o ine web applications - repositório aberto da …...sempre o estado real da aplica˘c~ao, podendo...

Faculdade de Engenharia da Universidade do Porto

Offline Web Applications

Enabling offline execution on the WOW! product

João Gonçalves da Costa

Relatório de Projecto realizado no Âmbito do

Mestrado Integrado em Engenharia Informática e Computação

Orientador: Teresa Galvão Dias (PhD.)

Julho de 2008

c© João Gonçalves da Costa, 31 de Julho de 2008

Offline Web Applications


Relatório de Projecto realizado no Âmbito do

Mestrado Integrado em Engenharia Informática e Computação

Aprovado em provas públicas pelo júri:

Presidente: Pedro Ferreira do Souto (PhD)

Arguente: Artur Pereira (PhD)

Vogal: Teresa Galvão Dias (PhD)

27 de Julho de 2008

Resumo

Este projecto teve como objectivo o estudo das Offline Web Applications (OWAs)e da sua implementação em web applications já existentes. Neste âmbito, foi feitauma avaliação da aplicação desta tecnologia no WOW!, uma plataforma integradade gestão de ordens de trabalho, desenvolvida pela Critical Software S.A. ao longodos últimos 6 anos, e implementada uma prova de conceito que permite a utilizaçãode um conjunto de funcionalidades base desta web application, independentementedo estado da ligação à Internet.

O conceito das OWAs enquadra-se numa tecnologia de Internet que permiteo acesso a um website através do browser mesmo na ausência de uma ligação àrede 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 compreensão dos problemas associados àsua implementação e respectivas soluções e também da avaliação dos benef́ıcios dautilização desta tecnologia para os utilizadores finais.

A evolução das tecnologias associadas à Internet, a que se assiste continua-mente, impulsionou também evolução da forma como a informação é produzida,distribúıda e armazenada. Surgiram novas web applications oferecendo funcionali-dades de criação e edição de conteúdos, que trouxeram consigo a vantagem de tornarposśıvel o acesso à informação a partir de qualquer lugar, mas também a desvan-tagem de tornar a ligação à Internet uma condição necessária para que isto aconteça.A proliferação destas aplicações, a crescente utilização da Internet [Gro08] e a adesãoaos seus serviços indiciam a existência de uma dependência cada vez maior de umaligação, que nem sempre existe.

As OWAs vêm assim colmatar esta falha, colocando no lado do cliente parte dainformação que até agora vinha a ser armazenada no servidor e tornando não sóposśıvel a sua consulta offline, como também reduzindo a carga no servidor, umavez que reduz as transferências de informação.

Pretende-se neste documento apresentar diferentes formas de como a utilizaçãoda tecnologia OWA pode beneficiar as web applications de hoje, melhorando o seudesempenho e dando-lhes novas possibilidades de execução, aproximando-as do desk-top.

i

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 mind,a 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 available.This 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

Agradecimentos

A realização e os objectivos alcançados neste projecto não teriam sido posśıveissem a colaboração de inúmeras pessoas. Agradeço profundamente a todos os quecontribúıram directa ou indirectamente para o seu sucesso:

À minha orientadora, Professora Teresa Galvão 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 Fábio Matos,que contribúıram para a minha a minha integração na Critical Software e que sempresouberam responder a todas as minhas questões,

A todos os que constituem a CSW Porto, pelo fantástico ambiente de amizadeque me proporcionaram,

Aos colegas de curso e a todos os que me auxiliaram na revisão deste documento,

Os meus sinceros agradecimentos!


v

Conteúdo

1 Introdução 11.1 Enquadramento . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11.2 Motivação . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21.3 Âmbito . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31.4 Objectivos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31.5 Estrutura do documento . . . . . . . . . . . . . . . . . . . . . . . . . 3

2 Enquadramento do Projecto 52.1 Evolução das arquitecturas de software . . . . . . . . . . . . . . . . . 5

2.1.1 Thin-clients . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52.1.2 Fat-clients . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62.1.3 Arquitecturas cliente-servidor . . . . . . . . . . . . . . . . . . 7

2.2 Evolução na Internet . . . . . . . . . . . . . . . . . . . . . . . . . . . 82.2.1 Páginas web estáticas . . . . . . . . . . . . . . . . . . . . . . . 92.2.2 Páginas web interactivas e páginas web dinâmicas . . . . . . . 92.2.3 Web 2.0 e Ajax . . . . . . . . . . . . . . . . . . . . . . . . . . 11

2.3 Offline Web Applications . . . . . . . . . . . . . . . . . . . . . . . . . 132.4 Comparação . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

3 Estado da arte 173.1 Gears . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

3.1.1 Arquitectura . . . . . . . . . . . . . . . . . . . . . . . . . . . . 173.1.2 Goggle Gears em dispositivos móveis . . . . . . . . . . . . . . 20

3.2 Adobe AIR . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 203.2.1 Segurança . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 223.2.2 Assinatura do código . . . . . . . . . . . . . . . . . . . . . . . 22

3.3 Mozilla Prism . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 233.3.1 XML User Interface Language . . . . . . . . . . . . . . . . . . 233.3.2 Prism . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

3.4 HTML 5 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 253.5 Web applications que usam funcionalidades offline . . . . . . . . . . . 26

3.5.1 Google Reader e Google Docs . . . . . . . . . . . . . . . . . . 263.5.2 Remember the Milk . . . . . . . . . . . . . . . . . . . . . . . . 273.5.3 MySpace e WordPress.com . . . . . . . . . . . . . . . . . . . . 27

3.6 Escolha da tecnologia . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

vii

CONTEÚDO

4 Desenvolvimento 334.1 Como ficar offline . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33

4.1.1 Funcionalidades dispońıveis em modo offline . . . . . . . . . . 344.2 Modos de execução . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35

4.2.1 Modo “utilizador decide” . . . . . . . . . . . . . . . . . . . . . 364.2.2 Modo aplicação decide . . . . . . . . . . . . . . . . . . . . . . 364.2.3 Modo “aplicação assume o estado offline” . . . . . . . . . . . 37

4.3 Sincronização de dados . . . . . . . . . . . . . . . . . . . . . . . . . . 384.3.1 Quando sincronizar? . . . . . . . . . . . . . . . . . . . . . . . 39

4.4 WOW! . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 404.5 Visão geral sobre a arquitectura do WOW! . . . . . . . . . . . . . . . 414.6 WOW! Offline . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42

4.6.1 Modo “aplicação decide” com detecção automática da ligação 434.6.2 Implementação do modo “utilizador decide” . . . . . . . . . . 454.6.3 Especificação do modo “aplicação assume o estado offline” . . 48

5 Resultados e Futuros Desenvolvimentos 515.1 Resultados Obtidos . . . . . . . . . . . . . . . . . . . . . . . . . . . . 515.2 Trabalho Futuro . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52

6 Conclusões 556.1 Conclusões . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55

Referências 59

A Screenshots 61

viii

Lista de Figuras

2.1 Arquitectura de um sistema thin-client em duas camadas (à esquerda)e em três camadas (à direita). Note-se a inclusão do servidor (main-frame) na definição das camadas desta arquitectura, devido à fortedependência cliente-servidor. . . . . . . . . . . . . . . . . . . . . . . . 9

2.2 Arquitectura de um fat-client em duas camadas (à esquerda) e emtrês camadas (à direita). . . . . . . . . . . . . . . . . . . . . . . . . . 10

2.3 Comparação do modelo de web aplications śıncrono, páginas estáticase interactivas abordados nas secções 2.2.1 e 2.2.2, com o modelo deweb applications Ajax (asśıncrono) abordado na secção 2.2.3. Figuraadaptada de http: // www. adaptivepath. com/ . . . . . . . . . . . 15

3.1 Esquema UML do processo efectuado pelos recursos do Gears do tipoManagedResourceStore para a actualização dos conteúdos definidosno ficheiro manifesto. . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

4.1 Exemplo de uma arquitectura de uma web application sem uma ca-mada de abstracção de dados. Figura adaptada de http: // gears.google. com/ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33

4.2 Exemplo de uma arquitectura de uma web application com uma ca-mada de abstracção de dados. Figura adaptada de http: // gears.google. com/ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34

4.3 Exemplo de uma arquitectura de uma web application com uma ca-mada de abstracção de dados e um data switch. Figura adaptada dehttp: // gears. google. com/ . . . . . . . . . . . . . . . . . . . . . 35

4.4 Esquema gráfico ilustrando uma OWA executando no browser uti-lizando um modo de execução do tipo “aplicação decide”, com de-tecção automática do estado da ligação via pedidos Ajax asśıncronosa cada cinco segundos. . . . . . . . . . . . . . . . . . . . . . . . . . . 37

4.5 Detalhe de um conjunto posśıvel de estados e respectivas transiçõespara uma dada ordem de trabalho no WOW!, desde a sua submissãono sistema até à sua conclusão em fecho ou cancelamento. Esta figurarepresenta apenas um exemplo, já que o mapa de estados para umaordem de trabalho é dinâmico e pode ser alterado por um admin-istrador. Figura retirada de uma brochura promocional do WOW!,Critical Software S.A. . . . . . . . . . . . . . . . . . . . . . . . . . . . 41

ix

http://www.adaptivepath.com/http://gears.google.com/http://gears.google.com/http://gears.google.com/http://gears.google.com/http://gears.google.com/

LISTA DE FIGURAS

4.6 A página inicial do WOW apresenta um resumo das últimas ordensde trabalho enviadas e recebidas. Na imagem pode-se observar atransição do estado online para offline. . . . . . . . . . . . . . . . . . 44

4.7 Ilustração 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 máquinaremota, consoante se verificarem ou não as condições expressas noponto 3.1.1. É representado um acesso a uma base de dados local(fornecida pelo Gears), mas a sua utilização é opcional. . . . . . . . . 45

4.8 Neste exemplo do modo “aplicação decide”, o teste da ligação é feitoé feito a cada cinco segundos. O resultado deste teste não reflectesempre o estado real da aplicação, podendo levar a aplicação a tercomportamentos indesejáveis. Na figura assinala-se um peŕıodo detempo no qual a representação interna do estado da ligação não cor-responde à realidade. . . . . . . . . . . . . . . . . . . . . . . . . . . . 46

4.9 Página de visualização do detalhe de uma ordem de trabalho. . . . . 474.10 Esquema UML que expressa os casos de uso do WOW! Offline no

modo “utilizador decide”. . . . . . . . . . . . . . . . . . . . . . . . . 484.11 Esquema UML que expressa os casos de uso do WOW! Offline no

modo “utilizador decide”. . . . . . . . . . . . . . . . . . . . . . . . . 494.12 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

A.1 Diálogo apresentado ao utilizador na primeira activação das funcional-idades offline no Google Docs & Spreadsheets. . . . . . . . . . . . . . 61

A.2 Na activação das funcionalidades offline é também oferecida a possi-bilidade da criação de alguns atalhos, por exemplo, no ambiente detrabalho. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62

A.3 O Google Docs mantém a todo o momento a possibilidade de alteraçãodestas definições, ou da anulação dos serviços offline para um dadocomputador. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62

A.4 Após a instalação do Gears qualquer visita ao Remember The Milkdespoleta uma sincronização que ocorre automaticamente e sem ne-cessidade de intervenção por parte do utilizador. . . . . . . . . . . . . 63

A.5 Após completar a sincronização de dados, mesmo que a ligação àInternet seja perdida o Remember the Milk continua dispońıvel nobrowser (com excepção das funcionalidades que pela sua naturezaexigem uma ligação, como por exemplo: partilha de tarefas e enviode convites.) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63

x

Lista de Tabelas

2.1 Comparação entre thin-clients e fat-clients . . . . . . . . . . . . . . . 7

3.1 Comparação das funcionalidades oferecidas pelo Adobe AIR para asplataformas web e desktop . . . . . . . . . . . . . . . . . . . . . . . . 30

3.2 Resumo da utilização de tecnologias OWA em algumas web applica-tions consideradas na análise do estado da arte. . . . . . . . . . . . . 31

xi

LISTA DE TABELAS

xii

Glossário

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

6–8

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

5–8

web application Sistema web (servidor, rede HTTP,browser) onde acções do utilizador(navegação e introdução de informação)afectam o estado lógico da aplicação.

i, iii,1–3,11–15,17–19,21–23,27,28, 33,36–38,42, 55,56

API Application Programming Interface 10, 17,18, 23,26, 28

ASP Linguagem interpretada pelo servidorque permite a criação de páginas webdinâmicas. Desenvolvida pela Microsoft.

11

BSD Berkeley Software Distribution 28

CSS Cascading Style Sheets 12, 20,21, 23,24, 46

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

20, 23,24

DTD Document Type Definition 24

xiii

Glossário

ECMAScript Padrão de linguagem de programaçãodefinido pela Ecma International que orig-inou o JavaScript e o JScript.

24

Flash Conteúdo interactivo de um ficheiro emformato SWF. É desenvolvido pela Adobee visualizado através do Adobe FlashPlayer.

21

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

21

GPL GNU General Public License 23

HTML HyperText Markup Language 1, 10–12, 21,24–26,49

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, 18,28, 34

LGPL GNU Lesser General Public License 23

Mozilla Prism Browser simplificado e “interpretador” deeXtensible User Interface Language (XUL)(também designado por XULRunner) queacolhe web applications sem a interfacegráfica habitual de um browser.

25

MPL Mozilla Public License 23

OCA Occasionally Connected Application 39OWA Offline Web Application i, iii,

2–5,15, 17,25, 26,28, 31,33, 36,51, 52,55, 56

PDF Portable Document Format 21

xiv

Glossário

PHP Linguagem interpretada pelo servidorque permite a criação de páginas webdinâmicas, mas que pode também ser in-vocada a partir da linha de comandos.

11

página web estática Página 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 ás desktop applications, masque mantém a informação no lado do servi-dor

5, 15,20, 28

RSS Really Simple Syndication 27

SLA Service Level Agreement 40SQLite Segundo a definição oficial: SQLite is a

software library that implements a self-contained, serverless, zero-configuration,transactional 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 gestãode ordens de trabalho e do seu fluxo, de-senvolvida pela Critical Software S.A.

i, iii,28, 33,40–43,45,51–53,56

WWW World Wide Web 11, 12,14

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

23, 24,28

XSLT eXtensible Stylesheet Language Transfor-mation

12

XUL eXtensible User Interface Language xiv,23–25

xv

Glossário

xvi

Caṕıtulo 1

Introdução

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

nos quais se baseia. Apresentam-se as motivações, âmbito, objectivos e a estrutura

deste documento.

1.1 Enquadramento

A Internet foi originalmente concebida para ser um espaço de partilha de in-

formação, onde pessoas (através de máquinas) pudessem comunicar. Na sua origem,

as páginas eram estáticas, constitúıdas por texto formatado em HyperText Markup

Language (HTML) e ligadas entre si [BL96]. Hoje encontramos conteúdos cada vez

mais complexos e dinâmicos, incluindo som, v́ıdeo ou streams multimédia [Loo06] e

em 2005 foi introduzido por [O’R09] o termo Web 2.0.

De acordo com [Greon] um website pode pertencer a uma ou várias das seguintes

categorias:

• Documento – um website essencialmente estático, onde alterações a umaparte do conteúdo não tem implicações no seu comportamento.

• Base de dados – um directório de informação organizada em categorias.

• Aplicação – um website dinâmico, que utiliza uma linguagem executada ouinterpretada do lado do servidor, e que processa as acções ou informação in-

troduzida pelo utilizador para fornecer um serviço ou nova informação.

A última 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

Introdução

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

acções do utilizador (navegação e introdução de informação) afectam o estado lógico

da aplicação. A sua definição tenta estabelecer que uma web application é um

sistema de software com estado de negócio1, e que a sua interface de interacção com

o utilizador é distribúıdo através de um sistema web.

1.2 Motivação

A quantidade de informação que é produzida e armazenada com recurso a es-

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

mentação, tornam por vezes a disponibilidade de ligação uma condição necessária

à produtividade e, como consequência desta barreira, muitos potenciais utilizadores

opõem-se à adopção de produtos web em detrimento das tradicionais desktop appli-

cations.

Assegurar o acesso a uma ligação de Internet é hoje muito mais fácil. A Internet

móvel é já uma realidade e encontra-se amplamente divulgada, mas continuam a

existir diversas situações nas quais os utilizadores estão privados de uma ligação

à Internet, tais como uma viagem de metro ou de avião, ou quando se encontram

deslocados do seu páıs de origem e não possuem nenhum plano de subscrição.

Uma OWA consiste numa web application que para além de manter todas as

caracteŕısticas anteriores, se mantém dispońıvel mesmo na ausência de uma ligação

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 manutenção do estado lógico da aplicação quando a ligação com o servidor é

quebrada, permitindo ao utilizador continuar a utilizar a aplicação, e que será capaz

de informar o servidor do estado em que a aplicação se encontra quando a ligação for

reposta. A principal vantagem que advém desta possibilidade é evidente: eliminar

a necessidade da existência de uma ligação à Internet para que a aplicação possa ser

utilizada.

Por outro lado, a vontade de integração 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 reflexão “para além

do browser” e a uma adaptação das arquitecturas existentes que permitisse ou o

acesso a funcionalidades disponibilizadas pelo sistema operativo ou, pelo menos, a

funcionalidades semelhantes. Pretende-se com esta aproximação tornar posśıveis

interacções entre o desktop e o browser, tais como arrastar um ficheiro para um

formulário web de upload de conteúdos, melhor suporte para o histórico do clipboard

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

1NT. business state

2

Introdução

num novo paradigma, que reúne as vantagens das web applications, tais como os

updates instantâneos ou o facto de não ser necessária nenhuma instalação, e das

desktop applications, como por exemplo: persistência no armazenamento de dados,

acesso a funcionalidades do sistema operativo ou integração e interacção com outras

aplicações, sejam elas web applications ou desktop applications.

1.3 Âmbito

Este projecto foi realizado na Critical Software S.A. no âmbito do Mestrado

Integrado em Engenharia Informática e Computação (MIEIC) da Faculdade de En-

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

2008.

1.4 Objectivos

São objectivos deste projecto:

1. Estudar e documentar o tema das OWAs acompanhando os últimos desenvolvi-

mentos nesta matéria.

2. Analisar o estado da arte, fazendo uma análise cŕıtica e objectiva sobre as

diversas metodologias existentes.

3. Implementar uma prova de conceito, que permita a execução offline de uma

web application, documentando todo o processo.

4. Estudar a possibilidade de permitir interacção com a aplicação (inserções e

alterações 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 não 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.

1.5 Estrutura do documento

Este documento está organizado em diferentes secções, apresentando o projecto

numa sequência lógica organizada da seguinte forma:

No caṕıtulo 1 faz-se uma breve apresentação do conceito OWAs e do contexto em

que surge. Apresenta-se também a estrutura do documento e definem-se os

termos e acrónimos utilizados.

3

Introdução

No caṕıtulo 2 faz-se uma descrição da evolução 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 matéria. Introduzem-se diversas

tecnologias directamente relacionadas com o tema deste projecto, exemplos de

aplicações que as usam e as razões que fundamentam as escolhas de tecnologias

efectuadas.

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

WOW! de gestão integrada de ordens de trabalho, a tecnologia escolhida e

a forma como foi utilizada para implementar a capacidade de execução offline.

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

iniciais do projecto e apresenta desenvolvimentos futuros e possibilidades de

continuação/aplicação do conhecimento adquirido.

No caṕıtulo 6 apresentam-se as conclusões.

4

Caṕıtulo 2

Enquadramento do Projecto

Neste caṕıtulo apresenta-se um breve resumo da evolução das arquitecturas de

software cliente-servidor e a forma como estas se comparam à evolução da Inter-

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

gias. Compara-se o comportamento e arquitectura dos thin-clients às páginas web

estáticas, a evolução dos fat-clients às páginas interactivas, Web 2.0 e Ajax, e

defende-se que as OWA constituem um próximo passo lógico e evolutivo, aproxi-

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

importância das OWAs e a estreita relação que têm com as Rich Internet Application

(RIA)s.

2.1 Evolução das arquitecturas de software

Os termos thin-client e fat-client são utilizados quer para descrever arquitecturas

lógicas (de software), quer para descrever arquitecturas f́ısicas (de hardware). Neste

caṕıtulo, excepto quando seja dada indicação em contrário, estes termos referem-se

sempre a uma arquitectura lógica.

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 secção 2.1.3,

especifica-se em cada caso qual o sistema estudado.

2.1.1 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


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

formação 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 aplicações cliente-servidor.

No ińıcio da história da computação, terminais ligavam-se directamente a main-

frames responsáveis por todo o processamento. Nesta arquitectura, era necessário

desenvolver duas aplicações distintas: uma aplicação central no servidor (main-

frame), responsável pela gestão de toda a informação e por todas as operações de

comunicação, e uma aplicação de visualização, instalada no cliente (terminal). O

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

nicação (entrada e sáıda) e apresentação dos resultados do servidor. Não tinham

um papel activo no cálculo nem na lógica de negócio e frequentemente não tinham

também nenhum mecanismo de armazenamento de dados.

Como vantagens, esta arquitectura apresenta uma reduzida necessidade de con-

figuração e manutenção do lado do cliente. Uma vez que o centro do processamento

e manipulação de dados ocorre no servidor, existe também uma centralização da

informação [NJN00] que introduz um ponto cŕıtico de falha1. Actualizações e novas

funcionalidades são fáceis de distribuir, uma vez que requerem apenas alterações no

servidor [Gro02a].

2.1.2 Fat-clients

Contrastando com os thin-clients, nesta arquitectura os clientes implementam

já uma parte da lógica de negócio e são responsáveis pelo processamento de dados.

Estes fat-clients vieram responder à necessidade crescente de aplicações com um

ńıvel de interactividade e capacidade de configuração maior que as oferecidas pela

arquitectura thin-client , descrita na secção 2.1.1. Apesar de manterem a sua de-

pendência do servidor, podem também ser executados sem uma conexão activa uma

vez que dispõe de armazenamento de dados local, o que lhes confere a capacidade

de persistência de dados e do estado de execução entre cada sessão.

Foi disponibilizando este controlo sobre o estado da aplicação, bem como acesso

a recursos locais (por exemplo, sistema de ficheiros e periféricos) 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 aplicação e uma actualização ao servidor implicava in-

variavelmente uma actualização manual também no cliente. Uma vez que nem todos

1NT.: single point of failure

6


Thin-clients Fat-clientsNão 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.

Não mantém registo do estado lógicoda aplicação entre duas sessões de uti-lização.

O acesso ao armazenamento localpermite-lhe manter registo do estadológico da aplicação entre duas sessões.

O thin-client não necessita de qualquerinstalação, estando “pronto a utilizar”.

É geralmente necessário instalar aaplicação para poder interagir com oservidor

Qualquer update no servidor reflecte-seimediatamente por todos os clientes.

Embora a aplicação cliente possa aler-tar para existência de novas versões, asactualizações têm que ser manualmenteinstalados pelo cliente.

O software do cliente destina-se apenasà apresentação de dados e comunicaçãocom o servidor, sendo portanto, de sim-ples implementação.

Como o software do cliente toma parteactiva no processamento de dados,a sua implementação requer cuidadosadicionais.

Grande mobilidade, uma vez que todaa informação é mantida no servidor

Parte da informação poderá estar ape-nas do lado cliente, pelo que existemalgumas restrições à sua mobilidade.

Tabela 2.1: Comparação entre thin-clients e fat-clients

os utilizadores actualizam regularmente as suas aplicações, o servidor tem que estar

preparado para lidar com versões antigas2, ou descontinuar os seus serviços 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 alterações que não sejam sincronizadas com o servidor estão apenas

dispońıveis nos seus computadores pessoais, o que introduz uma restrição à mobili-

dade.

Pode-se afirmar que as vantagens dos thin-clients são as desvantagens dos fat-

clients, e que as vantagens dos fat-clients são as vantagens dos thin-clients, tal como

se ilustra na Tabela 2.1.

2.1.3 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 serviços e um servidor como um prestador de serviços, tal como

definido por [Sch96] e [Sad97].

2NT. backward compatibility

7


As arquitecturas cliente-servidor são categorizadas pela modularização com que

são desenhadas, sendo consideradas as seguintes camadas:

1. Interface gráfica (front-end) através da qual os utilizadores interagem com

a aplicação. Quando este módulo é implementado separadamente dos outros

dois constitui uma aplicação thin-client por si só, uma vez que não implementa

regras de negócio (embora possa definir validações de formulários de inserção de

dados, por exemplo). A informação 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 lógica de negócio, também designada por camada intermédia, que imple-

menta as regras de aceitação e validação de todos os dados introduzidos pelo

utilizador. É também a plataforma de comunicação que une a camada superior

de visualização com a camada de acesso a dados;

3. A camada de dados inclui quer o sistema de persistência de dados, onde são

armazenados os dados relevantes, como também os mecanismos necessários

para a sua pesquisa, selecção e alteração.

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 três camadas,

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

implementação do servidor não se distinguir a camada de acesso a dados da camada

da lógica de negócio, são designados por sistemas de duas camadas. Caso seja feita

esta distinção, são designados por sistemas de três camadas. Ambos os casos são

ilustrados na Figura 2.1.

Historicamente, os fat-clients eram implementados numa arquitectura em duas

camadas. Possúıam apenas um módulo de visualização de dados, designado por

camada de interface, e um módulo que implementava toda a lógica de negócio e

regras de acesso à base de dados. No entanto, com a introdução de ligações mais

rápidas e de computadores pessoais com maior capacidade de processamento e so-

bretudo devido à complexidade crescente das aplicações, a lógica de negócio e a

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

arquitectura em três camadas e é ilustrado na Figura 2.2.

2.2 Evolução na Internet

Ao analisar a evolução das arquitecturas das aplicações desenvolvidas para a

Internet, podemos encontrar um paralelismo com a história da arquitectura de soft-

ware.

8


Figura 2.1: Arquitectura de um sistema thin-client em duas camadas (à esquerda) e emtrês camadas (à direita). Note-se a inclusão do servidor (mainframe) na definição dascamadas desta arquitectura, devido à forte dependência cliente-servidor.

2.2.1 Páginas web estáticas

Uma página web estática devolve sempre a mesma resposta a todos os pedidos,

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

forma de ligação entre diversas páginas estáticas.

A informação é armazenada num servidor, e o papel do cliente é apenas a apre-

sentação da informação. Esta forma de disponibilização de informação pode assim

ser comparada com os thin-clients descritos na secção 2.1.1: o utilizador acede a

um website estático para visualizar informação sem que o cliente tome parte no

processamento. A única diferença é que no caso da web estática a informação ap-

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

possibilidade de inserção de dados no cliente e após o seu processamento servidor,

nova informação poderia ser apresentada. O hipertexto é utilizado para ligar as

páginas entre si numa rede de conteúdos relacionados, e a navegação śıncrona era

feita através de cliques do rato: a cada clique uma nova página era apresentada.

Este modelo śıncrono é ilustrado na Figura 2.3.

2.2.2 Páginas web interactivas e páginas web dinâmicas

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

como principal ambiente de acolhimento. Os browsers utilizam uma Application

9


Figura 2.2: Arquitectura de um fat-client em duas camadas (à esquerda) e em três camadas(à direita).

Programming Interface (API) pública para criar “objectos” responsáveis por reflectir

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

A utilização mais frequente desta linguagem é a escrita de funções que são em-

bebidas ou inclúıdas em páginas web e que interagem com o DOM. Uma vez que o

JavaScript é executado localmente (na máquina do cliente e não no servidor) é capaz

de responder rapidamente a acções do utilizador, tornando a execução de aplicações

no browser mais flúıdas; o JavaScript pode também detectar acções do utilizador

que o HTML não 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 também a suportar uma versão semelhante desta

linguagem (hoje, todos os principais browsers suportam esta tecnologia).

Esta inovação permitiu tornar os websites mais interactivos, mas a sua utilização

esteve confinada apenas a este propósito durante um longo peŕıodo. As páginas

passaram a responder activamente a acções do utilizador (sendo uma das utilizações

3Netscape Communications – http://browser.netscape.com/4Microsoft Internet Explorer – http://www.microsoft.com/windows/products/winfamily/ie

10

http://browser.netscape.com/http://www.microsoft.com/windows/products/winfamily/ie


mais vulgares a validação de formulários) mas continuaram essencialmente estáticas.

O JavaScript ainda não era, nesta altura, utilizado para processar dados.

Também nesta altura (1995–96) 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 páginas dinâmicas, capazes de responder a inserção de dados ou outros pedidos

determinados por acções do utilizador. As páginas tornaram-se aplicações, web ap-

plications.

Uma definição tradicional de web application é: um conjunto de páginas web

logicamente agrupadas e geridas por uma única entidade, que têm como pontos de

entrada formulários de inserção de dados (web forms). Uma web application não é

mais do que uma aplicação que é acedida através de um browser. Têm geralmente

uma arquitectura lógica em três (interface, lógica de negócio e camada de dados)

camadas e estão armazenadas num servidor.

Há dois tipos de web applications:

• Orientadas à apresentação: São web applications que geram páginas web in-teractivas constitúıdas por vários tipos de linguagens de anotação (por exem-

plo: HTML, eXtensible Markup Language (XML)) e que apresentam conteúdo

dinâmico como resposta a pedidos efectuados pelo utilizador.

• Orientadas aos serviços: Uma web application orientada aos serviços imple-menta o ponto de acesso para um ou mais de um web service. São geralmente

clientes de service oriented web applications.

Uma vantagem significativa de implementar uma web application de forma a

suportar as funcionalidades padrão dos browsers é que estas terão o mesmo com-

portamento independentemente da plataforma e do browser a partir do qual serão

acedidas. No entanto, diferentes implementações de browsers, devido a diferentes

interpretações dos padrões definidos, tornam por vezes esta tarefa um pouco mais

complicada, existindo inclusivamente na web guiões de compatibilidade para os difer-

entes browsers como [Smi07].

2.2.3 Web 2.0 e Ajax

O termo web 2.0 descreve uma tendência de utilização e de design observada

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

de informação e principalmente: a colaboração entre utilizadores. Estes conceitos

levaram ao desenvolvimento e evolução de comunidades online tais como redes so-

ciais, wikis e blogues.

11


O termo tornou-se mais conhecido após a primeira conferência O’Reilly Media

Web 2.0 em 2004, e apesar de sugerir uma nova versão da WWW não se refere a

qualquer evolução tecnológica, mas apenas a alterações à forma como os utilizadores

se servem da web. De acordo com Tim O’Reilly [O’R06]: “Web 2.0 é uma revolução

na indústria do software, causada pela adopção da web como uma plataforma e pela

tentativa de entendimento das regras para o sucesso nesta nova plataforma”.

O desenvolvimento da Web 2.0 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 aplicações de desktop. Este

conceito foi melhor descrito por [Gar05] como um conjunto de várias tecnologias

que podem ser utilizadas para melhorar a experiência do utilizador de uma dada

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

recepção asśıncrona de respostas. As tecnologias mais frequentemente envolvidas

são:

• eXtensible HyperText Markup Language (XHTML) e Cascading Style Sheets(CSS) padrão para a apresentação;

• interacção dinâmica através do DOM;

• troca e manipulação de dados utilizando XML e eXtensible Stylesheet Lan-guage Transformation (XSLT) ou JavaScript Object Notation (JSON);

• pedidos asśıncronos utilizando XMLHttpRequest [vK08];

• JavaScript, utilizado para integrar todas estas tecnologias.

É importante frisar que o Ajax não é um produto nem uma tecnologia. É um

termo que descreve a utilização de um conjunto de tecnologias para o desenvolvi-

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

mente às web applications tradicionais, o Ajax introduz uma camada de visualização

diferente em três importantes pontos:

1. Do lado do cliente existe um motor que serve de intermediário entre a interface

da aplicação e o servidor.

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

de página directamente ao servidor.

3. Informação codificada em XML, em vez de páginas HTML, é trocada entre o

servidor e o cliente.

12


Isto significa que as páginas que utilizam Ajax contêm um motor do lado do

cliente, composto por um conjunto de funções JavaScript, responsável pela comu-

nicação com o servidor e por actualizar a interface com o resultado dessa mesma

comunicação.

Na Figura 2.3 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 comunicações com o servidor uma vez que a interface não fica “bloqueada” à es-

pera da resposta. Obtém-se assim aplicações com um comportamento mais fluido,

eliminando tempos de espera entre cada “clique” e melhorando a experiência do

utilizador.

2.3 Offline Web Applications

A informação gráfica (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 avançados sistemas de cache (armazenamento temporário) dos

browsers. Mas estes não são ainda capazes de guardar conteúdo criado pelo uti-

lizador, nem de apresentar informação independentemente do estado da ligação.

Numa altura onde se fala de serviços de Internet wireless municipalizados [Kha],

comunicações 3G e ligações de banda larga a alta velocidade, a ligação à rede global

continua a não estar permanentemente dispońıvel para os utilizadores. Na WWW

encontra-se uma importante parte da informação e das aplicações utilizadas para

criar e editar conteúdos. Por vezes, informação vital para a produtividade pode

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

metro, num avião, ou mesmo quando se desloca para uma cidade ou páıs diferente

do habitual, onde não subscreve um plano de acesso que lhe garanta a ligação.

Permitir o acesso offline a estes recursos assume assim a sua importância, porque

permitirá estender o alcance da informação a locais onde nunca esteve antes, e per-

mitirá também melhorar o desempenho das web applications, colocando informação

mais perto dos utilizadores, reduzindo a transferência de dados apenas ao essencial.

2.4 Comparação

Nas evoluções descritas neste caṕıtulo 2 pode-se observar que existe um par-

alelismo entre a evolução das arquitecturas tradicionais cliente-servidor e a evolução

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

se ao das páginas estáticas, no sentido em que o browser não toma parte em qualquer

13


processamento, e serve apenas como uma plataforma de interacção com o servidor;

tal como os clientes descritos na secção 2.1.1.

A sua próxima evolução, os fat-clients, trouxeram parte da capacidade de pro-

cessamento para o lado do cliente. Na web, foi também esta a inovação tecnológica

a que se assistiu, com a evolução das tecnologias que permitiram a criação de ver-

dadeiras aplicações, e com a introdução do Javascript no browser, dando ao cliente

a capacidade de processamento de dados. A necessidade da separação do código

em camadas lógicas advém da crescente complexidade das web applications. Esta

prática permite, entre outras coisas, melhorar o processo de desenvolvimento e a

capacidade de manutenção de uma aplicação.

Os fat-clients têm também a capacidade de armazenamento de dados, o que

permite a persistência de informações entre duas sessões e que algumas operações

sejam executadas sem a necessidade de comunicação com o servidor. Este facto pode

também ser uma realidade nas web applications com a adopção das tecnologias OWA.

Neste momento assiste-se a uma utilização cada vez maior da web como uma

plataforma de desenvolvimento. A capacidade de cooperação na edição de conteúdos,

e a mobilidade proporcionada por esta plataforma são os principais factores que

alimentam esta mudança, e pela primeira vez, as aplicações tradicionais têm com-

petição 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 lançaram publicamente ferramentas web complementares a produtos

seus, tradicionalmente associados ao desktop – Acrobat.com5 e Microsoft Office

Live6. Dotar estas web applications da capacidade de execução offline significa

aproximar a web e o desktop reunindo “o melhor de dois mundos”.

As vantagens da mobilidade posśıvel através da web a cooperação na criação e

edição de conteúdos e a possibilidade de utilizar aplicações sempre actualizadas e

sem necessidade de instalação são algumas das principais vantagens que promovem

esta mudança, que devido às preocupações associadas à usabilidade e experiência do

utilizador, está fortemente associada ao desenvolvimento de Rich Internet Applica-

tion (RIA)s.

5Adobe Acrobat.com http://www.acrobat.com6Microsoft – http://smallbusiness.officelive.com

14

http://www.acrobat.comhttp://smallbusiness.officelive.com


Figura 2.3: Comparação do modelo de web aplications śıncrono, páginas estáticas e in-teractivas abordados nas secções 2.2.1 e 2.2.2, com o modelo de web applications Ajax(asśıncrono) abordado na secção 2.2.3. Figura adaptada de http: // www. adaptivepath.com/

15

http://www.adaptivepath.com/http://www.adaptivepath.com/


16

Caṕıtulo 3

Estado da arte

Apesar de o conceito das OWAs não ser absolutamente novo, as tecnologias que

o suportam são 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.

3.1 Gears

O Gears1 é uma extensão às funcionalidades do browser introduzido pelo Google

que tem como principal objectivo tornar posśıvel a visualização de páginas de Inter-

net mesmo sem uma conexão 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.

3.1.1 Arquitectura

Esta ferramenta é constitúıda por três componentes principais:

• LocalServer — Intercepta pedidos de páginas web, e serve-as localmente;

• Database — Uma base de dados relacional constrúıda sobre SQLite;

• WorkerPool — Permite executar operações de computação de uma formaasśıncrona, sem afectar a capacidade de resposta e fluidez de execução da web

application. Assemelham-se a processos.

1Google Inc. – Mais informação em http://gears.google.com/

17

http://gears.google.com/

Estado da arte

LocalServer

O módulo LocalServer é uma cache de Uniform Resource Locators (URLs)

controlada pela web application. Quando não existe uma ligação 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 aplicação

pode utilizar dois tipos diferentes de armazenamento local de URLs:

• ResourceStore – serve para capturar URLs utilizando exclusivamente a APIde Javascript disponibilizada para o efeito. Uma aplicação poderá criar e

utilizar diversos ResourceStores simultaneamente para capturar ficheiros de

dados que necessitam de ser endereçados por um URL, tal como um ficheiro

PDF ou uma imagem.

• ManagedResourceStore – serve para capturar um conjunto de URLs que estãorelacionados, e que são declarado num ficheiro de manifesto (especificado em

JSON) e que são automaticamente actualizados. O ManagedResourceStore

permite que o conjunto de recursos necessários para correr uma web application

seja capturado e mantido actualizado automaticamente.

A principal diferença entre estes dois tipos de armazenamento de URLs é a forma

como são actualizados os seus conteúdos. Os conteúdos de um ManagedResourceStore

são actualizados sempre que a versão contida no ficheiro de manifesto for alterada,

enquanto que os conteúdos de um ResourceStore nunca são actualizados automati-

camente, mas apenas quando for explicitamente ordenado pela aplicação.

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

HTTPS sempre que se reúnam as seguintes condições:

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 não necessita de monitorizar o estado da ligação para atender aos

pedidos. Na verdade, sempre que as condições previamente enunciadas se verificarem

o LocalServer interceptará os pedidos e, independentemente do estado da ligação

à Internet, servi-los-á a partir do disco ŕıgido local. Caberá à aplicação 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 módulo Database permite guardar dados da web application assegurando a

sua persistência. Os dados são guardados de forma relacional no disco ŕıgido do uti-

lizador2 de acordo com o modelo de segurança estabelecido pelo Gears3, significando

que uma aplicação não pode aceder a conteúdos fora do seu domı́nio.

WorkerPool

Nos web browsers uma operação pesada de computação pode tornar a interface

lenta e tornar menos agradável a experiência do utilizador. O módulo WorkerPool

permite correr operações em background sem bloquear a interface com o utilizador.

Os scripts executados numa WorkerPool não activam os mecanismos de segurança

do browser que mostram a mensagem “A script on this page may be busy, or may

have stopped responding”.

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

Os Workers não partilham qualquer estado de execução, o que significa que uma

alteração a uma variável num Worker não afecta em nada a execução de outro

Worker. Além disso, os Workers não herdam automaticamente nenhum código 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́

também algumas limitações: os Workers não tem acesso ao DOM, e objectos como

window ou document não se encontram acesśıveis. Isto é consequência de os Workers

não partilharem o estado de execução. Mas têm acesso a todas as funções built-in

do Javascript. A maioria das funcionalidades do Gears pode também ser acedida

através de uma variável global especial definida como google.gears.factory. Para

outras funcionalidades espećıficas os Workers podem “pedir” à página principal para

continuar a execução através do envio de mensagens.

Outras funcionalidades

• HttpRequest – Este módulo implementa a especificação W3C XmlHttpRe-quest, definida em [vK08], tornando-a dispońıvel para os workers e para a

página principal.

• Timer – Este módulo implementa a especificação de timers tal como descritopor [Hic08], e torna-os dispońıveis para os workers e para a página principal

2Consultar: http://code.google.com/apis/gears/api_database.html#directories3Consultar: http://code.google.com/apis/gears/security.html

19

http://code.google.com/apis/gears/api_database.html#directorieshttp://code.google.com/apis/gears/security.html

Estado da arte

• Factory – Esta classe é utilizada para instanciar todos os outros objectos daAPI do Gears através do seu método create. Este método pode ser utilizado

com os seguintes parâmetros:

– beta.database

– beta.httprequest

– beta.localserver

– beta.timer

– beta.workerpool

3.1.2 Goggle Gears em dispositivos móveis

O Gears está também dispońıvel em dispositivos Windows Mobile 5 e 6.

Os dispositivos móveis estão, pela sua natureza, frequentemente desconectados

da Internet. Mesmo quando possuem uma ligação as latências na transferência de

dados em redes móveis tornam as aplicações pouco flúıdas, mas o Gears permite

ultrapassar este obstáculo.

O Gears funciona exactamente da mesma forma em dispositivos móveis equipados

com o Windows Mobile 5 e 6 como num computador comum. Se uma aplicação tiver

sido implementado com suporte para o Gears, então também estará preparada para

ser executada num dispositivo móvel, mas as limitações dos browsers dispońıveis

para dispositivos móveis têm que ser consideradas. Isto significa prever as condições

que permitam uma boa usabilidade devido aos pequenos ecrãs destes dispositivos,

bem como o seu suporte limitado dos padrões do DOM, CSS e JavaScript.

3.2 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 produção de conteúdos para a Internet no desenvolvimento de Rich Inter-

net Application (RIA)s. O Adobe AIR mantém uma relação com o browser, mas es-

tende as suas capacidades e tecnologias, permitindo o desenvolvimento de aplicações

também para o ambiente de trabalho, com janelas em tudo semelhantes às 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 aplicações. Para este efeito o Adobe

AIR tem uma aproximação diferente do Gears. Em vez de “estender” o browser

acrescentando-lhe funcionalidades, o AIR permite também o desenvolvimento de

4Adobe - http://www.adobe.com/products/air/

20

http://www.adobe.com/products/air/

Estado da arte

aplicações 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 utilização desta tecnologia permite utilizar o browser ou o próprio runtime

Adobe AIR, como plataforma de execução da aplicação.

Na Tabela 3.1 faz-se uma comparação das funcionalidades dispońıveis de acordo

consoante se escolha o browser ou o desktop como plataforma base para a aplicação.

Uma vez que as aplicações Adobe AIR na plataforma desktop têm um carácter

persistente (são instaladas no computador do utilizador), o Adobe AIR tem um

modelo de segurança que se assemelha com o das tradicionais aplicações desktop

[Ada08]. Este modelo é analisado nas secções 3.2.1 e 3.2.2. O ambiente em que

é executado o browser é restringido à execução de web applications que podem

ser de várias origens (incluindo de origens anónimas ou sem confiança). O Adobe

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

confiança do utilizador.

• HTML – O desenvolvimento de aplicações para o Adobe AIR pode ser feitocom recurso a tecnologias de HTML e Ajax comuns, utilizando as linguagens

de markup existentes, distribúıdas como texto e interpretadas em execução

(runtime);

• Flash – Outra alternativa será a utilização da linguagem Flash. Permite arenderização de gráficos vectoriais e áudio/v́ıdeo com suporte nativo. Utiliza

ActionScript para adicionar maior interactividade com o utilizador;

• Flex – O Flex é uma framework open source para o desenvolvimento de RIAsusando Flash. As aplicações Flex são na realidade Flash, sendo a principal

diferença o ambiente de desenvolvimento.

Como resultado, uma aplicação AIR poderá ser implementada:

• Baseada em Flash ou Flex (aplicações cujo conteúdo base é em ShockWaveFlash (SWF));

• Baseada em Flash ou Flex, também com HTML ou Portable Document Format(PDF). Aplicações cujo conteúdo de base é em Flash/Flex (SWF) com HTML

(HTML, JavaScript, CSS) ou conteúdo PDF inclúıdo;

• Baseada em HTML. Aplicações cujo conteúdo base é em HTML, Javascript,CSS;

• Baseada em HTML utilizando também Flash/Flex ou PDF.

21

Estado da arte

Os utilizadores interagem com uma aplicação AIR da mesma forma que interagem

com outras aplicações com janelas nativas do seu sistema operativo. O runtime é

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

aplicações AIR terão o mesmo aspecto que qualquer outra aplicação para o desktop.

3.2.1 Segurança

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

pode comprometer seriamente a sua segurança. 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 serão

apresentados ao utilizador no momento da instalação. Um outro aspecto ainda

relativo à segurança é o mecanismo de isolamento de cada ambiente (sandbox ).

3.2.2 Assinatura do código

O runtime AIR exige que todas as aplicações estejam digitalmente assinadas. As

assinaturas digitais de código são um processo que visa garantir a integridade da

aplicação e a identidade do seu autor, no momento da instalação. As equipas de

desenvolvimento podem “assinar” uma aplicação utilizando um certificado atribúıdo

por uma Entidade Certificadora (Certification Authority) ou através 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 aplicação quando o código tiver

sido assinado com um certificado que apresente confiança, ou que esteja encadeado

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

a aplicação.

As equipas de desenvolvimento podem também assinar as aplicações com um

certificado auto-atribúıdo (um certificado criado por elas próprias), mas neste caso

o instalador apresentará estas aplicações como sendo de uma origem não verificada.

O AIR utiliza a infraestrutura pública de chaves [Ent07] suportada pelo arquivo

local do sistema operativo. Para que a origem da aplicação seja reconhecida, o

computador onde a aplicação AIR está a ser instalada tem que confiar directamente

no certificado que foi utilizado para assinar a aplicação, ou confiar num certificado

que esteja num encadeamento lógico de certificados confiados, e que se ligue desta

forma ao certificado utilizado para assinar a aplicação.

Todas as aplicações AIR têm caracteŕısticas em comum, independentemente da

tecnologia utilizada para o seu desenvolvimento (HTML/Flex/Flash). No âmbito

de uma aplicação AIR existem um conjunto de APIs que estão 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 aplicação AIR possui também diferentes ńıveis de isolamento, chamados secu-

rity sandboxes, dependendo do tipo de conteúdo que está a ser carregado e do seu

objectivo:

• Isolamento ao ńıvel da aplicação5 – É a raiz de cada aplicação AIR. Esteńı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. Importação

dinâmica de conteúdos remotos é geralmente proibido e as técnicas e mecan-

ismos de geração dinâmica de código são fortemente restringidas. Apenas

conteúdo carregado directamente da directoria base da aplicação poderá ser

colocado neste ńıvel de isolamento.

• Isolamento não espećıfico da aplicação6 – contém todo o outro conteúdoque não tenha sido carregado directamente para o isolamento da aplicação.

Isto inclui conteúdo local e remoto. Este tipo de conteúdo não tem acesso

directo às APIs do AIR e rege-se pelas mesmas regras tal como se tivesse sido

carregado por um browser a partir da mesma localização (por exemplo, HTML

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

fosse acedido a partir do browser).

3.3 Mozilla Prism

3.3.1 XML User Interface Language

O eXtensible User Interface Language (XUL), é uma linguagem de anotação

baseada em XML desenvolvida pela Mozilla Foundation que opera em aplicações

Mozilla multi plataforma, tal como o Firefox. O motor Gecko é a única imple-

mentação completa desta linguagem, que foi desenhada sobre padrões web comuns,

como CSS, JavaScript e o DOM, e permite o desenvolvimento de interfaces gráficas

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

button, entre outros . Infelizmente o XUL não possui qualquer especificação formal

ou implementações de inter-operabilidade para outros motores que não o Gecko. No

entanto a sua implementação é licenciada em código aberto, pelas licenças 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 anotação poderosa baseada em componentes (widgets): O ob-

jectivo do XUL é permitir a construção de aplicações multi-plataforma, em

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

destina ao desenvolvimento de páginas web. Por esta razão o XUL está orien-

tado a componentes tais como janelas, botões, e etiquetas, em vez de páginas,

cabeçalhos de texto, e ligações de hipertexto. Investir tempo e esforço para

atingir este mesmo resultado em aplicações baseadas em DHTML, compromete

frequentemente a complexidade e desempenho da aplicação.

Baseado em padrões O XUL é um dialecto XML baseado no padrão W3C XML

1.0. As aplicações escritas em XUL são também baseadas em especificações

W3C adicionais, como HTML 4.0, CSS, DOM ńıvel 1 e 2; JavaScript 1.5,

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 aplicações

facilmente portáveis entre sistemas operativos nos quais o Mozilla é suportado.

Uma vez que o XUL oferece um ńıvel de abstracção dos componentes gráficos

de interface que disponibiliza, implementa a premissa “um código para todas

as plataformas”. A interface gráfica de todos os produtos centrais Mozilla

(browser, instant messenger, livro de endereços), é escrita em XUL, com um

único código base que suporta todas as plataformas Mozilla.

Separação entre o ńıvel de apresentação e a lógica de negócio: Uma das

maiores preocupações no desenvolvimento para a Internet é a forte ligação

entre estas duas camadas (interface e lógica). Isto constitui um problema sig-

nificativo no desenvolvimento de grandes aplicações, especialmente quando o

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

senvolvimento destas duas partes da aplicação estão muitas vezes espalhadas

por diferentes elementos. O XUL permite uma clara distinção entre a definição

da aplicação cliente e da lógica de implementação (XUL, eXtensible Binding

Language (XBL) e JavaScript), apresentação (CSS e imagens), internacional-

ização (Document Type Definitions (DTDs) e etiquetas de texto em ĺınguas

espećıficas guardados em ficheiros .properties). O esquema gráfico e apre-

sentação de uma aplicação XUL pode ser alterado de forma independente da

sua lógica ou implementação, e a aplicação pode ainda ser traduzida (interna-

tionalization) de forma independente da sua lógica, implementação ou apre-

sentação. Este grau de separação resulta em aplicações que são mais fáceis de

manter pelos programadores e facilmente adaptadas por designers e tradutores.

24

Estado da arte

Fácil adaptação Outro benef́ıcio que advém do ńıvel de separação entre lógica

de negócio e apresentação oferecido pelo XUL é a facilidade com que se pode

adaptar uma aplicação para diferentes clientes ou grupos de utilizadores. Um

programador pode utilizar a mesma aplicação base e adaptá-la consoante as

necessidades, através de diferentes temas (skins) e ficheiros de ĺınguas. Desta

forma, uma aplicação escrita e desenvolvida em Inglês pode ser rapidamente

traduzida para Português e distribúıda com outra aparência mais apropriada

ao cliente alvo.

3.3.2 Prism

O Mozilla Prism é um browser simplificado e “interpretador” de XUL (também

designado por XULRunner) que acolhe web applications sem a interface gráfica ha-

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

(SSB). Um SSB é uma aplicação com um browser embebido, desenhado para exe-

cutar apenas uma web application. Não possui os menus e barras de ferramentas

habituais. Um SSB tem uma integração com o sistema operativo e com o desktop

muito mais estreita do que uma web application acedida através de um browser, uma

vez que é executado em janela própria.

O Prism resulta de uma experiência da Mozilla e visa reduzir as diferenças entre

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

a experiência do utilizador. Numa apresentação oficial é dito que “[o Prism] pretende

ser uma ponte entre as diferenças que existem entre as aplicações tradicionais de

desktop e as web applications, explorando novos modelos de usabilidade, enquanto

que a linha que as separa se continua a definir” [Lab07].

3.4 HTML 5

A especificação HTML 5 [Hic08], que se encontra em fase de desenvolvimento

pelo grupo WHATWG, pretende ser uma norma de substituição dos padrões HTML

4, XHTML 1.x 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. Não sendo propriamente uma

tecnologia –mas antes uma especificação –é aqui mencionada por ter servido como

referência a diversas implementações de funcionalidades offline, e por se considerar

que venha a ter um impacto significativo nas implementações de diversos browsers.

Dion Almaer defendeu no seu blogue que o Gears era uma implementação do

HTML 5. No seu artigo “Gears as a bleeding-edge HTML 5 implementation” [Alm08]

o autor diz que ambos –o Gears e o HTML 5 –pretendem dar à web caracteŕısticas

25

Estado da arte

semelhantes e não encontrar motivo de “competição” entre as duas, mas que en-

quanto o HTML 5 é uma especificação o Gears é uma implementação.

No entanto, também é verdade que o HTML 5 cobre muitos outros pontos para

além das OWA que saem completamente fora do âmbito do Gears. Se esta es-

pecificação atingir um estado de maturidade que possibilite a sua adopção pelos

principais browsers, tornando nativo do browser o suporte OWA, então deixará de

fazer sentido a existência de uma extensão como o Gears.

A especificação 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 “cache” HTTP que garante a disponibilidade das aplicações mesmo quando

o utilizador não possui uma ligação à Internet.

Estas caracteŕısticas são as bases da tecnologia das OWA e têm correspondência

com os pontos analisados nas secções 3.1.1 e 3.1.1

3.5 Web applications que usam funcionalidades offline

Nesta secção apresentam-se algumas web applications que actualmente disponi-

bilizam funcionalidades offline. Estas aplicações foram escolhidas para uma análise

mais pormenorizada por utilizarem o Gears, que tal como descrito na secção 4, foi

a tecnologia escolhida para o projecto.

3.5.1 Google Reader e Google Docs

O Google Reader7 é um leitor de feeds RSS. Permite gerir a subscrição de vários

sites simultaneamente que disponibilizem conteúdos neste formato e foi a primeira

web application da Google com uma versão offline publicamente acesśıvel (desde

Junho de 2007).

O Google Reader implementa o modo “utilizador decide”, oferecendo na sua

interface um botão que permite alternar entre os modos online e offline.

O Google Docs8 é uma web application que permite a criação e edição de doc-

umentos de texto, folhas de cálculo e apresentações. Era já público desde Janeiro

de 2008 que o Google estava a desenvolver uma versão OWA desta aplicação, mas o

acesso a uma versão experimental só foi posśıvel a partir de 31 de Maio de 2008.

7Google Reader - http://reader.google.com/8Google Docs - http://docs.google.com/

26

http://reader.google.com/http://docs.google.com/

Estado da arte

A implementação das funcionalidades offline nestas duas aplicações seguiu difer-

entes aproximações, principalmente porque o Google Reader apresenta ao utilizador

informações que são fornecidas por fontes externas, enquanto que no Google Docs,

a informação é criada e editada pelo utilizador sobre a forma de documentos.

A diferente origem da informação implica que no Google Reader seja necessário

prever casos de excepção, tal como existirem demasiados itens que necessitam de

ser transferidos para o cliente. Não 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 às acções do utilizador o Google Reader apenas

transfere para o cliente os dois mil itens mais recentes na transição para o modo

offline.

3.5.2 Remember the Milk

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

Australiana que proporciona funcionalidades de agenda, gestão de tempo e de tare-

fas e foi uma das primeiras aplicações independentes do Google a adoptar o Gears

para acessos em modo offline. Permite que os seus utilizadores façam uma gestão

de tarefas agrupando-as em listas, adicionando-lhes campos de informação adicional

ou dando-lhes informação geográfica (recorrendo ao serviço 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, publicação

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

diferentes ńıveis de permissões de acesso definidos pelo utilizador.

3.5.3 MySpace e WordPress.com

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

mente que vai disponibilizar uma versão 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 rápido que a sua versão online.

O serviço de blogs Wordpress.com anunciou também o ińıcio da utilização desta

tecnologia com o fim de melhorar o desempenho. A versão que utiliza esta tecnologia

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

ter preferência sobre os seus congéneres online, e que permitem acelerar o processo

de carregamento da aplicação e visualização de blogs.

9Remember The Milk – http://www.rememberthemilk.com/10Google Maps – http://maps.google.com

27

http://www.rememberthemilk.com/http://maps.google.com

Estado da arte

O MySpace e o Wordpress.com são dois exemplos da utilização da tecnologia

OWA para optimização de web application já existentes. Sem pretenderem disponi-

bilizar uma versão que seja totalmente offline fazem uso do Gears para armazenar no

cliente parte dos recursos frequentemente acedidos na visualização das suas páginas.

3.6 Escolha da tecnologia

Após a análise das tecnologias apresentada nas secções 3.1 a 3.4, foi necessário es-

tudar a adequação de cada uma delas ao projecto em questão. 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 execução do projecto quando utilizado

na sua vertente desktop, tal como exposto na Tabela 3.1, mas a utilização desta

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

municação (troca de mensagens XML ou JSON). A vertente web do Adobe AIR

foca-se mais especificamente nas Rich Internet Applications e permite a reutilização

do código já existente (exigindo naturalmente a sua adaptação e a implementação

das funcionalidades pretendidas).

A tecnologia escolhida para a realização deste trabalho foi o Gears, sendo que

um dos principais factores a influenciar esta opção foi a liberdade introduzida pela

sua licença Berkeley Software Distribution (BSD)11.

Considerou-se o funcionamento desta ferramenta extremamente adequando à

aplicação no WOW!, uma vez que o seu principal objectivo é precisamente tornar

posśıvel a execução offline de uma página web e por virtude deste facto o Gears tem

uma API concisa e de simples aplicação prática, uma vez que não possui quaisquer

outros elementos distractores. O funcionamento do seu ManagedResourceStore ex-

emplificado na Figura 3.1, com a capacidade de actualização de recursos definidos

num ficheiro manifesto especificado em JSON pesou também nesta decisão.

11Sobre a licença BSD consultar: http://www.opensource.org/licenses/bsd-license.php e http://www.linfo.org/bsdlicense.html

28

http://www.opensource.org/licenses/bsd-license.phphttp://www.linfo.org/bsdlicense.htmlhttp://www.linfo.org/bsdlicense.html

Estado da arte

Figura 3.1: Esquema UML do processo efectuado pelos recursos do Gears do tipoManagedResourceStore para a actualização dos conteúdos definidos no ficheiro manifesto.

29

Estado da arte

Funcionalidade RIAs no browser RIAs no desktopDisponibilidadeda aplicação

As aplicações podem ser facil-mente exploradas e utilizadas

As aplicações quando instal-adas têm maior grau de fun-cionalidades e persistência

Instalação Não é necessário qualquer tipode instalação.

As aplicações são instaladasatravés do browser, ou descar-regadas e instaladas comouma aplicação tradicional.

Actualizações Aplicações são actualizadascarregando conteúdos paraum website.

O AIR disponibiliza uma APIque permite que as aplicaçõessejam actualizadas de umaforma

Sistemas opera-tivos suportados

As aplicações podem ser exe-cutadas em diversos sistemasoperativos e browsers.

As aplicações são multi-plataforma e podem serinstaladas e executadas emdiversos sistemas operativos ebrowsers.

Linguagens deprogramação

Javascript é disponibilizadopelo browser e ActionScripté disponibilizado pelo AdobeFlash Player.

Máquinas virtuais deJavascript e ActionScriptcompat́ıveis com o browser.

Capacidade deexecução embackground

As RIAs podem ser execu-tadas numa janela do browser.

As aplicações podem ser ex-ecutadas em background edisponibilizar notificações talcomo uma aplicação tradi-cional.

Persistência A actividade está limitada àsessão do browser. Quando obrowser é encerrado, toda ainformação é descartada.

As aplicações são instaladas eestão dispońıveis no desktop.Podem armazenar informaçãolocalmente e estão dispońıveisoffline.

Integração com odesktop

Integração com o desktop lim-itada devido a restrições im-postas pelo browser.

As aplicações podem acederao sistema de ficheiro, ao clip-board, eventos, notificações,etc.

Controlo da inter-face com o uti-lizador

As aplicações são acedidasatravés de uma janela dobrowser, que tem os seuspróprios controlos e visualgráfico.

As aplicações têm um vi-sual gráfico próprio, em janelaprópria.

Armazenamentode dados

As aplicações têm armazena-mento limitado, que pode serreescrito pelo browser.

As aplicações têm acesso à to-talidade do espaço dispońıvellocalmente, e a uma base dedados com a possibilidade deencriptação.

Tabela 3.1: Comparação das funcionalidades oferecidas pelo Adobe AIR para as platafor-mas web e desktop

30

Estado da arte

Aplicação Modo de execução utilizadoGoogle Reader Utiliza o modo “utilizador decide”, disponibilizando

ao utilizador um botão para alternar entre os modosonline e offline. Como lida com informação recol-hida de fontes externas, de natureza frequentementeefémera, o processo de sincronização apenas transfereos dois mil itens mais recentes quando passa ao es-tado offline. Neste modo são ainda guardadas in-formações de itens lidos e etiquetas atribúıdas quesão sincronizadas com o servidor quando o utilizadorvoltar a activar estado online.

Google Docs Utiliza o modo “aplicação decide”, permitindo que outilizador edite os conteúdos de documentos de texto,folhas de cálculo e de apresentações independente-mente do estado da ligação, desde o momento em queas funcionalidades offline são activadas. A aplicaçãofaz pequenas sincronizações com o servidor sempre quenecessário.

Remember the Milk Utiliza um modo h́ıbrido entre “aplicação deci

o ine web applications - repositório aberto da …...sempre o estado real da aplica˘c~ao, podendo...

Documents