Post on 02-Jan-2020
Faculdade de Engenharia da Universidade do Porto
Offline Web Applications
Enabling offline execution on the WOW! product
João Gonçalves da Costa
Relatório de Projecto realizado no Âmbito do
Mestrado Integrado em Engenharia Informática e Computação
Orientador: Teresa Galvão Dias (PhD.)
Julho de 2008
c© João Gonçalves da Costa, 31 de Julho de 2008
Offline Web Applications
João Gonçalves da Costa
Relatório de Projecto realizado no Âmbito do
Mestrado Integrado em Engenharia Informática e Computação
Aprovado em provas públicas pelo júri:
Presidente: Pedro Ferreira do Souto (PhD)
Arguente: Artur Pereira (PhD)
Vogal: Teresa Galvão Dias (PhD)
27 de Julho de 2008
Resumo
Este projecto teve como objectivo o estudo das Offline Web Applications (OWAs)e da sua implementação em web applications já existentes. Neste âmbito, foi feitauma avaliação da aplicação desta tecnologia no WOW!, uma plataforma integradade gestão de ordens de trabalho, desenvolvida pela Critical Software S.A. ao longodos últimos 6 anos, e implementada uma prova de conceito que permite a utilizaçãode um conjunto de funcionalidades base desta web application, independentementedo estado da ligação à Internet.
O conceito das OWAs enquadra-se numa tecnologia de Internet que permiteo acesso a um website através do browser mesmo na ausência de uma ligação à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 compreensão dos problemas associados àsua implementação e respectivas soluções e também da avaliação dos benef́ıcios dautilização desta tecnologia para os utilizadores finais.
A evolução das tecnologias associadas à Internet, a que se assiste continua-mente, impulsionou também evolução da forma como a informação é produzida,distribúıda e armazenada. Surgiram novas web applications oferecendo funcionali-dades de criação e edição de conteúdos, que trouxeram consigo a vantagem de tornarposśıvel o acesso à informação a partir de qualquer lugar, mas também a desvan-tagem de tornar a ligação à Internet uma condição necessária para que isto aconteça.A proliferação destas aplicações, a crescente utilização da Internet [Gro08] e a adesãoaos seus serviços indiciam a existência de uma dependência cada vez maior de umaligação, que nem sempre existe.
As OWAs vêm assim colmatar esta falha, colocando no lado do cliente parte dainformação que até agora vinha a ser armazenada no servidor e tornando não sóposśıvel a sua consulta offline, como também reduzindo a carga no servidor, umavez que reduz as transferências de informação.
Pretende-se neste documento apresentar diferentes formas de como a utilizaçãoda tecnologia OWA pode beneficiar as web applications de hoje, melhorando o seudesempenho e dando-lhes novas possibilidades de execução, 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 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
iv
Agradecimentos
A realização e os objectivos alcançados neste projecto não teriam sido posśıveissem a colaboração de inúmeras pessoas. Agradeço profundamente a todos os quecontribúıram directa ou indirectamente para o seu sucesso:
À minha orientadora, Professora Teresa Galvã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 Mauŕıcio Costa e o Fábio Matos,que contribúıram para a minha a minha integração na Critical Software e que sempresouberam responder a todas as minhas questões,
A todos os que constituem a CSW Porto, pelo fantástico ambiente de amizadeque me proporcionaram,
Aos colegas de curso e a todos os que me auxiliaram na revisão deste documento,
Os meus sinceros agradecimentos!
João Gonçalves da Costa
v
vi
Conteúdo
1 Introdução 11.1 Enquadramento . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11.2 Motivação . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21.3 Âmbito . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31.4 Objectivos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31.5 Estrutura do documento . . . . . . . . . . . . . . . . . . . . . . . . . 3
2 Enquadramento do Projecto 52.1 Evoluçã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 Evolução na Internet . . . . . . . . . . . . . . . . . . . . . . . . . . . 82.2.1 Páginas web estáticas . . . . . . . . . . . . . . . . . . . . . . . 92.2.2 Páginas web interactivas e páginas web dinâmicas . . . . . . . 92.2.3 Web 2.0 e Ajax . . . . . . . . . . . . . . . . . . . . . . . . . . 11
2.3 Offline Web Applications . . . . . . . . . . . . . . . . . . . . . . . . . 132.4 Comparação . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
3 Estado da arte 173.1 Gears . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
3.1.1 Arquitectura . . . . . . . . . . . . . . . . . . . . . . . . . . . . 173.1.2 Goggle Gears em dispositivos móveis . . . . . . . . . . . . . . 20
3.2 Adobe AIR . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 203.2.1 Segurança . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 223.2.2 Assinatura do có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
CONTEÚDO
4 Desenvolvimento 334.1 Como ficar offline . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
4.1.1 Funcionalidades dispońıveis em modo offline . . . . . . . . . . 344.2 Modos de execução . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
4.2.1 Modo “utilizador decide” . . . . . . . . . . . . . . . . . . . . . 364.2.2 Modo aplicação decide . . . . . . . . . . . . . . . . . . . . . . 364.2.3 Modo “aplicação assume o estado offline” . . . . . . . . . . . 37
4.3 Sincronização de dados . . . . . . . . . . . . . . . . . . . . . . . . . . 384.3.1 Quando sincronizar? . . . . . . . . . . . . . . . . . . . . . . . 39
4.4 WOW! . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 404.5 Visão geral sobre a arquitectura do WOW! . . . . . . . . . . . . . . . 414.6 WOW! Offline . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
4.6.1 Modo “aplicação decide” com detecção automática da ligação 434.6.2 Implementação do modo “utilizador decide” . . . . . . . . . . 454.6.3 Especificação do modo “aplicação assume o estado offline” . . 48
5 Resultados e Futuros Desenvolvimentos 515.1 Resultados Obtidos . . . . . . . . . . . . . . . . . . . . . . . . . . . . 515.2 Trabalho Futuro . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
6 Conclusões 556.1 Conclusões . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
Referências 59
A Screenshots 61
viii
Lista de Figuras
2.1 Arquitectura de um sistema thin-client em duas camadas (à esquerda)e em três camadas (à direita). Note-se a inclusão do servidor (main-frame) na definição das camadas desta arquitectura, devido à fortedependência cliente-servidor. . . . . . . . . . . . . . . . . . . . . . . . 9
2.2 Arquitectura de um fat-client em duas camadas (à esquerda) e emtrês camadas (à direita). . . . . . . . . . . . . . . . . . . . . . . . . . 10
2.3 Comparação do modelo de web aplications śıncrono, páginas estáticase interactivas abordados nas secções 2.2.1 e 2.2.2, com o modelo deweb applications Ajax (asśıncrono) abordado na secçã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 actualização dos conteúdos definidosno ficheiro manifesto. . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
4.1 Exemplo de uma arquitectura de uma web application sem uma ca-mada de abstracçã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 abstracçã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 abstracção de dados e um data switch. Figura adaptada dehttp: // gears. google. com/ . . . . . . . . . . . . . . . . . . . . . 35
4.4 Esquema gráfico ilustrando uma OWA executando no browser uti-lizando um modo de execução do tipo “aplicação decide”, com de-tecção automática do estado da ligação via pedidos Ajax asśıncronosa cada cinco segundos. . . . . . . . . . . . . . . . . . . . . . . . . . . 37
4.5 Detalhe de um conjunto posśıvel de estados e respectivas transiçõespara uma dada ordem de trabalho no WOW!, desde a sua submissãono sistema até à sua conclusão em fecho ou cancelamento. Esta figurarepresenta apenas um exemplo, já que o mapa de estados para umaordem de trabalho é dinâ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 página inicial do WOW apresenta um resumo das últimas ordensde trabalho enviadas e recebidas. Na imagem pode-se observar atransição do estado online para offline. . . . . . . . . . . . . . . . . . 44
4.7 Ilustraçã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 máquinaremota, consoante se verificarem ou não as condições expressas noponto 3.1.1. É representado um acesso a uma base de dados local(fornecida pelo Gears), mas a sua utilização é opcional. . . . . . . . . 45
4.8 Neste exemplo do modo “aplicação decide”, o teste da ligação é feitoé feito a cada cinco segundos. O resultado deste teste não reflectesempre o estado real da aplicação, podendo levar a aplicação a tercomportamentos indesejáveis. Na figura assinala-se um peŕıodo detempo no qual a representação interna do estado da ligação não cor-responde à realidade. . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
4.9 Página de visualizaçã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 Diálogo apresentado ao utilizador na primeira activação das funcional-idades offline no Google Docs & Spreadsheets. . . . . . . . . . . . . . 61
A.2 Na activação das funcionalidades offline é também oferecida a possi-bilidade da criação de alguns atalhos, por exemplo, no ambiente detrabalho. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
A.3 O Google Docs mantém a todo o momento a possibilidade de alteraçãodestas definições, ou da anulação dos serviços offline para um dadocomputador. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
A.4 Após a instalação do Gears qualquer visita ao Remember The Milkdespoleta uma sincronização que ocorre automaticamente e sem ne-cessidade de intervenção por parte do utilizador. . . . . . . . . . . . . 63
A.5 Após completar a sincronização de dados, mesmo que a ligação àInternet seja perdida o Remember the Milk continua dispońıvel nobrowser (com excepção das funcionalidades que pela sua naturezaexigem uma ligação, como por exemplo: partilha de tarefas e enviode convites.) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
x
Lista de Tabelas
2.1 Comparação entre thin-clients e fat-clients . . . . . . . . . . . . . . . 7
3.1 Comparação das funcionalidades oferecidas pelo Adobe AIR para asplataformas web e desktop . . . . . . . . . . . . . . . . . . . . . . . . 30
3.2 Resumo da utilização de tecnologias OWA em algumas web applica-tions consideradas na análise do estado da arte. . . . . . . . . . . . . 31
xi
LISTA DE TABELAS
xii
Glossário
fat-client Cliente que nã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 acções do utilizador(navegação e introdução de informação)afectam o estado lógico da aplicaçã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 criação de páginas webdinâ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
Glossário
ECMAScript Padrão de linguagem de programaçãodefinido pela Ecma International que orig-inou o JavaScript e o JScript.
24
Flash Conteúdo interactivo de um ficheiro emformato SWF. É desenvolvido pela Adobee visualizado através do Adobe FlashPlayer.
21
Flex Framework baseada em XML e Action-Script desenvolvida pela Adobe para a pro-gramaçã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 É 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)(também designado por XULRunner) queacolhe web applications sem a interfacegrá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
Glossário
PHP Linguagem interpretada pelo servidorque permite a criação de páginas webdinâmicas, mas que pode também ser in-vocada a partir da linha de comandos.
11
página web estática Pá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 ás desktop applications, masque mantém a informação no lado do servi-dor
5, 15,20, 28
RSS Really Simple Syndication 27
SLA Service Level Agreement 40SQLite Segundo a definiçã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 gestã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
Glossário
xvi
Caṕıtulo 1
Introdução
Neste caṕıtulo enquadra-se o tema do projecto, introduzindo alguns dos conceitos
nos quais se baseia. Apresentam-se as motivações, âmbito, objectivos e a estrutura
deste documento.
1.1 Enquadramento
A Internet foi originalmente concebida para ser um espaço de partilha de in-
formação, onde pessoas (através de máquinas) pudessem comunicar. Na sua origem,
as páginas eram estáticas, constitúıdas por texto formatado em HyperText Markup
Language (HTML) e ligadas entre si [BL96]. Hoje encontramos conteúdos cada vez
mais complexos e dinâmicos, incluindo som, v́ıdeo ou streams multimé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 várias das seguintes
categorias:
• Documento – um website essencialmente estático, onde alterações a umaparte do conteúdo não tem implicações no seu comportamento.
• Base de dados – um directório de informação organizada em categorias.
• Aplicação – um website dinâmico, que utiliza uma linguagem executada ouinterpretada do lado do servidor, e que processa as acções ou informação in-
troduzida pelo utilizador para fornecer um serviço ou nova informação.
A última destas categorias constitui aquilo que é normalmente designado por
web application. O conceito utilizado ao longo deste documento é o mesmo que
o introduzido por Jim Coallen em [Con99], que define web application como um
1
Introdução
sistema web (servidor, rede HyperText Transfer Protocol (HTTP), browser) onde
acções do utilizador (navegação e introdução de informação) afectam o estado lógico
da aplicação. A sua definição tenta estabelecer que uma web application é um
sistema de software com estado de negócio1, e que a sua interface de interacção com
o utilizador é distribúıdo através de um sistema web.
1.2 Motivação
A quantidade de informação que é produzida e armazenada com recurso a es-
tas web applications dispońıveis online, tais como e-mail, blogues ou mesmo docu-
mentação, tornam por vezes a disponibilidade de ligação uma condição necessária
à produtividade e, como consequência desta barreira, muitos potenciais utilizadores
opõem-se à adopção de produtos web em detrimento das tradicionais desktop appli-
cations.
Assegurar o acesso a uma ligação de Internet é hoje muito mais fácil. A Internet
móvel é já uma realidade e encontra-se amplamente divulgada, mas continuam a
existir diversas situações nas quais os utilizadores estão privados de uma ligação
à Internet, tais como uma viagem de metro ou de avião, ou quando se encontram
deslocados do seu páıs de origem e não possuem nenhum plano de subscrição.
Uma OWA consiste numa web application que para além de manter todas as
caracteŕısticas anteriores, se mantém dispońıvel mesmo na ausência de uma ligação
à Internet e surge como uma tentativa de estreitar as barreiras existentes entre a
web e o desktop. Isto significa que deverá existir um mecanismo capaz de assegurar
a manutenção do estado lógico da aplicação quando a ligação com o servidor é
quebrada, permitindo ao utilizador continuar a utilizar a aplicação, e que será capaz
de informar o servidor do estado em que a aplicação se encontra quando a ligação for
reposta. A principal vantagem que advém desta possibilidade é evidente: eliminar
a necessidade da existência de uma ligação à Internet para que a aplicação possa ser
utilizada.
Por outro lado, a vontade de integraçã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 reflexão “para além
do browser” e a uma adaptaçã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 aproximação tornar posśıveis
interacções entre o desktop e o browser, tais como arrastar um ficheiro para um
formulário web de upload de conteúdos, melhor suporte para o histórico do clipboard
ou ainda o acesso ao sistema de ficheiros local. Atingir estes objectivos reflecte-se
1NT. business state
2
Introdução
num novo paradigma, que reúne as vantagens das web applications, tais como os
updates instantâneos ou o facto de não ser necessária nenhuma instalação, e das
desktop applications, como por exemplo: persistência no armazenamento de dados,
acesso a funcionalidades do sistema operativo ou integração e interacção com outras
aplicações, sejam elas web applications ou desktop applications.
1.3 Âmbito
Este projecto foi realizado na Critical Software S.A. no âmbito do Mestrado
Integrado em Engenharia Informática e Computação (MIEIC) da Faculdade de En-
genharia da Universidade do Porto (FEUP) entre os meses de Fevereiro e Julho de
2008.
1.4 Objectivos
São objectivos deste projecto:
1. Estudar e documentar o tema das OWAs acompanhando os últimos desenvolvi-
mentos nesta matéria.
2. Analisar o estado da arte, fazendo uma análise cŕıtica e objectiva sobre as
diversas metodologias existentes.
3. Implementar uma prova de conceito, que permita a execução offline de uma
web application, documentando todo o processo.
4. Estudar a possibilidade de permitir interacção com a aplicação (inserções e
alteraçõ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 nã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 está organizado em diferentes secções, apresentando o projecto
numa sequência lógica organizada da seguinte forma:
No caṕıtulo 1 faz-se uma breve apresentação do conceito OWAs e do contexto em
que surge. Apresenta-se também a estrutura do documento e definem-se os
termos e acrónimos utilizados.
3
Introdução
No caṕıtulo 2 faz-se uma descrição da evolução das tecnologias que antecedem as
OWAs e das vantagens e desvantagens de cada uma, como forma de enquadra-
mento.
No caṕıtulo 3 analisa-se o estado da arte nesta matéria. Introduzem-se diversas
tecnologias directamente relacionadas com o tema deste projecto, exemplos de
aplicações que as usam e as razões que fundamentam as escolhas de tecnologias
efectuadas.
O caṕıtulo 4 contem o desenvolvimento do projecto. Analisa-se a plataforma
WOW! de gestão integrada de ordens de trabalho, a tecnologia escolhida e
a forma como foi utilizada para implementar a capacidade de execução offline.
O caṕıtulo 5 descreve os resultado obtidos, comparando-os com as expectativas
iniciais do projecto e apresenta desenvolvimentos futuros e possibilidades de
continuação/aplicação do conhecimento adquirido.
No caṕıtulo 6 apresentam-se as conclusões.
4
Caṕıtulo 2
Enquadramento do Projecto
Neste caṕıtulo apresenta-se um breve resumo da evolução das arquitecturas de
software cliente-servidor e a forma como estas se comparam à evoluçã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 às páginas web
estáticas, a evolução dos fat-clients às páginas interactivas, Web 2.0 e Ajax, e
defende-se que as OWA constituem um próximo passo lógico e evolutivo, aproxi-
mando a web do desktop. Referem-se ainda os principais factores que justificam a
importância das OWAs e a estreita relação que têm com as Rich Internet Application
(RIA)s.
2.1 Evolução das arquitecturas de software
Os termos thin-client e fat-client são utilizados quer para descrever arquitecturas
lógicas (de software), quer para descrever arquitecturas f́ısicas (de hardware). Neste
caṕıtulo, excepto quando seja dada indicação em contrário, estes termos referem-se
sempre a uma arquitectura ló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 eqúıvocos, em especial na secção 2.1.3,
especifica-se em cada caso qual o sistema estudado.
2.1.1 Thin-clients
Um thin-client é 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 sáıda de in-
formaçã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 ińıcio das aplicações cliente-servidor.
No ińıcio da história da computação, terminais ligavam-se directamente a main-
frames responsáveis por todo o processamento. Nesta arquitectura, era necessário
desenvolver duas aplicações distintas: uma aplicação central no servidor (main-
frame), responsável pela gestão de toda a informação e por todas as operações de
comunicação, e uma aplicação de visualização, instalada no cliente (terminal). O
papel destes terminais era apenas disponibilizar ao utilizador um meio de comu-
nicação (entrada e sáıda) e apresentação dos resultados do servidor. Não tinham
um papel activo no cálculo nem na lógica de negócio e frequentemente não tinham
também nenhum mecanismo de armazenamento de dados.
Como vantagens, esta arquitectura apresenta uma reduzida necessidade de con-
figuração e manutenção do lado do cliente. Uma vez que o centro do processamento
e manipulação de dados ocorre no servidor, existe também uma centralização da
informação [NJN00] que introduz um ponto cŕıtico de falha1. Actualizações e novas
funcionalidades são fáceis de distribuir, uma vez que requerem apenas alterações no
servidor [Gro02a].
2.1.2 Fat-clients
Contrastando com os thin-clients, nesta arquitectura os clientes implementam
já uma parte da lógica de negócio e são responsáveis pelo processamento de dados.
Estes fat-clients vieram responder à necessidade crescente de aplicações com um
ńıvel de interactividade e capacidade de configuração maior que as oferecidas pela
arquitectura thin-client , descrita na secção 2.1.1. Apesar de manterem a sua de-
pendência do servidor, podem também ser executados sem uma conexão activa uma
vez que dispõe de armazenamento de dados local, o que lhes confere a capacidade
de persistência de dados e do estado de execução entre cada sessão.
Foi disponibilizando este controlo sobre o estado da aplicação, bem como acesso
a recursos locais (por exemplo, sistema de ficheiros e perifé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 aplicação e uma actualização ao servidor implicava in-
variavelmente uma actualização manual também no cliente. Uma vez que nem todos
1NT.: single point of failure
6
Enquadramento do Projecto
Thin-clients Fat-clientsNã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.
Não mantém registo do estado lógicoda aplicação entre duas sessões de uti-lização.
O acesso ao armazenamento localpermite-lhe manter registo do estadológico da aplicação entre duas sessões.
O thin-client não necessita de qualquerinstalação, estando “pronto a utilizar”.
É geralmente necessário instalar aaplicação para poder interagir com oservidor
Qualquer update no servidor reflecte-seimediatamente por todos os clientes.
Embora a aplicação cliente possa aler-tar para existência de novas versões, asactualizações têm que ser manualmenteinstalados pelo cliente.
O software do cliente destina-se apenasà apresentação de dados e comunicaçãocom o servidor, sendo portanto, de sim-ples implementação.
Como o software do cliente toma parteactiva no processamento de dados,a sua implementação requer cuidadosadicionais.
Grande mobilidade, uma vez que todaa informação é mantida no servidor
Parte da informação poderá estar ape-nas do lado cliente, pelo que existemalgumas restrições à sua mobilidade.
Tabela 2.1: Comparação entre thin-clients e fat-clients
os utilizadores actualizam regularmente as suas aplicações, o servidor tem que estar
preparado para lidar com versões antigas2, ou descontinuar os seus serviços a uma
parte da sua comunidade de utilizadores até que estes actualizem os seus sistemas.
Como os utilizadores passam a utilizar os seus recursos locais para armazenamento
de dados, as alterações que não sejam sincronizadas com o servidor estão apenas
dispońıveis nos seus computadores pessoais, o que introduz uma restrição à mobili-
dade.
Pode-se afirmar que as vantagens dos thin-clients são as desvantagens dos fat-
clients, e que as vantagens dos fat-clients sã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 serviços e um servidor como um prestador de serviços, tal como
definido por [Sch96] e [Sad97].
2NT. backward compatibility
7
Enquadramento do Projecto
As arquitecturas cliente-servidor são categorizadas pela modularização com que
são desenhadas, sendo consideradas as seguintes camadas:
1. Interface gráfica (front-end) através da qual os utilizadores interagem com
a aplicação. Quando este módulo é implementado separadamente dos outros
dois constitui uma aplicação thin-client por si só, uma vez que não implementa
regras de negócio (embora possa definir validações de formulários de inserção de
dados, por exemplo). A informação introduzida pelo utilizador é enviada para
o servidor, que processa o seu pedido e retorna uma resposta. Este processo
repete-se até que o utilizador atinja o seu objectivo ou se desligue do sistema;
2. A lógica de negócio, também designada por camada intermédia, que imple-
menta as regras de aceitação e validação de todos os dados introduzidos pelo
utilizador. É também a plataforma de comunicação que une a camada superior
de visualização com a camada de acesso a dados;
3. A camada de dados inclui quer o sistema de persistência de dados, onde são
armazenados os dados relevantes, como também os mecanismos necessários
para a sua pesquisa, selecção e alteraçã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 três camadas,
dependendo apenas da forma como o servidor for implementado. No caso de, na
implementação do servidor não se distinguir a camada de acesso a dados da camada
da lógica de negócio, são designados por sistemas de duas camadas. Caso seja feita
esta distinção, são designados por sistemas de três camadas. Ambos os casos são
ilustrados na Figura 2.1.
Historicamente, os fat-clients eram implementados numa arquitectura em duas
camadas. Possúıam apenas um módulo de visualização de dados, designado por
camada de interface, e um módulo que implementava toda a lógica de negócio e
regras de acesso à base de dados. No entanto, com a introdução de ligações mais
rápidas e de computadores pessoais com maior capacidade de processamento e so-
bretudo devido à complexidade crescente das aplicações, a lógica de negócio e a
camada de acesso a dados tornaram-se independentes. Este modelo é designado por
arquitectura em três camadas e é ilustrado na Figura 2.2.
2.2 Evolução na Internet
Ao analisar a evolução das arquitecturas das aplicações desenvolvidas para a
Internet, podemos encontrar um paralelismo com a história da arquitectura de soft-
ware.
8
Enquadramento do Projecto
Figura 2.1: Arquitectura de um sistema thin-client em duas camadas (à esquerda) e emtrês camadas (à direita). Note-se a inclusão do servidor (mainframe) na definição dascamadas desta arquitectura, devido à forte dependência cliente-servidor.
2.2.1 Páginas web estáticas
Uma página web estática devolve sempre a mesma resposta a todos os pedidos,
para todos os utilizadores e em qualquer contexto, utilizando o hipertexto como
forma de ligação entre diversas páginas estáticas.
A informação é armazenada num servidor, e o papel do cliente é apenas a apre-
sentação da informação. Esta forma de disponibilização de informação pode assim
ser comparada com os thin-clients descritos na secção 2.1.1: o utilizador acede a
um website estático para visualizar informação sem que o cliente tome parte no
processamento. A única diferença é que no caso da web estática a informação ap-
resentada é sempre a mesma, enquanto que nos thin-clients era frequente existir a
possibilidade de inserção de dados no cliente e após o seu processamento servidor,
nova informação poderia ser apresentada. O hipertexto é utilizado para ligar as
páginas entre si numa rede de conteúdos relacionados, e a navegação śıncrona era
feita através de cliques do rato: a cada clique uma nova página era apresentada.
Este modelo śıncrono é ilustrado na Figura 2.3.
2.2.2 Páginas web interactivas e páginas web dinâmicas
O JavaScript é uma linguagem interpretada de scripting que tem os browsers
como principal ambiente de acolhimento. Os browsers utilizam uma Application
9
Enquadramento do Projecto
Figura 2.2: Arquitectura de um fat-client em duas camadas (à esquerda) e em três camadas(à direita).
Programming Interface (API) pública para criar “objectos” responsáveis por reflectir
e disponibilizar o Document Object Model (DOM) para o motor de JavaScript.
A utilização mais frequente desta linguagem é a escrita de funções que são em-
bebidas ou inclúıdas em páginas web e que interagem com o DOM. Uma vez que o
JavaScript é executado localmente (na máquina do cliente e não no servidor) é capaz
de responder rapidamente a acções do utilizador, tornando a execução de aplicações
no browser mais flúıdas; o JavaScript pode também detectar acções do utilizador
que o HTML nã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 também a suportar uma versão semelhante desta
linguagem (hoje, todos os principais browsers suportam esta tecnologia).
Esta inovação permitiu tornar os websites mais interactivos, mas a sua utilização
esteve confinada apenas a este propósito durante um longo peŕıodo. As páginas
passaram a responder activamente a acções do utilizador (sendo uma das utilizaçõ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
Enquadramento do Projecto
mais vulgares a validação de formulários) mas continuaram essencialmente estáticas.
O JavaScript ainda não era, nesta altura, utilizado para processar dados.
També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 páginas dinâmicas, capazes de responder a inserção de dados ou outros pedidos
determinados por acções do utilizador. As páginas tornaram-se aplicações, web ap-
plications.
Uma definição tradicional de web application é: um conjunto de páginas web
logicamente agrupadas e geridas por uma única entidade, que têm como pontos de
entrada formulários de inserção de dados (web forms). Uma web application não é
mais do que uma aplicação que é acedida através de um browser. Têm geralmente
uma arquitectura lógica em três (interface, lógica de negócio e camada de dados)
camadas e estão armazenadas num servidor.
Há dois tipos de web applications:
• Orientadas à apresentação: São web applications que geram páginas web in-teractivas constitúıdas por vários tipos de linguagens de anotação (por exem-
plo: HTML, eXtensible Markup Language (XML)) e que apresentam conteúdo
dinâmico como resposta a pedidos efectuados pelo utilizador.
• Orientadas aos serviços: Uma web application orientada aos serviços imple-menta o ponto de acesso para um ou mais de um web service. São geralmente
clientes de service oriented web applications.
Uma vantagem significativa de implementar uma web application de forma a
suportar as funcionalidades padrão dos browsers é que estas terão o mesmo com-
portamento independentemente da plataforma e do browser a partir do qual serão
acedidas. No entanto, diferentes implementações de browsers, devido a diferentes
interpretações dos padrões definidos, tornam por vezes esta tarefa um pouco mais
complicada, existindo inclusivamente na web guiõ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 tendência de utilização e de design observada
na World Wide Web (WWW) com o objectivo de melhorar a criatividade, partilha
de informação e principalmente: a colaboração entre utilizadores. Estes conceitos
levaram ao desenvolvimento e evolução de comunidades online tais como redes so-
ciais, wikis e blogues.
11
Enquadramento do Projecto
O termo tornou-se mais conhecido após a primeira conferência O’Reilly Media
Web 2.0 em 2004, e apesar de sugerir uma nova versão da WWW não se refere a
qualquer evolução tecnológica, mas apenas a alterações à forma como os utilizadores
se servem da web. De acordo com Tim O’Reilly [O’R06]: “Web 2.0 é uma revolução
na indústria do software, causada pela adopçã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 aplicações de desktop. Este
conceito foi melhor descrito por [Gar05] como um conjunto de várias tecnologias
que podem ser utilizadas para melhorar a experiência do utilizador de uma dada
web application, introduzindo a capacidade asśıncrona de envio de pedidos ou da
recepção asśıncrona de respostas. As tecnologias mais frequentemente envolvidas
são:
• eXtensible HyperText Markup Language (XHTML) e Cascading Style Sheets(CSS) padrão para a apresentação;
• interacção dinâmica através do DOM;
• troca e manipulação de dados utilizando XML e eXtensible Stylesheet Lan-guage Transformation (XSLT) ou JavaScript Object Notation (JSON);
• pedidos asśıncronos utilizando XMLHttpRequest [vK08];
• JavaScript, utilizado para integrar todas estas tecnologias.
É importante frisar que o Ajax não é um produto nem uma tecnologia. É um
termo que descreve a utilização de um conjunto de tecnologias para o desenvolvi-
mento de web applications com um elevado grau de interactividade. Comparativa-
mente às web applications tradicionais, o Ajax introduz uma camada de visualização
diferente em três importantes pontos:
1. Do lado do cliente existe um motor que serve de intermediário entre a interface
da aplicação e o servidor.
2. A actividade do utilizador despoleta chamadas JavaScript em vez de um pedido
de página directamente ao servidor.
3. Informação codificada em XML, em vez de páginas HTML, é trocada entre o
servidor e o cliente.
12
Enquadramento do Projecto
Isto significa que as páginas que utilizam Ajax contêm um motor do lado do
cliente, composto por um conjunto de funções JavaScript, responsável pela comu-
nicação com o servidor e por actualizar a interface com o resultado dessa mesma
comunicação.
Na Figura 2.3 ilustra-se a natureza asśı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 comunicações com o servidor uma vez que a interface não fica “bloqueada” à es-
pera da resposta. Obtém-se assim aplicações com um comportamento mais fluido,
eliminando tempos de espera entre cada “clique” e melhorando a experiência do
utilizador.
2.3 Offline Web Applications
A informação gráfica (bem como folhas de estilo e scripts), tais como as ima-
gens que constituem o visual de uma web application, é já tratada de forma especial
pelos cada vez mais avançados sistemas de cache (armazenamento temporário) dos
browsers. Mas estes não são ainda capazes de guardar conteúdo criado pelo uti-
lizador, nem de apresentar informação independentemente do estado da ligação.
Numa altura onde se fala de serviços de Internet wireless municipalizados [Kha],
comunicações 3G e ligações de banda larga a alta velocidade, a ligação à rede global
continua a não estar permanentemente dispońıvel para os utilizadores. Na WWW
encontra-se uma importante parte da informação e das aplicações utilizadas para
criar e editar conteúdos. Por vezes, informação vital para a produtividade pode
desaparecer subitamente do mapa de acesso de um utilizador, quando este entra no
metro, num avião, ou mesmo quando se desloca para uma cidade ou páıs diferente
do habitual, onde não subscreve um plano de acesso que lhe garanta a ligação.
Permitir o acesso offline a estes recursos assume assim a sua importância, porque
permitirá estender o alcance da informação a locais onde nunca esteve antes, e per-
mitirá também melhorar o desempenho das web applications, colocando informação
mais perto dos utilizadores, reduzindo a transferência de dados apenas ao essencial.
2.4 Comparação
Nas evoluções descritas neste caṕıtulo 2 pode-se observar que existe um par-
alelismo entre a evolução das arquitecturas tradicionais cliente-servidor e a evolução
a que se assiste na web. O comportamento e arquitectura dos thin-clients assemelha-
se ao das páginas estáticas, no sentido em que o browser não toma parte em qualquer
13
Enquadramento do Projecto
processamento, e serve apenas como uma plataforma de interacção com o servidor;
tal como os clientes descritos na secção 2.1.1.
A sua próxima evolução, os fat-clients, trouxeram parte da capacidade de pro-
cessamento para o lado do cliente. Na web, foi também esta a inovação tecnológica
a que se assistiu, com a evolução das tecnologias que permitiram a criação de ver-
dadeiras aplicações, e com a introdução do Javascript no browser, dando ao cliente
a capacidade de processamento de dados. A necessidade da separação do código
em camadas lógicas advém da crescente complexidade das web applications. Esta
prática permite, entre outras coisas, melhorar o processo de desenvolvimento e a
capacidade de manutenção de uma aplicação.
Os fat-clients têm também a capacidade de armazenamento de dados, o que
permite a persistência de informações entre duas sessões e que algumas operações
sejam executadas sem a necessidade de comunicação com o servidor. Este facto pode
também ser uma realidade nas web applications com a adopção das tecnologias OWA.
Neste momento assiste-se a uma utilização cada vez maior da web como uma
plataforma de desenvolvimento. A capacidade de cooperação na edição de conteúdos,
e a mobilidade proporcionada por esta plataforma são os principais factores que
alimentam esta mudança, e pela primeira vez, as aplicações tradicionais têm com-
petiçã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 lanç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 execução offline significa
aproximar a web e o desktop reunindo “o melhor de dois mundos”.
As vantagens da mobilidade posśıvel através da web a cooperação na criação e
edição de conteúdos e a possibilidade de utilizar aplicações sempre actualizadas e
sem necessidade de instalação são algumas das principais vantagens que promovem
esta mudança, que devido às preocupações associadas à usabilidade e experiência do
utilizador, está 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
Enquadramento do Projecto
Figura 2.3: Comparação do modelo de web aplications śıncrono, páginas estáticas e in-teractivas abordados nas secções 2.2.1 e 2.2.2, com o modelo de web applications Ajax(asśıncrono) abordado na secção 2.2.3. Figura adaptada de http: // www. adaptivepath.com/
15
http://www.adaptivepath.com/http://www.adaptivepath.com/
Enquadramento do Projecto
16
Caṕıtulo 3
Estado da arte
Apesar de o conceito das OWAs não ser absolutamente novo, as tecnologias que
o suportam são recentes. Neste caṕı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 é uma extensão às funcionalidades do browser introduzido pelo Google
que tem como principal objectivo tornar posśıvel a visualização de páginas de Inter-
net mesmo sem uma conexão dispońıvel. Encontra-se dispońı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 é constitúıda por três componentes principais:
• LocalServer — Intercepta pedidos de páginas web, e serve-as localmente;
• Database — Uma base de dados relacional constrúıda sobre SQLite;
• WorkerPool — Permite executar operações de computação de uma formaasśıncrona, sem afectar a capacidade de resposta e fluidez de execução da web
application. Assemelham-se a processos.
1Google Inc. – Mais informação em http://gears.google.com/
17
http://gears.google.com/
Estado da arte
LocalServer
O módulo LocalServer é uma cache de Uniform Resource Locators (URLs)
controlada pela web application. Quando não existe uma ligação à Internet e é
feito um pedido para um URL presente nesta cache, o LocalServer intercepta-o e
responde ao pedido localmente, a partir do disco ŕıgido do utilizador. A aplicaçã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 aplicação poderá criar e
utilizar diversos ResourceStores simultaneamente para capturar ficheiros de
dados que necessitam de ser endereçados por um URL, tal como um ficheiro
PDF ou uma imagem.
• ManagedResourceStore – serve para capturar um conjunto de URLs que estãorelacionados, e que são declarado num ficheiro de manifesto (especificado em
JSON) e que são automaticamente actualizados. O ManagedResourceStore
permite que o conjunto de recursos necessários para correr uma web application
seja capturado e mantido actualizado automaticamente.
A principal diferença entre estes dois tipos de armazenamento de URLs é a forma
como são actualizados os seus conteúdos. Os conteúdos de um ManagedResourceStore
são actualizados sempre que a versão contida no ficheiro de manifesto for alterada,
enquanto que os conteúdos de um ResourceStore nunca são actualizados automati-
camente, mas apenas quando for explicitamente ordenado pela aplicação.
O LocalServer é capaz de interceptar e servir localmente pedidos de HTTP e
HTTPS sempre que se reúnam as seguintes condiçõ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
deverá conter um cookie que lhe corresponda.
O LocalServer não necessita de monitorizar o estado da ligação para atender aos
pedidos. Na verdade, sempre que as condições previamente enunciadas se verificarem
o LocalServer interceptará os pedidos e, independentemente do estado da ligação
à Internet, servi-los-á a partir do disco ŕıgido local. Caberá à aplicaçã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 módulo Database permite guardar dados da web application assegurando a
sua persistência. Os dados são guardados de forma relacional no disco ŕıgido do uti-
lizador2 de acordo com o modelo de segurança estabelecido pelo Gears3, significando
que uma aplicação não pode aceder a conteúdos fora do seu domı́nio.
WorkerPool
Nos web browsers uma operação pesada de computação pode tornar a interface
lenta e tornar menos agradável a experiência do utilizador. O módulo WorkerPool
permite correr operações em background sem bloquear a interface com o utilizador.
Os scripts executados numa WorkerPool não activam os mecanismos de seguranç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 não partilham qualquer estado de execução, o que significa que uma
alteração a uma variável num Worker não afecta em nada a execução de outro
Worker. Além disso, os Workers não herdam automaticamente nenhum código dos
seus pais. Cada Worker é membro de um WorkerPool, e os Workers podem in-
teragir entre si enviando mensagens em formato de texto ou JSON. No entanto há
também algumas limitações: os Workers não tem acesso ao DOM, e objectos como
window ou document não se encontram acesśıveis. Isto é consequência de os Workers
não partilharem o estado de execução. Mas têm acesso a todas as funções built-in
do Javascript. A maioria das funcionalidades do Gears pode também ser acedida
através de uma variável global especial definida como google.gears.factory. Para
outras funcionalidades espećıficas os Workers podem “pedir” à página principal para
continuar a execução através do envio de mensagens.
Outras funcionalidades
• HttpRequest – Este módulo implementa a especificação W3C XmlHttpRe-quest, definida em [vK08], tornando-a dispońıvel para os workers e para a
página principal.
• Timer – Este módulo implementa a especificação de timers tal como descritopor [Hic08], e torna-os dispońıveis para os workers e para a pá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 é utilizada para instanciar todos os outros objectos daAPI do Gears através do seu método create. Este método pode ser utilizado
com os seguintes parâmetros:
– beta.database
– beta.httprequest
– beta.localserver
– beta.timer
– beta.workerpool
3.1.2 Goggle Gears em dispositivos móveis
O Gears está também dispońıvel em dispositivos Windows Mobile 5 e 6.
Os dispositivos móveis estão, pela sua natureza, frequentemente desconectados
da Internet. Mesmo quando possuem uma ligação as latências na transferência de
dados em redes móveis tornam as aplicações pouco flúıdas, mas o Gears permite
ultrapassar este obstáculo.
O Gears funciona exactamente da mesma forma em dispositivos móveis equipados
com o Windows Mobile 5 e 6 como num computador comum. Se uma aplicação tiver
sido implementado com suporte para o Gears, então também estará preparada para
ser executada num dispositivo móvel, mas as limitações dos browsers dispońıveis
para dispositivos móveis têm que ser consideradas. Isto significa prever as condições
que permitam uma boa usabilidade devido aos pequenos ecrãs destes dispositivos,
bem como o seu suporte limitado dos padrões do DOM, CSS e JavaScript.
3.2 Adobe AIR
O Adobe AIR4 é um runtime compat́ıvel com diversos browsers e sistemas opera-
tivos, que pretende dar aos programadores a possibilidade de combinar diversas tec-
nologias de produção de conteúdos para a Internet no desenvolvimento de Rich Inter-
net Application (RIA)s. O Adobe AIR mantém uma relação com o browser, mas es-
tende as suas capacidades e tecnologias, permitindo o desenvolvimento de aplicações
também para o ambiente de trabalho, com janelas em tudo semelhantes às do sis-
tema operativo. Segundo a Adobe, o objectivo é complementar o browser dando
aos utilizadores (mas essencialmente aos programadores e equipas de desenvolvi-
mento) a escolha sobre como distribuir as suas aplicações. Para este efeito o Adobe
AIR tem uma aproximação diferente do Gears. Em vez de “estender” o browser
acrescentando-lhe funcionalidades, o AIR permite também o desenvolvimento de
4Adobe - http://www.adobe.com/products/air/
20
http://www.adobe.com/products/air/
Estado da arte
aplicaçõ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 utilização desta tecnologia permite utilizar o browser ou o próprio runtime
Adobe AIR, como plataforma de execução da aplicação.
Na Tabela 3.1 faz-se uma comparação das funcionalidades dispońıveis de acordo
consoante se escolha o browser ou o desktop como plataforma base para a aplicação.
Uma vez que as aplicações Adobe AIR na plataforma desktop têm um carácter
persistente (são instaladas no computador do utilizador), o Adobe AIR tem um
modelo de segurança que se assemelha com o das tradicionais aplicações desktop
[Ada08]. Este modelo é analisado nas secções 3.2.1 e 3.2.2. O ambiente em que
é executado o browser é restringido à execução de web applications que podem
ser de várias origens (incluindo de origens anónimas ou sem confiança). O Adobe
AIR proporciona acesso a capacidades como acesso a ficheiros, que necessitam da
confiança do utilizador.
• HTML – O desenvolvimento de aplicações para o Adobe AIR pode ser feitocom recurso a tecnologias de HTML e Ajax comuns, utilizando as linguagens
de markup existentes, distribúıdas como texto e interpretadas em execução
(runtime);
• Flash – Outra alternativa será a utilização da linguagem Flash. Permite arenderização de gráficos vectoriais e áudio/v́ıdeo com suporte nativo. Utiliza
ActionScript para adicionar maior interactividade com o utilizador;
• Flex – O Flex é uma framework open source para o desenvolvimento de RIAsusando Flash. As aplicações Flex são na realidade Flash, sendo a principal
diferença o ambiente de desenvolvimento.
Como resultado, uma aplicação AIR poderá ser implementada:
• Baseada em Flash ou Flex (aplicações cujo conteúdo base é em ShockWaveFlash (SWF));
• Baseada em Flash ou Flex, também com HTML ou Portable Document Format(PDF). Aplicações cujo conteúdo de base é em Flash/Flex (SWF) com HTML
(HTML, JavaScript, CSS) ou conteúdo PDF inclúıdo;
• Baseada em HTML. Aplicações cujo conteúdo base é em HTML, Javascript,CSS;
• Baseada em HTML utilizando também Flash/Flex ou PDF.
21
Estado da arte
Os utilizadores interagem com uma aplicação AIR da mesma forma que interagem
com outras aplicações com janelas nativas do seu sistema operativo. O runtime é
instalado uma vez no computador do utilizador, e a partir desse momento, todas as
aplicações AIR terão o mesmo aspecto que qualquer outra aplicação para o desktop.
3.2.1 Segurança
Permitir que uma web application aceda ao disco de armazenamento do utilizador
pode comprometer seriamente a sua seguranç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 serão
apresentados ao utilizador no momento da instalação. Um outro aspecto ainda
relativo à segurança é o mecanismo de isolamento de cada ambiente (sandbox ).
3.2.2 Assinatura do código
O runtime AIR exige que todas as aplicações estejam digitalmente assinadas. As
assinaturas digitais de código são um processo que visa garantir a integridade da
aplicação e a identidade do seu autor, no momento da instalação. As equipas de
desenvolvimento podem “assinar” uma aplicação utilizando um certificado atribúıdo
por uma Entidade Certificadora (Certification Authority) ou atravé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 aplicação quando o código tiver
sido assinado com um certificado que apresente confiança, ou que esteja encadeado
com um certificado que tenha já sido aceite no computador em que se está a instalar
a aplicação.
As equipas de desenvolvimento podem também assinar as aplicações com um
certificado auto-atribúıdo (um certificado criado por elas próprias), mas neste caso
o instalador apresentará estas aplicações como sendo de uma origem não verificada.
O AIR utiliza a infraestrutura pública de chaves [Ent07] suportada pelo arquivo
local do sistema operativo. Para que a origem da aplicação seja reconhecida, o
computador onde a aplicação AIR está a ser instalada tem que confiar directamente
no certificado que foi utilizado para assinar a aplicação, ou confiar num certificado
que esteja num encadeamento lógico de certificados confiados, e que se ligue desta
forma ao certificado utilizado para assinar a aplicação.
Todas as aplicações AIR têm caracteŕısticas em comum, independentemente da
tecnologia utilizada para o seu desenvolvimento (HTML/Flex/Flash). No âmbito
de uma aplicação AIR existem um conjunto de APIs que estão dispońıveis e que
tornam posśıvel o acesso ao sistema local (leitura e escrita) e a recursos de rede que
22
Estado da arte
de outra forma nunca estariam acesśıveis a partir de uma web application comum.
Cada aplicação AIR possui também diferentes ńıveis de isolamento, chamados secu-
rity sandboxes, dependendo do tipo de conteúdo que está a ser carregado e do seu
objectivo:
• Isolamento ao ńıvel da aplicação5 – É a raiz de cada aplicação AIR. Esteńıvel de isolamento permite o acesso a APIs privilegiadas e espećıficas do
AIR. Em contrapartida, é negado o acesso a algumas APIs que poderiam ser
facilmente utilizadas de forma maliciosa contra o utilizador final. Importação
dinâmica de conteúdos remotos é geralmente proibido e as técnicas e mecan-
ismos de geração dinâmica de código são fortemente restringidas. Apenas
conteúdo carregado directamente da directoria base da aplicação poderá ser
colocado neste ńıvel de isolamento.
• Isolamento não espećıfico da aplicação6 – contém todo o outro conteúdoque não tenha sido carregado directamente para o isolamento da aplicação.
Isto inclui conteúdo local e remoto. Este tipo de conteúdo não tem acesso
directo às APIs do AIR e rege-se pelas mesmas regras tal como se tivesse sido
carregado por um browser a partir da mesma localizaçã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), é uma linguagem de anotação
baseada em XML desenvolvida pela Mozilla Foundation que opera em aplicações
Mozilla multi plataforma, tal como o Firefox. O motor Gecko é a única imple-
mentação completa desta linguagem, que foi desenhada sobre padrões web comuns,
como CSS, JavaScript e o DOM, e permite o desenvolvimento de interfaces gráficas
utilizando elementos pré-definidos tais como window, box, page, textbox, radio
button, entre outros . Infelizmente o XUL não possui qualquer especificação formal
ou implementações de inter-operabilidade para outros motores que não o Gecko. No
entanto a sua implementação é licenciada em código aberto, pelas licenças GNU Gen-
eral Public License (GPL), GNU Lesser General Public License (LGPL) e Mozilla
Public License (MPL).
Enunciam-se algumas caracteŕısticas desta linguagem:
5NT.: application sandbox6NT.: non-application sandbox
23
Estado da arte
Liguagem de anotação poderosa baseada em componentes (widgets): O ob-
jectivo do XUL é permitir a construção de aplicações multi-plataforma, em
claro contraste com o Dynamic HyperText Transfer Protocol (DHTML) que se
destina ao desenvolvimento de páginas web. Por esta razão o XUL está orien-
tado a componentes tais como janelas, botões, e etiquetas, em vez de páginas,
cabeçalhos de texto, e ligações de hipertexto. Investir tempo e esforço para
atingir este mesmo resultado em aplicações baseadas em DHTML, compromete
frequentemente a complexidade e desempenho da aplicação.
Baseado em padrões O XUL é um dialecto XML baseado no padrão W3C XML
1.0. As aplicações escritas em XUL são também baseadas em especificações
W3C adicionais, como HTML 4.0, CSS, DOM ńı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 é utilizado, tornando as aplicações
facilmente portáveis entre sistemas operativos nos quais o Mozilla é suportado.
Uma vez que o XUL oferece um ńıvel de abstracção dos componentes gráficos
de interface que disponibiliza, implementa a premissa “um código para todas
as plataformas”. A interface gráfica de todos os produtos centrais Mozilla
(browser, instant messenger, livro de endereços), é escrita em XUL, com um
único código base que suporta todas as plataformas Mozilla.
Separação entre o ńıvel de apresentação e a lógica de negócio: Uma das
maiores preocupações no desenvolvimento para a Internet é a forte ligação
entre estas duas camadas (interface e lógica). Isto constitui um problema sig-
nificativo no desenvolvimento de grandes aplicações, especialmente quando o
desenvolvimento é feito em ambientes de equipa, porque as capacidades de de-
senvolvimento destas duas partes da aplicação estão muitas vezes espalhadas
por diferentes elementos. O XUL permite uma clara distinção entre a definição
da aplicação cliente e da lógica de implementação (XUL, eXtensible Binding
Language (XBL) e JavaScript), apresentação (CSS e imagens), internacional-
ização (Document Type Definitions (DTDs) e etiquetas de texto em ĺınguas
espećıficas guardados em ficheiros .properties). O esquema gráfico e apre-
sentação de uma aplicação XUL pode ser alterado de forma independente da
sua lógica ou implementação, e a aplicação pode ainda ser traduzida (interna-
tionalization) de forma independente da sua lógica, implementação ou apre-
sentação. Este grau de separação resulta em aplicações que são mais fáceis de
manter pelos programadores e facilmente adaptadas por designers e tradutores.
24
Estado da arte
Fácil adaptação Outro benef́ıcio que advém do ńıvel de separação entre lógica
de negócio e apresentação oferecido pelo XUL é a facilidade com que se pode
adaptar uma aplicação para diferentes clientes ou grupos de utilizadores. Um
programador pode utilizar a mesma aplicação base e adaptá-la consoante as
necessidades, através de diferentes temas (skins) e ficheiros de ĺınguas. Desta
forma, uma aplicação escrita e desenvolvida em Inglês pode ser rapidamente
traduzida para Português e distribúıda com outra aparência mais apropriada
ao cliente alvo.
3.3.2 Prism
O Mozilla Prism é um browser simplificado e “interpretador” de XUL (também
designado por XULRunner) que acolhe web applications sem a interface gráfica ha-
bitual de um browser. Baseia-se num conceito designado por Site Specific Browser
(SSB). Um SSB é uma aplicação com um browser embebido, desenhado para exe-
cutar apenas uma web application. Não possui os menus e barras de ferramentas
habituais. Um SSB tem uma integração com o sistema operativo e com o desktop
muito mais estreita do que uma web application acedida através de um browser, uma
vez que é executado em janela própria.
O Prism resulta de uma experiência da Mozilla e visa reduzir as diferenças entre
as desktop applications tradicionais e as web applications. Um dos aspectos focados é
a experiência do utilizador. Numa apresentação oficial é dito que “[o Prism] pretende
ser uma ponte entre as diferenças que existem entre as aplicaçõ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 especificação HTML 5 [Hic08], que se encontra em fase de desenvolvimento
pelo grupo WHATWG, pretende ser uma norma de substituição dos padrões HTML
4, XHTML 1.x e do DOM2 HTML. Uma das propriedades que o distingue das tec-
nologias que pretende substituir é precisamente o suporte para OWA e armazena-
mento de dados no cliente de uma forma relacional. Não sendo propriamente uma
tecnologia –mas antes uma especificação –é aqui mencionada por ter servido como
referência a diversas implementações de funcionalidades offline, e por se considerar
que venha a ter um impacto significativo nas implementações de diversos browsers.
Dion Almaer defendeu no seu blogue que o Gears era uma implementaçã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 à web caracteŕısticas
25
Estado da arte
semelhantes e não encontrar motivo de “competição” entre as duas, mas que en-
quanto o HTML 5 é uma especificação o Gears é uma implementação.
No entanto, também é verdade que o HTML 5 cobre muitos outros pontos para
além das OWA que saem completamente fora do âmbito do Gears. Se esta es-
pecificação atingir um estado de maturidade que possibilite a sua adopção pelos
principais browsers, tornando nativo do browser o suporte OWA, então deixará de
fazer sentido a existência de uma extensão como o Gears.
A especificaçã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 aplicações mesmo quando
o utilizador não possui uma ligação à Internet.
Estas caracteŕısticas são as bases da tecnologia das OWA e têm correspondência
com os pontos analisados nas secções 3.1.1 e 3.1.1
3.5 Web applications que usam funcionalidades offline
Nesta secção apresentam-se algumas web applications que actualmente disponi-
bilizam funcionalidades offline. Estas aplicações foram escolhidas para uma análise
mais pormenorizada por utilizarem o Gears, que tal como descrito na secção 4, foi
a tecnologia escolhida para o projecto.
3.5.1 Google Reader e Google Docs
O Google Reader7 é um leitor de feeds RSS. Permite gerir a subscrição de vários
sites simultaneamente que disponibilizem conteúdos neste formato e foi a primeira
web application da Google com uma versão offline publicamente acesśıvel (desde
Junho de 2007).
O Google Reader implementa o modo “utilizador decide”, oferecendo na sua
interface um botão que permite alternar entre os modos online e offline.
O Google Docs8 é uma web application que permite a criação e edição de doc-
umentos de texto, folhas de cálculo e apresentações. Era já público desde Janeiro
de 2008 que o Google estava a desenvolver uma versão OWA desta aplicação, mas o
acesso a uma versão experimental só foi posśı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 implementação das funcionalidades offline nestas duas aplicações seguiu difer-
entes aproximações, principalmente porque o Google Reader apresenta ao utilizador
informações que são fornecidas por fontes externas, enquanto que no Google Docs,
a informação é criada e editada pelo utilizador sobre a forma de documentos.
A diferente origem da informação implica que no Google Reader seja necessário
prever casos de excepção, tal como existirem demasiados itens que necessitam de
ser transferidos para o cliente. Nã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 às acções do utilizador o Google Reader apenas
transfere para o cliente os dois mil itens mais recentes na transição para o modo
offline.
3.5.2 Remember the Milk
O Remember The Milk9 é uma web application desenvolvida por uma equipa
Australiana que proporciona funcionalidades de agenda, gestão de tempo e de tare-
fas e foi uma das primeiras aplicações independentes do Google a adoptar o Gears
para acessos em modo offline. Permite que os seus utilizadores façam uma gestão
de tarefas agrupando-as em listas, adicionando-lhes campos de informação adicional
ou dando-lhes informação geográfica (recorrendo ao serviç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, publicação
Really Simple Syndication (RSS) e partilha de categorias de tarefas de acordo com
diferentes ńıveis de permissõ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 versão do seu cliente de e-mail que utiliza o Gears
para acelerar o seu desempenho. Numa fase inicial estará dispońıvel apenas para
utilizadores que tenham cinco mil ou mais mensagens na sua caixa de correio, e
permitirá efectuar pesquisas muito mais rápido que a sua versão online.
O serviço de blogs Wordpress.com anunciou também o ińıcio da utilização desta
tecnologia com o fim de melhorar o desempenho. A versão que utiliza esta tecnologia
descarrega e armazena no cliente um conjunto de imagens e scripts que passam a
ter preferência sobre os seus congéneres online, e que permitem acelerar o processo
de carregamento da aplicação e visualizaçã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 são dois exemplos da utilização da tecnologia
OWA para optimização de web application já existentes. Sem pretenderem disponi-
bilizar uma versão que seja totalmente offline fazem uso do Gears para armazenar no
cliente parte dos recursos frequentemente acedidos na visualização das suas páginas.
3.6 Escolha da tecnologia
Após a análise das tecnologias apresentada nas secções 3.1 a 3.4, foi necessário es-
tudar a adequação de cada uma delas ao projecto em questão. Desde logo é posśı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 execução do projecto quando utilizado
na sua vertente desktop, tal como exposto na Tabela 3.1, mas a utilização desta
vertente implicaria o desenvolvimento de novas interfaces e de novas formas de co-
municação (troca de mensagens XML ou JSON). A vertente web do Adobe AIR
foca-se mais especificamente nas Rich Internet Applications e permite a reutilização
do código já existente (exigindo naturalmente a sua adaptação e a implementação
das funcionalidades pretendidas).
A tecnologia escolhida para a realização deste trabalho foi o Gears, sendo que
um dos principais factores a influenciar esta opção foi a liberdade introduzida pela
sua licença Berkeley Software Distribution (BSD)11.
Considerou-se o funcionamento desta ferramenta extremamente adequando à
aplicação no WOW!, uma vez que o seu principal objectivo é precisamente tornar
posśıvel a execução offline de uma página web e por virtude deste facto o Gears tem
uma API concisa e de simples aplicação prática, uma vez que não possui quaisquer
outros elementos distractores. O funcionamento do seu ManagedResourceStore ex-
emplificado na Figura 3.1, com a capacidade de actualização de recursos definidos
num ficheiro manifesto especificado em JSON pesou também nesta decisão.
11Sobre a licenç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 actualização dos conteúdos definidos no ficheiro manifesto.
29
Estado da arte
Funcionalidade RIAs no browser RIAs no desktopDisponibilidadeda aplicação
As aplicações podem ser facil-mente exploradas e utilizadas
As aplicações quando instal-adas têm maior grau de fun-cionalidades e persistência
Instalação Não é necessário qualquer tipode instalação.
As aplicações são instaladasatravés do browser, ou descar-regadas e instaladas comouma aplicação tradicional.
Actualizações Aplicações são actualizadascarregando conteúdos paraum website.
O AIR disponibiliza uma APIque permite que as aplicaçõessejam actualizadas de umaforma
Sistemas opera-tivos suportados
As aplicações podem ser exe-cutadas em diversos sistemasoperativos e browsers.
As aplicações são multi-plataforma e podem serinstaladas e executadas emdiversos sistemas operativos ebrowsers.
Linguagens deprogramação
Javascript é disponibilizadopelo browser e ActionScripté disponibilizado pelo AdobeFlash Player.
Máquinas virtuais deJavascript e ActionScriptcompat́ıveis com o browser.
Capacidade deexecução embackground
As RIAs podem ser execu-tadas numa janela do browser.
As aplicações podem ser ex-ecutadas em background edisponibilizar notificações talcomo uma aplicação tradi-cional.
Persistência A actividade está limitada àsessão do browser. Quando obrowser é encerrado, toda ainformação é descartada.
As aplicações são instaladas eestão dispońıveis no desktop.Podem armazenar informaçãolocalmente e estão dispońıveisoffline.
Integração com odesktop
Integração com o desktop lim-itada devido a restrições im-postas pelo browser.
As aplicações podem acederao sistema de ficheiro, ao clip-board, eventos, notificações,etc.
Controlo da inter-face com o uti-lizador
As aplicações são acedidasatravés de uma janela dobrowser, que tem os seuspróprios controlos e visualgráfico.
As aplicações têm um vi-sual gráfico próprio, em janelaprópria.
Armazenamentode dados
As aplicações têm armazena-mento limitado, que pode serreescrito pelo browser.
As aplicações têm acesso à to-talidade do espaço dispońıvellocalmente, e a uma base dedados com a possibilidade deencriptação.
Tabela 3.1: Comparação das funcionalidades oferecidas pelo Adobe AIR para as platafor-mas web e desktop
30
Estado da arte
Aplicação Modo de execução utilizadoGoogle Reader Utiliza o modo “utilizador decide”, disponibilizando
ao utilizador um botão para alternar entre os modosonline e offline. Como lida com informação recol-hida de fontes externas, de natureza frequentementeefémera, o processo de sincronização apenas transfereos dois mil itens mais recentes quando passa ao es-tado offline. Neste modo são ainda guardadas in-formações de itens lidos e etiquetas atribúıdas quesão sincronizadas com o servidor quando o utilizadorvoltar a activar estado online.
Google Docs Utiliza o modo “aplicação decide”, permitindo que outilizador edite os conteúdos de documentos de texto,folhas de cálculo e de apresentações independente-mente do estado da ligação, desde o momento em queas funcionalidades offline são activadas. A aplicaçãofaz pequenas sincronizações com o servidor sempre quenecessário.
Remember the Milk Utiliza um modo h́ıbrido entre “aplicação deci