O ine Web Applications

83
Faculdade de Engenharia da Universidade do Porto Offline Web Applications Enabling offline execution on the WOW! product Jo˜ ao Gon¸ calves da Costa Relat´ orio de Projecto realizado no ˆ Ambito do Mestrado Integrado em Engenharia Inform´ atica e Computa¸ c˜ao Orientador: Teresa Galv˜ao Dias (PhD.) Julho de 2008

Transcript of O ine Web Applications

Page 1: O ine Web Applications

Faculdade de Engenharia da Universidade do Porto

Offline Web Applications

Enabling offline execution on the WOW product

Joao Goncalves da Costa

Relatorio de Projecto realizado no Ambito do

Mestrado Integrado em Engenharia Informatica e Computacao

Orientador Teresa Galvao Dias (PhD)

Julho de 2008

ccopy Joao Goncalves da Costa 31 de Julho de 2008

Offline Web Applications

Joao Goncalves da Costa

Relatorio de Projecto realizado no Ambito do

Mestrado Integrado em Engenharia Informatica e Computacao

Aprovado em provas publicas pelo juri

Presidente Pedro Ferreira do Souto (PhD)

Arguente Artur Pereira (PhD)

Vogal Teresa Galvao Dias (PhD)

27 de Julho de 2008

Resumo

Este projecto teve como objectivo o estudo das Offline Web Applications (OWAs)e da sua implementacao em web applications ja existentes Neste ambito foi feitauma avaliacao da aplicacao desta tecnologia no WOW uma plataforma integradade gestao de ordens de trabalho desenvolvida pela Critical Software SA ao longodos ultimos 6 anos e implementada uma prova de conceito que permite a utilizacaode um conjunto de funcionalidades base desta web application independentementedo estado da ligacao a Internet

O conceito das OWAs enquadra-se numa tecnologia de Internet que permiteo acesso a um website atraves do browser mesmo na ausencia de uma ligacao arede global e foi considerado pela revista Technology Review como uma das maisimportantes tecnologias emergentes no final de 2007 [Nao08] O estudo efectuado noWOW pretende ser um primeiro passo na compreensao dos problemas associados asua implementacao e respectivas solucoes e tambem da avaliacao dos benefıcios dautilizacao desta tecnologia para os utilizadores finais

A evolucao das tecnologias associadas a Internet a que se assiste continua-mente impulsionou tambem evolucao da forma como a informacao e produzidadistribuıda e armazenada Surgiram novas web applications oferecendo funcionali-dades de criacao e edicao de conteudos que trouxeram consigo a vantagem de tornarpossıvel o acesso a informacao a partir de qualquer lugar mas tambem a desvan-tagem de tornar a ligacao a Internet uma condicao necessaria para que isto acontecaA proliferacao destas aplicacoes a crescente utilizacao da Internet [Gro08] e a adesaoaos seus servicos indiciam a existencia de uma dependencia cada vez maior de umaligacao que nem sempre existe

As OWAs vem assim colmatar esta falha colocando no lado do cliente parte dainformacao que ate agora vinha a ser armazenada no servidor e tornando nao sopossıvel a sua consulta offline como tambem reduzindo a carga no servidor umavez que reduz as transferencias de informacao

Pretende-se neste documento apresentar diferentes formas de como a utilizacaoda tecnologia OWA pode beneficiar as web applications de hoje melhorando o seudesempenho e dando-lhes novas possibilidades de execucao aproximando-as do desk-top

i

ii

Abstract

The main purpose of this project was to study the Offline Web Applications(OWAs) and its implementation in existent web applications With this goal in minda study was conducted to use this technology in WOW an integrated platform forwork orders and work flow management developed by Critical Software over thelast 6 years and implemented a proof of concept which enables the use of a baseset of functionality for this application regardless of the internet connection state

The concept of OWAs is connected with internet technology and allows accessto a website using the browser even if a connection to the internet is not availableThis concept was considered by Technology Review as one of the most importantemerging technologies in the last quarter of 2007 [Nao08] This study conductedover the WOW platform is intended to aid in the comprehension of the problemsand solutions associated to the use and implementation of OWA as well as thebenefits that it brings to the end user

The Internet and Internet technologies are changing the way in which informa-tion is produced distributed and stored New web applications appeared with newcontent creation and edition functionalities and with it the advantage of infor-mation retrieval from any place and time became possible but with the conditionof Internet connection availability With Internet use growing every year [Gro08]content creation is starting to move to this new platform The adoption of web ap-plications for content creation and edition is becoming more popular and it showsa dependency of a connection that is not always present

The OWAs are a way to solve this problem putting on the client side part ofthe information that was traditionally stored on the server and allows it to be seenand manipulated and helps reducing the server load

This document intends to present different ways in which this technology canhelp web applications as we know them improving the their overall performance andgiving them the ability to run on a browser regardless of the Internet connectionavailability

iii

iv

Agradecimentos

A realizacao e os objectivos alcancados neste projecto nao teriam sido possıveissem a colaboracao de inumeras pessoas Agradeco profundamente a todos os quecontribuıram directa ou indirectamente para o seu sucesso

A minha orientadora Professora Teresa Galvao Dias e ao Project ManagerEngenheiro Marcus Neves que me conduziram e acompanharam no desenvolvimentodeste projecto

A toda a equipa do WOW em especial o Pedro Maurıcio Costa e o Fabio Matosque contribuıram para a minha a minha integracao na Critical Software e que sempresouberam responder a todas as minhas questoes

A todos os que constituem a CSW Porto pelo fantastico ambiente de amizadeque me proporcionaram

Aos colegas de curso e a todos os que me auxiliaram na revisao deste documento

Os meus sinceros agradecimentos

Joao Goncalves da Costa

v

vi

Conteudo

1 Introducao 111 Enquadramento 112 Motivacao 213 Ambito 314 Objectivos 315 Estrutura do documento 3

2 Enquadramento do Projecto 521 Evolucao das arquitecturas de software 5

211 Thin-clients 5212 Fat-clients 6213 Arquitecturas cliente-servidor 7

22 Evolucao na Internet 8221 Paginas web estaticas 9222 Paginas web interactivas e paginas web dinamicas 9223 Web 20 e Ajax 11

23 Offline Web Applications 1324 Comparacao 13

3 Estado da arte 1731 Gears 17

311 Arquitectura 17312 Goggle Gears em dispositivos moveis 20

32 Adobe AIR 20321 Seguranca 22322 Assinatura do codigo 22

33 Mozilla Prism 23331 XML User Interface Language 23332 Prism 25

34 HTML 5 2535 Web applications que usam funcionalidades offline 26

351 Google Reader e Google Docs 26352 Remember the Milk 27353 MySpace e WordPresscom 27

36 Escolha da tecnologia 28

vii

CONTEUDO

4 Desenvolvimento 3341 Como ficar offline 33

411 Funcionalidades disponıveis em modo offline 3442 Modos de execucao 35

421 Modo ldquoutilizador deciderdquo 36422 Modo aplicacao decide 36423 Modo ldquoaplicacao assume o estado offlinerdquo 37

43 Sincronizacao de dados 38431 Quando sincronizar 39

44 WOW 4045 Visao geral sobre a arquitectura do WOW 4146 WOW Offline 42

461 Modo ldquoaplicacao deciderdquo com deteccao automatica da ligacao 43462 Implementacao do modo ldquoutilizador deciderdquo 45463 Especificacao do modo ldquoaplicacao assume o estado offlinerdquo 48

5 Resultados e Futuros Desenvolvimentos 5151 Resultados Obtidos 5152 Trabalho Futuro 52

6 Conclusoes 5561 Conclusoes 55

Referencias 59

A Screenshots 61

viii

Lista de Figuras

21 Arquitectura de um sistema thin-client em duas camadas (a esquerda)e em tres camadas (a direita) Note-se a inclusao do servidor (main-frame) na definicao das camadas desta arquitectura devido a fortedependencia cliente-servidor 9

22 Arquitectura de um fat-client em duas camadas (a esquerda) e emtres camadas (a direita) 10

23 Comparacao do modelo de web aplications sıncrono paginas estaticase interactivas abordados nas seccoes 221 e 222 com o modelo deweb applications Ajax (assıncrono) abordado na seccao 223 Figuraadaptada de http www adaptivepath com 15

31 Esquema UML do processo efectuado pelos recursos do Gears do tipoManagedResourceStore para a actualizacao dos conteudos definidosno ficheiro manifesto 29

41 Exemplo de uma arquitectura de uma web application sem uma ca-mada de abstraccao de dados Figura adaptada de http gears

google com 33

42 Exemplo de uma arquitectura de uma web application com uma ca-mada de abstraccao de dados Figura adaptada de http gears

google com 34

43 Exemplo de uma arquitectura de uma web application com uma ca-mada de abstraccao de dados e um data switch Figura adaptada dehttp gears google com 35

44 Esquema grafico ilustrando uma OWA executando no browser uti-lizando um modo de execucao do tipo ldquoaplicacao deciderdquo com de-teccao automatica do estado da ligacao via pedidos Ajax assıncronosa cada cinco segundos 37

45 Detalhe de um conjunto possıvel de estados e respectivas transicoespara uma dada ordem de trabalho no WOW desde a sua submissaono sistema ate a sua conclusao em fecho ou cancelamento Esta figurarepresenta apenas um exemplo ja que o mapa de estados para umaordem de trabalho e dinamico e pode ser alterado por um admin-istrador Figura retirada de uma brochura promocional do WOWCritical Software SA 41

ix

LISTA DE FIGURAS

46 A pagina inicial do WOW apresenta um resumo das ultimas ordensde trabalho enviadas e recebidas Na imagem pode-se observar atransicao do estado online para offline 44

47 Ilustracao do funcionamento do Gears numa web application que uti-liza um motor Ajax Os pedidos HTTP ou HTTPS podem ser inter-ceptados e tratados localmente ou podem ser feitos a uma maquinaremota consoante se verificarem ou nao as condicoes expressas noponto 311 E representado um acesso a uma base de dados local(fornecida pelo Gears) mas a sua utilizacao e opcional 45

48 Neste exemplo do modo ldquoaplicacao deciderdquo o teste da ligacao e feitoe feito a cada cinco segundos O resultado deste teste nao reflectesempre o estado real da aplicacao podendo levar a aplicacao a tercomportamentos indesejaveis Na figura assinala-se um perıodo detempo no qual a representacao interna do estado da ligacao nao cor-responde a realidade 46

49 Pagina de visualizacao do detalhe de uma ordem de trabalho 47410 Esquema UML que expressa os casos de uso do WOW Offline no

modo ldquoutilizador deciderdquo 48411 Esquema UML que expressa os casos de uso do WOW Offline no

modo ldquoutilizador deciderdquo 49412 Esquema UML que expressa o acto de recolha de dados em modo

online e offline recorrendo ao servidor (modo online) e ao sistemade armazenamento de dados local fornecido pelo Gears (modo offline) 50

A1 Dialogo apresentado ao utilizador na primeira activacao das funcional-idades offline no Google Docs amp Spreadsheets 61

A2 Na activacao das funcionalidades offline e tambem oferecida a possi-bilidade da criacao de alguns atalhos por exemplo no ambiente detrabalho 62

A3 O Google Docs mantem a todo o momento a possibilidade de alteracaodestas definicoes ou da anulacao dos servicos offline para um dadocomputador 62

A4 Apos a instalacao do Gears qualquer visita ao Remember The Milkdespoleta uma sincronizacao que ocorre automaticamente e sem ne-cessidade de intervencao por parte do utilizador 63

A5 Apos completar a sincronizacao de dados mesmo que a ligacao aInternet seja perdida o Remember the Milk continua disponıvel nobrowser (com excepcao das funcionalidades que pela sua naturezaexigem uma ligacao como por exemplo partilha de tarefas e enviode convites) 63

x

Lista de Tabelas

21 Comparacao entre thin-clients e fat-clients 7

31 Comparacao das funcionalidades oferecidas pelo Adobe AIR para asplataformas web e desktop 30

32 Resumo da utilizacao de tecnologias OWA em algumas web applica-tions consideradas na analise do estado da arte 31

xi

LISTA DE TABELAS

xii

Glossario

fat-client Cliente que nao depende totalmente de umservidor central para as suas actividadesde processamento e possui frequentementedispositivos de armazenamento de dados

6ndash8

thin-client Cliente que depende de um servidor centralpara as suas actividades de processamento

5ndash8

web application Sistema web (servidor rede HTTPbrowser) onde accoes do utilizador(navegacao e introducao de informacao)afectam o estado logico da aplicacao

i iii1ndash311ndash1517ndash1921ndash232728 3336ndash3842 5556

API Application Programming Interface 10 1718 2326 28

ASP Linguagem interpretada pelo servidorque permite a criacao de paginas webdinamicas Desenvolvida pela Microsoft

11

BSD Berkeley Software Distribution 28

CSS Cascading Style Sheets 12 2021 2324 46

DHTML Dynamic HyperText Transfer Protocol 24DOM Document Object Model 10 12

20 2324

DTD Document Type Definition 24

xiii

Glossario

ECMAScript Padrao de linguagem de programacaodefinido pela Ecma International que orig-inou o JavaScript e o JScript

24

Flash Conteudo interactivo de um ficheiro emformato SWF E desenvolvido pela Adobee visualizado atraves do Adobe FlashPlayer

21

Flex Framework baseada em XML e Action-Script desenvolvida pela Adobe para a pro-gramacao de Rich Internet Applications(RIA)

21

GPL GNU General Public License 23

HTML HyperText Markup Language 1 10ndash12 2124ndash2649

HTTP HyperText Transfer Protocol 2 26

JMS E uma API em Java que permite a troca demensagens entre componentes de software

42

JSON JavaScript Object Notation permite atroca de dados codificados num formatode texto de simples leitura

12 1828 34

LGPL GNU Lesser General Public License 23

Mozilla Prism Browser simplificado e ldquointerpretadorrdquo deeXtensible User Interface Language (XUL)(tambem designado por XULRunner) queacolhe web applications sem a interfacegrafica habitual de um browser

25

MPL Mozilla Public License 23

OCA Occasionally Connected Application 39OWA Offline Web Application i iii

2ndash515 1725 2628 3133 3651 5255 56

PDF Portable Document Format 21

xiv

Glossario

PHP Linguagem interpretada pelo servidorque permite a criacao de paginas webdinamicas mas que pode tambem ser in-vocada a partir da linha de comandos

11

pagina web estatica Pagina web que devolve sempre a mesmaresposta a todos os pedidos para todos osutilizadores e em qualquer contexto

5 9

RIA Rich Internet Applications web appli-cations que apresentam funcionalidadessemelhantes as desktop applications masque mantem a informacao no lado do servi-dor

5 1520 28

RSS Really Simple Syndication 27

SLA Service Level Agreement 40SQLite Segundo a definicao oficial SQLite is a

software library that implements a self-contained serverless zero-configurationtransactional SQL database engine

17

SSB Site Specific Browser 25SSL Secure Sockets Layer 22SWF ShockWave Flash 21

URL Uniform Resource Locator 18

VPN Virtual Private Network 38

WOW Work Orders Web Plataforma de gestaode ordens de trabalho e do seu fluxo de-senvolvida pela Critical Software SA

i iii28 3340ndash434551ndash5356

WWW World Wide Web 11 1214

XBL eXtensible Binding Language 24XHTML eXtensible HyperText Markup Language 12XML eXtensible Markup Language 11 12

23 2428

XSLT eXtensible Stylesheet Language Transfor-mation

12

XUL eXtensible User Interface Language xiv23ndash25

xv

Glossario

xvi

Capıtulo 1

Introducao

Neste capıtulo enquadra-se o tema do projecto introduzindo alguns dos conceitos

nos quais se baseia Apresentam-se as motivacoes ambito objectivos e a estrutura

deste documento

11 Enquadramento

A Internet foi originalmente concebida para ser um espaco de partilha de in-

formacao onde pessoas (atraves de maquinas) pudessem comunicar Na sua origem

as paginas eram estaticas constituıdas por texto formatado em HyperText Markup

Language (HTML) e ligadas entre si [BL96] Hoje encontramos conteudos cada vez

mais complexos e dinamicos incluindo som vıdeo ou streams multimedia [Loo06] e

em 2005 foi introduzido por [OrsquoR09] o termo Web 20

De acordo com [Greon] um website pode pertencer a uma ou varias das seguintes

categorias

bull Documento ndash um website essencialmente estatico onde alteracoes a uma

parte do conteudo nao tem implicacoes no seu comportamento

bull Base de dados ndash um directorio de informacao organizada em categorias

bull Aplicacao ndash um website dinamico que utiliza uma linguagem executada ou

interpretada do lado do servidor e que processa as accoes ou informacao in-

troduzida pelo utilizador para fornecer um servico ou nova informacao

A ultima destas categorias constitui aquilo que e normalmente designado por

web application O conceito utilizado ao longo deste documento e o mesmo que

o introduzido por Jim Coallen em [Con99] que define web application como um

1

Introducao

sistema web (servidor rede HyperText Transfer Protocol (HTTP) browser) onde

accoes do utilizador (navegacao e introducao de informacao) afectam o estado logico

da aplicacao A sua definicao tenta estabelecer que uma web application e um

sistema de software com estado de negocio1 e que a sua interface de interaccao com

o utilizador e distribuıdo atraves de um sistema web

12 Motivacao

A quantidade de informacao que e produzida e armazenada com recurso a es-

tas web applications disponıveis online tais como e-mail blogues ou mesmo docu-

mentacao tornam por vezes a disponibilidade de ligacao uma condicao necessaria

a produtividade e como consequencia desta barreira muitos potenciais utilizadores

opoem-se a adopcao de produtos web em detrimento das tradicionais desktop appli-

cations

Assegurar o acesso a uma ligacao de Internet e hoje muito mais facil A Internet

movel e ja uma realidade e encontra-se amplamente divulgada mas continuam a

existir diversas situacoes nas quais os utilizadores estao privados de uma ligacao

a Internet tais como uma viagem de metro ou de aviao ou quando se encontram

deslocados do seu paıs de origem e nao possuem nenhum plano de subscricao

Uma OWA consiste numa web application que para alem de manter todas as

caracterısticas anteriores se mantem disponıvel mesmo na ausencia de uma ligacao

a Internet e surge como uma tentativa de estreitar as barreiras existentes entre a

web e o desktop Isto significa que devera existir um mecanismo capaz de assegurar

a manutencao do estado logico da aplicacao quando a ligacao com o servidor e

quebrada permitindo ao utilizador continuar a utilizar a aplicacao e que sera capaz

de informar o servidor do estado em que a aplicacao se encontra quando a ligacao for

reposta A principal vantagem que advem desta possibilidade e evidente eliminar

a necessidade da existencia de uma ligacao a Internet para que a aplicacao possa ser

utilizada

Por outro lado a vontade de integracao de funcionalidades tıpicas das desktop

applications nas web applications foi um dos principais factores que impulsionou o

desenvolvimento deste conceito uma vez que obrigou a uma reflexao ldquopara alem

do browserrdquo e a uma adaptacao das arquitecturas existentes que permitisse ou o

acesso a funcionalidades disponibilizadas pelo sistema operativo ou pelo menos a

funcionalidades semelhantes Pretende-se com esta aproximacao tornar possıveis

interaccoes entre o desktop e o browser tais como arrastar um ficheiro para um

formulario web de upload de conteudos melhor suporte para o historico do clipboard

ou ainda o acesso ao sistema de ficheiros local Atingir estes objectivos reflecte-se

1NT business state

2

Introducao

num novo paradigma que reune as vantagens das web applications tais como os

updates instantaneos ou o facto de nao ser necessaria nenhuma instalacao e das

desktop applications como por exemplo persistencia no armazenamento de dados

acesso a funcionalidades do sistema operativo ou integracao e interaccao com outras

aplicacoes sejam elas web applications ou desktop applications

13 Ambito

Este projecto foi realizado na Critical Software SA no ambito do Mestrado

Integrado em Engenharia Informatica e Computacao (MIEIC) da Faculdade de En-

genharia da Universidade do Porto (FEUP) entre os meses de Fevereiro e Julho de

2008

14 Objectivos

Sao objectivos deste projecto

1 Estudar e documentar o tema das OWAs acompanhando os ultimos desenvolvi-

mentos nesta materia

2 Analisar o estado da arte fazendo uma analise crıtica e objectiva sobre as

diversas metodologias existentes

3 Implementar uma prova de conceito que permita a execucao offline de uma

web application documentando todo o processo

4 Estudar a possibilidade de permitir interaccao com a aplicacao (insercoes e

alteracoes aos dados) em modo offline

Em resumo o objectivo deste projecto foi estudar documentar e implementar

uma prova de conceito relacionada com o tema Offline Web Applications (OWA)

Este tema embora nao seja totalmente novo ganhou destaque ao longo do ano de

2007 com o surgimento de diversas ferramentas que se destinam a aproximar web

applications das desktop applications

15 Estrutura do documento

Este documento esta organizado em diferentes seccoes apresentando o projecto

numa sequencia logica organizada da seguinte forma

No capıtulo 1 faz-se uma breve apresentacao do conceito OWAs e do contexto em

que surge Apresenta-se tambem a estrutura do documento e definem-se os

termos e acronimos utilizados

3

Introducao

No capıtulo 2 faz-se uma descricao da evolucao das tecnologias que antecedem as

OWAs e das vantagens e desvantagens de cada uma como forma de enquadra-

mento

No capıtulo 3 analisa-se o estado da arte nesta materia Introduzem-se diversas

tecnologias directamente relacionadas com o tema deste projecto exemplos de

aplicacoes que as usam e as razoes que fundamentam as escolhas de tecnologias

efectuadas

O capıtulo 4 contem o desenvolvimento do projecto Analisa-se a plataforma

WOW de gestao integrada de ordens de trabalho a tecnologia escolhida e

a forma como foi utilizada para implementar a capacidade de execucao offline

O capıtulo 5 descreve os resultado obtidos comparando-os com as expectativas

iniciais do projecto e apresenta desenvolvimentos futuros e possibilidades de

continuacaoaplicacao do conhecimento adquirido

No capıtulo 6 apresentam-se as conclusoes

4

Capıtulo 2

Enquadramento do Projecto

Neste capıtulo apresenta-se um breve resumo da evolucao das arquitecturas de

software cliente-servidor e a forma como estas se comparam a evolucao da Inter-

net procurando estabelecer uma analogia entre o percurso de ambas as tecnolo-

gias Compara-se o comportamento e arquitectura dos thin-clients as paginas web

estaticas a evolucao dos fat-clients as paginas interactivas Web 20 e Ajax e

defende-se que as OWA constituem um proximo passo logico e evolutivo aproxi-

mando a web do desktop Referem-se ainda os principais factores que justificam a

importancia das OWAs e a estreita relacao que tem com as Rich Internet Application

(RIA)s

21 Evolucao das arquitecturas de software

Os termos thin-client e fat-client sao utilizados quer para descrever arquitecturas

logicas (de software) quer para descrever arquitecturas fısicas (de hardware) Neste

capıtulo excepto quando seja dada indicacao em contrario estes termos referem-se

sempre a uma arquitectura logica

Adicionalmente quando se trata de arquitecturas cliente-servidor pode-se estu-

dar a arquitectura desenvolvida do sistema como um todo da arquitectura do servi-

dor ou da arquitectura do cliente Para evitar equıvocos em especial na seccao 213

especifica-se em cada caso qual o sistema estudado

211 Thin-clients

Um thin-client e um computador cliente ou software cliente que no contexto

de uma arquitectura cliente-servidor depende de um servidor central para as suas

5

Enquadramento do Projecto

actividades de processamento e proporciona um canal de entrada e saıda de in-

formacao entre o utilizador e o servidor remoto Este termo quando aplicado a

hardware refere-se habitualmente a um computador que se destina a ser utilizado

como cliente de rede sem armazenamento local e com capacidade de processamento

reduzida [Gro02b] mas o conceito que aqui se analisa refere-se a uma arquitectura

de software que remonta ao inıcio das aplicacoes cliente-servidor

No inıcio da historia da computacao terminais ligavam-se directamente a main-

frames responsaveis por todo o processamento Nesta arquitectura era necessario

desenvolver duas aplicacoes distintas uma aplicacao central no servidor (main-

frame) responsavel pela gestao de toda a informacao e por todas as operacoes de

comunicacao e uma aplicacao de visualizacao instalada no cliente (terminal) O

papel destes terminais era apenas disponibilizar ao utilizador um meio de comu-

nicacao (entrada e saıda) e apresentacao dos resultados do servidor Nao tinham

um papel activo no calculo nem na logica de negocio e frequentemente nao tinham

tambem nenhum mecanismo de armazenamento de dados

Como vantagens esta arquitectura apresenta uma reduzida necessidade de con-

figuracao e manutencao do lado do cliente Uma vez que o centro do processamento

e manipulacao de dados ocorre no servidor existe tambem uma centralizacao da

informacao [NJN00] que introduz um ponto crıtico de falha1 Actualizacoes e novas

funcionalidades sao faceis de distribuir uma vez que requerem apenas alteracoes no

servidor [Gro02a]

212 Fat-clients

Contrastando com os thin-clients nesta arquitectura os clientes implementam

ja uma parte da logica de negocio e sao responsaveis pelo processamento de dados

Estes fat-clients vieram responder a necessidade crescente de aplicacoes com um

nıvel de interactividade e capacidade de configuracao maior que as oferecidas pela

arquitectura thin-client descrita na seccao 211 Apesar de manterem a sua de-

pendencia do servidor podem tambem ser executados sem uma conexao activa uma

vez que dispoe de armazenamento de dados local o que lhes confere a capacidade

de persistencia de dados e do estado de execucao entre cada sessao

Foi disponibilizando este controlo sobre o estado da aplicacao bem como acesso

a recursos locais (por exemplo sistema de ficheiros e perifericos) que surgiram as

primeiras verdadeiras desktop applications No entanto cada cliente tinha que ser

separadamente instalado no computador pessoal de cada utilizador que pretendesse

utilizar ou interagir com a aplicacao e uma actualizacao ao servidor implicava in-

variavelmente uma actualizacao manual tambem no cliente Uma vez que nem todos

1NT single point of failure

6

Enquadramento do Projecto

Thin-clients Fat-clientsNao toma parte no processamento dedados nem possui acesso ao sistema deficheiros

Participa activamente no processa-mento de dados recorrendo ao sis-tema de armazenamento local para ar-mazenamento de dados

Nao mantem registo do estado logicoda aplicacao entre duas sessoes de uti-lizacao

O acesso ao armazenamento localpermite-lhe manter registo do estadologico da aplicacao entre duas sessoes

O thin-client nao necessita de qualquerinstalacao estando ldquopronto a utilizarrdquo

E geralmente necessario instalar aaplicacao para poder interagir com oservidor

Qualquer update no servidor reflecte-seimediatamente por todos os clientes

Embora a aplicacao cliente possa aler-tar para existencia de novas versoes asactualizacoes tem que ser manualmenteinstalados pelo cliente

O software do cliente destina-se apenasa apresentacao de dados e comunicacaocom o servidor sendo portanto de sim-ples implementacao

Como o software do cliente toma parteactiva no processamento de dadosa sua implementacao requer cuidadosadicionais

Grande mobilidade uma vez que todaa informacao e mantida no servidor

Parte da informacao podera estar ape-nas do lado cliente pelo que existemalgumas restricoes a sua mobilidade

Tabela 21 Comparacao entre thin-clients e fat-clients

os utilizadores actualizam regularmente as suas aplicacoes o servidor tem que estar

preparado para lidar com versoes antigas2 ou descontinuar os seus servicos a uma

parte da sua comunidade de utilizadores ate que estes actualizem os seus sistemas

Como os utilizadores passam a utilizar os seus recursos locais para armazenamento

de dados as alteracoes que nao sejam sincronizadas com o servidor estao apenas

disponıveis nos seus computadores pessoais o que introduz uma restricao a mobili-

dade

Pode-se afirmar que as vantagens dos thin-clients sao as desvantagens dos fat-

clients e que as vantagens dos fat-clients sao as vantagens dos thin-clients tal como

se ilustra na Tabela 21

213 Arquitecturas cliente-servidor

Introduzidos os termos thin-client e fat-client interessa reafirmar que ambos

podem ser vistos como arquitecturas cliente-servidor Um cliente define-se como

um solicitador de servicos e um servidor como um prestador de servicos tal como

definido por [Sch96] e [Sad97]

2NT backward compatibility

7

Enquadramento do Projecto

As arquitecturas cliente-servidor sao categorizadas pela modularizacao com que

sao desenhadas sendo consideradas as seguintes camadas

1 Interface grafica (front-end) atraves da qual os utilizadores interagem com

a aplicacao Quando este modulo e implementado separadamente dos outros

dois constitui uma aplicacao thin-client por si so uma vez que nao implementa

regras de negocio (embora possa definir validacoes de formularios de insercao de

dados por exemplo) A informacao introduzida pelo utilizador e enviada para

o servidor que processa o seu pedido e retorna uma resposta Este processo

repete-se ate que o utilizador atinja o seu objectivo ou se desligue do sistema

2 A logica de negocio tambem designada por camada intermedia que imple-

menta as regras de aceitacao e validacao de todos os dados introduzidos pelo

utilizador E tambem a plataforma de comunicacao que une a camada superior

de visualizacao com a camada de acesso a dados

3 A camada de dados inclui quer o sistema de persistencia de dados onde sao

armazenados os dados relevantes como tambem os mecanismos necessarios

para a sua pesquisa seleccao e alteracao

Os thin-clients quando observados no seu conjunto de cliente e servidor podem

ser vistos quer como sistemas de duas camadas quer como sistemas de tres camadas

dependendo apenas da forma como o servidor for implementado No caso de na

implementacao do servidor nao se distinguir a camada de acesso a dados da camada

da logica de negocio sao designados por sistemas de duas camadas Caso seja feita

esta distincao sao designados por sistemas de tres camadas Ambos os casos sao

ilustrados na Figura 21

Historicamente os fat-clients eram implementados numa arquitectura em duas

camadas Possuıam apenas um modulo de visualizacao de dados designado por

camada de interface e um modulo que implementava toda a logica de negocio e

regras de acesso a base de dados No entanto com a introducao de ligacoes mais

rapidas e de computadores pessoais com maior capacidade de processamento e so-

bretudo devido a complexidade crescente das aplicacoes a logica de negocio e a

camada de acesso a dados tornaram-se independentes Este modelo e designado por

arquitectura em tres camadas e e ilustrado na Figura 22

22 Evolucao na Internet

Ao analisar a evolucao das arquitecturas das aplicacoes desenvolvidas para a

Internet podemos encontrar um paralelismo com a historia da arquitectura de soft-

ware

8

Enquadramento do Projecto

Figura 21 Arquitectura de um sistema thin-client em duas camadas (a esquerda) e emtres camadas (a direita) Note-se a inclusao do servidor (mainframe) na definicao dascamadas desta arquitectura devido a forte dependencia cliente-servidor

221 Paginas web estaticas

Uma pagina web estatica devolve sempre a mesma resposta a todos os pedidos

para todos os utilizadores e em qualquer contexto utilizando o hipertexto como

forma de ligacao entre diversas paginas estaticas

A informacao e armazenada num servidor e o papel do cliente e apenas a apre-

sentacao da informacao Esta forma de disponibilizacao de informacao pode assim

ser comparada com os thin-clients descritos na seccao 211 o utilizador acede a

um website estatico para visualizar informacao sem que o cliente tome parte no

processamento A unica diferenca e que no caso da web estatica a informacao ap-

resentada e sempre a mesma enquanto que nos thin-clients era frequente existir a

possibilidade de insercao de dados no cliente e apos o seu processamento servidor

nova informacao poderia ser apresentada O hipertexto e utilizado para ligar as

paginas entre si numa rede de conteudos relacionados e a navegacao sıncrona era

feita atraves de cliques do rato a cada clique uma nova pagina era apresentada

Este modelo sıncrono e ilustrado na Figura 23

222 Paginas web interactivas e paginas web dinamicas

O JavaScript e uma linguagem interpretada de scripting que tem os browsers

como principal ambiente de acolhimento Os browsers utilizam uma Application

9

Enquadramento do Projecto

Figura 22 Arquitectura de um fat-client em duas camadas (a esquerda) e em tres camadas(a direita)

Programming Interface (API) publica para criar ldquoobjectosrdquo responsaveis por reflectir

e disponibilizar o Document Object Model (DOM) para o motor de JavaScript

A utilizacao mais frequente desta linguagem e a escrita de funcoes que sao em-

bebidas ou incluıdas em paginas web e que interagem com o DOM Uma vez que o

JavaScript e executado localmente (na maquina do cliente e nao no servidor) e capaz

de responder rapidamente a accoes do utilizador tornando a execucao de aplicacoes

no browser mais fluıdas o JavaScript pode tambem detectar accoes do utilizador

que o HTML nao pode tal como o pressionar de uma tecla

Em Dezembro de 1995 a Netscape Communications adicionou suporte para o

JavaScript no browser Netscape Navigator3 e em Agosto de 1996 o browser Internet

Explorer4 da Microsoft passou a tambem a suportar uma versao semelhante desta

linguagem (hoje todos os principais browsers suportam esta tecnologia)

Esta inovacao permitiu tornar os websites mais interactivos mas a sua utilizacao

esteve confinada apenas a este proposito durante um longo perıodo As paginas

passaram a responder activamente a accoes do utilizador (sendo uma das utilizacoes

3Netscape Communications ndash httpbrowsernetscapecom4Microsoft Internet Explorer ndash httpwwwmicrosoftcomwindowsproductswinfamilyie

10

Enquadramento do Projecto

mais vulgares a validacao de formularios) mas continuaram essencialmente estaticas

O JavaScript ainda nao era nesta altura utilizado para processar dados

Tambem nesta altura (1995ndash96) surgiram linguagens server-side como o PHP

Hypertext Preprocessor (PHP) e Active Server Pages (ASP) e o servidor passou a ter

um processamento de dados introduzidos pelo utilizador mais activo Generalizaram-

se as paginas dinamicas capazes de responder a insercao de dados ou outros pedidos

determinados por accoes do utilizador As paginas tornaram-se aplicacoes web ap-

plications

Uma definicao tradicional de web application e um conjunto de paginas web

logicamente agrupadas e geridas por uma unica entidade que tem como pontos de

entrada formularios de insercao de dados (web forms) Uma web application nao e

mais do que uma aplicacao que e acedida atraves de um browser Tem geralmente

uma arquitectura logica em tres (interface logica de negocio e camada de dados)

camadas e estao armazenadas num servidor

Ha dois tipos de web applications

bull Orientadas a apresentacao Sao web applications que geram paginas web in-

teractivas constituıdas por varios tipos de linguagens de anotacao (por exem-

plo HTML eXtensible Markup Language (XML)) e que apresentam conteudo

dinamico como resposta a pedidos efectuados pelo utilizador

bull Orientadas aos servicos Uma web application orientada aos servicos imple-

menta o ponto de acesso para um ou mais de um web service Sao geralmente

clientes de service oriented web applications

Uma vantagem significativa de implementar uma web application de forma a

suportar as funcionalidades padrao dos browsers e que estas terao o mesmo com-

portamento independentemente da plataforma e do browser a partir do qual serao

acedidas No entanto diferentes implementacoes de browsers devido a diferentes

interpretacoes dos padroes definidos tornam por vezes esta tarefa um pouco mais

complicada existindo inclusivamente na web guioes de compatibilidade para os difer-

entes browsers como [Smi07]

223 Web 20 e Ajax

O termo web 20 descreve uma tendencia de utilizacao e de design observada

na World Wide Web (WWW) com o objectivo de melhorar a criatividade partilha

de informacao e principalmente a colaboracao entre utilizadores Estes conceitos

levaram ao desenvolvimento e evolucao de comunidades online tais como redes so-

ciais wikis e blogues

11

Enquadramento do Projecto

O termo tornou-se mais conhecido apos a primeira conferencia OrsquoReilly Media

Web 20 em 2004 e apesar de sugerir uma nova versao da WWW nao se refere a

qualquer evolucao tecnologica mas apenas a alteracoes a forma como os utilizadores

se servem da web De acordo com Tim OrsquoReilly [OrsquoR06] ldquoWeb 20 e uma revolucao

na industria do software causada pela adopcao da web como uma plataforma e pela

tentativa de entendimento das regras para o sucesso nesta nova plataformardquo

O desenvolvimento da Web 20 serve-se muitas vezes de um outro conceito Ajax

O conceito que hoje conhecemos como Ajax muitas vezes incorrectamente de-

scrito como uma tecnologia foi originalmente criado para permitir o desenvolvimento

de web applications que se assemelhassem ainda mais a aplicacoes de desktop Este

conceito foi melhor descrito por [Gar05] como um conjunto de varias tecnologias

que podem ser utilizadas para melhorar a experiencia do utilizador de uma dada

web application introduzindo a capacidade assıncrona de envio de pedidos ou da

recepcao assıncrona de respostas As tecnologias mais frequentemente envolvidas

sao

bull eXtensible HyperText Markup Language (XHTML) e Cascading Style Sheets

(CSS) padrao para a apresentacao

bull interaccao dinamica atraves do DOM

bull troca e manipulacao de dados utilizando XML e eXtensible Stylesheet Lan-

guage Transformation (XSLT) ou JavaScript Object Notation (JSON)

bull pedidos assıncronos utilizando XMLHttpRequest [vK08]

bull JavaScript utilizado para integrar todas estas tecnologias

E importante frisar que o Ajax nao e um produto nem uma tecnologia E um

termo que descreve a utilizacao de um conjunto de tecnologias para o desenvolvi-

mento de web applications com um elevado grau de interactividade Comparativa-

mente as web applications tradicionais o Ajax introduz uma camada de visualizacao

diferente em tres importantes pontos

1 Do lado do cliente existe um motor que serve de intermediario entre a interface

da aplicacao e o servidor

2 A actividade do utilizador despoleta chamadas JavaScript em vez de um pedido

de pagina directamente ao servidor

3 Informacao codificada em XML em vez de paginas HTML e trocada entre o

servidor e o cliente

12

Enquadramento do Projecto

Isto significa que as paginas que utilizam Ajax contem um motor do lado do

cliente composto por um conjunto de funcoes JavaScript responsavel pela comu-

nicacao com o servidor e por actualizar a interface com o resultado dessa mesma

comunicacao

Na Figura 23 ilustra-se a natureza assıncrona do Ajax quando comparada com

as web applications tradicionais Como se pode observar adicionando um mecan-

ismo Ajax a uma web application eliminam-se diversos tempos de espera associados

a comunicacoes com o servidor uma vez que a interface nao fica ldquobloqueadardquo a es-

pera da resposta Obtem-se assim aplicacoes com um comportamento mais fluido

eliminando tempos de espera entre cada ldquocliquerdquo e melhorando a experiencia do

utilizador

23 Offline Web Applications

A informacao grafica (bem como folhas de estilo e scripts) tais como as ima-

gens que constituem o visual de uma web application e ja tratada de forma especial

pelos cada vez mais avancados sistemas de cache (armazenamento temporario) dos

browsers Mas estes nao sao ainda capazes de guardar conteudo criado pelo uti-

lizador nem de apresentar informacao independentemente do estado da ligacao

Numa altura onde se fala de servicos de Internet wireless municipalizados [Kha]

comunicacoes 3G e ligacoes de banda larga a alta velocidade a ligacao a rede global

continua a nao estar permanentemente disponıvel para os utilizadores Na WWW

encontra-se uma importante parte da informacao e das aplicacoes utilizadas para

criar e editar conteudos Por vezes informacao vital para a produtividade pode

desaparecer subitamente do mapa de acesso de um utilizador quando este entra no

metro num aviao ou mesmo quando se desloca para uma cidade ou paıs diferente

do habitual onde nao subscreve um plano de acesso que lhe garanta a ligacao

Permitir o acesso offline a estes recursos assume assim a sua importancia porque

permitira estender o alcance da informacao a locais onde nunca esteve antes e per-

mitira tambem melhorar o desempenho das web applications colocando informacao

mais perto dos utilizadores reduzindo a transferencia de dados apenas ao essencial

24 Comparacao

Nas evolucoes descritas neste capıtulo 2 pode-se observar que existe um par-

alelismo entre a evolucao das arquitecturas tradicionais cliente-servidor e a evolucao

a que se assiste na web O comportamento e arquitectura dos thin-clients assemelha-

se ao das paginas estaticas no sentido em que o browser nao toma parte em qualquer

13

Enquadramento do Projecto

processamento e serve apenas como uma plataforma de interaccao com o servidor

tal como os clientes descritos na seccao 211

A sua proxima evolucao os fat-clients trouxeram parte da capacidade de pro-

cessamento para o lado do cliente Na web foi tambem esta a inovacao tecnologica

a que se assistiu com a evolucao das tecnologias que permitiram a criacao de ver-

dadeiras aplicacoes e com a introducao do Javascript no browser dando ao cliente

a capacidade de processamento de dados A necessidade da separacao do codigo

em camadas logicas advem da crescente complexidade das web applications Esta

pratica permite entre outras coisas melhorar o processo de desenvolvimento e a

capacidade de manutencao de uma aplicacao

Os fat-clients tem tambem a capacidade de armazenamento de dados o que

permite a persistencia de informacoes entre duas sessoes e que algumas operacoes

sejam executadas sem a necessidade de comunicacao com o servidor Este facto pode

tambem ser uma realidade nas web applications com a adopcao das tecnologias OWA

Neste momento assiste-se a uma utilizacao cada vez maior da web como uma

plataforma de desenvolvimento A capacidade de cooperacao na edicao de conteudos

e a mobilidade proporcionada por esta plataforma sao os principais factores que

alimentam esta mudanca e pela primeira vez as aplicacoes tradicionais tem com-

peticao vinda de web applications A prova do reconhecimento da web como plataforma

de desenvolvimento pode ser retirada da aposta de empresas como a Adobe e Mi-

crosoft que lancaram publicamente ferramentas web complementares a produtos

seus tradicionalmente associados ao desktop ndash Acrobatcom5 e Microsoft Office

Live6 Dotar estas web applications da capacidade de execucao offline significa

aproximar a web e o desktop reunindo ldquoo melhor de dois mundosrdquo

As vantagens da mobilidade possıvel atraves da web a cooperacao na criacao e

edicao de conteudos e a possibilidade de utilizar aplicacoes sempre actualizadas e

sem necessidade de instalacao sao algumas das principais vantagens que promovem

esta mudanca que devido as preocupacoes associadas a usabilidade e experiencia do

utilizador esta fortemente associada ao desenvolvimento de Rich Internet Applica-

tion (RIA)s

5Adobe Acrobatcom httpwwwacrobatcom6Microsoft ndash httpsmallbusinessofficelivecom

14

Enquadramento do Projecto

Figura 23 Comparacao do modelo de web aplications sıncrono paginas estaticas e in-teractivas abordados nas seccoes 221 e 222 com o modelo de web applications Ajax(assıncrono) abordado na seccao 223 Figura adaptada de http www adaptivepath

com

15

Enquadramento do Projecto

16

Capıtulo 3

Estado da arte

Apesar de o conceito das OWAs nao ser absolutamente novo as tecnologias que

o suportam sao recentes Neste capıtulo descrevem-se quatro tecnologias que foram

tidas como principais candidatas para o desenvolvimento deste projecto Descrevem-

se ainda alguns exemplos de web applications que disponibilizam actualmente fun-

cionalidades offline e o processo da escolha da tecnologia a utilizar neste projecto

31 Gears

O Gears1 e uma extensao as funcionalidades do browser introduzido pelo Google

que tem como principal objectivo tornar possıvel a visualizacao de paginas de Inter-

net mesmo sem uma conexao disponıvel Encontra-se disponıvel para as platafor-

mas Windows Macintosh e Linux e oferece uma API de Javascript que permite

a scripts aceder a um mecanismo de armazenamento local baseado numa base de

dados SQLite

311 Arquitectura

Esta ferramenta e constituıda por tres componentes principais

bull LocalServer mdash Intercepta pedidos de paginas web e serve-as localmente

bull Database mdash Uma base de dados relacional construıda sobre SQLite

bull WorkerPool mdash Permite executar operacoes de computacao de uma forma

assıncrona sem afectar a capacidade de resposta e fluidez de execucao da web

application Assemelham-se a processos

1Google Inc ndash Mais informacao em httpgearsgooglecom

17

Estado da arte

LocalServer

O modulo LocalServer e uma cache de Uniform Resource Locators (URLs)

controlada pela web application Quando nao existe uma ligacao a Internet e e

feito um pedido para um URL presente nesta cache o LocalServer intercepta-o e

responde ao pedido localmente a partir do disco rıgido do utilizador A aplicacao

pode utilizar dois tipos diferentes de armazenamento local de URLs

bull ResourceStore ndash serve para capturar URLs utilizando exclusivamente a API

de Javascript disponibilizada para o efeito Uma aplicacao podera criar e

utilizar diversos ResourceStores simultaneamente para capturar ficheiros de

dados que necessitam de ser enderecados por um URL tal como um ficheiro

PDF ou uma imagem

bull ManagedResourceStore ndash serve para capturar um conjunto de URLs que estao

relacionados e que sao declarado num ficheiro de manifesto (especificado em

JSON) e que sao automaticamente actualizados O ManagedResourceStore

permite que o conjunto de recursos necessarios para correr uma web application

seja capturado e mantido actualizado automaticamente

A principal diferenca entre estes dois tipos de armazenamento de URLs e a forma

como sao actualizados os seus conteudos Os conteudos de um ManagedResourceStore

sao actualizados sempre que a versao contida no ficheiro de manifesto for alterada

enquanto que os conteudos de um ResourceStore nunca sao actualizados automati-

camente mas apenas quando for explicitamente ordenado pela aplicacao

O LocalServer e capaz de interceptar e servir localmente pedidos de HTTP e

HTTPS sempre que se reunam as seguintes condicoes

1 O URL encontra-se armazenado num ResourceStore ou ManagedResourceStore

2 O sistema de armazenamento local encontra-se activo (enabled = true) Se

o sistema de armazenamento local tiver o atributo requiredCookie o pedido

devera conter um cookie que lhe corresponda

O LocalServer nao necessita de monitorizar o estado da ligacao para atender aos

pedidos Na verdade sempre que as condicoes previamente enunciadas se verificarem

o LocalServer interceptara os pedidos e independentemente do estado da ligacao

a Internet servi-los-a a partir do disco rıgido local Cabera a aplicacao definir qual

o modo em que pretende executar um pedido (online ou offline) definindo o valor

de verdade da propriedade enabled

18

Estado da arte

Database

O modulo Database permite guardar dados da web application assegurando a

sua persistencia Os dados sao guardados de forma relacional no disco rıgido do uti-

lizador2 de acordo com o modelo de seguranca estabelecido pelo Gears3 significando

que uma aplicacao nao pode aceder a conteudos fora do seu domınio

WorkerPool

Nos web browsers uma operacao pesada de computacao pode tornar a interface

lenta e tornar menos agradavel a experiencia do utilizador O modulo WorkerPool

permite correr operacoes em background sem bloquear a interface com o utilizador

Os scripts executados numa WorkerPool nao activam os mecanismos de seguranca

do browser que mostram a mensagem ldquoA script on this page may be busy or may

have stopped respondingrdquo

O WorkerPool comporta-se como um conjunto de processos em vez de threads

Os Workers nao partilham qualquer estado de execucao o que significa que uma

alteracao a uma variavel num Worker nao afecta em nada a execucao de outro

Worker Alem disso os Workers nao herdam automaticamente nenhum codigo dos

seus pais Cada Worker e membro de um WorkerPool e os Workers podem in-

teragir entre si enviando mensagens em formato de texto ou JSON No entanto ha

tambem algumas limitacoes os Workers nao tem acesso ao DOM e objectos como

window ou document nao se encontram acessıveis Isto e consequencia de os Workers

nao partilharem o estado de execucao Mas tem acesso a todas as funcoes built-in

do Javascript A maioria das funcionalidades do Gears pode tambem ser acedida

atraves de uma variavel global especial definida como googlegearsfactory Para

outras funcionalidades especıficas os Workers podem ldquopedirrdquo a pagina principal para

continuar a execucao atraves do envio de mensagens

Outras funcionalidades

bull HttpRequest ndash Este modulo implementa a especificacao W3C XmlHttpRe-

quest definida em [vK08] tornando-a disponıvel para os workers e para a

pagina principal

bull Timer ndash Este modulo implementa a especificacao de timers tal como descrito

por [Hic08] e torna-os disponıveis para os workers e para a pagina principal

2Consultar httpcodegooglecomapisgearsapi_databasehtmldirectories3Consultar httpcodegooglecomapisgearssecurityhtml

19

Estado da arte

bull Factory ndash Esta classe e utilizada para instanciar todos os outros objectos da

API do Gears atraves do seu metodo create Este metodo pode ser utilizado

com os seguintes parametros

ndash betadatabase

ndash betahttprequest

ndash betalocalserver

ndash betatimer

ndash betaworkerpool

312 Goggle Gears em dispositivos moveis

O Gears esta tambem disponıvel em dispositivos Windows Mobile 5 e 6

Os dispositivos moveis estao pela sua natureza frequentemente desconectados

da Internet Mesmo quando possuem uma ligacao as latencias na transferencia de

dados em redes moveis tornam as aplicacoes pouco fluıdas mas o Gears permite

ultrapassar este obstaculo

O Gears funciona exactamente da mesma forma em dispositivos moveis equipados

com o Windows Mobile 5 e 6 como num computador comum Se uma aplicacao tiver

sido implementado com suporte para o Gears entao tambem estara preparada para

ser executada num dispositivo movel mas as limitacoes dos browsers disponıveis

para dispositivos moveis tem que ser consideradas Isto significa prever as condicoes

que permitam uma boa usabilidade devido aos pequenos ecras destes dispositivos

bem como o seu suporte limitado dos padroes do DOM CSS e JavaScript

32 Adobe AIR

O Adobe AIR4 e um runtime compatıvel com diversos browsers e sistemas opera-

tivos que pretende dar aos programadores a possibilidade de combinar diversas tec-

nologias de producao de conteudos para a Internet no desenvolvimento de Rich Inter-

net Application (RIA)s O Adobe AIR mantem uma relacao com o browser mas es-

tende as suas capacidades e tecnologias permitindo o desenvolvimento de aplicacoes

tambem para o ambiente de trabalho com janelas em tudo semelhantes as do sis-

tema operativo Segundo a Adobe o objectivo e complementar o browser dando

aos utilizadores (mas essencialmente aos programadores e equipas de desenvolvi-

mento) a escolha sobre como distribuir as suas aplicacoes Para este efeito o Adobe

AIR tem uma aproximacao diferente do Gears Em vez de ldquoestenderrdquo o browser

acrescentando-lhe funcionalidades o AIR permite tambem o desenvolvimento de

4Adobe - httpwwwadobecomproductsair

20

Estado da arte

aplicacoes que se destinam a ser executadas fora do ambiente do browser mas uti-

lizando as tecnologias comuns da Internet (por exemplo HTML CSS JavaScript

Flash Flex)[CDGH08]

A utilizacao desta tecnologia permite utilizar o browser ou o proprio runtime

Adobe AIR como plataforma de execucao da aplicacao

Na Tabela 31 faz-se uma comparacao das funcionalidades disponıveis de acordo

consoante se escolha o browser ou o desktop como plataforma base para a aplicacao

Uma vez que as aplicacoes Adobe AIR na plataforma desktop tem um caracter

persistente (sao instaladas no computador do utilizador) o Adobe AIR tem um

modelo de seguranca que se assemelha com o das tradicionais aplicacoes desktop

[Ada08] Este modelo e analisado nas seccoes 321 e 322 O ambiente em que

e executado o browser e restringido a execucao de web applications que podem

ser de varias origens (incluindo de origens anonimas ou sem confianca) O Adobe

AIR proporciona acesso a capacidades como acesso a ficheiros que necessitam da

confianca do utilizador

bull HTML ndash O desenvolvimento de aplicacoes para o Adobe AIR pode ser feito

com recurso a tecnologias de HTML e Ajax comuns utilizando as linguagens

de markup existentes distribuıdas como texto e interpretadas em execucao

(runtime)

bull Flash ndash Outra alternativa sera a utilizacao da linguagem Flash Permite a

renderizacao de graficos vectoriais e audiovıdeo com suporte nativo Utiliza

ActionScript para adicionar maior interactividade com o utilizador

bull Flex ndash O Flex e uma framework open source para o desenvolvimento de RIAs

usando Flash As aplicacoes Flex sao na realidade Flash sendo a principal

diferenca o ambiente de desenvolvimento

Como resultado uma aplicacao AIR podera ser implementada

bull Baseada em Flash ou Flex (aplicacoes cujo conteudo base e em ShockWave

Flash (SWF))

bull Baseada em Flash ou Flex tambem com HTML ou Portable Document Format

(PDF) Aplicacoes cujo conteudo de base e em FlashFlex (SWF) com HTML

(HTML JavaScript CSS) ou conteudo PDF incluıdo

bull Baseada em HTML Aplicacoes cujo conteudo base e em HTML Javascript

CSS

bull Baseada em HTML utilizando tambem FlashFlex ou PDF

21

Estado da arte

Os utilizadores interagem com uma aplicacao AIR da mesma forma que interagem

com outras aplicacoes com janelas nativas do seu sistema operativo O runtime e

instalado uma vez no computador do utilizador e a partir desse momento todas as

aplicacoes AIR terao o mesmo aspecto que qualquer outra aplicacao para o desktop

321 Seguranca

Permitir que uma web application aceda ao disco de armazenamento do utilizador

pode comprometer seriamente a sua seguranca Neste sentido o Adobe AIR tem

suporte para assinaturas digitais (Secure Sockets Layer (SSL)) que podem ser com-

pradas pelas equipas de desenvolvimento que o desejem e cujos certificados serao

apresentados ao utilizador no momento da instalacao Um outro aspecto ainda

relativo a seguranca e o mecanismo de isolamento de cada ambiente (sandbox )

322 Assinatura do codigo

O runtime AIR exige que todas as aplicacoes estejam digitalmente assinadas As

assinaturas digitais de codigo sao um processo que visa garantir a integridade da

aplicacao e a identidade do seu autor no momento da instalacao As equipas de

desenvolvimento podem ldquoassinarrdquo uma aplicacao utilizando um certificado atribuıdo

por uma Entidade Certificadora (Certification Authority) ou atraves de um certifi-

cado individual (self signed certificate) Neste momento o Adobe AIR suporta como

entidades certificadoras a Verisign e a Thawte [Ado08]

O instalador apresenta o nome de quem publica a aplicacao quando o codigo tiver

sido assinado com um certificado que apresente confianca ou que esteja encadeado

com um certificado que tenha ja sido aceite no computador em que se esta a instalar

a aplicacao

As equipas de desenvolvimento podem tambem assinar as aplicacoes com um

certificado auto-atribuıdo (um certificado criado por elas proprias) mas neste caso

o instalador apresentara estas aplicacoes como sendo de uma origem nao verificada

O AIR utiliza a infraestrutura publica de chaves [Ent07] suportada pelo arquivo

local do sistema operativo Para que a origem da aplicacao seja reconhecida o

computador onde a aplicacao AIR esta a ser instalada tem que confiar directamente

no certificado que foi utilizado para assinar a aplicacao ou confiar num certificado

que esteja num encadeamento logico de certificados confiados e que se ligue desta

forma ao certificado utilizado para assinar a aplicacao

Todas as aplicacoes AIR tem caracterısticas em comum independentemente da

tecnologia utilizada para o seu desenvolvimento (HTMLFlexFlash) No ambito

de uma aplicacao AIR existem um conjunto de APIs que estao disponıveis e que

tornam possıvel o acesso ao sistema local (leitura e escrita) e a recursos de rede que

22

Estado da arte

de outra forma nunca estariam acessıveis a partir de uma web application comum

Cada aplicacao AIR possui tambem diferentes nıveis de isolamento chamados secu-

rity sandboxes dependendo do tipo de conteudo que esta a ser carregado e do seu

objectivo

bull Isolamento ao nıvel da aplicacao5 ndash E a raiz de cada aplicacao AIR Este

nıvel de isolamento permite o acesso a APIs privilegiadas e especıficas do

AIR Em contrapartida e negado o acesso a algumas APIs que poderiam ser

facilmente utilizadas de forma maliciosa contra o utilizador final Importacao

dinamica de conteudos remotos e geralmente proibido e as tecnicas e mecan-

ismos de geracao dinamica de codigo sao fortemente restringidas Apenas

conteudo carregado directamente da directoria base da aplicacao podera ser

colocado neste nıvel de isolamento

bull Isolamento nao especıfico da aplicacao6 ndash contem todo o outro conteudo

que nao tenha sido carregado directamente para o isolamento da aplicacao

Isto inclui conteudo local e remoto Este tipo de conteudo nao tem acesso

directo as APIs do AIR e rege-se pelas mesmas regras tal como se tivesse sido

carregado por um browser a partir da mesma localizacao (por exemplo HTML

carregado a partir de um domınio remoto comporta-se da mesma forma que se

fosse acedido a partir do browser)

33 Mozilla Prism

331 XML User Interface Language

O eXtensible User Interface Language (XUL) e uma linguagem de anotacao

baseada em XML desenvolvida pela Mozilla Foundation que opera em aplicacoes

Mozilla multi plataforma tal como o Firefox O motor Gecko e a unica imple-

mentacao completa desta linguagem que foi desenhada sobre padroes web comuns

como CSS JavaScript e o DOM e permite o desenvolvimento de interfaces graficas

utilizando elementos pre-definidos tais como window box page textbox radio

button entre outros Infelizmente o XUL nao possui qualquer especificacao formal

ou implementacoes de inter-operabilidade para outros motores que nao o Gecko No

entanto a sua implementacao e licenciada em codigo aberto pelas licencas GNU Gen-

eral Public License (GPL) GNU Lesser General Public License (LGPL) e Mozilla

Public License (MPL)

Enunciam-se algumas caracterısticas desta linguagem

5NT application sandbox6NT non-application sandbox

23

Estado da arte

Liguagem de anotacao poderosa baseada em componentes (widgets) O ob-

jectivo do XUL e permitir a construcao de aplicacoes multi-plataforma em

claro contraste com o Dynamic HyperText Transfer Protocol (DHTML) que se

destina ao desenvolvimento de paginas web Por esta razao o XUL esta orien-

tado a componentes tais como janelas botoes e etiquetas em vez de paginas

cabecalhos de texto e ligacoes de hipertexto Investir tempo e esforco para

atingir este mesmo resultado em aplicacoes baseadas em DHTML compromete

frequentemente a complexidade e desempenho da aplicacao

Baseado em padroes O XUL e um dialecto XML baseado no padrao W3C XML

10 As aplicacoes escritas em XUL sao tambem baseadas em especificacoes

W3C adicionais como HTML 40 CSS DOM nıvel 1 e 2 JavaScript 15

incluindo ECMA-262 Edition 3 (ECMAscript)

Portabilidade entre plataformas Tal como HTML o XUL foi desenhado para

ser independente da plataforma em que e utilizado tornando as aplicacoes

facilmente portaveis entre sistemas operativos nos quais o Mozilla e suportado

Uma vez que o XUL oferece um nıvel de abstraccao dos componentes graficos

de interface que disponibiliza implementa a premissa ldquoum codigo para todas

as plataformasrdquo A interface grafica de todos os produtos centrais Mozilla

(browser instant messenger livro de enderecos) e escrita em XUL com um

unico codigo base que suporta todas as plataformas Mozilla

Separacao entre o nıvel de apresentacao e a logica de negocio Uma das

maiores preocupacoes no desenvolvimento para a Internet e a forte ligacao

entre estas duas camadas (interface e logica) Isto constitui um problema sig-

nificativo no desenvolvimento de grandes aplicacoes especialmente quando o

desenvolvimento e feito em ambientes de equipa porque as capacidades de de-

senvolvimento destas duas partes da aplicacao estao muitas vezes espalhadas

por diferentes elementos O XUL permite uma clara distincao entre a definicao

da aplicacao cliente e da logica de implementacao (XUL eXtensible Binding

Language (XBL) e JavaScript) apresentacao (CSS e imagens) internacional-

izacao (Document Type Definitions (DTDs) e etiquetas de texto em lınguas

especıficas guardados em ficheiros properties) O esquema grafico e apre-

sentacao de uma aplicacao XUL pode ser alterado de forma independente da

sua logica ou implementacao e a aplicacao pode ainda ser traduzida (interna-

tionalization) de forma independente da sua logica implementacao ou apre-

sentacao Este grau de separacao resulta em aplicacoes que sao mais faceis de

manter pelos programadores e facilmente adaptadas por designers e tradutores

24

Estado da arte

Facil adaptacao Outro benefıcio que advem do nıvel de separacao entre logica

de negocio e apresentacao oferecido pelo XUL e a facilidade com que se pode

adaptar uma aplicacao para diferentes clientes ou grupos de utilizadores Um

programador pode utilizar a mesma aplicacao base e adapta-la consoante as

necessidades atraves de diferentes temas (skins) e ficheiros de lınguas Desta

forma uma aplicacao escrita e desenvolvida em Ingles pode ser rapidamente

traduzida para Portugues e distribuıda com outra aparencia mais apropriada

ao cliente alvo

332 Prism

O Mozilla Prism e um browser simplificado e ldquointerpretadorrdquo de XUL (tambem

designado por XULRunner) que acolhe web applications sem a interface grafica ha-

bitual de um browser Baseia-se num conceito designado por Site Specific Browser

(SSB) Um SSB e uma aplicacao com um browser embebido desenhado para exe-

cutar apenas uma web application Nao possui os menus e barras de ferramentas

habituais Um SSB tem uma integracao com o sistema operativo e com o desktop

muito mais estreita do que uma web application acedida atraves de um browser uma

vez que e executado em janela propria

O Prism resulta de uma experiencia da Mozilla e visa reduzir as diferencas entre

as desktop applications tradicionais e as web applications Um dos aspectos focados e

a experiencia do utilizador Numa apresentacao oficial e dito que ldquo[o Prism] pretende

ser uma ponte entre as diferencas que existem entre as aplicacoes tradicionais de

desktop e as web applications explorando novos modelos de usabilidade enquanto

que a linha que as separa se continua a definirrdquo [Lab07]

34 HTML 5

A especificacao HTML 5 [Hic08] que se encontra em fase de desenvolvimento

pelo grupo WHATWG pretende ser uma norma de substituicao dos padroes HTML

4 XHTML 1x e do DOM2 HTML Uma das propriedades que o distingue das tec-

nologias que pretende substituir e precisamente o suporte para OWA e armazena-

mento de dados no cliente de uma forma relacional Nao sendo propriamente uma

tecnologia ndashmas antes uma especificacao ndashe aqui mencionada por ter servido como

referencia a diversas implementacoes de funcionalidades offline e por se considerar

que venha a ter um impacto significativo nas implementacoes de diversos browsers

Dion Almaer defendeu no seu blogue que o Gears era uma implementacao do

HTML 5 No seu artigo ldquoGears as a bleeding-edge HTML 5 implementationrdquo [Alm08]

o autor diz que ambos ndasho Gears e o HTML 5 ndashpretendem dar a web caracterısticas

25

Estado da arte

semelhantes e nao encontrar motivo de ldquocompeticaordquo entre as duas mas que en-

quanto o HTML 5 e uma especificacao o Gears e uma implementacao

No entanto tambem e verdade que o HTML 5 cobre muitos outros pontos para

alem das OWA que saem completamente fora do ambito do Gears Se esta es-

pecificacao atingir um estado de maturidade que possibilite a sua adopcao pelos

principais browsers tornando nativo do browser o suporte OWA entao deixara de

fazer sentido a existencia de uma extensao como o Gears

A especificacao HTML 5 disponibiliza duas APIs relevantes para o tema das

OWA

1 Uma base de dados baseada em SQL que permite o armazenamento de dados

do lado do cliente

2 Uma ldquocacherdquo HTTP que garante a disponibilidade das aplicacoes mesmo quando

o utilizador nao possui uma ligacao a Internet

Estas caracterısticas sao as bases da tecnologia das OWA e tem correspondencia

com os pontos analisados nas seccoes 311 e 311

35 Web applications que usam funcionalidades offline

Nesta seccao apresentam-se algumas web applications que actualmente disponi-

bilizam funcionalidades offline Estas aplicacoes foram escolhidas para uma analise

mais pormenorizada por utilizarem o Gears que tal como descrito na seccao 4 foi

a tecnologia escolhida para o projecto

351 Google Reader e Google Docs

O Google Reader7 e um leitor de feeds RSS Permite gerir a subscricao de varios

sites simultaneamente que disponibilizem conteudos neste formato e foi a primeira

web application da Google com uma versao offline publicamente acessıvel (desde

Junho de 2007)

O Google Reader implementa o modo ldquoutilizador deciderdquo oferecendo na sua

interface um botao que permite alternar entre os modos online e offline

O Google Docs8 e uma web application que permite a criacao e edicao de doc-

umentos de texto folhas de calculo e apresentacoes Era ja publico desde Janeiro

de 2008 que o Google estava a desenvolver uma versao OWA desta aplicacao mas o

acesso a uma versao experimental so foi possıvel a partir de 31 de Maio de 2008

7Google Reader - httpreadergooglecom8Google Docs - httpdocsgooglecom

26

Estado da arte

A implementacao das funcionalidades offline nestas duas aplicacoes seguiu difer-

entes aproximacoes principalmente porque o Google Reader apresenta ao utilizador

informacoes que sao fornecidas por fontes externas enquanto que no Google Docs

a informacao e criada e editada pelo utilizador sobre a forma de documentos

A diferente origem da informacao implica que no Google Reader seja necessario

prever casos de excepcao tal como existirem demasiados itens que necessitam de

ser transferidos para o cliente Nao observar este ponto causa um problema grave

de usabilidade e para evitar tempos de espera demasiado longos e uma interface

com pouca capacidade de resposta as accoes do utilizador o Google Reader apenas

transfere para o cliente os dois mil itens mais recentes na transicao para o modo

offline

352 Remember the Milk

O Remember The Milk9 e uma web application desenvolvida por uma equipa

Australiana que proporciona funcionalidades de agenda gestao de tempo e de tare-

fas e foi uma das primeiras aplicacoes independentes do Google a adoptar o Gears

para acessos em modo offline Permite que os seus utilizadores facam uma gestao

de tarefas agrupando-as em listas adicionando-lhes campos de informacao adicional

ou dando-lhes informacao geografica (recorrendo ao servico Google Maps10) Entre

a sua lista de funcionalidades encontra-se ainda a possibilidade de importar e ex-

portar eventos no formato iCalendar (ics) etiquetas (tags) em tarefas publicacao

Really Simple Syndication (RSS) e partilha de categorias de tarefas de acordo com

diferentes nıveis de permissoes de acesso definidos pelo utilizador

353 MySpace e WordPresscom

O MySpace uma das maiores social networks na Internet anunciou recente-

mente que vai disponibilizar uma versao do seu cliente de e-mail que utiliza o Gears

para acelerar o seu desempenho Numa fase inicial estara disponıvel apenas para

utilizadores que tenham cinco mil ou mais mensagens na sua caixa de correio e

permitira efectuar pesquisas muito mais rapido que a sua versao online

O servico de blogs Wordpresscom anunciou tambem o inıcio da utilizacao desta

tecnologia com o fim de melhorar o desempenho A versao que utiliza esta tecnologia

descarrega e armazena no cliente um conjunto de imagens e scripts que passam a

ter preferencia sobre os seus congeneres online e que permitem acelerar o processo

de carregamento da aplicacao e visualizacao de blogs

9Remember The Milk ndash httpwwwrememberthemilkcom10Google Maps ndash httpmapsgooglecom

27

Estado da arte

O MySpace e o Wordpresscom sao dois exemplos da utilizacao da tecnologia

OWA para optimizacao de web application ja existentes Sem pretenderem disponi-

bilizar uma versao que seja totalmente offline fazem uso do Gears para armazenar no

cliente parte dos recursos frequentemente acedidos na visualizacao das suas paginas

36 Escolha da tecnologia

Apos a analise das tecnologias apresentada nas seccoes 31 a 34 foi necessario es-

tudar a adequacao de cada uma delas ao projecto em questao Desde logo e possıvel

observar que nem todas se dedicam apenas a OWA Por exemplo o Adobe AIR

apesar de ter suporte para OWA apenas disponibiliza algumas das funcionalidades

identificadas como mais indicadas para a execucao do projecto quando utilizado

na sua vertente desktop tal como exposto na Tabela 31 mas a utilizacao desta

vertente implicaria o desenvolvimento de novas interfaces e de novas formas de co-

municacao (troca de mensagens XML ou JSON) A vertente web do Adobe AIR

foca-se mais especificamente nas Rich Internet Applications e permite a reutilizacao

do codigo ja existente (exigindo naturalmente a sua adaptacao e a implementacao

das funcionalidades pretendidas)

A tecnologia escolhida para a realizacao deste trabalho foi o Gears sendo que

um dos principais factores a influenciar esta opcao foi a liberdade introduzida pela

sua licenca Berkeley Software Distribution (BSD)11

Considerou-se o funcionamento desta ferramenta extremamente adequando a

aplicacao no WOW uma vez que o seu principal objectivo e precisamente tornar

possıvel a execucao offline de uma pagina web e por virtude deste facto o Gears tem

uma API concisa e de simples aplicacao pratica uma vez que nao possui quaisquer

outros elementos distractores O funcionamento do seu ManagedResourceStore ex-

emplificado na Figura 31 com a capacidade de actualizacao de recursos definidos

num ficheiro manifesto especificado em JSON pesou tambem nesta decisao

11Sobre a licenca BSD consultar httpwwwopensourceorglicensesbsd-licensephp e http

wwwlinfoorgbsdlicensehtml

28

Estado da arte

Figura 31 Esquema UML do processo efectuado pelos recursos do Gears do tipoManagedResourceStore para a actualizacao dos conteudos definidos no ficheiro manifesto

29

Estado da arte

Funcionalidade RIAs no browser RIAs no desktop

Disponibilidadeda aplicacao

As aplicacoes podem ser facil-mente exploradas e utilizadas

As aplicacoes quando instal-adas tem maior grau de fun-cionalidades e persistencia

Instalacao Nao e necessario qualquer tipode instalacao

As aplicacoes sao instaladasatraves do browser ou descar-regadas e instaladas comouma aplicacao tradicional

Actualizacoes Aplicacoes sao actualizadascarregando conteudos paraum website

O AIR disponibiliza uma APIque permite que as aplicacoessejam actualizadas de umaforma

Sistemas opera-tivos suportados

As aplicacoes podem ser exe-cutadas em diversos sistemasoperativos e browsers

As aplicacoes sao multi-plataforma e podem serinstaladas e executadas emdiversos sistemas operativos ebrowsers

Linguagens deprogramacao

Javascript e disponibilizadopelo browser e ActionScripte disponibilizado pelo AdobeFlash Player

Maquinas virtuais deJavascript e ActionScriptcompatıveis com o browser

Capacidade deexecucao embackground

As RIAs podem ser execu-tadas numa janela do browser

As aplicacoes podem ser ex-ecutadas em background edisponibilizar notificacoes talcomo uma aplicacao tradi-cional

Persistencia A actividade esta limitada asessao do browser Quando obrowser e encerrado toda ainformacao e descartada

As aplicacoes sao instaladas eestao disponıveis no desktopPodem armazenar informacaolocalmente e estao disponıveisoffline

Integracao com odesktop

Integracao com o desktop lim-itada devido a restricoes im-postas pelo browser

As aplicacoes podem acederao sistema de ficheiro ao clip-board eventos notificacoesetc

Controlo da inter-face com o uti-lizador

As aplicacoes sao acedidasatraves de uma janela dobrowser que tem os seusproprios controlos e visualgrafico

As aplicacoes tem um vi-sual grafico proprio em janelapropria

Armazenamentode dados

As aplicacoes tem armazena-mento limitado que pode serreescrito pelo browser

As aplicacoes tem acesso a to-talidade do espaco disponıvellocalmente e a uma base dedados com a possibilidade deencriptacao

Tabela 31 Comparacao das funcionalidades oferecidas pelo Adobe AIR para as platafor-mas web e desktop

30

Estado da arte

Aplicacao Modo de execucao utilizadoGoogle Reader Utiliza o modo ldquoutilizador deciderdquo disponibilizando

ao utilizador um botao para alternar entre os modosonline e offline Como lida com informacao recol-hida de fontes externas de natureza frequentementeefemera o processo de sincronizacao apenas transfereos dois mil itens mais recentes quando passa ao es-tado offline Neste modo sao ainda guardadas in-formacoes de itens lidos e etiquetas atribuıdas quesao sincronizadas com o servidor quando o utilizadorvoltar a activar estado online

Google Docs Utiliza o modo ldquoaplicacao deciderdquo permitindo que outilizador edite os conteudos de documentos de textofolhas de calculo e de apresentacoes independente-mente do estado da ligacao desde o momento em queas funcionalidades offline sao activadas A aplicacaofaz pequenas sincronizacoes com o servidor sempre quenecessario

Remember the Milk Utiliza um modo hıbrido entre ldquoaplicacao deciderdquo eldquoutilizador deciderdquo A aplicacao encarrega-se da sin-cronizacao de dados mas disponibiliza um controlona sua interface que permite despoletar manualmenteeste processo para situacoes em que o utilizador fez al-teracoes recentes e pretende usufruir das capacidadesoffline imediatamente

MySpace O MySpace anunciou a utilizacao de mecanismos dearmazenamento de dados no cliente com recurso atecnologias OWA para melhorar o desempenho doseu cliente web de correio electronico nomeadamenteno que diz respeito a operacoes de pesquisa e or-denacao Inicialmente esta funcionalidade estara ape-nas disponıvel para utilizadores com cinco mil ou maismensagens na sua caixa de correio mas nao e aindaclaro se sera disponibilizada uma versao totalmenteoffline

Tabela 32 Resumo da utilizacao de tecnologias OWA em algumas web applications con-sideradas na analise do estado da arte

31

Estado da arte

32

Capıtulo 4

Desenvolvimento

Neste capıtulo introduz-se a aplicacao WOW e apresenta-se o estudo que foi

feito da adequacao de cada tecnologia para a implementacao da funcionalidade of-

fline nesta plataforma Fazem-se diversas consideracoes sobre opcoes a tomar na

concepcao de OWAs e problemas comuns na sua implementacao bem como sug-

estoes para os resolver O WOW e uma aplicacao ja existente de gestao de ordens

de trabalho e do fluxo de tarefas numa empresa ou organizacao

41 Como ficar offline

Na maior parte das web applications de hoje nao existe uma camada de dados

real A aplicacao exemplificada na Figura 41 ao longo da sua execucao acede

directamente a sua unica fonte de dados (o servidor) atraves de chamadas Ajax sem

que exista uma separacao clara destas duas camadas

Para que uma web application seja capaz de ser executada sem uma ligacao

activa a Internet e mantenha o seu caracter dinamico torna-se necessario incluir

Figura 41 Exemplo de uma arquitectura de uma web application sem uma camada deabstraccao de dados Figura adaptada de http gears google com

33

Desenvolvimento

Figura 42 Exemplo de uma arquitectura de uma web application com uma camada deabstraccao de dados Figura adaptada de http gears google com

um mecanismo de armazenamento de dados local seja uma base de dados ou a

capacidade de acesso ao disco No entanto este mecanismo introduz dois problemas

1 Qual das fontes de dados utilizar quando um utilizador faz um pedido de

informacao

2 A necessidade de implementar uma camada de acesso a dados que seja coerente

quer se use o servidor remoto ou local

Por exemplo em vez de a aplicacao Ajax fazer um pedido relativo as contas de

todos os utilizadores em formato JSON directamente ao servidor remoto podera ao

inves fazer o pedido a um objecto intermedio da camada de dados Este objecto

demonstrado na Figura 42 sera responsavel por implementar uma interface de

acesso a base de dados e retornar um objecto JavaScript com uma representacao da

resposta do servidor

Mas a existencia de uma segunda fonte de dados torna recomendavel tambem

a implementacao de uma camada de data switching que em funcao da existencia

de conexao a Internet e da necessidade de actualizacao dos dados decide se faz o

pedido ao servidor remoto ou se fornece os dados presentes localmente Este objecto

apresentado na Figura 43 decidira de forma transparente para o utilizador se le ou

escreve os dados localmente ou se os enviapede ao servidor remoto e pode tambem

iniciar o processo de convergencia de dados e de resolucao de conflitos

411 Funcionalidades disponıveis em modo offline

Por razoes praticas e provavel que nem todas as funcionalidades da aplicacao

possam ser disponibilizadas em modo offline E necessario escolher quais as fun-

cionalidades a disponibilizar no modo offline da aplicacao e implementar a logica

que decide quando utilizar a base de dados local ou o servidor remoto Apesar do

acesso a base de dados local ser muito mais rapido do que aceder ao servidor o

acesso local nem sempre e preferido Ha varias razoes que podem tornar necessario

escolher o acesso ao servidor em vez do acesso local

34

Desenvolvimento

Figura 43 Exemplo de uma arquitectura de uma web application com uma camada deabstraccao de dados e um data switch Figura adaptada de http gears google com

1 A informacao pode ter uma natureza efemera e nao fazer sentido guarda-la

localmente Exemplo dados em tempo real da bolsa de valores de Lisboa

2 Algumas aplicacoes lidam com informacao que so faz sentido na presenca de

uma ligacao Exemplo Instant Messaging

3 A aplicacao podera escolher apenas guardar a informacao acedida mais fre-

quentemente Exemplo para o utilizador poder alterar a lıngua de apre-

sentacao da aplicacao os conteudos terao que ser guardados em todas as

lınguas disponibilizadas pela aplicacao O custo de implementacao de algu-

mas funcionalidades pode nao compensar o benefıcio

4 A capacidade de processamento ou de armazenamento de dados pode inviabi-

lizar algumas funcionalidades offline Exemplo se uma dada funcionalidade

necessita de uma capacidade de armazenamento de dados para alem do razoavel

de um computador pessoal para ser util (visualizador de mapas)

42 Modos de execucao

Um aspecto que e necessario estudar para qualquer web application que se deseje

disponibilizar offline prende-se com tres modos de execucao que devem ser consid-

erados

1 Utilizador decide o modo de execucao A aplicacao tem modos distintos

de execucao para os estados online e offline geralmente indicados na interface

com o utilizador O utilizador e informado do estado da ligacao e participa na

alteracao de estado de execucao da aplicacao interagindo com a sua interface

2 Aplicacao decide o modo de execucao Pode ser implementado na propria

aplicacao um mecanismo de deteccao do estado da ligacao (por exemplo atraves

35

Desenvolvimento

de chamadas Ajax periodicas) transitando de estado e sincronizando automati-

camente Desta forma o utilizador nao precisa de participar na alteracao de

estado a menos que exista um conflito de dados que requeira a sua atencao

3 Aplicacao assume sempre o estado offline Outra hipotese sera imple-

mentar uma web application que assume sempre estar na ausencia de uma

ligacao ao servidor de dados Esta aplicacao responde aos pedidos do uti-

lizador efectuando pedidos de informacao ao servidor mas nao dependendo

de uma resposta valida para mostrar a informacao que ja tinha disponıvel an-

teriormente A sincronizacao de dados com o servidor e tentada sempre que

existam dados para submeter e uma accao do utilizador

421 Modo ldquoutilizador deciderdquo

Neste modo de execucao quando a aplicacao esta online comunica com o servidor

remoto quando esta offline comunica com a base de dados local A informacao tem

que ser sincronizada sempre que se muda de modo A principal vantagem desta opcao

e que e a mais simples de implementar mesmo para uma aplicacao ja existente e

portanto uma forma expedita de disponibilizar uma OWA No entanto tem tambem

algumas desvantagens que devem ser consideradas

1 O utilizador tem que se lembrar de fazer a alteracao de estado de execucao

Caso contrario podera estar a trabalhar inadvertidamente numa versao offline

com dados antigos ou nao ter a informacao necessaria se perder subitamente

a ligacao

2 Se a ligacao for intermitente o utilizador tera ou que escolher um dos modos

de execucao ou estar constantemente a trocar

3 Uma vez que a base de dados nao esta sempre actualizada nao podera ser

utilizada para melhorar a rapidez de execucao da aplicacao quando em modo

online

422 Modo aplicacao decide

A deteccao do estado da ligacao pode ser implementada atraves de um pedido

assıncrono ao servidor tal como ilustrado na Figura 44 O resultado deste pedido

definira o estado online (em caso de sucesso) ou offline (em caso de falha) A

sincronizacao de dados podera ser feita sempre que ocorra uma transicao do es-

tado offline para o estado online No entanto este metodo nao se revela eficiente

36

Desenvolvimento

Figura 44 Esquema grafico ilustrando uma OWA executando no browser utilizando ummodo de execucao do tipo ldquoaplicacao deciderdquo com deteccao automatica do estado daligacao via pedidos Ajax assıncronos a cada cinco segundos

para grandes aplicacoes uma vez que requer a troca de mensagens demasiado fre-

quentes com o servidor que se destinam exclusivamente a monitorizacao do estado

da ligacao

423 Modo ldquoaplicacao assume o estado offlinerdquo

Uma aplicacao transparente funciona assumindo sempre que esta em modo of-

fline ou pelo menos que pode perder a ligacao a qualquer momento Neste modo

tira-se o maximo partido do armazenamento local e fazem-se pequenas mas contınuas

sincronizacoes com o servidor sempre que este esteja disponıvel A sincronizacao de

dados tambem e feita sempre que se volta ao estado online

As vantagens de uma web application transparente sao as seguintes

bull Uma melhor experiencia para o utilizador uma vez que este nao tem que se

preocupar com o estado da ligacao ou com a transicao de estados

bull A aplicacao funciona de forma coerente mesmo que a ligacao seja intermitente

bull Uma vez que o armazenamento local e mantido actualizado pode ser utilizado

para melhorar o desempenho da aplicacao

Foram identificadas as seguintes desvantagens

bull E mais difıcil de implementar e a sincronizacao acarreta cuidados especiais

bull E necessario um cuidado adicional para evitar que as operacoes de sincronizacao

frequentes que ocorrem automaticamente nao afectem os tempos de resposta

da aplicacao

bull Os testes a aplicacao sao mais complexos uma vez que a sincronizacao de dados

nao ocorre em resposta a uma accao do utilizador

37

Desenvolvimento

43 Sincronizacao de dados

A sincronizacao de dados consiste na capacidade de identificar e transferir pe-

riodicamente a versao mais actual dos dados entre o cliente e o(s) servidor(es)

Independentemente do modo de execucao escolhido e mesmo do estado da ligacao

do utilizador a informacao armazenada localmente e a informacao armazenada no

servidor estarao por vezes dessincronizadas Isto podera acontecer sempre que por

exemplo

bull O utilizador faz alteracoes em modo offline

bull A informacao e partilhada e pode ser alterada por uma entidade externa

bull A informacao e fornecida por uma entidade externa

Resolver estas diferencas de forma a que a informacao local e remota encontrem

a igualdade chama-se sincronizacao de dados Ha varias aproximacoes possıveis

para este efeito que dependem da natureza da aplicacao cada uma com vantagens

e desvantagens

A capacidade de suportar a mobilidade dos utilizadores torna-se cada vez um

ponto mais importante de uma web application Para uma organizacao de dimensao

global e vital garantir que os seus colaboradores tem acesso a mesma informacao

que tem disponıvel nos seus postos de trabalho mesmo quando estao fora Na maior

parte dos casos estes colaboradores terao acesso a um computador portatil um

desktop Smartphone ou PDA e atraves destes poderao ter acesso a sua informacao

directamente atraves de ligacoes encriptadas Virtual Private Network (VPN) de um

servidor web ou de outro mecanismo de rede

Esta solucao e simples de implementar mas infelizmente para a maioria dos

colaboradores com grande factor de mobilidade nao e satisfatoria As principais

desvantagens sao as seguintes

bull Requisitos de ligacao Para permitir que os utilizadores acedam a sua in-

formacao e necessario garantir a capacidade constante de comunicacao pelo

menos durante o tempo necessario que assegure a sua transferencia

bull Velocidade de ligacao sem persistencia de dados e em ligacoes de fraca

qualidade a usabilidade por vezes torna-se inaceitavel

bull Ponto crıtico de falha Com este tipo de solucao todos os utilizadores de-

pendem da base de dados que armazena informacao vital para o funcionamento

do cliente

38

Desenvolvimento

bull Scalability do servidor A medida que novos utilizadores sao adicionados ao

sistema o desempenho do servidor e afectado levando a necessidade de maior

capacidade de armazenamento eou processamento

De acordo com a documentacao da Microsoft Sync Framework [Mic08] uma

solucao alternativa consiste em implementar uma Occasionally Connected Appli-

cation (OCA) Uma OCA permite a um utilizador remoto continuar a aceder a

sua informacao mesmo depois de perder a ligacao mas em vez de recorrer a um

servidor recorre a informacao armazenada no seu dispositivo local Para preencher

localmente a informacao que o utilizador necessita uma OCA possui mecanismos

de sincronizacao de dados que sao oferecidos por esta framework

431 Quando sincronizar

Uma das solucoes mais simples de implementar passa por disponibilizar um

mecanismo manual que despoleta a sincronizacao Diz-se manual porque e o uti-

lizador que escolhe quando sincronizar e pode ser implementada simplesmente

fazendo o upload de toda a informacao para o servidor e depois fazendo o download

da copia mais recente da informacao antes de voltar a ficar offline Para que esta

seja uma opcao viavel e necessario que

bull O volume de dados seja suficientemente pequeno para que possa ser transferido

do servidor para o cliente num espaco de tempo aceitavel

bull Que o utilizador indique explicitamente que quer mudar para o estado offline

ou online pressionando um botao da interface

Contudo podem ser identificados alguns problemas relacionados com esta abor-

dagem

bull Os utilizadores nem sempre podem prever o estado das suas ligacoes A ligacao

pode-se perder subitamente ou ter um caracter intermitente

bull O utilizador pode esquecer-se de efectuar a sincronizacao

Outra opcao sera conjugar a sincronizacao de dados com o modo de execucao

transparente A sincronizacao ocorre automaticamente em background de forma

nao intrusiva para o utilizador A aplicacao comunica com o servidor regularmente

efectuando pequenas trocas de dados com o objectivo de manter o sincronismo da

informacao local e remota Esta abordagem pode ser implementada com pedidos

Ajax assıncronos e regulares ao servidor o que permite manter a interaccao com a

interface fluıda evitando bloqueios Estes pedidos sao feitos prevendo as situacoes

39

Desenvolvimento

de disponibilidade ou indisponibilidade (timeout) do servidor Uma outra opcao

sera permitir que o servidor comunique essas alteracoes utilizando Comet1 tal como

descrito em [Wil06] e [Rus06] As vantagens destas aproximacoes sao

bull A informacao esta disponıvel a qualquer altura que o utilizador decida ficar

offline ou que a ligacao seja acidentalmente perdida

bull O desempenho da aplicacao pode ser melhorado quando se estiver a utilizar

uma ligacao a Internet lenta uma vez que o acesso a dados locais e mais

eficiente do que a consulta de dados ao servidor

44 WOW

O WOW e uma plataforma integrada de gestao de ordens de trabalho ja ex-

istente e desenvolvida pela Critical Software SA a qual se pretende adicionar a

capacidade de execucao offline Esta aplicacao e extremamente dinamica e con-

figuravel com um conjunto extremamente rico de funcionalidades das quais se

destacam

bull Gestao de Ordens de Trabalho ndash suportando a gestao dos pedidos desde a

sua criacao ate ao seu fecho tomando em conta os diferentes tipos de pedidos

(ordens de trabalho pedidos de informacao melhorias resolucao de problemas

etc) e diferentes tipos de accoes possıveis para cada um (Figura 45)

bull Monitorizacao de alteracoes ndash Historico de mudancas anexos e estados criando

relatorios de alteracao automaticamente (o que por quem e quando)

bull Uso de Service Level Agreements (SLAs) ndash E possıvel associar a um pedido um

SLA que define qual o perıodo de tempo atribuıdo a resolucao de um pedido

controlando e agilizando a resolucao do mesmo

bull Utilizacao de queries de utilizador configuraveis que permitem acesso rapido

a determinadas ordens de trabalho de acordo com o filtro configurado (por

exemplo ldquoPara mimrdquo ldquoPara o Grupordquo ldquoPelo Grupordquo)

bull Gestao do relacionamento entre pedidos

bull Pesquisa e filtragem de ordens de trabalho

bull Exportacao de dados em formatos padrao (PDF DOC ou XLS)

bull Integravel com solucoes externas

40

Desenvolvimento

Figura 45 Detalhe de um conjunto possıvel de estados e respectivas transicoes para umadada ordem de trabalho no WOW desde a sua submissao no sistema ate a sua conclusaoem fecho ou cancelamento Esta figura representa apenas um exemplo ja que o mapa deestados para uma ordem de trabalho e dinamico e pode ser alterado por um administradorFigura retirada de uma brochura promocional do WOW Critical Software SA

A utilizacao de uma ferramenta deste tipo por parte de uma empresa ou orga-

nizacao oferece vantagens quer a gestao de topo quer aos colaboradores individuais

para os colaboradores individuais o WOW e uma aplicacao onde estao registadas

todas as tarefas contribuindo activamente para o desenvolvimento em ambientes

multi-tarefa e para a organizacao pessoal das tarefas de acordo com prioridades

Para a gestao de topo esta ferramenta permite obter uma visao global do estado da

organizacao em termos de tempo gasto por tarefa executada sendo uma mais valia

para a previsao e gestaoalocacao de recursos

45 Visao geral sobre a arquitectura do WOW

O WOW e interessante nao so do ponto de vista de produto como tambem do

ponto de vista de plataforma Existem diversos plug-ins que estendem as funcional-

idades do WOW e existem ate projectos que pretendem usar a arquitectura do

WOW para criar produtos com fins diferentes do inicial (por exemplo o WOW-

Storm ndash um sistema de registo e classificacao social de ideias)

De modo a conseguir ter essa expansibilidade a plataforma WOW assenta sob

uma arquitectura distribuıda modular e expansıvel com uma componente central

ndash o core ndash estruturado em camadas logicas E no core que se situam todas as

1O Comet e um conceito semelhante ao Ajax introduzido por Alex Russel mas no qual e o servidor quetoma a iniciativa de ldquoenviarrdquo os dados ao browser sem que este tenha que efectuar um pedido Tambem econhecido por Ajax Push Reverse Ajax ou HTTP Streaming

41

Desenvolvimento

funcionalidades base da aplicacao quer a nıvel logico funcional e de apresentacao

quer a nıvel de gestao e configuracao

E possıvel a execucao de varias instancias do core simultaneamente em servidores

distintos o que permite a alta escalabilidade e disponibilidade desta aplicacao A

consistencia dos dados fica sempre garantida atraves da partilha da base de dados

e pelo balanceamento dos pedidos uma vez que cada um e encaminhado para uma

unica instancia

O WOW apresenta tambem a vantagem de ser uma plataforma extensıvel E

possıvel adicionar novas caracterısticas a plataforma atraves de componentes que se

podem ser divididos em duas categorias plugins e connectors

Os plugins sao componentes que se encontram no mesmo no fısico que a aplicacao

partilhando do mesmo contexto de execucao do core Sao assim uma forma mais

directa de obter informacao da plataforma visto que nao possuem restricoes de

acesso aos dados nem dependencias externas A arquitectura deste componente tera

assim que permitir varias execucoes instanciadas cada uma associada a um core

Por outro lado os connectors sao componentes que se encontram distribuıdos

comunicando externamente com o core Quer a sua execucao quer a obtencao

dos dados estao assim dependentes de interfaces de comunicacao externas que a

plataforma disponibiliza Estes componentes ao contrario dos plugins sao instan-

ciados unicamente e recorrem ao protocolo de comunicacao Java Messaging Service

(JMS) para comunicar com o core

46 WOW Offline

Para alem das opcoes tomadas relativamente a tecnologia a utilizar surgiu

tambem a necessidade de optar por um dos modos de execucao apresentados na

seccao 42

Das tres opcoes possıveis foi o modo ldquoaplicacao assume o estado offlinerdquo descrito

na seccao 423 que mereceu a maior atencao uma vez que reune as vantagens de

uma experiencia mais positiva para o utilizador (uma vez que este nao tem que

participar activamente na alteracao do modo execucao como descrito na seccao 421)

e nao constitui uma sobrecarga excessiva para servidor (como o modo abordado na

seccao 422)

No entanto esta opcao comprometia a complexidade da implementacao para alem

dos objectivos propostos para este projecto e para cumprir o prazo dado foi tomada

a decisao de implementar o modo ldquoutilizador deciderdquo especificando apenas de forma

teorica o modo ldquoaplicacao assume o estado offlinerdquo

As caracterısticas do Gears foram ja descritas na seccao 31 Na Figura 47

mostra-se a sua forma de funcionamento quando integrado numa web application

42

Desenvolvimento

Nesta figura representa-se o modulo LocalServer do Gears como um ponto de de-

cisao Aqui sao testadas as condicoes que determinam se o pedido sera interceptado e

servido localmente ou se prossegue para uma maquina remota E tambem represen-

tada uma base de dados que corresponde ao modulo Database mas que podera nao

ser utilizada Este modulo tal como o modulo Workerpool tem caracter opcional

e sao utilizados consoante os requisitos da aplicacao

A plataforma WOW lida com mais dados do que e necessario passar para o

lado do cliente Em conformidade com o ja exposto na seccao 411 volta-se a

frisar que nao se pretende recriar toda a logica de negocio nem os conteudos da

base de dados no cliente pela sua complexidade e volume de dados Pretende-se

pelo contrario permitir que os utilizadores tirem partido da capacidade de poder

consultar as suas ordens de trabalho quando nao dispoe de uma ligacao transferindo

apenas o essencial para isto seja possıvel

A pagina inicial do WOW apresenta um resumo das ordens de trabalho abertas

ndash enviadas e recebidas ndash que se pretende permitir visualizar offline (ver Figura 46)

Como prova de conceito foi efectuada uma abordagem pragmatica das varias possi-

bilidades descritas na seccao 42

461 Modo ldquoaplicacao deciderdquo com deteccao automatica da ligacao

A primeira abordagem estudada para a disponibilizacao das funcionalidades of-

fline foi o modo ldquoaplicacao deciderdquo com deteccao automatica de ligacao apresentado

na seccao 422 Para que isto seja possıvel foi implementado um mecanismo de ver-

ificacao periodica do estado da ligacao atraves de chamadas Ajax assıncronas O

resultado destes pedidos determina o estado da aplicacao executando as tarefas de

sincronizacao de dados sempre que pertinente Este metodo embora imediato e

simples de implementar depressa se revelou inadequado para o projecto devido ao

elevado consumo de recursos do servidor que a utilizacao intensiva faz esperar a

comunidade da plataforma WOW no principal cliente excede os 7000 utilizadores

Foi estimado que para uma utilizacao de fluidez aceitavel o estado da ligacao deveria

ser testado a cada cinco segundos Assumindo uma adesao (previsao pessimista) de

1 aos servicos offline assistir-se-ia a cerca de 840 pedidos adicionais por minuto

Mas o principal problema desta aproximacao prende-se com o facto de a ver-

ificacao ser feita em intervalos de tempo discretos levando a possibilidade de a

aplicacao poder ter em dado momento uma representacao errada do seu estado

real da ligacao Este problema e ilustrado na Figura 48 onde se ve claramente a

discrepancia entre o estado real da ligacao e a representacao interna que esta tem

Note-se que nesta janela de tempo qualquer accao do utilizador que exija uma

resposta sıncrona do utilizador leva-lo-a para um ldquobeco sem saıdardquo onde nao tera

43

Desenvolvimento

Figura 46 A pagina inicial do WOW apresenta um resumo das ultimas ordens de trabalhoenviadas e recebidas Na imagem pode-se observar a transicao do estado online para offline

acesso a versao offline porque a aplicacao nao fez a transicao automatica nem acesso

a versao online porque na verdade nao possui uma ligacao O que acontecera nesta

situacao sera uma tentativa de acesso ao servidor por parte da aplicacao numa

altura em que este se encontra indisponıvel e o resultado sera uma mensagem de

ldquopedido excedeu o tempordquo apresentado pelo browser Este e um estado sem retorno

porque apos o browser apresentar esta mensagem todos os recursos JavaScript ficam

indisponıveis tornando impossıvel o regresso ao estado anterior ou o tratamento do

erro de qualquer outra forma No entanto as chamadas Ajax podem ser tratadas de

forma especial para a eventualidade de falha e portanto nao constituem problema

44

Desenvolvimento

Figura 47 Ilustracao do funcionamento do Gears numa web application que utiliza ummotor Ajax Os pedidos HTTP ou HTTPS podem ser interceptados e tratados localmenteou podem ser feitos a uma maquina remota consoante se verificarem ou nao as condicoesexpressas no ponto 311 E representado um acesso a uma base de dados local (fornecidapelo Gears) mas a sua utilizacao e opcional

462 Implementacao do modo ldquoutilizador deciderdquo

Este modo de execucao foi ja descrito na seccao 421 e a sua principal carac-

terıstica e ser o utilizador a decidir se a aplicacao deve utilizar um servidor remoto

ou a maquina local como fornecedor de dados

Relativamente ao WOW o WOW Offline na vertente ldquoutilizador deciderdquo vem

alterar os seus casos de uso dando ao utilizador a possibilidade de alterar o estado

de execucao da aplicacao (entre online e offline) Resta dizer que no modo online se

mantem todas as funcionalidades anteriores e que no modo offline torna-se possıvel

visualizar os conteudos da pagina principal do WOW (Figura 46) e os detalhes das

ordens de trabalho (Figura 49) tal como expressa a Figura 410

Esta aproximacao foi utilizada na prova de conceito do WOW adicionando um

controlo a interface desta aplicacao que permite ao utilizador alternar entre os esta-

dos online e offline Na transicao de online para offline sao descarregados os recursos

necessarios para a execucao desta aplicacao sem recorrer a Internet Para o fazer

45

Desenvolvimento

Figura 48 Neste exemplo do modo ldquoaplicacao deciderdquo o teste da ligacao e feito e feito acada cinco segundos O resultado deste teste nao reflecte sempre o estado real da aplicacaopodendo levar a aplicacao a ter comportamentos indesejaveis Na figura assinala-se umperıodo de tempo no qual a representacao interna do estado da ligacao nao corresponde arealidade

e utilizado um recurso ResourceStore e um ManagedResourceStore (introduzidos

em 311) O primeiro e utilizado para armazenar a pagina principal do WOW ndash do-

ravante designada por homejsp ndash e o segundo e utilizado para armazenar imagens

folhas de estilo CSS e scripts JavaScript

Para a implementacao deste modo de execucao foram identificadas as seguintes

tarefas

1 Guardar informacao que permita a recriacao das paginas que se pretende

disponibilizar offline (utilizando o Gears)

2 Disponibilizar um controlo que permita alterar o estado de execucao atraves

da interaccao com a pagina principal

3 Durante a sincronizacao de dados apresentar o progresso da transferencia de

dados

O primeiro passo consistiu na identificacao de todos os conteudos que sao necessarios

transferir para a execucao offline Foi utilizado um recurso do Gears do tipo

ManagedResourceStore que recorre a um ficheiro manifesto para identificar to-

dos os ficheiros que deve transferir Este recurso e gerido automaticamente pelo

Gears transferindo para o cliente a versao mais recente sempre que e necessario

isto e sempre que exista um ficheiro manifesto com uma identificacao de versao que

seja diferente da actualmente disponıvel no cliente Uma vez identificados todos

ficheiros necessarios para a execucao offline num (ou mais) ficheiros manifesto o

Gears encarrega-se da sua actualizacao mas o preenchimento destes ficheiros man-

ifesto e manual o que se traduz num cuidado extra na manutencao da aplicacao

A forma como esta informacao e guardada deve tambem ser cuidadosamente

estudada A opcao mais flexıvel passa por utilizar o modulo Database apresentado

na seccao 311 e guardar a informacao de uma forma relacional Para a recriacao

das paginas pode ser disponibilizada uma versao HTML da pagina que funciona

46

Desenvolvimento

Figura 49 Pagina de visualizacao do detalhe de uma ordem de trabalho

como template nao possui quaisquer dados e e utilizada apenas em modo offline E

preenchida para cada pedido retirando os dados relevantes da base de dados

O modelo de dados do WOW torna esta opcao extremamente trabalhosa uma

vez que as entidades envolvidas na geracao de cada pagina de informacao sobre

cada ordem de trabalho tem relacoes de dependencia complexas seguindo padroes

muito variaveis Por exemplo em cada ordem de trabalho existe um formulario que

permite a sua progressao de estado com diversos campos opcionais e obrigatorios

este formulario e definido pelo administrador e esta relacionado nao apenas com o

tipo de ordem de trabalho mas tambem com o estado actual em que esta se encontra

e a accao que se pretende realizar O elevado numero de combinacoes de tipos de

ordem de trabalho estados e accoes que existem num dado momento juntamente

com a sua possibilidade de alteracao obrigariam a implementacao de uma logica de

negocio complexa o que esta fora do ambito deste projecto

47

Desenvolvimento

Figura 410 Esquema UML que expressa os casos de uso do WOW Offline no modoldquoutilizador deciderdquo

463 Especificacao do modo ldquoaplicacao assume o estado offlinerdquo

A aproximacao para o modo ldquoaplicacao assume o estado offlinerdquo foi tambem

dividida em varias tarefas

1 Guardar informacao que permita a recriacao da pagina principal do lado do

cliente no estado offline (utilizando o Gears)

2 Dotar a aplicacao do cliente de um mecanismo de deteccao da ligacao

3 Identificar os ldquomomentos chaverdquo em que devera ocorrer sincronizacao de dados

4 Implementar a sincronizacao de dados

A sincronizacao de dados deve ser feita em ambas as transicoes online-offline e

offline-online quer para transferir novos dados do servidor (os pedidos podem ser

alterados por outros utilizadores) quando se transita do estado quer para comunicar

eventuais alteracoes feitas em modo offline

Relativamente ao WOW o WOW Offline na vertente ldquoaplicacao assume o es-

tado offlinerdquo vem alterar os seus casos de uso dando ao utilizador a possibilidade

de activar esta funcionalidade A partir do momento que a funcionalidade esta ac-

tivada o utilizador deve tambem ter a possibilidade de gerir algumas preferencias

relacionadas com privacidade de dados Devera ter a hipotese de desactivar o ar-

mazenamento local e de remover todos os dados ja armazenados tal como descrito

na Figura 411

48

Desenvolvimento

Figura 411 Esquema UML que expressa os casos de uso do WOW Offline no modoldquoutilizador deciderdquo

A primeira vez que o WOW Offline e acedido por um cliente e caso seja detec-

tada a presenca do Gears todos os recursos necessarios a sua execucao sao trans-

feridos Todos os acessos posteriores serao feitos a estes recursos locais (recorda-se

que o Gears pode ser utilizado para os manter actualizados recorrendo ao Managed-

ResourceStore 311)

Atraves do JavaScript e possıvel interceptar os eventos de load e unload da

pagina que sao despoletados sempre que ocorre um re-acesso da mesma (incluindo

a accao refresh comum dos browsers) sempre que esta e abandonada ou ainda ou

ainda se a janela for encerrada

Tal como sugerido na seccao 462 a camada de interface desta aplicacao (cada

pagina individual em HTML) devera ser implementada como sendo um template

para apresentacao de dados sendo totalmente preenchida atraves de funcoes em

JavaScript O objectivo deste ponto e criar um padrao de dados que permita ao

JavaScript preencher os dados em cada pagina (template) independentemente de

qual seja a fonte ndash o servidor remoto ou a maquina local tal como exemplificado

no diagrama da Figura 412 Na figura a aplicacao recorre ao servidor remoto para

obter os dados pretendidos quando se encontra na presenca de uma ligacao mas

para dados que exijam uma carga de processamento pelo servidor este acto pode ser

49

Desenvolvimento

Figura 412 Esquema UML que expressa o acto de recolha de dados em modo online eoffline recorrendo ao servidor (modo online) e ao sistema de armazenamento de dadoslocal fornecido pelo Gears (modo offline)

substituıdo pelo envio de um campo de controlo que se destina a aferir se os dados

locais se encontram actualizados No caso de estarem actualizados a comunicacao

com o servidor pode ser substituıda por uma query a base de dados local

50

Capıtulo 5

Resultados e Futuros

Desenvolvimentos

Todo o estudo feito sobre o tema OWA foi ja abordado ao longo do documento

Neste capıtulo apresentam-se os resultados obtidos na implementacao da prova de

conceito que visava compreender a melhor forma de disponibilizar uma versao of-

fline no WOW uma plataforma de gestao de ordens de trabalho ja existente de-

senvolvida pela Critical Software SA

51 Resultados Obtidos

Os resultados obtidos neste projecto sao extremamente satisfatorios uma vez

que o estudo do tema OWA e a implementacao de uma prova de conceito que o

ilustrasse foi conseguido com sucesso

A funcionalidade offline foi adicionada ao produto WOW da Critical Software

SA permitindo a visualizacao de ordens de trabalho e dos seus detalhes mesmo na

ausencia de uma conexao activa a Internet Embora para a solucao implementada

tenha sido utilizada uma abordagem do tipo ldquoutilizador deciderdquo pretende-se que esta

seja convertida para ldquoaplicacao deciderdquo ou mesmo para uma aproximacao hıbrida

semelhante a utilizada pelas aplicacoes estudadas nas seccoes 351 e 352

Para a sua implementacao descrita no capıtulo 4 foram tomadas decisoes de or-

dem pratica que permitissem tornar o trabalho exequıvel nos prazos dados Tentou-

se sempre que estas decisoes afectassem o mınimo em termos de desempenho e de

experiencia para o utilizador Considera-se que a implementacao do modo offline

com uma transicao entre modos do tipo ldquoutilizador deciderdquo (ver seccao 42) reflecte

o compromisso entre o desempenho pretendido e os recursos disponıveis e para alem

51

Resultados e Futuros Desenvolvimentos

de ser um exemplo eficaz das possibilidades que as OWA podem trazer a aplicacao

WOW desenvolvida pela Critical Software e tambem um estudo que pode ser uti-

lizado para analisar a implementacao desta tecnologia noutros produtos da mesma

empresa

Note-se que o principal objectivo do trabalho era ganhar familiaridade com este

tema entender as suas vantagens e desvantagens e compreender as suas limitacoes

Tudo indica que existam varias possibilidades de implementacao deste paradigma

noutros produtos da Critical Software que pela sua natureza podem tambem tirar

partido da execucao offline

52 Trabalho Futuro

O desenvolvimento do conceito e formas de implementacao de OWA continua

em forte desenvolvimento no entanto a sua adopcao ainda nao e generalizada A

dificuldade da sua implementacao em web applications ja existentes e o principal

obstaculo a sua maior divulgacao

Ha tambem um factor que deve ser tido em consideracao a manutencao de

codigo A implementacao de uma versao offline de uma web application requer

a implementacao das mesmas regras de negocio (ou de uma versao simplificada)

utilizadas no servidor Para que isto seja possıvel e necessario ter em conta a

capacidade de processamento do cliente e o factor de duplicacao de codigo que

tornara a aplicacao mais difıcil de manter uma vez que uma alteracao a logica de

negocio do servidor implica tambem uma alteracao a sua versao offline

A prova de conceito implementada permite ja a visualizacao offline dos pedidos

abertos (enviados e recebidos) que constam na pagina principal (este numero e

fixo e pode ser alterado pelo administrador) Uma funcionalidade desejavel seria a

possibilidade de interaccao com a aplicacao em modo offline e sincronizacao com o

servidor quando existisse uma ligacao disponıvel

Foi estudada a utilizacao do modo de execucao ldquoaplicacao assume o estado of-

flinerdquo descrito em 423 e esta seria a forma desejavel para o WOW Offline no

entanto para que esta opcao seja viavel sera necessaria a implementacao de uma

forma eficiente de sincronizacao e armazenamento de dados de uma forma relacional

Para atingir este objectivo podera ser seguida uma polıtica de automacao do pro-

cesso no qual a versao online da aplicacao gera scripts de criacao para as tabelas

necessarias na base de dados da versao offline (nao existe nenhuma ferramenta para

o fazer portanto seria necessaria a sua implementacao) e no qual as paginas HTML

disponibilizadas pelo servidor aos clientes web (browser) servem como templates de

apresentacao de informacao e sao preenchidas de forma semelhante pelo servidor ndash

quando a aplicacao estiver online ndash ou pelo cliente atraves de funcoes em JavaScript

52

Resultados e Futuros Desenvolvimentos

ndash quando a aplicacao estiver offline No entanto no WOW devido a quantidade de

informacao tratada e devido as complexas relacoes entre as diferentes entidades e

de esperar que a complexidade da implementacao de um mecanismo deste tipo torne

esta aproximacao demasiado custosa

O HTML 5 embora um forte candidato ainda nao esta suficientemente desen-

volvido A sua especificacao ainda tem o caracter de Draft (rascunho) e esta sujeita

a modificacoes e a aceitacao e implementacao por parte dos browsers e portanto

de momento foi desconsiderado No entanto no futuro se esta especificacao atingir

um estado de maturidade que permita a sua adopcao devera ser considerada como

um possıvel caminho a seguir

53

Resultados e Futuros Desenvolvimentos

54

Capıtulo 6

Conclusoes

Neste capıtulo sao apresentadas as conclusoes do projecto e consideracoes finais

relativamente a tecnologia estudada

61 Conclusoes

O rapido desenvolvimento tecnologico faz prever que a disponibilidade de ligacao

a Internet seja cada vez mais facil e mais rapido mas vao continuar a existir lugares

onde o acesso e limitado e onde as OWA podem desempenhar um papel de relevo

Por outro lado esta tecnologia pode tambem ser utilizada para melhorar o desem-

penho de paginas web com uma necessidade elevada de imagens ou outros recursos

dispendiosos em termos de espaco e foram ate estudados dois exemplos da utilizacao

desta vertente desta tecnologia em 353

Acredita-se que as OWAs vem responder a uma necessidade real por parte das

web applications actuais e que a evolucao que representam se compara a que se

assistiu dos thin-clients para os fat-clients em termos de autonomia do servidor

A capacidade de oferecer conteudos dinamicos no browser independentemente da

existencia de uma ligacao reune as vantagens tıpicas das web applications como

ausencia de instalacao e actualizacoes instantaneas com as vantagens das aplicacoes

de desktop em capacidade de processamento e armazenamento de dados na maquina

local

As tecnologias disponıveis ate a data estudadas no ambito deste projecto que

permitem o desenvolvimento de OWAs e que apresentam maior maturidade sao o

Gears e o Adobe AIR Ambas se apresentam sobre a forma de plugins que necessitam

de uma instalacao extra para poderem ser utilizadas Apesar de esta instalacao ser

55

Conclusoes

apenas necessaria uma vez podera constituir um factor de desencorajamento a sua

adopcao

O HTML 5 uma especificacao abordada neste documento na seccao 34 podera

ser uma alternativa que oferece funcionalidades offline a uma web application sem a

necessidade de qualquer instalacao no entanto esta especificacao ainda nao foi aceite

pelos principais browsers ndash o documento que define o HTML 5 ainda tem o estatuto

de Draft ndash e ainda nao e possıvel antecipar quando e que isto podera acontecer

Um dos problemas que surge frequentemente na implementacao de uma versao

offline para uma web application e a necessidade de sincronizacao de dados Quando

a informacao pode ser alterada por varios utilizadores simultaneamente e necessario

prever os conflitos que daı podem surgir e dotar a aplicacao de uma forma de os

resolver ou alertar o utilizador para a necessidade de alteracao dos dados

Em conclusao todos os objectivos propostos para este projecto foram atingidos

A prova de conceito implementada reflecte de forma clara as possibilidades oferecidas

pela tecnologia OWA e sera utilizado no futuro para compreender a melhor forma

de o implementar de forma definitiva no WOW

56

Referencias

[Ada08] Lucas Adamski Introducing Adobe AIR security model Fevereiro de2008 Disponıvel em httpwwwadobecomdevnetairarticles

introduction_to_air_securityhtml acedido em Marco de 2008

[Ado08] Adobe Adobe AIR 10 Security White Paper 2008 Disponıvel emhttpdownloadmacromediacompubairdocumentation1air_

securitypdf acedido em Marco de 2008

[Alm08] Dion Almaer Gears as a bleeding-edge html 5 implementa-tion March 2008 Disponıvel em httpalmaercomblog

gears-as-a-bleeding-edge-html-5-implementation acedido emMarco de 2008

[BL96] Tim Berners-Lee The world wide web Past present and future Agostode 1996 Disponıvel em httpwwww3orgPeopleBerners-Lee

1996ppfhtml acedido em Abril de 2008

[CDGH08] Mike Chambers Daniel Dura Dragos Georgita and Kevin Hoyt AdobeAIR for JavaScript Developers OrsquoReilly Media 2008 Disponıvel emhttponairadobecomfilesAIRforJSDevPocketGuidepdf ace-dido em Abril de 2008

[Con99] Jim Conallen Modeling Web Application Architectures with UML Junho1999 Disponıvel em httpwwwumlorgcnUMLApplicationpdf

webappspdf acedido em Maio de 2008

[Ent07] Entrust What is a public key information 2007 Disponıvel em http

wwwentrustcompkihtm acedido em Junho de 2008

[Gar05] Jesse James Garret Ajax A new approach to web applicationsFebruary 2005 Disponıvel em httpwwwadaptivepathcomideas

essaysarchives000385php acedido em Marco de 2008

[Greon] Philip Greenspun Philip and Alexrsquos Guide to Web Publishing 2003(last revision) Disponıvel em httpphilipgreenspuncompandaacedido em Junho de 2008

[Gro02a] App Design Group Thick vs thin client comparison 2002 Disponıvelem httpwwwdonjacobsvwcomimagesweekendspecials

Thick-vs-Thinpdf acedido em Junho de 2008

57

REFERENCIAS

[Gro02b] Technical Research Group Thin Client Tecnhology - WhitePaper 2002 Disponıvel em httpwwwpicktrgcompubs

thinclientwhitepaperpdf acedido em Junho de 2008

[Gro08] Miniwatts Marketing Group World internet usage March 2008Disponıvel em httpwwwinternetworldstatscomstatshtm ace-dido em Abril de 2008

[Hic08] Ian Hickson HTML 5 Draft Recommendation 2008 Disponıvelem httpwwwwhatwgorgspecsweb-appscurrent-work ace-dido em Marco de 2008

[Kha] Olga Kharif Top 10 municipal wifi plans Disponıvel em http

imagesbusinessweekcomss0608muni_wifiindex_01htm ace-dido em Marco de 2008

[Lab07] Mozilla Labs Prism Outubro 2007 Disponıvel em httplabs

mozillacom200710prism acedido em Marco de 2008

[Loo06] Chris Loosley Rich Internet ApplicationsDesign MeasurementandManagement Challenges 2006 Disponıvel em httpwwwkeynote

comdocswhitepapersRichInternet_5pdf acedido em Maio de2008

[Mic08] Microsoft Introduction to Occasionally Connected Applications us-ing Sync Services for ADONET 2008 Disponıvel em httpmsdn

microsoftcomen-ussyncbb887608aspx acedido em Junho de2008

[Nao08] Erica Naone Offline web applications Abril 2008 Disponıvelem httpwwwtechnologyreviewcomread_articleaspxch=

specialsectionsampsc=emerging08ampid=20245 acedido emAbril de 2008

[NJN00] Jason Nieh Yang S Jae and Naomi Novik A comparison of thin-clientcomputing architectures 2000 Disponıvel em httpwwwnclcs

columbiaedupublicationscucs-022-00pdf acedido em Maio de2008

[OrsquoR06] Tim OrsquoReilly Web 20 compact definition Trying again Dezembro2006 Disponıvel em httpradaroreillycomarchives200612

web-20-compact-definition-tryihtml acedido em Marco de 2008

[OrsquoR09] Tim OrsquoReilly What is Web 20 Design patterns and business modelsfor the Next Generation of Software 20053009 Disponıvel emhttpwwworeillynetcompubaoreillytimnews200509

30what-is-web-20html acedido em Marco de 2008

[Rus06] Alex Russel Comet Low latency data for the browser March Marco2006 Disponıvel em httpalexdojotoolkitorgp=545 acedidoem Marco de 2008

58

REFERENCIAS

[Sad97] Darleen Sadoski Clientserver software architecturesndashan overviewAgosto 1997 Disponıvel em httpwwwseicmuedustr

descriptionsclientserver_bodyhtml acedido em Junho de2008

[Sch96] George Schussel Clientserver past present and future 1996

[Smi07] Kevin C Smith Css filters - will the browser apply the rule July 2007Disponıvel em httpcentriclecomrefcssfilters acedido emMarco de 2008

[vK08] Anne van Kesteren The XMLHttpRequest Object W3C Work-ing Draft 15 Abril 2008 Disponıvel em httpwwww3orgTR

XMLHttpRequest acedido em Abril de 2008

[Wil06] Greg Wilkins Why ajax comet July Julho 2006 Disponıvel emhttpwwwwebtidecomdownloadswhitePaperWhyAjaxhtml ace-dido em Abril de 2008

59

REFERENCIAS

60

Anexo A

Screenshots

Algumas imagens de aplicacoes que utilizam funcionalidades offline ilustrativasda tecnologia abordada neste documento

Figura A1 Dialogo apresentado ao utilizador na primeira activacao das funcionalidadesoffline no Google Docs amp Spreadsheets

61

Screenshots

Figura A2 Na activacao das funcionalidades offline e tambem oferecida a possibilidadeda criacao de alguns atalhos por exemplo no ambiente de trabalho

Figura A3 O Google Docs mantem a todo o momento a possibilidade de alteracao destasdefinicoes ou da anulacao dos servicos offline para um dado computador

62

Screenshots

Figura A4 Apos a instalacao do Gears qualquer visita ao Remember The Milk despoletauma sincronizacao que ocorre automaticamente e sem necessidade de intervencao por partedo utilizador

Figura A5 Apos completar a sincronizacao de dados mesmo que a ligacao a Internetseja perdida o Remember the Milk continua disponıvel no browser (com excepcao dasfuncionalidades que pela sua natureza exigem uma ligacao como por exemplo partilhade tarefas e envio de convites)

63

Page 2: O ine Web Applications

ccopy Joao Goncalves da Costa 31 de Julho de 2008

Offline Web Applications

Joao Goncalves da Costa

Relatorio de Projecto realizado no Ambito do

Mestrado Integrado em Engenharia Informatica e Computacao

Aprovado em provas publicas pelo juri

Presidente Pedro Ferreira do Souto (PhD)

Arguente Artur Pereira (PhD)

Vogal Teresa Galvao Dias (PhD)

27 de Julho de 2008

Resumo

Este projecto teve como objectivo o estudo das Offline Web Applications (OWAs)e da sua implementacao em web applications ja existentes Neste ambito foi feitauma avaliacao da aplicacao desta tecnologia no WOW uma plataforma integradade gestao de ordens de trabalho desenvolvida pela Critical Software SA ao longodos ultimos 6 anos e implementada uma prova de conceito que permite a utilizacaode um conjunto de funcionalidades base desta web application independentementedo estado da ligacao a Internet

O conceito das OWAs enquadra-se numa tecnologia de Internet que permiteo acesso a um website atraves do browser mesmo na ausencia de uma ligacao arede global e foi considerado pela revista Technology Review como uma das maisimportantes tecnologias emergentes no final de 2007 [Nao08] O estudo efectuado noWOW pretende ser um primeiro passo na compreensao dos problemas associados asua implementacao e respectivas solucoes e tambem da avaliacao dos benefıcios dautilizacao desta tecnologia para os utilizadores finais

A evolucao das tecnologias associadas a Internet a que se assiste continua-mente impulsionou tambem evolucao da forma como a informacao e produzidadistribuıda e armazenada Surgiram novas web applications oferecendo funcionali-dades de criacao e edicao de conteudos que trouxeram consigo a vantagem de tornarpossıvel o acesso a informacao a partir de qualquer lugar mas tambem a desvan-tagem de tornar a ligacao a Internet uma condicao necessaria para que isto acontecaA proliferacao destas aplicacoes a crescente utilizacao da Internet [Gro08] e a adesaoaos seus servicos indiciam a existencia de uma dependencia cada vez maior de umaligacao que nem sempre existe

As OWAs vem assim colmatar esta falha colocando no lado do cliente parte dainformacao que ate agora vinha a ser armazenada no servidor e tornando nao sopossıvel a sua consulta offline como tambem reduzindo a carga no servidor umavez que reduz as transferencias de informacao

Pretende-se neste documento apresentar diferentes formas de como a utilizacaoda tecnologia OWA pode beneficiar as web applications de hoje melhorando o seudesempenho e dando-lhes novas possibilidades de execucao aproximando-as do desk-top

i

ii

Abstract

The main purpose of this project was to study the Offline Web Applications(OWAs) and its implementation in existent web applications With this goal in minda study was conducted to use this technology in WOW an integrated platform forwork orders and work flow management developed by Critical Software over thelast 6 years and implemented a proof of concept which enables the use of a baseset of functionality for this application regardless of the internet connection state

The concept of OWAs is connected with internet technology and allows accessto a website using the browser even if a connection to the internet is not availableThis concept was considered by Technology Review as one of the most importantemerging technologies in the last quarter of 2007 [Nao08] This study conductedover the WOW platform is intended to aid in the comprehension of the problemsand solutions associated to the use and implementation of OWA as well as thebenefits that it brings to the end user

The Internet and Internet technologies are changing the way in which informa-tion is produced distributed and stored New web applications appeared with newcontent creation and edition functionalities and with it the advantage of infor-mation retrieval from any place and time became possible but with the conditionof Internet connection availability With Internet use growing every year [Gro08]content creation is starting to move to this new platform The adoption of web ap-plications for content creation and edition is becoming more popular and it showsa dependency of a connection that is not always present

The OWAs are a way to solve this problem putting on the client side part ofthe information that was traditionally stored on the server and allows it to be seenand manipulated and helps reducing the server load

This document intends to present different ways in which this technology canhelp web applications as we know them improving the their overall performance andgiving them the ability to run on a browser regardless of the Internet connectionavailability

iii

iv

Agradecimentos

A realizacao e os objectivos alcancados neste projecto nao teriam sido possıveissem a colaboracao de inumeras pessoas Agradeco profundamente a todos os quecontribuıram directa ou indirectamente para o seu sucesso

A minha orientadora Professora Teresa Galvao Dias e ao Project ManagerEngenheiro Marcus Neves que me conduziram e acompanharam no desenvolvimentodeste projecto

A toda a equipa do WOW em especial o Pedro Maurıcio Costa e o Fabio Matosque contribuıram para a minha a minha integracao na Critical Software e que sempresouberam responder a todas as minhas questoes

A todos os que constituem a CSW Porto pelo fantastico ambiente de amizadeque me proporcionaram

Aos colegas de curso e a todos os que me auxiliaram na revisao deste documento

Os meus sinceros agradecimentos

Joao Goncalves da Costa

v

vi

Conteudo

1 Introducao 111 Enquadramento 112 Motivacao 213 Ambito 314 Objectivos 315 Estrutura do documento 3

2 Enquadramento do Projecto 521 Evolucao das arquitecturas de software 5

211 Thin-clients 5212 Fat-clients 6213 Arquitecturas cliente-servidor 7

22 Evolucao na Internet 8221 Paginas web estaticas 9222 Paginas web interactivas e paginas web dinamicas 9223 Web 20 e Ajax 11

23 Offline Web Applications 1324 Comparacao 13

3 Estado da arte 1731 Gears 17

311 Arquitectura 17312 Goggle Gears em dispositivos moveis 20

32 Adobe AIR 20321 Seguranca 22322 Assinatura do codigo 22

33 Mozilla Prism 23331 XML User Interface Language 23332 Prism 25

34 HTML 5 2535 Web applications que usam funcionalidades offline 26

351 Google Reader e Google Docs 26352 Remember the Milk 27353 MySpace e WordPresscom 27

36 Escolha da tecnologia 28

vii

CONTEUDO

4 Desenvolvimento 3341 Como ficar offline 33

411 Funcionalidades disponıveis em modo offline 3442 Modos de execucao 35

421 Modo ldquoutilizador deciderdquo 36422 Modo aplicacao decide 36423 Modo ldquoaplicacao assume o estado offlinerdquo 37

43 Sincronizacao de dados 38431 Quando sincronizar 39

44 WOW 4045 Visao geral sobre a arquitectura do WOW 4146 WOW Offline 42

461 Modo ldquoaplicacao deciderdquo com deteccao automatica da ligacao 43462 Implementacao do modo ldquoutilizador deciderdquo 45463 Especificacao do modo ldquoaplicacao assume o estado offlinerdquo 48

5 Resultados e Futuros Desenvolvimentos 5151 Resultados Obtidos 5152 Trabalho Futuro 52

6 Conclusoes 5561 Conclusoes 55

Referencias 59

A Screenshots 61

viii

Lista de Figuras

21 Arquitectura de um sistema thin-client em duas camadas (a esquerda)e em tres camadas (a direita) Note-se a inclusao do servidor (main-frame) na definicao das camadas desta arquitectura devido a fortedependencia cliente-servidor 9

22 Arquitectura de um fat-client em duas camadas (a esquerda) e emtres camadas (a direita) 10

23 Comparacao do modelo de web aplications sıncrono paginas estaticase interactivas abordados nas seccoes 221 e 222 com o modelo deweb applications Ajax (assıncrono) abordado na seccao 223 Figuraadaptada de http www adaptivepath com 15

31 Esquema UML do processo efectuado pelos recursos do Gears do tipoManagedResourceStore para a actualizacao dos conteudos definidosno ficheiro manifesto 29

41 Exemplo de uma arquitectura de uma web application sem uma ca-mada de abstraccao de dados Figura adaptada de http gears

google com 33

42 Exemplo de uma arquitectura de uma web application com uma ca-mada de abstraccao de dados Figura adaptada de http gears

google com 34

43 Exemplo de uma arquitectura de uma web application com uma ca-mada de abstraccao de dados e um data switch Figura adaptada dehttp gears google com 35

44 Esquema grafico ilustrando uma OWA executando no browser uti-lizando um modo de execucao do tipo ldquoaplicacao deciderdquo com de-teccao automatica do estado da ligacao via pedidos Ajax assıncronosa cada cinco segundos 37

45 Detalhe de um conjunto possıvel de estados e respectivas transicoespara uma dada ordem de trabalho no WOW desde a sua submissaono sistema ate a sua conclusao em fecho ou cancelamento Esta figurarepresenta apenas um exemplo ja que o mapa de estados para umaordem de trabalho e dinamico e pode ser alterado por um admin-istrador Figura retirada de uma brochura promocional do WOWCritical Software SA 41

ix

LISTA DE FIGURAS

46 A pagina inicial do WOW apresenta um resumo das ultimas ordensde trabalho enviadas e recebidas Na imagem pode-se observar atransicao do estado online para offline 44

47 Ilustracao do funcionamento do Gears numa web application que uti-liza um motor Ajax Os pedidos HTTP ou HTTPS podem ser inter-ceptados e tratados localmente ou podem ser feitos a uma maquinaremota consoante se verificarem ou nao as condicoes expressas noponto 311 E representado um acesso a uma base de dados local(fornecida pelo Gears) mas a sua utilizacao e opcional 45

48 Neste exemplo do modo ldquoaplicacao deciderdquo o teste da ligacao e feitoe feito a cada cinco segundos O resultado deste teste nao reflectesempre o estado real da aplicacao podendo levar a aplicacao a tercomportamentos indesejaveis Na figura assinala-se um perıodo detempo no qual a representacao interna do estado da ligacao nao cor-responde a realidade 46

49 Pagina de visualizacao do detalhe de uma ordem de trabalho 47410 Esquema UML que expressa os casos de uso do WOW Offline no

modo ldquoutilizador deciderdquo 48411 Esquema UML que expressa os casos de uso do WOW Offline no

modo ldquoutilizador deciderdquo 49412 Esquema UML que expressa o acto de recolha de dados em modo

online e offline recorrendo ao servidor (modo online) e ao sistemade armazenamento de dados local fornecido pelo Gears (modo offline) 50

A1 Dialogo apresentado ao utilizador na primeira activacao das funcional-idades offline no Google Docs amp Spreadsheets 61

A2 Na activacao das funcionalidades offline e tambem oferecida a possi-bilidade da criacao de alguns atalhos por exemplo no ambiente detrabalho 62

A3 O Google Docs mantem a todo o momento a possibilidade de alteracaodestas definicoes ou da anulacao dos servicos offline para um dadocomputador 62

A4 Apos a instalacao do Gears qualquer visita ao Remember The Milkdespoleta uma sincronizacao que ocorre automaticamente e sem ne-cessidade de intervencao por parte do utilizador 63

A5 Apos completar a sincronizacao de dados mesmo que a ligacao aInternet seja perdida o Remember the Milk continua disponıvel nobrowser (com excepcao das funcionalidades que pela sua naturezaexigem uma ligacao como por exemplo partilha de tarefas e enviode convites) 63

x

Lista de Tabelas

21 Comparacao entre thin-clients e fat-clients 7

31 Comparacao das funcionalidades oferecidas pelo Adobe AIR para asplataformas web e desktop 30

32 Resumo da utilizacao de tecnologias OWA em algumas web applica-tions consideradas na analise do estado da arte 31

xi

LISTA DE TABELAS

xii

Glossario

fat-client Cliente que nao depende totalmente de umservidor central para as suas actividadesde processamento e possui frequentementedispositivos de armazenamento de dados

6ndash8

thin-client Cliente que depende de um servidor centralpara as suas actividades de processamento

5ndash8

web application Sistema web (servidor rede HTTPbrowser) onde accoes do utilizador(navegacao e introducao de informacao)afectam o estado logico da aplicacao

i iii1ndash311ndash1517ndash1921ndash232728 3336ndash3842 5556

API Application Programming Interface 10 1718 2326 28

ASP Linguagem interpretada pelo servidorque permite a criacao de paginas webdinamicas Desenvolvida pela Microsoft

11

BSD Berkeley Software Distribution 28

CSS Cascading Style Sheets 12 2021 2324 46

DHTML Dynamic HyperText Transfer Protocol 24DOM Document Object Model 10 12

20 2324

DTD Document Type Definition 24

xiii

Glossario

ECMAScript Padrao de linguagem de programacaodefinido pela Ecma International que orig-inou o JavaScript e o JScript

24

Flash Conteudo interactivo de um ficheiro emformato SWF E desenvolvido pela Adobee visualizado atraves do Adobe FlashPlayer

21

Flex Framework baseada em XML e Action-Script desenvolvida pela Adobe para a pro-gramacao de Rich Internet Applications(RIA)

21

GPL GNU General Public License 23

HTML HyperText Markup Language 1 10ndash12 2124ndash2649

HTTP HyperText Transfer Protocol 2 26

JMS E uma API em Java que permite a troca demensagens entre componentes de software

42

JSON JavaScript Object Notation permite atroca de dados codificados num formatode texto de simples leitura

12 1828 34

LGPL GNU Lesser General Public License 23

Mozilla Prism Browser simplificado e ldquointerpretadorrdquo deeXtensible User Interface Language (XUL)(tambem designado por XULRunner) queacolhe web applications sem a interfacegrafica habitual de um browser

25

MPL Mozilla Public License 23

OCA Occasionally Connected Application 39OWA Offline Web Application i iii

2ndash515 1725 2628 3133 3651 5255 56

PDF Portable Document Format 21

xiv

Glossario

PHP Linguagem interpretada pelo servidorque permite a criacao de paginas webdinamicas mas que pode tambem ser in-vocada a partir da linha de comandos

11

pagina web estatica Pagina web que devolve sempre a mesmaresposta a todos os pedidos para todos osutilizadores e em qualquer contexto

5 9

RIA Rich Internet Applications web appli-cations que apresentam funcionalidadessemelhantes as desktop applications masque mantem a informacao no lado do servi-dor

5 1520 28

RSS Really Simple Syndication 27

SLA Service Level Agreement 40SQLite Segundo a definicao oficial SQLite is a

software library that implements a self-contained serverless zero-configurationtransactional SQL database engine

17

SSB Site Specific Browser 25SSL Secure Sockets Layer 22SWF ShockWave Flash 21

URL Uniform Resource Locator 18

VPN Virtual Private Network 38

WOW Work Orders Web Plataforma de gestaode ordens de trabalho e do seu fluxo de-senvolvida pela Critical Software SA

i iii28 3340ndash434551ndash5356

WWW World Wide Web 11 1214

XBL eXtensible Binding Language 24XHTML eXtensible HyperText Markup Language 12XML eXtensible Markup Language 11 12

23 2428

XSLT eXtensible Stylesheet Language Transfor-mation

12

XUL eXtensible User Interface Language xiv23ndash25

xv

Glossario

xvi

Capıtulo 1

Introducao

Neste capıtulo enquadra-se o tema do projecto introduzindo alguns dos conceitos

nos quais se baseia Apresentam-se as motivacoes ambito objectivos e a estrutura

deste documento

11 Enquadramento

A Internet foi originalmente concebida para ser um espaco de partilha de in-

formacao onde pessoas (atraves de maquinas) pudessem comunicar Na sua origem

as paginas eram estaticas constituıdas por texto formatado em HyperText Markup

Language (HTML) e ligadas entre si [BL96] Hoje encontramos conteudos cada vez

mais complexos e dinamicos incluindo som vıdeo ou streams multimedia [Loo06] e

em 2005 foi introduzido por [OrsquoR09] o termo Web 20

De acordo com [Greon] um website pode pertencer a uma ou varias das seguintes

categorias

bull Documento ndash um website essencialmente estatico onde alteracoes a uma

parte do conteudo nao tem implicacoes no seu comportamento

bull Base de dados ndash um directorio de informacao organizada em categorias

bull Aplicacao ndash um website dinamico que utiliza uma linguagem executada ou

interpretada do lado do servidor e que processa as accoes ou informacao in-

troduzida pelo utilizador para fornecer um servico ou nova informacao

A ultima destas categorias constitui aquilo que e normalmente designado por

web application O conceito utilizado ao longo deste documento e o mesmo que

o introduzido por Jim Coallen em [Con99] que define web application como um

1

Introducao

sistema web (servidor rede HyperText Transfer Protocol (HTTP) browser) onde

accoes do utilizador (navegacao e introducao de informacao) afectam o estado logico

da aplicacao A sua definicao tenta estabelecer que uma web application e um

sistema de software com estado de negocio1 e que a sua interface de interaccao com

o utilizador e distribuıdo atraves de um sistema web

12 Motivacao

A quantidade de informacao que e produzida e armazenada com recurso a es-

tas web applications disponıveis online tais como e-mail blogues ou mesmo docu-

mentacao tornam por vezes a disponibilidade de ligacao uma condicao necessaria

a produtividade e como consequencia desta barreira muitos potenciais utilizadores

opoem-se a adopcao de produtos web em detrimento das tradicionais desktop appli-

cations

Assegurar o acesso a uma ligacao de Internet e hoje muito mais facil A Internet

movel e ja uma realidade e encontra-se amplamente divulgada mas continuam a

existir diversas situacoes nas quais os utilizadores estao privados de uma ligacao

a Internet tais como uma viagem de metro ou de aviao ou quando se encontram

deslocados do seu paıs de origem e nao possuem nenhum plano de subscricao

Uma OWA consiste numa web application que para alem de manter todas as

caracterısticas anteriores se mantem disponıvel mesmo na ausencia de uma ligacao

a Internet e surge como uma tentativa de estreitar as barreiras existentes entre a

web e o desktop Isto significa que devera existir um mecanismo capaz de assegurar

a manutencao do estado logico da aplicacao quando a ligacao com o servidor e

quebrada permitindo ao utilizador continuar a utilizar a aplicacao e que sera capaz

de informar o servidor do estado em que a aplicacao se encontra quando a ligacao for

reposta A principal vantagem que advem desta possibilidade e evidente eliminar

a necessidade da existencia de uma ligacao a Internet para que a aplicacao possa ser

utilizada

Por outro lado a vontade de integracao de funcionalidades tıpicas das desktop

applications nas web applications foi um dos principais factores que impulsionou o

desenvolvimento deste conceito uma vez que obrigou a uma reflexao ldquopara alem

do browserrdquo e a uma adaptacao das arquitecturas existentes que permitisse ou o

acesso a funcionalidades disponibilizadas pelo sistema operativo ou pelo menos a

funcionalidades semelhantes Pretende-se com esta aproximacao tornar possıveis

interaccoes entre o desktop e o browser tais como arrastar um ficheiro para um

formulario web de upload de conteudos melhor suporte para o historico do clipboard

ou ainda o acesso ao sistema de ficheiros local Atingir estes objectivos reflecte-se

1NT business state

2

Introducao

num novo paradigma que reune as vantagens das web applications tais como os

updates instantaneos ou o facto de nao ser necessaria nenhuma instalacao e das

desktop applications como por exemplo persistencia no armazenamento de dados

acesso a funcionalidades do sistema operativo ou integracao e interaccao com outras

aplicacoes sejam elas web applications ou desktop applications

13 Ambito

Este projecto foi realizado na Critical Software SA no ambito do Mestrado

Integrado em Engenharia Informatica e Computacao (MIEIC) da Faculdade de En-

genharia da Universidade do Porto (FEUP) entre os meses de Fevereiro e Julho de

2008

14 Objectivos

Sao objectivos deste projecto

1 Estudar e documentar o tema das OWAs acompanhando os ultimos desenvolvi-

mentos nesta materia

2 Analisar o estado da arte fazendo uma analise crıtica e objectiva sobre as

diversas metodologias existentes

3 Implementar uma prova de conceito que permita a execucao offline de uma

web application documentando todo o processo

4 Estudar a possibilidade de permitir interaccao com a aplicacao (insercoes e

alteracoes aos dados) em modo offline

Em resumo o objectivo deste projecto foi estudar documentar e implementar

uma prova de conceito relacionada com o tema Offline Web Applications (OWA)

Este tema embora nao seja totalmente novo ganhou destaque ao longo do ano de

2007 com o surgimento de diversas ferramentas que se destinam a aproximar web

applications das desktop applications

15 Estrutura do documento

Este documento esta organizado em diferentes seccoes apresentando o projecto

numa sequencia logica organizada da seguinte forma

No capıtulo 1 faz-se uma breve apresentacao do conceito OWAs e do contexto em

que surge Apresenta-se tambem a estrutura do documento e definem-se os

termos e acronimos utilizados

3

Introducao

No capıtulo 2 faz-se uma descricao da evolucao das tecnologias que antecedem as

OWAs e das vantagens e desvantagens de cada uma como forma de enquadra-

mento

No capıtulo 3 analisa-se o estado da arte nesta materia Introduzem-se diversas

tecnologias directamente relacionadas com o tema deste projecto exemplos de

aplicacoes que as usam e as razoes que fundamentam as escolhas de tecnologias

efectuadas

O capıtulo 4 contem o desenvolvimento do projecto Analisa-se a plataforma

WOW de gestao integrada de ordens de trabalho a tecnologia escolhida e

a forma como foi utilizada para implementar a capacidade de execucao offline

O capıtulo 5 descreve os resultado obtidos comparando-os com as expectativas

iniciais do projecto e apresenta desenvolvimentos futuros e possibilidades de

continuacaoaplicacao do conhecimento adquirido

No capıtulo 6 apresentam-se as conclusoes

4

Capıtulo 2

Enquadramento do Projecto

Neste capıtulo apresenta-se um breve resumo da evolucao das arquitecturas de

software cliente-servidor e a forma como estas se comparam a evolucao da Inter-

net procurando estabelecer uma analogia entre o percurso de ambas as tecnolo-

gias Compara-se o comportamento e arquitectura dos thin-clients as paginas web

estaticas a evolucao dos fat-clients as paginas interactivas Web 20 e Ajax e

defende-se que as OWA constituem um proximo passo logico e evolutivo aproxi-

mando a web do desktop Referem-se ainda os principais factores que justificam a

importancia das OWAs e a estreita relacao que tem com as Rich Internet Application

(RIA)s

21 Evolucao das arquitecturas de software

Os termos thin-client e fat-client sao utilizados quer para descrever arquitecturas

logicas (de software) quer para descrever arquitecturas fısicas (de hardware) Neste

capıtulo excepto quando seja dada indicacao em contrario estes termos referem-se

sempre a uma arquitectura logica

Adicionalmente quando se trata de arquitecturas cliente-servidor pode-se estu-

dar a arquitectura desenvolvida do sistema como um todo da arquitectura do servi-

dor ou da arquitectura do cliente Para evitar equıvocos em especial na seccao 213

especifica-se em cada caso qual o sistema estudado

211 Thin-clients

Um thin-client e um computador cliente ou software cliente que no contexto

de uma arquitectura cliente-servidor depende de um servidor central para as suas

5

Enquadramento do Projecto

actividades de processamento e proporciona um canal de entrada e saıda de in-

formacao entre o utilizador e o servidor remoto Este termo quando aplicado a

hardware refere-se habitualmente a um computador que se destina a ser utilizado

como cliente de rede sem armazenamento local e com capacidade de processamento

reduzida [Gro02b] mas o conceito que aqui se analisa refere-se a uma arquitectura

de software que remonta ao inıcio das aplicacoes cliente-servidor

No inıcio da historia da computacao terminais ligavam-se directamente a main-

frames responsaveis por todo o processamento Nesta arquitectura era necessario

desenvolver duas aplicacoes distintas uma aplicacao central no servidor (main-

frame) responsavel pela gestao de toda a informacao e por todas as operacoes de

comunicacao e uma aplicacao de visualizacao instalada no cliente (terminal) O

papel destes terminais era apenas disponibilizar ao utilizador um meio de comu-

nicacao (entrada e saıda) e apresentacao dos resultados do servidor Nao tinham

um papel activo no calculo nem na logica de negocio e frequentemente nao tinham

tambem nenhum mecanismo de armazenamento de dados

Como vantagens esta arquitectura apresenta uma reduzida necessidade de con-

figuracao e manutencao do lado do cliente Uma vez que o centro do processamento

e manipulacao de dados ocorre no servidor existe tambem uma centralizacao da

informacao [NJN00] que introduz um ponto crıtico de falha1 Actualizacoes e novas

funcionalidades sao faceis de distribuir uma vez que requerem apenas alteracoes no

servidor [Gro02a]

212 Fat-clients

Contrastando com os thin-clients nesta arquitectura os clientes implementam

ja uma parte da logica de negocio e sao responsaveis pelo processamento de dados

Estes fat-clients vieram responder a necessidade crescente de aplicacoes com um

nıvel de interactividade e capacidade de configuracao maior que as oferecidas pela

arquitectura thin-client descrita na seccao 211 Apesar de manterem a sua de-

pendencia do servidor podem tambem ser executados sem uma conexao activa uma

vez que dispoe de armazenamento de dados local o que lhes confere a capacidade

de persistencia de dados e do estado de execucao entre cada sessao

Foi disponibilizando este controlo sobre o estado da aplicacao bem como acesso

a recursos locais (por exemplo sistema de ficheiros e perifericos) que surgiram as

primeiras verdadeiras desktop applications No entanto cada cliente tinha que ser

separadamente instalado no computador pessoal de cada utilizador que pretendesse

utilizar ou interagir com a aplicacao e uma actualizacao ao servidor implicava in-

variavelmente uma actualizacao manual tambem no cliente Uma vez que nem todos

1NT single point of failure

6

Enquadramento do Projecto

Thin-clients Fat-clientsNao toma parte no processamento dedados nem possui acesso ao sistema deficheiros

Participa activamente no processa-mento de dados recorrendo ao sis-tema de armazenamento local para ar-mazenamento de dados

Nao mantem registo do estado logicoda aplicacao entre duas sessoes de uti-lizacao

O acesso ao armazenamento localpermite-lhe manter registo do estadologico da aplicacao entre duas sessoes

O thin-client nao necessita de qualquerinstalacao estando ldquopronto a utilizarrdquo

E geralmente necessario instalar aaplicacao para poder interagir com oservidor

Qualquer update no servidor reflecte-seimediatamente por todos os clientes

Embora a aplicacao cliente possa aler-tar para existencia de novas versoes asactualizacoes tem que ser manualmenteinstalados pelo cliente

O software do cliente destina-se apenasa apresentacao de dados e comunicacaocom o servidor sendo portanto de sim-ples implementacao

Como o software do cliente toma parteactiva no processamento de dadosa sua implementacao requer cuidadosadicionais

Grande mobilidade uma vez que todaa informacao e mantida no servidor

Parte da informacao podera estar ape-nas do lado cliente pelo que existemalgumas restricoes a sua mobilidade

Tabela 21 Comparacao entre thin-clients e fat-clients

os utilizadores actualizam regularmente as suas aplicacoes o servidor tem que estar

preparado para lidar com versoes antigas2 ou descontinuar os seus servicos a uma

parte da sua comunidade de utilizadores ate que estes actualizem os seus sistemas

Como os utilizadores passam a utilizar os seus recursos locais para armazenamento

de dados as alteracoes que nao sejam sincronizadas com o servidor estao apenas

disponıveis nos seus computadores pessoais o que introduz uma restricao a mobili-

dade

Pode-se afirmar que as vantagens dos thin-clients sao as desvantagens dos fat-

clients e que as vantagens dos fat-clients sao as vantagens dos thin-clients tal como

se ilustra na Tabela 21

213 Arquitecturas cliente-servidor

Introduzidos os termos thin-client e fat-client interessa reafirmar que ambos

podem ser vistos como arquitecturas cliente-servidor Um cliente define-se como

um solicitador de servicos e um servidor como um prestador de servicos tal como

definido por [Sch96] e [Sad97]

2NT backward compatibility

7

Enquadramento do Projecto

As arquitecturas cliente-servidor sao categorizadas pela modularizacao com que

sao desenhadas sendo consideradas as seguintes camadas

1 Interface grafica (front-end) atraves da qual os utilizadores interagem com

a aplicacao Quando este modulo e implementado separadamente dos outros

dois constitui uma aplicacao thin-client por si so uma vez que nao implementa

regras de negocio (embora possa definir validacoes de formularios de insercao de

dados por exemplo) A informacao introduzida pelo utilizador e enviada para

o servidor que processa o seu pedido e retorna uma resposta Este processo

repete-se ate que o utilizador atinja o seu objectivo ou se desligue do sistema

2 A logica de negocio tambem designada por camada intermedia que imple-

menta as regras de aceitacao e validacao de todos os dados introduzidos pelo

utilizador E tambem a plataforma de comunicacao que une a camada superior

de visualizacao com a camada de acesso a dados

3 A camada de dados inclui quer o sistema de persistencia de dados onde sao

armazenados os dados relevantes como tambem os mecanismos necessarios

para a sua pesquisa seleccao e alteracao

Os thin-clients quando observados no seu conjunto de cliente e servidor podem

ser vistos quer como sistemas de duas camadas quer como sistemas de tres camadas

dependendo apenas da forma como o servidor for implementado No caso de na

implementacao do servidor nao se distinguir a camada de acesso a dados da camada

da logica de negocio sao designados por sistemas de duas camadas Caso seja feita

esta distincao sao designados por sistemas de tres camadas Ambos os casos sao

ilustrados na Figura 21

Historicamente os fat-clients eram implementados numa arquitectura em duas

camadas Possuıam apenas um modulo de visualizacao de dados designado por

camada de interface e um modulo que implementava toda a logica de negocio e

regras de acesso a base de dados No entanto com a introducao de ligacoes mais

rapidas e de computadores pessoais com maior capacidade de processamento e so-

bretudo devido a complexidade crescente das aplicacoes a logica de negocio e a

camada de acesso a dados tornaram-se independentes Este modelo e designado por

arquitectura em tres camadas e e ilustrado na Figura 22

22 Evolucao na Internet

Ao analisar a evolucao das arquitecturas das aplicacoes desenvolvidas para a

Internet podemos encontrar um paralelismo com a historia da arquitectura de soft-

ware

8

Enquadramento do Projecto

Figura 21 Arquitectura de um sistema thin-client em duas camadas (a esquerda) e emtres camadas (a direita) Note-se a inclusao do servidor (mainframe) na definicao dascamadas desta arquitectura devido a forte dependencia cliente-servidor

221 Paginas web estaticas

Uma pagina web estatica devolve sempre a mesma resposta a todos os pedidos

para todos os utilizadores e em qualquer contexto utilizando o hipertexto como

forma de ligacao entre diversas paginas estaticas

A informacao e armazenada num servidor e o papel do cliente e apenas a apre-

sentacao da informacao Esta forma de disponibilizacao de informacao pode assim

ser comparada com os thin-clients descritos na seccao 211 o utilizador acede a

um website estatico para visualizar informacao sem que o cliente tome parte no

processamento A unica diferenca e que no caso da web estatica a informacao ap-

resentada e sempre a mesma enquanto que nos thin-clients era frequente existir a

possibilidade de insercao de dados no cliente e apos o seu processamento servidor

nova informacao poderia ser apresentada O hipertexto e utilizado para ligar as

paginas entre si numa rede de conteudos relacionados e a navegacao sıncrona era

feita atraves de cliques do rato a cada clique uma nova pagina era apresentada

Este modelo sıncrono e ilustrado na Figura 23

222 Paginas web interactivas e paginas web dinamicas

O JavaScript e uma linguagem interpretada de scripting que tem os browsers

como principal ambiente de acolhimento Os browsers utilizam uma Application

9

Enquadramento do Projecto

Figura 22 Arquitectura de um fat-client em duas camadas (a esquerda) e em tres camadas(a direita)

Programming Interface (API) publica para criar ldquoobjectosrdquo responsaveis por reflectir

e disponibilizar o Document Object Model (DOM) para o motor de JavaScript

A utilizacao mais frequente desta linguagem e a escrita de funcoes que sao em-

bebidas ou incluıdas em paginas web e que interagem com o DOM Uma vez que o

JavaScript e executado localmente (na maquina do cliente e nao no servidor) e capaz

de responder rapidamente a accoes do utilizador tornando a execucao de aplicacoes

no browser mais fluıdas o JavaScript pode tambem detectar accoes do utilizador

que o HTML nao pode tal como o pressionar de uma tecla

Em Dezembro de 1995 a Netscape Communications adicionou suporte para o

JavaScript no browser Netscape Navigator3 e em Agosto de 1996 o browser Internet

Explorer4 da Microsoft passou a tambem a suportar uma versao semelhante desta

linguagem (hoje todos os principais browsers suportam esta tecnologia)

Esta inovacao permitiu tornar os websites mais interactivos mas a sua utilizacao

esteve confinada apenas a este proposito durante um longo perıodo As paginas

passaram a responder activamente a accoes do utilizador (sendo uma das utilizacoes

3Netscape Communications ndash httpbrowsernetscapecom4Microsoft Internet Explorer ndash httpwwwmicrosoftcomwindowsproductswinfamilyie

10

Enquadramento do Projecto

mais vulgares a validacao de formularios) mas continuaram essencialmente estaticas

O JavaScript ainda nao era nesta altura utilizado para processar dados

Tambem nesta altura (1995ndash96) surgiram linguagens server-side como o PHP

Hypertext Preprocessor (PHP) e Active Server Pages (ASP) e o servidor passou a ter

um processamento de dados introduzidos pelo utilizador mais activo Generalizaram-

se as paginas dinamicas capazes de responder a insercao de dados ou outros pedidos

determinados por accoes do utilizador As paginas tornaram-se aplicacoes web ap-

plications

Uma definicao tradicional de web application e um conjunto de paginas web

logicamente agrupadas e geridas por uma unica entidade que tem como pontos de

entrada formularios de insercao de dados (web forms) Uma web application nao e

mais do que uma aplicacao que e acedida atraves de um browser Tem geralmente

uma arquitectura logica em tres (interface logica de negocio e camada de dados)

camadas e estao armazenadas num servidor

Ha dois tipos de web applications

bull Orientadas a apresentacao Sao web applications que geram paginas web in-

teractivas constituıdas por varios tipos de linguagens de anotacao (por exem-

plo HTML eXtensible Markup Language (XML)) e que apresentam conteudo

dinamico como resposta a pedidos efectuados pelo utilizador

bull Orientadas aos servicos Uma web application orientada aos servicos imple-

menta o ponto de acesso para um ou mais de um web service Sao geralmente

clientes de service oriented web applications

Uma vantagem significativa de implementar uma web application de forma a

suportar as funcionalidades padrao dos browsers e que estas terao o mesmo com-

portamento independentemente da plataforma e do browser a partir do qual serao

acedidas No entanto diferentes implementacoes de browsers devido a diferentes

interpretacoes dos padroes definidos tornam por vezes esta tarefa um pouco mais

complicada existindo inclusivamente na web guioes de compatibilidade para os difer-

entes browsers como [Smi07]

223 Web 20 e Ajax

O termo web 20 descreve uma tendencia de utilizacao e de design observada

na World Wide Web (WWW) com o objectivo de melhorar a criatividade partilha

de informacao e principalmente a colaboracao entre utilizadores Estes conceitos

levaram ao desenvolvimento e evolucao de comunidades online tais como redes so-

ciais wikis e blogues

11

Enquadramento do Projecto

O termo tornou-se mais conhecido apos a primeira conferencia OrsquoReilly Media

Web 20 em 2004 e apesar de sugerir uma nova versao da WWW nao se refere a

qualquer evolucao tecnologica mas apenas a alteracoes a forma como os utilizadores

se servem da web De acordo com Tim OrsquoReilly [OrsquoR06] ldquoWeb 20 e uma revolucao

na industria do software causada pela adopcao da web como uma plataforma e pela

tentativa de entendimento das regras para o sucesso nesta nova plataformardquo

O desenvolvimento da Web 20 serve-se muitas vezes de um outro conceito Ajax

O conceito que hoje conhecemos como Ajax muitas vezes incorrectamente de-

scrito como uma tecnologia foi originalmente criado para permitir o desenvolvimento

de web applications que se assemelhassem ainda mais a aplicacoes de desktop Este

conceito foi melhor descrito por [Gar05] como um conjunto de varias tecnologias

que podem ser utilizadas para melhorar a experiencia do utilizador de uma dada

web application introduzindo a capacidade assıncrona de envio de pedidos ou da

recepcao assıncrona de respostas As tecnologias mais frequentemente envolvidas

sao

bull eXtensible HyperText Markup Language (XHTML) e Cascading Style Sheets

(CSS) padrao para a apresentacao

bull interaccao dinamica atraves do DOM

bull troca e manipulacao de dados utilizando XML e eXtensible Stylesheet Lan-

guage Transformation (XSLT) ou JavaScript Object Notation (JSON)

bull pedidos assıncronos utilizando XMLHttpRequest [vK08]

bull JavaScript utilizado para integrar todas estas tecnologias

E importante frisar que o Ajax nao e um produto nem uma tecnologia E um

termo que descreve a utilizacao de um conjunto de tecnologias para o desenvolvi-

mento de web applications com um elevado grau de interactividade Comparativa-

mente as web applications tradicionais o Ajax introduz uma camada de visualizacao

diferente em tres importantes pontos

1 Do lado do cliente existe um motor que serve de intermediario entre a interface

da aplicacao e o servidor

2 A actividade do utilizador despoleta chamadas JavaScript em vez de um pedido

de pagina directamente ao servidor

3 Informacao codificada em XML em vez de paginas HTML e trocada entre o

servidor e o cliente

12

Enquadramento do Projecto

Isto significa que as paginas que utilizam Ajax contem um motor do lado do

cliente composto por um conjunto de funcoes JavaScript responsavel pela comu-

nicacao com o servidor e por actualizar a interface com o resultado dessa mesma

comunicacao

Na Figura 23 ilustra-se a natureza assıncrona do Ajax quando comparada com

as web applications tradicionais Como se pode observar adicionando um mecan-

ismo Ajax a uma web application eliminam-se diversos tempos de espera associados

a comunicacoes com o servidor uma vez que a interface nao fica ldquobloqueadardquo a es-

pera da resposta Obtem-se assim aplicacoes com um comportamento mais fluido

eliminando tempos de espera entre cada ldquocliquerdquo e melhorando a experiencia do

utilizador

23 Offline Web Applications

A informacao grafica (bem como folhas de estilo e scripts) tais como as ima-

gens que constituem o visual de uma web application e ja tratada de forma especial

pelos cada vez mais avancados sistemas de cache (armazenamento temporario) dos

browsers Mas estes nao sao ainda capazes de guardar conteudo criado pelo uti-

lizador nem de apresentar informacao independentemente do estado da ligacao

Numa altura onde se fala de servicos de Internet wireless municipalizados [Kha]

comunicacoes 3G e ligacoes de banda larga a alta velocidade a ligacao a rede global

continua a nao estar permanentemente disponıvel para os utilizadores Na WWW

encontra-se uma importante parte da informacao e das aplicacoes utilizadas para

criar e editar conteudos Por vezes informacao vital para a produtividade pode

desaparecer subitamente do mapa de acesso de um utilizador quando este entra no

metro num aviao ou mesmo quando se desloca para uma cidade ou paıs diferente

do habitual onde nao subscreve um plano de acesso que lhe garanta a ligacao

Permitir o acesso offline a estes recursos assume assim a sua importancia porque

permitira estender o alcance da informacao a locais onde nunca esteve antes e per-

mitira tambem melhorar o desempenho das web applications colocando informacao

mais perto dos utilizadores reduzindo a transferencia de dados apenas ao essencial

24 Comparacao

Nas evolucoes descritas neste capıtulo 2 pode-se observar que existe um par-

alelismo entre a evolucao das arquitecturas tradicionais cliente-servidor e a evolucao

a que se assiste na web O comportamento e arquitectura dos thin-clients assemelha-

se ao das paginas estaticas no sentido em que o browser nao toma parte em qualquer

13

Enquadramento do Projecto

processamento e serve apenas como uma plataforma de interaccao com o servidor

tal como os clientes descritos na seccao 211

A sua proxima evolucao os fat-clients trouxeram parte da capacidade de pro-

cessamento para o lado do cliente Na web foi tambem esta a inovacao tecnologica

a que se assistiu com a evolucao das tecnologias que permitiram a criacao de ver-

dadeiras aplicacoes e com a introducao do Javascript no browser dando ao cliente

a capacidade de processamento de dados A necessidade da separacao do codigo

em camadas logicas advem da crescente complexidade das web applications Esta

pratica permite entre outras coisas melhorar o processo de desenvolvimento e a

capacidade de manutencao de uma aplicacao

Os fat-clients tem tambem a capacidade de armazenamento de dados o que

permite a persistencia de informacoes entre duas sessoes e que algumas operacoes

sejam executadas sem a necessidade de comunicacao com o servidor Este facto pode

tambem ser uma realidade nas web applications com a adopcao das tecnologias OWA

Neste momento assiste-se a uma utilizacao cada vez maior da web como uma

plataforma de desenvolvimento A capacidade de cooperacao na edicao de conteudos

e a mobilidade proporcionada por esta plataforma sao os principais factores que

alimentam esta mudanca e pela primeira vez as aplicacoes tradicionais tem com-

peticao vinda de web applications A prova do reconhecimento da web como plataforma

de desenvolvimento pode ser retirada da aposta de empresas como a Adobe e Mi-

crosoft que lancaram publicamente ferramentas web complementares a produtos

seus tradicionalmente associados ao desktop ndash Acrobatcom5 e Microsoft Office

Live6 Dotar estas web applications da capacidade de execucao offline significa

aproximar a web e o desktop reunindo ldquoo melhor de dois mundosrdquo

As vantagens da mobilidade possıvel atraves da web a cooperacao na criacao e

edicao de conteudos e a possibilidade de utilizar aplicacoes sempre actualizadas e

sem necessidade de instalacao sao algumas das principais vantagens que promovem

esta mudanca que devido as preocupacoes associadas a usabilidade e experiencia do

utilizador esta fortemente associada ao desenvolvimento de Rich Internet Applica-

tion (RIA)s

5Adobe Acrobatcom httpwwwacrobatcom6Microsoft ndash httpsmallbusinessofficelivecom

14

Enquadramento do Projecto

Figura 23 Comparacao do modelo de web aplications sıncrono paginas estaticas e in-teractivas abordados nas seccoes 221 e 222 com o modelo de web applications Ajax(assıncrono) abordado na seccao 223 Figura adaptada de http www adaptivepath

com

15

Enquadramento do Projecto

16

Capıtulo 3

Estado da arte

Apesar de o conceito das OWAs nao ser absolutamente novo as tecnologias que

o suportam sao recentes Neste capıtulo descrevem-se quatro tecnologias que foram

tidas como principais candidatas para o desenvolvimento deste projecto Descrevem-

se ainda alguns exemplos de web applications que disponibilizam actualmente fun-

cionalidades offline e o processo da escolha da tecnologia a utilizar neste projecto

31 Gears

O Gears1 e uma extensao as funcionalidades do browser introduzido pelo Google

que tem como principal objectivo tornar possıvel a visualizacao de paginas de Inter-

net mesmo sem uma conexao disponıvel Encontra-se disponıvel para as platafor-

mas Windows Macintosh e Linux e oferece uma API de Javascript que permite

a scripts aceder a um mecanismo de armazenamento local baseado numa base de

dados SQLite

311 Arquitectura

Esta ferramenta e constituıda por tres componentes principais

bull LocalServer mdash Intercepta pedidos de paginas web e serve-as localmente

bull Database mdash Uma base de dados relacional construıda sobre SQLite

bull WorkerPool mdash Permite executar operacoes de computacao de uma forma

assıncrona sem afectar a capacidade de resposta e fluidez de execucao da web

application Assemelham-se a processos

1Google Inc ndash Mais informacao em httpgearsgooglecom

17

Estado da arte

LocalServer

O modulo LocalServer e uma cache de Uniform Resource Locators (URLs)

controlada pela web application Quando nao existe uma ligacao a Internet e e

feito um pedido para um URL presente nesta cache o LocalServer intercepta-o e

responde ao pedido localmente a partir do disco rıgido do utilizador A aplicacao

pode utilizar dois tipos diferentes de armazenamento local de URLs

bull ResourceStore ndash serve para capturar URLs utilizando exclusivamente a API

de Javascript disponibilizada para o efeito Uma aplicacao podera criar e

utilizar diversos ResourceStores simultaneamente para capturar ficheiros de

dados que necessitam de ser enderecados por um URL tal como um ficheiro

PDF ou uma imagem

bull ManagedResourceStore ndash serve para capturar um conjunto de URLs que estao

relacionados e que sao declarado num ficheiro de manifesto (especificado em

JSON) e que sao automaticamente actualizados O ManagedResourceStore

permite que o conjunto de recursos necessarios para correr uma web application

seja capturado e mantido actualizado automaticamente

A principal diferenca entre estes dois tipos de armazenamento de URLs e a forma

como sao actualizados os seus conteudos Os conteudos de um ManagedResourceStore

sao actualizados sempre que a versao contida no ficheiro de manifesto for alterada

enquanto que os conteudos de um ResourceStore nunca sao actualizados automati-

camente mas apenas quando for explicitamente ordenado pela aplicacao

O LocalServer e capaz de interceptar e servir localmente pedidos de HTTP e

HTTPS sempre que se reunam as seguintes condicoes

1 O URL encontra-se armazenado num ResourceStore ou ManagedResourceStore

2 O sistema de armazenamento local encontra-se activo (enabled = true) Se

o sistema de armazenamento local tiver o atributo requiredCookie o pedido

devera conter um cookie que lhe corresponda

O LocalServer nao necessita de monitorizar o estado da ligacao para atender aos

pedidos Na verdade sempre que as condicoes previamente enunciadas se verificarem

o LocalServer interceptara os pedidos e independentemente do estado da ligacao

a Internet servi-los-a a partir do disco rıgido local Cabera a aplicacao definir qual

o modo em que pretende executar um pedido (online ou offline) definindo o valor

de verdade da propriedade enabled

18

Estado da arte

Database

O modulo Database permite guardar dados da web application assegurando a

sua persistencia Os dados sao guardados de forma relacional no disco rıgido do uti-

lizador2 de acordo com o modelo de seguranca estabelecido pelo Gears3 significando

que uma aplicacao nao pode aceder a conteudos fora do seu domınio

WorkerPool

Nos web browsers uma operacao pesada de computacao pode tornar a interface

lenta e tornar menos agradavel a experiencia do utilizador O modulo WorkerPool

permite correr operacoes em background sem bloquear a interface com o utilizador

Os scripts executados numa WorkerPool nao activam os mecanismos de seguranca

do browser que mostram a mensagem ldquoA script on this page may be busy or may

have stopped respondingrdquo

O WorkerPool comporta-se como um conjunto de processos em vez de threads

Os Workers nao partilham qualquer estado de execucao o que significa que uma

alteracao a uma variavel num Worker nao afecta em nada a execucao de outro

Worker Alem disso os Workers nao herdam automaticamente nenhum codigo dos

seus pais Cada Worker e membro de um WorkerPool e os Workers podem in-

teragir entre si enviando mensagens em formato de texto ou JSON No entanto ha

tambem algumas limitacoes os Workers nao tem acesso ao DOM e objectos como

window ou document nao se encontram acessıveis Isto e consequencia de os Workers

nao partilharem o estado de execucao Mas tem acesso a todas as funcoes built-in

do Javascript A maioria das funcionalidades do Gears pode tambem ser acedida

atraves de uma variavel global especial definida como googlegearsfactory Para

outras funcionalidades especıficas os Workers podem ldquopedirrdquo a pagina principal para

continuar a execucao atraves do envio de mensagens

Outras funcionalidades

bull HttpRequest ndash Este modulo implementa a especificacao W3C XmlHttpRe-

quest definida em [vK08] tornando-a disponıvel para os workers e para a

pagina principal

bull Timer ndash Este modulo implementa a especificacao de timers tal como descrito

por [Hic08] e torna-os disponıveis para os workers e para a pagina principal

2Consultar httpcodegooglecomapisgearsapi_databasehtmldirectories3Consultar httpcodegooglecomapisgearssecurityhtml

19

Estado da arte

bull Factory ndash Esta classe e utilizada para instanciar todos os outros objectos da

API do Gears atraves do seu metodo create Este metodo pode ser utilizado

com os seguintes parametros

ndash betadatabase

ndash betahttprequest

ndash betalocalserver

ndash betatimer

ndash betaworkerpool

312 Goggle Gears em dispositivos moveis

O Gears esta tambem disponıvel em dispositivos Windows Mobile 5 e 6

Os dispositivos moveis estao pela sua natureza frequentemente desconectados

da Internet Mesmo quando possuem uma ligacao as latencias na transferencia de

dados em redes moveis tornam as aplicacoes pouco fluıdas mas o Gears permite

ultrapassar este obstaculo

O Gears funciona exactamente da mesma forma em dispositivos moveis equipados

com o Windows Mobile 5 e 6 como num computador comum Se uma aplicacao tiver

sido implementado com suporte para o Gears entao tambem estara preparada para

ser executada num dispositivo movel mas as limitacoes dos browsers disponıveis

para dispositivos moveis tem que ser consideradas Isto significa prever as condicoes

que permitam uma boa usabilidade devido aos pequenos ecras destes dispositivos

bem como o seu suporte limitado dos padroes do DOM CSS e JavaScript

32 Adobe AIR

O Adobe AIR4 e um runtime compatıvel com diversos browsers e sistemas opera-

tivos que pretende dar aos programadores a possibilidade de combinar diversas tec-

nologias de producao de conteudos para a Internet no desenvolvimento de Rich Inter-

net Application (RIA)s O Adobe AIR mantem uma relacao com o browser mas es-

tende as suas capacidades e tecnologias permitindo o desenvolvimento de aplicacoes

tambem para o ambiente de trabalho com janelas em tudo semelhantes as do sis-

tema operativo Segundo a Adobe o objectivo e complementar o browser dando

aos utilizadores (mas essencialmente aos programadores e equipas de desenvolvi-

mento) a escolha sobre como distribuir as suas aplicacoes Para este efeito o Adobe

AIR tem uma aproximacao diferente do Gears Em vez de ldquoestenderrdquo o browser

acrescentando-lhe funcionalidades o AIR permite tambem o desenvolvimento de

4Adobe - httpwwwadobecomproductsair

20

Estado da arte

aplicacoes que se destinam a ser executadas fora do ambiente do browser mas uti-

lizando as tecnologias comuns da Internet (por exemplo HTML CSS JavaScript

Flash Flex)[CDGH08]

A utilizacao desta tecnologia permite utilizar o browser ou o proprio runtime

Adobe AIR como plataforma de execucao da aplicacao

Na Tabela 31 faz-se uma comparacao das funcionalidades disponıveis de acordo

consoante se escolha o browser ou o desktop como plataforma base para a aplicacao

Uma vez que as aplicacoes Adobe AIR na plataforma desktop tem um caracter

persistente (sao instaladas no computador do utilizador) o Adobe AIR tem um

modelo de seguranca que se assemelha com o das tradicionais aplicacoes desktop

[Ada08] Este modelo e analisado nas seccoes 321 e 322 O ambiente em que

e executado o browser e restringido a execucao de web applications que podem

ser de varias origens (incluindo de origens anonimas ou sem confianca) O Adobe

AIR proporciona acesso a capacidades como acesso a ficheiros que necessitam da

confianca do utilizador

bull HTML ndash O desenvolvimento de aplicacoes para o Adobe AIR pode ser feito

com recurso a tecnologias de HTML e Ajax comuns utilizando as linguagens

de markup existentes distribuıdas como texto e interpretadas em execucao

(runtime)

bull Flash ndash Outra alternativa sera a utilizacao da linguagem Flash Permite a

renderizacao de graficos vectoriais e audiovıdeo com suporte nativo Utiliza

ActionScript para adicionar maior interactividade com o utilizador

bull Flex ndash O Flex e uma framework open source para o desenvolvimento de RIAs

usando Flash As aplicacoes Flex sao na realidade Flash sendo a principal

diferenca o ambiente de desenvolvimento

Como resultado uma aplicacao AIR podera ser implementada

bull Baseada em Flash ou Flex (aplicacoes cujo conteudo base e em ShockWave

Flash (SWF))

bull Baseada em Flash ou Flex tambem com HTML ou Portable Document Format

(PDF) Aplicacoes cujo conteudo de base e em FlashFlex (SWF) com HTML

(HTML JavaScript CSS) ou conteudo PDF incluıdo

bull Baseada em HTML Aplicacoes cujo conteudo base e em HTML Javascript

CSS

bull Baseada em HTML utilizando tambem FlashFlex ou PDF

21

Estado da arte

Os utilizadores interagem com uma aplicacao AIR da mesma forma que interagem

com outras aplicacoes com janelas nativas do seu sistema operativo O runtime e

instalado uma vez no computador do utilizador e a partir desse momento todas as

aplicacoes AIR terao o mesmo aspecto que qualquer outra aplicacao para o desktop

321 Seguranca

Permitir que uma web application aceda ao disco de armazenamento do utilizador

pode comprometer seriamente a sua seguranca Neste sentido o Adobe AIR tem

suporte para assinaturas digitais (Secure Sockets Layer (SSL)) que podem ser com-

pradas pelas equipas de desenvolvimento que o desejem e cujos certificados serao

apresentados ao utilizador no momento da instalacao Um outro aspecto ainda

relativo a seguranca e o mecanismo de isolamento de cada ambiente (sandbox )

322 Assinatura do codigo

O runtime AIR exige que todas as aplicacoes estejam digitalmente assinadas As

assinaturas digitais de codigo sao um processo que visa garantir a integridade da

aplicacao e a identidade do seu autor no momento da instalacao As equipas de

desenvolvimento podem ldquoassinarrdquo uma aplicacao utilizando um certificado atribuıdo

por uma Entidade Certificadora (Certification Authority) ou atraves de um certifi-

cado individual (self signed certificate) Neste momento o Adobe AIR suporta como

entidades certificadoras a Verisign e a Thawte [Ado08]

O instalador apresenta o nome de quem publica a aplicacao quando o codigo tiver

sido assinado com um certificado que apresente confianca ou que esteja encadeado

com um certificado que tenha ja sido aceite no computador em que se esta a instalar

a aplicacao

As equipas de desenvolvimento podem tambem assinar as aplicacoes com um

certificado auto-atribuıdo (um certificado criado por elas proprias) mas neste caso

o instalador apresentara estas aplicacoes como sendo de uma origem nao verificada

O AIR utiliza a infraestrutura publica de chaves [Ent07] suportada pelo arquivo

local do sistema operativo Para que a origem da aplicacao seja reconhecida o

computador onde a aplicacao AIR esta a ser instalada tem que confiar directamente

no certificado que foi utilizado para assinar a aplicacao ou confiar num certificado

que esteja num encadeamento logico de certificados confiados e que se ligue desta

forma ao certificado utilizado para assinar a aplicacao

Todas as aplicacoes AIR tem caracterısticas em comum independentemente da

tecnologia utilizada para o seu desenvolvimento (HTMLFlexFlash) No ambito

de uma aplicacao AIR existem um conjunto de APIs que estao disponıveis e que

tornam possıvel o acesso ao sistema local (leitura e escrita) e a recursos de rede que

22

Estado da arte

de outra forma nunca estariam acessıveis a partir de uma web application comum

Cada aplicacao AIR possui tambem diferentes nıveis de isolamento chamados secu-

rity sandboxes dependendo do tipo de conteudo que esta a ser carregado e do seu

objectivo

bull Isolamento ao nıvel da aplicacao5 ndash E a raiz de cada aplicacao AIR Este

nıvel de isolamento permite o acesso a APIs privilegiadas e especıficas do

AIR Em contrapartida e negado o acesso a algumas APIs que poderiam ser

facilmente utilizadas de forma maliciosa contra o utilizador final Importacao

dinamica de conteudos remotos e geralmente proibido e as tecnicas e mecan-

ismos de geracao dinamica de codigo sao fortemente restringidas Apenas

conteudo carregado directamente da directoria base da aplicacao podera ser

colocado neste nıvel de isolamento

bull Isolamento nao especıfico da aplicacao6 ndash contem todo o outro conteudo

que nao tenha sido carregado directamente para o isolamento da aplicacao

Isto inclui conteudo local e remoto Este tipo de conteudo nao tem acesso

directo as APIs do AIR e rege-se pelas mesmas regras tal como se tivesse sido

carregado por um browser a partir da mesma localizacao (por exemplo HTML

carregado a partir de um domınio remoto comporta-se da mesma forma que se

fosse acedido a partir do browser)

33 Mozilla Prism

331 XML User Interface Language

O eXtensible User Interface Language (XUL) e uma linguagem de anotacao

baseada em XML desenvolvida pela Mozilla Foundation que opera em aplicacoes

Mozilla multi plataforma tal como o Firefox O motor Gecko e a unica imple-

mentacao completa desta linguagem que foi desenhada sobre padroes web comuns

como CSS JavaScript e o DOM e permite o desenvolvimento de interfaces graficas

utilizando elementos pre-definidos tais como window box page textbox radio

button entre outros Infelizmente o XUL nao possui qualquer especificacao formal

ou implementacoes de inter-operabilidade para outros motores que nao o Gecko No

entanto a sua implementacao e licenciada em codigo aberto pelas licencas GNU Gen-

eral Public License (GPL) GNU Lesser General Public License (LGPL) e Mozilla

Public License (MPL)

Enunciam-se algumas caracterısticas desta linguagem

5NT application sandbox6NT non-application sandbox

23

Estado da arte

Liguagem de anotacao poderosa baseada em componentes (widgets) O ob-

jectivo do XUL e permitir a construcao de aplicacoes multi-plataforma em

claro contraste com o Dynamic HyperText Transfer Protocol (DHTML) que se

destina ao desenvolvimento de paginas web Por esta razao o XUL esta orien-

tado a componentes tais como janelas botoes e etiquetas em vez de paginas

cabecalhos de texto e ligacoes de hipertexto Investir tempo e esforco para

atingir este mesmo resultado em aplicacoes baseadas em DHTML compromete

frequentemente a complexidade e desempenho da aplicacao

Baseado em padroes O XUL e um dialecto XML baseado no padrao W3C XML

10 As aplicacoes escritas em XUL sao tambem baseadas em especificacoes

W3C adicionais como HTML 40 CSS DOM nıvel 1 e 2 JavaScript 15

incluindo ECMA-262 Edition 3 (ECMAscript)

Portabilidade entre plataformas Tal como HTML o XUL foi desenhado para

ser independente da plataforma em que e utilizado tornando as aplicacoes

facilmente portaveis entre sistemas operativos nos quais o Mozilla e suportado

Uma vez que o XUL oferece um nıvel de abstraccao dos componentes graficos

de interface que disponibiliza implementa a premissa ldquoum codigo para todas

as plataformasrdquo A interface grafica de todos os produtos centrais Mozilla

(browser instant messenger livro de enderecos) e escrita em XUL com um

unico codigo base que suporta todas as plataformas Mozilla

Separacao entre o nıvel de apresentacao e a logica de negocio Uma das

maiores preocupacoes no desenvolvimento para a Internet e a forte ligacao

entre estas duas camadas (interface e logica) Isto constitui um problema sig-

nificativo no desenvolvimento de grandes aplicacoes especialmente quando o

desenvolvimento e feito em ambientes de equipa porque as capacidades de de-

senvolvimento destas duas partes da aplicacao estao muitas vezes espalhadas

por diferentes elementos O XUL permite uma clara distincao entre a definicao

da aplicacao cliente e da logica de implementacao (XUL eXtensible Binding

Language (XBL) e JavaScript) apresentacao (CSS e imagens) internacional-

izacao (Document Type Definitions (DTDs) e etiquetas de texto em lınguas

especıficas guardados em ficheiros properties) O esquema grafico e apre-

sentacao de uma aplicacao XUL pode ser alterado de forma independente da

sua logica ou implementacao e a aplicacao pode ainda ser traduzida (interna-

tionalization) de forma independente da sua logica implementacao ou apre-

sentacao Este grau de separacao resulta em aplicacoes que sao mais faceis de

manter pelos programadores e facilmente adaptadas por designers e tradutores

24

Estado da arte

Facil adaptacao Outro benefıcio que advem do nıvel de separacao entre logica

de negocio e apresentacao oferecido pelo XUL e a facilidade com que se pode

adaptar uma aplicacao para diferentes clientes ou grupos de utilizadores Um

programador pode utilizar a mesma aplicacao base e adapta-la consoante as

necessidades atraves de diferentes temas (skins) e ficheiros de lınguas Desta

forma uma aplicacao escrita e desenvolvida em Ingles pode ser rapidamente

traduzida para Portugues e distribuıda com outra aparencia mais apropriada

ao cliente alvo

332 Prism

O Mozilla Prism e um browser simplificado e ldquointerpretadorrdquo de XUL (tambem

designado por XULRunner) que acolhe web applications sem a interface grafica ha-

bitual de um browser Baseia-se num conceito designado por Site Specific Browser

(SSB) Um SSB e uma aplicacao com um browser embebido desenhado para exe-

cutar apenas uma web application Nao possui os menus e barras de ferramentas

habituais Um SSB tem uma integracao com o sistema operativo e com o desktop

muito mais estreita do que uma web application acedida atraves de um browser uma

vez que e executado em janela propria

O Prism resulta de uma experiencia da Mozilla e visa reduzir as diferencas entre

as desktop applications tradicionais e as web applications Um dos aspectos focados e

a experiencia do utilizador Numa apresentacao oficial e dito que ldquo[o Prism] pretende

ser uma ponte entre as diferencas que existem entre as aplicacoes tradicionais de

desktop e as web applications explorando novos modelos de usabilidade enquanto

que a linha que as separa se continua a definirrdquo [Lab07]

34 HTML 5

A especificacao HTML 5 [Hic08] que se encontra em fase de desenvolvimento

pelo grupo WHATWG pretende ser uma norma de substituicao dos padroes HTML

4 XHTML 1x e do DOM2 HTML Uma das propriedades que o distingue das tec-

nologias que pretende substituir e precisamente o suporte para OWA e armazena-

mento de dados no cliente de uma forma relacional Nao sendo propriamente uma

tecnologia ndashmas antes uma especificacao ndashe aqui mencionada por ter servido como

referencia a diversas implementacoes de funcionalidades offline e por se considerar

que venha a ter um impacto significativo nas implementacoes de diversos browsers

Dion Almaer defendeu no seu blogue que o Gears era uma implementacao do

HTML 5 No seu artigo ldquoGears as a bleeding-edge HTML 5 implementationrdquo [Alm08]

o autor diz que ambos ndasho Gears e o HTML 5 ndashpretendem dar a web caracterısticas

25

Estado da arte

semelhantes e nao encontrar motivo de ldquocompeticaordquo entre as duas mas que en-

quanto o HTML 5 e uma especificacao o Gears e uma implementacao

No entanto tambem e verdade que o HTML 5 cobre muitos outros pontos para

alem das OWA que saem completamente fora do ambito do Gears Se esta es-

pecificacao atingir um estado de maturidade que possibilite a sua adopcao pelos

principais browsers tornando nativo do browser o suporte OWA entao deixara de

fazer sentido a existencia de uma extensao como o Gears

A especificacao HTML 5 disponibiliza duas APIs relevantes para o tema das

OWA

1 Uma base de dados baseada em SQL que permite o armazenamento de dados

do lado do cliente

2 Uma ldquocacherdquo HTTP que garante a disponibilidade das aplicacoes mesmo quando

o utilizador nao possui uma ligacao a Internet

Estas caracterısticas sao as bases da tecnologia das OWA e tem correspondencia

com os pontos analisados nas seccoes 311 e 311

35 Web applications que usam funcionalidades offline

Nesta seccao apresentam-se algumas web applications que actualmente disponi-

bilizam funcionalidades offline Estas aplicacoes foram escolhidas para uma analise

mais pormenorizada por utilizarem o Gears que tal como descrito na seccao 4 foi

a tecnologia escolhida para o projecto

351 Google Reader e Google Docs

O Google Reader7 e um leitor de feeds RSS Permite gerir a subscricao de varios

sites simultaneamente que disponibilizem conteudos neste formato e foi a primeira

web application da Google com uma versao offline publicamente acessıvel (desde

Junho de 2007)

O Google Reader implementa o modo ldquoutilizador deciderdquo oferecendo na sua

interface um botao que permite alternar entre os modos online e offline

O Google Docs8 e uma web application que permite a criacao e edicao de doc-

umentos de texto folhas de calculo e apresentacoes Era ja publico desde Janeiro

de 2008 que o Google estava a desenvolver uma versao OWA desta aplicacao mas o

acesso a uma versao experimental so foi possıvel a partir de 31 de Maio de 2008

7Google Reader - httpreadergooglecom8Google Docs - httpdocsgooglecom

26

Estado da arte

A implementacao das funcionalidades offline nestas duas aplicacoes seguiu difer-

entes aproximacoes principalmente porque o Google Reader apresenta ao utilizador

informacoes que sao fornecidas por fontes externas enquanto que no Google Docs

a informacao e criada e editada pelo utilizador sobre a forma de documentos

A diferente origem da informacao implica que no Google Reader seja necessario

prever casos de excepcao tal como existirem demasiados itens que necessitam de

ser transferidos para o cliente Nao observar este ponto causa um problema grave

de usabilidade e para evitar tempos de espera demasiado longos e uma interface

com pouca capacidade de resposta as accoes do utilizador o Google Reader apenas

transfere para o cliente os dois mil itens mais recentes na transicao para o modo

offline

352 Remember the Milk

O Remember The Milk9 e uma web application desenvolvida por uma equipa

Australiana que proporciona funcionalidades de agenda gestao de tempo e de tare-

fas e foi uma das primeiras aplicacoes independentes do Google a adoptar o Gears

para acessos em modo offline Permite que os seus utilizadores facam uma gestao

de tarefas agrupando-as em listas adicionando-lhes campos de informacao adicional

ou dando-lhes informacao geografica (recorrendo ao servico Google Maps10) Entre

a sua lista de funcionalidades encontra-se ainda a possibilidade de importar e ex-

portar eventos no formato iCalendar (ics) etiquetas (tags) em tarefas publicacao

Really Simple Syndication (RSS) e partilha de categorias de tarefas de acordo com

diferentes nıveis de permissoes de acesso definidos pelo utilizador

353 MySpace e WordPresscom

O MySpace uma das maiores social networks na Internet anunciou recente-

mente que vai disponibilizar uma versao do seu cliente de e-mail que utiliza o Gears

para acelerar o seu desempenho Numa fase inicial estara disponıvel apenas para

utilizadores que tenham cinco mil ou mais mensagens na sua caixa de correio e

permitira efectuar pesquisas muito mais rapido que a sua versao online

O servico de blogs Wordpresscom anunciou tambem o inıcio da utilizacao desta

tecnologia com o fim de melhorar o desempenho A versao que utiliza esta tecnologia

descarrega e armazena no cliente um conjunto de imagens e scripts que passam a

ter preferencia sobre os seus congeneres online e que permitem acelerar o processo

de carregamento da aplicacao e visualizacao de blogs

9Remember The Milk ndash httpwwwrememberthemilkcom10Google Maps ndash httpmapsgooglecom

27

Estado da arte

O MySpace e o Wordpresscom sao dois exemplos da utilizacao da tecnologia

OWA para optimizacao de web application ja existentes Sem pretenderem disponi-

bilizar uma versao que seja totalmente offline fazem uso do Gears para armazenar no

cliente parte dos recursos frequentemente acedidos na visualizacao das suas paginas

36 Escolha da tecnologia

Apos a analise das tecnologias apresentada nas seccoes 31 a 34 foi necessario es-

tudar a adequacao de cada uma delas ao projecto em questao Desde logo e possıvel

observar que nem todas se dedicam apenas a OWA Por exemplo o Adobe AIR

apesar de ter suporte para OWA apenas disponibiliza algumas das funcionalidades

identificadas como mais indicadas para a execucao do projecto quando utilizado

na sua vertente desktop tal como exposto na Tabela 31 mas a utilizacao desta

vertente implicaria o desenvolvimento de novas interfaces e de novas formas de co-

municacao (troca de mensagens XML ou JSON) A vertente web do Adobe AIR

foca-se mais especificamente nas Rich Internet Applications e permite a reutilizacao

do codigo ja existente (exigindo naturalmente a sua adaptacao e a implementacao

das funcionalidades pretendidas)

A tecnologia escolhida para a realizacao deste trabalho foi o Gears sendo que

um dos principais factores a influenciar esta opcao foi a liberdade introduzida pela

sua licenca Berkeley Software Distribution (BSD)11

Considerou-se o funcionamento desta ferramenta extremamente adequando a

aplicacao no WOW uma vez que o seu principal objectivo e precisamente tornar

possıvel a execucao offline de uma pagina web e por virtude deste facto o Gears tem

uma API concisa e de simples aplicacao pratica uma vez que nao possui quaisquer

outros elementos distractores O funcionamento do seu ManagedResourceStore ex-

emplificado na Figura 31 com a capacidade de actualizacao de recursos definidos

num ficheiro manifesto especificado em JSON pesou tambem nesta decisao

11Sobre a licenca BSD consultar httpwwwopensourceorglicensesbsd-licensephp e http

wwwlinfoorgbsdlicensehtml

28

Estado da arte

Figura 31 Esquema UML do processo efectuado pelos recursos do Gears do tipoManagedResourceStore para a actualizacao dos conteudos definidos no ficheiro manifesto

29

Estado da arte

Funcionalidade RIAs no browser RIAs no desktop

Disponibilidadeda aplicacao

As aplicacoes podem ser facil-mente exploradas e utilizadas

As aplicacoes quando instal-adas tem maior grau de fun-cionalidades e persistencia

Instalacao Nao e necessario qualquer tipode instalacao

As aplicacoes sao instaladasatraves do browser ou descar-regadas e instaladas comouma aplicacao tradicional

Actualizacoes Aplicacoes sao actualizadascarregando conteudos paraum website

O AIR disponibiliza uma APIque permite que as aplicacoessejam actualizadas de umaforma

Sistemas opera-tivos suportados

As aplicacoes podem ser exe-cutadas em diversos sistemasoperativos e browsers

As aplicacoes sao multi-plataforma e podem serinstaladas e executadas emdiversos sistemas operativos ebrowsers

Linguagens deprogramacao

Javascript e disponibilizadopelo browser e ActionScripte disponibilizado pelo AdobeFlash Player

Maquinas virtuais deJavascript e ActionScriptcompatıveis com o browser

Capacidade deexecucao embackground

As RIAs podem ser execu-tadas numa janela do browser

As aplicacoes podem ser ex-ecutadas em background edisponibilizar notificacoes talcomo uma aplicacao tradi-cional

Persistencia A actividade esta limitada asessao do browser Quando obrowser e encerrado toda ainformacao e descartada

As aplicacoes sao instaladas eestao disponıveis no desktopPodem armazenar informacaolocalmente e estao disponıveisoffline

Integracao com odesktop

Integracao com o desktop lim-itada devido a restricoes im-postas pelo browser

As aplicacoes podem acederao sistema de ficheiro ao clip-board eventos notificacoesetc

Controlo da inter-face com o uti-lizador

As aplicacoes sao acedidasatraves de uma janela dobrowser que tem os seusproprios controlos e visualgrafico

As aplicacoes tem um vi-sual grafico proprio em janelapropria

Armazenamentode dados

As aplicacoes tem armazena-mento limitado que pode serreescrito pelo browser

As aplicacoes tem acesso a to-talidade do espaco disponıvellocalmente e a uma base dedados com a possibilidade deencriptacao

Tabela 31 Comparacao das funcionalidades oferecidas pelo Adobe AIR para as platafor-mas web e desktop

30

Estado da arte

Aplicacao Modo de execucao utilizadoGoogle Reader Utiliza o modo ldquoutilizador deciderdquo disponibilizando

ao utilizador um botao para alternar entre os modosonline e offline Como lida com informacao recol-hida de fontes externas de natureza frequentementeefemera o processo de sincronizacao apenas transfereos dois mil itens mais recentes quando passa ao es-tado offline Neste modo sao ainda guardadas in-formacoes de itens lidos e etiquetas atribuıdas quesao sincronizadas com o servidor quando o utilizadorvoltar a activar estado online

Google Docs Utiliza o modo ldquoaplicacao deciderdquo permitindo que outilizador edite os conteudos de documentos de textofolhas de calculo e de apresentacoes independente-mente do estado da ligacao desde o momento em queas funcionalidades offline sao activadas A aplicacaofaz pequenas sincronizacoes com o servidor sempre quenecessario

Remember the Milk Utiliza um modo hıbrido entre ldquoaplicacao deciderdquo eldquoutilizador deciderdquo A aplicacao encarrega-se da sin-cronizacao de dados mas disponibiliza um controlona sua interface que permite despoletar manualmenteeste processo para situacoes em que o utilizador fez al-teracoes recentes e pretende usufruir das capacidadesoffline imediatamente

MySpace O MySpace anunciou a utilizacao de mecanismos dearmazenamento de dados no cliente com recurso atecnologias OWA para melhorar o desempenho doseu cliente web de correio electronico nomeadamenteno que diz respeito a operacoes de pesquisa e or-denacao Inicialmente esta funcionalidade estara ape-nas disponıvel para utilizadores com cinco mil ou maismensagens na sua caixa de correio mas nao e aindaclaro se sera disponibilizada uma versao totalmenteoffline

Tabela 32 Resumo da utilizacao de tecnologias OWA em algumas web applications con-sideradas na analise do estado da arte

31

Estado da arte

32

Capıtulo 4

Desenvolvimento

Neste capıtulo introduz-se a aplicacao WOW e apresenta-se o estudo que foi

feito da adequacao de cada tecnologia para a implementacao da funcionalidade of-

fline nesta plataforma Fazem-se diversas consideracoes sobre opcoes a tomar na

concepcao de OWAs e problemas comuns na sua implementacao bem como sug-

estoes para os resolver O WOW e uma aplicacao ja existente de gestao de ordens

de trabalho e do fluxo de tarefas numa empresa ou organizacao

41 Como ficar offline

Na maior parte das web applications de hoje nao existe uma camada de dados

real A aplicacao exemplificada na Figura 41 ao longo da sua execucao acede

directamente a sua unica fonte de dados (o servidor) atraves de chamadas Ajax sem

que exista uma separacao clara destas duas camadas

Para que uma web application seja capaz de ser executada sem uma ligacao

activa a Internet e mantenha o seu caracter dinamico torna-se necessario incluir

Figura 41 Exemplo de uma arquitectura de uma web application sem uma camada deabstraccao de dados Figura adaptada de http gears google com

33

Desenvolvimento

Figura 42 Exemplo de uma arquitectura de uma web application com uma camada deabstraccao de dados Figura adaptada de http gears google com

um mecanismo de armazenamento de dados local seja uma base de dados ou a

capacidade de acesso ao disco No entanto este mecanismo introduz dois problemas

1 Qual das fontes de dados utilizar quando um utilizador faz um pedido de

informacao

2 A necessidade de implementar uma camada de acesso a dados que seja coerente

quer se use o servidor remoto ou local

Por exemplo em vez de a aplicacao Ajax fazer um pedido relativo as contas de

todos os utilizadores em formato JSON directamente ao servidor remoto podera ao

inves fazer o pedido a um objecto intermedio da camada de dados Este objecto

demonstrado na Figura 42 sera responsavel por implementar uma interface de

acesso a base de dados e retornar um objecto JavaScript com uma representacao da

resposta do servidor

Mas a existencia de uma segunda fonte de dados torna recomendavel tambem

a implementacao de uma camada de data switching que em funcao da existencia

de conexao a Internet e da necessidade de actualizacao dos dados decide se faz o

pedido ao servidor remoto ou se fornece os dados presentes localmente Este objecto

apresentado na Figura 43 decidira de forma transparente para o utilizador se le ou

escreve os dados localmente ou se os enviapede ao servidor remoto e pode tambem

iniciar o processo de convergencia de dados e de resolucao de conflitos

411 Funcionalidades disponıveis em modo offline

Por razoes praticas e provavel que nem todas as funcionalidades da aplicacao

possam ser disponibilizadas em modo offline E necessario escolher quais as fun-

cionalidades a disponibilizar no modo offline da aplicacao e implementar a logica

que decide quando utilizar a base de dados local ou o servidor remoto Apesar do

acesso a base de dados local ser muito mais rapido do que aceder ao servidor o

acesso local nem sempre e preferido Ha varias razoes que podem tornar necessario

escolher o acesso ao servidor em vez do acesso local

34

Desenvolvimento

Figura 43 Exemplo de uma arquitectura de uma web application com uma camada deabstraccao de dados e um data switch Figura adaptada de http gears google com

1 A informacao pode ter uma natureza efemera e nao fazer sentido guarda-la

localmente Exemplo dados em tempo real da bolsa de valores de Lisboa

2 Algumas aplicacoes lidam com informacao que so faz sentido na presenca de

uma ligacao Exemplo Instant Messaging

3 A aplicacao podera escolher apenas guardar a informacao acedida mais fre-

quentemente Exemplo para o utilizador poder alterar a lıngua de apre-

sentacao da aplicacao os conteudos terao que ser guardados em todas as

lınguas disponibilizadas pela aplicacao O custo de implementacao de algu-

mas funcionalidades pode nao compensar o benefıcio

4 A capacidade de processamento ou de armazenamento de dados pode inviabi-

lizar algumas funcionalidades offline Exemplo se uma dada funcionalidade

necessita de uma capacidade de armazenamento de dados para alem do razoavel

de um computador pessoal para ser util (visualizador de mapas)

42 Modos de execucao

Um aspecto que e necessario estudar para qualquer web application que se deseje

disponibilizar offline prende-se com tres modos de execucao que devem ser consid-

erados

1 Utilizador decide o modo de execucao A aplicacao tem modos distintos

de execucao para os estados online e offline geralmente indicados na interface

com o utilizador O utilizador e informado do estado da ligacao e participa na

alteracao de estado de execucao da aplicacao interagindo com a sua interface

2 Aplicacao decide o modo de execucao Pode ser implementado na propria

aplicacao um mecanismo de deteccao do estado da ligacao (por exemplo atraves

35

Desenvolvimento

de chamadas Ajax periodicas) transitando de estado e sincronizando automati-

camente Desta forma o utilizador nao precisa de participar na alteracao de

estado a menos que exista um conflito de dados que requeira a sua atencao

3 Aplicacao assume sempre o estado offline Outra hipotese sera imple-

mentar uma web application que assume sempre estar na ausencia de uma

ligacao ao servidor de dados Esta aplicacao responde aos pedidos do uti-

lizador efectuando pedidos de informacao ao servidor mas nao dependendo

de uma resposta valida para mostrar a informacao que ja tinha disponıvel an-

teriormente A sincronizacao de dados com o servidor e tentada sempre que

existam dados para submeter e uma accao do utilizador

421 Modo ldquoutilizador deciderdquo

Neste modo de execucao quando a aplicacao esta online comunica com o servidor

remoto quando esta offline comunica com a base de dados local A informacao tem

que ser sincronizada sempre que se muda de modo A principal vantagem desta opcao

e que e a mais simples de implementar mesmo para uma aplicacao ja existente e

portanto uma forma expedita de disponibilizar uma OWA No entanto tem tambem

algumas desvantagens que devem ser consideradas

1 O utilizador tem que se lembrar de fazer a alteracao de estado de execucao

Caso contrario podera estar a trabalhar inadvertidamente numa versao offline

com dados antigos ou nao ter a informacao necessaria se perder subitamente

a ligacao

2 Se a ligacao for intermitente o utilizador tera ou que escolher um dos modos

de execucao ou estar constantemente a trocar

3 Uma vez que a base de dados nao esta sempre actualizada nao podera ser

utilizada para melhorar a rapidez de execucao da aplicacao quando em modo

online

422 Modo aplicacao decide

A deteccao do estado da ligacao pode ser implementada atraves de um pedido

assıncrono ao servidor tal como ilustrado na Figura 44 O resultado deste pedido

definira o estado online (em caso de sucesso) ou offline (em caso de falha) A

sincronizacao de dados podera ser feita sempre que ocorra uma transicao do es-

tado offline para o estado online No entanto este metodo nao se revela eficiente

36

Desenvolvimento

Figura 44 Esquema grafico ilustrando uma OWA executando no browser utilizando ummodo de execucao do tipo ldquoaplicacao deciderdquo com deteccao automatica do estado daligacao via pedidos Ajax assıncronos a cada cinco segundos

para grandes aplicacoes uma vez que requer a troca de mensagens demasiado fre-

quentes com o servidor que se destinam exclusivamente a monitorizacao do estado

da ligacao

423 Modo ldquoaplicacao assume o estado offlinerdquo

Uma aplicacao transparente funciona assumindo sempre que esta em modo of-

fline ou pelo menos que pode perder a ligacao a qualquer momento Neste modo

tira-se o maximo partido do armazenamento local e fazem-se pequenas mas contınuas

sincronizacoes com o servidor sempre que este esteja disponıvel A sincronizacao de

dados tambem e feita sempre que se volta ao estado online

As vantagens de uma web application transparente sao as seguintes

bull Uma melhor experiencia para o utilizador uma vez que este nao tem que se

preocupar com o estado da ligacao ou com a transicao de estados

bull A aplicacao funciona de forma coerente mesmo que a ligacao seja intermitente

bull Uma vez que o armazenamento local e mantido actualizado pode ser utilizado

para melhorar o desempenho da aplicacao

Foram identificadas as seguintes desvantagens

bull E mais difıcil de implementar e a sincronizacao acarreta cuidados especiais

bull E necessario um cuidado adicional para evitar que as operacoes de sincronizacao

frequentes que ocorrem automaticamente nao afectem os tempos de resposta

da aplicacao

bull Os testes a aplicacao sao mais complexos uma vez que a sincronizacao de dados

nao ocorre em resposta a uma accao do utilizador

37

Desenvolvimento

43 Sincronizacao de dados

A sincronizacao de dados consiste na capacidade de identificar e transferir pe-

riodicamente a versao mais actual dos dados entre o cliente e o(s) servidor(es)

Independentemente do modo de execucao escolhido e mesmo do estado da ligacao

do utilizador a informacao armazenada localmente e a informacao armazenada no

servidor estarao por vezes dessincronizadas Isto podera acontecer sempre que por

exemplo

bull O utilizador faz alteracoes em modo offline

bull A informacao e partilhada e pode ser alterada por uma entidade externa

bull A informacao e fornecida por uma entidade externa

Resolver estas diferencas de forma a que a informacao local e remota encontrem

a igualdade chama-se sincronizacao de dados Ha varias aproximacoes possıveis

para este efeito que dependem da natureza da aplicacao cada uma com vantagens

e desvantagens

A capacidade de suportar a mobilidade dos utilizadores torna-se cada vez um

ponto mais importante de uma web application Para uma organizacao de dimensao

global e vital garantir que os seus colaboradores tem acesso a mesma informacao

que tem disponıvel nos seus postos de trabalho mesmo quando estao fora Na maior

parte dos casos estes colaboradores terao acesso a um computador portatil um

desktop Smartphone ou PDA e atraves destes poderao ter acesso a sua informacao

directamente atraves de ligacoes encriptadas Virtual Private Network (VPN) de um

servidor web ou de outro mecanismo de rede

Esta solucao e simples de implementar mas infelizmente para a maioria dos

colaboradores com grande factor de mobilidade nao e satisfatoria As principais

desvantagens sao as seguintes

bull Requisitos de ligacao Para permitir que os utilizadores acedam a sua in-

formacao e necessario garantir a capacidade constante de comunicacao pelo

menos durante o tempo necessario que assegure a sua transferencia

bull Velocidade de ligacao sem persistencia de dados e em ligacoes de fraca

qualidade a usabilidade por vezes torna-se inaceitavel

bull Ponto crıtico de falha Com este tipo de solucao todos os utilizadores de-

pendem da base de dados que armazena informacao vital para o funcionamento

do cliente

38

Desenvolvimento

bull Scalability do servidor A medida que novos utilizadores sao adicionados ao

sistema o desempenho do servidor e afectado levando a necessidade de maior

capacidade de armazenamento eou processamento

De acordo com a documentacao da Microsoft Sync Framework [Mic08] uma

solucao alternativa consiste em implementar uma Occasionally Connected Appli-

cation (OCA) Uma OCA permite a um utilizador remoto continuar a aceder a

sua informacao mesmo depois de perder a ligacao mas em vez de recorrer a um

servidor recorre a informacao armazenada no seu dispositivo local Para preencher

localmente a informacao que o utilizador necessita uma OCA possui mecanismos

de sincronizacao de dados que sao oferecidos por esta framework

431 Quando sincronizar

Uma das solucoes mais simples de implementar passa por disponibilizar um

mecanismo manual que despoleta a sincronizacao Diz-se manual porque e o uti-

lizador que escolhe quando sincronizar e pode ser implementada simplesmente

fazendo o upload de toda a informacao para o servidor e depois fazendo o download

da copia mais recente da informacao antes de voltar a ficar offline Para que esta

seja uma opcao viavel e necessario que

bull O volume de dados seja suficientemente pequeno para que possa ser transferido

do servidor para o cliente num espaco de tempo aceitavel

bull Que o utilizador indique explicitamente que quer mudar para o estado offline

ou online pressionando um botao da interface

Contudo podem ser identificados alguns problemas relacionados com esta abor-

dagem

bull Os utilizadores nem sempre podem prever o estado das suas ligacoes A ligacao

pode-se perder subitamente ou ter um caracter intermitente

bull O utilizador pode esquecer-se de efectuar a sincronizacao

Outra opcao sera conjugar a sincronizacao de dados com o modo de execucao

transparente A sincronizacao ocorre automaticamente em background de forma

nao intrusiva para o utilizador A aplicacao comunica com o servidor regularmente

efectuando pequenas trocas de dados com o objectivo de manter o sincronismo da

informacao local e remota Esta abordagem pode ser implementada com pedidos

Ajax assıncronos e regulares ao servidor o que permite manter a interaccao com a

interface fluıda evitando bloqueios Estes pedidos sao feitos prevendo as situacoes

39

Desenvolvimento

de disponibilidade ou indisponibilidade (timeout) do servidor Uma outra opcao

sera permitir que o servidor comunique essas alteracoes utilizando Comet1 tal como

descrito em [Wil06] e [Rus06] As vantagens destas aproximacoes sao

bull A informacao esta disponıvel a qualquer altura que o utilizador decida ficar

offline ou que a ligacao seja acidentalmente perdida

bull O desempenho da aplicacao pode ser melhorado quando se estiver a utilizar

uma ligacao a Internet lenta uma vez que o acesso a dados locais e mais

eficiente do que a consulta de dados ao servidor

44 WOW

O WOW e uma plataforma integrada de gestao de ordens de trabalho ja ex-

istente e desenvolvida pela Critical Software SA a qual se pretende adicionar a

capacidade de execucao offline Esta aplicacao e extremamente dinamica e con-

figuravel com um conjunto extremamente rico de funcionalidades das quais se

destacam

bull Gestao de Ordens de Trabalho ndash suportando a gestao dos pedidos desde a

sua criacao ate ao seu fecho tomando em conta os diferentes tipos de pedidos

(ordens de trabalho pedidos de informacao melhorias resolucao de problemas

etc) e diferentes tipos de accoes possıveis para cada um (Figura 45)

bull Monitorizacao de alteracoes ndash Historico de mudancas anexos e estados criando

relatorios de alteracao automaticamente (o que por quem e quando)

bull Uso de Service Level Agreements (SLAs) ndash E possıvel associar a um pedido um

SLA que define qual o perıodo de tempo atribuıdo a resolucao de um pedido

controlando e agilizando a resolucao do mesmo

bull Utilizacao de queries de utilizador configuraveis que permitem acesso rapido

a determinadas ordens de trabalho de acordo com o filtro configurado (por

exemplo ldquoPara mimrdquo ldquoPara o Grupordquo ldquoPelo Grupordquo)

bull Gestao do relacionamento entre pedidos

bull Pesquisa e filtragem de ordens de trabalho

bull Exportacao de dados em formatos padrao (PDF DOC ou XLS)

bull Integravel com solucoes externas

40

Desenvolvimento

Figura 45 Detalhe de um conjunto possıvel de estados e respectivas transicoes para umadada ordem de trabalho no WOW desde a sua submissao no sistema ate a sua conclusaoem fecho ou cancelamento Esta figura representa apenas um exemplo ja que o mapa deestados para uma ordem de trabalho e dinamico e pode ser alterado por um administradorFigura retirada de uma brochura promocional do WOW Critical Software SA

A utilizacao de uma ferramenta deste tipo por parte de uma empresa ou orga-

nizacao oferece vantagens quer a gestao de topo quer aos colaboradores individuais

para os colaboradores individuais o WOW e uma aplicacao onde estao registadas

todas as tarefas contribuindo activamente para o desenvolvimento em ambientes

multi-tarefa e para a organizacao pessoal das tarefas de acordo com prioridades

Para a gestao de topo esta ferramenta permite obter uma visao global do estado da

organizacao em termos de tempo gasto por tarefa executada sendo uma mais valia

para a previsao e gestaoalocacao de recursos

45 Visao geral sobre a arquitectura do WOW

O WOW e interessante nao so do ponto de vista de produto como tambem do

ponto de vista de plataforma Existem diversos plug-ins que estendem as funcional-

idades do WOW e existem ate projectos que pretendem usar a arquitectura do

WOW para criar produtos com fins diferentes do inicial (por exemplo o WOW-

Storm ndash um sistema de registo e classificacao social de ideias)

De modo a conseguir ter essa expansibilidade a plataforma WOW assenta sob

uma arquitectura distribuıda modular e expansıvel com uma componente central

ndash o core ndash estruturado em camadas logicas E no core que se situam todas as

1O Comet e um conceito semelhante ao Ajax introduzido por Alex Russel mas no qual e o servidor quetoma a iniciativa de ldquoenviarrdquo os dados ao browser sem que este tenha que efectuar um pedido Tambem econhecido por Ajax Push Reverse Ajax ou HTTP Streaming

41

Desenvolvimento

funcionalidades base da aplicacao quer a nıvel logico funcional e de apresentacao

quer a nıvel de gestao e configuracao

E possıvel a execucao de varias instancias do core simultaneamente em servidores

distintos o que permite a alta escalabilidade e disponibilidade desta aplicacao A

consistencia dos dados fica sempre garantida atraves da partilha da base de dados

e pelo balanceamento dos pedidos uma vez que cada um e encaminhado para uma

unica instancia

O WOW apresenta tambem a vantagem de ser uma plataforma extensıvel E

possıvel adicionar novas caracterısticas a plataforma atraves de componentes que se

podem ser divididos em duas categorias plugins e connectors

Os plugins sao componentes que se encontram no mesmo no fısico que a aplicacao

partilhando do mesmo contexto de execucao do core Sao assim uma forma mais

directa de obter informacao da plataforma visto que nao possuem restricoes de

acesso aos dados nem dependencias externas A arquitectura deste componente tera

assim que permitir varias execucoes instanciadas cada uma associada a um core

Por outro lado os connectors sao componentes que se encontram distribuıdos

comunicando externamente com o core Quer a sua execucao quer a obtencao

dos dados estao assim dependentes de interfaces de comunicacao externas que a

plataforma disponibiliza Estes componentes ao contrario dos plugins sao instan-

ciados unicamente e recorrem ao protocolo de comunicacao Java Messaging Service

(JMS) para comunicar com o core

46 WOW Offline

Para alem das opcoes tomadas relativamente a tecnologia a utilizar surgiu

tambem a necessidade de optar por um dos modos de execucao apresentados na

seccao 42

Das tres opcoes possıveis foi o modo ldquoaplicacao assume o estado offlinerdquo descrito

na seccao 423 que mereceu a maior atencao uma vez que reune as vantagens de

uma experiencia mais positiva para o utilizador (uma vez que este nao tem que

participar activamente na alteracao do modo execucao como descrito na seccao 421)

e nao constitui uma sobrecarga excessiva para servidor (como o modo abordado na

seccao 422)

No entanto esta opcao comprometia a complexidade da implementacao para alem

dos objectivos propostos para este projecto e para cumprir o prazo dado foi tomada

a decisao de implementar o modo ldquoutilizador deciderdquo especificando apenas de forma

teorica o modo ldquoaplicacao assume o estado offlinerdquo

As caracterısticas do Gears foram ja descritas na seccao 31 Na Figura 47

mostra-se a sua forma de funcionamento quando integrado numa web application

42

Desenvolvimento

Nesta figura representa-se o modulo LocalServer do Gears como um ponto de de-

cisao Aqui sao testadas as condicoes que determinam se o pedido sera interceptado e

servido localmente ou se prossegue para uma maquina remota E tambem represen-

tada uma base de dados que corresponde ao modulo Database mas que podera nao

ser utilizada Este modulo tal como o modulo Workerpool tem caracter opcional

e sao utilizados consoante os requisitos da aplicacao

A plataforma WOW lida com mais dados do que e necessario passar para o

lado do cliente Em conformidade com o ja exposto na seccao 411 volta-se a

frisar que nao se pretende recriar toda a logica de negocio nem os conteudos da

base de dados no cliente pela sua complexidade e volume de dados Pretende-se

pelo contrario permitir que os utilizadores tirem partido da capacidade de poder

consultar as suas ordens de trabalho quando nao dispoe de uma ligacao transferindo

apenas o essencial para isto seja possıvel

A pagina inicial do WOW apresenta um resumo das ordens de trabalho abertas

ndash enviadas e recebidas ndash que se pretende permitir visualizar offline (ver Figura 46)

Como prova de conceito foi efectuada uma abordagem pragmatica das varias possi-

bilidades descritas na seccao 42

461 Modo ldquoaplicacao deciderdquo com deteccao automatica da ligacao

A primeira abordagem estudada para a disponibilizacao das funcionalidades of-

fline foi o modo ldquoaplicacao deciderdquo com deteccao automatica de ligacao apresentado

na seccao 422 Para que isto seja possıvel foi implementado um mecanismo de ver-

ificacao periodica do estado da ligacao atraves de chamadas Ajax assıncronas O

resultado destes pedidos determina o estado da aplicacao executando as tarefas de

sincronizacao de dados sempre que pertinente Este metodo embora imediato e

simples de implementar depressa se revelou inadequado para o projecto devido ao

elevado consumo de recursos do servidor que a utilizacao intensiva faz esperar a

comunidade da plataforma WOW no principal cliente excede os 7000 utilizadores

Foi estimado que para uma utilizacao de fluidez aceitavel o estado da ligacao deveria

ser testado a cada cinco segundos Assumindo uma adesao (previsao pessimista) de

1 aos servicos offline assistir-se-ia a cerca de 840 pedidos adicionais por minuto

Mas o principal problema desta aproximacao prende-se com o facto de a ver-

ificacao ser feita em intervalos de tempo discretos levando a possibilidade de a

aplicacao poder ter em dado momento uma representacao errada do seu estado

real da ligacao Este problema e ilustrado na Figura 48 onde se ve claramente a

discrepancia entre o estado real da ligacao e a representacao interna que esta tem

Note-se que nesta janela de tempo qualquer accao do utilizador que exija uma

resposta sıncrona do utilizador leva-lo-a para um ldquobeco sem saıdardquo onde nao tera

43

Desenvolvimento

Figura 46 A pagina inicial do WOW apresenta um resumo das ultimas ordens de trabalhoenviadas e recebidas Na imagem pode-se observar a transicao do estado online para offline

acesso a versao offline porque a aplicacao nao fez a transicao automatica nem acesso

a versao online porque na verdade nao possui uma ligacao O que acontecera nesta

situacao sera uma tentativa de acesso ao servidor por parte da aplicacao numa

altura em que este se encontra indisponıvel e o resultado sera uma mensagem de

ldquopedido excedeu o tempordquo apresentado pelo browser Este e um estado sem retorno

porque apos o browser apresentar esta mensagem todos os recursos JavaScript ficam

indisponıveis tornando impossıvel o regresso ao estado anterior ou o tratamento do

erro de qualquer outra forma No entanto as chamadas Ajax podem ser tratadas de

forma especial para a eventualidade de falha e portanto nao constituem problema

44

Desenvolvimento

Figura 47 Ilustracao do funcionamento do Gears numa web application que utiliza ummotor Ajax Os pedidos HTTP ou HTTPS podem ser interceptados e tratados localmenteou podem ser feitos a uma maquina remota consoante se verificarem ou nao as condicoesexpressas no ponto 311 E representado um acesso a uma base de dados local (fornecidapelo Gears) mas a sua utilizacao e opcional

462 Implementacao do modo ldquoutilizador deciderdquo

Este modo de execucao foi ja descrito na seccao 421 e a sua principal carac-

terıstica e ser o utilizador a decidir se a aplicacao deve utilizar um servidor remoto

ou a maquina local como fornecedor de dados

Relativamente ao WOW o WOW Offline na vertente ldquoutilizador deciderdquo vem

alterar os seus casos de uso dando ao utilizador a possibilidade de alterar o estado

de execucao da aplicacao (entre online e offline) Resta dizer que no modo online se

mantem todas as funcionalidades anteriores e que no modo offline torna-se possıvel

visualizar os conteudos da pagina principal do WOW (Figura 46) e os detalhes das

ordens de trabalho (Figura 49) tal como expressa a Figura 410

Esta aproximacao foi utilizada na prova de conceito do WOW adicionando um

controlo a interface desta aplicacao que permite ao utilizador alternar entre os esta-

dos online e offline Na transicao de online para offline sao descarregados os recursos

necessarios para a execucao desta aplicacao sem recorrer a Internet Para o fazer

45

Desenvolvimento

Figura 48 Neste exemplo do modo ldquoaplicacao deciderdquo o teste da ligacao e feito e feito acada cinco segundos O resultado deste teste nao reflecte sempre o estado real da aplicacaopodendo levar a aplicacao a ter comportamentos indesejaveis Na figura assinala-se umperıodo de tempo no qual a representacao interna do estado da ligacao nao corresponde arealidade

e utilizado um recurso ResourceStore e um ManagedResourceStore (introduzidos

em 311) O primeiro e utilizado para armazenar a pagina principal do WOW ndash do-

ravante designada por homejsp ndash e o segundo e utilizado para armazenar imagens

folhas de estilo CSS e scripts JavaScript

Para a implementacao deste modo de execucao foram identificadas as seguintes

tarefas

1 Guardar informacao que permita a recriacao das paginas que se pretende

disponibilizar offline (utilizando o Gears)

2 Disponibilizar um controlo que permita alterar o estado de execucao atraves

da interaccao com a pagina principal

3 Durante a sincronizacao de dados apresentar o progresso da transferencia de

dados

O primeiro passo consistiu na identificacao de todos os conteudos que sao necessarios

transferir para a execucao offline Foi utilizado um recurso do Gears do tipo

ManagedResourceStore que recorre a um ficheiro manifesto para identificar to-

dos os ficheiros que deve transferir Este recurso e gerido automaticamente pelo

Gears transferindo para o cliente a versao mais recente sempre que e necessario

isto e sempre que exista um ficheiro manifesto com uma identificacao de versao que

seja diferente da actualmente disponıvel no cliente Uma vez identificados todos

ficheiros necessarios para a execucao offline num (ou mais) ficheiros manifesto o

Gears encarrega-se da sua actualizacao mas o preenchimento destes ficheiros man-

ifesto e manual o que se traduz num cuidado extra na manutencao da aplicacao

A forma como esta informacao e guardada deve tambem ser cuidadosamente

estudada A opcao mais flexıvel passa por utilizar o modulo Database apresentado

na seccao 311 e guardar a informacao de uma forma relacional Para a recriacao

das paginas pode ser disponibilizada uma versao HTML da pagina que funciona

46

Desenvolvimento

Figura 49 Pagina de visualizacao do detalhe de uma ordem de trabalho

como template nao possui quaisquer dados e e utilizada apenas em modo offline E

preenchida para cada pedido retirando os dados relevantes da base de dados

O modelo de dados do WOW torna esta opcao extremamente trabalhosa uma

vez que as entidades envolvidas na geracao de cada pagina de informacao sobre

cada ordem de trabalho tem relacoes de dependencia complexas seguindo padroes

muito variaveis Por exemplo em cada ordem de trabalho existe um formulario que

permite a sua progressao de estado com diversos campos opcionais e obrigatorios

este formulario e definido pelo administrador e esta relacionado nao apenas com o

tipo de ordem de trabalho mas tambem com o estado actual em que esta se encontra

e a accao que se pretende realizar O elevado numero de combinacoes de tipos de

ordem de trabalho estados e accoes que existem num dado momento juntamente

com a sua possibilidade de alteracao obrigariam a implementacao de uma logica de

negocio complexa o que esta fora do ambito deste projecto

47

Desenvolvimento

Figura 410 Esquema UML que expressa os casos de uso do WOW Offline no modoldquoutilizador deciderdquo

463 Especificacao do modo ldquoaplicacao assume o estado offlinerdquo

A aproximacao para o modo ldquoaplicacao assume o estado offlinerdquo foi tambem

dividida em varias tarefas

1 Guardar informacao que permita a recriacao da pagina principal do lado do

cliente no estado offline (utilizando o Gears)

2 Dotar a aplicacao do cliente de um mecanismo de deteccao da ligacao

3 Identificar os ldquomomentos chaverdquo em que devera ocorrer sincronizacao de dados

4 Implementar a sincronizacao de dados

A sincronizacao de dados deve ser feita em ambas as transicoes online-offline e

offline-online quer para transferir novos dados do servidor (os pedidos podem ser

alterados por outros utilizadores) quando se transita do estado quer para comunicar

eventuais alteracoes feitas em modo offline

Relativamente ao WOW o WOW Offline na vertente ldquoaplicacao assume o es-

tado offlinerdquo vem alterar os seus casos de uso dando ao utilizador a possibilidade

de activar esta funcionalidade A partir do momento que a funcionalidade esta ac-

tivada o utilizador deve tambem ter a possibilidade de gerir algumas preferencias

relacionadas com privacidade de dados Devera ter a hipotese de desactivar o ar-

mazenamento local e de remover todos os dados ja armazenados tal como descrito

na Figura 411

48

Desenvolvimento

Figura 411 Esquema UML que expressa os casos de uso do WOW Offline no modoldquoutilizador deciderdquo

A primeira vez que o WOW Offline e acedido por um cliente e caso seja detec-

tada a presenca do Gears todos os recursos necessarios a sua execucao sao trans-

feridos Todos os acessos posteriores serao feitos a estes recursos locais (recorda-se

que o Gears pode ser utilizado para os manter actualizados recorrendo ao Managed-

ResourceStore 311)

Atraves do JavaScript e possıvel interceptar os eventos de load e unload da

pagina que sao despoletados sempre que ocorre um re-acesso da mesma (incluindo

a accao refresh comum dos browsers) sempre que esta e abandonada ou ainda ou

ainda se a janela for encerrada

Tal como sugerido na seccao 462 a camada de interface desta aplicacao (cada

pagina individual em HTML) devera ser implementada como sendo um template

para apresentacao de dados sendo totalmente preenchida atraves de funcoes em

JavaScript O objectivo deste ponto e criar um padrao de dados que permita ao

JavaScript preencher os dados em cada pagina (template) independentemente de

qual seja a fonte ndash o servidor remoto ou a maquina local tal como exemplificado

no diagrama da Figura 412 Na figura a aplicacao recorre ao servidor remoto para

obter os dados pretendidos quando se encontra na presenca de uma ligacao mas

para dados que exijam uma carga de processamento pelo servidor este acto pode ser

49

Desenvolvimento

Figura 412 Esquema UML que expressa o acto de recolha de dados em modo online eoffline recorrendo ao servidor (modo online) e ao sistema de armazenamento de dadoslocal fornecido pelo Gears (modo offline)

substituıdo pelo envio de um campo de controlo que se destina a aferir se os dados

locais se encontram actualizados No caso de estarem actualizados a comunicacao

com o servidor pode ser substituıda por uma query a base de dados local

50

Capıtulo 5

Resultados e Futuros

Desenvolvimentos

Todo o estudo feito sobre o tema OWA foi ja abordado ao longo do documento

Neste capıtulo apresentam-se os resultados obtidos na implementacao da prova de

conceito que visava compreender a melhor forma de disponibilizar uma versao of-

fline no WOW uma plataforma de gestao de ordens de trabalho ja existente de-

senvolvida pela Critical Software SA

51 Resultados Obtidos

Os resultados obtidos neste projecto sao extremamente satisfatorios uma vez

que o estudo do tema OWA e a implementacao de uma prova de conceito que o

ilustrasse foi conseguido com sucesso

A funcionalidade offline foi adicionada ao produto WOW da Critical Software

SA permitindo a visualizacao de ordens de trabalho e dos seus detalhes mesmo na

ausencia de uma conexao activa a Internet Embora para a solucao implementada

tenha sido utilizada uma abordagem do tipo ldquoutilizador deciderdquo pretende-se que esta

seja convertida para ldquoaplicacao deciderdquo ou mesmo para uma aproximacao hıbrida

semelhante a utilizada pelas aplicacoes estudadas nas seccoes 351 e 352

Para a sua implementacao descrita no capıtulo 4 foram tomadas decisoes de or-

dem pratica que permitissem tornar o trabalho exequıvel nos prazos dados Tentou-

se sempre que estas decisoes afectassem o mınimo em termos de desempenho e de

experiencia para o utilizador Considera-se que a implementacao do modo offline

com uma transicao entre modos do tipo ldquoutilizador deciderdquo (ver seccao 42) reflecte

o compromisso entre o desempenho pretendido e os recursos disponıveis e para alem

51

Resultados e Futuros Desenvolvimentos

de ser um exemplo eficaz das possibilidades que as OWA podem trazer a aplicacao

WOW desenvolvida pela Critical Software e tambem um estudo que pode ser uti-

lizado para analisar a implementacao desta tecnologia noutros produtos da mesma

empresa

Note-se que o principal objectivo do trabalho era ganhar familiaridade com este

tema entender as suas vantagens e desvantagens e compreender as suas limitacoes

Tudo indica que existam varias possibilidades de implementacao deste paradigma

noutros produtos da Critical Software que pela sua natureza podem tambem tirar

partido da execucao offline

52 Trabalho Futuro

O desenvolvimento do conceito e formas de implementacao de OWA continua

em forte desenvolvimento no entanto a sua adopcao ainda nao e generalizada A

dificuldade da sua implementacao em web applications ja existentes e o principal

obstaculo a sua maior divulgacao

Ha tambem um factor que deve ser tido em consideracao a manutencao de

codigo A implementacao de uma versao offline de uma web application requer

a implementacao das mesmas regras de negocio (ou de uma versao simplificada)

utilizadas no servidor Para que isto seja possıvel e necessario ter em conta a

capacidade de processamento do cliente e o factor de duplicacao de codigo que

tornara a aplicacao mais difıcil de manter uma vez que uma alteracao a logica de

negocio do servidor implica tambem uma alteracao a sua versao offline

A prova de conceito implementada permite ja a visualizacao offline dos pedidos

abertos (enviados e recebidos) que constam na pagina principal (este numero e

fixo e pode ser alterado pelo administrador) Uma funcionalidade desejavel seria a

possibilidade de interaccao com a aplicacao em modo offline e sincronizacao com o

servidor quando existisse uma ligacao disponıvel

Foi estudada a utilizacao do modo de execucao ldquoaplicacao assume o estado of-

flinerdquo descrito em 423 e esta seria a forma desejavel para o WOW Offline no

entanto para que esta opcao seja viavel sera necessaria a implementacao de uma

forma eficiente de sincronizacao e armazenamento de dados de uma forma relacional

Para atingir este objectivo podera ser seguida uma polıtica de automacao do pro-

cesso no qual a versao online da aplicacao gera scripts de criacao para as tabelas

necessarias na base de dados da versao offline (nao existe nenhuma ferramenta para

o fazer portanto seria necessaria a sua implementacao) e no qual as paginas HTML

disponibilizadas pelo servidor aos clientes web (browser) servem como templates de

apresentacao de informacao e sao preenchidas de forma semelhante pelo servidor ndash

quando a aplicacao estiver online ndash ou pelo cliente atraves de funcoes em JavaScript

52

Resultados e Futuros Desenvolvimentos

ndash quando a aplicacao estiver offline No entanto no WOW devido a quantidade de

informacao tratada e devido as complexas relacoes entre as diferentes entidades e

de esperar que a complexidade da implementacao de um mecanismo deste tipo torne

esta aproximacao demasiado custosa

O HTML 5 embora um forte candidato ainda nao esta suficientemente desen-

volvido A sua especificacao ainda tem o caracter de Draft (rascunho) e esta sujeita

a modificacoes e a aceitacao e implementacao por parte dos browsers e portanto

de momento foi desconsiderado No entanto no futuro se esta especificacao atingir

um estado de maturidade que permita a sua adopcao devera ser considerada como

um possıvel caminho a seguir

53

Resultados e Futuros Desenvolvimentos

54

Capıtulo 6

Conclusoes

Neste capıtulo sao apresentadas as conclusoes do projecto e consideracoes finais

relativamente a tecnologia estudada

61 Conclusoes

O rapido desenvolvimento tecnologico faz prever que a disponibilidade de ligacao

a Internet seja cada vez mais facil e mais rapido mas vao continuar a existir lugares

onde o acesso e limitado e onde as OWA podem desempenhar um papel de relevo

Por outro lado esta tecnologia pode tambem ser utilizada para melhorar o desem-

penho de paginas web com uma necessidade elevada de imagens ou outros recursos

dispendiosos em termos de espaco e foram ate estudados dois exemplos da utilizacao

desta vertente desta tecnologia em 353

Acredita-se que as OWAs vem responder a uma necessidade real por parte das

web applications actuais e que a evolucao que representam se compara a que se

assistiu dos thin-clients para os fat-clients em termos de autonomia do servidor

A capacidade de oferecer conteudos dinamicos no browser independentemente da

existencia de uma ligacao reune as vantagens tıpicas das web applications como

ausencia de instalacao e actualizacoes instantaneas com as vantagens das aplicacoes

de desktop em capacidade de processamento e armazenamento de dados na maquina

local

As tecnologias disponıveis ate a data estudadas no ambito deste projecto que

permitem o desenvolvimento de OWAs e que apresentam maior maturidade sao o

Gears e o Adobe AIR Ambas se apresentam sobre a forma de plugins que necessitam

de uma instalacao extra para poderem ser utilizadas Apesar de esta instalacao ser

55

Conclusoes

apenas necessaria uma vez podera constituir um factor de desencorajamento a sua

adopcao

O HTML 5 uma especificacao abordada neste documento na seccao 34 podera

ser uma alternativa que oferece funcionalidades offline a uma web application sem a

necessidade de qualquer instalacao no entanto esta especificacao ainda nao foi aceite

pelos principais browsers ndash o documento que define o HTML 5 ainda tem o estatuto

de Draft ndash e ainda nao e possıvel antecipar quando e que isto podera acontecer

Um dos problemas que surge frequentemente na implementacao de uma versao

offline para uma web application e a necessidade de sincronizacao de dados Quando

a informacao pode ser alterada por varios utilizadores simultaneamente e necessario

prever os conflitos que daı podem surgir e dotar a aplicacao de uma forma de os

resolver ou alertar o utilizador para a necessidade de alteracao dos dados

Em conclusao todos os objectivos propostos para este projecto foram atingidos

A prova de conceito implementada reflecte de forma clara as possibilidades oferecidas

pela tecnologia OWA e sera utilizado no futuro para compreender a melhor forma

de o implementar de forma definitiva no WOW

56

Referencias

[Ada08] Lucas Adamski Introducing Adobe AIR security model Fevereiro de2008 Disponıvel em httpwwwadobecomdevnetairarticles

introduction_to_air_securityhtml acedido em Marco de 2008

[Ado08] Adobe Adobe AIR 10 Security White Paper 2008 Disponıvel emhttpdownloadmacromediacompubairdocumentation1air_

securitypdf acedido em Marco de 2008

[Alm08] Dion Almaer Gears as a bleeding-edge html 5 implementa-tion March 2008 Disponıvel em httpalmaercomblog

gears-as-a-bleeding-edge-html-5-implementation acedido emMarco de 2008

[BL96] Tim Berners-Lee The world wide web Past present and future Agostode 1996 Disponıvel em httpwwww3orgPeopleBerners-Lee

1996ppfhtml acedido em Abril de 2008

[CDGH08] Mike Chambers Daniel Dura Dragos Georgita and Kevin Hoyt AdobeAIR for JavaScript Developers OrsquoReilly Media 2008 Disponıvel emhttponairadobecomfilesAIRforJSDevPocketGuidepdf ace-dido em Abril de 2008

[Con99] Jim Conallen Modeling Web Application Architectures with UML Junho1999 Disponıvel em httpwwwumlorgcnUMLApplicationpdf

webappspdf acedido em Maio de 2008

[Ent07] Entrust What is a public key information 2007 Disponıvel em http

wwwentrustcompkihtm acedido em Junho de 2008

[Gar05] Jesse James Garret Ajax A new approach to web applicationsFebruary 2005 Disponıvel em httpwwwadaptivepathcomideas

essaysarchives000385php acedido em Marco de 2008

[Greon] Philip Greenspun Philip and Alexrsquos Guide to Web Publishing 2003(last revision) Disponıvel em httpphilipgreenspuncompandaacedido em Junho de 2008

[Gro02a] App Design Group Thick vs thin client comparison 2002 Disponıvelem httpwwwdonjacobsvwcomimagesweekendspecials

Thick-vs-Thinpdf acedido em Junho de 2008

57

REFERENCIAS

[Gro02b] Technical Research Group Thin Client Tecnhology - WhitePaper 2002 Disponıvel em httpwwwpicktrgcompubs

thinclientwhitepaperpdf acedido em Junho de 2008

[Gro08] Miniwatts Marketing Group World internet usage March 2008Disponıvel em httpwwwinternetworldstatscomstatshtm ace-dido em Abril de 2008

[Hic08] Ian Hickson HTML 5 Draft Recommendation 2008 Disponıvelem httpwwwwhatwgorgspecsweb-appscurrent-work ace-dido em Marco de 2008

[Kha] Olga Kharif Top 10 municipal wifi plans Disponıvel em http

imagesbusinessweekcomss0608muni_wifiindex_01htm ace-dido em Marco de 2008

[Lab07] Mozilla Labs Prism Outubro 2007 Disponıvel em httplabs

mozillacom200710prism acedido em Marco de 2008

[Loo06] Chris Loosley Rich Internet ApplicationsDesign MeasurementandManagement Challenges 2006 Disponıvel em httpwwwkeynote

comdocswhitepapersRichInternet_5pdf acedido em Maio de2008

[Mic08] Microsoft Introduction to Occasionally Connected Applications us-ing Sync Services for ADONET 2008 Disponıvel em httpmsdn

microsoftcomen-ussyncbb887608aspx acedido em Junho de2008

[Nao08] Erica Naone Offline web applications Abril 2008 Disponıvelem httpwwwtechnologyreviewcomread_articleaspxch=

specialsectionsampsc=emerging08ampid=20245 acedido emAbril de 2008

[NJN00] Jason Nieh Yang S Jae and Naomi Novik A comparison of thin-clientcomputing architectures 2000 Disponıvel em httpwwwnclcs

columbiaedupublicationscucs-022-00pdf acedido em Maio de2008

[OrsquoR06] Tim OrsquoReilly Web 20 compact definition Trying again Dezembro2006 Disponıvel em httpradaroreillycomarchives200612

web-20-compact-definition-tryihtml acedido em Marco de 2008

[OrsquoR09] Tim OrsquoReilly What is Web 20 Design patterns and business modelsfor the Next Generation of Software 20053009 Disponıvel emhttpwwworeillynetcompubaoreillytimnews200509

30what-is-web-20html acedido em Marco de 2008

[Rus06] Alex Russel Comet Low latency data for the browser March Marco2006 Disponıvel em httpalexdojotoolkitorgp=545 acedidoem Marco de 2008

58

REFERENCIAS

[Sad97] Darleen Sadoski Clientserver software architecturesndashan overviewAgosto 1997 Disponıvel em httpwwwseicmuedustr

descriptionsclientserver_bodyhtml acedido em Junho de2008

[Sch96] George Schussel Clientserver past present and future 1996

[Smi07] Kevin C Smith Css filters - will the browser apply the rule July 2007Disponıvel em httpcentriclecomrefcssfilters acedido emMarco de 2008

[vK08] Anne van Kesteren The XMLHttpRequest Object W3C Work-ing Draft 15 Abril 2008 Disponıvel em httpwwww3orgTR

XMLHttpRequest acedido em Abril de 2008

[Wil06] Greg Wilkins Why ajax comet July Julho 2006 Disponıvel emhttpwwwwebtidecomdownloadswhitePaperWhyAjaxhtml ace-dido em Abril de 2008

59

REFERENCIAS

60

Anexo A

Screenshots

Algumas imagens de aplicacoes que utilizam funcionalidades offline ilustrativasda tecnologia abordada neste documento

Figura A1 Dialogo apresentado ao utilizador na primeira activacao das funcionalidadesoffline no Google Docs amp Spreadsheets

61

Screenshots

Figura A2 Na activacao das funcionalidades offline e tambem oferecida a possibilidadeda criacao de alguns atalhos por exemplo no ambiente de trabalho

Figura A3 O Google Docs mantem a todo o momento a possibilidade de alteracao destasdefinicoes ou da anulacao dos servicos offline para um dado computador

62

Screenshots

Figura A4 Apos a instalacao do Gears qualquer visita ao Remember The Milk despoletauma sincronizacao que ocorre automaticamente e sem necessidade de intervencao por partedo utilizador

Figura A5 Apos completar a sincronizacao de dados mesmo que a ligacao a Internetseja perdida o Remember the Milk continua disponıvel no browser (com excepcao dasfuncionalidades que pela sua natureza exigem uma ligacao como por exemplo partilhade tarefas e envio de convites)

63

Page 3: O ine Web Applications

Offline Web Applications

Joao Goncalves da Costa

Relatorio de Projecto realizado no Ambito do

Mestrado Integrado em Engenharia Informatica e Computacao

Aprovado em provas publicas pelo juri

Presidente Pedro Ferreira do Souto (PhD)

Arguente Artur Pereira (PhD)

Vogal Teresa Galvao Dias (PhD)

27 de Julho de 2008

Resumo

Este projecto teve como objectivo o estudo das Offline Web Applications (OWAs)e da sua implementacao em web applications ja existentes Neste ambito foi feitauma avaliacao da aplicacao desta tecnologia no WOW uma plataforma integradade gestao de ordens de trabalho desenvolvida pela Critical Software SA ao longodos ultimos 6 anos e implementada uma prova de conceito que permite a utilizacaode um conjunto de funcionalidades base desta web application independentementedo estado da ligacao a Internet

O conceito das OWAs enquadra-se numa tecnologia de Internet que permiteo acesso a um website atraves do browser mesmo na ausencia de uma ligacao arede global e foi considerado pela revista Technology Review como uma das maisimportantes tecnologias emergentes no final de 2007 [Nao08] O estudo efectuado noWOW pretende ser um primeiro passo na compreensao dos problemas associados asua implementacao e respectivas solucoes e tambem da avaliacao dos benefıcios dautilizacao desta tecnologia para os utilizadores finais

A evolucao das tecnologias associadas a Internet a que se assiste continua-mente impulsionou tambem evolucao da forma como a informacao e produzidadistribuıda e armazenada Surgiram novas web applications oferecendo funcionali-dades de criacao e edicao de conteudos que trouxeram consigo a vantagem de tornarpossıvel o acesso a informacao a partir de qualquer lugar mas tambem a desvan-tagem de tornar a ligacao a Internet uma condicao necessaria para que isto acontecaA proliferacao destas aplicacoes a crescente utilizacao da Internet [Gro08] e a adesaoaos seus servicos indiciam a existencia de uma dependencia cada vez maior de umaligacao que nem sempre existe

As OWAs vem assim colmatar esta falha colocando no lado do cliente parte dainformacao que ate agora vinha a ser armazenada no servidor e tornando nao sopossıvel a sua consulta offline como tambem reduzindo a carga no servidor umavez que reduz as transferencias de informacao

Pretende-se neste documento apresentar diferentes formas de como a utilizacaoda tecnologia OWA pode beneficiar as web applications de hoje melhorando o seudesempenho e dando-lhes novas possibilidades de execucao aproximando-as do desk-top

i

ii

Abstract

The main purpose of this project was to study the Offline Web Applications(OWAs) and its implementation in existent web applications With this goal in minda study was conducted to use this technology in WOW an integrated platform forwork orders and work flow management developed by Critical Software over thelast 6 years and implemented a proof of concept which enables the use of a baseset of functionality for this application regardless of the internet connection state

The concept of OWAs is connected with internet technology and allows accessto a website using the browser even if a connection to the internet is not availableThis concept was considered by Technology Review as one of the most importantemerging technologies in the last quarter of 2007 [Nao08] This study conductedover the WOW platform is intended to aid in the comprehension of the problemsand solutions associated to the use and implementation of OWA as well as thebenefits that it brings to the end user

The Internet and Internet technologies are changing the way in which informa-tion is produced distributed and stored New web applications appeared with newcontent creation and edition functionalities and with it the advantage of infor-mation retrieval from any place and time became possible but with the conditionof Internet connection availability With Internet use growing every year [Gro08]content creation is starting to move to this new platform The adoption of web ap-plications for content creation and edition is becoming more popular and it showsa dependency of a connection that is not always present

The OWAs are a way to solve this problem putting on the client side part ofthe information that was traditionally stored on the server and allows it to be seenand manipulated and helps reducing the server load

This document intends to present different ways in which this technology canhelp web applications as we know them improving the their overall performance andgiving them the ability to run on a browser regardless of the Internet connectionavailability

iii

iv

Agradecimentos

A realizacao e os objectivos alcancados neste projecto nao teriam sido possıveissem a colaboracao de inumeras pessoas Agradeco profundamente a todos os quecontribuıram directa ou indirectamente para o seu sucesso

A minha orientadora Professora Teresa Galvao Dias e ao Project ManagerEngenheiro Marcus Neves que me conduziram e acompanharam no desenvolvimentodeste projecto

A toda a equipa do WOW em especial o Pedro Maurıcio Costa e o Fabio Matosque contribuıram para a minha a minha integracao na Critical Software e que sempresouberam responder a todas as minhas questoes

A todos os que constituem a CSW Porto pelo fantastico ambiente de amizadeque me proporcionaram

Aos colegas de curso e a todos os que me auxiliaram na revisao deste documento

Os meus sinceros agradecimentos

Joao Goncalves da Costa

v

vi

Conteudo

1 Introducao 111 Enquadramento 112 Motivacao 213 Ambito 314 Objectivos 315 Estrutura do documento 3

2 Enquadramento do Projecto 521 Evolucao das arquitecturas de software 5

211 Thin-clients 5212 Fat-clients 6213 Arquitecturas cliente-servidor 7

22 Evolucao na Internet 8221 Paginas web estaticas 9222 Paginas web interactivas e paginas web dinamicas 9223 Web 20 e Ajax 11

23 Offline Web Applications 1324 Comparacao 13

3 Estado da arte 1731 Gears 17

311 Arquitectura 17312 Goggle Gears em dispositivos moveis 20

32 Adobe AIR 20321 Seguranca 22322 Assinatura do codigo 22

33 Mozilla Prism 23331 XML User Interface Language 23332 Prism 25

34 HTML 5 2535 Web applications que usam funcionalidades offline 26

351 Google Reader e Google Docs 26352 Remember the Milk 27353 MySpace e WordPresscom 27

36 Escolha da tecnologia 28

vii

CONTEUDO

4 Desenvolvimento 3341 Como ficar offline 33

411 Funcionalidades disponıveis em modo offline 3442 Modos de execucao 35

421 Modo ldquoutilizador deciderdquo 36422 Modo aplicacao decide 36423 Modo ldquoaplicacao assume o estado offlinerdquo 37

43 Sincronizacao de dados 38431 Quando sincronizar 39

44 WOW 4045 Visao geral sobre a arquitectura do WOW 4146 WOW Offline 42

461 Modo ldquoaplicacao deciderdquo com deteccao automatica da ligacao 43462 Implementacao do modo ldquoutilizador deciderdquo 45463 Especificacao do modo ldquoaplicacao assume o estado offlinerdquo 48

5 Resultados e Futuros Desenvolvimentos 5151 Resultados Obtidos 5152 Trabalho Futuro 52

6 Conclusoes 5561 Conclusoes 55

Referencias 59

A Screenshots 61

viii

Lista de Figuras

21 Arquitectura de um sistema thin-client em duas camadas (a esquerda)e em tres camadas (a direita) Note-se a inclusao do servidor (main-frame) na definicao das camadas desta arquitectura devido a fortedependencia cliente-servidor 9

22 Arquitectura de um fat-client em duas camadas (a esquerda) e emtres camadas (a direita) 10

23 Comparacao do modelo de web aplications sıncrono paginas estaticase interactivas abordados nas seccoes 221 e 222 com o modelo deweb applications Ajax (assıncrono) abordado na seccao 223 Figuraadaptada de http www adaptivepath com 15

31 Esquema UML do processo efectuado pelos recursos do Gears do tipoManagedResourceStore para a actualizacao dos conteudos definidosno ficheiro manifesto 29

41 Exemplo de uma arquitectura de uma web application sem uma ca-mada de abstraccao de dados Figura adaptada de http gears

google com 33

42 Exemplo de uma arquitectura de uma web application com uma ca-mada de abstraccao de dados Figura adaptada de http gears

google com 34

43 Exemplo de uma arquitectura de uma web application com uma ca-mada de abstraccao de dados e um data switch Figura adaptada dehttp gears google com 35

44 Esquema grafico ilustrando uma OWA executando no browser uti-lizando um modo de execucao do tipo ldquoaplicacao deciderdquo com de-teccao automatica do estado da ligacao via pedidos Ajax assıncronosa cada cinco segundos 37

45 Detalhe de um conjunto possıvel de estados e respectivas transicoespara uma dada ordem de trabalho no WOW desde a sua submissaono sistema ate a sua conclusao em fecho ou cancelamento Esta figurarepresenta apenas um exemplo ja que o mapa de estados para umaordem de trabalho e dinamico e pode ser alterado por um admin-istrador Figura retirada de uma brochura promocional do WOWCritical Software SA 41

ix

LISTA DE FIGURAS

46 A pagina inicial do WOW apresenta um resumo das ultimas ordensde trabalho enviadas e recebidas Na imagem pode-se observar atransicao do estado online para offline 44

47 Ilustracao do funcionamento do Gears numa web application que uti-liza um motor Ajax Os pedidos HTTP ou HTTPS podem ser inter-ceptados e tratados localmente ou podem ser feitos a uma maquinaremota consoante se verificarem ou nao as condicoes expressas noponto 311 E representado um acesso a uma base de dados local(fornecida pelo Gears) mas a sua utilizacao e opcional 45

48 Neste exemplo do modo ldquoaplicacao deciderdquo o teste da ligacao e feitoe feito a cada cinco segundos O resultado deste teste nao reflectesempre o estado real da aplicacao podendo levar a aplicacao a tercomportamentos indesejaveis Na figura assinala-se um perıodo detempo no qual a representacao interna do estado da ligacao nao cor-responde a realidade 46

49 Pagina de visualizacao do detalhe de uma ordem de trabalho 47410 Esquema UML que expressa os casos de uso do WOW Offline no

modo ldquoutilizador deciderdquo 48411 Esquema UML que expressa os casos de uso do WOW Offline no

modo ldquoutilizador deciderdquo 49412 Esquema UML que expressa o acto de recolha de dados em modo

online e offline recorrendo ao servidor (modo online) e ao sistemade armazenamento de dados local fornecido pelo Gears (modo offline) 50

A1 Dialogo apresentado ao utilizador na primeira activacao das funcional-idades offline no Google Docs amp Spreadsheets 61

A2 Na activacao das funcionalidades offline e tambem oferecida a possi-bilidade da criacao de alguns atalhos por exemplo no ambiente detrabalho 62

A3 O Google Docs mantem a todo o momento a possibilidade de alteracaodestas definicoes ou da anulacao dos servicos offline para um dadocomputador 62

A4 Apos a instalacao do Gears qualquer visita ao Remember The Milkdespoleta uma sincronizacao que ocorre automaticamente e sem ne-cessidade de intervencao por parte do utilizador 63

A5 Apos completar a sincronizacao de dados mesmo que a ligacao aInternet seja perdida o Remember the Milk continua disponıvel nobrowser (com excepcao das funcionalidades que pela sua naturezaexigem uma ligacao como por exemplo partilha de tarefas e enviode convites) 63

x

Lista de Tabelas

21 Comparacao entre thin-clients e fat-clients 7

31 Comparacao das funcionalidades oferecidas pelo Adobe AIR para asplataformas web e desktop 30

32 Resumo da utilizacao de tecnologias OWA em algumas web applica-tions consideradas na analise do estado da arte 31

xi

LISTA DE TABELAS

xii

Glossario

fat-client Cliente que nao depende totalmente de umservidor central para as suas actividadesde processamento e possui frequentementedispositivos de armazenamento de dados

6ndash8

thin-client Cliente que depende de um servidor centralpara as suas actividades de processamento

5ndash8

web application Sistema web (servidor rede HTTPbrowser) onde accoes do utilizador(navegacao e introducao de informacao)afectam o estado logico da aplicacao

i iii1ndash311ndash1517ndash1921ndash232728 3336ndash3842 5556

API Application Programming Interface 10 1718 2326 28

ASP Linguagem interpretada pelo servidorque permite a criacao de paginas webdinamicas Desenvolvida pela Microsoft

11

BSD Berkeley Software Distribution 28

CSS Cascading Style Sheets 12 2021 2324 46

DHTML Dynamic HyperText Transfer Protocol 24DOM Document Object Model 10 12

20 2324

DTD Document Type Definition 24

xiii

Glossario

ECMAScript Padrao de linguagem de programacaodefinido pela Ecma International que orig-inou o JavaScript e o JScript

24

Flash Conteudo interactivo de um ficheiro emformato SWF E desenvolvido pela Adobee visualizado atraves do Adobe FlashPlayer

21

Flex Framework baseada em XML e Action-Script desenvolvida pela Adobe para a pro-gramacao de Rich Internet Applications(RIA)

21

GPL GNU General Public License 23

HTML HyperText Markup Language 1 10ndash12 2124ndash2649

HTTP HyperText Transfer Protocol 2 26

JMS E uma API em Java que permite a troca demensagens entre componentes de software

42

JSON JavaScript Object Notation permite atroca de dados codificados num formatode texto de simples leitura

12 1828 34

LGPL GNU Lesser General Public License 23

Mozilla Prism Browser simplificado e ldquointerpretadorrdquo deeXtensible User Interface Language (XUL)(tambem designado por XULRunner) queacolhe web applications sem a interfacegrafica habitual de um browser

25

MPL Mozilla Public License 23

OCA Occasionally Connected Application 39OWA Offline Web Application i iii

2ndash515 1725 2628 3133 3651 5255 56

PDF Portable Document Format 21

xiv

Glossario

PHP Linguagem interpretada pelo servidorque permite a criacao de paginas webdinamicas mas que pode tambem ser in-vocada a partir da linha de comandos

11

pagina web estatica Pagina web que devolve sempre a mesmaresposta a todos os pedidos para todos osutilizadores e em qualquer contexto

5 9

RIA Rich Internet Applications web appli-cations que apresentam funcionalidadessemelhantes as desktop applications masque mantem a informacao no lado do servi-dor

5 1520 28

RSS Really Simple Syndication 27

SLA Service Level Agreement 40SQLite Segundo a definicao oficial SQLite is a

software library that implements a self-contained serverless zero-configurationtransactional SQL database engine

17

SSB Site Specific Browser 25SSL Secure Sockets Layer 22SWF ShockWave Flash 21

URL Uniform Resource Locator 18

VPN Virtual Private Network 38

WOW Work Orders Web Plataforma de gestaode ordens de trabalho e do seu fluxo de-senvolvida pela Critical Software SA

i iii28 3340ndash434551ndash5356

WWW World Wide Web 11 1214

XBL eXtensible Binding Language 24XHTML eXtensible HyperText Markup Language 12XML eXtensible Markup Language 11 12

23 2428

XSLT eXtensible Stylesheet Language Transfor-mation

12

XUL eXtensible User Interface Language xiv23ndash25

xv

Glossario

xvi

Capıtulo 1

Introducao

Neste capıtulo enquadra-se o tema do projecto introduzindo alguns dos conceitos

nos quais se baseia Apresentam-se as motivacoes ambito objectivos e a estrutura

deste documento

11 Enquadramento

A Internet foi originalmente concebida para ser um espaco de partilha de in-

formacao onde pessoas (atraves de maquinas) pudessem comunicar Na sua origem

as paginas eram estaticas constituıdas por texto formatado em HyperText Markup

Language (HTML) e ligadas entre si [BL96] Hoje encontramos conteudos cada vez

mais complexos e dinamicos incluindo som vıdeo ou streams multimedia [Loo06] e

em 2005 foi introduzido por [OrsquoR09] o termo Web 20

De acordo com [Greon] um website pode pertencer a uma ou varias das seguintes

categorias

bull Documento ndash um website essencialmente estatico onde alteracoes a uma

parte do conteudo nao tem implicacoes no seu comportamento

bull Base de dados ndash um directorio de informacao organizada em categorias

bull Aplicacao ndash um website dinamico que utiliza uma linguagem executada ou

interpretada do lado do servidor e que processa as accoes ou informacao in-

troduzida pelo utilizador para fornecer um servico ou nova informacao

A ultima destas categorias constitui aquilo que e normalmente designado por

web application O conceito utilizado ao longo deste documento e o mesmo que

o introduzido por Jim Coallen em [Con99] que define web application como um

1

Introducao

sistema web (servidor rede HyperText Transfer Protocol (HTTP) browser) onde

accoes do utilizador (navegacao e introducao de informacao) afectam o estado logico

da aplicacao A sua definicao tenta estabelecer que uma web application e um

sistema de software com estado de negocio1 e que a sua interface de interaccao com

o utilizador e distribuıdo atraves de um sistema web

12 Motivacao

A quantidade de informacao que e produzida e armazenada com recurso a es-

tas web applications disponıveis online tais como e-mail blogues ou mesmo docu-

mentacao tornam por vezes a disponibilidade de ligacao uma condicao necessaria

a produtividade e como consequencia desta barreira muitos potenciais utilizadores

opoem-se a adopcao de produtos web em detrimento das tradicionais desktop appli-

cations

Assegurar o acesso a uma ligacao de Internet e hoje muito mais facil A Internet

movel e ja uma realidade e encontra-se amplamente divulgada mas continuam a

existir diversas situacoes nas quais os utilizadores estao privados de uma ligacao

a Internet tais como uma viagem de metro ou de aviao ou quando se encontram

deslocados do seu paıs de origem e nao possuem nenhum plano de subscricao

Uma OWA consiste numa web application que para alem de manter todas as

caracterısticas anteriores se mantem disponıvel mesmo na ausencia de uma ligacao

a Internet e surge como uma tentativa de estreitar as barreiras existentes entre a

web e o desktop Isto significa que devera existir um mecanismo capaz de assegurar

a manutencao do estado logico da aplicacao quando a ligacao com o servidor e

quebrada permitindo ao utilizador continuar a utilizar a aplicacao e que sera capaz

de informar o servidor do estado em que a aplicacao se encontra quando a ligacao for

reposta A principal vantagem que advem desta possibilidade e evidente eliminar

a necessidade da existencia de uma ligacao a Internet para que a aplicacao possa ser

utilizada

Por outro lado a vontade de integracao de funcionalidades tıpicas das desktop

applications nas web applications foi um dos principais factores que impulsionou o

desenvolvimento deste conceito uma vez que obrigou a uma reflexao ldquopara alem

do browserrdquo e a uma adaptacao das arquitecturas existentes que permitisse ou o

acesso a funcionalidades disponibilizadas pelo sistema operativo ou pelo menos a

funcionalidades semelhantes Pretende-se com esta aproximacao tornar possıveis

interaccoes entre o desktop e o browser tais como arrastar um ficheiro para um

formulario web de upload de conteudos melhor suporte para o historico do clipboard

ou ainda o acesso ao sistema de ficheiros local Atingir estes objectivos reflecte-se

1NT business state

2

Introducao

num novo paradigma que reune as vantagens das web applications tais como os

updates instantaneos ou o facto de nao ser necessaria nenhuma instalacao e das

desktop applications como por exemplo persistencia no armazenamento de dados

acesso a funcionalidades do sistema operativo ou integracao e interaccao com outras

aplicacoes sejam elas web applications ou desktop applications

13 Ambito

Este projecto foi realizado na Critical Software SA no ambito do Mestrado

Integrado em Engenharia Informatica e Computacao (MIEIC) da Faculdade de En-

genharia da Universidade do Porto (FEUP) entre os meses de Fevereiro e Julho de

2008

14 Objectivos

Sao objectivos deste projecto

1 Estudar e documentar o tema das OWAs acompanhando os ultimos desenvolvi-

mentos nesta materia

2 Analisar o estado da arte fazendo uma analise crıtica e objectiva sobre as

diversas metodologias existentes

3 Implementar uma prova de conceito que permita a execucao offline de uma

web application documentando todo o processo

4 Estudar a possibilidade de permitir interaccao com a aplicacao (insercoes e

alteracoes aos dados) em modo offline

Em resumo o objectivo deste projecto foi estudar documentar e implementar

uma prova de conceito relacionada com o tema Offline Web Applications (OWA)

Este tema embora nao seja totalmente novo ganhou destaque ao longo do ano de

2007 com o surgimento de diversas ferramentas que se destinam a aproximar web

applications das desktop applications

15 Estrutura do documento

Este documento esta organizado em diferentes seccoes apresentando o projecto

numa sequencia logica organizada da seguinte forma

No capıtulo 1 faz-se uma breve apresentacao do conceito OWAs e do contexto em

que surge Apresenta-se tambem a estrutura do documento e definem-se os

termos e acronimos utilizados

3

Introducao

No capıtulo 2 faz-se uma descricao da evolucao das tecnologias que antecedem as

OWAs e das vantagens e desvantagens de cada uma como forma de enquadra-

mento

No capıtulo 3 analisa-se o estado da arte nesta materia Introduzem-se diversas

tecnologias directamente relacionadas com o tema deste projecto exemplos de

aplicacoes que as usam e as razoes que fundamentam as escolhas de tecnologias

efectuadas

O capıtulo 4 contem o desenvolvimento do projecto Analisa-se a plataforma

WOW de gestao integrada de ordens de trabalho a tecnologia escolhida e

a forma como foi utilizada para implementar a capacidade de execucao offline

O capıtulo 5 descreve os resultado obtidos comparando-os com as expectativas

iniciais do projecto e apresenta desenvolvimentos futuros e possibilidades de

continuacaoaplicacao do conhecimento adquirido

No capıtulo 6 apresentam-se as conclusoes

4

Capıtulo 2

Enquadramento do Projecto

Neste capıtulo apresenta-se um breve resumo da evolucao das arquitecturas de

software cliente-servidor e a forma como estas se comparam a evolucao da Inter-

net procurando estabelecer uma analogia entre o percurso de ambas as tecnolo-

gias Compara-se o comportamento e arquitectura dos thin-clients as paginas web

estaticas a evolucao dos fat-clients as paginas interactivas Web 20 e Ajax e

defende-se que as OWA constituem um proximo passo logico e evolutivo aproxi-

mando a web do desktop Referem-se ainda os principais factores que justificam a

importancia das OWAs e a estreita relacao que tem com as Rich Internet Application

(RIA)s

21 Evolucao das arquitecturas de software

Os termos thin-client e fat-client sao utilizados quer para descrever arquitecturas

logicas (de software) quer para descrever arquitecturas fısicas (de hardware) Neste

capıtulo excepto quando seja dada indicacao em contrario estes termos referem-se

sempre a uma arquitectura logica

Adicionalmente quando se trata de arquitecturas cliente-servidor pode-se estu-

dar a arquitectura desenvolvida do sistema como um todo da arquitectura do servi-

dor ou da arquitectura do cliente Para evitar equıvocos em especial na seccao 213

especifica-se em cada caso qual o sistema estudado

211 Thin-clients

Um thin-client e um computador cliente ou software cliente que no contexto

de uma arquitectura cliente-servidor depende de um servidor central para as suas

5

Enquadramento do Projecto

actividades de processamento e proporciona um canal de entrada e saıda de in-

formacao entre o utilizador e o servidor remoto Este termo quando aplicado a

hardware refere-se habitualmente a um computador que se destina a ser utilizado

como cliente de rede sem armazenamento local e com capacidade de processamento

reduzida [Gro02b] mas o conceito que aqui se analisa refere-se a uma arquitectura

de software que remonta ao inıcio das aplicacoes cliente-servidor

No inıcio da historia da computacao terminais ligavam-se directamente a main-

frames responsaveis por todo o processamento Nesta arquitectura era necessario

desenvolver duas aplicacoes distintas uma aplicacao central no servidor (main-

frame) responsavel pela gestao de toda a informacao e por todas as operacoes de

comunicacao e uma aplicacao de visualizacao instalada no cliente (terminal) O

papel destes terminais era apenas disponibilizar ao utilizador um meio de comu-

nicacao (entrada e saıda) e apresentacao dos resultados do servidor Nao tinham

um papel activo no calculo nem na logica de negocio e frequentemente nao tinham

tambem nenhum mecanismo de armazenamento de dados

Como vantagens esta arquitectura apresenta uma reduzida necessidade de con-

figuracao e manutencao do lado do cliente Uma vez que o centro do processamento

e manipulacao de dados ocorre no servidor existe tambem uma centralizacao da

informacao [NJN00] que introduz um ponto crıtico de falha1 Actualizacoes e novas

funcionalidades sao faceis de distribuir uma vez que requerem apenas alteracoes no

servidor [Gro02a]

212 Fat-clients

Contrastando com os thin-clients nesta arquitectura os clientes implementam

ja uma parte da logica de negocio e sao responsaveis pelo processamento de dados

Estes fat-clients vieram responder a necessidade crescente de aplicacoes com um

nıvel de interactividade e capacidade de configuracao maior que as oferecidas pela

arquitectura thin-client descrita na seccao 211 Apesar de manterem a sua de-

pendencia do servidor podem tambem ser executados sem uma conexao activa uma

vez que dispoe de armazenamento de dados local o que lhes confere a capacidade

de persistencia de dados e do estado de execucao entre cada sessao

Foi disponibilizando este controlo sobre o estado da aplicacao bem como acesso

a recursos locais (por exemplo sistema de ficheiros e perifericos) que surgiram as

primeiras verdadeiras desktop applications No entanto cada cliente tinha que ser

separadamente instalado no computador pessoal de cada utilizador que pretendesse

utilizar ou interagir com a aplicacao e uma actualizacao ao servidor implicava in-

variavelmente uma actualizacao manual tambem no cliente Uma vez que nem todos

1NT single point of failure

6

Enquadramento do Projecto

Thin-clients Fat-clientsNao toma parte no processamento dedados nem possui acesso ao sistema deficheiros

Participa activamente no processa-mento de dados recorrendo ao sis-tema de armazenamento local para ar-mazenamento de dados

Nao mantem registo do estado logicoda aplicacao entre duas sessoes de uti-lizacao

O acesso ao armazenamento localpermite-lhe manter registo do estadologico da aplicacao entre duas sessoes

O thin-client nao necessita de qualquerinstalacao estando ldquopronto a utilizarrdquo

E geralmente necessario instalar aaplicacao para poder interagir com oservidor

Qualquer update no servidor reflecte-seimediatamente por todos os clientes

Embora a aplicacao cliente possa aler-tar para existencia de novas versoes asactualizacoes tem que ser manualmenteinstalados pelo cliente

O software do cliente destina-se apenasa apresentacao de dados e comunicacaocom o servidor sendo portanto de sim-ples implementacao

Como o software do cliente toma parteactiva no processamento de dadosa sua implementacao requer cuidadosadicionais

Grande mobilidade uma vez que todaa informacao e mantida no servidor

Parte da informacao podera estar ape-nas do lado cliente pelo que existemalgumas restricoes a sua mobilidade

Tabela 21 Comparacao entre thin-clients e fat-clients

os utilizadores actualizam regularmente as suas aplicacoes o servidor tem que estar

preparado para lidar com versoes antigas2 ou descontinuar os seus servicos a uma

parte da sua comunidade de utilizadores ate que estes actualizem os seus sistemas

Como os utilizadores passam a utilizar os seus recursos locais para armazenamento

de dados as alteracoes que nao sejam sincronizadas com o servidor estao apenas

disponıveis nos seus computadores pessoais o que introduz uma restricao a mobili-

dade

Pode-se afirmar que as vantagens dos thin-clients sao as desvantagens dos fat-

clients e que as vantagens dos fat-clients sao as vantagens dos thin-clients tal como

se ilustra na Tabela 21

213 Arquitecturas cliente-servidor

Introduzidos os termos thin-client e fat-client interessa reafirmar que ambos

podem ser vistos como arquitecturas cliente-servidor Um cliente define-se como

um solicitador de servicos e um servidor como um prestador de servicos tal como

definido por [Sch96] e [Sad97]

2NT backward compatibility

7

Enquadramento do Projecto

As arquitecturas cliente-servidor sao categorizadas pela modularizacao com que

sao desenhadas sendo consideradas as seguintes camadas

1 Interface grafica (front-end) atraves da qual os utilizadores interagem com

a aplicacao Quando este modulo e implementado separadamente dos outros

dois constitui uma aplicacao thin-client por si so uma vez que nao implementa

regras de negocio (embora possa definir validacoes de formularios de insercao de

dados por exemplo) A informacao introduzida pelo utilizador e enviada para

o servidor que processa o seu pedido e retorna uma resposta Este processo

repete-se ate que o utilizador atinja o seu objectivo ou se desligue do sistema

2 A logica de negocio tambem designada por camada intermedia que imple-

menta as regras de aceitacao e validacao de todos os dados introduzidos pelo

utilizador E tambem a plataforma de comunicacao que une a camada superior

de visualizacao com a camada de acesso a dados

3 A camada de dados inclui quer o sistema de persistencia de dados onde sao

armazenados os dados relevantes como tambem os mecanismos necessarios

para a sua pesquisa seleccao e alteracao

Os thin-clients quando observados no seu conjunto de cliente e servidor podem

ser vistos quer como sistemas de duas camadas quer como sistemas de tres camadas

dependendo apenas da forma como o servidor for implementado No caso de na

implementacao do servidor nao se distinguir a camada de acesso a dados da camada

da logica de negocio sao designados por sistemas de duas camadas Caso seja feita

esta distincao sao designados por sistemas de tres camadas Ambos os casos sao

ilustrados na Figura 21

Historicamente os fat-clients eram implementados numa arquitectura em duas

camadas Possuıam apenas um modulo de visualizacao de dados designado por

camada de interface e um modulo que implementava toda a logica de negocio e

regras de acesso a base de dados No entanto com a introducao de ligacoes mais

rapidas e de computadores pessoais com maior capacidade de processamento e so-

bretudo devido a complexidade crescente das aplicacoes a logica de negocio e a

camada de acesso a dados tornaram-se independentes Este modelo e designado por

arquitectura em tres camadas e e ilustrado na Figura 22

22 Evolucao na Internet

Ao analisar a evolucao das arquitecturas das aplicacoes desenvolvidas para a

Internet podemos encontrar um paralelismo com a historia da arquitectura de soft-

ware

8

Enquadramento do Projecto

Figura 21 Arquitectura de um sistema thin-client em duas camadas (a esquerda) e emtres camadas (a direita) Note-se a inclusao do servidor (mainframe) na definicao dascamadas desta arquitectura devido a forte dependencia cliente-servidor

221 Paginas web estaticas

Uma pagina web estatica devolve sempre a mesma resposta a todos os pedidos

para todos os utilizadores e em qualquer contexto utilizando o hipertexto como

forma de ligacao entre diversas paginas estaticas

A informacao e armazenada num servidor e o papel do cliente e apenas a apre-

sentacao da informacao Esta forma de disponibilizacao de informacao pode assim

ser comparada com os thin-clients descritos na seccao 211 o utilizador acede a

um website estatico para visualizar informacao sem que o cliente tome parte no

processamento A unica diferenca e que no caso da web estatica a informacao ap-

resentada e sempre a mesma enquanto que nos thin-clients era frequente existir a

possibilidade de insercao de dados no cliente e apos o seu processamento servidor

nova informacao poderia ser apresentada O hipertexto e utilizado para ligar as

paginas entre si numa rede de conteudos relacionados e a navegacao sıncrona era

feita atraves de cliques do rato a cada clique uma nova pagina era apresentada

Este modelo sıncrono e ilustrado na Figura 23

222 Paginas web interactivas e paginas web dinamicas

O JavaScript e uma linguagem interpretada de scripting que tem os browsers

como principal ambiente de acolhimento Os browsers utilizam uma Application

9

Enquadramento do Projecto

Figura 22 Arquitectura de um fat-client em duas camadas (a esquerda) e em tres camadas(a direita)

Programming Interface (API) publica para criar ldquoobjectosrdquo responsaveis por reflectir

e disponibilizar o Document Object Model (DOM) para o motor de JavaScript

A utilizacao mais frequente desta linguagem e a escrita de funcoes que sao em-

bebidas ou incluıdas em paginas web e que interagem com o DOM Uma vez que o

JavaScript e executado localmente (na maquina do cliente e nao no servidor) e capaz

de responder rapidamente a accoes do utilizador tornando a execucao de aplicacoes

no browser mais fluıdas o JavaScript pode tambem detectar accoes do utilizador

que o HTML nao pode tal como o pressionar de uma tecla

Em Dezembro de 1995 a Netscape Communications adicionou suporte para o

JavaScript no browser Netscape Navigator3 e em Agosto de 1996 o browser Internet

Explorer4 da Microsoft passou a tambem a suportar uma versao semelhante desta

linguagem (hoje todos os principais browsers suportam esta tecnologia)

Esta inovacao permitiu tornar os websites mais interactivos mas a sua utilizacao

esteve confinada apenas a este proposito durante um longo perıodo As paginas

passaram a responder activamente a accoes do utilizador (sendo uma das utilizacoes

3Netscape Communications ndash httpbrowsernetscapecom4Microsoft Internet Explorer ndash httpwwwmicrosoftcomwindowsproductswinfamilyie

10

Enquadramento do Projecto

mais vulgares a validacao de formularios) mas continuaram essencialmente estaticas

O JavaScript ainda nao era nesta altura utilizado para processar dados

Tambem nesta altura (1995ndash96) surgiram linguagens server-side como o PHP

Hypertext Preprocessor (PHP) e Active Server Pages (ASP) e o servidor passou a ter

um processamento de dados introduzidos pelo utilizador mais activo Generalizaram-

se as paginas dinamicas capazes de responder a insercao de dados ou outros pedidos

determinados por accoes do utilizador As paginas tornaram-se aplicacoes web ap-

plications

Uma definicao tradicional de web application e um conjunto de paginas web

logicamente agrupadas e geridas por uma unica entidade que tem como pontos de

entrada formularios de insercao de dados (web forms) Uma web application nao e

mais do que uma aplicacao que e acedida atraves de um browser Tem geralmente

uma arquitectura logica em tres (interface logica de negocio e camada de dados)

camadas e estao armazenadas num servidor

Ha dois tipos de web applications

bull Orientadas a apresentacao Sao web applications que geram paginas web in-

teractivas constituıdas por varios tipos de linguagens de anotacao (por exem-

plo HTML eXtensible Markup Language (XML)) e que apresentam conteudo

dinamico como resposta a pedidos efectuados pelo utilizador

bull Orientadas aos servicos Uma web application orientada aos servicos imple-

menta o ponto de acesso para um ou mais de um web service Sao geralmente

clientes de service oriented web applications

Uma vantagem significativa de implementar uma web application de forma a

suportar as funcionalidades padrao dos browsers e que estas terao o mesmo com-

portamento independentemente da plataforma e do browser a partir do qual serao

acedidas No entanto diferentes implementacoes de browsers devido a diferentes

interpretacoes dos padroes definidos tornam por vezes esta tarefa um pouco mais

complicada existindo inclusivamente na web guioes de compatibilidade para os difer-

entes browsers como [Smi07]

223 Web 20 e Ajax

O termo web 20 descreve uma tendencia de utilizacao e de design observada

na World Wide Web (WWW) com o objectivo de melhorar a criatividade partilha

de informacao e principalmente a colaboracao entre utilizadores Estes conceitos

levaram ao desenvolvimento e evolucao de comunidades online tais como redes so-

ciais wikis e blogues

11

Enquadramento do Projecto

O termo tornou-se mais conhecido apos a primeira conferencia OrsquoReilly Media

Web 20 em 2004 e apesar de sugerir uma nova versao da WWW nao se refere a

qualquer evolucao tecnologica mas apenas a alteracoes a forma como os utilizadores

se servem da web De acordo com Tim OrsquoReilly [OrsquoR06] ldquoWeb 20 e uma revolucao

na industria do software causada pela adopcao da web como uma plataforma e pela

tentativa de entendimento das regras para o sucesso nesta nova plataformardquo

O desenvolvimento da Web 20 serve-se muitas vezes de um outro conceito Ajax

O conceito que hoje conhecemos como Ajax muitas vezes incorrectamente de-

scrito como uma tecnologia foi originalmente criado para permitir o desenvolvimento

de web applications que se assemelhassem ainda mais a aplicacoes de desktop Este

conceito foi melhor descrito por [Gar05] como um conjunto de varias tecnologias

que podem ser utilizadas para melhorar a experiencia do utilizador de uma dada

web application introduzindo a capacidade assıncrona de envio de pedidos ou da

recepcao assıncrona de respostas As tecnologias mais frequentemente envolvidas

sao

bull eXtensible HyperText Markup Language (XHTML) e Cascading Style Sheets

(CSS) padrao para a apresentacao

bull interaccao dinamica atraves do DOM

bull troca e manipulacao de dados utilizando XML e eXtensible Stylesheet Lan-

guage Transformation (XSLT) ou JavaScript Object Notation (JSON)

bull pedidos assıncronos utilizando XMLHttpRequest [vK08]

bull JavaScript utilizado para integrar todas estas tecnologias

E importante frisar que o Ajax nao e um produto nem uma tecnologia E um

termo que descreve a utilizacao de um conjunto de tecnologias para o desenvolvi-

mento de web applications com um elevado grau de interactividade Comparativa-

mente as web applications tradicionais o Ajax introduz uma camada de visualizacao

diferente em tres importantes pontos

1 Do lado do cliente existe um motor que serve de intermediario entre a interface

da aplicacao e o servidor

2 A actividade do utilizador despoleta chamadas JavaScript em vez de um pedido

de pagina directamente ao servidor

3 Informacao codificada em XML em vez de paginas HTML e trocada entre o

servidor e o cliente

12

Enquadramento do Projecto

Isto significa que as paginas que utilizam Ajax contem um motor do lado do

cliente composto por um conjunto de funcoes JavaScript responsavel pela comu-

nicacao com o servidor e por actualizar a interface com o resultado dessa mesma

comunicacao

Na Figura 23 ilustra-se a natureza assıncrona do Ajax quando comparada com

as web applications tradicionais Como se pode observar adicionando um mecan-

ismo Ajax a uma web application eliminam-se diversos tempos de espera associados

a comunicacoes com o servidor uma vez que a interface nao fica ldquobloqueadardquo a es-

pera da resposta Obtem-se assim aplicacoes com um comportamento mais fluido

eliminando tempos de espera entre cada ldquocliquerdquo e melhorando a experiencia do

utilizador

23 Offline Web Applications

A informacao grafica (bem como folhas de estilo e scripts) tais como as ima-

gens que constituem o visual de uma web application e ja tratada de forma especial

pelos cada vez mais avancados sistemas de cache (armazenamento temporario) dos

browsers Mas estes nao sao ainda capazes de guardar conteudo criado pelo uti-

lizador nem de apresentar informacao independentemente do estado da ligacao

Numa altura onde se fala de servicos de Internet wireless municipalizados [Kha]

comunicacoes 3G e ligacoes de banda larga a alta velocidade a ligacao a rede global

continua a nao estar permanentemente disponıvel para os utilizadores Na WWW

encontra-se uma importante parte da informacao e das aplicacoes utilizadas para

criar e editar conteudos Por vezes informacao vital para a produtividade pode

desaparecer subitamente do mapa de acesso de um utilizador quando este entra no

metro num aviao ou mesmo quando se desloca para uma cidade ou paıs diferente

do habitual onde nao subscreve um plano de acesso que lhe garanta a ligacao

Permitir o acesso offline a estes recursos assume assim a sua importancia porque

permitira estender o alcance da informacao a locais onde nunca esteve antes e per-

mitira tambem melhorar o desempenho das web applications colocando informacao

mais perto dos utilizadores reduzindo a transferencia de dados apenas ao essencial

24 Comparacao

Nas evolucoes descritas neste capıtulo 2 pode-se observar que existe um par-

alelismo entre a evolucao das arquitecturas tradicionais cliente-servidor e a evolucao

a que se assiste na web O comportamento e arquitectura dos thin-clients assemelha-

se ao das paginas estaticas no sentido em que o browser nao toma parte em qualquer

13

Enquadramento do Projecto

processamento e serve apenas como uma plataforma de interaccao com o servidor

tal como os clientes descritos na seccao 211

A sua proxima evolucao os fat-clients trouxeram parte da capacidade de pro-

cessamento para o lado do cliente Na web foi tambem esta a inovacao tecnologica

a que se assistiu com a evolucao das tecnologias que permitiram a criacao de ver-

dadeiras aplicacoes e com a introducao do Javascript no browser dando ao cliente

a capacidade de processamento de dados A necessidade da separacao do codigo

em camadas logicas advem da crescente complexidade das web applications Esta

pratica permite entre outras coisas melhorar o processo de desenvolvimento e a

capacidade de manutencao de uma aplicacao

Os fat-clients tem tambem a capacidade de armazenamento de dados o que

permite a persistencia de informacoes entre duas sessoes e que algumas operacoes

sejam executadas sem a necessidade de comunicacao com o servidor Este facto pode

tambem ser uma realidade nas web applications com a adopcao das tecnologias OWA

Neste momento assiste-se a uma utilizacao cada vez maior da web como uma

plataforma de desenvolvimento A capacidade de cooperacao na edicao de conteudos

e a mobilidade proporcionada por esta plataforma sao os principais factores que

alimentam esta mudanca e pela primeira vez as aplicacoes tradicionais tem com-

peticao vinda de web applications A prova do reconhecimento da web como plataforma

de desenvolvimento pode ser retirada da aposta de empresas como a Adobe e Mi-

crosoft que lancaram publicamente ferramentas web complementares a produtos

seus tradicionalmente associados ao desktop ndash Acrobatcom5 e Microsoft Office

Live6 Dotar estas web applications da capacidade de execucao offline significa

aproximar a web e o desktop reunindo ldquoo melhor de dois mundosrdquo

As vantagens da mobilidade possıvel atraves da web a cooperacao na criacao e

edicao de conteudos e a possibilidade de utilizar aplicacoes sempre actualizadas e

sem necessidade de instalacao sao algumas das principais vantagens que promovem

esta mudanca que devido as preocupacoes associadas a usabilidade e experiencia do

utilizador esta fortemente associada ao desenvolvimento de Rich Internet Applica-

tion (RIA)s

5Adobe Acrobatcom httpwwwacrobatcom6Microsoft ndash httpsmallbusinessofficelivecom

14

Enquadramento do Projecto

Figura 23 Comparacao do modelo de web aplications sıncrono paginas estaticas e in-teractivas abordados nas seccoes 221 e 222 com o modelo de web applications Ajax(assıncrono) abordado na seccao 223 Figura adaptada de http www adaptivepath

com

15

Enquadramento do Projecto

16

Capıtulo 3

Estado da arte

Apesar de o conceito das OWAs nao ser absolutamente novo as tecnologias que

o suportam sao recentes Neste capıtulo descrevem-se quatro tecnologias que foram

tidas como principais candidatas para o desenvolvimento deste projecto Descrevem-

se ainda alguns exemplos de web applications que disponibilizam actualmente fun-

cionalidades offline e o processo da escolha da tecnologia a utilizar neste projecto

31 Gears

O Gears1 e uma extensao as funcionalidades do browser introduzido pelo Google

que tem como principal objectivo tornar possıvel a visualizacao de paginas de Inter-

net mesmo sem uma conexao disponıvel Encontra-se disponıvel para as platafor-

mas Windows Macintosh e Linux e oferece uma API de Javascript que permite

a scripts aceder a um mecanismo de armazenamento local baseado numa base de

dados SQLite

311 Arquitectura

Esta ferramenta e constituıda por tres componentes principais

bull LocalServer mdash Intercepta pedidos de paginas web e serve-as localmente

bull Database mdash Uma base de dados relacional construıda sobre SQLite

bull WorkerPool mdash Permite executar operacoes de computacao de uma forma

assıncrona sem afectar a capacidade de resposta e fluidez de execucao da web

application Assemelham-se a processos

1Google Inc ndash Mais informacao em httpgearsgooglecom

17

Estado da arte

LocalServer

O modulo LocalServer e uma cache de Uniform Resource Locators (URLs)

controlada pela web application Quando nao existe uma ligacao a Internet e e

feito um pedido para um URL presente nesta cache o LocalServer intercepta-o e

responde ao pedido localmente a partir do disco rıgido do utilizador A aplicacao

pode utilizar dois tipos diferentes de armazenamento local de URLs

bull ResourceStore ndash serve para capturar URLs utilizando exclusivamente a API

de Javascript disponibilizada para o efeito Uma aplicacao podera criar e

utilizar diversos ResourceStores simultaneamente para capturar ficheiros de

dados que necessitam de ser enderecados por um URL tal como um ficheiro

PDF ou uma imagem

bull ManagedResourceStore ndash serve para capturar um conjunto de URLs que estao

relacionados e que sao declarado num ficheiro de manifesto (especificado em

JSON) e que sao automaticamente actualizados O ManagedResourceStore

permite que o conjunto de recursos necessarios para correr uma web application

seja capturado e mantido actualizado automaticamente

A principal diferenca entre estes dois tipos de armazenamento de URLs e a forma

como sao actualizados os seus conteudos Os conteudos de um ManagedResourceStore

sao actualizados sempre que a versao contida no ficheiro de manifesto for alterada

enquanto que os conteudos de um ResourceStore nunca sao actualizados automati-

camente mas apenas quando for explicitamente ordenado pela aplicacao

O LocalServer e capaz de interceptar e servir localmente pedidos de HTTP e

HTTPS sempre que se reunam as seguintes condicoes

1 O URL encontra-se armazenado num ResourceStore ou ManagedResourceStore

2 O sistema de armazenamento local encontra-se activo (enabled = true) Se

o sistema de armazenamento local tiver o atributo requiredCookie o pedido

devera conter um cookie que lhe corresponda

O LocalServer nao necessita de monitorizar o estado da ligacao para atender aos

pedidos Na verdade sempre que as condicoes previamente enunciadas se verificarem

o LocalServer interceptara os pedidos e independentemente do estado da ligacao

a Internet servi-los-a a partir do disco rıgido local Cabera a aplicacao definir qual

o modo em que pretende executar um pedido (online ou offline) definindo o valor

de verdade da propriedade enabled

18

Estado da arte

Database

O modulo Database permite guardar dados da web application assegurando a

sua persistencia Os dados sao guardados de forma relacional no disco rıgido do uti-

lizador2 de acordo com o modelo de seguranca estabelecido pelo Gears3 significando

que uma aplicacao nao pode aceder a conteudos fora do seu domınio

WorkerPool

Nos web browsers uma operacao pesada de computacao pode tornar a interface

lenta e tornar menos agradavel a experiencia do utilizador O modulo WorkerPool

permite correr operacoes em background sem bloquear a interface com o utilizador

Os scripts executados numa WorkerPool nao activam os mecanismos de seguranca

do browser que mostram a mensagem ldquoA script on this page may be busy or may

have stopped respondingrdquo

O WorkerPool comporta-se como um conjunto de processos em vez de threads

Os Workers nao partilham qualquer estado de execucao o que significa que uma

alteracao a uma variavel num Worker nao afecta em nada a execucao de outro

Worker Alem disso os Workers nao herdam automaticamente nenhum codigo dos

seus pais Cada Worker e membro de um WorkerPool e os Workers podem in-

teragir entre si enviando mensagens em formato de texto ou JSON No entanto ha

tambem algumas limitacoes os Workers nao tem acesso ao DOM e objectos como

window ou document nao se encontram acessıveis Isto e consequencia de os Workers

nao partilharem o estado de execucao Mas tem acesso a todas as funcoes built-in

do Javascript A maioria das funcionalidades do Gears pode tambem ser acedida

atraves de uma variavel global especial definida como googlegearsfactory Para

outras funcionalidades especıficas os Workers podem ldquopedirrdquo a pagina principal para

continuar a execucao atraves do envio de mensagens

Outras funcionalidades

bull HttpRequest ndash Este modulo implementa a especificacao W3C XmlHttpRe-

quest definida em [vK08] tornando-a disponıvel para os workers e para a

pagina principal

bull Timer ndash Este modulo implementa a especificacao de timers tal como descrito

por [Hic08] e torna-os disponıveis para os workers e para a pagina principal

2Consultar httpcodegooglecomapisgearsapi_databasehtmldirectories3Consultar httpcodegooglecomapisgearssecurityhtml

19

Estado da arte

bull Factory ndash Esta classe e utilizada para instanciar todos os outros objectos da

API do Gears atraves do seu metodo create Este metodo pode ser utilizado

com os seguintes parametros

ndash betadatabase

ndash betahttprequest

ndash betalocalserver

ndash betatimer

ndash betaworkerpool

312 Goggle Gears em dispositivos moveis

O Gears esta tambem disponıvel em dispositivos Windows Mobile 5 e 6

Os dispositivos moveis estao pela sua natureza frequentemente desconectados

da Internet Mesmo quando possuem uma ligacao as latencias na transferencia de

dados em redes moveis tornam as aplicacoes pouco fluıdas mas o Gears permite

ultrapassar este obstaculo

O Gears funciona exactamente da mesma forma em dispositivos moveis equipados

com o Windows Mobile 5 e 6 como num computador comum Se uma aplicacao tiver

sido implementado com suporte para o Gears entao tambem estara preparada para

ser executada num dispositivo movel mas as limitacoes dos browsers disponıveis

para dispositivos moveis tem que ser consideradas Isto significa prever as condicoes

que permitam uma boa usabilidade devido aos pequenos ecras destes dispositivos

bem como o seu suporte limitado dos padroes do DOM CSS e JavaScript

32 Adobe AIR

O Adobe AIR4 e um runtime compatıvel com diversos browsers e sistemas opera-

tivos que pretende dar aos programadores a possibilidade de combinar diversas tec-

nologias de producao de conteudos para a Internet no desenvolvimento de Rich Inter-

net Application (RIA)s O Adobe AIR mantem uma relacao com o browser mas es-

tende as suas capacidades e tecnologias permitindo o desenvolvimento de aplicacoes

tambem para o ambiente de trabalho com janelas em tudo semelhantes as do sis-

tema operativo Segundo a Adobe o objectivo e complementar o browser dando

aos utilizadores (mas essencialmente aos programadores e equipas de desenvolvi-

mento) a escolha sobre como distribuir as suas aplicacoes Para este efeito o Adobe

AIR tem uma aproximacao diferente do Gears Em vez de ldquoestenderrdquo o browser

acrescentando-lhe funcionalidades o AIR permite tambem o desenvolvimento de

4Adobe - httpwwwadobecomproductsair

20

Estado da arte

aplicacoes que se destinam a ser executadas fora do ambiente do browser mas uti-

lizando as tecnologias comuns da Internet (por exemplo HTML CSS JavaScript

Flash Flex)[CDGH08]

A utilizacao desta tecnologia permite utilizar o browser ou o proprio runtime

Adobe AIR como plataforma de execucao da aplicacao

Na Tabela 31 faz-se uma comparacao das funcionalidades disponıveis de acordo

consoante se escolha o browser ou o desktop como plataforma base para a aplicacao

Uma vez que as aplicacoes Adobe AIR na plataforma desktop tem um caracter

persistente (sao instaladas no computador do utilizador) o Adobe AIR tem um

modelo de seguranca que se assemelha com o das tradicionais aplicacoes desktop

[Ada08] Este modelo e analisado nas seccoes 321 e 322 O ambiente em que

e executado o browser e restringido a execucao de web applications que podem

ser de varias origens (incluindo de origens anonimas ou sem confianca) O Adobe

AIR proporciona acesso a capacidades como acesso a ficheiros que necessitam da

confianca do utilizador

bull HTML ndash O desenvolvimento de aplicacoes para o Adobe AIR pode ser feito

com recurso a tecnologias de HTML e Ajax comuns utilizando as linguagens

de markup existentes distribuıdas como texto e interpretadas em execucao

(runtime)

bull Flash ndash Outra alternativa sera a utilizacao da linguagem Flash Permite a

renderizacao de graficos vectoriais e audiovıdeo com suporte nativo Utiliza

ActionScript para adicionar maior interactividade com o utilizador

bull Flex ndash O Flex e uma framework open source para o desenvolvimento de RIAs

usando Flash As aplicacoes Flex sao na realidade Flash sendo a principal

diferenca o ambiente de desenvolvimento

Como resultado uma aplicacao AIR podera ser implementada

bull Baseada em Flash ou Flex (aplicacoes cujo conteudo base e em ShockWave

Flash (SWF))

bull Baseada em Flash ou Flex tambem com HTML ou Portable Document Format

(PDF) Aplicacoes cujo conteudo de base e em FlashFlex (SWF) com HTML

(HTML JavaScript CSS) ou conteudo PDF incluıdo

bull Baseada em HTML Aplicacoes cujo conteudo base e em HTML Javascript

CSS

bull Baseada em HTML utilizando tambem FlashFlex ou PDF

21

Estado da arte

Os utilizadores interagem com uma aplicacao AIR da mesma forma que interagem

com outras aplicacoes com janelas nativas do seu sistema operativo O runtime e

instalado uma vez no computador do utilizador e a partir desse momento todas as

aplicacoes AIR terao o mesmo aspecto que qualquer outra aplicacao para o desktop

321 Seguranca

Permitir que uma web application aceda ao disco de armazenamento do utilizador

pode comprometer seriamente a sua seguranca Neste sentido o Adobe AIR tem

suporte para assinaturas digitais (Secure Sockets Layer (SSL)) que podem ser com-

pradas pelas equipas de desenvolvimento que o desejem e cujos certificados serao

apresentados ao utilizador no momento da instalacao Um outro aspecto ainda

relativo a seguranca e o mecanismo de isolamento de cada ambiente (sandbox )

322 Assinatura do codigo

O runtime AIR exige que todas as aplicacoes estejam digitalmente assinadas As

assinaturas digitais de codigo sao um processo que visa garantir a integridade da

aplicacao e a identidade do seu autor no momento da instalacao As equipas de

desenvolvimento podem ldquoassinarrdquo uma aplicacao utilizando um certificado atribuıdo

por uma Entidade Certificadora (Certification Authority) ou atraves de um certifi-

cado individual (self signed certificate) Neste momento o Adobe AIR suporta como

entidades certificadoras a Verisign e a Thawte [Ado08]

O instalador apresenta o nome de quem publica a aplicacao quando o codigo tiver

sido assinado com um certificado que apresente confianca ou que esteja encadeado

com um certificado que tenha ja sido aceite no computador em que se esta a instalar

a aplicacao

As equipas de desenvolvimento podem tambem assinar as aplicacoes com um

certificado auto-atribuıdo (um certificado criado por elas proprias) mas neste caso

o instalador apresentara estas aplicacoes como sendo de uma origem nao verificada

O AIR utiliza a infraestrutura publica de chaves [Ent07] suportada pelo arquivo

local do sistema operativo Para que a origem da aplicacao seja reconhecida o

computador onde a aplicacao AIR esta a ser instalada tem que confiar directamente

no certificado que foi utilizado para assinar a aplicacao ou confiar num certificado

que esteja num encadeamento logico de certificados confiados e que se ligue desta

forma ao certificado utilizado para assinar a aplicacao

Todas as aplicacoes AIR tem caracterısticas em comum independentemente da

tecnologia utilizada para o seu desenvolvimento (HTMLFlexFlash) No ambito

de uma aplicacao AIR existem um conjunto de APIs que estao disponıveis e que

tornam possıvel o acesso ao sistema local (leitura e escrita) e a recursos de rede que

22

Estado da arte

de outra forma nunca estariam acessıveis a partir de uma web application comum

Cada aplicacao AIR possui tambem diferentes nıveis de isolamento chamados secu-

rity sandboxes dependendo do tipo de conteudo que esta a ser carregado e do seu

objectivo

bull Isolamento ao nıvel da aplicacao5 ndash E a raiz de cada aplicacao AIR Este

nıvel de isolamento permite o acesso a APIs privilegiadas e especıficas do

AIR Em contrapartida e negado o acesso a algumas APIs que poderiam ser

facilmente utilizadas de forma maliciosa contra o utilizador final Importacao

dinamica de conteudos remotos e geralmente proibido e as tecnicas e mecan-

ismos de geracao dinamica de codigo sao fortemente restringidas Apenas

conteudo carregado directamente da directoria base da aplicacao podera ser

colocado neste nıvel de isolamento

bull Isolamento nao especıfico da aplicacao6 ndash contem todo o outro conteudo

que nao tenha sido carregado directamente para o isolamento da aplicacao

Isto inclui conteudo local e remoto Este tipo de conteudo nao tem acesso

directo as APIs do AIR e rege-se pelas mesmas regras tal como se tivesse sido

carregado por um browser a partir da mesma localizacao (por exemplo HTML

carregado a partir de um domınio remoto comporta-se da mesma forma que se

fosse acedido a partir do browser)

33 Mozilla Prism

331 XML User Interface Language

O eXtensible User Interface Language (XUL) e uma linguagem de anotacao

baseada em XML desenvolvida pela Mozilla Foundation que opera em aplicacoes

Mozilla multi plataforma tal como o Firefox O motor Gecko e a unica imple-

mentacao completa desta linguagem que foi desenhada sobre padroes web comuns

como CSS JavaScript e o DOM e permite o desenvolvimento de interfaces graficas

utilizando elementos pre-definidos tais como window box page textbox radio

button entre outros Infelizmente o XUL nao possui qualquer especificacao formal

ou implementacoes de inter-operabilidade para outros motores que nao o Gecko No

entanto a sua implementacao e licenciada em codigo aberto pelas licencas GNU Gen-

eral Public License (GPL) GNU Lesser General Public License (LGPL) e Mozilla

Public License (MPL)

Enunciam-se algumas caracterısticas desta linguagem

5NT application sandbox6NT non-application sandbox

23

Estado da arte

Liguagem de anotacao poderosa baseada em componentes (widgets) O ob-

jectivo do XUL e permitir a construcao de aplicacoes multi-plataforma em

claro contraste com o Dynamic HyperText Transfer Protocol (DHTML) que se

destina ao desenvolvimento de paginas web Por esta razao o XUL esta orien-

tado a componentes tais como janelas botoes e etiquetas em vez de paginas

cabecalhos de texto e ligacoes de hipertexto Investir tempo e esforco para

atingir este mesmo resultado em aplicacoes baseadas em DHTML compromete

frequentemente a complexidade e desempenho da aplicacao

Baseado em padroes O XUL e um dialecto XML baseado no padrao W3C XML

10 As aplicacoes escritas em XUL sao tambem baseadas em especificacoes

W3C adicionais como HTML 40 CSS DOM nıvel 1 e 2 JavaScript 15

incluindo ECMA-262 Edition 3 (ECMAscript)

Portabilidade entre plataformas Tal como HTML o XUL foi desenhado para

ser independente da plataforma em que e utilizado tornando as aplicacoes

facilmente portaveis entre sistemas operativos nos quais o Mozilla e suportado

Uma vez que o XUL oferece um nıvel de abstraccao dos componentes graficos

de interface que disponibiliza implementa a premissa ldquoum codigo para todas

as plataformasrdquo A interface grafica de todos os produtos centrais Mozilla

(browser instant messenger livro de enderecos) e escrita em XUL com um

unico codigo base que suporta todas as plataformas Mozilla

Separacao entre o nıvel de apresentacao e a logica de negocio Uma das

maiores preocupacoes no desenvolvimento para a Internet e a forte ligacao

entre estas duas camadas (interface e logica) Isto constitui um problema sig-

nificativo no desenvolvimento de grandes aplicacoes especialmente quando o

desenvolvimento e feito em ambientes de equipa porque as capacidades de de-

senvolvimento destas duas partes da aplicacao estao muitas vezes espalhadas

por diferentes elementos O XUL permite uma clara distincao entre a definicao

da aplicacao cliente e da logica de implementacao (XUL eXtensible Binding

Language (XBL) e JavaScript) apresentacao (CSS e imagens) internacional-

izacao (Document Type Definitions (DTDs) e etiquetas de texto em lınguas

especıficas guardados em ficheiros properties) O esquema grafico e apre-

sentacao de uma aplicacao XUL pode ser alterado de forma independente da

sua logica ou implementacao e a aplicacao pode ainda ser traduzida (interna-

tionalization) de forma independente da sua logica implementacao ou apre-

sentacao Este grau de separacao resulta em aplicacoes que sao mais faceis de

manter pelos programadores e facilmente adaptadas por designers e tradutores

24

Estado da arte

Facil adaptacao Outro benefıcio que advem do nıvel de separacao entre logica

de negocio e apresentacao oferecido pelo XUL e a facilidade com que se pode

adaptar uma aplicacao para diferentes clientes ou grupos de utilizadores Um

programador pode utilizar a mesma aplicacao base e adapta-la consoante as

necessidades atraves de diferentes temas (skins) e ficheiros de lınguas Desta

forma uma aplicacao escrita e desenvolvida em Ingles pode ser rapidamente

traduzida para Portugues e distribuıda com outra aparencia mais apropriada

ao cliente alvo

332 Prism

O Mozilla Prism e um browser simplificado e ldquointerpretadorrdquo de XUL (tambem

designado por XULRunner) que acolhe web applications sem a interface grafica ha-

bitual de um browser Baseia-se num conceito designado por Site Specific Browser

(SSB) Um SSB e uma aplicacao com um browser embebido desenhado para exe-

cutar apenas uma web application Nao possui os menus e barras de ferramentas

habituais Um SSB tem uma integracao com o sistema operativo e com o desktop

muito mais estreita do que uma web application acedida atraves de um browser uma

vez que e executado em janela propria

O Prism resulta de uma experiencia da Mozilla e visa reduzir as diferencas entre

as desktop applications tradicionais e as web applications Um dos aspectos focados e

a experiencia do utilizador Numa apresentacao oficial e dito que ldquo[o Prism] pretende

ser uma ponte entre as diferencas que existem entre as aplicacoes tradicionais de

desktop e as web applications explorando novos modelos de usabilidade enquanto

que a linha que as separa se continua a definirrdquo [Lab07]

34 HTML 5

A especificacao HTML 5 [Hic08] que se encontra em fase de desenvolvimento

pelo grupo WHATWG pretende ser uma norma de substituicao dos padroes HTML

4 XHTML 1x e do DOM2 HTML Uma das propriedades que o distingue das tec-

nologias que pretende substituir e precisamente o suporte para OWA e armazena-

mento de dados no cliente de uma forma relacional Nao sendo propriamente uma

tecnologia ndashmas antes uma especificacao ndashe aqui mencionada por ter servido como

referencia a diversas implementacoes de funcionalidades offline e por se considerar

que venha a ter um impacto significativo nas implementacoes de diversos browsers

Dion Almaer defendeu no seu blogue que o Gears era uma implementacao do

HTML 5 No seu artigo ldquoGears as a bleeding-edge HTML 5 implementationrdquo [Alm08]

o autor diz que ambos ndasho Gears e o HTML 5 ndashpretendem dar a web caracterısticas

25

Estado da arte

semelhantes e nao encontrar motivo de ldquocompeticaordquo entre as duas mas que en-

quanto o HTML 5 e uma especificacao o Gears e uma implementacao

No entanto tambem e verdade que o HTML 5 cobre muitos outros pontos para

alem das OWA que saem completamente fora do ambito do Gears Se esta es-

pecificacao atingir um estado de maturidade que possibilite a sua adopcao pelos

principais browsers tornando nativo do browser o suporte OWA entao deixara de

fazer sentido a existencia de uma extensao como o Gears

A especificacao HTML 5 disponibiliza duas APIs relevantes para o tema das

OWA

1 Uma base de dados baseada em SQL que permite o armazenamento de dados

do lado do cliente

2 Uma ldquocacherdquo HTTP que garante a disponibilidade das aplicacoes mesmo quando

o utilizador nao possui uma ligacao a Internet

Estas caracterısticas sao as bases da tecnologia das OWA e tem correspondencia

com os pontos analisados nas seccoes 311 e 311

35 Web applications que usam funcionalidades offline

Nesta seccao apresentam-se algumas web applications que actualmente disponi-

bilizam funcionalidades offline Estas aplicacoes foram escolhidas para uma analise

mais pormenorizada por utilizarem o Gears que tal como descrito na seccao 4 foi

a tecnologia escolhida para o projecto

351 Google Reader e Google Docs

O Google Reader7 e um leitor de feeds RSS Permite gerir a subscricao de varios

sites simultaneamente que disponibilizem conteudos neste formato e foi a primeira

web application da Google com uma versao offline publicamente acessıvel (desde

Junho de 2007)

O Google Reader implementa o modo ldquoutilizador deciderdquo oferecendo na sua

interface um botao que permite alternar entre os modos online e offline

O Google Docs8 e uma web application que permite a criacao e edicao de doc-

umentos de texto folhas de calculo e apresentacoes Era ja publico desde Janeiro

de 2008 que o Google estava a desenvolver uma versao OWA desta aplicacao mas o

acesso a uma versao experimental so foi possıvel a partir de 31 de Maio de 2008

7Google Reader - httpreadergooglecom8Google Docs - httpdocsgooglecom

26

Estado da arte

A implementacao das funcionalidades offline nestas duas aplicacoes seguiu difer-

entes aproximacoes principalmente porque o Google Reader apresenta ao utilizador

informacoes que sao fornecidas por fontes externas enquanto que no Google Docs

a informacao e criada e editada pelo utilizador sobre a forma de documentos

A diferente origem da informacao implica que no Google Reader seja necessario

prever casos de excepcao tal como existirem demasiados itens que necessitam de

ser transferidos para o cliente Nao observar este ponto causa um problema grave

de usabilidade e para evitar tempos de espera demasiado longos e uma interface

com pouca capacidade de resposta as accoes do utilizador o Google Reader apenas

transfere para o cliente os dois mil itens mais recentes na transicao para o modo

offline

352 Remember the Milk

O Remember The Milk9 e uma web application desenvolvida por uma equipa

Australiana que proporciona funcionalidades de agenda gestao de tempo e de tare-

fas e foi uma das primeiras aplicacoes independentes do Google a adoptar o Gears

para acessos em modo offline Permite que os seus utilizadores facam uma gestao

de tarefas agrupando-as em listas adicionando-lhes campos de informacao adicional

ou dando-lhes informacao geografica (recorrendo ao servico Google Maps10) Entre

a sua lista de funcionalidades encontra-se ainda a possibilidade de importar e ex-

portar eventos no formato iCalendar (ics) etiquetas (tags) em tarefas publicacao

Really Simple Syndication (RSS) e partilha de categorias de tarefas de acordo com

diferentes nıveis de permissoes de acesso definidos pelo utilizador

353 MySpace e WordPresscom

O MySpace uma das maiores social networks na Internet anunciou recente-

mente que vai disponibilizar uma versao do seu cliente de e-mail que utiliza o Gears

para acelerar o seu desempenho Numa fase inicial estara disponıvel apenas para

utilizadores que tenham cinco mil ou mais mensagens na sua caixa de correio e

permitira efectuar pesquisas muito mais rapido que a sua versao online

O servico de blogs Wordpresscom anunciou tambem o inıcio da utilizacao desta

tecnologia com o fim de melhorar o desempenho A versao que utiliza esta tecnologia

descarrega e armazena no cliente um conjunto de imagens e scripts que passam a

ter preferencia sobre os seus congeneres online e que permitem acelerar o processo

de carregamento da aplicacao e visualizacao de blogs

9Remember The Milk ndash httpwwwrememberthemilkcom10Google Maps ndash httpmapsgooglecom

27

Estado da arte

O MySpace e o Wordpresscom sao dois exemplos da utilizacao da tecnologia

OWA para optimizacao de web application ja existentes Sem pretenderem disponi-

bilizar uma versao que seja totalmente offline fazem uso do Gears para armazenar no

cliente parte dos recursos frequentemente acedidos na visualizacao das suas paginas

36 Escolha da tecnologia

Apos a analise das tecnologias apresentada nas seccoes 31 a 34 foi necessario es-

tudar a adequacao de cada uma delas ao projecto em questao Desde logo e possıvel

observar que nem todas se dedicam apenas a OWA Por exemplo o Adobe AIR

apesar de ter suporte para OWA apenas disponibiliza algumas das funcionalidades

identificadas como mais indicadas para a execucao do projecto quando utilizado

na sua vertente desktop tal como exposto na Tabela 31 mas a utilizacao desta

vertente implicaria o desenvolvimento de novas interfaces e de novas formas de co-

municacao (troca de mensagens XML ou JSON) A vertente web do Adobe AIR

foca-se mais especificamente nas Rich Internet Applications e permite a reutilizacao

do codigo ja existente (exigindo naturalmente a sua adaptacao e a implementacao

das funcionalidades pretendidas)

A tecnologia escolhida para a realizacao deste trabalho foi o Gears sendo que

um dos principais factores a influenciar esta opcao foi a liberdade introduzida pela

sua licenca Berkeley Software Distribution (BSD)11

Considerou-se o funcionamento desta ferramenta extremamente adequando a

aplicacao no WOW uma vez que o seu principal objectivo e precisamente tornar

possıvel a execucao offline de uma pagina web e por virtude deste facto o Gears tem

uma API concisa e de simples aplicacao pratica uma vez que nao possui quaisquer

outros elementos distractores O funcionamento do seu ManagedResourceStore ex-

emplificado na Figura 31 com a capacidade de actualizacao de recursos definidos

num ficheiro manifesto especificado em JSON pesou tambem nesta decisao

11Sobre a licenca BSD consultar httpwwwopensourceorglicensesbsd-licensephp e http

wwwlinfoorgbsdlicensehtml

28

Estado da arte

Figura 31 Esquema UML do processo efectuado pelos recursos do Gears do tipoManagedResourceStore para a actualizacao dos conteudos definidos no ficheiro manifesto

29

Estado da arte

Funcionalidade RIAs no browser RIAs no desktop

Disponibilidadeda aplicacao

As aplicacoes podem ser facil-mente exploradas e utilizadas

As aplicacoes quando instal-adas tem maior grau de fun-cionalidades e persistencia

Instalacao Nao e necessario qualquer tipode instalacao

As aplicacoes sao instaladasatraves do browser ou descar-regadas e instaladas comouma aplicacao tradicional

Actualizacoes Aplicacoes sao actualizadascarregando conteudos paraum website

O AIR disponibiliza uma APIque permite que as aplicacoessejam actualizadas de umaforma

Sistemas opera-tivos suportados

As aplicacoes podem ser exe-cutadas em diversos sistemasoperativos e browsers

As aplicacoes sao multi-plataforma e podem serinstaladas e executadas emdiversos sistemas operativos ebrowsers

Linguagens deprogramacao

Javascript e disponibilizadopelo browser e ActionScripte disponibilizado pelo AdobeFlash Player

Maquinas virtuais deJavascript e ActionScriptcompatıveis com o browser

Capacidade deexecucao embackground

As RIAs podem ser execu-tadas numa janela do browser

As aplicacoes podem ser ex-ecutadas em background edisponibilizar notificacoes talcomo uma aplicacao tradi-cional

Persistencia A actividade esta limitada asessao do browser Quando obrowser e encerrado toda ainformacao e descartada

As aplicacoes sao instaladas eestao disponıveis no desktopPodem armazenar informacaolocalmente e estao disponıveisoffline

Integracao com odesktop

Integracao com o desktop lim-itada devido a restricoes im-postas pelo browser

As aplicacoes podem acederao sistema de ficheiro ao clip-board eventos notificacoesetc

Controlo da inter-face com o uti-lizador

As aplicacoes sao acedidasatraves de uma janela dobrowser que tem os seusproprios controlos e visualgrafico

As aplicacoes tem um vi-sual grafico proprio em janelapropria

Armazenamentode dados

As aplicacoes tem armazena-mento limitado que pode serreescrito pelo browser

As aplicacoes tem acesso a to-talidade do espaco disponıvellocalmente e a uma base dedados com a possibilidade deencriptacao

Tabela 31 Comparacao das funcionalidades oferecidas pelo Adobe AIR para as platafor-mas web e desktop

30

Estado da arte

Aplicacao Modo de execucao utilizadoGoogle Reader Utiliza o modo ldquoutilizador deciderdquo disponibilizando

ao utilizador um botao para alternar entre os modosonline e offline Como lida com informacao recol-hida de fontes externas de natureza frequentementeefemera o processo de sincronizacao apenas transfereos dois mil itens mais recentes quando passa ao es-tado offline Neste modo sao ainda guardadas in-formacoes de itens lidos e etiquetas atribuıdas quesao sincronizadas com o servidor quando o utilizadorvoltar a activar estado online

Google Docs Utiliza o modo ldquoaplicacao deciderdquo permitindo que outilizador edite os conteudos de documentos de textofolhas de calculo e de apresentacoes independente-mente do estado da ligacao desde o momento em queas funcionalidades offline sao activadas A aplicacaofaz pequenas sincronizacoes com o servidor sempre quenecessario

Remember the Milk Utiliza um modo hıbrido entre ldquoaplicacao deciderdquo eldquoutilizador deciderdquo A aplicacao encarrega-se da sin-cronizacao de dados mas disponibiliza um controlona sua interface que permite despoletar manualmenteeste processo para situacoes em que o utilizador fez al-teracoes recentes e pretende usufruir das capacidadesoffline imediatamente

MySpace O MySpace anunciou a utilizacao de mecanismos dearmazenamento de dados no cliente com recurso atecnologias OWA para melhorar o desempenho doseu cliente web de correio electronico nomeadamenteno que diz respeito a operacoes de pesquisa e or-denacao Inicialmente esta funcionalidade estara ape-nas disponıvel para utilizadores com cinco mil ou maismensagens na sua caixa de correio mas nao e aindaclaro se sera disponibilizada uma versao totalmenteoffline

Tabela 32 Resumo da utilizacao de tecnologias OWA em algumas web applications con-sideradas na analise do estado da arte

31

Estado da arte

32

Capıtulo 4

Desenvolvimento

Neste capıtulo introduz-se a aplicacao WOW e apresenta-se o estudo que foi

feito da adequacao de cada tecnologia para a implementacao da funcionalidade of-

fline nesta plataforma Fazem-se diversas consideracoes sobre opcoes a tomar na

concepcao de OWAs e problemas comuns na sua implementacao bem como sug-

estoes para os resolver O WOW e uma aplicacao ja existente de gestao de ordens

de trabalho e do fluxo de tarefas numa empresa ou organizacao

41 Como ficar offline

Na maior parte das web applications de hoje nao existe uma camada de dados

real A aplicacao exemplificada na Figura 41 ao longo da sua execucao acede

directamente a sua unica fonte de dados (o servidor) atraves de chamadas Ajax sem

que exista uma separacao clara destas duas camadas

Para que uma web application seja capaz de ser executada sem uma ligacao

activa a Internet e mantenha o seu caracter dinamico torna-se necessario incluir

Figura 41 Exemplo de uma arquitectura de uma web application sem uma camada deabstraccao de dados Figura adaptada de http gears google com

33

Desenvolvimento

Figura 42 Exemplo de uma arquitectura de uma web application com uma camada deabstraccao de dados Figura adaptada de http gears google com

um mecanismo de armazenamento de dados local seja uma base de dados ou a

capacidade de acesso ao disco No entanto este mecanismo introduz dois problemas

1 Qual das fontes de dados utilizar quando um utilizador faz um pedido de

informacao

2 A necessidade de implementar uma camada de acesso a dados que seja coerente

quer se use o servidor remoto ou local

Por exemplo em vez de a aplicacao Ajax fazer um pedido relativo as contas de

todos os utilizadores em formato JSON directamente ao servidor remoto podera ao

inves fazer o pedido a um objecto intermedio da camada de dados Este objecto

demonstrado na Figura 42 sera responsavel por implementar uma interface de

acesso a base de dados e retornar um objecto JavaScript com uma representacao da

resposta do servidor

Mas a existencia de uma segunda fonte de dados torna recomendavel tambem

a implementacao de uma camada de data switching que em funcao da existencia

de conexao a Internet e da necessidade de actualizacao dos dados decide se faz o

pedido ao servidor remoto ou se fornece os dados presentes localmente Este objecto

apresentado na Figura 43 decidira de forma transparente para o utilizador se le ou

escreve os dados localmente ou se os enviapede ao servidor remoto e pode tambem

iniciar o processo de convergencia de dados e de resolucao de conflitos

411 Funcionalidades disponıveis em modo offline

Por razoes praticas e provavel que nem todas as funcionalidades da aplicacao

possam ser disponibilizadas em modo offline E necessario escolher quais as fun-

cionalidades a disponibilizar no modo offline da aplicacao e implementar a logica

que decide quando utilizar a base de dados local ou o servidor remoto Apesar do

acesso a base de dados local ser muito mais rapido do que aceder ao servidor o

acesso local nem sempre e preferido Ha varias razoes que podem tornar necessario

escolher o acesso ao servidor em vez do acesso local

34

Desenvolvimento

Figura 43 Exemplo de uma arquitectura de uma web application com uma camada deabstraccao de dados e um data switch Figura adaptada de http gears google com

1 A informacao pode ter uma natureza efemera e nao fazer sentido guarda-la

localmente Exemplo dados em tempo real da bolsa de valores de Lisboa

2 Algumas aplicacoes lidam com informacao que so faz sentido na presenca de

uma ligacao Exemplo Instant Messaging

3 A aplicacao podera escolher apenas guardar a informacao acedida mais fre-

quentemente Exemplo para o utilizador poder alterar a lıngua de apre-

sentacao da aplicacao os conteudos terao que ser guardados em todas as

lınguas disponibilizadas pela aplicacao O custo de implementacao de algu-

mas funcionalidades pode nao compensar o benefıcio

4 A capacidade de processamento ou de armazenamento de dados pode inviabi-

lizar algumas funcionalidades offline Exemplo se uma dada funcionalidade

necessita de uma capacidade de armazenamento de dados para alem do razoavel

de um computador pessoal para ser util (visualizador de mapas)

42 Modos de execucao

Um aspecto que e necessario estudar para qualquer web application que se deseje

disponibilizar offline prende-se com tres modos de execucao que devem ser consid-

erados

1 Utilizador decide o modo de execucao A aplicacao tem modos distintos

de execucao para os estados online e offline geralmente indicados na interface

com o utilizador O utilizador e informado do estado da ligacao e participa na

alteracao de estado de execucao da aplicacao interagindo com a sua interface

2 Aplicacao decide o modo de execucao Pode ser implementado na propria

aplicacao um mecanismo de deteccao do estado da ligacao (por exemplo atraves

35

Desenvolvimento

de chamadas Ajax periodicas) transitando de estado e sincronizando automati-

camente Desta forma o utilizador nao precisa de participar na alteracao de

estado a menos que exista um conflito de dados que requeira a sua atencao

3 Aplicacao assume sempre o estado offline Outra hipotese sera imple-

mentar uma web application que assume sempre estar na ausencia de uma

ligacao ao servidor de dados Esta aplicacao responde aos pedidos do uti-

lizador efectuando pedidos de informacao ao servidor mas nao dependendo

de uma resposta valida para mostrar a informacao que ja tinha disponıvel an-

teriormente A sincronizacao de dados com o servidor e tentada sempre que

existam dados para submeter e uma accao do utilizador

421 Modo ldquoutilizador deciderdquo

Neste modo de execucao quando a aplicacao esta online comunica com o servidor

remoto quando esta offline comunica com a base de dados local A informacao tem

que ser sincronizada sempre que se muda de modo A principal vantagem desta opcao

e que e a mais simples de implementar mesmo para uma aplicacao ja existente e

portanto uma forma expedita de disponibilizar uma OWA No entanto tem tambem

algumas desvantagens que devem ser consideradas

1 O utilizador tem que se lembrar de fazer a alteracao de estado de execucao

Caso contrario podera estar a trabalhar inadvertidamente numa versao offline

com dados antigos ou nao ter a informacao necessaria se perder subitamente

a ligacao

2 Se a ligacao for intermitente o utilizador tera ou que escolher um dos modos

de execucao ou estar constantemente a trocar

3 Uma vez que a base de dados nao esta sempre actualizada nao podera ser

utilizada para melhorar a rapidez de execucao da aplicacao quando em modo

online

422 Modo aplicacao decide

A deteccao do estado da ligacao pode ser implementada atraves de um pedido

assıncrono ao servidor tal como ilustrado na Figura 44 O resultado deste pedido

definira o estado online (em caso de sucesso) ou offline (em caso de falha) A

sincronizacao de dados podera ser feita sempre que ocorra uma transicao do es-

tado offline para o estado online No entanto este metodo nao se revela eficiente

36

Desenvolvimento

Figura 44 Esquema grafico ilustrando uma OWA executando no browser utilizando ummodo de execucao do tipo ldquoaplicacao deciderdquo com deteccao automatica do estado daligacao via pedidos Ajax assıncronos a cada cinco segundos

para grandes aplicacoes uma vez que requer a troca de mensagens demasiado fre-

quentes com o servidor que se destinam exclusivamente a monitorizacao do estado

da ligacao

423 Modo ldquoaplicacao assume o estado offlinerdquo

Uma aplicacao transparente funciona assumindo sempre que esta em modo of-

fline ou pelo menos que pode perder a ligacao a qualquer momento Neste modo

tira-se o maximo partido do armazenamento local e fazem-se pequenas mas contınuas

sincronizacoes com o servidor sempre que este esteja disponıvel A sincronizacao de

dados tambem e feita sempre que se volta ao estado online

As vantagens de uma web application transparente sao as seguintes

bull Uma melhor experiencia para o utilizador uma vez que este nao tem que se

preocupar com o estado da ligacao ou com a transicao de estados

bull A aplicacao funciona de forma coerente mesmo que a ligacao seja intermitente

bull Uma vez que o armazenamento local e mantido actualizado pode ser utilizado

para melhorar o desempenho da aplicacao

Foram identificadas as seguintes desvantagens

bull E mais difıcil de implementar e a sincronizacao acarreta cuidados especiais

bull E necessario um cuidado adicional para evitar que as operacoes de sincronizacao

frequentes que ocorrem automaticamente nao afectem os tempos de resposta

da aplicacao

bull Os testes a aplicacao sao mais complexos uma vez que a sincronizacao de dados

nao ocorre em resposta a uma accao do utilizador

37

Desenvolvimento

43 Sincronizacao de dados

A sincronizacao de dados consiste na capacidade de identificar e transferir pe-

riodicamente a versao mais actual dos dados entre o cliente e o(s) servidor(es)

Independentemente do modo de execucao escolhido e mesmo do estado da ligacao

do utilizador a informacao armazenada localmente e a informacao armazenada no

servidor estarao por vezes dessincronizadas Isto podera acontecer sempre que por

exemplo

bull O utilizador faz alteracoes em modo offline

bull A informacao e partilhada e pode ser alterada por uma entidade externa

bull A informacao e fornecida por uma entidade externa

Resolver estas diferencas de forma a que a informacao local e remota encontrem

a igualdade chama-se sincronizacao de dados Ha varias aproximacoes possıveis

para este efeito que dependem da natureza da aplicacao cada uma com vantagens

e desvantagens

A capacidade de suportar a mobilidade dos utilizadores torna-se cada vez um

ponto mais importante de uma web application Para uma organizacao de dimensao

global e vital garantir que os seus colaboradores tem acesso a mesma informacao

que tem disponıvel nos seus postos de trabalho mesmo quando estao fora Na maior

parte dos casos estes colaboradores terao acesso a um computador portatil um

desktop Smartphone ou PDA e atraves destes poderao ter acesso a sua informacao

directamente atraves de ligacoes encriptadas Virtual Private Network (VPN) de um

servidor web ou de outro mecanismo de rede

Esta solucao e simples de implementar mas infelizmente para a maioria dos

colaboradores com grande factor de mobilidade nao e satisfatoria As principais

desvantagens sao as seguintes

bull Requisitos de ligacao Para permitir que os utilizadores acedam a sua in-

formacao e necessario garantir a capacidade constante de comunicacao pelo

menos durante o tempo necessario que assegure a sua transferencia

bull Velocidade de ligacao sem persistencia de dados e em ligacoes de fraca

qualidade a usabilidade por vezes torna-se inaceitavel

bull Ponto crıtico de falha Com este tipo de solucao todos os utilizadores de-

pendem da base de dados que armazena informacao vital para o funcionamento

do cliente

38

Desenvolvimento

bull Scalability do servidor A medida que novos utilizadores sao adicionados ao

sistema o desempenho do servidor e afectado levando a necessidade de maior

capacidade de armazenamento eou processamento

De acordo com a documentacao da Microsoft Sync Framework [Mic08] uma

solucao alternativa consiste em implementar uma Occasionally Connected Appli-

cation (OCA) Uma OCA permite a um utilizador remoto continuar a aceder a

sua informacao mesmo depois de perder a ligacao mas em vez de recorrer a um

servidor recorre a informacao armazenada no seu dispositivo local Para preencher

localmente a informacao que o utilizador necessita uma OCA possui mecanismos

de sincronizacao de dados que sao oferecidos por esta framework

431 Quando sincronizar

Uma das solucoes mais simples de implementar passa por disponibilizar um

mecanismo manual que despoleta a sincronizacao Diz-se manual porque e o uti-

lizador que escolhe quando sincronizar e pode ser implementada simplesmente

fazendo o upload de toda a informacao para o servidor e depois fazendo o download

da copia mais recente da informacao antes de voltar a ficar offline Para que esta

seja uma opcao viavel e necessario que

bull O volume de dados seja suficientemente pequeno para que possa ser transferido

do servidor para o cliente num espaco de tempo aceitavel

bull Que o utilizador indique explicitamente que quer mudar para o estado offline

ou online pressionando um botao da interface

Contudo podem ser identificados alguns problemas relacionados com esta abor-

dagem

bull Os utilizadores nem sempre podem prever o estado das suas ligacoes A ligacao

pode-se perder subitamente ou ter um caracter intermitente

bull O utilizador pode esquecer-se de efectuar a sincronizacao

Outra opcao sera conjugar a sincronizacao de dados com o modo de execucao

transparente A sincronizacao ocorre automaticamente em background de forma

nao intrusiva para o utilizador A aplicacao comunica com o servidor regularmente

efectuando pequenas trocas de dados com o objectivo de manter o sincronismo da

informacao local e remota Esta abordagem pode ser implementada com pedidos

Ajax assıncronos e regulares ao servidor o que permite manter a interaccao com a

interface fluıda evitando bloqueios Estes pedidos sao feitos prevendo as situacoes

39

Desenvolvimento

de disponibilidade ou indisponibilidade (timeout) do servidor Uma outra opcao

sera permitir que o servidor comunique essas alteracoes utilizando Comet1 tal como

descrito em [Wil06] e [Rus06] As vantagens destas aproximacoes sao

bull A informacao esta disponıvel a qualquer altura que o utilizador decida ficar

offline ou que a ligacao seja acidentalmente perdida

bull O desempenho da aplicacao pode ser melhorado quando se estiver a utilizar

uma ligacao a Internet lenta uma vez que o acesso a dados locais e mais

eficiente do que a consulta de dados ao servidor

44 WOW

O WOW e uma plataforma integrada de gestao de ordens de trabalho ja ex-

istente e desenvolvida pela Critical Software SA a qual se pretende adicionar a

capacidade de execucao offline Esta aplicacao e extremamente dinamica e con-

figuravel com um conjunto extremamente rico de funcionalidades das quais se

destacam

bull Gestao de Ordens de Trabalho ndash suportando a gestao dos pedidos desde a

sua criacao ate ao seu fecho tomando em conta os diferentes tipos de pedidos

(ordens de trabalho pedidos de informacao melhorias resolucao de problemas

etc) e diferentes tipos de accoes possıveis para cada um (Figura 45)

bull Monitorizacao de alteracoes ndash Historico de mudancas anexos e estados criando

relatorios de alteracao automaticamente (o que por quem e quando)

bull Uso de Service Level Agreements (SLAs) ndash E possıvel associar a um pedido um

SLA que define qual o perıodo de tempo atribuıdo a resolucao de um pedido

controlando e agilizando a resolucao do mesmo

bull Utilizacao de queries de utilizador configuraveis que permitem acesso rapido

a determinadas ordens de trabalho de acordo com o filtro configurado (por

exemplo ldquoPara mimrdquo ldquoPara o Grupordquo ldquoPelo Grupordquo)

bull Gestao do relacionamento entre pedidos

bull Pesquisa e filtragem de ordens de trabalho

bull Exportacao de dados em formatos padrao (PDF DOC ou XLS)

bull Integravel com solucoes externas

40

Desenvolvimento

Figura 45 Detalhe de um conjunto possıvel de estados e respectivas transicoes para umadada ordem de trabalho no WOW desde a sua submissao no sistema ate a sua conclusaoem fecho ou cancelamento Esta figura representa apenas um exemplo ja que o mapa deestados para uma ordem de trabalho e dinamico e pode ser alterado por um administradorFigura retirada de uma brochura promocional do WOW Critical Software SA

A utilizacao de uma ferramenta deste tipo por parte de uma empresa ou orga-

nizacao oferece vantagens quer a gestao de topo quer aos colaboradores individuais

para os colaboradores individuais o WOW e uma aplicacao onde estao registadas

todas as tarefas contribuindo activamente para o desenvolvimento em ambientes

multi-tarefa e para a organizacao pessoal das tarefas de acordo com prioridades

Para a gestao de topo esta ferramenta permite obter uma visao global do estado da

organizacao em termos de tempo gasto por tarefa executada sendo uma mais valia

para a previsao e gestaoalocacao de recursos

45 Visao geral sobre a arquitectura do WOW

O WOW e interessante nao so do ponto de vista de produto como tambem do

ponto de vista de plataforma Existem diversos plug-ins que estendem as funcional-

idades do WOW e existem ate projectos que pretendem usar a arquitectura do

WOW para criar produtos com fins diferentes do inicial (por exemplo o WOW-

Storm ndash um sistema de registo e classificacao social de ideias)

De modo a conseguir ter essa expansibilidade a plataforma WOW assenta sob

uma arquitectura distribuıda modular e expansıvel com uma componente central

ndash o core ndash estruturado em camadas logicas E no core que se situam todas as

1O Comet e um conceito semelhante ao Ajax introduzido por Alex Russel mas no qual e o servidor quetoma a iniciativa de ldquoenviarrdquo os dados ao browser sem que este tenha que efectuar um pedido Tambem econhecido por Ajax Push Reverse Ajax ou HTTP Streaming

41

Desenvolvimento

funcionalidades base da aplicacao quer a nıvel logico funcional e de apresentacao

quer a nıvel de gestao e configuracao

E possıvel a execucao de varias instancias do core simultaneamente em servidores

distintos o que permite a alta escalabilidade e disponibilidade desta aplicacao A

consistencia dos dados fica sempre garantida atraves da partilha da base de dados

e pelo balanceamento dos pedidos uma vez que cada um e encaminhado para uma

unica instancia

O WOW apresenta tambem a vantagem de ser uma plataforma extensıvel E

possıvel adicionar novas caracterısticas a plataforma atraves de componentes que se

podem ser divididos em duas categorias plugins e connectors

Os plugins sao componentes que se encontram no mesmo no fısico que a aplicacao

partilhando do mesmo contexto de execucao do core Sao assim uma forma mais

directa de obter informacao da plataforma visto que nao possuem restricoes de

acesso aos dados nem dependencias externas A arquitectura deste componente tera

assim que permitir varias execucoes instanciadas cada uma associada a um core

Por outro lado os connectors sao componentes que se encontram distribuıdos

comunicando externamente com o core Quer a sua execucao quer a obtencao

dos dados estao assim dependentes de interfaces de comunicacao externas que a

plataforma disponibiliza Estes componentes ao contrario dos plugins sao instan-

ciados unicamente e recorrem ao protocolo de comunicacao Java Messaging Service

(JMS) para comunicar com o core

46 WOW Offline

Para alem das opcoes tomadas relativamente a tecnologia a utilizar surgiu

tambem a necessidade de optar por um dos modos de execucao apresentados na

seccao 42

Das tres opcoes possıveis foi o modo ldquoaplicacao assume o estado offlinerdquo descrito

na seccao 423 que mereceu a maior atencao uma vez que reune as vantagens de

uma experiencia mais positiva para o utilizador (uma vez que este nao tem que

participar activamente na alteracao do modo execucao como descrito na seccao 421)

e nao constitui uma sobrecarga excessiva para servidor (como o modo abordado na

seccao 422)

No entanto esta opcao comprometia a complexidade da implementacao para alem

dos objectivos propostos para este projecto e para cumprir o prazo dado foi tomada

a decisao de implementar o modo ldquoutilizador deciderdquo especificando apenas de forma

teorica o modo ldquoaplicacao assume o estado offlinerdquo

As caracterısticas do Gears foram ja descritas na seccao 31 Na Figura 47

mostra-se a sua forma de funcionamento quando integrado numa web application

42

Desenvolvimento

Nesta figura representa-se o modulo LocalServer do Gears como um ponto de de-

cisao Aqui sao testadas as condicoes que determinam se o pedido sera interceptado e

servido localmente ou se prossegue para uma maquina remota E tambem represen-

tada uma base de dados que corresponde ao modulo Database mas que podera nao

ser utilizada Este modulo tal como o modulo Workerpool tem caracter opcional

e sao utilizados consoante os requisitos da aplicacao

A plataforma WOW lida com mais dados do que e necessario passar para o

lado do cliente Em conformidade com o ja exposto na seccao 411 volta-se a

frisar que nao se pretende recriar toda a logica de negocio nem os conteudos da

base de dados no cliente pela sua complexidade e volume de dados Pretende-se

pelo contrario permitir que os utilizadores tirem partido da capacidade de poder

consultar as suas ordens de trabalho quando nao dispoe de uma ligacao transferindo

apenas o essencial para isto seja possıvel

A pagina inicial do WOW apresenta um resumo das ordens de trabalho abertas

ndash enviadas e recebidas ndash que se pretende permitir visualizar offline (ver Figura 46)

Como prova de conceito foi efectuada uma abordagem pragmatica das varias possi-

bilidades descritas na seccao 42

461 Modo ldquoaplicacao deciderdquo com deteccao automatica da ligacao

A primeira abordagem estudada para a disponibilizacao das funcionalidades of-

fline foi o modo ldquoaplicacao deciderdquo com deteccao automatica de ligacao apresentado

na seccao 422 Para que isto seja possıvel foi implementado um mecanismo de ver-

ificacao periodica do estado da ligacao atraves de chamadas Ajax assıncronas O

resultado destes pedidos determina o estado da aplicacao executando as tarefas de

sincronizacao de dados sempre que pertinente Este metodo embora imediato e

simples de implementar depressa se revelou inadequado para o projecto devido ao

elevado consumo de recursos do servidor que a utilizacao intensiva faz esperar a

comunidade da plataforma WOW no principal cliente excede os 7000 utilizadores

Foi estimado que para uma utilizacao de fluidez aceitavel o estado da ligacao deveria

ser testado a cada cinco segundos Assumindo uma adesao (previsao pessimista) de

1 aos servicos offline assistir-se-ia a cerca de 840 pedidos adicionais por minuto

Mas o principal problema desta aproximacao prende-se com o facto de a ver-

ificacao ser feita em intervalos de tempo discretos levando a possibilidade de a

aplicacao poder ter em dado momento uma representacao errada do seu estado

real da ligacao Este problema e ilustrado na Figura 48 onde se ve claramente a

discrepancia entre o estado real da ligacao e a representacao interna que esta tem

Note-se que nesta janela de tempo qualquer accao do utilizador que exija uma

resposta sıncrona do utilizador leva-lo-a para um ldquobeco sem saıdardquo onde nao tera

43

Desenvolvimento

Figura 46 A pagina inicial do WOW apresenta um resumo das ultimas ordens de trabalhoenviadas e recebidas Na imagem pode-se observar a transicao do estado online para offline

acesso a versao offline porque a aplicacao nao fez a transicao automatica nem acesso

a versao online porque na verdade nao possui uma ligacao O que acontecera nesta

situacao sera uma tentativa de acesso ao servidor por parte da aplicacao numa

altura em que este se encontra indisponıvel e o resultado sera uma mensagem de

ldquopedido excedeu o tempordquo apresentado pelo browser Este e um estado sem retorno

porque apos o browser apresentar esta mensagem todos os recursos JavaScript ficam

indisponıveis tornando impossıvel o regresso ao estado anterior ou o tratamento do

erro de qualquer outra forma No entanto as chamadas Ajax podem ser tratadas de

forma especial para a eventualidade de falha e portanto nao constituem problema

44

Desenvolvimento

Figura 47 Ilustracao do funcionamento do Gears numa web application que utiliza ummotor Ajax Os pedidos HTTP ou HTTPS podem ser interceptados e tratados localmenteou podem ser feitos a uma maquina remota consoante se verificarem ou nao as condicoesexpressas no ponto 311 E representado um acesso a uma base de dados local (fornecidapelo Gears) mas a sua utilizacao e opcional

462 Implementacao do modo ldquoutilizador deciderdquo

Este modo de execucao foi ja descrito na seccao 421 e a sua principal carac-

terıstica e ser o utilizador a decidir se a aplicacao deve utilizar um servidor remoto

ou a maquina local como fornecedor de dados

Relativamente ao WOW o WOW Offline na vertente ldquoutilizador deciderdquo vem

alterar os seus casos de uso dando ao utilizador a possibilidade de alterar o estado

de execucao da aplicacao (entre online e offline) Resta dizer que no modo online se

mantem todas as funcionalidades anteriores e que no modo offline torna-se possıvel

visualizar os conteudos da pagina principal do WOW (Figura 46) e os detalhes das

ordens de trabalho (Figura 49) tal como expressa a Figura 410

Esta aproximacao foi utilizada na prova de conceito do WOW adicionando um

controlo a interface desta aplicacao que permite ao utilizador alternar entre os esta-

dos online e offline Na transicao de online para offline sao descarregados os recursos

necessarios para a execucao desta aplicacao sem recorrer a Internet Para o fazer

45

Desenvolvimento

Figura 48 Neste exemplo do modo ldquoaplicacao deciderdquo o teste da ligacao e feito e feito acada cinco segundos O resultado deste teste nao reflecte sempre o estado real da aplicacaopodendo levar a aplicacao a ter comportamentos indesejaveis Na figura assinala-se umperıodo de tempo no qual a representacao interna do estado da ligacao nao corresponde arealidade

e utilizado um recurso ResourceStore e um ManagedResourceStore (introduzidos

em 311) O primeiro e utilizado para armazenar a pagina principal do WOW ndash do-

ravante designada por homejsp ndash e o segundo e utilizado para armazenar imagens

folhas de estilo CSS e scripts JavaScript

Para a implementacao deste modo de execucao foram identificadas as seguintes

tarefas

1 Guardar informacao que permita a recriacao das paginas que se pretende

disponibilizar offline (utilizando o Gears)

2 Disponibilizar um controlo que permita alterar o estado de execucao atraves

da interaccao com a pagina principal

3 Durante a sincronizacao de dados apresentar o progresso da transferencia de

dados

O primeiro passo consistiu na identificacao de todos os conteudos que sao necessarios

transferir para a execucao offline Foi utilizado um recurso do Gears do tipo

ManagedResourceStore que recorre a um ficheiro manifesto para identificar to-

dos os ficheiros que deve transferir Este recurso e gerido automaticamente pelo

Gears transferindo para o cliente a versao mais recente sempre que e necessario

isto e sempre que exista um ficheiro manifesto com uma identificacao de versao que

seja diferente da actualmente disponıvel no cliente Uma vez identificados todos

ficheiros necessarios para a execucao offline num (ou mais) ficheiros manifesto o

Gears encarrega-se da sua actualizacao mas o preenchimento destes ficheiros man-

ifesto e manual o que se traduz num cuidado extra na manutencao da aplicacao

A forma como esta informacao e guardada deve tambem ser cuidadosamente

estudada A opcao mais flexıvel passa por utilizar o modulo Database apresentado

na seccao 311 e guardar a informacao de uma forma relacional Para a recriacao

das paginas pode ser disponibilizada uma versao HTML da pagina que funciona

46

Desenvolvimento

Figura 49 Pagina de visualizacao do detalhe de uma ordem de trabalho

como template nao possui quaisquer dados e e utilizada apenas em modo offline E

preenchida para cada pedido retirando os dados relevantes da base de dados

O modelo de dados do WOW torna esta opcao extremamente trabalhosa uma

vez que as entidades envolvidas na geracao de cada pagina de informacao sobre

cada ordem de trabalho tem relacoes de dependencia complexas seguindo padroes

muito variaveis Por exemplo em cada ordem de trabalho existe um formulario que

permite a sua progressao de estado com diversos campos opcionais e obrigatorios

este formulario e definido pelo administrador e esta relacionado nao apenas com o

tipo de ordem de trabalho mas tambem com o estado actual em que esta se encontra

e a accao que se pretende realizar O elevado numero de combinacoes de tipos de

ordem de trabalho estados e accoes que existem num dado momento juntamente

com a sua possibilidade de alteracao obrigariam a implementacao de uma logica de

negocio complexa o que esta fora do ambito deste projecto

47

Desenvolvimento

Figura 410 Esquema UML que expressa os casos de uso do WOW Offline no modoldquoutilizador deciderdquo

463 Especificacao do modo ldquoaplicacao assume o estado offlinerdquo

A aproximacao para o modo ldquoaplicacao assume o estado offlinerdquo foi tambem

dividida em varias tarefas

1 Guardar informacao que permita a recriacao da pagina principal do lado do

cliente no estado offline (utilizando o Gears)

2 Dotar a aplicacao do cliente de um mecanismo de deteccao da ligacao

3 Identificar os ldquomomentos chaverdquo em que devera ocorrer sincronizacao de dados

4 Implementar a sincronizacao de dados

A sincronizacao de dados deve ser feita em ambas as transicoes online-offline e

offline-online quer para transferir novos dados do servidor (os pedidos podem ser

alterados por outros utilizadores) quando se transita do estado quer para comunicar

eventuais alteracoes feitas em modo offline

Relativamente ao WOW o WOW Offline na vertente ldquoaplicacao assume o es-

tado offlinerdquo vem alterar os seus casos de uso dando ao utilizador a possibilidade

de activar esta funcionalidade A partir do momento que a funcionalidade esta ac-

tivada o utilizador deve tambem ter a possibilidade de gerir algumas preferencias

relacionadas com privacidade de dados Devera ter a hipotese de desactivar o ar-

mazenamento local e de remover todos os dados ja armazenados tal como descrito

na Figura 411

48

Desenvolvimento

Figura 411 Esquema UML que expressa os casos de uso do WOW Offline no modoldquoutilizador deciderdquo

A primeira vez que o WOW Offline e acedido por um cliente e caso seja detec-

tada a presenca do Gears todos os recursos necessarios a sua execucao sao trans-

feridos Todos os acessos posteriores serao feitos a estes recursos locais (recorda-se

que o Gears pode ser utilizado para os manter actualizados recorrendo ao Managed-

ResourceStore 311)

Atraves do JavaScript e possıvel interceptar os eventos de load e unload da

pagina que sao despoletados sempre que ocorre um re-acesso da mesma (incluindo

a accao refresh comum dos browsers) sempre que esta e abandonada ou ainda ou

ainda se a janela for encerrada

Tal como sugerido na seccao 462 a camada de interface desta aplicacao (cada

pagina individual em HTML) devera ser implementada como sendo um template

para apresentacao de dados sendo totalmente preenchida atraves de funcoes em

JavaScript O objectivo deste ponto e criar um padrao de dados que permita ao

JavaScript preencher os dados em cada pagina (template) independentemente de

qual seja a fonte ndash o servidor remoto ou a maquina local tal como exemplificado

no diagrama da Figura 412 Na figura a aplicacao recorre ao servidor remoto para

obter os dados pretendidos quando se encontra na presenca de uma ligacao mas

para dados que exijam uma carga de processamento pelo servidor este acto pode ser

49

Desenvolvimento

Figura 412 Esquema UML que expressa o acto de recolha de dados em modo online eoffline recorrendo ao servidor (modo online) e ao sistema de armazenamento de dadoslocal fornecido pelo Gears (modo offline)

substituıdo pelo envio de um campo de controlo que se destina a aferir se os dados

locais se encontram actualizados No caso de estarem actualizados a comunicacao

com o servidor pode ser substituıda por uma query a base de dados local

50

Capıtulo 5

Resultados e Futuros

Desenvolvimentos

Todo o estudo feito sobre o tema OWA foi ja abordado ao longo do documento

Neste capıtulo apresentam-se os resultados obtidos na implementacao da prova de

conceito que visava compreender a melhor forma de disponibilizar uma versao of-

fline no WOW uma plataforma de gestao de ordens de trabalho ja existente de-

senvolvida pela Critical Software SA

51 Resultados Obtidos

Os resultados obtidos neste projecto sao extremamente satisfatorios uma vez

que o estudo do tema OWA e a implementacao de uma prova de conceito que o

ilustrasse foi conseguido com sucesso

A funcionalidade offline foi adicionada ao produto WOW da Critical Software

SA permitindo a visualizacao de ordens de trabalho e dos seus detalhes mesmo na

ausencia de uma conexao activa a Internet Embora para a solucao implementada

tenha sido utilizada uma abordagem do tipo ldquoutilizador deciderdquo pretende-se que esta

seja convertida para ldquoaplicacao deciderdquo ou mesmo para uma aproximacao hıbrida

semelhante a utilizada pelas aplicacoes estudadas nas seccoes 351 e 352

Para a sua implementacao descrita no capıtulo 4 foram tomadas decisoes de or-

dem pratica que permitissem tornar o trabalho exequıvel nos prazos dados Tentou-

se sempre que estas decisoes afectassem o mınimo em termos de desempenho e de

experiencia para o utilizador Considera-se que a implementacao do modo offline

com uma transicao entre modos do tipo ldquoutilizador deciderdquo (ver seccao 42) reflecte

o compromisso entre o desempenho pretendido e os recursos disponıveis e para alem

51

Resultados e Futuros Desenvolvimentos

de ser um exemplo eficaz das possibilidades que as OWA podem trazer a aplicacao

WOW desenvolvida pela Critical Software e tambem um estudo que pode ser uti-

lizado para analisar a implementacao desta tecnologia noutros produtos da mesma

empresa

Note-se que o principal objectivo do trabalho era ganhar familiaridade com este

tema entender as suas vantagens e desvantagens e compreender as suas limitacoes

Tudo indica que existam varias possibilidades de implementacao deste paradigma

noutros produtos da Critical Software que pela sua natureza podem tambem tirar

partido da execucao offline

52 Trabalho Futuro

O desenvolvimento do conceito e formas de implementacao de OWA continua

em forte desenvolvimento no entanto a sua adopcao ainda nao e generalizada A

dificuldade da sua implementacao em web applications ja existentes e o principal

obstaculo a sua maior divulgacao

Ha tambem um factor que deve ser tido em consideracao a manutencao de

codigo A implementacao de uma versao offline de uma web application requer

a implementacao das mesmas regras de negocio (ou de uma versao simplificada)

utilizadas no servidor Para que isto seja possıvel e necessario ter em conta a

capacidade de processamento do cliente e o factor de duplicacao de codigo que

tornara a aplicacao mais difıcil de manter uma vez que uma alteracao a logica de

negocio do servidor implica tambem uma alteracao a sua versao offline

A prova de conceito implementada permite ja a visualizacao offline dos pedidos

abertos (enviados e recebidos) que constam na pagina principal (este numero e

fixo e pode ser alterado pelo administrador) Uma funcionalidade desejavel seria a

possibilidade de interaccao com a aplicacao em modo offline e sincronizacao com o

servidor quando existisse uma ligacao disponıvel

Foi estudada a utilizacao do modo de execucao ldquoaplicacao assume o estado of-

flinerdquo descrito em 423 e esta seria a forma desejavel para o WOW Offline no

entanto para que esta opcao seja viavel sera necessaria a implementacao de uma

forma eficiente de sincronizacao e armazenamento de dados de uma forma relacional

Para atingir este objectivo podera ser seguida uma polıtica de automacao do pro-

cesso no qual a versao online da aplicacao gera scripts de criacao para as tabelas

necessarias na base de dados da versao offline (nao existe nenhuma ferramenta para

o fazer portanto seria necessaria a sua implementacao) e no qual as paginas HTML

disponibilizadas pelo servidor aos clientes web (browser) servem como templates de

apresentacao de informacao e sao preenchidas de forma semelhante pelo servidor ndash

quando a aplicacao estiver online ndash ou pelo cliente atraves de funcoes em JavaScript

52

Resultados e Futuros Desenvolvimentos

ndash quando a aplicacao estiver offline No entanto no WOW devido a quantidade de

informacao tratada e devido as complexas relacoes entre as diferentes entidades e

de esperar que a complexidade da implementacao de um mecanismo deste tipo torne

esta aproximacao demasiado custosa

O HTML 5 embora um forte candidato ainda nao esta suficientemente desen-

volvido A sua especificacao ainda tem o caracter de Draft (rascunho) e esta sujeita

a modificacoes e a aceitacao e implementacao por parte dos browsers e portanto

de momento foi desconsiderado No entanto no futuro se esta especificacao atingir

um estado de maturidade que permita a sua adopcao devera ser considerada como

um possıvel caminho a seguir

53

Resultados e Futuros Desenvolvimentos

54

Capıtulo 6

Conclusoes

Neste capıtulo sao apresentadas as conclusoes do projecto e consideracoes finais

relativamente a tecnologia estudada

61 Conclusoes

O rapido desenvolvimento tecnologico faz prever que a disponibilidade de ligacao

a Internet seja cada vez mais facil e mais rapido mas vao continuar a existir lugares

onde o acesso e limitado e onde as OWA podem desempenhar um papel de relevo

Por outro lado esta tecnologia pode tambem ser utilizada para melhorar o desem-

penho de paginas web com uma necessidade elevada de imagens ou outros recursos

dispendiosos em termos de espaco e foram ate estudados dois exemplos da utilizacao

desta vertente desta tecnologia em 353

Acredita-se que as OWAs vem responder a uma necessidade real por parte das

web applications actuais e que a evolucao que representam se compara a que se

assistiu dos thin-clients para os fat-clients em termos de autonomia do servidor

A capacidade de oferecer conteudos dinamicos no browser independentemente da

existencia de uma ligacao reune as vantagens tıpicas das web applications como

ausencia de instalacao e actualizacoes instantaneas com as vantagens das aplicacoes

de desktop em capacidade de processamento e armazenamento de dados na maquina

local

As tecnologias disponıveis ate a data estudadas no ambito deste projecto que

permitem o desenvolvimento de OWAs e que apresentam maior maturidade sao o

Gears e o Adobe AIR Ambas se apresentam sobre a forma de plugins que necessitam

de uma instalacao extra para poderem ser utilizadas Apesar de esta instalacao ser

55

Conclusoes

apenas necessaria uma vez podera constituir um factor de desencorajamento a sua

adopcao

O HTML 5 uma especificacao abordada neste documento na seccao 34 podera

ser uma alternativa que oferece funcionalidades offline a uma web application sem a

necessidade de qualquer instalacao no entanto esta especificacao ainda nao foi aceite

pelos principais browsers ndash o documento que define o HTML 5 ainda tem o estatuto

de Draft ndash e ainda nao e possıvel antecipar quando e que isto podera acontecer

Um dos problemas que surge frequentemente na implementacao de uma versao

offline para uma web application e a necessidade de sincronizacao de dados Quando

a informacao pode ser alterada por varios utilizadores simultaneamente e necessario

prever os conflitos que daı podem surgir e dotar a aplicacao de uma forma de os

resolver ou alertar o utilizador para a necessidade de alteracao dos dados

Em conclusao todos os objectivos propostos para este projecto foram atingidos

A prova de conceito implementada reflecte de forma clara as possibilidades oferecidas

pela tecnologia OWA e sera utilizado no futuro para compreender a melhor forma

de o implementar de forma definitiva no WOW

56

Referencias

[Ada08] Lucas Adamski Introducing Adobe AIR security model Fevereiro de2008 Disponıvel em httpwwwadobecomdevnetairarticles

introduction_to_air_securityhtml acedido em Marco de 2008

[Ado08] Adobe Adobe AIR 10 Security White Paper 2008 Disponıvel emhttpdownloadmacromediacompubairdocumentation1air_

securitypdf acedido em Marco de 2008

[Alm08] Dion Almaer Gears as a bleeding-edge html 5 implementa-tion March 2008 Disponıvel em httpalmaercomblog

gears-as-a-bleeding-edge-html-5-implementation acedido emMarco de 2008

[BL96] Tim Berners-Lee The world wide web Past present and future Agostode 1996 Disponıvel em httpwwww3orgPeopleBerners-Lee

1996ppfhtml acedido em Abril de 2008

[CDGH08] Mike Chambers Daniel Dura Dragos Georgita and Kevin Hoyt AdobeAIR for JavaScript Developers OrsquoReilly Media 2008 Disponıvel emhttponairadobecomfilesAIRforJSDevPocketGuidepdf ace-dido em Abril de 2008

[Con99] Jim Conallen Modeling Web Application Architectures with UML Junho1999 Disponıvel em httpwwwumlorgcnUMLApplicationpdf

webappspdf acedido em Maio de 2008

[Ent07] Entrust What is a public key information 2007 Disponıvel em http

wwwentrustcompkihtm acedido em Junho de 2008

[Gar05] Jesse James Garret Ajax A new approach to web applicationsFebruary 2005 Disponıvel em httpwwwadaptivepathcomideas

essaysarchives000385php acedido em Marco de 2008

[Greon] Philip Greenspun Philip and Alexrsquos Guide to Web Publishing 2003(last revision) Disponıvel em httpphilipgreenspuncompandaacedido em Junho de 2008

[Gro02a] App Design Group Thick vs thin client comparison 2002 Disponıvelem httpwwwdonjacobsvwcomimagesweekendspecials

Thick-vs-Thinpdf acedido em Junho de 2008

57

REFERENCIAS

[Gro02b] Technical Research Group Thin Client Tecnhology - WhitePaper 2002 Disponıvel em httpwwwpicktrgcompubs

thinclientwhitepaperpdf acedido em Junho de 2008

[Gro08] Miniwatts Marketing Group World internet usage March 2008Disponıvel em httpwwwinternetworldstatscomstatshtm ace-dido em Abril de 2008

[Hic08] Ian Hickson HTML 5 Draft Recommendation 2008 Disponıvelem httpwwwwhatwgorgspecsweb-appscurrent-work ace-dido em Marco de 2008

[Kha] Olga Kharif Top 10 municipal wifi plans Disponıvel em http

imagesbusinessweekcomss0608muni_wifiindex_01htm ace-dido em Marco de 2008

[Lab07] Mozilla Labs Prism Outubro 2007 Disponıvel em httplabs

mozillacom200710prism acedido em Marco de 2008

[Loo06] Chris Loosley Rich Internet ApplicationsDesign MeasurementandManagement Challenges 2006 Disponıvel em httpwwwkeynote

comdocswhitepapersRichInternet_5pdf acedido em Maio de2008

[Mic08] Microsoft Introduction to Occasionally Connected Applications us-ing Sync Services for ADONET 2008 Disponıvel em httpmsdn

microsoftcomen-ussyncbb887608aspx acedido em Junho de2008

[Nao08] Erica Naone Offline web applications Abril 2008 Disponıvelem httpwwwtechnologyreviewcomread_articleaspxch=

specialsectionsampsc=emerging08ampid=20245 acedido emAbril de 2008

[NJN00] Jason Nieh Yang S Jae and Naomi Novik A comparison of thin-clientcomputing architectures 2000 Disponıvel em httpwwwnclcs

columbiaedupublicationscucs-022-00pdf acedido em Maio de2008

[OrsquoR06] Tim OrsquoReilly Web 20 compact definition Trying again Dezembro2006 Disponıvel em httpradaroreillycomarchives200612

web-20-compact-definition-tryihtml acedido em Marco de 2008

[OrsquoR09] Tim OrsquoReilly What is Web 20 Design patterns and business modelsfor the Next Generation of Software 20053009 Disponıvel emhttpwwworeillynetcompubaoreillytimnews200509

30what-is-web-20html acedido em Marco de 2008

[Rus06] Alex Russel Comet Low latency data for the browser March Marco2006 Disponıvel em httpalexdojotoolkitorgp=545 acedidoem Marco de 2008

58

REFERENCIAS

[Sad97] Darleen Sadoski Clientserver software architecturesndashan overviewAgosto 1997 Disponıvel em httpwwwseicmuedustr

descriptionsclientserver_bodyhtml acedido em Junho de2008

[Sch96] George Schussel Clientserver past present and future 1996

[Smi07] Kevin C Smith Css filters - will the browser apply the rule July 2007Disponıvel em httpcentriclecomrefcssfilters acedido emMarco de 2008

[vK08] Anne van Kesteren The XMLHttpRequest Object W3C Work-ing Draft 15 Abril 2008 Disponıvel em httpwwww3orgTR

XMLHttpRequest acedido em Abril de 2008

[Wil06] Greg Wilkins Why ajax comet July Julho 2006 Disponıvel emhttpwwwwebtidecomdownloadswhitePaperWhyAjaxhtml ace-dido em Abril de 2008

59

REFERENCIAS

60

Anexo A

Screenshots

Algumas imagens de aplicacoes que utilizam funcionalidades offline ilustrativasda tecnologia abordada neste documento

Figura A1 Dialogo apresentado ao utilizador na primeira activacao das funcionalidadesoffline no Google Docs amp Spreadsheets

61

Screenshots

Figura A2 Na activacao das funcionalidades offline e tambem oferecida a possibilidadeda criacao de alguns atalhos por exemplo no ambiente de trabalho

Figura A3 O Google Docs mantem a todo o momento a possibilidade de alteracao destasdefinicoes ou da anulacao dos servicos offline para um dado computador

62

Screenshots

Figura A4 Apos a instalacao do Gears qualquer visita ao Remember The Milk despoletauma sincronizacao que ocorre automaticamente e sem necessidade de intervencao por partedo utilizador

Figura A5 Apos completar a sincronizacao de dados mesmo que a ligacao a Internetseja perdida o Remember the Milk continua disponıvel no browser (com excepcao dasfuncionalidades que pela sua natureza exigem uma ligacao como por exemplo partilhade tarefas e envio de convites)

63

Page 4: O ine Web Applications

Resumo

Este projecto teve como objectivo o estudo das Offline Web Applications (OWAs)e da sua implementacao em web applications ja existentes Neste ambito foi feitauma avaliacao da aplicacao desta tecnologia no WOW uma plataforma integradade gestao de ordens de trabalho desenvolvida pela Critical Software SA ao longodos ultimos 6 anos e implementada uma prova de conceito que permite a utilizacaode um conjunto de funcionalidades base desta web application independentementedo estado da ligacao a Internet

O conceito das OWAs enquadra-se numa tecnologia de Internet que permiteo acesso a um website atraves do browser mesmo na ausencia de uma ligacao arede global e foi considerado pela revista Technology Review como uma das maisimportantes tecnologias emergentes no final de 2007 [Nao08] O estudo efectuado noWOW pretende ser um primeiro passo na compreensao dos problemas associados asua implementacao e respectivas solucoes e tambem da avaliacao dos benefıcios dautilizacao desta tecnologia para os utilizadores finais

A evolucao das tecnologias associadas a Internet a que se assiste continua-mente impulsionou tambem evolucao da forma como a informacao e produzidadistribuıda e armazenada Surgiram novas web applications oferecendo funcionali-dades de criacao e edicao de conteudos que trouxeram consigo a vantagem de tornarpossıvel o acesso a informacao a partir de qualquer lugar mas tambem a desvan-tagem de tornar a ligacao a Internet uma condicao necessaria para que isto acontecaA proliferacao destas aplicacoes a crescente utilizacao da Internet [Gro08] e a adesaoaos seus servicos indiciam a existencia de uma dependencia cada vez maior de umaligacao que nem sempre existe

As OWAs vem assim colmatar esta falha colocando no lado do cliente parte dainformacao que ate agora vinha a ser armazenada no servidor e tornando nao sopossıvel a sua consulta offline como tambem reduzindo a carga no servidor umavez que reduz as transferencias de informacao

Pretende-se neste documento apresentar diferentes formas de como a utilizacaoda tecnologia OWA pode beneficiar as web applications de hoje melhorando o seudesempenho e dando-lhes novas possibilidades de execucao aproximando-as do desk-top

i

ii

Abstract

The main purpose of this project was to study the Offline Web Applications(OWAs) and its implementation in existent web applications With this goal in minda study was conducted to use this technology in WOW an integrated platform forwork orders and work flow management developed by Critical Software over thelast 6 years and implemented a proof of concept which enables the use of a baseset of functionality for this application regardless of the internet connection state

The concept of OWAs is connected with internet technology and allows accessto a website using the browser even if a connection to the internet is not availableThis concept was considered by Technology Review as one of the most importantemerging technologies in the last quarter of 2007 [Nao08] This study conductedover the WOW platform is intended to aid in the comprehension of the problemsand solutions associated to the use and implementation of OWA as well as thebenefits that it brings to the end user

The Internet and Internet technologies are changing the way in which informa-tion is produced distributed and stored New web applications appeared with newcontent creation and edition functionalities and with it the advantage of infor-mation retrieval from any place and time became possible but with the conditionof Internet connection availability With Internet use growing every year [Gro08]content creation is starting to move to this new platform The adoption of web ap-plications for content creation and edition is becoming more popular and it showsa dependency of a connection that is not always present

The OWAs are a way to solve this problem putting on the client side part ofthe information that was traditionally stored on the server and allows it to be seenand manipulated and helps reducing the server load

This document intends to present different ways in which this technology canhelp web applications as we know them improving the their overall performance andgiving them the ability to run on a browser regardless of the Internet connectionavailability

iii

iv

Agradecimentos

A realizacao e os objectivos alcancados neste projecto nao teriam sido possıveissem a colaboracao de inumeras pessoas Agradeco profundamente a todos os quecontribuıram directa ou indirectamente para o seu sucesso

A minha orientadora Professora Teresa Galvao Dias e ao Project ManagerEngenheiro Marcus Neves que me conduziram e acompanharam no desenvolvimentodeste projecto

A toda a equipa do WOW em especial o Pedro Maurıcio Costa e o Fabio Matosque contribuıram para a minha a minha integracao na Critical Software e que sempresouberam responder a todas as minhas questoes

A todos os que constituem a CSW Porto pelo fantastico ambiente de amizadeque me proporcionaram

Aos colegas de curso e a todos os que me auxiliaram na revisao deste documento

Os meus sinceros agradecimentos

Joao Goncalves da Costa

v

vi

Conteudo

1 Introducao 111 Enquadramento 112 Motivacao 213 Ambito 314 Objectivos 315 Estrutura do documento 3

2 Enquadramento do Projecto 521 Evolucao das arquitecturas de software 5

211 Thin-clients 5212 Fat-clients 6213 Arquitecturas cliente-servidor 7

22 Evolucao na Internet 8221 Paginas web estaticas 9222 Paginas web interactivas e paginas web dinamicas 9223 Web 20 e Ajax 11

23 Offline Web Applications 1324 Comparacao 13

3 Estado da arte 1731 Gears 17

311 Arquitectura 17312 Goggle Gears em dispositivos moveis 20

32 Adobe AIR 20321 Seguranca 22322 Assinatura do codigo 22

33 Mozilla Prism 23331 XML User Interface Language 23332 Prism 25

34 HTML 5 2535 Web applications que usam funcionalidades offline 26

351 Google Reader e Google Docs 26352 Remember the Milk 27353 MySpace e WordPresscom 27

36 Escolha da tecnologia 28

vii

CONTEUDO

4 Desenvolvimento 3341 Como ficar offline 33

411 Funcionalidades disponıveis em modo offline 3442 Modos de execucao 35

421 Modo ldquoutilizador deciderdquo 36422 Modo aplicacao decide 36423 Modo ldquoaplicacao assume o estado offlinerdquo 37

43 Sincronizacao de dados 38431 Quando sincronizar 39

44 WOW 4045 Visao geral sobre a arquitectura do WOW 4146 WOW Offline 42

461 Modo ldquoaplicacao deciderdquo com deteccao automatica da ligacao 43462 Implementacao do modo ldquoutilizador deciderdquo 45463 Especificacao do modo ldquoaplicacao assume o estado offlinerdquo 48

5 Resultados e Futuros Desenvolvimentos 5151 Resultados Obtidos 5152 Trabalho Futuro 52

6 Conclusoes 5561 Conclusoes 55

Referencias 59

A Screenshots 61

viii

Lista de Figuras

21 Arquitectura de um sistema thin-client em duas camadas (a esquerda)e em tres camadas (a direita) Note-se a inclusao do servidor (main-frame) na definicao das camadas desta arquitectura devido a fortedependencia cliente-servidor 9

22 Arquitectura de um fat-client em duas camadas (a esquerda) e emtres camadas (a direita) 10

23 Comparacao do modelo de web aplications sıncrono paginas estaticase interactivas abordados nas seccoes 221 e 222 com o modelo deweb applications Ajax (assıncrono) abordado na seccao 223 Figuraadaptada de http www adaptivepath com 15

31 Esquema UML do processo efectuado pelos recursos do Gears do tipoManagedResourceStore para a actualizacao dos conteudos definidosno ficheiro manifesto 29

41 Exemplo de uma arquitectura de uma web application sem uma ca-mada de abstraccao de dados Figura adaptada de http gears

google com 33

42 Exemplo de uma arquitectura de uma web application com uma ca-mada de abstraccao de dados Figura adaptada de http gears

google com 34

43 Exemplo de uma arquitectura de uma web application com uma ca-mada de abstraccao de dados e um data switch Figura adaptada dehttp gears google com 35

44 Esquema grafico ilustrando uma OWA executando no browser uti-lizando um modo de execucao do tipo ldquoaplicacao deciderdquo com de-teccao automatica do estado da ligacao via pedidos Ajax assıncronosa cada cinco segundos 37

45 Detalhe de um conjunto possıvel de estados e respectivas transicoespara uma dada ordem de trabalho no WOW desde a sua submissaono sistema ate a sua conclusao em fecho ou cancelamento Esta figurarepresenta apenas um exemplo ja que o mapa de estados para umaordem de trabalho e dinamico e pode ser alterado por um admin-istrador Figura retirada de uma brochura promocional do WOWCritical Software SA 41

ix

LISTA DE FIGURAS

46 A pagina inicial do WOW apresenta um resumo das ultimas ordensde trabalho enviadas e recebidas Na imagem pode-se observar atransicao do estado online para offline 44

47 Ilustracao do funcionamento do Gears numa web application que uti-liza um motor Ajax Os pedidos HTTP ou HTTPS podem ser inter-ceptados e tratados localmente ou podem ser feitos a uma maquinaremota consoante se verificarem ou nao as condicoes expressas noponto 311 E representado um acesso a uma base de dados local(fornecida pelo Gears) mas a sua utilizacao e opcional 45

48 Neste exemplo do modo ldquoaplicacao deciderdquo o teste da ligacao e feitoe feito a cada cinco segundos O resultado deste teste nao reflectesempre o estado real da aplicacao podendo levar a aplicacao a tercomportamentos indesejaveis Na figura assinala-se um perıodo detempo no qual a representacao interna do estado da ligacao nao cor-responde a realidade 46

49 Pagina de visualizacao do detalhe de uma ordem de trabalho 47410 Esquema UML que expressa os casos de uso do WOW Offline no

modo ldquoutilizador deciderdquo 48411 Esquema UML que expressa os casos de uso do WOW Offline no

modo ldquoutilizador deciderdquo 49412 Esquema UML que expressa o acto de recolha de dados em modo

online e offline recorrendo ao servidor (modo online) e ao sistemade armazenamento de dados local fornecido pelo Gears (modo offline) 50

A1 Dialogo apresentado ao utilizador na primeira activacao das funcional-idades offline no Google Docs amp Spreadsheets 61

A2 Na activacao das funcionalidades offline e tambem oferecida a possi-bilidade da criacao de alguns atalhos por exemplo no ambiente detrabalho 62

A3 O Google Docs mantem a todo o momento a possibilidade de alteracaodestas definicoes ou da anulacao dos servicos offline para um dadocomputador 62

A4 Apos a instalacao do Gears qualquer visita ao Remember The Milkdespoleta uma sincronizacao que ocorre automaticamente e sem ne-cessidade de intervencao por parte do utilizador 63

A5 Apos completar a sincronizacao de dados mesmo que a ligacao aInternet seja perdida o Remember the Milk continua disponıvel nobrowser (com excepcao das funcionalidades que pela sua naturezaexigem uma ligacao como por exemplo partilha de tarefas e enviode convites) 63

x

Lista de Tabelas

21 Comparacao entre thin-clients e fat-clients 7

31 Comparacao das funcionalidades oferecidas pelo Adobe AIR para asplataformas web e desktop 30

32 Resumo da utilizacao de tecnologias OWA em algumas web applica-tions consideradas na analise do estado da arte 31

xi

LISTA DE TABELAS

xii

Glossario

fat-client Cliente que nao depende totalmente de umservidor central para as suas actividadesde processamento e possui frequentementedispositivos de armazenamento de dados

6ndash8

thin-client Cliente que depende de um servidor centralpara as suas actividades de processamento

5ndash8

web application Sistema web (servidor rede HTTPbrowser) onde accoes do utilizador(navegacao e introducao de informacao)afectam o estado logico da aplicacao

i iii1ndash311ndash1517ndash1921ndash232728 3336ndash3842 5556

API Application Programming Interface 10 1718 2326 28

ASP Linguagem interpretada pelo servidorque permite a criacao de paginas webdinamicas Desenvolvida pela Microsoft

11

BSD Berkeley Software Distribution 28

CSS Cascading Style Sheets 12 2021 2324 46

DHTML Dynamic HyperText Transfer Protocol 24DOM Document Object Model 10 12

20 2324

DTD Document Type Definition 24

xiii

Glossario

ECMAScript Padrao de linguagem de programacaodefinido pela Ecma International que orig-inou o JavaScript e o JScript

24

Flash Conteudo interactivo de um ficheiro emformato SWF E desenvolvido pela Adobee visualizado atraves do Adobe FlashPlayer

21

Flex Framework baseada em XML e Action-Script desenvolvida pela Adobe para a pro-gramacao de Rich Internet Applications(RIA)

21

GPL GNU General Public License 23

HTML HyperText Markup Language 1 10ndash12 2124ndash2649

HTTP HyperText Transfer Protocol 2 26

JMS E uma API em Java que permite a troca demensagens entre componentes de software

42

JSON JavaScript Object Notation permite atroca de dados codificados num formatode texto de simples leitura

12 1828 34

LGPL GNU Lesser General Public License 23

Mozilla Prism Browser simplificado e ldquointerpretadorrdquo deeXtensible User Interface Language (XUL)(tambem designado por XULRunner) queacolhe web applications sem a interfacegrafica habitual de um browser

25

MPL Mozilla Public License 23

OCA Occasionally Connected Application 39OWA Offline Web Application i iii

2ndash515 1725 2628 3133 3651 5255 56

PDF Portable Document Format 21

xiv

Glossario

PHP Linguagem interpretada pelo servidorque permite a criacao de paginas webdinamicas mas que pode tambem ser in-vocada a partir da linha de comandos

11

pagina web estatica Pagina web que devolve sempre a mesmaresposta a todos os pedidos para todos osutilizadores e em qualquer contexto

5 9

RIA Rich Internet Applications web appli-cations que apresentam funcionalidadessemelhantes as desktop applications masque mantem a informacao no lado do servi-dor

5 1520 28

RSS Really Simple Syndication 27

SLA Service Level Agreement 40SQLite Segundo a definicao oficial SQLite is a

software library that implements a self-contained serverless zero-configurationtransactional SQL database engine

17

SSB Site Specific Browser 25SSL Secure Sockets Layer 22SWF ShockWave Flash 21

URL Uniform Resource Locator 18

VPN Virtual Private Network 38

WOW Work Orders Web Plataforma de gestaode ordens de trabalho e do seu fluxo de-senvolvida pela Critical Software SA

i iii28 3340ndash434551ndash5356

WWW World Wide Web 11 1214

XBL eXtensible Binding Language 24XHTML eXtensible HyperText Markup Language 12XML eXtensible Markup Language 11 12

23 2428

XSLT eXtensible Stylesheet Language Transfor-mation

12

XUL eXtensible User Interface Language xiv23ndash25

xv

Glossario

xvi

Capıtulo 1

Introducao

Neste capıtulo enquadra-se o tema do projecto introduzindo alguns dos conceitos

nos quais se baseia Apresentam-se as motivacoes ambito objectivos e a estrutura

deste documento

11 Enquadramento

A Internet foi originalmente concebida para ser um espaco de partilha de in-

formacao onde pessoas (atraves de maquinas) pudessem comunicar Na sua origem

as paginas eram estaticas constituıdas por texto formatado em HyperText Markup

Language (HTML) e ligadas entre si [BL96] Hoje encontramos conteudos cada vez

mais complexos e dinamicos incluindo som vıdeo ou streams multimedia [Loo06] e

em 2005 foi introduzido por [OrsquoR09] o termo Web 20

De acordo com [Greon] um website pode pertencer a uma ou varias das seguintes

categorias

bull Documento ndash um website essencialmente estatico onde alteracoes a uma

parte do conteudo nao tem implicacoes no seu comportamento

bull Base de dados ndash um directorio de informacao organizada em categorias

bull Aplicacao ndash um website dinamico que utiliza uma linguagem executada ou

interpretada do lado do servidor e que processa as accoes ou informacao in-

troduzida pelo utilizador para fornecer um servico ou nova informacao

A ultima destas categorias constitui aquilo que e normalmente designado por

web application O conceito utilizado ao longo deste documento e o mesmo que

o introduzido por Jim Coallen em [Con99] que define web application como um

1

Introducao

sistema web (servidor rede HyperText Transfer Protocol (HTTP) browser) onde

accoes do utilizador (navegacao e introducao de informacao) afectam o estado logico

da aplicacao A sua definicao tenta estabelecer que uma web application e um

sistema de software com estado de negocio1 e que a sua interface de interaccao com

o utilizador e distribuıdo atraves de um sistema web

12 Motivacao

A quantidade de informacao que e produzida e armazenada com recurso a es-

tas web applications disponıveis online tais como e-mail blogues ou mesmo docu-

mentacao tornam por vezes a disponibilidade de ligacao uma condicao necessaria

a produtividade e como consequencia desta barreira muitos potenciais utilizadores

opoem-se a adopcao de produtos web em detrimento das tradicionais desktop appli-

cations

Assegurar o acesso a uma ligacao de Internet e hoje muito mais facil A Internet

movel e ja uma realidade e encontra-se amplamente divulgada mas continuam a

existir diversas situacoes nas quais os utilizadores estao privados de uma ligacao

a Internet tais como uma viagem de metro ou de aviao ou quando se encontram

deslocados do seu paıs de origem e nao possuem nenhum plano de subscricao

Uma OWA consiste numa web application que para alem de manter todas as

caracterısticas anteriores se mantem disponıvel mesmo na ausencia de uma ligacao

a Internet e surge como uma tentativa de estreitar as barreiras existentes entre a

web e o desktop Isto significa que devera existir um mecanismo capaz de assegurar

a manutencao do estado logico da aplicacao quando a ligacao com o servidor e

quebrada permitindo ao utilizador continuar a utilizar a aplicacao e que sera capaz

de informar o servidor do estado em que a aplicacao se encontra quando a ligacao for

reposta A principal vantagem que advem desta possibilidade e evidente eliminar

a necessidade da existencia de uma ligacao a Internet para que a aplicacao possa ser

utilizada

Por outro lado a vontade de integracao de funcionalidades tıpicas das desktop

applications nas web applications foi um dos principais factores que impulsionou o

desenvolvimento deste conceito uma vez que obrigou a uma reflexao ldquopara alem

do browserrdquo e a uma adaptacao das arquitecturas existentes que permitisse ou o

acesso a funcionalidades disponibilizadas pelo sistema operativo ou pelo menos a

funcionalidades semelhantes Pretende-se com esta aproximacao tornar possıveis

interaccoes entre o desktop e o browser tais como arrastar um ficheiro para um

formulario web de upload de conteudos melhor suporte para o historico do clipboard

ou ainda o acesso ao sistema de ficheiros local Atingir estes objectivos reflecte-se

1NT business state

2

Introducao

num novo paradigma que reune as vantagens das web applications tais como os

updates instantaneos ou o facto de nao ser necessaria nenhuma instalacao e das

desktop applications como por exemplo persistencia no armazenamento de dados

acesso a funcionalidades do sistema operativo ou integracao e interaccao com outras

aplicacoes sejam elas web applications ou desktop applications

13 Ambito

Este projecto foi realizado na Critical Software SA no ambito do Mestrado

Integrado em Engenharia Informatica e Computacao (MIEIC) da Faculdade de En-

genharia da Universidade do Porto (FEUP) entre os meses de Fevereiro e Julho de

2008

14 Objectivos

Sao objectivos deste projecto

1 Estudar e documentar o tema das OWAs acompanhando os ultimos desenvolvi-

mentos nesta materia

2 Analisar o estado da arte fazendo uma analise crıtica e objectiva sobre as

diversas metodologias existentes

3 Implementar uma prova de conceito que permita a execucao offline de uma

web application documentando todo o processo

4 Estudar a possibilidade de permitir interaccao com a aplicacao (insercoes e

alteracoes aos dados) em modo offline

Em resumo o objectivo deste projecto foi estudar documentar e implementar

uma prova de conceito relacionada com o tema Offline Web Applications (OWA)

Este tema embora nao seja totalmente novo ganhou destaque ao longo do ano de

2007 com o surgimento de diversas ferramentas que se destinam a aproximar web

applications das desktop applications

15 Estrutura do documento

Este documento esta organizado em diferentes seccoes apresentando o projecto

numa sequencia logica organizada da seguinte forma

No capıtulo 1 faz-se uma breve apresentacao do conceito OWAs e do contexto em

que surge Apresenta-se tambem a estrutura do documento e definem-se os

termos e acronimos utilizados

3

Introducao

No capıtulo 2 faz-se uma descricao da evolucao das tecnologias que antecedem as

OWAs e das vantagens e desvantagens de cada uma como forma de enquadra-

mento

No capıtulo 3 analisa-se o estado da arte nesta materia Introduzem-se diversas

tecnologias directamente relacionadas com o tema deste projecto exemplos de

aplicacoes que as usam e as razoes que fundamentam as escolhas de tecnologias

efectuadas

O capıtulo 4 contem o desenvolvimento do projecto Analisa-se a plataforma

WOW de gestao integrada de ordens de trabalho a tecnologia escolhida e

a forma como foi utilizada para implementar a capacidade de execucao offline

O capıtulo 5 descreve os resultado obtidos comparando-os com as expectativas

iniciais do projecto e apresenta desenvolvimentos futuros e possibilidades de

continuacaoaplicacao do conhecimento adquirido

No capıtulo 6 apresentam-se as conclusoes

4

Capıtulo 2

Enquadramento do Projecto

Neste capıtulo apresenta-se um breve resumo da evolucao das arquitecturas de

software cliente-servidor e a forma como estas se comparam a evolucao da Inter-

net procurando estabelecer uma analogia entre o percurso de ambas as tecnolo-

gias Compara-se o comportamento e arquitectura dos thin-clients as paginas web

estaticas a evolucao dos fat-clients as paginas interactivas Web 20 e Ajax e

defende-se que as OWA constituem um proximo passo logico e evolutivo aproxi-

mando a web do desktop Referem-se ainda os principais factores que justificam a

importancia das OWAs e a estreita relacao que tem com as Rich Internet Application

(RIA)s

21 Evolucao das arquitecturas de software

Os termos thin-client e fat-client sao utilizados quer para descrever arquitecturas

logicas (de software) quer para descrever arquitecturas fısicas (de hardware) Neste

capıtulo excepto quando seja dada indicacao em contrario estes termos referem-se

sempre a uma arquitectura logica

Adicionalmente quando se trata de arquitecturas cliente-servidor pode-se estu-

dar a arquitectura desenvolvida do sistema como um todo da arquitectura do servi-

dor ou da arquitectura do cliente Para evitar equıvocos em especial na seccao 213

especifica-se em cada caso qual o sistema estudado

211 Thin-clients

Um thin-client e um computador cliente ou software cliente que no contexto

de uma arquitectura cliente-servidor depende de um servidor central para as suas

5

Enquadramento do Projecto

actividades de processamento e proporciona um canal de entrada e saıda de in-

formacao entre o utilizador e o servidor remoto Este termo quando aplicado a

hardware refere-se habitualmente a um computador que se destina a ser utilizado

como cliente de rede sem armazenamento local e com capacidade de processamento

reduzida [Gro02b] mas o conceito que aqui se analisa refere-se a uma arquitectura

de software que remonta ao inıcio das aplicacoes cliente-servidor

No inıcio da historia da computacao terminais ligavam-se directamente a main-

frames responsaveis por todo o processamento Nesta arquitectura era necessario

desenvolver duas aplicacoes distintas uma aplicacao central no servidor (main-

frame) responsavel pela gestao de toda a informacao e por todas as operacoes de

comunicacao e uma aplicacao de visualizacao instalada no cliente (terminal) O

papel destes terminais era apenas disponibilizar ao utilizador um meio de comu-

nicacao (entrada e saıda) e apresentacao dos resultados do servidor Nao tinham

um papel activo no calculo nem na logica de negocio e frequentemente nao tinham

tambem nenhum mecanismo de armazenamento de dados

Como vantagens esta arquitectura apresenta uma reduzida necessidade de con-

figuracao e manutencao do lado do cliente Uma vez que o centro do processamento

e manipulacao de dados ocorre no servidor existe tambem uma centralizacao da

informacao [NJN00] que introduz um ponto crıtico de falha1 Actualizacoes e novas

funcionalidades sao faceis de distribuir uma vez que requerem apenas alteracoes no

servidor [Gro02a]

212 Fat-clients

Contrastando com os thin-clients nesta arquitectura os clientes implementam

ja uma parte da logica de negocio e sao responsaveis pelo processamento de dados

Estes fat-clients vieram responder a necessidade crescente de aplicacoes com um

nıvel de interactividade e capacidade de configuracao maior que as oferecidas pela

arquitectura thin-client descrita na seccao 211 Apesar de manterem a sua de-

pendencia do servidor podem tambem ser executados sem uma conexao activa uma

vez que dispoe de armazenamento de dados local o que lhes confere a capacidade

de persistencia de dados e do estado de execucao entre cada sessao

Foi disponibilizando este controlo sobre o estado da aplicacao bem como acesso

a recursos locais (por exemplo sistema de ficheiros e perifericos) que surgiram as

primeiras verdadeiras desktop applications No entanto cada cliente tinha que ser

separadamente instalado no computador pessoal de cada utilizador que pretendesse

utilizar ou interagir com a aplicacao e uma actualizacao ao servidor implicava in-

variavelmente uma actualizacao manual tambem no cliente Uma vez que nem todos

1NT single point of failure

6

Enquadramento do Projecto

Thin-clients Fat-clientsNao toma parte no processamento dedados nem possui acesso ao sistema deficheiros

Participa activamente no processa-mento de dados recorrendo ao sis-tema de armazenamento local para ar-mazenamento de dados

Nao mantem registo do estado logicoda aplicacao entre duas sessoes de uti-lizacao

O acesso ao armazenamento localpermite-lhe manter registo do estadologico da aplicacao entre duas sessoes

O thin-client nao necessita de qualquerinstalacao estando ldquopronto a utilizarrdquo

E geralmente necessario instalar aaplicacao para poder interagir com oservidor

Qualquer update no servidor reflecte-seimediatamente por todos os clientes

Embora a aplicacao cliente possa aler-tar para existencia de novas versoes asactualizacoes tem que ser manualmenteinstalados pelo cliente

O software do cliente destina-se apenasa apresentacao de dados e comunicacaocom o servidor sendo portanto de sim-ples implementacao

Como o software do cliente toma parteactiva no processamento de dadosa sua implementacao requer cuidadosadicionais

Grande mobilidade uma vez que todaa informacao e mantida no servidor

Parte da informacao podera estar ape-nas do lado cliente pelo que existemalgumas restricoes a sua mobilidade

Tabela 21 Comparacao entre thin-clients e fat-clients

os utilizadores actualizam regularmente as suas aplicacoes o servidor tem que estar

preparado para lidar com versoes antigas2 ou descontinuar os seus servicos a uma

parte da sua comunidade de utilizadores ate que estes actualizem os seus sistemas

Como os utilizadores passam a utilizar os seus recursos locais para armazenamento

de dados as alteracoes que nao sejam sincronizadas com o servidor estao apenas

disponıveis nos seus computadores pessoais o que introduz uma restricao a mobili-

dade

Pode-se afirmar que as vantagens dos thin-clients sao as desvantagens dos fat-

clients e que as vantagens dos fat-clients sao as vantagens dos thin-clients tal como

se ilustra na Tabela 21

213 Arquitecturas cliente-servidor

Introduzidos os termos thin-client e fat-client interessa reafirmar que ambos

podem ser vistos como arquitecturas cliente-servidor Um cliente define-se como

um solicitador de servicos e um servidor como um prestador de servicos tal como

definido por [Sch96] e [Sad97]

2NT backward compatibility

7

Enquadramento do Projecto

As arquitecturas cliente-servidor sao categorizadas pela modularizacao com que

sao desenhadas sendo consideradas as seguintes camadas

1 Interface grafica (front-end) atraves da qual os utilizadores interagem com

a aplicacao Quando este modulo e implementado separadamente dos outros

dois constitui uma aplicacao thin-client por si so uma vez que nao implementa

regras de negocio (embora possa definir validacoes de formularios de insercao de

dados por exemplo) A informacao introduzida pelo utilizador e enviada para

o servidor que processa o seu pedido e retorna uma resposta Este processo

repete-se ate que o utilizador atinja o seu objectivo ou se desligue do sistema

2 A logica de negocio tambem designada por camada intermedia que imple-

menta as regras de aceitacao e validacao de todos os dados introduzidos pelo

utilizador E tambem a plataforma de comunicacao que une a camada superior

de visualizacao com a camada de acesso a dados

3 A camada de dados inclui quer o sistema de persistencia de dados onde sao

armazenados os dados relevantes como tambem os mecanismos necessarios

para a sua pesquisa seleccao e alteracao

Os thin-clients quando observados no seu conjunto de cliente e servidor podem

ser vistos quer como sistemas de duas camadas quer como sistemas de tres camadas

dependendo apenas da forma como o servidor for implementado No caso de na

implementacao do servidor nao se distinguir a camada de acesso a dados da camada

da logica de negocio sao designados por sistemas de duas camadas Caso seja feita

esta distincao sao designados por sistemas de tres camadas Ambos os casos sao

ilustrados na Figura 21

Historicamente os fat-clients eram implementados numa arquitectura em duas

camadas Possuıam apenas um modulo de visualizacao de dados designado por

camada de interface e um modulo que implementava toda a logica de negocio e

regras de acesso a base de dados No entanto com a introducao de ligacoes mais

rapidas e de computadores pessoais com maior capacidade de processamento e so-

bretudo devido a complexidade crescente das aplicacoes a logica de negocio e a

camada de acesso a dados tornaram-se independentes Este modelo e designado por

arquitectura em tres camadas e e ilustrado na Figura 22

22 Evolucao na Internet

Ao analisar a evolucao das arquitecturas das aplicacoes desenvolvidas para a

Internet podemos encontrar um paralelismo com a historia da arquitectura de soft-

ware

8

Enquadramento do Projecto

Figura 21 Arquitectura de um sistema thin-client em duas camadas (a esquerda) e emtres camadas (a direita) Note-se a inclusao do servidor (mainframe) na definicao dascamadas desta arquitectura devido a forte dependencia cliente-servidor

221 Paginas web estaticas

Uma pagina web estatica devolve sempre a mesma resposta a todos os pedidos

para todos os utilizadores e em qualquer contexto utilizando o hipertexto como

forma de ligacao entre diversas paginas estaticas

A informacao e armazenada num servidor e o papel do cliente e apenas a apre-

sentacao da informacao Esta forma de disponibilizacao de informacao pode assim

ser comparada com os thin-clients descritos na seccao 211 o utilizador acede a

um website estatico para visualizar informacao sem que o cliente tome parte no

processamento A unica diferenca e que no caso da web estatica a informacao ap-

resentada e sempre a mesma enquanto que nos thin-clients era frequente existir a

possibilidade de insercao de dados no cliente e apos o seu processamento servidor

nova informacao poderia ser apresentada O hipertexto e utilizado para ligar as

paginas entre si numa rede de conteudos relacionados e a navegacao sıncrona era

feita atraves de cliques do rato a cada clique uma nova pagina era apresentada

Este modelo sıncrono e ilustrado na Figura 23

222 Paginas web interactivas e paginas web dinamicas

O JavaScript e uma linguagem interpretada de scripting que tem os browsers

como principal ambiente de acolhimento Os browsers utilizam uma Application

9

Enquadramento do Projecto

Figura 22 Arquitectura de um fat-client em duas camadas (a esquerda) e em tres camadas(a direita)

Programming Interface (API) publica para criar ldquoobjectosrdquo responsaveis por reflectir

e disponibilizar o Document Object Model (DOM) para o motor de JavaScript

A utilizacao mais frequente desta linguagem e a escrita de funcoes que sao em-

bebidas ou incluıdas em paginas web e que interagem com o DOM Uma vez que o

JavaScript e executado localmente (na maquina do cliente e nao no servidor) e capaz

de responder rapidamente a accoes do utilizador tornando a execucao de aplicacoes

no browser mais fluıdas o JavaScript pode tambem detectar accoes do utilizador

que o HTML nao pode tal como o pressionar de uma tecla

Em Dezembro de 1995 a Netscape Communications adicionou suporte para o

JavaScript no browser Netscape Navigator3 e em Agosto de 1996 o browser Internet

Explorer4 da Microsoft passou a tambem a suportar uma versao semelhante desta

linguagem (hoje todos os principais browsers suportam esta tecnologia)

Esta inovacao permitiu tornar os websites mais interactivos mas a sua utilizacao

esteve confinada apenas a este proposito durante um longo perıodo As paginas

passaram a responder activamente a accoes do utilizador (sendo uma das utilizacoes

3Netscape Communications ndash httpbrowsernetscapecom4Microsoft Internet Explorer ndash httpwwwmicrosoftcomwindowsproductswinfamilyie

10

Enquadramento do Projecto

mais vulgares a validacao de formularios) mas continuaram essencialmente estaticas

O JavaScript ainda nao era nesta altura utilizado para processar dados

Tambem nesta altura (1995ndash96) surgiram linguagens server-side como o PHP

Hypertext Preprocessor (PHP) e Active Server Pages (ASP) e o servidor passou a ter

um processamento de dados introduzidos pelo utilizador mais activo Generalizaram-

se as paginas dinamicas capazes de responder a insercao de dados ou outros pedidos

determinados por accoes do utilizador As paginas tornaram-se aplicacoes web ap-

plications

Uma definicao tradicional de web application e um conjunto de paginas web

logicamente agrupadas e geridas por uma unica entidade que tem como pontos de

entrada formularios de insercao de dados (web forms) Uma web application nao e

mais do que uma aplicacao que e acedida atraves de um browser Tem geralmente

uma arquitectura logica em tres (interface logica de negocio e camada de dados)

camadas e estao armazenadas num servidor

Ha dois tipos de web applications

bull Orientadas a apresentacao Sao web applications que geram paginas web in-

teractivas constituıdas por varios tipos de linguagens de anotacao (por exem-

plo HTML eXtensible Markup Language (XML)) e que apresentam conteudo

dinamico como resposta a pedidos efectuados pelo utilizador

bull Orientadas aos servicos Uma web application orientada aos servicos imple-

menta o ponto de acesso para um ou mais de um web service Sao geralmente

clientes de service oriented web applications

Uma vantagem significativa de implementar uma web application de forma a

suportar as funcionalidades padrao dos browsers e que estas terao o mesmo com-

portamento independentemente da plataforma e do browser a partir do qual serao

acedidas No entanto diferentes implementacoes de browsers devido a diferentes

interpretacoes dos padroes definidos tornam por vezes esta tarefa um pouco mais

complicada existindo inclusivamente na web guioes de compatibilidade para os difer-

entes browsers como [Smi07]

223 Web 20 e Ajax

O termo web 20 descreve uma tendencia de utilizacao e de design observada

na World Wide Web (WWW) com o objectivo de melhorar a criatividade partilha

de informacao e principalmente a colaboracao entre utilizadores Estes conceitos

levaram ao desenvolvimento e evolucao de comunidades online tais como redes so-

ciais wikis e blogues

11

Enquadramento do Projecto

O termo tornou-se mais conhecido apos a primeira conferencia OrsquoReilly Media

Web 20 em 2004 e apesar de sugerir uma nova versao da WWW nao se refere a

qualquer evolucao tecnologica mas apenas a alteracoes a forma como os utilizadores

se servem da web De acordo com Tim OrsquoReilly [OrsquoR06] ldquoWeb 20 e uma revolucao

na industria do software causada pela adopcao da web como uma plataforma e pela

tentativa de entendimento das regras para o sucesso nesta nova plataformardquo

O desenvolvimento da Web 20 serve-se muitas vezes de um outro conceito Ajax

O conceito que hoje conhecemos como Ajax muitas vezes incorrectamente de-

scrito como uma tecnologia foi originalmente criado para permitir o desenvolvimento

de web applications que se assemelhassem ainda mais a aplicacoes de desktop Este

conceito foi melhor descrito por [Gar05] como um conjunto de varias tecnologias

que podem ser utilizadas para melhorar a experiencia do utilizador de uma dada

web application introduzindo a capacidade assıncrona de envio de pedidos ou da

recepcao assıncrona de respostas As tecnologias mais frequentemente envolvidas

sao

bull eXtensible HyperText Markup Language (XHTML) e Cascading Style Sheets

(CSS) padrao para a apresentacao

bull interaccao dinamica atraves do DOM

bull troca e manipulacao de dados utilizando XML e eXtensible Stylesheet Lan-

guage Transformation (XSLT) ou JavaScript Object Notation (JSON)

bull pedidos assıncronos utilizando XMLHttpRequest [vK08]

bull JavaScript utilizado para integrar todas estas tecnologias

E importante frisar que o Ajax nao e um produto nem uma tecnologia E um

termo que descreve a utilizacao de um conjunto de tecnologias para o desenvolvi-

mento de web applications com um elevado grau de interactividade Comparativa-

mente as web applications tradicionais o Ajax introduz uma camada de visualizacao

diferente em tres importantes pontos

1 Do lado do cliente existe um motor que serve de intermediario entre a interface

da aplicacao e o servidor

2 A actividade do utilizador despoleta chamadas JavaScript em vez de um pedido

de pagina directamente ao servidor

3 Informacao codificada em XML em vez de paginas HTML e trocada entre o

servidor e o cliente

12

Enquadramento do Projecto

Isto significa que as paginas que utilizam Ajax contem um motor do lado do

cliente composto por um conjunto de funcoes JavaScript responsavel pela comu-

nicacao com o servidor e por actualizar a interface com o resultado dessa mesma

comunicacao

Na Figura 23 ilustra-se a natureza assıncrona do Ajax quando comparada com

as web applications tradicionais Como se pode observar adicionando um mecan-

ismo Ajax a uma web application eliminam-se diversos tempos de espera associados

a comunicacoes com o servidor uma vez que a interface nao fica ldquobloqueadardquo a es-

pera da resposta Obtem-se assim aplicacoes com um comportamento mais fluido

eliminando tempos de espera entre cada ldquocliquerdquo e melhorando a experiencia do

utilizador

23 Offline Web Applications

A informacao grafica (bem como folhas de estilo e scripts) tais como as ima-

gens que constituem o visual de uma web application e ja tratada de forma especial

pelos cada vez mais avancados sistemas de cache (armazenamento temporario) dos

browsers Mas estes nao sao ainda capazes de guardar conteudo criado pelo uti-

lizador nem de apresentar informacao independentemente do estado da ligacao

Numa altura onde se fala de servicos de Internet wireless municipalizados [Kha]

comunicacoes 3G e ligacoes de banda larga a alta velocidade a ligacao a rede global

continua a nao estar permanentemente disponıvel para os utilizadores Na WWW

encontra-se uma importante parte da informacao e das aplicacoes utilizadas para

criar e editar conteudos Por vezes informacao vital para a produtividade pode

desaparecer subitamente do mapa de acesso de um utilizador quando este entra no

metro num aviao ou mesmo quando se desloca para uma cidade ou paıs diferente

do habitual onde nao subscreve um plano de acesso que lhe garanta a ligacao

Permitir o acesso offline a estes recursos assume assim a sua importancia porque

permitira estender o alcance da informacao a locais onde nunca esteve antes e per-

mitira tambem melhorar o desempenho das web applications colocando informacao

mais perto dos utilizadores reduzindo a transferencia de dados apenas ao essencial

24 Comparacao

Nas evolucoes descritas neste capıtulo 2 pode-se observar que existe um par-

alelismo entre a evolucao das arquitecturas tradicionais cliente-servidor e a evolucao

a que se assiste na web O comportamento e arquitectura dos thin-clients assemelha-

se ao das paginas estaticas no sentido em que o browser nao toma parte em qualquer

13

Enquadramento do Projecto

processamento e serve apenas como uma plataforma de interaccao com o servidor

tal como os clientes descritos na seccao 211

A sua proxima evolucao os fat-clients trouxeram parte da capacidade de pro-

cessamento para o lado do cliente Na web foi tambem esta a inovacao tecnologica

a que se assistiu com a evolucao das tecnologias que permitiram a criacao de ver-

dadeiras aplicacoes e com a introducao do Javascript no browser dando ao cliente

a capacidade de processamento de dados A necessidade da separacao do codigo

em camadas logicas advem da crescente complexidade das web applications Esta

pratica permite entre outras coisas melhorar o processo de desenvolvimento e a

capacidade de manutencao de uma aplicacao

Os fat-clients tem tambem a capacidade de armazenamento de dados o que

permite a persistencia de informacoes entre duas sessoes e que algumas operacoes

sejam executadas sem a necessidade de comunicacao com o servidor Este facto pode

tambem ser uma realidade nas web applications com a adopcao das tecnologias OWA

Neste momento assiste-se a uma utilizacao cada vez maior da web como uma

plataforma de desenvolvimento A capacidade de cooperacao na edicao de conteudos

e a mobilidade proporcionada por esta plataforma sao os principais factores que

alimentam esta mudanca e pela primeira vez as aplicacoes tradicionais tem com-

peticao vinda de web applications A prova do reconhecimento da web como plataforma

de desenvolvimento pode ser retirada da aposta de empresas como a Adobe e Mi-

crosoft que lancaram publicamente ferramentas web complementares a produtos

seus tradicionalmente associados ao desktop ndash Acrobatcom5 e Microsoft Office

Live6 Dotar estas web applications da capacidade de execucao offline significa

aproximar a web e o desktop reunindo ldquoo melhor de dois mundosrdquo

As vantagens da mobilidade possıvel atraves da web a cooperacao na criacao e

edicao de conteudos e a possibilidade de utilizar aplicacoes sempre actualizadas e

sem necessidade de instalacao sao algumas das principais vantagens que promovem

esta mudanca que devido as preocupacoes associadas a usabilidade e experiencia do

utilizador esta fortemente associada ao desenvolvimento de Rich Internet Applica-

tion (RIA)s

5Adobe Acrobatcom httpwwwacrobatcom6Microsoft ndash httpsmallbusinessofficelivecom

14

Enquadramento do Projecto

Figura 23 Comparacao do modelo de web aplications sıncrono paginas estaticas e in-teractivas abordados nas seccoes 221 e 222 com o modelo de web applications Ajax(assıncrono) abordado na seccao 223 Figura adaptada de http www adaptivepath

com

15

Enquadramento do Projecto

16

Capıtulo 3

Estado da arte

Apesar de o conceito das OWAs nao ser absolutamente novo as tecnologias que

o suportam sao recentes Neste capıtulo descrevem-se quatro tecnologias que foram

tidas como principais candidatas para o desenvolvimento deste projecto Descrevem-

se ainda alguns exemplos de web applications que disponibilizam actualmente fun-

cionalidades offline e o processo da escolha da tecnologia a utilizar neste projecto

31 Gears

O Gears1 e uma extensao as funcionalidades do browser introduzido pelo Google

que tem como principal objectivo tornar possıvel a visualizacao de paginas de Inter-

net mesmo sem uma conexao disponıvel Encontra-se disponıvel para as platafor-

mas Windows Macintosh e Linux e oferece uma API de Javascript que permite

a scripts aceder a um mecanismo de armazenamento local baseado numa base de

dados SQLite

311 Arquitectura

Esta ferramenta e constituıda por tres componentes principais

bull LocalServer mdash Intercepta pedidos de paginas web e serve-as localmente

bull Database mdash Uma base de dados relacional construıda sobre SQLite

bull WorkerPool mdash Permite executar operacoes de computacao de uma forma

assıncrona sem afectar a capacidade de resposta e fluidez de execucao da web

application Assemelham-se a processos

1Google Inc ndash Mais informacao em httpgearsgooglecom

17

Estado da arte

LocalServer

O modulo LocalServer e uma cache de Uniform Resource Locators (URLs)

controlada pela web application Quando nao existe uma ligacao a Internet e e

feito um pedido para um URL presente nesta cache o LocalServer intercepta-o e

responde ao pedido localmente a partir do disco rıgido do utilizador A aplicacao

pode utilizar dois tipos diferentes de armazenamento local de URLs

bull ResourceStore ndash serve para capturar URLs utilizando exclusivamente a API

de Javascript disponibilizada para o efeito Uma aplicacao podera criar e

utilizar diversos ResourceStores simultaneamente para capturar ficheiros de

dados que necessitam de ser enderecados por um URL tal como um ficheiro

PDF ou uma imagem

bull ManagedResourceStore ndash serve para capturar um conjunto de URLs que estao

relacionados e que sao declarado num ficheiro de manifesto (especificado em

JSON) e que sao automaticamente actualizados O ManagedResourceStore

permite que o conjunto de recursos necessarios para correr uma web application

seja capturado e mantido actualizado automaticamente

A principal diferenca entre estes dois tipos de armazenamento de URLs e a forma

como sao actualizados os seus conteudos Os conteudos de um ManagedResourceStore

sao actualizados sempre que a versao contida no ficheiro de manifesto for alterada

enquanto que os conteudos de um ResourceStore nunca sao actualizados automati-

camente mas apenas quando for explicitamente ordenado pela aplicacao

O LocalServer e capaz de interceptar e servir localmente pedidos de HTTP e

HTTPS sempre que se reunam as seguintes condicoes

1 O URL encontra-se armazenado num ResourceStore ou ManagedResourceStore

2 O sistema de armazenamento local encontra-se activo (enabled = true) Se

o sistema de armazenamento local tiver o atributo requiredCookie o pedido

devera conter um cookie que lhe corresponda

O LocalServer nao necessita de monitorizar o estado da ligacao para atender aos

pedidos Na verdade sempre que as condicoes previamente enunciadas se verificarem

o LocalServer interceptara os pedidos e independentemente do estado da ligacao

a Internet servi-los-a a partir do disco rıgido local Cabera a aplicacao definir qual

o modo em que pretende executar um pedido (online ou offline) definindo o valor

de verdade da propriedade enabled

18

Estado da arte

Database

O modulo Database permite guardar dados da web application assegurando a

sua persistencia Os dados sao guardados de forma relacional no disco rıgido do uti-

lizador2 de acordo com o modelo de seguranca estabelecido pelo Gears3 significando

que uma aplicacao nao pode aceder a conteudos fora do seu domınio

WorkerPool

Nos web browsers uma operacao pesada de computacao pode tornar a interface

lenta e tornar menos agradavel a experiencia do utilizador O modulo WorkerPool

permite correr operacoes em background sem bloquear a interface com o utilizador

Os scripts executados numa WorkerPool nao activam os mecanismos de seguranca

do browser que mostram a mensagem ldquoA script on this page may be busy or may

have stopped respondingrdquo

O WorkerPool comporta-se como um conjunto de processos em vez de threads

Os Workers nao partilham qualquer estado de execucao o que significa que uma

alteracao a uma variavel num Worker nao afecta em nada a execucao de outro

Worker Alem disso os Workers nao herdam automaticamente nenhum codigo dos

seus pais Cada Worker e membro de um WorkerPool e os Workers podem in-

teragir entre si enviando mensagens em formato de texto ou JSON No entanto ha

tambem algumas limitacoes os Workers nao tem acesso ao DOM e objectos como

window ou document nao se encontram acessıveis Isto e consequencia de os Workers

nao partilharem o estado de execucao Mas tem acesso a todas as funcoes built-in

do Javascript A maioria das funcionalidades do Gears pode tambem ser acedida

atraves de uma variavel global especial definida como googlegearsfactory Para

outras funcionalidades especıficas os Workers podem ldquopedirrdquo a pagina principal para

continuar a execucao atraves do envio de mensagens

Outras funcionalidades

bull HttpRequest ndash Este modulo implementa a especificacao W3C XmlHttpRe-

quest definida em [vK08] tornando-a disponıvel para os workers e para a

pagina principal

bull Timer ndash Este modulo implementa a especificacao de timers tal como descrito

por [Hic08] e torna-os disponıveis para os workers e para a pagina principal

2Consultar httpcodegooglecomapisgearsapi_databasehtmldirectories3Consultar httpcodegooglecomapisgearssecurityhtml

19

Estado da arte

bull Factory ndash Esta classe e utilizada para instanciar todos os outros objectos da

API do Gears atraves do seu metodo create Este metodo pode ser utilizado

com os seguintes parametros

ndash betadatabase

ndash betahttprequest

ndash betalocalserver

ndash betatimer

ndash betaworkerpool

312 Goggle Gears em dispositivos moveis

O Gears esta tambem disponıvel em dispositivos Windows Mobile 5 e 6

Os dispositivos moveis estao pela sua natureza frequentemente desconectados

da Internet Mesmo quando possuem uma ligacao as latencias na transferencia de

dados em redes moveis tornam as aplicacoes pouco fluıdas mas o Gears permite

ultrapassar este obstaculo

O Gears funciona exactamente da mesma forma em dispositivos moveis equipados

com o Windows Mobile 5 e 6 como num computador comum Se uma aplicacao tiver

sido implementado com suporte para o Gears entao tambem estara preparada para

ser executada num dispositivo movel mas as limitacoes dos browsers disponıveis

para dispositivos moveis tem que ser consideradas Isto significa prever as condicoes

que permitam uma boa usabilidade devido aos pequenos ecras destes dispositivos

bem como o seu suporte limitado dos padroes do DOM CSS e JavaScript

32 Adobe AIR

O Adobe AIR4 e um runtime compatıvel com diversos browsers e sistemas opera-

tivos que pretende dar aos programadores a possibilidade de combinar diversas tec-

nologias de producao de conteudos para a Internet no desenvolvimento de Rich Inter-

net Application (RIA)s O Adobe AIR mantem uma relacao com o browser mas es-

tende as suas capacidades e tecnologias permitindo o desenvolvimento de aplicacoes

tambem para o ambiente de trabalho com janelas em tudo semelhantes as do sis-

tema operativo Segundo a Adobe o objectivo e complementar o browser dando

aos utilizadores (mas essencialmente aos programadores e equipas de desenvolvi-

mento) a escolha sobre como distribuir as suas aplicacoes Para este efeito o Adobe

AIR tem uma aproximacao diferente do Gears Em vez de ldquoestenderrdquo o browser

acrescentando-lhe funcionalidades o AIR permite tambem o desenvolvimento de

4Adobe - httpwwwadobecomproductsair

20

Estado da arte

aplicacoes que se destinam a ser executadas fora do ambiente do browser mas uti-

lizando as tecnologias comuns da Internet (por exemplo HTML CSS JavaScript

Flash Flex)[CDGH08]

A utilizacao desta tecnologia permite utilizar o browser ou o proprio runtime

Adobe AIR como plataforma de execucao da aplicacao

Na Tabela 31 faz-se uma comparacao das funcionalidades disponıveis de acordo

consoante se escolha o browser ou o desktop como plataforma base para a aplicacao

Uma vez que as aplicacoes Adobe AIR na plataforma desktop tem um caracter

persistente (sao instaladas no computador do utilizador) o Adobe AIR tem um

modelo de seguranca que se assemelha com o das tradicionais aplicacoes desktop

[Ada08] Este modelo e analisado nas seccoes 321 e 322 O ambiente em que

e executado o browser e restringido a execucao de web applications que podem

ser de varias origens (incluindo de origens anonimas ou sem confianca) O Adobe

AIR proporciona acesso a capacidades como acesso a ficheiros que necessitam da

confianca do utilizador

bull HTML ndash O desenvolvimento de aplicacoes para o Adobe AIR pode ser feito

com recurso a tecnologias de HTML e Ajax comuns utilizando as linguagens

de markup existentes distribuıdas como texto e interpretadas em execucao

(runtime)

bull Flash ndash Outra alternativa sera a utilizacao da linguagem Flash Permite a

renderizacao de graficos vectoriais e audiovıdeo com suporte nativo Utiliza

ActionScript para adicionar maior interactividade com o utilizador

bull Flex ndash O Flex e uma framework open source para o desenvolvimento de RIAs

usando Flash As aplicacoes Flex sao na realidade Flash sendo a principal

diferenca o ambiente de desenvolvimento

Como resultado uma aplicacao AIR podera ser implementada

bull Baseada em Flash ou Flex (aplicacoes cujo conteudo base e em ShockWave

Flash (SWF))

bull Baseada em Flash ou Flex tambem com HTML ou Portable Document Format

(PDF) Aplicacoes cujo conteudo de base e em FlashFlex (SWF) com HTML

(HTML JavaScript CSS) ou conteudo PDF incluıdo

bull Baseada em HTML Aplicacoes cujo conteudo base e em HTML Javascript

CSS

bull Baseada em HTML utilizando tambem FlashFlex ou PDF

21

Estado da arte

Os utilizadores interagem com uma aplicacao AIR da mesma forma que interagem

com outras aplicacoes com janelas nativas do seu sistema operativo O runtime e

instalado uma vez no computador do utilizador e a partir desse momento todas as

aplicacoes AIR terao o mesmo aspecto que qualquer outra aplicacao para o desktop

321 Seguranca

Permitir que uma web application aceda ao disco de armazenamento do utilizador

pode comprometer seriamente a sua seguranca Neste sentido o Adobe AIR tem

suporte para assinaturas digitais (Secure Sockets Layer (SSL)) que podem ser com-

pradas pelas equipas de desenvolvimento que o desejem e cujos certificados serao

apresentados ao utilizador no momento da instalacao Um outro aspecto ainda

relativo a seguranca e o mecanismo de isolamento de cada ambiente (sandbox )

322 Assinatura do codigo

O runtime AIR exige que todas as aplicacoes estejam digitalmente assinadas As

assinaturas digitais de codigo sao um processo que visa garantir a integridade da

aplicacao e a identidade do seu autor no momento da instalacao As equipas de

desenvolvimento podem ldquoassinarrdquo uma aplicacao utilizando um certificado atribuıdo

por uma Entidade Certificadora (Certification Authority) ou atraves de um certifi-

cado individual (self signed certificate) Neste momento o Adobe AIR suporta como

entidades certificadoras a Verisign e a Thawte [Ado08]

O instalador apresenta o nome de quem publica a aplicacao quando o codigo tiver

sido assinado com um certificado que apresente confianca ou que esteja encadeado

com um certificado que tenha ja sido aceite no computador em que se esta a instalar

a aplicacao

As equipas de desenvolvimento podem tambem assinar as aplicacoes com um

certificado auto-atribuıdo (um certificado criado por elas proprias) mas neste caso

o instalador apresentara estas aplicacoes como sendo de uma origem nao verificada

O AIR utiliza a infraestrutura publica de chaves [Ent07] suportada pelo arquivo

local do sistema operativo Para que a origem da aplicacao seja reconhecida o

computador onde a aplicacao AIR esta a ser instalada tem que confiar directamente

no certificado que foi utilizado para assinar a aplicacao ou confiar num certificado

que esteja num encadeamento logico de certificados confiados e que se ligue desta

forma ao certificado utilizado para assinar a aplicacao

Todas as aplicacoes AIR tem caracterısticas em comum independentemente da

tecnologia utilizada para o seu desenvolvimento (HTMLFlexFlash) No ambito

de uma aplicacao AIR existem um conjunto de APIs que estao disponıveis e que

tornam possıvel o acesso ao sistema local (leitura e escrita) e a recursos de rede que

22

Estado da arte

de outra forma nunca estariam acessıveis a partir de uma web application comum

Cada aplicacao AIR possui tambem diferentes nıveis de isolamento chamados secu-

rity sandboxes dependendo do tipo de conteudo que esta a ser carregado e do seu

objectivo

bull Isolamento ao nıvel da aplicacao5 ndash E a raiz de cada aplicacao AIR Este

nıvel de isolamento permite o acesso a APIs privilegiadas e especıficas do

AIR Em contrapartida e negado o acesso a algumas APIs que poderiam ser

facilmente utilizadas de forma maliciosa contra o utilizador final Importacao

dinamica de conteudos remotos e geralmente proibido e as tecnicas e mecan-

ismos de geracao dinamica de codigo sao fortemente restringidas Apenas

conteudo carregado directamente da directoria base da aplicacao podera ser

colocado neste nıvel de isolamento

bull Isolamento nao especıfico da aplicacao6 ndash contem todo o outro conteudo

que nao tenha sido carregado directamente para o isolamento da aplicacao

Isto inclui conteudo local e remoto Este tipo de conteudo nao tem acesso

directo as APIs do AIR e rege-se pelas mesmas regras tal como se tivesse sido

carregado por um browser a partir da mesma localizacao (por exemplo HTML

carregado a partir de um domınio remoto comporta-se da mesma forma que se

fosse acedido a partir do browser)

33 Mozilla Prism

331 XML User Interface Language

O eXtensible User Interface Language (XUL) e uma linguagem de anotacao

baseada em XML desenvolvida pela Mozilla Foundation que opera em aplicacoes

Mozilla multi plataforma tal como o Firefox O motor Gecko e a unica imple-

mentacao completa desta linguagem que foi desenhada sobre padroes web comuns

como CSS JavaScript e o DOM e permite o desenvolvimento de interfaces graficas

utilizando elementos pre-definidos tais como window box page textbox radio

button entre outros Infelizmente o XUL nao possui qualquer especificacao formal

ou implementacoes de inter-operabilidade para outros motores que nao o Gecko No

entanto a sua implementacao e licenciada em codigo aberto pelas licencas GNU Gen-

eral Public License (GPL) GNU Lesser General Public License (LGPL) e Mozilla

Public License (MPL)

Enunciam-se algumas caracterısticas desta linguagem

5NT application sandbox6NT non-application sandbox

23

Estado da arte

Liguagem de anotacao poderosa baseada em componentes (widgets) O ob-

jectivo do XUL e permitir a construcao de aplicacoes multi-plataforma em

claro contraste com o Dynamic HyperText Transfer Protocol (DHTML) que se

destina ao desenvolvimento de paginas web Por esta razao o XUL esta orien-

tado a componentes tais como janelas botoes e etiquetas em vez de paginas

cabecalhos de texto e ligacoes de hipertexto Investir tempo e esforco para

atingir este mesmo resultado em aplicacoes baseadas em DHTML compromete

frequentemente a complexidade e desempenho da aplicacao

Baseado em padroes O XUL e um dialecto XML baseado no padrao W3C XML

10 As aplicacoes escritas em XUL sao tambem baseadas em especificacoes

W3C adicionais como HTML 40 CSS DOM nıvel 1 e 2 JavaScript 15

incluindo ECMA-262 Edition 3 (ECMAscript)

Portabilidade entre plataformas Tal como HTML o XUL foi desenhado para

ser independente da plataforma em que e utilizado tornando as aplicacoes

facilmente portaveis entre sistemas operativos nos quais o Mozilla e suportado

Uma vez que o XUL oferece um nıvel de abstraccao dos componentes graficos

de interface que disponibiliza implementa a premissa ldquoum codigo para todas

as plataformasrdquo A interface grafica de todos os produtos centrais Mozilla

(browser instant messenger livro de enderecos) e escrita em XUL com um

unico codigo base que suporta todas as plataformas Mozilla

Separacao entre o nıvel de apresentacao e a logica de negocio Uma das

maiores preocupacoes no desenvolvimento para a Internet e a forte ligacao

entre estas duas camadas (interface e logica) Isto constitui um problema sig-

nificativo no desenvolvimento de grandes aplicacoes especialmente quando o

desenvolvimento e feito em ambientes de equipa porque as capacidades de de-

senvolvimento destas duas partes da aplicacao estao muitas vezes espalhadas

por diferentes elementos O XUL permite uma clara distincao entre a definicao

da aplicacao cliente e da logica de implementacao (XUL eXtensible Binding

Language (XBL) e JavaScript) apresentacao (CSS e imagens) internacional-

izacao (Document Type Definitions (DTDs) e etiquetas de texto em lınguas

especıficas guardados em ficheiros properties) O esquema grafico e apre-

sentacao de uma aplicacao XUL pode ser alterado de forma independente da

sua logica ou implementacao e a aplicacao pode ainda ser traduzida (interna-

tionalization) de forma independente da sua logica implementacao ou apre-

sentacao Este grau de separacao resulta em aplicacoes que sao mais faceis de

manter pelos programadores e facilmente adaptadas por designers e tradutores

24

Estado da arte

Facil adaptacao Outro benefıcio que advem do nıvel de separacao entre logica

de negocio e apresentacao oferecido pelo XUL e a facilidade com que se pode

adaptar uma aplicacao para diferentes clientes ou grupos de utilizadores Um

programador pode utilizar a mesma aplicacao base e adapta-la consoante as

necessidades atraves de diferentes temas (skins) e ficheiros de lınguas Desta

forma uma aplicacao escrita e desenvolvida em Ingles pode ser rapidamente

traduzida para Portugues e distribuıda com outra aparencia mais apropriada

ao cliente alvo

332 Prism

O Mozilla Prism e um browser simplificado e ldquointerpretadorrdquo de XUL (tambem

designado por XULRunner) que acolhe web applications sem a interface grafica ha-

bitual de um browser Baseia-se num conceito designado por Site Specific Browser

(SSB) Um SSB e uma aplicacao com um browser embebido desenhado para exe-

cutar apenas uma web application Nao possui os menus e barras de ferramentas

habituais Um SSB tem uma integracao com o sistema operativo e com o desktop

muito mais estreita do que uma web application acedida atraves de um browser uma

vez que e executado em janela propria

O Prism resulta de uma experiencia da Mozilla e visa reduzir as diferencas entre

as desktop applications tradicionais e as web applications Um dos aspectos focados e

a experiencia do utilizador Numa apresentacao oficial e dito que ldquo[o Prism] pretende

ser uma ponte entre as diferencas que existem entre as aplicacoes tradicionais de

desktop e as web applications explorando novos modelos de usabilidade enquanto

que a linha que as separa se continua a definirrdquo [Lab07]

34 HTML 5

A especificacao HTML 5 [Hic08] que se encontra em fase de desenvolvimento

pelo grupo WHATWG pretende ser uma norma de substituicao dos padroes HTML

4 XHTML 1x e do DOM2 HTML Uma das propriedades que o distingue das tec-

nologias que pretende substituir e precisamente o suporte para OWA e armazena-

mento de dados no cliente de uma forma relacional Nao sendo propriamente uma

tecnologia ndashmas antes uma especificacao ndashe aqui mencionada por ter servido como

referencia a diversas implementacoes de funcionalidades offline e por se considerar

que venha a ter um impacto significativo nas implementacoes de diversos browsers

Dion Almaer defendeu no seu blogue que o Gears era uma implementacao do

HTML 5 No seu artigo ldquoGears as a bleeding-edge HTML 5 implementationrdquo [Alm08]

o autor diz que ambos ndasho Gears e o HTML 5 ndashpretendem dar a web caracterısticas

25

Estado da arte

semelhantes e nao encontrar motivo de ldquocompeticaordquo entre as duas mas que en-

quanto o HTML 5 e uma especificacao o Gears e uma implementacao

No entanto tambem e verdade que o HTML 5 cobre muitos outros pontos para

alem das OWA que saem completamente fora do ambito do Gears Se esta es-

pecificacao atingir um estado de maturidade que possibilite a sua adopcao pelos

principais browsers tornando nativo do browser o suporte OWA entao deixara de

fazer sentido a existencia de uma extensao como o Gears

A especificacao HTML 5 disponibiliza duas APIs relevantes para o tema das

OWA

1 Uma base de dados baseada em SQL que permite o armazenamento de dados

do lado do cliente

2 Uma ldquocacherdquo HTTP que garante a disponibilidade das aplicacoes mesmo quando

o utilizador nao possui uma ligacao a Internet

Estas caracterısticas sao as bases da tecnologia das OWA e tem correspondencia

com os pontos analisados nas seccoes 311 e 311

35 Web applications que usam funcionalidades offline

Nesta seccao apresentam-se algumas web applications que actualmente disponi-

bilizam funcionalidades offline Estas aplicacoes foram escolhidas para uma analise

mais pormenorizada por utilizarem o Gears que tal como descrito na seccao 4 foi

a tecnologia escolhida para o projecto

351 Google Reader e Google Docs

O Google Reader7 e um leitor de feeds RSS Permite gerir a subscricao de varios

sites simultaneamente que disponibilizem conteudos neste formato e foi a primeira

web application da Google com uma versao offline publicamente acessıvel (desde

Junho de 2007)

O Google Reader implementa o modo ldquoutilizador deciderdquo oferecendo na sua

interface um botao que permite alternar entre os modos online e offline

O Google Docs8 e uma web application que permite a criacao e edicao de doc-

umentos de texto folhas de calculo e apresentacoes Era ja publico desde Janeiro

de 2008 que o Google estava a desenvolver uma versao OWA desta aplicacao mas o

acesso a uma versao experimental so foi possıvel a partir de 31 de Maio de 2008

7Google Reader - httpreadergooglecom8Google Docs - httpdocsgooglecom

26

Estado da arte

A implementacao das funcionalidades offline nestas duas aplicacoes seguiu difer-

entes aproximacoes principalmente porque o Google Reader apresenta ao utilizador

informacoes que sao fornecidas por fontes externas enquanto que no Google Docs

a informacao e criada e editada pelo utilizador sobre a forma de documentos

A diferente origem da informacao implica que no Google Reader seja necessario

prever casos de excepcao tal como existirem demasiados itens que necessitam de

ser transferidos para o cliente Nao observar este ponto causa um problema grave

de usabilidade e para evitar tempos de espera demasiado longos e uma interface

com pouca capacidade de resposta as accoes do utilizador o Google Reader apenas

transfere para o cliente os dois mil itens mais recentes na transicao para o modo

offline

352 Remember the Milk

O Remember The Milk9 e uma web application desenvolvida por uma equipa

Australiana que proporciona funcionalidades de agenda gestao de tempo e de tare-

fas e foi uma das primeiras aplicacoes independentes do Google a adoptar o Gears

para acessos em modo offline Permite que os seus utilizadores facam uma gestao

de tarefas agrupando-as em listas adicionando-lhes campos de informacao adicional

ou dando-lhes informacao geografica (recorrendo ao servico Google Maps10) Entre

a sua lista de funcionalidades encontra-se ainda a possibilidade de importar e ex-

portar eventos no formato iCalendar (ics) etiquetas (tags) em tarefas publicacao

Really Simple Syndication (RSS) e partilha de categorias de tarefas de acordo com

diferentes nıveis de permissoes de acesso definidos pelo utilizador

353 MySpace e WordPresscom

O MySpace uma das maiores social networks na Internet anunciou recente-

mente que vai disponibilizar uma versao do seu cliente de e-mail que utiliza o Gears

para acelerar o seu desempenho Numa fase inicial estara disponıvel apenas para

utilizadores que tenham cinco mil ou mais mensagens na sua caixa de correio e

permitira efectuar pesquisas muito mais rapido que a sua versao online

O servico de blogs Wordpresscom anunciou tambem o inıcio da utilizacao desta

tecnologia com o fim de melhorar o desempenho A versao que utiliza esta tecnologia

descarrega e armazena no cliente um conjunto de imagens e scripts que passam a

ter preferencia sobre os seus congeneres online e que permitem acelerar o processo

de carregamento da aplicacao e visualizacao de blogs

9Remember The Milk ndash httpwwwrememberthemilkcom10Google Maps ndash httpmapsgooglecom

27

Estado da arte

O MySpace e o Wordpresscom sao dois exemplos da utilizacao da tecnologia

OWA para optimizacao de web application ja existentes Sem pretenderem disponi-

bilizar uma versao que seja totalmente offline fazem uso do Gears para armazenar no

cliente parte dos recursos frequentemente acedidos na visualizacao das suas paginas

36 Escolha da tecnologia

Apos a analise das tecnologias apresentada nas seccoes 31 a 34 foi necessario es-

tudar a adequacao de cada uma delas ao projecto em questao Desde logo e possıvel

observar que nem todas se dedicam apenas a OWA Por exemplo o Adobe AIR

apesar de ter suporte para OWA apenas disponibiliza algumas das funcionalidades

identificadas como mais indicadas para a execucao do projecto quando utilizado

na sua vertente desktop tal como exposto na Tabela 31 mas a utilizacao desta

vertente implicaria o desenvolvimento de novas interfaces e de novas formas de co-

municacao (troca de mensagens XML ou JSON) A vertente web do Adobe AIR

foca-se mais especificamente nas Rich Internet Applications e permite a reutilizacao

do codigo ja existente (exigindo naturalmente a sua adaptacao e a implementacao

das funcionalidades pretendidas)

A tecnologia escolhida para a realizacao deste trabalho foi o Gears sendo que

um dos principais factores a influenciar esta opcao foi a liberdade introduzida pela

sua licenca Berkeley Software Distribution (BSD)11

Considerou-se o funcionamento desta ferramenta extremamente adequando a

aplicacao no WOW uma vez que o seu principal objectivo e precisamente tornar

possıvel a execucao offline de uma pagina web e por virtude deste facto o Gears tem

uma API concisa e de simples aplicacao pratica uma vez que nao possui quaisquer

outros elementos distractores O funcionamento do seu ManagedResourceStore ex-

emplificado na Figura 31 com a capacidade de actualizacao de recursos definidos

num ficheiro manifesto especificado em JSON pesou tambem nesta decisao

11Sobre a licenca BSD consultar httpwwwopensourceorglicensesbsd-licensephp e http

wwwlinfoorgbsdlicensehtml

28

Estado da arte

Figura 31 Esquema UML do processo efectuado pelos recursos do Gears do tipoManagedResourceStore para a actualizacao dos conteudos definidos no ficheiro manifesto

29

Estado da arte

Funcionalidade RIAs no browser RIAs no desktop

Disponibilidadeda aplicacao

As aplicacoes podem ser facil-mente exploradas e utilizadas

As aplicacoes quando instal-adas tem maior grau de fun-cionalidades e persistencia

Instalacao Nao e necessario qualquer tipode instalacao

As aplicacoes sao instaladasatraves do browser ou descar-regadas e instaladas comouma aplicacao tradicional

Actualizacoes Aplicacoes sao actualizadascarregando conteudos paraum website

O AIR disponibiliza uma APIque permite que as aplicacoessejam actualizadas de umaforma

Sistemas opera-tivos suportados

As aplicacoes podem ser exe-cutadas em diversos sistemasoperativos e browsers

As aplicacoes sao multi-plataforma e podem serinstaladas e executadas emdiversos sistemas operativos ebrowsers

Linguagens deprogramacao

Javascript e disponibilizadopelo browser e ActionScripte disponibilizado pelo AdobeFlash Player

Maquinas virtuais deJavascript e ActionScriptcompatıveis com o browser

Capacidade deexecucao embackground

As RIAs podem ser execu-tadas numa janela do browser

As aplicacoes podem ser ex-ecutadas em background edisponibilizar notificacoes talcomo uma aplicacao tradi-cional

Persistencia A actividade esta limitada asessao do browser Quando obrowser e encerrado toda ainformacao e descartada

As aplicacoes sao instaladas eestao disponıveis no desktopPodem armazenar informacaolocalmente e estao disponıveisoffline

Integracao com odesktop

Integracao com o desktop lim-itada devido a restricoes im-postas pelo browser

As aplicacoes podem acederao sistema de ficheiro ao clip-board eventos notificacoesetc

Controlo da inter-face com o uti-lizador

As aplicacoes sao acedidasatraves de uma janela dobrowser que tem os seusproprios controlos e visualgrafico

As aplicacoes tem um vi-sual grafico proprio em janelapropria

Armazenamentode dados

As aplicacoes tem armazena-mento limitado que pode serreescrito pelo browser

As aplicacoes tem acesso a to-talidade do espaco disponıvellocalmente e a uma base dedados com a possibilidade deencriptacao

Tabela 31 Comparacao das funcionalidades oferecidas pelo Adobe AIR para as platafor-mas web e desktop

30

Estado da arte

Aplicacao Modo de execucao utilizadoGoogle Reader Utiliza o modo ldquoutilizador deciderdquo disponibilizando

ao utilizador um botao para alternar entre os modosonline e offline Como lida com informacao recol-hida de fontes externas de natureza frequentementeefemera o processo de sincronizacao apenas transfereos dois mil itens mais recentes quando passa ao es-tado offline Neste modo sao ainda guardadas in-formacoes de itens lidos e etiquetas atribuıdas quesao sincronizadas com o servidor quando o utilizadorvoltar a activar estado online

Google Docs Utiliza o modo ldquoaplicacao deciderdquo permitindo que outilizador edite os conteudos de documentos de textofolhas de calculo e de apresentacoes independente-mente do estado da ligacao desde o momento em queas funcionalidades offline sao activadas A aplicacaofaz pequenas sincronizacoes com o servidor sempre quenecessario

Remember the Milk Utiliza um modo hıbrido entre ldquoaplicacao deciderdquo eldquoutilizador deciderdquo A aplicacao encarrega-se da sin-cronizacao de dados mas disponibiliza um controlona sua interface que permite despoletar manualmenteeste processo para situacoes em que o utilizador fez al-teracoes recentes e pretende usufruir das capacidadesoffline imediatamente

MySpace O MySpace anunciou a utilizacao de mecanismos dearmazenamento de dados no cliente com recurso atecnologias OWA para melhorar o desempenho doseu cliente web de correio electronico nomeadamenteno que diz respeito a operacoes de pesquisa e or-denacao Inicialmente esta funcionalidade estara ape-nas disponıvel para utilizadores com cinco mil ou maismensagens na sua caixa de correio mas nao e aindaclaro se sera disponibilizada uma versao totalmenteoffline

Tabela 32 Resumo da utilizacao de tecnologias OWA em algumas web applications con-sideradas na analise do estado da arte

31

Estado da arte

32

Capıtulo 4

Desenvolvimento

Neste capıtulo introduz-se a aplicacao WOW e apresenta-se o estudo que foi

feito da adequacao de cada tecnologia para a implementacao da funcionalidade of-

fline nesta plataforma Fazem-se diversas consideracoes sobre opcoes a tomar na

concepcao de OWAs e problemas comuns na sua implementacao bem como sug-

estoes para os resolver O WOW e uma aplicacao ja existente de gestao de ordens

de trabalho e do fluxo de tarefas numa empresa ou organizacao

41 Como ficar offline

Na maior parte das web applications de hoje nao existe uma camada de dados

real A aplicacao exemplificada na Figura 41 ao longo da sua execucao acede

directamente a sua unica fonte de dados (o servidor) atraves de chamadas Ajax sem

que exista uma separacao clara destas duas camadas

Para que uma web application seja capaz de ser executada sem uma ligacao

activa a Internet e mantenha o seu caracter dinamico torna-se necessario incluir

Figura 41 Exemplo de uma arquitectura de uma web application sem uma camada deabstraccao de dados Figura adaptada de http gears google com

33

Desenvolvimento

Figura 42 Exemplo de uma arquitectura de uma web application com uma camada deabstraccao de dados Figura adaptada de http gears google com

um mecanismo de armazenamento de dados local seja uma base de dados ou a

capacidade de acesso ao disco No entanto este mecanismo introduz dois problemas

1 Qual das fontes de dados utilizar quando um utilizador faz um pedido de

informacao

2 A necessidade de implementar uma camada de acesso a dados que seja coerente

quer se use o servidor remoto ou local

Por exemplo em vez de a aplicacao Ajax fazer um pedido relativo as contas de

todos os utilizadores em formato JSON directamente ao servidor remoto podera ao

inves fazer o pedido a um objecto intermedio da camada de dados Este objecto

demonstrado na Figura 42 sera responsavel por implementar uma interface de

acesso a base de dados e retornar um objecto JavaScript com uma representacao da

resposta do servidor

Mas a existencia de uma segunda fonte de dados torna recomendavel tambem

a implementacao de uma camada de data switching que em funcao da existencia

de conexao a Internet e da necessidade de actualizacao dos dados decide se faz o

pedido ao servidor remoto ou se fornece os dados presentes localmente Este objecto

apresentado na Figura 43 decidira de forma transparente para o utilizador se le ou

escreve os dados localmente ou se os enviapede ao servidor remoto e pode tambem

iniciar o processo de convergencia de dados e de resolucao de conflitos

411 Funcionalidades disponıveis em modo offline

Por razoes praticas e provavel que nem todas as funcionalidades da aplicacao

possam ser disponibilizadas em modo offline E necessario escolher quais as fun-

cionalidades a disponibilizar no modo offline da aplicacao e implementar a logica

que decide quando utilizar a base de dados local ou o servidor remoto Apesar do

acesso a base de dados local ser muito mais rapido do que aceder ao servidor o

acesso local nem sempre e preferido Ha varias razoes que podem tornar necessario

escolher o acesso ao servidor em vez do acesso local

34

Desenvolvimento

Figura 43 Exemplo de uma arquitectura de uma web application com uma camada deabstraccao de dados e um data switch Figura adaptada de http gears google com

1 A informacao pode ter uma natureza efemera e nao fazer sentido guarda-la

localmente Exemplo dados em tempo real da bolsa de valores de Lisboa

2 Algumas aplicacoes lidam com informacao que so faz sentido na presenca de

uma ligacao Exemplo Instant Messaging

3 A aplicacao podera escolher apenas guardar a informacao acedida mais fre-

quentemente Exemplo para o utilizador poder alterar a lıngua de apre-

sentacao da aplicacao os conteudos terao que ser guardados em todas as

lınguas disponibilizadas pela aplicacao O custo de implementacao de algu-

mas funcionalidades pode nao compensar o benefıcio

4 A capacidade de processamento ou de armazenamento de dados pode inviabi-

lizar algumas funcionalidades offline Exemplo se uma dada funcionalidade

necessita de uma capacidade de armazenamento de dados para alem do razoavel

de um computador pessoal para ser util (visualizador de mapas)

42 Modos de execucao

Um aspecto que e necessario estudar para qualquer web application que se deseje

disponibilizar offline prende-se com tres modos de execucao que devem ser consid-

erados

1 Utilizador decide o modo de execucao A aplicacao tem modos distintos

de execucao para os estados online e offline geralmente indicados na interface

com o utilizador O utilizador e informado do estado da ligacao e participa na

alteracao de estado de execucao da aplicacao interagindo com a sua interface

2 Aplicacao decide o modo de execucao Pode ser implementado na propria

aplicacao um mecanismo de deteccao do estado da ligacao (por exemplo atraves

35

Desenvolvimento

de chamadas Ajax periodicas) transitando de estado e sincronizando automati-

camente Desta forma o utilizador nao precisa de participar na alteracao de

estado a menos que exista um conflito de dados que requeira a sua atencao

3 Aplicacao assume sempre o estado offline Outra hipotese sera imple-

mentar uma web application que assume sempre estar na ausencia de uma

ligacao ao servidor de dados Esta aplicacao responde aos pedidos do uti-

lizador efectuando pedidos de informacao ao servidor mas nao dependendo

de uma resposta valida para mostrar a informacao que ja tinha disponıvel an-

teriormente A sincronizacao de dados com o servidor e tentada sempre que

existam dados para submeter e uma accao do utilizador

421 Modo ldquoutilizador deciderdquo

Neste modo de execucao quando a aplicacao esta online comunica com o servidor

remoto quando esta offline comunica com a base de dados local A informacao tem

que ser sincronizada sempre que se muda de modo A principal vantagem desta opcao

e que e a mais simples de implementar mesmo para uma aplicacao ja existente e

portanto uma forma expedita de disponibilizar uma OWA No entanto tem tambem

algumas desvantagens que devem ser consideradas

1 O utilizador tem que se lembrar de fazer a alteracao de estado de execucao

Caso contrario podera estar a trabalhar inadvertidamente numa versao offline

com dados antigos ou nao ter a informacao necessaria se perder subitamente

a ligacao

2 Se a ligacao for intermitente o utilizador tera ou que escolher um dos modos

de execucao ou estar constantemente a trocar

3 Uma vez que a base de dados nao esta sempre actualizada nao podera ser

utilizada para melhorar a rapidez de execucao da aplicacao quando em modo

online

422 Modo aplicacao decide

A deteccao do estado da ligacao pode ser implementada atraves de um pedido

assıncrono ao servidor tal como ilustrado na Figura 44 O resultado deste pedido

definira o estado online (em caso de sucesso) ou offline (em caso de falha) A

sincronizacao de dados podera ser feita sempre que ocorra uma transicao do es-

tado offline para o estado online No entanto este metodo nao se revela eficiente

36

Desenvolvimento

Figura 44 Esquema grafico ilustrando uma OWA executando no browser utilizando ummodo de execucao do tipo ldquoaplicacao deciderdquo com deteccao automatica do estado daligacao via pedidos Ajax assıncronos a cada cinco segundos

para grandes aplicacoes uma vez que requer a troca de mensagens demasiado fre-

quentes com o servidor que se destinam exclusivamente a monitorizacao do estado

da ligacao

423 Modo ldquoaplicacao assume o estado offlinerdquo

Uma aplicacao transparente funciona assumindo sempre que esta em modo of-

fline ou pelo menos que pode perder a ligacao a qualquer momento Neste modo

tira-se o maximo partido do armazenamento local e fazem-se pequenas mas contınuas

sincronizacoes com o servidor sempre que este esteja disponıvel A sincronizacao de

dados tambem e feita sempre que se volta ao estado online

As vantagens de uma web application transparente sao as seguintes

bull Uma melhor experiencia para o utilizador uma vez que este nao tem que se

preocupar com o estado da ligacao ou com a transicao de estados

bull A aplicacao funciona de forma coerente mesmo que a ligacao seja intermitente

bull Uma vez que o armazenamento local e mantido actualizado pode ser utilizado

para melhorar o desempenho da aplicacao

Foram identificadas as seguintes desvantagens

bull E mais difıcil de implementar e a sincronizacao acarreta cuidados especiais

bull E necessario um cuidado adicional para evitar que as operacoes de sincronizacao

frequentes que ocorrem automaticamente nao afectem os tempos de resposta

da aplicacao

bull Os testes a aplicacao sao mais complexos uma vez que a sincronizacao de dados

nao ocorre em resposta a uma accao do utilizador

37

Desenvolvimento

43 Sincronizacao de dados

A sincronizacao de dados consiste na capacidade de identificar e transferir pe-

riodicamente a versao mais actual dos dados entre o cliente e o(s) servidor(es)

Independentemente do modo de execucao escolhido e mesmo do estado da ligacao

do utilizador a informacao armazenada localmente e a informacao armazenada no

servidor estarao por vezes dessincronizadas Isto podera acontecer sempre que por

exemplo

bull O utilizador faz alteracoes em modo offline

bull A informacao e partilhada e pode ser alterada por uma entidade externa

bull A informacao e fornecida por uma entidade externa

Resolver estas diferencas de forma a que a informacao local e remota encontrem

a igualdade chama-se sincronizacao de dados Ha varias aproximacoes possıveis

para este efeito que dependem da natureza da aplicacao cada uma com vantagens

e desvantagens

A capacidade de suportar a mobilidade dos utilizadores torna-se cada vez um

ponto mais importante de uma web application Para uma organizacao de dimensao

global e vital garantir que os seus colaboradores tem acesso a mesma informacao

que tem disponıvel nos seus postos de trabalho mesmo quando estao fora Na maior

parte dos casos estes colaboradores terao acesso a um computador portatil um

desktop Smartphone ou PDA e atraves destes poderao ter acesso a sua informacao

directamente atraves de ligacoes encriptadas Virtual Private Network (VPN) de um

servidor web ou de outro mecanismo de rede

Esta solucao e simples de implementar mas infelizmente para a maioria dos

colaboradores com grande factor de mobilidade nao e satisfatoria As principais

desvantagens sao as seguintes

bull Requisitos de ligacao Para permitir que os utilizadores acedam a sua in-

formacao e necessario garantir a capacidade constante de comunicacao pelo

menos durante o tempo necessario que assegure a sua transferencia

bull Velocidade de ligacao sem persistencia de dados e em ligacoes de fraca

qualidade a usabilidade por vezes torna-se inaceitavel

bull Ponto crıtico de falha Com este tipo de solucao todos os utilizadores de-

pendem da base de dados que armazena informacao vital para o funcionamento

do cliente

38

Desenvolvimento

bull Scalability do servidor A medida que novos utilizadores sao adicionados ao

sistema o desempenho do servidor e afectado levando a necessidade de maior

capacidade de armazenamento eou processamento

De acordo com a documentacao da Microsoft Sync Framework [Mic08] uma

solucao alternativa consiste em implementar uma Occasionally Connected Appli-

cation (OCA) Uma OCA permite a um utilizador remoto continuar a aceder a

sua informacao mesmo depois de perder a ligacao mas em vez de recorrer a um

servidor recorre a informacao armazenada no seu dispositivo local Para preencher

localmente a informacao que o utilizador necessita uma OCA possui mecanismos

de sincronizacao de dados que sao oferecidos por esta framework

431 Quando sincronizar

Uma das solucoes mais simples de implementar passa por disponibilizar um

mecanismo manual que despoleta a sincronizacao Diz-se manual porque e o uti-

lizador que escolhe quando sincronizar e pode ser implementada simplesmente

fazendo o upload de toda a informacao para o servidor e depois fazendo o download

da copia mais recente da informacao antes de voltar a ficar offline Para que esta

seja uma opcao viavel e necessario que

bull O volume de dados seja suficientemente pequeno para que possa ser transferido

do servidor para o cliente num espaco de tempo aceitavel

bull Que o utilizador indique explicitamente que quer mudar para o estado offline

ou online pressionando um botao da interface

Contudo podem ser identificados alguns problemas relacionados com esta abor-

dagem

bull Os utilizadores nem sempre podem prever o estado das suas ligacoes A ligacao

pode-se perder subitamente ou ter um caracter intermitente

bull O utilizador pode esquecer-se de efectuar a sincronizacao

Outra opcao sera conjugar a sincronizacao de dados com o modo de execucao

transparente A sincronizacao ocorre automaticamente em background de forma

nao intrusiva para o utilizador A aplicacao comunica com o servidor regularmente

efectuando pequenas trocas de dados com o objectivo de manter o sincronismo da

informacao local e remota Esta abordagem pode ser implementada com pedidos

Ajax assıncronos e regulares ao servidor o que permite manter a interaccao com a

interface fluıda evitando bloqueios Estes pedidos sao feitos prevendo as situacoes

39

Desenvolvimento

de disponibilidade ou indisponibilidade (timeout) do servidor Uma outra opcao

sera permitir que o servidor comunique essas alteracoes utilizando Comet1 tal como

descrito em [Wil06] e [Rus06] As vantagens destas aproximacoes sao

bull A informacao esta disponıvel a qualquer altura que o utilizador decida ficar

offline ou que a ligacao seja acidentalmente perdida

bull O desempenho da aplicacao pode ser melhorado quando se estiver a utilizar

uma ligacao a Internet lenta uma vez que o acesso a dados locais e mais

eficiente do que a consulta de dados ao servidor

44 WOW

O WOW e uma plataforma integrada de gestao de ordens de trabalho ja ex-

istente e desenvolvida pela Critical Software SA a qual se pretende adicionar a

capacidade de execucao offline Esta aplicacao e extremamente dinamica e con-

figuravel com um conjunto extremamente rico de funcionalidades das quais se

destacam

bull Gestao de Ordens de Trabalho ndash suportando a gestao dos pedidos desde a

sua criacao ate ao seu fecho tomando em conta os diferentes tipos de pedidos

(ordens de trabalho pedidos de informacao melhorias resolucao de problemas

etc) e diferentes tipos de accoes possıveis para cada um (Figura 45)

bull Monitorizacao de alteracoes ndash Historico de mudancas anexos e estados criando

relatorios de alteracao automaticamente (o que por quem e quando)

bull Uso de Service Level Agreements (SLAs) ndash E possıvel associar a um pedido um

SLA que define qual o perıodo de tempo atribuıdo a resolucao de um pedido

controlando e agilizando a resolucao do mesmo

bull Utilizacao de queries de utilizador configuraveis que permitem acesso rapido

a determinadas ordens de trabalho de acordo com o filtro configurado (por

exemplo ldquoPara mimrdquo ldquoPara o Grupordquo ldquoPelo Grupordquo)

bull Gestao do relacionamento entre pedidos

bull Pesquisa e filtragem de ordens de trabalho

bull Exportacao de dados em formatos padrao (PDF DOC ou XLS)

bull Integravel com solucoes externas

40

Desenvolvimento

Figura 45 Detalhe de um conjunto possıvel de estados e respectivas transicoes para umadada ordem de trabalho no WOW desde a sua submissao no sistema ate a sua conclusaoem fecho ou cancelamento Esta figura representa apenas um exemplo ja que o mapa deestados para uma ordem de trabalho e dinamico e pode ser alterado por um administradorFigura retirada de uma brochura promocional do WOW Critical Software SA

A utilizacao de uma ferramenta deste tipo por parte de uma empresa ou orga-

nizacao oferece vantagens quer a gestao de topo quer aos colaboradores individuais

para os colaboradores individuais o WOW e uma aplicacao onde estao registadas

todas as tarefas contribuindo activamente para o desenvolvimento em ambientes

multi-tarefa e para a organizacao pessoal das tarefas de acordo com prioridades

Para a gestao de topo esta ferramenta permite obter uma visao global do estado da

organizacao em termos de tempo gasto por tarefa executada sendo uma mais valia

para a previsao e gestaoalocacao de recursos

45 Visao geral sobre a arquitectura do WOW

O WOW e interessante nao so do ponto de vista de produto como tambem do

ponto de vista de plataforma Existem diversos plug-ins que estendem as funcional-

idades do WOW e existem ate projectos que pretendem usar a arquitectura do

WOW para criar produtos com fins diferentes do inicial (por exemplo o WOW-

Storm ndash um sistema de registo e classificacao social de ideias)

De modo a conseguir ter essa expansibilidade a plataforma WOW assenta sob

uma arquitectura distribuıda modular e expansıvel com uma componente central

ndash o core ndash estruturado em camadas logicas E no core que se situam todas as

1O Comet e um conceito semelhante ao Ajax introduzido por Alex Russel mas no qual e o servidor quetoma a iniciativa de ldquoenviarrdquo os dados ao browser sem que este tenha que efectuar um pedido Tambem econhecido por Ajax Push Reverse Ajax ou HTTP Streaming

41

Desenvolvimento

funcionalidades base da aplicacao quer a nıvel logico funcional e de apresentacao

quer a nıvel de gestao e configuracao

E possıvel a execucao de varias instancias do core simultaneamente em servidores

distintos o que permite a alta escalabilidade e disponibilidade desta aplicacao A

consistencia dos dados fica sempre garantida atraves da partilha da base de dados

e pelo balanceamento dos pedidos uma vez que cada um e encaminhado para uma

unica instancia

O WOW apresenta tambem a vantagem de ser uma plataforma extensıvel E

possıvel adicionar novas caracterısticas a plataforma atraves de componentes que se

podem ser divididos em duas categorias plugins e connectors

Os plugins sao componentes que se encontram no mesmo no fısico que a aplicacao

partilhando do mesmo contexto de execucao do core Sao assim uma forma mais

directa de obter informacao da plataforma visto que nao possuem restricoes de

acesso aos dados nem dependencias externas A arquitectura deste componente tera

assim que permitir varias execucoes instanciadas cada uma associada a um core

Por outro lado os connectors sao componentes que se encontram distribuıdos

comunicando externamente com o core Quer a sua execucao quer a obtencao

dos dados estao assim dependentes de interfaces de comunicacao externas que a

plataforma disponibiliza Estes componentes ao contrario dos plugins sao instan-

ciados unicamente e recorrem ao protocolo de comunicacao Java Messaging Service

(JMS) para comunicar com o core

46 WOW Offline

Para alem das opcoes tomadas relativamente a tecnologia a utilizar surgiu

tambem a necessidade de optar por um dos modos de execucao apresentados na

seccao 42

Das tres opcoes possıveis foi o modo ldquoaplicacao assume o estado offlinerdquo descrito

na seccao 423 que mereceu a maior atencao uma vez que reune as vantagens de

uma experiencia mais positiva para o utilizador (uma vez que este nao tem que

participar activamente na alteracao do modo execucao como descrito na seccao 421)

e nao constitui uma sobrecarga excessiva para servidor (como o modo abordado na

seccao 422)

No entanto esta opcao comprometia a complexidade da implementacao para alem

dos objectivos propostos para este projecto e para cumprir o prazo dado foi tomada

a decisao de implementar o modo ldquoutilizador deciderdquo especificando apenas de forma

teorica o modo ldquoaplicacao assume o estado offlinerdquo

As caracterısticas do Gears foram ja descritas na seccao 31 Na Figura 47

mostra-se a sua forma de funcionamento quando integrado numa web application

42

Desenvolvimento

Nesta figura representa-se o modulo LocalServer do Gears como um ponto de de-

cisao Aqui sao testadas as condicoes que determinam se o pedido sera interceptado e

servido localmente ou se prossegue para uma maquina remota E tambem represen-

tada uma base de dados que corresponde ao modulo Database mas que podera nao

ser utilizada Este modulo tal como o modulo Workerpool tem caracter opcional

e sao utilizados consoante os requisitos da aplicacao

A plataforma WOW lida com mais dados do que e necessario passar para o

lado do cliente Em conformidade com o ja exposto na seccao 411 volta-se a

frisar que nao se pretende recriar toda a logica de negocio nem os conteudos da

base de dados no cliente pela sua complexidade e volume de dados Pretende-se

pelo contrario permitir que os utilizadores tirem partido da capacidade de poder

consultar as suas ordens de trabalho quando nao dispoe de uma ligacao transferindo

apenas o essencial para isto seja possıvel

A pagina inicial do WOW apresenta um resumo das ordens de trabalho abertas

ndash enviadas e recebidas ndash que se pretende permitir visualizar offline (ver Figura 46)

Como prova de conceito foi efectuada uma abordagem pragmatica das varias possi-

bilidades descritas na seccao 42

461 Modo ldquoaplicacao deciderdquo com deteccao automatica da ligacao

A primeira abordagem estudada para a disponibilizacao das funcionalidades of-

fline foi o modo ldquoaplicacao deciderdquo com deteccao automatica de ligacao apresentado

na seccao 422 Para que isto seja possıvel foi implementado um mecanismo de ver-

ificacao periodica do estado da ligacao atraves de chamadas Ajax assıncronas O

resultado destes pedidos determina o estado da aplicacao executando as tarefas de

sincronizacao de dados sempre que pertinente Este metodo embora imediato e

simples de implementar depressa se revelou inadequado para o projecto devido ao

elevado consumo de recursos do servidor que a utilizacao intensiva faz esperar a

comunidade da plataforma WOW no principal cliente excede os 7000 utilizadores

Foi estimado que para uma utilizacao de fluidez aceitavel o estado da ligacao deveria

ser testado a cada cinco segundos Assumindo uma adesao (previsao pessimista) de

1 aos servicos offline assistir-se-ia a cerca de 840 pedidos adicionais por minuto

Mas o principal problema desta aproximacao prende-se com o facto de a ver-

ificacao ser feita em intervalos de tempo discretos levando a possibilidade de a

aplicacao poder ter em dado momento uma representacao errada do seu estado

real da ligacao Este problema e ilustrado na Figura 48 onde se ve claramente a

discrepancia entre o estado real da ligacao e a representacao interna que esta tem

Note-se que nesta janela de tempo qualquer accao do utilizador que exija uma

resposta sıncrona do utilizador leva-lo-a para um ldquobeco sem saıdardquo onde nao tera

43

Desenvolvimento

Figura 46 A pagina inicial do WOW apresenta um resumo das ultimas ordens de trabalhoenviadas e recebidas Na imagem pode-se observar a transicao do estado online para offline

acesso a versao offline porque a aplicacao nao fez a transicao automatica nem acesso

a versao online porque na verdade nao possui uma ligacao O que acontecera nesta

situacao sera uma tentativa de acesso ao servidor por parte da aplicacao numa

altura em que este se encontra indisponıvel e o resultado sera uma mensagem de

ldquopedido excedeu o tempordquo apresentado pelo browser Este e um estado sem retorno

porque apos o browser apresentar esta mensagem todos os recursos JavaScript ficam

indisponıveis tornando impossıvel o regresso ao estado anterior ou o tratamento do

erro de qualquer outra forma No entanto as chamadas Ajax podem ser tratadas de

forma especial para a eventualidade de falha e portanto nao constituem problema

44

Desenvolvimento

Figura 47 Ilustracao do funcionamento do Gears numa web application que utiliza ummotor Ajax Os pedidos HTTP ou HTTPS podem ser interceptados e tratados localmenteou podem ser feitos a uma maquina remota consoante se verificarem ou nao as condicoesexpressas no ponto 311 E representado um acesso a uma base de dados local (fornecidapelo Gears) mas a sua utilizacao e opcional

462 Implementacao do modo ldquoutilizador deciderdquo

Este modo de execucao foi ja descrito na seccao 421 e a sua principal carac-

terıstica e ser o utilizador a decidir se a aplicacao deve utilizar um servidor remoto

ou a maquina local como fornecedor de dados

Relativamente ao WOW o WOW Offline na vertente ldquoutilizador deciderdquo vem

alterar os seus casos de uso dando ao utilizador a possibilidade de alterar o estado

de execucao da aplicacao (entre online e offline) Resta dizer que no modo online se

mantem todas as funcionalidades anteriores e que no modo offline torna-se possıvel

visualizar os conteudos da pagina principal do WOW (Figura 46) e os detalhes das

ordens de trabalho (Figura 49) tal como expressa a Figura 410

Esta aproximacao foi utilizada na prova de conceito do WOW adicionando um

controlo a interface desta aplicacao que permite ao utilizador alternar entre os esta-

dos online e offline Na transicao de online para offline sao descarregados os recursos

necessarios para a execucao desta aplicacao sem recorrer a Internet Para o fazer

45

Desenvolvimento

Figura 48 Neste exemplo do modo ldquoaplicacao deciderdquo o teste da ligacao e feito e feito acada cinco segundos O resultado deste teste nao reflecte sempre o estado real da aplicacaopodendo levar a aplicacao a ter comportamentos indesejaveis Na figura assinala-se umperıodo de tempo no qual a representacao interna do estado da ligacao nao corresponde arealidade

e utilizado um recurso ResourceStore e um ManagedResourceStore (introduzidos

em 311) O primeiro e utilizado para armazenar a pagina principal do WOW ndash do-

ravante designada por homejsp ndash e o segundo e utilizado para armazenar imagens

folhas de estilo CSS e scripts JavaScript

Para a implementacao deste modo de execucao foram identificadas as seguintes

tarefas

1 Guardar informacao que permita a recriacao das paginas que se pretende

disponibilizar offline (utilizando o Gears)

2 Disponibilizar um controlo que permita alterar o estado de execucao atraves

da interaccao com a pagina principal

3 Durante a sincronizacao de dados apresentar o progresso da transferencia de

dados

O primeiro passo consistiu na identificacao de todos os conteudos que sao necessarios

transferir para a execucao offline Foi utilizado um recurso do Gears do tipo

ManagedResourceStore que recorre a um ficheiro manifesto para identificar to-

dos os ficheiros que deve transferir Este recurso e gerido automaticamente pelo

Gears transferindo para o cliente a versao mais recente sempre que e necessario

isto e sempre que exista um ficheiro manifesto com uma identificacao de versao que

seja diferente da actualmente disponıvel no cliente Uma vez identificados todos

ficheiros necessarios para a execucao offline num (ou mais) ficheiros manifesto o

Gears encarrega-se da sua actualizacao mas o preenchimento destes ficheiros man-

ifesto e manual o que se traduz num cuidado extra na manutencao da aplicacao

A forma como esta informacao e guardada deve tambem ser cuidadosamente

estudada A opcao mais flexıvel passa por utilizar o modulo Database apresentado

na seccao 311 e guardar a informacao de uma forma relacional Para a recriacao

das paginas pode ser disponibilizada uma versao HTML da pagina que funciona

46

Desenvolvimento

Figura 49 Pagina de visualizacao do detalhe de uma ordem de trabalho

como template nao possui quaisquer dados e e utilizada apenas em modo offline E

preenchida para cada pedido retirando os dados relevantes da base de dados

O modelo de dados do WOW torna esta opcao extremamente trabalhosa uma

vez que as entidades envolvidas na geracao de cada pagina de informacao sobre

cada ordem de trabalho tem relacoes de dependencia complexas seguindo padroes

muito variaveis Por exemplo em cada ordem de trabalho existe um formulario que

permite a sua progressao de estado com diversos campos opcionais e obrigatorios

este formulario e definido pelo administrador e esta relacionado nao apenas com o

tipo de ordem de trabalho mas tambem com o estado actual em que esta se encontra

e a accao que se pretende realizar O elevado numero de combinacoes de tipos de

ordem de trabalho estados e accoes que existem num dado momento juntamente

com a sua possibilidade de alteracao obrigariam a implementacao de uma logica de

negocio complexa o que esta fora do ambito deste projecto

47

Desenvolvimento

Figura 410 Esquema UML que expressa os casos de uso do WOW Offline no modoldquoutilizador deciderdquo

463 Especificacao do modo ldquoaplicacao assume o estado offlinerdquo

A aproximacao para o modo ldquoaplicacao assume o estado offlinerdquo foi tambem

dividida em varias tarefas

1 Guardar informacao que permita a recriacao da pagina principal do lado do

cliente no estado offline (utilizando o Gears)

2 Dotar a aplicacao do cliente de um mecanismo de deteccao da ligacao

3 Identificar os ldquomomentos chaverdquo em que devera ocorrer sincronizacao de dados

4 Implementar a sincronizacao de dados

A sincronizacao de dados deve ser feita em ambas as transicoes online-offline e

offline-online quer para transferir novos dados do servidor (os pedidos podem ser

alterados por outros utilizadores) quando se transita do estado quer para comunicar

eventuais alteracoes feitas em modo offline

Relativamente ao WOW o WOW Offline na vertente ldquoaplicacao assume o es-

tado offlinerdquo vem alterar os seus casos de uso dando ao utilizador a possibilidade

de activar esta funcionalidade A partir do momento que a funcionalidade esta ac-

tivada o utilizador deve tambem ter a possibilidade de gerir algumas preferencias

relacionadas com privacidade de dados Devera ter a hipotese de desactivar o ar-

mazenamento local e de remover todos os dados ja armazenados tal como descrito

na Figura 411

48

Desenvolvimento

Figura 411 Esquema UML que expressa os casos de uso do WOW Offline no modoldquoutilizador deciderdquo

A primeira vez que o WOW Offline e acedido por um cliente e caso seja detec-

tada a presenca do Gears todos os recursos necessarios a sua execucao sao trans-

feridos Todos os acessos posteriores serao feitos a estes recursos locais (recorda-se

que o Gears pode ser utilizado para os manter actualizados recorrendo ao Managed-

ResourceStore 311)

Atraves do JavaScript e possıvel interceptar os eventos de load e unload da

pagina que sao despoletados sempre que ocorre um re-acesso da mesma (incluindo

a accao refresh comum dos browsers) sempre que esta e abandonada ou ainda ou

ainda se a janela for encerrada

Tal como sugerido na seccao 462 a camada de interface desta aplicacao (cada

pagina individual em HTML) devera ser implementada como sendo um template

para apresentacao de dados sendo totalmente preenchida atraves de funcoes em

JavaScript O objectivo deste ponto e criar um padrao de dados que permita ao

JavaScript preencher os dados em cada pagina (template) independentemente de

qual seja a fonte ndash o servidor remoto ou a maquina local tal como exemplificado

no diagrama da Figura 412 Na figura a aplicacao recorre ao servidor remoto para

obter os dados pretendidos quando se encontra na presenca de uma ligacao mas

para dados que exijam uma carga de processamento pelo servidor este acto pode ser

49

Desenvolvimento

Figura 412 Esquema UML que expressa o acto de recolha de dados em modo online eoffline recorrendo ao servidor (modo online) e ao sistema de armazenamento de dadoslocal fornecido pelo Gears (modo offline)

substituıdo pelo envio de um campo de controlo que se destina a aferir se os dados

locais se encontram actualizados No caso de estarem actualizados a comunicacao

com o servidor pode ser substituıda por uma query a base de dados local

50

Capıtulo 5

Resultados e Futuros

Desenvolvimentos

Todo o estudo feito sobre o tema OWA foi ja abordado ao longo do documento

Neste capıtulo apresentam-se os resultados obtidos na implementacao da prova de

conceito que visava compreender a melhor forma de disponibilizar uma versao of-

fline no WOW uma plataforma de gestao de ordens de trabalho ja existente de-

senvolvida pela Critical Software SA

51 Resultados Obtidos

Os resultados obtidos neste projecto sao extremamente satisfatorios uma vez

que o estudo do tema OWA e a implementacao de uma prova de conceito que o

ilustrasse foi conseguido com sucesso

A funcionalidade offline foi adicionada ao produto WOW da Critical Software

SA permitindo a visualizacao de ordens de trabalho e dos seus detalhes mesmo na

ausencia de uma conexao activa a Internet Embora para a solucao implementada

tenha sido utilizada uma abordagem do tipo ldquoutilizador deciderdquo pretende-se que esta

seja convertida para ldquoaplicacao deciderdquo ou mesmo para uma aproximacao hıbrida

semelhante a utilizada pelas aplicacoes estudadas nas seccoes 351 e 352

Para a sua implementacao descrita no capıtulo 4 foram tomadas decisoes de or-

dem pratica que permitissem tornar o trabalho exequıvel nos prazos dados Tentou-

se sempre que estas decisoes afectassem o mınimo em termos de desempenho e de

experiencia para o utilizador Considera-se que a implementacao do modo offline

com uma transicao entre modos do tipo ldquoutilizador deciderdquo (ver seccao 42) reflecte

o compromisso entre o desempenho pretendido e os recursos disponıveis e para alem

51

Resultados e Futuros Desenvolvimentos

de ser um exemplo eficaz das possibilidades que as OWA podem trazer a aplicacao

WOW desenvolvida pela Critical Software e tambem um estudo que pode ser uti-

lizado para analisar a implementacao desta tecnologia noutros produtos da mesma

empresa

Note-se que o principal objectivo do trabalho era ganhar familiaridade com este

tema entender as suas vantagens e desvantagens e compreender as suas limitacoes

Tudo indica que existam varias possibilidades de implementacao deste paradigma

noutros produtos da Critical Software que pela sua natureza podem tambem tirar

partido da execucao offline

52 Trabalho Futuro

O desenvolvimento do conceito e formas de implementacao de OWA continua

em forte desenvolvimento no entanto a sua adopcao ainda nao e generalizada A

dificuldade da sua implementacao em web applications ja existentes e o principal

obstaculo a sua maior divulgacao

Ha tambem um factor que deve ser tido em consideracao a manutencao de

codigo A implementacao de uma versao offline de uma web application requer

a implementacao das mesmas regras de negocio (ou de uma versao simplificada)

utilizadas no servidor Para que isto seja possıvel e necessario ter em conta a

capacidade de processamento do cliente e o factor de duplicacao de codigo que

tornara a aplicacao mais difıcil de manter uma vez que uma alteracao a logica de

negocio do servidor implica tambem uma alteracao a sua versao offline

A prova de conceito implementada permite ja a visualizacao offline dos pedidos

abertos (enviados e recebidos) que constam na pagina principal (este numero e

fixo e pode ser alterado pelo administrador) Uma funcionalidade desejavel seria a

possibilidade de interaccao com a aplicacao em modo offline e sincronizacao com o

servidor quando existisse uma ligacao disponıvel

Foi estudada a utilizacao do modo de execucao ldquoaplicacao assume o estado of-

flinerdquo descrito em 423 e esta seria a forma desejavel para o WOW Offline no

entanto para que esta opcao seja viavel sera necessaria a implementacao de uma

forma eficiente de sincronizacao e armazenamento de dados de uma forma relacional

Para atingir este objectivo podera ser seguida uma polıtica de automacao do pro-

cesso no qual a versao online da aplicacao gera scripts de criacao para as tabelas

necessarias na base de dados da versao offline (nao existe nenhuma ferramenta para

o fazer portanto seria necessaria a sua implementacao) e no qual as paginas HTML

disponibilizadas pelo servidor aos clientes web (browser) servem como templates de

apresentacao de informacao e sao preenchidas de forma semelhante pelo servidor ndash

quando a aplicacao estiver online ndash ou pelo cliente atraves de funcoes em JavaScript

52

Resultados e Futuros Desenvolvimentos

ndash quando a aplicacao estiver offline No entanto no WOW devido a quantidade de

informacao tratada e devido as complexas relacoes entre as diferentes entidades e

de esperar que a complexidade da implementacao de um mecanismo deste tipo torne

esta aproximacao demasiado custosa

O HTML 5 embora um forte candidato ainda nao esta suficientemente desen-

volvido A sua especificacao ainda tem o caracter de Draft (rascunho) e esta sujeita

a modificacoes e a aceitacao e implementacao por parte dos browsers e portanto

de momento foi desconsiderado No entanto no futuro se esta especificacao atingir

um estado de maturidade que permita a sua adopcao devera ser considerada como

um possıvel caminho a seguir

53

Resultados e Futuros Desenvolvimentos

54

Capıtulo 6

Conclusoes

Neste capıtulo sao apresentadas as conclusoes do projecto e consideracoes finais

relativamente a tecnologia estudada

61 Conclusoes

O rapido desenvolvimento tecnologico faz prever que a disponibilidade de ligacao

a Internet seja cada vez mais facil e mais rapido mas vao continuar a existir lugares

onde o acesso e limitado e onde as OWA podem desempenhar um papel de relevo

Por outro lado esta tecnologia pode tambem ser utilizada para melhorar o desem-

penho de paginas web com uma necessidade elevada de imagens ou outros recursos

dispendiosos em termos de espaco e foram ate estudados dois exemplos da utilizacao

desta vertente desta tecnologia em 353

Acredita-se que as OWAs vem responder a uma necessidade real por parte das

web applications actuais e que a evolucao que representam se compara a que se

assistiu dos thin-clients para os fat-clients em termos de autonomia do servidor

A capacidade de oferecer conteudos dinamicos no browser independentemente da

existencia de uma ligacao reune as vantagens tıpicas das web applications como

ausencia de instalacao e actualizacoes instantaneas com as vantagens das aplicacoes

de desktop em capacidade de processamento e armazenamento de dados na maquina

local

As tecnologias disponıveis ate a data estudadas no ambito deste projecto que

permitem o desenvolvimento de OWAs e que apresentam maior maturidade sao o

Gears e o Adobe AIR Ambas se apresentam sobre a forma de plugins que necessitam

de uma instalacao extra para poderem ser utilizadas Apesar de esta instalacao ser

55

Conclusoes

apenas necessaria uma vez podera constituir um factor de desencorajamento a sua

adopcao

O HTML 5 uma especificacao abordada neste documento na seccao 34 podera

ser uma alternativa que oferece funcionalidades offline a uma web application sem a

necessidade de qualquer instalacao no entanto esta especificacao ainda nao foi aceite

pelos principais browsers ndash o documento que define o HTML 5 ainda tem o estatuto

de Draft ndash e ainda nao e possıvel antecipar quando e que isto podera acontecer

Um dos problemas que surge frequentemente na implementacao de uma versao

offline para uma web application e a necessidade de sincronizacao de dados Quando

a informacao pode ser alterada por varios utilizadores simultaneamente e necessario

prever os conflitos que daı podem surgir e dotar a aplicacao de uma forma de os

resolver ou alertar o utilizador para a necessidade de alteracao dos dados

Em conclusao todos os objectivos propostos para este projecto foram atingidos

A prova de conceito implementada reflecte de forma clara as possibilidades oferecidas

pela tecnologia OWA e sera utilizado no futuro para compreender a melhor forma

de o implementar de forma definitiva no WOW

56

Referencias

[Ada08] Lucas Adamski Introducing Adobe AIR security model Fevereiro de2008 Disponıvel em httpwwwadobecomdevnetairarticles

introduction_to_air_securityhtml acedido em Marco de 2008

[Ado08] Adobe Adobe AIR 10 Security White Paper 2008 Disponıvel emhttpdownloadmacromediacompubairdocumentation1air_

securitypdf acedido em Marco de 2008

[Alm08] Dion Almaer Gears as a bleeding-edge html 5 implementa-tion March 2008 Disponıvel em httpalmaercomblog

gears-as-a-bleeding-edge-html-5-implementation acedido emMarco de 2008

[BL96] Tim Berners-Lee The world wide web Past present and future Agostode 1996 Disponıvel em httpwwww3orgPeopleBerners-Lee

1996ppfhtml acedido em Abril de 2008

[CDGH08] Mike Chambers Daniel Dura Dragos Georgita and Kevin Hoyt AdobeAIR for JavaScript Developers OrsquoReilly Media 2008 Disponıvel emhttponairadobecomfilesAIRforJSDevPocketGuidepdf ace-dido em Abril de 2008

[Con99] Jim Conallen Modeling Web Application Architectures with UML Junho1999 Disponıvel em httpwwwumlorgcnUMLApplicationpdf

webappspdf acedido em Maio de 2008

[Ent07] Entrust What is a public key information 2007 Disponıvel em http

wwwentrustcompkihtm acedido em Junho de 2008

[Gar05] Jesse James Garret Ajax A new approach to web applicationsFebruary 2005 Disponıvel em httpwwwadaptivepathcomideas

essaysarchives000385php acedido em Marco de 2008

[Greon] Philip Greenspun Philip and Alexrsquos Guide to Web Publishing 2003(last revision) Disponıvel em httpphilipgreenspuncompandaacedido em Junho de 2008

[Gro02a] App Design Group Thick vs thin client comparison 2002 Disponıvelem httpwwwdonjacobsvwcomimagesweekendspecials

Thick-vs-Thinpdf acedido em Junho de 2008

57

REFERENCIAS

[Gro02b] Technical Research Group Thin Client Tecnhology - WhitePaper 2002 Disponıvel em httpwwwpicktrgcompubs

thinclientwhitepaperpdf acedido em Junho de 2008

[Gro08] Miniwatts Marketing Group World internet usage March 2008Disponıvel em httpwwwinternetworldstatscomstatshtm ace-dido em Abril de 2008

[Hic08] Ian Hickson HTML 5 Draft Recommendation 2008 Disponıvelem httpwwwwhatwgorgspecsweb-appscurrent-work ace-dido em Marco de 2008

[Kha] Olga Kharif Top 10 municipal wifi plans Disponıvel em http

imagesbusinessweekcomss0608muni_wifiindex_01htm ace-dido em Marco de 2008

[Lab07] Mozilla Labs Prism Outubro 2007 Disponıvel em httplabs

mozillacom200710prism acedido em Marco de 2008

[Loo06] Chris Loosley Rich Internet ApplicationsDesign MeasurementandManagement Challenges 2006 Disponıvel em httpwwwkeynote

comdocswhitepapersRichInternet_5pdf acedido em Maio de2008

[Mic08] Microsoft Introduction to Occasionally Connected Applications us-ing Sync Services for ADONET 2008 Disponıvel em httpmsdn

microsoftcomen-ussyncbb887608aspx acedido em Junho de2008

[Nao08] Erica Naone Offline web applications Abril 2008 Disponıvelem httpwwwtechnologyreviewcomread_articleaspxch=

specialsectionsampsc=emerging08ampid=20245 acedido emAbril de 2008

[NJN00] Jason Nieh Yang S Jae and Naomi Novik A comparison of thin-clientcomputing architectures 2000 Disponıvel em httpwwwnclcs

columbiaedupublicationscucs-022-00pdf acedido em Maio de2008

[OrsquoR06] Tim OrsquoReilly Web 20 compact definition Trying again Dezembro2006 Disponıvel em httpradaroreillycomarchives200612

web-20-compact-definition-tryihtml acedido em Marco de 2008

[OrsquoR09] Tim OrsquoReilly What is Web 20 Design patterns and business modelsfor the Next Generation of Software 20053009 Disponıvel emhttpwwworeillynetcompubaoreillytimnews200509

30what-is-web-20html acedido em Marco de 2008

[Rus06] Alex Russel Comet Low latency data for the browser March Marco2006 Disponıvel em httpalexdojotoolkitorgp=545 acedidoem Marco de 2008

58

REFERENCIAS

[Sad97] Darleen Sadoski Clientserver software architecturesndashan overviewAgosto 1997 Disponıvel em httpwwwseicmuedustr

descriptionsclientserver_bodyhtml acedido em Junho de2008

[Sch96] George Schussel Clientserver past present and future 1996

[Smi07] Kevin C Smith Css filters - will the browser apply the rule July 2007Disponıvel em httpcentriclecomrefcssfilters acedido emMarco de 2008

[vK08] Anne van Kesteren The XMLHttpRequest Object W3C Work-ing Draft 15 Abril 2008 Disponıvel em httpwwww3orgTR

XMLHttpRequest acedido em Abril de 2008

[Wil06] Greg Wilkins Why ajax comet July Julho 2006 Disponıvel emhttpwwwwebtidecomdownloadswhitePaperWhyAjaxhtml ace-dido em Abril de 2008

59

REFERENCIAS

60

Anexo A

Screenshots

Algumas imagens de aplicacoes que utilizam funcionalidades offline ilustrativasda tecnologia abordada neste documento

Figura A1 Dialogo apresentado ao utilizador na primeira activacao das funcionalidadesoffline no Google Docs amp Spreadsheets

61

Screenshots

Figura A2 Na activacao das funcionalidades offline e tambem oferecida a possibilidadeda criacao de alguns atalhos por exemplo no ambiente de trabalho

Figura A3 O Google Docs mantem a todo o momento a possibilidade de alteracao destasdefinicoes ou da anulacao dos servicos offline para um dado computador

62

Screenshots

Figura A4 Apos a instalacao do Gears qualquer visita ao Remember The Milk despoletauma sincronizacao que ocorre automaticamente e sem necessidade de intervencao por partedo utilizador

Figura A5 Apos completar a sincronizacao de dados mesmo que a ligacao a Internetseja perdida o Remember the Milk continua disponıvel no browser (com excepcao dasfuncionalidades que pela sua natureza exigem uma ligacao como por exemplo partilhade tarefas e envio de convites)

63

Page 5: O ine Web Applications

ii

Abstract

The main purpose of this project was to study the Offline Web Applications(OWAs) and its implementation in existent web applications With this goal in minda study was conducted to use this technology in WOW an integrated platform forwork orders and work flow management developed by Critical Software over thelast 6 years and implemented a proof of concept which enables the use of a baseset of functionality for this application regardless of the internet connection state

The concept of OWAs is connected with internet technology and allows accessto a website using the browser even if a connection to the internet is not availableThis concept was considered by Technology Review as one of the most importantemerging technologies in the last quarter of 2007 [Nao08] This study conductedover the WOW platform is intended to aid in the comprehension of the problemsand solutions associated to the use and implementation of OWA as well as thebenefits that it brings to the end user

The Internet and Internet technologies are changing the way in which informa-tion is produced distributed and stored New web applications appeared with newcontent creation and edition functionalities and with it the advantage of infor-mation retrieval from any place and time became possible but with the conditionof Internet connection availability With Internet use growing every year [Gro08]content creation is starting to move to this new platform The adoption of web ap-plications for content creation and edition is becoming more popular and it showsa dependency of a connection that is not always present

The OWAs are a way to solve this problem putting on the client side part ofthe information that was traditionally stored on the server and allows it to be seenand manipulated and helps reducing the server load

This document intends to present different ways in which this technology canhelp web applications as we know them improving the their overall performance andgiving them the ability to run on a browser regardless of the Internet connectionavailability

iii

iv

Agradecimentos

A realizacao e os objectivos alcancados neste projecto nao teriam sido possıveissem a colaboracao de inumeras pessoas Agradeco profundamente a todos os quecontribuıram directa ou indirectamente para o seu sucesso

A minha orientadora Professora Teresa Galvao Dias e ao Project ManagerEngenheiro Marcus Neves que me conduziram e acompanharam no desenvolvimentodeste projecto

A toda a equipa do WOW em especial o Pedro Maurıcio Costa e o Fabio Matosque contribuıram para a minha a minha integracao na Critical Software e que sempresouberam responder a todas as minhas questoes

A todos os que constituem a CSW Porto pelo fantastico ambiente de amizadeque me proporcionaram

Aos colegas de curso e a todos os que me auxiliaram na revisao deste documento

Os meus sinceros agradecimentos

Joao Goncalves da Costa

v

vi

Conteudo

1 Introducao 111 Enquadramento 112 Motivacao 213 Ambito 314 Objectivos 315 Estrutura do documento 3

2 Enquadramento do Projecto 521 Evolucao das arquitecturas de software 5

211 Thin-clients 5212 Fat-clients 6213 Arquitecturas cliente-servidor 7

22 Evolucao na Internet 8221 Paginas web estaticas 9222 Paginas web interactivas e paginas web dinamicas 9223 Web 20 e Ajax 11

23 Offline Web Applications 1324 Comparacao 13

3 Estado da arte 1731 Gears 17

311 Arquitectura 17312 Goggle Gears em dispositivos moveis 20

32 Adobe AIR 20321 Seguranca 22322 Assinatura do codigo 22

33 Mozilla Prism 23331 XML User Interface Language 23332 Prism 25

34 HTML 5 2535 Web applications que usam funcionalidades offline 26

351 Google Reader e Google Docs 26352 Remember the Milk 27353 MySpace e WordPresscom 27

36 Escolha da tecnologia 28

vii

CONTEUDO

4 Desenvolvimento 3341 Como ficar offline 33

411 Funcionalidades disponıveis em modo offline 3442 Modos de execucao 35

421 Modo ldquoutilizador deciderdquo 36422 Modo aplicacao decide 36423 Modo ldquoaplicacao assume o estado offlinerdquo 37

43 Sincronizacao de dados 38431 Quando sincronizar 39

44 WOW 4045 Visao geral sobre a arquitectura do WOW 4146 WOW Offline 42

461 Modo ldquoaplicacao deciderdquo com deteccao automatica da ligacao 43462 Implementacao do modo ldquoutilizador deciderdquo 45463 Especificacao do modo ldquoaplicacao assume o estado offlinerdquo 48

5 Resultados e Futuros Desenvolvimentos 5151 Resultados Obtidos 5152 Trabalho Futuro 52

6 Conclusoes 5561 Conclusoes 55

Referencias 59

A Screenshots 61

viii

Lista de Figuras

21 Arquitectura de um sistema thin-client em duas camadas (a esquerda)e em tres camadas (a direita) Note-se a inclusao do servidor (main-frame) na definicao das camadas desta arquitectura devido a fortedependencia cliente-servidor 9

22 Arquitectura de um fat-client em duas camadas (a esquerda) e emtres camadas (a direita) 10

23 Comparacao do modelo de web aplications sıncrono paginas estaticase interactivas abordados nas seccoes 221 e 222 com o modelo deweb applications Ajax (assıncrono) abordado na seccao 223 Figuraadaptada de http www adaptivepath com 15

31 Esquema UML do processo efectuado pelos recursos do Gears do tipoManagedResourceStore para a actualizacao dos conteudos definidosno ficheiro manifesto 29

41 Exemplo de uma arquitectura de uma web application sem uma ca-mada de abstraccao de dados Figura adaptada de http gears

google com 33

42 Exemplo de uma arquitectura de uma web application com uma ca-mada de abstraccao de dados Figura adaptada de http gears

google com 34

43 Exemplo de uma arquitectura de uma web application com uma ca-mada de abstraccao de dados e um data switch Figura adaptada dehttp gears google com 35

44 Esquema grafico ilustrando uma OWA executando no browser uti-lizando um modo de execucao do tipo ldquoaplicacao deciderdquo com de-teccao automatica do estado da ligacao via pedidos Ajax assıncronosa cada cinco segundos 37

45 Detalhe de um conjunto possıvel de estados e respectivas transicoespara uma dada ordem de trabalho no WOW desde a sua submissaono sistema ate a sua conclusao em fecho ou cancelamento Esta figurarepresenta apenas um exemplo ja que o mapa de estados para umaordem de trabalho e dinamico e pode ser alterado por um admin-istrador Figura retirada de uma brochura promocional do WOWCritical Software SA 41

ix

LISTA DE FIGURAS

46 A pagina inicial do WOW apresenta um resumo das ultimas ordensde trabalho enviadas e recebidas Na imagem pode-se observar atransicao do estado online para offline 44

47 Ilustracao do funcionamento do Gears numa web application que uti-liza um motor Ajax Os pedidos HTTP ou HTTPS podem ser inter-ceptados e tratados localmente ou podem ser feitos a uma maquinaremota consoante se verificarem ou nao as condicoes expressas noponto 311 E representado um acesso a uma base de dados local(fornecida pelo Gears) mas a sua utilizacao e opcional 45

48 Neste exemplo do modo ldquoaplicacao deciderdquo o teste da ligacao e feitoe feito a cada cinco segundos O resultado deste teste nao reflectesempre o estado real da aplicacao podendo levar a aplicacao a tercomportamentos indesejaveis Na figura assinala-se um perıodo detempo no qual a representacao interna do estado da ligacao nao cor-responde a realidade 46

49 Pagina de visualizacao do detalhe de uma ordem de trabalho 47410 Esquema UML que expressa os casos de uso do WOW Offline no

modo ldquoutilizador deciderdquo 48411 Esquema UML que expressa os casos de uso do WOW Offline no

modo ldquoutilizador deciderdquo 49412 Esquema UML que expressa o acto de recolha de dados em modo

online e offline recorrendo ao servidor (modo online) e ao sistemade armazenamento de dados local fornecido pelo Gears (modo offline) 50

A1 Dialogo apresentado ao utilizador na primeira activacao das funcional-idades offline no Google Docs amp Spreadsheets 61

A2 Na activacao das funcionalidades offline e tambem oferecida a possi-bilidade da criacao de alguns atalhos por exemplo no ambiente detrabalho 62

A3 O Google Docs mantem a todo o momento a possibilidade de alteracaodestas definicoes ou da anulacao dos servicos offline para um dadocomputador 62

A4 Apos a instalacao do Gears qualquer visita ao Remember The Milkdespoleta uma sincronizacao que ocorre automaticamente e sem ne-cessidade de intervencao por parte do utilizador 63

A5 Apos completar a sincronizacao de dados mesmo que a ligacao aInternet seja perdida o Remember the Milk continua disponıvel nobrowser (com excepcao das funcionalidades que pela sua naturezaexigem uma ligacao como por exemplo partilha de tarefas e enviode convites) 63

x

Lista de Tabelas

21 Comparacao entre thin-clients e fat-clients 7

31 Comparacao das funcionalidades oferecidas pelo Adobe AIR para asplataformas web e desktop 30

32 Resumo da utilizacao de tecnologias OWA em algumas web applica-tions consideradas na analise do estado da arte 31

xi

LISTA DE TABELAS

xii

Glossario

fat-client Cliente que nao depende totalmente de umservidor central para as suas actividadesde processamento e possui frequentementedispositivos de armazenamento de dados

6ndash8

thin-client Cliente que depende de um servidor centralpara as suas actividades de processamento

5ndash8

web application Sistema web (servidor rede HTTPbrowser) onde accoes do utilizador(navegacao e introducao de informacao)afectam o estado logico da aplicacao

i iii1ndash311ndash1517ndash1921ndash232728 3336ndash3842 5556

API Application Programming Interface 10 1718 2326 28

ASP Linguagem interpretada pelo servidorque permite a criacao de paginas webdinamicas Desenvolvida pela Microsoft

11

BSD Berkeley Software Distribution 28

CSS Cascading Style Sheets 12 2021 2324 46

DHTML Dynamic HyperText Transfer Protocol 24DOM Document Object Model 10 12

20 2324

DTD Document Type Definition 24

xiii

Glossario

ECMAScript Padrao de linguagem de programacaodefinido pela Ecma International que orig-inou o JavaScript e o JScript

24

Flash Conteudo interactivo de um ficheiro emformato SWF E desenvolvido pela Adobee visualizado atraves do Adobe FlashPlayer

21

Flex Framework baseada em XML e Action-Script desenvolvida pela Adobe para a pro-gramacao de Rich Internet Applications(RIA)

21

GPL GNU General Public License 23

HTML HyperText Markup Language 1 10ndash12 2124ndash2649

HTTP HyperText Transfer Protocol 2 26

JMS E uma API em Java que permite a troca demensagens entre componentes de software

42

JSON JavaScript Object Notation permite atroca de dados codificados num formatode texto de simples leitura

12 1828 34

LGPL GNU Lesser General Public License 23

Mozilla Prism Browser simplificado e ldquointerpretadorrdquo deeXtensible User Interface Language (XUL)(tambem designado por XULRunner) queacolhe web applications sem a interfacegrafica habitual de um browser

25

MPL Mozilla Public License 23

OCA Occasionally Connected Application 39OWA Offline Web Application i iii

2ndash515 1725 2628 3133 3651 5255 56

PDF Portable Document Format 21

xiv

Glossario

PHP Linguagem interpretada pelo servidorque permite a criacao de paginas webdinamicas mas que pode tambem ser in-vocada a partir da linha de comandos

11

pagina web estatica Pagina web que devolve sempre a mesmaresposta a todos os pedidos para todos osutilizadores e em qualquer contexto

5 9

RIA Rich Internet Applications web appli-cations que apresentam funcionalidadessemelhantes as desktop applications masque mantem a informacao no lado do servi-dor

5 1520 28

RSS Really Simple Syndication 27

SLA Service Level Agreement 40SQLite Segundo a definicao oficial SQLite is a

software library that implements a self-contained serverless zero-configurationtransactional SQL database engine

17

SSB Site Specific Browser 25SSL Secure Sockets Layer 22SWF ShockWave Flash 21

URL Uniform Resource Locator 18

VPN Virtual Private Network 38

WOW Work Orders Web Plataforma de gestaode ordens de trabalho e do seu fluxo de-senvolvida pela Critical Software SA

i iii28 3340ndash434551ndash5356

WWW World Wide Web 11 1214

XBL eXtensible Binding Language 24XHTML eXtensible HyperText Markup Language 12XML eXtensible Markup Language 11 12

23 2428

XSLT eXtensible Stylesheet Language Transfor-mation

12

XUL eXtensible User Interface Language xiv23ndash25

xv

Glossario

xvi

Capıtulo 1

Introducao

Neste capıtulo enquadra-se o tema do projecto introduzindo alguns dos conceitos

nos quais se baseia Apresentam-se as motivacoes ambito objectivos e a estrutura

deste documento

11 Enquadramento

A Internet foi originalmente concebida para ser um espaco de partilha de in-

formacao onde pessoas (atraves de maquinas) pudessem comunicar Na sua origem

as paginas eram estaticas constituıdas por texto formatado em HyperText Markup

Language (HTML) e ligadas entre si [BL96] Hoje encontramos conteudos cada vez

mais complexos e dinamicos incluindo som vıdeo ou streams multimedia [Loo06] e

em 2005 foi introduzido por [OrsquoR09] o termo Web 20

De acordo com [Greon] um website pode pertencer a uma ou varias das seguintes

categorias

bull Documento ndash um website essencialmente estatico onde alteracoes a uma

parte do conteudo nao tem implicacoes no seu comportamento

bull Base de dados ndash um directorio de informacao organizada em categorias

bull Aplicacao ndash um website dinamico que utiliza uma linguagem executada ou

interpretada do lado do servidor e que processa as accoes ou informacao in-

troduzida pelo utilizador para fornecer um servico ou nova informacao

A ultima destas categorias constitui aquilo que e normalmente designado por

web application O conceito utilizado ao longo deste documento e o mesmo que

o introduzido por Jim Coallen em [Con99] que define web application como um

1

Introducao

sistema web (servidor rede HyperText Transfer Protocol (HTTP) browser) onde

accoes do utilizador (navegacao e introducao de informacao) afectam o estado logico

da aplicacao A sua definicao tenta estabelecer que uma web application e um

sistema de software com estado de negocio1 e que a sua interface de interaccao com

o utilizador e distribuıdo atraves de um sistema web

12 Motivacao

A quantidade de informacao que e produzida e armazenada com recurso a es-

tas web applications disponıveis online tais como e-mail blogues ou mesmo docu-

mentacao tornam por vezes a disponibilidade de ligacao uma condicao necessaria

a produtividade e como consequencia desta barreira muitos potenciais utilizadores

opoem-se a adopcao de produtos web em detrimento das tradicionais desktop appli-

cations

Assegurar o acesso a uma ligacao de Internet e hoje muito mais facil A Internet

movel e ja uma realidade e encontra-se amplamente divulgada mas continuam a

existir diversas situacoes nas quais os utilizadores estao privados de uma ligacao

a Internet tais como uma viagem de metro ou de aviao ou quando se encontram

deslocados do seu paıs de origem e nao possuem nenhum plano de subscricao

Uma OWA consiste numa web application que para alem de manter todas as

caracterısticas anteriores se mantem disponıvel mesmo na ausencia de uma ligacao

a Internet e surge como uma tentativa de estreitar as barreiras existentes entre a

web e o desktop Isto significa que devera existir um mecanismo capaz de assegurar

a manutencao do estado logico da aplicacao quando a ligacao com o servidor e

quebrada permitindo ao utilizador continuar a utilizar a aplicacao e que sera capaz

de informar o servidor do estado em que a aplicacao se encontra quando a ligacao for

reposta A principal vantagem que advem desta possibilidade e evidente eliminar

a necessidade da existencia de uma ligacao a Internet para que a aplicacao possa ser

utilizada

Por outro lado a vontade de integracao de funcionalidades tıpicas das desktop

applications nas web applications foi um dos principais factores que impulsionou o

desenvolvimento deste conceito uma vez que obrigou a uma reflexao ldquopara alem

do browserrdquo e a uma adaptacao das arquitecturas existentes que permitisse ou o

acesso a funcionalidades disponibilizadas pelo sistema operativo ou pelo menos a

funcionalidades semelhantes Pretende-se com esta aproximacao tornar possıveis

interaccoes entre o desktop e o browser tais como arrastar um ficheiro para um

formulario web de upload de conteudos melhor suporte para o historico do clipboard

ou ainda o acesso ao sistema de ficheiros local Atingir estes objectivos reflecte-se

1NT business state

2

Introducao

num novo paradigma que reune as vantagens das web applications tais como os

updates instantaneos ou o facto de nao ser necessaria nenhuma instalacao e das

desktop applications como por exemplo persistencia no armazenamento de dados

acesso a funcionalidades do sistema operativo ou integracao e interaccao com outras

aplicacoes sejam elas web applications ou desktop applications

13 Ambito

Este projecto foi realizado na Critical Software SA no ambito do Mestrado

Integrado em Engenharia Informatica e Computacao (MIEIC) da Faculdade de En-

genharia da Universidade do Porto (FEUP) entre os meses de Fevereiro e Julho de

2008

14 Objectivos

Sao objectivos deste projecto

1 Estudar e documentar o tema das OWAs acompanhando os ultimos desenvolvi-

mentos nesta materia

2 Analisar o estado da arte fazendo uma analise crıtica e objectiva sobre as

diversas metodologias existentes

3 Implementar uma prova de conceito que permita a execucao offline de uma

web application documentando todo o processo

4 Estudar a possibilidade de permitir interaccao com a aplicacao (insercoes e

alteracoes aos dados) em modo offline

Em resumo o objectivo deste projecto foi estudar documentar e implementar

uma prova de conceito relacionada com o tema Offline Web Applications (OWA)

Este tema embora nao seja totalmente novo ganhou destaque ao longo do ano de

2007 com o surgimento de diversas ferramentas que se destinam a aproximar web

applications das desktop applications

15 Estrutura do documento

Este documento esta organizado em diferentes seccoes apresentando o projecto

numa sequencia logica organizada da seguinte forma

No capıtulo 1 faz-se uma breve apresentacao do conceito OWAs e do contexto em

que surge Apresenta-se tambem a estrutura do documento e definem-se os

termos e acronimos utilizados

3

Introducao

No capıtulo 2 faz-se uma descricao da evolucao das tecnologias que antecedem as

OWAs e das vantagens e desvantagens de cada uma como forma de enquadra-

mento

No capıtulo 3 analisa-se o estado da arte nesta materia Introduzem-se diversas

tecnologias directamente relacionadas com o tema deste projecto exemplos de

aplicacoes que as usam e as razoes que fundamentam as escolhas de tecnologias

efectuadas

O capıtulo 4 contem o desenvolvimento do projecto Analisa-se a plataforma

WOW de gestao integrada de ordens de trabalho a tecnologia escolhida e

a forma como foi utilizada para implementar a capacidade de execucao offline

O capıtulo 5 descreve os resultado obtidos comparando-os com as expectativas

iniciais do projecto e apresenta desenvolvimentos futuros e possibilidades de

continuacaoaplicacao do conhecimento adquirido

No capıtulo 6 apresentam-se as conclusoes

4

Capıtulo 2

Enquadramento do Projecto

Neste capıtulo apresenta-se um breve resumo da evolucao das arquitecturas de

software cliente-servidor e a forma como estas se comparam a evolucao da Inter-

net procurando estabelecer uma analogia entre o percurso de ambas as tecnolo-

gias Compara-se o comportamento e arquitectura dos thin-clients as paginas web

estaticas a evolucao dos fat-clients as paginas interactivas Web 20 e Ajax e

defende-se que as OWA constituem um proximo passo logico e evolutivo aproxi-

mando a web do desktop Referem-se ainda os principais factores que justificam a

importancia das OWAs e a estreita relacao que tem com as Rich Internet Application

(RIA)s

21 Evolucao das arquitecturas de software

Os termos thin-client e fat-client sao utilizados quer para descrever arquitecturas

logicas (de software) quer para descrever arquitecturas fısicas (de hardware) Neste

capıtulo excepto quando seja dada indicacao em contrario estes termos referem-se

sempre a uma arquitectura logica

Adicionalmente quando se trata de arquitecturas cliente-servidor pode-se estu-

dar a arquitectura desenvolvida do sistema como um todo da arquitectura do servi-

dor ou da arquitectura do cliente Para evitar equıvocos em especial na seccao 213

especifica-se em cada caso qual o sistema estudado

211 Thin-clients

Um thin-client e um computador cliente ou software cliente que no contexto

de uma arquitectura cliente-servidor depende de um servidor central para as suas

5

Enquadramento do Projecto

actividades de processamento e proporciona um canal de entrada e saıda de in-

formacao entre o utilizador e o servidor remoto Este termo quando aplicado a

hardware refere-se habitualmente a um computador que se destina a ser utilizado

como cliente de rede sem armazenamento local e com capacidade de processamento

reduzida [Gro02b] mas o conceito que aqui se analisa refere-se a uma arquitectura

de software que remonta ao inıcio das aplicacoes cliente-servidor

No inıcio da historia da computacao terminais ligavam-se directamente a main-

frames responsaveis por todo o processamento Nesta arquitectura era necessario

desenvolver duas aplicacoes distintas uma aplicacao central no servidor (main-

frame) responsavel pela gestao de toda a informacao e por todas as operacoes de

comunicacao e uma aplicacao de visualizacao instalada no cliente (terminal) O

papel destes terminais era apenas disponibilizar ao utilizador um meio de comu-

nicacao (entrada e saıda) e apresentacao dos resultados do servidor Nao tinham

um papel activo no calculo nem na logica de negocio e frequentemente nao tinham

tambem nenhum mecanismo de armazenamento de dados

Como vantagens esta arquitectura apresenta uma reduzida necessidade de con-

figuracao e manutencao do lado do cliente Uma vez que o centro do processamento

e manipulacao de dados ocorre no servidor existe tambem uma centralizacao da

informacao [NJN00] que introduz um ponto crıtico de falha1 Actualizacoes e novas

funcionalidades sao faceis de distribuir uma vez que requerem apenas alteracoes no

servidor [Gro02a]

212 Fat-clients

Contrastando com os thin-clients nesta arquitectura os clientes implementam

ja uma parte da logica de negocio e sao responsaveis pelo processamento de dados

Estes fat-clients vieram responder a necessidade crescente de aplicacoes com um

nıvel de interactividade e capacidade de configuracao maior que as oferecidas pela

arquitectura thin-client descrita na seccao 211 Apesar de manterem a sua de-

pendencia do servidor podem tambem ser executados sem uma conexao activa uma

vez que dispoe de armazenamento de dados local o que lhes confere a capacidade

de persistencia de dados e do estado de execucao entre cada sessao

Foi disponibilizando este controlo sobre o estado da aplicacao bem como acesso

a recursos locais (por exemplo sistema de ficheiros e perifericos) que surgiram as

primeiras verdadeiras desktop applications No entanto cada cliente tinha que ser

separadamente instalado no computador pessoal de cada utilizador que pretendesse

utilizar ou interagir com a aplicacao e uma actualizacao ao servidor implicava in-

variavelmente uma actualizacao manual tambem no cliente Uma vez que nem todos

1NT single point of failure

6

Enquadramento do Projecto

Thin-clients Fat-clientsNao toma parte no processamento dedados nem possui acesso ao sistema deficheiros

Participa activamente no processa-mento de dados recorrendo ao sis-tema de armazenamento local para ar-mazenamento de dados

Nao mantem registo do estado logicoda aplicacao entre duas sessoes de uti-lizacao

O acesso ao armazenamento localpermite-lhe manter registo do estadologico da aplicacao entre duas sessoes

O thin-client nao necessita de qualquerinstalacao estando ldquopronto a utilizarrdquo

E geralmente necessario instalar aaplicacao para poder interagir com oservidor

Qualquer update no servidor reflecte-seimediatamente por todos os clientes

Embora a aplicacao cliente possa aler-tar para existencia de novas versoes asactualizacoes tem que ser manualmenteinstalados pelo cliente

O software do cliente destina-se apenasa apresentacao de dados e comunicacaocom o servidor sendo portanto de sim-ples implementacao

Como o software do cliente toma parteactiva no processamento de dadosa sua implementacao requer cuidadosadicionais

Grande mobilidade uma vez que todaa informacao e mantida no servidor

Parte da informacao podera estar ape-nas do lado cliente pelo que existemalgumas restricoes a sua mobilidade

Tabela 21 Comparacao entre thin-clients e fat-clients

os utilizadores actualizam regularmente as suas aplicacoes o servidor tem que estar

preparado para lidar com versoes antigas2 ou descontinuar os seus servicos a uma

parte da sua comunidade de utilizadores ate que estes actualizem os seus sistemas

Como os utilizadores passam a utilizar os seus recursos locais para armazenamento

de dados as alteracoes que nao sejam sincronizadas com o servidor estao apenas

disponıveis nos seus computadores pessoais o que introduz uma restricao a mobili-

dade

Pode-se afirmar que as vantagens dos thin-clients sao as desvantagens dos fat-

clients e que as vantagens dos fat-clients sao as vantagens dos thin-clients tal como

se ilustra na Tabela 21

213 Arquitecturas cliente-servidor

Introduzidos os termos thin-client e fat-client interessa reafirmar que ambos

podem ser vistos como arquitecturas cliente-servidor Um cliente define-se como

um solicitador de servicos e um servidor como um prestador de servicos tal como

definido por [Sch96] e [Sad97]

2NT backward compatibility

7

Enquadramento do Projecto

As arquitecturas cliente-servidor sao categorizadas pela modularizacao com que

sao desenhadas sendo consideradas as seguintes camadas

1 Interface grafica (front-end) atraves da qual os utilizadores interagem com

a aplicacao Quando este modulo e implementado separadamente dos outros

dois constitui uma aplicacao thin-client por si so uma vez que nao implementa

regras de negocio (embora possa definir validacoes de formularios de insercao de

dados por exemplo) A informacao introduzida pelo utilizador e enviada para

o servidor que processa o seu pedido e retorna uma resposta Este processo

repete-se ate que o utilizador atinja o seu objectivo ou se desligue do sistema

2 A logica de negocio tambem designada por camada intermedia que imple-

menta as regras de aceitacao e validacao de todos os dados introduzidos pelo

utilizador E tambem a plataforma de comunicacao que une a camada superior

de visualizacao com a camada de acesso a dados

3 A camada de dados inclui quer o sistema de persistencia de dados onde sao

armazenados os dados relevantes como tambem os mecanismos necessarios

para a sua pesquisa seleccao e alteracao

Os thin-clients quando observados no seu conjunto de cliente e servidor podem

ser vistos quer como sistemas de duas camadas quer como sistemas de tres camadas

dependendo apenas da forma como o servidor for implementado No caso de na

implementacao do servidor nao se distinguir a camada de acesso a dados da camada

da logica de negocio sao designados por sistemas de duas camadas Caso seja feita

esta distincao sao designados por sistemas de tres camadas Ambos os casos sao

ilustrados na Figura 21

Historicamente os fat-clients eram implementados numa arquitectura em duas

camadas Possuıam apenas um modulo de visualizacao de dados designado por

camada de interface e um modulo que implementava toda a logica de negocio e

regras de acesso a base de dados No entanto com a introducao de ligacoes mais

rapidas e de computadores pessoais com maior capacidade de processamento e so-

bretudo devido a complexidade crescente das aplicacoes a logica de negocio e a

camada de acesso a dados tornaram-se independentes Este modelo e designado por

arquitectura em tres camadas e e ilustrado na Figura 22

22 Evolucao na Internet

Ao analisar a evolucao das arquitecturas das aplicacoes desenvolvidas para a

Internet podemos encontrar um paralelismo com a historia da arquitectura de soft-

ware

8

Enquadramento do Projecto

Figura 21 Arquitectura de um sistema thin-client em duas camadas (a esquerda) e emtres camadas (a direita) Note-se a inclusao do servidor (mainframe) na definicao dascamadas desta arquitectura devido a forte dependencia cliente-servidor

221 Paginas web estaticas

Uma pagina web estatica devolve sempre a mesma resposta a todos os pedidos

para todos os utilizadores e em qualquer contexto utilizando o hipertexto como

forma de ligacao entre diversas paginas estaticas

A informacao e armazenada num servidor e o papel do cliente e apenas a apre-

sentacao da informacao Esta forma de disponibilizacao de informacao pode assim

ser comparada com os thin-clients descritos na seccao 211 o utilizador acede a

um website estatico para visualizar informacao sem que o cliente tome parte no

processamento A unica diferenca e que no caso da web estatica a informacao ap-

resentada e sempre a mesma enquanto que nos thin-clients era frequente existir a

possibilidade de insercao de dados no cliente e apos o seu processamento servidor

nova informacao poderia ser apresentada O hipertexto e utilizado para ligar as

paginas entre si numa rede de conteudos relacionados e a navegacao sıncrona era

feita atraves de cliques do rato a cada clique uma nova pagina era apresentada

Este modelo sıncrono e ilustrado na Figura 23

222 Paginas web interactivas e paginas web dinamicas

O JavaScript e uma linguagem interpretada de scripting que tem os browsers

como principal ambiente de acolhimento Os browsers utilizam uma Application

9

Enquadramento do Projecto

Figura 22 Arquitectura de um fat-client em duas camadas (a esquerda) e em tres camadas(a direita)

Programming Interface (API) publica para criar ldquoobjectosrdquo responsaveis por reflectir

e disponibilizar o Document Object Model (DOM) para o motor de JavaScript

A utilizacao mais frequente desta linguagem e a escrita de funcoes que sao em-

bebidas ou incluıdas em paginas web e que interagem com o DOM Uma vez que o

JavaScript e executado localmente (na maquina do cliente e nao no servidor) e capaz

de responder rapidamente a accoes do utilizador tornando a execucao de aplicacoes

no browser mais fluıdas o JavaScript pode tambem detectar accoes do utilizador

que o HTML nao pode tal como o pressionar de uma tecla

Em Dezembro de 1995 a Netscape Communications adicionou suporte para o

JavaScript no browser Netscape Navigator3 e em Agosto de 1996 o browser Internet

Explorer4 da Microsoft passou a tambem a suportar uma versao semelhante desta

linguagem (hoje todos os principais browsers suportam esta tecnologia)

Esta inovacao permitiu tornar os websites mais interactivos mas a sua utilizacao

esteve confinada apenas a este proposito durante um longo perıodo As paginas

passaram a responder activamente a accoes do utilizador (sendo uma das utilizacoes

3Netscape Communications ndash httpbrowsernetscapecom4Microsoft Internet Explorer ndash httpwwwmicrosoftcomwindowsproductswinfamilyie

10

Enquadramento do Projecto

mais vulgares a validacao de formularios) mas continuaram essencialmente estaticas

O JavaScript ainda nao era nesta altura utilizado para processar dados

Tambem nesta altura (1995ndash96) surgiram linguagens server-side como o PHP

Hypertext Preprocessor (PHP) e Active Server Pages (ASP) e o servidor passou a ter

um processamento de dados introduzidos pelo utilizador mais activo Generalizaram-

se as paginas dinamicas capazes de responder a insercao de dados ou outros pedidos

determinados por accoes do utilizador As paginas tornaram-se aplicacoes web ap-

plications

Uma definicao tradicional de web application e um conjunto de paginas web

logicamente agrupadas e geridas por uma unica entidade que tem como pontos de

entrada formularios de insercao de dados (web forms) Uma web application nao e

mais do que uma aplicacao que e acedida atraves de um browser Tem geralmente

uma arquitectura logica em tres (interface logica de negocio e camada de dados)

camadas e estao armazenadas num servidor

Ha dois tipos de web applications

bull Orientadas a apresentacao Sao web applications que geram paginas web in-

teractivas constituıdas por varios tipos de linguagens de anotacao (por exem-

plo HTML eXtensible Markup Language (XML)) e que apresentam conteudo

dinamico como resposta a pedidos efectuados pelo utilizador

bull Orientadas aos servicos Uma web application orientada aos servicos imple-

menta o ponto de acesso para um ou mais de um web service Sao geralmente

clientes de service oriented web applications

Uma vantagem significativa de implementar uma web application de forma a

suportar as funcionalidades padrao dos browsers e que estas terao o mesmo com-

portamento independentemente da plataforma e do browser a partir do qual serao

acedidas No entanto diferentes implementacoes de browsers devido a diferentes

interpretacoes dos padroes definidos tornam por vezes esta tarefa um pouco mais

complicada existindo inclusivamente na web guioes de compatibilidade para os difer-

entes browsers como [Smi07]

223 Web 20 e Ajax

O termo web 20 descreve uma tendencia de utilizacao e de design observada

na World Wide Web (WWW) com o objectivo de melhorar a criatividade partilha

de informacao e principalmente a colaboracao entre utilizadores Estes conceitos

levaram ao desenvolvimento e evolucao de comunidades online tais como redes so-

ciais wikis e blogues

11

Enquadramento do Projecto

O termo tornou-se mais conhecido apos a primeira conferencia OrsquoReilly Media

Web 20 em 2004 e apesar de sugerir uma nova versao da WWW nao se refere a

qualquer evolucao tecnologica mas apenas a alteracoes a forma como os utilizadores

se servem da web De acordo com Tim OrsquoReilly [OrsquoR06] ldquoWeb 20 e uma revolucao

na industria do software causada pela adopcao da web como uma plataforma e pela

tentativa de entendimento das regras para o sucesso nesta nova plataformardquo

O desenvolvimento da Web 20 serve-se muitas vezes de um outro conceito Ajax

O conceito que hoje conhecemos como Ajax muitas vezes incorrectamente de-

scrito como uma tecnologia foi originalmente criado para permitir o desenvolvimento

de web applications que se assemelhassem ainda mais a aplicacoes de desktop Este

conceito foi melhor descrito por [Gar05] como um conjunto de varias tecnologias

que podem ser utilizadas para melhorar a experiencia do utilizador de uma dada

web application introduzindo a capacidade assıncrona de envio de pedidos ou da

recepcao assıncrona de respostas As tecnologias mais frequentemente envolvidas

sao

bull eXtensible HyperText Markup Language (XHTML) e Cascading Style Sheets

(CSS) padrao para a apresentacao

bull interaccao dinamica atraves do DOM

bull troca e manipulacao de dados utilizando XML e eXtensible Stylesheet Lan-

guage Transformation (XSLT) ou JavaScript Object Notation (JSON)

bull pedidos assıncronos utilizando XMLHttpRequest [vK08]

bull JavaScript utilizado para integrar todas estas tecnologias

E importante frisar que o Ajax nao e um produto nem uma tecnologia E um

termo que descreve a utilizacao de um conjunto de tecnologias para o desenvolvi-

mento de web applications com um elevado grau de interactividade Comparativa-

mente as web applications tradicionais o Ajax introduz uma camada de visualizacao

diferente em tres importantes pontos

1 Do lado do cliente existe um motor que serve de intermediario entre a interface

da aplicacao e o servidor

2 A actividade do utilizador despoleta chamadas JavaScript em vez de um pedido

de pagina directamente ao servidor

3 Informacao codificada em XML em vez de paginas HTML e trocada entre o

servidor e o cliente

12

Enquadramento do Projecto

Isto significa que as paginas que utilizam Ajax contem um motor do lado do

cliente composto por um conjunto de funcoes JavaScript responsavel pela comu-

nicacao com o servidor e por actualizar a interface com o resultado dessa mesma

comunicacao

Na Figura 23 ilustra-se a natureza assıncrona do Ajax quando comparada com

as web applications tradicionais Como se pode observar adicionando um mecan-

ismo Ajax a uma web application eliminam-se diversos tempos de espera associados

a comunicacoes com o servidor uma vez que a interface nao fica ldquobloqueadardquo a es-

pera da resposta Obtem-se assim aplicacoes com um comportamento mais fluido

eliminando tempos de espera entre cada ldquocliquerdquo e melhorando a experiencia do

utilizador

23 Offline Web Applications

A informacao grafica (bem como folhas de estilo e scripts) tais como as ima-

gens que constituem o visual de uma web application e ja tratada de forma especial

pelos cada vez mais avancados sistemas de cache (armazenamento temporario) dos

browsers Mas estes nao sao ainda capazes de guardar conteudo criado pelo uti-

lizador nem de apresentar informacao independentemente do estado da ligacao

Numa altura onde se fala de servicos de Internet wireless municipalizados [Kha]

comunicacoes 3G e ligacoes de banda larga a alta velocidade a ligacao a rede global

continua a nao estar permanentemente disponıvel para os utilizadores Na WWW

encontra-se uma importante parte da informacao e das aplicacoes utilizadas para

criar e editar conteudos Por vezes informacao vital para a produtividade pode

desaparecer subitamente do mapa de acesso de um utilizador quando este entra no

metro num aviao ou mesmo quando se desloca para uma cidade ou paıs diferente

do habitual onde nao subscreve um plano de acesso que lhe garanta a ligacao

Permitir o acesso offline a estes recursos assume assim a sua importancia porque

permitira estender o alcance da informacao a locais onde nunca esteve antes e per-

mitira tambem melhorar o desempenho das web applications colocando informacao

mais perto dos utilizadores reduzindo a transferencia de dados apenas ao essencial

24 Comparacao

Nas evolucoes descritas neste capıtulo 2 pode-se observar que existe um par-

alelismo entre a evolucao das arquitecturas tradicionais cliente-servidor e a evolucao

a que se assiste na web O comportamento e arquitectura dos thin-clients assemelha-

se ao das paginas estaticas no sentido em que o browser nao toma parte em qualquer

13

Enquadramento do Projecto

processamento e serve apenas como uma plataforma de interaccao com o servidor

tal como os clientes descritos na seccao 211

A sua proxima evolucao os fat-clients trouxeram parte da capacidade de pro-

cessamento para o lado do cliente Na web foi tambem esta a inovacao tecnologica

a que se assistiu com a evolucao das tecnologias que permitiram a criacao de ver-

dadeiras aplicacoes e com a introducao do Javascript no browser dando ao cliente

a capacidade de processamento de dados A necessidade da separacao do codigo

em camadas logicas advem da crescente complexidade das web applications Esta

pratica permite entre outras coisas melhorar o processo de desenvolvimento e a

capacidade de manutencao de uma aplicacao

Os fat-clients tem tambem a capacidade de armazenamento de dados o que

permite a persistencia de informacoes entre duas sessoes e que algumas operacoes

sejam executadas sem a necessidade de comunicacao com o servidor Este facto pode

tambem ser uma realidade nas web applications com a adopcao das tecnologias OWA

Neste momento assiste-se a uma utilizacao cada vez maior da web como uma

plataforma de desenvolvimento A capacidade de cooperacao na edicao de conteudos

e a mobilidade proporcionada por esta plataforma sao os principais factores que

alimentam esta mudanca e pela primeira vez as aplicacoes tradicionais tem com-

peticao vinda de web applications A prova do reconhecimento da web como plataforma

de desenvolvimento pode ser retirada da aposta de empresas como a Adobe e Mi-

crosoft que lancaram publicamente ferramentas web complementares a produtos

seus tradicionalmente associados ao desktop ndash Acrobatcom5 e Microsoft Office

Live6 Dotar estas web applications da capacidade de execucao offline significa

aproximar a web e o desktop reunindo ldquoo melhor de dois mundosrdquo

As vantagens da mobilidade possıvel atraves da web a cooperacao na criacao e

edicao de conteudos e a possibilidade de utilizar aplicacoes sempre actualizadas e

sem necessidade de instalacao sao algumas das principais vantagens que promovem

esta mudanca que devido as preocupacoes associadas a usabilidade e experiencia do

utilizador esta fortemente associada ao desenvolvimento de Rich Internet Applica-

tion (RIA)s

5Adobe Acrobatcom httpwwwacrobatcom6Microsoft ndash httpsmallbusinessofficelivecom

14

Enquadramento do Projecto

Figura 23 Comparacao do modelo de web aplications sıncrono paginas estaticas e in-teractivas abordados nas seccoes 221 e 222 com o modelo de web applications Ajax(assıncrono) abordado na seccao 223 Figura adaptada de http www adaptivepath

com

15

Enquadramento do Projecto

16

Capıtulo 3

Estado da arte

Apesar de o conceito das OWAs nao ser absolutamente novo as tecnologias que

o suportam sao recentes Neste capıtulo descrevem-se quatro tecnologias que foram

tidas como principais candidatas para o desenvolvimento deste projecto Descrevem-

se ainda alguns exemplos de web applications que disponibilizam actualmente fun-

cionalidades offline e o processo da escolha da tecnologia a utilizar neste projecto

31 Gears

O Gears1 e uma extensao as funcionalidades do browser introduzido pelo Google

que tem como principal objectivo tornar possıvel a visualizacao de paginas de Inter-

net mesmo sem uma conexao disponıvel Encontra-se disponıvel para as platafor-

mas Windows Macintosh e Linux e oferece uma API de Javascript que permite

a scripts aceder a um mecanismo de armazenamento local baseado numa base de

dados SQLite

311 Arquitectura

Esta ferramenta e constituıda por tres componentes principais

bull LocalServer mdash Intercepta pedidos de paginas web e serve-as localmente

bull Database mdash Uma base de dados relacional construıda sobre SQLite

bull WorkerPool mdash Permite executar operacoes de computacao de uma forma

assıncrona sem afectar a capacidade de resposta e fluidez de execucao da web

application Assemelham-se a processos

1Google Inc ndash Mais informacao em httpgearsgooglecom

17

Estado da arte

LocalServer

O modulo LocalServer e uma cache de Uniform Resource Locators (URLs)

controlada pela web application Quando nao existe uma ligacao a Internet e e

feito um pedido para um URL presente nesta cache o LocalServer intercepta-o e

responde ao pedido localmente a partir do disco rıgido do utilizador A aplicacao

pode utilizar dois tipos diferentes de armazenamento local de URLs

bull ResourceStore ndash serve para capturar URLs utilizando exclusivamente a API

de Javascript disponibilizada para o efeito Uma aplicacao podera criar e

utilizar diversos ResourceStores simultaneamente para capturar ficheiros de

dados que necessitam de ser enderecados por um URL tal como um ficheiro

PDF ou uma imagem

bull ManagedResourceStore ndash serve para capturar um conjunto de URLs que estao

relacionados e que sao declarado num ficheiro de manifesto (especificado em

JSON) e que sao automaticamente actualizados O ManagedResourceStore

permite que o conjunto de recursos necessarios para correr uma web application

seja capturado e mantido actualizado automaticamente

A principal diferenca entre estes dois tipos de armazenamento de URLs e a forma

como sao actualizados os seus conteudos Os conteudos de um ManagedResourceStore

sao actualizados sempre que a versao contida no ficheiro de manifesto for alterada

enquanto que os conteudos de um ResourceStore nunca sao actualizados automati-

camente mas apenas quando for explicitamente ordenado pela aplicacao

O LocalServer e capaz de interceptar e servir localmente pedidos de HTTP e

HTTPS sempre que se reunam as seguintes condicoes

1 O URL encontra-se armazenado num ResourceStore ou ManagedResourceStore

2 O sistema de armazenamento local encontra-se activo (enabled = true) Se

o sistema de armazenamento local tiver o atributo requiredCookie o pedido

devera conter um cookie que lhe corresponda

O LocalServer nao necessita de monitorizar o estado da ligacao para atender aos

pedidos Na verdade sempre que as condicoes previamente enunciadas se verificarem

o LocalServer interceptara os pedidos e independentemente do estado da ligacao

a Internet servi-los-a a partir do disco rıgido local Cabera a aplicacao definir qual

o modo em que pretende executar um pedido (online ou offline) definindo o valor

de verdade da propriedade enabled

18

Estado da arte

Database

O modulo Database permite guardar dados da web application assegurando a

sua persistencia Os dados sao guardados de forma relacional no disco rıgido do uti-

lizador2 de acordo com o modelo de seguranca estabelecido pelo Gears3 significando

que uma aplicacao nao pode aceder a conteudos fora do seu domınio

WorkerPool

Nos web browsers uma operacao pesada de computacao pode tornar a interface

lenta e tornar menos agradavel a experiencia do utilizador O modulo WorkerPool

permite correr operacoes em background sem bloquear a interface com o utilizador

Os scripts executados numa WorkerPool nao activam os mecanismos de seguranca

do browser que mostram a mensagem ldquoA script on this page may be busy or may

have stopped respondingrdquo

O WorkerPool comporta-se como um conjunto de processos em vez de threads

Os Workers nao partilham qualquer estado de execucao o que significa que uma

alteracao a uma variavel num Worker nao afecta em nada a execucao de outro

Worker Alem disso os Workers nao herdam automaticamente nenhum codigo dos

seus pais Cada Worker e membro de um WorkerPool e os Workers podem in-

teragir entre si enviando mensagens em formato de texto ou JSON No entanto ha

tambem algumas limitacoes os Workers nao tem acesso ao DOM e objectos como

window ou document nao se encontram acessıveis Isto e consequencia de os Workers

nao partilharem o estado de execucao Mas tem acesso a todas as funcoes built-in

do Javascript A maioria das funcionalidades do Gears pode tambem ser acedida

atraves de uma variavel global especial definida como googlegearsfactory Para

outras funcionalidades especıficas os Workers podem ldquopedirrdquo a pagina principal para

continuar a execucao atraves do envio de mensagens

Outras funcionalidades

bull HttpRequest ndash Este modulo implementa a especificacao W3C XmlHttpRe-

quest definida em [vK08] tornando-a disponıvel para os workers e para a

pagina principal

bull Timer ndash Este modulo implementa a especificacao de timers tal como descrito

por [Hic08] e torna-os disponıveis para os workers e para a pagina principal

2Consultar httpcodegooglecomapisgearsapi_databasehtmldirectories3Consultar httpcodegooglecomapisgearssecurityhtml

19

Estado da arte

bull Factory ndash Esta classe e utilizada para instanciar todos os outros objectos da

API do Gears atraves do seu metodo create Este metodo pode ser utilizado

com os seguintes parametros

ndash betadatabase

ndash betahttprequest

ndash betalocalserver

ndash betatimer

ndash betaworkerpool

312 Goggle Gears em dispositivos moveis

O Gears esta tambem disponıvel em dispositivos Windows Mobile 5 e 6

Os dispositivos moveis estao pela sua natureza frequentemente desconectados

da Internet Mesmo quando possuem uma ligacao as latencias na transferencia de

dados em redes moveis tornam as aplicacoes pouco fluıdas mas o Gears permite

ultrapassar este obstaculo

O Gears funciona exactamente da mesma forma em dispositivos moveis equipados

com o Windows Mobile 5 e 6 como num computador comum Se uma aplicacao tiver

sido implementado com suporte para o Gears entao tambem estara preparada para

ser executada num dispositivo movel mas as limitacoes dos browsers disponıveis

para dispositivos moveis tem que ser consideradas Isto significa prever as condicoes

que permitam uma boa usabilidade devido aos pequenos ecras destes dispositivos

bem como o seu suporte limitado dos padroes do DOM CSS e JavaScript

32 Adobe AIR

O Adobe AIR4 e um runtime compatıvel com diversos browsers e sistemas opera-

tivos que pretende dar aos programadores a possibilidade de combinar diversas tec-

nologias de producao de conteudos para a Internet no desenvolvimento de Rich Inter-

net Application (RIA)s O Adobe AIR mantem uma relacao com o browser mas es-

tende as suas capacidades e tecnologias permitindo o desenvolvimento de aplicacoes

tambem para o ambiente de trabalho com janelas em tudo semelhantes as do sis-

tema operativo Segundo a Adobe o objectivo e complementar o browser dando

aos utilizadores (mas essencialmente aos programadores e equipas de desenvolvi-

mento) a escolha sobre como distribuir as suas aplicacoes Para este efeito o Adobe

AIR tem uma aproximacao diferente do Gears Em vez de ldquoestenderrdquo o browser

acrescentando-lhe funcionalidades o AIR permite tambem o desenvolvimento de

4Adobe - httpwwwadobecomproductsair

20

Estado da arte

aplicacoes que se destinam a ser executadas fora do ambiente do browser mas uti-

lizando as tecnologias comuns da Internet (por exemplo HTML CSS JavaScript

Flash Flex)[CDGH08]

A utilizacao desta tecnologia permite utilizar o browser ou o proprio runtime

Adobe AIR como plataforma de execucao da aplicacao

Na Tabela 31 faz-se uma comparacao das funcionalidades disponıveis de acordo

consoante se escolha o browser ou o desktop como plataforma base para a aplicacao

Uma vez que as aplicacoes Adobe AIR na plataforma desktop tem um caracter

persistente (sao instaladas no computador do utilizador) o Adobe AIR tem um

modelo de seguranca que se assemelha com o das tradicionais aplicacoes desktop

[Ada08] Este modelo e analisado nas seccoes 321 e 322 O ambiente em que

e executado o browser e restringido a execucao de web applications que podem

ser de varias origens (incluindo de origens anonimas ou sem confianca) O Adobe

AIR proporciona acesso a capacidades como acesso a ficheiros que necessitam da

confianca do utilizador

bull HTML ndash O desenvolvimento de aplicacoes para o Adobe AIR pode ser feito

com recurso a tecnologias de HTML e Ajax comuns utilizando as linguagens

de markup existentes distribuıdas como texto e interpretadas em execucao

(runtime)

bull Flash ndash Outra alternativa sera a utilizacao da linguagem Flash Permite a

renderizacao de graficos vectoriais e audiovıdeo com suporte nativo Utiliza

ActionScript para adicionar maior interactividade com o utilizador

bull Flex ndash O Flex e uma framework open source para o desenvolvimento de RIAs

usando Flash As aplicacoes Flex sao na realidade Flash sendo a principal

diferenca o ambiente de desenvolvimento

Como resultado uma aplicacao AIR podera ser implementada

bull Baseada em Flash ou Flex (aplicacoes cujo conteudo base e em ShockWave

Flash (SWF))

bull Baseada em Flash ou Flex tambem com HTML ou Portable Document Format

(PDF) Aplicacoes cujo conteudo de base e em FlashFlex (SWF) com HTML

(HTML JavaScript CSS) ou conteudo PDF incluıdo

bull Baseada em HTML Aplicacoes cujo conteudo base e em HTML Javascript

CSS

bull Baseada em HTML utilizando tambem FlashFlex ou PDF

21

Estado da arte

Os utilizadores interagem com uma aplicacao AIR da mesma forma que interagem

com outras aplicacoes com janelas nativas do seu sistema operativo O runtime e

instalado uma vez no computador do utilizador e a partir desse momento todas as

aplicacoes AIR terao o mesmo aspecto que qualquer outra aplicacao para o desktop

321 Seguranca

Permitir que uma web application aceda ao disco de armazenamento do utilizador

pode comprometer seriamente a sua seguranca Neste sentido o Adobe AIR tem

suporte para assinaturas digitais (Secure Sockets Layer (SSL)) que podem ser com-

pradas pelas equipas de desenvolvimento que o desejem e cujos certificados serao

apresentados ao utilizador no momento da instalacao Um outro aspecto ainda

relativo a seguranca e o mecanismo de isolamento de cada ambiente (sandbox )

322 Assinatura do codigo

O runtime AIR exige que todas as aplicacoes estejam digitalmente assinadas As

assinaturas digitais de codigo sao um processo que visa garantir a integridade da

aplicacao e a identidade do seu autor no momento da instalacao As equipas de

desenvolvimento podem ldquoassinarrdquo uma aplicacao utilizando um certificado atribuıdo

por uma Entidade Certificadora (Certification Authority) ou atraves de um certifi-

cado individual (self signed certificate) Neste momento o Adobe AIR suporta como

entidades certificadoras a Verisign e a Thawte [Ado08]

O instalador apresenta o nome de quem publica a aplicacao quando o codigo tiver

sido assinado com um certificado que apresente confianca ou que esteja encadeado

com um certificado que tenha ja sido aceite no computador em que se esta a instalar

a aplicacao

As equipas de desenvolvimento podem tambem assinar as aplicacoes com um

certificado auto-atribuıdo (um certificado criado por elas proprias) mas neste caso

o instalador apresentara estas aplicacoes como sendo de uma origem nao verificada

O AIR utiliza a infraestrutura publica de chaves [Ent07] suportada pelo arquivo

local do sistema operativo Para que a origem da aplicacao seja reconhecida o

computador onde a aplicacao AIR esta a ser instalada tem que confiar directamente

no certificado que foi utilizado para assinar a aplicacao ou confiar num certificado

que esteja num encadeamento logico de certificados confiados e que se ligue desta

forma ao certificado utilizado para assinar a aplicacao

Todas as aplicacoes AIR tem caracterısticas em comum independentemente da

tecnologia utilizada para o seu desenvolvimento (HTMLFlexFlash) No ambito

de uma aplicacao AIR existem um conjunto de APIs que estao disponıveis e que

tornam possıvel o acesso ao sistema local (leitura e escrita) e a recursos de rede que

22

Estado da arte

de outra forma nunca estariam acessıveis a partir de uma web application comum

Cada aplicacao AIR possui tambem diferentes nıveis de isolamento chamados secu-

rity sandboxes dependendo do tipo de conteudo que esta a ser carregado e do seu

objectivo

bull Isolamento ao nıvel da aplicacao5 ndash E a raiz de cada aplicacao AIR Este

nıvel de isolamento permite o acesso a APIs privilegiadas e especıficas do

AIR Em contrapartida e negado o acesso a algumas APIs que poderiam ser

facilmente utilizadas de forma maliciosa contra o utilizador final Importacao

dinamica de conteudos remotos e geralmente proibido e as tecnicas e mecan-

ismos de geracao dinamica de codigo sao fortemente restringidas Apenas

conteudo carregado directamente da directoria base da aplicacao podera ser

colocado neste nıvel de isolamento

bull Isolamento nao especıfico da aplicacao6 ndash contem todo o outro conteudo

que nao tenha sido carregado directamente para o isolamento da aplicacao

Isto inclui conteudo local e remoto Este tipo de conteudo nao tem acesso

directo as APIs do AIR e rege-se pelas mesmas regras tal como se tivesse sido

carregado por um browser a partir da mesma localizacao (por exemplo HTML

carregado a partir de um domınio remoto comporta-se da mesma forma que se

fosse acedido a partir do browser)

33 Mozilla Prism

331 XML User Interface Language

O eXtensible User Interface Language (XUL) e uma linguagem de anotacao

baseada em XML desenvolvida pela Mozilla Foundation que opera em aplicacoes

Mozilla multi plataforma tal como o Firefox O motor Gecko e a unica imple-

mentacao completa desta linguagem que foi desenhada sobre padroes web comuns

como CSS JavaScript e o DOM e permite o desenvolvimento de interfaces graficas

utilizando elementos pre-definidos tais como window box page textbox radio

button entre outros Infelizmente o XUL nao possui qualquer especificacao formal

ou implementacoes de inter-operabilidade para outros motores que nao o Gecko No

entanto a sua implementacao e licenciada em codigo aberto pelas licencas GNU Gen-

eral Public License (GPL) GNU Lesser General Public License (LGPL) e Mozilla

Public License (MPL)

Enunciam-se algumas caracterısticas desta linguagem

5NT application sandbox6NT non-application sandbox

23

Estado da arte

Liguagem de anotacao poderosa baseada em componentes (widgets) O ob-

jectivo do XUL e permitir a construcao de aplicacoes multi-plataforma em

claro contraste com o Dynamic HyperText Transfer Protocol (DHTML) que se

destina ao desenvolvimento de paginas web Por esta razao o XUL esta orien-

tado a componentes tais como janelas botoes e etiquetas em vez de paginas

cabecalhos de texto e ligacoes de hipertexto Investir tempo e esforco para

atingir este mesmo resultado em aplicacoes baseadas em DHTML compromete

frequentemente a complexidade e desempenho da aplicacao

Baseado em padroes O XUL e um dialecto XML baseado no padrao W3C XML

10 As aplicacoes escritas em XUL sao tambem baseadas em especificacoes

W3C adicionais como HTML 40 CSS DOM nıvel 1 e 2 JavaScript 15

incluindo ECMA-262 Edition 3 (ECMAscript)

Portabilidade entre plataformas Tal como HTML o XUL foi desenhado para

ser independente da plataforma em que e utilizado tornando as aplicacoes

facilmente portaveis entre sistemas operativos nos quais o Mozilla e suportado

Uma vez que o XUL oferece um nıvel de abstraccao dos componentes graficos

de interface que disponibiliza implementa a premissa ldquoum codigo para todas

as plataformasrdquo A interface grafica de todos os produtos centrais Mozilla

(browser instant messenger livro de enderecos) e escrita em XUL com um

unico codigo base que suporta todas as plataformas Mozilla

Separacao entre o nıvel de apresentacao e a logica de negocio Uma das

maiores preocupacoes no desenvolvimento para a Internet e a forte ligacao

entre estas duas camadas (interface e logica) Isto constitui um problema sig-

nificativo no desenvolvimento de grandes aplicacoes especialmente quando o

desenvolvimento e feito em ambientes de equipa porque as capacidades de de-

senvolvimento destas duas partes da aplicacao estao muitas vezes espalhadas

por diferentes elementos O XUL permite uma clara distincao entre a definicao

da aplicacao cliente e da logica de implementacao (XUL eXtensible Binding

Language (XBL) e JavaScript) apresentacao (CSS e imagens) internacional-

izacao (Document Type Definitions (DTDs) e etiquetas de texto em lınguas

especıficas guardados em ficheiros properties) O esquema grafico e apre-

sentacao de uma aplicacao XUL pode ser alterado de forma independente da

sua logica ou implementacao e a aplicacao pode ainda ser traduzida (interna-

tionalization) de forma independente da sua logica implementacao ou apre-

sentacao Este grau de separacao resulta em aplicacoes que sao mais faceis de

manter pelos programadores e facilmente adaptadas por designers e tradutores

24

Estado da arte

Facil adaptacao Outro benefıcio que advem do nıvel de separacao entre logica

de negocio e apresentacao oferecido pelo XUL e a facilidade com que se pode

adaptar uma aplicacao para diferentes clientes ou grupos de utilizadores Um

programador pode utilizar a mesma aplicacao base e adapta-la consoante as

necessidades atraves de diferentes temas (skins) e ficheiros de lınguas Desta

forma uma aplicacao escrita e desenvolvida em Ingles pode ser rapidamente

traduzida para Portugues e distribuıda com outra aparencia mais apropriada

ao cliente alvo

332 Prism

O Mozilla Prism e um browser simplificado e ldquointerpretadorrdquo de XUL (tambem

designado por XULRunner) que acolhe web applications sem a interface grafica ha-

bitual de um browser Baseia-se num conceito designado por Site Specific Browser

(SSB) Um SSB e uma aplicacao com um browser embebido desenhado para exe-

cutar apenas uma web application Nao possui os menus e barras de ferramentas

habituais Um SSB tem uma integracao com o sistema operativo e com o desktop

muito mais estreita do que uma web application acedida atraves de um browser uma

vez que e executado em janela propria

O Prism resulta de uma experiencia da Mozilla e visa reduzir as diferencas entre

as desktop applications tradicionais e as web applications Um dos aspectos focados e

a experiencia do utilizador Numa apresentacao oficial e dito que ldquo[o Prism] pretende

ser uma ponte entre as diferencas que existem entre as aplicacoes tradicionais de

desktop e as web applications explorando novos modelos de usabilidade enquanto

que a linha que as separa se continua a definirrdquo [Lab07]

34 HTML 5

A especificacao HTML 5 [Hic08] que se encontra em fase de desenvolvimento

pelo grupo WHATWG pretende ser uma norma de substituicao dos padroes HTML

4 XHTML 1x e do DOM2 HTML Uma das propriedades que o distingue das tec-

nologias que pretende substituir e precisamente o suporte para OWA e armazena-

mento de dados no cliente de uma forma relacional Nao sendo propriamente uma

tecnologia ndashmas antes uma especificacao ndashe aqui mencionada por ter servido como

referencia a diversas implementacoes de funcionalidades offline e por se considerar

que venha a ter um impacto significativo nas implementacoes de diversos browsers

Dion Almaer defendeu no seu blogue que o Gears era uma implementacao do

HTML 5 No seu artigo ldquoGears as a bleeding-edge HTML 5 implementationrdquo [Alm08]

o autor diz que ambos ndasho Gears e o HTML 5 ndashpretendem dar a web caracterısticas

25

Estado da arte

semelhantes e nao encontrar motivo de ldquocompeticaordquo entre as duas mas que en-

quanto o HTML 5 e uma especificacao o Gears e uma implementacao

No entanto tambem e verdade que o HTML 5 cobre muitos outros pontos para

alem das OWA que saem completamente fora do ambito do Gears Se esta es-

pecificacao atingir um estado de maturidade que possibilite a sua adopcao pelos

principais browsers tornando nativo do browser o suporte OWA entao deixara de

fazer sentido a existencia de uma extensao como o Gears

A especificacao HTML 5 disponibiliza duas APIs relevantes para o tema das

OWA

1 Uma base de dados baseada em SQL que permite o armazenamento de dados

do lado do cliente

2 Uma ldquocacherdquo HTTP que garante a disponibilidade das aplicacoes mesmo quando

o utilizador nao possui uma ligacao a Internet

Estas caracterısticas sao as bases da tecnologia das OWA e tem correspondencia

com os pontos analisados nas seccoes 311 e 311

35 Web applications que usam funcionalidades offline

Nesta seccao apresentam-se algumas web applications que actualmente disponi-

bilizam funcionalidades offline Estas aplicacoes foram escolhidas para uma analise

mais pormenorizada por utilizarem o Gears que tal como descrito na seccao 4 foi

a tecnologia escolhida para o projecto

351 Google Reader e Google Docs

O Google Reader7 e um leitor de feeds RSS Permite gerir a subscricao de varios

sites simultaneamente que disponibilizem conteudos neste formato e foi a primeira

web application da Google com uma versao offline publicamente acessıvel (desde

Junho de 2007)

O Google Reader implementa o modo ldquoutilizador deciderdquo oferecendo na sua

interface um botao que permite alternar entre os modos online e offline

O Google Docs8 e uma web application que permite a criacao e edicao de doc-

umentos de texto folhas de calculo e apresentacoes Era ja publico desde Janeiro

de 2008 que o Google estava a desenvolver uma versao OWA desta aplicacao mas o

acesso a uma versao experimental so foi possıvel a partir de 31 de Maio de 2008

7Google Reader - httpreadergooglecom8Google Docs - httpdocsgooglecom

26

Estado da arte

A implementacao das funcionalidades offline nestas duas aplicacoes seguiu difer-

entes aproximacoes principalmente porque o Google Reader apresenta ao utilizador

informacoes que sao fornecidas por fontes externas enquanto que no Google Docs

a informacao e criada e editada pelo utilizador sobre a forma de documentos

A diferente origem da informacao implica que no Google Reader seja necessario

prever casos de excepcao tal como existirem demasiados itens que necessitam de

ser transferidos para o cliente Nao observar este ponto causa um problema grave

de usabilidade e para evitar tempos de espera demasiado longos e uma interface

com pouca capacidade de resposta as accoes do utilizador o Google Reader apenas

transfere para o cliente os dois mil itens mais recentes na transicao para o modo

offline

352 Remember the Milk

O Remember The Milk9 e uma web application desenvolvida por uma equipa

Australiana que proporciona funcionalidades de agenda gestao de tempo e de tare-

fas e foi uma das primeiras aplicacoes independentes do Google a adoptar o Gears

para acessos em modo offline Permite que os seus utilizadores facam uma gestao

de tarefas agrupando-as em listas adicionando-lhes campos de informacao adicional

ou dando-lhes informacao geografica (recorrendo ao servico Google Maps10) Entre

a sua lista de funcionalidades encontra-se ainda a possibilidade de importar e ex-

portar eventos no formato iCalendar (ics) etiquetas (tags) em tarefas publicacao

Really Simple Syndication (RSS) e partilha de categorias de tarefas de acordo com

diferentes nıveis de permissoes de acesso definidos pelo utilizador

353 MySpace e WordPresscom

O MySpace uma das maiores social networks na Internet anunciou recente-

mente que vai disponibilizar uma versao do seu cliente de e-mail que utiliza o Gears

para acelerar o seu desempenho Numa fase inicial estara disponıvel apenas para

utilizadores que tenham cinco mil ou mais mensagens na sua caixa de correio e

permitira efectuar pesquisas muito mais rapido que a sua versao online

O servico de blogs Wordpresscom anunciou tambem o inıcio da utilizacao desta

tecnologia com o fim de melhorar o desempenho A versao que utiliza esta tecnologia

descarrega e armazena no cliente um conjunto de imagens e scripts que passam a

ter preferencia sobre os seus congeneres online e que permitem acelerar o processo

de carregamento da aplicacao e visualizacao de blogs

9Remember The Milk ndash httpwwwrememberthemilkcom10Google Maps ndash httpmapsgooglecom

27

Estado da arte

O MySpace e o Wordpresscom sao dois exemplos da utilizacao da tecnologia

OWA para optimizacao de web application ja existentes Sem pretenderem disponi-

bilizar uma versao que seja totalmente offline fazem uso do Gears para armazenar no

cliente parte dos recursos frequentemente acedidos na visualizacao das suas paginas

36 Escolha da tecnologia

Apos a analise das tecnologias apresentada nas seccoes 31 a 34 foi necessario es-

tudar a adequacao de cada uma delas ao projecto em questao Desde logo e possıvel

observar que nem todas se dedicam apenas a OWA Por exemplo o Adobe AIR

apesar de ter suporte para OWA apenas disponibiliza algumas das funcionalidades

identificadas como mais indicadas para a execucao do projecto quando utilizado

na sua vertente desktop tal como exposto na Tabela 31 mas a utilizacao desta

vertente implicaria o desenvolvimento de novas interfaces e de novas formas de co-

municacao (troca de mensagens XML ou JSON) A vertente web do Adobe AIR

foca-se mais especificamente nas Rich Internet Applications e permite a reutilizacao

do codigo ja existente (exigindo naturalmente a sua adaptacao e a implementacao

das funcionalidades pretendidas)

A tecnologia escolhida para a realizacao deste trabalho foi o Gears sendo que

um dos principais factores a influenciar esta opcao foi a liberdade introduzida pela

sua licenca Berkeley Software Distribution (BSD)11

Considerou-se o funcionamento desta ferramenta extremamente adequando a

aplicacao no WOW uma vez que o seu principal objectivo e precisamente tornar

possıvel a execucao offline de uma pagina web e por virtude deste facto o Gears tem

uma API concisa e de simples aplicacao pratica uma vez que nao possui quaisquer

outros elementos distractores O funcionamento do seu ManagedResourceStore ex-

emplificado na Figura 31 com a capacidade de actualizacao de recursos definidos

num ficheiro manifesto especificado em JSON pesou tambem nesta decisao

11Sobre a licenca BSD consultar httpwwwopensourceorglicensesbsd-licensephp e http

wwwlinfoorgbsdlicensehtml

28

Estado da arte

Figura 31 Esquema UML do processo efectuado pelos recursos do Gears do tipoManagedResourceStore para a actualizacao dos conteudos definidos no ficheiro manifesto

29

Estado da arte

Funcionalidade RIAs no browser RIAs no desktop

Disponibilidadeda aplicacao

As aplicacoes podem ser facil-mente exploradas e utilizadas

As aplicacoes quando instal-adas tem maior grau de fun-cionalidades e persistencia

Instalacao Nao e necessario qualquer tipode instalacao

As aplicacoes sao instaladasatraves do browser ou descar-regadas e instaladas comouma aplicacao tradicional

Actualizacoes Aplicacoes sao actualizadascarregando conteudos paraum website

O AIR disponibiliza uma APIque permite que as aplicacoessejam actualizadas de umaforma

Sistemas opera-tivos suportados

As aplicacoes podem ser exe-cutadas em diversos sistemasoperativos e browsers

As aplicacoes sao multi-plataforma e podem serinstaladas e executadas emdiversos sistemas operativos ebrowsers

Linguagens deprogramacao

Javascript e disponibilizadopelo browser e ActionScripte disponibilizado pelo AdobeFlash Player

Maquinas virtuais deJavascript e ActionScriptcompatıveis com o browser

Capacidade deexecucao embackground

As RIAs podem ser execu-tadas numa janela do browser

As aplicacoes podem ser ex-ecutadas em background edisponibilizar notificacoes talcomo uma aplicacao tradi-cional

Persistencia A actividade esta limitada asessao do browser Quando obrowser e encerrado toda ainformacao e descartada

As aplicacoes sao instaladas eestao disponıveis no desktopPodem armazenar informacaolocalmente e estao disponıveisoffline

Integracao com odesktop

Integracao com o desktop lim-itada devido a restricoes im-postas pelo browser

As aplicacoes podem acederao sistema de ficheiro ao clip-board eventos notificacoesetc

Controlo da inter-face com o uti-lizador

As aplicacoes sao acedidasatraves de uma janela dobrowser que tem os seusproprios controlos e visualgrafico

As aplicacoes tem um vi-sual grafico proprio em janelapropria

Armazenamentode dados

As aplicacoes tem armazena-mento limitado que pode serreescrito pelo browser

As aplicacoes tem acesso a to-talidade do espaco disponıvellocalmente e a uma base dedados com a possibilidade deencriptacao

Tabela 31 Comparacao das funcionalidades oferecidas pelo Adobe AIR para as platafor-mas web e desktop

30

Estado da arte

Aplicacao Modo de execucao utilizadoGoogle Reader Utiliza o modo ldquoutilizador deciderdquo disponibilizando

ao utilizador um botao para alternar entre os modosonline e offline Como lida com informacao recol-hida de fontes externas de natureza frequentementeefemera o processo de sincronizacao apenas transfereos dois mil itens mais recentes quando passa ao es-tado offline Neste modo sao ainda guardadas in-formacoes de itens lidos e etiquetas atribuıdas quesao sincronizadas com o servidor quando o utilizadorvoltar a activar estado online

Google Docs Utiliza o modo ldquoaplicacao deciderdquo permitindo que outilizador edite os conteudos de documentos de textofolhas de calculo e de apresentacoes independente-mente do estado da ligacao desde o momento em queas funcionalidades offline sao activadas A aplicacaofaz pequenas sincronizacoes com o servidor sempre quenecessario

Remember the Milk Utiliza um modo hıbrido entre ldquoaplicacao deciderdquo eldquoutilizador deciderdquo A aplicacao encarrega-se da sin-cronizacao de dados mas disponibiliza um controlona sua interface que permite despoletar manualmenteeste processo para situacoes em que o utilizador fez al-teracoes recentes e pretende usufruir das capacidadesoffline imediatamente

MySpace O MySpace anunciou a utilizacao de mecanismos dearmazenamento de dados no cliente com recurso atecnologias OWA para melhorar o desempenho doseu cliente web de correio electronico nomeadamenteno que diz respeito a operacoes de pesquisa e or-denacao Inicialmente esta funcionalidade estara ape-nas disponıvel para utilizadores com cinco mil ou maismensagens na sua caixa de correio mas nao e aindaclaro se sera disponibilizada uma versao totalmenteoffline

Tabela 32 Resumo da utilizacao de tecnologias OWA em algumas web applications con-sideradas na analise do estado da arte

31

Estado da arte

32

Capıtulo 4

Desenvolvimento

Neste capıtulo introduz-se a aplicacao WOW e apresenta-se o estudo que foi

feito da adequacao de cada tecnologia para a implementacao da funcionalidade of-

fline nesta plataforma Fazem-se diversas consideracoes sobre opcoes a tomar na

concepcao de OWAs e problemas comuns na sua implementacao bem como sug-

estoes para os resolver O WOW e uma aplicacao ja existente de gestao de ordens

de trabalho e do fluxo de tarefas numa empresa ou organizacao

41 Como ficar offline

Na maior parte das web applications de hoje nao existe uma camada de dados

real A aplicacao exemplificada na Figura 41 ao longo da sua execucao acede

directamente a sua unica fonte de dados (o servidor) atraves de chamadas Ajax sem

que exista uma separacao clara destas duas camadas

Para que uma web application seja capaz de ser executada sem uma ligacao

activa a Internet e mantenha o seu caracter dinamico torna-se necessario incluir

Figura 41 Exemplo de uma arquitectura de uma web application sem uma camada deabstraccao de dados Figura adaptada de http gears google com

33

Desenvolvimento

Figura 42 Exemplo de uma arquitectura de uma web application com uma camada deabstraccao de dados Figura adaptada de http gears google com

um mecanismo de armazenamento de dados local seja uma base de dados ou a

capacidade de acesso ao disco No entanto este mecanismo introduz dois problemas

1 Qual das fontes de dados utilizar quando um utilizador faz um pedido de

informacao

2 A necessidade de implementar uma camada de acesso a dados que seja coerente

quer se use o servidor remoto ou local

Por exemplo em vez de a aplicacao Ajax fazer um pedido relativo as contas de

todos os utilizadores em formato JSON directamente ao servidor remoto podera ao

inves fazer o pedido a um objecto intermedio da camada de dados Este objecto

demonstrado na Figura 42 sera responsavel por implementar uma interface de

acesso a base de dados e retornar um objecto JavaScript com uma representacao da

resposta do servidor

Mas a existencia de uma segunda fonte de dados torna recomendavel tambem

a implementacao de uma camada de data switching que em funcao da existencia

de conexao a Internet e da necessidade de actualizacao dos dados decide se faz o

pedido ao servidor remoto ou se fornece os dados presentes localmente Este objecto

apresentado na Figura 43 decidira de forma transparente para o utilizador se le ou

escreve os dados localmente ou se os enviapede ao servidor remoto e pode tambem

iniciar o processo de convergencia de dados e de resolucao de conflitos

411 Funcionalidades disponıveis em modo offline

Por razoes praticas e provavel que nem todas as funcionalidades da aplicacao

possam ser disponibilizadas em modo offline E necessario escolher quais as fun-

cionalidades a disponibilizar no modo offline da aplicacao e implementar a logica

que decide quando utilizar a base de dados local ou o servidor remoto Apesar do

acesso a base de dados local ser muito mais rapido do que aceder ao servidor o

acesso local nem sempre e preferido Ha varias razoes que podem tornar necessario

escolher o acesso ao servidor em vez do acesso local

34

Desenvolvimento

Figura 43 Exemplo de uma arquitectura de uma web application com uma camada deabstraccao de dados e um data switch Figura adaptada de http gears google com

1 A informacao pode ter uma natureza efemera e nao fazer sentido guarda-la

localmente Exemplo dados em tempo real da bolsa de valores de Lisboa

2 Algumas aplicacoes lidam com informacao que so faz sentido na presenca de

uma ligacao Exemplo Instant Messaging

3 A aplicacao podera escolher apenas guardar a informacao acedida mais fre-

quentemente Exemplo para o utilizador poder alterar a lıngua de apre-

sentacao da aplicacao os conteudos terao que ser guardados em todas as

lınguas disponibilizadas pela aplicacao O custo de implementacao de algu-

mas funcionalidades pode nao compensar o benefıcio

4 A capacidade de processamento ou de armazenamento de dados pode inviabi-

lizar algumas funcionalidades offline Exemplo se uma dada funcionalidade

necessita de uma capacidade de armazenamento de dados para alem do razoavel

de um computador pessoal para ser util (visualizador de mapas)

42 Modos de execucao

Um aspecto que e necessario estudar para qualquer web application que se deseje

disponibilizar offline prende-se com tres modos de execucao que devem ser consid-

erados

1 Utilizador decide o modo de execucao A aplicacao tem modos distintos

de execucao para os estados online e offline geralmente indicados na interface

com o utilizador O utilizador e informado do estado da ligacao e participa na

alteracao de estado de execucao da aplicacao interagindo com a sua interface

2 Aplicacao decide o modo de execucao Pode ser implementado na propria

aplicacao um mecanismo de deteccao do estado da ligacao (por exemplo atraves

35

Desenvolvimento

de chamadas Ajax periodicas) transitando de estado e sincronizando automati-

camente Desta forma o utilizador nao precisa de participar na alteracao de

estado a menos que exista um conflito de dados que requeira a sua atencao

3 Aplicacao assume sempre o estado offline Outra hipotese sera imple-

mentar uma web application que assume sempre estar na ausencia de uma

ligacao ao servidor de dados Esta aplicacao responde aos pedidos do uti-

lizador efectuando pedidos de informacao ao servidor mas nao dependendo

de uma resposta valida para mostrar a informacao que ja tinha disponıvel an-

teriormente A sincronizacao de dados com o servidor e tentada sempre que

existam dados para submeter e uma accao do utilizador

421 Modo ldquoutilizador deciderdquo

Neste modo de execucao quando a aplicacao esta online comunica com o servidor

remoto quando esta offline comunica com a base de dados local A informacao tem

que ser sincronizada sempre que se muda de modo A principal vantagem desta opcao

e que e a mais simples de implementar mesmo para uma aplicacao ja existente e

portanto uma forma expedita de disponibilizar uma OWA No entanto tem tambem

algumas desvantagens que devem ser consideradas

1 O utilizador tem que se lembrar de fazer a alteracao de estado de execucao

Caso contrario podera estar a trabalhar inadvertidamente numa versao offline

com dados antigos ou nao ter a informacao necessaria se perder subitamente

a ligacao

2 Se a ligacao for intermitente o utilizador tera ou que escolher um dos modos

de execucao ou estar constantemente a trocar

3 Uma vez que a base de dados nao esta sempre actualizada nao podera ser

utilizada para melhorar a rapidez de execucao da aplicacao quando em modo

online

422 Modo aplicacao decide

A deteccao do estado da ligacao pode ser implementada atraves de um pedido

assıncrono ao servidor tal como ilustrado na Figura 44 O resultado deste pedido

definira o estado online (em caso de sucesso) ou offline (em caso de falha) A

sincronizacao de dados podera ser feita sempre que ocorra uma transicao do es-

tado offline para o estado online No entanto este metodo nao se revela eficiente

36

Desenvolvimento

Figura 44 Esquema grafico ilustrando uma OWA executando no browser utilizando ummodo de execucao do tipo ldquoaplicacao deciderdquo com deteccao automatica do estado daligacao via pedidos Ajax assıncronos a cada cinco segundos

para grandes aplicacoes uma vez que requer a troca de mensagens demasiado fre-

quentes com o servidor que se destinam exclusivamente a monitorizacao do estado

da ligacao

423 Modo ldquoaplicacao assume o estado offlinerdquo

Uma aplicacao transparente funciona assumindo sempre que esta em modo of-

fline ou pelo menos que pode perder a ligacao a qualquer momento Neste modo

tira-se o maximo partido do armazenamento local e fazem-se pequenas mas contınuas

sincronizacoes com o servidor sempre que este esteja disponıvel A sincronizacao de

dados tambem e feita sempre que se volta ao estado online

As vantagens de uma web application transparente sao as seguintes

bull Uma melhor experiencia para o utilizador uma vez que este nao tem que se

preocupar com o estado da ligacao ou com a transicao de estados

bull A aplicacao funciona de forma coerente mesmo que a ligacao seja intermitente

bull Uma vez que o armazenamento local e mantido actualizado pode ser utilizado

para melhorar o desempenho da aplicacao

Foram identificadas as seguintes desvantagens

bull E mais difıcil de implementar e a sincronizacao acarreta cuidados especiais

bull E necessario um cuidado adicional para evitar que as operacoes de sincronizacao

frequentes que ocorrem automaticamente nao afectem os tempos de resposta

da aplicacao

bull Os testes a aplicacao sao mais complexos uma vez que a sincronizacao de dados

nao ocorre em resposta a uma accao do utilizador

37

Desenvolvimento

43 Sincronizacao de dados

A sincronizacao de dados consiste na capacidade de identificar e transferir pe-

riodicamente a versao mais actual dos dados entre o cliente e o(s) servidor(es)

Independentemente do modo de execucao escolhido e mesmo do estado da ligacao

do utilizador a informacao armazenada localmente e a informacao armazenada no

servidor estarao por vezes dessincronizadas Isto podera acontecer sempre que por

exemplo

bull O utilizador faz alteracoes em modo offline

bull A informacao e partilhada e pode ser alterada por uma entidade externa

bull A informacao e fornecida por uma entidade externa

Resolver estas diferencas de forma a que a informacao local e remota encontrem

a igualdade chama-se sincronizacao de dados Ha varias aproximacoes possıveis

para este efeito que dependem da natureza da aplicacao cada uma com vantagens

e desvantagens

A capacidade de suportar a mobilidade dos utilizadores torna-se cada vez um

ponto mais importante de uma web application Para uma organizacao de dimensao

global e vital garantir que os seus colaboradores tem acesso a mesma informacao

que tem disponıvel nos seus postos de trabalho mesmo quando estao fora Na maior

parte dos casos estes colaboradores terao acesso a um computador portatil um

desktop Smartphone ou PDA e atraves destes poderao ter acesso a sua informacao

directamente atraves de ligacoes encriptadas Virtual Private Network (VPN) de um

servidor web ou de outro mecanismo de rede

Esta solucao e simples de implementar mas infelizmente para a maioria dos

colaboradores com grande factor de mobilidade nao e satisfatoria As principais

desvantagens sao as seguintes

bull Requisitos de ligacao Para permitir que os utilizadores acedam a sua in-

formacao e necessario garantir a capacidade constante de comunicacao pelo

menos durante o tempo necessario que assegure a sua transferencia

bull Velocidade de ligacao sem persistencia de dados e em ligacoes de fraca

qualidade a usabilidade por vezes torna-se inaceitavel

bull Ponto crıtico de falha Com este tipo de solucao todos os utilizadores de-

pendem da base de dados que armazena informacao vital para o funcionamento

do cliente

38

Desenvolvimento

bull Scalability do servidor A medida que novos utilizadores sao adicionados ao

sistema o desempenho do servidor e afectado levando a necessidade de maior

capacidade de armazenamento eou processamento

De acordo com a documentacao da Microsoft Sync Framework [Mic08] uma

solucao alternativa consiste em implementar uma Occasionally Connected Appli-

cation (OCA) Uma OCA permite a um utilizador remoto continuar a aceder a

sua informacao mesmo depois de perder a ligacao mas em vez de recorrer a um

servidor recorre a informacao armazenada no seu dispositivo local Para preencher

localmente a informacao que o utilizador necessita uma OCA possui mecanismos

de sincronizacao de dados que sao oferecidos por esta framework

431 Quando sincronizar

Uma das solucoes mais simples de implementar passa por disponibilizar um

mecanismo manual que despoleta a sincronizacao Diz-se manual porque e o uti-

lizador que escolhe quando sincronizar e pode ser implementada simplesmente

fazendo o upload de toda a informacao para o servidor e depois fazendo o download

da copia mais recente da informacao antes de voltar a ficar offline Para que esta

seja uma opcao viavel e necessario que

bull O volume de dados seja suficientemente pequeno para que possa ser transferido

do servidor para o cliente num espaco de tempo aceitavel

bull Que o utilizador indique explicitamente que quer mudar para o estado offline

ou online pressionando um botao da interface

Contudo podem ser identificados alguns problemas relacionados com esta abor-

dagem

bull Os utilizadores nem sempre podem prever o estado das suas ligacoes A ligacao

pode-se perder subitamente ou ter um caracter intermitente

bull O utilizador pode esquecer-se de efectuar a sincronizacao

Outra opcao sera conjugar a sincronizacao de dados com o modo de execucao

transparente A sincronizacao ocorre automaticamente em background de forma

nao intrusiva para o utilizador A aplicacao comunica com o servidor regularmente

efectuando pequenas trocas de dados com o objectivo de manter o sincronismo da

informacao local e remota Esta abordagem pode ser implementada com pedidos

Ajax assıncronos e regulares ao servidor o que permite manter a interaccao com a

interface fluıda evitando bloqueios Estes pedidos sao feitos prevendo as situacoes

39

Desenvolvimento

de disponibilidade ou indisponibilidade (timeout) do servidor Uma outra opcao

sera permitir que o servidor comunique essas alteracoes utilizando Comet1 tal como

descrito em [Wil06] e [Rus06] As vantagens destas aproximacoes sao

bull A informacao esta disponıvel a qualquer altura que o utilizador decida ficar

offline ou que a ligacao seja acidentalmente perdida

bull O desempenho da aplicacao pode ser melhorado quando se estiver a utilizar

uma ligacao a Internet lenta uma vez que o acesso a dados locais e mais

eficiente do que a consulta de dados ao servidor

44 WOW

O WOW e uma plataforma integrada de gestao de ordens de trabalho ja ex-

istente e desenvolvida pela Critical Software SA a qual se pretende adicionar a

capacidade de execucao offline Esta aplicacao e extremamente dinamica e con-

figuravel com um conjunto extremamente rico de funcionalidades das quais se

destacam

bull Gestao de Ordens de Trabalho ndash suportando a gestao dos pedidos desde a

sua criacao ate ao seu fecho tomando em conta os diferentes tipos de pedidos

(ordens de trabalho pedidos de informacao melhorias resolucao de problemas

etc) e diferentes tipos de accoes possıveis para cada um (Figura 45)

bull Monitorizacao de alteracoes ndash Historico de mudancas anexos e estados criando

relatorios de alteracao automaticamente (o que por quem e quando)

bull Uso de Service Level Agreements (SLAs) ndash E possıvel associar a um pedido um

SLA que define qual o perıodo de tempo atribuıdo a resolucao de um pedido

controlando e agilizando a resolucao do mesmo

bull Utilizacao de queries de utilizador configuraveis que permitem acesso rapido

a determinadas ordens de trabalho de acordo com o filtro configurado (por

exemplo ldquoPara mimrdquo ldquoPara o Grupordquo ldquoPelo Grupordquo)

bull Gestao do relacionamento entre pedidos

bull Pesquisa e filtragem de ordens de trabalho

bull Exportacao de dados em formatos padrao (PDF DOC ou XLS)

bull Integravel com solucoes externas

40

Desenvolvimento

Figura 45 Detalhe de um conjunto possıvel de estados e respectivas transicoes para umadada ordem de trabalho no WOW desde a sua submissao no sistema ate a sua conclusaoem fecho ou cancelamento Esta figura representa apenas um exemplo ja que o mapa deestados para uma ordem de trabalho e dinamico e pode ser alterado por um administradorFigura retirada de uma brochura promocional do WOW Critical Software SA

A utilizacao de uma ferramenta deste tipo por parte de uma empresa ou orga-

nizacao oferece vantagens quer a gestao de topo quer aos colaboradores individuais

para os colaboradores individuais o WOW e uma aplicacao onde estao registadas

todas as tarefas contribuindo activamente para o desenvolvimento em ambientes

multi-tarefa e para a organizacao pessoal das tarefas de acordo com prioridades

Para a gestao de topo esta ferramenta permite obter uma visao global do estado da

organizacao em termos de tempo gasto por tarefa executada sendo uma mais valia

para a previsao e gestaoalocacao de recursos

45 Visao geral sobre a arquitectura do WOW

O WOW e interessante nao so do ponto de vista de produto como tambem do

ponto de vista de plataforma Existem diversos plug-ins que estendem as funcional-

idades do WOW e existem ate projectos que pretendem usar a arquitectura do

WOW para criar produtos com fins diferentes do inicial (por exemplo o WOW-

Storm ndash um sistema de registo e classificacao social de ideias)

De modo a conseguir ter essa expansibilidade a plataforma WOW assenta sob

uma arquitectura distribuıda modular e expansıvel com uma componente central

ndash o core ndash estruturado em camadas logicas E no core que se situam todas as

1O Comet e um conceito semelhante ao Ajax introduzido por Alex Russel mas no qual e o servidor quetoma a iniciativa de ldquoenviarrdquo os dados ao browser sem que este tenha que efectuar um pedido Tambem econhecido por Ajax Push Reverse Ajax ou HTTP Streaming

41

Desenvolvimento

funcionalidades base da aplicacao quer a nıvel logico funcional e de apresentacao

quer a nıvel de gestao e configuracao

E possıvel a execucao de varias instancias do core simultaneamente em servidores

distintos o que permite a alta escalabilidade e disponibilidade desta aplicacao A

consistencia dos dados fica sempre garantida atraves da partilha da base de dados

e pelo balanceamento dos pedidos uma vez que cada um e encaminhado para uma

unica instancia

O WOW apresenta tambem a vantagem de ser uma plataforma extensıvel E

possıvel adicionar novas caracterısticas a plataforma atraves de componentes que se

podem ser divididos em duas categorias plugins e connectors

Os plugins sao componentes que se encontram no mesmo no fısico que a aplicacao

partilhando do mesmo contexto de execucao do core Sao assim uma forma mais

directa de obter informacao da plataforma visto que nao possuem restricoes de

acesso aos dados nem dependencias externas A arquitectura deste componente tera

assim que permitir varias execucoes instanciadas cada uma associada a um core

Por outro lado os connectors sao componentes que se encontram distribuıdos

comunicando externamente com o core Quer a sua execucao quer a obtencao

dos dados estao assim dependentes de interfaces de comunicacao externas que a

plataforma disponibiliza Estes componentes ao contrario dos plugins sao instan-

ciados unicamente e recorrem ao protocolo de comunicacao Java Messaging Service

(JMS) para comunicar com o core

46 WOW Offline

Para alem das opcoes tomadas relativamente a tecnologia a utilizar surgiu

tambem a necessidade de optar por um dos modos de execucao apresentados na

seccao 42

Das tres opcoes possıveis foi o modo ldquoaplicacao assume o estado offlinerdquo descrito

na seccao 423 que mereceu a maior atencao uma vez que reune as vantagens de

uma experiencia mais positiva para o utilizador (uma vez que este nao tem que

participar activamente na alteracao do modo execucao como descrito na seccao 421)

e nao constitui uma sobrecarga excessiva para servidor (como o modo abordado na

seccao 422)

No entanto esta opcao comprometia a complexidade da implementacao para alem

dos objectivos propostos para este projecto e para cumprir o prazo dado foi tomada

a decisao de implementar o modo ldquoutilizador deciderdquo especificando apenas de forma

teorica o modo ldquoaplicacao assume o estado offlinerdquo

As caracterısticas do Gears foram ja descritas na seccao 31 Na Figura 47

mostra-se a sua forma de funcionamento quando integrado numa web application

42

Desenvolvimento

Nesta figura representa-se o modulo LocalServer do Gears como um ponto de de-

cisao Aqui sao testadas as condicoes que determinam se o pedido sera interceptado e

servido localmente ou se prossegue para uma maquina remota E tambem represen-

tada uma base de dados que corresponde ao modulo Database mas que podera nao

ser utilizada Este modulo tal como o modulo Workerpool tem caracter opcional

e sao utilizados consoante os requisitos da aplicacao

A plataforma WOW lida com mais dados do que e necessario passar para o

lado do cliente Em conformidade com o ja exposto na seccao 411 volta-se a

frisar que nao se pretende recriar toda a logica de negocio nem os conteudos da

base de dados no cliente pela sua complexidade e volume de dados Pretende-se

pelo contrario permitir que os utilizadores tirem partido da capacidade de poder

consultar as suas ordens de trabalho quando nao dispoe de uma ligacao transferindo

apenas o essencial para isto seja possıvel

A pagina inicial do WOW apresenta um resumo das ordens de trabalho abertas

ndash enviadas e recebidas ndash que se pretende permitir visualizar offline (ver Figura 46)

Como prova de conceito foi efectuada uma abordagem pragmatica das varias possi-

bilidades descritas na seccao 42

461 Modo ldquoaplicacao deciderdquo com deteccao automatica da ligacao

A primeira abordagem estudada para a disponibilizacao das funcionalidades of-

fline foi o modo ldquoaplicacao deciderdquo com deteccao automatica de ligacao apresentado

na seccao 422 Para que isto seja possıvel foi implementado um mecanismo de ver-

ificacao periodica do estado da ligacao atraves de chamadas Ajax assıncronas O

resultado destes pedidos determina o estado da aplicacao executando as tarefas de

sincronizacao de dados sempre que pertinente Este metodo embora imediato e

simples de implementar depressa se revelou inadequado para o projecto devido ao

elevado consumo de recursos do servidor que a utilizacao intensiva faz esperar a

comunidade da plataforma WOW no principal cliente excede os 7000 utilizadores

Foi estimado que para uma utilizacao de fluidez aceitavel o estado da ligacao deveria

ser testado a cada cinco segundos Assumindo uma adesao (previsao pessimista) de

1 aos servicos offline assistir-se-ia a cerca de 840 pedidos adicionais por minuto

Mas o principal problema desta aproximacao prende-se com o facto de a ver-

ificacao ser feita em intervalos de tempo discretos levando a possibilidade de a

aplicacao poder ter em dado momento uma representacao errada do seu estado

real da ligacao Este problema e ilustrado na Figura 48 onde se ve claramente a

discrepancia entre o estado real da ligacao e a representacao interna que esta tem

Note-se que nesta janela de tempo qualquer accao do utilizador que exija uma

resposta sıncrona do utilizador leva-lo-a para um ldquobeco sem saıdardquo onde nao tera

43

Desenvolvimento

Figura 46 A pagina inicial do WOW apresenta um resumo das ultimas ordens de trabalhoenviadas e recebidas Na imagem pode-se observar a transicao do estado online para offline

acesso a versao offline porque a aplicacao nao fez a transicao automatica nem acesso

a versao online porque na verdade nao possui uma ligacao O que acontecera nesta

situacao sera uma tentativa de acesso ao servidor por parte da aplicacao numa

altura em que este se encontra indisponıvel e o resultado sera uma mensagem de

ldquopedido excedeu o tempordquo apresentado pelo browser Este e um estado sem retorno

porque apos o browser apresentar esta mensagem todos os recursos JavaScript ficam

indisponıveis tornando impossıvel o regresso ao estado anterior ou o tratamento do

erro de qualquer outra forma No entanto as chamadas Ajax podem ser tratadas de

forma especial para a eventualidade de falha e portanto nao constituem problema

44

Desenvolvimento

Figura 47 Ilustracao do funcionamento do Gears numa web application que utiliza ummotor Ajax Os pedidos HTTP ou HTTPS podem ser interceptados e tratados localmenteou podem ser feitos a uma maquina remota consoante se verificarem ou nao as condicoesexpressas no ponto 311 E representado um acesso a uma base de dados local (fornecidapelo Gears) mas a sua utilizacao e opcional

462 Implementacao do modo ldquoutilizador deciderdquo

Este modo de execucao foi ja descrito na seccao 421 e a sua principal carac-

terıstica e ser o utilizador a decidir se a aplicacao deve utilizar um servidor remoto

ou a maquina local como fornecedor de dados

Relativamente ao WOW o WOW Offline na vertente ldquoutilizador deciderdquo vem

alterar os seus casos de uso dando ao utilizador a possibilidade de alterar o estado

de execucao da aplicacao (entre online e offline) Resta dizer que no modo online se

mantem todas as funcionalidades anteriores e que no modo offline torna-se possıvel

visualizar os conteudos da pagina principal do WOW (Figura 46) e os detalhes das

ordens de trabalho (Figura 49) tal como expressa a Figura 410

Esta aproximacao foi utilizada na prova de conceito do WOW adicionando um

controlo a interface desta aplicacao que permite ao utilizador alternar entre os esta-

dos online e offline Na transicao de online para offline sao descarregados os recursos

necessarios para a execucao desta aplicacao sem recorrer a Internet Para o fazer

45

Desenvolvimento

Figura 48 Neste exemplo do modo ldquoaplicacao deciderdquo o teste da ligacao e feito e feito acada cinco segundos O resultado deste teste nao reflecte sempre o estado real da aplicacaopodendo levar a aplicacao a ter comportamentos indesejaveis Na figura assinala-se umperıodo de tempo no qual a representacao interna do estado da ligacao nao corresponde arealidade

e utilizado um recurso ResourceStore e um ManagedResourceStore (introduzidos

em 311) O primeiro e utilizado para armazenar a pagina principal do WOW ndash do-

ravante designada por homejsp ndash e o segundo e utilizado para armazenar imagens

folhas de estilo CSS e scripts JavaScript

Para a implementacao deste modo de execucao foram identificadas as seguintes

tarefas

1 Guardar informacao que permita a recriacao das paginas que se pretende

disponibilizar offline (utilizando o Gears)

2 Disponibilizar um controlo que permita alterar o estado de execucao atraves

da interaccao com a pagina principal

3 Durante a sincronizacao de dados apresentar o progresso da transferencia de

dados

O primeiro passo consistiu na identificacao de todos os conteudos que sao necessarios

transferir para a execucao offline Foi utilizado um recurso do Gears do tipo

ManagedResourceStore que recorre a um ficheiro manifesto para identificar to-

dos os ficheiros que deve transferir Este recurso e gerido automaticamente pelo

Gears transferindo para o cliente a versao mais recente sempre que e necessario

isto e sempre que exista um ficheiro manifesto com uma identificacao de versao que

seja diferente da actualmente disponıvel no cliente Uma vez identificados todos

ficheiros necessarios para a execucao offline num (ou mais) ficheiros manifesto o

Gears encarrega-se da sua actualizacao mas o preenchimento destes ficheiros man-

ifesto e manual o que se traduz num cuidado extra na manutencao da aplicacao

A forma como esta informacao e guardada deve tambem ser cuidadosamente

estudada A opcao mais flexıvel passa por utilizar o modulo Database apresentado

na seccao 311 e guardar a informacao de uma forma relacional Para a recriacao

das paginas pode ser disponibilizada uma versao HTML da pagina que funciona

46

Desenvolvimento

Figura 49 Pagina de visualizacao do detalhe de uma ordem de trabalho

como template nao possui quaisquer dados e e utilizada apenas em modo offline E

preenchida para cada pedido retirando os dados relevantes da base de dados

O modelo de dados do WOW torna esta opcao extremamente trabalhosa uma

vez que as entidades envolvidas na geracao de cada pagina de informacao sobre

cada ordem de trabalho tem relacoes de dependencia complexas seguindo padroes

muito variaveis Por exemplo em cada ordem de trabalho existe um formulario que

permite a sua progressao de estado com diversos campos opcionais e obrigatorios

este formulario e definido pelo administrador e esta relacionado nao apenas com o

tipo de ordem de trabalho mas tambem com o estado actual em que esta se encontra

e a accao que se pretende realizar O elevado numero de combinacoes de tipos de

ordem de trabalho estados e accoes que existem num dado momento juntamente

com a sua possibilidade de alteracao obrigariam a implementacao de uma logica de

negocio complexa o que esta fora do ambito deste projecto

47

Desenvolvimento

Figura 410 Esquema UML que expressa os casos de uso do WOW Offline no modoldquoutilizador deciderdquo

463 Especificacao do modo ldquoaplicacao assume o estado offlinerdquo

A aproximacao para o modo ldquoaplicacao assume o estado offlinerdquo foi tambem

dividida em varias tarefas

1 Guardar informacao que permita a recriacao da pagina principal do lado do

cliente no estado offline (utilizando o Gears)

2 Dotar a aplicacao do cliente de um mecanismo de deteccao da ligacao

3 Identificar os ldquomomentos chaverdquo em que devera ocorrer sincronizacao de dados

4 Implementar a sincronizacao de dados

A sincronizacao de dados deve ser feita em ambas as transicoes online-offline e

offline-online quer para transferir novos dados do servidor (os pedidos podem ser

alterados por outros utilizadores) quando se transita do estado quer para comunicar

eventuais alteracoes feitas em modo offline

Relativamente ao WOW o WOW Offline na vertente ldquoaplicacao assume o es-

tado offlinerdquo vem alterar os seus casos de uso dando ao utilizador a possibilidade

de activar esta funcionalidade A partir do momento que a funcionalidade esta ac-

tivada o utilizador deve tambem ter a possibilidade de gerir algumas preferencias

relacionadas com privacidade de dados Devera ter a hipotese de desactivar o ar-

mazenamento local e de remover todos os dados ja armazenados tal como descrito

na Figura 411

48

Desenvolvimento

Figura 411 Esquema UML que expressa os casos de uso do WOW Offline no modoldquoutilizador deciderdquo

A primeira vez que o WOW Offline e acedido por um cliente e caso seja detec-

tada a presenca do Gears todos os recursos necessarios a sua execucao sao trans-

feridos Todos os acessos posteriores serao feitos a estes recursos locais (recorda-se

que o Gears pode ser utilizado para os manter actualizados recorrendo ao Managed-

ResourceStore 311)

Atraves do JavaScript e possıvel interceptar os eventos de load e unload da

pagina que sao despoletados sempre que ocorre um re-acesso da mesma (incluindo

a accao refresh comum dos browsers) sempre que esta e abandonada ou ainda ou

ainda se a janela for encerrada

Tal como sugerido na seccao 462 a camada de interface desta aplicacao (cada

pagina individual em HTML) devera ser implementada como sendo um template

para apresentacao de dados sendo totalmente preenchida atraves de funcoes em

JavaScript O objectivo deste ponto e criar um padrao de dados que permita ao

JavaScript preencher os dados em cada pagina (template) independentemente de

qual seja a fonte ndash o servidor remoto ou a maquina local tal como exemplificado

no diagrama da Figura 412 Na figura a aplicacao recorre ao servidor remoto para

obter os dados pretendidos quando se encontra na presenca de uma ligacao mas

para dados que exijam uma carga de processamento pelo servidor este acto pode ser

49

Desenvolvimento

Figura 412 Esquema UML que expressa o acto de recolha de dados em modo online eoffline recorrendo ao servidor (modo online) e ao sistema de armazenamento de dadoslocal fornecido pelo Gears (modo offline)

substituıdo pelo envio de um campo de controlo que se destina a aferir se os dados

locais se encontram actualizados No caso de estarem actualizados a comunicacao

com o servidor pode ser substituıda por uma query a base de dados local

50

Capıtulo 5

Resultados e Futuros

Desenvolvimentos

Todo o estudo feito sobre o tema OWA foi ja abordado ao longo do documento

Neste capıtulo apresentam-se os resultados obtidos na implementacao da prova de

conceito que visava compreender a melhor forma de disponibilizar uma versao of-

fline no WOW uma plataforma de gestao de ordens de trabalho ja existente de-

senvolvida pela Critical Software SA

51 Resultados Obtidos

Os resultados obtidos neste projecto sao extremamente satisfatorios uma vez

que o estudo do tema OWA e a implementacao de uma prova de conceito que o

ilustrasse foi conseguido com sucesso

A funcionalidade offline foi adicionada ao produto WOW da Critical Software

SA permitindo a visualizacao de ordens de trabalho e dos seus detalhes mesmo na

ausencia de uma conexao activa a Internet Embora para a solucao implementada

tenha sido utilizada uma abordagem do tipo ldquoutilizador deciderdquo pretende-se que esta

seja convertida para ldquoaplicacao deciderdquo ou mesmo para uma aproximacao hıbrida

semelhante a utilizada pelas aplicacoes estudadas nas seccoes 351 e 352

Para a sua implementacao descrita no capıtulo 4 foram tomadas decisoes de or-

dem pratica que permitissem tornar o trabalho exequıvel nos prazos dados Tentou-

se sempre que estas decisoes afectassem o mınimo em termos de desempenho e de

experiencia para o utilizador Considera-se que a implementacao do modo offline

com uma transicao entre modos do tipo ldquoutilizador deciderdquo (ver seccao 42) reflecte

o compromisso entre o desempenho pretendido e os recursos disponıveis e para alem

51

Resultados e Futuros Desenvolvimentos

de ser um exemplo eficaz das possibilidades que as OWA podem trazer a aplicacao

WOW desenvolvida pela Critical Software e tambem um estudo que pode ser uti-

lizado para analisar a implementacao desta tecnologia noutros produtos da mesma

empresa

Note-se que o principal objectivo do trabalho era ganhar familiaridade com este

tema entender as suas vantagens e desvantagens e compreender as suas limitacoes

Tudo indica que existam varias possibilidades de implementacao deste paradigma

noutros produtos da Critical Software que pela sua natureza podem tambem tirar

partido da execucao offline

52 Trabalho Futuro

O desenvolvimento do conceito e formas de implementacao de OWA continua

em forte desenvolvimento no entanto a sua adopcao ainda nao e generalizada A

dificuldade da sua implementacao em web applications ja existentes e o principal

obstaculo a sua maior divulgacao

Ha tambem um factor que deve ser tido em consideracao a manutencao de

codigo A implementacao de uma versao offline de uma web application requer

a implementacao das mesmas regras de negocio (ou de uma versao simplificada)

utilizadas no servidor Para que isto seja possıvel e necessario ter em conta a

capacidade de processamento do cliente e o factor de duplicacao de codigo que

tornara a aplicacao mais difıcil de manter uma vez que uma alteracao a logica de

negocio do servidor implica tambem uma alteracao a sua versao offline

A prova de conceito implementada permite ja a visualizacao offline dos pedidos

abertos (enviados e recebidos) que constam na pagina principal (este numero e

fixo e pode ser alterado pelo administrador) Uma funcionalidade desejavel seria a

possibilidade de interaccao com a aplicacao em modo offline e sincronizacao com o

servidor quando existisse uma ligacao disponıvel

Foi estudada a utilizacao do modo de execucao ldquoaplicacao assume o estado of-

flinerdquo descrito em 423 e esta seria a forma desejavel para o WOW Offline no

entanto para que esta opcao seja viavel sera necessaria a implementacao de uma

forma eficiente de sincronizacao e armazenamento de dados de uma forma relacional

Para atingir este objectivo podera ser seguida uma polıtica de automacao do pro-

cesso no qual a versao online da aplicacao gera scripts de criacao para as tabelas

necessarias na base de dados da versao offline (nao existe nenhuma ferramenta para

o fazer portanto seria necessaria a sua implementacao) e no qual as paginas HTML

disponibilizadas pelo servidor aos clientes web (browser) servem como templates de

apresentacao de informacao e sao preenchidas de forma semelhante pelo servidor ndash

quando a aplicacao estiver online ndash ou pelo cliente atraves de funcoes em JavaScript

52

Resultados e Futuros Desenvolvimentos

ndash quando a aplicacao estiver offline No entanto no WOW devido a quantidade de

informacao tratada e devido as complexas relacoes entre as diferentes entidades e

de esperar que a complexidade da implementacao de um mecanismo deste tipo torne

esta aproximacao demasiado custosa

O HTML 5 embora um forte candidato ainda nao esta suficientemente desen-

volvido A sua especificacao ainda tem o caracter de Draft (rascunho) e esta sujeita

a modificacoes e a aceitacao e implementacao por parte dos browsers e portanto

de momento foi desconsiderado No entanto no futuro se esta especificacao atingir

um estado de maturidade que permita a sua adopcao devera ser considerada como

um possıvel caminho a seguir

53

Resultados e Futuros Desenvolvimentos

54

Capıtulo 6

Conclusoes

Neste capıtulo sao apresentadas as conclusoes do projecto e consideracoes finais

relativamente a tecnologia estudada

61 Conclusoes

O rapido desenvolvimento tecnologico faz prever que a disponibilidade de ligacao

a Internet seja cada vez mais facil e mais rapido mas vao continuar a existir lugares

onde o acesso e limitado e onde as OWA podem desempenhar um papel de relevo

Por outro lado esta tecnologia pode tambem ser utilizada para melhorar o desem-

penho de paginas web com uma necessidade elevada de imagens ou outros recursos

dispendiosos em termos de espaco e foram ate estudados dois exemplos da utilizacao

desta vertente desta tecnologia em 353

Acredita-se que as OWAs vem responder a uma necessidade real por parte das

web applications actuais e que a evolucao que representam se compara a que se

assistiu dos thin-clients para os fat-clients em termos de autonomia do servidor

A capacidade de oferecer conteudos dinamicos no browser independentemente da

existencia de uma ligacao reune as vantagens tıpicas das web applications como

ausencia de instalacao e actualizacoes instantaneas com as vantagens das aplicacoes

de desktop em capacidade de processamento e armazenamento de dados na maquina

local

As tecnologias disponıveis ate a data estudadas no ambito deste projecto que

permitem o desenvolvimento de OWAs e que apresentam maior maturidade sao o

Gears e o Adobe AIR Ambas se apresentam sobre a forma de plugins que necessitam

de uma instalacao extra para poderem ser utilizadas Apesar de esta instalacao ser

55

Conclusoes

apenas necessaria uma vez podera constituir um factor de desencorajamento a sua

adopcao

O HTML 5 uma especificacao abordada neste documento na seccao 34 podera

ser uma alternativa que oferece funcionalidades offline a uma web application sem a

necessidade de qualquer instalacao no entanto esta especificacao ainda nao foi aceite

pelos principais browsers ndash o documento que define o HTML 5 ainda tem o estatuto

de Draft ndash e ainda nao e possıvel antecipar quando e que isto podera acontecer

Um dos problemas que surge frequentemente na implementacao de uma versao

offline para uma web application e a necessidade de sincronizacao de dados Quando

a informacao pode ser alterada por varios utilizadores simultaneamente e necessario

prever os conflitos que daı podem surgir e dotar a aplicacao de uma forma de os

resolver ou alertar o utilizador para a necessidade de alteracao dos dados

Em conclusao todos os objectivos propostos para este projecto foram atingidos

A prova de conceito implementada reflecte de forma clara as possibilidades oferecidas

pela tecnologia OWA e sera utilizado no futuro para compreender a melhor forma

de o implementar de forma definitiva no WOW

56

Referencias

[Ada08] Lucas Adamski Introducing Adobe AIR security model Fevereiro de2008 Disponıvel em httpwwwadobecomdevnetairarticles

introduction_to_air_securityhtml acedido em Marco de 2008

[Ado08] Adobe Adobe AIR 10 Security White Paper 2008 Disponıvel emhttpdownloadmacromediacompubairdocumentation1air_

securitypdf acedido em Marco de 2008

[Alm08] Dion Almaer Gears as a bleeding-edge html 5 implementa-tion March 2008 Disponıvel em httpalmaercomblog

gears-as-a-bleeding-edge-html-5-implementation acedido emMarco de 2008

[BL96] Tim Berners-Lee The world wide web Past present and future Agostode 1996 Disponıvel em httpwwww3orgPeopleBerners-Lee

1996ppfhtml acedido em Abril de 2008

[CDGH08] Mike Chambers Daniel Dura Dragos Georgita and Kevin Hoyt AdobeAIR for JavaScript Developers OrsquoReilly Media 2008 Disponıvel emhttponairadobecomfilesAIRforJSDevPocketGuidepdf ace-dido em Abril de 2008

[Con99] Jim Conallen Modeling Web Application Architectures with UML Junho1999 Disponıvel em httpwwwumlorgcnUMLApplicationpdf

webappspdf acedido em Maio de 2008

[Ent07] Entrust What is a public key information 2007 Disponıvel em http

wwwentrustcompkihtm acedido em Junho de 2008

[Gar05] Jesse James Garret Ajax A new approach to web applicationsFebruary 2005 Disponıvel em httpwwwadaptivepathcomideas

essaysarchives000385php acedido em Marco de 2008

[Greon] Philip Greenspun Philip and Alexrsquos Guide to Web Publishing 2003(last revision) Disponıvel em httpphilipgreenspuncompandaacedido em Junho de 2008

[Gro02a] App Design Group Thick vs thin client comparison 2002 Disponıvelem httpwwwdonjacobsvwcomimagesweekendspecials

Thick-vs-Thinpdf acedido em Junho de 2008

57

REFERENCIAS

[Gro02b] Technical Research Group Thin Client Tecnhology - WhitePaper 2002 Disponıvel em httpwwwpicktrgcompubs

thinclientwhitepaperpdf acedido em Junho de 2008

[Gro08] Miniwatts Marketing Group World internet usage March 2008Disponıvel em httpwwwinternetworldstatscomstatshtm ace-dido em Abril de 2008

[Hic08] Ian Hickson HTML 5 Draft Recommendation 2008 Disponıvelem httpwwwwhatwgorgspecsweb-appscurrent-work ace-dido em Marco de 2008

[Kha] Olga Kharif Top 10 municipal wifi plans Disponıvel em http

imagesbusinessweekcomss0608muni_wifiindex_01htm ace-dido em Marco de 2008

[Lab07] Mozilla Labs Prism Outubro 2007 Disponıvel em httplabs

mozillacom200710prism acedido em Marco de 2008

[Loo06] Chris Loosley Rich Internet ApplicationsDesign MeasurementandManagement Challenges 2006 Disponıvel em httpwwwkeynote

comdocswhitepapersRichInternet_5pdf acedido em Maio de2008

[Mic08] Microsoft Introduction to Occasionally Connected Applications us-ing Sync Services for ADONET 2008 Disponıvel em httpmsdn

microsoftcomen-ussyncbb887608aspx acedido em Junho de2008

[Nao08] Erica Naone Offline web applications Abril 2008 Disponıvelem httpwwwtechnologyreviewcomread_articleaspxch=

specialsectionsampsc=emerging08ampid=20245 acedido emAbril de 2008

[NJN00] Jason Nieh Yang S Jae and Naomi Novik A comparison of thin-clientcomputing architectures 2000 Disponıvel em httpwwwnclcs

columbiaedupublicationscucs-022-00pdf acedido em Maio de2008

[OrsquoR06] Tim OrsquoReilly Web 20 compact definition Trying again Dezembro2006 Disponıvel em httpradaroreillycomarchives200612

web-20-compact-definition-tryihtml acedido em Marco de 2008

[OrsquoR09] Tim OrsquoReilly What is Web 20 Design patterns and business modelsfor the Next Generation of Software 20053009 Disponıvel emhttpwwworeillynetcompubaoreillytimnews200509

30what-is-web-20html acedido em Marco de 2008

[Rus06] Alex Russel Comet Low latency data for the browser March Marco2006 Disponıvel em httpalexdojotoolkitorgp=545 acedidoem Marco de 2008

58

REFERENCIAS

[Sad97] Darleen Sadoski Clientserver software architecturesndashan overviewAgosto 1997 Disponıvel em httpwwwseicmuedustr

descriptionsclientserver_bodyhtml acedido em Junho de2008

[Sch96] George Schussel Clientserver past present and future 1996

[Smi07] Kevin C Smith Css filters - will the browser apply the rule July 2007Disponıvel em httpcentriclecomrefcssfilters acedido emMarco de 2008

[vK08] Anne van Kesteren The XMLHttpRequest Object W3C Work-ing Draft 15 Abril 2008 Disponıvel em httpwwww3orgTR

XMLHttpRequest acedido em Abril de 2008

[Wil06] Greg Wilkins Why ajax comet July Julho 2006 Disponıvel emhttpwwwwebtidecomdownloadswhitePaperWhyAjaxhtml ace-dido em Abril de 2008

59

REFERENCIAS

60

Anexo A

Screenshots

Algumas imagens de aplicacoes que utilizam funcionalidades offline ilustrativasda tecnologia abordada neste documento

Figura A1 Dialogo apresentado ao utilizador na primeira activacao das funcionalidadesoffline no Google Docs amp Spreadsheets

61

Screenshots

Figura A2 Na activacao das funcionalidades offline e tambem oferecida a possibilidadeda criacao de alguns atalhos por exemplo no ambiente de trabalho

Figura A3 O Google Docs mantem a todo o momento a possibilidade de alteracao destasdefinicoes ou da anulacao dos servicos offline para um dado computador

62

Screenshots

Figura A4 Apos a instalacao do Gears qualquer visita ao Remember The Milk despoletauma sincronizacao que ocorre automaticamente e sem necessidade de intervencao por partedo utilizador

Figura A5 Apos completar a sincronizacao de dados mesmo que a ligacao a Internetseja perdida o Remember the Milk continua disponıvel no browser (com excepcao dasfuncionalidades que pela sua natureza exigem uma ligacao como por exemplo partilhade tarefas e envio de convites)

63

Page 6: O ine Web Applications

Abstract

The main purpose of this project was to study the Offline Web Applications(OWAs) and its implementation in existent web applications With this goal in minda study was conducted to use this technology in WOW an integrated platform forwork orders and work flow management developed by Critical Software over thelast 6 years and implemented a proof of concept which enables the use of a baseset of functionality for this application regardless of the internet connection state

The concept of OWAs is connected with internet technology and allows accessto a website using the browser even if a connection to the internet is not availableThis concept was considered by Technology Review as one of the most importantemerging technologies in the last quarter of 2007 [Nao08] This study conductedover the WOW platform is intended to aid in the comprehension of the problemsand solutions associated to the use and implementation of OWA as well as thebenefits that it brings to the end user

The Internet and Internet technologies are changing the way in which informa-tion is produced distributed and stored New web applications appeared with newcontent creation and edition functionalities and with it the advantage of infor-mation retrieval from any place and time became possible but with the conditionof Internet connection availability With Internet use growing every year [Gro08]content creation is starting to move to this new platform The adoption of web ap-plications for content creation and edition is becoming more popular and it showsa dependency of a connection that is not always present

The OWAs are a way to solve this problem putting on the client side part ofthe information that was traditionally stored on the server and allows it to be seenand manipulated and helps reducing the server load

This document intends to present different ways in which this technology canhelp web applications as we know them improving the their overall performance andgiving them the ability to run on a browser regardless of the Internet connectionavailability

iii

iv

Agradecimentos

A realizacao e os objectivos alcancados neste projecto nao teriam sido possıveissem a colaboracao de inumeras pessoas Agradeco profundamente a todos os quecontribuıram directa ou indirectamente para o seu sucesso

A minha orientadora Professora Teresa Galvao Dias e ao Project ManagerEngenheiro Marcus Neves que me conduziram e acompanharam no desenvolvimentodeste projecto

A toda a equipa do WOW em especial o Pedro Maurıcio Costa e o Fabio Matosque contribuıram para a minha a minha integracao na Critical Software e que sempresouberam responder a todas as minhas questoes

A todos os que constituem a CSW Porto pelo fantastico ambiente de amizadeque me proporcionaram

Aos colegas de curso e a todos os que me auxiliaram na revisao deste documento

Os meus sinceros agradecimentos

Joao Goncalves da Costa

v

vi

Conteudo

1 Introducao 111 Enquadramento 112 Motivacao 213 Ambito 314 Objectivos 315 Estrutura do documento 3

2 Enquadramento do Projecto 521 Evolucao das arquitecturas de software 5

211 Thin-clients 5212 Fat-clients 6213 Arquitecturas cliente-servidor 7

22 Evolucao na Internet 8221 Paginas web estaticas 9222 Paginas web interactivas e paginas web dinamicas 9223 Web 20 e Ajax 11

23 Offline Web Applications 1324 Comparacao 13

3 Estado da arte 1731 Gears 17

311 Arquitectura 17312 Goggle Gears em dispositivos moveis 20

32 Adobe AIR 20321 Seguranca 22322 Assinatura do codigo 22

33 Mozilla Prism 23331 XML User Interface Language 23332 Prism 25

34 HTML 5 2535 Web applications que usam funcionalidades offline 26

351 Google Reader e Google Docs 26352 Remember the Milk 27353 MySpace e WordPresscom 27

36 Escolha da tecnologia 28

vii

CONTEUDO

4 Desenvolvimento 3341 Como ficar offline 33

411 Funcionalidades disponıveis em modo offline 3442 Modos de execucao 35

421 Modo ldquoutilizador deciderdquo 36422 Modo aplicacao decide 36423 Modo ldquoaplicacao assume o estado offlinerdquo 37

43 Sincronizacao de dados 38431 Quando sincronizar 39

44 WOW 4045 Visao geral sobre a arquitectura do WOW 4146 WOW Offline 42

461 Modo ldquoaplicacao deciderdquo com deteccao automatica da ligacao 43462 Implementacao do modo ldquoutilizador deciderdquo 45463 Especificacao do modo ldquoaplicacao assume o estado offlinerdquo 48

5 Resultados e Futuros Desenvolvimentos 5151 Resultados Obtidos 5152 Trabalho Futuro 52

6 Conclusoes 5561 Conclusoes 55

Referencias 59

A Screenshots 61

viii

Lista de Figuras

21 Arquitectura de um sistema thin-client em duas camadas (a esquerda)e em tres camadas (a direita) Note-se a inclusao do servidor (main-frame) na definicao das camadas desta arquitectura devido a fortedependencia cliente-servidor 9

22 Arquitectura de um fat-client em duas camadas (a esquerda) e emtres camadas (a direita) 10

23 Comparacao do modelo de web aplications sıncrono paginas estaticase interactivas abordados nas seccoes 221 e 222 com o modelo deweb applications Ajax (assıncrono) abordado na seccao 223 Figuraadaptada de http www adaptivepath com 15

31 Esquema UML do processo efectuado pelos recursos do Gears do tipoManagedResourceStore para a actualizacao dos conteudos definidosno ficheiro manifesto 29

41 Exemplo de uma arquitectura de uma web application sem uma ca-mada de abstraccao de dados Figura adaptada de http gears

google com 33

42 Exemplo de uma arquitectura de uma web application com uma ca-mada de abstraccao de dados Figura adaptada de http gears

google com 34

43 Exemplo de uma arquitectura de uma web application com uma ca-mada de abstraccao de dados e um data switch Figura adaptada dehttp gears google com 35

44 Esquema grafico ilustrando uma OWA executando no browser uti-lizando um modo de execucao do tipo ldquoaplicacao deciderdquo com de-teccao automatica do estado da ligacao via pedidos Ajax assıncronosa cada cinco segundos 37

45 Detalhe de um conjunto possıvel de estados e respectivas transicoespara uma dada ordem de trabalho no WOW desde a sua submissaono sistema ate a sua conclusao em fecho ou cancelamento Esta figurarepresenta apenas um exemplo ja que o mapa de estados para umaordem de trabalho e dinamico e pode ser alterado por um admin-istrador Figura retirada de uma brochura promocional do WOWCritical Software SA 41

ix

LISTA DE FIGURAS

46 A pagina inicial do WOW apresenta um resumo das ultimas ordensde trabalho enviadas e recebidas Na imagem pode-se observar atransicao do estado online para offline 44

47 Ilustracao do funcionamento do Gears numa web application que uti-liza um motor Ajax Os pedidos HTTP ou HTTPS podem ser inter-ceptados e tratados localmente ou podem ser feitos a uma maquinaremota consoante se verificarem ou nao as condicoes expressas noponto 311 E representado um acesso a uma base de dados local(fornecida pelo Gears) mas a sua utilizacao e opcional 45

48 Neste exemplo do modo ldquoaplicacao deciderdquo o teste da ligacao e feitoe feito a cada cinco segundos O resultado deste teste nao reflectesempre o estado real da aplicacao podendo levar a aplicacao a tercomportamentos indesejaveis Na figura assinala-se um perıodo detempo no qual a representacao interna do estado da ligacao nao cor-responde a realidade 46

49 Pagina de visualizacao do detalhe de uma ordem de trabalho 47410 Esquema UML que expressa os casos de uso do WOW Offline no

modo ldquoutilizador deciderdquo 48411 Esquema UML que expressa os casos de uso do WOW Offline no

modo ldquoutilizador deciderdquo 49412 Esquema UML que expressa o acto de recolha de dados em modo

online e offline recorrendo ao servidor (modo online) e ao sistemade armazenamento de dados local fornecido pelo Gears (modo offline) 50

A1 Dialogo apresentado ao utilizador na primeira activacao das funcional-idades offline no Google Docs amp Spreadsheets 61

A2 Na activacao das funcionalidades offline e tambem oferecida a possi-bilidade da criacao de alguns atalhos por exemplo no ambiente detrabalho 62

A3 O Google Docs mantem a todo o momento a possibilidade de alteracaodestas definicoes ou da anulacao dos servicos offline para um dadocomputador 62

A4 Apos a instalacao do Gears qualquer visita ao Remember The Milkdespoleta uma sincronizacao que ocorre automaticamente e sem ne-cessidade de intervencao por parte do utilizador 63

A5 Apos completar a sincronizacao de dados mesmo que a ligacao aInternet seja perdida o Remember the Milk continua disponıvel nobrowser (com excepcao das funcionalidades que pela sua naturezaexigem uma ligacao como por exemplo partilha de tarefas e enviode convites) 63

x

Lista de Tabelas

21 Comparacao entre thin-clients e fat-clients 7

31 Comparacao das funcionalidades oferecidas pelo Adobe AIR para asplataformas web e desktop 30

32 Resumo da utilizacao de tecnologias OWA em algumas web applica-tions consideradas na analise do estado da arte 31

xi

LISTA DE TABELAS

xii

Glossario

fat-client Cliente que nao depende totalmente de umservidor central para as suas actividadesde processamento e possui frequentementedispositivos de armazenamento de dados

6ndash8

thin-client Cliente que depende de um servidor centralpara as suas actividades de processamento

5ndash8

web application Sistema web (servidor rede HTTPbrowser) onde accoes do utilizador(navegacao e introducao de informacao)afectam o estado logico da aplicacao

i iii1ndash311ndash1517ndash1921ndash232728 3336ndash3842 5556

API Application Programming Interface 10 1718 2326 28

ASP Linguagem interpretada pelo servidorque permite a criacao de paginas webdinamicas Desenvolvida pela Microsoft

11

BSD Berkeley Software Distribution 28

CSS Cascading Style Sheets 12 2021 2324 46

DHTML Dynamic HyperText Transfer Protocol 24DOM Document Object Model 10 12

20 2324

DTD Document Type Definition 24

xiii

Glossario

ECMAScript Padrao de linguagem de programacaodefinido pela Ecma International que orig-inou o JavaScript e o JScript

24

Flash Conteudo interactivo de um ficheiro emformato SWF E desenvolvido pela Adobee visualizado atraves do Adobe FlashPlayer

21

Flex Framework baseada em XML e Action-Script desenvolvida pela Adobe para a pro-gramacao de Rich Internet Applications(RIA)

21

GPL GNU General Public License 23

HTML HyperText Markup Language 1 10ndash12 2124ndash2649

HTTP HyperText Transfer Protocol 2 26

JMS E uma API em Java que permite a troca demensagens entre componentes de software

42

JSON JavaScript Object Notation permite atroca de dados codificados num formatode texto de simples leitura

12 1828 34

LGPL GNU Lesser General Public License 23

Mozilla Prism Browser simplificado e ldquointerpretadorrdquo deeXtensible User Interface Language (XUL)(tambem designado por XULRunner) queacolhe web applications sem a interfacegrafica habitual de um browser

25

MPL Mozilla Public License 23

OCA Occasionally Connected Application 39OWA Offline Web Application i iii

2ndash515 1725 2628 3133 3651 5255 56

PDF Portable Document Format 21

xiv

Glossario

PHP Linguagem interpretada pelo servidorque permite a criacao de paginas webdinamicas mas que pode tambem ser in-vocada a partir da linha de comandos

11

pagina web estatica Pagina web que devolve sempre a mesmaresposta a todos os pedidos para todos osutilizadores e em qualquer contexto

5 9

RIA Rich Internet Applications web appli-cations que apresentam funcionalidadessemelhantes as desktop applications masque mantem a informacao no lado do servi-dor

5 1520 28

RSS Really Simple Syndication 27

SLA Service Level Agreement 40SQLite Segundo a definicao oficial SQLite is a

software library that implements a self-contained serverless zero-configurationtransactional SQL database engine

17

SSB Site Specific Browser 25SSL Secure Sockets Layer 22SWF ShockWave Flash 21

URL Uniform Resource Locator 18

VPN Virtual Private Network 38

WOW Work Orders Web Plataforma de gestaode ordens de trabalho e do seu fluxo de-senvolvida pela Critical Software SA

i iii28 3340ndash434551ndash5356

WWW World Wide Web 11 1214

XBL eXtensible Binding Language 24XHTML eXtensible HyperText Markup Language 12XML eXtensible Markup Language 11 12

23 2428

XSLT eXtensible Stylesheet Language Transfor-mation

12

XUL eXtensible User Interface Language xiv23ndash25

xv

Glossario

xvi

Capıtulo 1

Introducao

Neste capıtulo enquadra-se o tema do projecto introduzindo alguns dos conceitos

nos quais se baseia Apresentam-se as motivacoes ambito objectivos e a estrutura

deste documento

11 Enquadramento

A Internet foi originalmente concebida para ser um espaco de partilha de in-

formacao onde pessoas (atraves de maquinas) pudessem comunicar Na sua origem

as paginas eram estaticas constituıdas por texto formatado em HyperText Markup

Language (HTML) e ligadas entre si [BL96] Hoje encontramos conteudos cada vez

mais complexos e dinamicos incluindo som vıdeo ou streams multimedia [Loo06] e

em 2005 foi introduzido por [OrsquoR09] o termo Web 20

De acordo com [Greon] um website pode pertencer a uma ou varias das seguintes

categorias

bull Documento ndash um website essencialmente estatico onde alteracoes a uma

parte do conteudo nao tem implicacoes no seu comportamento

bull Base de dados ndash um directorio de informacao organizada em categorias

bull Aplicacao ndash um website dinamico que utiliza uma linguagem executada ou

interpretada do lado do servidor e que processa as accoes ou informacao in-

troduzida pelo utilizador para fornecer um servico ou nova informacao

A ultima destas categorias constitui aquilo que e normalmente designado por

web application O conceito utilizado ao longo deste documento e o mesmo que

o introduzido por Jim Coallen em [Con99] que define web application como um

1

Introducao

sistema web (servidor rede HyperText Transfer Protocol (HTTP) browser) onde

accoes do utilizador (navegacao e introducao de informacao) afectam o estado logico

da aplicacao A sua definicao tenta estabelecer que uma web application e um

sistema de software com estado de negocio1 e que a sua interface de interaccao com

o utilizador e distribuıdo atraves de um sistema web

12 Motivacao

A quantidade de informacao que e produzida e armazenada com recurso a es-

tas web applications disponıveis online tais como e-mail blogues ou mesmo docu-

mentacao tornam por vezes a disponibilidade de ligacao uma condicao necessaria

a produtividade e como consequencia desta barreira muitos potenciais utilizadores

opoem-se a adopcao de produtos web em detrimento das tradicionais desktop appli-

cations

Assegurar o acesso a uma ligacao de Internet e hoje muito mais facil A Internet

movel e ja uma realidade e encontra-se amplamente divulgada mas continuam a

existir diversas situacoes nas quais os utilizadores estao privados de uma ligacao

a Internet tais como uma viagem de metro ou de aviao ou quando se encontram

deslocados do seu paıs de origem e nao possuem nenhum plano de subscricao

Uma OWA consiste numa web application que para alem de manter todas as

caracterısticas anteriores se mantem disponıvel mesmo na ausencia de uma ligacao

a Internet e surge como uma tentativa de estreitar as barreiras existentes entre a

web e o desktop Isto significa que devera existir um mecanismo capaz de assegurar

a manutencao do estado logico da aplicacao quando a ligacao com o servidor e

quebrada permitindo ao utilizador continuar a utilizar a aplicacao e que sera capaz

de informar o servidor do estado em que a aplicacao se encontra quando a ligacao for

reposta A principal vantagem que advem desta possibilidade e evidente eliminar

a necessidade da existencia de uma ligacao a Internet para que a aplicacao possa ser

utilizada

Por outro lado a vontade de integracao de funcionalidades tıpicas das desktop

applications nas web applications foi um dos principais factores que impulsionou o

desenvolvimento deste conceito uma vez que obrigou a uma reflexao ldquopara alem

do browserrdquo e a uma adaptacao das arquitecturas existentes que permitisse ou o

acesso a funcionalidades disponibilizadas pelo sistema operativo ou pelo menos a

funcionalidades semelhantes Pretende-se com esta aproximacao tornar possıveis

interaccoes entre o desktop e o browser tais como arrastar um ficheiro para um

formulario web de upload de conteudos melhor suporte para o historico do clipboard

ou ainda o acesso ao sistema de ficheiros local Atingir estes objectivos reflecte-se

1NT business state

2

Introducao

num novo paradigma que reune as vantagens das web applications tais como os

updates instantaneos ou o facto de nao ser necessaria nenhuma instalacao e das

desktop applications como por exemplo persistencia no armazenamento de dados

acesso a funcionalidades do sistema operativo ou integracao e interaccao com outras

aplicacoes sejam elas web applications ou desktop applications

13 Ambito

Este projecto foi realizado na Critical Software SA no ambito do Mestrado

Integrado em Engenharia Informatica e Computacao (MIEIC) da Faculdade de En-

genharia da Universidade do Porto (FEUP) entre os meses de Fevereiro e Julho de

2008

14 Objectivos

Sao objectivos deste projecto

1 Estudar e documentar o tema das OWAs acompanhando os ultimos desenvolvi-

mentos nesta materia

2 Analisar o estado da arte fazendo uma analise crıtica e objectiva sobre as

diversas metodologias existentes

3 Implementar uma prova de conceito que permita a execucao offline de uma

web application documentando todo o processo

4 Estudar a possibilidade de permitir interaccao com a aplicacao (insercoes e

alteracoes aos dados) em modo offline

Em resumo o objectivo deste projecto foi estudar documentar e implementar

uma prova de conceito relacionada com o tema Offline Web Applications (OWA)

Este tema embora nao seja totalmente novo ganhou destaque ao longo do ano de

2007 com o surgimento de diversas ferramentas que se destinam a aproximar web

applications das desktop applications

15 Estrutura do documento

Este documento esta organizado em diferentes seccoes apresentando o projecto

numa sequencia logica organizada da seguinte forma

No capıtulo 1 faz-se uma breve apresentacao do conceito OWAs e do contexto em

que surge Apresenta-se tambem a estrutura do documento e definem-se os

termos e acronimos utilizados

3

Introducao

No capıtulo 2 faz-se uma descricao da evolucao das tecnologias que antecedem as

OWAs e das vantagens e desvantagens de cada uma como forma de enquadra-

mento

No capıtulo 3 analisa-se o estado da arte nesta materia Introduzem-se diversas

tecnologias directamente relacionadas com o tema deste projecto exemplos de

aplicacoes que as usam e as razoes que fundamentam as escolhas de tecnologias

efectuadas

O capıtulo 4 contem o desenvolvimento do projecto Analisa-se a plataforma

WOW de gestao integrada de ordens de trabalho a tecnologia escolhida e

a forma como foi utilizada para implementar a capacidade de execucao offline

O capıtulo 5 descreve os resultado obtidos comparando-os com as expectativas

iniciais do projecto e apresenta desenvolvimentos futuros e possibilidades de

continuacaoaplicacao do conhecimento adquirido

No capıtulo 6 apresentam-se as conclusoes

4

Capıtulo 2

Enquadramento do Projecto

Neste capıtulo apresenta-se um breve resumo da evolucao das arquitecturas de

software cliente-servidor e a forma como estas se comparam a evolucao da Inter-

net procurando estabelecer uma analogia entre o percurso de ambas as tecnolo-

gias Compara-se o comportamento e arquitectura dos thin-clients as paginas web

estaticas a evolucao dos fat-clients as paginas interactivas Web 20 e Ajax e

defende-se que as OWA constituem um proximo passo logico e evolutivo aproxi-

mando a web do desktop Referem-se ainda os principais factores que justificam a

importancia das OWAs e a estreita relacao que tem com as Rich Internet Application

(RIA)s

21 Evolucao das arquitecturas de software

Os termos thin-client e fat-client sao utilizados quer para descrever arquitecturas

logicas (de software) quer para descrever arquitecturas fısicas (de hardware) Neste

capıtulo excepto quando seja dada indicacao em contrario estes termos referem-se

sempre a uma arquitectura logica

Adicionalmente quando se trata de arquitecturas cliente-servidor pode-se estu-

dar a arquitectura desenvolvida do sistema como um todo da arquitectura do servi-

dor ou da arquitectura do cliente Para evitar equıvocos em especial na seccao 213

especifica-se em cada caso qual o sistema estudado

211 Thin-clients

Um thin-client e um computador cliente ou software cliente que no contexto

de uma arquitectura cliente-servidor depende de um servidor central para as suas

5

Enquadramento do Projecto

actividades de processamento e proporciona um canal de entrada e saıda de in-

formacao entre o utilizador e o servidor remoto Este termo quando aplicado a

hardware refere-se habitualmente a um computador que se destina a ser utilizado

como cliente de rede sem armazenamento local e com capacidade de processamento

reduzida [Gro02b] mas o conceito que aqui se analisa refere-se a uma arquitectura

de software que remonta ao inıcio das aplicacoes cliente-servidor

No inıcio da historia da computacao terminais ligavam-se directamente a main-

frames responsaveis por todo o processamento Nesta arquitectura era necessario

desenvolver duas aplicacoes distintas uma aplicacao central no servidor (main-

frame) responsavel pela gestao de toda a informacao e por todas as operacoes de

comunicacao e uma aplicacao de visualizacao instalada no cliente (terminal) O

papel destes terminais era apenas disponibilizar ao utilizador um meio de comu-

nicacao (entrada e saıda) e apresentacao dos resultados do servidor Nao tinham

um papel activo no calculo nem na logica de negocio e frequentemente nao tinham

tambem nenhum mecanismo de armazenamento de dados

Como vantagens esta arquitectura apresenta uma reduzida necessidade de con-

figuracao e manutencao do lado do cliente Uma vez que o centro do processamento

e manipulacao de dados ocorre no servidor existe tambem uma centralizacao da

informacao [NJN00] que introduz um ponto crıtico de falha1 Actualizacoes e novas

funcionalidades sao faceis de distribuir uma vez que requerem apenas alteracoes no

servidor [Gro02a]

212 Fat-clients

Contrastando com os thin-clients nesta arquitectura os clientes implementam

ja uma parte da logica de negocio e sao responsaveis pelo processamento de dados

Estes fat-clients vieram responder a necessidade crescente de aplicacoes com um

nıvel de interactividade e capacidade de configuracao maior que as oferecidas pela

arquitectura thin-client descrita na seccao 211 Apesar de manterem a sua de-

pendencia do servidor podem tambem ser executados sem uma conexao activa uma

vez que dispoe de armazenamento de dados local o que lhes confere a capacidade

de persistencia de dados e do estado de execucao entre cada sessao

Foi disponibilizando este controlo sobre o estado da aplicacao bem como acesso

a recursos locais (por exemplo sistema de ficheiros e perifericos) que surgiram as

primeiras verdadeiras desktop applications No entanto cada cliente tinha que ser

separadamente instalado no computador pessoal de cada utilizador que pretendesse

utilizar ou interagir com a aplicacao e uma actualizacao ao servidor implicava in-

variavelmente uma actualizacao manual tambem no cliente Uma vez que nem todos

1NT single point of failure

6

Enquadramento do Projecto

Thin-clients Fat-clientsNao toma parte no processamento dedados nem possui acesso ao sistema deficheiros

Participa activamente no processa-mento de dados recorrendo ao sis-tema de armazenamento local para ar-mazenamento de dados

Nao mantem registo do estado logicoda aplicacao entre duas sessoes de uti-lizacao

O acesso ao armazenamento localpermite-lhe manter registo do estadologico da aplicacao entre duas sessoes

O thin-client nao necessita de qualquerinstalacao estando ldquopronto a utilizarrdquo

E geralmente necessario instalar aaplicacao para poder interagir com oservidor

Qualquer update no servidor reflecte-seimediatamente por todos os clientes

Embora a aplicacao cliente possa aler-tar para existencia de novas versoes asactualizacoes tem que ser manualmenteinstalados pelo cliente

O software do cliente destina-se apenasa apresentacao de dados e comunicacaocom o servidor sendo portanto de sim-ples implementacao

Como o software do cliente toma parteactiva no processamento de dadosa sua implementacao requer cuidadosadicionais

Grande mobilidade uma vez que todaa informacao e mantida no servidor

Parte da informacao podera estar ape-nas do lado cliente pelo que existemalgumas restricoes a sua mobilidade

Tabela 21 Comparacao entre thin-clients e fat-clients

os utilizadores actualizam regularmente as suas aplicacoes o servidor tem que estar

preparado para lidar com versoes antigas2 ou descontinuar os seus servicos a uma

parte da sua comunidade de utilizadores ate que estes actualizem os seus sistemas

Como os utilizadores passam a utilizar os seus recursos locais para armazenamento

de dados as alteracoes que nao sejam sincronizadas com o servidor estao apenas

disponıveis nos seus computadores pessoais o que introduz uma restricao a mobili-

dade

Pode-se afirmar que as vantagens dos thin-clients sao as desvantagens dos fat-

clients e que as vantagens dos fat-clients sao as vantagens dos thin-clients tal como

se ilustra na Tabela 21

213 Arquitecturas cliente-servidor

Introduzidos os termos thin-client e fat-client interessa reafirmar que ambos

podem ser vistos como arquitecturas cliente-servidor Um cliente define-se como

um solicitador de servicos e um servidor como um prestador de servicos tal como

definido por [Sch96] e [Sad97]

2NT backward compatibility

7

Enquadramento do Projecto

As arquitecturas cliente-servidor sao categorizadas pela modularizacao com que

sao desenhadas sendo consideradas as seguintes camadas

1 Interface grafica (front-end) atraves da qual os utilizadores interagem com

a aplicacao Quando este modulo e implementado separadamente dos outros

dois constitui uma aplicacao thin-client por si so uma vez que nao implementa

regras de negocio (embora possa definir validacoes de formularios de insercao de

dados por exemplo) A informacao introduzida pelo utilizador e enviada para

o servidor que processa o seu pedido e retorna uma resposta Este processo

repete-se ate que o utilizador atinja o seu objectivo ou se desligue do sistema

2 A logica de negocio tambem designada por camada intermedia que imple-

menta as regras de aceitacao e validacao de todos os dados introduzidos pelo

utilizador E tambem a plataforma de comunicacao que une a camada superior

de visualizacao com a camada de acesso a dados

3 A camada de dados inclui quer o sistema de persistencia de dados onde sao

armazenados os dados relevantes como tambem os mecanismos necessarios

para a sua pesquisa seleccao e alteracao

Os thin-clients quando observados no seu conjunto de cliente e servidor podem

ser vistos quer como sistemas de duas camadas quer como sistemas de tres camadas

dependendo apenas da forma como o servidor for implementado No caso de na

implementacao do servidor nao se distinguir a camada de acesso a dados da camada

da logica de negocio sao designados por sistemas de duas camadas Caso seja feita

esta distincao sao designados por sistemas de tres camadas Ambos os casos sao

ilustrados na Figura 21

Historicamente os fat-clients eram implementados numa arquitectura em duas

camadas Possuıam apenas um modulo de visualizacao de dados designado por

camada de interface e um modulo que implementava toda a logica de negocio e

regras de acesso a base de dados No entanto com a introducao de ligacoes mais

rapidas e de computadores pessoais com maior capacidade de processamento e so-

bretudo devido a complexidade crescente das aplicacoes a logica de negocio e a

camada de acesso a dados tornaram-se independentes Este modelo e designado por

arquitectura em tres camadas e e ilustrado na Figura 22

22 Evolucao na Internet

Ao analisar a evolucao das arquitecturas das aplicacoes desenvolvidas para a

Internet podemos encontrar um paralelismo com a historia da arquitectura de soft-

ware

8

Enquadramento do Projecto

Figura 21 Arquitectura de um sistema thin-client em duas camadas (a esquerda) e emtres camadas (a direita) Note-se a inclusao do servidor (mainframe) na definicao dascamadas desta arquitectura devido a forte dependencia cliente-servidor

221 Paginas web estaticas

Uma pagina web estatica devolve sempre a mesma resposta a todos os pedidos

para todos os utilizadores e em qualquer contexto utilizando o hipertexto como

forma de ligacao entre diversas paginas estaticas

A informacao e armazenada num servidor e o papel do cliente e apenas a apre-

sentacao da informacao Esta forma de disponibilizacao de informacao pode assim

ser comparada com os thin-clients descritos na seccao 211 o utilizador acede a

um website estatico para visualizar informacao sem que o cliente tome parte no

processamento A unica diferenca e que no caso da web estatica a informacao ap-

resentada e sempre a mesma enquanto que nos thin-clients era frequente existir a

possibilidade de insercao de dados no cliente e apos o seu processamento servidor

nova informacao poderia ser apresentada O hipertexto e utilizado para ligar as

paginas entre si numa rede de conteudos relacionados e a navegacao sıncrona era

feita atraves de cliques do rato a cada clique uma nova pagina era apresentada

Este modelo sıncrono e ilustrado na Figura 23

222 Paginas web interactivas e paginas web dinamicas

O JavaScript e uma linguagem interpretada de scripting que tem os browsers

como principal ambiente de acolhimento Os browsers utilizam uma Application

9

Enquadramento do Projecto

Figura 22 Arquitectura de um fat-client em duas camadas (a esquerda) e em tres camadas(a direita)

Programming Interface (API) publica para criar ldquoobjectosrdquo responsaveis por reflectir

e disponibilizar o Document Object Model (DOM) para o motor de JavaScript

A utilizacao mais frequente desta linguagem e a escrita de funcoes que sao em-

bebidas ou incluıdas em paginas web e que interagem com o DOM Uma vez que o

JavaScript e executado localmente (na maquina do cliente e nao no servidor) e capaz

de responder rapidamente a accoes do utilizador tornando a execucao de aplicacoes

no browser mais fluıdas o JavaScript pode tambem detectar accoes do utilizador

que o HTML nao pode tal como o pressionar de uma tecla

Em Dezembro de 1995 a Netscape Communications adicionou suporte para o

JavaScript no browser Netscape Navigator3 e em Agosto de 1996 o browser Internet

Explorer4 da Microsoft passou a tambem a suportar uma versao semelhante desta

linguagem (hoje todos os principais browsers suportam esta tecnologia)

Esta inovacao permitiu tornar os websites mais interactivos mas a sua utilizacao

esteve confinada apenas a este proposito durante um longo perıodo As paginas

passaram a responder activamente a accoes do utilizador (sendo uma das utilizacoes

3Netscape Communications ndash httpbrowsernetscapecom4Microsoft Internet Explorer ndash httpwwwmicrosoftcomwindowsproductswinfamilyie

10

Enquadramento do Projecto

mais vulgares a validacao de formularios) mas continuaram essencialmente estaticas

O JavaScript ainda nao era nesta altura utilizado para processar dados

Tambem nesta altura (1995ndash96) surgiram linguagens server-side como o PHP

Hypertext Preprocessor (PHP) e Active Server Pages (ASP) e o servidor passou a ter

um processamento de dados introduzidos pelo utilizador mais activo Generalizaram-

se as paginas dinamicas capazes de responder a insercao de dados ou outros pedidos

determinados por accoes do utilizador As paginas tornaram-se aplicacoes web ap-

plications

Uma definicao tradicional de web application e um conjunto de paginas web

logicamente agrupadas e geridas por uma unica entidade que tem como pontos de

entrada formularios de insercao de dados (web forms) Uma web application nao e

mais do que uma aplicacao que e acedida atraves de um browser Tem geralmente

uma arquitectura logica em tres (interface logica de negocio e camada de dados)

camadas e estao armazenadas num servidor

Ha dois tipos de web applications

bull Orientadas a apresentacao Sao web applications que geram paginas web in-

teractivas constituıdas por varios tipos de linguagens de anotacao (por exem-

plo HTML eXtensible Markup Language (XML)) e que apresentam conteudo

dinamico como resposta a pedidos efectuados pelo utilizador

bull Orientadas aos servicos Uma web application orientada aos servicos imple-

menta o ponto de acesso para um ou mais de um web service Sao geralmente

clientes de service oriented web applications

Uma vantagem significativa de implementar uma web application de forma a

suportar as funcionalidades padrao dos browsers e que estas terao o mesmo com-

portamento independentemente da plataforma e do browser a partir do qual serao

acedidas No entanto diferentes implementacoes de browsers devido a diferentes

interpretacoes dos padroes definidos tornam por vezes esta tarefa um pouco mais

complicada existindo inclusivamente na web guioes de compatibilidade para os difer-

entes browsers como [Smi07]

223 Web 20 e Ajax

O termo web 20 descreve uma tendencia de utilizacao e de design observada

na World Wide Web (WWW) com o objectivo de melhorar a criatividade partilha

de informacao e principalmente a colaboracao entre utilizadores Estes conceitos

levaram ao desenvolvimento e evolucao de comunidades online tais como redes so-

ciais wikis e blogues

11

Enquadramento do Projecto

O termo tornou-se mais conhecido apos a primeira conferencia OrsquoReilly Media

Web 20 em 2004 e apesar de sugerir uma nova versao da WWW nao se refere a

qualquer evolucao tecnologica mas apenas a alteracoes a forma como os utilizadores

se servem da web De acordo com Tim OrsquoReilly [OrsquoR06] ldquoWeb 20 e uma revolucao

na industria do software causada pela adopcao da web como uma plataforma e pela

tentativa de entendimento das regras para o sucesso nesta nova plataformardquo

O desenvolvimento da Web 20 serve-se muitas vezes de um outro conceito Ajax

O conceito que hoje conhecemos como Ajax muitas vezes incorrectamente de-

scrito como uma tecnologia foi originalmente criado para permitir o desenvolvimento

de web applications que se assemelhassem ainda mais a aplicacoes de desktop Este

conceito foi melhor descrito por [Gar05] como um conjunto de varias tecnologias

que podem ser utilizadas para melhorar a experiencia do utilizador de uma dada

web application introduzindo a capacidade assıncrona de envio de pedidos ou da

recepcao assıncrona de respostas As tecnologias mais frequentemente envolvidas

sao

bull eXtensible HyperText Markup Language (XHTML) e Cascading Style Sheets

(CSS) padrao para a apresentacao

bull interaccao dinamica atraves do DOM

bull troca e manipulacao de dados utilizando XML e eXtensible Stylesheet Lan-

guage Transformation (XSLT) ou JavaScript Object Notation (JSON)

bull pedidos assıncronos utilizando XMLHttpRequest [vK08]

bull JavaScript utilizado para integrar todas estas tecnologias

E importante frisar que o Ajax nao e um produto nem uma tecnologia E um

termo que descreve a utilizacao de um conjunto de tecnologias para o desenvolvi-

mento de web applications com um elevado grau de interactividade Comparativa-

mente as web applications tradicionais o Ajax introduz uma camada de visualizacao

diferente em tres importantes pontos

1 Do lado do cliente existe um motor que serve de intermediario entre a interface

da aplicacao e o servidor

2 A actividade do utilizador despoleta chamadas JavaScript em vez de um pedido

de pagina directamente ao servidor

3 Informacao codificada em XML em vez de paginas HTML e trocada entre o

servidor e o cliente

12

Enquadramento do Projecto

Isto significa que as paginas que utilizam Ajax contem um motor do lado do

cliente composto por um conjunto de funcoes JavaScript responsavel pela comu-

nicacao com o servidor e por actualizar a interface com o resultado dessa mesma

comunicacao

Na Figura 23 ilustra-se a natureza assıncrona do Ajax quando comparada com

as web applications tradicionais Como se pode observar adicionando um mecan-

ismo Ajax a uma web application eliminam-se diversos tempos de espera associados

a comunicacoes com o servidor uma vez que a interface nao fica ldquobloqueadardquo a es-

pera da resposta Obtem-se assim aplicacoes com um comportamento mais fluido

eliminando tempos de espera entre cada ldquocliquerdquo e melhorando a experiencia do

utilizador

23 Offline Web Applications

A informacao grafica (bem como folhas de estilo e scripts) tais como as ima-

gens que constituem o visual de uma web application e ja tratada de forma especial

pelos cada vez mais avancados sistemas de cache (armazenamento temporario) dos

browsers Mas estes nao sao ainda capazes de guardar conteudo criado pelo uti-

lizador nem de apresentar informacao independentemente do estado da ligacao

Numa altura onde se fala de servicos de Internet wireless municipalizados [Kha]

comunicacoes 3G e ligacoes de banda larga a alta velocidade a ligacao a rede global

continua a nao estar permanentemente disponıvel para os utilizadores Na WWW

encontra-se uma importante parte da informacao e das aplicacoes utilizadas para

criar e editar conteudos Por vezes informacao vital para a produtividade pode

desaparecer subitamente do mapa de acesso de um utilizador quando este entra no

metro num aviao ou mesmo quando se desloca para uma cidade ou paıs diferente

do habitual onde nao subscreve um plano de acesso que lhe garanta a ligacao

Permitir o acesso offline a estes recursos assume assim a sua importancia porque

permitira estender o alcance da informacao a locais onde nunca esteve antes e per-

mitira tambem melhorar o desempenho das web applications colocando informacao

mais perto dos utilizadores reduzindo a transferencia de dados apenas ao essencial

24 Comparacao

Nas evolucoes descritas neste capıtulo 2 pode-se observar que existe um par-

alelismo entre a evolucao das arquitecturas tradicionais cliente-servidor e a evolucao

a que se assiste na web O comportamento e arquitectura dos thin-clients assemelha-

se ao das paginas estaticas no sentido em que o browser nao toma parte em qualquer

13

Enquadramento do Projecto

processamento e serve apenas como uma plataforma de interaccao com o servidor

tal como os clientes descritos na seccao 211

A sua proxima evolucao os fat-clients trouxeram parte da capacidade de pro-

cessamento para o lado do cliente Na web foi tambem esta a inovacao tecnologica

a que se assistiu com a evolucao das tecnologias que permitiram a criacao de ver-

dadeiras aplicacoes e com a introducao do Javascript no browser dando ao cliente

a capacidade de processamento de dados A necessidade da separacao do codigo

em camadas logicas advem da crescente complexidade das web applications Esta

pratica permite entre outras coisas melhorar o processo de desenvolvimento e a

capacidade de manutencao de uma aplicacao

Os fat-clients tem tambem a capacidade de armazenamento de dados o que

permite a persistencia de informacoes entre duas sessoes e que algumas operacoes

sejam executadas sem a necessidade de comunicacao com o servidor Este facto pode

tambem ser uma realidade nas web applications com a adopcao das tecnologias OWA

Neste momento assiste-se a uma utilizacao cada vez maior da web como uma

plataforma de desenvolvimento A capacidade de cooperacao na edicao de conteudos

e a mobilidade proporcionada por esta plataforma sao os principais factores que

alimentam esta mudanca e pela primeira vez as aplicacoes tradicionais tem com-

peticao vinda de web applications A prova do reconhecimento da web como plataforma

de desenvolvimento pode ser retirada da aposta de empresas como a Adobe e Mi-

crosoft que lancaram publicamente ferramentas web complementares a produtos

seus tradicionalmente associados ao desktop ndash Acrobatcom5 e Microsoft Office

Live6 Dotar estas web applications da capacidade de execucao offline significa

aproximar a web e o desktop reunindo ldquoo melhor de dois mundosrdquo

As vantagens da mobilidade possıvel atraves da web a cooperacao na criacao e

edicao de conteudos e a possibilidade de utilizar aplicacoes sempre actualizadas e

sem necessidade de instalacao sao algumas das principais vantagens que promovem

esta mudanca que devido as preocupacoes associadas a usabilidade e experiencia do

utilizador esta fortemente associada ao desenvolvimento de Rich Internet Applica-

tion (RIA)s

5Adobe Acrobatcom httpwwwacrobatcom6Microsoft ndash httpsmallbusinessofficelivecom

14

Enquadramento do Projecto

Figura 23 Comparacao do modelo de web aplications sıncrono paginas estaticas e in-teractivas abordados nas seccoes 221 e 222 com o modelo de web applications Ajax(assıncrono) abordado na seccao 223 Figura adaptada de http www adaptivepath

com

15

Enquadramento do Projecto

16

Capıtulo 3

Estado da arte

Apesar de o conceito das OWAs nao ser absolutamente novo as tecnologias que

o suportam sao recentes Neste capıtulo descrevem-se quatro tecnologias que foram

tidas como principais candidatas para o desenvolvimento deste projecto Descrevem-

se ainda alguns exemplos de web applications que disponibilizam actualmente fun-

cionalidades offline e o processo da escolha da tecnologia a utilizar neste projecto

31 Gears

O Gears1 e uma extensao as funcionalidades do browser introduzido pelo Google

que tem como principal objectivo tornar possıvel a visualizacao de paginas de Inter-

net mesmo sem uma conexao disponıvel Encontra-se disponıvel para as platafor-

mas Windows Macintosh e Linux e oferece uma API de Javascript que permite

a scripts aceder a um mecanismo de armazenamento local baseado numa base de

dados SQLite

311 Arquitectura

Esta ferramenta e constituıda por tres componentes principais

bull LocalServer mdash Intercepta pedidos de paginas web e serve-as localmente

bull Database mdash Uma base de dados relacional construıda sobre SQLite

bull WorkerPool mdash Permite executar operacoes de computacao de uma forma

assıncrona sem afectar a capacidade de resposta e fluidez de execucao da web

application Assemelham-se a processos

1Google Inc ndash Mais informacao em httpgearsgooglecom

17

Estado da arte

LocalServer

O modulo LocalServer e uma cache de Uniform Resource Locators (URLs)

controlada pela web application Quando nao existe uma ligacao a Internet e e

feito um pedido para um URL presente nesta cache o LocalServer intercepta-o e

responde ao pedido localmente a partir do disco rıgido do utilizador A aplicacao

pode utilizar dois tipos diferentes de armazenamento local de URLs

bull ResourceStore ndash serve para capturar URLs utilizando exclusivamente a API

de Javascript disponibilizada para o efeito Uma aplicacao podera criar e

utilizar diversos ResourceStores simultaneamente para capturar ficheiros de

dados que necessitam de ser enderecados por um URL tal como um ficheiro

PDF ou uma imagem

bull ManagedResourceStore ndash serve para capturar um conjunto de URLs que estao

relacionados e que sao declarado num ficheiro de manifesto (especificado em

JSON) e que sao automaticamente actualizados O ManagedResourceStore

permite que o conjunto de recursos necessarios para correr uma web application

seja capturado e mantido actualizado automaticamente

A principal diferenca entre estes dois tipos de armazenamento de URLs e a forma

como sao actualizados os seus conteudos Os conteudos de um ManagedResourceStore

sao actualizados sempre que a versao contida no ficheiro de manifesto for alterada

enquanto que os conteudos de um ResourceStore nunca sao actualizados automati-

camente mas apenas quando for explicitamente ordenado pela aplicacao

O LocalServer e capaz de interceptar e servir localmente pedidos de HTTP e

HTTPS sempre que se reunam as seguintes condicoes

1 O URL encontra-se armazenado num ResourceStore ou ManagedResourceStore

2 O sistema de armazenamento local encontra-se activo (enabled = true) Se

o sistema de armazenamento local tiver o atributo requiredCookie o pedido

devera conter um cookie que lhe corresponda

O LocalServer nao necessita de monitorizar o estado da ligacao para atender aos

pedidos Na verdade sempre que as condicoes previamente enunciadas se verificarem

o LocalServer interceptara os pedidos e independentemente do estado da ligacao

a Internet servi-los-a a partir do disco rıgido local Cabera a aplicacao definir qual

o modo em que pretende executar um pedido (online ou offline) definindo o valor

de verdade da propriedade enabled

18

Estado da arte

Database

O modulo Database permite guardar dados da web application assegurando a

sua persistencia Os dados sao guardados de forma relacional no disco rıgido do uti-

lizador2 de acordo com o modelo de seguranca estabelecido pelo Gears3 significando

que uma aplicacao nao pode aceder a conteudos fora do seu domınio

WorkerPool

Nos web browsers uma operacao pesada de computacao pode tornar a interface

lenta e tornar menos agradavel a experiencia do utilizador O modulo WorkerPool

permite correr operacoes em background sem bloquear a interface com o utilizador

Os scripts executados numa WorkerPool nao activam os mecanismos de seguranca

do browser que mostram a mensagem ldquoA script on this page may be busy or may

have stopped respondingrdquo

O WorkerPool comporta-se como um conjunto de processos em vez de threads

Os Workers nao partilham qualquer estado de execucao o que significa que uma

alteracao a uma variavel num Worker nao afecta em nada a execucao de outro

Worker Alem disso os Workers nao herdam automaticamente nenhum codigo dos

seus pais Cada Worker e membro de um WorkerPool e os Workers podem in-

teragir entre si enviando mensagens em formato de texto ou JSON No entanto ha

tambem algumas limitacoes os Workers nao tem acesso ao DOM e objectos como

window ou document nao se encontram acessıveis Isto e consequencia de os Workers

nao partilharem o estado de execucao Mas tem acesso a todas as funcoes built-in

do Javascript A maioria das funcionalidades do Gears pode tambem ser acedida

atraves de uma variavel global especial definida como googlegearsfactory Para

outras funcionalidades especıficas os Workers podem ldquopedirrdquo a pagina principal para

continuar a execucao atraves do envio de mensagens

Outras funcionalidades

bull HttpRequest ndash Este modulo implementa a especificacao W3C XmlHttpRe-

quest definida em [vK08] tornando-a disponıvel para os workers e para a

pagina principal

bull Timer ndash Este modulo implementa a especificacao de timers tal como descrito

por [Hic08] e torna-os disponıveis para os workers e para a pagina principal

2Consultar httpcodegooglecomapisgearsapi_databasehtmldirectories3Consultar httpcodegooglecomapisgearssecurityhtml

19

Estado da arte

bull Factory ndash Esta classe e utilizada para instanciar todos os outros objectos da

API do Gears atraves do seu metodo create Este metodo pode ser utilizado

com os seguintes parametros

ndash betadatabase

ndash betahttprequest

ndash betalocalserver

ndash betatimer

ndash betaworkerpool

312 Goggle Gears em dispositivos moveis

O Gears esta tambem disponıvel em dispositivos Windows Mobile 5 e 6

Os dispositivos moveis estao pela sua natureza frequentemente desconectados

da Internet Mesmo quando possuem uma ligacao as latencias na transferencia de

dados em redes moveis tornam as aplicacoes pouco fluıdas mas o Gears permite

ultrapassar este obstaculo

O Gears funciona exactamente da mesma forma em dispositivos moveis equipados

com o Windows Mobile 5 e 6 como num computador comum Se uma aplicacao tiver

sido implementado com suporte para o Gears entao tambem estara preparada para

ser executada num dispositivo movel mas as limitacoes dos browsers disponıveis

para dispositivos moveis tem que ser consideradas Isto significa prever as condicoes

que permitam uma boa usabilidade devido aos pequenos ecras destes dispositivos

bem como o seu suporte limitado dos padroes do DOM CSS e JavaScript

32 Adobe AIR

O Adobe AIR4 e um runtime compatıvel com diversos browsers e sistemas opera-

tivos que pretende dar aos programadores a possibilidade de combinar diversas tec-

nologias de producao de conteudos para a Internet no desenvolvimento de Rich Inter-

net Application (RIA)s O Adobe AIR mantem uma relacao com o browser mas es-

tende as suas capacidades e tecnologias permitindo o desenvolvimento de aplicacoes

tambem para o ambiente de trabalho com janelas em tudo semelhantes as do sis-

tema operativo Segundo a Adobe o objectivo e complementar o browser dando

aos utilizadores (mas essencialmente aos programadores e equipas de desenvolvi-

mento) a escolha sobre como distribuir as suas aplicacoes Para este efeito o Adobe

AIR tem uma aproximacao diferente do Gears Em vez de ldquoestenderrdquo o browser

acrescentando-lhe funcionalidades o AIR permite tambem o desenvolvimento de

4Adobe - httpwwwadobecomproductsair

20

Estado da arte

aplicacoes que se destinam a ser executadas fora do ambiente do browser mas uti-

lizando as tecnologias comuns da Internet (por exemplo HTML CSS JavaScript

Flash Flex)[CDGH08]

A utilizacao desta tecnologia permite utilizar o browser ou o proprio runtime

Adobe AIR como plataforma de execucao da aplicacao

Na Tabela 31 faz-se uma comparacao das funcionalidades disponıveis de acordo

consoante se escolha o browser ou o desktop como plataforma base para a aplicacao

Uma vez que as aplicacoes Adobe AIR na plataforma desktop tem um caracter

persistente (sao instaladas no computador do utilizador) o Adobe AIR tem um

modelo de seguranca que se assemelha com o das tradicionais aplicacoes desktop

[Ada08] Este modelo e analisado nas seccoes 321 e 322 O ambiente em que

e executado o browser e restringido a execucao de web applications que podem

ser de varias origens (incluindo de origens anonimas ou sem confianca) O Adobe

AIR proporciona acesso a capacidades como acesso a ficheiros que necessitam da

confianca do utilizador

bull HTML ndash O desenvolvimento de aplicacoes para o Adobe AIR pode ser feito

com recurso a tecnologias de HTML e Ajax comuns utilizando as linguagens

de markup existentes distribuıdas como texto e interpretadas em execucao

(runtime)

bull Flash ndash Outra alternativa sera a utilizacao da linguagem Flash Permite a

renderizacao de graficos vectoriais e audiovıdeo com suporte nativo Utiliza

ActionScript para adicionar maior interactividade com o utilizador

bull Flex ndash O Flex e uma framework open source para o desenvolvimento de RIAs

usando Flash As aplicacoes Flex sao na realidade Flash sendo a principal

diferenca o ambiente de desenvolvimento

Como resultado uma aplicacao AIR podera ser implementada

bull Baseada em Flash ou Flex (aplicacoes cujo conteudo base e em ShockWave

Flash (SWF))

bull Baseada em Flash ou Flex tambem com HTML ou Portable Document Format

(PDF) Aplicacoes cujo conteudo de base e em FlashFlex (SWF) com HTML

(HTML JavaScript CSS) ou conteudo PDF incluıdo

bull Baseada em HTML Aplicacoes cujo conteudo base e em HTML Javascript

CSS

bull Baseada em HTML utilizando tambem FlashFlex ou PDF

21

Estado da arte

Os utilizadores interagem com uma aplicacao AIR da mesma forma que interagem

com outras aplicacoes com janelas nativas do seu sistema operativo O runtime e

instalado uma vez no computador do utilizador e a partir desse momento todas as

aplicacoes AIR terao o mesmo aspecto que qualquer outra aplicacao para o desktop

321 Seguranca

Permitir que uma web application aceda ao disco de armazenamento do utilizador

pode comprometer seriamente a sua seguranca Neste sentido o Adobe AIR tem

suporte para assinaturas digitais (Secure Sockets Layer (SSL)) que podem ser com-

pradas pelas equipas de desenvolvimento que o desejem e cujos certificados serao

apresentados ao utilizador no momento da instalacao Um outro aspecto ainda

relativo a seguranca e o mecanismo de isolamento de cada ambiente (sandbox )

322 Assinatura do codigo

O runtime AIR exige que todas as aplicacoes estejam digitalmente assinadas As

assinaturas digitais de codigo sao um processo que visa garantir a integridade da

aplicacao e a identidade do seu autor no momento da instalacao As equipas de

desenvolvimento podem ldquoassinarrdquo uma aplicacao utilizando um certificado atribuıdo

por uma Entidade Certificadora (Certification Authority) ou atraves de um certifi-

cado individual (self signed certificate) Neste momento o Adobe AIR suporta como

entidades certificadoras a Verisign e a Thawte [Ado08]

O instalador apresenta o nome de quem publica a aplicacao quando o codigo tiver

sido assinado com um certificado que apresente confianca ou que esteja encadeado

com um certificado que tenha ja sido aceite no computador em que se esta a instalar

a aplicacao

As equipas de desenvolvimento podem tambem assinar as aplicacoes com um

certificado auto-atribuıdo (um certificado criado por elas proprias) mas neste caso

o instalador apresentara estas aplicacoes como sendo de uma origem nao verificada

O AIR utiliza a infraestrutura publica de chaves [Ent07] suportada pelo arquivo

local do sistema operativo Para que a origem da aplicacao seja reconhecida o

computador onde a aplicacao AIR esta a ser instalada tem que confiar directamente

no certificado que foi utilizado para assinar a aplicacao ou confiar num certificado

que esteja num encadeamento logico de certificados confiados e que se ligue desta

forma ao certificado utilizado para assinar a aplicacao

Todas as aplicacoes AIR tem caracterısticas em comum independentemente da

tecnologia utilizada para o seu desenvolvimento (HTMLFlexFlash) No ambito

de uma aplicacao AIR existem um conjunto de APIs que estao disponıveis e que

tornam possıvel o acesso ao sistema local (leitura e escrita) e a recursos de rede que

22

Estado da arte

de outra forma nunca estariam acessıveis a partir de uma web application comum

Cada aplicacao AIR possui tambem diferentes nıveis de isolamento chamados secu-

rity sandboxes dependendo do tipo de conteudo que esta a ser carregado e do seu

objectivo

bull Isolamento ao nıvel da aplicacao5 ndash E a raiz de cada aplicacao AIR Este

nıvel de isolamento permite o acesso a APIs privilegiadas e especıficas do

AIR Em contrapartida e negado o acesso a algumas APIs que poderiam ser

facilmente utilizadas de forma maliciosa contra o utilizador final Importacao

dinamica de conteudos remotos e geralmente proibido e as tecnicas e mecan-

ismos de geracao dinamica de codigo sao fortemente restringidas Apenas

conteudo carregado directamente da directoria base da aplicacao podera ser

colocado neste nıvel de isolamento

bull Isolamento nao especıfico da aplicacao6 ndash contem todo o outro conteudo

que nao tenha sido carregado directamente para o isolamento da aplicacao

Isto inclui conteudo local e remoto Este tipo de conteudo nao tem acesso

directo as APIs do AIR e rege-se pelas mesmas regras tal como se tivesse sido

carregado por um browser a partir da mesma localizacao (por exemplo HTML

carregado a partir de um domınio remoto comporta-se da mesma forma que se

fosse acedido a partir do browser)

33 Mozilla Prism

331 XML User Interface Language

O eXtensible User Interface Language (XUL) e uma linguagem de anotacao

baseada em XML desenvolvida pela Mozilla Foundation que opera em aplicacoes

Mozilla multi plataforma tal como o Firefox O motor Gecko e a unica imple-

mentacao completa desta linguagem que foi desenhada sobre padroes web comuns

como CSS JavaScript e o DOM e permite o desenvolvimento de interfaces graficas

utilizando elementos pre-definidos tais como window box page textbox radio

button entre outros Infelizmente o XUL nao possui qualquer especificacao formal

ou implementacoes de inter-operabilidade para outros motores que nao o Gecko No

entanto a sua implementacao e licenciada em codigo aberto pelas licencas GNU Gen-

eral Public License (GPL) GNU Lesser General Public License (LGPL) e Mozilla

Public License (MPL)

Enunciam-se algumas caracterısticas desta linguagem

5NT application sandbox6NT non-application sandbox

23

Estado da arte

Liguagem de anotacao poderosa baseada em componentes (widgets) O ob-

jectivo do XUL e permitir a construcao de aplicacoes multi-plataforma em

claro contraste com o Dynamic HyperText Transfer Protocol (DHTML) que se

destina ao desenvolvimento de paginas web Por esta razao o XUL esta orien-

tado a componentes tais como janelas botoes e etiquetas em vez de paginas

cabecalhos de texto e ligacoes de hipertexto Investir tempo e esforco para

atingir este mesmo resultado em aplicacoes baseadas em DHTML compromete

frequentemente a complexidade e desempenho da aplicacao

Baseado em padroes O XUL e um dialecto XML baseado no padrao W3C XML

10 As aplicacoes escritas em XUL sao tambem baseadas em especificacoes

W3C adicionais como HTML 40 CSS DOM nıvel 1 e 2 JavaScript 15

incluindo ECMA-262 Edition 3 (ECMAscript)

Portabilidade entre plataformas Tal como HTML o XUL foi desenhado para

ser independente da plataforma em que e utilizado tornando as aplicacoes

facilmente portaveis entre sistemas operativos nos quais o Mozilla e suportado

Uma vez que o XUL oferece um nıvel de abstraccao dos componentes graficos

de interface que disponibiliza implementa a premissa ldquoum codigo para todas

as plataformasrdquo A interface grafica de todos os produtos centrais Mozilla

(browser instant messenger livro de enderecos) e escrita em XUL com um

unico codigo base que suporta todas as plataformas Mozilla

Separacao entre o nıvel de apresentacao e a logica de negocio Uma das

maiores preocupacoes no desenvolvimento para a Internet e a forte ligacao

entre estas duas camadas (interface e logica) Isto constitui um problema sig-

nificativo no desenvolvimento de grandes aplicacoes especialmente quando o

desenvolvimento e feito em ambientes de equipa porque as capacidades de de-

senvolvimento destas duas partes da aplicacao estao muitas vezes espalhadas

por diferentes elementos O XUL permite uma clara distincao entre a definicao

da aplicacao cliente e da logica de implementacao (XUL eXtensible Binding

Language (XBL) e JavaScript) apresentacao (CSS e imagens) internacional-

izacao (Document Type Definitions (DTDs) e etiquetas de texto em lınguas

especıficas guardados em ficheiros properties) O esquema grafico e apre-

sentacao de uma aplicacao XUL pode ser alterado de forma independente da

sua logica ou implementacao e a aplicacao pode ainda ser traduzida (interna-

tionalization) de forma independente da sua logica implementacao ou apre-

sentacao Este grau de separacao resulta em aplicacoes que sao mais faceis de

manter pelos programadores e facilmente adaptadas por designers e tradutores

24

Estado da arte

Facil adaptacao Outro benefıcio que advem do nıvel de separacao entre logica

de negocio e apresentacao oferecido pelo XUL e a facilidade com que se pode

adaptar uma aplicacao para diferentes clientes ou grupos de utilizadores Um

programador pode utilizar a mesma aplicacao base e adapta-la consoante as

necessidades atraves de diferentes temas (skins) e ficheiros de lınguas Desta

forma uma aplicacao escrita e desenvolvida em Ingles pode ser rapidamente

traduzida para Portugues e distribuıda com outra aparencia mais apropriada

ao cliente alvo

332 Prism

O Mozilla Prism e um browser simplificado e ldquointerpretadorrdquo de XUL (tambem

designado por XULRunner) que acolhe web applications sem a interface grafica ha-

bitual de um browser Baseia-se num conceito designado por Site Specific Browser

(SSB) Um SSB e uma aplicacao com um browser embebido desenhado para exe-

cutar apenas uma web application Nao possui os menus e barras de ferramentas

habituais Um SSB tem uma integracao com o sistema operativo e com o desktop

muito mais estreita do que uma web application acedida atraves de um browser uma

vez que e executado em janela propria

O Prism resulta de uma experiencia da Mozilla e visa reduzir as diferencas entre

as desktop applications tradicionais e as web applications Um dos aspectos focados e

a experiencia do utilizador Numa apresentacao oficial e dito que ldquo[o Prism] pretende

ser uma ponte entre as diferencas que existem entre as aplicacoes tradicionais de

desktop e as web applications explorando novos modelos de usabilidade enquanto

que a linha que as separa se continua a definirrdquo [Lab07]

34 HTML 5

A especificacao HTML 5 [Hic08] que se encontra em fase de desenvolvimento

pelo grupo WHATWG pretende ser uma norma de substituicao dos padroes HTML

4 XHTML 1x e do DOM2 HTML Uma das propriedades que o distingue das tec-

nologias que pretende substituir e precisamente o suporte para OWA e armazena-

mento de dados no cliente de uma forma relacional Nao sendo propriamente uma

tecnologia ndashmas antes uma especificacao ndashe aqui mencionada por ter servido como

referencia a diversas implementacoes de funcionalidades offline e por se considerar

que venha a ter um impacto significativo nas implementacoes de diversos browsers

Dion Almaer defendeu no seu blogue que o Gears era uma implementacao do

HTML 5 No seu artigo ldquoGears as a bleeding-edge HTML 5 implementationrdquo [Alm08]

o autor diz que ambos ndasho Gears e o HTML 5 ndashpretendem dar a web caracterısticas

25

Estado da arte

semelhantes e nao encontrar motivo de ldquocompeticaordquo entre as duas mas que en-

quanto o HTML 5 e uma especificacao o Gears e uma implementacao

No entanto tambem e verdade que o HTML 5 cobre muitos outros pontos para

alem das OWA que saem completamente fora do ambito do Gears Se esta es-

pecificacao atingir um estado de maturidade que possibilite a sua adopcao pelos

principais browsers tornando nativo do browser o suporte OWA entao deixara de

fazer sentido a existencia de uma extensao como o Gears

A especificacao HTML 5 disponibiliza duas APIs relevantes para o tema das

OWA

1 Uma base de dados baseada em SQL que permite o armazenamento de dados

do lado do cliente

2 Uma ldquocacherdquo HTTP que garante a disponibilidade das aplicacoes mesmo quando

o utilizador nao possui uma ligacao a Internet

Estas caracterısticas sao as bases da tecnologia das OWA e tem correspondencia

com os pontos analisados nas seccoes 311 e 311

35 Web applications que usam funcionalidades offline

Nesta seccao apresentam-se algumas web applications que actualmente disponi-

bilizam funcionalidades offline Estas aplicacoes foram escolhidas para uma analise

mais pormenorizada por utilizarem o Gears que tal como descrito na seccao 4 foi

a tecnologia escolhida para o projecto

351 Google Reader e Google Docs

O Google Reader7 e um leitor de feeds RSS Permite gerir a subscricao de varios

sites simultaneamente que disponibilizem conteudos neste formato e foi a primeira

web application da Google com uma versao offline publicamente acessıvel (desde

Junho de 2007)

O Google Reader implementa o modo ldquoutilizador deciderdquo oferecendo na sua

interface um botao que permite alternar entre os modos online e offline

O Google Docs8 e uma web application que permite a criacao e edicao de doc-

umentos de texto folhas de calculo e apresentacoes Era ja publico desde Janeiro

de 2008 que o Google estava a desenvolver uma versao OWA desta aplicacao mas o

acesso a uma versao experimental so foi possıvel a partir de 31 de Maio de 2008

7Google Reader - httpreadergooglecom8Google Docs - httpdocsgooglecom

26

Estado da arte

A implementacao das funcionalidades offline nestas duas aplicacoes seguiu difer-

entes aproximacoes principalmente porque o Google Reader apresenta ao utilizador

informacoes que sao fornecidas por fontes externas enquanto que no Google Docs

a informacao e criada e editada pelo utilizador sobre a forma de documentos

A diferente origem da informacao implica que no Google Reader seja necessario

prever casos de excepcao tal como existirem demasiados itens que necessitam de

ser transferidos para o cliente Nao observar este ponto causa um problema grave

de usabilidade e para evitar tempos de espera demasiado longos e uma interface

com pouca capacidade de resposta as accoes do utilizador o Google Reader apenas

transfere para o cliente os dois mil itens mais recentes na transicao para o modo

offline

352 Remember the Milk

O Remember The Milk9 e uma web application desenvolvida por uma equipa

Australiana que proporciona funcionalidades de agenda gestao de tempo e de tare-

fas e foi uma das primeiras aplicacoes independentes do Google a adoptar o Gears

para acessos em modo offline Permite que os seus utilizadores facam uma gestao

de tarefas agrupando-as em listas adicionando-lhes campos de informacao adicional

ou dando-lhes informacao geografica (recorrendo ao servico Google Maps10) Entre

a sua lista de funcionalidades encontra-se ainda a possibilidade de importar e ex-

portar eventos no formato iCalendar (ics) etiquetas (tags) em tarefas publicacao

Really Simple Syndication (RSS) e partilha de categorias de tarefas de acordo com

diferentes nıveis de permissoes de acesso definidos pelo utilizador

353 MySpace e WordPresscom

O MySpace uma das maiores social networks na Internet anunciou recente-

mente que vai disponibilizar uma versao do seu cliente de e-mail que utiliza o Gears

para acelerar o seu desempenho Numa fase inicial estara disponıvel apenas para

utilizadores que tenham cinco mil ou mais mensagens na sua caixa de correio e

permitira efectuar pesquisas muito mais rapido que a sua versao online

O servico de blogs Wordpresscom anunciou tambem o inıcio da utilizacao desta

tecnologia com o fim de melhorar o desempenho A versao que utiliza esta tecnologia

descarrega e armazena no cliente um conjunto de imagens e scripts que passam a

ter preferencia sobre os seus congeneres online e que permitem acelerar o processo

de carregamento da aplicacao e visualizacao de blogs

9Remember The Milk ndash httpwwwrememberthemilkcom10Google Maps ndash httpmapsgooglecom

27

Estado da arte

O MySpace e o Wordpresscom sao dois exemplos da utilizacao da tecnologia

OWA para optimizacao de web application ja existentes Sem pretenderem disponi-

bilizar uma versao que seja totalmente offline fazem uso do Gears para armazenar no

cliente parte dos recursos frequentemente acedidos na visualizacao das suas paginas

36 Escolha da tecnologia

Apos a analise das tecnologias apresentada nas seccoes 31 a 34 foi necessario es-

tudar a adequacao de cada uma delas ao projecto em questao Desde logo e possıvel

observar que nem todas se dedicam apenas a OWA Por exemplo o Adobe AIR

apesar de ter suporte para OWA apenas disponibiliza algumas das funcionalidades

identificadas como mais indicadas para a execucao do projecto quando utilizado

na sua vertente desktop tal como exposto na Tabela 31 mas a utilizacao desta

vertente implicaria o desenvolvimento de novas interfaces e de novas formas de co-

municacao (troca de mensagens XML ou JSON) A vertente web do Adobe AIR

foca-se mais especificamente nas Rich Internet Applications e permite a reutilizacao

do codigo ja existente (exigindo naturalmente a sua adaptacao e a implementacao

das funcionalidades pretendidas)

A tecnologia escolhida para a realizacao deste trabalho foi o Gears sendo que

um dos principais factores a influenciar esta opcao foi a liberdade introduzida pela

sua licenca Berkeley Software Distribution (BSD)11

Considerou-se o funcionamento desta ferramenta extremamente adequando a

aplicacao no WOW uma vez que o seu principal objectivo e precisamente tornar

possıvel a execucao offline de uma pagina web e por virtude deste facto o Gears tem

uma API concisa e de simples aplicacao pratica uma vez que nao possui quaisquer

outros elementos distractores O funcionamento do seu ManagedResourceStore ex-

emplificado na Figura 31 com a capacidade de actualizacao de recursos definidos

num ficheiro manifesto especificado em JSON pesou tambem nesta decisao

11Sobre a licenca BSD consultar httpwwwopensourceorglicensesbsd-licensephp e http

wwwlinfoorgbsdlicensehtml

28

Estado da arte

Figura 31 Esquema UML do processo efectuado pelos recursos do Gears do tipoManagedResourceStore para a actualizacao dos conteudos definidos no ficheiro manifesto

29

Estado da arte

Funcionalidade RIAs no browser RIAs no desktop

Disponibilidadeda aplicacao

As aplicacoes podem ser facil-mente exploradas e utilizadas

As aplicacoes quando instal-adas tem maior grau de fun-cionalidades e persistencia

Instalacao Nao e necessario qualquer tipode instalacao

As aplicacoes sao instaladasatraves do browser ou descar-regadas e instaladas comouma aplicacao tradicional

Actualizacoes Aplicacoes sao actualizadascarregando conteudos paraum website

O AIR disponibiliza uma APIque permite que as aplicacoessejam actualizadas de umaforma

Sistemas opera-tivos suportados

As aplicacoes podem ser exe-cutadas em diversos sistemasoperativos e browsers

As aplicacoes sao multi-plataforma e podem serinstaladas e executadas emdiversos sistemas operativos ebrowsers

Linguagens deprogramacao

Javascript e disponibilizadopelo browser e ActionScripte disponibilizado pelo AdobeFlash Player

Maquinas virtuais deJavascript e ActionScriptcompatıveis com o browser

Capacidade deexecucao embackground

As RIAs podem ser execu-tadas numa janela do browser

As aplicacoes podem ser ex-ecutadas em background edisponibilizar notificacoes talcomo uma aplicacao tradi-cional

Persistencia A actividade esta limitada asessao do browser Quando obrowser e encerrado toda ainformacao e descartada

As aplicacoes sao instaladas eestao disponıveis no desktopPodem armazenar informacaolocalmente e estao disponıveisoffline

Integracao com odesktop

Integracao com o desktop lim-itada devido a restricoes im-postas pelo browser

As aplicacoes podem acederao sistema de ficheiro ao clip-board eventos notificacoesetc

Controlo da inter-face com o uti-lizador

As aplicacoes sao acedidasatraves de uma janela dobrowser que tem os seusproprios controlos e visualgrafico

As aplicacoes tem um vi-sual grafico proprio em janelapropria

Armazenamentode dados

As aplicacoes tem armazena-mento limitado que pode serreescrito pelo browser

As aplicacoes tem acesso a to-talidade do espaco disponıvellocalmente e a uma base dedados com a possibilidade deencriptacao

Tabela 31 Comparacao das funcionalidades oferecidas pelo Adobe AIR para as platafor-mas web e desktop

30

Estado da arte

Aplicacao Modo de execucao utilizadoGoogle Reader Utiliza o modo ldquoutilizador deciderdquo disponibilizando

ao utilizador um botao para alternar entre os modosonline e offline Como lida com informacao recol-hida de fontes externas de natureza frequentementeefemera o processo de sincronizacao apenas transfereos dois mil itens mais recentes quando passa ao es-tado offline Neste modo sao ainda guardadas in-formacoes de itens lidos e etiquetas atribuıdas quesao sincronizadas com o servidor quando o utilizadorvoltar a activar estado online

Google Docs Utiliza o modo ldquoaplicacao deciderdquo permitindo que outilizador edite os conteudos de documentos de textofolhas de calculo e de apresentacoes independente-mente do estado da ligacao desde o momento em queas funcionalidades offline sao activadas A aplicacaofaz pequenas sincronizacoes com o servidor sempre quenecessario

Remember the Milk Utiliza um modo hıbrido entre ldquoaplicacao deciderdquo eldquoutilizador deciderdquo A aplicacao encarrega-se da sin-cronizacao de dados mas disponibiliza um controlona sua interface que permite despoletar manualmenteeste processo para situacoes em que o utilizador fez al-teracoes recentes e pretende usufruir das capacidadesoffline imediatamente

MySpace O MySpace anunciou a utilizacao de mecanismos dearmazenamento de dados no cliente com recurso atecnologias OWA para melhorar o desempenho doseu cliente web de correio electronico nomeadamenteno que diz respeito a operacoes de pesquisa e or-denacao Inicialmente esta funcionalidade estara ape-nas disponıvel para utilizadores com cinco mil ou maismensagens na sua caixa de correio mas nao e aindaclaro se sera disponibilizada uma versao totalmenteoffline

Tabela 32 Resumo da utilizacao de tecnologias OWA em algumas web applications con-sideradas na analise do estado da arte

31

Estado da arte

32

Capıtulo 4

Desenvolvimento

Neste capıtulo introduz-se a aplicacao WOW e apresenta-se o estudo que foi

feito da adequacao de cada tecnologia para a implementacao da funcionalidade of-

fline nesta plataforma Fazem-se diversas consideracoes sobre opcoes a tomar na

concepcao de OWAs e problemas comuns na sua implementacao bem como sug-

estoes para os resolver O WOW e uma aplicacao ja existente de gestao de ordens

de trabalho e do fluxo de tarefas numa empresa ou organizacao

41 Como ficar offline

Na maior parte das web applications de hoje nao existe uma camada de dados

real A aplicacao exemplificada na Figura 41 ao longo da sua execucao acede

directamente a sua unica fonte de dados (o servidor) atraves de chamadas Ajax sem

que exista uma separacao clara destas duas camadas

Para que uma web application seja capaz de ser executada sem uma ligacao

activa a Internet e mantenha o seu caracter dinamico torna-se necessario incluir

Figura 41 Exemplo de uma arquitectura de uma web application sem uma camada deabstraccao de dados Figura adaptada de http gears google com

33

Desenvolvimento

Figura 42 Exemplo de uma arquitectura de uma web application com uma camada deabstraccao de dados Figura adaptada de http gears google com

um mecanismo de armazenamento de dados local seja uma base de dados ou a

capacidade de acesso ao disco No entanto este mecanismo introduz dois problemas

1 Qual das fontes de dados utilizar quando um utilizador faz um pedido de

informacao

2 A necessidade de implementar uma camada de acesso a dados que seja coerente

quer se use o servidor remoto ou local

Por exemplo em vez de a aplicacao Ajax fazer um pedido relativo as contas de

todos os utilizadores em formato JSON directamente ao servidor remoto podera ao

inves fazer o pedido a um objecto intermedio da camada de dados Este objecto

demonstrado na Figura 42 sera responsavel por implementar uma interface de

acesso a base de dados e retornar um objecto JavaScript com uma representacao da

resposta do servidor

Mas a existencia de uma segunda fonte de dados torna recomendavel tambem

a implementacao de uma camada de data switching que em funcao da existencia

de conexao a Internet e da necessidade de actualizacao dos dados decide se faz o

pedido ao servidor remoto ou se fornece os dados presentes localmente Este objecto

apresentado na Figura 43 decidira de forma transparente para o utilizador se le ou

escreve os dados localmente ou se os enviapede ao servidor remoto e pode tambem

iniciar o processo de convergencia de dados e de resolucao de conflitos

411 Funcionalidades disponıveis em modo offline

Por razoes praticas e provavel que nem todas as funcionalidades da aplicacao

possam ser disponibilizadas em modo offline E necessario escolher quais as fun-

cionalidades a disponibilizar no modo offline da aplicacao e implementar a logica

que decide quando utilizar a base de dados local ou o servidor remoto Apesar do

acesso a base de dados local ser muito mais rapido do que aceder ao servidor o

acesso local nem sempre e preferido Ha varias razoes que podem tornar necessario

escolher o acesso ao servidor em vez do acesso local

34

Desenvolvimento

Figura 43 Exemplo de uma arquitectura de uma web application com uma camada deabstraccao de dados e um data switch Figura adaptada de http gears google com

1 A informacao pode ter uma natureza efemera e nao fazer sentido guarda-la

localmente Exemplo dados em tempo real da bolsa de valores de Lisboa

2 Algumas aplicacoes lidam com informacao que so faz sentido na presenca de

uma ligacao Exemplo Instant Messaging

3 A aplicacao podera escolher apenas guardar a informacao acedida mais fre-

quentemente Exemplo para o utilizador poder alterar a lıngua de apre-

sentacao da aplicacao os conteudos terao que ser guardados em todas as

lınguas disponibilizadas pela aplicacao O custo de implementacao de algu-

mas funcionalidades pode nao compensar o benefıcio

4 A capacidade de processamento ou de armazenamento de dados pode inviabi-

lizar algumas funcionalidades offline Exemplo se uma dada funcionalidade

necessita de uma capacidade de armazenamento de dados para alem do razoavel

de um computador pessoal para ser util (visualizador de mapas)

42 Modos de execucao

Um aspecto que e necessario estudar para qualquer web application que se deseje

disponibilizar offline prende-se com tres modos de execucao que devem ser consid-

erados

1 Utilizador decide o modo de execucao A aplicacao tem modos distintos

de execucao para os estados online e offline geralmente indicados na interface

com o utilizador O utilizador e informado do estado da ligacao e participa na

alteracao de estado de execucao da aplicacao interagindo com a sua interface

2 Aplicacao decide o modo de execucao Pode ser implementado na propria

aplicacao um mecanismo de deteccao do estado da ligacao (por exemplo atraves

35

Desenvolvimento

de chamadas Ajax periodicas) transitando de estado e sincronizando automati-

camente Desta forma o utilizador nao precisa de participar na alteracao de

estado a menos que exista um conflito de dados que requeira a sua atencao

3 Aplicacao assume sempre o estado offline Outra hipotese sera imple-

mentar uma web application que assume sempre estar na ausencia de uma

ligacao ao servidor de dados Esta aplicacao responde aos pedidos do uti-

lizador efectuando pedidos de informacao ao servidor mas nao dependendo

de uma resposta valida para mostrar a informacao que ja tinha disponıvel an-

teriormente A sincronizacao de dados com o servidor e tentada sempre que

existam dados para submeter e uma accao do utilizador

421 Modo ldquoutilizador deciderdquo

Neste modo de execucao quando a aplicacao esta online comunica com o servidor

remoto quando esta offline comunica com a base de dados local A informacao tem

que ser sincronizada sempre que se muda de modo A principal vantagem desta opcao

e que e a mais simples de implementar mesmo para uma aplicacao ja existente e

portanto uma forma expedita de disponibilizar uma OWA No entanto tem tambem

algumas desvantagens que devem ser consideradas

1 O utilizador tem que se lembrar de fazer a alteracao de estado de execucao

Caso contrario podera estar a trabalhar inadvertidamente numa versao offline

com dados antigos ou nao ter a informacao necessaria se perder subitamente

a ligacao

2 Se a ligacao for intermitente o utilizador tera ou que escolher um dos modos

de execucao ou estar constantemente a trocar

3 Uma vez que a base de dados nao esta sempre actualizada nao podera ser

utilizada para melhorar a rapidez de execucao da aplicacao quando em modo

online

422 Modo aplicacao decide

A deteccao do estado da ligacao pode ser implementada atraves de um pedido

assıncrono ao servidor tal como ilustrado na Figura 44 O resultado deste pedido

definira o estado online (em caso de sucesso) ou offline (em caso de falha) A

sincronizacao de dados podera ser feita sempre que ocorra uma transicao do es-

tado offline para o estado online No entanto este metodo nao se revela eficiente

36

Desenvolvimento

Figura 44 Esquema grafico ilustrando uma OWA executando no browser utilizando ummodo de execucao do tipo ldquoaplicacao deciderdquo com deteccao automatica do estado daligacao via pedidos Ajax assıncronos a cada cinco segundos

para grandes aplicacoes uma vez que requer a troca de mensagens demasiado fre-

quentes com o servidor que se destinam exclusivamente a monitorizacao do estado

da ligacao

423 Modo ldquoaplicacao assume o estado offlinerdquo

Uma aplicacao transparente funciona assumindo sempre que esta em modo of-

fline ou pelo menos que pode perder a ligacao a qualquer momento Neste modo

tira-se o maximo partido do armazenamento local e fazem-se pequenas mas contınuas

sincronizacoes com o servidor sempre que este esteja disponıvel A sincronizacao de

dados tambem e feita sempre que se volta ao estado online

As vantagens de uma web application transparente sao as seguintes

bull Uma melhor experiencia para o utilizador uma vez que este nao tem que se

preocupar com o estado da ligacao ou com a transicao de estados

bull A aplicacao funciona de forma coerente mesmo que a ligacao seja intermitente

bull Uma vez que o armazenamento local e mantido actualizado pode ser utilizado

para melhorar o desempenho da aplicacao

Foram identificadas as seguintes desvantagens

bull E mais difıcil de implementar e a sincronizacao acarreta cuidados especiais

bull E necessario um cuidado adicional para evitar que as operacoes de sincronizacao

frequentes que ocorrem automaticamente nao afectem os tempos de resposta

da aplicacao

bull Os testes a aplicacao sao mais complexos uma vez que a sincronizacao de dados

nao ocorre em resposta a uma accao do utilizador

37

Desenvolvimento

43 Sincronizacao de dados

A sincronizacao de dados consiste na capacidade de identificar e transferir pe-

riodicamente a versao mais actual dos dados entre o cliente e o(s) servidor(es)

Independentemente do modo de execucao escolhido e mesmo do estado da ligacao

do utilizador a informacao armazenada localmente e a informacao armazenada no

servidor estarao por vezes dessincronizadas Isto podera acontecer sempre que por

exemplo

bull O utilizador faz alteracoes em modo offline

bull A informacao e partilhada e pode ser alterada por uma entidade externa

bull A informacao e fornecida por uma entidade externa

Resolver estas diferencas de forma a que a informacao local e remota encontrem

a igualdade chama-se sincronizacao de dados Ha varias aproximacoes possıveis

para este efeito que dependem da natureza da aplicacao cada uma com vantagens

e desvantagens

A capacidade de suportar a mobilidade dos utilizadores torna-se cada vez um

ponto mais importante de uma web application Para uma organizacao de dimensao

global e vital garantir que os seus colaboradores tem acesso a mesma informacao

que tem disponıvel nos seus postos de trabalho mesmo quando estao fora Na maior

parte dos casos estes colaboradores terao acesso a um computador portatil um

desktop Smartphone ou PDA e atraves destes poderao ter acesso a sua informacao

directamente atraves de ligacoes encriptadas Virtual Private Network (VPN) de um

servidor web ou de outro mecanismo de rede

Esta solucao e simples de implementar mas infelizmente para a maioria dos

colaboradores com grande factor de mobilidade nao e satisfatoria As principais

desvantagens sao as seguintes

bull Requisitos de ligacao Para permitir que os utilizadores acedam a sua in-

formacao e necessario garantir a capacidade constante de comunicacao pelo

menos durante o tempo necessario que assegure a sua transferencia

bull Velocidade de ligacao sem persistencia de dados e em ligacoes de fraca

qualidade a usabilidade por vezes torna-se inaceitavel

bull Ponto crıtico de falha Com este tipo de solucao todos os utilizadores de-

pendem da base de dados que armazena informacao vital para o funcionamento

do cliente

38

Desenvolvimento

bull Scalability do servidor A medida que novos utilizadores sao adicionados ao

sistema o desempenho do servidor e afectado levando a necessidade de maior

capacidade de armazenamento eou processamento

De acordo com a documentacao da Microsoft Sync Framework [Mic08] uma

solucao alternativa consiste em implementar uma Occasionally Connected Appli-

cation (OCA) Uma OCA permite a um utilizador remoto continuar a aceder a

sua informacao mesmo depois de perder a ligacao mas em vez de recorrer a um

servidor recorre a informacao armazenada no seu dispositivo local Para preencher

localmente a informacao que o utilizador necessita uma OCA possui mecanismos

de sincronizacao de dados que sao oferecidos por esta framework

431 Quando sincronizar

Uma das solucoes mais simples de implementar passa por disponibilizar um

mecanismo manual que despoleta a sincronizacao Diz-se manual porque e o uti-

lizador que escolhe quando sincronizar e pode ser implementada simplesmente

fazendo o upload de toda a informacao para o servidor e depois fazendo o download

da copia mais recente da informacao antes de voltar a ficar offline Para que esta

seja uma opcao viavel e necessario que

bull O volume de dados seja suficientemente pequeno para que possa ser transferido

do servidor para o cliente num espaco de tempo aceitavel

bull Que o utilizador indique explicitamente que quer mudar para o estado offline

ou online pressionando um botao da interface

Contudo podem ser identificados alguns problemas relacionados com esta abor-

dagem

bull Os utilizadores nem sempre podem prever o estado das suas ligacoes A ligacao

pode-se perder subitamente ou ter um caracter intermitente

bull O utilizador pode esquecer-se de efectuar a sincronizacao

Outra opcao sera conjugar a sincronizacao de dados com o modo de execucao

transparente A sincronizacao ocorre automaticamente em background de forma

nao intrusiva para o utilizador A aplicacao comunica com o servidor regularmente

efectuando pequenas trocas de dados com o objectivo de manter o sincronismo da

informacao local e remota Esta abordagem pode ser implementada com pedidos

Ajax assıncronos e regulares ao servidor o que permite manter a interaccao com a

interface fluıda evitando bloqueios Estes pedidos sao feitos prevendo as situacoes

39

Desenvolvimento

de disponibilidade ou indisponibilidade (timeout) do servidor Uma outra opcao

sera permitir que o servidor comunique essas alteracoes utilizando Comet1 tal como

descrito em [Wil06] e [Rus06] As vantagens destas aproximacoes sao

bull A informacao esta disponıvel a qualquer altura que o utilizador decida ficar

offline ou que a ligacao seja acidentalmente perdida

bull O desempenho da aplicacao pode ser melhorado quando se estiver a utilizar

uma ligacao a Internet lenta uma vez que o acesso a dados locais e mais

eficiente do que a consulta de dados ao servidor

44 WOW

O WOW e uma plataforma integrada de gestao de ordens de trabalho ja ex-

istente e desenvolvida pela Critical Software SA a qual se pretende adicionar a

capacidade de execucao offline Esta aplicacao e extremamente dinamica e con-

figuravel com um conjunto extremamente rico de funcionalidades das quais se

destacam

bull Gestao de Ordens de Trabalho ndash suportando a gestao dos pedidos desde a

sua criacao ate ao seu fecho tomando em conta os diferentes tipos de pedidos

(ordens de trabalho pedidos de informacao melhorias resolucao de problemas

etc) e diferentes tipos de accoes possıveis para cada um (Figura 45)

bull Monitorizacao de alteracoes ndash Historico de mudancas anexos e estados criando

relatorios de alteracao automaticamente (o que por quem e quando)

bull Uso de Service Level Agreements (SLAs) ndash E possıvel associar a um pedido um

SLA que define qual o perıodo de tempo atribuıdo a resolucao de um pedido

controlando e agilizando a resolucao do mesmo

bull Utilizacao de queries de utilizador configuraveis que permitem acesso rapido

a determinadas ordens de trabalho de acordo com o filtro configurado (por

exemplo ldquoPara mimrdquo ldquoPara o Grupordquo ldquoPelo Grupordquo)

bull Gestao do relacionamento entre pedidos

bull Pesquisa e filtragem de ordens de trabalho

bull Exportacao de dados em formatos padrao (PDF DOC ou XLS)

bull Integravel com solucoes externas

40

Desenvolvimento

Figura 45 Detalhe de um conjunto possıvel de estados e respectivas transicoes para umadada ordem de trabalho no WOW desde a sua submissao no sistema ate a sua conclusaoem fecho ou cancelamento Esta figura representa apenas um exemplo ja que o mapa deestados para uma ordem de trabalho e dinamico e pode ser alterado por um administradorFigura retirada de uma brochura promocional do WOW Critical Software SA

A utilizacao de uma ferramenta deste tipo por parte de uma empresa ou orga-

nizacao oferece vantagens quer a gestao de topo quer aos colaboradores individuais

para os colaboradores individuais o WOW e uma aplicacao onde estao registadas

todas as tarefas contribuindo activamente para o desenvolvimento em ambientes

multi-tarefa e para a organizacao pessoal das tarefas de acordo com prioridades

Para a gestao de topo esta ferramenta permite obter uma visao global do estado da

organizacao em termos de tempo gasto por tarefa executada sendo uma mais valia

para a previsao e gestaoalocacao de recursos

45 Visao geral sobre a arquitectura do WOW

O WOW e interessante nao so do ponto de vista de produto como tambem do

ponto de vista de plataforma Existem diversos plug-ins que estendem as funcional-

idades do WOW e existem ate projectos que pretendem usar a arquitectura do

WOW para criar produtos com fins diferentes do inicial (por exemplo o WOW-

Storm ndash um sistema de registo e classificacao social de ideias)

De modo a conseguir ter essa expansibilidade a plataforma WOW assenta sob

uma arquitectura distribuıda modular e expansıvel com uma componente central

ndash o core ndash estruturado em camadas logicas E no core que se situam todas as

1O Comet e um conceito semelhante ao Ajax introduzido por Alex Russel mas no qual e o servidor quetoma a iniciativa de ldquoenviarrdquo os dados ao browser sem que este tenha que efectuar um pedido Tambem econhecido por Ajax Push Reverse Ajax ou HTTP Streaming

41

Desenvolvimento

funcionalidades base da aplicacao quer a nıvel logico funcional e de apresentacao

quer a nıvel de gestao e configuracao

E possıvel a execucao de varias instancias do core simultaneamente em servidores

distintos o que permite a alta escalabilidade e disponibilidade desta aplicacao A

consistencia dos dados fica sempre garantida atraves da partilha da base de dados

e pelo balanceamento dos pedidos uma vez que cada um e encaminhado para uma

unica instancia

O WOW apresenta tambem a vantagem de ser uma plataforma extensıvel E

possıvel adicionar novas caracterısticas a plataforma atraves de componentes que se

podem ser divididos em duas categorias plugins e connectors

Os plugins sao componentes que se encontram no mesmo no fısico que a aplicacao

partilhando do mesmo contexto de execucao do core Sao assim uma forma mais

directa de obter informacao da plataforma visto que nao possuem restricoes de

acesso aos dados nem dependencias externas A arquitectura deste componente tera

assim que permitir varias execucoes instanciadas cada uma associada a um core

Por outro lado os connectors sao componentes que se encontram distribuıdos

comunicando externamente com o core Quer a sua execucao quer a obtencao

dos dados estao assim dependentes de interfaces de comunicacao externas que a

plataforma disponibiliza Estes componentes ao contrario dos plugins sao instan-

ciados unicamente e recorrem ao protocolo de comunicacao Java Messaging Service

(JMS) para comunicar com o core

46 WOW Offline

Para alem das opcoes tomadas relativamente a tecnologia a utilizar surgiu

tambem a necessidade de optar por um dos modos de execucao apresentados na

seccao 42

Das tres opcoes possıveis foi o modo ldquoaplicacao assume o estado offlinerdquo descrito

na seccao 423 que mereceu a maior atencao uma vez que reune as vantagens de

uma experiencia mais positiva para o utilizador (uma vez que este nao tem que

participar activamente na alteracao do modo execucao como descrito na seccao 421)

e nao constitui uma sobrecarga excessiva para servidor (como o modo abordado na

seccao 422)

No entanto esta opcao comprometia a complexidade da implementacao para alem

dos objectivos propostos para este projecto e para cumprir o prazo dado foi tomada

a decisao de implementar o modo ldquoutilizador deciderdquo especificando apenas de forma

teorica o modo ldquoaplicacao assume o estado offlinerdquo

As caracterısticas do Gears foram ja descritas na seccao 31 Na Figura 47

mostra-se a sua forma de funcionamento quando integrado numa web application

42

Desenvolvimento

Nesta figura representa-se o modulo LocalServer do Gears como um ponto de de-

cisao Aqui sao testadas as condicoes que determinam se o pedido sera interceptado e

servido localmente ou se prossegue para uma maquina remota E tambem represen-

tada uma base de dados que corresponde ao modulo Database mas que podera nao

ser utilizada Este modulo tal como o modulo Workerpool tem caracter opcional

e sao utilizados consoante os requisitos da aplicacao

A plataforma WOW lida com mais dados do que e necessario passar para o

lado do cliente Em conformidade com o ja exposto na seccao 411 volta-se a

frisar que nao se pretende recriar toda a logica de negocio nem os conteudos da

base de dados no cliente pela sua complexidade e volume de dados Pretende-se

pelo contrario permitir que os utilizadores tirem partido da capacidade de poder

consultar as suas ordens de trabalho quando nao dispoe de uma ligacao transferindo

apenas o essencial para isto seja possıvel

A pagina inicial do WOW apresenta um resumo das ordens de trabalho abertas

ndash enviadas e recebidas ndash que se pretende permitir visualizar offline (ver Figura 46)

Como prova de conceito foi efectuada uma abordagem pragmatica das varias possi-

bilidades descritas na seccao 42

461 Modo ldquoaplicacao deciderdquo com deteccao automatica da ligacao

A primeira abordagem estudada para a disponibilizacao das funcionalidades of-

fline foi o modo ldquoaplicacao deciderdquo com deteccao automatica de ligacao apresentado

na seccao 422 Para que isto seja possıvel foi implementado um mecanismo de ver-

ificacao periodica do estado da ligacao atraves de chamadas Ajax assıncronas O

resultado destes pedidos determina o estado da aplicacao executando as tarefas de

sincronizacao de dados sempre que pertinente Este metodo embora imediato e

simples de implementar depressa se revelou inadequado para o projecto devido ao

elevado consumo de recursos do servidor que a utilizacao intensiva faz esperar a

comunidade da plataforma WOW no principal cliente excede os 7000 utilizadores

Foi estimado que para uma utilizacao de fluidez aceitavel o estado da ligacao deveria

ser testado a cada cinco segundos Assumindo uma adesao (previsao pessimista) de

1 aos servicos offline assistir-se-ia a cerca de 840 pedidos adicionais por minuto

Mas o principal problema desta aproximacao prende-se com o facto de a ver-

ificacao ser feita em intervalos de tempo discretos levando a possibilidade de a

aplicacao poder ter em dado momento uma representacao errada do seu estado

real da ligacao Este problema e ilustrado na Figura 48 onde se ve claramente a

discrepancia entre o estado real da ligacao e a representacao interna que esta tem

Note-se que nesta janela de tempo qualquer accao do utilizador que exija uma

resposta sıncrona do utilizador leva-lo-a para um ldquobeco sem saıdardquo onde nao tera

43

Desenvolvimento

Figura 46 A pagina inicial do WOW apresenta um resumo das ultimas ordens de trabalhoenviadas e recebidas Na imagem pode-se observar a transicao do estado online para offline

acesso a versao offline porque a aplicacao nao fez a transicao automatica nem acesso

a versao online porque na verdade nao possui uma ligacao O que acontecera nesta

situacao sera uma tentativa de acesso ao servidor por parte da aplicacao numa

altura em que este se encontra indisponıvel e o resultado sera uma mensagem de

ldquopedido excedeu o tempordquo apresentado pelo browser Este e um estado sem retorno

porque apos o browser apresentar esta mensagem todos os recursos JavaScript ficam

indisponıveis tornando impossıvel o regresso ao estado anterior ou o tratamento do

erro de qualquer outra forma No entanto as chamadas Ajax podem ser tratadas de

forma especial para a eventualidade de falha e portanto nao constituem problema

44

Desenvolvimento

Figura 47 Ilustracao do funcionamento do Gears numa web application que utiliza ummotor Ajax Os pedidos HTTP ou HTTPS podem ser interceptados e tratados localmenteou podem ser feitos a uma maquina remota consoante se verificarem ou nao as condicoesexpressas no ponto 311 E representado um acesso a uma base de dados local (fornecidapelo Gears) mas a sua utilizacao e opcional

462 Implementacao do modo ldquoutilizador deciderdquo

Este modo de execucao foi ja descrito na seccao 421 e a sua principal carac-

terıstica e ser o utilizador a decidir se a aplicacao deve utilizar um servidor remoto

ou a maquina local como fornecedor de dados

Relativamente ao WOW o WOW Offline na vertente ldquoutilizador deciderdquo vem

alterar os seus casos de uso dando ao utilizador a possibilidade de alterar o estado

de execucao da aplicacao (entre online e offline) Resta dizer que no modo online se

mantem todas as funcionalidades anteriores e que no modo offline torna-se possıvel

visualizar os conteudos da pagina principal do WOW (Figura 46) e os detalhes das

ordens de trabalho (Figura 49) tal como expressa a Figura 410

Esta aproximacao foi utilizada na prova de conceito do WOW adicionando um

controlo a interface desta aplicacao que permite ao utilizador alternar entre os esta-

dos online e offline Na transicao de online para offline sao descarregados os recursos

necessarios para a execucao desta aplicacao sem recorrer a Internet Para o fazer

45

Desenvolvimento

Figura 48 Neste exemplo do modo ldquoaplicacao deciderdquo o teste da ligacao e feito e feito acada cinco segundos O resultado deste teste nao reflecte sempre o estado real da aplicacaopodendo levar a aplicacao a ter comportamentos indesejaveis Na figura assinala-se umperıodo de tempo no qual a representacao interna do estado da ligacao nao corresponde arealidade

e utilizado um recurso ResourceStore e um ManagedResourceStore (introduzidos

em 311) O primeiro e utilizado para armazenar a pagina principal do WOW ndash do-

ravante designada por homejsp ndash e o segundo e utilizado para armazenar imagens

folhas de estilo CSS e scripts JavaScript

Para a implementacao deste modo de execucao foram identificadas as seguintes

tarefas

1 Guardar informacao que permita a recriacao das paginas que se pretende

disponibilizar offline (utilizando o Gears)

2 Disponibilizar um controlo que permita alterar o estado de execucao atraves

da interaccao com a pagina principal

3 Durante a sincronizacao de dados apresentar o progresso da transferencia de

dados

O primeiro passo consistiu na identificacao de todos os conteudos que sao necessarios

transferir para a execucao offline Foi utilizado um recurso do Gears do tipo

ManagedResourceStore que recorre a um ficheiro manifesto para identificar to-

dos os ficheiros que deve transferir Este recurso e gerido automaticamente pelo

Gears transferindo para o cliente a versao mais recente sempre que e necessario

isto e sempre que exista um ficheiro manifesto com uma identificacao de versao que

seja diferente da actualmente disponıvel no cliente Uma vez identificados todos

ficheiros necessarios para a execucao offline num (ou mais) ficheiros manifesto o

Gears encarrega-se da sua actualizacao mas o preenchimento destes ficheiros man-

ifesto e manual o que se traduz num cuidado extra na manutencao da aplicacao

A forma como esta informacao e guardada deve tambem ser cuidadosamente

estudada A opcao mais flexıvel passa por utilizar o modulo Database apresentado

na seccao 311 e guardar a informacao de uma forma relacional Para a recriacao

das paginas pode ser disponibilizada uma versao HTML da pagina que funciona

46

Desenvolvimento

Figura 49 Pagina de visualizacao do detalhe de uma ordem de trabalho

como template nao possui quaisquer dados e e utilizada apenas em modo offline E

preenchida para cada pedido retirando os dados relevantes da base de dados

O modelo de dados do WOW torna esta opcao extremamente trabalhosa uma

vez que as entidades envolvidas na geracao de cada pagina de informacao sobre

cada ordem de trabalho tem relacoes de dependencia complexas seguindo padroes

muito variaveis Por exemplo em cada ordem de trabalho existe um formulario que

permite a sua progressao de estado com diversos campos opcionais e obrigatorios

este formulario e definido pelo administrador e esta relacionado nao apenas com o

tipo de ordem de trabalho mas tambem com o estado actual em que esta se encontra

e a accao que se pretende realizar O elevado numero de combinacoes de tipos de

ordem de trabalho estados e accoes que existem num dado momento juntamente

com a sua possibilidade de alteracao obrigariam a implementacao de uma logica de

negocio complexa o que esta fora do ambito deste projecto

47

Desenvolvimento

Figura 410 Esquema UML que expressa os casos de uso do WOW Offline no modoldquoutilizador deciderdquo

463 Especificacao do modo ldquoaplicacao assume o estado offlinerdquo

A aproximacao para o modo ldquoaplicacao assume o estado offlinerdquo foi tambem

dividida em varias tarefas

1 Guardar informacao que permita a recriacao da pagina principal do lado do

cliente no estado offline (utilizando o Gears)

2 Dotar a aplicacao do cliente de um mecanismo de deteccao da ligacao

3 Identificar os ldquomomentos chaverdquo em que devera ocorrer sincronizacao de dados

4 Implementar a sincronizacao de dados

A sincronizacao de dados deve ser feita em ambas as transicoes online-offline e

offline-online quer para transferir novos dados do servidor (os pedidos podem ser

alterados por outros utilizadores) quando se transita do estado quer para comunicar

eventuais alteracoes feitas em modo offline

Relativamente ao WOW o WOW Offline na vertente ldquoaplicacao assume o es-

tado offlinerdquo vem alterar os seus casos de uso dando ao utilizador a possibilidade

de activar esta funcionalidade A partir do momento que a funcionalidade esta ac-

tivada o utilizador deve tambem ter a possibilidade de gerir algumas preferencias

relacionadas com privacidade de dados Devera ter a hipotese de desactivar o ar-

mazenamento local e de remover todos os dados ja armazenados tal como descrito

na Figura 411

48

Desenvolvimento

Figura 411 Esquema UML que expressa os casos de uso do WOW Offline no modoldquoutilizador deciderdquo

A primeira vez que o WOW Offline e acedido por um cliente e caso seja detec-

tada a presenca do Gears todos os recursos necessarios a sua execucao sao trans-

feridos Todos os acessos posteriores serao feitos a estes recursos locais (recorda-se

que o Gears pode ser utilizado para os manter actualizados recorrendo ao Managed-

ResourceStore 311)

Atraves do JavaScript e possıvel interceptar os eventos de load e unload da

pagina que sao despoletados sempre que ocorre um re-acesso da mesma (incluindo

a accao refresh comum dos browsers) sempre que esta e abandonada ou ainda ou

ainda se a janela for encerrada

Tal como sugerido na seccao 462 a camada de interface desta aplicacao (cada

pagina individual em HTML) devera ser implementada como sendo um template

para apresentacao de dados sendo totalmente preenchida atraves de funcoes em

JavaScript O objectivo deste ponto e criar um padrao de dados que permita ao

JavaScript preencher os dados em cada pagina (template) independentemente de

qual seja a fonte ndash o servidor remoto ou a maquina local tal como exemplificado

no diagrama da Figura 412 Na figura a aplicacao recorre ao servidor remoto para

obter os dados pretendidos quando se encontra na presenca de uma ligacao mas

para dados que exijam uma carga de processamento pelo servidor este acto pode ser

49

Desenvolvimento

Figura 412 Esquema UML que expressa o acto de recolha de dados em modo online eoffline recorrendo ao servidor (modo online) e ao sistema de armazenamento de dadoslocal fornecido pelo Gears (modo offline)

substituıdo pelo envio de um campo de controlo que se destina a aferir se os dados

locais se encontram actualizados No caso de estarem actualizados a comunicacao

com o servidor pode ser substituıda por uma query a base de dados local

50

Capıtulo 5

Resultados e Futuros

Desenvolvimentos

Todo o estudo feito sobre o tema OWA foi ja abordado ao longo do documento

Neste capıtulo apresentam-se os resultados obtidos na implementacao da prova de

conceito que visava compreender a melhor forma de disponibilizar uma versao of-

fline no WOW uma plataforma de gestao de ordens de trabalho ja existente de-

senvolvida pela Critical Software SA

51 Resultados Obtidos

Os resultados obtidos neste projecto sao extremamente satisfatorios uma vez

que o estudo do tema OWA e a implementacao de uma prova de conceito que o

ilustrasse foi conseguido com sucesso

A funcionalidade offline foi adicionada ao produto WOW da Critical Software

SA permitindo a visualizacao de ordens de trabalho e dos seus detalhes mesmo na

ausencia de uma conexao activa a Internet Embora para a solucao implementada

tenha sido utilizada uma abordagem do tipo ldquoutilizador deciderdquo pretende-se que esta

seja convertida para ldquoaplicacao deciderdquo ou mesmo para uma aproximacao hıbrida

semelhante a utilizada pelas aplicacoes estudadas nas seccoes 351 e 352

Para a sua implementacao descrita no capıtulo 4 foram tomadas decisoes de or-

dem pratica que permitissem tornar o trabalho exequıvel nos prazos dados Tentou-

se sempre que estas decisoes afectassem o mınimo em termos de desempenho e de

experiencia para o utilizador Considera-se que a implementacao do modo offline

com uma transicao entre modos do tipo ldquoutilizador deciderdquo (ver seccao 42) reflecte

o compromisso entre o desempenho pretendido e os recursos disponıveis e para alem

51

Resultados e Futuros Desenvolvimentos

de ser um exemplo eficaz das possibilidades que as OWA podem trazer a aplicacao

WOW desenvolvida pela Critical Software e tambem um estudo que pode ser uti-

lizado para analisar a implementacao desta tecnologia noutros produtos da mesma

empresa

Note-se que o principal objectivo do trabalho era ganhar familiaridade com este

tema entender as suas vantagens e desvantagens e compreender as suas limitacoes

Tudo indica que existam varias possibilidades de implementacao deste paradigma

noutros produtos da Critical Software que pela sua natureza podem tambem tirar

partido da execucao offline

52 Trabalho Futuro

O desenvolvimento do conceito e formas de implementacao de OWA continua

em forte desenvolvimento no entanto a sua adopcao ainda nao e generalizada A

dificuldade da sua implementacao em web applications ja existentes e o principal

obstaculo a sua maior divulgacao

Ha tambem um factor que deve ser tido em consideracao a manutencao de

codigo A implementacao de uma versao offline de uma web application requer

a implementacao das mesmas regras de negocio (ou de uma versao simplificada)

utilizadas no servidor Para que isto seja possıvel e necessario ter em conta a

capacidade de processamento do cliente e o factor de duplicacao de codigo que

tornara a aplicacao mais difıcil de manter uma vez que uma alteracao a logica de

negocio do servidor implica tambem uma alteracao a sua versao offline

A prova de conceito implementada permite ja a visualizacao offline dos pedidos

abertos (enviados e recebidos) que constam na pagina principal (este numero e

fixo e pode ser alterado pelo administrador) Uma funcionalidade desejavel seria a

possibilidade de interaccao com a aplicacao em modo offline e sincronizacao com o

servidor quando existisse uma ligacao disponıvel

Foi estudada a utilizacao do modo de execucao ldquoaplicacao assume o estado of-

flinerdquo descrito em 423 e esta seria a forma desejavel para o WOW Offline no

entanto para que esta opcao seja viavel sera necessaria a implementacao de uma

forma eficiente de sincronizacao e armazenamento de dados de uma forma relacional

Para atingir este objectivo podera ser seguida uma polıtica de automacao do pro-

cesso no qual a versao online da aplicacao gera scripts de criacao para as tabelas

necessarias na base de dados da versao offline (nao existe nenhuma ferramenta para

o fazer portanto seria necessaria a sua implementacao) e no qual as paginas HTML

disponibilizadas pelo servidor aos clientes web (browser) servem como templates de

apresentacao de informacao e sao preenchidas de forma semelhante pelo servidor ndash

quando a aplicacao estiver online ndash ou pelo cliente atraves de funcoes em JavaScript

52

Resultados e Futuros Desenvolvimentos

ndash quando a aplicacao estiver offline No entanto no WOW devido a quantidade de

informacao tratada e devido as complexas relacoes entre as diferentes entidades e

de esperar que a complexidade da implementacao de um mecanismo deste tipo torne

esta aproximacao demasiado custosa

O HTML 5 embora um forte candidato ainda nao esta suficientemente desen-

volvido A sua especificacao ainda tem o caracter de Draft (rascunho) e esta sujeita

a modificacoes e a aceitacao e implementacao por parte dos browsers e portanto

de momento foi desconsiderado No entanto no futuro se esta especificacao atingir

um estado de maturidade que permita a sua adopcao devera ser considerada como

um possıvel caminho a seguir

53

Resultados e Futuros Desenvolvimentos

54

Capıtulo 6

Conclusoes

Neste capıtulo sao apresentadas as conclusoes do projecto e consideracoes finais

relativamente a tecnologia estudada

61 Conclusoes

O rapido desenvolvimento tecnologico faz prever que a disponibilidade de ligacao

a Internet seja cada vez mais facil e mais rapido mas vao continuar a existir lugares

onde o acesso e limitado e onde as OWA podem desempenhar um papel de relevo

Por outro lado esta tecnologia pode tambem ser utilizada para melhorar o desem-

penho de paginas web com uma necessidade elevada de imagens ou outros recursos

dispendiosos em termos de espaco e foram ate estudados dois exemplos da utilizacao

desta vertente desta tecnologia em 353

Acredita-se que as OWAs vem responder a uma necessidade real por parte das

web applications actuais e que a evolucao que representam se compara a que se

assistiu dos thin-clients para os fat-clients em termos de autonomia do servidor

A capacidade de oferecer conteudos dinamicos no browser independentemente da

existencia de uma ligacao reune as vantagens tıpicas das web applications como

ausencia de instalacao e actualizacoes instantaneas com as vantagens das aplicacoes

de desktop em capacidade de processamento e armazenamento de dados na maquina

local

As tecnologias disponıveis ate a data estudadas no ambito deste projecto que

permitem o desenvolvimento de OWAs e que apresentam maior maturidade sao o

Gears e o Adobe AIR Ambas se apresentam sobre a forma de plugins que necessitam

de uma instalacao extra para poderem ser utilizadas Apesar de esta instalacao ser

55

Conclusoes

apenas necessaria uma vez podera constituir um factor de desencorajamento a sua

adopcao

O HTML 5 uma especificacao abordada neste documento na seccao 34 podera

ser uma alternativa que oferece funcionalidades offline a uma web application sem a

necessidade de qualquer instalacao no entanto esta especificacao ainda nao foi aceite

pelos principais browsers ndash o documento que define o HTML 5 ainda tem o estatuto

de Draft ndash e ainda nao e possıvel antecipar quando e que isto podera acontecer

Um dos problemas que surge frequentemente na implementacao de uma versao

offline para uma web application e a necessidade de sincronizacao de dados Quando

a informacao pode ser alterada por varios utilizadores simultaneamente e necessario

prever os conflitos que daı podem surgir e dotar a aplicacao de uma forma de os

resolver ou alertar o utilizador para a necessidade de alteracao dos dados

Em conclusao todos os objectivos propostos para este projecto foram atingidos

A prova de conceito implementada reflecte de forma clara as possibilidades oferecidas

pela tecnologia OWA e sera utilizado no futuro para compreender a melhor forma

de o implementar de forma definitiva no WOW

56

Referencias

[Ada08] Lucas Adamski Introducing Adobe AIR security model Fevereiro de2008 Disponıvel em httpwwwadobecomdevnetairarticles

introduction_to_air_securityhtml acedido em Marco de 2008

[Ado08] Adobe Adobe AIR 10 Security White Paper 2008 Disponıvel emhttpdownloadmacromediacompubairdocumentation1air_

securitypdf acedido em Marco de 2008

[Alm08] Dion Almaer Gears as a bleeding-edge html 5 implementa-tion March 2008 Disponıvel em httpalmaercomblog

gears-as-a-bleeding-edge-html-5-implementation acedido emMarco de 2008

[BL96] Tim Berners-Lee The world wide web Past present and future Agostode 1996 Disponıvel em httpwwww3orgPeopleBerners-Lee

1996ppfhtml acedido em Abril de 2008

[CDGH08] Mike Chambers Daniel Dura Dragos Georgita and Kevin Hoyt AdobeAIR for JavaScript Developers OrsquoReilly Media 2008 Disponıvel emhttponairadobecomfilesAIRforJSDevPocketGuidepdf ace-dido em Abril de 2008

[Con99] Jim Conallen Modeling Web Application Architectures with UML Junho1999 Disponıvel em httpwwwumlorgcnUMLApplicationpdf

webappspdf acedido em Maio de 2008

[Ent07] Entrust What is a public key information 2007 Disponıvel em http

wwwentrustcompkihtm acedido em Junho de 2008

[Gar05] Jesse James Garret Ajax A new approach to web applicationsFebruary 2005 Disponıvel em httpwwwadaptivepathcomideas

essaysarchives000385php acedido em Marco de 2008

[Greon] Philip Greenspun Philip and Alexrsquos Guide to Web Publishing 2003(last revision) Disponıvel em httpphilipgreenspuncompandaacedido em Junho de 2008

[Gro02a] App Design Group Thick vs thin client comparison 2002 Disponıvelem httpwwwdonjacobsvwcomimagesweekendspecials

Thick-vs-Thinpdf acedido em Junho de 2008

57

REFERENCIAS

[Gro02b] Technical Research Group Thin Client Tecnhology - WhitePaper 2002 Disponıvel em httpwwwpicktrgcompubs

thinclientwhitepaperpdf acedido em Junho de 2008

[Gro08] Miniwatts Marketing Group World internet usage March 2008Disponıvel em httpwwwinternetworldstatscomstatshtm ace-dido em Abril de 2008

[Hic08] Ian Hickson HTML 5 Draft Recommendation 2008 Disponıvelem httpwwwwhatwgorgspecsweb-appscurrent-work ace-dido em Marco de 2008

[Kha] Olga Kharif Top 10 municipal wifi plans Disponıvel em http

imagesbusinessweekcomss0608muni_wifiindex_01htm ace-dido em Marco de 2008

[Lab07] Mozilla Labs Prism Outubro 2007 Disponıvel em httplabs

mozillacom200710prism acedido em Marco de 2008

[Loo06] Chris Loosley Rich Internet ApplicationsDesign MeasurementandManagement Challenges 2006 Disponıvel em httpwwwkeynote

comdocswhitepapersRichInternet_5pdf acedido em Maio de2008

[Mic08] Microsoft Introduction to Occasionally Connected Applications us-ing Sync Services for ADONET 2008 Disponıvel em httpmsdn

microsoftcomen-ussyncbb887608aspx acedido em Junho de2008

[Nao08] Erica Naone Offline web applications Abril 2008 Disponıvelem httpwwwtechnologyreviewcomread_articleaspxch=

specialsectionsampsc=emerging08ampid=20245 acedido emAbril de 2008

[NJN00] Jason Nieh Yang S Jae and Naomi Novik A comparison of thin-clientcomputing architectures 2000 Disponıvel em httpwwwnclcs

columbiaedupublicationscucs-022-00pdf acedido em Maio de2008

[OrsquoR06] Tim OrsquoReilly Web 20 compact definition Trying again Dezembro2006 Disponıvel em httpradaroreillycomarchives200612

web-20-compact-definition-tryihtml acedido em Marco de 2008

[OrsquoR09] Tim OrsquoReilly What is Web 20 Design patterns and business modelsfor the Next Generation of Software 20053009 Disponıvel emhttpwwworeillynetcompubaoreillytimnews200509

30what-is-web-20html acedido em Marco de 2008

[Rus06] Alex Russel Comet Low latency data for the browser March Marco2006 Disponıvel em httpalexdojotoolkitorgp=545 acedidoem Marco de 2008

58

REFERENCIAS

[Sad97] Darleen Sadoski Clientserver software architecturesndashan overviewAgosto 1997 Disponıvel em httpwwwseicmuedustr

descriptionsclientserver_bodyhtml acedido em Junho de2008

[Sch96] George Schussel Clientserver past present and future 1996

[Smi07] Kevin C Smith Css filters - will the browser apply the rule July 2007Disponıvel em httpcentriclecomrefcssfilters acedido emMarco de 2008

[vK08] Anne van Kesteren The XMLHttpRequest Object W3C Work-ing Draft 15 Abril 2008 Disponıvel em httpwwww3orgTR

XMLHttpRequest acedido em Abril de 2008

[Wil06] Greg Wilkins Why ajax comet July Julho 2006 Disponıvel emhttpwwwwebtidecomdownloadswhitePaperWhyAjaxhtml ace-dido em Abril de 2008

59

REFERENCIAS

60

Anexo A

Screenshots

Algumas imagens de aplicacoes que utilizam funcionalidades offline ilustrativasda tecnologia abordada neste documento

Figura A1 Dialogo apresentado ao utilizador na primeira activacao das funcionalidadesoffline no Google Docs amp Spreadsheets

61

Screenshots

Figura A2 Na activacao das funcionalidades offline e tambem oferecida a possibilidadeda criacao de alguns atalhos por exemplo no ambiente de trabalho

Figura A3 O Google Docs mantem a todo o momento a possibilidade de alteracao destasdefinicoes ou da anulacao dos servicos offline para um dado computador

62

Screenshots

Figura A4 Apos a instalacao do Gears qualquer visita ao Remember The Milk despoletauma sincronizacao que ocorre automaticamente e sem necessidade de intervencao por partedo utilizador

Figura A5 Apos completar a sincronizacao de dados mesmo que a ligacao a Internetseja perdida o Remember the Milk continua disponıvel no browser (com excepcao dasfuncionalidades que pela sua natureza exigem uma ligacao como por exemplo partilhade tarefas e envio de convites)

63

Page 7: O ine Web Applications

iv

Agradecimentos

A realizacao e os objectivos alcancados neste projecto nao teriam sido possıveissem a colaboracao de inumeras pessoas Agradeco profundamente a todos os quecontribuıram directa ou indirectamente para o seu sucesso

A minha orientadora Professora Teresa Galvao Dias e ao Project ManagerEngenheiro Marcus Neves que me conduziram e acompanharam no desenvolvimentodeste projecto

A toda a equipa do WOW em especial o Pedro Maurıcio Costa e o Fabio Matosque contribuıram para a minha a minha integracao na Critical Software e que sempresouberam responder a todas as minhas questoes

A todos os que constituem a CSW Porto pelo fantastico ambiente de amizadeque me proporcionaram

Aos colegas de curso e a todos os que me auxiliaram na revisao deste documento

Os meus sinceros agradecimentos

Joao Goncalves da Costa

v

vi

Conteudo

1 Introducao 111 Enquadramento 112 Motivacao 213 Ambito 314 Objectivos 315 Estrutura do documento 3

2 Enquadramento do Projecto 521 Evolucao das arquitecturas de software 5

211 Thin-clients 5212 Fat-clients 6213 Arquitecturas cliente-servidor 7

22 Evolucao na Internet 8221 Paginas web estaticas 9222 Paginas web interactivas e paginas web dinamicas 9223 Web 20 e Ajax 11

23 Offline Web Applications 1324 Comparacao 13

3 Estado da arte 1731 Gears 17

311 Arquitectura 17312 Goggle Gears em dispositivos moveis 20

32 Adobe AIR 20321 Seguranca 22322 Assinatura do codigo 22

33 Mozilla Prism 23331 XML User Interface Language 23332 Prism 25

34 HTML 5 2535 Web applications que usam funcionalidades offline 26

351 Google Reader e Google Docs 26352 Remember the Milk 27353 MySpace e WordPresscom 27

36 Escolha da tecnologia 28

vii

CONTEUDO

4 Desenvolvimento 3341 Como ficar offline 33

411 Funcionalidades disponıveis em modo offline 3442 Modos de execucao 35

421 Modo ldquoutilizador deciderdquo 36422 Modo aplicacao decide 36423 Modo ldquoaplicacao assume o estado offlinerdquo 37

43 Sincronizacao de dados 38431 Quando sincronizar 39

44 WOW 4045 Visao geral sobre a arquitectura do WOW 4146 WOW Offline 42

461 Modo ldquoaplicacao deciderdquo com deteccao automatica da ligacao 43462 Implementacao do modo ldquoutilizador deciderdquo 45463 Especificacao do modo ldquoaplicacao assume o estado offlinerdquo 48

5 Resultados e Futuros Desenvolvimentos 5151 Resultados Obtidos 5152 Trabalho Futuro 52

6 Conclusoes 5561 Conclusoes 55

Referencias 59

A Screenshots 61

viii

Lista de Figuras

21 Arquitectura de um sistema thin-client em duas camadas (a esquerda)e em tres camadas (a direita) Note-se a inclusao do servidor (main-frame) na definicao das camadas desta arquitectura devido a fortedependencia cliente-servidor 9

22 Arquitectura de um fat-client em duas camadas (a esquerda) e emtres camadas (a direita) 10

23 Comparacao do modelo de web aplications sıncrono paginas estaticase interactivas abordados nas seccoes 221 e 222 com o modelo deweb applications Ajax (assıncrono) abordado na seccao 223 Figuraadaptada de http www adaptivepath com 15

31 Esquema UML do processo efectuado pelos recursos do Gears do tipoManagedResourceStore para a actualizacao dos conteudos definidosno ficheiro manifesto 29

41 Exemplo de uma arquitectura de uma web application sem uma ca-mada de abstraccao de dados Figura adaptada de http gears

google com 33

42 Exemplo de uma arquitectura de uma web application com uma ca-mada de abstraccao de dados Figura adaptada de http gears

google com 34

43 Exemplo de uma arquitectura de uma web application com uma ca-mada de abstraccao de dados e um data switch Figura adaptada dehttp gears google com 35

44 Esquema grafico ilustrando uma OWA executando no browser uti-lizando um modo de execucao do tipo ldquoaplicacao deciderdquo com de-teccao automatica do estado da ligacao via pedidos Ajax assıncronosa cada cinco segundos 37

45 Detalhe de um conjunto possıvel de estados e respectivas transicoespara uma dada ordem de trabalho no WOW desde a sua submissaono sistema ate a sua conclusao em fecho ou cancelamento Esta figurarepresenta apenas um exemplo ja que o mapa de estados para umaordem de trabalho e dinamico e pode ser alterado por um admin-istrador Figura retirada de uma brochura promocional do WOWCritical Software SA 41

ix

LISTA DE FIGURAS

46 A pagina inicial do WOW apresenta um resumo das ultimas ordensde trabalho enviadas e recebidas Na imagem pode-se observar atransicao do estado online para offline 44

47 Ilustracao do funcionamento do Gears numa web application que uti-liza um motor Ajax Os pedidos HTTP ou HTTPS podem ser inter-ceptados e tratados localmente ou podem ser feitos a uma maquinaremota consoante se verificarem ou nao as condicoes expressas noponto 311 E representado um acesso a uma base de dados local(fornecida pelo Gears) mas a sua utilizacao e opcional 45

48 Neste exemplo do modo ldquoaplicacao deciderdquo o teste da ligacao e feitoe feito a cada cinco segundos O resultado deste teste nao reflectesempre o estado real da aplicacao podendo levar a aplicacao a tercomportamentos indesejaveis Na figura assinala-se um perıodo detempo no qual a representacao interna do estado da ligacao nao cor-responde a realidade 46

49 Pagina de visualizacao do detalhe de uma ordem de trabalho 47410 Esquema UML que expressa os casos de uso do WOW Offline no

modo ldquoutilizador deciderdquo 48411 Esquema UML que expressa os casos de uso do WOW Offline no

modo ldquoutilizador deciderdquo 49412 Esquema UML que expressa o acto de recolha de dados em modo

online e offline recorrendo ao servidor (modo online) e ao sistemade armazenamento de dados local fornecido pelo Gears (modo offline) 50

A1 Dialogo apresentado ao utilizador na primeira activacao das funcional-idades offline no Google Docs amp Spreadsheets 61

A2 Na activacao das funcionalidades offline e tambem oferecida a possi-bilidade da criacao de alguns atalhos por exemplo no ambiente detrabalho 62

A3 O Google Docs mantem a todo o momento a possibilidade de alteracaodestas definicoes ou da anulacao dos servicos offline para um dadocomputador 62

A4 Apos a instalacao do Gears qualquer visita ao Remember The Milkdespoleta uma sincronizacao que ocorre automaticamente e sem ne-cessidade de intervencao por parte do utilizador 63

A5 Apos completar a sincronizacao de dados mesmo que a ligacao aInternet seja perdida o Remember the Milk continua disponıvel nobrowser (com excepcao das funcionalidades que pela sua naturezaexigem uma ligacao como por exemplo partilha de tarefas e enviode convites) 63

x

Lista de Tabelas

21 Comparacao entre thin-clients e fat-clients 7

31 Comparacao das funcionalidades oferecidas pelo Adobe AIR para asplataformas web e desktop 30

32 Resumo da utilizacao de tecnologias OWA em algumas web applica-tions consideradas na analise do estado da arte 31

xi

LISTA DE TABELAS

xii

Glossario

fat-client Cliente que nao depende totalmente de umservidor central para as suas actividadesde processamento e possui frequentementedispositivos de armazenamento de dados

6ndash8

thin-client Cliente que depende de um servidor centralpara as suas actividades de processamento

5ndash8

web application Sistema web (servidor rede HTTPbrowser) onde accoes do utilizador(navegacao e introducao de informacao)afectam o estado logico da aplicacao

i iii1ndash311ndash1517ndash1921ndash232728 3336ndash3842 5556

API Application Programming Interface 10 1718 2326 28

ASP Linguagem interpretada pelo servidorque permite a criacao de paginas webdinamicas Desenvolvida pela Microsoft

11

BSD Berkeley Software Distribution 28

CSS Cascading Style Sheets 12 2021 2324 46

DHTML Dynamic HyperText Transfer Protocol 24DOM Document Object Model 10 12

20 2324

DTD Document Type Definition 24

xiii

Glossario

ECMAScript Padrao de linguagem de programacaodefinido pela Ecma International que orig-inou o JavaScript e o JScript

24

Flash Conteudo interactivo de um ficheiro emformato SWF E desenvolvido pela Adobee visualizado atraves do Adobe FlashPlayer

21

Flex Framework baseada em XML e Action-Script desenvolvida pela Adobe para a pro-gramacao de Rich Internet Applications(RIA)

21

GPL GNU General Public License 23

HTML HyperText Markup Language 1 10ndash12 2124ndash2649

HTTP HyperText Transfer Protocol 2 26

JMS E uma API em Java que permite a troca demensagens entre componentes de software

42

JSON JavaScript Object Notation permite atroca de dados codificados num formatode texto de simples leitura

12 1828 34

LGPL GNU Lesser General Public License 23

Mozilla Prism Browser simplificado e ldquointerpretadorrdquo deeXtensible User Interface Language (XUL)(tambem designado por XULRunner) queacolhe web applications sem a interfacegrafica habitual de um browser

25

MPL Mozilla Public License 23

OCA Occasionally Connected Application 39OWA Offline Web Application i iii

2ndash515 1725 2628 3133 3651 5255 56

PDF Portable Document Format 21

xiv

Glossario

PHP Linguagem interpretada pelo servidorque permite a criacao de paginas webdinamicas mas que pode tambem ser in-vocada a partir da linha de comandos

11

pagina web estatica Pagina web que devolve sempre a mesmaresposta a todos os pedidos para todos osutilizadores e em qualquer contexto

5 9

RIA Rich Internet Applications web appli-cations que apresentam funcionalidadessemelhantes as desktop applications masque mantem a informacao no lado do servi-dor

5 1520 28

RSS Really Simple Syndication 27

SLA Service Level Agreement 40SQLite Segundo a definicao oficial SQLite is a

software library that implements a self-contained serverless zero-configurationtransactional SQL database engine

17

SSB Site Specific Browser 25SSL Secure Sockets Layer 22SWF ShockWave Flash 21

URL Uniform Resource Locator 18

VPN Virtual Private Network 38

WOW Work Orders Web Plataforma de gestaode ordens de trabalho e do seu fluxo de-senvolvida pela Critical Software SA

i iii28 3340ndash434551ndash5356

WWW World Wide Web 11 1214

XBL eXtensible Binding Language 24XHTML eXtensible HyperText Markup Language 12XML eXtensible Markup Language 11 12

23 2428

XSLT eXtensible Stylesheet Language Transfor-mation

12

XUL eXtensible User Interface Language xiv23ndash25

xv

Glossario

xvi

Capıtulo 1

Introducao

Neste capıtulo enquadra-se o tema do projecto introduzindo alguns dos conceitos

nos quais se baseia Apresentam-se as motivacoes ambito objectivos e a estrutura

deste documento

11 Enquadramento

A Internet foi originalmente concebida para ser um espaco de partilha de in-

formacao onde pessoas (atraves de maquinas) pudessem comunicar Na sua origem

as paginas eram estaticas constituıdas por texto formatado em HyperText Markup

Language (HTML) e ligadas entre si [BL96] Hoje encontramos conteudos cada vez

mais complexos e dinamicos incluindo som vıdeo ou streams multimedia [Loo06] e

em 2005 foi introduzido por [OrsquoR09] o termo Web 20

De acordo com [Greon] um website pode pertencer a uma ou varias das seguintes

categorias

bull Documento ndash um website essencialmente estatico onde alteracoes a uma

parte do conteudo nao tem implicacoes no seu comportamento

bull Base de dados ndash um directorio de informacao organizada em categorias

bull Aplicacao ndash um website dinamico que utiliza uma linguagem executada ou

interpretada do lado do servidor e que processa as accoes ou informacao in-

troduzida pelo utilizador para fornecer um servico ou nova informacao

A ultima destas categorias constitui aquilo que e normalmente designado por

web application O conceito utilizado ao longo deste documento e o mesmo que

o introduzido por Jim Coallen em [Con99] que define web application como um

1

Introducao

sistema web (servidor rede HyperText Transfer Protocol (HTTP) browser) onde

accoes do utilizador (navegacao e introducao de informacao) afectam o estado logico

da aplicacao A sua definicao tenta estabelecer que uma web application e um

sistema de software com estado de negocio1 e que a sua interface de interaccao com

o utilizador e distribuıdo atraves de um sistema web

12 Motivacao

A quantidade de informacao que e produzida e armazenada com recurso a es-

tas web applications disponıveis online tais como e-mail blogues ou mesmo docu-

mentacao tornam por vezes a disponibilidade de ligacao uma condicao necessaria

a produtividade e como consequencia desta barreira muitos potenciais utilizadores

opoem-se a adopcao de produtos web em detrimento das tradicionais desktop appli-

cations

Assegurar o acesso a uma ligacao de Internet e hoje muito mais facil A Internet

movel e ja uma realidade e encontra-se amplamente divulgada mas continuam a

existir diversas situacoes nas quais os utilizadores estao privados de uma ligacao

a Internet tais como uma viagem de metro ou de aviao ou quando se encontram

deslocados do seu paıs de origem e nao possuem nenhum plano de subscricao

Uma OWA consiste numa web application que para alem de manter todas as

caracterısticas anteriores se mantem disponıvel mesmo na ausencia de uma ligacao

a Internet e surge como uma tentativa de estreitar as barreiras existentes entre a

web e o desktop Isto significa que devera existir um mecanismo capaz de assegurar

a manutencao do estado logico da aplicacao quando a ligacao com o servidor e

quebrada permitindo ao utilizador continuar a utilizar a aplicacao e que sera capaz

de informar o servidor do estado em que a aplicacao se encontra quando a ligacao for

reposta A principal vantagem que advem desta possibilidade e evidente eliminar

a necessidade da existencia de uma ligacao a Internet para que a aplicacao possa ser

utilizada

Por outro lado a vontade de integracao de funcionalidades tıpicas das desktop

applications nas web applications foi um dos principais factores que impulsionou o

desenvolvimento deste conceito uma vez que obrigou a uma reflexao ldquopara alem

do browserrdquo e a uma adaptacao das arquitecturas existentes que permitisse ou o

acesso a funcionalidades disponibilizadas pelo sistema operativo ou pelo menos a

funcionalidades semelhantes Pretende-se com esta aproximacao tornar possıveis

interaccoes entre o desktop e o browser tais como arrastar um ficheiro para um

formulario web de upload de conteudos melhor suporte para o historico do clipboard

ou ainda o acesso ao sistema de ficheiros local Atingir estes objectivos reflecte-se

1NT business state

2

Introducao

num novo paradigma que reune as vantagens das web applications tais como os

updates instantaneos ou o facto de nao ser necessaria nenhuma instalacao e das

desktop applications como por exemplo persistencia no armazenamento de dados

acesso a funcionalidades do sistema operativo ou integracao e interaccao com outras

aplicacoes sejam elas web applications ou desktop applications

13 Ambito

Este projecto foi realizado na Critical Software SA no ambito do Mestrado

Integrado em Engenharia Informatica e Computacao (MIEIC) da Faculdade de En-

genharia da Universidade do Porto (FEUP) entre os meses de Fevereiro e Julho de

2008

14 Objectivos

Sao objectivos deste projecto

1 Estudar e documentar o tema das OWAs acompanhando os ultimos desenvolvi-

mentos nesta materia

2 Analisar o estado da arte fazendo uma analise crıtica e objectiva sobre as

diversas metodologias existentes

3 Implementar uma prova de conceito que permita a execucao offline de uma

web application documentando todo o processo

4 Estudar a possibilidade de permitir interaccao com a aplicacao (insercoes e

alteracoes aos dados) em modo offline

Em resumo o objectivo deste projecto foi estudar documentar e implementar

uma prova de conceito relacionada com o tema Offline Web Applications (OWA)

Este tema embora nao seja totalmente novo ganhou destaque ao longo do ano de

2007 com o surgimento de diversas ferramentas que se destinam a aproximar web

applications das desktop applications

15 Estrutura do documento

Este documento esta organizado em diferentes seccoes apresentando o projecto

numa sequencia logica organizada da seguinte forma

No capıtulo 1 faz-se uma breve apresentacao do conceito OWAs e do contexto em

que surge Apresenta-se tambem a estrutura do documento e definem-se os

termos e acronimos utilizados

3

Introducao

No capıtulo 2 faz-se uma descricao da evolucao das tecnologias que antecedem as

OWAs e das vantagens e desvantagens de cada uma como forma de enquadra-

mento

No capıtulo 3 analisa-se o estado da arte nesta materia Introduzem-se diversas

tecnologias directamente relacionadas com o tema deste projecto exemplos de

aplicacoes que as usam e as razoes que fundamentam as escolhas de tecnologias

efectuadas

O capıtulo 4 contem o desenvolvimento do projecto Analisa-se a plataforma

WOW de gestao integrada de ordens de trabalho a tecnologia escolhida e

a forma como foi utilizada para implementar a capacidade de execucao offline

O capıtulo 5 descreve os resultado obtidos comparando-os com as expectativas

iniciais do projecto e apresenta desenvolvimentos futuros e possibilidades de

continuacaoaplicacao do conhecimento adquirido

No capıtulo 6 apresentam-se as conclusoes

4

Capıtulo 2

Enquadramento do Projecto

Neste capıtulo apresenta-se um breve resumo da evolucao das arquitecturas de

software cliente-servidor e a forma como estas se comparam a evolucao da Inter-

net procurando estabelecer uma analogia entre o percurso de ambas as tecnolo-

gias Compara-se o comportamento e arquitectura dos thin-clients as paginas web

estaticas a evolucao dos fat-clients as paginas interactivas Web 20 e Ajax e

defende-se que as OWA constituem um proximo passo logico e evolutivo aproxi-

mando a web do desktop Referem-se ainda os principais factores que justificam a

importancia das OWAs e a estreita relacao que tem com as Rich Internet Application

(RIA)s

21 Evolucao das arquitecturas de software

Os termos thin-client e fat-client sao utilizados quer para descrever arquitecturas

logicas (de software) quer para descrever arquitecturas fısicas (de hardware) Neste

capıtulo excepto quando seja dada indicacao em contrario estes termos referem-se

sempre a uma arquitectura logica

Adicionalmente quando se trata de arquitecturas cliente-servidor pode-se estu-

dar a arquitectura desenvolvida do sistema como um todo da arquitectura do servi-

dor ou da arquitectura do cliente Para evitar equıvocos em especial na seccao 213

especifica-se em cada caso qual o sistema estudado

211 Thin-clients

Um thin-client e um computador cliente ou software cliente que no contexto

de uma arquitectura cliente-servidor depende de um servidor central para as suas

5

Enquadramento do Projecto

actividades de processamento e proporciona um canal de entrada e saıda de in-

formacao entre o utilizador e o servidor remoto Este termo quando aplicado a

hardware refere-se habitualmente a um computador que se destina a ser utilizado

como cliente de rede sem armazenamento local e com capacidade de processamento

reduzida [Gro02b] mas o conceito que aqui se analisa refere-se a uma arquitectura

de software que remonta ao inıcio das aplicacoes cliente-servidor

No inıcio da historia da computacao terminais ligavam-se directamente a main-

frames responsaveis por todo o processamento Nesta arquitectura era necessario

desenvolver duas aplicacoes distintas uma aplicacao central no servidor (main-

frame) responsavel pela gestao de toda a informacao e por todas as operacoes de

comunicacao e uma aplicacao de visualizacao instalada no cliente (terminal) O

papel destes terminais era apenas disponibilizar ao utilizador um meio de comu-

nicacao (entrada e saıda) e apresentacao dos resultados do servidor Nao tinham

um papel activo no calculo nem na logica de negocio e frequentemente nao tinham

tambem nenhum mecanismo de armazenamento de dados

Como vantagens esta arquitectura apresenta uma reduzida necessidade de con-

figuracao e manutencao do lado do cliente Uma vez que o centro do processamento

e manipulacao de dados ocorre no servidor existe tambem uma centralizacao da

informacao [NJN00] que introduz um ponto crıtico de falha1 Actualizacoes e novas

funcionalidades sao faceis de distribuir uma vez que requerem apenas alteracoes no

servidor [Gro02a]

212 Fat-clients

Contrastando com os thin-clients nesta arquitectura os clientes implementam

ja uma parte da logica de negocio e sao responsaveis pelo processamento de dados

Estes fat-clients vieram responder a necessidade crescente de aplicacoes com um

nıvel de interactividade e capacidade de configuracao maior que as oferecidas pela

arquitectura thin-client descrita na seccao 211 Apesar de manterem a sua de-

pendencia do servidor podem tambem ser executados sem uma conexao activa uma

vez que dispoe de armazenamento de dados local o que lhes confere a capacidade

de persistencia de dados e do estado de execucao entre cada sessao

Foi disponibilizando este controlo sobre o estado da aplicacao bem como acesso

a recursos locais (por exemplo sistema de ficheiros e perifericos) que surgiram as

primeiras verdadeiras desktop applications No entanto cada cliente tinha que ser

separadamente instalado no computador pessoal de cada utilizador que pretendesse

utilizar ou interagir com a aplicacao e uma actualizacao ao servidor implicava in-

variavelmente uma actualizacao manual tambem no cliente Uma vez que nem todos

1NT single point of failure

6

Enquadramento do Projecto

Thin-clients Fat-clientsNao toma parte no processamento dedados nem possui acesso ao sistema deficheiros

Participa activamente no processa-mento de dados recorrendo ao sis-tema de armazenamento local para ar-mazenamento de dados

Nao mantem registo do estado logicoda aplicacao entre duas sessoes de uti-lizacao

O acesso ao armazenamento localpermite-lhe manter registo do estadologico da aplicacao entre duas sessoes

O thin-client nao necessita de qualquerinstalacao estando ldquopronto a utilizarrdquo

E geralmente necessario instalar aaplicacao para poder interagir com oservidor

Qualquer update no servidor reflecte-seimediatamente por todos os clientes

Embora a aplicacao cliente possa aler-tar para existencia de novas versoes asactualizacoes tem que ser manualmenteinstalados pelo cliente

O software do cliente destina-se apenasa apresentacao de dados e comunicacaocom o servidor sendo portanto de sim-ples implementacao

Como o software do cliente toma parteactiva no processamento de dadosa sua implementacao requer cuidadosadicionais

Grande mobilidade uma vez que todaa informacao e mantida no servidor

Parte da informacao podera estar ape-nas do lado cliente pelo que existemalgumas restricoes a sua mobilidade

Tabela 21 Comparacao entre thin-clients e fat-clients

os utilizadores actualizam regularmente as suas aplicacoes o servidor tem que estar

preparado para lidar com versoes antigas2 ou descontinuar os seus servicos a uma

parte da sua comunidade de utilizadores ate que estes actualizem os seus sistemas

Como os utilizadores passam a utilizar os seus recursos locais para armazenamento

de dados as alteracoes que nao sejam sincronizadas com o servidor estao apenas

disponıveis nos seus computadores pessoais o que introduz uma restricao a mobili-

dade

Pode-se afirmar que as vantagens dos thin-clients sao as desvantagens dos fat-

clients e que as vantagens dos fat-clients sao as vantagens dos thin-clients tal como

se ilustra na Tabela 21

213 Arquitecturas cliente-servidor

Introduzidos os termos thin-client e fat-client interessa reafirmar que ambos

podem ser vistos como arquitecturas cliente-servidor Um cliente define-se como

um solicitador de servicos e um servidor como um prestador de servicos tal como

definido por [Sch96] e [Sad97]

2NT backward compatibility

7

Enquadramento do Projecto

As arquitecturas cliente-servidor sao categorizadas pela modularizacao com que

sao desenhadas sendo consideradas as seguintes camadas

1 Interface grafica (front-end) atraves da qual os utilizadores interagem com

a aplicacao Quando este modulo e implementado separadamente dos outros

dois constitui uma aplicacao thin-client por si so uma vez que nao implementa

regras de negocio (embora possa definir validacoes de formularios de insercao de

dados por exemplo) A informacao introduzida pelo utilizador e enviada para

o servidor que processa o seu pedido e retorna uma resposta Este processo

repete-se ate que o utilizador atinja o seu objectivo ou se desligue do sistema

2 A logica de negocio tambem designada por camada intermedia que imple-

menta as regras de aceitacao e validacao de todos os dados introduzidos pelo

utilizador E tambem a plataforma de comunicacao que une a camada superior

de visualizacao com a camada de acesso a dados

3 A camada de dados inclui quer o sistema de persistencia de dados onde sao

armazenados os dados relevantes como tambem os mecanismos necessarios

para a sua pesquisa seleccao e alteracao

Os thin-clients quando observados no seu conjunto de cliente e servidor podem

ser vistos quer como sistemas de duas camadas quer como sistemas de tres camadas

dependendo apenas da forma como o servidor for implementado No caso de na

implementacao do servidor nao se distinguir a camada de acesso a dados da camada

da logica de negocio sao designados por sistemas de duas camadas Caso seja feita

esta distincao sao designados por sistemas de tres camadas Ambos os casos sao

ilustrados na Figura 21

Historicamente os fat-clients eram implementados numa arquitectura em duas

camadas Possuıam apenas um modulo de visualizacao de dados designado por

camada de interface e um modulo que implementava toda a logica de negocio e

regras de acesso a base de dados No entanto com a introducao de ligacoes mais

rapidas e de computadores pessoais com maior capacidade de processamento e so-

bretudo devido a complexidade crescente das aplicacoes a logica de negocio e a

camada de acesso a dados tornaram-se independentes Este modelo e designado por

arquitectura em tres camadas e e ilustrado na Figura 22

22 Evolucao na Internet

Ao analisar a evolucao das arquitecturas das aplicacoes desenvolvidas para a

Internet podemos encontrar um paralelismo com a historia da arquitectura de soft-

ware

8

Enquadramento do Projecto

Figura 21 Arquitectura de um sistema thin-client em duas camadas (a esquerda) e emtres camadas (a direita) Note-se a inclusao do servidor (mainframe) na definicao dascamadas desta arquitectura devido a forte dependencia cliente-servidor

221 Paginas web estaticas

Uma pagina web estatica devolve sempre a mesma resposta a todos os pedidos

para todos os utilizadores e em qualquer contexto utilizando o hipertexto como

forma de ligacao entre diversas paginas estaticas

A informacao e armazenada num servidor e o papel do cliente e apenas a apre-

sentacao da informacao Esta forma de disponibilizacao de informacao pode assim

ser comparada com os thin-clients descritos na seccao 211 o utilizador acede a

um website estatico para visualizar informacao sem que o cliente tome parte no

processamento A unica diferenca e que no caso da web estatica a informacao ap-

resentada e sempre a mesma enquanto que nos thin-clients era frequente existir a

possibilidade de insercao de dados no cliente e apos o seu processamento servidor

nova informacao poderia ser apresentada O hipertexto e utilizado para ligar as

paginas entre si numa rede de conteudos relacionados e a navegacao sıncrona era

feita atraves de cliques do rato a cada clique uma nova pagina era apresentada

Este modelo sıncrono e ilustrado na Figura 23

222 Paginas web interactivas e paginas web dinamicas

O JavaScript e uma linguagem interpretada de scripting que tem os browsers

como principal ambiente de acolhimento Os browsers utilizam uma Application

9

Enquadramento do Projecto

Figura 22 Arquitectura de um fat-client em duas camadas (a esquerda) e em tres camadas(a direita)

Programming Interface (API) publica para criar ldquoobjectosrdquo responsaveis por reflectir

e disponibilizar o Document Object Model (DOM) para o motor de JavaScript

A utilizacao mais frequente desta linguagem e a escrita de funcoes que sao em-

bebidas ou incluıdas em paginas web e que interagem com o DOM Uma vez que o

JavaScript e executado localmente (na maquina do cliente e nao no servidor) e capaz

de responder rapidamente a accoes do utilizador tornando a execucao de aplicacoes

no browser mais fluıdas o JavaScript pode tambem detectar accoes do utilizador

que o HTML nao pode tal como o pressionar de uma tecla

Em Dezembro de 1995 a Netscape Communications adicionou suporte para o

JavaScript no browser Netscape Navigator3 e em Agosto de 1996 o browser Internet

Explorer4 da Microsoft passou a tambem a suportar uma versao semelhante desta

linguagem (hoje todos os principais browsers suportam esta tecnologia)

Esta inovacao permitiu tornar os websites mais interactivos mas a sua utilizacao

esteve confinada apenas a este proposito durante um longo perıodo As paginas

passaram a responder activamente a accoes do utilizador (sendo uma das utilizacoes

3Netscape Communications ndash httpbrowsernetscapecom4Microsoft Internet Explorer ndash httpwwwmicrosoftcomwindowsproductswinfamilyie

10

Enquadramento do Projecto

mais vulgares a validacao de formularios) mas continuaram essencialmente estaticas

O JavaScript ainda nao era nesta altura utilizado para processar dados

Tambem nesta altura (1995ndash96) surgiram linguagens server-side como o PHP

Hypertext Preprocessor (PHP) e Active Server Pages (ASP) e o servidor passou a ter

um processamento de dados introduzidos pelo utilizador mais activo Generalizaram-

se as paginas dinamicas capazes de responder a insercao de dados ou outros pedidos

determinados por accoes do utilizador As paginas tornaram-se aplicacoes web ap-

plications

Uma definicao tradicional de web application e um conjunto de paginas web

logicamente agrupadas e geridas por uma unica entidade que tem como pontos de

entrada formularios de insercao de dados (web forms) Uma web application nao e

mais do que uma aplicacao que e acedida atraves de um browser Tem geralmente

uma arquitectura logica em tres (interface logica de negocio e camada de dados)

camadas e estao armazenadas num servidor

Ha dois tipos de web applications

bull Orientadas a apresentacao Sao web applications que geram paginas web in-

teractivas constituıdas por varios tipos de linguagens de anotacao (por exem-

plo HTML eXtensible Markup Language (XML)) e que apresentam conteudo

dinamico como resposta a pedidos efectuados pelo utilizador

bull Orientadas aos servicos Uma web application orientada aos servicos imple-

menta o ponto de acesso para um ou mais de um web service Sao geralmente

clientes de service oriented web applications

Uma vantagem significativa de implementar uma web application de forma a

suportar as funcionalidades padrao dos browsers e que estas terao o mesmo com-

portamento independentemente da plataforma e do browser a partir do qual serao

acedidas No entanto diferentes implementacoes de browsers devido a diferentes

interpretacoes dos padroes definidos tornam por vezes esta tarefa um pouco mais

complicada existindo inclusivamente na web guioes de compatibilidade para os difer-

entes browsers como [Smi07]

223 Web 20 e Ajax

O termo web 20 descreve uma tendencia de utilizacao e de design observada

na World Wide Web (WWW) com o objectivo de melhorar a criatividade partilha

de informacao e principalmente a colaboracao entre utilizadores Estes conceitos

levaram ao desenvolvimento e evolucao de comunidades online tais como redes so-

ciais wikis e blogues

11

Enquadramento do Projecto

O termo tornou-se mais conhecido apos a primeira conferencia OrsquoReilly Media

Web 20 em 2004 e apesar de sugerir uma nova versao da WWW nao se refere a

qualquer evolucao tecnologica mas apenas a alteracoes a forma como os utilizadores

se servem da web De acordo com Tim OrsquoReilly [OrsquoR06] ldquoWeb 20 e uma revolucao

na industria do software causada pela adopcao da web como uma plataforma e pela

tentativa de entendimento das regras para o sucesso nesta nova plataformardquo

O desenvolvimento da Web 20 serve-se muitas vezes de um outro conceito Ajax

O conceito que hoje conhecemos como Ajax muitas vezes incorrectamente de-

scrito como uma tecnologia foi originalmente criado para permitir o desenvolvimento

de web applications que se assemelhassem ainda mais a aplicacoes de desktop Este

conceito foi melhor descrito por [Gar05] como um conjunto de varias tecnologias

que podem ser utilizadas para melhorar a experiencia do utilizador de uma dada

web application introduzindo a capacidade assıncrona de envio de pedidos ou da

recepcao assıncrona de respostas As tecnologias mais frequentemente envolvidas

sao

bull eXtensible HyperText Markup Language (XHTML) e Cascading Style Sheets

(CSS) padrao para a apresentacao

bull interaccao dinamica atraves do DOM

bull troca e manipulacao de dados utilizando XML e eXtensible Stylesheet Lan-

guage Transformation (XSLT) ou JavaScript Object Notation (JSON)

bull pedidos assıncronos utilizando XMLHttpRequest [vK08]

bull JavaScript utilizado para integrar todas estas tecnologias

E importante frisar que o Ajax nao e um produto nem uma tecnologia E um

termo que descreve a utilizacao de um conjunto de tecnologias para o desenvolvi-

mento de web applications com um elevado grau de interactividade Comparativa-

mente as web applications tradicionais o Ajax introduz uma camada de visualizacao

diferente em tres importantes pontos

1 Do lado do cliente existe um motor que serve de intermediario entre a interface

da aplicacao e o servidor

2 A actividade do utilizador despoleta chamadas JavaScript em vez de um pedido

de pagina directamente ao servidor

3 Informacao codificada em XML em vez de paginas HTML e trocada entre o

servidor e o cliente

12

Enquadramento do Projecto

Isto significa que as paginas que utilizam Ajax contem um motor do lado do

cliente composto por um conjunto de funcoes JavaScript responsavel pela comu-

nicacao com o servidor e por actualizar a interface com o resultado dessa mesma

comunicacao

Na Figura 23 ilustra-se a natureza assıncrona do Ajax quando comparada com

as web applications tradicionais Como se pode observar adicionando um mecan-

ismo Ajax a uma web application eliminam-se diversos tempos de espera associados

a comunicacoes com o servidor uma vez que a interface nao fica ldquobloqueadardquo a es-

pera da resposta Obtem-se assim aplicacoes com um comportamento mais fluido

eliminando tempos de espera entre cada ldquocliquerdquo e melhorando a experiencia do

utilizador

23 Offline Web Applications

A informacao grafica (bem como folhas de estilo e scripts) tais como as ima-

gens que constituem o visual de uma web application e ja tratada de forma especial

pelos cada vez mais avancados sistemas de cache (armazenamento temporario) dos

browsers Mas estes nao sao ainda capazes de guardar conteudo criado pelo uti-

lizador nem de apresentar informacao independentemente do estado da ligacao

Numa altura onde se fala de servicos de Internet wireless municipalizados [Kha]

comunicacoes 3G e ligacoes de banda larga a alta velocidade a ligacao a rede global

continua a nao estar permanentemente disponıvel para os utilizadores Na WWW

encontra-se uma importante parte da informacao e das aplicacoes utilizadas para

criar e editar conteudos Por vezes informacao vital para a produtividade pode

desaparecer subitamente do mapa de acesso de um utilizador quando este entra no

metro num aviao ou mesmo quando se desloca para uma cidade ou paıs diferente

do habitual onde nao subscreve um plano de acesso que lhe garanta a ligacao

Permitir o acesso offline a estes recursos assume assim a sua importancia porque

permitira estender o alcance da informacao a locais onde nunca esteve antes e per-

mitira tambem melhorar o desempenho das web applications colocando informacao

mais perto dos utilizadores reduzindo a transferencia de dados apenas ao essencial

24 Comparacao

Nas evolucoes descritas neste capıtulo 2 pode-se observar que existe um par-

alelismo entre a evolucao das arquitecturas tradicionais cliente-servidor e a evolucao

a que se assiste na web O comportamento e arquitectura dos thin-clients assemelha-

se ao das paginas estaticas no sentido em que o browser nao toma parte em qualquer

13

Enquadramento do Projecto

processamento e serve apenas como uma plataforma de interaccao com o servidor

tal como os clientes descritos na seccao 211

A sua proxima evolucao os fat-clients trouxeram parte da capacidade de pro-

cessamento para o lado do cliente Na web foi tambem esta a inovacao tecnologica

a que se assistiu com a evolucao das tecnologias que permitiram a criacao de ver-

dadeiras aplicacoes e com a introducao do Javascript no browser dando ao cliente

a capacidade de processamento de dados A necessidade da separacao do codigo

em camadas logicas advem da crescente complexidade das web applications Esta

pratica permite entre outras coisas melhorar o processo de desenvolvimento e a

capacidade de manutencao de uma aplicacao

Os fat-clients tem tambem a capacidade de armazenamento de dados o que

permite a persistencia de informacoes entre duas sessoes e que algumas operacoes

sejam executadas sem a necessidade de comunicacao com o servidor Este facto pode

tambem ser uma realidade nas web applications com a adopcao das tecnologias OWA

Neste momento assiste-se a uma utilizacao cada vez maior da web como uma

plataforma de desenvolvimento A capacidade de cooperacao na edicao de conteudos

e a mobilidade proporcionada por esta plataforma sao os principais factores que

alimentam esta mudanca e pela primeira vez as aplicacoes tradicionais tem com-

peticao vinda de web applications A prova do reconhecimento da web como plataforma

de desenvolvimento pode ser retirada da aposta de empresas como a Adobe e Mi-

crosoft que lancaram publicamente ferramentas web complementares a produtos

seus tradicionalmente associados ao desktop ndash Acrobatcom5 e Microsoft Office

Live6 Dotar estas web applications da capacidade de execucao offline significa

aproximar a web e o desktop reunindo ldquoo melhor de dois mundosrdquo

As vantagens da mobilidade possıvel atraves da web a cooperacao na criacao e

edicao de conteudos e a possibilidade de utilizar aplicacoes sempre actualizadas e

sem necessidade de instalacao sao algumas das principais vantagens que promovem

esta mudanca que devido as preocupacoes associadas a usabilidade e experiencia do

utilizador esta fortemente associada ao desenvolvimento de Rich Internet Applica-

tion (RIA)s

5Adobe Acrobatcom httpwwwacrobatcom6Microsoft ndash httpsmallbusinessofficelivecom

14

Enquadramento do Projecto

Figura 23 Comparacao do modelo de web aplications sıncrono paginas estaticas e in-teractivas abordados nas seccoes 221 e 222 com o modelo de web applications Ajax(assıncrono) abordado na seccao 223 Figura adaptada de http www adaptivepath

com

15

Enquadramento do Projecto

16

Capıtulo 3

Estado da arte

Apesar de o conceito das OWAs nao ser absolutamente novo as tecnologias que

o suportam sao recentes Neste capıtulo descrevem-se quatro tecnologias que foram

tidas como principais candidatas para o desenvolvimento deste projecto Descrevem-

se ainda alguns exemplos de web applications que disponibilizam actualmente fun-

cionalidades offline e o processo da escolha da tecnologia a utilizar neste projecto

31 Gears

O Gears1 e uma extensao as funcionalidades do browser introduzido pelo Google

que tem como principal objectivo tornar possıvel a visualizacao de paginas de Inter-

net mesmo sem uma conexao disponıvel Encontra-se disponıvel para as platafor-

mas Windows Macintosh e Linux e oferece uma API de Javascript que permite

a scripts aceder a um mecanismo de armazenamento local baseado numa base de

dados SQLite

311 Arquitectura

Esta ferramenta e constituıda por tres componentes principais

bull LocalServer mdash Intercepta pedidos de paginas web e serve-as localmente

bull Database mdash Uma base de dados relacional construıda sobre SQLite

bull WorkerPool mdash Permite executar operacoes de computacao de uma forma

assıncrona sem afectar a capacidade de resposta e fluidez de execucao da web

application Assemelham-se a processos

1Google Inc ndash Mais informacao em httpgearsgooglecom

17

Estado da arte

LocalServer

O modulo LocalServer e uma cache de Uniform Resource Locators (URLs)

controlada pela web application Quando nao existe uma ligacao a Internet e e

feito um pedido para um URL presente nesta cache o LocalServer intercepta-o e

responde ao pedido localmente a partir do disco rıgido do utilizador A aplicacao

pode utilizar dois tipos diferentes de armazenamento local de URLs

bull ResourceStore ndash serve para capturar URLs utilizando exclusivamente a API

de Javascript disponibilizada para o efeito Uma aplicacao podera criar e

utilizar diversos ResourceStores simultaneamente para capturar ficheiros de

dados que necessitam de ser enderecados por um URL tal como um ficheiro

PDF ou uma imagem

bull ManagedResourceStore ndash serve para capturar um conjunto de URLs que estao

relacionados e que sao declarado num ficheiro de manifesto (especificado em

JSON) e que sao automaticamente actualizados O ManagedResourceStore

permite que o conjunto de recursos necessarios para correr uma web application

seja capturado e mantido actualizado automaticamente

A principal diferenca entre estes dois tipos de armazenamento de URLs e a forma

como sao actualizados os seus conteudos Os conteudos de um ManagedResourceStore

sao actualizados sempre que a versao contida no ficheiro de manifesto for alterada

enquanto que os conteudos de um ResourceStore nunca sao actualizados automati-

camente mas apenas quando for explicitamente ordenado pela aplicacao

O LocalServer e capaz de interceptar e servir localmente pedidos de HTTP e

HTTPS sempre que se reunam as seguintes condicoes

1 O URL encontra-se armazenado num ResourceStore ou ManagedResourceStore

2 O sistema de armazenamento local encontra-se activo (enabled = true) Se

o sistema de armazenamento local tiver o atributo requiredCookie o pedido

devera conter um cookie que lhe corresponda

O LocalServer nao necessita de monitorizar o estado da ligacao para atender aos

pedidos Na verdade sempre que as condicoes previamente enunciadas se verificarem

o LocalServer interceptara os pedidos e independentemente do estado da ligacao

a Internet servi-los-a a partir do disco rıgido local Cabera a aplicacao definir qual

o modo em que pretende executar um pedido (online ou offline) definindo o valor

de verdade da propriedade enabled

18

Estado da arte

Database

O modulo Database permite guardar dados da web application assegurando a

sua persistencia Os dados sao guardados de forma relacional no disco rıgido do uti-

lizador2 de acordo com o modelo de seguranca estabelecido pelo Gears3 significando

que uma aplicacao nao pode aceder a conteudos fora do seu domınio

WorkerPool

Nos web browsers uma operacao pesada de computacao pode tornar a interface

lenta e tornar menos agradavel a experiencia do utilizador O modulo WorkerPool

permite correr operacoes em background sem bloquear a interface com o utilizador

Os scripts executados numa WorkerPool nao activam os mecanismos de seguranca

do browser que mostram a mensagem ldquoA script on this page may be busy or may

have stopped respondingrdquo

O WorkerPool comporta-se como um conjunto de processos em vez de threads

Os Workers nao partilham qualquer estado de execucao o que significa que uma

alteracao a uma variavel num Worker nao afecta em nada a execucao de outro

Worker Alem disso os Workers nao herdam automaticamente nenhum codigo dos

seus pais Cada Worker e membro de um WorkerPool e os Workers podem in-

teragir entre si enviando mensagens em formato de texto ou JSON No entanto ha

tambem algumas limitacoes os Workers nao tem acesso ao DOM e objectos como

window ou document nao se encontram acessıveis Isto e consequencia de os Workers

nao partilharem o estado de execucao Mas tem acesso a todas as funcoes built-in

do Javascript A maioria das funcionalidades do Gears pode tambem ser acedida

atraves de uma variavel global especial definida como googlegearsfactory Para

outras funcionalidades especıficas os Workers podem ldquopedirrdquo a pagina principal para

continuar a execucao atraves do envio de mensagens

Outras funcionalidades

bull HttpRequest ndash Este modulo implementa a especificacao W3C XmlHttpRe-

quest definida em [vK08] tornando-a disponıvel para os workers e para a

pagina principal

bull Timer ndash Este modulo implementa a especificacao de timers tal como descrito

por [Hic08] e torna-os disponıveis para os workers e para a pagina principal

2Consultar httpcodegooglecomapisgearsapi_databasehtmldirectories3Consultar httpcodegooglecomapisgearssecurityhtml

19

Estado da arte

bull Factory ndash Esta classe e utilizada para instanciar todos os outros objectos da

API do Gears atraves do seu metodo create Este metodo pode ser utilizado

com os seguintes parametros

ndash betadatabase

ndash betahttprequest

ndash betalocalserver

ndash betatimer

ndash betaworkerpool

312 Goggle Gears em dispositivos moveis

O Gears esta tambem disponıvel em dispositivos Windows Mobile 5 e 6

Os dispositivos moveis estao pela sua natureza frequentemente desconectados

da Internet Mesmo quando possuem uma ligacao as latencias na transferencia de

dados em redes moveis tornam as aplicacoes pouco fluıdas mas o Gears permite

ultrapassar este obstaculo

O Gears funciona exactamente da mesma forma em dispositivos moveis equipados

com o Windows Mobile 5 e 6 como num computador comum Se uma aplicacao tiver

sido implementado com suporte para o Gears entao tambem estara preparada para

ser executada num dispositivo movel mas as limitacoes dos browsers disponıveis

para dispositivos moveis tem que ser consideradas Isto significa prever as condicoes

que permitam uma boa usabilidade devido aos pequenos ecras destes dispositivos

bem como o seu suporte limitado dos padroes do DOM CSS e JavaScript

32 Adobe AIR

O Adobe AIR4 e um runtime compatıvel com diversos browsers e sistemas opera-

tivos que pretende dar aos programadores a possibilidade de combinar diversas tec-

nologias de producao de conteudos para a Internet no desenvolvimento de Rich Inter-

net Application (RIA)s O Adobe AIR mantem uma relacao com o browser mas es-

tende as suas capacidades e tecnologias permitindo o desenvolvimento de aplicacoes

tambem para o ambiente de trabalho com janelas em tudo semelhantes as do sis-

tema operativo Segundo a Adobe o objectivo e complementar o browser dando

aos utilizadores (mas essencialmente aos programadores e equipas de desenvolvi-

mento) a escolha sobre como distribuir as suas aplicacoes Para este efeito o Adobe

AIR tem uma aproximacao diferente do Gears Em vez de ldquoestenderrdquo o browser

acrescentando-lhe funcionalidades o AIR permite tambem o desenvolvimento de

4Adobe - httpwwwadobecomproductsair

20

Estado da arte

aplicacoes que se destinam a ser executadas fora do ambiente do browser mas uti-

lizando as tecnologias comuns da Internet (por exemplo HTML CSS JavaScript

Flash Flex)[CDGH08]

A utilizacao desta tecnologia permite utilizar o browser ou o proprio runtime

Adobe AIR como plataforma de execucao da aplicacao

Na Tabela 31 faz-se uma comparacao das funcionalidades disponıveis de acordo

consoante se escolha o browser ou o desktop como plataforma base para a aplicacao

Uma vez que as aplicacoes Adobe AIR na plataforma desktop tem um caracter

persistente (sao instaladas no computador do utilizador) o Adobe AIR tem um

modelo de seguranca que se assemelha com o das tradicionais aplicacoes desktop

[Ada08] Este modelo e analisado nas seccoes 321 e 322 O ambiente em que

e executado o browser e restringido a execucao de web applications que podem

ser de varias origens (incluindo de origens anonimas ou sem confianca) O Adobe

AIR proporciona acesso a capacidades como acesso a ficheiros que necessitam da

confianca do utilizador

bull HTML ndash O desenvolvimento de aplicacoes para o Adobe AIR pode ser feito

com recurso a tecnologias de HTML e Ajax comuns utilizando as linguagens

de markup existentes distribuıdas como texto e interpretadas em execucao

(runtime)

bull Flash ndash Outra alternativa sera a utilizacao da linguagem Flash Permite a

renderizacao de graficos vectoriais e audiovıdeo com suporte nativo Utiliza

ActionScript para adicionar maior interactividade com o utilizador

bull Flex ndash O Flex e uma framework open source para o desenvolvimento de RIAs

usando Flash As aplicacoes Flex sao na realidade Flash sendo a principal

diferenca o ambiente de desenvolvimento

Como resultado uma aplicacao AIR podera ser implementada

bull Baseada em Flash ou Flex (aplicacoes cujo conteudo base e em ShockWave

Flash (SWF))

bull Baseada em Flash ou Flex tambem com HTML ou Portable Document Format

(PDF) Aplicacoes cujo conteudo de base e em FlashFlex (SWF) com HTML

(HTML JavaScript CSS) ou conteudo PDF incluıdo

bull Baseada em HTML Aplicacoes cujo conteudo base e em HTML Javascript

CSS

bull Baseada em HTML utilizando tambem FlashFlex ou PDF

21

Estado da arte

Os utilizadores interagem com uma aplicacao AIR da mesma forma que interagem

com outras aplicacoes com janelas nativas do seu sistema operativo O runtime e

instalado uma vez no computador do utilizador e a partir desse momento todas as

aplicacoes AIR terao o mesmo aspecto que qualquer outra aplicacao para o desktop

321 Seguranca

Permitir que uma web application aceda ao disco de armazenamento do utilizador

pode comprometer seriamente a sua seguranca Neste sentido o Adobe AIR tem

suporte para assinaturas digitais (Secure Sockets Layer (SSL)) que podem ser com-

pradas pelas equipas de desenvolvimento que o desejem e cujos certificados serao

apresentados ao utilizador no momento da instalacao Um outro aspecto ainda

relativo a seguranca e o mecanismo de isolamento de cada ambiente (sandbox )

322 Assinatura do codigo

O runtime AIR exige que todas as aplicacoes estejam digitalmente assinadas As

assinaturas digitais de codigo sao um processo que visa garantir a integridade da

aplicacao e a identidade do seu autor no momento da instalacao As equipas de

desenvolvimento podem ldquoassinarrdquo uma aplicacao utilizando um certificado atribuıdo

por uma Entidade Certificadora (Certification Authority) ou atraves de um certifi-

cado individual (self signed certificate) Neste momento o Adobe AIR suporta como

entidades certificadoras a Verisign e a Thawte [Ado08]

O instalador apresenta o nome de quem publica a aplicacao quando o codigo tiver

sido assinado com um certificado que apresente confianca ou que esteja encadeado

com um certificado que tenha ja sido aceite no computador em que se esta a instalar

a aplicacao

As equipas de desenvolvimento podem tambem assinar as aplicacoes com um

certificado auto-atribuıdo (um certificado criado por elas proprias) mas neste caso

o instalador apresentara estas aplicacoes como sendo de uma origem nao verificada

O AIR utiliza a infraestrutura publica de chaves [Ent07] suportada pelo arquivo

local do sistema operativo Para que a origem da aplicacao seja reconhecida o

computador onde a aplicacao AIR esta a ser instalada tem que confiar directamente

no certificado que foi utilizado para assinar a aplicacao ou confiar num certificado

que esteja num encadeamento logico de certificados confiados e que se ligue desta

forma ao certificado utilizado para assinar a aplicacao

Todas as aplicacoes AIR tem caracterısticas em comum independentemente da

tecnologia utilizada para o seu desenvolvimento (HTMLFlexFlash) No ambito

de uma aplicacao AIR existem um conjunto de APIs que estao disponıveis e que

tornam possıvel o acesso ao sistema local (leitura e escrita) e a recursos de rede que

22

Estado da arte

de outra forma nunca estariam acessıveis a partir de uma web application comum

Cada aplicacao AIR possui tambem diferentes nıveis de isolamento chamados secu-

rity sandboxes dependendo do tipo de conteudo que esta a ser carregado e do seu

objectivo

bull Isolamento ao nıvel da aplicacao5 ndash E a raiz de cada aplicacao AIR Este

nıvel de isolamento permite o acesso a APIs privilegiadas e especıficas do

AIR Em contrapartida e negado o acesso a algumas APIs que poderiam ser

facilmente utilizadas de forma maliciosa contra o utilizador final Importacao

dinamica de conteudos remotos e geralmente proibido e as tecnicas e mecan-

ismos de geracao dinamica de codigo sao fortemente restringidas Apenas

conteudo carregado directamente da directoria base da aplicacao podera ser

colocado neste nıvel de isolamento

bull Isolamento nao especıfico da aplicacao6 ndash contem todo o outro conteudo

que nao tenha sido carregado directamente para o isolamento da aplicacao

Isto inclui conteudo local e remoto Este tipo de conteudo nao tem acesso

directo as APIs do AIR e rege-se pelas mesmas regras tal como se tivesse sido

carregado por um browser a partir da mesma localizacao (por exemplo HTML

carregado a partir de um domınio remoto comporta-se da mesma forma que se

fosse acedido a partir do browser)

33 Mozilla Prism

331 XML User Interface Language

O eXtensible User Interface Language (XUL) e uma linguagem de anotacao

baseada em XML desenvolvida pela Mozilla Foundation que opera em aplicacoes

Mozilla multi plataforma tal como o Firefox O motor Gecko e a unica imple-

mentacao completa desta linguagem que foi desenhada sobre padroes web comuns

como CSS JavaScript e o DOM e permite o desenvolvimento de interfaces graficas

utilizando elementos pre-definidos tais como window box page textbox radio

button entre outros Infelizmente o XUL nao possui qualquer especificacao formal

ou implementacoes de inter-operabilidade para outros motores que nao o Gecko No

entanto a sua implementacao e licenciada em codigo aberto pelas licencas GNU Gen-

eral Public License (GPL) GNU Lesser General Public License (LGPL) e Mozilla

Public License (MPL)

Enunciam-se algumas caracterısticas desta linguagem

5NT application sandbox6NT non-application sandbox

23

Estado da arte

Liguagem de anotacao poderosa baseada em componentes (widgets) O ob-

jectivo do XUL e permitir a construcao de aplicacoes multi-plataforma em

claro contraste com o Dynamic HyperText Transfer Protocol (DHTML) que se

destina ao desenvolvimento de paginas web Por esta razao o XUL esta orien-

tado a componentes tais como janelas botoes e etiquetas em vez de paginas

cabecalhos de texto e ligacoes de hipertexto Investir tempo e esforco para

atingir este mesmo resultado em aplicacoes baseadas em DHTML compromete

frequentemente a complexidade e desempenho da aplicacao

Baseado em padroes O XUL e um dialecto XML baseado no padrao W3C XML

10 As aplicacoes escritas em XUL sao tambem baseadas em especificacoes

W3C adicionais como HTML 40 CSS DOM nıvel 1 e 2 JavaScript 15

incluindo ECMA-262 Edition 3 (ECMAscript)

Portabilidade entre plataformas Tal como HTML o XUL foi desenhado para

ser independente da plataforma em que e utilizado tornando as aplicacoes

facilmente portaveis entre sistemas operativos nos quais o Mozilla e suportado

Uma vez que o XUL oferece um nıvel de abstraccao dos componentes graficos

de interface que disponibiliza implementa a premissa ldquoum codigo para todas

as plataformasrdquo A interface grafica de todos os produtos centrais Mozilla

(browser instant messenger livro de enderecos) e escrita em XUL com um

unico codigo base que suporta todas as plataformas Mozilla

Separacao entre o nıvel de apresentacao e a logica de negocio Uma das

maiores preocupacoes no desenvolvimento para a Internet e a forte ligacao

entre estas duas camadas (interface e logica) Isto constitui um problema sig-

nificativo no desenvolvimento de grandes aplicacoes especialmente quando o

desenvolvimento e feito em ambientes de equipa porque as capacidades de de-

senvolvimento destas duas partes da aplicacao estao muitas vezes espalhadas

por diferentes elementos O XUL permite uma clara distincao entre a definicao

da aplicacao cliente e da logica de implementacao (XUL eXtensible Binding

Language (XBL) e JavaScript) apresentacao (CSS e imagens) internacional-

izacao (Document Type Definitions (DTDs) e etiquetas de texto em lınguas

especıficas guardados em ficheiros properties) O esquema grafico e apre-

sentacao de uma aplicacao XUL pode ser alterado de forma independente da

sua logica ou implementacao e a aplicacao pode ainda ser traduzida (interna-

tionalization) de forma independente da sua logica implementacao ou apre-

sentacao Este grau de separacao resulta em aplicacoes que sao mais faceis de

manter pelos programadores e facilmente adaptadas por designers e tradutores

24

Estado da arte

Facil adaptacao Outro benefıcio que advem do nıvel de separacao entre logica

de negocio e apresentacao oferecido pelo XUL e a facilidade com que se pode

adaptar uma aplicacao para diferentes clientes ou grupos de utilizadores Um

programador pode utilizar a mesma aplicacao base e adapta-la consoante as

necessidades atraves de diferentes temas (skins) e ficheiros de lınguas Desta

forma uma aplicacao escrita e desenvolvida em Ingles pode ser rapidamente

traduzida para Portugues e distribuıda com outra aparencia mais apropriada

ao cliente alvo

332 Prism

O Mozilla Prism e um browser simplificado e ldquointerpretadorrdquo de XUL (tambem

designado por XULRunner) que acolhe web applications sem a interface grafica ha-

bitual de um browser Baseia-se num conceito designado por Site Specific Browser

(SSB) Um SSB e uma aplicacao com um browser embebido desenhado para exe-

cutar apenas uma web application Nao possui os menus e barras de ferramentas

habituais Um SSB tem uma integracao com o sistema operativo e com o desktop

muito mais estreita do que uma web application acedida atraves de um browser uma

vez que e executado em janela propria

O Prism resulta de uma experiencia da Mozilla e visa reduzir as diferencas entre

as desktop applications tradicionais e as web applications Um dos aspectos focados e

a experiencia do utilizador Numa apresentacao oficial e dito que ldquo[o Prism] pretende

ser uma ponte entre as diferencas que existem entre as aplicacoes tradicionais de

desktop e as web applications explorando novos modelos de usabilidade enquanto

que a linha que as separa se continua a definirrdquo [Lab07]

34 HTML 5

A especificacao HTML 5 [Hic08] que se encontra em fase de desenvolvimento

pelo grupo WHATWG pretende ser uma norma de substituicao dos padroes HTML

4 XHTML 1x e do DOM2 HTML Uma das propriedades que o distingue das tec-

nologias que pretende substituir e precisamente o suporte para OWA e armazena-

mento de dados no cliente de uma forma relacional Nao sendo propriamente uma

tecnologia ndashmas antes uma especificacao ndashe aqui mencionada por ter servido como

referencia a diversas implementacoes de funcionalidades offline e por se considerar

que venha a ter um impacto significativo nas implementacoes de diversos browsers

Dion Almaer defendeu no seu blogue que o Gears era uma implementacao do

HTML 5 No seu artigo ldquoGears as a bleeding-edge HTML 5 implementationrdquo [Alm08]

o autor diz que ambos ndasho Gears e o HTML 5 ndashpretendem dar a web caracterısticas

25

Estado da arte

semelhantes e nao encontrar motivo de ldquocompeticaordquo entre as duas mas que en-

quanto o HTML 5 e uma especificacao o Gears e uma implementacao

No entanto tambem e verdade que o HTML 5 cobre muitos outros pontos para

alem das OWA que saem completamente fora do ambito do Gears Se esta es-

pecificacao atingir um estado de maturidade que possibilite a sua adopcao pelos

principais browsers tornando nativo do browser o suporte OWA entao deixara de

fazer sentido a existencia de uma extensao como o Gears

A especificacao HTML 5 disponibiliza duas APIs relevantes para o tema das

OWA

1 Uma base de dados baseada em SQL que permite o armazenamento de dados

do lado do cliente

2 Uma ldquocacherdquo HTTP que garante a disponibilidade das aplicacoes mesmo quando

o utilizador nao possui uma ligacao a Internet

Estas caracterısticas sao as bases da tecnologia das OWA e tem correspondencia

com os pontos analisados nas seccoes 311 e 311

35 Web applications que usam funcionalidades offline

Nesta seccao apresentam-se algumas web applications que actualmente disponi-

bilizam funcionalidades offline Estas aplicacoes foram escolhidas para uma analise

mais pormenorizada por utilizarem o Gears que tal como descrito na seccao 4 foi

a tecnologia escolhida para o projecto

351 Google Reader e Google Docs

O Google Reader7 e um leitor de feeds RSS Permite gerir a subscricao de varios

sites simultaneamente que disponibilizem conteudos neste formato e foi a primeira

web application da Google com uma versao offline publicamente acessıvel (desde

Junho de 2007)

O Google Reader implementa o modo ldquoutilizador deciderdquo oferecendo na sua

interface um botao que permite alternar entre os modos online e offline

O Google Docs8 e uma web application que permite a criacao e edicao de doc-

umentos de texto folhas de calculo e apresentacoes Era ja publico desde Janeiro

de 2008 que o Google estava a desenvolver uma versao OWA desta aplicacao mas o

acesso a uma versao experimental so foi possıvel a partir de 31 de Maio de 2008

7Google Reader - httpreadergooglecom8Google Docs - httpdocsgooglecom

26

Estado da arte

A implementacao das funcionalidades offline nestas duas aplicacoes seguiu difer-

entes aproximacoes principalmente porque o Google Reader apresenta ao utilizador

informacoes que sao fornecidas por fontes externas enquanto que no Google Docs

a informacao e criada e editada pelo utilizador sobre a forma de documentos

A diferente origem da informacao implica que no Google Reader seja necessario

prever casos de excepcao tal como existirem demasiados itens que necessitam de

ser transferidos para o cliente Nao observar este ponto causa um problema grave

de usabilidade e para evitar tempos de espera demasiado longos e uma interface

com pouca capacidade de resposta as accoes do utilizador o Google Reader apenas

transfere para o cliente os dois mil itens mais recentes na transicao para o modo

offline

352 Remember the Milk

O Remember The Milk9 e uma web application desenvolvida por uma equipa

Australiana que proporciona funcionalidades de agenda gestao de tempo e de tare-

fas e foi uma das primeiras aplicacoes independentes do Google a adoptar o Gears

para acessos em modo offline Permite que os seus utilizadores facam uma gestao

de tarefas agrupando-as em listas adicionando-lhes campos de informacao adicional

ou dando-lhes informacao geografica (recorrendo ao servico Google Maps10) Entre

a sua lista de funcionalidades encontra-se ainda a possibilidade de importar e ex-

portar eventos no formato iCalendar (ics) etiquetas (tags) em tarefas publicacao

Really Simple Syndication (RSS) e partilha de categorias de tarefas de acordo com

diferentes nıveis de permissoes de acesso definidos pelo utilizador

353 MySpace e WordPresscom

O MySpace uma das maiores social networks na Internet anunciou recente-

mente que vai disponibilizar uma versao do seu cliente de e-mail que utiliza o Gears

para acelerar o seu desempenho Numa fase inicial estara disponıvel apenas para

utilizadores que tenham cinco mil ou mais mensagens na sua caixa de correio e

permitira efectuar pesquisas muito mais rapido que a sua versao online

O servico de blogs Wordpresscom anunciou tambem o inıcio da utilizacao desta

tecnologia com o fim de melhorar o desempenho A versao que utiliza esta tecnologia

descarrega e armazena no cliente um conjunto de imagens e scripts que passam a

ter preferencia sobre os seus congeneres online e que permitem acelerar o processo

de carregamento da aplicacao e visualizacao de blogs

9Remember The Milk ndash httpwwwrememberthemilkcom10Google Maps ndash httpmapsgooglecom

27

Estado da arte

O MySpace e o Wordpresscom sao dois exemplos da utilizacao da tecnologia

OWA para optimizacao de web application ja existentes Sem pretenderem disponi-

bilizar uma versao que seja totalmente offline fazem uso do Gears para armazenar no

cliente parte dos recursos frequentemente acedidos na visualizacao das suas paginas

36 Escolha da tecnologia

Apos a analise das tecnologias apresentada nas seccoes 31 a 34 foi necessario es-

tudar a adequacao de cada uma delas ao projecto em questao Desde logo e possıvel

observar que nem todas se dedicam apenas a OWA Por exemplo o Adobe AIR

apesar de ter suporte para OWA apenas disponibiliza algumas das funcionalidades

identificadas como mais indicadas para a execucao do projecto quando utilizado

na sua vertente desktop tal como exposto na Tabela 31 mas a utilizacao desta

vertente implicaria o desenvolvimento de novas interfaces e de novas formas de co-

municacao (troca de mensagens XML ou JSON) A vertente web do Adobe AIR

foca-se mais especificamente nas Rich Internet Applications e permite a reutilizacao

do codigo ja existente (exigindo naturalmente a sua adaptacao e a implementacao

das funcionalidades pretendidas)

A tecnologia escolhida para a realizacao deste trabalho foi o Gears sendo que

um dos principais factores a influenciar esta opcao foi a liberdade introduzida pela

sua licenca Berkeley Software Distribution (BSD)11

Considerou-se o funcionamento desta ferramenta extremamente adequando a

aplicacao no WOW uma vez que o seu principal objectivo e precisamente tornar

possıvel a execucao offline de uma pagina web e por virtude deste facto o Gears tem

uma API concisa e de simples aplicacao pratica uma vez que nao possui quaisquer

outros elementos distractores O funcionamento do seu ManagedResourceStore ex-

emplificado na Figura 31 com a capacidade de actualizacao de recursos definidos

num ficheiro manifesto especificado em JSON pesou tambem nesta decisao

11Sobre a licenca BSD consultar httpwwwopensourceorglicensesbsd-licensephp e http

wwwlinfoorgbsdlicensehtml

28

Estado da arte

Figura 31 Esquema UML do processo efectuado pelos recursos do Gears do tipoManagedResourceStore para a actualizacao dos conteudos definidos no ficheiro manifesto

29

Estado da arte

Funcionalidade RIAs no browser RIAs no desktop

Disponibilidadeda aplicacao

As aplicacoes podem ser facil-mente exploradas e utilizadas

As aplicacoes quando instal-adas tem maior grau de fun-cionalidades e persistencia

Instalacao Nao e necessario qualquer tipode instalacao

As aplicacoes sao instaladasatraves do browser ou descar-regadas e instaladas comouma aplicacao tradicional

Actualizacoes Aplicacoes sao actualizadascarregando conteudos paraum website

O AIR disponibiliza uma APIque permite que as aplicacoessejam actualizadas de umaforma

Sistemas opera-tivos suportados

As aplicacoes podem ser exe-cutadas em diversos sistemasoperativos e browsers

As aplicacoes sao multi-plataforma e podem serinstaladas e executadas emdiversos sistemas operativos ebrowsers

Linguagens deprogramacao

Javascript e disponibilizadopelo browser e ActionScripte disponibilizado pelo AdobeFlash Player

Maquinas virtuais deJavascript e ActionScriptcompatıveis com o browser

Capacidade deexecucao embackground

As RIAs podem ser execu-tadas numa janela do browser

As aplicacoes podem ser ex-ecutadas em background edisponibilizar notificacoes talcomo uma aplicacao tradi-cional

Persistencia A actividade esta limitada asessao do browser Quando obrowser e encerrado toda ainformacao e descartada

As aplicacoes sao instaladas eestao disponıveis no desktopPodem armazenar informacaolocalmente e estao disponıveisoffline

Integracao com odesktop

Integracao com o desktop lim-itada devido a restricoes im-postas pelo browser

As aplicacoes podem acederao sistema de ficheiro ao clip-board eventos notificacoesetc

Controlo da inter-face com o uti-lizador

As aplicacoes sao acedidasatraves de uma janela dobrowser que tem os seusproprios controlos e visualgrafico

As aplicacoes tem um vi-sual grafico proprio em janelapropria

Armazenamentode dados

As aplicacoes tem armazena-mento limitado que pode serreescrito pelo browser

As aplicacoes tem acesso a to-talidade do espaco disponıvellocalmente e a uma base dedados com a possibilidade deencriptacao

Tabela 31 Comparacao das funcionalidades oferecidas pelo Adobe AIR para as platafor-mas web e desktop

30

Estado da arte

Aplicacao Modo de execucao utilizadoGoogle Reader Utiliza o modo ldquoutilizador deciderdquo disponibilizando

ao utilizador um botao para alternar entre os modosonline e offline Como lida com informacao recol-hida de fontes externas de natureza frequentementeefemera o processo de sincronizacao apenas transfereos dois mil itens mais recentes quando passa ao es-tado offline Neste modo sao ainda guardadas in-formacoes de itens lidos e etiquetas atribuıdas quesao sincronizadas com o servidor quando o utilizadorvoltar a activar estado online

Google Docs Utiliza o modo ldquoaplicacao deciderdquo permitindo que outilizador edite os conteudos de documentos de textofolhas de calculo e de apresentacoes independente-mente do estado da ligacao desde o momento em queas funcionalidades offline sao activadas A aplicacaofaz pequenas sincronizacoes com o servidor sempre quenecessario

Remember the Milk Utiliza um modo hıbrido entre ldquoaplicacao deciderdquo eldquoutilizador deciderdquo A aplicacao encarrega-se da sin-cronizacao de dados mas disponibiliza um controlona sua interface que permite despoletar manualmenteeste processo para situacoes em que o utilizador fez al-teracoes recentes e pretende usufruir das capacidadesoffline imediatamente

MySpace O MySpace anunciou a utilizacao de mecanismos dearmazenamento de dados no cliente com recurso atecnologias OWA para melhorar o desempenho doseu cliente web de correio electronico nomeadamenteno que diz respeito a operacoes de pesquisa e or-denacao Inicialmente esta funcionalidade estara ape-nas disponıvel para utilizadores com cinco mil ou maismensagens na sua caixa de correio mas nao e aindaclaro se sera disponibilizada uma versao totalmenteoffline

Tabela 32 Resumo da utilizacao de tecnologias OWA em algumas web applications con-sideradas na analise do estado da arte

31

Estado da arte

32

Capıtulo 4

Desenvolvimento

Neste capıtulo introduz-se a aplicacao WOW e apresenta-se o estudo que foi

feito da adequacao de cada tecnologia para a implementacao da funcionalidade of-

fline nesta plataforma Fazem-se diversas consideracoes sobre opcoes a tomar na

concepcao de OWAs e problemas comuns na sua implementacao bem como sug-

estoes para os resolver O WOW e uma aplicacao ja existente de gestao de ordens

de trabalho e do fluxo de tarefas numa empresa ou organizacao

41 Como ficar offline

Na maior parte das web applications de hoje nao existe uma camada de dados

real A aplicacao exemplificada na Figura 41 ao longo da sua execucao acede

directamente a sua unica fonte de dados (o servidor) atraves de chamadas Ajax sem

que exista uma separacao clara destas duas camadas

Para que uma web application seja capaz de ser executada sem uma ligacao

activa a Internet e mantenha o seu caracter dinamico torna-se necessario incluir

Figura 41 Exemplo de uma arquitectura de uma web application sem uma camada deabstraccao de dados Figura adaptada de http gears google com

33

Desenvolvimento

Figura 42 Exemplo de uma arquitectura de uma web application com uma camada deabstraccao de dados Figura adaptada de http gears google com

um mecanismo de armazenamento de dados local seja uma base de dados ou a

capacidade de acesso ao disco No entanto este mecanismo introduz dois problemas

1 Qual das fontes de dados utilizar quando um utilizador faz um pedido de

informacao

2 A necessidade de implementar uma camada de acesso a dados que seja coerente

quer se use o servidor remoto ou local

Por exemplo em vez de a aplicacao Ajax fazer um pedido relativo as contas de

todos os utilizadores em formato JSON directamente ao servidor remoto podera ao

inves fazer o pedido a um objecto intermedio da camada de dados Este objecto

demonstrado na Figura 42 sera responsavel por implementar uma interface de

acesso a base de dados e retornar um objecto JavaScript com uma representacao da

resposta do servidor

Mas a existencia de uma segunda fonte de dados torna recomendavel tambem

a implementacao de uma camada de data switching que em funcao da existencia

de conexao a Internet e da necessidade de actualizacao dos dados decide se faz o

pedido ao servidor remoto ou se fornece os dados presentes localmente Este objecto

apresentado na Figura 43 decidira de forma transparente para o utilizador se le ou

escreve os dados localmente ou se os enviapede ao servidor remoto e pode tambem

iniciar o processo de convergencia de dados e de resolucao de conflitos

411 Funcionalidades disponıveis em modo offline

Por razoes praticas e provavel que nem todas as funcionalidades da aplicacao

possam ser disponibilizadas em modo offline E necessario escolher quais as fun-

cionalidades a disponibilizar no modo offline da aplicacao e implementar a logica

que decide quando utilizar a base de dados local ou o servidor remoto Apesar do

acesso a base de dados local ser muito mais rapido do que aceder ao servidor o

acesso local nem sempre e preferido Ha varias razoes que podem tornar necessario

escolher o acesso ao servidor em vez do acesso local

34

Desenvolvimento

Figura 43 Exemplo de uma arquitectura de uma web application com uma camada deabstraccao de dados e um data switch Figura adaptada de http gears google com

1 A informacao pode ter uma natureza efemera e nao fazer sentido guarda-la

localmente Exemplo dados em tempo real da bolsa de valores de Lisboa

2 Algumas aplicacoes lidam com informacao que so faz sentido na presenca de

uma ligacao Exemplo Instant Messaging

3 A aplicacao podera escolher apenas guardar a informacao acedida mais fre-

quentemente Exemplo para o utilizador poder alterar a lıngua de apre-

sentacao da aplicacao os conteudos terao que ser guardados em todas as

lınguas disponibilizadas pela aplicacao O custo de implementacao de algu-

mas funcionalidades pode nao compensar o benefıcio

4 A capacidade de processamento ou de armazenamento de dados pode inviabi-

lizar algumas funcionalidades offline Exemplo se uma dada funcionalidade

necessita de uma capacidade de armazenamento de dados para alem do razoavel

de um computador pessoal para ser util (visualizador de mapas)

42 Modos de execucao

Um aspecto que e necessario estudar para qualquer web application que se deseje

disponibilizar offline prende-se com tres modos de execucao que devem ser consid-

erados

1 Utilizador decide o modo de execucao A aplicacao tem modos distintos

de execucao para os estados online e offline geralmente indicados na interface

com o utilizador O utilizador e informado do estado da ligacao e participa na

alteracao de estado de execucao da aplicacao interagindo com a sua interface

2 Aplicacao decide o modo de execucao Pode ser implementado na propria

aplicacao um mecanismo de deteccao do estado da ligacao (por exemplo atraves

35

Desenvolvimento

de chamadas Ajax periodicas) transitando de estado e sincronizando automati-

camente Desta forma o utilizador nao precisa de participar na alteracao de

estado a menos que exista um conflito de dados que requeira a sua atencao

3 Aplicacao assume sempre o estado offline Outra hipotese sera imple-

mentar uma web application que assume sempre estar na ausencia de uma

ligacao ao servidor de dados Esta aplicacao responde aos pedidos do uti-

lizador efectuando pedidos de informacao ao servidor mas nao dependendo

de uma resposta valida para mostrar a informacao que ja tinha disponıvel an-

teriormente A sincronizacao de dados com o servidor e tentada sempre que

existam dados para submeter e uma accao do utilizador

421 Modo ldquoutilizador deciderdquo

Neste modo de execucao quando a aplicacao esta online comunica com o servidor

remoto quando esta offline comunica com a base de dados local A informacao tem

que ser sincronizada sempre que se muda de modo A principal vantagem desta opcao

e que e a mais simples de implementar mesmo para uma aplicacao ja existente e

portanto uma forma expedita de disponibilizar uma OWA No entanto tem tambem

algumas desvantagens que devem ser consideradas

1 O utilizador tem que se lembrar de fazer a alteracao de estado de execucao

Caso contrario podera estar a trabalhar inadvertidamente numa versao offline

com dados antigos ou nao ter a informacao necessaria se perder subitamente

a ligacao

2 Se a ligacao for intermitente o utilizador tera ou que escolher um dos modos

de execucao ou estar constantemente a trocar

3 Uma vez que a base de dados nao esta sempre actualizada nao podera ser

utilizada para melhorar a rapidez de execucao da aplicacao quando em modo

online

422 Modo aplicacao decide

A deteccao do estado da ligacao pode ser implementada atraves de um pedido

assıncrono ao servidor tal como ilustrado na Figura 44 O resultado deste pedido

definira o estado online (em caso de sucesso) ou offline (em caso de falha) A

sincronizacao de dados podera ser feita sempre que ocorra uma transicao do es-

tado offline para o estado online No entanto este metodo nao se revela eficiente

36

Desenvolvimento

Figura 44 Esquema grafico ilustrando uma OWA executando no browser utilizando ummodo de execucao do tipo ldquoaplicacao deciderdquo com deteccao automatica do estado daligacao via pedidos Ajax assıncronos a cada cinco segundos

para grandes aplicacoes uma vez que requer a troca de mensagens demasiado fre-

quentes com o servidor que se destinam exclusivamente a monitorizacao do estado

da ligacao

423 Modo ldquoaplicacao assume o estado offlinerdquo

Uma aplicacao transparente funciona assumindo sempre que esta em modo of-

fline ou pelo menos que pode perder a ligacao a qualquer momento Neste modo

tira-se o maximo partido do armazenamento local e fazem-se pequenas mas contınuas

sincronizacoes com o servidor sempre que este esteja disponıvel A sincronizacao de

dados tambem e feita sempre que se volta ao estado online

As vantagens de uma web application transparente sao as seguintes

bull Uma melhor experiencia para o utilizador uma vez que este nao tem que se

preocupar com o estado da ligacao ou com a transicao de estados

bull A aplicacao funciona de forma coerente mesmo que a ligacao seja intermitente

bull Uma vez que o armazenamento local e mantido actualizado pode ser utilizado

para melhorar o desempenho da aplicacao

Foram identificadas as seguintes desvantagens

bull E mais difıcil de implementar e a sincronizacao acarreta cuidados especiais

bull E necessario um cuidado adicional para evitar que as operacoes de sincronizacao

frequentes que ocorrem automaticamente nao afectem os tempos de resposta

da aplicacao

bull Os testes a aplicacao sao mais complexos uma vez que a sincronizacao de dados

nao ocorre em resposta a uma accao do utilizador

37

Desenvolvimento

43 Sincronizacao de dados

A sincronizacao de dados consiste na capacidade de identificar e transferir pe-

riodicamente a versao mais actual dos dados entre o cliente e o(s) servidor(es)

Independentemente do modo de execucao escolhido e mesmo do estado da ligacao

do utilizador a informacao armazenada localmente e a informacao armazenada no

servidor estarao por vezes dessincronizadas Isto podera acontecer sempre que por

exemplo

bull O utilizador faz alteracoes em modo offline

bull A informacao e partilhada e pode ser alterada por uma entidade externa

bull A informacao e fornecida por uma entidade externa

Resolver estas diferencas de forma a que a informacao local e remota encontrem

a igualdade chama-se sincronizacao de dados Ha varias aproximacoes possıveis

para este efeito que dependem da natureza da aplicacao cada uma com vantagens

e desvantagens

A capacidade de suportar a mobilidade dos utilizadores torna-se cada vez um

ponto mais importante de uma web application Para uma organizacao de dimensao

global e vital garantir que os seus colaboradores tem acesso a mesma informacao

que tem disponıvel nos seus postos de trabalho mesmo quando estao fora Na maior

parte dos casos estes colaboradores terao acesso a um computador portatil um

desktop Smartphone ou PDA e atraves destes poderao ter acesso a sua informacao

directamente atraves de ligacoes encriptadas Virtual Private Network (VPN) de um

servidor web ou de outro mecanismo de rede

Esta solucao e simples de implementar mas infelizmente para a maioria dos

colaboradores com grande factor de mobilidade nao e satisfatoria As principais

desvantagens sao as seguintes

bull Requisitos de ligacao Para permitir que os utilizadores acedam a sua in-

formacao e necessario garantir a capacidade constante de comunicacao pelo

menos durante o tempo necessario que assegure a sua transferencia

bull Velocidade de ligacao sem persistencia de dados e em ligacoes de fraca

qualidade a usabilidade por vezes torna-se inaceitavel

bull Ponto crıtico de falha Com este tipo de solucao todos os utilizadores de-

pendem da base de dados que armazena informacao vital para o funcionamento

do cliente

38

Desenvolvimento

bull Scalability do servidor A medida que novos utilizadores sao adicionados ao

sistema o desempenho do servidor e afectado levando a necessidade de maior

capacidade de armazenamento eou processamento

De acordo com a documentacao da Microsoft Sync Framework [Mic08] uma

solucao alternativa consiste em implementar uma Occasionally Connected Appli-

cation (OCA) Uma OCA permite a um utilizador remoto continuar a aceder a

sua informacao mesmo depois de perder a ligacao mas em vez de recorrer a um

servidor recorre a informacao armazenada no seu dispositivo local Para preencher

localmente a informacao que o utilizador necessita uma OCA possui mecanismos

de sincronizacao de dados que sao oferecidos por esta framework

431 Quando sincronizar

Uma das solucoes mais simples de implementar passa por disponibilizar um

mecanismo manual que despoleta a sincronizacao Diz-se manual porque e o uti-

lizador que escolhe quando sincronizar e pode ser implementada simplesmente

fazendo o upload de toda a informacao para o servidor e depois fazendo o download

da copia mais recente da informacao antes de voltar a ficar offline Para que esta

seja uma opcao viavel e necessario que

bull O volume de dados seja suficientemente pequeno para que possa ser transferido

do servidor para o cliente num espaco de tempo aceitavel

bull Que o utilizador indique explicitamente que quer mudar para o estado offline

ou online pressionando um botao da interface

Contudo podem ser identificados alguns problemas relacionados com esta abor-

dagem

bull Os utilizadores nem sempre podem prever o estado das suas ligacoes A ligacao

pode-se perder subitamente ou ter um caracter intermitente

bull O utilizador pode esquecer-se de efectuar a sincronizacao

Outra opcao sera conjugar a sincronizacao de dados com o modo de execucao

transparente A sincronizacao ocorre automaticamente em background de forma

nao intrusiva para o utilizador A aplicacao comunica com o servidor regularmente

efectuando pequenas trocas de dados com o objectivo de manter o sincronismo da

informacao local e remota Esta abordagem pode ser implementada com pedidos

Ajax assıncronos e regulares ao servidor o que permite manter a interaccao com a

interface fluıda evitando bloqueios Estes pedidos sao feitos prevendo as situacoes

39

Desenvolvimento

de disponibilidade ou indisponibilidade (timeout) do servidor Uma outra opcao

sera permitir que o servidor comunique essas alteracoes utilizando Comet1 tal como

descrito em [Wil06] e [Rus06] As vantagens destas aproximacoes sao

bull A informacao esta disponıvel a qualquer altura que o utilizador decida ficar

offline ou que a ligacao seja acidentalmente perdida

bull O desempenho da aplicacao pode ser melhorado quando se estiver a utilizar

uma ligacao a Internet lenta uma vez que o acesso a dados locais e mais

eficiente do que a consulta de dados ao servidor

44 WOW

O WOW e uma plataforma integrada de gestao de ordens de trabalho ja ex-

istente e desenvolvida pela Critical Software SA a qual se pretende adicionar a

capacidade de execucao offline Esta aplicacao e extremamente dinamica e con-

figuravel com um conjunto extremamente rico de funcionalidades das quais se

destacam

bull Gestao de Ordens de Trabalho ndash suportando a gestao dos pedidos desde a

sua criacao ate ao seu fecho tomando em conta os diferentes tipos de pedidos

(ordens de trabalho pedidos de informacao melhorias resolucao de problemas

etc) e diferentes tipos de accoes possıveis para cada um (Figura 45)

bull Monitorizacao de alteracoes ndash Historico de mudancas anexos e estados criando

relatorios de alteracao automaticamente (o que por quem e quando)

bull Uso de Service Level Agreements (SLAs) ndash E possıvel associar a um pedido um

SLA que define qual o perıodo de tempo atribuıdo a resolucao de um pedido

controlando e agilizando a resolucao do mesmo

bull Utilizacao de queries de utilizador configuraveis que permitem acesso rapido

a determinadas ordens de trabalho de acordo com o filtro configurado (por

exemplo ldquoPara mimrdquo ldquoPara o Grupordquo ldquoPelo Grupordquo)

bull Gestao do relacionamento entre pedidos

bull Pesquisa e filtragem de ordens de trabalho

bull Exportacao de dados em formatos padrao (PDF DOC ou XLS)

bull Integravel com solucoes externas

40

Desenvolvimento

Figura 45 Detalhe de um conjunto possıvel de estados e respectivas transicoes para umadada ordem de trabalho no WOW desde a sua submissao no sistema ate a sua conclusaoem fecho ou cancelamento Esta figura representa apenas um exemplo ja que o mapa deestados para uma ordem de trabalho e dinamico e pode ser alterado por um administradorFigura retirada de uma brochura promocional do WOW Critical Software SA

A utilizacao de uma ferramenta deste tipo por parte de uma empresa ou orga-

nizacao oferece vantagens quer a gestao de topo quer aos colaboradores individuais

para os colaboradores individuais o WOW e uma aplicacao onde estao registadas

todas as tarefas contribuindo activamente para o desenvolvimento em ambientes

multi-tarefa e para a organizacao pessoal das tarefas de acordo com prioridades

Para a gestao de topo esta ferramenta permite obter uma visao global do estado da

organizacao em termos de tempo gasto por tarefa executada sendo uma mais valia

para a previsao e gestaoalocacao de recursos

45 Visao geral sobre a arquitectura do WOW

O WOW e interessante nao so do ponto de vista de produto como tambem do

ponto de vista de plataforma Existem diversos plug-ins que estendem as funcional-

idades do WOW e existem ate projectos que pretendem usar a arquitectura do

WOW para criar produtos com fins diferentes do inicial (por exemplo o WOW-

Storm ndash um sistema de registo e classificacao social de ideias)

De modo a conseguir ter essa expansibilidade a plataforma WOW assenta sob

uma arquitectura distribuıda modular e expansıvel com uma componente central

ndash o core ndash estruturado em camadas logicas E no core que se situam todas as

1O Comet e um conceito semelhante ao Ajax introduzido por Alex Russel mas no qual e o servidor quetoma a iniciativa de ldquoenviarrdquo os dados ao browser sem que este tenha que efectuar um pedido Tambem econhecido por Ajax Push Reverse Ajax ou HTTP Streaming

41

Desenvolvimento

funcionalidades base da aplicacao quer a nıvel logico funcional e de apresentacao

quer a nıvel de gestao e configuracao

E possıvel a execucao de varias instancias do core simultaneamente em servidores

distintos o que permite a alta escalabilidade e disponibilidade desta aplicacao A

consistencia dos dados fica sempre garantida atraves da partilha da base de dados

e pelo balanceamento dos pedidos uma vez que cada um e encaminhado para uma

unica instancia

O WOW apresenta tambem a vantagem de ser uma plataforma extensıvel E

possıvel adicionar novas caracterısticas a plataforma atraves de componentes que se

podem ser divididos em duas categorias plugins e connectors

Os plugins sao componentes que se encontram no mesmo no fısico que a aplicacao

partilhando do mesmo contexto de execucao do core Sao assim uma forma mais

directa de obter informacao da plataforma visto que nao possuem restricoes de

acesso aos dados nem dependencias externas A arquitectura deste componente tera

assim que permitir varias execucoes instanciadas cada uma associada a um core

Por outro lado os connectors sao componentes que se encontram distribuıdos

comunicando externamente com o core Quer a sua execucao quer a obtencao

dos dados estao assim dependentes de interfaces de comunicacao externas que a

plataforma disponibiliza Estes componentes ao contrario dos plugins sao instan-

ciados unicamente e recorrem ao protocolo de comunicacao Java Messaging Service

(JMS) para comunicar com o core

46 WOW Offline

Para alem das opcoes tomadas relativamente a tecnologia a utilizar surgiu

tambem a necessidade de optar por um dos modos de execucao apresentados na

seccao 42

Das tres opcoes possıveis foi o modo ldquoaplicacao assume o estado offlinerdquo descrito

na seccao 423 que mereceu a maior atencao uma vez que reune as vantagens de

uma experiencia mais positiva para o utilizador (uma vez que este nao tem que

participar activamente na alteracao do modo execucao como descrito na seccao 421)

e nao constitui uma sobrecarga excessiva para servidor (como o modo abordado na

seccao 422)

No entanto esta opcao comprometia a complexidade da implementacao para alem

dos objectivos propostos para este projecto e para cumprir o prazo dado foi tomada

a decisao de implementar o modo ldquoutilizador deciderdquo especificando apenas de forma

teorica o modo ldquoaplicacao assume o estado offlinerdquo

As caracterısticas do Gears foram ja descritas na seccao 31 Na Figura 47

mostra-se a sua forma de funcionamento quando integrado numa web application

42

Desenvolvimento

Nesta figura representa-se o modulo LocalServer do Gears como um ponto de de-

cisao Aqui sao testadas as condicoes que determinam se o pedido sera interceptado e

servido localmente ou se prossegue para uma maquina remota E tambem represen-

tada uma base de dados que corresponde ao modulo Database mas que podera nao

ser utilizada Este modulo tal como o modulo Workerpool tem caracter opcional

e sao utilizados consoante os requisitos da aplicacao

A plataforma WOW lida com mais dados do que e necessario passar para o

lado do cliente Em conformidade com o ja exposto na seccao 411 volta-se a

frisar que nao se pretende recriar toda a logica de negocio nem os conteudos da

base de dados no cliente pela sua complexidade e volume de dados Pretende-se

pelo contrario permitir que os utilizadores tirem partido da capacidade de poder

consultar as suas ordens de trabalho quando nao dispoe de uma ligacao transferindo

apenas o essencial para isto seja possıvel

A pagina inicial do WOW apresenta um resumo das ordens de trabalho abertas

ndash enviadas e recebidas ndash que se pretende permitir visualizar offline (ver Figura 46)

Como prova de conceito foi efectuada uma abordagem pragmatica das varias possi-

bilidades descritas na seccao 42

461 Modo ldquoaplicacao deciderdquo com deteccao automatica da ligacao

A primeira abordagem estudada para a disponibilizacao das funcionalidades of-

fline foi o modo ldquoaplicacao deciderdquo com deteccao automatica de ligacao apresentado

na seccao 422 Para que isto seja possıvel foi implementado um mecanismo de ver-

ificacao periodica do estado da ligacao atraves de chamadas Ajax assıncronas O

resultado destes pedidos determina o estado da aplicacao executando as tarefas de

sincronizacao de dados sempre que pertinente Este metodo embora imediato e

simples de implementar depressa se revelou inadequado para o projecto devido ao

elevado consumo de recursos do servidor que a utilizacao intensiva faz esperar a

comunidade da plataforma WOW no principal cliente excede os 7000 utilizadores

Foi estimado que para uma utilizacao de fluidez aceitavel o estado da ligacao deveria

ser testado a cada cinco segundos Assumindo uma adesao (previsao pessimista) de

1 aos servicos offline assistir-se-ia a cerca de 840 pedidos adicionais por minuto

Mas o principal problema desta aproximacao prende-se com o facto de a ver-

ificacao ser feita em intervalos de tempo discretos levando a possibilidade de a

aplicacao poder ter em dado momento uma representacao errada do seu estado

real da ligacao Este problema e ilustrado na Figura 48 onde se ve claramente a

discrepancia entre o estado real da ligacao e a representacao interna que esta tem

Note-se que nesta janela de tempo qualquer accao do utilizador que exija uma

resposta sıncrona do utilizador leva-lo-a para um ldquobeco sem saıdardquo onde nao tera

43

Desenvolvimento

Figura 46 A pagina inicial do WOW apresenta um resumo das ultimas ordens de trabalhoenviadas e recebidas Na imagem pode-se observar a transicao do estado online para offline

acesso a versao offline porque a aplicacao nao fez a transicao automatica nem acesso

a versao online porque na verdade nao possui uma ligacao O que acontecera nesta

situacao sera uma tentativa de acesso ao servidor por parte da aplicacao numa

altura em que este se encontra indisponıvel e o resultado sera uma mensagem de

ldquopedido excedeu o tempordquo apresentado pelo browser Este e um estado sem retorno

porque apos o browser apresentar esta mensagem todos os recursos JavaScript ficam

indisponıveis tornando impossıvel o regresso ao estado anterior ou o tratamento do

erro de qualquer outra forma No entanto as chamadas Ajax podem ser tratadas de

forma especial para a eventualidade de falha e portanto nao constituem problema

44

Desenvolvimento

Figura 47 Ilustracao do funcionamento do Gears numa web application que utiliza ummotor Ajax Os pedidos HTTP ou HTTPS podem ser interceptados e tratados localmenteou podem ser feitos a uma maquina remota consoante se verificarem ou nao as condicoesexpressas no ponto 311 E representado um acesso a uma base de dados local (fornecidapelo Gears) mas a sua utilizacao e opcional

462 Implementacao do modo ldquoutilizador deciderdquo

Este modo de execucao foi ja descrito na seccao 421 e a sua principal carac-

terıstica e ser o utilizador a decidir se a aplicacao deve utilizar um servidor remoto

ou a maquina local como fornecedor de dados

Relativamente ao WOW o WOW Offline na vertente ldquoutilizador deciderdquo vem

alterar os seus casos de uso dando ao utilizador a possibilidade de alterar o estado

de execucao da aplicacao (entre online e offline) Resta dizer que no modo online se

mantem todas as funcionalidades anteriores e que no modo offline torna-se possıvel

visualizar os conteudos da pagina principal do WOW (Figura 46) e os detalhes das

ordens de trabalho (Figura 49) tal como expressa a Figura 410

Esta aproximacao foi utilizada na prova de conceito do WOW adicionando um

controlo a interface desta aplicacao que permite ao utilizador alternar entre os esta-

dos online e offline Na transicao de online para offline sao descarregados os recursos

necessarios para a execucao desta aplicacao sem recorrer a Internet Para o fazer

45

Desenvolvimento

Figura 48 Neste exemplo do modo ldquoaplicacao deciderdquo o teste da ligacao e feito e feito acada cinco segundos O resultado deste teste nao reflecte sempre o estado real da aplicacaopodendo levar a aplicacao a ter comportamentos indesejaveis Na figura assinala-se umperıodo de tempo no qual a representacao interna do estado da ligacao nao corresponde arealidade

e utilizado um recurso ResourceStore e um ManagedResourceStore (introduzidos

em 311) O primeiro e utilizado para armazenar a pagina principal do WOW ndash do-

ravante designada por homejsp ndash e o segundo e utilizado para armazenar imagens

folhas de estilo CSS e scripts JavaScript

Para a implementacao deste modo de execucao foram identificadas as seguintes

tarefas

1 Guardar informacao que permita a recriacao das paginas que se pretende

disponibilizar offline (utilizando o Gears)

2 Disponibilizar um controlo que permita alterar o estado de execucao atraves

da interaccao com a pagina principal

3 Durante a sincronizacao de dados apresentar o progresso da transferencia de

dados

O primeiro passo consistiu na identificacao de todos os conteudos que sao necessarios

transferir para a execucao offline Foi utilizado um recurso do Gears do tipo

ManagedResourceStore que recorre a um ficheiro manifesto para identificar to-

dos os ficheiros que deve transferir Este recurso e gerido automaticamente pelo

Gears transferindo para o cliente a versao mais recente sempre que e necessario

isto e sempre que exista um ficheiro manifesto com uma identificacao de versao que

seja diferente da actualmente disponıvel no cliente Uma vez identificados todos

ficheiros necessarios para a execucao offline num (ou mais) ficheiros manifesto o

Gears encarrega-se da sua actualizacao mas o preenchimento destes ficheiros man-

ifesto e manual o que se traduz num cuidado extra na manutencao da aplicacao

A forma como esta informacao e guardada deve tambem ser cuidadosamente

estudada A opcao mais flexıvel passa por utilizar o modulo Database apresentado

na seccao 311 e guardar a informacao de uma forma relacional Para a recriacao

das paginas pode ser disponibilizada uma versao HTML da pagina que funciona

46

Desenvolvimento

Figura 49 Pagina de visualizacao do detalhe de uma ordem de trabalho

como template nao possui quaisquer dados e e utilizada apenas em modo offline E

preenchida para cada pedido retirando os dados relevantes da base de dados

O modelo de dados do WOW torna esta opcao extremamente trabalhosa uma

vez que as entidades envolvidas na geracao de cada pagina de informacao sobre

cada ordem de trabalho tem relacoes de dependencia complexas seguindo padroes

muito variaveis Por exemplo em cada ordem de trabalho existe um formulario que

permite a sua progressao de estado com diversos campos opcionais e obrigatorios

este formulario e definido pelo administrador e esta relacionado nao apenas com o

tipo de ordem de trabalho mas tambem com o estado actual em que esta se encontra

e a accao que se pretende realizar O elevado numero de combinacoes de tipos de

ordem de trabalho estados e accoes que existem num dado momento juntamente

com a sua possibilidade de alteracao obrigariam a implementacao de uma logica de

negocio complexa o que esta fora do ambito deste projecto

47

Desenvolvimento

Figura 410 Esquema UML que expressa os casos de uso do WOW Offline no modoldquoutilizador deciderdquo

463 Especificacao do modo ldquoaplicacao assume o estado offlinerdquo

A aproximacao para o modo ldquoaplicacao assume o estado offlinerdquo foi tambem

dividida em varias tarefas

1 Guardar informacao que permita a recriacao da pagina principal do lado do

cliente no estado offline (utilizando o Gears)

2 Dotar a aplicacao do cliente de um mecanismo de deteccao da ligacao

3 Identificar os ldquomomentos chaverdquo em que devera ocorrer sincronizacao de dados

4 Implementar a sincronizacao de dados

A sincronizacao de dados deve ser feita em ambas as transicoes online-offline e

offline-online quer para transferir novos dados do servidor (os pedidos podem ser

alterados por outros utilizadores) quando se transita do estado quer para comunicar

eventuais alteracoes feitas em modo offline

Relativamente ao WOW o WOW Offline na vertente ldquoaplicacao assume o es-

tado offlinerdquo vem alterar os seus casos de uso dando ao utilizador a possibilidade

de activar esta funcionalidade A partir do momento que a funcionalidade esta ac-

tivada o utilizador deve tambem ter a possibilidade de gerir algumas preferencias

relacionadas com privacidade de dados Devera ter a hipotese de desactivar o ar-

mazenamento local e de remover todos os dados ja armazenados tal como descrito

na Figura 411

48

Desenvolvimento

Figura 411 Esquema UML que expressa os casos de uso do WOW Offline no modoldquoutilizador deciderdquo

A primeira vez que o WOW Offline e acedido por um cliente e caso seja detec-

tada a presenca do Gears todos os recursos necessarios a sua execucao sao trans-

feridos Todos os acessos posteriores serao feitos a estes recursos locais (recorda-se

que o Gears pode ser utilizado para os manter actualizados recorrendo ao Managed-

ResourceStore 311)

Atraves do JavaScript e possıvel interceptar os eventos de load e unload da

pagina que sao despoletados sempre que ocorre um re-acesso da mesma (incluindo

a accao refresh comum dos browsers) sempre que esta e abandonada ou ainda ou

ainda se a janela for encerrada

Tal como sugerido na seccao 462 a camada de interface desta aplicacao (cada

pagina individual em HTML) devera ser implementada como sendo um template

para apresentacao de dados sendo totalmente preenchida atraves de funcoes em

JavaScript O objectivo deste ponto e criar um padrao de dados que permita ao

JavaScript preencher os dados em cada pagina (template) independentemente de

qual seja a fonte ndash o servidor remoto ou a maquina local tal como exemplificado

no diagrama da Figura 412 Na figura a aplicacao recorre ao servidor remoto para

obter os dados pretendidos quando se encontra na presenca de uma ligacao mas

para dados que exijam uma carga de processamento pelo servidor este acto pode ser

49

Desenvolvimento

Figura 412 Esquema UML que expressa o acto de recolha de dados em modo online eoffline recorrendo ao servidor (modo online) e ao sistema de armazenamento de dadoslocal fornecido pelo Gears (modo offline)

substituıdo pelo envio de um campo de controlo que se destina a aferir se os dados

locais se encontram actualizados No caso de estarem actualizados a comunicacao

com o servidor pode ser substituıda por uma query a base de dados local

50

Capıtulo 5

Resultados e Futuros

Desenvolvimentos

Todo o estudo feito sobre o tema OWA foi ja abordado ao longo do documento

Neste capıtulo apresentam-se os resultados obtidos na implementacao da prova de

conceito que visava compreender a melhor forma de disponibilizar uma versao of-

fline no WOW uma plataforma de gestao de ordens de trabalho ja existente de-

senvolvida pela Critical Software SA

51 Resultados Obtidos

Os resultados obtidos neste projecto sao extremamente satisfatorios uma vez

que o estudo do tema OWA e a implementacao de uma prova de conceito que o

ilustrasse foi conseguido com sucesso

A funcionalidade offline foi adicionada ao produto WOW da Critical Software

SA permitindo a visualizacao de ordens de trabalho e dos seus detalhes mesmo na

ausencia de uma conexao activa a Internet Embora para a solucao implementada

tenha sido utilizada uma abordagem do tipo ldquoutilizador deciderdquo pretende-se que esta

seja convertida para ldquoaplicacao deciderdquo ou mesmo para uma aproximacao hıbrida

semelhante a utilizada pelas aplicacoes estudadas nas seccoes 351 e 352

Para a sua implementacao descrita no capıtulo 4 foram tomadas decisoes de or-

dem pratica que permitissem tornar o trabalho exequıvel nos prazos dados Tentou-

se sempre que estas decisoes afectassem o mınimo em termos de desempenho e de

experiencia para o utilizador Considera-se que a implementacao do modo offline

com uma transicao entre modos do tipo ldquoutilizador deciderdquo (ver seccao 42) reflecte

o compromisso entre o desempenho pretendido e os recursos disponıveis e para alem

51

Resultados e Futuros Desenvolvimentos

de ser um exemplo eficaz das possibilidades que as OWA podem trazer a aplicacao

WOW desenvolvida pela Critical Software e tambem um estudo que pode ser uti-

lizado para analisar a implementacao desta tecnologia noutros produtos da mesma

empresa

Note-se que o principal objectivo do trabalho era ganhar familiaridade com este

tema entender as suas vantagens e desvantagens e compreender as suas limitacoes

Tudo indica que existam varias possibilidades de implementacao deste paradigma

noutros produtos da Critical Software que pela sua natureza podem tambem tirar

partido da execucao offline

52 Trabalho Futuro

O desenvolvimento do conceito e formas de implementacao de OWA continua

em forte desenvolvimento no entanto a sua adopcao ainda nao e generalizada A

dificuldade da sua implementacao em web applications ja existentes e o principal

obstaculo a sua maior divulgacao

Ha tambem um factor que deve ser tido em consideracao a manutencao de

codigo A implementacao de uma versao offline de uma web application requer

a implementacao das mesmas regras de negocio (ou de uma versao simplificada)

utilizadas no servidor Para que isto seja possıvel e necessario ter em conta a

capacidade de processamento do cliente e o factor de duplicacao de codigo que

tornara a aplicacao mais difıcil de manter uma vez que uma alteracao a logica de

negocio do servidor implica tambem uma alteracao a sua versao offline

A prova de conceito implementada permite ja a visualizacao offline dos pedidos

abertos (enviados e recebidos) que constam na pagina principal (este numero e

fixo e pode ser alterado pelo administrador) Uma funcionalidade desejavel seria a

possibilidade de interaccao com a aplicacao em modo offline e sincronizacao com o

servidor quando existisse uma ligacao disponıvel

Foi estudada a utilizacao do modo de execucao ldquoaplicacao assume o estado of-

flinerdquo descrito em 423 e esta seria a forma desejavel para o WOW Offline no

entanto para que esta opcao seja viavel sera necessaria a implementacao de uma

forma eficiente de sincronizacao e armazenamento de dados de uma forma relacional

Para atingir este objectivo podera ser seguida uma polıtica de automacao do pro-

cesso no qual a versao online da aplicacao gera scripts de criacao para as tabelas

necessarias na base de dados da versao offline (nao existe nenhuma ferramenta para

o fazer portanto seria necessaria a sua implementacao) e no qual as paginas HTML

disponibilizadas pelo servidor aos clientes web (browser) servem como templates de

apresentacao de informacao e sao preenchidas de forma semelhante pelo servidor ndash

quando a aplicacao estiver online ndash ou pelo cliente atraves de funcoes em JavaScript

52

Resultados e Futuros Desenvolvimentos

ndash quando a aplicacao estiver offline No entanto no WOW devido a quantidade de

informacao tratada e devido as complexas relacoes entre as diferentes entidades e

de esperar que a complexidade da implementacao de um mecanismo deste tipo torne

esta aproximacao demasiado custosa

O HTML 5 embora um forte candidato ainda nao esta suficientemente desen-

volvido A sua especificacao ainda tem o caracter de Draft (rascunho) e esta sujeita

a modificacoes e a aceitacao e implementacao por parte dos browsers e portanto

de momento foi desconsiderado No entanto no futuro se esta especificacao atingir

um estado de maturidade que permita a sua adopcao devera ser considerada como

um possıvel caminho a seguir

53

Resultados e Futuros Desenvolvimentos

54

Capıtulo 6

Conclusoes

Neste capıtulo sao apresentadas as conclusoes do projecto e consideracoes finais

relativamente a tecnologia estudada

61 Conclusoes

O rapido desenvolvimento tecnologico faz prever que a disponibilidade de ligacao

a Internet seja cada vez mais facil e mais rapido mas vao continuar a existir lugares

onde o acesso e limitado e onde as OWA podem desempenhar um papel de relevo

Por outro lado esta tecnologia pode tambem ser utilizada para melhorar o desem-

penho de paginas web com uma necessidade elevada de imagens ou outros recursos

dispendiosos em termos de espaco e foram ate estudados dois exemplos da utilizacao

desta vertente desta tecnologia em 353

Acredita-se que as OWAs vem responder a uma necessidade real por parte das

web applications actuais e que a evolucao que representam se compara a que se

assistiu dos thin-clients para os fat-clients em termos de autonomia do servidor

A capacidade de oferecer conteudos dinamicos no browser independentemente da

existencia de uma ligacao reune as vantagens tıpicas das web applications como

ausencia de instalacao e actualizacoes instantaneas com as vantagens das aplicacoes

de desktop em capacidade de processamento e armazenamento de dados na maquina

local

As tecnologias disponıveis ate a data estudadas no ambito deste projecto que

permitem o desenvolvimento de OWAs e que apresentam maior maturidade sao o

Gears e o Adobe AIR Ambas se apresentam sobre a forma de plugins que necessitam

de uma instalacao extra para poderem ser utilizadas Apesar de esta instalacao ser

55

Conclusoes

apenas necessaria uma vez podera constituir um factor de desencorajamento a sua

adopcao

O HTML 5 uma especificacao abordada neste documento na seccao 34 podera

ser uma alternativa que oferece funcionalidades offline a uma web application sem a

necessidade de qualquer instalacao no entanto esta especificacao ainda nao foi aceite

pelos principais browsers ndash o documento que define o HTML 5 ainda tem o estatuto

de Draft ndash e ainda nao e possıvel antecipar quando e que isto podera acontecer

Um dos problemas que surge frequentemente na implementacao de uma versao

offline para uma web application e a necessidade de sincronizacao de dados Quando

a informacao pode ser alterada por varios utilizadores simultaneamente e necessario

prever os conflitos que daı podem surgir e dotar a aplicacao de uma forma de os

resolver ou alertar o utilizador para a necessidade de alteracao dos dados

Em conclusao todos os objectivos propostos para este projecto foram atingidos

A prova de conceito implementada reflecte de forma clara as possibilidades oferecidas

pela tecnologia OWA e sera utilizado no futuro para compreender a melhor forma

de o implementar de forma definitiva no WOW

56

Referencias

[Ada08] Lucas Adamski Introducing Adobe AIR security model Fevereiro de2008 Disponıvel em httpwwwadobecomdevnetairarticles

introduction_to_air_securityhtml acedido em Marco de 2008

[Ado08] Adobe Adobe AIR 10 Security White Paper 2008 Disponıvel emhttpdownloadmacromediacompubairdocumentation1air_

securitypdf acedido em Marco de 2008

[Alm08] Dion Almaer Gears as a bleeding-edge html 5 implementa-tion March 2008 Disponıvel em httpalmaercomblog

gears-as-a-bleeding-edge-html-5-implementation acedido emMarco de 2008

[BL96] Tim Berners-Lee The world wide web Past present and future Agostode 1996 Disponıvel em httpwwww3orgPeopleBerners-Lee

1996ppfhtml acedido em Abril de 2008

[CDGH08] Mike Chambers Daniel Dura Dragos Georgita and Kevin Hoyt AdobeAIR for JavaScript Developers OrsquoReilly Media 2008 Disponıvel emhttponairadobecomfilesAIRforJSDevPocketGuidepdf ace-dido em Abril de 2008

[Con99] Jim Conallen Modeling Web Application Architectures with UML Junho1999 Disponıvel em httpwwwumlorgcnUMLApplicationpdf

webappspdf acedido em Maio de 2008

[Ent07] Entrust What is a public key information 2007 Disponıvel em http

wwwentrustcompkihtm acedido em Junho de 2008

[Gar05] Jesse James Garret Ajax A new approach to web applicationsFebruary 2005 Disponıvel em httpwwwadaptivepathcomideas

essaysarchives000385php acedido em Marco de 2008

[Greon] Philip Greenspun Philip and Alexrsquos Guide to Web Publishing 2003(last revision) Disponıvel em httpphilipgreenspuncompandaacedido em Junho de 2008

[Gro02a] App Design Group Thick vs thin client comparison 2002 Disponıvelem httpwwwdonjacobsvwcomimagesweekendspecials

Thick-vs-Thinpdf acedido em Junho de 2008

57

REFERENCIAS

[Gro02b] Technical Research Group Thin Client Tecnhology - WhitePaper 2002 Disponıvel em httpwwwpicktrgcompubs

thinclientwhitepaperpdf acedido em Junho de 2008

[Gro08] Miniwatts Marketing Group World internet usage March 2008Disponıvel em httpwwwinternetworldstatscomstatshtm ace-dido em Abril de 2008

[Hic08] Ian Hickson HTML 5 Draft Recommendation 2008 Disponıvelem httpwwwwhatwgorgspecsweb-appscurrent-work ace-dido em Marco de 2008

[Kha] Olga Kharif Top 10 municipal wifi plans Disponıvel em http

imagesbusinessweekcomss0608muni_wifiindex_01htm ace-dido em Marco de 2008

[Lab07] Mozilla Labs Prism Outubro 2007 Disponıvel em httplabs

mozillacom200710prism acedido em Marco de 2008

[Loo06] Chris Loosley Rich Internet ApplicationsDesign MeasurementandManagement Challenges 2006 Disponıvel em httpwwwkeynote

comdocswhitepapersRichInternet_5pdf acedido em Maio de2008

[Mic08] Microsoft Introduction to Occasionally Connected Applications us-ing Sync Services for ADONET 2008 Disponıvel em httpmsdn

microsoftcomen-ussyncbb887608aspx acedido em Junho de2008

[Nao08] Erica Naone Offline web applications Abril 2008 Disponıvelem httpwwwtechnologyreviewcomread_articleaspxch=

specialsectionsampsc=emerging08ampid=20245 acedido emAbril de 2008

[NJN00] Jason Nieh Yang S Jae and Naomi Novik A comparison of thin-clientcomputing architectures 2000 Disponıvel em httpwwwnclcs

columbiaedupublicationscucs-022-00pdf acedido em Maio de2008

[OrsquoR06] Tim OrsquoReilly Web 20 compact definition Trying again Dezembro2006 Disponıvel em httpradaroreillycomarchives200612

web-20-compact-definition-tryihtml acedido em Marco de 2008

[OrsquoR09] Tim OrsquoReilly What is Web 20 Design patterns and business modelsfor the Next Generation of Software 20053009 Disponıvel emhttpwwworeillynetcompubaoreillytimnews200509

30what-is-web-20html acedido em Marco de 2008

[Rus06] Alex Russel Comet Low latency data for the browser March Marco2006 Disponıvel em httpalexdojotoolkitorgp=545 acedidoem Marco de 2008

58

REFERENCIAS

[Sad97] Darleen Sadoski Clientserver software architecturesndashan overviewAgosto 1997 Disponıvel em httpwwwseicmuedustr

descriptionsclientserver_bodyhtml acedido em Junho de2008

[Sch96] George Schussel Clientserver past present and future 1996

[Smi07] Kevin C Smith Css filters - will the browser apply the rule July 2007Disponıvel em httpcentriclecomrefcssfilters acedido emMarco de 2008

[vK08] Anne van Kesteren The XMLHttpRequest Object W3C Work-ing Draft 15 Abril 2008 Disponıvel em httpwwww3orgTR

XMLHttpRequest acedido em Abril de 2008

[Wil06] Greg Wilkins Why ajax comet July Julho 2006 Disponıvel emhttpwwwwebtidecomdownloadswhitePaperWhyAjaxhtml ace-dido em Abril de 2008

59

REFERENCIAS

60

Anexo A

Screenshots

Algumas imagens de aplicacoes que utilizam funcionalidades offline ilustrativasda tecnologia abordada neste documento

Figura A1 Dialogo apresentado ao utilizador na primeira activacao das funcionalidadesoffline no Google Docs amp Spreadsheets

61

Screenshots

Figura A2 Na activacao das funcionalidades offline e tambem oferecida a possibilidadeda criacao de alguns atalhos por exemplo no ambiente de trabalho

Figura A3 O Google Docs mantem a todo o momento a possibilidade de alteracao destasdefinicoes ou da anulacao dos servicos offline para um dado computador

62

Screenshots

Figura A4 Apos a instalacao do Gears qualquer visita ao Remember The Milk despoletauma sincronizacao que ocorre automaticamente e sem necessidade de intervencao por partedo utilizador

Figura A5 Apos completar a sincronizacao de dados mesmo que a ligacao a Internetseja perdida o Remember the Milk continua disponıvel no browser (com excepcao dasfuncionalidades que pela sua natureza exigem uma ligacao como por exemplo partilhade tarefas e envio de convites)

63

Page 8: O ine Web Applications

Agradecimentos

A realizacao e os objectivos alcancados neste projecto nao teriam sido possıveissem a colaboracao de inumeras pessoas Agradeco profundamente a todos os quecontribuıram directa ou indirectamente para o seu sucesso

A minha orientadora Professora Teresa Galvao Dias e ao Project ManagerEngenheiro Marcus Neves que me conduziram e acompanharam no desenvolvimentodeste projecto

A toda a equipa do WOW em especial o Pedro Maurıcio Costa e o Fabio Matosque contribuıram para a minha a minha integracao na Critical Software e que sempresouberam responder a todas as minhas questoes

A todos os que constituem a CSW Porto pelo fantastico ambiente de amizadeque me proporcionaram

Aos colegas de curso e a todos os que me auxiliaram na revisao deste documento

Os meus sinceros agradecimentos

Joao Goncalves da Costa

v

vi

Conteudo

1 Introducao 111 Enquadramento 112 Motivacao 213 Ambito 314 Objectivos 315 Estrutura do documento 3

2 Enquadramento do Projecto 521 Evolucao das arquitecturas de software 5

211 Thin-clients 5212 Fat-clients 6213 Arquitecturas cliente-servidor 7

22 Evolucao na Internet 8221 Paginas web estaticas 9222 Paginas web interactivas e paginas web dinamicas 9223 Web 20 e Ajax 11

23 Offline Web Applications 1324 Comparacao 13

3 Estado da arte 1731 Gears 17

311 Arquitectura 17312 Goggle Gears em dispositivos moveis 20

32 Adobe AIR 20321 Seguranca 22322 Assinatura do codigo 22

33 Mozilla Prism 23331 XML User Interface Language 23332 Prism 25

34 HTML 5 2535 Web applications que usam funcionalidades offline 26

351 Google Reader e Google Docs 26352 Remember the Milk 27353 MySpace e WordPresscom 27

36 Escolha da tecnologia 28

vii

CONTEUDO

4 Desenvolvimento 3341 Como ficar offline 33

411 Funcionalidades disponıveis em modo offline 3442 Modos de execucao 35

421 Modo ldquoutilizador deciderdquo 36422 Modo aplicacao decide 36423 Modo ldquoaplicacao assume o estado offlinerdquo 37

43 Sincronizacao de dados 38431 Quando sincronizar 39

44 WOW 4045 Visao geral sobre a arquitectura do WOW 4146 WOW Offline 42

461 Modo ldquoaplicacao deciderdquo com deteccao automatica da ligacao 43462 Implementacao do modo ldquoutilizador deciderdquo 45463 Especificacao do modo ldquoaplicacao assume o estado offlinerdquo 48

5 Resultados e Futuros Desenvolvimentos 5151 Resultados Obtidos 5152 Trabalho Futuro 52

6 Conclusoes 5561 Conclusoes 55

Referencias 59

A Screenshots 61

viii

Lista de Figuras

21 Arquitectura de um sistema thin-client em duas camadas (a esquerda)e em tres camadas (a direita) Note-se a inclusao do servidor (main-frame) na definicao das camadas desta arquitectura devido a fortedependencia cliente-servidor 9

22 Arquitectura de um fat-client em duas camadas (a esquerda) e emtres camadas (a direita) 10

23 Comparacao do modelo de web aplications sıncrono paginas estaticase interactivas abordados nas seccoes 221 e 222 com o modelo deweb applications Ajax (assıncrono) abordado na seccao 223 Figuraadaptada de http www adaptivepath com 15

31 Esquema UML do processo efectuado pelos recursos do Gears do tipoManagedResourceStore para a actualizacao dos conteudos definidosno ficheiro manifesto 29

41 Exemplo de uma arquitectura de uma web application sem uma ca-mada de abstraccao de dados Figura adaptada de http gears

google com 33

42 Exemplo de uma arquitectura de uma web application com uma ca-mada de abstraccao de dados Figura adaptada de http gears

google com 34

43 Exemplo de uma arquitectura de uma web application com uma ca-mada de abstraccao de dados e um data switch Figura adaptada dehttp gears google com 35

44 Esquema grafico ilustrando uma OWA executando no browser uti-lizando um modo de execucao do tipo ldquoaplicacao deciderdquo com de-teccao automatica do estado da ligacao via pedidos Ajax assıncronosa cada cinco segundos 37

45 Detalhe de um conjunto possıvel de estados e respectivas transicoespara uma dada ordem de trabalho no WOW desde a sua submissaono sistema ate a sua conclusao em fecho ou cancelamento Esta figurarepresenta apenas um exemplo ja que o mapa de estados para umaordem de trabalho e dinamico e pode ser alterado por um admin-istrador Figura retirada de uma brochura promocional do WOWCritical Software SA 41

ix

LISTA DE FIGURAS

46 A pagina inicial do WOW apresenta um resumo das ultimas ordensde trabalho enviadas e recebidas Na imagem pode-se observar atransicao do estado online para offline 44

47 Ilustracao do funcionamento do Gears numa web application que uti-liza um motor Ajax Os pedidos HTTP ou HTTPS podem ser inter-ceptados e tratados localmente ou podem ser feitos a uma maquinaremota consoante se verificarem ou nao as condicoes expressas noponto 311 E representado um acesso a uma base de dados local(fornecida pelo Gears) mas a sua utilizacao e opcional 45

48 Neste exemplo do modo ldquoaplicacao deciderdquo o teste da ligacao e feitoe feito a cada cinco segundos O resultado deste teste nao reflectesempre o estado real da aplicacao podendo levar a aplicacao a tercomportamentos indesejaveis Na figura assinala-se um perıodo detempo no qual a representacao interna do estado da ligacao nao cor-responde a realidade 46

49 Pagina de visualizacao do detalhe de uma ordem de trabalho 47410 Esquema UML que expressa os casos de uso do WOW Offline no

modo ldquoutilizador deciderdquo 48411 Esquema UML que expressa os casos de uso do WOW Offline no

modo ldquoutilizador deciderdquo 49412 Esquema UML que expressa o acto de recolha de dados em modo

online e offline recorrendo ao servidor (modo online) e ao sistemade armazenamento de dados local fornecido pelo Gears (modo offline) 50

A1 Dialogo apresentado ao utilizador na primeira activacao das funcional-idades offline no Google Docs amp Spreadsheets 61

A2 Na activacao das funcionalidades offline e tambem oferecida a possi-bilidade da criacao de alguns atalhos por exemplo no ambiente detrabalho 62

A3 O Google Docs mantem a todo o momento a possibilidade de alteracaodestas definicoes ou da anulacao dos servicos offline para um dadocomputador 62

A4 Apos a instalacao do Gears qualquer visita ao Remember The Milkdespoleta uma sincronizacao que ocorre automaticamente e sem ne-cessidade de intervencao por parte do utilizador 63

A5 Apos completar a sincronizacao de dados mesmo que a ligacao aInternet seja perdida o Remember the Milk continua disponıvel nobrowser (com excepcao das funcionalidades que pela sua naturezaexigem uma ligacao como por exemplo partilha de tarefas e enviode convites) 63

x

Lista de Tabelas

21 Comparacao entre thin-clients e fat-clients 7

31 Comparacao das funcionalidades oferecidas pelo Adobe AIR para asplataformas web e desktop 30

32 Resumo da utilizacao de tecnologias OWA em algumas web applica-tions consideradas na analise do estado da arte 31

xi

LISTA DE TABELAS

xii

Glossario

fat-client Cliente que nao depende totalmente de umservidor central para as suas actividadesde processamento e possui frequentementedispositivos de armazenamento de dados

6ndash8

thin-client Cliente que depende de um servidor centralpara as suas actividades de processamento

5ndash8

web application Sistema web (servidor rede HTTPbrowser) onde accoes do utilizador(navegacao e introducao de informacao)afectam o estado logico da aplicacao

i iii1ndash311ndash1517ndash1921ndash232728 3336ndash3842 5556

API Application Programming Interface 10 1718 2326 28

ASP Linguagem interpretada pelo servidorque permite a criacao de paginas webdinamicas Desenvolvida pela Microsoft

11

BSD Berkeley Software Distribution 28

CSS Cascading Style Sheets 12 2021 2324 46

DHTML Dynamic HyperText Transfer Protocol 24DOM Document Object Model 10 12

20 2324

DTD Document Type Definition 24

xiii

Glossario

ECMAScript Padrao de linguagem de programacaodefinido pela Ecma International que orig-inou o JavaScript e o JScript

24

Flash Conteudo interactivo de um ficheiro emformato SWF E desenvolvido pela Adobee visualizado atraves do Adobe FlashPlayer

21

Flex Framework baseada em XML e Action-Script desenvolvida pela Adobe para a pro-gramacao de Rich Internet Applications(RIA)

21

GPL GNU General Public License 23

HTML HyperText Markup Language 1 10ndash12 2124ndash2649

HTTP HyperText Transfer Protocol 2 26

JMS E uma API em Java que permite a troca demensagens entre componentes de software

42

JSON JavaScript Object Notation permite atroca de dados codificados num formatode texto de simples leitura

12 1828 34

LGPL GNU Lesser General Public License 23

Mozilla Prism Browser simplificado e ldquointerpretadorrdquo deeXtensible User Interface Language (XUL)(tambem designado por XULRunner) queacolhe web applications sem a interfacegrafica habitual de um browser

25

MPL Mozilla Public License 23

OCA Occasionally Connected Application 39OWA Offline Web Application i iii

2ndash515 1725 2628 3133 3651 5255 56

PDF Portable Document Format 21

xiv

Glossario

PHP Linguagem interpretada pelo servidorque permite a criacao de paginas webdinamicas mas que pode tambem ser in-vocada a partir da linha de comandos

11

pagina web estatica Pagina web que devolve sempre a mesmaresposta a todos os pedidos para todos osutilizadores e em qualquer contexto

5 9

RIA Rich Internet Applications web appli-cations que apresentam funcionalidadessemelhantes as desktop applications masque mantem a informacao no lado do servi-dor

5 1520 28

RSS Really Simple Syndication 27

SLA Service Level Agreement 40SQLite Segundo a definicao oficial SQLite is a

software library that implements a self-contained serverless zero-configurationtransactional SQL database engine

17

SSB Site Specific Browser 25SSL Secure Sockets Layer 22SWF ShockWave Flash 21

URL Uniform Resource Locator 18

VPN Virtual Private Network 38

WOW Work Orders Web Plataforma de gestaode ordens de trabalho e do seu fluxo de-senvolvida pela Critical Software SA

i iii28 3340ndash434551ndash5356

WWW World Wide Web 11 1214

XBL eXtensible Binding Language 24XHTML eXtensible HyperText Markup Language 12XML eXtensible Markup Language 11 12

23 2428

XSLT eXtensible Stylesheet Language Transfor-mation

12

XUL eXtensible User Interface Language xiv23ndash25

xv

Glossario

xvi

Capıtulo 1

Introducao

Neste capıtulo enquadra-se o tema do projecto introduzindo alguns dos conceitos

nos quais se baseia Apresentam-se as motivacoes ambito objectivos e a estrutura

deste documento

11 Enquadramento

A Internet foi originalmente concebida para ser um espaco de partilha de in-

formacao onde pessoas (atraves de maquinas) pudessem comunicar Na sua origem

as paginas eram estaticas constituıdas por texto formatado em HyperText Markup

Language (HTML) e ligadas entre si [BL96] Hoje encontramos conteudos cada vez

mais complexos e dinamicos incluindo som vıdeo ou streams multimedia [Loo06] e

em 2005 foi introduzido por [OrsquoR09] o termo Web 20

De acordo com [Greon] um website pode pertencer a uma ou varias das seguintes

categorias

bull Documento ndash um website essencialmente estatico onde alteracoes a uma

parte do conteudo nao tem implicacoes no seu comportamento

bull Base de dados ndash um directorio de informacao organizada em categorias

bull Aplicacao ndash um website dinamico que utiliza uma linguagem executada ou

interpretada do lado do servidor e que processa as accoes ou informacao in-

troduzida pelo utilizador para fornecer um servico ou nova informacao

A ultima destas categorias constitui aquilo que e normalmente designado por

web application O conceito utilizado ao longo deste documento e o mesmo que

o introduzido por Jim Coallen em [Con99] que define web application como um

1

Introducao

sistema web (servidor rede HyperText Transfer Protocol (HTTP) browser) onde

accoes do utilizador (navegacao e introducao de informacao) afectam o estado logico

da aplicacao A sua definicao tenta estabelecer que uma web application e um

sistema de software com estado de negocio1 e que a sua interface de interaccao com

o utilizador e distribuıdo atraves de um sistema web

12 Motivacao

A quantidade de informacao que e produzida e armazenada com recurso a es-

tas web applications disponıveis online tais como e-mail blogues ou mesmo docu-

mentacao tornam por vezes a disponibilidade de ligacao uma condicao necessaria

a produtividade e como consequencia desta barreira muitos potenciais utilizadores

opoem-se a adopcao de produtos web em detrimento das tradicionais desktop appli-

cations

Assegurar o acesso a uma ligacao de Internet e hoje muito mais facil A Internet

movel e ja uma realidade e encontra-se amplamente divulgada mas continuam a

existir diversas situacoes nas quais os utilizadores estao privados de uma ligacao

a Internet tais como uma viagem de metro ou de aviao ou quando se encontram

deslocados do seu paıs de origem e nao possuem nenhum plano de subscricao

Uma OWA consiste numa web application que para alem de manter todas as

caracterısticas anteriores se mantem disponıvel mesmo na ausencia de uma ligacao

a Internet e surge como uma tentativa de estreitar as barreiras existentes entre a

web e o desktop Isto significa que devera existir um mecanismo capaz de assegurar

a manutencao do estado logico da aplicacao quando a ligacao com o servidor e

quebrada permitindo ao utilizador continuar a utilizar a aplicacao e que sera capaz

de informar o servidor do estado em que a aplicacao se encontra quando a ligacao for

reposta A principal vantagem que advem desta possibilidade e evidente eliminar

a necessidade da existencia de uma ligacao a Internet para que a aplicacao possa ser

utilizada

Por outro lado a vontade de integracao de funcionalidades tıpicas das desktop

applications nas web applications foi um dos principais factores que impulsionou o

desenvolvimento deste conceito uma vez que obrigou a uma reflexao ldquopara alem

do browserrdquo e a uma adaptacao das arquitecturas existentes que permitisse ou o

acesso a funcionalidades disponibilizadas pelo sistema operativo ou pelo menos a

funcionalidades semelhantes Pretende-se com esta aproximacao tornar possıveis

interaccoes entre o desktop e o browser tais como arrastar um ficheiro para um

formulario web de upload de conteudos melhor suporte para o historico do clipboard

ou ainda o acesso ao sistema de ficheiros local Atingir estes objectivos reflecte-se

1NT business state

2

Introducao

num novo paradigma que reune as vantagens das web applications tais como os

updates instantaneos ou o facto de nao ser necessaria nenhuma instalacao e das

desktop applications como por exemplo persistencia no armazenamento de dados

acesso a funcionalidades do sistema operativo ou integracao e interaccao com outras

aplicacoes sejam elas web applications ou desktop applications

13 Ambito

Este projecto foi realizado na Critical Software SA no ambito do Mestrado

Integrado em Engenharia Informatica e Computacao (MIEIC) da Faculdade de En-

genharia da Universidade do Porto (FEUP) entre os meses de Fevereiro e Julho de

2008

14 Objectivos

Sao objectivos deste projecto

1 Estudar e documentar o tema das OWAs acompanhando os ultimos desenvolvi-

mentos nesta materia

2 Analisar o estado da arte fazendo uma analise crıtica e objectiva sobre as

diversas metodologias existentes

3 Implementar uma prova de conceito que permita a execucao offline de uma

web application documentando todo o processo

4 Estudar a possibilidade de permitir interaccao com a aplicacao (insercoes e

alteracoes aos dados) em modo offline

Em resumo o objectivo deste projecto foi estudar documentar e implementar

uma prova de conceito relacionada com o tema Offline Web Applications (OWA)

Este tema embora nao seja totalmente novo ganhou destaque ao longo do ano de

2007 com o surgimento de diversas ferramentas que se destinam a aproximar web

applications das desktop applications

15 Estrutura do documento

Este documento esta organizado em diferentes seccoes apresentando o projecto

numa sequencia logica organizada da seguinte forma

No capıtulo 1 faz-se uma breve apresentacao do conceito OWAs e do contexto em

que surge Apresenta-se tambem a estrutura do documento e definem-se os

termos e acronimos utilizados

3

Introducao

No capıtulo 2 faz-se uma descricao da evolucao das tecnologias que antecedem as

OWAs e das vantagens e desvantagens de cada uma como forma de enquadra-

mento

No capıtulo 3 analisa-se o estado da arte nesta materia Introduzem-se diversas

tecnologias directamente relacionadas com o tema deste projecto exemplos de

aplicacoes que as usam e as razoes que fundamentam as escolhas de tecnologias

efectuadas

O capıtulo 4 contem o desenvolvimento do projecto Analisa-se a plataforma

WOW de gestao integrada de ordens de trabalho a tecnologia escolhida e

a forma como foi utilizada para implementar a capacidade de execucao offline

O capıtulo 5 descreve os resultado obtidos comparando-os com as expectativas

iniciais do projecto e apresenta desenvolvimentos futuros e possibilidades de

continuacaoaplicacao do conhecimento adquirido

No capıtulo 6 apresentam-se as conclusoes

4

Capıtulo 2

Enquadramento do Projecto

Neste capıtulo apresenta-se um breve resumo da evolucao das arquitecturas de

software cliente-servidor e a forma como estas se comparam a evolucao da Inter-

net procurando estabelecer uma analogia entre o percurso de ambas as tecnolo-

gias Compara-se o comportamento e arquitectura dos thin-clients as paginas web

estaticas a evolucao dos fat-clients as paginas interactivas Web 20 e Ajax e

defende-se que as OWA constituem um proximo passo logico e evolutivo aproxi-

mando a web do desktop Referem-se ainda os principais factores que justificam a

importancia das OWAs e a estreita relacao que tem com as Rich Internet Application

(RIA)s

21 Evolucao das arquitecturas de software

Os termos thin-client e fat-client sao utilizados quer para descrever arquitecturas

logicas (de software) quer para descrever arquitecturas fısicas (de hardware) Neste

capıtulo excepto quando seja dada indicacao em contrario estes termos referem-se

sempre a uma arquitectura logica

Adicionalmente quando se trata de arquitecturas cliente-servidor pode-se estu-

dar a arquitectura desenvolvida do sistema como um todo da arquitectura do servi-

dor ou da arquitectura do cliente Para evitar equıvocos em especial na seccao 213

especifica-se em cada caso qual o sistema estudado

211 Thin-clients

Um thin-client e um computador cliente ou software cliente que no contexto

de uma arquitectura cliente-servidor depende de um servidor central para as suas

5

Enquadramento do Projecto

actividades de processamento e proporciona um canal de entrada e saıda de in-

formacao entre o utilizador e o servidor remoto Este termo quando aplicado a

hardware refere-se habitualmente a um computador que se destina a ser utilizado

como cliente de rede sem armazenamento local e com capacidade de processamento

reduzida [Gro02b] mas o conceito que aqui se analisa refere-se a uma arquitectura

de software que remonta ao inıcio das aplicacoes cliente-servidor

No inıcio da historia da computacao terminais ligavam-se directamente a main-

frames responsaveis por todo o processamento Nesta arquitectura era necessario

desenvolver duas aplicacoes distintas uma aplicacao central no servidor (main-

frame) responsavel pela gestao de toda a informacao e por todas as operacoes de

comunicacao e uma aplicacao de visualizacao instalada no cliente (terminal) O

papel destes terminais era apenas disponibilizar ao utilizador um meio de comu-

nicacao (entrada e saıda) e apresentacao dos resultados do servidor Nao tinham

um papel activo no calculo nem na logica de negocio e frequentemente nao tinham

tambem nenhum mecanismo de armazenamento de dados

Como vantagens esta arquitectura apresenta uma reduzida necessidade de con-

figuracao e manutencao do lado do cliente Uma vez que o centro do processamento

e manipulacao de dados ocorre no servidor existe tambem uma centralizacao da

informacao [NJN00] que introduz um ponto crıtico de falha1 Actualizacoes e novas

funcionalidades sao faceis de distribuir uma vez que requerem apenas alteracoes no

servidor [Gro02a]

212 Fat-clients

Contrastando com os thin-clients nesta arquitectura os clientes implementam

ja uma parte da logica de negocio e sao responsaveis pelo processamento de dados

Estes fat-clients vieram responder a necessidade crescente de aplicacoes com um

nıvel de interactividade e capacidade de configuracao maior que as oferecidas pela

arquitectura thin-client descrita na seccao 211 Apesar de manterem a sua de-

pendencia do servidor podem tambem ser executados sem uma conexao activa uma

vez que dispoe de armazenamento de dados local o que lhes confere a capacidade

de persistencia de dados e do estado de execucao entre cada sessao

Foi disponibilizando este controlo sobre o estado da aplicacao bem como acesso

a recursos locais (por exemplo sistema de ficheiros e perifericos) que surgiram as

primeiras verdadeiras desktop applications No entanto cada cliente tinha que ser

separadamente instalado no computador pessoal de cada utilizador que pretendesse

utilizar ou interagir com a aplicacao e uma actualizacao ao servidor implicava in-

variavelmente uma actualizacao manual tambem no cliente Uma vez que nem todos

1NT single point of failure

6

Enquadramento do Projecto

Thin-clients Fat-clientsNao toma parte no processamento dedados nem possui acesso ao sistema deficheiros

Participa activamente no processa-mento de dados recorrendo ao sis-tema de armazenamento local para ar-mazenamento de dados

Nao mantem registo do estado logicoda aplicacao entre duas sessoes de uti-lizacao

O acesso ao armazenamento localpermite-lhe manter registo do estadologico da aplicacao entre duas sessoes

O thin-client nao necessita de qualquerinstalacao estando ldquopronto a utilizarrdquo

E geralmente necessario instalar aaplicacao para poder interagir com oservidor

Qualquer update no servidor reflecte-seimediatamente por todos os clientes

Embora a aplicacao cliente possa aler-tar para existencia de novas versoes asactualizacoes tem que ser manualmenteinstalados pelo cliente

O software do cliente destina-se apenasa apresentacao de dados e comunicacaocom o servidor sendo portanto de sim-ples implementacao

Como o software do cliente toma parteactiva no processamento de dadosa sua implementacao requer cuidadosadicionais

Grande mobilidade uma vez que todaa informacao e mantida no servidor

Parte da informacao podera estar ape-nas do lado cliente pelo que existemalgumas restricoes a sua mobilidade

Tabela 21 Comparacao entre thin-clients e fat-clients

os utilizadores actualizam regularmente as suas aplicacoes o servidor tem que estar

preparado para lidar com versoes antigas2 ou descontinuar os seus servicos a uma

parte da sua comunidade de utilizadores ate que estes actualizem os seus sistemas

Como os utilizadores passam a utilizar os seus recursos locais para armazenamento

de dados as alteracoes que nao sejam sincronizadas com o servidor estao apenas

disponıveis nos seus computadores pessoais o que introduz uma restricao a mobili-

dade

Pode-se afirmar que as vantagens dos thin-clients sao as desvantagens dos fat-

clients e que as vantagens dos fat-clients sao as vantagens dos thin-clients tal como

se ilustra na Tabela 21

213 Arquitecturas cliente-servidor

Introduzidos os termos thin-client e fat-client interessa reafirmar que ambos

podem ser vistos como arquitecturas cliente-servidor Um cliente define-se como

um solicitador de servicos e um servidor como um prestador de servicos tal como

definido por [Sch96] e [Sad97]

2NT backward compatibility

7

Enquadramento do Projecto

As arquitecturas cliente-servidor sao categorizadas pela modularizacao com que

sao desenhadas sendo consideradas as seguintes camadas

1 Interface grafica (front-end) atraves da qual os utilizadores interagem com

a aplicacao Quando este modulo e implementado separadamente dos outros

dois constitui uma aplicacao thin-client por si so uma vez que nao implementa

regras de negocio (embora possa definir validacoes de formularios de insercao de

dados por exemplo) A informacao introduzida pelo utilizador e enviada para

o servidor que processa o seu pedido e retorna uma resposta Este processo

repete-se ate que o utilizador atinja o seu objectivo ou se desligue do sistema

2 A logica de negocio tambem designada por camada intermedia que imple-

menta as regras de aceitacao e validacao de todos os dados introduzidos pelo

utilizador E tambem a plataforma de comunicacao que une a camada superior

de visualizacao com a camada de acesso a dados

3 A camada de dados inclui quer o sistema de persistencia de dados onde sao

armazenados os dados relevantes como tambem os mecanismos necessarios

para a sua pesquisa seleccao e alteracao

Os thin-clients quando observados no seu conjunto de cliente e servidor podem

ser vistos quer como sistemas de duas camadas quer como sistemas de tres camadas

dependendo apenas da forma como o servidor for implementado No caso de na

implementacao do servidor nao se distinguir a camada de acesso a dados da camada

da logica de negocio sao designados por sistemas de duas camadas Caso seja feita

esta distincao sao designados por sistemas de tres camadas Ambos os casos sao

ilustrados na Figura 21

Historicamente os fat-clients eram implementados numa arquitectura em duas

camadas Possuıam apenas um modulo de visualizacao de dados designado por

camada de interface e um modulo que implementava toda a logica de negocio e

regras de acesso a base de dados No entanto com a introducao de ligacoes mais

rapidas e de computadores pessoais com maior capacidade de processamento e so-

bretudo devido a complexidade crescente das aplicacoes a logica de negocio e a

camada de acesso a dados tornaram-se independentes Este modelo e designado por

arquitectura em tres camadas e e ilustrado na Figura 22

22 Evolucao na Internet

Ao analisar a evolucao das arquitecturas das aplicacoes desenvolvidas para a

Internet podemos encontrar um paralelismo com a historia da arquitectura de soft-

ware

8

Enquadramento do Projecto

Figura 21 Arquitectura de um sistema thin-client em duas camadas (a esquerda) e emtres camadas (a direita) Note-se a inclusao do servidor (mainframe) na definicao dascamadas desta arquitectura devido a forte dependencia cliente-servidor

221 Paginas web estaticas

Uma pagina web estatica devolve sempre a mesma resposta a todos os pedidos

para todos os utilizadores e em qualquer contexto utilizando o hipertexto como

forma de ligacao entre diversas paginas estaticas

A informacao e armazenada num servidor e o papel do cliente e apenas a apre-

sentacao da informacao Esta forma de disponibilizacao de informacao pode assim

ser comparada com os thin-clients descritos na seccao 211 o utilizador acede a

um website estatico para visualizar informacao sem que o cliente tome parte no

processamento A unica diferenca e que no caso da web estatica a informacao ap-

resentada e sempre a mesma enquanto que nos thin-clients era frequente existir a

possibilidade de insercao de dados no cliente e apos o seu processamento servidor

nova informacao poderia ser apresentada O hipertexto e utilizado para ligar as

paginas entre si numa rede de conteudos relacionados e a navegacao sıncrona era

feita atraves de cliques do rato a cada clique uma nova pagina era apresentada

Este modelo sıncrono e ilustrado na Figura 23

222 Paginas web interactivas e paginas web dinamicas

O JavaScript e uma linguagem interpretada de scripting que tem os browsers

como principal ambiente de acolhimento Os browsers utilizam uma Application

9

Enquadramento do Projecto

Figura 22 Arquitectura de um fat-client em duas camadas (a esquerda) e em tres camadas(a direita)

Programming Interface (API) publica para criar ldquoobjectosrdquo responsaveis por reflectir

e disponibilizar o Document Object Model (DOM) para o motor de JavaScript

A utilizacao mais frequente desta linguagem e a escrita de funcoes que sao em-

bebidas ou incluıdas em paginas web e que interagem com o DOM Uma vez que o

JavaScript e executado localmente (na maquina do cliente e nao no servidor) e capaz

de responder rapidamente a accoes do utilizador tornando a execucao de aplicacoes

no browser mais fluıdas o JavaScript pode tambem detectar accoes do utilizador

que o HTML nao pode tal como o pressionar de uma tecla

Em Dezembro de 1995 a Netscape Communications adicionou suporte para o

JavaScript no browser Netscape Navigator3 e em Agosto de 1996 o browser Internet

Explorer4 da Microsoft passou a tambem a suportar uma versao semelhante desta

linguagem (hoje todos os principais browsers suportam esta tecnologia)

Esta inovacao permitiu tornar os websites mais interactivos mas a sua utilizacao

esteve confinada apenas a este proposito durante um longo perıodo As paginas

passaram a responder activamente a accoes do utilizador (sendo uma das utilizacoes

3Netscape Communications ndash httpbrowsernetscapecom4Microsoft Internet Explorer ndash httpwwwmicrosoftcomwindowsproductswinfamilyie

10

Enquadramento do Projecto

mais vulgares a validacao de formularios) mas continuaram essencialmente estaticas

O JavaScript ainda nao era nesta altura utilizado para processar dados

Tambem nesta altura (1995ndash96) surgiram linguagens server-side como o PHP

Hypertext Preprocessor (PHP) e Active Server Pages (ASP) e o servidor passou a ter

um processamento de dados introduzidos pelo utilizador mais activo Generalizaram-

se as paginas dinamicas capazes de responder a insercao de dados ou outros pedidos

determinados por accoes do utilizador As paginas tornaram-se aplicacoes web ap-

plications

Uma definicao tradicional de web application e um conjunto de paginas web

logicamente agrupadas e geridas por uma unica entidade que tem como pontos de

entrada formularios de insercao de dados (web forms) Uma web application nao e

mais do que uma aplicacao que e acedida atraves de um browser Tem geralmente

uma arquitectura logica em tres (interface logica de negocio e camada de dados)

camadas e estao armazenadas num servidor

Ha dois tipos de web applications

bull Orientadas a apresentacao Sao web applications que geram paginas web in-

teractivas constituıdas por varios tipos de linguagens de anotacao (por exem-

plo HTML eXtensible Markup Language (XML)) e que apresentam conteudo

dinamico como resposta a pedidos efectuados pelo utilizador

bull Orientadas aos servicos Uma web application orientada aos servicos imple-

menta o ponto de acesso para um ou mais de um web service Sao geralmente

clientes de service oriented web applications

Uma vantagem significativa de implementar uma web application de forma a

suportar as funcionalidades padrao dos browsers e que estas terao o mesmo com-

portamento independentemente da plataforma e do browser a partir do qual serao

acedidas No entanto diferentes implementacoes de browsers devido a diferentes

interpretacoes dos padroes definidos tornam por vezes esta tarefa um pouco mais

complicada existindo inclusivamente na web guioes de compatibilidade para os difer-

entes browsers como [Smi07]

223 Web 20 e Ajax

O termo web 20 descreve uma tendencia de utilizacao e de design observada

na World Wide Web (WWW) com o objectivo de melhorar a criatividade partilha

de informacao e principalmente a colaboracao entre utilizadores Estes conceitos

levaram ao desenvolvimento e evolucao de comunidades online tais como redes so-

ciais wikis e blogues

11

Enquadramento do Projecto

O termo tornou-se mais conhecido apos a primeira conferencia OrsquoReilly Media

Web 20 em 2004 e apesar de sugerir uma nova versao da WWW nao se refere a

qualquer evolucao tecnologica mas apenas a alteracoes a forma como os utilizadores

se servem da web De acordo com Tim OrsquoReilly [OrsquoR06] ldquoWeb 20 e uma revolucao

na industria do software causada pela adopcao da web como uma plataforma e pela

tentativa de entendimento das regras para o sucesso nesta nova plataformardquo

O desenvolvimento da Web 20 serve-se muitas vezes de um outro conceito Ajax

O conceito que hoje conhecemos como Ajax muitas vezes incorrectamente de-

scrito como uma tecnologia foi originalmente criado para permitir o desenvolvimento

de web applications que se assemelhassem ainda mais a aplicacoes de desktop Este

conceito foi melhor descrito por [Gar05] como um conjunto de varias tecnologias

que podem ser utilizadas para melhorar a experiencia do utilizador de uma dada

web application introduzindo a capacidade assıncrona de envio de pedidos ou da

recepcao assıncrona de respostas As tecnologias mais frequentemente envolvidas

sao

bull eXtensible HyperText Markup Language (XHTML) e Cascading Style Sheets

(CSS) padrao para a apresentacao

bull interaccao dinamica atraves do DOM

bull troca e manipulacao de dados utilizando XML e eXtensible Stylesheet Lan-

guage Transformation (XSLT) ou JavaScript Object Notation (JSON)

bull pedidos assıncronos utilizando XMLHttpRequest [vK08]

bull JavaScript utilizado para integrar todas estas tecnologias

E importante frisar que o Ajax nao e um produto nem uma tecnologia E um

termo que descreve a utilizacao de um conjunto de tecnologias para o desenvolvi-

mento de web applications com um elevado grau de interactividade Comparativa-

mente as web applications tradicionais o Ajax introduz uma camada de visualizacao

diferente em tres importantes pontos

1 Do lado do cliente existe um motor que serve de intermediario entre a interface

da aplicacao e o servidor

2 A actividade do utilizador despoleta chamadas JavaScript em vez de um pedido

de pagina directamente ao servidor

3 Informacao codificada em XML em vez de paginas HTML e trocada entre o

servidor e o cliente

12

Enquadramento do Projecto

Isto significa que as paginas que utilizam Ajax contem um motor do lado do

cliente composto por um conjunto de funcoes JavaScript responsavel pela comu-

nicacao com o servidor e por actualizar a interface com o resultado dessa mesma

comunicacao

Na Figura 23 ilustra-se a natureza assıncrona do Ajax quando comparada com

as web applications tradicionais Como se pode observar adicionando um mecan-

ismo Ajax a uma web application eliminam-se diversos tempos de espera associados

a comunicacoes com o servidor uma vez que a interface nao fica ldquobloqueadardquo a es-

pera da resposta Obtem-se assim aplicacoes com um comportamento mais fluido

eliminando tempos de espera entre cada ldquocliquerdquo e melhorando a experiencia do

utilizador

23 Offline Web Applications

A informacao grafica (bem como folhas de estilo e scripts) tais como as ima-

gens que constituem o visual de uma web application e ja tratada de forma especial

pelos cada vez mais avancados sistemas de cache (armazenamento temporario) dos

browsers Mas estes nao sao ainda capazes de guardar conteudo criado pelo uti-

lizador nem de apresentar informacao independentemente do estado da ligacao

Numa altura onde se fala de servicos de Internet wireless municipalizados [Kha]

comunicacoes 3G e ligacoes de banda larga a alta velocidade a ligacao a rede global

continua a nao estar permanentemente disponıvel para os utilizadores Na WWW

encontra-se uma importante parte da informacao e das aplicacoes utilizadas para

criar e editar conteudos Por vezes informacao vital para a produtividade pode

desaparecer subitamente do mapa de acesso de um utilizador quando este entra no

metro num aviao ou mesmo quando se desloca para uma cidade ou paıs diferente

do habitual onde nao subscreve um plano de acesso que lhe garanta a ligacao

Permitir o acesso offline a estes recursos assume assim a sua importancia porque

permitira estender o alcance da informacao a locais onde nunca esteve antes e per-

mitira tambem melhorar o desempenho das web applications colocando informacao

mais perto dos utilizadores reduzindo a transferencia de dados apenas ao essencial

24 Comparacao

Nas evolucoes descritas neste capıtulo 2 pode-se observar que existe um par-

alelismo entre a evolucao das arquitecturas tradicionais cliente-servidor e a evolucao

a que se assiste na web O comportamento e arquitectura dos thin-clients assemelha-

se ao das paginas estaticas no sentido em que o browser nao toma parte em qualquer

13

Enquadramento do Projecto

processamento e serve apenas como uma plataforma de interaccao com o servidor

tal como os clientes descritos na seccao 211

A sua proxima evolucao os fat-clients trouxeram parte da capacidade de pro-

cessamento para o lado do cliente Na web foi tambem esta a inovacao tecnologica

a que se assistiu com a evolucao das tecnologias que permitiram a criacao de ver-

dadeiras aplicacoes e com a introducao do Javascript no browser dando ao cliente

a capacidade de processamento de dados A necessidade da separacao do codigo

em camadas logicas advem da crescente complexidade das web applications Esta

pratica permite entre outras coisas melhorar o processo de desenvolvimento e a

capacidade de manutencao de uma aplicacao

Os fat-clients tem tambem a capacidade de armazenamento de dados o que

permite a persistencia de informacoes entre duas sessoes e que algumas operacoes

sejam executadas sem a necessidade de comunicacao com o servidor Este facto pode

tambem ser uma realidade nas web applications com a adopcao das tecnologias OWA

Neste momento assiste-se a uma utilizacao cada vez maior da web como uma

plataforma de desenvolvimento A capacidade de cooperacao na edicao de conteudos

e a mobilidade proporcionada por esta plataforma sao os principais factores que

alimentam esta mudanca e pela primeira vez as aplicacoes tradicionais tem com-

peticao vinda de web applications A prova do reconhecimento da web como plataforma

de desenvolvimento pode ser retirada da aposta de empresas como a Adobe e Mi-

crosoft que lancaram publicamente ferramentas web complementares a produtos

seus tradicionalmente associados ao desktop ndash Acrobatcom5 e Microsoft Office

Live6 Dotar estas web applications da capacidade de execucao offline significa

aproximar a web e o desktop reunindo ldquoo melhor de dois mundosrdquo

As vantagens da mobilidade possıvel atraves da web a cooperacao na criacao e

edicao de conteudos e a possibilidade de utilizar aplicacoes sempre actualizadas e

sem necessidade de instalacao sao algumas das principais vantagens que promovem

esta mudanca que devido as preocupacoes associadas a usabilidade e experiencia do

utilizador esta fortemente associada ao desenvolvimento de Rich Internet Applica-

tion (RIA)s

5Adobe Acrobatcom httpwwwacrobatcom6Microsoft ndash httpsmallbusinessofficelivecom

14

Enquadramento do Projecto

Figura 23 Comparacao do modelo de web aplications sıncrono paginas estaticas e in-teractivas abordados nas seccoes 221 e 222 com o modelo de web applications Ajax(assıncrono) abordado na seccao 223 Figura adaptada de http www adaptivepath

com

15

Enquadramento do Projecto

16

Capıtulo 3

Estado da arte

Apesar de o conceito das OWAs nao ser absolutamente novo as tecnologias que

o suportam sao recentes Neste capıtulo descrevem-se quatro tecnologias que foram

tidas como principais candidatas para o desenvolvimento deste projecto Descrevem-

se ainda alguns exemplos de web applications que disponibilizam actualmente fun-

cionalidades offline e o processo da escolha da tecnologia a utilizar neste projecto

31 Gears

O Gears1 e uma extensao as funcionalidades do browser introduzido pelo Google

que tem como principal objectivo tornar possıvel a visualizacao de paginas de Inter-

net mesmo sem uma conexao disponıvel Encontra-se disponıvel para as platafor-

mas Windows Macintosh e Linux e oferece uma API de Javascript que permite

a scripts aceder a um mecanismo de armazenamento local baseado numa base de

dados SQLite

311 Arquitectura

Esta ferramenta e constituıda por tres componentes principais

bull LocalServer mdash Intercepta pedidos de paginas web e serve-as localmente

bull Database mdash Uma base de dados relacional construıda sobre SQLite

bull WorkerPool mdash Permite executar operacoes de computacao de uma forma

assıncrona sem afectar a capacidade de resposta e fluidez de execucao da web

application Assemelham-se a processos

1Google Inc ndash Mais informacao em httpgearsgooglecom

17

Estado da arte

LocalServer

O modulo LocalServer e uma cache de Uniform Resource Locators (URLs)

controlada pela web application Quando nao existe uma ligacao a Internet e e

feito um pedido para um URL presente nesta cache o LocalServer intercepta-o e

responde ao pedido localmente a partir do disco rıgido do utilizador A aplicacao

pode utilizar dois tipos diferentes de armazenamento local de URLs

bull ResourceStore ndash serve para capturar URLs utilizando exclusivamente a API

de Javascript disponibilizada para o efeito Uma aplicacao podera criar e

utilizar diversos ResourceStores simultaneamente para capturar ficheiros de

dados que necessitam de ser enderecados por um URL tal como um ficheiro

PDF ou uma imagem

bull ManagedResourceStore ndash serve para capturar um conjunto de URLs que estao

relacionados e que sao declarado num ficheiro de manifesto (especificado em

JSON) e que sao automaticamente actualizados O ManagedResourceStore

permite que o conjunto de recursos necessarios para correr uma web application

seja capturado e mantido actualizado automaticamente

A principal diferenca entre estes dois tipos de armazenamento de URLs e a forma

como sao actualizados os seus conteudos Os conteudos de um ManagedResourceStore

sao actualizados sempre que a versao contida no ficheiro de manifesto for alterada

enquanto que os conteudos de um ResourceStore nunca sao actualizados automati-

camente mas apenas quando for explicitamente ordenado pela aplicacao

O LocalServer e capaz de interceptar e servir localmente pedidos de HTTP e

HTTPS sempre que se reunam as seguintes condicoes

1 O URL encontra-se armazenado num ResourceStore ou ManagedResourceStore

2 O sistema de armazenamento local encontra-se activo (enabled = true) Se

o sistema de armazenamento local tiver o atributo requiredCookie o pedido

devera conter um cookie que lhe corresponda

O LocalServer nao necessita de monitorizar o estado da ligacao para atender aos

pedidos Na verdade sempre que as condicoes previamente enunciadas se verificarem

o LocalServer interceptara os pedidos e independentemente do estado da ligacao

a Internet servi-los-a a partir do disco rıgido local Cabera a aplicacao definir qual

o modo em que pretende executar um pedido (online ou offline) definindo o valor

de verdade da propriedade enabled

18

Estado da arte

Database

O modulo Database permite guardar dados da web application assegurando a

sua persistencia Os dados sao guardados de forma relacional no disco rıgido do uti-

lizador2 de acordo com o modelo de seguranca estabelecido pelo Gears3 significando

que uma aplicacao nao pode aceder a conteudos fora do seu domınio

WorkerPool

Nos web browsers uma operacao pesada de computacao pode tornar a interface

lenta e tornar menos agradavel a experiencia do utilizador O modulo WorkerPool

permite correr operacoes em background sem bloquear a interface com o utilizador

Os scripts executados numa WorkerPool nao activam os mecanismos de seguranca

do browser que mostram a mensagem ldquoA script on this page may be busy or may

have stopped respondingrdquo

O WorkerPool comporta-se como um conjunto de processos em vez de threads

Os Workers nao partilham qualquer estado de execucao o que significa que uma

alteracao a uma variavel num Worker nao afecta em nada a execucao de outro

Worker Alem disso os Workers nao herdam automaticamente nenhum codigo dos

seus pais Cada Worker e membro de um WorkerPool e os Workers podem in-

teragir entre si enviando mensagens em formato de texto ou JSON No entanto ha

tambem algumas limitacoes os Workers nao tem acesso ao DOM e objectos como

window ou document nao se encontram acessıveis Isto e consequencia de os Workers

nao partilharem o estado de execucao Mas tem acesso a todas as funcoes built-in

do Javascript A maioria das funcionalidades do Gears pode tambem ser acedida

atraves de uma variavel global especial definida como googlegearsfactory Para

outras funcionalidades especıficas os Workers podem ldquopedirrdquo a pagina principal para

continuar a execucao atraves do envio de mensagens

Outras funcionalidades

bull HttpRequest ndash Este modulo implementa a especificacao W3C XmlHttpRe-

quest definida em [vK08] tornando-a disponıvel para os workers e para a

pagina principal

bull Timer ndash Este modulo implementa a especificacao de timers tal como descrito

por [Hic08] e torna-os disponıveis para os workers e para a pagina principal

2Consultar httpcodegooglecomapisgearsapi_databasehtmldirectories3Consultar httpcodegooglecomapisgearssecurityhtml

19

Estado da arte

bull Factory ndash Esta classe e utilizada para instanciar todos os outros objectos da

API do Gears atraves do seu metodo create Este metodo pode ser utilizado

com os seguintes parametros

ndash betadatabase

ndash betahttprequest

ndash betalocalserver

ndash betatimer

ndash betaworkerpool

312 Goggle Gears em dispositivos moveis

O Gears esta tambem disponıvel em dispositivos Windows Mobile 5 e 6

Os dispositivos moveis estao pela sua natureza frequentemente desconectados

da Internet Mesmo quando possuem uma ligacao as latencias na transferencia de

dados em redes moveis tornam as aplicacoes pouco fluıdas mas o Gears permite

ultrapassar este obstaculo

O Gears funciona exactamente da mesma forma em dispositivos moveis equipados

com o Windows Mobile 5 e 6 como num computador comum Se uma aplicacao tiver

sido implementado com suporte para o Gears entao tambem estara preparada para

ser executada num dispositivo movel mas as limitacoes dos browsers disponıveis

para dispositivos moveis tem que ser consideradas Isto significa prever as condicoes

que permitam uma boa usabilidade devido aos pequenos ecras destes dispositivos

bem como o seu suporte limitado dos padroes do DOM CSS e JavaScript

32 Adobe AIR

O Adobe AIR4 e um runtime compatıvel com diversos browsers e sistemas opera-

tivos que pretende dar aos programadores a possibilidade de combinar diversas tec-

nologias de producao de conteudos para a Internet no desenvolvimento de Rich Inter-

net Application (RIA)s O Adobe AIR mantem uma relacao com o browser mas es-

tende as suas capacidades e tecnologias permitindo o desenvolvimento de aplicacoes

tambem para o ambiente de trabalho com janelas em tudo semelhantes as do sis-

tema operativo Segundo a Adobe o objectivo e complementar o browser dando

aos utilizadores (mas essencialmente aos programadores e equipas de desenvolvi-

mento) a escolha sobre como distribuir as suas aplicacoes Para este efeito o Adobe

AIR tem uma aproximacao diferente do Gears Em vez de ldquoestenderrdquo o browser

acrescentando-lhe funcionalidades o AIR permite tambem o desenvolvimento de

4Adobe - httpwwwadobecomproductsair

20

Estado da arte

aplicacoes que se destinam a ser executadas fora do ambiente do browser mas uti-

lizando as tecnologias comuns da Internet (por exemplo HTML CSS JavaScript

Flash Flex)[CDGH08]

A utilizacao desta tecnologia permite utilizar o browser ou o proprio runtime

Adobe AIR como plataforma de execucao da aplicacao

Na Tabela 31 faz-se uma comparacao das funcionalidades disponıveis de acordo

consoante se escolha o browser ou o desktop como plataforma base para a aplicacao

Uma vez que as aplicacoes Adobe AIR na plataforma desktop tem um caracter

persistente (sao instaladas no computador do utilizador) o Adobe AIR tem um

modelo de seguranca que se assemelha com o das tradicionais aplicacoes desktop

[Ada08] Este modelo e analisado nas seccoes 321 e 322 O ambiente em que

e executado o browser e restringido a execucao de web applications que podem

ser de varias origens (incluindo de origens anonimas ou sem confianca) O Adobe

AIR proporciona acesso a capacidades como acesso a ficheiros que necessitam da

confianca do utilizador

bull HTML ndash O desenvolvimento de aplicacoes para o Adobe AIR pode ser feito

com recurso a tecnologias de HTML e Ajax comuns utilizando as linguagens

de markup existentes distribuıdas como texto e interpretadas em execucao

(runtime)

bull Flash ndash Outra alternativa sera a utilizacao da linguagem Flash Permite a

renderizacao de graficos vectoriais e audiovıdeo com suporte nativo Utiliza

ActionScript para adicionar maior interactividade com o utilizador

bull Flex ndash O Flex e uma framework open source para o desenvolvimento de RIAs

usando Flash As aplicacoes Flex sao na realidade Flash sendo a principal

diferenca o ambiente de desenvolvimento

Como resultado uma aplicacao AIR podera ser implementada

bull Baseada em Flash ou Flex (aplicacoes cujo conteudo base e em ShockWave

Flash (SWF))

bull Baseada em Flash ou Flex tambem com HTML ou Portable Document Format

(PDF) Aplicacoes cujo conteudo de base e em FlashFlex (SWF) com HTML

(HTML JavaScript CSS) ou conteudo PDF incluıdo

bull Baseada em HTML Aplicacoes cujo conteudo base e em HTML Javascript

CSS

bull Baseada em HTML utilizando tambem FlashFlex ou PDF

21

Estado da arte

Os utilizadores interagem com uma aplicacao AIR da mesma forma que interagem

com outras aplicacoes com janelas nativas do seu sistema operativo O runtime e

instalado uma vez no computador do utilizador e a partir desse momento todas as

aplicacoes AIR terao o mesmo aspecto que qualquer outra aplicacao para o desktop

321 Seguranca

Permitir que uma web application aceda ao disco de armazenamento do utilizador

pode comprometer seriamente a sua seguranca Neste sentido o Adobe AIR tem

suporte para assinaturas digitais (Secure Sockets Layer (SSL)) que podem ser com-

pradas pelas equipas de desenvolvimento que o desejem e cujos certificados serao

apresentados ao utilizador no momento da instalacao Um outro aspecto ainda

relativo a seguranca e o mecanismo de isolamento de cada ambiente (sandbox )

322 Assinatura do codigo

O runtime AIR exige que todas as aplicacoes estejam digitalmente assinadas As

assinaturas digitais de codigo sao um processo que visa garantir a integridade da

aplicacao e a identidade do seu autor no momento da instalacao As equipas de

desenvolvimento podem ldquoassinarrdquo uma aplicacao utilizando um certificado atribuıdo

por uma Entidade Certificadora (Certification Authority) ou atraves de um certifi-

cado individual (self signed certificate) Neste momento o Adobe AIR suporta como

entidades certificadoras a Verisign e a Thawte [Ado08]

O instalador apresenta o nome de quem publica a aplicacao quando o codigo tiver

sido assinado com um certificado que apresente confianca ou que esteja encadeado

com um certificado que tenha ja sido aceite no computador em que se esta a instalar

a aplicacao

As equipas de desenvolvimento podem tambem assinar as aplicacoes com um

certificado auto-atribuıdo (um certificado criado por elas proprias) mas neste caso

o instalador apresentara estas aplicacoes como sendo de uma origem nao verificada

O AIR utiliza a infraestrutura publica de chaves [Ent07] suportada pelo arquivo

local do sistema operativo Para que a origem da aplicacao seja reconhecida o

computador onde a aplicacao AIR esta a ser instalada tem que confiar directamente

no certificado que foi utilizado para assinar a aplicacao ou confiar num certificado

que esteja num encadeamento logico de certificados confiados e que se ligue desta

forma ao certificado utilizado para assinar a aplicacao

Todas as aplicacoes AIR tem caracterısticas em comum independentemente da

tecnologia utilizada para o seu desenvolvimento (HTMLFlexFlash) No ambito

de uma aplicacao AIR existem um conjunto de APIs que estao disponıveis e que

tornam possıvel o acesso ao sistema local (leitura e escrita) e a recursos de rede que

22

Estado da arte

de outra forma nunca estariam acessıveis a partir de uma web application comum

Cada aplicacao AIR possui tambem diferentes nıveis de isolamento chamados secu-

rity sandboxes dependendo do tipo de conteudo que esta a ser carregado e do seu

objectivo

bull Isolamento ao nıvel da aplicacao5 ndash E a raiz de cada aplicacao AIR Este

nıvel de isolamento permite o acesso a APIs privilegiadas e especıficas do

AIR Em contrapartida e negado o acesso a algumas APIs que poderiam ser

facilmente utilizadas de forma maliciosa contra o utilizador final Importacao

dinamica de conteudos remotos e geralmente proibido e as tecnicas e mecan-

ismos de geracao dinamica de codigo sao fortemente restringidas Apenas

conteudo carregado directamente da directoria base da aplicacao podera ser

colocado neste nıvel de isolamento

bull Isolamento nao especıfico da aplicacao6 ndash contem todo o outro conteudo

que nao tenha sido carregado directamente para o isolamento da aplicacao

Isto inclui conteudo local e remoto Este tipo de conteudo nao tem acesso

directo as APIs do AIR e rege-se pelas mesmas regras tal como se tivesse sido

carregado por um browser a partir da mesma localizacao (por exemplo HTML

carregado a partir de um domınio remoto comporta-se da mesma forma que se

fosse acedido a partir do browser)

33 Mozilla Prism

331 XML User Interface Language

O eXtensible User Interface Language (XUL) e uma linguagem de anotacao

baseada em XML desenvolvida pela Mozilla Foundation que opera em aplicacoes

Mozilla multi plataforma tal como o Firefox O motor Gecko e a unica imple-

mentacao completa desta linguagem que foi desenhada sobre padroes web comuns

como CSS JavaScript e o DOM e permite o desenvolvimento de interfaces graficas

utilizando elementos pre-definidos tais como window box page textbox radio

button entre outros Infelizmente o XUL nao possui qualquer especificacao formal

ou implementacoes de inter-operabilidade para outros motores que nao o Gecko No

entanto a sua implementacao e licenciada em codigo aberto pelas licencas GNU Gen-

eral Public License (GPL) GNU Lesser General Public License (LGPL) e Mozilla

Public License (MPL)

Enunciam-se algumas caracterısticas desta linguagem

5NT application sandbox6NT non-application sandbox

23

Estado da arte

Liguagem de anotacao poderosa baseada em componentes (widgets) O ob-

jectivo do XUL e permitir a construcao de aplicacoes multi-plataforma em

claro contraste com o Dynamic HyperText Transfer Protocol (DHTML) que se

destina ao desenvolvimento de paginas web Por esta razao o XUL esta orien-

tado a componentes tais como janelas botoes e etiquetas em vez de paginas

cabecalhos de texto e ligacoes de hipertexto Investir tempo e esforco para

atingir este mesmo resultado em aplicacoes baseadas em DHTML compromete

frequentemente a complexidade e desempenho da aplicacao

Baseado em padroes O XUL e um dialecto XML baseado no padrao W3C XML

10 As aplicacoes escritas em XUL sao tambem baseadas em especificacoes

W3C adicionais como HTML 40 CSS DOM nıvel 1 e 2 JavaScript 15

incluindo ECMA-262 Edition 3 (ECMAscript)

Portabilidade entre plataformas Tal como HTML o XUL foi desenhado para

ser independente da plataforma em que e utilizado tornando as aplicacoes

facilmente portaveis entre sistemas operativos nos quais o Mozilla e suportado

Uma vez que o XUL oferece um nıvel de abstraccao dos componentes graficos

de interface que disponibiliza implementa a premissa ldquoum codigo para todas

as plataformasrdquo A interface grafica de todos os produtos centrais Mozilla

(browser instant messenger livro de enderecos) e escrita em XUL com um

unico codigo base que suporta todas as plataformas Mozilla

Separacao entre o nıvel de apresentacao e a logica de negocio Uma das

maiores preocupacoes no desenvolvimento para a Internet e a forte ligacao

entre estas duas camadas (interface e logica) Isto constitui um problema sig-

nificativo no desenvolvimento de grandes aplicacoes especialmente quando o

desenvolvimento e feito em ambientes de equipa porque as capacidades de de-

senvolvimento destas duas partes da aplicacao estao muitas vezes espalhadas

por diferentes elementos O XUL permite uma clara distincao entre a definicao

da aplicacao cliente e da logica de implementacao (XUL eXtensible Binding

Language (XBL) e JavaScript) apresentacao (CSS e imagens) internacional-

izacao (Document Type Definitions (DTDs) e etiquetas de texto em lınguas

especıficas guardados em ficheiros properties) O esquema grafico e apre-

sentacao de uma aplicacao XUL pode ser alterado de forma independente da

sua logica ou implementacao e a aplicacao pode ainda ser traduzida (interna-

tionalization) de forma independente da sua logica implementacao ou apre-

sentacao Este grau de separacao resulta em aplicacoes que sao mais faceis de

manter pelos programadores e facilmente adaptadas por designers e tradutores

24

Estado da arte

Facil adaptacao Outro benefıcio que advem do nıvel de separacao entre logica

de negocio e apresentacao oferecido pelo XUL e a facilidade com que se pode

adaptar uma aplicacao para diferentes clientes ou grupos de utilizadores Um

programador pode utilizar a mesma aplicacao base e adapta-la consoante as

necessidades atraves de diferentes temas (skins) e ficheiros de lınguas Desta

forma uma aplicacao escrita e desenvolvida em Ingles pode ser rapidamente

traduzida para Portugues e distribuıda com outra aparencia mais apropriada

ao cliente alvo

332 Prism

O Mozilla Prism e um browser simplificado e ldquointerpretadorrdquo de XUL (tambem

designado por XULRunner) que acolhe web applications sem a interface grafica ha-

bitual de um browser Baseia-se num conceito designado por Site Specific Browser

(SSB) Um SSB e uma aplicacao com um browser embebido desenhado para exe-

cutar apenas uma web application Nao possui os menus e barras de ferramentas

habituais Um SSB tem uma integracao com o sistema operativo e com o desktop

muito mais estreita do que uma web application acedida atraves de um browser uma

vez que e executado em janela propria

O Prism resulta de uma experiencia da Mozilla e visa reduzir as diferencas entre

as desktop applications tradicionais e as web applications Um dos aspectos focados e

a experiencia do utilizador Numa apresentacao oficial e dito que ldquo[o Prism] pretende

ser uma ponte entre as diferencas que existem entre as aplicacoes tradicionais de

desktop e as web applications explorando novos modelos de usabilidade enquanto

que a linha que as separa se continua a definirrdquo [Lab07]

34 HTML 5

A especificacao HTML 5 [Hic08] que se encontra em fase de desenvolvimento

pelo grupo WHATWG pretende ser uma norma de substituicao dos padroes HTML

4 XHTML 1x e do DOM2 HTML Uma das propriedades que o distingue das tec-

nologias que pretende substituir e precisamente o suporte para OWA e armazena-

mento de dados no cliente de uma forma relacional Nao sendo propriamente uma

tecnologia ndashmas antes uma especificacao ndashe aqui mencionada por ter servido como

referencia a diversas implementacoes de funcionalidades offline e por se considerar

que venha a ter um impacto significativo nas implementacoes de diversos browsers

Dion Almaer defendeu no seu blogue que o Gears era uma implementacao do

HTML 5 No seu artigo ldquoGears as a bleeding-edge HTML 5 implementationrdquo [Alm08]

o autor diz que ambos ndasho Gears e o HTML 5 ndashpretendem dar a web caracterısticas

25

Estado da arte

semelhantes e nao encontrar motivo de ldquocompeticaordquo entre as duas mas que en-

quanto o HTML 5 e uma especificacao o Gears e uma implementacao

No entanto tambem e verdade que o HTML 5 cobre muitos outros pontos para

alem das OWA que saem completamente fora do ambito do Gears Se esta es-

pecificacao atingir um estado de maturidade que possibilite a sua adopcao pelos

principais browsers tornando nativo do browser o suporte OWA entao deixara de

fazer sentido a existencia de uma extensao como o Gears

A especificacao HTML 5 disponibiliza duas APIs relevantes para o tema das

OWA

1 Uma base de dados baseada em SQL que permite o armazenamento de dados

do lado do cliente

2 Uma ldquocacherdquo HTTP que garante a disponibilidade das aplicacoes mesmo quando

o utilizador nao possui uma ligacao a Internet

Estas caracterısticas sao as bases da tecnologia das OWA e tem correspondencia

com os pontos analisados nas seccoes 311 e 311

35 Web applications que usam funcionalidades offline

Nesta seccao apresentam-se algumas web applications que actualmente disponi-

bilizam funcionalidades offline Estas aplicacoes foram escolhidas para uma analise

mais pormenorizada por utilizarem o Gears que tal como descrito na seccao 4 foi

a tecnologia escolhida para o projecto

351 Google Reader e Google Docs

O Google Reader7 e um leitor de feeds RSS Permite gerir a subscricao de varios

sites simultaneamente que disponibilizem conteudos neste formato e foi a primeira

web application da Google com uma versao offline publicamente acessıvel (desde

Junho de 2007)

O Google Reader implementa o modo ldquoutilizador deciderdquo oferecendo na sua

interface um botao que permite alternar entre os modos online e offline

O Google Docs8 e uma web application que permite a criacao e edicao de doc-

umentos de texto folhas de calculo e apresentacoes Era ja publico desde Janeiro

de 2008 que o Google estava a desenvolver uma versao OWA desta aplicacao mas o

acesso a uma versao experimental so foi possıvel a partir de 31 de Maio de 2008

7Google Reader - httpreadergooglecom8Google Docs - httpdocsgooglecom

26

Estado da arte

A implementacao das funcionalidades offline nestas duas aplicacoes seguiu difer-

entes aproximacoes principalmente porque o Google Reader apresenta ao utilizador

informacoes que sao fornecidas por fontes externas enquanto que no Google Docs

a informacao e criada e editada pelo utilizador sobre a forma de documentos

A diferente origem da informacao implica que no Google Reader seja necessario

prever casos de excepcao tal como existirem demasiados itens que necessitam de

ser transferidos para o cliente Nao observar este ponto causa um problema grave

de usabilidade e para evitar tempos de espera demasiado longos e uma interface

com pouca capacidade de resposta as accoes do utilizador o Google Reader apenas

transfere para o cliente os dois mil itens mais recentes na transicao para o modo

offline

352 Remember the Milk

O Remember The Milk9 e uma web application desenvolvida por uma equipa

Australiana que proporciona funcionalidades de agenda gestao de tempo e de tare-

fas e foi uma das primeiras aplicacoes independentes do Google a adoptar o Gears

para acessos em modo offline Permite que os seus utilizadores facam uma gestao

de tarefas agrupando-as em listas adicionando-lhes campos de informacao adicional

ou dando-lhes informacao geografica (recorrendo ao servico Google Maps10) Entre

a sua lista de funcionalidades encontra-se ainda a possibilidade de importar e ex-

portar eventos no formato iCalendar (ics) etiquetas (tags) em tarefas publicacao

Really Simple Syndication (RSS) e partilha de categorias de tarefas de acordo com

diferentes nıveis de permissoes de acesso definidos pelo utilizador

353 MySpace e WordPresscom

O MySpace uma das maiores social networks na Internet anunciou recente-

mente que vai disponibilizar uma versao do seu cliente de e-mail que utiliza o Gears

para acelerar o seu desempenho Numa fase inicial estara disponıvel apenas para

utilizadores que tenham cinco mil ou mais mensagens na sua caixa de correio e

permitira efectuar pesquisas muito mais rapido que a sua versao online

O servico de blogs Wordpresscom anunciou tambem o inıcio da utilizacao desta

tecnologia com o fim de melhorar o desempenho A versao que utiliza esta tecnologia

descarrega e armazena no cliente um conjunto de imagens e scripts que passam a

ter preferencia sobre os seus congeneres online e que permitem acelerar o processo

de carregamento da aplicacao e visualizacao de blogs

9Remember The Milk ndash httpwwwrememberthemilkcom10Google Maps ndash httpmapsgooglecom

27

Estado da arte

O MySpace e o Wordpresscom sao dois exemplos da utilizacao da tecnologia

OWA para optimizacao de web application ja existentes Sem pretenderem disponi-

bilizar uma versao que seja totalmente offline fazem uso do Gears para armazenar no

cliente parte dos recursos frequentemente acedidos na visualizacao das suas paginas

36 Escolha da tecnologia

Apos a analise das tecnologias apresentada nas seccoes 31 a 34 foi necessario es-

tudar a adequacao de cada uma delas ao projecto em questao Desde logo e possıvel

observar que nem todas se dedicam apenas a OWA Por exemplo o Adobe AIR

apesar de ter suporte para OWA apenas disponibiliza algumas das funcionalidades

identificadas como mais indicadas para a execucao do projecto quando utilizado

na sua vertente desktop tal como exposto na Tabela 31 mas a utilizacao desta

vertente implicaria o desenvolvimento de novas interfaces e de novas formas de co-

municacao (troca de mensagens XML ou JSON) A vertente web do Adobe AIR

foca-se mais especificamente nas Rich Internet Applications e permite a reutilizacao

do codigo ja existente (exigindo naturalmente a sua adaptacao e a implementacao

das funcionalidades pretendidas)

A tecnologia escolhida para a realizacao deste trabalho foi o Gears sendo que

um dos principais factores a influenciar esta opcao foi a liberdade introduzida pela

sua licenca Berkeley Software Distribution (BSD)11

Considerou-se o funcionamento desta ferramenta extremamente adequando a

aplicacao no WOW uma vez que o seu principal objectivo e precisamente tornar

possıvel a execucao offline de uma pagina web e por virtude deste facto o Gears tem

uma API concisa e de simples aplicacao pratica uma vez que nao possui quaisquer

outros elementos distractores O funcionamento do seu ManagedResourceStore ex-

emplificado na Figura 31 com a capacidade de actualizacao de recursos definidos

num ficheiro manifesto especificado em JSON pesou tambem nesta decisao

11Sobre a licenca BSD consultar httpwwwopensourceorglicensesbsd-licensephp e http

wwwlinfoorgbsdlicensehtml

28

Estado da arte

Figura 31 Esquema UML do processo efectuado pelos recursos do Gears do tipoManagedResourceStore para a actualizacao dos conteudos definidos no ficheiro manifesto

29

Estado da arte

Funcionalidade RIAs no browser RIAs no desktop

Disponibilidadeda aplicacao

As aplicacoes podem ser facil-mente exploradas e utilizadas

As aplicacoes quando instal-adas tem maior grau de fun-cionalidades e persistencia

Instalacao Nao e necessario qualquer tipode instalacao

As aplicacoes sao instaladasatraves do browser ou descar-regadas e instaladas comouma aplicacao tradicional

Actualizacoes Aplicacoes sao actualizadascarregando conteudos paraum website

O AIR disponibiliza uma APIque permite que as aplicacoessejam actualizadas de umaforma

Sistemas opera-tivos suportados

As aplicacoes podem ser exe-cutadas em diversos sistemasoperativos e browsers

As aplicacoes sao multi-plataforma e podem serinstaladas e executadas emdiversos sistemas operativos ebrowsers

Linguagens deprogramacao

Javascript e disponibilizadopelo browser e ActionScripte disponibilizado pelo AdobeFlash Player

Maquinas virtuais deJavascript e ActionScriptcompatıveis com o browser

Capacidade deexecucao embackground

As RIAs podem ser execu-tadas numa janela do browser

As aplicacoes podem ser ex-ecutadas em background edisponibilizar notificacoes talcomo uma aplicacao tradi-cional

Persistencia A actividade esta limitada asessao do browser Quando obrowser e encerrado toda ainformacao e descartada

As aplicacoes sao instaladas eestao disponıveis no desktopPodem armazenar informacaolocalmente e estao disponıveisoffline

Integracao com odesktop

Integracao com o desktop lim-itada devido a restricoes im-postas pelo browser

As aplicacoes podem acederao sistema de ficheiro ao clip-board eventos notificacoesetc

Controlo da inter-face com o uti-lizador

As aplicacoes sao acedidasatraves de uma janela dobrowser que tem os seusproprios controlos e visualgrafico

As aplicacoes tem um vi-sual grafico proprio em janelapropria

Armazenamentode dados

As aplicacoes tem armazena-mento limitado que pode serreescrito pelo browser

As aplicacoes tem acesso a to-talidade do espaco disponıvellocalmente e a uma base dedados com a possibilidade deencriptacao

Tabela 31 Comparacao das funcionalidades oferecidas pelo Adobe AIR para as platafor-mas web e desktop

30

Estado da arte

Aplicacao Modo de execucao utilizadoGoogle Reader Utiliza o modo ldquoutilizador deciderdquo disponibilizando

ao utilizador um botao para alternar entre os modosonline e offline Como lida com informacao recol-hida de fontes externas de natureza frequentementeefemera o processo de sincronizacao apenas transfereos dois mil itens mais recentes quando passa ao es-tado offline Neste modo sao ainda guardadas in-formacoes de itens lidos e etiquetas atribuıdas quesao sincronizadas com o servidor quando o utilizadorvoltar a activar estado online

Google Docs Utiliza o modo ldquoaplicacao deciderdquo permitindo que outilizador edite os conteudos de documentos de textofolhas de calculo e de apresentacoes independente-mente do estado da ligacao desde o momento em queas funcionalidades offline sao activadas A aplicacaofaz pequenas sincronizacoes com o servidor sempre quenecessario

Remember the Milk Utiliza um modo hıbrido entre ldquoaplicacao deciderdquo eldquoutilizador deciderdquo A aplicacao encarrega-se da sin-cronizacao de dados mas disponibiliza um controlona sua interface que permite despoletar manualmenteeste processo para situacoes em que o utilizador fez al-teracoes recentes e pretende usufruir das capacidadesoffline imediatamente

MySpace O MySpace anunciou a utilizacao de mecanismos dearmazenamento de dados no cliente com recurso atecnologias OWA para melhorar o desempenho doseu cliente web de correio electronico nomeadamenteno que diz respeito a operacoes de pesquisa e or-denacao Inicialmente esta funcionalidade estara ape-nas disponıvel para utilizadores com cinco mil ou maismensagens na sua caixa de correio mas nao e aindaclaro se sera disponibilizada uma versao totalmenteoffline

Tabela 32 Resumo da utilizacao de tecnologias OWA em algumas web applications con-sideradas na analise do estado da arte

31

Estado da arte

32

Capıtulo 4

Desenvolvimento

Neste capıtulo introduz-se a aplicacao WOW e apresenta-se o estudo que foi

feito da adequacao de cada tecnologia para a implementacao da funcionalidade of-

fline nesta plataforma Fazem-se diversas consideracoes sobre opcoes a tomar na

concepcao de OWAs e problemas comuns na sua implementacao bem como sug-

estoes para os resolver O WOW e uma aplicacao ja existente de gestao de ordens

de trabalho e do fluxo de tarefas numa empresa ou organizacao

41 Como ficar offline

Na maior parte das web applications de hoje nao existe uma camada de dados

real A aplicacao exemplificada na Figura 41 ao longo da sua execucao acede

directamente a sua unica fonte de dados (o servidor) atraves de chamadas Ajax sem

que exista uma separacao clara destas duas camadas

Para que uma web application seja capaz de ser executada sem uma ligacao

activa a Internet e mantenha o seu caracter dinamico torna-se necessario incluir

Figura 41 Exemplo de uma arquitectura de uma web application sem uma camada deabstraccao de dados Figura adaptada de http gears google com

33

Desenvolvimento

Figura 42 Exemplo de uma arquitectura de uma web application com uma camada deabstraccao de dados Figura adaptada de http gears google com

um mecanismo de armazenamento de dados local seja uma base de dados ou a

capacidade de acesso ao disco No entanto este mecanismo introduz dois problemas

1 Qual das fontes de dados utilizar quando um utilizador faz um pedido de

informacao

2 A necessidade de implementar uma camada de acesso a dados que seja coerente

quer se use o servidor remoto ou local

Por exemplo em vez de a aplicacao Ajax fazer um pedido relativo as contas de

todos os utilizadores em formato JSON directamente ao servidor remoto podera ao

inves fazer o pedido a um objecto intermedio da camada de dados Este objecto

demonstrado na Figura 42 sera responsavel por implementar uma interface de

acesso a base de dados e retornar um objecto JavaScript com uma representacao da

resposta do servidor

Mas a existencia de uma segunda fonte de dados torna recomendavel tambem

a implementacao de uma camada de data switching que em funcao da existencia

de conexao a Internet e da necessidade de actualizacao dos dados decide se faz o

pedido ao servidor remoto ou se fornece os dados presentes localmente Este objecto

apresentado na Figura 43 decidira de forma transparente para o utilizador se le ou

escreve os dados localmente ou se os enviapede ao servidor remoto e pode tambem

iniciar o processo de convergencia de dados e de resolucao de conflitos

411 Funcionalidades disponıveis em modo offline

Por razoes praticas e provavel que nem todas as funcionalidades da aplicacao

possam ser disponibilizadas em modo offline E necessario escolher quais as fun-

cionalidades a disponibilizar no modo offline da aplicacao e implementar a logica

que decide quando utilizar a base de dados local ou o servidor remoto Apesar do

acesso a base de dados local ser muito mais rapido do que aceder ao servidor o

acesso local nem sempre e preferido Ha varias razoes que podem tornar necessario

escolher o acesso ao servidor em vez do acesso local

34

Desenvolvimento

Figura 43 Exemplo de uma arquitectura de uma web application com uma camada deabstraccao de dados e um data switch Figura adaptada de http gears google com

1 A informacao pode ter uma natureza efemera e nao fazer sentido guarda-la

localmente Exemplo dados em tempo real da bolsa de valores de Lisboa

2 Algumas aplicacoes lidam com informacao que so faz sentido na presenca de

uma ligacao Exemplo Instant Messaging

3 A aplicacao podera escolher apenas guardar a informacao acedida mais fre-

quentemente Exemplo para o utilizador poder alterar a lıngua de apre-

sentacao da aplicacao os conteudos terao que ser guardados em todas as

lınguas disponibilizadas pela aplicacao O custo de implementacao de algu-

mas funcionalidades pode nao compensar o benefıcio

4 A capacidade de processamento ou de armazenamento de dados pode inviabi-

lizar algumas funcionalidades offline Exemplo se uma dada funcionalidade

necessita de uma capacidade de armazenamento de dados para alem do razoavel

de um computador pessoal para ser util (visualizador de mapas)

42 Modos de execucao

Um aspecto que e necessario estudar para qualquer web application que se deseje

disponibilizar offline prende-se com tres modos de execucao que devem ser consid-

erados

1 Utilizador decide o modo de execucao A aplicacao tem modos distintos

de execucao para os estados online e offline geralmente indicados na interface

com o utilizador O utilizador e informado do estado da ligacao e participa na

alteracao de estado de execucao da aplicacao interagindo com a sua interface

2 Aplicacao decide o modo de execucao Pode ser implementado na propria

aplicacao um mecanismo de deteccao do estado da ligacao (por exemplo atraves

35

Desenvolvimento

de chamadas Ajax periodicas) transitando de estado e sincronizando automati-

camente Desta forma o utilizador nao precisa de participar na alteracao de

estado a menos que exista um conflito de dados que requeira a sua atencao

3 Aplicacao assume sempre o estado offline Outra hipotese sera imple-

mentar uma web application que assume sempre estar na ausencia de uma

ligacao ao servidor de dados Esta aplicacao responde aos pedidos do uti-

lizador efectuando pedidos de informacao ao servidor mas nao dependendo

de uma resposta valida para mostrar a informacao que ja tinha disponıvel an-

teriormente A sincronizacao de dados com o servidor e tentada sempre que

existam dados para submeter e uma accao do utilizador

421 Modo ldquoutilizador deciderdquo

Neste modo de execucao quando a aplicacao esta online comunica com o servidor

remoto quando esta offline comunica com a base de dados local A informacao tem

que ser sincronizada sempre que se muda de modo A principal vantagem desta opcao

e que e a mais simples de implementar mesmo para uma aplicacao ja existente e

portanto uma forma expedita de disponibilizar uma OWA No entanto tem tambem

algumas desvantagens que devem ser consideradas

1 O utilizador tem que se lembrar de fazer a alteracao de estado de execucao

Caso contrario podera estar a trabalhar inadvertidamente numa versao offline

com dados antigos ou nao ter a informacao necessaria se perder subitamente

a ligacao

2 Se a ligacao for intermitente o utilizador tera ou que escolher um dos modos

de execucao ou estar constantemente a trocar

3 Uma vez que a base de dados nao esta sempre actualizada nao podera ser

utilizada para melhorar a rapidez de execucao da aplicacao quando em modo

online

422 Modo aplicacao decide

A deteccao do estado da ligacao pode ser implementada atraves de um pedido

assıncrono ao servidor tal como ilustrado na Figura 44 O resultado deste pedido

definira o estado online (em caso de sucesso) ou offline (em caso de falha) A

sincronizacao de dados podera ser feita sempre que ocorra uma transicao do es-

tado offline para o estado online No entanto este metodo nao se revela eficiente

36

Desenvolvimento

Figura 44 Esquema grafico ilustrando uma OWA executando no browser utilizando ummodo de execucao do tipo ldquoaplicacao deciderdquo com deteccao automatica do estado daligacao via pedidos Ajax assıncronos a cada cinco segundos

para grandes aplicacoes uma vez que requer a troca de mensagens demasiado fre-

quentes com o servidor que se destinam exclusivamente a monitorizacao do estado

da ligacao

423 Modo ldquoaplicacao assume o estado offlinerdquo

Uma aplicacao transparente funciona assumindo sempre que esta em modo of-

fline ou pelo menos que pode perder a ligacao a qualquer momento Neste modo

tira-se o maximo partido do armazenamento local e fazem-se pequenas mas contınuas

sincronizacoes com o servidor sempre que este esteja disponıvel A sincronizacao de

dados tambem e feita sempre que se volta ao estado online

As vantagens de uma web application transparente sao as seguintes

bull Uma melhor experiencia para o utilizador uma vez que este nao tem que se

preocupar com o estado da ligacao ou com a transicao de estados

bull A aplicacao funciona de forma coerente mesmo que a ligacao seja intermitente

bull Uma vez que o armazenamento local e mantido actualizado pode ser utilizado

para melhorar o desempenho da aplicacao

Foram identificadas as seguintes desvantagens

bull E mais difıcil de implementar e a sincronizacao acarreta cuidados especiais

bull E necessario um cuidado adicional para evitar que as operacoes de sincronizacao

frequentes que ocorrem automaticamente nao afectem os tempos de resposta

da aplicacao

bull Os testes a aplicacao sao mais complexos uma vez que a sincronizacao de dados

nao ocorre em resposta a uma accao do utilizador

37

Desenvolvimento

43 Sincronizacao de dados

A sincronizacao de dados consiste na capacidade de identificar e transferir pe-

riodicamente a versao mais actual dos dados entre o cliente e o(s) servidor(es)

Independentemente do modo de execucao escolhido e mesmo do estado da ligacao

do utilizador a informacao armazenada localmente e a informacao armazenada no

servidor estarao por vezes dessincronizadas Isto podera acontecer sempre que por

exemplo

bull O utilizador faz alteracoes em modo offline

bull A informacao e partilhada e pode ser alterada por uma entidade externa

bull A informacao e fornecida por uma entidade externa

Resolver estas diferencas de forma a que a informacao local e remota encontrem

a igualdade chama-se sincronizacao de dados Ha varias aproximacoes possıveis

para este efeito que dependem da natureza da aplicacao cada uma com vantagens

e desvantagens

A capacidade de suportar a mobilidade dos utilizadores torna-se cada vez um

ponto mais importante de uma web application Para uma organizacao de dimensao

global e vital garantir que os seus colaboradores tem acesso a mesma informacao

que tem disponıvel nos seus postos de trabalho mesmo quando estao fora Na maior

parte dos casos estes colaboradores terao acesso a um computador portatil um

desktop Smartphone ou PDA e atraves destes poderao ter acesso a sua informacao

directamente atraves de ligacoes encriptadas Virtual Private Network (VPN) de um

servidor web ou de outro mecanismo de rede

Esta solucao e simples de implementar mas infelizmente para a maioria dos

colaboradores com grande factor de mobilidade nao e satisfatoria As principais

desvantagens sao as seguintes

bull Requisitos de ligacao Para permitir que os utilizadores acedam a sua in-

formacao e necessario garantir a capacidade constante de comunicacao pelo

menos durante o tempo necessario que assegure a sua transferencia

bull Velocidade de ligacao sem persistencia de dados e em ligacoes de fraca

qualidade a usabilidade por vezes torna-se inaceitavel

bull Ponto crıtico de falha Com este tipo de solucao todos os utilizadores de-

pendem da base de dados que armazena informacao vital para o funcionamento

do cliente

38

Desenvolvimento

bull Scalability do servidor A medida que novos utilizadores sao adicionados ao

sistema o desempenho do servidor e afectado levando a necessidade de maior

capacidade de armazenamento eou processamento

De acordo com a documentacao da Microsoft Sync Framework [Mic08] uma

solucao alternativa consiste em implementar uma Occasionally Connected Appli-

cation (OCA) Uma OCA permite a um utilizador remoto continuar a aceder a

sua informacao mesmo depois de perder a ligacao mas em vez de recorrer a um

servidor recorre a informacao armazenada no seu dispositivo local Para preencher

localmente a informacao que o utilizador necessita uma OCA possui mecanismos

de sincronizacao de dados que sao oferecidos por esta framework

431 Quando sincronizar

Uma das solucoes mais simples de implementar passa por disponibilizar um

mecanismo manual que despoleta a sincronizacao Diz-se manual porque e o uti-

lizador que escolhe quando sincronizar e pode ser implementada simplesmente

fazendo o upload de toda a informacao para o servidor e depois fazendo o download

da copia mais recente da informacao antes de voltar a ficar offline Para que esta

seja uma opcao viavel e necessario que

bull O volume de dados seja suficientemente pequeno para que possa ser transferido

do servidor para o cliente num espaco de tempo aceitavel

bull Que o utilizador indique explicitamente que quer mudar para o estado offline

ou online pressionando um botao da interface

Contudo podem ser identificados alguns problemas relacionados com esta abor-

dagem

bull Os utilizadores nem sempre podem prever o estado das suas ligacoes A ligacao

pode-se perder subitamente ou ter um caracter intermitente

bull O utilizador pode esquecer-se de efectuar a sincronizacao

Outra opcao sera conjugar a sincronizacao de dados com o modo de execucao

transparente A sincronizacao ocorre automaticamente em background de forma

nao intrusiva para o utilizador A aplicacao comunica com o servidor regularmente

efectuando pequenas trocas de dados com o objectivo de manter o sincronismo da

informacao local e remota Esta abordagem pode ser implementada com pedidos

Ajax assıncronos e regulares ao servidor o que permite manter a interaccao com a

interface fluıda evitando bloqueios Estes pedidos sao feitos prevendo as situacoes

39

Desenvolvimento

de disponibilidade ou indisponibilidade (timeout) do servidor Uma outra opcao

sera permitir que o servidor comunique essas alteracoes utilizando Comet1 tal como

descrito em [Wil06] e [Rus06] As vantagens destas aproximacoes sao

bull A informacao esta disponıvel a qualquer altura que o utilizador decida ficar

offline ou que a ligacao seja acidentalmente perdida

bull O desempenho da aplicacao pode ser melhorado quando se estiver a utilizar

uma ligacao a Internet lenta uma vez que o acesso a dados locais e mais

eficiente do que a consulta de dados ao servidor

44 WOW

O WOW e uma plataforma integrada de gestao de ordens de trabalho ja ex-

istente e desenvolvida pela Critical Software SA a qual se pretende adicionar a

capacidade de execucao offline Esta aplicacao e extremamente dinamica e con-

figuravel com um conjunto extremamente rico de funcionalidades das quais se

destacam

bull Gestao de Ordens de Trabalho ndash suportando a gestao dos pedidos desde a

sua criacao ate ao seu fecho tomando em conta os diferentes tipos de pedidos

(ordens de trabalho pedidos de informacao melhorias resolucao de problemas

etc) e diferentes tipos de accoes possıveis para cada um (Figura 45)

bull Monitorizacao de alteracoes ndash Historico de mudancas anexos e estados criando

relatorios de alteracao automaticamente (o que por quem e quando)

bull Uso de Service Level Agreements (SLAs) ndash E possıvel associar a um pedido um

SLA que define qual o perıodo de tempo atribuıdo a resolucao de um pedido

controlando e agilizando a resolucao do mesmo

bull Utilizacao de queries de utilizador configuraveis que permitem acesso rapido

a determinadas ordens de trabalho de acordo com o filtro configurado (por

exemplo ldquoPara mimrdquo ldquoPara o Grupordquo ldquoPelo Grupordquo)

bull Gestao do relacionamento entre pedidos

bull Pesquisa e filtragem de ordens de trabalho

bull Exportacao de dados em formatos padrao (PDF DOC ou XLS)

bull Integravel com solucoes externas

40

Desenvolvimento

Figura 45 Detalhe de um conjunto possıvel de estados e respectivas transicoes para umadada ordem de trabalho no WOW desde a sua submissao no sistema ate a sua conclusaoem fecho ou cancelamento Esta figura representa apenas um exemplo ja que o mapa deestados para uma ordem de trabalho e dinamico e pode ser alterado por um administradorFigura retirada de uma brochura promocional do WOW Critical Software SA

A utilizacao de uma ferramenta deste tipo por parte de uma empresa ou orga-

nizacao oferece vantagens quer a gestao de topo quer aos colaboradores individuais

para os colaboradores individuais o WOW e uma aplicacao onde estao registadas

todas as tarefas contribuindo activamente para o desenvolvimento em ambientes

multi-tarefa e para a organizacao pessoal das tarefas de acordo com prioridades

Para a gestao de topo esta ferramenta permite obter uma visao global do estado da

organizacao em termos de tempo gasto por tarefa executada sendo uma mais valia

para a previsao e gestaoalocacao de recursos

45 Visao geral sobre a arquitectura do WOW

O WOW e interessante nao so do ponto de vista de produto como tambem do

ponto de vista de plataforma Existem diversos plug-ins que estendem as funcional-

idades do WOW e existem ate projectos que pretendem usar a arquitectura do

WOW para criar produtos com fins diferentes do inicial (por exemplo o WOW-

Storm ndash um sistema de registo e classificacao social de ideias)

De modo a conseguir ter essa expansibilidade a plataforma WOW assenta sob

uma arquitectura distribuıda modular e expansıvel com uma componente central

ndash o core ndash estruturado em camadas logicas E no core que se situam todas as

1O Comet e um conceito semelhante ao Ajax introduzido por Alex Russel mas no qual e o servidor quetoma a iniciativa de ldquoenviarrdquo os dados ao browser sem que este tenha que efectuar um pedido Tambem econhecido por Ajax Push Reverse Ajax ou HTTP Streaming

41

Desenvolvimento

funcionalidades base da aplicacao quer a nıvel logico funcional e de apresentacao

quer a nıvel de gestao e configuracao

E possıvel a execucao de varias instancias do core simultaneamente em servidores

distintos o que permite a alta escalabilidade e disponibilidade desta aplicacao A

consistencia dos dados fica sempre garantida atraves da partilha da base de dados

e pelo balanceamento dos pedidos uma vez que cada um e encaminhado para uma

unica instancia

O WOW apresenta tambem a vantagem de ser uma plataforma extensıvel E

possıvel adicionar novas caracterısticas a plataforma atraves de componentes que se

podem ser divididos em duas categorias plugins e connectors

Os plugins sao componentes que se encontram no mesmo no fısico que a aplicacao

partilhando do mesmo contexto de execucao do core Sao assim uma forma mais

directa de obter informacao da plataforma visto que nao possuem restricoes de

acesso aos dados nem dependencias externas A arquitectura deste componente tera

assim que permitir varias execucoes instanciadas cada uma associada a um core

Por outro lado os connectors sao componentes que se encontram distribuıdos

comunicando externamente com o core Quer a sua execucao quer a obtencao

dos dados estao assim dependentes de interfaces de comunicacao externas que a

plataforma disponibiliza Estes componentes ao contrario dos plugins sao instan-

ciados unicamente e recorrem ao protocolo de comunicacao Java Messaging Service

(JMS) para comunicar com o core

46 WOW Offline

Para alem das opcoes tomadas relativamente a tecnologia a utilizar surgiu

tambem a necessidade de optar por um dos modos de execucao apresentados na

seccao 42

Das tres opcoes possıveis foi o modo ldquoaplicacao assume o estado offlinerdquo descrito

na seccao 423 que mereceu a maior atencao uma vez que reune as vantagens de

uma experiencia mais positiva para o utilizador (uma vez que este nao tem que

participar activamente na alteracao do modo execucao como descrito na seccao 421)

e nao constitui uma sobrecarga excessiva para servidor (como o modo abordado na

seccao 422)

No entanto esta opcao comprometia a complexidade da implementacao para alem

dos objectivos propostos para este projecto e para cumprir o prazo dado foi tomada

a decisao de implementar o modo ldquoutilizador deciderdquo especificando apenas de forma

teorica o modo ldquoaplicacao assume o estado offlinerdquo

As caracterısticas do Gears foram ja descritas na seccao 31 Na Figura 47

mostra-se a sua forma de funcionamento quando integrado numa web application

42

Desenvolvimento

Nesta figura representa-se o modulo LocalServer do Gears como um ponto de de-

cisao Aqui sao testadas as condicoes que determinam se o pedido sera interceptado e

servido localmente ou se prossegue para uma maquina remota E tambem represen-

tada uma base de dados que corresponde ao modulo Database mas que podera nao

ser utilizada Este modulo tal como o modulo Workerpool tem caracter opcional

e sao utilizados consoante os requisitos da aplicacao

A plataforma WOW lida com mais dados do que e necessario passar para o

lado do cliente Em conformidade com o ja exposto na seccao 411 volta-se a

frisar que nao se pretende recriar toda a logica de negocio nem os conteudos da

base de dados no cliente pela sua complexidade e volume de dados Pretende-se

pelo contrario permitir que os utilizadores tirem partido da capacidade de poder

consultar as suas ordens de trabalho quando nao dispoe de uma ligacao transferindo

apenas o essencial para isto seja possıvel

A pagina inicial do WOW apresenta um resumo das ordens de trabalho abertas

ndash enviadas e recebidas ndash que se pretende permitir visualizar offline (ver Figura 46)

Como prova de conceito foi efectuada uma abordagem pragmatica das varias possi-

bilidades descritas na seccao 42

461 Modo ldquoaplicacao deciderdquo com deteccao automatica da ligacao

A primeira abordagem estudada para a disponibilizacao das funcionalidades of-

fline foi o modo ldquoaplicacao deciderdquo com deteccao automatica de ligacao apresentado

na seccao 422 Para que isto seja possıvel foi implementado um mecanismo de ver-

ificacao periodica do estado da ligacao atraves de chamadas Ajax assıncronas O

resultado destes pedidos determina o estado da aplicacao executando as tarefas de

sincronizacao de dados sempre que pertinente Este metodo embora imediato e

simples de implementar depressa se revelou inadequado para o projecto devido ao

elevado consumo de recursos do servidor que a utilizacao intensiva faz esperar a

comunidade da plataforma WOW no principal cliente excede os 7000 utilizadores

Foi estimado que para uma utilizacao de fluidez aceitavel o estado da ligacao deveria

ser testado a cada cinco segundos Assumindo uma adesao (previsao pessimista) de

1 aos servicos offline assistir-se-ia a cerca de 840 pedidos adicionais por minuto

Mas o principal problema desta aproximacao prende-se com o facto de a ver-

ificacao ser feita em intervalos de tempo discretos levando a possibilidade de a

aplicacao poder ter em dado momento uma representacao errada do seu estado

real da ligacao Este problema e ilustrado na Figura 48 onde se ve claramente a

discrepancia entre o estado real da ligacao e a representacao interna que esta tem

Note-se que nesta janela de tempo qualquer accao do utilizador que exija uma

resposta sıncrona do utilizador leva-lo-a para um ldquobeco sem saıdardquo onde nao tera

43

Desenvolvimento

Figura 46 A pagina inicial do WOW apresenta um resumo das ultimas ordens de trabalhoenviadas e recebidas Na imagem pode-se observar a transicao do estado online para offline

acesso a versao offline porque a aplicacao nao fez a transicao automatica nem acesso

a versao online porque na verdade nao possui uma ligacao O que acontecera nesta

situacao sera uma tentativa de acesso ao servidor por parte da aplicacao numa

altura em que este se encontra indisponıvel e o resultado sera uma mensagem de

ldquopedido excedeu o tempordquo apresentado pelo browser Este e um estado sem retorno

porque apos o browser apresentar esta mensagem todos os recursos JavaScript ficam

indisponıveis tornando impossıvel o regresso ao estado anterior ou o tratamento do

erro de qualquer outra forma No entanto as chamadas Ajax podem ser tratadas de

forma especial para a eventualidade de falha e portanto nao constituem problema

44

Desenvolvimento

Figura 47 Ilustracao do funcionamento do Gears numa web application que utiliza ummotor Ajax Os pedidos HTTP ou HTTPS podem ser interceptados e tratados localmenteou podem ser feitos a uma maquina remota consoante se verificarem ou nao as condicoesexpressas no ponto 311 E representado um acesso a uma base de dados local (fornecidapelo Gears) mas a sua utilizacao e opcional

462 Implementacao do modo ldquoutilizador deciderdquo

Este modo de execucao foi ja descrito na seccao 421 e a sua principal carac-

terıstica e ser o utilizador a decidir se a aplicacao deve utilizar um servidor remoto

ou a maquina local como fornecedor de dados

Relativamente ao WOW o WOW Offline na vertente ldquoutilizador deciderdquo vem

alterar os seus casos de uso dando ao utilizador a possibilidade de alterar o estado

de execucao da aplicacao (entre online e offline) Resta dizer que no modo online se

mantem todas as funcionalidades anteriores e que no modo offline torna-se possıvel

visualizar os conteudos da pagina principal do WOW (Figura 46) e os detalhes das

ordens de trabalho (Figura 49) tal como expressa a Figura 410

Esta aproximacao foi utilizada na prova de conceito do WOW adicionando um

controlo a interface desta aplicacao que permite ao utilizador alternar entre os esta-

dos online e offline Na transicao de online para offline sao descarregados os recursos

necessarios para a execucao desta aplicacao sem recorrer a Internet Para o fazer

45

Desenvolvimento

Figura 48 Neste exemplo do modo ldquoaplicacao deciderdquo o teste da ligacao e feito e feito acada cinco segundos O resultado deste teste nao reflecte sempre o estado real da aplicacaopodendo levar a aplicacao a ter comportamentos indesejaveis Na figura assinala-se umperıodo de tempo no qual a representacao interna do estado da ligacao nao corresponde arealidade

e utilizado um recurso ResourceStore e um ManagedResourceStore (introduzidos

em 311) O primeiro e utilizado para armazenar a pagina principal do WOW ndash do-

ravante designada por homejsp ndash e o segundo e utilizado para armazenar imagens

folhas de estilo CSS e scripts JavaScript

Para a implementacao deste modo de execucao foram identificadas as seguintes

tarefas

1 Guardar informacao que permita a recriacao das paginas que se pretende

disponibilizar offline (utilizando o Gears)

2 Disponibilizar um controlo que permita alterar o estado de execucao atraves

da interaccao com a pagina principal

3 Durante a sincronizacao de dados apresentar o progresso da transferencia de

dados

O primeiro passo consistiu na identificacao de todos os conteudos que sao necessarios

transferir para a execucao offline Foi utilizado um recurso do Gears do tipo

ManagedResourceStore que recorre a um ficheiro manifesto para identificar to-

dos os ficheiros que deve transferir Este recurso e gerido automaticamente pelo

Gears transferindo para o cliente a versao mais recente sempre que e necessario

isto e sempre que exista um ficheiro manifesto com uma identificacao de versao que

seja diferente da actualmente disponıvel no cliente Uma vez identificados todos

ficheiros necessarios para a execucao offline num (ou mais) ficheiros manifesto o

Gears encarrega-se da sua actualizacao mas o preenchimento destes ficheiros man-

ifesto e manual o que se traduz num cuidado extra na manutencao da aplicacao

A forma como esta informacao e guardada deve tambem ser cuidadosamente

estudada A opcao mais flexıvel passa por utilizar o modulo Database apresentado

na seccao 311 e guardar a informacao de uma forma relacional Para a recriacao

das paginas pode ser disponibilizada uma versao HTML da pagina que funciona

46

Desenvolvimento

Figura 49 Pagina de visualizacao do detalhe de uma ordem de trabalho

como template nao possui quaisquer dados e e utilizada apenas em modo offline E

preenchida para cada pedido retirando os dados relevantes da base de dados

O modelo de dados do WOW torna esta opcao extremamente trabalhosa uma

vez que as entidades envolvidas na geracao de cada pagina de informacao sobre

cada ordem de trabalho tem relacoes de dependencia complexas seguindo padroes

muito variaveis Por exemplo em cada ordem de trabalho existe um formulario que

permite a sua progressao de estado com diversos campos opcionais e obrigatorios

este formulario e definido pelo administrador e esta relacionado nao apenas com o

tipo de ordem de trabalho mas tambem com o estado actual em que esta se encontra

e a accao que se pretende realizar O elevado numero de combinacoes de tipos de

ordem de trabalho estados e accoes que existem num dado momento juntamente

com a sua possibilidade de alteracao obrigariam a implementacao de uma logica de

negocio complexa o que esta fora do ambito deste projecto

47

Desenvolvimento

Figura 410 Esquema UML que expressa os casos de uso do WOW Offline no modoldquoutilizador deciderdquo

463 Especificacao do modo ldquoaplicacao assume o estado offlinerdquo

A aproximacao para o modo ldquoaplicacao assume o estado offlinerdquo foi tambem

dividida em varias tarefas

1 Guardar informacao que permita a recriacao da pagina principal do lado do

cliente no estado offline (utilizando o Gears)

2 Dotar a aplicacao do cliente de um mecanismo de deteccao da ligacao

3 Identificar os ldquomomentos chaverdquo em que devera ocorrer sincronizacao de dados

4 Implementar a sincronizacao de dados

A sincronizacao de dados deve ser feita em ambas as transicoes online-offline e

offline-online quer para transferir novos dados do servidor (os pedidos podem ser

alterados por outros utilizadores) quando se transita do estado quer para comunicar

eventuais alteracoes feitas em modo offline

Relativamente ao WOW o WOW Offline na vertente ldquoaplicacao assume o es-

tado offlinerdquo vem alterar os seus casos de uso dando ao utilizador a possibilidade

de activar esta funcionalidade A partir do momento que a funcionalidade esta ac-

tivada o utilizador deve tambem ter a possibilidade de gerir algumas preferencias

relacionadas com privacidade de dados Devera ter a hipotese de desactivar o ar-

mazenamento local e de remover todos os dados ja armazenados tal como descrito

na Figura 411

48

Desenvolvimento

Figura 411 Esquema UML que expressa os casos de uso do WOW Offline no modoldquoutilizador deciderdquo

A primeira vez que o WOW Offline e acedido por um cliente e caso seja detec-

tada a presenca do Gears todos os recursos necessarios a sua execucao sao trans-

feridos Todos os acessos posteriores serao feitos a estes recursos locais (recorda-se

que o Gears pode ser utilizado para os manter actualizados recorrendo ao Managed-

ResourceStore 311)

Atraves do JavaScript e possıvel interceptar os eventos de load e unload da

pagina que sao despoletados sempre que ocorre um re-acesso da mesma (incluindo

a accao refresh comum dos browsers) sempre que esta e abandonada ou ainda ou

ainda se a janela for encerrada

Tal como sugerido na seccao 462 a camada de interface desta aplicacao (cada

pagina individual em HTML) devera ser implementada como sendo um template

para apresentacao de dados sendo totalmente preenchida atraves de funcoes em

JavaScript O objectivo deste ponto e criar um padrao de dados que permita ao

JavaScript preencher os dados em cada pagina (template) independentemente de

qual seja a fonte ndash o servidor remoto ou a maquina local tal como exemplificado

no diagrama da Figura 412 Na figura a aplicacao recorre ao servidor remoto para

obter os dados pretendidos quando se encontra na presenca de uma ligacao mas

para dados que exijam uma carga de processamento pelo servidor este acto pode ser

49

Desenvolvimento

Figura 412 Esquema UML que expressa o acto de recolha de dados em modo online eoffline recorrendo ao servidor (modo online) e ao sistema de armazenamento de dadoslocal fornecido pelo Gears (modo offline)

substituıdo pelo envio de um campo de controlo que se destina a aferir se os dados

locais se encontram actualizados No caso de estarem actualizados a comunicacao

com o servidor pode ser substituıda por uma query a base de dados local

50

Capıtulo 5

Resultados e Futuros

Desenvolvimentos

Todo o estudo feito sobre o tema OWA foi ja abordado ao longo do documento

Neste capıtulo apresentam-se os resultados obtidos na implementacao da prova de

conceito que visava compreender a melhor forma de disponibilizar uma versao of-

fline no WOW uma plataforma de gestao de ordens de trabalho ja existente de-

senvolvida pela Critical Software SA

51 Resultados Obtidos

Os resultados obtidos neste projecto sao extremamente satisfatorios uma vez

que o estudo do tema OWA e a implementacao de uma prova de conceito que o

ilustrasse foi conseguido com sucesso

A funcionalidade offline foi adicionada ao produto WOW da Critical Software

SA permitindo a visualizacao de ordens de trabalho e dos seus detalhes mesmo na

ausencia de uma conexao activa a Internet Embora para a solucao implementada

tenha sido utilizada uma abordagem do tipo ldquoutilizador deciderdquo pretende-se que esta

seja convertida para ldquoaplicacao deciderdquo ou mesmo para uma aproximacao hıbrida

semelhante a utilizada pelas aplicacoes estudadas nas seccoes 351 e 352

Para a sua implementacao descrita no capıtulo 4 foram tomadas decisoes de or-

dem pratica que permitissem tornar o trabalho exequıvel nos prazos dados Tentou-

se sempre que estas decisoes afectassem o mınimo em termos de desempenho e de

experiencia para o utilizador Considera-se que a implementacao do modo offline

com uma transicao entre modos do tipo ldquoutilizador deciderdquo (ver seccao 42) reflecte

o compromisso entre o desempenho pretendido e os recursos disponıveis e para alem

51

Resultados e Futuros Desenvolvimentos

de ser um exemplo eficaz das possibilidades que as OWA podem trazer a aplicacao

WOW desenvolvida pela Critical Software e tambem um estudo que pode ser uti-

lizado para analisar a implementacao desta tecnologia noutros produtos da mesma

empresa

Note-se que o principal objectivo do trabalho era ganhar familiaridade com este

tema entender as suas vantagens e desvantagens e compreender as suas limitacoes

Tudo indica que existam varias possibilidades de implementacao deste paradigma

noutros produtos da Critical Software que pela sua natureza podem tambem tirar

partido da execucao offline

52 Trabalho Futuro

O desenvolvimento do conceito e formas de implementacao de OWA continua

em forte desenvolvimento no entanto a sua adopcao ainda nao e generalizada A

dificuldade da sua implementacao em web applications ja existentes e o principal

obstaculo a sua maior divulgacao

Ha tambem um factor que deve ser tido em consideracao a manutencao de

codigo A implementacao de uma versao offline de uma web application requer

a implementacao das mesmas regras de negocio (ou de uma versao simplificada)

utilizadas no servidor Para que isto seja possıvel e necessario ter em conta a

capacidade de processamento do cliente e o factor de duplicacao de codigo que

tornara a aplicacao mais difıcil de manter uma vez que uma alteracao a logica de

negocio do servidor implica tambem uma alteracao a sua versao offline

A prova de conceito implementada permite ja a visualizacao offline dos pedidos

abertos (enviados e recebidos) que constam na pagina principal (este numero e

fixo e pode ser alterado pelo administrador) Uma funcionalidade desejavel seria a

possibilidade de interaccao com a aplicacao em modo offline e sincronizacao com o

servidor quando existisse uma ligacao disponıvel

Foi estudada a utilizacao do modo de execucao ldquoaplicacao assume o estado of-

flinerdquo descrito em 423 e esta seria a forma desejavel para o WOW Offline no

entanto para que esta opcao seja viavel sera necessaria a implementacao de uma

forma eficiente de sincronizacao e armazenamento de dados de uma forma relacional

Para atingir este objectivo podera ser seguida uma polıtica de automacao do pro-

cesso no qual a versao online da aplicacao gera scripts de criacao para as tabelas

necessarias na base de dados da versao offline (nao existe nenhuma ferramenta para

o fazer portanto seria necessaria a sua implementacao) e no qual as paginas HTML

disponibilizadas pelo servidor aos clientes web (browser) servem como templates de

apresentacao de informacao e sao preenchidas de forma semelhante pelo servidor ndash

quando a aplicacao estiver online ndash ou pelo cliente atraves de funcoes em JavaScript

52

Resultados e Futuros Desenvolvimentos

ndash quando a aplicacao estiver offline No entanto no WOW devido a quantidade de

informacao tratada e devido as complexas relacoes entre as diferentes entidades e

de esperar que a complexidade da implementacao de um mecanismo deste tipo torne

esta aproximacao demasiado custosa

O HTML 5 embora um forte candidato ainda nao esta suficientemente desen-

volvido A sua especificacao ainda tem o caracter de Draft (rascunho) e esta sujeita

a modificacoes e a aceitacao e implementacao por parte dos browsers e portanto

de momento foi desconsiderado No entanto no futuro se esta especificacao atingir

um estado de maturidade que permita a sua adopcao devera ser considerada como

um possıvel caminho a seguir

53

Resultados e Futuros Desenvolvimentos

54

Capıtulo 6

Conclusoes

Neste capıtulo sao apresentadas as conclusoes do projecto e consideracoes finais

relativamente a tecnologia estudada

61 Conclusoes

O rapido desenvolvimento tecnologico faz prever que a disponibilidade de ligacao

a Internet seja cada vez mais facil e mais rapido mas vao continuar a existir lugares

onde o acesso e limitado e onde as OWA podem desempenhar um papel de relevo

Por outro lado esta tecnologia pode tambem ser utilizada para melhorar o desem-

penho de paginas web com uma necessidade elevada de imagens ou outros recursos

dispendiosos em termos de espaco e foram ate estudados dois exemplos da utilizacao

desta vertente desta tecnologia em 353

Acredita-se que as OWAs vem responder a uma necessidade real por parte das

web applications actuais e que a evolucao que representam se compara a que se

assistiu dos thin-clients para os fat-clients em termos de autonomia do servidor

A capacidade de oferecer conteudos dinamicos no browser independentemente da

existencia de uma ligacao reune as vantagens tıpicas das web applications como

ausencia de instalacao e actualizacoes instantaneas com as vantagens das aplicacoes

de desktop em capacidade de processamento e armazenamento de dados na maquina

local

As tecnologias disponıveis ate a data estudadas no ambito deste projecto que

permitem o desenvolvimento de OWAs e que apresentam maior maturidade sao o

Gears e o Adobe AIR Ambas se apresentam sobre a forma de plugins que necessitam

de uma instalacao extra para poderem ser utilizadas Apesar de esta instalacao ser

55

Conclusoes

apenas necessaria uma vez podera constituir um factor de desencorajamento a sua

adopcao

O HTML 5 uma especificacao abordada neste documento na seccao 34 podera

ser uma alternativa que oferece funcionalidades offline a uma web application sem a

necessidade de qualquer instalacao no entanto esta especificacao ainda nao foi aceite

pelos principais browsers ndash o documento que define o HTML 5 ainda tem o estatuto

de Draft ndash e ainda nao e possıvel antecipar quando e que isto podera acontecer

Um dos problemas que surge frequentemente na implementacao de uma versao

offline para uma web application e a necessidade de sincronizacao de dados Quando

a informacao pode ser alterada por varios utilizadores simultaneamente e necessario

prever os conflitos que daı podem surgir e dotar a aplicacao de uma forma de os

resolver ou alertar o utilizador para a necessidade de alteracao dos dados

Em conclusao todos os objectivos propostos para este projecto foram atingidos

A prova de conceito implementada reflecte de forma clara as possibilidades oferecidas

pela tecnologia OWA e sera utilizado no futuro para compreender a melhor forma

de o implementar de forma definitiva no WOW

56

Referencias

[Ada08] Lucas Adamski Introducing Adobe AIR security model Fevereiro de2008 Disponıvel em httpwwwadobecomdevnetairarticles

introduction_to_air_securityhtml acedido em Marco de 2008

[Ado08] Adobe Adobe AIR 10 Security White Paper 2008 Disponıvel emhttpdownloadmacromediacompubairdocumentation1air_

securitypdf acedido em Marco de 2008

[Alm08] Dion Almaer Gears as a bleeding-edge html 5 implementa-tion March 2008 Disponıvel em httpalmaercomblog

gears-as-a-bleeding-edge-html-5-implementation acedido emMarco de 2008

[BL96] Tim Berners-Lee The world wide web Past present and future Agostode 1996 Disponıvel em httpwwww3orgPeopleBerners-Lee

1996ppfhtml acedido em Abril de 2008

[CDGH08] Mike Chambers Daniel Dura Dragos Georgita and Kevin Hoyt AdobeAIR for JavaScript Developers OrsquoReilly Media 2008 Disponıvel emhttponairadobecomfilesAIRforJSDevPocketGuidepdf ace-dido em Abril de 2008

[Con99] Jim Conallen Modeling Web Application Architectures with UML Junho1999 Disponıvel em httpwwwumlorgcnUMLApplicationpdf

webappspdf acedido em Maio de 2008

[Ent07] Entrust What is a public key information 2007 Disponıvel em http

wwwentrustcompkihtm acedido em Junho de 2008

[Gar05] Jesse James Garret Ajax A new approach to web applicationsFebruary 2005 Disponıvel em httpwwwadaptivepathcomideas

essaysarchives000385php acedido em Marco de 2008

[Greon] Philip Greenspun Philip and Alexrsquos Guide to Web Publishing 2003(last revision) Disponıvel em httpphilipgreenspuncompandaacedido em Junho de 2008

[Gro02a] App Design Group Thick vs thin client comparison 2002 Disponıvelem httpwwwdonjacobsvwcomimagesweekendspecials

Thick-vs-Thinpdf acedido em Junho de 2008

57

REFERENCIAS

[Gro02b] Technical Research Group Thin Client Tecnhology - WhitePaper 2002 Disponıvel em httpwwwpicktrgcompubs

thinclientwhitepaperpdf acedido em Junho de 2008

[Gro08] Miniwatts Marketing Group World internet usage March 2008Disponıvel em httpwwwinternetworldstatscomstatshtm ace-dido em Abril de 2008

[Hic08] Ian Hickson HTML 5 Draft Recommendation 2008 Disponıvelem httpwwwwhatwgorgspecsweb-appscurrent-work ace-dido em Marco de 2008

[Kha] Olga Kharif Top 10 municipal wifi plans Disponıvel em http

imagesbusinessweekcomss0608muni_wifiindex_01htm ace-dido em Marco de 2008

[Lab07] Mozilla Labs Prism Outubro 2007 Disponıvel em httplabs

mozillacom200710prism acedido em Marco de 2008

[Loo06] Chris Loosley Rich Internet ApplicationsDesign MeasurementandManagement Challenges 2006 Disponıvel em httpwwwkeynote

comdocswhitepapersRichInternet_5pdf acedido em Maio de2008

[Mic08] Microsoft Introduction to Occasionally Connected Applications us-ing Sync Services for ADONET 2008 Disponıvel em httpmsdn

microsoftcomen-ussyncbb887608aspx acedido em Junho de2008

[Nao08] Erica Naone Offline web applications Abril 2008 Disponıvelem httpwwwtechnologyreviewcomread_articleaspxch=

specialsectionsampsc=emerging08ampid=20245 acedido emAbril de 2008

[NJN00] Jason Nieh Yang S Jae and Naomi Novik A comparison of thin-clientcomputing architectures 2000 Disponıvel em httpwwwnclcs

columbiaedupublicationscucs-022-00pdf acedido em Maio de2008

[OrsquoR06] Tim OrsquoReilly Web 20 compact definition Trying again Dezembro2006 Disponıvel em httpradaroreillycomarchives200612

web-20-compact-definition-tryihtml acedido em Marco de 2008

[OrsquoR09] Tim OrsquoReilly What is Web 20 Design patterns and business modelsfor the Next Generation of Software 20053009 Disponıvel emhttpwwworeillynetcompubaoreillytimnews200509

30what-is-web-20html acedido em Marco de 2008

[Rus06] Alex Russel Comet Low latency data for the browser March Marco2006 Disponıvel em httpalexdojotoolkitorgp=545 acedidoem Marco de 2008

58

REFERENCIAS

[Sad97] Darleen Sadoski Clientserver software architecturesndashan overviewAgosto 1997 Disponıvel em httpwwwseicmuedustr

descriptionsclientserver_bodyhtml acedido em Junho de2008

[Sch96] George Schussel Clientserver past present and future 1996

[Smi07] Kevin C Smith Css filters - will the browser apply the rule July 2007Disponıvel em httpcentriclecomrefcssfilters acedido emMarco de 2008

[vK08] Anne van Kesteren The XMLHttpRequest Object W3C Work-ing Draft 15 Abril 2008 Disponıvel em httpwwww3orgTR

XMLHttpRequest acedido em Abril de 2008

[Wil06] Greg Wilkins Why ajax comet July Julho 2006 Disponıvel emhttpwwwwebtidecomdownloadswhitePaperWhyAjaxhtml ace-dido em Abril de 2008

59

REFERENCIAS

60

Anexo A

Screenshots

Algumas imagens de aplicacoes que utilizam funcionalidades offline ilustrativasda tecnologia abordada neste documento

Figura A1 Dialogo apresentado ao utilizador na primeira activacao das funcionalidadesoffline no Google Docs amp Spreadsheets

61

Screenshots

Figura A2 Na activacao das funcionalidades offline e tambem oferecida a possibilidadeda criacao de alguns atalhos por exemplo no ambiente de trabalho

Figura A3 O Google Docs mantem a todo o momento a possibilidade de alteracao destasdefinicoes ou da anulacao dos servicos offline para um dado computador

62

Screenshots

Figura A4 Apos a instalacao do Gears qualquer visita ao Remember The Milk despoletauma sincronizacao que ocorre automaticamente e sem necessidade de intervencao por partedo utilizador

Figura A5 Apos completar a sincronizacao de dados mesmo que a ligacao a Internetseja perdida o Remember the Milk continua disponıvel no browser (com excepcao dasfuncionalidades que pela sua natureza exigem uma ligacao como por exemplo partilhade tarefas e envio de convites)

63

Page 9: O ine Web Applications

vi

Conteudo

1 Introducao 111 Enquadramento 112 Motivacao 213 Ambito 314 Objectivos 315 Estrutura do documento 3

2 Enquadramento do Projecto 521 Evolucao das arquitecturas de software 5

211 Thin-clients 5212 Fat-clients 6213 Arquitecturas cliente-servidor 7

22 Evolucao na Internet 8221 Paginas web estaticas 9222 Paginas web interactivas e paginas web dinamicas 9223 Web 20 e Ajax 11

23 Offline Web Applications 1324 Comparacao 13

3 Estado da arte 1731 Gears 17

311 Arquitectura 17312 Goggle Gears em dispositivos moveis 20

32 Adobe AIR 20321 Seguranca 22322 Assinatura do codigo 22

33 Mozilla Prism 23331 XML User Interface Language 23332 Prism 25

34 HTML 5 2535 Web applications que usam funcionalidades offline 26

351 Google Reader e Google Docs 26352 Remember the Milk 27353 MySpace e WordPresscom 27

36 Escolha da tecnologia 28

vii

CONTEUDO

4 Desenvolvimento 3341 Como ficar offline 33

411 Funcionalidades disponıveis em modo offline 3442 Modos de execucao 35

421 Modo ldquoutilizador deciderdquo 36422 Modo aplicacao decide 36423 Modo ldquoaplicacao assume o estado offlinerdquo 37

43 Sincronizacao de dados 38431 Quando sincronizar 39

44 WOW 4045 Visao geral sobre a arquitectura do WOW 4146 WOW Offline 42

461 Modo ldquoaplicacao deciderdquo com deteccao automatica da ligacao 43462 Implementacao do modo ldquoutilizador deciderdquo 45463 Especificacao do modo ldquoaplicacao assume o estado offlinerdquo 48

5 Resultados e Futuros Desenvolvimentos 5151 Resultados Obtidos 5152 Trabalho Futuro 52

6 Conclusoes 5561 Conclusoes 55

Referencias 59

A Screenshots 61

viii

Lista de Figuras

21 Arquitectura de um sistema thin-client em duas camadas (a esquerda)e em tres camadas (a direita) Note-se a inclusao do servidor (main-frame) na definicao das camadas desta arquitectura devido a fortedependencia cliente-servidor 9

22 Arquitectura de um fat-client em duas camadas (a esquerda) e emtres camadas (a direita) 10

23 Comparacao do modelo de web aplications sıncrono paginas estaticase interactivas abordados nas seccoes 221 e 222 com o modelo deweb applications Ajax (assıncrono) abordado na seccao 223 Figuraadaptada de http www adaptivepath com 15

31 Esquema UML do processo efectuado pelos recursos do Gears do tipoManagedResourceStore para a actualizacao dos conteudos definidosno ficheiro manifesto 29

41 Exemplo de uma arquitectura de uma web application sem uma ca-mada de abstraccao de dados Figura adaptada de http gears

google com 33

42 Exemplo de uma arquitectura de uma web application com uma ca-mada de abstraccao de dados Figura adaptada de http gears

google com 34

43 Exemplo de uma arquitectura de uma web application com uma ca-mada de abstraccao de dados e um data switch Figura adaptada dehttp gears google com 35

44 Esquema grafico ilustrando uma OWA executando no browser uti-lizando um modo de execucao do tipo ldquoaplicacao deciderdquo com de-teccao automatica do estado da ligacao via pedidos Ajax assıncronosa cada cinco segundos 37

45 Detalhe de um conjunto possıvel de estados e respectivas transicoespara uma dada ordem de trabalho no WOW desde a sua submissaono sistema ate a sua conclusao em fecho ou cancelamento Esta figurarepresenta apenas um exemplo ja que o mapa de estados para umaordem de trabalho e dinamico e pode ser alterado por um admin-istrador Figura retirada de uma brochura promocional do WOWCritical Software SA 41

ix

LISTA DE FIGURAS

46 A pagina inicial do WOW apresenta um resumo das ultimas ordensde trabalho enviadas e recebidas Na imagem pode-se observar atransicao do estado online para offline 44

47 Ilustracao do funcionamento do Gears numa web application que uti-liza um motor Ajax Os pedidos HTTP ou HTTPS podem ser inter-ceptados e tratados localmente ou podem ser feitos a uma maquinaremota consoante se verificarem ou nao as condicoes expressas noponto 311 E representado um acesso a uma base de dados local(fornecida pelo Gears) mas a sua utilizacao e opcional 45

48 Neste exemplo do modo ldquoaplicacao deciderdquo o teste da ligacao e feitoe feito a cada cinco segundos O resultado deste teste nao reflectesempre o estado real da aplicacao podendo levar a aplicacao a tercomportamentos indesejaveis Na figura assinala-se um perıodo detempo no qual a representacao interna do estado da ligacao nao cor-responde a realidade 46

49 Pagina de visualizacao do detalhe de uma ordem de trabalho 47410 Esquema UML que expressa os casos de uso do WOW Offline no

modo ldquoutilizador deciderdquo 48411 Esquema UML que expressa os casos de uso do WOW Offline no

modo ldquoutilizador deciderdquo 49412 Esquema UML que expressa o acto de recolha de dados em modo

online e offline recorrendo ao servidor (modo online) e ao sistemade armazenamento de dados local fornecido pelo Gears (modo offline) 50

A1 Dialogo apresentado ao utilizador na primeira activacao das funcional-idades offline no Google Docs amp Spreadsheets 61

A2 Na activacao das funcionalidades offline e tambem oferecida a possi-bilidade da criacao de alguns atalhos por exemplo no ambiente detrabalho 62

A3 O Google Docs mantem a todo o momento a possibilidade de alteracaodestas definicoes ou da anulacao dos servicos offline para um dadocomputador 62

A4 Apos a instalacao do Gears qualquer visita ao Remember The Milkdespoleta uma sincronizacao que ocorre automaticamente e sem ne-cessidade de intervencao por parte do utilizador 63

A5 Apos completar a sincronizacao de dados mesmo que a ligacao aInternet seja perdida o Remember the Milk continua disponıvel nobrowser (com excepcao das funcionalidades que pela sua naturezaexigem uma ligacao como por exemplo partilha de tarefas e enviode convites) 63

x

Lista de Tabelas

21 Comparacao entre thin-clients e fat-clients 7

31 Comparacao das funcionalidades oferecidas pelo Adobe AIR para asplataformas web e desktop 30

32 Resumo da utilizacao de tecnologias OWA em algumas web applica-tions consideradas na analise do estado da arte 31

xi

LISTA DE TABELAS

xii

Glossario

fat-client Cliente que nao depende totalmente de umservidor central para as suas actividadesde processamento e possui frequentementedispositivos de armazenamento de dados

6ndash8

thin-client Cliente que depende de um servidor centralpara as suas actividades de processamento

5ndash8

web application Sistema web (servidor rede HTTPbrowser) onde accoes do utilizador(navegacao e introducao de informacao)afectam o estado logico da aplicacao

i iii1ndash311ndash1517ndash1921ndash232728 3336ndash3842 5556

API Application Programming Interface 10 1718 2326 28

ASP Linguagem interpretada pelo servidorque permite a criacao de paginas webdinamicas Desenvolvida pela Microsoft

11

BSD Berkeley Software Distribution 28

CSS Cascading Style Sheets 12 2021 2324 46

DHTML Dynamic HyperText Transfer Protocol 24DOM Document Object Model 10 12

20 2324

DTD Document Type Definition 24

xiii

Glossario

ECMAScript Padrao de linguagem de programacaodefinido pela Ecma International que orig-inou o JavaScript e o JScript

24

Flash Conteudo interactivo de um ficheiro emformato SWF E desenvolvido pela Adobee visualizado atraves do Adobe FlashPlayer

21

Flex Framework baseada em XML e Action-Script desenvolvida pela Adobe para a pro-gramacao de Rich Internet Applications(RIA)

21

GPL GNU General Public License 23

HTML HyperText Markup Language 1 10ndash12 2124ndash2649

HTTP HyperText Transfer Protocol 2 26

JMS E uma API em Java que permite a troca demensagens entre componentes de software

42

JSON JavaScript Object Notation permite atroca de dados codificados num formatode texto de simples leitura

12 1828 34

LGPL GNU Lesser General Public License 23

Mozilla Prism Browser simplificado e ldquointerpretadorrdquo deeXtensible User Interface Language (XUL)(tambem designado por XULRunner) queacolhe web applications sem a interfacegrafica habitual de um browser

25

MPL Mozilla Public License 23

OCA Occasionally Connected Application 39OWA Offline Web Application i iii

2ndash515 1725 2628 3133 3651 5255 56

PDF Portable Document Format 21

xiv

Glossario

PHP Linguagem interpretada pelo servidorque permite a criacao de paginas webdinamicas mas que pode tambem ser in-vocada a partir da linha de comandos

11

pagina web estatica Pagina web que devolve sempre a mesmaresposta a todos os pedidos para todos osutilizadores e em qualquer contexto

5 9

RIA Rich Internet Applications web appli-cations que apresentam funcionalidadessemelhantes as desktop applications masque mantem a informacao no lado do servi-dor

5 1520 28

RSS Really Simple Syndication 27

SLA Service Level Agreement 40SQLite Segundo a definicao oficial SQLite is a

software library that implements a self-contained serverless zero-configurationtransactional SQL database engine

17

SSB Site Specific Browser 25SSL Secure Sockets Layer 22SWF ShockWave Flash 21

URL Uniform Resource Locator 18

VPN Virtual Private Network 38

WOW Work Orders Web Plataforma de gestaode ordens de trabalho e do seu fluxo de-senvolvida pela Critical Software SA

i iii28 3340ndash434551ndash5356

WWW World Wide Web 11 1214

XBL eXtensible Binding Language 24XHTML eXtensible HyperText Markup Language 12XML eXtensible Markup Language 11 12

23 2428

XSLT eXtensible Stylesheet Language Transfor-mation

12

XUL eXtensible User Interface Language xiv23ndash25

xv

Glossario

xvi

Capıtulo 1

Introducao

Neste capıtulo enquadra-se o tema do projecto introduzindo alguns dos conceitos

nos quais se baseia Apresentam-se as motivacoes ambito objectivos e a estrutura

deste documento

11 Enquadramento

A Internet foi originalmente concebida para ser um espaco de partilha de in-

formacao onde pessoas (atraves de maquinas) pudessem comunicar Na sua origem

as paginas eram estaticas constituıdas por texto formatado em HyperText Markup

Language (HTML) e ligadas entre si [BL96] Hoje encontramos conteudos cada vez

mais complexos e dinamicos incluindo som vıdeo ou streams multimedia [Loo06] e

em 2005 foi introduzido por [OrsquoR09] o termo Web 20

De acordo com [Greon] um website pode pertencer a uma ou varias das seguintes

categorias

bull Documento ndash um website essencialmente estatico onde alteracoes a uma

parte do conteudo nao tem implicacoes no seu comportamento

bull Base de dados ndash um directorio de informacao organizada em categorias

bull Aplicacao ndash um website dinamico que utiliza uma linguagem executada ou

interpretada do lado do servidor e que processa as accoes ou informacao in-

troduzida pelo utilizador para fornecer um servico ou nova informacao

A ultima destas categorias constitui aquilo que e normalmente designado por

web application O conceito utilizado ao longo deste documento e o mesmo que

o introduzido por Jim Coallen em [Con99] que define web application como um

1

Introducao

sistema web (servidor rede HyperText Transfer Protocol (HTTP) browser) onde

accoes do utilizador (navegacao e introducao de informacao) afectam o estado logico

da aplicacao A sua definicao tenta estabelecer que uma web application e um

sistema de software com estado de negocio1 e que a sua interface de interaccao com

o utilizador e distribuıdo atraves de um sistema web

12 Motivacao

A quantidade de informacao que e produzida e armazenada com recurso a es-

tas web applications disponıveis online tais como e-mail blogues ou mesmo docu-

mentacao tornam por vezes a disponibilidade de ligacao uma condicao necessaria

a produtividade e como consequencia desta barreira muitos potenciais utilizadores

opoem-se a adopcao de produtos web em detrimento das tradicionais desktop appli-

cations

Assegurar o acesso a uma ligacao de Internet e hoje muito mais facil A Internet

movel e ja uma realidade e encontra-se amplamente divulgada mas continuam a

existir diversas situacoes nas quais os utilizadores estao privados de uma ligacao

a Internet tais como uma viagem de metro ou de aviao ou quando se encontram

deslocados do seu paıs de origem e nao possuem nenhum plano de subscricao

Uma OWA consiste numa web application que para alem de manter todas as

caracterısticas anteriores se mantem disponıvel mesmo na ausencia de uma ligacao

a Internet e surge como uma tentativa de estreitar as barreiras existentes entre a

web e o desktop Isto significa que devera existir um mecanismo capaz de assegurar

a manutencao do estado logico da aplicacao quando a ligacao com o servidor e

quebrada permitindo ao utilizador continuar a utilizar a aplicacao e que sera capaz

de informar o servidor do estado em que a aplicacao se encontra quando a ligacao for

reposta A principal vantagem que advem desta possibilidade e evidente eliminar

a necessidade da existencia de uma ligacao a Internet para que a aplicacao possa ser

utilizada

Por outro lado a vontade de integracao de funcionalidades tıpicas das desktop

applications nas web applications foi um dos principais factores que impulsionou o

desenvolvimento deste conceito uma vez que obrigou a uma reflexao ldquopara alem

do browserrdquo e a uma adaptacao das arquitecturas existentes que permitisse ou o

acesso a funcionalidades disponibilizadas pelo sistema operativo ou pelo menos a

funcionalidades semelhantes Pretende-se com esta aproximacao tornar possıveis

interaccoes entre o desktop e o browser tais como arrastar um ficheiro para um

formulario web de upload de conteudos melhor suporte para o historico do clipboard

ou ainda o acesso ao sistema de ficheiros local Atingir estes objectivos reflecte-se

1NT business state

2

Introducao

num novo paradigma que reune as vantagens das web applications tais como os

updates instantaneos ou o facto de nao ser necessaria nenhuma instalacao e das

desktop applications como por exemplo persistencia no armazenamento de dados

acesso a funcionalidades do sistema operativo ou integracao e interaccao com outras

aplicacoes sejam elas web applications ou desktop applications

13 Ambito

Este projecto foi realizado na Critical Software SA no ambito do Mestrado

Integrado em Engenharia Informatica e Computacao (MIEIC) da Faculdade de En-

genharia da Universidade do Porto (FEUP) entre os meses de Fevereiro e Julho de

2008

14 Objectivos

Sao objectivos deste projecto

1 Estudar e documentar o tema das OWAs acompanhando os ultimos desenvolvi-

mentos nesta materia

2 Analisar o estado da arte fazendo uma analise crıtica e objectiva sobre as

diversas metodologias existentes

3 Implementar uma prova de conceito que permita a execucao offline de uma

web application documentando todo o processo

4 Estudar a possibilidade de permitir interaccao com a aplicacao (insercoes e

alteracoes aos dados) em modo offline

Em resumo o objectivo deste projecto foi estudar documentar e implementar

uma prova de conceito relacionada com o tema Offline Web Applications (OWA)

Este tema embora nao seja totalmente novo ganhou destaque ao longo do ano de

2007 com o surgimento de diversas ferramentas que se destinam a aproximar web

applications das desktop applications

15 Estrutura do documento

Este documento esta organizado em diferentes seccoes apresentando o projecto

numa sequencia logica organizada da seguinte forma

No capıtulo 1 faz-se uma breve apresentacao do conceito OWAs e do contexto em

que surge Apresenta-se tambem a estrutura do documento e definem-se os

termos e acronimos utilizados

3

Introducao

No capıtulo 2 faz-se uma descricao da evolucao das tecnologias que antecedem as

OWAs e das vantagens e desvantagens de cada uma como forma de enquadra-

mento

No capıtulo 3 analisa-se o estado da arte nesta materia Introduzem-se diversas

tecnologias directamente relacionadas com o tema deste projecto exemplos de

aplicacoes que as usam e as razoes que fundamentam as escolhas de tecnologias

efectuadas

O capıtulo 4 contem o desenvolvimento do projecto Analisa-se a plataforma

WOW de gestao integrada de ordens de trabalho a tecnologia escolhida e

a forma como foi utilizada para implementar a capacidade de execucao offline

O capıtulo 5 descreve os resultado obtidos comparando-os com as expectativas

iniciais do projecto e apresenta desenvolvimentos futuros e possibilidades de

continuacaoaplicacao do conhecimento adquirido

No capıtulo 6 apresentam-se as conclusoes

4

Capıtulo 2

Enquadramento do Projecto

Neste capıtulo apresenta-se um breve resumo da evolucao das arquitecturas de

software cliente-servidor e a forma como estas se comparam a evolucao da Inter-

net procurando estabelecer uma analogia entre o percurso de ambas as tecnolo-

gias Compara-se o comportamento e arquitectura dos thin-clients as paginas web

estaticas a evolucao dos fat-clients as paginas interactivas Web 20 e Ajax e

defende-se que as OWA constituem um proximo passo logico e evolutivo aproxi-

mando a web do desktop Referem-se ainda os principais factores que justificam a

importancia das OWAs e a estreita relacao que tem com as Rich Internet Application

(RIA)s

21 Evolucao das arquitecturas de software

Os termos thin-client e fat-client sao utilizados quer para descrever arquitecturas

logicas (de software) quer para descrever arquitecturas fısicas (de hardware) Neste

capıtulo excepto quando seja dada indicacao em contrario estes termos referem-se

sempre a uma arquitectura logica

Adicionalmente quando se trata de arquitecturas cliente-servidor pode-se estu-

dar a arquitectura desenvolvida do sistema como um todo da arquitectura do servi-

dor ou da arquitectura do cliente Para evitar equıvocos em especial na seccao 213

especifica-se em cada caso qual o sistema estudado

211 Thin-clients

Um thin-client e um computador cliente ou software cliente que no contexto

de uma arquitectura cliente-servidor depende de um servidor central para as suas

5

Enquadramento do Projecto

actividades de processamento e proporciona um canal de entrada e saıda de in-

formacao entre o utilizador e o servidor remoto Este termo quando aplicado a

hardware refere-se habitualmente a um computador que se destina a ser utilizado

como cliente de rede sem armazenamento local e com capacidade de processamento

reduzida [Gro02b] mas o conceito que aqui se analisa refere-se a uma arquitectura

de software que remonta ao inıcio das aplicacoes cliente-servidor

No inıcio da historia da computacao terminais ligavam-se directamente a main-

frames responsaveis por todo o processamento Nesta arquitectura era necessario

desenvolver duas aplicacoes distintas uma aplicacao central no servidor (main-

frame) responsavel pela gestao de toda a informacao e por todas as operacoes de

comunicacao e uma aplicacao de visualizacao instalada no cliente (terminal) O

papel destes terminais era apenas disponibilizar ao utilizador um meio de comu-

nicacao (entrada e saıda) e apresentacao dos resultados do servidor Nao tinham

um papel activo no calculo nem na logica de negocio e frequentemente nao tinham

tambem nenhum mecanismo de armazenamento de dados

Como vantagens esta arquitectura apresenta uma reduzida necessidade de con-

figuracao e manutencao do lado do cliente Uma vez que o centro do processamento

e manipulacao de dados ocorre no servidor existe tambem uma centralizacao da

informacao [NJN00] que introduz um ponto crıtico de falha1 Actualizacoes e novas

funcionalidades sao faceis de distribuir uma vez que requerem apenas alteracoes no

servidor [Gro02a]

212 Fat-clients

Contrastando com os thin-clients nesta arquitectura os clientes implementam

ja uma parte da logica de negocio e sao responsaveis pelo processamento de dados

Estes fat-clients vieram responder a necessidade crescente de aplicacoes com um

nıvel de interactividade e capacidade de configuracao maior que as oferecidas pela

arquitectura thin-client descrita na seccao 211 Apesar de manterem a sua de-

pendencia do servidor podem tambem ser executados sem uma conexao activa uma

vez que dispoe de armazenamento de dados local o que lhes confere a capacidade

de persistencia de dados e do estado de execucao entre cada sessao

Foi disponibilizando este controlo sobre o estado da aplicacao bem como acesso

a recursos locais (por exemplo sistema de ficheiros e perifericos) que surgiram as

primeiras verdadeiras desktop applications No entanto cada cliente tinha que ser

separadamente instalado no computador pessoal de cada utilizador que pretendesse

utilizar ou interagir com a aplicacao e uma actualizacao ao servidor implicava in-

variavelmente uma actualizacao manual tambem no cliente Uma vez que nem todos

1NT single point of failure

6

Enquadramento do Projecto

Thin-clients Fat-clientsNao toma parte no processamento dedados nem possui acesso ao sistema deficheiros

Participa activamente no processa-mento de dados recorrendo ao sis-tema de armazenamento local para ar-mazenamento de dados

Nao mantem registo do estado logicoda aplicacao entre duas sessoes de uti-lizacao

O acesso ao armazenamento localpermite-lhe manter registo do estadologico da aplicacao entre duas sessoes

O thin-client nao necessita de qualquerinstalacao estando ldquopronto a utilizarrdquo

E geralmente necessario instalar aaplicacao para poder interagir com oservidor

Qualquer update no servidor reflecte-seimediatamente por todos os clientes

Embora a aplicacao cliente possa aler-tar para existencia de novas versoes asactualizacoes tem que ser manualmenteinstalados pelo cliente

O software do cliente destina-se apenasa apresentacao de dados e comunicacaocom o servidor sendo portanto de sim-ples implementacao

Como o software do cliente toma parteactiva no processamento de dadosa sua implementacao requer cuidadosadicionais

Grande mobilidade uma vez que todaa informacao e mantida no servidor

Parte da informacao podera estar ape-nas do lado cliente pelo que existemalgumas restricoes a sua mobilidade

Tabela 21 Comparacao entre thin-clients e fat-clients

os utilizadores actualizam regularmente as suas aplicacoes o servidor tem que estar

preparado para lidar com versoes antigas2 ou descontinuar os seus servicos a uma

parte da sua comunidade de utilizadores ate que estes actualizem os seus sistemas

Como os utilizadores passam a utilizar os seus recursos locais para armazenamento

de dados as alteracoes que nao sejam sincronizadas com o servidor estao apenas

disponıveis nos seus computadores pessoais o que introduz uma restricao a mobili-

dade

Pode-se afirmar que as vantagens dos thin-clients sao as desvantagens dos fat-

clients e que as vantagens dos fat-clients sao as vantagens dos thin-clients tal como

se ilustra na Tabela 21

213 Arquitecturas cliente-servidor

Introduzidos os termos thin-client e fat-client interessa reafirmar que ambos

podem ser vistos como arquitecturas cliente-servidor Um cliente define-se como

um solicitador de servicos e um servidor como um prestador de servicos tal como

definido por [Sch96] e [Sad97]

2NT backward compatibility

7

Enquadramento do Projecto

As arquitecturas cliente-servidor sao categorizadas pela modularizacao com que

sao desenhadas sendo consideradas as seguintes camadas

1 Interface grafica (front-end) atraves da qual os utilizadores interagem com

a aplicacao Quando este modulo e implementado separadamente dos outros

dois constitui uma aplicacao thin-client por si so uma vez que nao implementa

regras de negocio (embora possa definir validacoes de formularios de insercao de

dados por exemplo) A informacao introduzida pelo utilizador e enviada para

o servidor que processa o seu pedido e retorna uma resposta Este processo

repete-se ate que o utilizador atinja o seu objectivo ou se desligue do sistema

2 A logica de negocio tambem designada por camada intermedia que imple-

menta as regras de aceitacao e validacao de todos os dados introduzidos pelo

utilizador E tambem a plataforma de comunicacao que une a camada superior

de visualizacao com a camada de acesso a dados

3 A camada de dados inclui quer o sistema de persistencia de dados onde sao

armazenados os dados relevantes como tambem os mecanismos necessarios

para a sua pesquisa seleccao e alteracao

Os thin-clients quando observados no seu conjunto de cliente e servidor podem

ser vistos quer como sistemas de duas camadas quer como sistemas de tres camadas

dependendo apenas da forma como o servidor for implementado No caso de na

implementacao do servidor nao se distinguir a camada de acesso a dados da camada

da logica de negocio sao designados por sistemas de duas camadas Caso seja feita

esta distincao sao designados por sistemas de tres camadas Ambos os casos sao

ilustrados na Figura 21

Historicamente os fat-clients eram implementados numa arquitectura em duas

camadas Possuıam apenas um modulo de visualizacao de dados designado por

camada de interface e um modulo que implementava toda a logica de negocio e

regras de acesso a base de dados No entanto com a introducao de ligacoes mais

rapidas e de computadores pessoais com maior capacidade de processamento e so-

bretudo devido a complexidade crescente das aplicacoes a logica de negocio e a

camada de acesso a dados tornaram-se independentes Este modelo e designado por

arquitectura em tres camadas e e ilustrado na Figura 22

22 Evolucao na Internet

Ao analisar a evolucao das arquitecturas das aplicacoes desenvolvidas para a

Internet podemos encontrar um paralelismo com a historia da arquitectura de soft-

ware

8

Enquadramento do Projecto

Figura 21 Arquitectura de um sistema thin-client em duas camadas (a esquerda) e emtres camadas (a direita) Note-se a inclusao do servidor (mainframe) na definicao dascamadas desta arquitectura devido a forte dependencia cliente-servidor

221 Paginas web estaticas

Uma pagina web estatica devolve sempre a mesma resposta a todos os pedidos

para todos os utilizadores e em qualquer contexto utilizando o hipertexto como

forma de ligacao entre diversas paginas estaticas

A informacao e armazenada num servidor e o papel do cliente e apenas a apre-

sentacao da informacao Esta forma de disponibilizacao de informacao pode assim

ser comparada com os thin-clients descritos na seccao 211 o utilizador acede a

um website estatico para visualizar informacao sem que o cliente tome parte no

processamento A unica diferenca e que no caso da web estatica a informacao ap-

resentada e sempre a mesma enquanto que nos thin-clients era frequente existir a

possibilidade de insercao de dados no cliente e apos o seu processamento servidor

nova informacao poderia ser apresentada O hipertexto e utilizado para ligar as

paginas entre si numa rede de conteudos relacionados e a navegacao sıncrona era

feita atraves de cliques do rato a cada clique uma nova pagina era apresentada

Este modelo sıncrono e ilustrado na Figura 23

222 Paginas web interactivas e paginas web dinamicas

O JavaScript e uma linguagem interpretada de scripting que tem os browsers

como principal ambiente de acolhimento Os browsers utilizam uma Application

9

Enquadramento do Projecto

Figura 22 Arquitectura de um fat-client em duas camadas (a esquerda) e em tres camadas(a direita)

Programming Interface (API) publica para criar ldquoobjectosrdquo responsaveis por reflectir

e disponibilizar o Document Object Model (DOM) para o motor de JavaScript

A utilizacao mais frequente desta linguagem e a escrita de funcoes que sao em-

bebidas ou incluıdas em paginas web e que interagem com o DOM Uma vez que o

JavaScript e executado localmente (na maquina do cliente e nao no servidor) e capaz

de responder rapidamente a accoes do utilizador tornando a execucao de aplicacoes

no browser mais fluıdas o JavaScript pode tambem detectar accoes do utilizador

que o HTML nao pode tal como o pressionar de uma tecla

Em Dezembro de 1995 a Netscape Communications adicionou suporte para o

JavaScript no browser Netscape Navigator3 e em Agosto de 1996 o browser Internet

Explorer4 da Microsoft passou a tambem a suportar uma versao semelhante desta

linguagem (hoje todos os principais browsers suportam esta tecnologia)

Esta inovacao permitiu tornar os websites mais interactivos mas a sua utilizacao

esteve confinada apenas a este proposito durante um longo perıodo As paginas

passaram a responder activamente a accoes do utilizador (sendo uma das utilizacoes

3Netscape Communications ndash httpbrowsernetscapecom4Microsoft Internet Explorer ndash httpwwwmicrosoftcomwindowsproductswinfamilyie

10

Enquadramento do Projecto

mais vulgares a validacao de formularios) mas continuaram essencialmente estaticas

O JavaScript ainda nao era nesta altura utilizado para processar dados

Tambem nesta altura (1995ndash96) surgiram linguagens server-side como o PHP

Hypertext Preprocessor (PHP) e Active Server Pages (ASP) e o servidor passou a ter

um processamento de dados introduzidos pelo utilizador mais activo Generalizaram-

se as paginas dinamicas capazes de responder a insercao de dados ou outros pedidos

determinados por accoes do utilizador As paginas tornaram-se aplicacoes web ap-

plications

Uma definicao tradicional de web application e um conjunto de paginas web

logicamente agrupadas e geridas por uma unica entidade que tem como pontos de

entrada formularios de insercao de dados (web forms) Uma web application nao e

mais do que uma aplicacao que e acedida atraves de um browser Tem geralmente

uma arquitectura logica em tres (interface logica de negocio e camada de dados)

camadas e estao armazenadas num servidor

Ha dois tipos de web applications

bull Orientadas a apresentacao Sao web applications que geram paginas web in-

teractivas constituıdas por varios tipos de linguagens de anotacao (por exem-

plo HTML eXtensible Markup Language (XML)) e que apresentam conteudo

dinamico como resposta a pedidos efectuados pelo utilizador

bull Orientadas aos servicos Uma web application orientada aos servicos imple-

menta o ponto de acesso para um ou mais de um web service Sao geralmente

clientes de service oriented web applications

Uma vantagem significativa de implementar uma web application de forma a

suportar as funcionalidades padrao dos browsers e que estas terao o mesmo com-

portamento independentemente da plataforma e do browser a partir do qual serao

acedidas No entanto diferentes implementacoes de browsers devido a diferentes

interpretacoes dos padroes definidos tornam por vezes esta tarefa um pouco mais

complicada existindo inclusivamente na web guioes de compatibilidade para os difer-

entes browsers como [Smi07]

223 Web 20 e Ajax

O termo web 20 descreve uma tendencia de utilizacao e de design observada

na World Wide Web (WWW) com o objectivo de melhorar a criatividade partilha

de informacao e principalmente a colaboracao entre utilizadores Estes conceitos

levaram ao desenvolvimento e evolucao de comunidades online tais como redes so-

ciais wikis e blogues

11

Enquadramento do Projecto

O termo tornou-se mais conhecido apos a primeira conferencia OrsquoReilly Media

Web 20 em 2004 e apesar de sugerir uma nova versao da WWW nao se refere a

qualquer evolucao tecnologica mas apenas a alteracoes a forma como os utilizadores

se servem da web De acordo com Tim OrsquoReilly [OrsquoR06] ldquoWeb 20 e uma revolucao

na industria do software causada pela adopcao da web como uma plataforma e pela

tentativa de entendimento das regras para o sucesso nesta nova plataformardquo

O desenvolvimento da Web 20 serve-se muitas vezes de um outro conceito Ajax

O conceito que hoje conhecemos como Ajax muitas vezes incorrectamente de-

scrito como uma tecnologia foi originalmente criado para permitir o desenvolvimento

de web applications que se assemelhassem ainda mais a aplicacoes de desktop Este

conceito foi melhor descrito por [Gar05] como um conjunto de varias tecnologias

que podem ser utilizadas para melhorar a experiencia do utilizador de uma dada

web application introduzindo a capacidade assıncrona de envio de pedidos ou da

recepcao assıncrona de respostas As tecnologias mais frequentemente envolvidas

sao

bull eXtensible HyperText Markup Language (XHTML) e Cascading Style Sheets

(CSS) padrao para a apresentacao

bull interaccao dinamica atraves do DOM

bull troca e manipulacao de dados utilizando XML e eXtensible Stylesheet Lan-

guage Transformation (XSLT) ou JavaScript Object Notation (JSON)

bull pedidos assıncronos utilizando XMLHttpRequest [vK08]

bull JavaScript utilizado para integrar todas estas tecnologias

E importante frisar que o Ajax nao e um produto nem uma tecnologia E um

termo que descreve a utilizacao de um conjunto de tecnologias para o desenvolvi-

mento de web applications com um elevado grau de interactividade Comparativa-

mente as web applications tradicionais o Ajax introduz uma camada de visualizacao

diferente em tres importantes pontos

1 Do lado do cliente existe um motor que serve de intermediario entre a interface

da aplicacao e o servidor

2 A actividade do utilizador despoleta chamadas JavaScript em vez de um pedido

de pagina directamente ao servidor

3 Informacao codificada em XML em vez de paginas HTML e trocada entre o

servidor e o cliente

12

Enquadramento do Projecto

Isto significa que as paginas que utilizam Ajax contem um motor do lado do

cliente composto por um conjunto de funcoes JavaScript responsavel pela comu-

nicacao com o servidor e por actualizar a interface com o resultado dessa mesma

comunicacao

Na Figura 23 ilustra-se a natureza assıncrona do Ajax quando comparada com

as web applications tradicionais Como se pode observar adicionando um mecan-

ismo Ajax a uma web application eliminam-se diversos tempos de espera associados

a comunicacoes com o servidor uma vez que a interface nao fica ldquobloqueadardquo a es-

pera da resposta Obtem-se assim aplicacoes com um comportamento mais fluido

eliminando tempos de espera entre cada ldquocliquerdquo e melhorando a experiencia do

utilizador

23 Offline Web Applications

A informacao grafica (bem como folhas de estilo e scripts) tais como as ima-

gens que constituem o visual de uma web application e ja tratada de forma especial

pelos cada vez mais avancados sistemas de cache (armazenamento temporario) dos

browsers Mas estes nao sao ainda capazes de guardar conteudo criado pelo uti-

lizador nem de apresentar informacao independentemente do estado da ligacao

Numa altura onde se fala de servicos de Internet wireless municipalizados [Kha]

comunicacoes 3G e ligacoes de banda larga a alta velocidade a ligacao a rede global

continua a nao estar permanentemente disponıvel para os utilizadores Na WWW

encontra-se uma importante parte da informacao e das aplicacoes utilizadas para

criar e editar conteudos Por vezes informacao vital para a produtividade pode

desaparecer subitamente do mapa de acesso de um utilizador quando este entra no

metro num aviao ou mesmo quando se desloca para uma cidade ou paıs diferente

do habitual onde nao subscreve um plano de acesso que lhe garanta a ligacao

Permitir o acesso offline a estes recursos assume assim a sua importancia porque

permitira estender o alcance da informacao a locais onde nunca esteve antes e per-

mitira tambem melhorar o desempenho das web applications colocando informacao

mais perto dos utilizadores reduzindo a transferencia de dados apenas ao essencial

24 Comparacao

Nas evolucoes descritas neste capıtulo 2 pode-se observar que existe um par-

alelismo entre a evolucao das arquitecturas tradicionais cliente-servidor e a evolucao

a que se assiste na web O comportamento e arquitectura dos thin-clients assemelha-

se ao das paginas estaticas no sentido em que o browser nao toma parte em qualquer

13

Enquadramento do Projecto

processamento e serve apenas como uma plataforma de interaccao com o servidor

tal como os clientes descritos na seccao 211

A sua proxima evolucao os fat-clients trouxeram parte da capacidade de pro-

cessamento para o lado do cliente Na web foi tambem esta a inovacao tecnologica

a que se assistiu com a evolucao das tecnologias que permitiram a criacao de ver-

dadeiras aplicacoes e com a introducao do Javascript no browser dando ao cliente

a capacidade de processamento de dados A necessidade da separacao do codigo

em camadas logicas advem da crescente complexidade das web applications Esta

pratica permite entre outras coisas melhorar o processo de desenvolvimento e a

capacidade de manutencao de uma aplicacao

Os fat-clients tem tambem a capacidade de armazenamento de dados o que

permite a persistencia de informacoes entre duas sessoes e que algumas operacoes

sejam executadas sem a necessidade de comunicacao com o servidor Este facto pode

tambem ser uma realidade nas web applications com a adopcao das tecnologias OWA

Neste momento assiste-se a uma utilizacao cada vez maior da web como uma

plataforma de desenvolvimento A capacidade de cooperacao na edicao de conteudos

e a mobilidade proporcionada por esta plataforma sao os principais factores que

alimentam esta mudanca e pela primeira vez as aplicacoes tradicionais tem com-

peticao vinda de web applications A prova do reconhecimento da web como plataforma

de desenvolvimento pode ser retirada da aposta de empresas como a Adobe e Mi-

crosoft que lancaram publicamente ferramentas web complementares a produtos

seus tradicionalmente associados ao desktop ndash Acrobatcom5 e Microsoft Office

Live6 Dotar estas web applications da capacidade de execucao offline significa

aproximar a web e o desktop reunindo ldquoo melhor de dois mundosrdquo

As vantagens da mobilidade possıvel atraves da web a cooperacao na criacao e

edicao de conteudos e a possibilidade de utilizar aplicacoes sempre actualizadas e

sem necessidade de instalacao sao algumas das principais vantagens que promovem

esta mudanca que devido as preocupacoes associadas a usabilidade e experiencia do

utilizador esta fortemente associada ao desenvolvimento de Rich Internet Applica-

tion (RIA)s

5Adobe Acrobatcom httpwwwacrobatcom6Microsoft ndash httpsmallbusinessofficelivecom

14

Enquadramento do Projecto

Figura 23 Comparacao do modelo de web aplications sıncrono paginas estaticas e in-teractivas abordados nas seccoes 221 e 222 com o modelo de web applications Ajax(assıncrono) abordado na seccao 223 Figura adaptada de http www adaptivepath

com

15

Enquadramento do Projecto

16

Capıtulo 3

Estado da arte

Apesar de o conceito das OWAs nao ser absolutamente novo as tecnologias que

o suportam sao recentes Neste capıtulo descrevem-se quatro tecnologias que foram

tidas como principais candidatas para o desenvolvimento deste projecto Descrevem-

se ainda alguns exemplos de web applications que disponibilizam actualmente fun-

cionalidades offline e o processo da escolha da tecnologia a utilizar neste projecto

31 Gears

O Gears1 e uma extensao as funcionalidades do browser introduzido pelo Google

que tem como principal objectivo tornar possıvel a visualizacao de paginas de Inter-

net mesmo sem uma conexao disponıvel Encontra-se disponıvel para as platafor-

mas Windows Macintosh e Linux e oferece uma API de Javascript que permite

a scripts aceder a um mecanismo de armazenamento local baseado numa base de

dados SQLite

311 Arquitectura

Esta ferramenta e constituıda por tres componentes principais

bull LocalServer mdash Intercepta pedidos de paginas web e serve-as localmente

bull Database mdash Uma base de dados relacional construıda sobre SQLite

bull WorkerPool mdash Permite executar operacoes de computacao de uma forma

assıncrona sem afectar a capacidade de resposta e fluidez de execucao da web

application Assemelham-se a processos

1Google Inc ndash Mais informacao em httpgearsgooglecom

17

Estado da arte

LocalServer

O modulo LocalServer e uma cache de Uniform Resource Locators (URLs)

controlada pela web application Quando nao existe uma ligacao a Internet e e

feito um pedido para um URL presente nesta cache o LocalServer intercepta-o e

responde ao pedido localmente a partir do disco rıgido do utilizador A aplicacao

pode utilizar dois tipos diferentes de armazenamento local de URLs

bull ResourceStore ndash serve para capturar URLs utilizando exclusivamente a API

de Javascript disponibilizada para o efeito Uma aplicacao podera criar e

utilizar diversos ResourceStores simultaneamente para capturar ficheiros de

dados que necessitam de ser enderecados por um URL tal como um ficheiro

PDF ou uma imagem

bull ManagedResourceStore ndash serve para capturar um conjunto de URLs que estao

relacionados e que sao declarado num ficheiro de manifesto (especificado em

JSON) e que sao automaticamente actualizados O ManagedResourceStore

permite que o conjunto de recursos necessarios para correr uma web application

seja capturado e mantido actualizado automaticamente

A principal diferenca entre estes dois tipos de armazenamento de URLs e a forma

como sao actualizados os seus conteudos Os conteudos de um ManagedResourceStore

sao actualizados sempre que a versao contida no ficheiro de manifesto for alterada

enquanto que os conteudos de um ResourceStore nunca sao actualizados automati-

camente mas apenas quando for explicitamente ordenado pela aplicacao

O LocalServer e capaz de interceptar e servir localmente pedidos de HTTP e

HTTPS sempre que se reunam as seguintes condicoes

1 O URL encontra-se armazenado num ResourceStore ou ManagedResourceStore

2 O sistema de armazenamento local encontra-se activo (enabled = true) Se

o sistema de armazenamento local tiver o atributo requiredCookie o pedido

devera conter um cookie que lhe corresponda

O LocalServer nao necessita de monitorizar o estado da ligacao para atender aos

pedidos Na verdade sempre que as condicoes previamente enunciadas se verificarem

o LocalServer interceptara os pedidos e independentemente do estado da ligacao

a Internet servi-los-a a partir do disco rıgido local Cabera a aplicacao definir qual

o modo em que pretende executar um pedido (online ou offline) definindo o valor

de verdade da propriedade enabled

18

Estado da arte

Database

O modulo Database permite guardar dados da web application assegurando a

sua persistencia Os dados sao guardados de forma relacional no disco rıgido do uti-

lizador2 de acordo com o modelo de seguranca estabelecido pelo Gears3 significando

que uma aplicacao nao pode aceder a conteudos fora do seu domınio

WorkerPool

Nos web browsers uma operacao pesada de computacao pode tornar a interface

lenta e tornar menos agradavel a experiencia do utilizador O modulo WorkerPool

permite correr operacoes em background sem bloquear a interface com o utilizador

Os scripts executados numa WorkerPool nao activam os mecanismos de seguranca

do browser que mostram a mensagem ldquoA script on this page may be busy or may

have stopped respondingrdquo

O WorkerPool comporta-se como um conjunto de processos em vez de threads

Os Workers nao partilham qualquer estado de execucao o que significa que uma

alteracao a uma variavel num Worker nao afecta em nada a execucao de outro

Worker Alem disso os Workers nao herdam automaticamente nenhum codigo dos

seus pais Cada Worker e membro de um WorkerPool e os Workers podem in-

teragir entre si enviando mensagens em formato de texto ou JSON No entanto ha

tambem algumas limitacoes os Workers nao tem acesso ao DOM e objectos como

window ou document nao se encontram acessıveis Isto e consequencia de os Workers

nao partilharem o estado de execucao Mas tem acesso a todas as funcoes built-in

do Javascript A maioria das funcionalidades do Gears pode tambem ser acedida

atraves de uma variavel global especial definida como googlegearsfactory Para

outras funcionalidades especıficas os Workers podem ldquopedirrdquo a pagina principal para

continuar a execucao atraves do envio de mensagens

Outras funcionalidades

bull HttpRequest ndash Este modulo implementa a especificacao W3C XmlHttpRe-

quest definida em [vK08] tornando-a disponıvel para os workers e para a

pagina principal

bull Timer ndash Este modulo implementa a especificacao de timers tal como descrito

por [Hic08] e torna-os disponıveis para os workers e para a pagina principal

2Consultar httpcodegooglecomapisgearsapi_databasehtmldirectories3Consultar httpcodegooglecomapisgearssecurityhtml

19

Estado da arte

bull Factory ndash Esta classe e utilizada para instanciar todos os outros objectos da

API do Gears atraves do seu metodo create Este metodo pode ser utilizado

com os seguintes parametros

ndash betadatabase

ndash betahttprequest

ndash betalocalserver

ndash betatimer

ndash betaworkerpool

312 Goggle Gears em dispositivos moveis

O Gears esta tambem disponıvel em dispositivos Windows Mobile 5 e 6

Os dispositivos moveis estao pela sua natureza frequentemente desconectados

da Internet Mesmo quando possuem uma ligacao as latencias na transferencia de

dados em redes moveis tornam as aplicacoes pouco fluıdas mas o Gears permite

ultrapassar este obstaculo

O Gears funciona exactamente da mesma forma em dispositivos moveis equipados

com o Windows Mobile 5 e 6 como num computador comum Se uma aplicacao tiver

sido implementado com suporte para o Gears entao tambem estara preparada para

ser executada num dispositivo movel mas as limitacoes dos browsers disponıveis

para dispositivos moveis tem que ser consideradas Isto significa prever as condicoes

que permitam uma boa usabilidade devido aos pequenos ecras destes dispositivos

bem como o seu suporte limitado dos padroes do DOM CSS e JavaScript

32 Adobe AIR

O Adobe AIR4 e um runtime compatıvel com diversos browsers e sistemas opera-

tivos que pretende dar aos programadores a possibilidade de combinar diversas tec-

nologias de producao de conteudos para a Internet no desenvolvimento de Rich Inter-

net Application (RIA)s O Adobe AIR mantem uma relacao com o browser mas es-

tende as suas capacidades e tecnologias permitindo o desenvolvimento de aplicacoes

tambem para o ambiente de trabalho com janelas em tudo semelhantes as do sis-

tema operativo Segundo a Adobe o objectivo e complementar o browser dando

aos utilizadores (mas essencialmente aos programadores e equipas de desenvolvi-

mento) a escolha sobre como distribuir as suas aplicacoes Para este efeito o Adobe

AIR tem uma aproximacao diferente do Gears Em vez de ldquoestenderrdquo o browser

acrescentando-lhe funcionalidades o AIR permite tambem o desenvolvimento de

4Adobe - httpwwwadobecomproductsair

20

Estado da arte

aplicacoes que se destinam a ser executadas fora do ambiente do browser mas uti-

lizando as tecnologias comuns da Internet (por exemplo HTML CSS JavaScript

Flash Flex)[CDGH08]

A utilizacao desta tecnologia permite utilizar o browser ou o proprio runtime

Adobe AIR como plataforma de execucao da aplicacao

Na Tabela 31 faz-se uma comparacao das funcionalidades disponıveis de acordo

consoante se escolha o browser ou o desktop como plataforma base para a aplicacao

Uma vez que as aplicacoes Adobe AIR na plataforma desktop tem um caracter

persistente (sao instaladas no computador do utilizador) o Adobe AIR tem um

modelo de seguranca que se assemelha com o das tradicionais aplicacoes desktop

[Ada08] Este modelo e analisado nas seccoes 321 e 322 O ambiente em que

e executado o browser e restringido a execucao de web applications que podem

ser de varias origens (incluindo de origens anonimas ou sem confianca) O Adobe

AIR proporciona acesso a capacidades como acesso a ficheiros que necessitam da

confianca do utilizador

bull HTML ndash O desenvolvimento de aplicacoes para o Adobe AIR pode ser feito

com recurso a tecnologias de HTML e Ajax comuns utilizando as linguagens

de markup existentes distribuıdas como texto e interpretadas em execucao

(runtime)

bull Flash ndash Outra alternativa sera a utilizacao da linguagem Flash Permite a

renderizacao de graficos vectoriais e audiovıdeo com suporte nativo Utiliza

ActionScript para adicionar maior interactividade com o utilizador

bull Flex ndash O Flex e uma framework open source para o desenvolvimento de RIAs

usando Flash As aplicacoes Flex sao na realidade Flash sendo a principal

diferenca o ambiente de desenvolvimento

Como resultado uma aplicacao AIR podera ser implementada

bull Baseada em Flash ou Flex (aplicacoes cujo conteudo base e em ShockWave

Flash (SWF))

bull Baseada em Flash ou Flex tambem com HTML ou Portable Document Format

(PDF) Aplicacoes cujo conteudo de base e em FlashFlex (SWF) com HTML

(HTML JavaScript CSS) ou conteudo PDF incluıdo

bull Baseada em HTML Aplicacoes cujo conteudo base e em HTML Javascript

CSS

bull Baseada em HTML utilizando tambem FlashFlex ou PDF

21

Estado da arte

Os utilizadores interagem com uma aplicacao AIR da mesma forma que interagem

com outras aplicacoes com janelas nativas do seu sistema operativo O runtime e

instalado uma vez no computador do utilizador e a partir desse momento todas as

aplicacoes AIR terao o mesmo aspecto que qualquer outra aplicacao para o desktop

321 Seguranca

Permitir que uma web application aceda ao disco de armazenamento do utilizador

pode comprometer seriamente a sua seguranca Neste sentido o Adobe AIR tem

suporte para assinaturas digitais (Secure Sockets Layer (SSL)) que podem ser com-

pradas pelas equipas de desenvolvimento que o desejem e cujos certificados serao

apresentados ao utilizador no momento da instalacao Um outro aspecto ainda

relativo a seguranca e o mecanismo de isolamento de cada ambiente (sandbox )

322 Assinatura do codigo

O runtime AIR exige que todas as aplicacoes estejam digitalmente assinadas As

assinaturas digitais de codigo sao um processo que visa garantir a integridade da

aplicacao e a identidade do seu autor no momento da instalacao As equipas de

desenvolvimento podem ldquoassinarrdquo uma aplicacao utilizando um certificado atribuıdo

por uma Entidade Certificadora (Certification Authority) ou atraves de um certifi-

cado individual (self signed certificate) Neste momento o Adobe AIR suporta como

entidades certificadoras a Verisign e a Thawte [Ado08]

O instalador apresenta o nome de quem publica a aplicacao quando o codigo tiver

sido assinado com um certificado que apresente confianca ou que esteja encadeado

com um certificado que tenha ja sido aceite no computador em que se esta a instalar

a aplicacao

As equipas de desenvolvimento podem tambem assinar as aplicacoes com um

certificado auto-atribuıdo (um certificado criado por elas proprias) mas neste caso

o instalador apresentara estas aplicacoes como sendo de uma origem nao verificada

O AIR utiliza a infraestrutura publica de chaves [Ent07] suportada pelo arquivo

local do sistema operativo Para que a origem da aplicacao seja reconhecida o

computador onde a aplicacao AIR esta a ser instalada tem que confiar directamente

no certificado que foi utilizado para assinar a aplicacao ou confiar num certificado

que esteja num encadeamento logico de certificados confiados e que se ligue desta

forma ao certificado utilizado para assinar a aplicacao

Todas as aplicacoes AIR tem caracterısticas em comum independentemente da

tecnologia utilizada para o seu desenvolvimento (HTMLFlexFlash) No ambito

de uma aplicacao AIR existem um conjunto de APIs que estao disponıveis e que

tornam possıvel o acesso ao sistema local (leitura e escrita) e a recursos de rede que

22

Estado da arte

de outra forma nunca estariam acessıveis a partir de uma web application comum

Cada aplicacao AIR possui tambem diferentes nıveis de isolamento chamados secu-

rity sandboxes dependendo do tipo de conteudo que esta a ser carregado e do seu

objectivo

bull Isolamento ao nıvel da aplicacao5 ndash E a raiz de cada aplicacao AIR Este

nıvel de isolamento permite o acesso a APIs privilegiadas e especıficas do

AIR Em contrapartida e negado o acesso a algumas APIs que poderiam ser

facilmente utilizadas de forma maliciosa contra o utilizador final Importacao

dinamica de conteudos remotos e geralmente proibido e as tecnicas e mecan-

ismos de geracao dinamica de codigo sao fortemente restringidas Apenas

conteudo carregado directamente da directoria base da aplicacao podera ser

colocado neste nıvel de isolamento

bull Isolamento nao especıfico da aplicacao6 ndash contem todo o outro conteudo

que nao tenha sido carregado directamente para o isolamento da aplicacao

Isto inclui conteudo local e remoto Este tipo de conteudo nao tem acesso

directo as APIs do AIR e rege-se pelas mesmas regras tal como se tivesse sido

carregado por um browser a partir da mesma localizacao (por exemplo HTML

carregado a partir de um domınio remoto comporta-se da mesma forma que se

fosse acedido a partir do browser)

33 Mozilla Prism

331 XML User Interface Language

O eXtensible User Interface Language (XUL) e uma linguagem de anotacao

baseada em XML desenvolvida pela Mozilla Foundation que opera em aplicacoes

Mozilla multi plataforma tal como o Firefox O motor Gecko e a unica imple-

mentacao completa desta linguagem que foi desenhada sobre padroes web comuns

como CSS JavaScript e o DOM e permite o desenvolvimento de interfaces graficas

utilizando elementos pre-definidos tais como window box page textbox radio

button entre outros Infelizmente o XUL nao possui qualquer especificacao formal

ou implementacoes de inter-operabilidade para outros motores que nao o Gecko No

entanto a sua implementacao e licenciada em codigo aberto pelas licencas GNU Gen-

eral Public License (GPL) GNU Lesser General Public License (LGPL) e Mozilla

Public License (MPL)

Enunciam-se algumas caracterısticas desta linguagem

5NT application sandbox6NT non-application sandbox

23

Estado da arte

Liguagem de anotacao poderosa baseada em componentes (widgets) O ob-

jectivo do XUL e permitir a construcao de aplicacoes multi-plataforma em

claro contraste com o Dynamic HyperText Transfer Protocol (DHTML) que se

destina ao desenvolvimento de paginas web Por esta razao o XUL esta orien-

tado a componentes tais como janelas botoes e etiquetas em vez de paginas

cabecalhos de texto e ligacoes de hipertexto Investir tempo e esforco para

atingir este mesmo resultado em aplicacoes baseadas em DHTML compromete

frequentemente a complexidade e desempenho da aplicacao

Baseado em padroes O XUL e um dialecto XML baseado no padrao W3C XML

10 As aplicacoes escritas em XUL sao tambem baseadas em especificacoes

W3C adicionais como HTML 40 CSS DOM nıvel 1 e 2 JavaScript 15

incluindo ECMA-262 Edition 3 (ECMAscript)

Portabilidade entre plataformas Tal como HTML o XUL foi desenhado para

ser independente da plataforma em que e utilizado tornando as aplicacoes

facilmente portaveis entre sistemas operativos nos quais o Mozilla e suportado

Uma vez que o XUL oferece um nıvel de abstraccao dos componentes graficos

de interface que disponibiliza implementa a premissa ldquoum codigo para todas

as plataformasrdquo A interface grafica de todos os produtos centrais Mozilla

(browser instant messenger livro de enderecos) e escrita em XUL com um

unico codigo base que suporta todas as plataformas Mozilla

Separacao entre o nıvel de apresentacao e a logica de negocio Uma das

maiores preocupacoes no desenvolvimento para a Internet e a forte ligacao

entre estas duas camadas (interface e logica) Isto constitui um problema sig-

nificativo no desenvolvimento de grandes aplicacoes especialmente quando o

desenvolvimento e feito em ambientes de equipa porque as capacidades de de-

senvolvimento destas duas partes da aplicacao estao muitas vezes espalhadas

por diferentes elementos O XUL permite uma clara distincao entre a definicao

da aplicacao cliente e da logica de implementacao (XUL eXtensible Binding

Language (XBL) e JavaScript) apresentacao (CSS e imagens) internacional-

izacao (Document Type Definitions (DTDs) e etiquetas de texto em lınguas

especıficas guardados em ficheiros properties) O esquema grafico e apre-

sentacao de uma aplicacao XUL pode ser alterado de forma independente da

sua logica ou implementacao e a aplicacao pode ainda ser traduzida (interna-

tionalization) de forma independente da sua logica implementacao ou apre-

sentacao Este grau de separacao resulta em aplicacoes que sao mais faceis de

manter pelos programadores e facilmente adaptadas por designers e tradutores

24

Estado da arte

Facil adaptacao Outro benefıcio que advem do nıvel de separacao entre logica

de negocio e apresentacao oferecido pelo XUL e a facilidade com que se pode

adaptar uma aplicacao para diferentes clientes ou grupos de utilizadores Um

programador pode utilizar a mesma aplicacao base e adapta-la consoante as

necessidades atraves de diferentes temas (skins) e ficheiros de lınguas Desta

forma uma aplicacao escrita e desenvolvida em Ingles pode ser rapidamente

traduzida para Portugues e distribuıda com outra aparencia mais apropriada

ao cliente alvo

332 Prism

O Mozilla Prism e um browser simplificado e ldquointerpretadorrdquo de XUL (tambem

designado por XULRunner) que acolhe web applications sem a interface grafica ha-

bitual de um browser Baseia-se num conceito designado por Site Specific Browser

(SSB) Um SSB e uma aplicacao com um browser embebido desenhado para exe-

cutar apenas uma web application Nao possui os menus e barras de ferramentas

habituais Um SSB tem uma integracao com o sistema operativo e com o desktop

muito mais estreita do que uma web application acedida atraves de um browser uma

vez que e executado em janela propria

O Prism resulta de uma experiencia da Mozilla e visa reduzir as diferencas entre

as desktop applications tradicionais e as web applications Um dos aspectos focados e

a experiencia do utilizador Numa apresentacao oficial e dito que ldquo[o Prism] pretende

ser uma ponte entre as diferencas que existem entre as aplicacoes tradicionais de

desktop e as web applications explorando novos modelos de usabilidade enquanto

que a linha que as separa se continua a definirrdquo [Lab07]

34 HTML 5

A especificacao HTML 5 [Hic08] que se encontra em fase de desenvolvimento

pelo grupo WHATWG pretende ser uma norma de substituicao dos padroes HTML

4 XHTML 1x e do DOM2 HTML Uma das propriedades que o distingue das tec-

nologias que pretende substituir e precisamente o suporte para OWA e armazena-

mento de dados no cliente de uma forma relacional Nao sendo propriamente uma

tecnologia ndashmas antes uma especificacao ndashe aqui mencionada por ter servido como

referencia a diversas implementacoes de funcionalidades offline e por se considerar

que venha a ter um impacto significativo nas implementacoes de diversos browsers

Dion Almaer defendeu no seu blogue que o Gears era uma implementacao do

HTML 5 No seu artigo ldquoGears as a bleeding-edge HTML 5 implementationrdquo [Alm08]

o autor diz que ambos ndasho Gears e o HTML 5 ndashpretendem dar a web caracterısticas

25

Estado da arte

semelhantes e nao encontrar motivo de ldquocompeticaordquo entre as duas mas que en-

quanto o HTML 5 e uma especificacao o Gears e uma implementacao

No entanto tambem e verdade que o HTML 5 cobre muitos outros pontos para

alem das OWA que saem completamente fora do ambito do Gears Se esta es-

pecificacao atingir um estado de maturidade que possibilite a sua adopcao pelos

principais browsers tornando nativo do browser o suporte OWA entao deixara de

fazer sentido a existencia de uma extensao como o Gears

A especificacao HTML 5 disponibiliza duas APIs relevantes para o tema das

OWA

1 Uma base de dados baseada em SQL que permite o armazenamento de dados

do lado do cliente

2 Uma ldquocacherdquo HTTP que garante a disponibilidade das aplicacoes mesmo quando

o utilizador nao possui uma ligacao a Internet

Estas caracterısticas sao as bases da tecnologia das OWA e tem correspondencia

com os pontos analisados nas seccoes 311 e 311

35 Web applications que usam funcionalidades offline

Nesta seccao apresentam-se algumas web applications que actualmente disponi-

bilizam funcionalidades offline Estas aplicacoes foram escolhidas para uma analise

mais pormenorizada por utilizarem o Gears que tal como descrito na seccao 4 foi

a tecnologia escolhida para o projecto

351 Google Reader e Google Docs

O Google Reader7 e um leitor de feeds RSS Permite gerir a subscricao de varios

sites simultaneamente que disponibilizem conteudos neste formato e foi a primeira

web application da Google com uma versao offline publicamente acessıvel (desde

Junho de 2007)

O Google Reader implementa o modo ldquoutilizador deciderdquo oferecendo na sua

interface um botao que permite alternar entre os modos online e offline

O Google Docs8 e uma web application que permite a criacao e edicao de doc-

umentos de texto folhas de calculo e apresentacoes Era ja publico desde Janeiro

de 2008 que o Google estava a desenvolver uma versao OWA desta aplicacao mas o

acesso a uma versao experimental so foi possıvel a partir de 31 de Maio de 2008

7Google Reader - httpreadergooglecom8Google Docs - httpdocsgooglecom

26

Estado da arte

A implementacao das funcionalidades offline nestas duas aplicacoes seguiu difer-

entes aproximacoes principalmente porque o Google Reader apresenta ao utilizador

informacoes que sao fornecidas por fontes externas enquanto que no Google Docs

a informacao e criada e editada pelo utilizador sobre a forma de documentos

A diferente origem da informacao implica que no Google Reader seja necessario

prever casos de excepcao tal como existirem demasiados itens que necessitam de

ser transferidos para o cliente Nao observar este ponto causa um problema grave

de usabilidade e para evitar tempos de espera demasiado longos e uma interface

com pouca capacidade de resposta as accoes do utilizador o Google Reader apenas

transfere para o cliente os dois mil itens mais recentes na transicao para o modo

offline

352 Remember the Milk

O Remember The Milk9 e uma web application desenvolvida por uma equipa

Australiana que proporciona funcionalidades de agenda gestao de tempo e de tare-

fas e foi uma das primeiras aplicacoes independentes do Google a adoptar o Gears

para acessos em modo offline Permite que os seus utilizadores facam uma gestao

de tarefas agrupando-as em listas adicionando-lhes campos de informacao adicional

ou dando-lhes informacao geografica (recorrendo ao servico Google Maps10) Entre

a sua lista de funcionalidades encontra-se ainda a possibilidade de importar e ex-

portar eventos no formato iCalendar (ics) etiquetas (tags) em tarefas publicacao

Really Simple Syndication (RSS) e partilha de categorias de tarefas de acordo com

diferentes nıveis de permissoes de acesso definidos pelo utilizador

353 MySpace e WordPresscom

O MySpace uma das maiores social networks na Internet anunciou recente-

mente que vai disponibilizar uma versao do seu cliente de e-mail que utiliza o Gears

para acelerar o seu desempenho Numa fase inicial estara disponıvel apenas para

utilizadores que tenham cinco mil ou mais mensagens na sua caixa de correio e

permitira efectuar pesquisas muito mais rapido que a sua versao online

O servico de blogs Wordpresscom anunciou tambem o inıcio da utilizacao desta

tecnologia com o fim de melhorar o desempenho A versao que utiliza esta tecnologia

descarrega e armazena no cliente um conjunto de imagens e scripts que passam a

ter preferencia sobre os seus congeneres online e que permitem acelerar o processo

de carregamento da aplicacao e visualizacao de blogs

9Remember The Milk ndash httpwwwrememberthemilkcom10Google Maps ndash httpmapsgooglecom

27

Estado da arte

O MySpace e o Wordpresscom sao dois exemplos da utilizacao da tecnologia

OWA para optimizacao de web application ja existentes Sem pretenderem disponi-

bilizar uma versao que seja totalmente offline fazem uso do Gears para armazenar no

cliente parte dos recursos frequentemente acedidos na visualizacao das suas paginas

36 Escolha da tecnologia

Apos a analise das tecnologias apresentada nas seccoes 31 a 34 foi necessario es-

tudar a adequacao de cada uma delas ao projecto em questao Desde logo e possıvel

observar que nem todas se dedicam apenas a OWA Por exemplo o Adobe AIR

apesar de ter suporte para OWA apenas disponibiliza algumas das funcionalidades

identificadas como mais indicadas para a execucao do projecto quando utilizado

na sua vertente desktop tal como exposto na Tabela 31 mas a utilizacao desta

vertente implicaria o desenvolvimento de novas interfaces e de novas formas de co-

municacao (troca de mensagens XML ou JSON) A vertente web do Adobe AIR

foca-se mais especificamente nas Rich Internet Applications e permite a reutilizacao

do codigo ja existente (exigindo naturalmente a sua adaptacao e a implementacao

das funcionalidades pretendidas)

A tecnologia escolhida para a realizacao deste trabalho foi o Gears sendo que

um dos principais factores a influenciar esta opcao foi a liberdade introduzida pela

sua licenca Berkeley Software Distribution (BSD)11

Considerou-se o funcionamento desta ferramenta extremamente adequando a

aplicacao no WOW uma vez que o seu principal objectivo e precisamente tornar

possıvel a execucao offline de uma pagina web e por virtude deste facto o Gears tem

uma API concisa e de simples aplicacao pratica uma vez que nao possui quaisquer

outros elementos distractores O funcionamento do seu ManagedResourceStore ex-

emplificado na Figura 31 com a capacidade de actualizacao de recursos definidos

num ficheiro manifesto especificado em JSON pesou tambem nesta decisao

11Sobre a licenca BSD consultar httpwwwopensourceorglicensesbsd-licensephp e http

wwwlinfoorgbsdlicensehtml

28

Estado da arte

Figura 31 Esquema UML do processo efectuado pelos recursos do Gears do tipoManagedResourceStore para a actualizacao dos conteudos definidos no ficheiro manifesto

29

Estado da arte

Funcionalidade RIAs no browser RIAs no desktop

Disponibilidadeda aplicacao

As aplicacoes podem ser facil-mente exploradas e utilizadas

As aplicacoes quando instal-adas tem maior grau de fun-cionalidades e persistencia

Instalacao Nao e necessario qualquer tipode instalacao

As aplicacoes sao instaladasatraves do browser ou descar-regadas e instaladas comouma aplicacao tradicional

Actualizacoes Aplicacoes sao actualizadascarregando conteudos paraum website

O AIR disponibiliza uma APIque permite que as aplicacoessejam actualizadas de umaforma

Sistemas opera-tivos suportados

As aplicacoes podem ser exe-cutadas em diversos sistemasoperativos e browsers

As aplicacoes sao multi-plataforma e podem serinstaladas e executadas emdiversos sistemas operativos ebrowsers

Linguagens deprogramacao

Javascript e disponibilizadopelo browser e ActionScripte disponibilizado pelo AdobeFlash Player

Maquinas virtuais deJavascript e ActionScriptcompatıveis com o browser

Capacidade deexecucao embackground

As RIAs podem ser execu-tadas numa janela do browser

As aplicacoes podem ser ex-ecutadas em background edisponibilizar notificacoes talcomo uma aplicacao tradi-cional

Persistencia A actividade esta limitada asessao do browser Quando obrowser e encerrado toda ainformacao e descartada

As aplicacoes sao instaladas eestao disponıveis no desktopPodem armazenar informacaolocalmente e estao disponıveisoffline

Integracao com odesktop

Integracao com o desktop lim-itada devido a restricoes im-postas pelo browser

As aplicacoes podem acederao sistema de ficheiro ao clip-board eventos notificacoesetc

Controlo da inter-face com o uti-lizador

As aplicacoes sao acedidasatraves de uma janela dobrowser que tem os seusproprios controlos e visualgrafico

As aplicacoes tem um vi-sual grafico proprio em janelapropria

Armazenamentode dados

As aplicacoes tem armazena-mento limitado que pode serreescrito pelo browser

As aplicacoes tem acesso a to-talidade do espaco disponıvellocalmente e a uma base dedados com a possibilidade deencriptacao

Tabela 31 Comparacao das funcionalidades oferecidas pelo Adobe AIR para as platafor-mas web e desktop

30

Estado da arte

Aplicacao Modo de execucao utilizadoGoogle Reader Utiliza o modo ldquoutilizador deciderdquo disponibilizando

ao utilizador um botao para alternar entre os modosonline e offline Como lida com informacao recol-hida de fontes externas de natureza frequentementeefemera o processo de sincronizacao apenas transfereos dois mil itens mais recentes quando passa ao es-tado offline Neste modo sao ainda guardadas in-formacoes de itens lidos e etiquetas atribuıdas quesao sincronizadas com o servidor quando o utilizadorvoltar a activar estado online

Google Docs Utiliza o modo ldquoaplicacao deciderdquo permitindo que outilizador edite os conteudos de documentos de textofolhas de calculo e de apresentacoes independente-mente do estado da ligacao desde o momento em queas funcionalidades offline sao activadas A aplicacaofaz pequenas sincronizacoes com o servidor sempre quenecessario

Remember the Milk Utiliza um modo hıbrido entre ldquoaplicacao deciderdquo eldquoutilizador deciderdquo A aplicacao encarrega-se da sin-cronizacao de dados mas disponibiliza um controlona sua interface que permite despoletar manualmenteeste processo para situacoes em que o utilizador fez al-teracoes recentes e pretende usufruir das capacidadesoffline imediatamente

MySpace O MySpace anunciou a utilizacao de mecanismos dearmazenamento de dados no cliente com recurso atecnologias OWA para melhorar o desempenho doseu cliente web de correio electronico nomeadamenteno que diz respeito a operacoes de pesquisa e or-denacao Inicialmente esta funcionalidade estara ape-nas disponıvel para utilizadores com cinco mil ou maismensagens na sua caixa de correio mas nao e aindaclaro se sera disponibilizada uma versao totalmenteoffline

Tabela 32 Resumo da utilizacao de tecnologias OWA em algumas web applications con-sideradas na analise do estado da arte

31

Estado da arte

32

Capıtulo 4

Desenvolvimento

Neste capıtulo introduz-se a aplicacao WOW e apresenta-se o estudo que foi

feito da adequacao de cada tecnologia para a implementacao da funcionalidade of-

fline nesta plataforma Fazem-se diversas consideracoes sobre opcoes a tomar na

concepcao de OWAs e problemas comuns na sua implementacao bem como sug-

estoes para os resolver O WOW e uma aplicacao ja existente de gestao de ordens

de trabalho e do fluxo de tarefas numa empresa ou organizacao

41 Como ficar offline

Na maior parte das web applications de hoje nao existe uma camada de dados

real A aplicacao exemplificada na Figura 41 ao longo da sua execucao acede

directamente a sua unica fonte de dados (o servidor) atraves de chamadas Ajax sem

que exista uma separacao clara destas duas camadas

Para que uma web application seja capaz de ser executada sem uma ligacao

activa a Internet e mantenha o seu caracter dinamico torna-se necessario incluir

Figura 41 Exemplo de uma arquitectura de uma web application sem uma camada deabstraccao de dados Figura adaptada de http gears google com

33

Desenvolvimento

Figura 42 Exemplo de uma arquitectura de uma web application com uma camada deabstraccao de dados Figura adaptada de http gears google com

um mecanismo de armazenamento de dados local seja uma base de dados ou a

capacidade de acesso ao disco No entanto este mecanismo introduz dois problemas

1 Qual das fontes de dados utilizar quando um utilizador faz um pedido de

informacao

2 A necessidade de implementar uma camada de acesso a dados que seja coerente

quer se use o servidor remoto ou local

Por exemplo em vez de a aplicacao Ajax fazer um pedido relativo as contas de

todos os utilizadores em formato JSON directamente ao servidor remoto podera ao

inves fazer o pedido a um objecto intermedio da camada de dados Este objecto

demonstrado na Figura 42 sera responsavel por implementar uma interface de

acesso a base de dados e retornar um objecto JavaScript com uma representacao da

resposta do servidor

Mas a existencia de uma segunda fonte de dados torna recomendavel tambem

a implementacao de uma camada de data switching que em funcao da existencia

de conexao a Internet e da necessidade de actualizacao dos dados decide se faz o

pedido ao servidor remoto ou se fornece os dados presentes localmente Este objecto

apresentado na Figura 43 decidira de forma transparente para o utilizador se le ou

escreve os dados localmente ou se os enviapede ao servidor remoto e pode tambem

iniciar o processo de convergencia de dados e de resolucao de conflitos

411 Funcionalidades disponıveis em modo offline

Por razoes praticas e provavel que nem todas as funcionalidades da aplicacao

possam ser disponibilizadas em modo offline E necessario escolher quais as fun-

cionalidades a disponibilizar no modo offline da aplicacao e implementar a logica

que decide quando utilizar a base de dados local ou o servidor remoto Apesar do

acesso a base de dados local ser muito mais rapido do que aceder ao servidor o

acesso local nem sempre e preferido Ha varias razoes que podem tornar necessario

escolher o acesso ao servidor em vez do acesso local

34

Desenvolvimento

Figura 43 Exemplo de uma arquitectura de uma web application com uma camada deabstraccao de dados e um data switch Figura adaptada de http gears google com

1 A informacao pode ter uma natureza efemera e nao fazer sentido guarda-la

localmente Exemplo dados em tempo real da bolsa de valores de Lisboa

2 Algumas aplicacoes lidam com informacao que so faz sentido na presenca de

uma ligacao Exemplo Instant Messaging

3 A aplicacao podera escolher apenas guardar a informacao acedida mais fre-

quentemente Exemplo para o utilizador poder alterar a lıngua de apre-

sentacao da aplicacao os conteudos terao que ser guardados em todas as

lınguas disponibilizadas pela aplicacao O custo de implementacao de algu-

mas funcionalidades pode nao compensar o benefıcio

4 A capacidade de processamento ou de armazenamento de dados pode inviabi-

lizar algumas funcionalidades offline Exemplo se uma dada funcionalidade

necessita de uma capacidade de armazenamento de dados para alem do razoavel

de um computador pessoal para ser util (visualizador de mapas)

42 Modos de execucao

Um aspecto que e necessario estudar para qualquer web application que se deseje

disponibilizar offline prende-se com tres modos de execucao que devem ser consid-

erados

1 Utilizador decide o modo de execucao A aplicacao tem modos distintos

de execucao para os estados online e offline geralmente indicados na interface

com o utilizador O utilizador e informado do estado da ligacao e participa na

alteracao de estado de execucao da aplicacao interagindo com a sua interface

2 Aplicacao decide o modo de execucao Pode ser implementado na propria

aplicacao um mecanismo de deteccao do estado da ligacao (por exemplo atraves

35

Desenvolvimento

de chamadas Ajax periodicas) transitando de estado e sincronizando automati-

camente Desta forma o utilizador nao precisa de participar na alteracao de

estado a menos que exista um conflito de dados que requeira a sua atencao

3 Aplicacao assume sempre o estado offline Outra hipotese sera imple-

mentar uma web application que assume sempre estar na ausencia de uma

ligacao ao servidor de dados Esta aplicacao responde aos pedidos do uti-

lizador efectuando pedidos de informacao ao servidor mas nao dependendo

de uma resposta valida para mostrar a informacao que ja tinha disponıvel an-

teriormente A sincronizacao de dados com o servidor e tentada sempre que

existam dados para submeter e uma accao do utilizador

421 Modo ldquoutilizador deciderdquo

Neste modo de execucao quando a aplicacao esta online comunica com o servidor

remoto quando esta offline comunica com a base de dados local A informacao tem

que ser sincronizada sempre que se muda de modo A principal vantagem desta opcao

e que e a mais simples de implementar mesmo para uma aplicacao ja existente e

portanto uma forma expedita de disponibilizar uma OWA No entanto tem tambem

algumas desvantagens que devem ser consideradas

1 O utilizador tem que se lembrar de fazer a alteracao de estado de execucao

Caso contrario podera estar a trabalhar inadvertidamente numa versao offline

com dados antigos ou nao ter a informacao necessaria se perder subitamente

a ligacao

2 Se a ligacao for intermitente o utilizador tera ou que escolher um dos modos

de execucao ou estar constantemente a trocar

3 Uma vez que a base de dados nao esta sempre actualizada nao podera ser

utilizada para melhorar a rapidez de execucao da aplicacao quando em modo

online

422 Modo aplicacao decide

A deteccao do estado da ligacao pode ser implementada atraves de um pedido

assıncrono ao servidor tal como ilustrado na Figura 44 O resultado deste pedido

definira o estado online (em caso de sucesso) ou offline (em caso de falha) A

sincronizacao de dados podera ser feita sempre que ocorra uma transicao do es-

tado offline para o estado online No entanto este metodo nao se revela eficiente

36

Desenvolvimento

Figura 44 Esquema grafico ilustrando uma OWA executando no browser utilizando ummodo de execucao do tipo ldquoaplicacao deciderdquo com deteccao automatica do estado daligacao via pedidos Ajax assıncronos a cada cinco segundos

para grandes aplicacoes uma vez que requer a troca de mensagens demasiado fre-

quentes com o servidor que se destinam exclusivamente a monitorizacao do estado

da ligacao

423 Modo ldquoaplicacao assume o estado offlinerdquo

Uma aplicacao transparente funciona assumindo sempre que esta em modo of-

fline ou pelo menos que pode perder a ligacao a qualquer momento Neste modo

tira-se o maximo partido do armazenamento local e fazem-se pequenas mas contınuas

sincronizacoes com o servidor sempre que este esteja disponıvel A sincronizacao de

dados tambem e feita sempre que se volta ao estado online

As vantagens de uma web application transparente sao as seguintes

bull Uma melhor experiencia para o utilizador uma vez que este nao tem que se

preocupar com o estado da ligacao ou com a transicao de estados

bull A aplicacao funciona de forma coerente mesmo que a ligacao seja intermitente

bull Uma vez que o armazenamento local e mantido actualizado pode ser utilizado

para melhorar o desempenho da aplicacao

Foram identificadas as seguintes desvantagens

bull E mais difıcil de implementar e a sincronizacao acarreta cuidados especiais

bull E necessario um cuidado adicional para evitar que as operacoes de sincronizacao

frequentes que ocorrem automaticamente nao afectem os tempos de resposta

da aplicacao

bull Os testes a aplicacao sao mais complexos uma vez que a sincronizacao de dados

nao ocorre em resposta a uma accao do utilizador

37

Desenvolvimento

43 Sincronizacao de dados

A sincronizacao de dados consiste na capacidade de identificar e transferir pe-

riodicamente a versao mais actual dos dados entre o cliente e o(s) servidor(es)

Independentemente do modo de execucao escolhido e mesmo do estado da ligacao

do utilizador a informacao armazenada localmente e a informacao armazenada no

servidor estarao por vezes dessincronizadas Isto podera acontecer sempre que por

exemplo

bull O utilizador faz alteracoes em modo offline

bull A informacao e partilhada e pode ser alterada por uma entidade externa

bull A informacao e fornecida por uma entidade externa

Resolver estas diferencas de forma a que a informacao local e remota encontrem

a igualdade chama-se sincronizacao de dados Ha varias aproximacoes possıveis

para este efeito que dependem da natureza da aplicacao cada uma com vantagens

e desvantagens

A capacidade de suportar a mobilidade dos utilizadores torna-se cada vez um

ponto mais importante de uma web application Para uma organizacao de dimensao

global e vital garantir que os seus colaboradores tem acesso a mesma informacao

que tem disponıvel nos seus postos de trabalho mesmo quando estao fora Na maior

parte dos casos estes colaboradores terao acesso a um computador portatil um

desktop Smartphone ou PDA e atraves destes poderao ter acesso a sua informacao

directamente atraves de ligacoes encriptadas Virtual Private Network (VPN) de um

servidor web ou de outro mecanismo de rede

Esta solucao e simples de implementar mas infelizmente para a maioria dos

colaboradores com grande factor de mobilidade nao e satisfatoria As principais

desvantagens sao as seguintes

bull Requisitos de ligacao Para permitir que os utilizadores acedam a sua in-

formacao e necessario garantir a capacidade constante de comunicacao pelo

menos durante o tempo necessario que assegure a sua transferencia

bull Velocidade de ligacao sem persistencia de dados e em ligacoes de fraca

qualidade a usabilidade por vezes torna-se inaceitavel

bull Ponto crıtico de falha Com este tipo de solucao todos os utilizadores de-

pendem da base de dados que armazena informacao vital para o funcionamento

do cliente

38

Desenvolvimento

bull Scalability do servidor A medida que novos utilizadores sao adicionados ao

sistema o desempenho do servidor e afectado levando a necessidade de maior

capacidade de armazenamento eou processamento

De acordo com a documentacao da Microsoft Sync Framework [Mic08] uma

solucao alternativa consiste em implementar uma Occasionally Connected Appli-

cation (OCA) Uma OCA permite a um utilizador remoto continuar a aceder a

sua informacao mesmo depois de perder a ligacao mas em vez de recorrer a um

servidor recorre a informacao armazenada no seu dispositivo local Para preencher

localmente a informacao que o utilizador necessita uma OCA possui mecanismos

de sincronizacao de dados que sao oferecidos por esta framework

431 Quando sincronizar

Uma das solucoes mais simples de implementar passa por disponibilizar um

mecanismo manual que despoleta a sincronizacao Diz-se manual porque e o uti-

lizador que escolhe quando sincronizar e pode ser implementada simplesmente

fazendo o upload de toda a informacao para o servidor e depois fazendo o download

da copia mais recente da informacao antes de voltar a ficar offline Para que esta

seja uma opcao viavel e necessario que

bull O volume de dados seja suficientemente pequeno para que possa ser transferido

do servidor para o cliente num espaco de tempo aceitavel

bull Que o utilizador indique explicitamente que quer mudar para o estado offline

ou online pressionando um botao da interface

Contudo podem ser identificados alguns problemas relacionados com esta abor-

dagem

bull Os utilizadores nem sempre podem prever o estado das suas ligacoes A ligacao

pode-se perder subitamente ou ter um caracter intermitente

bull O utilizador pode esquecer-se de efectuar a sincronizacao

Outra opcao sera conjugar a sincronizacao de dados com o modo de execucao

transparente A sincronizacao ocorre automaticamente em background de forma

nao intrusiva para o utilizador A aplicacao comunica com o servidor regularmente

efectuando pequenas trocas de dados com o objectivo de manter o sincronismo da

informacao local e remota Esta abordagem pode ser implementada com pedidos

Ajax assıncronos e regulares ao servidor o que permite manter a interaccao com a

interface fluıda evitando bloqueios Estes pedidos sao feitos prevendo as situacoes

39

Desenvolvimento

de disponibilidade ou indisponibilidade (timeout) do servidor Uma outra opcao

sera permitir que o servidor comunique essas alteracoes utilizando Comet1 tal como

descrito em [Wil06] e [Rus06] As vantagens destas aproximacoes sao

bull A informacao esta disponıvel a qualquer altura que o utilizador decida ficar

offline ou que a ligacao seja acidentalmente perdida

bull O desempenho da aplicacao pode ser melhorado quando se estiver a utilizar

uma ligacao a Internet lenta uma vez que o acesso a dados locais e mais

eficiente do que a consulta de dados ao servidor

44 WOW

O WOW e uma plataforma integrada de gestao de ordens de trabalho ja ex-

istente e desenvolvida pela Critical Software SA a qual se pretende adicionar a

capacidade de execucao offline Esta aplicacao e extremamente dinamica e con-

figuravel com um conjunto extremamente rico de funcionalidades das quais se

destacam

bull Gestao de Ordens de Trabalho ndash suportando a gestao dos pedidos desde a

sua criacao ate ao seu fecho tomando em conta os diferentes tipos de pedidos

(ordens de trabalho pedidos de informacao melhorias resolucao de problemas

etc) e diferentes tipos de accoes possıveis para cada um (Figura 45)

bull Monitorizacao de alteracoes ndash Historico de mudancas anexos e estados criando

relatorios de alteracao automaticamente (o que por quem e quando)

bull Uso de Service Level Agreements (SLAs) ndash E possıvel associar a um pedido um

SLA que define qual o perıodo de tempo atribuıdo a resolucao de um pedido

controlando e agilizando a resolucao do mesmo

bull Utilizacao de queries de utilizador configuraveis que permitem acesso rapido

a determinadas ordens de trabalho de acordo com o filtro configurado (por

exemplo ldquoPara mimrdquo ldquoPara o Grupordquo ldquoPelo Grupordquo)

bull Gestao do relacionamento entre pedidos

bull Pesquisa e filtragem de ordens de trabalho

bull Exportacao de dados em formatos padrao (PDF DOC ou XLS)

bull Integravel com solucoes externas

40

Desenvolvimento

Figura 45 Detalhe de um conjunto possıvel de estados e respectivas transicoes para umadada ordem de trabalho no WOW desde a sua submissao no sistema ate a sua conclusaoem fecho ou cancelamento Esta figura representa apenas um exemplo ja que o mapa deestados para uma ordem de trabalho e dinamico e pode ser alterado por um administradorFigura retirada de uma brochura promocional do WOW Critical Software SA

A utilizacao de uma ferramenta deste tipo por parte de uma empresa ou orga-

nizacao oferece vantagens quer a gestao de topo quer aos colaboradores individuais

para os colaboradores individuais o WOW e uma aplicacao onde estao registadas

todas as tarefas contribuindo activamente para o desenvolvimento em ambientes

multi-tarefa e para a organizacao pessoal das tarefas de acordo com prioridades

Para a gestao de topo esta ferramenta permite obter uma visao global do estado da

organizacao em termos de tempo gasto por tarefa executada sendo uma mais valia

para a previsao e gestaoalocacao de recursos

45 Visao geral sobre a arquitectura do WOW

O WOW e interessante nao so do ponto de vista de produto como tambem do

ponto de vista de plataforma Existem diversos plug-ins que estendem as funcional-

idades do WOW e existem ate projectos que pretendem usar a arquitectura do

WOW para criar produtos com fins diferentes do inicial (por exemplo o WOW-

Storm ndash um sistema de registo e classificacao social de ideias)

De modo a conseguir ter essa expansibilidade a plataforma WOW assenta sob

uma arquitectura distribuıda modular e expansıvel com uma componente central

ndash o core ndash estruturado em camadas logicas E no core que se situam todas as

1O Comet e um conceito semelhante ao Ajax introduzido por Alex Russel mas no qual e o servidor quetoma a iniciativa de ldquoenviarrdquo os dados ao browser sem que este tenha que efectuar um pedido Tambem econhecido por Ajax Push Reverse Ajax ou HTTP Streaming

41

Desenvolvimento

funcionalidades base da aplicacao quer a nıvel logico funcional e de apresentacao

quer a nıvel de gestao e configuracao

E possıvel a execucao de varias instancias do core simultaneamente em servidores

distintos o que permite a alta escalabilidade e disponibilidade desta aplicacao A

consistencia dos dados fica sempre garantida atraves da partilha da base de dados

e pelo balanceamento dos pedidos uma vez que cada um e encaminhado para uma

unica instancia

O WOW apresenta tambem a vantagem de ser uma plataforma extensıvel E

possıvel adicionar novas caracterısticas a plataforma atraves de componentes que se

podem ser divididos em duas categorias plugins e connectors

Os plugins sao componentes que se encontram no mesmo no fısico que a aplicacao

partilhando do mesmo contexto de execucao do core Sao assim uma forma mais

directa de obter informacao da plataforma visto que nao possuem restricoes de

acesso aos dados nem dependencias externas A arquitectura deste componente tera

assim que permitir varias execucoes instanciadas cada uma associada a um core

Por outro lado os connectors sao componentes que se encontram distribuıdos

comunicando externamente com o core Quer a sua execucao quer a obtencao

dos dados estao assim dependentes de interfaces de comunicacao externas que a

plataforma disponibiliza Estes componentes ao contrario dos plugins sao instan-

ciados unicamente e recorrem ao protocolo de comunicacao Java Messaging Service

(JMS) para comunicar com o core

46 WOW Offline

Para alem das opcoes tomadas relativamente a tecnologia a utilizar surgiu

tambem a necessidade de optar por um dos modos de execucao apresentados na

seccao 42

Das tres opcoes possıveis foi o modo ldquoaplicacao assume o estado offlinerdquo descrito

na seccao 423 que mereceu a maior atencao uma vez que reune as vantagens de

uma experiencia mais positiva para o utilizador (uma vez que este nao tem que

participar activamente na alteracao do modo execucao como descrito na seccao 421)

e nao constitui uma sobrecarga excessiva para servidor (como o modo abordado na

seccao 422)

No entanto esta opcao comprometia a complexidade da implementacao para alem

dos objectivos propostos para este projecto e para cumprir o prazo dado foi tomada

a decisao de implementar o modo ldquoutilizador deciderdquo especificando apenas de forma

teorica o modo ldquoaplicacao assume o estado offlinerdquo

As caracterısticas do Gears foram ja descritas na seccao 31 Na Figura 47

mostra-se a sua forma de funcionamento quando integrado numa web application

42

Desenvolvimento

Nesta figura representa-se o modulo LocalServer do Gears como um ponto de de-

cisao Aqui sao testadas as condicoes que determinam se o pedido sera interceptado e

servido localmente ou se prossegue para uma maquina remota E tambem represen-

tada uma base de dados que corresponde ao modulo Database mas que podera nao

ser utilizada Este modulo tal como o modulo Workerpool tem caracter opcional

e sao utilizados consoante os requisitos da aplicacao

A plataforma WOW lida com mais dados do que e necessario passar para o

lado do cliente Em conformidade com o ja exposto na seccao 411 volta-se a

frisar que nao se pretende recriar toda a logica de negocio nem os conteudos da

base de dados no cliente pela sua complexidade e volume de dados Pretende-se

pelo contrario permitir que os utilizadores tirem partido da capacidade de poder

consultar as suas ordens de trabalho quando nao dispoe de uma ligacao transferindo

apenas o essencial para isto seja possıvel

A pagina inicial do WOW apresenta um resumo das ordens de trabalho abertas

ndash enviadas e recebidas ndash que se pretende permitir visualizar offline (ver Figura 46)

Como prova de conceito foi efectuada uma abordagem pragmatica das varias possi-

bilidades descritas na seccao 42

461 Modo ldquoaplicacao deciderdquo com deteccao automatica da ligacao

A primeira abordagem estudada para a disponibilizacao das funcionalidades of-

fline foi o modo ldquoaplicacao deciderdquo com deteccao automatica de ligacao apresentado

na seccao 422 Para que isto seja possıvel foi implementado um mecanismo de ver-

ificacao periodica do estado da ligacao atraves de chamadas Ajax assıncronas O

resultado destes pedidos determina o estado da aplicacao executando as tarefas de

sincronizacao de dados sempre que pertinente Este metodo embora imediato e

simples de implementar depressa se revelou inadequado para o projecto devido ao

elevado consumo de recursos do servidor que a utilizacao intensiva faz esperar a

comunidade da plataforma WOW no principal cliente excede os 7000 utilizadores

Foi estimado que para uma utilizacao de fluidez aceitavel o estado da ligacao deveria

ser testado a cada cinco segundos Assumindo uma adesao (previsao pessimista) de

1 aos servicos offline assistir-se-ia a cerca de 840 pedidos adicionais por minuto

Mas o principal problema desta aproximacao prende-se com o facto de a ver-

ificacao ser feita em intervalos de tempo discretos levando a possibilidade de a

aplicacao poder ter em dado momento uma representacao errada do seu estado

real da ligacao Este problema e ilustrado na Figura 48 onde se ve claramente a

discrepancia entre o estado real da ligacao e a representacao interna que esta tem

Note-se que nesta janela de tempo qualquer accao do utilizador que exija uma

resposta sıncrona do utilizador leva-lo-a para um ldquobeco sem saıdardquo onde nao tera

43

Desenvolvimento

Figura 46 A pagina inicial do WOW apresenta um resumo das ultimas ordens de trabalhoenviadas e recebidas Na imagem pode-se observar a transicao do estado online para offline

acesso a versao offline porque a aplicacao nao fez a transicao automatica nem acesso

a versao online porque na verdade nao possui uma ligacao O que acontecera nesta

situacao sera uma tentativa de acesso ao servidor por parte da aplicacao numa

altura em que este se encontra indisponıvel e o resultado sera uma mensagem de

ldquopedido excedeu o tempordquo apresentado pelo browser Este e um estado sem retorno

porque apos o browser apresentar esta mensagem todos os recursos JavaScript ficam

indisponıveis tornando impossıvel o regresso ao estado anterior ou o tratamento do

erro de qualquer outra forma No entanto as chamadas Ajax podem ser tratadas de

forma especial para a eventualidade de falha e portanto nao constituem problema

44

Desenvolvimento

Figura 47 Ilustracao do funcionamento do Gears numa web application que utiliza ummotor Ajax Os pedidos HTTP ou HTTPS podem ser interceptados e tratados localmenteou podem ser feitos a uma maquina remota consoante se verificarem ou nao as condicoesexpressas no ponto 311 E representado um acesso a uma base de dados local (fornecidapelo Gears) mas a sua utilizacao e opcional

462 Implementacao do modo ldquoutilizador deciderdquo

Este modo de execucao foi ja descrito na seccao 421 e a sua principal carac-

terıstica e ser o utilizador a decidir se a aplicacao deve utilizar um servidor remoto

ou a maquina local como fornecedor de dados

Relativamente ao WOW o WOW Offline na vertente ldquoutilizador deciderdquo vem

alterar os seus casos de uso dando ao utilizador a possibilidade de alterar o estado

de execucao da aplicacao (entre online e offline) Resta dizer que no modo online se

mantem todas as funcionalidades anteriores e que no modo offline torna-se possıvel

visualizar os conteudos da pagina principal do WOW (Figura 46) e os detalhes das

ordens de trabalho (Figura 49) tal como expressa a Figura 410

Esta aproximacao foi utilizada na prova de conceito do WOW adicionando um

controlo a interface desta aplicacao que permite ao utilizador alternar entre os esta-

dos online e offline Na transicao de online para offline sao descarregados os recursos

necessarios para a execucao desta aplicacao sem recorrer a Internet Para o fazer

45

Desenvolvimento

Figura 48 Neste exemplo do modo ldquoaplicacao deciderdquo o teste da ligacao e feito e feito acada cinco segundos O resultado deste teste nao reflecte sempre o estado real da aplicacaopodendo levar a aplicacao a ter comportamentos indesejaveis Na figura assinala-se umperıodo de tempo no qual a representacao interna do estado da ligacao nao corresponde arealidade

e utilizado um recurso ResourceStore e um ManagedResourceStore (introduzidos

em 311) O primeiro e utilizado para armazenar a pagina principal do WOW ndash do-

ravante designada por homejsp ndash e o segundo e utilizado para armazenar imagens

folhas de estilo CSS e scripts JavaScript

Para a implementacao deste modo de execucao foram identificadas as seguintes

tarefas

1 Guardar informacao que permita a recriacao das paginas que se pretende

disponibilizar offline (utilizando o Gears)

2 Disponibilizar um controlo que permita alterar o estado de execucao atraves

da interaccao com a pagina principal

3 Durante a sincronizacao de dados apresentar o progresso da transferencia de

dados

O primeiro passo consistiu na identificacao de todos os conteudos que sao necessarios

transferir para a execucao offline Foi utilizado um recurso do Gears do tipo

ManagedResourceStore que recorre a um ficheiro manifesto para identificar to-

dos os ficheiros que deve transferir Este recurso e gerido automaticamente pelo

Gears transferindo para o cliente a versao mais recente sempre que e necessario

isto e sempre que exista um ficheiro manifesto com uma identificacao de versao que

seja diferente da actualmente disponıvel no cliente Uma vez identificados todos

ficheiros necessarios para a execucao offline num (ou mais) ficheiros manifesto o

Gears encarrega-se da sua actualizacao mas o preenchimento destes ficheiros man-

ifesto e manual o que se traduz num cuidado extra na manutencao da aplicacao

A forma como esta informacao e guardada deve tambem ser cuidadosamente

estudada A opcao mais flexıvel passa por utilizar o modulo Database apresentado

na seccao 311 e guardar a informacao de uma forma relacional Para a recriacao

das paginas pode ser disponibilizada uma versao HTML da pagina que funciona

46

Desenvolvimento

Figura 49 Pagina de visualizacao do detalhe de uma ordem de trabalho

como template nao possui quaisquer dados e e utilizada apenas em modo offline E

preenchida para cada pedido retirando os dados relevantes da base de dados

O modelo de dados do WOW torna esta opcao extremamente trabalhosa uma

vez que as entidades envolvidas na geracao de cada pagina de informacao sobre

cada ordem de trabalho tem relacoes de dependencia complexas seguindo padroes

muito variaveis Por exemplo em cada ordem de trabalho existe um formulario que

permite a sua progressao de estado com diversos campos opcionais e obrigatorios

este formulario e definido pelo administrador e esta relacionado nao apenas com o

tipo de ordem de trabalho mas tambem com o estado actual em que esta se encontra

e a accao que se pretende realizar O elevado numero de combinacoes de tipos de

ordem de trabalho estados e accoes que existem num dado momento juntamente

com a sua possibilidade de alteracao obrigariam a implementacao de uma logica de

negocio complexa o que esta fora do ambito deste projecto

47

Desenvolvimento

Figura 410 Esquema UML que expressa os casos de uso do WOW Offline no modoldquoutilizador deciderdquo

463 Especificacao do modo ldquoaplicacao assume o estado offlinerdquo

A aproximacao para o modo ldquoaplicacao assume o estado offlinerdquo foi tambem

dividida em varias tarefas

1 Guardar informacao que permita a recriacao da pagina principal do lado do

cliente no estado offline (utilizando o Gears)

2 Dotar a aplicacao do cliente de um mecanismo de deteccao da ligacao

3 Identificar os ldquomomentos chaverdquo em que devera ocorrer sincronizacao de dados

4 Implementar a sincronizacao de dados

A sincronizacao de dados deve ser feita em ambas as transicoes online-offline e

offline-online quer para transferir novos dados do servidor (os pedidos podem ser

alterados por outros utilizadores) quando se transita do estado quer para comunicar

eventuais alteracoes feitas em modo offline

Relativamente ao WOW o WOW Offline na vertente ldquoaplicacao assume o es-

tado offlinerdquo vem alterar os seus casos de uso dando ao utilizador a possibilidade

de activar esta funcionalidade A partir do momento que a funcionalidade esta ac-

tivada o utilizador deve tambem ter a possibilidade de gerir algumas preferencias

relacionadas com privacidade de dados Devera ter a hipotese de desactivar o ar-

mazenamento local e de remover todos os dados ja armazenados tal como descrito

na Figura 411

48

Desenvolvimento

Figura 411 Esquema UML que expressa os casos de uso do WOW Offline no modoldquoutilizador deciderdquo

A primeira vez que o WOW Offline e acedido por um cliente e caso seja detec-

tada a presenca do Gears todos os recursos necessarios a sua execucao sao trans-

feridos Todos os acessos posteriores serao feitos a estes recursos locais (recorda-se

que o Gears pode ser utilizado para os manter actualizados recorrendo ao Managed-

ResourceStore 311)

Atraves do JavaScript e possıvel interceptar os eventos de load e unload da

pagina que sao despoletados sempre que ocorre um re-acesso da mesma (incluindo

a accao refresh comum dos browsers) sempre que esta e abandonada ou ainda ou

ainda se a janela for encerrada

Tal como sugerido na seccao 462 a camada de interface desta aplicacao (cada

pagina individual em HTML) devera ser implementada como sendo um template

para apresentacao de dados sendo totalmente preenchida atraves de funcoes em

JavaScript O objectivo deste ponto e criar um padrao de dados que permita ao

JavaScript preencher os dados em cada pagina (template) independentemente de

qual seja a fonte ndash o servidor remoto ou a maquina local tal como exemplificado

no diagrama da Figura 412 Na figura a aplicacao recorre ao servidor remoto para

obter os dados pretendidos quando se encontra na presenca de uma ligacao mas

para dados que exijam uma carga de processamento pelo servidor este acto pode ser

49

Desenvolvimento

Figura 412 Esquema UML que expressa o acto de recolha de dados em modo online eoffline recorrendo ao servidor (modo online) e ao sistema de armazenamento de dadoslocal fornecido pelo Gears (modo offline)

substituıdo pelo envio de um campo de controlo que se destina a aferir se os dados

locais se encontram actualizados No caso de estarem actualizados a comunicacao

com o servidor pode ser substituıda por uma query a base de dados local

50

Capıtulo 5

Resultados e Futuros

Desenvolvimentos

Todo o estudo feito sobre o tema OWA foi ja abordado ao longo do documento

Neste capıtulo apresentam-se os resultados obtidos na implementacao da prova de

conceito que visava compreender a melhor forma de disponibilizar uma versao of-

fline no WOW uma plataforma de gestao de ordens de trabalho ja existente de-

senvolvida pela Critical Software SA

51 Resultados Obtidos

Os resultados obtidos neste projecto sao extremamente satisfatorios uma vez

que o estudo do tema OWA e a implementacao de uma prova de conceito que o

ilustrasse foi conseguido com sucesso

A funcionalidade offline foi adicionada ao produto WOW da Critical Software

SA permitindo a visualizacao de ordens de trabalho e dos seus detalhes mesmo na

ausencia de uma conexao activa a Internet Embora para a solucao implementada

tenha sido utilizada uma abordagem do tipo ldquoutilizador deciderdquo pretende-se que esta

seja convertida para ldquoaplicacao deciderdquo ou mesmo para uma aproximacao hıbrida

semelhante a utilizada pelas aplicacoes estudadas nas seccoes 351 e 352

Para a sua implementacao descrita no capıtulo 4 foram tomadas decisoes de or-

dem pratica que permitissem tornar o trabalho exequıvel nos prazos dados Tentou-

se sempre que estas decisoes afectassem o mınimo em termos de desempenho e de

experiencia para o utilizador Considera-se que a implementacao do modo offline

com uma transicao entre modos do tipo ldquoutilizador deciderdquo (ver seccao 42) reflecte

o compromisso entre o desempenho pretendido e os recursos disponıveis e para alem

51

Resultados e Futuros Desenvolvimentos

de ser um exemplo eficaz das possibilidades que as OWA podem trazer a aplicacao

WOW desenvolvida pela Critical Software e tambem um estudo que pode ser uti-

lizado para analisar a implementacao desta tecnologia noutros produtos da mesma

empresa

Note-se que o principal objectivo do trabalho era ganhar familiaridade com este

tema entender as suas vantagens e desvantagens e compreender as suas limitacoes

Tudo indica que existam varias possibilidades de implementacao deste paradigma

noutros produtos da Critical Software que pela sua natureza podem tambem tirar

partido da execucao offline

52 Trabalho Futuro

O desenvolvimento do conceito e formas de implementacao de OWA continua

em forte desenvolvimento no entanto a sua adopcao ainda nao e generalizada A

dificuldade da sua implementacao em web applications ja existentes e o principal

obstaculo a sua maior divulgacao

Ha tambem um factor que deve ser tido em consideracao a manutencao de

codigo A implementacao de uma versao offline de uma web application requer

a implementacao das mesmas regras de negocio (ou de uma versao simplificada)

utilizadas no servidor Para que isto seja possıvel e necessario ter em conta a

capacidade de processamento do cliente e o factor de duplicacao de codigo que

tornara a aplicacao mais difıcil de manter uma vez que uma alteracao a logica de

negocio do servidor implica tambem uma alteracao a sua versao offline

A prova de conceito implementada permite ja a visualizacao offline dos pedidos

abertos (enviados e recebidos) que constam na pagina principal (este numero e

fixo e pode ser alterado pelo administrador) Uma funcionalidade desejavel seria a

possibilidade de interaccao com a aplicacao em modo offline e sincronizacao com o

servidor quando existisse uma ligacao disponıvel

Foi estudada a utilizacao do modo de execucao ldquoaplicacao assume o estado of-

flinerdquo descrito em 423 e esta seria a forma desejavel para o WOW Offline no

entanto para que esta opcao seja viavel sera necessaria a implementacao de uma

forma eficiente de sincronizacao e armazenamento de dados de uma forma relacional

Para atingir este objectivo podera ser seguida uma polıtica de automacao do pro-

cesso no qual a versao online da aplicacao gera scripts de criacao para as tabelas

necessarias na base de dados da versao offline (nao existe nenhuma ferramenta para

o fazer portanto seria necessaria a sua implementacao) e no qual as paginas HTML

disponibilizadas pelo servidor aos clientes web (browser) servem como templates de

apresentacao de informacao e sao preenchidas de forma semelhante pelo servidor ndash

quando a aplicacao estiver online ndash ou pelo cliente atraves de funcoes em JavaScript

52

Resultados e Futuros Desenvolvimentos

ndash quando a aplicacao estiver offline No entanto no WOW devido a quantidade de

informacao tratada e devido as complexas relacoes entre as diferentes entidades e

de esperar que a complexidade da implementacao de um mecanismo deste tipo torne

esta aproximacao demasiado custosa

O HTML 5 embora um forte candidato ainda nao esta suficientemente desen-

volvido A sua especificacao ainda tem o caracter de Draft (rascunho) e esta sujeita

a modificacoes e a aceitacao e implementacao por parte dos browsers e portanto

de momento foi desconsiderado No entanto no futuro se esta especificacao atingir

um estado de maturidade que permita a sua adopcao devera ser considerada como

um possıvel caminho a seguir

53

Resultados e Futuros Desenvolvimentos

54

Capıtulo 6

Conclusoes

Neste capıtulo sao apresentadas as conclusoes do projecto e consideracoes finais

relativamente a tecnologia estudada

61 Conclusoes

O rapido desenvolvimento tecnologico faz prever que a disponibilidade de ligacao

a Internet seja cada vez mais facil e mais rapido mas vao continuar a existir lugares

onde o acesso e limitado e onde as OWA podem desempenhar um papel de relevo

Por outro lado esta tecnologia pode tambem ser utilizada para melhorar o desem-

penho de paginas web com uma necessidade elevada de imagens ou outros recursos

dispendiosos em termos de espaco e foram ate estudados dois exemplos da utilizacao

desta vertente desta tecnologia em 353

Acredita-se que as OWAs vem responder a uma necessidade real por parte das

web applications actuais e que a evolucao que representam se compara a que se

assistiu dos thin-clients para os fat-clients em termos de autonomia do servidor

A capacidade de oferecer conteudos dinamicos no browser independentemente da

existencia de uma ligacao reune as vantagens tıpicas das web applications como

ausencia de instalacao e actualizacoes instantaneas com as vantagens das aplicacoes

de desktop em capacidade de processamento e armazenamento de dados na maquina

local

As tecnologias disponıveis ate a data estudadas no ambito deste projecto que

permitem o desenvolvimento de OWAs e que apresentam maior maturidade sao o

Gears e o Adobe AIR Ambas se apresentam sobre a forma de plugins que necessitam

de uma instalacao extra para poderem ser utilizadas Apesar de esta instalacao ser

55

Conclusoes

apenas necessaria uma vez podera constituir um factor de desencorajamento a sua

adopcao

O HTML 5 uma especificacao abordada neste documento na seccao 34 podera

ser uma alternativa que oferece funcionalidades offline a uma web application sem a

necessidade de qualquer instalacao no entanto esta especificacao ainda nao foi aceite

pelos principais browsers ndash o documento que define o HTML 5 ainda tem o estatuto

de Draft ndash e ainda nao e possıvel antecipar quando e que isto podera acontecer

Um dos problemas que surge frequentemente na implementacao de uma versao

offline para uma web application e a necessidade de sincronizacao de dados Quando

a informacao pode ser alterada por varios utilizadores simultaneamente e necessario

prever os conflitos que daı podem surgir e dotar a aplicacao de uma forma de os

resolver ou alertar o utilizador para a necessidade de alteracao dos dados

Em conclusao todos os objectivos propostos para este projecto foram atingidos

A prova de conceito implementada reflecte de forma clara as possibilidades oferecidas

pela tecnologia OWA e sera utilizado no futuro para compreender a melhor forma

de o implementar de forma definitiva no WOW

56

Referencias

[Ada08] Lucas Adamski Introducing Adobe AIR security model Fevereiro de2008 Disponıvel em httpwwwadobecomdevnetairarticles

introduction_to_air_securityhtml acedido em Marco de 2008

[Ado08] Adobe Adobe AIR 10 Security White Paper 2008 Disponıvel emhttpdownloadmacromediacompubairdocumentation1air_

securitypdf acedido em Marco de 2008

[Alm08] Dion Almaer Gears as a bleeding-edge html 5 implementa-tion March 2008 Disponıvel em httpalmaercomblog

gears-as-a-bleeding-edge-html-5-implementation acedido emMarco de 2008

[BL96] Tim Berners-Lee The world wide web Past present and future Agostode 1996 Disponıvel em httpwwww3orgPeopleBerners-Lee

1996ppfhtml acedido em Abril de 2008

[CDGH08] Mike Chambers Daniel Dura Dragos Georgita and Kevin Hoyt AdobeAIR for JavaScript Developers OrsquoReilly Media 2008 Disponıvel emhttponairadobecomfilesAIRforJSDevPocketGuidepdf ace-dido em Abril de 2008

[Con99] Jim Conallen Modeling Web Application Architectures with UML Junho1999 Disponıvel em httpwwwumlorgcnUMLApplicationpdf

webappspdf acedido em Maio de 2008

[Ent07] Entrust What is a public key information 2007 Disponıvel em http

wwwentrustcompkihtm acedido em Junho de 2008

[Gar05] Jesse James Garret Ajax A new approach to web applicationsFebruary 2005 Disponıvel em httpwwwadaptivepathcomideas

essaysarchives000385php acedido em Marco de 2008

[Greon] Philip Greenspun Philip and Alexrsquos Guide to Web Publishing 2003(last revision) Disponıvel em httpphilipgreenspuncompandaacedido em Junho de 2008

[Gro02a] App Design Group Thick vs thin client comparison 2002 Disponıvelem httpwwwdonjacobsvwcomimagesweekendspecials

Thick-vs-Thinpdf acedido em Junho de 2008

57

REFERENCIAS

[Gro02b] Technical Research Group Thin Client Tecnhology - WhitePaper 2002 Disponıvel em httpwwwpicktrgcompubs

thinclientwhitepaperpdf acedido em Junho de 2008

[Gro08] Miniwatts Marketing Group World internet usage March 2008Disponıvel em httpwwwinternetworldstatscomstatshtm ace-dido em Abril de 2008

[Hic08] Ian Hickson HTML 5 Draft Recommendation 2008 Disponıvelem httpwwwwhatwgorgspecsweb-appscurrent-work ace-dido em Marco de 2008

[Kha] Olga Kharif Top 10 municipal wifi plans Disponıvel em http

imagesbusinessweekcomss0608muni_wifiindex_01htm ace-dido em Marco de 2008

[Lab07] Mozilla Labs Prism Outubro 2007 Disponıvel em httplabs

mozillacom200710prism acedido em Marco de 2008

[Loo06] Chris Loosley Rich Internet ApplicationsDesign MeasurementandManagement Challenges 2006 Disponıvel em httpwwwkeynote

comdocswhitepapersRichInternet_5pdf acedido em Maio de2008

[Mic08] Microsoft Introduction to Occasionally Connected Applications us-ing Sync Services for ADONET 2008 Disponıvel em httpmsdn

microsoftcomen-ussyncbb887608aspx acedido em Junho de2008

[Nao08] Erica Naone Offline web applications Abril 2008 Disponıvelem httpwwwtechnologyreviewcomread_articleaspxch=

specialsectionsampsc=emerging08ampid=20245 acedido emAbril de 2008

[NJN00] Jason Nieh Yang S Jae and Naomi Novik A comparison of thin-clientcomputing architectures 2000 Disponıvel em httpwwwnclcs

columbiaedupublicationscucs-022-00pdf acedido em Maio de2008

[OrsquoR06] Tim OrsquoReilly Web 20 compact definition Trying again Dezembro2006 Disponıvel em httpradaroreillycomarchives200612

web-20-compact-definition-tryihtml acedido em Marco de 2008

[OrsquoR09] Tim OrsquoReilly What is Web 20 Design patterns and business modelsfor the Next Generation of Software 20053009 Disponıvel emhttpwwworeillynetcompubaoreillytimnews200509

30what-is-web-20html acedido em Marco de 2008

[Rus06] Alex Russel Comet Low latency data for the browser March Marco2006 Disponıvel em httpalexdojotoolkitorgp=545 acedidoem Marco de 2008

58

REFERENCIAS

[Sad97] Darleen Sadoski Clientserver software architecturesndashan overviewAgosto 1997 Disponıvel em httpwwwseicmuedustr

descriptionsclientserver_bodyhtml acedido em Junho de2008

[Sch96] George Schussel Clientserver past present and future 1996

[Smi07] Kevin C Smith Css filters - will the browser apply the rule July 2007Disponıvel em httpcentriclecomrefcssfilters acedido emMarco de 2008

[vK08] Anne van Kesteren The XMLHttpRequest Object W3C Work-ing Draft 15 Abril 2008 Disponıvel em httpwwww3orgTR

XMLHttpRequest acedido em Abril de 2008

[Wil06] Greg Wilkins Why ajax comet July Julho 2006 Disponıvel emhttpwwwwebtidecomdownloadswhitePaperWhyAjaxhtml ace-dido em Abril de 2008

59

REFERENCIAS

60

Anexo A

Screenshots

Algumas imagens de aplicacoes que utilizam funcionalidades offline ilustrativasda tecnologia abordada neste documento

Figura A1 Dialogo apresentado ao utilizador na primeira activacao das funcionalidadesoffline no Google Docs amp Spreadsheets

61

Screenshots

Figura A2 Na activacao das funcionalidades offline e tambem oferecida a possibilidadeda criacao de alguns atalhos por exemplo no ambiente de trabalho

Figura A3 O Google Docs mantem a todo o momento a possibilidade de alteracao destasdefinicoes ou da anulacao dos servicos offline para um dado computador

62

Screenshots

Figura A4 Apos a instalacao do Gears qualquer visita ao Remember The Milk despoletauma sincronizacao que ocorre automaticamente e sem necessidade de intervencao por partedo utilizador

Figura A5 Apos completar a sincronizacao de dados mesmo que a ligacao a Internetseja perdida o Remember the Milk continua disponıvel no browser (com excepcao dasfuncionalidades que pela sua natureza exigem uma ligacao como por exemplo partilhade tarefas e envio de convites)

63

Page 10: O ine Web Applications

Conteudo

1 Introducao 111 Enquadramento 112 Motivacao 213 Ambito 314 Objectivos 315 Estrutura do documento 3

2 Enquadramento do Projecto 521 Evolucao das arquitecturas de software 5

211 Thin-clients 5212 Fat-clients 6213 Arquitecturas cliente-servidor 7

22 Evolucao na Internet 8221 Paginas web estaticas 9222 Paginas web interactivas e paginas web dinamicas 9223 Web 20 e Ajax 11

23 Offline Web Applications 1324 Comparacao 13

3 Estado da arte 1731 Gears 17

311 Arquitectura 17312 Goggle Gears em dispositivos moveis 20

32 Adobe AIR 20321 Seguranca 22322 Assinatura do codigo 22

33 Mozilla Prism 23331 XML User Interface Language 23332 Prism 25

34 HTML 5 2535 Web applications que usam funcionalidades offline 26

351 Google Reader e Google Docs 26352 Remember the Milk 27353 MySpace e WordPresscom 27

36 Escolha da tecnologia 28

vii

CONTEUDO

4 Desenvolvimento 3341 Como ficar offline 33

411 Funcionalidades disponıveis em modo offline 3442 Modos de execucao 35

421 Modo ldquoutilizador deciderdquo 36422 Modo aplicacao decide 36423 Modo ldquoaplicacao assume o estado offlinerdquo 37

43 Sincronizacao de dados 38431 Quando sincronizar 39

44 WOW 4045 Visao geral sobre a arquitectura do WOW 4146 WOW Offline 42

461 Modo ldquoaplicacao deciderdquo com deteccao automatica da ligacao 43462 Implementacao do modo ldquoutilizador deciderdquo 45463 Especificacao do modo ldquoaplicacao assume o estado offlinerdquo 48

5 Resultados e Futuros Desenvolvimentos 5151 Resultados Obtidos 5152 Trabalho Futuro 52

6 Conclusoes 5561 Conclusoes 55

Referencias 59

A Screenshots 61

viii

Lista de Figuras

21 Arquitectura de um sistema thin-client em duas camadas (a esquerda)e em tres camadas (a direita) Note-se a inclusao do servidor (main-frame) na definicao das camadas desta arquitectura devido a fortedependencia cliente-servidor 9

22 Arquitectura de um fat-client em duas camadas (a esquerda) e emtres camadas (a direita) 10

23 Comparacao do modelo de web aplications sıncrono paginas estaticase interactivas abordados nas seccoes 221 e 222 com o modelo deweb applications Ajax (assıncrono) abordado na seccao 223 Figuraadaptada de http www adaptivepath com 15

31 Esquema UML do processo efectuado pelos recursos do Gears do tipoManagedResourceStore para a actualizacao dos conteudos definidosno ficheiro manifesto 29

41 Exemplo de uma arquitectura de uma web application sem uma ca-mada de abstraccao de dados Figura adaptada de http gears

google com 33

42 Exemplo de uma arquitectura de uma web application com uma ca-mada de abstraccao de dados Figura adaptada de http gears

google com 34

43 Exemplo de uma arquitectura de uma web application com uma ca-mada de abstraccao de dados e um data switch Figura adaptada dehttp gears google com 35

44 Esquema grafico ilustrando uma OWA executando no browser uti-lizando um modo de execucao do tipo ldquoaplicacao deciderdquo com de-teccao automatica do estado da ligacao via pedidos Ajax assıncronosa cada cinco segundos 37

45 Detalhe de um conjunto possıvel de estados e respectivas transicoespara uma dada ordem de trabalho no WOW desde a sua submissaono sistema ate a sua conclusao em fecho ou cancelamento Esta figurarepresenta apenas um exemplo ja que o mapa de estados para umaordem de trabalho e dinamico e pode ser alterado por um admin-istrador Figura retirada de uma brochura promocional do WOWCritical Software SA 41

ix

LISTA DE FIGURAS

46 A pagina inicial do WOW apresenta um resumo das ultimas ordensde trabalho enviadas e recebidas Na imagem pode-se observar atransicao do estado online para offline 44

47 Ilustracao do funcionamento do Gears numa web application que uti-liza um motor Ajax Os pedidos HTTP ou HTTPS podem ser inter-ceptados e tratados localmente ou podem ser feitos a uma maquinaremota consoante se verificarem ou nao as condicoes expressas noponto 311 E representado um acesso a uma base de dados local(fornecida pelo Gears) mas a sua utilizacao e opcional 45

48 Neste exemplo do modo ldquoaplicacao deciderdquo o teste da ligacao e feitoe feito a cada cinco segundos O resultado deste teste nao reflectesempre o estado real da aplicacao podendo levar a aplicacao a tercomportamentos indesejaveis Na figura assinala-se um perıodo detempo no qual a representacao interna do estado da ligacao nao cor-responde a realidade 46

49 Pagina de visualizacao do detalhe de uma ordem de trabalho 47410 Esquema UML que expressa os casos de uso do WOW Offline no

modo ldquoutilizador deciderdquo 48411 Esquema UML que expressa os casos de uso do WOW Offline no

modo ldquoutilizador deciderdquo 49412 Esquema UML que expressa o acto de recolha de dados em modo

online e offline recorrendo ao servidor (modo online) e ao sistemade armazenamento de dados local fornecido pelo Gears (modo offline) 50

A1 Dialogo apresentado ao utilizador na primeira activacao das funcional-idades offline no Google Docs amp Spreadsheets 61

A2 Na activacao das funcionalidades offline e tambem oferecida a possi-bilidade da criacao de alguns atalhos por exemplo no ambiente detrabalho 62

A3 O Google Docs mantem a todo o momento a possibilidade de alteracaodestas definicoes ou da anulacao dos servicos offline para um dadocomputador 62

A4 Apos a instalacao do Gears qualquer visita ao Remember The Milkdespoleta uma sincronizacao que ocorre automaticamente e sem ne-cessidade de intervencao por parte do utilizador 63

A5 Apos completar a sincronizacao de dados mesmo que a ligacao aInternet seja perdida o Remember the Milk continua disponıvel nobrowser (com excepcao das funcionalidades que pela sua naturezaexigem uma ligacao como por exemplo partilha de tarefas e enviode convites) 63

x

Lista de Tabelas

21 Comparacao entre thin-clients e fat-clients 7

31 Comparacao das funcionalidades oferecidas pelo Adobe AIR para asplataformas web e desktop 30

32 Resumo da utilizacao de tecnologias OWA em algumas web applica-tions consideradas na analise do estado da arte 31

xi

LISTA DE TABELAS

xii

Glossario

fat-client Cliente que nao depende totalmente de umservidor central para as suas actividadesde processamento e possui frequentementedispositivos de armazenamento de dados

6ndash8

thin-client Cliente que depende de um servidor centralpara as suas actividades de processamento

5ndash8

web application Sistema web (servidor rede HTTPbrowser) onde accoes do utilizador(navegacao e introducao de informacao)afectam o estado logico da aplicacao

i iii1ndash311ndash1517ndash1921ndash232728 3336ndash3842 5556

API Application Programming Interface 10 1718 2326 28

ASP Linguagem interpretada pelo servidorque permite a criacao de paginas webdinamicas Desenvolvida pela Microsoft

11

BSD Berkeley Software Distribution 28

CSS Cascading Style Sheets 12 2021 2324 46

DHTML Dynamic HyperText Transfer Protocol 24DOM Document Object Model 10 12

20 2324

DTD Document Type Definition 24

xiii

Glossario

ECMAScript Padrao de linguagem de programacaodefinido pela Ecma International que orig-inou o JavaScript e o JScript

24

Flash Conteudo interactivo de um ficheiro emformato SWF E desenvolvido pela Adobee visualizado atraves do Adobe FlashPlayer

21

Flex Framework baseada em XML e Action-Script desenvolvida pela Adobe para a pro-gramacao de Rich Internet Applications(RIA)

21

GPL GNU General Public License 23

HTML HyperText Markup Language 1 10ndash12 2124ndash2649

HTTP HyperText Transfer Protocol 2 26

JMS E uma API em Java que permite a troca demensagens entre componentes de software

42

JSON JavaScript Object Notation permite atroca de dados codificados num formatode texto de simples leitura

12 1828 34

LGPL GNU Lesser General Public License 23

Mozilla Prism Browser simplificado e ldquointerpretadorrdquo deeXtensible User Interface Language (XUL)(tambem designado por XULRunner) queacolhe web applications sem a interfacegrafica habitual de um browser

25

MPL Mozilla Public License 23

OCA Occasionally Connected Application 39OWA Offline Web Application i iii

2ndash515 1725 2628 3133 3651 5255 56

PDF Portable Document Format 21

xiv

Glossario

PHP Linguagem interpretada pelo servidorque permite a criacao de paginas webdinamicas mas que pode tambem ser in-vocada a partir da linha de comandos

11

pagina web estatica Pagina web que devolve sempre a mesmaresposta a todos os pedidos para todos osutilizadores e em qualquer contexto

5 9

RIA Rich Internet Applications web appli-cations que apresentam funcionalidadessemelhantes as desktop applications masque mantem a informacao no lado do servi-dor

5 1520 28

RSS Really Simple Syndication 27

SLA Service Level Agreement 40SQLite Segundo a definicao oficial SQLite is a

software library that implements a self-contained serverless zero-configurationtransactional SQL database engine

17

SSB Site Specific Browser 25SSL Secure Sockets Layer 22SWF ShockWave Flash 21

URL Uniform Resource Locator 18

VPN Virtual Private Network 38

WOW Work Orders Web Plataforma de gestaode ordens de trabalho e do seu fluxo de-senvolvida pela Critical Software SA

i iii28 3340ndash434551ndash5356

WWW World Wide Web 11 1214

XBL eXtensible Binding Language 24XHTML eXtensible HyperText Markup Language 12XML eXtensible Markup Language 11 12

23 2428

XSLT eXtensible Stylesheet Language Transfor-mation

12

XUL eXtensible User Interface Language xiv23ndash25

xv

Glossario

xvi

Capıtulo 1

Introducao

Neste capıtulo enquadra-se o tema do projecto introduzindo alguns dos conceitos

nos quais se baseia Apresentam-se as motivacoes ambito objectivos e a estrutura

deste documento

11 Enquadramento

A Internet foi originalmente concebida para ser um espaco de partilha de in-

formacao onde pessoas (atraves de maquinas) pudessem comunicar Na sua origem

as paginas eram estaticas constituıdas por texto formatado em HyperText Markup

Language (HTML) e ligadas entre si [BL96] Hoje encontramos conteudos cada vez

mais complexos e dinamicos incluindo som vıdeo ou streams multimedia [Loo06] e

em 2005 foi introduzido por [OrsquoR09] o termo Web 20

De acordo com [Greon] um website pode pertencer a uma ou varias das seguintes

categorias

bull Documento ndash um website essencialmente estatico onde alteracoes a uma

parte do conteudo nao tem implicacoes no seu comportamento

bull Base de dados ndash um directorio de informacao organizada em categorias

bull Aplicacao ndash um website dinamico que utiliza uma linguagem executada ou

interpretada do lado do servidor e que processa as accoes ou informacao in-

troduzida pelo utilizador para fornecer um servico ou nova informacao

A ultima destas categorias constitui aquilo que e normalmente designado por

web application O conceito utilizado ao longo deste documento e o mesmo que

o introduzido por Jim Coallen em [Con99] que define web application como um

1

Introducao

sistema web (servidor rede HyperText Transfer Protocol (HTTP) browser) onde

accoes do utilizador (navegacao e introducao de informacao) afectam o estado logico

da aplicacao A sua definicao tenta estabelecer que uma web application e um

sistema de software com estado de negocio1 e que a sua interface de interaccao com

o utilizador e distribuıdo atraves de um sistema web

12 Motivacao

A quantidade de informacao que e produzida e armazenada com recurso a es-

tas web applications disponıveis online tais como e-mail blogues ou mesmo docu-

mentacao tornam por vezes a disponibilidade de ligacao uma condicao necessaria

a produtividade e como consequencia desta barreira muitos potenciais utilizadores

opoem-se a adopcao de produtos web em detrimento das tradicionais desktop appli-

cations

Assegurar o acesso a uma ligacao de Internet e hoje muito mais facil A Internet

movel e ja uma realidade e encontra-se amplamente divulgada mas continuam a

existir diversas situacoes nas quais os utilizadores estao privados de uma ligacao

a Internet tais como uma viagem de metro ou de aviao ou quando se encontram

deslocados do seu paıs de origem e nao possuem nenhum plano de subscricao

Uma OWA consiste numa web application que para alem de manter todas as

caracterısticas anteriores se mantem disponıvel mesmo na ausencia de uma ligacao

a Internet e surge como uma tentativa de estreitar as barreiras existentes entre a

web e o desktop Isto significa que devera existir um mecanismo capaz de assegurar

a manutencao do estado logico da aplicacao quando a ligacao com o servidor e

quebrada permitindo ao utilizador continuar a utilizar a aplicacao e que sera capaz

de informar o servidor do estado em que a aplicacao se encontra quando a ligacao for

reposta A principal vantagem que advem desta possibilidade e evidente eliminar

a necessidade da existencia de uma ligacao a Internet para que a aplicacao possa ser

utilizada

Por outro lado a vontade de integracao de funcionalidades tıpicas das desktop

applications nas web applications foi um dos principais factores que impulsionou o

desenvolvimento deste conceito uma vez que obrigou a uma reflexao ldquopara alem

do browserrdquo e a uma adaptacao das arquitecturas existentes que permitisse ou o

acesso a funcionalidades disponibilizadas pelo sistema operativo ou pelo menos a

funcionalidades semelhantes Pretende-se com esta aproximacao tornar possıveis

interaccoes entre o desktop e o browser tais como arrastar um ficheiro para um

formulario web de upload de conteudos melhor suporte para o historico do clipboard

ou ainda o acesso ao sistema de ficheiros local Atingir estes objectivos reflecte-se

1NT business state

2

Introducao

num novo paradigma que reune as vantagens das web applications tais como os

updates instantaneos ou o facto de nao ser necessaria nenhuma instalacao e das

desktop applications como por exemplo persistencia no armazenamento de dados

acesso a funcionalidades do sistema operativo ou integracao e interaccao com outras

aplicacoes sejam elas web applications ou desktop applications

13 Ambito

Este projecto foi realizado na Critical Software SA no ambito do Mestrado

Integrado em Engenharia Informatica e Computacao (MIEIC) da Faculdade de En-

genharia da Universidade do Porto (FEUP) entre os meses de Fevereiro e Julho de

2008

14 Objectivos

Sao objectivos deste projecto

1 Estudar e documentar o tema das OWAs acompanhando os ultimos desenvolvi-

mentos nesta materia

2 Analisar o estado da arte fazendo uma analise crıtica e objectiva sobre as

diversas metodologias existentes

3 Implementar uma prova de conceito que permita a execucao offline de uma

web application documentando todo o processo

4 Estudar a possibilidade de permitir interaccao com a aplicacao (insercoes e

alteracoes aos dados) em modo offline

Em resumo o objectivo deste projecto foi estudar documentar e implementar

uma prova de conceito relacionada com o tema Offline Web Applications (OWA)

Este tema embora nao seja totalmente novo ganhou destaque ao longo do ano de

2007 com o surgimento de diversas ferramentas que se destinam a aproximar web

applications das desktop applications

15 Estrutura do documento

Este documento esta organizado em diferentes seccoes apresentando o projecto

numa sequencia logica organizada da seguinte forma

No capıtulo 1 faz-se uma breve apresentacao do conceito OWAs e do contexto em

que surge Apresenta-se tambem a estrutura do documento e definem-se os

termos e acronimos utilizados

3

Introducao

No capıtulo 2 faz-se uma descricao da evolucao das tecnologias que antecedem as

OWAs e das vantagens e desvantagens de cada uma como forma de enquadra-

mento

No capıtulo 3 analisa-se o estado da arte nesta materia Introduzem-se diversas

tecnologias directamente relacionadas com o tema deste projecto exemplos de

aplicacoes que as usam e as razoes que fundamentam as escolhas de tecnologias

efectuadas

O capıtulo 4 contem o desenvolvimento do projecto Analisa-se a plataforma

WOW de gestao integrada de ordens de trabalho a tecnologia escolhida e

a forma como foi utilizada para implementar a capacidade de execucao offline

O capıtulo 5 descreve os resultado obtidos comparando-os com as expectativas

iniciais do projecto e apresenta desenvolvimentos futuros e possibilidades de

continuacaoaplicacao do conhecimento adquirido

No capıtulo 6 apresentam-se as conclusoes

4

Capıtulo 2

Enquadramento do Projecto

Neste capıtulo apresenta-se um breve resumo da evolucao das arquitecturas de

software cliente-servidor e a forma como estas se comparam a evolucao da Inter-

net procurando estabelecer uma analogia entre o percurso de ambas as tecnolo-

gias Compara-se o comportamento e arquitectura dos thin-clients as paginas web

estaticas a evolucao dos fat-clients as paginas interactivas Web 20 e Ajax e

defende-se que as OWA constituem um proximo passo logico e evolutivo aproxi-

mando a web do desktop Referem-se ainda os principais factores que justificam a

importancia das OWAs e a estreita relacao que tem com as Rich Internet Application

(RIA)s

21 Evolucao das arquitecturas de software

Os termos thin-client e fat-client sao utilizados quer para descrever arquitecturas

logicas (de software) quer para descrever arquitecturas fısicas (de hardware) Neste

capıtulo excepto quando seja dada indicacao em contrario estes termos referem-se

sempre a uma arquitectura logica

Adicionalmente quando se trata de arquitecturas cliente-servidor pode-se estu-

dar a arquitectura desenvolvida do sistema como um todo da arquitectura do servi-

dor ou da arquitectura do cliente Para evitar equıvocos em especial na seccao 213

especifica-se em cada caso qual o sistema estudado

211 Thin-clients

Um thin-client e um computador cliente ou software cliente que no contexto

de uma arquitectura cliente-servidor depende de um servidor central para as suas

5

Enquadramento do Projecto

actividades de processamento e proporciona um canal de entrada e saıda de in-

formacao entre o utilizador e o servidor remoto Este termo quando aplicado a

hardware refere-se habitualmente a um computador que se destina a ser utilizado

como cliente de rede sem armazenamento local e com capacidade de processamento

reduzida [Gro02b] mas o conceito que aqui se analisa refere-se a uma arquitectura

de software que remonta ao inıcio das aplicacoes cliente-servidor

No inıcio da historia da computacao terminais ligavam-se directamente a main-

frames responsaveis por todo o processamento Nesta arquitectura era necessario

desenvolver duas aplicacoes distintas uma aplicacao central no servidor (main-

frame) responsavel pela gestao de toda a informacao e por todas as operacoes de

comunicacao e uma aplicacao de visualizacao instalada no cliente (terminal) O

papel destes terminais era apenas disponibilizar ao utilizador um meio de comu-

nicacao (entrada e saıda) e apresentacao dos resultados do servidor Nao tinham

um papel activo no calculo nem na logica de negocio e frequentemente nao tinham

tambem nenhum mecanismo de armazenamento de dados

Como vantagens esta arquitectura apresenta uma reduzida necessidade de con-

figuracao e manutencao do lado do cliente Uma vez que o centro do processamento

e manipulacao de dados ocorre no servidor existe tambem uma centralizacao da

informacao [NJN00] que introduz um ponto crıtico de falha1 Actualizacoes e novas

funcionalidades sao faceis de distribuir uma vez que requerem apenas alteracoes no

servidor [Gro02a]

212 Fat-clients

Contrastando com os thin-clients nesta arquitectura os clientes implementam

ja uma parte da logica de negocio e sao responsaveis pelo processamento de dados

Estes fat-clients vieram responder a necessidade crescente de aplicacoes com um

nıvel de interactividade e capacidade de configuracao maior que as oferecidas pela

arquitectura thin-client descrita na seccao 211 Apesar de manterem a sua de-

pendencia do servidor podem tambem ser executados sem uma conexao activa uma

vez que dispoe de armazenamento de dados local o que lhes confere a capacidade

de persistencia de dados e do estado de execucao entre cada sessao

Foi disponibilizando este controlo sobre o estado da aplicacao bem como acesso

a recursos locais (por exemplo sistema de ficheiros e perifericos) que surgiram as

primeiras verdadeiras desktop applications No entanto cada cliente tinha que ser

separadamente instalado no computador pessoal de cada utilizador que pretendesse

utilizar ou interagir com a aplicacao e uma actualizacao ao servidor implicava in-

variavelmente uma actualizacao manual tambem no cliente Uma vez que nem todos

1NT single point of failure

6

Enquadramento do Projecto

Thin-clients Fat-clientsNao toma parte no processamento dedados nem possui acesso ao sistema deficheiros

Participa activamente no processa-mento de dados recorrendo ao sis-tema de armazenamento local para ar-mazenamento de dados

Nao mantem registo do estado logicoda aplicacao entre duas sessoes de uti-lizacao

O acesso ao armazenamento localpermite-lhe manter registo do estadologico da aplicacao entre duas sessoes

O thin-client nao necessita de qualquerinstalacao estando ldquopronto a utilizarrdquo

E geralmente necessario instalar aaplicacao para poder interagir com oservidor

Qualquer update no servidor reflecte-seimediatamente por todos os clientes

Embora a aplicacao cliente possa aler-tar para existencia de novas versoes asactualizacoes tem que ser manualmenteinstalados pelo cliente

O software do cliente destina-se apenasa apresentacao de dados e comunicacaocom o servidor sendo portanto de sim-ples implementacao

Como o software do cliente toma parteactiva no processamento de dadosa sua implementacao requer cuidadosadicionais

Grande mobilidade uma vez que todaa informacao e mantida no servidor

Parte da informacao podera estar ape-nas do lado cliente pelo que existemalgumas restricoes a sua mobilidade

Tabela 21 Comparacao entre thin-clients e fat-clients

os utilizadores actualizam regularmente as suas aplicacoes o servidor tem que estar

preparado para lidar com versoes antigas2 ou descontinuar os seus servicos a uma

parte da sua comunidade de utilizadores ate que estes actualizem os seus sistemas

Como os utilizadores passam a utilizar os seus recursos locais para armazenamento

de dados as alteracoes que nao sejam sincronizadas com o servidor estao apenas

disponıveis nos seus computadores pessoais o que introduz uma restricao a mobili-

dade

Pode-se afirmar que as vantagens dos thin-clients sao as desvantagens dos fat-

clients e que as vantagens dos fat-clients sao as vantagens dos thin-clients tal como

se ilustra na Tabela 21

213 Arquitecturas cliente-servidor

Introduzidos os termos thin-client e fat-client interessa reafirmar que ambos

podem ser vistos como arquitecturas cliente-servidor Um cliente define-se como

um solicitador de servicos e um servidor como um prestador de servicos tal como

definido por [Sch96] e [Sad97]

2NT backward compatibility

7

Enquadramento do Projecto

As arquitecturas cliente-servidor sao categorizadas pela modularizacao com que

sao desenhadas sendo consideradas as seguintes camadas

1 Interface grafica (front-end) atraves da qual os utilizadores interagem com

a aplicacao Quando este modulo e implementado separadamente dos outros

dois constitui uma aplicacao thin-client por si so uma vez que nao implementa

regras de negocio (embora possa definir validacoes de formularios de insercao de

dados por exemplo) A informacao introduzida pelo utilizador e enviada para

o servidor que processa o seu pedido e retorna uma resposta Este processo

repete-se ate que o utilizador atinja o seu objectivo ou se desligue do sistema

2 A logica de negocio tambem designada por camada intermedia que imple-

menta as regras de aceitacao e validacao de todos os dados introduzidos pelo

utilizador E tambem a plataforma de comunicacao que une a camada superior

de visualizacao com a camada de acesso a dados

3 A camada de dados inclui quer o sistema de persistencia de dados onde sao

armazenados os dados relevantes como tambem os mecanismos necessarios

para a sua pesquisa seleccao e alteracao

Os thin-clients quando observados no seu conjunto de cliente e servidor podem

ser vistos quer como sistemas de duas camadas quer como sistemas de tres camadas

dependendo apenas da forma como o servidor for implementado No caso de na

implementacao do servidor nao se distinguir a camada de acesso a dados da camada

da logica de negocio sao designados por sistemas de duas camadas Caso seja feita

esta distincao sao designados por sistemas de tres camadas Ambos os casos sao

ilustrados na Figura 21

Historicamente os fat-clients eram implementados numa arquitectura em duas

camadas Possuıam apenas um modulo de visualizacao de dados designado por

camada de interface e um modulo que implementava toda a logica de negocio e

regras de acesso a base de dados No entanto com a introducao de ligacoes mais

rapidas e de computadores pessoais com maior capacidade de processamento e so-

bretudo devido a complexidade crescente das aplicacoes a logica de negocio e a

camada de acesso a dados tornaram-se independentes Este modelo e designado por

arquitectura em tres camadas e e ilustrado na Figura 22

22 Evolucao na Internet

Ao analisar a evolucao das arquitecturas das aplicacoes desenvolvidas para a

Internet podemos encontrar um paralelismo com a historia da arquitectura de soft-

ware

8

Enquadramento do Projecto

Figura 21 Arquitectura de um sistema thin-client em duas camadas (a esquerda) e emtres camadas (a direita) Note-se a inclusao do servidor (mainframe) na definicao dascamadas desta arquitectura devido a forte dependencia cliente-servidor

221 Paginas web estaticas

Uma pagina web estatica devolve sempre a mesma resposta a todos os pedidos

para todos os utilizadores e em qualquer contexto utilizando o hipertexto como

forma de ligacao entre diversas paginas estaticas

A informacao e armazenada num servidor e o papel do cliente e apenas a apre-

sentacao da informacao Esta forma de disponibilizacao de informacao pode assim

ser comparada com os thin-clients descritos na seccao 211 o utilizador acede a

um website estatico para visualizar informacao sem que o cliente tome parte no

processamento A unica diferenca e que no caso da web estatica a informacao ap-

resentada e sempre a mesma enquanto que nos thin-clients era frequente existir a

possibilidade de insercao de dados no cliente e apos o seu processamento servidor

nova informacao poderia ser apresentada O hipertexto e utilizado para ligar as

paginas entre si numa rede de conteudos relacionados e a navegacao sıncrona era

feita atraves de cliques do rato a cada clique uma nova pagina era apresentada

Este modelo sıncrono e ilustrado na Figura 23

222 Paginas web interactivas e paginas web dinamicas

O JavaScript e uma linguagem interpretada de scripting que tem os browsers

como principal ambiente de acolhimento Os browsers utilizam uma Application

9

Enquadramento do Projecto

Figura 22 Arquitectura de um fat-client em duas camadas (a esquerda) e em tres camadas(a direita)

Programming Interface (API) publica para criar ldquoobjectosrdquo responsaveis por reflectir

e disponibilizar o Document Object Model (DOM) para o motor de JavaScript

A utilizacao mais frequente desta linguagem e a escrita de funcoes que sao em-

bebidas ou incluıdas em paginas web e que interagem com o DOM Uma vez que o

JavaScript e executado localmente (na maquina do cliente e nao no servidor) e capaz

de responder rapidamente a accoes do utilizador tornando a execucao de aplicacoes

no browser mais fluıdas o JavaScript pode tambem detectar accoes do utilizador

que o HTML nao pode tal como o pressionar de uma tecla

Em Dezembro de 1995 a Netscape Communications adicionou suporte para o

JavaScript no browser Netscape Navigator3 e em Agosto de 1996 o browser Internet

Explorer4 da Microsoft passou a tambem a suportar uma versao semelhante desta

linguagem (hoje todos os principais browsers suportam esta tecnologia)

Esta inovacao permitiu tornar os websites mais interactivos mas a sua utilizacao

esteve confinada apenas a este proposito durante um longo perıodo As paginas

passaram a responder activamente a accoes do utilizador (sendo uma das utilizacoes

3Netscape Communications ndash httpbrowsernetscapecom4Microsoft Internet Explorer ndash httpwwwmicrosoftcomwindowsproductswinfamilyie

10

Enquadramento do Projecto

mais vulgares a validacao de formularios) mas continuaram essencialmente estaticas

O JavaScript ainda nao era nesta altura utilizado para processar dados

Tambem nesta altura (1995ndash96) surgiram linguagens server-side como o PHP

Hypertext Preprocessor (PHP) e Active Server Pages (ASP) e o servidor passou a ter

um processamento de dados introduzidos pelo utilizador mais activo Generalizaram-

se as paginas dinamicas capazes de responder a insercao de dados ou outros pedidos

determinados por accoes do utilizador As paginas tornaram-se aplicacoes web ap-

plications

Uma definicao tradicional de web application e um conjunto de paginas web

logicamente agrupadas e geridas por uma unica entidade que tem como pontos de

entrada formularios de insercao de dados (web forms) Uma web application nao e

mais do que uma aplicacao que e acedida atraves de um browser Tem geralmente

uma arquitectura logica em tres (interface logica de negocio e camada de dados)

camadas e estao armazenadas num servidor

Ha dois tipos de web applications

bull Orientadas a apresentacao Sao web applications que geram paginas web in-

teractivas constituıdas por varios tipos de linguagens de anotacao (por exem-

plo HTML eXtensible Markup Language (XML)) e que apresentam conteudo

dinamico como resposta a pedidos efectuados pelo utilizador

bull Orientadas aos servicos Uma web application orientada aos servicos imple-

menta o ponto de acesso para um ou mais de um web service Sao geralmente

clientes de service oriented web applications

Uma vantagem significativa de implementar uma web application de forma a

suportar as funcionalidades padrao dos browsers e que estas terao o mesmo com-

portamento independentemente da plataforma e do browser a partir do qual serao

acedidas No entanto diferentes implementacoes de browsers devido a diferentes

interpretacoes dos padroes definidos tornam por vezes esta tarefa um pouco mais

complicada existindo inclusivamente na web guioes de compatibilidade para os difer-

entes browsers como [Smi07]

223 Web 20 e Ajax

O termo web 20 descreve uma tendencia de utilizacao e de design observada

na World Wide Web (WWW) com o objectivo de melhorar a criatividade partilha

de informacao e principalmente a colaboracao entre utilizadores Estes conceitos

levaram ao desenvolvimento e evolucao de comunidades online tais como redes so-

ciais wikis e blogues

11

Enquadramento do Projecto

O termo tornou-se mais conhecido apos a primeira conferencia OrsquoReilly Media

Web 20 em 2004 e apesar de sugerir uma nova versao da WWW nao se refere a

qualquer evolucao tecnologica mas apenas a alteracoes a forma como os utilizadores

se servem da web De acordo com Tim OrsquoReilly [OrsquoR06] ldquoWeb 20 e uma revolucao

na industria do software causada pela adopcao da web como uma plataforma e pela

tentativa de entendimento das regras para o sucesso nesta nova plataformardquo

O desenvolvimento da Web 20 serve-se muitas vezes de um outro conceito Ajax

O conceito que hoje conhecemos como Ajax muitas vezes incorrectamente de-

scrito como uma tecnologia foi originalmente criado para permitir o desenvolvimento

de web applications que se assemelhassem ainda mais a aplicacoes de desktop Este

conceito foi melhor descrito por [Gar05] como um conjunto de varias tecnologias

que podem ser utilizadas para melhorar a experiencia do utilizador de uma dada

web application introduzindo a capacidade assıncrona de envio de pedidos ou da

recepcao assıncrona de respostas As tecnologias mais frequentemente envolvidas

sao

bull eXtensible HyperText Markup Language (XHTML) e Cascading Style Sheets

(CSS) padrao para a apresentacao

bull interaccao dinamica atraves do DOM

bull troca e manipulacao de dados utilizando XML e eXtensible Stylesheet Lan-

guage Transformation (XSLT) ou JavaScript Object Notation (JSON)

bull pedidos assıncronos utilizando XMLHttpRequest [vK08]

bull JavaScript utilizado para integrar todas estas tecnologias

E importante frisar que o Ajax nao e um produto nem uma tecnologia E um

termo que descreve a utilizacao de um conjunto de tecnologias para o desenvolvi-

mento de web applications com um elevado grau de interactividade Comparativa-

mente as web applications tradicionais o Ajax introduz uma camada de visualizacao

diferente em tres importantes pontos

1 Do lado do cliente existe um motor que serve de intermediario entre a interface

da aplicacao e o servidor

2 A actividade do utilizador despoleta chamadas JavaScript em vez de um pedido

de pagina directamente ao servidor

3 Informacao codificada em XML em vez de paginas HTML e trocada entre o

servidor e o cliente

12

Enquadramento do Projecto

Isto significa que as paginas que utilizam Ajax contem um motor do lado do

cliente composto por um conjunto de funcoes JavaScript responsavel pela comu-

nicacao com o servidor e por actualizar a interface com o resultado dessa mesma

comunicacao

Na Figura 23 ilustra-se a natureza assıncrona do Ajax quando comparada com

as web applications tradicionais Como se pode observar adicionando um mecan-

ismo Ajax a uma web application eliminam-se diversos tempos de espera associados

a comunicacoes com o servidor uma vez que a interface nao fica ldquobloqueadardquo a es-

pera da resposta Obtem-se assim aplicacoes com um comportamento mais fluido

eliminando tempos de espera entre cada ldquocliquerdquo e melhorando a experiencia do

utilizador

23 Offline Web Applications

A informacao grafica (bem como folhas de estilo e scripts) tais como as ima-

gens que constituem o visual de uma web application e ja tratada de forma especial

pelos cada vez mais avancados sistemas de cache (armazenamento temporario) dos

browsers Mas estes nao sao ainda capazes de guardar conteudo criado pelo uti-

lizador nem de apresentar informacao independentemente do estado da ligacao

Numa altura onde se fala de servicos de Internet wireless municipalizados [Kha]

comunicacoes 3G e ligacoes de banda larga a alta velocidade a ligacao a rede global

continua a nao estar permanentemente disponıvel para os utilizadores Na WWW

encontra-se uma importante parte da informacao e das aplicacoes utilizadas para

criar e editar conteudos Por vezes informacao vital para a produtividade pode

desaparecer subitamente do mapa de acesso de um utilizador quando este entra no

metro num aviao ou mesmo quando se desloca para uma cidade ou paıs diferente

do habitual onde nao subscreve um plano de acesso que lhe garanta a ligacao

Permitir o acesso offline a estes recursos assume assim a sua importancia porque

permitira estender o alcance da informacao a locais onde nunca esteve antes e per-

mitira tambem melhorar o desempenho das web applications colocando informacao

mais perto dos utilizadores reduzindo a transferencia de dados apenas ao essencial

24 Comparacao

Nas evolucoes descritas neste capıtulo 2 pode-se observar que existe um par-

alelismo entre a evolucao das arquitecturas tradicionais cliente-servidor e a evolucao

a que se assiste na web O comportamento e arquitectura dos thin-clients assemelha-

se ao das paginas estaticas no sentido em que o browser nao toma parte em qualquer

13

Enquadramento do Projecto

processamento e serve apenas como uma plataforma de interaccao com o servidor

tal como os clientes descritos na seccao 211

A sua proxima evolucao os fat-clients trouxeram parte da capacidade de pro-

cessamento para o lado do cliente Na web foi tambem esta a inovacao tecnologica

a que se assistiu com a evolucao das tecnologias que permitiram a criacao de ver-

dadeiras aplicacoes e com a introducao do Javascript no browser dando ao cliente

a capacidade de processamento de dados A necessidade da separacao do codigo

em camadas logicas advem da crescente complexidade das web applications Esta

pratica permite entre outras coisas melhorar o processo de desenvolvimento e a

capacidade de manutencao de uma aplicacao

Os fat-clients tem tambem a capacidade de armazenamento de dados o que

permite a persistencia de informacoes entre duas sessoes e que algumas operacoes

sejam executadas sem a necessidade de comunicacao com o servidor Este facto pode

tambem ser uma realidade nas web applications com a adopcao das tecnologias OWA

Neste momento assiste-se a uma utilizacao cada vez maior da web como uma

plataforma de desenvolvimento A capacidade de cooperacao na edicao de conteudos

e a mobilidade proporcionada por esta plataforma sao os principais factores que

alimentam esta mudanca e pela primeira vez as aplicacoes tradicionais tem com-

peticao vinda de web applications A prova do reconhecimento da web como plataforma

de desenvolvimento pode ser retirada da aposta de empresas como a Adobe e Mi-

crosoft que lancaram publicamente ferramentas web complementares a produtos

seus tradicionalmente associados ao desktop ndash Acrobatcom5 e Microsoft Office

Live6 Dotar estas web applications da capacidade de execucao offline significa

aproximar a web e o desktop reunindo ldquoo melhor de dois mundosrdquo

As vantagens da mobilidade possıvel atraves da web a cooperacao na criacao e

edicao de conteudos e a possibilidade de utilizar aplicacoes sempre actualizadas e

sem necessidade de instalacao sao algumas das principais vantagens que promovem

esta mudanca que devido as preocupacoes associadas a usabilidade e experiencia do

utilizador esta fortemente associada ao desenvolvimento de Rich Internet Applica-

tion (RIA)s

5Adobe Acrobatcom httpwwwacrobatcom6Microsoft ndash httpsmallbusinessofficelivecom

14

Enquadramento do Projecto

Figura 23 Comparacao do modelo de web aplications sıncrono paginas estaticas e in-teractivas abordados nas seccoes 221 e 222 com o modelo de web applications Ajax(assıncrono) abordado na seccao 223 Figura adaptada de http www adaptivepath

com

15

Enquadramento do Projecto

16

Capıtulo 3

Estado da arte

Apesar de o conceito das OWAs nao ser absolutamente novo as tecnologias que

o suportam sao recentes Neste capıtulo descrevem-se quatro tecnologias que foram

tidas como principais candidatas para o desenvolvimento deste projecto Descrevem-

se ainda alguns exemplos de web applications que disponibilizam actualmente fun-

cionalidades offline e o processo da escolha da tecnologia a utilizar neste projecto

31 Gears

O Gears1 e uma extensao as funcionalidades do browser introduzido pelo Google

que tem como principal objectivo tornar possıvel a visualizacao de paginas de Inter-

net mesmo sem uma conexao disponıvel Encontra-se disponıvel para as platafor-

mas Windows Macintosh e Linux e oferece uma API de Javascript que permite

a scripts aceder a um mecanismo de armazenamento local baseado numa base de

dados SQLite

311 Arquitectura

Esta ferramenta e constituıda por tres componentes principais

bull LocalServer mdash Intercepta pedidos de paginas web e serve-as localmente

bull Database mdash Uma base de dados relacional construıda sobre SQLite

bull WorkerPool mdash Permite executar operacoes de computacao de uma forma

assıncrona sem afectar a capacidade de resposta e fluidez de execucao da web

application Assemelham-se a processos

1Google Inc ndash Mais informacao em httpgearsgooglecom

17

Estado da arte

LocalServer

O modulo LocalServer e uma cache de Uniform Resource Locators (URLs)

controlada pela web application Quando nao existe uma ligacao a Internet e e

feito um pedido para um URL presente nesta cache o LocalServer intercepta-o e

responde ao pedido localmente a partir do disco rıgido do utilizador A aplicacao

pode utilizar dois tipos diferentes de armazenamento local de URLs

bull ResourceStore ndash serve para capturar URLs utilizando exclusivamente a API

de Javascript disponibilizada para o efeito Uma aplicacao podera criar e

utilizar diversos ResourceStores simultaneamente para capturar ficheiros de

dados que necessitam de ser enderecados por um URL tal como um ficheiro

PDF ou uma imagem

bull ManagedResourceStore ndash serve para capturar um conjunto de URLs que estao

relacionados e que sao declarado num ficheiro de manifesto (especificado em

JSON) e que sao automaticamente actualizados O ManagedResourceStore

permite que o conjunto de recursos necessarios para correr uma web application

seja capturado e mantido actualizado automaticamente

A principal diferenca entre estes dois tipos de armazenamento de URLs e a forma

como sao actualizados os seus conteudos Os conteudos de um ManagedResourceStore

sao actualizados sempre que a versao contida no ficheiro de manifesto for alterada

enquanto que os conteudos de um ResourceStore nunca sao actualizados automati-

camente mas apenas quando for explicitamente ordenado pela aplicacao

O LocalServer e capaz de interceptar e servir localmente pedidos de HTTP e

HTTPS sempre que se reunam as seguintes condicoes

1 O URL encontra-se armazenado num ResourceStore ou ManagedResourceStore

2 O sistema de armazenamento local encontra-se activo (enabled = true) Se

o sistema de armazenamento local tiver o atributo requiredCookie o pedido

devera conter um cookie que lhe corresponda

O LocalServer nao necessita de monitorizar o estado da ligacao para atender aos

pedidos Na verdade sempre que as condicoes previamente enunciadas se verificarem

o LocalServer interceptara os pedidos e independentemente do estado da ligacao

a Internet servi-los-a a partir do disco rıgido local Cabera a aplicacao definir qual

o modo em que pretende executar um pedido (online ou offline) definindo o valor

de verdade da propriedade enabled

18

Estado da arte

Database

O modulo Database permite guardar dados da web application assegurando a

sua persistencia Os dados sao guardados de forma relacional no disco rıgido do uti-

lizador2 de acordo com o modelo de seguranca estabelecido pelo Gears3 significando

que uma aplicacao nao pode aceder a conteudos fora do seu domınio

WorkerPool

Nos web browsers uma operacao pesada de computacao pode tornar a interface

lenta e tornar menos agradavel a experiencia do utilizador O modulo WorkerPool

permite correr operacoes em background sem bloquear a interface com o utilizador

Os scripts executados numa WorkerPool nao activam os mecanismos de seguranca

do browser que mostram a mensagem ldquoA script on this page may be busy or may

have stopped respondingrdquo

O WorkerPool comporta-se como um conjunto de processos em vez de threads

Os Workers nao partilham qualquer estado de execucao o que significa que uma

alteracao a uma variavel num Worker nao afecta em nada a execucao de outro

Worker Alem disso os Workers nao herdam automaticamente nenhum codigo dos

seus pais Cada Worker e membro de um WorkerPool e os Workers podem in-

teragir entre si enviando mensagens em formato de texto ou JSON No entanto ha

tambem algumas limitacoes os Workers nao tem acesso ao DOM e objectos como

window ou document nao se encontram acessıveis Isto e consequencia de os Workers

nao partilharem o estado de execucao Mas tem acesso a todas as funcoes built-in

do Javascript A maioria das funcionalidades do Gears pode tambem ser acedida

atraves de uma variavel global especial definida como googlegearsfactory Para

outras funcionalidades especıficas os Workers podem ldquopedirrdquo a pagina principal para

continuar a execucao atraves do envio de mensagens

Outras funcionalidades

bull HttpRequest ndash Este modulo implementa a especificacao W3C XmlHttpRe-

quest definida em [vK08] tornando-a disponıvel para os workers e para a

pagina principal

bull Timer ndash Este modulo implementa a especificacao de timers tal como descrito

por [Hic08] e torna-os disponıveis para os workers e para a pagina principal

2Consultar httpcodegooglecomapisgearsapi_databasehtmldirectories3Consultar httpcodegooglecomapisgearssecurityhtml

19

Estado da arte

bull Factory ndash Esta classe e utilizada para instanciar todos os outros objectos da

API do Gears atraves do seu metodo create Este metodo pode ser utilizado

com os seguintes parametros

ndash betadatabase

ndash betahttprequest

ndash betalocalserver

ndash betatimer

ndash betaworkerpool

312 Goggle Gears em dispositivos moveis

O Gears esta tambem disponıvel em dispositivos Windows Mobile 5 e 6

Os dispositivos moveis estao pela sua natureza frequentemente desconectados

da Internet Mesmo quando possuem uma ligacao as latencias na transferencia de

dados em redes moveis tornam as aplicacoes pouco fluıdas mas o Gears permite

ultrapassar este obstaculo

O Gears funciona exactamente da mesma forma em dispositivos moveis equipados

com o Windows Mobile 5 e 6 como num computador comum Se uma aplicacao tiver

sido implementado com suporte para o Gears entao tambem estara preparada para

ser executada num dispositivo movel mas as limitacoes dos browsers disponıveis

para dispositivos moveis tem que ser consideradas Isto significa prever as condicoes

que permitam uma boa usabilidade devido aos pequenos ecras destes dispositivos

bem como o seu suporte limitado dos padroes do DOM CSS e JavaScript

32 Adobe AIR

O Adobe AIR4 e um runtime compatıvel com diversos browsers e sistemas opera-

tivos que pretende dar aos programadores a possibilidade de combinar diversas tec-

nologias de producao de conteudos para a Internet no desenvolvimento de Rich Inter-

net Application (RIA)s O Adobe AIR mantem uma relacao com o browser mas es-

tende as suas capacidades e tecnologias permitindo o desenvolvimento de aplicacoes

tambem para o ambiente de trabalho com janelas em tudo semelhantes as do sis-

tema operativo Segundo a Adobe o objectivo e complementar o browser dando

aos utilizadores (mas essencialmente aos programadores e equipas de desenvolvi-

mento) a escolha sobre como distribuir as suas aplicacoes Para este efeito o Adobe

AIR tem uma aproximacao diferente do Gears Em vez de ldquoestenderrdquo o browser

acrescentando-lhe funcionalidades o AIR permite tambem o desenvolvimento de

4Adobe - httpwwwadobecomproductsair

20

Estado da arte

aplicacoes que se destinam a ser executadas fora do ambiente do browser mas uti-

lizando as tecnologias comuns da Internet (por exemplo HTML CSS JavaScript

Flash Flex)[CDGH08]

A utilizacao desta tecnologia permite utilizar o browser ou o proprio runtime

Adobe AIR como plataforma de execucao da aplicacao

Na Tabela 31 faz-se uma comparacao das funcionalidades disponıveis de acordo

consoante se escolha o browser ou o desktop como plataforma base para a aplicacao

Uma vez que as aplicacoes Adobe AIR na plataforma desktop tem um caracter

persistente (sao instaladas no computador do utilizador) o Adobe AIR tem um

modelo de seguranca que se assemelha com o das tradicionais aplicacoes desktop

[Ada08] Este modelo e analisado nas seccoes 321 e 322 O ambiente em que

e executado o browser e restringido a execucao de web applications que podem

ser de varias origens (incluindo de origens anonimas ou sem confianca) O Adobe

AIR proporciona acesso a capacidades como acesso a ficheiros que necessitam da

confianca do utilizador

bull HTML ndash O desenvolvimento de aplicacoes para o Adobe AIR pode ser feito

com recurso a tecnologias de HTML e Ajax comuns utilizando as linguagens

de markup existentes distribuıdas como texto e interpretadas em execucao

(runtime)

bull Flash ndash Outra alternativa sera a utilizacao da linguagem Flash Permite a

renderizacao de graficos vectoriais e audiovıdeo com suporte nativo Utiliza

ActionScript para adicionar maior interactividade com o utilizador

bull Flex ndash O Flex e uma framework open source para o desenvolvimento de RIAs

usando Flash As aplicacoes Flex sao na realidade Flash sendo a principal

diferenca o ambiente de desenvolvimento

Como resultado uma aplicacao AIR podera ser implementada

bull Baseada em Flash ou Flex (aplicacoes cujo conteudo base e em ShockWave

Flash (SWF))

bull Baseada em Flash ou Flex tambem com HTML ou Portable Document Format

(PDF) Aplicacoes cujo conteudo de base e em FlashFlex (SWF) com HTML

(HTML JavaScript CSS) ou conteudo PDF incluıdo

bull Baseada em HTML Aplicacoes cujo conteudo base e em HTML Javascript

CSS

bull Baseada em HTML utilizando tambem FlashFlex ou PDF

21

Estado da arte

Os utilizadores interagem com uma aplicacao AIR da mesma forma que interagem

com outras aplicacoes com janelas nativas do seu sistema operativo O runtime e

instalado uma vez no computador do utilizador e a partir desse momento todas as

aplicacoes AIR terao o mesmo aspecto que qualquer outra aplicacao para o desktop

321 Seguranca

Permitir que uma web application aceda ao disco de armazenamento do utilizador

pode comprometer seriamente a sua seguranca Neste sentido o Adobe AIR tem

suporte para assinaturas digitais (Secure Sockets Layer (SSL)) que podem ser com-

pradas pelas equipas de desenvolvimento que o desejem e cujos certificados serao

apresentados ao utilizador no momento da instalacao Um outro aspecto ainda

relativo a seguranca e o mecanismo de isolamento de cada ambiente (sandbox )

322 Assinatura do codigo

O runtime AIR exige que todas as aplicacoes estejam digitalmente assinadas As

assinaturas digitais de codigo sao um processo que visa garantir a integridade da

aplicacao e a identidade do seu autor no momento da instalacao As equipas de

desenvolvimento podem ldquoassinarrdquo uma aplicacao utilizando um certificado atribuıdo

por uma Entidade Certificadora (Certification Authority) ou atraves de um certifi-

cado individual (self signed certificate) Neste momento o Adobe AIR suporta como

entidades certificadoras a Verisign e a Thawte [Ado08]

O instalador apresenta o nome de quem publica a aplicacao quando o codigo tiver

sido assinado com um certificado que apresente confianca ou que esteja encadeado

com um certificado que tenha ja sido aceite no computador em que se esta a instalar

a aplicacao

As equipas de desenvolvimento podem tambem assinar as aplicacoes com um

certificado auto-atribuıdo (um certificado criado por elas proprias) mas neste caso

o instalador apresentara estas aplicacoes como sendo de uma origem nao verificada

O AIR utiliza a infraestrutura publica de chaves [Ent07] suportada pelo arquivo

local do sistema operativo Para que a origem da aplicacao seja reconhecida o

computador onde a aplicacao AIR esta a ser instalada tem que confiar directamente

no certificado que foi utilizado para assinar a aplicacao ou confiar num certificado

que esteja num encadeamento logico de certificados confiados e que se ligue desta

forma ao certificado utilizado para assinar a aplicacao

Todas as aplicacoes AIR tem caracterısticas em comum independentemente da

tecnologia utilizada para o seu desenvolvimento (HTMLFlexFlash) No ambito

de uma aplicacao AIR existem um conjunto de APIs que estao disponıveis e que

tornam possıvel o acesso ao sistema local (leitura e escrita) e a recursos de rede que

22

Estado da arte

de outra forma nunca estariam acessıveis a partir de uma web application comum

Cada aplicacao AIR possui tambem diferentes nıveis de isolamento chamados secu-

rity sandboxes dependendo do tipo de conteudo que esta a ser carregado e do seu

objectivo

bull Isolamento ao nıvel da aplicacao5 ndash E a raiz de cada aplicacao AIR Este

nıvel de isolamento permite o acesso a APIs privilegiadas e especıficas do

AIR Em contrapartida e negado o acesso a algumas APIs que poderiam ser

facilmente utilizadas de forma maliciosa contra o utilizador final Importacao

dinamica de conteudos remotos e geralmente proibido e as tecnicas e mecan-

ismos de geracao dinamica de codigo sao fortemente restringidas Apenas

conteudo carregado directamente da directoria base da aplicacao podera ser

colocado neste nıvel de isolamento

bull Isolamento nao especıfico da aplicacao6 ndash contem todo o outro conteudo

que nao tenha sido carregado directamente para o isolamento da aplicacao

Isto inclui conteudo local e remoto Este tipo de conteudo nao tem acesso

directo as APIs do AIR e rege-se pelas mesmas regras tal como se tivesse sido

carregado por um browser a partir da mesma localizacao (por exemplo HTML

carregado a partir de um domınio remoto comporta-se da mesma forma que se

fosse acedido a partir do browser)

33 Mozilla Prism

331 XML User Interface Language

O eXtensible User Interface Language (XUL) e uma linguagem de anotacao

baseada em XML desenvolvida pela Mozilla Foundation que opera em aplicacoes

Mozilla multi plataforma tal como o Firefox O motor Gecko e a unica imple-

mentacao completa desta linguagem que foi desenhada sobre padroes web comuns

como CSS JavaScript e o DOM e permite o desenvolvimento de interfaces graficas

utilizando elementos pre-definidos tais como window box page textbox radio

button entre outros Infelizmente o XUL nao possui qualquer especificacao formal

ou implementacoes de inter-operabilidade para outros motores que nao o Gecko No

entanto a sua implementacao e licenciada em codigo aberto pelas licencas GNU Gen-

eral Public License (GPL) GNU Lesser General Public License (LGPL) e Mozilla

Public License (MPL)

Enunciam-se algumas caracterısticas desta linguagem

5NT application sandbox6NT non-application sandbox

23

Estado da arte

Liguagem de anotacao poderosa baseada em componentes (widgets) O ob-

jectivo do XUL e permitir a construcao de aplicacoes multi-plataforma em

claro contraste com o Dynamic HyperText Transfer Protocol (DHTML) que se

destina ao desenvolvimento de paginas web Por esta razao o XUL esta orien-

tado a componentes tais como janelas botoes e etiquetas em vez de paginas

cabecalhos de texto e ligacoes de hipertexto Investir tempo e esforco para

atingir este mesmo resultado em aplicacoes baseadas em DHTML compromete

frequentemente a complexidade e desempenho da aplicacao

Baseado em padroes O XUL e um dialecto XML baseado no padrao W3C XML

10 As aplicacoes escritas em XUL sao tambem baseadas em especificacoes

W3C adicionais como HTML 40 CSS DOM nıvel 1 e 2 JavaScript 15

incluindo ECMA-262 Edition 3 (ECMAscript)

Portabilidade entre plataformas Tal como HTML o XUL foi desenhado para

ser independente da plataforma em que e utilizado tornando as aplicacoes

facilmente portaveis entre sistemas operativos nos quais o Mozilla e suportado

Uma vez que o XUL oferece um nıvel de abstraccao dos componentes graficos

de interface que disponibiliza implementa a premissa ldquoum codigo para todas

as plataformasrdquo A interface grafica de todos os produtos centrais Mozilla

(browser instant messenger livro de enderecos) e escrita em XUL com um

unico codigo base que suporta todas as plataformas Mozilla

Separacao entre o nıvel de apresentacao e a logica de negocio Uma das

maiores preocupacoes no desenvolvimento para a Internet e a forte ligacao

entre estas duas camadas (interface e logica) Isto constitui um problema sig-

nificativo no desenvolvimento de grandes aplicacoes especialmente quando o

desenvolvimento e feito em ambientes de equipa porque as capacidades de de-

senvolvimento destas duas partes da aplicacao estao muitas vezes espalhadas

por diferentes elementos O XUL permite uma clara distincao entre a definicao

da aplicacao cliente e da logica de implementacao (XUL eXtensible Binding

Language (XBL) e JavaScript) apresentacao (CSS e imagens) internacional-

izacao (Document Type Definitions (DTDs) e etiquetas de texto em lınguas

especıficas guardados em ficheiros properties) O esquema grafico e apre-

sentacao de uma aplicacao XUL pode ser alterado de forma independente da

sua logica ou implementacao e a aplicacao pode ainda ser traduzida (interna-

tionalization) de forma independente da sua logica implementacao ou apre-

sentacao Este grau de separacao resulta em aplicacoes que sao mais faceis de

manter pelos programadores e facilmente adaptadas por designers e tradutores

24

Estado da arte

Facil adaptacao Outro benefıcio que advem do nıvel de separacao entre logica

de negocio e apresentacao oferecido pelo XUL e a facilidade com que se pode

adaptar uma aplicacao para diferentes clientes ou grupos de utilizadores Um

programador pode utilizar a mesma aplicacao base e adapta-la consoante as

necessidades atraves de diferentes temas (skins) e ficheiros de lınguas Desta

forma uma aplicacao escrita e desenvolvida em Ingles pode ser rapidamente

traduzida para Portugues e distribuıda com outra aparencia mais apropriada

ao cliente alvo

332 Prism

O Mozilla Prism e um browser simplificado e ldquointerpretadorrdquo de XUL (tambem

designado por XULRunner) que acolhe web applications sem a interface grafica ha-

bitual de um browser Baseia-se num conceito designado por Site Specific Browser

(SSB) Um SSB e uma aplicacao com um browser embebido desenhado para exe-

cutar apenas uma web application Nao possui os menus e barras de ferramentas

habituais Um SSB tem uma integracao com o sistema operativo e com o desktop

muito mais estreita do que uma web application acedida atraves de um browser uma

vez que e executado em janela propria

O Prism resulta de uma experiencia da Mozilla e visa reduzir as diferencas entre

as desktop applications tradicionais e as web applications Um dos aspectos focados e

a experiencia do utilizador Numa apresentacao oficial e dito que ldquo[o Prism] pretende

ser uma ponte entre as diferencas que existem entre as aplicacoes tradicionais de

desktop e as web applications explorando novos modelos de usabilidade enquanto

que a linha que as separa se continua a definirrdquo [Lab07]

34 HTML 5

A especificacao HTML 5 [Hic08] que se encontra em fase de desenvolvimento

pelo grupo WHATWG pretende ser uma norma de substituicao dos padroes HTML

4 XHTML 1x e do DOM2 HTML Uma das propriedades que o distingue das tec-

nologias que pretende substituir e precisamente o suporte para OWA e armazena-

mento de dados no cliente de uma forma relacional Nao sendo propriamente uma

tecnologia ndashmas antes uma especificacao ndashe aqui mencionada por ter servido como

referencia a diversas implementacoes de funcionalidades offline e por se considerar

que venha a ter um impacto significativo nas implementacoes de diversos browsers

Dion Almaer defendeu no seu blogue que o Gears era uma implementacao do

HTML 5 No seu artigo ldquoGears as a bleeding-edge HTML 5 implementationrdquo [Alm08]

o autor diz que ambos ndasho Gears e o HTML 5 ndashpretendem dar a web caracterısticas

25

Estado da arte

semelhantes e nao encontrar motivo de ldquocompeticaordquo entre as duas mas que en-

quanto o HTML 5 e uma especificacao o Gears e uma implementacao

No entanto tambem e verdade que o HTML 5 cobre muitos outros pontos para

alem das OWA que saem completamente fora do ambito do Gears Se esta es-

pecificacao atingir um estado de maturidade que possibilite a sua adopcao pelos

principais browsers tornando nativo do browser o suporte OWA entao deixara de

fazer sentido a existencia de uma extensao como o Gears

A especificacao HTML 5 disponibiliza duas APIs relevantes para o tema das

OWA

1 Uma base de dados baseada em SQL que permite o armazenamento de dados

do lado do cliente

2 Uma ldquocacherdquo HTTP que garante a disponibilidade das aplicacoes mesmo quando

o utilizador nao possui uma ligacao a Internet

Estas caracterısticas sao as bases da tecnologia das OWA e tem correspondencia

com os pontos analisados nas seccoes 311 e 311

35 Web applications que usam funcionalidades offline

Nesta seccao apresentam-se algumas web applications que actualmente disponi-

bilizam funcionalidades offline Estas aplicacoes foram escolhidas para uma analise

mais pormenorizada por utilizarem o Gears que tal como descrito na seccao 4 foi

a tecnologia escolhida para o projecto

351 Google Reader e Google Docs

O Google Reader7 e um leitor de feeds RSS Permite gerir a subscricao de varios

sites simultaneamente que disponibilizem conteudos neste formato e foi a primeira

web application da Google com uma versao offline publicamente acessıvel (desde

Junho de 2007)

O Google Reader implementa o modo ldquoutilizador deciderdquo oferecendo na sua

interface um botao que permite alternar entre os modos online e offline

O Google Docs8 e uma web application que permite a criacao e edicao de doc-

umentos de texto folhas de calculo e apresentacoes Era ja publico desde Janeiro

de 2008 que o Google estava a desenvolver uma versao OWA desta aplicacao mas o

acesso a uma versao experimental so foi possıvel a partir de 31 de Maio de 2008

7Google Reader - httpreadergooglecom8Google Docs - httpdocsgooglecom

26

Estado da arte

A implementacao das funcionalidades offline nestas duas aplicacoes seguiu difer-

entes aproximacoes principalmente porque o Google Reader apresenta ao utilizador

informacoes que sao fornecidas por fontes externas enquanto que no Google Docs

a informacao e criada e editada pelo utilizador sobre a forma de documentos

A diferente origem da informacao implica que no Google Reader seja necessario

prever casos de excepcao tal como existirem demasiados itens que necessitam de

ser transferidos para o cliente Nao observar este ponto causa um problema grave

de usabilidade e para evitar tempos de espera demasiado longos e uma interface

com pouca capacidade de resposta as accoes do utilizador o Google Reader apenas

transfere para o cliente os dois mil itens mais recentes na transicao para o modo

offline

352 Remember the Milk

O Remember The Milk9 e uma web application desenvolvida por uma equipa

Australiana que proporciona funcionalidades de agenda gestao de tempo e de tare-

fas e foi uma das primeiras aplicacoes independentes do Google a adoptar o Gears

para acessos em modo offline Permite que os seus utilizadores facam uma gestao

de tarefas agrupando-as em listas adicionando-lhes campos de informacao adicional

ou dando-lhes informacao geografica (recorrendo ao servico Google Maps10) Entre

a sua lista de funcionalidades encontra-se ainda a possibilidade de importar e ex-

portar eventos no formato iCalendar (ics) etiquetas (tags) em tarefas publicacao

Really Simple Syndication (RSS) e partilha de categorias de tarefas de acordo com

diferentes nıveis de permissoes de acesso definidos pelo utilizador

353 MySpace e WordPresscom

O MySpace uma das maiores social networks na Internet anunciou recente-

mente que vai disponibilizar uma versao do seu cliente de e-mail que utiliza o Gears

para acelerar o seu desempenho Numa fase inicial estara disponıvel apenas para

utilizadores que tenham cinco mil ou mais mensagens na sua caixa de correio e

permitira efectuar pesquisas muito mais rapido que a sua versao online

O servico de blogs Wordpresscom anunciou tambem o inıcio da utilizacao desta

tecnologia com o fim de melhorar o desempenho A versao que utiliza esta tecnologia

descarrega e armazena no cliente um conjunto de imagens e scripts que passam a

ter preferencia sobre os seus congeneres online e que permitem acelerar o processo

de carregamento da aplicacao e visualizacao de blogs

9Remember The Milk ndash httpwwwrememberthemilkcom10Google Maps ndash httpmapsgooglecom

27

Estado da arte

O MySpace e o Wordpresscom sao dois exemplos da utilizacao da tecnologia

OWA para optimizacao de web application ja existentes Sem pretenderem disponi-

bilizar uma versao que seja totalmente offline fazem uso do Gears para armazenar no

cliente parte dos recursos frequentemente acedidos na visualizacao das suas paginas

36 Escolha da tecnologia

Apos a analise das tecnologias apresentada nas seccoes 31 a 34 foi necessario es-

tudar a adequacao de cada uma delas ao projecto em questao Desde logo e possıvel

observar que nem todas se dedicam apenas a OWA Por exemplo o Adobe AIR

apesar de ter suporte para OWA apenas disponibiliza algumas das funcionalidades

identificadas como mais indicadas para a execucao do projecto quando utilizado

na sua vertente desktop tal como exposto na Tabela 31 mas a utilizacao desta

vertente implicaria o desenvolvimento de novas interfaces e de novas formas de co-

municacao (troca de mensagens XML ou JSON) A vertente web do Adobe AIR

foca-se mais especificamente nas Rich Internet Applications e permite a reutilizacao

do codigo ja existente (exigindo naturalmente a sua adaptacao e a implementacao

das funcionalidades pretendidas)

A tecnologia escolhida para a realizacao deste trabalho foi o Gears sendo que

um dos principais factores a influenciar esta opcao foi a liberdade introduzida pela

sua licenca Berkeley Software Distribution (BSD)11

Considerou-se o funcionamento desta ferramenta extremamente adequando a

aplicacao no WOW uma vez que o seu principal objectivo e precisamente tornar

possıvel a execucao offline de uma pagina web e por virtude deste facto o Gears tem

uma API concisa e de simples aplicacao pratica uma vez que nao possui quaisquer

outros elementos distractores O funcionamento do seu ManagedResourceStore ex-

emplificado na Figura 31 com a capacidade de actualizacao de recursos definidos

num ficheiro manifesto especificado em JSON pesou tambem nesta decisao

11Sobre a licenca BSD consultar httpwwwopensourceorglicensesbsd-licensephp e http

wwwlinfoorgbsdlicensehtml

28

Estado da arte

Figura 31 Esquema UML do processo efectuado pelos recursos do Gears do tipoManagedResourceStore para a actualizacao dos conteudos definidos no ficheiro manifesto

29

Estado da arte

Funcionalidade RIAs no browser RIAs no desktop

Disponibilidadeda aplicacao

As aplicacoes podem ser facil-mente exploradas e utilizadas

As aplicacoes quando instal-adas tem maior grau de fun-cionalidades e persistencia

Instalacao Nao e necessario qualquer tipode instalacao

As aplicacoes sao instaladasatraves do browser ou descar-regadas e instaladas comouma aplicacao tradicional

Actualizacoes Aplicacoes sao actualizadascarregando conteudos paraum website

O AIR disponibiliza uma APIque permite que as aplicacoessejam actualizadas de umaforma

Sistemas opera-tivos suportados

As aplicacoes podem ser exe-cutadas em diversos sistemasoperativos e browsers

As aplicacoes sao multi-plataforma e podem serinstaladas e executadas emdiversos sistemas operativos ebrowsers

Linguagens deprogramacao

Javascript e disponibilizadopelo browser e ActionScripte disponibilizado pelo AdobeFlash Player

Maquinas virtuais deJavascript e ActionScriptcompatıveis com o browser

Capacidade deexecucao embackground

As RIAs podem ser execu-tadas numa janela do browser

As aplicacoes podem ser ex-ecutadas em background edisponibilizar notificacoes talcomo uma aplicacao tradi-cional

Persistencia A actividade esta limitada asessao do browser Quando obrowser e encerrado toda ainformacao e descartada

As aplicacoes sao instaladas eestao disponıveis no desktopPodem armazenar informacaolocalmente e estao disponıveisoffline

Integracao com odesktop

Integracao com o desktop lim-itada devido a restricoes im-postas pelo browser

As aplicacoes podem acederao sistema de ficheiro ao clip-board eventos notificacoesetc

Controlo da inter-face com o uti-lizador

As aplicacoes sao acedidasatraves de uma janela dobrowser que tem os seusproprios controlos e visualgrafico

As aplicacoes tem um vi-sual grafico proprio em janelapropria

Armazenamentode dados

As aplicacoes tem armazena-mento limitado que pode serreescrito pelo browser

As aplicacoes tem acesso a to-talidade do espaco disponıvellocalmente e a uma base dedados com a possibilidade deencriptacao

Tabela 31 Comparacao das funcionalidades oferecidas pelo Adobe AIR para as platafor-mas web e desktop

30

Estado da arte

Aplicacao Modo de execucao utilizadoGoogle Reader Utiliza o modo ldquoutilizador deciderdquo disponibilizando

ao utilizador um botao para alternar entre os modosonline e offline Como lida com informacao recol-hida de fontes externas de natureza frequentementeefemera o processo de sincronizacao apenas transfereos dois mil itens mais recentes quando passa ao es-tado offline Neste modo sao ainda guardadas in-formacoes de itens lidos e etiquetas atribuıdas quesao sincronizadas com o servidor quando o utilizadorvoltar a activar estado online

Google Docs Utiliza o modo ldquoaplicacao deciderdquo permitindo que outilizador edite os conteudos de documentos de textofolhas de calculo e de apresentacoes independente-mente do estado da ligacao desde o momento em queas funcionalidades offline sao activadas A aplicacaofaz pequenas sincronizacoes com o servidor sempre quenecessario

Remember the Milk Utiliza um modo hıbrido entre ldquoaplicacao deciderdquo eldquoutilizador deciderdquo A aplicacao encarrega-se da sin-cronizacao de dados mas disponibiliza um controlona sua interface que permite despoletar manualmenteeste processo para situacoes em que o utilizador fez al-teracoes recentes e pretende usufruir das capacidadesoffline imediatamente

MySpace O MySpace anunciou a utilizacao de mecanismos dearmazenamento de dados no cliente com recurso atecnologias OWA para melhorar o desempenho doseu cliente web de correio electronico nomeadamenteno que diz respeito a operacoes de pesquisa e or-denacao Inicialmente esta funcionalidade estara ape-nas disponıvel para utilizadores com cinco mil ou maismensagens na sua caixa de correio mas nao e aindaclaro se sera disponibilizada uma versao totalmenteoffline

Tabela 32 Resumo da utilizacao de tecnologias OWA em algumas web applications con-sideradas na analise do estado da arte

31

Estado da arte

32

Capıtulo 4

Desenvolvimento

Neste capıtulo introduz-se a aplicacao WOW e apresenta-se o estudo que foi

feito da adequacao de cada tecnologia para a implementacao da funcionalidade of-

fline nesta plataforma Fazem-se diversas consideracoes sobre opcoes a tomar na

concepcao de OWAs e problemas comuns na sua implementacao bem como sug-

estoes para os resolver O WOW e uma aplicacao ja existente de gestao de ordens

de trabalho e do fluxo de tarefas numa empresa ou organizacao

41 Como ficar offline

Na maior parte das web applications de hoje nao existe uma camada de dados

real A aplicacao exemplificada na Figura 41 ao longo da sua execucao acede

directamente a sua unica fonte de dados (o servidor) atraves de chamadas Ajax sem

que exista uma separacao clara destas duas camadas

Para que uma web application seja capaz de ser executada sem uma ligacao

activa a Internet e mantenha o seu caracter dinamico torna-se necessario incluir

Figura 41 Exemplo de uma arquitectura de uma web application sem uma camada deabstraccao de dados Figura adaptada de http gears google com

33

Desenvolvimento

Figura 42 Exemplo de uma arquitectura de uma web application com uma camada deabstraccao de dados Figura adaptada de http gears google com

um mecanismo de armazenamento de dados local seja uma base de dados ou a

capacidade de acesso ao disco No entanto este mecanismo introduz dois problemas

1 Qual das fontes de dados utilizar quando um utilizador faz um pedido de

informacao

2 A necessidade de implementar uma camada de acesso a dados que seja coerente

quer se use o servidor remoto ou local

Por exemplo em vez de a aplicacao Ajax fazer um pedido relativo as contas de

todos os utilizadores em formato JSON directamente ao servidor remoto podera ao

inves fazer o pedido a um objecto intermedio da camada de dados Este objecto

demonstrado na Figura 42 sera responsavel por implementar uma interface de

acesso a base de dados e retornar um objecto JavaScript com uma representacao da

resposta do servidor

Mas a existencia de uma segunda fonte de dados torna recomendavel tambem

a implementacao de uma camada de data switching que em funcao da existencia

de conexao a Internet e da necessidade de actualizacao dos dados decide se faz o

pedido ao servidor remoto ou se fornece os dados presentes localmente Este objecto

apresentado na Figura 43 decidira de forma transparente para o utilizador se le ou

escreve os dados localmente ou se os enviapede ao servidor remoto e pode tambem

iniciar o processo de convergencia de dados e de resolucao de conflitos

411 Funcionalidades disponıveis em modo offline

Por razoes praticas e provavel que nem todas as funcionalidades da aplicacao

possam ser disponibilizadas em modo offline E necessario escolher quais as fun-

cionalidades a disponibilizar no modo offline da aplicacao e implementar a logica

que decide quando utilizar a base de dados local ou o servidor remoto Apesar do

acesso a base de dados local ser muito mais rapido do que aceder ao servidor o

acesso local nem sempre e preferido Ha varias razoes que podem tornar necessario

escolher o acesso ao servidor em vez do acesso local

34

Desenvolvimento

Figura 43 Exemplo de uma arquitectura de uma web application com uma camada deabstraccao de dados e um data switch Figura adaptada de http gears google com

1 A informacao pode ter uma natureza efemera e nao fazer sentido guarda-la

localmente Exemplo dados em tempo real da bolsa de valores de Lisboa

2 Algumas aplicacoes lidam com informacao que so faz sentido na presenca de

uma ligacao Exemplo Instant Messaging

3 A aplicacao podera escolher apenas guardar a informacao acedida mais fre-

quentemente Exemplo para o utilizador poder alterar a lıngua de apre-

sentacao da aplicacao os conteudos terao que ser guardados em todas as

lınguas disponibilizadas pela aplicacao O custo de implementacao de algu-

mas funcionalidades pode nao compensar o benefıcio

4 A capacidade de processamento ou de armazenamento de dados pode inviabi-

lizar algumas funcionalidades offline Exemplo se uma dada funcionalidade

necessita de uma capacidade de armazenamento de dados para alem do razoavel

de um computador pessoal para ser util (visualizador de mapas)

42 Modos de execucao

Um aspecto que e necessario estudar para qualquer web application que se deseje

disponibilizar offline prende-se com tres modos de execucao que devem ser consid-

erados

1 Utilizador decide o modo de execucao A aplicacao tem modos distintos

de execucao para os estados online e offline geralmente indicados na interface

com o utilizador O utilizador e informado do estado da ligacao e participa na

alteracao de estado de execucao da aplicacao interagindo com a sua interface

2 Aplicacao decide o modo de execucao Pode ser implementado na propria

aplicacao um mecanismo de deteccao do estado da ligacao (por exemplo atraves

35

Desenvolvimento

de chamadas Ajax periodicas) transitando de estado e sincronizando automati-

camente Desta forma o utilizador nao precisa de participar na alteracao de

estado a menos que exista um conflito de dados que requeira a sua atencao

3 Aplicacao assume sempre o estado offline Outra hipotese sera imple-

mentar uma web application que assume sempre estar na ausencia de uma

ligacao ao servidor de dados Esta aplicacao responde aos pedidos do uti-

lizador efectuando pedidos de informacao ao servidor mas nao dependendo

de uma resposta valida para mostrar a informacao que ja tinha disponıvel an-

teriormente A sincronizacao de dados com o servidor e tentada sempre que

existam dados para submeter e uma accao do utilizador

421 Modo ldquoutilizador deciderdquo

Neste modo de execucao quando a aplicacao esta online comunica com o servidor

remoto quando esta offline comunica com a base de dados local A informacao tem

que ser sincronizada sempre que se muda de modo A principal vantagem desta opcao

e que e a mais simples de implementar mesmo para uma aplicacao ja existente e

portanto uma forma expedita de disponibilizar uma OWA No entanto tem tambem

algumas desvantagens que devem ser consideradas

1 O utilizador tem que se lembrar de fazer a alteracao de estado de execucao

Caso contrario podera estar a trabalhar inadvertidamente numa versao offline

com dados antigos ou nao ter a informacao necessaria se perder subitamente

a ligacao

2 Se a ligacao for intermitente o utilizador tera ou que escolher um dos modos

de execucao ou estar constantemente a trocar

3 Uma vez que a base de dados nao esta sempre actualizada nao podera ser

utilizada para melhorar a rapidez de execucao da aplicacao quando em modo

online

422 Modo aplicacao decide

A deteccao do estado da ligacao pode ser implementada atraves de um pedido

assıncrono ao servidor tal como ilustrado na Figura 44 O resultado deste pedido

definira o estado online (em caso de sucesso) ou offline (em caso de falha) A

sincronizacao de dados podera ser feita sempre que ocorra uma transicao do es-

tado offline para o estado online No entanto este metodo nao se revela eficiente

36

Desenvolvimento

Figura 44 Esquema grafico ilustrando uma OWA executando no browser utilizando ummodo de execucao do tipo ldquoaplicacao deciderdquo com deteccao automatica do estado daligacao via pedidos Ajax assıncronos a cada cinco segundos

para grandes aplicacoes uma vez que requer a troca de mensagens demasiado fre-

quentes com o servidor que se destinam exclusivamente a monitorizacao do estado

da ligacao

423 Modo ldquoaplicacao assume o estado offlinerdquo

Uma aplicacao transparente funciona assumindo sempre que esta em modo of-

fline ou pelo menos que pode perder a ligacao a qualquer momento Neste modo

tira-se o maximo partido do armazenamento local e fazem-se pequenas mas contınuas

sincronizacoes com o servidor sempre que este esteja disponıvel A sincronizacao de

dados tambem e feita sempre que se volta ao estado online

As vantagens de uma web application transparente sao as seguintes

bull Uma melhor experiencia para o utilizador uma vez que este nao tem que se

preocupar com o estado da ligacao ou com a transicao de estados

bull A aplicacao funciona de forma coerente mesmo que a ligacao seja intermitente

bull Uma vez que o armazenamento local e mantido actualizado pode ser utilizado

para melhorar o desempenho da aplicacao

Foram identificadas as seguintes desvantagens

bull E mais difıcil de implementar e a sincronizacao acarreta cuidados especiais

bull E necessario um cuidado adicional para evitar que as operacoes de sincronizacao

frequentes que ocorrem automaticamente nao afectem os tempos de resposta

da aplicacao

bull Os testes a aplicacao sao mais complexos uma vez que a sincronizacao de dados

nao ocorre em resposta a uma accao do utilizador

37

Desenvolvimento

43 Sincronizacao de dados

A sincronizacao de dados consiste na capacidade de identificar e transferir pe-

riodicamente a versao mais actual dos dados entre o cliente e o(s) servidor(es)

Independentemente do modo de execucao escolhido e mesmo do estado da ligacao

do utilizador a informacao armazenada localmente e a informacao armazenada no

servidor estarao por vezes dessincronizadas Isto podera acontecer sempre que por

exemplo

bull O utilizador faz alteracoes em modo offline

bull A informacao e partilhada e pode ser alterada por uma entidade externa

bull A informacao e fornecida por uma entidade externa

Resolver estas diferencas de forma a que a informacao local e remota encontrem

a igualdade chama-se sincronizacao de dados Ha varias aproximacoes possıveis

para este efeito que dependem da natureza da aplicacao cada uma com vantagens

e desvantagens

A capacidade de suportar a mobilidade dos utilizadores torna-se cada vez um

ponto mais importante de uma web application Para uma organizacao de dimensao

global e vital garantir que os seus colaboradores tem acesso a mesma informacao

que tem disponıvel nos seus postos de trabalho mesmo quando estao fora Na maior

parte dos casos estes colaboradores terao acesso a um computador portatil um

desktop Smartphone ou PDA e atraves destes poderao ter acesso a sua informacao

directamente atraves de ligacoes encriptadas Virtual Private Network (VPN) de um

servidor web ou de outro mecanismo de rede

Esta solucao e simples de implementar mas infelizmente para a maioria dos

colaboradores com grande factor de mobilidade nao e satisfatoria As principais

desvantagens sao as seguintes

bull Requisitos de ligacao Para permitir que os utilizadores acedam a sua in-

formacao e necessario garantir a capacidade constante de comunicacao pelo

menos durante o tempo necessario que assegure a sua transferencia

bull Velocidade de ligacao sem persistencia de dados e em ligacoes de fraca

qualidade a usabilidade por vezes torna-se inaceitavel

bull Ponto crıtico de falha Com este tipo de solucao todos os utilizadores de-

pendem da base de dados que armazena informacao vital para o funcionamento

do cliente

38

Desenvolvimento

bull Scalability do servidor A medida que novos utilizadores sao adicionados ao

sistema o desempenho do servidor e afectado levando a necessidade de maior

capacidade de armazenamento eou processamento

De acordo com a documentacao da Microsoft Sync Framework [Mic08] uma

solucao alternativa consiste em implementar uma Occasionally Connected Appli-

cation (OCA) Uma OCA permite a um utilizador remoto continuar a aceder a

sua informacao mesmo depois de perder a ligacao mas em vez de recorrer a um

servidor recorre a informacao armazenada no seu dispositivo local Para preencher

localmente a informacao que o utilizador necessita uma OCA possui mecanismos

de sincronizacao de dados que sao oferecidos por esta framework

431 Quando sincronizar

Uma das solucoes mais simples de implementar passa por disponibilizar um

mecanismo manual que despoleta a sincronizacao Diz-se manual porque e o uti-

lizador que escolhe quando sincronizar e pode ser implementada simplesmente

fazendo o upload de toda a informacao para o servidor e depois fazendo o download

da copia mais recente da informacao antes de voltar a ficar offline Para que esta

seja uma opcao viavel e necessario que

bull O volume de dados seja suficientemente pequeno para que possa ser transferido

do servidor para o cliente num espaco de tempo aceitavel

bull Que o utilizador indique explicitamente que quer mudar para o estado offline

ou online pressionando um botao da interface

Contudo podem ser identificados alguns problemas relacionados com esta abor-

dagem

bull Os utilizadores nem sempre podem prever o estado das suas ligacoes A ligacao

pode-se perder subitamente ou ter um caracter intermitente

bull O utilizador pode esquecer-se de efectuar a sincronizacao

Outra opcao sera conjugar a sincronizacao de dados com o modo de execucao

transparente A sincronizacao ocorre automaticamente em background de forma

nao intrusiva para o utilizador A aplicacao comunica com o servidor regularmente

efectuando pequenas trocas de dados com o objectivo de manter o sincronismo da

informacao local e remota Esta abordagem pode ser implementada com pedidos

Ajax assıncronos e regulares ao servidor o que permite manter a interaccao com a

interface fluıda evitando bloqueios Estes pedidos sao feitos prevendo as situacoes

39

Desenvolvimento

de disponibilidade ou indisponibilidade (timeout) do servidor Uma outra opcao

sera permitir que o servidor comunique essas alteracoes utilizando Comet1 tal como

descrito em [Wil06] e [Rus06] As vantagens destas aproximacoes sao

bull A informacao esta disponıvel a qualquer altura que o utilizador decida ficar

offline ou que a ligacao seja acidentalmente perdida

bull O desempenho da aplicacao pode ser melhorado quando se estiver a utilizar

uma ligacao a Internet lenta uma vez que o acesso a dados locais e mais

eficiente do que a consulta de dados ao servidor

44 WOW

O WOW e uma plataforma integrada de gestao de ordens de trabalho ja ex-

istente e desenvolvida pela Critical Software SA a qual se pretende adicionar a

capacidade de execucao offline Esta aplicacao e extremamente dinamica e con-

figuravel com um conjunto extremamente rico de funcionalidades das quais se

destacam

bull Gestao de Ordens de Trabalho ndash suportando a gestao dos pedidos desde a

sua criacao ate ao seu fecho tomando em conta os diferentes tipos de pedidos

(ordens de trabalho pedidos de informacao melhorias resolucao de problemas

etc) e diferentes tipos de accoes possıveis para cada um (Figura 45)

bull Monitorizacao de alteracoes ndash Historico de mudancas anexos e estados criando

relatorios de alteracao automaticamente (o que por quem e quando)

bull Uso de Service Level Agreements (SLAs) ndash E possıvel associar a um pedido um

SLA que define qual o perıodo de tempo atribuıdo a resolucao de um pedido

controlando e agilizando a resolucao do mesmo

bull Utilizacao de queries de utilizador configuraveis que permitem acesso rapido

a determinadas ordens de trabalho de acordo com o filtro configurado (por

exemplo ldquoPara mimrdquo ldquoPara o Grupordquo ldquoPelo Grupordquo)

bull Gestao do relacionamento entre pedidos

bull Pesquisa e filtragem de ordens de trabalho

bull Exportacao de dados em formatos padrao (PDF DOC ou XLS)

bull Integravel com solucoes externas

40

Desenvolvimento

Figura 45 Detalhe de um conjunto possıvel de estados e respectivas transicoes para umadada ordem de trabalho no WOW desde a sua submissao no sistema ate a sua conclusaoem fecho ou cancelamento Esta figura representa apenas um exemplo ja que o mapa deestados para uma ordem de trabalho e dinamico e pode ser alterado por um administradorFigura retirada de uma brochura promocional do WOW Critical Software SA

A utilizacao de uma ferramenta deste tipo por parte de uma empresa ou orga-

nizacao oferece vantagens quer a gestao de topo quer aos colaboradores individuais

para os colaboradores individuais o WOW e uma aplicacao onde estao registadas

todas as tarefas contribuindo activamente para o desenvolvimento em ambientes

multi-tarefa e para a organizacao pessoal das tarefas de acordo com prioridades

Para a gestao de topo esta ferramenta permite obter uma visao global do estado da

organizacao em termos de tempo gasto por tarefa executada sendo uma mais valia

para a previsao e gestaoalocacao de recursos

45 Visao geral sobre a arquitectura do WOW

O WOW e interessante nao so do ponto de vista de produto como tambem do

ponto de vista de plataforma Existem diversos plug-ins que estendem as funcional-

idades do WOW e existem ate projectos que pretendem usar a arquitectura do

WOW para criar produtos com fins diferentes do inicial (por exemplo o WOW-

Storm ndash um sistema de registo e classificacao social de ideias)

De modo a conseguir ter essa expansibilidade a plataforma WOW assenta sob

uma arquitectura distribuıda modular e expansıvel com uma componente central

ndash o core ndash estruturado em camadas logicas E no core que se situam todas as

1O Comet e um conceito semelhante ao Ajax introduzido por Alex Russel mas no qual e o servidor quetoma a iniciativa de ldquoenviarrdquo os dados ao browser sem que este tenha que efectuar um pedido Tambem econhecido por Ajax Push Reverse Ajax ou HTTP Streaming

41

Desenvolvimento

funcionalidades base da aplicacao quer a nıvel logico funcional e de apresentacao

quer a nıvel de gestao e configuracao

E possıvel a execucao de varias instancias do core simultaneamente em servidores

distintos o que permite a alta escalabilidade e disponibilidade desta aplicacao A

consistencia dos dados fica sempre garantida atraves da partilha da base de dados

e pelo balanceamento dos pedidos uma vez que cada um e encaminhado para uma

unica instancia

O WOW apresenta tambem a vantagem de ser uma plataforma extensıvel E

possıvel adicionar novas caracterısticas a plataforma atraves de componentes que se

podem ser divididos em duas categorias plugins e connectors

Os plugins sao componentes que se encontram no mesmo no fısico que a aplicacao

partilhando do mesmo contexto de execucao do core Sao assim uma forma mais

directa de obter informacao da plataforma visto que nao possuem restricoes de

acesso aos dados nem dependencias externas A arquitectura deste componente tera

assim que permitir varias execucoes instanciadas cada uma associada a um core

Por outro lado os connectors sao componentes que se encontram distribuıdos

comunicando externamente com o core Quer a sua execucao quer a obtencao

dos dados estao assim dependentes de interfaces de comunicacao externas que a

plataforma disponibiliza Estes componentes ao contrario dos plugins sao instan-

ciados unicamente e recorrem ao protocolo de comunicacao Java Messaging Service

(JMS) para comunicar com o core

46 WOW Offline

Para alem das opcoes tomadas relativamente a tecnologia a utilizar surgiu

tambem a necessidade de optar por um dos modos de execucao apresentados na

seccao 42

Das tres opcoes possıveis foi o modo ldquoaplicacao assume o estado offlinerdquo descrito

na seccao 423 que mereceu a maior atencao uma vez que reune as vantagens de

uma experiencia mais positiva para o utilizador (uma vez que este nao tem que

participar activamente na alteracao do modo execucao como descrito na seccao 421)

e nao constitui uma sobrecarga excessiva para servidor (como o modo abordado na

seccao 422)

No entanto esta opcao comprometia a complexidade da implementacao para alem

dos objectivos propostos para este projecto e para cumprir o prazo dado foi tomada

a decisao de implementar o modo ldquoutilizador deciderdquo especificando apenas de forma

teorica o modo ldquoaplicacao assume o estado offlinerdquo

As caracterısticas do Gears foram ja descritas na seccao 31 Na Figura 47

mostra-se a sua forma de funcionamento quando integrado numa web application

42

Desenvolvimento

Nesta figura representa-se o modulo LocalServer do Gears como um ponto de de-

cisao Aqui sao testadas as condicoes que determinam se o pedido sera interceptado e

servido localmente ou se prossegue para uma maquina remota E tambem represen-

tada uma base de dados que corresponde ao modulo Database mas que podera nao

ser utilizada Este modulo tal como o modulo Workerpool tem caracter opcional

e sao utilizados consoante os requisitos da aplicacao

A plataforma WOW lida com mais dados do que e necessario passar para o

lado do cliente Em conformidade com o ja exposto na seccao 411 volta-se a

frisar que nao se pretende recriar toda a logica de negocio nem os conteudos da

base de dados no cliente pela sua complexidade e volume de dados Pretende-se

pelo contrario permitir que os utilizadores tirem partido da capacidade de poder

consultar as suas ordens de trabalho quando nao dispoe de uma ligacao transferindo

apenas o essencial para isto seja possıvel

A pagina inicial do WOW apresenta um resumo das ordens de trabalho abertas

ndash enviadas e recebidas ndash que se pretende permitir visualizar offline (ver Figura 46)

Como prova de conceito foi efectuada uma abordagem pragmatica das varias possi-

bilidades descritas na seccao 42

461 Modo ldquoaplicacao deciderdquo com deteccao automatica da ligacao

A primeira abordagem estudada para a disponibilizacao das funcionalidades of-

fline foi o modo ldquoaplicacao deciderdquo com deteccao automatica de ligacao apresentado

na seccao 422 Para que isto seja possıvel foi implementado um mecanismo de ver-

ificacao periodica do estado da ligacao atraves de chamadas Ajax assıncronas O

resultado destes pedidos determina o estado da aplicacao executando as tarefas de

sincronizacao de dados sempre que pertinente Este metodo embora imediato e

simples de implementar depressa se revelou inadequado para o projecto devido ao

elevado consumo de recursos do servidor que a utilizacao intensiva faz esperar a

comunidade da plataforma WOW no principal cliente excede os 7000 utilizadores

Foi estimado que para uma utilizacao de fluidez aceitavel o estado da ligacao deveria

ser testado a cada cinco segundos Assumindo uma adesao (previsao pessimista) de

1 aos servicos offline assistir-se-ia a cerca de 840 pedidos adicionais por minuto

Mas o principal problema desta aproximacao prende-se com o facto de a ver-

ificacao ser feita em intervalos de tempo discretos levando a possibilidade de a

aplicacao poder ter em dado momento uma representacao errada do seu estado

real da ligacao Este problema e ilustrado na Figura 48 onde se ve claramente a

discrepancia entre o estado real da ligacao e a representacao interna que esta tem

Note-se que nesta janela de tempo qualquer accao do utilizador que exija uma

resposta sıncrona do utilizador leva-lo-a para um ldquobeco sem saıdardquo onde nao tera

43

Desenvolvimento

Figura 46 A pagina inicial do WOW apresenta um resumo das ultimas ordens de trabalhoenviadas e recebidas Na imagem pode-se observar a transicao do estado online para offline

acesso a versao offline porque a aplicacao nao fez a transicao automatica nem acesso

a versao online porque na verdade nao possui uma ligacao O que acontecera nesta

situacao sera uma tentativa de acesso ao servidor por parte da aplicacao numa

altura em que este se encontra indisponıvel e o resultado sera uma mensagem de

ldquopedido excedeu o tempordquo apresentado pelo browser Este e um estado sem retorno

porque apos o browser apresentar esta mensagem todos os recursos JavaScript ficam

indisponıveis tornando impossıvel o regresso ao estado anterior ou o tratamento do

erro de qualquer outra forma No entanto as chamadas Ajax podem ser tratadas de

forma especial para a eventualidade de falha e portanto nao constituem problema

44

Desenvolvimento

Figura 47 Ilustracao do funcionamento do Gears numa web application que utiliza ummotor Ajax Os pedidos HTTP ou HTTPS podem ser interceptados e tratados localmenteou podem ser feitos a uma maquina remota consoante se verificarem ou nao as condicoesexpressas no ponto 311 E representado um acesso a uma base de dados local (fornecidapelo Gears) mas a sua utilizacao e opcional

462 Implementacao do modo ldquoutilizador deciderdquo

Este modo de execucao foi ja descrito na seccao 421 e a sua principal carac-

terıstica e ser o utilizador a decidir se a aplicacao deve utilizar um servidor remoto

ou a maquina local como fornecedor de dados

Relativamente ao WOW o WOW Offline na vertente ldquoutilizador deciderdquo vem

alterar os seus casos de uso dando ao utilizador a possibilidade de alterar o estado

de execucao da aplicacao (entre online e offline) Resta dizer que no modo online se

mantem todas as funcionalidades anteriores e que no modo offline torna-se possıvel

visualizar os conteudos da pagina principal do WOW (Figura 46) e os detalhes das

ordens de trabalho (Figura 49) tal como expressa a Figura 410

Esta aproximacao foi utilizada na prova de conceito do WOW adicionando um

controlo a interface desta aplicacao que permite ao utilizador alternar entre os esta-

dos online e offline Na transicao de online para offline sao descarregados os recursos

necessarios para a execucao desta aplicacao sem recorrer a Internet Para o fazer

45

Desenvolvimento

Figura 48 Neste exemplo do modo ldquoaplicacao deciderdquo o teste da ligacao e feito e feito acada cinco segundos O resultado deste teste nao reflecte sempre o estado real da aplicacaopodendo levar a aplicacao a ter comportamentos indesejaveis Na figura assinala-se umperıodo de tempo no qual a representacao interna do estado da ligacao nao corresponde arealidade

e utilizado um recurso ResourceStore e um ManagedResourceStore (introduzidos

em 311) O primeiro e utilizado para armazenar a pagina principal do WOW ndash do-

ravante designada por homejsp ndash e o segundo e utilizado para armazenar imagens

folhas de estilo CSS e scripts JavaScript

Para a implementacao deste modo de execucao foram identificadas as seguintes

tarefas

1 Guardar informacao que permita a recriacao das paginas que se pretende

disponibilizar offline (utilizando o Gears)

2 Disponibilizar um controlo que permita alterar o estado de execucao atraves

da interaccao com a pagina principal

3 Durante a sincronizacao de dados apresentar o progresso da transferencia de

dados

O primeiro passo consistiu na identificacao de todos os conteudos que sao necessarios

transferir para a execucao offline Foi utilizado um recurso do Gears do tipo

ManagedResourceStore que recorre a um ficheiro manifesto para identificar to-

dos os ficheiros que deve transferir Este recurso e gerido automaticamente pelo

Gears transferindo para o cliente a versao mais recente sempre que e necessario

isto e sempre que exista um ficheiro manifesto com uma identificacao de versao que

seja diferente da actualmente disponıvel no cliente Uma vez identificados todos

ficheiros necessarios para a execucao offline num (ou mais) ficheiros manifesto o

Gears encarrega-se da sua actualizacao mas o preenchimento destes ficheiros man-

ifesto e manual o que se traduz num cuidado extra na manutencao da aplicacao

A forma como esta informacao e guardada deve tambem ser cuidadosamente

estudada A opcao mais flexıvel passa por utilizar o modulo Database apresentado

na seccao 311 e guardar a informacao de uma forma relacional Para a recriacao

das paginas pode ser disponibilizada uma versao HTML da pagina que funciona

46

Desenvolvimento

Figura 49 Pagina de visualizacao do detalhe de uma ordem de trabalho

como template nao possui quaisquer dados e e utilizada apenas em modo offline E

preenchida para cada pedido retirando os dados relevantes da base de dados

O modelo de dados do WOW torna esta opcao extremamente trabalhosa uma

vez que as entidades envolvidas na geracao de cada pagina de informacao sobre

cada ordem de trabalho tem relacoes de dependencia complexas seguindo padroes

muito variaveis Por exemplo em cada ordem de trabalho existe um formulario que

permite a sua progressao de estado com diversos campos opcionais e obrigatorios

este formulario e definido pelo administrador e esta relacionado nao apenas com o

tipo de ordem de trabalho mas tambem com o estado actual em que esta se encontra

e a accao que se pretende realizar O elevado numero de combinacoes de tipos de

ordem de trabalho estados e accoes que existem num dado momento juntamente

com a sua possibilidade de alteracao obrigariam a implementacao de uma logica de

negocio complexa o que esta fora do ambito deste projecto

47

Desenvolvimento

Figura 410 Esquema UML que expressa os casos de uso do WOW Offline no modoldquoutilizador deciderdquo

463 Especificacao do modo ldquoaplicacao assume o estado offlinerdquo

A aproximacao para o modo ldquoaplicacao assume o estado offlinerdquo foi tambem

dividida em varias tarefas

1 Guardar informacao que permita a recriacao da pagina principal do lado do

cliente no estado offline (utilizando o Gears)

2 Dotar a aplicacao do cliente de um mecanismo de deteccao da ligacao

3 Identificar os ldquomomentos chaverdquo em que devera ocorrer sincronizacao de dados

4 Implementar a sincronizacao de dados

A sincronizacao de dados deve ser feita em ambas as transicoes online-offline e

offline-online quer para transferir novos dados do servidor (os pedidos podem ser

alterados por outros utilizadores) quando se transita do estado quer para comunicar

eventuais alteracoes feitas em modo offline

Relativamente ao WOW o WOW Offline na vertente ldquoaplicacao assume o es-

tado offlinerdquo vem alterar os seus casos de uso dando ao utilizador a possibilidade

de activar esta funcionalidade A partir do momento que a funcionalidade esta ac-

tivada o utilizador deve tambem ter a possibilidade de gerir algumas preferencias

relacionadas com privacidade de dados Devera ter a hipotese de desactivar o ar-

mazenamento local e de remover todos os dados ja armazenados tal como descrito

na Figura 411

48

Desenvolvimento

Figura 411 Esquema UML que expressa os casos de uso do WOW Offline no modoldquoutilizador deciderdquo

A primeira vez que o WOW Offline e acedido por um cliente e caso seja detec-

tada a presenca do Gears todos os recursos necessarios a sua execucao sao trans-

feridos Todos os acessos posteriores serao feitos a estes recursos locais (recorda-se

que o Gears pode ser utilizado para os manter actualizados recorrendo ao Managed-

ResourceStore 311)

Atraves do JavaScript e possıvel interceptar os eventos de load e unload da

pagina que sao despoletados sempre que ocorre um re-acesso da mesma (incluindo

a accao refresh comum dos browsers) sempre que esta e abandonada ou ainda ou

ainda se a janela for encerrada

Tal como sugerido na seccao 462 a camada de interface desta aplicacao (cada

pagina individual em HTML) devera ser implementada como sendo um template

para apresentacao de dados sendo totalmente preenchida atraves de funcoes em

JavaScript O objectivo deste ponto e criar um padrao de dados que permita ao

JavaScript preencher os dados em cada pagina (template) independentemente de

qual seja a fonte ndash o servidor remoto ou a maquina local tal como exemplificado

no diagrama da Figura 412 Na figura a aplicacao recorre ao servidor remoto para

obter os dados pretendidos quando se encontra na presenca de uma ligacao mas

para dados que exijam uma carga de processamento pelo servidor este acto pode ser

49

Desenvolvimento

Figura 412 Esquema UML que expressa o acto de recolha de dados em modo online eoffline recorrendo ao servidor (modo online) e ao sistema de armazenamento de dadoslocal fornecido pelo Gears (modo offline)

substituıdo pelo envio de um campo de controlo que se destina a aferir se os dados

locais se encontram actualizados No caso de estarem actualizados a comunicacao

com o servidor pode ser substituıda por uma query a base de dados local

50

Capıtulo 5

Resultados e Futuros

Desenvolvimentos

Todo o estudo feito sobre o tema OWA foi ja abordado ao longo do documento

Neste capıtulo apresentam-se os resultados obtidos na implementacao da prova de

conceito que visava compreender a melhor forma de disponibilizar uma versao of-

fline no WOW uma plataforma de gestao de ordens de trabalho ja existente de-

senvolvida pela Critical Software SA

51 Resultados Obtidos

Os resultados obtidos neste projecto sao extremamente satisfatorios uma vez

que o estudo do tema OWA e a implementacao de uma prova de conceito que o

ilustrasse foi conseguido com sucesso

A funcionalidade offline foi adicionada ao produto WOW da Critical Software

SA permitindo a visualizacao de ordens de trabalho e dos seus detalhes mesmo na

ausencia de uma conexao activa a Internet Embora para a solucao implementada

tenha sido utilizada uma abordagem do tipo ldquoutilizador deciderdquo pretende-se que esta

seja convertida para ldquoaplicacao deciderdquo ou mesmo para uma aproximacao hıbrida

semelhante a utilizada pelas aplicacoes estudadas nas seccoes 351 e 352

Para a sua implementacao descrita no capıtulo 4 foram tomadas decisoes de or-

dem pratica que permitissem tornar o trabalho exequıvel nos prazos dados Tentou-

se sempre que estas decisoes afectassem o mınimo em termos de desempenho e de

experiencia para o utilizador Considera-se que a implementacao do modo offline

com uma transicao entre modos do tipo ldquoutilizador deciderdquo (ver seccao 42) reflecte

o compromisso entre o desempenho pretendido e os recursos disponıveis e para alem

51

Resultados e Futuros Desenvolvimentos

de ser um exemplo eficaz das possibilidades que as OWA podem trazer a aplicacao

WOW desenvolvida pela Critical Software e tambem um estudo que pode ser uti-

lizado para analisar a implementacao desta tecnologia noutros produtos da mesma

empresa

Note-se que o principal objectivo do trabalho era ganhar familiaridade com este

tema entender as suas vantagens e desvantagens e compreender as suas limitacoes

Tudo indica que existam varias possibilidades de implementacao deste paradigma

noutros produtos da Critical Software que pela sua natureza podem tambem tirar

partido da execucao offline

52 Trabalho Futuro

O desenvolvimento do conceito e formas de implementacao de OWA continua

em forte desenvolvimento no entanto a sua adopcao ainda nao e generalizada A

dificuldade da sua implementacao em web applications ja existentes e o principal

obstaculo a sua maior divulgacao

Ha tambem um factor que deve ser tido em consideracao a manutencao de

codigo A implementacao de uma versao offline de uma web application requer

a implementacao das mesmas regras de negocio (ou de uma versao simplificada)

utilizadas no servidor Para que isto seja possıvel e necessario ter em conta a

capacidade de processamento do cliente e o factor de duplicacao de codigo que

tornara a aplicacao mais difıcil de manter uma vez que uma alteracao a logica de

negocio do servidor implica tambem uma alteracao a sua versao offline

A prova de conceito implementada permite ja a visualizacao offline dos pedidos

abertos (enviados e recebidos) que constam na pagina principal (este numero e

fixo e pode ser alterado pelo administrador) Uma funcionalidade desejavel seria a

possibilidade de interaccao com a aplicacao em modo offline e sincronizacao com o

servidor quando existisse uma ligacao disponıvel

Foi estudada a utilizacao do modo de execucao ldquoaplicacao assume o estado of-

flinerdquo descrito em 423 e esta seria a forma desejavel para o WOW Offline no

entanto para que esta opcao seja viavel sera necessaria a implementacao de uma

forma eficiente de sincronizacao e armazenamento de dados de uma forma relacional

Para atingir este objectivo podera ser seguida uma polıtica de automacao do pro-

cesso no qual a versao online da aplicacao gera scripts de criacao para as tabelas

necessarias na base de dados da versao offline (nao existe nenhuma ferramenta para

o fazer portanto seria necessaria a sua implementacao) e no qual as paginas HTML

disponibilizadas pelo servidor aos clientes web (browser) servem como templates de

apresentacao de informacao e sao preenchidas de forma semelhante pelo servidor ndash

quando a aplicacao estiver online ndash ou pelo cliente atraves de funcoes em JavaScript

52

Resultados e Futuros Desenvolvimentos

ndash quando a aplicacao estiver offline No entanto no WOW devido a quantidade de

informacao tratada e devido as complexas relacoes entre as diferentes entidades e

de esperar que a complexidade da implementacao de um mecanismo deste tipo torne

esta aproximacao demasiado custosa

O HTML 5 embora um forte candidato ainda nao esta suficientemente desen-

volvido A sua especificacao ainda tem o caracter de Draft (rascunho) e esta sujeita

a modificacoes e a aceitacao e implementacao por parte dos browsers e portanto

de momento foi desconsiderado No entanto no futuro se esta especificacao atingir

um estado de maturidade que permita a sua adopcao devera ser considerada como

um possıvel caminho a seguir

53

Resultados e Futuros Desenvolvimentos

54

Capıtulo 6

Conclusoes

Neste capıtulo sao apresentadas as conclusoes do projecto e consideracoes finais

relativamente a tecnologia estudada

61 Conclusoes

O rapido desenvolvimento tecnologico faz prever que a disponibilidade de ligacao

a Internet seja cada vez mais facil e mais rapido mas vao continuar a existir lugares

onde o acesso e limitado e onde as OWA podem desempenhar um papel de relevo

Por outro lado esta tecnologia pode tambem ser utilizada para melhorar o desem-

penho de paginas web com uma necessidade elevada de imagens ou outros recursos

dispendiosos em termos de espaco e foram ate estudados dois exemplos da utilizacao

desta vertente desta tecnologia em 353

Acredita-se que as OWAs vem responder a uma necessidade real por parte das

web applications actuais e que a evolucao que representam se compara a que se

assistiu dos thin-clients para os fat-clients em termos de autonomia do servidor

A capacidade de oferecer conteudos dinamicos no browser independentemente da

existencia de uma ligacao reune as vantagens tıpicas das web applications como

ausencia de instalacao e actualizacoes instantaneas com as vantagens das aplicacoes

de desktop em capacidade de processamento e armazenamento de dados na maquina

local

As tecnologias disponıveis ate a data estudadas no ambito deste projecto que

permitem o desenvolvimento de OWAs e que apresentam maior maturidade sao o

Gears e o Adobe AIR Ambas se apresentam sobre a forma de plugins que necessitam

de uma instalacao extra para poderem ser utilizadas Apesar de esta instalacao ser

55

Conclusoes

apenas necessaria uma vez podera constituir um factor de desencorajamento a sua

adopcao

O HTML 5 uma especificacao abordada neste documento na seccao 34 podera

ser uma alternativa que oferece funcionalidades offline a uma web application sem a

necessidade de qualquer instalacao no entanto esta especificacao ainda nao foi aceite

pelos principais browsers ndash o documento que define o HTML 5 ainda tem o estatuto

de Draft ndash e ainda nao e possıvel antecipar quando e que isto podera acontecer

Um dos problemas que surge frequentemente na implementacao de uma versao

offline para uma web application e a necessidade de sincronizacao de dados Quando

a informacao pode ser alterada por varios utilizadores simultaneamente e necessario

prever os conflitos que daı podem surgir e dotar a aplicacao de uma forma de os

resolver ou alertar o utilizador para a necessidade de alteracao dos dados

Em conclusao todos os objectivos propostos para este projecto foram atingidos

A prova de conceito implementada reflecte de forma clara as possibilidades oferecidas

pela tecnologia OWA e sera utilizado no futuro para compreender a melhor forma

de o implementar de forma definitiva no WOW

56

Referencias

[Ada08] Lucas Adamski Introducing Adobe AIR security model Fevereiro de2008 Disponıvel em httpwwwadobecomdevnetairarticles

introduction_to_air_securityhtml acedido em Marco de 2008

[Ado08] Adobe Adobe AIR 10 Security White Paper 2008 Disponıvel emhttpdownloadmacromediacompubairdocumentation1air_

securitypdf acedido em Marco de 2008

[Alm08] Dion Almaer Gears as a bleeding-edge html 5 implementa-tion March 2008 Disponıvel em httpalmaercomblog

gears-as-a-bleeding-edge-html-5-implementation acedido emMarco de 2008

[BL96] Tim Berners-Lee The world wide web Past present and future Agostode 1996 Disponıvel em httpwwww3orgPeopleBerners-Lee

1996ppfhtml acedido em Abril de 2008

[CDGH08] Mike Chambers Daniel Dura Dragos Georgita and Kevin Hoyt AdobeAIR for JavaScript Developers OrsquoReilly Media 2008 Disponıvel emhttponairadobecomfilesAIRforJSDevPocketGuidepdf ace-dido em Abril de 2008

[Con99] Jim Conallen Modeling Web Application Architectures with UML Junho1999 Disponıvel em httpwwwumlorgcnUMLApplicationpdf

webappspdf acedido em Maio de 2008

[Ent07] Entrust What is a public key information 2007 Disponıvel em http

wwwentrustcompkihtm acedido em Junho de 2008

[Gar05] Jesse James Garret Ajax A new approach to web applicationsFebruary 2005 Disponıvel em httpwwwadaptivepathcomideas

essaysarchives000385php acedido em Marco de 2008

[Greon] Philip Greenspun Philip and Alexrsquos Guide to Web Publishing 2003(last revision) Disponıvel em httpphilipgreenspuncompandaacedido em Junho de 2008

[Gro02a] App Design Group Thick vs thin client comparison 2002 Disponıvelem httpwwwdonjacobsvwcomimagesweekendspecials

Thick-vs-Thinpdf acedido em Junho de 2008

57

REFERENCIAS

[Gro02b] Technical Research Group Thin Client Tecnhology - WhitePaper 2002 Disponıvel em httpwwwpicktrgcompubs

thinclientwhitepaperpdf acedido em Junho de 2008

[Gro08] Miniwatts Marketing Group World internet usage March 2008Disponıvel em httpwwwinternetworldstatscomstatshtm ace-dido em Abril de 2008

[Hic08] Ian Hickson HTML 5 Draft Recommendation 2008 Disponıvelem httpwwwwhatwgorgspecsweb-appscurrent-work ace-dido em Marco de 2008

[Kha] Olga Kharif Top 10 municipal wifi plans Disponıvel em http

imagesbusinessweekcomss0608muni_wifiindex_01htm ace-dido em Marco de 2008

[Lab07] Mozilla Labs Prism Outubro 2007 Disponıvel em httplabs

mozillacom200710prism acedido em Marco de 2008

[Loo06] Chris Loosley Rich Internet ApplicationsDesign MeasurementandManagement Challenges 2006 Disponıvel em httpwwwkeynote

comdocswhitepapersRichInternet_5pdf acedido em Maio de2008

[Mic08] Microsoft Introduction to Occasionally Connected Applications us-ing Sync Services for ADONET 2008 Disponıvel em httpmsdn

microsoftcomen-ussyncbb887608aspx acedido em Junho de2008

[Nao08] Erica Naone Offline web applications Abril 2008 Disponıvelem httpwwwtechnologyreviewcomread_articleaspxch=

specialsectionsampsc=emerging08ampid=20245 acedido emAbril de 2008

[NJN00] Jason Nieh Yang S Jae and Naomi Novik A comparison of thin-clientcomputing architectures 2000 Disponıvel em httpwwwnclcs

columbiaedupublicationscucs-022-00pdf acedido em Maio de2008

[OrsquoR06] Tim OrsquoReilly Web 20 compact definition Trying again Dezembro2006 Disponıvel em httpradaroreillycomarchives200612

web-20-compact-definition-tryihtml acedido em Marco de 2008

[OrsquoR09] Tim OrsquoReilly What is Web 20 Design patterns and business modelsfor the Next Generation of Software 20053009 Disponıvel emhttpwwworeillynetcompubaoreillytimnews200509

30what-is-web-20html acedido em Marco de 2008

[Rus06] Alex Russel Comet Low latency data for the browser March Marco2006 Disponıvel em httpalexdojotoolkitorgp=545 acedidoem Marco de 2008

58

REFERENCIAS

[Sad97] Darleen Sadoski Clientserver software architecturesndashan overviewAgosto 1997 Disponıvel em httpwwwseicmuedustr

descriptionsclientserver_bodyhtml acedido em Junho de2008

[Sch96] George Schussel Clientserver past present and future 1996

[Smi07] Kevin C Smith Css filters - will the browser apply the rule July 2007Disponıvel em httpcentriclecomrefcssfilters acedido emMarco de 2008

[vK08] Anne van Kesteren The XMLHttpRequest Object W3C Work-ing Draft 15 Abril 2008 Disponıvel em httpwwww3orgTR

XMLHttpRequest acedido em Abril de 2008

[Wil06] Greg Wilkins Why ajax comet July Julho 2006 Disponıvel emhttpwwwwebtidecomdownloadswhitePaperWhyAjaxhtml ace-dido em Abril de 2008

59

REFERENCIAS

60

Anexo A

Screenshots

Algumas imagens de aplicacoes que utilizam funcionalidades offline ilustrativasda tecnologia abordada neste documento

Figura A1 Dialogo apresentado ao utilizador na primeira activacao das funcionalidadesoffline no Google Docs amp Spreadsheets

61

Screenshots

Figura A2 Na activacao das funcionalidades offline e tambem oferecida a possibilidadeda criacao de alguns atalhos por exemplo no ambiente de trabalho

Figura A3 O Google Docs mantem a todo o momento a possibilidade de alteracao destasdefinicoes ou da anulacao dos servicos offline para um dado computador

62

Screenshots

Figura A4 Apos a instalacao do Gears qualquer visita ao Remember The Milk despoletauma sincronizacao que ocorre automaticamente e sem necessidade de intervencao por partedo utilizador

Figura A5 Apos completar a sincronizacao de dados mesmo que a ligacao a Internetseja perdida o Remember the Milk continua disponıvel no browser (com excepcao dasfuncionalidades que pela sua natureza exigem uma ligacao como por exemplo partilhade tarefas e envio de convites)

63

Page 11: O ine Web Applications

CONTEUDO

4 Desenvolvimento 3341 Como ficar offline 33

411 Funcionalidades disponıveis em modo offline 3442 Modos de execucao 35

421 Modo ldquoutilizador deciderdquo 36422 Modo aplicacao decide 36423 Modo ldquoaplicacao assume o estado offlinerdquo 37

43 Sincronizacao de dados 38431 Quando sincronizar 39

44 WOW 4045 Visao geral sobre a arquitectura do WOW 4146 WOW Offline 42

461 Modo ldquoaplicacao deciderdquo com deteccao automatica da ligacao 43462 Implementacao do modo ldquoutilizador deciderdquo 45463 Especificacao do modo ldquoaplicacao assume o estado offlinerdquo 48

5 Resultados e Futuros Desenvolvimentos 5151 Resultados Obtidos 5152 Trabalho Futuro 52

6 Conclusoes 5561 Conclusoes 55

Referencias 59

A Screenshots 61

viii

Lista de Figuras

21 Arquitectura de um sistema thin-client em duas camadas (a esquerda)e em tres camadas (a direita) Note-se a inclusao do servidor (main-frame) na definicao das camadas desta arquitectura devido a fortedependencia cliente-servidor 9

22 Arquitectura de um fat-client em duas camadas (a esquerda) e emtres camadas (a direita) 10

23 Comparacao do modelo de web aplications sıncrono paginas estaticase interactivas abordados nas seccoes 221 e 222 com o modelo deweb applications Ajax (assıncrono) abordado na seccao 223 Figuraadaptada de http www adaptivepath com 15

31 Esquema UML do processo efectuado pelos recursos do Gears do tipoManagedResourceStore para a actualizacao dos conteudos definidosno ficheiro manifesto 29

41 Exemplo de uma arquitectura de uma web application sem uma ca-mada de abstraccao de dados Figura adaptada de http gears

google com 33

42 Exemplo de uma arquitectura de uma web application com uma ca-mada de abstraccao de dados Figura adaptada de http gears

google com 34

43 Exemplo de uma arquitectura de uma web application com uma ca-mada de abstraccao de dados e um data switch Figura adaptada dehttp gears google com 35

44 Esquema grafico ilustrando uma OWA executando no browser uti-lizando um modo de execucao do tipo ldquoaplicacao deciderdquo com de-teccao automatica do estado da ligacao via pedidos Ajax assıncronosa cada cinco segundos 37

45 Detalhe de um conjunto possıvel de estados e respectivas transicoespara uma dada ordem de trabalho no WOW desde a sua submissaono sistema ate a sua conclusao em fecho ou cancelamento Esta figurarepresenta apenas um exemplo ja que o mapa de estados para umaordem de trabalho e dinamico e pode ser alterado por um admin-istrador Figura retirada de uma brochura promocional do WOWCritical Software SA 41

ix

LISTA DE FIGURAS

46 A pagina inicial do WOW apresenta um resumo das ultimas ordensde trabalho enviadas e recebidas Na imagem pode-se observar atransicao do estado online para offline 44

47 Ilustracao do funcionamento do Gears numa web application que uti-liza um motor Ajax Os pedidos HTTP ou HTTPS podem ser inter-ceptados e tratados localmente ou podem ser feitos a uma maquinaremota consoante se verificarem ou nao as condicoes expressas noponto 311 E representado um acesso a uma base de dados local(fornecida pelo Gears) mas a sua utilizacao e opcional 45

48 Neste exemplo do modo ldquoaplicacao deciderdquo o teste da ligacao e feitoe feito a cada cinco segundos O resultado deste teste nao reflectesempre o estado real da aplicacao podendo levar a aplicacao a tercomportamentos indesejaveis Na figura assinala-se um perıodo detempo no qual a representacao interna do estado da ligacao nao cor-responde a realidade 46

49 Pagina de visualizacao do detalhe de uma ordem de trabalho 47410 Esquema UML que expressa os casos de uso do WOW Offline no

modo ldquoutilizador deciderdquo 48411 Esquema UML que expressa os casos de uso do WOW Offline no

modo ldquoutilizador deciderdquo 49412 Esquema UML que expressa o acto de recolha de dados em modo

online e offline recorrendo ao servidor (modo online) e ao sistemade armazenamento de dados local fornecido pelo Gears (modo offline) 50

A1 Dialogo apresentado ao utilizador na primeira activacao das funcional-idades offline no Google Docs amp Spreadsheets 61

A2 Na activacao das funcionalidades offline e tambem oferecida a possi-bilidade da criacao de alguns atalhos por exemplo no ambiente detrabalho 62

A3 O Google Docs mantem a todo o momento a possibilidade de alteracaodestas definicoes ou da anulacao dos servicos offline para um dadocomputador 62

A4 Apos a instalacao do Gears qualquer visita ao Remember The Milkdespoleta uma sincronizacao que ocorre automaticamente e sem ne-cessidade de intervencao por parte do utilizador 63

A5 Apos completar a sincronizacao de dados mesmo que a ligacao aInternet seja perdida o Remember the Milk continua disponıvel nobrowser (com excepcao das funcionalidades que pela sua naturezaexigem uma ligacao como por exemplo partilha de tarefas e enviode convites) 63

x

Lista de Tabelas

21 Comparacao entre thin-clients e fat-clients 7

31 Comparacao das funcionalidades oferecidas pelo Adobe AIR para asplataformas web e desktop 30

32 Resumo da utilizacao de tecnologias OWA em algumas web applica-tions consideradas na analise do estado da arte 31

xi

LISTA DE TABELAS

xii

Glossario

fat-client Cliente que nao depende totalmente de umservidor central para as suas actividadesde processamento e possui frequentementedispositivos de armazenamento de dados

6ndash8

thin-client Cliente que depende de um servidor centralpara as suas actividades de processamento

5ndash8

web application Sistema web (servidor rede HTTPbrowser) onde accoes do utilizador(navegacao e introducao de informacao)afectam o estado logico da aplicacao

i iii1ndash311ndash1517ndash1921ndash232728 3336ndash3842 5556

API Application Programming Interface 10 1718 2326 28

ASP Linguagem interpretada pelo servidorque permite a criacao de paginas webdinamicas Desenvolvida pela Microsoft

11

BSD Berkeley Software Distribution 28

CSS Cascading Style Sheets 12 2021 2324 46

DHTML Dynamic HyperText Transfer Protocol 24DOM Document Object Model 10 12

20 2324

DTD Document Type Definition 24

xiii

Glossario

ECMAScript Padrao de linguagem de programacaodefinido pela Ecma International que orig-inou o JavaScript e o JScript

24

Flash Conteudo interactivo de um ficheiro emformato SWF E desenvolvido pela Adobee visualizado atraves do Adobe FlashPlayer

21

Flex Framework baseada em XML e Action-Script desenvolvida pela Adobe para a pro-gramacao de Rich Internet Applications(RIA)

21

GPL GNU General Public License 23

HTML HyperText Markup Language 1 10ndash12 2124ndash2649

HTTP HyperText Transfer Protocol 2 26

JMS E uma API em Java que permite a troca demensagens entre componentes de software

42

JSON JavaScript Object Notation permite atroca de dados codificados num formatode texto de simples leitura

12 1828 34

LGPL GNU Lesser General Public License 23

Mozilla Prism Browser simplificado e ldquointerpretadorrdquo deeXtensible User Interface Language (XUL)(tambem designado por XULRunner) queacolhe web applications sem a interfacegrafica habitual de um browser

25

MPL Mozilla Public License 23

OCA Occasionally Connected Application 39OWA Offline Web Application i iii

2ndash515 1725 2628 3133 3651 5255 56

PDF Portable Document Format 21

xiv

Glossario

PHP Linguagem interpretada pelo servidorque permite a criacao de paginas webdinamicas mas que pode tambem ser in-vocada a partir da linha de comandos

11

pagina web estatica Pagina web que devolve sempre a mesmaresposta a todos os pedidos para todos osutilizadores e em qualquer contexto

5 9

RIA Rich Internet Applications web appli-cations que apresentam funcionalidadessemelhantes as desktop applications masque mantem a informacao no lado do servi-dor

5 1520 28

RSS Really Simple Syndication 27

SLA Service Level Agreement 40SQLite Segundo a definicao oficial SQLite is a

software library that implements a self-contained serverless zero-configurationtransactional SQL database engine

17

SSB Site Specific Browser 25SSL Secure Sockets Layer 22SWF ShockWave Flash 21

URL Uniform Resource Locator 18

VPN Virtual Private Network 38

WOW Work Orders Web Plataforma de gestaode ordens de trabalho e do seu fluxo de-senvolvida pela Critical Software SA

i iii28 3340ndash434551ndash5356

WWW World Wide Web 11 1214

XBL eXtensible Binding Language 24XHTML eXtensible HyperText Markup Language 12XML eXtensible Markup Language 11 12

23 2428

XSLT eXtensible Stylesheet Language Transfor-mation

12

XUL eXtensible User Interface Language xiv23ndash25

xv

Glossario

xvi

Capıtulo 1

Introducao

Neste capıtulo enquadra-se o tema do projecto introduzindo alguns dos conceitos

nos quais se baseia Apresentam-se as motivacoes ambito objectivos e a estrutura

deste documento

11 Enquadramento

A Internet foi originalmente concebida para ser um espaco de partilha de in-

formacao onde pessoas (atraves de maquinas) pudessem comunicar Na sua origem

as paginas eram estaticas constituıdas por texto formatado em HyperText Markup

Language (HTML) e ligadas entre si [BL96] Hoje encontramos conteudos cada vez

mais complexos e dinamicos incluindo som vıdeo ou streams multimedia [Loo06] e

em 2005 foi introduzido por [OrsquoR09] o termo Web 20

De acordo com [Greon] um website pode pertencer a uma ou varias das seguintes

categorias

bull Documento ndash um website essencialmente estatico onde alteracoes a uma

parte do conteudo nao tem implicacoes no seu comportamento

bull Base de dados ndash um directorio de informacao organizada em categorias

bull Aplicacao ndash um website dinamico que utiliza uma linguagem executada ou

interpretada do lado do servidor e que processa as accoes ou informacao in-

troduzida pelo utilizador para fornecer um servico ou nova informacao

A ultima destas categorias constitui aquilo que e normalmente designado por

web application O conceito utilizado ao longo deste documento e o mesmo que

o introduzido por Jim Coallen em [Con99] que define web application como um

1

Introducao

sistema web (servidor rede HyperText Transfer Protocol (HTTP) browser) onde

accoes do utilizador (navegacao e introducao de informacao) afectam o estado logico

da aplicacao A sua definicao tenta estabelecer que uma web application e um

sistema de software com estado de negocio1 e que a sua interface de interaccao com

o utilizador e distribuıdo atraves de um sistema web

12 Motivacao

A quantidade de informacao que e produzida e armazenada com recurso a es-

tas web applications disponıveis online tais como e-mail blogues ou mesmo docu-

mentacao tornam por vezes a disponibilidade de ligacao uma condicao necessaria

a produtividade e como consequencia desta barreira muitos potenciais utilizadores

opoem-se a adopcao de produtos web em detrimento das tradicionais desktop appli-

cations

Assegurar o acesso a uma ligacao de Internet e hoje muito mais facil A Internet

movel e ja uma realidade e encontra-se amplamente divulgada mas continuam a

existir diversas situacoes nas quais os utilizadores estao privados de uma ligacao

a Internet tais como uma viagem de metro ou de aviao ou quando se encontram

deslocados do seu paıs de origem e nao possuem nenhum plano de subscricao

Uma OWA consiste numa web application que para alem de manter todas as

caracterısticas anteriores se mantem disponıvel mesmo na ausencia de uma ligacao

a Internet e surge como uma tentativa de estreitar as barreiras existentes entre a

web e o desktop Isto significa que devera existir um mecanismo capaz de assegurar

a manutencao do estado logico da aplicacao quando a ligacao com o servidor e

quebrada permitindo ao utilizador continuar a utilizar a aplicacao e que sera capaz

de informar o servidor do estado em que a aplicacao se encontra quando a ligacao for

reposta A principal vantagem que advem desta possibilidade e evidente eliminar

a necessidade da existencia de uma ligacao a Internet para que a aplicacao possa ser

utilizada

Por outro lado a vontade de integracao de funcionalidades tıpicas das desktop

applications nas web applications foi um dos principais factores que impulsionou o

desenvolvimento deste conceito uma vez que obrigou a uma reflexao ldquopara alem

do browserrdquo e a uma adaptacao das arquitecturas existentes que permitisse ou o

acesso a funcionalidades disponibilizadas pelo sistema operativo ou pelo menos a

funcionalidades semelhantes Pretende-se com esta aproximacao tornar possıveis

interaccoes entre o desktop e o browser tais como arrastar um ficheiro para um

formulario web de upload de conteudos melhor suporte para o historico do clipboard

ou ainda o acesso ao sistema de ficheiros local Atingir estes objectivos reflecte-se

1NT business state

2

Introducao

num novo paradigma que reune as vantagens das web applications tais como os

updates instantaneos ou o facto de nao ser necessaria nenhuma instalacao e das

desktop applications como por exemplo persistencia no armazenamento de dados

acesso a funcionalidades do sistema operativo ou integracao e interaccao com outras

aplicacoes sejam elas web applications ou desktop applications

13 Ambito

Este projecto foi realizado na Critical Software SA no ambito do Mestrado

Integrado em Engenharia Informatica e Computacao (MIEIC) da Faculdade de En-

genharia da Universidade do Porto (FEUP) entre os meses de Fevereiro e Julho de

2008

14 Objectivos

Sao objectivos deste projecto

1 Estudar e documentar o tema das OWAs acompanhando os ultimos desenvolvi-

mentos nesta materia

2 Analisar o estado da arte fazendo uma analise crıtica e objectiva sobre as

diversas metodologias existentes

3 Implementar uma prova de conceito que permita a execucao offline de uma

web application documentando todo o processo

4 Estudar a possibilidade de permitir interaccao com a aplicacao (insercoes e

alteracoes aos dados) em modo offline

Em resumo o objectivo deste projecto foi estudar documentar e implementar

uma prova de conceito relacionada com o tema Offline Web Applications (OWA)

Este tema embora nao seja totalmente novo ganhou destaque ao longo do ano de

2007 com o surgimento de diversas ferramentas que se destinam a aproximar web

applications das desktop applications

15 Estrutura do documento

Este documento esta organizado em diferentes seccoes apresentando o projecto

numa sequencia logica organizada da seguinte forma

No capıtulo 1 faz-se uma breve apresentacao do conceito OWAs e do contexto em

que surge Apresenta-se tambem a estrutura do documento e definem-se os

termos e acronimos utilizados

3

Introducao

No capıtulo 2 faz-se uma descricao da evolucao das tecnologias que antecedem as

OWAs e das vantagens e desvantagens de cada uma como forma de enquadra-

mento

No capıtulo 3 analisa-se o estado da arte nesta materia Introduzem-se diversas

tecnologias directamente relacionadas com o tema deste projecto exemplos de

aplicacoes que as usam e as razoes que fundamentam as escolhas de tecnologias

efectuadas

O capıtulo 4 contem o desenvolvimento do projecto Analisa-se a plataforma

WOW de gestao integrada de ordens de trabalho a tecnologia escolhida e

a forma como foi utilizada para implementar a capacidade de execucao offline

O capıtulo 5 descreve os resultado obtidos comparando-os com as expectativas

iniciais do projecto e apresenta desenvolvimentos futuros e possibilidades de

continuacaoaplicacao do conhecimento adquirido

No capıtulo 6 apresentam-se as conclusoes

4

Capıtulo 2

Enquadramento do Projecto

Neste capıtulo apresenta-se um breve resumo da evolucao das arquitecturas de

software cliente-servidor e a forma como estas se comparam a evolucao da Inter-

net procurando estabelecer uma analogia entre o percurso de ambas as tecnolo-

gias Compara-se o comportamento e arquitectura dos thin-clients as paginas web

estaticas a evolucao dos fat-clients as paginas interactivas Web 20 e Ajax e

defende-se que as OWA constituem um proximo passo logico e evolutivo aproxi-

mando a web do desktop Referem-se ainda os principais factores que justificam a

importancia das OWAs e a estreita relacao que tem com as Rich Internet Application

(RIA)s

21 Evolucao das arquitecturas de software

Os termos thin-client e fat-client sao utilizados quer para descrever arquitecturas

logicas (de software) quer para descrever arquitecturas fısicas (de hardware) Neste

capıtulo excepto quando seja dada indicacao em contrario estes termos referem-se

sempre a uma arquitectura logica

Adicionalmente quando se trata de arquitecturas cliente-servidor pode-se estu-

dar a arquitectura desenvolvida do sistema como um todo da arquitectura do servi-

dor ou da arquitectura do cliente Para evitar equıvocos em especial na seccao 213

especifica-se em cada caso qual o sistema estudado

211 Thin-clients

Um thin-client e um computador cliente ou software cliente que no contexto

de uma arquitectura cliente-servidor depende de um servidor central para as suas

5

Enquadramento do Projecto

actividades de processamento e proporciona um canal de entrada e saıda de in-

formacao entre o utilizador e o servidor remoto Este termo quando aplicado a

hardware refere-se habitualmente a um computador que se destina a ser utilizado

como cliente de rede sem armazenamento local e com capacidade de processamento

reduzida [Gro02b] mas o conceito que aqui se analisa refere-se a uma arquitectura

de software que remonta ao inıcio das aplicacoes cliente-servidor

No inıcio da historia da computacao terminais ligavam-se directamente a main-

frames responsaveis por todo o processamento Nesta arquitectura era necessario

desenvolver duas aplicacoes distintas uma aplicacao central no servidor (main-

frame) responsavel pela gestao de toda a informacao e por todas as operacoes de

comunicacao e uma aplicacao de visualizacao instalada no cliente (terminal) O

papel destes terminais era apenas disponibilizar ao utilizador um meio de comu-

nicacao (entrada e saıda) e apresentacao dos resultados do servidor Nao tinham

um papel activo no calculo nem na logica de negocio e frequentemente nao tinham

tambem nenhum mecanismo de armazenamento de dados

Como vantagens esta arquitectura apresenta uma reduzida necessidade de con-

figuracao e manutencao do lado do cliente Uma vez que o centro do processamento

e manipulacao de dados ocorre no servidor existe tambem uma centralizacao da

informacao [NJN00] que introduz um ponto crıtico de falha1 Actualizacoes e novas

funcionalidades sao faceis de distribuir uma vez que requerem apenas alteracoes no

servidor [Gro02a]

212 Fat-clients

Contrastando com os thin-clients nesta arquitectura os clientes implementam

ja uma parte da logica de negocio e sao responsaveis pelo processamento de dados

Estes fat-clients vieram responder a necessidade crescente de aplicacoes com um

nıvel de interactividade e capacidade de configuracao maior que as oferecidas pela

arquitectura thin-client descrita na seccao 211 Apesar de manterem a sua de-

pendencia do servidor podem tambem ser executados sem uma conexao activa uma

vez que dispoe de armazenamento de dados local o que lhes confere a capacidade

de persistencia de dados e do estado de execucao entre cada sessao

Foi disponibilizando este controlo sobre o estado da aplicacao bem como acesso

a recursos locais (por exemplo sistema de ficheiros e perifericos) que surgiram as

primeiras verdadeiras desktop applications No entanto cada cliente tinha que ser

separadamente instalado no computador pessoal de cada utilizador que pretendesse

utilizar ou interagir com a aplicacao e uma actualizacao ao servidor implicava in-

variavelmente uma actualizacao manual tambem no cliente Uma vez que nem todos

1NT single point of failure

6

Enquadramento do Projecto

Thin-clients Fat-clientsNao toma parte no processamento dedados nem possui acesso ao sistema deficheiros

Participa activamente no processa-mento de dados recorrendo ao sis-tema de armazenamento local para ar-mazenamento de dados

Nao mantem registo do estado logicoda aplicacao entre duas sessoes de uti-lizacao

O acesso ao armazenamento localpermite-lhe manter registo do estadologico da aplicacao entre duas sessoes

O thin-client nao necessita de qualquerinstalacao estando ldquopronto a utilizarrdquo

E geralmente necessario instalar aaplicacao para poder interagir com oservidor

Qualquer update no servidor reflecte-seimediatamente por todos os clientes

Embora a aplicacao cliente possa aler-tar para existencia de novas versoes asactualizacoes tem que ser manualmenteinstalados pelo cliente

O software do cliente destina-se apenasa apresentacao de dados e comunicacaocom o servidor sendo portanto de sim-ples implementacao

Como o software do cliente toma parteactiva no processamento de dadosa sua implementacao requer cuidadosadicionais

Grande mobilidade uma vez que todaa informacao e mantida no servidor

Parte da informacao podera estar ape-nas do lado cliente pelo que existemalgumas restricoes a sua mobilidade

Tabela 21 Comparacao entre thin-clients e fat-clients

os utilizadores actualizam regularmente as suas aplicacoes o servidor tem que estar

preparado para lidar com versoes antigas2 ou descontinuar os seus servicos a uma

parte da sua comunidade de utilizadores ate que estes actualizem os seus sistemas

Como os utilizadores passam a utilizar os seus recursos locais para armazenamento

de dados as alteracoes que nao sejam sincronizadas com o servidor estao apenas

disponıveis nos seus computadores pessoais o que introduz uma restricao a mobili-

dade

Pode-se afirmar que as vantagens dos thin-clients sao as desvantagens dos fat-

clients e que as vantagens dos fat-clients sao as vantagens dos thin-clients tal como

se ilustra na Tabela 21

213 Arquitecturas cliente-servidor

Introduzidos os termos thin-client e fat-client interessa reafirmar que ambos

podem ser vistos como arquitecturas cliente-servidor Um cliente define-se como

um solicitador de servicos e um servidor como um prestador de servicos tal como

definido por [Sch96] e [Sad97]

2NT backward compatibility

7

Enquadramento do Projecto

As arquitecturas cliente-servidor sao categorizadas pela modularizacao com que

sao desenhadas sendo consideradas as seguintes camadas

1 Interface grafica (front-end) atraves da qual os utilizadores interagem com

a aplicacao Quando este modulo e implementado separadamente dos outros

dois constitui uma aplicacao thin-client por si so uma vez que nao implementa

regras de negocio (embora possa definir validacoes de formularios de insercao de

dados por exemplo) A informacao introduzida pelo utilizador e enviada para

o servidor que processa o seu pedido e retorna uma resposta Este processo

repete-se ate que o utilizador atinja o seu objectivo ou se desligue do sistema

2 A logica de negocio tambem designada por camada intermedia que imple-

menta as regras de aceitacao e validacao de todos os dados introduzidos pelo

utilizador E tambem a plataforma de comunicacao que une a camada superior

de visualizacao com a camada de acesso a dados

3 A camada de dados inclui quer o sistema de persistencia de dados onde sao

armazenados os dados relevantes como tambem os mecanismos necessarios

para a sua pesquisa seleccao e alteracao

Os thin-clients quando observados no seu conjunto de cliente e servidor podem

ser vistos quer como sistemas de duas camadas quer como sistemas de tres camadas

dependendo apenas da forma como o servidor for implementado No caso de na

implementacao do servidor nao se distinguir a camada de acesso a dados da camada

da logica de negocio sao designados por sistemas de duas camadas Caso seja feita

esta distincao sao designados por sistemas de tres camadas Ambos os casos sao

ilustrados na Figura 21

Historicamente os fat-clients eram implementados numa arquitectura em duas

camadas Possuıam apenas um modulo de visualizacao de dados designado por

camada de interface e um modulo que implementava toda a logica de negocio e

regras de acesso a base de dados No entanto com a introducao de ligacoes mais

rapidas e de computadores pessoais com maior capacidade de processamento e so-

bretudo devido a complexidade crescente das aplicacoes a logica de negocio e a

camada de acesso a dados tornaram-se independentes Este modelo e designado por

arquitectura em tres camadas e e ilustrado na Figura 22

22 Evolucao na Internet

Ao analisar a evolucao das arquitecturas das aplicacoes desenvolvidas para a

Internet podemos encontrar um paralelismo com a historia da arquitectura de soft-

ware

8

Enquadramento do Projecto

Figura 21 Arquitectura de um sistema thin-client em duas camadas (a esquerda) e emtres camadas (a direita) Note-se a inclusao do servidor (mainframe) na definicao dascamadas desta arquitectura devido a forte dependencia cliente-servidor

221 Paginas web estaticas

Uma pagina web estatica devolve sempre a mesma resposta a todos os pedidos

para todos os utilizadores e em qualquer contexto utilizando o hipertexto como

forma de ligacao entre diversas paginas estaticas

A informacao e armazenada num servidor e o papel do cliente e apenas a apre-

sentacao da informacao Esta forma de disponibilizacao de informacao pode assim

ser comparada com os thin-clients descritos na seccao 211 o utilizador acede a

um website estatico para visualizar informacao sem que o cliente tome parte no

processamento A unica diferenca e que no caso da web estatica a informacao ap-

resentada e sempre a mesma enquanto que nos thin-clients era frequente existir a

possibilidade de insercao de dados no cliente e apos o seu processamento servidor

nova informacao poderia ser apresentada O hipertexto e utilizado para ligar as

paginas entre si numa rede de conteudos relacionados e a navegacao sıncrona era

feita atraves de cliques do rato a cada clique uma nova pagina era apresentada

Este modelo sıncrono e ilustrado na Figura 23

222 Paginas web interactivas e paginas web dinamicas

O JavaScript e uma linguagem interpretada de scripting que tem os browsers

como principal ambiente de acolhimento Os browsers utilizam uma Application

9

Enquadramento do Projecto

Figura 22 Arquitectura de um fat-client em duas camadas (a esquerda) e em tres camadas(a direita)

Programming Interface (API) publica para criar ldquoobjectosrdquo responsaveis por reflectir

e disponibilizar o Document Object Model (DOM) para o motor de JavaScript

A utilizacao mais frequente desta linguagem e a escrita de funcoes que sao em-

bebidas ou incluıdas em paginas web e que interagem com o DOM Uma vez que o

JavaScript e executado localmente (na maquina do cliente e nao no servidor) e capaz

de responder rapidamente a accoes do utilizador tornando a execucao de aplicacoes

no browser mais fluıdas o JavaScript pode tambem detectar accoes do utilizador

que o HTML nao pode tal como o pressionar de uma tecla

Em Dezembro de 1995 a Netscape Communications adicionou suporte para o

JavaScript no browser Netscape Navigator3 e em Agosto de 1996 o browser Internet

Explorer4 da Microsoft passou a tambem a suportar uma versao semelhante desta

linguagem (hoje todos os principais browsers suportam esta tecnologia)

Esta inovacao permitiu tornar os websites mais interactivos mas a sua utilizacao

esteve confinada apenas a este proposito durante um longo perıodo As paginas

passaram a responder activamente a accoes do utilizador (sendo uma das utilizacoes

3Netscape Communications ndash httpbrowsernetscapecom4Microsoft Internet Explorer ndash httpwwwmicrosoftcomwindowsproductswinfamilyie

10

Enquadramento do Projecto

mais vulgares a validacao de formularios) mas continuaram essencialmente estaticas

O JavaScript ainda nao era nesta altura utilizado para processar dados

Tambem nesta altura (1995ndash96) surgiram linguagens server-side como o PHP

Hypertext Preprocessor (PHP) e Active Server Pages (ASP) e o servidor passou a ter

um processamento de dados introduzidos pelo utilizador mais activo Generalizaram-

se as paginas dinamicas capazes de responder a insercao de dados ou outros pedidos

determinados por accoes do utilizador As paginas tornaram-se aplicacoes web ap-

plications

Uma definicao tradicional de web application e um conjunto de paginas web

logicamente agrupadas e geridas por uma unica entidade que tem como pontos de

entrada formularios de insercao de dados (web forms) Uma web application nao e

mais do que uma aplicacao que e acedida atraves de um browser Tem geralmente

uma arquitectura logica em tres (interface logica de negocio e camada de dados)

camadas e estao armazenadas num servidor

Ha dois tipos de web applications

bull Orientadas a apresentacao Sao web applications que geram paginas web in-

teractivas constituıdas por varios tipos de linguagens de anotacao (por exem-

plo HTML eXtensible Markup Language (XML)) e que apresentam conteudo

dinamico como resposta a pedidos efectuados pelo utilizador

bull Orientadas aos servicos Uma web application orientada aos servicos imple-

menta o ponto de acesso para um ou mais de um web service Sao geralmente

clientes de service oriented web applications

Uma vantagem significativa de implementar uma web application de forma a

suportar as funcionalidades padrao dos browsers e que estas terao o mesmo com-

portamento independentemente da plataforma e do browser a partir do qual serao

acedidas No entanto diferentes implementacoes de browsers devido a diferentes

interpretacoes dos padroes definidos tornam por vezes esta tarefa um pouco mais

complicada existindo inclusivamente na web guioes de compatibilidade para os difer-

entes browsers como [Smi07]

223 Web 20 e Ajax

O termo web 20 descreve uma tendencia de utilizacao e de design observada

na World Wide Web (WWW) com o objectivo de melhorar a criatividade partilha

de informacao e principalmente a colaboracao entre utilizadores Estes conceitos

levaram ao desenvolvimento e evolucao de comunidades online tais como redes so-

ciais wikis e blogues

11

Enquadramento do Projecto

O termo tornou-se mais conhecido apos a primeira conferencia OrsquoReilly Media

Web 20 em 2004 e apesar de sugerir uma nova versao da WWW nao se refere a

qualquer evolucao tecnologica mas apenas a alteracoes a forma como os utilizadores

se servem da web De acordo com Tim OrsquoReilly [OrsquoR06] ldquoWeb 20 e uma revolucao

na industria do software causada pela adopcao da web como uma plataforma e pela

tentativa de entendimento das regras para o sucesso nesta nova plataformardquo

O desenvolvimento da Web 20 serve-se muitas vezes de um outro conceito Ajax

O conceito que hoje conhecemos como Ajax muitas vezes incorrectamente de-

scrito como uma tecnologia foi originalmente criado para permitir o desenvolvimento

de web applications que se assemelhassem ainda mais a aplicacoes de desktop Este

conceito foi melhor descrito por [Gar05] como um conjunto de varias tecnologias

que podem ser utilizadas para melhorar a experiencia do utilizador de uma dada

web application introduzindo a capacidade assıncrona de envio de pedidos ou da

recepcao assıncrona de respostas As tecnologias mais frequentemente envolvidas

sao

bull eXtensible HyperText Markup Language (XHTML) e Cascading Style Sheets

(CSS) padrao para a apresentacao

bull interaccao dinamica atraves do DOM

bull troca e manipulacao de dados utilizando XML e eXtensible Stylesheet Lan-

guage Transformation (XSLT) ou JavaScript Object Notation (JSON)

bull pedidos assıncronos utilizando XMLHttpRequest [vK08]

bull JavaScript utilizado para integrar todas estas tecnologias

E importante frisar que o Ajax nao e um produto nem uma tecnologia E um

termo que descreve a utilizacao de um conjunto de tecnologias para o desenvolvi-

mento de web applications com um elevado grau de interactividade Comparativa-

mente as web applications tradicionais o Ajax introduz uma camada de visualizacao

diferente em tres importantes pontos

1 Do lado do cliente existe um motor que serve de intermediario entre a interface

da aplicacao e o servidor

2 A actividade do utilizador despoleta chamadas JavaScript em vez de um pedido

de pagina directamente ao servidor

3 Informacao codificada em XML em vez de paginas HTML e trocada entre o

servidor e o cliente

12

Enquadramento do Projecto

Isto significa que as paginas que utilizam Ajax contem um motor do lado do

cliente composto por um conjunto de funcoes JavaScript responsavel pela comu-

nicacao com o servidor e por actualizar a interface com o resultado dessa mesma

comunicacao

Na Figura 23 ilustra-se a natureza assıncrona do Ajax quando comparada com

as web applications tradicionais Como se pode observar adicionando um mecan-

ismo Ajax a uma web application eliminam-se diversos tempos de espera associados

a comunicacoes com o servidor uma vez que a interface nao fica ldquobloqueadardquo a es-

pera da resposta Obtem-se assim aplicacoes com um comportamento mais fluido

eliminando tempos de espera entre cada ldquocliquerdquo e melhorando a experiencia do

utilizador

23 Offline Web Applications

A informacao grafica (bem como folhas de estilo e scripts) tais como as ima-

gens que constituem o visual de uma web application e ja tratada de forma especial

pelos cada vez mais avancados sistemas de cache (armazenamento temporario) dos

browsers Mas estes nao sao ainda capazes de guardar conteudo criado pelo uti-

lizador nem de apresentar informacao independentemente do estado da ligacao

Numa altura onde se fala de servicos de Internet wireless municipalizados [Kha]

comunicacoes 3G e ligacoes de banda larga a alta velocidade a ligacao a rede global

continua a nao estar permanentemente disponıvel para os utilizadores Na WWW

encontra-se uma importante parte da informacao e das aplicacoes utilizadas para

criar e editar conteudos Por vezes informacao vital para a produtividade pode

desaparecer subitamente do mapa de acesso de um utilizador quando este entra no

metro num aviao ou mesmo quando se desloca para uma cidade ou paıs diferente

do habitual onde nao subscreve um plano de acesso que lhe garanta a ligacao

Permitir o acesso offline a estes recursos assume assim a sua importancia porque

permitira estender o alcance da informacao a locais onde nunca esteve antes e per-

mitira tambem melhorar o desempenho das web applications colocando informacao

mais perto dos utilizadores reduzindo a transferencia de dados apenas ao essencial

24 Comparacao

Nas evolucoes descritas neste capıtulo 2 pode-se observar que existe um par-

alelismo entre a evolucao das arquitecturas tradicionais cliente-servidor e a evolucao

a que se assiste na web O comportamento e arquitectura dos thin-clients assemelha-

se ao das paginas estaticas no sentido em que o browser nao toma parte em qualquer

13

Enquadramento do Projecto

processamento e serve apenas como uma plataforma de interaccao com o servidor

tal como os clientes descritos na seccao 211

A sua proxima evolucao os fat-clients trouxeram parte da capacidade de pro-

cessamento para o lado do cliente Na web foi tambem esta a inovacao tecnologica

a que se assistiu com a evolucao das tecnologias que permitiram a criacao de ver-

dadeiras aplicacoes e com a introducao do Javascript no browser dando ao cliente

a capacidade de processamento de dados A necessidade da separacao do codigo

em camadas logicas advem da crescente complexidade das web applications Esta

pratica permite entre outras coisas melhorar o processo de desenvolvimento e a

capacidade de manutencao de uma aplicacao

Os fat-clients tem tambem a capacidade de armazenamento de dados o que

permite a persistencia de informacoes entre duas sessoes e que algumas operacoes

sejam executadas sem a necessidade de comunicacao com o servidor Este facto pode

tambem ser uma realidade nas web applications com a adopcao das tecnologias OWA

Neste momento assiste-se a uma utilizacao cada vez maior da web como uma

plataforma de desenvolvimento A capacidade de cooperacao na edicao de conteudos

e a mobilidade proporcionada por esta plataforma sao os principais factores que

alimentam esta mudanca e pela primeira vez as aplicacoes tradicionais tem com-

peticao vinda de web applications A prova do reconhecimento da web como plataforma

de desenvolvimento pode ser retirada da aposta de empresas como a Adobe e Mi-

crosoft que lancaram publicamente ferramentas web complementares a produtos

seus tradicionalmente associados ao desktop ndash Acrobatcom5 e Microsoft Office

Live6 Dotar estas web applications da capacidade de execucao offline significa

aproximar a web e o desktop reunindo ldquoo melhor de dois mundosrdquo

As vantagens da mobilidade possıvel atraves da web a cooperacao na criacao e

edicao de conteudos e a possibilidade de utilizar aplicacoes sempre actualizadas e

sem necessidade de instalacao sao algumas das principais vantagens que promovem

esta mudanca que devido as preocupacoes associadas a usabilidade e experiencia do

utilizador esta fortemente associada ao desenvolvimento de Rich Internet Applica-

tion (RIA)s

5Adobe Acrobatcom httpwwwacrobatcom6Microsoft ndash httpsmallbusinessofficelivecom

14

Enquadramento do Projecto

Figura 23 Comparacao do modelo de web aplications sıncrono paginas estaticas e in-teractivas abordados nas seccoes 221 e 222 com o modelo de web applications Ajax(assıncrono) abordado na seccao 223 Figura adaptada de http www adaptivepath

com

15

Enquadramento do Projecto

16

Capıtulo 3

Estado da arte

Apesar de o conceito das OWAs nao ser absolutamente novo as tecnologias que

o suportam sao recentes Neste capıtulo descrevem-se quatro tecnologias que foram

tidas como principais candidatas para o desenvolvimento deste projecto Descrevem-

se ainda alguns exemplos de web applications que disponibilizam actualmente fun-

cionalidades offline e o processo da escolha da tecnologia a utilizar neste projecto

31 Gears

O Gears1 e uma extensao as funcionalidades do browser introduzido pelo Google

que tem como principal objectivo tornar possıvel a visualizacao de paginas de Inter-

net mesmo sem uma conexao disponıvel Encontra-se disponıvel para as platafor-

mas Windows Macintosh e Linux e oferece uma API de Javascript que permite

a scripts aceder a um mecanismo de armazenamento local baseado numa base de

dados SQLite

311 Arquitectura

Esta ferramenta e constituıda por tres componentes principais

bull LocalServer mdash Intercepta pedidos de paginas web e serve-as localmente

bull Database mdash Uma base de dados relacional construıda sobre SQLite

bull WorkerPool mdash Permite executar operacoes de computacao de uma forma

assıncrona sem afectar a capacidade de resposta e fluidez de execucao da web

application Assemelham-se a processos

1Google Inc ndash Mais informacao em httpgearsgooglecom

17

Estado da arte

LocalServer

O modulo LocalServer e uma cache de Uniform Resource Locators (URLs)

controlada pela web application Quando nao existe uma ligacao a Internet e e

feito um pedido para um URL presente nesta cache o LocalServer intercepta-o e

responde ao pedido localmente a partir do disco rıgido do utilizador A aplicacao

pode utilizar dois tipos diferentes de armazenamento local de URLs

bull ResourceStore ndash serve para capturar URLs utilizando exclusivamente a API

de Javascript disponibilizada para o efeito Uma aplicacao podera criar e

utilizar diversos ResourceStores simultaneamente para capturar ficheiros de

dados que necessitam de ser enderecados por um URL tal como um ficheiro

PDF ou uma imagem

bull ManagedResourceStore ndash serve para capturar um conjunto de URLs que estao

relacionados e que sao declarado num ficheiro de manifesto (especificado em

JSON) e que sao automaticamente actualizados O ManagedResourceStore

permite que o conjunto de recursos necessarios para correr uma web application

seja capturado e mantido actualizado automaticamente

A principal diferenca entre estes dois tipos de armazenamento de URLs e a forma

como sao actualizados os seus conteudos Os conteudos de um ManagedResourceStore

sao actualizados sempre que a versao contida no ficheiro de manifesto for alterada

enquanto que os conteudos de um ResourceStore nunca sao actualizados automati-

camente mas apenas quando for explicitamente ordenado pela aplicacao

O LocalServer e capaz de interceptar e servir localmente pedidos de HTTP e

HTTPS sempre que se reunam as seguintes condicoes

1 O URL encontra-se armazenado num ResourceStore ou ManagedResourceStore

2 O sistema de armazenamento local encontra-se activo (enabled = true) Se

o sistema de armazenamento local tiver o atributo requiredCookie o pedido

devera conter um cookie que lhe corresponda

O LocalServer nao necessita de monitorizar o estado da ligacao para atender aos

pedidos Na verdade sempre que as condicoes previamente enunciadas se verificarem

o LocalServer interceptara os pedidos e independentemente do estado da ligacao

a Internet servi-los-a a partir do disco rıgido local Cabera a aplicacao definir qual

o modo em que pretende executar um pedido (online ou offline) definindo o valor

de verdade da propriedade enabled

18

Estado da arte

Database

O modulo Database permite guardar dados da web application assegurando a

sua persistencia Os dados sao guardados de forma relacional no disco rıgido do uti-

lizador2 de acordo com o modelo de seguranca estabelecido pelo Gears3 significando

que uma aplicacao nao pode aceder a conteudos fora do seu domınio

WorkerPool

Nos web browsers uma operacao pesada de computacao pode tornar a interface

lenta e tornar menos agradavel a experiencia do utilizador O modulo WorkerPool

permite correr operacoes em background sem bloquear a interface com o utilizador

Os scripts executados numa WorkerPool nao activam os mecanismos de seguranca

do browser que mostram a mensagem ldquoA script on this page may be busy or may

have stopped respondingrdquo

O WorkerPool comporta-se como um conjunto de processos em vez de threads

Os Workers nao partilham qualquer estado de execucao o que significa que uma

alteracao a uma variavel num Worker nao afecta em nada a execucao de outro

Worker Alem disso os Workers nao herdam automaticamente nenhum codigo dos

seus pais Cada Worker e membro de um WorkerPool e os Workers podem in-

teragir entre si enviando mensagens em formato de texto ou JSON No entanto ha

tambem algumas limitacoes os Workers nao tem acesso ao DOM e objectos como

window ou document nao se encontram acessıveis Isto e consequencia de os Workers

nao partilharem o estado de execucao Mas tem acesso a todas as funcoes built-in

do Javascript A maioria das funcionalidades do Gears pode tambem ser acedida

atraves de uma variavel global especial definida como googlegearsfactory Para

outras funcionalidades especıficas os Workers podem ldquopedirrdquo a pagina principal para

continuar a execucao atraves do envio de mensagens

Outras funcionalidades

bull HttpRequest ndash Este modulo implementa a especificacao W3C XmlHttpRe-

quest definida em [vK08] tornando-a disponıvel para os workers e para a

pagina principal

bull Timer ndash Este modulo implementa a especificacao de timers tal como descrito

por [Hic08] e torna-os disponıveis para os workers e para a pagina principal

2Consultar httpcodegooglecomapisgearsapi_databasehtmldirectories3Consultar httpcodegooglecomapisgearssecurityhtml

19

Estado da arte

bull Factory ndash Esta classe e utilizada para instanciar todos os outros objectos da

API do Gears atraves do seu metodo create Este metodo pode ser utilizado

com os seguintes parametros

ndash betadatabase

ndash betahttprequest

ndash betalocalserver

ndash betatimer

ndash betaworkerpool

312 Goggle Gears em dispositivos moveis

O Gears esta tambem disponıvel em dispositivos Windows Mobile 5 e 6

Os dispositivos moveis estao pela sua natureza frequentemente desconectados

da Internet Mesmo quando possuem uma ligacao as latencias na transferencia de

dados em redes moveis tornam as aplicacoes pouco fluıdas mas o Gears permite

ultrapassar este obstaculo

O Gears funciona exactamente da mesma forma em dispositivos moveis equipados

com o Windows Mobile 5 e 6 como num computador comum Se uma aplicacao tiver

sido implementado com suporte para o Gears entao tambem estara preparada para

ser executada num dispositivo movel mas as limitacoes dos browsers disponıveis

para dispositivos moveis tem que ser consideradas Isto significa prever as condicoes

que permitam uma boa usabilidade devido aos pequenos ecras destes dispositivos

bem como o seu suporte limitado dos padroes do DOM CSS e JavaScript

32 Adobe AIR

O Adobe AIR4 e um runtime compatıvel com diversos browsers e sistemas opera-

tivos que pretende dar aos programadores a possibilidade de combinar diversas tec-

nologias de producao de conteudos para a Internet no desenvolvimento de Rich Inter-

net Application (RIA)s O Adobe AIR mantem uma relacao com o browser mas es-

tende as suas capacidades e tecnologias permitindo o desenvolvimento de aplicacoes

tambem para o ambiente de trabalho com janelas em tudo semelhantes as do sis-

tema operativo Segundo a Adobe o objectivo e complementar o browser dando

aos utilizadores (mas essencialmente aos programadores e equipas de desenvolvi-

mento) a escolha sobre como distribuir as suas aplicacoes Para este efeito o Adobe

AIR tem uma aproximacao diferente do Gears Em vez de ldquoestenderrdquo o browser

acrescentando-lhe funcionalidades o AIR permite tambem o desenvolvimento de

4Adobe - httpwwwadobecomproductsair

20

Estado da arte

aplicacoes que se destinam a ser executadas fora do ambiente do browser mas uti-

lizando as tecnologias comuns da Internet (por exemplo HTML CSS JavaScript

Flash Flex)[CDGH08]

A utilizacao desta tecnologia permite utilizar o browser ou o proprio runtime

Adobe AIR como plataforma de execucao da aplicacao

Na Tabela 31 faz-se uma comparacao das funcionalidades disponıveis de acordo

consoante se escolha o browser ou o desktop como plataforma base para a aplicacao

Uma vez que as aplicacoes Adobe AIR na plataforma desktop tem um caracter

persistente (sao instaladas no computador do utilizador) o Adobe AIR tem um

modelo de seguranca que se assemelha com o das tradicionais aplicacoes desktop

[Ada08] Este modelo e analisado nas seccoes 321 e 322 O ambiente em que

e executado o browser e restringido a execucao de web applications que podem

ser de varias origens (incluindo de origens anonimas ou sem confianca) O Adobe

AIR proporciona acesso a capacidades como acesso a ficheiros que necessitam da

confianca do utilizador

bull HTML ndash O desenvolvimento de aplicacoes para o Adobe AIR pode ser feito

com recurso a tecnologias de HTML e Ajax comuns utilizando as linguagens

de markup existentes distribuıdas como texto e interpretadas em execucao

(runtime)

bull Flash ndash Outra alternativa sera a utilizacao da linguagem Flash Permite a

renderizacao de graficos vectoriais e audiovıdeo com suporte nativo Utiliza

ActionScript para adicionar maior interactividade com o utilizador

bull Flex ndash O Flex e uma framework open source para o desenvolvimento de RIAs

usando Flash As aplicacoes Flex sao na realidade Flash sendo a principal

diferenca o ambiente de desenvolvimento

Como resultado uma aplicacao AIR podera ser implementada

bull Baseada em Flash ou Flex (aplicacoes cujo conteudo base e em ShockWave

Flash (SWF))

bull Baseada em Flash ou Flex tambem com HTML ou Portable Document Format

(PDF) Aplicacoes cujo conteudo de base e em FlashFlex (SWF) com HTML

(HTML JavaScript CSS) ou conteudo PDF incluıdo

bull Baseada em HTML Aplicacoes cujo conteudo base e em HTML Javascript

CSS

bull Baseada em HTML utilizando tambem FlashFlex ou PDF

21

Estado da arte

Os utilizadores interagem com uma aplicacao AIR da mesma forma que interagem

com outras aplicacoes com janelas nativas do seu sistema operativo O runtime e

instalado uma vez no computador do utilizador e a partir desse momento todas as

aplicacoes AIR terao o mesmo aspecto que qualquer outra aplicacao para o desktop

321 Seguranca

Permitir que uma web application aceda ao disco de armazenamento do utilizador

pode comprometer seriamente a sua seguranca Neste sentido o Adobe AIR tem

suporte para assinaturas digitais (Secure Sockets Layer (SSL)) que podem ser com-

pradas pelas equipas de desenvolvimento que o desejem e cujos certificados serao

apresentados ao utilizador no momento da instalacao Um outro aspecto ainda

relativo a seguranca e o mecanismo de isolamento de cada ambiente (sandbox )

322 Assinatura do codigo

O runtime AIR exige que todas as aplicacoes estejam digitalmente assinadas As

assinaturas digitais de codigo sao um processo que visa garantir a integridade da

aplicacao e a identidade do seu autor no momento da instalacao As equipas de

desenvolvimento podem ldquoassinarrdquo uma aplicacao utilizando um certificado atribuıdo

por uma Entidade Certificadora (Certification Authority) ou atraves de um certifi-

cado individual (self signed certificate) Neste momento o Adobe AIR suporta como

entidades certificadoras a Verisign e a Thawte [Ado08]

O instalador apresenta o nome de quem publica a aplicacao quando o codigo tiver

sido assinado com um certificado que apresente confianca ou que esteja encadeado

com um certificado que tenha ja sido aceite no computador em que se esta a instalar

a aplicacao

As equipas de desenvolvimento podem tambem assinar as aplicacoes com um

certificado auto-atribuıdo (um certificado criado por elas proprias) mas neste caso

o instalador apresentara estas aplicacoes como sendo de uma origem nao verificada

O AIR utiliza a infraestrutura publica de chaves [Ent07] suportada pelo arquivo

local do sistema operativo Para que a origem da aplicacao seja reconhecida o

computador onde a aplicacao AIR esta a ser instalada tem que confiar directamente

no certificado que foi utilizado para assinar a aplicacao ou confiar num certificado

que esteja num encadeamento logico de certificados confiados e que se ligue desta

forma ao certificado utilizado para assinar a aplicacao

Todas as aplicacoes AIR tem caracterısticas em comum independentemente da

tecnologia utilizada para o seu desenvolvimento (HTMLFlexFlash) No ambito

de uma aplicacao AIR existem um conjunto de APIs que estao disponıveis e que

tornam possıvel o acesso ao sistema local (leitura e escrita) e a recursos de rede que

22

Estado da arte

de outra forma nunca estariam acessıveis a partir de uma web application comum

Cada aplicacao AIR possui tambem diferentes nıveis de isolamento chamados secu-

rity sandboxes dependendo do tipo de conteudo que esta a ser carregado e do seu

objectivo

bull Isolamento ao nıvel da aplicacao5 ndash E a raiz de cada aplicacao AIR Este

nıvel de isolamento permite o acesso a APIs privilegiadas e especıficas do

AIR Em contrapartida e negado o acesso a algumas APIs que poderiam ser

facilmente utilizadas de forma maliciosa contra o utilizador final Importacao

dinamica de conteudos remotos e geralmente proibido e as tecnicas e mecan-

ismos de geracao dinamica de codigo sao fortemente restringidas Apenas

conteudo carregado directamente da directoria base da aplicacao podera ser

colocado neste nıvel de isolamento

bull Isolamento nao especıfico da aplicacao6 ndash contem todo o outro conteudo

que nao tenha sido carregado directamente para o isolamento da aplicacao

Isto inclui conteudo local e remoto Este tipo de conteudo nao tem acesso

directo as APIs do AIR e rege-se pelas mesmas regras tal como se tivesse sido

carregado por um browser a partir da mesma localizacao (por exemplo HTML

carregado a partir de um domınio remoto comporta-se da mesma forma que se

fosse acedido a partir do browser)

33 Mozilla Prism

331 XML User Interface Language

O eXtensible User Interface Language (XUL) e uma linguagem de anotacao

baseada em XML desenvolvida pela Mozilla Foundation que opera em aplicacoes

Mozilla multi plataforma tal como o Firefox O motor Gecko e a unica imple-

mentacao completa desta linguagem que foi desenhada sobre padroes web comuns

como CSS JavaScript e o DOM e permite o desenvolvimento de interfaces graficas

utilizando elementos pre-definidos tais como window box page textbox radio

button entre outros Infelizmente o XUL nao possui qualquer especificacao formal

ou implementacoes de inter-operabilidade para outros motores que nao o Gecko No

entanto a sua implementacao e licenciada em codigo aberto pelas licencas GNU Gen-

eral Public License (GPL) GNU Lesser General Public License (LGPL) e Mozilla

Public License (MPL)

Enunciam-se algumas caracterısticas desta linguagem

5NT application sandbox6NT non-application sandbox

23

Estado da arte

Liguagem de anotacao poderosa baseada em componentes (widgets) O ob-

jectivo do XUL e permitir a construcao de aplicacoes multi-plataforma em

claro contraste com o Dynamic HyperText Transfer Protocol (DHTML) que se

destina ao desenvolvimento de paginas web Por esta razao o XUL esta orien-

tado a componentes tais como janelas botoes e etiquetas em vez de paginas

cabecalhos de texto e ligacoes de hipertexto Investir tempo e esforco para

atingir este mesmo resultado em aplicacoes baseadas em DHTML compromete

frequentemente a complexidade e desempenho da aplicacao

Baseado em padroes O XUL e um dialecto XML baseado no padrao W3C XML

10 As aplicacoes escritas em XUL sao tambem baseadas em especificacoes

W3C adicionais como HTML 40 CSS DOM nıvel 1 e 2 JavaScript 15

incluindo ECMA-262 Edition 3 (ECMAscript)

Portabilidade entre plataformas Tal como HTML o XUL foi desenhado para

ser independente da plataforma em que e utilizado tornando as aplicacoes

facilmente portaveis entre sistemas operativos nos quais o Mozilla e suportado

Uma vez que o XUL oferece um nıvel de abstraccao dos componentes graficos

de interface que disponibiliza implementa a premissa ldquoum codigo para todas

as plataformasrdquo A interface grafica de todos os produtos centrais Mozilla

(browser instant messenger livro de enderecos) e escrita em XUL com um

unico codigo base que suporta todas as plataformas Mozilla

Separacao entre o nıvel de apresentacao e a logica de negocio Uma das

maiores preocupacoes no desenvolvimento para a Internet e a forte ligacao

entre estas duas camadas (interface e logica) Isto constitui um problema sig-

nificativo no desenvolvimento de grandes aplicacoes especialmente quando o

desenvolvimento e feito em ambientes de equipa porque as capacidades de de-

senvolvimento destas duas partes da aplicacao estao muitas vezes espalhadas

por diferentes elementos O XUL permite uma clara distincao entre a definicao

da aplicacao cliente e da logica de implementacao (XUL eXtensible Binding

Language (XBL) e JavaScript) apresentacao (CSS e imagens) internacional-

izacao (Document Type Definitions (DTDs) e etiquetas de texto em lınguas

especıficas guardados em ficheiros properties) O esquema grafico e apre-

sentacao de uma aplicacao XUL pode ser alterado de forma independente da

sua logica ou implementacao e a aplicacao pode ainda ser traduzida (interna-

tionalization) de forma independente da sua logica implementacao ou apre-

sentacao Este grau de separacao resulta em aplicacoes que sao mais faceis de

manter pelos programadores e facilmente adaptadas por designers e tradutores

24

Estado da arte

Facil adaptacao Outro benefıcio que advem do nıvel de separacao entre logica

de negocio e apresentacao oferecido pelo XUL e a facilidade com que se pode

adaptar uma aplicacao para diferentes clientes ou grupos de utilizadores Um

programador pode utilizar a mesma aplicacao base e adapta-la consoante as

necessidades atraves de diferentes temas (skins) e ficheiros de lınguas Desta

forma uma aplicacao escrita e desenvolvida em Ingles pode ser rapidamente

traduzida para Portugues e distribuıda com outra aparencia mais apropriada

ao cliente alvo

332 Prism

O Mozilla Prism e um browser simplificado e ldquointerpretadorrdquo de XUL (tambem

designado por XULRunner) que acolhe web applications sem a interface grafica ha-

bitual de um browser Baseia-se num conceito designado por Site Specific Browser

(SSB) Um SSB e uma aplicacao com um browser embebido desenhado para exe-

cutar apenas uma web application Nao possui os menus e barras de ferramentas

habituais Um SSB tem uma integracao com o sistema operativo e com o desktop

muito mais estreita do que uma web application acedida atraves de um browser uma

vez que e executado em janela propria

O Prism resulta de uma experiencia da Mozilla e visa reduzir as diferencas entre

as desktop applications tradicionais e as web applications Um dos aspectos focados e

a experiencia do utilizador Numa apresentacao oficial e dito que ldquo[o Prism] pretende

ser uma ponte entre as diferencas que existem entre as aplicacoes tradicionais de

desktop e as web applications explorando novos modelos de usabilidade enquanto

que a linha que as separa se continua a definirrdquo [Lab07]

34 HTML 5

A especificacao HTML 5 [Hic08] que se encontra em fase de desenvolvimento

pelo grupo WHATWG pretende ser uma norma de substituicao dos padroes HTML

4 XHTML 1x e do DOM2 HTML Uma das propriedades que o distingue das tec-

nologias que pretende substituir e precisamente o suporte para OWA e armazena-

mento de dados no cliente de uma forma relacional Nao sendo propriamente uma

tecnologia ndashmas antes uma especificacao ndashe aqui mencionada por ter servido como

referencia a diversas implementacoes de funcionalidades offline e por se considerar

que venha a ter um impacto significativo nas implementacoes de diversos browsers

Dion Almaer defendeu no seu blogue que o Gears era uma implementacao do

HTML 5 No seu artigo ldquoGears as a bleeding-edge HTML 5 implementationrdquo [Alm08]

o autor diz que ambos ndasho Gears e o HTML 5 ndashpretendem dar a web caracterısticas

25

Estado da arte

semelhantes e nao encontrar motivo de ldquocompeticaordquo entre as duas mas que en-

quanto o HTML 5 e uma especificacao o Gears e uma implementacao

No entanto tambem e verdade que o HTML 5 cobre muitos outros pontos para

alem das OWA que saem completamente fora do ambito do Gears Se esta es-

pecificacao atingir um estado de maturidade que possibilite a sua adopcao pelos

principais browsers tornando nativo do browser o suporte OWA entao deixara de

fazer sentido a existencia de uma extensao como o Gears

A especificacao HTML 5 disponibiliza duas APIs relevantes para o tema das

OWA

1 Uma base de dados baseada em SQL que permite o armazenamento de dados

do lado do cliente

2 Uma ldquocacherdquo HTTP que garante a disponibilidade das aplicacoes mesmo quando

o utilizador nao possui uma ligacao a Internet

Estas caracterısticas sao as bases da tecnologia das OWA e tem correspondencia

com os pontos analisados nas seccoes 311 e 311

35 Web applications que usam funcionalidades offline

Nesta seccao apresentam-se algumas web applications que actualmente disponi-

bilizam funcionalidades offline Estas aplicacoes foram escolhidas para uma analise

mais pormenorizada por utilizarem o Gears que tal como descrito na seccao 4 foi

a tecnologia escolhida para o projecto

351 Google Reader e Google Docs

O Google Reader7 e um leitor de feeds RSS Permite gerir a subscricao de varios

sites simultaneamente que disponibilizem conteudos neste formato e foi a primeira

web application da Google com uma versao offline publicamente acessıvel (desde

Junho de 2007)

O Google Reader implementa o modo ldquoutilizador deciderdquo oferecendo na sua

interface um botao que permite alternar entre os modos online e offline

O Google Docs8 e uma web application que permite a criacao e edicao de doc-

umentos de texto folhas de calculo e apresentacoes Era ja publico desde Janeiro

de 2008 que o Google estava a desenvolver uma versao OWA desta aplicacao mas o

acesso a uma versao experimental so foi possıvel a partir de 31 de Maio de 2008

7Google Reader - httpreadergooglecom8Google Docs - httpdocsgooglecom

26

Estado da arte

A implementacao das funcionalidades offline nestas duas aplicacoes seguiu difer-

entes aproximacoes principalmente porque o Google Reader apresenta ao utilizador

informacoes que sao fornecidas por fontes externas enquanto que no Google Docs

a informacao e criada e editada pelo utilizador sobre a forma de documentos

A diferente origem da informacao implica que no Google Reader seja necessario

prever casos de excepcao tal como existirem demasiados itens que necessitam de

ser transferidos para o cliente Nao observar este ponto causa um problema grave

de usabilidade e para evitar tempos de espera demasiado longos e uma interface

com pouca capacidade de resposta as accoes do utilizador o Google Reader apenas

transfere para o cliente os dois mil itens mais recentes na transicao para o modo

offline

352 Remember the Milk

O Remember The Milk9 e uma web application desenvolvida por uma equipa

Australiana que proporciona funcionalidades de agenda gestao de tempo e de tare-

fas e foi uma das primeiras aplicacoes independentes do Google a adoptar o Gears

para acessos em modo offline Permite que os seus utilizadores facam uma gestao

de tarefas agrupando-as em listas adicionando-lhes campos de informacao adicional

ou dando-lhes informacao geografica (recorrendo ao servico Google Maps10) Entre

a sua lista de funcionalidades encontra-se ainda a possibilidade de importar e ex-

portar eventos no formato iCalendar (ics) etiquetas (tags) em tarefas publicacao

Really Simple Syndication (RSS) e partilha de categorias de tarefas de acordo com

diferentes nıveis de permissoes de acesso definidos pelo utilizador

353 MySpace e WordPresscom

O MySpace uma das maiores social networks na Internet anunciou recente-

mente que vai disponibilizar uma versao do seu cliente de e-mail que utiliza o Gears

para acelerar o seu desempenho Numa fase inicial estara disponıvel apenas para

utilizadores que tenham cinco mil ou mais mensagens na sua caixa de correio e

permitira efectuar pesquisas muito mais rapido que a sua versao online

O servico de blogs Wordpresscom anunciou tambem o inıcio da utilizacao desta

tecnologia com o fim de melhorar o desempenho A versao que utiliza esta tecnologia

descarrega e armazena no cliente um conjunto de imagens e scripts que passam a

ter preferencia sobre os seus congeneres online e que permitem acelerar o processo

de carregamento da aplicacao e visualizacao de blogs

9Remember The Milk ndash httpwwwrememberthemilkcom10Google Maps ndash httpmapsgooglecom

27

Estado da arte

O MySpace e o Wordpresscom sao dois exemplos da utilizacao da tecnologia

OWA para optimizacao de web application ja existentes Sem pretenderem disponi-

bilizar uma versao que seja totalmente offline fazem uso do Gears para armazenar no

cliente parte dos recursos frequentemente acedidos na visualizacao das suas paginas

36 Escolha da tecnologia

Apos a analise das tecnologias apresentada nas seccoes 31 a 34 foi necessario es-

tudar a adequacao de cada uma delas ao projecto em questao Desde logo e possıvel

observar que nem todas se dedicam apenas a OWA Por exemplo o Adobe AIR

apesar de ter suporte para OWA apenas disponibiliza algumas das funcionalidades

identificadas como mais indicadas para a execucao do projecto quando utilizado

na sua vertente desktop tal como exposto na Tabela 31 mas a utilizacao desta

vertente implicaria o desenvolvimento de novas interfaces e de novas formas de co-

municacao (troca de mensagens XML ou JSON) A vertente web do Adobe AIR

foca-se mais especificamente nas Rich Internet Applications e permite a reutilizacao

do codigo ja existente (exigindo naturalmente a sua adaptacao e a implementacao

das funcionalidades pretendidas)

A tecnologia escolhida para a realizacao deste trabalho foi o Gears sendo que

um dos principais factores a influenciar esta opcao foi a liberdade introduzida pela

sua licenca Berkeley Software Distribution (BSD)11

Considerou-se o funcionamento desta ferramenta extremamente adequando a

aplicacao no WOW uma vez que o seu principal objectivo e precisamente tornar

possıvel a execucao offline de uma pagina web e por virtude deste facto o Gears tem

uma API concisa e de simples aplicacao pratica uma vez que nao possui quaisquer

outros elementos distractores O funcionamento do seu ManagedResourceStore ex-

emplificado na Figura 31 com a capacidade de actualizacao de recursos definidos

num ficheiro manifesto especificado em JSON pesou tambem nesta decisao

11Sobre a licenca BSD consultar httpwwwopensourceorglicensesbsd-licensephp e http

wwwlinfoorgbsdlicensehtml

28

Estado da arte

Figura 31 Esquema UML do processo efectuado pelos recursos do Gears do tipoManagedResourceStore para a actualizacao dos conteudos definidos no ficheiro manifesto

29

Estado da arte

Funcionalidade RIAs no browser RIAs no desktop

Disponibilidadeda aplicacao

As aplicacoes podem ser facil-mente exploradas e utilizadas

As aplicacoes quando instal-adas tem maior grau de fun-cionalidades e persistencia

Instalacao Nao e necessario qualquer tipode instalacao

As aplicacoes sao instaladasatraves do browser ou descar-regadas e instaladas comouma aplicacao tradicional

Actualizacoes Aplicacoes sao actualizadascarregando conteudos paraum website

O AIR disponibiliza uma APIque permite que as aplicacoessejam actualizadas de umaforma

Sistemas opera-tivos suportados

As aplicacoes podem ser exe-cutadas em diversos sistemasoperativos e browsers

As aplicacoes sao multi-plataforma e podem serinstaladas e executadas emdiversos sistemas operativos ebrowsers

Linguagens deprogramacao

Javascript e disponibilizadopelo browser e ActionScripte disponibilizado pelo AdobeFlash Player

Maquinas virtuais deJavascript e ActionScriptcompatıveis com o browser

Capacidade deexecucao embackground

As RIAs podem ser execu-tadas numa janela do browser

As aplicacoes podem ser ex-ecutadas em background edisponibilizar notificacoes talcomo uma aplicacao tradi-cional

Persistencia A actividade esta limitada asessao do browser Quando obrowser e encerrado toda ainformacao e descartada

As aplicacoes sao instaladas eestao disponıveis no desktopPodem armazenar informacaolocalmente e estao disponıveisoffline

Integracao com odesktop

Integracao com o desktop lim-itada devido a restricoes im-postas pelo browser

As aplicacoes podem acederao sistema de ficheiro ao clip-board eventos notificacoesetc

Controlo da inter-face com o uti-lizador

As aplicacoes sao acedidasatraves de uma janela dobrowser que tem os seusproprios controlos e visualgrafico

As aplicacoes tem um vi-sual grafico proprio em janelapropria

Armazenamentode dados

As aplicacoes tem armazena-mento limitado que pode serreescrito pelo browser

As aplicacoes tem acesso a to-talidade do espaco disponıvellocalmente e a uma base dedados com a possibilidade deencriptacao

Tabela 31 Comparacao das funcionalidades oferecidas pelo Adobe AIR para as platafor-mas web e desktop

30

Estado da arte

Aplicacao Modo de execucao utilizadoGoogle Reader Utiliza o modo ldquoutilizador deciderdquo disponibilizando

ao utilizador um botao para alternar entre os modosonline e offline Como lida com informacao recol-hida de fontes externas de natureza frequentementeefemera o processo de sincronizacao apenas transfereos dois mil itens mais recentes quando passa ao es-tado offline Neste modo sao ainda guardadas in-formacoes de itens lidos e etiquetas atribuıdas quesao sincronizadas com o servidor quando o utilizadorvoltar a activar estado online

Google Docs Utiliza o modo ldquoaplicacao deciderdquo permitindo que outilizador edite os conteudos de documentos de textofolhas de calculo e de apresentacoes independente-mente do estado da ligacao desde o momento em queas funcionalidades offline sao activadas A aplicacaofaz pequenas sincronizacoes com o servidor sempre quenecessario

Remember the Milk Utiliza um modo hıbrido entre ldquoaplicacao deciderdquo eldquoutilizador deciderdquo A aplicacao encarrega-se da sin-cronizacao de dados mas disponibiliza um controlona sua interface que permite despoletar manualmenteeste processo para situacoes em que o utilizador fez al-teracoes recentes e pretende usufruir das capacidadesoffline imediatamente

MySpace O MySpace anunciou a utilizacao de mecanismos dearmazenamento de dados no cliente com recurso atecnologias OWA para melhorar o desempenho doseu cliente web de correio electronico nomeadamenteno que diz respeito a operacoes de pesquisa e or-denacao Inicialmente esta funcionalidade estara ape-nas disponıvel para utilizadores com cinco mil ou maismensagens na sua caixa de correio mas nao e aindaclaro se sera disponibilizada uma versao totalmenteoffline

Tabela 32 Resumo da utilizacao de tecnologias OWA em algumas web applications con-sideradas na analise do estado da arte

31

Estado da arte

32

Capıtulo 4

Desenvolvimento

Neste capıtulo introduz-se a aplicacao WOW e apresenta-se o estudo que foi

feito da adequacao de cada tecnologia para a implementacao da funcionalidade of-

fline nesta plataforma Fazem-se diversas consideracoes sobre opcoes a tomar na

concepcao de OWAs e problemas comuns na sua implementacao bem como sug-

estoes para os resolver O WOW e uma aplicacao ja existente de gestao de ordens

de trabalho e do fluxo de tarefas numa empresa ou organizacao

41 Como ficar offline

Na maior parte das web applications de hoje nao existe uma camada de dados

real A aplicacao exemplificada na Figura 41 ao longo da sua execucao acede

directamente a sua unica fonte de dados (o servidor) atraves de chamadas Ajax sem

que exista uma separacao clara destas duas camadas

Para que uma web application seja capaz de ser executada sem uma ligacao

activa a Internet e mantenha o seu caracter dinamico torna-se necessario incluir

Figura 41 Exemplo de uma arquitectura de uma web application sem uma camada deabstraccao de dados Figura adaptada de http gears google com

33

Desenvolvimento

Figura 42 Exemplo de uma arquitectura de uma web application com uma camada deabstraccao de dados Figura adaptada de http gears google com

um mecanismo de armazenamento de dados local seja uma base de dados ou a

capacidade de acesso ao disco No entanto este mecanismo introduz dois problemas

1 Qual das fontes de dados utilizar quando um utilizador faz um pedido de

informacao

2 A necessidade de implementar uma camada de acesso a dados que seja coerente

quer se use o servidor remoto ou local

Por exemplo em vez de a aplicacao Ajax fazer um pedido relativo as contas de

todos os utilizadores em formato JSON directamente ao servidor remoto podera ao

inves fazer o pedido a um objecto intermedio da camada de dados Este objecto

demonstrado na Figura 42 sera responsavel por implementar uma interface de

acesso a base de dados e retornar um objecto JavaScript com uma representacao da

resposta do servidor

Mas a existencia de uma segunda fonte de dados torna recomendavel tambem

a implementacao de uma camada de data switching que em funcao da existencia

de conexao a Internet e da necessidade de actualizacao dos dados decide se faz o

pedido ao servidor remoto ou se fornece os dados presentes localmente Este objecto

apresentado na Figura 43 decidira de forma transparente para o utilizador se le ou

escreve os dados localmente ou se os enviapede ao servidor remoto e pode tambem

iniciar o processo de convergencia de dados e de resolucao de conflitos

411 Funcionalidades disponıveis em modo offline

Por razoes praticas e provavel que nem todas as funcionalidades da aplicacao

possam ser disponibilizadas em modo offline E necessario escolher quais as fun-

cionalidades a disponibilizar no modo offline da aplicacao e implementar a logica

que decide quando utilizar a base de dados local ou o servidor remoto Apesar do

acesso a base de dados local ser muito mais rapido do que aceder ao servidor o

acesso local nem sempre e preferido Ha varias razoes que podem tornar necessario

escolher o acesso ao servidor em vez do acesso local

34

Desenvolvimento

Figura 43 Exemplo de uma arquitectura de uma web application com uma camada deabstraccao de dados e um data switch Figura adaptada de http gears google com

1 A informacao pode ter uma natureza efemera e nao fazer sentido guarda-la

localmente Exemplo dados em tempo real da bolsa de valores de Lisboa

2 Algumas aplicacoes lidam com informacao que so faz sentido na presenca de

uma ligacao Exemplo Instant Messaging

3 A aplicacao podera escolher apenas guardar a informacao acedida mais fre-

quentemente Exemplo para o utilizador poder alterar a lıngua de apre-

sentacao da aplicacao os conteudos terao que ser guardados em todas as

lınguas disponibilizadas pela aplicacao O custo de implementacao de algu-

mas funcionalidades pode nao compensar o benefıcio

4 A capacidade de processamento ou de armazenamento de dados pode inviabi-

lizar algumas funcionalidades offline Exemplo se uma dada funcionalidade

necessita de uma capacidade de armazenamento de dados para alem do razoavel

de um computador pessoal para ser util (visualizador de mapas)

42 Modos de execucao

Um aspecto que e necessario estudar para qualquer web application que se deseje

disponibilizar offline prende-se com tres modos de execucao que devem ser consid-

erados

1 Utilizador decide o modo de execucao A aplicacao tem modos distintos

de execucao para os estados online e offline geralmente indicados na interface

com o utilizador O utilizador e informado do estado da ligacao e participa na

alteracao de estado de execucao da aplicacao interagindo com a sua interface

2 Aplicacao decide o modo de execucao Pode ser implementado na propria

aplicacao um mecanismo de deteccao do estado da ligacao (por exemplo atraves

35

Desenvolvimento

de chamadas Ajax periodicas) transitando de estado e sincronizando automati-

camente Desta forma o utilizador nao precisa de participar na alteracao de

estado a menos que exista um conflito de dados que requeira a sua atencao

3 Aplicacao assume sempre o estado offline Outra hipotese sera imple-

mentar uma web application que assume sempre estar na ausencia de uma

ligacao ao servidor de dados Esta aplicacao responde aos pedidos do uti-

lizador efectuando pedidos de informacao ao servidor mas nao dependendo

de uma resposta valida para mostrar a informacao que ja tinha disponıvel an-

teriormente A sincronizacao de dados com o servidor e tentada sempre que

existam dados para submeter e uma accao do utilizador

421 Modo ldquoutilizador deciderdquo

Neste modo de execucao quando a aplicacao esta online comunica com o servidor

remoto quando esta offline comunica com a base de dados local A informacao tem

que ser sincronizada sempre que se muda de modo A principal vantagem desta opcao

e que e a mais simples de implementar mesmo para uma aplicacao ja existente e

portanto uma forma expedita de disponibilizar uma OWA No entanto tem tambem

algumas desvantagens que devem ser consideradas

1 O utilizador tem que se lembrar de fazer a alteracao de estado de execucao

Caso contrario podera estar a trabalhar inadvertidamente numa versao offline

com dados antigos ou nao ter a informacao necessaria se perder subitamente

a ligacao

2 Se a ligacao for intermitente o utilizador tera ou que escolher um dos modos

de execucao ou estar constantemente a trocar

3 Uma vez que a base de dados nao esta sempre actualizada nao podera ser

utilizada para melhorar a rapidez de execucao da aplicacao quando em modo

online

422 Modo aplicacao decide

A deteccao do estado da ligacao pode ser implementada atraves de um pedido

assıncrono ao servidor tal como ilustrado na Figura 44 O resultado deste pedido

definira o estado online (em caso de sucesso) ou offline (em caso de falha) A

sincronizacao de dados podera ser feita sempre que ocorra uma transicao do es-

tado offline para o estado online No entanto este metodo nao se revela eficiente

36

Desenvolvimento

Figura 44 Esquema grafico ilustrando uma OWA executando no browser utilizando ummodo de execucao do tipo ldquoaplicacao deciderdquo com deteccao automatica do estado daligacao via pedidos Ajax assıncronos a cada cinco segundos

para grandes aplicacoes uma vez que requer a troca de mensagens demasiado fre-

quentes com o servidor que se destinam exclusivamente a monitorizacao do estado

da ligacao

423 Modo ldquoaplicacao assume o estado offlinerdquo

Uma aplicacao transparente funciona assumindo sempre que esta em modo of-

fline ou pelo menos que pode perder a ligacao a qualquer momento Neste modo

tira-se o maximo partido do armazenamento local e fazem-se pequenas mas contınuas

sincronizacoes com o servidor sempre que este esteja disponıvel A sincronizacao de

dados tambem e feita sempre que se volta ao estado online

As vantagens de uma web application transparente sao as seguintes

bull Uma melhor experiencia para o utilizador uma vez que este nao tem que se

preocupar com o estado da ligacao ou com a transicao de estados

bull A aplicacao funciona de forma coerente mesmo que a ligacao seja intermitente

bull Uma vez que o armazenamento local e mantido actualizado pode ser utilizado

para melhorar o desempenho da aplicacao

Foram identificadas as seguintes desvantagens

bull E mais difıcil de implementar e a sincronizacao acarreta cuidados especiais

bull E necessario um cuidado adicional para evitar que as operacoes de sincronizacao

frequentes que ocorrem automaticamente nao afectem os tempos de resposta

da aplicacao

bull Os testes a aplicacao sao mais complexos uma vez que a sincronizacao de dados

nao ocorre em resposta a uma accao do utilizador

37

Desenvolvimento

43 Sincronizacao de dados

A sincronizacao de dados consiste na capacidade de identificar e transferir pe-

riodicamente a versao mais actual dos dados entre o cliente e o(s) servidor(es)

Independentemente do modo de execucao escolhido e mesmo do estado da ligacao

do utilizador a informacao armazenada localmente e a informacao armazenada no

servidor estarao por vezes dessincronizadas Isto podera acontecer sempre que por

exemplo

bull O utilizador faz alteracoes em modo offline

bull A informacao e partilhada e pode ser alterada por uma entidade externa

bull A informacao e fornecida por uma entidade externa

Resolver estas diferencas de forma a que a informacao local e remota encontrem

a igualdade chama-se sincronizacao de dados Ha varias aproximacoes possıveis

para este efeito que dependem da natureza da aplicacao cada uma com vantagens

e desvantagens

A capacidade de suportar a mobilidade dos utilizadores torna-se cada vez um

ponto mais importante de uma web application Para uma organizacao de dimensao

global e vital garantir que os seus colaboradores tem acesso a mesma informacao

que tem disponıvel nos seus postos de trabalho mesmo quando estao fora Na maior

parte dos casos estes colaboradores terao acesso a um computador portatil um

desktop Smartphone ou PDA e atraves destes poderao ter acesso a sua informacao

directamente atraves de ligacoes encriptadas Virtual Private Network (VPN) de um

servidor web ou de outro mecanismo de rede

Esta solucao e simples de implementar mas infelizmente para a maioria dos

colaboradores com grande factor de mobilidade nao e satisfatoria As principais

desvantagens sao as seguintes

bull Requisitos de ligacao Para permitir que os utilizadores acedam a sua in-

formacao e necessario garantir a capacidade constante de comunicacao pelo

menos durante o tempo necessario que assegure a sua transferencia

bull Velocidade de ligacao sem persistencia de dados e em ligacoes de fraca

qualidade a usabilidade por vezes torna-se inaceitavel

bull Ponto crıtico de falha Com este tipo de solucao todos os utilizadores de-

pendem da base de dados que armazena informacao vital para o funcionamento

do cliente

38

Desenvolvimento

bull Scalability do servidor A medida que novos utilizadores sao adicionados ao

sistema o desempenho do servidor e afectado levando a necessidade de maior

capacidade de armazenamento eou processamento

De acordo com a documentacao da Microsoft Sync Framework [Mic08] uma

solucao alternativa consiste em implementar uma Occasionally Connected Appli-

cation (OCA) Uma OCA permite a um utilizador remoto continuar a aceder a

sua informacao mesmo depois de perder a ligacao mas em vez de recorrer a um

servidor recorre a informacao armazenada no seu dispositivo local Para preencher

localmente a informacao que o utilizador necessita uma OCA possui mecanismos

de sincronizacao de dados que sao oferecidos por esta framework

431 Quando sincronizar

Uma das solucoes mais simples de implementar passa por disponibilizar um

mecanismo manual que despoleta a sincronizacao Diz-se manual porque e o uti-

lizador que escolhe quando sincronizar e pode ser implementada simplesmente

fazendo o upload de toda a informacao para o servidor e depois fazendo o download

da copia mais recente da informacao antes de voltar a ficar offline Para que esta

seja uma opcao viavel e necessario que

bull O volume de dados seja suficientemente pequeno para que possa ser transferido

do servidor para o cliente num espaco de tempo aceitavel

bull Que o utilizador indique explicitamente que quer mudar para o estado offline

ou online pressionando um botao da interface

Contudo podem ser identificados alguns problemas relacionados com esta abor-

dagem

bull Os utilizadores nem sempre podem prever o estado das suas ligacoes A ligacao

pode-se perder subitamente ou ter um caracter intermitente

bull O utilizador pode esquecer-se de efectuar a sincronizacao

Outra opcao sera conjugar a sincronizacao de dados com o modo de execucao

transparente A sincronizacao ocorre automaticamente em background de forma

nao intrusiva para o utilizador A aplicacao comunica com o servidor regularmente

efectuando pequenas trocas de dados com o objectivo de manter o sincronismo da

informacao local e remota Esta abordagem pode ser implementada com pedidos

Ajax assıncronos e regulares ao servidor o que permite manter a interaccao com a

interface fluıda evitando bloqueios Estes pedidos sao feitos prevendo as situacoes

39

Desenvolvimento

de disponibilidade ou indisponibilidade (timeout) do servidor Uma outra opcao

sera permitir que o servidor comunique essas alteracoes utilizando Comet1 tal como

descrito em [Wil06] e [Rus06] As vantagens destas aproximacoes sao

bull A informacao esta disponıvel a qualquer altura que o utilizador decida ficar

offline ou que a ligacao seja acidentalmente perdida

bull O desempenho da aplicacao pode ser melhorado quando se estiver a utilizar

uma ligacao a Internet lenta uma vez que o acesso a dados locais e mais

eficiente do que a consulta de dados ao servidor

44 WOW

O WOW e uma plataforma integrada de gestao de ordens de trabalho ja ex-

istente e desenvolvida pela Critical Software SA a qual se pretende adicionar a

capacidade de execucao offline Esta aplicacao e extremamente dinamica e con-

figuravel com um conjunto extremamente rico de funcionalidades das quais se

destacam

bull Gestao de Ordens de Trabalho ndash suportando a gestao dos pedidos desde a

sua criacao ate ao seu fecho tomando em conta os diferentes tipos de pedidos

(ordens de trabalho pedidos de informacao melhorias resolucao de problemas

etc) e diferentes tipos de accoes possıveis para cada um (Figura 45)

bull Monitorizacao de alteracoes ndash Historico de mudancas anexos e estados criando

relatorios de alteracao automaticamente (o que por quem e quando)

bull Uso de Service Level Agreements (SLAs) ndash E possıvel associar a um pedido um

SLA que define qual o perıodo de tempo atribuıdo a resolucao de um pedido

controlando e agilizando a resolucao do mesmo

bull Utilizacao de queries de utilizador configuraveis que permitem acesso rapido

a determinadas ordens de trabalho de acordo com o filtro configurado (por

exemplo ldquoPara mimrdquo ldquoPara o Grupordquo ldquoPelo Grupordquo)

bull Gestao do relacionamento entre pedidos

bull Pesquisa e filtragem de ordens de trabalho

bull Exportacao de dados em formatos padrao (PDF DOC ou XLS)

bull Integravel com solucoes externas

40

Desenvolvimento

Figura 45 Detalhe de um conjunto possıvel de estados e respectivas transicoes para umadada ordem de trabalho no WOW desde a sua submissao no sistema ate a sua conclusaoem fecho ou cancelamento Esta figura representa apenas um exemplo ja que o mapa deestados para uma ordem de trabalho e dinamico e pode ser alterado por um administradorFigura retirada de uma brochura promocional do WOW Critical Software SA

A utilizacao de uma ferramenta deste tipo por parte de uma empresa ou orga-

nizacao oferece vantagens quer a gestao de topo quer aos colaboradores individuais

para os colaboradores individuais o WOW e uma aplicacao onde estao registadas

todas as tarefas contribuindo activamente para o desenvolvimento em ambientes

multi-tarefa e para a organizacao pessoal das tarefas de acordo com prioridades

Para a gestao de topo esta ferramenta permite obter uma visao global do estado da

organizacao em termos de tempo gasto por tarefa executada sendo uma mais valia

para a previsao e gestaoalocacao de recursos

45 Visao geral sobre a arquitectura do WOW

O WOW e interessante nao so do ponto de vista de produto como tambem do

ponto de vista de plataforma Existem diversos plug-ins que estendem as funcional-

idades do WOW e existem ate projectos que pretendem usar a arquitectura do

WOW para criar produtos com fins diferentes do inicial (por exemplo o WOW-

Storm ndash um sistema de registo e classificacao social de ideias)

De modo a conseguir ter essa expansibilidade a plataforma WOW assenta sob

uma arquitectura distribuıda modular e expansıvel com uma componente central

ndash o core ndash estruturado em camadas logicas E no core que se situam todas as

1O Comet e um conceito semelhante ao Ajax introduzido por Alex Russel mas no qual e o servidor quetoma a iniciativa de ldquoenviarrdquo os dados ao browser sem que este tenha que efectuar um pedido Tambem econhecido por Ajax Push Reverse Ajax ou HTTP Streaming

41

Desenvolvimento

funcionalidades base da aplicacao quer a nıvel logico funcional e de apresentacao

quer a nıvel de gestao e configuracao

E possıvel a execucao de varias instancias do core simultaneamente em servidores

distintos o que permite a alta escalabilidade e disponibilidade desta aplicacao A

consistencia dos dados fica sempre garantida atraves da partilha da base de dados

e pelo balanceamento dos pedidos uma vez que cada um e encaminhado para uma

unica instancia

O WOW apresenta tambem a vantagem de ser uma plataforma extensıvel E

possıvel adicionar novas caracterısticas a plataforma atraves de componentes que se

podem ser divididos em duas categorias plugins e connectors

Os plugins sao componentes que se encontram no mesmo no fısico que a aplicacao

partilhando do mesmo contexto de execucao do core Sao assim uma forma mais

directa de obter informacao da plataforma visto que nao possuem restricoes de

acesso aos dados nem dependencias externas A arquitectura deste componente tera

assim que permitir varias execucoes instanciadas cada uma associada a um core

Por outro lado os connectors sao componentes que se encontram distribuıdos

comunicando externamente com o core Quer a sua execucao quer a obtencao

dos dados estao assim dependentes de interfaces de comunicacao externas que a

plataforma disponibiliza Estes componentes ao contrario dos plugins sao instan-

ciados unicamente e recorrem ao protocolo de comunicacao Java Messaging Service

(JMS) para comunicar com o core

46 WOW Offline

Para alem das opcoes tomadas relativamente a tecnologia a utilizar surgiu

tambem a necessidade de optar por um dos modos de execucao apresentados na

seccao 42

Das tres opcoes possıveis foi o modo ldquoaplicacao assume o estado offlinerdquo descrito

na seccao 423 que mereceu a maior atencao uma vez que reune as vantagens de

uma experiencia mais positiva para o utilizador (uma vez que este nao tem que

participar activamente na alteracao do modo execucao como descrito na seccao 421)

e nao constitui uma sobrecarga excessiva para servidor (como o modo abordado na

seccao 422)

No entanto esta opcao comprometia a complexidade da implementacao para alem

dos objectivos propostos para este projecto e para cumprir o prazo dado foi tomada

a decisao de implementar o modo ldquoutilizador deciderdquo especificando apenas de forma

teorica o modo ldquoaplicacao assume o estado offlinerdquo

As caracterısticas do Gears foram ja descritas na seccao 31 Na Figura 47

mostra-se a sua forma de funcionamento quando integrado numa web application

42

Desenvolvimento

Nesta figura representa-se o modulo LocalServer do Gears como um ponto de de-

cisao Aqui sao testadas as condicoes que determinam se o pedido sera interceptado e

servido localmente ou se prossegue para uma maquina remota E tambem represen-

tada uma base de dados que corresponde ao modulo Database mas que podera nao

ser utilizada Este modulo tal como o modulo Workerpool tem caracter opcional

e sao utilizados consoante os requisitos da aplicacao

A plataforma WOW lida com mais dados do que e necessario passar para o

lado do cliente Em conformidade com o ja exposto na seccao 411 volta-se a

frisar que nao se pretende recriar toda a logica de negocio nem os conteudos da

base de dados no cliente pela sua complexidade e volume de dados Pretende-se

pelo contrario permitir que os utilizadores tirem partido da capacidade de poder

consultar as suas ordens de trabalho quando nao dispoe de uma ligacao transferindo

apenas o essencial para isto seja possıvel

A pagina inicial do WOW apresenta um resumo das ordens de trabalho abertas

ndash enviadas e recebidas ndash que se pretende permitir visualizar offline (ver Figura 46)

Como prova de conceito foi efectuada uma abordagem pragmatica das varias possi-

bilidades descritas na seccao 42

461 Modo ldquoaplicacao deciderdquo com deteccao automatica da ligacao

A primeira abordagem estudada para a disponibilizacao das funcionalidades of-

fline foi o modo ldquoaplicacao deciderdquo com deteccao automatica de ligacao apresentado

na seccao 422 Para que isto seja possıvel foi implementado um mecanismo de ver-

ificacao periodica do estado da ligacao atraves de chamadas Ajax assıncronas O

resultado destes pedidos determina o estado da aplicacao executando as tarefas de

sincronizacao de dados sempre que pertinente Este metodo embora imediato e

simples de implementar depressa se revelou inadequado para o projecto devido ao

elevado consumo de recursos do servidor que a utilizacao intensiva faz esperar a

comunidade da plataforma WOW no principal cliente excede os 7000 utilizadores

Foi estimado que para uma utilizacao de fluidez aceitavel o estado da ligacao deveria

ser testado a cada cinco segundos Assumindo uma adesao (previsao pessimista) de

1 aos servicos offline assistir-se-ia a cerca de 840 pedidos adicionais por minuto

Mas o principal problema desta aproximacao prende-se com o facto de a ver-

ificacao ser feita em intervalos de tempo discretos levando a possibilidade de a

aplicacao poder ter em dado momento uma representacao errada do seu estado

real da ligacao Este problema e ilustrado na Figura 48 onde se ve claramente a

discrepancia entre o estado real da ligacao e a representacao interna que esta tem

Note-se que nesta janela de tempo qualquer accao do utilizador que exija uma

resposta sıncrona do utilizador leva-lo-a para um ldquobeco sem saıdardquo onde nao tera

43

Desenvolvimento

Figura 46 A pagina inicial do WOW apresenta um resumo das ultimas ordens de trabalhoenviadas e recebidas Na imagem pode-se observar a transicao do estado online para offline

acesso a versao offline porque a aplicacao nao fez a transicao automatica nem acesso

a versao online porque na verdade nao possui uma ligacao O que acontecera nesta

situacao sera uma tentativa de acesso ao servidor por parte da aplicacao numa

altura em que este se encontra indisponıvel e o resultado sera uma mensagem de

ldquopedido excedeu o tempordquo apresentado pelo browser Este e um estado sem retorno

porque apos o browser apresentar esta mensagem todos os recursos JavaScript ficam

indisponıveis tornando impossıvel o regresso ao estado anterior ou o tratamento do

erro de qualquer outra forma No entanto as chamadas Ajax podem ser tratadas de

forma especial para a eventualidade de falha e portanto nao constituem problema

44

Desenvolvimento

Figura 47 Ilustracao do funcionamento do Gears numa web application que utiliza ummotor Ajax Os pedidos HTTP ou HTTPS podem ser interceptados e tratados localmenteou podem ser feitos a uma maquina remota consoante se verificarem ou nao as condicoesexpressas no ponto 311 E representado um acesso a uma base de dados local (fornecidapelo Gears) mas a sua utilizacao e opcional

462 Implementacao do modo ldquoutilizador deciderdquo

Este modo de execucao foi ja descrito na seccao 421 e a sua principal carac-

terıstica e ser o utilizador a decidir se a aplicacao deve utilizar um servidor remoto

ou a maquina local como fornecedor de dados

Relativamente ao WOW o WOW Offline na vertente ldquoutilizador deciderdquo vem

alterar os seus casos de uso dando ao utilizador a possibilidade de alterar o estado

de execucao da aplicacao (entre online e offline) Resta dizer que no modo online se

mantem todas as funcionalidades anteriores e que no modo offline torna-se possıvel

visualizar os conteudos da pagina principal do WOW (Figura 46) e os detalhes das

ordens de trabalho (Figura 49) tal como expressa a Figura 410

Esta aproximacao foi utilizada na prova de conceito do WOW adicionando um

controlo a interface desta aplicacao que permite ao utilizador alternar entre os esta-

dos online e offline Na transicao de online para offline sao descarregados os recursos

necessarios para a execucao desta aplicacao sem recorrer a Internet Para o fazer

45

Desenvolvimento

Figura 48 Neste exemplo do modo ldquoaplicacao deciderdquo o teste da ligacao e feito e feito acada cinco segundos O resultado deste teste nao reflecte sempre o estado real da aplicacaopodendo levar a aplicacao a ter comportamentos indesejaveis Na figura assinala-se umperıodo de tempo no qual a representacao interna do estado da ligacao nao corresponde arealidade

e utilizado um recurso ResourceStore e um ManagedResourceStore (introduzidos

em 311) O primeiro e utilizado para armazenar a pagina principal do WOW ndash do-

ravante designada por homejsp ndash e o segundo e utilizado para armazenar imagens

folhas de estilo CSS e scripts JavaScript

Para a implementacao deste modo de execucao foram identificadas as seguintes

tarefas

1 Guardar informacao que permita a recriacao das paginas que se pretende

disponibilizar offline (utilizando o Gears)

2 Disponibilizar um controlo que permita alterar o estado de execucao atraves

da interaccao com a pagina principal

3 Durante a sincronizacao de dados apresentar o progresso da transferencia de

dados

O primeiro passo consistiu na identificacao de todos os conteudos que sao necessarios

transferir para a execucao offline Foi utilizado um recurso do Gears do tipo

ManagedResourceStore que recorre a um ficheiro manifesto para identificar to-

dos os ficheiros que deve transferir Este recurso e gerido automaticamente pelo

Gears transferindo para o cliente a versao mais recente sempre que e necessario

isto e sempre que exista um ficheiro manifesto com uma identificacao de versao que

seja diferente da actualmente disponıvel no cliente Uma vez identificados todos

ficheiros necessarios para a execucao offline num (ou mais) ficheiros manifesto o

Gears encarrega-se da sua actualizacao mas o preenchimento destes ficheiros man-

ifesto e manual o que se traduz num cuidado extra na manutencao da aplicacao

A forma como esta informacao e guardada deve tambem ser cuidadosamente

estudada A opcao mais flexıvel passa por utilizar o modulo Database apresentado

na seccao 311 e guardar a informacao de uma forma relacional Para a recriacao

das paginas pode ser disponibilizada uma versao HTML da pagina que funciona

46

Desenvolvimento

Figura 49 Pagina de visualizacao do detalhe de uma ordem de trabalho

como template nao possui quaisquer dados e e utilizada apenas em modo offline E

preenchida para cada pedido retirando os dados relevantes da base de dados

O modelo de dados do WOW torna esta opcao extremamente trabalhosa uma

vez que as entidades envolvidas na geracao de cada pagina de informacao sobre

cada ordem de trabalho tem relacoes de dependencia complexas seguindo padroes

muito variaveis Por exemplo em cada ordem de trabalho existe um formulario que

permite a sua progressao de estado com diversos campos opcionais e obrigatorios

este formulario e definido pelo administrador e esta relacionado nao apenas com o

tipo de ordem de trabalho mas tambem com o estado actual em que esta se encontra

e a accao que se pretende realizar O elevado numero de combinacoes de tipos de

ordem de trabalho estados e accoes que existem num dado momento juntamente

com a sua possibilidade de alteracao obrigariam a implementacao de uma logica de

negocio complexa o que esta fora do ambito deste projecto

47

Desenvolvimento

Figura 410 Esquema UML que expressa os casos de uso do WOW Offline no modoldquoutilizador deciderdquo

463 Especificacao do modo ldquoaplicacao assume o estado offlinerdquo

A aproximacao para o modo ldquoaplicacao assume o estado offlinerdquo foi tambem

dividida em varias tarefas

1 Guardar informacao que permita a recriacao da pagina principal do lado do

cliente no estado offline (utilizando o Gears)

2 Dotar a aplicacao do cliente de um mecanismo de deteccao da ligacao

3 Identificar os ldquomomentos chaverdquo em que devera ocorrer sincronizacao de dados

4 Implementar a sincronizacao de dados

A sincronizacao de dados deve ser feita em ambas as transicoes online-offline e

offline-online quer para transferir novos dados do servidor (os pedidos podem ser

alterados por outros utilizadores) quando se transita do estado quer para comunicar

eventuais alteracoes feitas em modo offline

Relativamente ao WOW o WOW Offline na vertente ldquoaplicacao assume o es-

tado offlinerdquo vem alterar os seus casos de uso dando ao utilizador a possibilidade

de activar esta funcionalidade A partir do momento que a funcionalidade esta ac-

tivada o utilizador deve tambem ter a possibilidade de gerir algumas preferencias

relacionadas com privacidade de dados Devera ter a hipotese de desactivar o ar-

mazenamento local e de remover todos os dados ja armazenados tal como descrito

na Figura 411

48

Desenvolvimento

Figura 411 Esquema UML que expressa os casos de uso do WOW Offline no modoldquoutilizador deciderdquo

A primeira vez que o WOW Offline e acedido por um cliente e caso seja detec-

tada a presenca do Gears todos os recursos necessarios a sua execucao sao trans-

feridos Todos os acessos posteriores serao feitos a estes recursos locais (recorda-se

que o Gears pode ser utilizado para os manter actualizados recorrendo ao Managed-

ResourceStore 311)

Atraves do JavaScript e possıvel interceptar os eventos de load e unload da

pagina que sao despoletados sempre que ocorre um re-acesso da mesma (incluindo

a accao refresh comum dos browsers) sempre que esta e abandonada ou ainda ou

ainda se a janela for encerrada

Tal como sugerido na seccao 462 a camada de interface desta aplicacao (cada

pagina individual em HTML) devera ser implementada como sendo um template

para apresentacao de dados sendo totalmente preenchida atraves de funcoes em

JavaScript O objectivo deste ponto e criar um padrao de dados que permita ao

JavaScript preencher os dados em cada pagina (template) independentemente de

qual seja a fonte ndash o servidor remoto ou a maquina local tal como exemplificado

no diagrama da Figura 412 Na figura a aplicacao recorre ao servidor remoto para

obter os dados pretendidos quando se encontra na presenca de uma ligacao mas

para dados que exijam uma carga de processamento pelo servidor este acto pode ser

49

Desenvolvimento

Figura 412 Esquema UML que expressa o acto de recolha de dados em modo online eoffline recorrendo ao servidor (modo online) e ao sistema de armazenamento de dadoslocal fornecido pelo Gears (modo offline)

substituıdo pelo envio de um campo de controlo que se destina a aferir se os dados

locais se encontram actualizados No caso de estarem actualizados a comunicacao

com o servidor pode ser substituıda por uma query a base de dados local

50

Capıtulo 5

Resultados e Futuros

Desenvolvimentos

Todo o estudo feito sobre o tema OWA foi ja abordado ao longo do documento

Neste capıtulo apresentam-se os resultados obtidos na implementacao da prova de

conceito que visava compreender a melhor forma de disponibilizar uma versao of-

fline no WOW uma plataforma de gestao de ordens de trabalho ja existente de-

senvolvida pela Critical Software SA

51 Resultados Obtidos

Os resultados obtidos neste projecto sao extremamente satisfatorios uma vez

que o estudo do tema OWA e a implementacao de uma prova de conceito que o

ilustrasse foi conseguido com sucesso

A funcionalidade offline foi adicionada ao produto WOW da Critical Software

SA permitindo a visualizacao de ordens de trabalho e dos seus detalhes mesmo na

ausencia de uma conexao activa a Internet Embora para a solucao implementada

tenha sido utilizada uma abordagem do tipo ldquoutilizador deciderdquo pretende-se que esta

seja convertida para ldquoaplicacao deciderdquo ou mesmo para uma aproximacao hıbrida

semelhante a utilizada pelas aplicacoes estudadas nas seccoes 351 e 352

Para a sua implementacao descrita no capıtulo 4 foram tomadas decisoes de or-

dem pratica que permitissem tornar o trabalho exequıvel nos prazos dados Tentou-

se sempre que estas decisoes afectassem o mınimo em termos de desempenho e de

experiencia para o utilizador Considera-se que a implementacao do modo offline

com uma transicao entre modos do tipo ldquoutilizador deciderdquo (ver seccao 42) reflecte

o compromisso entre o desempenho pretendido e os recursos disponıveis e para alem

51

Resultados e Futuros Desenvolvimentos

de ser um exemplo eficaz das possibilidades que as OWA podem trazer a aplicacao

WOW desenvolvida pela Critical Software e tambem um estudo que pode ser uti-

lizado para analisar a implementacao desta tecnologia noutros produtos da mesma

empresa

Note-se que o principal objectivo do trabalho era ganhar familiaridade com este

tema entender as suas vantagens e desvantagens e compreender as suas limitacoes

Tudo indica que existam varias possibilidades de implementacao deste paradigma

noutros produtos da Critical Software que pela sua natureza podem tambem tirar

partido da execucao offline

52 Trabalho Futuro

O desenvolvimento do conceito e formas de implementacao de OWA continua

em forte desenvolvimento no entanto a sua adopcao ainda nao e generalizada A

dificuldade da sua implementacao em web applications ja existentes e o principal

obstaculo a sua maior divulgacao

Ha tambem um factor que deve ser tido em consideracao a manutencao de

codigo A implementacao de uma versao offline de uma web application requer

a implementacao das mesmas regras de negocio (ou de uma versao simplificada)

utilizadas no servidor Para que isto seja possıvel e necessario ter em conta a

capacidade de processamento do cliente e o factor de duplicacao de codigo que

tornara a aplicacao mais difıcil de manter uma vez que uma alteracao a logica de

negocio do servidor implica tambem uma alteracao a sua versao offline

A prova de conceito implementada permite ja a visualizacao offline dos pedidos

abertos (enviados e recebidos) que constam na pagina principal (este numero e

fixo e pode ser alterado pelo administrador) Uma funcionalidade desejavel seria a

possibilidade de interaccao com a aplicacao em modo offline e sincronizacao com o

servidor quando existisse uma ligacao disponıvel

Foi estudada a utilizacao do modo de execucao ldquoaplicacao assume o estado of-

flinerdquo descrito em 423 e esta seria a forma desejavel para o WOW Offline no

entanto para que esta opcao seja viavel sera necessaria a implementacao de uma

forma eficiente de sincronizacao e armazenamento de dados de uma forma relacional

Para atingir este objectivo podera ser seguida uma polıtica de automacao do pro-

cesso no qual a versao online da aplicacao gera scripts de criacao para as tabelas

necessarias na base de dados da versao offline (nao existe nenhuma ferramenta para

o fazer portanto seria necessaria a sua implementacao) e no qual as paginas HTML

disponibilizadas pelo servidor aos clientes web (browser) servem como templates de

apresentacao de informacao e sao preenchidas de forma semelhante pelo servidor ndash

quando a aplicacao estiver online ndash ou pelo cliente atraves de funcoes em JavaScript

52

Resultados e Futuros Desenvolvimentos

ndash quando a aplicacao estiver offline No entanto no WOW devido a quantidade de

informacao tratada e devido as complexas relacoes entre as diferentes entidades e

de esperar que a complexidade da implementacao de um mecanismo deste tipo torne

esta aproximacao demasiado custosa

O HTML 5 embora um forte candidato ainda nao esta suficientemente desen-

volvido A sua especificacao ainda tem o caracter de Draft (rascunho) e esta sujeita

a modificacoes e a aceitacao e implementacao por parte dos browsers e portanto

de momento foi desconsiderado No entanto no futuro se esta especificacao atingir

um estado de maturidade que permita a sua adopcao devera ser considerada como

um possıvel caminho a seguir

53

Resultados e Futuros Desenvolvimentos

54

Capıtulo 6

Conclusoes

Neste capıtulo sao apresentadas as conclusoes do projecto e consideracoes finais

relativamente a tecnologia estudada

61 Conclusoes

O rapido desenvolvimento tecnologico faz prever que a disponibilidade de ligacao

a Internet seja cada vez mais facil e mais rapido mas vao continuar a existir lugares

onde o acesso e limitado e onde as OWA podem desempenhar um papel de relevo

Por outro lado esta tecnologia pode tambem ser utilizada para melhorar o desem-

penho de paginas web com uma necessidade elevada de imagens ou outros recursos

dispendiosos em termos de espaco e foram ate estudados dois exemplos da utilizacao

desta vertente desta tecnologia em 353

Acredita-se que as OWAs vem responder a uma necessidade real por parte das

web applications actuais e que a evolucao que representam se compara a que se

assistiu dos thin-clients para os fat-clients em termos de autonomia do servidor

A capacidade de oferecer conteudos dinamicos no browser independentemente da

existencia de uma ligacao reune as vantagens tıpicas das web applications como

ausencia de instalacao e actualizacoes instantaneas com as vantagens das aplicacoes

de desktop em capacidade de processamento e armazenamento de dados na maquina

local

As tecnologias disponıveis ate a data estudadas no ambito deste projecto que

permitem o desenvolvimento de OWAs e que apresentam maior maturidade sao o

Gears e o Adobe AIR Ambas se apresentam sobre a forma de plugins que necessitam

de uma instalacao extra para poderem ser utilizadas Apesar de esta instalacao ser

55

Conclusoes

apenas necessaria uma vez podera constituir um factor de desencorajamento a sua

adopcao

O HTML 5 uma especificacao abordada neste documento na seccao 34 podera

ser uma alternativa que oferece funcionalidades offline a uma web application sem a

necessidade de qualquer instalacao no entanto esta especificacao ainda nao foi aceite

pelos principais browsers ndash o documento que define o HTML 5 ainda tem o estatuto

de Draft ndash e ainda nao e possıvel antecipar quando e que isto podera acontecer

Um dos problemas que surge frequentemente na implementacao de uma versao

offline para uma web application e a necessidade de sincronizacao de dados Quando

a informacao pode ser alterada por varios utilizadores simultaneamente e necessario

prever os conflitos que daı podem surgir e dotar a aplicacao de uma forma de os

resolver ou alertar o utilizador para a necessidade de alteracao dos dados

Em conclusao todos os objectivos propostos para este projecto foram atingidos

A prova de conceito implementada reflecte de forma clara as possibilidades oferecidas

pela tecnologia OWA e sera utilizado no futuro para compreender a melhor forma

de o implementar de forma definitiva no WOW

56

Referencias

[Ada08] Lucas Adamski Introducing Adobe AIR security model Fevereiro de2008 Disponıvel em httpwwwadobecomdevnetairarticles

introduction_to_air_securityhtml acedido em Marco de 2008

[Ado08] Adobe Adobe AIR 10 Security White Paper 2008 Disponıvel emhttpdownloadmacromediacompubairdocumentation1air_

securitypdf acedido em Marco de 2008

[Alm08] Dion Almaer Gears as a bleeding-edge html 5 implementa-tion March 2008 Disponıvel em httpalmaercomblog

gears-as-a-bleeding-edge-html-5-implementation acedido emMarco de 2008

[BL96] Tim Berners-Lee The world wide web Past present and future Agostode 1996 Disponıvel em httpwwww3orgPeopleBerners-Lee

1996ppfhtml acedido em Abril de 2008

[CDGH08] Mike Chambers Daniel Dura Dragos Georgita and Kevin Hoyt AdobeAIR for JavaScript Developers OrsquoReilly Media 2008 Disponıvel emhttponairadobecomfilesAIRforJSDevPocketGuidepdf ace-dido em Abril de 2008

[Con99] Jim Conallen Modeling Web Application Architectures with UML Junho1999 Disponıvel em httpwwwumlorgcnUMLApplicationpdf

webappspdf acedido em Maio de 2008

[Ent07] Entrust What is a public key information 2007 Disponıvel em http

wwwentrustcompkihtm acedido em Junho de 2008

[Gar05] Jesse James Garret Ajax A new approach to web applicationsFebruary 2005 Disponıvel em httpwwwadaptivepathcomideas

essaysarchives000385php acedido em Marco de 2008

[Greon] Philip Greenspun Philip and Alexrsquos Guide to Web Publishing 2003(last revision) Disponıvel em httpphilipgreenspuncompandaacedido em Junho de 2008

[Gro02a] App Design Group Thick vs thin client comparison 2002 Disponıvelem httpwwwdonjacobsvwcomimagesweekendspecials

Thick-vs-Thinpdf acedido em Junho de 2008

57

REFERENCIAS

[Gro02b] Technical Research Group Thin Client Tecnhology - WhitePaper 2002 Disponıvel em httpwwwpicktrgcompubs

thinclientwhitepaperpdf acedido em Junho de 2008

[Gro08] Miniwatts Marketing Group World internet usage March 2008Disponıvel em httpwwwinternetworldstatscomstatshtm ace-dido em Abril de 2008

[Hic08] Ian Hickson HTML 5 Draft Recommendation 2008 Disponıvelem httpwwwwhatwgorgspecsweb-appscurrent-work ace-dido em Marco de 2008

[Kha] Olga Kharif Top 10 municipal wifi plans Disponıvel em http

imagesbusinessweekcomss0608muni_wifiindex_01htm ace-dido em Marco de 2008

[Lab07] Mozilla Labs Prism Outubro 2007 Disponıvel em httplabs

mozillacom200710prism acedido em Marco de 2008

[Loo06] Chris Loosley Rich Internet ApplicationsDesign MeasurementandManagement Challenges 2006 Disponıvel em httpwwwkeynote

comdocswhitepapersRichInternet_5pdf acedido em Maio de2008

[Mic08] Microsoft Introduction to Occasionally Connected Applications us-ing Sync Services for ADONET 2008 Disponıvel em httpmsdn

microsoftcomen-ussyncbb887608aspx acedido em Junho de2008

[Nao08] Erica Naone Offline web applications Abril 2008 Disponıvelem httpwwwtechnologyreviewcomread_articleaspxch=

specialsectionsampsc=emerging08ampid=20245 acedido emAbril de 2008

[NJN00] Jason Nieh Yang S Jae and Naomi Novik A comparison of thin-clientcomputing architectures 2000 Disponıvel em httpwwwnclcs

columbiaedupublicationscucs-022-00pdf acedido em Maio de2008

[OrsquoR06] Tim OrsquoReilly Web 20 compact definition Trying again Dezembro2006 Disponıvel em httpradaroreillycomarchives200612

web-20-compact-definition-tryihtml acedido em Marco de 2008

[OrsquoR09] Tim OrsquoReilly What is Web 20 Design patterns and business modelsfor the Next Generation of Software 20053009 Disponıvel emhttpwwworeillynetcompubaoreillytimnews200509

30what-is-web-20html acedido em Marco de 2008

[Rus06] Alex Russel Comet Low latency data for the browser March Marco2006 Disponıvel em httpalexdojotoolkitorgp=545 acedidoem Marco de 2008

58

REFERENCIAS

[Sad97] Darleen Sadoski Clientserver software architecturesndashan overviewAgosto 1997 Disponıvel em httpwwwseicmuedustr

descriptionsclientserver_bodyhtml acedido em Junho de2008

[Sch96] George Schussel Clientserver past present and future 1996

[Smi07] Kevin C Smith Css filters - will the browser apply the rule July 2007Disponıvel em httpcentriclecomrefcssfilters acedido emMarco de 2008

[vK08] Anne van Kesteren The XMLHttpRequest Object W3C Work-ing Draft 15 Abril 2008 Disponıvel em httpwwww3orgTR

XMLHttpRequest acedido em Abril de 2008

[Wil06] Greg Wilkins Why ajax comet July Julho 2006 Disponıvel emhttpwwwwebtidecomdownloadswhitePaperWhyAjaxhtml ace-dido em Abril de 2008

59

REFERENCIAS

60

Anexo A

Screenshots

Algumas imagens de aplicacoes que utilizam funcionalidades offline ilustrativasda tecnologia abordada neste documento

Figura A1 Dialogo apresentado ao utilizador na primeira activacao das funcionalidadesoffline no Google Docs amp Spreadsheets

61

Screenshots

Figura A2 Na activacao das funcionalidades offline e tambem oferecida a possibilidadeda criacao de alguns atalhos por exemplo no ambiente de trabalho

Figura A3 O Google Docs mantem a todo o momento a possibilidade de alteracao destasdefinicoes ou da anulacao dos servicos offline para um dado computador

62

Screenshots

Figura A4 Apos a instalacao do Gears qualquer visita ao Remember The Milk despoletauma sincronizacao que ocorre automaticamente e sem necessidade de intervencao por partedo utilizador

Figura A5 Apos completar a sincronizacao de dados mesmo que a ligacao a Internetseja perdida o Remember the Milk continua disponıvel no browser (com excepcao dasfuncionalidades que pela sua natureza exigem uma ligacao como por exemplo partilhade tarefas e envio de convites)

63

Page 12: O ine Web Applications

Lista de Figuras

21 Arquitectura de um sistema thin-client em duas camadas (a esquerda)e em tres camadas (a direita) Note-se a inclusao do servidor (main-frame) na definicao das camadas desta arquitectura devido a fortedependencia cliente-servidor 9

22 Arquitectura de um fat-client em duas camadas (a esquerda) e emtres camadas (a direita) 10

23 Comparacao do modelo de web aplications sıncrono paginas estaticase interactivas abordados nas seccoes 221 e 222 com o modelo deweb applications Ajax (assıncrono) abordado na seccao 223 Figuraadaptada de http www adaptivepath com 15

31 Esquema UML do processo efectuado pelos recursos do Gears do tipoManagedResourceStore para a actualizacao dos conteudos definidosno ficheiro manifesto 29

41 Exemplo de uma arquitectura de uma web application sem uma ca-mada de abstraccao de dados Figura adaptada de http gears

google com 33

42 Exemplo de uma arquitectura de uma web application com uma ca-mada de abstraccao de dados Figura adaptada de http gears

google com 34

43 Exemplo de uma arquitectura de uma web application com uma ca-mada de abstraccao de dados e um data switch Figura adaptada dehttp gears google com 35

44 Esquema grafico ilustrando uma OWA executando no browser uti-lizando um modo de execucao do tipo ldquoaplicacao deciderdquo com de-teccao automatica do estado da ligacao via pedidos Ajax assıncronosa cada cinco segundos 37

45 Detalhe de um conjunto possıvel de estados e respectivas transicoespara uma dada ordem de trabalho no WOW desde a sua submissaono sistema ate a sua conclusao em fecho ou cancelamento Esta figurarepresenta apenas um exemplo ja que o mapa de estados para umaordem de trabalho e dinamico e pode ser alterado por um admin-istrador Figura retirada de uma brochura promocional do WOWCritical Software SA 41

ix

LISTA DE FIGURAS

46 A pagina inicial do WOW apresenta um resumo das ultimas ordensde trabalho enviadas e recebidas Na imagem pode-se observar atransicao do estado online para offline 44

47 Ilustracao do funcionamento do Gears numa web application que uti-liza um motor Ajax Os pedidos HTTP ou HTTPS podem ser inter-ceptados e tratados localmente ou podem ser feitos a uma maquinaremota consoante se verificarem ou nao as condicoes expressas noponto 311 E representado um acesso a uma base de dados local(fornecida pelo Gears) mas a sua utilizacao e opcional 45

48 Neste exemplo do modo ldquoaplicacao deciderdquo o teste da ligacao e feitoe feito a cada cinco segundos O resultado deste teste nao reflectesempre o estado real da aplicacao podendo levar a aplicacao a tercomportamentos indesejaveis Na figura assinala-se um perıodo detempo no qual a representacao interna do estado da ligacao nao cor-responde a realidade 46

49 Pagina de visualizacao do detalhe de uma ordem de trabalho 47410 Esquema UML que expressa os casos de uso do WOW Offline no

modo ldquoutilizador deciderdquo 48411 Esquema UML que expressa os casos de uso do WOW Offline no

modo ldquoutilizador deciderdquo 49412 Esquema UML que expressa o acto de recolha de dados em modo

online e offline recorrendo ao servidor (modo online) e ao sistemade armazenamento de dados local fornecido pelo Gears (modo offline) 50

A1 Dialogo apresentado ao utilizador na primeira activacao das funcional-idades offline no Google Docs amp Spreadsheets 61

A2 Na activacao das funcionalidades offline e tambem oferecida a possi-bilidade da criacao de alguns atalhos por exemplo no ambiente detrabalho 62

A3 O Google Docs mantem a todo o momento a possibilidade de alteracaodestas definicoes ou da anulacao dos servicos offline para um dadocomputador 62

A4 Apos a instalacao do Gears qualquer visita ao Remember The Milkdespoleta uma sincronizacao que ocorre automaticamente e sem ne-cessidade de intervencao por parte do utilizador 63

A5 Apos completar a sincronizacao de dados mesmo que a ligacao aInternet seja perdida o Remember the Milk continua disponıvel nobrowser (com excepcao das funcionalidades que pela sua naturezaexigem uma ligacao como por exemplo partilha de tarefas e enviode convites) 63

x

Lista de Tabelas

21 Comparacao entre thin-clients e fat-clients 7

31 Comparacao das funcionalidades oferecidas pelo Adobe AIR para asplataformas web e desktop 30

32 Resumo da utilizacao de tecnologias OWA em algumas web applica-tions consideradas na analise do estado da arte 31

xi

LISTA DE TABELAS

xii

Glossario

fat-client Cliente que nao depende totalmente de umservidor central para as suas actividadesde processamento e possui frequentementedispositivos de armazenamento de dados

6ndash8

thin-client Cliente que depende de um servidor centralpara as suas actividades de processamento

5ndash8

web application Sistema web (servidor rede HTTPbrowser) onde accoes do utilizador(navegacao e introducao de informacao)afectam o estado logico da aplicacao

i iii1ndash311ndash1517ndash1921ndash232728 3336ndash3842 5556

API Application Programming Interface 10 1718 2326 28

ASP Linguagem interpretada pelo servidorque permite a criacao de paginas webdinamicas Desenvolvida pela Microsoft

11

BSD Berkeley Software Distribution 28

CSS Cascading Style Sheets 12 2021 2324 46

DHTML Dynamic HyperText Transfer Protocol 24DOM Document Object Model 10 12

20 2324

DTD Document Type Definition 24

xiii

Glossario

ECMAScript Padrao de linguagem de programacaodefinido pela Ecma International que orig-inou o JavaScript e o JScript

24

Flash Conteudo interactivo de um ficheiro emformato SWF E desenvolvido pela Adobee visualizado atraves do Adobe FlashPlayer

21

Flex Framework baseada em XML e Action-Script desenvolvida pela Adobe para a pro-gramacao de Rich Internet Applications(RIA)

21

GPL GNU General Public License 23

HTML HyperText Markup Language 1 10ndash12 2124ndash2649

HTTP HyperText Transfer Protocol 2 26

JMS E uma API em Java que permite a troca demensagens entre componentes de software

42

JSON JavaScript Object Notation permite atroca de dados codificados num formatode texto de simples leitura

12 1828 34

LGPL GNU Lesser General Public License 23

Mozilla Prism Browser simplificado e ldquointerpretadorrdquo deeXtensible User Interface Language (XUL)(tambem designado por XULRunner) queacolhe web applications sem a interfacegrafica habitual de um browser

25

MPL Mozilla Public License 23

OCA Occasionally Connected Application 39OWA Offline Web Application i iii

2ndash515 1725 2628 3133 3651 5255 56

PDF Portable Document Format 21

xiv

Glossario

PHP Linguagem interpretada pelo servidorque permite a criacao de paginas webdinamicas mas que pode tambem ser in-vocada a partir da linha de comandos

11

pagina web estatica Pagina web que devolve sempre a mesmaresposta a todos os pedidos para todos osutilizadores e em qualquer contexto

5 9

RIA Rich Internet Applications web appli-cations que apresentam funcionalidadessemelhantes as desktop applications masque mantem a informacao no lado do servi-dor

5 1520 28

RSS Really Simple Syndication 27

SLA Service Level Agreement 40SQLite Segundo a definicao oficial SQLite is a

software library that implements a self-contained serverless zero-configurationtransactional SQL database engine

17

SSB Site Specific Browser 25SSL Secure Sockets Layer 22SWF ShockWave Flash 21

URL Uniform Resource Locator 18

VPN Virtual Private Network 38

WOW Work Orders Web Plataforma de gestaode ordens de trabalho e do seu fluxo de-senvolvida pela Critical Software SA

i iii28 3340ndash434551ndash5356

WWW World Wide Web 11 1214

XBL eXtensible Binding Language 24XHTML eXtensible HyperText Markup Language 12XML eXtensible Markup Language 11 12

23 2428

XSLT eXtensible Stylesheet Language Transfor-mation

12

XUL eXtensible User Interface Language xiv23ndash25

xv

Glossario

xvi

Capıtulo 1

Introducao

Neste capıtulo enquadra-se o tema do projecto introduzindo alguns dos conceitos

nos quais se baseia Apresentam-se as motivacoes ambito objectivos e a estrutura

deste documento

11 Enquadramento

A Internet foi originalmente concebida para ser um espaco de partilha de in-

formacao onde pessoas (atraves de maquinas) pudessem comunicar Na sua origem

as paginas eram estaticas constituıdas por texto formatado em HyperText Markup

Language (HTML) e ligadas entre si [BL96] Hoje encontramos conteudos cada vez

mais complexos e dinamicos incluindo som vıdeo ou streams multimedia [Loo06] e

em 2005 foi introduzido por [OrsquoR09] o termo Web 20

De acordo com [Greon] um website pode pertencer a uma ou varias das seguintes

categorias

bull Documento ndash um website essencialmente estatico onde alteracoes a uma

parte do conteudo nao tem implicacoes no seu comportamento

bull Base de dados ndash um directorio de informacao organizada em categorias

bull Aplicacao ndash um website dinamico que utiliza uma linguagem executada ou

interpretada do lado do servidor e que processa as accoes ou informacao in-

troduzida pelo utilizador para fornecer um servico ou nova informacao

A ultima destas categorias constitui aquilo que e normalmente designado por

web application O conceito utilizado ao longo deste documento e o mesmo que

o introduzido por Jim Coallen em [Con99] que define web application como um

1

Introducao

sistema web (servidor rede HyperText Transfer Protocol (HTTP) browser) onde

accoes do utilizador (navegacao e introducao de informacao) afectam o estado logico

da aplicacao A sua definicao tenta estabelecer que uma web application e um

sistema de software com estado de negocio1 e que a sua interface de interaccao com

o utilizador e distribuıdo atraves de um sistema web

12 Motivacao

A quantidade de informacao que e produzida e armazenada com recurso a es-

tas web applications disponıveis online tais como e-mail blogues ou mesmo docu-

mentacao tornam por vezes a disponibilidade de ligacao uma condicao necessaria

a produtividade e como consequencia desta barreira muitos potenciais utilizadores

opoem-se a adopcao de produtos web em detrimento das tradicionais desktop appli-

cations

Assegurar o acesso a uma ligacao de Internet e hoje muito mais facil A Internet

movel e ja uma realidade e encontra-se amplamente divulgada mas continuam a

existir diversas situacoes nas quais os utilizadores estao privados de uma ligacao

a Internet tais como uma viagem de metro ou de aviao ou quando se encontram

deslocados do seu paıs de origem e nao possuem nenhum plano de subscricao

Uma OWA consiste numa web application que para alem de manter todas as

caracterısticas anteriores se mantem disponıvel mesmo na ausencia de uma ligacao

a Internet e surge como uma tentativa de estreitar as barreiras existentes entre a

web e o desktop Isto significa que devera existir um mecanismo capaz de assegurar

a manutencao do estado logico da aplicacao quando a ligacao com o servidor e

quebrada permitindo ao utilizador continuar a utilizar a aplicacao e que sera capaz

de informar o servidor do estado em que a aplicacao se encontra quando a ligacao for

reposta A principal vantagem que advem desta possibilidade e evidente eliminar

a necessidade da existencia de uma ligacao a Internet para que a aplicacao possa ser

utilizada

Por outro lado a vontade de integracao de funcionalidades tıpicas das desktop

applications nas web applications foi um dos principais factores que impulsionou o

desenvolvimento deste conceito uma vez que obrigou a uma reflexao ldquopara alem

do browserrdquo e a uma adaptacao das arquitecturas existentes que permitisse ou o

acesso a funcionalidades disponibilizadas pelo sistema operativo ou pelo menos a

funcionalidades semelhantes Pretende-se com esta aproximacao tornar possıveis

interaccoes entre o desktop e o browser tais como arrastar um ficheiro para um

formulario web de upload de conteudos melhor suporte para o historico do clipboard

ou ainda o acesso ao sistema de ficheiros local Atingir estes objectivos reflecte-se

1NT business state

2

Introducao

num novo paradigma que reune as vantagens das web applications tais como os

updates instantaneos ou o facto de nao ser necessaria nenhuma instalacao e das

desktop applications como por exemplo persistencia no armazenamento de dados

acesso a funcionalidades do sistema operativo ou integracao e interaccao com outras

aplicacoes sejam elas web applications ou desktop applications

13 Ambito

Este projecto foi realizado na Critical Software SA no ambito do Mestrado

Integrado em Engenharia Informatica e Computacao (MIEIC) da Faculdade de En-

genharia da Universidade do Porto (FEUP) entre os meses de Fevereiro e Julho de

2008

14 Objectivos

Sao objectivos deste projecto

1 Estudar e documentar o tema das OWAs acompanhando os ultimos desenvolvi-

mentos nesta materia

2 Analisar o estado da arte fazendo uma analise crıtica e objectiva sobre as

diversas metodologias existentes

3 Implementar uma prova de conceito que permita a execucao offline de uma

web application documentando todo o processo

4 Estudar a possibilidade de permitir interaccao com a aplicacao (insercoes e

alteracoes aos dados) em modo offline

Em resumo o objectivo deste projecto foi estudar documentar e implementar

uma prova de conceito relacionada com o tema Offline Web Applications (OWA)

Este tema embora nao seja totalmente novo ganhou destaque ao longo do ano de

2007 com o surgimento de diversas ferramentas que se destinam a aproximar web

applications das desktop applications

15 Estrutura do documento

Este documento esta organizado em diferentes seccoes apresentando o projecto

numa sequencia logica organizada da seguinte forma

No capıtulo 1 faz-se uma breve apresentacao do conceito OWAs e do contexto em

que surge Apresenta-se tambem a estrutura do documento e definem-se os

termos e acronimos utilizados

3

Introducao

No capıtulo 2 faz-se uma descricao da evolucao das tecnologias que antecedem as

OWAs e das vantagens e desvantagens de cada uma como forma de enquadra-

mento

No capıtulo 3 analisa-se o estado da arte nesta materia Introduzem-se diversas

tecnologias directamente relacionadas com o tema deste projecto exemplos de

aplicacoes que as usam e as razoes que fundamentam as escolhas de tecnologias

efectuadas

O capıtulo 4 contem o desenvolvimento do projecto Analisa-se a plataforma

WOW de gestao integrada de ordens de trabalho a tecnologia escolhida e

a forma como foi utilizada para implementar a capacidade de execucao offline

O capıtulo 5 descreve os resultado obtidos comparando-os com as expectativas

iniciais do projecto e apresenta desenvolvimentos futuros e possibilidades de

continuacaoaplicacao do conhecimento adquirido

No capıtulo 6 apresentam-se as conclusoes

4

Capıtulo 2

Enquadramento do Projecto

Neste capıtulo apresenta-se um breve resumo da evolucao das arquitecturas de

software cliente-servidor e a forma como estas se comparam a evolucao da Inter-

net procurando estabelecer uma analogia entre o percurso de ambas as tecnolo-

gias Compara-se o comportamento e arquitectura dos thin-clients as paginas web

estaticas a evolucao dos fat-clients as paginas interactivas Web 20 e Ajax e

defende-se que as OWA constituem um proximo passo logico e evolutivo aproxi-

mando a web do desktop Referem-se ainda os principais factores que justificam a

importancia das OWAs e a estreita relacao que tem com as Rich Internet Application

(RIA)s

21 Evolucao das arquitecturas de software

Os termos thin-client e fat-client sao utilizados quer para descrever arquitecturas

logicas (de software) quer para descrever arquitecturas fısicas (de hardware) Neste

capıtulo excepto quando seja dada indicacao em contrario estes termos referem-se

sempre a uma arquitectura logica

Adicionalmente quando se trata de arquitecturas cliente-servidor pode-se estu-

dar a arquitectura desenvolvida do sistema como um todo da arquitectura do servi-

dor ou da arquitectura do cliente Para evitar equıvocos em especial na seccao 213

especifica-se em cada caso qual o sistema estudado

211 Thin-clients

Um thin-client e um computador cliente ou software cliente que no contexto

de uma arquitectura cliente-servidor depende de um servidor central para as suas

5

Enquadramento do Projecto

actividades de processamento e proporciona um canal de entrada e saıda de in-

formacao entre o utilizador e o servidor remoto Este termo quando aplicado a

hardware refere-se habitualmente a um computador que se destina a ser utilizado

como cliente de rede sem armazenamento local e com capacidade de processamento

reduzida [Gro02b] mas o conceito que aqui se analisa refere-se a uma arquitectura

de software que remonta ao inıcio das aplicacoes cliente-servidor

No inıcio da historia da computacao terminais ligavam-se directamente a main-

frames responsaveis por todo o processamento Nesta arquitectura era necessario

desenvolver duas aplicacoes distintas uma aplicacao central no servidor (main-

frame) responsavel pela gestao de toda a informacao e por todas as operacoes de

comunicacao e uma aplicacao de visualizacao instalada no cliente (terminal) O

papel destes terminais era apenas disponibilizar ao utilizador um meio de comu-

nicacao (entrada e saıda) e apresentacao dos resultados do servidor Nao tinham

um papel activo no calculo nem na logica de negocio e frequentemente nao tinham

tambem nenhum mecanismo de armazenamento de dados

Como vantagens esta arquitectura apresenta uma reduzida necessidade de con-

figuracao e manutencao do lado do cliente Uma vez que o centro do processamento

e manipulacao de dados ocorre no servidor existe tambem uma centralizacao da

informacao [NJN00] que introduz um ponto crıtico de falha1 Actualizacoes e novas

funcionalidades sao faceis de distribuir uma vez que requerem apenas alteracoes no

servidor [Gro02a]

212 Fat-clients

Contrastando com os thin-clients nesta arquitectura os clientes implementam

ja uma parte da logica de negocio e sao responsaveis pelo processamento de dados

Estes fat-clients vieram responder a necessidade crescente de aplicacoes com um

nıvel de interactividade e capacidade de configuracao maior que as oferecidas pela

arquitectura thin-client descrita na seccao 211 Apesar de manterem a sua de-

pendencia do servidor podem tambem ser executados sem uma conexao activa uma

vez que dispoe de armazenamento de dados local o que lhes confere a capacidade

de persistencia de dados e do estado de execucao entre cada sessao

Foi disponibilizando este controlo sobre o estado da aplicacao bem como acesso

a recursos locais (por exemplo sistema de ficheiros e perifericos) que surgiram as

primeiras verdadeiras desktop applications No entanto cada cliente tinha que ser

separadamente instalado no computador pessoal de cada utilizador que pretendesse

utilizar ou interagir com a aplicacao e uma actualizacao ao servidor implicava in-

variavelmente uma actualizacao manual tambem no cliente Uma vez que nem todos

1NT single point of failure

6

Enquadramento do Projecto

Thin-clients Fat-clientsNao toma parte no processamento dedados nem possui acesso ao sistema deficheiros

Participa activamente no processa-mento de dados recorrendo ao sis-tema de armazenamento local para ar-mazenamento de dados

Nao mantem registo do estado logicoda aplicacao entre duas sessoes de uti-lizacao

O acesso ao armazenamento localpermite-lhe manter registo do estadologico da aplicacao entre duas sessoes

O thin-client nao necessita de qualquerinstalacao estando ldquopronto a utilizarrdquo

E geralmente necessario instalar aaplicacao para poder interagir com oservidor

Qualquer update no servidor reflecte-seimediatamente por todos os clientes

Embora a aplicacao cliente possa aler-tar para existencia de novas versoes asactualizacoes tem que ser manualmenteinstalados pelo cliente

O software do cliente destina-se apenasa apresentacao de dados e comunicacaocom o servidor sendo portanto de sim-ples implementacao

Como o software do cliente toma parteactiva no processamento de dadosa sua implementacao requer cuidadosadicionais

Grande mobilidade uma vez que todaa informacao e mantida no servidor

Parte da informacao podera estar ape-nas do lado cliente pelo que existemalgumas restricoes a sua mobilidade

Tabela 21 Comparacao entre thin-clients e fat-clients

os utilizadores actualizam regularmente as suas aplicacoes o servidor tem que estar

preparado para lidar com versoes antigas2 ou descontinuar os seus servicos a uma

parte da sua comunidade de utilizadores ate que estes actualizem os seus sistemas

Como os utilizadores passam a utilizar os seus recursos locais para armazenamento

de dados as alteracoes que nao sejam sincronizadas com o servidor estao apenas

disponıveis nos seus computadores pessoais o que introduz uma restricao a mobili-

dade

Pode-se afirmar que as vantagens dos thin-clients sao as desvantagens dos fat-

clients e que as vantagens dos fat-clients sao as vantagens dos thin-clients tal como

se ilustra na Tabela 21

213 Arquitecturas cliente-servidor

Introduzidos os termos thin-client e fat-client interessa reafirmar que ambos

podem ser vistos como arquitecturas cliente-servidor Um cliente define-se como

um solicitador de servicos e um servidor como um prestador de servicos tal como

definido por [Sch96] e [Sad97]

2NT backward compatibility

7

Enquadramento do Projecto

As arquitecturas cliente-servidor sao categorizadas pela modularizacao com que

sao desenhadas sendo consideradas as seguintes camadas

1 Interface grafica (front-end) atraves da qual os utilizadores interagem com

a aplicacao Quando este modulo e implementado separadamente dos outros

dois constitui uma aplicacao thin-client por si so uma vez que nao implementa

regras de negocio (embora possa definir validacoes de formularios de insercao de

dados por exemplo) A informacao introduzida pelo utilizador e enviada para

o servidor que processa o seu pedido e retorna uma resposta Este processo

repete-se ate que o utilizador atinja o seu objectivo ou se desligue do sistema

2 A logica de negocio tambem designada por camada intermedia que imple-

menta as regras de aceitacao e validacao de todos os dados introduzidos pelo

utilizador E tambem a plataforma de comunicacao que une a camada superior

de visualizacao com a camada de acesso a dados

3 A camada de dados inclui quer o sistema de persistencia de dados onde sao

armazenados os dados relevantes como tambem os mecanismos necessarios

para a sua pesquisa seleccao e alteracao

Os thin-clients quando observados no seu conjunto de cliente e servidor podem

ser vistos quer como sistemas de duas camadas quer como sistemas de tres camadas

dependendo apenas da forma como o servidor for implementado No caso de na

implementacao do servidor nao se distinguir a camada de acesso a dados da camada

da logica de negocio sao designados por sistemas de duas camadas Caso seja feita

esta distincao sao designados por sistemas de tres camadas Ambos os casos sao

ilustrados na Figura 21

Historicamente os fat-clients eram implementados numa arquitectura em duas

camadas Possuıam apenas um modulo de visualizacao de dados designado por

camada de interface e um modulo que implementava toda a logica de negocio e

regras de acesso a base de dados No entanto com a introducao de ligacoes mais

rapidas e de computadores pessoais com maior capacidade de processamento e so-

bretudo devido a complexidade crescente das aplicacoes a logica de negocio e a

camada de acesso a dados tornaram-se independentes Este modelo e designado por

arquitectura em tres camadas e e ilustrado na Figura 22

22 Evolucao na Internet

Ao analisar a evolucao das arquitecturas das aplicacoes desenvolvidas para a

Internet podemos encontrar um paralelismo com a historia da arquitectura de soft-

ware

8

Enquadramento do Projecto

Figura 21 Arquitectura de um sistema thin-client em duas camadas (a esquerda) e emtres camadas (a direita) Note-se a inclusao do servidor (mainframe) na definicao dascamadas desta arquitectura devido a forte dependencia cliente-servidor

221 Paginas web estaticas

Uma pagina web estatica devolve sempre a mesma resposta a todos os pedidos

para todos os utilizadores e em qualquer contexto utilizando o hipertexto como

forma de ligacao entre diversas paginas estaticas

A informacao e armazenada num servidor e o papel do cliente e apenas a apre-

sentacao da informacao Esta forma de disponibilizacao de informacao pode assim

ser comparada com os thin-clients descritos na seccao 211 o utilizador acede a

um website estatico para visualizar informacao sem que o cliente tome parte no

processamento A unica diferenca e que no caso da web estatica a informacao ap-

resentada e sempre a mesma enquanto que nos thin-clients era frequente existir a

possibilidade de insercao de dados no cliente e apos o seu processamento servidor

nova informacao poderia ser apresentada O hipertexto e utilizado para ligar as

paginas entre si numa rede de conteudos relacionados e a navegacao sıncrona era

feita atraves de cliques do rato a cada clique uma nova pagina era apresentada

Este modelo sıncrono e ilustrado na Figura 23

222 Paginas web interactivas e paginas web dinamicas

O JavaScript e uma linguagem interpretada de scripting que tem os browsers

como principal ambiente de acolhimento Os browsers utilizam uma Application

9

Enquadramento do Projecto

Figura 22 Arquitectura de um fat-client em duas camadas (a esquerda) e em tres camadas(a direita)

Programming Interface (API) publica para criar ldquoobjectosrdquo responsaveis por reflectir

e disponibilizar o Document Object Model (DOM) para o motor de JavaScript

A utilizacao mais frequente desta linguagem e a escrita de funcoes que sao em-

bebidas ou incluıdas em paginas web e que interagem com o DOM Uma vez que o

JavaScript e executado localmente (na maquina do cliente e nao no servidor) e capaz

de responder rapidamente a accoes do utilizador tornando a execucao de aplicacoes

no browser mais fluıdas o JavaScript pode tambem detectar accoes do utilizador

que o HTML nao pode tal como o pressionar de uma tecla

Em Dezembro de 1995 a Netscape Communications adicionou suporte para o

JavaScript no browser Netscape Navigator3 e em Agosto de 1996 o browser Internet

Explorer4 da Microsoft passou a tambem a suportar uma versao semelhante desta

linguagem (hoje todos os principais browsers suportam esta tecnologia)

Esta inovacao permitiu tornar os websites mais interactivos mas a sua utilizacao

esteve confinada apenas a este proposito durante um longo perıodo As paginas

passaram a responder activamente a accoes do utilizador (sendo uma das utilizacoes

3Netscape Communications ndash httpbrowsernetscapecom4Microsoft Internet Explorer ndash httpwwwmicrosoftcomwindowsproductswinfamilyie

10

Enquadramento do Projecto

mais vulgares a validacao de formularios) mas continuaram essencialmente estaticas

O JavaScript ainda nao era nesta altura utilizado para processar dados

Tambem nesta altura (1995ndash96) surgiram linguagens server-side como o PHP

Hypertext Preprocessor (PHP) e Active Server Pages (ASP) e o servidor passou a ter

um processamento de dados introduzidos pelo utilizador mais activo Generalizaram-

se as paginas dinamicas capazes de responder a insercao de dados ou outros pedidos

determinados por accoes do utilizador As paginas tornaram-se aplicacoes web ap-

plications

Uma definicao tradicional de web application e um conjunto de paginas web

logicamente agrupadas e geridas por uma unica entidade que tem como pontos de

entrada formularios de insercao de dados (web forms) Uma web application nao e

mais do que uma aplicacao que e acedida atraves de um browser Tem geralmente

uma arquitectura logica em tres (interface logica de negocio e camada de dados)

camadas e estao armazenadas num servidor

Ha dois tipos de web applications

bull Orientadas a apresentacao Sao web applications que geram paginas web in-

teractivas constituıdas por varios tipos de linguagens de anotacao (por exem-

plo HTML eXtensible Markup Language (XML)) e que apresentam conteudo

dinamico como resposta a pedidos efectuados pelo utilizador

bull Orientadas aos servicos Uma web application orientada aos servicos imple-

menta o ponto de acesso para um ou mais de um web service Sao geralmente

clientes de service oriented web applications

Uma vantagem significativa de implementar uma web application de forma a

suportar as funcionalidades padrao dos browsers e que estas terao o mesmo com-

portamento independentemente da plataforma e do browser a partir do qual serao

acedidas No entanto diferentes implementacoes de browsers devido a diferentes

interpretacoes dos padroes definidos tornam por vezes esta tarefa um pouco mais

complicada existindo inclusivamente na web guioes de compatibilidade para os difer-

entes browsers como [Smi07]

223 Web 20 e Ajax

O termo web 20 descreve uma tendencia de utilizacao e de design observada

na World Wide Web (WWW) com o objectivo de melhorar a criatividade partilha

de informacao e principalmente a colaboracao entre utilizadores Estes conceitos

levaram ao desenvolvimento e evolucao de comunidades online tais como redes so-

ciais wikis e blogues

11

Enquadramento do Projecto

O termo tornou-se mais conhecido apos a primeira conferencia OrsquoReilly Media

Web 20 em 2004 e apesar de sugerir uma nova versao da WWW nao se refere a

qualquer evolucao tecnologica mas apenas a alteracoes a forma como os utilizadores

se servem da web De acordo com Tim OrsquoReilly [OrsquoR06] ldquoWeb 20 e uma revolucao

na industria do software causada pela adopcao da web como uma plataforma e pela

tentativa de entendimento das regras para o sucesso nesta nova plataformardquo

O desenvolvimento da Web 20 serve-se muitas vezes de um outro conceito Ajax

O conceito que hoje conhecemos como Ajax muitas vezes incorrectamente de-

scrito como uma tecnologia foi originalmente criado para permitir o desenvolvimento

de web applications que se assemelhassem ainda mais a aplicacoes de desktop Este

conceito foi melhor descrito por [Gar05] como um conjunto de varias tecnologias

que podem ser utilizadas para melhorar a experiencia do utilizador de uma dada

web application introduzindo a capacidade assıncrona de envio de pedidos ou da

recepcao assıncrona de respostas As tecnologias mais frequentemente envolvidas

sao

bull eXtensible HyperText Markup Language (XHTML) e Cascading Style Sheets

(CSS) padrao para a apresentacao

bull interaccao dinamica atraves do DOM

bull troca e manipulacao de dados utilizando XML e eXtensible Stylesheet Lan-

guage Transformation (XSLT) ou JavaScript Object Notation (JSON)

bull pedidos assıncronos utilizando XMLHttpRequest [vK08]

bull JavaScript utilizado para integrar todas estas tecnologias

E importante frisar que o Ajax nao e um produto nem uma tecnologia E um

termo que descreve a utilizacao de um conjunto de tecnologias para o desenvolvi-

mento de web applications com um elevado grau de interactividade Comparativa-

mente as web applications tradicionais o Ajax introduz uma camada de visualizacao

diferente em tres importantes pontos

1 Do lado do cliente existe um motor que serve de intermediario entre a interface

da aplicacao e o servidor

2 A actividade do utilizador despoleta chamadas JavaScript em vez de um pedido

de pagina directamente ao servidor

3 Informacao codificada em XML em vez de paginas HTML e trocada entre o

servidor e o cliente

12

Enquadramento do Projecto

Isto significa que as paginas que utilizam Ajax contem um motor do lado do

cliente composto por um conjunto de funcoes JavaScript responsavel pela comu-

nicacao com o servidor e por actualizar a interface com o resultado dessa mesma

comunicacao

Na Figura 23 ilustra-se a natureza assıncrona do Ajax quando comparada com

as web applications tradicionais Como se pode observar adicionando um mecan-

ismo Ajax a uma web application eliminam-se diversos tempos de espera associados

a comunicacoes com o servidor uma vez que a interface nao fica ldquobloqueadardquo a es-

pera da resposta Obtem-se assim aplicacoes com um comportamento mais fluido

eliminando tempos de espera entre cada ldquocliquerdquo e melhorando a experiencia do

utilizador

23 Offline Web Applications

A informacao grafica (bem como folhas de estilo e scripts) tais como as ima-

gens que constituem o visual de uma web application e ja tratada de forma especial

pelos cada vez mais avancados sistemas de cache (armazenamento temporario) dos

browsers Mas estes nao sao ainda capazes de guardar conteudo criado pelo uti-

lizador nem de apresentar informacao independentemente do estado da ligacao

Numa altura onde se fala de servicos de Internet wireless municipalizados [Kha]

comunicacoes 3G e ligacoes de banda larga a alta velocidade a ligacao a rede global

continua a nao estar permanentemente disponıvel para os utilizadores Na WWW

encontra-se uma importante parte da informacao e das aplicacoes utilizadas para

criar e editar conteudos Por vezes informacao vital para a produtividade pode

desaparecer subitamente do mapa de acesso de um utilizador quando este entra no

metro num aviao ou mesmo quando se desloca para uma cidade ou paıs diferente

do habitual onde nao subscreve um plano de acesso que lhe garanta a ligacao

Permitir o acesso offline a estes recursos assume assim a sua importancia porque

permitira estender o alcance da informacao a locais onde nunca esteve antes e per-

mitira tambem melhorar o desempenho das web applications colocando informacao

mais perto dos utilizadores reduzindo a transferencia de dados apenas ao essencial

24 Comparacao

Nas evolucoes descritas neste capıtulo 2 pode-se observar que existe um par-

alelismo entre a evolucao das arquitecturas tradicionais cliente-servidor e a evolucao

a que se assiste na web O comportamento e arquitectura dos thin-clients assemelha-

se ao das paginas estaticas no sentido em que o browser nao toma parte em qualquer

13

Enquadramento do Projecto

processamento e serve apenas como uma plataforma de interaccao com o servidor

tal como os clientes descritos na seccao 211

A sua proxima evolucao os fat-clients trouxeram parte da capacidade de pro-

cessamento para o lado do cliente Na web foi tambem esta a inovacao tecnologica

a que se assistiu com a evolucao das tecnologias que permitiram a criacao de ver-

dadeiras aplicacoes e com a introducao do Javascript no browser dando ao cliente

a capacidade de processamento de dados A necessidade da separacao do codigo

em camadas logicas advem da crescente complexidade das web applications Esta

pratica permite entre outras coisas melhorar o processo de desenvolvimento e a

capacidade de manutencao de uma aplicacao

Os fat-clients tem tambem a capacidade de armazenamento de dados o que

permite a persistencia de informacoes entre duas sessoes e que algumas operacoes

sejam executadas sem a necessidade de comunicacao com o servidor Este facto pode

tambem ser uma realidade nas web applications com a adopcao das tecnologias OWA

Neste momento assiste-se a uma utilizacao cada vez maior da web como uma

plataforma de desenvolvimento A capacidade de cooperacao na edicao de conteudos

e a mobilidade proporcionada por esta plataforma sao os principais factores que

alimentam esta mudanca e pela primeira vez as aplicacoes tradicionais tem com-

peticao vinda de web applications A prova do reconhecimento da web como plataforma

de desenvolvimento pode ser retirada da aposta de empresas como a Adobe e Mi-

crosoft que lancaram publicamente ferramentas web complementares a produtos

seus tradicionalmente associados ao desktop ndash Acrobatcom5 e Microsoft Office

Live6 Dotar estas web applications da capacidade de execucao offline significa

aproximar a web e o desktop reunindo ldquoo melhor de dois mundosrdquo

As vantagens da mobilidade possıvel atraves da web a cooperacao na criacao e

edicao de conteudos e a possibilidade de utilizar aplicacoes sempre actualizadas e

sem necessidade de instalacao sao algumas das principais vantagens que promovem

esta mudanca que devido as preocupacoes associadas a usabilidade e experiencia do

utilizador esta fortemente associada ao desenvolvimento de Rich Internet Applica-

tion (RIA)s

5Adobe Acrobatcom httpwwwacrobatcom6Microsoft ndash httpsmallbusinessofficelivecom

14

Enquadramento do Projecto

Figura 23 Comparacao do modelo de web aplications sıncrono paginas estaticas e in-teractivas abordados nas seccoes 221 e 222 com o modelo de web applications Ajax(assıncrono) abordado na seccao 223 Figura adaptada de http www adaptivepath

com

15

Enquadramento do Projecto

16

Capıtulo 3

Estado da arte

Apesar de o conceito das OWAs nao ser absolutamente novo as tecnologias que

o suportam sao recentes Neste capıtulo descrevem-se quatro tecnologias que foram

tidas como principais candidatas para o desenvolvimento deste projecto Descrevem-

se ainda alguns exemplos de web applications que disponibilizam actualmente fun-

cionalidades offline e o processo da escolha da tecnologia a utilizar neste projecto

31 Gears

O Gears1 e uma extensao as funcionalidades do browser introduzido pelo Google

que tem como principal objectivo tornar possıvel a visualizacao de paginas de Inter-

net mesmo sem uma conexao disponıvel Encontra-se disponıvel para as platafor-

mas Windows Macintosh e Linux e oferece uma API de Javascript que permite

a scripts aceder a um mecanismo de armazenamento local baseado numa base de

dados SQLite

311 Arquitectura

Esta ferramenta e constituıda por tres componentes principais

bull LocalServer mdash Intercepta pedidos de paginas web e serve-as localmente

bull Database mdash Uma base de dados relacional construıda sobre SQLite

bull WorkerPool mdash Permite executar operacoes de computacao de uma forma

assıncrona sem afectar a capacidade de resposta e fluidez de execucao da web

application Assemelham-se a processos

1Google Inc ndash Mais informacao em httpgearsgooglecom

17

Estado da arte

LocalServer

O modulo LocalServer e uma cache de Uniform Resource Locators (URLs)

controlada pela web application Quando nao existe uma ligacao a Internet e e

feito um pedido para um URL presente nesta cache o LocalServer intercepta-o e

responde ao pedido localmente a partir do disco rıgido do utilizador A aplicacao

pode utilizar dois tipos diferentes de armazenamento local de URLs

bull ResourceStore ndash serve para capturar URLs utilizando exclusivamente a API

de Javascript disponibilizada para o efeito Uma aplicacao podera criar e

utilizar diversos ResourceStores simultaneamente para capturar ficheiros de

dados que necessitam de ser enderecados por um URL tal como um ficheiro

PDF ou uma imagem

bull ManagedResourceStore ndash serve para capturar um conjunto de URLs que estao

relacionados e que sao declarado num ficheiro de manifesto (especificado em

JSON) e que sao automaticamente actualizados O ManagedResourceStore

permite que o conjunto de recursos necessarios para correr uma web application

seja capturado e mantido actualizado automaticamente

A principal diferenca entre estes dois tipos de armazenamento de URLs e a forma

como sao actualizados os seus conteudos Os conteudos de um ManagedResourceStore

sao actualizados sempre que a versao contida no ficheiro de manifesto for alterada

enquanto que os conteudos de um ResourceStore nunca sao actualizados automati-

camente mas apenas quando for explicitamente ordenado pela aplicacao

O LocalServer e capaz de interceptar e servir localmente pedidos de HTTP e

HTTPS sempre que se reunam as seguintes condicoes

1 O URL encontra-se armazenado num ResourceStore ou ManagedResourceStore

2 O sistema de armazenamento local encontra-se activo (enabled = true) Se

o sistema de armazenamento local tiver o atributo requiredCookie o pedido

devera conter um cookie que lhe corresponda

O LocalServer nao necessita de monitorizar o estado da ligacao para atender aos

pedidos Na verdade sempre que as condicoes previamente enunciadas se verificarem

o LocalServer interceptara os pedidos e independentemente do estado da ligacao

a Internet servi-los-a a partir do disco rıgido local Cabera a aplicacao definir qual

o modo em que pretende executar um pedido (online ou offline) definindo o valor

de verdade da propriedade enabled

18

Estado da arte

Database

O modulo Database permite guardar dados da web application assegurando a

sua persistencia Os dados sao guardados de forma relacional no disco rıgido do uti-

lizador2 de acordo com o modelo de seguranca estabelecido pelo Gears3 significando

que uma aplicacao nao pode aceder a conteudos fora do seu domınio

WorkerPool

Nos web browsers uma operacao pesada de computacao pode tornar a interface

lenta e tornar menos agradavel a experiencia do utilizador O modulo WorkerPool

permite correr operacoes em background sem bloquear a interface com o utilizador

Os scripts executados numa WorkerPool nao activam os mecanismos de seguranca

do browser que mostram a mensagem ldquoA script on this page may be busy or may

have stopped respondingrdquo

O WorkerPool comporta-se como um conjunto de processos em vez de threads

Os Workers nao partilham qualquer estado de execucao o que significa que uma

alteracao a uma variavel num Worker nao afecta em nada a execucao de outro

Worker Alem disso os Workers nao herdam automaticamente nenhum codigo dos

seus pais Cada Worker e membro de um WorkerPool e os Workers podem in-

teragir entre si enviando mensagens em formato de texto ou JSON No entanto ha

tambem algumas limitacoes os Workers nao tem acesso ao DOM e objectos como

window ou document nao se encontram acessıveis Isto e consequencia de os Workers

nao partilharem o estado de execucao Mas tem acesso a todas as funcoes built-in

do Javascript A maioria das funcionalidades do Gears pode tambem ser acedida

atraves de uma variavel global especial definida como googlegearsfactory Para

outras funcionalidades especıficas os Workers podem ldquopedirrdquo a pagina principal para

continuar a execucao atraves do envio de mensagens

Outras funcionalidades

bull HttpRequest ndash Este modulo implementa a especificacao W3C XmlHttpRe-

quest definida em [vK08] tornando-a disponıvel para os workers e para a

pagina principal

bull Timer ndash Este modulo implementa a especificacao de timers tal como descrito

por [Hic08] e torna-os disponıveis para os workers e para a pagina principal

2Consultar httpcodegooglecomapisgearsapi_databasehtmldirectories3Consultar httpcodegooglecomapisgearssecurityhtml

19

Estado da arte

bull Factory ndash Esta classe e utilizada para instanciar todos os outros objectos da

API do Gears atraves do seu metodo create Este metodo pode ser utilizado

com os seguintes parametros

ndash betadatabase

ndash betahttprequest

ndash betalocalserver

ndash betatimer

ndash betaworkerpool

312 Goggle Gears em dispositivos moveis

O Gears esta tambem disponıvel em dispositivos Windows Mobile 5 e 6

Os dispositivos moveis estao pela sua natureza frequentemente desconectados

da Internet Mesmo quando possuem uma ligacao as latencias na transferencia de

dados em redes moveis tornam as aplicacoes pouco fluıdas mas o Gears permite

ultrapassar este obstaculo

O Gears funciona exactamente da mesma forma em dispositivos moveis equipados

com o Windows Mobile 5 e 6 como num computador comum Se uma aplicacao tiver

sido implementado com suporte para o Gears entao tambem estara preparada para

ser executada num dispositivo movel mas as limitacoes dos browsers disponıveis

para dispositivos moveis tem que ser consideradas Isto significa prever as condicoes

que permitam uma boa usabilidade devido aos pequenos ecras destes dispositivos

bem como o seu suporte limitado dos padroes do DOM CSS e JavaScript

32 Adobe AIR

O Adobe AIR4 e um runtime compatıvel com diversos browsers e sistemas opera-

tivos que pretende dar aos programadores a possibilidade de combinar diversas tec-

nologias de producao de conteudos para a Internet no desenvolvimento de Rich Inter-

net Application (RIA)s O Adobe AIR mantem uma relacao com o browser mas es-

tende as suas capacidades e tecnologias permitindo o desenvolvimento de aplicacoes

tambem para o ambiente de trabalho com janelas em tudo semelhantes as do sis-

tema operativo Segundo a Adobe o objectivo e complementar o browser dando

aos utilizadores (mas essencialmente aos programadores e equipas de desenvolvi-

mento) a escolha sobre como distribuir as suas aplicacoes Para este efeito o Adobe

AIR tem uma aproximacao diferente do Gears Em vez de ldquoestenderrdquo o browser

acrescentando-lhe funcionalidades o AIR permite tambem o desenvolvimento de

4Adobe - httpwwwadobecomproductsair

20

Estado da arte

aplicacoes que se destinam a ser executadas fora do ambiente do browser mas uti-

lizando as tecnologias comuns da Internet (por exemplo HTML CSS JavaScript

Flash Flex)[CDGH08]

A utilizacao desta tecnologia permite utilizar o browser ou o proprio runtime

Adobe AIR como plataforma de execucao da aplicacao

Na Tabela 31 faz-se uma comparacao das funcionalidades disponıveis de acordo

consoante se escolha o browser ou o desktop como plataforma base para a aplicacao

Uma vez que as aplicacoes Adobe AIR na plataforma desktop tem um caracter

persistente (sao instaladas no computador do utilizador) o Adobe AIR tem um

modelo de seguranca que se assemelha com o das tradicionais aplicacoes desktop

[Ada08] Este modelo e analisado nas seccoes 321 e 322 O ambiente em que

e executado o browser e restringido a execucao de web applications que podem

ser de varias origens (incluindo de origens anonimas ou sem confianca) O Adobe

AIR proporciona acesso a capacidades como acesso a ficheiros que necessitam da

confianca do utilizador

bull HTML ndash O desenvolvimento de aplicacoes para o Adobe AIR pode ser feito

com recurso a tecnologias de HTML e Ajax comuns utilizando as linguagens

de markup existentes distribuıdas como texto e interpretadas em execucao

(runtime)

bull Flash ndash Outra alternativa sera a utilizacao da linguagem Flash Permite a

renderizacao de graficos vectoriais e audiovıdeo com suporte nativo Utiliza

ActionScript para adicionar maior interactividade com o utilizador

bull Flex ndash O Flex e uma framework open source para o desenvolvimento de RIAs

usando Flash As aplicacoes Flex sao na realidade Flash sendo a principal

diferenca o ambiente de desenvolvimento

Como resultado uma aplicacao AIR podera ser implementada

bull Baseada em Flash ou Flex (aplicacoes cujo conteudo base e em ShockWave

Flash (SWF))

bull Baseada em Flash ou Flex tambem com HTML ou Portable Document Format

(PDF) Aplicacoes cujo conteudo de base e em FlashFlex (SWF) com HTML

(HTML JavaScript CSS) ou conteudo PDF incluıdo

bull Baseada em HTML Aplicacoes cujo conteudo base e em HTML Javascript

CSS

bull Baseada em HTML utilizando tambem FlashFlex ou PDF

21

Estado da arte

Os utilizadores interagem com uma aplicacao AIR da mesma forma que interagem

com outras aplicacoes com janelas nativas do seu sistema operativo O runtime e

instalado uma vez no computador do utilizador e a partir desse momento todas as

aplicacoes AIR terao o mesmo aspecto que qualquer outra aplicacao para o desktop

321 Seguranca

Permitir que uma web application aceda ao disco de armazenamento do utilizador

pode comprometer seriamente a sua seguranca Neste sentido o Adobe AIR tem

suporte para assinaturas digitais (Secure Sockets Layer (SSL)) que podem ser com-

pradas pelas equipas de desenvolvimento que o desejem e cujos certificados serao

apresentados ao utilizador no momento da instalacao Um outro aspecto ainda

relativo a seguranca e o mecanismo de isolamento de cada ambiente (sandbox )

322 Assinatura do codigo

O runtime AIR exige que todas as aplicacoes estejam digitalmente assinadas As

assinaturas digitais de codigo sao um processo que visa garantir a integridade da

aplicacao e a identidade do seu autor no momento da instalacao As equipas de

desenvolvimento podem ldquoassinarrdquo uma aplicacao utilizando um certificado atribuıdo

por uma Entidade Certificadora (Certification Authority) ou atraves de um certifi-

cado individual (self signed certificate) Neste momento o Adobe AIR suporta como

entidades certificadoras a Verisign e a Thawte [Ado08]

O instalador apresenta o nome de quem publica a aplicacao quando o codigo tiver

sido assinado com um certificado que apresente confianca ou que esteja encadeado

com um certificado que tenha ja sido aceite no computador em que se esta a instalar

a aplicacao

As equipas de desenvolvimento podem tambem assinar as aplicacoes com um

certificado auto-atribuıdo (um certificado criado por elas proprias) mas neste caso

o instalador apresentara estas aplicacoes como sendo de uma origem nao verificada

O AIR utiliza a infraestrutura publica de chaves [Ent07] suportada pelo arquivo

local do sistema operativo Para que a origem da aplicacao seja reconhecida o

computador onde a aplicacao AIR esta a ser instalada tem que confiar directamente

no certificado que foi utilizado para assinar a aplicacao ou confiar num certificado

que esteja num encadeamento logico de certificados confiados e que se ligue desta

forma ao certificado utilizado para assinar a aplicacao

Todas as aplicacoes AIR tem caracterısticas em comum independentemente da

tecnologia utilizada para o seu desenvolvimento (HTMLFlexFlash) No ambito

de uma aplicacao AIR existem um conjunto de APIs que estao disponıveis e que

tornam possıvel o acesso ao sistema local (leitura e escrita) e a recursos de rede que

22

Estado da arte

de outra forma nunca estariam acessıveis a partir de uma web application comum

Cada aplicacao AIR possui tambem diferentes nıveis de isolamento chamados secu-

rity sandboxes dependendo do tipo de conteudo que esta a ser carregado e do seu

objectivo

bull Isolamento ao nıvel da aplicacao5 ndash E a raiz de cada aplicacao AIR Este

nıvel de isolamento permite o acesso a APIs privilegiadas e especıficas do

AIR Em contrapartida e negado o acesso a algumas APIs que poderiam ser

facilmente utilizadas de forma maliciosa contra o utilizador final Importacao

dinamica de conteudos remotos e geralmente proibido e as tecnicas e mecan-

ismos de geracao dinamica de codigo sao fortemente restringidas Apenas

conteudo carregado directamente da directoria base da aplicacao podera ser

colocado neste nıvel de isolamento

bull Isolamento nao especıfico da aplicacao6 ndash contem todo o outro conteudo

que nao tenha sido carregado directamente para o isolamento da aplicacao

Isto inclui conteudo local e remoto Este tipo de conteudo nao tem acesso

directo as APIs do AIR e rege-se pelas mesmas regras tal como se tivesse sido

carregado por um browser a partir da mesma localizacao (por exemplo HTML

carregado a partir de um domınio remoto comporta-se da mesma forma que se

fosse acedido a partir do browser)

33 Mozilla Prism

331 XML User Interface Language

O eXtensible User Interface Language (XUL) e uma linguagem de anotacao

baseada em XML desenvolvida pela Mozilla Foundation que opera em aplicacoes

Mozilla multi plataforma tal como o Firefox O motor Gecko e a unica imple-

mentacao completa desta linguagem que foi desenhada sobre padroes web comuns

como CSS JavaScript e o DOM e permite o desenvolvimento de interfaces graficas

utilizando elementos pre-definidos tais como window box page textbox radio

button entre outros Infelizmente o XUL nao possui qualquer especificacao formal

ou implementacoes de inter-operabilidade para outros motores que nao o Gecko No

entanto a sua implementacao e licenciada em codigo aberto pelas licencas GNU Gen-

eral Public License (GPL) GNU Lesser General Public License (LGPL) e Mozilla

Public License (MPL)

Enunciam-se algumas caracterısticas desta linguagem

5NT application sandbox6NT non-application sandbox

23

Estado da arte

Liguagem de anotacao poderosa baseada em componentes (widgets) O ob-

jectivo do XUL e permitir a construcao de aplicacoes multi-plataforma em

claro contraste com o Dynamic HyperText Transfer Protocol (DHTML) que se

destina ao desenvolvimento de paginas web Por esta razao o XUL esta orien-

tado a componentes tais como janelas botoes e etiquetas em vez de paginas

cabecalhos de texto e ligacoes de hipertexto Investir tempo e esforco para

atingir este mesmo resultado em aplicacoes baseadas em DHTML compromete

frequentemente a complexidade e desempenho da aplicacao

Baseado em padroes O XUL e um dialecto XML baseado no padrao W3C XML

10 As aplicacoes escritas em XUL sao tambem baseadas em especificacoes

W3C adicionais como HTML 40 CSS DOM nıvel 1 e 2 JavaScript 15

incluindo ECMA-262 Edition 3 (ECMAscript)

Portabilidade entre plataformas Tal como HTML o XUL foi desenhado para

ser independente da plataforma em que e utilizado tornando as aplicacoes

facilmente portaveis entre sistemas operativos nos quais o Mozilla e suportado

Uma vez que o XUL oferece um nıvel de abstraccao dos componentes graficos

de interface que disponibiliza implementa a premissa ldquoum codigo para todas

as plataformasrdquo A interface grafica de todos os produtos centrais Mozilla

(browser instant messenger livro de enderecos) e escrita em XUL com um

unico codigo base que suporta todas as plataformas Mozilla

Separacao entre o nıvel de apresentacao e a logica de negocio Uma das

maiores preocupacoes no desenvolvimento para a Internet e a forte ligacao

entre estas duas camadas (interface e logica) Isto constitui um problema sig-

nificativo no desenvolvimento de grandes aplicacoes especialmente quando o

desenvolvimento e feito em ambientes de equipa porque as capacidades de de-

senvolvimento destas duas partes da aplicacao estao muitas vezes espalhadas

por diferentes elementos O XUL permite uma clara distincao entre a definicao

da aplicacao cliente e da logica de implementacao (XUL eXtensible Binding

Language (XBL) e JavaScript) apresentacao (CSS e imagens) internacional-

izacao (Document Type Definitions (DTDs) e etiquetas de texto em lınguas

especıficas guardados em ficheiros properties) O esquema grafico e apre-

sentacao de uma aplicacao XUL pode ser alterado de forma independente da

sua logica ou implementacao e a aplicacao pode ainda ser traduzida (interna-

tionalization) de forma independente da sua logica implementacao ou apre-

sentacao Este grau de separacao resulta em aplicacoes que sao mais faceis de

manter pelos programadores e facilmente adaptadas por designers e tradutores

24

Estado da arte

Facil adaptacao Outro benefıcio que advem do nıvel de separacao entre logica

de negocio e apresentacao oferecido pelo XUL e a facilidade com que se pode

adaptar uma aplicacao para diferentes clientes ou grupos de utilizadores Um

programador pode utilizar a mesma aplicacao base e adapta-la consoante as

necessidades atraves de diferentes temas (skins) e ficheiros de lınguas Desta

forma uma aplicacao escrita e desenvolvida em Ingles pode ser rapidamente

traduzida para Portugues e distribuıda com outra aparencia mais apropriada

ao cliente alvo

332 Prism

O Mozilla Prism e um browser simplificado e ldquointerpretadorrdquo de XUL (tambem

designado por XULRunner) que acolhe web applications sem a interface grafica ha-

bitual de um browser Baseia-se num conceito designado por Site Specific Browser

(SSB) Um SSB e uma aplicacao com um browser embebido desenhado para exe-

cutar apenas uma web application Nao possui os menus e barras de ferramentas

habituais Um SSB tem uma integracao com o sistema operativo e com o desktop

muito mais estreita do que uma web application acedida atraves de um browser uma

vez que e executado em janela propria

O Prism resulta de uma experiencia da Mozilla e visa reduzir as diferencas entre

as desktop applications tradicionais e as web applications Um dos aspectos focados e

a experiencia do utilizador Numa apresentacao oficial e dito que ldquo[o Prism] pretende

ser uma ponte entre as diferencas que existem entre as aplicacoes tradicionais de

desktop e as web applications explorando novos modelos de usabilidade enquanto

que a linha que as separa se continua a definirrdquo [Lab07]

34 HTML 5

A especificacao HTML 5 [Hic08] que se encontra em fase de desenvolvimento

pelo grupo WHATWG pretende ser uma norma de substituicao dos padroes HTML

4 XHTML 1x e do DOM2 HTML Uma das propriedades que o distingue das tec-

nologias que pretende substituir e precisamente o suporte para OWA e armazena-

mento de dados no cliente de uma forma relacional Nao sendo propriamente uma

tecnologia ndashmas antes uma especificacao ndashe aqui mencionada por ter servido como

referencia a diversas implementacoes de funcionalidades offline e por se considerar

que venha a ter um impacto significativo nas implementacoes de diversos browsers

Dion Almaer defendeu no seu blogue que o Gears era uma implementacao do

HTML 5 No seu artigo ldquoGears as a bleeding-edge HTML 5 implementationrdquo [Alm08]

o autor diz que ambos ndasho Gears e o HTML 5 ndashpretendem dar a web caracterısticas

25

Estado da arte

semelhantes e nao encontrar motivo de ldquocompeticaordquo entre as duas mas que en-

quanto o HTML 5 e uma especificacao o Gears e uma implementacao

No entanto tambem e verdade que o HTML 5 cobre muitos outros pontos para

alem das OWA que saem completamente fora do ambito do Gears Se esta es-

pecificacao atingir um estado de maturidade que possibilite a sua adopcao pelos

principais browsers tornando nativo do browser o suporte OWA entao deixara de

fazer sentido a existencia de uma extensao como o Gears

A especificacao HTML 5 disponibiliza duas APIs relevantes para o tema das

OWA

1 Uma base de dados baseada em SQL que permite o armazenamento de dados

do lado do cliente

2 Uma ldquocacherdquo HTTP que garante a disponibilidade das aplicacoes mesmo quando

o utilizador nao possui uma ligacao a Internet

Estas caracterısticas sao as bases da tecnologia das OWA e tem correspondencia

com os pontos analisados nas seccoes 311 e 311

35 Web applications que usam funcionalidades offline

Nesta seccao apresentam-se algumas web applications que actualmente disponi-

bilizam funcionalidades offline Estas aplicacoes foram escolhidas para uma analise

mais pormenorizada por utilizarem o Gears que tal como descrito na seccao 4 foi

a tecnologia escolhida para o projecto

351 Google Reader e Google Docs

O Google Reader7 e um leitor de feeds RSS Permite gerir a subscricao de varios

sites simultaneamente que disponibilizem conteudos neste formato e foi a primeira

web application da Google com uma versao offline publicamente acessıvel (desde

Junho de 2007)

O Google Reader implementa o modo ldquoutilizador deciderdquo oferecendo na sua

interface um botao que permite alternar entre os modos online e offline

O Google Docs8 e uma web application que permite a criacao e edicao de doc-

umentos de texto folhas de calculo e apresentacoes Era ja publico desde Janeiro

de 2008 que o Google estava a desenvolver uma versao OWA desta aplicacao mas o

acesso a uma versao experimental so foi possıvel a partir de 31 de Maio de 2008

7Google Reader - httpreadergooglecom8Google Docs - httpdocsgooglecom

26

Estado da arte

A implementacao das funcionalidades offline nestas duas aplicacoes seguiu difer-

entes aproximacoes principalmente porque o Google Reader apresenta ao utilizador

informacoes que sao fornecidas por fontes externas enquanto que no Google Docs

a informacao e criada e editada pelo utilizador sobre a forma de documentos

A diferente origem da informacao implica que no Google Reader seja necessario

prever casos de excepcao tal como existirem demasiados itens que necessitam de

ser transferidos para o cliente Nao observar este ponto causa um problema grave

de usabilidade e para evitar tempos de espera demasiado longos e uma interface

com pouca capacidade de resposta as accoes do utilizador o Google Reader apenas

transfere para o cliente os dois mil itens mais recentes na transicao para o modo

offline

352 Remember the Milk

O Remember The Milk9 e uma web application desenvolvida por uma equipa

Australiana que proporciona funcionalidades de agenda gestao de tempo e de tare-

fas e foi uma das primeiras aplicacoes independentes do Google a adoptar o Gears

para acessos em modo offline Permite que os seus utilizadores facam uma gestao

de tarefas agrupando-as em listas adicionando-lhes campos de informacao adicional

ou dando-lhes informacao geografica (recorrendo ao servico Google Maps10) Entre

a sua lista de funcionalidades encontra-se ainda a possibilidade de importar e ex-

portar eventos no formato iCalendar (ics) etiquetas (tags) em tarefas publicacao

Really Simple Syndication (RSS) e partilha de categorias de tarefas de acordo com

diferentes nıveis de permissoes de acesso definidos pelo utilizador

353 MySpace e WordPresscom

O MySpace uma das maiores social networks na Internet anunciou recente-

mente que vai disponibilizar uma versao do seu cliente de e-mail que utiliza o Gears

para acelerar o seu desempenho Numa fase inicial estara disponıvel apenas para

utilizadores que tenham cinco mil ou mais mensagens na sua caixa de correio e

permitira efectuar pesquisas muito mais rapido que a sua versao online

O servico de blogs Wordpresscom anunciou tambem o inıcio da utilizacao desta

tecnologia com o fim de melhorar o desempenho A versao que utiliza esta tecnologia

descarrega e armazena no cliente um conjunto de imagens e scripts que passam a

ter preferencia sobre os seus congeneres online e que permitem acelerar o processo

de carregamento da aplicacao e visualizacao de blogs

9Remember The Milk ndash httpwwwrememberthemilkcom10Google Maps ndash httpmapsgooglecom

27

Estado da arte

O MySpace e o Wordpresscom sao dois exemplos da utilizacao da tecnologia

OWA para optimizacao de web application ja existentes Sem pretenderem disponi-

bilizar uma versao que seja totalmente offline fazem uso do Gears para armazenar no

cliente parte dos recursos frequentemente acedidos na visualizacao das suas paginas

36 Escolha da tecnologia

Apos a analise das tecnologias apresentada nas seccoes 31 a 34 foi necessario es-

tudar a adequacao de cada uma delas ao projecto em questao Desde logo e possıvel

observar que nem todas se dedicam apenas a OWA Por exemplo o Adobe AIR

apesar de ter suporte para OWA apenas disponibiliza algumas das funcionalidades

identificadas como mais indicadas para a execucao do projecto quando utilizado

na sua vertente desktop tal como exposto na Tabela 31 mas a utilizacao desta

vertente implicaria o desenvolvimento de novas interfaces e de novas formas de co-

municacao (troca de mensagens XML ou JSON) A vertente web do Adobe AIR

foca-se mais especificamente nas Rich Internet Applications e permite a reutilizacao

do codigo ja existente (exigindo naturalmente a sua adaptacao e a implementacao

das funcionalidades pretendidas)

A tecnologia escolhida para a realizacao deste trabalho foi o Gears sendo que

um dos principais factores a influenciar esta opcao foi a liberdade introduzida pela

sua licenca Berkeley Software Distribution (BSD)11

Considerou-se o funcionamento desta ferramenta extremamente adequando a

aplicacao no WOW uma vez que o seu principal objectivo e precisamente tornar

possıvel a execucao offline de uma pagina web e por virtude deste facto o Gears tem

uma API concisa e de simples aplicacao pratica uma vez que nao possui quaisquer

outros elementos distractores O funcionamento do seu ManagedResourceStore ex-

emplificado na Figura 31 com a capacidade de actualizacao de recursos definidos

num ficheiro manifesto especificado em JSON pesou tambem nesta decisao

11Sobre a licenca BSD consultar httpwwwopensourceorglicensesbsd-licensephp e http

wwwlinfoorgbsdlicensehtml

28

Estado da arte

Figura 31 Esquema UML do processo efectuado pelos recursos do Gears do tipoManagedResourceStore para a actualizacao dos conteudos definidos no ficheiro manifesto

29

Estado da arte

Funcionalidade RIAs no browser RIAs no desktop

Disponibilidadeda aplicacao

As aplicacoes podem ser facil-mente exploradas e utilizadas

As aplicacoes quando instal-adas tem maior grau de fun-cionalidades e persistencia

Instalacao Nao e necessario qualquer tipode instalacao

As aplicacoes sao instaladasatraves do browser ou descar-regadas e instaladas comouma aplicacao tradicional

Actualizacoes Aplicacoes sao actualizadascarregando conteudos paraum website

O AIR disponibiliza uma APIque permite que as aplicacoessejam actualizadas de umaforma

Sistemas opera-tivos suportados

As aplicacoes podem ser exe-cutadas em diversos sistemasoperativos e browsers

As aplicacoes sao multi-plataforma e podem serinstaladas e executadas emdiversos sistemas operativos ebrowsers

Linguagens deprogramacao

Javascript e disponibilizadopelo browser e ActionScripte disponibilizado pelo AdobeFlash Player

Maquinas virtuais deJavascript e ActionScriptcompatıveis com o browser

Capacidade deexecucao embackground

As RIAs podem ser execu-tadas numa janela do browser

As aplicacoes podem ser ex-ecutadas em background edisponibilizar notificacoes talcomo uma aplicacao tradi-cional

Persistencia A actividade esta limitada asessao do browser Quando obrowser e encerrado toda ainformacao e descartada

As aplicacoes sao instaladas eestao disponıveis no desktopPodem armazenar informacaolocalmente e estao disponıveisoffline

Integracao com odesktop

Integracao com o desktop lim-itada devido a restricoes im-postas pelo browser

As aplicacoes podem acederao sistema de ficheiro ao clip-board eventos notificacoesetc

Controlo da inter-face com o uti-lizador

As aplicacoes sao acedidasatraves de uma janela dobrowser que tem os seusproprios controlos e visualgrafico

As aplicacoes tem um vi-sual grafico proprio em janelapropria

Armazenamentode dados

As aplicacoes tem armazena-mento limitado que pode serreescrito pelo browser

As aplicacoes tem acesso a to-talidade do espaco disponıvellocalmente e a uma base dedados com a possibilidade deencriptacao

Tabela 31 Comparacao das funcionalidades oferecidas pelo Adobe AIR para as platafor-mas web e desktop

30

Estado da arte

Aplicacao Modo de execucao utilizadoGoogle Reader Utiliza o modo ldquoutilizador deciderdquo disponibilizando

ao utilizador um botao para alternar entre os modosonline e offline Como lida com informacao recol-hida de fontes externas de natureza frequentementeefemera o processo de sincronizacao apenas transfereos dois mil itens mais recentes quando passa ao es-tado offline Neste modo sao ainda guardadas in-formacoes de itens lidos e etiquetas atribuıdas quesao sincronizadas com o servidor quando o utilizadorvoltar a activar estado online

Google Docs Utiliza o modo ldquoaplicacao deciderdquo permitindo que outilizador edite os conteudos de documentos de textofolhas de calculo e de apresentacoes independente-mente do estado da ligacao desde o momento em queas funcionalidades offline sao activadas A aplicacaofaz pequenas sincronizacoes com o servidor sempre quenecessario

Remember the Milk Utiliza um modo hıbrido entre ldquoaplicacao deciderdquo eldquoutilizador deciderdquo A aplicacao encarrega-se da sin-cronizacao de dados mas disponibiliza um controlona sua interface que permite despoletar manualmenteeste processo para situacoes em que o utilizador fez al-teracoes recentes e pretende usufruir das capacidadesoffline imediatamente

MySpace O MySpace anunciou a utilizacao de mecanismos dearmazenamento de dados no cliente com recurso atecnologias OWA para melhorar o desempenho doseu cliente web de correio electronico nomeadamenteno que diz respeito a operacoes de pesquisa e or-denacao Inicialmente esta funcionalidade estara ape-nas disponıvel para utilizadores com cinco mil ou maismensagens na sua caixa de correio mas nao e aindaclaro se sera disponibilizada uma versao totalmenteoffline

Tabela 32 Resumo da utilizacao de tecnologias OWA em algumas web applications con-sideradas na analise do estado da arte

31

Estado da arte

32

Capıtulo 4

Desenvolvimento

Neste capıtulo introduz-se a aplicacao WOW e apresenta-se o estudo que foi

feito da adequacao de cada tecnologia para a implementacao da funcionalidade of-

fline nesta plataforma Fazem-se diversas consideracoes sobre opcoes a tomar na

concepcao de OWAs e problemas comuns na sua implementacao bem como sug-

estoes para os resolver O WOW e uma aplicacao ja existente de gestao de ordens

de trabalho e do fluxo de tarefas numa empresa ou organizacao

41 Como ficar offline

Na maior parte das web applications de hoje nao existe uma camada de dados

real A aplicacao exemplificada na Figura 41 ao longo da sua execucao acede

directamente a sua unica fonte de dados (o servidor) atraves de chamadas Ajax sem

que exista uma separacao clara destas duas camadas

Para que uma web application seja capaz de ser executada sem uma ligacao

activa a Internet e mantenha o seu caracter dinamico torna-se necessario incluir

Figura 41 Exemplo de uma arquitectura de uma web application sem uma camada deabstraccao de dados Figura adaptada de http gears google com

33

Desenvolvimento

Figura 42 Exemplo de uma arquitectura de uma web application com uma camada deabstraccao de dados Figura adaptada de http gears google com

um mecanismo de armazenamento de dados local seja uma base de dados ou a

capacidade de acesso ao disco No entanto este mecanismo introduz dois problemas

1 Qual das fontes de dados utilizar quando um utilizador faz um pedido de

informacao

2 A necessidade de implementar uma camada de acesso a dados que seja coerente

quer se use o servidor remoto ou local

Por exemplo em vez de a aplicacao Ajax fazer um pedido relativo as contas de

todos os utilizadores em formato JSON directamente ao servidor remoto podera ao

inves fazer o pedido a um objecto intermedio da camada de dados Este objecto

demonstrado na Figura 42 sera responsavel por implementar uma interface de

acesso a base de dados e retornar um objecto JavaScript com uma representacao da

resposta do servidor

Mas a existencia de uma segunda fonte de dados torna recomendavel tambem

a implementacao de uma camada de data switching que em funcao da existencia

de conexao a Internet e da necessidade de actualizacao dos dados decide se faz o

pedido ao servidor remoto ou se fornece os dados presentes localmente Este objecto

apresentado na Figura 43 decidira de forma transparente para o utilizador se le ou

escreve os dados localmente ou se os enviapede ao servidor remoto e pode tambem

iniciar o processo de convergencia de dados e de resolucao de conflitos

411 Funcionalidades disponıveis em modo offline

Por razoes praticas e provavel que nem todas as funcionalidades da aplicacao

possam ser disponibilizadas em modo offline E necessario escolher quais as fun-

cionalidades a disponibilizar no modo offline da aplicacao e implementar a logica

que decide quando utilizar a base de dados local ou o servidor remoto Apesar do

acesso a base de dados local ser muito mais rapido do que aceder ao servidor o

acesso local nem sempre e preferido Ha varias razoes que podem tornar necessario

escolher o acesso ao servidor em vez do acesso local

34

Desenvolvimento

Figura 43 Exemplo de uma arquitectura de uma web application com uma camada deabstraccao de dados e um data switch Figura adaptada de http gears google com

1 A informacao pode ter uma natureza efemera e nao fazer sentido guarda-la

localmente Exemplo dados em tempo real da bolsa de valores de Lisboa

2 Algumas aplicacoes lidam com informacao que so faz sentido na presenca de

uma ligacao Exemplo Instant Messaging

3 A aplicacao podera escolher apenas guardar a informacao acedida mais fre-

quentemente Exemplo para o utilizador poder alterar a lıngua de apre-

sentacao da aplicacao os conteudos terao que ser guardados em todas as

lınguas disponibilizadas pela aplicacao O custo de implementacao de algu-

mas funcionalidades pode nao compensar o benefıcio

4 A capacidade de processamento ou de armazenamento de dados pode inviabi-

lizar algumas funcionalidades offline Exemplo se uma dada funcionalidade

necessita de uma capacidade de armazenamento de dados para alem do razoavel

de um computador pessoal para ser util (visualizador de mapas)

42 Modos de execucao

Um aspecto que e necessario estudar para qualquer web application que se deseje

disponibilizar offline prende-se com tres modos de execucao que devem ser consid-

erados

1 Utilizador decide o modo de execucao A aplicacao tem modos distintos

de execucao para os estados online e offline geralmente indicados na interface

com o utilizador O utilizador e informado do estado da ligacao e participa na

alteracao de estado de execucao da aplicacao interagindo com a sua interface

2 Aplicacao decide o modo de execucao Pode ser implementado na propria

aplicacao um mecanismo de deteccao do estado da ligacao (por exemplo atraves

35

Desenvolvimento

de chamadas Ajax periodicas) transitando de estado e sincronizando automati-

camente Desta forma o utilizador nao precisa de participar na alteracao de

estado a menos que exista um conflito de dados que requeira a sua atencao

3 Aplicacao assume sempre o estado offline Outra hipotese sera imple-

mentar uma web application que assume sempre estar na ausencia de uma

ligacao ao servidor de dados Esta aplicacao responde aos pedidos do uti-

lizador efectuando pedidos de informacao ao servidor mas nao dependendo

de uma resposta valida para mostrar a informacao que ja tinha disponıvel an-

teriormente A sincronizacao de dados com o servidor e tentada sempre que

existam dados para submeter e uma accao do utilizador

421 Modo ldquoutilizador deciderdquo

Neste modo de execucao quando a aplicacao esta online comunica com o servidor

remoto quando esta offline comunica com a base de dados local A informacao tem

que ser sincronizada sempre que se muda de modo A principal vantagem desta opcao

e que e a mais simples de implementar mesmo para uma aplicacao ja existente e

portanto uma forma expedita de disponibilizar uma OWA No entanto tem tambem

algumas desvantagens que devem ser consideradas

1 O utilizador tem que se lembrar de fazer a alteracao de estado de execucao

Caso contrario podera estar a trabalhar inadvertidamente numa versao offline

com dados antigos ou nao ter a informacao necessaria se perder subitamente

a ligacao

2 Se a ligacao for intermitente o utilizador tera ou que escolher um dos modos

de execucao ou estar constantemente a trocar

3 Uma vez que a base de dados nao esta sempre actualizada nao podera ser

utilizada para melhorar a rapidez de execucao da aplicacao quando em modo

online

422 Modo aplicacao decide

A deteccao do estado da ligacao pode ser implementada atraves de um pedido

assıncrono ao servidor tal como ilustrado na Figura 44 O resultado deste pedido

definira o estado online (em caso de sucesso) ou offline (em caso de falha) A

sincronizacao de dados podera ser feita sempre que ocorra uma transicao do es-

tado offline para o estado online No entanto este metodo nao se revela eficiente

36

Desenvolvimento

Figura 44 Esquema grafico ilustrando uma OWA executando no browser utilizando ummodo de execucao do tipo ldquoaplicacao deciderdquo com deteccao automatica do estado daligacao via pedidos Ajax assıncronos a cada cinco segundos

para grandes aplicacoes uma vez que requer a troca de mensagens demasiado fre-

quentes com o servidor que se destinam exclusivamente a monitorizacao do estado

da ligacao

423 Modo ldquoaplicacao assume o estado offlinerdquo

Uma aplicacao transparente funciona assumindo sempre que esta em modo of-

fline ou pelo menos que pode perder a ligacao a qualquer momento Neste modo

tira-se o maximo partido do armazenamento local e fazem-se pequenas mas contınuas

sincronizacoes com o servidor sempre que este esteja disponıvel A sincronizacao de

dados tambem e feita sempre que se volta ao estado online

As vantagens de uma web application transparente sao as seguintes

bull Uma melhor experiencia para o utilizador uma vez que este nao tem que se

preocupar com o estado da ligacao ou com a transicao de estados

bull A aplicacao funciona de forma coerente mesmo que a ligacao seja intermitente

bull Uma vez que o armazenamento local e mantido actualizado pode ser utilizado

para melhorar o desempenho da aplicacao

Foram identificadas as seguintes desvantagens

bull E mais difıcil de implementar e a sincronizacao acarreta cuidados especiais

bull E necessario um cuidado adicional para evitar que as operacoes de sincronizacao

frequentes que ocorrem automaticamente nao afectem os tempos de resposta

da aplicacao

bull Os testes a aplicacao sao mais complexos uma vez que a sincronizacao de dados

nao ocorre em resposta a uma accao do utilizador

37

Desenvolvimento

43 Sincronizacao de dados

A sincronizacao de dados consiste na capacidade de identificar e transferir pe-

riodicamente a versao mais actual dos dados entre o cliente e o(s) servidor(es)

Independentemente do modo de execucao escolhido e mesmo do estado da ligacao

do utilizador a informacao armazenada localmente e a informacao armazenada no

servidor estarao por vezes dessincronizadas Isto podera acontecer sempre que por

exemplo

bull O utilizador faz alteracoes em modo offline

bull A informacao e partilhada e pode ser alterada por uma entidade externa

bull A informacao e fornecida por uma entidade externa

Resolver estas diferencas de forma a que a informacao local e remota encontrem

a igualdade chama-se sincronizacao de dados Ha varias aproximacoes possıveis

para este efeito que dependem da natureza da aplicacao cada uma com vantagens

e desvantagens

A capacidade de suportar a mobilidade dos utilizadores torna-se cada vez um

ponto mais importante de uma web application Para uma organizacao de dimensao

global e vital garantir que os seus colaboradores tem acesso a mesma informacao

que tem disponıvel nos seus postos de trabalho mesmo quando estao fora Na maior

parte dos casos estes colaboradores terao acesso a um computador portatil um

desktop Smartphone ou PDA e atraves destes poderao ter acesso a sua informacao

directamente atraves de ligacoes encriptadas Virtual Private Network (VPN) de um

servidor web ou de outro mecanismo de rede

Esta solucao e simples de implementar mas infelizmente para a maioria dos

colaboradores com grande factor de mobilidade nao e satisfatoria As principais

desvantagens sao as seguintes

bull Requisitos de ligacao Para permitir que os utilizadores acedam a sua in-

formacao e necessario garantir a capacidade constante de comunicacao pelo

menos durante o tempo necessario que assegure a sua transferencia

bull Velocidade de ligacao sem persistencia de dados e em ligacoes de fraca

qualidade a usabilidade por vezes torna-se inaceitavel

bull Ponto crıtico de falha Com este tipo de solucao todos os utilizadores de-

pendem da base de dados que armazena informacao vital para o funcionamento

do cliente

38

Desenvolvimento

bull Scalability do servidor A medida que novos utilizadores sao adicionados ao

sistema o desempenho do servidor e afectado levando a necessidade de maior

capacidade de armazenamento eou processamento

De acordo com a documentacao da Microsoft Sync Framework [Mic08] uma

solucao alternativa consiste em implementar uma Occasionally Connected Appli-

cation (OCA) Uma OCA permite a um utilizador remoto continuar a aceder a

sua informacao mesmo depois de perder a ligacao mas em vez de recorrer a um

servidor recorre a informacao armazenada no seu dispositivo local Para preencher

localmente a informacao que o utilizador necessita uma OCA possui mecanismos

de sincronizacao de dados que sao oferecidos por esta framework

431 Quando sincronizar

Uma das solucoes mais simples de implementar passa por disponibilizar um

mecanismo manual que despoleta a sincronizacao Diz-se manual porque e o uti-

lizador que escolhe quando sincronizar e pode ser implementada simplesmente

fazendo o upload de toda a informacao para o servidor e depois fazendo o download

da copia mais recente da informacao antes de voltar a ficar offline Para que esta

seja uma opcao viavel e necessario que

bull O volume de dados seja suficientemente pequeno para que possa ser transferido

do servidor para o cliente num espaco de tempo aceitavel

bull Que o utilizador indique explicitamente que quer mudar para o estado offline

ou online pressionando um botao da interface

Contudo podem ser identificados alguns problemas relacionados com esta abor-

dagem

bull Os utilizadores nem sempre podem prever o estado das suas ligacoes A ligacao

pode-se perder subitamente ou ter um caracter intermitente

bull O utilizador pode esquecer-se de efectuar a sincronizacao

Outra opcao sera conjugar a sincronizacao de dados com o modo de execucao

transparente A sincronizacao ocorre automaticamente em background de forma

nao intrusiva para o utilizador A aplicacao comunica com o servidor regularmente

efectuando pequenas trocas de dados com o objectivo de manter o sincronismo da

informacao local e remota Esta abordagem pode ser implementada com pedidos

Ajax assıncronos e regulares ao servidor o que permite manter a interaccao com a

interface fluıda evitando bloqueios Estes pedidos sao feitos prevendo as situacoes

39

Desenvolvimento

de disponibilidade ou indisponibilidade (timeout) do servidor Uma outra opcao

sera permitir que o servidor comunique essas alteracoes utilizando Comet1 tal como

descrito em [Wil06] e [Rus06] As vantagens destas aproximacoes sao

bull A informacao esta disponıvel a qualquer altura que o utilizador decida ficar

offline ou que a ligacao seja acidentalmente perdida

bull O desempenho da aplicacao pode ser melhorado quando se estiver a utilizar

uma ligacao a Internet lenta uma vez que o acesso a dados locais e mais

eficiente do que a consulta de dados ao servidor

44 WOW

O WOW e uma plataforma integrada de gestao de ordens de trabalho ja ex-

istente e desenvolvida pela Critical Software SA a qual se pretende adicionar a

capacidade de execucao offline Esta aplicacao e extremamente dinamica e con-

figuravel com um conjunto extremamente rico de funcionalidades das quais se

destacam

bull Gestao de Ordens de Trabalho ndash suportando a gestao dos pedidos desde a

sua criacao ate ao seu fecho tomando em conta os diferentes tipos de pedidos

(ordens de trabalho pedidos de informacao melhorias resolucao de problemas

etc) e diferentes tipos de accoes possıveis para cada um (Figura 45)

bull Monitorizacao de alteracoes ndash Historico de mudancas anexos e estados criando

relatorios de alteracao automaticamente (o que por quem e quando)

bull Uso de Service Level Agreements (SLAs) ndash E possıvel associar a um pedido um

SLA que define qual o perıodo de tempo atribuıdo a resolucao de um pedido

controlando e agilizando a resolucao do mesmo

bull Utilizacao de queries de utilizador configuraveis que permitem acesso rapido

a determinadas ordens de trabalho de acordo com o filtro configurado (por

exemplo ldquoPara mimrdquo ldquoPara o Grupordquo ldquoPelo Grupordquo)

bull Gestao do relacionamento entre pedidos

bull Pesquisa e filtragem de ordens de trabalho

bull Exportacao de dados em formatos padrao (PDF DOC ou XLS)

bull Integravel com solucoes externas

40

Desenvolvimento

Figura 45 Detalhe de um conjunto possıvel de estados e respectivas transicoes para umadada ordem de trabalho no WOW desde a sua submissao no sistema ate a sua conclusaoem fecho ou cancelamento Esta figura representa apenas um exemplo ja que o mapa deestados para uma ordem de trabalho e dinamico e pode ser alterado por um administradorFigura retirada de uma brochura promocional do WOW Critical Software SA

A utilizacao de uma ferramenta deste tipo por parte de uma empresa ou orga-

nizacao oferece vantagens quer a gestao de topo quer aos colaboradores individuais

para os colaboradores individuais o WOW e uma aplicacao onde estao registadas

todas as tarefas contribuindo activamente para o desenvolvimento em ambientes

multi-tarefa e para a organizacao pessoal das tarefas de acordo com prioridades

Para a gestao de topo esta ferramenta permite obter uma visao global do estado da

organizacao em termos de tempo gasto por tarefa executada sendo uma mais valia

para a previsao e gestaoalocacao de recursos

45 Visao geral sobre a arquitectura do WOW

O WOW e interessante nao so do ponto de vista de produto como tambem do

ponto de vista de plataforma Existem diversos plug-ins que estendem as funcional-

idades do WOW e existem ate projectos que pretendem usar a arquitectura do

WOW para criar produtos com fins diferentes do inicial (por exemplo o WOW-

Storm ndash um sistema de registo e classificacao social de ideias)

De modo a conseguir ter essa expansibilidade a plataforma WOW assenta sob

uma arquitectura distribuıda modular e expansıvel com uma componente central

ndash o core ndash estruturado em camadas logicas E no core que se situam todas as

1O Comet e um conceito semelhante ao Ajax introduzido por Alex Russel mas no qual e o servidor quetoma a iniciativa de ldquoenviarrdquo os dados ao browser sem que este tenha que efectuar um pedido Tambem econhecido por Ajax Push Reverse Ajax ou HTTP Streaming

41

Desenvolvimento

funcionalidades base da aplicacao quer a nıvel logico funcional e de apresentacao

quer a nıvel de gestao e configuracao

E possıvel a execucao de varias instancias do core simultaneamente em servidores

distintos o que permite a alta escalabilidade e disponibilidade desta aplicacao A

consistencia dos dados fica sempre garantida atraves da partilha da base de dados

e pelo balanceamento dos pedidos uma vez que cada um e encaminhado para uma

unica instancia

O WOW apresenta tambem a vantagem de ser uma plataforma extensıvel E

possıvel adicionar novas caracterısticas a plataforma atraves de componentes que se

podem ser divididos em duas categorias plugins e connectors

Os plugins sao componentes que se encontram no mesmo no fısico que a aplicacao

partilhando do mesmo contexto de execucao do core Sao assim uma forma mais

directa de obter informacao da plataforma visto que nao possuem restricoes de

acesso aos dados nem dependencias externas A arquitectura deste componente tera

assim que permitir varias execucoes instanciadas cada uma associada a um core

Por outro lado os connectors sao componentes que se encontram distribuıdos

comunicando externamente com o core Quer a sua execucao quer a obtencao

dos dados estao assim dependentes de interfaces de comunicacao externas que a

plataforma disponibiliza Estes componentes ao contrario dos plugins sao instan-

ciados unicamente e recorrem ao protocolo de comunicacao Java Messaging Service

(JMS) para comunicar com o core

46 WOW Offline

Para alem das opcoes tomadas relativamente a tecnologia a utilizar surgiu

tambem a necessidade de optar por um dos modos de execucao apresentados na

seccao 42

Das tres opcoes possıveis foi o modo ldquoaplicacao assume o estado offlinerdquo descrito

na seccao 423 que mereceu a maior atencao uma vez que reune as vantagens de

uma experiencia mais positiva para o utilizador (uma vez que este nao tem que

participar activamente na alteracao do modo execucao como descrito na seccao 421)

e nao constitui uma sobrecarga excessiva para servidor (como o modo abordado na

seccao 422)

No entanto esta opcao comprometia a complexidade da implementacao para alem

dos objectivos propostos para este projecto e para cumprir o prazo dado foi tomada

a decisao de implementar o modo ldquoutilizador deciderdquo especificando apenas de forma

teorica o modo ldquoaplicacao assume o estado offlinerdquo

As caracterısticas do Gears foram ja descritas na seccao 31 Na Figura 47

mostra-se a sua forma de funcionamento quando integrado numa web application

42

Desenvolvimento

Nesta figura representa-se o modulo LocalServer do Gears como um ponto de de-

cisao Aqui sao testadas as condicoes que determinam se o pedido sera interceptado e

servido localmente ou se prossegue para uma maquina remota E tambem represen-

tada uma base de dados que corresponde ao modulo Database mas que podera nao

ser utilizada Este modulo tal como o modulo Workerpool tem caracter opcional

e sao utilizados consoante os requisitos da aplicacao

A plataforma WOW lida com mais dados do que e necessario passar para o

lado do cliente Em conformidade com o ja exposto na seccao 411 volta-se a

frisar que nao se pretende recriar toda a logica de negocio nem os conteudos da

base de dados no cliente pela sua complexidade e volume de dados Pretende-se

pelo contrario permitir que os utilizadores tirem partido da capacidade de poder

consultar as suas ordens de trabalho quando nao dispoe de uma ligacao transferindo

apenas o essencial para isto seja possıvel

A pagina inicial do WOW apresenta um resumo das ordens de trabalho abertas

ndash enviadas e recebidas ndash que se pretende permitir visualizar offline (ver Figura 46)

Como prova de conceito foi efectuada uma abordagem pragmatica das varias possi-

bilidades descritas na seccao 42

461 Modo ldquoaplicacao deciderdquo com deteccao automatica da ligacao

A primeira abordagem estudada para a disponibilizacao das funcionalidades of-

fline foi o modo ldquoaplicacao deciderdquo com deteccao automatica de ligacao apresentado

na seccao 422 Para que isto seja possıvel foi implementado um mecanismo de ver-

ificacao periodica do estado da ligacao atraves de chamadas Ajax assıncronas O

resultado destes pedidos determina o estado da aplicacao executando as tarefas de

sincronizacao de dados sempre que pertinente Este metodo embora imediato e

simples de implementar depressa se revelou inadequado para o projecto devido ao

elevado consumo de recursos do servidor que a utilizacao intensiva faz esperar a

comunidade da plataforma WOW no principal cliente excede os 7000 utilizadores

Foi estimado que para uma utilizacao de fluidez aceitavel o estado da ligacao deveria

ser testado a cada cinco segundos Assumindo uma adesao (previsao pessimista) de

1 aos servicos offline assistir-se-ia a cerca de 840 pedidos adicionais por minuto

Mas o principal problema desta aproximacao prende-se com o facto de a ver-

ificacao ser feita em intervalos de tempo discretos levando a possibilidade de a

aplicacao poder ter em dado momento uma representacao errada do seu estado

real da ligacao Este problema e ilustrado na Figura 48 onde se ve claramente a

discrepancia entre o estado real da ligacao e a representacao interna que esta tem

Note-se que nesta janela de tempo qualquer accao do utilizador que exija uma

resposta sıncrona do utilizador leva-lo-a para um ldquobeco sem saıdardquo onde nao tera

43

Desenvolvimento

Figura 46 A pagina inicial do WOW apresenta um resumo das ultimas ordens de trabalhoenviadas e recebidas Na imagem pode-se observar a transicao do estado online para offline

acesso a versao offline porque a aplicacao nao fez a transicao automatica nem acesso

a versao online porque na verdade nao possui uma ligacao O que acontecera nesta

situacao sera uma tentativa de acesso ao servidor por parte da aplicacao numa

altura em que este se encontra indisponıvel e o resultado sera uma mensagem de

ldquopedido excedeu o tempordquo apresentado pelo browser Este e um estado sem retorno

porque apos o browser apresentar esta mensagem todos os recursos JavaScript ficam

indisponıveis tornando impossıvel o regresso ao estado anterior ou o tratamento do

erro de qualquer outra forma No entanto as chamadas Ajax podem ser tratadas de

forma especial para a eventualidade de falha e portanto nao constituem problema

44

Desenvolvimento

Figura 47 Ilustracao do funcionamento do Gears numa web application que utiliza ummotor Ajax Os pedidos HTTP ou HTTPS podem ser interceptados e tratados localmenteou podem ser feitos a uma maquina remota consoante se verificarem ou nao as condicoesexpressas no ponto 311 E representado um acesso a uma base de dados local (fornecidapelo Gears) mas a sua utilizacao e opcional

462 Implementacao do modo ldquoutilizador deciderdquo

Este modo de execucao foi ja descrito na seccao 421 e a sua principal carac-

terıstica e ser o utilizador a decidir se a aplicacao deve utilizar um servidor remoto

ou a maquina local como fornecedor de dados

Relativamente ao WOW o WOW Offline na vertente ldquoutilizador deciderdquo vem

alterar os seus casos de uso dando ao utilizador a possibilidade de alterar o estado

de execucao da aplicacao (entre online e offline) Resta dizer que no modo online se

mantem todas as funcionalidades anteriores e que no modo offline torna-se possıvel

visualizar os conteudos da pagina principal do WOW (Figura 46) e os detalhes das

ordens de trabalho (Figura 49) tal como expressa a Figura 410

Esta aproximacao foi utilizada na prova de conceito do WOW adicionando um

controlo a interface desta aplicacao que permite ao utilizador alternar entre os esta-

dos online e offline Na transicao de online para offline sao descarregados os recursos

necessarios para a execucao desta aplicacao sem recorrer a Internet Para o fazer

45

Desenvolvimento

Figura 48 Neste exemplo do modo ldquoaplicacao deciderdquo o teste da ligacao e feito e feito acada cinco segundos O resultado deste teste nao reflecte sempre o estado real da aplicacaopodendo levar a aplicacao a ter comportamentos indesejaveis Na figura assinala-se umperıodo de tempo no qual a representacao interna do estado da ligacao nao corresponde arealidade

e utilizado um recurso ResourceStore e um ManagedResourceStore (introduzidos

em 311) O primeiro e utilizado para armazenar a pagina principal do WOW ndash do-

ravante designada por homejsp ndash e o segundo e utilizado para armazenar imagens

folhas de estilo CSS e scripts JavaScript

Para a implementacao deste modo de execucao foram identificadas as seguintes

tarefas

1 Guardar informacao que permita a recriacao das paginas que se pretende

disponibilizar offline (utilizando o Gears)

2 Disponibilizar um controlo que permita alterar o estado de execucao atraves

da interaccao com a pagina principal

3 Durante a sincronizacao de dados apresentar o progresso da transferencia de

dados

O primeiro passo consistiu na identificacao de todos os conteudos que sao necessarios

transferir para a execucao offline Foi utilizado um recurso do Gears do tipo

ManagedResourceStore que recorre a um ficheiro manifesto para identificar to-

dos os ficheiros que deve transferir Este recurso e gerido automaticamente pelo

Gears transferindo para o cliente a versao mais recente sempre que e necessario

isto e sempre que exista um ficheiro manifesto com uma identificacao de versao que

seja diferente da actualmente disponıvel no cliente Uma vez identificados todos

ficheiros necessarios para a execucao offline num (ou mais) ficheiros manifesto o

Gears encarrega-se da sua actualizacao mas o preenchimento destes ficheiros man-

ifesto e manual o que se traduz num cuidado extra na manutencao da aplicacao

A forma como esta informacao e guardada deve tambem ser cuidadosamente

estudada A opcao mais flexıvel passa por utilizar o modulo Database apresentado

na seccao 311 e guardar a informacao de uma forma relacional Para a recriacao

das paginas pode ser disponibilizada uma versao HTML da pagina que funciona

46

Desenvolvimento

Figura 49 Pagina de visualizacao do detalhe de uma ordem de trabalho

como template nao possui quaisquer dados e e utilizada apenas em modo offline E

preenchida para cada pedido retirando os dados relevantes da base de dados

O modelo de dados do WOW torna esta opcao extremamente trabalhosa uma

vez que as entidades envolvidas na geracao de cada pagina de informacao sobre

cada ordem de trabalho tem relacoes de dependencia complexas seguindo padroes

muito variaveis Por exemplo em cada ordem de trabalho existe um formulario que

permite a sua progressao de estado com diversos campos opcionais e obrigatorios

este formulario e definido pelo administrador e esta relacionado nao apenas com o

tipo de ordem de trabalho mas tambem com o estado actual em que esta se encontra

e a accao que se pretende realizar O elevado numero de combinacoes de tipos de

ordem de trabalho estados e accoes que existem num dado momento juntamente

com a sua possibilidade de alteracao obrigariam a implementacao de uma logica de

negocio complexa o que esta fora do ambito deste projecto

47

Desenvolvimento

Figura 410 Esquema UML que expressa os casos de uso do WOW Offline no modoldquoutilizador deciderdquo

463 Especificacao do modo ldquoaplicacao assume o estado offlinerdquo

A aproximacao para o modo ldquoaplicacao assume o estado offlinerdquo foi tambem

dividida em varias tarefas

1 Guardar informacao que permita a recriacao da pagina principal do lado do

cliente no estado offline (utilizando o Gears)

2 Dotar a aplicacao do cliente de um mecanismo de deteccao da ligacao

3 Identificar os ldquomomentos chaverdquo em que devera ocorrer sincronizacao de dados

4 Implementar a sincronizacao de dados

A sincronizacao de dados deve ser feita em ambas as transicoes online-offline e

offline-online quer para transferir novos dados do servidor (os pedidos podem ser

alterados por outros utilizadores) quando se transita do estado quer para comunicar

eventuais alteracoes feitas em modo offline

Relativamente ao WOW o WOW Offline na vertente ldquoaplicacao assume o es-

tado offlinerdquo vem alterar os seus casos de uso dando ao utilizador a possibilidade

de activar esta funcionalidade A partir do momento que a funcionalidade esta ac-

tivada o utilizador deve tambem ter a possibilidade de gerir algumas preferencias

relacionadas com privacidade de dados Devera ter a hipotese de desactivar o ar-

mazenamento local e de remover todos os dados ja armazenados tal como descrito

na Figura 411

48

Desenvolvimento

Figura 411 Esquema UML que expressa os casos de uso do WOW Offline no modoldquoutilizador deciderdquo

A primeira vez que o WOW Offline e acedido por um cliente e caso seja detec-

tada a presenca do Gears todos os recursos necessarios a sua execucao sao trans-

feridos Todos os acessos posteriores serao feitos a estes recursos locais (recorda-se

que o Gears pode ser utilizado para os manter actualizados recorrendo ao Managed-

ResourceStore 311)

Atraves do JavaScript e possıvel interceptar os eventos de load e unload da

pagina que sao despoletados sempre que ocorre um re-acesso da mesma (incluindo

a accao refresh comum dos browsers) sempre que esta e abandonada ou ainda ou

ainda se a janela for encerrada

Tal como sugerido na seccao 462 a camada de interface desta aplicacao (cada

pagina individual em HTML) devera ser implementada como sendo um template

para apresentacao de dados sendo totalmente preenchida atraves de funcoes em

JavaScript O objectivo deste ponto e criar um padrao de dados que permita ao

JavaScript preencher os dados em cada pagina (template) independentemente de

qual seja a fonte ndash o servidor remoto ou a maquina local tal como exemplificado

no diagrama da Figura 412 Na figura a aplicacao recorre ao servidor remoto para

obter os dados pretendidos quando se encontra na presenca de uma ligacao mas

para dados que exijam uma carga de processamento pelo servidor este acto pode ser

49

Desenvolvimento

Figura 412 Esquema UML que expressa o acto de recolha de dados em modo online eoffline recorrendo ao servidor (modo online) e ao sistema de armazenamento de dadoslocal fornecido pelo Gears (modo offline)

substituıdo pelo envio de um campo de controlo que se destina a aferir se os dados

locais se encontram actualizados No caso de estarem actualizados a comunicacao

com o servidor pode ser substituıda por uma query a base de dados local

50

Capıtulo 5

Resultados e Futuros

Desenvolvimentos

Todo o estudo feito sobre o tema OWA foi ja abordado ao longo do documento

Neste capıtulo apresentam-se os resultados obtidos na implementacao da prova de

conceito que visava compreender a melhor forma de disponibilizar uma versao of-

fline no WOW uma plataforma de gestao de ordens de trabalho ja existente de-

senvolvida pela Critical Software SA

51 Resultados Obtidos

Os resultados obtidos neste projecto sao extremamente satisfatorios uma vez

que o estudo do tema OWA e a implementacao de uma prova de conceito que o

ilustrasse foi conseguido com sucesso

A funcionalidade offline foi adicionada ao produto WOW da Critical Software

SA permitindo a visualizacao de ordens de trabalho e dos seus detalhes mesmo na

ausencia de uma conexao activa a Internet Embora para a solucao implementada

tenha sido utilizada uma abordagem do tipo ldquoutilizador deciderdquo pretende-se que esta

seja convertida para ldquoaplicacao deciderdquo ou mesmo para uma aproximacao hıbrida

semelhante a utilizada pelas aplicacoes estudadas nas seccoes 351 e 352

Para a sua implementacao descrita no capıtulo 4 foram tomadas decisoes de or-

dem pratica que permitissem tornar o trabalho exequıvel nos prazos dados Tentou-

se sempre que estas decisoes afectassem o mınimo em termos de desempenho e de

experiencia para o utilizador Considera-se que a implementacao do modo offline

com uma transicao entre modos do tipo ldquoutilizador deciderdquo (ver seccao 42) reflecte

o compromisso entre o desempenho pretendido e os recursos disponıveis e para alem

51

Resultados e Futuros Desenvolvimentos

de ser um exemplo eficaz das possibilidades que as OWA podem trazer a aplicacao

WOW desenvolvida pela Critical Software e tambem um estudo que pode ser uti-

lizado para analisar a implementacao desta tecnologia noutros produtos da mesma

empresa

Note-se que o principal objectivo do trabalho era ganhar familiaridade com este

tema entender as suas vantagens e desvantagens e compreender as suas limitacoes

Tudo indica que existam varias possibilidades de implementacao deste paradigma

noutros produtos da Critical Software que pela sua natureza podem tambem tirar

partido da execucao offline

52 Trabalho Futuro

O desenvolvimento do conceito e formas de implementacao de OWA continua

em forte desenvolvimento no entanto a sua adopcao ainda nao e generalizada A

dificuldade da sua implementacao em web applications ja existentes e o principal

obstaculo a sua maior divulgacao

Ha tambem um factor que deve ser tido em consideracao a manutencao de

codigo A implementacao de uma versao offline de uma web application requer

a implementacao das mesmas regras de negocio (ou de uma versao simplificada)

utilizadas no servidor Para que isto seja possıvel e necessario ter em conta a

capacidade de processamento do cliente e o factor de duplicacao de codigo que

tornara a aplicacao mais difıcil de manter uma vez que uma alteracao a logica de

negocio do servidor implica tambem uma alteracao a sua versao offline

A prova de conceito implementada permite ja a visualizacao offline dos pedidos

abertos (enviados e recebidos) que constam na pagina principal (este numero e

fixo e pode ser alterado pelo administrador) Uma funcionalidade desejavel seria a

possibilidade de interaccao com a aplicacao em modo offline e sincronizacao com o

servidor quando existisse uma ligacao disponıvel

Foi estudada a utilizacao do modo de execucao ldquoaplicacao assume o estado of-

flinerdquo descrito em 423 e esta seria a forma desejavel para o WOW Offline no

entanto para que esta opcao seja viavel sera necessaria a implementacao de uma

forma eficiente de sincronizacao e armazenamento de dados de uma forma relacional

Para atingir este objectivo podera ser seguida uma polıtica de automacao do pro-

cesso no qual a versao online da aplicacao gera scripts de criacao para as tabelas

necessarias na base de dados da versao offline (nao existe nenhuma ferramenta para

o fazer portanto seria necessaria a sua implementacao) e no qual as paginas HTML

disponibilizadas pelo servidor aos clientes web (browser) servem como templates de

apresentacao de informacao e sao preenchidas de forma semelhante pelo servidor ndash

quando a aplicacao estiver online ndash ou pelo cliente atraves de funcoes em JavaScript

52

Resultados e Futuros Desenvolvimentos

ndash quando a aplicacao estiver offline No entanto no WOW devido a quantidade de

informacao tratada e devido as complexas relacoes entre as diferentes entidades e

de esperar que a complexidade da implementacao de um mecanismo deste tipo torne

esta aproximacao demasiado custosa

O HTML 5 embora um forte candidato ainda nao esta suficientemente desen-

volvido A sua especificacao ainda tem o caracter de Draft (rascunho) e esta sujeita

a modificacoes e a aceitacao e implementacao por parte dos browsers e portanto

de momento foi desconsiderado No entanto no futuro se esta especificacao atingir

um estado de maturidade que permita a sua adopcao devera ser considerada como

um possıvel caminho a seguir

53

Resultados e Futuros Desenvolvimentos

54

Capıtulo 6

Conclusoes

Neste capıtulo sao apresentadas as conclusoes do projecto e consideracoes finais

relativamente a tecnologia estudada

61 Conclusoes

O rapido desenvolvimento tecnologico faz prever que a disponibilidade de ligacao

a Internet seja cada vez mais facil e mais rapido mas vao continuar a existir lugares

onde o acesso e limitado e onde as OWA podem desempenhar um papel de relevo

Por outro lado esta tecnologia pode tambem ser utilizada para melhorar o desem-

penho de paginas web com uma necessidade elevada de imagens ou outros recursos

dispendiosos em termos de espaco e foram ate estudados dois exemplos da utilizacao

desta vertente desta tecnologia em 353

Acredita-se que as OWAs vem responder a uma necessidade real por parte das

web applications actuais e que a evolucao que representam se compara a que se

assistiu dos thin-clients para os fat-clients em termos de autonomia do servidor

A capacidade de oferecer conteudos dinamicos no browser independentemente da

existencia de uma ligacao reune as vantagens tıpicas das web applications como

ausencia de instalacao e actualizacoes instantaneas com as vantagens das aplicacoes

de desktop em capacidade de processamento e armazenamento de dados na maquina

local

As tecnologias disponıveis ate a data estudadas no ambito deste projecto que

permitem o desenvolvimento de OWAs e que apresentam maior maturidade sao o

Gears e o Adobe AIR Ambas se apresentam sobre a forma de plugins que necessitam

de uma instalacao extra para poderem ser utilizadas Apesar de esta instalacao ser

55

Conclusoes

apenas necessaria uma vez podera constituir um factor de desencorajamento a sua

adopcao

O HTML 5 uma especificacao abordada neste documento na seccao 34 podera

ser uma alternativa que oferece funcionalidades offline a uma web application sem a

necessidade de qualquer instalacao no entanto esta especificacao ainda nao foi aceite

pelos principais browsers ndash o documento que define o HTML 5 ainda tem o estatuto

de Draft ndash e ainda nao e possıvel antecipar quando e que isto podera acontecer

Um dos problemas que surge frequentemente na implementacao de uma versao

offline para uma web application e a necessidade de sincronizacao de dados Quando

a informacao pode ser alterada por varios utilizadores simultaneamente e necessario

prever os conflitos que daı podem surgir e dotar a aplicacao de uma forma de os

resolver ou alertar o utilizador para a necessidade de alteracao dos dados

Em conclusao todos os objectivos propostos para este projecto foram atingidos

A prova de conceito implementada reflecte de forma clara as possibilidades oferecidas

pela tecnologia OWA e sera utilizado no futuro para compreender a melhor forma

de o implementar de forma definitiva no WOW

56

Referencias

[Ada08] Lucas Adamski Introducing Adobe AIR security model Fevereiro de2008 Disponıvel em httpwwwadobecomdevnetairarticles

introduction_to_air_securityhtml acedido em Marco de 2008

[Ado08] Adobe Adobe AIR 10 Security White Paper 2008 Disponıvel emhttpdownloadmacromediacompubairdocumentation1air_

securitypdf acedido em Marco de 2008

[Alm08] Dion Almaer Gears as a bleeding-edge html 5 implementa-tion March 2008 Disponıvel em httpalmaercomblog

gears-as-a-bleeding-edge-html-5-implementation acedido emMarco de 2008

[BL96] Tim Berners-Lee The world wide web Past present and future Agostode 1996 Disponıvel em httpwwww3orgPeopleBerners-Lee

1996ppfhtml acedido em Abril de 2008

[CDGH08] Mike Chambers Daniel Dura Dragos Georgita and Kevin Hoyt AdobeAIR for JavaScript Developers OrsquoReilly Media 2008 Disponıvel emhttponairadobecomfilesAIRforJSDevPocketGuidepdf ace-dido em Abril de 2008

[Con99] Jim Conallen Modeling Web Application Architectures with UML Junho1999 Disponıvel em httpwwwumlorgcnUMLApplicationpdf

webappspdf acedido em Maio de 2008

[Ent07] Entrust What is a public key information 2007 Disponıvel em http

wwwentrustcompkihtm acedido em Junho de 2008

[Gar05] Jesse James Garret Ajax A new approach to web applicationsFebruary 2005 Disponıvel em httpwwwadaptivepathcomideas

essaysarchives000385php acedido em Marco de 2008

[Greon] Philip Greenspun Philip and Alexrsquos Guide to Web Publishing 2003(last revision) Disponıvel em httpphilipgreenspuncompandaacedido em Junho de 2008

[Gro02a] App Design Group Thick vs thin client comparison 2002 Disponıvelem httpwwwdonjacobsvwcomimagesweekendspecials

Thick-vs-Thinpdf acedido em Junho de 2008

57

REFERENCIAS

[Gro02b] Technical Research Group Thin Client Tecnhology - WhitePaper 2002 Disponıvel em httpwwwpicktrgcompubs

thinclientwhitepaperpdf acedido em Junho de 2008

[Gro08] Miniwatts Marketing Group World internet usage March 2008Disponıvel em httpwwwinternetworldstatscomstatshtm ace-dido em Abril de 2008

[Hic08] Ian Hickson HTML 5 Draft Recommendation 2008 Disponıvelem httpwwwwhatwgorgspecsweb-appscurrent-work ace-dido em Marco de 2008

[Kha] Olga Kharif Top 10 municipal wifi plans Disponıvel em http

imagesbusinessweekcomss0608muni_wifiindex_01htm ace-dido em Marco de 2008

[Lab07] Mozilla Labs Prism Outubro 2007 Disponıvel em httplabs

mozillacom200710prism acedido em Marco de 2008

[Loo06] Chris Loosley Rich Internet ApplicationsDesign MeasurementandManagement Challenges 2006 Disponıvel em httpwwwkeynote

comdocswhitepapersRichInternet_5pdf acedido em Maio de2008

[Mic08] Microsoft Introduction to Occasionally Connected Applications us-ing Sync Services for ADONET 2008 Disponıvel em httpmsdn

microsoftcomen-ussyncbb887608aspx acedido em Junho de2008

[Nao08] Erica Naone Offline web applications Abril 2008 Disponıvelem httpwwwtechnologyreviewcomread_articleaspxch=

specialsectionsampsc=emerging08ampid=20245 acedido emAbril de 2008

[NJN00] Jason Nieh Yang S Jae and Naomi Novik A comparison of thin-clientcomputing architectures 2000 Disponıvel em httpwwwnclcs

columbiaedupublicationscucs-022-00pdf acedido em Maio de2008

[OrsquoR06] Tim OrsquoReilly Web 20 compact definition Trying again Dezembro2006 Disponıvel em httpradaroreillycomarchives200612

web-20-compact-definition-tryihtml acedido em Marco de 2008

[OrsquoR09] Tim OrsquoReilly What is Web 20 Design patterns and business modelsfor the Next Generation of Software 20053009 Disponıvel emhttpwwworeillynetcompubaoreillytimnews200509

30what-is-web-20html acedido em Marco de 2008

[Rus06] Alex Russel Comet Low latency data for the browser March Marco2006 Disponıvel em httpalexdojotoolkitorgp=545 acedidoem Marco de 2008

58

REFERENCIAS

[Sad97] Darleen Sadoski Clientserver software architecturesndashan overviewAgosto 1997 Disponıvel em httpwwwseicmuedustr

descriptionsclientserver_bodyhtml acedido em Junho de2008

[Sch96] George Schussel Clientserver past present and future 1996

[Smi07] Kevin C Smith Css filters - will the browser apply the rule July 2007Disponıvel em httpcentriclecomrefcssfilters acedido emMarco de 2008

[vK08] Anne van Kesteren The XMLHttpRequest Object W3C Work-ing Draft 15 Abril 2008 Disponıvel em httpwwww3orgTR

XMLHttpRequest acedido em Abril de 2008

[Wil06] Greg Wilkins Why ajax comet July Julho 2006 Disponıvel emhttpwwwwebtidecomdownloadswhitePaperWhyAjaxhtml ace-dido em Abril de 2008

59

REFERENCIAS

60

Anexo A

Screenshots

Algumas imagens de aplicacoes que utilizam funcionalidades offline ilustrativasda tecnologia abordada neste documento

Figura A1 Dialogo apresentado ao utilizador na primeira activacao das funcionalidadesoffline no Google Docs amp Spreadsheets

61

Screenshots

Figura A2 Na activacao das funcionalidades offline e tambem oferecida a possibilidadeda criacao de alguns atalhos por exemplo no ambiente de trabalho

Figura A3 O Google Docs mantem a todo o momento a possibilidade de alteracao destasdefinicoes ou da anulacao dos servicos offline para um dado computador

62

Screenshots

Figura A4 Apos a instalacao do Gears qualquer visita ao Remember The Milk despoletauma sincronizacao que ocorre automaticamente e sem necessidade de intervencao por partedo utilizador

Figura A5 Apos completar a sincronizacao de dados mesmo que a ligacao a Internetseja perdida o Remember the Milk continua disponıvel no browser (com excepcao dasfuncionalidades que pela sua natureza exigem uma ligacao como por exemplo partilhade tarefas e envio de convites)

63

Page 13: O ine Web Applications

LISTA DE FIGURAS

46 A pagina inicial do WOW apresenta um resumo das ultimas ordensde trabalho enviadas e recebidas Na imagem pode-se observar atransicao do estado online para offline 44

47 Ilustracao do funcionamento do Gears numa web application que uti-liza um motor Ajax Os pedidos HTTP ou HTTPS podem ser inter-ceptados e tratados localmente ou podem ser feitos a uma maquinaremota consoante se verificarem ou nao as condicoes expressas noponto 311 E representado um acesso a uma base de dados local(fornecida pelo Gears) mas a sua utilizacao e opcional 45

48 Neste exemplo do modo ldquoaplicacao deciderdquo o teste da ligacao e feitoe feito a cada cinco segundos O resultado deste teste nao reflectesempre o estado real da aplicacao podendo levar a aplicacao a tercomportamentos indesejaveis Na figura assinala-se um perıodo detempo no qual a representacao interna do estado da ligacao nao cor-responde a realidade 46

49 Pagina de visualizacao do detalhe de uma ordem de trabalho 47410 Esquema UML que expressa os casos de uso do WOW Offline no

modo ldquoutilizador deciderdquo 48411 Esquema UML que expressa os casos de uso do WOW Offline no

modo ldquoutilizador deciderdquo 49412 Esquema UML que expressa o acto de recolha de dados em modo

online e offline recorrendo ao servidor (modo online) e ao sistemade armazenamento de dados local fornecido pelo Gears (modo offline) 50

A1 Dialogo apresentado ao utilizador na primeira activacao das funcional-idades offline no Google Docs amp Spreadsheets 61

A2 Na activacao das funcionalidades offline e tambem oferecida a possi-bilidade da criacao de alguns atalhos por exemplo no ambiente detrabalho 62

A3 O Google Docs mantem a todo o momento a possibilidade de alteracaodestas definicoes ou da anulacao dos servicos offline para um dadocomputador 62

A4 Apos a instalacao do Gears qualquer visita ao Remember The Milkdespoleta uma sincronizacao que ocorre automaticamente e sem ne-cessidade de intervencao por parte do utilizador 63

A5 Apos completar a sincronizacao de dados mesmo que a ligacao aInternet seja perdida o Remember the Milk continua disponıvel nobrowser (com excepcao das funcionalidades que pela sua naturezaexigem uma ligacao como por exemplo partilha de tarefas e enviode convites) 63

x

Lista de Tabelas

21 Comparacao entre thin-clients e fat-clients 7

31 Comparacao das funcionalidades oferecidas pelo Adobe AIR para asplataformas web e desktop 30

32 Resumo da utilizacao de tecnologias OWA em algumas web applica-tions consideradas na analise do estado da arte 31

xi

LISTA DE TABELAS

xii

Glossario

fat-client Cliente que nao depende totalmente de umservidor central para as suas actividadesde processamento e possui frequentementedispositivos de armazenamento de dados

6ndash8

thin-client Cliente que depende de um servidor centralpara as suas actividades de processamento

5ndash8

web application Sistema web (servidor rede HTTPbrowser) onde accoes do utilizador(navegacao e introducao de informacao)afectam o estado logico da aplicacao

i iii1ndash311ndash1517ndash1921ndash232728 3336ndash3842 5556

API Application Programming Interface 10 1718 2326 28

ASP Linguagem interpretada pelo servidorque permite a criacao de paginas webdinamicas Desenvolvida pela Microsoft

11

BSD Berkeley Software Distribution 28

CSS Cascading Style Sheets 12 2021 2324 46

DHTML Dynamic HyperText Transfer Protocol 24DOM Document Object Model 10 12

20 2324

DTD Document Type Definition 24

xiii

Glossario

ECMAScript Padrao de linguagem de programacaodefinido pela Ecma International que orig-inou o JavaScript e o JScript

24

Flash Conteudo interactivo de um ficheiro emformato SWF E desenvolvido pela Adobee visualizado atraves do Adobe FlashPlayer

21

Flex Framework baseada em XML e Action-Script desenvolvida pela Adobe para a pro-gramacao de Rich Internet Applications(RIA)

21

GPL GNU General Public License 23

HTML HyperText Markup Language 1 10ndash12 2124ndash2649

HTTP HyperText Transfer Protocol 2 26

JMS E uma API em Java que permite a troca demensagens entre componentes de software

42

JSON JavaScript Object Notation permite atroca de dados codificados num formatode texto de simples leitura

12 1828 34

LGPL GNU Lesser General Public License 23

Mozilla Prism Browser simplificado e ldquointerpretadorrdquo deeXtensible User Interface Language (XUL)(tambem designado por XULRunner) queacolhe web applications sem a interfacegrafica habitual de um browser

25

MPL Mozilla Public License 23

OCA Occasionally Connected Application 39OWA Offline Web Application i iii

2ndash515 1725 2628 3133 3651 5255 56

PDF Portable Document Format 21

xiv

Glossario

PHP Linguagem interpretada pelo servidorque permite a criacao de paginas webdinamicas mas que pode tambem ser in-vocada a partir da linha de comandos

11

pagina web estatica Pagina web que devolve sempre a mesmaresposta a todos os pedidos para todos osutilizadores e em qualquer contexto

5 9

RIA Rich Internet Applications web appli-cations que apresentam funcionalidadessemelhantes as desktop applications masque mantem a informacao no lado do servi-dor

5 1520 28

RSS Really Simple Syndication 27

SLA Service Level Agreement 40SQLite Segundo a definicao oficial SQLite is a

software library that implements a self-contained serverless zero-configurationtransactional SQL database engine

17

SSB Site Specific Browser 25SSL Secure Sockets Layer 22SWF ShockWave Flash 21

URL Uniform Resource Locator 18

VPN Virtual Private Network 38

WOW Work Orders Web Plataforma de gestaode ordens de trabalho e do seu fluxo de-senvolvida pela Critical Software SA

i iii28 3340ndash434551ndash5356

WWW World Wide Web 11 1214

XBL eXtensible Binding Language 24XHTML eXtensible HyperText Markup Language 12XML eXtensible Markup Language 11 12

23 2428

XSLT eXtensible Stylesheet Language Transfor-mation

12

XUL eXtensible User Interface Language xiv23ndash25

xv

Glossario

xvi

Capıtulo 1

Introducao

Neste capıtulo enquadra-se o tema do projecto introduzindo alguns dos conceitos

nos quais se baseia Apresentam-se as motivacoes ambito objectivos e a estrutura

deste documento

11 Enquadramento

A Internet foi originalmente concebida para ser um espaco de partilha de in-

formacao onde pessoas (atraves de maquinas) pudessem comunicar Na sua origem

as paginas eram estaticas constituıdas por texto formatado em HyperText Markup

Language (HTML) e ligadas entre si [BL96] Hoje encontramos conteudos cada vez

mais complexos e dinamicos incluindo som vıdeo ou streams multimedia [Loo06] e

em 2005 foi introduzido por [OrsquoR09] o termo Web 20

De acordo com [Greon] um website pode pertencer a uma ou varias das seguintes

categorias

bull Documento ndash um website essencialmente estatico onde alteracoes a uma

parte do conteudo nao tem implicacoes no seu comportamento

bull Base de dados ndash um directorio de informacao organizada em categorias

bull Aplicacao ndash um website dinamico que utiliza uma linguagem executada ou

interpretada do lado do servidor e que processa as accoes ou informacao in-

troduzida pelo utilizador para fornecer um servico ou nova informacao

A ultima destas categorias constitui aquilo que e normalmente designado por

web application O conceito utilizado ao longo deste documento e o mesmo que

o introduzido por Jim Coallen em [Con99] que define web application como um

1

Introducao

sistema web (servidor rede HyperText Transfer Protocol (HTTP) browser) onde

accoes do utilizador (navegacao e introducao de informacao) afectam o estado logico

da aplicacao A sua definicao tenta estabelecer que uma web application e um

sistema de software com estado de negocio1 e que a sua interface de interaccao com

o utilizador e distribuıdo atraves de um sistema web

12 Motivacao

A quantidade de informacao que e produzida e armazenada com recurso a es-

tas web applications disponıveis online tais como e-mail blogues ou mesmo docu-

mentacao tornam por vezes a disponibilidade de ligacao uma condicao necessaria

a produtividade e como consequencia desta barreira muitos potenciais utilizadores

opoem-se a adopcao de produtos web em detrimento das tradicionais desktop appli-

cations

Assegurar o acesso a uma ligacao de Internet e hoje muito mais facil A Internet

movel e ja uma realidade e encontra-se amplamente divulgada mas continuam a

existir diversas situacoes nas quais os utilizadores estao privados de uma ligacao

a Internet tais como uma viagem de metro ou de aviao ou quando se encontram

deslocados do seu paıs de origem e nao possuem nenhum plano de subscricao

Uma OWA consiste numa web application que para alem de manter todas as

caracterısticas anteriores se mantem disponıvel mesmo na ausencia de uma ligacao

a Internet e surge como uma tentativa de estreitar as barreiras existentes entre a

web e o desktop Isto significa que devera existir um mecanismo capaz de assegurar

a manutencao do estado logico da aplicacao quando a ligacao com o servidor e

quebrada permitindo ao utilizador continuar a utilizar a aplicacao e que sera capaz

de informar o servidor do estado em que a aplicacao se encontra quando a ligacao for

reposta A principal vantagem que advem desta possibilidade e evidente eliminar

a necessidade da existencia de uma ligacao a Internet para que a aplicacao possa ser

utilizada

Por outro lado a vontade de integracao de funcionalidades tıpicas das desktop

applications nas web applications foi um dos principais factores que impulsionou o

desenvolvimento deste conceito uma vez que obrigou a uma reflexao ldquopara alem

do browserrdquo e a uma adaptacao das arquitecturas existentes que permitisse ou o

acesso a funcionalidades disponibilizadas pelo sistema operativo ou pelo menos a

funcionalidades semelhantes Pretende-se com esta aproximacao tornar possıveis

interaccoes entre o desktop e o browser tais como arrastar um ficheiro para um

formulario web de upload de conteudos melhor suporte para o historico do clipboard

ou ainda o acesso ao sistema de ficheiros local Atingir estes objectivos reflecte-se

1NT business state

2

Introducao

num novo paradigma que reune as vantagens das web applications tais como os

updates instantaneos ou o facto de nao ser necessaria nenhuma instalacao e das

desktop applications como por exemplo persistencia no armazenamento de dados

acesso a funcionalidades do sistema operativo ou integracao e interaccao com outras

aplicacoes sejam elas web applications ou desktop applications

13 Ambito

Este projecto foi realizado na Critical Software SA no ambito do Mestrado

Integrado em Engenharia Informatica e Computacao (MIEIC) da Faculdade de En-

genharia da Universidade do Porto (FEUP) entre os meses de Fevereiro e Julho de

2008

14 Objectivos

Sao objectivos deste projecto

1 Estudar e documentar o tema das OWAs acompanhando os ultimos desenvolvi-

mentos nesta materia

2 Analisar o estado da arte fazendo uma analise crıtica e objectiva sobre as

diversas metodologias existentes

3 Implementar uma prova de conceito que permita a execucao offline de uma

web application documentando todo o processo

4 Estudar a possibilidade de permitir interaccao com a aplicacao (insercoes e

alteracoes aos dados) em modo offline

Em resumo o objectivo deste projecto foi estudar documentar e implementar

uma prova de conceito relacionada com o tema Offline Web Applications (OWA)

Este tema embora nao seja totalmente novo ganhou destaque ao longo do ano de

2007 com o surgimento de diversas ferramentas que se destinam a aproximar web

applications das desktop applications

15 Estrutura do documento

Este documento esta organizado em diferentes seccoes apresentando o projecto

numa sequencia logica organizada da seguinte forma

No capıtulo 1 faz-se uma breve apresentacao do conceito OWAs e do contexto em

que surge Apresenta-se tambem a estrutura do documento e definem-se os

termos e acronimos utilizados

3

Introducao

No capıtulo 2 faz-se uma descricao da evolucao das tecnologias que antecedem as

OWAs e das vantagens e desvantagens de cada uma como forma de enquadra-

mento

No capıtulo 3 analisa-se o estado da arte nesta materia Introduzem-se diversas

tecnologias directamente relacionadas com o tema deste projecto exemplos de

aplicacoes que as usam e as razoes que fundamentam as escolhas de tecnologias

efectuadas

O capıtulo 4 contem o desenvolvimento do projecto Analisa-se a plataforma

WOW de gestao integrada de ordens de trabalho a tecnologia escolhida e

a forma como foi utilizada para implementar a capacidade de execucao offline

O capıtulo 5 descreve os resultado obtidos comparando-os com as expectativas

iniciais do projecto e apresenta desenvolvimentos futuros e possibilidades de

continuacaoaplicacao do conhecimento adquirido

No capıtulo 6 apresentam-se as conclusoes

4

Capıtulo 2

Enquadramento do Projecto

Neste capıtulo apresenta-se um breve resumo da evolucao das arquitecturas de

software cliente-servidor e a forma como estas se comparam a evolucao da Inter-

net procurando estabelecer uma analogia entre o percurso de ambas as tecnolo-

gias Compara-se o comportamento e arquitectura dos thin-clients as paginas web

estaticas a evolucao dos fat-clients as paginas interactivas Web 20 e Ajax e

defende-se que as OWA constituem um proximo passo logico e evolutivo aproxi-

mando a web do desktop Referem-se ainda os principais factores que justificam a

importancia das OWAs e a estreita relacao que tem com as Rich Internet Application

(RIA)s

21 Evolucao das arquitecturas de software

Os termos thin-client e fat-client sao utilizados quer para descrever arquitecturas

logicas (de software) quer para descrever arquitecturas fısicas (de hardware) Neste

capıtulo excepto quando seja dada indicacao em contrario estes termos referem-se

sempre a uma arquitectura logica

Adicionalmente quando se trata de arquitecturas cliente-servidor pode-se estu-

dar a arquitectura desenvolvida do sistema como um todo da arquitectura do servi-

dor ou da arquitectura do cliente Para evitar equıvocos em especial na seccao 213

especifica-se em cada caso qual o sistema estudado

211 Thin-clients

Um thin-client e um computador cliente ou software cliente que no contexto

de uma arquitectura cliente-servidor depende de um servidor central para as suas

5

Enquadramento do Projecto

actividades de processamento e proporciona um canal de entrada e saıda de in-

formacao entre o utilizador e o servidor remoto Este termo quando aplicado a

hardware refere-se habitualmente a um computador que se destina a ser utilizado

como cliente de rede sem armazenamento local e com capacidade de processamento

reduzida [Gro02b] mas o conceito que aqui se analisa refere-se a uma arquitectura

de software que remonta ao inıcio das aplicacoes cliente-servidor

No inıcio da historia da computacao terminais ligavam-se directamente a main-

frames responsaveis por todo o processamento Nesta arquitectura era necessario

desenvolver duas aplicacoes distintas uma aplicacao central no servidor (main-

frame) responsavel pela gestao de toda a informacao e por todas as operacoes de

comunicacao e uma aplicacao de visualizacao instalada no cliente (terminal) O

papel destes terminais era apenas disponibilizar ao utilizador um meio de comu-

nicacao (entrada e saıda) e apresentacao dos resultados do servidor Nao tinham

um papel activo no calculo nem na logica de negocio e frequentemente nao tinham

tambem nenhum mecanismo de armazenamento de dados

Como vantagens esta arquitectura apresenta uma reduzida necessidade de con-

figuracao e manutencao do lado do cliente Uma vez que o centro do processamento

e manipulacao de dados ocorre no servidor existe tambem uma centralizacao da

informacao [NJN00] que introduz um ponto crıtico de falha1 Actualizacoes e novas

funcionalidades sao faceis de distribuir uma vez que requerem apenas alteracoes no

servidor [Gro02a]

212 Fat-clients

Contrastando com os thin-clients nesta arquitectura os clientes implementam

ja uma parte da logica de negocio e sao responsaveis pelo processamento de dados

Estes fat-clients vieram responder a necessidade crescente de aplicacoes com um

nıvel de interactividade e capacidade de configuracao maior que as oferecidas pela

arquitectura thin-client descrita na seccao 211 Apesar de manterem a sua de-

pendencia do servidor podem tambem ser executados sem uma conexao activa uma

vez que dispoe de armazenamento de dados local o que lhes confere a capacidade

de persistencia de dados e do estado de execucao entre cada sessao

Foi disponibilizando este controlo sobre o estado da aplicacao bem como acesso

a recursos locais (por exemplo sistema de ficheiros e perifericos) que surgiram as

primeiras verdadeiras desktop applications No entanto cada cliente tinha que ser

separadamente instalado no computador pessoal de cada utilizador que pretendesse

utilizar ou interagir com a aplicacao e uma actualizacao ao servidor implicava in-

variavelmente uma actualizacao manual tambem no cliente Uma vez que nem todos

1NT single point of failure

6

Enquadramento do Projecto

Thin-clients Fat-clientsNao toma parte no processamento dedados nem possui acesso ao sistema deficheiros

Participa activamente no processa-mento de dados recorrendo ao sis-tema de armazenamento local para ar-mazenamento de dados

Nao mantem registo do estado logicoda aplicacao entre duas sessoes de uti-lizacao

O acesso ao armazenamento localpermite-lhe manter registo do estadologico da aplicacao entre duas sessoes

O thin-client nao necessita de qualquerinstalacao estando ldquopronto a utilizarrdquo

E geralmente necessario instalar aaplicacao para poder interagir com oservidor

Qualquer update no servidor reflecte-seimediatamente por todos os clientes

Embora a aplicacao cliente possa aler-tar para existencia de novas versoes asactualizacoes tem que ser manualmenteinstalados pelo cliente

O software do cliente destina-se apenasa apresentacao de dados e comunicacaocom o servidor sendo portanto de sim-ples implementacao

Como o software do cliente toma parteactiva no processamento de dadosa sua implementacao requer cuidadosadicionais

Grande mobilidade uma vez que todaa informacao e mantida no servidor

Parte da informacao podera estar ape-nas do lado cliente pelo que existemalgumas restricoes a sua mobilidade

Tabela 21 Comparacao entre thin-clients e fat-clients

os utilizadores actualizam regularmente as suas aplicacoes o servidor tem que estar

preparado para lidar com versoes antigas2 ou descontinuar os seus servicos a uma

parte da sua comunidade de utilizadores ate que estes actualizem os seus sistemas

Como os utilizadores passam a utilizar os seus recursos locais para armazenamento

de dados as alteracoes que nao sejam sincronizadas com o servidor estao apenas

disponıveis nos seus computadores pessoais o que introduz uma restricao a mobili-

dade

Pode-se afirmar que as vantagens dos thin-clients sao as desvantagens dos fat-

clients e que as vantagens dos fat-clients sao as vantagens dos thin-clients tal como

se ilustra na Tabela 21

213 Arquitecturas cliente-servidor

Introduzidos os termos thin-client e fat-client interessa reafirmar que ambos

podem ser vistos como arquitecturas cliente-servidor Um cliente define-se como

um solicitador de servicos e um servidor como um prestador de servicos tal como

definido por [Sch96] e [Sad97]

2NT backward compatibility

7

Enquadramento do Projecto

As arquitecturas cliente-servidor sao categorizadas pela modularizacao com que

sao desenhadas sendo consideradas as seguintes camadas

1 Interface grafica (front-end) atraves da qual os utilizadores interagem com

a aplicacao Quando este modulo e implementado separadamente dos outros

dois constitui uma aplicacao thin-client por si so uma vez que nao implementa

regras de negocio (embora possa definir validacoes de formularios de insercao de

dados por exemplo) A informacao introduzida pelo utilizador e enviada para

o servidor que processa o seu pedido e retorna uma resposta Este processo

repete-se ate que o utilizador atinja o seu objectivo ou se desligue do sistema

2 A logica de negocio tambem designada por camada intermedia que imple-

menta as regras de aceitacao e validacao de todos os dados introduzidos pelo

utilizador E tambem a plataforma de comunicacao que une a camada superior

de visualizacao com a camada de acesso a dados

3 A camada de dados inclui quer o sistema de persistencia de dados onde sao

armazenados os dados relevantes como tambem os mecanismos necessarios

para a sua pesquisa seleccao e alteracao

Os thin-clients quando observados no seu conjunto de cliente e servidor podem

ser vistos quer como sistemas de duas camadas quer como sistemas de tres camadas

dependendo apenas da forma como o servidor for implementado No caso de na

implementacao do servidor nao se distinguir a camada de acesso a dados da camada

da logica de negocio sao designados por sistemas de duas camadas Caso seja feita

esta distincao sao designados por sistemas de tres camadas Ambos os casos sao

ilustrados na Figura 21

Historicamente os fat-clients eram implementados numa arquitectura em duas

camadas Possuıam apenas um modulo de visualizacao de dados designado por

camada de interface e um modulo que implementava toda a logica de negocio e

regras de acesso a base de dados No entanto com a introducao de ligacoes mais

rapidas e de computadores pessoais com maior capacidade de processamento e so-

bretudo devido a complexidade crescente das aplicacoes a logica de negocio e a

camada de acesso a dados tornaram-se independentes Este modelo e designado por

arquitectura em tres camadas e e ilustrado na Figura 22

22 Evolucao na Internet

Ao analisar a evolucao das arquitecturas das aplicacoes desenvolvidas para a

Internet podemos encontrar um paralelismo com a historia da arquitectura de soft-

ware

8

Enquadramento do Projecto

Figura 21 Arquitectura de um sistema thin-client em duas camadas (a esquerda) e emtres camadas (a direita) Note-se a inclusao do servidor (mainframe) na definicao dascamadas desta arquitectura devido a forte dependencia cliente-servidor

221 Paginas web estaticas

Uma pagina web estatica devolve sempre a mesma resposta a todos os pedidos

para todos os utilizadores e em qualquer contexto utilizando o hipertexto como

forma de ligacao entre diversas paginas estaticas

A informacao e armazenada num servidor e o papel do cliente e apenas a apre-

sentacao da informacao Esta forma de disponibilizacao de informacao pode assim

ser comparada com os thin-clients descritos na seccao 211 o utilizador acede a

um website estatico para visualizar informacao sem que o cliente tome parte no

processamento A unica diferenca e que no caso da web estatica a informacao ap-

resentada e sempre a mesma enquanto que nos thin-clients era frequente existir a

possibilidade de insercao de dados no cliente e apos o seu processamento servidor

nova informacao poderia ser apresentada O hipertexto e utilizado para ligar as

paginas entre si numa rede de conteudos relacionados e a navegacao sıncrona era

feita atraves de cliques do rato a cada clique uma nova pagina era apresentada

Este modelo sıncrono e ilustrado na Figura 23

222 Paginas web interactivas e paginas web dinamicas

O JavaScript e uma linguagem interpretada de scripting que tem os browsers

como principal ambiente de acolhimento Os browsers utilizam uma Application

9

Enquadramento do Projecto

Figura 22 Arquitectura de um fat-client em duas camadas (a esquerda) e em tres camadas(a direita)

Programming Interface (API) publica para criar ldquoobjectosrdquo responsaveis por reflectir

e disponibilizar o Document Object Model (DOM) para o motor de JavaScript

A utilizacao mais frequente desta linguagem e a escrita de funcoes que sao em-

bebidas ou incluıdas em paginas web e que interagem com o DOM Uma vez que o

JavaScript e executado localmente (na maquina do cliente e nao no servidor) e capaz

de responder rapidamente a accoes do utilizador tornando a execucao de aplicacoes

no browser mais fluıdas o JavaScript pode tambem detectar accoes do utilizador

que o HTML nao pode tal como o pressionar de uma tecla

Em Dezembro de 1995 a Netscape Communications adicionou suporte para o

JavaScript no browser Netscape Navigator3 e em Agosto de 1996 o browser Internet

Explorer4 da Microsoft passou a tambem a suportar uma versao semelhante desta

linguagem (hoje todos os principais browsers suportam esta tecnologia)

Esta inovacao permitiu tornar os websites mais interactivos mas a sua utilizacao

esteve confinada apenas a este proposito durante um longo perıodo As paginas

passaram a responder activamente a accoes do utilizador (sendo uma das utilizacoes

3Netscape Communications ndash httpbrowsernetscapecom4Microsoft Internet Explorer ndash httpwwwmicrosoftcomwindowsproductswinfamilyie

10

Enquadramento do Projecto

mais vulgares a validacao de formularios) mas continuaram essencialmente estaticas

O JavaScript ainda nao era nesta altura utilizado para processar dados

Tambem nesta altura (1995ndash96) surgiram linguagens server-side como o PHP

Hypertext Preprocessor (PHP) e Active Server Pages (ASP) e o servidor passou a ter

um processamento de dados introduzidos pelo utilizador mais activo Generalizaram-

se as paginas dinamicas capazes de responder a insercao de dados ou outros pedidos

determinados por accoes do utilizador As paginas tornaram-se aplicacoes web ap-

plications

Uma definicao tradicional de web application e um conjunto de paginas web

logicamente agrupadas e geridas por uma unica entidade que tem como pontos de

entrada formularios de insercao de dados (web forms) Uma web application nao e

mais do que uma aplicacao que e acedida atraves de um browser Tem geralmente

uma arquitectura logica em tres (interface logica de negocio e camada de dados)

camadas e estao armazenadas num servidor

Ha dois tipos de web applications

bull Orientadas a apresentacao Sao web applications que geram paginas web in-

teractivas constituıdas por varios tipos de linguagens de anotacao (por exem-

plo HTML eXtensible Markup Language (XML)) e que apresentam conteudo

dinamico como resposta a pedidos efectuados pelo utilizador

bull Orientadas aos servicos Uma web application orientada aos servicos imple-

menta o ponto de acesso para um ou mais de um web service Sao geralmente

clientes de service oriented web applications

Uma vantagem significativa de implementar uma web application de forma a

suportar as funcionalidades padrao dos browsers e que estas terao o mesmo com-

portamento independentemente da plataforma e do browser a partir do qual serao

acedidas No entanto diferentes implementacoes de browsers devido a diferentes

interpretacoes dos padroes definidos tornam por vezes esta tarefa um pouco mais

complicada existindo inclusivamente na web guioes de compatibilidade para os difer-

entes browsers como [Smi07]

223 Web 20 e Ajax

O termo web 20 descreve uma tendencia de utilizacao e de design observada

na World Wide Web (WWW) com o objectivo de melhorar a criatividade partilha

de informacao e principalmente a colaboracao entre utilizadores Estes conceitos

levaram ao desenvolvimento e evolucao de comunidades online tais como redes so-

ciais wikis e blogues

11

Enquadramento do Projecto

O termo tornou-se mais conhecido apos a primeira conferencia OrsquoReilly Media

Web 20 em 2004 e apesar de sugerir uma nova versao da WWW nao se refere a

qualquer evolucao tecnologica mas apenas a alteracoes a forma como os utilizadores

se servem da web De acordo com Tim OrsquoReilly [OrsquoR06] ldquoWeb 20 e uma revolucao

na industria do software causada pela adopcao da web como uma plataforma e pela

tentativa de entendimento das regras para o sucesso nesta nova plataformardquo

O desenvolvimento da Web 20 serve-se muitas vezes de um outro conceito Ajax

O conceito que hoje conhecemos como Ajax muitas vezes incorrectamente de-

scrito como uma tecnologia foi originalmente criado para permitir o desenvolvimento

de web applications que se assemelhassem ainda mais a aplicacoes de desktop Este

conceito foi melhor descrito por [Gar05] como um conjunto de varias tecnologias

que podem ser utilizadas para melhorar a experiencia do utilizador de uma dada

web application introduzindo a capacidade assıncrona de envio de pedidos ou da

recepcao assıncrona de respostas As tecnologias mais frequentemente envolvidas

sao

bull eXtensible HyperText Markup Language (XHTML) e Cascading Style Sheets

(CSS) padrao para a apresentacao

bull interaccao dinamica atraves do DOM

bull troca e manipulacao de dados utilizando XML e eXtensible Stylesheet Lan-

guage Transformation (XSLT) ou JavaScript Object Notation (JSON)

bull pedidos assıncronos utilizando XMLHttpRequest [vK08]

bull JavaScript utilizado para integrar todas estas tecnologias

E importante frisar que o Ajax nao e um produto nem uma tecnologia E um

termo que descreve a utilizacao de um conjunto de tecnologias para o desenvolvi-

mento de web applications com um elevado grau de interactividade Comparativa-

mente as web applications tradicionais o Ajax introduz uma camada de visualizacao

diferente em tres importantes pontos

1 Do lado do cliente existe um motor que serve de intermediario entre a interface

da aplicacao e o servidor

2 A actividade do utilizador despoleta chamadas JavaScript em vez de um pedido

de pagina directamente ao servidor

3 Informacao codificada em XML em vez de paginas HTML e trocada entre o

servidor e o cliente

12

Enquadramento do Projecto

Isto significa que as paginas que utilizam Ajax contem um motor do lado do

cliente composto por um conjunto de funcoes JavaScript responsavel pela comu-

nicacao com o servidor e por actualizar a interface com o resultado dessa mesma

comunicacao

Na Figura 23 ilustra-se a natureza assıncrona do Ajax quando comparada com

as web applications tradicionais Como se pode observar adicionando um mecan-

ismo Ajax a uma web application eliminam-se diversos tempos de espera associados

a comunicacoes com o servidor uma vez que a interface nao fica ldquobloqueadardquo a es-

pera da resposta Obtem-se assim aplicacoes com um comportamento mais fluido

eliminando tempos de espera entre cada ldquocliquerdquo e melhorando a experiencia do

utilizador

23 Offline Web Applications

A informacao grafica (bem como folhas de estilo e scripts) tais como as ima-

gens que constituem o visual de uma web application e ja tratada de forma especial

pelos cada vez mais avancados sistemas de cache (armazenamento temporario) dos

browsers Mas estes nao sao ainda capazes de guardar conteudo criado pelo uti-

lizador nem de apresentar informacao independentemente do estado da ligacao

Numa altura onde se fala de servicos de Internet wireless municipalizados [Kha]

comunicacoes 3G e ligacoes de banda larga a alta velocidade a ligacao a rede global

continua a nao estar permanentemente disponıvel para os utilizadores Na WWW

encontra-se uma importante parte da informacao e das aplicacoes utilizadas para

criar e editar conteudos Por vezes informacao vital para a produtividade pode

desaparecer subitamente do mapa de acesso de um utilizador quando este entra no

metro num aviao ou mesmo quando se desloca para uma cidade ou paıs diferente

do habitual onde nao subscreve um plano de acesso que lhe garanta a ligacao

Permitir o acesso offline a estes recursos assume assim a sua importancia porque

permitira estender o alcance da informacao a locais onde nunca esteve antes e per-

mitira tambem melhorar o desempenho das web applications colocando informacao

mais perto dos utilizadores reduzindo a transferencia de dados apenas ao essencial

24 Comparacao

Nas evolucoes descritas neste capıtulo 2 pode-se observar que existe um par-

alelismo entre a evolucao das arquitecturas tradicionais cliente-servidor e a evolucao

a que se assiste na web O comportamento e arquitectura dos thin-clients assemelha-

se ao das paginas estaticas no sentido em que o browser nao toma parte em qualquer

13

Enquadramento do Projecto

processamento e serve apenas como uma plataforma de interaccao com o servidor

tal como os clientes descritos na seccao 211

A sua proxima evolucao os fat-clients trouxeram parte da capacidade de pro-

cessamento para o lado do cliente Na web foi tambem esta a inovacao tecnologica

a que se assistiu com a evolucao das tecnologias que permitiram a criacao de ver-

dadeiras aplicacoes e com a introducao do Javascript no browser dando ao cliente

a capacidade de processamento de dados A necessidade da separacao do codigo

em camadas logicas advem da crescente complexidade das web applications Esta

pratica permite entre outras coisas melhorar o processo de desenvolvimento e a

capacidade de manutencao de uma aplicacao

Os fat-clients tem tambem a capacidade de armazenamento de dados o que

permite a persistencia de informacoes entre duas sessoes e que algumas operacoes

sejam executadas sem a necessidade de comunicacao com o servidor Este facto pode

tambem ser uma realidade nas web applications com a adopcao das tecnologias OWA

Neste momento assiste-se a uma utilizacao cada vez maior da web como uma

plataforma de desenvolvimento A capacidade de cooperacao na edicao de conteudos

e a mobilidade proporcionada por esta plataforma sao os principais factores que

alimentam esta mudanca e pela primeira vez as aplicacoes tradicionais tem com-

peticao vinda de web applications A prova do reconhecimento da web como plataforma

de desenvolvimento pode ser retirada da aposta de empresas como a Adobe e Mi-

crosoft que lancaram publicamente ferramentas web complementares a produtos

seus tradicionalmente associados ao desktop ndash Acrobatcom5 e Microsoft Office

Live6 Dotar estas web applications da capacidade de execucao offline significa

aproximar a web e o desktop reunindo ldquoo melhor de dois mundosrdquo

As vantagens da mobilidade possıvel atraves da web a cooperacao na criacao e

edicao de conteudos e a possibilidade de utilizar aplicacoes sempre actualizadas e

sem necessidade de instalacao sao algumas das principais vantagens que promovem

esta mudanca que devido as preocupacoes associadas a usabilidade e experiencia do

utilizador esta fortemente associada ao desenvolvimento de Rich Internet Applica-

tion (RIA)s

5Adobe Acrobatcom httpwwwacrobatcom6Microsoft ndash httpsmallbusinessofficelivecom

14

Enquadramento do Projecto

Figura 23 Comparacao do modelo de web aplications sıncrono paginas estaticas e in-teractivas abordados nas seccoes 221 e 222 com o modelo de web applications Ajax(assıncrono) abordado na seccao 223 Figura adaptada de http www adaptivepath

com

15

Enquadramento do Projecto

16

Capıtulo 3

Estado da arte

Apesar de o conceito das OWAs nao ser absolutamente novo as tecnologias que

o suportam sao recentes Neste capıtulo descrevem-se quatro tecnologias que foram

tidas como principais candidatas para o desenvolvimento deste projecto Descrevem-

se ainda alguns exemplos de web applications que disponibilizam actualmente fun-

cionalidades offline e o processo da escolha da tecnologia a utilizar neste projecto

31 Gears

O Gears1 e uma extensao as funcionalidades do browser introduzido pelo Google

que tem como principal objectivo tornar possıvel a visualizacao de paginas de Inter-

net mesmo sem uma conexao disponıvel Encontra-se disponıvel para as platafor-

mas Windows Macintosh e Linux e oferece uma API de Javascript que permite

a scripts aceder a um mecanismo de armazenamento local baseado numa base de

dados SQLite

311 Arquitectura

Esta ferramenta e constituıda por tres componentes principais

bull LocalServer mdash Intercepta pedidos de paginas web e serve-as localmente

bull Database mdash Uma base de dados relacional construıda sobre SQLite

bull WorkerPool mdash Permite executar operacoes de computacao de uma forma

assıncrona sem afectar a capacidade de resposta e fluidez de execucao da web

application Assemelham-se a processos

1Google Inc ndash Mais informacao em httpgearsgooglecom

17

Estado da arte

LocalServer

O modulo LocalServer e uma cache de Uniform Resource Locators (URLs)

controlada pela web application Quando nao existe uma ligacao a Internet e e

feito um pedido para um URL presente nesta cache o LocalServer intercepta-o e

responde ao pedido localmente a partir do disco rıgido do utilizador A aplicacao

pode utilizar dois tipos diferentes de armazenamento local de URLs

bull ResourceStore ndash serve para capturar URLs utilizando exclusivamente a API

de Javascript disponibilizada para o efeito Uma aplicacao podera criar e

utilizar diversos ResourceStores simultaneamente para capturar ficheiros de

dados que necessitam de ser enderecados por um URL tal como um ficheiro

PDF ou uma imagem

bull ManagedResourceStore ndash serve para capturar um conjunto de URLs que estao

relacionados e que sao declarado num ficheiro de manifesto (especificado em

JSON) e que sao automaticamente actualizados O ManagedResourceStore

permite que o conjunto de recursos necessarios para correr uma web application

seja capturado e mantido actualizado automaticamente

A principal diferenca entre estes dois tipos de armazenamento de URLs e a forma

como sao actualizados os seus conteudos Os conteudos de um ManagedResourceStore

sao actualizados sempre que a versao contida no ficheiro de manifesto for alterada

enquanto que os conteudos de um ResourceStore nunca sao actualizados automati-

camente mas apenas quando for explicitamente ordenado pela aplicacao

O LocalServer e capaz de interceptar e servir localmente pedidos de HTTP e

HTTPS sempre que se reunam as seguintes condicoes

1 O URL encontra-se armazenado num ResourceStore ou ManagedResourceStore

2 O sistema de armazenamento local encontra-se activo (enabled = true) Se

o sistema de armazenamento local tiver o atributo requiredCookie o pedido

devera conter um cookie que lhe corresponda

O LocalServer nao necessita de monitorizar o estado da ligacao para atender aos

pedidos Na verdade sempre que as condicoes previamente enunciadas se verificarem

o LocalServer interceptara os pedidos e independentemente do estado da ligacao

a Internet servi-los-a a partir do disco rıgido local Cabera a aplicacao definir qual

o modo em que pretende executar um pedido (online ou offline) definindo o valor

de verdade da propriedade enabled

18

Estado da arte

Database

O modulo Database permite guardar dados da web application assegurando a

sua persistencia Os dados sao guardados de forma relacional no disco rıgido do uti-

lizador2 de acordo com o modelo de seguranca estabelecido pelo Gears3 significando

que uma aplicacao nao pode aceder a conteudos fora do seu domınio

WorkerPool

Nos web browsers uma operacao pesada de computacao pode tornar a interface

lenta e tornar menos agradavel a experiencia do utilizador O modulo WorkerPool

permite correr operacoes em background sem bloquear a interface com o utilizador

Os scripts executados numa WorkerPool nao activam os mecanismos de seguranca

do browser que mostram a mensagem ldquoA script on this page may be busy or may

have stopped respondingrdquo

O WorkerPool comporta-se como um conjunto de processos em vez de threads

Os Workers nao partilham qualquer estado de execucao o que significa que uma

alteracao a uma variavel num Worker nao afecta em nada a execucao de outro

Worker Alem disso os Workers nao herdam automaticamente nenhum codigo dos

seus pais Cada Worker e membro de um WorkerPool e os Workers podem in-

teragir entre si enviando mensagens em formato de texto ou JSON No entanto ha

tambem algumas limitacoes os Workers nao tem acesso ao DOM e objectos como

window ou document nao se encontram acessıveis Isto e consequencia de os Workers

nao partilharem o estado de execucao Mas tem acesso a todas as funcoes built-in

do Javascript A maioria das funcionalidades do Gears pode tambem ser acedida

atraves de uma variavel global especial definida como googlegearsfactory Para

outras funcionalidades especıficas os Workers podem ldquopedirrdquo a pagina principal para

continuar a execucao atraves do envio de mensagens

Outras funcionalidades

bull HttpRequest ndash Este modulo implementa a especificacao W3C XmlHttpRe-

quest definida em [vK08] tornando-a disponıvel para os workers e para a

pagina principal

bull Timer ndash Este modulo implementa a especificacao de timers tal como descrito

por [Hic08] e torna-os disponıveis para os workers e para a pagina principal

2Consultar httpcodegooglecomapisgearsapi_databasehtmldirectories3Consultar httpcodegooglecomapisgearssecurityhtml

19

Estado da arte

bull Factory ndash Esta classe e utilizada para instanciar todos os outros objectos da

API do Gears atraves do seu metodo create Este metodo pode ser utilizado

com os seguintes parametros

ndash betadatabase

ndash betahttprequest

ndash betalocalserver

ndash betatimer

ndash betaworkerpool

312 Goggle Gears em dispositivos moveis

O Gears esta tambem disponıvel em dispositivos Windows Mobile 5 e 6

Os dispositivos moveis estao pela sua natureza frequentemente desconectados

da Internet Mesmo quando possuem uma ligacao as latencias na transferencia de

dados em redes moveis tornam as aplicacoes pouco fluıdas mas o Gears permite

ultrapassar este obstaculo

O Gears funciona exactamente da mesma forma em dispositivos moveis equipados

com o Windows Mobile 5 e 6 como num computador comum Se uma aplicacao tiver

sido implementado com suporte para o Gears entao tambem estara preparada para

ser executada num dispositivo movel mas as limitacoes dos browsers disponıveis

para dispositivos moveis tem que ser consideradas Isto significa prever as condicoes

que permitam uma boa usabilidade devido aos pequenos ecras destes dispositivos

bem como o seu suporte limitado dos padroes do DOM CSS e JavaScript

32 Adobe AIR

O Adobe AIR4 e um runtime compatıvel com diversos browsers e sistemas opera-

tivos que pretende dar aos programadores a possibilidade de combinar diversas tec-

nologias de producao de conteudos para a Internet no desenvolvimento de Rich Inter-

net Application (RIA)s O Adobe AIR mantem uma relacao com o browser mas es-

tende as suas capacidades e tecnologias permitindo o desenvolvimento de aplicacoes

tambem para o ambiente de trabalho com janelas em tudo semelhantes as do sis-

tema operativo Segundo a Adobe o objectivo e complementar o browser dando

aos utilizadores (mas essencialmente aos programadores e equipas de desenvolvi-

mento) a escolha sobre como distribuir as suas aplicacoes Para este efeito o Adobe

AIR tem uma aproximacao diferente do Gears Em vez de ldquoestenderrdquo o browser

acrescentando-lhe funcionalidades o AIR permite tambem o desenvolvimento de

4Adobe - httpwwwadobecomproductsair

20

Estado da arte

aplicacoes que se destinam a ser executadas fora do ambiente do browser mas uti-

lizando as tecnologias comuns da Internet (por exemplo HTML CSS JavaScript

Flash Flex)[CDGH08]

A utilizacao desta tecnologia permite utilizar o browser ou o proprio runtime

Adobe AIR como plataforma de execucao da aplicacao

Na Tabela 31 faz-se uma comparacao das funcionalidades disponıveis de acordo

consoante se escolha o browser ou o desktop como plataforma base para a aplicacao

Uma vez que as aplicacoes Adobe AIR na plataforma desktop tem um caracter

persistente (sao instaladas no computador do utilizador) o Adobe AIR tem um

modelo de seguranca que se assemelha com o das tradicionais aplicacoes desktop

[Ada08] Este modelo e analisado nas seccoes 321 e 322 O ambiente em que

e executado o browser e restringido a execucao de web applications que podem

ser de varias origens (incluindo de origens anonimas ou sem confianca) O Adobe

AIR proporciona acesso a capacidades como acesso a ficheiros que necessitam da

confianca do utilizador

bull HTML ndash O desenvolvimento de aplicacoes para o Adobe AIR pode ser feito

com recurso a tecnologias de HTML e Ajax comuns utilizando as linguagens

de markup existentes distribuıdas como texto e interpretadas em execucao

(runtime)

bull Flash ndash Outra alternativa sera a utilizacao da linguagem Flash Permite a

renderizacao de graficos vectoriais e audiovıdeo com suporte nativo Utiliza

ActionScript para adicionar maior interactividade com o utilizador

bull Flex ndash O Flex e uma framework open source para o desenvolvimento de RIAs

usando Flash As aplicacoes Flex sao na realidade Flash sendo a principal

diferenca o ambiente de desenvolvimento

Como resultado uma aplicacao AIR podera ser implementada

bull Baseada em Flash ou Flex (aplicacoes cujo conteudo base e em ShockWave

Flash (SWF))

bull Baseada em Flash ou Flex tambem com HTML ou Portable Document Format

(PDF) Aplicacoes cujo conteudo de base e em FlashFlex (SWF) com HTML

(HTML JavaScript CSS) ou conteudo PDF incluıdo

bull Baseada em HTML Aplicacoes cujo conteudo base e em HTML Javascript

CSS

bull Baseada em HTML utilizando tambem FlashFlex ou PDF

21

Estado da arte

Os utilizadores interagem com uma aplicacao AIR da mesma forma que interagem

com outras aplicacoes com janelas nativas do seu sistema operativo O runtime e

instalado uma vez no computador do utilizador e a partir desse momento todas as

aplicacoes AIR terao o mesmo aspecto que qualquer outra aplicacao para o desktop

321 Seguranca

Permitir que uma web application aceda ao disco de armazenamento do utilizador

pode comprometer seriamente a sua seguranca Neste sentido o Adobe AIR tem

suporte para assinaturas digitais (Secure Sockets Layer (SSL)) que podem ser com-

pradas pelas equipas de desenvolvimento que o desejem e cujos certificados serao

apresentados ao utilizador no momento da instalacao Um outro aspecto ainda

relativo a seguranca e o mecanismo de isolamento de cada ambiente (sandbox )

322 Assinatura do codigo

O runtime AIR exige que todas as aplicacoes estejam digitalmente assinadas As

assinaturas digitais de codigo sao um processo que visa garantir a integridade da

aplicacao e a identidade do seu autor no momento da instalacao As equipas de

desenvolvimento podem ldquoassinarrdquo uma aplicacao utilizando um certificado atribuıdo

por uma Entidade Certificadora (Certification Authority) ou atraves de um certifi-

cado individual (self signed certificate) Neste momento o Adobe AIR suporta como

entidades certificadoras a Verisign e a Thawte [Ado08]

O instalador apresenta o nome de quem publica a aplicacao quando o codigo tiver

sido assinado com um certificado que apresente confianca ou que esteja encadeado

com um certificado que tenha ja sido aceite no computador em que se esta a instalar

a aplicacao

As equipas de desenvolvimento podem tambem assinar as aplicacoes com um

certificado auto-atribuıdo (um certificado criado por elas proprias) mas neste caso

o instalador apresentara estas aplicacoes como sendo de uma origem nao verificada

O AIR utiliza a infraestrutura publica de chaves [Ent07] suportada pelo arquivo

local do sistema operativo Para que a origem da aplicacao seja reconhecida o

computador onde a aplicacao AIR esta a ser instalada tem que confiar directamente

no certificado que foi utilizado para assinar a aplicacao ou confiar num certificado

que esteja num encadeamento logico de certificados confiados e que se ligue desta

forma ao certificado utilizado para assinar a aplicacao

Todas as aplicacoes AIR tem caracterısticas em comum independentemente da

tecnologia utilizada para o seu desenvolvimento (HTMLFlexFlash) No ambito

de uma aplicacao AIR existem um conjunto de APIs que estao disponıveis e que

tornam possıvel o acesso ao sistema local (leitura e escrita) e a recursos de rede que

22

Estado da arte

de outra forma nunca estariam acessıveis a partir de uma web application comum

Cada aplicacao AIR possui tambem diferentes nıveis de isolamento chamados secu-

rity sandboxes dependendo do tipo de conteudo que esta a ser carregado e do seu

objectivo

bull Isolamento ao nıvel da aplicacao5 ndash E a raiz de cada aplicacao AIR Este

nıvel de isolamento permite o acesso a APIs privilegiadas e especıficas do

AIR Em contrapartida e negado o acesso a algumas APIs que poderiam ser

facilmente utilizadas de forma maliciosa contra o utilizador final Importacao

dinamica de conteudos remotos e geralmente proibido e as tecnicas e mecan-

ismos de geracao dinamica de codigo sao fortemente restringidas Apenas

conteudo carregado directamente da directoria base da aplicacao podera ser

colocado neste nıvel de isolamento

bull Isolamento nao especıfico da aplicacao6 ndash contem todo o outro conteudo

que nao tenha sido carregado directamente para o isolamento da aplicacao

Isto inclui conteudo local e remoto Este tipo de conteudo nao tem acesso

directo as APIs do AIR e rege-se pelas mesmas regras tal como se tivesse sido

carregado por um browser a partir da mesma localizacao (por exemplo HTML

carregado a partir de um domınio remoto comporta-se da mesma forma que se

fosse acedido a partir do browser)

33 Mozilla Prism

331 XML User Interface Language

O eXtensible User Interface Language (XUL) e uma linguagem de anotacao

baseada em XML desenvolvida pela Mozilla Foundation que opera em aplicacoes

Mozilla multi plataforma tal como o Firefox O motor Gecko e a unica imple-

mentacao completa desta linguagem que foi desenhada sobre padroes web comuns

como CSS JavaScript e o DOM e permite o desenvolvimento de interfaces graficas

utilizando elementos pre-definidos tais como window box page textbox radio

button entre outros Infelizmente o XUL nao possui qualquer especificacao formal

ou implementacoes de inter-operabilidade para outros motores que nao o Gecko No

entanto a sua implementacao e licenciada em codigo aberto pelas licencas GNU Gen-

eral Public License (GPL) GNU Lesser General Public License (LGPL) e Mozilla

Public License (MPL)

Enunciam-se algumas caracterısticas desta linguagem

5NT application sandbox6NT non-application sandbox

23

Estado da arte

Liguagem de anotacao poderosa baseada em componentes (widgets) O ob-

jectivo do XUL e permitir a construcao de aplicacoes multi-plataforma em

claro contraste com o Dynamic HyperText Transfer Protocol (DHTML) que se

destina ao desenvolvimento de paginas web Por esta razao o XUL esta orien-

tado a componentes tais como janelas botoes e etiquetas em vez de paginas

cabecalhos de texto e ligacoes de hipertexto Investir tempo e esforco para

atingir este mesmo resultado em aplicacoes baseadas em DHTML compromete

frequentemente a complexidade e desempenho da aplicacao

Baseado em padroes O XUL e um dialecto XML baseado no padrao W3C XML

10 As aplicacoes escritas em XUL sao tambem baseadas em especificacoes

W3C adicionais como HTML 40 CSS DOM nıvel 1 e 2 JavaScript 15

incluindo ECMA-262 Edition 3 (ECMAscript)

Portabilidade entre plataformas Tal como HTML o XUL foi desenhado para

ser independente da plataforma em que e utilizado tornando as aplicacoes

facilmente portaveis entre sistemas operativos nos quais o Mozilla e suportado

Uma vez que o XUL oferece um nıvel de abstraccao dos componentes graficos

de interface que disponibiliza implementa a premissa ldquoum codigo para todas

as plataformasrdquo A interface grafica de todos os produtos centrais Mozilla

(browser instant messenger livro de enderecos) e escrita em XUL com um

unico codigo base que suporta todas as plataformas Mozilla

Separacao entre o nıvel de apresentacao e a logica de negocio Uma das

maiores preocupacoes no desenvolvimento para a Internet e a forte ligacao

entre estas duas camadas (interface e logica) Isto constitui um problema sig-

nificativo no desenvolvimento de grandes aplicacoes especialmente quando o

desenvolvimento e feito em ambientes de equipa porque as capacidades de de-

senvolvimento destas duas partes da aplicacao estao muitas vezes espalhadas

por diferentes elementos O XUL permite uma clara distincao entre a definicao

da aplicacao cliente e da logica de implementacao (XUL eXtensible Binding

Language (XBL) e JavaScript) apresentacao (CSS e imagens) internacional-

izacao (Document Type Definitions (DTDs) e etiquetas de texto em lınguas

especıficas guardados em ficheiros properties) O esquema grafico e apre-

sentacao de uma aplicacao XUL pode ser alterado de forma independente da

sua logica ou implementacao e a aplicacao pode ainda ser traduzida (interna-

tionalization) de forma independente da sua logica implementacao ou apre-

sentacao Este grau de separacao resulta em aplicacoes que sao mais faceis de

manter pelos programadores e facilmente adaptadas por designers e tradutores

24

Estado da arte

Facil adaptacao Outro benefıcio que advem do nıvel de separacao entre logica

de negocio e apresentacao oferecido pelo XUL e a facilidade com que se pode

adaptar uma aplicacao para diferentes clientes ou grupos de utilizadores Um

programador pode utilizar a mesma aplicacao base e adapta-la consoante as

necessidades atraves de diferentes temas (skins) e ficheiros de lınguas Desta

forma uma aplicacao escrita e desenvolvida em Ingles pode ser rapidamente

traduzida para Portugues e distribuıda com outra aparencia mais apropriada

ao cliente alvo

332 Prism

O Mozilla Prism e um browser simplificado e ldquointerpretadorrdquo de XUL (tambem

designado por XULRunner) que acolhe web applications sem a interface grafica ha-

bitual de um browser Baseia-se num conceito designado por Site Specific Browser

(SSB) Um SSB e uma aplicacao com um browser embebido desenhado para exe-

cutar apenas uma web application Nao possui os menus e barras de ferramentas

habituais Um SSB tem uma integracao com o sistema operativo e com o desktop

muito mais estreita do que uma web application acedida atraves de um browser uma

vez que e executado em janela propria

O Prism resulta de uma experiencia da Mozilla e visa reduzir as diferencas entre

as desktop applications tradicionais e as web applications Um dos aspectos focados e

a experiencia do utilizador Numa apresentacao oficial e dito que ldquo[o Prism] pretende

ser uma ponte entre as diferencas que existem entre as aplicacoes tradicionais de

desktop e as web applications explorando novos modelos de usabilidade enquanto

que a linha que as separa se continua a definirrdquo [Lab07]

34 HTML 5

A especificacao HTML 5 [Hic08] que se encontra em fase de desenvolvimento

pelo grupo WHATWG pretende ser uma norma de substituicao dos padroes HTML

4 XHTML 1x e do DOM2 HTML Uma das propriedades que o distingue das tec-

nologias que pretende substituir e precisamente o suporte para OWA e armazena-

mento de dados no cliente de uma forma relacional Nao sendo propriamente uma

tecnologia ndashmas antes uma especificacao ndashe aqui mencionada por ter servido como

referencia a diversas implementacoes de funcionalidades offline e por se considerar

que venha a ter um impacto significativo nas implementacoes de diversos browsers

Dion Almaer defendeu no seu blogue que o Gears era uma implementacao do

HTML 5 No seu artigo ldquoGears as a bleeding-edge HTML 5 implementationrdquo [Alm08]

o autor diz que ambos ndasho Gears e o HTML 5 ndashpretendem dar a web caracterısticas

25

Estado da arte

semelhantes e nao encontrar motivo de ldquocompeticaordquo entre as duas mas que en-

quanto o HTML 5 e uma especificacao o Gears e uma implementacao

No entanto tambem e verdade que o HTML 5 cobre muitos outros pontos para

alem das OWA que saem completamente fora do ambito do Gears Se esta es-

pecificacao atingir um estado de maturidade que possibilite a sua adopcao pelos

principais browsers tornando nativo do browser o suporte OWA entao deixara de

fazer sentido a existencia de uma extensao como o Gears

A especificacao HTML 5 disponibiliza duas APIs relevantes para o tema das

OWA

1 Uma base de dados baseada em SQL que permite o armazenamento de dados

do lado do cliente

2 Uma ldquocacherdquo HTTP que garante a disponibilidade das aplicacoes mesmo quando

o utilizador nao possui uma ligacao a Internet

Estas caracterısticas sao as bases da tecnologia das OWA e tem correspondencia

com os pontos analisados nas seccoes 311 e 311

35 Web applications que usam funcionalidades offline

Nesta seccao apresentam-se algumas web applications que actualmente disponi-

bilizam funcionalidades offline Estas aplicacoes foram escolhidas para uma analise

mais pormenorizada por utilizarem o Gears que tal como descrito na seccao 4 foi

a tecnologia escolhida para o projecto

351 Google Reader e Google Docs

O Google Reader7 e um leitor de feeds RSS Permite gerir a subscricao de varios

sites simultaneamente que disponibilizem conteudos neste formato e foi a primeira

web application da Google com uma versao offline publicamente acessıvel (desde

Junho de 2007)

O Google Reader implementa o modo ldquoutilizador deciderdquo oferecendo na sua

interface um botao que permite alternar entre os modos online e offline

O Google Docs8 e uma web application que permite a criacao e edicao de doc-

umentos de texto folhas de calculo e apresentacoes Era ja publico desde Janeiro

de 2008 que o Google estava a desenvolver uma versao OWA desta aplicacao mas o

acesso a uma versao experimental so foi possıvel a partir de 31 de Maio de 2008

7Google Reader - httpreadergooglecom8Google Docs - httpdocsgooglecom

26

Estado da arte

A implementacao das funcionalidades offline nestas duas aplicacoes seguiu difer-

entes aproximacoes principalmente porque o Google Reader apresenta ao utilizador

informacoes que sao fornecidas por fontes externas enquanto que no Google Docs

a informacao e criada e editada pelo utilizador sobre a forma de documentos

A diferente origem da informacao implica que no Google Reader seja necessario

prever casos de excepcao tal como existirem demasiados itens que necessitam de

ser transferidos para o cliente Nao observar este ponto causa um problema grave

de usabilidade e para evitar tempos de espera demasiado longos e uma interface

com pouca capacidade de resposta as accoes do utilizador o Google Reader apenas

transfere para o cliente os dois mil itens mais recentes na transicao para o modo

offline

352 Remember the Milk

O Remember The Milk9 e uma web application desenvolvida por uma equipa

Australiana que proporciona funcionalidades de agenda gestao de tempo e de tare-

fas e foi uma das primeiras aplicacoes independentes do Google a adoptar o Gears

para acessos em modo offline Permite que os seus utilizadores facam uma gestao

de tarefas agrupando-as em listas adicionando-lhes campos de informacao adicional

ou dando-lhes informacao geografica (recorrendo ao servico Google Maps10) Entre

a sua lista de funcionalidades encontra-se ainda a possibilidade de importar e ex-

portar eventos no formato iCalendar (ics) etiquetas (tags) em tarefas publicacao

Really Simple Syndication (RSS) e partilha de categorias de tarefas de acordo com

diferentes nıveis de permissoes de acesso definidos pelo utilizador

353 MySpace e WordPresscom

O MySpace uma das maiores social networks na Internet anunciou recente-

mente que vai disponibilizar uma versao do seu cliente de e-mail que utiliza o Gears

para acelerar o seu desempenho Numa fase inicial estara disponıvel apenas para

utilizadores que tenham cinco mil ou mais mensagens na sua caixa de correio e

permitira efectuar pesquisas muito mais rapido que a sua versao online

O servico de blogs Wordpresscom anunciou tambem o inıcio da utilizacao desta

tecnologia com o fim de melhorar o desempenho A versao que utiliza esta tecnologia

descarrega e armazena no cliente um conjunto de imagens e scripts que passam a

ter preferencia sobre os seus congeneres online e que permitem acelerar o processo

de carregamento da aplicacao e visualizacao de blogs

9Remember The Milk ndash httpwwwrememberthemilkcom10Google Maps ndash httpmapsgooglecom

27

Estado da arte

O MySpace e o Wordpresscom sao dois exemplos da utilizacao da tecnologia

OWA para optimizacao de web application ja existentes Sem pretenderem disponi-

bilizar uma versao que seja totalmente offline fazem uso do Gears para armazenar no

cliente parte dos recursos frequentemente acedidos na visualizacao das suas paginas

36 Escolha da tecnologia

Apos a analise das tecnologias apresentada nas seccoes 31 a 34 foi necessario es-

tudar a adequacao de cada uma delas ao projecto em questao Desde logo e possıvel

observar que nem todas se dedicam apenas a OWA Por exemplo o Adobe AIR

apesar de ter suporte para OWA apenas disponibiliza algumas das funcionalidades

identificadas como mais indicadas para a execucao do projecto quando utilizado

na sua vertente desktop tal como exposto na Tabela 31 mas a utilizacao desta

vertente implicaria o desenvolvimento de novas interfaces e de novas formas de co-

municacao (troca de mensagens XML ou JSON) A vertente web do Adobe AIR

foca-se mais especificamente nas Rich Internet Applications e permite a reutilizacao

do codigo ja existente (exigindo naturalmente a sua adaptacao e a implementacao

das funcionalidades pretendidas)

A tecnologia escolhida para a realizacao deste trabalho foi o Gears sendo que

um dos principais factores a influenciar esta opcao foi a liberdade introduzida pela

sua licenca Berkeley Software Distribution (BSD)11

Considerou-se o funcionamento desta ferramenta extremamente adequando a

aplicacao no WOW uma vez que o seu principal objectivo e precisamente tornar

possıvel a execucao offline de uma pagina web e por virtude deste facto o Gears tem

uma API concisa e de simples aplicacao pratica uma vez que nao possui quaisquer

outros elementos distractores O funcionamento do seu ManagedResourceStore ex-

emplificado na Figura 31 com a capacidade de actualizacao de recursos definidos

num ficheiro manifesto especificado em JSON pesou tambem nesta decisao

11Sobre a licenca BSD consultar httpwwwopensourceorglicensesbsd-licensephp e http

wwwlinfoorgbsdlicensehtml

28

Estado da arte

Figura 31 Esquema UML do processo efectuado pelos recursos do Gears do tipoManagedResourceStore para a actualizacao dos conteudos definidos no ficheiro manifesto

29

Estado da arte

Funcionalidade RIAs no browser RIAs no desktop

Disponibilidadeda aplicacao

As aplicacoes podem ser facil-mente exploradas e utilizadas

As aplicacoes quando instal-adas tem maior grau de fun-cionalidades e persistencia

Instalacao Nao e necessario qualquer tipode instalacao

As aplicacoes sao instaladasatraves do browser ou descar-regadas e instaladas comouma aplicacao tradicional

Actualizacoes Aplicacoes sao actualizadascarregando conteudos paraum website

O AIR disponibiliza uma APIque permite que as aplicacoessejam actualizadas de umaforma

Sistemas opera-tivos suportados

As aplicacoes podem ser exe-cutadas em diversos sistemasoperativos e browsers

As aplicacoes sao multi-plataforma e podem serinstaladas e executadas emdiversos sistemas operativos ebrowsers

Linguagens deprogramacao

Javascript e disponibilizadopelo browser e ActionScripte disponibilizado pelo AdobeFlash Player

Maquinas virtuais deJavascript e ActionScriptcompatıveis com o browser

Capacidade deexecucao embackground

As RIAs podem ser execu-tadas numa janela do browser

As aplicacoes podem ser ex-ecutadas em background edisponibilizar notificacoes talcomo uma aplicacao tradi-cional

Persistencia A actividade esta limitada asessao do browser Quando obrowser e encerrado toda ainformacao e descartada

As aplicacoes sao instaladas eestao disponıveis no desktopPodem armazenar informacaolocalmente e estao disponıveisoffline

Integracao com odesktop

Integracao com o desktop lim-itada devido a restricoes im-postas pelo browser

As aplicacoes podem acederao sistema de ficheiro ao clip-board eventos notificacoesetc

Controlo da inter-face com o uti-lizador

As aplicacoes sao acedidasatraves de uma janela dobrowser que tem os seusproprios controlos e visualgrafico

As aplicacoes tem um vi-sual grafico proprio em janelapropria

Armazenamentode dados

As aplicacoes tem armazena-mento limitado que pode serreescrito pelo browser

As aplicacoes tem acesso a to-talidade do espaco disponıvellocalmente e a uma base dedados com a possibilidade deencriptacao

Tabela 31 Comparacao das funcionalidades oferecidas pelo Adobe AIR para as platafor-mas web e desktop

30

Estado da arte

Aplicacao Modo de execucao utilizadoGoogle Reader Utiliza o modo ldquoutilizador deciderdquo disponibilizando

ao utilizador um botao para alternar entre os modosonline e offline Como lida com informacao recol-hida de fontes externas de natureza frequentementeefemera o processo de sincronizacao apenas transfereos dois mil itens mais recentes quando passa ao es-tado offline Neste modo sao ainda guardadas in-formacoes de itens lidos e etiquetas atribuıdas quesao sincronizadas com o servidor quando o utilizadorvoltar a activar estado online

Google Docs Utiliza o modo ldquoaplicacao deciderdquo permitindo que outilizador edite os conteudos de documentos de textofolhas de calculo e de apresentacoes independente-mente do estado da ligacao desde o momento em queas funcionalidades offline sao activadas A aplicacaofaz pequenas sincronizacoes com o servidor sempre quenecessario

Remember the Milk Utiliza um modo hıbrido entre ldquoaplicacao deciderdquo eldquoutilizador deciderdquo A aplicacao encarrega-se da sin-cronizacao de dados mas disponibiliza um controlona sua interface que permite despoletar manualmenteeste processo para situacoes em que o utilizador fez al-teracoes recentes e pretende usufruir das capacidadesoffline imediatamente

MySpace O MySpace anunciou a utilizacao de mecanismos dearmazenamento de dados no cliente com recurso atecnologias OWA para melhorar o desempenho doseu cliente web de correio electronico nomeadamenteno que diz respeito a operacoes de pesquisa e or-denacao Inicialmente esta funcionalidade estara ape-nas disponıvel para utilizadores com cinco mil ou maismensagens na sua caixa de correio mas nao e aindaclaro se sera disponibilizada uma versao totalmenteoffline

Tabela 32 Resumo da utilizacao de tecnologias OWA em algumas web applications con-sideradas na analise do estado da arte

31

Estado da arte

32

Capıtulo 4

Desenvolvimento

Neste capıtulo introduz-se a aplicacao WOW e apresenta-se o estudo que foi

feito da adequacao de cada tecnologia para a implementacao da funcionalidade of-

fline nesta plataforma Fazem-se diversas consideracoes sobre opcoes a tomar na

concepcao de OWAs e problemas comuns na sua implementacao bem como sug-

estoes para os resolver O WOW e uma aplicacao ja existente de gestao de ordens

de trabalho e do fluxo de tarefas numa empresa ou organizacao

41 Como ficar offline

Na maior parte das web applications de hoje nao existe uma camada de dados

real A aplicacao exemplificada na Figura 41 ao longo da sua execucao acede

directamente a sua unica fonte de dados (o servidor) atraves de chamadas Ajax sem

que exista uma separacao clara destas duas camadas

Para que uma web application seja capaz de ser executada sem uma ligacao

activa a Internet e mantenha o seu caracter dinamico torna-se necessario incluir

Figura 41 Exemplo de uma arquitectura de uma web application sem uma camada deabstraccao de dados Figura adaptada de http gears google com

33

Desenvolvimento

Figura 42 Exemplo de uma arquitectura de uma web application com uma camada deabstraccao de dados Figura adaptada de http gears google com

um mecanismo de armazenamento de dados local seja uma base de dados ou a

capacidade de acesso ao disco No entanto este mecanismo introduz dois problemas

1 Qual das fontes de dados utilizar quando um utilizador faz um pedido de

informacao

2 A necessidade de implementar uma camada de acesso a dados que seja coerente

quer se use o servidor remoto ou local

Por exemplo em vez de a aplicacao Ajax fazer um pedido relativo as contas de

todos os utilizadores em formato JSON directamente ao servidor remoto podera ao

inves fazer o pedido a um objecto intermedio da camada de dados Este objecto

demonstrado na Figura 42 sera responsavel por implementar uma interface de

acesso a base de dados e retornar um objecto JavaScript com uma representacao da

resposta do servidor

Mas a existencia de uma segunda fonte de dados torna recomendavel tambem

a implementacao de uma camada de data switching que em funcao da existencia

de conexao a Internet e da necessidade de actualizacao dos dados decide se faz o

pedido ao servidor remoto ou se fornece os dados presentes localmente Este objecto

apresentado na Figura 43 decidira de forma transparente para o utilizador se le ou

escreve os dados localmente ou se os enviapede ao servidor remoto e pode tambem

iniciar o processo de convergencia de dados e de resolucao de conflitos

411 Funcionalidades disponıveis em modo offline

Por razoes praticas e provavel que nem todas as funcionalidades da aplicacao

possam ser disponibilizadas em modo offline E necessario escolher quais as fun-

cionalidades a disponibilizar no modo offline da aplicacao e implementar a logica

que decide quando utilizar a base de dados local ou o servidor remoto Apesar do

acesso a base de dados local ser muito mais rapido do que aceder ao servidor o

acesso local nem sempre e preferido Ha varias razoes que podem tornar necessario

escolher o acesso ao servidor em vez do acesso local

34

Desenvolvimento

Figura 43 Exemplo de uma arquitectura de uma web application com uma camada deabstraccao de dados e um data switch Figura adaptada de http gears google com

1 A informacao pode ter uma natureza efemera e nao fazer sentido guarda-la

localmente Exemplo dados em tempo real da bolsa de valores de Lisboa

2 Algumas aplicacoes lidam com informacao que so faz sentido na presenca de

uma ligacao Exemplo Instant Messaging

3 A aplicacao podera escolher apenas guardar a informacao acedida mais fre-

quentemente Exemplo para o utilizador poder alterar a lıngua de apre-

sentacao da aplicacao os conteudos terao que ser guardados em todas as

lınguas disponibilizadas pela aplicacao O custo de implementacao de algu-

mas funcionalidades pode nao compensar o benefıcio

4 A capacidade de processamento ou de armazenamento de dados pode inviabi-

lizar algumas funcionalidades offline Exemplo se uma dada funcionalidade

necessita de uma capacidade de armazenamento de dados para alem do razoavel

de um computador pessoal para ser util (visualizador de mapas)

42 Modos de execucao

Um aspecto que e necessario estudar para qualquer web application que se deseje

disponibilizar offline prende-se com tres modos de execucao que devem ser consid-

erados

1 Utilizador decide o modo de execucao A aplicacao tem modos distintos

de execucao para os estados online e offline geralmente indicados na interface

com o utilizador O utilizador e informado do estado da ligacao e participa na

alteracao de estado de execucao da aplicacao interagindo com a sua interface

2 Aplicacao decide o modo de execucao Pode ser implementado na propria

aplicacao um mecanismo de deteccao do estado da ligacao (por exemplo atraves

35

Desenvolvimento

de chamadas Ajax periodicas) transitando de estado e sincronizando automati-

camente Desta forma o utilizador nao precisa de participar na alteracao de

estado a menos que exista um conflito de dados que requeira a sua atencao

3 Aplicacao assume sempre o estado offline Outra hipotese sera imple-

mentar uma web application que assume sempre estar na ausencia de uma

ligacao ao servidor de dados Esta aplicacao responde aos pedidos do uti-

lizador efectuando pedidos de informacao ao servidor mas nao dependendo

de uma resposta valida para mostrar a informacao que ja tinha disponıvel an-

teriormente A sincronizacao de dados com o servidor e tentada sempre que

existam dados para submeter e uma accao do utilizador

421 Modo ldquoutilizador deciderdquo

Neste modo de execucao quando a aplicacao esta online comunica com o servidor

remoto quando esta offline comunica com a base de dados local A informacao tem

que ser sincronizada sempre que se muda de modo A principal vantagem desta opcao

e que e a mais simples de implementar mesmo para uma aplicacao ja existente e

portanto uma forma expedita de disponibilizar uma OWA No entanto tem tambem

algumas desvantagens que devem ser consideradas

1 O utilizador tem que se lembrar de fazer a alteracao de estado de execucao

Caso contrario podera estar a trabalhar inadvertidamente numa versao offline

com dados antigos ou nao ter a informacao necessaria se perder subitamente

a ligacao

2 Se a ligacao for intermitente o utilizador tera ou que escolher um dos modos

de execucao ou estar constantemente a trocar

3 Uma vez que a base de dados nao esta sempre actualizada nao podera ser

utilizada para melhorar a rapidez de execucao da aplicacao quando em modo

online

422 Modo aplicacao decide

A deteccao do estado da ligacao pode ser implementada atraves de um pedido

assıncrono ao servidor tal como ilustrado na Figura 44 O resultado deste pedido

definira o estado online (em caso de sucesso) ou offline (em caso de falha) A

sincronizacao de dados podera ser feita sempre que ocorra uma transicao do es-

tado offline para o estado online No entanto este metodo nao se revela eficiente

36

Desenvolvimento

Figura 44 Esquema grafico ilustrando uma OWA executando no browser utilizando ummodo de execucao do tipo ldquoaplicacao deciderdquo com deteccao automatica do estado daligacao via pedidos Ajax assıncronos a cada cinco segundos

para grandes aplicacoes uma vez que requer a troca de mensagens demasiado fre-

quentes com o servidor que se destinam exclusivamente a monitorizacao do estado

da ligacao

423 Modo ldquoaplicacao assume o estado offlinerdquo

Uma aplicacao transparente funciona assumindo sempre que esta em modo of-

fline ou pelo menos que pode perder a ligacao a qualquer momento Neste modo

tira-se o maximo partido do armazenamento local e fazem-se pequenas mas contınuas

sincronizacoes com o servidor sempre que este esteja disponıvel A sincronizacao de

dados tambem e feita sempre que se volta ao estado online

As vantagens de uma web application transparente sao as seguintes

bull Uma melhor experiencia para o utilizador uma vez que este nao tem que se

preocupar com o estado da ligacao ou com a transicao de estados

bull A aplicacao funciona de forma coerente mesmo que a ligacao seja intermitente

bull Uma vez que o armazenamento local e mantido actualizado pode ser utilizado

para melhorar o desempenho da aplicacao

Foram identificadas as seguintes desvantagens

bull E mais difıcil de implementar e a sincronizacao acarreta cuidados especiais

bull E necessario um cuidado adicional para evitar que as operacoes de sincronizacao

frequentes que ocorrem automaticamente nao afectem os tempos de resposta

da aplicacao

bull Os testes a aplicacao sao mais complexos uma vez que a sincronizacao de dados

nao ocorre em resposta a uma accao do utilizador

37

Desenvolvimento

43 Sincronizacao de dados

A sincronizacao de dados consiste na capacidade de identificar e transferir pe-

riodicamente a versao mais actual dos dados entre o cliente e o(s) servidor(es)

Independentemente do modo de execucao escolhido e mesmo do estado da ligacao

do utilizador a informacao armazenada localmente e a informacao armazenada no

servidor estarao por vezes dessincronizadas Isto podera acontecer sempre que por

exemplo

bull O utilizador faz alteracoes em modo offline

bull A informacao e partilhada e pode ser alterada por uma entidade externa

bull A informacao e fornecida por uma entidade externa

Resolver estas diferencas de forma a que a informacao local e remota encontrem

a igualdade chama-se sincronizacao de dados Ha varias aproximacoes possıveis

para este efeito que dependem da natureza da aplicacao cada uma com vantagens

e desvantagens

A capacidade de suportar a mobilidade dos utilizadores torna-se cada vez um

ponto mais importante de uma web application Para uma organizacao de dimensao

global e vital garantir que os seus colaboradores tem acesso a mesma informacao

que tem disponıvel nos seus postos de trabalho mesmo quando estao fora Na maior

parte dos casos estes colaboradores terao acesso a um computador portatil um

desktop Smartphone ou PDA e atraves destes poderao ter acesso a sua informacao

directamente atraves de ligacoes encriptadas Virtual Private Network (VPN) de um

servidor web ou de outro mecanismo de rede

Esta solucao e simples de implementar mas infelizmente para a maioria dos

colaboradores com grande factor de mobilidade nao e satisfatoria As principais

desvantagens sao as seguintes

bull Requisitos de ligacao Para permitir que os utilizadores acedam a sua in-

formacao e necessario garantir a capacidade constante de comunicacao pelo

menos durante o tempo necessario que assegure a sua transferencia

bull Velocidade de ligacao sem persistencia de dados e em ligacoes de fraca

qualidade a usabilidade por vezes torna-se inaceitavel

bull Ponto crıtico de falha Com este tipo de solucao todos os utilizadores de-

pendem da base de dados que armazena informacao vital para o funcionamento

do cliente

38

Desenvolvimento

bull Scalability do servidor A medida que novos utilizadores sao adicionados ao

sistema o desempenho do servidor e afectado levando a necessidade de maior

capacidade de armazenamento eou processamento

De acordo com a documentacao da Microsoft Sync Framework [Mic08] uma

solucao alternativa consiste em implementar uma Occasionally Connected Appli-

cation (OCA) Uma OCA permite a um utilizador remoto continuar a aceder a

sua informacao mesmo depois de perder a ligacao mas em vez de recorrer a um

servidor recorre a informacao armazenada no seu dispositivo local Para preencher

localmente a informacao que o utilizador necessita uma OCA possui mecanismos

de sincronizacao de dados que sao oferecidos por esta framework

431 Quando sincronizar

Uma das solucoes mais simples de implementar passa por disponibilizar um

mecanismo manual que despoleta a sincronizacao Diz-se manual porque e o uti-

lizador que escolhe quando sincronizar e pode ser implementada simplesmente

fazendo o upload de toda a informacao para o servidor e depois fazendo o download

da copia mais recente da informacao antes de voltar a ficar offline Para que esta

seja uma opcao viavel e necessario que

bull O volume de dados seja suficientemente pequeno para que possa ser transferido

do servidor para o cliente num espaco de tempo aceitavel

bull Que o utilizador indique explicitamente que quer mudar para o estado offline

ou online pressionando um botao da interface

Contudo podem ser identificados alguns problemas relacionados com esta abor-

dagem

bull Os utilizadores nem sempre podem prever o estado das suas ligacoes A ligacao

pode-se perder subitamente ou ter um caracter intermitente

bull O utilizador pode esquecer-se de efectuar a sincronizacao

Outra opcao sera conjugar a sincronizacao de dados com o modo de execucao

transparente A sincronizacao ocorre automaticamente em background de forma

nao intrusiva para o utilizador A aplicacao comunica com o servidor regularmente

efectuando pequenas trocas de dados com o objectivo de manter o sincronismo da

informacao local e remota Esta abordagem pode ser implementada com pedidos

Ajax assıncronos e regulares ao servidor o que permite manter a interaccao com a

interface fluıda evitando bloqueios Estes pedidos sao feitos prevendo as situacoes

39

Desenvolvimento

de disponibilidade ou indisponibilidade (timeout) do servidor Uma outra opcao

sera permitir que o servidor comunique essas alteracoes utilizando Comet1 tal como

descrito em [Wil06] e [Rus06] As vantagens destas aproximacoes sao

bull A informacao esta disponıvel a qualquer altura que o utilizador decida ficar

offline ou que a ligacao seja acidentalmente perdida

bull O desempenho da aplicacao pode ser melhorado quando se estiver a utilizar

uma ligacao a Internet lenta uma vez que o acesso a dados locais e mais

eficiente do que a consulta de dados ao servidor

44 WOW

O WOW e uma plataforma integrada de gestao de ordens de trabalho ja ex-

istente e desenvolvida pela Critical Software SA a qual se pretende adicionar a

capacidade de execucao offline Esta aplicacao e extremamente dinamica e con-

figuravel com um conjunto extremamente rico de funcionalidades das quais se

destacam

bull Gestao de Ordens de Trabalho ndash suportando a gestao dos pedidos desde a

sua criacao ate ao seu fecho tomando em conta os diferentes tipos de pedidos

(ordens de trabalho pedidos de informacao melhorias resolucao de problemas

etc) e diferentes tipos de accoes possıveis para cada um (Figura 45)

bull Monitorizacao de alteracoes ndash Historico de mudancas anexos e estados criando

relatorios de alteracao automaticamente (o que por quem e quando)

bull Uso de Service Level Agreements (SLAs) ndash E possıvel associar a um pedido um

SLA que define qual o perıodo de tempo atribuıdo a resolucao de um pedido

controlando e agilizando a resolucao do mesmo

bull Utilizacao de queries de utilizador configuraveis que permitem acesso rapido

a determinadas ordens de trabalho de acordo com o filtro configurado (por

exemplo ldquoPara mimrdquo ldquoPara o Grupordquo ldquoPelo Grupordquo)

bull Gestao do relacionamento entre pedidos

bull Pesquisa e filtragem de ordens de trabalho

bull Exportacao de dados em formatos padrao (PDF DOC ou XLS)

bull Integravel com solucoes externas

40

Desenvolvimento

Figura 45 Detalhe de um conjunto possıvel de estados e respectivas transicoes para umadada ordem de trabalho no WOW desde a sua submissao no sistema ate a sua conclusaoem fecho ou cancelamento Esta figura representa apenas um exemplo ja que o mapa deestados para uma ordem de trabalho e dinamico e pode ser alterado por um administradorFigura retirada de uma brochura promocional do WOW Critical Software SA

A utilizacao de uma ferramenta deste tipo por parte de uma empresa ou orga-

nizacao oferece vantagens quer a gestao de topo quer aos colaboradores individuais

para os colaboradores individuais o WOW e uma aplicacao onde estao registadas

todas as tarefas contribuindo activamente para o desenvolvimento em ambientes

multi-tarefa e para a organizacao pessoal das tarefas de acordo com prioridades

Para a gestao de topo esta ferramenta permite obter uma visao global do estado da

organizacao em termos de tempo gasto por tarefa executada sendo uma mais valia

para a previsao e gestaoalocacao de recursos

45 Visao geral sobre a arquitectura do WOW

O WOW e interessante nao so do ponto de vista de produto como tambem do

ponto de vista de plataforma Existem diversos plug-ins que estendem as funcional-

idades do WOW e existem ate projectos que pretendem usar a arquitectura do

WOW para criar produtos com fins diferentes do inicial (por exemplo o WOW-

Storm ndash um sistema de registo e classificacao social de ideias)

De modo a conseguir ter essa expansibilidade a plataforma WOW assenta sob

uma arquitectura distribuıda modular e expansıvel com uma componente central

ndash o core ndash estruturado em camadas logicas E no core que se situam todas as

1O Comet e um conceito semelhante ao Ajax introduzido por Alex Russel mas no qual e o servidor quetoma a iniciativa de ldquoenviarrdquo os dados ao browser sem que este tenha que efectuar um pedido Tambem econhecido por Ajax Push Reverse Ajax ou HTTP Streaming

41

Desenvolvimento

funcionalidades base da aplicacao quer a nıvel logico funcional e de apresentacao

quer a nıvel de gestao e configuracao

E possıvel a execucao de varias instancias do core simultaneamente em servidores

distintos o que permite a alta escalabilidade e disponibilidade desta aplicacao A

consistencia dos dados fica sempre garantida atraves da partilha da base de dados

e pelo balanceamento dos pedidos uma vez que cada um e encaminhado para uma

unica instancia

O WOW apresenta tambem a vantagem de ser uma plataforma extensıvel E

possıvel adicionar novas caracterısticas a plataforma atraves de componentes que se

podem ser divididos em duas categorias plugins e connectors

Os plugins sao componentes que se encontram no mesmo no fısico que a aplicacao

partilhando do mesmo contexto de execucao do core Sao assim uma forma mais

directa de obter informacao da plataforma visto que nao possuem restricoes de

acesso aos dados nem dependencias externas A arquitectura deste componente tera

assim que permitir varias execucoes instanciadas cada uma associada a um core

Por outro lado os connectors sao componentes que se encontram distribuıdos

comunicando externamente com o core Quer a sua execucao quer a obtencao

dos dados estao assim dependentes de interfaces de comunicacao externas que a

plataforma disponibiliza Estes componentes ao contrario dos plugins sao instan-

ciados unicamente e recorrem ao protocolo de comunicacao Java Messaging Service

(JMS) para comunicar com o core

46 WOW Offline

Para alem das opcoes tomadas relativamente a tecnologia a utilizar surgiu

tambem a necessidade de optar por um dos modos de execucao apresentados na

seccao 42

Das tres opcoes possıveis foi o modo ldquoaplicacao assume o estado offlinerdquo descrito

na seccao 423 que mereceu a maior atencao uma vez que reune as vantagens de

uma experiencia mais positiva para o utilizador (uma vez que este nao tem que

participar activamente na alteracao do modo execucao como descrito na seccao 421)

e nao constitui uma sobrecarga excessiva para servidor (como o modo abordado na

seccao 422)

No entanto esta opcao comprometia a complexidade da implementacao para alem

dos objectivos propostos para este projecto e para cumprir o prazo dado foi tomada

a decisao de implementar o modo ldquoutilizador deciderdquo especificando apenas de forma

teorica o modo ldquoaplicacao assume o estado offlinerdquo

As caracterısticas do Gears foram ja descritas na seccao 31 Na Figura 47

mostra-se a sua forma de funcionamento quando integrado numa web application

42

Desenvolvimento

Nesta figura representa-se o modulo LocalServer do Gears como um ponto de de-

cisao Aqui sao testadas as condicoes que determinam se o pedido sera interceptado e

servido localmente ou se prossegue para uma maquina remota E tambem represen-

tada uma base de dados que corresponde ao modulo Database mas que podera nao

ser utilizada Este modulo tal como o modulo Workerpool tem caracter opcional

e sao utilizados consoante os requisitos da aplicacao

A plataforma WOW lida com mais dados do que e necessario passar para o

lado do cliente Em conformidade com o ja exposto na seccao 411 volta-se a

frisar que nao se pretende recriar toda a logica de negocio nem os conteudos da

base de dados no cliente pela sua complexidade e volume de dados Pretende-se

pelo contrario permitir que os utilizadores tirem partido da capacidade de poder

consultar as suas ordens de trabalho quando nao dispoe de uma ligacao transferindo

apenas o essencial para isto seja possıvel

A pagina inicial do WOW apresenta um resumo das ordens de trabalho abertas

ndash enviadas e recebidas ndash que se pretende permitir visualizar offline (ver Figura 46)

Como prova de conceito foi efectuada uma abordagem pragmatica das varias possi-

bilidades descritas na seccao 42

461 Modo ldquoaplicacao deciderdquo com deteccao automatica da ligacao

A primeira abordagem estudada para a disponibilizacao das funcionalidades of-

fline foi o modo ldquoaplicacao deciderdquo com deteccao automatica de ligacao apresentado

na seccao 422 Para que isto seja possıvel foi implementado um mecanismo de ver-

ificacao periodica do estado da ligacao atraves de chamadas Ajax assıncronas O

resultado destes pedidos determina o estado da aplicacao executando as tarefas de

sincronizacao de dados sempre que pertinente Este metodo embora imediato e

simples de implementar depressa se revelou inadequado para o projecto devido ao

elevado consumo de recursos do servidor que a utilizacao intensiva faz esperar a

comunidade da plataforma WOW no principal cliente excede os 7000 utilizadores

Foi estimado que para uma utilizacao de fluidez aceitavel o estado da ligacao deveria

ser testado a cada cinco segundos Assumindo uma adesao (previsao pessimista) de

1 aos servicos offline assistir-se-ia a cerca de 840 pedidos adicionais por minuto

Mas o principal problema desta aproximacao prende-se com o facto de a ver-

ificacao ser feita em intervalos de tempo discretos levando a possibilidade de a

aplicacao poder ter em dado momento uma representacao errada do seu estado

real da ligacao Este problema e ilustrado na Figura 48 onde se ve claramente a

discrepancia entre o estado real da ligacao e a representacao interna que esta tem

Note-se que nesta janela de tempo qualquer accao do utilizador que exija uma

resposta sıncrona do utilizador leva-lo-a para um ldquobeco sem saıdardquo onde nao tera

43

Desenvolvimento

Figura 46 A pagina inicial do WOW apresenta um resumo das ultimas ordens de trabalhoenviadas e recebidas Na imagem pode-se observar a transicao do estado online para offline

acesso a versao offline porque a aplicacao nao fez a transicao automatica nem acesso

a versao online porque na verdade nao possui uma ligacao O que acontecera nesta

situacao sera uma tentativa de acesso ao servidor por parte da aplicacao numa

altura em que este se encontra indisponıvel e o resultado sera uma mensagem de

ldquopedido excedeu o tempordquo apresentado pelo browser Este e um estado sem retorno

porque apos o browser apresentar esta mensagem todos os recursos JavaScript ficam

indisponıveis tornando impossıvel o regresso ao estado anterior ou o tratamento do

erro de qualquer outra forma No entanto as chamadas Ajax podem ser tratadas de

forma especial para a eventualidade de falha e portanto nao constituem problema

44

Desenvolvimento

Figura 47 Ilustracao do funcionamento do Gears numa web application que utiliza ummotor Ajax Os pedidos HTTP ou HTTPS podem ser interceptados e tratados localmenteou podem ser feitos a uma maquina remota consoante se verificarem ou nao as condicoesexpressas no ponto 311 E representado um acesso a uma base de dados local (fornecidapelo Gears) mas a sua utilizacao e opcional

462 Implementacao do modo ldquoutilizador deciderdquo

Este modo de execucao foi ja descrito na seccao 421 e a sua principal carac-

terıstica e ser o utilizador a decidir se a aplicacao deve utilizar um servidor remoto

ou a maquina local como fornecedor de dados

Relativamente ao WOW o WOW Offline na vertente ldquoutilizador deciderdquo vem

alterar os seus casos de uso dando ao utilizador a possibilidade de alterar o estado

de execucao da aplicacao (entre online e offline) Resta dizer que no modo online se

mantem todas as funcionalidades anteriores e que no modo offline torna-se possıvel

visualizar os conteudos da pagina principal do WOW (Figura 46) e os detalhes das

ordens de trabalho (Figura 49) tal como expressa a Figura 410

Esta aproximacao foi utilizada na prova de conceito do WOW adicionando um

controlo a interface desta aplicacao que permite ao utilizador alternar entre os esta-

dos online e offline Na transicao de online para offline sao descarregados os recursos

necessarios para a execucao desta aplicacao sem recorrer a Internet Para o fazer

45

Desenvolvimento

Figura 48 Neste exemplo do modo ldquoaplicacao deciderdquo o teste da ligacao e feito e feito acada cinco segundos O resultado deste teste nao reflecte sempre o estado real da aplicacaopodendo levar a aplicacao a ter comportamentos indesejaveis Na figura assinala-se umperıodo de tempo no qual a representacao interna do estado da ligacao nao corresponde arealidade

e utilizado um recurso ResourceStore e um ManagedResourceStore (introduzidos

em 311) O primeiro e utilizado para armazenar a pagina principal do WOW ndash do-

ravante designada por homejsp ndash e o segundo e utilizado para armazenar imagens

folhas de estilo CSS e scripts JavaScript

Para a implementacao deste modo de execucao foram identificadas as seguintes

tarefas

1 Guardar informacao que permita a recriacao das paginas que se pretende

disponibilizar offline (utilizando o Gears)

2 Disponibilizar um controlo que permita alterar o estado de execucao atraves

da interaccao com a pagina principal

3 Durante a sincronizacao de dados apresentar o progresso da transferencia de

dados

O primeiro passo consistiu na identificacao de todos os conteudos que sao necessarios

transferir para a execucao offline Foi utilizado um recurso do Gears do tipo

ManagedResourceStore que recorre a um ficheiro manifesto para identificar to-

dos os ficheiros que deve transferir Este recurso e gerido automaticamente pelo

Gears transferindo para o cliente a versao mais recente sempre que e necessario

isto e sempre que exista um ficheiro manifesto com uma identificacao de versao que

seja diferente da actualmente disponıvel no cliente Uma vez identificados todos

ficheiros necessarios para a execucao offline num (ou mais) ficheiros manifesto o

Gears encarrega-se da sua actualizacao mas o preenchimento destes ficheiros man-

ifesto e manual o que se traduz num cuidado extra na manutencao da aplicacao

A forma como esta informacao e guardada deve tambem ser cuidadosamente

estudada A opcao mais flexıvel passa por utilizar o modulo Database apresentado

na seccao 311 e guardar a informacao de uma forma relacional Para a recriacao

das paginas pode ser disponibilizada uma versao HTML da pagina que funciona

46

Desenvolvimento

Figura 49 Pagina de visualizacao do detalhe de uma ordem de trabalho

como template nao possui quaisquer dados e e utilizada apenas em modo offline E

preenchida para cada pedido retirando os dados relevantes da base de dados

O modelo de dados do WOW torna esta opcao extremamente trabalhosa uma

vez que as entidades envolvidas na geracao de cada pagina de informacao sobre

cada ordem de trabalho tem relacoes de dependencia complexas seguindo padroes

muito variaveis Por exemplo em cada ordem de trabalho existe um formulario que

permite a sua progressao de estado com diversos campos opcionais e obrigatorios

este formulario e definido pelo administrador e esta relacionado nao apenas com o

tipo de ordem de trabalho mas tambem com o estado actual em que esta se encontra

e a accao que se pretende realizar O elevado numero de combinacoes de tipos de

ordem de trabalho estados e accoes que existem num dado momento juntamente

com a sua possibilidade de alteracao obrigariam a implementacao de uma logica de

negocio complexa o que esta fora do ambito deste projecto

47

Desenvolvimento

Figura 410 Esquema UML que expressa os casos de uso do WOW Offline no modoldquoutilizador deciderdquo

463 Especificacao do modo ldquoaplicacao assume o estado offlinerdquo

A aproximacao para o modo ldquoaplicacao assume o estado offlinerdquo foi tambem

dividida em varias tarefas

1 Guardar informacao que permita a recriacao da pagina principal do lado do

cliente no estado offline (utilizando o Gears)

2 Dotar a aplicacao do cliente de um mecanismo de deteccao da ligacao

3 Identificar os ldquomomentos chaverdquo em que devera ocorrer sincronizacao de dados

4 Implementar a sincronizacao de dados

A sincronizacao de dados deve ser feita em ambas as transicoes online-offline e

offline-online quer para transferir novos dados do servidor (os pedidos podem ser

alterados por outros utilizadores) quando se transita do estado quer para comunicar

eventuais alteracoes feitas em modo offline

Relativamente ao WOW o WOW Offline na vertente ldquoaplicacao assume o es-

tado offlinerdquo vem alterar os seus casos de uso dando ao utilizador a possibilidade

de activar esta funcionalidade A partir do momento que a funcionalidade esta ac-

tivada o utilizador deve tambem ter a possibilidade de gerir algumas preferencias

relacionadas com privacidade de dados Devera ter a hipotese de desactivar o ar-

mazenamento local e de remover todos os dados ja armazenados tal como descrito

na Figura 411

48

Desenvolvimento

Figura 411 Esquema UML que expressa os casos de uso do WOW Offline no modoldquoutilizador deciderdquo

A primeira vez que o WOW Offline e acedido por um cliente e caso seja detec-

tada a presenca do Gears todos os recursos necessarios a sua execucao sao trans-

feridos Todos os acessos posteriores serao feitos a estes recursos locais (recorda-se

que o Gears pode ser utilizado para os manter actualizados recorrendo ao Managed-

ResourceStore 311)

Atraves do JavaScript e possıvel interceptar os eventos de load e unload da

pagina que sao despoletados sempre que ocorre um re-acesso da mesma (incluindo

a accao refresh comum dos browsers) sempre que esta e abandonada ou ainda ou

ainda se a janela for encerrada

Tal como sugerido na seccao 462 a camada de interface desta aplicacao (cada

pagina individual em HTML) devera ser implementada como sendo um template

para apresentacao de dados sendo totalmente preenchida atraves de funcoes em

JavaScript O objectivo deste ponto e criar um padrao de dados que permita ao

JavaScript preencher os dados em cada pagina (template) independentemente de

qual seja a fonte ndash o servidor remoto ou a maquina local tal como exemplificado

no diagrama da Figura 412 Na figura a aplicacao recorre ao servidor remoto para

obter os dados pretendidos quando se encontra na presenca de uma ligacao mas

para dados que exijam uma carga de processamento pelo servidor este acto pode ser

49

Desenvolvimento

Figura 412 Esquema UML que expressa o acto de recolha de dados em modo online eoffline recorrendo ao servidor (modo online) e ao sistema de armazenamento de dadoslocal fornecido pelo Gears (modo offline)

substituıdo pelo envio de um campo de controlo que se destina a aferir se os dados

locais se encontram actualizados No caso de estarem actualizados a comunicacao

com o servidor pode ser substituıda por uma query a base de dados local

50

Capıtulo 5

Resultados e Futuros

Desenvolvimentos

Todo o estudo feito sobre o tema OWA foi ja abordado ao longo do documento

Neste capıtulo apresentam-se os resultados obtidos na implementacao da prova de

conceito que visava compreender a melhor forma de disponibilizar uma versao of-

fline no WOW uma plataforma de gestao de ordens de trabalho ja existente de-

senvolvida pela Critical Software SA

51 Resultados Obtidos

Os resultados obtidos neste projecto sao extremamente satisfatorios uma vez

que o estudo do tema OWA e a implementacao de uma prova de conceito que o

ilustrasse foi conseguido com sucesso

A funcionalidade offline foi adicionada ao produto WOW da Critical Software

SA permitindo a visualizacao de ordens de trabalho e dos seus detalhes mesmo na

ausencia de uma conexao activa a Internet Embora para a solucao implementada

tenha sido utilizada uma abordagem do tipo ldquoutilizador deciderdquo pretende-se que esta

seja convertida para ldquoaplicacao deciderdquo ou mesmo para uma aproximacao hıbrida

semelhante a utilizada pelas aplicacoes estudadas nas seccoes 351 e 352

Para a sua implementacao descrita no capıtulo 4 foram tomadas decisoes de or-

dem pratica que permitissem tornar o trabalho exequıvel nos prazos dados Tentou-

se sempre que estas decisoes afectassem o mınimo em termos de desempenho e de

experiencia para o utilizador Considera-se que a implementacao do modo offline

com uma transicao entre modos do tipo ldquoutilizador deciderdquo (ver seccao 42) reflecte

o compromisso entre o desempenho pretendido e os recursos disponıveis e para alem

51

Resultados e Futuros Desenvolvimentos

de ser um exemplo eficaz das possibilidades que as OWA podem trazer a aplicacao

WOW desenvolvida pela Critical Software e tambem um estudo que pode ser uti-

lizado para analisar a implementacao desta tecnologia noutros produtos da mesma

empresa

Note-se que o principal objectivo do trabalho era ganhar familiaridade com este

tema entender as suas vantagens e desvantagens e compreender as suas limitacoes

Tudo indica que existam varias possibilidades de implementacao deste paradigma

noutros produtos da Critical Software que pela sua natureza podem tambem tirar

partido da execucao offline

52 Trabalho Futuro

O desenvolvimento do conceito e formas de implementacao de OWA continua

em forte desenvolvimento no entanto a sua adopcao ainda nao e generalizada A

dificuldade da sua implementacao em web applications ja existentes e o principal

obstaculo a sua maior divulgacao

Ha tambem um factor que deve ser tido em consideracao a manutencao de

codigo A implementacao de uma versao offline de uma web application requer

a implementacao das mesmas regras de negocio (ou de uma versao simplificada)

utilizadas no servidor Para que isto seja possıvel e necessario ter em conta a

capacidade de processamento do cliente e o factor de duplicacao de codigo que

tornara a aplicacao mais difıcil de manter uma vez que uma alteracao a logica de

negocio do servidor implica tambem uma alteracao a sua versao offline

A prova de conceito implementada permite ja a visualizacao offline dos pedidos

abertos (enviados e recebidos) que constam na pagina principal (este numero e

fixo e pode ser alterado pelo administrador) Uma funcionalidade desejavel seria a

possibilidade de interaccao com a aplicacao em modo offline e sincronizacao com o

servidor quando existisse uma ligacao disponıvel

Foi estudada a utilizacao do modo de execucao ldquoaplicacao assume o estado of-

flinerdquo descrito em 423 e esta seria a forma desejavel para o WOW Offline no

entanto para que esta opcao seja viavel sera necessaria a implementacao de uma

forma eficiente de sincronizacao e armazenamento de dados de uma forma relacional

Para atingir este objectivo podera ser seguida uma polıtica de automacao do pro-

cesso no qual a versao online da aplicacao gera scripts de criacao para as tabelas

necessarias na base de dados da versao offline (nao existe nenhuma ferramenta para

o fazer portanto seria necessaria a sua implementacao) e no qual as paginas HTML

disponibilizadas pelo servidor aos clientes web (browser) servem como templates de

apresentacao de informacao e sao preenchidas de forma semelhante pelo servidor ndash

quando a aplicacao estiver online ndash ou pelo cliente atraves de funcoes em JavaScript

52

Resultados e Futuros Desenvolvimentos

ndash quando a aplicacao estiver offline No entanto no WOW devido a quantidade de

informacao tratada e devido as complexas relacoes entre as diferentes entidades e

de esperar que a complexidade da implementacao de um mecanismo deste tipo torne

esta aproximacao demasiado custosa

O HTML 5 embora um forte candidato ainda nao esta suficientemente desen-

volvido A sua especificacao ainda tem o caracter de Draft (rascunho) e esta sujeita

a modificacoes e a aceitacao e implementacao por parte dos browsers e portanto

de momento foi desconsiderado No entanto no futuro se esta especificacao atingir

um estado de maturidade que permita a sua adopcao devera ser considerada como

um possıvel caminho a seguir

53

Resultados e Futuros Desenvolvimentos

54

Capıtulo 6

Conclusoes

Neste capıtulo sao apresentadas as conclusoes do projecto e consideracoes finais

relativamente a tecnologia estudada

61 Conclusoes

O rapido desenvolvimento tecnologico faz prever que a disponibilidade de ligacao

a Internet seja cada vez mais facil e mais rapido mas vao continuar a existir lugares

onde o acesso e limitado e onde as OWA podem desempenhar um papel de relevo

Por outro lado esta tecnologia pode tambem ser utilizada para melhorar o desem-

penho de paginas web com uma necessidade elevada de imagens ou outros recursos

dispendiosos em termos de espaco e foram ate estudados dois exemplos da utilizacao

desta vertente desta tecnologia em 353

Acredita-se que as OWAs vem responder a uma necessidade real por parte das

web applications actuais e que a evolucao que representam se compara a que se

assistiu dos thin-clients para os fat-clients em termos de autonomia do servidor

A capacidade de oferecer conteudos dinamicos no browser independentemente da

existencia de uma ligacao reune as vantagens tıpicas das web applications como

ausencia de instalacao e actualizacoes instantaneas com as vantagens das aplicacoes

de desktop em capacidade de processamento e armazenamento de dados na maquina

local

As tecnologias disponıveis ate a data estudadas no ambito deste projecto que

permitem o desenvolvimento de OWAs e que apresentam maior maturidade sao o

Gears e o Adobe AIR Ambas se apresentam sobre a forma de plugins que necessitam

de uma instalacao extra para poderem ser utilizadas Apesar de esta instalacao ser

55

Conclusoes

apenas necessaria uma vez podera constituir um factor de desencorajamento a sua

adopcao

O HTML 5 uma especificacao abordada neste documento na seccao 34 podera

ser uma alternativa que oferece funcionalidades offline a uma web application sem a

necessidade de qualquer instalacao no entanto esta especificacao ainda nao foi aceite

pelos principais browsers ndash o documento que define o HTML 5 ainda tem o estatuto

de Draft ndash e ainda nao e possıvel antecipar quando e que isto podera acontecer

Um dos problemas que surge frequentemente na implementacao de uma versao

offline para uma web application e a necessidade de sincronizacao de dados Quando

a informacao pode ser alterada por varios utilizadores simultaneamente e necessario

prever os conflitos que daı podem surgir e dotar a aplicacao de uma forma de os

resolver ou alertar o utilizador para a necessidade de alteracao dos dados

Em conclusao todos os objectivos propostos para este projecto foram atingidos

A prova de conceito implementada reflecte de forma clara as possibilidades oferecidas

pela tecnologia OWA e sera utilizado no futuro para compreender a melhor forma

de o implementar de forma definitiva no WOW

56

Referencias

[Ada08] Lucas Adamski Introducing Adobe AIR security model Fevereiro de2008 Disponıvel em httpwwwadobecomdevnetairarticles

introduction_to_air_securityhtml acedido em Marco de 2008

[Ado08] Adobe Adobe AIR 10 Security White Paper 2008 Disponıvel emhttpdownloadmacromediacompubairdocumentation1air_

securitypdf acedido em Marco de 2008

[Alm08] Dion Almaer Gears as a bleeding-edge html 5 implementa-tion March 2008 Disponıvel em httpalmaercomblog

gears-as-a-bleeding-edge-html-5-implementation acedido emMarco de 2008

[BL96] Tim Berners-Lee The world wide web Past present and future Agostode 1996 Disponıvel em httpwwww3orgPeopleBerners-Lee

1996ppfhtml acedido em Abril de 2008

[CDGH08] Mike Chambers Daniel Dura Dragos Georgita and Kevin Hoyt AdobeAIR for JavaScript Developers OrsquoReilly Media 2008 Disponıvel emhttponairadobecomfilesAIRforJSDevPocketGuidepdf ace-dido em Abril de 2008

[Con99] Jim Conallen Modeling Web Application Architectures with UML Junho1999 Disponıvel em httpwwwumlorgcnUMLApplicationpdf

webappspdf acedido em Maio de 2008

[Ent07] Entrust What is a public key information 2007 Disponıvel em http

wwwentrustcompkihtm acedido em Junho de 2008

[Gar05] Jesse James Garret Ajax A new approach to web applicationsFebruary 2005 Disponıvel em httpwwwadaptivepathcomideas

essaysarchives000385php acedido em Marco de 2008

[Greon] Philip Greenspun Philip and Alexrsquos Guide to Web Publishing 2003(last revision) Disponıvel em httpphilipgreenspuncompandaacedido em Junho de 2008

[Gro02a] App Design Group Thick vs thin client comparison 2002 Disponıvelem httpwwwdonjacobsvwcomimagesweekendspecials

Thick-vs-Thinpdf acedido em Junho de 2008

57

REFERENCIAS

[Gro02b] Technical Research Group Thin Client Tecnhology - WhitePaper 2002 Disponıvel em httpwwwpicktrgcompubs

thinclientwhitepaperpdf acedido em Junho de 2008

[Gro08] Miniwatts Marketing Group World internet usage March 2008Disponıvel em httpwwwinternetworldstatscomstatshtm ace-dido em Abril de 2008

[Hic08] Ian Hickson HTML 5 Draft Recommendation 2008 Disponıvelem httpwwwwhatwgorgspecsweb-appscurrent-work ace-dido em Marco de 2008

[Kha] Olga Kharif Top 10 municipal wifi plans Disponıvel em http

imagesbusinessweekcomss0608muni_wifiindex_01htm ace-dido em Marco de 2008

[Lab07] Mozilla Labs Prism Outubro 2007 Disponıvel em httplabs

mozillacom200710prism acedido em Marco de 2008

[Loo06] Chris Loosley Rich Internet ApplicationsDesign MeasurementandManagement Challenges 2006 Disponıvel em httpwwwkeynote

comdocswhitepapersRichInternet_5pdf acedido em Maio de2008

[Mic08] Microsoft Introduction to Occasionally Connected Applications us-ing Sync Services for ADONET 2008 Disponıvel em httpmsdn

microsoftcomen-ussyncbb887608aspx acedido em Junho de2008

[Nao08] Erica Naone Offline web applications Abril 2008 Disponıvelem httpwwwtechnologyreviewcomread_articleaspxch=

specialsectionsampsc=emerging08ampid=20245 acedido emAbril de 2008

[NJN00] Jason Nieh Yang S Jae and Naomi Novik A comparison of thin-clientcomputing architectures 2000 Disponıvel em httpwwwnclcs

columbiaedupublicationscucs-022-00pdf acedido em Maio de2008

[OrsquoR06] Tim OrsquoReilly Web 20 compact definition Trying again Dezembro2006 Disponıvel em httpradaroreillycomarchives200612

web-20-compact-definition-tryihtml acedido em Marco de 2008

[OrsquoR09] Tim OrsquoReilly What is Web 20 Design patterns and business modelsfor the Next Generation of Software 20053009 Disponıvel emhttpwwworeillynetcompubaoreillytimnews200509

30what-is-web-20html acedido em Marco de 2008

[Rus06] Alex Russel Comet Low latency data for the browser March Marco2006 Disponıvel em httpalexdojotoolkitorgp=545 acedidoem Marco de 2008

58

REFERENCIAS

[Sad97] Darleen Sadoski Clientserver software architecturesndashan overviewAgosto 1997 Disponıvel em httpwwwseicmuedustr

descriptionsclientserver_bodyhtml acedido em Junho de2008

[Sch96] George Schussel Clientserver past present and future 1996

[Smi07] Kevin C Smith Css filters - will the browser apply the rule July 2007Disponıvel em httpcentriclecomrefcssfilters acedido emMarco de 2008

[vK08] Anne van Kesteren The XMLHttpRequest Object W3C Work-ing Draft 15 Abril 2008 Disponıvel em httpwwww3orgTR

XMLHttpRequest acedido em Abril de 2008

[Wil06] Greg Wilkins Why ajax comet July Julho 2006 Disponıvel emhttpwwwwebtidecomdownloadswhitePaperWhyAjaxhtml ace-dido em Abril de 2008

59

REFERENCIAS

60

Anexo A

Screenshots

Algumas imagens de aplicacoes que utilizam funcionalidades offline ilustrativasda tecnologia abordada neste documento

Figura A1 Dialogo apresentado ao utilizador na primeira activacao das funcionalidadesoffline no Google Docs amp Spreadsheets

61

Screenshots

Figura A2 Na activacao das funcionalidades offline e tambem oferecida a possibilidadeda criacao de alguns atalhos por exemplo no ambiente de trabalho

Figura A3 O Google Docs mantem a todo o momento a possibilidade de alteracao destasdefinicoes ou da anulacao dos servicos offline para um dado computador

62

Screenshots

Figura A4 Apos a instalacao do Gears qualquer visita ao Remember The Milk despoletauma sincronizacao que ocorre automaticamente e sem necessidade de intervencao por partedo utilizador

Figura A5 Apos completar a sincronizacao de dados mesmo que a ligacao a Internetseja perdida o Remember the Milk continua disponıvel no browser (com excepcao dasfuncionalidades que pela sua natureza exigem uma ligacao como por exemplo partilhade tarefas e envio de convites)

63

Page 14: O ine Web Applications

Lista de Tabelas

21 Comparacao entre thin-clients e fat-clients 7

31 Comparacao das funcionalidades oferecidas pelo Adobe AIR para asplataformas web e desktop 30

32 Resumo da utilizacao de tecnologias OWA em algumas web applica-tions consideradas na analise do estado da arte 31

xi

LISTA DE TABELAS

xii

Glossario

fat-client Cliente que nao depende totalmente de umservidor central para as suas actividadesde processamento e possui frequentementedispositivos de armazenamento de dados

6ndash8

thin-client Cliente que depende de um servidor centralpara as suas actividades de processamento

5ndash8

web application Sistema web (servidor rede HTTPbrowser) onde accoes do utilizador(navegacao e introducao de informacao)afectam o estado logico da aplicacao

i iii1ndash311ndash1517ndash1921ndash232728 3336ndash3842 5556

API Application Programming Interface 10 1718 2326 28

ASP Linguagem interpretada pelo servidorque permite a criacao de paginas webdinamicas Desenvolvida pela Microsoft

11

BSD Berkeley Software Distribution 28

CSS Cascading Style Sheets 12 2021 2324 46

DHTML Dynamic HyperText Transfer Protocol 24DOM Document Object Model 10 12

20 2324

DTD Document Type Definition 24

xiii

Glossario

ECMAScript Padrao de linguagem de programacaodefinido pela Ecma International que orig-inou o JavaScript e o JScript

24

Flash Conteudo interactivo de um ficheiro emformato SWF E desenvolvido pela Adobee visualizado atraves do Adobe FlashPlayer

21

Flex Framework baseada em XML e Action-Script desenvolvida pela Adobe para a pro-gramacao de Rich Internet Applications(RIA)

21

GPL GNU General Public License 23

HTML HyperText Markup Language 1 10ndash12 2124ndash2649

HTTP HyperText Transfer Protocol 2 26

JMS E uma API em Java que permite a troca demensagens entre componentes de software

42

JSON JavaScript Object Notation permite atroca de dados codificados num formatode texto de simples leitura

12 1828 34

LGPL GNU Lesser General Public License 23

Mozilla Prism Browser simplificado e ldquointerpretadorrdquo deeXtensible User Interface Language (XUL)(tambem designado por XULRunner) queacolhe web applications sem a interfacegrafica habitual de um browser

25

MPL Mozilla Public License 23

OCA Occasionally Connected Application 39OWA Offline Web Application i iii

2ndash515 1725 2628 3133 3651 5255 56

PDF Portable Document Format 21

xiv

Glossario

PHP Linguagem interpretada pelo servidorque permite a criacao de paginas webdinamicas mas que pode tambem ser in-vocada a partir da linha de comandos

11

pagina web estatica Pagina web que devolve sempre a mesmaresposta a todos os pedidos para todos osutilizadores e em qualquer contexto

5 9

RIA Rich Internet Applications web appli-cations que apresentam funcionalidadessemelhantes as desktop applications masque mantem a informacao no lado do servi-dor

5 1520 28

RSS Really Simple Syndication 27

SLA Service Level Agreement 40SQLite Segundo a definicao oficial SQLite is a

software library that implements a self-contained serverless zero-configurationtransactional SQL database engine

17

SSB Site Specific Browser 25SSL Secure Sockets Layer 22SWF ShockWave Flash 21

URL Uniform Resource Locator 18

VPN Virtual Private Network 38

WOW Work Orders Web Plataforma de gestaode ordens de trabalho e do seu fluxo de-senvolvida pela Critical Software SA

i iii28 3340ndash434551ndash5356

WWW World Wide Web 11 1214

XBL eXtensible Binding Language 24XHTML eXtensible HyperText Markup Language 12XML eXtensible Markup Language 11 12

23 2428

XSLT eXtensible Stylesheet Language Transfor-mation

12

XUL eXtensible User Interface Language xiv23ndash25

xv

Glossario

xvi

Capıtulo 1

Introducao

Neste capıtulo enquadra-se o tema do projecto introduzindo alguns dos conceitos

nos quais se baseia Apresentam-se as motivacoes ambito objectivos e a estrutura

deste documento

11 Enquadramento

A Internet foi originalmente concebida para ser um espaco de partilha de in-

formacao onde pessoas (atraves de maquinas) pudessem comunicar Na sua origem

as paginas eram estaticas constituıdas por texto formatado em HyperText Markup

Language (HTML) e ligadas entre si [BL96] Hoje encontramos conteudos cada vez

mais complexos e dinamicos incluindo som vıdeo ou streams multimedia [Loo06] e

em 2005 foi introduzido por [OrsquoR09] o termo Web 20

De acordo com [Greon] um website pode pertencer a uma ou varias das seguintes

categorias

bull Documento ndash um website essencialmente estatico onde alteracoes a uma

parte do conteudo nao tem implicacoes no seu comportamento

bull Base de dados ndash um directorio de informacao organizada em categorias

bull Aplicacao ndash um website dinamico que utiliza uma linguagem executada ou

interpretada do lado do servidor e que processa as accoes ou informacao in-

troduzida pelo utilizador para fornecer um servico ou nova informacao

A ultima destas categorias constitui aquilo que e normalmente designado por

web application O conceito utilizado ao longo deste documento e o mesmo que

o introduzido por Jim Coallen em [Con99] que define web application como um

1

Introducao

sistema web (servidor rede HyperText Transfer Protocol (HTTP) browser) onde

accoes do utilizador (navegacao e introducao de informacao) afectam o estado logico

da aplicacao A sua definicao tenta estabelecer que uma web application e um

sistema de software com estado de negocio1 e que a sua interface de interaccao com

o utilizador e distribuıdo atraves de um sistema web

12 Motivacao

A quantidade de informacao que e produzida e armazenada com recurso a es-

tas web applications disponıveis online tais como e-mail blogues ou mesmo docu-

mentacao tornam por vezes a disponibilidade de ligacao uma condicao necessaria

a produtividade e como consequencia desta barreira muitos potenciais utilizadores

opoem-se a adopcao de produtos web em detrimento das tradicionais desktop appli-

cations

Assegurar o acesso a uma ligacao de Internet e hoje muito mais facil A Internet

movel e ja uma realidade e encontra-se amplamente divulgada mas continuam a

existir diversas situacoes nas quais os utilizadores estao privados de uma ligacao

a Internet tais como uma viagem de metro ou de aviao ou quando se encontram

deslocados do seu paıs de origem e nao possuem nenhum plano de subscricao

Uma OWA consiste numa web application que para alem de manter todas as

caracterısticas anteriores se mantem disponıvel mesmo na ausencia de uma ligacao

a Internet e surge como uma tentativa de estreitar as barreiras existentes entre a

web e o desktop Isto significa que devera existir um mecanismo capaz de assegurar

a manutencao do estado logico da aplicacao quando a ligacao com o servidor e

quebrada permitindo ao utilizador continuar a utilizar a aplicacao e que sera capaz

de informar o servidor do estado em que a aplicacao se encontra quando a ligacao for

reposta A principal vantagem que advem desta possibilidade e evidente eliminar

a necessidade da existencia de uma ligacao a Internet para que a aplicacao possa ser

utilizada

Por outro lado a vontade de integracao de funcionalidades tıpicas das desktop

applications nas web applications foi um dos principais factores que impulsionou o

desenvolvimento deste conceito uma vez que obrigou a uma reflexao ldquopara alem

do browserrdquo e a uma adaptacao das arquitecturas existentes que permitisse ou o

acesso a funcionalidades disponibilizadas pelo sistema operativo ou pelo menos a

funcionalidades semelhantes Pretende-se com esta aproximacao tornar possıveis

interaccoes entre o desktop e o browser tais como arrastar um ficheiro para um

formulario web de upload de conteudos melhor suporte para o historico do clipboard

ou ainda o acesso ao sistema de ficheiros local Atingir estes objectivos reflecte-se

1NT business state

2

Introducao

num novo paradigma que reune as vantagens das web applications tais como os

updates instantaneos ou o facto de nao ser necessaria nenhuma instalacao e das

desktop applications como por exemplo persistencia no armazenamento de dados

acesso a funcionalidades do sistema operativo ou integracao e interaccao com outras

aplicacoes sejam elas web applications ou desktop applications

13 Ambito

Este projecto foi realizado na Critical Software SA no ambito do Mestrado

Integrado em Engenharia Informatica e Computacao (MIEIC) da Faculdade de En-

genharia da Universidade do Porto (FEUP) entre os meses de Fevereiro e Julho de

2008

14 Objectivos

Sao objectivos deste projecto

1 Estudar e documentar o tema das OWAs acompanhando os ultimos desenvolvi-

mentos nesta materia

2 Analisar o estado da arte fazendo uma analise crıtica e objectiva sobre as

diversas metodologias existentes

3 Implementar uma prova de conceito que permita a execucao offline de uma

web application documentando todo o processo

4 Estudar a possibilidade de permitir interaccao com a aplicacao (insercoes e

alteracoes aos dados) em modo offline

Em resumo o objectivo deste projecto foi estudar documentar e implementar

uma prova de conceito relacionada com o tema Offline Web Applications (OWA)

Este tema embora nao seja totalmente novo ganhou destaque ao longo do ano de

2007 com o surgimento de diversas ferramentas que se destinam a aproximar web

applications das desktop applications

15 Estrutura do documento

Este documento esta organizado em diferentes seccoes apresentando o projecto

numa sequencia logica organizada da seguinte forma

No capıtulo 1 faz-se uma breve apresentacao do conceito OWAs e do contexto em

que surge Apresenta-se tambem a estrutura do documento e definem-se os

termos e acronimos utilizados

3

Introducao

No capıtulo 2 faz-se uma descricao da evolucao das tecnologias que antecedem as

OWAs e das vantagens e desvantagens de cada uma como forma de enquadra-

mento

No capıtulo 3 analisa-se o estado da arte nesta materia Introduzem-se diversas

tecnologias directamente relacionadas com o tema deste projecto exemplos de

aplicacoes que as usam e as razoes que fundamentam as escolhas de tecnologias

efectuadas

O capıtulo 4 contem o desenvolvimento do projecto Analisa-se a plataforma

WOW de gestao integrada de ordens de trabalho a tecnologia escolhida e

a forma como foi utilizada para implementar a capacidade de execucao offline

O capıtulo 5 descreve os resultado obtidos comparando-os com as expectativas

iniciais do projecto e apresenta desenvolvimentos futuros e possibilidades de

continuacaoaplicacao do conhecimento adquirido

No capıtulo 6 apresentam-se as conclusoes

4

Capıtulo 2

Enquadramento do Projecto

Neste capıtulo apresenta-se um breve resumo da evolucao das arquitecturas de

software cliente-servidor e a forma como estas se comparam a evolucao da Inter-

net procurando estabelecer uma analogia entre o percurso de ambas as tecnolo-

gias Compara-se o comportamento e arquitectura dos thin-clients as paginas web

estaticas a evolucao dos fat-clients as paginas interactivas Web 20 e Ajax e

defende-se que as OWA constituem um proximo passo logico e evolutivo aproxi-

mando a web do desktop Referem-se ainda os principais factores que justificam a

importancia das OWAs e a estreita relacao que tem com as Rich Internet Application

(RIA)s

21 Evolucao das arquitecturas de software

Os termos thin-client e fat-client sao utilizados quer para descrever arquitecturas

logicas (de software) quer para descrever arquitecturas fısicas (de hardware) Neste

capıtulo excepto quando seja dada indicacao em contrario estes termos referem-se

sempre a uma arquitectura logica

Adicionalmente quando se trata de arquitecturas cliente-servidor pode-se estu-

dar a arquitectura desenvolvida do sistema como um todo da arquitectura do servi-

dor ou da arquitectura do cliente Para evitar equıvocos em especial na seccao 213

especifica-se em cada caso qual o sistema estudado

211 Thin-clients

Um thin-client e um computador cliente ou software cliente que no contexto

de uma arquitectura cliente-servidor depende de um servidor central para as suas

5

Enquadramento do Projecto

actividades de processamento e proporciona um canal de entrada e saıda de in-

formacao entre o utilizador e o servidor remoto Este termo quando aplicado a

hardware refere-se habitualmente a um computador que se destina a ser utilizado

como cliente de rede sem armazenamento local e com capacidade de processamento

reduzida [Gro02b] mas o conceito que aqui se analisa refere-se a uma arquitectura

de software que remonta ao inıcio das aplicacoes cliente-servidor

No inıcio da historia da computacao terminais ligavam-se directamente a main-

frames responsaveis por todo o processamento Nesta arquitectura era necessario

desenvolver duas aplicacoes distintas uma aplicacao central no servidor (main-

frame) responsavel pela gestao de toda a informacao e por todas as operacoes de

comunicacao e uma aplicacao de visualizacao instalada no cliente (terminal) O

papel destes terminais era apenas disponibilizar ao utilizador um meio de comu-

nicacao (entrada e saıda) e apresentacao dos resultados do servidor Nao tinham

um papel activo no calculo nem na logica de negocio e frequentemente nao tinham

tambem nenhum mecanismo de armazenamento de dados

Como vantagens esta arquitectura apresenta uma reduzida necessidade de con-

figuracao e manutencao do lado do cliente Uma vez que o centro do processamento

e manipulacao de dados ocorre no servidor existe tambem uma centralizacao da

informacao [NJN00] que introduz um ponto crıtico de falha1 Actualizacoes e novas

funcionalidades sao faceis de distribuir uma vez que requerem apenas alteracoes no

servidor [Gro02a]

212 Fat-clients

Contrastando com os thin-clients nesta arquitectura os clientes implementam

ja uma parte da logica de negocio e sao responsaveis pelo processamento de dados

Estes fat-clients vieram responder a necessidade crescente de aplicacoes com um

nıvel de interactividade e capacidade de configuracao maior que as oferecidas pela

arquitectura thin-client descrita na seccao 211 Apesar de manterem a sua de-

pendencia do servidor podem tambem ser executados sem uma conexao activa uma

vez que dispoe de armazenamento de dados local o que lhes confere a capacidade

de persistencia de dados e do estado de execucao entre cada sessao

Foi disponibilizando este controlo sobre o estado da aplicacao bem como acesso

a recursos locais (por exemplo sistema de ficheiros e perifericos) que surgiram as

primeiras verdadeiras desktop applications No entanto cada cliente tinha que ser

separadamente instalado no computador pessoal de cada utilizador que pretendesse

utilizar ou interagir com a aplicacao e uma actualizacao ao servidor implicava in-

variavelmente uma actualizacao manual tambem no cliente Uma vez que nem todos

1NT single point of failure

6

Enquadramento do Projecto

Thin-clients Fat-clientsNao toma parte no processamento dedados nem possui acesso ao sistema deficheiros

Participa activamente no processa-mento de dados recorrendo ao sis-tema de armazenamento local para ar-mazenamento de dados

Nao mantem registo do estado logicoda aplicacao entre duas sessoes de uti-lizacao

O acesso ao armazenamento localpermite-lhe manter registo do estadologico da aplicacao entre duas sessoes

O thin-client nao necessita de qualquerinstalacao estando ldquopronto a utilizarrdquo

E geralmente necessario instalar aaplicacao para poder interagir com oservidor

Qualquer update no servidor reflecte-seimediatamente por todos os clientes

Embora a aplicacao cliente possa aler-tar para existencia de novas versoes asactualizacoes tem que ser manualmenteinstalados pelo cliente

O software do cliente destina-se apenasa apresentacao de dados e comunicacaocom o servidor sendo portanto de sim-ples implementacao

Como o software do cliente toma parteactiva no processamento de dadosa sua implementacao requer cuidadosadicionais

Grande mobilidade uma vez que todaa informacao e mantida no servidor

Parte da informacao podera estar ape-nas do lado cliente pelo que existemalgumas restricoes a sua mobilidade

Tabela 21 Comparacao entre thin-clients e fat-clients

os utilizadores actualizam regularmente as suas aplicacoes o servidor tem que estar

preparado para lidar com versoes antigas2 ou descontinuar os seus servicos a uma

parte da sua comunidade de utilizadores ate que estes actualizem os seus sistemas

Como os utilizadores passam a utilizar os seus recursos locais para armazenamento

de dados as alteracoes que nao sejam sincronizadas com o servidor estao apenas

disponıveis nos seus computadores pessoais o que introduz uma restricao a mobili-

dade

Pode-se afirmar que as vantagens dos thin-clients sao as desvantagens dos fat-

clients e que as vantagens dos fat-clients sao as vantagens dos thin-clients tal como

se ilustra na Tabela 21

213 Arquitecturas cliente-servidor

Introduzidos os termos thin-client e fat-client interessa reafirmar que ambos

podem ser vistos como arquitecturas cliente-servidor Um cliente define-se como

um solicitador de servicos e um servidor como um prestador de servicos tal como

definido por [Sch96] e [Sad97]

2NT backward compatibility

7

Enquadramento do Projecto

As arquitecturas cliente-servidor sao categorizadas pela modularizacao com que

sao desenhadas sendo consideradas as seguintes camadas

1 Interface grafica (front-end) atraves da qual os utilizadores interagem com

a aplicacao Quando este modulo e implementado separadamente dos outros

dois constitui uma aplicacao thin-client por si so uma vez que nao implementa

regras de negocio (embora possa definir validacoes de formularios de insercao de

dados por exemplo) A informacao introduzida pelo utilizador e enviada para

o servidor que processa o seu pedido e retorna uma resposta Este processo

repete-se ate que o utilizador atinja o seu objectivo ou se desligue do sistema

2 A logica de negocio tambem designada por camada intermedia que imple-

menta as regras de aceitacao e validacao de todos os dados introduzidos pelo

utilizador E tambem a plataforma de comunicacao que une a camada superior

de visualizacao com a camada de acesso a dados

3 A camada de dados inclui quer o sistema de persistencia de dados onde sao

armazenados os dados relevantes como tambem os mecanismos necessarios

para a sua pesquisa seleccao e alteracao

Os thin-clients quando observados no seu conjunto de cliente e servidor podem

ser vistos quer como sistemas de duas camadas quer como sistemas de tres camadas

dependendo apenas da forma como o servidor for implementado No caso de na

implementacao do servidor nao se distinguir a camada de acesso a dados da camada

da logica de negocio sao designados por sistemas de duas camadas Caso seja feita

esta distincao sao designados por sistemas de tres camadas Ambos os casos sao

ilustrados na Figura 21

Historicamente os fat-clients eram implementados numa arquitectura em duas

camadas Possuıam apenas um modulo de visualizacao de dados designado por

camada de interface e um modulo que implementava toda a logica de negocio e

regras de acesso a base de dados No entanto com a introducao de ligacoes mais

rapidas e de computadores pessoais com maior capacidade de processamento e so-

bretudo devido a complexidade crescente das aplicacoes a logica de negocio e a

camada de acesso a dados tornaram-se independentes Este modelo e designado por

arquitectura em tres camadas e e ilustrado na Figura 22

22 Evolucao na Internet

Ao analisar a evolucao das arquitecturas das aplicacoes desenvolvidas para a

Internet podemos encontrar um paralelismo com a historia da arquitectura de soft-

ware

8

Enquadramento do Projecto

Figura 21 Arquitectura de um sistema thin-client em duas camadas (a esquerda) e emtres camadas (a direita) Note-se a inclusao do servidor (mainframe) na definicao dascamadas desta arquitectura devido a forte dependencia cliente-servidor

221 Paginas web estaticas

Uma pagina web estatica devolve sempre a mesma resposta a todos os pedidos

para todos os utilizadores e em qualquer contexto utilizando o hipertexto como

forma de ligacao entre diversas paginas estaticas

A informacao e armazenada num servidor e o papel do cliente e apenas a apre-

sentacao da informacao Esta forma de disponibilizacao de informacao pode assim

ser comparada com os thin-clients descritos na seccao 211 o utilizador acede a

um website estatico para visualizar informacao sem que o cliente tome parte no

processamento A unica diferenca e que no caso da web estatica a informacao ap-

resentada e sempre a mesma enquanto que nos thin-clients era frequente existir a

possibilidade de insercao de dados no cliente e apos o seu processamento servidor

nova informacao poderia ser apresentada O hipertexto e utilizado para ligar as

paginas entre si numa rede de conteudos relacionados e a navegacao sıncrona era

feita atraves de cliques do rato a cada clique uma nova pagina era apresentada

Este modelo sıncrono e ilustrado na Figura 23

222 Paginas web interactivas e paginas web dinamicas

O JavaScript e uma linguagem interpretada de scripting que tem os browsers

como principal ambiente de acolhimento Os browsers utilizam uma Application

9

Enquadramento do Projecto

Figura 22 Arquitectura de um fat-client em duas camadas (a esquerda) e em tres camadas(a direita)

Programming Interface (API) publica para criar ldquoobjectosrdquo responsaveis por reflectir

e disponibilizar o Document Object Model (DOM) para o motor de JavaScript

A utilizacao mais frequente desta linguagem e a escrita de funcoes que sao em-

bebidas ou incluıdas em paginas web e que interagem com o DOM Uma vez que o

JavaScript e executado localmente (na maquina do cliente e nao no servidor) e capaz

de responder rapidamente a accoes do utilizador tornando a execucao de aplicacoes

no browser mais fluıdas o JavaScript pode tambem detectar accoes do utilizador

que o HTML nao pode tal como o pressionar de uma tecla

Em Dezembro de 1995 a Netscape Communications adicionou suporte para o

JavaScript no browser Netscape Navigator3 e em Agosto de 1996 o browser Internet

Explorer4 da Microsoft passou a tambem a suportar uma versao semelhante desta

linguagem (hoje todos os principais browsers suportam esta tecnologia)

Esta inovacao permitiu tornar os websites mais interactivos mas a sua utilizacao

esteve confinada apenas a este proposito durante um longo perıodo As paginas

passaram a responder activamente a accoes do utilizador (sendo uma das utilizacoes

3Netscape Communications ndash httpbrowsernetscapecom4Microsoft Internet Explorer ndash httpwwwmicrosoftcomwindowsproductswinfamilyie

10

Enquadramento do Projecto

mais vulgares a validacao de formularios) mas continuaram essencialmente estaticas

O JavaScript ainda nao era nesta altura utilizado para processar dados

Tambem nesta altura (1995ndash96) surgiram linguagens server-side como o PHP

Hypertext Preprocessor (PHP) e Active Server Pages (ASP) e o servidor passou a ter

um processamento de dados introduzidos pelo utilizador mais activo Generalizaram-

se as paginas dinamicas capazes de responder a insercao de dados ou outros pedidos

determinados por accoes do utilizador As paginas tornaram-se aplicacoes web ap-

plications

Uma definicao tradicional de web application e um conjunto de paginas web

logicamente agrupadas e geridas por uma unica entidade que tem como pontos de

entrada formularios de insercao de dados (web forms) Uma web application nao e

mais do que uma aplicacao que e acedida atraves de um browser Tem geralmente

uma arquitectura logica em tres (interface logica de negocio e camada de dados)

camadas e estao armazenadas num servidor

Ha dois tipos de web applications

bull Orientadas a apresentacao Sao web applications que geram paginas web in-

teractivas constituıdas por varios tipos de linguagens de anotacao (por exem-

plo HTML eXtensible Markup Language (XML)) e que apresentam conteudo

dinamico como resposta a pedidos efectuados pelo utilizador

bull Orientadas aos servicos Uma web application orientada aos servicos imple-

menta o ponto de acesso para um ou mais de um web service Sao geralmente

clientes de service oriented web applications

Uma vantagem significativa de implementar uma web application de forma a

suportar as funcionalidades padrao dos browsers e que estas terao o mesmo com-

portamento independentemente da plataforma e do browser a partir do qual serao

acedidas No entanto diferentes implementacoes de browsers devido a diferentes

interpretacoes dos padroes definidos tornam por vezes esta tarefa um pouco mais

complicada existindo inclusivamente na web guioes de compatibilidade para os difer-

entes browsers como [Smi07]

223 Web 20 e Ajax

O termo web 20 descreve uma tendencia de utilizacao e de design observada

na World Wide Web (WWW) com o objectivo de melhorar a criatividade partilha

de informacao e principalmente a colaboracao entre utilizadores Estes conceitos

levaram ao desenvolvimento e evolucao de comunidades online tais como redes so-

ciais wikis e blogues

11

Enquadramento do Projecto

O termo tornou-se mais conhecido apos a primeira conferencia OrsquoReilly Media

Web 20 em 2004 e apesar de sugerir uma nova versao da WWW nao se refere a

qualquer evolucao tecnologica mas apenas a alteracoes a forma como os utilizadores

se servem da web De acordo com Tim OrsquoReilly [OrsquoR06] ldquoWeb 20 e uma revolucao

na industria do software causada pela adopcao da web como uma plataforma e pela

tentativa de entendimento das regras para o sucesso nesta nova plataformardquo

O desenvolvimento da Web 20 serve-se muitas vezes de um outro conceito Ajax

O conceito que hoje conhecemos como Ajax muitas vezes incorrectamente de-

scrito como uma tecnologia foi originalmente criado para permitir o desenvolvimento

de web applications que se assemelhassem ainda mais a aplicacoes de desktop Este

conceito foi melhor descrito por [Gar05] como um conjunto de varias tecnologias

que podem ser utilizadas para melhorar a experiencia do utilizador de uma dada

web application introduzindo a capacidade assıncrona de envio de pedidos ou da

recepcao assıncrona de respostas As tecnologias mais frequentemente envolvidas

sao

bull eXtensible HyperText Markup Language (XHTML) e Cascading Style Sheets

(CSS) padrao para a apresentacao

bull interaccao dinamica atraves do DOM

bull troca e manipulacao de dados utilizando XML e eXtensible Stylesheet Lan-

guage Transformation (XSLT) ou JavaScript Object Notation (JSON)

bull pedidos assıncronos utilizando XMLHttpRequest [vK08]

bull JavaScript utilizado para integrar todas estas tecnologias

E importante frisar que o Ajax nao e um produto nem uma tecnologia E um

termo que descreve a utilizacao de um conjunto de tecnologias para o desenvolvi-

mento de web applications com um elevado grau de interactividade Comparativa-

mente as web applications tradicionais o Ajax introduz uma camada de visualizacao

diferente em tres importantes pontos

1 Do lado do cliente existe um motor que serve de intermediario entre a interface

da aplicacao e o servidor

2 A actividade do utilizador despoleta chamadas JavaScript em vez de um pedido

de pagina directamente ao servidor

3 Informacao codificada em XML em vez de paginas HTML e trocada entre o

servidor e o cliente

12

Enquadramento do Projecto

Isto significa que as paginas que utilizam Ajax contem um motor do lado do

cliente composto por um conjunto de funcoes JavaScript responsavel pela comu-

nicacao com o servidor e por actualizar a interface com o resultado dessa mesma

comunicacao

Na Figura 23 ilustra-se a natureza assıncrona do Ajax quando comparada com

as web applications tradicionais Como se pode observar adicionando um mecan-

ismo Ajax a uma web application eliminam-se diversos tempos de espera associados

a comunicacoes com o servidor uma vez que a interface nao fica ldquobloqueadardquo a es-

pera da resposta Obtem-se assim aplicacoes com um comportamento mais fluido

eliminando tempos de espera entre cada ldquocliquerdquo e melhorando a experiencia do

utilizador

23 Offline Web Applications

A informacao grafica (bem como folhas de estilo e scripts) tais como as ima-

gens que constituem o visual de uma web application e ja tratada de forma especial

pelos cada vez mais avancados sistemas de cache (armazenamento temporario) dos

browsers Mas estes nao sao ainda capazes de guardar conteudo criado pelo uti-

lizador nem de apresentar informacao independentemente do estado da ligacao

Numa altura onde se fala de servicos de Internet wireless municipalizados [Kha]

comunicacoes 3G e ligacoes de banda larga a alta velocidade a ligacao a rede global

continua a nao estar permanentemente disponıvel para os utilizadores Na WWW

encontra-se uma importante parte da informacao e das aplicacoes utilizadas para

criar e editar conteudos Por vezes informacao vital para a produtividade pode

desaparecer subitamente do mapa de acesso de um utilizador quando este entra no

metro num aviao ou mesmo quando se desloca para uma cidade ou paıs diferente

do habitual onde nao subscreve um plano de acesso que lhe garanta a ligacao

Permitir o acesso offline a estes recursos assume assim a sua importancia porque

permitira estender o alcance da informacao a locais onde nunca esteve antes e per-

mitira tambem melhorar o desempenho das web applications colocando informacao

mais perto dos utilizadores reduzindo a transferencia de dados apenas ao essencial

24 Comparacao

Nas evolucoes descritas neste capıtulo 2 pode-se observar que existe um par-

alelismo entre a evolucao das arquitecturas tradicionais cliente-servidor e a evolucao

a que se assiste na web O comportamento e arquitectura dos thin-clients assemelha-

se ao das paginas estaticas no sentido em que o browser nao toma parte em qualquer

13

Enquadramento do Projecto

processamento e serve apenas como uma plataforma de interaccao com o servidor

tal como os clientes descritos na seccao 211

A sua proxima evolucao os fat-clients trouxeram parte da capacidade de pro-

cessamento para o lado do cliente Na web foi tambem esta a inovacao tecnologica

a que se assistiu com a evolucao das tecnologias que permitiram a criacao de ver-

dadeiras aplicacoes e com a introducao do Javascript no browser dando ao cliente

a capacidade de processamento de dados A necessidade da separacao do codigo

em camadas logicas advem da crescente complexidade das web applications Esta

pratica permite entre outras coisas melhorar o processo de desenvolvimento e a

capacidade de manutencao de uma aplicacao

Os fat-clients tem tambem a capacidade de armazenamento de dados o que

permite a persistencia de informacoes entre duas sessoes e que algumas operacoes

sejam executadas sem a necessidade de comunicacao com o servidor Este facto pode

tambem ser uma realidade nas web applications com a adopcao das tecnologias OWA

Neste momento assiste-se a uma utilizacao cada vez maior da web como uma

plataforma de desenvolvimento A capacidade de cooperacao na edicao de conteudos

e a mobilidade proporcionada por esta plataforma sao os principais factores que

alimentam esta mudanca e pela primeira vez as aplicacoes tradicionais tem com-

peticao vinda de web applications A prova do reconhecimento da web como plataforma

de desenvolvimento pode ser retirada da aposta de empresas como a Adobe e Mi-

crosoft que lancaram publicamente ferramentas web complementares a produtos

seus tradicionalmente associados ao desktop ndash Acrobatcom5 e Microsoft Office

Live6 Dotar estas web applications da capacidade de execucao offline significa

aproximar a web e o desktop reunindo ldquoo melhor de dois mundosrdquo

As vantagens da mobilidade possıvel atraves da web a cooperacao na criacao e

edicao de conteudos e a possibilidade de utilizar aplicacoes sempre actualizadas e

sem necessidade de instalacao sao algumas das principais vantagens que promovem

esta mudanca que devido as preocupacoes associadas a usabilidade e experiencia do

utilizador esta fortemente associada ao desenvolvimento de Rich Internet Applica-

tion (RIA)s

5Adobe Acrobatcom httpwwwacrobatcom6Microsoft ndash httpsmallbusinessofficelivecom

14

Enquadramento do Projecto

Figura 23 Comparacao do modelo de web aplications sıncrono paginas estaticas e in-teractivas abordados nas seccoes 221 e 222 com o modelo de web applications Ajax(assıncrono) abordado na seccao 223 Figura adaptada de http www adaptivepath

com

15

Enquadramento do Projecto

16

Capıtulo 3

Estado da arte

Apesar de o conceito das OWAs nao ser absolutamente novo as tecnologias que

o suportam sao recentes Neste capıtulo descrevem-se quatro tecnologias que foram

tidas como principais candidatas para o desenvolvimento deste projecto Descrevem-

se ainda alguns exemplos de web applications que disponibilizam actualmente fun-

cionalidades offline e o processo da escolha da tecnologia a utilizar neste projecto

31 Gears

O Gears1 e uma extensao as funcionalidades do browser introduzido pelo Google

que tem como principal objectivo tornar possıvel a visualizacao de paginas de Inter-

net mesmo sem uma conexao disponıvel Encontra-se disponıvel para as platafor-

mas Windows Macintosh e Linux e oferece uma API de Javascript que permite

a scripts aceder a um mecanismo de armazenamento local baseado numa base de

dados SQLite

311 Arquitectura

Esta ferramenta e constituıda por tres componentes principais

bull LocalServer mdash Intercepta pedidos de paginas web e serve-as localmente

bull Database mdash Uma base de dados relacional construıda sobre SQLite

bull WorkerPool mdash Permite executar operacoes de computacao de uma forma

assıncrona sem afectar a capacidade de resposta e fluidez de execucao da web

application Assemelham-se a processos

1Google Inc ndash Mais informacao em httpgearsgooglecom

17

Estado da arte

LocalServer

O modulo LocalServer e uma cache de Uniform Resource Locators (URLs)

controlada pela web application Quando nao existe uma ligacao a Internet e e

feito um pedido para um URL presente nesta cache o LocalServer intercepta-o e

responde ao pedido localmente a partir do disco rıgido do utilizador A aplicacao

pode utilizar dois tipos diferentes de armazenamento local de URLs

bull ResourceStore ndash serve para capturar URLs utilizando exclusivamente a API

de Javascript disponibilizada para o efeito Uma aplicacao podera criar e

utilizar diversos ResourceStores simultaneamente para capturar ficheiros de

dados que necessitam de ser enderecados por um URL tal como um ficheiro

PDF ou uma imagem

bull ManagedResourceStore ndash serve para capturar um conjunto de URLs que estao

relacionados e que sao declarado num ficheiro de manifesto (especificado em

JSON) e que sao automaticamente actualizados O ManagedResourceStore

permite que o conjunto de recursos necessarios para correr uma web application

seja capturado e mantido actualizado automaticamente

A principal diferenca entre estes dois tipos de armazenamento de URLs e a forma

como sao actualizados os seus conteudos Os conteudos de um ManagedResourceStore

sao actualizados sempre que a versao contida no ficheiro de manifesto for alterada

enquanto que os conteudos de um ResourceStore nunca sao actualizados automati-

camente mas apenas quando for explicitamente ordenado pela aplicacao

O LocalServer e capaz de interceptar e servir localmente pedidos de HTTP e

HTTPS sempre que se reunam as seguintes condicoes

1 O URL encontra-se armazenado num ResourceStore ou ManagedResourceStore

2 O sistema de armazenamento local encontra-se activo (enabled = true) Se

o sistema de armazenamento local tiver o atributo requiredCookie o pedido

devera conter um cookie que lhe corresponda

O LocalServer nao necessita de monitorizar o estado da ligacao para atender aos

pedidos Na verdade sempre que as condicoes previamente enunciadas se verificarem

o LocalServer interceptara os pedidos e independentemente do estado da ligacao

a Internet servi-los-a a partir do disco rıgido local Cabera a aplicacao definir qual

o modo em que pretende executar um pedido (online ou offline) definindo o valor

de verdade da propriedade enabled

18

Estado da arte

Database

O modulo Database permite guardar dados da web application assegurando a

sua persistencia Os dados sao guardados de forma relacional no disco rıgido do uti-

lizador2 de acordo com o modelo de seguranca estabelecido pelo Gears3 significando

que uma aplicacao nao pode aceder a conteudos fora do seu domınio

WorkerPool

Nos web browsers uma operacao pesada de computacao pode tornar a interface

lenta e tornar menos agradavel a experiencia do utilizador O modulo WorkerPool

permite correr operacoes em background sem bloquear a interface com o utilizador

Os scripts executados numa WorkerPool nao activam os mecanismos de seguranca

do browser que mostram a mensagem ldquoA script on this page may be busy or may

have stopped respondingrdquo

O WorkerPool comporta-se como um conjunto de processos em vez de threads

Os Workers nao partilham qualquer estado de execucao o que significa que uma

alteracao a uma variavel num Worker nao afecta em nada a execucao de outro

Worker Alem disso os Workers nao herdam automaticamente nenhum codigo dos

seus pais Cada Worker e membro de um WorkerPool e os Workers podem in-

teragir entre si enviando mensagens em formato de texto ou JSON No entanto ha

tambem algumas limitacoes os Workers nao tem acesso ao DOM e objectos como

window ou document nao se encontram acessıveis Isto e consequencia de os Workers

nao partilharem o estado de execucao Mas tem acesso a todas as funcoes built-in

do Javascript A maioria das funcionalidades do Gears pode tambem ser acedida

atraves de uma variavel global especial definida como googlegearsfactory Para

outras funcionalidades especıficas os Workers podem ldquopedirrdquo a pagina principal para

continuar a execucao atraves do envio de mensagens

Outras funcionalidades

bull HttpRequest ndash Este modulo implementa a especificacao W3C XmlHttpRe-

quest definida em [vK08] tornando-a disponıvel para os workers e para a

pagina principal

bull Timer ndash Este modulo implementa a especificacao de timers tal como descrito

por [Hic08] e torna-os disponıveis para os workers e para a pagina principal

2Consultar httpcodegooglecomapisgearsapi_databasehtmldirectories3Consultar httpcodegooglecomapisgearssecurityhtml

19

Estado da arte

bull Factory ndash Esta classe e utilizada para instanciar todos os outros objectos da

API do Gears atraves do seu metodo create Este metodo pode ser utilizado

com os seguintes parametros

ndash betadatabase

ndash betahttprequest

ndash betalocalserver

ndash betatimer

ndash betaworkerpool

312 Goggle Gears em dispositivos moveis

O Gears esta tambem disponıvel em dispositivos Windows Mobile 5 e 6

Os dispositivos moveis estao pela sua natureza frequentemente desconectados

da Internet Mesmo quando possuem uma ligacao as latencias na transferencia de

dados em redes moveis tornam as aplicacoes pouco fluıdas mas o Gears permite

ultrapassar este obstaculo

O Gears funciona exactamente da mesma forma em dispositivos moveis equipados

com o Windows Mobile 5 e 6 como num computador comum Se uma aplicacao tiver

sido implementado com suporte para o Gears entao tambem estara preparada para

ser executada num dispositivo movel mas as limitacoes dos browsers disponıveis

para dispositivos moveis tem que ser consideradas Isto significa prever as condicoes

que permitam uma boa usabilidade devido aos pequenos ecras destes dispositivos

bem como o seu suporte limitado dos padroes do DOM CSS e JavaScript

32 Adobe AIR

O Adobe AIR4 e um runtime compatıvel com diversos browsers e sistemas opera-

tivos que pretende dar aos programadores a possibilidade de combinar diversas tec-

nologias de producao de conteudos para a Internet no desenvolvimento de Rich Inter-

net Application (RIA)s O Adobe AIR mantem uma relacao com o browser mas es-

tende as suas capacidades e tecnologias permitindo o desenvolvimento de aplicacoes

tambem para o ambiente de trabalho com janelas em tudo semelhantes as do sis-

tema operativo Segundo a Adobe o objectivo e complementar o browser dando

aos utilizadores (mas essencialmente aos programadores e equipas de desenvolvi-

mento) a escolha sobre como distribuir as suas aplicacoes Para este efeito o Adobe

AIR tem uma aproximacao diferente do Gears Em vez de ldquoestenderrdquo o browser

acrescentando-lhe funcionalidades o AIR permite tambem o desenvolvimento de

4Adobe - httpwwwadobecomproductsair

20

Estado da arte

aplicacoes que se destinam a ser executadas fora do ambiente do browser mas uti-

lizando as tecnologias comuns da Internet (por exemplo HTML CSS JavaScript

Flash Flex)[CDGH08]

A utilizacao desta tecnologia permite utilizar o browser ou o proprio runtime

Adobe AIR como plataforma de execucao da aplicacao

Na Tabela 31 faz-se uma comparacao das funcionalidades disponıveis de acordo

consoante se escolha o browser ou o desktop como plataforma base para a aplicacao

Uma vez que as aplicacoes Adobe AIR na plataforma desktop tem um caracter

persistente (sao instaladas no computador do utilizador) o Adobe AIR tem um

modelo de seguranca que se assemelha com o das tradicionais aplicacoes desktop

[Ada08] Este modelo e analisado nas seccoes 321 e 322 O ambiente em que

e executado o browser e restringido a execucao de web applications que podem

ser de varias origens (incluindo de origens anonimas ou sem confianca) O Adobe

AIR proporciona acesso a capacidades como acesso a ficheiros que necessitam da

confianca do utilizador

bull HTML ndash O desenvolvimento de aplicacoes para o Adobe AIR pode ser feito

com recurso a tecnologias de HTML e Ajax comuns utilizando as linguagens

de markup existentes distribuıdas como texto e interpretadas em execucao

(runtime)

bull Flash ndash Outra alternativa sera a utilizacao da linguagem Flash Permite a

renderizacao de graficos vectoriais e audiovıdeo com suporte nativo Utiliza

ActionScript para adicionar maior interactividade com o utilizador

bull Flex ndash O Flex e uma framework open source para o desenvolvimento de RIAs

usando Flash As aplicacoes Flex sao na realidade Flash sendo a principal

diferenca o ambiente de desenvolvimento

Como resultado uma aplicacao AIR podera ser implementada

bull Baseada em Flash ou Flex (aplicacoes cujo conteudo base e em ShockWave

Flash (SWF))

bull Baseada em Flash ou Flex tambem com HTML ou Portable Document Format

(PDF) Aplicacoes cujo conteudo de base e em FlashFlex (SWF) com HTML

(HTML JavaScript CSS) ou conteudo PDF incluıdo

bull Baseada em HTML Aplicacoes cujo conteudo base e em HTML Javascript

CSS

bull Baseada em HTML utilizando tambem FlashFlex ou PDF

21

Estado da arte

Os utilizadores interagem com uma aplicacao AIR da mesma forma que interagem

com outras aplicacoes com janelas nativas do seu sistema operativo O runtime e

instalado uma vez no computador do utilizador e a partir desse momento todas as

aplicacoes AIR terao o mesmo aspecto que qualquer outra aplicacao para o desktop

321 Seguranca

Permitir que uma web application aceda ao disco de armazenamento do utilizador

pode comprometer seriamente a sua seguranca Neste sentido o Adobe AIR tem

suporte para assinaturas digitais (Secure Sockets Layer (SSL)) que podem ser com-

pradas pelas equipas de desenvolvimento que o desejem e cujos certificados serao

apresentados ao utilizador no momento da instalacao Um outro aspecto ainda

relativo a seguranca e o mecanismo de isolamento de cada ambiente (sandbox )

322 Assinatura do codigo

O runtime AIR exige que todas as aplicacoes estejam digitalmente assinadas As

assinaturas digitais de codigo sao um processo que visa garantir a integridade da

aplicacao e a identidade do seu autor no momento da instalacao As equipas de

desenvolvimento podem ldquoassinarrdquo uma aplicacao utilizando um certificado atribuıdo

por uma Entidade Certificadora (Certification Authority) ou atraves de um certifi-

cado individual (self signed certificate) Neste momento o Adobe AIR suporta como

entidades certificadoras a Verisign e a Thawte [Ado08]

O instalador apresenta o nome de quem publica a aplicacao quando o codigo tiver

sido assinado com um certificado que apresente confianca ou que esteja encadeado

com um certificado que tenha ja sido aceite no computador em que se esta a instalar

a aplicacao

As equipas de desenvolvimento podem tambem assinar as aplicacoes com um

certificado auto-atribuıdo (um certificado criado por elas proprias) mas neste caso

o instalador apresentara estas aplicacoes como sendo de uma origem nao verificada

O AIR utiliza a infraestrutura publica de chaves [Ent07] suportada pelo arquivo

local do sistema operativo Para que a origem da aplicacao seja reconhecida o

computador onde a aplicacao AIR esta a ser instalada tem que confiar directamente

no certificado que foi utilizado para assinar a aplicacao ou confiar num certificado

que esteja num encadeamento logico de certificados confiados e que se ligue desta

forma ao certificado utilizado para assinar a aplicacao

Todas as aplicacoes AIR tem caracterısticas em comum independentemente da

tecnologia utilizada para o seu desenvolvimento (HTMLFlexFlash) No ambito

de uma aplicacao AIR existem um conjunto de APIs que estao disponıveis e que

tornam possıvel o acesso ao sistema local (leitura e escrita) e a recursos de rede que

22

Estado da arte

de outra forma nunca estariam acessıveis a partir de uma web application comum

Cada aplicacao AIR possui tambem diferentes nıveis de isolamento chamados secu-

rity sandboxes dependendo do tipo de conteudo que esta a ser carregado e do seu

objectivo

bull Isolamento ao nıvel da aplicacao5 ndash E a raiz de cada aplicacao AIR Este

nıvel de isolamento permite o acesso a APIs privilegiadas e especıficas do

AIR Em contrapartida e negado o acesso a algumas APIs que poderiam ser

facilmente utilizadas de forma maliciosa contra o utilizador final Importacao

dinamica de conteudos remotos e geralmente proibido e as tecnicas e mecan-

ismos de geracao dinamica de codigo sao fortemente restringidas Apenas

conteudo carregado directamente da directoria base da aplicacao podera ser

colocado neste nıvel de isolamento

bull Isolamento nao especıfico da aplicacao6 ndash contem todo o outro conteudo

que nao tenha sido carregado directamente para o isolamento da aplicacao

Isto inclui conteudo local e remoto Este tipo de conteudo nao tem acesso

directo as APIs do AIR e rege-se pelas mesmas regras tal como se tivesse sido

carregado por um browser a partir da mesma localizacao (por exemplo HTML

carregado a partir de um domınio remoto comporta-se da mesma forma que se

fosse acedido a partir do browser)

33 Mozilla Prism

331 XML User Interface Language

O eXtensible User Interface Language (XUL) e uma linguagem de anotacao

baseada em XML desenvolvida pela Mozilla Foundation que opera em aplicacoes

Mozilla multi plataforma tal como o Firefox O motor Gecko e a unica imple-

mentacao completa desta linguagem que foi desenhada sobre padroes web comuns

como CSS JavaScript e o DOM e permite o desenvolvimento de interfaces graficas

utilizando elementos pre-definidos tais como window box page textbox radio

button entre outros Infelizmente o XUL nao possui qualquer especificacao formal

ou implementacoes de inter-operabilidade para outros motores que nao o Gecko No

entanto a sua implementacao e licenciada em codigo aberto pelas licencas GNU Gen-

eral Public License (GPL) GNU Lesser General Public License (LGPL) e Mozilla

Public License (MPL)

Enunciam-se algumas caracterısticas desta linguagem

5NT application sandbox6NT non-application sandbox

23

Estado da arte

Liguagem de anotacao poderosa baseada em componentes (widgets) O ob-

jectivo do XUL e permitir a construcao de aplicacoes multi-plataforma em

claro contraste com o Dynamic HyperText Transfer Protocol (DHTML) que se

destina ao desenvolvimento de paginas web Por esta razao o XUL esta orien-

tado a componentes tais como janelas botoes e etiquetas em vez de paginas

cabecalhos de texto e ligacoes de hipertexto Investir tempo e esforco para

atingir este mesmo resultado em aplicacoes baseadas em DHTML compromete

frequentemente a complexidade e desempenho da aplicacao

Baseado em padroes O XUL e um dialecto XML baseado no padrao W3C XML

10 As aplicacoes escritas em XUL sao tambem baseadas em especificacoes

W3C adicionais como HTML 40 CSS DOM nıvel 1 e 2 JavaScript 15

incluindo ECMA-262 Edition 3 (ECMAscript)

Portabilidade entre plataformas Tal como HTML o XUL foi desenhado para

ser independente da plataforma em que e utilizado tornando as aplicacoes

facilmente portaveis entre sistemas operativos nos quais o Mozilla e suportado

Uma vez que o XUL oferece um nıvel de abstraccao dos componentes graficos

de interface que disponibiliza implementa a premissa ldquoum codigo para todas

as plataformasrdquo A interface grafica de todos os produtos centrais Mozilla

(browser instant messenger livro de enderecos) e escrita em XUL com um

unico codigo base que suporta todas as plataformas Mozilla

Separacao entre o nıvel de apresentacao e a logica de negocio Uma das

maiores preocupacoes no desenvolvimento para a Internet e a forte ligacao

entre estas duas camadas (interface e logica) Isto constitui um problema sig-

nificativo no desenvolvimento de grandes aplicacoes especialmente quando o

desenvolvimento e feito em ambientes de equipa porque as capacidades de de-

senvolvimento destas duas partes da aplicacao estao muitas vezes espalhadas

por diferentes elementos O XUL permite uma clara distincao entre a definicao

da aplicacao cliente e da logica de implementacao (XUL eXtensible Binding

Language (XBL) e JavaScript) apresentacao (CSS e imagens) internacional-

izacao (Document Type Definitions (DTDs) e etiquetas de texto em lınguas

especıficas guardados em ficheiros properties) O esquema grafico e apre-

sentacao de uma aplicacao XUL pode ser alterado de forma independente da

sua logica ou implementacao e a aplicacao pode ainda ser traduzida (interna-

tionalization) de forma independente da sua logica implementacao ou apre-

sentacao Este grau de separacao resulta em aplicacoes que sao mais faceis de

manter pelos programadores e facilmente adaptadas por designers e tradutores

24

Estado da arte

Facil adaptacao Outro benefıcio que advem do nıvel de separacao entre logica

de negocio e apresentacao oferecido pelo XUL e a facilidade com que se pode

adaptar uma aplicacao para diferentes clientes ou grupos de utilizadores Um

programador pode utilizar a mesma aplicacao base e adapta-la consoante as

necessidades atraves de diferentes temas (skins) e ficheiros de lınguas Desta

forma uma aplicacao escrita e desenvolvida em Ingles pode ser rapidamente

traduzida para Portugues e distribuıda com outra aparencia mais apropriada

ao cliente alvo

332 Prism

O Mozilla Prism e um browser simplificado e ldquointerpretadorrdquo de XUL (tambem

designado por XULRunner) que acolhe web applications sem a interface grafica ha-

bitual de um browser Baseia-se num conceito designado por Site Specific Browser

(SSB) Um SSB e uma aplicacao com um browser embebido desenhado para exe-

cutar apenas uma web application Nao possui os menus e barras de ferramentas

habituais Um SSB tem uma integracao com o sistema operativo e com o desktop

muito mais estreita do que uma web application acedida atraves de um browser uma

vez que e executado em janela propria

O Prism resulta de uma experiencia da Mozilla e visa reduzir as diferencas entre

as desktop applications tradicionais e as web applications Um dos aspectos focados e

a experiencia do utilizador Numa apresentacao oficial e dito que ldquo[o Prism] pretende

ser uma ponte entre as diferencas que existem entre as aplicacoes tradicionais de

desktop e as web applications explorando novos modelos de usabilidade enquanto

que a linha que as separa se continua a definirrdquo [Lab07]

34 HTML 5

A especificacao HTML 5 [Hic08] que se encontra em fase de desenvolvimento

pelo grupo WHATWG pretende ser uma norma de substituicao dos padroes HTML

4 XHTML 1x e do DOM2 HTML Uma das propriedades que o distingue das tec-

nologias que pretende substituir e precisamente o suporte para OWA e armazena-

mento de dados no cliente de uma forma relacional Nao sendo propriamente uma

tecnologia ndashmas antes uma especificacao ndashe aqui mencionada por ter servido como

referencia a diversas implementacoes de funcionalidades offline e por se considerar

que venha a ter um impacto significativo nas implementacoes de diversos browsers

Dion Almaer defendeu no seu blogue que o Gears era uma implementacao do

HTML 5 No seu artigo ldquoGears as a bleeding-edge HTML 5 implementationrdquo [Alm08]

o autor diz que ambos ndasho Gears e o HTML 5 ndashpretendem dar a web caracterısticas

25

Estado da arte

semelhantes e nao encontrar motivo de ldquocompeticaordquo entre as duas mas que en-

quanto o HTML 5 e uma especificacao o Gears e uma implementacao

No entanto tambem e verdade que o HTML 5 cobre muitos outros pontos para

alem das OWA que saem completamente fora do ambito do Gears Se esta es-

pecificacao atingir um estado de maturidade que possibilite a sua adopcao pelos

principais browsers tornando nativo do browser o suporte OWA entao deixara de

fazer sentido a existencia de uma extensao como o Gears

A especificacao HTML 5 disponibiliza duas APIs relevantes para o tema das

OWA

1 Uma base de dados baseada em SQL que permite o armazenamento de dados

do lado do cliente

2 Uma ldquocacherdquo HTTP que garante a disponibilidade das aplicacoes mesmo quando

o utilizador nao possui uma ligacao a Internet

Estas caracterısticas sao as bases da tecnologia das OWA e tem correspondencia

com os pontos analisados nas seccoes 311 e 311

35 Web applications que usam funcionalidades offline

Nesta seccao apresentam-se algumas web applications que actualmente disponi-

bilizam funcionalidades offline Estas aplicacoes foram escolhidas para uma analise

mais pormenorizada por utilizarem o Gears que tal como descrito na seccao 4 foi

a tecnologia escolhida para o projecto

351 Google Reader e Google Docs

O Google Reader7 e um leitor de feeds RSS Permite gerir a subscricao de varios

sites simultaneamente que disponibilizem conteudos neste formato e foi a primeira

web application da Google com uma versao offline publicamente acessıvel (desde

Junho de 2007)

O Google Reader implementa o modo ldquoutilizador deciderdquo oferecendo na sua

interface um botao que permite alternar entre os modos online e offline

O Google Docs8 e uma web application que permite a criacao e edicao de doc-

umentos de texto folhas de calculo e apresentacoes Era ja publico desde Janeiro

de 2008 que o Google estava a desenvolver uma versao OWA desta aplicacao mas o

acesso a uma versao experimental so foi possıvel a partir de 31 de Maio de 2008

7Google Reader - httpreadergooglecom8Google Docs - httpdocsgooglecom

26

Estado da arte

A implementacao das funcionalidades offline nestas duas aplicacoes seguiu difer-

entes aproximacoes principalmente porque o Google Reader apresenta ao utilizador

informacoes que sao fornecidas por fontes externas enquanto que no Google Docs

a informacao e criada e editada pelo utilizador sobre a forma de documentos

A diferente origem da informacao implica que no Google Reader seja necessario

prever casos de excepcao tal como existirem demasiados itens que necessitam de

ser transferidos para o cliente Nao observar este ponto causa um problema grave

de usabilidade e para evitar tempos de espera demasiado longos e uma interface

com pouca capacidade de resposta as accoes do utilizador o Google Reader apenas

transfere para o cliente os dois mil itens mais recentes na transicao para o modo

offline

352 Remember the Milk

O Remember The Milk9 e uma web application desenvolvida por uma equipa

Australiana que proporciona funcionalidades de agenda gestao de tempo e de tare-

fas e foi uma das primeiras aplicacoes independentes do Google a adoptar o Gears

para acessos em modo offline Permite que os seus utilizadores facam uma gestao

de tarefas agrupando-as em listas adicionando-lhes campos de informacao adicional

ou dando-lhes informacao geografica (recorrendo ao servico Google Maps10) Entre

a sua lista de funcionalidades encontra-se ainda a possibilidade de importar e ex-

portar eventos no formato iCalendar (ics) etiquetas (tags) em tarefas publicacao

Really Simple Syndication (RSS) e partilha de categorias de tarefas de acordo com

diferentes nıveis de permissoes de acesso definidos pelo utilizador

353 MySpace e WordPresscom

O MySpace uma das maiores social networks na Internet anunciou recente-

mente que vai disponibilizar uma versao do seu cliente de e-mail que utiliza o Gears

para acelerar o seu desempenho Numa fase inicial estara disponıvel apenas para

utilizadores que tenham cinco mil ou mais mensagens na sua caixa de correio e

permitira efectuar pesquisas muito mais rapido que a sua versao online

O servico de blogs Wordpresscom anunciou tambem o inıcio da utilizacao desta

tecnologia com o fim de melhorar o desempenho A versao que utiliza esta tecnologia

descarrega e armazena no cliente um conjunto de imagens e scripts que passam a

ter preferencia sobre os seus congeneres online e que permitem acelerar o processo

de carregamento da aplicacao e visualizacao de blogs

9Remember The Milk ndash httpwwwrememberthemilkcom10Google Maps ndash httpmapsgooglecom

27

Estado da arte

O MySpace e o Wordpresscom sao dois exemplos da utilizacao da tecnologia

OWA para optimizacao de web application ja existentes Sem pretenderem disponi-

bilizar uma versao que seja totalmente offline fazem uso do Gears para armazenar no

cliente parte dos recursos frequentemente acedidos na visualizacao das suas paginas

36 Escolha da tecnologia

Apos a analise das tecnologias apresentada nas seccoes 31 a 34 foi necessario es-

tudar a adequacao de cada uma delas ao projecto em questao Desde logo e possıvel

observar que nem todas se dedicam apenas a OWA Por exemplo o Adobe AIR

apesar de ter suporte para OWA apenas disponibiliza algumas das funcionalidades

identificadas como mais indicadas para a execucao do projecto quando utilizado

na sua vertente desktop tal como exposto na Tabela 31 mas a utilizacao desta

vertente implicaria o desenvolvimento de novas interfaces e de novas formas de co-

municacao (troca de mensagens XML ou JSON) A vertente web do Adobe AIR

foca-se mais especificamente nas Rich Internet Applications e permite a reutilizacao

do codigo ja existente (exigindo naturalmente a sua adaptacao e a implementacao

das funcionalidades pretendidas)

A tecnologia escolhida para a realizacao deste trabalho foi o Gears sendo que

um dos principais factores a influenciar esta opcao foi a liberdade introduzida pela

sua licenca Berkeley Software Distribution (BSD)11

Considerou-se o funcionamento desta ferramenta extremamente adequando a

aplicacao no WOW uma vez que o seu principal objectivo e precisamente tornar

possıvel a execucao offline de uma pagina web e por virtude deste facto o Gears tem

uma API concisa e de simples aplicacao pratica uma vez que nao possui quaisquer

outros elementos distractores O funcionamento do seu ManagedResourceStore ex-

emplificado na Figura 31 com a capacidade de actualizacao de recursos definidos

num ficheiro manifesto especificado em JSON pesou tambem nesta decisao

11Sobre a licenca BSD consultar httpwwwopensourceorglicensesbsd-licensephp e http

wwwlinfoorgbsdlicensehtml

28

Estado da arte

Figura 31 Esquema UML do processo efectuado pelos recursos do Gears do tipoManagedResourceStore para a actualizacao dos conteudos definidos no ficheiro manifesto

29

Estado da arte

Funcionalidade RIAs no browser RIAs no desktop

Disponibilidadeda aplicacao

As aplicacoes podem ser facil-mente exploradas e utilizadas

As aplicacoes quando instal-adas tem maior grau de fun-cionalidades e persistencia

Instalacao Nao e necessario qualquer tipode instalacao

As aplicacoes sao instaladasatraves do browser ou descar-regadas e instaladas comouma aplicacao tradicional

Actualizacoes Aplicacoes sao actualizadascarregando conteudos paraum website

O AIR disponibiliza uma APIque permite que as aplicacoessejam actualizadas de umaforma

Sistemas opera-tivos suportados

As aplicacoes podem ser exe-cutadas em diversos sistemasoperativos e browsers

As aplicacoes sao multi-plataforma e podem serinstaladas e executadas emdiversos sistemas operativos ebrowsers

Linguagens deprogramacao

Javascript e disponibilizadopelo browser e ActionScripte disponibilizado pelo AdobeFlash Player

Maquinas virtuais deJavascript e ActionScriptcompatıveis com o browser

Capacidade deexecucao embackground

As RIAs podem ser execu-tadas numa janela do browser

As aplicacoes podem ser ex-ecutadas em background edisponibilizar notificacoes talcomo uma aplicacao tradi-cional

Persistencia A actividade esta limitada asessao do browser Quando obrowser e encerrado toda ainformacao e descartada

As aplicacoes sao instaladas eestao disponıveis no desktopPodem armazenar informacaolocalmente e estao disponıveisoffline

Integracao com odesktop

Integracao com o desktop lim-itada devido a restricoes im-postas pelo browser

As aplicacoes podem acederao sistema de ficheiro ao clip-board eventos notificacoesetc

Controlo da inter-face com o uti-lizador

As aplicacoes sao acedidasatraves de uma janela dobrowser que tem os seusproprios controlos e visualgrafico

As aplicacoes tem um vi-sual grafico proprio em janelapropria

Armazenamentode dados

As aplicacoes tem armazena-mento limitado que pode serreescrito pelo browser

As aplicacoes tem acesso a to-talidade do espaco disponıvellocalmente e a uma base dedados com a possibilidade deencriptacao

Tabela 31 Comparacao das funcionalidades oferecidas pelo Adobe AIR para as platafor-mas web e desktop

30

Estado da arte

Aplicacao Modo de execucao utilizadoGoogle Reader Utiliza o modo ldquoutilizador deciderdquo disponibilizando

ao utilizador um botao para alternar entre os modosonline e offline Como lida com informacao recol-hida de fontes externas de natureza frequentementeefemera o processo de sincronizacao apenas transfereos dois mil itens mais recentes quando passa ao es-tado offline Neste modo sao ainda guardadas in-formacoes de itens lidos e etiquetas atribuıdas quesao sincronizadas com o servidor quando o utilizadorvoltar a activar estado online

Google Docs Utiliza o modo ldquoaplicacao deciderdquo permitindo que outilizador edite os conteudos de documentos de textofolhas de calculo e de apresentacoes independente-mente do estado da ligacao desde o momento em queas funcionalidades offline sao activadas A aplicacaofaz pequenas sincronizacoes com o servidor sempre quenecessario

Remember the Milk Utiliza um modo hıbrido entre ldquoaplicacao deciderdquo eldquoutilizador deciderdquo A aplicacao encarrega-se da sin-cronizacao de dados mas disponibiliza um controlona sua interface que permite despoletar manualmenteeste processo para situacoes em que o utilizador fez al-teracoes recentes e pretende usufruir das capacidadesoffline imediatamente

MySpace O MySpace anunciou a utilizacao de mecanismos dearmazenamento de dados no cliente com recurso atecnologias OWA para melhorar o desempenho doseu cliente web de correio electronico nomeadamenteno que diz respeito a operacoes de pesquisa e or-denacao Inicialmente esta funcionalidade estara ape-nas disponıvel para utilizadores com cinco mil ou maismensagens na sua caixa de correio mas nao e aindaclaro se sera disponibilizada uma versao totalmenteoffline

Tabela 32 Resumo da utilizacao de tecnologias OWA em algumas web applications con-sideradas na analise do estado da arte

31

Estado da arte

32

Capıtulo 4

Desenvolvimento

Neste capıtulo introduz-se a aplicacao WOW e apresenta-se o estudo que foi

feito da adequacao de cada tecnologia para a implementacao da funcionalidade of-

fline nesta plataforma Fazem-se diversas consideracoes sobre opcoes a tomar na

concepcao de OWAs e problemas comuns na sua implementacao bem como sug-

estoes para os resolver O WOW e uma aplicacao ja existente de gestao de ordens

de trabalho e do fluxo de tarefas numa empresa ou organizacao

41 Como ficar offline

Na maior parte das web applications de hoje nao existe uma camada de dados

real A aplicacao exemplificada na Figura 41 ao longo da sua execucao acede

directamente a sua unica fonte de dados (o servidor) atraves de chamadas Ajax sem

que exista uma separacao clara destas duas camadas

Para que uma web application seja capaz de ser executada sem uma ligacao

activa a Internet e mantenha o seu caracter dinamico torna-se necessario incluir

Figura 41 Exemplo de uma arquitectura de uma web application sem uma camada deabstraccao de dados Figura adaptada de http gears google com

33

Desenvolvimento

Figura 42 Exemplo de uma arquitectura de uma web application com uma camada deabstraccao de dados Figura adaptada de http gears google com

um mecanismo de armazenamento de dados local seja uma base de dados ou a

capacidade de acesso ao disco No entanto este mecanismo introduz dois problemas

1 Qual das fontes de dados utilizar quando um utilizador faz um pedido de

informacao

2 A necessidade de implementar uma camada de acesso a dados que seja coerente

quer se use o servidor remoto ou local

Por exemplo em vez de a aplicacao Ajax fazer um pedido relativo as contas de

todos os utilizadores em formato JSON directamente ao servidor remoto podera ao

inves fazer o pedido a um objecto intermedio da camada de dados Este objecto

demonstrado na Figura 42 sera responsavel por implementar uma interface de

acesso a base de dados e retornar um objecto JavaScript com uma representacao da

resposta do servidor

Mas a existencia de uma segunda fonte de dados torna recomendavel tambem

a implementacao de uma camada de data switching que em funcao da existencia

de conexao a Internet e da necessidade de actualizacao dos dados decide se faz o

pedido ao servidor remoto ou se fornece os dados presentes localmente Este objecto

apresentado na Figura 43 decidira de forma transparente para o utilizador se le ou

escreve os dados localmente ou se os enviapede ao servidor remoto e pode tambem

iniciar o processo de convergencia de dados e de resolucao de conflitos

411 Funcionalidades disponıveis em modo offline

Por razoes praticas e provavel que nem todas as funcionalidades da aplicacao

possam ser disponibilizadas em modo offline E necessario escolher quais as fun-

cionalidades a disponibilizar no modo offline da aplicacao e implementar a logica

que decide quando utilizar a base de dados local ou o servidor remoto Apesar do

acesso a base de dados local ser muito mais rapido do que aceder ao servidor o

acesso local nem sempre e preferido Ha varias razoes que podem tornar necessario

escolher o acesso ao servidor em vez do acesso local

34

Desenvolvimento

Figura 43 Exemplo de uma arquitectura de uma web application com uma camada deabstraccao de dados e um data switch Figura adaptada de http gears google com

1 A informacao pode ter uma natureza efemera e nao fazer sentido guarda-la

localmente Exemplo dados em tempo real da bolsa de valores de Lisboa

2 Algumas aplicacoes lidam com informacao que so faz sentido na presenca de

uma ligacao Exemplo Instant Messaging

3 A aplicacao podera escolher apenas guardar a informacao acedida mais fre-

quentemente Exemplo para o utilizador poder alterar a lıngua de apre-

sentacao da aplicacao os conteudos terao que ser guardados em todas as

lınguas disponibilizadas pela aplicacao O custo de implementacao de algu-

mas funcionalidades pode nao compensar o benefıcio

4 A capacidade de processamento ou de armazenamento de dados pode inviabi-

lizar algumas funcionalidades offline Exemplo se uma dada funcionalidade

necessita de uma capacidade de armazenamento de dados para alem do razoavel

de um computador pessoal para ser util (visualizador de mapas)

42 Modos de execucao

Um aspecto que e necessario estudar para qualquer web application que se deseje

disponibilizar offline prende-se com tres modos de execucao que devem ser consid-

erados

1 Utilizador decide o modo de execucao A aplicacao tem modos distintos

de execucao para os estados online e offline geralmente indicados na interface

com o utilizador O utilizador e informado do estado da ligacao e participa na

alteracao de estado de execucao da aplicacao interagindo com a sua interface

2 Aplicacao decide o modo de execucao Pode ser implementado na propria

aplicacao um mecanismo de deteccao do estado da ligacao (por exemplo atraves

35

Desenvolvimento

de chamadas Ajax periodicas) transitando de estado e sincronizando automati-

camente Desta forma o utilizador nao precisa de participar na alteracao de

estado a menos que exista um conflito de dados que requeira a sua atencao

3 Aplicacao assume sempre o estado offline Outra hipotese sera imple-

mentar uma web application que assume sempre estar na ausencia de uma

ligacao ao servidor de dados Esta aplicacao responde aos pedidos do uti-

lizador efectuando pedidos de informacao ao servidor mas nao dependendo

de uma resposta valida para mostrar a informacao que ja tinha disponıvel an-

teriormente A sincronizacao de dados com o servidor e tentada sempre que

existam dados para submeter e uma accao do utilizador

421 Modo ldquoutilizador deciderdquo

Neste modo de execucao quando a aplicacao esta online comunica com o servidor

remoto quando esta offline comunica com a base de dados local A informacao tem

que ser sincronizada sempre que se muda de modo A principal vantagem desta opcao

e que e a mais simples de implementar mesmo para uma aplicacao ja existente e

portanto uma forma expedita de disponibilizar uma OWA No entanto tem tambem

algumas desvantagens que devem ser consideradas

1 O utilizador tem que se lembrar de fazer a alteracao de estado de execucao

Caso contrario podera estar a trabalhar inadvertidamente numa versao offline

com dados antigos ou nao ter a informacao necessaria se perder subitamente

a ligacao

2 Se a ligacao for intermitente o utilizador tera ou que escolher um dos modos

de execucao ou estar constantemente a trocar

3 Uma vez que a base de dados nao esta sempre actualizada nao podera ser

utilizada para melhorar a rapidez de execucao da aplicacao quando em modo

online

422 Modo aplicacao decide

A deteccao do estado da ligacao pode ser implementada atraves de um pedido

assıncrono ao servidor tal como ilustrado na Figura 44 O resultado deste pedido

definira o estado online (em caso de sucesso) ou offline (em caso de falha) A

sincronizacao de dados podera ser feita sempre que ocorra uma transicao do es-

tado offline para o estado online No entanto este metodo nao se revela eficiente

36

Desenvolvimento

Figura 44 Esquema grafico ilustrando uma OWA executando no browser utilizando ummodo de execucao do tipo ldquoaplicacao deciderdquo com deteccao automatica do estado daligacao via pedidos Ajax assıncronos a cada cinco segundos

para grandes aplicacoes uma vez que requer a troca de mensagens demasiado fre-

quentes com o servidor que se destinam exclusivamente a monitorizacao do estado

da ligacao

423 Modo ldquoaplicacao assume o estado offlinerdquo

Uma aplicacao transparente funciona assumindo sempre que esta em modo of-

fline ou pelo menos que pode perder a ligacao a qualquer momento Neste modo

tira-se o maximo partido do armazenamento local e fazem-se pequenas mas contınuas

sincronizacoes com o servidor sempre que este esteja disponıvel A sincronizacao de

dados tambem e feita sempre que se volta ao estado online

As vantagens de uma web application transparente sao as seguintes

bull Uma melhor experiencia para o utilizador uma vez que este nao tem que se

preocupar com o estado da ligacao ou com a transicao de estados

bull A aplicacao funciona de forma coerente mesmo que a ligacao seja intermitente

bull Uma vez que o armazenamento local e mantido actualizado pode ser utilizado

para melhorar o desempenho da aplicacao

Foram identificadas as seguintes desvantagens

bull E mais difıcil de implementar e a sincronizacao acarreta cuidados especiais

bull E necessario um cuidado adicional para evitar que as operacoes de sincronizacao

frequentes que ocorrem automaticamente nao afectem os tempos de resposta

da aplicacao

bull Os testes a aplicacao sao mais complexos uma vez que a sincronizacao de dados

nao ocorre em resposta a uma accao do utilizador

37

Desenvolvimento

43 Sincronizacao de dados

A sincronizacao de dados consiste na capacidade de identificar e transferir pe-

riodicamente a versao mais actual dos dados entre o cliente e o(s) servidor(es)

Independentemente do modo de execucao escolhido e mesmo do estado da ligacao

do utilizador a informacao armazenada localmente e a informacao armazenada no

servidor estarao por vezes dessincronizadas Isto podera acontecer sempre que por

exemplo

bull O utilizador faz alteracoes em modo offline

bull A informacao e partilhada e pode ser alterada por uma entidade externa

bull A informacao e fornecida por uma entidade externa

Resolver estas diferencas de forma a que a informacao local e remota encontrem

a igualdade chama-se sincronizacao de dados Ha varias aproximacoes possıveis

para este efeito que dependem da natureza da aplicacao cada uma com vantagens

e desvantagens

A capacidade de suportar a mobilidade dos utilizadores torna-se cada vez um

ponto mais importante de uma web application Para uma organizacao de dimensao

global e vital garantir que os seus colaboradores tem acesso a mesma informacao

que tem disponıvel nos seus postos de trabalho mesmo quando estao fora Na maior

parte dos casos estes colaboradores terao acesso a um computador portatil um

desktop Smartphone ou PDA e atraves destes poderao ter acesso a sua informacao

directamente atraves de ligacoes encriptadas Virtual Private Network (VPN) de um

servidor web ou de outro mecanismo de rede

Esta solucao e simples de implementar mas infelizmente para a maioria dos

colaboradores com grande factor de mobilidade nao e satisfatoria As principais

desvantagens sao as seguintes

bull Requisitos de ligacao Para permitir que os utilizadores acedam a sua in-

formacao e necessario garantir a capacidade constante de comunicacao pelo

menos durante o tempo necessario que assegure a sua transferencia

bull Velocidade de ligacao sem persistencia de dados e em ligacoes de fraca

qualidade a usabilidade por vezes torna-se inaceitavel

bull Ponto crıtico de falha Com este tipo de solucao todos os utilizadores de-

pendem da base de dados que armazena informacao vital para o funcionamento

do cliente

38

Desenvolvimento

bull Scalability do servidor A medida que novos utilizadores sao adicionados ao

sistema o desempenho do servidor e afectado levando a necessidade de maior

capacidade de armazenamento eou processamento

De acordo com a documentacao da Microsoft Sync Framework [Mic08] uma

solucao alternativa consiste em implementar uma Occasionally Connected Appli-

cation (OCA) Uma OCA permite a um utilizador remoto continuar a aceder a

sua informacao mesmo depois de perder a ligacao mas em vez de recorrer a um

servidor recorre a informacao armazenada no seu dispositivo local Para preencher

localmente a informacao que o utilizador necessita uma OCA possui mecanismos

de sincronizacao de dados que sao oferecidos por esta framework

431 Quando sincronizar

Uma das solucoes mais simples de implementar passa por disponibilizar um

mecanismo manual que despoleta a sincronizacao Diz-se manual porque e o uti-

lizador que escolhe quando sincronizar e pode ser implementada simplesmente

fazendo o upload de toda a informacao para o servidor e depois fazendo o download

da copia mais recente da informacao antes de voltar a ficar offline Para que esta

seja uma opcao viavel e necessario que

bull O volume de dados seja suficientemente pequeno para que possa ser transferido

do servidor para o cliente num espaco de tempo aceitavel

bull Que o utilizador indique explicitamente que quer mudar para o estado offline

ou online pressionando um botao da interface

Contudo podem ser identificados alguns problemas relacionados com esta abor-

dagem

bull Os utilizadores nem sempre podem prever o estado das suas ligacoes A ligacao

pode-se perder subitamente ou ter um caracter intermitente

bull O utilizador pode esquecer-se de efectuar a sincronizacao

Outra opcao sera conjugar a sincronizacao de dados com o modo de execucao

transparente A sincronizacao ocorre automaticamente em background de forma

nao intrusiva para o utilizador A aplicacao comunica com o servidor regularmente

efectuando pequenas trocas de dados com o objectivo de manter o sincronismo da

informacao local e remota Esta abordagem pode ser implementada com pedidos

Ajax assıncronos e regulares ao servidor o que permite manter a interaccao com a

interface fluıda evitando bloqueios Estes pedidos sao feitos prevendo as situacoes

39

Desenvolvimento

de disponibilidade ou indisponibilidade (timeout) do servidor Uma outra opcao

sera permitir que o servidor comunique essas alteracoes utilizando Comet1 tal como

descrito em [Wil06] e [Rus06] As vantagens destas aproximacoes sao

bull A informacao esta disponıvel a qualquer altura que o utilizador decida ficar

offline ou que a ligacao seja acidentalmente perdida

bull O desempenho da aplicacao pode ser melhorado quando se estiver a utilizar

uma ligacao a Internet lenta uma vez que o acesso a dados locais e mais

eficiente do que a consulta de dados ao servidor

44 WOW

O WOW e uma plataforma integrada de gestao de ordens de trabalho ja ex-

istente e desenvolvida pela Critical Software SA a qual se pretende adicionar a

capacidade de execucao offline Esta aplicacao e extremamente dinamica e con-

figuravel com um conjunto extremamente rico de funcionalidades das quais se

destacam

bull Gestao de Ordens de Trabalho ndash suportando a gestao dos pedidos desde a

sua criacao ate ao seu fecho tomando em conta os diferentes tipos de pedidos

(ordens de trabalho pedidos de informacao melhorias resolucao de problemas

etc) e diferentes tipos de accoes possıveis para cada um (Figura 45)

bull Monitorizacao de alteracoes ndash Historico de mudancas anexos e estados criando

relatorios de alteracao automaticamente (o que por quem e quando)

bull Uso de Service Level Agreements (SLAs) ndash E possıvel associar a um pedido um

SLA que define qual o perıodo de tempo atribuıdo a resolucao de um pedido

controlando e agilizando a resolucao do mesmo

bull Utilizacao de queries de utilizador configuraveis que permitem acesso rapido

a determinadas ordens de trabalho de acordo com o filtro configurado (por

exemplo ldquoPara mimrdquo ldquoPara o Grupordquo ldquoPelo Grupordquo)

bull Gestao do relacionamento entre pedidos

bull Pesquisa e filtragem de ordens de trabalho

bull Exportacao de dados em formatos padrao (PDF DOC ou XLS)

bull Integravel com solucoes externas

40

Desenvolvimento

Figura 45 Detalhe de um conjunto possıvel de estados e respectivas transicoes para umadada ordem de trabalho no WOW desde a sua submissao no sistema ate a sua conclusaoem fecho ou cancelamento Esta figura representa apenas um exemplo ja que o mapa deestados para uma ordem de trabalho e dinamico e pode ser alterado por um administradorFigura retirada de uma brochura promocional do WOW Critical Software SA

A utilizacao de uma ferramenta deste tipo por parte de uma empresa ou orga-

nizacao oferece vantagens quer a gestao de topo quer aos colaboradores individuais

para os colaboradores individuais o WOW e uma aplicacao onde estao registadas

todas as tarefas contribuindo activamente para o desenvolvimento em ambientes

multi-tarefa e para a organizacao pessoal das tarefas de acordo com prioridades

Para a gestao de topo esta ferramenta permite obter uma visao global do estado da

organizacao em termos de tempo gasto por tarefa executada sendo uma mais valia

para a previsao e gestaoalocacao de recursos

45 Visao geral sobre a arquitectura do WOW

O WOW e interessante nao so do ponto de vista de produto como tambem do

ponto de vista de plataforma Existem diversos plug-ins que estendem as funcional-

idades do WOW e existem ate projectos que pretendem usar a arquitectura do

WOW para criar produtos com fins diferentes do inicial (por exemplo o WOW-

Storm ndash um sistema de registo e classificacao social de ideias)

De modo a conseguir ter essa expansibilidade a plataforma WOW assenta sob

uma arquitectura distribuıda modular e expansıvel com uma componente central

ndash o core ndash estruturado em camadas logicas E no core que se situam todas as

1O Comet e um conceito semelhante ao Ajax introduzido por Alex Russel mas no qual e o servidor quetoma a iniciativa de ldquoenviarrdquo os dados ao browser sem que este tenha que efectuar um pedido Tambem econhecido por Ajax Push Reverse Ajax ou HTTP Streaming

41

Desenvolvimento

funcionalidades base da aplicacao quer a nıvel logico funcional e de apresentacao

quer a nıvel de gestao e configuracao

E possıvel a execucao de varias instancias do core simultaneamente em servidores

distintos o que permite a alta escalabilidade e disponibilidade desta aplicacao A

consistencia dos dados fica sempre garantida atraves da partilha da base de dados

e pelo balanceamento dos pedidos uma vez que cada um e encaminhado para uma

unica instancia

O WOW apresenta tambem a vantagem de ser uma plataforma extensıvel E

possıvel adicionar novas caracterısticas a plataforma atraves de componentes que se

podem ser divididos em duas categorias plugins e connectors

Os plugins sao componentes que se encontram no mesmo no fısico que a aplicacao

partilhando do mesmo contexto de execucao do core Sao assim uma forma mais

directa de obter informacao da plataforma visto que nao possuem restricoes de

acesso aos dados nem dependencias externas A arquitectura deste componente tera

assim que permitir varias execucoes instanciadas cada uma associada a um core

Por outro lado os connectors sao componentes que se encontram distribuıdos

comunicando externamente com o core Quer a sua execucao quer a obtencao

dos dados estao assim dependentes de interfaces de comunicacao externas que a

plataforma disponibiliza Estes componentes ao contrario dos plugins sao instan-

ciados unicamente e recorrem ao protocolo de comunicacao Java Messaging Service

(JMS) para comunicar com o core

46 WOW Offline

Para alem das opcoes tomadas relativamente a tecnologia a utilizar surgiu

tambem a necessidade de optar por um dos modos de execucao apresentados na

seccao 42

Das tres opcoes possıveis foi o modo ldquoaplicacao assume o estado offlinerdquo descrito

na seccao 423 que mereceu a maior atencao uma vez que reune as vantagens de

uma experiencia mais positiva para o utilizador (uma vez que este nao tem que

participar activamente na alteracao do modo execucao como descrito na seccao 421)

e nao constitui uma sobrecarga excessiva para servidor (como o modo abordado na

seccao 422)

No entanto esta opcao comprometia a complexidade da implementacao para alem

dos objectivos propostos para este projecto e para cumprir o prazo dado foi tomada

a decisao de implementar o modo ldquoutilizador deciderdquo especificando apenas de forma

teorica o modo ldquoaplicacao assume o estado offlinerdquo

As caracterısticas do Gears foram ja descritas na seccao 31 Na Figura 47

mostra-se a sua forma de funcionamento quando integrado numa web application

42

Desenvolvimento

Nesta figura representa-se o modulo LocalServer do Gears como um ponto de de-

cisao Aqui sao testadas as condicoes que determinam se o pedido sera interceptado e

servido localmente ou se prossegue para uma maquina remota E tambem represen-

tada uma base de dados que corresponde ao modulo Database mas que podera nao

ser utilizada Este modulo tal como o modulo Workerpool tem caracter opcional

e sao utilizados consoante os requisitos da aplicacao

A plataforma WOW lida com mais dados do que e necessario passar para o

lado do cliente Em conformidade com o ja exposto na seccao 411 volta-se a

frisar que nao se pretende recriar toda a logica de negocio nem os conteudos da

base de dados no cliente pela sua complexidade e volume de dados Pretende-se

pelo contrario permitir que os utilizadores tirem partido da capacidade de poder

consultar as suas ordens de trabalho quando nao dispoe de uma ligacao transferindo

apenas o essencial para isto seja possıvel

A pagina inicial do WOW apresenta um resumo das ordens de trabalho abertas

ndash enviadas e recebidas ndash que se pretende permitir visualizar offline (ver Figura 46)

Como prova de conceito foi efectuada uma abordagem pragmatica das varias possi-

bilidades descritas na seccao 42

461 Modo ldquoaplicacao deciderdquo com deteccao automatica da ligacao

A primeira abordagem estudada para a disponibilizacao das funcionalidades of-

fline foi o modo ldquoaplicacao deciderdquo com deteccao automatica de ligacao apresentado

na seccao 422 Para que isto seja possıvel foi implementado um mecanismo de ver-

ificacao periodica do estado da ligacao atraves de chamadas Ajax assıncronas O

resultado destes pedidos determina o estado da aplicacao executando as tarefas de

sincronizacao de dados sempre que pertinente Este metodo embora imediato e

simples de implementar depressa se revelou inadequado para o projecto devido ao

elevado consumo de recursos do servidor que a utilizacao intensiva faz esperar a

comunidade da plataforma WOW no principal cliente excede os 7000 utilizadores

Foi estimado que para uma utilizacao de fluidez aceitavel o estado da ligacao deveria

ser testado a cada cinco segundos Assumindo uma adesao (previsao pessimista) de

1 aos servicos offline assistir-se-ia a cerca de 840 pedidos adicionais por minuto

Mas o principal problema desta aproximacao prende-se com o facto de a ver-

ificacao ser feita em intervalos de tempo discretos levando a possibilidade de a

aplicacao poder ter em dado momento uma representacao errada do seu estado

real da ligacao Este problema e ilustrado na Figura 48 onde se ve claramente a

discrepancia entre o estado real da ligacao e a representacao interna que esta tem

Note-se que nesta janela de tempo qualquer accao do utilizador que exija uma

resposta sıncrona do utilizador leva-lo-a para um ldquobeco sem saıdardquo onde nao tera

43

Desenvolvimento

Figura 46 A pagina inicial do WOW apresenta um resumo das ultimas ordens de trabalhoenviadas e recebidas Na imagem pode-se observar a transicao do estado online para offline

acesso a versao offline porque a aplicacao nao fez a transicao automatica nem acesso

a versao online porque na verdade nao possui uma ligacao O que acontecera nesta

situacao sera uma tentativa de acesso ao servidor por parte da aplicacao numa

altura em que este se encontra indisponıvel e o resultado sera uma mensagem de

ldquopedido excedeu o tempordquo apresentado pelo browser Este e um estado sem retorno

porque apos o browser apresentar esta mensagem todos os recursos JavaScript ficam

indisponıveis tornando impossıvel o regresso ao estado anterior ou o tratamento do

erro de qualquer outra forma No entanto as chamadas Ajax podem ser tratadas de

forma especial para a eventualidade de falha e portanto nao constituem problema

44

Desenvolvimento

Figura 47 Ilustracao do funcionamento do Gears numa web application que utiliza ummotor Ajax Os pedidos HTTP ou HTTPS podem ser interceptados e tratados localmenteou podem ser feitos a uma maquina remota consoante se verificarem ou nao as condicoesexpressas no ponto 311 E representado um acesso a uma base de dados local (fornecidapelo Gears) mas a sua utilizacao e opcional

462 Implementacao do modo ldquoutilizador deciderdquo

Este modo de execucao foi ja descrito na seccao 421 e a sua principal carac-

terıstica e ser o utilizador a decidir se a aplicacao deve utilizar um servidor remoto

ou a maquina local como fornecedor de dados

Relativamente ao WOW o WOW Offline na vertente ldquoutilizador deciderdquo vem

alterar os seus casos de uso dando ao utilizador a possibilidade de alterar o estado

de execucao da aplicacao (entre online e offline) Resta dizer que no modo online se

mantem todas as funcionalidades anteriores e que no modo offline torna-se possıvel

visualizar os conteudos da pagina principal do WOW (Figura 46) e os detalhes das

ordens de trabalho (Figura 49) tal como expressa a Figura 410

Esta aproximacao foi utilizada na prova de conceito do WOW adicionando um

controlo a interface desta aplicacao que permite ao utilizador alternar entre os esta-

dos online e offline Na transicao de online para offline sao descarregados os recursos

necessarios para a execucao desta aplicacao sem recorrer a Internet Para o fazer

45

Desenvolvimento

Figura 48 Neste exemplo do modo ldquoaplicacao deciderdquo o teste da ligacao e feito e feito acada cinco segundos O resultado deste teste nao reflecte sempre o estado real da aplicacaopodendo levar a aplicacao a ter comportamentos indesejaveis Na figura assinala-se umperıodo de tempo no qual a representacao interna do estado da ligacao nao corresponde arealidade

e utilizado um recurso ResourceStore e um ManagedResourceStore (introduzidos

em 311) O primeiro e utilizado para armazenar a pagina principal do WOW ndash do-

ravante designada por homejsp ndash e o segundo e utilizado para armazenar imagens

folhas de estilo CSS e scripts JavaScript

Para a implementacao deste modo de execucao foram identificadas as seguintes

tarefas

1 Guardar informacao que permita a recriacao das paginas que se pretende

disponibilizar offline (utilizando o Gears)

2 Disponibilizar um controlo que permita alterar o estado de execucao atraves

da interaccao com a pagina principal

3 Durante a sincronizacao de dados apresentar o progresso da transferencia de

dados

O primeiro passo consistiu na identificacao de todos os conteudos que sao necessarios

transferir para a execucao offline Foi utilizado um recurso do Gears do tipo

ManagedResourceStore que recorre a um ficheiro manifesto para identificar to-

dos os ficheiros que deve transferir Este recurso e gerido automaticamente pelo

Gears transferindo para o cliente a versao mais recente sempre que e necessario

isto e sempre que exista um ficheiro manifesto com uma identificacao de versao que

seja diferente da actualmente disponıvel no cliente Uma vez identificados todos

ficheiros necessarios para a execucao offline num (ou mais) ficheiros manifesto o

Gears encarrega-se da sua actualizacao mas o preenchimento destes ficheiros man-

ifesto e manual o que se traduz num cuidado extra na manutencao da aplicacao

A forma como esta informacao e guardada deve tambem ser cuidadosamente

estudada A opcao mais flexıvel passa por utilizar o modulo Database apresentado

na seccao 311 e guardar a informacao de uma forma relacional Para a recriacao

das paginas pode ser disponibilizada uma versao HTML da pagina que funciona

46

Desenvolvimento

Figura 49 Pagina de visualizacao do detalhe de uma ordem de trabalho

como template nao possui quaisquer dados e e utilizada apenas em modo offline E

preenchida para cada pedido retirando os dados relevantes da base de dados

O modelo de dados do WOW torna esta opcao extremamente trabalhosa uma

vez que as entidades envolvidas na geracao de cada pagina de informacao sobre

cada ordem de trabalho tem relacoes de dependencia complexas seguindo padroes

muito variaveis Por exemplo em cada ordem de trabalho existe um formulario que

permite a sua progressao de estado com diversos campos opcionais e obrigatorios

este formulario e definido pelo administrador e esta relacionado nao apenas com o

tipo de ordem de trabalho mas tambem com o estado actual em que esta se encontra

e a accao que se pretende realizar O elevado numero de combinacoes de tipos de

ordem de trabalho estados e accoes que existem num dado momento juntamente

com a sua possibilidade de alteracao obrigariam a implementacao de uma logica de

negocio complexa o que esta fora do ambito deste projecto

47

Desenvolvimento

Figura 410 Esquema UML que expressa os casos de uso do WOW Offline no modoldquoutilizador deciderdquo

463 Especificacao do modo ldquoaplicacao assume o estado offlinerdquo

A aproximacao para o modo ldquoaplicacao assume o estado offlinerdquo foi tambem

dividida em varias tarefas

1 Guardar informacao que permita a recriacao da pagina principal do lado do

cliente no estado offline (utilizando o Gears)

2 Dotar a aplicacao do cliente de um mecanismo de deteccao da ligacao

3 Identificar os ldquomomentos chaverdquo em que devera ocorrer sincronizacao de dados

4 Implementar a sincronizacao de dados

A sincronizacao de dados deve ser feita em ambas as transicoes online-offline e

offline-online quer para transferir novos dados do servidor (os pedidos podem ser

alterados por outros utilizadores) quando se transita do estado quer para comunicar

eventuais alteracoes feitas em modo offline

Relativamente ao WOW o WOW Offline na vertente ldquoaplicacao assume o es-

tado offlinerdquo vem alterar os seus casos de uso dando ao utilizador a possibilidade

de activar esta funcionalidade A partir do momento que a funcionalidade esta ac-

tivada o utilizador deve tambem ter a possibilidade de gerir algumas preferencias

relacionadas com privacidade de dados Devera ter a hipotese de desactivar o ar-

mazenamento local e de remover todos os dados ja armazenados tal como descrito

na Figura 411

48

Desenvolvimento

Figura 411 Esquema UML que expressa os casos de uso do WOW Offline no modoldquoutilizador deciderdquo

A primeira vez que o WOW Offline e acedido por um cliente e caso seja detec-

tada a presenca do Gears todos os recursos necessarios a sua execucao sao trans-

feridos Todos os acessos posteriores serao feitos a estes recursos locais (recorda-se

que o Gears pode ser utilizado para os manter actualizados recorrendo ao Managed-

ResourceStore 311)

Atraves do JavaScript e possıvel interceptar os eventos de load e unload da

pagina que sao despoletados sempre que ocorre um re-acesso da mesma (incluindo

a accao refresh comum dos browsers) sempre que esta e abandonada ou ainda ou

ainda se a janela for encerrada

Tal como sugerido na seccao 462 a camada de interface desta aplicacao (cada

pagina individual em HTML) devera ser implementada como sendo um template

para apresentacao de dados sendo totalmente preenchida atraves de funcoes em

JavaScript O objectivo deste ponto e criar um padrao de dados que permita ao

JavaScript preencher os dados em cada pagina (template) independentemente de

qual seja a fonte ndash o servidor remoto ou a maquina local tal como exemplificado

no diagrama da Figura 412 Na figura a aplicacao recorre ao servidor remoto para

obter os dados pretendidos quando se encontra na presenca de uma ligacao mas

para dados que exijam uma carga de processamento pelo servidor este acto pode ser

49

Desenvolvimento

Figura 412 Esquema UML que expressa o acto de recolha de dados em modo online eoffline recorrendo ao servidor (modo online) e ao sistema de armazenamento de dadoslocal fornecido pelo Gears (modo offline)

substituıdo pelo envio de um campo de controlo que se destina a aferir se os dados

locais se encontram actualizados No caso de estarem actualizados a comunicacao

com o servidor pode ser substituıda por uma query a base de dados local

50

Capıtulo 5

Resultados e Futuros

Desenvolvimentos

Todo o estudo feito sobre o tema OWA foi ja abordado ao longo do documento

Neste capıtulo apresentam-se os resultados obtidos na implementacao da prova de

conceito que visava compreender a melhor forma de disponibilizar uma versao of-

fline no WOW uma plataforma de gestao de ordens de trabalho ja existente de-

senvolvida pela Critical Software SA

51 Resultados Obtidos

Os resultados obtidos neste projecto sao extremamente satisfatorios uma vez

que o estudo do tema OWA e a implementacao de uma prova de conceito que o

ilustrasse foi conseguido com sucesso

A funcionalidade offline foi adicionada ao produto WOW da Critical Software

SA permitindo a visualizacao de ordens de trabalho e dos seus detalhes mesmo na

ausencia de uma conexao activa a Internet Embora para a solucao implementada

tenha sido utilizada uma abordagem do tipo ldquoutilizador deciderdquo pretende-se que esta

seja convertida para ldquoaplicacao deciderdquo ou mesmo para uma aproximacao hıbrida

semelhante a utilizada pelas aplicacoes estudadas nas seccoes 351 e 352

Para a sua implementacao descrita no capıtulo 4 foram tomadas decisoes de or-

dem pratica que permitissem tornar o trabalho exequıvel nos prazos dados Tentou-

se sempre que estas decisoes afectassem o mınimo em termos de desempenho e de

experiencia para o utilizador Considera-se que a implementacao do modo offline

com uma transicao entre modos do tipo ldquoutilizador deciderdquo (ver seccao 42) reflecte

o compromisso entre o desempenho pretendido e os recursos disponıveis e para alem

51

Resultados e Futuros Desenvolvimentos

de ser um exemplo eficaz das possibilidades que as OWA podem trazer a aplicacao

WOW desenvolvida pela Critical Software e tambem um estudo que pode ser uti-

lizado para analisar a implementacao desta tecnologia noutros produtos da mesma

empresa

Note-se que o principal objectivo do trabalho era ganhar familiaridade com este

tema entender as suas vantagens e desvantagens e compreender as suas limitacoes

Tudo indica que existam varias possibilidades de implementacao deste paradigma

noutros produtos da Critical Software que pela sua natureza podem tambem tirar

partido da execucao offline

52 Trabalho Futuro

O desenvolvimento do conceito e formas de implementacao de OWA continua

em forte desenvolvimento no entanto a sua adopcao ainda nao e generalizada A

dificuldade da sua implementacao em web applications ja existentes e o principal

obstaculo a sua maior divulgacao

Ha tambem um factor que deve ser tido em consideracao a manutencao de

codigo A implementacao de uma versao offline de uma web application requer

a implementacao das mesmas regras de negocio (ou de uma versao simplificada)

utilizadas no servidor Para que isto seja possıvel e necessario ter em conta a

capacidade de processamento do cliente e o factor de duplicacao de codigo que

tornara a aplicacao mais difıcil de manter uma vez que uma alteracao a logica de

negocio do servidor implica tambem uma alteracao a sua versao offline

A prova de conceito implementada permite ja a visualizacao offline dos pedidos

abertos (enviados e recebidos) que constam na pagina principal (este numero e

fixo e pode ser alterado pelo administrador) Uma funcionalidade desejavel seria a

possibilidade de interaccao com a aplicacao em modo offline e sincronizacao com o

servidor quando existisse uma ligacao disponıvel

Foi estudada a utilizacao do modo de execucao ldquoaplicacao assume o estado of-

flinerdquo descrito em 423 e esta seria a forma desejavel para o WOW Offline no

entanto para que esta opcao seja viavel sera necessaria a implementacao de uma

forma eficiente de sincronizacao e armazenamento de dados de uma forma relacional

Para atingir este objectivo podera ser seguida uma polıtica de automacao do pro-

cesso no qual a versao online da aplicacao gera scripts de criacao para as tabelas

necessarias na base de dados da versao offline (nao existe nenhuma ferramenta para

o fazer portanto seria necessaria a sua implementacao) e no qual as paginas HTML

disponibilizadas pelo servidor aos clientes web (browser) servem como templates de

apresentacao de informacao e sao preenchidas de forma semelhante pelo servidor ndash

quando a aplicacao estiver online ndash ou pelo cliente atraves de funcoes em JavaScript

52

Resultados e Futuros Desenvolvimentos

ndash quando a aplicacao estiver offline No entanto no WOW devido a quantidade de

informacao tratada e devido as complexas relacoes entre as diferentes entidades e

de esperar que a complexidade da implementacao de um mecanismo deste tipo torne

esta aproximacao demasiado custosa

O HTML 5 embora um forte candidato ainda nao esta suficientemente desen-

volvido A sua especificacao ainda tem o caracter de Draft (rascunho) e esta sujeita

a modificacoes e a aceitacao e implementacao por parte dos browsers e portanto

de momento foi desconsiderado No entanto no futuro se esta especificacao atingir

um estado de maturidade que permita a sua adopcao devera ser considerada como

um possıvel caminho a seguir

53

Resultados e Futuros Desenvolvimentos

54

Capıtulo 6

Conclusoes

Neste capıtulo sao apresentadas as conclusoes do projecto e consideracoes finais

relativamente a tecnologia estudada

61 Conclusoes

O rapido desenvolvimento tecnologico faz prever que a disponibilidade de ligacao

a Internet seja cada vez mais facil e mais rapido mas vao continuar a existir lugares

onde o acesso e limitado e onde as OWA podem desempenhar um papel de relevo

Por outro lado esta tecnologia pode tambem ser utilizada para melhorar o desem-

penho de paginas web com uma necessidade elevada de imagens ou outros recursos

dispendiosos em termos de espaco e foram ate estudados dois exemplos da utilizacao

desta vertente desta tecnologia em 353

Acredita-se que as OWAs vem responder a uma necessidade real por parte das

web applications actuais e que a evolucao que representam se compara a que se

assistiu dos thin-clients para os fat-clients em termos de autonomia do servidor

A capacidade de oferecer conteudos dinamicos no browser independentemente da

existencia de uma ligacao reune as vantagens tıpicas das web applications como

ausencia de instalacao e actualizacoes instantaneas com as vantagens das aplicacoes

de desktop em capacidade de processamento e armazenamento de dados na maquina

local

As tecnologias disponıveis ate a data estudadas no ambito deste projecto que

permitem o desenvolvimento de OWAs e que apresentam maior maturidade sao o

Gears e o Adobe AIR Ambas se apresentam sobre a forma de plugins que necessitam

de uma instalacao extra para poderem ser utilizadas Apesar de esta instalacao ser

55

Conclusoes

apenas necessaria uma vez podera constituir um factor de desencorajamento a sua

adopcao

O HTML 5 uma especificacao abordada neste documento na seccao 34 podera

ser uma alternativa que oferece funcionalidades offline a uma web application sem a

necessidade de qualquer instalacao no entanto esta especificacao ainda nao foi aceite

pelos principais browsers ndash o documento que define o HTML 5 ainda tem o estatuto

de Draft ndash e ainda nao e possıvel antecipar quando e que isto podera acontecer

Um dos problemas que surge frequentemente na implementacao de uma versao

offline para uma web application e a necessidade de sincronizacao de dados Quando

a informacao pode ser alterada por varios utilizadores simultaneamente e necessario

prever os conflitos que daı podem surgir e dotar a aplicacao de uma forma de os

resolver ou alertar o utilizador para a necessidade de alteracao dos dados

Em conclusao todos os objectivos propostos para este projecto foram atingidos

A prova de conceito implementada reflecte de forma clara as possibilidades oferecidas

pela tecnologia OWA e sera utilizado no futuro para compreender a melhor forma

de o implementar de forma definitiva no WOW

56

Referencias

[Ada08] Lucas Adamski Introducing Adobe AIR security model Fevereiro de2008 Disponıvel em httpwwwadobecomdevnetairarticles

introduction_to_air_securityhtml acedido em Marco de 2008

[Ado08] Adobe Adobe AIR 10 Security White Paper 2008 Disponıvel emhttpdownloadmacromediacompubairdocumentation1air_

securitypdf acedido em Marco de 2008

[Alm08] Dion Almaer Gears as a bleeding-edge html 5 implementa-tion March 2008 Disponıvel em httpalmaercomblog

gears-as-a-bleeding-edge-html-5-implementation acedido emMarco de 2008

[BL96] Tim Berners-Lee The world wide web Past present and future Agostode 1996 Disponıvel em httpwwww3orgPeopleBerners-Lee

1996ppfhtml acedido em Abril de 2008

[CDGH08] Mike Chambers Daniel Dura Dragos Georgita and Kevin Hoyt AdobeAIR for JavaScript Developers OrsquoReilly Media 2008 Disponıvel emhttponairadobecomfilesAIRforJSDevPocketGuidepdf ace-dido em Abril de 2008

[Con99] Jim Conallen Modeling Web Application Architectures with UML Junho1999 Disponıvel em httpwwwumlorgcnUMLApplicationpdf

webappspdf acedido em Maio de 2008

[Ent07] Entrust What is a public key information 2007 Disponıvel em http

wwwentrustcompkihtm acedido em Junho de 2008

[Gar05] Jesse James Garret Ajax A new approach to web applicationsFebruary 2005 Disponıvel em httpwwwadaptivepathcomideas

essaysarchives000385php acedido em Marco de 2008

[Greon] Philip Greenspun Philip and Alexrsquos Guide to Web Publishing 2003(last revision) Disponıvel em httpphilipgreenspuncompandaacedido em Junho de 2008

[Gro02a] App Design Group Thick vs thin client comparison 2002 Disponıvelem httpwwwdonjacobsvwcomimagesweekendspecials

Thick-vs-Thinpdf acedido em Junho de 2008

57

REFERENCIAS

[Gro02b] Technical Research Group Thin Client Tecnhology - WhitePaper 2002 Disponıvel em httpwwwpicktrgcompubs

thinclientwhitepaperpdf acedido em Junho de 2008

[Gro08] Miniwatts Marketing Group World internet usage March 2008Disponıvel em httpwwwinternetworldstatscomstatshtm ace-dido em Abril de 2008

[Hic08] Ian Hickson HTML 5 Draft Recommendation 2008 Disponıvelem httpwwwwhatwgorgspecsweb-appscurrent-work ace-dido em Marco de 2008

[Kha] Olga Kharif Top 10 municipal wifi plans Disponıvel em http

imagesbusinessweekcomss0608muni_wifiindex_01htm ace-dido em Marco de 2008

[Lab07] Mozilla Labs Prism Outubro 2007 Disponıvel em httplabs

mozillacom200710prism acedido em Marco de 2008

[Loo06] Chris Loosley Rich Internet ApplicationsDesign MeasurementandManagement Challenges 2006 Disponıvel em httpwwwkeynote

comdocswhitepapersRichInternet_5pdf acedido em Maio de2008

[Mic08] Microsoft Introduction to Occasionally Connected Applications us-ing Sync Services for ADONET 2008 Disponıvel em httpmsdn

microsoftcomen-ussyncbb887608aspx acedido em Junho de2008

[Nao08] Erica Naone Offline web applications Abril 2008 Disponıvelem httpwwwtechnologyreviewcomread_articleaspxch=

specialsectionsampsc=emerging08ampid=20245 acedido emAbril de 2008

[NJN00] Jason Nieh Yang S Jae and Naomi Novik A comparison of thin-clientcomputing architectures 2000 Disponıvel em httpwwwnclcs

columbiaedupublicationscucs-022-00pdf acedido em Maio de2008

[OrsquoR06] Tim OrsquoReilly Web 20 compact definition Trying again Dezembro2006 Disponıvel em httpradaroreillycomarchives200612

web-20-compact-definition-tryihtml acedido em Marco de 2008

[OrsquoR09] Tim OrsquoReilly What is Web 20 Design patterns and business modelsfor the Next Generation of Software 20053009 Disponıvel emhttpwwworeillynetcompubaoreillytimnews200509

30what-is-web-20html acedido em Marco de 2008

[Rus06] Alex Russel Comet Low latency data for the browser March Marco2006 Disponıvel em httpalexdojotoolkitorgp=545 acedidoem Marco de 2008

58

REFERENCIAS

[Sad97] Darleen Sadoski Clientserver software architecturesndashan overviewAgosto 1997 Disponıvel em httpwwwseicmuedustr

descriptionsclientserver_bodyhtml acedido em Junho de2008

[Sch96] George Schussel Clientserver past present and future 1996

[Smi07] Kevin C Smith Css filters - will the browser apply the rule July 2007Disponıvel em httpcentriclecomrefcssfilters acedido emMarco de 2008

[vK08] Anne van Kesteren The XMLHttpRequest Object W3C Work-ing Draft 15 Abril 2008 Disponıvel em httpwwww3orgTR

XMLHttpRequest acedido em Abril de 2008

[Wil06] Greg Wilkins Why ajax comet July Julho 2006 Disponıvel emhttpwwwwebtidecomdownloadswhitePaperWhyAjaxhtml ace-dido em Abril de 2008

59

REFERENCIAS

60

Anexo A

Screenshots

Algumas imagens de aplicacoes que utilizam funcionalidades offline ilustrativasda tecnologia abordada neste documento

Figura A1 Dialogo apresentado ao utilizador na primeira activacao das funcionalidadesoffline no Google Docs amp Spreadsheets

61

Screenshots

Figura A2 Na activacao das funcionalidades offline e tambem oferecida a possibilidadeda criacao de alguns atalhos por exemplo no ambiente de trabalho

Figura A3 O Google Docs mantem a todo o momento a possibilidade de alteracao destasdefinicoes ou da anulacao dos servicos offline para um dado computador

62

Screenshots

Figura A4 Apos a instalacao do Gears qualquer visita ao Remember The Milk despoletauma sincronizacao que ocorre automaticamente e sem necessidade de intervencao por partedo utilizador

Figura A5 Apos completar a sincronizacao de dados mesmo que a ligacao a Internetseja perdida o Remember the Milk continua disponıvel no browser (com excepcao dasfuncionalidades que pela sua natureza exigem uma ligacao como por exemplo partilhade tarefas e envio de convites)

63

Page 15: O ine Web Applications

LISTA DE TABELAS

xii

Glossario

fat-client Cliente que nao depende totalmente de umservidor central para as suas actividadesde processamento e possui frequentementedispositivos de armazenamento de dados

6ndash8

thin-client Cliente que depende de um servidor centralpara as suas actividades de processamento

5ndash8

web application Sistema web (servidor rede HTTPbrowser) onde accoes do utilizador(navegacao e introducao de informacao)afectam o estado logico da aplicacao

i iii1ndash311ndash1517ndash1921ndash232728 3336ndash3842 5556

API Application Programming Interface 10 1718 2326 28

ASP Linguagem interpretada pelo servidorque permite a criacao de paginas webdinamicas Desenvolvida pela Microsoft

11

BSD Berkeley Software Distribution 28

CSS Cascading Style Sheets 12 2021 2324 46

DHTML Dynamic HyperText Transfer Protocol 24DOM Document Object Model 10 12

20 2324

DTD Document Type Definition 24

xiii

Glossario

ECMAScript Padrao de linguagem de programacaodefinido pela Ecma International que orig-inou o JavaScript e o JScript

24

Flash Conteudo interactivo de um ficheiro emformato SWF E desenvolvido pela Adobee visualizado atraves do Adobe FlashPlayer

21

Flex Framework baseada em XML e Action-Script desenvolvida pela Adobe para a pro-gramacao de Rich Internet Applications(RIA)

21

GPL GNU General Public License 23

HTML HyperText Markup Language 1 10ndash12 2124ndash2649

HTTP HyperText Transfer Protocol 2 26

JMS E uma API em Java que permite a troca demensagens entre componentes de software

42

JSON JavaScript Object Notation permite atroca de dados codificados num formatode texto de simples leitura

12 1828 34

LGPL GNU Lesser General Public License 23

Mozilla Prism Browser simplificado e ldquointerpretadorrdquo deeXtensible User Interface Language (XUL)(tambem designado por XULRunner) queacolhe web applications sem a interfacegrafica habitual de um browser

25

MPL Mozilla Public License 23

OCA Occasionally Connected Application 39OWA Offline Web Application i iii

2ndash515 1725 2628 3133 3651 5255 56

PDF Portable Document Format 21

xiv

Glossario

PHP Linguagem interpretada pelo servidorque permite a criacao de paginas webdinamicas mas que pode tambem ser in-vocada a partir da linha de comandos

11

pagina web estatica Pagina web que devolve sempre a mesmaresposta a todos os pedidos para todos osutilizadores e em qualquer contexto

5 9

RIA Rich Internet Applications web appli-cations que apresentam funcionalidadessemelhantes as desktop applications masque mantem a informacao no lado do servi-dor

5 1520 28

RSS Really Simple Syndication 27

SLA Service Level Agreement 40SQLite Segundo a definicao oficial SQLite is a

software library that implements a self-contained serverless zero-configurationtransactional SQL database engine

17

SSB Site Specific Browser 25SSL Secure Sockets Layer 22SWF ShockWave Flash 21

URL Uniform Resource Locator 18

VPN Virtual Private Network 38

WOW Work Orders Web Plataforma de gestaode ordens de trabalho e do seu fluxo de-senvolvida pela Critical Software SA

i iii28 3340ndash434551ndash5356

WWW World Wide Web 11 1214

XBL eXtensible Binding Language 24XHTML eXtensible HyperText Markup Language 12XML eXtensible Markup Language 11 12

23 2428

XSLT eXtensible Stylesheet Language Transfor-mation

12

XUL eXtensible User Interface Language xiv23ndash25

xv

Glossario

xvi

Capıtulo 1

Introducao

Neste capıtulo enquadra-se o tema do projecto introduzindo alguns dos conceitos

nos quais se baseia Apresentam-se as motivacoes ambito objectivos e a estrutura

deste documento

11 Enquadramento

A Internet foi originalmente concebida para ser um espaco de partilha de in-

formacao onde pessoas (atraves de maquinas) pudessem comunicar Na sua origem

as paginas eram estaticas constituıdas por texto formatado em HyperText Markup

Language (HTML) e ligadas entre si [BL96] Hoje encontramos conteudos cada vez

mais complexos e dinamicos incluindo som vıdeo ou streams multimedia [Loo06] e

em 2005 foi introduzido por [OrsquoR09] o termo Web 20

De acordo com [Greon] um website pode pertencer a uma ou varias das seguintes

categorias

bull Documento ndash um website essencialmente estatico onde alteracoes a uma

parte do conteudo nao tem implicacoes no seu comportamento

bull Base de dados ndash um directorio de informacao organizada em categorias

bull Aplicacao ndash um website dinamico que utiliza uma linguagem executada ou

interpretada do lado do servidor e que processa as accoes ou informacao in-

troduzida pelo utilizador para fornecer um servico ou nova informacao

A ultima destas categorias constitui aquilo que e normalmente designado por

web application O conceito utilizado ao longo deste documento e o mesmo que

o introduzido por Jim Coallen em [Con99] que define web application como um

1

Introducao

sistema web (servidor rede HyperText Transfer Protocol (HTTP) browser) onde

accoes do utilizador (navegacao e introducao de informacao) afectam o estado logico

da aplicacao A sua definicao tenta estabelecer que uma web application e um

sistema de software com estado de negocio1 e que a sua interface de interaccao com

o utilizador e distribuıdo atraves de um sistema web

12 Motivacao

A quantidade de informacao que e produzida e armazenada com recurso a es-

tas web applications disponıveis online tais como e-mail blogues ou mesmo docu-

mentacao tornam por vezes a disponibilidade de ligacao uma condicao necessaria

a produtividade e como consequencia desta barreira muitos potenciais utilizadores

opoem-se a adopcao de produtos web em detrimento das tradicionais desktop appli-

cations

Assegurar o acesso a uma ligacao de Internet e hoje muito mais facil A Internet

movel e ja uma realidade e encontra-se amplamente divulgada mas continuam a

existir diversas situacoes nas quais os utilizadores estao privados de uma ligacao

a Internet tais como uma viagem de metro ou de aviao ou quando se encontram

deslocados do seu paıs de origem e nao possuem nenhum plano de subscricao

Uma OWA consiste numa web application que para alem de manter todas as

caracterısticas anteriores se mantem disponıvel mesmo na ausencia de uma ligacao

a Internet e surge como uma tentativa de estreitar as barreiras existentes entre a

web e o desktop Isto significa que devera existir um mecanismo capaz de assegurar

a manutencao do estado logico da aplicacao quando a ligacao com o servidor e

quebrada permitindo ao utilizador continuar a utilizar a aplicacao e que sera capaz

de informar o servidor do estado em que a aplicacao se encontra quando a ligacao for

reposta A principal vantagem que advem desta possibilidade e evidente eliminar

a necessidade da existencia de uma ligacao a Internet para que a aplicacao possa ser

utilizada

Por outro lado a vontade de integracao de funcionalidades tıpicas das desktop

applications nas web applications foi um dos principais factores que impulsionou o

desenvolvimento deste conceito uma vez que obrigou a uma reflexao ldquopara alem

do browserrdquo e a uma adaptacao das arquitecturas existentes que permitisse ou o

acesso a funcionalidades disponibilizadas pelo sistema operativo ou pelo menos a

funcionalidades semelhantes Pretende-se com esta aproximacao tornar possıveis

interaccoes entre o desktop e o browser tais como arrastar um ficheiro para um

formulario web de upload de conteudos melhor suporte para o historico do clipboard

ou ainda o acesso ao sistema de ficheiros local Atingir estes objectivos reflecte-se

1NT business state

2

Introducao

num novo paradigma que reune as vantagens das web applications tais como os

updates instantaneos ou o facto de nao ser necessaria nenhuma instalacao e das

desktop applications como por exemplo persistencia no armazenamento de dados

acesso a funcionalidades do sistema operativo ou integracao e interaccao com outras

aplicacoes sejam elas web applications ou desktop applications

13 Ambito

Este projecto foi realizado na Critical Software SA no ambito do Mestrado

Integrado em Engenharia Informatica e Computacao (MIEIC) da Faculdade de En-

genharia da Universidade do Porto (FEUP) entre os meses de Fevereiro e Julho de

2008

14 Objectivos

Sao objectivos deste projecto

1 Estudar e documentar o tema das OWAs acompanhando os ultimos desenvolvi-

mentos nesta materia

2 Analisar o estado da arte fazendo uma analise crıtica e objectiva sobre as

diversas metodologias existentes

3 Implementar uma prova de conceito que permita a execucao offline de uma

web application documentando todo o processo

4 Estudar a possibilidade de permitir interaccao com a aplicacao (insercoes e

alteracoes aos dados) em modo offline

Em resumo o objectivo deste projecto foi estudar documentar e implementar

uma prova de conceito relacionada com o tema Offline Web Applications (OWA)

Este tema embora nao seja totalmente novo ganhou destaque ao longo do ano de

2007 com o surgimento de diversas ferramentas que se destinam a aproximar web

applications das desktop applications

15 Estrutura do documento

Este documento esta organizado em diferentes seccoes apresentando o projecto

numa sequencia logica organizada da seguinte forma

No capıtulo 1 faz-se uma breve apresentacao do conceito OWAs e do contexto em

que surge Apresenta-se tambem a estrutura do documento e definem-se os

termos e acronimos utilizados

3

Introducao

No capıtulo 2 faz-se uma descricao da evolucao das tecnologias que antecedem as

OWAs e das vantagens e desvantagens de cada uma como forma de enquadra-

mento

No capıtulo 3 analisa-se o estado da arte nesta materia Introduzem-se diversas

tecnologias directamente relacionadas com o tema deste projecto exemplos de

aplicacoes que as usam e as razoes que fundamentam as escolhas de tecnologias

efectuadas

O capıtulo 4 contem o desenvolvimento do projecto Analisa-se a plataforma

WOW de gestao integrada de ordens de trabalho a tecnologia escolhida e

a forma como foi utilizada para implementar a capacidade de execucao offline

O capıtulo 5 descreve os resultado obtidos comparando-os com as expectativas

iniciais do projecto e apresenta desenvolvimentos futuros e possibilidades de

continuacaoaplicacao do conhecimento adquirido

No capıtulo 6 apresentam-se as conclusoes

4

Capıtulo 2

Enquadramento do Projecto

Neste capıtulo apresenta-se um breve resumo da evolucao das arquitecturas de

software cliente-servidor e a forma como estas se comparam a evolucao da Inter-

net procurando estabelecer uma analogia entre o percurso de ambas as tecnolo-

gias Compara-se o comportamento e arquitectura dos thin-clients as paginas web

estaticas a evolucao dos fat-clients as paginas interactivas Web 20 e Ajax e

defende-se que as OWA constituem um proximo passo logico e evolutivo aproxi-

mando a web do desktop Referem-se ainda os principais factores que justificam a

importancia das OWAs e a estreita relacao que tem com as Rich Internet Application

(RIA)s

21 Evolucao das arquitecturas de software

Os termos thin-client e fat-client sao utilizados quer para descrever arquitecturas

logicas (de software) quer para descrever arquitecturas fısicas (de hardware) Neste

capıtulo excepto quando seja dada indicacao em contrario estes termos referem-se

sempre a uma arquitectura logica

Adicionalmente quando se trata de arquitecturas cliente-servidor pode-se estu-

dar a arquitectura desenvolvida do sistema como um todo da arquitectura do servi-

dor ou da arquitectura do cliente Para evitar equıvocos em especial na seccao 213

especifica-se em cada caso qual o sistema estudado

211 Thin-clients

Um thin-client e um computador cliente ou software cliente que no contexto

de uma arquitectura cliente-servidor depende de um servidor central para as suas

5

Enquadramento do Projecto

actividades de processamento e proporciona um canal de entrada e saıda de in-

formacao entre o utilizador e o servidor remoto Este termo quando aplicado a

hardware refere-se habitualmente a um computador que se destina a ser utilizado

como cliente de rede sem armazenamento local e com capacidade de processamento

reduzida [Gro02b] mas o conceito que aqui se analisa refere-se a uma arquitectura

de software que remonta ao inıcio das aplicacoes cliente-servidor

No inıcio da historia da computacao terminais ligavam-se directamente a main-

frames responsaveis por todo o processamento Nesta arquitectura era necessario

desenvolver duas aplicacoes distintas uma aplicacao central no servidor (main-

frame) responsavel pela gestao de toda a informacao e por todas as operacoes de

comunicacao e uma aplicacao de visualizacao instalada no cliente (terminal) O

papel destes terminais era apenas disponibilizar ao utilizador um meio de comu-

nicacao (entrada e saıda) e apresentacao dos resultados do servidor Nao tinham

um papel activo no calculo nem na logica de negocio e frequentemente nao tinham

tambem nenhum mecanismo de armazenamento de dados

Como vantagens esta arquitectura apresenta uma reduzida necessidade de con-

figuracao e manutencao do lado do cliente Uma vez que o centro do processamento

e manipulacao de dados ocorre no servidor existe tambem uma centralizacao da

informacao [NJN00] que introduz um ponto crıtico de falha1 Actualizacoes e novas

funcionalidades sao faceis de distribuir uma vez que requerem apenas alteracoes no

servidor [Gro02a]

212 Fat-clients

Contrastando com os thin-clients nesta arquitectura os clientes implementam

ja uma parte da logica de negocio e sao responsaveis pelo processamento de dados

Estes fat-clients vieram responder a necessidade crescente de aplicacoes com um

nıvel de interactividade e capacidade de configuracao maior que as oferecidas pela

arquitectura thin-client descrita na seccao 211 Apesar de manterem a sua de-

pendencia do servidor podem tambem ser executados sem uma conexao activa uma

vez que dispoe de armazenamento de dados local o que lhes confere a capacidade

de persistencia de dados e do estado de execucao entre cada sessao

Foi disponibilizando este controlo sobre o estado da aplicacao bem como acesso

a recursos locais (por exemplo sistema de ficheiros e perifericos) que surgiram as

primeiras verdadeiras desktop applications No entanto cada cliente tinha que ser

separadamente instalado no computador pessoal de cada utilizador que pretendesse

utilizar ou interagir com a aplicacao e uma actualizacao ao servidor implicava in-

variavelmente uma actualizacao manual tambem no cliente Uma vez que nem todos

1NT single point of failure

6

Enquadramento do Projecto

Thin-clients Fat-clientsNao toma parte no processamento dedados nem possui acesso ao sistema deficheiros

Participa activamente no processa-mento de dados recorrendo ao sis-tema de armazenamento local para ar-mazenamento de dados

Nao mantem registo do estado logicoda aplicacao entre duas sessoes de uti-lizacao

O acesso ao armazenamento localpermite-lhe manter registo do estadologico da aplicacao entre duas sessoes

O thin-client nao necessita de qualquerinstalacao estando ldquopronto a utilizarrdquo

E geralmente necessario instalar aaplicacao para poder interagir com oservidor

Qualquer update no servidor reflecte-seimediatamente por todos os clientes

Embora a aplicacao cliente possa aler-tar para existencia de novas versoes asactualizacoes tem que ser manualmenteinstalados pelo cliente

O software do cliente destina-se apenasa apresentacao de dados e comunicacaocom o servidor sendo portanto de sim-ples implementacao

Como o software do cliente toma parteactiva no processamento de dadosa sua implementacao requer cuidadosadicionais

Grande mobilidade uma vez que todaa informacao e mantida no servidor

Parte da informacao podera estar ape-nas do lado cliente pelo que existemalgumas restricoes a sua mobilidade

Tabela 21 Comparacao entre thin-clients e fat-clients

os utilizadores actualizam regularmente as suas aplicacoes o servidor tem que estar

preparado para lidar com versoes antigas2 ou descontinuar os seus servicos a uma

parte da sua comunidade de utilizadores ate que estes actualizem os seus sistemas

Como os utilizadores passam a utilizar os seus recursos locais para armazenamento

de dados as alteracoes que nao sejam sincronizadas com o servidor estao apenas

disponıveis nos seus computadores pessoais o que introduz uma restricao a mobili-

dade

Pode-se afirmar que as vantagens dos thin-clients sao as desvantagens dos fat-

clients e que as vantagens dos fat-clients sao as vantagens dos thin-clients tal como

se ilustra na Tabela 21

213 Arquitecturas cliente-servidor

Introduzidos os termos thin-client e fat-client interessa reafirmar que ambos

podem ser vistos como arquitecturas cliente-servidor Um cliente define-se como

um solicitador de servicos e um servidor como um prestador de servicos tal como

definido por [Sch96] e [Sad97]

2NT backward compatibility

7

Enquadramento do Projecto

As arquitecturas cliente-servidor sao categorizadas pela modularizacao com que

sao desenhadas sendo consideradas as seguintes camadas

1 Interface grafica (front-end) atraves da qual os utilizadores interagem com

a aplicacao Quando este modulo e implementado separadamente dos outros

dois constitui uma aplicacao thin-client por si so uma vez que nao implementa

regras de negocio (embora possa definir validacoes de formularios de insercao de

dados por exemplo) A informacao introduzida pelo utilizador e enviada para

o servidor que processa o seu pedido e retorna uma resposta Este processo

repete-se ate que o utilizador atinja o seu objectivo ou se desligue do sistema

2 A logica de negocio tambem designada por camada intermedia que imple-

menta as regras de aceitacao e validacao de todos os dados introduzidos pelo

utilizador E tambem a plataforma de comunicacao que une a camada superior

de visualizacao com a camada de acesso a dados

3 A camada de dados inclui quer o sistema de persistencia de dados onde sao

armazenados os dados relevantes como tambem os mecanismos necessarios

para a sua pesquisa seleccao e alteracao

Os thin-clients quando observados no seu conjunto de cliente e servidor podem

ser vistos quer como sistemas de duas camadas quer como sistemas de tres camadas

dependendo apenas da forma como o servidor for implementado No caso de na

implementacao do servidor nao se distinguir a camada de acesso a dados da camada

da logica de negocio sao designados por sistemas de duas camadas Caso seja feita

esta distincao sao designados por sistemas de tres camadas Ambos os casos sao

ilustrados na Figura 21

Historicamente os fat-clients eram implementados numa arquitectura em duas

camadas Possuıam apenas um modulo de visualizacao de dados designado por

camada de interface e um modulo que implementava toda a logica de negocio e

regras de acesso a base de dados No entanto com a introducao de ligacoes mais

rapidas e de computadores pessoais com maior capacidade de processamento e so-

bretudo devido a complexidade crescente das aplicacoes a logica de negocio e a

camada de acesso a dados tornaram-se independentes Este modelo e designado por

arquitectura em tres camadas e e ilustrado na Figura 22

22 Evolucao na Internet

Ao analisar a evolucao das arquitecturas das aplicacoes desenvolvidas para a

Internet podemos encontrar um paralelismo com a historia da arquitectura de soft-

ware

8

Enquadramento do Projecto

Figura 21 Arquitectura de um sistema thin-client em duas camadas (a esquerda) e emtres camadas (a direita) Note-se a inclusao do servidor (mainframe) na definicao dascamadas desta arquitectura devido a forte dependencia cliente-servidor

221 Paginas web estaticas

Uma pagina web estatica devolve sempre a mesma resposta a todos os pedidos

para todos os utilizadores e em qualquer contexto utilizando o hipertexto como

forma de ligacao entre diversas paginas estaticas

A informacao e armazenada num servidor e o papel do cliente e apenas a apre-

sentacao da informacao Esta forma de disponibilizacao de informacao pode assim

ser comparada com os thin-clients descritos na seccao 211 o utilizador acede a

um website estatico para visualizar informacao sem que o cliente tome parte no

processamento A unica diferenca e que no caso da web estatica a informacao ap-

resentada e sempre a mesma enquanto que nos thin-clients era frequente existir a

possibilidade de insercao de dados no cliente e apos o seu processamento servidor

nova informacao poderia ser apresentada O hipertexto e utilizado para ligar as

paginas entre si numa rede de conteudos relacionados e a navegacao sıncrona era

feita atraves de cliques do rato a cada clique uma nova pagina era apresentada

Este modelo sıncrono e ilustrado na Figura 23

222 Paginas web interactivas e paginas web dinamicas

O JavaScript e uma linguagem interpretada de scripting que tem os browsers

como principal ambiente de acolhimento Os browsers utilizam uma Application

9

Enquadramento do Projecto

Figura 22 Arquitectura de um fat-client em duas camadas (a esquerda) e em tres camadas(a direita)

Programming Interface (API) publica para criar ldquoobjectosrdquo responsaveis por reflectir

e disponibilizar o Document Object Model (DOM) para o motor de JavaScript

A utilizacao mais frequente desta linguagem e a escrita de funcoes que sao em-

bebidas ou incluıdas em paginas web e que interagem com o DOM Uma vez que o

JavaScript e executado localmente (na maquina do cliente e nao no servidor) e capaz

de responder rapidamente a accoes do utilizador tornando a execucao de aplicacoes

no browser mais fluıdas o JavaScript pode tambem detectar accoes do utilizador

que o HTML nao pode tal como o pressionar de uma tecla

Em Dezembro de 1995 a Netscape Communications adicionou suporte para o

JavaScript no browser Netscape Navigator3 e em Agosto de 1996 o browser Internet

Explorer4 da Microsoft passou a tambem a suportar uma versao semelhante desta

linguagem (hoje todos os principais browsers suportam esta tecnologia)

Esta inovacao permitiu tornar os websites mais interactivos mas a sua utilizacao

esteve confinada apenas a este proposito durante um longo perıodo As paginas

passaram a responder activamente a accoes do utilizador (sendo uma das utilizacoes

3Netscape Communications ndash httpbrowsernetscapecom4Microsoft Internet Explorer ndash httpwwwmicrosoftcomwindowsproductswinfamilyie

10

Enquadramento do Projecto

mais vulgares a validacao de formularios) mas continuaram essencialmente estaticas

O JavaScript ainda nao era nesta altura utilizado para processar dados

Tambem nesta altura (1995ndash96) surgiram linguagens server-side como o PHP

Hypertext Preprocessor (PHP) e Active Server Pages (ASP) e o servidor passou a ter

um processamento de dados introduzidos pelo utilizador mais activo Generalizaram-

se as paginas dinamicas capazes de responder a insercao de dados ou outros pedidos

determinados por accoes do utilizador As paginas tornaram-se aplicacoes web ap-

plications

Uma definicao tradicional de web application e um conjunto de paginas web

logicamente agrupadas e geridas por uma unica entidade que tem como pontos de

entrada formularios de insercao de dados (web forms) Uma web application nao e

mais do que uma aplicacao que e acedida atraves de um browser Tem geralmente

uma arquitectura logica em tres (interface logica de negocio e camada de dados)

camadas e estao armazenadas num servidor

Ha dois tipos de web applications

bull Orientadas a apresentacao Sao web applications que geram paginas web in-

teractivas constituıdas por varios tipos de linguagens de anotacao (por exem-

plo HTML eXtensible Markup Language (XML)) e que apresentam conteudo

dinamico como resposta a pedidos efectuados pelo utilizador

bull Orientadas aos servicos Uma web application orientada aos servicos imple-

menta o ponto de acesso para um ou mais de um web service Sao geralmente

clientes de service oriented web applications

Uma vantagem significativa de implementar uma web application de forma a

suportar as funcionalidades padrao dos browsers e que estas terao o mesmo com-

portamento independentemente da plataforma e do browser a partir do qual serao

acedidas No entanto diferentes implementacoes de browsers devido a diferentes

interpretacoes dos padroes definidos tornam por vezes esta tarefa um pouco mais

complicada existindo inclusivamente na web guioes de compatibilidade para os difer-

entes browsers como [Smi07]

223 Web 20 e Ajax

O termo web 20 descreve uma tendencia de utilizacao e de design observada

na World Wide Web (WWW) com o objectivo de melhorar a criatividade partilha

de informacao e principalmente a colaboracao entre utilizadores Estes conceitos

levaram ao desenvolvimento e evolucao de comunidades online tais como redes so-

ciais wikis e blogues

11

Enquadramento do Projecto

O termo tornou-se mais conhecido apos a primeira conferencia OrsquoReilly Media

Web 20 em 2004 e apesar de sugerir uma nova versao da WWW nao se refere a

qualquer evolucao tecnologica mas apenas a alteracoes a forma como os utilizadores

se servem da web De acordo com Tim OrsquoReilly [OrsquoR06] ldquoWeb 20 e uma revolucao

na industria do software causada pela adopcao da web como uma plataforma e pela

tentativa de entendimento das regras para o sucesso nesta nova plataformardquo

O desenvolvimento da Web 20 serve-se muitas vezes de um outro conceito Ajax

O conceito que hoje conhecemos como Ajax muitas vezes incorrectamente de-

scrito como uma tecnologia foi originalmente criado para permitir o desenvolvimento

de web applications que se assemelhassem ainda mais a aplicacoes de desktop Este

conceito foi melhor descrito por [Gar05] como um conjunto de varias tecnologias

que podem ser utilizadas para melhorar a experiencia do utilizador de uma dada

web application introduzindo a capacidade assıncrona de envio de pedidos ou da

recepcao assıncrona de respostas As tecnologias mais frequentemente envolvidas

sao

bull eXtensible HyperText Markup Language (XHTML) e Cascading Style Sheets

(CSS) padrao para a apresentacao

bull interaccao dinamica atraves do DOM

bull troca e manipulacao de dados utilizando XML e eXtensible Stylesheet Lan-

guage Transformation (XSLT) ou JavaScript Object Notation (JSON)

bull pedidos assıncronos utilizando XMLHttpRequest [vK08]

bull JavaScript utilizado para integrar todas estas tecnologias

E importante frisar que o Ajax nao e um produto nem uma tecnologia E um

termo que descreve a utilizacao de um conjunto de tecnologias para o desenvolvi-

mento de web applications com um elevado grau de interactividade Comparativa-

mente as web applications tradicionais o Ajax introduz uma camada de visualizacao

diferente em tres importantes pontos

1 Do lado do cliente existe um motor que serve de intermediario entre a interface

da aplicacao e o servidor

2 A actividade do utilizador despoleta chamadas JavaScript em vez de um pedido

de pagina directamente ao servidor

3 Informacao codificada em XML em vez de paginas HTML e trocada entre o

servidor e o cliente

12

Enquadramento do Projecto

Isto significa que as paginas que utilizam Ajax contem um motor do lado do

cliente composto por um conjunto de funcoes JavaScript responsavel pela comu-

nicacao com o servidor e por actualizar a interface com o resultado dessa mesma

comunicacao

Na Figura 23 ilustra-se a natureza assıncrona do Ajax quando comparada com

as web applications tradicionais Como se pode observar adicionando um mecan-

ismo Ajax a uma web application eliminam-se diversos tempos de espera associados

a comunicacoes com o servidor uma vez que a interface nao fica ldquobloqueadardquo a es-

pera da resposta Obtem-se assim aplicacoes com um comportamento mais fluido

eliminando tempos de espera entre cada ldquocliquerdquo e melhorando a experiencia do

utilizador

23 Offline Web Applications

A informacao grafica (bem como folhas de estilo e scripts) tais como as ima-

gens que constituem o visual de uma web application e ja tratada de forma especial

pelos cada vez mais avancados sistemas de cache (armazenamento temporario) dos

browsers Mas estes nao sao ainda capazes de guardar conteudo criado pelo uti-

lizador nem de apresentar informacao independentemente do estado da ligacao

Numa altura onde se fala de servicos de Internet wireless municipalizados [Kha]

comunicacoes 3G e ligacoes de banda larga a alta velocidade a ligacao a rede global

continua a nao estar permanentemente disponıvel para os utilizadores Na WWW

encontra-se uma importante parte da informacao e das aplicacoes utilizadas para

criar e editar conteudos Por vezes informacao vital para a produtividade pode

desaparecer subitamente do mapa de acesso de um utilizador quando este entra no

metro num aviao ou mesmo quando se desloca para uma cidade ou paıs diferente

do habitual onde nao subscreve um plano de acesso que lhe garanta a ligacao

Permitir o acesso offline a estes recursos assume assim a sua importancia porque

permitira estender o alcance da informacao a locais onde nunca esteve antes e per-

mitira tambem melhorar o desempenho das web applications colocando informacao

mais perto dos utilizadores reduzindo a transferencia de dados apenas ao essencial

24 Comparacao

Nas evolucoes descritas neste capıtulo 2 pode-se observar que existe um par-

alelismo entre a evolucao das arquitecturas tradicionais cliente-servidor e a evolucao

a que se assiste na web O comportamento e arquitectura dos thin-clients assemelha-

se ao das paginas estaticas no sentido em que o browser nao toma parte em qualquer

13

Enquadramento do Projecto

processamento e serve apenas como uma plataforma de interaccao com o servidor

tal como os clientes descritos na seccao 211

A sua proxima evolucao os fat-clients trouxeram parte da capacidade de pro-

cessamento para o lado do cliente Na web foi tambem esta a inovacao tecnologica

a que se assistiu com a evolucao das tecnologias que permitiram a criacao de ver-

dadeiras aplicacoes e com a introducao do Javascript no browser dando ao cliente

a capacidade de processamento de dados A necessidade da separacao do codigo

em camadas logicas advem da crescente complexidade das web applications Esta

pratica permite entre outras coisas melhorar o processo de desenvolvimento e a

capacidade de manutencao de uma aplicacao

Os fat-clients tem tambem a capacidade de armazenamento de dados o que

permite a persistencia de informacoes entre duas sessoes e que algumas operacoes

sejam executadas sem a necessidade de comunicacao com o servidor Este facto pode

tambem ser uma realidade nas web applications com a adopcao das tecnologias OWA

Neste momento assiste-se a uma utilizacao cada vez maior da web como uma

plataforma de desenvolvimento A capacidade de cooperacao na edicao de conteudos

e a mobilidade proporcionada por esta plataforma sao os principais factores que

alimentam esta mudanca e pela primeira vez as aplicacoes tradicionais tem com-

peticao vinda de web applications A prova do reconhecimento da web como plataforma

de desenvolvimento pode ser retirada da aposta de empresas como a Adobe e Mi-

crosoft que lancaram publicamente ferramentas web complementares a produtos

seus tradicionalmente associados ao desktop ndash Acrobatcom5 e Microsoft Office

Live6 Dotar estas web applications da capacidade de execucao offline significa

aproximar a web e o desktop reunindo ldquoo melhor de dois mundosrdquo

As vantagens da mobilidade possıvel atraves da web a cooperacao na criacao e

edicao de conteudos e a possibilidade de utilizar aplicacoes sempre actualizadas e

sem necessidade de instalacao sao algumas das principais vantagens que promovem

esta mudanca que devido as preocupacoes associadas a usabilidade e experiencia do

utilizador esta fortemente associada ao desenvolvimento de Rich Internet Applica-

tion (RIA)s

5Adobe Acrobatcom httpwwwacrobatcom6Microsoft ndash httpsmallbusinessofficelivecom

14

Enquadramento do Projecto

Figura 23 Comparacao do modelo de web aplications sıncrono paginas estaticas e in-teractivas abordados nas seccoes 221 e 222 com o modelo de web applications Ajax(assıncrono) abordado na seccao 223 Figura adaptada de http www adaptivepath

com

15

Enquadramento do Projecto

16

Capıtulo 3

Estado da arte

Apesar de o conceito das OWAs nao ser absolutamente novo as tecnologias que

o suportam sao recentes Neste capıtulo descrevem-se quatro tecnologias que foram

tidas como principais candidatas para o desenvolvimento deste projecto Descrevem-

se ainda alguns exemplos de web applications que disponibilizam actualmente fun-

cionalidades offline e o processo da escolha da tecnologia a utilizar neste projecto

31 Gears

O Gears1 e uma extensao as funcionalidades do browser introduzido pelo Google

que tem como principal objectivo tornar possıvel a visualizacao de paginas de Inter-

net mesmo sem uma conexao disponıvel Encontra-se disponıvel para as platafor-

mas Windows Macintosh e Linux e oferece uma API de Javascript que permite

a scripts aceder a um mecanismo de armazenamento local baseado numa base de

dados SQLite

311 Arquitectura

Esta ferramenta e constituıda por tres componentes principais

bull LocalServer mdash Intercepta pedidos de paginas web e serve-as localmente

bull Database mdash Uma base de dados relacional construıda sobre SQLite

bull WorkerPool mdash Permite executar operacoes de computacao de uma forma

assıncrona sem afectar a capacidade de resposta e fluidez de execucao da web

application Assemelham-se a processos

1Google Inc ndash Mais informacao em httpgearsgooglecom

17

Estado da arte

LocalServer

O modulo LocalServer e uma cache de Uniform Resource Locators (URLs)

controlada pela web application Quando nao existe uma ligacao a Internet e e

feito um pedido para um URL presente nesta cache o LocalServer intercepta-o e

responde ao pedido localmente a partir do disco rıgido do utilizador A aplicacao

pode utilizar dois tipos diferentes de armazenamento local de URLs

bull ResourceStore ndash serve para capturar URLs utilizando exclusivamente a API

de Javascript disponibilizada para o efeito Uma aplicacao podera criar e

utilizar diversos ResourceStores simultaneamente para capturar ficheiros de

dados que necessitam de ser enderecados por um URL tal como um ficheiro

PDF ou uma imagem

bull ManagedResourceStore ndash serve para capturar um conjunto de URLs que estao

relacionados e que sao declarado num ficheiro de manifesto (especificado em

JSON) e que sao automaticamente actualizados O ManagedResourceStore

permite que o conjunto de recursos necessarios para correr uma web application

seja capturado e mantido actualizado automaticamente

A principal diferenca entre estes dois tipos de armazenamento de URLs e a forma

como sao actualizados os seus conteudos Os conteudos de um ManagedResourceStore

sao actualizados sempre que a versao contida no ficheiro de manifesto for alterada

enquanto que os conteudos de um ResourceStore nunca sao actualizados automati-

camente mas apenas quando for explicitamente ordenado pela aplicacao

O LocalServer e capaz de interceptar e servir localmente pedidos de HTTP e

HTTPS sempre que se reunam as seguintes condicoes

1 O URL encontra-se armazenado num ResourceStore ou ManagedResourceStore

2 O sistema de armazenamento local encontra-se activo (enabled = true) Se

o sistema de armazenamento local tiver o atributo requiredCookie o pedido

devera conter um cookie que lhe corresponda

O LocalServer nao necessita de monitorizar o estado da ligacao para atender aos

pedidos Na verdade sempre que as condicoes previamente enunciadas se verificarem

o LocalServer interceptara os pedidos e independentemente do estado da ligacao

a Internet servi-los-a a partir do disco rıgido local Cabera a aplicacao definir qual

o modo em que pretende executar um pedido (online ou offline) definindo o valor

de verdade da propriedade enabled

18

Estado da arte

Database

O modulo Database permite guardar dados da web application assegurando a

sua persistencia Os dados sao guardados de forma relacional no disco rıgido do uti-

lizador2 de acordo com o modelo de seguranca estabelecido pelo Gears3 significando

que uma aplicacao nao pode aceder a conteudos fora do seu domınio

WorkerPool

Nos web browsers uma operacao pesada de computacao pode tornar a interface

lenta e tornar menos agradavel a experiencia do utilizador O modulo WorkerPool

permite correr operacoes em background sem bloquear a interface com o utilizador

Os scripts executados numa WorkerPool nao activam os mecanismos de seguranca

do browser que mostram a mensagem ldquoA script on this page may be busy or may

have stopped respondingrdquo

O WorkerPool comporta-se como um conjunto de processos em vez de threads

Os Workers nao partilham qualquer estado de execucao o que significa que uma

alteracao a uma variavel num Worker nao afecta em nada a execucao de outro

Worker Alem disso os Workers nao herdam automaticamente nenhum codigo dos

seus pais Cada Worker e membro de um WorkerPool e os Workers podem in-

teragir entre si enviando mensagens em formato de texto ou JSON No entanto ha

tambem algumas limitacoes os Workers nao tem acesso ao DOM e objectos como

window ou document nao se encontram acessıveis Isto e consequencia de os Workers

nao partilharem o estado de execucao Mas tem acesso a todas as funcoes built-in

do Javascript A maioria das funcionalidades do Gears pode tambem ser acedida

atraves de uma variavel global especial definida como googlegearsfactory Para

outras funcionalidades especıficas os Workers podem ldquopedirrdquo a pagina principal para

continuar a execucao atraves do envio de mensagens

Outras funcionalidades

bull HttpRequest ndash Este modulo implementa a especificacao W3C XmlHttpRe-

quest definida em [vK08] tornando-a disponıvel para os workers e para a

pagina principal

bull Timer ndash Este modulo implementa a especificacao de timers tal como descrito

por [Hic08] e torna-os disponıveis para os workers e para a pagina principal

2Consultar httpcodegooglecomapisgearsapi_databasehtmldirectories3Consultar httpcodegooglecomapisgearssecurityhtml

19

Estado da arte

bull Factory ndash Esta classe e utilizada para instanciar todos os outros objectos da

API do Gears atraves do seu metodo create Este metodo pode ser utilizado

com os seguintes parametros

ndash betadatabase

ndash betahttprequest

ndash betalocalserver

ndash betatimer

ndash betaworkerpool

312 Goggle Gears em dispositivos moveis

O Gears esta tambem disponıvel em dispositivos Windows Mobile 5 e 6

Os dispositivos moveis estao pela sua natureza frequentemente desconectados

da Internet Mesmo quando possuem uma ligacao as latencias na transferencia de

dados em redes moveis tornam as aplicacoes pouco fluıdas mas o Gears permite

ultrapassar este obstaculo

O Gears funciona exactamente da mesma forma em dispositivos moveis equipados

com o Windows Mobile 5 e 6 como num computador comum Se uma aplicacao tiver

sido implementado com suporte para o Gears entao tambem estara preparada para

ser executada num dispositivo movel mas as limitacoes dos browsers disponıveis

para dispositivos moveis tem que ser consideradas Isto significa prever as condicoes

que permitam uma boa usabilidade devido aos pequenos ecras destes dispositivos

bem como o seu suporte limitado dos padroes do DOM CSS e JavaScript

32 Adobe AIR

O Adobe AIR4 e um runtime compatıvel com diversos browsers e sistemas opera-

tivos que pretende dar aos programadores a possibilidade de combinar diversas tec-

nologias de producao de conteudos para a Internet no desenvolvimento de Rich Inter-

net Application (RIA)s O Adobe AIR mantem uma relacao com o browser mas es-

tende as suas capacidades e tecnologias permitindo o desenvolvimento de aplicacoes

tambem para o ambiente de trabalho com janelas em tudo semelhantes as do sis-

tema operativo Segundo a Adobe o objectivo e complementar o browser dando

aos utilizadores (mas essencialmente aos programadores e equipas de desenvolvi-

mento) a escolha sobre como distribuir as suas aplicacoes Para este efeito o Adobe

AIR tem uma aproximacao diferente do Gears Em vez de ldquoestenderrdquo o browser

acrescentando-lhe funcionalidades o AIR permite tambem o desenvolvimento de

4Adobe - httpwwwadobecomproductsair

20

Estado da arte

aplicacoes que se destinam a ser executadas fora do ambiente do browser mas uti-

lizando as tecnologias comuns da Internet (por exemplo HTML CSS JavaScript

Flash Flex)[CDGH08]

A utilizacao desta tecnologia permite utilizar o browser ou o proprio runtime

Adobe AIR como plataforma de execucao da aplicacao

Na Tabela 31 faz-se uma comparacao das funcionalidades disponıveis de acordo

consoante se escolha o browser ou o desktop como plataforma base para a aplicacao

Uma vez que as aplicacoes Adobe AIR na plataforma desktop tem um caracter

persistente (sao instaladas no computador do utilizador) o Adobe AIR tem um

modelo de seguranca que se assemelha com o das tradicionais aplicacoes desktop

[Ada08] Este modelo e analisado nas seccoes 321 e 322 O ambiente em que

e executado o browser e restringido a execucao de web applications que podem

ser de varias origens (incluindo de origens anonimas ou sem confianca) O Adobe

AIR proporciona acesso a capacidades como acesso a ficheiros que necessitam da

confianca do utilizador

bull HTML ndash O desenvolvimento de aplicacoes para o Adobe AIR pode ser feito

com recurso a tecnologias de HTML e Ajax comuns utilizando as linguagens

de markup existentes distribuıdas como texto e interpretadas em execucao

(runtime)

bull Flash ndash Outra alternativa sera a utilizacao da linguagem Flash Permite a

renderizacao de graficos vectoriais e audiovıdeo com suporte nativo Utiliza

ActionScript para adicionar maior interactividade com o utilizador

bull Flex ndash O Flex e uma framework open source para o desenvolvimento de RIAs

usando Flash As aplicacoes Flex sao na realidade Flash sendo a principal

diferenca o ambiente de desenvolvimento

Como resultado uma aplicacao AIR podera ser implementada

bull Baseada em Flash ou Flex (aplicacoes cujo conteudo base e em ShockWave

Flash (SWF))

bull Baseada em Flash ou Flex tambem com HTML ou Portable Document Format

(PDF) Aplicacoes cujo conteudo de base e em FlashFlex (SWF) com HTML

(HTML JavaScript CSS) ou conteudo PDF incluıdo

bull Baseada em HTML Aplicacoes cujo conteudo base e em HTML Javascript

CSS

bull Baseada em HTML utilizando tambem FlashFlex ou PDF

21

Estado da arte

Os utilizadores interagem com uma aplicacao AIR da mesma forma que interagem

com outras aplicacoes com janelas nativas do seu sistema operativo O runtime e

instalado uma vez no computador do utilizador e a partir desse momento todas as

aplicacoes AIR terao o mesmo aspecto que qualquer outra aplicacao para o desktop

321 Seguranca

Permitir que uma web application aceda ao disco de armazenamento do utilizador

pode comprometer seriamente a sua seguranca Neste sentido o Adobe AIR tem

suporte para assinaturas digitais (Secure Sockets Layer (SSL)) que podem ser com-

pradas pelas equipas de desenvolvimento que o desejem e cujos certificados serao

apresentados ao utilizador no momento da instalacao Um outro aspecto ainda

relativo a seguranca e o mecanismo de isolamento de cada ambiente (sandbox )

322 Assinatura do codigo

O runtime AIR exige que todas as aplicacoes estejam digitalmente assinadas As

assinaturas digitais de codigo sao um processo que visa garantir a integridade da

aplicacao e a identidade do seu autor no momento da instalacao As equipas de

desenvolvimento podem ldquoassinarrdquo uma aplicacao utilizando um certificado atribuıdo

por uma Entidade Certificadora (Certification Authority) ou atraves de um certifi-

cado individual (self signed certificate) Neste momento o Adobe AIR suporta como

entidades certificadoras a Verisign e a Thawte [Ado08]

O instalador apresenta o nome de quem publica a aplicacao quando o codigo tiver

sido assinado com um certificado que apresente confianca ou que esteja encadeado

com um certificado que tenha ja sido aceite no computador em que se esta a instalar

a aplicacao

As equipas de desenvolvimento podem tambem assinar as aplicacoes com um

certificado auto-atribuıdo (um certificado criado por elas proprias) mas neste caso

o instalador apresentara estas aplicacoes como sendo de uma origem nao verificada

O AIR utiliza a infraestrutura publica de chaves [Ent07] suportada pelo arquivo

local do sistema operativo Para que a origem da aplicacao seja reconhecida o

computador onde a aplicacao AIR esta a ser instalada tem que confiar directamente

no certificado que foi utilizado para assinar a aplicacao ou confiar num certificado

que esteja num encadeamento logico de certificados confiados e que se ligue desta

forma ao certificado utilizado para assinar a aplicacao

Todas as aplicacoes AIR tem caracterısticas em comum independentemente da

tecnologia utilizada para o seu desenvolvimento (HTMLFlexFlash) No ambito

de uma aplicacao AIR existem um conjunto de APIs que estao disponıveis e que

tornam possıvel o acesso ao sistema local (leitura e escrita) e a recursos de rede que

22

Estado da arte

de outra forma nunca estariam acessıveis a partir de uma web application comum

Cada aplicacao AIR possui tambem diferentes nıveis de isolamento chamados secu-

rity sandboxes dependendo do tipo de conteudo que esta a ser carregado e do seu

objectivo

bull Isolamento ao nıvel da aplicacao5 ndash E a raiz de cada aplicacao AIR Este

nıvel de isolamento permite o acesso a APIs privilegiadas e especıficas do

AIR Em contrapartida e negado o acesso a algumas APIs que poderiam ser

facilmente utilizadas de forma maliciosa contra o utilizador final Importacao

dinamica de conteudos remotos e geralmente proibido e as tecnicas e mecan-

ismos de geracao dinamica de codigo sao fortemente restringidas Apenas

conteudo carregado directamente da directoria base da aplicacao podera ser

colocado neste nıvel de isolamento

bull Isolamento nao especıfico da aplicacao6 ndash contem todo o outro conteudo

que nao tenha sido carregado directamente para o isolamento da aplicacao

Isto inclui conteudo local e remoto Este tipo de conteudo nao tem acesso

directo as APIs do AIR e rege-se pelas mesmas regras tal como se tivesse sido

carregado por um browser a partir da mesma localizacao (por exemplo HTML

carregado a partir de um domınio remoto comporta-se da mesma forma que se

fosse acedido a partir do browser)

33 Mozilla Prism

331 XML User Interface Language

O eXtensible User Interface Language (XUL) e uma linguagem de anotacao

baseada em XML desenvolvida pela Mozilla Foundation que opera em aplicacoes

Mozilla multi plataforma tal como o Firefox O motor Gecko e a unica imple-

mentacao completa desta linguagem que foi desenhada sobre padroes web comuns

como CSS JavaScript e o DOM e permite o desenvolvimento de interfaces graficas

utilizando elementos pre-definidos tais como window box page textbox radio

button entre outros Infelizmente o XUL nao possui qualquer especificacao formal

ou implementacoes de inter-operabilidade para outros motores que nao o Gecko No

entanto a sua implementacao e licenciada em codigo aberto pelas licencas GNU Gen-

eral Public License (GPL) GNU Lesser General Public License (LGPL) e Mozilla

Public License (MPL)

Enunciam-se algumas caracterısticas desta linguagem

5NT application sandbox6NT non-application sandbox

23

Estado da arte

Liguagem de anotacao poderosa baseada em componentes (widgets) O ob-

jectivo do XUL e permitir a construcao de aplicacoes multi-plataforma em

claro contraste com o Dynamic HyperText Transfer Protocol (DHTML) que se

destina ao desenvolvimento de paginas web Por esta razao o XUL esta orien-

tado a componentes tais como janelas botoes e etiquetas em vez de paginas

cabecalhos de texto e ligacoes de hipertexto Investir tempo e esforco para

atingir este mesmo resultado em aplicacoes baseadas em DHTML compromete

frequentemente a complexidade e desempenho da aplicacao

Baseado em padroes O XUL e um dialecto XML baseado no padrao W3C XML

10 As aplicacoes escritas em XUL sao tambem baseadas em especificacoes

W3C adicionais como HTML 40 CSS DOM nıvel 1 e 2 JavaScript 15

incluindo ECMA-262 Edition 3 (ECMAscript)

Portabilidade entre plataformas Tal como HTML o XUL foi desenhado para

ser independente da plataforma em que e utilizado tornando as aplicacoes

facilmente portaveis entre sistemas operativos nos quais o Mozilla e suportado

Uma vez que o XUL oferece um nıvel de abstraccao dos componentes graficos

de interface que disponibiliza implementa a premissa ldquoum codigo para todas

as plataformasrdquo A interface grafica de todos os produtos centrais Mozilla

(browser instant messenger livro de enderecos) e escrita em XUL com um

unico codigo base que suporta todas as plataformas Mozilla

Separacao entre o nıvel de apresentacao e a logica de negocio Uma das

maiores preocupacoes no desenvolvimento para a Internet e a forte ligacao

entre estas duas camadas (interface e logica) Isto constitui um problema sig-

nificativo no desenvolvimento de grandes aplicacoes especialmente quando o

desenvolvimento e feito em ambientes de equipa porque as capacidades de de-

senvolvimento destas duas partes da aplicacao estao muitas vezes espalhadas

por diferentes elementos O XUL permite uma clara distincao entre a definicao

da aplicacao cliente e da logica de implementacao (XUL eXtensible Binding

Language (XBL) e JavaScript) apresentacao (CSS e imagens) internacional-

izacao (Document Type Definitions (DTDs) e etiquetas de texto em lınguas

especıficas guardados em ficheiros properties) O esquema grafico e apre-

sentacao de uma aplicacao XUL pode ser alterado de forma independente da

sua logica ou implementacao e a aplicacao pode ainda ser traduzida (interna-

tionalization) de forma independente da sua logica implementacao ou apre-

sentacao Este grau de separacao resulta em aplicacoes que sao mais faceis de

manter pelos programadores e facilmente adaptadas por designers e tradutores

24

Estado da arte

Facil adaptacao Outro benefıcio que advem do nıvel de separacao entre logica

de negocio e apresentacao oferecido pelo XUL e a facilidade com que se pode

adaptar uma aplicacao para diferentes clientes ou grupos de utilizadores Um

programador pode utilizar a mesma aplicacao base e adapta-la consoante as

necessidades atraves de diferentes temas (skins) e ficheiros de lınguas Desta

forma uma aplicacao escrita e desenvolvida em Ingles pode ser rapidamente

traduzida para Portugues e distribuıda com outra aparencia mais apropriada

ao cliente alvo

332 Prism

O Mozilla Prism e um browser simplificado e ldquointerpretadorrdquo de XUL (tambem

designado por XULRunner) que acolhe web applications sem a interface grafica ha-

bitual de um browser Baseia-se num conceito designado por Site Specific Browser

(SSB) Um SSB e uma aplicacao com um browser embebido desenhado para exe-

cutar apenas uma web application Nao possui os menus e barras de ferramentas

habituais Um SSB tem uma integracao com o sistema operativo e com o desktop

muito mais estreita do que uma web application acedida atraves de um browser uma

vez que e executado em janela propria

O Prism resulta de uma experiencia da Mozilla e visa reduzir as diferencas entre

as desktop applications tradicionais e as web applications Um dos aspectos focados e

a experiencia do utilizador Numa apresentacao oficial e dito que ldquo[o Prism] pretende

ser uma ponte entre as diferencas que existem entre as aplicacoes tradicionais de

desktop e as web applications explorando novos modelos de usabilidade enquanto

que a linha que as separa se continua a definirrdquo [Lab07]

34 HTML 5

A especificacao HTML 5 [Hic08] que se encontra em fase de desenvolvimento

pelo grupo WHATWG pretende ser uma norma de substituicao dos padroes HTML

4 XHTML 1x e do DOM2 HTML Uma das propriedades que o distingue das tec-

nologias que pretende substituir e precisamente o suporte para OWA e armazena-

mento de dados no cliente de uma forma relacional Nao sendo propriamente uma

tecnologia ndashmas antes uma especificacao ndashe aqui mencionada por ter servido como

referencia a diversas implementacoes de funcionalidades offline e por se considerar

que venha a ter um impacto significativo nas implementacoes de diversos browsers

Dion Almaer defendeu no seu blogue que o Gears era uma implementacao do

HTML 5 No seu artigo ldquoGears as a bleeding-edge HTML 5 implementationrdquo [Alm08]

o autor diz que ambos ndasho Gears e o HTML 5 ndashpretendem dar a web caracterısticas

25

Estado da arte

semelhantes e nao encontrar motivo de ldquocompeticaordquo entre as duas mas que en-

quanto o HTML 5 e uma especificacao o Gears e uma implementacao

No entanto tambem e verdade que o HTML 5 cobre muitos outros pontos para

alem das OWA que saem completamente fora do ambito do Gears Se esta es-

pecificacao atingir um estado de maturidade que possibilite a sua adopcao pelos

principais browsers tornando nativo do browser o suporte OWA entao deixara de

fazer sentido a existencia de uma extensao como o Gears

A especificacao HTML 5 disponibiliza duas APIs relevantes para o tema das

OWA

1 Uma base de dados baseada em SQL que permite o armazenamento de dados

do lado do cliente

2 Uma ldquocacherdquo HTTP que garante a disponibilidade das aplicacoes mesmo quando

o utilizador nao possui uma ligacao a Internet

Estas caracterısticas sao as bases da tecnologia das OWA e tem correspondencia

com os pontos analisados nas seccoes 311 e 311

35 Web applications que usam funcionalidades offline

Nesta seccao apresentam-se algumas web applications que actualmente disponi-

bilizam funcionalidades offline Estas aplicacoes foram escolhidas para uma analise

mais pormenorizada por utilizarem o Gears que tal como descrito na seccao 4 foi

a tecnologia escolhida para o projecto

351 Google Reader e Google Docs

O Google Reader7 e um leitor de feeds RSS Permite gerir a subscricao de varios

sites simultaneamente que disponibilizem conteudos neste formato e foi a primeira

web application da Google com uma versao offline publicamente acessıvel (desde

Junho de 2007)

O Google Reader implementa o modo ldquoutilizador deciderdquo oferecendo na sua

interface um botao que permite alternar entre os modos online e offline

O Google Docs8 e uma web application que permite a criacao e edicao de doc-

umentos de texto folhas de calculo e apresentacoes Era ja publico desde Janeiro

de 2008 que o Google estava a desenvolver uma versao OWA desta aplicacao mas o

acesso a uma versao experimental so foi possıvel a partir de 31 de Maio de 2008

7Google Reader - httpreadergooglecom8Google Docs - httpdocsgooglecom

26

Estado da arte

A implementacao das funcionalidades offline nestas duas aplicacoes seguiu difer-

entes aproximacoes principalmente porque o Google Reader apresenta ao utilizador

informacoes que sao fornecidas por fontes externas enquanto que no Google Docs

a informacao e criada e editada pelo utilizador sobre a forma de documentos

A diferente origem da informacao implica que no Google Reader seja necessario

prever casos de excepcao tal como existirem demasiados itens que necessitam de

ser transferidos para o cliente Nao observar este ponto causa um problema grave

de usabilidade e para evitar tempos de espera demasiado longos e uma interface

com pouca capacidade de resposta as accoes do utilizador o Google Reader apenas

transfere para o cliente os dois mil itens mais recentes na transicao para o modo

offline

352 Remember the Milk

O Remember The Milk9 e uma web application desenvolvida por uma equipa

Australiana que proporciona funcionalidades de agenda gestao de tempo e de tare-

fas e foi uma das primeiras aplicacoes independentes do Google a adoptar o Gears

para acessos em modo offline Permite que os seus utilizadores facam uma gestao

de tarefas agrupando-as em listas adicionando-lhes campos de informacao adicional

ou dando-lhes informacao geografica (recorrendo ao servico Google Maps10) Entre

a sua lista de funcionalidades encontra-se ainda a possibilidade de importar e ex-

portar eventos no formato iCalendar (ics) etiquetas (tags) em tarefas publicacao

Really Simple Syndication (RSS) e partilha de categorias de tarefas de acordo com

diferentes nıveis de permissoes de acesso definidos pelo utilizador

353 MySpace e WordPresscom

O MySpace uma das maiores social networks na Internet anunciou recente-

mente que vai disponibilizar uma versao do seu cliente de e-mail que utiliza o Gears

para acelerar o seu desempenho Numa fase inicial estara disponıvel apenas para

utilizadores que tenham cinco mil ou mais mensagens na sua caixa de correio e

permitira efectuar pesquisas muito mais rapido que a sua versao online

O servico de blogs Wordpresscom anunciou tambem o inıcio da utilizacao desta

tecnologia com o fim de melhorar o desempenho A versao que utiliza esta tecnologia

descarrega e armazena no cliente um conjunto de imagens e scripts que passam a

ter preferencia sobre os seus congeneres online e que permitem acelerar o processo

de carregamento da aplicacao e visualizacao de blogs

9Remember The Milk ndash httpwwwrememberthemilkcom10Google Maps ndash httpmapsgooglecom

27

Estado da arte

O MySpace e o Wordpresscom sao dois exemplos da utilizacao da tecnologia

OWA para optimizacao de web application ja existentes Sem pretenderem disponi-

bilizar uma versao que seja totalmente offline fazem uso do Gears para armazenar no

cliente parte dos recursos frequentemente acedidos na visualizacao das suas paginas

36 Escolha da tecnologia

Apos a analise das tecnologias apresentada nas seccoes 31 a 34 foi necessario es-

tudar a adequacao de cada uma delas ao projecto em questao Desde logo e possıvel

observar que nem todas se dedicam apenas a OWA Por exemplo o Adobe AIR

apesar de ter suporte para OWA apenas disponibiliza algumas das funcionalidades

identificadas como mais indicadas para a execucao do projecto quando utilizado

na sua vertente desktop tal como exposto na Tabela 31 mas a utilizacao desta

vertente implicaria o desenvolvimento de novas interfaces e de novas formas de co-

municacao (troca de mensagens XML ou JSON) A vertente web do Adobe AIR

foca-se mais especificamente nas Rich Internet Applications e permite a reutilizacao

do codigo ja existente (exigindo naturalmente a sua adaptacao e a implementacao

das funcionalidades pretendidas)

A tecnologia escolhida para a realizacao deste trabalho foi o Gears sendo que

um dos principais factores a influenciar esta opcao foi a liberdade introduzida pela

sua licenca Berkeley Software Distribution (BSD)11

Considerou-se o funcionamento desta ferramenta extremamente adequando a

aplicacao no WOW uma vez que o seu principal objectivo e precisamente tornar

possıvel a execucao offline de uma pagina web e por virtude deste facto o Gears tem

uma API concisa e de simples aplicacao pratica uma vez que nao possui quaisquer

outros elementos distractores O funcionamento do seu ManagedResourceStore ex-

emplificado na Figura 31 com a capacidade de actualizacao de recursos definidos

num ficheiro manifesto especificado em JSON pesou tambem nesta decisao

11Sobre a licenca BSD consultar httpwwwopensourceorglicensesbsd-licensephp e http

wwwlinfoorgbsdlicensehtml

28

Estado da arte

Figura 31 Esquema UML do processo efectuado pelos recursos do Gears do tipoManagedResourceStore para a actualizacao dos conteudos definidos no ficheiro manifesto

29

Estado da arte

Funcionalidade RIAs no browser RIAs no desktop

Disponibilidadeda aplicacao

As aplicacoes podem ser facil-mente exploradas e utilizadas

As aplicacoes quando instal-adas tem maior grau de fun-cionalidades e persistencia

Instalacao Nao e necessario qualquer tipode instalacao

As aplicacoes sao instaladasatraves do browser ou descar-regadas e instaladas comouma aplicacao tradicional

Actualizacoes Aplicacoes sao actualizadascarregando conteudos paraum website

O AIR disponibiliza uma APIque permite que as aplicacoessejam actualizadas de umaforma

Sistemas opera-tivos suportados

As aplicacoes podem ser exe-cutadas em diversos sistemasoperativos e browsers

As aplicacoes sao multi-plataforma e podem serinstaladas e executadas emdiversos sistemas operativos ebrowsers

Linguagens deprogramacao

Javascript e disponibilizadopelo browser e ActionScripte disponibilizado pelo AdobeFlash Player

Maquinas virtuais deJavascript e ActionScriptcompatıveis com o browser

Capacidade deexecucao embackground

As RIAs podem ser execu-tadas numa janela do browser

As aplicacoes podem ser ex-ecutadas em background edisponibilizar notificacoes talcomo uma aplicacao tradi-cional

Persistencia A actividade esta limitada asessao do browser Quando obrowser e encerrado toda ainformacao e descartada

As aplicacoes sao instaladas eestao disponıveis no desktopPodem armazenar informacaolocalmente e estao disponıveisoffline

Integracao com odesktop

Integracao com o desktop lim-itada devido a restricoes im-postas pelo browser

As aplicacoes podem acederao sistema de ficheiro ao clip-board eventos notificacoesetc

Controlo da inter-face com o uti-lizador

As aplicacoes sao acedidasatraves de uma janela dobrowser que tem os seusproprios controlos e visualgrafico

As aplicacoes tem um vi-sual grafico proprio em janelapropria

Armazenamentode dados

As aplicacoes tem armazena-mento limitado que pode serreescrito pelo browser

As aplicacoes tem acesso a to-talidade do espaco disponıvellocalmente e a uma base dedados com a possibilidade deencriptacao

Tabela 31 Comparacao das funcionalidades oferecidas pelo Adobe AIR para as platafor-mas web e desktop

30

Estado da arte

Aplicacao Modo de execucao utilizadoGoogle Reader Utiliza o modo ldquoutilizador deciderdquo disponibilizando

ao utilizador um botao para alternar entre os modosonline e offline Como lida com informacao recol-hida de fontes externas de natureza frequentementeefemera o processo de sincronizacao apenas transfereos dois mil itens mais recentes quando passa ao es-tado offline Neste modo sao ainda guardadas in-formacoes de itens lidos e etiquetas atribuıdas quesao sincronizadas com o servidor quando o utilizadorvoltar a activar estado online

Google Docs Utiliza o modo ldquoaplicacao deciderdquo permitindo que outilizador edite os conteudos de documentos de textofolhas de calculo e de apresentacoes independente-mente do estado da ligacao desde o momento em queas funcionalidades offline sao activadas A aplicacaofaz pequenas sincronizacoes com o servidor sempre quenecessario

Remember the Milk Utiliza um modo hıbrido entre ldquoaplicacao deciderdquo eldquoutilizador deciderdquo A aplicacao encarrega-se da sin-cronizacao de dados mas disponibiliza um controlona sua interface que permite despoletar manualmenteeste processo para situacoes em que o utilizador fez al-teracoes recentes e pretende usufruir das capacidadesoffline imediatamente

MySpace O MySpace anunciou a utilizacao de mecanismos dearmazenamento de dados no cliente com recurso atecnologias OWA para melhorar o desempenho doseu cliente web de correio electronico nomeadamenteno que diz respeito a operacoes de pesquisa e or-denacao Inicialmente esta funcionalidade estara ape-nas disponıvel para utilizadores com cinco mil ou maismensagens na sua caixa de correio mas nao e aindaclaro se sera disponibilizada uma versao totalmenteoffline

Tabela 32 Resumo da utilizacao de tecnologias OWA em algumas web applications con-sideradas na analise do estado da arte

31

Estado da arte

32

Capıtulo 4

Desenvolvimento

Neste capıtulo introduz-se a aplicacao WOW e apresenta-se o estudo que foi

feito da adequacao de cada tecnologia para a implementacao da funcionalidade of-

fline nesta plataforma Fazem-se diversas consideracoes sobre opcoes a tomar na

concepcao de OWAs e problemas comuns na sua implementacao bem como sug-

estoes para os resolver O WOW e uma aplicacao ja existente de gestao de ordens

de trabalho e do fluxo de tarefas numa empresa ou organizacao

41 Como ficar offline

Na maior parte das web applications de hoje nao existe uma camada de dados

real A aplicacao exemplificada na Figura 41 ao longo da sua execucao acede

directamente a sua unica fonte de dados (o servidor) atraves de chamadas Ajax sem

que exista uma separacao clara destas duas camadas

Para que uma web application seja capaz de ser executada sem uma ligacao

activa a Internet e mantenha o seu caracter dinamico torna-se necessario incluir

Figura 41 Exemplo de uma arquitectura de uma web application sem uma camada deabstraccao de dados Figura adaptada de http gears google com

33

Desenvolvimento

Figura 42 Exemplo de uma arquitectura de uma web application com uma camada deabstraccao de dados Figura adaptada de http gears google com

um mecanismo de armazenamento de dados local seja uma base de dados ou a

capacidade de acesso ao disco No entanto este mecanismo introduz dois problemas

1 Qual das fontes de dados utilizar quando um utilizador faz um pedido de

informacao

2 A necessidade de implementar uma camada de acesso a dados que seja coerente

quer se use o servidor remoto ou local

Por exemplo em vez de a aplicacao Ajax fazer um pedido relativo as contas de

todos os utilizadores em formato JSON directamente ao servidor remoto podera ao

inves fazer o pedido a um objecto intermedio da camada de dados Este objecto

demonstrado na Figura 42 sera responsavel por implementar uma interface de

acesso a base de dados e retornar um objecto JavaScript com uma representacao da

resposta do servidor

Mas a existencia de uma segunda fonte de dados torna recomendavel tambem

a implementacao de uma camada de data switching que em funcao da existencia

de conexao a Internet e da necessidade de actualizacao dos dados decide se faz o

pedido ao servidor remoto ou se fornece os dados presentes localmente Este objecto

apresentado na Figura 43 decidira de forma transparente para o utilizador se le ou

escreve os dados localmente ou se os enviapede ao servidor remoto e pode tambem

iniciar o processo de convergencia de dados e de resolucao de conflitos

411 Funcionalidades disponıveis em modo offline

Por razoes praticas e provavel que nem todas as funcionalidades da aplicacao

possam ser disponibilizadas em modo offline E necessario escolher quais as fun-

cionalidades a disponibilizar no modo offline da aplicacao e implementar a logica

que decide quando utilizar a base de dados local ou o servidor remoto Apesar do

acesso a base de dados local ser muito mais rapido do que aceder ao servidor o

acesso local nem sempre e preferido Ha varias razoes que podem tornar necessario

escolher o acesso ao servidor em vez do acesso local

34

Desenvolvimento

Figura 43 Exemplo de uma arquitectura de uma web application com uma camada deabstraccao de dados e um data switch Figura adaptada de http gears google com

1 A informacao pode ter uma natureza efemera e nao fazer sentido guarda-la

localmente Exemplo dados em tempo real da bolsa de valores de Lisboa

2 Algumas aplicacoes lidam com informacao que so faz sentido na presenca de

uma ligacao Exemplo Instant Messaging

3 A aplicacao podera escolher apenas guardar a informacao acedida mais fre-

quentemente Exemplo para o utilizador poder alterar a lıngua de apre-

sentacao da aplicacao os conteudos terao que ser guardados em todas as

lınguas disponibilizadas pela aplicacao O custo de implementacao de algu-

mas funcionalidades pode nao compensar o benefıcio

4 A capacidade de processamento ou de armazenamento de dados pode inviabi-

lizar algumas funcionalidades offline Exemplo se uma dada funcionalidade

necessita de uma capacidade de armazenamento de dados para alem do razoavel

de um computador pessoal para ser util (visualizador de mapas)

42 Modos de execucao

Um aspecto que e necessario estudar para qualquer web application que se deseje

disponibilizar offline prende-se com tres modos de execucao que devem ser consid-

erados

1 Utilizador decide o modo de execucao A aplicacao tem modos distintos

de execucao para os estados online e offline geralmente indicados na interface

com o utilizador O utilizador e informado do estado da ligacao e participa na

alteracao de estado de execucao da aplicacao interagindo com a sua interface

2 Aplicacao decide o modo de execucao Pode ser implementado na propria

aplicacao um mecanismo de deteccao do estado da ligacao (por exemplo atraves

35

Desenvolvimento

de chamadas Ajax periodicas) transitando de estado e sincronizando automati-

camente Desta forma o utilizador nao precisa de participar na alteracao de

estado a menos que exista um conflito de dados que requeira a sua atencao

3 Aplicacao assume sempre o estado offline Outra hipotese sera imple-

mentar uma web application que assume sempre estar na ausencia de uma

ligacao ao servidor de dados Esta aplicacao responde aos pedidos do uti-

lizador efectuando pedidos de informacao ao servidor mas nao dependendo

de uma resposta valida para mostrar a informacao que ja tinha disponıvel an-

teriormente A sincronizacao de dados com o servidor e tentada sempre que

existam dados para submeter e uma accao do utilizador

421 Modo ldquoutilizador deciderdquo

Neste modo de execucao quando a aplicacao esta online comunica com o servidor

remoto quando esta offline comunica com a base de dados local A informacao tem

que ser sincronizada sempre que se muda de modo A principal vantagem desta opcao

e que e a mais simples de implementar mesmo para uma aplicacao ja existente e

portanto uma forma expedita de disponibilizar uma OWA No entanto tem tambem

algumas desvantagens que devem ser consideradas

1 O utilizador tem que se lembrar de fazer a alteracao de estado de execucao

Caso contrario podera estar a trabalhar inadvertidamente numa versao offline

com dados antigos ou nao ter a informacao necessaria se perder subitamente

a ligacao

2 Se a ligacao for intermitente o utilizador tera ou que escolher um dos modos

de execucao ou estar constantemente a trocar

3 Uma vez que a base de dados nao esta sempre actualizada nao podera ser

utilizada para melhorar a rapidez de execucao da aplicacao quando em modo

online

422 Modo aplicacao decide

A deteccao do estado da ligacao pode ser implementada atraves de um pedido

assıncrono ao servidor tal como ilustrado na Figura 44 O resultado deste pedido

definira o estado online (em caso de sucesso) ou offline (em caso de falha) A

sincronizacao de dados podera ser feita sempre que ocorra uma transicao do es-

tado offline para o estado online No entanto este metodo nao se revela eficiente

36

Desenvolvimento

Figura 44 Esquema grafico ilustrando uma OWA executando no browser utilizando ummodo de execucao do tipo ldquoaplicacao deciderdquo com deteccao automatica do estado daligacao via pedidos Ajax assıncronos a cada cinco segundos

para grandes aplicacoes uma vez que requer a troca de mensagens demasiado fre-

quentes com o servidor que se destinam exclusivamente a monitorizacao do estado

da ligacao

423 Modo ldquoaplicacao assume o estado offlinerdquo

Uma aplicacao transparente funciona assumindo sempre que esta em modo of-

fline ou pelo menos que pode perder a ligacao a qualquer momento Neste modo

tira-se o maximo partido do armazenamento local e fazem-se pequenas mas contınuas

sincronizacoes com o servidor sempre que este esteja disponıvel A sincronizacao de

dados tambem e feita sempre que se volta ao estado online

As vantagens de uma web application transparente sao as seguintes

bull Uma melhor experiencia para o utilizador uma vez que este nao tem que se

preocupar com o estado da ligacao ou com a transicao de estados

bull A aplicacao funciona de forma coerente mesmo que a ligacao seja intermitente

bull Uma vez que o armazenamento local e mantido actualizado pode ser utilizado

para melhorar o desempenho da aplicacao

Foram identificadas as seguintes desvantagens

bull E mais difıcil de implementar e a sincronizacao acarreta cuidados especiais

bull E necessario um cuidado adicional para evitar que as operacoes de sincronizacao

frequentes que ocorrem automaticamente nao afectem os tempos de resposta

da aplicacao

bull Os testes a aplicacao sao mais complexos uma vez que a sincronizacao de dados

nao ocorre em resposta a uma accao do utilizador

37

Desenvolvimento

43 Sincronizacao de dados

A sincronizacao de dados consiste na capacidade de identificar e transferir pe-

riodicamente a versao mais actual dos dados entre o cliente e o(s) servidor(es)

Independentemente do modo de execucao escolhido e mesmo do estado da ligacao

do utilizador a informacao armazenada localmente e a informacao armazenada no

servidor estarao por vezes dessincronizadas Isto podera acontecer sempre que por

exemplo

bull O utilizador faz alteracoes em modo offline

bull A informacao e partilhada e pode ser alterada por uma entidade externa

bull A informacao e fornecida por uma entidade externa

Resolver estas diferencas de forma a que a informacao local e remota encontrem

a igualdade chama-se sincronizacao de dados Ha varias aproximacoes possıveis

para este efeito que dependem da natureza da aplicacao cada uma com vantagens

e desvantagens

A capacidade de suportar a mobilidade dos utilizadores torna-se cada vez um

ponto mais importante de uma web application Para uma organizacao de dimensao

global e vital garantir que os seus colaboradores tem acesso a mesma informacao

que tem disponıvel nos seus postos de trabalho mesmo quando estao fora Na maior

parte dos casos estes colaboradores terao acesso a um computador portatil um

desktop Smartphone ou PDA e atraves destes poderao ter acesso a sua informacao

directamente atraves de ligacoes encriptadas Virtual Private Network (VPN) de um

servidor web ou de outro mecanismo de rede

Esta solucao e simples de implementar mas infelizmente para a maioria dos

colaboradores com grande factor de mobilidade nao e satisfatoria As principais

desvantagens sao as seguintes

bull Requisitos de ligacao Para permitir que os utilizadores acedam a sua in-

formacao e necessario garantir a capacidade constante de comunicacao pelo

menos durante o tempo necessario que assegure a sua transferencia

bull Velocidade de ligacao sem persistencia de dados e em ligacoes de fraca

qualidade a usabilidade por vezes torna-se inaceitavel

bull Ponto crıtico de falha Com este tipo de solucao todos os utilizadores de-

pendem da base de dados que armazena informacao vital para o funcionamento

do cliente

38

Desenvolvimento

bull Scalability do servidor A medida que novos utilizadores sao adicionados ao

sistema o desempenho do servidor e afectado levando a necessidade de maior

capacidade de armazenamento eou processamento

De acordo com a documentacao da Microsoft Sync Framework [Mic08] uma

solucao alternativa consiste em implementar uma Occasionally Connected Appli-

cation (OCA) Uma OCA permite a um utilizador remoto continuar a aceder a

sua informacao mesmo depois de perder a ligacao mas em vez de recorrer a um

servidor recorre a informacao armazenada no seu dispositivo local Para preencher

localmente a informacao que o utilizador necessita uma OCA possui mecanismos

de sincronizacao de dados que sao oferecidos por esta framework

431 Quando sincronizar

Uma das solucoes mais simples de implementar passa por disponibilizar um

mecanismo manual que despoleta a sincronizacao Diz-se manual porque e o uti-

lizador que escolhe quando sincronizar e pode ser implementada simplesmente

fazendo o upload de toda a informacao para o servidor e depois fazendo o download

da copia mais recente da informacao antes de voltar a ficar offline Para que esta

seja uma opcao viavel e necessario que

bull O volume de dados seja suficientemente pequeno para que possa ser transferido

do servidor para o cliente num espaco de tempo aceitavel

bull Que o utilizador indique explicitamente que quer mudar para o estado offline

ou online pressionando um botao da interface

Contudo podem ser identificados alguns problemas relacionados com esta abor-

dagem

bull Os utilizadores nem sempre podem prever o estado das suas ligacoes A ligacao

pode-se perder subitamente ou ter um caracter intermitente

bull O utilizador pode esquecer-se de efectuar a sincronizacao

Outra opcao sera conjugar a sincronizacao de dados com o modo de execucao

transparente A sincronizacao ocorre automaticamente em background de forma

nao intrusiva para o utilizador A aplicacao comunica com o servidor regularmente

efectuando pequenas trocas de dados com o objectivo de manter o sincronismo da

informacao local e remota Esta abordagem pode ser implementada com pedidos

Ajax assıncronos e regulares ao servidor o que permite manter a interaccao com a

interface fluıda evitando bloqueios Estes pedidos sao feitos prevendo as situacoes

39

Desenvolvimento

de disponibilidade ou indisponibilidade (timeout) do servidor Uma outra opcao

sera permitir que o servidor comunique essas alteracoes utilizando Comet1 tal como

descrito em [Wil06] e [Rus06] As vantagens destas aproximacoes sao

bull A informacao esta disponıvel a qualquer altura que o utilizador decida ficar

offline ou que a ligacao seja acidentalmente perdida

bull O desempenho da aplicacao pode ser melhorado quando se estiver a utilizar

uma ligacao a Internet lenta uma vez que o acesso a dados locais e mais

eficiente do que a consulta de dados ao servidor

44 WOW

O WOW e uma plataforma integrada de gestao de ordens de trabalho ja ex-

istente e desenvolvida pela Critical Software SA a qual se pretende adicionar a

capacidade de execucao offline Esta aplicacao e extremamente dinamica e con-

figuravel com um conjunto extremamente rico de funcionalidades das quais se

destacam

bull Gestao de Ordens de Trabalho ndash suportando a gestao dos pedidos desde a

sua criacao ate ao seu fecho tomando em conta os diferentes tipos de pedidos

(ordens de trabalho pedidos de informacao melhorias resolucao de problemas

etc) e diferentes tipos de accoes possıveis para cada um (Figura 45)

bull Monitorizacao de alteracoes ndash Historico de mudancas anexos e estados criando

relatorios de alteracao automaticamente (o que por quem e quando)

bull Uso de Service Level Agreements (SLAs) ndash E possıvel associar a um pedido um

SLA que define qual o perıodo de tempo atribuıdo a resolucao de um pedido

controlando e agilizando a resolucao do mesmo

bull Utilizacao de queries de utilizador configuraveis que permitem acesso rapido

a determinadas ordens de trabalho de acordo com o filtro configurado (por

exemplo ldquoPara mimrdquo ldquoPara o Grupordquo ldquoPelo Grupordquo)

bull Gestao do relacionamento entre pedidos

bull Pesquisa e filtragem de ordens de trabalho

bull Exportacao de dados em formatos padrao (PDF DOC ou XLS)

bull Integravel com solucoes externas

40

Desenvolvimento

Figura 45 Detalhe de um conjunto possıvel de estados e respectivas transicoes para umadada ordem de trabalho no WOW desde a sua submissao no sistema ate a sua conclusaoem fecho ou cancelamento Esta figura representa apenas um exemplo ja que o mapa deestados para uma ordem de trabalho e dinamico e pode ser alterado por um administradorFigura retirada de uma brochura promocional do WOW Critical Software SA

A utilizacao de uma ferramenta deste tipo por parte de uma empresa ou orga-

nizacao oferece vantagens quer a gestao de topo quer aos colaboradores individuais

para os colaboradores individuais o WOW e uma aplicacao onde estao registadas

todas as tarefas contribuindo activamente para o desenvolvimento em ambientes

multi-tarefa e para a organizacao pessoal das tarefas de acordo com prioridades

Para a gestao de topo esta ferramenta permite obter uma visao global do estado da

organizacao em termos de tempo gasto por tarefa executada sendo uma mais valia

para a previsao e gestaoalocacao de recursos

45 Visao geral sobre a arquitectura do WOW

O WOW e interessante nao so do ponto de vista de produto como tambem do

ponto de vista de plataforma Existem diversos plug-ins que estendem as funcional-

idades do WOW e existem ate projectos que pretendem usar a arquitectura do

WOW para criar produtos com fins diferentes do inicial (por exemplo o WOW-

Storm ndash um sistema de registo e classificacao social de ideias)

De modo a conseguir ter essa expansibilidade a plataforma WOW assenta sob

uma arquitectura distribuıda modular e expansıvel com uma componente central

ndash o core ndash estruturado em camadas logicas E no core que se situam todas as

1O Comet e um conceito semelhante ao Ajax introduzido por Alex Russel mas no qual e o servidor quetoma a iniciativa de ldquoenviarrdquo os dados ao browser sem que este tenha que efectuar um pedido Tambem econhecido por Ajax Push Reverse Ajax ou HTTP Streaming

41

Desenvolvimento

funcionalidades base da aplicacao quer a nıvel logico funcional e de apresentacao

quer a nıvel de gestao e configuracao

E possıvel a execucao de varias instancias do core simultaneamente em servidores

distintos o que permite a alta escalabilidade e disponibilidade desta aplicacao A

consistencia dos dados fica sempre garantida atraves da partilha da base de dados

e pelo balanceamento dos pedidos uma vez que cada um e encaminhado para uma

unica instancia

O WOW apresenta tambem a vantagem de ser uma plataforma extensıvel E

possıvel adicionar novas caracterısticas a plataforma atraves de componentes que se

podem ser divididos em duas categorias plugins e connectors

Os plugins sao componentes que se encontram no mesmo no fısico que a aplicacao

partilhando do mesmo contexto de execucao do core Sao assim uma forma mais

directa de obter informacao da plataforma visto que nao possuem restricoes de

acesso aos dados nem dependencias externas A arquitectura deste componente tera

assim que permitir varias execucoes instanciadas cada uma associada a um core

Por outro lado os connectors sao componentes que se encontram distribuıdos

comunicando externamente com o core Quer a sua execucao quer a obtencao

dos dados estao assim dependentes de interfaces de comunicacao externas que a

plataforma disponibiliza Estes componentes ao contrario dos plugins sao instan-

ciados unicamente e recorrem ao protocolo de comunicacao Java Messaging Service

(JMS) para comunicar com o core

46 WOW Offline

Para alem das opcoes tomadas relativamente a tecnologia a utilizar surgiu

tambem a necessidade de optar por um dos modos de execucao apresentados na

seccao 42

Das tres opcoes possıveis foi o modo ldquoaplicacao assume o estado offlinerdquo descrito

na seccao 423 que mereceu a maior atencao uma vez que reune as vantagens de

uma experiencia mais positiva para o utilizador (uma vez que este nao tem que

participar activamente na alteracao do modo execucao como descrito na seccao 421)

e nao constitui uma sobrecarga excessiva para servidor (como o modo abordado na

seccao 422)

No entanto esta opcao comprometia a complexidade da implementacao para alem

dos objectivos propostos para este projecto e para cumprir o prazo dado foi tomada

a decisao de implementar o modo ldquoutilizador deciderdquo especificando apenas de forma

teorica o modo ldquoaplicacao assume o estado offlinerdquo

As caracterısticas do Gears foram ja descritas na seccao 31 Na Figura 47

mostra-se a sua forma de funcionamento quando integrado numa web application

42

Desenvolvimento

Nesta figura representa-se o modulo LocalServer do Gears como um ponto de de-

cisao Aqui sao testadas as condicoes que determinam se o pedido sera interceptado e

servido localmente ou se prossegue para uma maquina remota E tambem represen-

tada uma base de dados que corresponde ao modulo Database mas que podera nao

ser utilizada Este modulo tal como o modulo Workerpool tem caracter opcional

e sao utilizados consoante os requisitos da aplicacao

A plataforma WOW lida com mais dados do que e necessario passar para o

lado do cliente Em conformidade com o ja exposto na seccao 411 volta-se a

frisar que nao se pretende recriar toda a logica de negocio nem os conteudos da

base de dados no cliente pela sua complexidade e volume de dados Pretende-se

pelo contrario permitir que os utilizadores tirem partido da capacidade de poder

consultar as suas ordens de trabalho quando nao dispoe de uma ligacao transferindo

apenas o essencial para isto seja possıvel

A pagina inicial do WOW apresenta um resumo das ordens de trabalho abertas

ndash enviadas e recebidas ndash que se pretende permitir visualizar offline (ver Figura 46)

Como prova de conceito foi efectuada uma abordagem pragmatica das varias possi-

bilidades descritas na seccao 42

461 Modo ldquoaplicacao deciderdquo com deteccao automatica da ligacao

A primeira abordagem estudada para a disponibilizacao das funcionalidades of-

fline foi o modo ldquoaplicacao deciderdquo com deteccao automatica de ligacao apresentado

na seccao 422 Para que isto seja possıvel foi implementado um mecanismo de ver-

ificacao periodica do estado da ligacao atraves de chamadas Ajax assıncronas O

resultado destes pedidos determina o estado da aplicacao executando as tarefas de

sincronizacao de dados sempre que pertinente Este metodo embora imediato e

simples de implementar depressa se revelou inadequado para o projecto devido ao

elevado consumo de recursos do servidor que a utilizacao intensiva faz esperar a

comunidade da plataforma WOW no principal cliente excede os 7000 utilizadores

Foi estimado que para uma utilizacao de fluidez aceitavel o estado da ligacao deveria

ser testado a cada cinco segundos Assumindo uma adesao (previsao pessimista) de

1 aos servicos offline assistir-se-ia a cerca de 840 pedidos adicionais por minuto

Mas o principal problema desta aproximacao prende-se com o facto de a ver-

ificacao ser feita em intervalos de tempo discretos levando a possibilidade de a

aplicacao poder ter em dado momento uma representacao errada do seu estado

real da ligacao Este problema e ilustrado na Figura 48 onde se ve claramente a

discrepancia entre o estado real da ligacao e a representacao interna que esta tem

Note-se que nesta janela de tempo qualquer accao do utilizador que exija uma

resposta sıncrona do utilizador leva-lo-a para um ldquobeco sem saıdardquo onde nao tera

43

Desenvolvimento

Figura 46 A pagina inicial do WOW apresenta um resumo das ultimas ordens de trabalhoenviadas e recebidas Na imagem pode-se observar a transicao do estado online para offline

acesso a versao offline porque a aplicacao nao fez a transicao automatica nem acesso

a versao online porque na verdade nao possui uma ligacao O que acontecera nesta

situacao sera uma tentativa de acesso ao servidor por parte da aplicacao numa

altura em que este se encontra indisponıvel e o resultado sera uma mensagem de

ldquopedido excedeu o tempordquo apresentado pelo browser Este e um estado sem retorno

porque apos o browser apresentar esta mensagem todos os recursos JavaScript ficam

indisponıveis tornando impossıvel o regresso ao estado anterior ou o tratamento do

erro de qualquer outra forma No entanto as chamadas Ajax podem ser tratadas de

forma especial para a eventualidade de falha e portanto nao constituem problema

44

Desenvolvimento

Figura 47 Ilustracao do funcionamento do Gears numa web application que utiliza ummotor Ajax Os pedidos HTTP ou HTTPS podem ser interceptados e tratados localmenteou podem ser feitos a uma maquina remota consoante se verificarem ou nao as condicoesexpressas no ponto 311 E representado um acesso a uma base de dados local (fornecidapelo Gears) mas a sua utilizacao e opcional

462 Implementacao do modo ldquoutilizador deciderdquo

Este modo de execucao foi ja descrito na seccao 421 e a sua principal carac-

terıstica e ser o utilizador a decidir se a aplicacao deve utilizar um servidor remoto

ou a maquina local como fornecedor de dados

Relativamente ao WOW o WOW Offline na vertente ldquoutilizador deciderdquo vem

alterar os seus casos de uso dando ao utilizador a possibilidade de alterar o estado

de execucao da aplicacao (entre online e offline) Resta dizer que no modo online se

mantem todas as funcionalidades anteriores e que no modo offline torna-se possıvel

visualizar os conteudos da pagina principal do WOW (Figura 46) e os detalhes das

ordens de trabalho (Figura 49) tal como expressa a Figura 410

Esta aproximacao foi utilizada na prova de conceito do WOW adicionando um

controlo a interface desta aplicacao que permite ao utilizador alternar entre os esta-

dos online e offline Na transicao de online para offline sao descarregados os recursos

necessarios para a execucao desta aplicacao sem recorrer a Internet Para o fazer

45

Desenvolvimento

Figura 48 Neste exemplo do modo ldquoaplicacao deciderdquo o teste da ligacao e feito e feito acada cinco segundos O resultado deste teste nao reflecte sempre o estado real da aplicacaopodendo levar a aplicacao a ter comportamentos indesejaveis Na figura assinala-se umperıodo de tempo no qual a representacao interna do estado da ligacao nao corresponde arealidade

e utilizado um recurso ResourceStore e um ManagedResourceStore (introduzidos

em 311) O primeiro e utilizado para armazenar a pagina principal do WOW ndash do-

ravante designada por homejsp ndash e o segundo e utilizado para armazenar imagens

folhas de estilo CSS e scripts JavaScript

Para a implementacao deste modo de execucao foram identificadas as seguintes

tarefas

1 Guardar informacao que permita a recriacao das paginas que se pretende

disponibilizar offline (utilizando o Gears)

2 Disponibilizar um controlo que permita alterar o estado de execucao atraves

da interaccao com a pagina principal

3 Durante a sincronizacao de dados apresentar o progresso da transferencia de

dados

O primeiro passo consistiu na identificacao de todos os conteudos que sao necessarios

transferir para a execucao offline Foi utilizado um recurso do Gears do tipo

ManagedResourceStore que recorre a um ficheiro manifesto para identificar to-

dos os ficheiros que deve transferir Este recurso e gerido automaticamente pelo

Gears transferindo para o cliente a versao mais recente sempre que e necessario

isto e sempre que exista um ficheiro manifesto com uma identificacao de versao que

seja diferente da actualmente disponıvel no cliente Uma vez identificados todos

ficheiros necessarios para a execucao offline num (ou mais) ficheiros manifesto o

Gears encarrega-se da sua actualizacao mas o preenchimento destes ficheiros man-

ifesto e manual o que se traduz num cuidado extra na manutencao da aplicacao

A forma como esta informacao e guardada deve tambem ser cuidadosamente

estudada A opcao mais flexıvel passa por utilizar o modulo Database apresentado

na seccao 311 e guardar a informacao de uma forma relacional Para a recriacao

das paginas pode ser disponibilizada uma versao HTML da pagina que funciona

46

Desenvolvimento

Figura 49 Pagina de visualizacao do detalhe de uma ordem de trabalho

como template nao possui quaisquer dados e e utilizada apenas em modo offline E

preenchida para cada pedido retirando os dados relevantes da base de dados

O modelo de dados do WOW torna esta opcao extremamente trabalhosa uma

vez que as entidades envolvidas na geracao de cada pagina de informacao sobre

cada ordem de trabalho tem relacoes de dependencia complexas seguindo padroes

muito variaveis Por exemplo em cada ordem de trabalho existe um formulario que

permite a sua progressao de estado com diversos campos opcionais e obrigatorios

este formulario e definido pelo administrador e esta relacionado nao apenas com o

tipo de ordem de trabalho mas tambem com o estado actual em que esta se encontra

e a accao que se pretende realizar O elevado numero de combinacoes de tipos de

ordem de trabalho estados e accoes que existem num dado momento juntamente

com a sua possibilidade de alteracao obrigariam a implementacao de uma logica de

negocio complexa o que esta fora do ambito deste projecto

47

Desenvolvimento

Figura 410 Esquema UML que expressa os casos de uso do WOW Offline no modoldquoutilizador deciderdquo

463 Especificacao do modo ldquoaplicacao assume o estado offlinerdquo

A aproximacao para o modo ldquoaplicacao assume o estado offlinerdquo foi tambem

dividida em varias tarefas

1 Guardar informacao que permita a recriacao da pagina principal do lado do

cliente no estado offline (utilizando o Gears)

2 Dotar a aplicacao do cliente de um mecanismo de deteccao da ligacao

3 Identificar os ldquomomentos chaverdquo em que devera ocorrer sincronizacao de dados

4 Implementar a sincronizacao de dados

A sincronizacao de dados deve ser feita em ambas as transicoes online-offline e

offline-online quer para transferir novos dados do servidor (os pedidos podem ser

alterados por outros utilizadores) quando se transita do estado quer para comunicar

eventuais alteracoes feitas em modo offline

Relativamente ao WOW o WOW Offline na vertente ldquoaplicacao assume o es-

tado offlinerdquo vem alterar os seus casos de uso dando ao utilizador a possibilidade

de activar esta funcionalidade A partir do momento que a funcionalidade esta ac-

tivada o utilizador deve tambem ter a possibilidade de gerir algumas preferencias

relacionadas com privacidade de dados Devera ter a hipotese de desactivar o ar-

mazenamento local e de remover todos os dados ja armazenados tal como descrito

na Figura 411

48

Desenvolvimento

Figura 411 Esquema UML que expressa os casos de uso do WOW Offline no modoldquoutilizador deciderdquo

A primeira vez que o WOW Offline e acedido por um cliente e caso seja detec-

tada a presenca do Gears todos os recursos necessarios a sua execucao sao trans-

feridos Todos os acessos posteriores serao feitos a estes recursos locais (recorda-se

que o Gears pode ser utilizado para os manter actualizados recorrendo ao Managed-

ResourceStore 311)

Atraves do JavaScript e possıvel interceptar os eventos de load e unload da

pagina que sao despoletados sempre que ocorre um re-acesso da mesma (incluindo

a accao refresh comum dos browsers) sempre que esta e abandonada ou ainda ou

ainda se a janela for encerrada

Tal como sugerido na seccao 462 a camada de interface desta aplicacao (cada

pagina individual em HTML) devera ser implementada como sendo um template

para apresentacao de dados sendo totalmente preenchida atraves de funcoes em

JavaScript O objectivo deste ponto e criar um padrao de dados que permita ao

JavaScript preencher os dados em cada pagina (template) independentemente de

qual seja a fonte ndash o servidor remoto ou a maquina local tal como exemplificado

no diagrama da Figura 412 Na figura a aplicacao recorre ao servidor remoto para

obter os dados pretendidos quando se encontra na presenca de uma ligacao mas

para dados que exijam uma carga de processamento pelo servidor este acto pode ser

49

Desenvolvimento

Figura 412 Esquema UML que expressa o acto de recolha de dados em modo online eoffline recorrendo ao servidor (modo online) e ao sistema de armazenamento de dadoslocal fornecido pelo Gears (modo offline)

substituıdo pelo envio de um campo de controlo que se destina a aferir se os dados

locais se encontram actualizados No caso de estarem actualizados a comunicacao

com o servidor pode ser substituıda por uma query a base de dados local

50

Capıtulo 5

Resultados e Futuros

Desenvolvimentos

Todo o estudo feito sobre o tema OWA foi ja abordado ao longo do documento

Neste capıtulo apresentam-se os resultados obtidos na implementacao da prova de

conceito que visava compreender a melhor forma de disponibilizar uma versao of-

fline no WOW uma plataforma de gestao de ordens de trabalho ja existente de-

senvolvida pela Critical Software SA

51 Resultados Obtidos

Os resultados obtidos neste projecto sao extremamente satisfatorios uma vez

que o estudo do tema OWA e a implementacao de uma prova de conceito que o

ilustrasse foi conseguido com sucesso

A funcionalidade offline foi adicionada ao produto WOW da Critical Software

SA permitindo a visualizacao de ordens de trabalho e dos seus detalhes mesmo na

ausencia de uma conexao activa a Internet Embora para a solucao implementada

tenha sido utilizada uma abordagem do tipo ldquoutilizador deciderdquo pretende-se que esta

seja convertida para ldquoaplicacao deciderdquo ou mesmo para uma aproximacao hıbrida

semelhante a utilizada pelas aplicacoes estudadas nas seccoes 351 e 352

Para a sua implementacao descrita no capıtulo 4 foram tomadas decisoes de or-

dem pratica que permitissem tornar o trabalho exequıvel nos prazos dados Tentou-

se sempre que estas decisoes afectassem o mınimo em termos de desempenho e de

experiencia para o utilizador Considera-se que a implementacao do modo offline

com uma transicao entre modos do tipo ldquoutilizador deciderdquo (ver seccao 42) reflecte

o compromisso entre o desempenho pretendido e os recursos disponıveis e para alem

51

Resultados e Futuros Desenvolvimentos

de ser um exemplo eficaz das possibilidades que as OWA podem trazer a aplicacao

WOW desenvolvida pela Critical Software e tambem um estudo que pode ser uti-

lizado para analisar a implementacao desta tecnologia noutros produtos da mesma

empresa

Note-se que o principal objectivo do trabalho era ganhar familiaridade com este

tema entender as suas vantagens e desvantagens e compreender as suas limitacoes

Tudo indica que existam varias possibilidades de implementacao deste paradigma

noutros produtos da Critical Software que pela sua natureza podem tambem tirar

partido da execucao offline

52 Trabalho Futuro

O desenvolvimento do conceito e formas de implementacao de OWA continua

em forte desenvolvimento no entanto a sua adopcao ainda nao e generalizada A

dificuldade da sua implementacao em web applications ja existentes e o principal

obstaculo a sua maior divulgacao

Ha tambem um factor que deve ser tido em consideracao a manutencao de

codigo A implementacao de uma versao offline de uma web application requer

a implementacao das mesmas regras de negocio (ou de uma versao simplificada)

utilizadas no servidor Para que isto seja possıvel e necessario ter em conta a

capacidade de processamento do cliente e o factor de duplicacao de codigo que

tornara a aplicacao mais difıcil de manter uma vez que uma alteracao a logica de

negocio do servidor implica tambem uma alteracao a sua versao offline

A prova de conceito implementada permite ja a visualizacao offline dos pedidos

abertos (enviados e recebidos) que constam na pagina principal (este numero e

fixo e pode ser alterado pelo administrador) Uma funcionalidade desejavel seria a

possibilidade de interaccao com a aplicacao em modo offline e sincronizacao com o

servidor quando existisse uma ligacao disponıvel

Foi estudada a utilizacao do modo de execucao ldquoaplicacao assume o estado of-

flinerdquo descrito em 423 e esta seria a forma desejavel para o WOW Offline no

entanto para que esta opcao seja viavel sera necessaria a implementacao de uma

forma eficiente de sincronizacao e armazenamento de dados de uma forma relacional

Para atingir este objectivo podera ser seguida uma polıtica de automacao do pro-

cesso no qual a versao online da aplicacao gera scripts de criacao para as tabelas

necessarias na base de dados da versao offline (nao existe nenhuma ferramenta para

o fazer portanto seria necessaria a sua implementacao) e no qual as paginas HTML

disponibilizadas pelo servidor aos clientes web (browser) servem como templates de

apresentacao de informacao e sao preenchidas de forma semelhante pelo servidor ndash

quando a aplicacao estiver online ndash ou pelo cliente atraves de funcoes em JavaScript

52

Resultados e Futuros Desenvolvimentos

ndash quando a aplicacao estiver offline No entanto no WOW devido a quantidade de

informacao tratada e devido as complexas relacoes entre as diferentes entidades e

de esperar que a complexidade da implementacao de um mecanismo deste tipo torne

esta aproximacao demasiado custosa

O HTML 5 embora um forte candidato ainda nao esta suficientemente desen-

volvido A sua especificacao ainda tem o caracter de Draft (rascunho) e esta sujeita

a modificacoes e a aceitacao e implementacao por parte dos browsers e portanto

de momento foi desconsiderado No entanto no futuro se esta especificacao atingir

um estado de maturidade que permita a sua adopcao devera ser considerada como

um possıvel caminho a seguir

53

Resultados e Futuros Desenvolvimentos

54

Capıtulo 6

Conclusoes

Neste capıtulo sao apresentadas as conclusoes do projecto e consideracoes finais

relativamente a tecnologia estudada

61 Conclusoes

O rapido desenvolvimento tecnologico faz prever que a disponibilidade de ligacao

a Internet seja cada vez mais facil e mais rapido mas vao continuar a existir lugares

onde o acesso e limitado e onde as OWA podem desempenhar um papel de relevo

Por outro lado esta tecnologia pode tambem ser utilizada para melhorar o desem-

penho de paginas web com uma necessidade elevada de imagens ou outros recursos

dispendiosos em termos de espaco e foram ate estudados dois exemplos da utilizacao

desta vertente desta tecnologia em 353

Acredita-se que as OWAs vem responder a uma necessidade real por parte das

web applications actuais e que a evolucao que representam se compara a que se

assistiu dos thin-clients para os fat-clients em termos de autonomia do servidor

A capacidade de oferecer conteudos dinamicos no browser independentemente da

existencia de uma ligacao reune as vantagens tıpicas das web applications como

ausencia de instalacao e actualizacoes instantaneas com as vantagens das aplicacoes

de desktop em capacidade de processamento e armazenamento de dados na maquina

local

As tecnologias disponıveis ate a data estudadas no ambito deste projecto que

permitem o desenvolvimento de OWAs e que apresentam maior maturidade sao o

Gears e o Adobe AIR Ambas se apresentam sobre a forma de plugins que necessitam

de uma instalacao extra para poderem ser utilizadas Apesar de esta instalacao ser

55

Conclusoes

apenas necessaria uma vez podera constituir um factor de desencorajamento a sua

adopcao

O HTML 5 uma especificacao abordada neste documento na seccao 34 podera

ser uma alternativa que oferece funcionalidades offline a uma web application sem a

necessidade de qualquer instalacao no entanto esta especificacao ainda nao foi aceite

pelos principais browsers ndash o documento que define o HTML 5 ainda tem o estatuto

de Draft ndash e ainda nao e possıvel antecipar quando e que isto podera acontecer

Um dos problemas que surge frequentemente na implementacao de uma versao

offline para uma web application e a necessidade de sincronizacao de dados Quando

a informacao pode ser alterada por varios utilizadores simultaneamente e necessario

prever os conflitos que daı podem surgir e dotar a aplicacao de uma forma de os

resolver ou alertar o utilizador para a necessidade de alteracao dos dados

Em conclusao todos os objectivos propostos para este projecto foram atingidos

A prova de conceito implementada reflecte de forma clara as possibilidades oferecidas

pela tecnologia OWA e sera utilizado no futuro para compreender a melhor forma

de o implementar de forma definitiva no WOW

56

Referencias

[Ada08] Lucas Adamski Introducing Adobe AIR security model Fevereiro de2008 Disponıvel em httpwwwadobecomdevnetairarticles

introduction_to_air_securityhtml acedido em Marco de 2008

[Ado08] Adobe Adobe AIR 10 Security White Paper 2008 Disponıvel emhttpdownloadmacromediacompubairdocumentation1air_

securitypdf acedido em Marco de 2008

[Alm08] Dion Almaer Gears as a bleeding-edge html 5 implementa-tion March 2008 Disponıvel em httpalmaercomblog

gears-as-a-bleeding-edge-html-5-implementation acedido emMarco de 2008

[BL96] Tim Berners-Lee The world wide web Past present and future Agostode 1996 Disponıvel em httpwwww3orgPeopleBerners-Lee

1996ppfhtml acedido em Abril de 2008

[CDGH08] Mike Chambers Daniel Dura Dragos Georgita and Kevin Hoyt AdobeAIR for JavaScript Developers OrsquoReilly Media 2008 Disponıvel emhttponairadobecomfilesAIRforJSDevPocketGuidepdf ace-dido em Abril de 2008

[Con99] Jim Conallen Modeling Web Application Architectures with UML Junho1999 Disponıvel em httpwwwumlorgcnUMLApplicationpdf

webappspdf acedido em Maio de 2008

[Ent07] Entrust What is a public key information 2007 Disponıvel em http

wwwentrustcompkihtm acedido em Junho de 2008

[Gar05] Jesse James Garret Ajax A new approach to web applicationsFebruary 2005 Disponıvel em httpwwwadaptivepathcomideas

essaysarchives000385php acedido em Marco de 2008

[Greon] Philip Greenspun Philip and Alexrsquos Guide to Web Publishing 2003(last revision) Disponıvel em httpphilipgreenspuncompandaacedido em Junho de 2008

[Gro02a] App Design Group Thick vs thin client comparison 2002 Disponıvelem httpwwwdonjacobsvwcomimagesweekendspecials

Thick-vs-Thinpdf acedido em Junho de 2008

57

REFERENCIAS

[Gro02b] Technical Research Group Thin Client Tecnhology - WhitePaper 2002 Disponıvel em httpwwwpicktrgcompubs

thinclientwhitepaperpdf acedido em Junho de 2008

[Gro08] Miniwatts Marketing Group World internet usage March 2008Disponıvel em httpwwwinternetworldstatscomstatshtm ace-dido em Abril de 2008

[Hic08] Ian Hickson HTML 5 Draft Recommendation 2008 Disponıvelem httpwwwwhatwgorgspecsweb-appscurrent-work ace-dido em Marco de 2008

[Kha] Olga Kharif Top 10 municipal wifi plans Disponıvel em http

imagesbusinessweekcomss0608muni_wifiindex_01htm ace-dido em Marco de 2008

[Lab07] Mozilla Labs Prism Outubro 2007 Disponıvel em httplabs

mozillacom200710prism acedido em Marco de 2008

[Loo06] Chris Loosley Rich Internet ApplicationsDesign MeasurementandManagement Challenges 2006 Disponıvel em httpwwwkeynote

comdocswhitepapersRichInternet_5pdf acedido em Maio de2008

[Mic08] Microsoft Introduction to Occasionally Connected Applications us-ing Sync Services for ADONET 2008 Disponıvel em httpmsdn

microsoftcomen-ussyncbb887608aspx acedido em Junho de2008

[Nao08] Erica Naone Offline web applications Abril 2008 Disponıvelem httpwwwtechnologyreviewcomread_articleaspxch=

specialsectionsampsc=emerging08ampid=20245 acedido emAbril de 2008

[NJN00] Jason Nieh Yang S Jae and Naomi Novik A comparison of thin-clientcomputing architectures 2000 Disponıvel em httpwwwnclcs

columbiaedupublicationscucs-022-00pdf acedido em Maio de2008

[OrsquoR06] Tim OrsquoReilly Web 20 compact definition Trying again Dezembro2006 Disponıvel em httpradaroreillycomarchives200612

web-20-compact-definition-tryihtml acedido em Marco de 2008

[OrsquoR09] Tim OrsquoReilly What is Web 20 Design patterns and business modelsfor the Next Generation of Software 20053009 Disponıvel emhttpwwworeillynetcompubaoreillytimnews200509

30what-is-web-20html acedido em Marco de 2008

[Rus06] Alex Russel Comet Low latency data for the browser March Marco2006 Disponıvel em httpalexdojotoolkitorgp=545 acedidoem Marco de 2008

58

REFERENCIAS

[Sad97] Darleen Sadoski Clientserver software architecturesndashan overviewAgosto 1997 Disponıvel em httpwwwseicmuedustr

descriptionsclientserver_bodyhtml acedido em Junho de2008

[Sch96] George Schussel Clientserver past present and future 1996

[Smi07] Kevin C Smith Css filters - will the browser apply the rule July 2007Disponıvel em httpcentriclecomrefcssfilters acedido emMarco de 2008

[vK08] Anne van Kesteren The XMLHttpRequest Object W3C Work-ing Draft 15 Abril 2008 Disponıvel em httpwwww3orgTR

XMLHttpRequest acedido em Abril de 2008

[Wil06] Greg Wilkins Why ajax comet July Julho 2006 Disponıvel emhttpwwwwebtidecomdownloadswhitePaperWhyAjaxhtml ace-dido em Abril de 2008

59

REFERENCIAS

60

Anexo A

Screenshots

Algumas imagens de aplicacoes que utilizam funcionalidades offline ilustrativasda tecnologia abordada neste documento

Figura A1 Dialogo apresentado ao utilizador na primeira activacao das funcionalidadesoffline no Google Docs amp Spreadsheets

61

Screenshots

Figura A2 Na activacao das funcionalidades offline e tambem oferecida a possibilidadeda criacao de alguns atalhos por exemplo no ambiente de trabalho

Figura A3 O Google Docs mantem a todo o momento a possibilidade de alteracao destasdefinicoes ou da anulacao dos servicos offline para um dado computador

62

Screenshots

Figura A4 Apos a instalacao do Gears qualquer visita ao Remember The Milk despoletauma sincronizacao que ocorre automaticamente e sem necessidade de intervencao por partedo utilizador

Figura A5 Apos completar a sincronizacao de dados mesmo que a ligacao a Internetseja perdida o Remember the Milk continua disponıvel no browser (com excepcao dasfuncionalidades que pela sua natureza exigem uma ligacao como por exemplo partilhade tarefas e envio de convites)

63

Page 16: O ine Web Applications

Glossario

fat-client Cliente que nao depende totalmente de umservidor central para as suas actividadesde processamento e possui frequentementedispositivos de armazenamento de dados

6ndash8

thin-client Cliente que depende de um servidor centralpara as suas actividades de processamento

5ndash8

web application Sistema web (servidor rede HTTPbrowser) onde accoes do utilizador(navegacao e introducao de informacao)afectam o estado logico da aplicacao

i iii1ndash311ndash1517ndash1921ndash232728 3336ndash3842 5556

API Application Programming Interface 10 1718 2326 28

ASP Linguagem interpretada pelo servidorque permite a criacao de paginas webdinamicas Desenvolvida pela Microsoft

11

BSD Berkeley Software Distribution 28

CSS Cascading Style Sheets 12 2021 2324 46

DHTML Dynamic HyperText Transfer Protocol 24DOM Document Object Model 10 12

20 2324

DTD Document Type Definition 24

xiii

Glossario

ECMAScript Padrao de linguagem de programacaodefinido pela Ecma International que orig-inou o JavaScript e o JScript

24

Flash Conteudo interactivo de um ficheiro emformato SWF E desenvolvido pela Adobee visualizado atraves do Adobe FlashPlayer

21

Flex Framework baseada em XML e Action-Script desenvolvida pela Adobe para a pro-gramacao de Rich Internet Applications(RIA)

21

GPL GNU General Public License 23

HTML HyperText Markup Language 1 10ndash12 2124ndash2649

HTTP HyperText Transfer Protocol 2 26

JMS E uma API em Java que permite a troca demensagens entre componentes de software

42

JSON JavaScript Object Notation permite atroca de dados codificados num formatode texto de simples leitura

12 1828 34

LGPL GNU Lesser General Public License 23

Mozilla Prism Browser simplificado e ldquointerpretadorrdquo deeXtensible User Interface Language (XUL)(tambem designado por XULRunner) queacolhe web applications sem a interfacegrafica habitual de um browser

25

MPL Mozilla Public License 23

OCA Occasionally Connected Application 39OWA Offline Web Application i iii

2ndash515 1725 2628 3133 3651 5255 56

PDF Portable Document Format 21

xiv

Glossario

PHP Linguagem interpretada pelo servidorque permite a criacao de paginas webdinamicas mas que pode tambem ser in-vocada a partir da linha de comandos

11

pagina web estatica Pagina web que devolve sempre a mesmaresposta a todos os pedidos para todos osutilizadores e em qualquer contexto

5 9

RIA Rich Internet Applications web appli-cations que apresentam funcionalidadessemelhantes as desktop applications masque mantem a informacao no lado do servi-dor

5 1520 28

RSS Really Simple Syndication 27

SLA Service Level Agreement 40SQLite Segundo a definicao oficial SQLite is a

software library that implements a self-contained serverless zero-configurationtransactional SQL database engine

17

SSB Site Specific Browser 25SSL Secure Sockets Layer 22SWF ShockWave Flash 21

URL Uniform Resource Locator 18

VPN Virtual Private Network 38

WOW Work Orders Web Plataforma de gestaode ordens de trabalho e do seu fluxo de-senvolvida pela Critical Software SA

i iii28 3340ndash434551ndash5356

WWW World Wide Web 11 1214

XBL eXtensible Binding Language 24XHTML eXtensible HyperText Markup Language 12XML eXtensible Markup Language 11 12

23 2428

XSLT eXtensible Stylesheet Language Transfor-mation

12

XUL eXtensible User Interface Language xiv23ndash25

xv

Glossario

xvi

Capıtulo 1

Introducao

Neste capıtulo enquadra-se o tema do projecto introduzindo alguns dos conceitos

nos quais se baseia Apresentam-se as motivacoes ambito objectivos e a estrutura

deste documento

11 Enquadramento

A Internet foi originalmente concebida para ser um espaco de partilha de in-

formacao onde pessoas (atraves de maquinas) pudessem comunicar Na sua origem

as paginas eram estaticas constituıdas por texto formatado em HyperText Markup

Language (HTML) e ligadas entre si [BL96] Hoje encontramos conteudos cada vez

mais complexos e dinamicos incluindo som vıdeo ou streams multimedia [Loo06] e

em 2005 foi introduzido por [OrsquoR09] o termo Web 20

De acordo com [Greon] um website pode pertencer a uma ou varias das seguintes

categorias

bull Documento ndash um website essencialmente estatico onde alteracoes a uma

parte do conteudo nao tem implicacoes no seu comportamento

bull Base de dados ndash um directorio de informacao organizada em categorias

bull Aplicacao ndash um website dinamico que utiliza uma linguagem executada ou

interpretada do lado do servidor e que processa as accoes ou informacao in-

troduzida pelo utilizador para fornecer um servico ou nova informacao

A ultima destas categorias constitui aquilo que e normalmente designado por

web application O conceito utilizado ao longo deste documento e o mesmo que

o introduzido por Jim Coallen em [Con99] que define web application como um

1

Introducao

sistema web (servidor rede HyperText Transfer Protocol (HTTP) browser) onde

accoes do utilizador (navegacao e introducao de informacao) afectam o estado logico

da aplicacao A sua definicao tenta estabelecer que uma web application e um

sistema de software com estado de negocio1 e que a sua interface de interaccao com

o utilizador e distribuıdo atraves de um sistema web

12 Motivacao

A quantidade de informacao que e produzida e armazenada com recurso a es-

tas web applications disponıveis online tais como e-mail blogues ou mesmo docu-

mentacao tornam por vezes a disponibilidade de ligacao uma condicao necessaria

a produtividade e como consequencia desta barreira muitos potenciais utilizadores

opoem-se a adopcao de produtos web em detrimento das tradicionais desktop appli-

cations

Assegurar o acesso a uma ligacao de Internet e hoje muito mais facil A Internet

movel e ja uma realidade e encontra-se amplamente divulgada mas continuam a

existir diversas situacoes nas quais os utilizadores estao privados de uma ligacao

a Internet tais como uma viagem de metro ou de aviao ou quando se encontram

deslocados do seu paıs de origem e nao possuem nenhum plano de subscricao

Uma OWA consiste numa web application que para alem de manter todas as

caracterısticas anteriores se mantem disponıvel mesmo na ausencia de uma ligacao

a Internet e surge como uma tentativa de estreitar as barreiras existentes entre a

web e o desktop Isto significa que devera existir um mecanismo capaz de assegurar

a manutencao do estado logico da aplicacao quando a ligacao com o servidor e

quebrada permitindo ao utilizador continuar a utilizar a aplicacao e que sera capaz

de informar o servidor do estado em que a aplicacao se encontra quando a ligacao for

reposta A principal vantagem que advem desta possibilidade e evidente eliminar

a necessidade da existencia de uma ligacao a Internet para que a aplicacao possa ser

utilizada

Por outro lado a vontade de integracao de funcionalidades tıpicas das desktop

applications nas web applications foi um dos principais factores que impulsionou o

desenvolvimento deste conceito uma vez que obrigou a uma reflexao ldquopara alem

do browserrdquo e a uma adaptacao das arquitecturas existentes que permitisse ou o

acesso a funcionalidades disponibilizadas pelo sistema operativo ou pelo menos a

funcionalidades semelhantes Pretende-se com esta aproximacao tornar possıveis

interaccoes entre o desktop e o browser tais como arrastar um ficheiro para um

formulario web de upload de conteudos melhor suporte para o historico do clipboard

ou ainda o acesso ao sistema de ficheiros local Atingir estes objectivos reflecte-se

1NT business state

2

Introducao

num novo paradigma que reune as vantagens das web applications tais como os

updates instantaneos ou o facto de nao ser necessaria nenhuma instalacao e das

desktop applications como por exemplo persistencia no armazenamento de dados

acesso a funcionalidades do sistema operativo ou integracao e interaccao com outras

aplicacoes sejam elas web applications ou desktop applications

13 Ambito

Este projecto foi realizado na Critical Software SA no ambito do Mestrado

Integrado em Engenharia Informatica e Computacao (MIEIC) da Faculdade de En-

genharia da Universidade do Porto (FEUP) entre os meses de Fevereiro e Julho de

2008

14 Objectivos

Sao objectivos deste projecto

1 Estudar e documentar o tema das OWAs acompanhando os ultimos desenvolvi-

mentos nesta materia

2 Analisar o estado da arte fazendo uma analise crıtica e objectiva sobre as

diversas metodologias existentes

3 Implementar uma prova de conceito que permita a execucao offline de uma

web application documentando todo o processo

4 Estudar a possibilidade de permitir interaccao com a aplicacao (insercoes e

alteracoes aos dados) em modo offline

Em resumo o objectivo deste projecto foi estudar documentar e implementar

uma prova de conceito relacionada com o tema Offline Web Applications (OWA)

Este tema embora nao seja totalmente novo ganhou destaque ao longo do ano de

2007 com o surgimento de diversas ferramentas que se destinam a aproximar web

applications das desktop applications

15 Estrutura do documento

Este documento esta organizado em diferentes seccoes apresentando o projecto

numa sequencia logica organizada da seguinte forma

No capıtulo 1 faz-se uma breve apresentacao do conceito OWAs e do contexto em

que surge Apresenta-se tambem a estrutura do documento e definem-se os

termos e acronimos utilizados

3

Introducao

No capıtulo 2 faz-se uma descricao da evolucao das tecnologias que antecedem as

OWAs e das vantagens e desvantagens de cada uma como forma de enquadra-

mento

No capıtulo 3 analisa-se o estado da arte nesta materia Introduzem-se diversas

tecnologias directamente relacionadas com o tema deste projecto exemplos de

aplicacoes que as usam e as razoes que fundamentam as escolhas de tecnologias

efectuadas

O capıtulo 4 contem o desenvolvimento do projecto Analisa-se a plataforma

WOW de gestao integrada de ordens de trabalho a tecnologia escolhida e

a forma como foi utilizada para implementar a capacidade de execucao offline

O capıtulo 5 descreve os resultado obtidos comparando-os com as expectativas

iniciais do projecto e apresenta desenvolvimentos futuros e possibilidades de

continuacaoaplicacao do conhecimento adquirido

No capıtulo 6 apresentam-se as conclusoes

4

Capıtulo 2

Enquadramento do Projecto

Neste capıtulo apresenta-se um breve resumo da evolucao das arquitecturas de

software cliente-servidor e a forma como estas se comparam a evolucao da Inter-

net procurando estabelecer uma analogia entre o percurso de ambas as tecnolo-

gias Compara-se o comportamento e arquitectura dos thin-clients as paginas web

estaticas a evolucao dos fat-clients as paginas interactivas Web 20 e Ajax e

defende-se que as OWA constituem um proximo passo logico e evolutivo aproxi-

mando a web do desktop Referem-se ainda os principais factores que justificam a

importancia das OWAs e a estreita relacao que tem com as Rich Internet Application

(RIA)s

21 Evolucao das arquitecturas de software

Os termos thin-client e fat-client sao utilizados quer para descrever arquitecturas

logicas (de software) quer para descrever arquitecturas fısicas (de hardware) Neste

capıtulo excepto quando seja dada indicacao em contrario estes termos referem-se

sempre a uma arquitectura logica

Adicionalmente quando se trata de arquitecturas cliente-servidor pode-se estu-

dar a arquitectura desenvolvida do sistema como um todo da arquitectura do servi-

dor ou da arquitectura do cliente Para evitar equıvocos em especial na seccao 213

especifica-se em cada caso qual o sistema estudado

211 Thin-clients

Um thin-client e um computador cliente ou software cliente que no contexto

de uma arquitectura cliente-servidor depende de um servidor central para as suas

5

Enquadramento do Projecto

actividades de processamento e proporciona um canal de entrada e saıda de in-

formacao entre o utilizador e o servidor remoto Este termo quando aplicado a

hardware refere-se habitualmente a um computador que se destina a ser utilizado

como cliente de rede sem armazenamento local e com capacidade de processamento

reduzida [Gro02b] mas o conceito que aqui se analisa refere-se a uma arquitectura

de software que remonta ao inıcio das aplicacoes cliente-servidor

No inıcio da historia da computacao terminais ligavam-se directamente a main-

frames responsaveis por todo o processamento Nesta arquitectura era necessario

desenvolver duas aplicacoes distintas uma aplicacao central no servidor (main-

frame) responsavel pela gestao de toda a informacao e por todas as operacoes de

comunicacao e uma aplicacao de visualizacao instalada no cliente (terminal) O

papel destes terminais era apenas disponibilizar ao utilizador um meio de comu-

nicacao (entrada e saıda) e apresentacao dos resultados do servidor Nao tinham

um papel activo no calculo nem na logica de negocio e frequentemente nao tinham

tambem nenhum mecanismo de armazenamento de dados

Como vantagens esta arquitectura apresenta uma reduzida necessidade de con-

figuracao e manutencao do lado do cliente Uma vez que o centro do processamento

e manipulacao de dados ocorre no servidor existe tambem uma centralizacao da

informacao [NJN00] que introduz um ponto crıtico de falha1 Actualizacoes e novas

funcionalidades sao faceis de distribuir uma vez que requerem apenas alteracoes no

servidor [Gro02a]

212 Fat-clients

Contrastando com os thin-clients nesta arquitectura os clientes implementam

ja uma parte da logica de negocio e sao responsaveis pelo processamento de dados

Estes fat-clients vieram responder a necessidade crescente de aplicacoes com um

nıvel de interactividade e capacidade de configuracao maior que as oferecidas pela

arquitectura thin-client descrita na seccao 211 Apesar de manterem a sua de-

pendencia do servidor podem tambem ser executados sem uma conexao activa uma

vez que dispoe de armazenamento de dados local o que lhes confere a capacidade

de persistencia de dados e do estado de execucao entre cada sessao

Foi disponibilizando este controlo sobre o estado da aplicacao bem como acesso

a recursos locais (por exemplo sistema de ficheiros e perifericos) que surgiram as

primeiras verdadeiras desktop applications No entanto cada cliente tinha que ser

separadamente instalado no computador pessoal de cada utilizador que pretendesse

utilizar ou interagir com a aplicacao e uma actualizacao ao servidor implicava in-

variavelmente uma actualizacao manual tambem no cliente Uma vez que nem todos

1NT single point of failure

6

Enquadramento do Projecto

Thin-clients Fat-clientsNao toma parte no processamento dedados nem possui acesso ao sistema deficheiros

Participa activamente no processa-mento de dados recorrendo ao sis-tema de armazenamento local para ar-mazenamento de dados

Nao mantem registo do estado logicoda aplicacao entre duas sessoes de uti-lizacao

O acesso ao armazenamento localpermite-lhe manter registo do estadologico da aplicacao entre duas sessoes

O thin-client nao necessita de qualquerinstalacao estando ldquopronto a utilizarrdquo

E geralmente necessario instalar aaplicacao para poder interagir com oservidor

Qualquer update no servidor reflecte-seimediatamente por todos os clientes

Embora a aplicacao cliente possa aler-tar para existencia de novas versoes asactualizacoes tem que ser manualmenteinstalados pelo cliente

O software do cliente destina-se apenasa apresentacao de dados e comunicacaocom o servidor sendo portanto de sim-ples implementacao

Como o software do cliente toma parteactiva no processamento de dadosa sua implementacao requer cuidadosadicionais

Grande mobilidade uma vez que todaa informacao e mantida no servidor

Parte da informacao podera estar ape-nas do lado cliente pelo que existemalgumas restricoes a sua mobilidade

Tabela 21 Comparacao entre thin-clients e fat-clients

os utilizadores actualizam regularmente as suas aplicacoes o servidor tem que estar

preparado para lidar com versoes antigas2 ou descontinuar os seus servicos a uma

parte da sua comunidade de utilizadores ate que estes actualizem os seus sistemas

Como os utilizadores passam a utilizar os seus recursos locais para armazenamento

de dados as alteracoes que nao sejam sincronizadas com o servidor estao apenas

disponıveis nos seus computadores pessoais o que introduz uma restricao a mobili-

dade

Pode-se afirmar que as vantagens dos thin-clients sao as desvantagens dos fat-

clients e que as vantagens dos fat-clients sao as vantagens dos thin-clients tal como

se ilustra na Tabela 21

213 Arquitecturas cliente-servidor

Introduzidos os termos thin-client e fat-client interessa reafirmar que ambos

podem ser vistos como arquitecturas cliente-servidor Um cliente define-se como

um solicitador de servicos e um servidor como um prestador de servicos tal como

definido por [Sch96] e [Sad97]

2NT backward compatibility

7

Enquadramento do Projecto

As arquitecturas cliente-servidor sao categorizadas pela modularizacao com que

sao desenhadas sendo consideradas as seguintes camadas

1 Interface grafica (front-end) atraves da qual os utilizadores interagem com

a aplicacao Quando este modulo e implementado separadamente dos outros

dois constitui uma aplicacao thin-client por si so uma vez que nao implementa

regras de negocio (embora possa definir validacoes de formularios de insercao de

dados por exemplo) A informacao introduzida pelo utilizador e enviada para

o servidor que processa o seu pedido e retorna uma resposta Este processo

repete-se ate que o utilizador atinja o seu objectivo ou se desligue do sistema

2 A logica de negocio tambem designada por camada intermedia que imple-

menta as regras de aceitacao e validacao de todos os dados introduzidos pelo

utilizador E tambem a plataforma de comunicacao que une a camada superior

de visualizacao com a camada de acesso a dados

3 A camada de dados inclui quer o sistema de persistencia de dados onde sao

armazenados os dados relevantes como tambem os mecanismos necessarios

para a sua pesquisa seleccao e alteracao

Os thin-clients quando observados no seu conjunto de cliente e servidor podem

ser vistos quer como sistemas de duas camadas quer como sistemas de tres camadas

dependendo apenas da forma como o servidor for implementado No caso de na

implementacao do servidor nao se distinguir a camada de acesso a dados da camada

da logica de negocio sao designados por sistemas de duas camadas Caso seja feita

esta distincao sao designados por sistemas de tres camadas Ambos os casos sao

ilustrados na Figura 21

Historicamente os fat-clients eram implementados numa arquitectura em duas

camadas Possuıam apenas um modulo de visualizacao de dados designado por

camada de interface e um modulo que implementava toda a logica de negocio e

regras de acesso a base de dados No entanto com a introducao de ligacoes mais

rapidas e de computadores pessoais com maior capacidade de processamento e so-

bretudo devido a complexidade crescente das aplicacoes a logica de negocio e a

camada de acesso a dados tornaram-se independentes Este modelo e designado por

arquitectura em tres camadas e e ilustrado na Figura 22

22 Evolucao na Internet

Ao analisar a evolucao das arquitecturas das aplicacoes desenvolvidas para a

Internet podemos encontrar um paralelismo com a historia da arquitectura de soft-

ware

8

Enquadramento do Projecto

Figura 21 Arquitectura de um sistema thin-client em duas camadas (a esquerda) e emtres camadas (a direita) Note-se a inclusao do servidor (mainframe) na definicao dascamadas desta arquitectura devido a forte dependencia cliente-servidor

221 Paginas web estaticas

Uma pagina web estatica devolve sempre a mesma resposta a todos os pedidos

para todos os utilizadores e em qualquer contexto utilizando o hipertexto como

forma de ligacao entre diversas paginas estaticas

A informacao e armazenada num servidor e o papel do cliente e apenas a apre-

sentacao da informacao Esta forma de disponibilizacao de informacao pode assim

ser comparada com os thin-clients descritos na seccao 211 o utilizador acede a

um website estatico para visualizar informacao sem que o cliente tome parte no

processamento A unica diferenca e que no caso da web estatica a informacao ap-

resentada e sempre a mesma enquanto que nos thin-clients era frequente existir a

possibilidade de insercao de dados no cliente e apos o seu processamento servidor

nova informacao poderia ser apresentada O hipertexto e utilizado para ligar as

paginas entre si numa rede de conteudos relacionados e a navegacao sıncrona era

feita atraves de cliques do rato a cada clique uma nova pagina era apresentada

Este modelo sıncrono e ilustrado na Figura 23

222 Paginas web interactivas e paginas web dinamicas

O JavaScript e uma linguagem interpretada de scripting que tem os browsers

como principal ambiente de acolhimento Os browsers utilizam uma Application

9

Enquadramento do Projecto

Figura 22 Arquitectura de um fat-client em duas camadas (a esquerda) e em tres camadas(a direita)

Programming Interface (API) publica para criar ldquoobjectosrdquo responsaveis por reflectir

e disponibilizar o Document Object Model (DOM) para o motor de JavaScript

A utilizacao mais frequente desta linguagem e a escrita de funcoes que sao em-

bebidas ou incluıdas em paginas web e que interagem com o DOM Uma vez que o

JavaScript e executado localmente (na maquina do cliente e nao no servidor) e capaz

de responder rapidamente a accoes do utilizador tornando a execucao de aplicacoes

no browser mais fluıdas o JavaScript pode tambem detectar accoes do utilizador

que o HTML nao pode tal como o pressionar de uma tecla

Em Dezembro de 1995 a Netscape Communications adicionou suporte para o

JavaScript no browser Netscape Navigator3 e em Agosto de 1996 o browser Internet

Explorer4 da Microsoft passou a tambem a suportar uma versao semelhante desta

linguagem (hoje todos os principais browsers suportam esta tecnologia)

Esta inovacao permitiu tornar os websites mais interactivos mas a sua utilizacao

esteve confinada apenas a este proposito durante um longo perıodo As paginas

passaram a responder activamente a accoes do utilizador (sendo uma das utilizacoes

3Netscape Communications ndash httpbrowsernetscapecom4Microsoft Internet Explorer ndash httpwwwmicrosoftcomwindowsproductswinfamilyie

10

Enquadramento do Projecto

mais vulgares a validacao de formularios) mas continuaram essencialmente estaticas

O JavaScript ainda nao era nesta altura utilizado para processar dados

Tambem nesta altura (1995ndash96) surgiram linguagens server-side como o PHP

Hypertext Preprocessor (PHP) e Active Server Pages (ASP) e o servidor passou a ter

um processamento de dados introduzidos pelo utilizador mais activo Generalizaram-

se as paginas dinamicas capazes de responder a insercao de dados ou outros pedidos

determinados por accoes do utilizador As paginas tornaram-se aplicacoes web ap-

plications

Uma definicao tradicional de web application e um conjunto de paginas web

logicamente agrupadas e geridas por uma unica entidade que tem como pontos de

entrada formularios de insercao de dados (web forms) Uma web application nao e

mais do que uma aplicacao que e acedida atraves de um browser Tem geralmente

uma arquitectura logica em tres (interface logica de negocio e camada de dados)

camadas e estao armazenadas num servidor

Ha dois tipos de web applications

bull Orientadas a apresentacao Sao web applications que geram paginas web in-

teractivas constituıdas por varios tipos de linguagens de anotacao (por exem-

plo HTML eXtensible Markup Language (XML)) e que apresentam conteudo

dinamico como resposta a pedidos efectuados pelo utilizador

bull Orientadas aos servicos Uma web application orientada aos servicos imple-

menta o ponto de acesso para um ou mais de um web service Sao geralmente

clientes de service oriented web applications

Uma vantagem significativa de implementar uma web application de forma a

suportar as funcionalidades padrao dos browsers e que estas terao o mesmo com-

portamento independentemente da plataforma e do browser a partir do qual serao

acedidas No entanto diferentes implementacoes de browsers devido a diferentes

interpretacoes dos padroes definidos tornam por vezes esta tarefa um pouco mais

complicada existindo inclusivamente na web guioes de compatibilidade para os difer-

entes browsers como [Smi07]

223 Web 20 e Ajax

O termo web 20 descreve uma tendencia de utilizacao e de design observada

na World Wide Web (WWW) com o objectivo de melhorar a criatividade partilha

de informacao e principalmente a colaboracao entre utilizadores Estes conceitos

levaram ao desenvolvimento e evolucao de comunidades online tais como redes so-

ciais wikis e blogues

11

Enquadramento do Projecto

O termo tornou-se mais conhecido apos a primeira conferencia OrsquoReilly Media

Web 20 em 2004 e apesar de sugerir uma nova versao da WWW nao se refere a

qualquer evolucao tecnologica mas apenas a alteracoes a forma como os utilizadores

se servem da web De acordo com Tim OrsquoReilly [OrsquoR06] ldquoWeb 20 e uma revolucao

na industria do software causada pela adopcao da web como uma plataforma e pela

tentativa de entendimento das regras para o sucesso nesta nova plataformardquo

O desenvolvimento da Web 20 serve-se muitas vezes de um outro conceito Ajax

O conceito que hoje conhecemos como Ajax muitas vezes incorrectamente de-

scrito como uma tecnologia foi originalmente criado para permitir o desenvolvimento

de web applications que se assemelhassem ainda mais a aplicacoes de desktop Este

conceito foi melhor descrito por [Gar05] como um conjunto de varias tecnologias

que podem ser utilizadas para melhorar a experiencia do utilizador de uma dada

web application introduzindo a capacidade assıncrona de envio de pedidos ou da

recepcao assıncrona de respostas As tecnologias mais frequentemente envolvidas

sao

bull eXtensible HyperText Markup Language (XHTML) e Cascading Style Sheets

(CSS) padrao para a apresentacao

bull interaccao dinamica atraves do DOM

bull troca e manipulacao de dados utilizando XML e eXtensible Stylesheet Lan-

guage Transformation (XSLT) ou JavaScript Object Notation (JSON)

bull pedidos assıncronos utilizando XMLHttpRequest [vK08]

bull JavaScript utilizado para integrar todas estas tecnologias

E importante frisar que o Ajax nao e um produto nem uma tecnologia E um

termo que descreve a utilizacao de um conjunto de tecnologias para o desenvolvi-

mento de web applications com um elevado grau de interactividade Comparativa-

mente as web applications tradicionais o Ajax introduz uma camada de visualizacao

diferente em tres importantes pontos

1 Do lado do cliente existe um motor que serve de intermediario entre a interface

da aplicacao e o servidor

2 A actividade do utilizador despoleta chamadas JavaScript em vez de um pedido

de pagina directamente ao servidor

3 Informacao codificada em XML em vez de paginas HTML e trocada entre o

servidor e o cliente

12

Enquadramento do Projecto

Isto significa que as paginas que utilizam Ajax contem um motor do lado do

cliente composto por um conjunto de funcoes JavaScript responsavel pela comu-

nicacao com o servidor e por actualizar a interface com o resultado dessa mesma

comunicacao

Na Figura 23 ilustra-se a natureza assıncrona do Ajax quando comparada com

as web applications tradicionais Como se pode observar adicionando um mecan-

ismo Ajax a uma web application eliminam-se diversos tempos de espera associados

a comunicacoes com o servidor uma vez que a interface nao fica ldquobloqueadardquo a es-

pera da resposta Obtem-se assim aplicacoes com um comportamento mais fluido

eliminando tempos de espera entre cada ldquocliquerdquo e melhorando a experiencia do

utilizador

23 Offline Web Applications

A informacao grafica (bem como folhas de estilo e scripts) tais como as ima-

gens que constituem o visual de uma web application e ja tratada de forma especial

pelos cada vez mais avancados sistemas de cache (armazenamento temporario) dos

browsers Mas estes nao sao ainda capazes de guardar conteudo criado pelo uti-

lizador nem de apresentar informacao independentemente do estado da ligacao

Numa altura onde se fala de servicos de Internet wireless municipalizados [Kha]

comunicacoes 3G e ligacoes de banda larga a alta velocidade a ligacao a rede global

continua a nao estar permanentemente disponıvel para os utilizadores Na WWW

encontra-se uma importante parte da informacao e das aplicacoes utilizadas para

criar e editar conteudos Por vezes informacao vital para a produtividade pode

desaparecer subitamente do mapa de acesso de um utilizador quando este entra no

metro num aviao ou mesmo quando se desloca para uma cidade ou paıs diferente

do habitual onde nao subscreve um plano de acesso que lhe garanta a ligacao

Permitir o acesso offline a estes recursos assume assim a sua importancia porque

permitira estender o alcance da informacao a locais onde nunca esteve antes e per-

mitira tambem melhorar o desempenho das web applications colocando informacao

mais perto dos utilizadores reduzindo a transferencia de dados apenas ao essencial

24 Comparacao

Nas evolucoes descritas neste capıtulo 2 pode-se observar que existe um par-

alelismo entre a evolucao das arquitecturas tradicionais cliente-servidor e a evolucao

a que se assiste na web O comportamento e arquitectura dos thin-clients assemelha-

se ao das paginas estaticas no sentido em que o browser nao toma parte em qualquer

13

Enquadramento do Projecto

processamento e serve apenas como uma plataforma de interaccao com o servidor

tal como os clientes descritos na seccao 211

A sua proxima evolucao os fat-clients trouxeram parte da capacidade de pro-

cessamento para o lado do cliente Na web foi tambem esta a inovacao tecnologica

a que se assistiu com a evolucao das tecnologias que permitiram a criacao de ver-

dadeiras aplicacoes e com a introducao do Javascript no browser dando ao cliente

a capacidade de processamento de dados A necessidade da separacao do codigo

em camadas logicas advem da crescente complexidade das web applications Esta

pratica permite entre outras coisas melhorar o processo de desenvolvimento e a

capacidade de manutencao de uma aplicacao

Os fat-clients tem tambem a capacidade de armazenamento de dados o que

permite a persistencia de informacoes entre duas sessoes e que algumas operacoes

sejam executadas sem a necessidade de comunicacao com o servidor Este facto pode

tambem ser uma realidade nas web applications com a adopcao das tecnologias OWA

Neste momento assiste-se a uma utilizacao cada vez maior da web como uma

plataforma de desenvolvimento A capacidade de cooperacao na edicao de conteudos

e a mobilidade proporcionada por esta plataforma sao os principais factores que

alimentam esta mudanca e pela primeira vez as aplicacoes tradicionais tem com-

peticao vinda de web applications A prova do reconhecimento da web como plataforma

de desenvolvimento pode ser retirada da aposta de empresas como a Adobe e Mi-

crosoft que lancaram publicamente ferramentas web complementares a produtos

seus tradicionalmente associados ao desktop ndash Acrobatcom5 e Microsoft Office

Live6 Dotar estas web applications da capacidade de execucao offline significa

aproximar a web e o desktop reunindo ldquoo melhor de dois mundosrdquo

As vantagens da mobilidade possıvel atraves da web a cooperacao na criacao e

edicao de conteudos e a possibilidade de utilizar aplicacoes sempre actualizadas e

sem necessidade de instalacao sao algumas das principais vantagens que promovem

esta mudanca que devido as preocupacoes associadas a usabilidade e experiencia do

utilizador esta fortemente associada ao desenvolvimento de Rich Internet Applica-

tion (RIA)s

5Adobe Acrobatcom httpwwwacrobatcom6Microsoft ndash httpsmallbusinessofficelivecom

14

Enquadramento do Projecto

Figura 23 Comparacao do modelo de web aplications sıncrono paginas estaticas e in-teractivas abordados nas seccoes 221 e 222 com o modelo de web applications Ajax(assıncrono) abordado na seccao 223 Figura adaptada de http www adaptivepath

com

15

Enquadramento do Projecto

16

Capıtulo 3

Estado da arte

Apesar de o conceito das OWAs nao ser absolutamente novo as tecnologias que

o suportam sao recentes Neste capıtulo descrevem-se quatro tecnologias que foram

tidas como principais candidatas para o desenvolvimento deste projecto Descrevem-

se ainda alguns exemplos de web applications que disponibilizam actualmente fun-

cionalidades offline e o processo da escolha da tecnologia a utilizar neste projecto

31 Gears

O Gears1 e uma extensao as funcionalidades do browser introduzido pelo Google

que tem como principal objectivo tornar possıvel a visualizacao de paginas de Inter-

net mesmo sem uma conexao disponıvel Encontra-se disponıvel para as platafor-

mas Windows Macintosh e Linux e oferece uma API de Javascript que permite

a scripts aceder a um mecanismo de armazenamento local baseado numa base de

dados SQLite

311 Arquitectura

Esta ferramenta e constituıda por tres componentes principais

bull LocalServer mdash Intercepta pedidos de paginas web e serve-as localmente

bull Database mdash Uma base de dados relacional construıda sobre SQLite

bull WorkerPool mdash Permite executar operacoes de computacao de uma forma

assıncrona sem afectar a capacidade de resposta e fluidez de execucao da web

application Assemelham-se a processos

1Google Inc ndash Mais informacao em httpgearsgooglecom

17

Estado da arte

LocalServer

O modulo LocalServer e uma cache de Uniform Resource Locators (URLs)

controlada pela web application Quando nao existe uma ligacao a Internet e e

feito um pedido para um URL presente nesta cache o LocalServer intercepta-o e

responde ao pedido localmente a partir do disco rıgido do utilizador A aplicacao

pode utilizar dois tipos diferentes de armazenamento local de URLs

bull ResourceStore ndash serve para capturar URLs utilizando exclusivamente a API

de Javascript disponibilizada para o efeito Uma aplicacao podera criar e

utilizar diversos ResourceStores simultaneamente para capturar ficheiros de

dados que necessitam de ser enderecados por um URL tal como um ficheiro

PDF ou uma imagem

bull ManagedResourceStore ndash serve para capturar um conjunto de URLs que estao

relacionados e que sao declarado num ficheiro de manifesto (especificado em

JSON) e que sao automaticamente actualizados O ManagedResourceStore

permite que o conjunto de recursos necessarios para correr uma web application

seja capturado e mantido actualizado automaticamente

A principal diferenca entre estes dois tipos de armazenamento de URLs e a forma

como sao actualizados os seus conteudos Os conteudos de um ManagedResourceStore

sao actualizados sempre que a versao contida no ficheiro de manifesto for alterada

enquanto que os conteudos de um ResourceStore nunca sao actualizados automati-

camente mas apenas quando for explicitamente ordenado pela aplicacao

O LocalServer e capaz de interceptar e servir localmente pedidos de HTTP e

HTTPS sempre que se reunam as seguintes condicoes

1 O URL encontra-se armazenado num ResourceStore ou ManagedResourceStore

2 O sistema de armazenamento local encontra-se activo (enabled = true) Se

o sistema de armazenamento local tiver o atributo requiredCookie o pedido

devera conter um cookie que lhe corresponda

O LocalServer nao necessita de monitorizar o estado da ligacao para atender aos

pedidos Na verdade sempre que as condicoes previamente enunciadas se verificarem

o LocalServer interceptara os pedidos e independentemente do estado da ligacao

a Internet servi-los-a a partir do disco rıgido local Cabera a aplicacao definir qual

o modo em que pretende executar um pedido (online ou offline) definindo o valor

de verdade da propriedade enabled

18

Estado da arte

Database

O modulo Database permite guardar dados da web application assegurando a

sua persistencia Os dados sao guardados de forma relacional no disco rıgido do uti-

lizador2 de acordo com o modelo de seguranca estabelecido pelo Gears3 significando

que uma aplicacao nao pode aceder a conteudos fora do seu domınio

WorkerPool

Nos web browsers uma operacao pesada de computacao pode tornar a interface

lenta e tornar menos agradavel a experiencia do utilizador O modulo WorkerPool

permite correr operacoes em background sem bloquear a interface com o utilizador

Os scripts executados numa WorkerPool nao activam os mecanismos de seguranca

do browser que mostram a mensagem ldquoA script on this page may be busy or may

have stopped respondingrdquo

O WorkerPool comporta-se como um conjunto de processos em vez de threads

Os Workers nao partilham qualquer estado de execucao o que significa que uma

alteracao a uma variavel num Worker nao afecta em nada a execucao de outro

Worker Alem disso os Workers nao herdam automaticamente nenhum codigo dos

seus pais Cada Worker e membro de um WorkerPool e os Workers podem in-

teragir entre si enviando mensagens em formato de texto ou JSON No entanto ha

tambem algumas limitacoes os Workers nao tem acesso ao DOM e objectos como

window ou document nao se encontram acessıveis Isto e consequencia de os Workers

nao partilharem o estado de execucao Mas tem acesso a todas as funcoes built-in

do Javascript A maioria das funcionalidades do Gears pode tambem ser acedida

atraves de uma variavel global especial definida como googlegearsfactory Para

outras funcionalidades especıficas os Workers podem ldquopedirrdquo a pagina principal para

continuar a execucao atraves do envio de mensagens

Outras funcionalidades

bull HttpRequest ndash Este modulo implementa a especificacao W3C XmlHttpRe-

quest definida em [vK08] tornando-a disponıvel para os workers e para a

pagina principal

bull Timer ndash Este modulo implementa a especificacao de timers tal como descrito

por [Hic08] e torna-os disponıveis para os workers e para a pagina principal

2Consultar httpcodegooglecomapisgearsapi_databasehtmldirectories3Consultar httpcodegooglecomapisgearssecurityhtml

19

Estado da arte

bull Factory ndash Esta classe e utilizada para instanciar todos os outros objectos da

API do Gears atraves do seu metodo create Este metodo pode ser utilizado

com os seguintes parametros

ndash betadatabase

ndash betahttprequest

ndash betalocalserver

ndash betatimer

ndash betaworkerpool

312 Goggle Gears em dispositivos moveis

O Gears esta tambem disponıvel em dispositivos Windows Mobile 5 e 6

Os dispositivos moveis estao pela sua natureza frequentemente desconectados

da Internet Mesmo quando possuem uma ligacao as latencias na transferencia de

dados em redes moveis tornam as aplicacoes pouco fluıdas mas o Gears permite

ultrapassar este obstaculo

O Gears funciona exactamente da mesma forma em dispositivos moveis equipados

com o Windows Mobile 5 e 6 como num computador comum Se uma aplicacao tiver

sido implementado com suporte para o Gears entao tambem estara preparada para

ser executada num dispositivo movel mas as limitacoes dos browsers disponıveis

para dispositivos moveis tem que ser consideradas Isto significa prever as condicoes

que permitam uma boa usabilidade devido aos pequenos ecras destes dispositivos

bem como o seu suporte limitado dos padroes do DOM CSS e JavaScript

32 Adobe AIR

O Adobe AIR4 e um runtime compatıvel com diversos browsers e sistemas opera-

tivos que pretende dar aos programadores a possibilidade de combinar diversas tec-

nologias de producao de conteudos para a Internet no desenvolvimento de Rich Inter-

net Application (RIA)s O Adobe AIR mantem uma relacao com o browser mas es-

tende as suas capacidades e tecnologias permitindo o desenvolvimento de aplicacoes

tambem para o ambiente de trabalho com janelas em tudo semelhantes as do sis-

tema operativo Segundo a Adobe o objectivo e complementar o browser dando

aos utilizadores (mas essencialmente aos programadores e equipas de desenvolvi-

mento) a escolha sobre como distribuir as suas aplicacoes Para este efeito o Adobe

AIR tem uma aproximacao diferente do Gears Em vez de ldquoestenderrdquo o browser

acrescentando-lhe funcionalidades o AIR permite tambem o desenvolvimento de

4Adobe - httpwwwadobecomproductsair

20

Estado da arte

aplicacoes que se destinam a ser executadas fora do ambiente do browser mas uti-

lizando as tecnologias comuns da Internet (por exemplo HTML CSS JavaScript

Flash Flex)[CDGH08]

A utilizacao desta tecnologia permite utilizar o browser ou o proprio runtime

Adobe AIR como plataforma de execucao da aplicacao

Na Tabela 31 faz-se uma comparacao das funcionalidades disponıveis de acordo

consoante se escolha o browser ou o desktop como plataforma base para a aplicacao

Uma vez que as aplicacoes Adobe AIR na plataforma desktop tem um caracter

persistente (sao instaladas no computador do utilizador) o Adobe AIR tem um

modelo de seguranca que se assemelha com o das tradicionais aplicacoes desktop

[Ada08] Este modelo e analisado nas seccoes 321 e 322 O ambiente em que

e executado o browser e restringido a execucao de web applications que podem

ser de varias origens (incluindo de origens anonimas ou sem confianca) O Adobe

AIR proporciona acesso a capacidades como acesso a ficheiros que necessitam da

confianca do utilizador

bull HTML ndash O desenvolvimento de aplicacoes para o Adobe AIR pode ser feito

com recurso a tecnologias de HTML e Ajax comuns utilizando as linguagens

de markup existentes distribuıdas como texto e interpretadas em execucao

(runtime)

bull Flash ndash Outra alternativa sera a utilizacao da linguagem Flash Permite a

renderizacao de graficos vectoriais e audiovıdeo com suporte nativo Utiliza

ActionScript para adicionar maior interactividade com o utilizador

bull Flex ndash O Flex e uma framework open source para o desenvolvimento de RIAs

usando Flash As aplicacoes Flex sao na realidade Flash sendo a principal

diferenca o ambiente de desenvolvimento

Como resultado uma aplicacao AIR podera ser implementada

bull Baseada em Flash ou Flex (aplicacoes cujo conteudo base e em ShockWave

Flash (SWF))

bull Baseada em Flash ou Flex tambem com HTML ou Portable Document Format

(PDF) Aplicacoes cujo conteudo de base e em FlashFlex (SWF) com HTML

(HTML JavaScript CSS) ou conteudo PDF incluıdo

bull Baseada em HTML Aplicacoes cujo conteudo base e em HTML Javascript

CSS

bull Baseada em HTML utilizando tambem FlashFlex ou PDF

21

Estado da arte

Os utilizadores interagem com uma aplicacao AIR da mesma forma que interagem

com outras aplicacoes com janelas nativas do seu sistema operativo O runtime e

instalado uma vez no computador do utilizador e a partir desse momento todas as

aplicacoes AIR terao o mesmo aspecto que qualquer outra aplicacao para o desktop

321 Seguranca

Permitir que uma web application aceda ao disco de armazenamento do utilizador

pode comprometer seriamente a sua seguranca Neste sentido o Adobe AIR tem

suporte para assinaturas digitais (Secure Sockets Layer (SSL)) que podem ser com-

pradas pelas equipas de desenvolvimento que o desejem e cujos certificados serao

apresentados ao utilizador no momento da instalacao Um outro aspecto ainda

relativo a seguranca e o mecanismo de isolamento de cada ambiente (sandbox )

322 Assinatura do codigo

O runtime AIR exige que todas as aplicacoes estejam digitalmente assinadas As

assinaturas digitais de codigo sao um processo que visa garantir a integridade da

aplicacao e a identidade do seu autor no momento da instalacao As equipas de

desenvolvimento podem ldquoassinarrdquo uma aplicacao utilizando um certificado atribuıdo

por uma Entidade Certificadora (Certification Authority) ou atraves de um certifi-

cado individual (self signed certificate) Neste momento o Adobe AIR suporta como

entidades certificadoras a Verisign e a Thawte [Ado08]

O instalador apresenta o nome de quem publica a aplicacao quando o codigo tiver

sido assinado com um certificado que apresente confianca ou que esteja encadeado

com um certificado que tenha ja sido aceite no computador em que se esta a instalar

a aplicacao

As equipas de desenvolvimento podem tambem assinar as aplicacoes com um

certificado auto-atribuıdo (um certificado criado por elas proprias) mas neste caso

o instalador apresentara estas aplicacoes como sendo de uma origem nao verificada

O AIR utiliza a infraestrutura publica de chaves [Ent07] suportada pelo arquivo

local do sistema operativo Para que a origem da aplicacao seja reconhecida o

computador onde a aplicacao AIR esta a ser instalada tem que confiar directamente

no certificado que foi utilizado para assinar a aplicacao ou confiar num certificado

que esteja num encadeamento logico de certificados confiados e que se ligue desta

forma ao certificado utilizado para assinar a aplicacao

Todas as aplicacoes AIR tem caracterısticas em comum independentemente da

tecnologia utilizada para o seu desenvolvimento (HTMLFlexFlash) No ambito

de uma aplicacao AIR existem um conjunto de APIs que estao disponıveis e que

tornam possıvel o acesso ao sistema local (leitura e escrita) e a recursos de rede que

22

Estado da arte

de outra forma nunca estariam acessıveis a partir de uma web application comum

Cada aplicacao AIR possui tambem diferentes nıveis de isolamento chamados secu-

rity sandboxes dependendo do tipo de conteudo que esta a ser carregado e do seu

objectivo

bull Isolamento ao nıvel da aplicacao5 ndash E a raiz de cada aplicacao AIR Este

nıvel de isolamento permite o acesso a APIs privilegiadas e especıficas do

AIR Em contrapartida e negado o acesso a algumas APIs que poderiam ser

facilmente utilizadas de forma maliciosa contra o utilizador final Importacao

dinamica de conteudos remotos e geralmente proibido e as tecnicas e mecan-

ismos de geracao dinamica de codigo sao fortemente restringidas Apenas

conteudo carregado directamente da directoria base da aplicacao podera ser

colocado neste nıvel de isolamento

bull Isolamento nao especıfico da aplicacao6 ndash contem todo o outro conteudo

que nao tenha sido carregado directamente para o isolamento da aplicacao

Isto inclui conteudo local e remoto Este tipo de conteudo nao tem acesso

directo as APIs do AIR e rege-se pelas mesmas regras tal como se tivesse sido

carregado por um browser a partir da mesma localizacao (por exemplo HTML

carregado a partir de um domınio remoto comporta-se da mesma forma que se

fosse acedido a partir do browser)

33 Mozilla Prism

331 XML User Interface Language

O eXtensible User Interface Language (XUL) e uma linguagem de anotacao

baseada em XML desenvolvida pela Mozilla Foundation que opera em aplicacoes

Mozilla multi plataforma tal como o Firefox O motor Gecko e a unica imple-

mentacao completa desta linguagem que foi desenhada sobre padroes web comuns

como CSS JavaScript e o DOM e permite o desenvolvimento de interfaces graficas

utilizando elementos pre-definidos tais como window box page textbox radio

button entre outros Infelizmente o XUL nao possui qualquer especificacao formal

ou implementacoes de inter-operabilidade para outros motores que nao o Gecko No

entanto a sua implementacao e licenciada em codigo aberto pelas licencas GNU Gen-

eral Public License (GPL) GNU Lesser General Public License (LGPL) e Mozilla

Public License (MPL)

Enunciam-se algumas caracterısticas desta linguagem

5NT application sandbox6NT non-application sandbox

23

Estado da arte

Liguagem de anotacao poderosa baseada em componentes (widgets) O ob-

jectivo do XUL e permitir a construcao de aplicacoes multi-plataforma em

claro contraste com o Dynamic HyperText Transfer Protocol (DHTML) que se

destina ao desenvolvimento de paginas web Por esta razao o XUL esta orien-

tado a componentes tais como janelas botoes e etiquetas em vez de paginas

cabecalhos de texto e ligacoes de hipertexto Investir tempo e esforco para

atingir este mesmo resultado em aplicacoes baseadas em DHTML compromete

frequentemente a complexidade e desempenho da aplicacao

Baseado em padroes O XUL e um dialecto XML baseado no padrao W3C XML

10 As aplicacoes escritas em XUL sao tambem baseadas em especificacoes

W3C adicionais como HTML 40 CSS DOM nıvel 1 e 2 JavaScript 15

incluindo ECMA-262 Edition 3 (ECMAscript)

Portabilidade entre plataformas Tal como HTML o XUL foi desenhado para

ser independente da plataforma em que e utilizado tornando as aplicacoes

facilmente portaveis entre sistemas operativos nos quais o Mozilla e suportado

Uma vez que o XUL oferece um nıvel de abstraccao dos componentes graficos

de interface que disponibiliza implementa a premissa ldquoum codigo para todas

as plataformasrdquo A interface grafica de todos os produtos centrais Mozilla

(browser instant messenger livro de enderecos) e escrita em XUL com um

unico codigo base que suporta todas as plataformas Mozilla

Separacao entre o nıvel de apresentacao e a logica de negocio Uma das

maiores preocupacoes no desenvolvimento para a Internet e a forte ligacao

entre estas duas camadas (interface e logica) Isto constitui um problema sig-

nificativo no desenvolvimento de grandes aplicacoes especialmente quando o

desenvolvimento e feito em ambientes de equipa porque as capacidades de de-

senvolvimento destas duas partes da aplicacao estao muitas vezes espalhadas

por diferentes elementos O XUL permite uma clara distincao entre a definicao

da aplicacao cliente e da logica de implementacao (XUL eXtensible Binding

Language (XBL) e JavaScript) apresentacao (CSS e imagens) internacional-

izacao (Document Type Definitions (DTDs) e etiquetas de texto em lınguas

especıficas guardados em ficheiros properties) O esquema grafico e apre-

sentacao de uma aplicacao XUL pode ser alterado de forma independente da

sua logica ou implementacao e a aplicacao pode ainda ser traduzida (interna-

tionalization) de forma independente da sua logica implementacao ou apre-

sentacao Este grau de separacao resulta em aplicacoes que sao mais faceis de

manter pelos programadores e facilmente adaptadas por designers e tradutores

24

Estado da arte

Facil adaptacao Outro benefıcio que advem do nıvel de separacao entre logica

de negocio e apresentacao oferecido pelo XUL e a facilidade com que se pode

adaptar uma aplicacao para diferentes clientes ou grupos de utilizadores Um

programador pode utilizar a mesma aplicacao base e adapta-la consoante as

necessidades atraves de diferentes temas (skins) e ficheiros de lınguas Desta

forma uma aplicacao escrita e desenvolvida em Ingles pode ser rapidamente

traduzida para Portugues e distribuıda com outra aparencia mais apropriada

ao cliente alvo

332 Prism

O Mozilla Prism e um browser simplificado e ldquointerpretadorrdquo de XUL (tambem

designado por XULRunner) que acolhe web applications sem a interface grafica ha-

bitual de um browser Baseia-se num conceito designado por Site Specific Browser

(SSB) Um SSB e uma aplicacao com um browser embebido desenhado para exe-

cutar apenas uma web application Nao possui os menus e barras de ferramentas

habituais Um SSB tem uma integracao com o sistema operativo e com o desktop

muito mais estreita do que uma web application acedida atraves de um browser uma

vez que e executado em janela propria

O Prism resulta de uma experiencia da Mozilla e visa reduzir as diferencas entre

as desktop applications tradicionais e as web applications Um dos aspectos focados e

a experiencia do utilizador Numa apresentacao oficial e dito que ldquo[o Prism] pretende

ser uma ponte entre as diferencas que existem entre as aplicacoes tradicionais de

desktop e as web applications explorando novos modelos de usabilidade enquanto

que a linha que as separa se continua a definirrdquo [Lab07]

34 HTML 5

A especificacao HTML 5 [Hic08] que se encontra em fase de desenvolvimento

pelo grupo WHATWG pretende ser uma norma de substituicao dos padroes HTML

4 XHTML 1x e do DOM2 HTML Uma das propriedades que o distingue das tec-

nologias que pretende substituir e precisamente o suporte para OWA e armazena-

mento de dados no cliente de uma forma relacional Nao sendo propriamente uma

tecnologia ndashmas antes uma especificacao ndashe aqui mencionada por ter servido como

referencia a diversas implementacoes de funcionalidades offline e por se considerar

que venha a ter um impacto significativo nas implementacoes de diversos browsers

Dion Almaer defendeu no seu blogue que o Gears era uma implementacao do

HTML 5 No seu artigo ldquoGears as a bleeding-edge HTML 5 implementationrdquo [Alm08]

o autor diz que ambos ndasho Gears e o HTML 5 ndashpretendem dar a web caracterısticas

25

Estado da arte

semelhantes e nao encontrar motivo de ldquocompeticaordquo entre as duas mas que en-

quanto o HTML 5 e uma especificacao o Gears e uma implementacao

No entanto tambem e verdade que o HTML 5 cobre muitos outros pontos para

alem das OWA que saem completamente fora do ambito do Gears Se esta es-

pecificacao atingir um estado de maturidade que possibilite a sua adopcao pelos

principais browsers tornando nativo do browser o suporte OWA entao deixara de

fazer sentido a existencia de uma extensao como o Gears

A especificacao HTML 5 disponibiliza duas APIs relevantes para o tema das

OWA

1 Uma base de dados baseada em SQL que permite o armazenamento de dados

do lado do cliente

2 Uma ldquocacherdquo HTTP que garante a disponibilidade das aplicacoes mesmo quando

o utilizador nao possui uma ligacao a Internet

Estas caracterısticas sao as bases da tecnologia das OWA e tem correspondencia

com os pontos analisados nas seccoes 311 e 311

35 Web applications que usam funcionalidades offline

Nesta seccao apresentam-se algumas web applications que actualmente disponi-

bilizam funcionalidades offline Estas aplicacoes foram escolhidas para uma analise

mais pormenorizada por utilizarem o Gears que tal como descrito na seccao 4 foi

a tecnologia escolhida para o projecto

351 Google Reader e Google Docs

O Google Reader7 e um leitor de feeds RSS Permite gerir a subscricao de varios

sites simultaneamente que disponibilizem conteudos neste formato e foi a primeira

web application da Google com uma versao offline publicamente acessıvel (desde

Junho de 2007)

O Google Reader implementa o modo ldquoutilizador deciderdquo oferecendo na sua

interface um botao que permite alternar entre os modos online e offline

O Google Docs8 e uma web application que permite a criacao e edicao de doc-

umentos de texto folhas de calculo e apresentacoes Era ja publico desde Janeiro

de 2008 que o Google estava a desenvolver uma versao OWA desta aplicacao mas o

acesso a uma versao experimental so foi possıvel a partir de 31 de Maio de 2008

7Google Reader - httpreadergooglecom8Google Docs - httpdocsgooglecom

26

Estado da arte

A implementacao das funcionalidades offline nestas duas aplicacoes seguiu difer-

entes aproximacoes principalmente porque o Google Reader apresenta ao utilizador

informacoes que sao fornecidas por fontes externas enquanto que no Google Docs

a informacao e criada e editada pelo utilizador sobre a forma de documentos

A diferente origem da informacao implica que no Google Reader seja necessario

prever casos de excepcao tal como existirem demasiados itens que necessitam de

ser transferidos para o cliente Nao observar este ponto causa um problema grave

de usabilidade e para evitar tempos de espera demasiado longos e uma interface

com pouca capacidade de resposta as accoes do utilizador o Google Reader apenas

transfere para o cliente os dois mil itens mais recentes na transicao para o modo

offline

352 Remember the Milk

O Remember The Milk9 e uma web application desenvolvida por uma equipa

Australiana que proporciona funcionalidades de agenda gestao de tempo e de tare-

fas e foi uma das primeiras aplicacoes independentes do Google a adoptar o Gears

para acessos em modo offline Permite que os seus utilizadores facam uma gestao

de tarefas agrupando-as em listas adicionando-lhes campos de informacao adicional

ou dando-lhes informacao geografica (recorrendo ao servico Google Maps10) Entre

a sua lista de funcionalidades encontra-se ainda a possibilidade de importar e ex-

portar eventos no formato iCalendar (ics) etiquetas (tags) em tarefas publicacao

Really Simple Syndication (RSS) e partilha de categorias de tarefas de acordo com

diferentes nıveis de permissoes de acesso definidos pelo utilizador

353 MySpace e WordPresscom

O MySpace uma das maiores social networks na Internet anunciou recente-

mente que vai disponibilizar uma versao do seu cliente de e-mail que utiliza o Gears

para acelerar o seu desempenho Numa fase inicial estara disponıvel apenas para

utilizadores que tenham cinco mil ou mais mensagens na sua caixa de correio e

permitira efectuar pesquisas muito mais rapido que a sua versao online

O servico de blogs Wordpresscom anunciou tambem o inıcio da utilizacao desta

tecnologia com o fim de melhorar o desempenho A versao que utiliza esta tecnologia

descarrega e armazena no cliente um conjunto de imagens e scripts que passam a

ter preferencia sobre os seus congeneres online e que permitem acelerar o processo

de carregamento da aplicacao e visualizacao de blogs

9Remember The Milk ndash httpwwwrememberthemilkcom10Google Maps ndash httpmapsgooglecom

27

Estado da arte

O MySpace e o Wordpresscom sao dois exemplos da utilizacao da tecnologia

OWA para optimizacao de web application ja existentes Sem pretenderem disponi-

bilizar uma versao que seja totalmente offline fazem uso do Gears para armazenar no

cliente parte dos recursos frequentemente acedidos na visualizacao das suas paginas

36 Escolha da tecnologia

Apos a analise das tecnologias apresentada nas seccoes 31 a 34 foi necessario es-

tudar a adequacao de cada uma delas ao projecto em questao Desde logo e possıvel

observar que nem todas se dedicam apenas a OWA Por exemplo o Adobe AIR

apesar de ter suporte para OWA apenas disponibiliza algumas das funcionalidades

identificadas como mais indicadas para a execucao do projecto quando utilizado

na sua vertente desktop tal como exposto na Tabela 31 mas a utilizacao desta

vertente implicaria o desenvolvimento de novas interfaces e de novas formas de co-

municacao (troca de mensagens XML ou JSON) A vertente web do Adobe AIR

foca-se mais especificamente nas Rich Internet Applications e permite a reutilizacao

do codigo ja existente (exigindo naturalmente a sua adaptacao e a implementacao

das funcionalidades pretendidas)

A tecnologia escolhida para a realizacao deste trabalho foi o Gears sendo que

um dos principais factores a influenciar esta opcao foi a liberdade introduzida pela

sua licenca Berkeley Software Distribution (BSD)11

Considerou-se o funcionamento desta ferramenta extremamente adequando a

aplicacao no WOW uma vez que o seu principal objectivo e precisamente tornar

possıvel a execucao offline de uma pagina web e por virtude deste facto o Gears tem

uma API concisa e de simples aplicacao pratica uma vez que nao possui quaisquer

outros elementos distractores O funcionamento do seu ManagedResourceStore ex-

emplificado na Figura 31 com a capacidade de actualizacao de recursos definidos

num ficheiro manifesto especificado em JSON pesou tambem nesta decisao

11Sobre a licenca BSD consultar httpwwwopensourceorglicensesbsd-licensephp e http

wwwlinfoorgbsdlicensehtml

28

Estado da arte

Figura 31 Esquema UML do processo efectuado pelos recursos do Gears do tipoManagedResourceStore para a actualizacao dos conteudos definidos no ficheiro manifesto

29

Estado da arte

Funcionalidade RIAs no browser RIAs no desktop

Disponibilidadeda aplicacao

As aplicacoes podem ser facil-mente exploradas e utilizadas

As aplicacoes quando instal-adas tem maior grau de fun-cionalidades e persistencia

Instalacao Nao e necessario qualquer tipode instalacao

As aplicacoes sao instaladasatraves do browser ou descar-regadas e instaladas comouma aplicacao tradicional

Actualizacoes Aplicacoes sao actualizadascarregando conteudos paraum website

O AIR disponibiliza uma APIque permite que as aplicacoessejam actualizadas de umaforma

Sistemas opera-tivos suportados

As aplicacoes podem ser exe-cutadas em diversos sistemasoperativos e browsers

As aplicacoes sao multi-plataforma e podem serinstaladas e executadas emdiversos sistemas operativos ebrowsers

Linguagens deprogramacao

Javascript e disponibilizadopelo browser e ActionScripte disponibilizado pelo AdobeFlash Player

Maquinas virtuais deJavascript e ActionScriptcompatıveis com o browser

Capacidade deexecucao embackground

As RIAs podem ser execu-tadas numa janela do browser

As aplicacoes podem ser ex-ecutadas em background edisponibilizar notificacoes talcomo uma aplicacao tradi-cional

Persistencia A actividade esta limitada asessao do browser Quando obrowser e encerrado toda ainformacao e descartada

As aplicacoes sao instaladas eestao disponıveis no desktopPodem armazenar informacaolocalmente e estao disponıveisoffline

Integracao com odesktop

Integracao com o desktop lim-itada devido a restricoes im-postas pelo browser

As aplicacoes podem acederao sistema de ficheiro ao clip-board eventos notificacoesetc

Controlo da inter-face com o uti-lizador

As aplicacoes sao acedidasatraves de uma janela dobrowser que tem os seusproprios controlos e visualgrafico

As aplicacoes tem um vi-sual grafico proprio em janelapropria

Armazenamentode dados

As aplicacoes tem armazena-mento limitado que pode serreescrito pelo browser

As aplicacoes tem acesso a to-talidade do espaco disponıvellocalmente e a uma base dedados com a possibilidade deencriptacao

Tabela 31 Comparacao das funcionalidades oferecidas pelo Adobe AIR para as platafor-mas web e desktop

30

Estado da arte

Aplicacao Modo de execucao utilizadoGoogle Reader Utiliza o modo ldquoutilizador deciderdquo disponibilizando

ao utilizador um botao para alternar entre os modosonline e offline Como lida com informacao recol-hida de fontes externas de natureza frequentementeefemera o processo de sincronizacao apenas transfereos dois mil itens mais recentes quando passa ao es-tado offline Neste modo sao ainda guardadas in-formacoes de itens lidos e etiquetas atribuıdas quesao sincronizadas com o servidor quando o utilizadorvoltar a activar estado online

Google Docs Utiliza o modo ldquoaplicacao deciderdquo permitindo que outilizador edite os conteudos de documentos de textofolhas de calculo e de apresentacoes independente-mente do estado da ligacao desde o momento em queas funcionalidades offline sao activadas A aplicacaofaz pequenas sincronizacoes com o servidor sempre quenecessario

Remember the Milk Utiliza um modo hıbrido entre ldquoaplicacao deciderdquo eldquoutilizador deciderdquo A aplicacao encarrega-se da sin-cronizacao de dados mas disponibiliza um controlona sua interface que permite despoletar manualmenteeste processo para situacoes em que o utilizador fez al-teracoes recentes e pretende usufruir das capacidadesoffline imediatamente

MySpace O MySpace anunciou a utilizacao de mecanismos dearmazenamento de dados no cliente com recurso atecnologias OWA para melhorar o desempenho doseu cliente web de correio electronico nomeadamenteno que diz respeito a operacoes de pesquisa e or-denacao Inicialmente esta funcionalidade estara ape-nas disponıvel para utilizadores com cinco mil ou maismensagens na sua caixa de correio mas nao e aindaclaro se sera disponibilizada uma versao totalmenteoffline

Tabela 32 Resumo da utilizacao de tecnologias OWA em algumas web applications con-sideradas na analise do estado da arte

31

Estado da arte

32

Capıtulo 4

Desenvolvimento

Neste capıtulo introduz-se a aplicacao WOW e apresenta-se o estudo que foi

feito da adequacao de cada tecnologia para a implementacao da funcionalidade of-

fline nesta plataforma Fazem-se diversas consideracoes sobre opcoes a tomar na

concepcao de OWAs e problemas comuns na sua implementacao bem como sug-

estoes para os resolver O WOW e uma aplicacao ja existente de gestao de ordens

de trabalho e do fluxo de tarefas numa empresa ou organizacao

41 Como ficar offline

Na maior parte das web applications de hoje nao existe uma camada de dados

real A aplicacao exemplificada na Figura 41 ao longo da sua execucao acede

directamente a sua unica fonte de dados (o servidor) atraves de chamadas Ajax sem

que exista uma separacao clara destas duas camadas

Para que uma web application seja capaz de ser executada sem uma ligacao

activa a Internet e mantenha o seu caracter dinamico torna-se necessario incluir

Figura 41 Exemplo de uma arquitectura de uma web application sem uma camada deabstraccao de dados Figura adaptada de http gears google com

33

Desenvolvimento

Figura 42 Exemplo de uma arquitectura de uma web application com uma camada deabstraccao de dados Figura adaptada de http gears google com

um mecanismo de armazenamento de dados local seja uma base de dados ou a

capacidade de acesso ao disco No entanto este mecanismo introduz dois problemas

1 Qual das fontes de dados utilizar quando um utilizador faz um pedido de

informacao

2 A necessidade de implementar uma camada de acesso a dados que seja coerente

quer se use o servidor remoto ou local

Por exemplo em vez de a aplicacao Ajax fazer um pedido relativo as contas de

todos os utilizadores em formato JSON directamente ao servidor remoto podera ao

inves fazer o pedido a um objecto intermedio da camada de dados Este objecto

demonstrado na Figura 42 sera responsavel por implementar uma interface de

acesso a base de dados e retornar um objecto JavaScript com uma representacao da

resposta do servidor

Mas a existencia de uma segunda fonte de dados torna recomendavel tambem

a implementacao de uma camada de data switching que em funcao da existencia

de conexao a Internet e da necessidade de actualizacao dos dados decide se faz o

pedido ao servidor remoto ou se fornece os dados presentes localmente Este objecto

apresentado na Figura 43 decidira de forma transparente para o utilizador se le ou

escreve os dados localmente ou se os enviapede ao servidor remoto e pode tambem

iniciar o processo de convergencia de dados e de resolucao de conflitos

411 Funcionalidades disponıveis em modo offline

Por razoes praticas e provavel que nem todas as funcionalidades da aplicacao

possam ser disponibilizadas em modo offline E necessario escolher quais as fun-

cionalidades a disponibilizar no modo offline da aplicacao e implementar a logica

que decide quando utilizar a base de dados local ou o servidor remoto Apesar do

acesso a base de dados local ser muito mais rapido do que aceder ao servidor o

acesso local nem sempre e preferido Ha varias razoes que podem tornar necessario

escolher o acesso ao servidor em vez do acesso local

34

Desenvolvimento

Figura 43 Exemplo de uma arquitectura de uma web application com uma camada deabstraccao de dados e um data switch Figura adaptada de http gears google com

1 A informacao pode ter uma natureza efemera e nao fazer sentido guarda-la

localmente Exemplo dados em tempo real da bolsa de valores de Lisboa

2 Algumas aplicacoes lidam com informacao que so faz sentido na presenca de

uma ligacao Exemplo Instant Messaging

3 A aplicacao podera escolher apenas guardar a informacao acedida mais fre-

quentemente Exemplo para o utilizador poder alterar a lıngua de apre-

sentacao da aplicacao os conteudos terao que ser guardados em todas as

lınguas disponibilizadas pela aplicacao O custo de implementacao de algu-

mas funcionalidades pode nao compensar o benefıcio

4 A capacidade de processamento ou de armazenamento de dados pode inviabi-

lizar algumas funcionalidades offline Exemplo se uma dada funcionalidade

necessita de uma capacidade de armazenamento de dados para alem do razoavel

de um computador pessoal para ser util (visualizador de mapas)

42 Modos de execucao

Um aspecto que e necessario estudar para qualquer web application que se deseje

disponibilizar offline prende-se com tres modos de execucao que devem ser consid-

erados

1 Utilizador decide o modo de execucao A aplicacao tem modos distintos

de execucao para os estados online e offline geralmente indicados na interface

com o utilizador O utilizador e informado do estado da ligacao e participa na

alteracao de estado de execucao da aplicacao interagindo com a sua interface

2 Aplicacao decide o modo de execucao Pode ser implementado na propria

aplicacao um mecanismo de deteccao do estado da ligacao (por exemplo atraves

35

Desenvolvimento

de chamadas Ajax periodicas) transitando de estado e sincronizando automati-

camente Desta forma o utilizador nao precisa de participar na alteracao de

estado a menos que exista um conflito de dados que requeira a sua atencao

3 Aplicacao assume sempre o estado offline Outra hipotese sera imple-

mentar uma web application que assume sempre estar na ausencia de uma

ligacao ao servidor de dados Esta aplicacao responde aos pedidos do uti-

lizador efectuando pedidos de informacao ao servidor mas nao dependendo

de uma resposta valida para mostrar a informacao que ja tinha disponıvel an-

teriormente A sincronizacao de dados com o servidor e tentada sempre que

existam dados para submeter e uma accao do utilizador

421 Modo ldquoutilizador deciderdquo

Neste modo de execucao quando a aplicacao esta online comunica com o servidor

remoto quando esta offline comunica com a base de dados local A informacao tem

que ser sincronizada sempre que se muda de modo A principal vantagem desta opcao

e que e a mais simples de implementar mesmo para uma aplicacao ja existente e

portanto uma forma expedita de disponibilizar uma OWA No entanto tem tambem

algumas desvantagens que devem ser consideradas

1 O utilizador tem que se lembrar de fazer a alteracao de estado de execucao

Caso contrario podera estar a trabalhar inadvertidamente numa versao offline

com dados antigos ou nao ter a informacao necessaria se perder subitamente

a ligacao

2 Se a ligacao for intermitente o utilizador tera ou que escolher um dos modos

de execucao ou estar constantemente a trocar

3 Uma vez que a base de dados nao esta sempre actualizada nao podera ser

utilizada para melhorar a rapidez de execucao da aplicacao quando em modo

online

422 Modo aplicacao decide

A deteccao do estado da ligacao pode ser implementada atraves de um pedido

assıncrono ao servidor tal como ilustrado na Figura 44 O resultado deste pedido

definira o estado online (em caso de sucesso) ou offline (em caso de falha) A

sincronizacao de dados podera ser feita sempre que ocorra uma transicao do es-

tado offline para o estado online No entanto este metodo nao se revela eficiente

36

Desenvolvimento

Figura 44 Esquema grafico ilustrando uma OWA executando no browser utilizando ummodo de execucao do tipo ldquoaplicacao deciderdquo com deteccao automatica do estado daligacao via pedidos Ajax assıncronos a cada cinco segundos

para grandes aplicacoes uma vez que requer a troca de mensagens demasiado fre-

quentes com o servidor que se destinam exclusivamente a monitorizacao do estado

da ligacao

423 Modo ldquoaplicacao assume o estado offlinerdquo

Uma aplicacao transparente funciona assumindo sempre que esta em modo of-

fline ou pelo menos que pode perder a ligacao a qualquer momento Neste modo

tira-se o maximo partido do armazenamento local e fazem-se pequenas mas contınuas

sincronizacoes com o servidor sempre que este esteja disponıvel A sincronizacao de

dados tambem e feita sempre que se volta ao estado online

As vantagens de uma web application transparente sao as seguintes

bull Uma melhor experiencia para o utilizador uma vez que este nao tem que se

preocupar com o estado da ligacao ou com a transicao de estados

bull A aplicacao funciona de forma coerente mesmo que a ligacao seja intermitente

bull Uma vez que o armazenamento local e mantido actualizado pode ser utilizado

para melhorar o desempenho da aplicacao

Foram identificadas as seguintes desvantagens

bull E mais difıcil de implementar e a sincronizacao acarreta cuidados especiais

bull E necessario um cuidado adicional para evitar que as operacoes de sincronizacao

frequentes que ocorrem automaticamente nao afectem os tempos de resposta

da aplicacao

bull Os testes a aplicacao sao mais complexos uma vez que a sincronizacao de dados

nao ocorre em resposta a uma accao do utilizador

37

Desenvolvimento

43 Sincronizacao de dados

A sincronizacao de dados consiste na capacidade de identificar e transferir pe-

riodicamente a versao mais actual dos dados entre o cliente e o(s) servidor(es)

Independentemente do modo de execucao escolhido e mesmo do estado da ligacao

do utilizador a informacao armazenada localmente e a informacao armazenada no

servidor estarao por vezes dessincronizadas Isto podera acontecer sempre que por

exemplo

bull O utilizador faz alteracoes em modo offline

bull A informacao e partilhada e pode ser alterada por uma entidade externa

bull A informacao e fornecida por uma entidade externa

Resolver estas diferencas de forma a que a informacao local e remota encontrem

a igualdade chama-se sincronizacao de dados Ha varias aproximacoes possıveis

para este efeito que dependem da natureza da aplicacao cada uma com vantagens

e desvantagens

A capacidade de suportar a mobilidade dos utilizadores torna-se cada vez um

ponto mais importante de uma web application Para uma organizacao de dimensao

global e vital garantir que os seus colaboradores tem acesso a mesma informacao

que tem disponıvel nos seus postos de trabalho mesmo quando estao fora Na maior

parte dos casos estes colaboradores terao acesso a um computador portatil um

desktop Smartphone ou PDA e atraves destes poderao ter acesso a sua informacao

directamente atraves de ligacoes encriptadas Virtual Private Network (VPN) de um

servidor web ou de outro mecanismo de rede

Esta solucao e simples de implementar mas infelizmente para a maioria dos

colaboradores com grande factor de mobilidade nao e satisfatoria As principais

desvantagens sao as seguintes

bull Requisitos de ligacao Para permitir que os utilizadores acedam a sua in-

formacao e necessario garantir a capacidade constante de comunicacao pelo

menos durante o tempo necessario que assegure a sua transferencia

bull Velocidade de ligacao sem persistencia de dados e em ligacoes de fraca

qualidade a usabilidade por vezes torna-se inaceitavel

bull Ponto crıtico de falha Com este tipo de solucao todos os utilizadores de-

pendem da base de dados que armazena informacao vital para o funcionamento

do cliente

38

Desenvolvimento

bull Scalability do servidor A medida que novos utilizadores sao adicionados ao

sistema o desempenho do servidor e afectado levando a necessidade de maior

capacidade de armazenamento eou processamento

De acordo com a documentacao da Microsoft Sync Framework [Mic08] uma

solucao alternativa consiste em implementar uma Occasionally Connected Appli-

cation (OCA) Uma OCA permite a um utilizador remoto continuar a aceder a

sua informacao mesmo depois de perder a ligacao mas em vez de recorrer a um

servidor recorre a informacao armazenada no seu dispositivo local Para preencher

localmente a informacao que o utilizador necessita uma OCA possui mecanismos

de sincronizacao de dados que sao oferecidos por esta framework

431 Quando sincronizar

Uma das solucoes mais simples de implementar passa por disponibilizar um

mecanismo manual que despoleta a sincronizacao Diz-se manual porque e o uti-

lizador que escolhe quando sincronizar e pode ser implementada simplesmente

fazendo o upload de toda a informacao para o servidor e depois fazendo o download

da copia mais recente da informacao antes de voltar a ficar offline Para que esta

seja uma opcao viavel e necessario que

bull O volume de dados seja suficientemente pequeno para que possa ser transferido

do servidor para o cliente num espaco de tempo aceitavel

bull Que o utilizador indique explicitamente que quer mudar para o estado offline

ou online pressionando um botao da interface

Contudo podem ser identificados alguns problemas relacionados com esta abor-

dagem

bull Os utilizadores nem sempre podem prever o estado das suas ligacoes A ligacao

pode-se perder subitamente ou ter um caracter intermitente

bull O utilizador pode esquecer-se de efectuar a sincronizacao

Outra opcao sera conjugar a sincronizacao de dados com o modo de execucao

transparente A sincronizacao ocorre automaticamente em background de forma

nao intrusiva para o utilizador A aplicacao comunica com o servidor regularmente

efectuando pequenas trocas de dados com o objectivo de manter o sincronismo da

informacao local e remota Esta abordagem pode ser implementada com pedidos

Ajax assıncronos e regulares ao servidor o que permite manter a interaccao com a

interface fluıda evitando bloqueios Estes pedidos sao feitos prevendo as situacoes

39

Desenvolvimento

de disponibilidade ou indisponibilidade (timeout) do servidor Uma outra opcao

sera permitir que o servidor comunique essas alteracoes utilizando Comet1 tal como

descrito em [Wil06] e [Rus06] As vantagens destas aproximacoes sao

bull A informacao esta disponıvel a qualquer altura que o utilizador decida ficar

offline ou que a ligacao seja acidentalmente perdida

bull O desempenho da aplicacao pode ser melhorado quando se estiver a utilizar

uma ligacao a Internet lenta uma vez que o acesso a dados locais e mais

eficiente do que a consulta de dados ao servidor

44 WOW

O WOW e uma plataforma integrada de gestao de ordens de trabalho ja ex-

istente e desenvolvida pela Critical Software SA a qual se pretende adicionar a

capacidade de execucao offline Esta aplicacao e extremamente dinamica e con-

figuravel com um conjunto extremamente rico de funcionalidades das quais se

destacam

bull Gestao de Ordens de Trabalho ndash suportando a gestao dos pedidos desde a

sua criacao ate ao seu fecho tomando em conta os diferentes tipos de pedidos

(ordens de trabalho pedidos de informacao melhorias resolucao de problemas

etc) e diferentes tipos de accoes possıveis para cada um (Figura 45)

bull Monitorizacao de alteracoes ndash Historico de mudancas anexos e estados criando

relatorios de alteracao automaticamente (o que por quem e quando)

bull Uso de Service Level Agreements (SLAs) ndash E possıvel associar a um pedido um

SLA que define qual o perıodo de tempo atribuıdo a resolucao de um pedido

controlando e agilizando a resolucao do mesmo

bull Utilizacao de queries de utilizador configuraveis que permitem acesso rapido

a determinadas ordens de trabalho de acordo com o filtro configurado (por

exemplo ldquoPara mimrdquo ldquoPara o Grupordquo ldquoPelo Grupordquo)

bull Gestao do relacionamento entre pedidos

bull Pesquisa e filtragem de ordens de trabalho

bull Exportacao de dados em formatos padrao (PDF DOC ou XLS)

bull Integravel com solucoes externas

40

Desenvolvimento

Figura 45 Detalhe de um conjunto possıvel de estados e respectivas transicoes para umadada ordem de trabalho no WOW desde a sua submissao no sistema ate a sua conclusaoem fecho ou cancelamento Esta figura representa apenas um exemplo ja que o mapa deestados para uma ordem de trabalho e dinamico e pode ser alterado por um administradorFigura retirada de uma brochura promocional do WOW Critical Software SA

A utilizacao de uma ferramenta deste tipo por parte de uma empresa ou orga-

nizacao oferece vantagens quer a gestao de topo quer aos colaboradores individuais

para os colaboradores individuais o WOW e uma aplicacao onde estao registadas

todas as tarefas contribuindo activamente para o desenvolvimento em ambientes

multi-tarefa e para a organizacao pessoal das tarefas de acordo com prioridades

Para a gestao de topo esta ferramenta permite obter uma visao global do estado da

organizacao em termos de tempo gasto por tarefa executada sendo uma mais valia

para a previsao e gestaoalocacao de recursos

45 Visao geral sobre a arquitectura do WOW

O WOW e interessante nao so do ponto de vista de produto como tambem do

ponto de vista de plataforma Existem diversos plug-ins que estendem as funcional-

idades do WOW e existem ate projectos que pretendem usar a arquitectura do

WOW para criar produtos com fins diferentes do inicial (por exemplo o WOW-

Storm ndash um sistema de registo e classificacao social de ideias)

De modo a conseguir ter essa expansibilidade a plataforma WOW assenta sob

uma arquitectura distribuıda modular e expansıvel com uma componente central

ndash o core ndash estruturado em camadas logicas E no core que se situam todas as

1O Comet e um conceito semelhante ao Ajax introduzido por Alex Russel mas no qual e o servidor quetoma a iniciativa de ldquoenviarrdquo os dados ao browser sem que este tenha que efectuar um pedido Tambem econhecido por Ajax Push Reverse Ajax ou HTTP Streaming

41

Desenvolvimento

funcionalidades base da aplicacao quer a nıvel logico funcional e de apresentacao

quer a nıvel de gestao e configuracao

E possıvel a execucao de varias instancias do core simultaneamente em servidores

distintos o que permite a alta escalabilidade e disponibilidade desta aplicacao A

consistencia dos dados fica sempre garantida atraves da partilha da base de dados

e pelo balanceamento dos pedidos uma vez que cada um e encaminhado para uma

unica instancia

O WOW apresenta tambem a vantagem de ser uma plataforma extensıvel E

possıvel adicionar novas caracterısticas a plataforma atraves de componentes que se

podem ser divididos em duas categorias plugins e connectors

Os plugins sao componentes que se encontram no mesmo no fısico que a aplicacao

partilhando do mesmo contexto de execucao do core Sao assim uma forma mais

directa de obter informacao da plataforma visto que nao possuem restricoes de

acesso aos dados nem dependencias externas A arquitectura deste componente tera

assim que permitir varias execucoes instanciadas cada uma associada a um core

Por outro lado os connectors sao componentes que se encontram distribuıdos

comunicando externamente com o core Quer a sua execucao quer a obtencao

dos dados estao assim dependentes de interfaces de comunicacao externas que a

plataforma disponibiliza Estes componentes ao contrario dos plugins sao instan-

ciados unicamente e recorrem ao protocolo de comunicacao Java Messaging Service

(JMS) para comunicar com o core

46 WOW Offline

Para alem das opcoes tomadas relativamente a tecnologia a utilizar surgiu

tambem a necessidade de optar por um dos modos de execucao apresentados na

seccao 42

Das tres opcoes possıveis foi o modo ldquoaplicacao assume o estado offlinerdquo descrito

na seccao 423 que mereceu a maior atencao uma vez que reune as vantagens de

uma experiencia mais positiva para o utilizador (uma vez que este nao tem que

participar activamente na alteracao do modo execucao como descrito na seccao 421)

e nao constitui uma sobrecarga excessiva para servidor (como o modo abordado na

seccao 422)

No entanto esta opcao comprometia a complexidade da implementacao para alem

dos objectivos propostos para este projecto e para cumprir o prazo dado foi tomada

a decisao de implementar o modo ldquoutilizador deciderdquo especificando apenas de forma

teorica o modo ldquoaplicacao assume o estado offlinerdquo

As caracterısticas do Gears foram ja descritas na seccao 31 Na Figura 47

mostra-se a sua forma de funcionamento quando integrado numa web application

42

Desenvolvimento

Nesta figura representa-se o modulo LocalServer do Gears como um ponto de de-

cisao Aqui sao testadas as condicoes que determinam se o pedido sera interceptado e

servido localmente ou se prossegue para uma maquina remota E tambem represen-

tada uma base de dados que corresponde ao modulo Database mas que podera nao

ser utilizada Este modulo tal como o modulo Workerpool tem caracter opcional

e sao utilizados consoante os requisitos da aplicacao

A plataforma WOW lida com mais dados do que e necessario passar para o

lado do cliente Em conformidade com o ja exposto na seccao 411 volta-se a

frisar que nao se pretende recriar toda a logica de negocio nem os conteudos da

base de dados no cliente pela sua complexidade e volume de dados Pretende-se

pelo contrario permitir que os utilizadores tirem partido da capacidade de poder

consultar as suas ordens de trabalho quando nao dispoe de uma ligacao transferindo

apenas o essencial para isto seja possıvel

A pagina inicial do WOW apresenta um resumo das ordens de trabalho abertas

ndash enviadas e recebidas ndash que se pretende permitir visualizar offline (ver Figura 46)

Como prova de conceito foi efectuada uma abordagem pragmatica das varias possi-

bilidades descritas na seccao 42

461 Modo ldquoaplicacao deciderdquo com deteccao automatica da ligacao

A primeira abordagem estudada para a disponibilizacao das funcionalidades of-

fline foi o modo ldquoaplicacao deciderdquo com deteccao automatica de ligacao apresentado

na seccao 422 Para que isto seja possıvel foi implementado um mecanismo de ver-

ificacao periodica do estado da ligacao atraves de chamadas Ajax assıncronas O

resultado destes pedidos determina o estado da aplicacao executando as tarefas de

sincronizacao de dados sempre que pertinente Este metodo embora imediato e

simples de implementar depressa se revelou inadequado para o projecto devido ao

elevado consumo de recursos do servidor que a utilizacao intensiva faz esperar a

comunidade da plataforma WOW no principal cliente excede os 7000 utilizadores

Foi estimado que para uma utilizacao de fluidez aceitavel o estado da ligacao deveria

ser testado a cada cinco segundos Assumindo uma adesao (previsao pessimista) de

1 aos servicos offline assistir-se-ia a cerca de 840 pedidos adicionais por minuto

Mas o principal problema desta aproximacao prende-se com o facto de a ver-

ificacao ser feita em intervalos de tempo discretos levando a possibilidade de a

aplicacao poder ter em dado momento uma representacao errada do seu estado

real da ligacao Este problema e ilustrado na Figura 48 onde se ve claramente a

discrepancia entre o estado real da ligacao e a representacao interna que esta tem

Note-se que nesta janela de tempo qualquer accao do utilizador que exija uma

resposta sıncrona do utilizador leva-lo-a para um ldquobeco sem saıdardquo onde nao tera

43

Desenvolvimento

Figura 46 A pagina inicial do WOW apresenta um resumo das ultimas ordens de trabalhoenviadas e recebidas Na imagem pode-se observar a transicao do estado online para offline

acesso a versao offline porque a aplicacao nao fez a transicao automatica nem acesso

a versao online porque na verdade nao possui uma ligacao O que acontecera nesta

situacao sera uma tentativa de acesso ao servidor por parte da aplicacao numa

altura em que este se encontra indisponıvel e o resultado sera uma mensagem de

ldquopedido excedeu o tempordquo apresentado pelo browser Este e um estado sem retorno

porque apos o browser apresentar esta mensagem todos os recursos JavaScript ficam

indisponıveis tornando impossıvel o regresso ao estado anterior ou o tratamento do

erro de qualquer outra forma No entanto as chamadas Ajax podem ser tratadas de

forma especial para a eventualidade de falha e portanto nao constituem problema

44

Desenvolvimento

Figura 47 Ilustracao do funcionamento do Gears numa web application que utiliza ummotor Ajax Os pedidos HTTP ou HTTPS podem ser interceptados e tratados localmenteou podem ser feitos a uma maquina remota consoante se verificarem ou nao as condicoesexpressas no ponto 311 E representado um acesso a uma base de dados local (fornecidapelo Gears) mas a sua utilizacao e opcional

462 Implementacao do modo ldquoutilizador deciderdquo

Este modo de execucao foi ja descrito na seccao 421 e a sua principal carac-

terıstica e ser o utilizador a decidir se a aplicacao deve utilizar um servidor remoto

ou a maquina local como fornecedor de dados

Relativamente ao WOW o WOW Offline na vertente ldquoutilizador deciderdquo vem

alterar os seus casos de uso dando ao utilizador a possibilidade de alterar o estado

de execucao da aplicacao (entre online e offline) Resta dizer que no modo online se

mantem todas as funcionalidades anteriores e que no modo offline torna-se possıvel

visualizar os conteudos da pagina principal do WOW (Figura 46) e os detalhes das

ordens de trabalho (Figura 49) tal como expressa a Figura 410

Esta aproximacao foi utilizada na prova de conceito do WOW adicionando um

controlo a interface desta aplicacao que permite ao utilizador alternar entre os esta-

dos online e offline Na transicao de online para offline sao descarregados os recursos

necessarios para a execucao desta aplicacao sem recorrer a Internet Para o fazer

45

Desenvolvimento

Figura 48 Neste exemplo do modo ldquoaplicacao deciderdquo o teste da ligacao e feito e feito acada cinco segundos O resultado deste teste nao reflecte sempre o estado real da aplicacaopodendo levar a aplicacao a ter comportamentos indesejaveis Na figura assinala-se umperıodo de tempo no qual a representacao interna do estado da ligacao nao corresponde arealidade

e utilizado um recurso ResourceStore e um ManagedResourceStore (introduzidos

em 311) O primeiro e utilizado para armazenar a pagina principal do WOW ndash do-

ravante designada por homejsp ndash e o segundo e utilizado para armazenar imagens

folhas de estilo CSS e scripts JavaScript

Para a implementacao deste modo de execucao foram identificadas as seguintes

tarefas

1 Guardar informacao que permita a recriacao das paginas que se pretende

disponibilizar offline (utilizando o Gears)

2 Disponibilizar um controlo que permita alterar o estado de execucao atraves

da interaccao com a pagina principal

3 Durante a sincronizacao de dados apresentar o progresso da transferencia de

dados

O primeiro passo consistiu na identificacao de todos os conteudos que sao necessarios

transferir para a execucao offline Foi utilizado um recurso do Gears do tipo

ManagedResourceStore que recorre a um ficheiro manifesto para identificar to-

dos os ficheiros que deve transferir Este recurso e gerido automaticamente pelo

Gears transferindo para o cliente a versao mais recente sempre que e necessario

isto e sempre que exista um ficheiro manifesto com uma identificacao de versao que

seja diferente da actualmente disponıvel no cliente Uma vez identificados todos

ficheiros necessarios para a execucao offline num (ou mais) ficheiros manifesto o

Gears encarrega-se da sua actualizacao mas o preenchimento destes ficheiros man-

ifesto e manual o que se traduz num cuidado extra na manutencao da aplicacao

A forma como esta informacao e guardada deve tambem ser cuidadosamente

estudada A opcao mais flexıvel passa por utilizar o modulo Database apresentado

na seccao 311 e guardar a informacao de uma forma relacional Para a recriacao

das paginas pode ser disponibilizada uma versao HTML da pagina que funciona

46

Desenvolvimento

Figura 49 Pagina de visualizacao do detalhe de uma ordem de trabalho

como template nao possui quaisquer dados e e utilizada apenas em modo offline E

preenchida para cada pedido retirando os dados relevantes da base de dados

O modelo de dados do WOW torna esta opcao extremamente trabalhosa uma

vez que as entidades envolvidas na geracao de cada pagina de informacao sobre

cada ordem de trabalho tem relacoes de dependencia complexas seguindo padroes

muito variaveis Por exemplo em cada ordem de trabalho existe um formulario que

permite a sua progressao de estado com diversos campos opcionais e obrigatorios

este formulario e definido pelo administrador e esta relacionado nao apenas com o

tipo de ordem de trabalho mas tambem com o estado actual em que esta se encontra

e a accao que se pretende realizar O elevado numero de combinacoes de tipos de

ordem de trabalho estados e accoes que existem num dado momento juntamente

com a sua possibilidade de alteracao obrigariam a implementacao de uma logica de

negocio complexa o que esta fora do ambito deste projecto

47

Desenvolvimento

Figura 410 Esquema UML que expressa os casos de uso do WOW Offline no modoldquoutilizador deciderdquo

463 Especificacao do modo ldquoaplicacao assume o estado offlinerdquo

A aproximacao para o modo ldquoaplicacao assume o estado offlinerdquo foi tambem

dividida em varias tarefas

1 Guardar informacao que permita a recriacao da pagina principal do lado do

cliente no estado offline (utilizando o Gears)

2 Dotar a aplicacao do cliente de um mecanismo de deteccao da ligacao

3 Identificar os ldquomomentos chaverdquo em que devera ocorrer sincronizacao de dados

4 Implementar a sincronizacao de dados

A sincronizacao de dados deve ser feita em ambas as transicoes online-offline e

offline-online quer para transferir novos dados do servidor (os pedidos podem ser

alterados por outros utilizadores) quando se transita do estado quer para comunicar

eventuais alteracoes feitas em modo offline

Relativamente ao WOW o WOW Offline na vertente ldquoaplicacao assume o es-

tado offlinerdquo vem alterar os seus casos de uso dando ao utilizador a possibilidade

de activar esta funcionalidade A partir do momento que a funcionalidade esta ac-

tivada o utilizador deve tambem ter a possibilidade de gerir algumas preferencias

relacionadas com privacidade de dados Devera ter a hipotese de desactivar o ar-

mazenamento local e de remover todos os dados ja armazenados tal como descrito

na Figura 411

48

Desenvolvimento

Figura 411 Esquema UML que expressa os casos de uso do WOW Offline no modoldquoutilizador deciderdquo

A primeira vez que o WOW Offline e acedido por um cliente e caso seja detec-

tada a presenca do Gears todos os recursos necessarios a sua execucao sao trans-

feridos Todos os acessos posteriores serao feitos a estes recursos locais (recorda-se

que o Gears pode ser utilizado para os manter actualizados recorrendo ao Managed-

ResourceStore 311)

Atraves do JavaScript e possıvel interceptar os eventos de load e unload da

pagina que sao despoletados sempre que ocorre um re-acesso da mesma (incluindo

a accao refresh comum dos browsers) sempre que esta e abandonada ou ainda ou

ainda se a janela for encerrada

Tal como sugerido na seccao 462 a camada de interface desta aplicacao (cada

pagina individual em HTML) devera ser implementada como sendo um template

para apresentacao de dados sendo totalmente preenchida atraves de funcoes em

JavaScript O objectivo deste ponto e criar um padrao de dados que permita ao

JavaScript preencher os dados em cada pagina (template) independentemente de

qual seja a fonte ndash o servidor remoto ou a maquina local tal como exemplificado

no diagrama da Figura 412 Na figura a aplicacao recorre ao servidor remoto para

obter os dados pretendidos quando se encontra na presenca de uma ligacao mas

para dados que exijam uma carga de processamento pelo servidor este acto pode ser

49

Desenvolvimento

Figura 412 Esquema UML que expressa o acto de recolha de dados em modo online eoffline recorrendo ao servidor (modo online) e ao sistema de armazenamento de dadoslocal fornecido pelo Gears (modo offline)

substituıdo pelo envio de um campo de controlo que se destina a aferir se os dados

locais se encontram actualizados No caso de estarem actualizados a comunicacao

com o servidor pode ser substituıda por uma query a base de dados local

50

Capıtulo 5

Resultados e Futuros

Desenvolvimentos

Todo o estudo feito sobre o tema OWA foi ja abordado ao longo do documento

Neste capıtulo apresentam-se os resultados obtidos na implementacao da prova de

conceito que visava compreender a melhor forma de disponibilizar uma versao of-

fline no WOW uma plataforma de gestao de ordens de trabalho ja existente de-

senvolvida pela Critical Software SA

51 Resultados Obtidos

Os resultados obtidos neste projecto sao extremamente satisfatorios uma vez

que o estudo do tema OWA e a implementacao de uma prova de conceito que o

ilustrasse foi conseguido com sucesso

A funcionalidade offline foi adicionada ao produto WOW da Critical Software

SA permitindo a visualizacao de ordens de trabalho e dos seus detalhes mesmo na

ausencia de uma conexao activa a Internet Embora para a solucao implementada

tenha sido utilizada uma abordagem do tipo ldquoutilizador deciderdquo pretende-se que esta

seja convertida para ldquoaplicacao deciderdquo ou mesmo para uma aproximacao hıbrida

semelhante a utilizada pelas aplicacoes estudadas nas seccoes 351 e 352

Para a sua implementacao descrita no capıtulo 4 foram tomadas decisoes de or-

dem pratica que permitissem tornar o trabalho exequıvel nos prazos dados Tentou-

se sempre que estas decisoes afectassem o mınimo em termos de desempenho e de

experiencia para o utilizador Considera-se que a implementacao do modo offline

com uma transicao entre modos do tipo ldquoutilizador deciderdquo (ver seccao 42) reflecte

o compromisso entre o desempenho pretendido e os recursos disponıveis e para alem

51

Resultados e Futuros Desenvolvimentos

de ser um exemplo eficaz das possibilidades que as OWA podem trazer a aplicacao

WOW desenvolvida pela Critical Software e tambem um estudo que pode ser uti-

lizado para analisar a implementacao desta tecnologia noutros produtos da mesma

empresa

Note-se que o principal objectivo do trabalho era ganhar familiaridade com este

tema entender as suas vantagens e desvantagens e compreender as suas limitacoes

Tudo indica que existam varias possibilidades de implementacao deste paradigma

noutros produtos da Critical Software que pela sua natureza podem tambem tirar

partido da execucao offline

52 Trabalho Futuro

O desenvolvimento do conceito e formas de implementacao de OWA continua

em forte desenvolvimento no entanto a sua adopcao ainda nao e generalizada A

dificuldade da sua implementacao em web applications ja existentes e o principal

obstaculo a sua maior divulgacao

Ha tambem um factor que deve ser tido em consideracao a manutencao de

codigo A implementacao de uma versao offline de uma web application requer

a implementacao das mesmas regras de negocio (ou de uma versao simplificada)

utilizadas no servidor Para que isto seja possıvel e necessario ter em conta a

capacidade de processamento do cliente e o factor de duplicacao de codigo que

tornara a aplicacao mais difıcil de manter uma vez que uma alteracao a logica de

negocio do servidor implica tambem uma alteracao a sua versao offline

A prova de conceito implementada permite ja a visualizacao offline dos pedidos

abertos (enviados e recebidos) que constam na pagina principal (este numero e

fixo e pode ser alterado pelo administrador) Uma funcionalidade desejavel seria a

possibilidade de interaccao com a aplicacao em modo offline e sincronizacao com o

servidor quando existisse uma ligacao disponıvel

Foi estudada a utilizacao do modo de execucao ldquoaplicacao assume o estado of-

flinerdquo descrito em 423 e esta seria a forma desejavel para o WOW Offline no

entanto para que esta opcao seja viavel sera necessaria a implementacao de uma

forma eficiente de sincronizacao e armazenamento de dados de uma forma relacional

Para atingir este objectivo podera ser seguida uma polıtica de automacao do pro-

cesso no qual a versao online da aplicacao gera scripts de criacao para as tabelas

necessarias na base de dados da versao offline (nao existe nenhuma ferramenta para

o fazer portanto seria necessaria a sua implementacao) e no qual as paginas HTML

disponibilizadas pelo servidor aos clientes web (browser) servem como templates de

apresentacao de informacao e sao preenchidas de forma semelhante pelo servidor ndash

quando a aplicacao estiver online ndash ou pelo cliente atraves de funcoes em JavaScript

52

Resultados e Futuros Desenvolvimentos

ndash quando a aplicacao estiver offline No entanto no WOW devido a quantidade de

informacao tratada e devido as complexas relacoes entre as diferentes entidades e

de esperar que a complexidade da implementacao de um mecanismo deste tipo torne

esta aproximacao demasiado custosa

O HTML 5 embora um forte candidato ainda nao esta suficientemente desen-

volvido A sua especificacao ainda tem o caracter de Draft (rascunho) e esta sujeita

a modificacoes e a aceitacao e implementacao por parte dos browsers e portanto

de momento foi desconsiderado No entanto no futuro se esta especificacao atingir

um estado de maturidade que permita a sua adopcao devera ser considerada como

um possıvel caminho a seguir

53

Resultados e Futuros Desenvolvimentos

54

Capıtulo 6

Conclusoes

Neste capıtulo sao apresentadas as conclusoes do projecto e consideracoes finais

relativamente a tecnologia estudada

61 Conclusoes

O rapido desenvolvimento tecnologico faz prever que a disponibilidade de ligacao

a Internet seja cada vez mais facil e mais rapido mas vao continuar a existir lugares

onde o acesso e limitado e onde as OWA podem desempenhar um papel de relevo

Por outro lado esta tecnologia pode tambem ser utilizada para melhorar o desem-

penho de paginas web com uma necessidade elevada de imagens ou outros recursos

dispendiosos em termos de espaco e foram ate estudados dois exemplos da utilizacao

desta vertente desta tecnologia em 353

Acredita-se que as OWAs vem responder a uma necessidade real por parte das

web applications actuais e que a evolucao que representam se compara a que se

assistiu dos thin-clients para os fat-clients em termos de autonomia do servidor

A capacidade de oferecer conteudos dinamicos no browser independentemente da

existencia de uma ligacao reune as vantagens tıpicas das web applications como

ausencia de instalacao e actualizacoes instantaneas com as vantagens das aplicacoes

de desktop em capacidade de processamento e armazenamento de dados na maquina

local

As tecnologias disponıveis ate a data estudadas no ambito deste projecto que

permitem o desenvolvimento de OWAs e que apresentam maior maturidade sao o

Gears e o Adobe AIR Ambas se apresentam sobre a forma de plugins que necessitam

de uma instalacao extra para poderem ser utilizadas Apesar de esta instalacao ser

55

Conclusoes

apenas necessaria uma vez podera constituir um factor de desencorajamento a sua

adopcao

O HTML 5 uma especificacao abordada neste documento na seccao 34 podera

ser uma alternativa que oferece funcionalidades offline a uma web application sem a

necessidade de qualquer instalacao no entanto esta especificacao ainda nao foi aceite

pelos principais browsers ndash o documento que define o HTML 5 ainda tem o estatuto

de Draft ndash e ainda nao e possıvel antecipar quando e que isto podera acontecer

Um dos problemas que surge frequentemente na implementacao de uma versao

offline para uma web application e a necessidade de sincronizacao de dados Quando

a informacao pode ser alterada por varios utilizadores simultaneamente e necessario

prever os conflitos que daı podem surgir e dotar a aplicacao de uma forma de os

resolver ou alertar o utilizador para a necessidade de alteracao dos dados

Em conclusao todos os objectivos propostos para este projecto foram atingidos

A prova de conceito implementada reflecte de forma clara as possibilidades oferecidas

pela tecnologia OWA e sera utilizado no futuro para compreender a melhor forma

de o implementar de forma definitiva no WOW

56

Referencias

[Ada08] Lucas Adamski Introducing Adobe AIR security model Fevereiro de2008 Disponıvel em httpwwwadobecomdevnetairarticles

introduction_to_air_securityhtml acedido em Marco de 2008

[Ado08] Adobe Adobe AIR 10 Security White Paper 2008 Disponıvel emhttpdownloadmacromediacompubairdocumentation1air_

securitypdf acedido em Marco de 2008

[Alm08] Dion Almaer Gears as a bleeding-edge html 5 implementa-tion March 2008 Disponıvel em httpalmaercomblog

gears-as-a-bleeding-edge-html-5-implementation acedido emMarco de 2008

[BL96] Tim Berners-Lee The world wide web Past present and future Agostode 1996 Disponıvel em httpwwww3orgPeopleBerners-Lee

1996ppfhtml acedido em Abril de 2008

[CDGH08] Mike Chambers Daniel Dura Dragos Georgita and Kevin Hoyt AdobeAIR for JavaScript Developers OrsquoReilly Media 2008 Disponıvel emhttponairadobecomfilesAIRforJSDevPocketGuidepdf ace-dido em Abril de 2008

[Con99] Jim Conallen Modeling Web Application Architectures with UML Junho1999 Disponıvel em httpwwwumlorgcnUMLApplicationpdf

webappspdf acedido em Maio de 2008

[Ent07] Entrust What is a public key information 2007 Disponıvel em http

wwwentrustcompkihtm acedido em Junho de 2008

[Gar05] Jesse James Garret Ajax A new approach to web applicationsFebruary 2005 Disponıvel em httpwwwadaptivepathcomideas

essaysarchives000385php acedido em Marco de 2008

[Greon] Philip Greenspun Philip and Alexrsquos Guide to Web Publishing 2003(last revision) Disponıvel em httpphilipgreenspuncompandaacedido em Junho de 2008

[Gro02a] App Design Group Thick vs thin client comparison 2002 Disponıvelem httpwwwdonjacobsvwcomimagesweekendspecials

Thick-vs-Thinpdf acedido em Junho de 2008

57

REFERENCIAS

[Gro02b] Technical Research Group Thin Client Tecnhology - WhitePaper 2002 Disponıvel em httpwwwpicktrgcompubs

thinclientwhitepaperpdf acedido em Junho de 2008

[Gro08] Miniwatts Marketing Group World internet usage March 2008Disponıvel em httpwwwinternetworldstatscomstatshtm ace-dido em Abril de 2008

[Hic08] Ian Hickson HTML 5 Draft Recommendation 2008 Disponıvelem httpwwwwhatwgorgspecsweb-appscurrent-work ace-dido em Marco de 2008

[Kha] Olga Kharif Top 10 municipal wifi plans Disponıvel em http

imagesbusinessweekcomss0608muni_wifiindex_01htm ace-dido em Marco de 2008

[Lab07] Mozilla Labs Prism Outubro 2007 Disponıvel em httplabs

mozillacom200710prism acedido em Marco de 2008

[Loo06] Chris Loosley Rich Internet ApplicationsDesign MeasurementandManagement Challenges 2006 Disponıvel em httpwwwkeynote

comdocswhitepapersRichInternet_5pdf acedido em Maio de2008

[Mic08] Microsoft Introduction to Occasionally Connected Applications us-ing Sync Services for ADONET 2008 Disponıvel em httpmsdn

microsoftcomen-ussyncbb887608aspx acedido em Junho de2008

[Nao08] Erica Naone Offline web applications Abril 2008 Disponıvelem httpwwwtechnologyreviewcomread_articleaspxch=

specialsectionsampsc=emerging08ampid=20245 acedido emAbril de 2008

[NJN00] Jason Nieh Yang S Jae and Naomi Novik A comparison of thin-clientcomputing architectures 2000 Disponıvel em httpwwwnclcs

columbiaedupublicationscucs-022-00pdf acedido em Maio de2008

[OrsquoR06] Tim OrsquoReilly Web 20 compact definition Trying again Dezembro2006 Disponıvel em httpradaroreillycomarchives200612

web-20-compact-definition-tryihtml acedido em Marco de 2008

[OrsquoR09] Tim OrsquoReilly What is Web 20 Design patterns and business modelsfor the Next Generation of Software 20053009 Disponıvel emhttpwwworeillynetcompubaoreillytimnews200509

30what-is-web-20html acedido em Marco de 2008

[Rus06] Alex Russel Comet Low latency data for the browser March Marco2006 Disponıvel em httpalexdojotoolkitorgp=545 acedidoem Marco de 2008

58

REFERENCIAS

[Sad97] Darleen Sadoski Clientserver software architecturesndashan overviewAgosto 1997 Disponıvel em httpwwwseicmuedustr

descriptionsclientserver_bodyhtml acedido em Junho de2008

[Sch96] George Schussel Clientserver past present and future 1996

[Smi07] Kevin C Smith Css filters - will the browser apply the rule July 2007Disponıvel em httpcentriclecomrefcssfilters acedido emMarco de 2008

[vK08] Anne van Kesteren The XMLHttpRequest Object W3C Work-ing Draft 15 Abril 2008 Disponıvel em httpwwww3orgTR

XMLHttpRequest acedido em Abril de 2008

[Wil06] Greg Wilkins Why ajax comet July Julho 2006 Disponıvel emhttpwwwwebtidecomdownloadswhitePaperWhyAjaxhtml ace-dido em Abril de 2008

59

REFERENCIAS

60

Anexo A

Screenshots

Algumas imagens de aplicacoes que utilizam funcionalidades offline ilustrativasda tecnologia abordada neste documento

Figura A1 Dialogo apresentado ao utilizador na primeira activacao das funcionalidadesoffline no Google Docs amp Spreadsheets

61

Screenshots

Figura A2 Na activacao das funcionalidades offline e tambem oferecida a possibilidadeda criacao de alguns atalhos por exemplo no ambiente de trabalho

Figura A3 O Google Docs mantem a todo o momento a possibilidade de alteracao destasdefinicoes ou da anulacao dos servicos offline para um dado computador

62

Screenshots

Figura A4 Apos a instalacao do Gears qualquer visita ao Remember The Milk despoletauma sincronizacao que ocorre automaticamente e sem necessidade de intervencao por partedo utilizador

Figura A5 Apos completar a sincronizacao de dados mesmo que a ligacao a Internetseja perdida o Remember the Milk continua disponıvel no browser (com excepcao dasfuncionalidades que pela sua natureza exigem uma ligacao como por exemplo partilhade tarefas e envio de convites)

63

Page 17: O ine Web Applications
Page 18: O ine Web Applications
Page 19: O ine Web Applications
Page 20: O ine Web Applications
Page 21: O ine Web Applications
Page 22: O ine Web Applications
Page 23: O ine Web Applications
Page 24: O ine Web Applications
Page 25: O ine Web Applications
Page 26: O ine Web Applications
Page 27: O ine Web Applications
Page 28: O ine Web Applications
Page 29: O ine Web Applications
Page 30: O ine Web Applications
Page 31: O ine Web Applications
Page 32: O ine Web Applications
Page 33: O ine Web Applications
Page 34: O ine Web Applications
Page 35: O ine Web Applications
Page 36: O ine Web Applications
Page 37: O ine Web Applications
Page 38: O ine Web Applications
Page 39: O ine Web Applications
Page 40: O ine Web Applications
Page 41: O ine Web Applications
Page 42: O ine Web Applications
Page 43: O ine Web Applications
Page 44: O ine Web Applications
Page 45: O ine Web Applications
Page 46: O ine Web Applications
Page 47: O ine Web Applications
Page 48: O ine Web Applications
Page 49: O ine Web Applications
Page 50: O ine Web Applications
Page 51: O ine Web Applications
Page 52: O ine Web Applications
Page 53: O ine Web Applications
Page 54: O ine Web Applications
Page 55: O ine Web Applications
Page 56: O ine Web Applications
Page 57: O ine Web Applications
Page 58: O ine Web Applications
Page 59: O ine Web Applications
Page 60: O ine Web Applications
Page 61: O ine Web Applications
Page 62: O ine Web Applications
Page 63: O ine Web Applications
Page 64: O ine Web Applications
Page 65: O ine Web Applications
Page 66: O ine Web Applications
Page 67: O ine Web Applications
Page 68: O ine Web Applications
Page 69: O ine Web Applications
Page 70: O ine Web Applications
Page 71: O ine Web Applications
Page 72: O ine Web Applications
Page 73: O ine Web Applications
Page 74: O ine Web Applications
Page 75: O ine Web Applications
Page 76: O ine Web Applications
Page 77: O ine Web Applications
Page 78: O ine Web Applications
Page 79: O ine Web Applications
Page 80: O ine Web Applications
Page 81: O ine Web Applications
Page 82: O ine Web Applications