Offline Web Applications

Faculdade de Engenharia da Universidade do Porto

Oﬄine Web Applications

Enabling oﬄine execution on the WOW! product

Jo˜aoGon¸calves da Costa

Relatóriode Projecto realizado no Ambitoˆ do Mestrado Integrado em Engenharia Informáticae Computa¸cão

Orientador: Teresa Galv˜aoDias (PhD.)

Julho de 2008 c Jo˜aoGon¸calves da Costa, 31 de Julho de 2008 Oﬄine Web Applications

Jo˜aoGon¸calves da Costa

Relatóriode Projecto realizado no Ambitoˆ do Mestrado Integrado em Engenharia Informáticae Computa¸cão

Aprovado em provas p´ublicaspelo j´uri:

Presidente: Pedro Ferreira do Souto (PhD)

Arguente: Artur Pereira (PhD) Vogal: Teresa Galv˜aoDias (PhD)

27 de Julho de 2008

Resumo

Este projecto teve como objectivo o estudo das Offline Web Applications (OWAs) e da sua implementa¸cãoem web applications jáexistentes. Neste âmbito, foi feita uma avalia¸cãoda aplica¸cãodesta tecnologia no WOW!, uma plataforma integrada de gestãode ordens de trabalho, desenvolvida pela Critical Software S.A. ao longo dos últimos6 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ésdo browser mesmo na ausênciade 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ãodos problemas associados à sua implementa¸cãoe respectivas solu¸cõese tambémda avalia¸cãodos benef´ıciosda utiliza¸cãodesta tecnologia para os utilizadores finais. A evolu¸cãodas tecnologias associadas àInternet, a que se assiste continua- mente, impulsionou também evolu¸cãoda forma como a informa¸cãoéproduzida, distribu´ıdae armazenada. Surgiram novas web applications oferecendo funcionalidades de cria¸cãoe edi¸cãode conteúdos,que trouxeram consigo a vantagem de tornar poss´ıvel o acesso àinforma¸cãoa partir de qualquer lugar, mas tambéma desvan- tagem de tornar a liga¸cãoàInternet uma condi¸cãonecessáriapara que isto aconte¸ca. A prolifera¸cãodestas aplica¸cões,a crescente utiliza¸cãoda Internet [Gro08] e a adesão aos seus servi¸cosindiciam a existênciade uma dependênciacada vez maior de uma liga¸cão,que nem sempre existe. As OWAs vêmassim colmatar esta falha, colocando no lado do cliente parte da informa¸cãoque atéagora vinha a ser armazenada no servidor e tornando nãosó poss´ıvel a sua consulta offline, como tambémreduzindo a carga no servidor, uma vez que reduz as transferênciasde informa¸cão. Pretende-se neste documento apresentar diferentes formas de como a utiliza¸cão da tecnologia OWA pode beneficiar as web applications de hoje, melhorando o seu desempenho e dando-lhes novas possibilidades de execu¸cão,aproximando-as do desktop.

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 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 information is produced, distributed and stored. New web applications appeared, with new content creation and edition functionalities, and with it, the advantage of information 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 applications 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

iii iv Agradecimentos

A realiza¸cãoe os objectivos alcan¸cados neste projecto nãoteriam sido poss´ıveis sem a colabora¸cãode inúmeraspessoas. Agrade¸coprofundamente a todos os que contribu´ıramdirecta ou indirectamente para o seu sucesso:

A` minha orientadora, Professora Teresa Galv˜aoDias, 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´ıcioCosta e o FábioMatos, que contribu´ırampara a minha a minha integra¸cãona Critical Software e que sempre souberam responder a todas as minhas questões,

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

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

Os meus sinceros agradecimentos! Jo˜aoGon¸calves da Costa

v vi Conte´udo

1 Introdu¸c˜ao1 1.1 Enquadramento ...... 1 1.2 Motiva¸c˜ao ...... 2 1.3 Ambitoˆ ...... 3 1.4 Objectivos ...... 3 1.5 Estrutura do documento ...... 3

2 Enquadramento do Projecto5 2.1 Evolu¸cãodas 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ãona Internet ...... 8 2.2.1 Páginas web estáticas...... 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ão...... 13

3 Estado da arte 17 3.1 Gears ...... 17 3.1.1 Arquitectura ...... 17 3.1.2 Goggle Gears em dispositivos móveis ...... 20 3.2 Adobe AIR ...... 20 3.2.1 Seguran¸ca ...... 22 3.2.2 Assinatura do código ...... 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 3.6 Escolha da tecnologia ...... 28

vii CONTEUDO´

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ão ...... 35 4.2.1 Modo “utilizador decide” ...... 36 4.2.2 Modo aplica¸cãodecide ...... 36 4.2.3 Modo “aplica¸cãoassume o estado offline”...... 37 4.3 Sincroniza¸cãode dados ...... 38 4.3.1 Quando sincronizar? ...... 39 4.4 WOW!...... 40 4.5 Visãogeral sobre a arquitectura do WOW! ...... 41 4.6 WOW! Offline ...... 42 4.6.1 Modo “aplica¸cãodecide” com deteçcãoautomáticada liga¸cão 43 4.6.2 Implementa¸cãodo modo “utilizador decide” ...... 45 4.6.3 Especifica¸cãodo modo “aplica¸cãoassume o estado offline”.. 48

5 Resultados e Futuros Desenvolvimentos 51 5.1 Resultados Obtidos ...... 51 5.2 Trabalho Futuro ...... 52

6 Conclus˜oes 55 6.1 Conclus˜oes...... 55

Referˆencias 59

A Screenshots 61

viii Lista de Figuras

2.1 Arquitectura de um sistema thin-client em duas camadas (àesquerda) e em trêscamadas (àdireita). Note-se a inclusãodo servidor (mainframe) na defini¸cãodas camadas desta arquitectura, devido àforte dependênciacliente-servidor...... 9 2.2 Arquitectura de um fat-client em duas camadas (àesquerda) e em trêscamadas (àdireita)...... 10 2.3 Compara¸cãodo modelo de web aplications s´ıncrono,páginas estáticas e interactivas abordados nas seçcões 2.2.1e 2.2.2, com o modelo de web applications Ajax (ass´ıncrono)abordado na seçcão 2.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ãodos conteúdosdefinidos no ficheiro manifesto...... 29

4.1 Exemplo de uma arquitectura de uma web application sem uma camada de abstraçcãode dados. Figura adaptada de http: // gears. google. com/ ...... 33 4.2 Exemplo de uma arquitectura de uma web application com uma camada de abstraçcãode dados. Figura adaptada de http: // gears. google. com/ ...... 34 4.3 Exemplo de uma arquitectura de uma web application com uma camada de abstraçcãode dados e um data switch. Figura adaptada de http: // gears. google. com/ ...... 35 4.4 Esquema gráficoilustrando uma OWA executando no browser utilizando um modo de execu¸cãodo tipo “aplica¸cãodecide”, com de- teçcãoautomáticado estado da liga¸cãovia 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ãoem fecho ou cancelamento. Esta figura representa apenas um exemplo, jáque o mapa de estados para uma ordem de trabalho édinâmicoe pode ser alterado por um administrador. Figura retirada de uma brochura promocional do WOW!, Critical Software S.A...... 41

ix LISTA DE FIGURAS

4.6 A páginainicial do WOW apresenta um resumo das últimasordens de trabalho enviadas e recebidas. Na imagem pode-se observar a transi¸cãodo estado online para offline...... 44 4.7 Ilustra¸cãodo funcionamento do Gears numa web application que utiliza um motor Ajax. Os pedidos HTTP ou HTTPS podem ser interceptados e tratados localmente ou podem ser feitos a uma máquina remota, consoante se verificarem ou nãoas condi¸cõesexpressas no ponto 3.1.1. E´ 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ãodecide”, o teste da liga¸cãoéfeito éfeito a cada cinco segundos. O resultado deste teste nãoreflecte sempre o estado real da aplica¸cão,podendo levar a aplica¸cãoa ter comportamentos indesejáveis. Na figura assinala-se um per´ıodo de tempo no qual a representa¸cãointerna do estado da liga¸cãonãocor- responde àrealidade...... 46 4.9 Páginade visualiza¸cãodo 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álogoapresentado ao utilizador na primeira activa¸cãodas funcionalidades offline no Google Docs & Spreadsheets...... 61 A.2 Na activa¸cãodas funcionalidades offline étambémoferecida a possibilidade da cria¸cãode alguns atalhos, por exemplo, no ambiente de trabalho...... 62 A.3 O Google Docs mantéma todo o momento a possibilidade de altera¸cão destas defini¸cões,ou da anula¸cãodos servi¸cosoffline para um dado computador...... 62 A.4 Apósa instala¸cãodo Gears qualquer visita ao Remember The Milk despoleta uma sincroniza¸cãoque ocorre automaticamente e sem necessidade de interven¸cãopor parte do utilizador...... 63 A.5 Apóscompletar a sincroniza¸cãode dados, mesmo que a liga¸cãoà Internet seja perdida o Remember the Milk continua dispon´ıvel no browser (com excep¸cãodas funcionalidades que pela sua natureza exigem uma liga¸cão,como por exemplo: partilha de tarefas e envio de convites.) ...... 63

x Lista de Tabelas

2.1 Compara¸cãoentre thin-clients e fat-clients ...... 7 3.1 Compara¸cãodas funcionalidades oferecidas pelo Adobe AIR para as plataformas web e desktop ...... 30 3.2 Resumo da utiliza¸cãode tecnologias OWA em algumas web applications consideradas na análisedo estado da arte...... 31

xi LISTA DE TABELAS

xii Gloss´ario

fat-client Cliente que nãodepende totalmente de um 6–8 servidor central para as suas actividades de processamento e possui frequentemente dispositivos de armazenamento de dados. thin-client Cliente que depende de um servidor central 5–8 para as suas actividades de processamento. web application Sistema web (servidor, rede HTTP, i, iii, browser) onde açcões do utilizador 1–3, (navega¸cão e introdu¸cão de informa¸cão) 11–15, afectam o estado lógicoda aplica¸cão. 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 11 que permite a cria¸cão de páginas web dinâmicas.Desenvolvida pela Microsoft.

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 DTD Document Type Deﬁnition 24

xiii Gloss´ario

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

Flash Conteúdointeractivo de um ficheiro em 21 formato SWF. E´ desenvolvido pela Adobe e visualizado através do Adobe Flash Player. Flex Framework baseada em XML e Action- 21 Script desenvolvida pela Adobe para a programa¸cãode Rich Internet Applications (RIA)

GPL GNU General Public License 23

HTML HyperText Markup Language1, 10– 12, 21, 24–26, 49 HTTP HyperText Transfer Protocol2, 26

JMS E´ uma API em Java que permite a troca de 42 mensagens entre componentes de software. JSON JavaScript Object Notation, permite a 12, 18, troca de dados, codiﬁcados num formato 28, 34 de texto de simples leitura

LGPL GNU Lesser General Public License 23

Mozilla Prism Browser simplificado e “interpretador” de 25 eXtensible User Interface Language (XUL) (tambémdesignado por XULRunner) que acolhe web applications sem a interface gráficahabitual de um browser. MPL Mozilla Public License 23

OCA Occasionally Connected Application 39 OWA Oﬄine Web Applicationi, iii, 2–5, 15, 17, 25, 26, 28, 31, 33, 36, 51, 52, 55, 56

PDF Portable Document Format 21

xiv Gloss´ario

PHP Linguagem interpretada pelo servidor 11 que permite a cria¸cão de páginas web dinâmicas,mas que pode tambémser in- vocada a partir da linha de comandos. página web estática Página web que devolve sempre a mesma 5,9 resposta a todos os pedidos, para todos os utilizadores e em qualquer contexto.

RIA Rich Internet Applications web appli- 5, 15, cations que apresentam funcionalidades 20, 28 semelhantes ás desktop applications, mas que mantéma informa¸cãono lado do servidor RSS Really Simple Syndication 27

SLA Service Level Agreement 40 SQLite Segundo a defini¸cãooficial: SQLite is a 17 software library that implements a self- contained, serverless, zero-configuration, transactional SQL database engine.. 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 i, iii, de ordens de trabalho e do seu ﬂuxo, de- 28, 33, senvolvida pela Critical Software S.A. 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- 12 mation XUL eXtensible User Interface Language xiv, 23–25

xv Gloss´ario

xvi Cap´ıtulo1

Introdu¸c˜ao

Neste cap´ıtuloenquadra-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¸code partilha de informa¸cão,onde pessoas (atravésde máquinas)pudessem comunicar. Na sua origem, as páginaseram estáticas,constitu´ıdaspor 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´ıdeoou 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áriasdas seguintes categorias:

• Documento – um website essencialmente estático,onde altera¸cõesa uma parte do conteúdonãotem implica¸cõesno seu comportamento.

• Base de dados – um direct´oriode informa¸c˜aoorganizada 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õesou informa¸cãoin- troduzida pelo utilizador para fornecer um servi¸coou nova informa¸cão.

A últimadestas 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¸cão sistema web (servidor, rede HyperText Transfer Protocol (HTTP), browser) onde açcõesdo utilizador (navega¸cãoe introdu¸cãode informa¸cão)afectam o estado lógico da aplica¸cão. A sua defini¸cãotenta estabelecer que uma web application éum sistema de software com estado de negócio1, e que a sua interface de interaçcãocom o utilizador édistribu´ıdoatravésde um sistema web.

1.2 Motiva¸c˜ao

A quantidade de informa¸cãoque éproduzida e armazenada com recurso a estas web applications dispon´ıveis online, tais como e-mail, blogues ou mesmo documenta¸cão,tornam por vezes a disponibilidade de liga¸cãouma condi¸cãonecessária àprodutividade e, como consequênciadesta barreira, muitos potenciais utilizadores opõem-seàadop¸cãode produtos web em detrimento das tradicionais desktop applications. Assegurar o acesso a uma liga¸cãode 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õesnas quais os utilizadores estãoprivados de uma liga¸cão àInternet, tais como uma viagem de metro ou de avião,ou quando se encontram deslocados do seu pa´ıs de origem e nãopossuem nenhum plano de subscri¸cão. Uma OWA consiste numa web application que para alémde manter todas as caracter´ısticasanteriores, se mantémdispon´ıvel mesmo na ausênciade uma liga¸cã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¸cãodo estado lógicoda aplica¸cãoquando a liga¸cãocom 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ãose encontra quando a liga¸cãofor reposta. A principal vantagem que advémdesta possibilidade éevidente: eliminar a necessidade da existênciade uma liga¸cãoàInternet para que a aplica¸cãopossa ser utilizada. Por outro lado, a vontade de integra¸cãode funcionalidades t´ıpicasdas 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ãodas 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ãotornar poss´ıveis interaçcõesentre 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óricodo clipboard ou ainda o acesso ao sistema de ficheiros local. Atingir estes objectivos reflecte-se

1NT. business state

2 Introdu¸cão num novo paradigma, que reúneas vantagens das web applications, tais como os updates instantâneosou o facto de nãoser necessárianenhuma instala¸cão,e das desktop applications, como por exemplo: persistênciano armazenamento de dados, acesso a funcionalidades do sistema operativo ou integra¸cãoe interaçcãocom 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áticae 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ãoobjectivos deste projecto: 1. Estudar e documentar o tema das OWAs acompanhando os últimos desenvolvimentos nesta matéria.

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 oﬄine de uma web application, documentando todo o processo.

4. Estudar a possibilidade de permitir interaçcãocom a aplica¸cão(inser¸cõese altera¸cõesaos 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ãoseja 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êncialógicaorganizada da seguinte forma:

No cap´ıtulo1 faz-se uma breve apresenta¸cãodo conceito OWAs e do contexto em que surge. Apresenta-se tambéma estrutura do documento e definem-se os termos e acrónimosutilizados.

3 Introdu¸c˜ao

No cap´ıtulo2 faz-se uma descri¸c˜aoda evolu¸c˜aodas tecnologias que antecedem as OWAs e das vantagens e desvantagens de cada uma, como forma de enquadramento.

No cap´ıtulo3 analisa-se o estado da arte nesta matéria. Introduzem-se diversas tecnologias directamente relacionadas com o tema deste projecto, exemplos de aplica¸cõesque as usam e as razõesque fundamentam as escolhas de tecnologias efectuadas.

O cap´ıtulo4 contem o desenvolvimento do projecto. Analisa-se a plataforma WOW! de gestãointegrada de ordens de trabalho, a tecnologia escolhida e a forma como foi utilizada para implementar a capacidade de execu¸cão offline.

O cap´ıtulo5 descreve os resultado obtidos, comparando-os com as expectativas iniciais do projecto e apresenta desenvolvimentos futuros e possibilidades de continua¸c˜ao/aplica¸c˜aodo conhecimento adquirido.

No cap´ıtulo6 apresentam-se as conclus˜oes.

4 Cap´ıtulo2

Enquadramento do Projecto

Neste cap´ıtuloapresenta-se um breve resumo da evolu¸cãodas arquitecturas de software cliente-servidor e a forma como estas se comparam àevolu¸cãoda Inter- net, procurando estabelecer uma analogia entre o percurso de ambas as tecnologias. Compara-se o comportamento e arquitectura dos thin-clients às páginas web estáticas, a evolu¸cãodos fat-clients àspáginasinteractivas, Web 2.0 e Ajax, e defende-se que as OWA constituem um próximopasso lógicoe evolutivo, aproximando a web do desktop. Referem-se ainda os principais factores que justificam a importânciadas OWAs e a estreita rela¸cãoque têmcom as Rich Internet Application (RIA)s.

2.1 Evolu¸c˜aodas arquitecturas de software

Os termos thin-client e fat-client sãoutilizados 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ãoem contrário,estes termos referem-se sempre a uma arquitectura lógica. Adicionalmente, quando se trata de arquitecturas cliente-servidor pode-se estudar a arquitectura desenvolvida do sistema como um todo, da arquitectura do servidor ou da arquitectura do cliente. Para evitar equ´ıvocos, em especial na seçcão 2.1.3, especifica-se em cada caso qual o sistema estudado.

2.1.1 Thin-clients

Um thin-client ´eum computador cliente ou software cliente, que no contexto de uma arquitectura cliente-servidor, depende de um servidor central para as suas

5 Enquadramento do Projecto actividades de processamento e proporciona um canal de entrada e sa´ıda de informa¸cãoentre 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´ıciodas aplica¸cõescliente-servidor. No in´ıcioda históriada 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õesdistintas: uma aplica¸cãocentral no servidor (mainframe), responsável pela gestão de toda a informa¸cãoe por todas as opera¸cões de comunica¸cão,e uma aplica¸cãode visualiza¸cão,instalada no cliente (terminal). O papel destes terminais era apenas disponibilizar ao utilizador um meio de comunica¸cão(entrada e sa´ıda)e apresenta¸cãodos resultados do servidor. Nãotinham um papel activo no cálculonem na lógicade negócioe frequentemente nãotinham tambémnenhum mecanismo de armazenamento de dados. Como vantagens, esta arquitectura apresenta uma reduzida necessidade de configura¸cãoe manuten¸cãodo lado do cliente. Uma vez que o centro do processamento e manipula¸cãode dados ocorre no servidor, existe tambémuma centraliza¸cãoda informa¸cão[NJN00] que introduz um ponto cr´ıticode falha1. Actualiza¸cõese novas funcionalidades sãofáceisde distribuir, uma vez que requerem apenas altera¸cõesno servidor [Gro02a].

2.1.2 Fat-clients

Contrastando com os thin-clients, nesta arquitectura os clientes implementam jáuma parte da lógicade negócio e sãoresponsáveis pelo processamento de dados. Estes fat-clients vieram responder ànecessidade crescente de aplica¸cõescom um n´ıvel de interactividade e capacidade de configura¸cãomaior 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émser executados sem uma conexãoactiva uma vez que dispõede armazenamento de dados local, o que lhes confere a capacidade de persistênciade dados e do estado de execu¸cãoentre 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ãoe uma actualiza¸cãoao servidor implicava in- variavelmente uma actualiza¸cãomanual tambémno cliente. Uma vez que nem todos

1NT.: single point of failure

6 Enquadramento do Projecto

Thin-clients Fat-clients Nãotoma parte no processamento de Participa activamente no processa- dados nem possui acesso ao sistema de mento de dados, recorrendo ao sis- ficheiros. tema de armazenamento local para armazenamento de dados. Nãomantémregisto do estado lógico O acesso ao armazenamento local da aplica¸cãoentre duas sessõesde uti- permite-lhe manter registo do estado liza¸cão. lógicoda aplica¸cãoentre duas sessões. O thin-client nãonecessita de qualquer E´ geralmente necessário instalar a instala¸cão,estando “pronto a utilizar”. aplica¸cãopara poder interagir com o servidor Qualquer update no servidor reflecte-se Embora a aplica¸cãocliente possa aler- imediatamente por todos os clientes. tar para existênciade novas versões, as actualiza¸cõestêm que ser manualmente instalados pelo cliente. O software do cliente destina-se apenas Como o software do cliente toma parte àapresenta¸cãode dados e comunica¸cão activa no processamento de dados, com o servidor, sendo portanto, de sim- a sua implementa¸cãorequer cuidados ples implementa¸cão. adicionais. Grande mobilidade, uma vez que toda Parte da informa¸cãopoderáestar ape- a informa¸cãoémantida no servidor nas do lado cliente, pelo que existem algumas restri¸cõesàsua mobilidade.

Tabela 2.1: Compara¸cãoentre thin-clients e fat-clients os utilizadores actualizam regularmente as suas aplica¸cões,o servidor tem que estar preparado para lidar com versõesantigas2, ou descontinuar os seus servi¸cosa 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õesque nãosejam sincronizadas com o servidor estãoapenas 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ãoas desvantagens dos fat- clients, e que as vantagens dos fat-clients sãoas 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¸cose um servidor como um prestador de servi¸cos,tal como definido por [Sch96] e [Sad97].

2NT. backward compatibility

7 Enquadramento do Projecto

As arquitecturas cliente-servidor sãocategorizadas pela modulariza¸cãocom que sãodesenhadas, sendo consideradas as seguintes camadas:

1. Interface gráfica (front-end) atravésda 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ãoimplementa regras de negócio(embora possa definir valida¸cõesde formuláriosde inser¸cãode dados, por exemplo). A informa¸cãointroduzida 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ógicade negócio, tambémdesignada por camada intermédia,que implementa as regras de aceita¸cãoe valida¸cãode todos os dados introduzidos pelo utilizador. E´ tambéma plataforma de comunica¸cãoque une a camada superior de visualiza¸cãocom a camada de acesso a dados;

3.A camada de dados inclui quer o sistema de persistênciade dados, onde são armazenados os dados relevantes, como tambémos mecanismos necessários para a sua pesquisa, seleçcãoe altera¸cã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êscamadas, dependendo apenas da forma como o servidor for implementado. No caso de, na implementa¸cãodo servidor nãose distinguir a camada de acesso a dados da camada da lógicade negócio,sãodesignados por sistemas de duas camadas. Caso seja feita esta distin¸cão,sãodesignados por sistemas de trêscamadas. Ambos os casos são ilustrados na Figura 2.1. Historicamente, os fat-clients eram implementados numa arquitectura em duas camadas. Possu´ıamapenas um módulode visualiza¸cãode dados, designado por camada de interface, e um móduloque implementava toda a lógicade negócioe regras de acesso àbase de dados. No entanto, com a introdu¸cãode liga¸cõesmais rápidase de computadores pessoais com maior capacidade de processamento e so- bretudo devido àcomplexidade crescente das aplica¸cões,a lógicade negócio e a camada de acesso a dados tornaram-se independentes. Este modelo édesignado por arquitectura em trêscamadas e éilustrado na Figura 2.2.

2.2 Evolu¸c˜aona Internet

Ao analisar a evolu¸cãodas arquitecturas das aplica¸cõesdesenvolvidas para a Internet, podemos encontrar um paralelismo com a históriada arquitectura de software.

8 Enquadramento do Projecto

Figura 2.1: Arquitectura de um sistema thin-client em duas camadas (àesquerda) e em trêscamadas (àdireita). Note-se a inclusãodo servidor (mainframe) na defini¸cãodas camadas desta arquitectura, devido àforte dependênciacliente-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ãoentre diversas páginas estáticas. A informa¸cãoéarmazenada num servidor, e o papel do cliente éapenas a apresenta¸cãoda informa¸cão.Esta forma de disponibiliza¸cãode informa¸cãopode assim ser comparada com os thin-clients descritos na seçcão 2.1.1: o utilizador acede a um website estáticopara visualizar informa¸cãosem que o cliente tome parte no processamento. A únicadiferen¸caéque no caso da web estáticaa informa¸cãoap- resentada ésempre a mesma, enquanto que nos thin-clients era frequente existir a possibilidade de inser¸cãode dados no cliente e apóso seu processamento servidor, nova informa¸cãopoderia ser apresentada. O hipertexto éutilizado para ligar as páginasentre si numa rede de conteúdosrelacionados, e a navega¸cãos´ıncronaera feita atravésde cliques do rato: a cada clique uma nova páginaera apresentada. Este modelo s´ıncronoéilustrado na Figura 2.3.

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

O JavaScript ´euma 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êscamadas (àdireita).

Programming Interface (API) públicapara criar “objectos” responsáveis por reflectir e disponibilizar o Document Object Model (DOM) para o motor de JavaScript. A utiliza¸cãomais frequente desta linguagem éa escrita de fun¸cõesque sãoem- bebidas ou inclu´ıdasem páginasweb e que interagem com o DOM. Uma vez que o JavaScript éexecutado localmente (na máquina do cliente e nãono servidor) écapaz de responder rapidamente a açcõesdo utilizador, tornando a execu¸cãode aplica¸cões no browser mais flu´ıdas;o JavaScript pode tambémdetectar açcõesdo utilizador que o HTML nãopode, 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éma suportar uma versãosemelhante desta linguagem (hoje, todos os principais browsers suportam esta tecnologia). Esta inova¸cãopermitiu tornar os websites mais interactivos, mas a sua utiliza¸cão esteve confinada apenas a este propósitodurante um longo per´ıodo. As páginas passaram a responder activamente a açcõesdo utilizador (sendo uma das utiliza¸cões

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

10 Enquadramento do Projecto mais vulgares a valida¸cãode formulários)mas continuaram essencialmente estáticas. O JavaScript ainda nãoera, nesta altura, utilizado para processar dados. Tambémnesta 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¸cãode dados ou outros pedidos determinados por açcõesdo utilizador. As páginastornaram-se aplica¸cões, web applications. Uma defini¸cãotradicional de web application é: um conjunto de páginas web logicamente agrupadas e geridas por uma únicaentidade, que têmcomo pontos de entrada formuláriosde inser¸cão de dados (web forms). Uma web application nãoé mais do que uma aplica¸cãoque éacedida atravésde um browser. Têmgeralmente uma arquitectura lógicaem três(interface, lógicade negócioe camada de dados) camadas e estãoarmazenadas num servidor. Hádois tipos de web applications:

• Orientadas àapresenta¸cão: São web applications que geram páginas web interactivas constitu´ıdas por vários tipos de linguagens de anota¸cão(por exemplo: HTML, eXtensible Markup Language (XML)) e que apresentam conteúdo dinâmicocomo resposta a pedidos efectuados pelo utilizador.

• Orientadas aos servi¸cos: Uma web application orientada aos servi¸cosimple- menta o ponto de acesso para um ou mais de um web service. S˜aogeralmente clientes de service oriented web applications.

Uma vantagem significativa de implementar uma web application de forma a suportar as funcionalidades padrãodos browsers éque estas terãoo mesmo comportamento independentemente da plataforma e do browser a partir do qual serão acedidas. No entanto, diferentes implementa¸cõesde browsers, devido a diferentes interpreta¸cõesdos padrõesdefinidos, tornam por vezes esta tarefa um pouco mais complicada, existindo inclusivamente na web guiõesde compatibilidade para os diferentes browsers como [Smi07].

2.2.3 Web 2.0 e Ajax

O termo web 2.0 descreve uma tendênciade utiliza¸cãoe de design observada na World Wide Web (WWW) com o objectivo de melhorar a criatividade, partilha de informa¸cãoe principalmente: a colabora¸cãoentre utilizadores. Estes conceitos levaram ao desenvolvimento e evolu¸cão de comunidades online tais como redes so- ciais, wikis e blogues.

11 Enquadramento do Projecto

O termo tornou-se mais conhecido apósa primeira conferênciaO’Reilly Media Web 2.0 em 2004, e apesar de sugerir uma nova versãoda WWW nãose refere a qualquer evolu¸cãotecnoló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ústriado software, causada pela adop¸cãoda 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 descrito como uma tecnologia, foi originalmente criado para permitir o desenvolvimento de web applications que se assemelhassem ainda mais a aplica¸cõesde desktop. Este conceito foi melhor descrito por [Gar05] como um conjunto de váriastecnologias que podem ser utilizadas para melhorar a experiênciado utilizador de uma dada web application, introduzindo a capacidade ass´ıncronade envio de pedidos ou da recep¸cãoass´ıncronade respostas. As tecnologias mais frequentemente envolvidas são:

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

• interaçcãodinâmica atravésdo DOM;

• troca e manipula¸c˜aode dados utilizando XMLe eXtensible Stylesheet Lan- guage Transformation (XSLT) ou JavaScript Object Notation (JSON);

• pedidos ass´ıncronosutilizando XMLHttpRequest [vK08];

• JavaScript, utilizado para integrar todas estas tecnologias.

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

1. Do lado do cliente existe um motor que serve de intermedi´arioentre a interface da aplica¸c˜aoe o servidor.

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

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

12 Enquadramento do Projecto

Isto significa que as páginasque utilizam Ajax contêmum motor do lado do cliente, composto por um conjunto de fun¸cõesJavaScript, responsável pela comunica¸cãocom o servidor e por actualizar a interface com o resultado dessa mesma comunica¸cão. Na Figura 2.3 ilustra-se a natureza ass´ıncronado Ajax quando comparada com as web applications tradicionais. Como se pode observar, adicionando um mecanismo Ajax a uma web application eliminam-se diversos tempos de espera associados a comunica¸cõescom o servidor uma vez que a interface nãofica “bloqueada” àes- pera da resposta. Obtém-seassim aplica¸cõescom um comportamento mais fluido, eliminando tempos de espera entre cada “clique” e melhorando a experiênciado utilizador.

2.3 Oﬄine Web Applications

A informa¸cãográfica(bem como folhas de estilo e scripts), tais como as imagens que constituem o visual de uma web application, éjátratada de forma especial pelos cada vez mais avan¸cadossistemas de cache (armazenamento temporário)dos browsers. Mas estes nãosãoainda capazes de guardar conteúdocriado pelo utilizador, nem de apresentar informa¸cãoindependentemente do estado da liga¸cão. Numa altura onde se fala de servi¸cosde Internet wireless municipalizados [Kha], comunica¸cões3G e liga¸cõesde banda larga a alta velocidade, a liga¸cãoàrede global continua a nãoestar permanentemente dispon´ıvel para os utilizadores. Na WWW encontra-se uma importante parte da informa¸cãoe das aplica¸cõesutilizadas para criar e editar conteúdos. Por vezes, informa¸cãovital 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´ısdiferente do habitual, onde nãosubscreve 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ãoa locais onde nunca esteve antes, e per- mitirátambémmelhorar o desempenho das web applications, colocando informa¸cão mais perto dos utilizadores, reduzindo a transferênciade dados apenas ao essencial.

2.4 Compara¸c˜ao

Nas evolu¸cõesdescritas neste cap´ıtulo2 pode-se observar que existe um paralelismo entre a evolu¸cãodas 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áginasestáticas,no sentido em que o browser nãotoma parte em qualquer

13 Enquadramento do Projecto processamento, e serve apenas como uma plataforma de interaçcãocom o servidor; tal como os clientes descritos na seçcão 2.1.1. A sua próximaevolu¸cão,os fat-clients, trouxeram parte da capacidade de processamento para o lado do cliente. Na web, foi tambémesta a inova¸cãotecnológica a que se assistiu, com a evolu¸cãodas tecnologias que permitiram a cria¸cãode verdadeiras aplica¸cões,e com a introdu¸cãodo Javascript no browser, dando ao cliente a capacidade de processamento de dados. A necessidade da separa¸cãodo código em camadas lógicasadvémda crescente complexidade das web applications. Esta práticapermite, entre outras coisas, melhorar o processo de desenvolvimento e a capacidade de manuten¸cãode uma aplica¸cão. Os fat-clients têmtambéma capacidade de armazenamento de dados, o que permite a persistênciade informa¸cõesentre duas sessõese que algumas opera¸cões sejam executadas sem a necessidade de comunica¸cãocom o servidor. Este facto pode tambémser uma realidade nas web applications com a adop¸cãodas tecnologias OWA. Neste momento assiste-se a uma utiliza¸cãocada vez maior da web como uma plataforma de desenvolvimento. A capacidade de coopera¸cãona edi¸cãode conteúdos, e a mobilidade proporcionada por esta plataforma sãoos principais factores que alimentam esta mudan¸ca,e pela primeira vez, as aplica¸cõestradicionais têmcom- peti¸cãovinda 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¸carampublicamente 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ão offline significa aproximar a web e o desktop reunindo “o melhor de dois mundos”. As vantagens da mobilidade poss´ıvel atravésda web a coopera¸cãona cria¸cãoe edi¸cãode conteúdose a possibilidade de utilizar aplica¸cõessempre actualizadas e sem necessidade de instala¸cãosãoalgumas das principais vantagens que promovem esta mudan¸ca, que devido àspreocupa¸cõesassociadas àusabilidade e experiênciado utilizador, estáfortemente associada ao desenvolvimento de Rich Internet Applica- tion (RIA)s.

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

14 Enquadramento do Projecto

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

15 Enquadramento do Projecto

16 Cap´ıtulo3

Estado da arte

Apesar de o conceito das OWAs nãoser absolutamente novo, as tecnologias que o suportam sãorecentes. Neste cap´ıtulodescrevem-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 funcionalidades offline e o processo da escolha da tecnologia a utilizar neste projecto.

3.1 Gears

O Gears1 éuma extensãoàsfuncionalidades do browser introduzido pelo Google que tem como principal objectivo tornar poss´ıvel a visualiza¸cãode páginasde Inter- net mesmo sem uma conexãodispon´ıvel. Encontra-se dispon´ıvel para as plataformas 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 ´econstitu´ıdapor trˆescomponentes principais:

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

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

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

1Google Inc. – Mais informa¸c˜aoem http://gears.google.com/

17 Estado da arte

LocalServer

O módulo LocalServer éuma cache de Uniform Resource Locators (URLs) controlada pela web application. Quando nãoexiste 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´ıgidodo 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ãopoderácriar e utilizar diversos ResourceStores simultaneamente para capturar ficheiros de dados que necessitam de ser endere¸cadospor um URL, tal como um ficheiro PDF ou uma imagem.

• ManagedResourceStore – serve para capturar um conjunto de URLs que estão relacionados, e que sãodeclarado num ficheiro de manifesto (especificado em JSON) e que sãoautomaticamente actualizados. O ManagedResourceStore permite que o conjunto de recursos necessáriospara correr uma web application seja capturado e mantido actualizado automaticamente.

A principal diferen¸caentre estes dois tipos de armazenamento de URLs éa forma como sãoactualizados os seus conteúdos.Os conteúdosde um ManagedResourceStore sãoactualizados sempre que a versãocontida no ficheiro de manifesto for alterada, enquanto que os conteúdosde um ResourceStore nunca sãoactualizados automaticamente, 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únamas seguintes condi¸cõ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´aconter um cookie que lhe corresponda.

O LocalServer nãonecessita de monitorizar o estado da liga¸cãopara atender aos pedidos. Na verdade, sempre que as condi¸cõespreviamente enunciadas se verificarem o LocalServer interceptaráos pedidos e, independentemente do estado da liga¸cão àInternet, servi-los-áa partir do disco r´ıgidolocal. Caberáàaplica¸cãodefinir 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ãoguardados de forma relacional no disco r´ıgidodo uti- lizador2 de acordo com o modelo de seguran¸caestabelecido pelo Gears3, significando que uma aplica¸cãonãopode aceder a conteúdosfora do seu dom´ınio.

WorkerPool

Nos web browsers uma opera¸cãopesada de computa¸cãopode tornar a interface lenta e tornar menos agradável a experiênciado utilizador. O módulo WorkerPool permite correr opera¸cõesem background sem bloquear a interface com o utilizador. Os scripts executados numa WorkerPool nãoactivam 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ãopartilham qualquer estado de execu¸cão,o que significa que uma altera¸cãoa uma variável num Worker nãoafecta em nada a execu¸cãode outro Worker. Além disso, os Workers nãoherdam automaticamente nenhum códigodos seus pais. Cada Worker émembro de um WorkerPool, e os Workers podem interagir entre si enviando mensagens em formato de texto ou JSON. No entanto há tambémalgumas limita¸cões:os Workers nãotem acesso ao DOM, e objectos como window ou document nãose encontram acess´ıveis. Isto éconsequênciade os Workers nãopartilharem o estado de execu¸cão.Mas têmacesso a todas as fun¸cões built-in do Javascript. A maioria das funcionalidades do Gears pode também ser acedida atravésde uma variável global especial definida como google.gears.factory. Para outras funcionalidades espec´ıficasos Workers podem “pedir” àpáginaprincipal para continuar a execu¸cãoatravésdo envio de mensagens.

Outras funcionalidades

• HttpRequest – Este móduloimplementa a especifica¸cãoW3C XmlHttpRe- quest, definida em [vK08], tornando-a dispon´ıvel para os workers e para a páginaprincipal.

• Timer – Este móduloimplementa a especifica¸cãode timers tal como descrito por [Hic08], e torna-os dispon´ıveis para os workers e para a páginaprincipal

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

19 Estado da arte

• Factory – Esta classe éutilizada para instanciar todos os outros objectos da API do Gears atravésdo 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átambémdispon´ı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ãoas latênciasna transferênciade dados em redes móveis tornam as aplica¸cõespouco 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ãotiver sido implementado com suporte para o Gears, entãotambémestarápreparada para ser executada num dispositivo móvel, mas as limita¸cõesdos browsers dispon´ıveis para dispositivos móveis têmque ser consideradas. Isto significa prever as condi¸cões que permitam uma boa usabilidade devido aos pequenos ecrãsdestes dispositivos, bem como o seu suporte limitado dos padrõesdo DOM, CSS e JavaScript.

3.2 Adobe AIR

O Adobe AIR4 éum runtime compat´ıvel com diversos browsers e sistemas operativos, que pretende dar aos programadores a possibilidade de combinar diversas tecnologias de produ¸cãode conteúdospara a Internet no desenvolvimento de Rich Inter- net Application (RIA)s. O Adobe AIR mantémuma rela¸cãocom o browser, mas es- tende as suas capacidades e tecnologias, permitindo o desenvolvimento de aplica¸cões tambémpara o ambiente de trabalho, com janelas em tudo semelhantes àsdo sistema operativo. Segundo a Adobe, o objectivo écomplementar o browser dando aos utilizadores (mas essencialmente aos programadores e equipas de desenvolvimento) a escolha sobre como distribuir as suas aplica¸cões.Para este efeito o Adobe AIR tem uma aproxima¸cãodiferente do Gears. Em vez de “estender” o browser acrescentando-lhe funcionalidades, o AIR permite tambémo desenvolvimento de

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

20 Estado da arte aplica¸cõesque se destinam a ser executadas fora do ambiente do browser, mas utilizando as tecnologias comuns da Internet (por exemplo: HTML, CSS, JavaScript, Flash, Flex)[CDGH08]. A utiliza¸cãodesta tecnologia permite utilizar o browser ou o próprio runtime Adobe AIR, como plataforma de execu¸cãoda aplica¸cão. Na Tabela 3.1 faz-se uma compara¸cãodas 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õesAdobe AIR na plataforma desktop têmum carácter persistente (sãoinstaladas no computador do utilizador), o Adobe AIR tem um modelo de seguran¸caque se assemelha com o das tradicionais aplica¸cões desktop [Ada08]. Este modelo éanalisado nas seçcões 3.2.1e 3.2.2. O ambiente em que éexecutado o browser érestringido àexecu¸cãode web applications que podem ser de váriasorigens (incluindo de origens anónimasou sem confian¸ca). O Adobe AIR proporciona acesso a capacidades como acesso a ficheiros, que necessitam da confian¸cado utilizador.

• HTML – O desenvolvimento de aplica¸c˜oespara 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ãoda linguagem Flash. Permite a renderiza¸cãode gráficosvectoriais e áudio/v´ıdeocom suporte nativo. Utiliza ActionScript para adicionar maior interactividade com o utilizador;

• Flex – O Flex éuma framework open source para o desenvolvimento de RIAs usando Flash. As aplica¸cõesFlex sãona realidade Flash, sendo a principal diferen¸cao ambiente de desenvolvimento.

Como resultado, uma aplica¸c˜aoAIR poder´aser implementada:

• Baseada em Flash ou Flex (aplica¸cõescujo conteúdobase éem ShockWave Flash (SWF));

• Baseada em Flash ou Flex, tambémcom HTML ou Portable Document Format (PDF). Aplica¸cõescujo conteúdode base éem Flash/Flex(SWF) com HTML (HTML, JavaScript, CSS) ou conteúdo PDF inclu´ıdo;

• Baseada em HTML. Aplica¸cõescujo conteúdobase éem HTML, Javascript, CSS;

• Baseada em HTML utilizando tamb´em Flash/Flex ou PDF.

21 Estado da arte

Os utilizadores interagem com uma aplica¸cãoAIR da mesma forma que interagem com outras aplica¸cõescom janelas nativas do seu sistema operativo. O runtime é instalado uma vez no computador do utilizador, e a partir desse momento, todas as aplica¸cõesAIR terãoo mesmo aspecto que qualquer outra aplica¸cãopara o desktop.

3.2.1 Seguran¸ca

Permitir que uma web application aceda 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õesestejam digitalmente assinadas. As assinaturas digitais de códigosãoum processo que visa garantir a integridade da aplica¸cãoe a identidade do seu autor, no momento da instala¸cão. As equipas de desenvolvimento podem “assinar” uma aplica¸cãoutilizando um certificado atribu´ıdo por uma Entidade Certificadora (Certification Authority) ou atravésde um certificado 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ãoquando o códigotiver 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émassinar as aplica¸cõescom um certificado auto-atribu´ıdo(um certificado criado por elas próprias),mas neste caso o instalador apresentaráestas aplica¸cõescomo sendo de uma origem nãoverificada. O AIR utiliza a infraestrutura públicade 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ãoAIR 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ógicode certificados confiados, e que se ligue desta forma ao certificado utilizado para assinar a aplica¸cão. Todas as aplica¸cõesAIR têmcaracter´ısticasem comum, independentemente da tecnologia utilizada para o seu desenvolvimento (HTML/Flex/Flash). No âmbito de uma aplica¸cãoAIR existem um conjunto de APIs que estãodispon´ıveis e que tornam poss´ıvel o acesso ao sistema local (leitura e escrita) e a recursos de rede que

22 Estado da arte de outra forma nunca estariam acess´ıveis a partir de uma web application comum. Cada aplica¸cãoAIR possui tambémdiferentes n´ıveis de isolamento, chamados security sandboxes, dependendo do tipo de conteúdoque estáa ser carregado e do seu objectivo:

• Isolamento ao n´ıvel da aplica¸cão5 – E´ a raiz de cada aplica¸cãoAIR. 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âmicade conteúdosremotos égeralmente proibido e as técnicase mecanismos de gera¸cãodinâmicade códigosãofortemente restringidas. Apenas conteúdocarregado directamente da directoria base da aplica¸cãopoderáser colocado neste n´ıvel de isolamento.

• Isolamento nãoespec´ıficoda aplica¸cão6 – contémtodo o outro conteúdo que nãotenha sido carregado directamente para o isolamento da aplica¸cão. Isto inclui conteúdolocal e remoto. Este tipo de conteúdonãotem acesso directo àsAPIs 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´ınioremoto 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 únicaimple- menta¸cãocompleta 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é-definidostais como window, box, page, textbox, radio button, entre outros . Infelizmente o XUL nãopossui qualquer especifica¸cãoformal ou implementa¸cõesde inter-operabilidade para outros motores que nãoo Gecko. No entanto a sua implementa¸cãoélicenciada em códigoaberto, pelas licen¸cas GNU Gen- eral Public License (GPL), GNU Lesser General Public License (LGPL)e Mozilla Public License (MPL). Enunciam-se algumas caracter´ısticas desta linguagem:

5NT.: application sandbox 6NT.: non-application sandbox

23 Estado da arte

Liguagem de anota¸cãopoderosa baseada em componentes (widgets): O objectivo do XUL épermitir a constru¸cãode aplica¸cõesmulti-plataforma, em claro contraste com o Dynamic HyperText Transfer Protocol (DHTML) que se destina ao desenvolvimento de páginas web. Por esta razãoo XUL estáorien- tado a componentes tais como janelas, botões,e etiquetas, em vez de páginas, cabe¸calhosde texto, e liga¸cõesde hipertexto. Investir tempo e esfor¸copara atingir este mesmo resultado em aplica¸cõesbaseadas em DHTML, compromete frequentemente a complexidade e desempenho da aplica¸cão.

Baseado em padrões O XUL éum dialecto XML baseado no padrãoW3C XML 1.0. As aplica¸cõesescritas em XUL sãotambémbaseadas 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ãodos componentes gráficos de interface que disponibiliza, implementa a premissa “um códigopara todas as plataformas”. A interface gráficade todos os produtos centrais Mozilla (browser, instant messenger, livro de endere¸cos),éescrita em XUL, com um únicocódigobase que suporta todas as plataformas Mozilla.

Separa¸cãoentre o n´ıvel de apresenta¸cãoe a lógicade negócio: Uma das maiores preocupa¸cõesno desenvolvimento para a Internet éa forte liga¸cão entre estas duas camadas (interface e lógica). Isto constitui um problema significativo no desenvolvimento de grandes aplica¸cões,especialmente quando o desenvolvimento éfeito em ambientes de equipa, porque as capacidades de desenvolvimento destas duas partes da aplica¸cãoestãomuitas vezes espalhadas por diferentes elementos. O XUL permite uma clara distin¸cãoentre a defini¸cão da aplica¸cãocliente e da lógicade 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áficoe apresenta¸cãode uma aplica¸cão XUL pode ser alterado de forma independente da sua lógica ou implementa¸cão,e a aplica¸cãopode ainda ser traduzida (interna- tionalization) de forma independente da sua lógica,implementa¸cãoou apresenta¸cão.Este grau de separa¸cãoresulta em aplica¸cõesque sãomais fáceisde manter pelos programadores e facilmente adaptadas por designers e tradutores.

24 Estado da arte

Fáciladapta¸cão Outro benef´ıcio que advémdo n´ıvel de separa¸cãoentre lógica de negócioe apresenta¸cãooferecido pelo XUL éa facilidade com que se pode adaptar uma aplica¸cãopara diferentes clientes ou grupos de utilizadores. Um programador pode utilizar a mesma aplica¸cãobase e adaptá-laconsoante as necessidades, atravésde diferentes temas (skins) e ficheiros de l´ınguas. Desta forma, uma aplica¸cãoescrita e desenvolvida em Inglêspode ser rapidamente traduzida para Portuguêse distribu´ıdacom 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áficaha- bitual de um browser. Baseia-se num conceito designado por Site Specific Browser (SSB). Um SSB éuma aplica¸cãocom um browser embebido, desenhado para executar apenas uma web application. Nãopossui os menus e barras de ferramentas habituais. Um SSB tem uma integra¸cãocom o sistema operativo e com o desktop muito mais estreita do que uma web application acedida atravésde um browser, uma vez que éexecutado em janela própria. O Prism resulta de uma experiênciada Mozilla e visa reduzir as diferen¸casentre as desktop applications tradicionais e as web applications. Um dos aspectos focados é a experiênciado utilizador. Numa apresenta¸cãooficial édito que “[o Prism] pretende ser uma ponte entre as diferen¸casque existem entre as aplica¸cõestradicionais 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ãoHTML 5 [Hic08], que se encontra em fase de desenvolvimento pelo grupo WHATWG, pretende ser uma norma de substitui¸cãodos padrõesHTML 4, XHTML 1.x e do DOM2 HTML. Uma das propriedades que o distingue das tecnologias que pretende substituir éprecisamente o suporte para OWA e armazenamento de dados no cliente de uma forma relacional. Nãosendo propriamente uma tecnologia –mas antes uma especifica¸cão–éaqui mencionada por ter servido como referênciaa diversas implementa¸cõesde funcionalidades offline, e por se considerar que venha a ter um impacto significativo nas implementa¸cõesde diversos browsers. Dion Almaer defendeu no seu blogue que o Gears era uma implementa¸cãodo 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 caracter´ısticas

25 Estado da arte semelhantes e nãoencontrar motivo de “competi¸cão”entre as duas, mas que enquanto o HTML 5 éuma especifica¸cãoo Gears éuma implementa¸cão. No entanto, tambéméverdade que o HTML 5 cobre muitos outros pontos para alémdas OWA que saem completamente fora do âmbito do Gears. Se esta especifica¸cãoatingir um estado de maturidade que possibilite a sua adop¸cãopelos principais browsers, tornando nativo do browser o suporte OWA, entãodeixaráde fazer sentido a existênciade uma extensãocomo o Gears. A especifica¸cã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¸cõesmesmo quando o utilizador nãopossui uma liga¸cãoàInternet.

Estas caracter´ısticassãoas bases da tecnologia das OWA e têmcorrespondência com os pontos analisados nas seçcões 3.1.1e 3.1.1

3.5 Web applications que usam funcionalidades oﬄine

Nesta seçcãoapresentam-se algumas web applications que actualmente disponibilizam funcionalidades offline. Estas aplica¸cõesforam escolhidas para uma análise mais pormenorizada por utilizarem o Gears, que tal como descrito na seçcão4, 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¸cãode vários sites simultaneamente que disponibilizem conteúdosneste formato e foi a primeira web application da Google com uma versão offline publicamente acess´ıvel (desde Junho de 2007). O Google Reader implementa o modo “utilizador decide”, oferecendo na sua interface um botãoque permite alternar entre os modos online e offline. O Google Docs8 éuma web application que permite a cria¸cãoe edi¸cãode documentos de texto, folhas de cálculoe apresenta¸cões. Era jápúblicodesde Janeiro de 2008 que o Google estava a desenvolver uma versão OWA desta aplica¸cão, mas o acesso a uma versãoexperimental sófoi poss´ıvel a partir de 31 de Maio de 2008.

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

26 Estado da arte

A implementa¸cãodas funcionalidades offline nestas duas aplica¸cõesseguiu diferentes aproxima¸cões, principalmente porque o Google Reader apresenta ao utilizador informa¸cõesque sãofornecidas por fontes externas, enquanto que no Google Docs, a informa¸cãoécriada e editada pelo utilizador sobre a forma de documentos. A diferente origem da informa¸cãoimplica que no Google Reader seja necessário prever casos de excep¸cão,tal como existirem demasiados itens que necessitam de ser transferidos para o cliente. Nãoobservar este ponto causa um problema grave de usabilidade, e para evitar tempos de espera demasiado longos e uma interface com pouca capacidade de resposta àsaçcõesdo utilizador o Google Reader apenas transfere para o cliente os dois mil itens mais recentes na transi¸cãopara 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ãode tempo e de tarefas e foi uma das primeiras aplica¸cõesindependentes do Google a adoptar o Gears para acessos em modo offline. Permite que os seus utilizadores fa¸camuma gestão de tarefas agrupando-as em listas, adicionando-lhes campos de informa¸cãoadicional ou dando-lhes informa¸cãogeográfica(recorrendo ao servi¸coGoogle 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¸cão Really Simple Syndication (RSS) e partilha de categorias de tarefas de acordo com diferentes n´ıveis de permissõesde 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ãodo seu cliente de e-mail que utiliza o Gears para acelerar o seu desempenho. Numa fase inicial estarádispon´ıvel apenas para utilizadores que tenham cinco mil ou mais mensagens na sua caixa de correio, e permitiráefectuar pesquisas muito mais rápidoque a sua versão online. O servi¸code blogs Wordpress.com anunciou tambémo in´ıcioda utiliza¸cãodesta tecnologia com o fim de melhorar o desempenho. A versãoque utiliza esta tecnologia descarrega e armazena no cliente um conjunto de imagens e scripts que passam a ter preferênciasobre os seus congéneres online, e que permitem acelerar o processo de carregamento da aplica¸cãoe visualiza¸cãode blogs.

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

27 Estado da arte

O MySpace e o Wordpress.com sãodois exemplos da utiliza¸cãoda tecnologia OWA para optimiza¸cãode web application jáexistentes. Sem pretenderem disponibilizar uma versãoque seja totalmente offline fazem uso do Gears para armazenar no cliente parte dos recursos frequentemente acedidos na visualiza¸cãodas suas páginas.

3.6 Escolha da tecnologia

Apósa análisedas tecnologias apresentada nas seçcões 3.1a 3.4, foi necessárioes- tudar a adequa¸cãode cada uma delas ao projecto em questão.Desde logo époss´ıvel observar que nem todas se dedicam apenas a OWA. Por exemplo, o Adobe AIR, apesar de ter suporte para OWA apenas disponibiliza algumas das funcionalidades identificadas como mais indicadas para a execu¸cãodo projecto quando utilizado na sua vertente desktop, tal como exposto na Tabela 3.1, mas a utiliza¸cãodesta vertente implicaria o desenvolvimento de novas interfaces e de novas formas de comunica¸cã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¸cão do códigojáexistente (exigindo naturalmente a sua adapta¸cãoe a implementa¸cão das funcionalidades pretendidas). A tecnologia escolhida para a realiza¸cãodeste trabalho foi o Gears, sendo que um dos principais factores a influenciar esta op¸cãofoi a liberdade introduzida pela sua licen¸ca Berkeley Software Distribution (BSD)11. Considerou-se o funcionamento desta ferramenta extremamente adequando à aplica¸cãono WOW!, uma vez que o seu principal objectivo éprecisamente tornar poss´ıvel a execu¸cão offline de uma página web e por virtude deste facto o Gears tem uma API concisa e de simples aplica¸cãoprática,uma vez que nãopossui quaisquer outros elementos distractores. O funcionamento do seu ManagedResourceStore exemplificado na Figura 3.1, com a capacidade de actualiza¸cãode recursos definidos num ficheiro manifesto especificado em JSON pesou tambémnesta decisão.

11Sobre a licen¸caBSD consultar: http://www.opensource.org/licenses/bsd-license.php e http: //www.linfo.org/bsdlicense.html

28 Estado da arte

Figura 3.1: Esquema UML do processo efectuado pelos recursos do Gears do tipo ManagedResourceStore para a actualiza¸cãodos conteúdosdefinidos no ficheiro manifesto.

29 Estado da arte

Funcionalidade RIAs no browser RIAs no desktop Disponibilidade As aplica¸cõespodem ser facil- As aplica¸cõesquando instal- da aplica¸cão mente exploradas e utilizadas adas têmmaior grau de funcionalidades e persistência Instala¸cão Nãoénecessárioqualquer tipo As aplica¸cões são instaladas de instala¸cão. atravésdo browser, ou descar- regadas e instaladas como uma aplica¸cãotradicional. Actualiza¸cões Aplica¸cões são actualizadas O AIR disponibiliza uma API carregando conteúdos para que permite que as aplica¸cões um website. sejam actualizadas de uma forma Sistemas opera- As aplica¸cõespodem ser exe- As aplica¸cões são multi- tivos suportados cutadas em diversos sistemas plataforma e podem ser operativos e browsers. instaladas e executadas em diversos sistemas operativos e browsers. Linguagens de Javascript é disponibilizado Máquinas virtuais de programa¸cão pelo browser e ActionScript Javascript e ActionScript édisponibilizado pelo Adobe compat´ıveis com o browser. Flash Player. Capacidade de As RIAs podem ser execu- As aplica¸cõespodem ser ex- execu¸cão em tadas numa janela do browser. ecutadas em background e background disponibilizar notifica¸cõestal como uma aplica¸cão tradi- cional. Persistência A actividade estálimitada à As aplica¸cõessãoinstaladas e sessãodo browser. Quando o estãodispon´ıveis no desktop. browser éencerrado, toda a Podem armazenar informa¸cão informa¸cãoédescartada. localmente e estãodispon´ıveis offline. Integra¸cãocom o Integra¸cãocom o desktop lim- As aplica¸cões podem aceder desktop itada devido a restri¸cõesim- ao sistema de ficheiro, ao clip- postas pelo browser. board, eventos, notifica¸cões, etc. Controlo da inter- As aplica¸cões são acedidas As aplica¸cões têm um vi- face com o uti- através de uma janela do sual gráficopróprio, em janela lizador browser, que tem os seus própria. próprios controlos e visual gráfico. Armazenamento As aplica¸cõestêmarmazena- As aplica¸cõestêmacesso àto- de dados mento limitado, que pode ser talidade do espa¸codispon´ıvel reescrito pelo browser. localmente, e a uma base de dados com a possibilidade de encripta¸cão.

Tabela 3.1: Compara¸c˜aodas funcionalidades oferecidas pelo Adobe AIR para as plataformas web e desktop

30 Estado da arte

Aplica¸cão Modo de execu¸cãoutilizado Google Reader Utiliza o modo “utilizador decide”, disponibilizando ao utilizador um botãopara alternar entre os modos online e offline. Como lida com informa¸cãorecol- hida de fontes externas, de natureza frequentemente efémera,o processo de sincroniza¸cãoapenas transfere os dois mil itens mais recentes quando passa ao estado offline. Neste modo sãoainda guardadas informa¸cõesde itens lidos e etiquetas atribu´ıdas que sãosincronizadas com o servidor quando o utilizador voltar a activar estado online. Google Docs Utiliza o modo “aplica¸cãodecide”, permitindo que o utilizador edite os conteúdosde documentos de texto, folhas de cálculoe de apresenta¸cõesindependente- mente do estado da liga¸cão,desde o momento em que as funcionalidades offline sãoactivadas. A aplica¸cão faz pequenas sincroniza¸cõescom o servidor sempre que necessário. Remember the Milk Utiliza um modo h´ıbrido entre “aplica¸cãodecide” e “utilizador decide”. A aplica¸cãoencarrega-se da sincroniza¸cãode dados, mas disponibiliza um controlo na sua interface que permite despoletar manualmente este processo, para situa¸cõesem que o utilizador fez altera¸cõesrecentes e pretende usufruir das capacidades offline imediatamente. MySpace O MySpace anunciou a utiliza¸cãode mecanismos de armazenamento de dados no cliente com recurso a tecnologias OWA, para melhorar o desempenho do seu cliente web de correio electrónico,nomeadamente no que diz respeito a opera¸cõesde pesquisa e or- dena¸cão.Inicialmente esta funcionalidade estaráape- nas dispon´ıvel para utilizadores com cinco mil ou mais mensagens na sua caixa de correio, mas nãoéainda claro se serádisponibilizada uma versãototalmente offline.

Tabela 3.2: Resumo da utiliza¸c˜aode tecnologias OWA em algumas web applications consideradas na an´alise do estado da arte.

31 Estado da arte

32 Cap´ıtulo4

Desenvolvimento

Neste cap´ıtulointroduz-se a aplica¸cão WOW! e apresenta-se o estudo que foi feito da adequa¸cãode cada tecnologia para a implementa¸cãoda funcionalidade offline nesta plataforma. Fazem-se diversas considera¸cõessobre op¸cõesa tomar na concep¸cãode OWAs e problemas comuns na sua implementa¸cão,bem como sug- estõespara os resolver. O WOW! éuma aplica¸cãojáexistente, de gestãode ordens de trabalho e do fluxo de tarefas numa empresa ou organiza¸cão.

4.1 Como ﬁcar oﬄine

Na maior parte das web applications de hoje nãoexiste uma camada de dados real. A aplica¸cãoexemplificada na Figura 4.1, ao longo da sua execu¸cão, acede directamente àsua únicafonte de dados (o servidor) através de chamadas Ajax sem que exista uma separa¸cãoclara destas duas camadas. Para que uma web application seja capaz de ser executada sem uma liga¸cão activa àInternet e mantenha o seu caracter dinâmico, torna-se necessárioincluir

Figura 4.1: Exemplo de uma arquitectura de uma web application sem uma camada de abstrac¸c˜aode dados. Figura adaptada de http: // gears. google. com/

33 Desenvolvimento

Figura 4.2: Exemplo de uma arquitectura de uma web application com uma camada de abstrac¸c˜aode dados. Figura adaptada de http: // gears. google. com/ um mecanismo de armazenamento de dados local, seja uma base de dados ou a capacidade de acesso ao disco. No entanto, este mecanismo introduz dois problemas:

1. Qual das fontes de dados utilizar quando um utilizador faz um pedido de informa¸c˜ao?

2. A necessidade de implementar uma camada de acesso a dados que seja coerente quer se use o servidor remoto ou local.

Por exemplo, em vez de a aplica¸cãoAjax fazer um pedido relativo àscontas de todos os utilizadores em formato JSON directamente ao servidor remoto, poderáao invésfazer o pedido a um objecto intermédioda camada de dados. Este objecto, demonstrado na Figura 4.2, seráresponsável por implementar uma interface de acesso àbase de dados e retornar um objecto JavaScript com uma representa¸cãoda resposta do servidor. Mas a existênciade uma segunda fonte de dados torna recomendável também a implementa¸cãode uma camada de data switching, que em fun¸cãoda existência de conexãoàInternet e da necessidade de actualiza¸cãodos dados, decide se faz o pedido ao servidor remoto ou se fornece os dados presentes localmente. Este objecto, apresentado na Figura 4.3, decidiráde forma transparente para o utilizador se lêou escreve os dados localmente ou se os envia/pede ao servidor remoto, e pode também iniciar o processo de convergênciade dados e de resolu¸cãode conflitos.

4.1.1 Funcionalidades dispon´ıveis em modo oﬄine

Por razõespráticas,éprovável que nem todas as funcionalidades da aplica¸cão possam ser disponibilizadas em modo offline. E´ necessárioescolher quais as funcionalidades a disponibilizar no modo offline da aplica¸cãoe implementar a lógica que decide quando utilizar a base de dados local ou o servidor remoto. Apesar do acesso àbase de dados local ser muito mais rápidodo que aceder ao servidor, o acesso local nem sempre épreferido. Háváriasrazõesque podem tornar necessário escolher o acesso ao servidor em vez do acesso local.

34 Desenvolvimento

Figura 4.3: Exemplo de uma arquitectura de uma web application com uma camada de abstrac¸c˜aode dados e um data switch. Figura adaptada de http: // gears. google. com/

1. A informa¸cãopode ter uma natureza efémerae nãofazer sentido guardá-la localmente. Exemplo: dados em tempo real da bolsa de valores de Lisboa.

2. Algumas aplica¸cõeslidam com informa¸cãoque sófaz sentido na presen¸cade uma liga¸cão.Exemplo: Instant Messaging

3. A aplica¸cãopoderáescolher apenas guardar a informa¸cãoacedida mais frequentemente. Exemplo: para o utilizador poder alterar a l´ıngua de apresenta¸cãoda aplica¸cão, os conteúdosterãoque ser guardados em todas as l´ınguasdisponibilizadas pela aplica¸cão. O custo de implementa¸cãode algumas funcionalidades pode nãocompensar o benef´ıcio.

4. A capacidade de processamento ou de armazenamento de dados pode inviabi- lizar algumas funcionalidades offline. Exemplo, se uma dada funcionalidade necessita de uma capacidade de armazenamento de dados para alémdo razoável de um computador pessoal para ser útil(visualizador de mapas).

4.2 Modos de execu¸c˜ao

Um aspecto que énecessárioestudar para qualquer web application que se deseje disponibilizar offline prende-se com trêsmodos de execu¸cãoque devem ser consid- erados:

1. Utilizador decide o modo de execu¸cão: A aplica¸cãotem modos distintos de execu¸cãopara os estados online e offline, geralmente indicados na interface com o utilizador. O utilizador éinformado do estado da liga¸cãoe participa na altera¸cãode estado de execu¸cãoda aplica¸cãointeragindo com a sua interface,

2. Aplica¸cãodecide o modo de execu¸cão: Pode ser implementado na própria aplica¸cãoum mecanismo de deteçcãodo estado da liga¸cão(por exemplo, através

35 Desenvolvimento

de chamadas Ajax periódicas),transitando de estado e sincronizando automaticamente. Desta forma o utilizador nãoprecisa de participar na altera¸cãode estado, a menos que exista um conflito de dados que requeira a sua aten¸cão.

3. Aplica¸cãoassume sempre o estado offline: Outra hipóteseseráimple- mentar uma web application que assume sempre estar na ausênciade uma liga¸cãoao servidor de dados. Esta aplica¸cãoresponde aos pedidos do utilizador efectuando pedidos de informa¸cão ao servidor, mas nãodependendo de uma resposta válidapara mostrar a informa¸cãoque játinha dispon´ıvel an- teriormente. A sincroniza¸cãode dados com o servidor étentada sempre que existam dados para submeter e uma açcãodo utilizador.

4.2.1 Modo “utilizador decide”

Neste modo de execu¸cão,quando a aplica¸cãoestá online comunica com o servidor remoto; quando está offline comunica com a base de dados local. A informa¸cãotem que ser sincronizada sempre que se muda de modo. A principal vantagem desta op¸cão éque éa mais simples de implementar mesmo para uma aplica¸cãojáexistente, e portanto uma forma expedita de disponibilizar uma OWA. No entanto tem também algumas desvantagens que devem ser consideradas:

1. O utilizador tem que se lembrar de fazer a altera¸cãode estado de execu¸cão. Caso contráriopoderáestar a trabalhar inadvertidamente numa versão offline com dados antigos, ou nãoter a informa¸cãonecessáriase perder subitamente a liga¸cão.

2. Se a liga¸cãofor intermitente, o utilizador teráou que escolher um dos modos de execu¸cão,ou estar constantemente a trocar.

3. Uma vez que a base de dados nãoestásempre actualizada, nãopoderáser utilizada para melhorar a rapidez de execu¸cãoda aplica¸cãoquando em modo online.

4.2.2 Modo aplica¸c˜aodecide

A deteçcãodo estado da liga¸cãopode ser implementada atravésde um pedido ass´ıncronoao servidor tal como ilustrado na Figura 4.4. O resultado deste pedido definiráo estado online (em caso de sucesso) ou offline (em caso de falha). A sincroniza¸cãode dados poderáser feita sempre que ocorra uma transi¸cãodo estado offline para o estado online. No entanto este método nãose revela eficiente

36 Desenvolvimento

Figura 4.4: Esquema gráficoilustrando uma OWA executando no browser utilizando um modo de execu¸cãodo tipo “aplica¸cãodecide”, com deteçcãoautomáticado estado da liga¸cãovia pedidos Ajax ass´ıncronosa cada cinco segundos. para grandes aplica¸cões,uma vez que requer a troca de mensagens demasiado frequentes com o servidor, que se destinam exclusivamente àmonitoriza¸cãodo estado da liga¸cão.

4.2.3 Modo “aplica¸c˜aoassume o estado oﬄine”

Uma aplica¸cãotransparente funciona assumindo sempre que estáem modo offline, ou pelo menos que pode perder a liga¸cãoa qualquer momento. Neste modo, tira-se o máximopartido do armazenamento local, e fazem-se pequenas mas cont´ınuas sincroniza¸cõescom o servidor sempre que este esteja dispon´ıvel. A sincroniza¸cãode dados tambéméfeita sempre que se volta ao estado online. As vantagens de uma web application transparente sãoas seguintes:

• Uma melhor experiênciapara o utilizador, uma vez que este não tem que se preocupar com o estado da liga¸cãoou com a transi¸cãode estados.

• A aplica¸c˜aofunciona de forma coerente, mesmo que a liga¸c˜aoseja intermitente.

• Uma vez que o armazenamento local ´emantido actualizado, pode ser utilizado para melhorar o desempenho da aplica¸c˜ao.

Foram identiﬁcadas as seguintes desvantagens:

• E´ mais dif´ıcilde implementar e a sincroniza¸c˜aoacarreta cuidados especiais.

• E´ necessárioum cuidado adicional para evitar que as opera¸cõesde sincroniza¸cão frequentes que ocorrem automaticamente nãoafectem os tempos de resposta da aplica¸cão.

• Os testes àaplica¸cãosãomais complexos uma vez que a sincroniza¸cãode dados nãoocorre em resposta a uma açcãodo utilizador.

37 Desenvolvimento

4.3 Sincroniza¸c˜aode dados

A sincroniza¸cãode dados consiste na capacidade de identificar e transferir pe- riodicamente a versãomais actual dos dados, entre o cliente e o(s) servidor(es). Independentemente do modo de execu¸cãoescolhido e mesmo do estado da liga¸cão do utilizador, a informa¸cãoarmazenada localmente e a informa¸cãoarmazenada no servidor estarãopor vezes dessincronizadas. Isto poderáacontecer sempre que, por exemplo:

• O utilizador faz altera¸c˜oesem modo oﬄine.

• A informa¸c˜ao´epartilhada e pode ser alterada por uma entidade externa.

• A informa¸c˜ao´efornecida por uma entidade externa.

Resolver estas diferen¸casde forma a que a informa¸cãolocal e remota encontrem a igualdade chama-se sincroniza¸cãode dados. Háváriasaproxima¸cõesposs´ıveis para este efeito que dependem da natureza da aplica¸cão,cada uma com vantagens e desvantagens. A capacidade de suportar a mobilidade dos utilizadores torna-se cada vez um ponto mais importante de uma web application. Para uma organiza¸cãode dimensão global, évital garantir que os seus colaboradores têmacesso àmesma informa¸cão que têmdispon´ıvel nos seus postos de trabalho mesmo quando estãofora. Na maior parte dos casos, estes colaboradores terãoacesso a um computador portátil,um desktop, Smartphone ou PDA, e atravésdestes poderãoter acesso àsua informa¸cão directamente atravésde liga¸cõesencriptadas Virtual Private Network (VPN), de um servidor web, ou de outro mecanismo de rede. Esta solu¸cãoésimples de implementar, mas infelizmente, para a maioria dos colaboradores com grande factor de mobilidade, nãoésatisfatória. As principais desvantagens sãoas seguintes:

• Requisitos de liga¸cão: Para permitir que os utilizadores acedam àsua informa¸cão,énecessáriogarantir a capacidade constante de comunica¸cão,pelo menos durante o tempo necessário que assegure a sua transferência.

• Velocidade de liga¸cão: sem persistênciade dados e em liga¸cõesde fraca qualidade, a usabilidade por vezes torna-se inaceitável.

• Ponto cr´ıticode falha: Com este tipo de solu¸c˜ao,todos os utilizadores dependem da base de dados que armazena informa¸c˜aovital para o funcionamento do cliente.

38 Desenvolvimento

• Scalability do servidor: A´ medida que novos utilizadores sãoadicionados ao sistema o desempenho do servidor éafectado, levando ànecessidade de maior capacidade de armazenamento e/ou processamento.

De acordo com a documenta¸cãoda Microsoft Sync Framework [Mic08], uma solu¸cãoalternativa consiste em implementar uma Occasionally Connected Appli- cation (OCA). Uma OCA permite a um utilizador remoto continuar a aceder à sua informa¸cãomesmo depois de perder a liga¸cão,mas em vez de recorrer a um servidor, recorre a informa¸cãoarmazenada no seu dispositivo local. Para preencher localmente a informa¸cãoque o utilizador necessita, uma OCA possui mecanismos de sincroniza¸cãode dados que sãooferecidos por esta framework.

4.3.1 Quando sincronizar?

Uma das solu¸cõesmais simples de implementar passa por disponibilizar um mecanismo manual que despoleta a sincroniza¸cão. Diz-se manual porque éo utilizador que escolhe quando sincronizar, e pode ser implementada simplesmente fazendo o upload de toda a informa¸cãopara o servidor e depois fazendo o download da cópiamais recente da informa¸cãoantes de voltar a ficar offline. Para que esta seja uma op¸cãoviável énecessárioque:

• O volume de dados seja suﬁcientemente pequeno para que possa ser transferido do servidor para o cliente num espa¸code tempo aceit´avel,

• Que o utilizador indique explicitamente que quer mudar para o estado oﬄine, ou online pressionando um bot˜aoda interface.

Contudo, podem ser identiﬁcados alguns problemas relacionados com esta abordagem:

• Os utilizadores nem sempre podem prever o estado das suas liga¸cões. A liga¸cão pode-se perder subitamente ou ter um carácterintermitente.

• O utilizador pode esquecer-se de efectuar a sincroniza¸c˜ao.

Outra op¸cãoseráconjugar a sincroniza¸cãode dados com o modo de execu¸cão transparente. A sincroniza¸cãoocorre automaticamente em background, de forma nãointrusiva para o utilizador. A aplica¸cãocomunica com o servidor regularmente efectuando pequenas trocas de dados, com o objectivo de manter o sincronismo da informa¸cãolocal e remota. Esta abordagem pode ser implementada com pedidos Ajax ass´ıncronos e regulares ao servidor, o que permite manter a interaçcãocom a interface flu´ıda,evitando bloqueios. Estes pedidos sãofeitos prevendo as situa¸cões

39 Desenvolvimento de disponibilidade ou indisponibilidade (timeout) do servidor. Uma outra op¸cão serápermitir que o servidor comunique essas altera¸cõesutilizando Comet1 tal como descrito em [Wil06] e [Rus06]. As vantagens destas aproxima¸cões são:

• A informa¸cãoestádispon´ıvel a qualquer altura que o utilizador decida ficar offline ou que a liga¸cãoseja acidentalmente perdida.

• O desempenho da aplica¸cãopode ser melhorado quando se estiver a utilizar uma liga¸cãoàInternet lenta, uma vez que o acesso a dados locais émais eficiente do que a consulta de dados ao servidor.

4.4 WOW!

O WOW! éuma plataforma integrada de gestãode ordens de trabalho, jáex- istente e desenvolvida pela Critical Software S.A., àqual se pretende adicionar a capacidade de execu¸cão offline. Esta aplica¸cãoéextremamente dinâmicae con- figurável, com um conjunto extremamente rico de funcionalidades, das quais se destacam:

• Gestãode Ordens de Trabalho – suportando a gestãodos pedidos desde a sua cria¸cãoatéao seu fecho, tomando em conta os diferentes tipos de pedidos (ordens de trabalho, pedidos de informa¸cão,melhorias, resolu¸cãode problemas, etc.), e diferentes tipos de açcõesposs´ıveis para cada um (Figura 4.5);

• Monitoriza¸cãode altera¸cões– Históricode mudan¸cas,anexos e estados, criando relatóriosde altera¸cãoautomaticamente (o quê,por quem e quando);

• Uso de Service Level Agreements (SLAs)– E´ poss´ıvel associar a um pedido um SLA que define qual o per´ıodo de tempo atribu´ıdoàresolu¸cãode um pedido, controlando e agilizando a resolu¸cãodo mesmo;

• Utiliza¸cãode queries de utilizador configuráveis que permitem acesso rápido a determinadas ordens de trabalho de acordo com o filtro configurado (por exemplo, “Para mim”, “Para o Grupo”, “Pelo Grupo”).

• Gest˜aodo relacionamento entre pedidos;

• Pesquisa e ﬁltragem de ordens de trabalho;

• Exporta¸c˜aode dados em formatos padr˜ao(PDF, DOC ou XLS);

• Integr´avel com solu¸c˜oesexternas.

40 Desenvolvimento

Figura 4.5: Detalhe de um conjunto poss´ıvel de estados e respectivas transi¸cõespara uma dada ordem de trabalho no WOW!, desde a sua submissãono 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âmicoe pode ser alterado por um administrador. Figura retirada de uma brochura promocional do WOW!, Critical Software S.A.

A utiliza¸cãode uma ferramenta deste tipo, por parte de uma empresa ou organiza¸cão,oferece vantagens quer àgestãode topo quer aos colaboradores individuais: para os colaboradores individuais, o WOW! éuma aplica¸cãoonde estãoregistadas todas as tarefas, contribuindo activamente para o desenvolvimento em ambientes multi-tarefa e para a organiza¸cãopessoal das tarefas de acordo com prioridades. Para a gestãode topo, esta ferramenta permite obter uma visãoglobal do estado da organiza¸cãoem termos de tempo gasto por tarefa executada, sendo uma mais valia para a previsãoe gestão/aloca¸cãode recursos.

4.5 Vis˜aogeral sobre a arquitectura do WOW!

O WOW! éinteressante nãosódo ponto de vista de produto como tambémdo ponto de vista de plataforma. Existem diversos plug-ins que estendem as funcionalidades do WOW!, e existem atéprojectos que pretendem usar a arquitectura do WOW! para criar produtos com fins diferentes do inicial (por exemplo o WOW- Storm – um sistema de registo e classifica¸cãosocial de ideias). De modo a conseguir ter essa expansibilidade, a plataforma WOW! assenta sob uma arquitectura distribu´ıda,modular e expans´ıvel, com uma componente central – o core – estruturado em camadas lógicas. E´ no core que se situam todas as

1O Comet éum conceito semelhante ao Ajax introduzido por Alex Russel, mas no qual éo servidor que toma a iniciativa de “enviar” os dados ao browser sem que este tenha que efectuar um pedido. Tambémé conhecido por Ajax Push, Reverse Ajax ou HTTP Streaming

41 Desenvolvimento funcionalidades base da aplica¸cão,quer a n´ıvel lógico,funcional e de apresenta¸cão, quer a n´ıvel de gestãoe configura¸cão. E´ poss´ıvel a execu¸cãode váriasinstâncias do core simultaneamente, em servidores distintos, o que permite a alta escalabilidade e disponibilidade desta aplica¸cão. A consistênciados dados fica sempre garantida atravésda partilha da base de dados e pelo balanceamento dos pedidos, uma vez que cada um éencaminhado para uma únicainstância. O WOW! apresenta tambéma vantagem de ser uma plataforma extens´ıvel. E´ poss´ıvel adicionar novas caracter´ısticasàplataforma atravésde componentes que se podem ser divididos em duas categorias: plugins e connectors. Os plugins sãocomponentes que se encontram no mesmo nóf´ısicoque a aplica¸cão, partilhando do mesmo contexto de execu¸cãodo core. Sãoassim uma forma mais directa de obter informa¸cãoda plataforma, visto que nãopossuem restri¸cõesde acesso aos dados nem dependênciasexternas. A arquitectura deste componente terá assim que permitir váriasexecu¸cõesinstanciadas, cada uma associada a um core. Por outro lado, os connectors sãocomponentes que se encontram distribu´ıdos, comunicando externamente com o core. Quer a sua execu¸cão,quer a obten¸cão dos dados estãoassim dependentes de interfaces de comunica¸cãoexternas que a plataforma disponibiliza. Estes componentes, ao contráriodos plugins, sãoinstan- ciados unicamente e recorrem ao protocolo de comunica¸cão Java Messaging Service (JMS) para comunicar com o core.

4.6 WOW! Oﬄine

Para além das op¸cõestomadas relativamente àtecnologia a utilizar, surgiu tambéma necessidade de optar por um dos modos de execu¸cãoapresentados na seçcão 4.2. Das trêsop¸cõesposs´ıveis, foi o modo “aplica¸cãoassume o estado offline”, descrito na seçcão 4.2.3, que mereceu a maior aten¸cão,uma vez que reúneas vantagens de uma experiênciamais positiva para o utilizador (uma vez que este nãotem que participar activamente na altera¸cãodo modo execu¸cãocomo descrito na seçcão 4.2.1) e nãoconstitui uma sobrecarga excessiva para servidor (como o modo abordado na seçcão 4.2.2). No entanto esta op¸cãocomprometia a complexidade da implementa¸cãopara além dos objectivos propostos para este projecto, e para cumprir o prazo dado foi tomada a decisãode implementar o modo “utilizador decide”, especificando apenas de forma teóricao modo “aplica¸cãoassume o estado offline”. As caracter´ısticas do Gears foram jádescritas na seçcão 3.1. Na Figura 4.7 mostra-se a sua forma de funcionamento quando integrado numa web application.

42 Desenvolvimento

Nesta figura representa-se o módulo LocalServer do Gears como um ponto de de- cisão.Aqui sãotestadas as condi¸cõesque determinam se o pedido seráinterceptado e servido localmente ou se prossegue para uma máquinaremota. E´ tambémrepresen- tada uma base de dados, que corresponde ao módulo Database, mas que poderánão ser utilizada. Este módulo,tal como o módulo Workerpool, tem carácteropcional e sãoutilizados consoante os requisitos da aplica¸cão. A plataforma WOW! lida com mais dados do que énecessáriopassar para o lado do cliente. Em conformidade com o jáexposto na seçcão 4.1.1, volta-se a frisar que nãose pretende recriar toda a lógicade negócio,nem os conteúdosda base de dados no cliente, pela sua complexidade e volume de dados. Pretende-se, pelo contrário,permitir que os utilizadores tirem partido da capacidade de poder consultar as suas ordens de trabalho quando nãodispõede uma liga¸cão,transferindo apenas o essencial para isto seja poss´ıvel. A páginainicial do WOW! apresenta um resumo das ordens de trabalho abertas – enviadas e recebidas – que se pretende permitir visualizar offline (ver Figura 4.6). Como prova de conceito foi efectuada uma abordagem pragmáticadas váriaspossi- bilidades descritas na seçcão 4.2.

4.6.1 Modo “aplica¸cãodecide” com deteçcãoautomáticada liga¸cão

A primeira abordagem estudada para a disponibiliza¸cãodas funcionalidades offline foi o modo “aplica¸cãodecide” com deteçcãoautomáticade liga¸cão,apresentado na seçcão 4.2.2. Para que isto seja poss´ıvel foi implementado um mecanismo de ver- ifica¸cãoperiódicado estado da liga¸cãoatravésde chamadas Ajax ass´ıncronas. O resultado destes pedidos determina o estado da aplica¸cão,executando as tarefas de sincroniza¸cãode dados sempre que pertinente. Este método, embora imediato e simples de implementar depressa se revelou inadequado para o projecto, devido ao elevado consumo de recursos do servidor que a utiliza¸cãointensiva faz esperar: a comunidade da plataforma WOW! no principal cliente excede os 7000 utilizadores. Foi estimado que para uma utiliza¸cãode fluidez aceitável o estado da liga¸cãodeveria ser testado a cada cinco segundos. Assumindo uma adesão(previsãopessimista) de 1% aos servi¸cos offline assistir-se-ia a cerca de 840 pedidos adicionais por minuto. Mas o principal problema desta aproxima¸cãoprende-se com o facto de a ver- ifica¸cãoser feita em intervalos de tempo discretos, levando àpossibilidade de a aplica¸cãopoder ter em dado momento, uma representa¸cãoerrada do seu estado real da liga¸cão. Este problema éilustrado na Figura 4.8 onde se vêclaramente a discrepânciaentre o estado real da liga¸cãoe a representa¸cão interna que esta tem. Note-se que nesta janela de tempo, qualquer açcãodo utilizador que exija uma resposta s´ıncronado utilizador levá-lo-ápara um “beco sem sa´ıda” onde nãoterá

43 Desenvolvimento

Figura 4.6: A páginainicial do WOW apresenta um resumo das últimasordens de trabalho enviadas e recebidas. Na imagem pode-se observar a transi¸cãodo estado online para offline.

acesso àversão offline porque a aplica¸cãonãofez a transi¸cãoautomática,nem acesso àversão online, porque na verdade, nãopossui uma liga¸cão.O que aconteceránesta situa¸cãoseráuma tentativa de acesso ao servidor por parte da aplica¸cão,numa altura em que este se encontra indispon´ıvel, e o resultado seráuma mensagem de “pedido excedeu o tempo” apresentado pelo browser. Este éum estado sem retorno porque apóso browser apresentar esta mensagem todos os recursos JavaScript ficam indispon´ıveis, tornando imposs´ıvel o regresso ao estado anterior ou o tratamento do erro de qualquer outra forma. No entanto, as chamadas Ajax podem ser tratadas de forma especial para a eventualidade de falha, e portanto, nãoconstituem problema.

44 Desenvolvimento

Figura 4.7: Ilustra¸cãodo funcionamento do Gears numa web application que utiliza um motor Ajax. Os pedidos HTTP ou HTTPS podem ser interceptados e tratados localmente ou podem ser feitos a uma máquina remota, consoante se verificarem ou nãoas condi¸cões expressas no ponto 3.1.1. E´ representado um acesso a uma base de dados local (fornecida pelo Gears), mas a sua utiliza¸cãoéopcional.

4.6.2 Implementa¸c˜aodo modo “utilizador decide”

Este modo de execu¸cãofoi jádescrito na seçcão 4.2.1 e a sua principal caracter´ısticaéser o utilizador a decidir se a aplica¸cãodeve utilizar um servidor remoto ou a máquinalocal como fornecedor de dados. Relativamente ao WOW!, o WOW! Offline na vertente “utilizador decide” vem alterar os seus casos de uso, dando ao utilizador a possibilidade de alterar o estado de execu¸cãoda aplica¸cão(entre online e offline). Resta dizer que no modo online se mantêmtodas as funcionalidades anteriores, e que no modo offline torna-se poss´ıvel visualizar os conteúdosda páginaprincipal do WOW! (Figura 4.6) e os detalhes das ordens de trabalho (Figura 4.9), tal como expressa a Figura 4.10 Esta aproxima¸cãofoi utilizada na prova de conceito do WOW! adicionando um controlo àinterface desta aplica¸cãoque permite ao utilizador alternar entre os estados online e offline. Na transi¸cãode online para offline sãodescarregados os recursos necessáriospara a execu¸cãodesta aplica¸cãosem recorrer àInternet. Para o fazer

45 Desenvolvimento

Figura 4.8: Neste exemplo do modo “aplica¸cãodecide”, o teste da liga¸cãoéfeito éfeito a cada cinco segundos. O resultado deste teste nãoreflecte sempre o estado real da aplica¸cão, podendo levar a aplica¸cãoa ter comportamentos indesejáveis. Na figura assinala-se um per´ıodo de tempo no qual a representa¸cãointerna do estado da liga¸cãonãocorresponde à realidade.

éutilizado um recurso ResourceStore e um ManagedResourceStore (introduzidos em 3.1.1). O primeiro éutilizado para armazenar a páginaprincipal do WOW! – do- ravante designada por home.jsp – e o segundo éutilizado para armazenar imagens, folhas de estilo CSSe scripts JavaScript. Para a implementa¸cãodeste modo de execu¸cãoforam identificadas as seguintes tarefas:

1. Guardar informa¸cãoque permita a recria¸cãodas páginasque se pretende disponibilizar offline (utilizando o Gears).

2. Disponibilizar um controlo que permita alterar o estado de execu¸cãoatravés da interaçcãocom a página principal.

3. Durante a sincroniza¸c˜aode dados, apresentar o progresso da transferˆenciade dados.

O primeiro passo consistiu na identifica¸cãode todos os conteúdosque sãonecessários transferir para a execu¸cão offline. Foi utilizado um recurso do Gears do tipo ManagedResourceStore, que recorre a um ficheiro manifesto para identificar todos os ficheiros que deve transferir. Este recurso égerido automaticamente pelo Gears, transferindo para o cliente a versãomais recente sempre que énecessário, isto é,sempre que exista um ficheiro manifesto com uma identifica¸cãode versãoque seja diferente da actualmente dispon´ıvel no cliente. Uma vez identificados todos ficheiros necessáriospara a execu¸cão offline num (ou mais) ficheiros manifesto o Gears encarrega-se da sua actualiza¸cão,mas o preenchimento destes ficheiros manifesto émanual, o que se traduz num cuidado extra na manuten¸cãoda aplica¸cão. A forma como esta informa¸cãoéguardada deve tambémser cuidadosamente estudada. A op¸cãomais flex´ıvel passa por utilizar o módulo Database apresentado na seçcão 3.1.1 e guardar a informa¸cãode uma forma relacional. Para a recria¸cão das páginaspode ser disponibilizada uma versãoHTML da páginaque funciona

46 Desenvolvimento

Figura 4.9: P´aginade visualiza¸c˜aodo detalhe de uma ordem de trabalho.

como template, nãopossui quaisquer dados e éutilizada apenas em modo offline. E´ preenchida para cada pedido retirando os dados relevantes da base de dados. O modelo de dados do WOW! torna esta op¸cãoextremamente trabalhosa, uma vez que as entidades envolvidas na gera¸cãode cada páginade informa¸cão,sobre cada ordem de trabalho, têmrela¸cõesde dependênciacomplexas, seguindo padrões muito variáveis. Por exemplo: em cada ordem de trabalho existe um formulárioque permite a sua progressãode estado, com diversos campos opcionais e obrigatórios; este formulárioédefinido pelo administrador e estárelacionado nãoapenas com o tipo de ordem de trabalho, mas tambémcom o estado actual em que esta se encontra e a açcãoque se pretende realizar. O elevado númerode combina¸cõesde tipos de ordem de trabalho, estados e açcõesque existem num dado momento, juntamente com a sua possibilidade de altera¸cão,obrigariam àimplementa¸cãode uma lógicade negóciocomplexa, o que estáfora do âmbito deste projecto.

47 Desenvolvimento

Figura 4.10: Esquema UML que expressa os casos de uso do WOW! Oﬄine no modo “utilizador decide”.

4.6.3 Especifica¸cãodo modo “aplica¸cãoassume o estado offline”

A aproxima¸cãopara o modo “aplica¸cãoassume o estado offline” foi também dividida em váriastarefas:

1. Guardar informa¸cãoque permita a recria¸cãoda páginaprincipal do lado do cliente no estado offline (utilizando o Gears)

2. Dotar a aplica¸cãodo cliente de um mecanismo de deteçcãoda liga¸cão.

3. Identificar os “momentos chave” em que deveráocorrer sincroniza¸cãode dados

4. Implementar a sincroniza¸c˜aode dados.

A sincroniza¸cãode dados deve ser feita em ambas as transi¸cões online-offline e offline-online, quer para transferir novos dados do servidor (os pedidos podem ser alterados por outros utilizadores) quando se transita do estado quer para comunicar eventuais altera¸cõesfeitas em modo offline. Relativamente ao WOW!, o WOW! Offline na vertente “aplica¸cãoassume o estado offline” vem alterar os seus casos de uso, dando ao utilizador a possibilidade de activar esta funcionalidade. A partir do momento que a funcionalidade estáac- tivada o utilizador deve tambémter a possibilidade de gerir algumas preferências relacionadas com privacidade de dados. Deveráter a hipótesede desactivar o armazenamento local e de remover todos os dados jáarmazenados tal como descrito na Figura 4.11.

48 Desenvolvimento

Figura 4.11: Esquema UML que expressa os casos de uso do WOW! Oﬄine no modo “utilizador decide”.

A primeira vez que o WOW! Offline éacedido por um cliente, e caso seja detec- tada a presen¸cado Gears, todos os recursos necessáriosàsua execu¸cãosãotrans- feridos. Todos os acessos posteriores serãofeitos a estes recursos locais (recorda-se que o Gears pode ser utilizado para os manter actualizados recorrendo ao Managed- ResourceStore 3.1.1). Atravésdo JavaScript époss´ıvel interceptar os eventos de load e unload da página,que sãodespoletados sempre que ocorre um re-acesso da mesma (incluindo a açcão refresh comum dos browsers) sempre que esta éabandonada ou ainda ou ainda se a janela for encerrada. Tal como sugerido na seçcão 4.6.2 a camada de interface desta aplica¸cão(cada páginaindividual em HTML) deveráser implementada como sendo um template para apresenta¸cão de dados, sendo totalmente preenchida atravésde fun¸cõesem JavaScript. O objectivo deste ponto écriar um padrãode dados que permita ao JavaScript preencher os dados em cada página (template) independentemente de qual seja a fonte – o servidor remoto ou a máquinalocal tal como exemplificado no diagrama da Figura 4.12. Na figura a aplica¸cãorecorre ao servidor remoto para obter os dados pretendidos quando se encontra na presen¸cade uma liga¸cão,mas para dados que exijam uma carga de processamento pelo servidor este acto pode ser

49 Desenvolvimento

Figura 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). substitu´ıdopelo envio de um campo de controlo que se destina a aferir se os dados locais se encontram actualizados. No caso de estarem actualizados a comunica¸cão com o servidor pode ser substitu´ıdapor uma query àbase de dados local.

50 Cap´ıtulo5

Resultados e Futuros Desenvolvimentos

Todo o estudo feito sobre o tema OWA foi jáabordado ao longo do documento. Neste cap´ıtuloapresentam-se os resultados obtidos na implementa¸cãoda prova de conceito, que visava compreender a melhor forma de disponibilizar uma versãoof- fline no WOW!, uma plataforma de gestãode ordens de trabalho jáexistente, desenvolvida pela Critical Software S.A.

5.1 Resultados Obtidos

Os resultados obtidos neste projecto sãoextremamente satisfatórios, uma vez que o estudo do tema OWA e a implementa¸cãode uma prova de conceito que o ilustrasse foi conseguido com sucesso. A funcionalidade offline foi adicionada ao produto WOW! da Critical Software S.A., permitindo a visualiza¸cãode ordens de trabalho, e dos seus detalhes, mesmo na ausênciade uma conexãoactiva àInternet. Embora para a solu¸cãoimplementada tenha sido utilizada uma abordagem do tipo “utilizador decide”, pretende-se que esta seja convertida para “aplica¸cãodecide”, ou mesmo para uma aproxima¸cãoh´ıbrida, semelhante àutilizada pelas aplica¸cões estudadas nas seçcões 3.5.1e 3.5.2. Para a sua implementa¸cão,descrita no cap´ıtulo4, foram tomadas decisõesde ordem práticaque permitissem tornar o trabalho exequ´ıvel nos prazos dados. Tentou- se sempre que estas decisõesafectassem o m´ınimoem termos de desempenho e de experiênciapara o utilizador. Considera-se que a implementa¸cãodo modo offline com uma transi¸cãoentre modos do tipo “utilizador decide” (ver seçcão 4.2) reflecte o compromisso entre o desempenho pretendido e os recursos dispon´ıveis, e para além

51 Resultados e Futuros Desenvolvimentos de ser um exemplo eficaz das possibilidades que as OWA podem trazer àaplica¸cão WOW! desenvolvida pela Critical Software, étambémum estudo que pode ser utilizado para analisar a implementa¸cãodesta tecnologia noutros produtos da mesma empresa. Note-se que o principal objectivo do trabalho era ganhar familiaridade com este tema, entender as suas vantagens e desvantagens, e compreender as suas limita¸cões. Tudo indica que existam váriaspossibilidades de implementa¸cãodeste paradigma noutros produtos da Critical Software, que pela sua natureza, podem tambémtirar partido da execu¸cão offline.

5.2 Trabalho Futuro

O desenvolvimento do conceito e formas de implementa¸cãode OWA continua em forte desenvolvimento, no entanto a sua adop¸cãoainda nãoégeneralizada. A dificuldade da sua implementa¸cãoem web applications jáexistentes éo principal obstáculoàsua maior divulga¸cão. Hátambémum factor que deve ser tido em considera¸cão: a manuten¸cãode código. A implementa¸cãode uma versão offline de uma web application requer a implementa¸cãodas mesmas regras de negócio(ou de uma versãosimplificada) utilizadas no servidor. Para que isto seja poss´ıvel énecessárioter em conta: a capacidade de processamento do cliente e o factor de duplica¸cãode código, que tornaráa aplica¸cãomais dif´ıcilde manter, uma vez que uma altera¸cãoàlógicade negóciodo servidor implica tambémuma altera¸cãoàsua versão offline. A prova de conceito implementada permite jáa visualiza¸cão offline dos pedidos abertos (enviados e recebidos) que constam na páginaprincipal (este númeroé fixo e pode ser alterado pelo administrador). Uma funcionalidade desejável seria a possibilidade de interaçcãocom a aplica¸cãoem modo offline e sincroniza¸cãocom o servidor quando existisse uma liga¸cãodispon´ıvel. Foi estudada a utiliza¸cãodo modo de execu¸cão“aplica¸cãoassume o estado offline”, descrito em 4.2.3, e esta seria a forma desejável para o WOW! Offline, no entanto, para que esta op¸cãoseja viável, seránecessáriaa implementa¸cãode uma forma eficiente de sincroniza¸cãoe armazenamento de dados de uma forma relacional. Para atingir este objectivo poderáser seguida uma pol´ıticade automa¸cãodo processo, no qual a versão online da aplica¸cãogera scripts de cria¸cãopara as tabelas necessáriasna base de dados da versão offline (nãoexiste nenhuma ferramenta para o fazer, portanto seria necessáriaa sua implementa¸cão),e no qual as páginasHTML disponibilizadas pelo servidor aos clientes web (browser) servem como templates de apresenta¸cãode informa¸cãoe sãopreenchidas de forma semelhante pelo servidor – quando a aplica¸cãoestiver online – ou pelo cliente, atravésde fun¸cõesem JavaScript

52 Resultados e Futuros Desenvolvimentos

– quando a aplica¸cãoestiver offline. No entanto no WOW!, devido àquantidade de informa¸cãotratada e devido àscomplexas rela¸cõesentre as diferentes entidades, é de esperar que a complexidade da implementa¸cãode um mecanismo deste tipo torne esta aproxima¸cãodemasiado custosa. O HTML 5, embora um forte candidato, ainda nãoestásuficientemente desenvolvido. A sua especifica¸cãoainda tem o carácterde Draft (rascunho) e estásujeita a modifica¸cõese àaceita¸cãoe implementa¸cãopor parte dos browsers, e portanto de momento, foi desconsiderado. No entanto no futuro, se esta especifica¸cãoatingir um estado de maturidade que permita a sua adop¸cão,deveráser considerada como um poss´ıvel caminho a seguir.

53 Resultados e Futuros Desenvolvimentos

54 Cap´ıtulo6

Conclus˜oes

Neste cap´ıtulosãoapresentadas as conclusõesdo projecto e considera¸cõesfinais relativamente àtecnologia estudada.

6.1 Conclus˜oes

O rápidodesenvolvimento tecnológico faz prever que a disponibilidade de liga¸cão àInternet seja cada vez mais fácil e mais rápido,mas vãocontinuar a existir lugares onde o acesso élimitado e onde as OWA podem desempenhar um papel de relevo. Por outro lado, esta tecnologia pode tambémser utilizada para melhorar o desempenho de páginas web com uma necessidade elevada de imagens ou outros recursos dispendiosos em termos de espa¸coe foram atéestudados dois exemplos da utiliza¸cão desta vertente desta tecnologia em 3.5.3. Acredita-se que as OWAs vêmresponder a uma necessidade real por parte das web applications actuais, e que a evolu¸cão que representam se compara àque se assistiu dos thin-clients para os fat-clients, em termos de autonomia do servidor. A capacidade de oferecer conteúdosdinâmicosno browser independentemente da existênciade uma liga¸cãoreúneas vantagens t´ıpicasdas web applications, como ausênciade instala¸cãoe actualiza¸cõesinstantâneas,com as vantagens das aplica¸cões de desktop em capacidade de processamento e armazenamento de dados na máquina local. As tecnologias dispon´ıveis atéàdata, estudadas no âmbito deste projecto, que permitem o desenvolvimento de OWAs e que apresentam maior maturidade sãoo Gears e o Adobe AIR. Ambas se apresentam sobre a forma de plugins que necessitam de uma instala¸cãoextra para poderem ser utilizadas. Apesar de esta instala¸cãoser

55 Conclusões apenas necessáriauma vez, poderáconstituir um factor de desencorajamento àsua adop¸cão. O HTML 5, uma especifica¸cãoabordada neste documento na seçcão 3.4, poderá ser uma alternativa que oferece funcionalidades offline a uma web application sem a necessidade de qualquer instala¸cão,no entanto esta especifica¸cãoainda nãofoi aceite pelos principais browsers – o documento que define o HTML 5 ainda tem o estatuto de Draft – e ainda nãoéposs´ıvel antecipar quando éque isto poderáacontecer. Um dos problemas que surge frequentemente na implementa¸cãode uma versão offline para uma web application éa necessidade de sincroniza¸cãode dados. Quando a informa¸cãopode ser alterada por váriosutilizadores simultaneamente, énecessário prever os conflitos que da´ıpodem surgir e dotar a aplica¸cãode uma forma de os resolver ou alertar o utilizador para a necessidade de altera¸cão dos dados. Em conclusão,todos os objectivos propostos para este projecto foram atingidos. A prova de conceito implementada reflecte de forma clara as possibilidades oferecidas pela tecnologia OWA e seráutilizado no futuro para compreender a melhor forma de o implementar de forma definitiva no WOW!.

56 Referˆencias

[Ada08] Lucas Adamski. Introducing Adobe AIR security model, Fevereiro de 2008. Dispon´ıvel em http://www.adobe.com/devnet/air/articles/ introduction_to_air_security.html, acedido em Mar¸code 2008.

[Ado08] Adobe. Adobe AIR 1.0 Security White Paper, 2008. Dispon´ıvel em http://download.macromedia.com/pub/air/documentation/1/air_ security.pdf, acedido em Mar¸code 2008.

[Alm08] Dion Almaer. Gears as a bleeding-edge html 5 implementation, March, 2008. Dispon´ıvel em http://almaer.com/blog/ gears-as-a-bleeding-edge-html-5-implementation, acedido em Mar¸code 2008.

[BL96] Tim Berners-Lee. The world wide web: Past, present and future. Agosto de 1996. Dispon´ıvel em http://www.w3.org/People/Berners-Lee/ 1996/ppf.html, acedido em Abril de 2008.

[CDGH08] Mike Chambers, Daniel Dura, Dragos Georgita, and Kevin Hoyt. Adobe AIR for JavaScript Developers. O’Reilly Media, 2008. Dispon´ıvel em http://onair.adobe.com/files/AIRforJSDevPocketGuide.pdf, acedido em Abril de 2008.

[Con99] Jim Conallen. Modeling Web Application Architectures with UML, Junho 1999. Dispon´ıvel em http://www.uml.org.cn/UMLApplication/pdf/ webapps.pdf, acedido em Maio de 2008.

[Ent07] Entrust. What is a public key information?, 2007. Dispon´ıvel em http: //www.entrust.com/pki.htm, acedido em Junho de 2008.

[Gar05] Jesse James Garret. Ajax: A new approach to web applications. February 2005. Dispon´ıvel em http://www.adaptivepath.com/ideas/ essays/archives/000385.php, acedido em Mar¸code 2008.

[Greon] Philip Greenspun. Philip and Alex’s Guide to Web Publishing. 2003 (last revision). Dispon´ıvel em http://philip.greenspun.com/panda/, acedido em Junho de 2008.

[Gro02a] App Design Group. Thick vs. thin client comparison, 2002. Dispon´ıvel em http://www.donjacobsvw.com/images/weekendspecials/ Thick-vs-Thin.pdf, acedido em Junho de 2008.

57 REFERENCIASˆ

[Gro02b] Technical Research Group. Thin Client Tecnhology - White Paper, 2002. Dispon´ıvel em http://www.picktrg.com/pubs/ thinclientwhitepaper.pdf, acedido em Junho de 2008. [Gro08] Miniwatts Marketing Group. World internet usage, March 2008. Dispon´ıvel em http://www.internetworldstats.com/stats.htm, acedido em Abril de 2008. [Hic08] Ian Hickson. HTML 5 Draft Recommendation, 2008. Dispon´ıvel em http://www.whatwg.org/specs/web-apps/current-work/, acedido em Mar¸code 2008. [Kha] Olga Kharif. Top 10 municipal wifi plans. Dispon´ıvel em http:// images.businessweek.com/ss/06/08/muni_wifi/index_01.htm, acedido em Mar¸code 2008. [Lab07] Mozilla Labs. Prism, Outubro 2007. Dispon´ıvel em http://labs. mozilla.com/2007/10/prism/, acedido em Mar¸code 2008. [Loo06] Chris Loosley. Rich Internet Applications:Design, Measurement,and Management Challenges, 2006. Dispon´ıvel em http://www.keynote. com/docs/whitepapers/RichInternet_5.pdf, acedido em Maio de 2008. [Mic08] Microsoft. Introduction to Occasionally Connected Applications using Sync Services for ADO.NET, 2008. Dispon´ıvel em http://msdn. microsoft.com/en-us/sync/bb887608.aspx, acedido em Junho de 2008. [Nao08] Erica Naone. Offline web applications, Abril 2008. Dispon´ıvel em http://www.technologyreview.com/read_article.aspx?ch= specialsections{\&%}sc=emerging08{\&}id=20245, acedido em Abril de 2008. [NJN00] Jason Nieh, Yang S. Jae, and Naomi Novik. A comparison of thin-client computing architectures. 2000. Dispon´ıvel em http://www.ncl.cs. columbia.edu/publications/cucs-022-00.pdf, acedido em Maio de 2008. [O’R06] Tim O’Reilly. Web 2.0 compact definition: Trying again, Dezembro 2006. Dispon´ıvel em http://radar.oreilly.com/archives/2006/12/ web-20-compact-definition-tryi.html, acedido em Mar¸code 2008. [O’R09] Tim O’Reilly. What is Web 2.0: Design patterns and business models for the Next Generation of Software, 2005/30/09. Dispon´ıvel em http://www.oreillynet.com/pub/a/oreilly/tim/news/2005/09/ 30/what-is-web-20.html, acedido em Mar¸code 2008. [Rus06] Alex Russel. Comet: Low latency data for the browser, March Mar¸co 2006. Dispon´ıvel em http://alex.dojotoolkit.org/?p=545, acedido em Mar¸code 2008.

58 REFERENCIASˆ

[Sad97] Darleen Sadoski. Client/server software architectures–an overview. Agosto 1997. Dispon´ıvel em http://www.sei.cmu.edu/str/ descriptions/clientserver_body.html, acedido em Junho de 2008. [Sch96] George Schussel. Client/server past, present, and future. 1996. [Smi07] Kevin C. Smith. Css ﬁlters - will the browser apply the rule?, July 2007. Dispon´ıvel em http://centricle.com/ref/css/filters/, acedido em Mar¸code 2008. [vK08] Anne van Kesteren. The XMLHttpRequest Object W3C Work- ing Draft, 15 Abril 2008. Dispon´ıvel em http://www.w3.org/TR/ XMLHttpRequest/, acedido em Abril de 2008. [Wil06] Greg Wilkins. Why ajax comet?, July Julho 2006. Dispon´ıvel em http://www.webtide.com/downloads/whitePaperWhyAjax.html, acedido em Abril de 2008.

59 REFERENCIASˆ

60 Anexo A

Screenshots

Algumas imagens de aplica¸c˜oesque utilizam funcionalidades oﬄine ilustrativas da tecnologia abordada neste documento.

Figura A.1: Diálogoapresentado ao utilizador na primeira activa¸cãodas funcionalidades offline no Google Docs & Spreadsheets.

61 Screenshots

Figura A.2: Na activa¸cãodas funcionalidades offline étambémoferecida a possibilidade da cria¸cãode alguns atalhos, por exemplo, no ambiente de trabalho.

Figura A.3: O Google Docs mantéma todo o momento a possibilidade de altera¸cãodestas defini¸cões,ou da anula¸cãodos servi¸cosoffline para um dado computador.

62 Screenshots

Figura A.4: Apósa instala¸cãodo Gears qualquer visita ao Remember The Milk despoleta uma sincroniza¸cãoque ocorre automaticamente e sem necessidade de interven¸cãopor parte do utilizador.

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