Offline web applications : Enablng offline execution on the WOW! product

(1)

Faculdade de Engenharia da Universidade do Porto

Offline Web Applications

Enabling offline execution on the WOW! product

Jo˜

ao Gon¸

calves da Costa

Relat´orio de Projecto realizado no ˆAmbito do

Mestrado Integrado em Engenharia Inform´atica e Computa¸c˜ao

Orientador: Teresa Galv˜ao Dias (PhD.)

(2)

c

(3)

Offline Web Applications

Jo˜

ao Gon¸

calves da Costa

Relat´

orio de Projecto realizado no ˆ

Ambito do

Mestrado Integrado em Engenharia Inform´

atica e Computa¸c˜

ao

Aprovado em provas p´

ublicas pelo j´

uri:

Presidente: Pedro Ferreira do Souto (PhD)

Arguente: Artur Pereira (PhD) Vogal: Teresa Galv˜ao Dias (PhD)

(4)

(5)

Resumo

Este projecto teve como objectivo o estudo dasOffline Web Applications (OWAs)

e da sua implementa¸cão em web applications já existentes. Neste âmbito, foi feita uma avalia¸cão da aplica¸cão desta tecnologia no WOW!, uma plataforma integrada de gestão de ordens de trabalho, desenvolvida pela Critical Software S.A. ao longo dos últimos 6 anos, e implementada uma prova de conceito que permite a utiliza¸cão de um conjunto de funcionalidades base desta web application, independentemente do estado da liga¸cão à Internet.

O conceito das OWAs enquadra-se numa tecnologia de Internet que permite o acesso a um website através do browser mesmo na ausência de uma liga¸cão à rede global, e foi considerado pela revista Technology Review como uma das mais importantes tecnologias emergentes no final de 2007 [Nao08]. O estudo efectuado no

WOW!pretende ser um primeiro passo na compreensão dos problemas associados à sua implementa¸cão e respectivas solu¸cões e também da avalia¸cão dos benef´ıcios da utiliza¸cão desta tecnologia para os utilizadores finais.

A evolu¸cão das tecnologias associadas à Internet, a que se assiste continua-mente, impulsionou também evolu¸cão da forma como a informa¸cão é produzida, distribu´ıda e armazenada. Surgiram novas web applications oferecendo funcionali-dades de cria¸cão e edi¸cão de conteúdos, que trouxeram consigo a vantagem de tornar poss´ıvel o acesso à informa¸cão a partir de qualquer lugar, mas também a desvan-tagem de tornar a liga¸cão à Internet uma condi¸cão necessária para que isto aconte¸ca. A prolifera¸cão destas aplica¸cões, a crescente utiliza¸cão da Internet [Gro08] e a adesão aos seus servi¸cos indiciam a existência de uma dependência cada vez maior de uma liga¸cão, que nem sempre existe.

As OWAs vêm assim colmatar esta falha, colocando no lado do cliente parte da informa¸cão que até agora vinha a ser armazenada no servidor e tornando não só poss´ıvel a sua consulta offline, como também reduzindo a carga no servidor, uma vez que reduz as transferências de informa¸cão.

Pretende-se neste documento apresentar diferentes formas de como a utiliza¸c˜ao da tecnologia OWA pode beneficiar as web applications de hoje, melhorando o seu desempenho e dando-lhes novas possibilidades de execu¸c˜ao, aproximando-as do desk-top.

(6)

(7)

Abstract

The main purpose of this project was to study the Offline Web Applications (OWAs)and its implementation in existentweb applications. With this goal in mind, a study was conducted to use this technology inWOW!, an integrated platform for work orders and work flow management, developed by Critical Software over the last 6 years, and implemented a proof of concept, which enables the use of a base set of functionality for this application, regardless of the internet connection state.

The concept of OWAs is connected with internet technology, and allows access to 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 important emerging technologies in the last quarter of 2007 [Nao08]. This study, conducted over the WOW! platform, is intended to aid in the comprehension of the problems and solutions associated to the use and implementation of OWA, as well as the benefits 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 applicationsappeared, with new content creation and edition functionalities, and with it, the advantage of infor-mation retrieval from any place and time became possible, but with the condition of 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 shows a dependency of a connection that is not always present.

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

This document intends to present different ways in which this technology can help web applications as we know them, improving the their overall performance and giving them the ability to run on a browser, regardless of the Internet connection availability

(8)

(9)

Agradecimentos

A realiza¸cão e os objectivos alcan¸cados neste projecto não teriam sido poss´ıveis sem a colabora¸cão de inúmeras pessoas. Agrade¸co profundamente a todos os que contribu´ıram directa ou indirectamente para o seu sucesso:

`

A minha orientadora, Professora Teresa Galv˜ao Dias, e ao Project Manager Engenheiro Marcus Neves, que me conduziram e acompanharam no desenvolvimento deste projecto,

A toda a equipa do WOW!, em especial o Pedro Maur´ıcio Costa e o Fábio Matos, que contribu´ıram para a minha a minha integra¸cão na Critical Software e que sempre souberam responder a todas as minhas questões,

A todos os que constituem a CSW Porto, pelo fant´astico ambiente de amizade que me proporcionaram,

Aos colegas de curso e a todos os que me auxiliaram na revis˜ao deste documento,

Os meus sinceros agradecimentos! Jo˜ao Gon¸calves da Costa

(10)

(11)

Conte´

udo

1 Introdu¸cão 1 1.1 Enquadramento . . . 1 1.2 Motiva¸cão . . . 2 1.3 Ambito . . . .ˆ 3 1.4 Objectivos . . . 3 1.5 Estrutura do documento . . . 3 2 Enquadramento do Projecto 5 2.1 Evolu¸cão das arquitecturas de software . . . 5

2.1.1 Thin-clients . . . 5

2.1.2 Fat-clients . . . 6

2.1.3 Arquitecturas cliente-servidor . . . 7

2.2 Evolu¸c˜ao na Internet . . . 8

2.2.1 P´aginas web est´aticas . . . 9

2.2.2 Páginas web interactivas e páginas web dinâmicas . . . 9

2.2.3 Web 2.0 e Ajax . . . 11

2.3 Offline Web Applications . . . 13

2.4 Compara¸c˜ao . . . 13

3 Estado da arte 17 3.1 Gears . . . 17

3.1.1 Arquitectura . . . 17

3.1.2 Goggle Gears em dispositivos m´oveis . . . 20

3.2 Adobe AIR . . . 20

3.2.1 Seguran¸ca . . . 22

3.2.2 Assinatura do c´odigo . . . 22

3.3 Mozilla Prism . . . 23

3.3.1 XML User Interface Language . . . 23

3.3.2 Prism . . . 25

3.4 HTML 5 . . . 25

3.5 Web applications que usam funcionalidades offline . . . 26

3.5.1 Google Reader e Google Docs . . . 26

3.5.2 Remember the Milk . . . 27

3.5.3 MySpace e WordPress.com . . . 27

(12)

CONTE ´UDO

4 Desenvolvimento 33

4.1 Como ficar offline . . . 33

4.1.1 Funcionalidades dispon´ıveis em modo offline . . . 34

4.2 Modos de execu¸c˜ao . . . 35

4.2.1 Modo “utilizador decide” . . . 36

4.2.2 Modo aplica¸c˜ao decide . . . 36

4.2.3 Modo “aplica¸c˜ao assume o estado offline” . . . 37

4.3 Sincroniza¸c˜ao de dados . . . 38

4.3.1 Quando sincronizar? . . . 39

4.4 WOW! . . . 40

4.5 Vis˜ao geral sobre a arquitectura do WOW! . . . 41

4.6 WOW! Offline . . . 42

4.6.1 Modo “aplica¸cão decide” com deteçcão automática da liga¸cão 43 4.6.2 Implementa¸cão do modo “utilizador decide” . . . 45

4.6.3 Especifica¸c˜ao do modo “aplica¸c˜ao assume o estado offline” . . 48

5 Resultados e Futuros Desenvolvimentos 51 5.1 Resultados Obtidos . . . 51 5.2 Trabalho Futuro . . . 52 6 Conclusões 55 6.1 Conclusões . . . 55 Referências 59 A Screenshots 61

(13)

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¸cão das camadas desta arquitectura, devido à forte dependência cliente-servidor. . . 9

2.2 Arquitectura de um fat-client em duas camadas (à esquerda) e em três camadas (à direita). . . 10

2.3 Compara¸cão do modelo de web aplications s´ıncrono, páginas estáticas e interactivas abordados nas seçcões 2.2.1 e 2.2.2, com o modelo de web applications Ajax (ass´ıncrono) abordado na seçcão2.2.3. Figura adaptada de http: // www. adaptivepath. com/ . . . 15

3.1 Esquema UML do processo efectuado pelos recursos do Gears do tipo ManagedResourceStore para a actualiza¸c˜ao dos conte´udos definidos no ficheiro manifesto. . . 29

4.1 Exemplo de uma arquitectura de uma web application sem uma ca-mada de abstrac¸c˜ao 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¸c˜ao 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¸c˜ao de dados e um data switch. Figura adaptada de

http: // gears. google. com/ . . . 35

4.4 Esquema gráfico ilustrando uma OWA executando no browser uti-lizando um modo de execu¸cão do tipo “aplica¸cão decide”, com de-teçcão automática do estado da liga¸cão via pedidos Ajax ass´ıncronos a cada cinco segundos. . . 37

4.5 Detalhe de um conjunto poss´ıvel de estados e respectivas transi¸cões para uma dada ordem de trabalho no WOW!, desde a sua submissão no sistema até à sua conclusão em fecho ou cancelamento. Esta figura representa apenas um exemplo, já que o mapa de estados para uma ordem 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

(14)

LISTA DE FIGURAS

4.6 A página inicial do WOW apresenta um resumo das últimas ordens de trabalho enviadas e recebidas. Na imagem pode-se observar a transi¸cão do estado online para offline. . . 44

4.7 Ilustra¸cã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áquina remota, consoante se verificarem ou não as condi¸cões expressas no ponto 3.1.1. É representado um acesso a uma base de dados local (fornecida pelo Gears), mas a sua utiliza¸cão é opcional. . . 45

4.8 Neste exemplo do modo “aplica¸cão decide”, o teste da liga¸cão é feito ´

e feito a cada cinco segundos. O resultado deste teste não reflecte sempre o estado real da aplica¸cão, podendo levar a aplica¸cão a ter comportamentos indesejáveis. Na figura assinala-se um per´ıodo de tempo no qual a representa¸cão interna do estado da liga¸cão não cor-responde à realidade. . . 46

4.9 P´agina de visualiza¸c˜ao do detalhe de uma ordem de trabalho. . . 47

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

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

4.12 Esquema UML que expressa o acto de recolha de dados em modo online e offline, recorrendo ao servidor (modo online) e ao sistema de armazenamento de dados local fornecido pelo Gears (modo offline). 50

A.1 Di´alogo apresentado ao utilizador na primeira activa¸c˜ao das funcional-idades offline no Google Docs & Spreadsheets. . . 61

A.2 Na activa¸cão das funcionalidades offline é também oferecida a possi-bilidade da cria¸cão de alguns atalhos, por exemplo, no ambiente de trabalho. . . 62

A.3 O Google Docs mantém a todo o momento a possibilidade de altera¸cão destas defini¸cões, ou da anula¸cão dos servi¸cos offline para um dado computador. . . 62

A.4 Após a instala¸cão do Gears qualquer visita ao Remember The Milk despoleta uma sincroniza¸cão que ocorre automaticamente e sem ne-cessidade de interven¸cão por parte do utilizador. . . 63

A.5 Após completar a sincroniza¸cão de dados, mesmo que a liga¸cão à Internet seja perdida o Remember the Milk continua dispon´ıvel no browser (com excep¸cão das funcionalidades que pela sua natureza exigem uma liga¸cão, como por exemplo: partilha de tarefas e envio de convites.) . . . 63

(15)

Lista de Tabelas

2.1 Compara¸c˜ao entre thin-clients e fat-clients . . . 7

3.1 Compara¸c˜ao das funcionalidades oferecidas pelo Adobe AIR para as plataformas web e desktop . . . 30

3.2 Resumo da utiliza¸c˜ao de tecnologias OWA em algumas web applica-tions consideradas na an´alise do estado da arte. . . 31

(16)

(17)

Gloss´

ario

fat-client Cliente que n˜ao depende totalmente de um servidor central para as suas actividades de processamento e possui frequentemente dispositivos de armazenamento de dados.

6–8

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

5–8

web application Sistema web (servidor, rede HTTP, browser ) onde açcões do utilizador (navega¸cão e introdu¸cão de informa¸cão) afectam o estado lógico da aplica¸cã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 servidor que permite a cria¸cão de páginas web dinâ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 24

DOM Document Object Model 10, 12,

20, 23,

24

(18)

Gloss´ario

ECMAScript Padr˜ao de linguagem de programa¸c˜ao definido pela Ecma International que orig-inou o JavaScript e o JScript.

24

Flash Conteúdo interactivo de um ficheiro em formato SWF. É desenvolvido pela Adobe e visualizado através do Adobe Flash Player.

21

Flex Framework baseada em XML e Action-Script desenvolvida pela Adobe para a pro-grama¸c˜ao 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 de´ mensagens entre componentes de software.

42

JSON JavaScript Object Notation, permite a troca de dados, codificados num formato de texto de simples leitura

12, 18,

28, 34

LGPL GNU Lesser General Public License 23

Mozilla Prism Browser simplificado e “interpretador” de

eXtensible User Interface Language (XUL)

(tamb´em designado por XULRunner) que acolhe web applications sem a interface gr´afica habitual de um browser.

25

MPL Mozilla Public License 23

OCA Occasionally Connected Application 39

OWA Offline Web Application i, iii,

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

(19)

Gloss´ario

PHP Linguagem interpretada pelo servidor que permite a cria¸cão de páginas web dinâ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 mesma resposta a todos os pedidos, para todos os utilizadores e em qualquer contexto.

5, 9

RIA Rich Internet Applications web appli-cations que apresentam funcionalidades semelhantes ás desktop applications, mas que mantém a informa¸cão no lado do servi-dor

5, 15,

20,28

RSS Really Simple Syndication 27

SLA Service Level Agreement 40

SQLite Segundo a defini¸c˜ao oficial: SQLite is a software library that implements a self-contained, serverless, zero-configuration, transactional SQL database engine..

17

SSB Site Specific Browser 25

SSL Secure Sockets Layer 22

SWF ShockWave Flash 21

URL Uniform Resource Locator 18

VPN Virtual Private Network 38

WOW! Work Orders Web. Plataforma de gest˜ao de 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 24

XHTML eXtensible HyperText Markup Language 12

XML eXtensible Markup Language 11, 12,

23, 24,

28

XSLT eXtensible Stylesheet Language Transfor-mation

12

XUL eXtensible User Interface Language xiv,

(20)

(21)

Cap´ıtulo 1

Introdu¸

c˜

ao

Neste cap´ıtulo enquadra-se o tema do projecto, introduzindo alguns dos conceitos nos quais se baseia. Apresentam-se as motiva¸c˜oes, ˆambito, objectivos e a estrutura deste documento.

1.1 Enquadramento

A Internet foi originalmente concebida para ser um espa¸co de partilha de in-forma¸cão, onde pessoas (através de máquinas) pudessem comunicar. Na sua origem, as páginas eram estáticas, constitu´ıdas por texto formatado emHyperText 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´arias das seguintes categorias:

• Documento – um website essencialmente estático, onde altera¸cões a uma parte do conteúdo não tem implica¸cões no seu comportamento.

• Base de dados – um direct´orio de informa¸c˜ao organizada em categorias.

• Aplica¸cão – um website dinâmico, que utiliza uma linguagem executada ou interpretada do lado do servidor, e que processa as açcões ou informa¸cão in-troduzida pelo utilizador para fornecer um servi¸co ou nova informa¸cão.

A ´ultima destas categorias constitui aquilo que ´e normalmente designado por

web application. O conceito utilizado ao longo deste documento ´e o mesmo que o introduzido por Jim Coallen em [Con99], que define web application como um

(22)

Introdu¸c˜ao

sistema web (servidor, rede HyperText Transfer Protocol (HTTP), browser ) onde açcões do utilizador (navega¸cão e introdu¸cão de informa¸cão) afectam o estado lógico da aplica¸cão. A sua defini¸cão tenta estabelecer que uma web application é um sistema de software com estado de negócio1, e que a sua interface de interaçcão com o utilizador é distribu´ıdo através de um sistema web.

1.2 Motiva¸

c˜

ao

A quantidade de informa¸cão que é produzida e armazenada com recurso a es-tas web applications dispon´ıveis online, tais como e-mail, blogues ou mesmo docu-menta¸cão, tornam por vezes a disponibilidade de liga¸cão uma condi¸cão necessária `

a produtividade e, como consequência desta barreira, muitos potenciais utilizadores opõem-se à adop¸cão de produtos web em detrimento das tradicionais desktop appli-cations.

Assegurar o acesso a uma liga¸cã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¸cões nas quais os utilizadores estão privados de uma liga¸cão `

a Internet, tais como uma viagem de metro ou de avião, ou quando se encontram deslocados do seu pa´ıs de origem e não possuem nenhum plano de subscri¸cão.

Uma OWA consiste numa web application que para além de manter todas as caracter´ısticas anteriores, se mantém dispon´ıvel mesmo na ausência de uma liga¸cão `

a 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¸cão do estado lógico da aplica¸cão quando a liga¸cão com o servidor é quebrada, permitindo ao utilizador continuar a utilizar a aplica¸cão, e que será capaz de informar o servidor do estado em que a aplica¸cão se encontra quando a liga¸cão for reposta. A principal vantagem que advém desta possibilidade é evidente: eliminar a necessidade da existência de uma liga¸cão à Internet para que a aplica¸cão possa ser utilizada.

Por outro lado, a vontade de integra¸cã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¸cã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¸cão tornar poss´ıveis interaçcõ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

(23)

Introdu¸c˜ao

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¸cão, e das desktop applications, como por exemplo: persistência no armazenamento de dados, acesso a funcionalidades do sistema operativo ou integra¸cão e interaçcão com outras aplica¸cões, sejam elas web applications ou desktop applications.

1.3 Ambito

ˆ

Este projecto foi realizado na Critical Software S.A. no âmbito do Mestrado Integrado em Engenharia Informática e Computa¸cã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˜ao objectivos deste projecto:

1. Estudar e documentar o tema dasOWAsacompanhando os ´ultimos desenvolvi-mentos nesta mat´eria.

2. Analisar o estado da arte, fazendo uma an´alise cr´ıtica e objectiva sobre as diversas metodologias existentes.

3. Implementar uma prova de conceito, que permita a execu¸c˜ao offline de uma

web application, documentando todo o processo.

4. Estudar a possibilidade de permitir interaçcão com a aplica¸cão (inser¸cões e altera¸cõ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˜ao 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 seçcões, apresentando o projecto numa sequência lógica organizada da seguinte forma:

No cap´ıtulo 1 faz-se uma breve apresenta¸cão do conceitoOWAse do contexto em que surge. Apresenta-se também a estrutura do documento e definem-se os termos e acrónimos utilizados.

(24)

Introdu¸c˜ao

No cap´ıtulo 2 faz-se uma descri¸c˜ao da evolu¸c˜ao 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 matéria. Introduzem-se diversas tecnologias directamente relacionadas com o tema deste projecto, exemplos de aplica¸cões que as usam e as razões que fundamentam as escolhas de tecnologias efectuadas.

O cap´ı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¸cã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 continua¸cão/aplica¸cão do conhecimento adquirido.

(25)

Cap´ıtulo 2

Enquadramento do Projecto

Neste cap´ıtulo apresenta-se um breve resumo da evolu¸cão das arquitecturas de software cliente-servidor e a forma como estas se comparam à evolu¸cã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¸cã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 dasOWAse a estreita rela¸cão que têm com asRich Internet Application (RIA)s.

2.1 Evolu¸

c˜

ao 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 cap´ıtulo, excepto quando seja dada indica¸cã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 equ´ıvocos, em especial na sec¸c˜ao2.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

(26)

Enquadramento do Projecto

actividades de processamento e proporciona um canal de entrada e sa´ıda de in-forma¸c˜ao 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 aplica¸c˜oes cliente-servidor.

No in´ıcio da história da computa¸cão, terminais ligavam-se directamente a main-frames responsáveis por todo o processamento. Nesta arquitectura, era necessário desenvolver duas aplica¸cões distintas: uma aplica¸cão central no servidor (main-frame), responsável pela gestão de toda a informa¸cão e por todas as opera¸cões de comunica¸cão, e uma aplica¸cão de visualiza¸cão, instalada no cliente (terminal). O papel destes terminais era apenas disponibilizar ao utilizador um meio de comu-nica¸cão (entrada e sa´ıda) e apresenta¸cã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¸cão e manuten¸cão do lado do cliente. Uma vez que o centro do processamento e manipula¸cão de dados ocorre no servidor, existe também uma centraliza¸cão da informa¸cão [NJN00] que introduz um ponto cr´ıtico de falha1. Actualiza¸cões e novas funcionalidades são fáceis de distribuir, uma vez que requerem apenas altera¸cõ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-client s vieram responder à necessidade crescente de aplica¸cões com um n´ıvel de interactividade e capacidade de configura¸cão maior que as oferecidas pela arquitectura thin-client, descrita na seçcã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¸cão entre cada sessão.

Foi disponibilizando este controlo sobre o estado da aplica¸cã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¸cão e uma actualiza¸cão ao servidor implicava in-variavelmente uma actualiza¸cão manual também no cliente. Uma vez que nem todos

(27)

Thin-clients Fat-clients

N˜ao toma parte no processamento de dados nem possui acesso ao sistema de ficheiros.

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ógico da aplica¸cão entre duas sessões de uti-liza¸cão.

O acesso ao armazenamento local permite-lhe manter registo do estado lógico da aplica¸cão entre duas sessões. O thin-client não necessita de qualquer

instala¸c˜ao, estando “pronto a utilizar”. ´

E geralmente necess´ario instalar a aplica¸c˜ao para poder interagir com o servidor

Qualquer update no servidor reflecte-se imediatamente por todos os clientes.

Embora a aplica¸cão cliente possa aler-tar para existência de novas versões, as actualiza¸cões têm que ser manualmente instalados pelo cliente.

O software do cliente destina-se apenas `

a apresenta¸cão de dados e comunica¸cão com o servidor, sendo portanto, de sim-ples implementa¸cão.

Como o software do cliente toma parte activa no processamento de dados, a sua implementa¸c˜ao requer cuidados adicionais.

Grande mobilidade, uma vez que toda a informa¸c˜ao ´e mantida no servidor

Parte da informa¸cão poderá estar ape-nas do lado cliente, pelo que existem algumas restri¸cões à sua mobilidade. Tabela 2.1: Compara¸cão entre thin-clients e fat-clients

os utilizadores actualizam regularmente as suas aplica¸c˜oes, o servidor tem que estar preparado para lidar com vers˜oes antigas2_{, ou descontinuar os seus servi¸cos 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¸cões que não sejam sincronizadas com o servidor estão apenas dispon´ıveis nos seus computadores pessoais, o que introduz uma restri¸cão à mobili-dade.

Pode-se afirmar que as vantagens dos thin-clients s˜ao as desvantagens dos fat-clients, e que as vantagens dos fat-clients s˜ao 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¸cos e um servidor como um prestador de servi¸cos, tal como definido por [Sch96] e [Sad97].

(28)

As arquitecturas cliente-servidor são categorizadas pela modulariza¸cã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¸cão. Quando este módulo é implementado separadamente dos outros dois constitui uma aplica¸cão thin-client por si só, uma vez que não implementa regras de negócio (embora possa definir valida¸cões de formulários de inser¸cão de dados, por exemplo). A informa¸cã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¸cão e valida¸cão de todos os dados introduzidos pelo utilizador. É também a plataforma de comunica¸cão que une a camada superior de visualiza¸cã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, seleçcão e altera¸cão.

Osthin-client s, 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¸cã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¸cão, são designados por sistemas de três camadas. Ambos os casos são ilustrados na Figura 2.1.

Historicamente, os fat-client s eram implementados numa arquitectura em duas camadas. Possu´ıam apenas um módulo de visualiza¸cã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¸cão de liga¸cões mais rápidas e de computadores pessoais com maior capacidade de processamento e so-bretudo devido à complexidade crescente das aplica¸cõ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 Figura2.2.

2.2 Evolu¸

c˜

ao na Internet

Ao analisar a evolu¸cão das arquitecturas das aplica¸cões desenvolvidas para a Internet, podemos encontrar um paralelismo com a história da arquitectura de soft-ware.

(29)

Figura 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 (mainframe) na defini¸cão das camadas desta arquitectura, devido à forte dependência cliente-servidor.

2.2.1 P´aginas web est´aticas

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¸cão entre diversas páginas estáticas.

A informa¸cão é armazenada num servidor, e o papel do cliente é apenas a apre-senta¸cão da informa¸cão. Esta forma de disponibiliza¸cão de informa¸cão pode assim ser comparada com os thin-clients descritos na seçcão 2.1.1: o utilizador acede a um website estático para visualizar informa¸cão sem que o cliente tome parte no processamento. A única diferen¸ca é que no caso da web estática a informa¸cão ap-resentada é sempre a mesma, enquanto que nos thin-clients era frequente existir a possibilidade de inser¸cão de dados no cliente e após o seu processamento servidor, nova informa¸cão poderia ser apresentada. O hipertexto é utilizado para ligar as páginas entre si numa rede de conteúdos relacionados, e a navega¸cão s´ıncrona era feita através de cliques do rato: a cada clique uma nova página era apresentada. Este modelo s´ıncrono é ilustrado na Figura2.3.

2.2.2 Páginas web interactivas e páginas web dinâmicas

O JavaScript ´e uma linguagem interpretada de scripting que tem os browsers como principal ambiente de acolhimento. Os browsers utilizam uma Application

(30)

Figura 2.2: Arquitectura de um fat-client em duas camadas (à esquerda) e em três camadas (à direita).

Programming Interface (API)p´ublica para criar “objectos” respons´aveis por reflectir e disponibilizar o Document Object Model (DOM) para o motor de JavaScript.

A utiliza¸cão mais frequente desta linguagem é a escrita de fun¸cões que são em-bebidas ou inclu´ı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 açcões do utilizador, tornando a execu¸cão de aplica¸cões no browser mais flu´ıdas; o JavaScript pode também detectar açcões do utilizador que o HTMLnã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´em a suportar uma vers˜ao semelhante desta linguagem (hoje, todos os principais browsers suportam esta tecnologia).

Esta inova¸cão permitiu tornar os websites mais interactivos, mas a sua utiliza¸cão esteve confinada apenas a este propósito durante um longo per´ıodo. As páginas passaram a responder activamente a açcões do utilizador (sendo uma das utiliza¸cões

3

Netscape Communications –http://browser.netscape.com/

(31)

mais vulgares a valida¸cã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)eActive 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¸cão de dados ou outros pedidos determinados por açcões do utilizador. As páginas tornaram-se aplica¸cões, web ap-plications.

Uma defini¸cã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¸cão de dados (web forms). Uma web application não é mais do que uma aplica¸cã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´a dois tipos de web applications:

• Orientadas à apresenta¸cão: São web applications que geram páginas web in-teractivas constitu´ıdas por vários tipos de linguagens de anota¸cã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¸cos: Uma web application orientada aos servi¸cos imple-menta o ponto de acesso para um ou mais de um web service. S˜ao 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¸cões de browsers, devido a diferentes interpreta¸cõ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¸cão e de design observada naWorld Wide Web (WWW) com o objectivo de melhorar a criatividade, partilha de informa¸cão e principalmente: a colabora¸cão entre utilizadores. Estes conceitos levaram ao desenvolvimento e evolu¸cão de comunidades online tais como redes so-ciais, wikis e blogues.

(32)

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¸cão tecnológica, mas apenas a altera¸cões à forma como os utilizadores se servem da web. De acordo com Tim O’Reilly [O’R06]: “Web 2.0 é uma revolu¸cão na indústria do software, causada pela adop¸cã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¸cõ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 ass´ıncrona de envio de pedidos ou da recep¸c˜ao ass´ıncrona de respostas. As tecnologias mais frequentemente envolvidas s˜ao:

• eXtensible HyperText Markup Language (XHTML) e Cascading Style Sheets (CSS) padr˜ao para a apresenta¸c˜ao;

• interaçcão dinâmica através do DOM;

• troca e manipula¸c˜ao de dados utilizando XML e eXtensible Stylesheet Lan-guage Transformation (XSLT) ouJavaScript Object Notation (JSON);

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

• JavaScript, utilizado para integrar todas estas tecnologias.

´

E importante frisar que o Ajax não é um produto nem uma tecnologia. É um termo que descreve a utiliza¸cão de um conjunto de tecnologias para o desenvolvi-mento de web applications com um elevado grau de interactividade. Comparativa-mente àsweb applicationstradicionais, o Ajax introduz uma camada de visualiza¸cão diferente em três importantes pontos:

1. Do lado do cliente existe um motor que serve de intermedi´ario entre a interface da aplica¸c˜ao e o servidor.

2. A actividade do utilizador despoleta chamadas JavaScript em vez de um pedido de p´agina directamente ao servidor.

3. Informa¸cão codificada em XML, em vez de páginas HTML, é trocada entre o servidor e o cliente.

(33)

Isto significa que as páginas que utilizam Ajax contêm um motor do lado do cliente, composto por um conjunto de fun¸cões JavaScript, responsável pela comu-nica¸cão com o servidor e por actualizar a interface com o resultado dessa mesma comunica¸cã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 umaweb application eliminam-se diversos tempos de espera associados a comunica¸cões com o servidor uma vez que a interface não fica “bloqueada” à es-pera da resposta. Obtém-se assim aplica¸cõ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¸cã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¸cados 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¸cão independentemente do estado da liga¸cão.

Numa altura onde se fala de servi¸cos de Internet wireless municipalizados [Kha], comunica¸cões 3G e liga¸cões de banda larga a alta velocidade, a liga¸cão à rede global continua a não estar permanentemente dispon´ıvel para os utilizadores. Na WWW

encontra-se uma importante parte da informa¸cão e das aplica¸cões utilizadas para criar e editar conteúdos. Por vezes, informa¸cã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 pa´ıs diferente do habitual, onde não subscreve um plano de acesso que lhe garanta a liga¸cão.

Permitir o acesso offline a estes recursos assume assim a sua importância, porque permitirá estender o alcance da informa¸cão a locais onde nunca esteve antes, e per-mitirá também melhorar o desempenho das web applications, colocando informa¸cão mais perto dos utilizadores, reduzindo a transferência de dados apenas ao essencial.

2.4 Compara¸

c˜

ao

Nas evolu¸cões descritas neste cap´ıtulo 2 pode-se observar que existe um par-alelismo entre a evolu¸cão das arquitecturas tradicionais cliente-servidor e a evolu¸cã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

(34)

processamento, e serve apenas como uma plataforma de interaçcão com o servidor; tal como os clientes descritos na seçcão 2.1.1.

A sua próxima evolu¸cão, os fat-clients, trouxeram parte da capacidade de pro-cessamento para o lado do cliente. Na web, foi também esta a inova¸cão tecnológica a que se assistiu, com a evolu¸cão das tecnologias que permitiram a cria¸cão de ver-dadeiras aplica¸cões, e com a introdu¸cão do Javascript no browser, dando ao cliente a capacidade de processamento de dados. A necessidade da separa¸cã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¸cão de uma aplica¸cão.

Os fat-clients têm também a capacidade de armazenamento de dados, o que permite a persistência de informa¸cões entre duas sessões e que algumas opera¸cões sejam executadas sem a necessidade de comunica¸cão com o servidor. Este facto pode também ser uma realidade nasweb applicationscom a adop¸cão das tecnologiasOWA. Neste momento assiste-se a uma utiliza¸cão cada vez maior da web como uma plataforma de desenvolvimento. A capacidade de coopera¸cão na edi¸cão de conteúdos, e a mobilidade proporcionada por esta plataforma são os principais factores que alimentam esta mudan¸ca, e pela primeira vez, as aplica¸cões tradicionais têm com-peti¸cão vinda deweb 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¸caram 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¸c˜}_{ao offline significa}

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

As vantagens da mobilidade poss´ıvel através da web a coopera¸cão na cria¸cão e edi¸cão de conteúdos e a possibilidade de utilizar aplica¸cões sempre actualizadas e sem necessidade de instala¸cão são algumas das principais vantagens que promovem esta mudan¸ca, que devido às preocupa¸cões associadas à usabilidade e experiência do utilizador, está fortemente associada ao desenvolvimento de Rich Internet Applica-tion (RIA)s.

5

Adobe Acrobat.comhttp://www.acrobat.com

(35)

Figura 2.3: Compara¸cão do modelo de web aplications s´ıncrono, páginas estáticas e in-teractivas abordados nas seçcões 2.2.1 e 2.2.2, com o modelo de web applications Ajax (ass´ıncrono) abordado na seçcão2.2.3. Figura adaptada dehttp: // www. adaptivepath. com/

(36)

(37)

Cap´ıtulo 3

Estado da arte

Apesar de o conceito das OWAs n˜ao ser absolutamente novo, as tecnologias que o suportam s˜ao 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 extens˜}_{ao `}_{as funcionalidades do browser introduzido pelo Google}

que tem como principal objectivo tornar poss´ıvel a visualiza¸cão de páginas de Inter-net mesmo sem uma conexã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 trˆes componentes principais:

• LocalServer — Intercepta pedidos de p´aginas web, e serve-as localmente;

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

• WorkerPool — Permite executar opera¸cões de computa¸cão de uma forma ass´ıncrona, sem afectar a capacidade de resposta e fluidez de execu¸cão da web application. Assemelham-se a processos.

(38)

Estado da arte

LocalServer

O m´odulo LocalServer ´e uma cache de Uniform Resource Locators (URLs)

controlada pela web application. Quando não existe uma liga¸cã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 r´ıgido do utilizador. A aplica¸cão pode utilizar dois tipos diferentes de armazenamento local de URLs:

• ResourceStore – serve para capturar URLs utilizando exclusivamente a API

de Javascript disponibilizada para o efeito. Uma aplica¸c˜ao poder´a criar e utilizar diversos ResourceStores simultaneamente para capturar ficheiros de dados que necessitam de ser endere¸cados por um URL, tal como um ficheiro PDF ou uma imagem.

• ManagedResourceStore – serve para capturar um conjunto deURLsque est˜ao relacionados, e que s˜ao declarado num ficheiro de manifesto (especificado em

JSON) e que s˜ao automaticamente actualizados. O ManagedResourceStore permite que o conjunto de recursos necess´arios para correr umaweb application

seja capturado e mantido actualizado automaticamente.

A principal diferen¸ca 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¸cão.

O LocalServer é capaz de interceptar e servir localmente pedidos de HTTP e HTTPS sempre que se reúnam as seguintes condi¸cões:

1. OURLencontra-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´a conter um cookie que lhe corresponda.

O LocalServer não necessita de monitorizar o estado da liga¸cão para atender aos pedidos. Na verdade, sempre que as condi¸cões previamente enunciadas se verificarem o LocalServer interceptará os pedidos e, independentemente do estado da liga¸cão `

a Internet, servi-los-á a partir do disco r´ıgido local. Caberá à aplica¸cão definir qual o modo em que pretende executar um pedido (online ou offline), definindo o valor de verdade da propriedade enabled.

(39)

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 r´ıgido do uti-lizador2_{de acordo com o modelo de seguran¸ca estabelecido pelo Gears}3_{, significando}

que uma aplica¸cão não pode aceder a conteúdos fora do seu dom´ınio.

WorkerPool

Nos web browsers uma opera¸cão pesada de computa¸cão pode tornar a interface lenta e tornar menos agradável a experiência do utilizador. O módulo WorkerPool permite correr opera¸cões em background sem bloquear a interface com o utilizador. Os scripts executados numa WorkerPool não activam os mecanismos de seguran¸ca 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¸cão, o que significa que uma altera¸cão a uma variável num Worker não afecta em nada a execu¸cã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¸cões: os Workers não tem acesso ao DOM, e objectos como window ou document não se encontram acess´ıveis. Isto é consequência de os Workers não partilharem o estado de execu¸cão. Mas têm acesso a todas as fun¸cõ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 espec´ıficas os Workers podem “pedir” à página principal para continuar a execu¸cão através do envio de mensagens.

Outras funcionalidades

• HttpRequest – Este módulo implementa a especifica¸cão W3C XmlHttpRe-quest, definida em [vK08], tornando-a dispon´ıvel para os workers e para a página principal.

• Timer – Este módulo implementa a especifica¸cão de timers tal como descrito por [Hic08], e torna-os dispon´ıveis para os workers e para a página principal

2

Consultar: http://code.google.com/apis/gears/api_database.html#directories

(40)

Estado da arte

• Factory – Esta classe é utilizada para instanciar todos os outros objectos da API 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´oveis

O Gears est´a tamb´em dispon´ı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¸cão as latências na transferência de dados em redes móveis tornam as aplica¸cões pouco flu´ı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¸cã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¸cões dos browsers dispon´ıveis para dispositivos móveis têm que ser consideradas. Isto significa prever as condi¸cõ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_´_{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 produ¸cão de conteúdos para a Internet no desenvolvimento deRich Inter-net Application (RIA)s. O Adobe AIR mantém uma rela¸cão com o browser, mas es-tende as suas capacidades e tecnologias, permitindo o desenvolvimento de aplica¸cõ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¸cões. Para este efeito o Adobe AIR tem uma aproxima¸cão diferente do Gears. Em vez de “estender” o browser acrescentando-lhe funcionalidades, o AIR permite também o desenvolvimento de

(41)

Estado da arte

aplica¸c˜oes 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¸cão desta tecnologia permite utilizar o browser ou o próprio runtime Adobe AIR, como plataforma de execu¸cão da aplica¸cão.

Na Tabela 3.1 faz-se uma compara¸cão das funcionalidades dispon´ıveis de acordo consoante se escolha o browser ou o desktop como plataforma base para a aplica¸cão. Uma vez que as aplica¸cõ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¸ca que se assemelha com o das tradicionais aplica¸cões desktop [Ada08]. Este modelo é analisado nas seçcões 3.2.1 e 3.2.2. O ambiente em que é executado o browser é restringido à execu¸cão de web applications que podem ser de várias origens (incluindo de origens anónimas ou sem confian¸ca). O Adobe AIR proporciona acesso a capacidades como acesso a ficheiros, que necessitam da confian¸ca do utilizador.

• HTML – O desenvolvimento de aplica¸c˜oes para o Adobe AIR pode ser feito com recurso a tecnologias de HTML e Ajax comuns, utilizando as linguagens de markup existentes, distribu´ıdas como texto e interpretadas em execu¸c˜ao (runtime);

• Flash – Outra alternativa será a utiliza¸cão da linguagem Flash. Permite a renderiza¸cão de gráficos vectoriais e áudio/v´ıdeo com suporte nativo. Utiliza ActionScript para adicionar maior interactividade com o utilizador;

• Flex – OFlex é uma framework open source para o desenvolvimento de RIAs usando Flash. As aplica¸cões Flex são na realidade Flash, sendo a principal diferen¸ca o ambiente de desenvolvimento.

Como resultado, uma aplica¸c˜ao AIR poder´a ser implementada:

• Baseada em Flash ou Flex (aplica¸cões cujo conteúdo base é em ShockWave Flash (SWF));

• Baseada emFlashouFlex, também comHTMLouPortable Document Format (PDF). Aplica¸cões cujo conteúdo de base é emFlash/Flex (SWF) com HTML

(HTML, JavaScript, CSS) ou conte´udo PDF inclu´ıdo;

• Baseada em HTML. Aplica¸cões cujo conteúdo base é em HTML, Javascript,

CSS;

(42)

Estado da arte

Os utilizadores interagem com uma aplica¸cão AIR da mesma forma que interagem com outras aplica¸cõ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¸cões AIR terão o mesmo aspecto que qualquer outra aplica¸cão para o desktop.

3.2.1 Seguran¸ca

Permitir que umaweb applicationaceda ao disco de armazenamento do utilizador pode comprometer seriamente a sua seguran¸ca. 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¸cão. Um outro aspecto ainda relativo à seguran¸ca é o mecanismo de isolamento de cada ambiente (sandbox ).

3.2.2 Assinatura do c´odigo

O runtime AIR exige que todas as aplica¸cões estejam digitalmente assinadas. As assinaturas digitais de código são um processo que visa garantir a integridade da aplica¸cão e a identidade do seu autor, no momento da instala¸cão. As equipas de desenvolvimento podem “assinar” uma aplica¸cão utilizando um certificado atribu´ı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¸cão quando o código tiver sido assinado com um certificado que apresente confian¸ca, ou que esteja encadeado com um certificado que tenha já sido aceite no computador em que se está a instalar a aplica¸cão.

As equipas de desenvolvimento podem também assinar as aplica¸cões com um certificado auto-atribu´ıdo (um certificado criado por elas próprias), mas neste caso o instalador apresentará estas aplica¸cõ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¸cão seja reconhecida, o computador onde a aplica¸cão AIR está a ser instalada tem que confiar directamente no certificado que foi utilizado para assinar a aplica¸cã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¸cão.

Todas as aplica¸cões AIR têm caracter´ısticas em comum, independentemente da tecnologia utilizada para o seu desenvolvimento (HTML/Flex/Flash). No âmbito de uma aplica¸cão AIR existem um conjunto de APIs que estão dispon´ıveis e que tornam poss´ıvel o acesso ao sistema local (leitura e escrita) e a recursos de rede que

(43)

Estado da arte

de outra forma nunca estariam acess´ıveis a partir de uma web application comum. Cada aplica¸cão AIR possui também diferentes n´ıveis de isolamento, chamados secu-rity sandboxes, dependendo do tipo de conteúdo que está a ser carregado e do seu objectivo:

• Isolamento ao n´ıvel da aplica¸c˜ao5 _{– ´}_{E a raiz de cada aplica¸c˜}_{ao AIR. Este}

n´ıvel de isolamento permite o acesso a APIs privilegiadas e espec´ıficas do AIR. Em contrapartida, é negado o acesso a algumas APIs que poderiam ser facilmente utilizadas de forma maliciosa contra o utilizador final. Importa¸cão dinâmica de conteúdos remotos é geralmente proibido e as técnicas e mecan-ismos de gera¸cão dinâmica de código são fortemente restringidas. Apenas conteúdo carregado directamente da directoria base da aplica¸cão poderá ser colocado neste n´ıvel de isolamento.

• Isolamento não espec´ıfico da aplica¸cão6 – contém todo o outro conteúdo que não tenha sido carregado directamente para o isolamento da aplica¸cã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¸cã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¸cão baseada em XML desenvolvida pela Mozilla Foundation que opera em aplica¸cões Mozilla multi plataforma, tal como o Firefox. O motor Gecko é a única imple-menta¸cão completa desta linguagem, que foi desenhada sobre padrões web comuns, comoCSS, JavaScript e oDOM, e permite o desenvolvimento de interfaces gráficas utilizando elementos pré-definidos tais como window, box, page, textbox, radio button, entre outros . Infelizmente oXULnão possui qualquer especifica¸cão formal ou implementa¸cões de inter-operabilidade para outros motores que não o Gecko. No entanto a sua implementa¸cão é licenciada em código aberto, pelas licen¸casGNU Gen-eral Public License (GPL), GNU Lesser General Public License (LGPL) e Mozilla Public License (MPL).

Enunciam-se algumas caracter´ısticas desta linguagem:

5

NT.: application sandbox

(44)

Estado da arte

Liguagem de anota¸cão poderosa baseada em componentes (widgets): O ob-jectivo do XUL é permitir a constru¸cão de aplica¸cões multi-plataforma, em claro contraste com oDynamic 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¸calhos de texto, e liga¸cões de hipertexto. Investir tempo e esfor¸co para atingir este mesmo resultado em aplica¸cões baseadas emDHTML, compromete frequentemente a complexidade e desempenho da aplica¸cão.

Baseado em padrões OXUL é um dialecto XMLbaseado no padrão W3C XML 1.0. As aplica¸cões escritas em XUL são também baseadas em especifica¸cõ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 é utilizado, tornando as aplica¸cões facilmente portáveis entre sistemas operativos nos quais o Mozilla é suportado. Uma vez que o XUL oferece um n´ıvel de abstraçcã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¸cos), é escrita em XUL, com um ´

unico c´odigo base que suporta todas as plataformas Mozilla.

Separa¸cão entre o n´ıvel de apresenta¸cão e a lógica de negócio: Uma das maiores preocupa¸cões no desenvolvimento para a Internet é a forte liga¸cão entre estas duas camadas (interface e lógica). Isto constitui um problema sig-nificativo no desenvolvimento de grandes aplica¸cões, especialmente quando o desenvolvimento é feito em ambientes de equipa, porque as capacidades de de-senvolvimento destas duas partes da aplica¸cão estão muitas vezes espalhadas por diferentes elementos. OXULpermite uma clara distin¸cão entre a defini¸cão da aplica¸cão cliente e da lógica de implementa¸cão (XUL, eXtensible Binding Language (XBL) e JavaScript), apresenta¸cão (CSS e imagens), internacional-iza¸cão (Document Type Definitions (DTDs) e etiquetas de texto em l´ınguas espec´ıficas guardados em ficheiros .properties). O esquema gráfico e apre-senta¸cão de uma aplica¸cão XUL pode ser alterado de forma independente da sua lógica ou implementa¸cão, e a aplica¸cão pode ainda ser traduzida (interna-tionalization) de forma independente da sua lógica, implementa¸cão ou apre-senta¸cão. Este grau de separa¸cão resulta em aplica¸cões que são mais fáceis de manter pelos programadores e facilmente adaptadas por designers e tradutores.

(45)

Estado da arte

Fácil adapta¸cão Outro benef´ıcio que advém do n´ıvel de separa¸cão entre lógica de negócio e apresenta¸cão oferecido pelo XUL é a facilidade com que se pode adaptar uma aplica¸cão para diferentes clientes ou grupos de utilizadores. Um programador pode utilizar a mesma aplica¸cão base e adaptá-la consoante as necessidades, através de diferentes temas (skins) e ficheiros de l´ınguas. Desta forma, uma aplica¸cão escrita e desenvolvida em Inglês pode ser rapidamente traduzida para Português e distribu´ı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¸cã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¸cã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¸cas entre as desktop applications tradicionais e as web applications. Um dos aspectos focados é a experiência do utilizador. Numa apresenta¸cão oficial é dito que “[o Prism] pretende ser uma ponte entre as diferen¸cas que existem entre as aplica¸cõ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¸cão HTML 5 [Hic08], que se encontra em fase de desenvolvimento pelo grupo WHATWG, pretende ser uma norma de substitui¸cã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¸cão –é aqui mencionada por ter servido como referência a diversas implementa¸cões de funcionalidades offline, e por se considerar que venha a ter um impacto significativo nas implementa¸cões de diversos browsers. Dion Almaer defendeu no seu blogue que o Gears era uma implementa¸cão do

HTML5. 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

(46)

Estado da arte

semelhantes e não encontrar motivo de “competi¸cão” entre as duas, mas que en-quanto o HTML 5 é uma especifica¸cão o Gears é uma implementa¸cão.

No entanto, também é verdade que oHTML 5 cobre muitos outros pontos para além das OWA que saem completamente fora do âmbito do Gears. Se esta es-pecifica¸cão atingir um estado de maturidade que possibilite a sua adop¸cã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¸c˜ao 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”HTTPque garante a disponibilidade das aplica¸cões mesmo quando o utilizador não possui uma liga¸cão à Internet.

Estas caracter´ısticas são as bases da tecnologia das OWA e têm correspondência com os pontos analisados nas seçcões 3.1.1 e3.1.1

3.5 Web applications que usam funcionalidades offline

Nesta seçcão apresentam-se algumas web applications que actualmente disponi-bilizam funcionalidades offline. Estas aplica¸cões foram escolhidas para uma análise mais pormenorizada por utilizarem o Gears, que tal como descrito na seçcã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 subscri¸c˜}_{ao de v´}_arios

sites simultaneamente que disponibilizem conte´udos neste formato e foi a primeira web application da Google com uma vers˜ao offline publicamente acess´ıvel (desde Junho de 2007).

O Google Reader implementa o modo “utilizador decide”, oferecendo na sua interface um bot˜ao que permite alternar entre os modos online e offline.

O Google Docs8 _´_{e uma web application que permite a cria¸c˜}_{ao e edi¸c˜}_{ao de}

doc-umentos de texto, folhas de cálculo e apresenta¸cões. Era já público desde Janeiro de 2008 que o Google estava a desenvolver uma versãoOWA desta aplica¸cão, mas o acesso a uma versão experimental só foi poss´ıvel a partir de 31 de Maio de 2008.

7

Google Reader -http://reader.google.com/