O ine Web Applications
Transcript of O ine Web Applications
Faculdade de Engenharia da Universidade do Porto
Offline Web Applications
Enabling offline execution on the WOW product
Joao Goncalves da Costa
Relatorio de Projecto realizado no Ambito do
Mestrado Integrado em Engenharia Informatica e Computacao
Orientador Teresa Galvao Dias (PhD)
Julho de 2008
ccopy Joao Goncalves da Costa 31 de Julho de 2008
Offline Web Applications
Joao Goncalves da Costa
Relatorio de Projecto realizado no Ambito do
Mestrado Integrado em Engenharia Informatica e Computacao
Aprovado em provas publicas pelo juri
Presidente Pedro Ferreira do Souto (PhD)
Arguente Artur Pereira (PhD)
Vogal Teresa Galvao Dias (PhD)
27 de Julho de 2008
Resumo
Este projecto teve como objectivo o estudo das Offline Web Applications (OWAs)e da sua implementacao em web applications ja existentes Neste ambito foi feitauma avaliacao da aplicacao desta tecnologia no WOW uma plataforma integradade gestao de ordens de trabalho desenvolvida pela Critical Software SA ao longodos ultimos 6 anos e implementada uma prova de conceito que permite a utilizacaode um conjunto de funcionalidades base desta web application independentementedo estado da ligacao a Internet
O conceito das OWAs enquadra-se numa tecnologia de Internet que permiteo acesso a um website atraves do browser mesmo na ausencia de uma ligacao arede global e foi considerado pela revista Technology Review como uma das maisimportantes tecnologias emergentes no final de 2007 [Nao08] O estudo efectuado noWOW pretende ser um primeiro passo na compreensao dos problemas associados asua implementacao e respectivas solucoes e tambem da avaliacao dos benefıcios dautilizacao desta tecnologia para os utilizadores finais
A evolucao das tecnologias associadas a Internet a que se assiste continua-mente impulsionou tambem evolucao da forma como a informacao e produzidadistribuıda e armazenada Surgiram novas web applications oferecendo funcionali-dades de criacao e edicao de conteudos que trouxeram consigo a vantagem de tornarpossıvel o acesso a informacao a partir de qualquer lugar mas tambem a desvan-tagem de tornar a ligacao a Internet uma condicao necessaria para que isto acontecaA proliferacao destas aplicacoes a crescente utilizacao da Internet [Gro08] e a adesaoaos seus servicos indiciam a existencia de uma dependencia cada vez maior de umaligacao que nem sempre existe
As OWAs vem assim colmatar esta falha colocando no lado do cliente parte dainformacao que ate agora vinha a ser armazenada no servidor e tornando nao sopossıvel a sua consulta offline como tambem reduzindo a carga no servidor umavez que reduz as transferencias de informacao
Pretende-se neste documento apresentar diferentes formas de como a utilizacaoda tecnologia OWA pode beneficiar as web applications de hoje melhorando o seudesempenho e dando-lhes novas possibilidades de execucao aproximando-as do desk-top
i
ii
Abstract
The main purpose of this project was to study the Offline Web Applications(OWAs) and its implementation in existent web applications With this goal in minda study was conducted to use this technology in WOW an integrated platform forwork orders and work flow management developed by Critical Software over thelast 6 years and implemented a proof of concept which enables the use of a baseset of functionality for this application regardless of the internet connection state
The concept of OWAs is connected with internet technology and allows accessto a website using the browser even if a connection to the internet is not availableThis concept was considered by Technology Review as one of the most importantemerging technologies in the last quarter of 2007 [Nao08] This study conductedover the WOW platform is intended to aid in the comprehension of the problemsand solutions associated to the use and implementation of OWA as well as thebenefits that it brings to the end user
The Internet and Internet technologies are changing the way in which informa-tion is produced distributed and stored New web applications appeared with newcontent creation and edition functionalities and with it the advantage of infor-mation retrieval from any place and time became possible but with the conditionof Internet connection availability With Internet use growing every year [Gro08]content creation is starting to move to this new platform The adoption of web ap-plications for content creation and edition is becoming more popular and it showsa dependency of a connection that is not always present
The OWAs are a way to solve this problem putting on the client side part ofthe information that was traditionally stored on the server and allows it to be seenand manipulated and helps reducing the server load
This document intends to present different ways in which this technology canhelp web applications as we know them improving the their overall performance andgiving them the ability to run on a browser regardless of the Internet connectionavailability
iii
iv
Agradecimentos
A realizacao e os objectivos alcancados neste projecto nao teriam sido possıveissem a colaboracao de inumeras pessoas Agradeco profundamente a todos os quecontribuıram directa ou indirectamente para o seu sucesso
A minha orientadora Professora Teresa Galvao Dias e ao Project ManagerEngenheiro Marcus Neves que me conduziram e acompanharam no desenvolvimentodeste projecto
A toda a equipa do WOW em especial o Pedro Maurıcio Costa e o Fabio Matosque contribuıram para a minha a minha integracao na Critical Software e que sempresouberam responder a todas as minhas questoes
A todos os que constituem a CSW Porto pelo fantastico ambiente de amizadeque me proporcionaram
Aos colegas de curso e a todos os que me auxiliaram na revisao deste documento
Os meus sinceros agradecimentos
Joao Goncalves da Costa
v
vi
Conteudo
1 Introducao 111 Enquadramento 112 Motivacao 213 Ambito 314 Objectivos 315 Estrutura do documento 3
2 Enquadramento do Projecto 521 Evolucao das arquitecturas de software 5
211 Thin-clients 5212 Fat-clients 6213 Arquitecturas cliente-servidor 7
22 Evolucao na Internet 8221 Paginas web estaticas 9222 Paginas web interactivas e paginas web dinamicas 9223 Web 20 e Ajax 11
23 Offline Web Applications 1324 Comparacao 13
3 Estado da arte 1731 Gears 17
311 Arquitectura 17312 Goggle Gears em dispositivos moveis 20
32 Adobe AIR 20321 Seguranca 22322 Assinatura do codigo 22
33 Mozilla Prism 23331 XML User Interface Language 23332 Prism 25
34 HTML 5 2535 Web applications que usam funcionalidades offline 26
351 Google Reader e Google Docs 26352 Remember the Milk 27353 MySpace e WordPresscom 27
36 Escolha da tecnologia 28
vii
CONTEUDO
4 Desenvolvimento 3341 Como ficar offline 33
411 Funcionalidades disponıveis em modo offline 3442 Modos de execucao 35
421 Modo ldquoutilizador deciderdquo 36422 Modo aplicacao decide 36423 Modo ldquoaplicacao assume o estado offlinerdquo 37
43 Sincronizacao de dados 38431 Quando sincronizar 39
44 WOW 4045 Visao geral sobre a arquitectura do WOW 4146 WOW Offline 42
461 Modo ldquoaplicacao deciderdquo com deteccao automatica da ligacao 43462 Implementacao do modo ldquoutilizador deciderdquo 45463 Especificacao do modo ldquoaplicacao assume o estado offlinerdquo 48
5 Resultados e Futuros Desenvolvimentos 5151 Resultados Obtidos 5152 Trabalho Futuro 52
6 Conclusoes 5561 Conclusoes 55
Referencias 59
A Screenshots 61
viii
Lista de Figuras
21 Arquitectura de um sistema thin-client em duas camadas (a esquerda)e em tres camadas (a direita) Note-se a inclusao do servidor (main-frame) na definicao das camadas desta arquitectura devido a fortedependencia cliente-servidor 9
22 Arquitectura de um fat-client em duas camadas (a esquerda) e emtres camadas (a direita) 10
23 Comparacao do modelo de web aplications sıncrono paginas estaticase interactivas abordados nas seccoes 221 e 222 com o modelo deweb applications Ajax (assıncrono) abordado na seccao 223 Figuraadaptada de http www adaptivepath com 15
31 Esquema UML do processo efectuado pelos recursos do Gears do tipoManagedResourceStore para a actualizacao dos conteudos definidosno ficheiro manifesto 29
41 Exemplo de uma arquitectura de uma web application sem uma ca-mada de abstraccao de dados Figura adaptada de http gears
google com 33
42 Exemplo de uma arquitectura de uma web application com uma ca-mada de abstraccao de dados Figura adaptada de http gears
google com 34
43 Exemplo de uma arquitectura de uma web application com uma ca-mada de abstraccao de dados e um data switch Figura adaptada dehttp gears google com 35
44 Esquema grafico ilustrando uma OWA executando no browser uti-lizando um modo de execucao do tipo ldquoaplicacao deciderdquo com de-teccao automatica do estado da ligacao via pedidos Ajax assıncronosa cada cinco segundos 37
45 Detalhe de um conjunto possıvel de estados e respectivas transicoespara uma dada ordem de trabalho no WOW desde a sua submissaono sistema ate a sua conclusao em fecho ou cancelamento Esta figurarepresenta apenas um exemplo ja que o mapa de estados para umaordem de trabalho e dinamico e pode ser alterado por um admin-istrador Figura retirada de uma brochura promocional do WOWCritical Software SA 41
ix
LISTA DE FIGURAS
46 A pagina inicial do WOW apresenta um resumo das ultimas ordensde trabalho enviadas e recebidas Na imagem pode-se observar atransicao do estado online para offline 44
47 Ilustracao do funcionamento do Gears numa web application que uti-liza um motor Ajax Os pedidos HTTP ou HTTPS podem ser inter-ceptados e tratados localmente ou podem ser feitos a uma maquinaremota consoante se verificarem ou nao as condicoes expressas noponto 311 E representado um acesso a uma base de dados local(fornecida pelo Gears) mas a sua utilizacao e opcional 45
48 Neste exemplo do modo ldquoaplicacao deciderdquo o teste da ligacao e feitoe feito a cada cinco segundos O resultado deste teste nao reflectesempre o estado real da aplicacao podendo levar a aplicacao a tercomportamentos indesejaveis Na figura assinala-se um perıodo detempo no qual a representacao interna do estado da ligacao nao cor-responde a realidade 46
49 Pagina de visualizacao do detalhe de uma ordem de trabalho 47410 Esquema UML que expressa os casos de uso do WOW Offline no
modo ldquoutilizador deciderdquo 48411 Esquema UML que expressa os casos de uso do WOW Offline no
modo ldquoutilizador deciderdquo 49412 Esquema UML que expressa o acto de recolha de dados em modo
online e offline recorrendo ao servidor (modo online) e ao sistemade armazenamento de dados local fornecido pelo Gears (modo offline) 50
A1 Dialogo apresentado ao utilizador na primeira activacao das funcional-idades offline no Google Docs amp Spreadsheets 61
A2 Na activacao das funcionalidades offline e tambem oferecida a possi-bilidade da criacao de alguns atalhos por exemplo no ambiente detrabalho 62
A3 O Google Docs mantem a todo o momento a possibilidade de alteracaodestas definicoes ou da anulacao dos servicos offline para um dadocomputador 62
A4 Apos a instalacao do Gears qualquer visita ao Remember The Milkdespoleta uma sincronizacao que ocorre automaticamente e sem ne-cessidade de intervencao por parte do utilizador 63
A5 Apos completar a sincronizacao de dados mesmo que a ligacao aInternet seja perdida o Remember the Milk continua disponıvel nobrowser (com excepcao das funcionalidades que pela sua naturezaexigem uma ligacao como por exemplo partilha de tarefas e enviode convites) 63
x
Lista de Tabelas
21 Comparacao entre thin-clients e fat-clients 7
31 Comparacao das funcionalidades oferecidas pelo Adobe AIR para asplataformas web e desktop 30
32 Resumo da utilizacao de tecnologias OWA em algumas web applica-tions consideradas na analise do estado da arte 31
xi
LISTA DE TABELAS
xii
Glossario
fat-client Cliente que nao depende totalmente de umservidor central para as suas actividadesde processamento e possui frequentementedispositivos de armazenamento de dados
6ndash8
thin-client Cliente que depende de um servidor centralpara as suas actividades de processamento
5ndash8
web application Sistema web (servidor rede HTTPbrowser) onde accoes do utilizador(navegacao e introducao de informacao)afectam o estado logico da aplicacao
i iii1ndash311ndash1517ndash1921ndash232728 3336ndash3842 5556
API Application Programming Interface 10 1718 2326 28
ASP Linguagem interpretada pelo servidorque permite a criacao de paginas webdinamicas Desenvolvida pela Microsoft
11
BSD Berkeley Software Distribution 28
CSS Cascading Style Sheets 12 2021 2324 46
DHTML Dynamic HyperText Transfer Protocol 24DOM Document Object Model 10 12
20 2324
DTD Document Type Definition 24
xiii
Glossario
ECMAScript Padrao de linguagem de programacaodefinido pela Ecma International que orig-inou o JavaScript e o JScript
24
Flash Conteudo interactivo de um ficheiro emformato SWF E desenvolvido pela Adobee visualizado atraves do Adobe FlashPlayer
21
Flex Framework baseada em XML e Action-Script desenvolvida pela Adobe para a pro-gramacao de Rich Internet Applications(RIA)
21
GPL GNU General Public License 23
HTML HyperText Markup Language 1 10ndash12 2124ndash2649
HTTP HyperText Transfer Protocol 2 26
JMS E uma API em Java que permite a troca demensagens entre componentes de software
42
JSON JavaScript Object Notation permite atroca de dados codificados num formatode texto de simples leitura
12 1828 34
LGPL GNU Lesser General Public License 23
Mozilla Prism Browser simplificado e ldquointerpretadorrdquo deeXtensible User Interface Language (XUL)(tambem designado por XULRunner) queacolhe web applications sem a interfacegrafica habitual de um browser
25
MPL Mozilla Public License 23
OCA Occasionally Connected Application 39OWA Offline Web Application i iii
2ndash515 1725 2628 3133 3651 5255 56
PDF Portable Document Format 21
xiv
Glossario
PHP Linguagem interpretada pelo servidorque permite a criacao de paginas webdinamicas mas que pode tambem ser in-vocada a partir da linha de comandos
11
pagina web estatica Pagina web que devolve sempre a mesmaresposta a todos os pedidos para todos osutilizadores e em qualquer contexto
5 9
RIA Rich Internet Applications web appli-cations que apresentam funcionalidadessemelhantes as desktop applications masque mantem a informacao no lado do servi-dor
5 1520 28
RSS Really Simple Syndication 27
SLA Service Level Agreement 40SQLite Segundo a definicao oficial SQLite is a
software library that implements a self-contained serverless zero-configurationtransactional SQL database engine
17
SSB Site Specific Browser 25SSL Secure Sockets Layer 22SWF ShockWave Flash 21
URL Uniform Resource Locator 18
VPN Virtual Private Network 38
WOW Work Orders Web Plataforma de gestaode ordens de trabalho e do seu fluxo de-senvolvida pela Critical Software SA
i iii28 3340ndash434551ndash5356
WWW World Wide Web 11 1214
XBL eXtensible Binding Language 24XHTML eXtensible HyperText Markup Language 12XML eXtensible Markup Language 11 12
23 2428
XSLT eXtensible Stylesheet Language Transfor-mation
12
XUL eXtensible User Interface Language xiv23ndash25
xv
Glossario
xvi
Capıtulo 1
Introducao
Neste capıtulo enquadra-se o tema do projecto introduzindo alguns dos conceitos
nos quais se baseia Apresentam-se as motivacoes ambito objectivos e a estrutura
deste documento
11 Enquadramento
A Internet foi originalmente concebida para ser um espaco de partilha de in-
formacao onde pessoas (atraves de maquinas) pudessem comunicar Na sua origem
as paginas eram estaticas constituıdas por texto formatado em HyperText Markup
Language (HTML) e ligadas entre si [BL96] Hoje encontramos conteudos cada vez
mais complexos e dinamicos incluindo som vıdeo ou streams multimedia [Loo06] e
em 2005 foi introduzido por [OrsquoR09] o termo Web 20
De acordo com [Greon] um website pode pertencer a uma ou varias das seguintes
categorias
bull Documento ndash um website essencialmente estatico onde alteracoes a uma
parte do conteudo nao tem implicacoes no seu comportamento
bull Base de dados ndash um directorio de informacao organizada em categorias
bull Aplicacao ndash um website dinamico que utiliza uma linguagem executada ou
interpretada do lado do servidor e que processa as accoes ou informacao in-
troduzida pelo utilizador para fornecer um servico ou nova informacao
A ultima destas categorias constitui aquilo que e normalmente designado por
web application O conceito utilizado ao longo deste documento e o mesmo que
o introduzido por Jim Coallen em [Con99] que define web application como um
1
Introducao
sistema web (servidor rede HyperText Transfer Protocol (HTTP) browser) onde
accoes do utilizador (navegacao e introducao de informacao) afectam o estado logico
da aplicacao A sua definicao tenta estabelecer que uma web application e um
sistema de software com estado de negocio1 e que a sua interface de interaccao com
o utilizador e distribuıdo atraves de um sistema web
12 Motivacao
A quantidade de informacao que e produzida e armazenada com recurso a es-
tas web applications disponıveis online tais como e-mail blogues ou mesmo docu-
mentacao tornam por vezes a disponibilidade de ligacao uma condicao necessaria
a produtividade e como consequencia desta barreira muitos potenciais utilizadores
opoem-se a adopcao de produtos web em detrimento das tradicionais desktop appli-
cations
Assegurar o acesso a uma ligacao de Internet e hoje muito mais facil A Internet
movel e ja uma realidade e encontra-se amplamente divulgada mas continuam a
existir diversas situacoes nas quais os utilizadores estao privados de uma ligacao
a Internet tais como uma viagem de metro ou de aviao ou quando se encontram
deslocados do seu paıs de origem e nao possuem nenhum plano de subscricao
Uma OWA consiste numa web application que para alem de manter todas as
caracterısticas anteriores se mantem disponıvel mesmo na ausencia de uma ligacao
a Internet e surge como uma tentativa de estreitar as barreiras existentes entre a
web e o desktop Isto significa que devera existir um mecanismo capaz de assegurar
a manutencao do estado logico da aplicacao quando a ligacao com o servidor e
quebrada permitindo ao utilizador continuar a utilizar a aplicacao e que sera capaz
de informar o servidor do estado em que a aplicacao se encontra quando a ligacao for
reposta A principal vantagem que advem desta possibilidade e evidente eliminar
a necessidade da existencia de uma ligacao a Internet para que a aplicacao possa ser
utilizada
Por outro lado a vontade de integracao de funcionalidades tıpicas das desktop
applications nas web applications foi um dos principais factores que impulsionou o
desenvolvimento deste conceito uma vez que obrigou a uma reflexao ldquopara alem
do browserrdquo e a uma adaptacao das arquitecturas existentes que permitisse ou o
acesso a funcionalidades disponibilizadas pelo sistema operativo ou pelo menos a
funcionalidades semelhantes Pretende-se com esta aproximacao tornar possıveis
interaccoes entre o desktop e o browser tais como arrastar um ficheiro para um
formulario web de upload de conteudos melhor suporte para o historico do clipboard
ou ainda o acesso ao sistema de ficheiros local Atingir estes objectivos reflecte-se
1NT business state
2
Introducao
num novo paradigma que reune as vantagens das web applications tais como os
updates instantaneos ou o facto de nao ser necessaria nenhuma instalacao e das
desktop applications como por exemplo persistencia no armazenamento de dados
acesso a funcionalidades do sistema operativo ou integracao e interaccao com outras
aplicacoes sejam elas web applications ou desktop applications
13 Ambito
Este projecto foi realizado na Critical Software SA no ambito do Mestrado
Integrado em Engenharia Informatica e Computacao (MIEIC) da Faculdade de En-
genharia da Universidade do Porto (FEUP) entre os meses de Fevereiro e Julho de
2008
14 Objectivos
Sao objectivos deste projecto
1 Estudar e documentar o tema das OWAs acompanhando os ultimos desenvolvi-
mentos nesta materia
2 Analisar o estado da arte fazendo uma analise crıtica e objectiva sobre as
diversas metodologias existentes
3 Implementar uma prova de conceito que permita a execucao offline de uma
web application documentando todo o processo
4 Estudar a possibilidade de permitir interaccao com a aplicacao (insercoes e
alteracoes aos dados) em modo offline
Em resumo o objectivo deste projecto foi estudar documentar e implementar
uma prova de conceito relacionada com o tema Offline Web Applications (OWA)
Este tema embora nao seja totalmente novo ganhou destaque ao longo do ano de
2007 com o surgimento de diversas ferramentas que se destinam a aproximar web
applications das desktop applications
15 Estrutura do documento
Este documento esta organizado em diferentes seccoes apresentando o projecto
numa sequencia logica organizada da seguinte forma
No capıtulo 1 faz-se uma breve apresentacao do conceito OWAs e do contexto em
que surge Apresenta-se tambem a estrutura do documento e definem-se os
termos e acronimos utilizados
3
Introducao
No capıtulo 2 faz-se uma descricao da evolucao das tecnologias que antecedem as
OWAs e das vantagens e desvantagens de cada uma como forma de enquadra-
mento
No capıtulo 3 analisa-se o estado da arte nesta materia Introduzem-se diversas
tecnologias directamente relacionadas com o tema deste projecto exemplos de
aplicacoes que as usam e as razoes que fundamentam as escolhas de tecnologias
efectuadas
O capıtulo 4 contem o desenvolvimento do projecto Analisa-se a plataforma
WOW de gestao integrada de ordens de trabalho a tecnologia escolhida e
a forma como foi utilizada para implementar a capacidade de execucao offline
O capıtulo 5 descreve os resultado obtidos comparando-os com as expectativas
iniciais do projecto e apresenta desenvolvimentos futuros e possibilidades de
continuacaoaplicacao do conhecimento adquirido
No capıtulo 6 apresentam-se as conclusoes
4
Capıtulo 2
Enquadramento do Projecto
Neste capıtulo apresenta-se um breve resumo da evolucao das arquitecturas de
software cliente-servidor e a forma como estas se comparam a evolucao da Inter-
net procurando estabelecer uma analogia entre o percurso de ambas as tecnolo-
gias Compara-se o comportamento e arquitectura dos thin-clients as paginas web
estaticas a evolucao dos fat-clients as paginas interactivas Web 20 e Ajax e
defende-se que as OWA constituem um proximo passo logico e evolutivo aproxi-
mando a web do desktop Referem-se ainda os principais factores que justificam a
importancia das OWAs e a estreita relacao que tem com as Rich Internet Application
(RIA)s
21 Evolucao das arquitecturas de software
Os termos thin-client e fat-client sao utilizados quer para descrever arquitecturas
logicas (de software) quer para descrever arquitecturas fısicas (de hardware) Neste
capıtulo excepto quando seja dada indicacao em contrario estes termos referem-se
sempre a uma arquitectura logica
Adicionalmente quando se trata de arquitecturas cliente-servidor pode-se estu-
dar a arquitectura desenvolvida do sistema como um todo da arquitectura do servi-
dor ou da arquitectura do cliente Para evitar equıvocos em especial na seccao 213
especifica-se em cada caso qual o sistema estudado
211 Thin-clients
Um thin-client e um computador cliente ou software cliente que no contexto
de uma arquitectura cliente-servidor depende de um servidor central para as suas
5
Enquadramento do Projecto
actividades de processamento e proporciona um canal de entrada e saıda de in-
formacao entre o utilizador e o servidor remoto Este termo quando aplicado a
hardware refere-se habitualmente a um computador que se destina a ser utilizado
como cliente de rede sem armazenamento local e com capacidade de processamento
reduzida [Gro02b] mas o conceito que aqui se analisa refere-se a uma arquitectura
de software que remonta ao inıcio das aplicacoes cliente-servidor
No inıcio da historia da computacao terminais ligavam-se directamente a main-
frames responsaveis por todo o processamento Nesta arquitectura era necessario
desenvolver duas aplicacoes distintas uma aplicacao central no servidor (main-
frame) responsavel pela gestao de toda a informacao e por todas as operacoes de
comunicacao e uma aplicacao de visualizacao instalada no cliente (terminal) O
papel destes terminais era apenas disponibilizar ao utilizador um meio de comu-
nicacao (entrada e saıda) e apresentacao dos resultados do servidor Nao tinham
um papel activo no calculo nem na logica de negocio e frequentemente nao tinham
tambem nenhum mecanismo de armazenamento de dados
Como vantagens esta arquitectura apresenta uma reduzida necessidade de con-
figuracao e manutencao do lado do cliente Uma vez que o centro do processamento
e manipulacao de dados ocorre no servidor existe tambem uma centralizacao da
informacao [NJN00] que introduz um ponto crıtico de falha1 Actualizacoes e novas
funcionalidades sao faceis de distribuir uma vez que requerem apenas alteracoes no
servidor [Gro02a]
212 Fat-clients
Contrastando com os thin-clients nesta arquitectura os clientes implementam
ja uma parte da logica de negocio e sao responsaveis pelo processamento de dados
Estes fat-clients vieram responder a necessidade crescente de aplicacoes com um
nıvel de interactividade e capacidade de configuracao maior que as oferecidas pela
arquitectura thin-client descrita na seccao 211 Apesar de manterem a sua de-
pendencia do servidor podem tambem ser executados sem uma conexao activa uma
vez que dispoe de armazenamento de dados local o que lhes confere a capacidade
de persistencia de dados e do estado de execucao entre cada sessao
Foi disponibilizando este controlo sobre o estado da aplicacao bem como acesso
a recursos locais (por exemplo sistema de ficheiros e perifericos) que surgiram as
primeiras verdadeiras desktop applications No entanto cada cliente tinha que ser
separadamente instalado no computador pessoal de cada utilizador que pretendesse
utilizar ou interagir com a aplicacao e uma actualizacao ao servidor implicava in-
variavelmente uma actualizacao manual tambem no cliente Uma vez que nem todos
1NT single point of failure
6
Enquadramento do Projecto
Thin-clients Fat-clientsNao toma parte no processamento dedados nem possui acesso ao sistema deficheiros
Participa activamente no processa-mento de dados recorrendo ao sis-tema de armazenamento local para ar-mazenamento de dados
Nao mantem registo do estado logicoda aplicacao entre duas sessoes de uti-lizacao
O acesso ao armazenamento localpermite-lhe manter registo do estadologico da aplicacao entre duas sessoes
O thin-client nao necessita de qualquerinstalacao estando ldquopronto a utilizarrdquo
E geralmente necessario instalar aaplicacao para poder interagir com oservidor
Qualquer update no servidor reflecte-seimediatamente por todos os clientes
Embora a aplicacao cliente possa aler-tar para existencia de novas versoes asactualizacoes tem que ser manualmenteinstalados pelo cliente
O software do cliente destina-se apenasa apresentacao de dados e comunicacaocom o servidor sendo portanto de sim-ples implementacao
Como o software do cliente toma parteactiva no processamento de dadosa sua implementacao requer cuidadosadicionais
Grande mobilidade uma vez que todaa informacao e mantida no servidor
Parte da informacao podera estar ape-nas do lado cliente pelo que existemalgumas restricoes a sua mobilidade
Tabela 21 Comparacao entre thin-clients e fat-clients
os utilizadores actualizam regularmente as suas aplicacoes o servidor tem que estar
preparado para lidar com versoes antigas2 ou descontinuar os seus servicos a uma
parte da sua comunidade de utilizadores ate que estes actualizem os seus sistemas
Como os utilizadores passam a utilizar os seus recursos locais para armazenamento
de dados as alteracoes que nao sejam sincronizadas com o servidor estao apenas
disponıveis nos seus computadores pessoais o que introduz uma restricao a mobili-
dade
Pode-se afirmar que as vantagens dos thin-clients sao as desvantagens dos fat-
clients e que as vantagens dos fat-clients sao as vantagens dos thin-clients tal como
se ilustra na Tabela 21
213 Arquitecturas cliente-servidor
Introduzidos os termos thin-client e fat-client interessa reafirmar que ambos
podem ser vistos como arquitecturas cliente-servidor Um cliente define-se como
um solicitador de servicos e um servidor como um prestador de servicos tal como
definido por [Sch96] e [Sad97]
2NT backward compatibility
7
Enquadramento do Projecto
As arquitecturas cliente-servidor sao categorizadas pela modularizacao com que
sao desenhadas sendo consideradas as seguintes camadas
1 Interface grafica (front-end) atraves da qual os utilizadores interagem com
a aplicacao Quando este modulo e implementado separadamente dos outros
dois constitui uma aplicacao thin-client por si so uma vez que nao implementa
regras de negocio (embora possa definir validacoes de formularios de insercao de
dados por exemplo) A informacao introduzida pelo utilizador e enviada para
o servidor que processa o seu pedido e retorna uma resposta Este processo
repete-se ate que o utilizador atinja o seu objectivo ou se desligue do sistema
2 A logica de negocio tambem designada por camada intermedia que imple-
menta as regras de aceitacao e validacao de todos os dados introduzidos pelo
utilizador E tambem a plataforma de comunicacao que une a camada superior
de visualizacao com a camada de acesso a dados
3 A camada de dados inclui quer o sistema de persistencia de dados onde sao
armazenados os dados relevantes como tambem os mecanismos necessarios
para a sua pesquisa seleccao e alteracao
Os thin-clients quando observados no seu conjunto de cliente e servidor podem
ser vistos quer como sistemas de duas camadas quer como sistemas de tres camadas
dependendo apenas da forma como o servidor for implementado No caso de na
implementacao do servidor nao se distinguir a camada de acesso a dados da camada
da logica de negocio sao designados por sistemas de duas camadas Caso seja feita
esta distincao sao designados por sistemas de tres camadas Ambos os casos sao
ilustrados na Figura 21
Historicamente os fat-clients eram implementados numa arquitectura em duas
camadas Possuıam apenas um modulo de visualizacao de dados designado por
camada de interface e um modulo que implementava toda a logica de negocio e
regras de acesso a base de dados No entanto com a introducao de ligacoes mais
rapidas e de computadores pessoais com maior capacidade de processamento e so-
bretudo devido a complexidade crescente das aplicacoes a logica de negocio e a
camada de acesso a dados tornaram-se independentes Este modelo e designado por
arquitectura em tres camadas e e ilustrado na Figura 22
22 Evolucao na Internet
Ao analisar a evolucao das arquitecturas das aplicacoes desenvolvidas para a
Internet podemos encontrar um paralelismo com a historia da arquitectura de soft-
ware
8
Enquadramento do Projecto
Figura 21 Arquitectura de um sistema thin-client em duas camadas (a esquerda) e emtres camadas (a direita) Note-se a inclusao do servidor (mainframe) na definicao dascamadas desta arquitectura devido a forte dependencia cliente-servidor
221 Paginas web estaticas
Uma pagina web estatica devolve sempre a mesma resposta a todos os pedidos
para todos os utilizadores e em qualquer contexto utilizando o hipertexto como
forma de ligacao entre diversas paginas estaticas
A informacao e armazenada num servidor e o papel do cliente e apenas a apre-
sentacao da informacao Esta forma de disponibilizacao de informacao pode assim
ser comparada com os thin-clients descritos na seccao 211 o utilizador acede a
um website estatico para visualizar informacao sem que o cliente tome parte no
processamento A unica diferenca e que no caso da web estatica a informacao ap-
resentada e sempre a mesma enquanto que nos thin-clients era frequente existir a
possibilidade de insercao de dados no cliente e apos o seu processamento servidor
nova informacao poderia ser apresentada O hipertexto e utilizado para ligar as
paginas entre si numa rede de conteudos relacionados e a navegacao sıncrona era
feita atraves de cliques do rato a cada clique uma nova pagina era apresentada
Este modelo sıncrono e ilustrado na Figura 23
222 Paginas web interactivas e paginas web dinamicas
O JavaScript e uma linguagem interpretada de scripting que tem os browsers
como principal ambiente de acolhimento Os browsers utilizam uma Application
9
Enquadramento do Projecto
Figura 22 Arquitectura de um fat-client em duas camadas (a esquerda) e em tres camadas(a direita)
Programming Interface (API) publica para criar ldquoobjectosrdquo responsaveis por reflectir
e disponibilizar o Document Object Model (DOM) para o motor de JavaScript
A utilizacao mais frequente desta linguagem e a escrita de funcoes que sao em-
bebidas ou incluıdas em paginas web e que interagem com o DOM Uma vez que o
JavaScript e executado localmente (na maquina do cliente e nao no servidor) e capaz
de responder rapidamente a accoes do utilizador tornando a execucao de aplicacoes
no browser mais fluıdas o JavaScript pode tambem detectar accoes do utilizador
que o HTML nao pode tal como o pressionar de uma tecla
Em Dezembro de 1995 a Netscape Communications adicionou suporte para o
JavaScript no browser Netscape Navigator3 e em Agosto de 1996 o browser Internet
Explorer4 da Microsoft passou a tambem a suportar uma versao semelhante desta
linguagem (hoje todos os principais browsers suportam esta tecnologia)
Esta inovacao permitiu tornar os websites mais interactivos mas a sua utilizacao
esteve confinada apenas a este proposito durante um longo perıodo As paginas
passaram a responder activamente a accoes do utilizador (sendo uma das utilizacoes
3Netscape Communications ndash httpbrowsernetscapecom4Microsoft Internet Explorer ndash httpwwwmicrosoftcomwindowsproductswinfamilyie
10
Enquadramento do Projecto
mais vulgares a validacao de formularios) mas continuaram essencialmente estaticas
O JavaScript ainda nao era nesta altura utilizado para processar dados
Tambem nesta altura (1995ndash96) surgiram linguagens server-side como o PHP
Hypertext Preprocessor (PHP) e Active Server Pages (ASP) e o servidor passou a ter
um processamento de dados introduzidos pelo utilizador mais activo Generalizaram-
se as paginas dinamicas capazes de responder a insercao de dados ou outros pedidos
determinados por accoes do utilizador As paginas tornaram-se aplicacoes web ap-
plications
Uma definicao tradicional de web application e um conjunto de paginas web
logicamente agrupadas e geridas por uma unica entidade que tem como pontos de
entrada formularios de insercao de dados (web forms) Uma web application nao e
mais do que uma aplicacao que e acedida atraves de um browser Tem geralmente
uma arquitectura logica em tres (interface logica de negocio e camada de dados)
camadas e estao armazenadas num servidor
Ha dois tipos de web applications
bull Orientadas a apresentacao Sao web applications que geram paginas web in-
teractivas constituıdas por varios tipos de linguagens de anotacao (por exem-
plo HTML eXtensible Markup Language (XML)) e que apresentam conteudo
dinamico como resposta a pedidos efectuados pelo utilizador
bull Orientadas aos servicos Uma web application orientada aos servicos imple-
menta o ponto de acesso para um ou mais de um web service Sao geralmente
clientes de service oriented web applications
Uma vantagem significativa de implementar uma web application de forma a
suportar as funcionalidades padrao dos browsers e que estas terao o mesmo com-
portamento independentemente da plataforma e do browser a partir do qual serao
acedidas No entanto diferentes implementacoes de browsers devido a diferentes
interpretacoes dos padroes definidos tornam por vezes esta tarefa um pouco mais
complicada existindo inclusivamente na web guioes de compatibilidade para os difer-
entes browsers como [Smi07]
223 Web 20 e Ajax
O termo web 20 descreve uma tendencia de utilizacao e de design observada
na World Wide Web (WWW) com o objectivo de melhorar a criatividade partilha
de informacao e principalmente a colaboracao entre utilizadores Estes conceitos
levaram ao desenvolvimento e evolucao de comunidades online tais como redes so-
ciais wikis e blogues
11
Enquadramento do Projecto
O termo tornou-se mais conhecido apos a primeira conferencia OrsquoReilly Media
Web 20 em 2004 e apesar de sugerir uma nova versao da WWW nao se refere a
qualquer evolucao tecnologica mas apenas a alteracoes a forma como os utilizadores
se servem da web De acordo com Tim OrsquoReilly [OrsquoR06] ldquoWeb 20 e uma revolucao
na industria do software causada pela adopcao da web como uma plataforma e pela
tentativa de entendimento das regras para o sucesso nesta nova plataformardquo
O desenvolvimento da Web 20 serve-se muitas vezes de um outro conceito Ajax
O conceito que hoje conhecemos como Ajax muitas vezes incorrectamente de-
scrito como uma tecnologia foi originalmente criado para permitir o desenvolvimento
de web applications que se assemelhassem ainda mais a aplicacoes de desktop Este
conceito foi melhor descrito por [Gar05] como um conjunto de varias tecnologias
que podem ser utilizadas para melhorar a experiencia do utilizador de uma dada
web application introduzindo a capacidade assıncrona de envio de pedidos ou da
recepcao assıncrona de respostas As tecnologias mais frequentemente envolvidas
sao
bull eXtensible HyperText Markup Language (XHTML) e Cascading Style Sheets
(CSS) padrao para a apresentacao
bull interaccao dinamica atraves do DOM
bull troca e manipulacao de dados utilizando XML e eXtensible Stylesheet Lan-
guage Transformation (XSLT) ou JavaScript Object Notation (JSON)
bull pedidos assıncronos utilizando XMLHttpRequest [vK08]
bull JavaScript utilizado para integrar todas estas tecnologias
E importante frisar que o Ajax nao e um produto nem uma tecnologia E um
termo que descreve a utilizacao de um conjunto de tecnologias para o desenvolvi-
mento de web applications com um elevado grau de interactividade Comparativa-
mente as web applications tradicionais o Ajax introduz uma camada de visualizacao
diferente em tres importantes pontos
1 Do lado do cliente existe um motor que serve de intermediario entre a interface
da aplicacao e o servidor
2 A actividade do utilizador despoleta chamadas JavaScript em vez de um pedido
de pagina directamente ao servidor
3 Informacao codificada em XML em vez de paginas HTML e trocada entre o
servidor e o cliente
12
Enquadramento do Projecto
Isto significa que as paginas que utilizam Ajax contem um motor do lado do
cliente composto por um conjunto de funcoes JavaScript responsavel pela comu-
nicacao com o servidor e por actualizar a interface com o resultado dessa mesma
comunicacao
Na Figura 23 ilustra-se a natureza assıncrona do Ajax quando comparada com
as web applications tradicionais Como se pode observar adicionando um mecan-
ismo Ajax a uma web application eliminam-se diversos tempos de espera associados
a comunicacoes com o servidor uma vez que a interface nao fica ldquobloqueadardquo a es-
pera da resposta Obtem-se assim aplicacoes com um comportamento mais fluido
eliminando tempos de espera entre cada ldquocliquerdquo e melhorando a experiencia do
utilizador
23 Offline Web Applications
A informacao grafica (bem como folhas de estilo e scripts) tais como as ima-
gens que constituem o visual de uma web application e ja tratada de forma especial
pelos cada vez mais avancados sistemas de cache (armazenamento temporario) dos
browsers Mas estes nao sao ainda capazes de guardar conteudo criado pelo uti-
lizador nem de apresentar informacao independentemente do estado da ligacao
Numa altura onde se fala de servicos de Internet wireless municipalizados [Kha]
comunicacoes 3G e ligacoes de banda larga a alta velocidade a ligacao a rede global
continua a nao estar permanentemente disponıvel para os utilizadores Na WWW
encontra-se uma importante parte da informacao e das aplicacoes utilizadas para
criar e editar conteudos Por vezes informacao vital para a produtividade pode
desaparecer subitamente do mapa de acesso de um utilizador quando este entra no
metro num aviao ou mesmo quando se desloca para uma cidade ou paıs diferente
do habitual onde nao subscreve um plano de acesso que lhe garanta a ligacao
Permitir o acesso offline a estes recursos assume assim a sua importancia porque
permitira estender o alcance da informacao a locais onde nunca esteve antes e per-
mitira tambem melhorar o desempenho das web applications colocando informacao
mais perto dos utilizadores reduzindo a transferencia de dados apenas ao essencial
24 Comparacao
Nas evolucoes descritas neste capıtulo 2 pode-se observar que existe um par-
alelismo entre a evolucao das arquitecturas tradicionais cliente-servidor e a evolucao
a que se assiste na web O comportamento e arquitectura dos thin-clients assemelha-
se ao das paginas estaticas no sentido em que o browser nao toma parte em qualquer
13
Enquadramento do Projecto
processamento e serve apenas como uma plataforma de interaccao com o servidor
tal como os clientes descritos na seccao 211
A sua proxima evolucao os fat-clients trouxeram parte da capacidade de pro-
cessamento para o lado do cliente Na web foi tambem esta a inovacao tecnologica
a que se assistiu com a evolucao das tecnologias que permitiram a criacao de ver-
dadeiras aplicacoes e com a introducao do Javascript no browser dando ao cliente
a capacidade de processamento de dados A necessidade da separacao do codigo
em camadas logicas advem da crescente complexidade das web applications Esta
pratica permite entre outras coisas melhorar o processo de desenvolvimento e a
capacidade de manutencao de uma aplicacao
Os fat-clients tem tambem a capacidade de armazenamento de dados o que
permite a persistencia de informacoes entre duas sessoes e que algumas operacoes
sejam executadas sem a necessidade de comunicacao com o servidor Este facto pode
tambem ser uma realidade nas web applications com a adopcao das tecnologias OWA
Neste momento assiste-se a uma utilizacao cada vez maior da web como uma
plataforma de desenvolvimento A capacidade de cooperacao na edicao de conteudos
e a mobilidade proporcionada por esta plataforma sao os principais factores que
alimentam esta mudanca e pela primeira vez as aplicacoes tradicionais tem com-
peticao vinda de web applications A prova do reconhecimento da web como plataforma
de desenvolvimento pode ser retirada da aposta de empresas como a Adobe e Mi-
crosoft que lancaram publicamente ferramentas web complementares a produtos
seus tradicionalmente associados ao desktop ndash Acrobatcom5 e Microsoft Office
Live6 Dotar estas web applications da capacidade de execucao offline significa
aproximar a web e o desktop reunindo ldquoo melhor de dois mundosrdquo
As vantagens da mobilidade possıvel atraves da web a cooperacao na criacao e
edicao de conteudos e a possibilidade de utilizar aplicacoes sempre actualizadas e
sem necessidade de instalacao sao algumas das principais vantagens que promovem
esta mudanca que devido as preocupacoes associadas a usabilidade e experiencia do
utilizador esta fortemente associada ao desenvolvimento de Rich Internet Applica-
tion (RIA)s
5Adobe Acrobatcom httpwwwacrobatcom6Microsoft ndash httpsmallbusinessofficelivecom
14
Enquadramento do Projecto
Figura 23 Comparacao do modelo de web aplications sıncrono paginas estaticas e in-teractivas abordados nas seccoes 221 e 222 com o modelo de web applications Ajax(assıncrono) abordado na seccao 223 Figura adaptada de http www adaptivepath
com
15
Enquadramento do Projecto
16
Capıtulo 3
Estado da arte
Apesar de o conceito das OWAs nao ser absolutamente novo as tecnologias que
o suportam sao recentes Neste capıtulo descrevem-se quatro tecnologias que foram
tidas como principais candidatas para o desenvolvimento deste projecto Descrevem-
se ainda alguns exemplos de web applications que disponibilizam actualmente fun-
cionalidades offline e o processo da escolha da tecnologia a utilizar neste projecto
31 Gears
O Gears1 e uma extensao as funcionalidades do browser introduzido pelo Google
que tem como principal objectivo tornar possıvel a visualizacao de paginas de Inter-
net mesmo sem uma conexao disponıvel Encontra-se disponıvel para as platafor-
mas Windows Macintosh e Linux e oferece uma API de Javascript que permite
a scripts aceder a um mecanismo de armazenamento local baseado numa base de
dados SQLite
311 Arquitectura
Esta ferramenta e constituıda por tres componentes principais
bull LocalServer mdash Intercepta pedidos de paginas web e serve-as localmente
bull Database mdash Uma base de dados relacional construıda sobre SQLite
bull WorkerPool mdash Permite executar operacoes de computacao de uma forma
assıncrona sem afectar a capacidade de resposta e fluidez de execucao da web
application Assemelham-se a processos
1Google Inc ndash Mais informacao em httpgearsgooglecom
17
Estado da arte
LocalServer
O modulo LocalServer e uma cache de Uniform Resource Locators (URLs)
controlada pela web application Quando nao existe uma ligacao a Internet e e
feito um pedido para um URL presente nesta cache o LocalServer intercepta-o e
responde ao pedido localmente a partir do disco rıgido do utilizador A aplicacao
pode utilizar dois tipos diferentes de armazenamento local de URLs
bull ResourceStore ndash serve para capturar URLs utilizando exclusivamente a API
de Javascript disponibilizada para o efeito Uma aplicacao podera criar e
utilizar diversos ResourceStores simultaneamente para capturar ficheiros de
dados que necessitam de ser enderecados por um URL tal como um ficheiro
PDF ou uma imagem
bull ManagedResourceStore ndash serve para capturar um conjunto de URLs que estao
relacionados e que sao declarado num ficheiro de manifesto (especificado em
JSON) e que sao automaticamente actualizados O ManagedResourceStore
permite que o conjunto de recursos necessarios para correr uma web application
seja capturado e mantido actualizado automaticamente
A principal diferenca entre estes dois tipos de armazenamento de URLs e a forma
como sao actualizados os seus conteudos Os conteudos de um ManagedResourceStore
sao actualizados sempre que a versao contida no ficheiro de manifesto for alterada
enquanto que os conteudos de um ResourceStore nunca sao actualizados automati-
camente mas apenas quando for explicitamente ordenado pela aplicacao
O LocalServer e capaz de interceptar e servir localmente pedidos de HTTP e
HTTPS sempre que se reunam as seguintes condicoes
1 O URL encontra-se armazenado num ResourceStore ou ManagedResourceStore
2 O sistema de armazenamento local encontra-se activo (enabled = true) Se
o sistema de armazenamento local tiver o atributo requiredCookie o pedido
devera conter um cookie que lhe corresponda
O LocalServer nao necessita de monitorizar o estado da ligacao para atender aos
pedidos Na verdade sempre que as condicoes previamente enunciadas se verificarem
o LocalServer interceptara os pedidos e independentemente do estado da ligacao
a Internet servi-los-a a partir do disco rıgido local Cabera a aplicacao definir qual
o modo em que pretende executar um pedido (online ou offline) definindo o valor
de verdade da propriedade enabled
18
Estado da arte
Database
O modulo Database permite guardar dados da web application assegurando a
sua persistencia Os dados sao guardados de forma relacional no disco rıgido do uti-
lizador2 de acordo com o modelo de seguranca estabelecido pelo Gears3 significando
que uma aplicacao nao pode aceder a conteudos fora do seu domınio
WorkerPool
Nos web browsers uma operacao pesada de computacao pode tornar a interface
lenta e tornar menos agradavel a experiencia do utilizador O modulo WorkerPool
permite correr operacoes em background sem bloquear a interface com o utilizador
Os scripts executados numa WorkerPool nao activam os mecanismos de seguranca
do browser que mostram a mensagem ldquoA script on this page may be busy or may
have stopped respondingrdquo
O WorkerPool comporta-se como um conjunto de processos em vez de threads
Os Workers nao partilham qualquer estado de execucao o que significa que uma
alteracao a uma variavel num Worker nao afecta em nada a execucao de outro
Worker Alem disso os Workers nao herdam automaticamente nenhum codigo dos
seus pais Cada Worker e membro de um WorkerPool e os Workers podem in-
teragir entre si enviando mensagens em formato de texto ou JSON No entanto ha
tambem algumas limitacoes os Workers nao tem acesso ao DOM e objectos como
window ou document nao se encontram acessıveis Isto e consequencia de os Workers
nao partilharem o estado de execucao Mas tem acesso a todas as funcoes built-in
do Javascript A maioria das funcionalidades do Gears pode tambem ser acedida
atraves de uma variavel global especial definida como googlegearsfactory Para
outras funcionalidades especıficas os Workers podem ldquopedirrdquo a pagina principal para
continuar a execucao atraves do envio de mensagens
Outras funcionalidades
bull HttpRequest ndash Este modulo implementa a especificacao W3C XmlHttpRe-
quest definida em [vK08] tornando-a disponıvel para os workers e para a
pagina principal
bull Timer ndash Este modulo implementa a especificacao de timers tal como descrito
por [Hic08] e torna-os disponıveis para os workers e para a pagina principal
2Consultar httpcodegooglecomapisgearsapi_databasehtmldirectories3Consultar httpcodegooglecomapisgearssecurityhtml
19
Estado da arte
bull Factory ndash Esta classe e utilizada para instanciar todos os outros objectos da
API do Gears atraves do seu metodo create Este metodo pode ser utilizado
com os seguintes parametros
ndash betadatabase
ndash betahttprequest
ndash betalocalserver
ndash betatimer
ndash betaworkerpool
312 Goggle Gears em dispositivos moveis
O Gears esta tambem disponıvel em dispositivos Windows Mobile 5 e 6
Os dispositivos moveis estao pela sua natureza frequentemente desconectados
da Internet Mesmo quando possuem uma ligacao as latencias na transferencia de
dados em redes moveis tornam as aplicacoes pouco fluıdas mas o Gears permite
ultrapassar este obstaculo
O Gears funciona exactamente da mesma forma em dispositivos moveis equipados
com o Windows Mobile 5 e 6 como num computador comum Se uma aplicacao tiver
sido implementado com suporte para o Gears entao tambem estara preparada para
ser executada num dispositivo movel mas as limitacoes dos browsers disponıveis
para dispositivos moveis tem que ser consideradas Isto significa prever as condicoes
que permitam uma boa usabilidade devido aos pequenos ecras destes dispositivos
bem como o seu suporte limitado dos padroes do DOM CSS e JavaScript
32 Adobe AIR
O Adobe AIR4 e um runtime compatıvel com diversos browsers e sistemas opera-
tivos que pretende dar aos programadores a possibilidade de combinar diversas tec-
nologias de producao de conteudos para a Internet no desenvolvimento de Rich Inter-
net Application (RIA)s O Adobe AIR mantem uma relacao com o browser mas es-
tende as suas capacidades e tecnologias permitindo o desenvolvimento de aplicacoes
tambem para o ambiente de trabalho com janelas em tudo semelhantes as do sis-
tema operativo Segundo a Adobe o objectivo e complementar o browser dando
aos utilizadores (mas essencialmente aos programadores e equipas de desenvolvi-
mento) a escolha sobre como distribuir as suas aplicacoes Para este efeito o Adobe
AIR tem uma aproximacao diferente do Gears Em vez de ldquoestenderrdquo o browser
acrescentando-lhe funcionalidades o AIR permite tambem o desenvolvimento de
4Adobe - httpwwwadobecomproductsair
20
Estado da arte
aplicacoes que se destinam a ser executadas fora do ambiente do browser mas uti-
lizando as tecnologias comuns da Internet (por exemplo HTML CSS JavaScript
Flash Flex)[CDGH08]
A utilizacao desta tecnologia permite utilizar o browser ou o proprio runtime
Adobe AIR como plataforma de execucao da aplicacao
Na Tabela 31 faz-se uma comparacao das funcionalidades disponıveis de acordo
consoante se escolha o browser ou o desktop como plataforma base para a aplicacao
Uma vez que as aplicacoes Adobe AIR na plataforma desktop tem um caracter
persistente (sao instaladas no computador do utilizador) o Adobe AIR tem um
modelo de seguranca que se assemelha com o das tradicionais aplicacoes desktop
[Ada08] Este modelo e analisado nas seccoes 321 e 322 O ambiente em que
e executado o browser e restringido a execucao de web applications que podem
ser de varias origens (incluindo de origens anonimas ou sem confianca) O Adobe
AIR proporciona acesso a capacidades como acesso a ficheiros que necessitam da
confianca do utilizador
bull HTML ndash O desenvolvimento de aplicacoes para o Adobe AIR pode ser feito
com recurso a tecnologias de HTML e Ajax comuns utilizando as linguagens
de markup existentes distribuıdas como texto e interpretadas em execucao
(runtime)
bull Flash ndash Outra alternativa sera a utilizacao da linguagem Flash Permite a
renderizacao de graficos vectoriais e audiovıdeo com suporte nativo Utiliza
ActionScript para adicionar maior interactividade com o utilizador
bull Flex ndash O Flex e uma framework open source para o desenvolvimento de RIAs
usando Flash As aplicacoes Flex sao na realidade Flash sendo a principal
diferenca o ambiente de desenvolvimento
Como resultado uma aplicacao AIR podera ser implementada
bull Baseada em Flash ou Flex (aplicacoes cujo conteudo base e em ShockWave
Flash (SWF))
bull Baseada em Flash ou Flex tambem com HTML ou Portable Document Format
(PDF) Aplicacoes cujo conteudo de base e em FlashFlex (SWF) com HTML
(HTML JavaScript CSS) ou conteudo PDF incluıdo
bull Baseada em HTML Aplicacoes cujo conteudo base e em HTML Javascript
CSS
bull Baseada em HTML utilizando tambem FlashFlex ou PDF
21
Estado da arte
Os utilizadores interagem com uma aplicacao AIR da mesma forma que interagem
com outras aplicacoes com janelas nativas do seu sistema operativo O runtime e
instalado uma vez no computador do utilizador e a partir desse momento todas as
aplicacoes AIR terao o mesmo aspecto que qualquer outra aplicacao para o desktop
321 Seguranca
Permitir que uma web application aceda ao disco de armazenamento do utilizador
pode comprometer seriamente a sua seguranca Neste sentido o Adobe AIR tem
suporte para assinaturas digitais (Secure Sockets Layer (SSL)) que podem ser com-
pradas pelas equipas de desenvolvimento que o desejem e cujos certificados serao
apresentados ao utilizador no momento da instalacao Um outro aspecto ainda
relativo a seguranca e o mecanismo de isolamento de cada ambiente (sandbox )
322 Assinatura do codigo
O runtime AIR exige que todas as aplicacoes estejam digitalmente assinadas As
assinaturas digitais de codigo sao um processo que visa garantir a integridade da
aplicacao e a identidade do seu autor no momento da instalacao As equipas de
desenvolvimento podem ldquoassinarrdquo uma aplicacao utilizando um certificado atribuıdo
por uma Entidade Certificadora (Certification Authority) ou atraves de um certifi-
cado individual (self signed certificate) Neste momento o Adobe AIR suporta como
entidades certificadoras a Verisign e a Thawte [Ado08]
O instalador apresenta o nome de quem publica a aplicacao quando o codigo tiver
sido assinado com um certificado que apresente confianca ou que esteja encadeado
com um certificado que tenha ja sido aceite no computador em que se esta a instalar
a aplicacao
As equipas de desenvolvimento podem tambem assinar as aplicacoes com um
certificado auto-atribuıdo (um certificado criado por elas proprias) mas neste caso
o instalador apresentara estas aplicacoes como sendo de uma origem nao verificada
O AIR utiliza a infraestrutura publica de chaves [Ent07] suportada pelo arquivo
local do sistema operativo Para que a origem da aplicacao seja reconhecida o
computador onde a aplicacao AIR esta a ser instalada tem que confiar directamente
no certificado que foi utilizado para assinar a aplicacao ou confiar num certificado
que esteja num encadeamento logico de certificados confiados e que se ligue desta
forma ao certificado utilizado para assinar a aplicacao
Todas as aplicacoes AIR tem caracterısticas em comum independentemente da
tecnologia utilizada para o seu desenvolvimento (HTMLFlexFlash) No ambito
de uma aplicacao AIR existem um conjunto de APIs que estao disponıveis e que
tornam possıvel o acesso ao sistema local (leitura e escrita) e a recursos de rede que
22
Estado da arte
de outra forma nunca estariam acessıveis a partir de uma web application comum
Cada aplicacao AIR possui tambem diferentes nıveis de isolamento chamados secu-
rity sandboxes dependendo do tipo de conteudo que esta a ser carregado e do seu
objectivo
bull Isolamento ao nıvel da aplicacao5 ndash E a raiz de cada aplicacao AIR Este
nıvel de isolamento permite o acesso a APIs privilegiadas e especıficas do
AIR Em contrapartida e negado o acesso a algumas APIs que poderiam ser
facilmente utilizadas de forma maliciosa contra o utilizador final Importacao
dinamica de conteudos remotos e geralmente proibido e as tecnicas e mecan-
ismos de geracao dinamica de codigo sao fortemente restringidas Apenas
conteudo carregado directamente da directoria base da aplicacao podera ser
colocado neste nıvel de isolamento
bull Isolamento nao especıfico da aplicacao6 ndash contem todo o outro conteudo
que nao tenha sido carregado directamente para o isolamento da aplicacao
Isto inclui conteudo local e remoto Este tipo de conteudo nao tem acesso
directo as APIs do AIR e rege-se pelas mesmas regras tal como se tivesse sido
carregado por um browser a partir da mesma localizacao (por exemplo HTML
carregado a partir de um domınio remoto comporta-se da mesma forma que se
fosse acedido a partir do browser)
33 Mozilla Prism
331 XML User Interface Language
O eXtensible User Interface Language (XUL) e uma linguagem de anotacao
baseada em XML desenvolvida pela Mozilla Foundation que opera em aplicacoes
Mozilla multi plataforma tal como o Firefox O motor Gecko e a unica imple-
mentacao completa desta linguagem que foi desenhada sobre padroes web comuns
como CSS JavaScript e o DOM e permite o desenvolvimento de interfaces graficas
utilizando elementos pre-definidos tais como window box page textbox radio
button entre outros Infelizmente o XUL nao possui qualquer especificacao formal
ou implementacoes de inter-operabilidade para outros motores que nao o Gecko No
entanto a sua implementacao e licenciada em codigo aberto pelas licencas GNU Gen-
eral Public License (GPL) GNU Lesser General Public License (LGPL) e Mozilla
Public License (MPL)
Enunciam-se algumas caracterısticas desta linguagem
5NT application sandbox6NT non-application sandbox
23
Estado da arte
Liguagem de anotacao poderosa baseada em componentes (widgets) O ob-
jectivo do XUL e permitir a construcao de aplicacoes multi-plataforma em
claro contraste com o Dynamic HyperText Transfer Protocol (DHTML) que se
destina ao desenvolvimento de paginas web Por esta razao o XUL esta orien-
tado a componentes tais como janelas botoes e etiquetas em vez de paginas
cabecalhos de texto e ligacoes de hipertexto Investir tempo e esforco para
atingir este mesmo resultado em aplicacoes baseadas em DHTML compromete
frequentemente a complexidade e desempenho da aplicacao
Baseado em padroes O XUL e um dialecto XML baseado no padrao W3C XML
10 As aplicacoes escritas em XUL sao tambem baseadas em especificacoes
W3C adicionais como HTML 40 CSS DOM nıvel 1 e 2 JavaScript 15
incluindo ECMA-262 Edition 3 (ECMAscript)
Portabilidade entre plataformas Tal como HTML o XUL foi desenhado para
ser independente da plataforma em que e utilizado tornando as aplicacoes
facilmente portaveis entre sistemas operativos nos quais o Mozilla e suportado
Uma vez que o XUL oferece um nıvel de abstraccao dos componentes graficos
de interface que disponibiliza implementa a premissa ldquoum codigo para todas
as plataformasrdquo A interface grafica de todos os produtos centrais Mozilla
(browser instant messenger livro de enderecos) e escrita em XUL com um
unico codigo base que suporta todas as plataformas Mozilla
Separacao entre o nıvel de apresentacao e a logica de negocio Uma das
maiores preocupacoes no desenvolvimento para a Internet e a forte ligacao
entre estas duas camadas (interface e logica) Isto constitui um problema sig-
nificativo no desenvolvimento de grandes aplicacoes especialmente quando o
desenvolvimento e feito em ambientes de equipa porque as capacidades de de-
senvolvimento destas duas partes da aplicacao estao muitas vezes espalhadas
por diferentes elementos O XUL permite uma clara distincao entre a definicao
da aplicacao cliente e da logica de implementacao (XUL eXtensible Binding
Language (XBL) e JavaScript) apresentacao (CSS e imagens) internacional-
izacao (Document Type Definitions (DTDs) e etiquetas de texto em lınguas
especıficas guardados em ficheiros properties) O esquema grafico e apre-
sentacao de uma aplicacao XUL pode ser alterado de forma independente da
sua logica ou implementacao e a aplicacao pode ainda ser traduzida (interna-
tionalization) de forma independente da sua logica implementacao ou apre-
sentacao Este grau de separacao resulta em aplicacoes que sao mais faceis de
manter pelos programadores e facilmente adaptadas por designers e tradutores
24
Estado da arte
Facil adaptacao Outro benefıcio que advem do nıvel de separacao entre logica
de negocio e apresentacao oferecido pelo XUL e a facilidade com que se pode
adaptar uma aplicacao para diferentes clientes ou grupos de utilizadores Um
programador pode utilizar a mesma aplicacao base e adapta-la consoante as
necessidades atraves de diferentes temas (skins) e ficheiros de lınguas Desta
forma uma aplicacao escrita e desenvolvida em Ingles pode ser rapidamente
traduzida para Portugues e distribuıda com outra aparencia mais apropriada
ao cliente alvo
332 Prism
O Mozilla Prism e um browser simplificado e ldquointerpretadorrdquo de XUL (tambem
designado por XULRunner) que acolhe web applications sem a interface grafica ha-
bitual de um browser Baseia-se num conceito designado por Site Specific Browser
(SSB) Um SSB e uma aplicacao com um browser embebido desenhado para exe-
cutar apenas uma web application Nao possui os menus e barras de ferramentas
habituais Um SSB tem uma integracao com o sistema operativo e com o desktop
muito mais estreita do que uma web application acedida atraves de um browser uma
vez que e executado em janela propria
O Prism resulta de uma experiencia da Mozilla e visa reduzir as diferencas entre
as desktop applications tradicionais e as web applications Um dos aspectos focados e
a experiencia do utilizador Numa apresentacao oficial e dito que ldquo[o Prism] pretende
ser uma ponte entre as diferencas que existem entre as aplicacoes tradicionais de
desktop e as web applications explorando novos modelos de usabilidade enquanto
que a linha que as separa se continua a definirrdquo [Lab07]
34 HTML 5
A especificacao HTML 5 [Hic08] que se encontra em fase de desenvolvimento
pelo grupo WHATWG pretende ser uma norma de substituicao dos padroes HTML
4 XHTML 1x e do DOM2 HTML Uma das propriedades que o distingue das tec-
nologias que pretende substituir e precisamente o suporte para OWA e armazena-
mento de dados no cliente de uma forma relacional Nao sendo propriamente uma
tecnologia ndashmas antes uma especificacao ndashe aqui mencionada por ter servido como
referencia a diversas implementacoes de funcionalidades offline e por se considerar
que venha a ter um impacto significativo nas implementacoes de diversos browsers
Dion Almaer defendeu no seu blogue que o Gears era uma implementacao do
HTML 5 No seu artigo ldquoGears as a bleeding-edge HTML 5 implementationrdquo [Alm08]
o autor diz que ambos ndasho Gears e o HTML 5 ndashpretendem dar a web caracterısticas
25
Estado da arte
semelhantes e nao encontrar motivo de ldquocompeticaordquo entre as duas mas que en-
quanto o HTML 5 e uma especificacao o Gears e uma implementacao
No entanto tambem e verdade que o HTML 5 cobre muitos outros pontos para
alem das OWA que saem completamente fora do ambito do Gears Se esta es-
pecificacao atingir um estado de maturidade que possibilite a sua adopcao pelos
principais browsers tornando nativo do browser o suporte OWA entao deixara de
fazer sentido a existencia de uma extensao como o Gears
A especificacao HTML 5 disponibiliza duas APIs relevantes para o tema das
OWA
1 Uma base de dados baseada em SQL que permite o armazenamento de dados
do lado do cliente
2 Uma ldquocacherdquo HTTP que garante a disponibilidade das aplicacoes mesmo quando
o utilizador nao possui uma ligacao a Internet
Estas caracterısticas sao as bases da tecnologia das OWA e tem correspondencia
com os pontos analisados nas seccoes 311 e 311
35 Web applications que usam funcionalidades offline
Nesta seccao apresentam-se algumas web applications que actualmente disponi-
bilizam funcionalidades offline Estas aplicacoes foram escolhidas para uma analise
mais pormenorizada por utilizarem o Gears que tal como descrito na seccao 4 foi
a tecnologia escolhida para o projecto
351 Google Reader e Google Docs
O Google Reader7 e um leitor de feeds RSS Permite gerir a subscricao de varios
sites simultaneamente que disponibilizem conteudos neste formato e foi a primeira
web application da Google com uma versao offline publicamente acessıvel (desde
Junho de 2007)
O Google Reader implementa o modo ldquoutilizador deciderdquo oferecendo na sua
interface um botao que permite alternar entre os modos online e offline
O Google Docs8 e uma web application que permite a criacao e edicao de doc-
umentos de texto folhas de calculo e apresentacoes Era ja publico desde Janeiro
de 2008 que o Google estava a desenvolver uma versao OWA desta aplicacao mas o
acesso a uma versao experimental so foi possıvel a partir de 31 de Maio de 2008
7Google Reader - httpreadergooglecom8Google Docs - httpdocsgooglecom
26
Estado da arte
A implementacao das funcionalidades offline nestas duas aplicacoes seguiu difer-
entes aproximacoes principalmente porque o Google Reader apresenta ao utilizador
informacoes que sao fornecidas por fontes externas enquanto que no Google Docs
a informacao e criada e editada pelo utilizador sobre a forma de documentos
A diferente origem da informacao implica que no Google Reader seja necessario
prever casos de excepcao tal como existirem demasiados itens que necessitam de
ser transferidos para o cliente Nao observar este ponto causa um problema grave
de usabilidade e para evitar tempos de espera demasiado longos e uma interface
com pouca capacidade de resposta as accoes do utilizador o Google Reader apenas
transfere para o cliente os dois mil itens mais recentes na transicao para o modo
offline
352 Remember the Milk
O Remember The Milk9 e uma web application desenvolvida por uma equipa
Australiana que proporciona funcionalidades de agenda gestao de tempo e de tare-
fas e foi uma das primeiras aplicacoes independentes do Google a adoptar o Gears
para acessos em modo offline Permite que os seus utilizadores facam uma gestao
de tarefas agrupando-as em listas adicionando-lhes campos de informacao adicional
ou dando-lhes informacao geografica (recorrendo ao servico Google Maps10) Entre
a sua lista de funcionalidades encontra-se ainda a possibilidade de importar e ex-
portar eventos no formato iCalendar (ics) etiquetas (tags) em tarefas publicacao
Really Simple Syndication (RSS) e partilha de categorias de tarefas de acordo com
diferentes nıveis de permissoes de acesso definidos pelo utilizador
353 MySpace e WordPresscom
O MySpace uma das maiores social networks na Internet anunciou recente-
mente que vai disponibilizar uma versao do seu cliente de e-mail que utiliza o Gears
para acelerar o seu desempenho Numa fase inicial estara disponıvel apenas para
utilizadores que tenham cinco mil ou mais mensagens na sua caixa de correio e
permitira efectuar pesquisas muito mais rapido que a sua versao online
O servico de blogs Wordpresscom anunciou tambem o inıcio da utilizacao desta
tecnologia com o fim de melhorar o desempenho A versao que utiliza esta tecnologia
descarrega e armazena no cliente um conjunto de imagens e scripts que passam a
ter preferencia sobre os seus congeneres online e que permitem acelerar o processo
de carregamento da aplicacao e visualizacao de blogs
9Remember The Milk ndash httpwwwrememberthemilkcom10Google Maps ndash httpmapsgooglecom
27
Estado da arte
O MySpace e o Wordpresscom sao dois exemplos da utilizacao da tecnologia
OWA para optimizacao de web application ja existentes Sem pretenderem disponi-
bilizar uma versao que seja totalmente offline fazem uso do Gears para armazenar no
cliente parte dos recursos frequentemente acedidos na visualizacao das suas paginas
36 Escolha da tecnologia
Apos a analise das tecnologias apresentada nas seccoes 31 a 34 foi necessario es-
tudar a adequacao de cada uma delas ao projecto em questao Desde logo e possıvel
observar que nem todas se dedicam apenas a OWA Por exemplo o Adobe AIR
apesar de ter suporte para OWA apenas disponibiliza algumas das funcionalidades
identificadas como mais indicadas para a execucao do projecto quando utilizado
na sua vertente desktop tal como exposto na Tabela 31 mas a utilizacao desta
vertente implicaria o desenvolvimento de novas interfaces e de novas formas de co-
municacao (troca de mensagens XML ou JSON) A vertente web do Adobe AIR
foca-se mais especificamente nas Rich Internet Applications e permite a reutilizacao
do codigo ja existente (exigindo naturalmente a sua adaptacao e a implementacao
das funcionalidades pretendidas)
A tecnologia escolhida para a realizacao deste trabalho foi o Gears sendo que
um dos principais factores a influenciar esta opcao foi a liberdade introduzida pela
sua licenca Berkeley Software Distribution (BSD)11
Considerou-se o funcionamento desta ferramenta extremamente adequando a
aplicacao no WOW uma vez que o seu principal objectivo e precisamente tornar
possıvel a execucao offline de uma pagina web e por virtude deste facto o Gears tem
uma API concisa e de simples aplicacao pratica uma vez que nao possui quaisquer
outros elementos distractores O funcionamento do seu ManagedResourceStore ex-
emplificado na Figura 31 com a capacidade de actualizacao de recursos definidos
num ficheiro manifesto especificado em JSON pesou tambem nesta decisao
11Sobre a licenca BSD consultar httpwwwopensourceorglicensesbsd-licensephp e http
wwwlinfoorgbsdlicensehtml
28
Estado da arte
Figura 31 Esquema UML do processo efectuado pelos recursos do Gears do tipoManagedResourceStore para a actualizacao dos conteudos definidos no ficheiro manifesto
29
Estado da arte
Funcionalidade RIAs no browser RIAs no desktop
Disponibilidadeda aplicacao
As aplicacoes podem ser facil-mente exploradas e utilizadas
As aplicacoes quando instal-adas tem maior grau de fun-cionalidades e persistencia
Instalacao Nao e necessario qualquer tipode instalacao
As aplicacoes sao instaladasatraves do browser ou descar-regadas e instaladas comouma aplicacao tradicional
Actualizacoes Aplicacoes sao actualizadascarregando conteudos paraum website
O AIR disponibiliza uma APIque permite que as aplicacoessejam actualizadas de umaforma
Sistemas opera-tivos suportados
As aplicacoes podem ser exe-cutadas em diversos sistemasoperativos e browsers
As aplicacoes sao multi-plataforma e podem serinstaladas e executadas emdiversos sistemas operativos ebrowsers
Linguagens deprogramacao
Javascript e disponibilizadopelo browser e ActionScripte disponibilizado pelo AdobeFlash Player
Maquinas virtuais deJavascript e ActionScriptcompatıveis com o browser
Capacidade deexecucao embackground
As RIAs podem ser execu-tadas numa janela do browser
As aplicacoes podem ser ex-ecutadas em background edisponibilizar notificacoes talcomo uma aplicacao tradi-cional
Persistencia A actividade esta limitada asessao do browser Quando obrowser e encerrado toda ainformacao e descartada
As aplicacoes sao instaladas eestao disponıveis no desktopPodem armazenar informacaolocalmente e estao disponıveisoffline
Integracao com odesktop
Integracao com o desktop lim-itada devido a restricoes im-postas pelo browser
As aplicacoes podem acederao sistema de ficheiro ao clip-board eventos notificacoesetc
Controlo da inter-face com o uti-lizador
As aplicacoes sao acedidasatraves de uma janela dobrowser que tem os seusproprios controlos e visualgrafico
As aplicacoes tem um vi-sual grafico proprio em janelapropria
Armazenamentode dados
As aplicacoes tem armazena-mento limitado que pode serreescrito pelo browser
As aplicacoes tem acesso a to-talidade do espaco disponıvellocalmente e a uma base dedados com a possibilidade deencriptacao
Tabela 31 Comparacao das funcionalidades oferecidas pelo Adobe AIR para as platafor-mas web e desktop
30
Estado da arte
Aplicacao Modo de execucao utilizadoGoogle Reader Utiliza o modo ldquoutilizador deciderdquo disponibilizando
ao utilizador um botao para alternar entre os modosonline e offline Como lida com informacao recol-hida de fontes externas de natureza frequentementeefemera o processo de sincronizacao apenas transfereos dois mil itens mais recentes quando passa ao es-tado offline Neste modo sao ainda guardadas in-formacoes de itens lidos e etiquetas atribuıdas quesao sincronizadas com o servidor quando o utilizadorvoltar a activar estado online
Google Docs Utiliza o modo ldquoaplicacao deciderdquo permitindo que outilizador edite os conteudos de documentos de textofolhas de calculo e de apresentacoes independente-mente do estado da ligacao desde o momento em queas funcionalidades offline sao activadas A aplicacaofaz pequenas sincronizacoes com o servidor sempre quenecessario
Remember the Milk Utiliza um modo hıbrido entre ldquoaplicacao deciderdquo eldquoutilizador deciderdquo A aplicacao encarrega-se da sin-cronizacao de dados mas disponibiliza um controlona sua interface que permite despoletar manualmenteeste processo para situacoes em que o utilizador fez al-teracoes recentes e pretende usufruir das capacidadesoffline imediatamente
MySpace O MySpace anunciou a utilizacao de mecanismos dearmazenamento de dados no cliente com recurso atecnologias OWA para melhorar o desempenho doseu cliente web de correio electronico nomeadamenteno que diz respeito a operacoes de pesquisa e or-denacao Inicialmente esta funcionalidade estara ape-nas disponıvel para utilizadores com cinco mil ou maismensagens na sua caixa de correio mas nao e aindaclaro se sera disponibilizada uma versao totalmenteoffline
Tabela 32 Resumo da utilizacao de tecnologias OWA em algumas web applications con-sideradas na analise do estado da arte
31
Estado da arte
32
Capıtulo 4
Desenvolvimento
Neste capıtulo introduz-se a aplicacao WOW e apresenta-se o estudo que foi
feito da adequacao de cada tecnologia para a implementacao da funcionalidade of-
fline nesta plataforma Fazem-se diversas consideracoes sobre opcoes a tomar na
concepcao de OWAs e problemas comuns na sua implementacao bem como sug-
estoes para os resolver O WOW e uma aplicacao ja existente de gestao de ordens
de trabalho e do fluxo de tarefas numa empresa ou organizacao
41 Como ficar offline
Na maior parte das web applications de hoje nao existe uma camada de dados
real A aplicacao exemplificada na Figura 41 ao longo da sua execucao acede
directamente a sua unica fonte de dados (o servidor) atraves de chamadas Ajax sem
que exista uma separacao clara destas duas camadas
Para que uma web application seja capaz de ser executada sem uma ligacao
activa a Internet e mantenha o seu caracter dinamico torna-se necessario incluir
Figura 41 Exemplo de uma arquitectura de uma web application sem uma camada deabstraccao de dados Figura adaptada de http gears google com
33
Desenvolvimento
Figura 42 Exemplo de uma arquitectura de uma web application com uma camada deabstraccao de dados Figura adaptada de http gears google com
um mecanismo de armazenamento de dados local seja uma base de dados ou a
capacidade de acesso ao disco No entanto este mecanismo introduz dois problemas
1 Qual das fontes de dados utilizar quando um utilizador faz um pedido de
informacao
2 A necessidade de implementar uma camada de acesso a dados que seja coerente
quer se use o servidor remoto ou local
Por exemplo em vez de a aplicacao Ajax fazer um pedido relativo as contas de
todos os utilizadores em formato JSON directamente ao servidor remoto podera ao
inves fazer o pedido a um objecto intermedio da camada de dados Este objecto
demonstrado na Figura 42 sera responsavel por implementar uma interface de
acesso a base de dados e retornar um objecto JavaScript com uma representacao da
resposta do servidor
Mas a existencia de uma segunda fonte de dados torna recomendavel tambem
a implementacao de uma camada de data switching que em funcao da existencia
de conexao a Internet e da necessidade de actualizacao dos dados decide se faz o
pedido ao servidor remoto ou se fornece os dados presentes localmente Este objecto
apresentado na Figura 43 decidira de forma transparente para o utilizador se le ou
escreve os dados localmente ou se os enviapede ao servidor remoto e pode tambem
iniciar o processo de convergencia de dados e de resolucao de conflitos
411 Funcionalidades disponıveis em modo offline
Por razoes praticas e provavel que nem todas as funcionalidades da aplicacao
possam ser disponibilizadas em modo offline E necessario escolher quais as fun-
cionalidades a disponibilizar no modo offline da aplicacao e implementar a logica
que decide quando utilizar a base de dados local ou o servidor remoto Apesar do
acesso a base de dados local ser muito mais rapido do que aceder ao servidor o
acesso local nem sempre e preferido Ha varias razoes que podem tornar necessario
escolher o acesso ao servidor em vez do acesso local
34
Desenvolvimento
Figura 43 Exemplo de uma arquitectura de uma web application com uma camada deabstraccao de dados e um data switch Figura adaptada de http gears google com
1 A informacao pode ter uma natureza efemera e nao fazer sentido guarda-la
localmente Exemplo dados em tempo real da bolsa de valores de Lisboa
2 Algumas aplicacoes lidam com informacao que so faz sentido na presenca de
uma ligacao Exemplo Instant Messaging
3 A aplicacao podera escolher apenas guardar a informacao acedida mais fre-
quentemente Exemplo para o utilizador poder alterar a lıngua de apre-
sentacao da aplicacao os conteudos terao que ser guardados em todas as
lınguas disponibilizadas pela aplicacao O custo de implementacao de algu-
mas funcionalidades pode nao compensar o benefıcio
4 A capacidade de processamento ou de armazenamento de dados pode inviabi-
lizar algumas funcionalidades offline Exemplo se uma dada funcionalidade
necessita de uma capacidade de armazenamento de dados para alem do razoavel
de um computador pessoal para ser util (visualizador de mapas)
42 Modos de execucao
Um aspecto que e necessario estudar para qualquer web application que se deseje
disponibilizar offline prende-se com tres modos de execucao que devem ser consid-
erados
1 Utilizador decide o modo de execucao A aplicacao tem modos distintos
de execucao para os estados online e offline geralmente indicados na interface
com o utilizador O utilizador e informado do estado da ligacao e participa na
alteracao de estado de execucao da aplicacao interagindo com a sua interface
2 Aplicacao decide o modo de execucao Pode ser implementado na propria
aplicacao um mecanismo de deteccao do estado da ligacao (por exemplo atraves
35
Desenvolvimento
de chamadas Ajax periodicas) transitando de estado e sincronizando automati-
camente Desta forma o utilizador nao precisa de participar na alteracao de
estado a menos que exista um conflito de dados que requeira a sua atencao
3 Aplicacao assume sempre o estado offline Outra hipotese sera imple-
mentar uma web application que assume sempre estar na ausencia de uma
ligacao ao servidor de dados Esta aplicacao responde aos pedidos do uti-
lizador efectuando pedidos de informacao ao servidor mas nao dependendo
de uma resposta valida para mostrar a informacao que ja tinha disponıvel an-
teriormente A sincronizacao de dados com o servidor e tentada sempre que
existam dados para submeter e uma accao do utilizador
421 Modo ldquoutilizador deciderdquo
Neste modo de execucao quando a aplicacao esta online comunica com o servidor
remoto quando esta offline comunica com a base de dados local A informacao tem
que ser sincronizada sempre que se muda de modo A principal vantagem desta opcao
e que e a mais simples de implementar mesmo para uma aplicacao ja existente e
portanto uma forma expedita de disponibilizar uma OWA No entanto tem tambem
algumas desvantagens que devem ser consideradas
1 O utilizador tem que se lembrar de fazer a alteracao de estado de execucao
Caso contrario podera estar a trabalhar inadvertidamente numa versao offline
com dados antigos ou nao ter a informacao necessaria se perder subitamente
a ligacao
2 Se a ligacao for intermitente o utilizador tera ou que escolher um dos modos
de execucao ou estar constantemente a trocar
3 Uma vez que a base de dados nao esta sempre actualizada nao podera ser
utilizada para melhorar a rapidez de execucao da aplicacao quando em modo
online
422 Modo aplicacao decide
A deteccao do estado da ligacao pode ser implementada atraves de um pedido
assıncrono ao servidor tal como ilustrado na Figura 44 O resultado deste pedido
definira o estado online (em caso de sucesso) ou offline (em caso de falha) A
sincronizacao de dados podera ser feita sempre que ocorra uma transicao do es-
tado offline para o estado online No entanto este metodo nao se revela eficiente
36
Desenvolvimento
Figura 44 Esquema grafico ilustrando uma OWA executando no browser utilizando ummodo de execucao do tipo ldquoaplicacao deciderdquo com deteccao automatica do estado daligacao via pedidos Ajax assıncronos a cada cinco segundos
para grandes aplicacoes uma vez que requer a troca de mensagens demasiado fre-
quentes com o servidor que se destinam exclusivamente a monitorizacao do estado
da ligacao
423 Modo ldquoaplicacao assume o estado offlinerdquo
Uma aplicacao transparente funciona assumindo sempre que esta em modo of-
fline ou pelo menos que pode perder a ligacao a qualquer momento Neste modo
tira-se o maximo partido do armazenamento local e fazem-se pequenas mas contınuas
sincronizacoes com o servidor sempre que este esteja disponıvel A sincronizacao de
dados tambem e feita sempre que se volta ao estado online
As vantagens de uma web application transparente sao as seguintes
bull Uma melhor experiencia para o utilizador uma vez que este nao tem que se
preocupar com o estado da ligacao ou com a transicao de estados
bull A aplicacao funciona de forma coerente mesmo que a ligacao seja intermitente
bull Uma vez que o armazenamento local e mantido actualizado pode ser utilizado
para melhorar o desempenho da aplicacao
Foram identificadas as seguintes desvantagens
bull E mais difıcil de implementar e a sincronizacao acarreta cuidados especiais
bull E necessario um cuidado adicional para evitar que as operacoes de sincronizacao
frequentes que ocorrem automaticamente nao afectem os tempos de resposta
da aplicacao
bull Os testes a aplicacao sao mais complexos uma vez que a sincronizacao de dados
nao ocorre em resposta a uma accao do utilizador
37
Desenvolvimento
43 Sincronizacao de dados
A sincronizacao de dados consiste na capacidade de identificar e transferir pe-
riodicamente a versao mais actual dos dados entre o cliente e o(s) servidor(es)
Independentemente do modo de execucao escolhido e mesmo do estado da ligacao
do utilizador a informacao armazenada localmente e a informacao armazenada no
servidor estarao por vezes dessincronizadas Isto podera acontecer sempre que por
exemplo
bull O utilizador faz alteracoes em modo offline
bull A informacao e partilhada e pode ser alterada por uma entidade externa
bull A informacao e fornecida por uma entidade externa
Resolver estas diferencas de forma a que a informacao local e remota encontrem
a igualdade chama-se sincronizacao de dados Ha varias aproximacoes possıveis
para este efeito que dependem da natureza da aplicacao cada uma com vantagens
e desvantagens
A capacidade de suportar a mobilidade dos utilizadores torna-se cada vez um
ponto mais importante de uma web application Para uma organizacao de dimensao
global e vital garantir que os seus colaboradores tem acesso a mesma informacao
que tem disponıvel nos seus postos de trabalho mesmo quando estao fora Na maior
parte dos casos estes colaboradores terao acesso a um computador portatil um
desktop Smartphone ou PDA e atraves destes poderao ter acesso a sua informacao
directamente atraves de ligacoes encriptadas Virtual Private Network (VPN) de um
servidor web ou de outro mecanismo de rede
Esta solucao e simples de implementar mas infelizmente para a maioria dos
colaboradores com grande factor de mobilidade nao e satisfatoria As principais
desvantagens sao as seguintes
bull Requisitos de ligacao Para permitir que os utilizadores acedam a sua in-
formacao e necessario garantir a capacidade constante de comunicacao pelo
menos durante o tempo necessario que assegure a sua transferencia
bull Velocidade de ligacao sem persistencia de dados e em ligacoes de fraca
qualidade a usabilidade por vezes torna-se inaceitavel
bull Ponto crıtico de falha Com este tipo de solucao todos os utilizadores de-
pendem da base de dados que armazena informacao vital para o funcionamento
do cliente
38
Desenvolvimento
bull Scalability do servidor A medida que novos utilizadores sao adicionados ao
sistema o desempenho do servidor e afectado levando a necessidade de maior
capacidade de armazenamento eou processamento
De acordo com a documentacao da Microsoft Sync Framework [Mic08] uma
solucao alternativa consiste em implementar uma Occasionally Connected Appli-
cation (OCA) Uma OCA permite a um utilizador remoto continuar a aceder a
sua informacao mesmo depois de perder a ligacao mas em vez de recorrer a um
servidor recorre a informacao armazenada no seu dispositivo local Para preencher
localmente a informacao que o utilizador necessita uma OCA possui mecanismos
de sincronizacao de dados que sao oferecidos por esta framework
431 Quando sincronizar
Uma das solucoes mais simples de implementar passa por disponibilizar um
mecanismo manual que despoleta a sincronizacao Diz-se manual porque e o uti-
lizador que escolhe quando sincronizar e pode ser implementada simplesmente
fazendo o upload de toda a informacao para o servidor e depois fazendo o download
da copia mais recente da informacao antes de voltar a ficar offline Para que esta
seja uma opcao viavel e necessario que
bull O volume de dados seja suficientemente pequeno para que possa ser transferido
do servidor para o cliente num espaco de tempo aceitavel
bull Que o utilizador indique explicitamente que quer mudar para o estado offline
ou online pressionando um botao da interface
Contudo podem ser identificados alguns problemas relacionados com esta abor-
dagem
bull Os utilizadores nem sempre podem prever o estado das suas ligacoes A ligacao
pode-se perder subitamente ou ter um caracter intermitente
bull O utilizador pode esquecer-se de efectuar a sincronizacao
Outra opcao sera conjugar a sincronizacao de dados com o modo de execucao
transparente A sincronizacao ocorre automaticamente em background de forma
nao intrusiva para o utilizador A aplicacao comunica com o servidor regularmente
efectuando pequenas trocas de dados com o objectivo de manter o sincronismo da
informacao local e remota Esta abordagem pode ser implementada com pedidos
Ajax assıncronos e regulares ao servidor o que permite manter a interaccao com a
interface fluıda evitando bloqueios Estes pedidos sao feitos prevendo as situacoes
39
Desenvolvimento
de disponibilidade ou indisponibilidade (timeout) do servidor Uma outra opcao
sera permitir que o servidor comunique essas alteracoes utilizando Comet1 tal como
descrito em [Wil06] e [Rus06] As vantagens destas aproximacoes sao
bull A informacao esta disponıvel a qualquer altura que o utilizador decida ficar
offline ou que a ligacao seja acidentalmente perdida
bull O desempenho da aplicacao pode ser melhorado quando se estiver a utilizar
uma ligacao a Internet lenta uma vez que o acesso a dados locais e mais
eficiente do que a consulta de dados ao servidor
44 WOW
O WOW e uma plataforma integrada de gestao de ordens de trabalho ja ex-
istente e desenvolvida pela Critical Software SA a qual se pretende adicionar a
capacidade de execucao offline Esta aplicacao e extremamente dinamica e con-
figuravel com um conjunto extremamente rico de funcionalidades das quais se
destacam
bull Gestao de Ordens de Trabalho ndash suportando a gestao dos pedidos desde a
sua criacao ate ao seu fecho tomando em conta os diferentes tipos de pedidos
(ordens de trabalho pedidos de informacao melhorias resolucao de problemas
etc) e diferentes tipos de accoes possıveis para cada um (Figura 45)
bull Monitorizacao de alteracoes ndash Historico de mudancas anexos e estados criando
relatorios de alteracao automaticamente (o que por quem e quando)
bull Uso de Service Level Agreements (SLAs) ndash E possıvel associar a um pedido um
SLA que define qual o perıodo de tempo atribuıdo a resolucao de um pedido
controlando e agilizando a resolucao do mesmo
bull Utilizacao de queries de utilizador configuraveis que permitem acesso rapido
a determinadas ordens de trabalho de acordo com o filtro configurado (por
exemplo ldquoPara mimrdquo ldquoPara o Grupordquo ldquoPelo Grupordquo)
bull Gestao do relacionamento entre pedidos
bull Pesquisa e filtragem de ordens de trabalho
bull Exportacao de dados em formatos padrao (PDF DOC ou XLS)
bull Integravel com solucoes externas
40
Desenvolvimento
Figura 45 Detalhe de um conjunto possıvel de estados e respectivas transicoes para umadada ordem de trabalho no WOW desde a sua submissao no sistema ate a sua conclusaoem fecho ou cancelamento Esta figura representa apenas um exemplo ja que o mapa deestados para uma ordem de trabalho e dinamico e pode ser alterado por um administradorFigura retirada de uma brochura promocional do WOW Critical Software SA
A utilizacao de uma ferramenta deste tipo por parte de uma empresa ou orga-
nizacao oferece vantagens quer a gestao de topo quer aos colaboradores individuais
para os colaboradores individuais o WOW e uma aplicacao onde estao registadas
todas as tarefas contribuindo activamente para o desenvolvimento em ambientes
multi-tarefa e para a organizacao pessoal das tarefas de acordo com prioridades
Para a gestao de topo esta ferramenta permite obter uma visao global do estado da
organizacao em termos de tempo gasto por tarefa executada sendo uma mais valia
para a previsao e gestaoalocacao de recursos
45 Visao geral sobre a arquitectura do WOW
O WOW e interessante nao so do ponto de vista de produto como tambem do
ponto de vista de plataforma Existem diversos plug-ins que estendem as funcional-
idades do WOW e existem ate projectos que pretendem usar a arquitectura do
WOW para criar produtos com fins diferentes do inicial (por exemplo o WOW-
Storm ndash um sistema de registo e classificacao social de ideias)
De modo a conseguir ter essa expansibilidade a plataforma WOW assenta sob
uma arquitectura distribuıda modular e expansıvel com uma componente central
ndash o core ndash estruturado em camadas logicas E no core que se situam todas as
1O Comet e um conceito semelhante ao Ajax introduzido por Alex Russel mas no qual e o servidor quetoma a iniciativa de ldquoenviarrdquo os dados ao browser sem que este tenha que efectuar um pedido Tambem econhecido por Ajax Push Reverse Ajax ou HTTP Streaming
41
Desenvolvimento
funcionalidades base da aplicacao quer a nıvel logico funcional e de apresentacao
quer a nıvel de gestao e configuracao
E possıvel a execucao de varias instancias do core simultaneamente em servidores
distintos o que permite a alta escalabilidade e disponibilidade desta aplicacao A
consistencia dos dados fica sempre garantida atraves da partilha da base de dados
e pelo balanceamento dos pedidos uma vez que cada um e encaminhado para uma
unica instancia
O WOW apresenta tambem a vantagem de ser uma plataforma extensıvel E
possıvel adicionar novas caracterısticas a plataforma atraves de componentes que se
podem ser divididos em duas categorias plugins e connectors
Os plugins sao componentes que se encontram no mesmo no fısico que a aplicacao
partilhando do mesmo contexto de execucao do core Sao assim uma forma mais
directa de obter informacao da plataforma visto que nao possuem restricoes de
acesso aos dados nem dependencias externas A arquitectura deste componente tera
assim que permitir varias execucoes instanciadas cada uma associada a um core
Por outro lado os connectors sao componentes que se encontram distribuıdos
comunicando externamente com o core Quer a sua execucao quer a obtencao
dos dados estao assim dependentes de interfaces de comunicacao externas que a
plataforma disponibiliza Estes componentes ao contrario dos plugins sao instan-
ciados unicamente e recorrem ao protocolo de comunicacao Java Messaging Service
(JMS) para comunicar com o core
46 WOW Offline
Para alem das opcoes tomadas relativamente a tecnologia a utilizar surgiu
tambem a necessidade de optar por um dos modos de execucao apresentados na
seccao 42
Das tres opcoes possıveis foi o modo ldquoaplicacao assume o estado offlinerdquo descrito
na seccao 423 que mereceu a maior atencao uma vez que reune as vantagens de
uma experiencia mais positiva para o utilizador (uma vez que este nao tem que
participar activamente na alteracao do modo execucao como descrito na seccao 421)
e nao constitui uma sobrecarga excessiva para servidor (como o modo abordado na
seccao 422)
No entanto esta opcao comprometia a complexidade da implementacao para alem
dos objectivos propostos para este projecto e para cumprir o prazo dado foi tomada
a decisao de implementar o modo ldquoutilizador deciderdquo especificando apenas de forma
teorica o modo ldquoaplicacao assume o estado offlinerdquo
As caracterısticas do Gears foram ja descritas na seccao 31 Na Figura 47
mostra-se a sua forma de funcionamento quando integrado numa web application
42
Desenvolvimento
Nesta figura representa-se o modulo LocalServer do Gears como um ponto de de-
cisao Aqui sao testadas as condicoes que determinam se o pedido sera interceptado e
servido localmente ou se prossegue para uma maquina remota E tambem represen-
tada uma base de dados que corresponde ao modulo Database mas que podera nao
ser utilizada Este modulo tal como o modulo Workerpool tem caracter opcional
e sao utilizados consoante os requisitos da aplicacao
A plataforma WOW lida com mais dados do que e necessario passar para o
lado do cliente Em conformidade com o ja exposto na seccao 411 volta-se a
frisar que nao se pretende recriar toda a logica de negocio nem os conteudos da
base de dados no cliente pela sua complexidade e volume de dados Pretende-se
pelo contrario permitir que os utilizadores tirem partido da capacidade de poder
consultar as suas ordens de trabalho quando nao dispoe de uma ligacao transferindo
apenas o essencial para isto seja possıvel
A pagina inicial do WOW apresenta um resumo das ordens de trabalho abertas
ndash enviadas e recebidas ndash que se pretende permitir visualizar offline (ver Figura 46)
Como prova de conceito foi efectuada uma abordagem pragmatica das varias possi-
bilidades descritas na seccao 42
461 Modo ldquoaplicacao deciderdquo com deteccao automatica da ligacao
A primeira abordagem estudada para a disponibilizacao das funcionalidades of-
fline foi o modo ldquoaplicacao deciderdquo com deteccao automatica de ligacao apresentado
na seccao 422 Para que isto seja possıvel foi implementado um mecanismo de ver-
ificacao periodica do estado da ligacao atraves de chamadas Ajax assıncronas O
resultado destes pedidos determina o estado da aplicacao executando as tarefas de
sincronizacao de dados sempre que pertinente Este metodo embora imediato e
simples de implementar depressa se revelou inadequado para o projecto devido ao
elevado consumo de recursos do servidor que a utilizacao intensiva faz esperar a
comunidade da plataforma WOW no principal cliente excede os 7000 utilizadores
Foi estimado que para uma utilizacao de fluidez aceitavel o estado da ligacao deveria
ser testado a cada cinco segundos Assumindo uma adesao (previsao pessimista) de
1 aos servicos offline assistir-se-ia a cerca de 840 pedidos adicionais por minuto
Mas o principal problema desta aproximacao prende-se com o facto de a ver-
ificacao ser feita em intervalos de tempo discretos levando a possibilidade de a
aplicacao poder ter em dado momento uma representacao errada do seu estado
real da ligacao Este problema e ilustrado na Figura 48 onde se ve claramente a
discrepancia entre o estado real da ligacao e a representacao interna que esta tem
Note-se que nesta janela de tempo qualquer accao do utilizador que exija uma
resposta sıncrona do utilizador leva-lo-a para um ldquobeco sem saıdardquo onde nao tera
43
Desenvolvimento
Figura 46 A pagina inicial do WOW apresenta um resumo das ultimas ordens de trabalhoenviadas e recebidas Na imagem pode-se observar a transicao do estado online para offline
acesso a versao offline porque a aplicacao nao fez a transicao automatica nem acesso
a versao online porque na verdade nao possui uma ligacao O que acontecera nesta
situacao sera uma tentativa de acesso ao servidor por parte da aplicacao numa
altura em que este se encontra indisponıvel e o resultado sera uma mensagem de
ldquopedido excedeu o tempordquo apresentado pelo browser Este e um estado sem retorno
porque apos o browser apresentar esta mensagem todos os recursos JavaScript ficam
indisponıveis tornando impossıvel o regresso ao estado anterior ou o tratamento do
erro de qualquer outra forma No entanto as chamadas Ajax podem ser tratadas de
forma especial para a eventualidade de falha e portanto nao constituem problema
44
Desenvolvimento
Figura 47 Ilustracao do funcionamento do Gears numa web application que utiliza ummotor Ajax Os pedidos HTTP ou HTTPS podem ser interceptados e tratados localmenteou podem ser feitos a uma maquina remota consoante se verificarem ou nao as condicoesexpressas no ponto 311 E representado um acesso a uma base de dados local (fornecidapelo Gears) mas a sua utilizacao e opcional
462 Implementacao do modo ldquoutilizador deciderdquo
Este modo de execucao foi ja descrito na seccao 421 e a sua principal carac-
terıstica e ser o utilizador a decidir se a aplicacao deve utilizar um servidor remoto
ou a maquina local como fornecedor de dados
Relativamente ao WOW o WOW Offline na vertente ldquoutilizador deciderdquo vem
alterar os seus casos de uso dando ao utilizador a possibilidade de alterar o estado
de execucao da aplicacao (entre online e offline) Resta dizer que no modo online se
mantem todas as funcionalidades anteriores e que no modo offline torna-se possıvel
visualizar os conteudos da pagina principal do WOW (Figura 46) e os detalhes das
ordens de trabalho (Figura 49) tal como expressa a Figura 410
Esta aproximacao foi utilizada na prova de conceito do WOW adicionando um
controlo a interface desta aplicacao que permite ao utilizador alternar entre os esta-
dos online e offline Na transicao de online para offline sao descarregados os recursos
necessarios para a execucao desta aplicacao sem recorrer a Internet Para o fazer
45
Desenvolvimento
Figura 48 Neste exemplo do modo ldquoaplicacao deciderdquo o teste da ligacao e feito e feito acada cinco segundos O resultado deste teste nao reflecte sempre o estado real da aplicacaopodendo levar a aplicacao a ter comportamentos indesejaveis Na figura assinala-se umperıodo de tempo no qual a representacao interna do estado da ligacao nao corresponde arealidade
e utilizado um recurso ResourceStore e um ManagedResourceStore (introduzidos
em 311) O primeiro e utilizado para armazenar a pagina principal do WOW ndash do-
ravante designada por homejsp ndash e o segundo e utilizado para armazenar imagens
folhas de estilo CSS e scripts JavaScript
Para a implementacao deste modo de execucao foram identificadas as seguintes
tarefas
1 Guardar informacao que permita a recriacao das paginas que se pretende
disponibilizar offline (utilizando o Gears)
2 Disponibilizar um controlo que permita alterar o estado de execucao atraves
da interaccao com a pagina principal
3 Durante a sincronizacao de dados apresentar o progresso da transferencia de
dados
O primeiro passo consistiu na identificacao de todos os conteudos que sao necessarios
transferir para a execucao offline Foi utilizado um recurso do Gears do tipo
ManagedResourceStore que recorre a um ficheiro manifesto para identificar to-
dos os ficheiros que deve transferir Este recurso e gerido automaticamente pelo
Gears transferindo para o cliente a versao mais recente sempre que e necessario
isto e sempre que exista um ficheiro manifesto com uma identificacao de versao que
seja diferente da actualmente disponıvel no cliente Uma vez identificados todos
ficheiros necessarios para a execucao offline num (ou mais) ficheiros manifesto o
Gears encarrega-se da sua actualizacao mas o preenchimento destes ficheiros man-
ifesto e manual o que se traduz num cuidado extra na manutencao da aplicacao
A forma como esta informacao e guardada deve tambem ser cuidadosamente
estudada A opcao mais flexıvel passa por utilizar o modulo Database apresentado
na seccao 311 e guardar a informacao de uma forma relacional Para a recriacao
das paginas pode ser disponibilizada uma versao HTML da pagina que funciona
46
Desenvolvimento
Figura 49 Pagina de visualizacao do detalhe de uma ordem de trabalho
como template nao possui quaisquer dados e e utilizada apenas em modo offline E
preenchida para cada pedido retirando os dados relevantes da base de dados
O modelo de dados do WOW torna esta opcao extremamente trabalhosa uma
vez que as entidades envolvidas na geracao de cada pagina de informacao sobre
cada ordem de trabalho tem relacoes de dependencia complexas seguindo padroes
muito variaveis Por exemplo em cada ordem de trabalho existe um formulario que
permite a sua progressao de estado com diversos campos opcionais e obrigatorios
este formulario e definido pelo administrador e esta relacionado nao apenas com o
tipo de ordem de trabalho mas tambem com o estado actual em que esta se encontra
e a accao que se pretende realizar O elevado numero de combinacoes de tipos de
ordem de trabalho estados e accoes que existem num dado momento juntamente
com a sua possibilidade de alteracao obrigariam a implementacao de uma logica de
negocio complexa o que esta fora do ambito deste projecto
47
Desenvolvimento
Figura 410 Esquema UML que expressa os casos de uso do WOW Offline no modoldquoutilizador deciderdquo
463 Especificacao do modo ldquoaplicacao assume o estado offlinerdquo
A aproximacao para o modo ldquoaplicacao assume o estado offlinerdquo foi tambem
dividida em varias tarefas
1 Guardar informacao que permita a recriacao da pagina principal do lado do
cliente no estado offline (utilizando o Gears)
2 Dotar a aplicacao do cliente de um mecanismo de deteccao da ligacao
3 Identificar os ldquomomentos chaverdquo em que devera ocorrer sincronizacao de dados
4 Implementar a sincronizacao de dados
A sincronizacao de dados deve ser feita em ambas as transicoes online-offline e
offline-online quer para transferir novos dados do servidor (os pedidos podem ser
alterados por outros utilizadores) quando se transita do estado quer para comunicar
eventuais alteracoes feitas em modo offline
Relativamente ao WOW o WOW Offline na vertente ldquoaplicacao assume o es-
tado offlinerdquo vem alterar os seus casos de uso dando ao utilizador a possibilidade
de activar esta funcionalidade A partir do momento que a funcionalidade esta ac-
tivada o utilizador deve tambem ter a possibilidade de gerir algumas preferencias
relacionadas com privacidade de dados Devera ter a hipotese de desactivar o ar-
mazenamento local e de remover todos os dados ja armazenados tal como descrito
na Figura 411
48
Desenvolvimento
Figura 411 Esquema UML que expressa os casos de uso do WOW Offline no modoldquoutilizador deciderdquo
A primeira vez que o WOW Offline e acedido por um cliente e caso seja detec-
tada a presenca do Gears todos os recursos necessarios a sua execucao sao trans-
feridos Todos os acessos posteriores serao feitos a estes recursos locais (recorda-se
que o Gears pode ser utilizado para os manter actualizados recorrendo ao Managed-
ResourceStore 311)
Atraves do JavaScript e possıvel interceptar os eventos de load e unload da
pagina que sao despoletados sempre que ocorre um re-acesso da mesma (incluindo
a accao refresh comum dos browsers) sempre que esta e abandonada ou ainda ou
ainda se a janela for encerrada
Tal como sugerido na seccao 462 a camada de interface desta aplicacao (cada
pagina individual em HTML) devera ser implementada como sendo um template
para apresentacao de dados sendo totalmente preenchida atraves de funcoes em
JavaScript O objectivo deste ponto e criar um padrao de dados que permita ao
JavaScript preencher os dados em cada pagina (template) independentemente de
qual seja a fonte ndash o servidor remoto ou a maquina local tal como exemplificado
no diagrama da Figura 412 Na figura a aplicacao recorre ao servidor remoto para
obter os dados pretendidos quando se encontra na presenca de uma ligacao mas
para dados que exijam uma carga de processamento pelo servidor este acto pode ser
49
Desenvolvimento
Figura 412 Esquema UML que expressa o acto de recolha de dados em modo online eoffline recorrendo ao servidor (modo online) e ao sistema de armazenamento de dadoslocal fornecido pelo Gears (modo offline)
substituıdo pelo envio de um campo de controlo que se destina a aferir se os dados
locais se encontram actualizados No caso de estarem actualizados a comunicacao
com o servidor pode ser substituıda por uma query a base de dados local
50
Capıtulo 5
Resultados e Futuros
Desenvolvimentos
Todo o estudo feito sobre o tema OWA foi ja abordado ao longo do documento
Neste capıtulo apresentam-se os resultados obtidos na implementacao da prova de
conceito que visava compreender a melhor forma de disponibilizar uma versao of-
fline no WOW uma plataforma de gestao de ordens de trabalho ja existente de-
senvolvida pela Critical Software SA
51 Resultados Obtidos
Os resultados obtidos neste projecto sao extremamente satisfatorios uma vez
que o estudo do tema OWA e a implementacao de uma prova de conceito que o
ilustrasse foi conseguido com sucesso
A funcionalidade offline foi adicionada ao produto WOW da Critical Software
SA permitindo a visualizacao de ordens de trabalho e dos seus detalhes mesmo na
ausencia de uma conexao activa a Internet Embora para a solucao implementada
tenha sido utilizada uma abordagem do tipo ldquoutilizador deciderdquo pretende-se que esta
seja convertida para ldquoaplicacao deciderdquo ou mesmo para uma aproximacao hıbrida
semelhante a utilizada pelas aplicacoes estudadas nas seccoes 351 e 352
Para a sua implementacao descrita no capıtulo 4 foram tomadas decisoes de or-
dem pratica que permitissem tornar o trabalho exequıvel nos prazos dados Tentou-
se sempre que estas decisoes afectassem o mınimo em termos de desempenho e de
experiencia para o utilizador Considera-se que a implementacao do modo offline
com uma transicao entre modos do tipo ldquoutilizador deciderdquo (ver seccao 42) reflecte
o compromisso entre o desempenho pretendido e os recursos disponıveis e para alem
51
Resultados e Futuros Desenvolvimentos
de ser um exemplo eficaz das possibilidades que as OWA podem trazer a aplicacao
WOW desenvolvida pela Critical Software e tambem um estudo que pode ser uti-
lizado para analisar a implementacao desta tecnologia noutros produtos da mesma
empresa
Note-se que o principal objectivo do trabalho era ganhar familiaridade com este
tema entender as suas vantagens e desvantagens e compreender as suas limitacoes
Tudo indica que existam varias possibilidades de implementacao deste paradigma
noutros produtos da Critical Software que pela sua natureza podem tambem tirar
partido da execucao offline
52 Trabalho Futuro
O desenvolvimento do conceito e formas de implementacao de OWA continua
em forte desenvolvimento no entanto a sua adopcao ainda nao e generalizada A
dificuldade da sua implementacao em web applications ja existentes e o principal
obstaculo a sua maior divulgacao
Ha tambem um factor que deve ser tido em consideracao a manutencao de
codigo A implementacao de uma versao offline de uma web application requer
a implementacao das mesmas regras de negocio (ou de uma versao simplificada)
utilizadas no servidor Para que isto seja possıvel e necessario ter em conta a
capacidade de processamento do cliente e o factor de duplicacao de codigo que
tornara a aplicacao mais difıcil de manter uma vez que uma alteracao a logica de
negocio do servidor implica tambem uma alteracao a sua versao offline
A prova de conceito implementada permite ja a visualizacao offline dos pedidos
abertos (enviados e recebidos) que constam na pagina principal (este numero e
fixo e pode ser alterado pelo administrador) Uma funcionalidade desejavel seria a
possibilidade de interaccao com a aplicacao em modo offline e sincronizacao com o
servidor quando existisse uma ligacao disponıvel
Foi estudada a utilizacao do modo de execucao ldquoaplicacao assume o estado of-
flinerdquo descrito em 423 e esta seria a forma desejavel para o WOW Offline no
entanto para que esta opcao seja viavel sera necessaria a implementacao de uma
forma eficiente de sincronizacao e armazenamento de dados de uma forma relacional
Para atingir este objectivo podera ser seguida uma polıtica de automacao do pro-
cesso no qual a versao online da aplicacao gera scripts de criacao para as tabelas
necessarias na base de dados da versao offline (nao existe nenhuma ferramenta para
o fazer portanto seria necessaria a sua implementacao) e no qual as paginas HTML
disponibilizadas pelo servidor aos clientes web (browser) servem como templates de
apresentacao de informacao e sao preenchidas de forma semelhante pelo servidor ndash
quando a aplicacao estiver online ndash ou pelo cliente atraves de funcoes em JavaScript
52
Resultados e Futuros Desenvolvimentos
ndash quando a aplicacao estiver offline No entanto no WOW devido a quantidade de
informacao tratada e devido as complexas relacoes entre as diferentes entidades e
de esperar que a complexidade da implementacao de um mecanismo deste tipo torne
esta aproximacao demasiado custosa
O HTML 5 embora um forte candidato ainda nao esta suficientemente desen-
volvido A sua especificacao ainda tem o caracter de Draft (rascunho) e esta sujeita
a modificacoes e a aceitacao e implementacao por parte dos browsers e portanto
de momento foi desconsiderado No entanto no futuro se esta especificacao atingir
um estado de maturidade que permita a sua adopcao devera ser considerada como
um possıvel caminho a seguir
53
Resultados e Futuros Desenvolvimentos
54
Capıtulo 6
Conclusoes
Neste capıtulo sao apresentadas as conclusoes do projecto e consideracoes finais
relativamente a tecnologia estudada
61 Conclusoes
O rapido desenvolvimento tecnologico faz prever que a disponibilidade de ligacao
a Internet seja cada vez mais facil e mais rapido mas vao continuar a existir lugares
onde o acesso e limitado e onde as OWA podem desempenhar um papel de relevo
Por outro lado esta tecnologia pode tambem ser utilizada para melhorar o desem-
penho de paginas web com uma necessidade elevada de imagens ou outros recursos
dispendiosos em termos de espaco e foram ate estudados dois exemplos da utilizacao
desta vertente desta tecnologia em 353
Acredita-se que as OWAs vem responder a uma necessidade real por parte das
web applications actuais e que a evolucao que representam se compara a que se
assistiu dos thin-clients para os fat-clients em termos de autonomia do servidor
A capacidade de oferecer conteudos dinamicos no browser independentemente da
existencia de uma ligacao reune as vantagens tıpicas das web applications como
ausencia de instalacao e actualizacoes instantaneas com as vantagens das aplicacoes
de desktop em capacidade de processamento e armazenamento de dados na maquina
local
As tecnologias disponıveis ate a data estudadas no ambito deste projecto que
permitem o desenvolvimento de OWAs e que apresentam maior maturidade sao o
Gears e o Adobe AIR Ambas se apresentam sobre a forma de plugins que necessitam
de uma instalacao extra para poderem ser utilizadas Apesar de esta instalacao ser
55
Conclusoes
apenas necessaria uma vez podera constituir um factor de desencorajamento a sua
adopcao
O HTML 5 uma especificacao abordada neste documento na seccao 34 podera
ser uma alternativa que oferece funcionalidades offline a uma web application sem a
necessidade de qualquer instalacao no entanto esta especificacao ainda nao foi aceite
pelos principais browsers ndash o documento que define o HTML 5 ainda tem o estatuto
de Draft ndash e ainda nao e possıvel antecipar quando e que isto podera acontecer
Um dos problemas que surge frequentemente na implementacao de uma versao
offline para uma web application e a necessidade de sincronizacao de dados Quando
a informacao pode ser alterada por varios utilizadores simultaneamente e necessario
prever os conflitos que daı podem surgir e dotar a aplicacao de uma forma de os
resolver ou alertar o utilizador para a necessidade de alteracao dos dados
Em conclusao todos os objectivos propostos para este projecto foram atingidos
A prova de conceito implementada reflecte de forma clara as possibilidades oferecidas
pela tecnologia OWA e sera utilizado no futuro para compreender a melhor forma
de o implementar de forma definitiva no WOW
56
Referencias
[Ada08] Lucas Adamski Introducing Adobe AIR security model Fevereiro de2008 Disponıvel em httpwwwadobecomdevnetairarticles
introduction_to_air_securityhtml acedido em Marco de 2008
[Ado08] Adobe Adobe AIR 10 Security White Paper 2008 Disponıvel emhttpdownloadmacromediacompubairdocumentation1air_
securitypdf acedido em Marco de 2008
[Alm08] Dion Almaer Gears as a bleeding-edge html 5 implementa-tion March 2008 Disponıvel em httpalmaercomblog
gears-as-a-bleeding-edge-html-5-implementation acedido emMarco de 2008
[BL96] Tim Berners-Lee The world wide web Past present and future Agostode 1996 Disponıvel em httpwwww3orgPeopleBerners-Lee
1996ppfhtml acedido em Abril de 2008
[CDGH08] Mike Chambers Daniel Dura Dragos Georgita and Kevin Hoyt AdobeAIR for JavaScript Developers OrsquoReilly Media 2008 Disponıvel emhttponairadobecomfilesAIRforJSDevPocketGuidepdf ace-dido em Abril de 2008
[Con99] Jim Conallen Modeling Web Application Architectures with UML Junho1999 Disponıvel em httpwwwumlorgcnUMLApplicationpdf
webappspdf acedido em Maio de 2008
[Ent07] Entrust What is a public key information 2007 Disponıvel em http
wwwentrustcompkihtm acedido em Junho de 2008
[Gar05] Jesse James Garret Ajax A new approach to web applicationsFebruary 2005 Disponıvel em httpwwwadaptivepathcomideas
essaysarchives000385php acedido em Marco de 2008
[Greon] Philip Greenspun Philip and Alexrsquos Guide to Web Publishing 2003(last revision) Disponıvel em httpphilipgreenspuncompandaacedido em Junho de 2008
[Gro02a] App Design Group Thick vs thin client comparison 2002 Disponıvelem httpwwwdonjacobsvwcomimagesweekendspecials
Thick-vs-Thinpdf acedido em Junho de 2008
57
REFERENCIAS
[Gro02b] Technical Research Group Thin Client Tecnhology - WhitePaper 2002 Disponıvel em httpwwwpicktrgcompubs
thinclientwhitepaperpdf acedido em Junho de 2008
[Gro08] Miniwatts Marketing Group World internet usage March 2008Disponıvel em httpwwwinternetworldstatscomstatshtm ace-dido em Abril de 2008
[Hic08] Ian Hickson HTML 5 Draft Recommendation 2008 Disponıvelem httpwwwwhatwgorgspecsweb-appscurrent-work ace-dido em Marco de 2008
[Kha] Olga Kharif Top 10 municipal wifi plans Disponıvel em http
imagesbusinessweekcomss0608muni_wifiindex_01htm ace-dido em Marco de 2008
[Lab07] Mozilla Labs Prism Outubro 2007 Disponıvel em httplabs
mozillacom200710prism acedido em Marco de 2008
[Loo06] Chris Loosley Rich Internet ApplicationsDesign MeasurementandManagement Challenges 2006 Disponıvel em httpwwwkeynote
comdocswhitepapersRichInternet_5pdf acedido em Maio de2008
[Mic08] Microsoft Introduction to Occasionally Connected Applications us-ing Sync Services for ADONET 2008 Disponıvel em httpmsdn
microsoftcomen-ussyncbb887608aspx acedido em Junho de2008
[Nao08] Erica Naone Offline web applications Abril 2008 Disponıvelem httpwwwtechnologyreviewcomread_articleaspxch=
specialsectionsampsc=emerging08ampid=20245 acedido emAbril de 2008
[NJN00] Jason Nieh Yang S Jae and Naomi Novik A comparison of thin-clientcomputing architectures 2000 Disponıvel em httpwwwnclcs
columbiaedupublicationscucs-022-00pdf acedido em Maio de2008
[OrsquoR06] Tim OrsquoReilly Web 20 compact definition Trying again Dezembro2006 Disponıvel em httpradaroreillycomarchives200612
web-20-compact-definition-tryihtml acedido em Marco de 2008
[OrsquoR09] Tim OrsquoReilly What is Web 20 Design patterns and business modelsfor the Next Generation of Software 20053009 Disponıvel emhttpwwworeillynetcompubaoreillytimnews200509
30what-is-web-20html acedido em Marco de 2008
[Rus06] Alex Russel Comet Low latency data for the browser March Marco2006 Disponıvel em httpalexdojotoolkitorgp=545 acedidoem Marco de 2008
58
REFERENCIAS
[Sad97] Darleen Sadoski Clientserver software architecturesndashan overviewAgosto 1997 Disponıvel em httpwwwseicmuedustr
descriptionsclientserver_bodyhtml acedido em Junho de2008
[Sch96] George Schussel Clientserver past present and future 1996
[Smi07] Kevin C Smith Css filters - will the browser apply the rule July 2007Disponıvel em httpcentriclecomrefcssfilters acedido emMarco de 2008
[vK08] Anne van Kesteren The XMLHttpRequest Object W3C Work-ing Draft 15 Abril 2008 Disponıvel em httpwwww3orgTR
XMLHttpRequest acedido em Abril de 2008
[Wil06] Greg Wilkins Why ajax comet July Julho 2006 Disponıvel emhttpwwwwebtidecomdownloadswhitePaperWhyAjaxhtml ace-dido em Abril de 2008
59
REFERENCIAS
60
Anexo A
Screenshots
Algumas imagens de aplicacoes que utilizam funcionalidades offline ilustrativasda tecnologia abordada neste documento
Figura A1 Dialogo apresentado ao utilizador na primeira activacao das funcionalidadesoffline no Google Docs amp Spreadsheets
61
Screenshots
Figura A2 Na activacao das funcionalidades offline e tambem oferecida a possibilidadeda criacao de alguns atalhos por exemplo no ambiente de trabalho
Figura A3 O Google Docs mantem a todo o momento a possibilidade de alteracao destasdefinicoes ou da anulacao dos servicos offline para um dado computador
62
Screenshots
Figura A4 Apos a instalacao do Gears qualquer visita ao Remember The Milk despoletauma sincronizacao que ocorre automaticamente e sem necessidade de intervencao por partedo utilizador
Figura A5 Apos completar a sincronizacao de dados mesmo que a ligacao a Internetseja perdida o Remember the Milk continua disponıvel no browser (com excepcao dasfuncionalidades que pela sua natureza exigem uma ligacao como por exemplo partilhade tarefas e envio de convites)
63
ccopy Joao Goncalves da Costa 31 de Julho de 2008
Offline Web Applications
Joao Goncalves da Costa
Relatorio de Projecto realizado no Ambito do
Mestrado Integrado em Engenharia Informatica e Computacao
Aprovado em provas publicas pelo juri
Presidente Pedro Ferreira do Souto (PhD)
Arguente Artur Pereira (PhD)
Vogal Teresa Galvao Dias (PhD)
27 de Julho de 2008
Resumo
Este projecto teve como objectivo o estudo das Offline Web Applications (OWAs)e da sua implementacao em web applications ja existentes Neste ambito foi feitauma avaliacao da aplicacao desta tecnologia no WOW uma plataforma integradade gestao de ordens de trabalho desenvolvida pela Critical Software SA ao longodos ultimos 6 anos e implementada uma prova de conceito que permite a utilizacaode um conjunto de funcionalidades base desta web application independentementedo estado da ligacao a Internet
O conceito das OWAs enquadra-se numa tecnologia de Internet que permiteo acesso a um website atraves do browser mesmo na ausencia de uma ligacao arede global e foi considerado pela revista Technology Review como uma das maisimportantes tecnologias emergentes no final de 2007 [Nao08] O estudo efectuado noWOW pretende ser um primeiro passo na compreensao dos problemas associados asua implementacao e respectivas solucoes e tambem da avaliacao dos benefıcios dautilizacao desta tecnologia para os utilizadores finais
A evolucao das tecnologias associadas a Internet a que se assiste continua-mente impulsionou tambem evolucao da forma como a informacao e produzidadistribuıda e armazenada Surgiram novas web applications oferecendo funcionali-dades de criacao e edicao de conteudos que trouxeram consigo a vantagem de tornarpossıvel o acesso a informacao a partir de qualquer lugar mas tambem a desvan-tagem de tornar a ligacao a Internet uma condicao necessaria para que isto acontecaA proliferacao destas aplicacoes a crescente utilizacao da Internet [Gro08] e a adesaoaos seus servicos indiciam a existencia de uma dependencia cada vez maior de umaligacao que nem sempre existe
As OWAs vem assim colmatar esta falha colocando no lado do cliente parte dainformacao que ate agora vinha a ser armazenada no servidor e tornando nao sopossıvel a sua consulta offline como tambem reduzindo a carga no servidor umavez que reduz as transferencias de informacao
Pretende-se neste documento apresentar diferentes formas de como a utilizacaoda tecnologia OWA pode beneficiar as web applications de hoje melhorando o seudesempenho e dando-lhes novas possibilidades de execucao aproximando-as do desk-top
i
ii
Abstract
The main purpose of this project was to study the Offline Web Applications(OWAs) and its implementation in existent web applications With this goal in minda study was conducted to use this technology in WOW an integrated platform forwork orders and work flow management developed by Critical Software over thelast 6 years and implemented a proof of concept which enables the use of a baseset of functionality for this application regardless of the internet connection state
The concept of OWAs is connected with internet technology and allows accessto a website using the browser even if a connection to the internet is not availableThis concept was considered by Technology Review as one of the most importantemerging technologies in the last quarter of 2007 [Nao08] This study conductedover the WOW platform is intended to aid in the comprehension of the problemsand solutions associated to the use and implementation of OWA as well as thebenefits that it brings to the end user
The Internet and Internet technologies are changing the way in which informa-tion is produced distributed and stored New web applications appeared with newcontent creation and edition functionalities and with it the advantage of infor-mation retrieval from any place and time became possible but with the conditionof Internet connection availability With Internet use growing every year [Gro08]content creation is starting to move to this new platform The adoption of web ap-plications for content creation and edition is becoming more popular and it showsa dependency of a connection that is not always present
The OWAs are a way to solve this problem putting on the client side part ofthe information that was traditionally stored on the server and allows it to be seenand manipulated and helps reducing the server load
This document intends to present different ways in which this technology canhelp web applications as we know them improving the their overall performance andgiving them the ability to run on a browser regardless of the Internet connectionavailability
iii
iv
Agradecimentos
A realizacao e os objectivos alcancados neste projecto nao teriam sido possıveissem a colaboracao de inumeras pessoas Agradeco profundamente a todos os quecontribuıram directa ou indirectamente para o seu sucesso
A minha orientadora Professora Teresa Galvao Dias e ao Project ManagerEngenheiro Marcus Neves que me conduziram e acompanharam no desenvolvimentodeste projecto
A toda a equipa do WOW em especial o Pedro Maurıcio Costa e o Fabio Matosque contribuıram para a minha a minha integracao na Critical Software e que sempresouberam responder a todas as minhas questoes
A todos os que constituem a CSW Porto pelo fantastico ambiente de amizadeque me proporcionaram
Aos colegas de curso e a todos os que me auxiliaram na revisao deste documento
Os meus sinceros agradecimentos
Joao Goncalves da Costa
v
vi
Conteudo
1 Introducao 111 Enquadramento 112 Motivacao 213 Ambito 314 Objectivos 315 Estrutura do documento 3
2 Enquadramento do Projecto 521 Evolucao das arquitecturas de software 5
211 Thin-clients 5212 Fat-clients 6213 Arquitecturas cliente-servidor 7
22 Evolucao na Internet 8221 Paginas web estaticas 9222 Paginas web interactivas e paginas web dinamicas 9223 Web 20 e Ajax 11
23 Offline Web Applications 1324 Comparacao 13
3 Estado da arte 1731 Gears 17
311 Arquitectura 17312 Goggle Gears em dispositivos moveis 20
32 Adobe AIR 20321 Seguranca 22322 Assinatura do codigo 22
33 Mozilla Prism 23331 XML User Interface Language 23332 Prism 25
34 HTML 5 2535 Web applications que usam funcionalidades offline 26
351 Google Reader e Google Docs 26352 Remember the Milk 27353 MySpace e WordPresscom 27
36 Escolha da tecnologia 28
vii
CONTEUDO
4 Desenvolvimento 3341 Como ficar offline 33
411 Funcionalidades disponıveis em modo offline 3442 Modos de execucao 35
421 Modo ldquoutilizador deciderdquo 36422 Modo aplicacao decide 36423 Modo ldquoaplicacao assume o estado offlinerdquo 37
43 Sincronizacao de dados 38431 Quando sincronizar 39
44 WOW 4045 Visao geral sobre a arquitectura do WOW 4146 WOW Offline 42
461 Modo ldquoaplicacao deciderdquo com deteccao automatica da ligacao 43462 Implementacao do modo ldquoutilizador deciderdquo 45463 Especificacao do modo ldquoaplicacao assume o estado offlinerdquo 48
5 Resultados e Futuros Desenvolvimentos 5151 Resultados Obtidos 5152 Trabalho Futuro 52
6 Conclusoes 5561 Conclusoes 55
Referencias 59
A Screenshots 61
viii
Lista de Figuras
21 Arquitectura de um sistema thin-client em duas camadas (a esquerda)e em tres camadas (a direita) Note-se a inclusao do servidor (main-frame) na definicao das camadas desta arquitectura devido a fortedependencia cliente-servidor 9
22 Arquitectura de um fat-client em duas camadas (a esquerda) e emtres camadas (a direita) 10
23 Comparacao do modelo de web aplications sıncrono paginas estaticase interactivas abordados nas seccoes 221 e 222 com o modelo deweb applications Ajax (assıncrono) abordado na seccao 223 Figuraadaptada de http www adaptivepath com 15
31 Esquema UML do processo efectuado pelos recursos do Gears do tipoManagedResourceStore para a actualizacao dos conteudos definidosno ficheiro manifesto 29
41 Exemplo de uma arquitectura de uma web application sem uma ca-mada de abstraccao de dados Figura adaptada de http gears
google com 33
42 Exemplo de uma arquitectura de uma web application com uma ca-mada de abstraccao de dados Figura adaptada de http gears
google com 34
43 Exemplo de uma arquitectura de uma web application com uma ca-mada de abstraccao de dados e um data switch Figura adaptada dehttp gears google com 35
44 Esquema grafico ilustrando uma OWA executando no browser uti-lizando um modo de execucao do tipo ldquoaplicacao deciderdquo com de-teccao automatica do estado da ligacao via pedidos Ajax assıncronosa cada cinco segundos 37
45 Detalhe de um conjunto possıvel de estados e respectivas transicoespara uma dada ordem de trabalho no WOW desde a sua submissaono sistema ate a sua conclusao em fecho ou cancelamento Esta figurarepresenta apenas um exemplo ja que o mapa de estados para umaordem de trabalho e dinamico e pode ser alterado por um admin-istrador Figura retirada de uma brochura promocional do WOWCritical Software SA 41
ix
LISTA DE FIGURAS
46 A pagina inicial do WOW apresenta um resumo das ultimas ordensde trabalho enviadas e recebidas Na imagem pode-se observar atransicao do estado online para offline 44
47 Ilustracao do funcionamento do Gears numa web application que uti-liza um motor Ajax Os pedidos HTTP ou HTTPS podem ser inter-ceptados e tratados localmente ou podem ser feitos a uma maquinaremota consoante se verificarem ou nao as condicoes expressas noponto 311 E representado um acesso a uma base de dados local(fornecida pelo Gears) mas a sua utilizacao e opcional 45
48 Neste exemplo do modo ldquoaplicacao deciderdquo o teste da ligacao e feitoe feito a cada cinco segundos O resultado deste teste nao reflectesempre o estado real da aplicacao podendo levar a aplicacao a tercomportamentos indesejaveis Na figura assinala-se um perıodo detempo no qual a representacao interna do estado da ligacao nao cor-responde a realidade 46
49 Pagina de visualizacao do detalhe de uma ordem de trabalho 47410 Esquema UML que expressa os casos de uso do WOW Offline no
modo ldquoutilizador deciderdquo 48411 Esquema UML que expressa os casos de uso do WOW Offline no
modo ldquoutilizador deciderdquo 49412 Esquema UML que expressa o acto de recolha de dados em modo
online e offline recorrendo ao servidor (modo online) e ao sistemade armazenamento de dados local fornecido pelo Gears (modo offline) 50
A1 Dialogo apresentado ao utilizador na primeira activacao das funcional-idades offline no Google Docs amp Spreadsheets 61
A2 Na activacao das funcionalidades offline e tambem oferecida a possi-bilidade da criacao de alguns atalhos por exemplo no ambiente detrabalho 62
A3 O Google Docs mantem a todo o momento a possibilidade de alteracaodestas definicoes ou da anulacao dos servicos offline para um dadocomputador 62
A4 Apos a instalacao do Gears qualquer visita ao Remember The Milkdespoleta uma sincronizacao que ocorre automaticamente e sem ne-cessidade de intervencao por parte do utilizador 63
A5 Apos completar a sincronizacao de dados mesmo que a ligacao aInternet seja perdida o Remember the Milk continua disponıvel nobrowser (com excepcao das funcionalidades que pela sua naturezaexigem uma ligacao como por exemplo partilha de tarefas e enviode convites) 63
x
Lista de Tabelas
21 Comparacao entre thin-clients e fat-clients 7
31 Comparacao das funcionalidades oferecidas pelo Adobe AIR para asplataformas web e desktop 30
32 Resumo da utilizacao de tecnologias OWA em algumas web applica-tions consideradas na analise do estado da arte 31
xi
LISTA DE TABELAS
xii
Glossario
fat-client Cliente que nao depende totalmente de umservidor central para as suas actividadesde processamento e possui frequentementedispositivos de armazenamento de dados
6ndash8
thin-client Cliente que depende de um servidor centralpara as suas actividades de processamento
5ndash8
web application Sistema web (servidor rede HTTPbrowser) onde accoes do utilizador(navegacao e introducao de informacao)afectam o estado logico da aplicacao
i iii1ndash311ndash1517ndash1921ndash232728 3336ndash3842 5556
API Application Programming Interface 10 1718 2326 28
ASP Linguagem interpretada pelo servidorque permite a criacao de paginas webdinamicas Desenvolvida pela Microsoft
11
BSD Berkeley Software Distribution 28
CSS Cascading Style Sheets 12 2021 2324 46
DHTML Dynamic HyperText Transfer Protocol 24DOM Document Object Model 10 12
20 2324
DTD Document Type Definition 24
xiii
Glossario
ECMAScript Padrao de linguagem de programacaodefinido pela Ecma International que orig-inou o JavaScript e o JScript
24
Flash Conteudo interactivo de um ficheiro emformato SWF E desenvolvido pela Adobee visualizado atraves do Adobe FlashPlayer
21
Flex Framework baseada em XML e Action-Script desenvolvida pela Adobe para a pro-gramacao de Rich Internet Applications(RIA)
21
GPL GNU General Public License 23
HTML HyperText Markup Language 1 10ndash12 2124ndash2649
HTTP HyperText Transfer Protocol 2 26
JMS E uma API em Java que permite a troca demensagens entre componentes de software
42
JSON JavaScript Object Notation permite atroca de dados codificados num formatode texto de simples leitura
12 1828 34
LGPL GNU Lesser General Public License 23
Mozilla Prism Browser simplificado e ldquointerpretadorrdquo deeXtensible User Interface Language (XUL)(tambem designado por XULRunner) queacolhe web applications sem a interfacegrafica habitual de um browser
25
MPL Mozilla Public License 23
OCA Occasionally Connected Application 39OWA Offline Web Application i iii
2ndash515 1725 2628 3133 3651 5255 56
PDF Portable Document Format 21
xiv
Glossario
PHP Linguagem interpretada pelo servidorque permite a criacao de paginas webdinamicas mas que pode tambem ser in-vocada a partir da linha de comandos
11
pagina web estatica Pagina web que devolve sempre a mesmaresposta a todos os pedidos para todos osutilizadores e em qualquer contexto
5 9
RIA Rich Internet Applications web appli-cations que apresentam funcionalidadessemelhantes as desktop applications masque mantem a informacao no lado do servi-dor
5 1520 28
RSS Really Simple Syndication 27
SLA Service Level Agreement 40SQLite Segundo a definicao oficial SQLite is a
software library that implements a self-contained serverless zero-configurationtransactional SQL database engine
17
SSB Site Specific Browser 25SSL Secure Sockets Layer 22SWF ShockWave Flash 21
URL Uniform Resource Locator 18
VPN Virtual Private Network 38
WOW Work Orders Web Plataforma de gestaode ordens de trabalho e do seu fluxo de-senvolvida pela Critical Software SA
i iii28 3340ndash434551ndash5356
WWW World Wide Web 11 1214
XBL eXtensible Binding Language 24XHTML eXtensible HyperText Markup Language 12XML eXtensible Markup Language 11 12
23 2428
XSLT eXtensible Stylesheet Language Transfor-mation
12
XUL eXtensible User Interface Language xiv23ndash25
xv
Glossario
xvi
Capıtulo 1
Introducao
Neste capıtulo enquadra-se o tema do projecto introduzindo alguns dos conceitos
nos quais se baseia Apresentam-se as motivacoes ambito objectivos e a estrutura
deste documento
11 Enquadramento
A Internet foi originalmente concebida para ser um espaco de partilha de in-
formacao onde pessoas (atraves de maquinas) pudessem comunicar Na sua origem
as paginas eram estaticas constituıdas por texto formatado em HyperText Markup
Language (HTML) e ligadas entre si [BL96] Hoje encontramos conteudos cada vez
mais complexos e dinamicos incluindo som vıdeo ou streams multimedia [Loo06] e
em 2005 foi introduzido por [OrsquoR09] o termo Web 20
De acordo com [Greon] um website pode pertencer a uma ou varias das seguintes
categorias
bull Documento ndash um website essencialmente estatico onde alteracoes a uma
parte do conteudo nao tem implicacoes no seu comportamento
bull Base de dados ndash um directorio de informacao organizada em categorias
bull Aplicacao ndash um website dinamico que utiliza uma linguagem executada ou
interpretada do lado do servidor e que processa as accoes ou informacao in-
troduzida pelo utilizador para fornecer um servico ou nova informacao
A ultima destas categorias constitui aquilo que e normalmente designado por
web application O conceito utilizado ao longo deste documento e o mesmo que
o introduzido por Jim Coallen em [Con99] que define web application como um
1
Introducao
sistema web (servidor rede HyperText Transfer Protocol (HTTP) browser) onde
accoes do utilizador (navegacao e introducao de informacao) afectam o estado logico
da aplicacao A sua definicao tenta estabelecer que uma web application e um
sistema de software com estado de negocio1 e que a sua interface de interaccao com
o utilizador e distribuıdo atraves de um sistema web
12 Motivacao
A quantidade de informacao que e produzida e armazenada com recurso a es-
tas web applications disponıveis online tais como e-mail blogues ou mesmo docu-
mentacao tornam por vezes a disponibilidade de ligacao uma condicao necessaria
a produtividade e como consequencia desta barreira muitos potenciais utilizadores
opoem-se a adopcao de produtos web em detrimento das tradicionais desktop appli-
cations
Assegurar o acesso a uma ligacao de Internet e hoje muito mais facil A Internet
movel e ja uma realidade e encontra-se amplamente divulgada mas continuam a
existir diversas situacoes nas quais os utilizadores estao privados de uma ligacao
a Internet tais como uma viagem de metro ou de aviao ou quando se encontram
deslocados do seu paıs de origem e nao possuem nenhum plano de subscricao
Uma OWA consiste numa web application que para alem de manter todas as
caracterısticas anteriores se mantem disponıvel mesmo na ausencia de uma ligacao
a Internet e surge como uma tentativa de estreitar as barreiras existentes entre a
web e o desktop Isto significa que devera existir um mecanismo capaz de assegurar
a manutencao do estado logico da aplicacao quando a ligacao com o servidor e
quebrada permitindo ao utilizador continuar a utilizar a aplicacao e que sera capaz
de informar o servidor do estado em que a aplicacao se encontra quando a ligacao for
reposta A principal vantagem que advem desta possibilidade e evidente eliminar
a necessidade da existencia de uma ligacao a Internet para que a aplicacao possa ser
utilizada
Por outro lado a vontade de integracao de funcionalidades tıpicas das desktop
applications nas web applications foi um dos principais factores que impulsionou o
desenvolvimento deste conceito uma vez que obrigou a uma reflexao ldquopara alem
do browserrdquo e a uma adaptacao das arquitecturas existentes que permitisse ou o
acesso a funcionalidades disponibilizadas pelo sistema operativo ou pelo menos a
funcionalidades semelhantes Pretende-se com esta aproximacao tornar possıveis
interaccoes entre o desktop e o browser tais como arrastar um ficheiro para um
formulario web de upload de conteudos melhor suporte para o historico do clipboard
ou ainda o acesso ao sistema de ficheiros local Atingir estes objectivos reflecte-se
1NT business state
2
Introducao
num novo paradigma que reune as vantagens das web applications tais como os
updates instantaneos ou o facto de nao ser necessaria nenhuma instalacao e das
desktop applications como por exemplo persistencia no armazenamento de dados
acesso a funcionalidades do sistema operativo ou integracao e interaccao com outras
aplicacoes sejam elas web applications ou desktop applications
13 Ambito
Este projecto foi realizado na Critical Software SA no ambito do Mestrado
Integrado em Engenharia Informatica e Computacao (MIEIC) da Faculdade de En-
genharia da Universidade do Porto (FEUP) entre os meses de Fevereiro e Julho de
2008
14 Objectivos
Sao objectivos deste projecto
1 Estudar e documentar o tema das OWAs acompanhando os ultimos desenvolvi-
mentos nesta materia
2 Analisar o estado da arte fazendo uma analise crıtica e objectiva sobre as
diversas metodologias existentes
3 Implementar uma prova de conceito que permita a execucao offline de uma
web application documentando todo o processo
4 Estudar a possibilidade de permitir interaccao com a aplicacao (insercoes e
alteracoes aos dados) em modo offline
Em resumo o objectivo deste projecto foi estudar documentar e implementar
uma prova de conceito relacionada com o tema Offline Web Applications (OWA)
Este tema embora nao seja totalmente novo ganhou destaque ao longo do ano de
2007 com o surgimento de diversas ferramentas que se destinam a aproximar web
applications das desktop applications
15 Estrutura do documento
Este documento esta organizado em diferentes seccoes apresentando o projecto
numa sequencia logica organizada da seguinte forma
No capıtulo 1 faz-se uma breve apresentacao do conceito OWAs e do contexto em
que surge Apresenta-se tambem a estrutura do documento e definem-se os
termos e acronimos utilizados
3
Introducao
No capıtulo 2 faz-se uma descricao da evolucao das tecnologias que antecedem as
OWAs e das vantagens e desvantagens de cada uma como forma de enquadra-
mento
No capıtulo 3 analisa-se o estado da arte nesta materia Introduzem-se diversas
tecnologias directamente relacionadas com o tema deste projecto exemplos de
aplicacoes que as usam e as razoes que fundamentam as escolhas de tecnologias
efectuadas
O capıtulo 4 contem o desenvolvimento do projecto Analisa-se a plataforma
WOW de gestao integrada de ordens de trabalho a tecnologia escolhida e
a forma como foi utilizada para implementar a capacidade de execucao offline
O capıtulo 5 descreve os resultado obtidos comparando-os com as expectativas
iniciais do projecto e apresenta desenvolvimentos futuros e possibilidades de
continuacaoaplicacao do conhecimento adquirido
No capıtulo 6 apresentam-se as conclusoes
4
Capıtulo 2
Enquadramento do Projecto
Neste capıtulo apresenta-se um breve resumo da evolucao das arquitecturas de
software cliente-servidor e a forma como estas se comparam a evolucao da Inter-
net procurando estabelecer uma analogia entre o percurso de ambas as tecnolo-
gias Compara-se o comportamento e arquitectura dos thin-clients as paginas web
estaticas a evolucao dos fat-clients as paginas interactivas Web 20 e Ajax e
defende-se que as OWA constituem um proximo passo logico e evolutivo aproxi-
mando a web do desktop Referem-se ainda os principais factores que justificam a
importancia das OWAs e a estreita relacao que tem com as Rich Internet Application
(RIA)s
21 Evolucao das arquitecturas de software
Os termos thin-client e fat-client sao utilizados quer para descrever arquitecturas
logicas (de software) quer para descrever arquitecturas fısicas (de hardware) Neste
capıtulo excepto quando seja dada indicacao em contrario estes termos referem-se
sempre a uma arquitectura logica
Adicionalmente quando se trata de arquitecturas cliente-servidor pode-se estu-
dar a arquitectura desenvolvida do sistema como um todo da arquitectura do servi-
dor ou da arquitectura do cliente Para evitar equıvocos em especial na seccao 213
especifica-se em cada caso qual o sistema estudado
211 Thin-clients
Um thin-client e um computador cliente ou software cliente que no contexto
de uma arquitectura cliente-servidor depende de um servidor central para as suas
5
Enquadramento do Projecto
actividades de processamento e proporciona um canal de entrada e saıda de in-
formacao entre o utilizador e o servidor remoto Este termo quando aplicado a
hardware refere-se habitualmente a um computador que se destina a ser utilizado
como cliente de rede sem armazenamento local e com capacidade de processamento
reduzida [Gro02b] mas o conceito que aqui se analisa refere-se a uma arquitectura
de software que remonta ao inıcio das aplicacoes cliente-servidor
No inıcio da historia da computacao terminais ligavam-se directamente a main-
frames responsaveis por todo o processamento Nesta arquitectura era necessario
desenvolver duas aplicacoes distintas uma aplicacao central no servidor (main-
frame) responsavel pela gestao de toda a informacao e por todas as operacoes de
comunicacao e uma aplicacao de visualizacao instalada no cliente (terminal) O
papel destes terminais era apenas disponibilizar ao utilizador um meio de comu-
nicacao (entrada e saıda) e apresentacao dos resultados do servidor Nao tinham
um papel activo no calculo nem na logica de negocio e frequentemente nao tinham
tambem nenhum mecanismo de armazenamento de dados
Como vantagens esta arquitectura apresenta uma reduzida necessidade de con-
figuracao e manutencao do lado do cliente Uma vez que o centro do processamento
e manipulacao de dados ocorre no servidor existe tambem uma centralizacao da
informacao [NJN00] que introduz um ponto crıtico de falha1 Actualizacoes e novas
funcionalidades sao faceis de distribuir uma vez que requerem apenas alteracoes no
servidor [Gro02a]
212 Fat-clients
Contrastando com os thin-clients nesta arquitectura os clientes implementam
ja uma parte da logica de negocio e sao responsaveis pelo processamento de dados
Estes fat-clients vieram responder a necessidade crescente de aplicacoes com um
nıvel de interactividade e capacidade de configuracao maior que as oferecidas pela
arquitectura thin-client descrita na seccao 211 Apesar de manterem a sua de-
pendencia do servidor podem tambem ser executados sem uma conexao activa uma
vez que dispoe de armazenamento de dados local o que lhes confere a capacidade
de persistencia de dados e do estado de execucao entre cada sessao
Foi disponibilizando este controlo sobre o estado da aplicacao bem como acesso
a recursos locais (por exemplo sistema de ficheiros e perifericos) que surgiram as
primeiras verdadeiras desktop applications No entanto cada cliente tinha que ser
separadamente instalado no computador pessoal de cada utilizador que pretendesse
utilizar ou interagir com a aplicacao e uma actualizacao ao servidor implicava in-
variavelmente uma actualizacao manual tambem no cliente Uma vez que nem todos
1NT single point of failure
6
Enquadramento do Projecto
Thin-clients Fat-clientsNao toma parte no processamento dedados nem possui acesso ao sistema deficheiros
Participa activamente no processa-mento de dados recorrendo ao sis-tema de armazenamento local para ar-mazenamento de dados
Nao mantem registo do estado logicoda aplicacao entre duas sessoes de uti-lizacao
O acesso ao armazenamento localpermite-lhe manter registo do estadologico da aplicacao entre duas sessoes
O thin-client nao necessita de qualquerinstalacao estando ldquopronto a utilizarrdquo
E geralmente necessario instalar aaplicacao para poder interagir com oservidor
Qualquer update no servidor reflecte-seimediatamente por todos os clientes
Embora a aplicacao cliente possa aler-tar para existencia de novas versoes asactualizacoes tem que ser manualmenteinstalados pelo cliente
O software do cliente destina-se apenasa apresentacao de dados e comunicacaocom o servidor sendo portanto de sim-ples implementacao
Como o software do cliente toma parteactiva no processamento de dadosa sua implementacao requer cuidadosadicionais
Grande mobilidade uma vez que todaa informacao e mantida no servidor
Parte da informacao podera estar ape-nas do lado cliente pelo que existemalgumas restricoes a sua mobilidade
Tabela 21 Comparacao entre thin-clients e fat-clients
os utilizadores actualizam regularmente as suas aplicacoes o servidor tem que estar
preparado para lidar com versoes antigas2 ou descontinuar os seus servicos a uma
parte da sua comunidade de utilizadores ate que estes actualizem os seus sistemas
Como os utilizadores passam a utilizar os seus recursos locais para armazenamento
de dados as alteracoes que nao sejam sincronizadas com o servidor estao apenas
disponıveis nos seus computadores pessoais o que introduz uma restricao a mobili-
dade
Pode-se afirmar que as vantagens dos thin-clients sao as desvantagens dos fat-
clients e que as vantagens dos fat-clients sao as vantagens dos thin-clients tal como
se ilustra na Tabela 21
213 Arquitecturas cliente-servidor
Introduzidos os termos thin-client e fat-client interessa reafirmar que ambos
podem ser vistos como arquitecturas cliente-servidor Um cliente define-se como
um solicitador de servicos e um servidor como um prestador de servicos tal como
definido por [Sch96] e [Sad97]
2NT backward compatibility
7
Enquadramento do Projecto
As arquitecturas cliente-servidor sao categorizadas pela modularizacao com que
sao desenhadas sendo consideradas as seguintes camadas
1 Interface grafica (front-end) atraves da qual os utilizadores interagem com
a aplicacao Quando este modulo e implementado separadamente dos outros
dois constitui uma aplicacao thin-client por si so uma vez que nao implementa
regras de negocio (embora possa definir validacoes de formularios de insercao de
dados por exemplo) A informacao introduzida pelo utilizador e enviada para
o servidor que processa o seu pedido e retorna uma resposta Este processo
repete-se ate que o utilizador atinja o seu objectivo ou se desligue do sistema
2 A logica de negocio tambem designada por camada intermedia que imple-
menta as regras de aceitacao e validacao de todos os dados introduzidos pelo
utilizador E tambem a plataforma de comunicacao que une a camada superior
de visualizacao com a camada de acesso a dados
3 A camada de dados inclui quer o sistema de persistencia de dados onde sao
armazenados os dados relevantes como tambem os mecanismos necessarios
para a sua pesquisa seleccao e alteracao
Os thin-clients quando observados no seu conjunto de cliente e servidor podem
ser vistos quer como sistemas de duas camadas quer como sistemas de tres camadas
dependendo apenas da forma como o servidor for implementado No caso de na
implementacao do servidor nao se distinguir a camada de acesso a dados da camada
da logica de negocio sao designados por sistemas de duas camadas Caso seja feita
esta distincao sao designados por sistemas de tres camadas Ambos os casos sao
ilustrados na Figura 21
Historicamente os fat-clients eram implementados numa arquitectura em duas
camadas Possuıam apenas um modulo de visualizacao de dados designado por
camada de interface e um modulo que implementava toda a logica de negocio e
regras de acesso a base de dados No entanto com a introducao de ligacoes mais
rapidas e de computadores pessoais com maior capacidade de processamento e so-
bretudo devido a complexidade crescente das aplicacoes a logica de negocio e a
camada de acesso a dados tornaram-se independentes Este modelo e designado por
arquitectura em tres camadas e e ilustrado na Figura 22
22 Evolucao na Internet
Ao analisar a evolucao das arquitecturas das aplicacoes desenvolvidas para a
Internet podemos encontrar um paralelismo com a historia da arquitectura de soft-
ware
8
Enquadramento do Projecto
Figura 21 Arquitectura de um sistema thin-client em duas camadas (a esquerda) e emtres camadas (a direita) Note-se a inclusao do servidor (mainframe) na definicao dascamadas desta arquitectura devido a forte dependencia cliente-servidor
221 Paginas web estaticas
Uma pagina web estatica devolve sempre a mesma resposta a todos os pedidos
para todos os utilizadores e em qualquer contexto utilizando o hipertexto como
forma de ligacao entre diversas paginas estaticas
A informacao e armazenada num servidor e o papel do cliente e apenas a apre-
sentacao da informacao Esta forma de disponibilizacao de informacao pode assim
ser comparada com os thin-clients descritos na seccao 211 o utilizador acede a
um website estatico para visualizar informacao sem que o cliente tome parte no
processamento A unica diferenca e que no caso da web estatica a informacao ap-
resentada e sempre a mesma enquanto que nos thin-clients era frequente existir a
possibilidade de insercao de dados no cliente e apos o seu processamento servidor
nova informacao poderia ser apresentada O hipertexto e utilizado para ligar as
paginas entre si numa rede de conteudos relacionados e a navegacao sıncrona era
feita atraves de cliques do rato a cada clique uma nova pagina era apresentada
Este modelo sıncrono e ilustrado na Figura 23
222 Paginas web interactivas e paginas web dinamicas
O JavaScript e uma linguagem interpretada de scripting que tem os browsers
como principal ambiente de acolhimento Os browsers utilizam uma Application
9
Enquadramento do Projecto
Figura 22 Arquitectura de um fat-client em duas camadas (a esquerda) e em tres camadas(a direita)
Programming Interface (API) publica para criar ldquoobjectosrdquo responsaveis por reflectir
e disponibilizar o Document Object Model (DOM) para o motor de JavaScript
A utilizacao mais frequente desta linguagem e a escrita de funcoes que sao em-
bebidas ou incluıdas em paginas web e que interagem com o DOM Uma vez que o
JavaScript e executado localmente (na maquina do cliente e nao no servidor) e capaz
de responder rapidamente a accoes do utilizador tornando a execucao de aplicacoes
no browser mais fluıdas o JavaScript pode tambem detectar accoes do utilizador
que o HTML nao pode tal como o pressionar de uma tecla
Em Dezembro de 1995 a Netscape Communications adicionou suporte para o
JavaScript no browser Netscape Navigator3 e em Agosto de 1996 o browser Internet
Explorer4 da Microsoft passou a tambem a suportar uma versao semelhante desta
linguagem (hoje todos os principais browsers suportam esta tecnologia)
Esta inovacao permitiu tornar os websites mais interactivos mas a sua utilizacao
esteve confinada apenas a este proposito durante um longo perıodo As paginas
passaram a responder activamente a accoes do utilizador (sendo uma das utilizacoes
3Netscape Communications ndash httpbrowsernetscapecom4Microsoft Internet Explorer ndash httpwwwmicrosoftcomwindowsproductswinfamilyie
10
Enquadramento do Projecto
mais vulgares a validacao de formularios) mas continuaram essencialmente estaticas
O JavaScript ainda nao era nesta altura utilizado para processar dados
Tambem nesta altura (1995ndash96) surgiram linguagens server-side como o PHP
Hypertext Preprocessor (PHP) e Active Server Pages (ASP) e o servidor passou a ter
um processamento de dados introduzidos pelo utilizador mais activo Generalizaram-
se as paginas dinamicas capazes de responder a insercao de dados ou outros pedidos
determinados por accoes do utilizador As paginas tornaram-se aplicacoes web ap-
plications
Uma definicao tradicional de web application e um conjunto de paginas web
logicamente agrupadas e geridas por uma unica entidade que tem como pontos de
entrada formularios de insercao de dados (web forms) Uma web application nao e
mais do que uma aplicacao que e acedida atraves de um browser Tem geralmente
uma arquitectura logica em tres (interface logica de negocio e camada de dados)
camadas e estao armazenadas num servidor
Ha dois tipos de web applications
bull Orientadas a apresentacao Sao web applications que geram paginas web in-
teractivas constituıdas por varios tipos de linguagens de anotacao (por exem-
plo HTML eXtensible Markup Language (XML)) e que apresentam conteudo
dinamico como resposta a pedidos efectuados pelo utilizador
bull Orientadas aos servicos Uma web application orientada aos servicos imple-
menta o ponto de acesso para um ou mais de um web service Sao geralmente
clientes de service oriented web applications
Uma vantagem significativa de implementar uma web application de forma a
suportar as funcionalidades padrao dos browsers e que estas terao o mesmo com-
portamento independentemente da plataforma e do browser a partir do qual serao
acedidas No entanto diferentes implementacoes de browsers devido a diferentes
interpretacoes dos padroes definidos tornam por vezes esta tarefa um pouco mais
complicada existindo inclusivamente na web guioes de compatibilidade para os difer-
entes browsers como [Smi07]
223 Web 20 e Ajax
O termo web 20 descreve uma tendencia de utilizacao e de design observada
na World Wide Web (WWW) com o objectivo de melhorar a criatividade partilha
de informacao e principalmente a colaboracao entre utilizadores Estes conceitos
levaram ao desenvolvimento e evolucao de comunidades online tais como redes so-
ciais wikis e blogues
11
Enquadramento do Projecto
O termo tornou-se mais conhecido apos a primeira conferencia OrsquoReilly Media
Web 20 em 2004 e apesar de sugerir uma nova versao da WWW nao se refere a
qualquer evolucao tecnologica mas apenas a alteracoes a forma como os utilizadores
se servem da web De acordo com Tim OrsquoReilly [OrsquoR06] ldquoWeb 20 e uma revolucao
na industria do software causada pela adopcao da web como uma plataforma e pela
tentativa de entendimento das regras para o sucesso nesta nova plataformardquo
O desenvolvimento da Web 20 serve-se muitas vezes de um outro conceito Ajax
O conceito que hoje conhecemos como Ajax muitas vezes incorrectamente de-
scrito como uma tecnologia foi originalmente criado para permitir o desenvolvimento
de web applications que se assemelhassem ainda mais a aplicacoes de desktop Este
conceito foi melhor descrito por [Gar05] como um conjunto de varias tecnologias
que podem ser utilizadas para melhorar a experiencia do utilizador de uma dada
web application introduzindo a capacidade assıncrona de envio de pedidos ou da
recepcao assıncrona de respostas As tecnologias mais frequentemente envolvidas
sao
bull eXtensible HyperText Markup Language (XHTML) e Cascading Style Sheets
(CSS) padrao para a apresentacao
bull interaccao dinamica atraves do DOM
bull troca e manipulacao de dados utilizando XML e eXtensible Stylesheet Lan-
guage Transformation (XSLT) ou JavaScript Object Notation (JSON)
bull pedidos assıncronos utilizando XMLHttpRequest [vK08]
bull JavaScript utilizado para integrar todas estas tecnologias
E importante frisar que o Ajax nao e um produto nem uma tecnologia E um
termo que descreve a utilizacao de um conjunto de tecnologias para o desenvolvi-
mento de web applications com um elevado grau de interactividade Comparativa-
mente as web applications tradicionais o Ajax introduz uma camada de visualizacao
diferente em tres importantes pontos
1 Do lado do cliente existe um motor que serve de intermediario entre a interface
da aplicacao e o servidor
2 A actividade do utilizador despoleta chamadas JavaScript em vez de um pedido
de pagina directamente ao servidor
3 Informacao codificada em XML em vez de paginas HTML e trocada entre o
servidor e o cliente
12
Enquadramento do Projecto
Isto significa que as paginas que utilizam Ajax contem um motor do lado do
cliente composto por um conjunto de funcoes JavaScript responsavel pela comu-
nicacao com o servidor e por actualizar a interface com o resultado dessa mesma
comunicacao
Na Figura 23 ilustra-se a natureza assıncrona do Ajax quando comparada com
as web applications tradicionais Como se pode observar adicionando um mecan-
ismo Ajax a uma web application eliminam-se diversos tempos de espera associados
a comunicacoes com o servidor uma vez que a interface nao fica ldquobloqueadardquo a es-
pera da resposta Obtem-se assim aplicacoes com um comportamento mais fluido
eliminando tempos de espera entre cada ldquocliquerdquo e melhorando a experiencia do
utilizador
23 Offline Web Applications
A informacao grafica (bem como folhas de estilo e scripts) tais como as ima-
gens que constituem o visual de uma web application e ja tratada de forma especial
pelos cada vez mais avancados sistemas de cache (armazenamento temporario) dos
browsers Mas estes nao sao ainda capazes de guardar conteudo criado pelo uti-
lizador nem de apresentar informacao independentemente do estado da ligacao
Numa altura onde se fala de servicos de Internet wireless municipalizados [Kha]
comunicacoes 3G e ligacoes de banda larga a alta velocidade a ligacao a rede global
continua a nao estar permanentemente disponıvel para os utilizadores Na WWW
encontra-se uma importante parte da informacao e das aplicacoes utilizadas para
criar e editar conteudos Por vezes informacao vital para a produtividade pode
desaparecer subitamente do mapa de acesso de um utilizador quando este entra no
metro num aviao ou mesmo quando se desloca para uma cidade ou paıs diferente
do habitual onde nao subscreve um plano de acesso que lhe garanta a ligacao
Permitir o acesso offline a estes recursos assume assim a sua importancia porque
permitira estender o alcance da informacao a locais onde nunca esteve antes e per-
mitira tambem melhorar o desempenho das web applications colocando informacao
mais perto dos utilizadores reduzindo a transferencia de dados apenas ao essencial
24 Comparacao
Nas evolucoes descritas neste capıtulo 2 pode-se observar que existe um par-
alelismo entre a evolucao das arquitecturas tradicionais cliente-servidor e a evolucao
a que se assiste na web O comportamento e arquitectura dos thin-clients assemelha-
se ao das paginas estaticas no sentido em que o browser nao toma parte em qualquer
13
Enquadramento do Projecto
processamento e serve apenas como uma plataforma de interaccao com o servidor
tal como os clientes descritos na seccao 211
A sua proxima evolucao os fat-clients trouxeram parte da capacidade de pro-
cessamento para o lado do cliente Na web foi tambem esta a inovacao tecnologica
a que se assistiu com a evolucao das tecnologias que permitiram a criacao de ver-
dadeiras aplicacoes e com a introducao do Javascript no browser dando ao cliente
a capacidade de processamento de dados A necessidade da separacao do codigo
em camadas logicas advem da crescente complexidade das web applications Esta
pratica permite entre outras coisas melhorar o processo de desenvolvimento e a
capacidade de manutencao de uma aplicacao
Os fat-clients tem tambem a capacidade de armazenamento de dados o que
permite a persistencia de informacoes entre duas sessoes e que algumas operacoes
sejam executadas sem a necessidade de comunicacao com o servidor Este facto pode
tambem ser uma realidade nas web applications com a adopcao das tecnologias OWA
Neste momento assiste-se a uma utilizacao cada vez maior da web como uma
plataforma de desenvolvimento A capacidade de cooperacao na edicao de conteudos
e a mobilidade proporcionada por esta plataforma sao os principais factores que
alimentam esta mudanca e pela primeira vez as aplicacoes tradicionais tem com-
peticao vinda de web applications A prova do reconhecimento da web como plataforma
de desenvolvimento pode ser retirada da aposta de empresas como a Adobe e Mi-
crosoft que lancaram publicamente ferramentas web complementares a produtos
seus tradicionalmente associados ao desktop ndash Acrobatcom5 e Microsoft Office
Live6 Dotar estas web applications da capacidade de execucao offline significa
aproximar a web e o desktop reunindo ldquoo melhor de dois mundosrdquo
As vantagens da mobilidade possıvel atraves da web a cooperacao na criacao e
edicao de conteudos e a possibilidade de utilizar aplicacoes sempre actualizadas e
sem necessidade de instalacao sao algumas das principais vantagens que promovem
esta mudanca que devido as preocupacoes associadas a usabilidade e experiencia do
utilizador esta fortemente associada ao desenvolvimento de Rich Internet Applica-
tion (RIA)s
5Adobe Acrobatcom httpwwwacrobatcom6Microsoft ndash httpsmallbusinessofficelivecom
14
Enquadramento do Projecto
Figura 23 Comparacao do modelo de web aplications sıncrono paginas estaticas e in-teractivas abordados nas seccoes 221 e 222 com o modelo de web applications Ajax(assıncrono) abordado na seccao 223 Figura adaptada de http www adaptivepath
com
15
Enquadramento do Projecto
16
Capıtulo 3
Estado da arte
Apesar de o conceito das OWAs nao ser absolutamente novo as tecnologias que
o suportam sao recentes Neste capıtulo descrevem-se quatro tecnologias que foram
tidas como principais candidatas para o desenvolvimento deste projecto Descrevem-
se ainda alguns exemplos de web applications que disponibilizam actualmente fun-
cionalidades offline e o processo da escolha da tecnologia a utilizar neste projecto
31 Gears
O Gears1 e uma extensao as funcionalidades do browser introduzido pelo Google
que tem como principal objectivo tornar possıvel a visualizacao de paginas de Inter-
net mesmo sem uma conexao disponıvel Encontra-se disponıvel para as platafor-
mas Windows Macintosh e Linux e oferece uma API de Javascript que permite
a scripts aceder a um mecanismo de armazenamento local baseado numa base de
dados SQLite
311 Arquitectura
Esta ferramenta e constituıda por tres componentes principais
bull LocalServer mdash Intercepta pedidos de paginas web e serve-as localmente
bull Database mdash Uma base de dados relacional construıda sobre SQLite
bull WorkerPool mdash Permite executar operacoes de computacao de uma forma
assıncrona sem afectar a capacidade de resposta e fluidez de execucao da web
application Assemelham-se a processos
1Google Inc ndash Mais informacao em httpgearsgooglecom
17
Estado da arte
LocalServer
O modulo LocalServer e uma cache de Uniform Resource Locators (URLs)
controlada pela web application Quando nao existe uma ligacao a Internet e e
feito um pedido para um URL presente nesta cache o LocalServer intercepta-o e
responde ao pedido localmente a partir do disco rıgido do utilizador A aplicacao
pode utilizar dois tipos diferentes de armazenamento local de URLs
bull ResourceStore ndash serve para capturar URLs utilizando exclusivamente a API
de Javascript disponibilizada para o efeito Uma aplicacao podera criar e
utilizar diversos ResourceStores simultaneamente para capturar ficheiros de
dados que necessitam de ser enderecados por um URL tal como um ficheiro
PDF ou uma imagem
bull ManagedResourceStore ndash serve para capturar um conjunto de URLs que estao
relacionados e que sao declarado num ficheiro de manifesto (especificado em
JSON) e que sao automaticamente actualizados O ManagedResourceStore
permite que o conjunto de recursos necessarios para correr uma web application
seja capturado e mantido actualizado automaticamente
A principal diferenca entre estes dois tipos de armazenamento de URLs e a forma
como sao actualizados os seus conteudos Os conteudos de um ManagedResourceStore
sao actualizados sempre que a versao contida no ficheiro de manifesto for alterada
enquanto que os conteudos de um ResourceStore nunca sao actualizados automati-
camente mas apenas quando for explicitamente ordenado pela aplicacao
O LocalServer e capaz de interceptar e servir localmente pedidos de HTTP e
HTTPS sempre que se reunam as seguintes condicoes
1 O URL encontra-se armazenado num ResourceStore ou ManagedResourceStore
2 O sistema de armazenamento local encontra-se activo (enabled = true) Se
o sistema de armazenamento local tiver o atributo requiredCookie o pedido
devera conter um cookie que lhe corresponda
O LocalServer nao necessita de monitorizar o estado da ligacao para atender aos
pedidos Na verdade sempre que as condicoes previamente enunciadas se verificarem
o LocalServer interceptara os pedidos e independentemente do estado da ligacao
a Internet servi-los-a a partir do disco rıgido local Cabera a aplicacao definir qual
o modo em que pretende executar um pedido (online ou offline) definindo o valor
de verdade da propriedade enabled
18
Estado da arte
Database
O modulo Database permite guardar dados da web application assegurando a
sua persistencia Os dados sao guardados de forma relacional no disco rıgido do uti-
lizador2 de acordo com o modelo de seguranca estabelecido pelo Gears3 significando
que uma aplicacao nao pode aceder a conteudos fora do seu domınio
WorkerPool
Nos web browsers uma operacao pesada de computacao pode tornar a interface
lenta e tornar menos agradavel a experiencia do utilizador O modulo WorkerPool
permite correr operacoes em background sem bloquear a interface com o utilizador
Os scripts executados numa WorkerPool nao activam os mecanismos de seguranca
do browser que mostram a mensagem ldquoA script on this page may be busy or may
have stopped respondingrdquo
O WorkerPool comporta-se como um conjunto de processos em vez de threads
Os Workers nao partilham qualquer estado de execucao o que significa que uma
alteracao a uma variavel num Worker nao afecta em nada a execucao de outro
Worker Alem disso os Workers nao herdam automaticamente nenhum codigo dos
seus pais Cada Worker e membro de um WorkerPool e os Workers podem in-
teragir entre si enviando mensagens em formato de texto ou JSON No entanto ha
tambem algumas limitacoes os Workers nao tem acesso ao DOM e objectos como
window ou document nao se encontram acessıveis Isto e consequencia de os Workers
nao partilharem o estado de execucao Mas tem acesso a todas as funcoes built-in
do Javascript A maioria das funcionalidades do Gears pode tambem ser acedida
atraves de uma variavel global especial definida como googlegearsfactory Para
outras funcionalidades especıficas os Workers podem ldquopedirrdquo a pagina principal para
continuar a execucao atraves do envio de mensagens
Outras funcionalidades
bull HttpRequest ndash Este modulo implementa a especificacao W3C XmlHttpRe-
quest definida em [vK08] tornando-a disponıvel para os workers e para a
pagina principal
bull Timer ndash Este modulo implementa a especificacao de timers tal como descrito
por [Hic08] e torna-os disponıveis para os workers e para a pagina principal
2Consultar httpcodegooglecomapisgearsapi_databasehtmldirectories3Consultar httpcodegooglecomapisgearssecurityhtml
19
Estado da arte
bull Factory ndash Esta classe e utilizada para instanciar todos os outros objectos da
API do Gears atraves do seu metodo create Este metodo pode ser utilizado
com os seguintes parametros
ndash betadatabase
ndash betahttprequest
ndash betalocalserver
ndash betatimer
ndash betaworkerpool
312 Goggle Gears em dispositivos moveis
O Gears esta tambem disponıvel em dispositivos Windows Mobile 5 e 6
Os dispositivos moveis estao pela sua natureza frequentemente desconectados
da Internet Mesmo quando possuem uma ligacao as latencias na transferencia de
dados em redes moveis tornam as aplicacoes pouco fluıdas mas o Gears permite
ultrapassar este obstaculo
O Gears funciona exactamente da mesma forma em dispositivos moveis equipados
com o Windows Mobile 5 e 6 como num computador comum Se uma aplicacao tiver
sido implementado com suporte para o Gears entao tambem estara preparada para
ser executada num dispositivo movel mas as limitacoes dos browsers disponıveis
para dispositivos moveis tem que ser consideradas Isto significa prever as condicoes
que permitam uma boa usabilidade devido aos pequenos ecras destes dispositivos
bem como o seu suporte limitado dos padroes do DOM CSS e JavaScript
32 Adobe AIR
O Adobe AIR4 e um runtime compatıvel com diversos browsers e sistemas opera-
tivos que pretende dar aos programadores a possibilidade de combinar diversas tec-
nologias de producao de conteudos para a Internet no desenvolvimento de Rich Inter-
net Application (RIA)s O Adobe AIR mantem uma relacao com o browser mas es-
tende as suas capacidades e tecnologias permitindo o desenvolvimento de aplicacoes
tambem para o ambiente de trabalho com janelas em tudo semelhantes as do sis-
tema operativo Segundo a Adobe o objectivo e complementar o browser dando
aos utilizadores (mas essencialmente aos programadores e equipas de desenvolvi-
mento) a escolha sobre como distribuir as suas aplicacoes Para este efeito o Adobe
AIR tem uma aproximacao diferente do Gears Em vez de ldquoestenderrdquo o browser
acrescentando-lhe funcionalidades o AIR permite tambem o desenvolvimento de
4Adobe - httpwwwadobecomproductsair
20
Estado da arte
aplicacoes que se destinam a ser executadas fora do ambiente do browser mas uti-
lizando as tecnologias comuns da Internet (por exemplo HTML CSS JavaScript
Flash Flex)[CDGH08]
A utilizacao desta tecnologia permite utilizar o browser ou o proprio runtime
Adobe AIR como plataforma de execucao da aplicacao
Na Tabela 31 faz-se uma comparacao das funcionalidades disponıveis de acordo
consoante se escolha o browser ou o desktop como plataforma base para a aplicacao
Uma vez que as aplicacoes Adobe AIR na plataforma desktop tem um caracter
persistente (sao instaladas no computador do utilizador) o Adobe AIR tem um
modelo de seguranca que se assemelha com o das tradicionais aplicacoes desktop
[Ada08] Este modelo e analisado nas seccoes 321 e 322 O ambiente em que
e executado o browser e restringido a execucao de web applications que podem
ser de varias origens (incluindo de origens anonimas ou sem confianca) O Adobe
AIR proporciona acesso a capacidades como acesso a ficheiros que necessitam da
confianca do utilizador
bull HTML ndash O desenvolvimento de aplicacoes para o Adobe AIR pode ser feito
com recurso a tecnologias de HTML e Ajax comuns utilizando as linguagens
de markup existentes distribuıdas como texto e interpretadas em execucao
(runtime)
bull Flash ndash Outra alternativa sera a utilizacao da linguagem Flash Permite a
renderizacao de graficos vectoriais e audiovıdeo com suporte nativo Utiliza
ActionScript para adicionar maior interactividade com o utilizador
bull Flex ndash O Flex e uma framework open source para o desenvolvimento de RIAs
usando Flash As aplicacoes Flex sao na realidade Flash sendo a principal
diferenca o ambiente de desenvolvimento
Como resultado uma aplicacao AIR podera ser implementada
bull Baseada em Flash ou Flex (aplicacoes cujo conteudo base e em ShockWave
Flash (SWF))
bull Baseada em Flash ou Flex tambem com HTML ou Portable Document Format
(PDF) Aplicacoes cujo conteudo de base e em FlashFlex (SWF) com HTML
(HTML JavaScript CSS) ou conteudo PDF incluıdo
bull Baseada em HTML Aplicacoes cujo conteudo base e em HTML Javascript
CSS
bull Baseada em HTML utilizando tambem FlashFlex ou PDF
21
Estado da arte
Os utilizadores interagem com uma aplicacao AIR da mesma forma que interagem
com outras aplicacoes com janelas nativas do seu sistema operativo O runtime e
instalado uma vez no computador do utilizador e a partir desse momento todas as
aplicacoes AIR terao o mesmo aspecto que qualquer outra aplicacao para o desktop
321 Seguranca
Permitir que uma web application aceda ao disco de armazenamento do utilizador
pode comprometer seriamente a sua seguranca Neste sentido o Adobe AIR tem
suporte para assinaturas digitais (Secure Sockets Layer (SSL)) que podem ser com-
pradas pelas equipas de desenvolvimento que o desejem e cujos certificados serao
apresentados ao utilizador no momento da instalacao Um outro aspecto ainda
relativo a seguranca e o mecanismo de isolamento de cada ambiente (sandbox )
322 Assinatura do codigo
O runtime AIR exige que todas as aplicacoes estejam digitalmente assinadas As
assinaturas digitais de codigo sao um processo que visa garantir a integridade da
aplicacao e a identidade do seu autor no momento da instalacao As equipas de
desenvolvimento podem ldquoassinarrdquo uma aplicacao utilizando um certificado atribuıdo
por uma Entidade Certificadora (Certification Authority) ou atraves de um certifi-
cado individual (self signed certificate) Neste momento o Adobe AIR suporta como
entidades certificadoras a Verisign e a Thawte [Ado08]
O instalador apresenta o nome de quem publica a aplicacao quando o codigo tiver
sido assinado com um certificado que apresente confianca ou que esteja encadeado
com um certificado que tenha ja sido aceite no computador em que se esta a instalar
a aplicacao
As equipas de desenvolvimento podem tambem assinar as aplicacoes com um
certificado auto-atribuıdo (um certificado criado por elas proprias) mas neste caso
o instalador apresentara estas aplicacoes como sendo de uma origem nao verificada
O AIR utiliza a infraestrutura publica de chaves [Ent07] suportada pelo arquivo
local do sistema operativo Para que a origem da aplicacao seja reconhecida o
computador onde a aplicacao AIR esta a ser instalada tem que confiar directamente
no certificado que foi utilizado para assinar a aplicacao ou confiar num certificado
que esteja num encadeamento logico de certificados confiados e que se ligue desta
forma ao certificado utilizado para assinar a aplicacao
Todas as aplicacoes AIR tem caracterısticas em comum independentemente da
tecnologia utilizada para o seu desenvolvimento (HTMLFlexFlash) No ambito
de uma aplicacao AIR existem um conjunto de APIs que estao disponıveis e que
tornam possıvel o acesso ao sistema local (leitura e escrita) e a recursos de rede que
22
Estado da arte
de outra forma nunca estariam acessıveis a partir de uma web application comum
Cada aplicacao AIR possui tambem diferentes nıveis de isolamento chamados secu-
rity sandboxes dependendo do tipo de conteudo que esta a ser carregado e do seu
objectivo
bull Isolamento ao nıvel da aplicacao5 ndash E a raiz de cada aplicacao AIR Este
nıvel de isolamento permite o acesso a APIs privilegiadas e especıficas do
AIR Em contrapartida e negado o acesso a algumas APIs que poderiam ser
facilmente utilizadas de forma maliciosa contra o utilizador final Importacao
dinamica de conteudos remotos e geralmente proibido e as tecnicas e mecan-
ismos de geracao dinamica de codigo sao fortemente restringidas Apenas
conteudo carregado directamente da directoria base da aplicacao podera ser
colocado neste nıvel de isolamento
bull Isolamento nao especıfico da aplicacao6 ndash contem todo o outro conteudo
que nao tenha sido carregado directamente para o isolamento da aplicacao
Isto inclui conteudo local e remoto Este tipo de conteudo nao tem acesso
directo as APIs do AIR e rege-se pelas mesmas regras tal como se tivesse sido
carregado por um browser a partir da mesma localizacao (por exemplo HTML
carregado a partir de um domınio remoto comporta-se da mesma forma que se
fosse acedido a partir do browser)
33 Mozilla Prism
331 XML User Interface Language
O eXtensible User Interface Language (XUL) e uma linguagem de anotacao
baseada em XML desenvolvida pela Mozilla Foundation que opera em aplicacoes
Mozilla multi plataforma tal como o Firefox O motor Gecko e a unica imple-
mentacao completa desta linguagem que foi desenhada sobre padroes web comuns
como CSS JavaScript e o DOM e permite o desenvolvimento de interfaces graficas
utilizando elementos pre-definidos tais como window box page textbox radio
button entre outros Infelizmente o XUL nao possui qualquer especificacao formal
ou implementacoes de inter-operabilidade para outros motores que nao o Gecko No
entanto a sua implementacao e licenciada em codigo aberto pelas licencas GNU Gen-
eral Public License (GPL) GNU Lesser General Public License (LGPL) e Mozilla
Public License (MPL)
Enunciam-se algumas caracterısticas desta linguagem
5NT application sandbox6NT non-application sandbox
23
Estado da arte
Liguagem de anotacao poderosa baseada em componentes (widgets) O ob-
jectivo do XUL e permitir a construcao de aplicacoes multi-plataforma em
claro contraste com o Dynamic HyperText Transfer Protocol (DHTML) que se
destina ao desenvolvimento de paginas web Por esta razao o XUL esta orien-
tado a componentes tais como janelas botoes e etiquetas em vez de paginas
cabecalhos de texto e ligacoes de hipertexto Investir tempo e esforco para
atingir este mesmo resultado em aplicacoes baseadas em DHTML compromete
frequentemente a complexidade e desempenho da aplicacao
Baseado em padroes O XUL e um dialecto XML baseado no padrao W3C XML
10 As aplicacoes escritas em XUL sao tambem baseadas em especificacoes
W3C adicionais como HTML 40 CSS DOM nıvel 1 e 2 JavaScript 15
incluindo ECMA-262 Edition 3 (ECMAscript)
Portabilidade entre plataformas Tal como HTML o XUL foi desenhado para
ser independente da plataforma em que e utilizado tornando as aplicacoes
facilmente portaveis entre sistemas operativos nos quais o Mozilla e suportado
Uma vez que o XUL oferece um nıvel de abstraccao dos componentes graficos
de interface que disponibiliza implementa a premissa ldquoum codigo para todas
as plataformasrdquo A interface grafica de todos os produtos centrais Mozilla
(browser instant messenger livro de enderecos) e escrita em XUL com um
unico codigo base que suporta todas as plataformas Mozilla
Separacao entre o nıvel de apresentacao e a logica de negocio Uma das
maiores preocupacoes no desenvolvimento para a Internet e a forte ligacao
entre estas duas camadas (interface e logica) Isto constitui um problema sig-
nificativo no desenvolvimento de grandes aplicacoes especialmente quando o
desenvolvimento e feito em ambientes de equipa porque as capacidades de de-
senvolvimento destas duas partes da aplicacao estao muitas vezes espalhadas
por diferentes elementos O XUL permite uma clara distincao entre a definicao
da aplicacao cliente e da logica de implementacao (XUL eXtensible Binding
Language (XBL) e JavaScript) apresentacao (CSS e imagens) internacional-
izacao (Document Type Definitions (DTDs) e etiquetas de texto em lınguas
especıficas guardados em ficheiros properties) O esquema grafico e apre-
sentacao de uma aplicacao XUL pode ser alterado de forma independente da
sua logica ou implementacao e a aplicacao pode ainda ser traduzida (interna-
tionalization) de forma independente da sua logica implementacao ou apre-
sentacao Este grau de separacao resulta em aplicacoes que sao mais faceis de
manter pelos programadores e facilmente adaptadas por designers e tradutores
24
Estado da arte
Facil adaptacao Outro benefıcio que advem do nıvel de separacao entre logica
de negocio e apresentacao oferecido pelo XUL e a facilidade com que se pode
adaptar uma aplicacao para diferentes clientes ou grupos de utilizadores Um
programador pode utilizar a mesma aplicacao base e adapta-la consoante as
necessidades atraves de diferentes temas (skins) e ficheiros de lınguas Desta
forma uma aplicacao escrita e desenvolvida em Ingles pode ser rapidamente
traduzida para Portugues e distribuıda com outra aparencia mais apropriada
ao cliente alvo
332 Prism
O Mozilla Prism e um browser simplificado e ldquointerpretadorrdquo de XUL (tambem
designado por XULRunner) que acolhe web applications sem a interface grafica ha-
bitual de um browser Baseia-se num conceito designado por Site Specific Browser
(SSB) Um SSB e uma aplicacao com um browser embebido desenhado para exe-
cutar apenas uma web application Nao possui os menus e barras de ferramentas
habituais Um SSB tem uma integracao com o sistema operativo e com o desktop
muito mais estreita do que uma web application acedida atraves de um browser uma
vez que e executado em janela propria
O Prism resulta de uma experiencia da Mozilla e visa reduzir as diferencas entre
as desktop applications tradicionais e as web applications Um dos aspectos focados e
a experiencia do utilizador Numa apresentacao oficial e dito que ldquo[o Prism] pretende
ser uma ponte entre as diferencas que existem entre as aplicacoes tradicionais de
desktop e as web applications explorando novos modelos de usabilidade enquanto
que a linha que as separa se continua a definirrdquo [Lab07]
34 HTML 5
A especificacao HTML 5 [Hic08] que se encontra em fase de desenvolvimento
pelo grupo WHATWG pretende ser uma norma de substituicao dos padroes HTML
4 XHTML 1x e do DOM2 HTML Uma das propriedades que o distingue das tec-
nologias que pretende substituir e precisamente o suporte para OWA e armazena-
mento de dados no cliente de uma forma relacional Nao sendo propriamente uma
tecnologia ndashmas antes uma especificacao ndashe aqui mencionada por ter servido como
referencia a diversas implementacoes de funcionalidades offline e por se considerar
que venha a ter um impacto significativo nas implementacoes de diversos browsers
Dion Almaer defendeu no seu blogue que o Gears era uma implementacao do
HTML 5 No seu artigo ldquoGears as a bleeding-edge HTML 5 implementationrdquo [Alm08]
o autor diz que ambos ndasho Gears e o HTML 5 ndashpretendem dar a web caracterısticas
25
Estado da arte
semelhantes e nao encontrar motivo de ldquocompeticaordquo entre as duas mas que en-
quanto o HTML 5 e uma especificacao o Gears e uma implementacao
No entanto tambem e verdade que o HTML 5 cobre muitos outros pontos para
alem das OWA que saem completamente fora do ambito do Gears Se esta es-
pecificacao atingir um estado de maturidade que possibilite a sua adopcao pelos
principais browsers tornando nativo do browser o suporte OWA entao deixara de
fazer sentido a existencia de uma extensao como o Gears
A especificacao HTML 5 disponibiliza duas APIs relevantes para o tema das
OWA
1 Uma base de dados baseada em SQL que permite o armazenamento de dados
do lado do cliente
2 Uma ldquocacherdquo HTTP que garante a disponibilidade das aplicacoes mesmo quando
o utilizador nao possui uma ligacao a Internet
Estas caracterısticas sao as bases da tecnologia das OWA e tem correspondencia
com os pontos analisados nas seccoes 311 e 311
35 Web applications que usam funcionalidades offline
Nesta seccao apresentam-se algumas web applications que actualmente disponi-
bilizam funcionalidades offline Estas aplicacoes foram escolhidas para uma analise
mais pormenorizada por utilizarem o Gears que tal como descrito na seccao 4 foi
a tecnologia escolhida para o projecto
351 Google Reader e Google Docs
O Google Reader7 e um leitor de feeds RSS Permite gerir a subscricao de varios
sites simultaneamente que disponibilizem conteudos neste formato e foi a primeira
web application da Google com uma versao offline publicamente acessıvel (desde
Junho de 2007)
O Google Reader implementa o modo ldquoutilizador deciderdquo oferecendo na sua
interface um botao que permite alternar entre os modos online e offline
O Google Docs8 e uma web application que permite a criacao e edicao de doc-
umentos de texto folhas de calculo e apresentacoes Era ja publico desde Janeiro
de 2008 que o Google estava a desenvolver uma versao OWA desta aplicacao mas o
acesso a uma versao experimental so foi possıvel a partir de 31 de Maio de 2008
7Google Reader - httpreadergooglecom8Google Docs - httpdocsgooglecom
26
Estado da arte
A implementacao das funcionalidades offline nestas duas aplicacoes seguiu difer-
entes aproximacoes principalmente porque o Google Reader apresenta ao utilizador
informacoes que sao fornecidas por fontes externas enquanto que no Google Docs
a informacao e criada e editada pelo utilizador sobre a forma de documentos
A diferente origem da informacao implica que no Google Reader seja necessario
prever casos de excepcao tal como existirem demasiados itens que necessitam de
ser transferidos para o cliente Nao observar este ponto causa um problema grave
de usabilidade e para evitar tempos de espera demasiado longos e uma interface
com pouca capacidade de resposta as accoes do utilizador o Google Reader apenas
transfere para o cliente os dois mil itens mais recentes na transicao para o modo
offline
352 Remember the Milk
O Remember The Milk9 e uma web application desenvolvida por uma equipa
Australiana que proporciona funcionalidades de agenda gestao de tempo e de tare-
fas e foi uma das primeiras aplicacoes independentes do Google a adoptar o Gears
para acessos em modo offline Permite que os seus utilizadores facam uma gestao
de tarefas agrupando-as em listas adicionando-lhes campos de informacao adicional
ou dando-lhes informacao geografica (recorrendo ao servico Google Maps10) Entre
a sua lista de funcionalidades encontra-se ainda a possibilidade de importar e ex-
portar eventos no formato iCalendar (ics) etiquetas (tags) em tarefas publicacao
Really Simple Syndication (RSS) e partilha de categorias de tarefas de acordo com
diferentes nıveis de permissoes de acesso definidos pelo utilizador
353 MySpace e WordPresscom
O MySpace uma das maiores social networks na Internet anunciou recente-
mente que vai disponibilizar uma versao do seu cliente de e-mail que utiliza o Gears
para acelerar o seu desempenho Numa fase inicial estara disponıvel apenas para
utilizadores que tenham cinco mil ou mais mensagens na sua caixa de correio e
permitira efectuar pesquisas muito mais rapido que a sua versao online
O servico de blogs Wordpresscom anunciou tambem o inıcio da utilizacao desta
tecnologia com o fim de melhorar o desempenho A versao que utiliza esta tecnologia
descarrega e armazena no cliente um conjunto de imagens e scripts que passam a
ter preferencia sobre os seus congeneres online e que permitem acelerar o processo
de carregamento da aplicacao e visualizacao de blogs
9Remember The Milk ndash httpwwwrememberthemilkcom10Google Maps ndash httpmapsgooglecom
27
Estado da arte
O MySpace e o Wordpresscom sao dois exemplos da utilizacao da tecnologia
OWA para optimizacao de web application ja existentes Sem pretenderem disponi-
bilizar uma versao que seja totalmente offline fazem uso do Gears para armazenar no
cliente parte dos recursos frequentemente acedidos na visualizacao das suas paginas
36 Escolha da tecnologia
Apos a analise das tecnologias apresentada nas seccoes 31 a 34 foi necessario es-
tudar a adequacao de cada uma delas ao projecto em questao Desde logo e possıvel
observar que nem todas se dedicam apenas a OWA Por exemplo o Adobe AIR
apesar de ter suporte para OWA apenas disponibiliza algumas das funcionalidades
identificadas como mais indicadas para a execucao do projecto quando utilizado
na sua vertente desktop tal como exposto na Tabela 31 mas a utilizacao desta
vertente implicaria o desenvolvimento de novas interfaces e de novas formas de co-
municacao (troca de mensagens XML ou JSON) A vertente web do Adobe AIR
foca-se mais especificamente nas Rich Internet Applications e permite a reutilizacao
do codigo ja existente (exigindo naturalmente a sua adaptacao e a implementacao
das funcionalidades pretendidas)
A tecnologia escolhida para a realizacao deste trabalho foi o Gears sendo que
um dos principais factores a influenciar esta opcao foi a liberdade introduzida pela
sua licenca Berkeley Software Distribution (BSD)11
Considerou-se o funcionamento desta ferramenta extremamente adequando a
aplicacao no WOW uma vez que o seu principal objectivo e precisamente tornar
possıvel a execucao offline de uma pagina web e por virtude deste facto o Gears tem
uma API concisa e de simples aplicacao pratica uma vez que nao possui quaisquer
outros elementos distractores O funcionamento do seu ManagedResourceStore ex-
emplificado na Figura 31 com a capacidade de actualizacao de recursos definidos
num ficheiro manifesto especificado em JSON pesou tambem nesta decisao
11Sobre a licenca BSD consultar httpwwwopensourceorglicensesbsd-licensephp e http
wwwlinfoorgbsdlicensehtml
28
Estado da arte
Figura 31 Esquema UML do processo efectuado pelos recursos do Gears do tipoManagedResourceStore para a actualizacao dos conteudos definidos no ficheiro manifesto
29
Estado da arte
Funcionalidade RIAs no browser RIAs no desktop
Disponibilidadeda aplicacao
As aplicacoes podem ser facil-mente exploradas e utilizadas
As aplicacoes quando instal-adas tem maior grau de fun-cionalidades e persistencia
Instalacao Nao e necessario qualquer tipode instalacao
As aplicacoes sao instaladasatraves do browser ou descar-regadas e instaladas comouma aplicacao tradicional
Actualizacoes Aplicacoes sao actualizadascarregando conteudos paraum website
O AIR disponibiliza uma APIque permite que as aplicacoessejam actualizadas de umaforma
Sistemas opera-tivos suportados
As aplicacoes podem ser exe-cutadas em diversos sistemasoperativos e browsers
As aplicacoes sao multi-plataforma e podem serinstaladas e executadas emdiversos sistemas operativos ebrowsers
Linguagens deprogramacao
Javascript e disponibilizadopelo browser e ActionScripte disponibilizado pelo AdobeFlash Player
Maquinas virtuais deJavascript e ActionScriptcompatıveis com o browser
Capacidade deexecucao embackground
As RIAs podem ser execu-tadas numa janela do browser
As aplicacoes podem ser ex-ecutadas em background edisponibilizar notificacoes talcomo uma aplicacao tradi-cional
Persistencia A actividade esta limitada asessao do browser Quando obrowser e encerrado toda ainformacao e descartada
As aplicacoes sao instaladas eestao disponıveis no desktopPodem armazenar informacaolocalmente e estao disponıveisoffline
Integracao com odesktop
Integracao com o desktop lim-itada devido a restricoes im-postas pelo browser
As aplicacoes podem acederao sistema de ficheiro ao clip-board eventos notificacoesetc
Controlo da inter-face com o uti-lizador
As aplicacoes sao acedidasatraves de uma janela dobrowser que tem os seusproprios controlos e visualgrafico
As aplicacoes tem um vi-sual grafico proprio em janelapropria
Armazenamentode dados
As aplicacoes tem armazena-mento limitado que pode serreescrito pelo browser
As aplicacoes tem acesso a to-talidade do espaco disponıvellocalmente e a uma base dedados com a possibilidade deencriptacao
Tabela 31 Comparacao das funcionalidades oferecidas pelo Adobe AIR para as platafor-mas web e desktop
30
Estado da arte
Aplicacao Modo de execucao utilizadoGoogle Reader Utiliza o modo ldquoutilizador deciderdquo disponibilizando
ao utilizador um botao para alternar entre os modosonline e offline Como lida com informacao recol-hida de fontes externas de natureza frequentementeefemera o processo de sincronizacao apenas transfereos dois mil itens mais recentes quando passa ao es-tado offline Neste modo sao ainda guardadas in-formacoes de itens lidos e etiquetas atribuıdas quesao sincronizadas com o servidor quando o utilizadorvoltar a activar estado online
Google Docs Utiliza o modo ldquoaplicacao deciderdquo permitindo que outilizador edite os conteudos de documentos de textofolhas de calculo e de apresentacoes independente-mente do estado da ligacao desde o momento em queas funcionalidades offline sao activadas A aplicacaofaz pequenas sincronizacoes com o servidor sempre quenecessario
Remember the Milk Utiliza um modo hıbrido entre ldquoaplicacao deciderdquo eldquoutilizador deciderdquo A aplicacao encarrega-se da sin-cronizacao de dados mas disponibiliza um controlona sua interface que permite despoletar manualmenteeste processo para situacoes em que o utilizador fez al-teracoes recentes e pretende usufruir das capacidadesoffline imediatamente
MySpace O MySpace anunciou a utilizacao de mecanismos dearmazenamento de dados no cliente com recurso atecnologias OWA para melhorar o desempenho doseu cliente web de correio electronico nomeadamenteno que diz respeito a operacoes de pesquisa e or-denacao Inicialmente esta funcionalidade estara ape-nas disponıvel para utilizadores com cinco mil ou maismensagens na sua caixa de correio mas nao e aindaclaro se sera disponibilizada uma versao totalmenteoffline
Tabela 32 Resumo da utilizacao de tecnologias OWA em algumas web applications con-sideradas na analise do estado da arte
31
Estado da arte
32
Capıtulo 4
Desenvolvimento
Neste capıtulo introduz-se a aplicacao WOW e apresenta-se o estudo que foi
feito da adequacao de cada tecnologia para a implementacao da funcionalidade of-
fline nesta plataforma Fazem-se diversas consideracoes sobre opcoes a tomar na
concepcao de OWAs e problemas comuns na sua implementacao bem como sug-
estoes para os resolver O WOW e uma aplicacao ja existente de gestao de ordens
de trabalho e do fluxo de tarefas numa empresa ou organizacao
41 Como ficar offline
Na maior parte das web applications de hoje nao existe uma camada de dados
real A aplicacao exemplificada na Figura 41 ao longo da sua execucao acede
directamente a sua unica fonte de dados (o servidor) atraves de chamadas Ajax sem
que exista uma separacao clara destas duas camadas
Para que uma web application seja capaz de ser executada sem uma ligacao
activa a Internet e mantenha o seu caracter dinamico torna-se necessario incluir
Figura 41 Exemplo de uma arquitectura de uma web application sem uma camada deabstraccao de dados Figura adaptada de http gears google com
33
Desenvolvimento
Figura 42 Exemplo de uma arquitectura de uma web application com uma camada deabstraccao de dados Figura adaptada de http gears google com
um mecanismo de armazenamento de dados local seja uma base de dados ou a
capacidade de acesso ao disco No entanto este mecanismo introduz dois problemas
1 Qual das fontes de dados utilizar quando um utilizador faz um pedido de
informacao
2 A necessidade de implementar uma camada de acesso a dados que seja coerente
quer se use o servidor remoto ou local
Por exemplo em vez de a aplicacao Ajax fazer um pedido relativo as contas de
todos os utilizadores em formato JSON directamente ao servidor remoto podera ao
inves fazer o pedido a um objecto intermedio da camada de dados Este objecto
demonstrado na Figura 42 sera responsavel por implementar uma interface de
acesso a base de dados e retornar um objecto JavaScript com uma representacao da
resposta do servidor
Mas a existencia de uma segunda fonte de dados torna recomendavel tambem
a implementacao de uma camada de data switching que em funcao da existencia
de conexao a Internet e da necessidade de actualizacao dos dados decide se faz o
pedido ao servidor remoto ou se fornece os dados presentes localmente Este objecto
apresentado na Figura 43 decidira de forma transparente para o utilizador se le ou
escreve os dados localmente ou se os enviapede ao servidor remoto e pode tambem
iniciar o processo de convergencia de dados e de resolucao de conflitos
411 Funcionalidades disponıveis em modo offline
Por razoes praticas e provavel que nem todas as funcionalidades da aplicacao
possam ser disponibilizadas em modo offline E necessario escolher quais as fun-
cionalidades a disponibilizar no modo offline da aplicacao e implementar a logica
que decide quando utilizar a base de dados local ou o servidor remoto Apesar do
acesso a base de dados local ser muito mais rapido do que aceder ao servidor o
acesso local nem sempre e preferido Ha varias razoes que podem tornar necessario
escolher o acesso ao servidor em vez do acesso local
34
Desenvolvimento
Figura 43 Exemplo de uma arquitectura de uma web application com uma camada deabstraccao de dados e um data switch Figura adaptada de http gears google com
1 A informacao pode ter uma natureza efemera e nao fazer sentido guarda-la
localmente Exemplo dados em tempo real da bolsa de valores de Lisboa
2 Algumas aplicacoes lidam com informacao que so faz sentido na presenca de
uma ligacao Exemplo Instant Messaging
3 A aplicacao podera escolher apenas guardar a informacao acedida mais fre-
quentemente Exemplo para o utilizador poder alterar a lıngua de apre-
sentacao da aplicacao os conteudos terao que ser guardados em todas as
lınguas disponibilizadas pela aplicacao O custo de implementacao de algu-
mas funcionalidades pode nao compensar o benefıcio
4 A capacidade de processamento ou de armazenamento de dados pode inviabi-
lizar algumas funcionalidades offline Exemplo se uma dada funcionalidade
necessita de uma capacidade de armazenamento de dados para alem do razoavel
de um computador pessoal para ser util (visualizador de mapas)
42 Modos de execucao
Um aspecto que e necessario estudar para qualquer web application que se deseje
disponibilizar offline prende-se com tres modos de execucao que devem ser consid-
erados
1 Utilizador decide o modo de execucao A aplicacao tem modos distintos
de execucao para os estados online e offline geralmente indicados na interface
com o utilizador O utilizador e informado do estado da ligacao e participa na
alteracao de estado de execucao da aplicacao interagindo com a sua interface
2 Aplicacao decide o modo de execucao Pode ser implementado na propria
aplicacao um mecanismo de deteccao do estado da ligacao (por exemplo atraves
35
Desenvolvimento
de chamadas Ajax periodicas) transitando de estado e sincronizando automati-
camente Desta forma o utilizador nao precisa de participar na alteracao de
estado a menos que exista um conflito de dados que requeira a sua atencao
3 Aplicacao assume sempre o estado offline Outra hipotese sera imple-
mentar uma web application que assume sempre estar na ausencia de uma
ligacao ao servidor de dados Esta aplicacao responde aos pedidos do uti-
lizador efectuando pedidos de informacao ao servidor mas nao dependendo
de uma resposta valida para mostrar a informacao que ja tinha disponıvel an-
teriormente A sincronizacao de dados com o servidor e tentada sempre que
existam dados para submeter e uma accao do utilizador
421 Modo ldquoutilizador deciderdquo
Neste modo de execucao quando a aplicacao esta online comunica com o servidor
remoto quando esta offline comunica com a base de dados local A informacao tem
que ser sincronizada sempre que se muda de modo A principal vantagem desta opcao
e que e a mais simples de implementar mesmo para uma aplicacao ja existente e
portanto uma forma expedita de disponibilizar uma OWA No entanto tem tambem
algumas desvantagens que devem ser consideradas
1 O utilizador tem que se lembrar de fazer a alteracao de estado de execucao
Caso contrario podera estar a trabalhar inadvertidamente numa versao offline
com dados antigos ou nao ter a informacao necessaria se perder subitamente
a ligacao
2 Se a ligacao for intermitente o utilizador tera ou que escolher um dos modos
de execucao ou estar constantemente a trocar
3 Uma vez que a base de dados nao esta sempre actualizada nao podera ser
utilizada para melhorar a rapidez de execucao da aplicacao quando em modo
online
422 Modo aplicacao decide
A deteccao do estado da ligacao pode ser implementada atraves de um pedido
assıncrono ao servidor tal como ilustrado na Figura 44 O resultado deste pedido
definira o estado online (em caso de sucesso) ou offline (em caso de falha) A
sincronizacao de dados podera ser feita sempre que ocorra uma transicao do es-
tado offline para o estado online No entanto este metodo nao se revela eficiente
36
Desenvolvimento
Figura 44 Esquema grafico ilustrando uma OWA executando no browser utilizando ummodo de execucao do tipo ldquoaplicacao deciderdquo com deteccao automatica do estado daligacao via pedidos Ajax assıncronos a cada cinco segundos
para grandes aplicacoes uma vez que requer a troca de mensagens demasiado fre-
quentes com o servidor que se destinam exclusivamente a monitorizacao do estado
da ligacao
423 Modo ldquoaplicacao assume o estado offlinerdquo
Uma aplicacao transparente funciona assumindo sempre que esta em modo of-
fline ou pelo menos que pode perder a ligacao a qualquer momento Neste modo
tira-se o maximo partido do armazenamento local e fazem-se pequenas mas contınuas
sincronizacoes com o servidor sempre que este esteja disponıvel A sincronizacao de
dados tambem e feita sempre que se volta ao estado online
As vantagens de uma web application transparente sao as seguintes
bull Uma melhor experiencia para o utilizador uma vez que este nao tem que se
preocupar com o estado da ligacao ou com a transicao de estados
bull A aplicacao funciona de forma coerente mesmo que a ligacao seja intermitente
bull Uma vez que o armazenamento local e mantido actualizado pode ser utilizado
para melhorar o desempenho da aplicacao
Foram identificadas as seguintes desvantagens
bull E mais difıcil de implementar e a sincronizacao acarreta cuidados especiais
bull E necessario um cuidado adicional para evitar que as operacoes de sincronizacao
frequentes que ocorrem automaticamente nao afectem os tempos de resposta
da aplicacao
bull Os testes a aplicacao sao mais complexos uma vez que a sincronizacao de dados
nao ocorre em resposta a uma accao do utilizador
37
Desenvolvimento
43 Sincronizacao de dados
A sincronizacao de dados consiste na capacidade de identificar e transferir pe-
riodicamente a versao mais actual dos dados entre o cliente e o(s) servidor(es)
Independentemente do modo de execucao escolhido e mesmo do estado da ligacao
do utilizador a informacao armazenada localmente e a informacao armazenada no
servidor estarao por vezes dessincronizadas Isto podera acontecer sempre que por
exemplo
bull O utilizador faz alteracoes em modo offline
bull A informacao e partilhada e pode ser alterada por uma entidade externa
bull A informacao e fornecida por uma entidade externa
Resolver estas diferencas de forma a que a informacao local e remota encontrem
a igualdade chama-se sincronizacao de dados Ha varias aproximacoes possıveis
para este efeito que dependem da natureza da aplicacao cada uma com vantagens
e desvantagens
A capacidade de suportar a mobilidade dos utilizadores torna-se cada vez um
ponto mais importante de uma web application Para uma organizacao de dimensao
global e vital garantir que os seus colaboradores tem acesso a mesma informacao
que tem disponıvel nos seus postos de trabalho mesmo quando estao fora Na maior
parte dos casos estes colaboradores terao acesso a um computador portatil um
desktop Smartphone ou PDA e atraves destes poderao ter acesso a sua informacao
directamente atraves de ligacoes encriptadas Virtual Private Network (VPN) de um
servidor web ou de outro mecanismo de rede
Esta solucao e simples de implementar mas infelizmente para a maioria dos
colaboradores com grande factor de mobilidade nao e satisfatoria As principais
desvantagens sao as seguintes
bull Requisitos de ligacao Para permitir que os utilizadores acedam a sua in-
formacao e necessario garantir a capacidade constante de comunicacao pelo
menos durante o tempo necessario que assegure a sua transferencia
bull Velocidade de ligacao sem persistencia de dados e em ligacoes de fraca
qualidade a usabilidade por vezes torna-se inaceitavel
bull Ponto crıtico de falha Com este tipo de solucao todos os utilizadores de-
pendem da base de dados que armazena informacao vital para o funcionamento
do cliente
38
Desenvolvimento
bull Scalability do servidor A medida que novos utilizadores sao adicionados ao
sistema o desempenho do servidor e afectado levando a necessidade de maior
capacidade de armazenamento eou processamento
De acordo com a documentacao da Microsoft Sync Framework [Mic08] uma
solucao alternativa consiste em implementar uma Occasionally Connected Appli-
cation (OCA) Uma OCA permite a um utilizador remoto continuar a aceder a
sua informacao mesmo depois de perder a ligacao mas em vez de recorrer a um
servidor recorre a informacao armazenada no seu dispositivo local Para preencher
localmente a informacao que o utilizador necessita uma OCA possui mecanismos
de sincronizacao de dados que sao oferecidos por esta framework
431 Quando sincronizar
Uma das solucoes mais simples de implementar passa por disponibilizar um
mecanismo manual que despoleta a sincronizacao Diz-se manual porque e o uti-
lizador que escolhe quando sincronizar e pode ser implementada simplesmente
fazendo o upload de toda a informacao para o servidor e depois fazendo o download
da copia mais recente da informacao antes de voltar a ficar offline Para que esta
seja uma opcao viavel e necessario que
bull O volume de dados seja suficientemente pequeno para que possa ser transferido
do servidor para o cliente num espaco de tempo aceitavel
bull Que o utilizador indique explicitamente que quer mudar para o estado offline
ou online pressionando um botao da interface
Contudo podem ser identificados alguns problemas relacionados com esta abor-
dagem
bull Os utilizadores nem sempre podem prever o estado das suas ligacoes A ligacao
pode-se perder subitamente ou ter um caracter intermitente
bull O utilizador pode esquecer-se de efectuar a sincronizacao
Outra opcao sera conjugar a sincronizacao de dados com o modo de execucao
transparente A sincronizacao ocorre automaticamente em background de forma
nao intrusiva para o utilizador A aplicacao comunica com o servidor regularmente
efectuando pequenas trocas de dados com o objectivo de manter o sincronismo da
informacao local e remota Esta abordagem pode ser implementada com pedidos
Ajax assıncronos e regulares ao servidor o que permite manter a interaccao com a
interface fluıda evitando bloqueios Estes pedidos sao feitos prevendo as situacoes
39
Desenvolvimento
de disponibilidade ou indisponibilidade (timeout) do servidor Uma outra opcao
sera permitir que o servidor comunique essas alteracoes utilizando Comet1 tal como
descrito em [Wil06] e [Rus06] As vantagens destas aproximacoes sao
bull A informacao esta disponıvel a qualquer altura que o utilizador decida ficar
offline ou que a ligacao seja acidentalmente perdida
bull O desempenho da aplicacao pode ser melhorado quando se estiver a utilizar
uma ligacao a Internet lenta uma vez que o acesso a dados locais e mais
eficiente do que a consulta de dados ao servidor
44 WOW
O WOW e uma plataforma integrada de gestao de ordens de trabalho ja ex-
istente e desenvolvida pela Critical Software SA a qual se pretende adicionar a
capacidade de execucao offline Esta aplicacao e extremamente dinamica e con-
figuravel com um conjunto extremamente rico de funcionalidades das quais se
destacam
bull Gestao de Ordens de Trabalho ndash suportando a gestao dos pedidos desde a
sua criacao ate ao seu fecho tomando em conta os diferentes tipos de pedidos
(ordens de trabalho pedidos de informacao melhorias resolucao de problemas
etc) e diferentes tipos de accoes possıveis para cada um (Figura 45)
bull Monitorizacao de alteracoes ndash Historico de mudancas anexos e estados criando
relatorios de alteracao automaticamente (o que por quem e quando)
bull Uso de Service Level Agreements (SLAs) ndash E possıvel associar a um pedido um
SLA que define qual o perıodo de tempo atribuıdo a resolucao de um pedido
controlando e agilizando a resolucao do mesmo
bull Utilizacao de queries de utilizador configuraveis que permitem acesso rapido
a determinadas ordens de trabalho de acordo com o filtro configurado (por
exemplo ldquoPara mimrdquo ldquoPara o Grupordquo ldquoPelo Grupordquo)
bull Gestao do relacionamento entre pedidos
bull Pesquisa e filtragem de ordens de trabalho
bull Exportacao de dados em formatos padrao (PDF DOC ou XLS)
bull Integravel com solucoes externas
40
Desenvolvimento
Figura 45 Detalhe de um conjunto possıvel de estados e respectivas transicoes para umadada ordem de trabalho no WOW desde a sua submissao no sistema ate a sua conclusaoem fecho ou cancelamento Esta figura representa apenas um exemplo ja que o mapa deestados para uma ordem de trabalho e dinamico e pode ser alterado por um administradorFigura retirada de uma brochura promocional do WOW Critical Software SA
A utilizacao de uma ferramenta deste tipo por parte de uma empresa ou orga-
nizacao oferece vantagens quer a gestao de topo quer aos colaboradores individuais
para os colaboradores individuais o WOW e uma aplicacao onde estao registadas
todas as tarefas contribuindo activamente para o desenvolvimento em ambientes
multi-tarefa e para a organizacao pessoal das tarefas de acordo com prioridades
Para a gestao de topo esta ferramenta permite obter uma visao global do estado da
organizacao em termos de tempo gasto por tarefa executada sendo uma mais valia
para a previsao e gestaoalocacao de recursos
45 Visao geral sobre a arquitectura do WOW
O WOW e interessante nao so do ponto de vista de produto como tambem do
ponto de vista de plataforma Existem diversos plug-ins que estendem as funcional-
idades do WOW e existem ate projectos que pretendem usar a arquitectura do
WOW para criar produtos com fins diferentes do inicial (por exemplo o WOW-
Storm ndash um sistema de registo e classificacao social de ideias)
De modo a conseguir ter essa expansibilidade a plataforma WOW assenta sob
uma arquitectura distribuıda modular e expansıvel com uma componente central
ndash o core ndash estruturado em camadas logicas E no core que se situam todas as
1O Comet e um conceito semelhante ao Ajax introduzido por Alex Russel mas no qual e o servidor quetoma a iniciativa de ldquoenviarrdquo os dados ao browser sem que este tenha que efectuar um pedido Tambem econhecido por Ajax Push Reverse Ajax ou HTTP Streaming
41
Desenvolvimento
funcionalidades base da aplicacao quer a nıvel logico funcional e de apresentacao
quer a nıvel de gestao e configuracao
E possıvel a execucao de varias instancias do core simultaneamente em servidores
distintos o que permite a alta escalabilidade e disponibilidade desta aplicacao A
consistencia dos dados fica sempre garantida atraves da partilha da base de dados
e pelo balanceamento dos pedidos uma vez que cada um e encaminhado para uma
unica instancia
O WOW apresenta tambem a vantagem de ser uma plataforma extensıvel E
possıvel adicionar novas caracterısticas a plataforma atraves de componentes que se
podem ser divididos em duas categorias plugins e connectors
Os plugins sao componentes que se encontram no mesmo no fısico que a aplicacao
partilhando do mesmo contexto de execucao do core Sao assim uma forma mais
directa de obter informacao da plataforma visto que nao possuem restricoes de
acesso aos dados nem dependencias externas A arquitectura deste componente tera
assim que permitir varias execucoes instanciadas cada uma associada a um core
Por outro lado os connectors sao componentes que se encontram distribuıdos
comunicando externamente com o core Quer a sua execucao quer a obtencao
dos dados estao assim dependentes de interfaces de comunicacao externas que a
plataforma disponibiliza Estes componentes ao contrario dos plugins sao instan-
ciados unicamente e recorrem ao protocolo de comunicacao Java Messaging Service
(JMS) para comunicar com o core
46 WOW Offline
Para alem das opcoes tomadas relativamente a tecnologia a utilizar surgiu
tambem a necessidade de optar por um dos modos de execucao apresentados na
seccao 42
Das tres opcoes possıveis foi o modo ldquoaplicacao assume o estado offlinerdquo descrito
na seccao 423 que mereceu a maior atencao uma vez que reune as vantagens de
uma experiencia mais positiva para o utilizador (uma vez que este nao tem que
participar activamente na alteracao do modo execucao como descrito na seccao 421)
e nao constitui uma sobrecarga excessiva para servidor (como o modo abordado na
seccao 422)
No entanto esta opcao comprometia a complexidade da implementacao para alem
dos objectivos propostos para este projecto e para cumprir o prazo dado foi tomada
a decisao de implementar o modo ldquoutilizador deciderdquo especificando apenas de forma
teorica o modo ldquoaplicacao assume o estado offlinerdquo
As caracterısticas do Gears foram ja descritas na seccao 31 Na Figura 47
mostra-se a sua forma de funcionamento quando integrado numa web application
42
Desenvolvimento
Nesta figura representa-se o modulo LocalServer do Gears como um ponto de de-
cisao Aqui sao testadas as condicoes que determinam se o pedido sera interceptado e
servido localmente ou se prossegue para uma maquina remota E tambem represen-
tada uma base de dados que corresponde ao modulo Database mas que podera nao
ser utilizada Este modulo tal como o modulo Workerpool tem caracter opcional
e sao utilizados consoante os requisitos da aplicacao
A plataforma WOW lida com mais dados do que e necessario passar para o
lado do cliente Em conformidade com o ja exposto na seccao 411 volta-se a
frisar que nao se pretende recriar toda a logica de negocio nem os conteudos da
base de dados no cliente pela sua complexidade e volume de dados Pretende-se
pelo contrario permitir que os utilizadores tirem partido da capacidade de poder
consultar as suas ordens de trabalho quando nao dispoe de uma ligacao transferindo
apenas o essencial para isto seja possıvel
A pagina inicial do WOW apresenta um resumo das ordens de trabalho abertas
ndash enviadas e recebidas ndash que se pretende permitir visualizar offline (ver Figura 46)
Como prova de conceito foi efectuada uma abordagem pragmatica das varias possi-
bilidades descritas na seccao 42
461 Modo ldquoaplicacao deciderdquo com deteccao automatica da ligacao
A primeira abordagem estudada para a disponibilizacao das funcionalidades of-
fline foi o modo ldquoaplicacao deciderdquo com deteccao automatica de ligacao apresentado
na seccao 422 Para que isto seja possıvel foi implementado um mecanismo de ver-
ificacao periodica do estado da ligacao atraves de chamadas Ajax assıncronas O
resultado destes pedidos determina o estado da aplicacao executando as tarefas de
sincronizacao de dados sempre que pertinente Este metodo embora imediato e
simples de implementar depressa se revelou inadequado para o projecto devido ao
elevado consumo de recursos do servidor que a utilizacao intensiva faz esperar a
comunidade da plataforma WOW no principal cliente excede os 7000 utilizadores
Foi estimado que para uma utilizacao de fluidez aceitavel o estado da ligacao deveria
ser testado a cada cinco segundos Assumindo uma adesao (previsao pessimista) de
1 aos servicos offline assistir-se-ia a cerca de 840 pedidos adicionais por minuto
Mas o principal problema desta aproximacao prende-se com o facto de a ver-
ificacao ser feita em intervalos de tempo discretos levando a possibilidade de a
aplicacao poder ter em dado momento uma representacao errada do seu estado
real da ligacao Este problema e ilustrado na Figura 48 onde se ve claramente a
discrepancia entre o estado real da ligacao e a representacao interna que esta tem
Note-se que nesta janela de tempo qualquer accao do utilizador que exija uma
resposta sıncrona do utilizador leva-lo-a para um ldquobeco sem saıdardquo onde nao tera
43
Desenvolvimento
Figura 46 A pagina inicial do WOW apresenta um resumo das ultimas ordens de trabalhoenviadas e recebidas Na imagem pode-se observar a transicao do estado online para offline
acesso a versao offline porque a aplicacao nao fez a transicao automatica nem acesso
a versao online porque na verdade nao possui uma ligacao O que acontecera nesta
situacao sera uma tentativa de acesso ao servidor por parte da aplicacao numa
altura em que este se encontra indisponıvel e o resultado sera uma mensagem de
ldquopedido excedeu o tempordquo apresentado pelo browser Este e um estado sem retorno
porque apos o browser apresentar esta mensagem todos os recursos JavaScript ficam
indisponıveis tornando impossıvel o regresso ao estado anterior ou o tratamento do
erro de qualquer outra forma No entanto as chamadas Ajax podem ser tratadas de
forma especial para a eventualidade de falha e portanto nao constituem problema
44
Desenvolvimento
Figura 47 Ilustracao do funcionamento do Gears numa web application que utiliza ummotor Ajax Os pedidos HTTP ou HTTPS podem ser interceptados e tratados localmenteou podem ser feitos a uma maquina remota consoante se verificarem ou nao as condicoesexpressas no ponto 311 E representado um acesso a uma base de dados local (fornecidapelo Gears) mas a sua utilizacao e opcional
462 Implementacao do modo ldquoutilizador deciderdquo
Este modo de execucao foi ja descrito na seccao 421 e a sua principal carac-
terıstica e ser o utilizador a decidir se a aplicacao deve utilizar um servidor remoto
ou a maquina local como fornecedor de dados
Relativamente ao WOW o WOW Offline na vertente ldquoutilizador deciderdquo vem
alterar os seus casos de uso dando ao utilizador a possibilidade de alterar o estado
de execucao da aplicacao (entre online e offline) Resta dizer que no modo online se
mantem todas as funcionalidades anteriores e que no modo offline torna-se possıvel
visualizar os conteudos da pagina principal do WOW (Figura 46) e os detalhes das
ordens de trabalho (Figura 49) tal como expressa a Figura 410
Esta aproximacao foi utilizada na prova de conceito do WOW adicionando um
controlo a interface desta aplicacao que permite ao utilizador alternar entre os esta-
dos online e offline Na transicao de online para offline sao descarregados os recursos
necessarios para a execucao desta aplicacao sem recorrer a Internet Para o fazer
45
Desenvolvimento
Figura 48 Neste exemplo do modo ldquoaplicacao deciderdquo o teste da ligacao e feito e feito acada cinco segundos O resultado deste teste nao reflecte sempre o estado real da aplicacaopodendo levar a aplicacao a ter comportamentos indesejaveis Na figura assinala-se umperıodo de tempo no qual a representacao interna do estado da ligacao nao corresponde arealidade
e utilizado um recurso ResourceStore e um ManagedResourceStore (introduzidos
em 311) O primeiro e utilizado para armazenar a pagina principal do WOW ndash do-
ravante designada por homejsp ndash e o segundo e utilizado para armazenar imagens
folhas de estilo CSS e scripts JavaScript
Para a implementacao deste modo de execucao foram identificadas as seguintes
tarefas
1 Guardar informacao que permita a recriacao das paginas que se pretende
disponibilizar offline (utilizando o Gears)
2 Disponibilizar um controlo que permita alterar o estado de execucao atraves
da interaccao com a pagina principal
3 Durante a sincronizacao de dados apresentar o progresso da transferencia de
dados
O primeiro passo consistiu na identificacao de todos os conteudos que sao necessarios
transferir para a execucao offline Foi utilizado um recurso do Gears do tipo
ManagedResourceStore que recorre a um ficheiro manifesto para identificar to-
dos os ficheiros que deve transferir Este recurso e gerido automaticamente pelo
Gears transferindo para o cliente a versao mais recente sempre que e necessario
isto e sempre que exista um ficheiro manifesto com uma identificacao de versao que
seja diferente da actualmente disponıvel no cliente Uma vez identificados todos
ficheiros necessarios para a execucao offline num (ou mais) ficheiros manifesto o
Gears encarrega-se da sua actualizacao mas o preenchimento destes ficheiros man-
ifesto e manual o que se traduz num cuidado extra na manutencao da aplicacao
A forma como esta informacao e guardada deve tambem ser cuidadosamente
estudada A opcao mais flexıvel passa por utilizar o modulo Database apresentado
na seccao 311 e guardar a informacao de uma forma relacional Para a recriacao
das paginas pode ser disponibilizada uma versao HTML da pagina que funciona
46
Desenvolvimento
Figura 49 Pagina de visualizacao do detalhe de uma ordem de trabalho
como template nao possui quaisquer dados e e utilizada apenas em modo offline E
preenchida para cada pedido retirando os dados relevantes da base de dados
O modelo de dados do WOW torna esta opcao extremamente trabalhosa uma
vez que as entidades envolvidas na geracao de cada pagina de informacao sobre
cada ordem de trabalho tem relacoes de dependencia complexas seguindo padroes
muito variaveis Por exemplo em cada ordem de trabalho existe um formulario que
permite a sua progressao de estado com diversos campos opcionais e obrigatorios
este formulario e definido pelo administrador e esta relacionado nao apenas com o
tipo de ordem de trabalho mas tambem com o estado actual em que esta se encontra
e a accao que se pretende realizar O elevado numero de combinacoes de tipos de
ordem de trabalho estados e accoes que existem num dado momento juntamente
com a sua possibilidade de alteracao obrigariam a implementacao de uma logica de
negocio complexa o que esta fora do ambito deste projecto
47
Desenvolvimento
Figura 410 Esquema UML que expressa os casos de uso do WOW Offline no modoldquoutilizador deciderdquo
463 Especificacao do modo ldquoaplicacao assume o estado offlinerdquo
A aproximacao para o modo ldquoaplicacao assume o estado offlinerdquo foi tambem
dividida em varias tarefas
1 Guardar informacao que permita a recriacao da pagina principal do lado do
cliente no estado offline (utilizando o Gears)
2 Dotar a aplicacao do cliente de um mecanismo de deteccao da ligacao
3 Identificar os ldquomomentos chaverdquo em que devera ocorrer sincronizacao de dados
4 Implementar a sincronizacao de dados
A sincronizacao de dados deve ser feita em ambas as transicoes online-offline e
offline-online quer para transferir novos dados do servidor (os pedidos podem ser
alterados por outros utilizadores) quando se transita do estado quer para comunicar
eventuais alteracoes feitas em modo offline
Relativamente ao WOW o WOW Offline na vertente ldquoaplicacao assume o es-
tado offlinerdquo vem alterar os seus casos de uso dando ao utilizador a possibilidade
de activar esta funcionalidade A partir do momento que a funcionalidade esta ac-
tivada o utilizador deve tambem ter a possibilidade de gerir algumas preferencias
relacionadas com privacidade de dados Devera ter a hipotese de desactivar o ar-
mazenamento local e de remover todos os dados ja armazenados tal como descrito
na Figura 411
48
Desenvolvimento
Figura 411 Esquema UML que expressa os casos de uso do WOW Offline no modoldquoutilizador deciderdquo
A primeira vez que o WOW Offline e acedido por um cliente e caso seja detec-
tada a presenca do Gears todos os recursos necessarios a sua execucao sao trans-
feridos Todos os acessos posteriores serao feitos a estes recursos locais (recorda-se
que o Gears pode ser utilizado para os manter actualizados recorrendo ao Managed-
ResourceStore 311)
Atraves do JavaScript e possıvel interceptar os eventos de load e unload da
pagina que sao despoletados sempre que ocorre um re-acesso da mesma (incluindo
a accao refresh comum dos browsers) sempre que esta e abandonada ou ainda ou
ainda se a janela for encerrada
Tal como sugerido na seccao 462 a camada de interface desta aplicacao (cada
pagina individual em HTML) devera ser implementada como sendo um template
para apresentacao de dados sendo totalmente preenchida atraves de funcoes em
JavaScript O objectivo deste ponto e criar um padrao de dados que permita ao
JavaScript preencher os dados em cada pagina (template) independentemente de
qual seja a fonte ndash o servidor remoto ou a maquina local tal como exemplificado
no diagrama da Figura 412 Na figura a aplicacao recorre ao servidor remoto para
obter os dados pretendidos quando se encontra na presenca de uma ligacao mas
para dados que exijam uma carga de processamento pelo servidor este acto pode ser
49
Desenvolvimento
Figura 412 Esquema UML que expressa o acto de recolha de dados em modo online eoffline recorrendo ao servidor (modo online) e ao sistema de armazenamento de dadoslocal fornecido pelo Gears (modo offline)
substituıdo pelo envio de um campo de controlo que se destina a aferir se os dados
locais se encontram actualizados No caso de estarem actualizados a comunicacao
com o servidor pode ser substituıda por uma query a base de dados local
50
Capıtulo 5
Resultados e Futuros
Desenvolvimentos
Todo o estudo feito sobre o tema OWA foi ja abordado ao longo do documento
Neste capıtulo apresentam-se os resultados obtidos na implementacao da prova de
conceito que visava compreender a melhor forma de disponibilizar uma versao of-
fline no WOW uma plataforma de gestao de ordens de trabalho ja existente de-
senvolvida pela Critical Software SA
51 Resultados Obtidos
Os resultados obtidos neste projecto sao extremamente satisfatorios uma vez
que o estudo do tema OWA e a implementacao de uma prova de conceito que o
ilustrasse foi conseguido com sucesso
A funcionalidade offline foi adicionada ao produto WOW da Critical Software
SA permitindo a visualizacao de ordens de trabalho e dos seus detalhes mesmo na
ausencia de uma conexao activa a Internet Embora para a solucao implementada
tenha sido utilizada uma abordagem do tipo ldquoutilizador deciderdquo pretende-se que esta
seja convertida para ldquoaplicacao deciderdquo ou mesmo para uma aproximacao hıbrida
semelhante a utilizada pelas aplicacoes estudadas nas seccoes 351 e 352
Para a sua implementacao descrita no capıtulo 4 foram tomadas decisoes de or-
dem pratica que permitissem tornar o trabalho exequıvel nos prazos dados Tentou-
se sempre que estas decisoes afectassem o mınimo em termos de desempenho e de
experiencia para o utilizador Considera-se que a implementacao do modo offline
com uma transicao entre modos do tipo ldquoutilizador deciderdquo (ver seccao 42) reflecte
o compromisso entre o desempenho pretendido e os recursos disponıveis e para alem
51
Resultados e Futuros Desenvolvimentos
de ser um exemplo eficaz das possibilidades que as OWA podem trazer a aplicacao
WOW desenvolvida pela Critical Software e tambem um estudo que pode ser uti-
lizado para analisar a implementacao desta tecnologia noutros produtos da mesma
empresa
Note-se que o principal objectivo do trabalho era ganhar familiaridade com este
tema entender as suas vantagens e desvantagens e compreender as suas limitacoes
Tudo indica que existam varias possibilidades de implementacao deste paradigma
noutros produtos da Critical Software que pela sua natureza podem tambem tirar
partido da execucao offline
52 Trabalho Futuro
O desenvolvimento do conceito e formas de implementacao de OWA continua
em forte desenvolvimento no entanto a sua adopcao ainda nao e generalizada A
dificuldade da sua implementacao em web applications ja existentes e o principal
obstaculo a sua maior divulgacao
Ha tambem um factor que deve ser tido em consideracao a manutencao de
codigo A implementacao de uma versao offline de uma web application requer
a implementacao das mesmas regras de negocio (ou de uma versao simplificada)
utilizadas no servidor Para que isto seja possıvel e necessario ter em conta a
capacidade de processamento do cliente e o factor de duplicacao de codigo que
tornara a aplicacao mais difıcil de manter uma vez que uma alteracao a logica de
negocio do servidor implica tambem uma alteracao a sua versao offline
A prova de conceito implementada permite ja a visualizacao offline dos pedidos
abertos (enviados e recebidos) que constam na pagina principal (este numero e
fixo e pode ser alterado pelo administrador) Uma funcionalidade desejavel seria a
possibilidade de interaccao com a aplicacao em modo offline e sincronizacao com o
servidor quando existisse uma ligacao disponıvel
Foi estudada a utilizacao do modo de execucao ldquoaplicacao assume o estado of-
flinerdquo descrito em 423 e esta seria a forma desejavel para o WOW Offline no
entanto para que esta opcao seja viavel sera necessaria a implementacao de uma
forma eficiente de sincronizacao e armazenamento de dados de uma forma relacional
Para atingir este objectivo podera ser seguida uma polıtica de automacao do pro-
cesso no qual a versao online da aplicacao gera scripts de criacao para as tabelas
necessarias na base de dados da versao offline (nao existe nenhuma ferramenta para
o fazer portanto seria necessaria a sua implementacao) e no qual as paginas HTML
disponibilizadas pelo servidor aos clientes web (browser) servem como templates de
apresentacao de informacao e sao preenchidas de forma semelhante pelo servidor ndash
quando a aplicacao estiver online ndash ou pelo cliente atraves de funcoes em JavaScript
52
Resultados e Futuros Desenvolvimentos
ndash quando a aplicacao estiver offline No entanto no WOW devido a quantidade de
informacao tratada e devido as complexas relacoes entre as diferentes entidades e
de esperar que a complexidade da implementacao de um mecanismo deste tipo torne
esta aproximacao demasiado custosa
O HTML 5 embora um forte candidato ainda nao esta suficientemente desen-
volvido A sua especificacao ainda tem o caracter de Draft (rascunho) e esta sujeita
a modificacoes e a aceitacao e implementacao por parte dos browsers e portanto
de momento foi desconsiderado No entanto no futuro se esta especificacao atingir
um estado de maturidade que permita a sua adopcao devera ser considerada como
um possıvel caminho a seguir
53
Resultados e Futuros Desenvolvimentos
54
Capıtulo 6
Conclusoes
Neste capıtulo sao apresentadas as conclusoes do projecto e consideracoes finais
relativamente a tecnologia estudada
61 Conclusoes
O rapido desenvolvimento tecnologico faz prever que a disponibilidade de ligacao
a Internet seja cada vez mais facil e mais rapido mas vao continuar a existir lugares
onde o acesso e limitado e onde as OWA podem desempenhar um papel de relevo
Por outro lado esta tecnologia pode tambem ser utilizada para melhorar o desem-
penho de paginas web com uma necessidade elevada de imagens ou outros recursos
dispendiosos em termos de espaco e foram ate estudados dois exemplos da utilizacao
desta vertente desta tecnologia em 353
Acredita-se que as OWAs vem responder a uma necessidade real por parte das
web applications actuais e que a evolucao que representam se compara a que se
assistiu dos thin-clients para os fat-clients em termos de autonomia do servidor
A capacidade de oferecer conteudos dinamicos no browser independentemente da
existencia de uma ligacao reune as vantagens tıpicas das web applications como
ausencia de instalacao e actualizacoes instantaneas com as vantagens das aplicacoes
de desktop em capacidade de processamento e armazenamento de dados na maquina
local
As tecnologias disponıveis ate a data estudadas no ambito deste projecto que
permitem o desenvolvimento de OWAs e que apresentam maior maturidade sao o
Gears e o Adobe AIR Ambas se apresentam sobre a forma de plugins que necessitam
de uma instalacao extra para poderem ser utilizadas Apesar de esta instalacao ser
55
Conclusoes
apenas necessaria uma vez podera constituir um factor de desencorajamento a sua
adopcao
O HTML 5 uma especificacao abordada neste documento na seccao 34 podera
ser uma alternativa que oferece funcionalidades offline a uma web application sem a
necessidade de qualquer instalacao no entanto esta especificacao ainda nao foi aceite
pelos principais browsers ndash o documento que define o HTML 5 ainda tem o estatuto
de Draft ndash e ainda nao e possıvel antecipar quando e que isto podera acontecer
Um dos problemas que surge frequentemente na implementacao de uma versao
offline para uma web application e a necessidade de sincronizacao de dados Quando
a informacao pode ser alterada por varios utilizadores simultaneamente e necessario
prever os conflitos que daı podem surgir e dotar a aplicacao de uma forma de os
resolver ou alertar o utilizador para a necessidade de alteracao dos dados
Em conclusao todos os objectivos propostos para este projecto foram atingidos
A prova de conceito implementada reflecte de forma clara as possibilidades oferecidas
pela tecnologia OWA e sera utilizado no futuro para compreender a melhor forma
de o implementar de forma definitiva no WOW
56
Referencias
[Ada08] Lucas Adamski Introducing Adobe AIR security model Fevereiro de2008 Disponıvel em httpwwwadobecomdevnetairarticles
introduction_to_air_securityhtml acedido em Marco de 2008
[Ado08] Adobe Adobe AIR 10 Security White Paper 2008 Disponıvel emhttpdownloadmacromediacompubairdocumentation1air_
securitypdf acedido em Marco de 2008
[Alm08] Dion Almaer Gears as a bleeding-edge html 5 implementa-tion March 2008 Disponıvel em httpalmaercomblog
gears-as-a-bleeding-edge-html-5-implementation acedido emMarco de 2008
[BL96] Tim Berners-Lee The world wide web Past present and future Agostode 1996 Disponıvel em httpwwww3orgPeopleBerners-Lee
1996ppfhtml acedido em Abril de 2008
[CDGH08] Mike Chambers Daniel Dura Dragos Georgita and Kevin Hoyt AdobeAIR for JavaScript Developers OrsquoReilly Media 2008 Disponıvel emhttponairadobecomfilesAIRforJSDevPocketGuidepdf ace-dido em Abril de 2008
[Con99] Jim Conallen Modeling Web Application Architectures with UML Junho1999 Disponıvel em httpwwwumlorgcnUMLApplicationpdf
webappspdf acedido em Maio de 2008
[Ent07] Entrust What is a public key information 2007 Disponıvel em http
wwwentrustcompkihtm acedido em Junho de 2008
[Gar05] Jesse James Garret Ajax A new approach to web applicationsFebruary 2005 Disponıvel em httpwwwadaptivepathcomideas
essaysarchives000385php acedido em Marco de 2008
[Greon] Philip Greenspun Philip and Alexrsquos Guide to Web Publishing 2003(last revision) Disponıvel em httpphilipgreenspuncompandaacedido em Junho de 2008
[Gro02a] App Design Group Thick vs thin client comparison 2002 Disponıvelem httpwwwdonjacobsvwcomimagesweekendspecials
Thick-vs-Thinpdf acedido em Junho de 2008
57
REFERENCIAS
[Gro02b] Technical Research Group Thin Client Tecnhology - WhitePaper 2002 Disponıvel em httpwwwpicktrgcompubs
thinclientwhitepaperpdf acedido em Junho de 2008
[Gro08] Miniwatts Marketing Group World internet usage March 2008Disponıvel em httpwwwinternetworldstatscomstatshtm ace-dido em Abril de 2008
[Hic08] Ian Hickson HTML 5 Draft Recommendation 2008 Disponıvelem httpwwwwhatwgorgspecsweb-appscurrent-work ace-dido em Marco de 2008
[Kha] Olga Kharif Top 10 municipal wifi plans Disponıvel em http
imagesbusinessweekcomss0608muni_wifiindex_01htm ace-dido em Marco de 2008
[Lab07] Mozilla Labs Prism Outubro 2007 Disponıvel em httplabs
mozillacom200710prism acedido em Marco de 2008
[Loo06] Chris Loosley Rich Internet ApplicationsDesign MeasurementandManagement Challenges 2006 Disponıvel em httpwwwkeynote
comdocswhitepapersRichInternet_5pdf acedido em Maio de2008
[Mic08] Microsoft Introduction to Occasionally Connected Applications us-ing Sync Services for ADONET 2008 Disponıvel em httpmsdn
microsoftcomen-ussyncbb887608aspx acedido em Junho de2008
[Nao08] Erica Naone Offline web applications Abril 2008 Disponıvelem httpwwwtechnologyreviewcomread_articleaspxch=
specialsectionsampsc=emerging08ampid=20245 acedido emAbril de 2008
[NJN00] Jason Nieh Yang S Jae and Naomi Novik A comparison of thin-clientcomputing architectures 2000 Disponıvel em httpwwwnclcs
columbiaedupublicationscucs-022-00pdf acedido em Maio de2008
[OrsquoR06] Tim OrsquoReilly Web 20 compact definition Trying again Dezembro2006 Disponıvel em httpradaroreillycomarchives200612
web-20-compact-definition-tryihtml acedido em Marco de 2008
[OrsquoR09] Tim OrsquoReilly What is Web 20 Design patterns and business modelsfor the Next Generation of Software 20053009 Disponıvel emhttpwwworeillynetcompubaoreillytimnews200509
30what-is-web-20html acedido em Marco de 2008
[Rus06] Alex Russel Comet Low latency data for the browser March Marco2006 Disponıvel em httpalexdojotoolkitorgp=545 acedidoem Marco de 2008
58
REFERENCIAS
[Sad97] Darleen Sadoski Clientserver software architecturesndashan overviewAgosto 1997 Disponıvel em httpwwwseicmuedustr
descriptionsclientserver_bodyhtml acedido em Junho de2008
[Sch96] George Schussel Clientserver past present and future 1996
[Smi07] Kevin C Smith Css filters - will the browser apply the rule July 2007Disponıvel em httpcentriclecomrefcssfilters acedido emMarco de 2008
[vK08] Anne van Kesteren The XMLHttpRequest Object W3C Work-ing Draft 15 Abril 2008 Disponıvel em httpwwww3orgTR
XMLHttpRequest acedido em Abril de 2008
[Wil06] Greg Wilkins Why ajax comet July Julho 2006 Disponıvel emhttpwwwwebtidecomdownloadswhitePaperWhyAjaxhtml ace-dido em Abril de 2008
59
REFERENCIAS
60
Anexo A
Screenshots
Algumas imagens de aplicacoes que utilizam funcionalidades offline ilustrativasda tecnologia abordada neste documento
Figura A1 Dialogo apresentado ao utilizador na primeira activacao das funcionalidadesoffline no Google Docs amp Spreadsheets
61
Screenshots
Figura A2 Na activacao das funcionalidades offline e tambem oferecida a possibilidadeda criacao de alguns atalhos por exemplo no ambiente de trabalho
Figura A3 O Google Docs mantem a todo o momento a possibilidade de alteracao destasdefinicoes ou da anulacao dos servicos offline para um dado computador
62
Screenshots
Figura A4 Apos a instalacao do Gears qualquer visita ao Remember The Milk despoletauma sincronizacao que ocorre automaticamente e sem necessidade de intervencao por partedo utilizador
Figura A5 Apos completar a sincronizacao de dados mesmo que a ligacao a Internetseja perdida o Remember the Milk continua disponıvel no browser (com excepcao dasfuncionalidades que pela sua natureza exigem uma ligacao como por exemplo partilhade tarefas e envio de convites)
63
Offline Web Applications
Joao Goncalves da Costa
Relatorio de Projecto realizado no Ambito do
Mestrado Integrado em Engenharia Informatica e Computacao
Aprovado em provas publicas pelo juri
Presidente Pedro Ferreira do Souto (PhD)
Arguente Artur Pereira (PhD)
Vogal Teresa Galvao Dias (PhD)
27 de Julho de 2008
Resumo
Este projecto teve como objectivo o estudo das Offline Web Applications (OWAs)e da sua implementacao em web applications ja existentes Neste ambito foi feitauma avaliacao da aplicacao desta tecnologia no WOW uma plataforma integradade gestao de ordens de trabalho desenvolvida pela Critical Software SA ao longodos ultimos 6 anos e implementada uma prova de conceito que permite a utilizacaode um conjunto de funcionalidades base desta web application independentementedo estado da ligacao a Internet
O conceito das OWAs enquadra-se numa tecnologia de Internet que permiteo acesso a um website atraves do browser mesmo na ausencia de uma ligacao arede global e foi considerado pela revista Technology Review como uma das maisimportantes tecnologias emergentes no final de 2007 [Nao08] O estudo efectuado noWOW pretende ser um primeiro passo na compreensao dos problemas associados asua implementacao e respectivas solucoes e tambem da avaliacao dos benefıcios dautilizacao desta tecnologia para os utilizadores finais
A evolucao das tecnologias associadas a Internet a que se assiste continua-mente impulsionou tambem evolucao da forma como a informacao e produzidadistribuıda e armazenada Surgiram novas web applications oferecendo funcionali-dades de criacao e edicao de conteudos que trouxeram consigo a vantagem de tornarpossıvel o acesso a informacao a partir de qualquer lugar mas tambem a desvan-tagem de tornar a ligacao a Internet uma condicao necessaria para que isto acontecaA proliferacao destas aplicacoes a crescente utilizacao da Internet [Gro08] e a adesaoaos seus servicos indiciam a existencia de uma dependencia cada vez maior de umaligacao que nem sempre existe
As OWAs vem assim colmatar esta falha colocando no lado do cliente parte dainformacao que ate agora vinha a ser armazenada no servidor e tornando nao sopossıvel a sua consulta offline como tambem reduzindo a carga no servidor umavez que reduz as transferencias de informacao
Pretende-se neste documento apresentar diferentes formas de como a utilizacaoda tecnologia OWA pode beneficiar as web applications de hoje melhorando o seudesempenho e dando-lhes novas possibilidades de execucao aproximando-as do desk-top
i
ii
Abstract
The main purpose of this project was to study the Offline Web Applications(OWAs) and its implementation in existent web applications With this goal in minda study was conducted to use this technology in WOW an integrated platform forwork orders and work flow management developed by Critical Software over thelast 6 years and implemented a proof of concept which enables the use of a baseset of functionality for this application regardless of the internet connection state
The concept of OWAs is connected with internet technology and allows accessto a website using the browser even if a connection to the internet is not availableThis concept was considered by Technology Review as one of the most importantemerging technologies in the last quarter of 2007 [Nao08] This study conductedover the WOW platform is intended to aid in the comprehension of the problemsand solutions associated to the use and implementation of OWA as well as thebenefits that it brings to the end user
The Internet and Internet technologies are changing the way in which informa-tion is produced distributed and stored New web applications appeared with newcontent creation and edition functionalities and with it the advantage of infor-mation retrieval from any place and time became possible but with the conditionof Internet connection availability With Internet use growing every year [Gro08]content creation is starting to move to this new platform The adoption of web ap-plications for content creation and edition is becoming more popular and it showsa dependency of a connection that is not always present
The OWAs are a way to solve this problem putting on the client side part ofthe information that was traditionally stored on the server and allows it to be seenand manipulated and helps reducing the server load
This document intends to present different ways in which this technology canhelp web applications as we know them improving the their overall performance andgiving them the ability to run on a browser regardless of the Internet connectionavailability
iii
iv
Agradecimentos
A realizacao e os objectivos alcancados neste projecto nao teriam sido possıveissem a colaboracao de inumeras pessoas Agradeco profundamente a todos os quecontribuıram directa ou indirectamente para o seu sucesso
A minha orientadora Professora Teresa Galvao Dias e ao Project ManagerEngenheiro Marcus Neves que me conduziram e acompanharam no desenvolvimentodeste projecto
A toda a equipa do WOW em especial o Pedro Maurıcio Costa e o Fabio Matosque contribuıram para a minha a minha integracao na Critical Software e que sempresouberam responder a todas as minhas questoes
A todos os que constituem a CSW Porto pelo fantastico ambiente de amizadeque me proporcionaram
Aos colegas de curso e a todos os que me auxiliaram na revisao deste documento
Os meus sinceros agradecimentos
Joao Goncalves da Costa
v
vi
Conteudo
1 Introducao 111 Enquadramento 112 Motivacao 213 Ambito 314 Objectivos 315 Estrutura do documento 3
2 Enquadramento do Projecto 521 Evolucao das arquitecturas de software 5
211 Thin-clients 5212 Fat-clients 6213 Arquitecturas cliente-servidor 7
22 Evolucao na Internet 8221 Paginas web estaticas 9222 Paginas web interactivas e paginas web dinamicas 9223 Web 20 e Ajax 11
23 Offline Web Applications 1324 Comparacao 13
3 Estado da arte 1731 Gears 17
311 Arquitectura 17312 Goggle Gears em dispositivos moveis 20
32 Adobe AIR 20321 Seguranca 22322 Assinatura do codigo 22
33 Mozilla Prism 23331 XML User Interface Language 23332 Prism 25
34 HTML 5 2535 Web applications que usam funcionalidades offline 26
351 Google Reader e Google Docs 26352 Remember the Milk 27353 MySpace e WordPresscom 27
36 Escolha da tecnologia 28
vii
CONTEUDO
4 Desenvolvimento 3341 Como ficar offline 33
411 Funcionalidades disponıveis em modo offline 3442 Modos de execucao 35
421 Modo ldquoutilizador deciderdquo 36422 Modo aplicacao decide 36423 Modo ldquoaplicacao assume o estado offlinerdquo 37
43 Sincronizacao de dados 38431 Quando sincronizar 39
44 WOW 4045 Visao geral sobre a arquitectura do WOW 4146 WOW Offline 42
461 Modo ldquoaplicacao deciderdquo com deteccao automatica da ligacao 43462 Implementacao do modo ldquoutilizador deciderdquo 45463 Especificacao do modo ldquoaplicacao assume o estado offlinerdquo 48
5 Resultados e Futuros Desenvolvimentos 5151 Resultados Obtidos 5152 Trabalho Futuro 52
6 Conclusoes 5561 Conclusoes 55
Referencias 59
A Screenshots 61
viii
Lista de Figuras
21 Arquitectura de um sistema thin-client em duas camadas (a esquerda)e em tres camadas (a direita) Note-se a inclusao do servidor (main-frame) na definicao das camadas desta arquitectura devido a fortedependencia cliente-servidor 9
22 Arquitectura de um fat-client em duas camadas (a esquerda) e emtres camadas (a direita) 10
23 Comparacao do modelo de web aplications sıncrono paginas estaticase interactivas abordados nas seccoes 221 e 222 com o modelo deweb applications Ajax (assıncrono) abordado na seccao 223 Figuraadaptada de http www adaptivepath com 15
31 Esquema UML do processo efectuado pelos recursos do Gears do tipoManagedResourceStore para a actualizacao dos conteudos definidosno ficheiro manifesto 29
41 Exemplo de uma arquitectura de uma web application sem uma ca-mada de abstraccao de dados Figura adaptada de http gears
google com 33
42 Exemplo de uma arquitectura de uma web application com uma ca-mada de abstraccao de dados Figura adaptada de http gears
google com 34
43 Exemplo de uma arquitectura de uma web application com uma ca-mada de abstraccao de dados e um data switch Figura adaptada dehttp gears google com 35
44 Esquema grafico ilustrando uma OWA executando no browser uti-lizando um modo de execucao do tipo ldquoaplicacao deciderdquo com de-teccao automatica do estado da ligacao via pedidos Ajax assıncronosa cada cinco segundos 37
45 Detalhe de um conjunto possıvel de estados e respectivas transicoespara uma dada ordem de trabalho no WOW desde a sua submissaono sistema ate a sua conclusao em fecho ou cancelamento Esta figurarepresenta apenas um exemplo ja que o mapa de estados para umaordem de trabalho e dinamico e pode ser alterado por um admin-istrador Figura retirada de uma brochura promocional do WOWCritical Software SA 41
ix
LISTA DE FIGURAS
46 A pagina inicial do WOW apresenta um resumo das ultimas ordensde trabalho enviadas e recebidas Na imagem pode-se observar atransicao do estado online para offline 44
47 Ilustracao do funcionamento do Gears numa web application que uti-liza um motor Ajax Os pedidos HTTP ou HTTPS podem ser inter-ceptados e tratados localmente ou podem ser feitos a uma maquinaremota consoante se verificarem ou nao as condicoes expressas noponto 311 E representado um acesso a uma base de dados local(fornecida pelo Gears) mas a sua utilizacao e opcional 45
48 Neste exemplo do modo ldquoaplicacao deciderdquo o teste da ligacao e feitoe feito a cada cinco segundos O resultado deste teste nao reflectesempre o estado real da aplicacao podendo levar a aplicacao a tercomportamentos indesejaveis Na figura assinala-se um perıodo detempo no qual a representacao interna do estado da ligacao nao cor-responde a realidade 46
49 Pagina de visualizacao do detalhe de uma ordem de trabalho 47410 Esquema UML que expressa os casos de uso do WOW Offline no
modo ldquoutilizador deciderdquo 48411 Esquema UML que expressa os casos de uso do WOW Offline no
modo ldquoutilizador deciderdquo 49412 Esquema UML que expressa o acto de recolha de dados em modo
online e offline recorrendo ao servidor (modo online) e ao sistemade armazenamento de dados local fornecido pelo Gears (modo offline) 50
A1 Dialogo apresentado ao utilizador na primeira activacao das funcional-idades offline no Google Docs amp Spreadsheets 61
A2 Na activacao das funcionalidades offline e tambem oferecida a possi-bilidade da criacao de alguns atalhos por exemplo no ambiente detrabalho 62
A3 O Google Docs mantem a todo o momento a possibilidade de alteracaodestas definicoes ou da anulacao dos servicos offline para um dadocomputador 62
A4 Apos a instalacao do Gears qualquer visita ao Remember The Milkdespoleta uma sincronizacao que ocorre automaticamente e sem ne-cessidade de intervencao por parte do utilizador 63
A5 Apos completar a sincronizacao de dados mesmo que a ligacao aInternet seja perdida o Remember the Milk continua disponıvel nobrowser (com excepcao das funcionalidades que pela sua naturezaexigem uma ligacao como por exemplo partilha de tarefas e enviode convites) 63
x
Lista de Tabelas
21 Comparacao entre thin-clients e fat-clients 7
31 Comparacao das funcionalidades oferecidas pelo Adobe AIR para asplataformas web e desktop 30
32 Resumo da utilizacao de tecnologias OWA em algumas web applica-tions consideradas na analise do estado da arte 31
xi
LISTA DE TABELAS
xii
Glossario
fat-client Cliente que nao depende totalmente de umservidor central para as suas actividadesde processamento e possui frequentementedispositivos de armazenamento de dados
6ndash8
thin-client Cliente que depende de um servidor centralpara as suas actividades de processamento
5ndash8
web application Sistema web (servidor rede HTTPbrowser) onde accoes do utilizador(navegacao e introducao de informacao)afectam o estado logico da aplicacao
i iii1ndash311ndash1517ndash1921ndash232728 3336ndash3842 5556
API Application Programming Interface 10 1718 2326 28
ASP Linguagem interpretada pelo servidorque permite a criacao de paginas webdinamicas Desenvolvida pela Microsoft
11
BSD Berkeley Software Distribution 28
CSS Cascading Style Sheets 12 2021 2324 46
DHTML Dynamic HyperText Transfer Protocol 24DOM Document Object Model 10 12
20 2324
DTD Document Type Definition 24
xiii
Glossario
ECMAScript Padrao de linguagem de programacaodefinido pela Ecma International que orig-inou o JavaScript e o JScript
24
Flash Conteudo interactivo de um ficheiro emformato SWF E desenvolvido pela Adobee visualizado atraves do Adobe FlashPlayer
21
Flex Framework baseada em XML e Action-Script desenvolvida pela Adobe para a pro-gramacao de Rich Internet Applications(RIA)
21
GPL GNU General Public License 23
HTML HyperText Markup Language 1 10ndash12 2124ndash2649
HTTP HyperText Transfer Protocol 2 26
JMS E uma API em Java que permite a troca demensagens entre componentes de software
42
JSON JavaScript Object Notation permite atroca de dados codificados num formatode texto de simples leitura
12 1828 34
LGPL GNU Lesser General Public License 23
Mozilla Prism Browser simplificado e ldquointerpretadorrdquo deeXtensible User Interface Language (XUL)(tambem designado por XULRunner) queacolhe web applications sem a interfacegrafica habitual de um browser
25
MPL Mozilla Public License 23
OCA Occasionally Connected Application 39OWA Offline Web Application i iii
2ndash515 1725 2628 3133 3651 5255 56
PDF Portable Document Format 21
xiv
Glossario
PHP Linguagem interpretada pelo servidorque permite a criacao de paginas webdinamicas mas que pode tambem ser in-vocada a partir da linha de comandos
11
pagina web estatica Pagina web que devolve sempre a mesmaresposta a todos os pedidos para todos osutilizadores e em qualquer contexto
5 9
RIA Rich Internet Applications web appli-cations que apresentam funcionalidadessemelhantes as desktop applications masque mantem a informacao no lado do servi-dor
5 1520 28
RSS Really Simple Syndication 27
SLA Service Level Agreement 40SQLite Segundo a definicao oficial SQLite is a
software library that implements a self-contained serverless zero-configurationtransactional SQL database engine
17
SSB Site Specific Browser 25SSL Secure Sockets Layer 22SWF ShockWave Flash 21
URL Uniform Resource Locator 18
VPN Virtual Private Network 38
WOW Work Orders Web Plataforma de gestaode ordens de trabalho e do seu fluxo de-senvolvida pela Critical Software SA
i iii28 3340ndash434551ndash5356
WWW World Wide Web 11 1214
XBL eXtensible Binding Language 24XHTML eXtensible HyperText Markup Language 12XML eXtensible Markup Language 11 12
23 2428
XSLT eXtensible Stylesheet Language Transfor-mation
12
XUL eXtensible User Interface Language xiv23ndash25
xv
Glossario
xvi
Capıtulo 1
Introducao
Neste capıtulo enquadra-se o tema do projecto introduzindo alguns dos conceitos
nos quais se baseia Apresentam-se as motivacoes ambito objectivos e a estrutura
deste documento
11 Enquadramento
A Internet foi originalmente concebida para ser um espaco de partilha de in-
formacao onde pessoas (atraves de maquinas) pudessem comunicar Na sua origem
as paginas eram estaticas constituıdas por texto formatado em HyperText Markup
Language (HTML) e ligadas entre si [BL96] Hoje encontramos conteudos cada vez
mais complexos e dinamicos incluindo som vıdeo ou streams multimedia [Loo06] e
em 2005 foi introduzido por [OrsquoR09] o termo Web 20
De acordo com [Greon] um website pode pertencer a uma ou varias das seguintes
categorias
bull Documento ndash um website essencialmente estatico onde alteracoes a uma
parte do conteudo nao tem implicacoes no seu comportamento
bull Base de dados ndash um directorio de informacao organizada em categorias
bull Aplicacao ndash um website dinamico que utiliza uma linguagem executada ou
interpretada do lado do servidor e que processa as accoes ou informacao in-
troduzida pelo utilizador para fornecer um servico ou nova informacao
A ultima destas categorias constitui aquilo que e normalmente designado por
web application O conceito utilizado ao longo deste documento e o mesmo que
o introduzido por Jim Coallen em [Con99] que define web application como um
1
Introducao
sistema web (servidor rede HyperText Transfer Protocol (HTTP) browser) onde
accoes do utilizador (navegacao e introducao de informacao) afectam o estado logico
da aplicacao A sua definicao tenta estabelecer que uma web application e um
sistema de software com estado de negocio1 e que a sua interface de interaccao com
o utilizador e distribuıdo atraves de um sistema web
12 Motivacao
A quantidade de informacao que e produzida e armazenada com recurso a es-
tas web applications disponıveis online tais como e-mail blogues ou mesmo docu-
mentacao tornam por vezes a disponibilidade de ligacao uma condicao necessaria
a produtividade e como consequencia desta barreira muitos potenciais utilizadores
opoem-se a adopcao de produtos web em detrimento das tradicionais desktop appli-
cations
Assegurar o acesso a uma ligacao de Internet e hoje muito mais facil A Internet
movel e ja uma realidade e encontra-se amplamente divulgada mas continuam a
existir diversas situacoes nas quais os utilizadores estao privados de uma ligacao
a Internet tais como uma viagem de metro ou de aviao ou quando se encontram
deslocados do seu paıs de origem e nao possuem nenhum plano de subscricao
Uma OWA consiste numa web application que para alem de manter todas as
caracterısticas anteriores se mantem disponıvel mesmo na ausencia de uma ligacao
a Internet e surge como uma tentativa de estreitar as barreiras existentes entre a
web e o desktop Isto significa que devera existir um mecanismo capaz de assegurar
a manutencao do estado logico da aplicacao quando a ligacao com o servidor e
quebrada permitindo ao utilizador continuar a utilizar a aplicacao e que sera capaz
de informar o servidor do estado em que a aplicacao se encontra quando a ligacao for
reposta A principal vantagem que advem desta possibilidade e evidente eliminar
a necessidade da existencia de uma ligacao a Internet para que a aplicacao possa ser
utilizada
Por outro lado a vontade de integracao de funcionalidades tıpicas das desktop
applications nas web applications foi um dos principais factores que impulsionou o
desenvolvimento deste conceito uma vez que obrigou a uma reflexao ldquopara alem
do browserrdquo e a uma adaptacao das arquitecturas existentes que permitisse ou o
acesso a funcionalidades disponibilizadas pelo sistema operativo ou pelo menos a
funcionalidades semelhantes Pretende-se com esta aproximacao tornar possıveis
interaccoes entre o desktop e o browser tais como arrastar um ficheiro para um
formulario web de upload de conteudos melhor suporte para o historico do clipboard
ou ainda o acesso ao sistema de ficheiros local Atingir estes objectivos reflecte-se
1NT business state
2
Introducao
num novo paradigma que reune as vantagens das web applications tais como os
updates instantaneos ou o facto de nao ser necessaria nenhuma instalacao e das
desktop applications como por exemplo persistencia no armazenamento de dados
acesso a funcionalidades do sistema operativo ou integracao e interaccao com outras
aplicacoes sejam elas web applications ou desktop applications
13 Ambito
Este projecto foi realizado na Critical Software SA no ambito do Mestrado
Integrado em Engenharia Informatica e Computacao (MIEIC) da Faculdade de En-
genharia da Universidade do Porto (FEUP) entre os meses de Fevereiro e Julho de
2008
14 Objectivos
Sao objectivos deste projecto
1 Estudar e documentar o tema das OWAs acompanhando os ultimos desenvolvi-
mentos nesta materia
2 Analisar o estado da arte fazendo uma analise crıtica e objectiva sobre as
diversas metodologias existentes
3 Implementar uma prova de conceito que permita a execucao offline de uma
web application documentando todo o processo
4 Estudar a possibilidade de permitir interaccao com a aplicacao (insercoes e
alteracoes aos dados) em modo offline
Em resumo o objectivo deste projecto foi estudar documentar e implementar
uma prova de conceito relacionada com o tema Offline Web Applications (OWA)
Este tema embora nao seja totalmente novo ganhou destaque ao longo do ano de
2007 com o surgimento de diversas ferramentas que se destinam a aproximar web
applications das desktop applications
15 Estrutura do documento
Este documento esta organizado em diferentes seccoes apresentando o projecto
numa sequencia logica organizada da seguinte forma
No capıtulo 1 faz-se uma breve apresentacao do conceito OWAs e do contexto em
que surge Apresenta-se tambem a estrutura do documento e definem-se os
termos e acronimos utilizados
3
Introducao
No capıtulo 2 faz-se uma descricao da evolucao das tecnologias que antecedem as
OWAs e das vantagens e desvantagens de cada uma como forma de enquadra-
mento
No capıtulo 3 analisa-se o estado da arte nesta materia Introduzem-se diversas
tecnologias directamente relacionadas com o tema deste projecto exemplos de
aplicacoes que as usam e as razoes que fundamentam as escolhas de tecnologias
efectuadas
O capıtulo 4 contem o desenvolvimento do projecto Analisa-se a plataforma
WOW de gestao integrada de ordens de trabalho a tecnologia escolhida e
a forma como foi utilizada para implementar a capacidade de execucao offline
O capıtulo 5 descreve os resultado obtidos comparando-os com as expectativas
iniciais do projecto e apresenta desenvolvimentos futuros e possibilidades de
continuacaoaplicacao do conhecimento adquirido
No capıtulo 6 apresentam-se as conclusoes
4
Capıtulo 2
Enquadramento do Projecto
Neste capıtulo apresenta-se um breve resumo da evolucao das arquitecturas de
software cliente-servidor e a forma como estas se comparam a evolucao da Inter-
net procurando estabelecer uma analogia entre o percurso de ambas as tecnolo-
gias Compara-se o comportamento e arquitectura dos thin-clients as paginas web
estaticas a evolucao dos fat-clients as paginas interactivas Web 20 e Ajax e
defende-se que as OWA constituem um proximo passo logico e evolutivo aproxi-
mando a web do desktop Referem-se ainda os principais factores que justificam a
importancia das OWAs e a estreita relacao que tem com as Rich Internet Application
(RIA)s
21 Evolucao das arquitecturas de software
Os termos thin-client e fat-client sao utilizados quer para descrever arquitecturas
logicas (de software) quer para descrever arquitecturas fısicas (de hardware) Neste
capıtulo excepto quando seja dada indicacao em contrario estes termos referem-se
sempre a uma arquitectura logica
Adicionalmente quando se trata de arquitecturas cliente-servidor pode-se estu-
dar a arquitectura desenvolvida do sistema como um todo da arquitectura do servi-
dor ou da arquitectura do cliente Para evitar equıvocos em especial na seccao 213
especifica-se em cada caso qual o sistema estudado
211 Thin-clients
Um thin-client e um computador cliente ou software cliente que no contexto
de uma arquitectura cliente-servidor depende de um servidor central para as suas
5
Enquadramento do Projecto
actividades de processamento e proporciona um canal de entrada e saıda de in-
formacao entre o utilizador e o servidor remoto Este termo quando aplicado a
hardware refere-se habitualmente a um computador que se destina a ser utilizado
como cliente de rede sem armazenamento local e com capacidade de processamento
reduzida [Gro02b] mas o conceito que aqui se analisa refere-se a uma arquitectura
de software que remonta ao inıcio das aplicacoes cliente-servidor
No inıcio da historia da computacao terminais ligavam-se directamente a main-
frames responsaveis por todo o processamento Nesta arquitectura era necessario
desenvolver duas aplicacoes distintas uma aplicacao central no servidor (main-
frame) responsavel pela gestao de toda a informacao e por todas as operacoes de
comunicacao e uma aplicacao de visualizacao instalada no cliente (terminal) O
papel destes terminais era apenas disponibilizar ao utilizador um meio de comu-
nicacao (entrada e saıda) e apresentacao dos resultados do servidor Nao tinham
um papel activo no calculo nem na logica de negocio e frequentemente nao tinham
tambem nenhum mecanismo de armazenamento de dados
Como vantagens esta arquitectura apresenta uma reduzida necessidade de con-
figuracao e manutencao do lado do cliente Uma vez que o centro do processamento
e manipulacao de dados ocorre no servidor existe tambem uma centralizacao da
informacao [NJN00] que introduz um ponto crıtico de falha1 Actualizacoes e novas
funcionalidades sao faceis de distribuir uma vez que requerem apenas alteracoes no
servidor [Gro02a]
212 Fat-clients
Contrastando com os thin-clients nesta arquitectura os clientes implementam
ja uma parte da logica de negocio e sao responsaveis pelo processamento de dados
Estes fat-clients vieram responder a necessidade crescente de aplicacoes com um
nıvel de interactividade e capacidade de configuracao maior que as oferecidas pela
arquitectura thin-client descrita na seccao 211 Apesar de manterem a sua de-
pendencia do servidor podem tambem ser executados sem uma conexao activa uma
vez que dispoe de armazenamento de dados local o que lhes confere a capacidade
de persistencia de dados e do estado de execucao entre cada sessao
Foi disponibilizando este controlo sobre o estado da aplicacao bem como acesso
a recursos locais (por exemplo sistema de ficheiros e perifericos) que surgiram as
primeiras verdadeiras desktop applications No entanto cada cliente tinha que ser
separadamente instalado no computador pessoal de cada utilizador que pretendesse
utilizar ou interagir com a aplicacao e uma actualizacao ao servidor implicava in-
variavelmente uma actualizacao manual tambem no cliente Uma vez que nem todos
1NT single point of failure
6
Enquadramento do Projecto
Thin-clients Fat-clientsNao toma parte no processamento dedados nem possui acesso ao sistema deficheiros
Participa activamente no processa-mento de dados recorrendo ao sis-tema de armazenamento local para ar-mazenamento de dados
Nao mantem registo do estado logicoda aplicacao entre duas sessoes de uti-lizacao
O acesso ao armazenamento localpermite-lhe manter registo do estadologico da aplicacao entre duas sessoes
O thin-client nao necessita de qualquerinstalacao estando ldquopronto a utilizarrdquo
E geralmente necessario instalar aaplicacao para poder interagir com oservidor
Qualquer update no servidor reflecte-seimediatamente por todos os clientes
Embora a aplicacao cliente possa aler-tar para existencia de novas versoes asactualizacoes tem que ser manualmenteinstalados pelo cliente
O software do cliente destina-se apenasa apresentacao de dados e comunicacaocom o servidor sendo portanto de sim-ples implementacao
Como o software do cliente toma parteactiva no processamento de dadosa sua implementacao requer cuidadosadicionais
Grande mobilidade uma vez que todaa informacao e mantida no servidor
Parte da informacao podera estar ape-nas do lado cliente pelo que existemalgumas restricoes a sua mobilidade
Tabela 21 Comparacao entre thin-clients e fat-clients
os utilizadores actualizam regularmente as suas aplicacoes o servidor tem que estar
preparado para lidar com versoes antigas2 ou descontinuar os seus servicos a uma
parte da sua comunidade de utilizadores ate que estes actualizem os seus sistemas
Como os utilizadores passam a utilizar os seus recursos locais para armazenamento
de dados as alteracoes que nao sejam sincronizadas com o servidor estao apenas
disponıveis nos seus computadores pessoais o que introduz uma restricao a mobili-
dade
Pode-se afirmar que as vantagens dos thin-clients sao as desvantagens dos fat-
clients e que as vantagens dos fat-clients sao as vantagens dos thin-clients tal como
se ilustra na Tabela 21
213 Arquitecturas cliente-servidor
Introduzidos os termos thin-client e fat-client interessa reafirmar que ambos
podem ser vistos como arquitecturas cliente-servidor Um cliente define-se como
um solicitador de servicos e um servidor como um prestador de servicos tal como
definido por [Sch96] e [Sad97]
2NT backward compatibility
7
Enquadramento do Projecto
As arquitecturas cliente-servidor sao categorizadas pela modularizacao com que
sao desenhadas sendo consideradas as seguintes camadas
1 Interface grafica (front-end) atraves da qual os utilizadores interagem com
a aplicacao Quando este modulo e implementado separadamente dos outros
dois constitui uma aplicacao thin-client por si so uma vez que nao implementa
regras de negocio (embora possa definir validacoes de formularios de insercao de
dados por exemplo) A informacao introduzida pelo utilizador e enviada para
o servidor que processa o seu pedido e retorna uma resposta Este processo
repete-se ate que o utilizador atinja o seu objectivo ou se desligue do sistema
2 A logica de negocio tambem designada por camada intermedia que imple-
menta as regras de aceitacao e validacao de todos os dados introduzidos pelo
utilizador E tambem a plataforma de comunicacao que une a camada superior
de visualizacao com a camada de acesso a dados
3 A camada de dados inclui quer o sistema de persistencia de dados onde sao
armazenados os dados relevantes como tambem os mecanismos necessarios
para a sua pesquisa seleccao e alteracao
Os thin-clients quando observados no seu conjunto de cliente e servidor podem
ser vistos quer como sistemas de duas camadas quer como sistemas de tres camadas
dependendo apenas da forma como o servidor for implementado No caso de na
implementacao do servidor nao se distinguir a camada de acesso a dados da camada
da logica de negocio sao designados por sistemas de duas camadas Caso seja feita
esta distincao sao designados por sistemas de tres camadas Ambos os casos sao
ilustrados na Figura 21
Historicamente os fat-clients eram implementados numa arquitectura em duas
camadas Possuıam apenas um modulo de visualizacao de dados designado por
camada de interface e um modulo que implementava toda a logica de negocio e
regras de acesso a base de dados No entanto com a introducao de ligacoes mais
rapidas e de computadores pessoais com maior capacidade de processamento e so-
bretudo devido a complexidade crescente das aplicacoes a logica de negocio e a
camada de acesso a dados tornaram-se independentes Este modelo e designado por
arquitectura em tres camadas e e ilustrado na Figura 22
22 Evolucao na Internet
Ao analisar a evolucao das arquitecturas das aplicacoes desenvolvidas para a
Internet podemos encontrar um paralelismo com a historia da arquitectura de soft-
ware
8
Enquadramento do Projecto
Figura 21 Arquitectura de um sistema thin-client em duas camadas (a esquerda) e emtres camadas (a direita) Note-se a inclusao do servidor (mainframe) na definicao dascamadas desta arquitectura devido a forte dependencia cliente-servidor
221 Paginas web estaticas
Uma pagina web estatica devolve sempre a mesma resposta a todos os pedidos
para todos os utilizadores e em qualquer contexto utilizando o hipertexto como
forma de ligacao entre diversas paginas estaticas
A informacao e armazenada num servidor e o papel do cliente e apenas a apre-
sentacao da informacao Esta forma de disponibilizacao de informacao pode assim
ser comparada com os thin-clients descritos na seccao 211 o utilizador acede a
um website estatico para visualizar informacao sem que o cliente tome parte no
processamento A unica diferenca e que no caso da web estatica a informacao ap-
resentada e sempre a mesma enquanto que nos thin-clients era frequente existir a
possibilidade de insercao de dados no cliente e apos o seu processamento servidor
nova informacao poderia ser apresentada O hipertexto e utilizado para ligar as
paginas entre si numa rede de conteudos relacionados e a navegacao sıncrona era
feita atraves de cliques do rato a cada clique uma nova pagina era apresentada
Este modelo sıncrono e ilustrado na Figura 23
222 Paginas web interactivas e paginas web dinamicas
O JavaScript e uma linguagem interpretada de scripting que tem os browsers
como principal ambiente de acolhimento Os browsers utilizam uma Application
9
Enquadramento do Projecto
Figura 22 Arquitectura de um fat-client em duas camadas (a esquerda) e em tres camadas(a direita)
Programming Interface (API) publica para criar ldquoobjectosrdquo responsaveis por reflectir
e disponibilizar o Document Object Model (DOM) para o motor de JavaScript
A utilizacao mais frequente desta linguagem e a escrita de funcoes que sao em-
bebidas ou incluıdas em paginas web e que interagem com o DOM Uma vez que o
JavaScript e executado localmente (na maquina do cliente e nao no servidor) e capaz
de responder rapidamente a accoes do utilizador tornando a execucao de aplicacoes
no browser mais fluıdas o JavaScript pode tambem detectar accoes do utilizador
que o HTML nao pode tal como o pressionar de uma tecla
Em Dezembro de 1995 a Netscape Communications adicionou suporte para o
JavaScript no browser Netscape Navigator3 e em Agosto de 1996 o browser Internet
Explorer4 da Microsoft passou a tambem a suportar uma versao semelhante desta
linguagem (hoje todos os principais browsers suportam esta tecnologia)
Esta inovacao permitiu tornar os websites mais interactivos mas a sua utilizacao
esteve confinada apenas a este proposito durante um longo perıodo As paginas
passaram a responder activamente a accoes do utilizador (sendo uma das utilizacoes
3Netscape Communications ndash httpbrowsernetscapecom4Microsoft Internet Explorer ndash httpwwwmicrosoftcomwindowsproductswinfamilyie
10
Enquadramento do Projecto
mais vulgares a validacao de formularios) mas continuaram essencialmente estaticas
O JavaScript ainda nao era nesta altura utilizado para processar dados
Tambem nesta altura (1995ndash96) surgiram linguagens server-side como o PHP
Hypertext Preprocessor (PHP) e Active Server Pages (ASP) e o servidor passou a ter
um processamento de dados introduzidos pelo utilizador mais activo Generalizaram-
se as paginas dinamicas capazes de responder a insercao de dados ou outros pedidos
determinados por accoes do utilizador As paginas tornaram-se aplicacoes web ap-
plications
Uma definicao tradicional de web application e um conjunto de paginas web
logicamente agrupadas e geridas por uma unica entidade que tem como pontos de
entrada formularios de insercao de dados (web forms) Uma web application nao e
mais do que uma aplicacao que e acedida atraves de um browser Tem geralmente
uma arquitectura logica em tres (interface logica de negocio e camada de dados)
camadas e estao armazenadas num servidor
Ha dois tipos de web applications
bull Orientadas a apresentacao Sao web applications que geram paginas web in-
teractivas constituıdas por varios tipos de linguagens de anotacao (por exem-
plo HTML eXtensible Markup Language (XML)) e que apresentam conteudo
dinamico como resposta a pedidos efectuados pelo utilizador
bull Orientadas aos servicos Uma web application orientada aos servicos imple-
menta o ponto de acesso para um ou mais de um web service Sao geralmente
clientes de service oriented web applications
Uma vantagem significativa de implementar uma web application de forma a
suportar as funcionalidades padrao dos browsers e que estas terao o mesmo com-
portamento independentemente da plataforma e do browser a partir do qual serao
acedidas No entanto diferentes implementacoes de browsers devido a diferentes
interpretacoes dos padroes definidos tornam por vezes esta tarefa um pouco mais
complicada existindo inclusivamente na web guioes de compatibilidade para os difer-
entes browsers como [Smi07]
223 Web 20 e Ajax
O termo web 20 descreve uma tendencia de utilizacao e de design observada
na World Wide Web (WWW) com o objectivo de melhorar a criatividade partilha
de informacao e principalmente a colaboracao entre utilizadores Estes conceitos
levaram ao desenvolvimento e evolucao de comunidades online tais como redes so-
ciais wikis e blogues
11
Enquadramento do Projecto
O termo tornou-se mais conhecido apos a primeira conferencia OrsquoReilly Media
Web 20 em 2004 e apesar de sugerir uma nova versao da WWW nao se refere a
qualquer evolucao tecnologica mas apenas a alteracoes a forma como os utilizadores
se servem da web De acordo com Tim OrsquoReilly [OrsquoR06] ldquoWeb 20 e uma revolucao
na industria do software causada pela adopcao da web como uma plataforma e pela
tentativa de entendimento das regras para o sucesso nesta nova plataformardquo
O desenvolvimento da Web 20 serve-se muitas vezes de um outro conceito Ajax
O conceito que hoje conhecemos como Ajax muitas vezes incorrectamente de-
scrito como uma tecnologia foi originalmente criado para permitir o desenvolvimento
de web applications que se assemelhassem ainda mais a aplicacoes de desktop Este
conceito foi melhor descrito por [Gar05] como um conjunto de varias tecnologias
que podem ser utilizadas para melhorar a experiencia do utilizador de uma dada
web application introduzindo a capacidade assıncrona de envio de pedidos ou da
recepcao assıncrona de respostas As tecnologias mais frequentemente envolvidas
sao
bull eXtensible HyperText Markup Language (XHTML) e Cascading Style Sheets
(CSS) padrao para a apresentacao
bull interaccao dinamica atraves do DOM
bull troca e manipulacao de dados utilizando XML e eXtensible Stylesheet Lan-
guage Transformation (XSLT) ou JavaScript Object Notation (JSON)
bull pedidos assıncronos utilizando XMLHttpRequest [vK08]
bull JavaScript utilizado para integrar todas estas tecnologias
E importante frisar que o Ajax nao e um produto nem uma tecnologia E um
termo que descreve a utilizacao de um conjunto de tecnologias para o desenvolvi-
mento de web applications com um elevado grau de interactividade Comparativa-
mente as web applications tradicionais o Ajax introduz uma camada de visualizacao
diferente em tres importantes pontos
1 Do lado do cliente existe um motor que serve de intermediario entre a interface
da aplicacao e o servidor
2 A actividade do utilizador despoleta chamadas JavaScript em vez de um pedido
de pagina directamente ao servidor
3 Informacao codificada em XML em vez de paginas HTML e trocada entre o
servidor e o cliente
12
Enquadramento do Projecto
Isto significa que as paginas que utilizam Ajax contem um motor do lado do
cliente composto por um conjunto de funcoes JavaScript responsavel pela comu-
nicacao com o servidor e por actualizar a interface com o resultado dessa mesma
comunicacao
Na Figura 23 ilustra-se a natureza assıncrona do Ajax quando comparada com
as web applications tradicionais Como se pode observar adicionando um mecan-
ismo Ajax a uma web application eliminam-se diversos tempos de espera associados
a comunicacoes com o servidor uma vez que a interface nao fica ldquobloqueadardquo a es-
pera da resposta Obtem-se assim aplicacoes com um comportamento mais fluido
eliminando tempos de espera entre cada ldquocliquerdquo e melhorando a experiencia do
utilizador
23 Offline Web Applications
A informacao grafica (bem como folhas de estilo e scripts) tais como as ima-
gens que constituem o visual de uma web application e ja tratada de forma especial
pelos cada vez mais avancados sistemas de cache (armazenamento temporario) dos
browsers Mas estes nao sao ainda capazes de guardar conteudo criado pelo uti-
lizador nem de apresentar informacao independentemente do estado da ligacao
Numa altura onde se fala de servicos de Internet wireless municipalizados [Kha]
comunicacoes 3G e ligacoes de banda larga a alta velocidade a ligacao a rede global
continua a nao estar permanentemente disponıvel para os utilizadores Na WWW
encontra-se uma importante parte da informacao e das aplicacoes utilizadas para
criar e editar conteudos Por vezes informacao vital para a produtividade pode
desaparecer subitamente do mapa de acesso de um utilizador quando este entra no
metro num aviao ou mesmo quando se desloca para uma cidade ou paıs diferente
do habitual onde nao subscreve um plano de acesso que lhe garanta a ligacao
Permitir o acesso offline a estes recursos assume assim a sua importancia porque
permitira estender o alcance da informacao a locais onde nunca esteve antes e per-
mitira tambem melhorar o desempenho das web applications colocando informacao
mais perto dos utilizadores reduzindo a transferencia de dados apenas ao essencial
24 Comparacao
Nas evolucoes descritas neste capıtulo 2 pode-se observar que existe um par-
alelismo entre a evolucao das arquitecturas tradicionais cliente-servidor e a evolucao
a que se assiste na web O comportamento e arquitectura dos thin-clients assemelha-
se ao das paginas estaticas no sentido em que o browser nao toma parte em qualquer
13
Enquadramento do Projecto
processamento e serve apenas como uma plataforma de interaccao com o servidor
tal como os clientes descritos na seccao 211
A sua proxima evolucao os fat-clients trouxeram parte da capacidade de pro-
cessamento para o lado do cliente Na web foi tambem esta a inovacao tecnologica
a que se assistiu com a evolucao das tecnologias que permitiram a criacao de ver-
dadeiras aplicacoes e com a introducao do Javascript no browser dando ao cliente
a capacidade de processamento de dados A necessidade da separacao do codigo
em camadas logicas advem da crescente complexidade das web applications Esta
pratica permite entre outras coisas melhorar o processo de desenvolvimento e a
capacidade de manutencao de uma aplicacao
Os fat-clients tem tambem a capacidade de armazenamento de dados o que
permite a persistencia de informacoes entre duas sessoes e que algumas operacoes
sejam executadas sem a necessidade de comunicacao com o servidor Este facto pode
tambem ser uma realidade nas web applications com a adopcao das tecnologias OWA
Neste momento assiste-se a uma utilizacao cada vez maior da web como uma
plataforma de desenvolvimento A capacidade de cooperacao na edicao de conteudos
e a mobilidade proporcionada por esta plataforma sao os principais factores que
alimentam esta mudanca e pela primeira vez as aplicacoes tradicionais tem com-
peticao vinda de web applications A prova do reconhecimento da web como plataforma
de desenvolvimento pode ser retirada da aposta de empresas como a Adobe e Mi-
crosoft que lancaram publicamente ferramentas web complementares a produtos
seus tradicionalmente associados ao desktop ndash Acrobatcom5 e Microsoft Office
Live6 Dotar estas web applications da capacidade de execucao offline significa
aproximar a web e o desktop reunindo ldquoo melhor de dois mundosrdquo
As vantagens da mobilidade possıvel atraves da web a cooperacao na criacao e
edicao de conteudos e a possibilidade de utilizar aplicacoes sempre actualizadas e
sem necessidade de instalacao sao algumas das principais vantagens que promovem
esta mudanca que devido as preocupacoes associadas a usabilidade e experiencia do
utilizador esta fortemente associada ao desenvolvimento de Rich Internet Applica-
tion (RIA)s
5Adobe Acrobatcom httpwwwacrobatcom6Microsoft ndash httpsmallbusinessofficelivecom
14
Enquadramento do Projecto
Figura 23 Comparacao do modelo de web aplications sıncrono paginas estaticas e in-teractivas abordados nas seccoes 221 e 222 com o modelo de web applications Ajax(assıncrono) abordado na seccao 223 Figura adaptada de http www adaptivepath
com
15
Enquadramento do Projecto
16
Capıtulo 3
Estado da arte
Apesar de o conceito das OWAs nao ser absolutamente novo as tecnologias que
o suportam sao recentes Neste capıtulo descrevem-se quatro tecnologias que foram
tidas como principais candidatas para o desenvolvimento deste projecto Descrevem-
se ainda alguns exemplos de web applications que disponibilizam actualmente fun-
cionalidades offline e o processo da escolha da tecnologia a utilizar neste projecto
31 Gears
O Gears1 e uma extensao as funcionalidades do browser introduzido pelo Google
que tem como principal objectivo tornar possıvel a visualizacao de paginas de Inter-
net mesmo sem uma conexao disponıvel Encontra-se disponıvel para as platafor-
mas Windows Macintosh e Linux e oferece uma API de Javascript que permite
a scripts aceder a um mecanismo de armazenamento local baseado numa base de
dados SQLite
311 Arquitectura
Esta ferramenta e constituıda por tres componentes principais
bull LocalServer mdash Intercepta pedidos de paginas web e serve-as localmente
bull Database mdash Uma base de dados relacional construıda sobre SQLite
bull WorkerPool mdash Permite executar operacoes de computacao de uma forma
assıncrona sem afectar a capacidade de resposta e fluidez de execucao da web
application Assemelham-se a processos
1Google Inc ndash Mais informacao em httpgearsgooglecom
17
Estado da arte
LocalServer
O modulo LocalServer e uma cache de Uniform Resource Locators (URLs)
controlada pela web application Quando nao existe uma ligacao a Internet e e
feito um pedido para um URL presente nesta cache o LocalServer intercepta-o e
responde ao pedido localmente a partir do disco rıgido do utilizador A aplicacao
pode utilizar dois tipos diferentes de armazenamento local de URLs
bull ResourceStore ndash serve para capturar URLs utilizando exclusivamente a API
de Javascript disponibilizada para o efeito Uma aplicacao podera criar e
utilizar diversos ResourceStores simultaneamente para capturar ficheiros de
dados que necessitam de ser enderecados por um URL tal como um ficheiro
PDF ou uma imagem
bull ManagedResourceStore ndash serve para capturar um conjunto de URLs que estao
relacionados e que sao declarado num ficheiro de manifesto (especificado em
JSON) e que sao automaticamente actualizados O ManagedResourceStore
permite que o conjunto de recursos necessarios para correr uma web application
seja capturado e mantido actualizado automaticamente
A principal diferenca entre estes dois tipos de armazenamento de URLs e a forma
como sao actualizados os seus conteudos Os conteudos de um ManagedResourceStore
sao actualizados sempre que a versao contida no ficheiro de manifesto for alterada
enquanto que os conteudos de um ResourceStore nunca sao actualizados automati-
camente mas apenas quando for explicitamente ordenado pela aplicacao
O LocalServer e capaz de interceptar e servir localmente pedidos de HTTP e
HTTPS sempre que se reunam as seguintes condicoes
1 O URL encontra-se armazenado num ResourceStore ou ManagedResourceStore
2 O sistema de armazenamento local encontra-se activo (enabled = true) Se
o sistema de armazenamento local tiver o atributo requiredCookie o pedido
devera conter um cookie que lhe corresponda
O LocalServer nao necessita de monitorizar o estado da ligacao para atender aos
pedidos Na verdade sempre que as condicoes previamente enunciadas se verificarem
o LocalServer interceptara os pedidos e independentemente do estado da ligacao
a Internet servi-los-a a partir do disco rıgido local Cabera a aplicacao definir qual
o modo em que pretende executar um pedido (online ou offline) definindo o valor
de verdade da propriedade enabled
18
Estado da arte
Database
O modulo Database permite guardar dados da web application assegurando a
sua persistencia Os dados sao guardados de forma relacional no disco rıgido do uti-
lizador2 de acordo com o modelo de seguranca estabelecido pelo Gears3 significando
que uma aplicacao nao pode aceder a conteudos fora do seu domınio
WorkerPool
Nos web browsers uma operacao pesada de computacao pode tornar a interface
lenta e tornar menos agradavel a experiencia do utilizador O modulo WorkerPool
permite correr operacoes em background sem bloquear a interface com o utilizador
Os scripts executados numa WorkerPool nao activam os mecanismos de seguranca
do browser que mostram a mensagem ldquoA script on this page may be busy or may
have stopped respondingrdquo
O WorkerPool comporta-se como um conjunto de processos em vez de threads
Os Workers nao partilham qualquer estado de execucao o que significa que uma
alteracao a uma variavel num Worker nao afecta em nada a execucao de outro
Worker Alem disso os Workers nao herdam automaticamente nenhum codigo dos
seus pais Cada Worker e membro de um WorkerPool e os Workers podem in-
teragir entre si enviando mensagens em formato de texto ou JSON No entanto ha
tambem algumas limitacoes os Workers nao tem acesso ao DOM e objectos como
window ou document nao se encontram acessıveis Isto e consequencia de os Workers
nao partilharem o estado de execucao Mas tem acesso a todas as funcoes built-in
do Javascript A maioria das funcionalidades do Gears pode tambem ser acedida
atraves de uma variavel global especial definida como googlegearsfactory Para
outras funcionalidades especıficas os Workers podem ldquopedirrdquo a pagina principal para
continuar a execucao atraves do envio de mensagens
Outras funcionalidades
bull HttpRequest ndash Este modulo implementa a especificacao W3C XmlHttpRe-
quest definida em [vK08] tornando-a disponıvel para os workers e para a
pagina principal
bull Timer ndash Este modulo implementa a especificacao de timers tal como descrito
por [Hic08] e torna-os disponıveis para os workers e para a pagina principal
2Consultar httpcodegooglecomapisgearsapi_databasehtmldirectories3Consultar httpcodegooglecomapisgearssecurityhtml
19
Estado da arte
bull Factory ndash Esta classe e utilizada para instanciar todos os outros objectos da
API do Gears atraves do seu metodo create Este metodo pode ser utilizado
com os seguintes parametros
ndash betadatabase
ndash betahttprequest
ndash betalocalserver
ndash betatimer
ndash betaworkerpool
312 Goggle Gears em dispositivos moveis
O Gears esta tambem disponıvel em dispositivos Windows Mobile 5 e 6
Os dispositivos moveis estao pela sua natureza frequentemente desconectados
da Internet Mesmo quando possuem uma ligacao as latencias na transferencia de
dados em redes moveis tornam as aplicacoes pouco fluıdas mas o Gears permite
ultrapassar este obstaculo
O Gears funciona exactamente da mesma forma em dispositivos moveis equipados
com o Windows Mobile 5 e 6 como num computador comum Se uma aplicacao tiver
sido implementado com suporte para o Gears entao tambem estara preparada para
ser executada num dispositivo movel mas as limitacoes dos browsers disponıveis
para dispositivos moveis tem que ser consideradas Isto significa prever as condicoes
que permitam uma boa usabilidade devido aos pequenos ecras destes dispositivos
bem como o seu suporte limitado dos padroes do DOM CSS e JavaScript
32 Adobe AIR
O Adobe AIR4 e um runtime compatıvel com diversos browsers e sistemas opera-
tivos que pretende dar aos programadores a possibilidade de combinar diversas tec-
nologias de producao de conteudos para a Internet no desenvolvimento de Rich Inter-
net Application (RIA)s O Adobe AIR mantem uma relacao com o browser mas es-
tende as suas capacidades e tecnologias permitindo o desenvolvimento de aplicacoes
tambem para o ambiente de trabalho com janelas em tudo semelhantes as do sis-
tema operativo Segundo a Adobe o objectivo e complementar o browser dando
aos utilizadores (mas essencialmente aos programadores e equipas de desenvolvi-
mento) a escolha sobre como distribuir as suas aplicacoes Para este efeito o Adobe
AIR tem uma aproximacao diferente do Gears Em vez de ldquoestenderrdquo o browser
acrescentando-lhe funcionalidades o AIR permite tambem o desenvolvimento de
4Adobe - httpwwwadobecomproductsair
20
Estado da arte
aplicacoes que se destinam a ser executadas fora do ambiente do browser mas uti-
lizando as tecnologias comuns da Internet (por exemplo HTML CSS JavaScript
Flash Flex)[CDGH08]
A utilizacao desta tecnologia permite utilizar o browser ou o proprio runtime
Adobe AIR como plataforma de execucao da aplicacao
Na Tabela 31 faz-se uma comparacao das funcionalidades disponıveis de acordo
consoante se escolha o browser ou o desktop como plataforma base para a aplicacao
Uma vez que as aplicacoes Adobe AIR na plataforma desktop tem um caracter
persistente (sao instaladas no computador do utilizador) o Adobe AIR tem um
modelo de seguranca que se assemelha com o das tradicionais aplicacoes desktop
[Ada08] Este modelo e analisado nas seccoes 321 e 322 O ambiente em que
e executado o browser e restringido a execucao de web applications que podem
ser de varias origens (incluindo de origens anonimas ou sem confianca) O Adobe
AIR proporciona acesso a capacidades como acesso a ficheiros que necessitam da
confianca do utilizador
bull HTML ndash O desenvolvimento de aplicacoes para o Adobe AIR pode ser feito
com recurso a tecnologias de HTML e Ajax comuns utilizando as linguagens
de markup existentes distribuıdas como texto e interpretadas em execucao
(runtime)
bull Flash ndash Outra alternativa sera a utilizacao da linguagem Flash Permite a
renderizacao de graficos vectoriais e audiovıdeo com suporte nativo Utiliza
ActionScript para adicionar maior interactividade com o utilizador
bull Flex ndash O Flex e uma framework open source para o desenvolvimento de RIAs
usando Flash As aplicacoes Flex sao na realidade Flash sendo a principal
diferenca o ambiente de desenvolvimento
Como resultado uma aplicacao AIR podera ser implementada
bull Baseada em Flash ou Flex (aplicacoes cujo conteudo base e em ShockWave
Flash (SWF))
bull Baseada em Flash ou Flex tambem com HTML ou Portable Document Format
(PDF) Aplicacoes cujo conteudo de base e em FlashFlex (SWF) com HTML
(HTML JavaScript CSS) ou conteudo PDF incluıdo
bull Baseada em HTML Aplicacoes cujo conteudo base e em HTML Javascript
CSS
bull Baseada em HTML utilizando tambem FlashFlex ou PDF
21
Estado da arte
Os utilizadores interagem com uma aplicacao AIR da mesma forma que interagem
com outras aplicacoes com janelas nativas do seu sistema operativo O runtime e
instalado uma vez no computador do utilizador e a partir desse momento todas as
aplicacoes AIR terao o mesmo aspecto que qualquer outra aplicacao para o desktop
321 Seguranca
Permitir que uma web application aceda ao disco de armazenamento do utilizador
pode comprometer seriamente a sua seguranca Neste sentido o Adobe AIR tem
suporte para assinaturas digitais (Secure Sockets Layer (SSL)) que podem ser com-
pradas pelas equipas de desenvolvimento que o desejem e cujos certificados serao
apresentados ao utilizador no momento da instalacao Um outro aspecto ainda
relativo a seguranca e o mecanismo de isolamento de cada ambiente (sandbox )
322 Assinatura do codigo
O runtime AIR exige que todas as aplicacoes estejam digitalmente assinadas As
assinaturas digitais de codigo sao um processo que visa garantir a integridade da
aplicacao e a identidade do seu autor no momento da instalacao As equipas de
desenvolvimento podem ldquoassinarrdquo uma aplicacao utilizando um certificado atribuıdo
por uma Entidade Certificadora (Certification Authority) ou atraves de um certifi-
cado individual (self signed certificate) Neste momento o Adobe AIR suporta como
entidades certificadoras a Verisign e a Thawte [Ado08]
O instalador apresenta o nome de quem publica a aplicacao quando o codigo tiver
sido assinado com um certificado que apresente confianca ou que esteja encadeado
com um certificado que tenha ja sido aceite no computador em que se esta a instalar
a aplicacao
As equipas de desenvolvimento podem tambem assinar as aplicacoes com um
certificado auto-atribuıdo (um certificado criado por elas proprias) mas neste caso
o instalador apresentara estas aplicacoes como sendo de uma origem nao verificada
O AIR utiliza a infraestrutura publica de chaves [Ent07] suportada pelo arquivo
local do sistema operativo Para que a origem da aplicacao seja reconhecida o
computador onde a aplicacao AIR esta a ser instalada tem que confiar directamente
no certificado que foi utilizado para assinar a aplicacao ou confiar num certificado
que esteja num encadeamento logico de certificados confiados e que se ligue desta
forma ao certificado utilizado para assinar a aplicacao
Todas as aplicacoes AIR tem caracterısticas em comum independentemente da
tecnologia utilizada para o seu desenvolvimento (HTMLFlexFlash) No ambito
de uma aplicacao AIR existem um conjunto de APIs que estao disponıveis e que
tornam possıvel o acesso ao sistema local (leitura e escrita) e a recursos de rede que
22
Estado da arte
de outra forma nunca estariam acessıveis a partir de uma web application comum
Cada aplicacao AIR possui tambem diferentes nıveis de isolamento chamados secu-
rity sandboxes dependendo do tipo de conteudo que esta a ser carregado e do seu
objectivo
bull Isolamento ao nıvel da aplicacao5 ndash E a raiz de cada aplicacao AIR Este
nıvel de isolamento permite o acesso a APIs privilegiadas e especıficas do
AIR Em contrapartida e negado o acesso a algumas APIs que poderiam ser
facilmente utilizadas de forma maliciosa contra o utilizador final Importacao
dinamica de conteudos remotos e geralmente proibido e as tecnicas e mecan-
ismos de geracao dinamica de codigo sao fortemente restringidas Apenas
conteudo carregado directamente da directoria base da aplicacao podera ser
colocado neste nıvel de isolamento
bull Isolamento nao especıfico da aplicacao6 ndash contem todo o outro conteudo
que nao tenha sido carregado directamente para o isolamento da aplicacao
Isto inclui conteudo local e remoto Este tipo de conteudo nao tem acesso
directo as APIs do AIR e rege-se pelas mesmas regras tal como se tivesse sido
carregado por um browser a partir da mesma localizacao (por exemplo HTML
carregado a partir de um domınio remoto comporta-se da mesma forma que se
fosse acedido a partir do browser)
33 Mozilla Prism
331 XML User Interface Language
O eXtensible User Interface Language (XUL) e uma linguagem de anotacao
baseada em XML desenvolvida pela Mozilla Foundation que opera em aplicacoes
Mozilla multi plataforma tal como o Firefox O motor Gecko e a unica imple-
mentacao completa desta linguagem que foi desenhada sobre padroes web comuns
como CSS JavaScript e o DOM e permite o desenvolvimento de interfaces graficas
utilizando elementos pre-definidos tais como window box page textbox radio
button entre outros Infelizmente o XUL nao possui qualquer especificacao formal
ou implementacoes de inter-operabilidade para outros motores que nao o Gecko No
entanto a sua implementacao e licenciada em codigo aberto pelas licencas GNU Gen-
eral Public License (GPL) GNU Lesser General Public License (LGPL) e Mozilla
Public License (MPL)
Enunciam-se algumas caracterısticas desta linguagem
5NT application sandbox6NT non-application sandbox
23
Estado da arte
Liguagem de anotacao poderosa baseada em componentes (widgets) O ob-
jectivo do XUL e permitir a construcao de aplicacoes multi-plataforma em
claro contraste com o Dynamic HyperText Transfer Protocol (DHTML) que se
destina ao desenvolvimento de paginas web Por esta razao o XUL esta orien-
tado a componentes tais como janelas botoes e etiquetas em vez de paginas
cabecalhos de texto e ligacoes de hipertexto Investir tempo e esforco para
atingir este mesmo resultado em aplicacoes baseadas em DHTML compromete
frequentemente a complexidade e desempenho da aplicacao
Baseado em padroes O XUL e um dialecto XML baseado no padrao W3C XML
10 As aplicacoes escritas em XUL sao tambem baseadas em especificacoes
W3C adicionais como HTML 40 CSS DOM nıvel 1 e 2 JavaScript 15
incluindo ECMA-262 Edition 3 (ECMAscript)
Portabilidade entre plataformas Tal como HTML o XUL foi desenhado para
ser independente da plataforma em que e utilizado tornando as aplicacoes
facilmente portaveis entre sistemas operativos nos quais o Mozilla e suportado
Uma vez que o XUL oferece um nıvel de abstraccao dos componentes graficos
de interface que disponibiliza implementa a premissa ldquoum codigo para todas
as plataformasrdquo A interface grafica de todos os produtos centrais Mozilla
(browser instant messenger livro de enderecos) e escrita em XUL com um
unico codigo base que suporta todas as plataformas Mozilla
Separacao entre o nıvel de apresentacao e a logica de negocio Uma das
maiores preocupacoes no desenvolvimento para a Internet e a forte ligacao
entre estas duas camadas (interface e logica) Isto constitui um problema sig-
nificativo no desenvolvimento de grandes aplicacoes especialmente quando o
desenvolvimento e feito em ambientes de equipa porque as capacidades de de-
senvolvimento destas duas partes da aplicacao estao muitas vezes espalhadas
por diferentes elementos O XUL permite uma clara distincao entre a definicao
da aplicacao cliente e da logica de implementacao (XUL eXtensible Binding
Language (XBL) e JavaScript) apresentacao (CSS e imagens) internacional-
izacao (Document Type Definitions (DTDs) e etiquetas de texto em lınguas
especıficas guardados em ficheiros properties) O esquema grafico e apre-
sentacao de uma aplicacao XUL pode ser alterado de forma independente da
sua logica ou implementacao e a aplicacao pode ainda ser traduzida (interna-
tionalization) de forma independente da sua logica implementacao ou apre-
sentacao Este grau de separacao resulta em aplicacoes que sao mais faceis de
manter pelos programadores e facilmente adaptadas por designers e tradutores
24
Estado da arte
Facil adaptacao Outro benefıcio que advem do nıvel de separacao entre logica
de negocio e apresentacao oferecido pelo XUL e a facilidade com que se pode
adaptar uma aplicacao para diferentes clientes ou grupos de utilizadores Um
programador pode utilizar a mesma aplicacao base e adapta-la consoante as
necessidades atraves de diferentes temas (skins) e ficheiros de lınguas Desta
forma uma aplicacao escrita e desenvolvida em Ingles pode ser rapidamente
traduzida para Portugues e distribuıda com outra aparencia mais apropriada
ao cliente alvo
332 Prism
O Mozilla Prism e um browser simplificado e ldquointerpretadorrdquo de XUL (tambem
designado por XULRunner) que acolhe web applications sem a interface grafica ha-
bitual de um browser Baseia-se num conceito designado por Site Specific Browser
(SSB) Um SSB e uma aplicacao com um browser embebido desenhado para exe-
cutar apenas uma web application Nao possui os menus e barras de ferramentas
habituais Um SSB tem uma integracao com o sistema operativo e com o desktop
muito mais estreita do que uma web application acedida atraves de um browser uma
vez que e executado em janela propria
O Prism resulta de uma experiencia da Mozilla e visa reduzir as diferencas entre
as desktop applications tradicionais e as web applications Um dos aspectos focados e
a experiencia do utilizador Numa apresentacao oficial e dito que ldquo[o Prism] pretende
ser uma ponte entre as diferencas que existem entre as aplicacoes tradicionais de
desktop e as web applications explorando novos modelos de usabilidade enquanto
que a linha que as separa se continua a definirrdquo [Lab07]
34 HTML 5
A especificacao HTML 5 [Hic08] que se encontra em fase de desenvolvimento
pelo grupo WHATWG pretende ser uma norma de substituicao dos padroes HTML
4 XHTML 1x e do DOM2 HTML Uma das propriedades que o distingue das tec-
nologias que pretende substituir e precisamente o suporte para OWA e armazena-
mento de dados no cliente de uma forma relacional Nao sendo propriamente uma
tecnologia ndashmas antes uma especificacao ndashe aqui mencionada por ter servido como
referencia a diversas implementacoes de funcionalidades offline e por se considerar
que venha a ter um impacto significativo nas implementacoes de diversos browsers
Dion Almaer defendeu no seu blogue que o Gears era uma implementacao do
HTML 5 No seu artigo ldquoGears as a bleeding-edge HTML 5 implementationrdquo [Alm08]
o autor diz que ambos ndasho Gears e o HTML 5 ndashpretendem dar a web caracterısticas
25
Estado da arte
semelhantes e nao encontrar motivo de ldquocompeticaordquo entre as duas mas que en-
quanto o HTML 5 e uma especificacao o Gears e uma implementacao
No entanto tambem e verdade que o HTML 5 cobre muitos outros pontos para
alem das OWA que saem completamente fora do ambito do Gears Se esta es-
pecificacao atingir um estado de maturidade que possibilite a sua adopcao pelos
principais browsers tornando nativo do browser o suporte OWA entao deixara de
fazer sentido a existencia de uma extensao como o Gears
A especificacao HTML 5 disponibiliza duas APIs relevantes para o tema das
OWA
1 Uma base de dados baseada em SQL que permite o armazenamento de dados
do lado do cliente
2 Uma ldquocacherdquo HTTP que garante a disponibilidade das aplicacoes mesmo quando
o utilizador nao possui uma ligacao a Internet
Estas caracterısticas sao as bases da tecnologia das OWA e tem correspondencia
com os pontos analisados nas seccoes 311 e 311
35 Web applications que usam funcionalidades offline
Nesta seccao apresentam-se algumas web applications que actualmente disponi-
bilizam funcionalidades offline Estas aplicacoes foram escolhidas para uma analise
mais pormenorizada por utilizarem o Gears que tal como descrito na seccao 4 foi
a tecnologia escolhida para o projecto
351 Google Reader e Google Docs
O Google Reader7 e um leitor de feeds RSS Permite gerir a subscricao de varios
sites simultaneamente que disponibilizem conteudos neste formato e foi a primeira
web application da Google com uma versao offline publicamente acessıvel (desde
Junho de 2007)
O Google Reader implementa o modo ldquoutilizador deciderdquo oferecendo na sua
interface um botao que permite alternar entre os modos online e offline
O Google Docs8 e uma web application que permite a criacao e edicao de doc-
umentos de texto folhas de calculo e apresentacoes Era ja publico desde Janeiro
de 2008 que o Google estava a desenvolver uma versao OWA desta aplicacao mas o
acesso a uma versao experimental so foi possıvel a partir de 31 de Maio de 2008
7Google Reader - httpreadergooglecom8Google Docs - httpdocsgooglecom
26
Estado da arte
A implementacao das funcionalidades offline nestas duas aplicacoes seguiu difer-
entes aproximacoes principalmente porque o Google Reader apresenta ao utilizador
informacoes que sao fornecidas por fontes externas enquanto que no Google Docs
a informacao e criada e editada pelo utilizador sobre a forma de documentos
A diferente origem da informacao implica que no Google Reader seja necessario
prever casos de excepcao tal como existirem demasiados itens que necessitam de
ser transferidos para o cliente Nao observar este ponto causa um problema grave
de usabilidade e para evitar tempos de espera demasiado longos e uma interface
com pouca capacidade de resposta as accoes do utilizador o Google Reader apenas
transfere para o cliente os dois mil itens mais recentes na transicao para o modo
offline
352 Remember the Milk
O Remember The Milk9 e uma web application desenvolvida por uma equipa
Australiana que proporciona funcionalidades de agenda gestao de tempo e de tare-
fas e foi uma das primeiras aplicacoes independentes do Google a adoptar o Gears
para acessos em modo offline Permite que os seus utilizadores facam uma gestao
de tarefas agrupando-as em listas adicionando-lhes campos de informacao adicional
ou dando-lhes informacao geografica (recorrendo ao servico Google Maps10) Entre
a sua lista de funcionalidades encontra-se ainda a possibilidade de importar e ex-
portar eventos no formato iCalendar (ics) etiquetas (tags) em tarefas publicacao
Really Simple Syndication (RSS) e partilha de categorias de tarefas de acordo com
diferentes nıveis de permissoes de acesso definidos pelo utilizador
353 MySpace e WordPresscom
O MySpace uma das maiores social networks na Internet anunciou recente-
mente que vai disponibilizar uma versao do seu cliente de e-mail que utiliza o Gears
para acelerar o seu desempenho Numa fase inicial estara disponıvel apenas para
utilizadores que tenham cinco mil ou mais mensagens na sua caixa de correio e
permitira efectuar pesquisas muito mais rapido que a sua versao online
O servico de blogs Wordpresscom anunciou tambem o inıcio da utilizacao desta
tecnologia com o fim de melhorar o desempenho A versao que utiliza esta tecnologia
descarrega e armazena no cliente um conjunto de imagens e scripts que passam a
ter preferencia sobre os seus congeneres online e que permitem acelerar o processo
de carregamento da aplicacao e visualizacao de blogs
9Remember The Milk ndash httpwwwrememberthemilkcom10Google Maps ndash httpmapsgooglecom
27
Estado da arte
O MySpace e o Wordpresscom sao dois exemplos da utilizacao da tecnologia
OWA para optimizacao de web application ja existentes Sem pretenderem disponi-
bilizar uma versao que seja totalmente offline fazem uso do Gears para armazenar no
cliente parte dos recursos frequentemente acedidos na visualizacao das suas paginas
36 Escolha da tecnologia
Apos a analise das tecnologias apresentada nas seccoes 31 a 34 foi necessario es-
tudar a adequacao de cada uma delas ao projecto em questao Desde logo e possıvel
observar que nem todas se dedicam apenas a OWA Por exemplo o Adobe AIR
apesar de ter suporte para OWA apenas disponibiliza algumas das funcionalidades
identificadas como mais indicadas para a execucao do projecto quando utilizado
na sua vertente desktop tal como exposto na Tabela 31 mas a utilizacao desta
vertente implicaria o desenvolvimento de novas interfaces e de novas formas de co-
municacao (troca de mensagens XML ou JSON) A vertente web do Adobe AIR
foca-se mais especificamente nas Rich Internet Applications e permite a reutilizacao
do codigo ja existente (exigindo naturalmente a sua adaptacao e a implementacao
das funcionalidades pretendidas)
A tecnologia escolhida para a realizacao deste trabalho foi o Gears sendo que
um dos principais factores a influenciar esta opcao foi a liberdade introduzida pela
sua licenca Berkeley Software Distribution (BSD)11
Considerou-se o funcionamento desta ferramenta extremamente adequando a
aplicacao no WOW uma vez que o seu principal objectivo e precisamente tornar
possıvel a execucao offline de uma pagina web e por virtude deste facto o Gears tem
uma API concisa e de simples aplicacao pratica uma vez que nao possui quaisquer
outros elementos distractores O funcionamento do seu ManagedResourceStore ex-
emplificado na Figura 31 com a capacidade de actualizacao de recursos definidos
num ficheiro manifesto especificado em JSON pesou tambem nesta decisao
11Sobre a licenca BSD consultar httpwwwopensourceorglicensesbsd-licensephp e http
wwwlinfoorgbsdlicensehtml
28
Estado da arte
Figura 31 Esquema UML do processo efectuado pelos recursos do Gears do tipoManagedResourceStore para a actualizacao dos conteudos definidos no ficheiro manifesto
29
Estado da arte
Funcionalidade RIAs no browser RIAs no desktop
Disponibilidadeda aplicacao
As aplicacoes podem ser facil-mente exploradas e utilizadas
As aplicacoes quando instal-adas tem maior grau de fun-cionalidades e persistencia
Instalacao Nao e necessario qualquer tipode instalacao
As aplicacoes sao instaladasatraves do browser ou descar-regadas e instaladas comouma aplicacao tradicional
Actualizacoes Aplicacoes sao actualizadascarregando conteudos paraum website
O AIR disponibiliza uma APIque permite que as aplicacoessejam actualizadas de umaforma
Sistemas opera-tivos suportados
As aplicacoes podem ser exe-cutadas em diversos sistemasoperativos e browsers
As aplicacoes sao multi-plataforma e podem serinstaladas e executadas emdiversos sistemas operativos ebrowsers
Linguagens deprogramacao
Javascript e disponibilizadopelo browser e ActionScripte disponibilizado pelo AdobeFlash Player
Maquinas virtuais deJavascript e ActionScriptcompatıveis com o browser
Capacidade deexecucao embackground
As RIAs podem ser execu-tadas numa janela do browser
As aplicacoes podem ser ex-ecutadas em background edisponibilizar notificacoes talcomo uma aplicacao tradi-cional
Persistencia A actividade esta limitada asessao do browser Quando obrowser e encerrado toda ainformacao e descartada
As aplicacoes sao instaladas eestao disponıveis no desktopPodem armazenar informacaolocalmente e estao disponıveisoffline
Integracao com odesktop
Integracao com o desktop lim-itada devido a restricoes im-postas pelo browser
As aplicacoes podem acederao sistema de ficheiro ao clip-board eventos notificacoesetc
Controlo da inter-face com o uti-lizador
As aplicacoes sao acedidasatraves de uma janela dobrowser que tem os seusproprios controlos e visualgrafico
As aplicacoes tem um vi-sual grafico proprio em janelapropria
Armazenamentode dados
As aplicacoes tem armazena-mento limitado que pode serreescrito pelo browser
As aplicacoes tem acesso a to-talidade do espaco disponıvellocalmente e a uma base dedados com a possibilidade deencriptacao
Tabela 31 Comparacao das funcionalidades oferecidas pelo Adobe AIR para as platafor-mas web e desktop
30
Estado da arte
Aplicacao Modo de execucao utilizadoGoogle Reader Utiliza o modo ldquoutilizador deciderdquo disponibilizando
ao utilizador um botao para alternar entre os modosonline e offline Como lida com informacao recol-hida de fontes externas de natureza frequentementeefemera o processo de sincronizacao apenas transfereos dois mil itens mais recentes quando passa ao es-tado offline Neste modo sao ainda guardadas in-formacoes de itens lidos e etiquetas atribuıdas quesao sincronizadas com o servidor quando o utilizadorvoltar a activar estado online
Google Docs Utiliza o modo ldquoaplicacao deciderdquo permitindo que outilizador edite os conteudos de documentos de textofolhas de calculo e de apresentacoes independente-mente do estado da ligacao desde o momento em queas funcionalidades offline sao activadas A aplicacaofaz pequenas sincronizacoes com o servidor sempre quenecessario
Remember the Milk Utiliza um modo hıbrido entre ldquoaplicacao deciderdquo eldquoutilizador deciderdquo A aplicacao encarrega-se da sin-cronizacao de dados mas disponibiliza um controlona sua interface que permite despoletar manualmenteeste processo para situacoes em que o utilizador fez al-teracoes recentes e pretende usufruir das capacidadesoffline imediatamente
MySpace O MySpace anunciou a utilizacao de mecanismos dearmazenamento de dados no cliente com recurso atecnologias OWA para melhorar o desempenho doseu cliente web de correio electronico nomeadamenteno que diz respeito a operacoes de pesquisa e or-denacao Inicialmente esta funcionalidade estara ape-nas disponıvel para utilizadores com cinco mil ou maismensagens na sua caixa de correio mas nao e aindaclaro se sera disponibilizada uma versao totalmenteoffline
Tabela 32 Resumo da utilizacao de tecnologias OWA em algumas web applications con-sideradas na analise do estado da arte
31
Estado da arte
32
Capıtulo 4
Desenvolvimento
Neste capıtulo introduz-se a aplicacao WOW e apresenta-se o estudo que foi
feito da adequacao de cada tecnologia para a implementacao da funcionalidade of-
fline nesta plataforma Fazem-se diversas consideracoes sobre opcoes a tomar na
concepcao de OWAs e problemas comuns na sua implementacao bem como sug-
estoes para os resolver O WOW e uma aplicacao ja existente de gestao de ordens
de trabalho e do fluxo de tarefas numa empresa ou organizacao
41 Como ficar offline
Na maior parte das web applications de hoje nao existe uma camada de dados
real A aplicacao exemplificada na Figura 41 ao longo da sua execucao acede
directamente a sua unica fonte de dados (o servidor) atraves de chamadas Ajax sem
que exista uma separacao clara destas duas camadas
Para que uma web application seja capaz de ser executada sem uma ligacao
activa a Internet e mantenha o seu caracter dinamico torna-se necessario incluir
Figura 41 Exemplo de uma arquitectura de uma web application sem uma camada deabstraccao de dados Figura adaptada de http gears google com
33
Desenvolvimento
Figura 42 Exemplo de uma arquitectura de uma web application com uma camada deabstraccao de dados Figura adaptada de http gears google com
um mecanismo de armazenamento de dados local seja uma base de dados ou a
capacidade de acesso ao disco No entanto este mecanismo introduz dois problemas
1 Qual das fontes de dados utilizar quando um utilizador faz um pedido de
informacao
2 A necessidade de implementar uma camada de acesso a dados que seja coerente
quer se use o servidor remoto ou local
Por exemplo em vez de a aplicacao Ajax fazer um pedido relativo as contas de
todos os utilizadores em formato JSON directamente ao servidor remoto podera ao
inves fazer o pedido a um objecto intermedio da camada de dados Este objecto
demonstrado na Figura 42 sera responsavel por implementar uma interface de
acesso a base de dados e retornar um objecto JavaScript com uma representacao da
resposta do servidor
Mas a existencia de uma segunda fonte de dados torna recomendavel tambem
a implementacao de uma camada de data switching que em funcao da existencia
de conexao a Internet e da necessidade de actualizacao dos dados decide se faz o
pedido ao servidor remoto ou se fornece os dados presentes localmente Este objecto
apresentado na Figura 43 decidira de forma transparente para o utilizador se le ou
escreve os dados localmente ou se os enviapede ao servidor remoto e pode tambem
iniciar o processo de convergencia de dados e de resolucao de conflitos
411 Funcionalidades disponıveis em modo offline
Por razoes praticas e provavel que nem todas as funcionalidades da aplicacao
possam ser disponibilizadas em modo offline E necessario escolher quais as fun-
cionalidades a disponibilizar no modo offline da aplicacao e implementar a logica
que decide quando utilizar a base de dados local ou o servidor remoto Apesar do
acesso a base de dados local ser muito mais rapido do que aceder ao servidor o
acesso local nem sempre e preferido Ha varias razoes que podem tornar necessario
escolher o acesso ao servidor em vez do acesso local
34
Desenvolvimento
Figura 43 Exemplo de uma arquitectura de uma web application com uma camada deabstraccao de dados e um data switch Figura adaptada de http gears google com
1 A informacao pode ter uma natureza efemera e nao fazer sentido guarda-la
localmente Exemplo dados em tempo real da bolsa de valores de Lisboa
2 Algumas aplicacoes lidam com informacao que so faz sentido na presenca de
uma ligacao Exemplo Instant Messaging
3 A aplicacao podera escolher apenas guardar a informacao acedida mais fre-
quentemente Exemplo para o utilizador poder alterar a lıngua de apre-
sentacao da aplicacao os conteudos terao que ser guardados em todas as
lınguas disponibilizadas pela aplicacao O custo de implementacao de algu-
mas funcionalidades pode nao compensar o benefıcio
4 A capacidade de processamento ou de armazenamento de dados pode inviabi-
lizar algumas funcionalidades offline Exemplo se uma dada funcionalidade
necessita de uma capacidade de armazenamento de dados para alem do razoavel
de um computador pessoal para ser util (visualizador de mapas)
42 Modos de execucao
Um aspecto que e necessario estudar para qualquer web application que se deseje
disponibilizar offline prende-se com tres modos de execucao que devem ser consid-
erados
1 Utilizador decide o modo de execucao A aplicacao tem modos distintos
de execucao para os estados online e offline geralmente indicados na interface
com o utilizador O utilizador e informado do estado da ligacao e participa na
alteracao de estado de execucao da aplicacao interagindo com a sua interface
2 Aplicacao decide o modo de execucao Pode ser implementado na propria
aplicacao um mecanismo de deteccao do estado da ligacao (por exemplo atraves
35
Desenvolvimento
de chamadas Ajax periodicas) transitando de estado e sincronizando automati-
camente Desta forma o utilizador nao precisa de participar na alteracao de
estado a menos que exista um conflito de dados que requeira a sua atencao
3 Aplicacao assume sempre o estado offline Outra hipotese sera imple-
mentar uma web application que assume sempre estar na ausencia de uma
ligacao ao servidor de dados Esta aplicacao responde aos pedidos do uti-
lizador efectuando pedidos de informacao ao servidor mas nao dependendo
de uma resposta valida para mostrar a informacao que ja tinha disponıvel an-
teriormente A sincronizacao de dados com o servidor e tentada sempre que
existam dados para submeter e uma accao do utilizador
421 Modo ldquoutilizador deciderdquo
Neste modo de execucao quando a aplicacao esta online comunica com o servidor
remoto quando esta offline comunica com a base de dados local A informacao tem
que ser sincronizada sempre que se muda de modo A principal vantagem desta opcao
e que e a mais simples de implementar mesmo para uma aplicacao ja existente e
portanto uma forma expedita de disponibilizar uma OWA No entanto tem tambem
algumas desvantagens que devem ser consideradas
1 O utilizador tem que se lembrar de fazer a alteracao de estado de execucao
Caso contrario podera estar a trabalhar inadvertidamente numa versao offline
com dados antigos ou nao ter a informacao necessaria se perder subitamente
a ligacao
2 Se a ligacao for intermitente o utilizador tera ou que escolher um dos modos
de execucao ou estar constantemente a trocar
3 Uma vez que a base de dados nao esta sempre actualizada nao podera ser
utilizada para melhorar a rapidez de execucao da aplicacao quando em modo
online
422 Modo aplicacao decide
A deteccao do estado da ligacao pode ser implementada atraves de um pedido
assıncrono ao servidor tal como ilustrado na Figura 44 O resultado deste pedido
definira o estado online (em caso de sucesso) ou offline (em caso de falha) A
sincronizacao de dados podera ser feita sempre que ocorra uma transicao do es-
tado offline para o estado online No entanto este metodo nao se revela eficiente
36
Desenvolvimento
Figura 44 Esquema grafico ilustrando uma OWA executando no browser utilizando ummodo de execucao do tipo ldquoaplicacao deciderdquo com deteccao automatica do estado daligacao via pedidos Ajax assıncronos a cada cinco segundos
para grandes aplicacoes uma vez que requer a troca de mensagens demasiado fre-
quentes com o servidor que se destinam exclusivamente a monitorizacao do estado
da ligacao
423 Modo ldquoaplicacao assume o estado offlinerdquo
Uma aplicacao transparente funciona assumindo sempre que esta em modo of-
fline ou pelo menos que pode perder a ligacao a qualquer momento Neste modo
tira-se o maximo partido do armazenamento local e fazem-se pequenas mas contınuas
sincronizacoes com o servidor sempre que este esteja disponıvel A sincronizacao de
dados tambem e feita sempre que se volta ao estado online
As vantagens de uma web application transparente sao as seguintes
bull Uma melhor experiencia para o utilizador uma vez que este nao tem que se
preocupar com o estado da ligacao ou com a transicao de estados
bull A aplicacao funciona de forma coerente mesmo que a ligacao seja intermitente
bull Uma vez que o armazenamento local e mantido actualizado pode ser utilizado
para melhorar o desempenho da aplicacao
Foram identificadas as seguintes desvantagens
bull E mais difıcil de implementar e a sincronizacao acarreta cuidados especiais
bull E necessario um cuidado adicional para evitar que as operacoes de sincronizacao
frequentes que ocorrem automaticamente nao afectem os tempos de resposta
da aplicacao
bull Os testes a aplicacao sao mais complexos uma vez que a sincronizacao de dados
nao ocorre em resposta a uma accao do utilizador
37
Desenvolvimento
43 Sincronizacao de dados
A sincronizacao de dados consiste na capacidade de identificar e transferir pe-
riodicamente a versao mais actual dos dados entre o cliente e o(s) servidor(es)
Independentemente do modo de execucao escolhido e mesmo do estado da ligacao
do utilizador a informacao armazenada localmente e a informacao armazenada no
servidor estarao por vezes dessincronizadas Isto podera acontecer sempre que por
exemplo
bull O utilizador faz alteracoes em modo offline
bull A informacao e partilhada e pode ser alterada por uma entidade externa
bull A informacao e fornecida por uma entidade externa
Resolver estas diferencas de forma a que a informacao local e remota encontrem
a igualdade chama-se sincronizacao de dados Ha varias aproximacoes possıveis
para este efeito que dependem da natureza da aplicacao cada uma com vantagens
e desvantagens
A capacidade de suportar a mobilidade dos utilizadores torna-se cada vez um
ponto mais importante de uma web application Para uma organizacao de dimensao
global e vital garantir que os seus colaboradores tem acesso a mesma informacao
que tem disponıvel nos seus postos de trabalho mesmo quando estao fora Na maior
parte dos casos estes colaboradores terao acesso a um computador portatil um
desktop Smartphone ou PDA e atraves destes poderao ter acesso a sua informacao
directamente atraves de ligacoes encriptadas Virtual Private Network (VPN) de um
servidor web ou de outro mecanismo de rede
Esta solucao e simples de implementar mas infelizmente para a maioria dos
colaboradores com grande factor de mobilidade nao e satisfatoria As principais
desvantagens sao as seguintes
bull Requisitos de ligacao Para permitir que os utilizadores acedam a sua in-
formacao e necessario garantir a capacidade constante de comunicacao pelo
menos durante o tempo necessario que assegure a sua transferencia
bull Velocidade de ligacao sem persistencia de dados e em ligacoes de fraca
qualidade a usabilidade por vezes torna-se inaceitavel
bull Ponto crıtico de falha Com este tipo de solucao todos os utilizadores de-
pendem da base de dados que armazena informacao vital para o funcionamento
do cliente
38
Desenvolvimento
bull Scalability do servidor A medida que novos utilizadores sao adicionados ao
sistema o desempenho do servidor e afectado levando a necessidade de maior
capacidade de armazenamento eou processamento
De acordo com a documentacao da Microsoft Sync Framework [Mic08] uma
solucao alternativa consiste em implementar uma Occasionally Connected Appli-
cation (OCA) Uma OCA permite a um utilizador remoto continuar a aceder a
sua informacao mesmo depois de perder a ligacao mas em vez de recorrer a um
servidor recorre a informacao armazenada no seu dispositivo local Para preencher
localmente a informacao que o utilizador necessita uma OCA possui mecanismos
de sincronizacao de dados que sao oferecidos por esta framework
431 Quando sincronizar
Uma das solucoes mais simples de implementar passa por disponibilizar um
mecanismo manual que despoleta a sincronizacao Diz-se manual porque e o uti-
lizador que escolhe quando sincronizar e pode ser implementada simplesmente
fazendo o upload de toda a informacao para o servidor e depois fazendo o download
da copia mais recente da informacao antes de voltar a ficar offline Para que esta
seja uma opcao viavel e necessario que
bull O volume de dados seja suficientemente pequeno para que possa ser transferido
do servidor para o cliente num espaco de tempo aceitavel
bull Que o utilizador indique explicitamente que quer mudar para o estado offline
ou online pressionando um botao da interface
Contudo podem ser identificados alguns problemas relacionados com esta abor-
dagem
bull Os utilizadores nem sempre podem prever o estado das suas ligacoes A ligacao
pode-se perder subitamente ou ter um caracter intermitente
bull O utilizador pode esquecer-se de efectuar a sincronizacao
Outra opcao sera conjugar a sincronizacao de dados com o modo de execucao
transparente A sincronizacao ocorre automaticamente em background de forma
nao intrusiva para o utilizador A aplicacao comunica com o servidor regularmente
efectuando pequenas trocas de dados com o objectivo de manter o sincronismo da
informacao local e remota Esta abordagem pode ser implementada com pedidos
Ajax assıncronos e regulares ao servidor o que permite manter a interaccao com a
interface fluıda evitando bloqueios Estes pedidos sao feitos prevendo as situacoes
39
Desenvolvimento
de disponibilidade ou indisponibilidade (timeout) do servidor Uma outra opcao
sera permitir que o servidor comunique essas alteracoes utilizando Comet1 tal como
descrito em [Wil06] e [Rus06] As vantagens destas aproximacoes sao
bull A informacao esta disponıvel a qualquer altura que o utilizador decida ficar
offline ou que a ligacao seja acidentalmente perdida
bull O desempenho da aplicacao pode ser melhorado quando se estiver a utilizar
uma ligacao a Internet lenta uma vez que o acesso a dados locais e mais
eficiente do que a consulta de dados ao servidor
44 WOW
O WOW e uma plataforma integrada de gestao de ordens de trabalho ja ex-
istente e desenvolvida pela Critical Software SA a qual se pretende adicionar a
capacidade de execucao offline Esta aplicacao e extremamente dinamica e con-
figuravel com um conjunto extremamente rico de funcionalidades das quais se
destacam
bull Gestao de Ordens de Trabalho ndash suportando a gestao dos pedidos desde a
sua criacao ate ao seu fecho tomando em conta os diferentes tipos de pedidos
(ordens de trabalho pedidos de informacao melhorias resolucao de problemas
etc) e diferentes tipos de accoes possıveis para cada um (Figura 45)
bull Monitorizacao de alteracoes ndash Historico de mudancas anexos e estados criando
relatorios de alteracao automaticamente (o que por quem e quando)
bull Uso de Service Level Agreements (SLAs) ndash E possıvel associar a um pedido um
SLA que define qual o perıodo de tempo atribuıdo a resolucao de um pedido
controlando e agilizando a resolucao do mesmo
bull Utilizacao de queries de utilizador configuraveis que permitem acesso rapido
a determinadas ordens de trabalho de acordo com o filtro configurado (por
exemplo ldquoPara mimrdquo ldquoPara o Grupordquo ldquoPelo Grupordquo)
bull Gestao do relacionamento entre pedidos
bull Pesquisa e filtragem de ordens de trabalho
bull Exportacao de dados em formatos padrao (PDF DOC ou XLS)
bull Integravel com solucoes externas
40
Desenvolvimento
Figura 45 Detalhe de um conjunto possıvel de estados e respectivas transicoes para umadada ordem de trabalho no WOW desde a sua submissao no sistema ate a sua conclusaoem fecho ou cancelamento Esta figura representa apenas um exemplo ja que o mapa deestados para uma ordem de trabalho e dinamico e pode ser alterado por um administradorFigura retirada de uma brochura promocional do WOW Critical Software SA
A utilizacao de uma ferramenta deste tipo por parte de uma empresa ou orga-
nizacao oferece vantagens quer a gestao de topo quer aos colaboradores individuais
para os colaboradores individuais o WOW e uma aplicacao onde estao registadas
todas as tarefas contribuindo activamente para o desenvolvimento em ambientes
multi-tarefa e para a organizacao pessoal das tarefas de acordo com prioridades
Para a gestao de topo esta ferramenta permite obter uma visao global do estado da
organizacao em termos de tempo gasto por tarefa executada sendo uma mais valia
para a previsao e gestaoalocacao de recursos
45 Visao geral sobre a arquitectura do WOW
O WOW e interessante nao so do ponto de vista de produto como tambem do
ponto de vista de plataforma Existem diversos plug-ins que estendem as funcional-
idades do WOW e existem ate projectos que pretendem usar a arquitectura do
WOW para criar produtos com fins diferentes do inicial (por exemplo o WOW-
Storm ndash um sistema de registo e classificacao social de ideias)
De modo a conseguir ter essa expansibilidade a plataforma WOW assenta sob
uma arquitectura distribuıda modular e expansıvel com uma componente central
ndash o core ndash estruturado em camadas logicas E no core que se situam todas as
1O Comet e um conceito semelhante ao Ajax introduzido por Alex Russel mas no qual e o servidor quetoma a iniciativa de ldquoenviarrdquo os dados ao browser sem que este tenha que efectuar um pedido Tambem econhecido por Ajax Push Reverse Ajax ou HTTP Streaming
41
Desenvolvimento
funcionalidades base da aplicacao quer a nıvel logico funcional e de apresentacao
quer a nıvel de gestao e configuracao
E possıvel a execucao de varias instancias do core simultaneamente em servidores
distintos o que permite a alta escalabilidade e disponibilidade desta aplicacao A
consistencia dos dados fica sempre garantida atraves da partilha da base de dados
e pelo balanceamento dos pedidos uma vez que cada um e encaminhado para uma
unica instancia
O WOW apresenta tambem a vantagem de ser uma plataforma extensıvel E
possıvel adicionar novas caracterısticas a plataforma atraves de componentes que se
podem ser divididos em duas categorias plugins e connectors
Os plugins sao componentes que se encontram no mesmo no fısico que a aplicacao
partilhando do mesmo contexto de execucao do core Sao assim uma forma mais
directa de obter informacao da plataforma visto que nao possuem restricoes de
acesso aos dados nem dependencias externas A arquitectura deste componente tera
assim que permitir varias execucoes instanciadas cada uma associada a um core
Por outro lado os connectors sao componentes que se encontram distribuıdos
comunicando externamente com o core Quer a sua execucao quer a obtencao
dos dados estao assim dependentes de interfaces de comunicacao externas que a
plataforma disponibiliza Estes componentes ao contrario dos plugins sao instan-
ciados unicamente e recorrem ao protocolo de comunicacao Java Messaging Service
(JMS) para comunicar com o core
46 WOW Offline
Para alem das opcoes tomadas relativamente a tecnologia a utilizar surgiu
tambem a necessidade de optar por um dos modos de execucao apresentados na
seccao 42
Das tres opcoes possıveis foi o modo ldquoaplicacao assume o estado offlinerdquo descrito
na seccao 423 que mereceu a maior atencao uma vez que reune as vantagens de
uma experiencia mais positiva para o utilizador (uma vez que este nao tem que
participar activamente na alteracao do modo execucao como descrito na seccao 421)
e nao constitui uma sobrecarga excessiva para servidor (como o modo abordado na
seccao 422)
No entanto esta opcao comprometia a complexidade da implementacao para alem
dos objectivos propostos para este projecto e para cumprir o prazo dado foi tomada
a decisao de implementar o modo ldquoutilizador deciderdquo especificando apenas de forma
teorica o modo ldquoaplicacao assume o estado offlinerdquo
As caracterısticas do Gears foram ja descritas na seccao 31 Na Figura 47
mostra-se a sua forma de funcionamento quando integrado numa web application
42
Desenvolvimento
Nesta figura representa-se o modulo LocalServer do Gears como um ponto de de-
cisao Aqui sao testadas as condicoes que determinam se o pedido sera interceptado e
servido localmente ou se prossegue para uma maquina remota E tambem represen-
tada uma base de dados que corresponde ao modulo Database mas que podera nao
ser utilizada Este modulo tal como o modulo Workerpool tem caracter opcional
e sao utilizados consoante os requisitos da aplicacao
A plataforma WOW lida com mais dados do que e necessario passar para o
lado do cliente Em conformidade com o ja exposto na seccao 411 volta-se a
frisar que nao se pretende recriar toda a logica de negocio nem os conteudos da
base de dados no cliente pela sua complexidade e volume de dados Pretende-se
pelo contrario permitir que os utilizadores tirem partido da capacidade de poder
consultar as suas ordens de trabalho quando nao dispoe de uma ligacao transferindo
apenas o essencial para isto seja possıvel
A pagina inicial do WOW apresenta um resumo das ordens de trabalho abertas
ndash enviadas e recebidas ndash que se pretende permitir visualizar offline (ver Figura 46)
Como prova de conceito foi efectuada uma abordagem pragmatica das varias possi-
bilidades descritas na seccao 42
461 Modo ldquoaplicacao deciderdquo com deteccao automatica da ligacao
A primeira abordagem estudada para a disponibilizacao das funcionalidades of-
fline foi o modo ldquoaplicacao deciderdquo com deteccao automatica de ligacao apresentado
na seccao 422 Para que isto seja possıvel foi implementado um mecanismo de ver-
ificacao periodica do estado da ligacao atraves de chamadas Ajax assıncronas O
resultado destes pedidos determina o estado da aplicacao executando as tarefas de
sincronizacao de dados sempre que pertinente Este metodo embora imediato e
simples de implementar depressa se revelou inadequado para o projecto devido ao
elevado consumo de recursos do servidor que a utilizacao intensiva faz esperar a
comunidade da plataforma WOW no principal cliente excede os 7000 utilizadores
Foi estimado que para uma utilizacao de fluidez aceitavel o estado da ligacao deveria
ser testado a cada cinco segundos Assumindo uma adesao (previsao pessimista) de
1 aos servicos offline assistir-se-ia a cerca de 840 pedidos adicionais por minuto
Mas o principal problema desta aproximacao prende-se com o facto de a ver-
ificacao ser feita em intervalos de tempo discretos levando a possibilidade de a
aplicacao poder ter em dado momento uma representacao errada do seu estado
real da ligacao Este problema e ilustrado na Figura 48 onde se ve claramente a
discrepancia entre o estado real da ligacao e a representacao interna que esta tem
Note-se que nesta janela de tempo qualquer accao do utilizador que exija uma
resposta sıncrona do utilizador leva-lo-a para um ldquobeco sem saıdardquo onde nao tera
43
Desenvolvimento
Figura 46 A pagina inicial do WOW apresenta um resumo das ultimas ordens de trabalhoenviadas e recebidas Na imagem pode-se observar a transicao do estado online para offline
acesso a versao offline porque a aplicacao nao fez a transicao automatica nem acesso
a versao online porque na verdade nao possui uma ligacao O que acontecera nesta
situacao sera uma tentativa de acesso ao servidor por parte da aplicacao numa
altura em que este se encontra indisponıvel e o resultado sera uma mensagem de
ldquopedido excedeu o tempordquo apresentado pelo browser Este e um estado sem retorno
porque apos o browser apresentar esta mensagem todos os recursos JavaScript ficam
indisponıveis tornando impossıvel o regresso ao estado anterior ou o tratamento do
erro de qualquer outra forma No entanto as chamadas Ajax podem ser tratadas de
forma especial para a eventualidade de falha e portanto nao constituem problema
44
Desenvolvimento
Figura 47 Ilustracao do funcionamento do Gears numa web application que utiliza ummotor Ajax Os pedidos HTTP ou HTTPS podem ser interceptados e tratados localmenteou podem ser feitos a uma maquina remota consoante se verificarem ou nao as condicoesexpressas no ponto 311 E representado um acesso a uma base de dados local (fornecidapelo Gears) mas a sua utilizacao e opcional
462 Implementacao do modo ldquoutilizador deciderdquo
Este modo de execucao foi ja descrito na seccao 421 e a sua principal carac-
terıstica e ser o utilizador a decidir se a aplicacao deve utilizar um servidor remoto
ou a maquina local como fornecedor de dados
Relativamente ao WOW o WOW Offline na vertente ldquoutilizador deciderdquo vem
alterar os seus casos de uso dando ao utilizador a possibilidade de alterar o estado
de execucao da aplicacao (entre online e offline) Resta dizer que no modo online se
mantem todas as funcionalidades anteriores e que no modo offline torna-se possıvel
visualizar os conteudos da pagina principal do WOW (Figura 46) e os detalhes das
ordens de trabalho (Figura 49) tal como expressa a Figura 410
Esta aproximacao foi utilizada na prova de conceito do WOW adicionando um
controlo a interface desta aplicacao que permite ao utilizador alternar entre os esta-
dos online e offline Na transicao de online para offline sao descarregados os recursos
necessarios para a execucao desta aplicacao sem recorrer a Internet Para o fazer
45
Desenvolvimento
Figura 48 Neste exemplo do modo ldquoaplicacao deciderdquo o teste da ligacao e feito e feito acada cinco segundos O resultado deste teste nao reflecte sempre o estado real da aplicacaopodendo levar a aplicacao a ter comportamentos indesejaveis Na figura assinala-se umperıodo de tempo no qual a representacao interna do estado da ligacao nao corresponde arealidade
e utilizado um recurso ResourceStore e um ManagedResourceStore (introduzidos
em 311) O primeiro e utilizado para armazenar a pagina principal do WOW ndash do-
ravante designada por homejsp ndash e o segundo e utilizado para armazenar imagens
folhas de estilo CSS e scripts JavaScript
Para a implementacao deste modo de execucao foram identificadas as seguintes
tarefas
1 Guardar informacao que permita a recriacao das paginas que se pretende
disponibilizar offline (utilizando o Gears)
2 Disponibilizar um controlo que permita alterar o estado de execucao atraves
da interaccao com a pagina principal
3 Durante a sincronizacao de dados apresentar o progresso da transferencia de
dados
O primeiro passo consistiu na identificacao de todos os conteudos que sao necessarios
transferir para a execucao offline Foi utilizado um recurso do Gears do tipo
ManagedResourceStore que recorre a um ficheiro manifesto para identificar to-
dos os ficheiros que deve transferir Este recurso e gerido automaticamente pelo
Gears transferindo para o cliente a versao mais recente sempre que e necessario
isto e sempre que exista um ficheiro manifesto com uma identificacao de versao que
seja diferente da actualmente disponıvel no cliente Uma vez identificados todos
ficheiros necessarios para a execucao offline num (ou mais) ficheiros manifesto o
Gears encarrega-se da sua actualizacao mas o preenchimento destes ficheiros man-
ifesto e manual o que se traduz num cuidado extra na manutencao da aplicacao
A forma como esta informacao e guardada deve tambem ser cuidadosamente
estudada A opcao mais flexıvel passa por utilizar o modulo Database apresentado
na seccao 311 e guardar a informacao de uma forma relacional Para a recriacao
das paginas pode ser disponibilizada uma versao HTML da pagina que funciona
46
Desenvolvimento
Figura 49 Pagina de visualizacao do detalhe de uma ordem de trabalho
como template nao possui quaisquer dados e e utilizada apenas em modo offline E
preenchida para cada pedido retirando os dados relevantes da base de dados
O modelo de dados do WOW torna esta opcao extremamente trabalhosa uma
vez que as entidades envolvidas na geracao de cada pagina de informacao sobre
cada ordem de trabalho tem relacoes de dependencia complexas seguindo padroes
muito variaveis Por exemplo em cada ordem de trabalho existe um formulario que
permite a sua progressao de estado com diversos campos opcionais e obrigatorios
este formulario e definido pelo administrador e esta relacionado nao apenas com o
tipo de ordem de trabalho mas tambem com o estado actual em que esta se encontra
e a accao que se pretende realizar O elevado numero de combinacoes de tipos de
ordem de trabalho estados e accoes que existem num dado momento juntamente
com a sua possibilidade de alteracao obrigariam a implementacao de uma logica de
negocio complexa o que esta fora do ambito deste projecto
47
Desenvolvimento
Figura 410 Esquema UML que expressa os casos de uso do WOW Offline no modoldquoutilizador deciderdquo
463 Especificacao do modo ldquoaplicacao assume o estado offlinerdquo
A aproximacao para o modo ldquoaplicacao assume o estado offlinerdquo foi tambem
dividida em varias tarefas
1 Guardar informacao que permita a recriacao da pagina principal do lado do
cliente no estado offline (utilizando o Gears)
2 Dotar a aplicacao do cliente de um mecanismo de deteccao da ligacao
3 Identificar os ldquomomentos chaverdquo em que devera ocorrer sincronizacao de dados
4 Implementar a sincronizacao de dados
A sincronizacao de dados deve ser feita em ambas as transicoes online-offline e
offline-online quer para transferir novos dados do servidor (os pedidos podem ser
alterados por outros utilizadores) quando se transita do estado quer para comunicar
eventuais alteracoes feitas em modo offline
Relativamente ao WOW o WOW Offline na vertente ldquoaplicacao assume o es-
tado offlinerdquo vem alterar os seus casos de uso dando ao utilizador a possibilidade
de activar esta funcionalidade A partir do momento que a funcionalidade esta ac-
tivada o utilizador deve tambem ter a possibilidade de gerir algumas preferencias
relacionadas com privacidade de dados Devera ter a hipotese de desactivar o ar-
mazenamento local e de remover todos os dados ja armazenados tal como descrito
na Figura 411
48
Desenvolvimento
Figura 411 Esquema UML que expressa os casos de uso do WOW Offline no modoldquoutilizador deciderdquo
A primeira vez que o WOW Offline e acedido por um cliente e caso seja detec-
tada a presenca do Gears todos os recursos necessarios a sua execucao sao trans-
feridos Todos os acessos posteriores serao feitos a estes recursos locais (recorda-se
que o Gears pode ser utilizado para os manter actualizados recorrendo ao Managed-
ResourceStore 311)
Atraves do JavaScript e possıvel interceptar os eventos de load e unload da
pagina que sao despoletados sempre que ocorre um re-acesso da mesma (incluindo
a accao refresh comum dos browsers) sempre que esta e abandonada ou ainda ou
ainda se a janela for encerrada
Tal como sugerido na seccao 462 a camada de interface desta aplicacao (cada
pagina individual em HTML) devera ser implementada como sendo um template
para apresentacao de dados sendo totalmente preenchida atraves de funcoes em
JavaScript O objectivo deste ponto e criar um padrao de dados que permita ao
JavaScript preencher os dados em cada pagina (template) independentemente de
qual seja a fonte ndash o servidor remoto ou a maquina local tal como exemplificado
no diagrama da Figura 412 Na figura a aplicacao recorre ao servidor remoto para
obter os dados pretendidos quando se encontra na presenca de uma ligacao mas
para dados que exijam uma carga de processamento pelo servidor este acto pode ser
49
Desenvolvimento
Figura 412 Esquema UML que expressa o acto de recolha de dados em modo online eoffline recorrendo ao servidor (modo online) e ao sistema de armazenamento de dadoslocal fornecido pelo Gears (modo offline)
substituıdo pelo envio de um campo de controlo que se destina a aferir se os dados
locais se encontram actualizados No caso de estarem actualizados a comunicacao
com o servidor pode ser substituıda por uma query a base de dados local
50
Capıtulo 5
Resultados e Futuros
Desenvolvimentos
Todo o estudo feito sobre o tema OWA foi ja abordado ao longo do documento
Neste capıtulo apresentam-se os resultados obtidos na implementacao da prova de
conceito que visava compreender a melhor forma de disponibilizar uma versao of-
fline no WOW uma plataforma de gestao de ordens de trabalho ja existente de-
senvolvida pela Critical Software SA
51 Resultados Obtidos
Os resultados obtidos neste projecto sao extremamente satisfatorios uma vez
que o estudo do tema OWA e a implementacao de uma prova de conceito que o
ilustrasse foi conseguido com sucesso
A funcionalidade offline foi adicionada ao produto WOW da Critical Software
SA permitindo a visualizacao de ordens de trabalho e dos seus detalhes mesmo na
ausencia de uma conexao activa a Internet Embora para a solucao implementada
tenha sido utilizada uma abordagem do tipo ldquoutilizador deciderdquo pretende-se que esta
seja convertida para ldquoaplicacao deciderdquo ou mesmo para uma aproximacao hıbrida
semelhante a utilizada pelas aplicacoes estudadas nas seccoes 351 e 352
Para a sua implementacao descrita no capıtulo 4 foram tomadas decisoes de or-
dem pratica que permitissem tornar o trabalho exequıvel nos prazos dados Tentou-
se sempre que estas decisoes afectassem o mınimo em termos de desempenho e de
experiencia para o utilizador Considera-se que a implementacao do modo offline
com uma transicao entre modos do tipo ldquoutilizador deciderdquo (ver seccao 42) reflecte
o compromisso entre o desempenho pretendido e os recursos disponıveis e para alem
51
Resultados e Futuros Desenvolvimentos
de ser um exemplo eficaz das possibilidades que as OWA podem trazer a aplicacao
WOW desenvolvida pela Critical Software e tambem um estudo que pode ser uti-
lizado para analisar a implementacao desta tecnologia noutros produtos da mesma
empresa
Note-se que o principal objectivo do trabalho era ganhar familiaridade com este
tema entender as suas vantagens e desvantagens e compreender as suas limitacoes
Tudo indica que existam varias possibilidades de implementacao deste paradigma
noutros produtos da Critical Software que pela sua natureza podem tambem tirar
partido da execucao offline
52 Trabalho Futuro
O desenvolvimento do conceito e formas de implementacao de OWA continua
em forte desenvolvimento no entanto a sua adopcao ainda nao e generalizada A
dificuldade da sua implementacao em web applications ja existentes e o principal
obstaculo a sua maior divulgacao
Ha tambem um factor que deve ser tido em consideracao a manutencao de
codigo A implementacao de uma versao offline de uma web application requer
a implementacao das mesmas regras de negocio (ou de uma versao simplificada)
utilizadas no servidor Para que isto seja possıvel e necessario ter em conta a
capacidade de processamento do cliente e o factor de duplicacao de codigo que
tornara a aplicacao mais difıcil de manter uma vez que uma alteracao a logica de
negocio do servidor implica tambem uma alteracao a sua versao offline
A prova de conceito implementada permite ja a visualizacao offline dos pedidos
abertos (enviados e recebidos) que constam na pagina principal (este numero e
fixo e pode ser alterado pelo administrador) Uma funcionalidade desejavel seria a
possibilidade de interaccao com a aplicacao em modo offline e sincronizacao com o
servidor quando existisse uma ligacao disponıvel
Foi estudada a utilizacao do modo de execucao ldquoaplicacao assume o estado of-
flinerdquo descrito em 423 e esta seria a forma desejavel para o WOW Offline no
entanto para que esta opcao seja viavel sera necessaria a implementacao de uma
forma eficiente de sincronizacao e armazenamento de dados de uma forma relacional
Para atingir este objectivo podera ser seguida uma polıtica de automacao do pro-
cesso no qual a versao online da aplicacao gera scripts de criacao para as tabelas
necessarias na base de dados da versao offline (nao existe nenhuma ferramenta para
o fazer portanto seria necessaria a sua implementacao) e no qual as paginas HTML
disponibilizadas pelo servidor aos clientes web (browser) servem como templates de
apresentacao de informacao e sao preenchidas de forma semelhante pelo servidor ndash
quando a aplicacao estiver online ndash ou pelo cliente atraves de funcoes em JavaScript
52
Resultados e Futuros Desenvolvimentos
ndash quando a aplicacao estiver offline No entanto no WOW devido a quantidade de
informacao tratada e devido as complexas relacoes entre as diferentes entidades e
de esperar que a complexidade da implementacao de um mecanismo deste tipo torne
esta aproximacao demasiado custosa
O HTML 5 embora um forte candidato ainda nao esta suficientemente desen-
volvido A sua especificacao ainda tem o caracter de Draft (rascunho) e esta sujeita
a modificacoes e a aceitacao e implementacao por parte dos browsers e portanto
de momento foi desconsiderado No entanto no futuro se esta especificacao atingir
um estado de maturidade que permita a sua adopcao devera ser considerada como
um possıvel caminho a seguir
53
Resultados e Futuros Desenvolvimentos
54
Capıtulo 6
Conclusoes
Neste capıtulo sao apresentadas as conclusoes do projecto e consideracoes finais
relativamente a tecnologia estudada
61 Conclusoes
O rapido desenvolvimento tecnologico faz prever que a disponibilidade de ligacao
a Internet seja cada vez mais facil e mais rapido mas vao continuar a existir lugares
onde o acesso e limitado e onde as OWA podem desempenhar um papel de relevo
Por outro lado esta tecnologia pode tambem ser utilizada para melhorar o desem-
penho de paginas web com uma necessidade elevada de imagens ou outros recursos
dispendiosos em termos de espaco e foram ate estudados dois exemplos da utilizacao
desta vertente desta tecnologia em 353
Acredita-se que as OWAs vem responder a uma necessidade real por parte das
web applications actuais e que a evolucao que representam se compara a que se
assistiu dos thin-clients para os fat-clients em termos de autonomia do servidor
A capacidade de oferecer conteudos dinamicos no browser independentemente da
existencia de uma ligacao reune as vantagens tıpicas das web applications como
ausencia de instalacao e actualizacoes instantaneas com as vantagens das aplicacoes
de desktop em capacidade de processamento e armazenamento de dados na maquina
local
As tecnologias disponıveis ate a data estudadas no ambito deste projecto que
permitem o desenvolvimento de OWAs e que apresentam maior maturidade sao o
Gears e o Adobe AIR Ambas se apresentam sobre a forma de plugins que necessitam
de uma instalacao extra para poderem ser utilizadas Apesar de esta instalacao ser
55
Conclusoes
apenas necessaria uma vez podera constituir um factor de desencorajamento a sua
adopcao
O HTML 5 uma especificacao abordada neste documento na seccao 34 podera
ser uma alternativa que oferece funcionalidades offline a uma web application sem a
necessidade de qualquer instalacao no entanto esta especificacao ainda nao foi aceite
pelos principais browsers ndash o documento que define o HTML 5 ainda tem o estatuto
de Draft ndash e ainda nao e possıvel antecipar quando e que isto podera acontecer
Um dos problemas que surge frequentemente na implementacao de uma versao
offline para uma web application e a necessidade de sincronizacao de dados Quando
a informacao pode ser alterada por varios utilizadores simultaneamente e necessario
prever os conflitos que daı podem surgir e dotar a aplicacao de uma forma de os
resolver ou alertar o utilizador para a necessidade de alteracao dos dados
Em conclusao todos os objectivos propostos para este projecto foram atingidos
A prova de conceito implementada reflecte de forma clara as possibilidades oferecidas
pela tecnologia OWA e sera utilizado no futuro para compreender a melhor forma
de o implementar de forma definitiva no WOW
56
Referencias
[Ada08] Lucas Adamski Introducing Adobe AIR security model Fevereiro de2008 Disponıvel em httpwwwadobecomdevnetairarticles
introduction_to_air_securityhtml acedido em Marco de 2008
[Ado08] Adobe Adobe AIR 10 Security White Paper 2008 Disponıvel emhttpdownloadmacromediacompubairdocumentation1air_
securitypdf acedido em Marco de 2008
[Alm08] Dion Almaer Gears as a bleeding-edge html 5 implementa-tion March 2008 Disponıvel em httpalmaercomblog
gears-as-a-bleeding-edge-html-5-implementation acedido emMarco de 2008
[BL96] Tim Berners-Lee The world wide web Past present and future Agostode 1996 Disponıvel em httpwwww3orgPeopleBerners-Lee
1996ppfhtml acedido em Abril de 2008
[CDGH08] Mike Chambers Daniel Dura Dragos Georgita and Kevin Hoyt AdobeAIR for JavaScript Developers OrsquoReilly Media 2008 Disponıvel emhttponairadobecomfilesAIRforJSDevPocketGuidepdf ace-dido em Abril de 2008
[Con99] Jim Conallen Modeling Web Application Architectures with UML Junho1999 Disponıvel em httpwwwumlorgcnUMLApplicationpdf
webappspdf acedido em Maio de 2008
[Ent07] Entrust What is a public key information 2007 Disponıvel em http
wwwentrustcompkihtm acedido em Junho de 2008
[Gar05] Jesse James Garret Ajax A new approach to web applicationsFebruary 2005 Disponıvel em httpwwwadaptivepathcomideas
essaysarchives000385php acedido em Marco de 2008
[Greon] Philip Greenspun Philip and Alexrsquos Guide to Web Publishing 2003(last revision) Disponıvel em httpphilipgreenspuncompandaacedido em Junho de 2008
[Gro02a] App Design Group Thick vs thin client comparison 2002 Disponıvelem httpwwwdonjacobsvwcomimagesweekendspecials
Thick-vs-Thinpdf acedido em Junho de 2008
57
REFERENCIAS
[Gro02b] Technical Research Group Thin Client Tecnhology - WhitePaper 2002 Disponıvel em httpwwwpicktrgcompubs
thinclientwhitepaperpdf acedido em Junho de 2008
[Gro08] Miniwatts Marketing Group World internet usage March 2008Disponıvel em httpwwwinternetworldstatscomstatshtm ace-dido em Abril de 2008
[Hic08] Ian Hickson HTML 5 Draft Recommendation 2008 Disponıvelem httpwwwwhatwgorgspecsweb-appscurrent-work ace-dido em Marco de 2008
[Kha] Olga Kharif Top 10 municipal wifi plans Disponıvel em http
imagesbusinessweekcomss0608muni_wifiindex_01htm ace-dido em Marco de 2008
[Lab07] Mozilla Labs Prism Outubro 2007 Disponıvel em httplabs
mozillacom200710prism acedido em Marco de 2008
[Loo06] Chris Loosley Rich Internet ApplicationsDesign MeasurementandManagement Challenges 2006 Disponıvel em httpwwwkeynote
comdocswhitepapersRichInternet_5pdf acedido em Maio de2008
[Mic08] Microsoft Introduction to Occasionally Connected Applications us-ing Sync Services for ADONET 2008 Disponıvel em httpmsdn
microsoftcomen-ussyncbb887608aspx acedido em Junho de2008
[Nao08] Erica Naone Offline web applications Abril 2008 Disponıvelem httpwwwtechnologyreviewcomread_articleaspxch=
specialsectionsampsc=emerging08ampid=20245 acedido emAbril de 2008
[NJN00] Jason Nieh Yang S Jae and Naomi Novik A comparison of thin-clientcomputing architectures 2000 Disponıvel em httpwwwnclcs
columbiaedupublicationscucs-022-00pdf acedido em Maio de2008
[OrsquoR06] Tim OrsquoReilly Web 20 compact definition Trying again Dezembro2006 Disponıvel em httpradaroreillycomarchives200612
web-20-compact-definition-tryihtml acedido em Marco de 2008
[OrsquoR09] Tim OrsquoReilly What is Web 20 Design patterns and business modelsfor the Next Generation of Software 20053009 Disponıvel emhttpwwworeillynetcompubaoreillytimnews200509
30what-is-web-20html acedido em Marco de 2008
[Rus06] Alex Russel Comet Low latency data for the browser March Marco2006 Disponıvel em httpalexdojotoolkitorgp=545 acedidoem Marco de 2008
58
REFERENCIAS
[Sad97] Darleen Sadoski Clientserver software architecturesndashan overviewAgosto 1997 Disponıvel em httpwwwseicmuedustr
descriptionsclientserver_bodyhtml acedido em Junho de2008
[Sch96] George Schussel Clientserver past present and future 1996
[Smi07] Kevin C Smith Css filters - will the browser apply the rule July 2007Disponıvel em httpcentriclecomrefcssfilters acedido emMarco de 2008
[vK08] Anne van Kesteren The XMLHttpRequest Object W3C Work-ing Draft 15 Abril 2008 Disponıvel em httpwwww3orgTR
XMLHttpRequest acedido em Abril de 2008
[Wil06] Greg Wilkins Why ajax comet July Julho 2006 Disponıvel emhttpwwwwebtidecomdownloadswhitePaperWhyAjaxhtml ace-dido em Abril de 2008
59
REFERENCIAS
60
Anexo A
Screenshots
Algumas imagens de aplicacoes que utilizam funcionalidades offline ilustrativasda tecnologia abordada neste documento
Figura A1 Dialogo apresentado ao utilizador na primeira activacao das funcionalidadesoffline no Google Docs amp Spreadsheets
61
Screenshots
Figura A2 Na activacao das funcionalidades offline e tambem oferecida a possibilidadeda criacao de alguns atalhos por exemplo no ambiente de trabalho
Figura A3 O Google Docs mantem a todo o momento a possibilidade de alteracao destasdefinicoes ou da anulacao dos servicos offline para um dado computador
62
Screenshots
Figura A4 Apos a instalacao do Gears qualquer visita ao Remember The Milk despoletauma sincronizacao que ocorre automaticamente e sem necessidade de intervencao por partedo utilizador
Figura A5 Apos completar a sincronizacao de dados mesmo que a ligacao a Internetseja perdida o Remember the Milk continua disponıvel no browser (com excepcao dasfuncionalidades que pela sua natureza exigem uma ligacao como por exemplo partilhade tarefas e envio de convites)
63
Resumo
Este projecto teve como objectivo o estudo das Offline Web Applications (OWAs)e da sua implementacao em web applications ja existentes Neste ambito foi feitauma avaliacao da aplicacao desta tecnologia no WOW uma plataforma integradade gestao de ordens de trabalho desenvolvida pela Critical Software SA ao longodos ultimos 6 anos e implementada uma prova de conceito que permite a utilizacaode um conjunto de funcionalidades base desta web application independentementedo estado da ligacao a Internet
O conceito das OWAs enquadra-se numa tecnologia de Internet que permiteo acesso a um website atraves do browser mesmo na ausencia de uma ligacao arede global e foi considerado pela revista Technology Review como uma das maisimportantes tecnologias emergentes no final de 2007 [Nao08] O estudo efectuado noWOW pretende ser um primeiro passo na compreensao dos problemas associados asua implementacao e respectivas solucoes e tambem da avaliacao dos benefıcios dautilizacao desta tecnologia para os utilizadores finais
A evolucao das tecnologias associadas a Internet a que se assiste continua-mente impulsionou tambem evolucao da forma como a informacao e produzidadistribuıda e armazenada Surgiram novas web applications oferecendo funcionali-dades de criacao e edicao de conteudos que trouxeram consigo a vantagem de tornarpossıvel o acesso a informacao a partir de qualquer lugar mas tambem a desvan-tagem de tornar a ligacao a Internet uma condicao necessaria para que isto acontecaA proliferacao destas aplicacoes a crescente utilizacao da Internet [Gro08] e a adesaoaos seus servicos indiciam a existencia de uma dependencia cada vez maior de umaligacao que nem sempre existe
As OWAs vem assim colmatar esta falha colocando no lado do cliente parte dainformacao que ate agora vinha a ser armazenada no servidor e tornando nao sopossıvel a sua consulta offline como tambem reduzindo a carga no servidor umavez que reduz as transferencias de informacao
Pretende-se neste documento apresentar diferentes formas de como a utilizacaoda tecnologia OWA pode beneficiar as web applications de hoje melhorando o seudesempenho e dando-lhes novas possibilidades de execucao aproximando-as do desk-top
i
ii
Abstract
The main purpose of this project was to study the Offline Web Applications(OWAs) and its implementation in existent web applications With this goal in minda study was conducted to use this technology in WOW an integrated platform forwork orders and work flow management developed by Critical Software over thelast 6 years and implemented a proof of concept which enables the use of a baseset of functionality for this application regardless of the internet connection state
The concept of OWAs is connected with internet technology and allows accessto a website using the browser even if a connection to the internet is not availableThis concept was considered by Technology Review as one of the most importantemerging technologies in the last quarter of 2007 [Nao08] This study conductedover the WOW platform is intended to aid in the comprehension of the problemsand solutions associated to the use and implementation of OWA as well as thebenefits that it brings to the end user
The Internet and Internet technologies are changing the way in which informa-tion is produced distributed and stored New web applications appeared with newcontent creation and edition functionalities and with it the advantage of infor-mation retrieval from any place and time became possible but with the conditionof Internet connection availability With Internet use growing every year [Gro08]content creation is starting to move to this new platform The adoption of web ap-plications for content creation and edition is becoming more popular and it showsa dependency of a connection that is not always present
The OWAs are a way to solve this problem putting on the client side part ofthe information that was traditionally stored on the server and allows it to be seenand manipulated and helps reducing the server load
This document intends to present different ways in which this technology canhelp web applications as we know them improving the their overall performance andgiving them the ability to run on a browser regardless of the Internet connectionavailability
iii
iv
Agradecimentos
A realizacao e os objectivos alcancados neste projecto nao teriam sido possıveissem a colaboracao de inumeras pessoas Agradeco profundamente a todos os quecontribuıram directa ou indirectamente para o seu sucesso
A minha orientadora Professora Teresa Galvao Dias e ao Project ManagerEngenheiro Marcus Neves que me conduziram e acompanharam no desenvolvimentodeste projecto
A toda a equipa do WOW em especial o Pedro Maurıcio Costa e o Fabio Matosque contribuıram para a minha a minha integracao na Critical Software e que sempresouberam responder a todas as minhas questoes
A todos os que constituem a CSW Porto pelo fantastico ambiente de amizadeque me proporcionaram
Aos colegas de curso e a todos os que me auxiliaram na revisao deste documento
Os meus sinceros agradecimentos
Joao Goncalves da Costa
v
vi
Conteudo
1 Introducao 111 Enquadramento 112 Motivacao 213 Ambito 314 Objectivos 315 Estrutura do documento 3
2 Enquadramento do Projecto 521 Evolucao das arquitecturas de software 5
211 Thin-clients 5212 Fat-clients 6213 Arquitecturas cliente-servidor 7
22 Evolucao na Internet 8221 Paginas web estaticas 9222 Paginas web interactivas e paginas web dinamicas 9223 Web 20 e Ajax 11
23 Offline Web Applications 1324 Comparacao 13
3 Estado da arte 1731 Gears 17
311 Arquitectura 17312 Goggle Gears em dispositivos moveis 20
32 Adobe AIR 20321 Seguranca 22322 Assinatura do codigo 22
33 Mozilla Prism 23331 XML User Interface Language 23332 Prism 25
34 HTML 5 2535 Web applications que usam funcionalidades offline 26
351 Google Reader e Google Docs 26352 Remember the Milk 27353 MySpace e WordPresscom 27
36 Escolha da tecnologia 28
vii
CONTEUDO
4 Desenvolvimento 3341 Como ficar offline 33
411 Funcionalidades disponıveis em modo offline 3442 Modos de execucao 35
421 Modo ldquoutilizador deciderdquo 36422 Modo aplicacao decide 36423 Modo ldquoaplicacao assume o estado offlinerdquo 37
43 Sincronizacao de dados 38431 Quando sincronizar 39
44 WOW 4045 Visao geral sobre a arquitectura do WOW 4146 WOW Offline 42
461 Modo ldquoaplicacao deciderdquo com deteccao automatica da ligacao 43462 Implementacao do modo ldquoutilizador deciderdquo 45463 Especificacao do modo ldquoaplicacao assume o estado offlinerdquo 48
5 Resultados e Futuros Desenvolvimentos 5151 Resultados Obtidos 5152 Trabalho Futuro 52
6 Conclusoes 5561 Conclusoes 55
Referencias 59
A Screenshots 61
viii
Lista de Figuras
21 Arquitectura de um sistema thin-client em duas camadas (a esquerda)e em tres camadas (a direita) Note-se a inclusao do servidor (main-frame) na definicao das camadas desta arquitectura devido a fortedependencia cliente-servidor 9
22 Arquitectura de um fat-client em duas camadas (a esquerda) e emtres camadas (a direita) 10
23 Comparacao do modelo de web aplications sıncrono paginas estaticase interactivas abordados nas seccoes 221 e 222 com o modelo deweb applications Ajax (assıncrono) abordado na seccao 223 Figuraadaptada de http www adaptivepath com 15
31 Esquema UML do processo efectuado pelos recursos do Gears do tipoManagedResourceStore para a actualizacao dos conteudos definidosno ficheiro manifesto 29
41 Exemplo de uma arquitectura de uma web application sem uma ca-mada de abstraccao de dados Figura adaptada de http gears
google com 33
42 Exemplo de uma arquitectura de uma web application com uma ca-mada de abstraccao de dados Figura adaptada de http gears
google com 34
43 Exemplo de uma arquitectura de uma web application com uma ca-mada de abstraccao de dados e um data switch Figura adaptada dehttp gears google com 35
44 Esquema grafico ilustrando uma OWA executando no browser uti-lizando um modo de execucao do tipo ldquoaplicacao deciderdquo com de-teccao automatica do estado da ligacao via pedidos Ajax assıncronosa cada cinco segundos 37
45 Detalhe de um conjunto possıvel de estados e respectivas transicoespara uma dada ordem de trabalho no WOW desde a sua submissaono sistema ate a sua conclusao em fecho ou cancelamento Esta figurarepresenta apenas um exemplo ja que o mapa de estados para umaordem de trabalho e dinamico e pode ser alterado por um admin-istrador Figura retirada de uma brochura promocional do WOWCritical Software SA 41
ix
LISTA DE FIGURAS
46 A pagina inicial do WOW apresenta um resumo das ultimas ordensde trabalho enviadas e recebidas Na imagem pode-se observar atransicao do estado online para offline 44
47 Ilustracao do funcionamento do Gears numa web application que uti-liza um motor Ajax Os pedidos HTTP ou HTTPS podem ser inter-ceptados e tratados localmente ou podem ser feitos a uma maquinaremota consoante se verificarem ou nao as condicoes expressas noponto 311 E representado um acesso a uma base de dados local(fornecida pelo Gears) mas a sua utilizacao e opcional 45
48 Neste exemplo do modo ldquoaplicacao deciderdquo o teste da ligacao e feitoe feito a cada cinco segundos O resultado deste teste nao reflectesempre o estado real da aplicacao podendo levar a aplicacao a tercomportamentos indesejaveis Na figura assinala-se um perıodo detempo no qual a representacao interna do estado da ligacao nao cor-responde a realidade 46
49 Pagina de visualizacao do detalhe de uma ordem de trabalho 47410 Esquema UML que expressa os casos de uso do WOW Offline no
modo ldquoutilizador deciderdquo 48411 Esquema UML que expressa os casos de uso do WOW Offline no
modo ldquoutilizador deciderdquo 49412 Esquema UML que expressa o acto de recolha de dados em modo
online e offline recorrendo ao servidor (modo online) e ao sistemade armazenamento de dados local fornecido pelo Gears (modo offline) 50
A1 Dialogo apresentado ao utilizador na primeira activacao das funcional-idades offline no Google Docs amp Spreadsheets 61
A2 Na activacao das funcionalidades offline e tambem oferecida a possi-bilidade da criacao de alguns atalhos por exemplo no ambiente detrabalho 62
A3 O Google Docs mantem a todo o momento a possibilidade de alteracaodestas definicoes ou da anulacao dos servicos offline para um dadocomputador 62
A4 Apos a instalacao do Gears qualquer visita ao Remember The Milkdespoleta uma sincronizacao que ocorre automaticamente e sem ne-cessidade de intervencao por parte do utilizador 63
A5 Apos completar a sincronizacao de dados mesmo que a ligacao aInternet seja perdida o Remember the Milk continua disponıvel nobrowser (com excepcao das funcionalidades que pela sua naturezaexigem uma ligacao como por exemplo partilha de tarefas e enviode convites) 63
x
Lista de Tabelas
21 Comparacao entre thin-clients e fat-clients 7
31 Comparacao das funcionalidades oferecidas pelo Adobe AIR para asplataformas web e desktop 30
32 Resumo da utilizacao de tecnologias OWA em algumas web applica-tions consideradas na analise do estado da arte 31
xi
LISTA DE TABELAS
xii
Glossario
fat-client Cliente que nao depende totalmente de umservidor central para as suas actividadesde processamento e possui frequentementedispositivos de armazenamento de dados
6ndash8
thin-client Cliente que depende de um servidor centralpara as suas actividades de processamento
5ndash8
web application Sistema web (servidor rede HTTPbrowser) onde accoes do utilizador(navegacao e introducao de informacao)afectam o estado logico da aplicacao
i iii1ndash311ndash1517ndash1921ndash232728 3336ndash3842 5556
API Application Programming Interface 10 1718 2326 28
ASP Linguagem interpretada pelo servidorque permite a criacao de paginas webdinamicas Desenvolvida pela Microsoft
11
BSD Berkeley Software Distribution 28
CSS Cascading Style Sheets 12 2021 2324 46
DHTML Dynamic HyperText Transfer Protocol 24DOM Document Object Model 10 12
20 2324
DTD Document Type Definition 24
xiii
Glossario
ECMAScript Padrao de linguagem de programacaodefinido pela Ecma International que orig-inou o JavaScript e o JScript
24
Flash Conteudo interactivo de um ficheiro emformato SWF E desenvolvido pela Adobee visualizado atraves do Adobe FlashPlayer
21
Flex Framework baseada em XML e Action-Script desenvolvida pela Adobe para a pro-gramacao de Rich Internet Applications(RIA)
21
GPL GNU General Public License 23
HTML HyperText Markup Language 1 10ndash12 2124ndash2649
HTTP HyperText Transfer Protocol 2 26
JMS E uma API em Java que permite a troca demensagens entre componentes de software
42
JSON JavaScript Object Notation permite atroca de dados codificados num formatode texto de simples leitura
12 1828 34
LGPL GNU Lesser General Public License 23
Mozilla Prism Browser simplificado e ldquointerpretadorrdquo deeXtensible User Interface Language (XUL)(tambem designado por XULRunner) queacolhe web applications sem a interfacegrafica habitual de um browser
25
MPL Mozilla Public License 23
OCA Occasionally Connected Application 39OWA Offline Web Application i iii
2ndash515 1725 2628 3133 3651 5255 56
PDF Portable Document Format 21
xiv
Glossario
PHP Linguagem interpretada pelo servidorque permite a criacao de paginas webdinamicas mas que pode tambem ser in-vocada a partir da linha de comandos
11
pagina web estatica Pagina web que devolve sempre a mesmaresposta a todos os pedidos para todos osutilizadores e em qualquer contexto
5 9
RIA Rich Internet Applications web appli-cations que apresentam funcionalidadessemelhantes as desktop applications masque mantem a informacao no lado do servi-dor
5 1520 28
RSS Really Simple Syndication 27
SLA Service Level Agreement 40SQLite Segundo a definicao oficial SQLite is a
software library that implements a self-contained serverless zero-configurationtransactional SQL database engine
17
SSB Site Specific Browser 25SSL Secure Sockets Layer 22SWF ShockWave Flash 21
URL Uniform Resource Locator 18
VPN Virtual Private Network 38
WOW Work Orders Web Plataforma de gestaode ordens de trabalho e do seu fluxo de-senvolvida pela Critical Software SA
i iii28 3340ndash434551ndash5356
WWW World Wide Web 11 1214
XBL eXtensible Binding Language 24XHTML eXtensible HyperText Markup Language 12XML eXtensible Markup Language 11 12
23 2428
XSLT eXtensible Stylesheet Language Transfor-mation
12
XUL eXtensible User Interface Language xiv23ndash25
xv
Glossario
xvi
Capıtulo 1
Introducao
Neste capıtulo enquadra-se o tema do projecto introduzindo alguns dos conceitos
nos quais se baseia Apresentam-se as motivacoes ambito objectivos e a estrutura
deste documento
11 Enquadramento
A Internet foi originalmente concebida para ser um espaco de partilha de in-
formacao onde pessoas (atraves de maquinas) pudessem comunicar Na sua origem
as paginas eram estaticas constituıdas por texto formatado em HyperText Markup
Language (HTML) e ligadas entre si [BL96] Hoje encontramos conteudos cada vez
mais complexos e dinamicos incluindo som vıdeo ou streams multimedia [Loo06] e
em 2005 foi introduzido por [OrsquoR09] o termo Web 20
De acordo com [Greon] um website pode pertencer a uma ou varias das seguintes
categorias
bull Documento ndash um website essencialmente estatico onde alteracoes a uma
parte do conteudo nao tem implicacoes no seu comportamento
bull Base de dados ndash um directorio de informacao organizada em categorias
bull Aplicacao ndash um website dinamico que utiliza uma linguagem executada ou
interpretada do lado do servidor e que processa as accoes ou informacao in-
troduzida pelo utilizador para fornecer um servico ou nova informacao
A ultima destas categorias constitui aquilo que e normalmente designado por
web application O conceito utilizado ao longo deste documento e o mesmo que
o introduzido por Jim Coallen em [Con99] que define web application como um
1
Introducao
sistema web (servidor rede HyperText Transfer Protocol (HTTP) browser) onde
accoes do utilizador (navegacao e introducao de informacao) afectam o estado logico
da aplicacao A sua definicao tenta estabelecer que uma web application e um
sistema de software com estado de negocio1 e que a sua interface de interaccao com
o utilizador e distribuıdo atraves de um sistema web
12 Motivacao
A quantidade de informacao que e produzida e armazenada com recurso a es-
tas web applications disponıveis online tais como e-mail blogues ou mesmo docu-
mentacao tornam por vezes a disponibilidade de ligacao uma condicao necessaria
a produtividade e como consequencia desta barreira muitos potenciais utilizadores
opoem-se a adopcao de produtos web em detrimento das tradicionais desktop appli-
cations
Assegurar o acesso a uma ligacao de Internet e hoje muito mais facil A Internet
movel e ja uma realidade e encontra-se amplamente divulgada mas continuam a
existir diversas situacoes nas quais os utilizadores estao privados de uma ligacao
a Internet tais como uma viagem de metro ou de aviao ou quando se encontram
deslocados do seu paıs de origem e nao possuem nenhum plano de subscricao
Uma OWA consiste numa web application que para alem de manter todas as
caracterısticas anteriores se mantem disponıvel mesmo na ausencia de uma ligacao
a Internet e surge como uma tentativa de estreitar as barreiras existentes entre a
web e o desktop Isto significa que devera existir um mecanismo capaz de assegurar
a manutencao do estado logico da aplicacao quando a ligacao com o servidor e
quebrada permitindo ao utilizador continuar a utilizar a aplicacao e que sera capaz
de informar o servidor do estado em que a aplicacao se encontra quando a ligacao for
reposta A principal vantagem que advem desta possibilidade e evidente eliminar
a necessidade da existencia de uma ligacao a Internet para que a aplicacao possa ser
utilizada
Por outro lado a vontade de integracao de funcionalidades tıpicas das desktop
applications nas web applications foi um dos principais factores que impulsionou o
desenvolvimento deste conceito uma vez que obrigou a uma reflexao ldquopara alem
do browserrdquo e a uma adaptacao das arquitecturas existentes que permitisse ou o
acesso a funcionalidades disponibilizadas pelo sistema operativo ou pelo menos a
funcionalidades semelhantes Pretende-se com esta aproximacao tornar possıveis
interaccoes entre o desktop e o browser tais como arrastar um ficheiro para um
formulario web de upload de conteudos melhor suporte para o historico do clipboard
ou ainda o acesso ao sistema de ficheiros local Atingir estes objectivos reflecte-se
1NT business state
2
Introducao
num novo paradigma que reune as vantagens das web applications tais como os
updates instantaneos ou o facto de nao ser necessaria nenhuma instalacao e das
desktop applications como por exemplo persistencia no armazenamento de dados
acesso a funcionalidades do sistema operativo ou integracao e interaccao com outras
aplicacoes sejam elas web applications ou desktop applications
13 Ambito
Este projecto foi realizado na Critical Software SA no ambito do Mestrado
Integrado em Engenharia Informatica e Computacao (MIEIC) da Faculdade de En-
genharia da Universidade do Porto (FEUP) entre os meses de Fevereiro e Julho de
2008
14 Objectivos
Sao objectivos deste projecto
1 Estudar e documentar o tema das OWAs acompanhando os ultimos desenvolvi-
mentos nesta materia
2 Analisar o estado da arte fazendo uma analise crıtica e objectiva sobre as
diversas metodologias existentes
3 Implementar uma prova de conceito que permita a execucao offline de uma
web application documentando todo o processo
4 Estudar a possibilidade de permitir interaccao com a aplicacao (insercoes e
alteracoes aos dados) em modo offline
Em resumo o objectivo deste projecto foi estudar documentar e implementar
uma prova de conceito relacionada com o tema Offline Web Applications (OWA)
Este tema embora nao seja totalmente novo ganhou destaque ao longo do ano de
2007 com o surgimento de diversas ferramentas que se destinam a aproximar web
applications das desktop applications
15 Estrutura do documento
Este documento esta organizado em diferentes seccoes apresentando o projecto
numa sequencia logica organizada da seguinte forma
No capıtulo 1 faz-se uma breve apresentacao do conceito OWAs e do contexto em
que surge Apresenta-se tambem a estrutura do documento e definem-se os
termos e acronimos utilizados
3
Introducao
No capıtulo 2 faz-se uma descricao da evolucao das tecnologias que antecedem as
OWAs e das vantagens e desvantagens de cada uma como forma de enquadra-
mento
No capıtulo 3 analisa-se o estado da arte nesta materia Introduzem-se diversas
tecnologias directamente relacionadas com o tema deste projecto exemplos de
aplicacoes que as usam e as razoes que fundamentam as escolhas de tecnologias
efectuadas
O capıtulo 4 contem o desenvolvimento do projecto Analisa-se a plataforma
WOW de gestao integrada de ordens de trabalho a tecnologia escolhida e
a forma como foi utilizada para implementar a capacidade de execucao offline
O capıtulo 5 descreve os resultado obtidos comparando-os com as expectativas
iniciais do projecto e apresenta desenvolvimentos futuros e possibilidades de
continuacaoaplicacao do conhecimento adquirido
No capıtulo 6 apresentam-se as conclusoes
4
Capıtulo 2
Enquadramento do Projecto
Neste capıtulo apresenta-se um breve resumo da evolucao das arquitecturas de
software cliente-servidor e a forma como estas se comparam a evolucao da Inter-
net procurando estabelecer uma analogia entre o percurso de ambas as tecnolo-
gias Compara-se o comportamento e arquitectura dos thin-clients as paginas web
estaticas a evolucao dos fat-clients as paginas interactivas Web 20 e Ajax e
defende-se que as OWA constituem um proximo passo logico e evolutivo aproxi-
mando a web do desktop Referem-se ainda os principais factores que justificam a
importancia das OWAs e a estreita relacao que tem com as Rich Internet Application
(RIA)s
21 Evolucao das arquitecturas de software
Os termos thin-client e fat-client sao utilizados quer para descrever arquitecturas
logicas (de software) quer para descrever arquitecturas fısicas (de hardware) Neste
capıtulo excepto quando seja dada indicacao em contrario estes termos referem-se
sempre a uma arquitectura logica
Adicionalmente quando se trata de arquitecturas cliente-servidor pode-se estu-
dar a arquitectura desenvolvida do sistema como um todo da arquitectura do servi-
dor ou da arquitectura do cliente Para evitar equıvocos em especial na seccao 213
especifica-se em cada caso qual o sistema estudado
211 Thin-clients
Um thin-client e um computador cliente ou software cliente que no contexto
de uma arquitectura cliente-servidor depende de um servidor central para as suas
5
Enquadramento do Projecto
actividades de processamento e proporciona um canal de entrada e saıda de in-
formacao entre o utilizador e o servidor remoto Este termo quando aplicado a
hardware refere-se habitualmente a um computador que se destina a ser utilizado
como cliente de rede sem armazenamento local e com capacidade de processamento
reduzida [Gro02b] mas o conceito que aqui se analisa refere-se a uma arquitectura
de software que remonta ao inıcio das aplicacoes cliente-servidor
No inıcio da historia da computacao terminais ligavam-se directamente a main-
frames responsaveis por todo o processamento Nesta arquitectura era necessario
desenvolver duas aplicacoes distintas uma aplicacao central no servidor (main-
frame) responsavel pela gestao de toda a informacao e por todas as operacoes de
comunicacao e uma aplicacao de visualizacao instalada no cliente (terminal) O
papel destes terminais era apenas disponibilizar ao utilizador um meio de comu-
nicacao (entrada e saıda) e apresentacao dos resultados do servidor Nao tinham
um papel activo no calculo nem na logica de negocio e frequentemente nao tinham
tambem nenhum mecanismo de armazenamento de dados
Como vantagens esta arquitectura apresenta uma reduzida necessidade de con-
figuracao e manutencao do lado do cliente Uma vez que o centro do processamento
e manipulacao de dados ocorre no servidor existe tambem uma centralizacao da
informacao [NJN00] que introduz um ponto crıtico de falha1 Actualizacoes e novas
funcionalidades sao faceis de distribuir uma vez que requerem apenas alteracoes no
servidor [Gro02a]
212 Fat-clients
Contrastando com os thin-clients nesta arquitectura os clientes implementam
ja uma parte da logica de negocio e sao responsaveis pelo processamento de dados
Estes fat-clients vieram responder a necessidade crescente de aplicacoes com um
nıvel de interactividade e capacidade de configuracao maior que as oferecidas pela
arquitectura thin-client descrita na seccao 211 Apesar de manterem a sua de-
pendencia do servidor podem tambem ser executados sem uma conexao activa uma
vez que dispoe de armazenamento de dados local o que lhes confere a capacidade
de persistencia de dados e do estado de execucao entre cada sessao
Foi disponibilizando este controlo sobre o estado da aplicacao bem como acesso
a recursos locais (por exemplo sistema de ficheiros e perifericos) que surgiram as
primeiras verdadeiras desktop applications No entanto cada cliente tinha que ser
separadamente instalado no computador pessoal de cada utilizador que pretendesse
utilizar ou interagir com a aplicacao e uma actualizacao ao servidor implicava in-
variavelmente uma actualizacao manual tambem no cliente Uma vez que nem todos
1NT single point of failure
6
Enquadramento do Projecto
Thin-clients Fat-clientsNao toma parte no processamento dedados nem possui acesso ao sistema deficheiros
Participa activamente no processa-mento de dados recorrendo ao sis-tema de armazenamento local para ar-mazenamento de dados
Nao mantem registo do estado logicoda aplicacao entre duas sessoes de uti-lizacao
O acesso ao armazenamento localpermite-lhe manter registo do estadologico da aplicacao entre duas sessoes
O thin-client nao necessita de qualquerinstalacao estando ldquopronto a utilizarrdquo
E geralmente necessario instalar aaplicacao para poder interagir com oservidor
Qualquer update no servidor reflecte-seimediatamente por todos os clientes
Embora a aplicacao cliente possa aler-tar para existencia de novas versoes asactualizacoes tem que ser manualmenteinstalados pelo cliente
O software do cliente destina-se apenasa apresentacao de dados e comunicacaocom o servidor sendo portanto de sim-ples implementacao
Como o software do cliente toma parteactiva no processamento de dadosa sua implementacao requer cuidadosadicionais
Grande mobilidade uma vez que todaa informacao e mantida no servidor
Parte da informacao podera estar ape-nas do lado cliente pelo que existemalgumas restricoes a sua mobilidade
Tabela 21 Comparacao entre thin-clients e fat-clients
os utilizadores actualizam regularmente as suas aplicacoes o servidor tem que estar
preparado para lidar com versoes antigas2 ou descontinuar os seus servicos a uma
parte da sua comunidade de utilizadores ate que estes actualizem os seus sistemas
Como os utilizadores passam a utilizar os seus recursos locais para armazenamento
de dados as alteracoes que nao sejam sincronizadas com o servidor estao apenas
disponıveis nos seus computadores pessoais o que introduz uma restricao a mobili-
dade
Pode-se afirmar que as vantagens dos thin-clients sao as desvantagens dos fat-
clients e que as vantagens dos fat-clients sao as vantagens dos thin-clients tal como
se ilustra na Tabela 21
213 Arquitecturas cliente-servidor
Introduzidos os termos thin-client e fat-client interessa reafirmar que ambos
podem ser vistos como arquitecturas cliente-servidor Um cliente define-se como
um solicitador de servicos e um servidor como um prestador de servicos tal como
definido por [Sch96] e [Sad97]
2NT backward compatibility
7
Enquadramento do Projecto
As arquitecturas cliente-servidor sao categorizadas pela modularizacao com que
sao desenhadas sendo consideradas as seguintes camadas
1 Interface grafica (front-end) atraves da qual os utilizadores interagem com
a aplicacao Quando este modulo e implementado separadamente dos outros
dois constitui uma aplicacao thin-client por si so uma vez que nao implementa
regras de negocio (embora possa definir validacoes de formularios de insercao de
dados por exemplo) A informacao introduzida pelo utilizador e enviada para
o servidor que processa o seu pedido e retorna uma resposta Este processo
repete-se ate que o utilizador atinja o seu objectivo ou se desligue do sistema
2 A logica de negocio tambem designada por camada intermedia que imple-
menta as regras de aceitacao e validacao de todos os dados introduzidos pelo
utilizador E tambem a plataforma de comunicacao que une a camada superior
de visualizacao com a camada de acesso a dados
3 A camada de dados inclui quer o sistema de persistencia de dados onde sao
armazenados os dados relevantes como tambem os mecanismos necessarios
para a sua pesquisa seleccao e alteracao
Os thin-clients quando observados no seu conjunto de cliente e servidor podem
ser vistos quer como sistemas de duas camadas quer como sistemas de tres camadas
dependendo apenas da forma como o servidor for implementado No caso de na
implementacao do servidor nao se distinguir a camada de acesso a dados da camada
da logica de negocio sao designados por sistemas de duas camadas Caso seja feita
esta distincao sao designados por sistemas de tres camadas Ambos os casos sao
ilustrados na Figura 21
Historicamente os fat-clients eram implementados numa arquitectura em duas
camadas Possuıam apenas um modulo de visualizacao de dados designado por
camada de interface e um modulo que implementava toda a logica de negocio e
regras de acesso a base de dados No entanto com a introducao de ligacoes mais
rapidas e de computadores pessoais com maior capacidade de processamento e so-
bretudo devido a complexidade crescente das aplicacoes a logica de negocio e a
camada de acesso a dados tornaram-se independentes Este modelo e designado por
arquitectura em tres camadas e e ilustrado na Figura 22
22 Evolucao na Internet
Ao analisar a evolucao das arquitecturas das aplicacoes desenvolvidas para a
Internet podemos encontrar um paralelismo com a historia da arquitectura de soft-
ware
8
Enquadramento do Projecto
Figura 21 Arquitectura de um sistema thin-client em duas camadas (a esquerda) e emtres camadas (a direita) Note-se a inclusao do servidor (mainframe) na definicao dascamadas desta arquitectura devido a forte dependencia cliente-servidor
221 Paginas web estaticas
Uma pagina web estatica devolve sempre a mesma resposta a todos os pedidos
para todos os utilizadores e em qualquer contexto utilizando o hipertexto como
forma de ligacao entre diversas paginas estaticas
A informacao e armazenada num servidor e o papel do cliente e apenas a apre-
sentacao da informacao Esta forma de disponibilizacao de informacao pode assim
ser comparada com os thin-clients descritos na seccao 211 o utilizador acede a
um website estatico para visualizar informacao sem que o cliente tome parte no
processamento A unica diferenca e que no caso da web estatica a informacao ap-
resentada e sempre a mesma enquanto que nos thin-clients era frequente existir a
possibilidade de insercao de dados no cliente e apos o seu processamento servidor
nova informacao poderia ser apresentada O hipertexto e utilizado para ligar as
paginas entre si numa rede de conteudos relacionados e a navegacao sıncrona era
feita atraves de cliques do rato a cada clique uma nova pagina era apresentada
Este modelo sıncrono e ilustrado na Figura 23
222 Paginas web interactivas e paginas web dinamicas
O JavaScript e uma linguagem interpretada de scripting que tem os browsers
como principal ambiente de acolhimento Os browsers utilizam uma Application
9
Enquadramento do Projecto
Figura 22 Arquitectura de um fat-client em duas camadas (a esquerda) e em tres camadas(a direita)
Programming Interface (API) publica para criar ldquoobjectosrdquo responsaveis por reflectir
e disponibilizar o Document Object Model (DOM) para o motor de JavaScript
A utilizacao mais frequente desta linguagem e a escrita de funcoes que sao em-
bebidas ou incluıdas em paginas web e que interagem com o DOM Uma vez que o
JavaScript e executado localmente (na maquina do cliente e nao no servidor) e capaz
de responder rapidamente a accoes do utilizador tornando a execucao de aplicacoes
no browser mais fluıdas o JavaScript pode tambem detectar accoes do utilizador
que o HTML nao pode tal como o pressionar de uma tecla
Em Dezembro de 1995 a Netscape Communications adicionou suporte para o
JavaScript no browser Netscape Navigator3 e em Agosto de 1996 o browser Internet
Explorer4 da Microsoft passou a tambem a suportar uma versao semelhante desta
linguagem (hoje todos os principais browsers suportam esta tecnologia)
Esta inovacao permitiu tornar os websites mais interactivos mas a sua utilizacao
esteve confinada apenas a este proposito durante um longo perıodo As paginas
passaram a responder activamente a accoes do utilizador (sendo uma das utilizacoes
3Netscape Communications ndash httpbrowsernetscapecom4Microsoft Internet Explorer ndash httpwwwmicrosoftcomwindowsproductswinfamilyie
10
Enquadramento do Projecto
mais vulgares a validacao de formularios) mas continuaram essencialmente estaticas
O JavaScript ainda nao era nesta altura utilizado para processar dados
Tambem nesta altura (1995ndash96) surgiram linguagens server-side como o PHP
Hypertext Preprocessor (PHP) e Active Server Pages (ASP) e o servidor passou a ter
um processamento de dados introduzidos pelo utilizador mais activo Generalizaram-
se as paginas dinamicas capazes de responder a insercao de dados ou outros pedidos
determinados por accoes do utilizador As paginas tornaram-se aplicacoes web ap-
plications
Uma definicao tradicional de web application e um conjunto de paginas web
logicamente agrupadas e geridas por uma unica entidade que tem como pontos de
entrada formularios de insercao de dados (web forms) Uma web application nao e
mais do que uma aplicacao que e acedida atraves de um browser Tem geralmente
uma arquitectura logica em tres (interface logica de negocio e camada de dados)
camadas e estao armazenadas num servidor
Ha dois tipos de web applications
bull Orientadas a apresentacao Sao web applications que geram paginas web in-
teractivas constituıdas por varios tipos de linguagens de anotacao (por exem-
plo HTML eXtensible Markup Language (XML)) e que apresentam conteudo
dinamico como resposta a pedidos efectuados pelo utilizador
bull Orientadas aos servicos Uma web application orientada aos servicos imple-
menta o ponto de acesso para um ou mais de um web service Sao geralmente
clientes de service oriented web applications
Uma vantagem significativa de implementar uma web application de forma a
suportar as funcionalidades padrao dos browsers e que estas terao o mesmo com-
portamento independentemente da plataforma e do browser a partir do qual serao
acedidas No entanto diferentes implementacoes de browsers devido a diferentes
interpretacoes dos padroes definidos tornam por vezes esta tarefa um pouco mais
complicada existindo inclusivamente na web guioes de compatibilidade para os difer-
entes browsers como [Smi07]
223 Web 20 e Ajax
O termo web 20 descreve uma tendencia de utilizacao e de design observada
na World Wide Web (WWW) com o objectivo de melhorar a criatividade partilha
de informacao e principalmente a colaboracao entre utilizadores Estes conceitos
levaram ao desenvolvimento e evolucao de comunidades online tais como redes so-
ciais wikis e blogues
11
Enquadramento do Projecto
O termo tornou-se mais conhecido apos a primeira conferencia OrsquoReilly Media
Web 20 em 2004 e apesar de sugerir uma nova versao da WWW nao se refere a
qualquer evolucao tecnologica mas apenas a alteracoes a forma como os utilizadores
se servem da web De acordo com Tim OrsquoReilly [OrsquoR06] ldquoWeb 20 e uma revolucao
na industria do software causada pela adopcao da web como uma plataforma e pela
tentativa de entendimento das regras para o sucesso nesta nova plataformardquo
O desenvolvimento da Web 20 serve-se muitas vezes de um outro conceito Ajax
O conceito que hoje conhecemos como Ajax muitas vezes incorrectamente de-
scrito como uma tecnologia foi originalmente criado para permitir o desenvolvimento
de web applications que se assemelhassem ainda mais a aplicacoes de desktop Este
conceito foi melhor descrito por [Gar05] como um conjunto de varias tecnologias
que podem ser utilizadas para melhorar a experiencia do utilizador de uma dada
web application introduzindo a capacidade assıncrona de envio de pedidos ou da
recepcao assıncrona de respostas As tecnologias mais frequentemente envolvidas
sao
bull eXtensible HyperText Markup Language (XHTML) e Cascading Style Sheets
(CSS) padrao para a apresentacao
bull interaccao dinamica atraves do DOM
bull troca e manipulacao de dados utilizando XML e eXtensible Stylesheet Lan-
guage Transformation (XSLT) ou JavaScript Object Notation (JSON)
bull pedidos assıncronos utilizando XMLHttpRequest [vK08]
bull JavaScript utilizado para integrar todas estas tecnologias
E importante frisar que o Ajax nao e um produto nem uma tecnologia E um
termo que descreve a utilizacao de um conjunto de tecnologias para o desenvolvi-
mento de web applications com um elevado grau de interactividade Comparativa-
mente as web applications tradicionais o Ajax introduz uma camada de visualizacao
diferente em tres importantes pontos
1 Do lado do cliente existe um motor que serve de intermediario entre a interface
da aplicacao e o servidor
2 A actividade do utilizador despoleta chamadas JavaScript em vez de um pedido
de pagina directamente ao servidor
3 Informacao codificada em XML em vez de paginas HTML e trocada entre o
servidor e o cliente
12
Enquadramento do Projecto
Isto significa que as paginas que utilizam Ajax contem um motor do lado do
cliente composto por um conjunto de funcoes JavaScript responsavel pela comu-
nicacao com o servidor e por actualizar a interface com o resultado dessa mesma
comunicacao
Na Figura 23 ilustra-se a natureza assıncrona do Ajax quando comparada com
as web applications tradicionais Como se pode observar adicionando um mecan-
ismo Ajax a uma web application eliminam-se diversos tempos de espera associados
a comunicacoes com o servidor uma vez que a interface nao fica ldquobloqueadardquo a es-
pera da resposta Obtem-se assim aplicacoes com um comportamento mais fluido
eliminando tempos de espera entre cada ldquocliquerdquo e melhorando a experiencia do
utilizador
23 Offline Web Applications
A informacao grafica (bem como folhas de estilo e scripts) tais como as ima-
gens que constituem o visual de uma web application e ja tratada de forma especial
pelos cada vez mais avancados sistemas de cache (armazenamento temporario) dos
browsers Mas estes nao sao ainda capazes de guardar conteudo criado pelo uti-
lizador nem de apresentar informacao independentemente do estado da ligacao
Numa altura onde se fala de servicos de Internet wireless municipalizados [Kha]
comunicacoes 3G e ligacoes de banda larga a alta velocidade a ligacao a rede global
continua a nao estar permanentemente disponıvel para os utilizadores Na WWW
encontra-se uma importante parte da informacao e das aplicacoes utilizadas para
criar e editar conteudos Por vezes informacao vital para a produtividade pode
desaparecer subitamente do mapa de acesso de um utilizador quando este entra no
metro num aviao ou mesmo quando se desloca para uma cidade ou paıs diferente
do habitual onde nao subscreve um plano de acesso que lhe garanta a ligacao
Permitir o acesso offline a estes recursos assume assim a sua importancia porque
permitira estender o alcance da informacao a locais onde nunca esteve antes e per-
mitira tambem melhorar o desempenho das web applications colocando informacao
mais perto dos utilizadores reduzindo a transferencia de dados apenas ao essencial
24 Comparacao
Nas evolucoes descritas neste capıtulo 2 pode-se observar que existe um par-
alelismo entre a evolucao das arquitecturas tradicionais cliente-servidor e a evolucao
a que se assiste na web O comportamento e arquitectura dos thin-clients assemelha-
se ao das paginas estaticas no sentido em que o browser nao toma parte em qualquer
13
Enquadramento do Projecto
processamento e serve apenas como uma plataforma de interaccao com o servidor
tal como os clientes descritos na seccao 211
A sua proxima evolucao os fat-clients trouxeram parte da capacidade de pro-
cessamento para o lado do cliente Na web foi tambem esta a inovacao tecnologica
a que se assistiu com a evolucao das tecnologias que permitiram a criacao de ver-
dadeiras aplicacoes e com a introducao do Javascript no browser dando ao cliente
a capacidade de processamento de dados A necessidade da separacao do codigo
em camadas logicas advem da crescente complexidade das web applications Esta
pratica permite entre outras coisas melhorar o processo de desenvolvimento e a
capacidade de manutencao de uma aplicacao
Os fat-clients tem tambem a capacidade de armazenamento de dados o que
permite a persistencia de informacoes entre duas sessoes e que algumas operacoes
sejam executadas sem a necessidade de comunicacao com o servidor Este facto pode
tambem ser uma realidade nas web applications com a adopcao das tecnologias OWA
Neste momento assiste-se a uma utilizacao cada vez maior da web como uma
plataforma de desenvolvimento A capacidade de cooperacao na edicao de conteudos
e a mobilidade proporcionada por esta plataforma sao os principais factores que
alimentam esta mudanca e pela primeira vez as aplicacoes tradicionais tem com-
peticao vinda de web applications A prova do reconhecimento da web como plataforma
de desenvolvimento pode ser retirada da aposta de empresas como a Adobe e Mi-
crosoft que lancaram publicamente ferramentas web complementares a produtos
seus tradicionalmente associados ao desktop ndash Acrobatcom5 e Microsoft Office
Live6 Dotar estas web applications da capacidade de execucao offline significa
aproximar a web e o desktop reunindo ldquoo melhor de dois mundosrdquo
As vantagens da mobilidade possıvel atraves da web a cooperacao na criacao e
edicao de conteudos e a possibilidade de utilizar aplicacoes sempre actualizadas e
sem necessidade de instalacao sao algumas das principais vantagens que promovem
esta mudanca que devido as preocupacoes associadas a usabilidade e experiencia do
utilizador esta fortemente associada ao desenvolvimento de Rich Internet Applica-
tion (RIA)s
5Adobe Acrobatcom httpwwwacrobatcom6Microsoft ndash httpsmallbusinessofficelivecom
14
Enquadramento do Projecto
Figura 23 Comparacao do modelo de web aplications sıncrono paginas estaticas e in-teractivas abordados nas seccoes 221 e 222 com o modelo de web applications Ajax(assıncrono) abordado na seccao 223 Figura adaptada de http www adaptivepath
com
15
Enquadramento do Projecto
16
Capıtulo 3
Estado da arte
Apesar de o conceito das OWAs nao ser absolutamente novo as tecnologias que
o suportam sao recentes Neste capıtulo descrevem-se quatro tecnologias que foram
tidas como principais candidatas para o desenvolvimento deste projecto Descrevem-
se ainda alguns exemplos de web applications que disponibilizam actualmente fun-
cionalidades offline e o processo da escolha da tecnologia a utilizar neste projecto
31 Gears
O Gears1 e uma extensao as funcionalidades do browser introduzido pelo Google
que tem como principal objectivo tornar possıvel a visualizacao de paginas de Inter-
net mesmo sem uma conexao disponıvel Encontra-se disponıvel para as platafor-
mas Windows Macintosh e Linux e oferece uma API de Javascript que permite
a scripts aceder a um mecanismo de armazenamento local baseado numa base de
dados SQLite
311 Arquitectura
Esta ferramenta e constituıda por tres componentes principais
bull LocalServer mdash Intercepta pedidos de paginas web e serve-as localmente
bull Database mdash Uma base de dados relacional construıda sobre SQLite
bull WorkerPool mdash Permite executar operacoes de computacao de uma forma
assıncrona sem afectar a capacidade de resposta e fluidez de execucao da web
application Assemelham-se a processos
1Google Inc ndash Mais informacao em httpgearsgooglecom
17
Estado da arte
LocalServer
O modulo LocalServer e uma cache de Uniform Resource Locators (URLs)
controlada pela web application Quando nao existe uma ligacao a Internet e e
feito um pedido para um URL presente nesta cache o LocalServer intercepta-o e
responde ao pedido localmente a partir do disco rıgido do utilizador A aplicacao
pode utilizar dois tipos diferentes de armazenamento local de URLs
bull ResourceStore ndash serve para capturar URLs utilizando exclusivamente a API
de Javascript disponibilizada para o efeito Uma aplicacao podera criar e
utilizar diversos ResourceStores simultaneamente para capturar ficheiros de
dados que necessitam de ser enderecados por um URL tal como um ficheiro
PDF ou uma imagem
bull ManagedResourceStore ndash serve para capturar um conjunto de URLs que estao
relacionados e que sao declarado num ficheiro de manifesto (especificado em
JSON) e que sao automaticamente actualizados O ManagedResourceStore
permite que o conjunto de recursos necessarios para correr uma web application
seja capturado e mantido actualizado automaticamente
A principal diferenca entre estes dois tipos de armazenamento de URLs e a forma
como sao actualizados os seus conteudos Os conteudos de um ManagedResourceStore
sao actualizados sempre que a versao contida no ficheiro de manifesto for alterada
enquanto que os conteudos de um ResourceStore nunca sao actualizados automati-
camente mas apenas quando for explicitamente ordenado pela aplicacao
O LocalServer e capaz de interceptar e servir localmente pedidos de HTTP e
HTTPS sempre que se reunam as seguintes condicoes
1 O URL encontra-se armazenado num ResourceStore ou ManagedResourceStore
2 O sistema de armazenamento local encontra-se activo (enabled = true) Se
o sistema de armazenamento local tiver o atributo requiredCookie o pedido
devera conter um cookie que lhe corresponda
O LocalServer nao necessita de monitorizar o estado da ligacao para atender aos
pedidos Na verdade sempre que as condicoes previamente enunciadas se verificarem
o LocalServer interceptara os pedidos e independentemente do estado da ligacao
a Internet servi-los-a a partir do disco rıgido local Cabera a aplicacao definir qual
o modo em que pretende executar um pedido (online ou offline) definindo o valor
de verdade da propriedade enabled
18
Estado da arte
Database
O modulo Database permite guardar dados da web application assegurando a
sua persistencia Os dados sao guardados de forma relacional no disco rıgido do uti-
lizador2 de acordo com o modelo de seguranca estabelecido pelo Gears3 significando
que uma aplicacao nao pode aceder a conteudos fora do seu domınio
WorkerPool
Nos web browsers uma operacao pesada de computacao pode tornar a interface
lenta e tornar menos agradavel a experiencia do utilizador O modulo WorkerPool
permite correr operacoes em background sem bloquear a interface com o utilizador
Os scripts executados numa WorkerPool nao activam os mecanismos de seguranca
do browser que mostram a mensagem ldquoA script on this page may be busy or may
have stopped respondingrdquo
O WorkerPool comporta-se como um conjunto de processos em vez de threads
Os Workers nao partilham qualquer estado de execucao o que significa que uma
alteracao a uma variavel num Worker nao afecta em nada a execucao de outro
Worker Alem disso os Workers nao herdam automaticamente nenhum codigo dos
seus pais Cada Worker e membro de um WorkerPool e os Workers podem in-
teragir entre si enviando mensagens em formato de texto ou JSON No entanto ha
tambem algumas limitacoes os Workers nao tem acesso ao DOM e objectos como
window ou document nao se encontram acessıveis Isto e consequencia de os Workers
nao partilharem o estado de execucao Mas tem acesso a todas as funcoes built-in
do Javascript A maioria das funcionalidades do Gears pode tambem ser acedida
atraves de uma variavel global especial definida como googlegearsfactory Para
outras funcionalidades especıficas os Workers podem ldquopedirrdquo a pagina principal para
continuar a execucao atraves do envio de mensagens
Outras funcionalidades
bull HttpRequest ndash Este modulo implementa a especificacao W3C XmlHttpRe-
quest definida em [vK08] tornando-a disponıvel para os workers e para a
pagina principal
bull Timer ndash Este modulo implementa a especificacao de timers tal como descrito
por [Hic08] e torna-os disponıveis para os workers e para a pagina principal
2Consultar httpcodegooglecomapisgearsapi_databasehtmldirectories3Consultar httpcodegooglecomapisgearssecurityhtml
19
Estado da arte
bull Factory ndash Esta classe e utilizada para instanciar todos os outros objectos da
API do Gears atraves do seu metodo create Este metodo pode ser utilizado
com os seguintes parametros
ndash betadatabase
ndash betahttprequest
ndash betalocalserver
ndash betatimer
ndash betaworkerpool
312 Goggle Gears em dispositivos moveis
O Gears esta tambem disponıvel em dispositivos Windows Mobile 5 e 6
Os dispositivos moveis estao pela sua natureza frequentemente desconectados
da Internet Mesmo quando possuem uma ligacao as latencias na transferencia de
dados em redes moveis tornam as aplicacoes pouco fluıdas mas o Gears permite
ultrapassar este obstaculo
O Gears funciona exactamente da mesma forma em dispositivos moveis equipados
com o Windows Mobile 5 e 6 como num computador comum Se uma aplicacao tiver
sido implementado com suporte para o Gears entao tambem estara preparada para
ser executada num dispositivo movel mas as limitacoes dos browsers disponıveis
para dispositivos moveis tem que ser consideradas Isto significa prever as condicoes
que permitam uma boa usabilidade devido aos pequenos ecras destes dispositivos
bem como o seu suporte limitado dos padroes do DOM CSS e JavaScript
32 Adobe AIR
O Adobe AIR4 e um runtime compatıvel com diversos browsers e sistemas opera-
tivos que pretende dar aos programadores a possibilidade de combinar diversas tec-
nologias de producao de conteudos para a Internet no desenvolvimento de Rich Inter-
net Application (RIA)s O Adobe AIR mantem uma relacao com o browser mas es-
tende as suas capacidades e tecnologias permitindo o desenvolvimento de aplicacoes
tambem para o ambiente de trabalho com janelas em tudo semelhantes as do sis-
tema operativo Segundo a Adobe o objectivo e complementar o browser dando
aos utilizadores (mas essencialmente aos programadores e equipas de desenvolvi-
mento) a escolha sobre como distribuir as suas aplicacoes Para este efeito o Adobe
AIR tem uma aproximacao diferente do Gears Em vez de ldquoestenderrdquo o browser
acrescentando-lhe funcionalidades o AIR permite tambem o desenvolvimento de
4Adobe - httpwwwadobecomproductsair
20
Estado da arte
aplicacoes que se destinam a ser executadas fora do ambiente do browser mas uti-
lizando as tecnologias comuns da Internet (por exemplo HTML CSS JavaScript
Flash Flex)[CDGH08]
A utilizacao desta tecnologia permite utilizar o browser ou o proprio runtime
Adobe AIR como plataforma de execucao da aplicacao
Na Tabela 31 faz-se uma comparacao das funcionalidades disponıveis de acordo
consoante se escolha o browser ou o desktop como plataforma base para a aplicacao
Uma vez que as aplicacoes Adobe AIR na plataforma desktop tem um caracter
persistente (sao instaladas no computador do utilizador) o Adobe AIR tem um
modelo de seguranca que se assemelha com o das tradicionais aplicacoes desktop
[Ada08] Este modelo e analisado nas seccoes 321 e 322 O ambiente em que
e executado o browser e restringido a execucao de web applications que podem
ser de varias origens (incluindo de origens anonimas ou sem confianca) O Adobe
AIR proporciona acesso a capacidades como acesso a ficheiros que necessitam da
confianca do utilizador
bull HTML ndash O desenvolvimento de aplicacoes para o Adobe AIR pode ser feito
com recurso a tecnologias de HTML e Ajax comuns utilizando as linguagens
de markup existentes distribuıdas como texto e interpretadas em execucao
(runtime)
bull Flash ndash Outra alternativa sera a utilizacao da linguagem Flash Permite a
renderizacao de graficos vectoriais e audiovıdeo com suporte nativo Utiliza
ActionScript para adicionar maior interactividade com o utilizador
bull Flex ndash O Flex e uma framework open source para o desenvolvimento de RIAs
usando Flash As aplicacoes Flex sao na realidade Flash sendo a principal
diferenca o ambiente de desenvolvimento
Como resultado uma aplicacao AIR podera ser implementada
bull Baseada em Flash ou Flex (aplicacoes cujo conteudo base e em ShockWave
Flash (SWF))
bull Baseada em Flash ou Flex tambem com HTML ou Portable Document Format
(PDF) Aplicacoes cujo conteudo de base e em FlashFlex (SWF) com HTML
(HTML JavaScript CSS) ou conteudo PDF incluıdo
bull Baseada em HTML Aplicacoes cujo conteudo base e em HTML Javascript
CSS
bull Baseada em HTML utilizando tambem FlashFlex ou PDF
21
Estado da arte
Os utilizadores interagem com uma aplicacao AIR da mesma forma que interagem
com outras aplicacoes com janelas nativas do seu sistema operativo O runtime e
instalado uma vez no computador do utilizador e a partir desse momento todas as
aplicacoes AIR terao o mesmo aspecto que qualquer outra aplicacao para o desktop
321 Seguranca
Permitir que uma web application aceda ao disco de armazenamento do utilizador
pode comprometer seriamente a sua seguranca Neste sentido o Adobe AIR tem
suporte para assinaturas digitais (Secure Sockets Layer (SSL)) que podem ser com-
pradas pelas equipas de desenvolvimento que o desejem e cujos certificados serao
apresentados ao utilizador no momento da instalacao Um outro aspecto ainda
relativo a seguranca e o mecanismo de isolamento de cada ambiente (sandbox )
322 Assinatura do codigo
O runtime AIR exige que todas as aplicacoes estejam digitalmente assinadas As
assinaturas digitais de codigo sao um processo que visa garantir a integridade da
aplicacao e a identidade do seu autor no momento da instalacao As equipas de
desenvolvimento podem ldquoassinarrdquo uma aplicacao utilizando um certificado atribuıdo
por uma Entidade Certificadora (Certification Authority) ou atraves de um certifi-
cado individual (self signed certificate) Neste momento o Adobe AIR suporta como
entidades certificadoras a Verisign e a Thawte [Ado08]
O instalador apresenta o nome de quem publica a aplicacao quando o codigo tiver
sido assinado com um certificado que apresente confianca ou que esteja encadeado
com um certificado que tenha ja sido aceite no computador em que se esta a instalar
a aplicacao
As equipas de desenvolvimento podem tambem assinar as aplicacoes com um
certificado auto-atribuıdo (um certificado criado por elas proprias) mas neste caso
o instalador apresentara estas aplicacoes como sendo de uma origem nao verificada
O AIR utiliza a infraestrutura publica de chaves [Ent07] suportada pelo arquivo
local do sistema operativo Para que a origem da aplicacao seja reconhecida o
computador onde a aplicacao AIR esta a ser instalada tem que confiar directamente
no certificado que foi utilizado para assinar a aplicacao ou confiar num certificado
que esteja num encadeamento logico de certificados confiados e que se ligue desta
forma ao certificado utilizado para assinar a aplicacao
Todas as aplicacoes AIR tem caracterısticas em comum independentemente da
tecnologia utilizada para o seu desenvolvimento (HTMLFlexFlash) No ambito
de uma aplicacao AIR existem um conjunto de APIs que estao disponıveis e que
tornam possıvel o acesso ao sistema local (leitura e escrita) e a recursos de rede que
22
Estado da arte
de outra forma nunca estariam acessıveis a partir de uma web application comum
Cada aplicacao AIR possui tambem diferentes nıveis de isolamento chamados secu-
rity sandboxes dependendo do tipo de conteudo que esta a ser carregado e do seu
objectivo
bull Isolamento ao nıvel da aplicacao5 ndash E a raiz de cada aplicacao AIR Este
nıvel de isolamento permite o acesso a APIs privilegiadas e especıficas do
AIR Em contrapartida e negado o acesso a algumas APIs que poderiam ser
facilmente utilizadas de forma maliciosa contra o utilizador final Importacao
dinamica de conteudos remotos e geralmente proibido e as tecnicas e mecan-
ismos de geracao dinamica de codigo sao fortemente restringidas Apenas
conteudo carregado directamente da directoria base da aplicacao podera ser
colocado neste nıvel de isolamento
bull Isolamento nao especıfico da aplicacao6 ndash contem todo o outro conteudo
que nao tenha sido carregado directamente para o isolamento da aplicacao
Isto inclui conteudo local e remoto Este tipo de conteudo nao tem acesso
directo as APIs do AIR e rege-se pelas mesmas regras tal como se tivesse sido
carregado por um browser a partir da mesma localizacao (por exemplo HTML
carregado a partir de um domınio remoto comporta-se da mesma forma que se
fosse acedido a partir do browser)
33 Mozilla Prism
331 XML User Interface Language
O eXtensible User Interface Language (XUL) e uma linguagem de anotacao
baseada em XML desenvolvida pela Mozilla Foundation que opera em aplicacoes
Mozilla multi plataforma tal como o Firefox O motor Gecko e a unica imple-
mentacao completa desta linguagem que foi desenhada sobre padroes web comuns
como CSS JavaScript e o DOM e permite o desenvolvimento de interfaces graficas
utilizando elementos pre-definidos tais como window box page textbox radio
button entre outros Infelizmente o XUL nao possui qualquer especificacao formal
ou implementacoes de inter-operabilidade para outros motores que nao o Gecko No
entanto a sua implementacao e licenciada em codigo aberto pelas licencas GNU Gen-
eral Public License (GPL) GNU Lesser General Public License (LGPL) e Mozilla
Public License (MPL)
Enunciam-se algumas caracterısticas desta linguagem
5NT application sandbox6NT non-application sandbox
23
Estado da arte
Liguagem de anotacao poderosa baseada em componentes (widgets) O ob-
jectivo do XUL e permitir a construcao de aplicacoes multi-plataforma em
claro contraste com o Dynamic HyperText Transfer Protocol (DHTML) que se
destina ao desenvolvimento de paginas web Por esta razao o XUL esta orien-
tado a componentes tais como janelas botoes e etiquetas em vez de paginas
cabecalhos de texto e ligacoes de hipertexto Investir tempo e esforco para
atingir este mesmo resultado em aplicacoes baseadas em DHTML compromete
frequentemente a complexidade e desempenho da aplicacao
Baseado em padroes O XUL e um dialecto XML baseado no padrao W3C XML
10 As aplicacoes escritas em XUL sao tambem baseadas em especificacoes
W3C adicionais como HTML 40 CSS DOM nıvel 1 e 2 JavaScript 15
incluindo ECMA-262 Edition 3 (ECMAscript)
Portabilidade entre plataformas Tal como HTML o XUL foi desenhado para
ser independente da plataforma em que e utilizado tornando as aplicacoes
facilmente portaveis entre sistemas operativos nos quais o Mozilla e suportado
Uma vez que o XUL oferece um nıvel de abstraccao dos componentes graficos
de interface que disponibiliza implementa a premissa ldquoum codigo para todas
as plataformasrdquo A interface grafica de todos os produtos centrais Mozilla
(browser instant messenger livro de enderecos) e escrita em XUL com um
unico codigo base que suporta todas as plataformas Mozilla
Separacao entre o nıvel de apresentacao e a logica de negocio Uma das
maiores preocupacoes no desenvolvimento para a Internet e a forte ligacao
entre estas duas camadas (interface e logica) Isto constitui um problema sig-
nificativo no desenvolvimento de grandes aplicacoes especialmente quando o
desenvolvimento e feito em ambientes de equipa porque as capacidades de de-
senvolvimento destas duas partes da aplicacao estao muitas vezes espalhadas
por diferentes elementos O XUL permite uma clara distincao entre a definicao
da aplicacao cliente e da logica de implementacao (XUL eXtensible Binding
Language (XBL) e JavaScript) apresentacao (CSS e imagens) internacional-
izacao (Document Type Definitions (DTDs) e etiquetas de texto em lınguas
especıficas guardados em ficheiros properties) O esquema grafico e apre-
sentacao de uma aplicacao XUL pode ser alterado de forma independente da
sua logica ou implementacao e a aplicacao pode ainda ser traduzida (interna-
tionalization) de forma independente da sua logica implementacao ou apre-
sentacao Este grau de separacao resulta em aplicacoes que sao mais faceis de
manter pelos programadores e facilmente adaptadas por designers e tradutores
24
Estado da arte
Facil adaptacao Outro benefıcio que advem do nıvel de separacao entre logica
de negocio e apresentacao oferecido pelo XUL e a facilidade com que se pode
adaptar uma aplicacao para diferentes clientes ou grupos de utilizadores Um
programador pode utilizar a mesma aplicacao base e adapta-la consoante as
necessidades atraves de diferentes temas (skins) e ficheiros de lınguas Desta
forma uma aplicacao escrita e desenvolvida em Ingles pode ser rapidamente
traduzida para Portugues e distribuıda com outra aparencia mais apropriada
ao cliente alvo
332 Prism
O Mozilla Prism e um browser simplificado e ldquointerpretadorrdquo de XUL (tambem
designado por XULRunner) que acolhe web applications sem a interface grafica ha-
bitual de um browser Baseia-se num conceito designado por Site Specific Browser
(SSB) Um SSB e uma aplicacao com um browser embebido desenhado para exe-
cutar apenas uma web application Nao possui os menus e barras de ferramentas
habituais Um SSB tem uma integracao com o sistema operativo e com o desktop
muito mais estreita do que uma web application acedida atraves de um browser uma
vez que e executado em janela propria
O Prism resulta de uma experiencia da Mozilla e visa reduzir as diferencas entre
as desktop applications tradicionais e as web applications Um dos aspectos focados e
a experiencia do utilizador Numa apresentacao oficial e dito que ldquo[o Prism] pretende
ser uma ponte entre as diferencas que existem entre as aplicacoes tradicionais de
desktop e as web applications explorando novos modelos de usabilidade enquanto
que a linha que as separa se continua a definirrdquo [Lab07]
34 HTML 5
A especificacao HTML 5 [Hic08] que se encontra em fase de desenvolvimento
pelo grupo WHATWG pretende ser uma norma de substituicao dos padroes HTML
4 XHTML 1x e do DOM2 HTML Uma das propriedades que o distingue das tec-
nologias que pretende substituir e precisamente o suporte para OWA e armazena-
mento de dados no cliente de uma forma relacional Nao sendo propriamente uma
tecnologia ndashmas antes uma especificacao ndashe aqui mencionada por ter servido como
referencia a diversas implementacoes de funcionalidades offline e por se considerar
que venha a ter um impacto significativo nas implementacoes de diversos browsers
Dion Almaer defendeu no seu blogue que o Gears era uma implementacao do
HTML 5 No seu artigo ldquoGears as a bleeding-edge HTML 5 implementationrdquo [Alm08]
o autor diz que ambos ndasho Gears e o HTML 5 ndashpretendem dar a web caracterısticas
25
Estado da arte
semelhantes e nao encontrar motivo de ldquocompeticaordquo entre as duas mas que en-
quanto o HTML 5 e uma especificacao o Gears e uma implementacao
No entanto tambem e verdade que o HTML 5 cobre muitos outros pontos para
alem das OWA que saem completamente fora do ambito do Gears Se esta es-
pecificacao atingir um estado de maturidade que possibilite a sua adopcao pelos
principais browsers tornando nativo do browser o suporte OWA entao deixara de
fazer sentido a existencia de uma extensao como o Gears
A especificacao HTML 5 disponibiliza duas APIs relevantes para o tema das
OWA
1 Uma base de dados baseada em SQL que permite o armazenamento de dados
do lado do cliente
2 Uma ldquocacherdquo HTTP que garante a disponibilidade das aplicacoes mesmo quando
o utilizador nao possui uma ligacao a Internet
Estas caracterısticas sao as bases da tecnologia das OWA e tem correspondencia
com os pontos analisados nas seccoes 311 e 311
35 Web applications que usam funcionalidades offline
Nesta seccao apresentam-se algumas web applications que actualmente disponi-
bilizam funcionalidades offline Estas aplicacoes foram escolhidas para uma analise
mais pormenorizada por utilizarem o Gears que tal como descrito na seccao 4 foi
a tecnologia escolhida para o projecto
351 Google Reader e Google Docs
O Google Reader7 e um leitor de feeds RSS Permite gerir a subscricao de varios
sites simultaneamente que disponibilizem conteudos neste formato e foi a primeira
web application da Google com uma versao offline publicamente acessıvel (desde
Junho de 2007)
O Google Reader implementa o modo ldquoutilizador deciderdquo oferecendo na sua
interface um botao que permite alternar entre os modos online e offline
O Google Docs8 e uma web application que permite a criacao e edicao de doc-
umentos de texto folhas de calculo e apresentacoes Era ja publico desde Janeiro
de 2008 que o Google estava a desenvolver uma versao OWA desta aplicacao mas o
acesso a uma versao experimental so foi possıvel a partir de 31 de Maio de 2008
7Google Reader - httpreadergooglecom8Google Docs - httpdocsgooglecom
26
Estado da arte
A implementacao das funcionalidades offline nestas duas aplicacoes seguiu difer-
entes aproximacoes principalmente porque o Google Reader apresenta ao utilizador
informacoes que sao fornecidas por fontes externas enquanto que no Google Docs
a informacao e criada e editada pelo utilizador sobre a forma de documentos
A diferente origem da informacao implica que no Google Reader seja necessario
prever casos de excepcao tal como existirem demasiados itens que necessitam de
ser transferidos para o cliente Nao observar este ponto causa um problema grave
de usabilidade e para evitar tempos de espera demasiado longos e uma interface
com pouca capacidade de resposta as accoes do utilizador o Google Reader apenas
transfere para o cliente os dois mil itens mais recentes na transicao para o modo
offline
352 Remember the Milk
O Remember The Milk9 e uma web application desenvolvida por uma equipa
Australiana que proporciona funcionalidades de agenda gestao de tempo e de tare-
fas e foi uma das primeiras aplicacoes independentes do Google a adoptar o Gears
para acessos em modo offline Permite que os seus utilizadores facam uma gestao
de tarefas agrupando-as em listas adicionando-lhes campos de informacao adicional
ou dando-lhes informacao geografica (recorrendo ao servico Google Maps10) Entre
a sua lista de funcionalidades encontra-se ainda a possibilidade de importar e ex-
portar eventos no formato iCalendar (ics) etiquetas (tags) em tarefas publicacao
Really Simple Syndication (RSS) e partilha de categorias de tarefas de acordo com
diferentes nıveis de permissoes de acesso definidos pelo utilizador
353 MySpace e WordPresscom
O MySpace uma das maiores social networks na Internet anunciou recente-
mente que vai disponibilizar uma versao do seu cliente de e-mail que utiliza o Gears
para acelerar o seu desempenho Numa fase inicial estara disponıvel apenas para
utilizadores que tenham cinco mil ou mais mensagens na sua caixa de correio e
permitira efectuar pesquisas muito mais rapido que a sua versao online
O servico de blogs Wordpresscom anunciou tambem o inıcio da utilizacao desta
tecnologia com o fim de melhorar o desempenho A versao que utiliza esta tecnologia
descarrega e armazena no cliente um conjunto de imagens e scripts que passam a
ter preferencia sobre os seus congeneres online e que permitem acelerar o processo
de carregamento da aplicacao e visualizacao de blogs
9Remember The Milk ndash httpwwwrememberthemilkcom10Google Maps ndash httpmapsgooglecom
27
Estado da arte
O MySpace e o Wordpresscom sao dois exemplos da utilizacao da tecnologia
OWA para optimizacao de web application ja existentes Sem pretenderem disponi-
bilizar uma versao que seja totalmente offline fazem uso do Gears para armazenar no
cliente parte dos recursos frequentemente acedidos na visualizacao das suas paginas
36 Escolha da tecnologia
Apos a analise das tecnologias apresentada nas seccoes 31 a 34 foi necessario es-
tudar a adequacao de cada uma delas ao projecto em questao Desde logo e possıvel
observar que nem todas se dedicam apenas a OWA Por exemplo o Adobe AIR
apesar de ter suporte para OWA apenas disponibiliza algumas das funcionalidades
identificadas como mais indicadas para a execucao do projecto quando utilizado
na sua vertente desktop tal como exposto na Tabela 31 mas a utilizacao desta
vertente implicaria o desenvolvimento de novas interfaces e de novas formas de co-
municacao (troca de mensagens XML ou JSON) A vertente web do Adobe AIR
foca-se mais especificamente nas Rich Internet Applications e permite a reutilizacao
do codigo ja existente (exigindo naturalmente a sua adaptacao e a implementacao
das funcionalidades pretendidas)
A tecnologia escolhida para a realizacao deste trabalho foi o Gears sendo que
um dos principais factores a influenciar esta opcao foi a liberdade introduzida pela
sua licenca Berkeley Software Distribution (BSD)11
Considerou-se o funcionamento desta ferramenta extremamente adequando a
aplicacao no WOW uma vez que o seu principal objectivo e precisamente tornar
possıvel a execucao offline de uma pagina web e por virtude deste facto o Gears tem
uma API concisa e de simples aplicacao pratica uma vez que nao possui quaisquer
outros elementos distractores O funcionamento do seu ManagedResourceStore ex-
emplificado na Figura 31 com a capacidade de actualizacao de recursos definidos
num ficheiro manifesto especificado em JSON pesou tambem nesta decisao
11Sobre a licenca BSD consultar httpwwwopensourceorglicensesbsd-licensephp e http
wwwlinfoorgbsdlicensehtml
28
Estado da arte
Figura 31 Esquema UML do processo efectuado pelos recursos do Gears do tipoManagedResourceStore para a actualizacao dos conteudos definidos no ficheiro manifesto
29
Estado da arte
Funcionalidade RIAs no browser RIAs no desktop
Disponibilidadeda aplicacao
As aplicacoes podem ser facil-mente exploradas e utilizadas
As aplicacoes quando instal-adas tem maior grau de fun-cionalidades e persistencia
Instalacao Nao e necessario qualquer tipode instalacao
As aplicacoes sao instaladasatraves do browser ou descar-regadas e instaladas comouma aplicacao tradicional
Actualizacoes Aplicacoes sao actualizadascarregando conteudos paraum website
O AIR disponibiliza uma APIque permite que as aplicacoessejam actualizadas de umaforma
Sistemas opera-tivos suportados
As aplicacoes podem ser exe-cutadas em diversos sistemasoperativos e browsers
As aplicacoes sao multi-plataforma e podem serinstaladas e executadas emdiversos sistemas operativos ebrowsers
Linguagens deprogramacao
Javascript e disponibilizadopelo browser e ActionScripte disponibilizado pelo AdobeFlash Player
Maquinas virtuais deJavascript e ActionScriptcompatıveis com o browser
Capacidade deexecucao embackground
As RIAs podem ser execu-tadas numa janela do browser
As aplicacoes podem ser ex-ecutadas em background edisponibilizar notificacoes talcomo uma aplicacao tradi-cional
Persistencia A actividade esta limitada asessao do browser Quando obrowser e encerrado toda ainformacao e descartada
As aplicacoes sao instaladas eestao disponıveis no desktopPodem armazenar informacaolocalmente e estao disponıveisoffline
Integracao com odesktop
Integracao com o desktop lim-itada devido a restricoes im-postas pelo browser
As aplicacoes podem acederao sistema de ficheiro ao clip-board eventos notificacoesetc
Controlo da inter-face com o uti-lizador
As aplicacoes sao acedidasatraves de uma janela dobrowser que tem os seusproprios controlos e visualgrafico
As aplicacoes tem um vi-sual grafico proprio em janelapropria
Armazenamentode dados
As aplicacoes tem armazena-mento limitado que pode serreescrito pelo browser
As aplicacoes tem acesso a to-talidade do espaco disponıvellocalmente e a uma base dedados com a possibilidade deencriptacao
Tabela 31 Comparacao das funcionalidades oferecidas pelo Adobe AIR para as platafor-mas web e desktop
30
Estado da arte
Aplicacao Modo de execucao utilizadoGoogle Reader Utiliza o modo ldquoutilizador deciderdquo disponibilizando
ao utilizador um botao para alternar entre os modosonline e offline Como lida com informacao recol-hida de fontes externas de natureza frequentementeefemera o processo de sincronizacao apenas transfereos dois mil itens mais recentes quando passa ao es-tado offline Neste modo sao ainda guardadas in-formacoes de itens lidos e etiquetas atribuıdas quesao sincronizadas com o servidor quando o utilizadorvoltar a activar estado online
Google Docs Utiliza o modo ldquoaplicacao deciderdquo permitindo que outilizador edite os conteudos de documentos de textofolhas de calculo e de apresentacoes independente-mente do estado da ligacao desde o momento em queas funcionalidades offline sao activadas A aplicacaofaz pequenas sincronizacoes com o servidor sempre quenecessario
Remember the Milk Utiliza um modo hıbrido entre ldquoaplicacao deciderdquo eldquoutilizador deciderdquo A aplicacao encarrega-se da sin-cronizacao de dados mas disponibiliza um controlona sua interface que permite despoletar manualmenteeste processo para situacoes em que o utilizador fez al-teracoes recentes e pretende usufruir das capacidadesoffline imediatamente
MySpace O MySpace anunciou a utilizacao de mecanismos dearmazenamento de dados no cliente com recurso atecnologias OWA para melhorar o desempenho doseu cliente web de correio electronico nomeadamenteno que diz respeito a operacoes de pesquisa e or-denacao Inicialmente esta funcionalidade estara ape-nas disponıvel para utilizadores com cinco mil ou maismensagens na sua caixa de correio mas nao e aindaclaro se sera disponibilizada uma versao totalmenteoffline
Tabela 32 Resumo da utilizacao de tecnologias OWA em algumas web applications con-sideradas na analise do estado da arte
31
Estado da arte
32
Capıtulo 4
Desenvolvimento
Neste capıtulo introduz-se a aplicacao WOW e apresenta-se o estudo que foi
feito da adequacao de cada tecnologia para a implementacao da funcionalidade of-
fline nesta plataforma Fazem-se diversas consideracoes sobre opcoes a tomar na
concepcao de OWAs e problemas comuns na sua implementacao bem como sug-
estoes para os resolver O WOW e uma aplicacao ja existente de gestao de ordens
de trabalho e do fluxo de tarefas numa empresa ou organizacao
41 Como ficar offline
Na maior parte das web applications de hoje nao existe uma camada de dados
real A aplicacao exemplificada na Figura 41 ao longo da sua execucao acede
directamente a sua unica fonte de dados (o servidor) atraves de chamadas Ajax sem
que exista uma separacao clara destas duas camadas
Para que uma web application seja capaz de ser executada sem uma ligacao
activa a Internet e mantenha o seu caracter dinamico torna-se necessario incluir
Figura 41 Exemplo de uma arquitectura de uma web application sem uma camada deabstraccao de dados Figura adaptada de http gears google com
33
Desenvolvimento
Figura 42 Exemplo de uma arquitectura de uma web application com uma camada deabstraccao de dados Figura adaptada de http gears google com
um mecanismo de armazenamento de dados local seja uma base de dados ou a
capacidade de acesso ao disco No entanto este mecanismo introduz dois problemas
1 Qual das fontes de dados utilizar quando um utilizador faz um pedido de
informacao
2 A necessidade de implementar uma camada de acesso a dados que seja coerente
quer se use o servidor remoto ou local
Por exemplo em vez de a aplicacao Ajax fazer um pedido relativo as contas de
todos os utilizadores em formato JSON directamente ao servidor remoto podera ao
inves fazer o pedido a um objecto intermedio da camada de dados Este objecto
demonstrado na Figura 42 sera responsavel por implementar uma interface de
acesso a base de dados e retornar um objecto JavaScript com uma representacao da
resposta do servidor
Mas a existencia de uma segunda fonte de dados torna recomendavel tambem
a implementacao de uma camada de data switching que em funcao da existencia
de conexao a Internet e da necessidade de actualizacao dos dados decide se faz o
pedido ao servidor remoto ou se fornece os dados presentes localmente Este objecto
apresentado na Figura 43 decidira de forma transparente para o utilizador se le ou
escreve os dados localmente ou se os enviapede ao servidor remoto e pode tambem
iniciar o processo de convergencia de dados e de resolucao de conflitos
411 Funcionalidades disponıveis em modo offline
Por razoes praticas e provavel que nem todas as funcionalidades da aplicacao
possam ser disponibilizadas em modo offline E necessario escolher quais as fun-
cionalidades a disponibilizar no modo offline da aplicacao e implementar a logica
que decide quando utilizar a base de dados local ou o servidor remoto Apesar do
acesso a base de dados local ser muito mais rapido do que aceder ao servidor o
acesso local nem sempre e preferido Ha varias razoes que podem tornar necessario
escolher o acesso ao servidor em vez do acesso local
34
Desenvolvimento
Figura 43 Exemplo de uma arquitectura de uma web application com uma camada deabstraccao de dados e um data switch Figura adaptada de http gears google com
1 A informacao pode ter uma natureza efemera e nao fazer sentido guarda-la
localmente Exemplo dados em tempo real da bolsa de valores de Lisboa
2 Algumas aplicacoes lidam com informacao que so faz sentido na presenca de
uma ligacao Exemplo Instant Messaging
3 A aplicacao podera escolher apenas guardar a informacao acedida mais fre-
quentemente Exemplo para o utilizador poder alterar a lıngua de apre-
sentacao da aplicacao os conteudos terao que ser guardados em todas as
lınguas disponibilizadas pela aplicacao O custo de implementacao de algu-
mas funcionalidades pode nao compensar o benefıcio
4 A capacidade de processamento ou de armazenamento de dados pode inviabi-
lizar algumas funcionalidades offline Exemplo se uma dada funcionalidade
necessita de uma capacidade de armazenamento de dados para alem do razoavel
de um computador pessoal para ser util (visualizador de mapas)
42 Modos de execucao
Um aspecto que e necessario estudar para qualquer web application que se deseje
disponibilizar offline prende-se com tres modos de execucao que devem ser consid-
erados
1 Utilizador decide o modo de execucao A aplicacao tem modos distintos
de execucao para os estados online e offline geralmente indicados na interface
com o utilizador O utilizador e informado do estado da ligacao e participa na
alteracao de estado de execucao da aplicacao interagindo com a sua interface
2 Aplicacao decide o modo de execucao Pode ser implementado na propria
aplicacao um mecanismo de deteccao do estado da ligacao (por exemplo atraves
35
Desenvolvimento
de chamadas Ajax periodicas) transitando de estado e sincronizando automati-
camente Desta forma o utilizador nao precisa de participar na alteracao de
estado a menos que exista um conflito de dados que requeira a sua atencao
3 Aplicacao assume sempre o estado offline Outra hipotese sera imple-
mentar uma web application que assume sempre estar na ausencia de uma
ligacao ao servidor de dados Esta aplicacao responde aos pedidos do uti-
lizador efectuando pedidos de informacao ao servidor mas nao dependendo
de uma resposta valida para mostrar a informacao que ja tinha disponıvel an-
teriormente A sincronizacao de dados com o servidor e tentada sempre que
existam dados para submeter e uma accao do utilizador
421 Modo ldquoutilizador deciderdquo
Neste modo de execucao quando a aplicacao esta online comunica com o servidor
remoto quando esta offline comunica com a base de dados local A informacao tem
que ser sincronizada sempre que se muda de modo A principal vantagem desta opcao
e que e a mais simples de implementar mesmo para uma aplicacao ja existente e
portanto uma forma expedita de disponibilizar uma OWA No entanto tem tambem
algumas desvantagens que devem ser consideradas
1 O utilizador tem que se lembrar de fazer a alteracao de estado de execucao
Caso contrario podera estar a trabalhar inadvertidamente numa versao offline
com dados antigos ou nao ter a informacao necessaria se perder subitamente
a ligacao
2 Se a ligacao for intermitente o utilizador tera ou que escolher um dos modos
de execucao ou estar constantemente a trocar
3 Uma vez que a base de dados nao esta sempre actualizada nao podera ser
utilizada para melhorar a rapidez de execucao da aplicacao quando em modo
online
422 Modo aplicacao decide
A deteccao do estado da ligacao pode ser implementada atraves de um pedido
assıncrono ao servidor tal como ilustrado na Figura 44 O resultado deste pedido
definira o estado online (em caso de sucesso) ou offline (em caso de falha) A
sincronizacao de dados podera ser feita sempre que ocorra uma transicao do es-
tado offline para o estado online No entanto este metodo nao se revela eficiente
36
Desenvolvimento
Figura 44 Esquema grafico ilustrando uma OWA executando no browser utilizando ummodo de execucao do tipo ldquoaplicacao deciderdquo com deteccao automatica do estado daligacao via pedidos Ajax assıncronos a cada cinco segundos
para grandes aplicacoes uma vez que requer a troca de mensagens demasiado fre-
quentes com o servidor que se destinam exclusivamente a monitorizacao do estado
da ligacao
423 Modo ldquoaplicacao assume o estado offlinerdquo
Uma aplicacao transparente funciona assumindo sempre que esta em modo of-
fline ou pelo menos que pode perder a ligacao a qualquer momento Neste modo
tira-se o maximo partido do armazenamento local e fazem-se pequenas mas contınuas
sincronizacoes com o servidor sempre que este esteja disponıvel A sincronizacao de
dados tambem e feita sempre que se volta ao estado online
As vantagens de uma web application transparente sao as seguintes
bull Uma melhor experiencia para o utilizador uma vez que este nao tem que se
preocupar com o estado da ligacao ou com a transicao de estados
bull A aplicacao funciona de forma coerente mesmo que a ligacao seja intermitente
bull Uma vez que o armazenamento local e mantido actualizado pode ser utilizado
para melhorar o desempenho da aplicacao
Foram identificadas as seguintes desvantagens
bull E mais difıcil de implementar e a sincronizacao acarreta cuidados especiais
bull E necessario um cuidado adicional para evitar que as operacoes de sincronizacao
frequentes que ocorrem automaticamente nao afectem os tempos de resposta
da aplicacao
bull Os testes a aplicacao sao mais complexos uma vez que a sincronizacao de dados
nao ocorre em resposta a uma accao do utilizador
37
Desenvolvimento
43 Sincronizacao de dados
A sincronizacao de dados consiste na capacidade de identificar e transferir pe-
riodicamente a versao mais actual dos dados entre o cliente e o(s) servidor(es)
Independentemente do modo de execucao escolhido e mesmo do estado da ligacao
do utilizador a informacao armazenada localmente e a informacao armazenada no
servidor estarao por vezes dessincronizadas Isto podera acontecer sempre que por
exemplo
bull O utilizador faz alteracoes em modo offline
bull A informacao e partilhada e pode ser alterada por uma entidade externa
bull A informacao e fornecida por uma entidade externa
Resolver estas diferencas de forma a que a informacao local e remota encontrem
a igualdade chama-se sincronizacao de dados Ha varias aproximacoes possıveis
para este efeito que dependem da natureza da aplicacao cada uma com vantagens
e desvantagens
A capacidade de suportar a mobilidade dos utilizadores torna-se cada vez um
ponto mais importante de uma web application Para uma organizacao de dimensao
global e vital garantir que os seus colaboradores tem acesso a mesma informacao
que tem disponıvel nos seus postos de trabalho mesmo quando estao fora Na maior
parte dos casos estes colaboradores terao acesso a um computador portatil um
desktop Smartphone ou PDA e atraves destes poderao ter acesso a sua informacao
directamente atraves de ligacoes encriptadas Virtual Private Network (VPN) de um
servidor web ou de outro mecanismo de rede
Esta solucao e simples de implementar mas infelizmente para a maioria dos
colaboradores com grande factor de mobilidade nao e satisfatoria As principais
desvantagens sao as seguintes
bull Requisitos de ligacao Para permitir que os utilizadores acedam a sua in-
formacao e necessario garantir a capacidade constante de comunicacao pelo
menos durante o tempo necessario que assegure a sua transferencia
bull Velocidade de ligacao sem persistencia de dados e em ligacoes de fraca
qualidade a usabilidade por vezes torna-se inaceitavel
bull Ponto crıtico de falha Com este tipo de solucao todos os utilizadores de-
pendem da base de dados que armazena informacao vital para o funcionamento
do cliente
38
Desenvolvimento
bull Scalability do servidor A medida que novos utilizadores sao adicionados ao
sistema o desempenho do servidor e afectado levando a necessidade de maior
capacidade de armazenamento eou processamento
De acordo com a documentacao da Microsoft Sync Framework [Mic08] uma
solucao alternativa consiste em implementar uma Occasionally Connected Appli-
cation (OCA) Uma OCA permite a um utilizador remoto continuar a aceder a
sua informacao mesmo depois de perder a ligacao mas em vez de recorrer a um
servidor recorre a informacao armazenada no seu dispositivo local Para preencher
localmente a informacao que o utilizador necessita uma OCA possui mecanismos
de sincronizacao de dados que sao oferecidos por esta framework
431 Quando sincronizar
Uma das solucoes mais simples de implementar passa por disponibilizar um
mecanismo manual que despoleta a sincronizacao Diz-se manual porque e o uti-
lizador que escolhe quando sincronizar e pode ser implementada simplesmente
fazendo o upload de toda a informacao para o servidor e depois fazendo o download
da copia mais recente da informacao antes de voltar a ficar offline Para que esta
seja uma opcao viavel e necessario que
bull O volume de dados seja suficientemente pequeno para que possa ser transferido
do servidor para o cliente num espaco de tempo aceitavel
bull Que o utilizador indique explicitamente que quer mudar para o estado offline
ou online pressionando um botao da interface
Contudo podem ser identificados alguns problemas relacionados com esta abor-
dagem
bull Os utilizadores nem sempre podem prever o estado das suas ligacoes A ligacao
pode-se perder subitamente ou ter um caracter intermitente
bull O utilizador pode esquecer-se de efectuar a sincronizacao
Outra opcao sera conjugar a sincronizacao de dados com o modo de execucao
transparente A sincronizacao ocorre automaticamente em background de forma
nao intrusiva para o utilizador A aplicacao comunica com o servidor regularmente
efectuando pequenas trocas de dados com o objectivo de manter o sincronismo da
informacao local e remota Esta abordagem pode ser implementada com pedidos
Ajax assıncronos e regulares ao servidor o que permite manter a interaccao com a
interface fluıda evitando bloqueios Estes pedidos sao feitos prevendo as situacoes
39
Desenvolvimento
de disponibilidade ou indisponibilidade (timeout) do servidor Uma outra opcao
sera permitir que o servidor comunique essas alteracoes utilizando Comet1 tal como
descrito em [Wil06] e [Rus06] As vantagens destas aproximacoes sao
bull A informacao esta disponıvel a qualquer altura que o utilizador decida ficar
offline ou que a ligacao seja acidentalmente perdida
bull O desempenho da aplicacao pode ser melhorado quando se estiver a utilizar
uma ligacao a Internet lenta uma vez que o acesso a dados locais e mais
eficiente do que a consulta de dados ao servidor
44 WOW
O WOW e uma plataforma integrada de gestao de ordens de trabalho ja ex-
istente e desenvolvida pela Critical Software SA a qual se pretende adicionar a
capacidade de execucao offline Esta aplicacao e extremamente dinamica e con-
figuravel com um conjunto extremamente rico de funcionalidades das quais se
destacam
bull Gestao de Ordens de Trabalho ndash suportando a gestao dos pedidos desde a
sua criacao ate ao seu fecho tomando em conta os diferentes tipos de pedidos
(ordens de trabalho pedidos de informacao melhorias resolucao de problemas
etc) e diferentes tipos de accoes possıveis para cada um (Figura 45)
bull Monitorizacao de alteracoes ndash Historico de mudancas anexos e estados criando
relatorios de alteracao automaticamente (o que por quem e quando)
bull Uso de Service Level Agreements (SLAs) ndash E possıvel associar a um pedido um
SLA que define qual o perıodo de tempo atribuıdo a resolucao de um pedido
controlando e agilizando a resolucao do mesmo
bull Utilizacao de queries de utilizador configuraveis que permitem acesso rapido
a determinadas ordens de trabalho de acordo com o filtro configurado (por
exemplo ldquoPara mimrdquo ldquoPara o Grupordquo ldquoPelo Grupordquo)
bull Gestao do relacionamento entre pedidos
bull Pesquisa e filtragem de ordens de trabalho
bull Exportacao de dados em formatos padrao (PDF DOC ou XLS)
bull Integravel com solucoes externas
40
Desenvolvimento
Figura 45 Detalhe de um conjunto possıvel de estados e respectivas transicoes para umadada ordem de trabalho no WOW desde a sua submissao no sistema ate a sua conclusaoem fecho ou cancelamento Esta figura representa apenas um exemplo ja que o mapa deestados para uma ordem de trabalho e dinamico e pode ser alterado por um administradorFigura retirada de uma brochura promocional do WOW Critical Software SA
A utilizacao de uma ferramenta deste tipo por parte de uma empresa ou orga-
nizacao oferece vantagens quer a gestao de topo quer aos colaboradores individuais
para os colaboradores individuais o WOW e uma aplicacao onde estao registadas
todas as tarefas contribuindo activamente para o desenvolvimento em ambientes
multi-tarefa e para a organizacao pessoal das tarefas de acordo com prioridades
Para a gestao de topo esta ferramenta permite obter uma visao global do estado da
organizacao em termos de tempo gasto por tarefa executada sendo uma mais valia
para a previsao e gestaoalocacao de recursos
45 Visao geral sobre a arquitectura do WOW
O WOW e interessante nao so do ponto de vista de produto como tambem do
ponto de vista de plataforma Existem diversos plug-ins que estendem as funcional-
idades do WOW e existem ate projectos que pretendem usar a arquitectura do
WOW para criar produtos com fins diferentes do inicial (por exemplo o WOW-
Storm ndash um sistema de registo e classificacao social de ideias)
De modo a conseguir ter essa expansibilidade a plataforma WOW assenta sob
uma arquitectura distribuıda modular e expansıvel com uma componente central
ndash o core ndash estruturado em camadas logicas E no core que se situam todas as
1O Comet e um conceito semelhante ao Ajax introduzido por Alex Russel mas no qual e o servidor quetoma a iniciativa de ldquoenviarrdquo os dados ao browser sem que este tenha que efectuar um pedido Tambem econhecido por Ajax Push Reverse Ajax ou HTTP Streaming
41
Desenvolvimento
funcionalidades base da aplicacao quer a nıvel logico funcional e de apresentacao
quer a nıvel de gestao e configuracao
E possıvel a execucao de varias instancias do core simultaneamente em servidores
distintos o que permite a alta escalabilidade e disponibilidade desta aplicacao A
consistencia dos dados fica sempre garantida atraves da partilha da base de dados
e pelo balanceamento dos pedidos uma vez que cada um e encaminhado para uma
unica instancia
O WOW apresenta tambem a vantagem de ser uma plataforma extensıvel E
possıvel adicionar novas caracterısticas a plataforma atraves de componentes que se
podem ser divididos em duas categorias plugins e connectors
Os plugins sao componentes que se encontram no mesmo no fısico que a aplicacao
partilhando do mesmo contexto de execucao do core Sao assim uma forma mais
directa de obter informacao da plataforma visto que nao possuem restricoes de
acesso aos dados nem dependencias externas A arquitectura deste componente tera
assim que permitir varias execucoes instanciadas cada uma associada a um core
Por outro lado os connectors sao componentes que se encontram distribuıdos
comunicando externamente com o core Quer a sua execucao quer a obtencao
dos dados estao assim dependentes de interfaces de comunicacao externas que a
plataforma disponibiliza Estes componentes ao contrario dos plugins sao instan-
ciados unicamente e recorrem ao protocolo de comunicacao Java Messaging Service
(JMS) para comunicar com o core
46 WOW Offline
Para alem das opcoes tomadas relativamente a tecnologia a utilizar surgiu
tambem a necessidade de optar por um dos modos de execucao apresentados na
seccao 42
Das tres opcoes possıveis foi o modo ldquoaplicacao assume o estado offlinerdquo descrito
na seccao 423 que mereceu a maior atencao uma vez que reune as vantagens de
uma experiencia mais positiva para o utilizador (uma vez que este nao tem que
participar activamente na alteracao do modo execucao como descrito na seccao 421)
e nao constitui uma sobrecarga excessiva para servidor (como o modo abordado na
seccao 422)
No entanto esta opcao comprometia a complexidade da implementacao para alem
dos objectivos propostos para este projecto e para cumprir o prazo dado foi tomada
a decisao de implementar o modo ldquoutilizador deciderdquo especificando apenas de forma
teorica o modo ldquoaplicacao assume o estado offlinerdquo
As caracterısticas do Gears foram ja descritas na seccao 31 Na Figura 47
mostra-se a sua forma de funcionamento quando integrado numa web application
42
Desenvolvimento
Nesta figura representa-se o modulo LocalServer do Gears como um ponto de de-
cisao Aqui sao testadas as condicoes que determinam se o pedido sera interceptado e
servido localmente ou se prossegue para uma maquina remota E tambem represen-
tada uma base de dados que corresponde ao modulo Database mas que podera nao
ser utilizada Este modulo tal como o modulo Workerpool tem caracter opcional
e sao utilizados consoante os requisitos da aplicacao
A plataforma WOW lida com mais dados do que e necessario passar para o
lado do cliente Em conformidade com o ja exposto na seccao 411 volta-se a
frisar que nao se pretende recriar toda a logica de negocio nem os conteudos da
base de dados no cliente pela sua complexidade e volume de dados Pretende-se
pelo contrario permitir que os utilizadores tirem partido da capacidade de poder
consultar as suas ordens de trabalho quando nao dispoe de uma ligacao transferindo
apenas o essencial para isto seja possıvel
A pagina inicial do WOW apresenta um resumo das ordens de trabalho abertas
ndash enviadas e recebidas ndash que se pretende permitir visualizar offline (ver Figura 46)
Como prova de conceito foi efectuada uma abordagem pragmatica das varias possi-
bilidades descritas na seccao 42
461 Modo ldquoaplicacao deciderdquo com deteccao automatica da ligacao
A primeira abordagem estudada para a disponibilizacao das funcionalidades of-
fline foi o modo ldquoaplicacao deciderdquo com deteccao automatica de ligacao apresentado
na seccao 422 Para que isto seja possıvel foi implementado um mecanismo de ver-
ificacao periodica do estado da ligacao atraves de chamadas Ajax assıncronas O
resultado destes pedidos determina o estado da aplicacao executando as tarefas de
sincronizacao de dados sempre que pertinente Este metodo embora imediato e
simples de implementar depressa se revelou inadequado para o projecto devido ao
elevado consumo de recursos do servidor que a utilizacao intensiva faz esperar a
comunidade da plataforma WOW no principal cliente excede os 7000 utilizadores
Foi estimado que para uma utilizacao de fluidez aceitavel o estado da ligacao deveria
ser testado a cada cinco segundos Assumindo uma adesao (previsao pessimista) de
1 aos servicos offline assistir-se-ia a cerca de 840 pedidos adicionais por minuto
Mas o principal problema desta aproximacao prende-se com o facto de a ver-
ificacao ser feita em intervalos de tempo discretos levando a possibilidade de a
aplicacao poder ter em dado momento uma representacao errada do seu estado
real da ligacao Este problema e ilustrado na Figura 48 onde se ve claramente a
discrepancia entre o estado real da ligacao e a representacao interna que esta tem
Note-se que nesta janela de tempo qualquer accao do utilizador que exija uma
resposta sıncrona do utilizador leva-lo-a para um ldquobeco sem saıdardquo onde nao tera
43
Desenvolvimento
Figura 46 A pagina inicial do WOW apresenta um resumo das ultimas ordens de trabalhoenviadas e recebidas Na imagem pode-se observar a transicao do estado online para offline
acesso a versao offline porque a aplicacao nao fez a transicao automatica nem acesso
a versao online porque na verdade nao possui uma ligacao O que acontecera nesta
situacao sera uma tentativa de acesso ao servidor por parte da aplicacao numa
altura em que este se encontra indisponıvel e o resultado sera uma mensagem de
ldquopedido excedeu o tempordquo apresentado pelo browser Este e um estado sem retorno
porque apos o browser apresentar esta mensagem todos os recursos JavaScript ficam
indisponıveis tornando impossıvel o regresso ao estado anterior ou o tratamento do
erro de qualquer outra forma No entanto as chamadas Ajax podem ser tratadas de
forma especial para a eventualidade de falha e portanto nao constituem problema
44
Desenvolvimento
Figura 47 Ilustracao do funcionamento do Gears numa web application que utiliza ummotor Ajax Os pedidos HTTP ou HTTPS podem ser interceptados e tratados localmenteou podem ser feitos a uma maquina remota consoante se verificarem ou nao as condicoesexpressas no ponto 311 E representado um acesso a uma base de dados local (fornecidapelo Gears) mas a sua utilizacao e opcional
462 Implementacao do modo ldquoutilizador deciderdquo
Este modo de execucao foi ja descrito na seccao 421 e a sua principal carac-
terıstica e ser o utilizador a decidir se a aplicacao deve utilizar um servidor remoto
ou a maquina local como fornecedor de dados
Relativamente ao WOW o WOW Offline na vertente ldquoutilizador deciderdquo vem
alterar os seus casos de uso dando ao utilizador a possibilidade de alterar o estado
de execucao da aplicacao (entre online e offline) Resta dizer que no modo online se
mantem todas as funcionalidades anteriores e que no modo offline torna-se possıvel
visualizar os conteudos da pagina principal do WOW (Figura 46) e os detalhes das
ordens de trabalho (Figura 49) tal como expressa a Figura 410
Esta aproximacao foi utilizada na prova de conceito do WOW adicionando um
controlo a interface desta aplicacao que permite ao utilizador alternar entre os esta-
dos online e offline Na transicao de online para offline sao descarregados os recursos
necessarios para a execucao desta aplicacao sem recorrer a Internet Para o fazer
45
Desenvolvimento
Figura 48 Neste exemplo do modo ldquoaplicacao deciderdquo o teste da ligacao e feito e feito acada cinco segundos O resultado deste teste nao reflecte sempre o estado real da aplicacaopodendo levar a aplicacao a ter comportamentos indesejaveis Na figura assinala-se umperıodo de tempo no qual a representacao interna do estado da ligacao nao corresponde arealidade
e utilizado um recurso ResourceStore e um ManagedResourceStore (introduzidos
em 311) O primeiro e utilizado para armazenar a pagina principal do WOW ndash do-
ravante designada por homejsp ndash e o segundo e utilizado para armazenar imagens
folhas de estilo CSS e scripts JavaScript
Para a implementacao deste modo de execucao foram identificadas as seguintes
tarefas
1 Guardar informacao que permita a recriacao das paginas que se pretende
disponibilizar offline (utilizando o Gears)
2 Disponibilizar um controlo que permita alterar o estado de execucao atraves
da interaccao com a pagina principal
3 Durante a sincronizacao de dados apresentar o progresso da transferencia de
dados
O primeiro passo consistiu na identificacao de todos os conteudos que sao necessarios
transferir para a execucao offline Foi utilizado um recurso do Gears do tipo
ManagedResourceStore que recorre a um ficheiro manifesto para identificar to-
dos os ficheiros que deve transferir Este recurso e gerido automaticamente pelo
Gears transferindo para o cliente a versao mais recente sempre que e necessario
isto e sempre que exista um ficheiro manifesto com uma identificacao de versao que
seja diferente da actualmente disponıvel no cliente Uma vez identificados todos
ficheiros necessarios para a execucao offline num (ou mais) ficheiros manifesto o
Gears encarrega-se da sua actualizacao mas o preenchimento destes ficheiros man-
ifesto e manual o que se traduz num cuidado extra na manutencao da aplicacao
A forma como esta informacao e guardada deve tambem ser cuidadosamente
estudada A opcao mais flexıvel passa por utilizar o modulo Database apresentado
na seccao 311 e guardar a informacao de uma forma relacional Para a recriacao
das paginas pode ser disponibilizada uma versao HTML da pagina que funciona
46
Desenvolvimento
Figura 49 Pagina de visualizacao do detalhe de uma ordem de trabalho
como template nao possui quaisquer dados e e utilizada apenas em modo offline E
preenchida para cada pedido retirando os dados relevantes da base de dados
O modelo de dados do WOW torna esta opcao extremamente trabalhosa uma
vez que as entidades envolvidas na geracao de cada pagina de informacao sobre
cada ordem de trabalho tem relacoes de dependencia complexas seguindo padroes
muito variaveis Por exemplo em cada ordem de trabalho existe um formulario que
permite a sua progressao de estado com diversos campos opcionais e obrigatorios
este formulario e definido pelo administrador e esta relacionado nao apenas com o
tipo de ordem de trabalho mas tambem com o estado actual em que esta se encontra
e a accao que se pretende realizar O elevado numero de combinacoes de tipos de
ordem de trabalho estados e accoes que existem num dado momento juntamente
com a sua possibilidade de alteracao obrigariam a implementacao de uma logica de
negocio complexa o que esta fora do ambito deste projecto
47
Desenvolvimento
Figura 410 Esquema UML que expressa os casos de uso do WOW Offline no modoldquoutilizador deciderdquo
463 Especificacao do modo ldquoaplicacao assume o estado offlinerdquo
A aproximacao para o modo ldquoaplicacao assume o estado offlinerdquo foi tambem
dividida em varias tarefas
1 Guardar informacao que permita a recriacao da pagina principal do lado do
cliente no estado offline (utilizando o Gears)
2 Dotar a aplicacao do cliente de um mecanismo de deteccao da ligacao
3 Identificar os ldquomomentos chaverdquo em que devera ocorrer sincronizacao de dados
4 Implementar a sincronizacao de dados
A sincronizacao de dados deve ser feita em ambas as transicoes online-offline e
offline-online quer para transferir novos dados do servidor (os pedidos podem ser
alterados por outros utilizadores) quando se transita do estado quer para comunicar
eventuais alteracoes feitas em modo offline
Relativamente ao WOW o WOW Offline na vertente ldquoaplicacao assume o es-
tado offlinerdquo vem alterar os seus casos de uso dando ao utilizador a possibilidade
de activar esta funcionalidade A partir do momento que a funcionalidade esta ac-
tivada o utilizador deve tambem ter a possibilidade de gerir algumas preferencias
relacionadas com privacidade de dados Devera ter a hipotese de desactivar o ar-
mazenamento local e de remover todos os dados ja armazenados tal como descrito
na Figura 411
48
Desenvolvimento
Figura 411 Esquema UML que expressa os casos de uso do WOW Offline no modoldquoutilizador deciderdquo
A primeira vez que o WOW Offline e acedido por um cliente e caso seja detec-
tada a presenca do Gears todos os recursos necessarios a sua execucao sao trans-
feridos Todos os acessos posteriores serao feitos a estes recursos locais (recorda-se
que o Gears pode ser utilizado para os manter actualizados recorrendo ao Managed-
ResourceStore 311)
Atraves do JavaScript e possıvel interceptar os eventos de load e unload da
pagina que sao despoletados sempre que ocorre um re-acesso da mesma (incluindo
a accao refresh comum dos browsers) sempre que esta e abandonada ou ainda ou
ainda se a janela for encerrada
Tal como sugerido na seccao 462 a camada de interface desta aplicacao (cada
pagina individual em HTML) devera ser implementada como sendo um template
para apresentacao de dados sendo totalmente preenchida atraves de funcoes em
JavaScript O objectivo deste ponto e criar um padrao de dados que permita ao
JavaScript preencher os dados em cada pagina (template) independentemente de
qual seja a fonte ndash o servidor remoto ou a maquina local tal como exemplificado
no diagrama da Figura 412 Na figura a aplicacao recorre ao servidor remoto para
obter os dados pretendidos quando se encontra na presenca de uma ligacao mas
para dados que exijam uma carga de processamento pelo servidor este acto pode ser
49
Desenvolvimento
Figura 412 Esquema UML que expressa o acto de recolha de dados em modo online eoffline recorrendo ao servidor (modo online) e ao sistema de armazenamento de dadoslocal fornecido pelo Gears (modo offline)
substituıdo pelo envio de um campo de controlo que se destina a aferir se os dados
locais se encontram actualizados No caso de estarem actualizados a comunicacao
com o servidor pode ser substituıda por uma query a base de dados local
50
Capıtulo 5
Resultados e Futuros
Desenvolvimentos
Todo o estudo feito sobre o tema OWA foi ja abordado ao longo do documento
Neste capıtulo apresentam-se os resultados obtidos na implementacao da prova de
conceito que visava compreender a melhor forma de disponibilizar uma versao of-
fline no WOW uma plataforma de gestao de ordens de trabalho ja existente de-
senvolvida pela Critical Software SA
51 Resultados Obtidos
Os resultados obtidos neste projecto sao extremamente satisfatorios uma vez
que o estudo do tema OWA e a implementacao de uma prova de conceito que o
ilustrasse foi conseguido com sucesso
A funcionalidade offline foi adicionada ao produto WOW da Critical Software
SA permitindo a visualizacao de ordens de trabalho e dos seus detalhes mesmo na
ausencia de uma conexao activa a Internet Embora para a solucao implementada
tenha sido utilizada uma abordagem do tipo ldquoutilizador deciderdquo pretende-se que esta
seja convertida para ldquoaplicacao deciderdquo ou mesmo para uma aproximacao hıbrida
semelhante a utilizada pelas aplicacoes estudadas nas seccoes 351 e 352
Para a sua implementacao descrita no capıtulo 4 foram tomadas decisoes de or-
dem pratica que permitissem tornar o trabalho exequıvel nos prazos dados Tentou-
se sempre que estas decisoes afectassem o mınimo em termos de desempenho e de
experiencia para o utilizador Considera-se que a implementacao do modo offline
com uma transicao entre modos do tipo ldquoutilizador deciderdquo (ver seccao 42) reflecte
o compromisso entre o desempenho pretendido e os recursos disponıveis e para alem
51
Resultados e Futuros Desenvolvimentos
de ser um exemplo eficaz das possibilidades que as OWA podem trazer a aplicacao
WOW desenvolvida pela Critical Software e tambem um estudo que pode ser uti-
lizado para analisar a implementacao desta tecnologia noutros produtos da mesma
empresa
Note-se que o principal objectivo do trabalho era ganhar familiaridade com este
tema entender as suas vantagens e desvantagens e compreender as suas limitacoes
Tudo indica que existam varias possibilidades de implementacao deste paradigma
noutros produtos da Critical Software que pela sua natureza podem tambem tirar
partido da execucao offline
52 Trabalho Futuro
O desenvolvimento do conceito e formas de implementacao de OWA continua
em forte desenvolvimento no entanto a sua adopcao ainda nao e generalizada A
dificuldade da sua implementacao em web applications ja existentes e o principal
obstaculo a sua maior divulgacao
Ha tambem um factor que deve ser tido em consideracao a manutencao de
codigo A implementacao de uma versao offline de uma web application requer
a implementacao das mesmas regras de negocio (ou de uma versao simplificada)
utilizadas no servidor Para que isto seja possıvel e necessario ter em conta a
capacidade de processamento do cliente e o factor de duplicacao de codigo que
tornara a aplicacao mais difıcil de manter uma vez que uma alteracao a logica de
negocio do servidor implica tambem uma alteracao a sua versao offline
A prova de conceito implementada permite ja a visualizacao offline dos pedidos
abertos (enviados e recebidos) que constam na pagina principal (este numero e
fixo e pode ser alterado pelo administrador) Uma funcionalidade desejavel seria a
possibilidade de interaccao com a aplicacao em modo offline e sincronizacao com o
servidor quando existisse uma ligacao disponıvel
Foi estudada a utilizacao do modo de execucao ldquoaplicacao assume o estado of-
flinerdquo descrito em 423 e esta seria a forma desejavel para o WOW Offline no
entanto para que esta opcao seja viavel sera necessaria a implementacao de uma
forma eficiente de sincronizacao e armazenamento de dados de uma forma relacional
Para atingir este objectivo podera ser seguida uma polıtica de automacao do pro-
cesso no qual a versao online da aplicacao gera scripts de criacao para as tabelas
necessarias na base de dados da versao offline (nao existe nenhuma ferramenta para
o fazer portanto seria necessaria a sua implementacao) e no qual as paginas HTML
disponibilizadas pelo servidor aos clientes web (browser) servem como templates de
apresentacao de informacao e sao preenchidas de forma semelhante pelo servidor ndash
quando a aplicacao estiver online ndash ou pelo cliente atraves de funcoes em JavaScript
52
Resultados e Futuros Desenvolvimentos
ndash quando a aplicacao estiver offline No entanto no WOW devido a quantidade de
informacao tratada e devido as complexas relacoes entre as diferentes entidades e
de esperar que a complexidade da implementacao de um mecanismo deste tipo torne
esta aproximacao demasiado custosa
O HTML 5 embora um forte candidato ainda nao esta suficientemente desen-
volvido A sua especificacao ainda tem o caracter de Draft (rascunho) e esta sujeita
a modificacoes e a aceitacao e implementacao por parte dos browsers e portanto
de momento foi desconsiderado No entanto no futuro se esta especificacao atingir
um estado de maturidade que permita a sua adopcao devera ser considerada como
um possıvel caminho a seguir
53
Resultados e Futuros Desenvolvimentos
54
Capıtulo 6
Conclusoes
Neste capıtulo sao apresentadas as conclusoes do projecto e consideracoes finais
relativamente a tecnologia estudada
61 Conclusoes
O rapido desenvolvimento tecnologico faz prever que a disponibilidade de ligacao
a Internet seja cada vez mais facil e mais rapido mas vao continuar a existir lugares
onde o acesso e limitado e onde as OWA podem desempenhar um papel de relevo
Por outro lado esta tecnologia pode tambem ser utilizada para melhorar o desem-
penho de paginas web com uma necessidade elevada de imagens ou outros recursos
dispendiosos em termos de espaco e foram ate estudados dois exemplos da utilizacao
desta vertente desta tecnologia em 353
Acredita-se que as OWAs vem responder a uma necessidade real por parte das
web applications actuais e que a evolucao que representam se compara a que se
assistiu dos thin-clients para os fat-clients em termos de autonomia do servidor
A capacidade de oferecer conteudos dinamicos no browser independentemente da
existencia de uma ligacao reune as vantagens tıpicas das web applications como
ausencia de instalacao e actualizacoes instantaneas com as vantagens das aplicacoes
de desktop em capacidade de processamento e armazenamento de dados na maquina
local
As tecnologias disponıveis ate a data estudadas no ambito deste projecto que
permitem o desenvolvimento de OWAs e que apresentam maior maturidade sao o
Gears e o Adobe AIR Ambas se apresentam sobre a forma de plugins que necessitam
de uma instalacao extra para poderem ser utilizadas Apesar de esta instalacao ser
55
Conclusoes
apenas necessaria uma vez podera constituir um factor de desencorajamento a sua
adopcao
O HTML 5 uma especificacao abordada neste documento na seccao 34 podera
ser uma alternativa que oferece funcionalidades offline a uma web application sem a
necessidade de qualquer instalacao no entanto esta especificacao ainda nao foi aceite
pelos principais browsers ndash o documento que define o HTML 5 ainda tem o estatuto
de Draft ndash e ainda nao e possıvel antecipar quando e que isto podera acontecer
Um dos problemas que surge frequentemente na implementacao de uma versao
offline para uma web application e a necessidade de sincronizacao de dados Quando
a informacao pode ser alterada por varios utilizadores simultaneamente e necessario
prever os conflitos que daı podem surgir e dotar a aplicacao de uma forma de os
resolver ou alertar o utilizador para a necessidade de alteracao dos dados
Em conclusao todos os objectivos propostos para este projecto foram atingidos
A prova de conceito implementada reflecte de forma clara as possibilidades oferecidas
pela tecnologia OWA e sera utilizado no futuro para compreender a melhor forma
de o implementar de forma definitiva no WOW
56
Referencias
[Ada08] Lucas Adamski Introducing Adobe AIR security model Fevereiro de2008 Disponıvel em httpwwwadobecomdevnetairarticles
introduction_to_air_securityhtml acedido em Marco de 2008
[Ado08] Adobe Adobe AIR 10 Security White Paper 2008 Disponıvel emhttpdownloadmacromediacompubairdocumentation1air_
securitypdf acedido em Marco de 2008
[Alm08] Dion Almaer Gears as a bleeding-edge html 5 implementa-tion March 2008 Disponıvel em httpalmaercomblog
gears-as-a-bleeding-edge-html-5-implementation acedido emMarco de 2008
[BL96] Tim Berners-Lee The world wide web Past present and future Agostode 1996 Disponıvel em httpwwww3orgPeopleBerners-Lee
1996ppfhtml acedido em Abril de 2008
[CDGH08] Mike Chambers Daniel Dura Dragos Georgita and Kevin Hoyt AdobeAIR for JavaScript Developers OrsquoReilly Media 2008 Disponıvel emhttponairadobecomfilesAIRforJSDevPocketGuidepdf ace-dido em Abril de 2008
[Con99] Jim Conallen Modeling Web Application Architectures with UML Junho1999 Disponıvel em httpwwwumlorgcnUMLApplicationpdf
webappspdf acedido em Maio de 2008
[Ent07] Entrust What is a public key information 2007 Disponıvel em http
wwwentrustcompkihtm acedido em Junho de 2008
[Gar05] Jesse James Garret Ajax A new approach to web applicationsFebruary 2005 Disponıvel em httpwwwadaptivepathcomideas
essaysarchives000385php acedido em Marco de 2008
[Greon] Philip Greenspun Philip and Alexrsquos Guide to Web Publishing 2003(last revision) Disponıvel em httpphilipgreenspuncompandaacedido em Junho de 2008
[Gro02a] App Design Group Thick vs thin client comparison 2002 Disponıvelem httpwwwdonjacobsvwcomimagesweekendspecials
Thick-vs-Thinpdf acedido em Junho de 2008
57
REFERENCIAS
[Gro02b] Technical Research Group Thin Client Tecnhology - WhitePaper 2002 Disponıvel em httpwwwpicktrgcompubs
thinclientwhitepaperpdf acedido em Junho de 2008
[Gro08] Miniwatts Marketing Group World internet usage March 2008Disponıvel em httpwwwinternetworldstatscomstatshtm ace-dido em Abril de 2008
[Hic08] Ian Hickson HTML 5 Draft Recommendation 2008 Disponıvelem httpwwwwhatwgorgspecsweb-appscurrent-work ace-dido em Marco de 2008
[Kha] Olga Kharif Top 10 municipal wifi plans Disponıvel em http
imagesbusinessweekcomss0608muni_wifiindex_01htm ace-dido em Marco de 2008
[Lab07] Mozilla Labs Prism Outubro 2007 Disponıvel em httplabs
mozillacom200710prism acedido em Marco de 2008
[Loo06] Chris Loosley Rich Internet ApplicationsDesign MeasurementandManagement Challenges 2006 Disponıvel em httpwwwkeynote
comdocswhitepapersRichInternet_5pdf acedido em Maio de2008
[Mic08] Microsoft Introduction to Occasionally Connected Applications us-ing Sync Services for ADONET 2008 Disponıvel em httpmsdn
microsoftcomen-ussyncbb887608aspx acedido em Junho de2008
[Nao08] Erica Naone Offline web applications Abril 2008 Disponıvelem httpwwwtechnologyreviewcomread_articleaspxch=
specialsectionsampsc=emerging08ampid=20245 acedido emAbril de 2008
[NJN00] Jason Nieh Yang S Jae and Naomi Novik A comparison of thin-clientcomputing architectures 2000 Disponıvel em httpwwwnclcs
columbiaedupublicationscucs-022-00pdf acedido em Maio de2008
[OrsquoR06] Tim OrsquoReilly Web 20 compact definition Trying again Dezembro2006 Disponıvel em httpradaroreillycomarchives200612
web-20-compact-definition-tryihtml acedido em Marco de 2008
[OrsquoR09] Tim OrsquoReilly What is Web 20 Design patterns and business modelsfor the Next Generation of Software 20053009 Disponıvel emhttpwwworeillynetcompubaoreillytimnews200509
30what-is-web-20html acedido em Marco de 2008
[Rus06] Alex Russel Comet Low latency data for the browser March Marco2006 Disponıvel em httpalexdojotoolkitorgp=545 acedidoem Marco de 2008
58
REFERENCIAS
[Sad97] Darleen Sadoski Clientserver software architecturesndashan overviewAgosto 1997 Disponıvel em httpwwwseicmuedustr
descriptionsclientserver_bodyhtml acedido em Junho de2008
[Sch96] George Schussel Clientserver past present and future 1996
[Smi07] Kevin C Smith Css filters - will the browser apply the rule July 2007Disponıvel em httpcentriclecomrefcssfilters acedido emMarco de 2008
[vK08] Anne van Kesteren The XMLHttpRequest Object W3C Work-ing Draft 15 Abril 2008 Disponıvel em httpwwww3orgTR
XMLHttpRequest acedido em Abril de 2008
[Wil06] Greg Wilkins Why ajax comet July Julho 2006 Disponıvel emhttpwwwwebtidecomdownloadswhitePaperWhyAjaxhtml ace-dido em Abril de 2008
59
REFERENCIAS
60
Anexo A
Screenshots
Algumas imagens de aplicacoes que utilizam funcionalidades offline ilustrativasda tecnologia abordada neste documento
Figura A1 Dialogo apresentado ao utilizador na primeira activacao das funcionalidadesoffline no Google Docs amp Spreadsheets
61
Screenshots
Figura A2 Na activacao das funcionalidades offline e tambem oferecida a possibilidadeda criacao de alguns atalhos por exemplo no ambiente de trabalho
Figura A3 O Google Docs mantem a todo o momento a possibilidade de alteracao destasdefinicoes ou da anulacao dos servicos offline para um dado computador
62
Screenshots
Figura A4 Apos a instalacao do Gears qualquer visita ao Remember The Milk despoletauma sincronizacao que ocorre automaticamente e sem necessidade de intervencao por partedo utilizador
Figura A5 Apos completar a sincronizacao de dados mesmo que a ligacao a Internetseja perdida o Remember the Milk continua disponıvel no browser (com excepcao dasfuncionalidades que pela sua natureza exigem uma ligacao como por exemplo partilhade tarefas e envio de convites)
63
ii
Abstract
The main purpose of this project was to study the Offline Web Applications(OWAs) and its implementation in existent web applications With this goal in minda study was conducted to use this technology in WOW an integrated platform forwork orders and work flow management developed by Critical Software over thelast 6 years and implemented a proof of concept which enables the use of a baseset of functionality for this application regardless of the internet connection state
The concept of OWAs is connected with internet technology and allows accessto a website using the browser even if a connection to the internet is not availableThis concept was considered by Technology Review as one of the most importantemerging technologies in the last quarter of 2007 [Nao08] This study conductedover the WOW platform is intended to aid in the comprehension of the problemsand solutions associated to the use and implementation of OWA as well as thebenefits that it brings to the end user
The Internet and Internet technologies are changing the way in which informa-tion is produced distributed and stored New web applications appeared with newcontent creation and edition functionalities and with it the advantage of infor-mation retrieval from any place and time became possible but with the conditionof Internet connection availability With Internet use growing every year [Gro08]content creation is starting to move to this new platform The adoption of web ap-plications for content creation and edition is becoming more popular and it showsa dependency of a connection that is not always present
The OWAs are a way to solve this problem putting on the client side part ofthe information that was traditionally stored on the server and allows it to be seenand manipulated and helps reducing the server load
This document intends to present different ways in which this technology canhelp web applications as we know them improving the their overall performance andgiving them the ability to run on a browser regardless of the Internet connectionavailability
iii
iv
Agradecimentos
A realizacao e os objectivos alcancados neste projecto nao teriam sido possıveissem a colaboracao de inumeras pessoas Agradeco profundamente a todos os quecontribuıram directa ou indirectamente para o seu sucesso
A minha orientadora Professora Teresa Galvao Dias e ao Project ManagerEngenheiro Marcus Neves que me conduziram e acompanharam no desenvolvimentodeste projecto
A toda a equipa do WOW em especial o Pedro Maurıcio Costa e o Fabio Matosque contribuıram para a minha a minha integracao na Critical Software e que sempresouberam responder a todas as minhas questoes
A todos os que constituem a CSW Porto pelo fantastico ambiente de amizadeque me proporcionaram
Aos colegas de curso e a todos os que me auxiliaram na revisao deste documento
Os meus sinceros agradecimentos
Joao Goncalves da Costa
v
vi
Conteudo
1 Introducao 111 Enquadramento 112 Motivacao 213 Ambito 314 Objectivos 315 Estrutura do documento 3
2 Enquadramento do Projecto 521 Evolucao das arquitecturas de software 5
211 Thin-clients 5212 Fat-clients 6213 Arquitecturas cliente-servidor 7
22 Evolucao na Internet 8221 Paginas web estaticas 9222 Paginas web interactivas e paginas web dinamicas 9223 Web 20 e Ajax 11
23 Offline Web Applications 1324 Comparacao 13
3 Estado da arte 1731 Gears 17
311 Arquitectura 17312 Goggle Gears em dispositivos moveis 20
32 Adobe AIR 20321 Seguranca 22322 Assinatura do codigo 22
33 Mozilla Prism 23331 XML User Interface Language 23332 Prism 25
34 HTML 5 2535 Web applications que usam funcionalidades offline 26
351 Google Reader e Google Docs 26352 Remember the Milk 27353 MySpace e WordPresscom 27
36 Escolha da tecnologia 28
vii
CONTEUDO
4 Desenvolvimento 3341 Como ficar offline 33
411 Funcionalidades disponıveis em modo offline 3442 Modos de execucao 35
421 Modo ldquoutilizador deciderdquo 36422 Modo aplicacao decide 36423 Modo ldquoaplicacao assume o estado offlinerdquo 37
43 Sincronizacao de dados 38431 Quando sincronizar 39
44 WOW 4045 Visao geral sobre a arquitectura do WOW 4146 WOW Offline 42
461 Modo ldquoaplicacao deciderdquo com deteccao automatica da ligacao 43462 Implementacao do modo ldquoutilizador deciderdquo 45463 Especificacao do modo ldquoaplicacao assume o estado offlinerdquo 48
5 Resultados e Futuros Desenvolvimentos 5151 Resultados Obtidos 5152 Trabalho Futuro 52
6 Conclusoes 5561 Conclusoes 55
Referencias 59
A Screenshots 61
viii
Lista de Figuras
21 Arquitectura de um sistema thin-client em duas camadas (a esquerda)e em tres camadas (a direita) Note-se a inclusao do servidor (main-frame) na definicao das camadas desta arquitectura devido a fortedependencia cliente-servidor 9
22 Arquitectura de um fat-client em duas camadas (a esquerda) e emtres camadas (a direita) 10
23 Comparacao do modelo de web aplications sıncrono paginas estaticase interactivas abordados nas seccoes 221 e 222 com o modelo deweb applications Ajax (assıncrono) abordado na seccao 223 Figuraadaptada de http www adaptivepath com 15
31 Esquema UML do processo efectuado pelos recursos do Gears do tipoManagedResourceStore para a actualizacao dos conteudos definidosno ficheiro manifesto 29
41 Exemplo de uma arquitectura de uma web application sem uma ca-mada de abstraccao de dados Figura adaptada de http gears
google com 33
42 Exemplo de uma arquitectura de uma web application com uma ca-mada de abstraccao de dados Figura adaptada de http gears
google com 34
43 Exemplo de uma arquitectura de uma web application com uma ca-mada de abstraccao de dados e um data switch Figura adaptada dehttp gears google com 35
44 Esquema grafico ilustrando uma OWA executando no browser uti-lizando um modo de execucao do tipo ldquoaplicacao deciderdquo com de-teccao automatica do estado da ligacao via pedidos Ajax assıncronosa cada cinco segundos 37
45 Detalhe de um conjunto possıvel de estados e respectivas transicoespara uma dada ordem de trabalho no WOW desde a sua submissaono sistema ate a sua conclusao em fecho ou cancelamento Esta figurarepresenta apenas um exemplo ja que o mapa de estados para umaordem de trabalho e dinamico e pode ser alterado por um admin-istrador Figura retirada de uma brochura promocional do WOWCritical Software SA 41
ix
LISTA DE FIGURAS
46 A pagina inicial do WOW apresenta um resumo das ultimas ordensde trabalho enviadas e recebidas Na imagem pode-se observar atransicao do estado online para offline 44
47 Ilustracao do funcionamento do Gears numa web application que uti-liza um motor Ajax Os pedidos HTTP ou HTTPS podem ser inter-ceptados e tratados localmente ou podem ser feitos a uma maquinaremota consoante se verificarem ou nao as condicoes expressas noponto 311 E representado um acesso a uma base de dados local(fornecida pelo Gears) mas a sua utilizacao e opcional 45
48 Neste exemplo do modo ldquoaplicacao deciderdquo o teste da ligacao e feitoe feito a cada cinco segundos O resultado deste teste nao reflectesempre o estado real da aplicacao podendo levar a aplicacao a tercomportamentos indesejaveis Na figura assinala-se um perıodo detempo no qual a representacao interna do estado da ligacao nao cor-responde a realidade 46
49 Pagina de visualizacao do detalhe de uma ordem de trabalho 47410 Esquema UML que expressa os casos de uso do WOW Offline no
modo ldquoutilizador deciderdquo 48411 Esquema UML que expressa os casos de uso do WOW Offline no
modo ldquoutilizador deciderdquo 49412 Esquema UML que expressa o acto de recolha de dados em modo
online e offline recorrendo ao servidor (modo online) e ao sistemade armazenamento de dados local fornecido pelo Gears (modo offline) 50
A1 Dialogo apresentado ao utilizador na primeira activacao das funcional-idades offline no Google Docs amp Spreadsheets 61
A2 Na activacao das funcionalidades offline e tambem oferecida a possi-bilidade da criacao de alguns atalhos por exemplo no ambiente detrabalho 62
A3 O Google Docs mantem a todo o momento a possibilidade de alteracaodestas definicoes ou da anulacao dos servicos offline para um dadocomputador 62
A4 Apos a instalacao do Gears qualquer visita ao Remember The Milkdespoleta uma sincronizacao que ocorre automaticamente e sem ne-cessidade de intervencao por parte do utilizador 63
A5 Apos completar a sincronizacao de dados mesmo que a ligacao aInternet seja perdida o Remember the Milk continua disponıvel nobrowser (com excepcao das funcionalidades que pela sua naturezaexigem uma ligacao como por exemplo partilha de tarefas e enviode convites) 63
x
Lista de Tabelas
21 Comparacao entre thin-clients e fat-clients 7
31 Comparacao das funcionalidades oferecidas pelo Adobe AIR para asplataformas web e desktop 30
32 Resumo da utilizacao de tecnologias OWA em algumas web applica-tions consideradas na analise do estado da arte 31
xi
LISTA DE TABELAS
xii
Glossario
fat-client Cliente que nao depende totalmente de umservidor central para as suas actividadesde processamento e possui frequentementedispositivos de armazenamento de dados
6ndash8
thin-client Cliente que depende de um servidor centralpara as suas actividades de processamento
5ndash8
web application Sistema web (servidor rede HTTPbrowser) onde accoes do utilizador(navegacao e introducao de informacao)afectam o estado logico da aplicacao
i iii1ndash311ndash1517ndash1921ndash232728 3336ndash3842 5556
API Application Programming Interface 10 1718 2326 28
ASP Linguagem interpretada pelo servidorque permite a criacao de paginas webdinamicas Desenvolvida pela Microsoft
11
BSD Berkeley Software Distribution 28
CSS Cascading Style Sheets 12 2021 2324 46
DHTML Dynamic HyperText Transfer Protocol 24DOM Document Object Model 10 12
20 2324
DTD Document Type Definition 24
xiii
Glossario
ECMAScript Padrao de linguagem de programacaodefinido pela Ecma International que orig-inou o JavaScript e o JScript
24
Flash Conteudo interactivo de um ficheiro emformato SWF E desenvolvido pela Adobee visualizado atraves do Adobe FlashPlayer
21
Flex Framework baseada em XML e Action-Script desenvolvida pela Adobe para a pro-gramacao de Rich Internet Applications(RIA)
21
GPL GNU General Public License 23
HTML HyperText Markup Language 1 10ndash12 2124ndash2649
HTTP HyperText Transfer Protocol 2 26
JMS E uma API em Java que permite a troca demensagens entre componentes de software
42
JSON JavaScript Object Notation permite atroca de dados codificados num formatode texto de simples leitura
12 1828 34
LGPL GNU Lesser General Public License 23
Mozilla Prism Browser simplificado e ldquointerpretadorrdquo deeXtensible User Interface Language (XUL)(tambem designado por XULRunner) queacolhe web applications sem a interfacegrafica habitual de um browser
25
MPL Mozilla Public License 23
OCA Occasionally Connected Application 39OWA Offline Web Application i iii
2ndash515 1725 2628 3133 3651 5255 56
PDF Portable Document Format 21
xiv
Glossario
PHP Linguagem interpretada pelo servidorque permite a criacao de paginas webdinamicas mas que pode tambem ser in-vocada a partir da linha de comandos
11
pagina web estatica Pagina web que devolve sempre a mesmaresposta a todos os pedidos para todos osutilizadores e em qualquer contexto
5 9
RIA Rich Internet Applications web appli-cations que apresentam funcionalidadessemelhantes as desktop applications masque mantem a informacao no lado do servi-dor
5 1520 28
RSS Really Simple Syndication 27
SLA Service Level Agreement 40SQLite Segundo a definicao oficial SQLite is a
software library that implements a self-contained serverless zero-configurationtransactional SQL database engine
17
SSB Site Specific Browser 25SSL Secure Sockets Layer 22SWF ShockWave Flash 21
URL Uniform Resource Locator 18
VPN Virtual Private Network 38
WOW Work Orders Web Plataforma de gestaode ordens de trabalho e do seu fluxo de-senvolvida pela Critical Software SA
i iii28 3340ndash434551ndash5356
WWW World Wide Web 11 1214
XBL eXtensible Binding Language 24XHTML eXtensible HyperText Markup Language 12XML eXtensible Markup Language 11 12
23 2428
XSLT eXtensible Stylesheet Language Transfor-mation
12
XUL eXtensible User Interface Language xiv23ndash25
xv
Glossario
xvi
Capıtulo 1
Introducao
Neste capıtulo enquadra-se o tema do projecto introduzindo alguns dos conceitos
nos quais se baseia Apresentam-se as motivacoes ambito objectivos e a estrutura
deste documento
11 Enquadramento
A Internet foi originalmente concebida para ser um espaco de partilha de in-
formacao onde pessoas (atraves de maquinas) pudessem comunicar Na sua origem
as paginas eram estaticas constituıdas por texto formatado em HyperText Markup
Language (HTML) e ligadas entre si [BL96] Hoje encontramos conteudos cada vez
mais complexos e dinamicos incluindo som vıdeo ou streams multimedia [Loo06] e
em 2005 foi introduzido por [OrsquoR09] o termo Web 20
De acordo com [Greon] um website pode pertencer a uma ou varias das seguintes
categorias
bull Documento ndash um website essencialmente estatico onde alteracoes a uma
parte do conteudo nao tem implicacoes no seu comportamento
bull Base de dados ndash um directorio de informacao organizada em categorias
bull Aplicacao ndash um website dinamico que utiliza uma linguagem executada ou
interpretada do lado do servidor e que processa as accoes ou informacao in-
troduzida pelo utilizador para fornecer um servico ou nova informacao
A ultima destas categorias constitui aquilo que e normalmente designado por
web application O conceito utilizado ao longo deste documento e o mesmo que
o introduzido por Jim Coallen em [Con99] que define web application como um
1
Introducao
sistema web (servidor rede HyperText Transfer Protocol (HTTP) browser) onde
accoes do utilizador (navegacao e introducao de informacao) afectam o estado logico
da aplicacao A sua definicao tenta estabelecer que uma web application e um
sistema de software com estado de negocio1 e que a sua interface de interaccao com
o utilizador e distribuıdo atraves de um sistema web
12 Motivacao
A quantidade de informacao que e produzida e armazenada com recurso a es-
tas web applications disponıveis online tais como e-mail blogues ou mesmo docu-
mentacao tornam por vezes a disponibilidade de ligacao uma condicao necessaria
a produtividade e como consequencia desta barreira muitos potenciais utilizadores
opoem-se a adopcao de produtos web em detrimento das tradicionais desktop appli-
cations
Assegurar o acesso a uma ligacao de Internet e hoje muito mais facil A Internet
movel e ja uma realidade e encontra-se amplamente divulgada mas continuam a
existir diversas situacoes nas quais os utilizadores estao privados de uma ligacao
a Internet tais como uma viagem de metro ou de aviao ou quando se encontram
deslocados do seu paıs de origem e nao possuem nenhum plano de subscricao
Uma OWA consiste numa web application que para alem de manter todas as
caracterısticas anteriores se mantem disponıvel mesmo na ausencia de uma ligacao
a Internet e surge como uma tentativa de estreitar as barreiras existentes entre a
web e o desktop Isto significa que devera existir um mecanismo capaz de assegurar
a manutencao do estado logico da aplicacao quando a ligacao com o servidor e
quebrada permitindo ao utilizador continuar a utilizar a aplicacao e que sera capaz
de informar o servidor do estado em que a aplicacao se encontra quando a ligacao for
reposta A principal vantagem que advem desta possibilidade e evidente eliminar
a necessidade da existencia de uma ligacao a Internet para que a aplicacao possa ser
utilizada
Por outro lado a vontade de integracao de funcionalidades tıpicas das desktop
applications nas web applications foi um dos principais factores que impulsionou o
desenvolvimento deste conceito uma vez que obrigou a uma reflexao ldquopara alem
do browserrdquo e a uma adaptacao das arquitecturas existentes que permitisse ou o
acesso a funcionalidades disponibilizadas pelo sistema operativo ou pelo menos a
funcionalidades semelhantes Pretende-se com esta aproximacao tornar possıveis
interaccoes entre o desktop e o browser tais como arrastar um ficheiro para um
formulario web de upload de conteudos melhor suporte para o historico do clipboard
ou ainda o acesso ao sistema de ficheiros local Atingir estes objectivos reflecte-se
1NT business state
2
Introducao
num novo paradigma que reune as vantagens das web applications tais como os
updates instantaneos ou o facto de nao ser necessaria nenhuma instalacao e das
desktop applications como por exemplo persistencia no armazenamento de dados
acesso a funcionalidades do sistema operativo ou integracao e interaccao com outras
aplicacoes sejam elas web applications ou desktop applications
13 Ambito
Este projecto foi realizado na Critical Software SA no ambito do Mestrado
Integrado em Engenharia Informatica e Computacao (MIEIC) da Faculdade de En-
genharia da Universidade do Porto (FEUP) entre os meses de Fevereiro e Julho de
2008
14 Objectivos
Sao objectivos deste projecto
1 Estudar e documentar o tema das OWAs acompanhando os ultimos desenvolvi-
mentos nesta materia
2 Analisar o estado da arte fazendo uma analise crıtica e objectiva sobre as
diversas metodologias existentes
3 Implementar uma prova de conceito que permita a execucao offline de uma
web application documentando todo o processo
4 Estudar a possibilidade de permitir interaccao com a aplicacao (insercoes e
alteracoes aos dados) em modo offline
Em resumo o objectivo deste projecto foi estudar documentar e implementar
uma prova de conceito relacionada com o tema Offline Web Applications (OWA)
Este tema embora nao seja totalmente novo ganhou destaque ao longo do ano de
2007 com o surgimento de diversas ferramentas que se destinam a aproximar web
applications das desktop applications
15 Estrutura do documento
Este documento esta organizado em diferentes seccoes apresentando o projecto
numa sequencia logica organizada da seguinte forma
No capıtulo 1 faz-se uma breve apresentacao do conceito OWAs e do contexto em
que surge Apresenta-se tambem a estrutura do documento e definem-se os
termos e acronimos utilizados
3
Introducao
No capıtulo 2 faz-se uma descricao da evolucao das tecnologias que antecedem as
OWAs e das vantagens e desvantagens de cada uma como forma de enquadra-
mento
No capıtulo 3 analisa-se o estado da arte nesta materia Introduzem-se diversas
tecnologias directamente relacionadas com o tema deste projecto exemplos de
aplicacoes que as usam e as razoes que fundamentam as escolhas de tecnologias
efectuadas
O capıtulo 4 contem o desenvolvimento do projecto Analisa-se a plataforma
WOW de gestao integrada de ordens de trabalho a tecnologia escolhida e
a forma como foi utilizada para implementar a capacidade de execucao offline
O capıtulo 5 descreve os resultado obtidos comparando-os com as expectativas
iniciais do projecto e apresenta desenvolvimentos futuros e possibilidades de
continuacaoaplicacao do conhecimento adquirido
No capıtulo 6 apresentam-se as conclusoes
4
Capıtulo 2
Enquadramento do Projecto
Neste capıtulo apresenta-se um breve resumo da evolucao das arquitecturas de
software cliente-servidor e a forma como estas se comparam a evolucao da Inter-
net procurando estabelecer uma analogia entre o percurso de ambas as tecnolo-
gias Compara-se o comportamento e arquitectura dos thin-clients as paginas web
estaticas a evolucao dos fat-clients as paginas interactivas Web 20 e Ajax e
defende-se que as OWA constituem um proximo passo logico e evolutivo aproxi-
mando a web do desktop Referem-se ainda os principais factores que justificam a
importancia das OWAs e a estreita relacao que tem com as Rich Internet Application
(RIA)s
21 Evolucao das arquitecturas de software
Os termos thin-client e fat-client sao utilizados quer para descrever arquitecturas
logicas (de software) quer para descrever arquitecturas fısicas (de hardware) Neste
capıtulo excepto quando seja dada indicacao em contrario estes termos referem-se
sempre a uma arquitectura logica
Adicionalmente quando se trata de arquitecturas cliente-servidor pode-se estu-
dar a arquitectura desenvolvida do sistema como um todo da arquitectura do servi-
dor ou da arquitectura do cliente Para evitar equıvocos em especial na seccao 213
especifica-se em cada caso qual o sistema estudado
211 Thin-clients
Um thin-client e um computador cliente ou software cliente que no contexto
de uma arquitectura cliente-servidor depende de um servidor central para as suas
5
Enquadramento do Projecto
actividades de processamento e proporciona um canal de entrada e saıda de in-
formacao entre o utilizador e o servidor remoto Este termo quando aplicado a
hardware refere-se habitualmente a um computador que se destina a ser utilizado
como cliente de rede sem armazenamento local e com capacidade de processamento
reduzida [Gro02b] mas o conceito que aqui se analisa refere-se a uma arquitectura
de software que remonta ao inıcio das aplicacoes cliente-servidor
No inıcio da historia da computacao terminais ligavam-se directamente a main-
frames responsaveis por todo o processamento Nesta arquitectura era necessario
desenvolver duas aplicacoes distintas uma aplicacao central no servidor (main-
frame) responsavel pela gestao de toda a informacao e por todas as operacoes de
comunicacao e uma aplicacao de visualizacao instalada no cliente (terminal) O
papel destes terminais era apenas disponibilizar ao utilizador um meio de comu-
nicacao (entrada e saıda) e apresentacao dos resultados do servidor Nao tinham
um papel activo no calculo nem na logica de negocio e frequentemente nao tinham
tambem nenhum mecanismo de armazenamento de dados
Como vantagens esta arquitectura apresenta uma reduzida necessidade de con-
figuracao e manutencao do lado do cliente Uma vez que o centro do processamento
e manipulacao de dados ocorre no servidor existe tambem uma centralizacao da
informacao [NJN00] que introduz um ponto crıtico de falha1 Actualizacoes e novas
funcionalidades sao faceis de distribuir uma vez que requerem apenas alteracoes no
servidor [Gro02a]
212 Fat-clients
Contrastando com os thin-clients nesta arquitectura os clientes implementam
ja uma parte da logica de negocio e sao responsaveis pelo processamento de dados
Estes fat-clients vieram responder a necessidade crescente de aplicacoes com um
nıvel de interactividade e capacidade de configuracao maior que as oferecidas pela
arquitectura thin-client descrita na seccao 211 Apesar de manterem a sua de-
pendencia do servidor podem tambem ser executados sem uma conexao activa uma
vez que dispoe de armazenamento de dados local o que lhes confere a capacidade
de persistencia de dados e do estado de execucao entre cada sessao
Foi disponibilizando este controlo sobre o estado da aplicacao bem como acesso
a recursos locais (por exemplo sistema de ficheiros e perifericos) que surgiram as
primeiras verdadeiras desktop applications No entanto cada cliente tinha que ser
separadamente instalado no computador pessoal de cada utilizador que pretendesse
utilizar ou interagir com a aplicacao e uma actualizacao ao servidor implicava in-
variavelmente uma actualizacao manual tambem no cliente Uma vez que nem todos
1NT single point of failure
6
Enquadramento do Projecto
Thin-clients Fat-clientsNao toma parte no processamento dedados nem possui acesso ao sistema deficheiros
Participa activamente no processa-mento de dados recorrendo ao sis-tema de armazenamento local para ar-mazenamento de dados
Nao mantem registo do estado logicoda aplicacao entre duas sessoes de uti-lizacao
O acesso ao armazenamento localpermite-lhe manter registo do estadologico da aplicacao entre duas sessoes
O thin-client nao necessita de qualquerinstalacao estando ldquopronto a utilizarrdquo
E geralmente necessario instalar aaplicacao para poder interagir com oservidor
Qualquer update no servidor reflecte-seimediatamente por todos os clientes
Embora a aplicacao cliente possa aler-tar para existencia de novas versoes asactualizacoes tem que ser manualmenteinstalados pelo cliente
O software do cliente destina-se apenasa apresentacao de dados e comunicacaocom o servidor sendo portanto de sim-ples implementacao
Como o software do cliente toma parteactiva no processamento de dadosa sua implementacao requer cuidadosadicionais
Grande mobilidade uma vez que todaa informacao e mantida no servidor
Parte da informacao podera estar ape-nas do lado cliente pelo que existemalgumas restricoes a sua mobilidade
Tabela 21 Comparacao entre thin-clients e fat-clients
os utilizadores actualizam regularmente as suas aplicacoes o servidor tem que estar
preparado para lidar com versoes antigas2 ou descontinuar os seus servicos a uma
parte da sua comunidade de utilizadores ate que estes actualizem os seus sistemas
Como os utilizadores passam a utilizar os seus recursos locais para armazenamento
de dados as alteracoes que nao sejam sincronizadas com o servidor estao apenas
disponıveis nos seus computadores pessoais o que introduz uma restricao a mobili-
dade
Pode-se afirmar que as vantagens dos thin-clients sao as desvantagens dos fat-
clients e que as vantagens dos fat-clients sao as vantagens dos thin-clients tal como
se ilustra na Tabela 21
213 Arquitecturas cliente-servidor
Introduzidos os termos thin-client e fat-client interessa reafirmar que ambos
podem ser vistos como arquitecturas cliente-servidor Um cliente define-se como
um solicitador de servicos e um servidor como um prestador de servicos tal como
definido por [Sch96] e [Sad97]
2NT backward compatibility
7
Enquadramento do Projecto
As arquitecturas cliente-servidor sao categorizadas pela modularizacao com que
sao desenhadas sendo consideradas as seguintes camadas
1 Interface grafica (front-end) atraves da qual os utilizadores interagem com
a aplicacao Quando este modulo e implementado separadamente dos outros
dois constitui uma aplicacao thin-client por si so uma vez que nao implementa
regras de negocio (embora possa definir validacoes de formularios de insercao de
dados por exemplo) A informacao introduzida pelo utilizador e enviada para
o servidor que processa o seu pedido e retorna uma resposta Este processo
repete-se ate que o utilizador atinja o seu objectivo ou se desligue do sistema
2 A logica de negocio tambem designada por camada intermedia que imple-
menta as regras de aceitacao e validacao de todos os dados introduzidos pelo
utilizador E tambem a plataforma de comunicacao que une a camada superior
de visualizacao com a camada de acesso a dados
3 A camada de dados inclui quer o sistema de persistencia de dados onde sao
armazenados os dados relevantes como tambem os mecanismos necessarios
para a sua pesquisa seleccao e alteracao
Os thin-clients quando observados no seu conjunto de cliente e servidor podem
ser vistos quer como sistemas de duas camadas quer como sistemas de tres camadas
dependendo apenas da forma como o servidor for implementado No caso de na
implementacao do servidor nao se distinguir a camada de acesso a dados da camada
da logica de negocio sao designados por sistemas de duas camadas Caso seja feita
esta distincao sao designados por sistemas de tres camadas Ambos os casos sao
ilustrados na Figura 21
Historicamente os fat-clients eram implementados numa arquitectura em duas
camadas Possuıam apenas um modulo de visualizacao de dados designado por
camada de interface e um modulo que implementava toda a logica de negocio e
regras de acesso a base de dados No entanto com a introducao de ligacoes mais
rapidas e de computadores pessoais com maior capacidade de processamento e so-
bretudo devido a complexidade crescente das aplicacoes a logica de negocio e a
camada de acesso a dados tornaram-se independentes Este modelo e designado por
arquitectura em tres camadas e e ilustrado na Figura 22
22 Evolucao na Internet
Ao analisar a evolucao das arquitecturas das aplicacoes desenvolvidas para a
Internet podemos encontrar um paralelismo com a historia da arquitectura de soft-
ware
8
Enquadramento do Projecto
Figura 21 Arquitectura de um sistema thin-client em duas camadas (a esquerda) e emtres camadas (a direita) Note-se a inclusao do servidor (mainframe) na definicao dascamadas desta arquitectura devido a forte dependencia cliente-servidor
221 Paginas web estaticas
Uma pagina web estatica devolve sempre a mesma resposta a todos os pedidos
para todos os utilizadores e em qualquer contexto utilizando o hipertexto como
forma de ligacao entre diversas paginas estaticas
A informacao e armazenada num servidor e o papel do cliente e apenas a apre-
sentacao da informacao Esta forma de disponibilizacao de informacao pode assim
ser comparada com os thin-clients descritos na seccao 211 o utilizador acede a
um website estatico para visualizar informacao sem que o cliente tome parte no
processamento A unica diferenca e que no caso da web estatica a informacao ap-
resentada e sempre a mesma enquanto que nos thin-clients era frequente existir a
possibilidade de insercao de dados no cliente e apos o seu processamento servidor
nova informacao poderia ser apresentada O hipertexto e utilizado para ligar as
paginas entre si numa rede de conteudos relacionados e a navegacao sıncrona era
feita atraves de cliques do rato a cada clique uma nova pagina era apresentada
Este modelo sıncrono e ilustrado na Figura 23
222 Paginas web interactivas e paginas web dinamicas
O JavaScript e uma linguagem interpretada de scripting que tem os browsers
como principal ambiente de acolhimento Os browsers utilizam uma Application
9
Enquadramento do Projecto
Figura 22 Arquitectura de um fat-client em duas camadas (a esquerda) e em tres camadas(a direita)
Programming Interface (API) publica para criar ldquoobjectosrdquo responsaveis por reflectir
e disponibilizar o Document Object Model (DOM) para o motor de JavaScript
A utilizacao mais frequente desta linguagem e a escrita de funcoes que sao em-
bebidas ou incluıdas em paginas web e que interagem com o DOM Uma vez que o
JavaScript e executado localmente (na maquina do cliente e nao no servidor) e capaz
de responder rapidamente a accoes do utilizador tornando a execucao de aplicacoes
no browser mais fluıdas o JavaScript pode tambem detectar accoes do utilizador
que o HTML nao pode tal como o pressionar de uma tecla
Em Dezembro de 1995 a Netscape Communications adicionou suporte para o
JavaScript no browser Netscape Navigator3 e em Agosto de 1996 o browser Internet
Explorer4 da Microsoft passou a tambem a suportar uma versao semelhante desta
linguagem (hoje todos os principais browsers suportam esta tecnologia)
Esta inovacao permitiu tornar os websites mais interactivos mas a sua utilizacao
esteve confinada apenas a este proposito durante um longo perıodo As paginas
passaram a responder activamente a accoes do utilizador (sendo uma das utilizacoes
3Netscape Communications ndash httpbrowsernetscapecom4Microsoft Internet Explorer ndash httpwwwmicrosoftcomwindowsproductswinfamilyie
10
Enquadramento do Projecto
mais vulgares a validacao de formularios) mas continuaram essencialmente estaticas
O JavaScript ainda nao era nesta altura utilizado para processar dados
Tambem nesta altura (1995ndash96) surgiram linguagens server-side como o PHP
Hypertext Preprocessor (PHP) e Active Server Pages (ASP) e o servidor passou a ter
um processamento de dados introduzidos pelo utilizador mais activo Generalizaram-
se as paginas dinamicas capazes de responder a insercao de dados ou outros pedidos
determinados por accoes do utilizador As paginas tornaram-se aplicacoes web ap-
plications
Uma definicao tradicional de web application e um conjunto de paginas web
logicamente agrupadas e geridas por uma unica entidade que tem como pontos de
entrada formularios de insercao de dados (web forms) Uma web application nao e
mais do que uma aplicacao que e acedida atraves de um browser Tem geralmente
uma arquitectura logica em tres (interface logica de negocio e camada de dados)
camadas e estao armazenadas num servidor
Ha dois tipos de web applications
bull Orientadas a apresentacao Sao web applications que geram paginas web in-
teractivas constituıdas por varios tipos de linguagens de anotacao (por exem-
plo HTML eXtensible Markup Language (XML)) e que apresentam conteudo
dinamico como resposta a pedidos efectuados pelo utilizador
bull Orientadas aos servicos Uma web application orientada aos servicos imple-
menta o ponto de acesso para um ou mais de um web service Sao geralmente
clientes de service oriented web applications
Uma vantagem significativa de implementar uma web application de forma a
suportar as funcionalidades padrao dos browsers e que estas terao o mesmo com-
portamento independentemente da plataforma e do browser a partir do qual serao
acedidas No entanto diferentes implementacoes de browsers devido a diferentes
interpretacoes dos padroes definidos tornam por vezes esta tarefa um pouco mais
complicada existindo inclusivamente na web guioes de compatibilidade para os difer-
entes browsers como [Smi07]
223 Web 20 e Ajax
O termo web 20 descreve uma tendencia de utilizacao e de design observada
na World Wide Web (WWW) com o objectivo de melhorar a criatividade partilha
de informacao e principalmente a colaboracao entre utilizadores Estes conceitos
levaram ao desenvolvimento e evolucao de comunidades online tais como redes so-
ciais wikis e blogues
11
Enquadramento do Projecto
O termo tornou-se mais conhecido apos a primeira conferencia OrsquoReilly Media
Web 20 em 2004 e apesar de sugerir uma nova versao da WWW nao se refere a
qualquer evolucao tecnologica mas apenas a alteracoes a forma como os utilizadores
se servem da web De acordo com Tim OrsquoReilly [OrsquoR06] ldquoWeb 20 e uma revolucao
na industria do software causada pela adopcao da web como uma plataforma e pela
tentativa de entendimento das regras para o sucesso nesta nova plataformardquo
O desenvolvimento da Web 20 serve-se muitas vezes de um outro conceito Ajax
O conceito que hoje conhecemos como Ajax muitas vezes incorrectamente de-
scrito como uma tecnologia foi originalmente criado para permitir o desenvolvimento
de web applications que se assemelhassem ainda mais a aplicacoes de desktop Este
conceito foi melhor descrito por [Gar05] como um conjunto de varias tecnologias
que podem ser utilizadas para melhorar a experiencia do utilizador de uma dada
web application introduzindo a capacidade assıncrona de envio de pedidos ou da
recepcao assıncrona de respostas As tecnologias mais frequentemente envolvidas
sao
bull eXtensible HyperText Markup Language (XHTML) e Cascading Style Sheets
(CSS) padrao para a apresentacao
bull interaccao dinamica atraves do DOM
bull troca e manipulacao de dados utilizando XML e eXtensible Stylesheet Lan-
guage Transformation (XSLT) ou JavaScript Object Notation (JSON)
bull pedidos assıncronos utilizando XMLHttpRequest [vK08]
bull JavaScript utilizado para integrar todas estas tecnologias
E importante frisar que o Ajax nao e um produto nem uma tecnologia E um
termo que descreve a utilizacao de um conjunto de tecnologias para o desenvolvi-
mento de web applications com um elevado grau de interactividade Comparativa-
mente as web applications tradicionais o Ajax introduz uma camada de visualizacao
diferente em tres importantes pontos
1 Do lado do cliente existe um motor que serve de intermediario entre a interface
da aplicacao e o servidor
2 A actividade do utilizador despoleta chamadas JavaScript em vez de um pedido
de pagina directamente ao servidor
3 Informacao codificada em XML em vez de paginas HTML e trocada entre o
servidor e o cliente
12
Enquadramento do Projecto
Isto significa que as paginas que utilizam Ajax contem um motor do lado do
cliente composto por um conjunto de funcoes JavaScript responsavel pela comu-
nicacao com o servidor e por actualizar a interface com o resultado dessa mesma
comunicacao
Na Figura 23 ilustra-se a natureza assıncrona do Ajax quando comparada com
as web applications tradicionais Como se pode observar adicionando um mecan-
ismo Ajax a uma web application eliminam-se diversos tempos de espera associados
a comunicacoes com o servidor uma vez que a interface nao fica ldquobloqueadardquo a es-
pera da resposta Obtem-se assim aplicacoes com um comportamento mais fluido
eliminando tempos de espera entre cada ldquocliquerdquo e melhorando a experiencia do
utilizador
23 Offline Web Applications
A informacao grafica (bem como folhas de estilo e scripts) tais como as ima-
gens que constituem o visual de uma web application e ja tratada de forma especial
pelos cada vez mais avancados sistemas de cache (armazenamento temporario) dos
browsers Mas estes nao sao ainda capazes de guardar conteudo criado pelo uti-
lizador nem de apresentar informacao independentemente do estado da ligacao
Numa altura onde se fala de servicos de Internet wireless municipalizados [Kha]
comunicacoes 3G e ligacoes de banda larga a alta velocidade a ligacao a rede global
continua a nao estar permanentemente disponıvel para os utilizadores Na WWW
encontra-se uma importante parte da informacao e das aplicacoes utilizadas para
criar e editar conteudos Por vezes informacao vital para a produtividade pode
desaparecer subitamente do mapa de acesso de um utilizador quando este entra no
metro num aviao ou mesmo quando se desloca para uma cidade ou paıs diferente
do habitual onde nao subscreve um plano de acesso que lhe garanta a ligacao
Permitir o acesso offline a estes recursos assume assim a sua importancia porque
permitira estender o alcance da informacao a locais onde nunca esteve antes e per-
mitira tambem melhorar o desempenho das web applications colocando informacao
mais perto dos utilizadores reduzindo a transferencia de dados apenas ao essencial
24 Comparacao
Nas evolucoes descritas neste capıtulo 2 pode-se observar que existe um par-
alelismo entre a evolucao das arquitecturas tradicionais cliente-servidor e a evolucao
a que se assiste na web O comportamento e arquitectura dos thin-clients assemelha-
se ao das paginas estaticas no sentido em que o browser nao toma parte em qualquer
13
Enquadramento do Projecto
processamento e serve apenas como uma plataforma de interaccao com o servidor
tal como os clientes descritos na seccao 211
A sua proxima evolucao os fat-clients trouxeram parte da capacidade de pro-
cessamento para o lado do cliente Na web foi tambem esta a inovacao tecnologica
a que se assistiu com a evolucao das tecnologias que permitiram a criacao de ver-
dadeiras aplicacoes e com a introducao do Javascript no browser dando ao cliente
a capacidade de processamento de dados A necessidade da separacao do codigo
em camadas logicas advem da crescente complexidade das web applications Esta
pratica permite entre outras coisas melhorar o processo de desenvolvimento e a
capacidade de manutencao de uma aplicacao
Os fat-clients tem tambem a capacidade de armazenamento de dados o que
permite a persistencia de informacoes entre duas sessoes e que algumas operacoes
sejam executadas sem a necessidade de comunicacao com o servidor Este facto pode
tambem ser uma realidade nas web applications com a adopcao das tecnologias OWA
Neste momento assiste-se a uma utilizacao cada vez maior da web como uma
plataforma de desenvolvimento A capacidade de cooperacao na edicao de conteudos
e a mobilidade proporcionada por esta plataforma sao os principais factores que
alimentam esta mudanca e pela primeira vez as aplicacoes tradicionais tem com-
peticao vinda de web applications A prova do reconhecimento da web como plataforma
de desenvolvimento pode ser retirada da aposta de empresas como a Adobe e Mi-
crosoft que lancaram publicamente ferramentas web complementares a produtos
seus tradicionalmente associados ao desktop ndash Acrobatcom5 e Microsoft Office
Live6 Dotar estas web applications da capacidade de execucao offline significa
aproximar a web e o desktop reunindo ldquoo melhor de dois mundosrdquo
As vantagens da mobilidade possıvel atraves da web a cooperacao na criacao e
edicao de conteudos e a possibilidade de utilizar aplicacoes sempre actualizadas e
sem necessidade de instalacao sao algumas das principais vantagens que promovem
esta mudanca que devido as preocupacoes associadas a usabilidade e experiencia do
utilizador esta fortemente associada ao desenvolvimento de Rich Internet Applica-
tion (RIA)s
5Adobe Acrobatcom httpwwwacrobatcom6Microsoft ndash httpsmallbusinessofficelivecom
14
Enquadramento do Projecto
Figura 23 Comparacao do modelo de web aplications sıncrono paginas estaticas e in-teractivas abordados nas seccoes 221 e 222 com o modelo de web applications Ajax(assıncrono) abordado na seccao 223 Figura adaptada de http www adaptivepath
com
15
Enquadramento do Projecto
16
Capıtulo 3
Estado da arte
Apesar de o conceito das OWAs nao ser absolutamente novo as tecnologias que
o suportam sao recentes Neste capıtulo descrevem-se quatro tecnologias que foram
tidas como principais candidatas para o desenvolvimento deste projecto Descrevem-
se ainda alguns exemplos de web applications que disponibilizam actualmente fun-
cionalidades offline e o processo da escolha da tecnologia a utilizar neste projecto
31 Gears
O Gears1 e uma extensao as funcionalidades do browser introduzido pelo Google
que tem como principal objectivo tornar possıvel a visualizacao de paginas de Inter-
net mesmo sem uma conexao disponıvel Encontra-se disponıvel para as platafor-
mas Windows Macintosh e Linux e oferece uma API de Javascript que permite
a scripts aceder a um mecanismo de armazenamento local baseado numa base de
dados SQLite
311 Arquitectura
Esta ferramenta e constituıda por tres componentes principais
bull LocalServer mdash Intercepta pedidos de paginas web e serve-as localmente
bull Database mdash Uma base de dados relacional construıda sobre SQLite
bull WorkerPool mdash Permite executar operacoes de computacao de uma forma
assıncrona sem afectar a capacidade de resposta e fluidez de execucao da web
application Assemelham-se a processos
1Google Inc ndash Mais informacao em httpgearsgooglecom
17
Estado da arte
LocalServer
O modulo LocalServer e uma cache de Uniform Resource Locators (URLs)
controlada pela web application Quando nao existe uma ligacao a Internet e e
feito um pedido para um URL presente nesta cache o LocalServer intercepta-o e
responde ao pedido localmente a partir do disco rıgido do utilizador A aplicacao
pode utilizar dois tipos diferentes de armazenamento local de URLs
bull ResourceStore ndash serve para capturar URLs utilizando exclusivamente a API
de Javascript disponibilizada para o efeito Uma aplicacao podera criar e
utilizar diversos ResourceStores simultaneamente para capturar ficheiros de
dados que necessitam de ser enderecados por um URL tal como um ficheiro
PDF ou uma imagem
bull ManagedResourceStore ndash serve para capturar um conjunto de URLs que estao
relacionados e que sao declarado num ficheiro de manifesto (especificado em
JSON) e que sao automaticamente actualizados O ManagedResourceStore
permite que o conjunto de recursos necessarios para correr uma web application
seja capturado e mantido actualizado automaticamente
A principal diferenca entre estes dois tipos de armazenamento de URLs e a forma
como sao actualizados os seus conteudos Os conteudos de um ManagedResourceStore
sao actualizados sempre que a versao contida no ficheiro de manifesto for alterada
enquanto que os conteudos de um ResourceStore nunca sao actualizados automati-
camente mas apenas quando for explicitamente ordenado pela aplicacao
O LocalServer e capaz de interceptar e servir localmente pedidos de HTTP e
HTTPS sempre que se reunam as seguintes condicoes
1 O URL encontra-se armazenado num ResourceStore ou ManagedResourceStore
2 O sistema de armazenamento local encontra-se activo (enabled = true) Se
o sistema de armazenamento local tiver o atributo requiredCookie o pedido
devera conter um cookie que lhe corresponda
O LocalServer nao necessita de monitorizar o estado da ligacao para atender aos
pedidos Na verdade sempre que as condicoes previamente enunciadas se verificarem
o LocalServer interceptara os pedidos e independentemente do estado da ligacao
a Internet servi-los-a a partir do disco rıgido local Cabera a aplicacao definir qual
o modo em que pretende executar um pedido (online ou offline) definindo o valor
de verdade da propriedade enabled
18
Estado da arte
Database
O modulo Database permite guardar dados da web application assegurando a
sua persistencia Os dados sao guardados de forma relacional no disco rıgido do uti-
lizador2 de acordo com o modelo de seguranca estabelecido pelo Gears3 significando
que uma aplicacao nao pode aceder a conteudos fora do seu domınio
WorkerPool
Nos web browsers uma operacao pesada de computacao pode tornar a interface
lenta e tornar menos agradavel a experiencia do utilizador O modulo WorkerPool
permite correr operacoes em background sem bloquear a interface com o utilizador
Os scripts executados numa WorkerPool nao activam os mecanismos de seguranca
do browser que mostram a mensagem ldquoA script on this page may be busy or may
have stopped respondingrdquo
O WorkerPool comporta-se como um conjunto de processos em vez de threads
Os Workers nao partilham qualquer estado de execucao o que significa que uma
alteracao a uma variavel num Worker nao afecta em nada a execucao de outro
Worker Alem disso os Workers nao herdam automaticamente nenhum codigo dos
seus pais Cada Worker e membro de um WorkerPool e os Workers podem in-
teragir entre si enviando mensagens em formato de texto ou JSON No entanto ha
tambem algumas limitacoes os Workers nao tem acesso ao DOM e objectos como
window ou document nao se encontram acessıveis Isto e consequencia de os Workers
nao partilharem o estado de execucao Mas tem acesso a todas as funcoes built-in
do Javascript A maioria das funcionalidades do Gears pode tambem ser acedida
atraves de uma variavel global especial definida como googlegearsfactory Para
outras funcionalidades especıficas os Workers podem ldquopedirrdquo a pagina principal para
continuar a execucao atraves do envio de mensagens
Outras funcionalidades
bull HttpRequest ndash Este modulo implementa a especificacao W3C XmlHttpRe-
quest definida em [vK08] tornando-a disponıvel para os workers e para a
pagina principal
bull Timer ndash Este modulo implementa a especificacao de timers tal como descrito
por [Hic08] e torna-os disponıveis para os workers e para a pagina principal
2Consultar httpcodegooglecomapisgearsapi_databasehtmldirectories3Consultar httpcodegooglecomapisgearssecurityhtml
19
Estado da arte
bull Factory ndash Esta classe e utilizada para instanciar todos os outros objectos da
API do Gears atraves do seu metodo create Este metodo pode ser utilizado
com os seguintes parametros
ndash betadatabase
ndash betahttprequest
ndash betalocalserver
ndash betatimer
ndash betaworkerpool
312 Goggle Gears em dispositivos moveis
O Gears esta tambem disponıvel em dispositivos Windows Mobile 5 e 6
Os dispositivos moveis estao pela sua natureza frequentemente desconectados
da Internet Mesmo quando possuem uma ligacao as latencias na transferencia de
dados em redes moveis tornam as aplicacoes pouco fluıdas mas o Gears permite
ultrapassar este obstaculo
O Gears funciona exactamente da mesma forma em dispositivos moveis equipados
com o Windows Mobile 5 e 6 como num computador comum Se uma aplicacao tiver
sido implementado com suporte para o Gears entao tambem estara preparada para
ser executada num dispositivo movel mas as limitacoes dos browsers disponıveis
para dispositivos moveis tem que ser consideradas Isto significa prever as condicoes
que permitam uma boa usabilidade devido aos pequenos ecras destes dispositivos
bem como o seu suporte limitado dos padroes do DOM CSS e JavaScript
32 Adobe AIR
O Adobe AIR4 e um runtime compatıvel com diversos browsers e sistemas opera-
tivos que pretende dar aos programadores a possibilidade de combinar diversas tec-
nologias de producao de conteudos para a Internet no desenvolvimento de Rich Inter-
net Application (RIA)s O Adobe AIR mantem uma relacao com o browser mas es-
tende as suas capacidades e tecnologias permitindo o desenvolvimento de aplicacoes
tambem para o ambiente de trabalho com janelas em tudo semelhantes as do sis-
tema operativo Segundo a Adobe o objectivo e complementar o browser dando
aos utilizadores (mas essencialmente aos programadores e equipas de desenvolvi-
mento) a escolha sobre como distribuir as suas aplicacoes Para este efeito o Adobe
AIR tem uma aproximacao diferente do Gears Em vez de ldquoestenderrdquo o browser
acrescentando-lhe funcionalidades o AIR permite tambem o desenvolvimento de
4Adobe - httpwwwadobecomproductsair
20
Estado da arte
aplicacoes que se destinam a ser executadas fora do ambiente do browser mas uti-
lizando as tecnologias comuns da Internet (por exemplo HTML CSS JavaScript
Flash Flex)[CDGH08]
A utilizacao desta tecnologia permite utilizar o browser ou o proprio runtime
Adobe AIR como plataforma de execucao da aplicacao
Na Tabela 31 faz-se uma comparacao das funcionalidades disponıveis de acordo
consoante se escolha o browser ou o desktop como plataforma base para a aplicacao
Uma vez que as aplicacoes Adobe AIR na plataforma desktop tem um caracter
persistente (sao instaladas no computador do utilizador) o Adobe AIR tem um
modelo de seguranca que se assemelha com o das tradicionais aplicacoes desktop
[Ada08] Este modelo e analisado nas seccoes 321 e 322 O ambiente em que
e executado o browser e restringido a execucao de web applications que podem
ser de varias origens (incluindo de origens anonimas ou sem confianca) O Adobe
AIR proporciona acesso a capacidades como acesso a ficheiros que necessitam da
confianca do utilizador
bull HTML ndash O desenvolvimento de aplicacoes para o Adobe AIR pode ser feito
com recurso a tecnologias de HTML e Ajax comuns utilizando as linguagens
de markup existentes distribuıdas como texto e interpretadas em execucao
(runtime)
bull Flash ndash Outra alternativa sera a utilizacao da linguagem Flash Permite a
renderizacao de graficos vectoriais e audiovıdeo com suporte nativo Utiliza
ActionScript para adicionar maior interactividade com o utilizador
bull Flex ndash O Flex e uma framework open source para o desenvolvimento de RIAs
usando Flash As aplicacoes Flex sao na realidade Flash sendo a principal
diferenca o ambiente de desenvolvimento
Como resultado uma aplicacao AIR podera ser implementada
bull Baseada em Flash ou Flex (aplicacoes cujo conteudo base e em ShockWave
Flash (SWF))
bull Baseada em Flash ou Flex tambem com HTML ou Portable Document Format
(PDF) Aplicacoes cujo conteudo de base e em FlashFlex (SWF) com HTML
(HTML JavaScript CSS) ou conteudo PDF incluıdo
bull Baseada em HTML Aplicacoes cujo conteudo base e em HTML Javascript
CSS
bull Baseada em HTML utilizando tambem FlashFlex ou PDF
21
Estado da arte
Os utilizadores interagem com uma aplicacao AIR da mesma forma que interagem
com outras aplicacoes com janelas nativas do seu sistema operativo O runtime e
instalado uma vez no computador do utilizador e a partir desse momento todas as
aplicacoes AIR terao o mesmo aspecto que qualquer outra aplicacao para o desktop
321 Seguranca
Permitir que uma web application aceda ao disco de armazenamento do utilizador
pode comprometer seriamente a sua seguranca Neste sentido o Adobe AIR tem
suporte para assinaturas digitais (Secure Sockets Layer (SSL)) que podem ser com-
pradas pelas equipas de desenvolvimento que o desejem e cujos certificados serao
apresentados ao utilizador no momento da instalacao Um outro aspecto ainda
relativo a seguranca e o mecanismo de isolamento de cada ambiente (sandbox )
322 Assinatura do codigo
O runtime AIR exige que todas as aplicacoes estejam digitalmente assinadas As
assinaturas digitais de codigo sao um processo que visa garantir a integridade da
aplicacao e a identidade do seu autor no momento da instalacao As equipas de
desenvolvimento podem ldquoassinarrdquo uma aplicacao utilizando um certificado atribuıdo
por uma Entidade Certificadora (Certification Authority) ou atraves de um certifi-
cado individual (self signed certificate) Neste momento o Adobe AIR suporta como
entidades certificadoras a Verisign e a Thawte [Ado08]
O instalador apresenta o nome de quem publica a aplicacao quando o codigo tiver
sido assinado com um certificado que apresente confianca ou que esteja encadeado
com um certificado que tenha ja sido aceite no computador em que se esta a instalar
a aplicacao
As equipas de desenvolvimento podem tambem assinar as aplicacoes com um
certificado auto-atribuıdo (um certificado criado por elas proprias) mas neste caso
o instalador apresentara estas aplicacoes como sendo de uma origem nao verificada
O AIR utiliza a infraestrutura publica de chaves [Ent07] suportada pelo arquivo
local do sistema operativo Para que a origem da aplicacao seja reconhecida o
computador onde a aplicacao AIR esta a ser instalada tem que confiar directamente
no certificado que foi utilizado para assinar a aplicacao ou confiar num certificado
que esteja num encadeamento logico de certificados confiados e que se ligue desta
forma ao certificado utilizado para assinar a aplicacao
Todas as aplicacoes AIR tem caracterısticas em comum independentemente da
tecnologia utilizada para o seu desenvolvimento (HTMLFlexFlash) No ambito
de uma aplicacao AIR existem um conjunto de APIs que estao disponıveis e que
tornam possıvel o acesso ao sistema local (leitura e escrita) e a recursos de rede que
22
Estado da arte
de outra forma nunca estariam acessıveis a partir de uma web application comum
Cada aplicacao AIR possui tambem diferentes nıveis de isolamento chamados secu-
rity sandboxes dependendo do tipo de conteudo que esta a ser carregado e do seu
objectivo
bull Isolamento ao nıvel da aplicacao5 ndash E a raiz de cada aplicacao AIR Este
nıvel de isolamento permite o acesso a APIs privilegiadas e especıficas do
AIR Em contrapartida e negado o acesso a algumas APIs que poderiam ser
facilmente utilizadas de forma maliciosa contra o utilizador final Importacao
dinamica de conteudos remotos e geralmente proibido e as tecnicas e mecan-
ismos de geracao dinamica de codigo sao fortemente restringidas Apenas
conteudo carregado directamente da directoria base da aplicacao podera ser
colocado neste nıvel de isolamento
bull Isolamento nao especıfico da aplicacao6 ndash contem todo o outro conteudo
que nao tenha sido carregado directamente para o isolamento da aplicacao
Isto inclui conteudo local e remoto Este tipo de conteudo nao tem acesso
directo as APIs do AIR e rege-se pelas mesmas regras tal como se tivesse sido
carregado por um browser a partir da mesma localizacao (por exemplo HTML
carregado a partir de um domınio remoto comporta-se da mesma forma que se
fosse acedido a partir do browser)
33 Mozilla Prism
331 XML User Interface Language
O eXtensible User Interface Language (XUL) e uma linguagem de anotacao
baseada em XML desenvolvida pela Mozilla Foundation que opera em aplicacoes
Mozilla multi plataforma tal como o Firefox O motor Gecko e a unica imple-
mentacao completa desta linguagem que foi desenhada sobre padroes web comuns
como CSS JavaScript e o DOM e permite o desenvolvimento de interfaces graficas
utilizando elementos pre-definidos tais como window box page textbox radio
button entre outros Infelizmente o XUL nao possui qualquer especificacao formal
ou implementacoes de inter-operabilidade para outros motores que nao o Gecko No
entanto a sua implementacao e licenciada em codigo aberto pelas licencas GNU Gen-
eral Public License (GPL) GNU Lesser General Public License (LGPL) e Mozilla
Public License (MPL)
Enunciam-se algumas caracterısticas desta linguagem
5NT application sandbox6NT non-application sandbox
23
Estado da arte
Liguagem de anotacao poderosa baseada em componentes (widgets) O ob-
jectivo do XUL e permitir a construcao de aplicacoes multi-plataforma em
claro contraste com o Dynamic HyperText Transfer Protocol (DHTML) que se
destina ao desenvolvimento de paginas web Por esta razao o XUL esta orien-
tado a componentes tais como janelas botoes e etiquetas em vez de paginas
cabecalhos de texto e ligacoes de hipertexto Investir tempo e esforco para
atingir este mesmo resultado em aplicacoes baseadas em DHTML compromete
frequentemente a complexidade e desempenho da aplicacao
Baseado em padroes O XUL e um dialecto XML baseado no padrao W3C XML
10 As aplicacoes escritas em XUL sao tambem baseadas em especificacoes
W3C adicionais como HTML 40 CSS DOM nıvel 1 e 2 JavaScript 15
incluindo ECMA-262 Edition 3 (ECMAscript)
Portabilidade entre plataformas Tal como HTML o XUL foi desenhado para
ser independente da plataforma em que e utilizado tornando as aplicacoes
facilmente portaveis entre sistemas operativos nos quais o Mozilla e suportado
Uma vez que o XUL oferece um nıvel de abstraccao dos componentes graficos
de interface que disponibiliza implementa a premissa ldquoum codigo para todas
as plataformasrdquo A interface grafica de todos os produtos centrais Mozilla
(browser instant messenger livro de enderecos) e escrita em XUL com um
unico codigo base que suporta todas as plataformas Mozilla
Separacao entre o nıvel de apresentacao e a logica de negocio Uma das
maiores preocupacoes no desenvolvimento para a Internet e a forte ligacao
entre estas duas camadas (interface e logica) Isto constitui um problema sig-
nificativo no desenvolvimento de grandes aplicacoes especialmente quando o
desenvolvimento e feito em ambientes de equipa porque as capacidades de de-
senvolvimento destas duas partes da aplicacao estao muitas vezes espalhadas
por diferentes elementos O XUL permite uma clara distincao entre a definicao
da aplicacao cliente e da logica de implementacao (XUL eXtensible Binding
Language (XBL) e JavaScript) apresentacao (CSS e imagens) internacional-
izacao (Document Type Definitions (DTDs) e etiquetas de texto em lınguas
especıficas guardados em ficheiros properties) O esquema grafico e apre-
sentacao de uma aplicacao XUL pode ser alterado de forma independente da
sua logica ou implementacao e a aplicacao pode ainda ser traduzida (interna-
tionalization) de forma independente da sua logica implementacao ou apre-
sentacao Este grau de separacao resulta em aplicacoes que sao mais faceis de
manter pelos programadores e facilmente adaptadas por designers e tradutores
24
Estado da arte
Facil adaptacao Outro benefıcio que advem do nıvel de separacao entre logica
de negocio e apresentacao oferecido pelo XUL e a facilidade com que se pode
adaptar uma aplicacao para diferentes clientes ou grupos de utilizadores Um
programador pode utilizar a mesma aplicacao base e adapta-la consoante as
necessidades atraves de diferentes temas (skins) e ficheiros de lınguas Desta
forma uma aplicacao escrita e desenvolvida em Ingles pode ser rapidamente
traduzida para Portugues e distribuıda com outra aparencia mais apropriada
ao cliente alvo
332 Prism
O Mozilla Prism e um browser simplificado e ldquointerpretadorrdquo de XUL (tambem
designado por XULRunner) que acolhe web applications sem a interface grafica ha-
bitual de um browser Baseia-se num conceito designado por Site Specific Browser
(SSB) Um SSB e uma aplicacao com um browser embebido desenhado para exe-
cutar apenas uma web application Nao possui os menus e barras de ferramentas
habituais Um SSB tem uma integracao com o sistema operativo e com o desktop
muito mais estreita do que uma web application acedida atraves de um browser uma
vez que e executado em janela propria
O Prism resulta de uma experiencia da Mozilla e visa reduzir as diferencas entre
as desktop applications tradicionais e as web applications Um dos aspectos focados e
a experiencia do utilizador Numa apresentacao oficial e dito que ldquo[o Prism] pretende
ser uma ponte entre as diferencas que existem entre as aplicacoes tradicionais de
desktop e as web applications explorando novos modelos de usabilidade enquanto
que a linha que as separa se continua a definirrdquo [Lab07]
34 HTML 5
A especificacao HTML 5 [Hic08] que se encontra em fase de desenvolvimento
pelo grupo WHATWG pretende ser uma norma de substituicao dos padroes HTML
4 XHTML 1x e do DOM2 HTML Uma das propriedades que o distingue das tec-
nologias que pretende substituir e precisamente o suporte para OWA e armazena-
mento de dados no cliente de uma forma relacional Nao sendo propriamente uma
tecnologia ndashmas antes uma especificacao ndashe aqui mencionada por ter servido como
referencia a diversas implementacoes de funcionalidades offline e por se considerar
que venha a ter um impacto significativo nas implementacoes de diversos browsers
Dion Almaer defendeu no seu blogue que o Gears era uma implementacao do
HTML 5 No seu artigo ldquoGears as a bleeding-edge HTML 5 implementationrdquo [Alm08]
o autor diz que ambos ndasho Gears e o HTML 5 ndashpretendem dar a web caracterısticas
25
Estado da arte
semelhantes e nao encontrar motivo de ldquocompeticaordquo entre as duas mas que en-
quanto o HTML 5 e uma especificacao o Gears e uma implementacao
No entanto tambem e verdade que o HTML 5 cobre muitos outros pontos para
alem das OWA que saem completamente fora do ambito do Gears Se esta es-
pecificacao atingir um estado de maturidade que possibilite a sua adopcao pelos
principais browsers tornando nativo do browser o suporte OWA entao deixara de
fazer sentido a existencia de uma extensao como o Gears
A especificacao HTML 5 disponibiliza duas APIs relevantes para o tema das
OWA
1 Uma base de dados baseada em SQL que permite o armazenamento de dados
do lado do cliente
2 Uma ldquocacherdquo HTTP que garante a disponibilidade das aplicacoes mesmo quando
o utilizador nao possui uma ligacao a Internet
Estas caracterısticas sao as bases da tecnologia das OWA e tem correspondencia
com os pontos analisados nas seccoes 311 e 311
35 Web applications que usam funcionalidades offline
Nesta seccao apresentam-se algumas web applications que actualmente disponi-
bilizam funcionalidades offline Estas aplicacoes foram escolhidas para uma analise
mais pormenorizada por utilizarem o Gears que tal como descrito na seccao 4 foi
a tecnologia escolhida para o projecto
351 Google Reader e Google Docs
O Google Reader7 e um leitor de feeds RSS Permite gerir a subscricao de varios
sites simultaneamente que disponibilizem conteudos neste formato e foi a primeira
web application da Google com uma versao offline publicamente acessıvel (desde
Junho de 2007)
O Google Reader implementa o modo ldquoutilizador deciderdquo oferecendo na sua
interface um botao que permite alternar entre os modos online e offline
O Google Docs8 e uma web application que permite a criacao e edicao de doc-
umentos de texto folhas de calculo e apresentacoes Era ja publico desde Janeiro
de 2008 que o Google estava a desenvolver uma versao OWA desta aplicacao mas o
acesso a uma versao experimental so foi possıvel a partir de 31 de Maio de 2008
7Google Reader - httpreadergooglecom8Google Docs - httpdocsgooglecom
26
Estado da arte
A implementacao das funcionalidades offline nestas duas aplicacoes seguiu difer-
entes aproximacoes principalmente porque o Google Reader apresenta ao utilizador
informacoes que sao fornecidas por fontes externas enquanto que no Google Docs
a informacao e criada e editada pelo utilizador sobre a forma de documentos
A diferente origem da informacao implica que no Google Reader seja necessario
prever casos de excepcao tal como existirem demasiados itens que necessitam de
ser transferidos para o cliente Nao observar este ponto causa um problema grave
de usabilidade e para evitar tempos de espera demasiado longos e uma interface
com pouca capacidade de resposta as accoes do utilizador o Google Reader apenas
transfere para o cliente os dois mil itens mais recentes na transicao para o modo
offline
352 Remember the Milk
O Remember The Milk9 e uma web application desenvolvida por uma equipa
Australiana que proporciona funcionalidades de agenda gestao de tempo e de tare-
fas e foi uma das primeiras aplicacoes independentes do Google a adoptar o Gears
para acessos em modo offline Permite que os seus utilizadores facam uma gestao
de tarefas agrupando-as em listas adicionando-lhes campos de informacao adicional
ou dando-lhes informacao geografica (recorrendo ao servico Google Maps10) Entre
a sua lista de funcionalidades encontra-se ainda a possibilidade de importar e ex-
portar eventos no formato iCalendar (ics) etiquetas (tags) em tarefas publicacao
Really Simple Syndication (RSS) e partilha de categorias de tarefas de acordo com
diferentes nıveis de permissoes de acesso definidos pelo utilizador
353 MySpace e WordPresscom
O MySpace uma das maiores social networks na Internet anunciou recente-
mente que vai disponibilizar uma versao do seu cliente de e-mail que utiliza o Gears
para acelerar o seu desempenho Numa fase inicial estara disponıvel apenas para
utilizadores que tenham cinco mil ou mais mensagens na sua caixa de correio e
permitira efectuar pesquisas muito mais rapido que a sua versao online
O servico de blogs Wordpresscom anunciou tambem o inıcio da utilizacao desta
tecnologia com o fim de melhorar o desempenho A versao que utiliza esta tecnologia
descarrega e armazena no cliente um conjunto de imagens e scripts que passam a
ter preferencia sobre os seus congeneres online e que permitem acelerar o processo
de carregamento da aplicacao e visualizacao de blogs
9Remember The Milk ndash httpwwwrememberthemilkcom10Google Maps ndash httpmapsgooglecom
27
Estado da arte
O MySpace e o Wordpresscom sao dois exemplos da utilizacao da tecnologia
OWA para optimizacao de web application ja existentes Sem pretenderem disponi-
bilizar uma versao que seja totalmente offline fazem uso do Gears para armazenar no
cliente parte dos recursos frequentemente acedidos na visualizacao das suas paginas
36 Escolha da tecnologia
Apos a analise das tecnologias apresentada nas seccoes 31 a 34 foi necessario es-
tudar a adequacao de cada uma delas ao projecto em questao Desde logo e possıvel
observar que nem todas se dedicam apenas a OWA Por exemplo o Adobe AIR
apesar de ter suporte para OWA apenas disponibiliza algumas das funcionalidades
identificadas como mais indicadas para a execucao do projecto quando utilizado
na sua vertente desktop tal como exposto na Tabela 31 mas a utilizacao desta
vertente implicaria o desenvolvimento de novas interfaces e de novas formas de co-
municacao (troca de mensagens XML ou JSON) A vertente web do Adobe AIR
foca-se mais especificamente nas Rich Internet Applications e permite a reutilizacao
do codigo ja existente (exigindo naturalmente a sua adaptacao e a implementacao
das funcionalidades pretendidas)
A tecnologia escolhida para a realizacao deste trabalho foi o Gears sendo que
um dos principais factores a influenciar esta opcao foi a liberdade introduzida pela
sua licenca Berkeley Software Distribution (BSD)11
Considerou-se o funcionamento desta ferramenta extremamente adequando a
aplicacao no WOW uma vez que o seu principal objectivo e precisamente tornar
possıvel a execucao offline de uma pagina web e por virtude deste facto o Gears tem
uma API concisa e de simples aplicacao pratica uma vez que nao possui quaisquer
outros elementos distractores O funcionamento do seu ManagedResourceStore ex-
emplificado na Figura 31 com a capacidade de actualizacao de recursos definidos
num ficheiro manifesto especificado em JSON pesou tambem nesta decisao
11Sobre a licenca BSD consultar httpwwwopensourceorglicensesbsd-licensephp e http
wwwlinfoorgbsdlicensehtml
28
Estado da arte
Figura 31 Esquema UML do processo efectuado pelos recursos do Gears do tipoManagedResourceStore para a actualizacao dos conteudos definidos no ficheiro manifesto
29
Estado da arte
Funcionalidade RIAs no browser RIAs no desktop
Disponibilidadeda aplicacao
As aplicacoes podem ser facil-mente exploradas e utilizadas
As aplicacoes quando instal-adas tem maior grau de fun-cionalidades e persistencia
Instalacao Nao e necessario qualquer tipode instalacao
As aplicacoes sao instaladasatraves do browser ou descar-regadas e instaladas comouma aplicacao tradicional
Actualizacoes Aplicacoes sao actualizadascarregando conteudos paraum website
O AIR disponibiliza uma APIque permite que as aplicacoessejam actualizadas de umaforma
Sistemas opera-tivos suportados
As aplicacoes podem ser exe-cutadas em diversos sistemasoperativos e browsers
As aplicacoes sao multi-plataforma e podem serinstaladas e executadas emdiversos sistemas operativos ebrowsers
Linguagens deprogramacao
Javascript e disponibilizadopelo browser e ActionScripte disponibilizado pelo AdobeFlash Player
Maquinas virtuais deJavascript e ActionScriptcompatıveis com o browser
Capacidade deexecucao embackground
As RIAs podem ser execu-tadas numa janela do browser
As aplicacoes podem ser ex-ecutadas em background edisponibilizar notificacoes talcomo uma aplicacao tradi-cional
Persistencia A actividade esta limitada asessao do browser Quando obrowser e encerrado toda ainformacao e descartada
As aplicacoes sao instaladas eestao disponıveis no desktopPodem armazenar informacaolocalmente e estao disponıveisoffline
Integracao com odesktop
Integracao com o desktop lim-itada devido a restricoes im-postas pelo browser
As aplicacoes podem acederao sistema de ficheiro ao clip-board eventos notificacoesetc
Controlo da inter-face com o uti-lizador
As aplicacoes sao acedidasatraves de uma janela dobrowser que tem os seusproprios controlos e visualgrafico
As aplicacoes tem um vi-sual grafico proprio em janelapropria
Armazenamentode dados
As aplicacoes tem armazena-mento limitado que pode serreescrito pelo browser
As aplicacoes tem acesso a to-talidade do espaco disponıvellocalmente e a uma base dedados com a possibilidade deencriptacao
Tabela 31 Comparacao das funcionalidades oferecidas pelo Adobe AIR para as platafor-mas web e desktop
30
Estado da arte
Aplicacao Modo de execucao utilizadoGoogle Reader Utiliza o modo ldquoutilizador deciderdquo disponibilizando
ao utilizador um botao para alternar entre os modosonline e offline Como lida com informacao recol-hida de fontes externas de natureza frequentementeefemera o processo de sincronizacao apenas transfereos dois mil itens mais recentes quando passa ao es-tado offline Neste modo sao ainda guardadas in-formacoes de itens lidos e etiquetas atribuıdas quesao sincronizadas com o servidor quando o utilizadorvoltar a activar estado online
Google Docs Utiliza o modo ldquoaplicacao deciderdquo permitindo que outilizador edite os conteudos de documentos de textofolhas de calculo e de apresentacoes independente-mente do estado da ligacao desde o momento em queas funcionalidades offline sao activadas A aplicacaofaz pequenas sincronizacoes com o servidor sempre quenecessario
Remember the Milk Utiliza um modo hıbrido entre ldquoaplicacao deciderdquo eldquoutilizador deciderdquo A aplicacao encarrega-se da sin-cronizacao de dados mas disponibiliza um controlona sua interface que permite despoletar manualmenteeste processo para situacoes em que o utilizador fez al-teracoes recentes e pretende usufruir das capacidadesoffline imediatamente
MySpace O MySpace anunciou a utilizacao de mecanismos dearmazenamento de dados no cliente com recurso atecnologias OWA para melhorar o desempenho doseu cliente web de correio electronico nomeadamenteno que diz respeito a operacoes de pesquisa e or-denacao Inicialmente esta funcionalidade estara ape-nas disponıvel para utilizadores com cinco mil ou maismensagens na sua caixa de correio mas nao e aindaclaro se sera disponibilizada uma versao totalmenteoffline
Tabela 32 Resumo da utilizacao de tecnologias OWA em algumas web applications con-sideradas na analise do estado da arte
31
Estado da arte
32
Capıtulo 4
Desenvolvimento
Neste capıtulo introduz-se a aplicacao WOW e apresenta-se o estudo que foi
feito da adequacao de cada tecnologia para a implementacao da funcionalidade of-
fline nesta plataforma Fazem-se diversas consideracoes sobre opcoes a tomar na
concepcao de OWAs e problemas comuns na sua implementacao bem como sug-
estoes para os resolver O WOW e uma aplicacao ja existente de gestao de ordens
de trabalho e do fluxo de tarefas numa empresa ou organizacao
41 Como ficar offline
Na maior parte das web applications de hoje nao existe uma camada de dados
real A aplicacao exemplificada na Figura 41 ao longo da sua execucao acede
directamente a sua unica fonte de dados (o servidor) atraves de chamadas Ajax sem
que exista uma separacao clara destas duas camadas
Para que uma web application seja capaz de ser executada sem uma ligacao
activa a Internet e mantenha o seu caracter dinamico torna-se necessario incluir
Figura 41 Exemplo de uma arquitectura de uma web application sem uma camada deabstraccao de dados Figura adaptada de http gears google com
33
Desenvolvimento
Figura 42 Exemplo de uma arquitectura de uma web application com uma camada deabstraccao de dados Figura adaptada de http gears google com
um mecanismo de armazenamento de dados local seja uma base de dados ou a
capacidade de acesso ao disco No entanto este mecanismo introduz dois problemas
1 Qual das fontes de dados utilizar quando um utilizador faz um pedido de
informacao
2 A necessidade de implementar uma camada de acesso a dados que seja coerente
quer se use o servidor remoto ou local
Por exemplo em vez de a aplicacao Ajax fazer um pedido relativo as contas de
todos os utilizadores em formato JSON directamente ao servidor remoto podera ao
inves fazer o pedido a um objecto intermedio da camada de dados Este objecto
demonstrado na Figura 42 sera responsavel por implementar uma interface de
acesso a base de dados e retornar um objecto JavaScript com uma representacao da
resposta do servidor
Mas a existencia de uma segunda fonte de dados torna recomendavel tambem
a implementacao de uma camada de data switching que em funcao da existencia
de conexao a Internet e da necessidade de actualizacao dos dados decide se faz o
pedido ao servidor remoto ou se fornece os dados presentes localmente Este objecto
apresentado na Figura 43 decidira de forma transparente para o utilizador se le ou
escreve os dados localmente ou se os enviapede ao servidor remoto e pode tambem
iniciar o processo de convergencia de dados e de resolucao de conflitos
411 Funcionalidades disponıveis em modo offline
Por razoes praticas e provavel que nem todas as funcionalidades da aplicacao
possam ser disponibilizadas em modo offline E necessario escolher quais as fun-
cionalidades a disponibilizar no modo offline da aplicacao e implementar a logica
que decide quando utilizar a base de dados local ou o servidor remoto Apesar do
acesso a base de dados local ser muito mais rapido do que aceder ao servidor o
acesso local nem sempre e preferido Ha varias razoes que podem tornar necessario
escolher o acesso ao servidor em vez do acesso local
34
Desenvolvimento
Figura 43 Exemplo de uma arquitectura de uma web application com uma camada deabstraccao de dados e um data switch Figura adaptada de http gears google com
1 A informacao pode ter uma natureza efemera e nao fazer sentido guarda-la
localmente Exemplo dados em tempo real da bolsa de valores de Lisboa
2 Algumas aplicacoes lidam com informacao que so faz sentido na presenca de
uma ligacao Exemplo Instant Messaging
3 A aplicacao podera escolher apenas guardar a informacao acedida mais fre-
quentemente Exemplo para o utilizador poder alterar a lıngua de apre-
sentacao da aplicacao os conteudos terao que ser guardados em todas as
lınguas disponibilizadas pela aplicacao O custo de implementacao de algu-
mas funcionalidades pode nao compensar o benefıcio
4 A capacidade de processamento ou de armazenamento de dados pode inviabi-
lizar algumas funcionalidades offline Exemplo se uma dada funcionalidade
necessita de uma capacidade de armazenamento de dados para alem do razoavel
de um computador pessoal para ser util (visualizador de mapas)
42 Modos de execucao
Um aspecto que e necessario estudar para qualquer web application que se deseje
disponibilizar offline prende-se com tres modos de execucao que devem ser consid-
erados
1 Utilizador decide o modo de execucao A aplicacao tem modos distintos
de execucao para os estados online e offline geralmente indicados na interface
com o utilizador O utilizador e informado do estado da ligacao e participa na
alteracao de estado de execucao da aplicacao interagindo com a sua interface
2 Aplicacao decide o modo de execucao Pode ser implementado na propria
aplicacao um mecanismo de deteccao do estado da ligacao (por exemplo atraves
35
Desenvolvimento
de chamadas Ajax periodicas) transitando de estado e sincronizando automati-
camente Desta forma o utilizador nao precisa de participar na alteracao de
estado a menos que exista um conflito de dados que requeira a sua atencao
3 Aplicacao assume sempre o estado offline Outra hipotese sera imple-
mentar uma web application que assume sempre estar na ausencia de uma
ligacao ao servidor de dados Esta aplicacao responde aos pedidos do uti-
lizador efectuando pedidos de informacao ao servidor mas nao dependendo
de uma resposta valida para mostrar a informacao que ja tinha disponıvel an-
teriormente A sincronizacao de dados com o servidor e tentada sempre que
existam dados para submeter e uma accao do utilizador
421 Modo ldquoutilizador deciderdquo
Neste modo de execucao quando a aplicacao esta online comunica com o servidor
remoto quando esta offline comunica com a base de dados local A informacao tem
que ser sincronizada sempre que se muda de modo A principal vantagem desta opcao
e que e a mais simples de implementar mesmo para uma aplicacao ja existente e
portanto uma forma expedita de disponibilizar uma OWA No entanto tem tambem
algumas desvantagens que devem ser consideradas
1 O utilizador tem que se lembrar de fazer a alteracao de estado de execucao
Caso contrario podera estar a trabalhar inadvertidamente numa versao offline
com dados antigos ou nao ter a informacao necessaria se perder subitamente
a ligacao
2 Se a ligacao for intermitente o utilizador tera ou que escolher um dos modos
de execucao ou estar constantemente a trocar
3 Uma vez que a base de dados nao esta sempre actualizada nao podera ser
utilizada para melhorar a rapidez de execucao da aplicacao quando em modo
online
422 Modo aplicacao decide
A deteccao do estado da ligacao pode ser implementada atraves de um pedido
assıncrono ao servidor tal como ilustrado na Figura 44 O resultado deste pedido
definira o estado online (em caso de sucesso) ou offline (em caso de falha) A
sincronizacao de dados podera ser feita sempre que ocorra uma transicao do es-
tado offline para o estado online No entanto este metodo nao se revela eficiente
36
Desenvolvimento
Figura 44 Esquema grafico ilustrando uma OWA executando no browser utilizando ummodo de execucao do tipo ldquoaplicacao deciderdquo com deteccao automatica do estado daligacao via pedidos Ajax assıncronos a cada cinco segundos
para grandes aplicacoes uma vez que requer a troca de mensagens demasiado fre-
quentes com o servidor que se destinam exclusivamente a monitorizacao do estado
da ligacao
423 Modo ldquoaplicacao assume o estado offlinerdquo
Uma aplicacao transparente funciona assumindo sempre que esta em modo of-
fline ou pelo menos que pode perder a ligacao a qualquer momento Neste modo
tira-se o maximo partido do armazenamento local e fazem-se pequenas mas contınuas
sincronizacoes com o servidor sempre que este esteja disponıvel A sincronizacao de
dados tambem e feita sempre que se volta ao estado online
As vantagens de uma web application transparente sao as seguintes
bull Uma melhor experiencia para o utilizador uma vez que este nao tem que se
preocupar com o estado da ligacao ou com a transicao de estados
bull A aplicacao funciona de forma coerente mesmo que a ligacao seja intermitente
bull Uma vez que o armazenamento local e mantido actualizado pode ser utilizado
para melhorar o desempenho da aplicacao
Foram identificadas as seguintes desvantagens
bull E mais difıcil de implementar e a sincronizacao acarreta cuidados especiais
bull E necessario um cuidado adicional para evitar que as operacoes de sincronizacao
frequentes que ocorrem automaticamente nao afectem os tempos de resposta
da aplicacao
bull Os testes a aplicacao sao mais complexos uma vez que a sincronizacao de dados
nao ocorre em resposta a uma accao do utilizador
37
Desenvolvimento
43 Sincronizacao de dados
A sincronizacao de dados consiste na capacidade de identificar e transferir pe-
riodicamente a versao mais actual dos dados entre o cliente e o(s) servidor(es)
Independentemente do modo de execucao escolhido e mesmo do estado da ligacao
do utilizador a informacao armazenada localmente e a informacao armazenada no
servidor estarao por vezes dessincronizadas Isto podera acontecer sempre que por
exemplo
bull O utilizador faz alteracoes em modo offline
bull A informacao e partilhada e pode ser alterada por uma entidade externa
bull A informacao e fornecida por uma entidade externa
Resolver estas diferencas de forma a que a informacao local e remota encontrem
a igualdade chama-se sincronizacao de dados Ha varias aproximacoes possıveis
para este efeito que dependem da natureza da aplicacao cada uma com vantagens
e desvantagens
A capacidade de suportar a mobilidade dos utilizadores torna-se cada vez um
ponto mais importante de uma web application Para uma organizacao de dimensao
global e vital garantir que os seus colaboradores tem acesso a mesma informacao
que tem disponıvel nos seus postos de trabalho mesmo quando estao fora Na maior
parte dos casos estes colaboradores terao acesso a um computador portatil um
desktop Smartphone ou PDA e atraves destes poderao ter acesso a sua informacao
directamente atraves de ligacoes encriptadas Virtual Private Network (VPN) de um
servidor web ou de outro mecanismo de rede
Esta solucao e simples de implementar mas infelizmente para a maioria dos
colaboradores com grande factor de mobilidade nao e satisfatoria As principais
desvantagens sao as seguintes
bull Requisitos de ligacao Para permitir que os utilizadores acedam a sua in-
formacao e necessario garantir a capacidade constante de comunicacao pelo
menos durante o tempo necessario que assegure a sua transferencia
bull Velocidade de ligacao sem persistencia de dados e em ligacoes de fraca
qualidade a usabilidade por vezes torna-se inaceitavel
bull Ponto crıtico de falha Com este tipo de solucao todos os utilizadores de-
pendem da base de dados que armazena informacao vital para o funcionamento
do cliente
38
Desenvolvimento
bull Scalability do servidor A medida que novos utilizadores sao adicionados ao
sistema o desempenho do servidor e afectado levando a necessidade de maior
capacidade de armazenamento eou processamento
De acordo com a documentacao da Microsoft Sync Framework [Mic08] uma
solucao alternativa consiste em implementar uma Occasionally Connected Appli-
cation (OCA) Uma OCA permite a um utilizador remoto continuar a aceder a
sua informacao mesmo depois de perder a ligacao mas em vez de recorrer a um
servidor recorre a informacao armazenada no seu dispositivo local Para preencher
localmente a informacao que o utilizador necessita uma OCA possui mecanismos
de sincronizacao de dados que sao oferecidos por esta framework
431 Quando sincronizar
Uma das solucoes mais simples de implementar passa por disponibilizar um
mecanismo manual que despoleta a sincronizacao Diz-se manual porque e o uti-
lizador que escolhe quando sincronizar e pode ser implementada simplesmente
fazendo o upload de toda a informacao para o servidor e depois fazendo o download
da copia mais recente da informacao antes de voltar a ficar offline Para que esta
seja uma opcao viavel e necessario que
bull O volume de dados seja suficientemente pequeno para que possa ser transferido
do servidor para o cliente num espaco de tempo aceitavel
bull Que o utilizador indique explicitamente que quer mudar para o estado offline
ou online pressionando um botao da interface
Contudo podem ser identificados alguns problemas relacionados com esta abor-
dagem
bull Os utilizadores nem sempre podem prever o estado das suas ligacoes A ligacao
pode-se perder subitamente ou ter um caracter intermitente
bull O utilizador pode esquecer-se de efectuar a sincronizacao
Outra opcao sera conjugar a sincronizacao de dados com o modo de execucao
transparente A sincronizacao ocorre automaticamente em background de forma
nao intrusiva para o utilizador A aplicacao comunica com o servidor regularmente
efectuando pequenas trocas de dados com o objectivo de manter o sincronismo da
informacao local e remota Esta abordagem pode ser implementada com pedidos
Ajax assıncronos e regulares ao servidor o que permite manter a interaccao com a
interface fluıda evitando bloqueios Estes pedidos sao feitos prevendo as situacoes
39
Desenvolvimento
de disponibilidade ou indisponibilidade (timeout) do servidor Uma outra opcao
sera permitir que o servidor comunique essas alteracoes utilizando Comet1 tal como
descrito em [Wil06] e [Rus06] As vantagens destas aproximacoes sao
bull A informacao esta disponıvel a qualquer altura que o utilizador decida ficar
offline ou que a ligacao seja acidentalmente perdida
bull O desempenho da aplicacao pode ser melhorado quando se estiver a utilizar
uma ligacao a Internet lenta uma vez que o acesso a dados locais e mais
eficiente do que a consulta de dados ao servidor
44 WOW
O WOW e uma plataforma integrada de gestao de ordens de trabalho ja ex-
istente e desenvolvida pela Critical Software SA a qual se pretende adicionar a
capacidade de execucao offline Esta aplicacao e extremamente dinamica e con-
figuravel com um conjunto extremamente rico de funcionalidades das quais se
destacam
bull Gestao de Ordens de Trabalho ndash suportando a gestao dos pedidos desde a
sua criacao ate ao seu fecho tomando em conta os diferentes tipos de pedidos
(ordens de trabalho pedidos de informacao melhorias resolucao de problemas
etc) e diferentes tipos de accoes possıveis para cada um (Figura 45)
bull Monitorizacao de alteracoes ndash Historico de mudancas anexos e estados criando
relatorios de alteracao automaticamente (o que por quem e quando)
bull Uso de Service Level Agreements (SLAs) ndash E possıvel associar a um pedido um
SLA que define qual o perıodo de tempo atribuıdo a resolucao de um pedido
controlando e agilizando a resolucao do mesmo
bull Utilizacao de queries de utilizador configuraveis que permitem acesso rapido
a determinadas ordens de trabalho de acordo com o filtro configurado (por
exemplo ldquoPara mimrdquo ldquoPara o Grupordquo ldquoPelo Grupordquo)
bull Gestao do relacionamento entre pedidos
bull Pesquisa e filtragem de ordens de trabalho
bull Exportacao de dados em formatos padrao (PDF DOC ou XLS)
bull Integravel com solucoes externas
40
Desenvolvimento
Figura 45 Detalhe de um conjunto possıvel de estados e respectivas transicoes para umadada ordem de trabalho no WOW desde a sua submissao no sistema ate a sua conclusaoem fecho ou cancelamento Esta figura representa apenas um exemplo ja que o mapa deestados para uma ordem de trabalho e dinamico e pode ser alterado por um administradorFigura retirada de uma brochura promocional do WOW Critical Software SA
A utilizacao de uma ferramenta deste tipo por parte de uma empresa ou orga-
nizacao oferece vantagens quer a gestao de topo quer aos colaboradores individuais
para os colaboradores individuais o WOW e uma aplicacao onde estao registadas
todas as tarefas contribuindo activamente para o desenvolvimento em ambientes
multi-tarefa e para a organizacao pessoal das tarefas de acordo com prioridades
Para a gestao de topo esta ferramenta permite obter uma visao global do estado da
organizacao em termos de tempo gasto por tarefa executada sendo uma mais valia
para a previsao e gestaoalocacao de recursos
45 Visao geral sobre a arquitectura do WOW
O WOW e interessante nao so do ponto de vista de produto como tambem do
ponto de vista de plataforma Existem diversos plug-ins que estendem as funcional-
idades do WOW e existem ate projectos que pretendem usar a arquitectura do
WOW para criar produtos com fins diferentes do inicial (por exemplo o WOW-
Storm ndash um sistema de registo e classificacao social de ideias)
De modo a conseguir ter essa expansibilidade a plataforma WOW assenta sob
uma arquitectura distribuıda modular e expansıvel com uma componente central
ndash o core ndash estruturado em camadas logicas E no core que se situam todas as
1O Comet e um conceito semelhante ao Ajax introduzido por Alex Russel mas no qual e o servidor quetoma a iniciativa de ldquoenviarrdquo os dados ao browser sem que este tenha que efectuar um pedido Tambem econhecido por Ajax Push Reverse Ajax ou HTTP Streaming
41
Desenvolvimento
funcionalidades base da aplicacao quer a nıvel logico funcional e de apresentacao
quer a nıvel de gestao e configuracao
E possıvel a execucao de varias instancias do core simultaneamente em servidores
distintos o que permite a alta escalabilidade e disponibilidade desta aplicacao A
consistencia dos dados fica sempre garantida atraves da partilha da base de dados
e pelo balanceamento dos pedidos uma vez que cada um e encaminhado para uma
unica instancia
O WOW apresenta tambem a vantagem de ser uma plataforma extensıvel E
possıvel adicionar novas caracterısticas a plataforma atraves de componentes que se
podem ser divididos em duas categorias plugins e connectors
Os plugins sao componentes que se encontram no mesmo no fısico que a aplicacao
partilhando do mesmo contexto de execucao do core Sao assim uma forma mais
directa de obter informacao da plataforma visto que nao possuem restricoes de
acesso aos dados nem dependencias externas A arquitectura deste componente tera
assim que permitir varias execucoes instanciadas cada uma associada a um core
Por outro lado os connectors sao componentes que se encontram distribuıdos
comunicando externamente com o core Quer a sua execucao quer a obtencao
dos dados estao assim dependentes de interfaces de comunicacao externas que a
plataforma disponibiliza Estes componentes ao contrario dos plugins sao instan-
ciados unicamente e recorrem ao protocolo de comunicacao Java Messaging Service
(JMS) para comunicar com o core
46 WOW Offline
Para alem das opcoes tomadas relativamente a tecnologia a utilizar surgiu
tambem a necessidade de optar por um dos modos de execucao apresentados na
seccao 42
Das tres opcoes possıveis foi o modo ldquoaplicacao assume o estado offlinerdquo descrito
na seccao 423 que mereceu a maior atencao uma vez que reune as vantagens de
uma experiencia mais positiva para o utilizador (uma vez que este nao tem que
participar activamente na alteracao do modo execucao como descrito na seccao 421)
e nao constitui uma sobrecarga excessiva para servidor (como o modo abordado na
seccao 422)
No entanto esta opcao comprometia a complexidade da implementacao para alem
dos objectivos propostos para este projecto e para cumprir o prazo dado foi tomada
a decisao de implementar o modo ldquoutilizador deciderdquo especificando apenas de forma
teorica o modo ldquoaplicacao assume o estado offlinerdquo
As caracterısticas do Gears foram ja descritas na seccao 31 Na Figura 47
mostra-se a sua forma de funcionamento quando integrado numa web application
42
Desenvolvimento
Nesta figura representa-se o modulo LocalServer do Gears como um ponto de de-
cisao Aqui sao testadas as condicoes que determinam se o pedido sera interceptado e
servido localmente ou se prossegue para uma maquina remota E tambem represen-
tada uma base de dados que corresponde ao modulo Database mas que podera nao
ser utilizada Este modulo tal como o modulo Workerpool tem caracter opcional
e sao utilizados consoante os requisitos da aplicacao
A plataforma WOW lida com mais dados do que e necessario passar para o
lado do cliente Em conformidade com o ja exposto na seccao 411 volta-se a
frisar que nao se pretende recriar toda a logica de negocio nem os conteudos da
base de dados no cliente pela sua complexidade e volume de dados Pretende-se
pelo contrario permitir que os utilizadores tirem partido da capacidade de poder
consultar as suas ordens de trabalho quando nao dispoe de uma ligacao transferindo
apenas o essencial para isto seja possıvel
A pagina inicial do WOW apresenta um resumo das ordens de trabalho abertas
ndash enviadas e recebidas ndash que se pretende permitir visualizar offline (ver Figura 46)
Como prova de conceito foi efectuada uma abordagem pragmatica das varias possi-
bilidades descritas na seccao 42
461 Modo ldquoaplicacao deciderdquo com deteccao automatica da ligacao
A primeira abordagem estudada para a disponibilizacao das funcionalidades of-
fline foi o modo ldquoaplicacao deciderdquo com deteccao automatica de ligacao apresentado
na seccao 422 Para que isto seja possıvel foi implementado um mecanismo de ver-
ificacao periodica do estado da ligacao atraves de chamadas Ajax assıncronas O
resultado destes pedidos determina o estado da aplicacao executando as tarefas de
sincronizacao de dados sempre que pertinente Este metodo embora imediato e
simples de implementar depressa se revelou inadequado para o projecto devido ao
elevado consumo de recursos do servidor que a utilizacao intensiva faz esperar a
comunidade da plataforma WOW no principal cliente excede os 7000 utilizadores
Foi estimado que para uma utilizacao de fluidez aceitavel o estado da ligacao deveria
ser testado a cada cinco segundos Assumindo uma adesao (previsao pessimista) de
1 aos servicos offline assistir-se-ia a cerca de 840 pedidos adicionais por minuto
Mas o principal problema desta aproximacao prende-se com o facto de a ver-
ificacao ser feita em intervalos de tempo discretos levando a possibilidade de a
aplicacao poder ter em dado momento uma representacao errada do seu estado
real da ligacao Este problema e ilustrado na Figura 48 onde se ve claramente a
discrepancia entre o estado real da ligacao e a representacao interna que esta tem
Note-se que nesta janela de tempo qualquer accao do utilizador que exija uma
resposta sıncrona do utilizador leva-lo-a para um ldquobeco sem saıdardquo onde nao tera
43
Desenvolvimento
Figura 46 A pagina inicial do WOW apresenta um resumo das ultimas ordens de trabalhoenviadas e recebidas Na imagem pode-se observar a transicao do estado online para offline
acesso a versao offline porque a aplicacao nao fez a transicao automatica nem acesso
a versao online porque na verdade nao possui uma ligacao O que acontecera nesta
situacao sera uma tentativa de acesso ao servidor por parte da aplicacao numa
altura em que este se encontra indisponıvel e o resultado sera uma mensagem de
ldquopedido excedeu o tempordquo apresentado pelo browser Este e um estado sem retorno
porque apos o browser apresentar esta mensagem todos os recursos JavaScript ficam
indisponıveis tornando impossıvel o regresso ao estado anterior ou o tratamento do
erro de qualquer outra forma No entanto as chamadas Ajax podem ser tratadas de
forma especial para a eventualidade de falha e portanto nao constituem problema
44
Desenvolvimento
Figura 47 Ilustracao do funcionamento do Gears numa web application que utiliza ummotor Ajax Os pedidos HTTP ou HTTPS podem ser interceptados e tratados localmenteou podem ser feitos a uma maquina remota consoante se verificarem ou nao as condicoesexpressas no ponto 311 E representado um acesso a uma base de dados local (fornecidapelo Gears) mas a sua utilizacao e opcional
462 Implementacao do modo ldquoutilizador deciderdquo
Este modo de execucao foi ja descrito na seccao 421 e a sua principal carac-
terıstica e ser o utilizador a decidir se a aplicacao deve utilizar um servidor remoto
ou a maquina local como fornecedor de dados
Relativamente ao WOW o WOW Offline na vertente ldquoutilizador deciderdquo vem
alterar os seus casos de uso dando ao utilizador a possibilidade de alterar o estado
de execucao da aplicacao (entre online e offline) Resta dizer que no modo online se
mantem todas as funcionalidades anteriores e que no modo offline torna-se possıvel
visualizar os conteudos da pagina principal do WOW (Figura 46) e os detalhes das
ordens de trabalho (Figura 49) tal como expressa a Figura 410
Esta aproximacao foi utilizada na prova de conceito do WOW adicionando um
controlo a interface desta aplicacao que permite ao utilizador alternar entre os esta-
dos online e offline Na transicao de online para offline sao descarregados os recursos
necessarios para a execucao desta aplicacao sem recorrer a Internet Para o fazer
45
Desenvolvimento
Figura 48 Neste exemplo do modo ldquoaplicacao deciderdquo o teste da ligacao e feito e feito acada cinco segundos O resultado deste teste nao reflecte sempre o estado real da aplicacaopodendo levar a aplicacao a ter comportamentos indesejaveis Na figura assinala-se umperıodo de tempo no qual a representacao interna do estado da ligacao nao corresponde arealidade
e utilizado um recurso ResourceStore e um ManagedResourceStore (introduzidos
em 311) O primeiro e utilizado para armazenar a pagina principal do WOW ndash do-
ravante designada por homejsp ndash e o segundo e utilizado para armazenar imagens
folhas de estilo CSS e scripts JavaScript
Para a implementacao deste modo de execucao foram identificadas as seguintes
tarefas
1 Guardar informacao que permita a recriacao das paginas que se pretende
disponibilizar offline (utilizando o Gears)
2 Disponibilizar um controlo que permita alterar o estado de execucao atraves
da interaccao com a pagina principal
3 Durante a sincronizacao de dados apresentar o progresso da transferencia de
dados
O primeiro passo consistiu na identificacao de todos os conteudos que sao necessarios
transferir para a execucao offline Foi utilizado um recurso do Gears do tipo
ManagedResourceStore que recorre a um ficheiro manifesto para identificar to-
dos os ficheiros que deve transferir Este recurso e gerido automaticamente pelo
Gears transferindo para o cliente a versao mais recente sempre que e necessario
isto e sempre que exista um ficheiro manifesto com uma identificacao de versao que
seja diferente da actualmente disponıvel no cliente Uma vez identificados todos
ficheiros necessarios para a execucao offline num (ou mais) ficheiros manifesto o
Gears encarrega-se da sua actualizacao mas o preenchimento destes ficheiros man-
ifesto e manual o que se traduz num cuidado extra na manutencao da aplicacao
A forma como esta informacao e guardada deve tambem ser cuidadosamente
estudada A opcao mais flexıvel passa por utilizar o modulo Database apresentado
na seccao 311 e guardar a informacao de uma forma relacional Para a recriacao
das paginas pode ser disponibilizada uma versao HTML da pagina que funciona
46
Desenvolvimento
Figura 49 Pagina de visualizacao do detalhe de uma ordem de trabalho
como template nao possui quaisquer dados e e utilizada apenas em modo offline E
preenchida para cada pedido retirando os dados relevantes da base de dados
O modelo de dados do WOW torna esta opcao extremamente trabalhosa uma
vez que as entidades envolvidas na geracao de cada pagina de informacao sobre
cada ordem de trabalho tem relacoes de dependencia complexas seguindo padroes
muito variaveis Por exemplo em cada ordem de trabalho existe um formulario que
permite a sua progressao de estado com diversos campos opcionais e obrigatorios
este formulario e definido pelo administrador e esta relacionado nao apenas com o
tipo de ordem de trabalho mas tambem com o estado actual em que esta se encontra
e a accao que se pretende realizar O elevado numero de combinacoes de tipos de
ordem de trabalho estados e accoes que existem num dado momento juntamente
com a sua possibilidade de alteracao obrigariam a implementacao de uma logica de
negocio complexa o que esta fora do ambito deste projecto
47
Desenvolvimento
Figura 410 Esquema UML que expressa os casos de uso do WOW Offline no modoldquoutilizador deciderdquo
463 Especificacao do modo ldquoaplicacao assume o estado offlinerdquo
A aproximacao para o modo ldquoaplicacao assume o estado offlinerdquo foi tambem
dividida em varias tarefas
1 Guardar informacao que permita a recriacao da pagina principal do lado do
cliente no estado offline (utilizando o Gears)
2 Dotar a aplicacao do cliente de um mecanismo de deteccao da ligacao
3 Identificar os ldquomomentos chaverdquo em que devera ocorrer sincronizacao de dados
4 Implementar a sincronizacao de dados
A sincronizacao de dados deve ser feita em ambas as transicoes online-offline e
offline-online quer para transferir novos dados do servidor (os pedidos podem ser
alterados por outros utilizadores) quando se transita do estado quer para comunicar
eventuais alteracoes feitas em modo offline
Relativamente ao WOW o WOW Offline na vertente ldquoaplicacao assume o es-
tado offlinerdquo vem alterar os seus casos de uso dando ao utilizador a possibilidade
de activar esta funcionalidade A partir do momento que a funcionalidade esta ac-
tivada o utilizador deve tambem ter a possibilidade de gerir algumas preferencias
relacionadas com privacidade de dados Devera ter a hipotese de desactivar o ar-
mazenamento local e de remover todos os dados ja armazenados tal como descrito
na Figura 411
48
Desenvolvimento
Figura 411 Esquema UML que expressa os casos de uso do WOW Offline no modoldquoutilizador deciderdquo
A primeira vez que o WOW Offline e acedido por um cliente e caso seja detec-
tada a presenca do Gears todos os recursos necessarios a sua execucao sao trans-
feridos Todos os acessos posteriores serao feitos a estes recursos locais (recorda-se
que o Gears pode ser utilizado para os manter actualizados recorrendo ao Managed-
ResourceStore 311)
Atraves do JavaScript e possıvel interceptar os eventos de load e unload da
pagina que sao despoletados sempre que ocorre um re-acesso da mesma (incluindo
a accao refresh comum dos browsers) sempre que esta e abandonada ou ainda ou
ainda se a janela for encerrada
Tal como sugerido na seccao 462 a camada de interface desta aplicacao (cada
pagina individual em HTML) devera ser implementada como sendo um template
para apresentacao de dados sendo totalmente preenchida atraves de funcoes em
JavaScript O objectivo deste ponto e criar um padrao de dados que permita ao
JavaScript preencher os dados em cada pagina (template) independentemente de
qual seja a fonte ndash o servidor remoto ou a maquina local tal como exemplificado
no diagrama da Figura 412 Na figura a aplicacao recorre ao servidor remoto para
obter os dados pretendidos quando se encontra na presenca de uma ligacao mas
para dados que exijam uma carga de processamento pelo servidor este acto pode ser
49
Desenvolvimento
Figura 412 Esquema UML que expressa o acto de recolha de dados em modo online eoffline recorrendo ao servidor (modo online) e ao sistema de armazenamento de dadoslocal fornecido pelo Gears (modo offline)
substituıdo pelo envio de um campo de controlo que se destina a aferir se os dados
locais se encontram actualizados No caso de estarem actualizados a comunicacao
com o servidor pode ser substituıda por uma query a base de dados local
50
Capıtulo 5
Resultados e Futuros
Desenvolvimentos
Todo o estudo feito sobre o tema OWA foi ja abordado ao longo do documento
Neste capıtulo apresentam-se os resultados obtidos na implementacao da prova de
conceito que visava compreender a melhor forma de disponibilizar uma versao of-
fline no WOW uma plataforma de gestao de ordens de trabalho ja existente de-
senvolvida pela Critical Software SA
51 Resultados Obtidos
Os resultados obtidos neste projecto sao extremamente satisfatorios uma vez
que o estudo do tema OWA e a implementacao de uma prova de conceito que o
ilustrasse foi conseguido com sucesso
A funcionalidade offline foi adicionada ao produto WOW da Critical Software
SA permitindo a visualizacao de ordens de trabalho e dos seus detalhes mesmo na
ausencia de uma conexao activa a Internet Embora para a solucao implementada
tenha sido utilizada uma abordagem do tipo ldquoutilizador deciderdquo pretende-se que esta
seja convertida para ldquoaplicacao deciderdquo ou mesmo para uma aproximacao hıbrida
semelhante a utilizada pelas aplicacoes estudadas nas seccoes 351 e 352
Para a sua implementacao descrita no capıtulo 4 foram tomadas decisoes de or-
dem pratica que permitissem tornar o trabalho exequıvel nos prazos dados Tentou-
se sempre que estas decisoes afectassem o mınimo em termos de desempenho e de
experiencia para o utilizador Considera-se que a implementacao do modo offline
com uma transicao entre modos do tipo ldquoutilizador deciderdquo (ver seccao 42) reflecte
o compromisso entre o desempenho pretendido e os recursos disponıveis e para alem
51
Resultados e Futuros Desenvolvimentos
de ser um exemplo eficaz das possibilidades que as OWA podem trazer a aplicacao
WOW desenvolvida pela Critical Software e tambem um estudo que pode ser uti-
lizado para analisar a implementacao desta tecnologia noutros produtos da mesma
empresa
Note-se que o principal objectivo do trabalho era ganhar familiaridade com este
tema entender as suas vantagens e desvantagens e compreender as suas limitacoes
Tudo indica que existam varias possibilidades de implementacao deste paradigma
noutros produtos da Critical Software que pela sua natureza podem tambem tirar
partido da execucao offline
52 Trabalho Futuro
O desenvolvimento do conceito e formas de implementacao de OWA continua
em forte desenvolvimento no entanto a sua adopcao ainda nao e generalizada A
dificuldade da sua implementacao em web applications ja existentes e o principal
obstaculo a sua maior divulgacao
Ha tambem um factor que deve ser tido em consideracao a manutencao de
codigo A implementacao de uma versao offline de uma web application requer
a implementacao das mesmas regras de negocio (ou de uma versao simplificada)
utilizadas no servidor Para que isto seja possıvel e necessario ter em conta a
capacidade de processamento do cliente e o factor de duplicacao de codigo que
tornara a aplicacao mais difıcil de manter uma vez que uma alteracao a logica de
negocio do servidor implica tambem uma alteracao a sua versao offline
A prova de conceito implementada permite ja a visualizacao offline dos pedidos
abertos (enviados e recebidos) que constam na pagina principal (este numero e
fixo e pode ser alterado pelo administrador) Uma funcionalidade desejavel seria a
possibilidade de interaccao com a aplicacao em modo offline e sincronizacao com o
servidor quando existisse uma ligacao disponıvel
Foi estudada a utilizacao do modo de execucao ldquoaplicacao assume o estado of-
flinerdquo descrito em 423 e esta seria a forma desejavel para o WOW Offline no
entanto para que esta opcao seja viavel sera necessaria a implementacao de uma
forma eficiente de sincronizacao e armazenamento de dados de uma forma relacional
Para atingir este objectivo podera ser seguida uma polıtica de automacao do pro-
cesso no qual a versao online da aplicacao gera scripts de criacao para as tabelas
necessarias na base de dados da versao offline (nao existe nenhuma ferramenta para
o fazer portanto seria necessaria a sua implementacao) e no qual as paginas HTML
disponibilizadas pelo servidor aos clientes web (browser) servem como templates de
apresentacao de informacao e sao preenchidas de forma semelhante pelo servidor ndash
quando a aplicacao estiver online ndash ou pelo cliente atraves de funcoes em JavaScript
52
Resultados e Futuros Desenvolvimentos
ndash quando a aplicacao estiver offline No entanto no WOW devido a quantidade de
informacao tratada e devido as complexas relacoes entre as diferentes entidades e
de esperar que a complexidade da implementacao de um mecanismo deste tipo torne
esta aproximacao demasiado custosa
O HTML 5 embora um forte candidato ainda nao esta suficientemente desen-
volvido A sua especificacao ainda tem o caracter de Draft (rascunho) e esta sujeita
a modificacoes e a aceitacao e implementacao por parte dos browsers e portanto
de momento foi desconsiderado No entanto no futuro se esta especificacao atingir
um estado de maturidade que permita a sua adopcao devera ser considerada como
um possıvel caminho a seguir
53
Resultados e Futuros Desenvolvimentos
54
Capıtulo 6
Conclusoes
Neste capıtulo sao apresentadas as conclusoes do projecto e consideracoes finais
relativamente a tecnologia estudada
61 Conclusoes
O rapido desenvolvimento tecnologico faz prever que a disponibilidade de ligacao
a Internet seja cada vez mais facil e mais rapido mas vao continuar a existir lugares
onde o acesso e limitado e onde as OWA podem desempenhar um papel de relevo
Por outro lado esta tecnologia pode tambem ser utilizada para melhorar o desem-
penho de paginas web com uma necessidade elevada de imagens ou outros recursos
dispendiosos em termos de espaco e foram ate estudados dois exemplos da utilizacao
desta vertente desta tecnologia em 353
Acredita-se que as OWAs vem responder a uma necessidade real por parte das
web applications actuais e que a evolucao que representam se compara a que se
assistiu dos thin-clients para os fat-clients em termos de autonomia do servidor
A capacidade de oferecer conteudos dinamicos no browser independentemente da
existencia de uma ligacao reune as vantagens tıpicas das web applications como
ausencia de instalacao e actualizacoes instantaneas com as vantagens das aplicacoes
de desktop em capacidade de processamento e armazenamento de dados na maquina
local
As tecnologias disponıveis ate a data estudadas no ambito deste projecto que
permitem o desenvolvimento de OWAs e que apresentam maior maturidade sao o
Gears e o Adobe AIR Ambas se apresentam sobre a forma de plugins que necessitam
de uma instalacao extra para poderem ser utilizadas Apesar de esta instalacao ser
55
Conclusoes
apenas necessaria uma vez podera constituir um factor de desencorajamento a sua
adopcao
O HTML 5 uma especificacao abordada neste documento na seccao 34 podera
ser uma alternativa que oferece funcionalidades offline a uma web application sem a
necessidade de qualquer instalacao no entanto esta especificacao ainda nao foi aceite
pelos principais browsers ndash o documento que define o HTML 5 ainda tem o estatuto
de Draft ndash e ainda nao e possıvel antecipar quando e que isto podera acontecer
Um dos problemas que surge frequentemente na implementacao de uma versao
offline para uma web application e a necessidade de sincronizacao de dados Quando
a informacao pode ser alterada por varios utilizadores simultaneamente e necessario
prever os conflitos que daı podem surgir e dotar a aplicacao de uma forma de os
resolver ou alertar o utilizador para a necessidade de alteracao dos dados
Em conclusao todos os objectivos propostos para este projecto foram atingidos
A prova de conceito implementada reflecte de forma clara as possibilidades oferecidas
pela tecnologia OWA e sera utilizado no futuro para compreender a melhor forma
de o implementar de forma definitiva no WOW
56
Referencias
[Ada08] Lucas Adamski Introducing Adobe AIR security model Fevereiro de2008 Disponıvel em httpwwwadobecomdevnetairarticles
introduction_to_air_securityhtml acedido em Marco de 2008
[Ado08] Adobe Adobe AIR 10 Security White Paper 2008 Disponıvel emhttpdownloadmacromediacompubairdocumentation1air_
securitypdf acedido em Marco de 2008
[Alm08] Dion Almaer Gears as a bleeding-edge html 5 implementa-tion March 2008 Disponıvel em httpalmaercomblog
gears-as-a-bleeding-edge-html-5-implementation acedido emMarco de 2008
[BL96] Tim Berners-Lee The world wide web Past present and future Agostode 1996 Disponıvel em httpwwww3orgPeopleBerners-Lee
1996ppfhtml acedido em Abril de 2008
[CDGH08] Mike Chambers Daniel Dura Dragos Georgita and Kevin Hoyt AdobeAIR for JavaScript Developers OrsquoReilly Media 2008 Disponıvel emhttponairadobecomfilesAIRforJSDevPocketGuidepdf ace-dido em Abril de 2008
[Con99] Jim Conallen Modeling Web Application Architectures with UML Junho1999 Disponıvel em httpwwwumlorgcnUMLApplicationpdf
webappspdf acedido em Maio de 2008
[Ent07] Entrust What is a public key information 2007 Disponıvel em http
wwwentrustcompkihtm acedido em Junho de 2008
[Gar05] Jesse James Garret Ajax A new approach to web applicationsFebruary 2005 Disponıvel em httpwwwadaptivepathcomideas
essaysarchives000385php acedido em Marco de 2008
[Greon] Philip Greenspun Philip and Alexrsquos Guide to Web Publishing 2003(last revision) Disponıvel em httpphilipgreenspuncompandaacedido em Junho de 2008
[Gro02a] App Design Group Thick vs thin client comparison 2002 Disponıvelem httpwwwdonjacobsvwcomimagesweekendspecials
Thick-vs-Thinpdf acedido em Junho de 2008
57
REFERENCIAS
[Gro02b] Technical Research Group Thin Client Tecnhology - WhitePaper 2002 Disponıvel em httpwwwpicktrgcompubs
thinclientwhitepaperpdf acedido em Junho de 2008
[Gro08] Miniwatts Marketing Group World internet usage March 2008Disponıvel em httpwwwinternetworldstatscomstatshtm ace-dido em Abril de 2008
[Hic08] Ian Hickson HTML 5 Draft Recommendation 2008 Disponıvelem httpwwwwhatwgorgspecsweb-appscurrent-work ace-dido em Marco de 2008
[Kha] Olga Kharif Top 10 municipal wifi plans Disponıvel em http
imagesbusinessweekcomss0608muni_wifiindex_01htm ace-dido em Marco de 2008
[Lab07] Mozilla Labs Prism Outubro 2007 Disponıvel em httplabs
mozillacom200710prism acedido em Marco de 2008
[Loo06] Chris Loosley Rich Internet ApplicationsDesign MeasurementandManagement Challenges 2006 Disponıvel em httpwwwkeynote
comdocswhitepapersRichInternet_5pdf acedido em Maio de2008
[Mic08] Microsoft Introduction to Occasionally Connected Applications us-ing Sync Services for ADONET 2008 Disponıvel em httpmsdn
microsoftcomen-ussyncbb887608aspx acedido em Junho de2008
[Nao08] Erica Naone Offline web applications Abril 2008 Disponıvelem httpwwwtechnologyreviewcomread_articleaspxch=
specialsectionsampsc=emerging08ampid=20245 acedido emAbril de 2008
[NJN00] Jason Nieh Yang S Jae and Naomi Novik A comparison of thin-clientcomputing architectures 2000 Disponıvel em httpwwwnclcs
columbiaedupublicationscucs-022-00pdf acedido em Maio de2008
[OrsquoR06] Tim OrsquoReilly Web 20 compact definition Trying again Dezembro2006 Disponıvel em httpradaroreillycomarchives200612
web-20-compact-definition-tryihtml acedido em Marco de 2008
[OrsquoR09] Tim OrsquoReilly What is Web 20 Design patterns and business modelsfor the Next Generation of Software 20053009 Disponıvel emhttpwwworeillynetcompubaoreillytimnews200509
30what-is-web-20html acedido em Marco de 2008
[Rus06] Alex Russel Comet Low latency data for the browser March Marco2006 Disponıvel em httpalexdojotoolkitorgp=545 acedidoem Marco de 2008
58
REFERENCIAS
[Sad97] Darleen Sadoski Clientserver software architecturesndashan overviewAgosto 1997 Disponıvel em httpwwwseicmuedustr
descriptionsclientserver_bodyhtml acedido em Junho de2008
[Sch96] George Schussel Clientserver past present and future 1996
[Smi07] Kevin C Smith Css filters - will the browser apply the rule July 2007Disponıvel em httpcentriclecomrefcssfilters acedido emMarco de 2008
[vK08] Anne van Kesteren The XMLHttpRequest Object W3C Work-ing Draft 15 Abril 2008 Disponıvel em httpwwww3orgTR
XMLHttpRequest acedido em Abril de 2008
[Wil06] Greg Wilkins Why ajax comet July Julho 2006 Disponıvel emhttpwwwwebtidecomdownloadswhitePaperWhyAjaxhtml ace-dido em Abril de 2008
59
REFERENCIAS
60
Anexo A
Screenshots
Algumas imagens de aplicacoes que utilizam funcionalidades offline ilustrativasda tecnologia abordada neste documento
Figura A1 Dialogo apresentado ao utilizador na primeira activacao das funcionalidadesoffline no Google Docs amp Spreadsheets
61
Screenshots
Figura A2 Na activacao das funcionalidades offline e tambem oferecida a possibilidadeda criacao de alguns atalhos por exemplo no ambiente de trabalho
Figura A3 O Google Docs mantem a todo o momento a possibilidade de alteracao destasdefinicoes ou da anulacao dos servicos offline para um dado computador
62
Screenshots
Figura A4 Apos a instalacao do Gears qualquer visita ao Remember The Milk despoletauma sincronizacao que ocorre automaticamente e sem necessidade de intervencao por partedo utilizador
Figura A5 Apos completar a sincronizacao de dados mesmo que a ligacao a Internetseja perdida o Remember the Milk continua disponıvel no browser (com excepcao dasfuncionalidades que pela sua natureza exigem uma ligacao como por exemplo partilhade tarefas e envio de convites)
63
Abstract
The main purpose of this project was to study the Offline Web Applications(OWAs) and its implementation in existent web applications With this goal in minda study was conducted to use this technology in WOW an integrated platform forwork orders and work flow management developed by Critical Software over thelast 6 years and implemented a proof of concept which enables the use of a baseset of functionality for this application regardless of the internet connection state
The concept of OWAs is connected with internet technology and allows accessto a website using the browser even if a connection to the internet is not availableThis concept was considered by Technology Review as one of the most importantemerging technologies in the last quarter of 2007 [Nao08] This study conductedover the WOW platform is intended to aid in the comprehension of the problemsand solutions associated to the use and implementation of OWA as well as thebenefits that it brings to the end user
The Internet and Internet technologies are changing the way in which informa-tion is produced distributed and stored New web applications appeared with newcontent creation and edition functionalities and with it the advantage of infor-mation retrieval from any place and time became possible but with the conditionof Internet connection availability With Internet use growing every year [Gro08]content creation is starting to move to this new platform The adoption of web ap-plications for content creation and edition is becoming more popular and it showsa dependency of a connection that is not always present
The OWAs are a way to solve this problem putting on the client side part ofthe information that was traditionally stored on the server and allows it to be seenand manipulated and helps reducing the server load
This document intends to present different ways in which this technology canhelp web applications as we know them improving the their overall performance andgiving them the ability to run on a browser regardless of the Internet connectionavailability
iii
iv
Agradecimentos
A realizacao e os objectivos alcancados neste projecto nao teriam sido possıveissem a colaboracao de inumeras pessoas Agradeco profundamente a todos os quecontribuıram directa ou indirectamente para o seu sucesso
A minha orientadora Professora Teresa Galvao Dias e ao Project ManagerEngenheiro Marcus Neves que me conduziram e acompanharam no desenvolvimentodeste projecto
A toda a equipa do WOW em especial o Pedro Maurıcio Costa e o Fabio Matosque contribuıram para a minha a minha integracao na Critical Software e que sempresouberam responder a todas as minhas questoes
A todos os que constituem a CSW Porto pelo fantastico ambiente de amizadeque me proporcionaram
Aos colegas de curso e a todos os que me auxiliaram na revisao deste documento
Os meus sinceros agradecimentos
Joao Goncalves da Costa
v
vi
Conteudo
1 Introducao 111 Enquadramento 112 Motivacao 213 Ambito 314 Objectivos 315 Estrutura do documento 3
2 Enquadramento do Projecto 521 Evolucao das arquitecturas de software 5
211 Thin-clients 5212 Fat-clients 6213 Arquitecturas cliente-servidor 7
22 Evolucao na Internet 8221 Paginas web estaticas 9222 Paginas web interactivas e paginas web dinamicas 9223 Web 20 e Ajax 11
23 Offline Web Applications 1324 Comparacao 13
3 Estado da arte 1731 Gears 17
311 Arquitectura 17312 Goggle Gears em dispositivos moveis 20
32 Adobe AIR 20321 Seguranca 22322 Assinatura do codigo 22
33 Mozilla Prism 23331 XML User Interface Language 23332 Prism 25
34 HTML 5 2535 Web applications que usam funcionalidades offline 26
351 Google Reader e Google Docs 26352 Remember the Milk 27353 MySpace e WordPresscom 27
36 Escolha da tecnologia 28
vii
CONTEUDO
4 Desenvolvimento 3341 Como ficar offline 33
411 Funcionalidades disponıveis em modo offline 3442 Modos de execucao 35
421 Modo ldquoutilizador deciderdquo 36422 Modo aplicacao decide 36423 Modo ldquoaplicacao assume o estado offlinerdquo 37
43 Sincronizacao de dados 38431 Quando sincronizar 39
44 WOW 4045 Visao geral sobre a arquitectura do WOW 4146 WOW Offline 42
461 Modo ldquoaplicacao deciderdquo com deteccao automatica da ligacao 43462 Implementacao do modo ldquoutilizador deciderdquo 45463 Especificacao do modo ldquoaplicacao assume o estado offlinerdquo 48
5 Resultados e Futuros Desenvolvimentos 5151 Resultados Obtidos 5152 Trabalho Futuro 52
6 Conclusoes 5561 Conclusoes 55
Referencias 59
A Screenshots 61
viii
Lista de Figuras
21 Arquitectura de um sistema thin-client em duas camadas (a esquerda)e em tres camadas (a direita) Note-se a inclusao do servidor (main-frame) na definicao das camadas desta arquitectura devido a fortedependencia cliente-servidor 9
22 Arquitectura de um fat-client em duas camadas (a esquerda) e emtres camadas (a direita) 10
23 Comparacao do modelo de web aplications sıncrono paginas estaticase interactivas abordados nas seccoes 221 e 222 com o modelo deweb applications Ajax (assıncrono) abordado na seccao 223 Figuraadaptada de http www adaptivepath com 15
31 Esquema UML do processo efectuado pelos recursos do Gears do tipoManagedResourceStore para a actualizacao dos conteudos definidosno ficheiro manifesto 29
41 Exemplo de uma arquitectura de uma web application sem uma ca-mada de abstraccao de dados Figura adaptada de http gears
google com 33
42 Exemplo de uma arquitectura de uma web application com uma ca-mada de abstraccao de dados Figura adaptada de http gears
google com 34
43 Exemplo de uma arquitectura de uma web application com uma ca-mada de abstraccao de dados e um data switch Figura adaptada dehttp gears google com 35
44 Esquema grafico ilustrando uma OWA executando no browser uti-lizando um modo de execucao do tipo ldquoaplicacao deciderdquo com de-teccao automatica do estado da ligacao via pedidos Ajax assıncronosa cada cinco segundos 37
45 Detalhe de um conjunto possıvel de estados e respectivas transicoespara uma dada ordem de trabalho no WOW desde a sua submissaono sistema ate a sua conclusao em fecho ou cancelamento Esta figurarepresenta apenas um exemplo ja que o mapa de estados para umaordem de trabalho e dinamico e pode ser alterado por um admin-istrador Figura retirada de uma brochura promocional do WOWCritical Software SA 41
ix
LISTA DE FIGURAS
46 A pagina inicial do WOW apresenta um resumo das ultimas ordensde trabalho enviadas e recebidas Na imagem pode-se observar atransicao do estado online para offline 44
47 Ilustracao do funcionamento do Gears numa web application que uti-liza um motor Ajax Os pedidos HTTP ou HTTPS podem ser inter-ceptados e tratados localmente ou podem ser feitos a uma maquinaremota consoante se verificarem ou nao as condicoes expressas noponto 311 E representado um acesso a uma base de dados local(fornecida pelo Gears) mas a sua utilizacao e opcional 45
48 Neste exemplo do modo ldquoaplicacao deciderdquo o teste da ligacao e feitoe feito a cada cinco segundos O resultado deste teste nao reflectesempre o estado real da aplicacao podendo levar a aplicacao a tercomportamentos indesejaveis Na figura assinala-se um perıodo detempo no qual a representacao interna do estado da ligacao nao cor-responde a realidade 46
49 Pagina de visualizacao do detalhe de uma ordem de trabalho 47410 Esquema UML que expressa os casos de uso do WOW Offline no
modo ldquoutilizador deciderdquo 48411 Esquema UML que expressa os casos de uso do WOW Offline no
modo ldquoutilizador deciderdquo 49412 Esquema UML que expressa o acto de recolha de dados em modo
online e offline recorrendo ao servidor (modo online) e ao sistemade armazenamento de dados local fornecido pelo Gears (modo offline) 50
A1 Dialogo apresentado ao utilizador na primeira activacao das funcional-idades offline no Google Docs amp Spreadsheets 61
A2 Na activacao das funcionalidades offline e tambem oferecida a possi-bilidade da criacao de alguns atalhos por exemplo no ambiente detrabalho 62
A3 O Google Docs mantem a todo o momento a possibilidade de alteracaodestas definicoes ou da anulacao dos servicos offline para um dadocomputador 62
A4 Apos a instalacao do Gears qualquer visita ao Remember The Milkdespoleta uma sincronizacao que ocorre automaticamente e sem ne-cessidade de intervencao por parte do utilizador 63
A5 Apos completar a sincronizacao de dados mesmo que a ligacao aInternet seja perdida o Remember the Milk continua disponıvel nobrowser (com excepcao das funcionalidades que pela sua naturezaexigem uma ligacao como por exemplo partilha de tarefas e enviode convites) 63
x
Lista de Tabelas
21 Comparacao entre thin-clients e fat-clients 7
31 Comparacao das funcionalidades oferecidas pelo Adobe AIR para asplataformas web e desktop 30
32 Resumo da utilizacao de tecnologias OWA em algumas web applica-tions consideradas na analise do estado da arte 31
xi
LISTA DE TABELAS
xii
Glossario
fat-client Cliente que nao depende totalmente de umservidor central para as suas actividadesde processamento e possui frequentementedispositivos de armazenamento de dados
6ndash8
thin-client Cliente que depende de um servidor centralpara as suas actividades de processamento
5ndash8
web application Sistema web (servidor rede HTTPbrowser) onde accoes do utilizador(navegacao e introducao de informacao)afectam o estado logico da aplicacao
i iii1ndash311ndash1517ndash1921ndash232728 3336ndash3842 5556
API Application Programming Interface 10 1718 2326 28
ASP Linguagem interpretada pelo servidorque permite a criacao de paginas webdinamicas Desenvolvida pela Microsoft
11
BSD Berkeley Software Distribution 28
CSS Cascading Style Sheets 12 2021 2324 46
DHTML Dynamic HyperText Transfer Protocol 24DOM Document Object Model 10 12
20 2324
DTD Document Type Definition 24
xiii
Glossario
ECMAScript Padrao de linguagem de programacaodefinido pela Ecma International que orig-inou o JavaScript e o JScript
24
Flash Conteudo interactivo de um ficheiro emformato SWF E desenvolvido pela Adobee visualizado atraves do Adobe FlashPlayer
21
Flex Framework baseada em XML e Action-Script desenvolvida pela Adobe para a pro-gramacao de Rich Internet Applications(RIA)
21
GPL GNU General Public License 23
HTML HyperText Markup Language 1 10ndash12 2124ndash2649
HTTP HyperText Transfer Protocol 2 26
JMS E uma API em Java que permite a troca demensagens entre componentes de software
42
JSON JavaScript Object Notation permite atroca de dados codificados num formatode texto de simples leitura
12 1828 34
LGPL GNU Lesser General Public License 23
Mozilla Prism Browser simplificado e ldquointerpretadorrdquo deeXtensible User Interface Language (XUL)(tambem designado por XULRunner) queacolhe web applications sem a interfacegrafica habitual de um browser
25
MPL Mozilla Public License 23
OCA Occasionally Connected Application 39OWA Offline Web Application i iii
2ndash515 1725 2628 3133 3651 5255 56
PDF Portable Document Format 21
xiv
Glossario
PHP Linguagem interpretada pelo servidorque permite a criacao de paginas webdinamicas mas que pode tambem ser in-vocada a partir da linha de comandos
11
pagina web estatica Pagina web que devolve sempre a mesmaresposta a todos os pedidos para todos osutilizadores e em qualquer contexto
5 9
RIA Rich Internet Applications web appli-cations que apresentam funcionalidadessemelhantes as desktop applications masque mantem a informacao no lado do servi-dor
5 1520 28
RSS Really Simple Syndication 27
SLA Service Level Agreement 40SQLite Segundo a definicao oficial SQLite is a
software library that implements a self-contained serverless zero-configurationtransactional SQL database engine
17
SSB Site Specific Browser 25SSL Secure Sockets Layer 22SWF ShockWave Flash 21
URL Uniform Resource Locator 18
VPN Virtual Private Network 38
WOW Work Orders Web Plataforma de gestaode ordens de trabalho e do seu fluxo de-senvolvida pela Critical Software SA
i iii28 3340ndash434551ndash5356
WWW World Wide Web 11 1214
XBL eXtensible Binding Language 24XHTML eXtensible HyperText Markup Language 12XML eXtensible Markup Language 11 12
23 2428
XSLT eXtensible Stylesheet Language Transfor-mation
12
XUL eXtensible User Interface Language xiv23ndash25
xv
Glossario
xvi
Capıtulo 1
Introducao
Neste capıtulo enquadra-se o tema do projecto introduzindo alguns dos conceitos
nos quais se baseia Apresentam-se as motivacoes ambito objectivos e a estrutura
deste documento
11 Enquadramento
A Internet foi originalmente concebida para ser um espaco de partilha de in-
formacao onde pessoas (atraves de maquinas) pudessem comunicar Na sua origem
as paginas eram estaticas constituıdas por texto formatado em HyperText Markup
Language (HTML) e ligadas entre si [BL96] Hoje encontramos conteudos cada vez
mais complexos e dinamicos incluindo som vıdeo ou streams multimedia [Loo06] e
em 2005 foi introduzido por [OrsquoR09] o termo Web 20
De acordo com [Greon] um website pode pertencer a uma ou varias das seguintes
categorias
bull Documento ndash um website essencialmente estatico onde alteracoes a uma
parte do conteudo nao tem implicacoes no seu comportamento
bull Base de dados ndash um directorio de informacao organizada em categorias
bull Aplicacao ndash um website dinamico que utiliza uma linguagem executada ou
interpretada do lado do servidor e que processa as accoes ou informacao in-
troduzida pelo utilizador para fornecer um servico ou nova informacao
A ultima destas categorias constitui aquilo que e normalmente designado por
web application O conceito utilizado ao longo deste documento e o mesmo que
o introduzido por Jim Coallen em [Con99] que define web application como um
1
Introducao
sistema web (servidor rede HyperText Transfer Protocol (HTTP) browser) onde
accoes do utilizador (navegacao e introducao de informacao) afectam o estado logico
da aplicacao A sua definicao tenta estabelecer que uma web application e um
sistema de software com estado de negocio1 e que a sua interface de interaccao com
o utilizador e distribuıdo atraves de um sistema web
12 Motivacao
A quantidade de informacao que e produzida e armazenada com recurso a es-
tas web applications disponıveis online tais como e-mail blogues ou mesmo docu-
mentacao tornam por vezes a disponibilidade de ligacao uma condicao necessaria
a produtividade e como consequencia desta barreira muitos potenciais utilizadores
opoem-se a adopcao de produtos web em detrimento das tradicionais desktop appli-
cations
Assegurar o acesso a uma ligacao de Internet e hoje muito mais facil A Internet
movel e ja uma realidade e encontra-se amplamente divulgada mas continuam a
existir diversas situacoes nas quais os utilizadores estao privados de uma ligacao
a Internet tais como uma viagem de metro ou de aviao ou quando se encontram
deslocados do seu paıs de origem e nao possuem nenhum plano de subscricao
Uma OWA consiste numa web application que para alem de manter todas as
caracterısticas anteriores se mantem disponıvel mesmo na ausencia de uma ligacao
a Internet e surge como uma tentativa de estreitar as barreiras existentes entre a
web e o desktop Isto significa que devera existir um mecanismo capaz de assegurar
a manutencao do estado logico da aplicacao quando a ligacao com o servidor e
quebrada permitindo ao utilizador continuar a utilizar a aplicacao e que sera capaz
de informar o servidor do estado em que a aplicacao se encontra quando a ligacao for
reposta A principal vantagem que advem desta possibilidade e evidente eliminar
a necessidade da existencia de uma ligacao a Internet para que a aplicacao possa ser
utilizada
Por outro lado a vontade de integracao de funcionalidades tıpicas das desktop
applications nas web applications foi um dos principais factores que impulsionou o
desenvolvimento deste conceito uma vez que obrigou a uma reflexao ldquopara alem
do browserrdquo e a uma adaptacao das arquitecturas existentes que permitisse ou o
acesso a funcionalidades disponibilizadas pelo sistema operativo ou pelo menos a
funcionalidades semelhantes Pretende-se com esta aproximacao tornar possıveis
interaccoes entre o desktop e o browser tais como arrastar um ficheiro para um
formulario web de upload de conteudos melhor suporte para o historico do clipboard
ou ainda o acesso ao sistema de ficheiros local Atingir estes objectivos reflecte-se
1NT business state
2
Introducao
num novo paradigma que reune as vantagens das web applications tais como os
updates instantaneos ou o facto de nao ser necessaria nenhuma instalacao e das
desktop applications como por exemplo persistencia no armazenamento de dados
acesso a funcionalidades do sistema operativo ou integracao e interaccao com outras
aplicacoes sejam elas web applications ou desktop applications
13 Ambito
Este projecto foi realizado na Critical Software SA no ambito do Mestrado
Integrado em Engenharia Informatica e Computacao (MIEIC) da Faculdade de En-
genharia da Universidade do Porto (FEUP) entre os meses de Fevereiro e Julho de
2008
14 Objectivos
Sao objectivos deste projecto
1 Estudar e documentar o tema das OWAs acompanhando os ultimos desenvolvi-
mentos nesta materia
2 Analisar o estado da arte fazendo uma analise crıtica e objectiva sobre as
diversas metodologias existentes
3 Implementar uma prova de conceito que permita a execucao offline de uma
web application documentando todo o processo
4 Estudar a possibilidade de permitir interaccao com a aplicacao (insercoes e
alteracoes aos dados) em modo offline
Em resumo o objectivo deste projecto foi estudar documentar e implementar
uma prova de conceito relacionada com o tema Offline Web Applications (OWA)
Este tema embora nao seja totalmente novo ganhou destaque ao longo do ano de
2007 com o surgimento de diversas ferramentas que se destinam a aproximar web
applications das desktop applications
15 Estrutura do documento
Este documento esta organizado em diferentes seccoes apresentando o projecto
numa sequencia logica organizada da seguinte forma
No capıtulo 1 faz-se uma breve apresentacao do conceito OWAs e do contexto em
que surge Apresenta-se tambem a estrutura do documento e definem-se os
termos e acronimos utilizados
3
Introducao
No capıtulo 2 faz-se uma descricao da evolucao das tecnologias que antecedem as
OWAs e das vantagens e desvantagens de cada uma como forma de enquadra-
mento
No capıtulo 3 analisa-se o estado da arte nesta materia Introduzem-se diversas
tecnologias directamente relacionadas com o tema deste projecto exemplos de
aplicacoes que as usam e as razoes que fundamentam as escolhas de tecnologias
efectuadas
O capıtulo 4 contem o desenvolvimento do projecto Analisa-se a plataforma
WOW de gestao integrada de ordens de trabalho a tecnologia escolhida e
a forma como foi utilizada para implementar a capacidade de execucao offline
O capıtulo 5 descreve os resultado obtidos comparando-os com as expectativas
iniciais do projecto e apresenta desenvolvimentos futuros e possibilidades de
continuacaoaplicacao do conhecimento adquirido
No capıtulo 6 apresentam-se as conclusoes
4
Capıtulo 2
Enquadramento do Projecto
Neste capıtulo apresenta-se um breve resumo da evolucao das arquitecturas de
software cliente-servidor e a forma como estas se comparam a evolucao da Inter-
net procurando estabelecer uma analogia entre o percurso de ambas as tecnolo-
gias Compara-se o comportamento e arquitectura dos thin-clients as paginas web
estaticas a evolucao dos fat-clients as paginas interactivas Web 20 e Ajax e
defende-se que as OWA constituem um proximo passo logico e evolutivo aproxi-
mando a web do desktop Referem-se ainda os principais factores que justificam a
importancia das OWAs e a estreita relacao que tem com as Rich Internet Application
(RIA)s
21 Evolucao das arquitecturas de software
Os termos thin-client e fat-client sao utilizados quer para descrever arquitecturas
logicas (de software) quer para descrever arquitecturas fısicas (de hardware) Neste
capıtulo excepto quando seja dada indicacao em contrario estes termos referem-se
sempre a uma arquitectura logica
Adicionalmente quando se trata de arquitecturas cliente-servidor pode-se estu-
dar a arquitectura desenvolvida do sistema como um todo da arquitectura do servi-
dor ou da arquitectura do cliente Para evitar equıvocos em especial na seccao 213
especifica-se em cada caso qual o sistema estudado
211 Thin-clients
Um thin-client e um computador cliente ou software cliente que no contexto
de uma arquitectura cliente-servidor depende de um servidor central para as suas
5
Enquadramento do Projecto
actividades de processamento e proporciona um canal de entrada e saıda de in-
formacao entre o utilizador e o servidor remoto Este termo quando aplicado a
hardware refere-se habitualmente a um computador que se destina a ser utilizado
como cliente de rede sem armazenamento local e com capacidade de processamento
reduzida [Gro02b] mas o conceito que aqui se analisa refere-se a uma arquitectura
de software que remonta ao inıcio das aplicacoes cliente-servidor
No inıcio da historia da computacao terminais ligavam-se directamente a main-
frames responsaveis por todo o processamento Nesta arquitectura era necessario
desenvolver duas aplicacoes distintas uma aplicacao central no servidor (main-
frame) responsavel pela gestao de toda a informacao e por todas as operacoes de
comunicacao e uma aplicacao de visualizacao instalada no cliente (terminal) O
papel destes terminais era apenas disponibilizar ao utilizador um meio de comu-
nicacao (entrada e saıda) e apresentacao dos resultados do servidor Nao tinham
um papel activo no calculo nem na logica de negocio e frequentemente nao tinham
tambem nenhum mecanismo de armazenamento de dados
Como vantagens esta arquitectura apresenta uma reduzida necessidade de con-
figuracao e manutencao do lado do cliente Uma vez que o centro do processamento
e manipulacao de dados ocorre no servidor existe tambem uma centralizacao da
informacao [NJN00] que introduz um ponto crıtico de falha1 Actualizacoes e novas
funcionalidades sao faceis de distribuir uma vez que requerem apenas alteracoes no
servidor [Gro02a]
212 Fat-clients
Contrastando com os thin-clients nesta arquitectura os clientes implementam
ja uma parte da logica de negocio e sao responsaveis pelo processamento de dados
Estes fat-clients vieram responder a necessidade crescente de aplicacoes com um
nıvel de interactividade e capacidade de configuracao maior que as oferecidas pela
arquitectura thin-client descrita na seccao 211 Apesar de manterem a sua de-
pendencia do servidor podem tambem ser executados sem uma conexao activa uma
vez que dispoe de armazenamento de dados local o que lhes confere a capacidade
de persistencia de dados e do estado de execucao entre cada sessao
Foi disponibilizando este controlo sobre o estado da aplicacao bem como acesso
a recursos locais (por exemplo sistema de ficheiros e perifericos) que surgiram as
primeiras verdadeiras desktop applications No entanto cada cliente tinha que ser
separadamente instalado no computador pessoal de cada utilizador que pretendesse
utilizar ou interagir com a aplicacao e uma actualizacao ao servidor implicava in-
variavelmente uma actualizacao manual tambem no cliente Uma vez que nem todos
1NT single point of failure
6
Enquadramento do Projecto
Thin-clients Fat-clientsNao toma parte no processamento dedados nem possui acesso ao sistema deficheiros
Participa activamente no processa-mento de dados recorrendo ao sis-tema de armazenamento local para ar-mazenamento de dados
Nao mantem registo do estado logicoda aplicacao entre duas sessoes de uti-lizacao
O acesso ao armazenamento localpermite-lhe manter registo do estadologico da aplicacao entre duas sessoes
O thin-client nao necessita de qualquerinstalacao estando ldquopronto a utilizarrdquo
E geralmente necessario instalar aaplicacao para poder interagir com oservidor
Qualquer update no servidor reflecte-seimediatamente por todos os clientes
Embora a aplicacao cliente possa aler-tar para existencia de novas versoes asactualizacoes tem que ser manualmenteinstalados pelo cliente
O software do cliente destina-se apenasa apresentacao de dados e comunicacaocom o servidor sendo portanto de sim-ples implementacao
Como o software do cliente toma parteactiva no processamento de dadosa sua implementacao requer cuidadosadicionais
Grande mobilidade uma vez que todaa informacao e mantida no servidor
Parte da informacao podera estar ape-nas do lado cliente pelo que existemalgumas restricoes a sua mobilidade
Tabela 21 Comparacao entre thin-clients e fat-clients
os utilizadores actualizam regularmente as suas aplicacoes o servidor tem que estar
preparado para lidar com versoes antigas2 ou descontinuar os seus servicos a uma
parte da sua comunidade de utilizadores ate que estes actualizem os seus sistemas
Como os utilizadores passam a utilizar os seus recursos locais para armazenamento
de dados as alteracoes que nao sejam sincronizadas com o servidor estao apenas
disponıveis nos seus computadores pessoais o que introduz uma restricao a mobili-
dade
Pode-se afirmar que as vantagens dos thin-clients sao as desvantagens dos fat-
clients e que as vantagens dos fat-clients sao as vantagens dos thin-clients tal como
se ilustra na Tabela 21
213 Arquitecturas cliente-servidor
Introduzidos os termos thin-client e fat-client interessa reafirmar que ambos
podem ser vistos como arquitecturas cliente-servidor Um cliente define-se como
um solicitador de servicos e um servidor como um prestador de servicos tal como
definido por [Sch96] e [Sad97]
2NT backward compatibility
7
Enquadramento do Projecto
As arquitecturas cliente-servidor sao categorizadas pela modularizacao com que
sao desenhadas sendo consideradas as seguintes camadas
1 Interface grafica (front-end) atraves da qual os utilizadores interagem com
a aplicacao Quando este modulo e implementado separadamente dos outros
dois constitui uma aplicacao thin-client por si so uma vez que nao implementa
regras de negocio (embora possa definir validacoes de formularios de insercao de
dados por exemplo) A informacao introduzida pelo utilizador e enviada para
o servidor que processa o seu pedido e retorna uma resposta Este processo
repete-se ate que o utilizador atinja o seu objectivo ou se desligue do sistema
2 A logica de negocio tambem designada por camada intermedia que imple-
menta as regras de aceitacao e validacao de todos os dados introduzidos pelo
utilizador E tambem a plataforma de comunicacao que une a camada superior
de visualizacao com a camada de acesso a dados
3 A camada de dados inclui quer o sistema de persistencia de dados onde sao
armazenados os dados relevantes como tambem os mecanismos necessarios
para a sua pesquisa seleccao e alteracao
Os thin-clients quando observados no seu conjunto de cliente e servidor podem
ser vistos quer como sistemas de duas camadas quer como sistemas de tres camadas
dependendo apenas da forma como o servidor for implementado No caso de na
implementacao do servidor nao se distinguir a camada de acesso a dados da camada
da logica de negocio sao designados por sistemas de duas camadas Caso seja feita
esta distincao sao designados por sistemas de tres camadas Ambos os casos sao
ilustrados na Figura 21
Historicamente os fat-clients eram implementados numa arquitectura em duas
camadas Possuıam apenas um modulo de visualizacao de dados designado por
camada de interface e um modulo que implementava toda a logica de negocio e
regras de acesso a base de dados No entanto com a introducao de ligacoes mais
rapidas e de computadores pessoais com maior capacidade de processamento e so-
bretudo devido a complexidade crescente das aplicacoes a logica de negocio e a
camada de acesso a dados tornaram-se independentes Este modelo e designado por
arquitectura em tres camadas e e ilustrado na Figura 22
22 Evolucao na Internet
Ao analisar a evolucao das arquitecturas das aplicacoes desenvolvidas para a
Internet podemos encontrar um paralelismo com a historia da arquitectura de soft-
ware
8
Enquadramento do Projecto
Figura 21 Arquitectura de um sistema thin-client em duas camadas (a esquerda) e emtres camadas (a direita) Note-se a inclusao do servidor (mainframe) na definicao dascamadas desta arquitectura devido a forte dependencia cliente-servidor
221 Paginas web estaticas
Uma pagina web estatica devolve sempre a mesma resposta a todos os pedidos
para todos os utilizadores e em qualquer contexto utilizando o hipertexto como
forma de ligacao entre diversas paginas estaticas
A informacao e armazenada num servidor e o papel do cliente e apenas a apre-
sentacao da informacao Esta forma de disponibilizacao de informacao pode assim
ser comparada com os thin-clients descritos na seccao 211 o utilizador acede a
um website estatico para visualizar informacao sem que o cliente tome parte no
processamento A unica diferenca e que no caso da web estatica a informacao ap-
resentada e sempre a mesma enquanto que nos thin-clients era frequente existir a
possibilidade de insercao de dados no cliente e apos o seu processamento servidor
nova informacao poderia ser apresentada O hipertexto e utilizado para ligar as
paginas entre si numa rede de conteudos relacionados e a navegacao sıncrona era
feita atraves de cliques do rato a cada clique uma nova pagina era apresentada
Este modelo sıncrono e ilustrado na Figura 23
222 Paginas web interactivas e paginas web dinamicas
O JavaScript e uma linguagem interpretada de scripting que tem os browsers
como principal ambiente de acolhimento Os browsers utilizam uma Application
9
Enquadramento do Projecto
Figura 22 Arquitectura de um fat-client em duas camadas (a esquerda) e em tres camadas(a direita)
Programming Interface (API) publica para criar ldquoobjectosrdquo responsaveis por reflectir
e disponibilizar o Document Object Model (DOM) para o motor de JavaScript
A utilizacao mais frequente desta linguagem e a escrita de funcoes que sao em-
bebidas ou incluıdas em paginas web e que interagem com o DOM Uma vez que o
JavaScript e executado localmente (na maquina do cliente e nao no servidor) e capaz
de responder rapidamente a accoes do utilizador tornando a execucao de aplicacoes
no browser mais fluıdas o JavaScript pode tambem detectar accoes do utilizador
que o HTML nao pode tal como o pressionar de uma tecla
Em Dezembro de 1995 a Netscape Communications adicionou suporte para o
JavaScript no browser Netscape Navigator3 e em Agosto de 1996 o browser Internet
Explorer4 da Microsoft passou a tambem a suportar uma versao semelhante desta
linguagem (hoje todos os principais browsers suportam esta tecnologia)
Esta inovacao permitiu tornar os websites mais interactivos mas a sua utilizacao
esteve confinada apenas a este proposito durante um longo perıodo As paginas
passaram a responder activamente a accoes do utilizador (sendo uma das utilizacoes
3Netscape Communications ndash httpbrowsernetscapecom4Microsoft Internet Explorer ndash httpwwwmicrosoftcomwindowsproductswinfamilyie
10
Enquadramento do Projecto
mais vulgares a validacao de formularios) mas continuaram essencialmente estaticas
O JavaScript ainda nao era nesta altura utilizado para processar dados
Tambem nesta altura (1995ndash96) surgiram linguagens server-side como o PHP
Hypertext Preprocessor (PHP) e Active Server Pages (ASP) e o servidor passou a ter
um processamento de dados introduzidos pelo utilizador mais activo Generalizaram-
se as paginas dinamicas capazes de responder a insercao de dados ou outros pedidos
determinados por accoes do utilizador As paginas tornaram-se aplicacoes web ap-
plications
Uma definicao tradicional de web application e um conjunto de paginas web
logicamente agrupadas e geridas por uma unica entidade que tem como pontos de
entrada formularios de insercao de dados (web forms) Uma web application nao e
mais do que uma aplicacao que e acedida atraves de um browser Tem geralmente
uma arquitectura logica em tres (interface logica de negocio e camada de dados)
camadas e estao armazenadas num servidor
Ha dois tipos de web applications
bull Orientadas a apresentacao Sao web applications que geram paginas web in-
teractivas constituıdas por varios tipos de linguagens de anotacao (por exem-
plo HTML eXtensible Markup Language (XML)) e que apresentam conteudo
dinamico como resposta a pedidos efectuados pelo utilizador
bull Orientadas aos servicos Uma web application orientada aos servicos imple-
menta o ponto de acesso para um ou mais de um web service Sao geralmente
clientes de service oriented web applications
Uma vantagem significativa de implementar uma web application de forma a
suportar as funcionalidades padrao dos browsers e que estas terao o mesmo com-
portamento independentemente da plataforma e do browser a partir do qual serao
acedidas No entanto diferentes implementacoes de browsers devido a diferentes
interpretacoes dos padroes definidos tornam por vezes esta tarefa um pouco mais
complicada existindo inclusivamente na web guioes de compatibilidade para os difer-
entes browsers como [Smi07]
223 Web 20 e Ajax
O termo web 20 descreve uma tendencia de utilizacao e de design observada
na World Wide Web (WWW) com o objectivo de melhorar a criatividade partilha
de informacao e principalmente a colaboracao entre utilizadores Estes conceitos
levaram ao desenvolvimento e evolucao de comunidades online tais como redes so-
ciais wikis e blogues
11
Enquadramento do Projecto
O termo tornou-se mais conhecido apos a primeira conferencia OrsquoReilly Media
Web 20 em 2004 e apesar de sugerir uma nova versao da WWW nao se refere a
qualquer evolucao tecnologica mas apenas a alteracoes a forma como os utilizadores
se servem da web De acordo com Tim OrsquoReilly [OrsquoR06] ldquoWeb 20 e uma revolucao
na industria do software causada pela adopcao da web como uma plataforma e pela
tentativa de entendimento das regras para o sucesso nesta nova plataformardquo
O desenvolvimento da Web 20 serve-se muitas vezes de um outro conceito Ajax
O conceito que hoje conhecemos como Ajax muitas vezes incorrectamente de-
scrito como uma tecnologia foi originalmente criado para permitir o desenvolvimento
de web applications que se assemelhassem ainda mais a aplicacoes de desktop Este
conceito foi melhor descrito por [Gar05] como um conjunto de varias tecnologias
que podem ser utilizadas para melhorar a experiencia do utilizador de uma dada
web application introduzindo a capacidade assıncrona de envio de pedidos ou da
recepcao assıncrona de respostas As tecnologias mais frequentemente envolvidas
sao
bull eXtensible HyperText Markup Language (XHTML) e Cascading Style Sheets
(CSS) padrao para a apresentacao
bull interaccao dinamica atraves do DOM
bull troca e manipulacao de dados utilizando XML e eXtensible Stylesheet Lan-
guage Transformation (XSLT) ou JavaScript Object Notation (JSON)
bull pedidos assıncronos utilizando XMLHttpRequest [vK08]
bull JavaScript utilizado para integrar todas estas tecnologias
E importante frisar que o Ajax nao e um produto nem uma tecnologia E um
termo que descreve a utilizacao de um conjunto de tecnologias para o desenvolvi-
mento de web applications com um elevado grau de interactividade Comparativa-
mente as web applications tradicionais o Ajax introduz uma camada de visualizacao
diferente em tres importantes pontos
1 Do lado do cliente existe um motor que serve de intermediario entre a interface
da aplicacao e o servidor
2 A actividade do utilizador despoleta chamadas JavaScript em vez de um pedido
de pagina directamente ao servidor
3 Informacao codificada em XML em vez de paginas HTML e trocada entre o
servidor e o cliente
12
Enquadramento do Projecto
Isto significa que as paginas que utilizam Ajax contem um motor do lado do
cliente composto por um conjunto de funcoes JavaScript responsavel pela comu-
nicacao com o servidor e por actualizar a interface com o resultado dessa mesma
comunicacao
Na Figura 23 ilustra-se a natureza assıncrona do Ajax quando comparada com
as web applications tradicionais Como se pode observar adicionando um mecan-
ismo Ajax a uma web application eliminam-se diversos tempos de espera associados
a comunicacoes com o servidor uma vez que a interface nao fica ldquobloqueadardquo a es-
pera da resposta Obtem-se assim aplicacoes com um comportamento mais fluido
eliminando tempos de espera entre cada ldquocliquerdquo e melhorando a experiencia do
utilizador
23 Offline Web Applications
A informacao grafica (bem como folhas de estilo e scripts) tais como as ima-
gens que constituem o visual de uma web application e ja tratada de forma especial
pelos cada vez mais avancados sistemas de cache (armazenamento temporario) dos
browsers Mas estes nao sao ainda capazes de guardar conteudo criado pelo uti-
lizador nem de apresentar informacao independentemente do estado da ligacao
Numa altura onde se fala de servicos de Internet wireless municipalizados [Kha]
comunicacoes 3G e ligacoes de banda larga a alta velocidade a ligacao a rede global
continua a nao estar permanentemente disponıvel para os utilizadores Na WWW
encontra-se uma importante parte da informacao e das aplicacoes utilizadas para
criar e editar conteudos Por vezes informacao vital para a produtividade pode
desaparecer subitamente do mapa de acesso de um utilizador quando este entra no
metro num aviao ou mesmo quando se desloca para uma cidade ou paıs diferente
do habitual onde nao subscreve um plano de acesso que lhe garanta a ligacao
Permitir o acesso offline a estes recursos assume assim a sua importancia porque
permitira estender o alcance da informacao a locais onde nunca esteve antes e per-
mitira tambem melhorar o desempenho das web applications colocando informacao
mais perto dos utilizadores reduzindo a transferencia de dados apenas ao essencial
24 Comparacao
Nas evolucoes descritas neste capıtulo 2 pode-se observar que existe um par-
alelismo entre a evolucao das arquitecturas tradicionais cliente-servidor e a evolucao
a que se assiste na web O comportamento e arquitectura dos thin-clients assemelha-
se ao das paginas estaticas no sentido em que o browser nao toma parte em qualquer
13
Enquadramento do Projecto
processamento e serve apenas como uma plataforma de interaccao com o servidor
tal como os clientes descritos na seccao 211
A sua proxima evolucao os fat-clients trouxeram parte da capacidade de pro-
cessamento para o lado do cliente Na web foi tambem esta a inovacao tecnologica
a que se assistiu com a evolucao das tecnologias que permitiram a criacao de ver-
dadeiras aplicacoes e com a introducao do Javascript no browser dando ao cliente
a capacidade de processamento de dados A necessidade da separacao do codigo
em camadas logicas advem da crescente complexidade das web applications Esta
pratica permite entre outras coisas melhorar o processo de desenvolvimento e a
capacidade de manutencao de uma aplicacao
Os fat-clients tem tambem a capacidade de armazenamento de dados o que
permite a persistencia de informacoes entre duas sessoes e que algumas operacoes
sejam executadas sem a necessidade de comunicacao com o servidor Este facto pode
tambem ser uma realidade nas web applications com a adopcao das tecnologias OWA
Neste momento assiste-se a uma utilizacao cada vez maior da web como uma
plataforma de desenvolvimento A capacidade de cooperacao na edicao de conteudos
e a mobilidade proporcionada por esta plataforma sao os principais factores que
alimentam esta mudanca e pela primeira vez as aplicacoes tradicionais tem com-
peticao vinda de web applications A prova do reconhecimento da web como plataforma
de desenvolvimento pode ser retirada da aposta de empresas como a Adobe e Mi-
crosoft que lancaram publicamente ferramentas web complementares a produtos
seus tradicionalmente associados ao desktop ndash Acrobatcom5 e Microsoft Office
Live6 Dotar estas web applications da capacidade de execucao offline significa
aproximar a web e o desktop reunindo ldquoo melhor de dois mundosrdquo
As vantagens da mobilidade possıvel atraves da web a cooperacao na criacao e
edicao de conteudos e a possibilidade de utilizar aplicacoes sempre actualizadas e
sem necessidade de instalacao sao algumas das principais vantagens que promovem
esta mudanca que devido as preocupacoes associadas a usabilidade e experiencia do
utilizador esta fortemente associada ao desenvolvimento de Rich Internet Applica-
tion (RIA)s
5Adobe Acrobatcom httpwwwacrobatcom6Microsoft ndash httpsmallbusinessofficelivecom
14
Enquadramento do Projecto
Figura 23 Comparacao do modelo de web aplications sıncrono paginas estaticas e in-teractivas abordados nas seccoes 221 e 222 com o modelo de web applications Ajax(assıncrono) abordado na seccao 223 Figura adaptada de http www adaptivepath
com
15
Enquadramento do Projecto
16
Capıtulo 3
Estado da arte
Apesar de o conceito das OWAs nao ser absolutamente novo as tecnologias que
o suportam sao recentes Neste capıtulo descrevem-se quatro tecnologias que foram
tidas como principais candidatas para o desenvolvimento deste projecto Descrevem-
se ainda alguns exemplos de web applications que disponibilizam actualmente fun-
cionalidades offline e o processo da escolha da tecnologia a utilizar neste projecto
31 Gears
O Gears1 e uma extensao as funcionalidades do browser introduzido pelo Google
que tem como principal objectivo tornar possıvel a visualizacao de paginas de Inter-
net mesmo sem uma conexao disponıvel Encontra-se disponıvel para as platafor-
mas Windows Macintosh e Linux e oferece uma API de Javascript que permite
a scripts aceder a um mecanismo de armazenamento local baseado numa base de
dados SQLite
311 Arquitectura
Esta ferramenta e constituıda por tres componentes principais
bull LocalServer mdash Intercepta pedidos de paginas web e serve-as localmente
bull Database mdash Uma base de dados relacional construıda sobre SQLite
bull WorkerPool mdash Permite executar operacoes de computacao de uma forma
assıncrona sem afectar a capacidade de resposta e fluidez de execucao da web
application Assemelham-se a processos
1Google Inc ndash Mais informacao em httpgearsgooglecom
17
Estado da arte
LocalServer
O modulo LocalServer e uma cache de Uniform Resource Locators (URLs)
controlada pela web application Quando nao existe uma ligacao a Internet e e
feito um pedido para um URL presente nesta cache o LocalServer intercepta-o e
responde ao pedido localmente a partir do disco rıgido do utilizador A aplicacao
pode utilizar dois tipos diferentes de armazenamento local de URLs
bull ResourceStore ndash serve para capturar URLs utilizando exclusivamente a API
de Javascript disponibilizada para o efeito Uma aplicacao podera criar e
utilizar diversos ResourceStores simultaneamente para capturar ficheiros de
dados que necessitam de ser enderecados por um URL tal como um ficheiro
PDF ou uma imagem
bull ManagedResourceStore ndash serve para capturar um conjunto de URLs que estao
relacionados e que sao declarado num ficheiro de manifesto (especificado em
JSON) e que sao automaticamente actualizados O ManagedResourceStore
permite que o conjunto de recursos necessarios para correr uma web application
seja capturado e mantido actualizado automaticamente
A principal diferenca entre estes dois tipos de armazenamento de URLs e a forma
como sao actualizados os seus conteudos Os conteudos de um ManagedResourceStore
sao actualizados sempre que a versao contida no ficheiro de manifesto for alterada
enquanto que os conteudos de um ResourceStore nunca sao actualizados automati-
camente mas apenas quando for explicitamente ordenado pela aplicacao
O LocalServer e capaz de interceptar e servir localmente pedidos de HTTP e
HTTPS sempre que se reunam as seguintes condicoes
1 O URL encontra-se armazenado num ResourceStore ou ManagedResourceStore
2 O sistema de armazenamento local encontra-se activo (enabled = true) Se
o sistema de armazenamento local tiver o atributo requiredCookie o pedido
devera conter um cookie que lhe corresponda
O LocalServer nao necessita de monitorizar o estado da ligacao para atender aos
pedidos Na verdade sempre que as condicoes previamente enunciadas se verificarem
o LocalServer interceptara os pedidos e independentemente do estado da ligacao
a Internet servi-los-a a partir do disco rıgido local Cabera a aplicacao definir qual
o modo em que pretende executar um pedido (online ou offline) definindo o valor
de verdade da propriedade enabled
18
Estado da arte
Database
O modulo Database permite guardar dados da web application assegurando a
sua persistencia Os dados sao guardados de forma relacional no disco rıgido do uti-
lizador2 de acordo com o modelo de seguranca estabelecido pelo Gears3 significando
que uma aplicacao nao pode aceder a conteudos fora do seu domınio
WorkerPool
Nos web browsers uma operacao pesada de computacao pode tornar a interface
lenta e tornar menos agradavel a experiencia do utilizador O modulo WorkerPool
permite correr operacoes em background sem bloquear a interface com o utilizador
Os scripts executados numa WorkerPool nao activam os mecanismos de seguranca
do browser que mostram a mensagem ldquoA script on this page may be busy or may
have stopped respondingrdquo
O WorkerPool comporta-se como um conjunto de processos em vez de threads
Os Workers nao partilham qualquer estado de execucao o que significa que uma
alteracao a uma variavel num Worker nao afecta em nada a execucao de outro
Worker Alem disso os Workers nao herdam automaticamente nenhum codigo dos
seus pais Cada Worker e membro de um WorkerPool e os Workers podem in-
teragir entre si enviando mensagens em formato de texto ou JSON No entanto ha
tambem algumas limitacoes os Workers nao tem acesso ao DOM e objectos como
window ou document nao se encontram acessıveis Isto e consequencia de os Workers
nao partilharem o estado de execucao Mas tem acesso a todas as funcoes built-in
do Javascript A maioria das funcionalidades do Gears pode tambem ser acedida
atraves de uma variavel global especial definida como googlegearsfactory Para
outras funcionalidades especıficas os Workers podem ldquopedirrdquo a pagina principal para
continuar a execucao atraves do envio de mensagens
Outras funcionalidades
bull HttpRequest ndash Este modulo implementa a especificacao W3C XmlHttpRe-
quest definida em [vK08] tornando-a disponıvel para os workers e para a
pagina principal
bull Timer ndash Este modulo implementa a especificacao de timers tal como descrito
por [Hic08] e torna-os disponıveis para os workers e para a pagina principal
2Consultar httpcodegooglecomapisgearsapi_databasehtmldirectories3Consultar httpcodegooglecomapisgearssecurityhtml
19
Estado da arte
bull Factory ndash Esta classe e utilizada para instanciar todos os outros objectos da
API do Gears atraves do seu metodo create Este metodo pode ser utilizado
com os seguintes parametros
ndash betadatabase
ndash betahttprequest
ndash betalocalserver
ndash betatimer
ndash betaworkerpool
312 Goggle Gears em dispositivos moveis
O Gears esta tambem disponıvel em dispositivos Windows Mobile 5 e 6
Os dispositivos moveis estao pela sua natureza frequentemente desconectados
da Internet Mesmo quando possuem uma ligacao as latencias na transferencia de
dados em redes moveis tornam as aplicacoes pouco fluıdas mas o Gears permite
ultrapassar este obstaculo
O Gears funciona exactamente da mesma forma em dispositivos moveis equipados
com o Windows Mobile 5 e 6 como num computador comum Se uma aplicacao tiver
sido implementado com suporte para o Gears entao tambem estara preparada para
ser executada num dispositivo movel mas as limitacoes dos browsers disponıveis
para dispositivos moveis tem que ser consideradas Isto significa prever as condicoes
que permitam uma boa usabilidade devido aos pequenos ecras destes dispositivos
bem como o seu suporte limitado dos padroes do DOM CSS e JavaScript
32 Adobe AIR
O Adobe AIR4 e um runtime compatıvel com diversos browsers e sistemas opera-
tivos que pretende dar aos programadores a possibilidade de combinar diversas tec-
nologias de producao de conteudos para a Internet no desenvolvimento de Rich Inter-
net Application (RIA)s O Adobe AIR mantem uma relacao com o browser mas es-
tende as suas capacidades e tecnologias permitindo o desenvolvimento de aplicacoes
tambem para o ambiente de trabalho com janelas em tudo semelhantes as do sis-
tema operativo Segundo a Adobe o objectivo e complementar o browser dando
aos utilizadores (mas essencialmente aos programadores e equipas de desenvolvi-
mento) a escolha sobre como distribuir as suas aplicacoes Para este efeito o Adobe
AIR tem uma aproximacao diferente do Gears Em vez de ldquoestenderrdquo o browser
acrescentando-lhe funcionalidades o AIR permite tambem o desenvolvimento de
4Adobe - httpwwwadobecomproductsair
20
Estado da arte
aplicacoes que se destinam a ser executadas fora do ambiente do browser mas uti-
lizando as tecnologias comuns da Internet (por exemplo HTML CSS JavaScript
Flash Flex)[CDGH08]
A utilizacao desta tecnologia permite utilizar o browser ou o proprio runtime
Adobe AIR como plataforma de execucao da aplicacao
Na Tabela 31 faz-se uma comparacao das funcionalidades disponıveis de acordo
consoante se escolha o browser ou o desktop como plataforma base para a aplicacao
Uma vez que as aplicacoes Adobe AIR na plataforma desktop tem um caracter
persistente (sao instaladas no computador do utilizador) o Adobe AIR tem um
modelo de seguranca que se assemelha com o das tradicionais aplicacoes desktop
[Ada08] Este modelo e analisado nas seccoes 321 e 322 O ambiente em que
e executado o browser e restringido a execucao de web applications que podem
ser de varias origens (incluindo de origens anonimas ou sem confianca) O Adobe
AIR proporciona acesso a capacidades como acesso a ficheiros que necessitam da
confianca do utilizador
bull HTML ndash O desenvolvimento de aplicacoes para o Adobe AIR pode ser feito
com recurso a tecnologias de HTML e Ajax comuns utilizando as linguagens
de markup existentes distribuıdas como texto e interpretadas em execucao
(runtime)
bull Flash ndash Outra alternativa sera a utilizacao da linguagem Flash Permite a
renderizacao de graficos vectoriais e audiovıdeo com suporte nativo Utiliza
ActionScript para adicionar maior interactividade com o utilizador
bull Flex ndash O Flex e uma framework open source para o desenvolvimento de RIAs
usando Flash As aplicacoes Flex sao na realidade Flash sendo a principal
diferenca o ambiente de desenvolvimento
Como resultado uma aplicacao AIR podera ser implementada
bull Baseada em Flash ou Flex (aplicacoes cujo conteudo base e em ShockWave
Flash (SWF))
bull Baseada em Flash ou Flex tambem com HTML ou Portable Document Format
(PDF) Aplicacoes cujo conteudo de base e em FlashFlex (SWF) com HTML
(HTML JavaScript CSS) ou conteudo PDF incluıdo
bull Baseada em HTML Aplicacoes cujo conteudo base e em HTML Javascript
CSS
bull Baseada em HTML utilizando tambem FlashFlex ou PDF
21
Estado da arte
Os utilizadores interagem com uma aplicacao AIR da mesma forma que interagem
com outras aplicacoes com janelas nativas do seu sistema operativo O runtime e
instalado uma vez no computador do utilizador e a partir desse momento todas as
aplicacoes AIR terao o mesmo aspecto que qualquer outra aplicacao para o desktop
321 Seguranca
Permitir que uma web application aceda ao disco de armazenamento do utilizador
pode comprometer seriamente a sua seguranca Neste sentido o Adobe AIR tem
suporte para assinaturas digitais (Secure Sockets Layer (SSL)) que podem ser com-
pradas pelas equipas de desenvolvimento que o desejem e cujos certificados serao
apresentados ao utilizador no momento da instalacao Um outro aspecto ainda
relativo a seguranca e o mecanismo de isolamento de cada ambiente (sandbox )
322 Assinatura do codigo
O runtime AIR exige que todas as aplicacoes estejam digitalmente assinadas As
assinaturas digitais de codigo sao um processo que visa garantir a integridade da
aplicacao e a identidade do seu autor no momento da instalacao As equipas de
desenvolvimento podem ldquoassinarrdquo uma aplicacao utilizando um certificado atribuıdo
por uma Entidade Certificadora (Certification Authority) ou atraves de um certifi-
cado individual (self signed certificate) Neste momento o Adobe AIR suporta como
entidades certificadoras a Verisign e a Thawte [Ado08]
O instalador apresenta o nome de quem publica a aplicacao quando o codigo tiver
sido assinado com um certificado que apresente confianca ou que esteja encadeado
com um certificado que tenha ja sido aceite no computador em que se esta a instalar
a aplicacao
As equipas de desenvolvimento podem tambem assinar as aplicacoes com um
certificado auto-atribuıdo (um certificado criado por elas proprias) mas neste caso
o instalador apresentara estas aplicacoes como sendo de uma origem nao verificada
O AIR utiliza a infraestrutura publica de chaves [Ent07] suportada pelo arquivo
local do sistema operativo Para que a origem da aplicacao seja reconhecida o
computador onde a aplicacao AIR esta a ser instalada tem que confiar directamente
no certificado que foi utilizado para assinar a aplicacao ou confiar num certificado
que esteja num encadeamento logico de certificados confiados e que se ligue desta
forma ao certificado utilizado para assinar a aplicacao
Todas as aplicacoes AIR tem caracterısticas em comum independentemente da
tecnologia utilizada para o seu desenvolvimento (HTMLFlexFlash) No ambito
de uma aplicacao AIR existem um conjunto de APIs que estao disponıveis e que
tornam possıvel o acesso ao sistema local (leitura e escrita) e a recursos de rede que
22
Estado da arte
de outra forma nunca estariam acessıveis a partir de uma web application comum
Cada aplicacao AIR possui tambem diferentes nıveis de isolamento chamados secu-
rity sandboxes dependendo do tipo de conteudo que esta a ser carregado e do seu
objectivo
bull Isolamento ao nıvel da aplicacao5 ndash E a raiz de cada aplicacao AIR Este
nıvel de isolamento permite o acesso a APIs privilegiadas e especıficas do
AIR Em contrapartida e negado o acesso a algumas APIs que poderiam ser
facilmente utilizadas de forma maliciosa contra o utilizador final Importacao
dinamica de conteudos remotos e geralmente proibido e as tecnicas e mecan-
ismos de geracao dinamica de codigo sao fortemente restringidas Apenas
conteudo carregado directamente da directoria base da aplicacao podera ser
colocado neste nıvel de isolamento
bull Isolamento nao especıfico da aplicacao6 ndash contem todo o outro conteudo
que nao tenha sido carregado directamente para o isolamento da aplicacao
Isto inclui conteudo local e remoto Este tipo de conteudo nao tem acesso
directo as APIs do AIR e rege-se pelas mesmas regras tal como se tivesse sido
carregado por um browser a partir da mesma localizacao (por exemplo HTML
carregado a partir de um domınio remoto comporta-se da mesma forma que se
fosse acedido a partir do browser)
33 Mozilla Prism
331 XML User Interface Language
O eXtensible User Interface Language (XUL) e uma linguagem de anotacao
baseada em XML desenvolvida pela Mozilla Foundation que opera em aplicacoes
Mozilla multi plataforma tal como o Firefox O motor Gecko e a unica imple-
mentacao completa desta linguagem que foi desenhada sobre padroes web comuns
como CSS JavaScript e o DOM e permite o desenvolvimento de interfaces graficas
utilizando elementos pre-definidos tais como window box page textbox radio
button entre outros Infelizmente o XUL nao possui qualquer especificacao formal
ou implementacoes de inter-operabilidade para outros motores que nao o Gecko No
entanto a sua implementacao e licenciada em codigo aberto pelas licencas GNU Gen-
eral Public License (GPL) GNU Lesser General Public License (LGPL) e Mozilla
Public License (MPL)
Enunciam-se algumas caracterısticas desta linguagem
5NT application sandbox6NT non-application sandbox
23
Estado da arte
Liguagem de anotacao poderosa baseada em componentes (widgets) O ob-
jectivo do XUL e permitir a construcao de aplicacoes multi-plataforma em
claro contraste com o Dynamic HyperText Transfer Protocol (DHTML) que se
destina ao desenvolvimento de paginas web Por esta razao o XUL esta orien-
tado a componentes tais como janelas botoes e etiquetas em vez de paginas
cabecalhos de texto e ligacoes de hipertexto Investir tempo e esforco para
atingir este mesmo resultado em aplicacoes baseadas em DHTML compromete
frequentemente a complexidade e desempenho da aplicacao
Baseado em padroes O XUL e um dialecto XML baseado no padrao W3C XML
10 As aplicacoes escritas em XUL sao tambem baseadas em especificacoes
W3C adicionais como HTML 40 CSS DOM nıvel 1 e 2 JavaScript 15
incluindo ECMA-262 Edition 3 (ECMAscript)
Portabilidade entre plataformas Tal como HTML o XUL foi desenhado para
ser independente da plataforma em que e utilizado tornando as aplicacoes
facilmente portaveis entre sistemas operativos nos quais o Mozilla e suportado
Uma vez que o XUL oferece um nıvel de abstraccao dos componentes graficos
de interface que disponibiliza implementa a premissa ldquoum codigo para todas
as plataformasrdquo A interface grafica de todos os produtos centrais Mozilla
(browser instant messenger livro de enderecos) e escrita em XUL com um
unico codigo base que suporta todas as plataformas Mozilla
Separacao entre o nıvel de apresentacao e a logica de negocio Uma das
maiores preocupacoes no desenvolvimento para a Internet e a forte ligacao
entre estas duas camadas (interface e logica) Isto constitui um problema sig-
nificativo no desenvolvimento de grandes aplicacoes especialmente quando o
desenvolvimento e feito em ambientes de equipa porque as capacidades de de-
senvolvimento destas duas partes da aplicacao estao muitas vezes espalhadas
por diferentes elementos O XUL permite uma clara distincao entre a definicao
da aplicacao cliente e da logica de implementacao (XUL eXtensible Binding
Language (XBL) e JavaScript) apresentacao (CSS e imagens) internacional-
izacao (Document Type Definitions (DTDs) e etiquetas de texto em lınguas
especıficas guardados em ficheiros properties) O esquema grafico e apre-
sentacao de uma aplicacao XUL pode ser alterado de forma independente da
sua logica ou implementacao e a aplicacao pode ainda ser traduzida (interna-
tionalization) de forma independente da sua logica implementacao ou apre-
sentacao Este grau de separacao resulta em aplicacoes que sao mais faceis de
manter pelos programadores e facilmente adaptadas por designers e tradutores
24
Estado da arte
Facil adaptacao Outro benefıcio que advem do nıvel de separacao entre logica
de negocio e apresentacao oferecido pelo XUL e a facilidade com que se pode
adaptar uma aplicacao para diferentes clientes ou grupos de utilizadores Um
programador pode utilizar a mesma aplicacao base e adapta-la consoante as
necessidades atraves de diferentes temas (skins) e ficheiros de lınguas Desta
forma uma aplicacao escrita e desenvolvida em Ingles pode ser rapidamente
traduzida para Portugues e distribuıda com outra aparencia mais apropriada
ao cliente alvo
332 Prism
O Mozilla Prism e um browser simplificado e ldquointerpretadorrdquo de XUL (tambem
designado por XULRunner) que acolhe web applications sem a interface grafica ha-
bitual de um browser Baseia-se num conceito designado por Site Specific Browser
(SSB) Um SSB e uma aplicacao com um browser embebido desenhado para exe-
cutar apenas uma web application Nao possui os menus e barras de ferramentas
habituais Um SSB tem uma integracao com o sistema operativo e com o desktop
muito mais estreita do que uma web application acedida atraves de um browser uma
vez que e executado em janela propria
O Prism resulta de uma experiencia da Mozilla e visa reduzir as diferencas entre
as desktop applications tradicionais e as web applications Um dos aspectos focados e
a experiencia do utilizador Numa apresentacao oficial e dito que ldquo[o Prism] pretende
ser uma ponte entre as diferencas que existem entre as aplicacoes tradicionais de
desktop e as web applications explorando novos modelos de usabilidade enquanto
que a linha que as separa se continua a definirrdquo [Lab07]
34 HTML 5
A especificacao HTML 5 [Hic08] que se encontra em fase de desenvolvimento
pelo grupo WHATWG pretende ser uma norma de substituicao dos padroes HTML
4 XHTML 1x e do DOM2 HTML Uma das propriedades que o distingue das tec-
nologias que pretende substituir e precisamente o suporte para OWA e armazena-
mento de dados no cliente de uma forma relacional Nao sendo propriamente uma
tecnologia ndashmas antes uma especificacao ndashe aqui mencionada por ter servido como
referencia a diversas implementacoes de funcionalidades offline e por se considerar
que venha a ter um impacto significativo nas implementacoes de diversos browsers
Dion Almaer defendeu no seu blogue que o Gears era uma implementacao do
HTML 5 No seu artigo ldquoGears as a bleeding-edge HTML 5 implementationrdquo [Alm08]
o autor diz que ambos ndasho Gears e o HTML 5 ndashpretendem dar a web caracterısticas
25
Estado da arte
semelhantes e nao encontrar motivo de ldquocompeticaordquo entre as duas mas que en-
quanto o HTML 5 e uma especificacao o Gears e uma implementacao
No entanto tambem e verdade que o HTML 5 cobre muitos outros pontos para
alem das OWA que saem completamente fora do ambito do Gears Se esta es-
pecificacao atingir um estado de maturidade que possibilite a sua adopcao pelos
principais browsers tornando nativo do browser o suporte OWA entao deixara de
fazer sentido a existencia de uma extensao como o Gears
A especificacao HTML 5 disponibiliza duas APIs relevantes para o tema das
OWA
1 Uma base de dados baseada em SQL que permite o armazenamento de dados
do lado do cliente
2 Uma ldquocacherdquo HTTP que garante a disponibilidade das aplicacoes mesmo quando
o utilizador nao possui uma ligacao a Internet
Estas caracterısticas sao as bases da tecnologia das OWA e tem correspondencia
com os pontos analisados nas seccoes 311 e 311
35 Web applications que usam funcionalidades offline
Nesta seccao apresentam-se algumas web applications que actualmente disponi-
bilizam funcionalidades offline Estas aplicacoes foram escolhidas para uma analise
mais pormenorizada por utilizarem o Gears que tal como descrito na seccao 4 foi
a tecnologia escolhida para o projecto
351 Google Reader e Google Docs
O Google Reader7 e um leitor de feeds RSS Permite gerir a subscricao de varios
sites simultaneamente que disponibilizem conteudos neste formato e foi a primeira
web application da Google com uma versao offline publicamente acessıvel (desde
Junho de 2007)
O Google Reader implementa o modo ldquoutilizador deciderdquo oferecendo na sua
interface um botao que permite alternar entre os modos online e offline
O Google Docs8 e uma web application que permite a criacao e edicao de doc-
umentos de texto folhas de calculo e apresentacoes Era ja publico desde Janeiro
de 2008 que o Google estava a desenvolver uma versao OWA desta aplicacao mas o
acesso a uma versao experimental so foi possıvel a partir de 31 de Maio de 2008
7Google Reader - httpreadergooglecom8Google Docs - httpdocsgooglecom
26
Estado da arte
A implementacao das funcionalidades offline nestas duas aplicacoes seguiu difer-
entes aproximacoes principalmente porque o Google Reader apresenta ao utilizador
informacoes que sao fornecidas por fontes externas enquanto que no Google Docs
a informacao e criada e editada pelo utilizador sobre a forma de documentos
A diferente origem da informacao implica que no Google Reader seja necessario
prever casos de excepcao tal como existirem demasiados itens que necessitam de
ser transferidos para o cliente Nao observar este ponto causa um problema grave
de usabilidade e para evitar tempos de espera demasiado longos e uma interface
com pouca capacidade de resposta as accoes do utilizador o Google Reader apenas
transfere para o cliente os dois mil itens mais recentes na transicao para o modo
offline
352 Remember the Milk
O Remember The Milk9 e uma web application desenvolvida por uma equipa
Australiana que proporciona funcionalidades de agenda gestao de tempo e de tare-
fas e foi uma das primeiras aplicacoes independentes do Google a adoptar o Gears
para acessos em modo offline Permite que os seus utilizadores facam uma gestao
de tarefas agrupando-as em listas adicionando-lhes campos de informacao adicional
ou dando-lhes informacao geografica (recorrendo ao servico Google Maps10) Entre
a sua lista de funcionalidades encontra-se ainda a possibilidade de importar e ex-
portar eventos no formato iCalendar (ics) etiquetas (tags) em tarefas publicacao
Really Simple Syndication (RSS) e partilha de categorias de tarefas de acordo com
diferentes nıveis de permissoes de acesso definidos pelo utilizador
353 MySpace e WordPresscom
O MySpace uma das maiores social networks na Internet anunciou recente-
mente que vai disponibilizar uma versao do seu cliente de e-mail que utiliza o Gears
para acelerar o seu desempenho Numa fase inicial estara disponıvel apenas para
utilizadores que tenham cinco mil ou mais mensagens na sua caixa de correio e
permitira efectuar pesquisas muito mais rapido que a sua versao online
O servico de blogs Wordpresscom anunciou tambem o inıcio da utilizacao desta
tecnologia com o fim de melhorar o desempenho A versao que utiliza esta tecnologia
descarrega e armazena no cliente um conjunto de imagens e scripts que passam a
ter preferencia sobre os seus congeneres online e que permitem acelerar o processo
de carregamento da aplicacao e visualizacao de blogs
9Remember The Milk ndash httpwwwrememberthemilkcom10Google Maps ndash httpmapsgooglecom
27
Estado da arte
O MySpace e o Wordpresscom sao dois exemplos da utilizacao da tecnologia
OWA para optimizacao de web application ja existentes Sem pretenderem disponi-
bilizar uma versao que seja totalmente offline fazem uso do Gears para armazenar no
cliente parte dos recursos frequentemente acedidos na visualizacao das suas paginas
36 Escolha da tecnologia
Apos a analise das tecnologias apresentada nas seccoes 31 a 34 foi necessario es-
tudar a adequacao de cada uma delas ao projecto em questao Desde logo e possıvel
observar que nem todas se dedicam apenas a OWA Por exemplo o Adobe AIR
apesar de ter suporte para OWA apenas disponibiliza algumas das funcionalidades
identificadas como mais indicadas para a execucao do projecto quando utilizado
na sua vertente desktop tal como exposto na Tabela 31 mas a utilizacao desta
vertente implicaria o desenvolvimento de novas interfaces e de novas formas de co-
municacao (troca de mensagens XML ou JSON) A vertente web do Adobe AIR
foca-se mais especificamente nas Rich Internet Applications e permite a reutilizacao
do codigo ja existente (exigindo naturalmente a sua adaptacao e a implementacao
das funcionalidades pretendidas)
A tecnologia escolhida para a realizacao deste trabalho foi o Gears sendo que
um dos principais factores a influenciar esta opcao foi a liberdade introduzida pela
sua licenca Berkeley Software Distribution (BSD)11
Considerou-se o funcionamento desta ferramenta extremamente adequando a
aplicacao no WOW uma vez que o seu principal objectivo e precisamente tornar
possıvel a execucao offline de uma pagina web e por virtude deste facto o Gears tem
uma API concisa e de simples aplicacao pratica uma vez que nao possui quaisquer
outros elementos distractores O funcionamento do seu ManagedResourceStore ex-
emplificado na Figura 31 com a capacidade de actualizacao de recursos definidos
num ficheiro manifesto especificado em JSON pesou tambem nesta decisao
11Sobre a licenca BSD consultar httpwwwopensourceorglicensesbsd-licensephp e http
wwwlinfoorgbsdlicensehtml
28
Estado da arte
Figura 31 Esquema UML do processo efectuado pelos recursos do Gears do tipoManagedResourceStore para a actualizacao dos conteudos definidos no ficheiro manifesto
29
Estado da arte
Funcionalidade RIAs no browser RIAs no desktop
Disponibilidadeda aplicacao
As aplicacoes podem ser facil-mente exploradas e utilizadas
As aplicacoes quando instal-adas tem maior grau de fun-cionalidades e persistencia
Instalacao Nao e necessario qualquer tipode instalacao
As aplicacoes sao instaladasatraves do browser ou descar-regadas e instaladas comouma aplicacao tradicional
Actualizacoes Aplicacoes sao actualizadascarregando conteudos paraum website
O AIR disponibiliza uma APIque permite que as aplicacoessejam actualizadas de umaforma
Sistemas opera-tivos suportados
As aplicacoes podem ser exe-cutadas em diversos sistemasoperativos e browsers
As aplicacoes sao multi-plataforma e podem serinstaladas e executadas emdiversos sistemas operativos ebrowsers
Linguagens deprogramacao
Javascript e disponibilizadopelo browser e ActionScripte disponibilizado pelo AdobeFlash Player
Maquinas virtuais deJavascript e ActionScriptcompatıveis com o browser
Capacidade deexecucao embackground
As RIAs podem ser execu-tadas numa janela do browser
As aplicacoes podem ser ex-ecutadas em background edisponibilizar notificacoes talcomo uma aplicacao tradi-cional
Persistencia A actividade esta limitada asessao do browser Quando obrowser e encerrado toda ainformacao e descartada
As aplicacoes sao instaladas eestao disponıveis no desktopPodem armazenar informacaolocalmente e estao disponıveisoffline
Integracao com odesktop
Integracao com o desktop lim-itada devido a restricoes im-postas pelo browser
As aplicacoes podem acederao sistema de ficheiro ao clip-board eventos notificacoesetc
Controlo da inter-face com o uti-lizador
As aplicacoes sao acedidasatraves de uma janela dobrowser que tem os seusproprios controlos e visualgrafico
As aplicacoes tem um vi-sual grafico proprio em janelapropria
Armazenamentode dados
As aplicacoes tem armazena-mento limitado que pode serreescrito pelo browser
As aplicacoes tem acesso a to-talidade do espaco disponıvellocalmente e a uma base dedados com a possibilidade deencriptacao
Tabela 31 Comparacao das funcionalidades oferecidas pelo Adobe AIR para as platafor-mas web e desktop
30
Estado da arte
Aplicacao Modo de execucao utilizadoGoogle Reader Utiliza o modo ldquoutilizador deciderdquo disponibilizando
ao utilizador um botao para alternar entre os modosonline e offline Como lida com informacao recol-hida de fontes externas de natureza frequentementeefemera o processo de sincronizacao apenas transfereos dois mil itens mais recentes quando passa ao es-tado offline Neste modo sao ainda guardadas in-formacoes de itens lidos e etiquetas atribuıdas quesao sincronizadas com o servidor quando o utilizadorvoltar a activar estado online
Google Docs Utiliza o modo ldquoaplicacao deciderdquo permitindo que outilizador edite os conteudos de documentos de textofolhas de calculo e de apresentacoes independente-mente do estado da ligacao desde o momento em queas funcionalidades offline sao activadas A aplicacaofaz pequenas sincronizacoes com o servidor sempre quenecessario
Remember the Milk Utiliza um modo hıbrido entre ldquoaplicacao deciderdquo eldquoutilizador deciderdquo A aplicacao encarrega-se da sin-cronizacao de dados mas disponibiliza um controlona sua interface que permite despoletar manualmenteeste processo para situacoes em que o utilizador fez al-teracoes recentes e pretende usufruir das capacidadesoffline imediatamente
MySpace O MySpace anunciou a utilizacao de mecanismos dearmazenamento de dados no cliente com recurso atecnologias OWA para melhorar o desempenho doseu cliente web de correio electronico nomeadamenteno que diz respeito a operacoes de pesquisa e or-denacao Inicialmente esta funcionalidade estara ape-nas disponıvel para utilizadores com cinco mil ou maismensagens na sua caixa de correio mas nao e aindaclaro se sera disponibilizada uma versao totalmenteoffline
Tabela 32 Resumo da utilizacao de tecnologias OWA em algumas web applications con-sideradas na analise do estado da arte
31
Estado da arte
32
Capıtulo 4
Desenvolvimento
Neste capıtulo introduz-se a aplicacao WOW e apresenta-se o estudo que foi
feito da adequacao de cada tecnologia para a implementacao da funcionalidade of-
fline nesta plataforma Fazem-se diversas consideracoes sobre opcoes a tomar na
concepcao de OWAs e problemas comuns na sua implementacao bem como sug-
estoes para os resolver O WOW e uma aplicacao ja existente de gestao de ordens
de trabalho e do fluxo de tarefas numa empresa ou organizacao
41 Como ficar offline
Na maior parte das web applications de hoje nao existe uma camada de dados
real A aplicacao exemplificada na Figura 41 ao longo da sua execucao acede
directamente a sua unica fonte de dados (o servidor) atraves de chamadas Ajax sem
que exista uma separacao clara destas duas camadas
Para que uma web application seja capaz de ser executada sem uma ligacao
activa a Internet e mantenha o seu caracter dinamico torna-se necessario incluir
Figura 41 Exemplo de uma arquitectura de uma web application sem uma camada deabstraccao de dados Figura adaptada de http gears google com
33
Desenvolvimento
Figura 42 Exemplo de uma arquitectura de uma web application com uma camada deabstraccao de dados Figura adaptada de http gears google com
um mecanismo de armazenamento de dados local seja uma base de dados ou a
capacidade de acesso ao disco No entanto este mecanismo introduz dois problemas
1 Qual das fontes de dados utilizar quando um utilizador faz um pedido de
informacao
2 A necessidade de implementar uma camada de acesso a dados que seja coerente
quer se use o servidor remoto ou local
Por exemplo em vez de a aplicacao Ajax fazer um pedido relativo as contas de
todos os utilizadores em formato JSON directamente ao servidor remoto podera ao
inves fazer o pedido a um objecto intermedio da camada de dados Este objecto
demonstrado na Figura 42 sera responsavel por implementar uma interface de
acesso a base de dados e retornar um objecto JavaScript com uma representacao da
resposta do servidor
Mas a existencia de uma segunda fonte de dados torna recomendavel tambem
a implementacao de uma camada de data switching que em funcao da existencia
de conexao a Internet e da necessidade de actualizacao dos dados decide se faz o
pedido ao servidor remoto ou se fornece os dados presentes localmente Este objecto
apresentado na Figura 43 decidira de forma transparente para o utilizador se le ou
escreve os dados localmente ou se os enviapede ao servidor remoto e pode tambem
iniciar o processo de convergencia de dados e de resolucao de conflitos
411 Funcionalidades disponıveis em modo offline
Por razoes praticas e provavel que nem todas as funcionalidades da aplicacao
possam ser disponibilizadas em modo offline E necessario escolher quais as fun-
cionalidades a disponibilizar no modo offline da aplicacao e implementar a logica
que decide quando utilizar a base de dados local ou o servidor remoto Apesar do
acesso a base de dados local ser muito mais rapido do que aceder ao servidor o
acesso local nem sempre e preferido Ha varias razoes que podem tornar necessario
escolher o acesso ao servidor em vez do acesso local
34
Desenvolvimento
Figura 43 Exemplo de uma arquitectura de uma web application com uma camada deabstraccao de dados e um data switch Figura adaptada de http gears google com
1 A informacao pode ter uma natureza efemera e nao fazer sentido guarda-la
localmente Exemplo dados em tempo real da bolsa de valores de Lisboa
2 Algumas aplicacoes lidam com informacao que so faz sentido na presenca de
uma ligacao Exemplo Instant Messaging
3 A aplicacao podera escolher apenas guardar a informacao acedida mais fre-
quentemente Exemplo para o utilizador poder alterar a lıngua de apre-
sentacao da aplicacao os conteudos terao que ser guardados em todas as
lınguas disponibilizadas pela aplicacao O custo de implementacao de algu-
mas funcionalidades pode nao compensar o benefıcio
4 A capacidade de processamento ou de armazenamento de dados pode inviabi-
lizar algumas funcionalidades offline Exemplo se uma dada funcionalidade
necessita de uma capacidade de armazenamento de dados para alem do razoavel
de um computador pessoal para ser util (visualizador de mapas)
42 Modos de execucao
Um aspecto que e necessario estudar para qualquer web application que se deseje
disponibilizar offline prende-se com tres modos de execucao que devem ser consid-
erados
1 Utilizador decide o modo de execucao A aplicacao tem modos distintos
de execucao para os estados online e offline geralmente indicados na interface
com o utilizador O utilizador e informado do estado da ligacao e participa na
alteracao de estado de execucao da aplicacao interagindo com a sua interface
2 Aplicacao decide o modo de execucao Pode ser implementado na propria
aplicacao um mecanismo de deteccao do estado da ligacao (por exemplo atraves
35
Desenvolvimento
de chamadas Ajax periodicas) transitando de estado e sincronizando automati-
camente Desta forma o utilizador nao precisa de participar na alteracao de
estado a menos que exista um conflito de dados que requeira a sua atencao
3 Aplicacao assume sempre o estado offline Outra hipotese sera imple-
mentar uma web application que assume sempre estar na ausencia de uma
ligacao ao servidor de dados Esta aplicacao responde aos pedidos do uti-
lizador efectuando pedidos de informacao ao servidor mas nao dependendo
de uma resposta valida para mostrar a informacao que ja tinha disponıvel an-
teriormente A sincronizacao de dados com o servidor e tentada sempre que
existam dados para submeter e uma accao do utilizador
421 Modo ldquoutilizador deciderdquo
Neste modo de execucao quando a aplicacao esta online comunica com o servidor
remoto quando esta offline comunica com a base de dados local A informacao tem
que ser sincronizada sempre que se muda de modo A principal vantagem desta opcao
e que e a mais simples de implementar mesmo para uma aplicacao ja existente e
portanto uma forma expedita de disponibilizar uma OWA No entanto tem tambem
algumas desvantagens que devem ser consideradas
1 O utilizador tem que se lembrar de fazer a alteracao de estado de execucao
Caso contrario podera estar a trabalhar inadvertidamente numa versao offline
com dados antigos ou nao ter a informacao necessaria se perder subitamente
a ligacao
2 Se a ligacao for intermitente o utilizador tera ou que escolher um dos modos
de execucao ou estar constantemente a trocar
3 Uma vez que a base de dados nao esta sempre actualizada nao podera ser
utilizada para melhorar a rapidez de execucao da aplicacao quando em modo
online
422 Modo aplicacao decide
A deteccao do estado da ligacao pode ser implementada atraves de um pedido
assıncrono ao servidor tal como ilustrado na Figura 44 O resultado deste pedido
definira o estado online (em caso de sucesso) ou offline (em caso de falha) A
sincronizacao de dados podera ser feita sempre que ocorra uma transicao do es-
tado offline para o estado online No entanto este metodo nao se revela eficiente
36
Desenvolvimento
Figura 44 Esquema grafico ilustrando uma OWA executando no browser utilizando ummodo de execucao do tipo ldquoaplicacao deciderdquo com deteccao automatica do estado daligacao via pedidos Ajax assıncronos a cada cinco segundos
para grandes aplicacoes uma vez que requer a troca de mensagens demasiado fre-
quentes com o servidor que se destinam exclusivamente a monitorizacao do estado
da ligacao
423 Modo ldquoaplicacao assume o estado offlinerdquo
Uma aplicacao transparente funciona assumindo sempre que esta em modo of-
fline ou pelo menos que pode perder a ligacao a qualquer momento Neste modo
tira-se o maximo partido do armazenamento local e fazem-se pequenas mas contınuas
sincronizacoes com o servidor sempre que este esteja disponıvel A sincronizacao de
dados tambem e feita sempre que se volta ao estado online
As vantagens de uma web application transparente sao as seguintes
bull Uma melhor experiencia para o utilizador uma vez que este nao tem que se
preocupar com o estado da ligacao ou com a transicao de estados
bull A aplicacao funciona de forma coerente mesmo que a ligacao seja intermitente
bull Uma vez que o armazenamento local e mantido actualizado pode ser utilizado
para melhorar o desempenho da aplicacao
Foram identificadas as seguintes desvantagens
bull E mais difıcil de implementar e a sincronizacao acarreta cuidados especiais
bull E necessario um cuidado adicional para evitar que as operacoes de sincronizacao
frequentes que ocorrem automaticamente nao afectem os tempos de resposta
da aplicacao
bull Os testes a aplicacao sao mais complexos uma vez que a sincronizacao de dados
nao ocorre em resposta a uma accao do utilizador
37
Desenvolvimento
43 Sincronizacao de dados
A sincronizacao de dados consiste na capacidade de identificar e transferir pe-
riodicamente a versao mais actual dos dados entre o cliente e o(s) servidor(es)
Independentemente do modo de execucao escolhido e mesmo do estado da ligacao
do utilizador a informacao armazenada localmente e a informacao armazenada no
servidor estarao por vezes dessincronizadas Isto podera acontecer sempre que por
exemplo
bull O utilizador faz alteracoes em modo offline
bull A informacao e partilhada e pode ser alterada por uma entidade externa
bull A informacao e fornecida por uma entidade externa
Resolver estas diferencas de forma a que a informacao local e remota encontrem
a igualdade chama-se sincronizacao de dados Ha varias aproximacoes possıveis
para este efeito que dependem da natureza da aplicacao cada uma com vantagens
e desvantagens
A capacidade de suportar a mobilidade dos utilizadores torna-se cada vez um
ponto mais importante de uma web application Para uma organizacao de dimensao
global e vital garantir que os seus colaboradores tem acesso a mesma informacao
que tem disponıvel nos seus postos de trabalho mesmo quando estao fora Na maior
parte dos casos estes colaboradores terao acesso a um computador portatil um
desktop Smartphone ou PDA e atraves destes poderao ter acesso a sua informacao
directamente atraves de ligacoes encriptadas Virtual Private Network (VPN) de um
servidor web ou de outro mecanismo de rede
Esta solucao e simples de implementar mas infelizmente para a maioria dos
colaboradores com grande factor de mobilidade nao e satisfatoria As principais
desvantagens sao as seguintes
bull Requisitos de ligacao Para permitir que os utilizadores acedam a sua in-
formacao e necessario garantir a capacidade constante de comunicacao pelo
menos durante o tempo necessario que assegure a sua transferencia
bull Velocidade de ligacao sem persistencia de dados e em ligacoes de fraca
qualidade a usabilidade por vezes torna-se inaceitavel
bull Ponto crıtico de falha Com este tipo de solucao todos os utilizadores de-
pendem da base de dados que armazena informacao vital para o funcionamento
do cliente
38
Desenvolvimento
bull Scalability do servidor A medida que novos utilizadores sao adicionados ao
sistema o desempenho do servidor e afectado levando a necessidade de maior
capacidade de armazenamento eou processamento
De acordo com a documentacao da Microsoft Sync Framework [Mic08] uma
solucao alternativa consiste em implementar uma Occasionally Connected Appli-
cation (OCA) Uma OCA permite a um utilizador remoto continuar a aceder a
sua informacao mesmo depois de perder a ligacao mas em vez de recorrer a um
servidor recorre a informacao armazenada no seu dispositivo local Para preencher
localmente a informacao que o utilizador necessita uma OCA possui mecanismos
de sincronizacao de dados que sao oferecidos por esta framework
431 Quando sincronizar
Uma das solucoes mais simples de implementar passa por disponibilizar um
mecanismo manual que despoleta a sincronizacao Diz-se manual porque e o uti-
lizador que escolhe quando sincronizar e pode ser implementada simplesmente
fazendo o upload de toda a informacao para o servidor e depois fazendo o download
da copia mais recente da informacao antes de voltar a ficar offline Para que esta
seja uma opcao viavel e necessario que
bull O volume de dados seja suficientemente pequeno para que possa ser transferido
do servidor para o cliente num espaco de tempo aceitavel
bull Que o utilizador indique explicitamente que quer mudar para o estado offline
ou online pressionando um botao da interface
Contudo podem ser identificados alguns problemas relacionados com esta abor-
dagem
bull Os utilizadores nem sempre podem prever o estado das suas ligacoes A ligacao
pode-se perder subitamente ou ter um caracter intermitente
bull O utilizador pode esquecer-se de efectuar a sincronizacao
Outra opcao sera conjugar a sincronizacao de dados com o modo de execucao
transparente A sincronizacao ocorre automaticamente em background de forma
nao intrusiva para o utilizador A aplicacao comunica com o servidor regularmente
efectuando pequenas trocas de dados com o objectivo de manter o sincronismo da
informacao local e remota Esta abordagem pode ser implementada com pedidos
Ajax assıncronos e regulares ao servidor o que permite manter a interaccao com a
interface fluıda evitando bloqueios Estes pedidos sao feitos prevendo as situacoes
39
Desenvolvimento
de disponibilidade ou indisponibilidade (timeout) do servidor Uma outra opcao
sera permitir que o servidor comunique essas alteracoes utilizando Comet1 tal como
descrito em [Wil06] e [Rus06] As vantagens destas aproximacoes sao
bull A informacao esta disponıvel a qualquer altura que o utilizador decida ficar
offline ou que a ligacao seja acidentalmente perdida
bull O desempenho da aplicacao pode ser melhorado quando se estiver a utilizar
uma ligacao a Internet lenta uma vez que o acesso a dados locais e mais
eficiente do que a consulta de dados ao servidor
44 WOW
O WOW e uma plataforma integrada de gestao de ordens de trabalho ja ex-
istente e desenvolvida pela Critical Software SA a qual se pretende adicionar a
capacidade de execucao offline Esta aplicacao e extremamente dinamica e con-
figuravel com um conjunto extremamente rico de funcionalidades das quais se
destacam
bull Gestao de Ordens de Trabalho ndash suportando a gestao dos pedidos desde a
sua criacao ate ao seu fecho tomando em conta os diferentes tipos de pedidos
(ordens de trabalho pedidos de informacao melhorias resolucao de problemas
etc) e diferentes tipos de accoes possıveis para cada um (Figura 45)
bull Monitorizacao de alteracoes ndash Historico de mudancas anexos e estados criando
relatorios de alteracao automaticamente (o que por quem e quando)
bull Uso de Service Level Agreements (SLAs) ndash E possıvel associar a um pedido um
SLA que define qual o perıodo de tempo atribuıdo a resolucao de um pedido
controlando e agilizando a resolucao do mesmo
bull Utilizacao de queries de utilizador configuraveis que permitem acesso rapido
a determinadas ordens de trabalho de acordo com o filtro configurado (por
exemplo ldquoPara mimrdquo ldquoPara o Grupordquo ldquoPelo Grupordquo)
bull Gestao do relacionamento entre pedidos
bull Pesquisa e filtragem de ordens de trabalho
bull Exportacao de dados em formatos padrao (PDF DOC ou XLS)
bull Integravel com solucoes externas
40
Desenvolvimento
Figura 45 Detalhe de um conjunto possıvel de estados e respectivas transicoes para umadada ordem de trabalho no WOW desde a sua submissao no sistema ate a sua conclusaoem fecho ou cancelamento Esta figura representa apenas um exemplo ja que o mapa deestados para uma ordem de trabalho e dinamico e pode ser alterado por um administradorFigura retirada de uma brochura promocional do WOW Critical Software SA
A utilizacao de uma ferramenta deste tipo por parte de uma empresa ou orga-
nizacao oferece vantagens quer a gestao de topo quer aos colaboradores individuais
para os colaboradores individuais o WOW e uma aplicacao onde estao registadas
todas as tarefas contribuindo activamente para o desenvolvimento em ambientes
multi-tarefa e para a organizacao pessoal das tarefas de acordo com prioridades
Para a gestao de topo esta ferramenta permite obter uma visao global do estado da
organizacao em termos de tempo gasto por tarefa executada sendo uma mais valia
para a previsao e gestaoalocacao de recursos
45 Visao geral sobre a arquitectura do WOW
O WOW e interessante nao so do ponto de vista de produto como tambem do
ponto de vista de plataforma Existem diversos plug-ins que estendem as funcional-
idades do WOW e existem ate projectos que pretendem usar a arquitectura do
WOW para criar produtos com fins diferentes do inicial (por exemplo o WOW-
Storm ndash um sistema de registo e classificacao social de ideias)
De modo a conseguir ter essa expansibilidade a plataforma WOW assenta sob
uma arquitectura distribuıda modular e expansıvel com uma componente central
ndash o core ndash estruturado em camadas logicas E no core que se situam todas as
1O Comet e um conceito semelhante ao Ajax introduzido por Alex Russel mas no qual e o servidor quetoma a iniciativa de ldquoenviarrdquo os dados ao browser sem que este tenha que efectuar um pedido Tambem econhecido por Ajax Push Reverse Ajax ou HTTP Streaming
41
Desenvolvimento
funcionalidades base da aplicacao quer a nıvel logico funcional e de apresentacao
quer a nıvel de gestao e configuracao
E possıvel a execucao de varias instancias do core simultaneamente em servidores
distintos o que permite a alta escalabilidade e disponibilidade desta aplicacao A
consistencia dos dados fica sempre garantida atraves da partilha da base de dados
e pelo balanceamento dos pedidos uma vez que cada um e encaminhado para uma
unica instancia
O WOW apresenta tambem a vantagem de ser uma plataforma extensıvel E
possıvel adicionar novas caracterısticas a plataforma atraves de componentes que se
podem ser divididos em duas categorias plugins e connectors
Os plugins sao componentes que se encontram no mesmo no fısico que a aplicacao
partilhando do mesmo contexto de execucao do core Sao assim uma forma mais
directa de obter informacao da plataforma visto que nao possuem restricoes de
acesso aos dados nem dependencias externas A arquitectura deste componente tera
assim que permitir varias execucoes instanciadas cada uma associada a um core
Por outro lado os connectors sao componentes que se encontram distribuıdos
comunicando externamente com o core Quer a sua execucao quer a obtencao
dos dados estao assim dependentes de interfaces de comunicacao externas que a
plataforma disponibiliza Estes componentes ao contrario dos plugins sao instan-
ciados unicamente e recorrem ao protocolo de comunicacao Java Messaging Service
(JMS) para comunicar com o core
46 WOW Offline
Para alem das opcoes tomadas relativamente a tecnologia a utilizar surgiu
tambem a necessidade de optar por um dos modos de execucao apresentados na
seccao 42
Das tres opcoes possıveis foi o modo ldquoaplicacao assume o estado offlinerdquo descrito
na seccao 423 que mereceu a maior atencao uma vez que reune as vantagens de
uma experiencia mais positiva para o utilizador (uma vez que este nao tem que
participar activamente na alteracao do modo execucao como descrito na seccao 421)
e nao constitui uma sobrecarga excessiva para servidor (como o modo abordado na
seccao 422)
No entanto esta opcao comprometia a complexidade da implementacao para alem
dos objectivos propostos para este projecto e para cumprir o prazo dado foi tomada
a decisao de implementar o modo ldquoutilizador deciderdquo especificando apenas de forma
teorica o modo ldquoaplicacao assume o estado offlinerdquo
As caracterısticas do Gears foram ja descritas na seccao 31 Na Figura 47
mostra-se a sua forma de funcionamento quando integrado numa web application
42
Desenvolvimento
Nesta figura representa-se o modulo LocalServer do Gears como um ponto de de-
cisao Aqui sao testadas as condicoes que determinam se o pedido sera interceptado e
servido localmente ou se prossegue para uma maquina remota E tambem represen-
tada uma base de dados que corresponde ao modulo Database mas que podera nao
ser utilizada Este modulo tal como o modulo Workerpool tem caracter opcional
e sao utilizados consoante os requisitos da aplicacao
A plataforma WOW lida com mais dados do que e necessario passar para o
lado do cliente Em conformidade com o ja exposto na seccao 411 volta-se a
frisar que nao se pretende recriar toda a logica de negocio nem os conteudos da
base de dados no cliente pela sua complexidade e volume de dados Pretende-se
pelo contrario permitir que os utilizadores tirem partido da capacidade de poder
consultar as suas ordens de trabalho quando nao dispoe de uma ligacao transferindo
apenas o essencial para isto seja possıvel
A pagina inicial do WOW apresenta um resumo das ordens de trabalho abertas
ndash enviadas e recebidas ndash que se pretende permitir visualizar offline (ver Figura 46)
Como prova de conceito foi efectuada uma abordagem pragmatica das varias possi-
bilidades descritas na seccao 42
461 Modo ldquoaplicacao deciderdquo com deteccao automatica da ligacao
A primeira abordagem estudada para a disponibilizacao das funcionalidades of-
fline foi o modo ldquoaplicacao deciderdquo com deteccao automatica de ligacao apresentado
na seccao 422 Para que isto seja possıvel foi implementado um mecanismo de ver-
ificacao periodica do estado da ligacao atraves de chamadas Ajax assıncronas O
resultado destes pedidos determina o estado da aplicacao executando as tarefas de
sincronizacao de dados sempre que pertinente Este metodo embora imediato e
simples de implementar depressa se revelou inadequado para o projecto devido ao
elevado consumo de recursos do servidor que a utilizacao intensiva faz esperar a
comunidade da plataforma WOW no principal cliente excede os 7000 utilizadores
Foi estimado que para uma utilizacao de fluidez aceitavel o estado da ligacao deveria
ser testado a cada cinco segundos Assumindo uma adesao (previsao pessimista) de
1 aos servicos offline assistir-se-ia a cerca de 840 pedidos adicionais por minuto
Mas o principal problema desta aproximacao prende-se com o facto de a ver-
ificacao ser feita em intervalos de tempo discretos levando a possibilidade de a
aplicacao poder ter em dado momento uma representacao errada do seu estado
real da ligacao Este problema e ilustrado na Figura 48 onde se ve claramente a
discrepancia entre o estado real da ligacao e a representacao interna que esta tem
Note-se que nesta janela de tempo qualquer accao do utilizador que exija uma
resposta sıncrona do utilizador leva-lo-a para um ldquobeco sem saıdardquo onde nao tera
43
Desenvolvimento
Figura 46 A pagina inicial do WOW apresenta um resumo das ultimas ordens de trabalhoenviadas e recebidas Na imagem pode-se observar a transicao do estado online para offline
acesso a versao offline porque a aplicacao nao fez a transicao automatica nem acesso
a versao online porque na verdade nao possui uma ligacao O que acontecera nesta
situacao sera uma tentativa de acesso ao servidor por parte da aplicacao numa
altura em que este se encontra indisponıvel e o resultado sera uma mensagem de
ldquopedido excedeu o tempordquo apresentado pelo browser Este e um estado sem retorno
porque apos o browser apresentar esta mensagem todos os recursos JavaScript ficam
indisponıveis tornando impossıvel o regresso ao estado anterior ou o tratamento do
erro de qualquer outra forma No entanto as chamadas Ajax podem ser tratadas de
forma especial para a eventualidade de falha e portanto nao constituem problema
44
Desenvolvimento
Figura 47 Ilustracao do funcionamento do Gears numa web application que utiliza ummotor Ajax Os pedidos HTTP ou HTTPS podem ser interceptados e tratados localmenteou podem ser feitos a uma maquina remota consoante se verificarem ou nao as condicoesexpressas no ponto 311 E representado um acesso a uma base de dados local (fornecidapelo Gears) mas a sua utilizacao e opcional
462 Implementacao do modo ldquoutilizador deciderdquo
Este modo de execucao foi ja descrito na seccao 421 e a sua principal carac-
terıstica e ser o utilizador a decidir se a aplicacao deve utilizar um servidor remoto
ou a maquina local como fornecedor de dados
Relativamente ao WOW o WOW Offline na vertente ldquoutilizador deciderdquo vem
alterar os seus casos de uso dando ao utilizador a possibilidade de alterar o estado
de execucao da aplicacao (entre online e offline) Resta dizer que no modo online se
mantem todas as funcionalidades anteriores e que no modo offline torna-se possıvel
visualizar os conteudos da pagina principal do WOW (Figura 46) e os detalhes das
ordens de trabalho (Figura 49) tal como expressa a Figura 410
Esta aproximacao foi utilizada na prova de conceito do WOW adicionando um
controlo a interface desta aplicacao que permite ao utilizador alternar entre os esta-
dos online e offline Na transicao de online para offline sao descarregados os recursos
necessarios para a execucao desta aplicacao sem recorrer a Internet Para o fazer
45
Desenvolvimento
Figura 48 Neste exemplo do modo ldquoaplicacao deciderdquo o teste da ligacao e feito e feito acada cinco segundos O resultado deste teste nao reflecte sempre o estado real da aplicacaopodendo levar a aplicacao a ter comportamentos indesejaveis Na figura assinala-se umperıodo de tempo no qual a representacao interna do estado da ligacao nao corresponde arealidade
e utilizado um recurso ResourceStore e um ManagedResourceStore (introduzidos
em 311) O primeiro e utilizado para armazenar a pagina principal do WOW ndash do-
ravante designada por homejsp ndash e o segundo e utilizado para armazenar imagens
folhas de estilo CSS e scripts JavaScript
Para a implementacao deste modo de execucao foram identificadas as seguintes
tarefas
1 Guardar informacao que permita a recriacao das paginas que se pretende
disponibilizar offline (utilizando o Gears)
2 Disponibilizar um controlo que permita alterar o estado de execucao atraves
da interaccao com a pagina principal
3 Durante a sincronizacao de dados apresentar o progresso da transferencia de
dados
O primeiro passo consistiu na identificacao de todos os conteudos que sao necessarios
transferir para a execucao offline Foi utilizado um recurso do Gears do tipo
ManagedResourceStore que recorre a um ficheiro manifesto para identificar to-
dos os ficheiros que deve transferir Este recurso e gerido automaticamente pelo
Gears transferindo para o cliente a versao mais recente sempre que e necessario
isto e sempre que exista um ficheiro manifesto com uma identificacao de versao que
seja diferente da actualmente disponıvel no cliente Uma vez identificados todos
ficheiros necessarios para a execucao offline num (ou mais) ficheiros manifesto o
Gears encarrega-se da sua actualizacao mas o preenchimento destes ficheiros man-
ifesto e manual o que se traduz num cuidado extra na manutencao da aplicacao
A forma como esta informacao e guardada deve tambem ser cuidadosamente
estudada A opcao mais flexıvel passa por utilizar o modulo Database apresentado
na seccao 311 e guardar a informacao de uma forma relacional Para a recriacao
das paginas pode ser disponibilizada uma versao HTML da pagina que funciona
46
Desenvolvimento
Figura 49 Pagina de visualizacao do detalhe de uma ordem de trabalho
como template nao possui quaisquer dados e e utilizada apenas em modo offline E
preenchida para cada pedido retirando os dados relevantes da base de dados
O modelo de dados do WOW torna esta opcao extremamente trabalhosa uma
vez que as entidades envolvidas na geracao de cada pagina de informacao sobre
cada ordem de trabalho tem relacoes de dependencia complexas seguindo padroes
muito variaveis Por exemplo em cada ordem de trabalho existe um formulario que
permite a sua progressao de estado com diversos campos opcionais e obrigatorios
este formulario e definido pelo administrador e esta relacionado nao apenas com o
tipo de ordem de trabalho mas tambem com o estado actual em que esta se encontra
e a accao que se pretende realizar O elevado numero de combinacoes de tipos de
ordem de trabalho estados e accoes que existem num dado momento juntamente
com a sua possibilidade de alteracao obrigariam a implementacao de uma logica de
negocio complexa o que esta fora do ambito deste projecto
47
Desenvolvimento
Figura 410 Esquema UML que expressa os casos de uso do WOW Offline no modoldquoutilizador deciderdquo
463 Especificacao do modo ldquoaplicacao assume o estado offlinerdquo
A aproximacao para o modo ldquoaplicacao assume o estado offlinerdquo foi tambem
dividida em varias tarefas
1 Guardar informacao que permita a recriacao da pagina principal do lado do
cliente no estado offline (utilizando o Gears)
2 Dotar a aplicacao do cliente de um mecanismo de deteccao da ligacao
3 Identificar os ldquomomentos chaverdquo em que devera ocorrer sincronizacao de dados
4 Implementar a sincronizacao de dados
A sincronizacao de dados deve ser feita em ambas as transicoes online-offline e
offline-online quer para transferir novos dados do servidor (os pedidos podem ser
alterados por outros utilizadores) quando se transita do estado quer para comunicar
eventuais alteracoes feitas em modo offline
Relativamente ao WOW o WOW Offline na vertente ldquoaplicacao assume o es-
tado offlinerdquo vem alterar os seus casos de uso dando ao utilizador a possibilidade
de activar esta funcionalidade A partir do momento que a funcionalidade esta ac-
tivada o utilizador deve tambem ter a possibilidade de gerir algumas preferencias
relacionadas com privacidade de dados Devera ter a hipotese de desactivar o ar-
mazenamento local e de remover todos os dados ja armazenados tal como descrito
na Figura 411
48
Desenvolvimento
Figura 411 Esquema UML que expressa os casos de uso do WOW Offline no modoldquoutilizador deciderdquo
A primeira vez que o WOW Offline e acedido por um cliente e caso seja detec-
tada a presenca do Gears todos os recursos necessarios a sua execucao sao trans-
feridos Todos os acessos posteriores serao feitos a estes recursos locais (recorda-se
que o Gears pode ser utilizado para os manter actualizados recorrendo ao Managed-
ResourceStore 311)
Atraves do JavaScript e possıvel interceptar os eventos de load e unload da
pagina que sao despoletados sempre que ocorre um re-acesso da mesma (incluindo
a accao refresh comum dos browsers) sempre que esta e abandonada ou ainda ou
ainda se a janela for encerrada
Tal como sugerido na seccao 462 a camada de interface desta aplicacao (cada
pagina individual em HTML) devera ser implementada como sendo um template
para apresentacao de dados sendo totalmente preenchida atraves de funcoes em
JavaScript O objectivo deste ponto e criar um padrao de dados que permita ao
JavaScript preencher os dados em cada pagina (template) independentemente de
qual seja a fonte ndash o servidor remoto ou a maquina local tal como exemplificado
no diagrama da Figura 412 Na figura a aplicacao recorre ao servidor remoto para
obter os dados pretendidos quando se encontra na presenca de uma ligacao mas
para dados que exijam uma carga de processamento pelo servidor este acto pode ser
49
Desenvolvimento
Figura 412 Esquema UML que expressa o acto de recolha de dados em modo online eoffline recorrendo ao servidor (modo online) e ao sistema de armazenamento de dadoslocal fornecido pelo Gears (modo offline)
substituıdo pelo envio de um campo de controlo que se destina a aferir se os dados
locais se encontram actualizados No caso de estarem actualizados a comunicacao
com o servidor pode ser substituıda por uma query a base de dados local
50
Capıtulo 5
Resultados e Futuros
Desenvolvimentos
Todo o estudo feito sobre o tema OWA foi ja abordado ao longo do documento
Neste capıtulo apresentam-se os resultados obtidos na implementacao da prova de
conceito que visava compreender a melhor forma de disponibilizar uma versao of-
fline no WOW uma plataforma de gestao de ordens de trabalho ja existente de-
senvolvida pela Critical Software SA
51 Resultados Obtidos
Os resultados obtidos neste projecto sao extremamente satisfatorios uma vez
que o estudo do tema OWA e a implementacao de uma prova de conceito que o
ilustrasse foi conseguido com sucesso
A funcionalidade offline foi adicionada ao produto WOW da Critical Software
SA permitindo a visualizacao de ordens de trabalho e dos seus detalhes mesmo na
ausencia de uma conexao activa a Internet Embora para a solucao implementada
tenha sido utilizada uma abordagem do tipo ldquoutilizador deciderdquo pretende-se que esta
seja convertida para ldquoaplicacao deciderdquo ou mesmo para uma aproximacao hıbrida
semelhante a utilizada pelas aplicacoes estudadas nas seccoes 351 e 352
Para a sua implementacao descrita no capıtulo 4 foram tomadas decisoes de or-
dem pratica que permitissem tornar o trabalho exequıvel nos prazos dados Tentou-
se sempre que estas decisoes afectassem o mınimo em termos de desempenho e de
experiencia para o utilizador Considera-se que a implementacao do modo offline
com uma transicao entre modos do tipo ldquoutilizador deciderdquo (ver seccao 42) reflecte
o compromisso entre o desempenho pretendido e os recursos disponıveis e para alem
51
Resultados e Futuros Desenvolvimentos
de ser um exemplo eficaz das possibilidades que as OWA podem trazer a aplicacao
WOW desenvolvida pela Critical Software e tambem um estudo que pode ser uti-
lizado para analisar a implementacao desta tecnologia noutros produtos da mesma
empresa
Note-se que o principal objectivo do trabalho era ganhar familiaridade com este
tema entender as suas vantagens e desvantagens e compreender as suas limitacoes
Tudo indica que existam varias possibilidades de implementacao deste paradigma
noutros produtos da Critical Software que pela sua natureza podem tambem tirar
partido da execucao offline
52 Trabalho Futuro
O desenvolvimento do conceito e formas de implementacao de OWA continua
em forte desenvolvimento no entanto a sua adopcao ainda nao e generalizada A
dificuldade da sua implementacao em web applications ja existentes e o principal
obstaculo a sua maior divulgacao
Ha tambem um factor que deve ser tido em consideracao a manutencao de
codigo A implementacao de uma versao offline de uma web application requer
a implementacao das mesmas regras de negocio (ou de uma versao simplificada)
utilizadas no servidor Para que isto seja possıvel e necessario ter em conta a
capacidade de processamento do cliente e o factor de duplicacao de codigo que
tornara a aplicacao mais difıcil de manter uma vez que uma alteracao a logica de
negocio do servidor implica tambem uma alteracao a sua versao offline
A prova de conceito implementada permite ja a visualizacao offline dos pedidos
abertos (enviados e recebidos) que constam na pagina principal (este numero e
fixo e pode ser alterado pelo administrador) Uma funcionalidade desejavel seria a
possibilidade de interaccao com a aplicacao em modo offline e sincronizacao com o
servidor quando existisse uma ligacao disponıvel
Foi estudada a utilizacao do modo de execucao ldquoaplicacao assume o estado of-
flinerdquo descrito em 423 e esta seria a forma desejavel para o WOW Offline no
entanto para que esta opcao seja viavel sera necessaria a implementacao de uma
forma eficiente de sincronizacao e armazenamento de dados de uma forma relacional
Para atingir este objectivo podera ser seguida uma polıtica de automacao do pro-
cesso no qual a versao online da aplicacao gera scripts de criacao para as tabelas
necessarias na base de dados da versao offline (nao existe nenhuma ferramenta para
o fazer portanto seria necessaria a sua implementacao) e no qual as paginas HTML
disponibilizadas pelo servidor aos clientes web (browser) servem como templates de
apresentacao de informacao e sao preenchidas de forma semelhante pelo servidor ndash
quando a aplicacao estiver online ndash ou pelo cliente atraves de funcoes em JavaScript
52
Resultados e Futuros Desenvolvimentos
ndash quando a aplicacao estiver offline No entanto no WOW devido a quantidade de
informacao tratada e devido as complexas relacoes entre as diferentes entidades e
de esperar que a complexidade da implementacao de um mecanismo deste tipo torne
esta aproximacao demasiado custosa
O HTML 5 embora um forte candidato ainda nao esta suficientemente desen-
volvido A sua especificacao ainda tem o caracter de Draft (rascunho) e esta sujeita
a modificacoes e a aceitacao e implementacao por parte dos browsers e portanto
de momento foi desconsiderado No entanto no futuro se esta especificacao atingir
um estado de maturidade que permita a sua adopcao devera ser considerada como
um possıvel caminho a seguir
53
Resultados e Futuros Desenvolvimentos
54
Capıtulo 6
Conclusoes
Neste capıtulo sao apresentadas as conclusoes do projecto e consideracoes finais
relativamente a tecnologia estudada
61 Conclusoes
O rapido desenvolvimento tecnologico faz prever que a disponibilidade de ligacao
a Internet seja cada vez mais facil e mais rapido mas vao continuar a existir lugares
onde o acesso e limitado e onde as OWA podem desempenhar um papel de relevo
Por outro lado esta tecnologia pode tambem ser utilizada para melhorar o desem-
penho de paginas web com uma necessidade elevada de imagens ou outros recursos
dispendiosos em termos de espaco e foram ate estudados dois exemplos da utilizacao
desta vertente desta tecnologia em 353
Acredita-se que as OWAs vem responder a uma necessidade real por parte das
web applications actuais e que a evolucao que representam se compara a que se
assistiu dos thin-clients para os fat-clients em termos de autonomia do servidor
A capacidade de oferecer conteudos dinamicos no browser independentemente da
existencia de uma ligacao reune as vantagens tıpicas das web applications como
ausencia de instalacao e actualizacoes instantaneas com as vantagens das aplicacoes
de desktop em capacidade de processamento e armazenamento de dados na maquina
local
As tecnologias disponıveis ate a data estudadas no ambito deste projecto que
permitem o desenvolvimento de OWAs e que apresentam maior maturidade sao o
Gears e o Adobe AIR Ambas se apresentam sobre a forma de plugins que necessitam
de uma instalacao extra para poderem ser utilizadas Apesar de esta instalacao ser
55
Conclusoes
apenas necessaria uma vez podera constituir um factor de desencorajamento a sua
adopcao
O HTML 5 uma especificacao abordada neste documento na seccao 34 podera
ser uma alternativa que oferece funcionalidades offline a uma web application sem a
necessidade de qualquer instalacao no entanto esta especificacao ainda nao foi aceite
pelos principais browsers ndash o documento que define o HTML 5 ainda tem o estatuto
de Draft ndash e ainda nao e possıvel antecipar quando e que isto podera acontecer
Um dos problemas que surge frequentemente na implementacao de uma versao
offline para uma web application e a necessidade de sincronizacao de dados Quando
a informacao pode ser alterada por varios utilizadores simultaneamente e necessario
prever os conflitos que daı podem surgir e dotar a aplicacao de uma forma de os
resolver ou alertar o utilizador para a necessidade de alteracao dos dados
Em conclusao todos os objectivos propostos para este projecto foram atingidos
A prova de conceito implementada reflecte de forma clara as possibilidades oferecidas
pela tecnologia OWA e sera utilizado no futuro para compreender a melhor forma
de o implementar de forma definitiva no WOW
56
Referencias
[Ada08] Lucas Adamski Introducing Adobe AIR security model Fevereiro de2008 Disponıvel em httpwwwadobecomdevnetairarticles
introduction_to_air_securityhtml acedido em Marco de 2008
[Ado08] Adobe Adobe AIR 10 Security White Paper 2008 Disponıvel emhttpdownloadmacromediacompubairdocumentation1air_
securitypdf acedido em Marco de 2008
[Alm08] Dion Almaer Gears as a bleeding-edge html 5 implementa-tion March 2008 Disponıvel em httpalmaercomblog
gears-as-a-bleeding-edge-html-5-implementation acedido emMarco de 2008
[BL96] Tim Berners-Lee The world wide web Past present and future Agostode 1996 Disponıvel em httpwwww3orgPeopleBerners-Lee
1996ppfhtml acedido em Abril de 2008
[CDGH08] Mike Chambers Daniel Dura Dragos Georgita and Kevin Hoyt AdobeAIR for JavaScript Developers OrsquoReilly Media 2008 Disponıvel emhttponairadobecomfilesAIRforJSDevPocketGuidepdf ace-dido em Abril de 2008
[Con99] Jim Conallen Modeling Web Application Architectures with UML Junho1999 Disponıvel em httpwwwumlorgcnUMLApplicationpdf
webappspdf acedido em Maio de 2008
[Ent07] Entrust What is a public key information 2007 Disponıvel em http
wwwentrustcompkihtm acedido em Junho de 2008
[Gar05] Jesse James Garret Ajax A new approach to web applicationsFebruary 2005 Disponıvel em httpwwwadaptivepathcomideas
essaysarchives000385php acedido em Marco de 2008
[Greon] Philip Greenspun Philip and Alexrsquos Guide to Web Publishing 2003(last revision) Disponıvel em httpphilipgreenspuncompandaacedido em Junho de 2008
[Gro02a] App Design Group Thick vs thin client comparison 2002 Disponıvelem httpwwwdonjacobsvwcomimagesweekendspecials
Thick-vs-Thinpdf acedido em Junho de 2008
57
REFERENCIAS
[Gro02b] Technical Research Group Thin Client Tecnhology - WhitePaper 2002 Disponıvel em httpwwwpicktrgcompubs
thinclientwhitepaperpdf acedido em Junho de 2008
[Gro08] Miniwatts Marketing Group World internet usage March 2008Disponıvel em httpwwwinternetworldstatscomstatshtm ace-dido em Abril de 2008
[Hic08] Ian Hickson HTML 5 Draft Recommendation 2008 Disponıvelem httpwwwwhatwgorgspecsweb-appscurrent-work ace-dido em Marco de 2008
[Kha] Olga Kharif Top 10 municipal wifi plans Disponıvel em http
imagesbusinessweekcomss0608muni_wifiindex_01htm ace-dido em Marco de 2008
[Lab07] Mozilla Labs Prism Outubro 2007 Disponıvel em httplabs
mozillacom200710prism acedido em Marco de 2008
[Loo06] Chris Loosley Rich Internet ApplicationsDesign MeasurementandManagement Challenges 2006 Disponıvel em httpwwwkeynote
comdocswhitepapersRichInternet_5pdf acedido em Maio de2008
[Mic08] Microsoft Introduction to Occasionally Connected Applications us-ing Sync Services for ADONET 2008 Disponıvel em httpmsdn
microsoftcomen-ussyncbb887608aspx acedido em Junho de2008
[Nao08] Erica Naone Offline web applications Abril 2008 Disponıvelem httpwwwtechnologyreviewcomread_articleaspxch=
specialsectionsampsc=emerging08ampid=20245 acedido emAbril de 2008
[NJN00] Jason Nieh Yang S Jae and Naomi Novik A comparison of thin-clientcomputing architectures 2000 Disponıvel em httpwwwnclcs
columbiaedupublicationscucs-022-00pdf acedido em Maio de2008
[OrsquoR06] Tim OrsquoReilly Web 20 compact definition Trying again Dezembro2006 Disponıvel em httpradaroreillycomarchives200612
web-20-compact-definition-tryihtml acedido em Marco de 2008
[OrsquoR09] Tim OrsquoReilly What is Web 20 Design patterns and business modelsfor the Next Generation of Software 20053009 Disponıvel emhttpwwworeillynetcompubaoreillytimnews200509
30what-is-web-20html acedido em Marco de 2008
[Rus06] Alex Russel Comet Low latency data for the browser March Marco2006 Disponıvel em httpalexdojotoolkitorgp=545 acedidoem Marco de 2008
58
REFERENCIAS
[Sad97] Darleen Sadoski Clientserver software architecturesndashan overviewAgosto 1997 Disponıvel em httpwwwseicmuedustr
descriptionsclientserver_bodyhtml acedido em Junho de2008
[Sch96] George Schussel Clientserver past present and future 1996
[Smi07] Kevin C Smith Css filters - will the browser apply the rule July 2007Disponıvel em httpcentriclecomrefcssfilters acedido emMarco de 2008
[vK08] Anne van Kesteren The XMLHttpRequest Object W3C Work-ing Draft 15 Abril 2008 Disponıvel em httpwwww3orgTR
XMLHttpRequest acedido em Abril de 2008
[Wil06] Greg Wilkins Why ajax comet July Julho 2006 Disponıvel emhttpwwwwebtidecomdownloadswhitePaperWhyAjaxhtml ace-dido em Abril de 2008
59
REFERENCIAS
60
Anexo A
Screenshots
Algumas imagens de aplicacoes que utilizam funcionalidades offline ilustrativasda tecnologia abordada neste documento
Figura A1 Dialogo apresentado ao utilizador na primeira activacao das funcionalidadesoffline no Google Docs amp Spreadsheets
61
Screenshots
Figura A2 Na activacao das funcionalidades offline e tambem oferecida a possibilidadeda criacao de alguns atalhos por exemplo no ambiente de trabalho
Figura A3 O Google Docs mantem a todo o momento a possibilidade de alteracao destasdefinicoes ou da anulacao dos servicos offline para um dado computador
62
Screenshots
Figura A4 Apos a instalacao do Gears qualquer visita ao Remember The Milk despoletauma sincronizacao que ocorre automaticamente e sem necessidade de intervencao por partedo utilizador
Figura A5 Apos completar a sincronizacao de dados mesmo que a ligacao a Internetseja perdida o Remember the Milk continua disponıvel no browser (com excepcao dasfuncionalidades que pela sua natureza exigem uma ligacao como por exemplo partilhade tarefas e envio de convites)
63
iv
Agradecimentos
A realizacao e os objectivos alcancados neste projecto nao teriam sido possıveissem a colaboracao de inumeras pessoas Agradeco profundamente a todos os quecontribuıram directa ou indirectamente para o seu sucesso
A minha orientadora Professora Teresa Galvao Dias e ao Project ManagerEngenheiro Marcus Neves que me conduziram e acompanharam no desenvolvimentodeste projecto
A toda a equipa do WOW em especial o Pedro Maurıcio Costa e o Fabio Matosque contribuıram para a minha a minha integracao na Critical Software e que sempresouberam responder a todas as minhas questoes
A todos os que constituem a CSW Porto pelo fantastico ambiente de amizadeque me proporcionaram
Aos colegas de curso e a todos os que me auxiliaram na revisao deste documento
Os meus sinceros agradecimentos
Joao Goncalves da Costa
v
vi
Conteudo
1 Introducao 111 Enquadramento 112 Motivacao 213 Ambito 314 Objectivos 315 Estrutura do documento 3
2 Enquadramento do Projecto 521 Evolucao das arquitecturas de software 5
211 Thin-clients 5212 Fat-clients 6213 Arquitecturas cliente-servidor 7
22 Evolucao na Internet 8221 Paginas web estaticas 9222 Paginas web interactivas e paginas web dinamicas 9223 Web 20 e Ajax 11
23 Offline Web Applications 1324 Comparacao 13
3 Estado da arte 1731 Gears 17
311 Arquitectura 17312 Goggle Gears em dispositivos moveis 20
32 Adobe AIR 20321 Seguranca 22322 Assinatura do codigo 22
33 Mozilla Prism 23331 XML User Interface Language 23332 Prism 25
34 HTML 5 2535 Web applications que usam funcionalidades offline 26
351 Google Reader e Google Docs 26352 Remember the Milk 27353 MySpace e WordPresscom 27
36 Escolha da tecnologia 28
vii
CONTEUDO
4 Desenvolvimento 3341 Como ficar offline 33
411 Funcionalidades disponıveis em modo offline 3442 Modos de execucao 35
421 Modo ldquoutilizador deciderdquo 36422 Modo aplicacao decide 36423 Modo ldquoaplicacao assume o estado offlinerdquo 37
43 Sincronizacao de dados 38431 Quando sincronizar 39
44 WOW 4045 Visao geral sobre a arquitectura do WOW 4146 WOW Offline 42
461 Modo ldquoaplicacao deciderdquo com deteccao automatica da ligacao 43462 Implementacao do modo ldquoutilizador deciderdquo 45463 Especificacao do modo ldquoaplicacao assume o estado offlinerdquo 48
5 Resultados e Futuros Desenvolvimentos 5151 Resultados Obtidos 5152 Trabalho Futuro 52
6 Conclusoes 5561 Conclusoes 55
Referencias 59
A Screenshots 61
viii
Lista de Figuras
21 Arquitectura de um sistema thin-client em duas camadas (a esquerda)e em tres camadas (a direita) Note-se a inclusao do servidor (main-frame) na definicao das camadas desta arquitectura devido a fortedependencia cliente-servidor 9
22 Arquitectura de um fat-client em duas camadas (a esquerda) e emtres camadas (a direita) 10
23 Comparacao do modelo de web aplications sıncrono paginas estaticase interactivas abordados nas seccoes 221 e 222 com o modelo deweb applications Ajax (assıncrono) abordado na seccao 223 Figuraadaptada de http www adaptivepath com 15
31 Esquema UML do processo efectuado pelos recursos do Gears do tipoManagedResourceStore para a actualizacao dos conteudos definidosno ficheiro manifesto 29
41 Exemplo de uma arquitectura de uma web application sem uma ca-mada de abstraccao de dados Figura adaptada de http gears
google com 33
42 Exemplo de uma arquitectura de uma web application com uma ca-mada de abstraccao de dados Figura adaptada de http gears
google com 34
43 Exemplo de uma arquitectura de uma web application com uma ca-mada de abstraccao de dados e um data switch Figura adaptada dehttp gears google com 35
44 Esquema grafico ilustrando uma OWA executando no browser uti-lizando um modo de execucao do tipo ldquoaplicacao deciderdquo com de-teccao automatica do estado da ligacao via pedidos Ajax assıncronosa cada cinco segundos 37
45 Detalhe de um conjunto possıvel de estados e respectivas transicoespara uma dada ordem de trabalho no WOW desde a sua submissaono sistema ate a sua conclusao em fecho ou cancelamento Esta figurarepresenta apenas um exemplo ja que o mapa de estados para umaordem de trabalho e dinamico e pode ser alterado por um admin-istrador Figura retirada de uma brochura promocional do WOWCritical Software SA 41
ix
LISTA DE FIGURAS
46 A pagina inicial do WOW apresenta um resumo das ultimas ordensde trabalho enviadas e recebidas Na imagem pode-se observar atransicao do estado online para offline 44
47 Ilustracao do funcionamento do Gears numa web application que uti-liza um motor Ajax Os pedidos HTTP ou HTTPS podem ser inter-ceptados e tratados localmente ou podem ser feitos a uma maquinaremota consoante se verificarem ou nao as condicoes expressas noponto 311 E representado um acesso a uma base de dados local(fornecida pelo Gears) mas a sua utilizacao e opcional 45
48 Neste exemplo do modo ldquoaplicacao deciderdquo o teste da ligacao e feitoe feito a cada cinco segundos O resultado deste teste nao reflectesempre o estado real da aplicacao podendo levar a aplicacao a tercomportamentos indesejaveis Na figura assinala-se um perıodo detempo no qual a representacao interna do estado da ligacao nao cor-responde a realidade 46
49 Pagina de visualizacao do detalhe de uma ordem de trabalho 47410 Esquema UML que expressa os casos de uso do WOW Offline no
modo ldquoutilizador deciderdquo 48411 Esquema UML que expressa os casos de uso do WOW Offline no
modo ldquoutilizador deciderdquo 49412 Esquema UML que expressa o acto de recolha de dados em modo
online e offline recorrendo ao servidor (modo online) e ao sistemade armazenamento de dados local fornecido pelo Gears (modo offline) 50
A1 Dialogo apresentado ao utilizador na primeira activacao das funcional-idades offline no Google Docs amp Spreadsheets 61
A2 Na activacao das funcionalidades offline e tambem oferecida a possi-bilidade da criacao de alguns atalhos por exemplo no ambiente detrabalho 62
A3 O Google Docs mantem a todo o momento a possibilidade de alteracaodestas definicoes ou da anulacao dos servicos offline para um dadocomputador 62
A4 Apos a instalacao do Gears qualquer visita ao Remember The Milkdespoleta uma sincronizacao que ocorre automaticamente e sem ne-cessidade de intervencao por parte do utilizador 63
A5 Apos completar a sincronizacao de dados mesmo que a ligacao aInternet seja perdida o Remember the Milk continua disponıvel nobrowser (com excepcao das funcionalidades que pela sua naturezaexigem uma ligacao como por exemplo partilha de tarefas e enviode convites) 63
x
Lista de Tabelas
21 Comparacao entre thin-clients e fat-clients 7
31 Comparacao das funcionalidades oferecidas pelo Adobe AIR para asplataformas web e desktop 30
32 Resumo da utilizacao de tecnologias OWA em algumas web applica-tions consideradas na analise do estado da arte 31
xi
LISTA DE TABELAS
xii
Glossario
fat-client Cliente que nao depende totalmente de umservidor central para as suas actividadesde processamento e possui frequentementedispositivos de armazenamento de dados
6ndash8
thin-client Cliente que depende de um servidor centralpara as suas actividades de processamento
5ndash8
web application Sistema web (servidor rede HTTPbrowser) onde accoes do utilizador(navegacao e introducao de informacao)afectam o estado logico da aplicacao
i iii1ndash311ndash1517ndash1921ndash232728 3336ndash3842 5556
API Application Programming Interface 10 1718 2326 28
ASP Linguagem interpretada pelo servidorque permite a criacao de paginas webdinamicas Desenvolvida pela Microsoft
11
BSD Berkeley Software Distribution 28
CSS Cascading Style Sheets 12 2021 2324 46
DHTML Dynamic HyperText Transfer Protocol 24DOM Document Object Model 10 12
20 2324
DTD Document Type Definition 24
xiii
Glossario
ECMAScript Padrao de linguagem de programacaodefinido pela Ecma International que orig-inou o JavaScript e o JScript
24
Flash Conteudo interactivo de um ficheiro emformato SWF E desenvolvido pela Adobee visualizado atraves do Adobe FlashPlayer
21
Flex Framework baseada em XML e Action-Script desenvolvida pela Adobe para a pro-gramacao de Rich Internet Applications(RIA)
21
GPL GNU General Public License 23
HTML HyperText Markup Language 1 10ndash12 2124ndash2649
HTTP HyperText Transfer Protocol 2 26
JMS E uma API em Java que permite a troca demensagens entre componentes de software
42
JSON JavaScript Object Notation permite atroca de dados codificados num formatode texto de simples leitura
12 1828 34
LGPL GNU Lesser General Public License 23
Mozilla Prism Browser simplificado e ldquointerpretadorrdquo deeXtensible User Interface Language (XUL)(tambem designado por XULRunner) queacolhe web applications sem a interfacegrafica habitual de um browser
25
MPL Mozilla Public License 23
OCA Occasionally Connected Application 39OWA Offline Web Application i iii
2ndash515 1725 2628 3133 3651 5255 56
PDF Portable Document Format 21
xiv
Glossario
PHP Linguagem interpretada pelo servidorque permite a criacao de paginas webdinamicas mas que pode tambem ser in-vocada a partir da linha de comandos
11
pagina web estatica Pagina web que devolve sempre a mesmaresposta a todos os pedidos para todos osutilizadores e em qualquer contexto
5 9
RIA Rich Internet Applications web appli-cations que apresentam funcionalidadessemelhantes as desktop applications masque mantem a informacao no lado do servi-dor
5 1520 28
RSS Really Simple Syndication 27
SLA Service Level Agreement 40SQLite Segundo a definicao oficial SQLite is a
software library that implements a self-contained serverless zero-configurationtransactional SQL database engine
17
SSB Site Specific Browser 25SSL Secure Sockets Layer 22SWF ShockWave Flash 21
URL Uniform Resource Locator 18
VPN Virtual Private Network 38
WOW Work Orders Web Plataforma de gestaode ordens de trabalho e do seu fluxo de-senvolvida pela Critical Software SA
i iii28 3340ndash434551ndash5356
WWW World Wide Web 11 1214
XBL eXtensible Binding Language 24XHTML eXtensible HyperText Markup Language 12XML eXtensible Markup Language 11 12
23 2428
XSLT eXtensible Stylesheet Language Transfor-mation
12
XUL eXtensible User Interface Language xiv23ndash25
xv
Glossario
xvi
Capıtulo 1
Introducao
Neste capıtulo enquadra-se o tema do projecto introduzindo alguns dos conceitos
nos quais se baseia Apresentam-se as motivacoes ambito objectivos e a estrutura
deste documento
11 Enquadramento
A Internet foi originalmente concebida para ser um espaco de partilha de in-
formacao onde pessoas (atraves de maquinas) pudessem comunicar Na sua origem
as paginas eram estaticas constituıdas por texto formatado em HyperText Markup
Language (HTML) e ligadas entre si [BL96] Hoje encontramos conteudos cada vez
mais complexos e dinamicos incluindo som vıdeo ou streams multimedia [Loo06] e
em 2005 foi introduzido por [OrsquoR09] o termo Web 20
De acordo com [Greon] um website pode pertencer a uma ou varias das seguintes
categorias
bull Documento ndash um website essencialmente estatico onde alteracoes a uma
parte do conteudo nao tem implicacoes no seu comportamento
bull Base de dados ndash um directorio de informacao organizada em categorias
bull Aplicacao ndash um website dinamico que utiliza uma linguagem executada ou
interpretada do lado do servidor e que processa as accoes ou informacao in-
troduzida pelo utilizador para fornecer um servico ou nova informacao
A ultima destas categorias constitui aquilo que e normalmente designado por
web application O conceito utilizado ao longo deste documento e o mesmo que
o introduzido por Jim Coallen em [Con99] que define web application como um
1
Introducao
sistema web (servidor rede HyperText Transfer Protocol (HTTP) browser) onde
accoes do utilizador (navegacao e introducao de informacao) afectam o estado logico
da aplicacao A sua definicao tenta estabelecer que uma web application e um
sistema de software com estado de negocio1 e que a sua interface de interaccao com
o utilizador e distribuıdo atraves de um sistema web
12 Motivacao
A quantidade de informacao que e produzida e armazenada com recurso a es-
tas web applications disponıveis online tais como e-mail blogues ou mesmo docu-
mentacao tornam por vezes a disponibilidade de ligacao uma condicao necessaria
a produtividade e como consequencia desta barreira muitos potenciais utilizadores
opoem-se a adopcao de produtos web em detrimento das tradicionais desktop appli-
cations
Assegurar o acesso a uma ligacao de Internet e hoje muito mais facil A Internet
movel e ja uma realidade e encontra-se amplamente divulgada mas continuam a
existir diversas situacoes nas quais os utilizadores estao privados de uma ligacao
a Internet tais como uma viagem de metro ou de aviao ou quando se encontram
deslocados do seu paıs de origem e nao possuem nenhum plano de subscricao
Uma OWA consiste numa web application que para alem de manter todas as
caracterısticas anteriores se mantem disponıvel mesmo na ausencia de uma ligacao
a Internet e surge como uma tentativa de estreitar as barreiras existentes entre a
web e o desktop Isto significa que devera existir um mecanismo capaz de assegurar
a manutencao do estado logico da aplicacao quando a ligacao com o servidor e
quebrada permitindo ao utilizador continuar a utilizar a aplicacao e que sera capaz
de informar o servidor do estado em que a aplicacao se encontra quando a ligacao for
reposta A principal vantagem que advem desta possibilidade e evidente eliminar
a necessidade da existencia de uma ligacao a Internet para que a aplicacao possa ser
utilizada
Por outro lado a vontade de integracao de funcionalidades tıpicas das desktop
applications nas web applications foi um dos principais factores que impulsionou o
desenvolvimento deste conceito uma vez que obrigou a uma reflexao ldquopara alem
do browserrdquo e a uma adaptacao das arquitecturas existentes que permitisse ou o
acesso a funcionalidades disponibilizadas pelo sistema operativo ou pelo menos a
funcionalidades semelhantes Pretende-se com esta aproximacao tornar possıveis
interaccoes entre o desktop e o browser tais como arrastar um ficheiro para um
formulario web de upload de conteudos melhor suporte para o historico do clipboard
ou ainda o acesso ao sistema de ficheiros local Atingir estes objectivos reflecte-se
1NT business state
2
Introducao
num novo paradigma que reune as vantagens das web applications tais como os
updates instantaneos ou o facto de nao ser necessaria nenhuma instalacao e das
desktop applications como por exemplo persistencia no armazenamento de dados
acesso a funcionalidades do sistema operativo ou integracao e interaccao com outras
aplicacoes sejam elas web applications ou desktop applications
13 Ambito
Este projecto foi realizado na Critical Software SA no ambito do Mestrado
Integrado em Engenharia Informatica e Computacao (MIEIC) da Faculdade de En-
genharia da Universidade do Porto (FEUP) entre os meses de Fevereiro e Julho de
2008
14 Objectivos
Sao objectivos deste projecto
1 Estudar e documentar o tema das OWAs acompanhando os ultimos desenvolvi-
mentos nesta materia
2 Analisar o estado da arte fazendo uma analise crıtica e objectiva sobre as
diversas metodologias existentes
3 Implementar uma prova de conceito que permita a execucao offline de uma
web application documentando todo o processo
4 Estudar a possibilidade de permitir interaccao com a aplicacao (insercoes e
alteracoes aos dados) em modo offline
Em resumo o objectivo deste projecto foi estudar documentar e implementar
uma prova de conceito relacionada com o tema Offline Web Applications (OWA)
Este tema embora nao seja totalmente novo ganhou destaque ao longo do ano de
2007 com o surgimento de diversas ferramentas que se destinam a aproximar web
applications das desktop applications
15 Estrutura do documento
Este documento esta organizado em diferentes seccoes apresentando o projecto
numa sequencia logica organizada da seguinte forma
No capıtulo 1 faz-se uma breve apresentacao do conceito OWAs e do contexto em
que surge Apresenta-se tambem a estrutura do documento e definem-se os
termos e acronimos utilizados
3
Introducao
No capıtulo 2 faz-se uma descricao da evolucao das tecnologias que antecedem as
OWAs e das vantagens e desvantagens de cada uma como forma de enquadra-
mento
No capıtulo 3 analisa-se o estado da arte nesta materia Introduzem-se diversas
tecnologias directamente relacionadas com o tema deste projecto exemplos de
aplicacoes que as usam e as razoes que fundamentam as escolhas de tecnologias
efectuadas
O capıtulo 4 contem o desenvolvimento do projecto Analisa-se a plataforma
WOW de gestao integrada de ordens de trabalho a tecnologia escolhida e
a forma como foi utilizada para implementar a capacidade de execucao offline
O capıtulo 5 descreve os resultado obtidos comparando-os com as expectativas
iniciais do projecto e apresenta desenvolvimentos futuros e possibilidades de
continuacaoaplicacao do conhecimento adquirido
No capıtulo 6 apresentam-se as conclusoes
4
Capıtulo 2
Enquadramento do Projecto
Neste capıtulo apresenta-se um breve resumo da evolucao das arquitecturas de
software cliente-servidor e a forma como estas se comparam a evolucao da Inter-
net procurando estabelecer uma analogia entre o percurso de ambas as tecnolo-
gias Compara-se o comportamento e arquitectura dos thin-clients as paginas web
estaticas a evolucao dos fat-clients as paginas interactivas Web 20 e Ajax e
defende-se que as OWA constituem um proximo passo logico e evolutivo aproxi-
mando a web do desktop Referem-se ainda os principais factores que justificam a
importancia das OWAs e a estreita relacao que tem com as Rich Internet Application
(RIA)s
21 Evolucao das arquitecturas de software
Os termos thin-client e fat-client sao utilizados quer para descrever arquitecturas
logicas (de software) quer para descrever arquitecturas fısicas (de hardware) Neste
capıtulo excepto quando seja dada indicacao em contrario estes termos referem-se
sempre a uma arquitectura logica
Adicionalmente quando se trata de arquitecturas cliente-servidor pode-se estu-
dar a arquitectura desenvolvida do sistema como um todo da arquitectura do servi-
dor ou da arquitectura do cliente Para evitar equıvocos em especial na seccao 213
especifica-se em cada caso qual o sistema estudado
211 Thin-clients
Um thin-client e um computador cliente ou software cliente que no contexto
de uma arquitectura cliente-servidor depende de um servidor central para as suas
5
Enquadramento do Projecto
actividades de processamento e proporciona um canal de entrada e saıda de in-
formacao entre o utilizador e o servidor remoto Este termo quando aplicado a
hardware refere-se habitualmente a um computador que se destina a ser utilizado
como cliente de rede sem armazenamento local e com capacidade de processamento
reduzida [Gro02b] mas o conceito que aqui se analisa refere-se a uma arquitectura
de software que remonta ao inıcio das aplicacoes cliente-servidor
No inıcio da historia da computacao terminais ligavam-se directamente a main-
frames responsaveis por todo o processamento Nesta arquitectura era necessario
desenvolver duas aplicacoes distintas uma aplicacao central no servidor (main-
frame) responsavel pela gestao de toda a informacao e por todas as operacoes de
comunicacao e uma aplicacao de visualizacao instalada no cliente (terminal) O
papel destes terminais era apenas disponibilizar ao utilizador um meio de comu-
nicacao (entrada e saıda) e apresentacao dos resultados do servidor Nao tinham
um papel activo no calculo nem na logica de negocio e frequentemente nao tinham
tambem nenhum mecanismo de armazenamento de dados
Como vantagens esta arquitectura apresenta uma reduzida necessidade de con-
figuracao e manutencao do lado do cliente Uma vez que o centro do processamento
e manipulacao de dados ocorre no servidor existe tambem uma centralizacao da
informacao [NJN00] que introduz um ponto crıtico de falha1 Actualizacoes e novas
funcionalidades sao faceis de distribuir uma vez que requerem apenas alteracoes no
servidor [Gro02a]
212 Fat-clients
Contrastando com os thin-clients nesta arquitectura os clientes implementam
ja uma parte da logica de negocio e sao responsaveis pelo processamento de dados
Estes fat-clients vieram responder a necessidade crescente de aplicacoes com um
nıvel de interactividade e capacidade de configuracao maior que as oferecidas pela
arquitectura thin-client descrita na seccao 211 Apesar de manterem a sua de-
pendencia do servidor podem tambem ser executados sem uma conexao activa uma
vez que dispoe de armazenamento de dados local o que lhes confere a capacidade
de persistencia de dados e do estado de execucao entre cada sessao
Foi disponibilizando este controlo sobre o estado da aplicacao bem como acesso
a recursos locais (por exemplo sistema de ficheiros e perifericos) que surgiram as
primeiras verdadeiras desktop applications No entanto cada cliente tinha que ser
separadamente instalado no computador pessoal de cada utilizador que pretendesse
utilizar ou interagir com a aplicacao e uma actualizacao ao servidor implicava in-
variavelmente uma actualizacao manual tambem no cliente Uma vez que nem todos
1NT single point of failure
6
Enquadramento do Projecto
Thin-clients Fat-clientsNao toma parte no processamento dedados nem possui acesso ao sistema deficheiros
Participa activamente no processa-mento de dados recorrendo ao sis-tema de armazenamento local para ar-mazenamento de dados
Nao mantem registo do estado logicoda aplicacao entre duas sessoes de uti-lizacao
O acesso ao armazenamento localpermite-lhe manter registo do estadologico da aplicacao entre duas sessoes
O thin-client nao necessita de qualquerinstalacao estando ldquopronto a utilizarrdquo
E geralmente necessario instalar aaplicacao para poder interagir com oservidor
Qualquer update no servidor reflecte-seimediatamente por todos os clientes
Embora a aplicacao cliente possa aler-tar para existencia de novas versoes asactualizacoes tem que ser manualmenteinstalados pelo cliente
O software do cliente destina-se apenasa apresentacao de dados e comunicacaocom o servidor sendo portanto de sim-ples implementacao
Como o software do cliente toma parteactiva no processamento de dadosa sua implementacao requer cuidadosadicionais
Grande mobilidade uma vez que todaa informacao e mantida no servidor
Parte da informacao podera estar ape-nas do lado cliente pelo que existemalgumas restricoes a sua mobilidade
Tabela 21 Comparacao entre thin-clients e fat-clients
os utilizadores actualizam regularmente as suas aplicacoes o servidor tem que estar
preparado para lidar com versoes antigas2 ou descontinuar os seus servicos a uma
parte da sua comunidade de utilizadores ate que estes actualizem os seus sistemas
Como os utilizadores passam a utilizar os seus recursos locais para armazenamento
de dados as alteracoes que nao sejam sincronizadas com o servidor estao apenas
disponıveis nos seus computadores pessoais o que introduz uma restricao a mobili-
dade
Pode-se afirmar que as vantagens dos thin-clients sao as desvantagens dos fat-
clients e que as vantagens dos fat-clients sao as vantagens dos thin-clients tal como
se ilustra na Tabela 21
213 Arquitecturas cliente-servidor
Introduzidos os termos thin-client e fat-client interessa reafirmar que ambos
podem ser vistos como arquitecturas cliente-servidor Um cliente define-se como
um solicitador de servicos e um servidor como um prestador de servicos tal como
definido por [Sch96] e [Sad97]
2NT backward compatibility
7
Enquadramento do Projecto
As arquitecturas cliente-servidor sao categorizadas pela modularizacao com que
sao desenhadas sendo consideradas as seguintes camadas
1 Interface grafica (front-end) atraves da qual os utilizadores interagem com
a aplicacao Quando este modulo e implementado separadamente dos outros
dois constitui uma aplicacao thin-client por si so uma vez que nao implementa
regras de negocio (embora possa definir validacoes de formularios de insercao de
dados por exemplo) A informacao introduzida pelo utilizador e enviada para
o servidor que processa o seu pedido e retorna uma resposta Este processo
repete-se ate que o utilizador atinja o seu objectivo ou se desligue do sistema
2 A logica de negocio tambem designada por camada intermedia que imple-
menta as regras de aceitacao e validacao de todos os dados introduzidos pelo
utilizador E tambem a plataforma de comunicacao que une a camada superior
de visualizacao com a camada de acesso a dados
3 A camada de dados inclui quer o sistema de persistencia de dados onde sao
armazenados os dados relevantes como tambem os mecanismos necessarios
para a sua pesquisa seleccao e alteracao
Os thin-clients quando observados no seu conjunto de cliente e servidor podem
ser vistos quer como sistemas de duas camadas quer como sistemas de tres camadas
dependendo apenas da forma como o servidor for implementado No caso de na
implementacao do servidor nao se distinguir a camada de acesso a dados da camada
da logica de negocio sao designados por sistemas de duas camadas Caso seja feita
esta distincao sao designados por sistemas de tres camadas Ambos os casos sao
ilustrados na Figura 21
Historicamente os fat-clients eram implementados numa arquitectura em duas
camadas Possuıam apenas um modulo de visualizacao de dados designado por
camada de interface e um modulo que implementava toda a logica de negocio e
regras de acesso a base de dados No entanto com a introducao de ligacoes mais
rapidas e de computadores pessoais com maior capacidade de processamento e so-
bretudo devido a complexidade crescente das aplicacoes a logica de negocio e a
camada de acesso a dados tornaram-se independentes Este modelo e designado por
arquitectura em tres camadas e e ilustrado na Figura 22
22 Evolucao na Internet
Ao analisar a evolucao das arquitecturas das aplicacoes desenvolvidas para a
Internet podemos encontrar um paralelismo com a historia da arquitectura de soft-
ware
8
Enquadramento do Projecto
Figura 21 Arquitectura de um sistema thin-client em duas camadas (a esquerda) e emtres camadas (a direita) Note-se a inclusao do servidor (mainframe) na definicao dascamadas desta arquitectura devido a forte dependencia cliente-servidor
221 Paginas web estaticas
Uma pagina web estatica devolve sempre a mesma resposta a todos os pedidos
para todos os utilizadores e em qualquer contexto utilizando o hipertexto como
forma de ligacao entre diversas paginas estaticas
A informacao e armazenada num servidor e o papel do cliente e apenas a apre-
sentacao da informacao Esta forma de disponibilizacao de informacao pode assim
ser comparada com os thin-clients descritos na seccao 211 o utilizador acede a
um website estatico para visualizar informacao sem que o cliente tome parte no
processamento A unica diferenca e que no caso da web estatica a informacao ap-
resentada e sempre a mesma enquanto que nos thin-clients era frequente existir a
possibilidade de insercao de dados no cliente e apos o seu processamento servidor
nova informacao poderia ser apresentada O hipertexto e utilizado para ligar as
paginas entre si numa rede de conteudos relacionados e a navegacao sıncrona era
feita atraves de cliques do rato a cada clique uma nova pagina era apresentada
Este modelo sıncrono e ilustrado na Figura 23
222 Paginas web interactivas e paginas web dinamicas
O JavaScript e uma linguagem interpretada de scripting que tem os browsers
como principal ambiente de acolhimento Os browsers utilizam uma Application
9
Enquadramento do Projecto
Figura 22 Arquitectura de um fat-client em duas camadas (a esquerda) e em tres camadas(a direita)
Programming Interface (API) publica para criar ldquoobjectosrdquo responsaveis por reflectir
e disponibilizar o Document Object Model (DOM) para o motor de JavaScript
A utilizacao mais frequente desta linguagem e a escrita de funcoes que sao em-
bebidas ou incluıdas em paginas web e que interagem com o DOM Uma vez que o
JavaScript e executado localmente (na maquina do cliente e nao no servidor) e capaz
de responder rapidamente a accoes do utilizador tornando a execucao de aplicacoes
no browser mais fluıdas o JavaScript pode tambem detectar accoes do utilizador
que o HTML nao pode tal como o pressionar de uma tecla
Em Dezembro de 1995 a Netscape Communications adicionou suporte para o
JavaScript no browser Netscape Navigator3 e em Agosto de 1996 o browser Internet
Explorer4 da Microsoft passou a tambem a suportar uma versao semelhante desta
linguagem (hoje todos os principais browsers suportam esta tecnologia)
Esta inovacao permitiu tornar os websites mais interactivos mas a sua utilizacao
esteve confinada apenas a este proposito durante um longo perıodo As paginas
passaram a responder activamente a accoes do utilizador (sendo uma das utilizacoes
3Netscape Communications ndash httpbrowsernetscapecom4Microsoft Internet Explorer ndash httpwwwmicrosoftcomwindowsproductswinfamilyie
10
Enquadramento do Projecto
mais vulgares a validacao de formularios) mas continuaram essencialmente estaticas
O JavaScript ainda nao era nesta altura utilizado para processar dados
Tambem nesta altura (1995ndash96) surgiram linguagens server-side como o PHP
Hypertext Preprocessor (PHP) e Active Server Pages (ASP) e o servidor passou a ter
um processamento de dados introduzidos pelo utilizador mais activo Generalizaram-
se as paginas dinamicas capazes de responder a insercao de dados ou outros pedidos
determinados por accoes do utilizador As paginas tornaram-se aplicacoes web ap-
plications
Uma definicao tradicional de web application e um conjunto de paginas web
logicamente agrupadas e geridas por uma unica entidade que tem como pontos de
entrada formularios de insercao de dados (web forms) Uma web application nao e
mais do que uma aplicacao que e acedida atraves de um browser Tem geralmente
uma arquitectura logica em tres (interface logica de negocio e camada de dados)
camadas e estao armazenadas num servidor
Ha dois tipos de web applications
bull Orientadas a apresentacao Sao web applications que geram paginas web in-
teractivas constituıdas por varios tipos de linguagens de anotacao (por exem-
plo HTML eXtensible Markup Language (XML)) e que apresentam conteudo
dinamico como resposta a pedidos efectuados pelo utilizador
bull Orientadas aos servicos Uma web application orientada aos servicos imple-
menta o ponto de acesso para um ou mais de um web service Sao geralmente
clientes de service oriented web applications
Uma vantagem significativa de implementar uma web application de forma a
suportar as funcionalidades padrao dos browsers e que estas terao o mesmo com-
portamento independentemente da plataforma e do browser a partir do qual serao
acedidas No entanto diferentes implementacoes de browsers devido a diferentes
interpretacoes dos padroes definidos tornam por vezes esta tarefa um pouco mais
complicada existindo inclusivamente na web guioes de compatibilidade para os difer-
entes browsers como [Smi07]
223 Web 20 e Ajax
O termo web 20 descreve uma tendencia de utilizacao e de design observada
na World Wide Web (WWW) com o objectivo de melhorar a criatividade partilha
de informacao e principalmente a colaboracao entre utilizadores Estes conceitos
levaram ao desenvolvimento e evolucao de comunidades online tais como redes so-
ciais wikis e blogues
11
Enquadramento do Projecto
O termo tornou-se mais conhecido apos a primeira conferencia OrsquoReilly Media
Web 20 em 2004 e apesar de sugerir uma nova versao da WWW nao se refere a
qualquer evolucao tecnologica mas apenas a alteracoes a forma como os utilizadores
se servem da web De acordo com Tim OrsquoReilly [OrsquoR06] ldquoWeb 20 e uma revolucao
na industria do software causada pela adopcao da web como uma plataforma e pela
tentativa de entendimento das regras para o sucesso nesta nova plataformardquo
O desenvolvimento da Web 20 serve-se muitas vezes de um outro conceito Ajax
O conceito que hoje conhecemos como Ajax muitas vezes incorrectamente de-
scrito como uma tecnologia foi originalmente criado para permitir o desenvolvimento
de web applications que se assemelhassem ainda mais a aplicacoes de desktop Este
conceito foi melhor descrito por [Gar05] como um conjunto de varias tecnologias
que podem ser utilizadas para melhorar a experiencia do utilizador de uma dada
web application introduzindo a capacidade assıncrona de envio de pedidos ou da
recepcao assıncrona de respostas As tecnologias mais frequentemente envolvidas
sao
bull eXtensible HyperText Markup Language (XHTML) e Cascading Style Sheets
(CSS) padrao para a apresentacao
bull interaccao dinamica atraves do DOM
bull troca e manipulacao de dados utilizando XML e eXtensible Stylesheet Lan-
guage Transformation (XSLT) ou JavaScript Object Notation (JSON)
bull pedidos assıncronos utilizando XMLHttpRequest [vK08]
bull JavaScript utilizado para integrar todas estas tecnologias
E importante frisar que o Ajax nao e um produto nem uma tecnologia E um
termo que descreve a utilizacao de um conjunto de tecnologias para o desenvolvi-
mento de web applications com um elevado grau de interactividade Comparativa-
mente as web applications tradicionais o Ajax introduz uma camada de visualizacao
diferente em tres importantes pontos
1 Do lado do cliente existe um motor que serve de intermediario entre a interface
da aplicacao e o servidor
2 A actividade do utilizador despoleta chamadas JavaScript em vez de um pedido
de pagina directamente ao servidor
3 Informacao codificada em XML em vez de paginas HTML e trocada entre o
servidor e o cliente
12
Enquadramento do Projecto
Isto significa que as paginas que utilizam Ajax contem um motor do lado do
cliente composto por um conjunto de funcoes JavaScript responsavel pela comu-
nicacao com o servidor e por actualizar a interface com o resultado dessa mesma
comunicacao
Na Figura 23 ilustra-se a natureza assıncrona do Ajax quando comparada com
as web applications tradicionais Como se pode observar adicionando um mecan-
ismo Ajax a uma web application eliminam-se diversos tempos de espera associados
a comunicacoes com o servidor uma vez que a interface nao fica ldquobloqueadardquo a es-
pera da resposta Obtem-se assim aplicacoes com um comportamento mais fluido
eliminando tempos de espera entre cada ldquocliquerdquo e melhorando a experiencia do
utilizador
23 Offline Web Applications
A informacao grafica (bem como folhas de estilo e scripts) tais como as ima-
gens que constituem o visual de uma web application e ja tratada de forma especial
pelos cada vez mais avancados sistemas de cache (armazenamento temporario) dos
browsers Mas estes nao sao ainda capazes de guardar conteudo criado pelo uti-
lizador nem de apresentar informacao independentemente do estado da ligacao
Numa altura onde se fala de servicos de Internet wireless municipalizados [Kha]
comunicacoes 3G e ligacoes de banda larga a alta velocidade a ligacao a rede global
continua a nao estar permanentemente disponıvel para os utilizadores Na WWW
encontra-se uma importante parte da informacao e das aplicacoes utilizadas para
criar e editar conteudos Por vezes informacao vital para a produtividade pode
desaparecer subitamente do mapa de acesso de um utilizador quando este entra no
metro num aviao ou mesmo quando se desloca para uma cidade ou paıs diferente
do habitual onde nao subscreve um plano de acesso que lhe garanta a ligacao
Permitir o acesso offline a estes recursos assume assim a sua importancia porque
permitira estender o alcance da informacao a locais onde nunca esteve antes e per-
mitira tambem melhorar o desempenho das web applications colocando informacao
mais perto dos utilizadores reduzindo a transferencia de dados apenas ao essencial
24 Comparacao
Nas evolucoes descritas neste capıtulo 2 pode-se observar que existe um par-
alelismo entre a evolucao das arquitecturas tradicionais cliente-servidor e a evolucao
a que se assiste na web O comportamento e arquitectura dos thin-clients assemelha-
se ao das paginas estaticas no sentido em que o browser nao toma parte em qualquer
13
Enquadramento do Projecto
processamento e serve apenas como uma plataforma de interaccao com o servidor
tal como os clientes descritos na seccao 211
A sua proxima evolucao os fat-clients trouxeram parte da capacidade de pro-
cessamento para o lado do cliente Na web foi tambem esta a inovacao tecnologica
a que se assistiu com a evolucao das tecnologias que permitiram a criacao de ver-
dadeiras aplicacoes e com a introducao do Javascript no browser dando ao cliente
a capacidade de processamento de dados A necessidade da separacao do codigo
em camadas logicas advem da crescente complexidade das web applications Esta
pratica permite entre outras coisas melhorar o processo de desenvolvimento e a
capacidade de manutencao de uma aplicacao
Os fat-clients tem tambem a capacidade de armazenamento de dados o que
permite a persistencia de informacoes entre duas sessoes e que algumas operacoes
sejam executadas sem a necessidade de comunicacao com o servidor Este facto pode
tambem ser uma realidade nas web applications com a adopcao das tecnologias OWA
Neste momento assiste-se a uma utilizacao cada vez maior da web como uma
plataforma de desenvolvimento A capacidade de cooperacao na edicao de conteudos
e a mobilidade proporcionada por esta plataforma sao os principais factores que
alimentam esta mudanca e pela primeira vez as aplicacoes tradicionais tem com-
peticao vinda de web applications A prova do reconhecimento da web como plataforma
de desenvolvimento pode ser retirada da aposta de empresas como a Adobe e Mi-
crosoft que lancaram publicamente ferramentas web complementares a produtos
seus tradicionalmente associados ao desktop ndash Acrobatcom5 e Microsoft Office
Live6 Dotar estas web applications da capacidade de execucao offline significa
aproximar a web e o desktop reunindo ldquoo melhor de dois mundosrdquo
As vantagens da mobilidade possıvel atraves da web a cooperacao na criacao e
edicao de conteudos e a possibilidade de utilizar aplicacoes sempre actualizadas e
sem necessidade de instalacao sao algumas das principais vantagens que promovem
esta mudanca que devido as preocupacoes associadas a usabilidade e experiencia do
utilizador esta fortemente associada ao desenvolvimento de Rich Internet Applica-
tion (RIA)s
5Adobe Acrobatcom httpwwwacrobatcom6Microsoft ndash httpsmallbusinessofficelivecom
14
Enquadramento do Projecto
Figura 23 Comparacao do modelo de web aplications sıncrono paginas estaticas e in-teractivas abordados nas seccoes 221 e 222 com o modelo de web applications Ajax(assıncrono) abordado na seccao 223 Figura adaptada de http www adaptivepath
com
15
Enquadramento do Projecto
16
Capıtulo 3
Estado da arte
Apesar de o conceito das OWAs nao ser absolutamente novo as tecnologias que
o suportam sao recentes Neste capıtulo descrevem-se quatro tecnologias que foram
tidas como principais candidatas para o desenvolvimento deste projecto Descrevem-
se ainda alguns exemplos de web applications que disponibilizam actualmente fun-
cionalidades offline e o processo da escolha da tecnologia a utilizar neste projecto
31 Gears
O Gears1 e uma extensao as funcionalidades do browser introduzido pelo Google
que tem como principal objectivo tornar possıvel a visualizacao de paginas de Inter-
net mesmo sem uma conexao disponıvel Encontra-se disponıvel para as platafor-
mas Windows Macintosh e Linux e oferece uma API de Javascript que permite
a scripts aceder a um mecanismo de armazenamento local baseado numa base de
dados SQLite
311 Arquitectura
Esta ferramenta e constituıda por tres componentes principais
bull LocalServer mdash Intercepta pedidos de paginas web e serve-as localmente
bull Database mdash Uma base de dados relacional construıda sobre SQLite
bull WorkerPool mdash Permite executar operacoes de computacao de uma forma
assıncrona sem afectar a capacidade de resposta e fluidez de execucao da web
application Assemelham-se a processos
1Google Inc ndash Mais informacao em httpgearsgooglecom
17
Estado da arte
LocalServer
O modulo LocalServer e uma cache de Uniform Resource Locators (URLs)
controlada pela web application Quando nao existe uma ligacao a Internet e e
feito um pedido para um URL presente nesta cache o LocalServer intercepta-o e
responde ao pedido localmente a partir do disco rıgido do utilizador A aplicacao
pode utilizar dois tipos diferentes de armazenamento local de URLs
bull ResourceStore ndash serve para capturar URLs utilizando exclusivamente a API
de Javascript disponibilizada para o efeito Uma aplicacao podera criar e
utilizar diversos ResourceStores simultaneamente para capturar ficheiros de
dados que necessitam de ser enderecados por um URL tal como um ficheiro
PDF ou uma imagem
bull ManagedResourceStore ndash serve para capturar um conjunto de URLs que estao
relacionados e que sao declarado num ficheiro de manifesto (especificado em
JSON) e que sao automaticamente actualizados O ManagedResourceStore
permite que o conjunto de recursos necessarios para correr uma web application
seja capturado e mantido actualizado automaticamente
A principal diferenca entre estes dois tipos de armazenamento de URLs e a forma
como sao actualizados os seus conteudos Os conteudos de um ManagedResourceStore
sao actualizados sempre que a versao contida no ficheiro de manifesto for alterada
enquanto que os conteudos de um ResourceStore nunca sao actualizados automati-
camente mas apenas quando for explicitamente ordenado pela aplicacao
O LocalServer e capaz de interceptar e servir localmente pedidos de HTTP e
HTTPS sempre que se reunam as seguintes condicoes
1 O URL encontra-se armazenado num ResourceStore ou ManagedResourceStore
2 O sistema de armazenamento local encontra-se activo (enabled = true) Se
o sistema de armazenamento local tiver o atributo requiredCookie o pedido
devera conter um cookie que lhe corresponda
O LocalServer nao necessita de monitorizar o estado da ligacao para atender aos
pedidos Na verdade sempre que as condicoes previamente enunciadas se verificarem
o LocalServer interceptara os pedidos e independentemente do estado da ligacao
a Internet servi-los-a a partir do disco rıgido local Cabera a aplicacao definir qual
o modo em que pretende executar um pedido (online ou offline) definindo o valor
de verdade da propriedade enabled
18
Estado da arte
Database
O modulo Database permite guardar dados da web application assegurando a
sua persistencia Os dados sao guardados de forma relacional no disco rıgido do uti-
lizador2 de acordo com o modelo de seguranca estabelecido pelo Gears3 significando
que uma aplicacao nao pode aceder a conteudos fora do seu domınio
WorkerPool
Nos web browsers uma operacao pesada de computacao pode tornar a interface
lenta e tornar menos agradavel a experiencia do utilizador O modulo WorkerPool
permite correr operacoes em background sem bloquear a interface com o utilizador
Os scripts executados numa WorkerPool nao activam os mecanismos de seguranca
do browser que mostram a mensagem ldquoA script on this page may be busy or may
have stopped respondingrdquo
O WorkerPool comporta-se como um conjunto de processos em vez de threads
Os Workers nao partilham qualquer estado de execucao o que significa que uma
alteracao a uma variavel num Worker nao afecta em nada a execucao de outro
Worker Alem disso os Workers nao herdam automaticamente nenhum codigo dos
seus pais Cada Worker e membro de um WorkerPool e os Workers podem in-
teragir entre si enviando mensagens em formato de texto ou JSON No entanto ha
tambem algumas limitacoes os Workers nao tem acesso ao DOM e objectos como
window ou document nao se encontram acessıveis Isto e consequencia de os Workers
nao partilharem o estado de execucao Mas tem acesso a todas as funcoes built-in
do Javascript A maioria das funcionalidades do Gears pode tambem ser acedida
atraves de uma variavel global especial definida como googlegearsfactory Para
outras funcionalidades especıficas os Workers podem ldquopedirrdquo a pagina principal para
continuar a execucao atraves do envio de mensagens
Outras funcionalidades
bull HttpRequest ndash Este modulo implementa a especificacao W3C XmlHttpRe-
quest definida em [vK08] tornando-a disponıvel para os workers e para a
pagina principal
bull Timer ndash Este modulo implementa a especificacao de timers tal como descrito
por [Hic08] e torna-os disponıveis para os workers e para a pagina principal
2Consultar httpcodegooglecomapisgearsapi_databasehtmldirectories3Consultar httpcodegooglecomapisgearssecurityhtml
19
Estado da arte
bull Factory ndash Esta classe e utilizada para instanciar todos os outros objectos da
API do Gears atraves do seu metodo create Este metodo pode ser utilizado
com os seguintes parametros
ndash betadatabase
ndash betahttprequest
ndash betalocalserver
ndash betatimer
ndash betaworkerpool
312 Goggle Gears em dispositivos moveis
O Gears esta tambem disponıvel em dispositivos Windows Mobile 5 e 6
Os dispositivos moveis estao pela sua natureza frequentemente desconectados
da Internet Mesmo quando possuem uma ligacao as latencias na transferencia de
dados em redes moveis tornam as aplicacoes pouco fluıdas mas o Gears permite
ultrapassar este obstaculo
O Gears funciona exactamente da mesma forma em dispositivos moveis equipados
com o Windows Mobile 5 e 6 como num computador comum Se uma aplicacao tiver
sido implementado com suporte para o Gears entao tambem estara preparada para
ser executada num dispositivo movel mas as limitacoes dos browsers disponıveis
para dispositivos moveis tem que ser consideradas Isto significa prever as condicoes
que permitam uma boa usabilidade devido aos pequenos ecras destes dispositivos
bem como o seu suporte limitado dos padroes do DOM CSS e JavaScript
32 Adobe AIR
O Adobe AIR4 e um runtime compatıvel com diversos browsers e sistemas opera-
tivos que pretende dar aos programadores a possibilidade de combinar diversas tec-
nologias de producao de conteudos para a Internet no desenvolvimento de Rich Inter-
net Application (RIA)s O Adobe AIR mantem uma relacao com o browser mas es-
tende as suas capacidades e tecnologias permitindo o desenvolvimento de aplicacoes
tambem para o ambiente de trabalho com janelas em tudo semelhantes as do sis-
tema operativo Segundo a Adobe o objectivo e complementar o browser dando
aos utilizadores (mas essencialmente aos programadores e equipas de desenvolvi-
mento) a escolha sobre como distribuir as suas aplicacoes Para este efeito o Adobe
AIR tem uma aproximacao diferente do Gears Em vez de ldquoestenderrdquo o browser
acrescentando-lhe funcionalidades o AIR permite tambem o desenvolvimento de
4Adobe - httpwwwadobecomproductsair
20
Estado da arte
aplicacoes que se destinam a ser executadas fora do ambiente do browser mas uti-
lizando as tecnologias comuns da Internet (por exemplo HTML CSS JavaScript
Flash Flex)[CDGH08]
A utilizacao desta tecnologia permite utilizar o browser ou o proprio runtime
Adobe AIR como plataforma de execucao da aplicacao
Na Tabela 31 faz-se uma comparacao das funcionalidades disponıveis de acordo
consoante se escolha o browser ou o desktop como plataforma base para a aplicacao
Uma vez que as aplicacoes Adobe AIR na plataforma desktop tem um caracter
persistente (sao instaladas no computador do utilizador) o Adobe AIR tem um
modelo de seguranca que se assemelha com o das tradicionais aplicacoes desktop
[Ada08] Este modelo e analisado nas seccoes 321 e 322 O ambiente em que
e executado o browser e restringido a execucao de web applications que podem
ser de varias origens (incluindo de origens anonimas ou sem confianca) O Adobe
AIR proporciona acesso a capacidades como acesso a ficheiros que necessitam da
confianca do utilizador
bull HTML ndash O desenvolvimento de aplicacoes para o Adobe AIR pode ser feito
com recurso a tecnologias de HTML e Ajax comuns utilizando as linguagens
de markup existentes distribuıdas como texto e interpretadas em execucao
(runtime)
bull Flash ndash Outra alternativa sera a utilizacao da linguagem Flash Permite a
renderizacao de graficos vectoriais e audiovıdeo com suporte nativo Utiliza
ActionScript para adicionar maior interactividade com o utilizador
bull Flex ndash O Flex e uma framework open source para o desenvolvimento de RIAs
usando Flash As aplicacoes Flex sao na realidade Flash sendo a principal
diferenca o ambiente de desenvolvimento
Como resultado uma aplicacao AIR podera ser implementada
bull Baseada em Flash ou Flex (aplicacoes cujo conteudo base e em ShockWave
Flash (SWF))
bull Baseada em Flash ou Flex tambem com HTML ou Portable Document Format
(PDF) Aplicacoes cujo conteudo de base e em FlashFlex (SWF) com HTML
(HTML JavaScript CSS) ou conteudo PDF incluıdo
bull Baseada em HTML Aplicacoes cujo conteudo base e em HTML Javascript
CSS
bull Baseada em HTML utilizando tambem FlashFlex ou PDF
21
Estado da arte
Os utilizadores interagem com uma aplicacao AIR da mesma forma que interagem
com outras aplicacoes com janelas nativas do seu sistema operativo O runtime e
instalado uma vez no computador do utilizador e a partir desse momento todas as
aplicacoes AIR terao o mesmo aspecto que qualquer outra aplicacao para o desktop
321 Seguranca
Permitir que uma web application aceda ao disco de armazenamento do utilizador
pode comprometer seriamente a sua seguranca Neste sentido o Adobe AIR tem
suporte para assinaturas digitais (Secure Sockets Layer (SSL)) que podem ser com-
pradas pelas equipas de desenvolvimento que o desejem e cujos certificados serao
apresentados ao utilizador no momento da instalacao Um outro aspecto ainda
relativo a seguranca e o mecanismo de isolamento de cada ambiente (sandbox )
322 Assinatura do codigo
O runtime AIR exige que todas as aplicacoes estejam digitalmente assinadas As
assinaturas digitais de codigo sao um processo que visa garantir a integridade da
aplicacao e a identidade do seu autor no momento da instalacao As equipas de
desenvolvimento podem ldquoassinarrdquo uma aplicacao utilizando um certificado atribuıdo
por uma Entidade Certificadora (Certification Authority) ou atraves de um certifi-
cado individual (self signed certificate) Neste momento o Adobe AIR suporta como
entidades certificadoras a Verisign e a Thawte [Ado08]
O instalador apresenta o nome de quem publica a aplicacao quando o codigo tiver
sido assinado com um certificado que apresente confianca ou que esteja encadeado
com um certificado que tenha ja sido aceite no computador em que se esta a instalar
a aplicacao
As equipas de desenvolvimento podem tambem assinar as aplicacoes com um
certificado auto-atribuıdo (um certificado criado por elas proprias) mas neste caso
o instalador apresentara estas aplicacoes como sendo de uma origem nao verificada
O AIR utiliza a infraestrutura publica de chaves [Ent07] suportada pelo arquivo
local do sistema operativo Para que a origem da aplicacao seja reconhecida o
computador onde a aplicacao AIR esta a ser instalada tem que confiar directamente
no certificado que foi utilizado para assinar a aplicacao ou confiar num certificado
que esteja num encadeamento logico de certificados confiados e que se ligue desta
forma ao certificado utilizado para assinar a aplicacao
Todas as aplicacoes AIR tem caracterısticas em comum independentemente da
tecnologia utilizada para o seu desenvolvimento (HTMLFlexFlash) No ambito
de uma aplicacao AIR existem um conjunto de APIs que estao disponıveis e que
tornam possıvel o acesso ao sistema local (leitura e escrita) e a recursos de rede que
22
Estado da arte
de outra forma nunca estariam acessıveis a partir de uma web application comum
Cada aplicacao AIR possui tambem diferentes nıveis de isolamento chamados secu-
rity sandboxes dependendo do tipo de conteudo que esta a ser carregado e do seu
objectivo
bull Isolamento ao nıvel da aplicacao5 ndash E a raiz de cada aplicacao AIR Este
nıvel de isolamento permite o acesso a APIs privilegiadas e especıficas do
AIR Em contrapartida e negado o acesso a algumas APIs que poderiam ser
facilmente utilizadas de forma maliciosa contra o utilizador final Importacao
dinamica de conteudos remotos e geralmente proibido e as tecnicas e mecan-
ismos de geracao dinamica de codigo sao fortemente restringidas Apenas
conteudo carregado directamente da directoria base da aplicacao podera ser
colocado neste nıvel de isolamento
bull Isolamento nao especıfico da aplicacao6 ndash contem todo o outro conteudo
que nao tenha sido carregado directamente para o isolamento da aplicacao
Isto inclui conteudo local e remoto Este tipo de conteudo nao tem acesso
directo as APIs do AIR e rege-se pelas mesmas regras tal como se tivesse sido
carregado por um browser a partir da mesma localizacao (por exemplo HTML
carregado a partir de um domınio remoto comporta-se da mesma forma que se
fosse acedido a partir do browser)
33 Mozilla Prism
331 XML User Interface Language
O eXtensible User Interface Language (XUL) e uma linguagem de anotacao
baseada em XML desenvolvida pela Mozilla Foundation que opera em aplicacoes
Mozilla multi plataforma tal como o Firefox O motor Gecko e a unica imple-
mentacao completa desta linguagem que foi desenhada sobre padroes web comuns
como CSS JavaScript e o DOM e permite o desenvolvimento de interfaces graficas
utilizando elementos pre-definidos tais como window box page textbox radio
button entre outros Infelizmente o XUL nao possui qualquer especificacao formal
ou implementacoes de inter-operabilidade para outros motores que nao o Gecko No
entanto a sua implementacao e licenciada em codigo aberto pelas licencas GNU Gen-
eral Public License (GPL) GNU Lesser General Public License (LGPL) e Mozilla
Public License (MPL)
Enunciam-se algumas caracterısticas desta linguagem
5NT application sandbox6NT non-application sandbox
23
Estado da arte
Liguagem de anotacao poderosa baseada em componentes (widgets) O ob-
jectivo do XUL e permitir a construcao de aplicacoes multi-plataforma em
claro contraste com o Dynamic HyperText Transfer Protocol (DHTML) que se
destina ao desenvolvimento de paginas web Por esta razao o XUL esta orien-
tado a componentes tais como janelas botoes e etiquetas em vez de paginas
cabecalhos de texto e ligacoes de hipertexto Investir tempo e esforco para
atingir este mesmo resultado em aplicacoes baseadas em DHTML compromete
frequentemente a complexidade e desempenho da aplicacao
Baseado em padroes O XUL e um dialecto XML baseado no padrao W3C XML
10 As aplicacoes escritas em XUL sao tambem baseadas em especificacoes
W3C adicionais como HTML 40 CSS DOM nıvel 1 e 2 JavaScript 15
incluindo ECMA-262 Edition 3 (ECMAscript)
Portabilidade entre plataformas Tal como HTML o XUL foi desenhado para
ser independente da plataforma em que e utilizado tornando as aplicacoes
facilmente portaveis entre sistemas operativos nos quais o Mozilla e suportado
Uma vez que o XUL oferece um nıvel de abstraccao dos componentes graficos
de interface que disponibiliza implementa a premissa ldquoum codigo para todas
as plataformasrdquo A interface grafica de todos os produtos centrais Mozilla
(browser instant messenger livro de enderecos) e escrita em XUL com um
unico codigo base que suporta todas as plataformas Mozilla
Separacao entre o nıvel de apresentacao e a logica de negocio Uma das
maiores preocupacoes no desenvolvimento para a Internet e a forte ligacao
entre estas duas camadas (interface e logica) Isto constitui um problema sig-
nificativo no desenvolvimento de grandes aplicacoes especialmente quando o
desenvolvimento e feito em ambientes de equipa porque as capacidades de de-
senvolvimento destas duas partes da aplicacao estao muitas vezes espalhadas
por diferentes elementos O XUL permite uma clara distincao entre a definicao
da aplicacao cliente e da logica de implementacao (XUL eXtensible Binding
Language (XBL) e JavaScript) apresentacao (CSS e imagens) internacional-
izacao (Document Type Definitions (DTDs) e etiquetas de texto em lınguas
especıficas guardados em ficheiros properties) O esquema grafico e apre-
sentacao de uma aplicacao XUL pode ser alterado de forma independente da
sua logica ou implementacao e a aplicacao pode ainda ser traduzida (interna-
tionalization) de forma independente da sua logica implementacao ou apre-
sentacao Este grau de separacao resulta em aplicacoes que sao mais faceis de
manter pelos programadores e facilmente adaptadas por designers e tradutores
24
Estado da arte
Facil adaptacao Outro benefıcio que advem do nıvel de separacao entre logica
de negocio e apresentacao oferecido pelo XUL e a facilidade com que se pode
adaptar uma aplicacao para diferentes clientes ou grupos de utilizadores Um
programador pode utilizar a mesma aplicacao base e adapta-la consoante as
necessidades atraves de diferentes temas (skins) e ficheiros de lınguas Desta
forma uma aplicacao escrita e desenvolvida em Ingles pode ser rapidamente
traduzida para Portugues e distribuıda com outra aparencia mais apropriada
ao cliente alvo
332 Prism
O Mozilla Prism e um browser simplificado e ldquointerpretadorrdquo de XUL (tambem
designado por XULRunner) que acolhe web applications sem a interface grafica ha-
bitual de um browser Baseia-se num conceito designado por Site Specific Browser
(SSB) Um SSB e uma aplicacao com um browser embebido desenhado para exe-
cutar apenas uma web application Nao possui os menus e barras de ferramentas
habituais Um SSB tem uma integracao com o sistema operativo e com o desktop
muito mais estreita do que uma web application acedida atraves de um browser uma
vez que e executado em janela propria
O Prism resulta de uma experiencia da Mozilla e visa reduzir as diferencas entre
as desktop applications tradicionais e as web applications Um dos aspectos focados e
a experiencia do utilizador Numa apresentacao oficial e dito que ldquo[o Prism] pretende
ser uma ponte entre as diferencas que existem entre as aplicacoes tradicionais de
desktop e as web applications explorando novos modelos de usabilidade enquanto
que a linha que as separa se continua a definirrdquo [Lab07]
34 HTML 5
A especificacao HTML 5 [Hic08] que se encontra em fase de desenvolvimento
pelo grupo WHATWG pretende ser uma norma de substituicao dos padroes HTML
4 XHTML 1x e do DOM2 HTML Uma das propriedades que o distingue das tec-
nologias que pretende substituir e precisamente o suporte para OWA e armazena-
mento de dados no cliente de uma forma relacional Nao sendo propriamente uma
tecnologia ndashmas antes uma especificacao ndashe aqui mencionada por ter servido como
referencia a diversas implementacoes de funcionalidades offline e por se considerar
que venha a ter um impacto significativo nas implementacoes de diversos browsers
Dion Almaer defendeu no seu blogue que o Gears era uma implementacao do
HTML 5 No seu artigo ldquoGears as a bleeding-edge HTML 5 implementationrdquo [Alm08]
o autor diz que ambos ndasho Gears e o HTML 5 ndashpretendem dar a web caracterısticas
25
Estado da arte
semelhantes e nao encontrar motivo de ldquocompeticaordquo entre as duas mas que en-
quanto o HTML 5 e uma especificacao o Gears e uma implementacao
No entanto tambem e verdade que o HTML 5 cobre muitos outros pontos para
alem das OWA que saem completamente fora do ambito do Gears Se esta es-
pecificacao atingir um estado de maturidade que possibilite a sua adopcao pelos
principais browsers tornando nativo do browser o suporte OWA entao deixara de
fazer sentido a existencia de uma extensao como o Gears
A especificacao HTML 5 disponibiliza duas APIs relevantes para o tema das
OWA
1 Uma base de dados baseada em SQL que permite o armazenamento de dados
do lado do cliente
2 Uma ldquocacherdquo HTTP que garante a disponibilidade das aplicacoes mesmo quando
o utilizador nao possui uma ligacao a Internet
Estas caracterısticas sao as bases da tecnologia das OWA e tem correspondencia
com os pontos analisados nas seccoes 311 e 311
35 Web applications que usam funcionalidades offline
Nesta seccao apresentam-se algumas web applications que actualmente disponi-
bilizam funcionalidades offline Estas aplicacoes foram escolhidas para uma analise
mais pormenorizada por utilizarem o Gears que tal como descrito na seccao 4 foi
a tecnologia escolhida para o projecto
351 Google Reader e Google Docs
O Google Reader7 e um leitor de feeds RSS Permite gerir a subscricao de varios
sites simultaneamente que disponibilizem conteudos neste formato e foi a primeira
web application da Google com uma versao offline publicamente acessıvel (desde
Junho de 2007)
O Google Reader implementa o modo ldquoutilizador deciderdquo oferecendo na sua
interface um botao que permite alternar entre os modos online e offline
O Google Docs8 e uma web application que permite a criacao e edicao de doc-
umentos de texto folhas de calculo e apresentacoes Era ja publico desde Janeiro
de 2008 que o Google estava a desenvolver uma versao OWA desta aplicacao mas o
acesso a uma versao experimental so foi possıvel a partir de 31 de Maio de 2008
7Google Reader - httpreadergooglecom8Google Docs - httpdocsgooglecom
26
Estado da arte
A implementacao das funcionalidades offline nestas duas aplicacoes seguiu difer-
entes aproximacoes principalmente porque o Google Reader apresenta ao utilizador
informacoes que sao fornecidas por fontes externas enquanto que no Google Docs
a informacao e criada e editada pelo utilizador sobre a forma de documentos
A diferente origem da informacao implica que no Google Reader seja necessario
prever casos de excepcao tal como existirem demasiados itens que necessitam de
ser transferidos para o cliente Nao observar este ponto causa um problema grave
de usabilidade e para evitar tempos de espera demasiado longos e uma interface
com pouca capacidade de resposta as accoes do utilizador o Google Reader apenas
transfere para o cliente os dois mil itens mais recentes na transicao para o modo
offline
352 Remember the Milk
O Remember The Milk9 e uma web application desenvolvida por uma equipa
Australiana que proporciona funcionalidades de agenda gestao de tempo e de tare-
fas e foi uma das primeiras aplicacoes independentes do Google a adoptar o Gears
para acessos em modo offline Permite que os seus utilizadores facam uma gestao
de tarefas agrupando-as em listas adicionando-lhes campos de informacao adicional
ou dando-lhes informacao geografica (recorrendo ao servico Google Maps10) Entre
a sua lista de funcionalidades encontra-se ainda a possibilidade de importar e ex-
portar eventos no formato iCalendar (ics) etiquetas (tags) em tarefas publicacao
Really Simple Syndication (RSS) e partilha de categorias de tarefas de acordo com
diferentes nıveis de permissoes de acesso definidos pelo utilizador
353 MySpace e WordPresscom
O MySpace uma das maiores social networks na Internet anunciou recente-
mente que vai disponibilizar uma versao do seu cliente de e-mail que utiliza o Gears
para acelerar o seu desempenho Numa fase inicial estara disponıvel apenas para
utilizadores que tenham cinco mil ou mais mensagens na sua caixa de correio e
permitira efectuar pesquisas muito mais rapido que a sua versao online
O servico de blogs Wordpresscom anunciou tambem o inıcio da utilizacao desta
tecnologia com o fim de melhorar o desempenho A versao que utiliza esta tecnologia
descarrega e armazena no cliente um conjunto de imagens e scripts que passam a
ter preferencia sobre os seus congeneres online e que permitem acelerar o processo
de carregamento da aplicacao e visualizacao de blogs
9Remember The Milk ndash httpwwwrememberthemilkcom10Google Maps ndash httpmapsgooglecom
27
Estado da arte
O MySpace e o Wordpresscom sao dois exemplos da utilizacao da tecnologia
OWA para optimizacao de web application ja existentes Sem pretenderem disponi-
bilizar uma versao que seja totalmente offline fazem uso do Gears para armazenar no
cliente parte dos recursos frequentemente acedidos na visualizacao das suas paginas
36 Escolha da tecnologia
Apos a analise das tecnologias apresentada nas seccoes 31 a 34 foi necessario es-
tudar a adequacao de cada uma delas ao projecto em questao Desde logo e possıvel
observar que nem todas se dedicam apenas a OWA Por exemplo o Adobe AIR
apesar de ter suporte para OWA apenas disponibiliza algumas das funcionalidades
identificadas como mais indicadas para a execucao do projecto quando utilizado
na sua vertente desktop tal como exposto na Tabela 31 mas a utilizacao desta
vertente implicaria o desenvolvimento de novas interfaces e de novas formas de co-
municacao (troca de mensagens XML ou JSON) A vertente web do Adobe AIR
foca-se mais especificamente nas Rich Internet Applications e permite a reutilizacao
do codigo ja existente (exigindo naturalmente a sua adaptacao e a implementacao
das funcionalidades pretendidas)
A tecnologia escolhida para a realizacao deste trabalho foi o Gears sendo que
um dos principais factores a influenciar esta opcao foi a liberdade introduzida pela
sua licenca Berkeley Software Distribution (BSD)11
Considerou-se o funcionamento desta ferramenta extremamente adequando a
aplicacao no WOW uma vez que o seu principal objectivo e precisamente tornar
possıvel a execucao offline de uma pagina web e por virtude deste facto o Gears tem
uma API concisa e de simples aplicacao pratica uma vez que nao possui quaisquer
outros elementos distractores O funcionamento do seu ManagedResourceStore ex-
emplificado na Figura 31 com a capacidade de actualizacao de recursos definidos
num ficheiro manifesto especificado em JSON pesou tambem nesta decisao
11Sobre a licenca BSD consultar httpwwwopensourceorglicensesbsd-licensephp e http
wwwlinfoorgbsdlicensehtml
28
Estado da arte
Figura 31 Esquema UML do processo efectuado pelos recursos do Gears do tipoManagedResourceStore para a actualizacao dos conteudos definidos no ficheiro manifesto
29
Estado da arte
Funcionalidade RIAs no browser RIAs no desktop
Disponibilidadeda aplicacao
As aplicacoes podem ser facil-mente exploradas e utilizadas
As aplicacoes quando instal-adas tem maior grau de fun-cionalidades e persistencia
Instalacao Nao e necessario qualquer tipode instalacao
As aplicacoes sao instaladasatraves do browser ou descar-regadas e instaladas comouma aplicacao tradicional
Actualizacoes Aplicacoes sao actualizadascarregando conteudos paraum website
O AIR disponibiliza uma APIque permite que as aplicacoessejam actualizadas de umaforma
Sistemas opera-tivos suportados
As aplicacoes podem ser exe-cutadas em diversos sistemasoperativos e browsers
As aplicacoes sao multi-plataforma e podem serinstaladas e executadas emdiversos sistemas operativos ebrowsers
Linguagens deprogramacao
Javascript e disponibilizadopelo browser e ActionScripte disponibilizado pelo AdobeFlash Player
Maquinas virtuais deJavascript e ActionScriptcompatıveis com o browser
Capacidade deexecucao embackground
As RIAs podem ser execu-tadas numa janela do browser
As aplicacoes podem ser ex-ecutadas em background edisponibilizar notificacoes talcomo uma aplicacao tradi-cional
Persistencia A actividade esta limitada asessao do browser Quando obrowser e encerrado toda ainformacao e descartada
As aplicacoes sao instaladas eestao disponıveis no desktopPodem armazenar informacaolocalmente e estao disponıveisoffline
Integracao com odesktop
Integracao com o desktop lim-itada devido a restricoes im-postas pelo browser
As aplicacoes podem acederao sistema de ficheiro ao clip-board eventos notificacoesetc
Controlo da inter-face com o uti-lizador
As aplicacoes sao acedidasatraves de uma janela dobrowser que tem os seusproprios controlos e visualgrafico
As aplicacoes tem um vi-sual grafico proprio em janelapropria
Armazenamentode dados
As aplicacoes tem armazena-mento limitado que pode serreescrito pelo browser
As aplicacoes tem acesso a to-talidade do espaco disponıvellocalmente e a uma base dedados com a possibilidade deencriptacao
Tabela 31 Comparacao das funcionalidades oferecidas pelo Adobe AIR para as platafor-mas web e desktop
30
Estado da arte
Aplicacao Modo de execucao utilizadoGoogle Reader Utiliza o modo ldquoutilizador deciderdquo disponibilizando
ao utilizador um botao para alternar entre os modosonline e offline Como lida com informacao recol-hida de fontes externas de natureza frequentementeefemera o processo de sincronizacao apenas transfereos dois mil itens mais recentes quando passa ao es-tado offline Neste modo sao ainda guardadas in-formacoes de itens lidos e etiquetas atribuıdas quesao sincronizadas com o servidor quando o utilizadorvoltar a activar estado online
Google Docs Utiliza o modo ldquoaplicacao deciderdquo permitindo que outilizador edite os conteudos de documentos de textofolhas de calculo e de apresentacoes independente-mente do estado da ligacao desde o momento em queas funcionalidades offline sao activadas A aplicacaofaz pequenas sincronizacoes com o servidor sempre quenecessario
Remember the Milk Utiliza um modo hıbrido entre ldquoaplicacao deciderdquo eldquoutilizador deciderdquo A aplicacao encarrega-se da sin-cronizacao de dados mas disponibiliza um controlona sua interface que permite despoletar manualmenteeste processo para situacoes em que o utilizador fez al-teracoes recentes e pretende usufruir das capacidadesoffline imediatamente
MySpace O MySpace anunciou a utilizacao de mecanismos dearmazenamento de dados no cliente com recurso atecnologias OWA para melhorar o desempenho doseu cliente web de correio electronico nomeadamenteno que diz respeito a operacoes de pesquisa e or-denacao Inicialmente esta funcionalidade estara ape-nas disponıvel para utilizadores com cinco mil ou maismensagens na sua caixa de correio mas nao e aindaclaro se sera disponibilizada uma versao totalmenteoffline
Tabela 32 Resumo da utilizacao de tecnologias OWA em algumas web applications con-sideradas na analise do estado da arte
31
Estado da arte
32
Capıtulo 4
Desenvolvimento
Neste capıtulo introduz-se a aplicacao WOW e apresenta-se o estudo que foi
feito da adequacao de cada tecnologia para a implementacao da funcionalidade of-
fline nesta plataforma Fazem-se diversas consideracoes sobre opcoes a tomar na
concepcao de OWAs e problemas comuns na sua implementacao bem como sug-
estoes para os resolver O WOW e uma aplicacao ja existente de gestao de ordens
de trabalho e do fluxo de tarefas numa empresa ou organizacao
41 Como ficar offline
Na maior parte das web applications de hoje nao existe uma camada de dados
real A aplicacao exemplificada na Figura 41 ao longo da sua execucao acede
directamente a sua unica fonte de dados (o servidor) atraves de chamadas Ajax sem
que exista uma separacao clara destas duas camadas
Para que uma web application seja capaz de ser executada sem uma ligacao
activa a Internet e mantenha o seu caracter dinamico torna-se necessario incluir
Figura 41 Exemplo de uma arquitectura de uma web application sem uma camada deabstraccao de dados Figura adaptada de http gears google com
33
Desenvolvimento
Figura 42 Exemplo de uma arquitectura de uma web application com uma camada deabstraccao de dados Figura adaptada de http gears google com
um mecanismo de armazenamento de dados local seja uma base de dados ou a
capacidade de acesso ao disco No entanto este mecanismo introduz dois problemas
1 Qual das fontes de dados utilizar quando um utilizador faz um pedido de
informacao
2 A necessidade de implementar uma camada de acesso a dados que seja coerente
quer se use o servidor remoto ou local
Por exemplo em vez de a aplicacao Ajax fazer um pedido relativo as contas de
todos os utilizadores em formato JSON directamente ao servidor remoto podera ao
inves fazer o pedido a um objecto intermedio da camada de dados Este objecto
demonstrado na Figura 42 sera responsavel por implementar uma interface de
acesso a base de dados e retornar um objecto JavaScript com uma representacao da
resposta do servidor
Mas a existencia de uma segunda fonte de dados torna recomendavel tambem
a implementacao de uma camada de data switching que em funcao da existencia
de conexao a Internet e da necessidade de actualizacao dos dados decide se faz o
pedido ao servidor remoto ou se fornece os dados presentes localmente Este objecto
apresentado na Figura 43 decidira de forma transparente para o utilizador se le ou
escreve os dados localmente ou se os enviapede ao servidor remoto e pode tambem
iniciar o processo de convergencia de dados e de resolucao de conflitos
411 Funcionalidades disponıveis em modo offline
Por razoes praticas e provavel que nem todas as funcionalidades da aplicacao
possam ser disponibilizadas em modo offline E necessario escolher quais as fun-
cionalidades a disponibilizar no modo offline da aplicacao e implementar a logica
que decide quando utilizar a base de dados local ou o servidor remoto Apesar do
acesso a base de dados local ser muito mais rapido do que aceder ao servidor o
acesso local nem sempre e preferido Ha varias razoes que podem tornar necessario
escolher o acesso ao servidor em vez do acesso local
34
Desenvolvimento
Figura 43 Exemplo de uma arquitectura de uma web application com uma camada deabstraccao de dados e um data switch Figura adaptada de http gears google com
1 A informacao pode ter uma natureza efemera e nao fazer sentido guarda-la
localmente Exemplo dados em tempo real da bolsa de valores de Lisboa
2 Algumas aplicacoes lidam com informacao que so faz sentido na presenca de
uma ligacao Exemplo Instant Messaging
3 A aplicacao podera escolher apenas guardar a informacao acedida mais fre-
quentemente Exemplo para o utilizador poder alterar a lıngua de apre-
sentacao da aplicacao os conteudos terao que ser guardados em todas as
lınguas disponibilizadas pela aplicacao O custo de implementacao de algu-
mas funcionalidades pode nao compensar o benefıcio
4 A capacidade de processamento ou de armazenamento de dados pode inviabi-
lizar algumas funcionalidades offline Exemplo se uma dada funcionalidade
necessita de uma capacidade de armazenamento de dados para alem do razoavel
de um computador pessoal para ser util (visualizador de mapas)
42 Modos de execucao
Um aspecto que e necessario estudar para qualquer web application que se deseje
disponibilizar offline prende-se com tres modos de execucao que devem ser consid-
erados
1 Utilizador decide o modo de execucao A aplicacao tem modos distintos
de execucao para os estados online e offline geralmente indicados na interface
com o utilizador O utilizador e informado do estado da ligacao e participa na
alteracao de estado de execucao da aplicacao interagindo com a sua interface
2 Aplicacao decide o modo de execucao Pode ser implementado na propria
aplicacao um mecanismo de deteccao do estado da ligacao (por exemplo atraves
35
Desenvolvimento
de chamadas Ajax periodicas) transitando de estado e sincronizando automati-
camente Desta forma o utilizador nao precisa de participar na alteracao de
estado a menos que exista um conflito de dados que requeira a sua atencao
3 Aplicacao assume sempre o estado offline Outra hipotese sera imple-
mentar uma web application que assume sempre estar na ausencia de uma
ligacao ao servidor de dados Esta aplicacao responde aos pedidos do uti-
lizador efectuando pedidos de informacao ao servidor mas nao dependendo
de uma resposta valida para mostrar a informacao que ja tinha disponıvel an-
teriormente A sincronizacao de dados com o servidor e tentada sempre que
existam dados para submeter e uma accao do utilizador
421 Modo ldquoutilizador deciderdquo
Neste modo de execucao quando a aplicacao esta online comunica com o servidor
remoto quando esta offline comunica com a base de dados local A informacao tem
que ser sincronizada sempre que se muda de modo A principal vantagem desta opcao
e que e a mais simples de implementar mesmo para uma aplicacao ja existente e
portanto uma forma expedita de disponibilizar uma OWA No entanto tem tambem
algumas desvantagens que devem ser consideradas
1 O utilizador tem que se lembrar de fazer a alteracao de estado de execucao
Caso contrario podera estar a trabalhar inadvertidamente numa versao offline
com dados antigos ou nao ter a informacao necessaria se perder subitamente
a ligacao
2 Se a ligacao for intermitente o utilizador tera ou que escolher um dos modos
de execucao ou estar constantemente a trocar
3 Uma vez que a base de dados nao esta sempre actualizada nao podera ser
utilizada para melhorar a rapidez de execucao da aplicacao quando em modo
online
422 Modo aplicacao decide
A deteccao do estado da ligacao pode ser implementada atraves de um pedido
assıncrono ao servidor tal como ilustrado na Figura 44 O resultado deste pedido
definira o estado online (em caso de sucesso) ou offline (em caso de falha) A
sincronizacao de dados podera ser feita sempre que ocorra uma transicao do es-
tado offline para o estado online No entanto este metodo nao se revela eficiente
36
Desenvolvimento
Figura 44 Esquema grafico ilustrando uma OWA executando no browser utilizando ummodo de execucao do tipo ldquoaplicacao deciderdquo com deteccao automatica do estado daligacao via pedidos Ajax assıncronos a cada cinco segundos
para grandes aplicacoes uma vez que requer a troca de mensagens demasiado fre-
quentes com o servidor que se destinam exclusivamente a monitorizacao do estado
da ligacao
423 Modo ldquoaplicacao assume o estado offlinerdquo
Uma aplicacao transparente funciona assumindo sempre que esta em modo of-
fline ou pelo menos que pode perder a ligacao a qualquer momento Neste modo
tira-se o maximo partido do armazenamento local e fazem-se pequenas mas contınuas
sincronizacoes com o servidor sempre que este esteja disponıvel A sincronizacao de
dados tambem e feita sempre que se volta ao estado online
As vantagens de uma web application transparente sao as seguintes
bull Uma melhor experiencia para o utilizador uma vez que este nao tem que se
preocupar com o estado da ligacao ou com a transicao de estados
bull A aplicacao funciona de forma coerente mesmo que a ligacao seja intermitente
bull Uma vez que o armazenamento local e mantido actualizado pode ser utilizado
para melhorar o desempenho da aplicacao
Foram identificadas as seguintes desvantagens
bull E mais difıcil de implementar e a sincronizacao acarreta cuidados especiais
bull E necessario um cuidado adicional para evitar que as operacoes de sincronizacao
frequentes que ocorrem automaticamente nao afectem os tempos de resposta
da aplicacao
bull Os testes a aplicacao sao mais complexos uma vez que a sincronizacao de dados
nao ocorre em resposta a uma accao do utilizador
37
Desenvolvimento
43 Sincronizacao de dados
A sincronizacao de dados consiste na capacidade de identificar e transferir pe-
riodicamente a versao mais actual dos dados entre o cliente e o(s) servidor(es)
Independentemente do modo de execucao escolhido e mesmo do estado da ligacao
do utilizador a informacao armazenada localmente e a informacao armazenada no
servidor estarao por vezes dessincronizadas Isto podera acontecer sempre que por
exemplo
bull O utilizador faz alteracoes em modo offline
bull A informacao e partilhada e pode ser alterada por uma entidade externa
bull A informacao e fornecida por uma entidade externa
Resolver estas diferencas de forma a que a informacao local e remota encontrem
a igualdade chama-se sincronizacao de dados Ha varias aproximacoes possıveis
para este efeito que dependem da natureza da aplicacao cada uma com vantagens
e desvantagens
A capacidade de suportar a mobilidade dos utilizadores torna-se cada vez um
ponto mais importante de uma web application Para uma organizacao de dimensao
global e vital garantir que os seus colaboradores tem acesso a mesma informacao
que tem disponıvel nos seus postos de trabalho mesmo quando estao fora Na maior
parte dos casos estes colaboradores terao acesso a um computador portatil um
desktop Smartphone ou PDA e atraves destes poderao ter acesso a sua informacao
directamente atraves de ligacoes encriptadas Virtual Private Network (VPN) de um
servidor web ou de outro mecanismo de rede
Esta solucao e simples de implementar mas infelizmente para a maioria dos
colaboradores com grande factor de mobilidade nao e satisfatoria As principais
desvantagens sao as seguintes
bull Requisitos de ligacao Para permitir que os utilizadores acedam a sua in-
formacao e necessario garantir a capacidade constante de comunicacao pelo
menos durante o tempo necessario que assegure a sua transferencia
bull Velocidade de ligacao sem persistencia de dados e em ligacoes de fraca
qualidade a usabilidade por vezes torna-se inaceitavel
bull Ponto crıtico de falha Com este tipo de solucao todos os utilizadores de-
pendem da base de dados que armazena informacao vital para o funcionamento
do cliente
38
Desenvolvimento
bull Scalability do servidor A medida que novos utilizadores sao adicionados ao
sistema o desempenho do servidor e afectado levando a necessidade de maior
capacidade de armazenamento eou processamento
De acordo com a documentacao da Microsoft Sync Framework [Mic08] uma
solucao alternativa consiste em implementar uma Occasionally Connected Appli-
cation (OCA) Uma OCA permite a um utilizador remoto continuar a aceder a
sua informacao mesmo depois de perder a ligacao mas em vez de recorrer a um
servidor recorre a informacao armazenada no seu dispositivo local Para preencher
localmente a informacao que o utilizador necessita uma OCA possui mecanismos
de sincronizacao de dados que sao oferecidos por esta framework
431 Quando sincronizar
Uma das solucoes mais simples de implementar passa por disponibilizar um
mecanismo manual que despoleta a sincronizacao Diz-se manual porque e o uti-
lizador que escolhe quando sincronizar e pode ser implementada simplesmente
fazendo o upload de toda a informacao para o servidor e depois fazendo o download
da copia mais recente da informacao antes de voltar a ficar offline Para que esta
seja uma opcao viavel e necessario que
bull O volume de dados seja suficientemente pequeno para que possa ser transferido
do servidor para o cliente num espaco de tempo aceitavel
bull Que o utilizador indique explicitamente que quer mudar para o estado offline
ou online pressionando um botao da interface
Contudo podem ser identificados alguns problemas relacionados com esta abor-
dagem
bull Os utilizadores nem sempre podem prever o estado das suas ligacoes A ligacao
pode-se perder subitamente ou ter um caracter intermitente
bull O utilizador pode esquecer-se de efectuar a sincronizacao
Outra opcao sera conjugar a sincronizacao de dados com o modo de execucao
transparente A sincronizacao ocorre automaticamente em background de forma
nao intrusiva para o utilizador A aplicacao comunica com o servidor regularmente
efectuando pequenas trocas de dados com o objectivo de manter o sincronismo da
informacao local e remota Esta abordagem pode ser implementada com pedidos
Ajax assıncronos e regulares ao servidor o que permite manter a interaccao com a
interface fluıda evitando bloqueios Estes pedidos sao feitos prevendo as situacoes
39
Desenvolvimento
de disponibilidade ou indisponibilidade (timeout) do servidor Uma outra opcao
sera permitir que o servidor comunique essas alteracoes utilizando Comet1 tal como
descrito em [Wil06] e [Rus06] As vantagens destas aproximacoes sao
bull A informacao esta disponıvel a qualquer altura que o utilizador decida ficar
offline ou que a ligacao seja acidentalmente perdida
bull O desempenho da aplicacao pode ser melhorado quando se estiver a utilizar
uma ligacao a Internet lenta uma vez que o acesso a dados locais e mais
eficiente do que a consulta de dados ao servidor
44 WOW
O WOW e uma plataforma integrada de gestao de ordens de trabalho ja ex-
istente e desenvolvida pela Critical Software SA a qual se pretende adicionar a
capacidade de execucao offline Esta aplicacao e extremamente dinamica e con-
figuravel com um conjunto extremamente rico de funcionalidades das quais se
destacam
bull Gestao de Ordens de Trabalho ndash suportando a gestao dos pedidos desde a
sua criacao ate ao seu fecho tomando em conta os diferentes tipos de pedidos
(ordens de trabalho pedidos de informacao melhorias resolucao de problemas
etc) e diferentes tipos de accoes possıveis para cada um (Figura 45)
bull Monitorizacao de alteracoes ndash Historico de mudancas anexos e estados criando
relatorios de alteracao automaticamente (o que por quem e quando)
bull Uso de Service Level Agreements (SLAs) ndash E possıvel associar a um pedido um
SLA que define qual o perıodo de tempo atribuıdo a resolucao de um pedido
controlando e agilizando a resolucao do mesmo
bull Utilizacao de queries de utilizador configuraveis que permitem acesso rapido
a determinadas ordens de trabalho de acordo com o filtro configurado (por
exemplo ldquoPara mimrdquo ldquoPara o Grupordquo ldquoPelo Grupordquo)
bull Gestao do relacionamento entre pedidos
bull Pesquisa e filtragem de ordens de trabalho
bull Exportacao de dados em formatos padrao (PDF DOC ou XLS)
bull Integravel com solucoes externas
40
Desenvolvimento
Figura 45 Detalhe de um conjunto possıvel de estados e respectivas transicoes para umadada ordem de trabalho no WOW desde a sua submissao no sistema ate a sua conclusaoem fecho ou cancelamento Esta figura representa apenas um exemplo ja que o mapa deestados para uma ordem de trabalho e dinamico e pode ser alterado por um administradorFigura retirada de uma brochura promocional do WOW Critical Software SA
A utilizacao de uma ferramenta deste tipo por parte de uma empresa ou orga-
nizacao oferece vantagens quer a gestao de topo quer aos colaboradores individuais
para os colaboradores individuais o WOW e uma aplicacao onde estao registadas
todas as tarefas contribuindo activamente para o desenvolvimento em ambientes
multi-tarefa e para a organizacao pessoal das tarefas de acordo com prioridades
Para a gestao de topo esta ferramenta permite obter uma visao global do estado da
organizacao em termos de tempo gasto por tarefa executada sendo uma mais valia
para a previsao e gestaoalocacao de recursos
45 Visao geral sobre a arquitectura do WOW
O WOW e interessante nao so do ponto de vista de produto como tambem do
ponto de vista de plataforma Existem diversos plug-ins que estendem as funcional-
idades do WOW e existem ate projectos que pretendem usar a arquitectura do
WOW para criar produtos com fins diferentes do inicial (por exemplo o WOW-
Storm ndash um sistema de registo e classificacao social de ideias)
De modo a conseguir ter essa expansibilidade a plataforma WOW assenta sob
uma arquitectura distribuıda modular e expansıvel com uma componente central
ndash o core ndash estruturado em camadas logicas E no core que se situam todas as
1O Comet e um conceito semelhante ao Ajax introduzido por Alex Russel mas no qual e o servidor quetoma a iniciativa de ldquoenviarrdquo os dados ao browser sem que este tenha que efectuar um pedido Tambem econhecido por Ajax Push Reverse Ajax ou HTTP Streaming
41
Desenvolvimento
funcionalidades base da aplicacao quer a nıvel logico funcional e de apresentacao
quer a nıvel de gestao e configuracao
E possıvel a execucao de varias instancias do core simultaneamente em servidores
distintos o que permite a alta escalabilidade e disponibilidade desta aplicacao A
consistencia dos dados fica sempre garantida atraves da partilha da base de dados
e pelo balanceamento dos pedidos uma vez que cada um e encaminhado para uma
unica instancia
O WOW apresenta tambem a vantagem de ser uma plataforma extensıvel E
possıvel adicionar novas caracterısticas a plataforma atraves de componentes que se
podem ser divididos em duas categorias plugins e connectors
Os plugins sao componentes que se encontram no mesmo no fısico que a aplicacao
partilhando do mesmo contexto de execucao do core Sao assim uma forma mais
directa de obter informacao da plataforma visto que nao possuem restricoes de
acesso aos dados nem dependencias externas A arquitectura deste componente tera
assim que permitir varias execucoes instanciadas cada uma associada a um core
Por outro lado os connectors sao componentes que se encontram distribuıdos
comunicando externamente com o core Quer a sua execucao quer a obtencao
dos dados estao assim dependentes de interfaces de comunicacao externas que a
plataforma disponibiliza Estes componentes ao contrario dos plugins sao instan-
ciados unicamente e recorrem ao protocolo de comunicacao Java Messaging Service
(JMS) para comunicar com o core
46 WOW Offline
Para alem das opcoes tomadas relativamente a tecnologia a utilizar surgiu
tambem a necessidade de optar por um dos modos de execucao apresentados na
seccao 42
Das tres opcoes possıveis foi o modo ldquoaplicacao assume o estado offlinerdquo descrito
na seccao 423 que mereceu a maior atencao uma vez que reune as vantagens de
uma experiencia mais positiva para o utilizador (uma vez que este nao tem que
participar activamente na alteracao do modo execucao como descrito na seccao 421)
e nao constitui uma sobrecarga excessiva para servidor (como o modo abordado na
seccao 422)
No entanto esta opcao comprometia a complexidade da implementacao para alem
dos objectivos propostos para este projecto e para cumprir o prazo dado foi tomada
a decisao de implementar o modo ldquoutilizador deciderdquo especificando apenas de forma
teorica o modo ldquoaplicacao assume o estado offlinerdquo
As caracterısticas do Gears foram ja descritas na seccao 31 Na Figura 47
mostra-se a sua forma de funcionamento quando integrado numa web application
42
Desenvolvimento
Nesta figura representa-se o modulo LocalServer do Gears como um ponto de de-
cisao Aqui sao testadas as condicoes que determinam se o pedido sera interceptado e
servido localmente ou se prossegue para uma maquina remota E tambem represen-
tada uma base de dados que corresponde ao modulo Database mas que podera nao
ser utilizada Este modulo tal como o modulo Workerpool tem caracter opcional
e sao utilizados consoante os requisitos da aplicacao
A plataforma WOW lida com mais dados do que e necessario passar para o
lado do cliente Em conformidade com o ja exposto na seccao 411 volta-se a
frisar que nao se pretende recriar toda a logica de negocio nem os conteudos da
base de dados no cliente pela sua complexidade e volume de dados Pretende-se
pelo contrario permitir que os utilizadores tirem partido da capacidade de poder
consultar as suas ordens de trabalho quando nao dispoe de uma ligacao transferindo
apenas o essencial para isto seja possıvel
A pagina inicial do WOW apresenta um resumo das ordens de trabalho abertas
ndash enviadas e recebidas ndash que se pretende permitir visualizar offline (ver Figura 46)
Como prova de conceito foi efectuada uma abordagem pragmatica das varias possi-
bilidades descritas na seccao 42
461 Modo ldquoaplicacao deciderdquo com deteccao automatica da ligacao
A primeira abordagem estudada para a disponibilizacao das funcionalidades of-
fline foi o modo ldquoaplicacao deciderdquo com deteccao automatica de ligacao apresentado
na seccao 422 Para que isto seja possıvel foi implementado um mecanismo de ver-
ificacao periodica do estado da ligacao atraves de chamadas Ajax assıncronas O
resultado destes pedidos determina o estado da aplicacao executando as tarefas de
sincronizacao de dados sempre que pertinente Este metodo embora imediato e
simples de implementar depressa se revelou inadequado para o projecto devido ao
elevado consumo de recursos do servidor que a utilizacao intensiva faz esperar a
comunidade da plataforma WOW no principal cliente excede os 7000 utilizadores
Foi estimado que para uma utilizacao de fluidez aceitavel o estado da ligacao deveria
ser testado a cada cinco segundos Assumindo uma adesao (previsao pessimista) de
1 aos servicos offline assistir-se-ia a cerca de 840 pedidos adicionais por minuto
Mas o principal problema desta aproximacao prende-se com o facto de a ver-
ificacao ser feita em intervalos de tempo discretos levando a possibilidade de a
aplicacao poder ter em dado momento uma representacao errada do seu estado
real da ligacao Este problema e ilustrado na Figura 48 onde se ve claramente a
discrepancia entre o estado real da ligacao e a representacao interna que esta tem
Note-se que nesta janela de tempo qualquer accao do utilizador que exija uma
resposta sıncrona do utilizador leva-lo-a para um ldquobeco sem saıdardquo onde nao tera
43
Desenvolvimento
Figura 46 A pagina inicial do WOW apresenta um resumo das ultimas ordens de trabalhoenviadas e recebidas Na imagem pode-se observar a transicao do estado online para offline
acesso a versao offline porque a aplicacao nao fez a transicao automatica nem acesso
a versao online porque na verdade nao possui uma ligacao O que acontecera nesta
situacao sera uma tentativa de acesso ao servidor por parte da aplicacao numa
altura em que este se encontra indisponıvel e o resultado sera uma mensagem de
ldquopedido excedeu o tempordquo apresentado pelo browser Este e um estado sem retorno
porque apos o browser apresentar esta mensagem todos os recursos JavaScript ficam
indisponıveis tornando impossıvel o regresso ao estado anterior ou o tratamento do
erro de qualquer outra forma No entanto as chamadas Ajax podem ser tratadas de
forma especial para a eventualidade de falha e portanto nao constituem problema
44
Desenvolvimento
Figura 47 Ilustracao do funcionamento do Gears numa web application que utiliza ummotor Ajax Os pedidos HTTP ou HTTPS podem ser interceptados e tratados localmenteou podem ser feitos a uma maquina remota consoante se verificarem ou nao as condicoesexpressas no ponto 311 E representado um acesso a uma base de dados local (fornecidapelo Gears) mas a sua utilizacao e opcional
462 Implementacao do modo ldquoutilizador deciderdquo
Este modo de execucao foi ja descrito na seccao 421 e a sua principal carac-
terıstica e ser o utilizador a decidir se a aplicacao deve utilizar um servidor remoto
ou a maquina local como fornecedor de dados
Relativamente ao WOW o WOW Offline na vertente ldquoutilizador deciderdquo vem
alterar os seus casos de uso dando ao utilizador a possibilidade de alterar o estado
de execucao da aplicacao (entre online e offline) Resta dizer que no modo online se
mantem todas as funcionalidades anteriores e que no modo offline torna-se possıvel
visualizar os conteudos da pagina principal do WOW (Figura 46) e os detalhes das
ordens de trabalho (Figura 49) tal como expressa a Figura 410
Esta aproximacao foi utilizada na prova de conceito do WOW adicionando um
controlo a interface desta aplicacao que permite ao utilizador alternar entre os esta-
dos online e offline Na transicao de online para offline sao descarregados os recursos
necessarios para a execucao desta aplicacao sem recorrer a Internet Para o fazer
45
Desenvolvimento
Figura 48 Neste exemplo do modo ldquoaplicacao deciderdquo o teste da ligacao e feito e feito acada cinco segundos O resultado deste teste nao reflecte sempre o estado real da aplicacaopodendo levar a aplicacao a ter comportamentos indesejaveis Na figura assinala-se umperıodo de tempo no qual a representacao interna do estado da ligacao nao corresponde arealidade
e utilizado um recurso ResourceStore e um ManagedResourceStore (introduzidos
em 311) O primeiro e utilizado para armazenar a pagina principal do WOW ndash do-
ravante designada por homejsp ndash e o segundo e utilizado para armazenar imagens
folhas de estilo CSS e scripts JavaScript
Para a implementacao deste modo de execucao foram identificadas as seguintes
tarefas
1 Guardar informacao que permita a recriacao das paginas que se pretende
disponibilizar offline (utilizando o Gears)
2 Disponibilizar um controlo que permita alterar o estado de execucao atraves
da interaccao com a pagina principal
3 Durante a sincronizacao de dados apresentar o progresso da transferencia de
dados
O primeiro passo consistiu na identificacao de todos os conteudos que sao necessarios
transferir para a execucao offline Foi utilizado um recurso do Gears do tipo
ManagedResourceStore que recorre a um ficheiro manifesto para identificar to-
dos os ficheiros que deve transferir Este recurso e gerido automaticamente pelo
Gears transferindo para o cliente a versao mais recente sempre que e necessario
isto e sempre que exista um ficheiro manifesto com uma identificacao de versao que
seja diferente da actualmente disponıvel no cliente Uma vez identificados todos
ficheiros necessarios para a execucao offline num (ou mais) ficheiros manifesto o
Gears encarrega-se da sua actualizacao mas o preenchimento destes ficheiros man-
ifesto e manual o que se traduz num cuidado extra na manutencao da aplicacao
A forma como esta informacao e guardada deve tambem ser cuidadosamente
estudada A opcao mais flexıvel passa por utilizar o modulo Database apresentado
na seccao 311 e guardar a informacao de uma forma relacional Para a recriacao
das paginas pode ser disponibilizada uma versao HTML da pagina que funciona
46
Desenvolvimento
Figura 49 Pagina de visualizacao do detalhe de uma ordem de trabalho
como template nao possui quaisquer dados e e utilizada apenas em modo offline E
preenchida para cada pedido retirando os dados relevantes da base de dados
O modelo de dados do WOW torna esta opcao extremamente trabalhosa uma
vez que as entidades envolvidas na geracao de cada pagina de informacao sobre
cada ordem de trabalho tem relacoes de dependencia complexas seguindo padroes
muito variaveis Por exemplo em cada ordem de trabalho existe um formulario que
permite a sua progressao de estado com diversos campos opcionais e obrigatorios
este formulario e definido pelo administrador e esta relacionado nao apenas com o
tipo de ordem de trabalho mas tambem com o estado actual em que esta se encontra
e a accao que se pretende realizar O elevado numero de combinacoes de tipos de
ordem de trabalho estados e accoes que existem num dado momento juntamente
com a sua possibilidade de alteracao obrigariam a implementacao de uma logica de
negocio complexa o que esta fora do ambito deste projecto
47
Desenvolvimento
Figura 410 Esquema UML que expressa os casos de uso do WOW Offline no modoldquoutilizador deciderdquo
463 Especificacao do modo ldquoaplicacao assume o estado offlinerdquo
A aproximacao para o modo ldquoaplicacao assume o estado offlinerdquo foi tambem
dividida em varias tarefas
1 Guardar informacao que permita a recriacao da pagina principal do lado do
cliente no estado offline (utilizando o Gears)
2 Dotar a aplicacao do cliente de um mecanismo de deteccao da ligacao
3 Identificar os ldquomomentos chaverdquo em que devera ocorrer sincronizacao de dados
4 Implementar a sincronizacao de dados
A sincronizacao de dados deve ser feita em ambas as transicoes online-offline e
offline-online quer para transferir novos dados do servidor (os pedidos podem ser
alterados por outros utilizadores) quando se transita do estado quer para comunicar
eventuais alteracoes feitas em modo offline
Relativamente ao WOW o WOW Offline na vertente ldquoaplicacao assume o es-
tado offlinerdquo vem alterar os seus casos de uso dando ao utilizador a possibilidade
de activar esta funcionalidade A partir do momento que a funcionalidade esta ac-
tivada o utilizador deve tambem ter a possibilidade de gerir algumas preferencias
relacionadas com privacidade de dados Devera ter a hipotese de desactivar o ar-
mazenamento local e de remover todos os dados ja armazenados tal como descrito
na Figura 411
48
Desenvolvimento
Figura 411 Esquema UML que expressa os casos de uso do WOW Offline no modoldquoutilizador deciderdquo
A primeira vez que o WOW Offline e acedido por um cliente e caso seja detec-
tada a presenca do Gears todos os recursos necessarios a sua execucao sao trans-
feridos Todos os acessos posteriores serao feitos a estes recursos locais (recorda-se
que o Gears pode ser utilizado para os manter actualizados recorrendo ao Managed-
ResourceStore 311)
Atraves do JavaScript e possıvel interceptar os eventos de load e unload da
pagina que sao despoletados sempre que ocorre um re-acesso da mesma (incluindo
a accao refresh comum dos browsers) sempre que esta e abandonada ou ainda ou
ainda se a janela for encerrada
Tal como sugerido na seccao 462 a camada de interface desta aplicacao (cada
pagina individual em HTML) devera ser implementada como sendo um template
para apresentacao de dados sendo totalmente preenchida atraves de funcoes em
JavaScript O objectivo deste ponto e criar um padrao de dados que permita ao
JavaScript preencher os dados em cada pagina (template) independentemente de
qual seja a fonte ndash o servidor remoto ou a maquina local tal como exemplificado
no diagrama da Figura 412 Na figura a aplicacao recorre ao servidor remoto para
obter os dados pretendidos quando se encontra na presenca de uma ligacao mas
para dados que exijam uma carga de processamento pelo servidor este acto pode ser
49
Desenvolvimento
Figura 412 Esquema UML que expressa o acto de recolha de dados em modo online eoffline recorrendo ao servidor (modo online) e ao sistema de armazenamento de dadoslocal fornecido pelo Gears (modo offline)
substituıdo pelo envio de um campo de controlo que se destina a aferir se os dados
locais se encontram actualizados No caso de estarem actualizados a comunicacao
com o servidor pode ser substituıda por uma query a base de dados local
50
Capıtulo 5
Resultados e Futuros
Desenvolvimentos
Todo o estudo feito sobre o tema OWA foi ja abordado ao longo do documento
Neste capıtulo apresentam-se os resultados obtidos na implementacao da prova de
conceito que visava compreender a melhor forma de disponibilizar uma versao of-
fline no WOW uma plataforma de gestao de ordens de trabalho ja existente de-
senvolvida pela Critical Software SA
51 Resultados Obtidos
Os resultados obtidos neste projecto sao extremamente satisfatorios uma vez
que o estudo do tema OWA e a implementacao de uma prova de conceito que o
ilustrasse foi conseguido com sucesso
A funcionalidade offline foi adicionada ao produto WOW da Critical Software
SA permitindo a visualizacao de ordens de trabalho e dos seus detalhes mesmo na
ausencia de uma conexao activa a Internet Embora para a solucao implementada
tenha sido utilizada uma abordagem do tipo ldquoutilizador deciderdquo pretende-se que esta
seja convertida para ldquoaplicacao deciderdquo ou mesmo para uma aproximacao hıbrida
semelhante a utilizada pelas aplicacoes estudadas nas seccoes 351 e 352
Para a sua implementacao descrita no capıtulo 4 foram tomadas decisoes de or-
dem pratica que permitissem tornar o trabalho exequıvel nos prazos dados Tentou-
se sempre que estas decisoes afectassem o mınimo em termos de desempenho e de
experiencia para o utilizador Considera-se que a implementacao do modo offline
com uma transicao entre modos do tipo ldquoutilizador deciderdquo (ver seccao 42) reflecte
o compromisso entre o desempenho pretendido e os recursos disponıveis e para alem
51
Resultados e Futuros Desenvolvimentos
de ser um exemplo eficaz das possibilidades que as OWA podem trazer a aplicacao
WOW desenvolvida pela Critical Software e tambem um estudo que pode ser uti-
lizado para analisar a implementacao desta tecnologia noutros produtos da mesma
empresa
Note-se que o principal objectivo do trabalho era ganhar familiaridade com este
tema entender as suas vantagens e desvantagens e compreender as suas limitacoes
Tudo indica que existam varias possibilidades de implementacao deste paradigma
noutros produtos da Critical Software que pela sua natureza podem tambem tirar
partido da execucao offline
52 Trabalho Futuro
O desenvolvimento do conceito e formas de implementacao de OWA continua
em forte desenvolvimento no entanto a sua adopcao ainda nao e generalizada A
dificuldade da sua implementacao em web applications ja existentes e o principal
obstaculo a sua maior divulgacao
Ha tambem um factor que deve ser tido em consideracao a manutencao de
codigo A implementacao de uma versao offline de uma web application requer
a implementacao das mesmas regras de negocio (ou de uma versao simplificada)
utilizadas no servidor Para que isto seja possıvel e necessario ter em conta a
capacidade de processamento do cliente e o factor de duplicacao de codigo que
tornara a aplicacao mais difıcil de manter uma vez que uma alteracao a logica de
negocio do servidor implica tambem uma alteracao a sua versao offline
A prova de conceito implementada permite ja a visualizacao offline dos pedidos
abertos (enviados e recebidos) que constam na pagina principal (este numero e
fixo e pode ser alterado pelo administrador) Uma funcionalidade desejavel seria a
possibilidade de interaccao com a aplicacao em modo offline e sincronizacao com o
servidor quando existisse uma ligacao disponıvel
Foi estudada a utilizacao do modo de execucao ldquoaplicacao assume o estado of-
flinerdquo descrito em 423 e esta seria a forma desejavel para o WOW Offline no
entanto para que esta opcao seja viavel sera necessaria a implementacao de uma
forma eficiente de sincronizacao e armazenamento de dados de uma forma relacional
Para atingir este objectivo podera ser seguida uma polıtica de automacao do pro-
cesso no qual a versao online da aplicacao gera scripts de criacao para as tabelas
necessarias na base de dados da versao offline (nao existe nenhuma ferramenta para
o fazer portanto seria necessaria a sua implementacao) e no qual as paginas HTML
disponibilizadas pelo servidor aos clientes web (browser) servem como templates de
apresentacao de informacao e sao preenchidas de forma semelhante pelo servidor ndash
quando a aplicacao estiver online ndash ou pelo cliente atraves de funcoes em JavaScript
52
Resultados e Futuros Desenvolvimentos
ndash quando a aplicacao estiver offline No entanto no WOW devido a quantidade de
informacao tratada e devido as complexas relacoes entre as diferentes entidades e
de esperar que a complexidade da implementacao de um mecanismo deste tipo torne
esta aproximacao demasiado custosa
O HTML 5 embora um forte candidato ainda nao esta suficientemente desen-
volvido A sua especificacao ainda tem o caracter de Draft (rascunho) e esta sujeita
a modificacoes e a aceitacao e implementacao por parte dos browsers e portanto
de momento foi desconsiderado No entanto no futuro se esta especificacao atingir
um estado de maturidade que permita a sua adopcao devera ser considerada como
um possıvel caminho a seguir
53
Resultados e Futuros Desenvolvimentos
54
Capıtulo 6
Conclusoes
Neste capıtulo sao apresentadas as conclusoes do projecto e consideracoes finais
relativamente a tecnologia estudada
61 Conclusoes
O rapido desenvolvimento tecnologico faz prever que a disponibilidade de ligacao
a Internet seja cada vez mais facil e mais rapido mas vao continuar a existir lugares
onde o acesso e limitado e onde as OWA podem desempenhar um papel de relevo
Por outro lado esta tecnologia pode tambem ser utilizada para melhorar o desem-
penho de paginas web com uma necessidade elevada de imagens ou outros recursos
dispendiosos em termos de espaco e foram ate estudados dois exemplos da utilizacao
desta vertente desta tecnologia em 353
Acredita-se que as OWAs vem responder a uma necessidade real por parte das
web applications actuais e que a evolucao que representam se compara a que se
assistiu dos thin-clients para os fat-clients em termos de autonomia do servidor
A capacidade de oferecer conteudos dinamicos no browser independentemente da
existencia de uma ligacao reune as vantagens tıpicas das web applications como
ausencia de instalacao e actualizacoes instantaneas com as vantagens das aplicacoes
de desktop em capacidade de processamento e armazenamento de dados na maquina
local
As tecnologias disponıveis ate a data estudadas no ambito deste projecto que
permitem o desenvolvimento de OWAs e que apresentam maior maturidade sao o
Gears e o Adobe AIR Ambas se apresentam sobre a forma de plugins que necessitam
de uma instalacao extra para poderem ser utilizadas Apesar de esta instalacao ser
55
Conclusoes
apenas necessaria uma vez podera constituir um factor de desencorajamento a sua
adopcao
O HTML 5 uma especificacao abordada neste documento na seccao 34 podera
ser uma alternativa que oferece funcionalidades offline a uma web application sem a
necessidade de qualquer instalacao no entanto esta especificacao ainda nao foi aceite
pelos principais browsers ndash o documento que define o HTML 5 ainda tem o estatuto
de Draft ndash e ainda nao e possıvel antecipar quando e que isto podera acontecer
Um dos problemas que surge frequentemente na implementacao de uma versao
offline para uma web application e a necessidade de sincronizacao de dados Quando
a informacao pode ser alterada por varios utilizadores simultaneamente e necessario
prever os conflitos que daı podem surgir e dotar a aplicacao de uma forma de os
resolver ou alertar o utilizador para a necessidade de alteracao dos dados
Em conclusao todos os objectivos propostos para este projecto foram atingidos
A prova de conceito implementada reflecte de forma clara as possibilidades oferecidas
pela tecnologia OWA e sera utilizado no futuro para compreender a melhor forma
de o implementar de forma definitiva no WOW
56
Referencias
[Ada08] Lucas Adamski Introducing Adobe AIR security model Fevereiro de2008 Disponıvel em httpwwwadobecomdevnetairarticles
introduction_to_air_securityhtml acedido em Marco de 2008
[Ado08] Adobe Adobe AIR 10 Security White Paper 2008 Disponıvel emhttpdownloadmacromediacompubairdocumentation1air_
securitypdf acedido em Marco de 2008
[Alm08] Dion Almaer Gears as a bleeding-edge html 5 implementa-tion March 2008 Disponıvel em httpalmaercomblog
gears-as-a-bleeding-edge-html-5-implementation acedido emMarco de 2008
[BL96] Tim Berners-Lee The world wide web Past present and future Agostode 1996 Disponıvel em httpwwww3orgPeopleBerners-Lee
1996ppfhtml acedido em Abril de 2008
[CDGH08] Mike Chambers Daniel Dura Dragos Georgita and Kevin Hoyt AdobeAIR for JavaScript Developers OrsquoReilly Media 2008 Disponıvel emhttponairadobecomfilesAIRforJSDevPocketGuidepdf ace-dido em Abril de 2008
[Con99] Jim Conallen Modeling Web Application Architectures with UML Junho1999 Disponıvel em httpwwwumlorgcnUMLApplicationpdf
webappspdf acedido em Maio de 2008
[Ent07] Entrust What is a public key information 2007 Disponıvel em http
wwwentrustcompkihtm acedido em Junho de 2008
[Gar05] Jesse James Garret Ajax A new approach to web applicationsFebruary 2005 Disponıvel em httpwwwadaptivepathcomideas
essaysarchives000385php acedido em Marco de 2008
[Greon] Philip Greenspun Philip and Alexrsquos Guide to Web Publishing 2003(last revision) Disponıvel em httpphilipgreenspuncompandaacedido em Junho de 2008
[Gro02a] App Design Group Thick vs thin client comparison 2002 Disponıvelem httpwwwdonjacobsvwcomimagesweekendspecials
Thick-vs-Thinpdf acedido em Junho de 2008
57
REFERENCIAS
[Gro02b] Technical Research Group Thin Client Tecnhology - WhitePaper 2002 Disponıvel em httpwwwpicktrgcompubs
thinclientwhitepaperpdf acedido em Junho de 2008
[Gro08] Miniwatts Marketing Group World internet usage March 2008Disponıvel em httpwwwinternetworldstatscomstatshtm ace-dido em Abril de 2008
[Hic08] Ian Hickson HTML 5 Draft Recommendation 2008 Disponıvelem httpwwwwhatwgorgspecsweb-appscurrent-work ace-dido em Marco de 2008
[Kha] Olga Kharif Top 10 municipal wifi plans Disponıvel em http
imagesbusinessweekcomss0608muni_wifiindex_01htm ace-dido em Marco de 2008
[Lab07] Mozilla Labs Prism Outubro 2007 Disponıvel em httplabs
mozillacom200710prism acedido em Marco de 2008
[Loo06] Chris Loosley Rich Internet ApplicationsDesign MeasurementandManagement Challenges 2006 Disponıvel em httpwwwkeynote
comdocswhitepapersRichInternet_5pdf acedido em Maio de2008
[Mic08] Microsoft Introduction to Occasionally Connected Applications us-ing Sync Services for ADONET 2008 Disponıvel em httpmsdn
microsoftcomen-ussyncbb887608aspx acedido em Junho de2008
[Nao08] Erica Naone Offline web applications Abril 2008 Disponıvelem httpwwwtechnologyreviewcomread_articleaspxch=
specialsectionsampsc=emerging08ampid=20245 acedido emAbril de 2008
[NJN00] Jason Nieh Yang S Jae and Naomi Novik A comparison of thin-clientcomputing architectures 2000 Disponıvel em httpwwwnclcs
columbiaedupublicationscucs-022-00pdf acedido em Maio de2008
[OrsquoR06] Tim OrsquoReilly Web 20 compact definition Trying again Dezembro2006 Disponıvel em httpradaroreillycomarchives200612
web-20-compact-definition-tryihtml acedido em Marco de 2008
[OrsquoR09] Tim OrsquoReilly What is Web 20 Design patterns and business modelsfor the Next Generation of Software 20053009 Disponıvel emhttpwwworeillynetcompubaoreillytimnews200509
30what-is-web-20html acedido em Marco de 2008
[Rus06] Alex Russel Comet Low latency data for the browser March Marco2006 Disponıvel em httpalexdojotoolkitorgp=545 acedidoem Marco de 2008
58
REFERENCIAS
[Sad97] Darleen Sadoski Clientserver software architecturesndashan overviewAgosto 1997 Disponıvel em httpwwwseicmuedustr
descriptionsclientserver_bodyhtml acedido em Junho de2008
[Sch96] George Schussel Clientserver past present and future 1996
[Smi07] Kevin C Smith Css filters - will the browser apply the rule July 2007Disponıvel em httpcentriclecomrefcssfilters acedido emMarco de 2008
[vK08] Anne van Kesteren The XMLHttpRequest Object W3C Work-ing Draft 15 Abril 2008 Disponıvel em httpwwww3orgTR
XMLHttpRequest acedido em Abril de 2008
[Wil06] Greg Wilkins Why ajax comet July Julho 2006 Disponıvel emhttpwwwwebtidecomdownloadswhitePaperWhyAjaxhtml ace-dido em Abril de 2008
59
REFERENCIAS
60
Anexo A
Screenshots
Algumas imagens de aplicacoes que utilizam funcionalidades offline ilustrativasda tecnologia abordada neste documento
Figura A1 Dialogo apresentado ao utilizador na primeira activacao das funcionalidadesoffline no Google Docs amp Spreadsheets
61
Screenshots
Figura A2 Na activacao das funcionalidades offline e tambem oferecida a possibilidadeda criacao de alguns atalhos por exemplo no ambiente de trabalho
Figura A3 O Google Docs mantem a todo o momento a possibilidade de alteracao destasdefinicoes ou da anulacao dos servicos offline para um dado computador
62
Screenshots
Figura A4 Apos a instalacao do Gears qualquer visita ao Remember The Milk despoletauma sincronizacao que ocorre automaticamente e sem necessidade de intervencao por partedo utilizador
Figura A5 Apos completar a sincronizacao de dados mesmo que a ligacao a Internetseja perdida o Remember the Milk continua disponıvel no browser (com excepcao dasfuncionalidades que pela sua natureza exigem uma ligacao como por exemplo partilhade tarefas e envio de convites)
63
Agradecimentos
A realizacao e os objectivos alcancados neste projecto nao teriam sido possıveissem a colaboracao de inumeras pessoas Agradeco profundamente a todos os quecontribuıram directa ou indirectamente para o seu sucesso
A minha orientadora Professora Teresa Galvao Dias e ao Project ManagerEngenheiro Marcus Neves que me conduziram e acompanharam no desenvolvimentodeste projecto
A toda a equipa do WOW em especial o Pedro Maurıcio Costa e o Fabio Matosque contribuıram para a minha a minha integracao na Critical Software e que sempresouberam responder a todas as minhas questoes
A todos os que constituem a CSW Porto pelo fantastico ambiente de amizadeque me proporcionaram
Aos colegas de curso e a todos os que me auxiliaram na revisao deste documento
Os meus sinceros agradecimentos
Joao Goncalves da Costa
v
vi
Conteudo
1 Introducao 111 Enquadramento 112 Motivacao 213 Ambito 314 Objectivos 315 Estrutura do documento 3
2 Enquadramento do Projecto 521 Evolucao das arquitecturas de software 5
211 Thin-clients 5212 Fat-clients 6213 Arquitecturas cliente-servidor 7
22 Evolucao na Internet 8221 Paginas web estaticas 9222 Paginas web interactivas e paginas web dinamicas 9223 Web 20 e Ajax 11
23 Offline Web Applications 1324 Comparacao 13
3 Estado da arte 1731 Gears 17
311 Arquitectura 17312 Goggle Gears em dispositivos moveis 20
32 Adobe AIR 20321 Seguranca 22322 Assinatura do codigo 22
33 Mozilla Prism 23331 XML User Interface Language 23332 Prism 25
34 HTML 5 2535 Web applications que usam funcionalidades offline 26
351 Google Reader e Google Docs 26352 Remember the Milk 27353 MySpace e WordPresscom 27
36 Escolha da tecnologia 28
vii
CONTEUDO
4 Desenvolvimento 3341 Como ficar offline 33
411 Funcionalidades disponıveis em modo offline 3442 Modos de execucao 35
421 Modo ldquoutilizador deciderdquo 36422 Modo aplicacao decide 36423 Modo ldquoaplicacao assume o estado offlinerdquo 37
43 Sincronizacao de dados 38431 Quando sincronizar 39
44 WOW 4045 Visao geral sobre a arquitectura do WOW 4146 WOW Offline 42
461 Modo ldquoaplicacao deciderdquo com deteccao automatica da ligacao 43462 Implementacao do modo ldquoutilizador deciderdquo 45463 Especificacao do modo ldquoaplicacao assume o estado offlinerdquo 48
5 Resultados e Futuros Desenvolvimentos 5151 Resultados Obtidos 5152 Trabalho Futuro 52
6 Conclusoes 5561 Conclusoes 55
Referencias 59
A Screenshots 61
viii
Lista de Figuras
21 Arquitectura de um sistema thin-client em duas camadas (a esquerda)e em tres camadas (a direita) Note-se a inclusao do servidor (main-frame) na definicao das camadas desta arquitectura devido a fortedependencia cliente-servidor 9
22 Arquitectura de um fat-client em duas camadas (a esquerda) e emtres camadas (a direita) 10
23 Comparacao do modelo de web aplications sıncrono paginas estaticase interactivas abordados nas seccoes 221 e 222 com o modelo deweb applications Ajax (assıncrono) abordado na seccao 223 Figuraadaptada de http www adaptivepath com 15
31 Esquema UML do processo efectuado pelos recursos do Gears do tipoManagedResourceStore para a actualizacao dos conteudos definidosno ficheiro manifesto 29
41 Exemplo de uma arquitectura de uma web application sem uma ca-mada de abstraccao de dados Figura adaptada de http gears
google com 33
42 Exemplo de uma arquitectura de uma web application com uma ca-mada de abstraccao de dados Figura adaptada de http gears
google com 34
43 Exemplo de uma arquitectura de uma web application com uma ca-mada de abstraccao de dados e um data switch Figura adaptada dehttp gears google com 35
44 Esquema grafico ilustrando uma OWA executando no browser uti-lizando um modo de execucao do tipo ldquoaplicacao deciderdquo com de-teccao automatica do estado da ligacao via pedidos Ajax assıncronosa cada cinco segundos 37
45 Detalhe de um conjunto possıvel de estados e respectivas transicoespara uma dada ordem de trabalho no WOW desde a sua submissaono sistema ate a sua conclusao em fecho ou cancelamento Esta figurarepresenta apenas um exemplo ja que o mapa de estados para umaordem de trabalho e dinamico e pode ser alterado por um admin-istrador Figura retirada de uma brochura promocional do WOWCritical Software SA 41
ix
LISTA DE FIGURAS
46 A pagina inicial do WOW apresenta um resumo das ultimas ordensde trabalho enviadas e recebidas Na imagem pode-se observar atransicao do estado online para offline 44
47 Ilustracao do funcionamento do Gears numa web application que uti-liza um motor Ajax Os pedidos HTTP ou HTTPS podem ser inter-ceptados e tratados localmente ou podem ser feitos a uma maquinaremota consoante se verificarem ou nao as condicoes expressas noponto 311 E representado um acesso a uma base de dados local(fornecida pelo Gears) mas a sua utilizacao e opcional 45
48 Neste exemplo do modo ldquoaplicacao deciderdquo o teste da ligacao e feitoe feito a cada cinco segundos O resultado deste teste nao reflectesempre o estado real da aplicacao podendo levar a aplicacao a tercomportamentos indesejaveis Na figura assinala-se um perıodo detempo no qual a representacao interna do estado da ligacao nao cor-responde a realidade 46
49 Pagina de visualizacao do detalhe de uma ordem de trabalho 47410 Esquema UML que expressa os casos de uso do WOW Offline no
modo ldquoutilizador deciderdquo 48411 Esquema UML que expressa os casos de uso do WOW Offline no
modo ldquoutilizador deciderdquo 49412 Esquema UML que expressa o acto de recolha de dados em modo
online e offline recorrendo ao servidor (modo online) e ao sistemade armazenamento de dados local fornecido pelo Gears (modo offline) 50
A1 Dialogo apresentado ao utilizador na primeira activacao das funcional-idades offline no Google Docs amp Spreadsheets 61
A2 Na activacao das funcionalidades offline e tambem oferecida a possi-bilidade da criacao de alguns atalhos por exemplo no ambiente detrabalho 62
A3 O Google Docs mantem a todo o momento a possibilidade de alteracaodestas definicoes ou da anulacao dos servicos offline para um dadocomputador 62
A4 Apos a instalacao do Gears qualquer visita ao Remember The Milkdespoleta uma sincronizacao que ocorre automaticamente e sem ne-cessidade de intervencao por parte do utilizador 63
A5 Apos completar a sincronizacao de dados mesmo que a ligacao aInternet seja perdida o Remember the Milk continua disponıvel nobrowser (com excepcao das funcionalidades que pela sua naturezaexigem uma ligacao como por exemplo partilha de tarefas e enviode convites) 63
x
Lista de Tabelas
21 Comparacao entre thin-clients e fat-clients 7
31 Comparacao das funcionalidades oferecidas pelo Adobe AIR para asplataformas web e desktop 30
32 Resumo da utilizacao de tecnologias OWA em algumas web applica-tions consideradas na analise do estado da arte 31
xi
LISTA DE TABELAS
xii
Glossario
fat-client Cliente que nao depende totalmente de umservidor central para as suas actividadesde processamento e possui frequentementedispositivos de armazenamento de dados
6ndash8
thin-client Cliente que depende de um servidor centralpara as suas actividades de processamento
5ndash8
web application Sistema web (servidor rede HTTPbrowser) onde accoes do utilizador(navegacao e introducao de informacao)afectam o estado logico da aplicacao
i iii1ndash311ndash1517ndash1921ndash232728 3336ndash3842 5556
API Application Programming Interface 10 1718 2326 28
ASP Linguagem interpretada pelo servidorque permite a criacao de paginas webdinamicas Desenvolvida pela Microsoft
11
BSD Berkeley Software Distribution 28
CSS Cascading Style Sheets 12 2021 2324 46
DHTML Dynamic HyperText Transfer Protocol 24DOM Document Object Model 10 12
20 2324
DTD Document Type Definition 24
xiii
Glossario
ECMAScript Padrao de linguagem de programacaodefinido pela Ecma International que orig-inou o JavaScript e o JScript
24
Flash Conteudo interactivo de um ficheiro emformato SWF E desenvolvido pela Adobee visualizado atraves do Adobe FlashPlayer
21
Flex Framework baseada em XML e Action-Script desenvolvida pela Adobe para a pro-gramacao de Rich Internet Applications(RIA)
21
GPL GNU General Public License 23
HTML HyperText Markup Language 1 10ndash12 2124ndash2649
HTTP HyperText Transfer Protocol 2 26
JMS E uma API em Java que permite a troca demensagens entre componentes de software
42
JSON JavaScript Object Notation permite atroca de dados codificados num formatode texto de simples leitura
12 1828 34
LGPL GNU Lesser General Public License 23
Mozilla Prism Browser simplificado e ldquointerpretadorrdquo deeXtensible User Interface Language (XUL)(tambem designado por XULRunner) queacolhe web applications sem a interfacegrafica habitual de um browser
25
MPL Mozilla Public License 23
OCA Occasionally Connected Application 39OWA Offline Web Application i iii
2ndash515 1725 2628 3133 3651 5255 56
PDF Portable Document Format 21
xiv
Glossario
PHP Linguagem interpretada pelo servidorque permite a criacao de paginas webdinamicas mas que pode tambem ser in-vocada a partir da linha de comandos
11
pagina web estatica Pagina web que devolve sempre a mesmaresposta a todos os pedidos para todos osutilizadores e em qualquer contexto
5 9
RIA Rich Internet Applications web appli-cations que apresentam funcionalidadessemelhantes as desktop applications masque mantem a informacao no lado do servi-dor
5 1520 28
RSS Really Simple Syndication 27
SLA Service Level Agreement 40SQLite Segundo a definicao oficial SQLite is a
software library that implements a self-contained serverless zero-configurationtransactional SQL database engine
17
SSB Site Specific Browser 25SSL Secure Sockets Layer 22SWF ShockWave Flash 21
URL Uniform Resource Locator 18
VPN Virtual Private Network 38
WOW Work Orders Web Plataforma de gestaode ordens de trabalho e do seu fluxo de-senvolvida pela Critical Software SA
i iii28 3340ndash434551ndash5356
WWW World Wide Web 11 1214
XBL eXtensible Binding Language 24XHTML eXtensible HyperText Markup Language 12XML eXtensible Markup Language 11 12
23 2428
XSLT eXtensible Stylesheet Language Transfor-mation
12
XUL eXtensible User Interface Language xiv23ndash25
xv
Glossario
xvi
Capıtulo 1
Introducao
Neste capıtulo enquadra-se o tema do projecto introduzindo alguns dos conceitos
nos quais se baseia Apresentam-se as motivacoes ambito objectivos e a estrutura
deste documento
11 Enquadramento
A Internet foi originalmente concebida para ser um espaco de partilha de in-
formacao onde pessoas (atraves de maquinas) pudessem comunicar Na sua origem
as paginas eram estaticas constituıdas por texto formatado em HyperText Markup
Language (HTML) e ligadas entre si [BL96] Hoje encontramos conteudos cada vez
mais complexos e dinamicos incluindo som vıdeo ou streams multimedia [Loo06] e
em 2005 foi introduzido por [OrsquoR09] o termo Web 20
De acordo com [Greon] um website pode pertencer a uma ou varias das seguintes
categorias
bull Documento ndash um website essencialmente estatico onde alteracoes a uma
parte do conteudo nao tem implicacoes no seu comportamento
bull Base de dados ndash um directorio de informacao organizada em categorias
bull Aplicacao ndash um website dinamico que utiliza uma linguagem executada ou
interpretada do lado do servidor e que processa as accoes ou informacao in-
troduzida pelo utilizador para fornecer um servico ou nova informacao
A ultima destas categorias constitui aquilo que e normalmente designado por
web application O conceito utilizado ao longo deste documento e o mesmo que
o introduzido por Jim Coallen em [Con99] que define web application como um
1
Introducao
sistema web (servidor rede HyperText Transfer Protocol (HTTP) browser) onde
accoes do utilizador (navegacao e introducao de informacao) afectam o estado logico
da aplicacao A sua definicao tenta estabelecer que uma web application e um
sistema de software com estado de negocio1 e que a sua interface de interaccao com
o utilizador e distribuıdo atraves de um sistema web
12 Motivacao
A quantidade de informacao que e produzida e armazenada com recurso a es-
tas web applications disponıveis online tais como e-mail blogues ou mesmo docu-
mentacao tornam por vezes a disponibilidade de ligacao uma condicao necessaria
a produtividade e como consequencia desta barreira muitos potenciais utilizadores
opoem-se a adopcao de produtos web em detrimento das tradicionais desktop appli-
cations
Assegurar o acesso a uma ligacao de Internet e hoje muito mais facil A Internet
movel e ja uma realidade e encontra-se amplamente divulgada mas continuam a
existir diversas situacoes nas quais os utilizadores estao privados de uma ligacao
a Internet tais como uma viagem de metro ou de aviao ou quando se encontram
deslocados do seu paıs de origem e nao possuem nenhum plano de subscricao
Uma OWA consiste numa web application que para alem de manter todas as
caracterısticas anteriores se mantem disponıvel mesmo na ausencia de uma ligacao
a Internet e surge como uma tentativa de estreitar as barreiras existentes entre a
web e o desktop Isto significa que devera existir um mecanismo capaz de assegurar
a manutencao do estado logico da aplicacao quando a ligacao com o servidor e
quebrada permitindo ao utilizador continuar a utilizar a aplicacao e que sera capaz
de informar o servidor do estado em que a aplicacao se encontra quando a ligacao for
reposta A principal vantagem que advem desta possibilidade e evidente eliminar
a necessidade da existencia de uma ligacao a Internet para que a aplicacao possa ser
utilizada
Por outro lado a vontade de integracao de funcionalidades tıpicas das desktop
applications nas web applications foi um dos principais factores que impulsionou o
desenvolvimento deste conceito uma vez que obrigou a uma reflexao ldquopara alem
do browserrdquo e a uma adaptacao das arquitecturas existentes que permitisse ou o
acesso a funcionalidades disponibilizadas pelo sistema operativo ou pelo menos a
funcionalidades semelhantes Pretende-se com esta aproximacao tornar possıveis
interaccoes entre o desktop e o browser tais como arrastar um ficheiro para um
formulario web de upload de conteudos melhor suporte para o historico do clipboard
ou ainda o acesso ao sistema de ficheiros local Atingir estes objectivos reflecte-se
1NT business state
2
Introducao
num novo paradigma que reune as vantagens das web applications tais como os
updates instantaneos ou o facto de nao ser necessaria nenhuma instalacao e das
desktop applications como por exemplo persistencia no armazenamento de dados
acesso a funcionalidades do sistema operativo ou integracao e interaccao com outras
aplicacoes sejam elas web applications ou desktop applications
13 Ambito
Este projecto foi realizado na Critical Software SA no ambito do Mestrado
Integrado em Engenharia Informatica e Computacao (MIEIC) da Faculdade de En-
genharia da Universidade do Porto (FEUP) entre os meses de Fevereiro e Julho de
2008
14 Objectivos
Sao objectivos deste projecto
1 Estudar e documentar o tema das OWAs acompanhando os ultimos desenvolvi-
mentos nesta materia
2 Analisar o estado da arte fazendo uma analise crıtica e objectiva sobre as
diversas metodologias existentes
3 Implementar uma prova de conceito que permita a execucao offline de uma
web application documentando todo o processo
4 Estudar a possibilidade de permitir interaccao com a aplicacao (insercoes e
alteracoes aos dados) em modo offline
Em resumo o objectivo deste projecto foi estudar documentar e implementar
uma prova de conceito relacionada com o tema Offline Web Applications (OWA)
Este tema embora nao seja totalmente novo ganhou destaque ao longo do ano de
2007 com o surgimento de diversas ferramentas que se destinam a aproximar web
applications das desktop applications
15 Estrutura do documento
Este documento esta organizado em diferentes seccoes apresentando o projecto
numa sequencia logica organizada da seguinte forma
No capıtulo 1 faz-se uma breve apresentacao do conceito OWAs e do contexto em
que surge Apresenta-se tambem a estrutura do documento e definem-se os
termos e acronimos utilizados
3
Introducao
No capıtulo 2 faz-se uma descricao da evolucao das tecnologias que antecedem as
OWAs e das vantagens e desvantagens de cada uma como forma de enquadra-
mento
No capıtulo 3 analisa-se o estado da arte nesta materia Introduzem-se diversas
tecnologias directamente relacionadas com o tema deste projecto exemplos de
aplicacoes que as usam e as razoes que fundamentam as escolhas de tecnologias
efectuadas
O capıtulo 4 contem o desenvolvimento do projecto Analisa-se a plataforma
WOW de gestao integrada de ordens de trabalho a tecnologia escolhida e
a forma como foi utilizada para implementar a capacidade de execucao offline
O capıtulo 5 descreve os resultado obtidos comparando-os com as expectativas
iniciais do projecto e apresenta desenvolvimentos futuros e possibilidades de
continuacaoaplicacao do conhecimento adquirido
No capıtulo 6 apresentam-se as conclusoes
4
Capıtulo 2
Enquadramento do Projecto
Neste capıtulo apresenta-se um breve resumo da evolucao das arquitecturas de
software cliente-servidor e a forma como estas se comparam a evolucao da Inter-
net procurando estabelecer uma analogia entre o percurso de ambas as tecnolo-
gias Compara-se o comportamento e arquitectura dos thin-clients as paginas web
estaticas a evolucao dos fat-clients as paginas interactivas Web 20 e Ajax e
defende-se que as OWA constituem um proximo passo logico e evolutivo aproxi-
mando a web do desktop Referem-se ainda os principais factores que justificam a
importancia das OWAs e a estreita relacao que tem com as Rich Internet Application
(RIA)s
21 Evolucao das arquitecturas de software
Os termos thin-client e fat-client sao utilizados quer para descrever arquitecturas
logicas (de software) quer para descrever arquitecturas fısicas (de hardware) Neste
capıtulo excepto quando seja dada indicacao em contrario estes termos referem-se
sempre a uma arquitectura logica
Adicionalmente quando se trata de arquitecturas cliente-servidor pode-se estu-
dar a arquitectura desenvolvida do sistema como um todo da arquitectura do servi-
dor ou da arquitectura do cliente Para evitar equıvocos em especial na seccao 213
especifica-se em cada caso qual o sistema estudado
211 Thin-clients
Um thin-client e um computador cliente ou software cliente que no contexto
de uma arquitectura cliente-servidor depende de um servidor central para as suas
5
Enquadramento do Projecto
actividades de processamento e proporciona um canal de entrada e saıda de in-
formacao entre o utilizador e o servidor remoto Este termo quando aplicado a
hardware refere-se habitualmente a um computador que se destina a ser utilizado
como cliente de rede sem armazenamento local e com capacidade de processamento
reduzida [Gro02b] mas o conceito que aqui se analisa refere-se a uma arquitectura
de software que remonta ao inıcio das aplicacoes cliente-servidor
No inıcio da historia da computacao terminais ligavam-se directamente a main-
frames responsaveis por todo o processamento Nesta arquitectura era necessario
desenvolver duas aplicacoes distintas uma aplicacao central no servidor (main-
frame) responsavel pela gestao de toda a informacao e por todas as operacoes de
comunicacao e uma aplicacao de visualizacao instalada no cliente (terminal) O
papel destes terminais era apenas disponibilizar ao utilizador um meio de comu-
nicacao (entrada e saıda) e apresentacao dos resultados do servidor Nao tinham
um papel activo no calculo nem na logica de negocio e frequentemente nao tinham
tambem nenhum mecanismo de armazenamento de dados
Como vantagens esta arquitectura apresenta uma reduzida necessidade de con-
figuracao e manutencao do lado do cliente Uma vez que o centro do processamento
e manipulacao de dados ocorre no servidor existe tambem uma centralizacao da
informacao [NJN00] que introduz um ponto crıtico de falha1 Actualizacoes e novas
funcionalidades sao faceis de distribuir uma vez que requerem apenas alteracoes no
servidor [Gro02a]
212 Fat-clients
Contrastando com os thin-clients nesta arquitectura os clientes implementam
ja uma parte da logica de negocio e sao responsaveis pelo processamento de dados
Estes fat-clients vieram responder a necessidade crescente de aplicacoes com um
nıvel de interactividade e capacidade de configuracao maior que as oferecidas pela
arquitectura thin-client descrita na seccao 211 Apesar de manterem a sua de-
pendencia do servidor podem tambem ser executados sem uma conexao activa uma
vez que dispoe de armazenamento de dados local o que lhes confere a capacidade
de persistencia de dados e do estado de execucao entre cada sessao
Foi disponibilizando este controlo sobre o estado da aplicacao bem como acesso
a recursos locais (por exemplo sistema de ficheiros e perifericos) que surgiram as
primeiras verdadeiras desktop applications No entanto cada cliente tinha que ser
separadamente instalado no computador pessoal de cada utilizador que pretendesse
utilizar ou interagir com a aplicacao e uma actualizacao ao servidor implicava in-
variavelmente uma actualizacao manual tambem no cliente Uma vez que nem todos
1NT single point of failure
6
Enquadramento do Projecto
Thin-clients Fat-clientsNao toma parte no processamento dedados nem possui acesso ao sistema deficheiros
Participa activamente no processa-mento de dados recorrendo ao sis-tema de armazenamento local para ar-mazenamento de dados
Nao mantem registo do estado logicoda aplicacao entre duas sessoes de uti-lizacao
O acesso ao armazenamento localpermite-lhe manter registo do estadologico da aplicacao entre duas sessoes
O thin-client nao necessita de qualquerinstalacao estando ldquopronto a utilizarrdquo
E geralmente necessario instalar aaplicacao para poder interagir com oservidor
Qualquer update no servidor reflecte-seimediatamente por todos os clientes
Embora a aplicacao cliente possa aler-tar para existencia de novas versoes asactualizacoes tem que ser manualmenteinstalados pelo cliente
O software do cliente destina-se apenasa apresentacao de dados e comunicacaocom o servidor sendo portanto de sim-ples implementacao
Como o software do cliente toma parteactiva no processamento de dadosa sua implementacao requer cuidadosadicionais
Grande mobilidade uma vez que todaa informacao e mantida no servidor
Parte da informacao podera estar ape-nas do lado cliente pelo que existemalgumas restricoes a sua mobilidade
Tabela 21 Comparacao entre thin-clients e fat-clients
os utilizadores actualizam regularmente as suas aplicacoes o servidor tem que estar
preparado para lidar com versoes antigas2 ou descontinuar os seus servicos a uma
parte da sua comunidade de utilizadores ate que estes actualizem os seus sistemas
Como os utilizadores passam a utilizar os seus recursos locais para armazenamento
de dados as alteracoes que nao sejam sincronizadas com o servidor estao apenas
disponıveis nos seus computadores pessoais o que introduz uma restricao a mobili-
dade
Pode-se afirmar que as vantagens dos thin-clients sao as desvantagens dos fat-
clients e que as vantagens dos fat-clients sao as vantagens dos thin-clients tal como
se ilustra na Tabela 21
213 Arquitecturas cliente-servidor
Introduzidos os termos thin-client e fat-client interessa reafirmar que ambos
podem ser vistos como arquitecturas cliente-servidor Um cliente define-se como
um solicitador de servicos e um servidor como um prestador de servicos tal como
definido por [Sch96] e [Sad97]
2NT backward compatibility
7
Enquadramento do Projecto
As arquitecturas cliente-servidor sao categorizadas pela modularizacao com que
sao desenhadas sendo consideradas as seguintes camadas
1 Interface grafica (front-end) atraves da qual os utilizadores interagem com
a aplicacao Quando este modulo e implementado separadamente dos outros
dois constitui uma aplicacao thin-client por si so uma vez que nao implementa
regras de negocio (embora possa definir validacoes de formularios de insercao de
dados por exemplo) A informacao introduzida pelo utilizador e enviada para
o servidor que processa o seu pedido e retorna uma resposta Este processo
repete-se ate que o utilizador atinja o seu objectivo ou se desligue do sistema
2 A logica de negocio tambem designada por camada intermedia que imple-
menta as regras de aceitacao e validacao de todos os dados introduzidos pelo
utilizador E tambem a plataforma de comunicacao que une a camada superior
de visualizacao com a camada de acesso a dados
3 A camada de dados inclui quer o sistema de persistencia de dados onde sao
armazenados os dados relevantes como tambem os mecanismos necessarios
para a sua pesquisa seleccao e alteracao
Os thin-clients quando observados no seu conjunto de cliente e servidor podem
ser vistos quer como sistemas de duas camadas quer como sistemas de tres camadas
dependendo apenas da forma como o servidor for implementado No caso de na
implementacao do servidor nao se distinguir a camada de acesso a dados da camada
da logica de negocio sao designados por sistemas de duas camadas Caso seja feita
esta distincao sao designados por sistemas de tres camadas Ambos os casos sao
ilustrados na Figura 21
Historicamente os fat-clients eram implementados numa arquitectura em duas
camadas Possuıam apenas um modulo de visualizacao de dados designado por
camada de interface e um modulo que implementava toda a logica de negocio e
regras de acesso a base de dados No entanto com a introducao de ligacoes mais
rapidas e de computadores pessoais com maior capacidade de processamento e so-
bretudo devido a complexidade crescente das aplicacoes a logica de negocio e a
camada de acesso a dados tornaram-se independentes Este modelo e designado por
arquitectura em tres camadas e e ilustrado na Figura 22
22 Evolucao na Internet
Ao analisar a evolucao das arquitecturas das aplicacoes desenvolvidas para a
Internet podemos encontrar um paralelismo com a historia da arquitectura de soft-
ware
8
Enquadramento do Projecto
Figura 21 Arquitectura de um sistema thin-client em duas camadas (a esquerda) e emtres camadas (a direita) Note-se a inclusao do servidor (mainframe) na definicao dascamadas desta arquitectura devido a forte dependencia cliente-servidor
221 Paginas web estaticas
Uma pagina web estatica devolve sempre a mesma resposta a todos os pedidos
para todos os utilizadores e em qualquer contexto utilizando o hipertexto como
forma de ligacao entre diversas paginas estaticas
A informacao e armazenada num servidor e o papel do cliente e apenas a apre-
sentacao da informacao Esta forma de disponibilizacao de informacao pode assim
ser comparada com os thin-clients descritos na seccao 211 o utilizador acede a
um website estatico para visualizar informacao sem que o cliente tome parte no
processamento A unica diferenca e que no caso da web estatica a informacao ap-
resentada e sempre a mesma enquanto que nos thin-clients era frequente existir a
possibilidade de insercao de dados no cliente e apos o seu processamento servidor
nova informacao poderia ser apresentada O hipertexto e utilizado para ligar as
paginas entre si numa rede de conteudos relacionados e a navegacao sıncrona era
feita atraves de cliques do rato a cada clique uma nova pagina era apresentada
Este modelo sıncrono e ilustrado na Figura 23
222 Paginas web interactivas e paginas web dinamicas
O JavaScript e uma linguagem interpretada de scripting que tem os browsers
como principal ambiente de acolhimento Os browsers utilizam uma Application
9
Enquadramento do Projecto
Figura 22 Arquitectura de um fat-client em duas camadas (a esquerda) e em tres camadas(a direita)
Programming Interface (API) publica para criar ldquoobjectosrdquo responsaveis por reflectir
e disponibilizar o Document Object Model (DOM) para o motor de JavaScript
A utilizacao mais frequente desta linguagem e a escrita de funcoes que sao em-
bebidas ou incluıdas em paginas web e que interagem com o DOM Uma vez que o
JavaScript e executado localmente (na maquina do cliente e nao no servidor) e capaz
de responder rapidamente a accoes do utilizador tornando a execucao de aplicacoes
no browser mais fluıdas o JavaScript pode tambem detectar accoes do utilizador
que o HTML nao pode tal como o pressionar de uma tecla
Em Dezembro de 1995 a Netscape Communications adicionou suporte para o
JavaScript no browser Netscape Navigator3 e em Agosto de 1996 o browser Internet
Explorer4 da Microsoft passou a tambem a suportar uma versao semelhante desta
linguagem (hoje todos os principais browsers suportam esta tecnologia)
Esta inovacao permitiu tornar os websites mais interactivos mas a sua utilizacao
esteve confinada apenas a este proposito durante um longo perıodo As paginas
passaram a responder activamente a accoes do utilizador (sendo uma das utilizacoes
3Netscape Communications ndash httpbrowsernetscapecom4Microsoft Internet Explorer ndash httpwwwmicrosoftcomwindowsproductswinfamilyie
10
Enquadramento do Projecto
mais vulgares a validacao de formularios) mas continuaram essencialmente estaticas
O JavaScript ainda nao era nesta altura utilizado para processar dados
Tambem nesta altura (1995ndash96) surgiram linguagens server-side como o PHP
Hypertext Preprocessor (PHP) e Active Server Pages (ASP) e o servidor passou a ter
um processamento de dados introduzidos pelo utilizador mais activo Generalizaram-
se as paginas dinamicas capazes de responder a insercao de dados ou outros pedidos
determinados por accoes do utilizador As paginas tornaram-se aplicacoes web ap-
plications
Uma definicao tradicional de web application e um conjunto de paginas web
logicamente agrupadas e geridas por uma unica entidade que tem como pontos de
entrada formularios de insercao de dados (web forms) Uma web application nao e
mais do que uma aplicacao que e acedida atraves de um browser Tem geralmente
uma arquitectura logica em tres (interface logica de negocio e camada de dados)
camadas e estao armazenadas num servidor
Ha dois tipos de web applications
bull Orientadas a apresentacao Sao web applications que geram paginas web in-
teractivas constituıdas por varios tipos de linguagens de anotacao (por exem-
plo HTML eXtensible Markup Language (XML)) e que apresentam conteudo
dinamico como resposta a pedidos efectuados pelo utilizador
bull Orientadas aos servicos Uma web application orientada aos servicos imple-
menta o ponto de acesso para um ou mais de um web service Sao geralmente
clientes de service oriented web applications
Uma vantagem significativa de implementar uma web application de forma a
suportar as funcionalidades padrao dos browsers e que estas terao o mesmo com-
portamento independentemente da plataforma e do browser a partir do qual serao
acedidas No entanto diferentes implementacoes de browsers devido a diferentes
interpretacoes dos padroes definidos tornam por vezes esta tarefa um pouco mais
complicada existindo inclusivamente na web guioes de compatibilidade para os difer-
entes browsers como [Smi07]
223 Web 20 e Ajax
O termo web 20 descreve uma tendencia de utilizacao e de design observada
na World Wide Web (WWW) com o objectivo de melhorar a criatividade partilha
de informacao e principalmente a colaboracao entre utilizadores Estes conceitos
levaram ao desenvolvimento e evolucao de comunidades online tais como redes so-
ciais wikis e blogues
11
Enquadramento do Projecto
O termo tornou-se mais conhecido apos a primeira conferencia OrsquoReilly Media
Web 20 em 2004 e apesar de sugerir uma nova versao da WWW nao se refere a
qualquer evolucao tecnologica mas apenas a alteracoes a forma como os utilizadores
se servem da web De acordo com Tim OrsquoReilly [OrsquoR06] ldquoWeb 20 e uma revolucao
na industria do software causada pela adopcao da web como uma plataforma e pela
tentativa de entendimento das regras para o sucesso nesta nova plataformardquo
O desenvolvimento da Web 20 serve-se muitas vezes de um outro conceito Ajax
O conceito que hoje conhecemos como Ajax muitas vezes incorrectamente de-
scrito como uma tecnologia foi originalmente criado para permitir o desenvolvimento
de web applications que se assemelhassem ainda mais a aplicacoes de desktop Este
conceito foi melhor descrito por [Gar05] como um conjunto de varias tecnologias
que podem ser utilizadas para melhorar a experiencia do utilizador de uma dada
web application introduzindo a capacidade assıncrona de envio de pedidos ou da
recepcao assıncrona de respostas As tecnologias mais frequentemente envolvidas
sao
bull eXtensible HyperText Markup Language (XHTML) e Cascading Style Sheets
(CSS) padrao para a apresentacao
bull interaccao dinamica atraves do DOM
bull troca e manipulacao de dados utilizando XML e eXtensible Stylesheet Lan-
guage Transformation (XSLT) ou JavaScript Object Notation (JSON)
bull pedidos assıncronos utilizando XMLHttpRequest [vK08]
bull JavaScript utilizado para integrar todas estas tecnologias
E importante frisar que o Ajax nao e um produto nem uma tecnologia E um
termo que descreve a utilizacao de um conjunto de tecnologias para o desenvolvi-
mento de web applications com um elevado grau de interactividade Comparativa-
mente as web applications tradicionais o Ajax introduz uma camada de visualizacao
diferente em tres importantes pontos
1 Do lado do cliente existe um motor que serve de intermediario entre a interface
da aplicacao e o servidor
2 A actividade do utilizador despoleta chamadas JavaScript em vez de um pedido
de pagina directamente ao servidor
3 Informacao codificada em XML em vez de paginas HTML e trocada entre o
servidor e o cliente
12
Enquadramento do Projecto
Isto significa que as paginas que utilizam Ajax contem um motor do lado do
cliente composto por um conjunto de funcoes JavaScript responsavel pela comu-
nicacao com o servidor e por actualizar a interface com o resultado dessa mesma
comunicacao
Na Figura 23 ilustra-se a natureza assıncrona do Ajax quando comparada com
as web applications tradicionais Como se pode observar adicionando um mecan-
ismo Ajax a uma web application eliminam-se diversos tempos de espera associados
a comunicacoes com o servidor uma vez que a interface nao fica ldquobloqueadardquo a es-
pera da resposta Obtem-se assim aplicacoes com um comportamento mais fluido
eliminando tempos de espera entre cada ldquocliquerdquo e melhorando a experiencia do
utilizador
23 Offline Web Applications
A informacao grafica (bem como folhas de estilo e scripts) tais como as ima-
gens que constituem o visual de uma web application e ja tratada de forma especial
pelos cada vez mais avancados sistemas de cache (armazenamento temporario) dos
browsers Mas estes nao sao ainda capazes de guardar conteudo criado pelo uti-
lizador nem de apresentar informacao independentemente do estado da ligacao
Numa altura onde se fala de servicos de Internet wireless municipalizados [Kha]
comunicacoes 3G e ligacoes de banda larga a alta velocidade a ligacao a rede global
continua a nao estar permanentemente disponıvel para os utilizadores Na WWW
encontra-se uma importante parte da informacao e das aplicacoes utilizadas para
criar e editar conteudos Por vezes informacao vital para a produtividade pode
desaparecer subitamente do mapa de acesso de um utilizador quando este entra no
metro num aviao ou mesmo quando se desloca para uma cidade ou paıs diferente
do habitual onde nao subscreve um plano de acesso que lhe garanta a ligacao
Permitir o acesso offline a estes recursos assume assim a sua importancia porque
permitira estender o alcance da informacao a locais onde nunca esteve antes e per-
mitira tambem melhorar o desempenho das web applications colocando informacao
mais perto dos utilizadores reduzindo a transferencia de dados apenas ao essencial
24 Comparacao
Nas evolucoes descritas neste capıtulo 2 pode-se observar que existe um par-
alelismo entre a evolucao das arquitecturas tradicionais cliente-servidor e a evolucao
a que se assiste na web O comportamento e arquitectura dos thin-clients assemelha-
se ao das paginas estaticas no sentido em que o browser nao toma parte em qualquer
13
Enquadramento do Projecto
processamento e serve apenas como uma plataforma de interaccao com o servidor
tal como os clientes descritos na seccao 211
A sua proxima evolucao os fat-clients trouxeram parte da capacidade de pro-
cessamento para o lado do cliente Na web foi tambem esta a inovacao tecnologica
a que se assistiu com a evolucao das tecnologias que permitiram a criacao de ver-
dadeiras aplicacoes e com a introducao do Javascript no browser dando ao cliente
a capacidade de processamento de dados A necessidade da separacao do codigo
em camadas logicas advem da crescente complexidade das web applications Esta
pratica permite entre outras coisas melhorar o processo de desenvolvimento e a
capacidade de manutencao de uma aplicacao
Os fat-clients tem tambem a capacidade de armazenamento de dados o que
permite a persistencia de informacoes entre duas sessoes e que algumas operacoes
sejam executadas sem a necessidade de comunicacao com o servidor Este facto pode
tambem ser uma realidade nas web applications com a adopcao das tecnologias OWA
Neste momento assiste-se a uma utilizacao cada vez maior da web como uma
plataforma de desenvolvimento A capacidade de cooperacao na edicao de conteudos
e a mobilidade proporcionada por esta plataforma sao os principais factores que
alimentam esta mudanca e pela primeira vez as aplicacoes tradicionais tem com-
peticao vinda de web applications A prova do reconhecimento da web como plataforma
de desenvolvimento pode ser retirada da aposta de empresas como a Adobe e Mi-
crosoft que lancaram publicamente ferramentas web complementares a produtos
seus tradicionalmente associados ao desktop ndash Acrobatcom5 e Microsoft Office
Live6 Dotar estas web applications da capacidade de execucao offline significa
aproximar a web e o desktop reunindo ldquoo melhor de dois mundosrdquo
As vantagens da mobilidade possıvel atraves da web a cooperacao na criacao e
edicao de conteudos e a possibilidade de utilizar aplicacoes sempre actualizadas e
sem necessidade de instalacao sao algumas das principais vantagens que promovem
esta mudanca que devido as preocupacoes associadas a usabilidade e experiencia do
utilizador esta fortemente associada ao desenvolvimento de Rich Internet Applica-
tion (RIA)s
5Adobe Acrobatcom httpwwwacrobatcom6Microsoft ndash httpsmallbusinessofficelivecom
14
Enquadramento do Projecto
Figura 23 Comparacao do modelo de web aplications sıncrono paginas estaticas e in-teractivas abordados nas seccoes 221 e 222 com o modelo de web applications Ajax(assıncrono) abordado na seccao 223 Figura adaptada de http www adaptivepath
com
15
Enquadramento do Projecto
16
Capıtulo 3
Estado da arte
Apesar de o conceito das OWAs nao ser absolutamente novo as tecnologias que
o suportam sao recentes Neste capıtulo descrevem-se quatro tecnologias que foram
tidas como principais candidatas para o desenvolvimento deste projecto Descrevem-
se ainda alguns exemplos de web applications que disponibilizam actualmente fun-
cionalidades offline e o processo da escolha da tecnologia a utilizar neste projecto
31 Gears
O Gears1 e uma extensao as funcionalidades do browser introduzido pelo Google
que tem como principal objectivo tornar possıvel a visualizacao de paginas de Inter-
net mesmo sem uma conexao disponıvel Encontra-se disponıvel para as platafor-
mas Windows Macintosh e Linux e oferece uma API de Javascript que permite
a scripts aceder a um mecanismo de armazenamento local baseado numa base de
dados SQLite
311 Arquitectura
Esta ferramenta e constituıda por tres componentes principais
bull LocalServer mdash Intercepta pedidos de paginas web e serve-as localmente
bull Database mdash Uma base de dados relacional construıda sobre SQLite
bull WorkerPool mdash Permite executar operacoes de computacao de uma forma
assıncrona sem afectar a capacidade de resposta e fluidez de execucao da web
application Assemelham-se a processos
1Google Inc ndash Mais informacao em httpgearsgooglecom
17
Estado da arte
LocalServer
O modulo LocalServer e uma cache de Uniform Resource Locators (URLs)
controlada pela web application Quando nao existe uma ligacao a Internet e e
feito um pedido para um URL presente nesta cache o LocalServer intercepta-o e
responde ao pedido localmente a partir do disco rıgido do utilizador A aplicacao
pode utilizar dois tipos diferentes de armazenamento local de URLs
bull ResourceStore ndash serve para capturar URLs utilizando exclusivamente a API
de Javascript disponibilizada para o efeito Uma aplicacao podera criar e
utilizar diversos ResourceStores simultaneamente para capturar ficheiros de
dados que necessitam de ser enderecados por um URL tal como um ficheiro
PDF ou uma imagem
bull ManagedResourceStore ndash serve para capturar um conjunto de URLs que estao
relacionados e que sao declarado num ficheiro de manifesto (especificado em
JSON) e que sao automaticamente actualizados O ManagedResourceStore
permite que o conjunto de recursos necessarios para correr uma web application
seja capturado e mantido actualizado automaticamente
A principal diferenca entre estes dois tipos de armazenamento de URLs e a forma
como sao actualizados os seus conteudos Os conteudos de um ManagedResourceStore
sao actualizados sempre que a versao contida no ficheiro de manifesto for alterada
enquanto que os conteudos de um ResourceStore nunca sao actualizados automati-
camente mas apenas quando for explicitamente ordenado pela aplicacao
O LocalServer e capaz de interceptar e servir localmente pedidos de HTTP e
HTTPS sempre que se reunam as seguintes condicoes
1 O URL encontra-se armazenado num ResourceStore ou ManagedResourceStore
2 O sistema de armazenamento local encontra-se activo (enabled = true) Se
o sistema de armazenamento local tiver o atributo requiredCookie o pedido
devera conter um cookie que lhe corresponda
O LocalServer nao necessita de monitorizar o estado da ligacao para atender aos
pedidos Na verdade sempre que as condicoes previamente enunciadas se verificarem
o LocalServer interceptara os pedidos e independentemente do estado da ligacao
a Internet servi-los-a a partir do disco rıgido local Cabera a aplicacao definir qual
o modo em que pretende executar um pedido (online ou offline) definindo o valor
de verdade da propriedade enabled
18
Estado da arte
Database
O modulo Database permite guardar dados da web application assegurando a
sua persistencia Os dados sao guardados de forma relacional no disco rıgido do uti-
lizador2 de acordo com o modelo de seguranca estabelecido pelo Gears3 significando
que uma aplicacao nao pode aceder a conteudos fora do seu domınio
WorkerPool
Nos web browsers uma operacao pesada de computacao pode tornar a interface
lenta e tornar menos agradavel a experiencia do utilizador O modulo WorkerPool
permite correr operacoes em background sem bloquear a interface com o utilizador
Os scripts executados numa WorkerPool nao activam os mecanismos de seguranca
do browser que mostram a mensagem ldquoA script on this page may be busy or may
have stopped respondingrdquo
O WorkerPool comporta-se como um conjunto de processos em vez de threads
Os Workers nao partilham qualquer estado de execucao o que significa que uma
alteracao a uma variavel num Worker nao afecta em nada a execucao de outro
Worker Alem disso os Workers nao herdam automaticamente nenhum codigo dos
seus pais Cada Worker e membro de um WorkerPool e os Workers podem in-
teragir entre si enviando mensagens em formato de texto ou JSON No entanto ha
tambem algumas limitacoes os Workers nao tem acesso ao DOM e objectos como
window ou document nao se encontram acessıveis Isto e consequencia de os Workers
nao partilharem o estado de execucao Mas tem acesso a todas as funcoes built-in
do Javascript A maioria das funcionalidades do Gears pode tambem ser acedida
atraves de uma variavel global especial definida como googlegearsfactory Para
outras funcionalidades especıficas os Workers podem ldquopedirrdquo a pagina principal para
continuar a execucao atraves do envio de mensagens
Outras funcionalidades
bull HttpRequest ndash Este modulo implementa a especificacao W3C XmlHttpRe-
quest definida em [vK08] tornando-a disponıvel para os workers e para a
pagina principal
bull Timer ndash Este modulo implementa a especificacao de timers tal como descrito
por [Hic08] e torna-os disponıveis para os workers e para a pagina principal
2Consultar httpcodegooglecomapisgearsapi_databasehtmldirectories3Consultar httpcodegooglecomapisgearssecurityhtml
19
Estado da arte
bull Factory ndash Esta classe e utilizada para instanciar todos os outros objectos da
API do Gears atraves do seu metodo create Este metodo pode ser utilizado
com os seguintes parametros
ndash betadatabase
ndash betahttprequest
ndash betalocalserver
ndash betatimer
ndash betaworkerpool
312 Goggle Gears em dispositivos moveis
O Gears esta tambem disponıvel em dispositivos Windows Mobile 5 e 6
Os dispositivos moveis estao pela sua natureza frequentemente desconectados
da Internet Mesmo quando possuem uma ligacao as latencias na transferencia de
dados em redes moveis tornam as aplicacoes pouco fluıdas mas o Gears permite
ultrapassar este obstaculo
O Gears funciona exactamente da mesma forma em dispositivos moveis equipados
com o Windows Mobile 5 e 6 como num computador comum Se uma aplicacao tiver
sido implementado com suporte para o Gears entao tambem estara preparada para
ser executada num dispositivo movel mas as limitacoes dos browsers disponıveis
para dispositivos moveis tem que ser consideradas Isto significa prever as condicoes
que permitam uma boa usabilidade devido aos pequenos ecras destes dispositivos
bem como o seu suporte limitado dos padroes do DOM CSS e JavaScript
32 Adobe AIR
O Adobe AIR4 e um runtime compatıvel com diversos browsers e sistemas opera-
tivos que pretende dar aos programadores a possibilidade de combinar diversas tec-
nologias de producao de conteudos para a Internet no desenvolvimento de Rich Inter-
net Application (RIA)s O Adobe AIR mantem uma relacao com o browser mas es-
tende as suas capacidades e tecnologias permitindo o desenvolvimento de aplicacoes
tambem para o ambiente de trabalho com janelas em tudo semelhantes as do sis-
tema operativo Segundo a Adobe o objectivo e complementar o browser dando
aos utilizadores (mas essencialmente aos programadores e equipas de desenvolvi-
mento) a escolha sobre como distribuir as suas aplicacoes Para este efeito o Adobe
AIR tem uma aproximacao diferente do Gears Em vez de ldquoestenderrdquo o browser
acrescentando-lhe funcionalidades o AIR permite tambem o desenvolvimento de
4Adobe - httpwwwadobecomproductsair
20
Estado da arte
aplicacoes que se destinam a ser executadas fora do ambiente do browser mas uti-
lizando as tecnologias comuns da Internet (por exemplo HTML CSS JavaScript
Flash Flex)[CDGH08]
A utilizacao desta tecnologia permite utilizar o browser ou o proprio runtime
Adobe AIR como plataforma de execucao da aplicacao
Na Tabela 31 faz-se uma comparacao das funcionalidades disponıveis de acordo
consoante se escolha o browser ou o desktop como plataforma base para a aplicacao
Uma vez que as aplicacoes Adobe AIR na plataforma desktop tem um caracter
persistente (sao instaladas no computador do utilizador) o Adobe AIR tem um
modelo de seguranca que se assemelha com o das tradicionais aplicacoes desktop
[Ada08] Este modelo e analisado nas seccoes 321 e 322 O ambiente em que
e executado o browser e restringido a execucao de web applications que podem
ser de varias origens (incluindo de origens anonimas ou sem confianca) O Adobe
AIR proporciona acesso a capacidades como acesso a ficheiros que necessitam da
confianca do utilizador
bull HTML ndash O desenvolvimento de aplicacoes para o Adobe AIR pode ser feito
com recurso a tecnologias de HTML e Ajax comuns utilizando as linguagens
de markup existentes distribuıdas como texto e interpretadas em execucao
(runtime)
bull Flash ndash Outra alternativa sera a utilizacao da linguagem Flash Permite a
renderizacao de graficos vectoriais e audiovıdeo com suporte nativo Utiliza
ActionScript para adicionar maior interactividade com o utilizador
bull Flex ndash O Flex e uma framework open source para o desenvolvimento de RIAs
usando Flash As aplicacoes Flex sao na realidade Flash sendo a principal
diferenca o ambiente de desenvolvimento
Como resultado uma aplicacao AIR podera ser implementada
bull Baseada em Flash ou Flex (aplicacoes cujo conteudo base e em ShockWave
Flash (SWF))
bull Baseada em Flash ou Flex tambem com HTML ou Portable Document Format
(PDF) Aplicacoes cujo conteudo de base e em FlashFlex (SWF) com HTML
(HTML JavaScript CSS) ou conteudo PDF incluıdo
bull Baseada em HTML Aplicacoes cujo conteudo base e em HTML Javascript
CSS
bull Baseada em HTML utilizando tambem FlashFlex ou PDF
21
Estado da arte
Os utilizadores interagem com uma aplicacao AIR da mesma forma que interagem
com outras aplicacoes com janelas nativas do seu sistema operativo O runtime e
instalado uma vez no computador do utilizador e a partir desse momento todas as
aplicacoes AIR terao o mesmo aspecto que qualquer outra aplicacao para o desktop
321 Seguranca
Permitir que uma web application aceda ao disco de armazenamento do utilizador
pode comprometer seriamente a sua seguranca Neste sentido o Adobe AIR tem
suporte para assinaturas digitais (Secure Sockets Layer (SSL)) que podem ser com-
pradas pelas equipas de desenvolvimento que o desejem e cujos certificados serao
apresentados ao utilizador no momento da instalacao Um outro aspecto ainda
relativo a seguranca e o mecanismo de isolamento de cada ambiente (sandbox )
322 Assinatura do codigo
O runtime AIR exige que todas as aplicacoes estejam digitalmente assinadas As
assinaturas digitais de codigo sao um processo que visa garantir a integridade da
aplicacao e a identidade do seu autor no momento da instalacao As equipas de
desenvolvimento podem ldquoassinarrdquo uma aplicacao utilizando um certificado atribuıdo
por uma Entidade Certificadora (Certification Authority) ou atraves de um certifi-
cado individual (self signed certificate) Neste momento o Adobe AIR suporta como
entidades certificadoras a Verisign e a Thawte [Ado08]
O instalador apresenta o nome de quem publica a aplicacao quando o codigo tiver
sido assinado com um certificado que apresente confianca ou que esteja encadeado
com um certificado que tenha ja sido aceite no computador em que se esta a instalar
a aplicacao
As equipas de desenvolvimento podem tambem assinar as aplicacoes com um
certificado auto-atribuıdo (um certificado criado por elas proprias) mas neste caso
o instalador apresentara estas aplicacoes como sendo de uma origem nao verificada
O AIR utiliza a infraestrutura publica de chaves [Ent07] suportada pelo arquivo
local do sistema operativo Para que a origem da aplicacao seja reconhecida o
computador onde a aplicacao AIR esta a ser instalada tem que confiar directamente
no certificado que foi utilizado para assinar a aplicacao ou confiar num certificado
que esteja num encadeamento logico de certificados confiados e que se ligue desta
forma ao certificado utilizado para assinar a aplicacao
Todas as aplicacoes AIR tem caracterısticas em comum independentemente da
tecnologia utilizada para o seu desenvolvimento (HTMLFlexFlash) No ambito
de uma aplicacao AIR existem um conjunto de APIs que estao disponıveis e que
tornam possıvel o acesso ao sistema local (leitura e escrita) e a recursos de rede que
22
Estado da arte
de outra forma nunca estariam acessıveis a partir de uma web application comum
Cada aplicacao AIR possui tambem diferentes nıveis de isolamento chamados secu-
rity sandboxes dependendo do tipo de conteudo que esta a ser carregado e do seu
objectivo
bull Isolamento ao nıvel da aplicacao5 ndash E a raiz de cada aplicacao AIR Este
nıvel de isolamento permite o acesso a APIs privilegiadas e especıficas do
AIR Em contrapartida e negado o acesso a algumas APIs que poderiam ser
facilmente utilizadas de forma maliciosa contra o utilizador final Importacao
dinamica de conteudos remotos e geralmente proibido e as tecnicas e mecan-
ismos de geracao dinamica de codigo sao fortemente restringidas Apenas
conteudo carregado directamente da directoria base da aplicacao podera ser
colocado neste nıvel de isolamento
bull Isolamento nao especıfico da aplicacao6 ndash contem todo o outro conteudo
que nao tenha sido carregado directamente para o isolamento da aplicacao
Isto inclui conteudo local e remoto Este tipo de conteudo nao tem acesso
directo as APIs do AIR e rege-se pelas mesmas regras tal como se tivesse sido
carregado por um browser a partir da mesma localizacao (por exemplo HTML
carregado a partir de um domınio remoto comporta-se da mesma forma que se
fosse acedido a partir do browser)
33 Mozilla Prism
331 XML User Interface Language
O eXtensible User Interface Language (XUL) e uma linguagem de anotacao
baseada em XML desenvolvida pela Mozilla Foundation que opera em aplicacoes
Mozilla multi plataforma tal como o Firefox O motor Gecko e a unica imple-
mentacao completa desta linguagem que foi desenhada sobre padroes web comuns
como CSS JavaScript e o DOM e permite o desenvolvimento de interfaces graficas
utilizando elementos pre-definidos tais como window box page textbox radio
button entre outros Infelizmente o XUL nao possui qualquer especificacao formal
ou implementacoes de inter-operabilidade para outros motores que nao o Gecko No
entanto a sua implementacao e licenciada em codigo aberto pelas licencas GNU Gen-
eral Public License (GPL) GNU Lesser General Public License (LGPL) e Mozilla
Public License (MPL)
Enunciam-se algumas caracterısticas desta linguagem
5NT application sandbox6NT non-application sandbox
23
Estado da arte
Liguagem de anotacao poderosa baseada em componentes (widgets) O ob-
jectivo do XUL e permitir a construcao de aplicacoes multi-plataforma em
claro contraste com o Dynamic HyperText Transfer Protocol (DHTML) que se
destina ao desenvolvimento de paginas web Por esta razao o XUL esta orien-
tado a componentes tais como janelas botoes e etiquetas em vez de paginas
cabecalhos de texto e ligacoes de hipertexto Investir tempo e esforco para
atingir este mesmo resultado em aplicacoes baseadas em DHTML compromete
frequentemente a complexidade e desempenho da aplicacao
Baseado em padroes O XUL e um dialecto XML baseado no padrao W3C XML
10 As aplicacoes escritas em XUL sao tambem baseadas em especificacoes
W3C adicionais como HTML 40 CSS DOM nıvel 1 e 2 JavaScript 15
incluindo ECMA-262 Edition 3 (ECMAscript)
Portabilidade entre plataformas Tal como HTML o XUL foi desenhado para
ser independente da plataforma em que e utilizado tornando as aplicacoes
facilmente portaveis entre sistemas operativos nos quais o Mozilla e suportado
Uma vez que o XUL oferece um nıvel de abstraccao dos componentes graficos
de interface que disponibiliza implementa a premissa ldquoum codigo para todas
as plataformasrdquo A interface grafica de todos os produtos centrais Mozilla
(browser instant messenger livro de enderecos) e escrita em XUL com um
unico codigo base que suporta todas as plataformas Mozilla
Separacao entre o nıvel de apresentacao e a logica de negocio Uma das
maiores preocupacoes no desenvolvimento para a Internet e a forte ligacao
entre estas duas camadas (interface e logica) Isto constitui um problema sig-
nificativo no desenvolvimento de grandes aplicacoes especialmente quando o
desenvolvimento e feito em ambientes de equipa porque as capacidades de de-
senvolvimento destas duas partes da aplicacao estao muitas vezes espalhadas
por diferentes elementos O XUL permite uma clara distincao entre a definicao
da aplicacao cliente e da logica de implementacao (XUL eXtensible Binding
Language (XBL) e JavaScript) apresentacao (CSS e imagens) internacional-
izacao (Document Type Definitions (DTDs) e etiquetas de texto em lınguas
especıficas guardados em ficheiros properties) O esquema grafico e apre-
sentacao de uma aplicacao XUL pode ser alterado de forma independente da
sua logica ou implementacao e a aplicacao pode ainda ser traduzida (interna-
tionalization) de forma independente da sua logica implementacao ou apre-
sentacao Este grau de separacao resulta em aplicacoes que sao mais faceis de
manter pelos programadores e facilmente adaptadas por designers e tradutores
24
Estado da arte
Facil adaptacao Outro benefıcio que advem do nıvel de separacao entre logica
de negocio e apresentacao oferecido pelo XUL e a facilidade com que se pode
adaptar uma aplicacao para diferentes clientes ou grupos de utilizadores Um
programador pode utilizar a mesma aplicacao base e adapta-la consoante as
necessidades atraves de diferentes temas (skins) e ficheiros de lınguas Desta
forma uma aplicacao escrita e desenvolvida em Ingles pode ser rapidamente
traduzida para Portugues e distribuıda com outra aparencia mais apropriada
ao cliente alvo
332 Prism
O Mozilla Prism e um browser simplificado e ldquointerpretadorrdquo de XUL (tambem
designado por XULRunner) que acolhe web applications sem a interface grafica ha-
bitual de um browser Baseia-se num conceito designado por Site Specific Browser
(SSB) Um SSB e uma aplicacao com um browser embebido desenhado para exe-
cutar apenas uma web application Nao possui os menus e barras de ferramentas
habituais Um SSB tem uma integracao com o sistema operativo e com o desktop
muito mais estreita do que uma web application acedida atraves de um browser uma
vez que e executado em janela propria
O Prism resulta de uma experiencia da Mozilla e visa reduzir as diferencas entre
as desktop applications tradicionais e as web applications Um dos aspectos focados e
a experiencia do utilizador Numa apresentacao oficial e dito que ldquo[o Prism] pretende
ser uma ponte entre as diferencas que existem entre as aplicacoes tradicionais de
desktop e as web applications explorando novos modelos de usabilidade enquanto
que a linha que as separa se continua a definirrdquo [Lab07]
34 HTML 5
A especificacao HTML 5 [Hic08] que se encontra em fase de desenvolvimento
pelo grupo WHATWG pretende ser uma norma de substituicao dos padroes HTML
4 XHTML 1x e do DOM2 HTML Uma das propriedades que o distingue das tec-
nologias que pretende substituir e precisamente o suporte para OWA e armazena-
mento de dados no cliente de uma forma relacional Nao sendo propriamente uma
tecnologia ndashmas antes uma especificacao ndashe aqui mencionada por ter servido como
referencia a diversas implementacoes de funcionalidades offline e por se considerar
que venha a ter um impacto significativo nas implementacoes de diversos browsers
Dion Almaer defendeu no seu blogue que o Gears era uma implementacao do
HTML 5 No seu artigo ldquoGears as a bleeding-edge HTML 5 implementationrdquo [Alm08]
o autor diz que ambos ndasho Gears e o HTML 5 ndashpretendem dar a web caracterısticas
25
Estado da arte
semelhantes e nao encontrar motivo de ldquocompeticaordquo entre as duas mas que en-
quanto o HTML 5 e uma especificacao o Gears e uma implementacao
No entanto tambem e verdade que o HTML 5 cobre muitos outros pontos para
alem das OWA que saem completamente fora do ambito do Gears Se esta es-
pecificacao atingir um estado de maturidade que possibilite a sua adopcao pelos
principais browsers tornando nativo do browser o suporte OWA entao deixara de
fazer sentido a existencia de uma extensao como o Gears
A especificacao HTML 5 disponibiliza duas APIs relevantes para o tema das
OWA
1 Uma base de dados baseada em SQL que permite o armazenamento de dados
do lado do cliente
2 Uma ldquocacherdquo HTTP que garante a disponibilidade das aplicacoes mesmo quando
o utilizador nao possui uma ligacao a Internet
Estas caracterısticas sao as bases da tecnologia das OWA e tem correspondencia
com os pontos analisados nas seccoes 311 e 311
35 Web applications que usam funcionalidades offline
Nesta seccao apresentam-se algumas web applications que actualmente disponi-
bilizam funcionalidades offline Estas aplicacoes foram escolhidas para uma analise
mais pormenorizada por utilizarem o Gears que tal como descrito na seccao 4 foi
a tecnologia escolhida para o projecto
351 Google Reader e Google Docs
O Google Reader7 e um leitor de feeds RSS Permite gerir a subscricao de varios
sites simultaneamente que disponibilizem conteudos neste formato e foi a primeira
web application da Google com uma versao offline publicamente acessıvel (desde
Junho de 2007)
O Google Reader implementa o modo ldquoutilizador deciderdquo oferecendo na sua
interface um botao que permite alternar entre os modos online e offline
O Google Docs8 e uma web application que permite a criacao e edicao de doc-
umentos de texto folhas de calculo e apresentacoes Era ja publico desde Janeiro
de 2008 que o Google estava a desenvolver uma versao OWA desta aplicacao mas o
acesso a uma versao experimental so foi possıvel a partir de 31 de Maio de 2008
7Google Reader - httpreadergooglecom8Google Docs - httpdocsgooglecom
26
Estado da arte
A implementacao das funcionalidades offline nestas duas aplicacoes seguiu difer-
entes aproximacoes principalmente porque o Google Reader apresenta ao utilizador
informacoes que sao fornecidas por fontes externas enquanto que no Google Docs
a informacao e criada e editada pelo utilizador sobre a forma de documentos
A diferente origem da informacao implica que no Google Reader seja necessario
prever casos de excepcao tal como existirem demasiados itens que necessitam de
ser transferidos para o cliente Nao observar este ponto causa um problema grave
de usabilidade e para evitar tempos de espera demasiado longos e uma interface
com pouca capacidade de resposta as accoes do utilizador o Google Reader apenas
transfere para o cliente os dois mil itens mais recentes na transicao para o modo
offline
352 Remember the Milk
O Remember The Milk9 e uma web application desenvolvida por uma equipa
Australiana que proporciona funcionalidades de agenda gestao de tempo e de tare-
fas e foi uma das primeiras aplicacoes independentes do Google a adoptar o Gears
para acessos em modo offline Permite que os seus utilizadores facam uma gestao
de tarefas agrupando-as em listas adicionando-lhes campos de informacao adicional
ou dando-lhes informacao geografica (recorrendo ao servico Google Maps10) Entre
a sua lista de funcionalidades encontra-se ainda a possibilidade de importar e ex-
portar eventos no formato iCalendar (ics) etiquetas (tags) em tarefas publicacao
Really Simple Syndication (RSS) e partilha de categorias de tarefas de acordo com
diferentes nıveis de permissoes de acesso definidos pelo utilizador
353 MySpace e WordPresscom
O MySpace uma das maiores social networks na Internet anunciou recente-
mente que vai disponibilizar uma versao do seu cliente de e-mail que utiliza o Gears
para acelerar o seu desempenho Numa fase inicial estara disponıvel apenas para
utilizadores que tenham cinco mil ou mais mensagens na sua caixa de correio e
permitira efectuar pesquisas muito mais rapido que a sua versao online
O servico de blogs Wordpresscom anunciou tambem o inıcio da utilizacao desta
tecnologia com o fim de melhorar o desempenho A versao que utiliza esta tecnologia
descarrega e armazena no cliente um conjunto de imagens e scripts que passam a
ter preferencia sobre os seus congeneres online e que permitem acelerar o processo
de carregamento da aplicacao e visualizacao de blogs
9Remember The Milk ndash httpwwwrememberthemilkcom10Google Maps ndash httpmapsgooglecom
27
Estado da arte
O MySpace e o Wordpresscom sao dois exemplos da utilizacao da tecnologia
OWA para optimizacao de web application ja existentes Sem pretenderem disponi-
bilizar uma versao que seja totalmente offline fazem uso do Gears para armazenar no
cliente parte dos recursos frequentemente acedidos na visualizacao das suas paginas
36 Escolha da tecnologia
Apos a analise das tecnologias apresentada nas seccoes 31 a 34 foi necessario es-
tudar a adequacao de cada uma delas ao projecto em questao Desde logo e possıvel
observar que nem todas se dedicam apenas a OWA Por exemplo o Adobe AIR
apesar de ter suporte para OWA apenas disponibiliza algumas das funcionalidades
identificadas como mais indicadas para a execucao do projecto quando utilizado
na sua vertente desktop tal como exposto na Tabela 31 mas a utilizacao desta
vertente implicaria o desenvolvimento de novas interfaces e de novas formas de co-
municacao (troca de mensagens XML ou JSON) A vertente web do Adobe AIR
foca-se mais especificamente nas Rich Internet Applications e permite a reutilizacao
do codigo ja existente (exigindo naturalmente a sua adaptacao e a implementacao
das funcionalidades pretendidas)
A tecnologia escolhida para a realizacao deste trabalho foi o Gears sendo que
um dos principais factores a influenciar esta opcao foi a liberdade introduzida pela
sua licenca Berkeley Software Distribution (BSD)11
Considerou-se o funcionamento desta ferramenta extremamente adequando a
aplicacao no WOW uma vez que o seu principal objectivo e precisamente tornar
possıvel a execucao offline de uma pagina web e por virtude deste facto o Gears tem
uma API concisa e de simples aplicacao pratica uma vez que nao possui quaisquer
outros elementos distractores O funcionamento do seu ManagedResourceStore ex-
emplificado na Figura 31 com a capacidade de actualizacao de recursos definidos
num ficheiro manifesto especificado em JSON pesou tambem nesta decisao
11Sobre a licenca BSD consultar httpwwwopensourceorglicensesbsd-licensephp e http
wwwlinfoorgbsdlicensehtml
28
Estado da arte
Figura 31 Esquema UML do processo efectuado pelos recursos do Gears do tipoManagedResourceStore para a actualizacao dos conteudos definidos no ficheiro manifesto
29
Estado da arte
Funcionalidade RIAs no browser RIAs no desktop
Disponibilidadeda aplicacao
As aplicacoes podem ser facil-mente exploradas e utilizadas
As aplicacoes quando instal-adas tem maior grau de fun-cionalidades e persistencia
Instalacao Nao e necessario qualquer tipode instalacao
As aplicacoes sao instaladasatraves do browser ou descar-regadas e instaladas comouma aplicacao tradicional
Actualizacoes Aplicacoes sao actualizadascarregando conteudos paraum website
O AIR disponibiliza uma APIque permite que as aplicacoessejam actualizadas de umaforma
Sistemas opera-tivos suportados
As aplicacoes podem ser exe-cutadas em diversos sistemasoperativos e browsers
As aplicacoes sao multi-plataforma e podem serinstaladas e executadas emdiversos sistemas operativos ebrowsers
Linguagens deprogramacao
Javascript e disponibilizadopelo browser e ActionScripte disponibilizado pelo AdobeFlash Player
Maquinas virtuais deJavascript e ActionScriptcompatıveis com o browser
Capacidade deexecucao embackground
As RIAs podem ser execu-tadas numa janela do browser
As aplicacoes podem ser ex-ecutadas em background edisponibilizar notificacoes talcomo uma aplicacao tradi-cional
Persistencia A actividade esta limitada asessao do browser Quando obrowser e encerrado toda ainformacao e descartada
As aplicacoes sao instaladas eestao disponıveis no desktopPodem armazenar informacaolocalmente e estao disponıveisoffline
Integracao com odesktop
Integracao com o desktop lim-itada devido a restricoes im-postas pelo browser
As aplicacoes podem acederao sistema de ficheiro ao clip-board eventos notificacoesetc
Controlo da inter-face com o uti-lizador
As aplicacoes sao acedidasatraves de uma janela dobrowser que tem os seusproprios controlos e visualgrafico
As aplicacoes tem um vi-sual grafico proprio em janelapropria
Armazenamentode dados
As aplicacoes tem armazena-mento limitado que pode serreescrito pelo browser
As aplicacoes tem acesso a to-talidade do espaco disponıvellocalmente e a uma base dedados com a possibilidade deencriptacao
Tabela 31 Comparacao das funcionalidades oferecidas pelo Adobe AIR para as platafor-mas web e desktop
30
Estado da arte
Aplicacao Modo de execucao utilizadoGoogle Reader Utiliza o modo ldquoutilizador deciderdquo disponibilizando
ao utilizador um botao para alternar entre os modosonline e offline Como lida com informacao recol-hida de fontes externas de natureza frequentementeefemera o processo de sincronizacao apenas transfereos dois mil itens mais recentes quando passa ao es-tado offline Neste modo sao ainda guardadas in-formacoes de itens lidos e etiquetas atribuıdas quesao sincronizadas com o servidor quando o utilizadorvoltar a activar estado online
Google Docs Utiliza o modo ldquoaplicacao deciderdquo permitindo que outilizador edite os conteudos de documentos de textofolhas de calculo e de apresentacoes independente-mente do estado da ligacao desde o momento em queas funcionalidades offline sao activadas A aplicacaofaz pequenas sincronizacoes com o servidor sempre quenecessario
Remember the Milk Utiliza um modo hıbrido entre ldquoaplicacao deciderdquo eldquoutilizador deciderdquo A aplicacao encarrega-se da sin-cronizacao de dados mas disponibiliza um controlona sua interface que permite despoletar manualmenteeste processo para situacoes em que o utilizador fez al-teracoes recentes e pretende usufruir das capacidadesoffline imediatamente
MySpace O MySpace anunciou a utilizacao de mecanismos dearmazenamento de dados no cliente com recurso atecnologias OWA para melhorar o desempenho doseu cliente web de correio electronico nomeadamenteno que diz respeito a operacoes de pesquisa e or-denacao Inicialmente esta funcionalidade estara ape-nas disponıvel para utilizadores com cinco mil ou maismensagens na sua caixa de correio mas nao e aindaclaro se sera disponibilizada uma versao totalmenteoffline
Tabela 32 Resumo da utilizacao de tecnologias OWA em algumas web applications con-sideradas na analise do estado da arte
31
Estado da arte
32
Capıtulo 4
Desenvolvimento
Neste capıtulo introduz-se a aplicacao WOW e apresenta-se o estudo que foi
feito da adequacao de cada tecnologia para a implementacao da funcionalidade of-
fline nesta plataforma Fazem-se diversas consideracoes sobre opcoes a tomar na
concepcao de OWAs e problemas comuns na sua implementacao bem como sug-
estoes para os resolver O WOW e uma aplicacao ja existente de gestao de ordens
de trabalho e do fluxo de tarefas numa empresa ou organizacao
41 Como ficar offline
Na maior parte das web applications de hoje nao existe uma camada de dados
real A aplicacao exemplificada na Figura 41 ao longo da sua execucao acede
directamente a sua unica fonte de dados (o servidor) atraves de chamadas Ajax sem
que exista uma separacao clara destas duas camadas
Para que uma web application seja capaz de ser executada sem uma ligacao
activa a Internet e mantenha o seu caracter dinamico torna-se necessario incluir
Figura 41 Exemplo de uma arquitectura de uma web application sem uma camada deabstraccao de dados Figura adaptada de http gears google com
33
Desenvolvimento
Figura 42 Exemplo de uma arquitectura de uma web application com uma camada deabstraccao de dados Figura adaptada de http gears google com
um mecanismo de armazenamento de dados local seja uma base de dados ou a
capacidade de acesso ao disco No entanto este mecanismo introduz dois problemas
1 Qual das fontes de dados utilizar quando um utilizador faz um pedido de
informacao
2 A necessidade de implementar uma camada de acesso a dados que seja coerente
quer se use o servidor remoto ou local
Por exemplo em vez de a aplicacao Ajax fazer um pedido relativo as contas de
todos os utilizadores em formato JSON directamente ao servidor remoto podera ao
inves fazer o pedido a um objecto intermedio da camada de dados Este objecto
demonstrado na Figura 42 sera responsavel por implementar uma interface de
acesso a base de dados e retornar um objecto JavaScript com uma representacao da
resposta do servidor
Mas a existencia de uma segunda fonte de dados torna recomendavel tambem
a implementacao de uma camada de data switching que em funcao da existencia
de conexao a Internet e da necessidade de actualizacao dos dados decide se faz o
pedido ao servidor remoto ou se fornece os dados presentes localmente Este objecto
apresentado na Figura 43 decidira de forma transparente para o utilizador se le ou
escreve os dados localmente ou se os enviapede ao servidor remoto e pode tambem
iniciar o processo de convergencia de dados e de resolucao de conflitos
411 Funcionalidades disponıveis em modo offline
Por razoes praticas e provavel que nem todas as funcionalidades da aplicacao
possam ser disponibilizadas em modo offline E necessario escolher quais as fun-
cionalidades a disponibilizar no modo offline da aplicacao e implementar a logica
que decide quando utilizar a base de dados local ou o servidor remoto Apesar do
acesso a base de dados local ser muito mais rapido do que aceder ao servidor o
acesso local nem sempre e preferido Ha varias razoes que podem tornar necessario
escolher o acesso ao servidor em vez do acesso local
34
Desenvolvimento
Figura 43 Exemplo de uma arquitectura de uma web application com uma camada deabstraccao de dados e um data switch Figura adaptada de http gears google com
1 A informacao pode ter uma natureza efemera e nao fazer sentido guarda-la
localmente Exemplo dados em tempo real da bolsa de valores de Lisboa
2 Algumas aplicacoes lidam com informacao que so faz sentido na presenca de
uma ligacao Exemplo Instant Messaging
3 A aplicacao podera escolher apenas guardar a informacao acedida mais fre-
quentemente Exemplo para o utilizador poder alterar a lıngua de apre-
sentacao da aplicacao os conteudos terao que ser guardados em todas as
lınguas disponibilizadas pela aplicacao O custo de implementacao de algu-
mas funcionalidades pode nao compensar o benefıcio
4 A capacidade de processamento ou de armazenamento de dados pode inviabi-
lizar algumas funcionalidades offline Exemplo se uma dada funcionalidade
necessita de uma capacidade de armazenamento de dados para alem do razoavel
de um computador pessoal para ser util (visualizador de mapas)
42 Modos de execucao
Um aspecto que e necessario estudar para qualquer web application que se deseje
disponibilizar offline prende-se com tres modos de execucao que devem ser consid-
erados
1 Utilizador decide o modo de execucao A aplicacao tem modos distintos
de execucao para os estados online e offline geralmente indicados na interface
com o utilizador O utilizador e informado do estado da ligacao e participa na
alteracao de estado de execucao da aplicacao interagindo com a sua interface
2 Aplicacao decide o modo de execucao Pode ser implementado na propria
aplicacao um mecanismo de deteccao do estado da ligacao (por exemplo atraves
35
Desenvolvimento
de chamadas Ajax periodicas) transitando de estado e sincronizando automati-
camente Desta forma o utilizador nao precisa de participar na alteracao de
estado a menos que exista um conflito de dados que requeira a sua atencao
3 Aplicacao assume sempre o estado offline Outra hipotese sera imple-
mentar uma web application que assume sempre estar na ausencia de uma
ligacao ao servidor de dados Esta aplicacao responde aos pedidos do uti-
lizador efectuando pedidos de informacao ao servidor mas nao dependendo
de uma resposta valida para mostrar a informacao que ja tinha disponıvel an-
teriormente A sincronizacao de dados com o servidor e tentada sempre que
existam dados para submeter e uma accao do utilizador
421 Modo ldquoutilizador deciderdquo
Neste modo de execucao quando a aplicacao esta online comunica com o servidor
remoto quando esta offline comunica com a base de dados local A informacao tem
que ser sincronizada sempre que se muda de modo A principal vantagem desta opcao
e que e a mais simples de implementar mesmo para uma aplicacao ja existente e
portanto uma forma expedita de disponibilizar uma OWA No entanto tem tambem
algumas desvantagens que devem ser consideradas
1 O utilizador tem que se lembrar de fazer a alteracao de estado de execucao
Caso contrario podera estar a trabalhar inadvertidamente numa versao offline
com dados antigos ou nao ter a informacao necessaria se perder subitamente
a ligacao
2 Se a ligacao for intermitente o utilizador tera ou que escolher um dos modos
de execucao ou estar constantemente a trocar
3 Uma vez que a base de dados nao esta sempre actualizada nao podera ser
utilizada para melhorar a rapidez de execucao da aplicacao quando em modo
online
422 Modo aplicacao decide
A deteccao do estado da ligacao pode ser implementada atraves de um pedido
assıncrono ao servidor tal como ilustrado na Figura 44 O resultado deste pedido
definira o estado online (em caso de sucesso) ou offline (em caso de falha) A
sincronizacao de dados podera ser feita sempre que ocorra uma transicao do es-
tado offline para o estado online No entanto este metodo nao se revela eficiente
36
Desenvolvimento
Figura 44 Esquema grafico ilustrando uma OWA executando no browser utilizando ummodo de execucao do tipo ldquoaplicacao deciderdquo com deteccao automatica do estado daligacao via pedidos Ajax assıncronos a cada cinco segundos
para grandes aplicacoes uma vez que requer a troca de mensagens demasiado fre-
quentes com o servidor que se destinam exclusivamente a monitorizacao do estado
da ligacao
423 Modo ldquoaplicacao assume o estado offlinerdquo
Uma aplicacao transparente funciona assumindo sempre que esta em modo of-
fline ou pelo menos que pode perder a ligacao a qualquer momento Neste modo
tira-se o maximo partido do armazenamento local e fazem-se pequenas mas contınuas
sincronizacoes com o servidor sempre que este esteja disponıvel A sincronizacao de
dados tambem e feita sempre que se volta ao estado online
As vantagens de uma web application transparente sao as seguintes
bull Uma melhor experiencia para o utilizador uma vez que este nao tem que se
preocupar com o estado da ligacao ou com a transicao de estados
bull A aplicacao funciona de forma coerente mesmo que a ligacao seja intermitente
bull Uma vez que o armazenamento local e mantido actualizado pode ser utilizado
para melhorar o desempenho da aplicacao
Foram identificadas as seguintes desvantagens
bull E mais difıcil de implementar e a sincronizacao acarreta cuidados especiais
bull E necessario um cuidado adicional para evitar que as operacoes de sincronizacao
frequentes que ocorrem automaticamente nao afectem os tempos de resposta
da aplicacao
bull Os testes a aplicacao sao mais complexos uma vez que a sincronizacao de dados
nao ocorre em resposta a uma accao do utilizador
37
Desenvolvimento
43 Sincronizacao de dados
A sincronizacao de dados consiste na capacidade de identificar e transferir pe-
riodicamente a versao mais actual dos dados entre o cliente e o(s) servidor(es)
Independentemente do modo de execucao escolhido e mesmo do estado da ligacao
do utilizador a informacao armazenada localmente e a informacao armazenada no
servidor estarao por vezes dessincronizadas Isto podera acontecer sempre que por
exemplo
bull O utilizador faz alteracoes em modo offline
bull A informacao e partilhada e pode ser alterada por uma entidade externa
bull A informacao e fornecida por uma entidade externa
Resolver estas diferencas de forma a que a informacao local e remota encontrem
a igualdade chama-se sincronizacao de dados Ha varias aproximacoes possıveis
para este efeito que dependem da natureza da aplicacao cada uma com vantagens
e desvantagens
A capacidade de suportar a mobilidade dos utilizadores torna-se cada vez um
ponto mais importante de uma web application Para uma organizacao de dimensao
global e vital garantir que os seus colaboradores tem acesso a mesma informacao
que tem disponıvel nos seus postos de trabalho mesmo quando estao fora Na maior
parte dos casos estes colaboradores terao acesso a um computador portatil um
desktop Smartphone ou PDA e atraves destes poderao ter acesso a sua informacao
directamente atraves de ligacoes encriptadas Virtual Private Network (VPN) de um
servidor web ou de outro mecanismo de rede
Esta solucao e simples de implementar mas infelizmente para a maioria dos
colaboradores com grande factor de mobilidade nao e satisfatoria As principais
desvantagens sao as seguintes
bull Requisitos de ligacao Para permitir que os utilizadores acedam a sua in-
formacao e necessario garantir a capacidade constante de comunicacao pelo
menos durante o tempo necessario que assegure a sua transferencia
bull Velocidade de ligacao sem persistencia de dados e em ligacoes de fraca
qualidade a usabilidade por vezes torna-se inaceitavel
bull Ponto crıtico de falha Com este tipo de solucao todos os utilizadores de-
pendem da base de dados que armazena informacao vital para o funcionamento
do cliente
38
Desenvolvimento
bull Scalability do servidor A medida que novos utilizadores sao adicionados ao
sistema o desempenho do servidor e afectado levando a necessidade de maior
capacidade de armazenamento eou processamento
De acordo com a documentacao da Microsoft Sync Framework [Mic08] uma
solucao alternativa consiste em implementar uma Occasionally Connected Appli-
cation (OCA) Uma OCA permite a um utilizador remoto continuar a aceder a
sua informacao mesmo depois de perder a ligacao mas em vez de recorrer a um
servidor recorre a informacao armazenada no seu dispositivo local Para preencher
localmente a informacao que o utilizador necessita uma OCA possui mecanismos
de sincronizacao de dados que sao oferecidos por esta framework
431 Quando sincronizar
Uma das solucoes mais simples de implementar passa por disponibilizar um
mecanismo manual que despoleta a sincronizacao Diz-se manual porque e o uti-
lizador que escolhe quando sincronizar e pode ser implementada simplesmente
fazendo o upload de toda a informacao para o servidor e depois fazendo o download
da copia mais recente da informacao antes de voltar a ficar offline Para que esta
seja uma opcao viavel e necessario que
bull O volume de dados seja suficientemente pequeno para que possa ser transferido
do servidor para o cliente num espaco de tempo aceitavel
bull Que o utilizador indique explicitamente que quer mudar para o estado offline
ou online pressionando um botao da interface
Contudo podem ser identificados alguns problemas relacionados com esta abor-
dagem
bull Os utilizadores nem sempre podem prever o estado das suas ligacoes A ligacao
pode-se perder subitamente ou ter um caracter intermitente
bull O utilizador pode esquecer-se de efectuar a sincronizacao
Outra opcao sera conjugar a sincronizacao de dados com o modo de execucao
transparente A sincronizacao ocorre automaticamente em background de forma
nao intrusiva para o utilizador A aplicacao comunica com o servidor regularmente
efectuando pequenas trocas de dados com o objectivo de manter o sincronismo da
informacao local e remota Esta abordagem pode ser implementada com pedidos
Ajax assıncronos e regulares ao servidor o que permite manter a interaccao com a
interface fluıda evitando bloqueios Estes pedidos sao feitos prevendo as situacoes
39
Desenvolvimento
de disponibilidade ou indisponibilidade (timeout) do servidor Uma outra opcao
sera permitir que o servidor comunique essas alteracoes utilizando Comet1 tal como
descrito em [Wil06] e [Rus06] As vantagens destas aproximacoes sao
bull A informacao esta disponıvel a qualquer altura que o utilizador decida ficar
offline ou que a ligacao seja acidentalmente perdida
bull O desempenho da aplicacao pode ser melhorado quando se estiver a utilizar
uma ligacao a Internet lenta uma vez que o acesso a dados locais e mais
eficiente do que a consulta de dados ao servidor
44 WOW
O WOW e uma plataforma integrada de gestao de ordens de trabalho ja ex-
istente e desenvolvida pela Critical Software SA a qual se pretende adicionar a
capacidade de execucao offline Esta aplicacao e extremamente dinamica e con-
figuravel com um conjunto extremamente rico de funcionalidades das quais se
destacam
bull Gestao de Ordens de Trabalho ndash suportando a gestao dos pedidos desde a
sua criacao ate ao seu fecho tomando em conta os diferentes tipos de pedidos
(ordens de trabalho pedidos de informacao melhorias resolucao de problemas
etc) e diferentes tipos de accoes possıveis para cada um (Figura 45)
bull Monitorizacao de alteracoes ndash Historico de mudancas anexos e estados criando
relatorios de alteracao automaticamente (o que por quem e quando)
bull Uso de Service Level Agreements (SLAs) ndash E possıvel associar a um pedido um
SLA que define qual o perıodo de tempo atribuıdo a resolucao de um pedido
controlando e agilizando a resolucao do mesmo
bull Utilizacao de queries de utilizador configuraveis que permitem acesso rapido
a determinadas ordens de trabalho de acordo com o filtro configurado (por
exemplo ldquoPara mimrdquo ldquoPara o Grupordquo ldquoPelo Grupordquo)
bull Gestao do relacionamento entre pedidos
bull Pesquisa e filtragem de ordens de trabalho
bull Exportacao de dados em formatos padrao (PDF DOC ou XLS)
bull Integravel com solucoes externas
40
Desenvolvimento
Figura 45 Detalhe de um conjunto possıvel de estados e respectivas transicoes para umadada ordem de trabalho no WOW desde a sua submissao no sistema ate a sua conclusaoem fecho ou cancelamento Esta figura representa apenas um exemplo ja que o mapa deestados para uma ordem de trabalho e dinamico e pode ser alterado por um administradorFigura retirada de uma brochura promocional do WOW Critical Software SA
A utilizacao de uma ferramenta deste tipo por parte de uma empresa ou orga-
nizacao oferece vantagens quer a gestao de topo quer aos colaboradores individuais
para os colaboradores individuais o WOW e uma aplicacao onde estao registadas
todas as tarefas contribuindo activamente para o desenvolvimento em ambientes
multi-tarefa e para a organizacao pessoal das tarefas de acordo com prioridades
Para a gestao de topo esta ferramenta permite obter uma visao global do estado da
organizacao em termos de tempo gasto por tarefa executada sendo uma mais valia
para a previsao e gestaoalocacao de recursos
45 Visao geral sobre a arquitectura do WOW
O WOW e interessante nao so do ponto de vista de produto como tambem do
ponto de vista de plataforma Existem diversos plug-ins que estendem as funcional-
idades do WOW e existem ate projectos que pretendem usar a arquitectura do
WOW para criar produtos com fins diferentes do inicial (por exemplo o WOW-
Storm ndash um sistema de registo e classificacao social de ideias)
De modo a conseguir ter essa expansibilidade a plataforma WOW assenta sob
uma arquitectura distribuıda modular e expansıvel com uma componente central
ndash o core ndash estruturado em camadas logicas E no core que se situam todas as
1O Comet e um conceito semelhante ao Ajax introduzido por Alex Russel mas no qual e o servidor quetoma a iniciativa de ldquoenviarrdquo os dados ao browser sem que este tenha que efectuar um pedido Tambem econhecido por Ajax Push Reverse Ajax ou HTTP Streaming
41
Desenvolvimento
funcionalidades base da aplicacao quer a nıvel logico funcional e de apresentacao
quer a nıvel de gestao e configuracao
E possıvel a execucao de varias instancias do core simultaneamente em servidores
distintos o que permite a alta escalabilidade e disponibilidade desta aplicacao A
consistencia dos dados fica sempre garantida atraves da partilha da base de dados
e pelo balanceamento dos pedidos uma vez que cada um e encaminhado para uma
unica instancia
O WOW apresenta tambem a vantagem de ser uma plataforma extensıvel E
possıvel adicionar novas caracterısticas a plataforma atraves de componentes que se
podem ser divididos em duas categorias plugins e connectors
Os plugins sao componentes que se encontram no mesmo no fısico que a aplicacao
partilhando do mesmo contexto de execucao do core Sao assim uma forma mais
directa de obter informacao da plataforma visto que nao possuem restricoes de
acesso aos dados nem dependencias externas A arquitectura deste componente tera
assim que permitir varias execucoes instanciadas cada uma associada a um core
Por outro lado os connectors sao componentes que se encontram distribuıdos
comunicando externamente com o core Quer a sua execucao quer a obtencao
dos dados estao assim dependentes de interfaces de comunicacao externas que a
plataforma disponibiliza Estes componentes ao contrario dos plugins sao instan-
ciados unicamente e recorrem ao protocolo de comunicacao Java Messaging Service
(JMS) para comunicar com o core
46 WOW Offline
Para alem das opcoes tomadas relativamente a tecnologia a utilizar surgiu
tambem a necessidade de optar por um dos modos de execucao apresentados na
seccao 42
Das tres opcoes possıveis foi o modo ldquoaplicacao assume o estado offlinerdquo descrito
na seccao 423 que mereceu a maior atencao uma vez que reune as vantagens de
uma experiencia mais positiva para o utilizador (uma vez que este nao tem que
participar activamente na alteracao do modo execucao como descrito na seccao 421)
e nao constitui uma sobrecarga excessiva para servidor (como o modo abordado na
seccao 422)
No entanto esta opcao comprometia a complexidade da implementacao para alem
dos objectivos propostos para este projecto e para cumprir o prazo dado foi tomada
a decisao de implementar o modo ldquoutilizador deciderdquo especificando apenas de forma
teorica o modo ldquoaplicacao assume o estado offlinerdquo
As caracterısticas do Gears foram ja descritas na seccao 31 Na Figura 47
mostra-se a sua forma de funcionamento quando integrado numa web application
42
Desenvolvimento
Nesta figura representa-se o modulo LocalServer do Gears como um ponto de de-
cisao Aqui sao testadas as condicoes que determinam se o pedido sera interceptado e
servido localmente ou se prossegue para uma maquina remota E tambem represen-
tada uma base de dados que corresponde ao modulo Database mas que podera nao
ser utilizada Este modulo tal como o modulo Workerpool tem caracter opcional
e sao utilizados consoante os requisitos da aplicacao
A plataforma WOW lida com mais dados do que e necessario passar para o
lado do cliente Em conformidade com o ja exposto na seccao 411 volta-se a
frisar que nao se pretende recriar toda a logica de negocio nem os conteudos da
base de dados no cliente pela sua complexidade e volume de dados Pretende-se
pelo contrario permitir que os utilizadores tirem partido da capacidade de poder
consultar as suas ordens de trabalho quando nao dispoe de uma ligacao transferindo
apenas o essencial para isto seja possıvel
A pagina inicial do WOW apresenta um resumo das ordens de trabalho abertas
ndash enviadas e recebidas ndash que se pretende permitir visualizar offline (ver Figura 46)
Como prova de conceito foi efectuada uma abordagem pragmatica das varias possi-
bilidades descritas na seccao 42
461 Modo ldquoaplicacao deciderdquo com deteccao automatica da ligacao
A primeira abordagem estudada para a disponibilizacao das funcionalidades of-
fline foi o modo ldquoaplicacao deciderdquo com deteccao automatica de ligacao apresentado
na seccao 422 Para que isto seja possıvel foi implementado um mecanismo de ver-
ificacao periodica do estado da ligacao atraves de chamadas Ajax assıncronas O
resultado destes pedidos determina o estado da aplicacao executando as tarefas de
sincronizacao de dados sempre que pertinente Este metodo embora imediato e
simples de implementar depressa se revelou inadequado para o projecto devido ao
elevado consumo de recursos do servidor que a utilizacao intensiva faz esperar a
comunidade da plataforma WOW no principal cliente excede os 7000 utilizadores
Foi estimado que para uma utilizacao de fluidez aceitavel o estado da ligacao deveria
ser testado a cada cinco segundos Assumindo uma adesao (previsao pessimista) de
1 aos servicos offline assistir-se-ia a cerca de 840 pedidos adicionais por minuto
Mas o principal problema desta aproximacao prende-se com o facto de a ver-
ificacao ser feita em intervalos de tempo discretos levando a possibilidade de a
aplicacao poder ter em dado momento uma representacao errada do seu estado
real da ligacao Este problema e ilustrado na Figura 48 onde se ve claramente a
discrepancia entre o estado real da ligacao e a representacao interna que esta tem
Note-se que nesta janela de tempo qualquer accao do utilizador que exija uma
resposta sıncrona do utilizador leva-lo-a para um ldquobeco sem saıdardquo onde nao tera
43
Desenvolvimento
Figura 46 A pagina inicial do WOW apresenta um resumo das ultimas ordens de trabalhoenviadas e recebidas Na imagem pode-se observar a transicao do estado online para offline
acesso a versao offline porque a aplicacao nao fez a transicao automatica nem acesso
a versao online porque na verdade nao possui uma ligacao O que acontecera nesta
situacao sera uma tentativa de acesso ao servidor por parte da aplicacao numa
altura em que este se encontra indisponıvel e o resultado sera uma mensagem de
ldquopedido excedeu o tempordquo apresentado pelo browser Este e um estado sem retorno
porque apos o browser apresentar esta mensagem todos os recursos JavaScript ficam
indisponıveis tornando impossıvel o regresso ao estado anterior ou o tratamento do
erro de qualquer outra forma No entanto as chamadas Ajax podem ser tratadas de
forma especial para a eventualidade de falha e portanto nao constituem problema
44
Desenvolvimento
Figura 47 Ilustracao do funcionamento do Gears numa web application que utiliza ummotor Ajax Os pedidos HTTP ou HTTPS podem ser interceptados e tratados localmenteou podem ser feitos a uma maquina remota consoante se verificarem ou nao as condicoesexpressas no ponto 311 E representado um acesso a uma base de dados local (fornecidapelo Gears) mas a sua utilizacao e opcional
462 Implementacao do modo ldquoutilizador deciderdquo
Este modo de execucao foi ja descrito na seccao 421 e a sua principal carac-
terıstica e ser o utilizador a decidir se a aplicacao deve utilizar um servidor remoto
ou a maquina local como fornecedor de dados
Relativamente ao WOW o WOW Offline na vertente ldquoutilizador deciderdquo vem
alterar os seus casos de uso dando ao utilizador a possibilidade de alterar o estado
de execucao da aplicacao (entre online e offline) Resta dizer que no modo online se
mantem todas as funcionalidades anteriores e que no modo offline torna-se possıvel
visualizar os conteudos da pagina principal do WOW (Figura 46) e os detalhes das
ordens de trabalho (Figura 49) tal como expressa a Figura 410
Esta aproximacao foi utilizada na prova de conceito do WOW adicionando um
controlo a interface desta aplicacao que permite ao utilizador alternar entre os esta-
dos online e offline Na transicao de online para offline sao descarregados os recursos
necessarios para a execucao desta aplicacao sem recorrer a Internet Para o fazer
45
Desenvolvimento
Figura 48 Neste exemplo do modo ldquoaplicacao deciderdquo o teste da ligacao e feito e feito acada cinco segundos O resultado deste teste nao reflecte sempre o estado real da aplicacaopodendo levar a aplicacao a ter comportamentos indesejaveis Na figura assinala-se umperıodo de tempo no qual a representacao interna do estado da ligacao nao corresponde arealidade
e utilizado um recurso ResourceStore e um ManagedResourceStore (introduzidos
em 311) O primeiro e utilizado para armazenar a pagina principal do WOW ndash do-
ravante designada por homejsp ndash e o segundo e utilizado para armazenar imagens
folhas de estilo CSS e scripts JavaScript
Para a implementacao deste modo de execucao foram identificadas as seguintes
tarefas
1 Guardar informacao que permita a recriacao das paginas que se pretende
disponibilizar offline (utilizando o Gears)
2 Disponibilizar um controlo que permita alterar o estado de execucao atraves
da interaccao com a pagina principal
3 Durante a sincronizacao de dados apresentar o progresso da transferencia de
dados
O primeiro passo consistiu na identificacao de todos os conteudos que sao necessarios
transferir para a execucao offline Foi utilizado um recurso do Gears do tipo
ManagedResourceStore que recorre a um ficheiro manifesto para identificar to-
dos os ficheiros que deve transferir Este recurso e gerido automaticamente pelo
Gears transferindo para o cliente a versao mais recente sempre que e necessario
isto e sempre que exista um ficheiro manifesto com uma identificacao de versao que
seja diferente da actualmente disponıvel no cliente Uma vez identificados todos
ficheiros necessarios para a execucao offline num (ou mais) ficheiros manifesto o
Gears encarrega-se da sua actualizacao mas o preenchimento destes ficheiros man-
ifesto e manual o que se traduz num cuidado extra na manutencao da aplicacao
A forma como esta informacao e guardada deve tambem ser cuidadosamente
estudada A opcao mais flexıvel passa por utilizar o modulo Database apresentado
na seccao 311 e guardar a informacao de uma forma relacional Para a recriacao
das paginas pode ser disponibilizada uma versao HTML da pagina que funciona
46
Desenvolvimento
Figura 49 Pagina de visualizacao do detalhe de uma ordem de trabalho
como template nao possui quaisquer dados e e utilizada apenas em modo offline E
preenchida para cada pedido retirando os dados relevantes da base de dados
O modelo de dados do WOW torna esta opcao extremamente trabalhosa uma
vez que as entidades envolvidas na geracao de cada pagina de informacao sobre
cada ordem de trabalho tem relacoes de dependencia complexas seguindo padroes
muito variaveis Por exemplo em cada ordem de trabalho existe um formulario que
permite a sua progressao de estado com diversos campos opcionais e obrigatorios
este formulario e definido pelo administrador e esta relacionado nao apenas com o
tipo de ordem de trabalho mas tambem com o estado actual em que esta se encontra
e a accao que se pretende realizar O elevado numero de combinacoes de tipos de
ordem de trabalho estados e accoes que existem num dado momento juntamente
com a sua possibilidade de alteracao obrigariam a implementacao de uma logica de
negocio complexa o que esta fora do ambito deste projecto
47
Desenvolvimento
Figura 410 Esquema UML que expressa os casos de uso do WOW Offline no modoldquoutilizador deciderdquo
463 Especificacao do modo ldquoaplicacao assume o estado offlinerdquo
A aproximacao para o modo ldquoaplicacao assume o estado offlinerdquo foi tambem
dividida em varias tarefas
1 Guardar informacao que permita a recriacao da pagina principal do lado do
cliente no estado offline (utilizando o Gears)
2 Dotar a aplicacao do cliente de um mecanismo de deteccao da ligacao
3 Identificar os ldquomomentos chaverdquo em que devera ocorrer sincronizacao de dados
4 Implementar a sincronizacao de dados
A sincronizacao de dados deve ser feita em ambas as transicoes online-offline e
offline-online quer para transferir novos dados do servidor (os pedidos podem ser
alterados por outros utilizadores) quando se transita do estado quer para comunicar
eventuais alteracoes feitas em modo offline
Relativamente ao WOW o WOW Offline na vertente ldquoaplicacao assume o es-
tado offlinerdquo vem alterar os seus casos de uso dando ao utilizador a possibilidade
de activar esta funcionalidade A partir do momento que a funcionalidade esta ac-
tivada o utilizador deve tambem ter a possibilidade de gerir algumas preferencias
relacionadas com privacidade de dados Devera ter a hipotese de desactivar o ar-
mazenamento local e de remover todos os dados ja armazenados tal como descrito
na Figura 411
48
Desenvolvimento
Figura 411 Esquema UML que expressa os casos de uso do WOW Offline no modoldquoutilizador deciderdquo
A primeira vez que o WOW Offline e acedido por um cliente e caso seja detec-
tada a presenca do Gears todos os recursos necessarios a sua execucao sao trans-
feridos Todos os acessos posteriores serao feitos a estes recursos locais (recorda-se
que o Gears pode ser utilizado para os manter actualizados recorrendo ao Managed-
ResourceStore 311)
Atraves do JavaScript e possıvel interceptar os eventos de load e unload da
pagina que sao despoletados sempre que ocorre um re-acesso da mesma (incluindo
a accao refresh comum dos browsers) sempre que esta e abandonada ou ainda ou
ainda se a janela for encerrada
Tal como sugerido na seccao 462 a camada de interface desta aplicacao (cada
pagina individual em HTML) devera ser implementada como sendo um template
para apresentacao de dados sendo totalmente preenchida atraves de funcoes em
JavaScript O objectivo deste ponto e criar um padrao de dados que permita ao
JavaScript preencher os dados em cada pagina (template) independentemente de
qual seja a fonte ndash o servidor remoto ou a maquina local tal como exemplificado
no diagrama da Figura 412 Na figura a aplicacao recorre ao servidor remoto para
obter os dados pretendidos quando se encontra na presenca de uma ligacao mas
para dados que exijam uma carga de processamento pelo servidor este acto pode ser
49
Desenvolvimento
Figura 412 Esquema UML que expressa o acto de recolha de dados em modo online eoffline recorrendo ao servidor (modo online) e ao sistema de armazenamento de dadoslocal fornecido pelo Gears (modo offline)
substituıdo pelo envio de um campo de controlo que se destina a aferir se os dados
locais se encontram actualizados No caso de estarem actualizados a comunicacao
com o servidor pode ser substituıda por uma query a base de dados local
50
Capıtulo 5
Resultados e Futuros
Desenvolvimentos
Todo o estudo feito sobre o tema OWA foi ja abordado ao longo do documento
Neste capıtulo apresentam-se os resultados obtidos na implementacao da prova de
conceito que visava compreender a melhor forma de disponibilizar uma versao of-
fline no WOW uma plataforma de gestao de ordens de trabalho ja existente de-
senvolvida pela Critical Software SA
51 Resultados Obtidos
Os resultados obtidos neste projecto sao extremamente satisfatorios uma vez
que o estudo do tema OWA e a implementacao de uma prova de conceito que o
ilustrasse foi conseguido com sucesso
A funcionalidade offline foi adicionada ao produto WOW da Critical Software
SA permitindo a visualizacao de ordens de trabalho e dos seus detalhes mesmo na
ausencia de uma conexao activa a Internet Embora para a solucao implementada
tenha sido utilizada uma abordagem do tipo ldquoutilizador deciderdquo pretende-se que esta
seja convertida para ldquoaplicacao deciderdquo ou mesmo para uma aproximacao hıbrida
semelhante a utilizada pelas aplicacoes estudadas nas seccoes 351 e 352
Para a sua implementacao descrita no capıtulo 4 foram tomadas decisoes de or-
dem pratica que permitissem tornar o trabalho exequıvel nos prazos dados Tentou-
se sempre que estas decisoes afectassem o mınimo em termos de desempenho e de
experiencia para o utilizador Considera-se que a implementacao do modo offline
com uma transicao entre modos do tipo ldquoutilizador deciderdquo (ver seccao 42) reflecte
o compromisso entre o desempenho pretendido e os recursos disponıveis e para alem
51
Resultados e Futuros Desenvolvimentos
de ser um exemplo eficaz das possibilidades que as OWA podem trazer a aplicacao
WOW desenvolvida pela Critical Software e tambem um estudo que pode ser uti-
lizado para analisar a implementacao desta tecnologia noutros produtos da mesma
empresa
Note-se que o principal objectivo do trabalho era ganhar familiaridade com este
tema entender as suas vantagens e desvantagens e compreender as suas limitacoes
Tudo indica que existam varias possibilidades de implementacao deste paradigma
noutros produtos da Critical Software que pela sua natureza podem tambem tirar
partido da execucao offline
52 Trabalho Futuro
O desenvolvimento do conceito e formas de implementacao de OWA continua
em forte desenvolvimento no entanto a sua adopcao ainda nao e generalizada A
dificuldade da sua implementacao em web applications ja existentes e o principal
obstaculo a sua maior divulgacao
Ha tambem um factor que deve ser tido em consideracao a manutencao de
codigo A implementacao de uma versao offline de uma web application requer
a implementacao das mesmas regras de negocio (ou de uma versao simplificada)
utilizadas no servidor Para que isto seja possıvel e necessario ter em conta a
capacidade de processamento do cliente e o factor de duplicacao de codigo que
tornara a aplicacao mais difıcil de manter uma vez que uma alteracao a logica de
negocio do servidor implica tambem uma alteracao a sua versao offline
A prova de conceito implementada permite ja a visualizacao offline dos pedidos
abertos (enviados e recebidos) que constam na pagina principal (este numero e
fixo e pode ser alterado pelo administrador) Uma funcionalidade desejavel seria a
possibilidade de interaccao com a aplicacao em modo offline e sincronizacao com o
servidor quando existisse uma ligacao disponıvel
Foi estudada a utilizacao do modo de execucao ldquoaplicacao assume o estado of-
flinerdquo descrito em 423 e esta seria a forma desejavel para o WOW Offline no
entanto para que esta opcao seja viavel sera necessaria a implementacao de uma
forma eficiente de sincronizacao e armazenamento de dados de uma forma relacional
Para atingir este objectivo podera ser seguida uma polıtica de automacao do pro-
cesso no qual a versao online da aplicacao gera scripts de criacao para as tabelas
necessarias na base de dados da versao offline (nao existe nenhuma ferramenta para
o fazer portanto seria necessaria a sua implementacao) e no qual as paginas HTML
disponibilizadas pelo servidor aos clientes web (browser) servem como templates de
apresentacao de informacao e sao preenchidas de forma semelhante pelo servidor ndash
quando a aplicacao estiver online ndash ou pelo cliente atraves de funcoes em JavaScript
52
Resultados e Futuros Desenvolvimentos
ndash quando a aplicacao estiver offline No entanto no WOW devido a quantidade de
informacao tratada e devido as complexas relacoes entre as diferentes entidades e
de esperar que a complexidade da implementacao de um mecanismo deste tipo torne
esta aproximacao demasiado custosa
O HTML 5 embora um forte candidato ainda nao esta suficientemente desen-
volvido A sua especificacao ainda tem o caracter de Draft (rascunho) e esta sujeita
a modificacoes e a aceitacao e implementacao por parte dos browsers e portanto
de momento foi desconsiderado No entanto no futuro se esta especificacao atingir
um estado de maturidade que permita a sua adopcao devera ser considerada como
um possıvel caminho a seguir
53
Resultados e Futuros Desenvolvimentos
54
Capıtulo 6
Conclusoes
Neste capıtulo sao apresentadas as conclusoes do projecto e consideracoes finais
relativamente a tecnologia estudada
61 Conclusoes
O rapido desenvolvimento tecnologico faz prever que a disponibilidade de ligacao
a Internet seja cada vez mais facil e mais rapido mas vao continuar a existir lugares
onde o acesso e limitado e onde as OWA podem desempenhar um papel de relevo
Por outro lado esta tecnologia pode tambem ser utilizada para melhorar o desem-
penho de paginas web com uma necessidade elevada de imagens ou outros recursos
dispendiosos em termos de espaco e foram ate estudados dois exemplos da utilizacao
desta vertente desta tecnologia em 353
Acredita-se que as OWAs vem responder a uma necessidade real por parte das
web applications actuais e que a evolucao que representam se compara a que se
assistiu dos thin-clients para os fat-clients em termos de autonomia do servidor
A capacidade de oferecer conteudos dinamicos no browser independentemente da
existencia de uma ligacao reune as vantagens tıpicas das web applications como
ausencia de instalacao e actualizacoes instantaneas com as vantagens das aplicacoes
de desktop em capacidade de processamento e armazenamento de dados na maquina
local
As tecnologias disponıveis ate a data estudadas no ambito deste projecto que
permitem o desenvolvimento de OWAs e que apresentam maior maturidade sao o
Gears e o Adobe AIR Ambas se apresentam sobre a forma de plugins que necessitam
de uma instalacao extra para poderem ser utilizadas Apesar de esta instalacao ser
55
Conclusoes
apenas necessaria uma vez podera constituir um factor de desencorajamento a sua
adopcao
O HTML 5 uma especificacao abordada neste documento na seccao 34 podera
ser uma alternativa que oferece funcionalidades offline a uma web application sem a
necessidade de qualquer instalacao no entanto esta especificacao ainda nao foi aceite
pelos principais browsers ndash o documento que define o HTML 5 ainda tem o estatuto
de Draft ndash e ainda nao e possıvel antecipar quando e que isto podera acontecer
Um dos problemas que surge frequentemente na implementacao de uma versao
offline para uma web application e a necessidade de sincronizacao de dados Quando
a informacao pode ser alterada por varios utilizadores simultaneamente e necessario
prever os conflitos que daı podem surgir e dotar a aplicacao de uma forma de os
resolver ou alertar o utilizador para a necessidade de alteracao dos dados
Em conclusao todos os objectivos propostos para este projecto foram atingidos
A prova de conceito implementada reflecte de forma clara as possibilidades oferecidas
pela tecnologia OWA e sera utilizado no futuro para compreender a melhor forma
de o implementar de forma definitiva no WOW
56
Referencias
[Ada08] Lucas Adamski Introducing Adobe AIR security model Fevereiro de2008 Disponıvel em httpwwwadobecomdevnetairarticles
introduction_to_air_securityhtml acedido em Marco de 2008
[Ado08] Adobe Adobe AIR 10 Security White Paper 2008 Disponıvel emhttpdownloadmacromediacompubairdocumentation1air_
securitypdf acedido em Marco de 2008
[Alm08] Dion Almaer Gears as a bleeding-edge html 5 implementa-tion March 2008 Disponıvel em httpalmaercomblog
gears-as-a-bleeding-edge-html-5-implementation acedido emMarco de 2008
[BL96] Tim Berners-Lee The world wide web Past present and future Agostode 1996 Disponıvel em httpwwww3orgPeopleBerners-Lee
1996ppfhtml acedido em Abril de 2008
[CDGH08] Mike Chambers Daniel Dura Dragos Georgita and Kevin Hoyt AdobeAIR for JavaScript Developers OrsquoReilly Media 2008 Disponıvel emhttponairadobecomfilesAIRforJSDevPocketGuidepdf ace-dido em Abril de 2008
[Con99] Jim Conallen Modeling Web Application Architectures with UML Junho1999 Disponıvel em httpwwwumlorgcnUMLApplicationpdf
webappspdf acedido em Maio de 2008
[Ent07] Entrust What is a public key information 2007 Disponıvel em http
wwwentrustcompkihtm acedido em Junho de 2008
[Gar05] Jesse James Garret Ajax A new approach to web applicationsFebruary 2005 Disponıvel em httpwwwadaptivepathcomideas
essaysarchives000385php acedido em Marco de 2008
[Greon] Philip Greenspun Philip and Alexrsquos Guide to Web Publishing 2003(last revision) Disponıvel em httpphilipgreenspuncompandaacedido em Junho de 2008
[Gro02a] App Design Group Thick vs thin client comparison 2002 Disponıvelem httpwwwdonjacobsvwcomimagesweekendspecials
Thick-vs-Thinpdf acedido em Junho de 2008
57
REFERENCIAS
[Gro02b] Technical Research Group Thin Client Tecnhology - WhitePaper 2002 Disponıvel em httpwwwpicktrgcompubs
thinclientwhitepaperpdf acedido em Junho de 2008
[Gro08] Miniwatts Marketing Group World internet usage March 2008Disponıvel em httpwwwinternetworldstatscomstatshtm ace-dido em Abril de 2008
[Hic08] Ian Hickson HTML 5 Draft Recommendation 2008 Disponıvelem httpwwwwhatwgorgspecsweb-appscurrent-work ace-dido em Marco de 2008
[Kha] Olga Kharif Top 10 municipal wifi plans Disponıvel em http
imagesbusinessweekcomss0608muni_wifiindex_01htm ace-dido em Marco de 2008
[Lab07] Mozilla Labs Prism Outubro 2007 Disponıvel em httplabs
mozillacom200710prism acedido em Marco de 2008
[Loo06] Chris Loosley Rich Internet ApplicationsDesign MeasurementandManagement Challenges 2006 Disponıvel em httpwwwkeynote
comdocswhitepapersRichInternet_5pdf acedido em Maio de2008
[Mic08] Microsoft Introduction to Occasionally Connected Applications us-ing Sync Services for ADONET 2008 Disponıvel em httpmsdn
microsoftcomen-ussyncbb887608aspx acedido em Junho de2008
[Nao08] Erica Naone Offline web applications Abril 2008 Disponıvelem httpwwwtechnologyreviewcomread_articleaspxch=
specialsectionsampsc=emerging08ampid=20245 acedido emAbril de 2008
[NJN00] Jason Nieh Yang S Jae and Naomi Novik A comparison of thin-clientcomputing architectures 2000 Disponıvel em httpwwwnclcs
columbiaedupublicationscucs-022-00pdf acedido em Maio de2008
[OrsquoR06] Tim OrsquoReilly Web 20 compact definition Trying again Dezembro2006 Disponıvel em httpradaroreillycomarchives200612
web-20-compact-definition-tryihtml acedido em Marco de 2008
[OrsquoR09] Tim OrsquoReilly What is Web 20 Design patterns and business modelsfor the Next Generation of Software 20053009 Disponıvel emhttpwwworeillynetcompubaoreillytimnews200509
30what-is-web-20html acedido em Marco de 2008
[Rus06] Alex Russel Comet Low latency data for the browser March Marco2006 Disponıvel em httpalexdojotoolkitorgp=545 acedidoem Marco de 2008
58
REFERENCIAS
[Sad97] Darleen Sadoski Clientserver software architecturesndashan overviewAgosto 1997 Disponıvel em httpwwwseicmuedustr
descriptionsclientserver_bodyhtml acedido em Junho de2008
[Sch96] George Schussel Clientserver past present and future 1996
[Smi07] Kevin C Smith Css filters - will the browser apply the rule July 2007Disponıvel em httpcentriclecomrefcssfilters acedido emMarco de 2008
[vK08] Anne van Kesteren The XMLHttpRequest Object W3C Work-ing Draft 15 Abril 2008 Disponıvel em httpwwww3orgTR
XMLHttpRequest acedido em Abril de 2008
[Wil06] Greg Wilkins Why ajax comet July Julho 2006 Disponıvel emhttpwwwwebtidecomdownloadswhitePaperWhyAjaxhtml ace-dido em Abril de 2008
59
REFERENCIAS
60
Anexo A
Screenshots
Algumas imagens de aplicacoes que utilizam funcionalidades offline ilustrativasda tecnologia abordada neste documento
Figura A1 Dialogo apresentado ao utilizador na primeira activacao das funcionalidadesoffline no Google Docs amp Spreadsheets
61
Screenshots
Figura A2 Na activacao das funcionalidades offline e tambem oferecida a possibilidadeda criacao de alguns atalhos por exemplo no ambiente de trabalho
Figura A3 O Google Docs mantem a todo o momento a possibilidade de alteracao destasdefinicoes ou da anulacao dos servicos offline para um dado computador
62
Screenshots
Figura A4 Apos a instalacao do Gears qualquer visita ao Remember The Milk despoletauma sincronizacao que ocorre automaticamente e sem necessidade de intervencao por partedo utilizador
Figura A5 Apos completar a sincronizacao de dados mesmo que a ligacao a Internetseja perdida o Remember the Milk continua disponıvel no browser (com excepcao dasfuncionalidades que pela sua natureza exigem uma ligacao como por exemplo partilhade tarefas e envio de convites)
63
vi
Conteudo
1 Introducao 111 Enquadramento 112 Motivacao 213 Ambito 314 Objectivos 315 Estrutura do documento 3
2 Enquadramento do Projecto 521 Evolucao das arquitecturas de software 5
211 Thin-clients 5212 Fat-clients 6213 Arquitecturas cliente-servidor 7
22 Evolucao na Internet 8221 Paginas web estaticas 9222 Paginas web interactivas e paginas web dinamicas 9223 Web 20 e Ajax 11
23 Offline Web Applications 1324 Comparacao 13
3 Estado da arte 1731 Gears 17
311 Arquitectura 17312 Goggle Gears em dispositivos moveis 20
32 Adobe AIR 20321 Seguranca 22322 Assinatura do codigo 22
33 Mozilla Prism 23331 XML User Interface Language 23332 Prism 25
34 HTML 5 2535 Web applications que usam funcionalidades offline 26
351 Google Reader e Google Docs 26352 Remember the Milk 27353 MySpace e WordPresscom 27
36 Escolha da tecnologia 28
vii
CONTEUDO
4 Desenvolvimento 3341 Como ficar offline 33
411 Funcionalidades disponıveis em modo offline 3442 Modos de execucao 35
421 Modo ldquoutilizador deciderdquo 36422 Modo aplicacao decide 36423 Modo ldquoaplicacao assume o estado offlinerdquo 37
43 Sincronizacao de dados 38431 Quando sincronizar 39
44 WOW 4045 Visao geral sobre a arquitectura do WOW 4146 WOW Offline 42
461 Modo ldquoaplicacao deciderdquo com deteccao automatica da ligacao 43462 Implementacao do modo ldquoutilizador deciderdquo 45463 Especificacao do modo ldquoaplicacao assume o estado offlinerdquo 48
5 Resultados e Futuros Desenvolvimentos 5151 Resultados Obtidos 5152 Trabalho Futuro 52
6 Conclusoes 5561 Conclusoes 55
Referencias 59
A Screenshots 61
viii
Lista de Figuras
21 Arquitectura de um sistema thin-client em duas camadas (a esquerda)e em tres camadas (a direita) Note-se a inclusao do servidor (main-frame) na definicao das camadas desta arquitectura devido a fortedependencia cliente-servidor 9
22 Arquitectura de um fat-client em duas camadas (a esquerda) e emtres camadas (a direita) 10
23 Comparacao do modelo de web aplications sıncrono paginas estaticase interactivas abordados nas seccoes 221 e 222 com o modelo deweb applications Ajax (assıncrono) abordado na seccao 223 Figuraadaptada de http www adaptivepath com 15
31 Esquema UML do processo efectuado pelos recursos do Gears do tipoManagedResourceStore para a actualizacao dos conteudos definidosno ficheiro manifesto 29
41 Exemplo de uma arquitectura de uma web application sem uma ca-mada de abstraccao de dados Figura adaptada de http gears
google com 33
42 Exemplo de uma arquitectura de uma web application com uma ca-mada de abstraccao de dados Figura adaptada de http gears
google com 34
43 Exemplo de uma arquitectura de uma web application com uma ca-mada de abstraccao de dados e um data switch Figura adaptada dehttp gears google com 35
44 Esquema grafico ilustrando uma OWA executando no browser uti-lizando um modo de execucao do tipo ldquoaplicacao deciderdquo com de-teccao automatica do estado da ligacao via pedidos Ajax assıncronosa cada cinco segundos 37
45 Detalhe de um conjunto possıvel de estados e respectivas transicoespara uma dada ordem de trabalho no WOW desde a sua submissaono sistema ate a sua conclusao em fecho ou cancelamento Esta figurarepresenta apenas um exemplo ja que o mapa de estados para umaordem de trabalho e dinamico e pode ser alterado por um admin-istrador Figura retirada de uma brochura promocional do WOWCritical Software SA 41
ix
LISTA DE FIGURAS
46 A pagina inicial do WOW apresenta um resumo das ultimas ordensde trabalho enviadas e recebidas Na imagem pode-se observar atransicao do estado online para offline 44
47 Ilustracao do funcionamento do Gears numa web application que uti-liza um motor Ajax Os pedidos HTTP ou HTTPS podem ser inter-ceptados e tratados localmente ou podem ser feitos a uma maquinaremota consoante se verificarem ou nao as condicoes expressas noponto 311 E representado um acesso a uma base de dados local(fornecida pelo Gears) mas a sua utilizacao e opcional 45
48 Neste exemplo do modo ldquoaplicacao deciderdquo o teste da ligacao e feitoe feito a cada cinco segundos O resultado deste teste nao reflectesempre o estado real da aplicacao podendo levar a aplicacao a tercomportamentos indesejaveis Na figura assinala-se um perıodo detempo no qual a representacao interna do estado da ligacao nao cor-responde a realidade 46
49 Pagina de visualizacao do detalhe de uma ordem de trabalho 47410 Esquema UML que expressa os casos de uso do WOW Offline no
modo ldquoutilizador deciderdquo 48411 Esquema UML que expressa os casos de uso do WOW Offline no
modo ldquoutilizador deciderdquo 49412 Esquema UML que expressa o acto de recolha de dados em modo
online e offline recorrendo ao servidor (modo online) e ao sistemade armazenamento de dados local fornecido pelo Gears (modo offline) 50
A1 Dialogo apresentado ao utilizador na primeira activacao das funcional-idades offline no Google Docs amp Spreadsheets 61
A2 Na activacao das funcionalidades offline e tambem oferecida a possi-bilidade da criacao de alguns atalhos por exemplo no ambiente detrabalho 62
A3 O Google Docs mantem a todo o momento a possibilidade de alteracaodestas definicoes ou da anulacao dos servicos offline para um dadocomputador 62
A4 Apos a instalacao do Gears qualquer visita ao Remember The Milkdespoleta uma sincronizacao que ocorre automaticamente e sem ne-cessidade de intervencao por parte do utilizador 63
A5 Apos completar a sincronizacao de dados mesmo que a ligacao aInternet seja perdida o Remember the Milk continua disponıvel nobrowser (com excepcao das funcionalidades que pela sua naturezaexigem uma ligacao como por exemplo partilha de tarefas e enviode convites) 63
x
Lista de Tabelas
21 Comparacao entre thin-clients e fat-clients 7
31 Comparacao das funcionalidades oferecidas pelo Adobe AIR para asplataformas web e desktop 30
32 Resumo da utilizacao de tecnologias OWA em algumas web applica-tions consideradas na analise do estado da arte 31
xi
LISTA DE TABELAS
xii
Glossario
fat-client Cliente que nao depende totalmente de umservidor central para as suas actividadesde processamento e possui frequentementedispositivos de armazenamento de dados
6ndash8
thin-client Cliente que depende de um servidor centralpara as suas actividades de processamento
5ndash8
web application Sistema web (servidor rede HTTPbrowser) onde accoes do utilizador(navegacao e introducao de informacao)afectam o estado logico da aplicacao
i iii1ndash311ndash1517ndash1921ndash232728 3336ndash3842 5556
API Application Programming Interface 10 1718 2326 28
ASP Linguagem interpretada pelo servidorque permite a criacao de paginas webdinamicas Desenvolvida pela Microsoft
11
BSD Berkeley Software Distribution 28
CSS Cascading Style Sheets 12 2021 2324 46
DHTML Dynamic HyperText Transfer Protocol 24DOM Document Object Model 10 12
20 2324
DTD Document Type Definition 24
xiii
Glossario
ECMAScript Padrao de linguagem de programacaodefinido pela Ecma International que orig-inou o JavaScript e o JScript
24
Flash Conteudo interactivo de um ficheiro emformato SWF E desenvolvido pela Adobee visualizado atraves do Adobe FlashPlayer
21
Flex Framework baseada em XML e Action-Script desenvolvida pela Adobe para a pro-gramacao de Rich Internet Applications(RIA)
21
GPL GNU General Public License 23
HTML HyperText Markup Language 1 10ndash12 2124ndash2649
HTTP HyperText Transfer Protocol 2 26
JMS E uma API em Java que permite a troca demensagens entre componentes de software
42
JSON JavaScript Object Notation permite atroca de dados codificados num formatode texto de simples leitura
12 1828 34
LGPL GNU Lesser General Public License 23
Mozilla Prism Browser simplificado e ldquointerpretadorrdquo deeXtensible User Interface Language (XUL)(tambem designado por XULRunner) queacolhe web applications sem a interfacegrafica habitual de um browser
25
MPL Mozilla Public License 23
OCA Occasionally Connected Application 39OWA Offline Web Application i iii
2ndash515 1725 2628 3133 3651 5255 56
PDF Portable Document Format 21
xiv
Glossario
PHP Linguagem interpretada pelo servidorque permite a criacao de paginas webdinamicas mas que pode tambem ser in-vocada a partir da linha de comandos
11
pagina web estatica Pagina web que devolve sempre a mesmaresposta a todos os pedidos para todos osutilizadores e em qualquer contexto
5 9
RIA Rich Internet Applications web appli-cations que apresentam funcionalidadessemelhantes as desktop applications masque mantem a informacao no lado do servi-dor
5 1520 28
RSS Really Simple Syndication 27
SLA Service Level Agreement 40SQLite Segundo a definicao oficial SQLite is a
software library that implements a self-contained serverless zero-configurationtransactional SQL database engine
17
SSB Site Specific Browser 25SSL Secure Sockets Layer 22SWF ShockWave Flash 21
URL Uniform Resource Locator 18
VPN Virtual Private Network 38
WOW Work Orders Web Plataforma de gestaode ordens de trabalho e do seu fluxo de-senvolvida pela Critical Software SA
i iii28 3340ndash434551ndash5356
WWW World Wide Web 11 1214
XBL eXtensible Binding Language 24XHTML eXtensible HyperText Markup Language 12XML eXtensible Markup Language 11 12
23 2428
XSLT eXtensible Stylesheet Language Transfor-mation
12
XUL eXtensible User Interface Language xiv23ndash25
xv
Glossario
xvi
Capıtulo 1
Introducao
Neste capıtulo enquadra-se o tema do projecto introduzindo alguns dos conceitos
nos quais se baseia Apresentam-se as motivacoes ambito objectivos e a estrutura
deste documento
11 Enquadramento
A Internet foi originalmente concebida para ser um espaco de partilha de in-
formacao onde pessoas (atraves de maquinas) pudessem comunicar Na sua origem
as paginas eram estaticas constituıdas por texto formatado em HyperText Markup
Language (HTML) e ligadas entre si [BL96] Hoje encontramos conteudos cada vez
mais complexos e dinamicos incluindo som vıdeo ou streams multimedia [Loo06] e
em 2005 foi introduzido por [OrsquoR09] o termo Web 20
De acordo com [Greon] um website pode pertencer a uma ou varias das seguintes
categorias
bull Documento ndash um website essencialmente estatico onde alteracoes a uma
parte do conteudo nao tem implicacoes no seu comportamento
bull Base de dados ndash um directorio de informacao organizada em categorias
bull Aplicacao ndash um website dinamico que utiliza uma linguagem executada ou
interpretada do lado do servidor e que processa as accoes ou informacao in-
troduzida pelo utilizador para fornecer um servico ou nova informacao
A ultima destas categorias constitui aquilo que e normalmente designado por
web application O conceito utilizado ao longo deste documento e o mesmo que
o introduzido por Jim Coallen em [Con99] que define web application como um
1
Introducao
sistema web (servidor rede HyperText Transfer Protocol (HTTP) browser) onde
accoes do utilizador (navegacao e introducao de informacao) afectam o estado logico
da aplicacao A sua definicao tenta estabelecer que uma web application e um
sistema de software com estado de negocio1 e que a sua interface de interaccao com
o utilizador e distribuıdo atraves de um sistema web
12 Motivacao
A quantidade de informacao que e produzida e armazenada com recurso a es-
tas web applications disponıveis online tais como e-mail blogues ou mesmo docu-
mentacao tornam por vezes a disponibilidade de ligacao uma condicao necessaria
a produtividade e como consequencia desta barreira muitos potenciais utilizadores
opoem-se a adopcao de produtos web em detrimento das tradicionais desktop appli-
cations
Assegurar o acesso a uma ligacao de Internet e hoje muito mais facil A Internet
movel e ja uma realidade e encontra-se amplamente divulgada mas continuam a
existir diversas situacoes nas quais os utilizadores estao privados de uma ligacao
a Internet tais como uma viagem de metro ou de aviao ou quando se encontram
deslocados do seu paıs de origem e nao possuem nenhum plano de subscricao
Uma OWA consiste numa web application que para alem de manter todas as
caracterısticas anteriores se mantem disponıvel mesmo na ausencia de uma ligacao
a Internet e surge como uma tentativa de estreitar as barreiras existentes entre a
web e o desktop Isto significa que devera existir um mecanismo capaz de assegurar
a manutencao do estado logico da aplicacao quando a ligacao com o servidor e
quebrada permitindo ao utilizador continuar a utilizar a aplicacao e que sera capaz
de informar o servidor do estado em que a aplicacao se encontra quando a ligacao for
reposta A principal vantagem que advem desta possibilidade e evidente eliminar
a necessidade da existencia de uma ligacao a Internet para que a aplicacao possa ser
utilizada
Por outro lado a vontade de integracao de funcionalidades tıpicas das desktop
applications nas web applications foi um dos principais factores que impulsionou o
desenvolvimento deste conceito uma vez que obrigou a uma reflexao ldquopara alem
do browserrdquo e a uma adaptacao das arquitecturas existentes que permitisse ou o
acesso a funcionalidades disponibilizadas pelo sistema operativo ou pelo menos a
funcionalidades semelhantes Pretende-se com esta aproximacao tornar possıveis
interaccoes entre o desktop e o browser tais como arrastar um ficheiro para um
formulario web de upload de conteudos melhor suporte para o historico do clipboard
ou ainda o acesso ao sistema de ficheiros local Atingir estes objectivos reflecte-se
1NT business state
2
Introducao
num novo paradigma que reune as vantagens das web applications tais como os
updates instantaneos ou o facto de nao ser necessaria nenhuma instalacao e das
desktop applications como por exemplo persistencia no armazenamento de dados
acesso a funcionalidades do sistema operativo ou integracao e interaccao com outras
aplicacoes sejam elas web applications ou desktop applications
13 Ambito
Este projecto foi realizado na Critical Software SA no ambito do Mestrado
Integrado em Engenharia Informatica e Computacao (MIEIC) da Faculdade de En-
genharia da Universidade do Porto (FEUP) entre os meses de Fevereiro e Julho de
2008
14 Objectivos
Sao objectivos deste projecto
1 Estudar e documentar o tema das OWAs acompanhando os ultimos desenvolvi-
mentos nesta materia
2 Analisar o estado da arte fazendo uma analise crıtica e objectiva sobre as
diversas metodologias existentes
3 Implementar uma prova de conceito que permita a execucao offline de uma
web application documentando todo o processo
4 Estudar a possibilidade de permitir interaccao com a aplicacao (insercoes e
alteracoes aos dados) em modo offline
Em resumo o objectivo deste projecto foi estudar documentar e implementar
uma prova de conceito relacionada com o tema Offline Web Applications (OWA)
Este tema embora nao seja totalmente novo ganhou destaque ao longo do ano de
2007 com o surgimento de diversas ferramentas que se destinam a aproximar web
applications das desktop applications
15 Estrutura do documento
Este documento esta organizado em diferentes seccoes apresentando o projecto
numa sequencia logica organizada da seguinte forma
No capıtulo 1 faz-se uma breve apresentacao do conceito OWAs e do contexto em
que surge Apresenta-se tambem a estrutura do documento e definem-se os
termos e acronimos utilizados
3
Introducao
No capıtulo 2 faz-se uma descricao da evolucao das tecnologias que antecedem as
OWAs e das vantagens e desvantagens de cada uma como forma de enquadra-
mento
No capıtulo 3 analisa-se o estado da arte nesta materia Introduzem-se diversas
tecnologias directamente relacionadas com o tema deste projecto exemplos de
aplicacoes que as usam e as razoes que fundamentam as escolhas de tecnologias
efectuadas
O capıtulo 4 contem o desenvolvimento do projecto Analisa-se a plataforma
WOW de gestao integrada de ordens de trabalho a tecnologia escolhida e
a forma como foi utilizada para implementar a capacidade de execucao offline
O capıtulo 5 descreve os resultado obtidos comparando-os com as expectativas
iniciais do projecto e apresenta desenvolvimentos futuros e possibilidades de
continuacaoaplicacao do conhecimento adquirido
No capıtulo 6 apresentam-se as conclusoes
4
Capıtulo 2
Enquadramento do Projecto
Neste capıtulo apresenta-se um breve resumo da evolucao das arquitecturas de
software cliente-servidor e a forma como estas se comparam a evolucao da Inter-
net procurando estabelecer uma analogia entre o percurso de ambas as tecnolo-
gias Compara-se o comportamento e arquitectura dos thin-clients as paginas web
estaticas a evolucao dos fat-clients as paginas interactivas Web 20 e Ajax e
defende-se que as OWA constituem um proximo passo logico e evolutivo aproxi-
mando a web do desktop Referem-se ainda os principais factores que justificam a
importancia das OWAs e a estreita relacao que tem com as Rich Internet Application
(RIA)s
21 Evolucao das arquitecturas de software
Os termos thin-client e fat-client sao utilizados quer para descrever arquitecturas
logicas (de software) quer para descrever arquitecturas fısicas (de hardware) Neste
capıtulo excepto quando seja dada indicacao em contrario estes termos referem-se
sempre a uma arquitectura logica
Adicionalmente quando se trata de arquitecturas cliente-servidor pode-se estu-
dar a arquitectura desenvolvida do sistema como um todo da arquitectura do servi-
dor ou da arquitectura do cliente Para evitar equıvocos em especial na seccao 213
especifica-se em cada caso qual o sistema estudado
211 Thin-clients
Um thin-client e um computador cliente ou software cliente que no contexto
de uma arquitectura cliente-servidor depende de um servidor central para as suas
5
Enquadramento do Projecto
actividades de processamento e proporciona um canal de entrada e saıda de in-
formacao entre o utilizador e o servidor remoto Este termo quando aplicado a
hardware refere-se habitualmente a um computador que se destina a ser utilizado
como cliente de rede sem armazenamento local e com capacidade de processamento
reduzida [Gro02b] mas o conceito que aqui se analisa refere-se a uma arquitectura
de software que remonta ao inıcio das aplicacoes cliente-servidor
No inıcio da historia da computacao terminais ligavam-se directamente a main-
frames responsaveis por todo o processamento Nesta arquitectura era necessario
desenvolver duas aplicacoes distintas uma aplicacao central no servidor (main-
frame) responsavel pela gestao de toda a informacao e por todas as operacoes de
comunicacao e uma aplicacao de visualizacao instalada no cliente (terminal) O
papel destes terminais era apenas disponibilizar ao utilizador um meio de comu-
nicacao (entrada e saıda) e apresentacao dos resultados do servidor Nao tinham
um papel activo no calculo nem na logica de negocio e frequentemente nao tinham
tambem nenhum mecanismo de armazenamento de dados
Como vantagens esta arquitectura apresenta uma reduzida necessidade de con-
figuracao e manutencao do lado do cliente Uma vez que o centro do processamento
e manipulacao de dados ocorre no servidor existe tambem uma centralizacao da
informacao [NJN00] que introduz um ponto crıtico de falha1 Actualizacoes e novas
funcionalidades sao faceis de distribuir uma vez que requerem apenas alteracoes no
servidor [Gro02a]
212 Fat-clients
Contrastando com os thin-clients nesta arquitectura os clientes implementam
ja uma parte da logica de negocio e sao responsaveis pelo processamento de dados
Estes fat-clients vieram responder a necessidade crescente de aplicacoes com um
nıvel de interactividade e capacidade de configuracao maior que as oferecidas pela
arquitectura thin-client descrita na seccao 211 Apesar de manterem a sua de-
pendencia do servidor podem tambem ser executados sem uma conexao activa uma
vez que dispoe de armazenamento de dados local o que lhes confere a capacidade
de persistencia de dados e do estado de execucao entre cada sessao
Foi disponibilizando este controlo sobre o estado da aplicacao bem como acesso
a recursos locais (por exemplo sistema de ficheiros e perifericos) que surgiram as
primeiras verdadeiras desktop applications No entanto cada cliente tinha que ser
separadamente instalado no computador pessoal de cada utilizador que pretendesse
utilizar ou interagir com a aplicacao e uma actualizacao ao servidor implicava in-
variavelmente uma actualizacao manual tambem no cliente Uma vez que nem todos
1NT single point of failure
6
Enquadramento do Projecto
Thin-clients Fat-clientsNao toma parte no processamento dedados nem possui acesso ao sistema deficheiros
Participa activamente no processa-mento de dados recorrendo ao sis-tema de armazenamento local para ar-mazenamento de dados
Nao mantem registo do estado logicoda aplicacao entre duas sessoes de uti-lizacao
O acesso ao armazenamento localpermite-lhe manter registo do estadologico da aplicacao entre duas sessoes
O thin-client nao necessita de qualquerinstalacao estando ldquopronto a utilizarrdquo
E geralmente necessario instalar aaplicacao para poder interagir com oservidor
Qualquer update no servidor reflecte-seimediatamente por todos os clientes
Embora a aplicacao cliente possa aler-tar para existencia de novas versoes asactualizacoes tem que ser manualmenteinstalados pelo cliente
O software do cliente destina-se apenasa apresentacao de dados e comunicacaocom o servidor sendo portanto de sim-ples implementacao
Como o software do cliente toma parteactiva no processamento de dadosa sua implementacao requer cuidadosadicionais
Grande mobilidade uma vez que todaa informacao e mantida no servidor
Parte da informacao podera estar ape-nas do lado cliente pelo que existemalgumas restricoes a sua mobilidade
Tabela 21 Comparacao entre thin-clients e fat-clients
os utilizadores actualizam regularmente as suas aplicacoes o servidor tem que estar
preparado para lidar com versoes antigas2 ou descontinuar os seus servicos a uma
parte da sua comunidade de utilizadores ate que estes actualizem os seus sistemas
Como os utilizadores passam a utilizar os seus recursos locais para armazenamento
de dados as alteracoes que nao sejam sincronizadas com o servidor estao apenas
disponıveis nos seus computadores pessoais o que introduz uma restricao a mobili-
dade
Pode-se afirmar que as vantagens dos thin-clients sao as desvantagens dos fat-
clients e que as vantagens dos fat-clients sao as vantagens dos thin-clients tal como
se ilustra na Tabela 21
213 Arquitecturas cliente-servidor
Introduzidos os termos thin-client e fat-client interessa reafirmar que ambos
podem ser vistos como arquitecturas cliente-servidor Um cliente define-se como
um solicitador de servicos e um servidor como um prestador de servicos tal como
definido por [Sch96] e [Sad97]
2NT backward compatibility
7
Enquadramento do Projecto
As arquitecturas cliente-servidor sao categorizadas pela modularizacao com que
sao desenhadas sendo consideradas as seguintes camadas
1 Interface grafica (front-end) atraves da qual os utilizadores interagem com
a aplicacao Quando este modulo e implementado separadamente dos outros
dois constitui uma aplicacao thin-client por si so uma vez que nao implementa
regras de negocio (embora possa definir validacoes de formularios de insercao de
dados por exemplo) A informacao introduzida pelo utilizador e enviada para
o servidor que processa o seu pedido e retorna uma resposta Este processo
repete-se ate que o utilizador atinja o seu objectivo ou se desligue do sistema
2 A logica de negocio tambem designada por camada intermedia que imple-
menta as regras de aceitacao e validacao de todos os dados introduzidos pelo
utilizador E tambem a plataforma de comunicacao que une a camada superior
de visualizacao com a camada de acesso a dados
3 A camada de dados inclui quer o sistema de persistencia de dados onde sao
armazenados os dados relevantes como tambem os mecanismos necessarios
para a sua pesquisa seleccao e alteracao
Os thin-clients quando observados no seu conjunto de cliente e servidor podem
ser vistos quer como sistemas de duas camadas quer como sistemas de tres camadas
dependendo apenas da forma como o servidor for implementado No caso de na
implementacao do servidor nao se distinguir a camada de acesso a dados da camada
da logica de negocio sao designados por sistemas de duas camadas Caso seja feita
esta distincao sao designados por sistemas de tres camadas Ambos os casos sao
ilustrados na Figura 21
Historicamente os fat-clients eram implementados numa arquitectura em duas
camadas Possuıam apenas um modulo de visualizacao de dados designado por
camada de interface e um modulo que implementava toda a logica de negocio e
regras de acesso a base de dados No entanto com a introducao de ligacoes mais
rapidas e de computadores pessoais com maior capacidade de processamento e so-
bretudo devido a complexidade crescente das aplicacoes a logica de negocio e a
camada de acesso a dados tornaram-se independentes Este modelo e designado por
arquitectura em tres camadas e e ilustrado na Figura 22
22 Evolucao na Internet
Ao analisar a evolucao das arquitecturas das aplicacoes desenvolvidas para a
Internet podemos encontrar um paralelismo com a historia da arquitectura de soft-
ware
8
Enquadramento do Projecto
Figura 21 Arquitectura de um sistema thin-client em duas camadas (a esquerda) e emtres camadas (a direita) Note-se a inclusao do servidor (mainframe) na definicao dascamadas desta arquitectura devido a forte dependencia cliente-servidor
221 Paginas web estaticas
Uma pagina web estatica devolve sempre a mesma resposta a todos os pedidos
para todos os utilizadores e em qualquer contexto utilizando o hipertexto como
forma de ligacao entre diversas paginas estaticas
A informacao e armazenada num servidor e o papel do cliente e apenas a apre-
sentacao da informacao Esta forma de disponibilizacao de informacao pode assim
ser comparada com os thin-clients descritos na seccao 211 o utilizador acede a
um website estatico para visualizar informacao sem que o cliente tome parte no
processamento A unica diferenca e que no caso da web estatica a informacao ap-
resentada e sempre a mesma enquanto que nos thin-clients era frequente existir a
possibilidade de insercao de dados no cliente e apos o seu processamento servidor
nova informacao poderia ser apresentada O hipertexto e utilizado para ligar as
paginas entre si numa rede de conteudos relacionados e a navegacao sıncrona era
feita atraves de cliques do rato a cada clique uma nova pagina era apresentada
Este modelo sıncrono e ilustrado na Figura 23
222 Paginas web interactivas e paginas web dinamicas
O JavaScript e uma linguagem interpretada de scripting que tem os browsers
como principal ambiente de acolhimento Os browsers utilizam uma Application
9
Enquadramento do Projecto
Figura 22 Arquitectura de um fat-client em duas camadas (a esquerda) e em tres camadas(a direita)
Programming Interface (API) publica para criar ldquoobjectosrdquo responsaveis por reflectir
e disponibilizar o Document Object Model (DOM) para o motor de JavaScript
A utilizacao mais frequente desta linguagem e a escrita de funcoes que sao em-
bebidas ou incluıdas em paginas web e que interagem com o DOM Uma vez que o
JavaScript e executado localmente (na maquina do cliente e nao no servidor) e capaz
de responder rapidamente a accoes do utilizador tornando a execucao de aplicacoes
no browser mais fluıdas o JavaScript pode tambem detectar accoes do utilizador
que o HTML nao pode tal como o pressionar de uma tecla
Em Dezembro de 1995 a Netscape Communications adicionou suporte para o
JavaScript no browser Netscape Navigator3 e em Agosto de 1996 o browser Internet
Explorer4 da Microsoft passou a tambem a suportar uma versao semelhante desta
linguagem (hoje todos os principais browsers suportam esta tecnologia)
Esta inovacao permitiu tornar os websites mais interactivos mas a sua utilizacao
esteve confinada apenas a este proposito durante um longo perıodo As paginas
passaram a responder activamente a accoes do utilizador (sendo uma das utilizacoes
3Netscape Communications ndash httpbrowsernetscapecom4Microsoft Internet Explorer ndash httpwwwmicrosoftcomwindowsproductswinfamilyie
10
Enquadramento do Projecto
mais vulgares a validacao de formularios) mas continuaram essencialmente estaticas
O JavaScript ainda nao era nesta altura utilizado para processar dados
Tambem nesta altura (1995ndash96) surgiram linguagens server-side como o PHP
Hypertext Preprocessor (PHP) e Active Server Pages (ASP) e o servidor passou a ter
um processamento de dados introduzidos pelo utilizador mais activo Generalizaram-
se as paginas dinamicas capazes de responder a insercao de dados ou outros pedidos
determinados por accoes do utilizador As paginas tornaram-se aplicacoes web ap-
plications
Uma definicao tradicional de web application e um conjunto de paginas web
logicamente agrupadas e geridas por uma unica entidade que tem como pontos de
entrada formularios de insercao de dados (web forms) Uma web application nao e
mais do que uma aplicacao que e acedida atraves de um browser Tem geralmente
uma arquitectura logica em tres (interface logica de negocio e camada de dados)
camadas e estao armazenadas num servidor
Ha dois tipos de web applications
bull Orientadas a apresentacao Sao web applications que geram paginas web in-
teractivas constituıdas por varios tipos de linguagens de anotacao (por exem-
plo HTML eXtensible Markup Language (XML)) e que apresentam conteudo
dinamico como resposta a pedidos efectuados pelo utilizador
bull Orientadas aos servicos Uma web application orientada aos servicos imple-
menta o ponto de acesso para um ou mais de um web service Sao geralmente
clientes de service oriented web applications
Uma vantagem significativa de implementar uma web application de forma a
suportar as funcionalidades padrao dos browsers e que estas terao o mesmo com-
portamento independentemente da plataforma e do browser a partir do qual serao
acedidas No entanto diferentes implementacoes de browsers devido a diferentes
interpretacoes dos padroes definidos tornam por vezes esta tarefa um pouco mais
complicada existindo inclusivamente na web guioes de compatibilidade para os difer-
entes browsers como [Smi07]
223 Web 20 e Ajax
O termo web 20 descreve uma tendencia de utilizacao e de design observada
na World Wide Web (WWW) com o objectivo de melhorar a criatividade partilha
de informacao e principalmente a colaboracao entre utilizadores Estes conceitos
levaram ao desenvolvimento e evolucao de comunidades online tais como redes so-
ciais wikis e blogues
11
Enquadramento do Projecto
O termo tornou-se mais conhecido apos a primeira conferencia OrsquoReilly Media
Web 20 em 2004 e apesar de sugerir uma nova versao da WWW nao se refere a
qualquer evolucao tecnologica mas apenas a alteracoes a forma como os utilizadores
se servem da web De acordo com Tim OrsquoReilly [OrsquoR06] ldquoWeb 20 e uma revolucao
na industria do software causada pela adopcao da web como uma plataforma e pela
tentativa de entendimento das regras para o sucesso nesta nova plataformardquo
O desenvolvimento da Web 20 serve-se muitas vezes de um outro conceito Ajax
O conceito que hoje conhecemos como Ajax muitas vezes incorrectamente de-
scrito como uma tecnologia foi originalmente criado para permitir o desenvolvimento
de web applications que se assemelhassem ainda mais a aplicacoes de desktop Este
conceito foi melhor descrito por [Gar05] como um conjunto de varias tecnologias
que podem ser utilizadas para melhorar a experiencia do utilizador de uma dada
web application introduzindo a capacidade assıncrona de envio de pedidos ou da
recepcao assıncrona de respostas As tecnologias mais frequentemente envolvidas
sao
bull eXtensible HyperText Markup Language (XHTML) e Cascading Style Sheets
(CSS) padrao para a apresentacao
bull interaccao dinamica atraves do DOM
bull troca e manipulacao de dados utilizando XML e eXtensible Stylesheet Lan-
guage Transformation (XSLT) ou JavaScript Object Notation (JSON)
bull pedidos assıncronos utilizando XMLHttpRequest [vK08]
bull JavaScript utilizado para integrar todas estas tecnologias
E importante frisar que o Ajax nao e um produto nem uma tecnologia E um
termo que descreve a utilizacao de um conjunto de tecnologias para o desenvolvi-
mento de web applications com um elevado grau de interactividade Comparativa-
mente as web applications tradicionais o Ajax introduz uma camada de visualizacao
diferente em tres importantes pontos
1 Do lado do cliente existe um motor que serve de intermediario entre a interface
da aplicacao e o servidor
2 A actividade do utilizador despoleta chamadas JavaScript em vez de um pedido
de pagina directamente ao servidor
3 Informacao codificada em XML em vez de paginas HTML e trocada entre o
servidor e o cliente
12
Enquadramento do Projecto
Isto significa que as paginas que utilizam Ajax contem um motor do lado do
cliente composto por um conjunto de funcoes JavaScript responsavel pela comu-
nicacao com o servidor e por actualizar a interface com o resultado dessa mesma
comunicacao
Na Figura 23 ilustra-se a natureza assıncrona do Ajax quando comparada com
as web applications tradicionais Como se pode observar adicionando um mecan-
ismo Ajax a uma web application eliminam-se diversos tempos de espera associados
a comunicacoes com o servidor uma vez que a interface nao fica ldquobloqueadardquo a es-
pera da resposta Obtem-se assim aplicacoes com um comportamento mais fluido
eliminando tempos de espera entre cada ldquocliquerdquo e melhorando a experiencia do
utilizador
23 Offline Web Applications
A informacao grafica (bem como folhas de estilo e scripts) tais como as ima-
gens que constituem o visual de uma web application e ja tratada de forma especial
pelos cada vez mais avancados sistemas de cache (armazenamento temporario) dos
browsers Mas estes nao sao ainda capazes de guardar conteudo criado pelo uti-
lizador nem de apresentar informacao independentemente do estado da ligacao
Numa altura onde se fala de servicos de Internet wireless municipalizados [Kha]
comunicacoes 3G e ligacoes de banda larga a alta velocidade a ligacao a rede global
continua a nao estar permanentemente disponıvel para os utilizadores Na WWW
encontra-se uma importante parte da informacao e das aplicacoes utilizadas para
criar e editar conteudos Por vezes informacao vital para a produtividade pode
desaparecer subitamente do mapa de acesso de um utilizador quando este entra no
metro num aviao ou mesmo quando se desloca para uma cidade ou paıs diferente
do habitual onde nao subscreve um plano de acesso que lhe garanta a ligacao
Permitir o acesso offline a estes recursos assume assim a sua importancia porque
permitira estender o alcance da informacao a locais onde nunca esteve antes e per-
mitira tambem melhorar o desempenho das web applications colocando informacao
mais perto dos utilizadores reduzindo a transferencia de dados apenas ao essencial
24 Comparacao
Nas evolucoes descritas neste capıtulo 2 pode-se observar que existe um par-
alelismo entre a evolucao das arquitecturas tradicionais cliente-servidor e a evolucao
a que se assiste na web O comportamento e arquitectura dos thin-clients assemelha-
se ao das paginas estaticas no sentido em que o browser nao toma parte em qualquer
13
Enquadramento do Projecto
processamento e serve apenas como uma plataforma de interaccao com o servidor
tal como os clientes descritos na seccao 211
A sua proxima evolucao os fat-clients trouxeram parte da capacidade de pro-
cessamento para o lado do cliente Na web foi tambem esta a inovacao tecnologica
a que se assistiu com a evolucao das tecnologias que permitiram a criacao de ver-
dadeiras aplicacoes e com a introducao do Javascript no browser dando ao cliente
a capacidade de processamento de dados A necessidade da separacao do codigo
em camadas logicas advem da crescente complexidade das web applications Esta
pratica permite entre outras coisas melhorar o processo de desenvolvimento e a
capacidade de manutencao de uma aplicacao
Os fat-clients tem tambem a capacidade de armazenamento de dados o que
permite a persistencia de informacoes entre duas sessoes e que algumas operacoes
sejam executadas sem a necessidade de comunicacao com o servidor Este facto pode
tambem ser uma realidade nas web applications com a adopcao das tecnologias OWA
Neste momento assiste-se a uma utilizacao cada vez maior da web como uma
plataforma de desenvolvimento A capacidade de cooperacao na edicao de conteudos
e a mobilidade proporcionada por esta plataforma sao os principais factores que
alimentam esta mudanca e pela primeira vez as aplicacoes tradicionais tem com-
peticao vinda de web applications A prova do reconhecimento da web como plataforma
de desenvolvimento pode ser retirada da aposta de empresas como a Adobe e Mi-
crosoft que lancaram publicamente ferramentas web complementares a produtos
seus tradicionalmente associados ao desktop ndash Acrobatcom5 e Microsoft Office
Live6 Dotar estas web applications da capacidade de execucao offline significa
aproximar a web e o desktop reunindo ldquoo melhor de dois mundosrdquo
As vantagens da mobilidade possıvel atraves da web a cooperacao na criacao e
edicao de conteudos e a possibilidade de utilizar aplicacoes sempre actualizadas e
sem necessidade de instalacao sao algumas das principais vantagens que promovem
esta mudanca que devido as preocupacoes associadas a usabilidade e experiencia do
utilizador esta fortemente associada ao desenvolvimento de Rich Internet Applica-
tion (RIA)s
5Adobe Acrobatcom httpwwwacrobatcom6Microsoft ndash httpsmallbusinessofficelivecom
14
Enquadramento do Projecto
Figura 23 Comparacao do modelo de web aplications sıncrono paginas estaticas e in-teractivas abordados nas seccoes 221 e 222 com o modelo de web applications Ajax(assıncrono) abordado na seccao 223 Figura adaptada de http www adaptivepath
com
15
Enquadramento do Projecto
16
Capıtulo 3
Estado da arte
Apesar de o conceito das OWAs nao ser absolutamente novo as tecnologias que
o suportam sao recentes Neste capıtulo descrevem-se quatro tecnologias que foram
tidas como principais candidatas para o desenvolvimento deste projecto Descrevem-
se ainda alguns exemplos de web applications que disponibilizam actualmente fun-
cionalidades offline e o processo da escolha da tecnologia a utilizar neste projecto
31 Gears
O Gears1 e uma extensao as funcionalidades do browser introduzido pelo Google
que tem como principal objectivo tornar possıvel a visualizacao de paginas de Inter-
net mesmo sem uma conexao disponıvel Encontra-se disponıvel para as platafor-
mas Windows Macintosh e Linux e oferece uma API de Javascript que permite
a scripts aceder a um mecanismo de armazenamento local baseado numa base de
dados SQLite
311 Arquitectura
Esta ferramenta e constituıda por tres componentes principais
bull LocalServer mdash Intercepta pedidos de paginas web e serve-as localmente
bull Database mdash Uma base de dados relacional construıda sobre SQLite
bull WorkerPool mdash Permite executar operacoes de computacao de uma forma
assıncrona sem afectar a capacidade de resposta e fluidez de execucao da web
application Assemelham-se a processos
1Google Inc ndash Mais informacao em httpgearsgooglecom
17
Estado da arte
LocalServer
O modulo LocalServer e uma cache de Uniform Resource Locators (URLs)
controlada pela web application Quando nao existe uma ligacao a Internet e e
feito um pedido para um URL presente nesta cache o LocalServer intercepta-o e
responde ao pedido localmente a partir do disco rıgido do utilizador A aplicacao
pode utilizar dois tipos diferentes de armazenamento local de URLs
bull ResourceStore ndash serve para capturar URLs utilizando exclusivamente a API
de Javascript disponibilizada para o efeito Uma aplicacao podera criar e
utilizar diversos ResourceStores simultaneamente para capturar ficheiros de
dados que necessitam de ser enderecados por um URL tal como um ficheiro
PDF ou uma imagem
bull ManagedResourceStore ndash serve para capturar um conjunto de URLs que estao
relacionados e que sao declarado num ficheiro de manifesto (especificado em
JSON) e que sao automaticamente actualizados O ManagedResourceStore
permite que o conjunto de recursos necessarios para correr uma web application
seja capturado e mantido actualizado automaticamente
A principal diferenca entre estes dois tipos de armazenamento de URLs e a forma
como sao actualizados os seus conteudos Os conteudos de um ManagedResourceStore
sao actualizados sempre que a versao contida no ficheiro de manifesto for alterada
enquanto que os conteudos de um ResourceStore nunca sao actualizados automati-
camente mas apenas quando for explicitamente ordenado pela aplicacao
O LocalServer e capaz de interceptar e servir localmente pedidos de HTTP e
HTTPS sempre que se reunam as seguintes condicoes
1 O URL encontra-se armazenado num ResourceStore ou ManagedResourceStore
2 O sistema de armazenamento local encontra-se activo (enabled = true) Se
o sistema de armazenamento local tiver o atributo requiredCookie o pedido
devera conter um cookie que lhe corresponda
O LocalServer nao necessita de monitorizar o estado da ligacao para atender aos
pedidos Na verdade sempre que as condicoes previamente enunciadas se verificarem
o LocalServer interceptara os pedidos e independentemente do estado da ligacao
a Internet servi-los-a a partir do disco rıgido local Cabera a aplicacao definir qual
o modo em que pretende executar um pedido (online ou offline) definindo o valor
de verdade da propriedade enabled
18
Estado da arte
Database
O modulo Database permite guardar dados da web application assegurando a
sua persistencia Os dados sao guardados de forma relacional no disco rıgido do uti-
lizador2 de acordo com o modelo de seguranca estabelecido pelo Gears3 significando
que uma aplicacao nao pode aceder a conteudos fora do seu domınio
WorkerPool
Nos web browsers uma operacao pesada de computacao pode tornar a interface
lenta e tornar menos agradavel a experiencia do utilizador O modulo WorkerPool
permite correr operacoes em background sem bloquear a interface com o utilizador
Os scripts executados numa WorkerPool nao activam os mecanismos de seguranca
do browser que mostram a mensagem ldquoA script on this page may be busy or may
have stopped respondingrdquo
O WorkerPool comporta-se como um conjunto de processos em vez de threads
Os Workers nao partilham qualquer estado de execucao o que significa que uma
alteracao a uma variavel num Worker nao afecta em nada a execucao de outro
Worker Alem disso os Workers nao herdam automaticamente nenhum codigo dos
seus pais Cada Worker e membro de um WorkerPool e os Workers podem in-
teragir entre si enviando mensagens em formato de texto ou JSON No entanto ha
tambem algumas limitacoes os Workers nao tem acesso ao DOM e objectos como
window ou document nao se encontram acessıveis Isto e consequencia de os Workers
nao partilharem o estado de execucao Mas tem acesso a todas as funcoes built-in
do Javascript A maioria das funcionalidades do Gears pode tambem ser acedida
atraves de uma variavel global especial definida como googlegearsfactory Para
outras funcionalidades especıficas os Workers podem ldquopedirrdquo a pagina principal para
continuar a execucao atraves do envio de mensagens
Outras funcionalidades
bull HttpRequest ndash Este modulo implementa a especificacao W3C XmlHttpRe-
quest definida em [vK08] tornando-a disponıvel para os workers e para a
pagina principal
bull Timer ndash Este modulo implementa a especificacao de timers tal como descrito
por [Hic08] e torna-os disponıveis para os workers e para a pagina principal
2Consultar httpcodegooglecomapisgearsapi_databasehtmldirectories3Consultar httpcodegooglecomapisgearssecurityhtml
19
Estado da arte
bull Factory ndash Esta classe e utilizada para instanciar todos os outros objectos da
API do Gears atraves do seu metodo create Este metodo pode ser utilizado
com os seguintes parametros
ndash betadatabase
ndash betahttprequest
ndash betalocalserver
ndash betatimer
ndash betaworkerpool
312 Goggle Gears em dispositivos moveis
O Gears esta tambem disponıvel em dispositivos Windows Mobile 5 e 6
Os dispositivos moveis estao pela sua natureza frequentemente desconectados
da Internet Mesmo quando possuem uma ligacao as latencias na transferencia de
dados em redes moveis tornam as aplicacoes pouco fluıdas mas o Gears permite
ultrapassar este obstaculo
O Gears funciona exactamente da mesma forma em dispositivos moveis equipados
com o Windows Mobile 5 e 6 como num computador comum Se uma aplicacao tiver
sido implementado com suporte para o Gears entao tambem estara preparada para
ser executada num dispositivo movel mas as limitacoes dos browsers disponıveis
para dispositivos moveis tem que ser consideradas Isto significa prever as condicoes
que permitam uma boa usabilidade devido aos pequenos ecras destes dispositivos
bem como o seu suporte limitado dos padroes do DOM CSS e JavaScript
32 Adobe AIR
O Adobe AIR4 e um runtime compatıvel com diversos browsers e sistemas opera-
tivos que pretende dar aos programadores a possibilidade de combinar diversas tec-
nologias de producao de conteudos para a Internet no desenvolvimento de Rich Inter-
net Application (RIA)s O Adobe AIR mantem uma relacao com o browser mas es-
tende as suas capacidades e tecnologias permitindo o desenvolvimento de aplicacoes
tambem para o ambiente de trabalho com janelas em tudo semelhantes as do sis-
tema operativo Segundo a Adobe o objectivo e complementar o browser dando
aos utilizadores (mas essencialmente aos programadores e equipas de desenvolvi-
mento) a escolha sobre como distribuir as suas aplicacoes Para este efeito o Adobe
AIR tem uma aproximacao diferente do Gears Em vez de ldquoestenderrdquo o browser
acrescentando-lhe funcionalidades o AIR permite tambem o desenvolvimento de
4Adobe - httpwwwadobecomproductsair
20
Estado da arte
aplicacoes que se destinam a ser executadas fora do ambiente do browser mas uti-
lizando as tecnologias comuns da Internet (por exemplo HTML CSS JavaScript
Flash Flex)[CDGH08]
A utilizacao desta tecnologia permite utilizar o browser ou o proprio runtime
Adobe AIR como plataforma de execucao da aplicacao
Na Tabela 31 faz-se uma comparacao das funcionalidades disponıveis de acordo
consoante se escolha o browser ou o desktop como plataforma base para a aplicacao
Uma vez que as aplicacoes Adobe AIR na plataforma desktop tem um caracter
persistente (sao instaladas no computador do utilizador) o Adobe AIR tem um
modelo de seguranca que se assemelha com o das tradicionais aplicacoes desktop
[Ada08] Este modelo e analisado nas seccoes 321 e 322 O ambiente em que
e executado o browser e restringido a execucao de web applications que podem
ser de varias origens (incluindo de origens anonimas ou sem confianca) O Adobe
AIR proporciona acesso a capacidades como acesso a ficheiros que necessitam da
confianca do utilizador
bull HTML ndash O desenvolvimento de aplicacoes para o Adobe AIR pode ser feito
com recurso a tecnologias de HTML e Ajax comuns utilizando as linguagens
de markup existentes distribuıdas como texto e interpretadas em execucao
(runtime)
bull Flash ndash Outra alternativa sera a utilizacao da linguagem Flash Permite a
renderizacao de graficos vectoriais e audiovıdeo com suporte nativo Utiliza
ActionScript para adicionar maior interactividade com o utilizador
bull Flex ndash O Flex e uma framework open source para o desenvolvimento de RIAs
usando Flash As aplicacoes Flex sao na realidade Flash sendo a principal
diferenca o ambiente de desenvolvimento
Como resultado uma aplicacao AIR podera ser implementada
bull Baseada em Flash ou Flex (aplicacoes cujo conteudo base e em ShockWave
Flash (SWF))
bull Baseada em Flash ou Flex tambem com HTML ou Portable Document Format
(PDF) Aplicacoes cujo conteudo de base e em FlashFlex (SWF) com HTML
(HTML JavaScript CSS) ou conteudo PDF incluıdo
bull Baseada em HTML Aplicacoes cujo conteudo base e em HTML Javascript
CSS
bull Baseada em HTML utilizando tambem FlashFlex ou PDF
21
Estado da arte
Os utilizadores interagem com uma aplicacao AIR da mesma forma que interagem
com outras aplicacoes com janelas nativas do seu sistema operativo O runtime e
instalado uma vez no computador do utilizador e a partir desse momento todas as
aplicacoes AIR terao o mesmo aspecto que qualquer outra aplicacao para o desktop
321 Seguranca
Permitir que uma web application aceda ao disco de armazenamento do utilizador
pode comprometer seriamente a sua seguranca Neste sentido o Adobe AIR tem
suporte para assinaturas digitais (Secure Sockets Layer (SSL)) que podem ser com-
pradas pelas equipas de desenvolvimento que o desejem e cujos certificados serao
apresentados ao utilizador no momento da instalacao Um outro aspecto ainda
relativo a seguranca e o mecanismo de isolamento de cada ambiente (sandbox )
322 Assinatura do codigo
O runtime AIR exige que todas as aplicacoes estejam digitalmente assinadas As
assinaturas digitais de codigo sao um processo que visa garantir a integridade da
aplicacao e a identidade do seu autor no momento da instalacao As equipas de
desenvolvimento podem ldquoassinarrdquo uma aplicacao utilizando um certificado atribuıdo
por uma Entidade Certificadora (Certification Authority) ou atraves de um certifi-
cado individual (self signed certificate) Neste momento o Adobe AIR suporta como
entidades certificadoras a Verisign e a Thawte [Ado08]
O instalador apresenta o nome de quem publica a aplicacao quando o codigo tiver
sido assinado com um certificado que apresente confianca ou que esteja encadeado
com um certificado que tenha ja sido aceite no computador em que se esta a instalar
a aplicacao
As equipas de desenvolvimento podem tambem assinar as aplicacoes com um
certificado auto-atribuıdo (um certificado criado por elas proprias) mas neste caso
o instalador apresentara estas aplicacoes como sendo de uma origem nao verificada
O AIR utiliza a infraestrutura publica de chaves [Ent07] suportada pelo arquivo
local do sistema operativo Para que a origem da aplicacao seja reconhecida o
computador onde a aplicacao AIR esta a ser instalada tem que confiar directamente
no certificado que foi utilizado para assinar a aplicacao ou confiar num certificado
que esteja num encadeamento logico de certificados confiados e que se ligue desta
forma ao certificado utilizado para assinar a aplicacao
Todas as aplicacoes AIR tem caracterısticas em comum independentemente da
tecnologia utilizada para o seu desenvolvimento (HTMLFlexFlash) No ambito
de uma aplicacao AIR existem um conjunto de APIs que estao disponıveis e que
tornam possıvel o acesso ao sistema local (leitura e escrita) e a recursos de rede que
22
Estado da arte
de outra forma nunca estariam acessıveis a partir de uma web application comum
Cada aplicacao AIR possui tambem diferentes nıveis de isolamento chamados secu-
rity sandboxes dependendo do tipo de conteudo que esta a ser carregado e do seu
objectivo
bull Isolamento ao nıvel da aplicacao5 ndash E a raiz de cada aplicacao AIR Este
nıvel de isolamento permite o acesso a APIs privilegiadas e especıficas do
AIR Em contrapartida e negado o acesso a algumas APIs que poderiam ser
facilmente utilizadas de forma maliciosa contra o utilizador final Importacao
dinamica de conteudos remotos e geralmente proibido e as tecnicas e mecan-
ismos de geracao dinamica de codigo sao fortemente restringidas Apenas
conteudo carregado directamente da directoria base da aplicacao podera ser
colocado neste nıvel de isolamento
bull Isolamento nao especıfico da aplicacao6 ndash contem todo o outro conteudo
que nao tenha sido carregado directamente para o isolamento da aplicacao
Isto inclui conteudo local e remoto Este tipo de conteudo nao tem acesso
directo as APIs do AIR e rege-se pelas mesmas regras tal como se tivesse sido
carregado por um browser a partir da mesma localizacao (por exemplo HTML
carregado a partir de um domınio remoto comporta-se da mesma forma que se
fosse acedido a partir do browser)
33 Mozilla Prism
331 XML User Interface Language
O eXtensible User Interface Language (XUL) e uma linguagem de anotacao
baseada em XML desenvolvida pela Mozilla Foundation que opera em aplicacoes
Mozilla multi plataforma tal como o Firefox O motor Gecko e a unica imple-
mentacao completa desta linguagem que foi desenhada sobre padroes web comuns
como CSS JavaScript e o DOM e permite o desenvolvimento de interfaces graficas
utilizando elementos pre-definidos tais como window box page textbox radio
button entre outros Infelizmente o XUL nao possui qualquer especificacao formal
ou implementacoes de inter-operabilidade para outros motores que nao o Gecko No
entanto a sua implementacao e licenciada em codigo aberto pelas licencas GNU Gen-
eral Public License (GPL) GNU Lesser General Public License (LGPL) e Mozilla
Public License (MPL)
Enunciam-se algumas caracterısticas desta linguagem
5NT application sandbox6NT non-application sandbox
23
Estado da arte
Liguagem de anotacao poderosa baseada em componentes (widgets) O ob-
jectivo do XUL e permitir a construcao de aplicacoes multi-plataforma em
claro contraste com o Dynamic HyperText Transfer Protocol (DHTML) que se
destina ao desenvolvimento de paginas web Por esta razao o XUL esta orien-
tado a componentes tais como janelas botoes e etiquetas em vez de paginas
cabecalhos de texto e ligacoes de hipertexto Investir tempo e esforco para
atingir este mesmo resultado em aplicacoes baseadas em DHTML compromete
frequentemente a complexidade e desempenho da aplicacao
Baseado em padroes O XUL e um dialecto XML baseado no padrao W3C XML
10 As aplicacoes escritas em XUL sao tambem baseadas em especificacoes
W3C adicionais como HTML 40 CSS DOM nıvel 1 e 2 JavaScript 15
incluindo ECMA-262 Edition 3 (ECMAscript)
Portabilidade entre plataformas Tal como HTML o XUL foi desenhado para
ser independente da plataforma em que e utilizado tornando as aplicacoes
facilmente portaveis entre sistemas operativos nos quais o Mozilla e suportado
Uma vez que o XUL oferece um nıvel de abstraccao dos componentes graficos
de interface que disponibiliza implementa a premissa ldquoum codigo para todas
as plataformasrdquo A interface grafica de todos os produtos centrais Mozilla
(browser instant messenger livro de enderecos) e escrita em XUL com um
unico codigo base que suporta todas as plataformas Mozilla
Separacao entre o nıvel de apresentacao e a logica de negocio Uma das
maiores preocupacoes no desenvolvimento para a Internet e a forte ligacao
entre estas duas camadas (interface e logica) Isto constitui um problema sig-
nificativo no desenvolvimento de grandes aplicacoes especialmente quando o
desenvolvimento e feito em ambientes de equipa porque as capacidades de de-
senvolvimento destas duas partes da aplicacao estao muitas vezes espalhadas
por diferentes elementos O XUL permite uma clara distincao entre a definicao
da aplicacao cliente e da logica de implementacao (XUL eXtensible Binding
Language (XBL) e JavaScript) apresentacao (CSS e imagens) internacional-
izacao (Document Type Definitions (DTDs) e etiquetas de texto em lınguas
especıficas guardados em ficheiros properties) O esquema grafico e apre-
sentacao de uma aplicacao XUL pode ser alterado de forma independente da
sua logica ou implementacao e a aplicacao pode ainda ser traduzida (interna-
tionalization) de forma independente da sua logica implementacao ou apre-
sentacao Este grau de separacao resulta em aplicacoes que sao mais faceis de
manter pelos programadores e facilmente adaptadas por designers e tradutores
24
Estado da arte
Facil adaptacao Outro benefıcio que advem do nıvel de separacao entre logica
de negocio e apresentacao oferecido pelo XUL e a facilidade com que se pode
adaptar uma aplicacao para diferentes clientes ou grupos de utilizadores Um
programador pode utilizar a mesma aplicacao base e adapta-la consoante as
necessidades atraves de diferentes temas (skins) e ficheiros de lınguas Desta
forma uma aplicacao escrita e desenvolvida em Ingles pode ser rapidamente
traduzida para Portugues e distribuıda com outra aparencia mais apropriada
ao cliente alvo
332 Prism
O Mozilla Prism e um browser simplificado e ldquointerpretadorrdquo de XUL (tambem
designado por XULRunner) que acolhe web applications sem a interface grafica ha-
bitual de um browser Baseia-se num conceito designado por Site Specific Browser
(SSB) Um SSB e uma aplicacao com um browser embebido desenhado para exe-
cutar apenas uma web application Nao possui os menus e barras de ferramentas
habituais Um SSB tem uma integracao com o sistema operativo e com o desktop
muito mais estreita do que uma web application acedida atraves de um browser uma
vez que e executado em janela propria
O Prism resulta de uma experiencia da Mozilla e visa reduzir as diferencas entre
as desktop applications tradicionais e as web applications Um dos aspectos focados e
a experiencia do utilizador Numa apresentacao oficial e dito que ldquo[o Prism] pretende
ser uma ponte entre as diferencas que existem entre as aplicacoes tradicionais de
desktop e as web applications explorando novos modelos de usabilidade enquanto
que a linha que as separa se continua a definirrdquo [Lab07]
34 HTML 5
A especificacao HTML 5 [Hic08] que se encontra em fase de desenvolvimento
pelo grupo WHATWG pretende ser uma norma de substituicao dos padroes HTML
4 XHTML 1x e do DOM2 HTML Uma das propriedades que o distingue das tec-
nologias que pretende substituir e precisamente o suporte para OWA e armazena-
mento de dados no cliente de uma forma relacional Nao sendo propriamente uma
tecnologia ndashmas antes uma especificacao ndashe aqui mencionada por ter servido como
referencia a diversas implementacoes de funcionalidades offline e por se considerar
que venha a ter um impacto significativo nas implementacoes de diversos browsers
Dion Almaer defendeu no seu blogue que o Gears era uma implementacao do
HTML 5 No seu artigo ldquoGears as a bleeding-edge HTML 5 implementationrdquo [Alm08]
o autor diz que ambos ndasho Gears e o HTML 5 ndashpretendem dar a web caracterısticas
25
Estado da arte
semelhantes e nao encontrar motivo de ldquocompeticaordquo entre as duas mas que en-
quanto o HTML 5 e uma especificacao o Gears e uma implementacao
No entanto tambem e verdade que o HTML 5 cobre muitos outros pontos para
alem das OWA que saem completamente fora do ambito do Gears Se esta es-
pecificacao atingir um estado de maturidade que possibilite a sua adopcao pelos
principais browsers tornando nativo do browser o suporte OWA entao deixara de
fazer sentido a existencia de uma extensao como o Gears
A especificacao HTML 5 disponibiliza duas APIs relevantes para o tema das
OWA
1 Uma base de dados baseada em SQL que permite o armazenamento de dados
do lado do cliente
2 Uma ldquocacherdquo HTTP que garante a disponibilidade das aplicacoes mesmo quando
o utilizador nao possui uma ligacao a Internet
Estas caracterısticas sao as bases da tecnologia das OWA e tem correspondencia
com os pontos analisados nas seccoes 311 e 311
35 Web applications que usam funcionalidades offline
Nesta seccao apresentam-se algumas web applications que actualmente disponi-
bilizam funcionalidades offline Estas aplicacoes foram escolhidas para uma analise
mais pormenorizada por utilizarem o Gears que tal como descrito na seccao 4 foi
a tecnologia escolhida para o projecto
351 Google Reader e Google Docs
O Google Reader7 e um leitor de feeds RSS Permite gerir a subscricao de varios
sites simultaneamente que disponibilizem conteudos neste formato e foi a primeira
web application da Google com uma versao offline publicamente acessıvel (desde
Junho de 2007)
O Google Reader implementa o modo ldquoutilizador deciderdquo oferecendo na sua
interface um botao que permite alternar entre os modos online e offline
O Google Docs8 e uma web application que permite a criacao e edicao de doc-
umentos de texto folhas de calculo e apresentacoes Era ja publico desde Janeiro
de 2008 que o Google estava a desenvolver uma versao OWA desta aplicacao mas o
acesso a uma versao experimental so foi possıvel a partir de 31 de Maio de 2008
7Google Reader - httpreadergooglecom8Google Docs - httpdocsgooglecom
26
Estado da arte
A implementacao das funcionalidades offline nestas duas aplicacoes seguiu difer-
entes aproximacoes principalmente porque o Google Reader apresenta ao utilizador
informacoes que sao fornecidas por fontes externas enquanto que no Google Docs
a informacao e criada e editada pelo utilizador sobre a forma de documentos
A diferente origem da informacao implica que no Google Reader seja necessario
prever casos de excepcao tal como existirem demasiados itens que necessitam de
ser transferidos para o cliente Nao observar este ponto causa um problema grave
de usabilidade e para evitar tempos de espera demasiado longos e uma interface
com pouca capacidade de resposta as accoes do utilizador o Google Reader apenas
transfere para o cliente os dois mil itens mais recentes na transicao para o modo
offline
352 Remember the Milk
O Remember The Milk9 e uma web application desenvolvida por uma equipa
Australiana que proporciona funcionalidades de agenda gestao de tempo e de tare-
fas e foi uma das primeiras aplicacoes independentes do Google a adoptar o Gears
para acessos em modo offline Permite que os seus utilizadores facam uma gestao
de tarefas agrupando-as em listas adicionando-lhes campos de informacao adicional
ou dando-lhes informacao geografica (recorrendo ao servico Google Maps10) Entre
a sua lista de funcionalidades encontra-se ainda a possibilidade de importar e ex-
portar eventos no formato iCalendar (ics) etiquetas (tags) em tarefas publicacao
Really Simple Syndication (RSS) e partilha de categorias de tarefas de acordo com
diferentes nıveis de permissoes de acesso definidos pelo utilizador
353 MySpace e WordPresscom
O MySpace uma das maiores social networks na Internet anunciou recente-
mente que vai disponibilizar uma versao do seu cliente de e-mail que utiliza o Gears
para acelerar o seu desempenho Numa fase inicial estara disponıvel apenas para
utilizadores que tenham cinco mil ou mais mensagens na sua caixa de correio e
permitira efectuar pesquisas muito mais rapido que a sua versao online
O servico de blogs Wordpresscom anunciou tambem o inıcio da utilizacao desta
tecnologia com o fim de melhorar o desempenho A versao que utiliza esta tecnologia
descarrega e armazena no cliente um conjunto de imagens e scripts que passam a
ter preferencia sobre os seus congeneres online e que permitem acelerar o processo
de carregamento da aplicacao e visualizacao de blogs
9Remember The Milk ndash httpwwwrememberthemilkcom10Google Maps ndash httpmapsgooglecom
27
Estado da arte
O MySpace e o Wordpresscom sao dois exemplos da utilizacao da tecnologia
OWA para optimizacao de web application ja existentes Sem pretenderem disponi-
bilizar uma versao que seja totalmente offline fazem uso do Gears para armazenar no
cliente parte dos recursos frequentemente acedidos na visualizacao das suas paginas
36 Escolha da tecnologia
Apos a analise das tecnologias apresentada nas seccoes 31 a 34 foi necessario es-
tudar a adequacao de cada uma delas ao projecto em questao Desde logo e possıvel
observar que nem todas se dedicam apenas a OWA Por exemplo o Adobe AIR
apesar de ter suporte para OWA apenas disponibiliza algumas das funcionalidades
identificadas como mais indicadas para a execucao do projecto quando utilizado
na sua vertente desktop tal como exposto na Tabela 31 mas a utilizacao desta
vertente implicaria o desenvolvimento de novas interfaces e de novas formas de co-
municacao (troca de mensagens XML ou JSON) A vertente web do Adobe AIR
foca-se mais especificamente nas Rich Internet Applications e permite a reutilizacao
do codigo ja existente (exigindo naturalmente a sua adaptacao e a implementacao
das funcionalidades pretendidas)
A tecnologia escolhida para a realizacao deste trabalho foi o Gears sendo que
um dos principais factores a influenciar esta opcao foi a liberdade introduzida pela
sua licenca Berkeley Software Distribution (BSD)11
Considerou-se o funcionamento desta ferramenta extremamente adequando a
aplicacao no WOW uma vez que o seu principal objectivo e precisamente tornar
possıvel a execucao offline de uma pagina web e por virtude deste facto o Gears tem
uma API concisa e de simples aplicacao pratica uma vez que nao possui quaisquer
outros elementos distractores O funcionamento do seu ManagedResourceStore ex-
emplificado na Figura 31 com a capacidade de actualizacao de recursos definidos
num ficheiro manifesto especificado em JSON pesou tambem nesta decisao
11Sobre a licenca BSD consultar httpwwwopensourceorglicensesbsd-licensephp e http
wwwlinfoorgbsdlicensehtml
28
Estado da arte
Figura 31 Esquema UML do processo efectuado pelos recursos do Gears do tipoManagedResourceStore para a actualizacao dos conteudos definidos no ficheiro manifesto
29
Estado da arte
Funcionalidade RIAs no browser RIAs no desktop
Disponibilidadeda aplicacao
As aplicacoes podem ser facil-mente exploradas e utilizadas
As aplicacoes quando instal-adas tem maior grau de fun-cionalidades e persistencia
Instalacao Nao e necessario qualquer tipode instalacao
As aplicacoes sao instaladasatraves do browser ou descar-regadas e instaladas comouma aplicacao tradicional
Actualizacoes Aplicacoes sao actualizadascarregando conteudos paraum website
O AIR disponibiliza uma APIque permite que as aplicacoessejam actualizadas de umaforma
Sistemas opera-tivos suportados
As aplicacoes podem ser exe-cutadas em diversos sistemasoperativos e browsers
As aplicacoes sao multi-plataforma e podem serinstaladas e executadas emdiversos sistemas operativos ebrowsers
Linguagens deprogramacao
Javascript e disponibilizadopelo browser e ActionScripte disponibilizado pelo AdobeFlash Player
Maquinas virtuais deJavascript e ActionScriptcompatıveis com o browser
Capacidade deexecucao embackground
As RIAs podem ser execu-tadas numa janela do browser
As aplicacoes podem ser ex-ecutadas em background edisponibilizar notificacoes talcomo uma aplicacao tradi-cional
Persistencia A actividade esta limitada asessao do browser Quando obrowser e encerrado toda ainformacao e descartada
As aplicacoes sao instaladas eestao disponıveis no desktopPodem armazenar informacaolocalmente e estao disponıveisoffline
Integracao com odesktop
Integracao com o desktop lim-itada devido a restricoes im-postas pelo browser
As aplicacoes podem acederao sistema de ficheiro ao clip-board eventos notificacoesetc
Controlo da inter-face com o uti-lizador
As aplicacoes sao acedidasatraves de uma janela dobrowser que tem os seusproprios controlos e visualgrafico
As aplicacoes tem um vi-sual grafico proprio em janelapropria
Armazenamentode dados
As aplicacoes tem armazena-mento limitado que pode serreescrito pelo browser
As aplicacoes tem acesso a to-talidade do espaco disponıvellocalmente e a uma base dedados com a possibilidade deencriptacao
Tabela 31 Comparacao das funcionalidades oferecidas pelo Adobe AIR para as platafor-mas web e desktop
30
Estado da arte
Aplicacao Modo de execucao utilizadoGoogle Reader Utiliza o modo ldquoutilizador deciderdquo disponibilizando
ao utilizador um botao para alternar entre os modosonline e offline Como lida com informacao recol-hida de fontes externas de natureza frequentementeefemera o processo de sincronizacao apenas transfereos dois mil itens mais recentes quando passa ao es-tado offline Neste modo sao ainda guardadas in-formacoes de itens lidos e etiquetas atribuıdas quesao sincronizadas com o servidor quando o utilizadorvoltar a activar estado online
Google Docs Utiliza o modo ldquoaplicacao deciderdquo permitindo que outilizador edite os conteudos de documentos de textofolhas de calculo e de apresentacoes independente-mente do estado da ligacao desde o momento em queas funcionalidades offline sao activadas A aplicacaofaz pequenas sincronizacoes com o servidor sempre quenecessario
Remember the Milk Utiliza um modo hıbrido entre ldquoaplicacao deciderdquo eldquoutilizador deciderdquo A aplicacao encarrega-se da sin-cronizacao de dados mas disponibiliza um controlona sua interface que permite despoletar manualmenteeste processo para situacoes em que o utilizador fez al-teracoes recentes e pretende usufruir das capacidadesoffline imediatamente
MySpace O MySpace anunciou a utilizacao de mecanismos dearmazenamento de dados no cliente com recurso atecnologias OWA para melhorar o desempenho doseu cliente web de correio electronico nomeadamenteno que diz respeito a operacoes de pesquisa e or-denacao Inicialmente esta funcionalidade estara ape-nas disponıvel para utilizadores com cinco mil ou maismensagens na sua caixa de correio mas nao e aindaclaro se sera disponibilizada uma versao totalmenteoffline
Tabela 32 Resumo da utilizacao de tecnologias OWA em algumas web applications con-sideradas na analise do estado da arte
31
Estado da arte
32
Capıtulo 4
Desenvolvimento
Neste capıtulo introduz-se a aplicacao WOW e apresenta-se o estudo que foi
feito da adequacao de cada tecnologia para a implementacao da funcionalidade of-
fline nesta plataforma Fazem-se diversas consideracoes sobre opcoes a tomar na
concepcao de OWAs e problemas comuns na sua implementacao bem como sug-
estoes para os resolver O WOW e uma aplicacao ja existente de gestao de ordens
de trabalho e do fluxo de tarefas numa empresa ou organizacao
41 Como ficar offline
Na maior parte das web applications de hoje nao existe uma camada de dados
real A aplicacao exemplificada na Figura 41 ao longo da sua execucao acede
directamente a sua unica fonte de dados (o servidor) atraves de chamadas Ajax sem
que exista uma separacao clara destas duas camadas
Para que uma web application seja capaz de ser executada sem uma ligacao
activa a Internet e mantenha o seu caracter dinamico torna-se necessario incluir
Figura 41 Exemplo de uma arquitectura de uma web application sem uma camada deabstraccao de dados Figura adaptada de http gears google com
33
Desenvolvimento
Figura 42 Exemplo de uma arquitectura de uma web application com uma camada deabstraccao de dados Figura adaptada de http gears google com
um mecanismo de armazenamento de dados local seja uma base de dados ou a
capacidade de acesso ao disco No entanto este mecanismo introduz dois problemas
1 Qual das fontes de dados utilizar quando um utilizador faz um pedido de
informacao
2 A necessidade de implementar uma camada de acesso a dados que seja coerente
quer se use o servidor remoto ou local
Por exemplo em vez de a aplicacao Ajax fazer um pedido relativo as contas de
todos os utilizadores em formato JSON directamente ao servidor remoto podera ao
inves fazer o pedido a um objecto intermedio da camada de dados Este objecto
demonstrado na Figura 42 sera responsavel por implementar uma interface de
acesso a base de dados e retornar um objecto JavaScript com uma representacao da
resposta do servidor
Mas a existencia de uma segunda fonte de dados torna recomendavel tambem
a implementacao de uma camada de data switching que em funcao da existencia
de conexao a Internet e da necessidade de actualizacao dos dados decide se faz o
pedido ao servidor remoto ou se fornece os dados presentes localmente Este objecto
apresentado na Figura 43 decidira de forma transparente para o utilizador se le ou
escreve os dados localmente ou se os enviapede ao servidor remoto e pode tambem
iniciar o processo de convergencia de dados e de resolucao de conflitos
411 Funcionalidades disponıveis em modo offline
Por razoes praticas e provavel que nem todas as funcionalidades da aplicacao
possam ser disponibilizadas em modo offline E necessario escolher quais as fun-
cionalidades a disponibilizar no modo offline da aplicacao e implementar a logica
que decide quando utilizar a base de dados local ou o servidor remoto Apesar do
acesso a base de dados local ser muito mais rapido do que aceder ao servidor o
acesso local nem sempre e preferido Ha varias razoes que podem tornar necessario
escolher o acesso ao servidor em vez do acesso local
34
Desenvolvimento
Figura 43 Exemplo de uma arquitectura de uma web application com uma camada deabstraccao de dados e um data switch Figura adaptada de http gears google com
1 A informacao pode ter uma natureza efemera e nao fazer sentido guarda-la
localmente Exemplo dados em tempo real da bolsa de valores de Lisboa
2 Algumas aplicacoes lidam com informacao que so faz sentido na presenca de
uma ligacao Exemplo Instant Messaging
3 A aplicacao podera escolher apenas guardar a informacao acedida mais fre-
quentemente Exemplo para o utilizador poder alterar a lıngua de apre-
sentacao da aplicacao os conteudos terao que ser guardados em todas as
lınguas disponibilizadas pela aplicacao O custo de implementacao de algu-
mas funcionalidades pode nao compensar o benefıcio
4 A capacidade de processamento ou de armazenamento de dados pode inviabi-
lizar algumas funcionalidades offline Exemplo se uma dada funcionalidade
necessita de uma capacidade de armazenamento de dados para alem do razoavel
de um computador pessoal para ser util (visualizador de mapas)
42 Modos de execucao
Um aspecto que e necessario estudar para qualquer web application que se deseje
disponibilizar offline prende-se com tres modos de execucao que devem ser consid-
erados
1 Utilizador decide o modo de execucao A aplicacao tem modos distintos
de execucao para os estados online e offline geralmente indicados na interface
com o utilizador O utilizador e informado do estado da ligacao e participa na
alteracao de estado de execucao da aplicacao interagindo com a sua interface
2 Aplicacao decide o modo de execucao Pode ser implementado na propria
aplicacao um mecanismo de deteccao do estado da ligacao (por exemplo atraves
35
Desenvolvimento
de chamadas Ajax periodicas) transitando de estado e sincronizando automati-
camente Desta forma o utilizador nao precisa de participar na alteracao de
estado a menos que exista um conflito de dados que requeira a sua atencao
3 Aplicacao assume sempre o estado offline Outra hipotese sera imple-
mentar uma web application que assume sempre estar na ausencia de uma
ligacao ao servidor de dados Esta aplicacao responde aos pedidos do uti-
lizador efectuando pedidos de informacao ao servidor mas nao dependendo
de uma resposta valida para mostrar a informacao que ja tinha disponıvel an-
teriormente A sincronizacao de dados com o servidor e tentada sempre que
existam dados para submeter e uma accao do utilizador
421 Modo ldquoutilizador deciderdquo
Neste modo de execucao quando a aplicacao esta online comunica com o servidor
remoto quando esta offline comunica com a base de dados local A informacao tem
que ser sincronizada sempre que se muda de modo A principal vantagem desta opcao
e que e a mais simples de implementar mesmo para uma aplicacao ja existente e
portanto uma forma expedita de disponibilizar uma OWA No entanto tem tambem
algumas desvantagens que devem ser consideradas
1 O utilizador tem que se lembrar de fazer a alteracao de estado de execucao
Caso contrario podera estar a trabalhar inadvertidamente numa versao offline
com dados antigos ou nao ter a informacao necessaria se perder subitamente
a ligacao
2 Se a ligacao for intermitente o utilizador tera ou que escolher um dos modos
de execucao ou estar constantemente a trocar
3 Uma vez que a base de dados nao esta sempre actualizada nao podera ser
utilizada para melhorar a rapidez de execucao da aplicacao quando em modo
online
422 Modo aplicacao decide
A deteccao do estado da ligacao pode ser implementada atraves de um pedido
assıncrono ao servidor tal como ilustrado na Figura 44 O resultado deste pedido
definira o estado online (em caso de sucesso) ou offline (em caso de falha) A
sincronizacao de dados podera ser feita sempre que ocorra uma transicao do es-
tado offline para o estado online No entanto este metodo nao se revela eficiente
36
Desenvolvimento
Figura 44 Esquema grafico ilustrando uma OWA executando no browser utilizando ummodo de execucao do tipo ldquoaplicacao deciderdquo com deteccao automatica do estado daligacao via pedidos Ajax assıncronos a cada cinco segundos
para grandes aplicacoes uma vez que requer a troca de mensagens demasiado fre-
quentes com o servidor que se destinam exclusivamente a monitorizacao do estado
da ligacao
423 Modo ldquoaplicacao assume o estado offlinerdquo
Uma aplicacao transparente funciona assumindo sempre que esta em modo of-
fline ou pelo menos que pode perder a ligacao a qualquer momento Neste modo
tira-se o maximo partido do armazenamento local e fazem-se pequenas mas contınuas
sincronizacoes com o servidor sempre que este esteja disponıvel A sincronizacao de
dados tambem e feita sempre que se volta ao estado online
As vantagens de uma web application transparente sao as seguintes
bull Uma melhor experiencia para o utilizador uma vez que este nao tem que se
preocupar com o estado da ligacao ou com a transicao de estados
bull A aplicacao funciona de forma coerente mesmo que a ligacao seja intermitente
bull Uma vez que o armazenamento local e mantido actualizado pode ser utilizado
para melhorar o desempenho da aplicacao
Foram identificadas as seguintes desvantagens
bull E mais difıcil de implementar e a sincronizacao acarreta cuidados especiais
bull E necessario um cuidado adicional para evitar que as operacoes de sincronizacao
frequentes que ocorrem automaticamente nao afectem os tempos de resposta
da aplicacao
bull Os testes a aplicacao sao mais complexos uma vez que a sincronizacao de dados
nao ocorre em resposta a uma accao do utilizador
37
Desenvolvimento
43 Sincronizacao de dados
A sincronizacao de dados consiste na capacidade de identificar e transferir pe-
riodicamente a versao mais actual dos dados entre o cliente e o(s) servidor(es)
Independentemente do modo de execucao escolhido e mesmo do estado da ligacao
do utilizador a informacao armazenada localmente e a informacao armazenada no
servidor estarao por vezes dessincronizadas Isto podera acontecer sempre que por
exemplo
bull O utilizador faz alteracoes em modo offline
bull A informacao e partilhada e pode ser alterada por uma entidade externa
bull A informacao e fornecida por uma entidade externa
Resolver estas diferencas de forma a que a informacao local e remota encontrem
a igualdade chama-se sincronizacao de dados Ha varias aproximacoes possıveis
para este efeito que dependem da natureza da aplicacao cada uma com vantagens
e desvantagens
A capacidade de suportar a mobilidade dos utilizadores torna-se cada vez um
ponto mais importante de uma web application Para uma organizacao de dimensao
global e vital garantir que os seus colaboradores tem acesso a mesma informacao
que tem disponıvel nos seus postos de trabalho mesmo quando estao fora Na maior
parte dos casos estes colaboradores terao acesso a um computador portatil um
desktop Smartphone ou PDA e atraves destes poderao ter acesso a sua informacao
directamente atraves de ligacoes encriptadas Virtual Private Network (VPN) de um
servidor web ou de outro mecanismo de rede
Esta solucao e simples de implementar mas infelizmente para a maioria dos
colaboradores com grande factor de mobilidade nao e satisfatoria As principais
desvantagens sao as seguintes
bull Requisitos de ligacao Para permitir que os utilizadores acedam a sua in-
formacao e necessario garantir a capacidade constante de comunicacao pelo
menos durante o tempo necessario que assegure a sua transferencia
bull Velocidade de ligacao sem persistencia de dados e em ligacoes de fraca
qualidade a usabilidade por vezes torna-se inaceitavel
bull Ponto crıtico de falha Com este tipo de solucao todos os utilizadores de-
pendem da base de dados que armazena informacao vital para o funcionamento
do cliente
38
Desenvolvimento
bull Scalability do servidor A medida que novos utilizadores sao adicionados ao
sistema o desempenho do servidor e afectado levando a necessidade de maior
capacidade de armazenamento eou processamento
De acordo com a documentacao da Microsoft Sync Framework [Mic08] uma
solucao alternativa consiste em implementar uma Occasionally Connected Appli-
cation (OCA) Uma OCA permite a um utilizador remoto continuar a aceder a
sua informacao mesmo depois de perder a ligacao mas em vez de recorrer a um
servidor recorre a informacao armazenada no seu dispositivo local Para preencher
localmente a informacao que o utilizador necessita uma OCA possui mecanismos
de sincronizacao de dados que sao oferecidos por esta framework
431 Quando sincronizar
Uma das solucoes mais simples de implementar passa por disponibilizar um
mecanismo manual que despoleta a sincronizacao Diz-se manual porque e o uti-
lizador que escolhe quando sincronizar e pode ser implementada simplesmente
fazendo o upload de toda a informacao para o servidor e depois fazendo o download
da copia mais recente da informacao antes de voltar a ficar offline Para que esta
seja uma opcao viavel e necessario que
bull O volume de dados seja suficientemente pequeno para que possa ser transferido
do servidor para o cliente num espaco de tempo aceitavel
bull Que o utilizador indique explicitamente que quer mudar para o estado offline
ou online pressionando um botao da interface
Contudo podem ser identificados alguns problemas relacionados com esta abor-
dagem
bull Os utilizadores nem sempre podem prever o estado das suas ligacoes A ligacao
pode-se perder subitamente ou ter um caracter intermitente
bull O utilizador pode esquecer-se de efectuar a sincronizacao
Outra opcao sera conjugar a sincronizacao de dados com o modo de execucao
transparente A sincronizacao ocorre automaticamente em background de forma
nao intrusiva para o utilizador A aplicacao comunica com o servidor regularmente
efectuando pequenas trocas de dados com o objectivo de manter o sincronismo da
informacao local e remota Esta abordagem pode ser implementada com pedidos
Ajax assıncronos e regulares ao servidor o que permite manter a interaccao com a
interface fluıda evitando bloqueios Estes pedidos sao feitos prevendo as situacoes
39
Desenvolvimento
de disponibilidade ou indisponibilidade (timeout) do servidor Uma outra opcao
sera permitir que o servidor comunique essas alteracoes utilizando Comet1 tal como
descrito em [Wil06] e [Rus06] As vantagens destas aproximacoes sao
bull A informacao esta disponıvel a qualquer altura que o utilizador decida ficar
offline ou que a ligacao seja acidentalmente perdida
bull O desempenho da aplicacao pode ser melhorado quando se estiver a utilizar
uma ligacao a Internet lenta uma vez que o acesso a dados locais e mais
eficiente do que a consulta de dados ao servidor
44 WOW
O WOW e uma plataforma integrada de gestao de ordens de trabalho ja ex-
istente e desenvolvida pela Critical Software SA a qual se pretende adicionar a
capacidade de execucao offline Esta aplicacao e extremamente dinamica e con-
figuravel com um conjunto extremamente rico de funcionalidades das quais se
destacam
bull Gestao de Ordens de Trabalho ndash suportando a gestao dos pedidos desde a
sua criacao ate ao seu fecho tomando em conta os diferentes tipos de pedidos
(ordens de trabalho pedidos de informacao melhorias resolucao de problemas
etc) e diferentes tipos de accoes possıveis para cada um (Figura 45)
bull Monitorizacao de alteracoes ndash Historico de mudancas anexos e estados criando
relatorios de alteracao automaticamente (o que por quem e quando)
bull Uso de Service Level Agreements (SLAs) ndash E possıvel associar a um pedido um
SLA que define qual o perıodo de tempo atribuıdo a resolucao de um pedido
controlando e agilizando a resolucao do mesmo
bull Utilizacao de queries de utilizador configuraveis que permitem acesso rapido
a determinadas ordens de trabalho de acordo com o filtro configurado (por
exemplo ldquoPara mimrdquo ldquoPara o Grupordquo ldquoPelo Grupordquo)
bull Gestao do relacionamento entre pedidos
bull Pesquisa e filtragem de ordens de trabalho
bull Exportacao de dados em formatos padrao (PDF DOC ou XLS)
bull Integravel com solucoes externas
40
Desenvolvimento
Figura 45 Detalhe de um conjunto possıvel de estados e respectivas transicoes para umadada ordem de trabalho no WOW desde a sua submissao no sistema ate a sua conclusaoem fecho ou cancelamento Esta figura representa apenas um exemplo ja que o mapa deestados para uma ordem de trabalho e dinamico e pode ser alterado por um administradorFigura retirada de uma brochura promocional do WOW Critical Software SA
A utilizacao de uma ferramenta deste tipo por parte de uma empresa ou orga-
nizacao oferece vantagens quer a gestao de topo quer aos colaboradores individuais
para os colaboradores individuais o WOW e uma aplicacao onde estao registadas
todas as tarefas contribuindo activamente para o desenvolvimento em ambientes
multi-tarefa e para a organizacao pessoal das tarefas de acordo com prioridades
Para a gestao de topo esta ferramenta permite obter uma visao global do estado da
organizacao em termos de tempo gasto por tarefa executada sendo uma mais valia
para a previsao e gestaoalocacao de recursos
45 Visao geral sobre a arquitectura do WOW
O WOW e interessante nao so do ponto de vista de produto como tambem do
ponto de vista de plataforma Existem diversos plug-ins que estendem as funcional-
idades do WOW e existem ate projectos que pretendem usar a arquitectura do
WOW para criar produtos com fins diferentes do inicial (por exemplo o WOW-
Storm ndash um sistema de registo e classificacao social de ideias)
De modo a conseguir ter essa expansibilidade a plataforma WOW assenta sob
uma arquitectura distribuıda modular e expansıvel com uma componente central
ndash o core ndash estruturado em camadas logicas E no core que se situam todas as
1O Comet e um conceito semelhante ao Ajax introduzido por Alex Russel mas no qual e o servidor quetoma a iniciativa de ldquoenviarrdquo os dados ao browser sem que este tenha que efectuar um pedido Tambem econhecido por Ajax Push Reverse Ajax ou HTTP Streaming
41
Desenvolvimento
funcionalidades base da aplicacao quer a nıvel logico funcional e de apresentacao
quer a nıvel de gestao e configuracao
E possıvel a execucao de varias instancias do core simultaneamente em servidores
distintos o que permite a alta escalabilidade e disponibilidade desta aplicacao A
consistencia dos dados fica sempre garantida atraves da partilha da base de dados
e pelo balanceamento dos pedidos uma vez que cada um e encaminhado para uma
unica instancia
O WOW apresenta tambem a vantagem de ser uma plataforma extensıvel E
possıvel adicionar novas caracterısticas a plataforma atraves de componentes que se
podem ser divididos em duas categorias plugins e connectors
Os plugins sao componentes que se encontram no mesmo no fısico que a aplicacao
partilhando do mesmo contexto de execucao do core Sao assim uma forma mais
directa de obter informacao da plataforma visto que nao possuem restricoes de
acesso aos dados nem dependencias externas A arquitectura deste componente tera
assim que permitir varias execucoes instanciadas cada uma associada a um core
Por outro lado os connectors sao componentes que se encontram distribuıdos
comunicando externamente com o core Quer a sua execucao quer a obtencao
dos dados estao assim dependentes de interfaces de comunicacao externas que a
plataforma disponibiliza Estes componentes ao contrario dos plugins sao instan-
ciados unicamente e recorrem ao protocolo de comunicacao Java Messaging Service
(JMS) para comunicar com o core
46 WOW Offline
Para alem das opcoes tomadas relativamente a tecnologia a utilizar surgiu
tambem a necessidade de optar por um dos modos de execucao apresentados na
seccao 42
Das tres opcoes possıveis foi o modo ldquoaplicacao assume o estado offlinerdquo descrito
na seccao 423 que mereceu a maior atencao uma vez que reune as vantagens de
uma experiencia mais positiva para o utilizador (uma vez que este nao tem que
participar activamente na alteracao do modo execucao como descrito na seccao 421)
e nao constitui uma sobrecarga excessiva para servidor (como o modo abordado na
seccao 422)
No entanto esta opcao comprometia a complexidade da implementacao para alem
dos objectivos propostos para este projecto e para cumprir o prazo dado foi tomada
a decisao de implementar o modo ldquoutilizador deciderdquo especificando apenas de forma
teorica o modo ldquoaplicacao assume o estado offlinerdquo
As caracterısticas do Gears foram ja descritas na seccao 31 Na Figura 47
mostra-se a sua forma de funcionamento quando integrado numa web application
42
Desenvolvimento
Nesta figura representa-se o modulo LocalServer do Gears como um ponto de de-
cisao Aqui sao testadas as condicoes que determinam se o pedido sera interceptado e
servido localmente ou se prossegue para uma maquina remota E tambem represen-
tada uma base de dados que corresponde ao modulo Database mas que podera nao
ser utilizada Este modulo tal como o modulo Workerpool tem caracter opcional
e sao utilizados consoante os requisitos da aplicacao
A plataforma WOW lida com mais dados do que e necessario passar para o
lado do cliente Em conformidade com o ja exposto na seccao 411 volta-se a
frisar que nao se pretende recriar toda a logica de negocio nem os conteudos da
base de dados no cliente pela sua complexidade e volume de dados Pretende-se
pelo contrario permitir que os utilizadores tirem partido da capacidade de poder
consultar as suas ordens de trabalho quando nao dispoe de uma ligacao transferindo
apenas o essencial para isto seja possıvel
A pagina inicial do WOW apresenta um resumo das ordens de trabalho abertas
ndash enviadas e recebidas ndash que se pretende permitir visualizar offline (ver Figura 46)
Como prova de conceito foi efectuada uma abordagem pragmatica das varias possi-
bilidades descritas na seccao 42
461 Modo ldquoaplicacao deciderdquo com deteccao automatica da ligacao
A primeira abordagem estudada para a disponibilizacao das funcionalidades of-
fline foi o modo ldquoaplicacao deciderdquo com deteccao automatica de ligacao apresentado
na seccao 422 Para que isto seja possıvel foi implementado um mecanismo de ver-
ificacao periodica do estado da ligacao atraves de chamadas Ajax assıncronas O
resultado destes pedidos determina o estado da aplicacao executando as tarefas de
sincronizacao de dados sempre que pertinente Este metodo embora imediato e
simples de implementar depressa se revelou inadequado para o projecto devido ao
elevado consumo de recursos do servidor que a utilizacao intensiva faz esperar a
comunidade da plataforma WOW no principal cliente excede os 7000 utilizadores
Foi estimado que para uma utilizacao de fluidez aceitavel o estado da ligacao deveria
ser testado a cada cinco segundos Assumindo uma adesao (previsao pessimista) de
1 aos servicos offline assistir-se-ia a cerca de 840 pedidos adicionais por minuto
Mas o principal problema desta aproximacao prende-se com o facto de a ver-
ificacao ser feita em intervalos de tempo discretos levando a possibilidade de a
aplicacao poder ter em dado momento uma representacao errada do seu estado
real da ligacao Este problema e ilustrado na Figura 48 onde se ve claramente a
discrepancia entre o estado real da ligacao e a representacao interna que esta tem
Note-se que nesta janela de tempo qualquer accao do utilizador que exija uma
resposta sıncrona do utilizador leva-lo-a para um ldquobeco sem saıdardquo onde nao tera
43
Desenvolvimento
Figura 46 A pagina inicial do WOW apresenta um resumo das ultimas ordens de trabalhoenviadas e recebidas Na imagem pode-se observar a transicao do estado online para offline
acesso a versao offline porque a aplicacao nao fez a transicao automatica nem acesso
a versao online porque na verdade nao possui uma ligacao O que acontecera nesta
situacao sera uma tentativa de acesso ao servidor por parte da aplicacao numa
altura em que este se encontra indisponıvel e o resultado sera uma mensagem de
ldquopedido excedeu o tempordquo apresentado pelo browser Este e um estado sem retorno
porque apos o browser apresentar esta mensagem todos os recursos JavaScript ficam
indisponıveis tornando impossıvel o regresso ao estado anterior ou o tratamento do
erro de qualquer outra forma No entanto as chamadas Ajax podem ser tratadas de
forma especial para a eventualidade de falha e portanto nao constituem problema
44
Desenvolvimento
Figura 47 Ilustracao do funcionamento do Gears numa web application que utiliza ummotor Ajax Os pedidos HTTP ou HTTPS podem ser interceptados e tratados localmenteou podem ser feitos a uma maquina remota consoante se verificarem ou nao as condicoesexpressas no ponto 311 E representado um acesso a uma base de dados local (fornecidapelo Gears) mas a sua utilizacao e opcional
462 Implementacao do modo ldquoutilizador deciderdquo
Este modo de execucao foi ja descrito na seccao 421 e a sua principal carac-
terıstica e ser o utilizador a decidir se a aplicacao deve utilizar um servidor remoto
ou a maquina local como fornecedor de dados
Relativamente ao WOW o WOW Offline na vertente ldquoutilizador deciderdquo vem
alterar os seus casos de uso dando ao utilizador a possibilidade de alterar o estado
de execucao da aplicacao (entre online e offline) Resta dizer que no modo online se
mantem todas as funcionalidades anteriores e que no modo offline torna-se possıvel
visualizar os conteudos da pagina principal do WOW (Figura 46) e os detalhes das
ordens de trabalho (Figura 49) tal como expressa a Figura 410
Esta aproximacao foi utilizada na prova de conceito do WOW adicionando um
controlo a interface desta aplicacao que permite ao utilizador alternar entre os esta-
dos online e offline Na transicao de online para offline sao descarregados os recursos
necessarios para a execucao desta aplicacao sem recorrer a Internet Para o fazer
45
Desenvolvimento
Figura 48 Neste exemplo do modo ldquoaplicacao deciderdquo o teste da ligacao e feito e feito acada cinco segundos O resultado deste teste nao reflecte sempre o estado real da aplicacaopodendo levar a aplicacao a ter comportamentos indesejaveis Na figura assinala-se umperıodo de tempo no qual a representacao interna do estado da ligacao nao corresponde arealidade
e utilizado um recurso ResourceStore e um ManagedResourceStore (introduzidos
em 311) O primeiro e utilizado para armazenar a pagina principal do WOW ndash do-
ravante designada por homejsp ndash e o segundo e utilizado para armazenar imagens
folhas de estilo CSS e scripts JavaScript
Para a implementacao deste modo de execucao foram identificadas as seguintes
tarefas
1 Guardar informacao que permita a recriacao das paginas que se pretende
disponibilizar offline (utilizando o Gears)
2 Disponibilizar um controlo que permita alterar o estado de execucao atraves
da interaccao com a pagina principal
3 Durante a sincronizacao de dados apresentar o progresso da transferencia de
dados
O primeiro passo consistiu na identificacao de todos os conteudos que sao necessarios
transferir para a execucao offline Foi utilizado um recurso do Gears do tipo
ManagedResourceStore que recorre a um ficheiro manifesto para identificar to-
dos os ficheiros que deve transferir Este recurso e gerido automaticamente pelo
Gears transferindo para o cliente a versao mais recente sempre que e necessario
isto e sempre que exista um ficheiro manifesto com uma identificacao de versao que
seja diferente da actualmente disponıvel no cliente Uma vez identificados todos
ficheiros necessarios para a execucao offline num (ou mais) ficheiros manifesto o
Gears encarrega-se da sua actualizacao mas o preenchimento destes ficheiros man-
ifesto e manual o que se traduz num cuidado extra na manutencao da aplicacao
A forma como esta informacao e guardada deve tambem ser cuidadosamente
estudada A opcao mais flexıvel passa por utilizar o modulo Database apresentado
na seccao 311 e guardar a informacao de uma forma relacional Para a recriacao
das paginas pode ser disponibilizada uma versao HTML da pagina que funciona
46
Desenvolvimento
Figura 49 Pagina de visualizacao do detalhe de uma ordem de trabalho
como template nao possui quaisquer dados e e utilizada apenas em modo offline E
preenchida para cada pedido retirando os dados relevantes da base de dados
O modelo de dados do WOW torna esta opcao extremamente trabalhosa uma
vez que as entidades envolvidas na geracao de cada pagina de informacao sobre
cada ordem de trabalho tem relacoes de dependencia complexas seguindo padroes
muito variaveis Por exemplo em cada ordem de trabalho existe um formulario que
permite a sua progressao de estado com diversos campos opcionais e obrigatorios
este formulario e definido pelo administrador e esta relacionado nao apenas com o
tipo de ordem de trabalho mas tambem com o estado actual em que esta se encontra
e a accao que se pretende realizar O elevado numero de combinacoes de tipos de
ordem de trabalho estados e accoes que existem num dado momento juntamente
com a sua possibilidade de alteracao obrigariam a implementacao de uma logica de
negocio complexa o que esta fora do ambito deste projecto
47
Desenvolvimento
Figura 410 Esquema UML que expressa os casos de uso do WOW Offline no modoldquoutilizador deciderdquo
463 Especificacao do modo ldquoaplicacao assume o estado offlinerdquo
A aproximacao para o modo ldquoaplicacao assume o estado offlinerdquo foi tambem
dividida em varias tarefas
1 Guardar informacao que permita a recriacao da pagina principal do lado do
cliente no estado offline (utilizando o Gears)
2 Dotar a aplicacao do cliente de um mecanismo de deteccao da ligacao
3 Identificar os ldquomomentos chaverdquo em que devera ocorrer sincronizacao de dados
4 Implementar a sincronizacao de dados
A sincronizacao de dados deve ser feita em ambas as transicoes online-offline e
offline-online quer para transferir novos dados do servidor (os pedidos podem ser
alterados por outros utilizadores) quando se transita do estado quer para comunicar
eventuais alteracoes feitas em modo offline
Relativamente ao WOW o WOW Offline na vertente ldquoaplicacao assume o es-
tado offlinerdquo vem alterar os seus casos de uso dando ao utilizador a possibilidade
de activar esta funcionalidade A partir do momento que a funcionalidade esta ac-
tivada o utilizador deve tambem ter a possibilidade de gerir algumas preferencias
relacionadas com privacidade de dados Devera ter a hipotese de desactivar o ar-
mazenamento local e de remover todos os dados ja armazenados tal como descrito
na Figura 411
48
Desenvolvimento
Figura 411 Esquema UML que expressa os casos de uso do WOW Offline no modoldquoutilizador deciderdquo
A primeira vez que o WOW Offline e acedido por um cliente e caso seja detec-
tada a presenca do Gears todos os recursos necessarios a sua execucao sao trans-
feridos Todos os acessos posteriores serao feitos a estes recursos locais (recorda-se
que o Gears pode ser utilizado para os manter actualizados recorrendo ao Managed-
ResourceStore 311)
Atraves do JavaScript e possıvel interceptar os eventos de load e unload da
pagina que sao despoletados sempre que ocorre um re-acesso da mesma (incluindo
a accao refresh comum dos browsers) sempre que esta e abandonada ou ainda ou
ainda se a janela for encerrada
Tal como sugerido na seccao 462 a camada de interface desta aplicacao (cada
pagina individual em HTML) devera ser implementada como sendo um template
para apresentacao de dados sendo totalmente preenchida atraves de funcoes em
JavaScript O objectivo deste ponto e criar um padrao de dados que permita ao
JavaScript preencher os dados em cada pagina (template) independentemente de
qual seja a fonte ndash o servidor remoto ou a maquina local tal como exemplificado
no diagrama da Figura 412 Na figura a aplicacao recorre ao servidor remoto para
obter os dados pretendidos quando se encontra na presenca de uma ligacao mas
para dados que exijam uma carga de processamento pelo servidor este acto pode ser
49
Desenvolvimento
Figura 412 Esquema UML que expressa o acto de recolha de dados em modo online eoffline recorrendo ao servidor (modo online) e ao sistema de armazenamento de dadoslocal fornecido pelo Gears (modo offline)
substituıdo pelo envio de um campo de controlo que se destina a aferir se os dados
locais se encontram actualizados No caso de estarem actualizados a comunicacao
com o servidor pode ser substituıda por uma query a base de dados local
50
Capıtulo 5
Resultados e Futuros
Desenvolvimentos
Todo o estudo feito sobre o tema OWA foi ja abordado ao longo do documento
Neste capıtulo apresentam-se os resultados obtidos na implementacao da prova de
conceito que visava compreender a melhor forma de disponibilizar uma versao of-
fline no WOW uma plataforma de gestao de ordens de trabalho ja existente de-
senvolvida pela Critical Software SA
51 Resultados Obtidos
Os resultados obtidos neste projecto sao extremamente satisfatorios uma vez
que o estudo do tema OWA e a implementacao de uma prova de conceito que o
ilustrasse foi conseguido com sucesso
A funcionalidade offline foi adicionada ao produto WOW da Critical Software
SA permitindo a visualizacao de ordens de trabalho e dos seus detalhes mesmo na
ausencia de uma conexao activa a Internet Embora para a solucao implementada
tenha sido utilizada uma abordagem do tipo ldquoutilizador deciderdquo pretende-se que esta
seja convertida para ldquoaplicacao deciderdquo ou mesmo para uma aproximacao hıbrida
semelhante a utilizada pelas aplicacoes estudadas nas seccoes 351 e 352
Para a sua implementacao descrita no capıtulo 4 foram tomadas decisoes de or-
dem pratica que permitissem tornar o trabalho exequıvel nos prazos dados Tentou-
se sempre que estas decisoes afectassem o mınimo em termos de desempenho e de
experiencia para o utilizador Considera-se que a implementacao do modo offline
com uma transicao entre modos do tipo ldquoutilizador deciderdquo (ver seccao 42) reflecte
o compromisso entre o desempenho pretendido e os recursos disponıveis e para alem
51
Resultados e Futuros Desenvolvimentos
de ser um exemplo eficaz das possibilidades que as OWA podem trazer a aplicacao
WOW desenvolvida pela Critical Software e tambem um estudo que pode ser uti-
lizado para analisar a implementacao desta tecnologia noutros produtos da mesma
empresa
Note-se que o principal objectivo do trabalho era ganhar familiaridade com este
tema entender as suas vantagens e desvantagens e compreender as suas limitacoes
Tudo indica que existam varias possibilidades de implementacao deste paradigma
noutros produtos da Critical Software que pela sua natureza podem tambem tirar
partido da execucao offline
52 Trabalho Futuro
O desenvolvimento do conceito e formas de implementacao de OWA continua
em forte desenvolvimento no entanto a sua adopcao ainda nao e generalizada A
dificuldade da sua implementacao em web applications ja existentes e o principal
obstaculo a sua maior divulgacao
Ha tambem um factor que deve ser tido em consideracao a manutencao de
codigo A implementacao de uma versao offline de uma web application requer
a implementacao das mesmas regras de negocio (ou de uma versao simplificada)
utilizadas no servidor Para que isto seja possıvel e necessario ter em conta a
capacidade de processamento do cliente e o factor de duplicacao de codigo que
tornara a aplicacao mais difıcil de manter uma vez que uma alteracao a logica de
negocio do servidor implica tambem uma alteracao a sua versao offline
A prova de conceito implementada permite ja a visualizacao offline dos pedidos
abertos (enviados e recebidos) que constam na pagina principal (este numero e
fixo e pode ser alterado pelo administrador) Uma funcionalidade desejavel seria a
possibilidade de interaccao com a aplicacao em modo offline e sincronizacao com o
servidor quando existisse uma ligacao disponıvel
Foi estudada a utilizacao do modo de execucao ldquoaplicacao assume o estado of-
flinerdquo descrito em 423 e esta seria a forma desejavel para o WOW Offline no
entanto para que esta opcao seja viavel sera necessaria a implementacao de uma
forma eficiente de sincronizacao e armazenamento de dados de uma forma relacional
Para atingir este objectivo podera ser seguida uma polıtica de automacao do pro-
cesso no qual a versao online da aplicacao gera scripts de criacao para as tabelas
necessarias na base de dados da versao offline (nao existe nenhuma ferramenta para
o fazer portanto seria necessaria a sua implementacao) e no qual as paginas HTML
disponibilizadas pelo servidor aos clientes web (browser) servem como templates de
apresentacao de informacao e sao preenchidas de forma semelhante pelo servidor ndash
quando a aplicacao estiver online ndash ou pelo cliente atraves de funcoes em JavaScript
52
Resultados e Futuros Desenvolvimentos
ndash quando a aplicacao estiver offline No entanto no WOW devido a quantidade de
informacao tratada e devido as complexas relacoes entre as diferentes entidades e
de esperar que a complexidade da implementacao de um mecanismo deste tipo torne
esta aproximacao demasiado custosa
O HTML 5 embora um forte candidato ainda nao esta suficientemente desen-
volvido A sua especificacao ainda tem o caracter de Draft (rascunho) e esta sujeita
a modificacoes e a aceitacao e implementacao por parte dos browsers e portanto
de momento foi desconsiderado No entanto no futuro se esta especificacao atingir
um estado de maturidade que permita a sua adopcao devera ser considerada como
um possıvel caminho a seguir
53
Resultados e Futuros Desenvolvimentos
54
Capıtulo 6
Conclusoes
Neste capıtulo sao apresentadas as conclusoes do projecto e consideracoes finais
relativamente a tecnologia estudada
61 Conclusoes
O rapido desenvolvimento tecnologico faz prever que a disponibilidade de ligacao
a Internet seja cada vez mais facil e mais rapido mas vao continuar a existir lugares
onde o acesso e limitado e onde as OWA podem desempenhar um papel de relevo
Por outro lado esta tecnologia pode tambem ser utilizada para melhorar o desem-
penho de paginas web com uma necessidade elevada de imagens ou outros recursos
dispendiosos em termos de espaco e foram ate estudados dois exemplos da utilizacao
desta vertente desta tecnologia em 353
Acredita-se que as OWAs vem responder a uma necessidade real por parte das
web applications actuais e que a evolucao que representam se compara a que se
assistiu dos thin-clients para os fat-clients em termos de autonomia do servidor
A capacidade de oferecer conteudos dinamicos no browser independentemente da
existencia de uma ligacao reune as vantagens tıpicas das web applications como
ausencia de instalacao e actualizacoes instantaneas com as vantagens das aplicacoes
de desktop em capacidade de processamento e armazenamento de dados na maquina
local
As tecnologias disponıveis ate a data estudadas no ambito deste projecto que
permitem o desenvolvimento de OWAs e que apresentam maior maturidade sao o
Gears e o Adobe AIR Ambas se apresentam sobre a forma de plugins que necessitam
de uma instalacao extra para poderem ser utilizadas Apesar de esta instalacao ser
55
Conclusoes
apenas necessaria uma vez podera constituir um factor de desencorajamento a sua
adopcao
O HTML 5 uma especificacao abordada neste documento na seccao 34 podera
ser uma alternativa que oferece funcionalidades offline a uma web application sem a
necessidade de qualquer instalacao no entanto esta especificacao ainda nao foi aceite
pelos principais browsers ndash o documento que define o HTML 5 ainda tem o estatuto
de Draft ndash e ainda nao e possıvel antecipar quando e que isto podera acontecer
Um dos problemas que surge frequentemente na implementacao de uma versao
offline para uma web application e a necessidade de sincronizacao de dados Quando
a informacao pode ser alterada por varios utilizadores simultaneamente e necessario
prever os conflitos que daı podem surgir e dotar a aplicacao de uma forma de os
resolver ou alertar o utilizador para a necessidade de alteracao dos dados
Em conclusao todos os objectivos propostos para este projecto foram atingidos
A prova de conceito implementada reflecte de forma clara as possibilidades oferecidas
pela tecnologia OWA e sera utilizado no futuro para compreender a melhor forma
de o implementar de forma definitiva no WOW
56
Referencias
[Ada08] Lucas Adamski Introducing Adobe AIR security model Fevereiro de2008 Disponıvel em httpwwwadobecomdevnetairarticles
introduction_to_air_securityhtml acedido em Marco de 2008
[Ado08] Adobe Adobe AIR 10 Security White Paper 2008 Disponıvel emhttpdownloadmacromediacompubairdocumentation1air_
securitypdf acedido em Marco de 2008
[Alm08] Dion Almaer Gears as a bleeding-edge html 5 implementa-tion March 2008 Disponıvel em httpalmaercomblog
gears-as-a-bleeding-edge-html-5-implementation acedido emMarco de 2008
[BL96] Tim Berners-Lee The world wide web Past present and future Agostode 1996 Disponıvel em httpwwww3orgPeopleBerners-Lee
1996ppfhtml acedido em Abril de 2008
[CDGH08] Mike Chambers Daniel Dura Dragos Georgita and Kevin Hoyt AdobeAIR for JavaScript Developers OrsquoReilly Media 2008 Disponıvel emhttponairadobecomfilesAIRforJSDevPocketGuidepdf ace-dido em Abril de 2008
[Con99] Jim Conallen Modeling Web Application Architectures with UML Junho1999 Disponıvel em httpwwwumlorgcnUMLApplicationpdf
webappspdf acedido em Maio de 2008
[Ent07] Entrust What is a public key information 2007 Disponıvel em http
wwwentrustcompkihtm acedido em Junho de 2008
[Gar05] Jesse James Garret Ajax A new approach to web applicationsFebruary 2005 Disponıvel em httpwwwadaptivepathcomideas
essaysarchives000385php acedido em Marco de 2008
[Greon] Philip Greenspun Philip and Alexrsquos Guide to Web Publishing 2003(last revision) Disponıvel em httpphilipgreenspuncompandaacedido em Junho de 2008
[Gro02a] App Design Group Thick vs thin client comparison 2002 Disponıvelem httpwwwdonjacobsvwcomimagesweekendspecials
Thick-vs-Thinpdf acedido em Junho de 2008
57
REFERENCIAS
[Gro02b] Technical Research Group Thin Client Tecnhology - WhitePaper 2002 Disponıvel em httpwwwpicktrgcompubs
thinclientwhitepaperpdf acedido em Junho de 2008
[Gro08] Miniwatts Marketing Group World internet usage March 2008Disponıvel em httpwwwinternetworldstatscomstatshtm ace-dido em Abril de 2008
[Hic08] Ian Hickson HTML 5 Draft Recommendation 2008 Disponıvelem httpwwwwhatwgorgspecsweb-appscurrent-work ace-dido em Marco de 2008
[Kha] Olga Kharif Top 10 municipal wifi plans Disponıvel em http
imagesbusinessweekcomss0608muni_wifiindex_01htm ace-dido em Marco de 2008
[Lab07] Mozilla Labs Prism Outubro 2007 Disponıvel em httplabs
mozillacom200710prism acedido em Marco de 2008
[Loo06] Chris Loosley Rich Internet ApplicationsDesign MeasurementandManagement Challenges 2006 Disponıvel em httpwwwkeynote
comdocswhitepapersRichInternet_5pdf acedido em Maio de2008
[Mic08] Microsoft Introduction to Occasionally Connected Applications us-ing Sync Services for ADONET 2008 Disponıvel em httpmsdn
microsoftcomen-ussyncbb887608aspx acedido em Junho de2008
[Nao08] Erica Naone Offline web applications Abril 2008 Disponıvelem httpwwwtechnologyreviewcomread_articleaspxch=
specialsectionsampsc=emerging08ampid=20245 acedido emAbril de 2008
[NJN00] Jason Nieh Yang S Jae and Naomi Novik A comparison of thin-clientcomputing architectures 2000 Disponıvel em httpwwwnclcs
columbiaedupublicationscucs-022-00pdf acedido em Maio de2008
[OrsquoR06] Tim OrsquoReilly Web 20 compact definition Trying again Dezembro2006 Disponıvel em httpradaroreillycomarchives200612
web-20-compact-definition-tryihtml acedido em Marco de 2008
[OrsquoR09] Tim OrsquoReilly What is Web 20 Design patterns and business modelsfor the Next Generation of Software 20053009 Disponıvel emhttpwwworeillynetcompubaoreillytimnews200509
30what-is-web-20html acedido em Marco de 2008
[Rus06] Alex Russel Comet Low latency data for the browser March Marco2006 Disponıvel em httpalexdojotoolkitorgp=545 acedidoem Marco de 2008
58
REFERENCIAS
[Sad97] Darleen Sadoski Clientserver software architecturesndashan overviewAgosto 1997 Disponıvel em httpwwwseicmuedustr
descriptionsclientserver_bodyhtml acedido em Junho de2008
[Sch96] George Schussel Clientserver past present and future 1996
[Smi07] Kevin C Smith Css filters - will the browser apply the rule July 2007Disponıvel em httpcentriclecomrefcssfilters acedido emMarco de 2008
[vK08] Anne van Kesteren The XMLHttpRequest Object W3C Work-ing Draft 15 Abril 2008 Disponıvel em httpwwww3orgTR
XMLHttpRequest acedido em Abril de 2008
[Wil06] Greg Wilkins Why ajax comet July Julho 2006 Disponıvel emhttpwwwwebtidecomdownloadswhitePaperWhyAjaxhtml ace-dido em Abril de 2008
59
REFERENCIAS
60
Anexo A
Screenshots
Algumas imagens de aplicacoes que utilizam funcionalidades offline ilustrativasda tecnologia abordada neste documento
Figura A1 Dialogo apresentado ao utilizador na primeira activacao das funcionalidadesoffline no Google Docs amp Spreadsheets
61
Screenshots
Figura A2 Na activacao das funcionalidades offline e tambem oferecida a possibilidadeda criacao de alguns atalhos por exemplo no ambiente de trabalho
Figura A3 O Google Docs mantem a todo o momento a possibilidade de alteracao destasdefinicoes ou da anulacao dos servicos offline para um dado computador
62
Screenshots
Figura A4 Apos a instalacao do Gears qualquer visita ao Remember The Milk despoletauma sincronizacao que ocorre automaticamente e sem necessidade de intervencao por partedo utilizador
Figura A5 Apos completar a sincronizacao de dados mesmo que a ligacao a Internetseja perdida o Remember the Milk continua disponıvel no browser (com excepcao dasfuncionalidades que pela sua natureza exigem uma ligacao como por exemplo partilhade tarefas e envio de convites)
63
Conteudo
1 Introducao 111 Enquadramento 112 Motivacao 213 Ambito 314 Objectivos 315 Estrutura do documento 3
2 Enquadramento do Projecto 521 Evolucao das arquitecturas de software 5
211 Thin-clients 5212 Fat-clients 6213 Arquitecturas cliente-servidor 7
22 Evolucao na Internet 8221 Paginas web estaticas 9222 Paginas web interactivas e paginas web dinamicas 9223 Web 20 e Ajax 11
23 Offline Web Applications 1324 Comparacao 13
3 Estado da arte 1731 Gears 17
311 Arquitectura 17312 Goggle Gears em dispositivos moveis 20
32 Adobe AIR 20321 Seguranca 22322 Assinatura do codigo 22
33 Mozilla Prism 23331 XML User Interface Language 23332 Prism 25
34 HTML 5 2535 Web applications que usam funcionalidades offline 26
351 Google Reader e Google Docs 26352 Remember the Milk 27353 MySpace e WordPresscom 27
36 Escolha da tecnologia 28
vii
CONTEUDO
4 Desenvolvimento 3341 Como ficar offline 33
411 Funcionalidades disponıveis em modo offline 3442 Modos de execucao 35
421 Modo ldquoutilizador deciderdquo 36422 Modo aplicacao decide 36423 Modo ldquoaplicacao assume o estado offlinerdquo 37
43 Sincronizacao de dados 38431 Quando sincronizar 39
44 WOW 4045 Visao geral sobre a arquitectura do WOW 4146 WOW Offline 42
461 Modo ldquoaplicacao deciderdquo com deteccao automatica da ligacao 43462 Implementacao do modo ldquoutilizador deciderdquo 45463 Especificacao do modo ldquoaplicacao assume o estado offlinerdquo 48
5 Resultados e Futuros Desenvolvimentos 5151 Resultados Obtidos 5152 Trabalho Futuro 52
6 Conclusoes 5561 Conclusoes 55
Referencias 59
A Screenshots 61
viii
Lista de Figuras
21 Arquitectura de um sistema thin-client em duas camadas (a esquerda)e em tres camadas (a direita) Note-se a inclusao do servidor (main-frame) na definicao das camadas desta arquitectura devido a fortedependencia cliente-servidor 9
22 Arquitectura de um fat-client em duas camadas (a esquerda) e emtres camadas (a direita) 10
23 Comparacao do modelo de web aplications sıncrono paginas estaticase interactivas abordados nas seccoes 221 e 222 com o modelo deweb applications Ajax (assıncrono) abordado na seccao 223 Figuraadaptada de http www adaptivepath com 15
31 Esquema UML do processo efectuado pelos recursos do Gears do tipoManagedResourceStore para a actualizacao dos conteudos definidosno ficheiro manifesto 29
41 Exemplo de uma arquitectura de uma web application sem uma ca-mada de abstraccao de dados Figura adaptada de http gears
google com 33
42 Exemplo de uma arquitectura de uma web application com uma ca-mada de abstraccao de dados Figura adaptada de http gears
google com 34
43 Exemplo de uma arquitectura de uma web application com uma ca-mada de abstraccao de dados e um data switch Figura adaptada dehttp gears google com 35
44 Esquema grafico ilustrando uma OWA executando no browser uti-lizando um modo de execucao do tipo ldquoaplicacao deciderdquo com de-teccao automatica do estado da ligacao via pedidos Ajax assıncronosa cada cinco segundos 37
45 Detalhe de um conjunto possıvel de estados e respectivas transicoespara uma dada ordem de trabalho no WOW desde a sua submissaono sistema ate a sua conclusao em fecho ou cancelamento Esta figurarepresenta apenas um exemplo ja que o mapa de estados para umaordem de trabalho e dinamico e pode ser alterado por um admin-istrador Figura retirada de uma brochura promocional do WOWCritical Software SA 41
ix
LISTA DE FIGURAS
46 A pagina inicial do WOW apresenta um resumo das ultimas ordensde trabalho enviadas e recebidas Na imagem pode-se observar atransicao do estado online para offline 44
47 Ilustracao do funcionamento do Gears numa web application que uti-liza um motor Ajax Os pedidos HTTP ou HTTPS podem ser inter-ceptados e tratados localmente ou podem ser feitos a uma maquinaremota consoante se verificarem ou nao as condicoes expressas noponto 311 E representado um acesso a uma base de dados local(fornecida pelo Gears) mas a sua utilizacao e opcional 45
48 Neste exemplo do modo ldquoaplicacao deciderdquo o teste da ligacao e feitoe feito a cada cinco segundos O resultado deste teste nao reflectesempre o estado real da aplicacao podendo levar a aplicacao a tercomportamentos indesejaveis Na figura assinala-se um perıodo detempo no qual a representacao interna do estado da ligacao nao cor-responde a realidade 46
49 Pagina de visualizacao do detalhe de uma ordem de trabalho 47410 Esquema UML que expressa os casos de uso do WOW Offline no
modo ldquoutilizador deciderdquo 48411 Esquema UML que expressa os casos de uso do WOW Offline no
modo ldquoutilizador deciderdquo 49412 Esquema UML que expressa o acto de recolha de dados em modo
online e offline recorrendo ao servidor (modo online) e ao sistemade armazenamento de dados local fornecido pelo Gears (modo offline) 50
A1 Dialogo apresentado ao utilizador na primeira activacao das funcional-idades offline no Google Docs amp Spreadsheets 61
A2 Na activacao das funcionalidades offline e tambem oferecida a possi-bilidade da criacao de alguns atalhos por exemplo no ambiente detrabalho 62
A3 O Google Docs mantem a todo o momento a possibilidade de alteracaodestas definicoes ou da anulacao dos servicos offline para um dadocomputador 62
A4 Apos a instalacao do Gears qualquer visita ao Remember The Milkdespoleta uma sincronizacao que ocorre automaticamente e sem ne-cessidade de intervencao por parte do utilizador 63
A5 Apos completar a sincronizacao de dados mesmo que a ligacao aInternet seja perdida o Remember the Milk continua disponıvel nobrowser (com excepcao das funcionalidades que pela sua naturezaexigem uma ligacao como por exemplo partilha de tarefas e enviode convites) 63
x
Lista de Tabelas
21 Comparacao entre thin-clients e fat-clients 7
31 Comparacao das funcionalidades oferecidas pelo Adobe AIR para asplataformas web e desktop 30
32 Resumo da utilizacao de tecnologias OWA em algumas web applica-tions consideradas na analise do estado da arte 31
xi
LISTA DE TABELAS
xii
Glossario
fat-client Cliente que nao depende totalmente de umservidor central para as suas actividadesde processamento e possui frequentementedispositivos de armazenamento de dados
6ndash8
thin-client Cliente que depende de um servidor centralpara as suas actividades de processamento
5ndash8
web application Sistema web (servidor rede HTTPbrowser) onde accoes do utilizador(navegacao e introducao de informacao)afectam o estado logico da aplicacao
i iii1ndash311ndash1517ndash1921ndash232728 3336ndash3842 5556
API Application Programming Interface 10 1718 2326 28
ASP Linguagem interpretada pelo servidorque permite a criacao de paginas webdinamicas Desenvolvida pela Microsoft
11
BSD Berkeley Software Distribution 28
CSS Cascading Style Sheets 12 2021 2324 46
DHTML Dynamic HyperText Transfer Protocol 24DOM Document Object Model 10 12
20 2324
DTD Document Type Definition 24
xiii
Glossario
ECMAScript Padrao de linguagem de programacaodefinido pela Ecma International que orig-inou o JavaScript e o JScript
24
Flash Conteudo interactivo de um ficheiro emformato SWF E desenvolvido pela Adobee visualizado atraves do Adobe FlashPlayer
21
Flex Framework baseada em XML e Action-Script desenvolvida pela Adobe para a pro-gramacao de Rich Internet Applications(RIA)
21
GPL GNU General Public License 23
HTML HyperText Markup Language 1 10ndash12 2124ndash2649
HTTP HyperText Transfer Protocol 2 26
JMS E uma API em Java que permite a troca demensagens entre componentes de software
42
JSON JavaScript Object Notation permite atroca de dados codificados num formatode texto de simples leitura
12 1828 34
LGPL GNU Lesser General Public License 23
Mozilla Prism Browser simplificado e ldquointerpretadorrdquo deeXtensible User Interface Language (XUL)(tambem designado por XULRunner) queacolhe web applications sem a interfacegrafica habitual de um browser
25
MPL Mozilla Public License 23
OCA Occasionally Connected Application 39OWA Offline Web Application i iii
2ndash515 1725 2628 3133 3651 5255 56
PDF Portable Document Format 21
xiv
Glossario
PHP Linguagem interpretada pelo servidorque permite a criacao de paginas webdinamicas mas que pode tambem ser in-vocada a partir da linha de comandos
11
pagina web estatica Pagina web que devolve sempre a mesmaresposta a todos os pedidos para todos osutilizadores e em qualquer contexto
5 9
RIA Rich Internet Applications web appli-cations que apresentam funcionalidadessemelhantes as desktop applications masque mantem a informacao no lado do servi-dor
5 1520 28
RSS Really Simple Syndication 27
SLA Service Level Agreement 40SQLite Segundo a definicao oficial SQLite is a
software library that implements a self-contained serverless zero-configurationtransactional SQL database engine
17
SSB Site Specific Browser 25SSL Secure Sockets Layer 22SWF ShockWave Flash 21
URL Uniform Resource Locator 18
VPN Virtual Private Network 38
WOW Work Orders Web Plataforma de gestaode ordens de trabalho e do seu fluxo de-senvolvida pela Critical Software SA
i iii28 3340ndash434551ndash5356
WWW World Wide Web 11 1214
XBL eXtensible Binding Language 24XHTML eXtensible HyperText Markup Language 12XML eXtensible Markup Language 11 12
23 2428
XSLT eXtensible Stylesheet Language Transfor-mation
12
XUL eXtensible User Interface Language xiv23ndash25
xv
Glossario
xvi
Capıtulo 1
Introducao
Neste capıtulo enquadra-se o tema do projecto introduzindo alguns dos conceitos
nos quais se baseia Apresentam-se as motivacoes ambito objectivos e a estrutura
deste documento
11 Enquadramento
A Internet foi originalmente concebida para ser um espaco de partilha de in-
formacao onde pessoas (atraves de maquinas) pudessem comunicar Na sua origem
as paginas eram estaticas constituıdas por texto formatado em HyperText Markup
Language (HTML) e ligadas entre si [BL96] Hoje encontramos conteudos cada vez
mais complexos e dinamicos incluindo som vıdeo ou streams multimedia [Loo06] e
em 2005 foi introduzido por [OrsquoR09] o termo Web 20
De acordo com [Greon] um website pode pertencer a uma ou varias das seguintes
categorias
bull Documento ndash um website essencialmente estatico onde alteracoes a uma
parte do conteudo nao tem implicacoes no seu comportamento
bull Base de dados ndash um directorio de informacao organizada em categorias
bull Aplicacao ndash um website dinamico que utiliza uma linguagem executada ou
interpretada do lado do servidor e que processa as accoes ou informacao in-
troduzida pelo utilizador para fornecer um servico ou nova informacao
A ultima destas categorias constitui aquilo que e normalmente designado por
web application O conceito utilizado ao longo deste documento e o mesmo que
o introduzido por Jim Coallen em [Con99] que define web application como um
1
Introducao
sistema web (servidor rede HyperText Transfer Protocol (HTTP) browser) onde
accoes do utilizador (navegacao e introducao de informacao) afectam o estado logico
da aplicacao A sua definicao tenta estabelecer que uma web application e um
sistema de software com estado de negocio1 e que a sua interface de interaccao com
o utilizador e distribuıdo atraves de um sistema web
12 Motivacao
A quantidade de informacao que e produzida e armazenada com recurso a es-
tas web applications disponıveis online tais como e-mail blogues ou mesmo docu-
mentacao tornam por vezes a disponibilidade de ligacao uma condicao necessaria
a produtividade e como consequencia desta barreira muitos potenciais utilizadores
opoem-se a adopcao de produtos web em detrimento das tradicionais desktop appli-
cations
Assegurar o acesso a uma ligacao de Internet e hoje muito mais facil A Internet
movel e ja uma realidade e encontra-se amplamente divulgada mas continuam a
existir diversas situacoes nas quais os utilizadores estao privados de uma ligacao
a Internet tais como uma viagem de metro ou de aviao ou quando se encontram
deslocados do seu paıs de origem e nao possuem nenhum plano de subscricao
Uma OWA consiste numa web application que para alem de manter todas as
caracterısticas anteriores se mantem disponıvel mesmo na ausencia de uma ligacao
a Internet e surge como uma tentativa de estreitar as barreiras existentes entre a
web e o desktop Isto significa que devera existir um mecanismo capaz de assegurar
a manutencao do estado logico da aplicacao quando a ligacao com o servidor e
quebrada permitindo ao utilizador continuar a utilizar a aplicacao e que sera capaz
de informar o servidor do estado em que a aplicacao se encontra quando a ligacao for
reposta A principal vantagem que advem desta possibilidade e evidente eliminar
a necessidade da existencia de uma ligacao a Internet para que a aplicacao possa ser
utilizada
Por outro lado a vontade de integracao de funcionalidades tıpicas das desktop
applications nas web applications foi um dos principais factores que impulsionou o
desenvolvimento deste conceito uma vez que obrigou a uma reflexao ldquopara alem
do browserrdquo e a uma adaptacao das arquitecturas existentes que permitisse ou o
acesso a funcionalidades disponibilizadas pelo sistema operativo ou pelo menos a
funcionalidades semelhantes Pretende-se com esta aproximacao tornar possıveis
interaccoes entre o desktop e o browser tais como arrastar um ficheiro para um
formulario web de upload de conteudos melhor suporte para o historico do clipboard
ou ainda o acesso ao sistema de ficheiros local Atingir estes objectivos reflecte-se
1NT business state
2
Introducao
num novo paradigma que reune as vantagens das web applications tais como os
updates instantaneos ou o facto de nao ser necessaria nenhuma instalacao e das
desktop applications como por exemplo persistencia no armazenamento de dados
acesso a funcionalidades do sistema operativo ou integracao e interaccao com outras
aplicacoes sejam elas web applications ou desktop applications
13 Ambito
Este projecto foi realizado na Critical Software SA no ambito do Mestrado
Integrado em Engenharia Informatica e Computacao (MIEIC) da Faculdade de En-
genharia da Universidade do Porto (FEUP) entre os meses de Fevereiro e Julho de
2008
14 Objectivos
Sao objectivos deste projecto
1 Estudar e documentar o tema das OWAs acompanhando os ultimos desenvolvi-
mentos nesta materia
2 Analisar o estado da arte fazendo uma analise crıtica e objectiva sobre as
diversas metodologias existentes
3 Implementar uma prova de conceito que permita a execucao offline de uma
web application documentando todo o processo
4 Estudar a possibilidade de permitir interaccao com a aplicacao (insercoes e
alteracoes aos dados) em modo offline
Em resumo o objectivo deste projecto foi estudar documentar e implementar
uma prova de conceito relacionada com o tema Offline Web Applications (OWA)
Este tema embora nao seja totalmente novo ganhou destaque ao longo do ano de
2007 com o surgimento de diversas ferramentas que se destinam a aproximar web
applications das desktop applications
15 Estrutura do documento
Este documento esta organizado em diferentes seccoes apresentando o projecto
numa sequencia logica organizada da seguinte forma
No capıtulo 1 faz-se uma breve apresentacao do conceito OWAs e do contexto em
que surge Apresenta-se tambem a estrutura do documento e definem-se os
termos e acronimos utilizados
3
Introducao
No capıtulo 2 faz-se uma descricao da evolucao das tecnologias que antecedem as
OWAs e das vantagens e desvantagens de cada uma como forma de enquadra-
mento
No capıtulo 3 analisa-se o estado da arte nesta materia Introduzem-se diversas
tecnologias directamente relacionadas com o tema deste projecto exemplos de
aplicacoes que as usam e as razoes que fundamentam as escolhas de tecnologias
efectuadas
O capıtulo 4 contem o desenvolvimento do projecto Analisa-se a plataforma
WOW de gestao integrada de ordens de trabalho a tecnologia escolhida e
a forma como foi utilizada para implementar a capacidade de execucao offline
O capıtulo 5 descreve os resultado obtidos comparando-os com as expectativas
iniciais do projecto e apresenta desenvolvimentos futuros e possibilidades de
continuacaoaplicacao do conhecimento adquirido
No capıtulo 6 apresentam-se as conclusoes
4
Capıtulo 2
Enquadramento do Projecto
Neste capıtulo apresenta-se um breve resumo da evolucao das arquitecturas de
software cliente-servidor e a forma como estas se comparam a evolucao da Inter-
net procurando estabelecer uma analogia entre o percurso de ambas as tecnolo-
gias Compara-se o comportamento e arquitectura dos thin-clients as paginas web
estaticas a evolucao dos fat-clients as paginas interactivas Web 20 e Ajax e
defende-se que as OWA constituem um proximo passo logico e evolutivo aproxi-
mando a web do desktop Referem-se ainda os principais factores que justificam a
importancia das OWAs e a estreita relacao que tem com as Rich Internet Application
(RIA)s
21 Evolucao das arquitecturas de software
Os termos thin-client e fat-client sao utilizados quer para descrever arquitecturas
logicas (de software) quer para descrever arquitecturas fısicas (de hardware) Neste
capıtulo excepto quando seja dada indicacao em contrario estes termos referem-se
sempre a uma arquitectura logica
Adicionalmente quando se trata de arquitecturas cliente-servidor pode-se estu-
dar a arquitectura desenvolvida do sistema como um todo da arquitectura do servi-
dor ou da arquitectura do cliente Para evitar equıvocos em especial na seccao 213
especifica-se em cada caso qual o sistema estudado
211 Thin-clients
Um thin-client e um computador cliente ou software cliente que no contexto
de uma arquitectura cliente-servidor depende de um servidor central para as suas
5
Enquadramento do Projecto
actividades de processamento e proporciona um canal de entrada e saıda de in-
formacao entre o utilizador e o servidor remoto Este termo quando aplicado a
hardware refere-se habitualmente a um computador que se destina a ser utilizado
como cliente de rede sem armazenamento local e com capacidade de processamento
reduzida [Gro02b] mas o conceito que aqui se analisa refere-se a uma arquitectura
de software que remonta ao inıcio das aplicacoes cliente-servidor
No inıcio da historia da computacao terminais ligavam-se directamente a main-
frames responsaveis por todo o processamento Nesta arquitectura era necessario
desenvolver duas aplicacoes distintas uma aplicacao central no servidor (main-
frame) responsavel pela gestao de toda a informacao e por todas as operacoes de
comunicacao e uma aplicacao de visualizacao instalada no cliente (terminal) O
papel destes terminais era apenas disponibilizar ao utilizador um meio de comu-
nicacao (entrada e saıda) e apresentacao dos resultados do servidor Nao tinham
um papel activo no calculo nem na logica de negocio e frequentemente nao tinham
tambem nenhum mecanismo de armazenamento de dados
Como vantagens esta arquitectura apresenta uma reduzida necessidade de con-
figuracao e manutencao do lado do cliente Uma vez que o centro do processamento
e manipulacao de dados ocorre no servidor existe tambem uma centralizacao da
informacao [NJN00] que introduz um ponto crıtico de falha1 Actualizacoes e novas
funcionalidades sao faceis de distribuir uma vez que requerem apenas alteracoes no
servidor [Gro02a]
212 Fat-clients
Contrastando com os thin-clients nesta arquitectura os clientes implementam
ja uma parte da logica de negocio e sao responsaveis pelo processamento de dados
Estes fat-clients vieram responder a necessidade crescente de aplicacoes com um
nıvel de interactividade e capacidade de configuracao maior que as oferecidas pela
arquitectura thin-client descrita na seccao 211 Apesar de manterem a sua de-
pendencia do servidor podem tambem ser executados sem uma conexao activa uma
vez que dispoe de armazenamento de dados local o que lhes confere a capacidade
de persistencia de dados e do estado de execucao entre cada sessao
Foi disponibilizando este controlo sobre o estado da aplicacao bem como acesso
a recursos locais (por exemplo sistema de ficheiros e perifericos) que surgiram as
primeiras verdadeiras desktop applications No entanto cada cliente tinha que ser
separadamente instalado no computador pessoal de cada utilizador que pretendesse
utilizar ou interagir com a aplicacao e uma actualizacao ao servidor implicava in-
variavelmente uma actualizacao manual tambem no cliente Uma vez que nem todos
1NT single point of failure
6
Enquadramento do Projecto
Thin-clients Fat-clientsNao toma parte no processamento dedados nem possui acesso ao sistema deficheiros
Participa activamente no processa-mento de dados recorrendo ao sis-tema de armazenamento local para ar-mazenamento de dados
Nao mantem registo do estado logicoda aplicacao entre duas sessoes de uti-lizacao
O acesso ao armazenamento localpermite-lhe manter registo do estadologico da aplicacao entre duas sessoes
O thin-client nao necessita de qualquerinstalacao estando ldquopronto a utilizarrdquo
E geralmente necessario instalar aaplicacao para poder interagir com oservidor
Qualquer update no servidor reflecte-seimediatamente por todos os clientes
Embora a aplicacao cliente possa aler-tar para existencia de novas versoes asactualizacoes tem que ser manualmenteinstalados pelo cliente
O software do cliente destina-se apenasa apresentacao de dados e comunicacaocom o servidor sendo portanto de sim-ples implementacao
Como o software do cliente toma parteactiva no processamento de dadosa sua implementacao requer cuidadosadicionais
Grande mobilidade uma vez que todaa informacao e mantida no servidor
Parte da informacao podera estar ape-nas do lado cliente pelo que existemalgumas restricoes a sua mobilidade
Tabela 21 Comparacao entre thin-clients e fat-clients
os utilizadores actualizam regularmente as suas aplicacoes o servidor tem que estar
preparado para lidar com versoes antigas2 ou descontinuar os seus servicos a uma
parte da sua comunidade de utilizadores ate que estes actualizem os seus sistemas
Como os utilizadores passam a utilizar os seus recursos locais para armazenamento
de dados as alteracoes que nao sejam sincronizadas com o servidor estao apenas
disponıveis nos seus computadores pessoais o que introduz uma restricao a mobili-
dade
Pode-se afirmar que as vantagens dos thin-clients sao as desvantagens dos fat-
clients e que as vantagens dos fat-clients sao as vantagens dos thin-clients tal como
se ilustra na Tabela 21
213 Arquitecturas cliente-servidor
Introduzidos os termos thin-client e fat-client interessa reafirmar que ambos
podem ser vistos como arquitecturas cliente-servidor Um cliente define-se como
um solicitador de servicos e um servidor como um prestador de servicos tal como
definido por [Sch96] e [Sad97]
2NT backward compatibility
7
Enquadramento do Projecto
As arquitecturas cliente-servidor sao categorizadas pela modularizacao com que
sao desenhadas sendo consideradas as seguintes camadas
1 Interface grafica (front-end) atraves da qual os utilizadores interagem com
a aplicacao Quando este modulo e implementado separadamente dos outros
dois constitui uma aplicacao thin-client por si so uma vez que nao implementa
regras de negocio (embora possa definir validacoes de formularios de insercao de
dados por exemplo) A informacao introduzida pelo utilizador e enviada para
o servidor que processa o seu pedido e retorna uma resposta Este processo
repete-se ate que o utilizador atinja o seu objectivo ou se desligue do sistema
2 A logica de negocio tambem designada por camada intermedia que imple-
menta as regras de aceitacao e validacao de todos os dados introduzidos pelo
utilizador E tambem a plataforma de comunicacao que une a camada superior
de visualizacao com a camada de acesso a dados
3 A camada de dados inclui quer o sistema de persistencia de dados onde sao
armazenados os dados relevantes como tambem os mecanismos necessarios
para a sua pesquisa seleccao e alteracao
Os thin-clients quando observados no seu conjunto de cliente e servidor podem
ser vistos quer como sistemas de duas camadas quer como sistemas de tres camadas
dependendo apenas da forma como o servidor for implementado No caso de na
implementacao do servidor nao se distinguir a camada de acesso a dados da camada
da logica de negocio sao designados por sistemas de duas camadas Caso seja feita
esta distincao sao designados por sistemas de tres camadas Ambos os casos sao
ilustrados na Figura 21
Historicamente os fat-clients eram implementados numa arquitectura em duas
camadas Possuıam apenas um modulo de visualizacao de dados designado por
camada de interface e um modulo que implementava toda a logica de negocio e
regras de acesso a base de dados No entanto com a introducao de ligacoes mais
rapidas e de computadores pessoais com maior capacidade de processamento e so-
bretudo devido a complexidade crescente das aplicacoes a logica de negocio e a
camada de acesso a dados tornaram-se independentes Este modelo e designado por
arquitectura em tres camadas e e ilustrado na Figura 22
22 Evolucao na Internet
Ao analisar a evolucao das arquitecturas das aplicacoes desenvolvidas para a
Internet podemos encontrar um paralelismo com a historia da arquitectura de soft-
ware
8
Enquadramento do Projecto
Figura 21 Arquitectura de um sistema thin-client em duas camadas (a esquerda) e emtres camadas (a direita) Note-se a inclusao do servidor (mainframe) na definicao dascamadas desta arquitectura devido a forte dependencia cliente-servidor
221 Paginas web estaticas
Uma pagina web estatica devolve sempre a mesma resposta a todos os pedidos
para todos os utilizadores e em qualquer contexto utilizando o hipertexto como
forma de ligacao entre diversas paginas estaticas
A informacao e armazenada num servidor e o papel do cliente e apenas a apre-
sentacao da informacao Esta forma de disponibilizacao de informacao pode assim
ser comparada com os thin-clients descritos na seccao 211 o utilizador acede a
um website estatico para visualizar informacao sem que o cliente tome parte no
processamento A unica diferenca e que no caso da web estatica a informacao ap-
resentada e sempre a mesma enquanto que nos thin-clients era frequente existir a
possibilidade de insercao de dados no cliente e apos o seu processamento servidor
nova informacao poderia ser apresentada O hipertexto e utilizado para ligar as
paginas entre si numa rede de conteudos relacionados e a navegacao sıncrona era
feita atraves de cliques do rato a cada clique uma nova pagina era apresentada
Este modelo sıncrono e ilustrado na Figura 23
222 Paginas web interactivas e paginas web dinamicas
O JavaScript e uma linguagem interpretada de scripting que tem os browsers
como principal ambiente de acolhimento Os browsers utilizam uma Application
9
Enquadramento do Projecto
Figura 22 Arquitectura de um fat-client em duas camadas (a esquerda) e em tres camadas(a direita)
Programming Interface (API) publica para criar ldquoobjectosrdquo responsaveis por reflectir
e disponibilizar o Document Object Model (DOM) para o motor de JavaScript
A utilizacao mais frequente desta linguagem e a escrita de funcoes que sao em-
bebidas ou incluıdas em paginas web e que interagem com o DOM Uma vez que o
JavaScript e executado localmente (na maquina do cliente e nao no servidor) e capaz
de responder rapidamente a accoes do utilizador tornando a execucao de aplicacoes
no browser mais fluıdas o JavaScript pode tambem detectar accoes do utilizador
que o HTML nao pode tal como o pressionar de uma tecla
Em Dezembro de 1995 a Netscape Communications adicionou suporte para o
JavaScript no browser Netscape Navigator3 e em Agosto de 1996 o browser Internet
Explorer4 da Microsoft passou a tambem a suportar uma versao semelhante desta
linguagem (hoje todos os principais browsers suportam esta tecnologia)
Esta inovacao permitiu tornar os websites mais interactivos mas a sua utilizacao
esteve confinada apenas a este proposito durante um longo perıodo As paginas
passaram a responder activamente a accoes do utilizador (sendo uma das utilizacoes
3Netscape Communications ndash httpbrowsernetscapecom4Microsoft Internet Explorer ndash httpwwwmicrosoftcomwindowsproductswinfamilyie
10
Enquadramento do Projecto
mais vulgares a validacao de formularios) mas continuaram essencialmente estaticas
O JavaScript ainda nao era nesta altura utilizado para processar dados
Tambem nesta altura (1995ndash96) surgiram linguagens server-side como o PHP
Hypertext Preprocessor (PHP) e Active Server Pages (ASP) e o servidor passou a ter
um processamento de dados introduzidos pelo utilizador mais activo Generalizaram-
se as paginas dinamicas capazes de responder a insercao de dados ou outros pedidos
determinados por accoes do utilizador As paginas tornaram-se aplicacoes web ap-
plications
Uma definicao tradicional de web application e um conjunto de paginas web
logicamente agrupadas e geridas por uma unica entidade que tem como pontos de
entrada formularios de insercao de dados (web forms) Uma web application nao e
mais do que uma aplicacao que e acedida atraves de um browser Tem geralmente
uma arquitectura logica em tres (interface logica de negocio e camada de dados)
camadas e estao armazenadas num servidor
Ha dois tipos de web applications
bull Orientadas a apresentacao Sao web applications que geram paginas web in-
teractivas constituıdas por varios tipos de linguagens de anotacao (por exem-
plo HTML eXtensible Markup Language (XML)) e que apresentam conteudo
dinamico como resposta a pedidos efectuados pelo utilizador
bull Orientadas aos servicos Uma web application orientada aos servicos imple-
menta o ponto de acesso para um ou mais de um web service Sao geralmente
clientes de service oriented web applications
Uma vantagem significativa de implementar uma web application de forma a
suportar as funcionalidades padrao dos browsers e que estas terao o mesmo com-
portamento independentemente da plataforma e do browser a partir do qual serao
acedidas No entanto diferentes implementacoes de browsers devido a diferentes
interpretacoes dos padroes definidos tornam por vezes esta tarefa um pouco mais
complicada existindo inclusivamente na web guioes de compatibilidade para os difer-
entes browsers como [Smi07]
223 Web 20 e Ajax
O termo web 20 descreve uma tendencia de utilizacao e de design observada
na World Wide Web (WWW) com o objectivo de melhorar a criatividade partilha
de informacao e principalmente a colaboracao entre utilizadores Estes conceitos
levaram ao desenvolvimento e evolucao de comunidades online tais como redes so-
ciais wikis e blogues
11
Enquadramento do Projecto
O termo tornou-se mais conhecido apos a primeira conferencia OrsquoReilly Media
Web 20 em 2004 e apesar de sugerir uma nova versao da WWW nao se refere a
qualquer evolucao tecnologica mas apenas a alteracoes a forma como os utilizadores
se servem da web De acordo com Tim OrsquoReilly [OrsquoR06] ldquoWeb 20 e uma revolucao
na industria do software causada pela adopcao da web como uma plataforma e pela
tentativa de entendimento das regras para o sucesso nesta nova plataformardquo
O desenvolvimento da Web 20 serve-se muitas vezes de um outro conceito Ajax
O conceito que hoje conhecemos como Ajax muitas vezes incorrectamente de-
scrito como uma tecnologia foi originalmente criado para permitir o desenvolvimento
de web applications que se assemelhassem ainda mais a aplicacoes de desktop Este
conceito foi melhor descrito por [Gar05] como um conjunto de varias tecnologias
que podem ser utilizadas para melhorar a experiencia do utilizador de uma dada
web application introduzindo a capacidade assıncrona de envio de pedidos ou da
recepcao assıncrona de respostas As tecnologias mais frequentemente envolvidas
sao
bull eXtensible HyperText Markup Language (XHTML) e Cascading Style Sheets
(CSS) padrao para a apresentacao
bull interaccao dinamica atraves do DOM
bull troca e manipulacao de dados utilizando XML e eXtensible Stylesheet Lan-
guage Transformation (XSLT) ou JavaScript Object Notation (JSON)
bull pedidos assıncronos utilizando XMLHttpRequest [vK08]
bull JavaScript utilizado para integrar todas estas tecnologias
E importante frisar que o Ajax nao e um produto nem uma tecnologia E um
termo que descreve a utilizacao de um conjunto de tecnologias para o desenvolvi-
mento de web applications com um elevado grau de interactividade Comparativa-
mente as web applications tradicionais o Ajax introduz uma camada de visualizacao
diferente em tres importantes pontos
1 Do lado do cliente existe um motor que serve de intermediario entre a interface
da aplicacao e o servidor
2 A actividade do utilizador despoleta chamadas JavaScript em vez de um pedido
de pagina directamente ao servidor
3 Informacao codificada em XML em vez de paginas HTML e trocada entre o
servidor e o cliente
12
Enquadramento do Projecto
Isto significa que as paginas que utilizam Ajax contem um motor do lado do
cliente composto por um conjunto de funcoes JavaScript responsavel pela comu-
nicacao com o servidor e por actualizar a interface com o resultado dessa mesma
comunicacao
Na Figura 23 ilustra-se a natureza assıncrona do Ajax quando comparada com
as web applications tradicionais Como se pode observar adicionando um mecan-
ismo Ajax a uma web application eliminam-se diversos tempos de espera associados
a comunicacoes com o servidor uma vez que a interface nao fica ldquobloqueadardquo a es-
pera da resposta Obtem-se assim aplicacoes com um comportamento mais fluido
eliminando tempos de espera entre cada ldquocliquerdquo e melhorando a experiencia do
utilizador
23 Offline Web Applications
A informacao grafica (bem como folhas de estilo e scripts) tais como as ima-
gens que constituem o visual de uma web application e ja tratada de forma especial
pelos cada vez mais avancados sistemas de cache (armazenamento temporario) dos
browsers Mas estes nao sao ainda capazes de guardar conteudo criado pelo uti-
lizador nem de apresentar informacao independentemente do estado da ligacao
Numa altura onde se fala de servicos de Internet wireless municipalizados [Kha]
comunicacoes 3G e ligacoes de banda larga a alta velocidade a ligacao a rede global
continua a nao estar permanentemente disponıvel para os utilizadores Na WWW
encontra-se uma importante parte da informacao e das aplicacoes utilizadas para
criar e editar conteudos Por vezes informacao vital para a produtividade pode
desaparecer subitamente do mapa de acesso de um utilizador quando este entra no
metro num aviao ou mesmo quando se desloca para uma cidade ou paıs diferente
do habitual onde nao subscreve um plano de acesso que lhe garanta a ligacao
Permitir o acesso offline a estes recursos assume assim a sua importancia porque
permitira estender o alcance da informacao a locais onde nunca esteve antes e per-
mitira tambem melhorar o desempenho das web applications colocando informacao
mais perto dos utilizadores reduzindo a transferencia de dados apenas ao essencial
24 Comparacao
Nas evolucoes descritas neste capıtulo 2 pode-se observar que existe um par-
alelismo entre a evolucao das arquitecturas tradicionais cliente-servidor e a evolucao
a que se assiste na web O comportamento e arquitectura dos thin-clients assemelha-
se ao das paginas estaticas no sentido em que o browser nao toma parte em qualquer
13
Enquadramento do Projecto
processamento e serve apenas como uma plataforma de interaccao com o servidor
tal como os clientes descritos na seccao 211
A sua proxima evolucao os fat-clients trouxeram parte da capacidade de pro-
cessamento para o lado do cliente Na web foi tambem esta a inovacao tecnologica
a que se assistiu com a evolucao das tecnologias que permitiram a criacao de ver-
dadeiras aplicacoes e com a introducao do Javascript no browser dando ao cliente
a capacidade de processamento de dados A necessidade da separacao do codigo
em camadas logicas advem da crescente complexidade das web applications Esta
pratica permite entre outras coisas melhorar o processo de desenvolvimento e a
capacidade de manutencao de uma aplicacao
Os fat-clients tem tambem a capacidade de armazenamento de dados o que
permite a persistencia de informacoes entre duas sessoes e que algumas operacoes
sejam executadas sem a necessidade de comunicacao com o servidor Este facto pode
tambem ser uma realidade nas web applications com a adopcao das tecnologias OWA
Neste momento assiste-se a uma utilizacao cada vez maior da web como uma
plataforma de desenvolvimento A capacidade de cooperacao na edicao de conteudos
e a mobilidade proporcionada por esta plataforma sao os principais factores que
alimentam esta mudanca e pela primeira vez as aplicacoes tradicionais tem com-
peticao vinda de web applications A prova do reconhecimento da web como plataforma
de desenvolvimento pode ser retirada da aposta de empresas como a Adobe e Mi-
crosoft que lancaram publicamente ferramentas web complementares a produtos
seus tradicionalmente associados ao desktop ndash Acrobatcom5 e Microsoft Office
Live6 Dotar estas web applications da capacidade de execucao offline significa
aproximar a web e o desktop reunindo ldquoo melhor de dois mundosrdquo
As vantagens da mobilidade possıvel atraves da web a cooperacao na criacao e
edicao de conteudos e a possibilidade de utilizar aplicacoes sempre actualizadas e
sem necessidade de instalacao sao algumas das principais vantagens que promovem
esta mudanca que devido as preocupacoes associadas a usabilidade e experiencia do
utilizador esta fortemente associada ao desenvolvimento de Rich Internet Applica-
tion (RIA)s
5Adobe Acrobatcom httpwwwacrobatcom6Microsoft ndash httpsmallbusinessofficelivecom
14
Enquadramento do Projecto
Figura 23 Comparacao do modelo de web aplications sıncrono paginas estaticas e in-teractivas abordados nas seccoes 221 e 222 com o modelo de web applications Ajax(assıncrono) abordado na seccao 223 Figura adaptada de http www adaptivepath
com
15
Enquadramento do Projecto
16
Capıtulo 3
Estado da arte
Apesar de o conceito das OWAs nao ser absolutamente novo as tecnologias que
o suportam sao recentes Neste capıtulo descrevem-se quatro tecnologias que foram
tidas como principais candidatas para o desenvolvimento deste projecto Descrevem-
se ainda alguns exemplos de web applications que disponibilizam actualmente fun-
cionalidades offline e o processo da escolha da tecnologia a utilizar neste projecto
31 Gears
O Gears1 e uma extensao as funcionalidades do browser introduzido pelo Google
que tem como principal objectivo tornar possıvel a visualizacao de paginas de Inter-
net mesmo sem uma conexao disponıvel Encontra-se disponıvel para as platafor-
mas Windows Macintosh e Linux e oferece uma API de Javascript que permite
a scripts aceder a um mecanismo de armazenamento local baseado numa base de
dados SQLite
311 Arquitectura
Esta ferramenta e constituıda por tres componentes principais
bull LocalServer mdash Intercepta pedidos de paginas web e serve-as localmente
bull Database mdash Uma base de dados relacional construıda sobre SQLite
bull WorkerPool mdash Permite executar operacoes de computacao de uma forma
assıncrona sem afectar a capacidade de resposta e fluidez de execucao da web
application Assemelham-se a processos
1Google Inc ndash Mais informacao em httpgearsgooglecom
17
Estado da arte
LocalServer
O modulo LocalServer e uma cache de Uniform Resource Locators (URLs)
controlada pela web application Quando nao existe uma ligacao a Internet e e
feito um pedido para um URL presente nesta cache o LocalServer intercepta-o e
responde ao pedido localmente a partir do disco rıgido do utilizador A aplicacao
pode utilizar dois tipos diferentes de armazenamento local de URLs
bull ResourceStore ndash serve para capturar URLs utilizando exclusivamente a API
de Javascript disponibilizada para o efeito Uma aplicacao podera criar e
utilizar diversos ResourceStores simultaneamente para capturar ficheiros de
dados que necessitam de ser enderecados por um URL tal como um ficheiro
PDF ou uma imagem
bull ManagedResourceStore ndash serve para capturar um conjunto de URLs que estao
relacionados e que sao declarado num ficheiro de manifesto (especificado em
JSON) e que sao automaticamente actualizados O ManagedResourceStore
permite que o conjunto de recursos necessarios para correr uma web application
seja capturado e mantido actualizado automaticamente
A principal diferenca entre estes dois tipos de armazenamento de URLs e a forma
como sao actualizados os seus conteudos Os conteudos de um ManagedResourceStore
sao actualizados sempre que a versao contida no ficheiro de manifesto for alterada
enquanto que os conteudos de um ResourceStore nunca sao actualizados automati-
camente mas apenas quando for explicitamente ordenado pela aplicacao
O LocalServer e capaz de interceptar e servir localmente pedidos de HTTP e
HTTPS sempre que se reunam as seguintes condicoes
1 O URL encontra-se armazenado num ResourceStore ou ManagedResourceStore
2 O sistema de armazenamento local encontra-se activo (enabled = true) Se
o sistema de armazenamento local tiver o atributo requiredCookie o pedido
devera conter um cookie que lhe corresponda
O LocalServer nao necessita de monitorizar o estado da ligacao para atender aos
pedidos Na verdade sempre que as condicoes previamente enunciadas se verificarem
o LocalServer interceptara os pedidos e independentemente do estado da ligacao
a Internet servi-los-a a partir do disco rıgido local Cabera a aplicacao definir qual
o modo em que pretende executar um pedido (online ou offline) definindo o valor
de verdade da propriedade enabled
18
Estado da arte
Database
O modulo Database permite guardar dados da web application assegurando a
sua persistencia Os dados sao guardados de forma relacional no disco rıgido do uti-
lizador2 de acordo com o modelo de seguranca estabelecido pelo Gears3 significando
que uma aplicacao nao pode aceder a conteudos fora do seu domınio
WorkerPool
Nos web browsers uma operacao pesada de computacao pode tornar a interface
lenta e tornar menos agradavel a experiencia do utilizador O modulo WorkerPool
permite correr operacoes em background sem bloquear a interface com o utilizador
Os scripts executados numa WorkerPool nao activam os mecanismos de seguranca
do browser que mostram a mensagem ldquoA script on this page may be busy or may
have stopped respondingrdquo
O WorkerPool comporta-se como um conjunto de processos em vez de threads
Os Workers nao partilham qualquer estado de execucao o que significa que uma
alteracao a uma variavel num Worker nao afecta em nada a execucao de outro
Worker Alem disso os Workers nao herdam automaticamente nenhum codigo dos
seus pais Cada Worker e membro de um WorkerPool e os Workers podem in-
teragir entre si enviando mensagens em formato de texto ou JSON No entanto ha
tambem algumas limitacoes os Workers nao tem acesso ao DOM e objectos como
window ou document nao se encontram acessıveis Isto e consequencia de os Workers
nao partilharem o estado de execucao Mas tem acesso a todas as funcoes built-in
do Javascript A maioria das funcionalidades do Gears pode tambem ser acedida
atraves de uma variavel global especial definida como googlegearsfactory Para
outras funcionalidades especıficas os Workers podem ldquopedirrdquo a pagina principal para
continuar a execucao atraves do envio de mensagens
Outras funcionalidades
bull HttpRequest ndash Este modulo implementa a especificacao W3C XmlHttpRe-
quest definida em [vK08] tornando-a disponıvel para os workers e para a
pagina principal
bull Timer ndash Este modulo implementa a especificacao de timers tal como descrito
por [Hic08] e torna-os disponıveis para os workers e para a pagina principal
2Consultar httpcodegooglecomapisgearsapi_databasehtmldirectories3Consultar httpcodegooglecomapisgearssecurityhtml
19
Estado da arte
bull Factory ndash Esta classe e utilizada para instanciar todos os outros objectos da
API do Gears atraves do seu metodo create Este metodo pode ser utilizado
com os seguintes parametros
ndash betadatabase
ndash betahttprequest
ndash betalocalserver
ndash betatimer
ndash betaworkerpool
312 Goggle Gears em dispositivos moveis
O Gears esta tambem disponıvel em dispositivos Windows Mobile 5 e 6
Os dispositivos moveis estao pela sua natureza frequentemente desconectados
da Internet Mesmo quando possuem uma ligacao as latencias na transferencia de
dados em redes moveis tornam as aplicacoes pouco fluıdas mas o Gears permite
ultrapassar este obstaculo
O Gears funciona exactamente da mesma forma em dispositivos moveis equipados
com o Windows Mobile 5 e 6 como num computador comum Se uma aplicacao tiver
sido implementado com suporte para o Gears entao tambem estara preparada para
ser executada num dispositivo movel mas as limitacoes dos browsers disponıveis
para dispositivos moveis tem que ser consideradas Isto significa prever as condicoes
que permitam uma boa usabilidade devido aos pequenos ecras destes dispositivos
bem como o seu suporte limitado dos padroes do DOM CSS e JavaScript
32 Adobe AIR
O Adobe AIR4 e um runtime compatıvel com diversos browsers e sistemas opera-
tivos que pretende dar aos programadores a possibilidade de combinar diversas tec-
nologias de producao de conteudos para a Internet no desenvolvimento de Rich Inter-
net Application (RIA)s O Adobe AIR mantem uma relacao com o browser mas es-
tende as suas capacidades e tecnologias permitindo o desenvolvimento de aplicacoes
tambem para o ambiente de trabalho com janelas em tudo semelhantes as do sis-
tema operativo Segundo a Adobe o objectivo e complementar o browser dando
aos utilizadores (mas essencialmente aos programadores e equipas de desenvolvi-
mento) a escolha sobre como distribuir as suas aplicacoes Para este efeito o Adobe
AIR tem uma aproximacao diferente do Gears Em vez de ldquoestenderrdquo o browser
acrescentando-lhe funcionalidades o AIR permite tambem o desenvolvimento de
4Adobe - httpwwwadobecomproductsair
20
Estado da arte
aplicacoes que se destinam a ser executadas fora do ambiente do browser mas uti-
lizando as tecnologias comuns da Internet (por exemplo HTML CSS JavaScript
Flash Flex)[CDGH08]
A utilizacao desta tecnologia permite utilizar o browser ou o proprio runtime
Adobe AIR como plataforma de execucao da aplicacao
Na Tabela 31 faz-se uma comparacao das funcionalidades disponıveis de acordo
consoante se escolha o browser ou o desktop como plataforma base para a aplicacao
Uma vez que as aplicacoes Adobe AIR na plataforma desktop tem um caracter
persistente (sao instaladas no computador do utilizador) o Adobe AIR tem um
modelo de seguranca que se assemelha com o das tradicionais aplicacoes desktop
[Ada08] Este modelo e analisado nas seccoes 321 e 322 O ambiente em que
e executado o browser e restringido a execucao de web applications que podem
ser de varias origens (incluindo de origens anonimas ou sem confianca) O Adobe
AIR proporciona acesso a capacidades como acesso a ficheiros que necessitam da
confianca do utilizador
bull HTML ndash O desenvolvimento de aplicacoes para o Adobe AIR pode ser feito
com recurso a tecnologias de HTML e Ajax comuns utilizando as linguagens
de markup existentes distribuıdas como texto e interpretadas em execucao
(runtime)
bull Flash ndash Outra alternativa sera a utilizacao da linguagem Flash Permite a
renderizacao de graficos vectoriais e audiovıdeo com suporte nativo Utiliza
ActionScript para adicionar maior interactividade com o utilizador
bull Flex ndash O Flex e uma framework open source para o desenvolvimento de RIAs
usando Flash As aplicacoes Flex sao na realidade Flash sendo a principal
diferenca o ambiente de desenvolvimento
Como resultado uma aplicacao AIR podera ser implementada
bull Baseada em Flash ou Flex (aplicacoes cujo conteudo base e em ShockWave
Flash (SWF))
bull Baseada em Flash ou Flex tambem com HTML ou Portable Document Format
(PDF) Aplicacoes cujo conteudo de base e em FlashFlex (SWF) com HTML
(HTML JavaScript CSS) ou conteudo PDF incluıdo
bull Baseada em HTML Aplicacoes cujo conteudo base e em HTML Javascript
CSS
bull Baseada em HTML utilizando tambem FlashFlex ou PDF
21
Estado da arte
Os utilizadores interagem com uma aplicacao AIR da mesma forma que interagem
com outras aplicacoes com janelas nativas do seu sistema operativo O runtime e
instalado uma vez no computador do utilizador e a partir desse momento todas as
aplicacoes AIR terao o mesmo aspecto que qualquer outra aplicacao para o desktop
321 Seguranca
Permitir que uma web application aceda ao disco de armazenamento do utilizador
pode comprometer seriamente a sua seguranca Neste sentido o Adobe AIR tem
suporte para assinaturas digitais (Secure Sockets Layer (SSL)) que podem ser com-
pradas pelas equipas de desenvolvimento que o desejem e cujos certificados serao
apresentados ao utilizador no momento da instalacao Um outro aspecto ainda
relativo a seguranca e o mecanismo de isolamento de cada ambiente (sandbox )
322 Assinatura do codigo
O runtime AIR exige que todas as aplicacoes estejam digitalmente assinadas As
assinaturas digitais de codigo sao um processo que visa garantir a integridade da
aplicacao e a identidade do seu autor no momento da instalacao As equipas de
desenvolvimento podem ldquoassinarrdquo uma aplicacao utilizando um certificado atribuıdo
por uma Entidade Certificadora (Certification Authority) ou atraves de um certifi-
cado individual (self signed certificate) Neste momento o Adobe AIR suporta como
entidades certificadoras a Verisign e a Thawte [Ado08]
O instalador apresenta o nome de quem publica a aplicacao quando o codigo tiver
sido assinado com um certificado que apresente confianca ou que esteja encadeado
com um certificado que tenha ja sido aceite no computador em que se esta a instalar
a aplicacao
As equipas de desenvolvimento podem tambem assinar as aplicacoes com um
certificado auto-atribuıdo (um certificado criado por elas proprias) mas neste caso
o instalador apresentara estas aplicacoes como sendo de uma origem nao verificada
O AIR utiliza a infraestrutura publica de chaves [Ent07] suportada pelo arquivo
local do sistema operativo Para que a origem da aplicacao seja reconhecida o
computador onde a aplicacao AIR esta a ser instalada tem que confiar directamente
no certificado que foi utilizado para assinar a aplicacao ou confiar num certificado
que esteja num encadeamento logico de certificados confiados e que se ligue desta
forma ao certificado utilizado para assinar a aplicacao
Todas as aplicacoes AIR tem caracterısticas em comum independentemente da
tecnologia utilizada para o seu desenvolvimento (HTMLFlexFlash) No ambito
de uma aplicacao AIR existem um conjunto de APIs que estao disponıveis e que
tornam possıvel o acesso ao sistema local (leitura e escrita) e a recursos de rede que
22
Estado da arte
de outra forma nunca estariam acessıveis a partir de uma web application comum
Cada aplicacao AIR possui tambem diferentes nıveis de isolamento chamados secu-
rity sandboxes dependendo do tipo de conteudo que esta a ser carregado e do seu
objectivo
bull Isolamento ao nıvel da aplicacao5 ndash E a raiz de cada aplicacao AIR Este
nıvel de isolamento permite o acesso a APIs privilegiadas e especıficas do
AIR Em contrapartida e negado o acesso a algumas APIs que poderiam ser
facilmente utilizadas de forma maliciosa contra o utilizador final Importacao
dinamica de conteudos remotos e geralmente proibido e as tecnicas e mecan-
ismos de geracao dinamica de codigo sao fortemente restringidas Apenas
conteudo carregado directamente da directoria base da aplicacao podera ser
colocado neste nıvel de isolamento
bull Isolamento nao especıfico da aplicacao6 ndash contem todo o outro conteudo
que nao tenha sido carregado directamente para o isolamento da aplicacao
Isto inclui conteudo local e remoto Este tipo de conteudo nao tem acesso
directo as APIs do AIR e rege-se pelas mesmas regras tal como se tivesse sido
carregado por um browser a partir da mesma localizacao (por exemplo HTML
carregado a partir de um domınio remoto comporta-se da mesma forma que se
fosse acedido a partir do browser)
33 Mozilla Prism
331 XML User Interface Language
O eXtensible User Interface Language (XUL) e uma linguagem de anotacao
baseada em XML desenvolvida pela Mozilla Foundation que opera em aplicacoes
Mozilla multi plataforma tal como o Firefox O motor Gecko e a unica imple-
mentacao completa desta linguagem que foi desenhada sobre padroes web comuns
como CSS JavaScript e o DOM e permite o desenvolvimento de interfaces graficas
utilizando elementos pre-definidos tais como window box page textbox radio
button entre outros Infelizmente o XUL nao possui qualquer especificacao formal
ou implementacoes de inter-operabilidade para outros motores que nao o Gecko No
entanto a sua implementacao e licenciada em codigo aberto pelas licencas GNU Gen-
eral Public License (GPL) GNU Lesser General Public License (LGPL) e Mozilla
Public License (MPL)
Enunciam-se algumas caracterısticas desta linguagem
5NT application sandbox6NT non-application sandbox
23
Estado da arte
Liguagem de anotacao poderosa baseada em componentes (widgets) O ob-
jectivo do XUL e permitir a construcao de aplicacoes multi-plataforma em
claro contraste com o Dynamic HyperText Transfer Protocol (DHTML) que se
destina ao desenvolvimento de paginas web Por esta razao o XUL esta orien-
tado a componentes tais como janelas botoes e etiquetas em vez de paginas
cabecalhos de texto e ligacoes de hipertexto Investir tempo e esforco para
atingir este mesmo resultado em aplicacoes baseadas em DHTML compromete
frequentemente a complexidade e desempenho da aplicacao
Baseado em padroes O XUL e um dialecto XML baseado no padrao W3C XML
10 As aplicacoes escritas em XUL sao tambem baseadas em especificacoes
W3C adicionais como HTML 40 CSS DOM nıvel 1 e 2 JavaScript 15
incluindo ECMA-262 Edition 3 (ECMAscript)
Portabilidade entre plataformas Tal como HTML o XUL foi desenhado para
ser independente da plataforma em que e utilizado tornando as aplicacoes
facilmente portaveis entre sistemas operativos nos quais o Mozilla e suportado
Uma vez que o XUL oferece um nıvel de abstraccao dos componentes graficos
de interface que disponibiliza implementa a premissa ldquoum codigo para todas
as plataformasrdquo A interface grafica de todos os produtos centrais Mozilla
(browser instant messenger livro de enderecos) e escrita em XUL com um
unico codigo base que suporta todas as plataformas Mozilla
Separacao entre o nıvel de apresentacao e a logica de negocio Uma das
maiores preocupacoes no desenvolvimento para a Internet e a forte ligacao
entre estas duas camadas (interface e logica) Isto constitui um problema sig-
nificativo no desenvolvimento de grandes aplicacoes especialmente quando o
desenvolvimento e feito em ambientes de equipa porque as capacidades de de-
senvolvimento destas duas partes da aplicacao estao muitas vezes espalhadas
por diferentes elementos O XUL permite uma clara distincao entre a definicao
da aplicacao cliente e da logica de implementacao (XUL eXtensible Binding
Language (XBL) e JavaScript) apresentacao (CSS e imagens) internacional-
izacao (Document Type Definitions (DTDs) e etiquetas de texto em lınguas
especıficas guardados em ficheiros properties) O esquema grafico e apre-
sentacao de uma aplicacao XUL pode ser alterado de forma independente da
sua logica ou implementacao e a aplicacao pode ainda ser traduzida (interna-
tionalization) de forma independente da sua logica implementacao ou apre-
sentacao Este grau de separacao resulta em aplicacoes que sao mais faceis de
manter pelos programadores e facilmente adaptadas por designers e tradutores
24
Estado da arte
Facil adaptacao Outro benefıcio que advem do nıvel de separacao entre logica
de negocio e apresentacao oferecido pelo XUL e a facilidade com que se pode
adaptar uma aplicacao para diferentes clientes ou grupos de utilizadores Um
programador pode utilizar a mesma aplicacao base e adapta-la consoante as
necessidades atraves de diferentes temas (skins) e ficheiros de lınguas Desta
forma uma aplicacao escrita e desenvolvida em Ingles pode ser rapidamente
traduzida para Portugues e distribuıda com outra aparencia mais apropriada
ao cliente alvo
332 Prism
O Mozilla Prism e um browser simplificado e ldquointerpretadorrdquo de XUL (tambem
designado por XULRunner) que acolhe web applications sem a interface grafica ha-
bitual de um browser Baseia-se num conceito designado por Site Specific Browser
(SSB) Um SSB e uma aplicacao com um browser embebido desenhado para exe-
cutar apenas uma web application Nao possui os menus e barras de ferramentas
habituais Um SSB tem uma integracao com o sistema operativo e com o desktop
muito mais estreita do que uma web application acedida atraves de um browser uma
vez que e executado em janela propria
O Prism resulta de uma experiencia da Mozilla e visa reduzir as diferencas entre
as desktop applications tradicionais e as web applications Um dos aspectos focados e
a experiencia do utilizador Numa apresentacao oficial e dito que ldquo[o Prism] pretende
ser uma ponte entre as diferencas que existem entre as aplicacoes tradicionais de
desktop e as web applications explorando novos modelos de usabilidade enquanto
que a linha que as separa se continua a definirrdquo [Lab07]
34 HTML 5
A especificacao HTML 5 [Hic08] que se encontra em fase de desenvolvimento
pelo grupo WHATWG pretende ser uma norma de substituicao dos padroes HTML
4 XHTML 1x e do DOM2 HTML Uma das propriedades que o distingue das tec-
nologias que pretende substituir e precisamente o suporte para OWA e armazena-
mento de dados no cliente de uma forma relacional Nao sendo propriamente uma
tecnologia ndashmas antes uma especificacao ndashe aqui mencionada por ter servido como
referencia a diversas implementacoes de funcionalidades offline e por se considerar
que venha a ter um impacto significativo nas implementacoes de diversos browsers
Dion Almaer defendeu no seu blogue que o Gears era uma implementacao do
HTML 5 No seu artigo ldquoGears as a bleeding-edge HTML 5 implementationrdquo [Alm08]
o autor diz que ambos ndasho Gears e o HTML 5 ndashpretendem dar a web caracterısticas
25
Estado da arte
semelhantes e nao encontrar motivo de ldquocompeticaordquo entre as duas mas que en-
quanto o HTML 5 e uma especificacao o Gears e uma implementacao
No entanto tambem e verdade que o HTML 5 cobre muitos outros pontos para
alem das OWA que saem completamente fora do ambito do Gears Se esta es-
pecificacao atingir um estado de maturidade que possibilite a sua adopcao pelos
principais browsers tornando nativo do browser o suporte OWA entao deixara de
fazer sentido a existencia de uma extensao como o Gears
A especificacao HTML 5 disponibiliza duas APIs relevantes para o tema das
OWA
1 Uma base de dados baseada em SQL que permite o armazenamento de dados
do lado do cliente
2 Uma ldquocacherdquo HTTP que garante a disponibilidade das aplicacoes mesmo quando
o utilizador nao possui uma ligacao a Internet
Estas caracterısticas sao as bases da tecnologia das OWA e tem correspondencia
com os pontos analisados nas seccoes 311 e 311
35 Web applications que usam funcionalidades offline
Nesta seccao apresentam-se algumas web applications que actualmente disponi-
bilizam funcionalidades offline Estas aplicacoes foram escolhidas para uma analise
mais pormenorizada por utilizarem o Gears que tal como descrito na seccao 4 foi
a tecnologia escolhida para o projecto
351 Google Reader e Google Docs
O Google Reader7 e um leitor de feeds RSS Permite gerir a subscricao de varios
sites simultaneamente que disponibilizem conteudos neste formato e foi a primeira
web application da Google com uma versao offline publicamente acessıvel (desde
Junho de 2007)
O Google Reader implementa o modo ldquoutilizador deciderdquo oferecendo na sua
interface um botao que permite alternar entre os modos online e offline
O Google Docs8 e uma web application que permite a criacao e edicao de doc-
umentos de texto folhas de calculo e apresentacoes Era ja publico desde Janeiro
de 2008 que o Google estava a desenvolver uma versao OWA desta aplicacao mas o
acesso a uma versao experimental so foi possıvel a partir de 31 de Maio de 2008
7Google Reader - httpreadergooglecom8Google Docs - httpdocsgooglecom
26
Estado da arte
A implementacao das funcionalidades offline nestas duas aplicacoes seguiu difer-
entes aproximacoes principalmente porque o Google Reader apresenta ao utilizador
informacoes que sao fornecidas por fontes externas enquanto que no Google Docs
a informacao e criada e editada pelo utilizador sobre a forma de documentos
A diferente origem da informacao implica que no Google Reader seja necessario
prever casos de excepcao tal como existirem demasiados itens que necessitam de
ser transferidos para o cliente Nao observar este ponto causa um problema grave
de usabilidade e para evitar tempos de espera demasiado longos e uma interface
com pouca capacidade de resposta as accoes do utilizador o Google Reader apenas
transfere para o cliente os dois mil itens mais recentes na transicao para o modo
offline
352 Remember the Milk
O Remember The Milk9 e uma web application desenvolvida por uma equipa
Australiana que proporciona funcionalidades de agenda gestao de tempo e de tare-
fas e foi uma das primeiras aplicacoes independentes do Google a adoptar o Gears
para acessos em modo offline Permite que os seus utilizadores facam uma gestao
de tarefas agrupando-as em listas adicionando-lhes campos de informacao adicional
ou dando-lhes informacao geografica (recorrendo ao servico Google Maps10) Entre
a sua lista de funcionalidades encontra-se ainda a possibilidade de importar e ex-
portar eventos no formato iCalendar (ics) etiquetas (tags) em tarefas publicacao
Really Simple Syndication (RSS) e partilha de categorias de tarefas de acordo com
diferentes nıveis de permissoes de acesso definidos pelo utilizador
353 MySpace e WordPresscom
O MySpace uma das maiores social networks na Internet anunciou recente-
mente que vai disponibilizar uma versao do seu cliente de e-mail que utiliza o Gears
para acelerar o seu desempenho Numa fase inicial estara disponıvel apenas para
utilizadores que tenham cinco mil ou mais mensagens na sua caixa de correio e
permitira efectuar pesquisas muito mais rapido que a sua versao online
O servico de blogs Wordpresscom anunciou tambem o inıcio da utilizacao desta
tecnologia com o fim de melhorar o desempenho A versao que utiliza esta tecnologia
descarrega e armazena no cliente um conjunto de imagens e scripts que passam a
ter preferencia sobre os seus congeneres online e que permitem acelerar o processo
de carregamento da aplicacao e visualizacao de blogs
9Remember The Milk ndash httpwwwrememberthemilkcom10Google Maps ndash httpmapsgooglecom
27
Estado da arte
O MySpace e o Wordpresscom sao dois exemplos da utilizacao da tecnologia
OWA para optimizacao de web application ja existentes Sem pretenderem disponi-
bilizar uma versao que seja totalmente offline fazem uso do Gears para armazenar no
cliente parte dos recursos frequentemente acedidos na visualizacao das suas paginas
36 Escolha da tecnologia
Apos a analise das tecnologias apresentada nas seccoes 31 a 34 foi necessario es-
tudar a adequacao de cada uma delas ao projecto em questao Desde logo e possıvel
observar que nem todas se dedicam apenas a OWA Por exemplo o Adobe AIR
apesar de ter suporte para OWA apenas disponibiliza algumas das funcionalidades
identificadas como mais indicadas para a execucao do projecto quando utilizado
na sua vertente desktop tal como exposto na Tabela 31 mas a utilizacao desta
vertente implicaria o desenvolvimento de novas interfaces e de novas formas de co-
municacao (troca de mensagens XML ou JSON) A vertente web do Adobe AIR
foca-se mais especificamente nas Rich Internet Applications e permite a reutilizacao
do codigo ja existente (exigindo naturalmente a sua adaptacao e a implementacao
das funcionalidades pretendidas)
A tecnologia escolhida para a realizacao deste trabalho foi o Gears sendo que
um dos principais factores a influenciar esta opcao foi a liberdade introduzida pela
sua licenca Berkeley Software Distribution (BSD)11
Considerou-se o funcionamento desta ferramenta extremamente adequando a
aplicacao no WOW uma vez que o seu principal objectivo e precisamente tornar
possıvel a execucao offline de uma pagina web e por virtude deste facto o Gears tem
uma API concisa e de simples aplicacao pratica uma vez que nao possui quaisquer
outros elementos distractores O funcionamento do seu ManagedResourceStore ex-
emplificado na Figura 31 com a capacidade de actualizacao de recursos definidos
num ficheiro manifesto especificado em JSON pesou tambem nesta decisao
11Sobre a licenca BSD consultar httpwwwopensourceorglicensesbsd-licensephp e http
wwwlinfoorgbsdlicensehtml
28
Estado da arte
Figura 31 Esquema UML do processo efectuado pelos recursos do Gears do tipoManagedResourceStore para a actualizacao dos conteudos definidos no ficheiro manifesto
29
Estado da arte
Funcionalidade RIAs no browser RIAs no desktop
Disponibilidadeda aplicacao
As aplicacoes podem ser facil-mente exploradas e utilizadas
As aplicacoes quando instal-adas tem maior grau de fun-cionalidades e persistencia
Instalacao Nao e necessario qualquer tipode instalacao
As aplicacoes sao instaladasatraves do browser ou descar-regadas e instaladas comouma aplicacao tradicional
Actualizacoes Aplicacoes sao actualizadascarregando conteudos paraum website
O AIR disponibiliza uma APIque permite que as aplicacoessejam actualizadas de umaforma
Sistemas opera-tivos suportados
As aplicacoes podem ser exe-cutadas em diversos sistemasoperativos e browsers
As aplicacoes sao multi-plataforma e podem serinstaladas e executadas emdiversos sistemas operativos ebrowsers
Linguagens deprogramacao
Javascript e disponibilizadopelo browser e ActionScripte disponibilizado pelo AdobeFlash Player
Maquinas virtuais deJavascript e ActionScriptcompatıveis com o browser
Capacidade deexecucao embackground
As RIAs podem ser execu-tadas numa janela do browser
As aplicacoes podem ser ex-ecutadas em background edisponibilizar notificacoes talcomo uma aplicacao tradi-cional
Persistencia A actividade esta limitada asessao do browser Quando obrowser e encerrado toda ainformacao e descartada
As aplicacoes sao instaladas eestao disponıveis no desktopPodem armazenar informacaolocalmente e estao disponıveisoffline
Integracao com odesktop
Integracao com o desktop lim-itada devido a restricoes im-postas pelo browser
As aplicacoes podem acederao sistema de ficheiro ao clip-board eventos notificacoesetc
Controlo da inter-face com o uti-lizador
As aplicacoes sao acedidasatraves de uma janela dobrowser que tem os seusproprios controlos e visualgrafico
As aplicacoes tem um vi-sual grafico proprio em janelapropria
Armazenamentode dados
As aplicacoes tem armazena-mento limitado que pode serreescrito pelo browser
As aplicacoes tem acesso a to-talidade do espaco disponıvellocalmente e a uma base dedados com a possibilidade deencriptacao
Tabela 31 Comparacao das funcionalidades oferecidas pelo Adobe AIR para as platafor-mas web e desktop
30
Estado da arte
Aplicacao Modo de execucao utilizadoGoogle Reader Utiliza o modo ldquoutilizador deciderdquo disponibilizando
ao utilizador um botao para alternar entre os modosonline e offline Como lida com informacao recol-hida de fontes externas de natureza frequentementeefemera o processo de sincronizacao apenas transfereos dois mil itens mais recentes quando passa ao es-tado offline Neste modo sao ainda guardadas in-formacoes de itens lidos e etiquetas atribuıdas quesao sincronizadas com o servidor quando o utilizadorvoltar a activar estado online
Google Docs Utiliza o modo ldquoaplicacao deciderdquo permitindo que outilizador edite os conteudos de documentos de textofolhas de calculo e de apresentacoes independente-mente do estado da ligacao desde o momento em queas funcionalidades offline sao activadas A aplicacaofaz pequenas sincronizacoes com o servidor sempre quenecessario
Remember the Milk Utiliza um modo hıbrido entre ldquoaplicacao deciderdquo eldquoutilizador deciderdquo A aplicacao encarrega-se da sin-cronizacao de dados mas disponibiliza um controlona sua interface que permite despoletar manualmenteeste processo para situacoes em que o utilizador fez al-teracoes recentes e pretende usufruir das capacidadesoffline imediatamente
MySpace O MySpace anunciou a utilizacao de mecanismos dearmazenamento de dados no cliente com recurso atecnologias OWA para melhorar o desempenho doseu cliente web de correio electronico nomeadamenteno que diz respeito a operacoes de pesquisa e or-denacao Inicialmente esta funcionalidade estara ape-nas disponıvel para utilizadores com cinco mil ou maismensagens na sua caixa de correio mas nao e aindaclaro se sera disponibilizada uma versao totalmenteoffline
Tabela 32 Resumo da utilizacao de tecnologias OWA em algumas web applications con-sideradas na analise do estado da arte
31
Estado da arte
32
Capıtulo 4
Desenvolvimento
Neste capıtulo introduz-se a aplicacao WOW e apresenta-se o estudo que foi
feito da adequacao de cada tecnologia para a implementacao da funcionalidade of-
fline nesta plataforma Fazem-se diversas consideracoes sobre opcoes a tomar na
concepcao de OWAs e problemas comuns na sua implementacao bem como sug-
estoes para os resolver O WOW e uma aplicacao ja existente de gestao de ordens
de trabalho e do fluxo de tarefas numa empresa ou organizacao
41 Como ficar offline
Na maior parte das web applications de hoje nao existe uma camada de dados
real A aplicacao exemplificada na Figura 41 ao longo da sua execucao acede
directamente a sua unica fonte de dados (o servidor) atraves de chamadas Ajax sem
que exista uma separacao clara destas duas camadas
Para que uma web application seja capaz de ser executada sem uma ligacao
activa a Internet e mantenha o seu caracter dinamico torna-se necessario incluir
Figura 41 Exemplo de uma arquitectura de uma web application sem uma camada deabstraccao de dados Figura adaptada de http gears google com
33
Desenvolvimento
Figura 42 Exemplo de uma arquitectura de uma web application com uma camada deabstraccao de dados Figura adaptada de http gears google com
um mecanismo de armazenamento de dados local seja uma base de dados ou a
capacidade de acesso ao disco No entanto este mecanismo introduz dois problemas
1 Qual das fontes de dados utilizar quando um utilizador faz um pedido de
informacao
2 A necessidade de implementar uma camada de acesso a dados que seja coerente
quer se use o servidor remoto ou local
Por exemplo em vez de a aplicacao Ajax fazer um pedido relativo as contas de
todos os utilizadores em formato JSON directamente ao servidor remoto podera ao
inves fazer o pedido a um objecto intermedio da camada de dados Este objecto
demonstrado na Figura 42 sera responsavel por implementar uma interface de
acesso a base de dados e retornar um objecto JavaScript com uma representacao da
resposta do servidor
Mas a existencia de uma segunda fonte de dados torna recomendavel tambem
a implementacao de uma camada de data switching que em funcao da existencia
de conexao a Internet e da necessidade de actualizacao dos dados decide se faz o
pedido ao servidor remoto ou se fornece os dados presentes localmente Este objecto
apresentado na Figura 43 decidira de forma transparente para o utilizador se le ou
escreve os dados localmente ou se os enviapede ao servidor remoto e pode tambem
iniciar o processo de convergencia de dados e de resolucao de conflitos
411 Funcionalidades disponıveis em modo offline
Por razoes praticas e provavel que nem todas as funcionalidades da aplicacao
possam ser disponibilizadas em modo offline E necessario escolher quais as fun-
cionalidades a disponibilizar no modo offline da aplicacao e implementar a logica
que decide quando utilizar a base de dados local ou o servidor remoto Apesar do
acesso a base de dados local ser muito mais rapido do que aceder ao servidor o
acesso local nem sempre e preferido Ha varias razoes que podem tornar necessario
escolher o acesso ao servidor em vez do acesso local
34
Desenvolvimento
Figura 43 Exemplo de uma arquitectura de uma web application com uma camada deabstraccao de dados e um data switch Figura adaptada de http gears google com
1 A informacao pode ter uma natureza efemera e nao fazer sentido guarda-la
localmente Exemplo dados em tempo real da bolsa de valores de Lisboa
2 Algumas aplicacoes lidam com informacao que so faz sentido na presenca de
uma ligacao Exemplo Instant Messaging
3 A aplicacao podera escolher apenas guardar a informacao acedida mais fre-
quentemente Exemplo para o utilizador poder alterar a lıngua de apre-
sentacao da aplicacao os conteudos terao que ser guardados em todas as
lınguas disponibilizadas pela aplicacao O custo de implementacao de algu-
mas funcionalidades pode nao compensar o benefıcio
4 A capacidade de processamento ou de armazenamento de dados pode inviabi-
lizar algumas funcionalidades offline Exemplo se uma dada funcionalidade
necessita de uma capacidade de armazenamento de dados para alem do razoavel
de um computador pessoal para ser util (visualizador de mapas)
42 Modos de execucao
Um aspecto que e necessario estudar para qualquer web application que se deseje
disponibilizar offline prende-se com tres modos de execucao que devem ser consid-
erados
1 Utilizador decide o modo de execucao A aplicacao tem modos distintos
de execucao para os estados online e offline geralmente indicados na interface
com o utilizador O utilizador e informado do estado da ligacao e participa na
alteracao de estado de execucao da aplicacao interagindo com a sua interface
2 Aplicacao decide o modo de execucao Pode ser implementado na propria
aplicacao um mecanismo de deteccao do estado da ligacao (por exemplo atraves
35
Desenvolvimento
de chamadas Ajax periodicas) transitando de estado e sincronizando automati-
camente Desta forma o utilizador nao precisa de participar na alteracao de
estado a menos que exista um conflito de dados que requeira a sua atencao
3 Aplicacao assume sempre o estado offline Outra hipotese sera imple-
mentar uma web application que assume sempre estar na ausencia de uma
ligacao ao servidor de dados Esta aplicacao responde aos pedidos do uti-
lizador efectuando pedidos de informacao ao servidor mas nao dependendo
de uma resposta valida para mostrar a informacao que ja tinha disponıvel an-
teriormente A sincronizacao de dados com o servidor e tentada sempre que
existam dados para submeter e uma accao do utilizador
421 Modo ldquoutilizador deciderdquo
Neste modo de execucao quando a aplicacao esta online comunica com o servidor
remoto quando esta offline comunica com a base de dados local A informacao tem
que ser sincronizada sempre que se muda de modo A principal vantagem desta opcao
e que e a mais simples de implementar mesmo para uma aplicacao ja existente e
portanto uma forma expedita de disponibilizar uma OWA No entanto tem tambem
algumas desvantagens que devem ser consideradas
1 O utilizador tem que se lembrar de fazer a alteracao de estado de execucao
Caso contrario podera estar a trabalhar inadvertidamente numa versao offline
com dados antigos ou nao ter a informacao necessaria se perder subitamente
a ligacao
2 Se a ligacao for intermitente o utilizador tera ou que escolher um dos modos
de execucao ou estar constantemente a trocar
3 Uma vez que a base de dados nao esta sempre actualizada nao podera ser
utilizada para melhorar a rapidez de execucao da aplicacao quando em modo
online
422 Modo aplicacao decide
A deteccao do estado da ligacao pode ser implementada atraves de um pedido
assıncrono ao servidor tal como ilustrado na Figura 44 O resultado deste pedido
definira o estado online (em caso de sucesso) ou offline (em caso de falha) A
sincronizacao de dados podera ser feita sempre que ocorra uma transicao do es-
tado offline para o estado online No entanto este metodo nao se revela eficiente
36
Desenvolvimento
Figura 44 Esquema grafico ilustrando uma OWA executando no browser utilizando ummodo de execucao do tipo ldquoaplicacao deciderdquo com deteccao automatica do estado daligacao via pedidos Ajax assıncronos a cada cinco segundos
para grandes aplicacoes uma vez que requer a troca de mensagens demasiado fre-
quentes com o servidor que se destinam exclusivamente a monitorizacao do estado
da ligacao
423 Modo ldquoaplicacao assume o estado offlinerdquo
Uma aplicacao transparente funciona assumindo sempre que esta em modo of-
fline ou pelo menos que pode perder a ligacao a qualquer momento Neste modo
tira-se o maximo partido do armazenamento local e fazem-se pequenas mas contınuas
sincronizacoes com o servidor sempre que este esteja disponıvel A sincronizacao de
dados tambem e feita sempre que se volta ao estado online
As vantagens de uma web application transparente sao as seguintes
bull Uma melhor experiencia para o utilizador uma vez que este nao tem que se
preocupar com o estado da ligacao ou com a transicao de estados
bull A aplicacao funciona de forma coerente mesmo que a ligacao seja intermitente
bull Uma vez que o armazenamento local e mantido actualizado pode ser utilizado
para melhorar o desempenho da aplicacao
Foram identificadas as seguintes desvantagens
bull E mais difıcil de implementar e a sincronizacao acarreta cuidados especiais
bull E necessario um cuidado adicional para evitar que as operacoes de sincronizacao
frequentes que ocorrem automaticamente nao afectem os tempos de resposta
da aplicacao
bull Os testes a aplicacao sao mais complexos uma vez que a sincronizacao de dados
nao ocorre em resposta a uma accao do utilizador
37
Desenvolvimento
43 Sincronizacao de dados
A sincronizacao de dados consiste na capacidade de identificar e transferir pe-
riodicamente a versao mais actual dos dados entre o cliente e o(s) servidor(es)
Independentemente do modo de execucao escolhido e mesmo do estado da ligacao
do utilizador a informacao armazenada localmente e a informacao armazenada no
servidor estarao por vezes dessincronizadas Isto podera acontecer sempre que por
exemplo
bull O utilizador faz alteracoes em modo offline
bull A informacao e partilhada e pode ser alterada por uma entidade externa
bull A informacao e fornecida por uma entidade externa
Resolver estas diferencas de forma a que a informacao local e remota encontrem
a igualdade chama-se sincronizacao de dados Ha varias aproximacoes possıveis
para este efeito que dependem da natureza da aplicacao cada uma com vantagens
e desvantagens
A capacidade de suportar a mobilidade dos utilizadores torna-se cada vez um
ponto mais importante de uma web application Para uma organizacao de dimensao
global e vital garantir que os seus colaboradores tem acesso a mesma informacao
que tem disponıvel nos seus postos de trabalho mesmo quando estao fora Na maior
parte dos casos estes colaboradores terao acesso a um computador portatil um
desktop Smartphone ou PDA e atraves destes poderao ter acesso a sua informacao
directamente atraves de ligacoes encriptadas Virtual Private Network (VPN) de um
servidor web ou de outro mecanismo de rede
Esta solucao e simples de implementar mas infelizmente para a maioria dos
colaboradores com grande factor de mobilidade nao e satisfatoria As principais
desvantagens sao as seguintes
bull Requisitos de ligacao Para permitir que os utilizadores acedam a sua in-
formacao e necessario garantir a capacidade constante de comunicacao pelo
menos durante o tempo necessario que assegure a sua transferencia
bull Velocidade de ligacao sem persistencia de dados e em ligacoes de fraca
qualidade a usabilidade por vezes torna-se inaceitavel
bull Ponto crıtico de falha Com este tipo de solucao todos os utilizadores de-
pendem da base de dados que armazena informacao vital para o funcionamento
do cliente
38
Desenvolvimento
bull Scalability do servidor A medida que novos utilizadores sao adicionados ao
sistema o desempenho do servidor e afectado levando a necessidade de maior
capacidade de armazenamento eou processamento
De acordo com a documentacao da Microsoft Sync Framework [Mic08] uma
solucao alternativa consiste em implementar uma Occasionally Connected Appli-
cation (OCA) Uma OCA permite a um utilizador remoto continuar a aceder a
sua informacao mesmo depois de perder a ligacao mas em vez de recorrer a um
servidor recorre a informacao armazenada no seu dispositivo local Para preencher
localmente a informacao que o utilizador necessita uma OCA possui mecanismos
de sincronizacao de dados que sao oferecidos por esta framework
431 Quando sincronizar
Uma das solucoes mais simples de implementar passa por disponibilizar um
mecanismo manual que despoleta a sincronizacao Diz-se manual porque e o uti-
lizador que escolhe quando sincronizar e pode ser implementada simplesmente
fazendo o upload de toda a informacao para o servidor e depois fazendo o download
da copia mais recente da informacao antes de voltar a ficar offline Para que esta
seja uma opcao viavel e necessario que
bull O volume de dados seja suficientemente pequeno para que possa ser transferido
do servidor para o cliente num espaco de tempo aceitavel
bull Que o utilizador indique explicitamente que quer mudar para o estado offline
ou online pressionando um botao da interface
Contudo podem ser identificados alguns problemas relacionados com esta abor-
dagem
bull Os utilizadores nem sempre podem prever o estado das suas ligacoes A ligacao
pode-se perder subitamente ou ter um caracter intermitente
bull O utilizador pode esquecer-se de efectuar a sincronizacao
Outra opcao sera conjugar a sincronizacao de dados com o modo de execucao
transparente A sincronizacao ocorre automaticamente em background de forma
nao intrusiva para o utilizador A aplicacao comunica com o servidor regularmente
efectuando pequenas trocas de dados com o objectivo de manter o sincronismo da
informacao local e remota Esta abordagem pode ser implementada com pedidos
Ajax assıncronos e regulares ao servidor o que permite manter a interaccao com a
interface fluıda evitando bloqueios Estes pedidos sao feitos prevendo as situacoes
39
Desenvolvimento
de disponibilidade ou indisponibilidade (timeout) do servidor Uma outra opcao
sera permitir que o servidor comunique essas alteracoes utilizando Comet1 tal como
descrito em [Wil06] e [Rus06] As vantagens destas aproximacoes sao
bull A informacao esta disponıvel a qualquer altura que o utilizador decida ficar
offline ou que a ligacao seja acidentalmente perdida
bull O desempenho da aplicacao pode ser melhorado quando se estiver a utilizar
uma ligacao a Internet lenta uma vez que o acesso a dados locais e mais
eficiente do que a consulta de dados ao servidor
44 WOW
O WOW e uma plataforma integrada de gestao de ordens de trabalho ja ex-
istente e desenvolvida pela Critical Software SA a qual se pretende adicionar a
capacidade de execucao offline Esta aplicacao e extremamente dinamica e con-
figuravel com um conjunto extremamente rico de funcionalidades das quais se
destacam
bull Gestao de Ordens de Trabalho ndash suportando a gestao dos pedidos desde a
sua criacao ate ao seu fecho tomando em conta os diferentes tipos de pedidos
(ordens de trabalho pedidos de informacao melhorias resolucao de problemas
etc) e diferentes tipos de accoes possıveis para cada um (Figura 45)
bull Monitorizacao de alteracoes ndash Historico de mudancas anexos e estados criando
relatorios de alteracao automaticamente (o que por quem e quando)
bull Uso de Service Level Agreements (SLAs) ndash E possıvel associar a um pedido um
SLA que define qual o perıodo de tempo atribuıdo a resolucao de um pedido
controlando e agilizando a resolucao do mesmo
bull Utilizacao de queries de utilizador configuraveis que permitem acesso rapido
a determinadas ordens de trabalho de acordo com o filtro configurado (por
exemplo ldquoPara mimrdquo ldquoPara o Grupordquo ldquoPelo Grupordquo)
bull Gestao do relacionamento entre pedidos
bull Pesquisa e filtragem de ordens de trabalho
bull Exportacao de dados em formatos padrao (PDF DOC ou XLS)
bull Integravel com solucoes externas
40
Desenvolvimento
Figura 45 Detalhe de um conjunto possıvel de estados e respectivas transicoes para umadada ordem de trabalho no WOW desde a sua submissao no sistema ate a sua conclusaoem fecho ou cancelamento Esta figura representa apenas um exemplo ja que o mapa deestados para uma ordem de trabalho e dinamico e pode ser alterado por um administradorFigura retirada de uma brochura promocional do WOW Critical Software SA
A utilizacao de uma ferramenta deste tipo por parte de uma empresa ou orga-
nizacao oferece vantagens quer a gestao de topo quer aos colaboradores individuais
para os colaboradores individuais o WOW e uma aplicacao onde estao registadas
todas as tarefas contribuindo activamente para o desenvolvimento em ambientes
multi-tarefa e para a organizacao pessoal das tarefas de acordo com prioridades
Para a gestao de topo esta ferramenta permite obter uma visao global do estado da
organizacao em termos de tempo gasto por tarefa executada sendo uma mais valia
para a previsao e gestaoalocacao de recursos
45 Visao geral sobre a arquitectura do WOW
O WOW e interessante nao so do ponto de vista de produto como tambem do
ponto de vista de plataforma Existem diversos plug-ins que estendem as funcional-
idades do WOW e existem ate projectos que pretendem usar a arquitectura do
WOW para criar produtos com fins diferentes do inicial (por exemplo o WOW-
Storm ndash um sistema de registo e classificacao social de ideias)
De modo a conseguir ter essa expansibilidade a plataforma WOW assenta sob
uma arquitectura distribuıda modular e expansıvel com uma componente central
ndash o core ndash estruturado em camadas logicas E no core que se situam todas as
1O Comet e um conceito semelhante ao Ajax introduzido por Alex Russel mas no qual e o servidor quetoma a iniciativa de ldquoenviarrdquo os dados ao browser sem que este tenha que efectuar um pedido Tambem econhecido por Ajax Push Reverse Ajax ou HTTP Streaming
41
Desenvolvimento
funcionalidades base da aplicacao quer a nıvel logico funcional e de apresentacao
quer a nıvel de gestao e configuracao
E possıvel a execucao de varias instancias do core simultaneamente em servidores
distintos o que permite a alta escalabilidade e disponibilidade desta aplicacao A
consistencia dos dados fica sempre garantida atraves da partilha da base de dados
e pelo balanceamento dos pedidos uma vez que cada um e encaminhado para uma
unica instancia
O WOW apresenta tambem a vantagem de ser uma plataforma extensıvel E
possıvel adicionar novas caracterısticas a plataforma atraves de componentes que se
podem ser divididos em duas categorias plugins e connectors
Os plugins sao componentes que se encontram no mesmo no fısico que a aplicacao
partilhando do mesmo contexto de execucao do core Sao assim uma forma mais
directa de obter informacao da plataforma visto que nao possuem restricoes de
acesso aos dados nem dependencias externas A arquitectura deste componente tera
assim que permitir varias execucoes instanciadas cada uma associada a um core
Por outro lado os connectors sao componentes que se encontram distribuıdos
comunicando externamente com o core Quer a sua execucao quer a obtencao
dos dados estao assim dependentes de interfaces de comunicacao externas que a
plataforma disponibiliza Estes componentes ao contrario dos plugins sao instan-
ciados unicamente e recorrem ao protocolo de comunicacao Java Messaging Service
(JMS) para comunicar com o core
46 WOW Offline
Para alem das opcoes tomadas relativamente a tecnologia a utilizar surgiu
tambem a necessidade de optar por um dos modos de execucao apresentados na
seccao 42
Das tres opcoes possıveis foi o modo ldquoaplicacao assume o estado offlinerdquo descrito
na seccao 423 que mereceu a maior atencao uma vez que reune as vantagens de
uma experiencia mais positiva para o utilizador (uma vez que este nao tem que
participar activamente na alteracao do modo execucao como descrito na seccao 421)
e nao constitui uma sobrecarga excessiva para servidor (como o modo abordado na
seccao 422)
No entanto esta opcao comprometia a complexidade da implementacao para alem
dos objectivos propostos para este projecto e para cumprir o prazo dado foi tomada
a decisao de implementar o modo ldquoutilizador deciderdquo especificando apenas de forma
teorica o modo ldquoaplicacao assume o estado offlinerdquo
As caracterısticas do Gears foram ja descritas na seccao 31 Na Figura 47
mostra-se a sua forma de funcionamento quando integrado numa web application
42
Desenvolvimento
Nesta figura representa-se o modulo LocalServer do Gears como um ponto de de-
cisao Aqui sao testadas as condicoes que determinam se o pedido sera interceptado e
servido localmente ou se prossegue para uma maquina remota E tambem represen-
tada uma base de dados que corresponde ao modulo Database mas que podera nao
ser utilizada Este modulo tal como o modulo Workerpool tem caracter opcional
e sao utilizados consoante os requisitos da aplicacao
A plataforma WOW lida com mais dados do que e necessario passar para o
lado do cliente Em conformidade com o ja exposto na seccao 411 volta-se a
frisar que nao se pretende recriar toda a logica de negocio nem os conteudos da
base de dados no cliente pela sua complexidade e volume de dados Pretende-se
pelo contrario permitir que os utilizadores tirem partido da capacidade de poder
consultar as suas ordens de trabalho quando nao dispoe de uma ligacao transferindo
apenas o essencial para isto seja possıvel
A pagina inicial do WOW apresenta um resumo das ordens de trabalho abertas
ndash enviadas e recebidas ndash que se pretende permitir visualizar offline (ver Figura 46)
Como prova de conceito foi efectuada uma abordagem pragmatica das varias possi-
bilidades descritas na seccao 42
461 Modo ldquoaplicacao deciderdquo com deteccao automatica da ligacao
A primeira abordagem estudada para a disponibilizacao das funcionalidades of-
fline foi o modo ldquoaplicacao deciderdquo com deteccao automatica de ligacao apresentado
na seccao 422 Para que isto seja possıvel foi implementado um mecanismo de ver-
ificacao periodica do estado da ligacao atraves de chamadas Ajax assıncronas O
resultado destes pedidos determina o estado da aplicacao executando as tarefas de
sincronizacao de dados sempre que pertinente Este metodo embora imediato e
simples de implementar depressa se revelou inadequado para o projecto devido ao
elevado consumo de recursos do servidor que a utilizacao intensiva faz esperar a
comunidade da plataforma WOW no principal cliente excede os 7000 utilizadores
Foi estimado que para uma utilizacao de fluidez aceitavel o estado da ligacao deveria
ser testado a cada cinco segundos Assumindo uma adesao (previsao pessimista) de
1 aos servicos offline assistir-se-ia a cerca de 840 pedidos adicionais por minuto
Mas o principal problema desta aproximacao prende-se com o facto de a ver-
ificacao ser feita em intervalos de tempo discretos levando a possibilidade de a
aplicacao poder ter em dado momento uma representacao errada do seu estado
real da ligacao Este problema e ilustrado na Figura 48 onde se ve claramente a
discrepancia entre o estado real da ligacao e a representacao interna que esta tem
Note-se que nesta janela de tempo qualquer accao do utilizador que exija uma
resposta sıncrona do utilizador leva-lo-a para um ldquobeco sem saıdardquo onde nao tera
43
Desenvolvimento
Figura 46 A pagina inicial do WOW apresenta um resumo das ultimas ordens de trabalhoenviadas e recebidas Na imagem pode-se observar a transicao do estado online para offline
acesso a versao offline porque a aplicacao nao fez a transicao automatica nem acesso
a versao online porque na verdade nao possui uma ligacao O que acontecera nesta
situacao sera uma tentativa de acesso ao servidor por parte da aplicacao numa
altura em que este se encontra indisponıvel e o resultado sera uma mensagem de
ldquopedido excedeu o tempordquo apresentado pelo browser Este e um estado sem retorno
porque apos o browser apresentar esta mensagem todos os recursos JavaScript ficam
indisponıveis tornando impossıvel o regresso ao estado anterior ou o tratamento do
erro de qualquer outra forma No entanto as chamadas Ajax podem ser tratadas de
forma especial para a eventualidade de falha e portanto nao constituem problema
44
Desenvolvimento
Figura 47 Ilustracao do funcionamento do Gears numa web application que utiliza ummotor Ajax Os pedidos HTTP ou HTTPS podem ser interceptados e tratados localmenteou podem ser feitos a uma maquina remota consoante se verificarem ou nao as condicoesexpressas no ponto 311 E representado um acesso a uma base de dados local (fornecidapelo Gears) mas a sua utilizacao e opcional
462 Implementacao do modo ldquoutilizador deciderdquo
Este modo de execucao foi ja descrito na seccao 421 e a sua principal carac-
terıstica e ser o utilizador a decidir se a aplicacao deve utilizar um servidor remoto
ou a maquina local como fornecedor de dados
Relativamente ao WOW o WOW Offline na vertente ldquoutilizador deciderdquo vem
alterar os seus casos de uso dando ao utilizador a possibilidade de alterar o estado
de execucao da aplicacao (entre online e offline) Resta dizer que no modo online se
mantem todas as funcionalidades anteriores e que no modo offline torna-se possıvel
visualizar os conteudos da pagina principal do WOW (Figura 46) e os detalhes das
ordens de trabalho (Figura 49) tal como expressa a Figura 410
Esta aproximacao foi utilizada na prova de conceito do WOW adicionando um
controlo a interface desta aplicacao que permite ao utilizador alternar entre os esta-
dos online e offline Na transicao de online para offline sao descarregados os recursos
necessarios para a execucao desta aplicacao sem recorrer a Internet Para o fazer
45
Desenvolvimento
Figura 48 Neste exemplo do modo ldquoaplicacao deciderdquo o teste da ligacao e feito e feito acada cinco segundos O resultado deste teste nao reflecte sempre o estado real da aplicacaopodendo levar a aplicacao a ter comportamentos indesejaveis Na figura assinala-se umperıodo de tempo no qual a representacao interna do estado da ligacao nao corresponde arealidade
e utilizado um recurso ResourceStore e um ManagedResourceStore (introduzidos
em 311) O primeiro e utilizado para armazenar a pagina principal do WOW ndash do-
ravante designada por homejsp ndash e o segundo e utilizado para armazenar imagens
folhas de estilo CSS e scripts JavaScript
Para a implementacao deste modo de execucao foram identificadas as seguintes
tarefas
1 Guardar informacao que permita a recriacao das paginas que se pretende
disponibilizar offline (utilizando o Gears)
2 Disponibilizar um controlo que permita alterar o estado de execucao atraves
da interaccao com a pagina principal
3 Durante a sincronizacao de dados apresentar o progresso da transferencia de
dados
O primeiro passo consistiu na identificacao de todos os conteudos que sao necessarios
transferir para a execucao offline Foi utilizado um recurso do Gears do tipo
ManagedResourceStore que recorre a um ficheiro manifesto para identificar to-
dos os ficheiros que deve transferir Este recurso e gerido automaticamente pelo
Gears transferindo para o cliente a versao mais recente sempre que e necessario
isto e sempre que exista um ficheiro manifesto com uma identificacao de versao que
seja diferente da actualmente disponıvel no cliente Uma vez identificados todos
ficheiros necessarios para a execucao offline num (ou mais) ficheiros manifesto o
Gears encarrega-se da sua actualizacao mas o preenchimento destes ficheiros man-
ifesto e manual o que se traduz num cuidado extra na manutencao da aplicacao
A forma como esta informacao e guardada deve tambem ser cuidadosamente
estudada A opcao mais flexıvel passa por utilizar o modulo Database apresentado
na seccao 311 e guardar a informacao de uma forma relacional Para a recriacao
das paginas pode ser disponibilizada uma versao HTML da pagina que funciona
46
Desenvolvimento
Figura 49 Pagina de visualizacao do detalhe de uma ordem de trabalho
como template nao possui quaisquer dados e e utilizada apenas em modo offline E
preenchida para cada pedido retirando os dados relevantes da base de dados
O modelo de dados do WOW torna esta opcao extremamente trabalhosa uma
vez que as entidades envolvidas na geracao de cada pagina de informacao sobre
cada ordem de trabalho tem relacoes de dependencia complexas seguindo padroes
muito variaveis Por exemplo em cada ordem de trabalho existe um formulario que
permite a sua progressao de estado com diversos campos opcionais e obrigatorios
este formulario e definido pelo administrador e esta relacionado nao apenas com o
tipo de ordem de trabalho mas tambem com o estado actual em que esta se encontra
e a accao que se pretende realizar O elevado numero de combinacoes de tipos de
ordem de trabalho estados e accoes que existem num dado momento juntamente
com a sua possibilidade de alteracao obrigariam a implementacao de uma logica de
negocio complexa o que esta fora do ambito deste projecto
47
Desenvolvimento
Figura 410 Esquema UML que expressa os casos de uso do WOW Offline no modoldquoutilizador deciderdquo
463 Especificacao do modo ldquoaplicacao assume o estado offlinerdquo
A aproximacao para o modo ldquoaplicacao assume o estado offlinerdquo foi tambem
dividida em varias tarefas
1 Guardar informacao que permita a recriacao da pagina principal do lado do
cliente no estado offline (utilizando o Gears)
2 Dotar a aplicacao do cliente de um mecanismo de deteccao da ligacao
3 Identificar os ldquomomentos chaverdquo em que devera ocorrer sincronizacao de dados
4 Implementar a sincronizacao de dados
A sincronizacao de dados deve ser feita em ambas as transicoes online-offline e
offline-online quer para transferir novos dados do servidor (os pedidos podem ser
alterados por outros utilizadores) quando se transita do estado quer para comunicar
eventuais alteracoes feitas em modo offline
Relativamente ao WOW o WOW Offline na vertente ldquoaplicacao assume o es-
tado offlinerdquo vem alterar os seus casos de uso dando ao utilizador a possibilidade
de activar esta funcionalidade A partir do momento que a funcionalidade esta ac-
tivada o utilizador deve tambem ter a possibilidade de gerir algumas preferencias
relacionadas com privacidade de dados Devera ter a hipotese de desactivar o ar-
mazenamento local e de remover todos os dados ja armazenados tal como descrito
na Figura 411
48
Desenvolvimento
Figura 411 Esquema UML que expressa os casos de uso do WOW Offline no modoldquoutilizador deciderdquo
A primeira vez que o WOW Offline e acedido por um cliente e caso seja detec-
tada a presenca do Gears todos os recursos necessarios a sua execucao sao trans-
feridos Todos os acessos posteriores serao feitos a estes recursos locais (recorda-se
que o Gears pode ser utilizado para os manter actualizados recorrendo ao Managed-
ResourceStore 311)
Atraves do JavaScript e possıvel interceptar os eventos de load e unload da
pagina que sao despoletados sempre que ocorre um re-acesso da mesma (incluindo
a accao refresh comum dos browsers) sempre que esta e abandonada ou ainda ou
ainda se a janela for encerrada
Tal como sugerido na seccao 462 a camada de interface desta aplicacao (cada
pagina individual em HTML) devera ser implementada como sendo um template
para apresentacao de dados sendo totalmente preenchida atraves de funcoes em
JavaScript O objectivo deste ponto e criar um padrao de dados que permita ao
JavaScript preencher os dados em cada pagina (template) independentemente de
qual seja a fonte ndash o servidor remoto ou a maquina local tal como exemplificado
no diagrama da Figura 412 Na figura a aplicacao recorre ao servidor remoto para
obter os dados pretendidos quando se encontra na presenca de uma ligacao mas
para dados que exijam uma carga de processamento pelo servidor este acto pode ser
49
Desenvolvimento
Figura 412 Esquema UML que expressa o acto de recolha de dados em modo online eoffline recorrendo ao servidor (modo online) e ao sistema de armazenamento de dadoslocal fornecido pelo Gears (modo offline)
substituıdo pelo envio de um campo de controlo que se destina a aferir se os dados
locais se encontram actualizados No caso de estarem actualizados a comunicacao
com o servidor pode ser substituıda por uma query a base de dados local
50
Capıtulo 5
Resultados e Futuros
Desenvolvimentos
Todo o estudo feito sobre o tema OWA foi ja abordado ao longo do documento
Neste capıtulo apresentam-se os resultados obtidos na implementacao da prova de
conceito que visava compreender a melhor forma de disponibilizar uma versao of-
fline no WOW uma plataforma de gestao de ordens de trabalho ja existente de-
senvolvida pela Critical Software SA
51 Resultados Obtidos
Os resultados obtidos neste projecto sao extremamente satisfatorios uma vez
que o estudo do tema OWA e a implementacao de uma prova de conceito que o
ilustrasse foi conseguido com sucesso
A funcionalidade offline foi adicionada ao produto WOW da Critical Software
SA permitindo a visualizacao de ordens de trabalho e dos seus detalhes mesmo na
ausencia de uma conexao activa a Internet Embora para a solucao implementada
tenha sido utilizada uma abordagem do tipo ldquoutilizador deciderdquo pretende-se que esta
seja convertida para ldquoaplicacao deciderdquo ou mesmo para uma aproximacao hıbrida
semelhante a utilizada pelas aplicacoes estudadas nas seccoes 351 e 352
Para a sua implementacao descrita no capıtulo 4 foram tomadas decisoes de or-
dem pratica que permitissem tornar o trabalho exequıvel nos prazos dados Tentou-
se sempre que estas decisoes afectassem o mınimo em termos de desempenho e de
experiencia para o utilizador Considera-se que a implementacao do modo offline
com uma transicao entre modos do tipo ldquoutilizador deciderdquo (ver seccao 42) reflecte
o compromisso entre o desempenho pretendido e os recursos disponıveis e para alem
51
Resultados e Futuros Desenvolvimentos
de ser um exemplo eficaz das possibilidades que as OWA podem trazer a aplicacao
WOW desenvolvida pela Critical Software e tambem um estudo que pode ser uti-
lizado para analisar a implementacao desta tecnologia noutros produtos da mesma
empresa
Note-se que o principal objectivo do trabalho era ganhar familiaridade com este
tema entender as suas vantagens e desvantagens e compreender as suas limitacoes
Tudo indica que existam varias possibilidades de implementacao deste paradigma
noutros produtos da Critical Software que pela sua natureza podem tambem tirar
partido da execucao offline
52 Trabalho Futuro
O desenvolvimento do conceito e formas de implementacao de OWA continua
em forte desenvolvimento no entanto a sua adopcao ainda nao e generalizada A
dificuldade da sua implementacao em web applications ja existentes e o principal
obstaculo a sua maior divulgacao
Ha tambem um factor que deve ser tido em consideracao a manutencao de
codigo A implementacao de uma versao offline de uma web application requer
a implementacao das mesmas regras de negocio (ou de uma versao simplificada)
utilizadas no servidor Para que isto seja possıvel e necessario ter em conta a
capacidade de processamento do cliente e o factor de duplicacao de codigo que
tornara a aplicacao mais difıcil de manter uma vez que uma alteracao a logica de
negocio do servidor implica tambem uma alteracao a sua versao offline
A prova de conceito implementada permite ja a visualizacao offline dos pedidos
abertos (enviados e recebidos) que constam na pagina principal (este numero e
fixo e pode ser alterado pelo administrador) Uma funcionalidade desejavel seria a
possibilidade de interaccao com a aplicacao em modo offline e sincronizacao com o
servidor quando existisse uma ligacao disponıvel
Foi estudada a utilizacao do modo de execucao ldquoaplicacao assume o estado of-
flinerdquo descrito em 423 e esta seria a forma desejavel para o WOW Offline no
entanto para que esta opcao seja viavel sera necessaria a implementacao de uma
forma eficiente de sincronizacao e armazenamento de dados de uma forma relacional
Para atingir este objectivo podera ser seguida uma polıtica de automacao do pro-
cesso no qual a versao online da aplicacao gera scripts de criacao para as tabelas
necessarias na base de dados da versao offline (nao existe nenhuma ferramenta para
o fazer portanto seria necessaria a sua implementacao) e no qual as paginas HTML
disponibilizadas pelo servidor aos clientes web (browser) servem como templates de
apresentacao de informacao e sao preenchidas de forma semelhante pelo servidor ndash
quando a aplicacao estiver online ndash ou pelo cliente atraves de funcoes em JavaScript
52
Resultados e Futuros Desenvolvimentos
ndash quando a aplicacao estiver offline No entanto no WOW devido a quantidade de
informacao tratada e devido as complexas relacoes entre as diferentes entidades e
de esperar que a complexidade da implementacao de um mecanismo deste tipo torne
esta aproximacao demasiado custosa
O HTML 5 embora um forte candidato ainda nao esta suficientemente desen-
volvido A sua especificacao ainda tem o caracter de Draft (rascunho) e esta sujeita
a modificacoes e a aceitacao e implementacao por parte dos browsers e portanto
de momento foi desconsiderado No entanto no futuro se esta especificacao atingir
um estado de maturidade que permita a sua adopcao devera ser considerada como
um possıvel caminho a seguir
53
Resultados e Futuros Desenvolvimentos
54
Capıtulo 6
Conclusoes
Neste capıtulo sao apresentadas as conclusoes do projecto e consideracoes finais
relativamente a tecnologia estudada
61 Conclusoes
O rapido desenvolvimento tecnologico faz prever que a disponibilidade de ligacao
a Internet seja cada vez mais facil e mais rapido mas vao continuar a existir lugares
onde o acesso e limitado e onde as OWA podem desempenhar um papel de relevo
Por outro lado esta tecnologia pode tambem ser utilizada para melhorar o desem-
penho de paginas web com uma necessidade elevada de imagens ou outros recursos
dispendiosos em termos de espaco e foram ate estudados dois exemplos da utilizacao
desta vertente desta tecnologia em 353
Acredita-se que as OWAs vem responder a uma necessidade real por parte das
web applications actuais e que a evolucao que representam se compara a que se
assistiu dos thin-clients para os fat-clients em termos de autonomia do servidor
A capacidade de oferecer conteudos dinamicos no browser independentemente da
existencia de uma ligacao reune as vantagens tıpicas das web applications como
ausencia de instalacao e actualizacoes instantaneas com as vantagens das aplicacoes
de desktop em capacidade de processamento e armazenamento de dados na maquina
local
As tecnologias disponıveis ate a data estudadas no ambito deste projecto que
permitem o desenvolvimento de OWAs e que apresentam maior maturidade sao o
Gears e o Adobe AIR Ambas se apresentam sobre a forma de plugins que necessitam
de uma instalacao extra para poderem ser utilizadas Apesar de esta instalacao ser
55
Conclusoes
apenas necessaria uma vez podera constituir um factor de desencorajamento a sua
adopcao
O HTML 5 uma especificacao abordada neste documento na seccao 34 podera
ser uma alternativa que oferece funcionalidades offline a uma web application sem a
necessidade de qualquer instalacao no entanto esta especificacao ainda nao foi aceite
pelos principais browsers ndash o documento que define o HTML 5 ainda tem o estatuto
de Draft ndash e ainda nao e possıvel antecipar quando e que isto podera acontecer
Um dos problemas que surge frequentemente na implementacao de uma versao
offline para uma web application e a necessidade de sincronizacao de dados Quando
a informacao pode ser alterada por varios utilizadores simultaneamente e necessario
prever os conflitos que daı podem surgir e dotar a aplicacao de uma forma de os
resolver ou alertar o utilizador para a necessidade de alteracao dos dados
Em conclusao todos os objectivos propostos para este projecto foram atingidos
A prova de conceito implementada reflecte de forma clara as possibilidades oferecidas
pela tecnologia OWA e sera utilizado no futuro para compreender a melhor forma
de o implementar de forma definitiva no WOW
56
Referencias
[Ada08] Lucas Adamski Introducing Adobe AIR security model Fevereiro de2008 Disponıvel em httpwwwadobecomdevnetairarticles
introduction_to_air_securityhtml acedido em Marco de 2008
[Ado08] Adobe Adobe AIR 10 Security White Paper 2008 Disponıvel emhttpdownloadmacromediacompubairdocumentation1air_
securitypdf acedido em Marco de 2008
[Alm08] Dion Almaer Gears as a bleeding-edge html 5 implementa-tion March 2008 Disponıvel em httpalmaercomblog
gears-as-a-bleeding-edge-html-5-implementation acedido emMarco de 2008
[BL96] Tim Berners-Lee The world wide web Past present and future Agostode 1996 Disponıvel em httpwwww3orgPeopleBerners-Lee
1996ppfhtml acedido em Abril de 2008
[CDGH08] Mike Chambers Daniel Dura Dragos Georgita and Kevin Hoyt AdobeAIR for JavaScript Developers OrsquoReilly Media 2008 Disponıvel emhttponairadobecomfilesAIRforJSDevPocketGuidepdf ace-dido em Abril de 2008
[Con99] Jim Conallen Modeling Web Application Architectures with UML Junho1999 Disponıvel em httpwwwumlorgcnUMLApplicationpdf
webappspdf acedido em Maio de 2008
[Ent07] Entrust What is a public key information 2007 Disponıvel em http
wwwentrustcompkihtm acedido em Junho de 2008
[Gar05] Jesse James Garret Ajax A new approach to web applicationsFebruary 2005 Disponıvel em httpwwwadaptivepathcomideas
essaysarchives000385php acedido em Marco de 2008
[Greon] Philip Greenspun Philip and Alexrsquos Guide to Web Publishing 2003(last revision) Disponıvel em httpphilipgreenspuncompandaacedido em Junho de 2008
[Gro02a] App Design Group Thick vs thin client comparison 2002 Disponıvelem httpwwwdonjacobsvwcomimagesweekendspecials
Thick-vs-Thinpdf acedido em Junho de 2008
57
REFERENCIAS
[Gro02b] Technical Research Group Thin Client Tecnhology - WhitePaper 2002 Disponıvel em httpwwwpicktrgcompubs
thinclientwhitepaperpdf acedido em Junho de 2008
[Gro08] Miniwatts Marketing Group World internet usage March 2008Disponıvel em httpwwwinternetworldstatscomstatshtm ace-dido em Abril de 2008
[Hic08] Ian Hickson HTML 5 Draft Recommendation 2008 Disponıvelem httpwwwwhatwgorgspecsweb-appscurrent-work ace-dido em Marco de 2008
[Kha] Olga Kharif Top 10 municipal wifi plans Disponıvel em http
imagesbusinessweekcomss0608muni_wifiindex_01htm ace-dido em Marco de 2008
[Lab07] Mozilla Labs Prism Outubro 2007 Disponıvel em httplabs
mozillacom200710prism acedido em Marco de 2008
[Loo06] Chris Loosley Rich Internet ApplicationsDesign MeasurementandManagement Challenges 2006 Disponıvel em httpwwwkeynote
comdocswhitepapersRichInternet_5pdf acedido em Maio de2008
[Mic08] Microsoft Introduction to Occasionally Connected Applications us-ing Sync Services for ADONET 2008 Disponıvel em httpmsdn
microsoftcomen-ussyncbb887608aspx acedido em Junho de2008
[Nao08] Erica Naone Offline web applications Abril 2008 Disponıvelem httpwwwtechnologyreviewcomread_articleaspxch=
specialsectionsampsc=emerging08ampid=20245 acedido emAbril de 2008
[NJN00] Jason Nieh Yang S Jae and Naomi Novik A comparison of thin-clientcomputing architectures 2000 Disponıvel em httpwwwnclcs
columbiaedupublicationscucs-022-00pdf acedido em Maio de2008
[OrsquoR06] Tim OrsquoReilly Web 20 compact definition Trying again Dezembro2006 Disponıvel em httpradaroreillycomarchives200612
web-20-compact-definition-tryihtml acedido em Marco de 2008
[OrsquoR09] Tim OrsquoReilly What is Web 20 Design patterns and business modelsfor the Next Generation of Software 20053009 Disponıvel emhttpwwworeillynetcompubaoreillytimnews200509
30what-is-web-20html acedido em Marco de 2008
[Rus06] Alex Russel Comet Low latency data for the browser March Marco2006 Disponıvel em httpalexdojotoolkitorgp=545 acedidoem Marco de 2008
58
REFERENCIAS
[Sad97] Darleen Sadoski Clientserver software architecturesndashan overviewAgosto 1997 Disponıvel em httpwwwseicmuedustr
descriptionsclientserver_bodyhtml acedido em Junho de2008
[Sch96] George Schussel Clientserver past present and future 1996
[Smi07] Kevin C Smith Css filters - will the browser apply the rule July 2007Disponıvel em httpcentriclecomrefcssfilters acedido emMarco de 2008
[vK08] Anne van Kesteren The XMLHttpRequest Object W3C Work-ing Draft 15 Abril 2008 Disponıvel em httpwwww3orgTR
XMLHttpRequest acedido em Abril de 2008
[Wil06] Greg Wilkins Why ajax comet July Julho 2006 Disponıvel emhttpwwwwebtidecomdownloadswhitePaperWhyAjaxhtml ace-dido em Abril de 2008
59
REFERENCIAS
60
Anexo A
Screenshots
Algumas imagens de aplicacoes que utilizam funcionalidades offline ilustrativasda tecnologia abordada neste documento
Figura A1 Dialogo apresentado ao utilizador na primeira activacao das funcionalidadesoffline no Google Docs amp Spreadsheets
61
Screenshots
Figura A2 Na activacao das funcionalidades offline e tambem oferecida a possibilidadeda criacao de alguns atalhos por exemplo no ambiente de trabalho
Figura A3 O Google Docs mantem a todo o momento a possibilidade de alteracao destasdefinicoes ou da anulacao dos servicos offline para um dado computador
62
Screenshots
Figura A4 Apos a instalacao do Gears qualquer visita ao Remember The Milk despoletauma sincronizacao que ocorre automaticamente e sem necessidade de intervencao por partedo utilizador
Figura A5 Apos completar a sincronizacao de dados mesmo que a ligacao a Internetseja perdida o Remember the Milk continua disponıvel no browser (com excepcao dasfuncionalidades que pela sua natureza exigem uma ligacao como por exemplo partilhade tarefas e envio de convites)
63
CONTEUDO
4 Desenvolvimento 3341 Como ficar offline 33
411 Funcionalidades disponıveis em modo offline 3442 Modos de execucao 35
421 Modo ldquoutilizador deciderdquo 36422 Modo aplicacao decide 36423 Modo ldquoaplicacao assume o estado offlinerdquo 37
43 Sincronizacao de dados 38431 Quando sincronizar 39
44 WOW 4045 Visao geral sobre a arquitectura do WOW 4146 WOW Offline 42
461 Modo ldquoaplicacao deciderdquo com deteccao automatica da ligacao 43462 Implementacao do modo ldquoutilizador deciderdquo 45463 Especificacao do modo ldquoaplicacao assume o estado offlinerdquo 48
5 Resultados e Futuros Desenvolvimentos 5151 Resultados Obtidos 5152 Trabalho Futuro 52
6 Conclusoes 5561 Conclusoes 55
Referencias 59
A Screenshots 61
viii
Lista de Figuras
21 Arquitectura de um sistema thin-client em duas camadas (a esquerda)e em tres camadas (a direita) Note-se a inclusao do servidor (main-frame) na definicao das camadas desta arquitectura devido a fortedependencia cliente-servidor 9
22 Arquitectura de um fat-client em duas camadas (a esquerda) e emtres camadas (a direita) 10
23 Comparacao do modelo de web aplications sıncrono paginas estaticase interactivas abordados nas seccoes 221 e 222 com o modelo deweb applications Ajax (assıncrono) abordado na seccao 223 Figuraadaptada de http www adaptivepath com 15
31 Esquema UML do processo efectuado pelos recursos do Gears do tipoManagedResourceStore para a actualizacao dos conteudos definidosno ficheiro manifesto 29
41 Exemplo de uma arquitectura de uma web application sem uma ca-mada de abstraccao de dados Figura adaptada de http gears
google com 33
42 Exemplo de uma arquitectura de uma web application com uma ca-mada de abstraccao de dados Figura adaptada de http gears
google com 34
43 Exemplo de uma arquitectura de uma web application com uma ca-mada de abstraccao de dados e um data switch Figura adaptada dehttp gears google com 35
44 Esquema grafico ilustrando uma OWA executando no browser uti-lizando um modo de execucao do tipo ldquoaplicacao deciderdquo com de-teccao automatica do estado da ligacao via pedidos Ajax assıncronosa cada cinco segundos 37
45 Detalhe de um conjunto possıvel de estados e respectivas transicoespara uma dada ordem de trabalho no WOW desde a sua submissaono sistema ate a sua conclusao em fecho ou cancelamento Esta figurarepresenta apenas um exemplo ja que o mapa de estados para umaordem de trabalho e dinamico e pode ser alterado por um admin-istrador Figura retirada de uma brochura promocional do WOWCritical Software SA 41
ix
LISTA DE FIGURAS
46 A pagina inicial do WOW apresenta um resumo das ultimas ordensde trabalho enviadas e recebidas Na imagem pode-se observar atransicao do estado online para offline 44
47 Ilustracao do funcionamento do Gears numa web application que uti-liza um motor Ajax Os pedidos HTTP ou HTTPS podem ser inter-ceptados e tratados localmente ou podem ser feitos a uma maquinaremota consoante se verificarem ou nao as condicoes expressas noponto 311 E representado um acesso a uma base de dados local(fornecida pelo Gears) mas a sua utilizacao e opcional 45
48 Neste exemplo do modo ldquoaplicacao deciderdquo o teste da ligacao e feitoe feito a cada cinco segundos O resultado deste teste nao reflectesempre o estado real da aplicacao podendo levar a aplicacao a tercomportamentos indesejaveis Na figura assinala-se um perıodo detempo no qual a representacao interna do estado da ligacao nao cor-responde a realidade 46
49 Pagina de visualizacao do detalhe de uma ordem de trabalho 47410 Esquema UML que expressa os casos de uso do WOW Offline no
modo ldquoutilizador deciderdquo 48411 Esquema UML que expressa os casos de uso do WOW Offline no
modo ldquoutilizador deciderdquo 49412 Esquema UML que expressa o acto de recolha de dados em modo
online e offline recorrendo ao servidor (modo online) e ao sistemade armazenamento de dados local fornecido pelo Gears (modo offline) 50
A1 Dialogo apresentado ao utilizador na primeira activacao das funcional-idades offline no Google Docs amp Spreadsheets 61
A2 Na activacao das funcionalidades offline e tambem oferecida a possi-bilidade da criacao de alguns atalhos por exemplo no ambiente detrabalho 62
A3 O Google Docs mantem a todo o momento a possibilidade de alteracaodestas definicoes ou da anulacao dos servicos offline para um dadocomputador 62
A4 Apos a instalacao do Gears qualquer visita ao Remember The Milkdespoleta uma sincronizacao que ocorre automaticamente e sem ne-cessidade de intervencao por parte do utilizador 63
A5 Apos completar a sincronizacao de dados mesmo que a ligacao aInternet seja perdida o Remember the Milk continua disponıvel nobrowser (com excepcao das funcionalidades que pela sua naturezaexigem uma ligacao como por exemplo partilha de tarefas e enviode convites) 63
x
Lista de Tabelas
21 Comparacao entre thin-clients e fat-clients 7
31 Comparacao das funcionalidades oferecidas pelo Adobe AIR para asplataformas web e desktop 30
32 Resumo da utilizacao de tecnologias OWA em algumas web applica-tions consideradas na analise do estado da arte 31
xi
LISTA DE TABELAS
xii
Glossario
fat-client Cliente que nao depende totalmente de umservidor central para as suas actividadesde processamento e possui frequentementedispositivos de armazenamento de dados
6ndash8
thin-client Cliente que depende de um servidor centralpara as suas actividades de processamento
5ndash8
web application Sistema web (servidor rede HTTPbrowser) onde accoes do utilizador(navegacao e introducao de informacao)afectam o estado logico da aplicacao
i iii1ndash311ndash1517ndash1921ndash232728 3336ndash3842 5556
API Application Programming Interface 10 1718 2326 28
ASP Linguagem interpretada pelo servidorque permite a criacao de paginas webdinamicas Desenvolvida pela Microsoft
11
BSD Berkeley Software Distribution 28
CSS Cascading Style Sheets 12 2021 2324 46
DHTML Dynamic HyperText Transfer Protocol 24DOM Document Object Model 10 12
20 2324
DTD Document Type Definition 24
xiii
Glossario
ECMAScript Padrao de linguagem de programacaodefinido pela Ecma International que orig-inou o JavaScript e o JScript
24
Flash Conteudo interactivo de um ficheiro emformato SWF E desenvolvido pela Adobee visualizado atraves do Adobe FlashPlayer
21
Flex Framework baseada em XML e Action-Script desenvolvida pela Adobe para a pro-gramacao de Rich Internet Applications(RIA)
21
GPL GNU General Public License 23
HTML HyperText Markup Language 1 10ndash12 2124ndash2649
HTTP HyperText Transfer Protocol 2 26
JMS E uma API em Java que permite a troca demensagens entre componentes de software
42
JSON JavaScript Object Notation permite atroca de dados codificados num formatode texto de simples leitura
12 1828 34
LGPL GNU Lesser General Public License 23
Mozilla Prism Browser simplificado e ldquointerpretadorrdquo deeXtensible User Interface Language (XUL)(tambem designado por XULRunner) queacolhe web applications sem a interfacegrafica habitual de um browser
25
MPL Mozilla Public License 23
OCA Occasionally Connected Application 39OWA Offline Web Application i iii
2ndash515 1725 2628 3133 3651 5255 56
PDF Portable Document Format 21
xiv
Glossario
PHP Linguagem interpretada pelo servidorque permite a criacao de paginas webdinamicas mas que pode tambem ser in-vocada a partir da linha de comandos
11
pagina web estatica Pagina web que devolve sempre a mesmaresposta a todos os pedidos para todos osutilizadores e em qualquer contexto
5 9
RIA Rich Internet Applications web appli-cations que apresentam funcionalidadessemelhantes as desktop applications masque mantem a informacao no lado do servi-dor
5 1520 28
RSS Really Simple Syndication 27
SLA Service Level Agreement 40SQLite Segundo a definicao oficial SQLite is a
software library that implements a self-contained serverless zero-configurationtransactional SQL database engine
17
SSB Site Specific Browser 25SSL Secure Sockets Layer 22SWF ShockWave Flash 21
URL Uniform Resource Locator 18
VPN Virtual Private Network 38
WOW Work Orders Web Plataforma de gestaode ordens de trabalho e do seu fluxo de-senvolvida pela Critical Software SA
i iii28 3340ndash434551ndash5356
WWW World Wide Web 11 1214
XBL eXtensible Binding Language 24XHTML eXtensible HyperText Markup Language 12XML eXtensible Markup Language 11 12
23 2428
XSLT eXtensible Stylesheet Language Transfor-mation
12
XUL eXtensible User Interface Language xiv23ndash25
xv
Glossario
xvi
Capıtulo 1
Introducao
Neste capıtulo enquadra-se o tema do projecto introduzindo alguns dos conceitos
nos quais se baseia Apresentam-se as motivacoes ambito objectivos e a estrutura
deste documento
11 Enquadramento
A Internet foi originalmente concebida para ser um espaco de partilha de in-
formacao onde pessoas (atraves de maquinas) pudessem comunicar Na sua origem
as paginas eram estaticas constituıdas por texto formatado em HyperText Markup
Language (HTML) e ligadas entre si [BL96] Hoje encontramos conteudos cada vez
mais complexos e dinamicos incluindo som vıdeo ou streams multimedia [Loo06] e
em 2005 foi introduzido por [OrsquoR09] o termo Web 20
De acordo com [Greon] um website pode pertencer a uma ou varias das seguintes
categorias
bull Documento ndash um website essencialmente estatico onde alteracoes a uma
parte do conteudo nao tem implicacoes no seu comportamento
bull Base de dados ndash um directorio de informacao organizada em categorias
bull Aplicacao ndash um website dinamico que utiliza uma linguagem executada ou
interpretada do lado do servidor e que processa as accoes ou informacao in-
troduzida pelo utilizador para fornecer um servico ou nova informacao
A ultima destas categorias constitui aquilo que e normalmente designado por
web application O conceito utilizado ao longo deste documento e o mesmo que
o introduzido por Jim Coallen em [Con99] que define web application como um
1
Introducao
sistema web (servidor rede HyperText Transfer Protocol (HTTP) browser) onde
accoes do utilizador (navegacao e introducao de informacao) afectam o estado logico
da aplicacao A sua definicao tenta estabelecer que uma web application e um
sistema de software com estado de negocio1 e que a sua interface de interaccao com
o utilizador e distribuıdo atraves de um sistema web
12 Motivacao
A quantidade de informacao que e produzida e armazenada com recurso a es-
tas web applications disponıveis online tais como e-mail blogues ou mesmo docu-
mentacao tornam por vezes a disponibilidade de ligacao uma condicao necessaria
a produtividade e como consequencia desta barreira muitos potenciais utilizadores
opoem-se a adopcao de produtos web em detrimento das tradicionais desktop appli-
cations
Assegurar o acesso a uma ligacao de Internet e hoje muito mais facil A Internet
movel e ja uma realidade e encontra-se amplamente divulgada mas continuam a
existir diversas situacoes nas quais os utilizadores estao privados de uma ligacao
a Internet tais como uma viagem de metro ou de aviao ou quando se encontram
deslocados do seu paıs de origem e nao possuem nenhum plano de subscricao
Uma OWA consiste numa web application que para alem de manter todas as
caracterısticas anteriores se mantem disponıvel mesmo na ausencia de uma ligacao
a Internet e surge como uma tentativa de estreitar as barreiras existentes entre a
web e o desktop Isto significa que devera existir um mecanismo capaz de assegurar
a manutencao do estado logico da aplicacao quando a ligacao com o servidor e
quebrada permitindo ao utilizador continuar a utilizar a aplicacao e que sera capaz
de informar o servidor do estado em que a aplicacao se encontra quando a ligacao for
reposta A principal vantagem que advem desta possibilidade e evidente eliminar
a necessidade da existencia de uma ligacao a Internet para que a aplicacao possa ser
utilizada
Por outro lado a vontade de integracao de funcionalidades tıpicas das desktop
applications nas web applications foi um dos principais factores que impulsionou o
desenvolvimento deste conceito uma vez que obrigou a uma reflexao ldquopara alem
do browserrdquo e a uma adaptacao das arquitecturas existentes que permitisse ou o
acesso a funcionalidades disponibilizadas pelo sistema operativo ou pelo menos a
funcionalidades semelhantes Pretende-se com esta aproximacao tornar possıveis
interaccoes entre o desktop e o browser tais como arrastar um ficheiro para um
formulario web de upload de conteudos melhor suporte para o historico do clipboard
ou ainda o acesso ao sistema de ficheiros local Atingir estes objectivos reflecte-se
1NT business state
2
Introducao
num novo paradigma que reune as vantagens das web applications tais como os
updates instantaneos ou o facto de nao ser necessaria nenhuma instalacao e das
desktop applications como por exemplo persistencia no armazenamento de dados
acesso a funcionalidades do sistema operativo ou integracao e interaccao com outras
aplicacoes sejam elas web applications ou desktop applications
13 Ambito
Este projecto foi realizado na Critical Software SA no ambito do Mestrado
Integrado em Engenharia Informatica e Computacao (MIEIC) da Faculdade de En-
genharia da Universidade do Porto (FEUP) entre os meses de Fevereiro e Julho de
2008
14 Objectivos
Sao objectivos deste projecto
1 Estudar e documentar o tema das OWAs acompanhando os ultimos desenvolvi-
mentos nesta materia
2 Analisar o estado da arte fazendo uma analise crıtica e objectiva sobre as
diversas metodologias existentes
3 Implementar uma prova de conceito que permita a execucao offline de uma
web application documentando todo o processo
4 Estudar a possibilidade de permitir interaccao com a aplicacao (insercoes e
alteracoes aos dados) em modo offline
Em resumo o objectivo deste projecto foi estudar documentar e implementar
uma prova de conceito relacionada com o tema Offline Web Applications (OWA)
Este tema embora nao seja totalmente novo ganhou destaque ao longo do ano de
2007 com o surgimento de diversas ferramentas que se destinam a aproximar web
applications das desktop applications
15 Estrutura do documento
Este documento esta organizado em diferentes seccoes apresentando o projecto
numa sequencia logica organizada da seguinte forma
No capıtulo 1 faz-se uma breve apresentacao do conceito OWAs e do contexto em
que surge Apresenta-se tambem a estrutura do documento e definem-se os
termos e acronimos utilizados
3
Introducao
No capıtulo 2 faz-se uma descricao da evolucao das tecnologias que antecedem as
OWAs e das vantagens e desvantagens de cada uma como forma de enquadra-
mento
No capıtulo 3 analisa-se o estado da arte nesta materia Introduzem-se diversas
tecnologias directamente relacionadas com o tema deste projecto exemplos de
aplicacoes que as usam e as razoes que fundamentam as escolhas de tecnologias
efectuadas
O capıtulo 4 contem o desenvolvimento do projecto Analisa-se a plataforma
WOW de gestao integrada de ordens de trabalho a tecnologia escolhida e
a forma como foi utilizada para implementar a capacidade de execucao offline
O capıtulo 5 descreve os resultado obtidos comparando-os com as expectativas
iniciais do projecto e apresenta desenvolvimentos futuros e possibilidades de
continuacaoaplicacao do conhecimento adquirido
No capıtulo 6 apresentam-se as conclusoes
4
Capıtulo 2
Enquadramento do Projecto
Neste capıtulo apresenta-se um breve resumo da evolucao das arquitecturas de
software cliente-servidor e a forma como estas se comparam a evolucao da Inter-
net procurando estabelecer uma analogia entre o percurso de ambas as tecnolo-
gias Compara-se o comportamento e arquitectura dos thin-clients as paginas web
estaticas a evolucao dos fat-clients as paginas interactivas Web 20 e Ajax e
defende-se que as OWA constituem um proximo passo logico e evolutivo aproxi-
mando a web do desktop Referem-se ainda os principais factores que justificam a
importancia das OWAs e a estreita relacao que tem com as Rich Internet Application
(RIA)s
21 Evolucao das arquitecturas de software
Os termos thin-client e fat-client sao utilizados quer para descrever arquitecturas
logicas (de software) quer para descrever arquitecturas fısicas (de hardware) Neste
capıtulo excepto quando seja dada indicacao em contrario estes termos referem-se
sempre a uma arquitectura logica
Adicionalmente quando se trata de arquitecturas cliente-servidor pode-se estu-
dar a arquitectura desenvolvida do sistema como um todo da arquitectura do servi-
dor ou da arquitectura do cliente Para evitar equıvocos em especial na seccao 213
especifica-se em cada caso qual o sistema estudado
211 Thin-clients
Um thin-client e um computador cliente ou software cliente que no contexto
de uma arquitectura cliente-servidor depende de um servidor central para as suas
5
Enquadramento do Projecto
actividades de processamento e proporciona um canal de entrada e saıda de in-
formacao entre o utilizador e o servidor remoto Este termo quando aplicado a
hardware refere-se habitualmente a um computador que se destina a ser utilizado
como cliente de rede sem armazenamento local e com capacidade de processamento
reduzida [Gro02b] mas o conceito que aqui se analisa refere-se a uma arquitectura
de software que remonta ao inıcio das aplicacoes cliente-servidor
No inıcio da historia da computacao terminais ligavam-se directamente a main-
frames responsaveis por todo o processamento Nesta arquitectura era necessario
desenvolver duas aplicacoes distintas uma aplicacao central no servidor (main-
frame) responsavel pela gestao de toda a informacao e por todas as operacoes de
comunicacao e uma aplicacao de visualizacao instalada no cliente (terminal) O
papel destes terminais era apenas disponibilizar ao utilizador um meio de comu-
nicacao (entrada e saıda) e apresentacao dos resultados do servidor Nao tinham
um papel activo no calculo nem na logica de negocio e frequentemente nao tinham
tambem nenhum mecanismo de armazenamento de dados
Como vantagens esta arquitectura apresenta uma reduzida necessidade de con-
figuracao e manutencao do lado do cliente Uma vez que o centro do processamento
e manipulacao de dados ocorre no servidor existe tambem uma centralizacao da
informacao [NJN00] que introduz um ponto crıtico de falha1 Actualizacoes e novas
funcionalidades sao faceis de distribuir uma vez que requerem apenas alteracoes no
servidor [Gro02a]
212 Fat-clients
Contrastando com os thin-clients nesta arquitectura os clientes implementam
ja uma parte da logica de negocio e sao responsaveis pelo processamento de dados
Estes fat-clients vieram responder a necessidade crescente de aplicacoes com um
nıvel de interactividade e capacidade de configuracao maior que as oferecidas pela
arquitectura thin-client descrita na seccao 211 Apesar de manterem a sua de-
pendencia do servidor podem tambem ser executados sem uma conexao activa uma
vez que dispoe de armazenamento de dados local o que lhes confere a capacidade
de persistencia de dados e do estado de execucao entre cada sessao
Foi disponibilizando este controlo sobre o estado da aplicacao bem como acesso
a recursos locais (por exemplo sistema de ficheiros e perifericos) que surgiram as
primeiras verdadeiras desktop applications No entanto cada cliente tinha que ser
separadamente instalado no computador pessoal de cada utilizador que pretendesse
utilizar ou interagir com a aplicacao e uma actualizacao ao servidor implicava in-
variavelmente uma actualizacao manual tambem no cliente Uma vez que nem todos
1NT single point of failure
6
Enquadramento do Projecto
Thin-clients Fat-clientsNao toma parte no processamento dedados nem possui acesso ao sistema deficheiros
Participa activamente no processa-mento de dados recorrendo ao sis-tema de armazenamento local para ar-mazenamento de dados
Nao mantem registo do estado logicoda aplicacao entre duas sessoes de uti-lizacao
O acesso ao armazenamento localpermite-lhe manter registo do estadologico da aplicacao entre duas sessoes
O thin-client nao necessita de qualquerinstalacao estando ldquopronto a utilizarrdquo
E geralmente necessario instalar aaplicacao para poder interagir com oservidor
Qualquer update no servidor reflecte-seimediatamente por todos os clientes
Embora a aplicacao cliente possa aler-tar para existencia de novas versoes asactualizacoes tem que ser manualmenteinstalados pelo cliente
O software do cliente destina-se apenasa apresentacao de dados e comunicacaocom o servidor sendo portanto de sim-ples implementacao
Como o software do cliente toma parteactiva no processamento de dadosa sua implementacao requer cuidadosadicionais
Grande mobilidade uma vez que todaa informacao e mantida no servidor
Parte da informacao podera estar ape-nas do lado cliente pelo que existemalgumas restricoes a sua mobilidade
Tabela 21 Comparacao entre thin-clients e fat-clients
os utilizadores actualizam regularmente as suas aplicacoes o servidor tem que estar
preparado para lidar com versoes antigas2 ou descontinuar os seus servicos a uma
parte da sua comunidade de utilizadores ate que estes actualizem os seus sistemas
Como os utilizadores passam a utilizar os seus recursos locais para armazenamento
de dados as alteracoes que nao sejam sincronizadas com o servidor estao apenas
disponıveis nos seus computadores pessoais o que introduz uma restricao a mobili-
dade
Pode-se afirmar que as vantagens dos thin-clients sao as desvantagens dos fat-
clients e que as vantagens dos fat-clients sao as vantagens dos thin-clients tal como
se ilustra na Tabela 21
213 Arquitecturas cliente-servidor
Introduzidos os termos thin-client e fat-client interessa reafirmar que ambos
podem ser vistos como arquitecturas cliente-servidor Um cliente define-se como
um solicitador de servicos e um servidor como um prestador de servicos tal como
definido por [Sch96] e [Sad97]
2NT backward compatibility
7
Enquadramento do Projecto
As arquitecturas cliente-servidor sao categorizadas pela modularizacao com que
sao desenhadas sendo consideradas as seguintes camadas
1 Interface grafica (front-end) atraves da qual os utilizadores interagem com
a aplicacao Quando este modulo e implementado separadamente dos outros
dois constitui uma aplicacao thin-client por si so uma vez que nao implementa
regras de negocio (embora possa definir validacoes de formularios de insercao de
dados por exemplo) A informacao introduzida pelo utilizador e enviada para
o servidor que processa o seu pedido e retorna uma resposta Este processo
repete-se ate que o utilizador atinja o seu objectivo ou se desligue do sistema
2 A logica de negocio tambem designada por camada intermedia que imple-
menta as regras de aceitacao e validacao de todos os dados introduzidos pelo
utilizador E tambem a plataforma de comunicacao que une a camada superior
de visualizacao com a camada de acesso a dados
3 A camada de dados inclui quer o sistema de persistencia de dados onde sao
armazenados os dados relevantes como tambem os mecanismos necessarios
para a sua pesquisa seleccao e alteracao
Os thin-clients quando observados no seu conjunto de cliente e servidor podem
ser vistos quer como sistemas de duas camadas quer como sistemas de tres camadas
dependendo apenas da forma como o servidor for implementado No caso de na
implementacao do servidor nao se distinguir a camada de acesso a dados da camada
da logica de negocio sao designados por sistemas de duas camadas Caso seja feita
esta distincao sao designados por sistemas de tres camadas Ambos os casos sao
ilustrados na Figura 21
Historicamente os fat-clients eram implementados numa arquitectura em duas
camadas Possuıam apenas um modulo de visualizacao de dados designado por
camada de interface e um modulo que implementava toda a logica de negocio e
regras de acesso a base de dados No entanto com a introducao de ligacoes mais
rapidas e de computadores pessoais com maior capacidade de processamento e so-
bretudo devido a complexidade crescente das aplicacoes a logica de negocio e a
camada de acesso a dados tornaram-se independentes Este modelo e designado por
arquitectura em tres camadas e e ilustrado na Figura 22
22 Evolucao na Internet
Ao analisar a evolucao das arquitecturas das aplicacoes desenvolvidas para a
Internet podemos encontrar um paralelismo com a historia da arquitectura de soft-
ware
8
Enquadramento do Projecto
Figura 21 Arquitectura de um sistema thin-client em duas camadas (a esquerda) e emtres camadas (a direita) Note-se a inclusao do servidor (mainframe) na definicao dascamadas desta arquitectura devido a forte dependencia cliente-servidor
221 Paginas web estaticas
Uma pagina web estatica devolve sempre a mesma resposta a todos os pedidos
para todos os utilizadores e em qualquer contexto utilizando o hipertexto como
forma de ligacao entre diversas paginas estaticas
A informacao e armazenada num servidor e o papel do cliente e apenas a apre-
sentacao da informacao Esta forma de disponibilizacao de informacao pode assim
ser comparada com os thin-clients descritos na seccao 211 o utilizador acede a
um website estatico para visualizar informacao sem que o cliente tome parte no
processamento A unica diferenca e que no caso da web estatica a informacao ap-
resentada e sempre a mesma enquanto que nos thin-clients era frequente existir a
possibilidade de insercao de dados no cliente e apos o seu processamento servidor
nova informacao poderia ser apresentada O hipertexto e utilizado para ligar as
paginas entre si numa rede de conteudos relacionados e a navegacao sıncrona era
feita atraves de cliques do rato a cada clique uma nova pagina era apresentada
Este modelo sıncrono e ilustrado na Figura 23
222 Paginas web interactivas e paginas web dinamicas
O JavaScript e uma linguagem interpretada de scripting que tem os browsers
como principal ambiente de acolhimento Os browsers utilizam uma Application
9
Enquadramento do Projecto
Figura 22 Arquitectura de um fat-client em duas camadas (a esquerda) e em tres camadas(a direita)
Programming Interface (API) publica para criar ldquoobjectosrdquo responsaveis por reflectir
e disponibilizar o Document Object Model (DOM) para o motor de JavaScript
A utilizacao mais frequente desta linguagem e a escrita de funcoes que sao em-
bebidas ou incluıdas em paginas web e que interagem com o DOM Uma vez que o
JavaScript e executado localmente (na maquina do cliente e nao no servidor) e capaz
de responder rapidamente a accoes do utilizador tornando a execucao de aplicacoes
no browser mais fluıdas o JavaScript pode tambem detectar accoes do utilizador
que o HTML nao pode tal como o pressionar de uma tecla
Em Dezembro de 1995 a Netscape Communications adicionou suporte para o
JavaScript no browser Netscape Navigator3 e em Agosto de 1996 o browser Internet
Explorer4 da Microsoft passou a tambem a suportar uma versao semelhante desta
linguagem (hoje todos os principais browsers suportam esta tecnologia)
Esta inovacao permitiu tornar os websites mais interactivos mas a sua utilizacao
esteve confinada apenas a este proposito durante um longo perıodo As paginas
passaram a responder activamente a accoes do utilizador (sendo uma das utilizacoes
3Netscape Communications ndash httpbrowsernetscapecom4Microsoft Internet Explorer ndash httpwwwmicrosoftcomwindowsproductswinfamilyie
10
Enquadramento do Projecto
mais vulgares a validacao de formularios) mas continuaram essencialmente estaticas
O JavaScript ainda nao era nesta altura utilizado para processar dados
Tambem nesta altura (1995ndash96) surgiram linguagens server-side como o PHP
Hypertext Preprocessor (PHP) e Active Server Pages (ASP) e o servidor passou a ter
um processamento de dados introduzidos pelo utilizador mais activo Generalizaram-
se as paginas dinamicas capazes de responder a insercao de dados ou outros pedidos
determinados por accoes do utilizador As paginas tornaram-se aplicacoes web ap-
plications
Uma definicao tradicional de web application e um conjunto de paginas web
logicamente agrupadas e geridas por uma unica entidade que tem como pontos de
entrada formularios de insercao de dados (web forms) Uma web application nao e
mais do que uma aplicacao que e acedida atraves de um browser Tem geralmente
uma arquitectura logica em tres (interface logica de negocio e camada de dados)
camadas e estao armazenadas num servidor
Ha dois tipos de web applications
bull Orientadas a apresentacao Sao web applications que geram paginas web in-
teractivas constituıdas por varios tipos de linguagens de anotacao (por exem-
plo HTML eXtensible Markup Language (XML)) e que apresentam conteudo
dinamico como resposta a pedidos efectuados pelo utilizador
bull Orientadas aos servicos Uma web application orientada aos servicos imple-
menta o ponto de acesso para um ou mais de um web service Sao geralmente
clientes de service oriented web applications
Uma vantagem significativa de implementar uma web application de forma a
suportar as funcionalidades padrao dos browsers e que estas terao o mesmo com-
portamento independentemente da plataforma e do browser a partir do qual serao
acedidas No entanto diferentes implementacoes de browsers devido a diferentes
interpretacoes dos padroes definidos tornam por vezes esta tarefa um pouco mais
complicada existindo inclusivamente na web guioes de compatibilidade para os difer-
entes browsers como [Smi07]
223 Web 20 e Ajax
O termo web 20 descreve uma tendencia de utilizacao e de design observada
na World Wide Web (WWW) com o objectivo de melhorar a criatividade partilha
de informacao e principalmente a colaboracao entre utilizadores Estes conceitos
levaram ao desenvolvimento e evolucao de comunidades online tais como redes so-
ciais wikis e blogues
11
Enquadramento do Projecto
O termo tornou-se mais conhecido apos a primeira conferencia OrsquoReilly Media
Web 20 em 2004 e apesar de sugerir uma nova versao da WWW nao se refere a
qualquer evolucao tecnologica mas apenas a alteracoes a forma como os utilizadores
se servem da web De acordo com Tim OrsquoReilly [OrsquoR06] ldquoWeb 20 e uma revolucao
na industria do software causada pela adopcao da web como uma plataforma e pela
tentativa de entendimento das regras para o sucesso nesta nova plataformardquo
O desenvolvimento da Web 20 serve-se muitas vezes de um outro conceito Ajax
O conceito que hoje conhecemos como Ajax muitas vezes incorrectamente de-
scrito como uma tecnologia foi originalmente criado para permitir o desenvolvimento
de web applications que se assemelhassem ainda mais a aplicacoes de desktop Este
conceito foi melhor descrito por [Gar05] como um conjunto de varias tecnologias
que podem ser utilizadas para melhorar a experiencia do utilizador de uma dada
web application introduzindo a capacidade assıncrona de envio de pedidos ou da
recepcao assıncrona de respostas As tecnologias mais frequentemente envolvidas
sao
bull eXtensible HyperText Markup Language (XHTML) e Cascading Style Sheets
(CSS) padrao para a apresentacao
bull interaccao dinamica atraves do DOM
bull troca e manipulacao de dados utilizando XML e eXtensible Stylesheet Lan-
guage Transformation (XSLT) ou JavaScript Object Notation (JSON)
bull pedidos assıncronos utilizando XMLHttpRequest [vK08]
bull JavaScript utilizado para integrar todas estas tecnologias
E importante frisar que o Ajax nao e um produto nem uma tecnologia E um
termo que descreve a utilizacao de um conjunto de tecnologias para o desenvolvi-
mento de web applications com um elevado grau de interactividade Comparativa-
mente as web applications tradicionais o Ajax introduz uma camada de visualizacao
diferente em tres importantes pontos
1 Do lado do cliente existe um motor que serve de intermediario entre a interface
da aplicacao e o servidor
2 A actividade do utilizador despoleta chamadas JavaScript em vez de um pedido
de pagina directamente ao servidor
3 Informacao codificada em XML em vez de paginas HTML e trocada entre o
servidor e o cliente
12
Enquadramento do Projecto
Isto significa que as paginas que utilizam Ajax contem um motor do lado do
cliente composto por um conjunto de funcoes JavaScript responsavel pela comu-
nicacao com o servidor e por actualizar a interface com o resultado dessa mesma
comunicacao
Na Figura 23 ilustra-se a natureza assıncrona do Ajax quando comparada com
as web applications tradicionais Como se pode observar adicionando um mecan-
ismo Ajax a uma web application eliminam-se diversos tempos de espera associados
a comunicacoes com o servidor uma vez que a interface nao fica ldquobloqueadardquo a es-
pera da resposta Obtem-se assim aplicacoes com um comportamento mais fluido
eliminando tempos de espera entre cada ldquocliquerdquo e melhorando a experiencia do
utilizador
23 Offline Web Applications
A informacao grafica (bem como folhas de estilo e scripts) tais como as ima-
gens que constituem o visual de uma web application e ja tratada de forma especial
pelos cada vez mais avancados sistemas de cache (armazenamento temporario) dos
browsers Mas estes nao sao ainda capazes de guardar conteudo criado pelo uti-
lizador nem de apresentar informacao independentemente do estado da ligacao
Numa altura onde se fala de servicos de Internet wireless municipalizados [Kha]
comunicacoes 3G e ligacoes de banda larga a alta velocidade a ligacao a rede global
continua a nao estar permanentemente disponıvel para os utilizadores Na WWW
encontra-se uma importante parte da informacao e das aplicacoes utilizadas para
criar e editar conteudos Por vezes informacao vital para a produtividade pode
desaparecer subitamente do mapa de acesso de um utilizador quando este entra no
metro num aviao ou mesmo quando se desloca para uma cidade ou paıs diferente
do habitual onde nao subscreve um plano de acesso que lhe garanta a ligacao
Permitir o acesso offline a estes recursos assume assim a sua importancia porque
permitira estender o alcance da informacao a locais onde nunca esteve antes e per-
mitira tambem melhorar o desempenho das web applications colocando informacao
mais perto dos utilizadores reduzindo a transferencia de dados apenas ao essencial
24 Comparacao
Nas evolucoes descritas neste capıtulo 2 pode-se observar que existe um par-
alelismo entre a evolucao das arquitecturas tradicionais cliente-servidor e a evolucao
a que se assiste na web O comportamento e arquitectura dos thin-clients assemelha-
se ao das paginas estaticas no sentido em que o browser nao toma parte em qualquer
13
Enquadramento do Projecto
processamento e serve apenas como uma plataforma de interaccao com o servidor
tal como os clientes descritos na seccao 211
A sua proxima evolucao os fat-clients trouxeram parte da capacidade de pro-
cessamento para o lado do cliente Na web foi tambem esta a inovacao tecnologica
a que se assistiu com a evolucao das tecnologias que permitiram a criacao de ver-
dadeiras aplicacoes e com a introducao do Javascript no browser dando ao cliente
a capacidade de processamento de dados A necessidade da separacao do codigo
em camadas logicas advem da crescente complexidade das web applications Esta
pratica permite entre outras coisas melhorar o processo de desenvolvimento e a
capacidade de manutencao de uma aplicacao
Os fat-clients tem tambem a capacidade de armazenamento de dados o que
permite a persistencia de informacoes entre duas sessoes e que algumas operacoes
sejam executadas sem a necessidade de comunicacao com o servidor Este facto pode
tambem ser uma realidade nas web applications com a adopcao das tecnologias OWA
Neste momento assiste-se a uma utilizacao cada vez maior da web como uma
plataforma de desenvolvimento A capacidade de cooperacao na edicao de conteudos
e a mobilidade proporcionada por esta plataforma sao os principais factores que
alimentam esta mudanca e pela primeira vez as aplicacoes tradicionais tem com-
peticao vinda de web applications A prova do reconhecimento da web como plataforma
de desenvolvimento pode ser retirada da aposta de empresas como a Adobe e Mi-
crosoft que lancaram publicamente ferramentas web complementares a produtos
seus tradicionalmente associados ao desktop ndash Acrobatcom5 e Microsoft Office
Live6 Dotar estas web applications da capacidade de execucao offline significa
aproximar a web e o desktop reunindo ldquoo melhor de dois mundosrdquo
As vantagens da mobilidade possıvel atraves da web a cooperacao na criacao e
edicao de conteudos e a possibilidade de utilizar aplicacoes sempre actualizadas e
sem necessidade de instalacao sao algumas das principais vantagens que promovem
esta mudanca que devido as preocupacoes associadas a usabilidade e experiencia do
utilizador esta fortemente associada ao desenvolvimento de Rich Internet Applica-
tion (RIA)s
5Adobe Acrobatcom httpwwwacrobatcom6Microsoft ndash httpsmallbusinessofficelivecom
14
Enquadramento do Projecto
Figura 23 Comparacao do modelo de web aplications sıncrono paginas estaticas e in-teractivas abordados nas seccoes 221 e 222 com o modelo de web applications Ajax(assıncrono) abordado na seccao 223 Figura adaptada de http www adaptivepath
com
15
Enquadramento do Projecto
16
Capıtulo 3
Estado da arte
Apesar de o conceito das OWAs nao ser absolutamente novo as tecnologias que
o suportam sao recentes Neste capıtulo descrevem-se quatro tecnologias que foram
tidas como principais candidatas para o desenvolvimento deste projecto Descrevem-
se ainda alguns exemplos de web applications que disponibilizam actualmente fun-
cionalidades offline e o processo da escolha da tecnologia a utilizar neste projecto
31 Gears
O Gears1 e uma extensao as funcionalidades do browser introduzido pelo Google
que tem como principal objectivo tornar possıvel a visualizacao de paginas de Inter-
net mesmo sem uma conexao disponıvel Encontra-se disponıvel para as platafor-
mas Windows Macintosh e Linux e oferece uma API de Javascript que permite
a scripts aceder a um mecanismo de armazenamento local baseado numa base de
dados SQLite
311 Arquitectura
Esta ferramenta e constituıda por tres componentes principais
bull LocalServer mdash Intercepta pedidos de paginas web e serve-as localmente
bull Database mdash Uma base de dados relacional construıda sobre SQLite
bull WorkerPool mdash Permite executar operacoes de computacao de uma forma
assıncrona sem afectar a capacidade de resposta e fluidez de execucao da web
application Assemelham-se a processos
1Google Inc ndash Mais informacao em httpgearsgooglecom
17
Estado da arte
LocalServer
O modulo LocalServer e uma cache de Uniform Resource Locators (URLs)
controlada pela web application Quando nao existe uma ligacao a Internet e e
feito um pedido para um URL presente nesta cache o LocalServer intercepta-o e
responde ao pedido localmente a partir do disco rıgido do utilizador A aplicacao
pode utilizar dois tipos diferentes de armazenamento local de URLs
bull ResourceStore ndash serve para capturar URLs utilizando exclusivamente a API
de Javascript disponibilizada para o efeito Uma aplicacao podera criar e
utilizar diversos ResourceStores simultaneamente para capturar ficheiros de
dados que necessitam de ser enderecados por um URL tal como um ficheiro
PDF ou uma imagem
bull ManagedResourceStore ndash serve para capturar um conjunto de URLs que estao
relacionados e que sao declarado num ficheiro de manifesto (especificado em
JSON) e que sao automaticamente actualizados O ManagedResourceStore
permite que o conjunto de recursos necessarios para correr uma web application
seja capturado e mantido actualizado automaticamente
A principal diferenca entre estes dois tipos de armazenamento de URLs e a forma
como sao actualizados os seus conteudos Os conteudos de um ManagedResourceStore
sao actualizados sempre que a versao contida no ficheiro de manifesto for alterada
enquanto que os conteudos de um ResourceStore nunca sao actualizados automati-
camente mas apenas quando for explicitamente ordenado pela aplicacao
O LocalServer e capaz de interceptar e servir localmente pedidos de HTTP e
HTTPS sempre que se reunam as seguintes condicoes
1 O URL encontra-se armazenado num ResourceStore ou ManagedResourceStore
2 O sistema de armazenamento local encontra-se activo (enabled = true) Se
o sistema de armazenamento local tiver o atributo requiredCookie o pedido
devera conter um cookie que lhe corresponda
O LocalServer nao necessita de monitorizar o estado da ligacao para atender aos
pedidos Na verdade sempre que as condicoes previamente enunciadas se verificarem
o LocalServer interceptara os pedidos e independentemente do estado da ligacao
a Internet servi-los-a a partir do disco rıgido local Cabera a aplicacao definir qual
o modo em que pretende executar um pedido (online ou offline) definindo o valor
de verdade da propriedade enabled
18
Estado da arte
Database
O modulo Database permite guardar dados da web application assegurando a
sua persistencia Os dados sao guardados de forma relacional no disco rıgido do uti-
lizador2 de acordo com o modelo de seguranca estabelecido pelo Gears3 significando
que uma aplicacao nao pode aceder a conteudos fora do seu domınio
WorkerPool
Nos web browsers uma operacao pesada de computacao pode tornar a interface
lenta e tornar menos agradavel a experiencia do utilizador O modulo WorkerPool
permite correr operacoes em background sem bloquear a interface com o utilizador
Os scripts executados numa WorkerPool nao activam os mecanismos de seguranca
do browser que mostram a mensagem ldquoA script on this page may be busy or may
have stopped respondingrdquo
O WorkerPool comporta-se como um conjunto de processos em vez de threads
Os Workers nao partilham qualquer estado de execucao o que significa que uma
alteracao a uma variavel num Worker nao afecta em nada a execucao de outro
Worker Alem disso os Workers nao herdam automaticamente nenhum codigo dos
seus pais Cada Worker e membro de um WorkerPool e os Workers podem in-
teragir entre si enviando mensagens em formato de texto ou JSON No entanto ha
tambem algumas limitacoes os Workers nao tem acesso ao DOM e objectos como
window ou document nao se encontram acessıveis Isto e consequencia de os Workers
nao partilharem o estado de execucao Mas tem acesso a todas as funcoes built-in
do Javascript A maioria das funcionalidades do Gears pode tambem ser acedida
atraves de uma variavel global especial definida como googlegearsfactory Para
outras funcionalidades especıficas os Workers podem ldquopedirrdquo a pagina principal para
continuar a execucao atraves do envio de mensagens
Outras funcionalidades
bull HttpRequest ndash Este modulo implementa a especificacao W3C XmlHttpRe-
quest definida em [vK08] tornando-a disponıvel para os workers e para a
pagina principal
bull Timer ndash Este modulo implementa a especificacao de timers tal como descrito
por [Hic08] e torna-os disponıveis para os workers e para a pagina principal
2Consultar httpcodegooglecomapisgearsapi_databasehtmldirectories3Consultar httpcodegooglecomapisgearssecurityhtml
19
Estado da arte
bull Factory ndash Esta classe e utilizada para instanciar todos os outros objectos da
API do Gears atraves do seu metodo create Este metodo pode ser utilizado
com os seguintes parametros
ndash betadatabase
ndash betahttprequest
ndash betalocalserver
ndash betatimer
ndash betaworkerpool
312 Goggle Gears em dispositivos moveis
O Gears esta tambem disponıvel em dispositivos Windows Mobile 5 e 6
Os dispositivos moveis estao pela sua natureza frequentemente desconectados
da Internet Mesmo quando possuem uma ligacao as latencias na transferencia de
dados em redes moveis tornam as aplicacoes pouco fluıdas mas o Gears permite
ultrapassar este obstaculo
O Gears funciona exactamente da mesma forma em dispositivos moveis equipados
com o Windows Mobile 5 e 6 como num computador comum Se uma aplicacao tiver
sido implementado com suporte para o Gears entao tambem estara preparada para
ser executada num dispositivo movel mas as limitacoes dos browsers disponıveis
para dispositivos moveis tem que ser consideradas Isto significa prever as condicoes
que permitam uma boa usabilidade devido aos pequenos ecras destes dispositivos
bem como o seu suporte limitado dos padroes do DOM CSS e JavaScript
32 Adobe AIR
O Adobe AIR4 e um runtime compatıvel com diversos browsers e sistemas opera-
tivos que pretende dar aos programadores a possibilidade de combinar diversas tec-
nologias de producao de conteudos para a Internet no desenvolvimento de Rich Inter-
net Application (RIA)s O Adobe AIR mantem uma relacao com o browser mas es-
tende as suas capacidades e tecnologias permitindo o desenvolvimento de aplicacoes
tambem para o ambiente de trabalho com janelas em tudo semelhantes as do sis-
tema operativo Segundo a Adobe o objectivo e complementar o browser dando
aos utilizadores (mas essencialmente aos programadores e equipas de desenvolvi-
mento) a escolha sobre como distribuir as suas aplicacoes Para este efeito o Adobe
AIR tem uma aproximacao diferente do Gears Em vez de ldquoestenderrdquo o browser
acrescentando-lhe funcionalidades o AIR permite tambem o desenvolvimento de
4Adobe - httpwwwadobecomproductsair
20
Estado da arte
aplicacoes que se destinam a ser executadas fora do ambiente do browser mas uti-
lizando as tecnologias comuns da Internet (por exemplo HTML CSS JavaScript
Flash Flex)[CDGH08]
A utilizacao desta tecnologia permite utilizar o browser ou o proprio runtime
Adobe AIR como plataforma de execucao da aplicacao
Na Tabela 31 faz-se uma comparacao das funcionalidades disponıveis de acordo
consoante se escolha o browser ou o desktop como plataforma base para a aplicacao
Uma vez que as aplicacoes Adobe AIR na plataforma desktop tem um caracter
persistente (sao instaladas no computador do utilizador) o Adobe AIR tem um
modelo de seguranca que se assemelha com o das tradicionais aplicacoes desktop
[Ada08] Este modelo e analisado nas seccoes 321 e 322 O ambiente em que
e executado o browser e restringido a execucao de web applications que podem
ser de varias origens (incluindo de origens anonimas ou sem confianca) O Adobe
AIR proporciona acesso a capacidades como acesso a ficheiros que necessitam da
confianca do utilizador
bull HTML ndash O desenvolvimento de aplicacoes para o Adobe AIR pode ser feito
com recurso a tecnologias de HTML e Ajax comuns utilizando as linguagens
de markup existentes distribuıdas como texto e interpretadas em execucao
(runtime)
bull Flash ndash Outra alternativa sera a utilizacao da linguagem Flash Permite a
renderizacao de graficos vectoriais e audiovıdeo com suporte nativo Utiliza
ActionScript para adicionar maior interactividade com o utilizador
bull Flex ndash O Flex e uma framework open source para o desenvolvimento de RIAs
usando Flash As aplicacoes Flex sao na realidade Flash sendo a principal
diferenca o ambiente de desenvolvimento
Como resultado uma aplicacao AIR podera ser implementada
bull Baseada em Flash ou Flex (aplicacoes cujo conteudo base e em ShockWave
Flash (SWF))
bull Baseada em Flash ou Flex tambem com HTML ou Portable Document Format
(PDF) Aplicacoes cujo conteudo de base e em FlashFlex (SWF) com HTML
(HTML JavaScript CSS) ou conteudo PDF incluıdo
bull Baseada em HTML Aplicacoes cujo conteudo base e em HTML Javascript
CSS
bull Baseada em HTML utilizando tambem FlashFlex ou PDF
21
Estado da arte
Os utilizadores interagem com uma aplicacao AIR da mesma forma que interagem
com outras aplicacoes com janelas nativas do seu sistema operativo O runtime e
instalado uma vez no computador do utilizador e a partir desse momento todas as
aplicacoes AIR terao o mesmo aspecto que qualquer outra aplicacao para o desktop
321 Seguranca
Permitir que uma web application aceda ao disco de armazenamento do utilizador
pode comprometer seriamente a sua seguranca Neste sentido o Adobe AIR tem
suporte para assinaturas digitais (Secure Sockets Layer (SSL)) que podem ser com-
pradas pelas equipas de desenvolvimento que o desejem e cujos certificados serao
apresentados ao utilizador no momento da instalacao Um outro aspecto ainda
relativo a seguranca e o mecanismo de isolamento de cada ambiente (sandbox )
322 Assinatura do codigo
O runtime AIR exige que todas as aplicacoes estejam digitalmente assinadas As
assinaturas digitais de codigo sao um processo que visa garantir a integridade da
aplicacao e a identidade do seu autor no momento da instalacao As equipas de
desenvolvimento podem ldquoassinarrdquo uma aplicacao utilizando um certificado atribuıdo
por uma Entidade Certificadora (Certification Authority) ou atraves de um certifi-
cado individual (self signed certificate) Neste momento o Adobe AIR suporta como
entidades certificadoras a Verisign e a Thawte [Ado08]
O instalador apresenta o nome de quem publica a aplicacao quando o codigo tiver
sido assinado com um certificado que apresente confianca ou que esteja encadeado
com um certificado que tenha ja sido aceite no computador em que se esta a instalar
a aplicacao
As equipas de desenvolvimento podem tambem assinar as aplicacoes com um
certificado auto-atribuıdo (um certificado criado por elas proprias) mas neste caso
o instalador apresentara estas aplicacoes como sendo de uma origem nao verificada
O AIR utiliza a infraestrutura publica de chaves [Ent07] suportada pelo arquivo
local do sistema operativo Para que a origem da aplicacao seja reconhecida o
computador onde a aplicacao AIR esta a ser instalada tem que confiar directamente
no certificado que foi utilizado para assinar a aplicacao ou confiar num certificado
que esteja num encadeamento logico de certificados confiados e que se ligue desta
forma ao certificado utilizado para assinar a aplicacao
Todas as aplicacoes AIR tem caracterısticas em comum independentemente da
tecnologia utilizada para o seu desenvolvimento (HTMLFlexFlash) No ambito
de uma aplicacao AIR existem um conjunto de APIs que estao disponıveis e que
tornam possıvel o acesso ao sistema local (leitura e escrita) e a recursos de rede que
22
Estado da arte
de outra forma nunca estariam acessıveis a partir de uma web application comum
Cada aplicacao AIR possui tambem diferentes nıveis de isolamento chamados secu-
rity sandboxes dependendo do tipo de conteudo que esta a ser carregado e do seu
objectivo
bull Isolamento ao nıvel da aplicacao5 ndash E a raiz de cada aplicacao AIR Este
nıvel de isolamento permite o acesso a APIs privilegiadas e especıficas do
AIR Em contrapartida e negado o acesso a algumas APIs que poderiam ser
facilmente utilizadas de forma maliciosa contra o utilizador final Importacao
dinamica de conteudos remotos e geralmente proibido e as tecnicas e mecan-
ismos de geracao dinamica de codigo sao fortemente restringidas Apenas
conteudo carregado directamente da directoria base da aplicacao podera ser
colocado neste nıvel de isolamento
bull Isolamento nao especıfico da aplicacao6 ndash contem todo o outro conteudo
que nao tenha sido carregado directamente para o isolamento da aplicacao
Isto inclui conteudo local e remoto Este tipo de conteudo nao tem acesso
directo as APIs do AIR e rege-se pelas mesmas regras tal como se tivesse sido
carregado por um browser a partir da mesma localizacao (por exemplo HTML
carregado a partir de um domınio remoto comporta-se da mesma forma que se
fosse acedido a partir do browser)
33 Mozilla Prism
331 XML User Interface Language
O eXtensible User Interface Language (XUL) e uma linguagem de anotacao
baseada em XML desenvolvida pela Mozilla Foundation que opera em aplicacoes
Mozilla multi plataforma tal como o Firefox O motor Gecko e a unica imple-
mentacao completa desta linguagem que foi desenhada sobre padroes web comuns
como CSS JavaScript e o DOM e permite o desenvolvimento de interfaces graficas
utilizando elementos pre-definidos tais como window box page textbox radio
button entre outros Infelizmente o XUL nao possui qualquer especificacao formal
ou implementacoes de inter-operabilidade para outros motores que nao o Gecko No
entanto a sua implementacao e licenciada em codigo aberto pelas licencas GNU Gen-
eral Public License (GPL) GNU Lesser General Public License (LGPL) e Mozilla
Public License (MPL)
Enunciam-se algumas caracterısticas desta linguagem
5NT application sandbox6NT non-application sandbox
23
Estado da arte
Liguagem de anotacao poderosa baseada em componentes (widgets) O ob-
jectivo do XUL e permitir a construcao de aplicacoes multi-plataforma em
claro contraste com o Dynamic HyperText Transfer Protocol (DHTML) que se
destina ao desenvolvimento de paginas web Por esta razao o XUL esta orien-
tado a componentes tais como janelas botoes e etiquetas em vez de paginas
cabecalhos de texto e ligacoes de hipertexto Investir tempo e esforco para
atingir este mesmo resultado em aplicacoes baseadas em DHTML compromete
frequentemente a complexidade e desempenho da aplicacao
Baseado em padroes O XUL e um dialecto XML baseado no padrao W3C XML
10 As aplicacoes escritas em XUL sao tambem baseadas em especificacoes
W3C adicionais como HTML 40 CSS DOM nıvel 1 e 2 JavaScript 15
incluindo ECMA-262 Edition 3 (ECMAscript)
Portabilidade entre plataformas Tal como HTML o XUL foi desenhado para
ser independente da plataforma em que e utilizado tornando as aplicacoes
facilmente portaveis entre sistemas operativos nos quais o Mozilla e suportado
Uma vez que o XUL oferece um nıvel de abstraccao dos componentes graficos
de interface que disponibiliza implementa a premissa ldquoum codigo para todas
as plataformasrdquo A interface grafica de todos os produtos centrais Mozilla
(browser instant messenger livro de enderecos) e escrita em XUL com um
unico codigo base que suporta todas as plataformas Mozilla
Separacao entre o nıvel de apresentacao e a logica de negocio Uma das
maiores preocupacoes no desenvolvimento para a Internet e a forte ligacao
entre estas duas camadas (interface e logica) Isto constitui um problema sig-
nificativo no desenvolvimento de grandes aplicacoes especialmente quando o
desenvolvimento e feito em ambientes de equipa porque as capacidades de de-
senvolvimento destas duas partes da aplicacao estao muitas vezes espalhadas
por diferentes elementos O XUL permite uma clara distincao entre a definicao
da aplicacao cliente e da logica de implementacao (XUL eXtensible Binding
Language (XBL) e JavaScript) apresentacao (CSS e imagens) internacional-
izacao (Document Type Definitions (DTDs) e etiquetas de texto em lınguas
especıficas guardados em ficheiros properties) O esquema grafico e apre-
sentacao de uma aplicacao XUL pode ser alterado de forma independente da
sua logica ou implementacao e a aplicacao pode ainda ser traduzida (interna-
tionalization) de forma independente da sua logica implementacao ou apre-
sentacao Este grau de separacao resulta em aplicacoes que sao mais faceis de
manter pelos programadores e facilmente adaptadas por designers e tradutores
24
Estado da arte
Facil adaptacao Outro benefıcio que advem do nıvel de separacao entre logica
de negocio e apresentacao oferecido pelo XUL e a facilidade com que se pode
adaptar uma aplicacao para diferentes clientes ou grupos de utilizadores Um
programador pode utilizar a mesma aplicacao base e adapta-la consoante as
necessidades atraves de diferentes temas (skins) e ficheiros de lınguas Desta
forma uma aplicacao escrita e desenvolvida em Ingles pode ser rapidamente
traduzida para Portugues e distribuıda com outra aparencia mais apropriada
ao cliente alvo
332 Prism
O Mozilla Prism e um browser simplificado e ldquointerpretadorrdquo de XUL (tambem
designado por XULRunner) que acolhe web applications sem a interface grafica ha-
bitual de um browser Baseia-se num conceito designado por Site Specific Browser
(SSB) Um SSB e uma aplicacao com um browser embebido desenhado para exe-
cutar apenas uma web application Nao possui os menus e barras de ferramentas
habituais Um SSB tem uma integracao com o sistema operativo e com o desktop
muito mais estreita do que uma web application acedida atraves de um browser uma
vez que e executado em janela propria
O Prism resulta de uma experiencia da Mozilla e visa reduzir as diferencas entre
as desktop applications tradicionais e as web applications Um dos aspectos focados e
a experiencia do utilizador Numa apresentacao oficial e dito que ldquo[o Prism] pretende
ser uma ponte entre as diferencas que existem entre as aplicacoes tradicionais de
desktop e as web applications explorando novos modelos de usabilidade enquanto
que a linha que as separa se continua a definirrdquo [Lab07]
34 HTML 5
A especificacao HTML 5 [Hic08] que se encontra em fase de desenvolvimento
pelo grupo WHATWG pretende ser uma norma de substituicao dos padroes HTML
4 XHTML 1x e do DOM2 HTML Uma das propriedades que o distingue das tec-
nologias que pretende substituir e precisamente o suporte para OWA e armazena-
mento de dados no cliente de uma forma relacional Nao sendo propriamente uma
tecnologia ndashmas antes uma especificacao ndashe aqui mencionada por ter servido como
referencia a diversas implementacoes de funcionalidades offline e por se considerar
que venha a ter um impacto significativo nas implementacoes de diversos browsers
Dion Almaer defendeu no seu blogue que o Gears era uma implementacao do
HTML 5 No seu artigo ldquoGears as a bleeding-edge HTML 5 implementationrdquo [Alm08]
o autor diz que ambos ndasho Gears e o HTML 5 ndashpretendem dar a web caracterısticas
25
Estado da arte
semelhantes e nao encontrar motivo de ldquocompeticaordquo entre as duas mas que en-
quanto o HTML 5 e uma especificacao o Gears e uma implementacao
No entanto tambem e verdade que o HTML 5 cobre muitos outros pontos para
alem das OWA que saem completamente fora do ambito do Gears Se esta es-
pecificacao atingir um estado de maturidade que possibilite a sua adopcao pelos
principais browsers tornando nativo do browser o suporte OWA entao deixara de
fazer sentido a existencia de uma extensao como o Gears
A especificacao HTML 5 disponibiliza duas APIs relevantes para o tema das
OWA
1 Uma base de dados baseada em SQL que permite o armazenamento de dados
do lado do cliente
2 Uma ldquocacherdquo HTTP que garante a disponibilidade das aplicacoes mesmo quando
o utilizador nao possui uma ligacao a Internet
Estas caracterısticas sao as bases da tecnologia das OWA e tem correspondencia
com os pontos analisados nas seccoes 311 e 311
35 Web applications que usam funcionalidades offline
Nesta seccao apresentam-se algumas web applications que actualmente disponi-
bilizam funcionalidades offline Estas aplicacoes foram escolhidas para uma analise
mais pormenorizada por utilizarem o Gears que tal como descrito na seccao 4 foi
a tecnologia escolhida para o projecto
351 Google Reader e Google Docs
O Google Reader7 e um leitor de feeds RSS Permite gerir a subscricao de varios
sites simultaneamente que disponibilizem conteudos neste formato e foi a primeira
web application da Google com uma versao offline publicamente acessıvel (desde
Junho de 2007)
O Google Reader implementa o modo ldquoutilizador deciderdquo oferecendo na sua
interface um botao que permite alternar entre os modos online e offline
O Google Docs8 e uma web application que permite a criacao e edicao de doc-
umentos de texto folhas de calculo e apresentacoes Era ja publico desde Janeiro
de 2008 que o Google estava a desenvolver uma versao OWA desta aplicacao mas o
acesso a uma versao experimental so foi possıvel a partir de 31 de Maio de 2008
7Google Reader - httpreadergooglecom8Google Docs - httpdocsgooglecom
26
Estado da arte
A implementacao das funcionalidades offline nestas duas aplicacoes seguiu difer-
entes aproximacoes principalmente porque o Google Reader apresenta ao utilizador
informacoes que sao fornecidas por fontes externas enquanto que no Google Docs
a informacao e criada e editada pelo utilizador sobre a forma de documentos
A diferente origem da informacao implica que no Google Reader seja necessario
prever casos de excepcao tal como existirem demasiados itens que necessitam de
ser transferidos para o cliente Nao observar este ponto causa um problema grave
de usabilidade e para evitar tempos de espera demasiado longos e uma interface
com pouca capacidade de resposta as accoes do utilizador o Google Reader apenas
transfere para o cliente os dois mil itens mais recentes na transicao para o modo
offline
352 Remember the Milk
O Remember The Milk9 e uma web application desenvolvida por uma equipa
Australiana que proporciona funcionalidades de agenda gestao de tempo e de tare-
fas e foi uma das primeiras aplicacoes independentes do Google a adoptar o Gears
para acessos em modo offline Permite que os seus utilizadores facam uma gestao
de tarefas agrupando-as em listas adicionando-lhes campos de informacao adicional
ou dando-lhes informacao geografica (recorrendo ao servico Google Maps10) Entre
a sua lista de funcionalidades encontra-se ainda a possibilidade de importar e ex-
portar eventos no formato iCalendar (ics) etiquetas (tags) em tarefas publicacao
Really Simple Syndication (RSS) e partilha de categorias de tarefas de acordo com
diferentes nıveis de permissoes de acesso definidos pelo utilizador
353 MySpace e WordPresscom
O MySpace uma das maiores social networks na Internet anunciou recente-
mente que vai disponibilizar uma versao do seu cliente de e-mail que utiliza o Gears
para acelerar o seu desempenho Numa fase inicial estara disponıvel apenas para
utilizadores que tenham cinco mil ou mais mensagens na sua caixa de correio e
permitira efectuar pesquisas muito mais rapido que a sua versao online
O servico de blogs Wordpresscom anunciou tambem o inıcio da utilizacao desta
tecnologia com o fim de melhorar o desempenho A versao que utiliza esta tecnologia
descarrega e armazena no cliente um conjunto de imagens e scripts que passam a
ter preferencia sobre os seus congeneres online e que permitem acelerar o processo
de carregamento da aplicacao e visualizacao de blogs
9Remember The Milk ndash httpwwwrememberthemilkcom10Google Maps ndash httpmapsgooglecom
27
Estado da arte
O MySpace e o Wordpresscom sao dois exemplos da utilizacao da tecnologia
OWA para optimizacao de web application ja existentes Sem pretenderem disponi-
bilizar uma versao que seja totalmente offline fazem uso do Gears para armazenar no
cliente parte dos recursos frequentemente acedidos na visualizacao das suas paginas
36 Escolha da tecnologia
Apos a analise das tecnologias apresentada nas seccoes 31 a 34 foi necessario es-
tudar a adequacao de cada uma delas ao projecto em questao Desde logo e possıvel
observar que nem todas se dedicam apenas a OWA Por exemplo o Adobe AIR
apesar de ter suporte para OWA apenas disponibiliza algumas das funcionalidades
identificadas como mais indicadas para a execucao do projecto quando utilizado
na sua vertente desktop tal como exposto na Tabela 31 mas a utilizacao desta
vertente implicaria o desenvolvimento de novas interfaces e de novas formas de co-
municacao (troca de mensagens XML ou JSON) A vertente web do Adobe AIR
foca-se mais especificamente nas Rich Internet Applications e permite a reutilizacao
do codigo ja existente (exigindo naturalmente a sua adaptacao e a implementacao
das funcionalidades pretendidas)
A tecnologia escolhida para a realizacao deste trabalho foi o Gears sendo que
um dos principais factores a influenciar esta opcao foi a liberdade introduzida pela
sua licenca Berkeley Software Distribution (BSD)11
Considerou-se o funcionamento desta ferramenta extremamente adequando a
aplicacao no WOW uma vez que o seu principal objectivo e precisamente tornar
possıvel a execucao offline de uma pagina web e por virtude deste facto o Gears tem
uma API concisa e de simples aplicacao pratica uma vez que nao possui quaisquer
outros elementos distractores O funcionamento do seu ManagedResourceStore ex-
emplificado na Figura 31 com a capacidade de actualizacao de recursos definidos
num ficheiro manifesto especificado em JSON pesou tambem nesta decisao
11Sobre a licenca BSD consultar httpwwwopensourceorglicensesbsd-licensephp e http
wwwlinfoorgbsdlicensehtml
28
Estado da arte
Figura 31 Esquema UML do processo efectuado pelos recursos do Gears do tipoManagedResourceStore para a actualizacao dos conteudos definidos no ficheiro manifesto
29
Estado da arte
Funcionalidade RIAs no browser RIAs no desktop
Disponibilidadeda aplicacao
As aplicacoes podem ser facil-mente exploradas e utilizadas
As aplicacoes quando instal-adas tem maior grau de fun-cionalidades e persistencia
Instalacao Nao e necessario qualquer tipode instalacao
As aplicacoes sao instaladasatraves do browser ou descar-regadas e instaladas comouma aplicacao tradicional
Actualizacoes Aplicacoes sao actualizadascarregando conteudos paraum website
O AIR disponibiliza uma APIque permite que as aplicacoessejam actualizadas de umaforma
Sistemas opera-tivos suportados
As aplicacoes podem ser exe-cutadas em diversos sistemasoperativos e browsers
As aplicacoes sao multi-plataforma e podem serinstaladas e executadas emdiversos sistemas operativos ebrowsers
Linguagens deprogramacao
Javascript e disponibilizadopelo browser e ActionScripte disponibilizado pelo AdobeFlash Player
Maquinas virtuais deJavascript e ActionScriptcompatıveis com o browser
Capacidade deexecucao embackground
As RIAs podem ser execu-tadas numa janela do browser
As aplicacoes podem ser ex-ecutadas em background edisponibilizar notificacoes talcomo uma aplicacao tradi-cional
Persistencia A actividade esta limitada asessao do browser Quando obrowser e encerrado toda ainformacao e descartada
As aplicacoes sao instaladas eestao disponıveis no desktopPodem armazenar informacaolocalmente e estao disponıveisoffline
Integracao com odesktop
Integracao com o desktop lim-itada devido a restricoes im-postas pelo browser
As aplicacoes podem acederao sistema de ficheiro ao clip-board eventos notificacoesetc
Controlo da inter-face com o uti-lizador
As aplicacoes sao acedidasatraves de uma janela dobrowser que tem os seusproprios controlos e visualgrafico
As aplicacoes tem um vi-sual grafico proprio em janelapropria
Armazenamentode dados
As aplicacoes tem armazena-mento limitado que pode serreescrito pelo browser
As aplicacoes tem acesso a to-talidade do espaco disponıvellocalmente e a uma base dedados com a possibilidade deencriptacao
Tabela 31 Comparacao das funcionalidades oferecidas pelo Adobe AIR para as platafor-mas web e desktop
30
Estado da arte
Aplicacao Modo de execucao utilizadoGoogle Reader Utiliza o modo ldquoutilizador deciderdquo disponibilizando
ao utilizador um botao para alternar entre os modosonline e offline Como lida com informacao recol-hida de fontes externas de natureza frequentementeefemera o processo de sincronizacao apenas transfereos dois mil itens mais recentes quando passa ao es-tado offline Neste modo sao ainda guardadas in-formacoes de itens lidos e etiquetas atribuıdas quesao sincronizadas com o servidor quando o utilizadorvoltar a activar estado online
Google Docs Utiliza o modo ldquoaplicacao deciderdquo permitindo que outilizador edite os conteudos de documentos de textofolhas de calculo e de apresentacoes independente-mente do estado da ligacao desde o momento em queas funcionalidades offline sao activadas A aplicacaofaz pequenas sincronizacoes com o servidor sempre quenecessario
Remember the Milk Utiliza um modo hıbrido entre ldquoaplicacao deciderdquo eldquoutilizador deciderdquo A aplicacao encarrega-se da sin-cronizacao de dados mas disponibiliza um controlona sua interface que permite despoletar manualmenteeste processo para situacoes em que o utilizador fez al-teracoes recentes e pretende usufruir das capacidadesoffline imediatamente
MySpace O MySpace anunciou a utilizacao de mecanismos dearmazenamento de dados no cliente com recurso atecnologias OWA para melhorar o desempenho doseu cliente web de correio electronico nomeadamenteno que diz respeito a operacoes de pesquisa e or-denacao Inicialmente esta funcionalidade estara ape-nas disponıvel para utilizadores com cinco mil ou maismensagens na sua caixa de correio mas nao e aindaclaro se sera disponibilizada uma versao totalmenteoffline
Tabela 32 Resumo da utilizacao de tecnologias OWA em algumas web applications con-sideradas na analise do estado da arte
31
Estado da arte
32
Capıtulo 4
Desenvolvimento
Neste capıtulo introduz-se a aplicacao WOW e apresenta-se o estudo que foi
feito da adequacao de cada tecnologia para a implementacao da funcionalidade of-
fline nesta plataforma Fazem-se diversas consideracoes sobre opcoes a tomar na
concepcao de OWAs e problemas comuns na sua implementacao bem como sug-
estoes para os resolver O WOW e uma aplicacao ja existente de gestao de ordens
de trabalho e do fluxo de tarefas numa empresa ou organizacao
41 Como ficar offline
Na maior parte das web applications de hoje nao existe uma camada de dados
real A aplicacao exemplificada na Figura 41 ao longo da sua execucao acede
directamente a sua unica fonte de dados (o servidor) atraves de chamadas Ajax sem
que exista uma separacao clara destas duas camadas
Para que uma web application seja capaz de ser executada sem uma ligacao
activa a Internet e mantenha o seu caracter dinamico torna-se necessario incluir
Figura 41 Exemplo de uma arquitectura de uma web application sem uma camada deabstraccao de dados Figura adaptada de http gears google com
33
Desenvolvimento
Figura 42 Exemplo de uma arquitectura de uma web application com uma camada deabstraccao de dados Figura adaptada de http gears google com
um mecanismo de armazenamento de dados local seja uma base de dados ou a
capacidade de acesso ao disco No entanto este mecanismo introduz dois problemas
1 Qual das fontes de dados utilizar quando um utilizador faz um pedido de
informacao
2 A necessidade de implementar uma camada de acesso a dados que seja coerente
quer se use o servidor remoto ou local
Por exemplo em vez de a aplicacao Ajax fazer um pedido relativo as contas de
todos os utilizadores em formato JSON directamente ao servidor remoto podera ao
inves fazer o pedido a um objecto intermedio da camada de dados Este objecto
demonstrado na Figura 42 sera responsavel por implementar uma interface de
acesso a base de dados e retornar um objecto JavaScript com uma representacao da
resposta do servidor
Mas a existencia de uma segunda fonte de dados torna recomendavel tambem
a implementacao de uma camada de data switching que em funcao da existencia
de conexao a Internet e da necessidade de actualizacao dos dados decide se faz o
pedido ao servidor remoto ou se fornece os dados presentes localmente Este objecto
apresentado na Figura 43 decidira de forma transparente para o utilizador se le ou
escreve os dados localmente ou se os enviapede ao servidor remoto e pode tambem
iniciar o processo de convergencia de dados e de resolucao de conflitos
411 Funcionalidades disponıveis em modo offline
Por razoes praticas e provavel que nem todas as funcionalidades da aplicacao
possam ser disponibilizadas em modo offline E necessario escolher quais as fun-
cionalidades a disponibilizar no modo offline da aplicacao e implementar a logica
que decide quando utilizar a base de dados local ou o servidor remoto Apesar do
acesso a base de dados local ser muito mais rapido do que aceder ao servidor o
acesso local nem sempre e preferido Ha varias razoes que podem tornar necessario
escolher o acesso ao servidor em vez do acesso local
34
Desenvolvimento
Figura 43 Exemplo de uma arquitectura de uma web application com uma camada deabstraccao de dados e um data switch Figura adaptada de http gears google com
1 A informacao pode ter uma natureza efemera e nao fazer sentido guarda-la
localmente Exemplo dados em tempo real da bolsa de valores de Lisboa
2 Algumas aplicacoes lidam com informacao que so faz sentido na presenca de
uma ligacao Exemplo Instant Messaging
3 A aplicacao podera escolher apenas guardar a informacao acedida mais fre-
quentemente Exemplo para o utilizador poder alterar a lıngua de apre-
sentacao da aplicacao os conteudos terao que ser guardados em todas as
lınguas disponibilizadas pela aplicacao O custo de implementacao de algu-
mas funcionalidades pode nao compensar o benefıcio
4 A capacidade de processamento ou de armazenamento de dados pode inviabi-
lizar algumas funcionalidades offline Exemplo se uma dada funcionalidade
necessita de uma capacidade de armazenamento de dados para alem do razoavel
de um computador pessoal para ser util (visualizador de mapas)
42 Modos de execucao
Um aspecto que e necessario estudar para qualquer web application que se deseje
disponibilizar offline prende-se com tres modos de execucao que devem ser consid-
erados
1 Utilizador decide o modo de execucao A aplicacao tem modos distintos
de execucao para os estados online e offline geralmente indicados na interface
com o utilizador O utilizador e informado do estado da ligacao e participa na
alteracao de estado de execucao da aplicacao interagindo com a sua interface
2 Aplicacao decide o modo de execucao Pode ser implementado na propria
aplicacao um mecanismo de deteccao do estado da ligacao (por exemplo atraves
35
Desenvolvimento
de chamadas Ajax periodicas) transitando de estado e sincronizando automati-
camente Desta forma o utilizador nao precisa de participar na alteracao de
estado a menos que exista um conflito de dados que requeira a sua atencao
3 Aplicacao assume sempre o estado offline Outra hipotese sera imple-
mentar uma web application que assume sempre estar na ausencia de uma
ligacao ao servidor de dados Esta aplicacao responde aos pedidos do uti-
lizador efectuando pedidos de informacao ao servidor mas nao dependendo
de uma resposta valida para mostrar a informacao que ja tinha disponıvel an-
teriormente A sincronizacao de dados com o servidor e tentada sempre que
existam dados para submeter e uma accao do utilizador
421 Modo ldquoutilizador deciderdquo
Neste modo de execucao quando a aplicacao esta online comunica com o servidor
remoto quando esta offline comunica com a base de dados local A informacao tem
que ser sincronizada sempre que se muda de modo A principal vantagem desta opcao
e que e a mais simples de implementar mesmo para uma aplicacao ja existente e
portanto uma forma expedita de disponibilizar uma OWA No entanto tem tambem
algumas desvantagens que devem ser consideradas
1 O utilizador tem que se lembrar de fazer a alteracao de estado de execucao
Caso contrario podera estar a trabalhar inadvertidamente numa versao offline
com dados antigos ou nao ter a informacao necessaria se perder subitamente
a ligacao
2 Se a ligacao for intermitente o utilizador tera ou que escolher um dos modos
de execucao ou estar constantemente a trocar
3 Uma vez que a base de dados nao esta sempre actualizada nao podera ser
utilizada para melhorar a rapidez de execucao da aplicacao quando em modo
online
422 Modo aplicacao decide
A deteccao do estado da ligacao pode ser implementada atraves de um pedido
assıncrono ao servidor tal como ilustrado na Figura 44 O resultado deste pedido
definira o estado online (em caso de sucesso) ou offline (em caso de falha) A
sincronizacao de dados podera ser feita sempre que ocorra uma transicao do es-
tado offline para o estado online No entanto este metodo nao se revela eficiente
36
Desenvolvimento
Figura 44 Esquema grafico ilustrando uma OWA executando no browser utilizando ummodo de execucao do tipo ldquoaplicacao deciderdquo com deteccao automatica do estado daligacao via pedidos Ajax assıncronos a cada cinco segundos
para grandes aplicacoes uma vez que requer a troca de mensagens demasiado fre-
quentes com o servidor que se destinam exclusivamente a monitorizacao do estado
da ligacao
423 Modo ldquoaplicacao assume o estado offlinerdquo
Uma aplicacao transparente funciona assumindo sempre que esta em modo of-
fline ou pelo menos que pode perder a ligacao a qualquer momento Neste modo
tira-se o maximo partido do armazenamento local e fazem-se pequenas mas contınuas
sincronizacoes com o servidor sempre que este esteja disponıvel A sincronizacao de
dados tambem e feita sempre que se volta ao estado online
As vantagens de uma web application transparente sao as seguintes
bull Uma melhor experiencia para o utilizador uma vez que este nao tem que se
preocupar com o estado da ligacao ou com a transicao de estados
bull A aplicacao funciona de forma coerente mesmo que a ligacao seja intermitente
bull Uma vez que o armazenamento local e mantido actualizado pode ser utilizado
para melhorar o desempenho da aplicacao
Foram identificadas as seguintes desvantagens
bull E mais difıcil de implementar e a sincronizacao acarreta cuidados especiais
bull E necessario um cuidado adicional para evitar que as operacoes de sincronizacao
frequentes que ocorrem automaticamente nao afectem os tempos de resposta
da aplicacao
bull Os testes a aplicacao sao mais complexos uma vez que a sincronizacao de dados
nao ocorre em resposta a uma accao do utilizador
37
Desenvolvimento
43 Sincronizacao de dados
A sincronizacao de dados consiste na capacidade de identificar e transferir pe-
riodicamente a versao mais actual dos dados entre o cliente e o(s) servidor(es)
Independentemente do modo de execucao escolhido e mesmo do estado da ligacao
do utilizador a informacao armazenada localmente e a informacao armazenada no
servidor estarao por vezes dessincronizadas Isto podera acontecer sempre que por
exemplo
bull O utilizador faz alteracoes em modo offline
bull A informacao e partilhada e pode ser alterada por uma entidade externa
bull A informacao e fornecida por uma entidade externa
Resolver estas diferencas de forma a que a informacao local e remota encontrem
a igualdade chama-se sincronizacao de dados Ha varias aproximacoes possıveis
para este efeito que dependem da natureza da aplicacao cada uma com vantagens
e desvantagens
A capacidade de suportar a mobilidade dos utilizadores torna-se cada vez um
ponto mais importante de uma web application Para uma organizacao de dimensao
global e vital garantir que os seus colaboradores tem acesso a mesma informacao
que tem disponıvel nos seus postos de trabalho mesmo quando estao fora Na maior
parte dos casos estes colaboradores terao acesso a um computador portatil um
desktop Smartphone ou PDA e atraves destes poderao ter acesso a sua informacao
directamente atraves de ligacoes encriptadas Virtual Private Network (VPN) de um
servidor web ou de outro mecanismo de rede
Esta solucao e simples de implementar mas infelizmente para a maioria dos
colaboradores com grande factor de mobilidade nao e satisfatoria As principais
desvantagens sao as seguintes
bull Requisitos de ligacao Para permitir que os utilizadores acedam a sua in-
formacao e necessario garantir a capacidade constante de comunicacao pelo
menos durante o tempo necessario que assegure a sua transferencia
bull Velocidade de ligacao sem persistencia de dados e em ligacoes de fraca
qualidade a usabilidade por vezes torna-se inaceitavel
bull Ponto crıtico de falha Com este tipo de solucao todos os utilizadores de-
pendem da base de dados que armazena informacao vital para o funcionamento
do cliente
38
Desenvolvimento
bull Scalability do servidor A medida que novos utilizadores sao adicionados ao
sistema o desempenho do servidor e afectado levando a necessidade de maior
capacidade de armazenamento eou processamento
De acordo com a documentacao da Microsoft Sync Framework [Mic08] uma
solucao alternativa consiste em implementar uma Occasionally Connected Appli-
cation (OCA) Uma OCA permite a um utilizador remoto continuar a aceder a
sua informacao mesmo depois de perder a ligacao mas em vez de recorrer a um
servidor recorre a informacao armazenada no seu dispositivo local Para preencher
localmente a informacao que o utilizador necessita uma OCA possui mecanismos
de sincronizacao de dados que sao oferecidos por esta framework
431 Quando sincronizar
Uma das solucoes mais simples de implementar passa por disponibilizar um
mecanismo manual que despoleta a sincronizacao Diz-se manual porque e o uti-
lizador que escolhe quando sincronizar e pode ser implementada simplesmente
fazendo o upload de toda a informacao para o servidor e depois fazendo o download
da copia mais recente da informacao antes de voltar a ficar offline Para que esta
seja uma opcao viavel e necessario que
bull O volume de dados seja suficientemente pequeno para que possa ser transferido
do servidor para o cliente num espaco de tempo aceitavel
bull Que o utilizador indique explicitamente que quer mudar para o estado offline
ou online pressionando um botao da interface
Contudo podem ser identificados alguns problemas relacionados com esta abor-
dagem
bull Os utilizadores nem sempre podem prever o estado das suas ligacoes A ligacao
pode-se perder subitamente ou ter um caracter intermitente
bull O utilizador pode esquecer-se de efectuar a sincronizacao
Outra opcao sera conjugar a sincronizacao de dados com o modo de execucao
transparente A sincronizacao ocorre automaticamente em background de forma
nao intrusiva para o utilizador A aplicacao comunica com o servidor regularmente
efectuando pequenas trocas de dados com o objectivo de manter o sincronismo da
informacao local e remota Esta abordagem pode ser implementada com pedidos
Ajax assıncronos e regulares ao servidor o que permite manter a interaccao com a
interface fluıda evitando bloqueios Estes pedidos sao feitos prevendo as situacoes
39
Desenvolvimento
de disponibilidade ou indisponibilidade (timeout) do servidor Uma outra opcao
sera permitir que o servidor comunique essas alteracoes utilizando Comet1 tal como
descrito em [Wil06] e [Rus06] As vantagens destas aproximacoes sao
bull A informacao esta disponıvel a qualquer altura que o utilizador decida ficar
offline ou que a ligacao seja acidentalmente perdida
bull O desempenho da aplicacao pode ser melhorado quando se estiver a utilizar
uma ligacao a Internet lenta uma vez que o acesso a dados locais e mais
eficiente do que a consulta de dados ao servidor
44 WOW
O WOW e uma plataforma integrada de gestao de ordens de trabalho ja ex-
istente e desenvolvida pela Critical Software SA a qual se pretende adicionar a
capacidade de execucao offline Esta aplicacao e extremamente dinamica e con-
figuravel com um conjunto extremamente rico de funcionalidades das quais se
destacam
bull Gestao de Ordens de Trabalho ndash suportando a gestao dos pedidos desde a
sua criacao ate ao seu fecho tomando em conta os diferentes tipos de pedidos
(ordens de trabalho pedidos de informacao melhorias resolucao de problemas
etc) e diferentes tipos de accoes possıveis para cada um (Figura 45)
bull Monitorizacao de alteracoes ndash Historico de mudancas anexos e estados criando
relatorios de alteracao automaticamente (o que por quem e quando)
bull Uso de Service Level Agreements (SLAs) ndash E possıvel associar a um pedido um
SLA que define qual o perıodo de tempo atribuıdo a resolucao de um pedido
controlando e agilizando a resolucao do mesmo
bull Utilizacao de queries de utilizador configuraveis que permitem acesso rapido
a determinadas ordens de trabalho de acordo com o filtro configurado (por
exemplo ldquoPara mimrdquo ldquoPara o Grupordquo ldquoPelo Grupordquo)
bull Gestao do relacionamento entre pedidos
bull Pesquisa e filtragem de ordens de trabalho
bull Exportacao de dados em formatos padrao (PDF DOC ou XLS)
bull Integravel com solucoes externas
40
Desenvolvimento
Figura 45 Detalhe de um conjunto possıvel de estados e respectivas transicoes para umadada ordem de trabalho no WOW desde a sua submissao no sistema ate a sua conclusaoem fecho ou cancelamento Esta figura representa apenas um exemplo ja que o mapa deestados para uma ordem de trabalho e dinamico e pode ser alterado por um administradorFigura retirada de uma brochura promocional do WOW Critical Software SA
A utilizacao de uma ferramenta deste tipo por parte de uma empresa ou orga-
nizacao oferece vantagens quer a gestao de topo quer aos colaboradores individuais
para os colaboradores individuais o WOW e uma aplicacao onde estao registadas
todas as tarefas contribuindo activamente para o desenvolvimento em ambientes
multi-tarefa e para a organizacao pessoal das tarefas de acordo com prioridades
Para a gestao de topo esta ferramenta permite obter uma visao global do estado da
organizacao em termos de tempo gasto por tarefa executada sendo uma mais valia
para a previsao e gestaoalocacao de recursos
45 Visao geral sobre a arquitectura do WOW
O WOW e interessante nao so do ponto de vista de produto como tambem do
ponto de vista de plataforma Existem diversos plug-ins que estendem as funcional-
idades do WOW e existem ate projectos que pretendem usar a arquitectura do
WOW para criar produtos com fins diferentes do inicial (por exemplo o WOW-
Storm ndash um sistema de registo e classificacao social de ideias)
De modo a conseguir ter essa expansibilidade a plataforma WOW assenta sob
uma arquitectura distribuıda modular e expansıvel com uma componente central
ndash o core ndash estruturado em camadas logicas E no core que se situam todas as
1O Comet e um conceito semelhante ao Ajax introduzido por Alex Russel mas no qual e o servidor quetoma a iniciativa de ldquoenviarrdquo os dados ao browser sem que este tenha que efectuar um pedido Tambem econhecido por Ajax Push Reverse Ajax ou HTTP Streaming
41
Desenvolvimento
funcionalidades base da aplicacao quer a nıvel logico funcional e de apresentacao
quer a nıvel de gestao e configuracao
E possıvel a execucao de varias instancias do core simultaneamente em servidores
distintos o que permite a alta escalabilidade e disponibilidade desta aplicacao A
consistencia dos dados fica sempre garantida atraves da partilha da base de dados
e pelo balanceamento dos pedidos uma vez que cada um e encaminhado para uma
unica instancia
O WOW apresenta tambem a vantagem de ser uma plataforma extensıvel E
possıvel adicionar novas caracterısticas a plataforma atraves de componentes que se
podem ser divididos em duas categorias plugins e connectors
Os plugins sao componentes que se encontram no mesmo no fısico que a aplicacao
partilhando do mesmo contexto de execucao do core Sao assim uma forma mais
directa de obter informacao da plataforma visto que nao possuem restricoes de
acesso aos dados nem dependencias externas A arquitectura deste componente tera
assim que permitir varias execucoes instanciadas cada uma associada a um core
Por outro lado os connectors sao componentes que se encontram distribuıdos
comunicando externamente com o core Quer a sua execucao quer a obtencao
dos dados estao assim dependentes de interfaces de comunicacao externas que a
plataforma disponibiliza Estes componentes ao contrario dos plugins sao instan-
ciados unicamente e recorrem ao protocolo de comunicacao Java Messaging Service
(JMS) para comunicar com o core
46 WOW Offline
Para alem das opcoes tomadas relativamente a tecnologia a utilizar surgiu
tambem a necessidade de optar por um dos modos de execucao apresentados na
seccao 42
Das tres opcoes possıveis foi o modo ldquoaplicacao assume o estado offlinerdquo descrito
na seccao 423 que mereceu a maior atencao uma vez que reune as vantagens de
uma experiencia mais positiva para o utilizador (uma vez que este nao tem que
participar activamente na alteracao do modo execucao como descrito na seccao 421)
e nao constitui uma sobrecarga excessiva para servidor (como o modo abordado na
seccao 422)
No entanto esta opcao comprometia a complexidade da implementacao para alem
dos objectivos propostos para este projecto e para cumprir o prazo dado foi tomada
a decisao de implementar o modo ldquoutilizador deciderdquo especificando apenas de forma
teorica o modo ldquoaplicacao assume o estado offlinerdquo
As caracterısticas do Gears foram ja descritas na seccao 31 Na Figura 47
mostra-se a sua forma de funcionamento quando integrado numa web application
42
Desenvolvimento
Nesta figura representa-se o modulo LocalServer do Gears como um ponto de de-
cisao Aqui sao testadas as condicoes que determinam se o pedido sera interceptado e
servido localmente ou se prossegue para uma maquina remota E tambem represen-
tada uma base de dados que corresponde ao modulo Database mas que podera nao
ser utilizada Este modulo tal como o modulo Workerpool tem caracter opcional
e sao utilizados consoante os requisitos da aplicacao
A plataforma WOW lida com mais dados do que e necessario passar para o
lado do cliente Em conformidade com o ja exposto na seccao 411 volta-se a
frisar que nao se pretende recriar toda a logica de negocio nem os conteudos da
base de dados no cliente pela sua complexidade e volume de dados Pretende-se
pelo contrario permitir que os utilizadores tirem partido da capacidade de poder
consultar as suas ordens de trabalho quando nao dispoe de uma ligacao transferindo
apenas o essencial para isto seja possıvel
A pagina inicial do WOW apresenta um resumo das ordens de trabalho abertas
ndash enviadas e recebidas ndash que se pretende permitir visualizar offline (ver Figura 46)
Como prova de conceito foi efectuada uma abordagem pragmatica das varias possi-
bilidades descritas na seccao 42
461 Modo ldquoaplicacao deciderdquo com deteccao automatica da ligacao
A primeira abordagem estudada para a disponibilizacao das funcionalidades of-
fline foi o modo ldquoaplicacao deciderdquo com deteccao automatica de ligacao apresentado
na seccao 422 Para que isto seja possıvel foi implementado um mecanismo de ver-
ificacao periodica do estado da ligacao atraves de chamadas Ajax assıncronas O
resultado destes pedidos determina o estado da aplicacao executando as tarefas de
sincronizacao de dados sempre que pertinente Este metodo embora imediato e
simples de implementar depressa se revelou inadequado para o projecto devido ao
elevado consumo de recursos do servidor que a utilizacao intensiva faz esperar a
comunidade da plataforma WOW no principal cliente excede os 7000 utilizadores
Foi estimado que para uma utilizacao de fluidez aceitavel o estado da ligacao deveria
ser testado a cada cinco segundos Assumindo uma adesao (previsao pessimista) de
1 aos servicos offline assistir-se-ia a cerca de 840 pedidos adicionais por minuto
Mas o principal problema desta aproximacao prende-se com o facto de a ver-
ificacao ser feita em intervalos de tempo discretos levando a possibilidade de a
aplicacao poder ter em dado momento uma representacao errada do seu estado
real da ligacao Este problema e ilustrado na Figura 48 onde se ve claramente a
discrepancia entre o estado real da ligacao e a representacao interna que esta tem
Note-se que nesta janela de tempo qualquer accao do utilizador que exija uma
resposta sıncrona do utilizador leva-lo-a para um ldquobeco sem saıdardquo onde nao tera
43
Desenvolvimento
Figura 46 A pagina inicial do WOW apresenta um resumo das ultimas ordens de trabalhoenviadas e recebidas Na imagem pode-se observar a transicao do estado online para offline
acesso a versao offline porque a aplicacao nao fez a transicao automatica nem acesso
a versao online porque na verdade nao possui uma ligacao O que acontecera nesta
situacao sera uma tentativa de acesso ao servidor por parte da aplicacao numa
altura em que este se encontra indisponıvel e o resultado sera uma mensagem de
ldquopedido excedeu o tempordquo apresentado pelo browser Este e um estado sem retorno
porque apos o browser apresentar esta mensagem todos os recursos JavaScript ficam
indisponıveis tornando impossıvel o regresso ao estado anterior ou o tratamento do
erro de qualquer outra forma No entanto as chamadas Ajax podem ser tratadas de
forma especial para a eventualidade de falha e portanto nao constituem problema
44
Desenvolvimento
Figura 47 Ilustracao do funcionamento do Gears numa web application que utiliza ummotor Ajax Os pedidos HTTP ou HTTPS podem ser interceptados e tratados localmenteou podem ser feitos a uma maquina remota consoante se verificarem ou nao as condicoesexpressas no ponto 311 E representado um acesso a uma base de dados local (fornecidapelo Gears) mas a sua utilizacao e opcional
462 Implementacao do modo ldquoutilizador deciderdquo
Este modo de execucao foi ja descrito na seccao 421 e a sua principal carac-
terıstica e ser o utilizador a decidir se a aplicacao deve utilizar um servidor remoto
ou a maquina local como fornecedor de dados
Relativamente ao WOW o WOW Offline na vertente ldquoutilizador deciderdquo vem
alterar os seus casos de uso dando ao utilizador a possibilidade de alterar o estado
de execucao da aplicacao (entre online e offline) Resta dizer que no modo online se
mantem todas as funcionalidades anteriores e que no modo offline torna-se possıvel
visualizar os conteudos da pagina principal do WOW (Figura 46) e os detalhes das
ordens de trabalho (Figura 49) tal como expressa a Figura 410
Esta aproximacao foi utilizada na prova de conceito do WOW adicionando um
controlo a interface desta aplicacao que permite ao utilizador alternar entre os esta-
dos online e offline Na transicao de online para offline sao descarregados os recursos
necessarios para a execucao desta aplicacao sem recorrer a Internet Para o fazer
45
Desenvolvimento
Figura 48 Neste exemplo do modo ldquoaplicacao deciderdquo o teste da ligacao e feito e feito acada cinco segundos O resultado deste teste nao reflecte sempre o estado real da aplicacaopodendo levar a aplicacao a ter comportamentos indesejaveis Na figura assinala-se umperıodo de tempo no qual a representacao interna do estado da ligacao nao corresponde arealidade
e utilizado um recurso ResourceStore e um ManagedResourceStore (introduzidos
em 311) O primeiro e utilizado para armazenar a pagina principal do WOW ndash do-
ravante designada por homejsp ndash e o segundo e utilizado para armazenar imagens
folhas de estilo CSS e scripts JavaScript
Para a implementacao deste modo de execucao foram identificadas as seguintes
tarefas
1 Guardar informacao que permita a recriacao das paginas que se pretende
disponibilizar offline (utilizando o Gears)
2 Disponibilizar um controlo que permita alterar o estado de execucao atraves
da interaccao com a pagina principal
3 Durante a sincronizacao de dados apresentar o progresso da transferencia de
dados
O primeiro passo consistiu na identificacao de todos os conteudos que sao necessarios
transferir para a execucao offline Foi utilizado um recurso do Gears do tipo
ManagedResourceStore que recorre a um ficheiro manifesto para identificar to-
dos os ficheiros que deve transferir Este recurso e gerido automaticamente pelo
Gears transferindo para o cliente a versao mais recente sempre que e necessario
isto e sempre que exista um ficheiro manifesto com uma identificacao de versao que
seja diferente da actualmente disponıvel no cliente Uma vez identificados todos
ficheiros necessarios para a execucao offline num (ou mais) ficheiros manifesto o
Gears encarrega-se da sua actualizacao mas o preenchimento destes ficheiros man-
ifesto e manual o que se traduz num cuidado extra na manutencao da aplicacao
A forma como esta informacao e guardada deve tambem ser cuidadosamente
estudada A opcao mais flexıvel passa por utilizar o modulo Database apresentado
na seccao 311 e guardar a informacao de uma forma relacional Para a recriacao
das paginas pode ser disponibilizada uma versao HTML da pagina que funciona
46
Desenvolvimento
Figura 49 Pagina de visualizacao do detalhe de uma ordem de trabalho
como template nao possui quaisquer dados e e utilizada apenas em modo offline E
preenchida para cada pedido retirando os dados relevantes da base de dados
O modelo de dados do WOW torna esta opcao extremamente trabalhosa uma
vez que as entidades envolvidas na geracao de cada pagina de informacao sobre
cada ordem de trabalho tem relacoes de dependencia complexas seguindo padroes
muito variaveis Por exemplo em cada ordem de trabalho existe um formulario que
permite a sua progressao de estado com diversos campos opcionais e obrigatorios
este formulario e definido pelo administrador e esta relacionado nao apenas com o
tipo de ordem de trabalho mas tambem com o estado actual em que esta se encontra
e a accao que se pretende realizar O elevado numero de combinacoes de tipos de
ordem de trabalho estados e accoes que existem num dado momento juntamente
com a sua possibilidade de alteracao obrigariam a implementacao de uma logica de
negocio complexa o que esta fora do ambito deste projecto
47
Desenvolvimento
Figura 410 Esquema UML que expressa os casos de uso do WOW Offline no modoldquoutilizador deciderdquo
463 Especificacao do modo ldquoaplicacao assume o estado offlinerdquo
A aproximacao para o modo ldquoaplicacao assume o estado offlinerdquo foi tambem
dividida em varias tarefas
1 Guardar informacao que permita a recriacao da pagina principal do lado do
cliente no estado offline (utilizando o Gears)
2 Dotar a aplicacao do cliente de um mecanismo de deteccao da ligacao
3 Identificar os ldquomomentos chaverdquo em que devera ocorrer sincronizacao de dados
4 Implementar a sincronizacao de dados
A sincronizacao de dados deve ser feita em ambas as transicoes online-offline e
offline-online quer para transferir novos dados do servidor (os pedidos podem ser
alterados por outros utilizadores) quando se transita do estado quer para comunicar
eventuais alteracoes feitas em modo offline
Relativamente ao WOW o WOW Offline na vertente ldquoaplicacao assume o es-
tado offlinerdquo vem alterar os seus casos de uso dando ao utilizador a possibilidade
de activar esta funcionalidade A partir do momento que a funcionalidade esta ac-
tivada o utilizador deve tambem ter a possibilidade de gerir algumas preferencias
relacionadas com privacidade de dados Devera ter a hipotese de desactivar o ar-
mazenamento local e de remover todos os dados ja armazenados tal como descrito
na Figura 411
48
Desenvolvimento
Figura 411 Esquema UML que expressa os casos de uso do WOW Offline no modoldquoutilizador deciderdquo
A primeira vez que o WOW Offline e acedido por um cliente e caso seja detec-
tada a presenca do Gears todos os recursos necessarios a sua execucao sao trans-
feridos Todos os acessos posteriores serao feitos a estes recursos locais (recorda-se
que o Gears pode ser utilizado para os manter actualizados recorrendo ao Managed-
ResourceStore 311)
Atraves do JavaScript e possıvel interceptar os eventos de load e unload da
pagina que sao despoletados sempre que ocorre um re-acesso da mesma (incluindo
a accao refresh comum dos browsers) sempre que esta e abandonada ou ainda ou
ainda se a janela for encerrada
Tal como sugerido na seccao 462 a camada de interface desta aplicacao (cada
pagina individual em HTML) devera ser implementada como sendo um template
para apresentacao de dados sendo totalmente preenchida atraves de funcoes em
JavaScript O objectivo deste ponto e criar um padrao de dados que permita ao
JavaScript preencher os dados em cada pagina (template) independentemente de
qual seja a fonte ndash o servidor remoto ou a maquina local tal como exemplificado
no diagrama da Figura 412 Na figura a aplicacao recorre ao servidor remoto para
obter os dados pretendidos quando se encontra na presenca de uma ligacao mas
para dados que exijam uma carga de processamento pelo servidor este acto pode ser
49
Desenvolvimento
Figura 412 Esquema UML que expressa o acto de recolha de dados em modo online eoffline recorrendo ao servidor (modo online) e ao sistema de armazenamento de dadoslocal fornecido pelo Gears (modo offline)
substituıdo pelo envio de um campo de controlo que se destina a aferir se os dados
locais se encontram actualizados No caso de estarem actualizados a comunicacao
com o servidor pode ser substituıda por uma query a base de dados local
50
Capıtulo 5
Resultados e Futuros
Desenvolvimentos
Todo o estudo feito sobre o tema OWA foi ja abordado ao longo do documento
Neste capıtulo apresentam-se os resultados obtidos na implementacao da prova de
conceito que visava compreender a melhor forma de disponibilizar uma versao of-
fline no WOW uma plataforma de gestao de ordens de trabalho ja existente de-
senvolvida pela Critical Software SA
51 Resultados Obtidos
Os resultados obtidos neste projecto sao extremamente satisfatorios uma vez
que o estudo do tema OWA e a implementacao de uma prova de conceito que o
ilustrasse foi conseguido com sucesso
A funcionalidade offline foi adicionada ao produto WOW da Critical Software
SA permitindo a visualizacao de ordens de trabalho e dos seus detalhes mesmo na
ausencia de uma conexao activa a Internet Embora para a solucao implementada
tenha sido utilizada uma abordagem do tipo ldquoutilizador deciderdquo pretende-se que esta
seja convertida para ldquoaplicacao deciderdquo ou mesmo para uma aproximacao hıbrida
semelhante a utilizada pelas aplicacoes estudadas nas seccoes 351 e 352
Para a sua implementacao descrita no capıtulo 4 foram tomadas decisoes de or-
dem pratica que permitissem tornar o trabalho exequıvel nos prazos dados Tentou-
se sempre que estas decisoes afectassem o mınimo em termos de desempenho e de
experiencia para o utilizador Considera-se que a implementacao do modo offline
com uma transicao entre modos do tipo ldquoutilizador deciderdquo (ver seccao 42) reflecte
o compromisso entre o desempenho pretendido e os recursos disponıveis e para alem
51
Resultados e Futuros Desenvolvimentos
de ser um exemplo eficaz das possibilidades que as OWA podem trazer a aplicacao
WOW desenvolvida pela Critical Software e tambem um estudo que pode ser uti-
lizado para analisar a implementacao desta tecnologia noutros produtos da mesma
empresa
Note-se que o principal objectivo do trabalho era ganhar familiaridade com este
tema entender as suas vantagens e desvantagens e compreender as suas limitacoes
Tudo indica que existam varias possibilidades de implementacao deste paradigma
noutros produtos da Critical Software que pela sua natureza podem tambem tirar
partido da execucao offline
52 Trabalho Futuro
O desenvolvimento do conceito e formas de implementacao de OWA continua
em forte desenvolvimento no entanto a sua adopcao ainda nao e generalizada A
dificuldade da sua implementacao em web applications ja existentes e o principal
obstaculo a sua maior divulgacao
Ha tambem um factor que deve ser tido em consideracao a manutencao de
codigo A implementacao de uma versao offline de uma web application requer
a implementacao das mesmas regras de negocio (ou de uma versao simplificada)
utilizadas no servidor Para que isto seja possıvel e necessario ter em conta a
capacidade de processamento do cliente e o factor de duplicacao de codigo que
tornara a aplicacao mais difıcil de manter uma vez que uma alteracao a logica de
negocio do servidor implica tambem uma alteracao a sua versao offline
A prova de conceito implementada permite ja a visualizacao offline dos pedidos
abertos (enviados e recebidos) que constam na pagina principal (este numero e
fixo e pode ser alterado pelo administrador) Uma funcionalidade desejavel seria a
possibilidade de interaccao com a aplicacao em modo offline e sincronizacao com o
servidor quando existisse uma ligacao disponıvel
Foi estudada a utilizacao do modo de execucao ldquoaplicacao assume o estado of-
flinerdquo descrito em 423 e esta seria a forma desejavel para o WOW Offline no
entanto para que esta opcao seja viavel sera necessaria a implementacao de uma
forma eficiente de sincronizacao e armazenamento de dados de uma forma relacional
Para atingir este objectivo podera ser seguida uma polıtica de automacao do pro-
cesso no qual a versao online da aplicacao gera scripts de criacao para as tabelas
necessarias na base de dados da versao offline (nao existe nenhuma ferramenta para
o fazer portanto seria necessaria a sua implementacao) e no qual as paginas HTML
disponibilizadas pelo servidor aos clientes web (browser) servem como templates de
apresentacao de informacao e sao preenchidas de forma semelhante pelo servidor ndash
quando a aplicacao estiver online ndash ou pelo cliente atraves de funcoes em JavaScript
52
Resultados e Futuros Desenvolvimentos
ndash quando a aplicacao estiver offline No entanto no WOW devido a quantidade de
informacao tratada e devido as complexas relacoes entre as diferentes entidades e
de esperar que a complexidade da implementacao de um mecanismo deste tipo torne
esta aproximacao demasiado custosa
O HTML 5 embora um forte candidato ainda nao esta suficientemente desen-
volvido A sua especificacao ainda tem o caracter de Draft (rascunho) e esta sujeita
a modificacoes e a aceitacao e implementacao por parte dos browsers e portanto
de momento foi desconsiderado No entanto no futuro se esta especificacao atingir
um estado de maturidade que permita a sua adopcao devera ser considerada como
um possıvel caminho a seguir
53
Resultados e Futuros Desenvolvimentos
54
Capıtulo 6
Conclusoes
Neste capıtulo sao apresentadas as conclusoes do projecto e consideracoes finais
relativamente a tecnologia estudada
61 Conclusoes
O rapido desenvolvimento tecnologico faz prever que a disponibilidade de ligacao
a Internet seja cada vez mais facil e mais rapido mas vao continuar a existir lugares
onde o acesso e limitado e onde as OWA podem desempenhar um papel de relevo
Por outro lado esta tecnologia pode tambem ser utilizada para melhorar o desem-
penho de paginas web com uma necessidade elevada de imagens ou outros recursos
dispendiosos em termos de espaco e foram ate estudados dois exemplos da utilizacao
desta vertente desta tecnologia em 353
Acredita-se que as OWAs vem responder a uma necessidade real por parte das
web applications actuais e que a evolucao que representam se compara a que se
assistiu dos thin-clients para os fat-clients em termos de autonomia do servidor
A capacidade de oferecer conteudos dinamicos no browser independentemente da
existencia de uma ligacao reune as vantagens tıpicas das web applications como
ausencia de instalacao e actualizacoes instantaneas com as vantagens das aplicacoes
de desktop em capacidade de processamento e armazenamento de dados na maquina
local
As tecnologias disponıveis ate a data estudadas no ambito deste projecto que
permitem o desenvolvimento de OWAs e que apresentam maior maturidade sao o
Gears e o Adobe AIR Ambas se apresentam sobre a forma de plugins que necessitam
de uma instalacao extra para poderem ser utilizadas Apesar de esta instalacao ser
55
Conclusoes
apenas necessaria uma vez podera constituir um factor de desencorajamento a sua
adopcao
O HTML 5 uma especificacao abordada neste documento na seccao 34 podera
ser uma alternativa que oferece funcionalidades offline a uma web application sem a
necessidade de qualquer instalacao no entanto esta especificacao ainda nao foi aceite
pelos principais browsers ndash o documento que define o HTML 5 ainda tem o estatuto
de Draft ndash e ainda nao e possıvel antecipar quando e que isto podera acontecer
Um dos problemas que surge frequentemente na implementacao de uma versao
offline para uma web application e a necessidade de sincronizacao de dados Quando
a informacao pode ser alterada por varios utilizadores simultaneamente e necessario
prever os conflitos que daı podem surgir e dotar a aplicacao de uma forma de os
resolver ou alertar o utilizador para a necessidade de alteracao dos dados
Em conclusao todos os objectivos propostos para este projecto foram atingidos
A prova de conceito implementada reflecte de forma clara as possibilidades oferecidas
pela tecnologia OWA e sera utilizado no futuro para compreender a melhor forma
de o implementar de forma definitiva no WOW
56
Referencias
[Ada08] Lucas Adamski Introducing Adobe AIR security model Fevereiro de2008 Disponıvel em httpwwwadobecomdevnetairarticles
introduction_to_air_securityhtml acedido em Marco de 2008
[Ado08] Adobe Adobe AIR 10 Security White Paper 2008 Disponıvel emhttpdownloadmacromediacompubairdocumentation1air_
securitypdf acedido em Marco de 2008
[Alm08] Dion Almaer Gears as a bleeding-edge html 5 implementa-tion March 2008 Disponıvel em httpalmaercomblog
gears-as-a-bleeding-edge-html-5-implementation acedido emMarco de 2008
[BL96] Tim Berners-Lee The world wide web Past present and future Agostode 1996 Disponıvel em httpwwww3orgPeopleBerners-Lee
1996ppfhtml acedido em Abril de 2008
[CDGH08] Mike Chambers Daniel Dura Dragos Georgita and Kevin Hoyt AdobeAIR for JavaScript Developers OrsquoReilly Media 2008 Disponıvel emhttponairadobecomfilesAIRforJSDevPocketGuidepdf ace-dido em Abril de 2008
[Con99] Jim Conallen Modeling Web Application Architectures with UML Junho1999 Disponıvel em httpwwwumlorgcnUMLApplicationpdf
webappspdf acedido em Maio de 2008
[Ent07] Entrust What is a public key information 2007 Disponıvel em http
wwwentrustcompkihtm acedido em Junho de 2008
[Gar05] Jesse James Garret Ajax A new approach to web applicationsFebruary 2005 Disponıvel em httpwwwadaptivepathcomideas
essaysarchives000385php acedido em Marco de 2008
[Greon] Philip Greenspun Philip and Alexrsquos Guide to Web Publishing 2003(last revision) Disponıvel em httpphilipgreenspuncompandaacedido em Junho de 2008
[Gro02a] App Design Group Thick vs thin client comparison 2002 Disponıvelem httpwwwdonjacobsvwcomimagesweekendspecials
Thick-vs-Thinpdf acedido em Junho de 2008
57
REFERENCIAS
[Gro02b] Technical Research Group Thin Client Tecnhology - WhitePaper 2002 Disponıvel em httpwwwpicktrgcompubs
thinclientwhitepaperpdf acedido em Junho de 2008
[Gro08] Miniwatts Marketing Group World internet usage March 2008Disponıvel em httpwwwinternetworldstatscomstatshtm ace-dido em Abril de 2008
[Hic08] Ian Hickson HTML 5 Draft Recommendation 2008 Disponıvelem httpwwwwhatwgorgspecsweb-appscurrent-work ace-dido em Marco de 2008
[Kha] Olga Kharif Top 10 municipal wifi plans Disponıvel em http
imagesbusinessweekcomss0608muni_wifiindex_01htm ace-dido em Marco de 2008
[Lab07] Mozilla Labs Prism Outubro 2007 Disponıvel em httplabs
mozillacom200710prism acedido em Marco de 2008
[Loo06] Chris Loosley Rich Internet ApplicationsDesign MeasurementandManagement Challenges 2006 Disponıvel em httpwwwkeynote
comdocswhitepapersRichInternet_5pdf acedido em Maio de2008
[Mic08] Microsoft Introduction to Occasionally Connected Applications us-ing Sync Services for ADONET 2008 Disponıvel em httpmsdn
microsoftcomen-ussyncbb887608aspx acedido em Junho de2008
[Nao08] Erica Naone Offline web applications Abril 2008 Disponıvelem httpwwwtechnologyreviewcomread_articleaspxch=
specialsectionsampsc=emerging08ampid=20245 acedido emAbril de 2008
[NJN00] Jason Nieh Yang S Jae and Naomi Novik A comparison of thin-clientcomputing architectures 2000 Disponıvel em httpwwwnclcs
columbiaedupublicationscucs-022-00pdf acedido em Maio de2008
[OrsquoR06] Tim OrsquoReilly Web 20 compact definition Trying again Dezembro2006 Disponıvel em httpradaroreillycomarchives200612
web-20-compact-definition-tryihtml acedido em Marco de 2008
[OrsquoR09] Tim OrsquoReilly What is Web 20 Design patterns and business modelsfor the Next Generation of Software 20053009 Disponıvel emhttpwwworeillynetcompubaoreillytimnews200509
30what-is-web-20html acedido em Marco de 2008
[Rus06] Alex Russel Comet Low latency data for the browser March Marco2006 Disponıvel em httpalexdojotoolkitorgp=545 acedidoem Marco de 2008
58
REFERENCIAS
[Sad97] Darleen Sadoski Clientserver software architecturesndashan overviewAgosto 1997 Disponıvel em httpwwwseicmuedustr
descriptionsclientserver_bodyhtml acedido em Junho de2008
[Sch96] George Schussel Clientserver past present and future 1996
[Smi07] Kevin C Smith Css filters - will the browser apply the rule July 2007Disponıvel em httpcentriclecomrefcssfilters acedido emMarco de 2008
[vK08] Anne van Kesteren The XMLHttpRequest Object W3C Work-ing Draft 15 Abril 2008 Disponıvel em httpwwww3orgTR
XMLHttpRequest acedido em Abril de 2008
[Wil06] Greg Wilkins Why ajax comet July Julho 2006 Disponıvel emhttpwwwwebtidecomdownloadswhitePaperWhyAjaxhtml ace-dido em Abril de 2008
59
REFERENCIAS
60
Anexo A
Screenshots
Algumas imagens de aplicacoes que utilizam funcionalidades offline ilustrativasda tecnologia abordada neste documento
Figura A1 Dialogo apresentado ao utilizador na primeira activacao das funcionalidadesoffline no Google Docs amp Spreadsheets
61
Screenshots
Figura A2 Na activacao das funcionalidades offline e tambem oferecida a possibilidadeda criacao de alguns atalhos por exemplo no ambiente de trabalho
Figura A3 O Google Docs mantem a todo o momento a possibilidade de alteracao destasdefinicoes ou da anulacao dos servicos offline para um dado computador
62
Screenshots
Figura A4 Apos a instalacao do Gears qualquer visita ao Remember The Milk despoletauma sincronizacao que ocorre automaticamente e sem necessidade de intervencao por partedo utilizador
Figura A5 Apos completar a sincronizacao de dados mesmo que a ligacao a Internetseja perdida o Remember the Milk continua disponıvel no browser (com excepcao dasfuncionalidades que pela sua natureza exigem uma ligacao como por exemplo partilhade tarefas e envio de convites)
63
Lista de Figuras
21 Arquitectura de um sistema thin-client em duas camadas (a esquerda)e em tres camadas (a direita) Note-se a inclusao do servidor (main-frame) na definicao das camadas desta arquitectura devido a fortedependencia cliente-servidor 9
22 Arquitectura de um fat-client em duas camadas (a esquerda) e emtres camadas (a direita) 10
23 Comparacao do modelo de web aplications sıncrono paginas estaticase interactivas abordados nas seccoes 221 e 222 com o modelo deweb applications Ajax (assıncrono) abordado na seccao 223 Figuraadaptada de http www adaptivepath com 15
31 Esquema UML do processo efectuado pelos recursos do Gears do tipoManagedResourceStore para a actualizacao dos conteudos definidosno ficheiro manifesto 29
41 Exemplo de uma arquitectura de uma web application sem uma ca-mada de abstraccao de dados Figura adaptada de http gears
google com 33
42 Exemplo de uma arquitectura de uma web application com uma ca-mada de abstraccao de dados Figura adaptada de http gears
google com 34
43 Exemplo de uma arquitectura de uma web application com uma ca-mada de abstraccao de dados e um data switch Figura adaptada dehttp gears google com 35
44 Esquema grafico ilustrando uma OWA executando no browser uti-lizando um modo de execucao do tipo ldquoaplicacao deciderdquo com de-teccao automatica do estado da ligacao via pedidos Ajax assıncronosa cada cinco segundos 37
45 Detalhe de um conjunto possıvel de estados e respectivas transicoespara uma dada ordem de trabalho no WOW desde a sua submissaono sistema ate a sua conclusao em fecho ou cancelamento Esta figurarepresenta apenas um exemplo ja que o mapa de estados para umaordem de trabalho e dinamico e pode ser alterado por um admin-istrador Figura retirada de uma brochura promocional do WOWCritical Software SA 41
ix
LISTA DE FIGURAS
46 A pagina inicial do WOW apresenta um resumo das ultimas ordensde trabalho enviadas e recebidas Na imagem pode-se observar atransicao do estado online para offline 44
47 Ilustracao do funcionamento do Gears numa web application que uti-liza um motor Ajax Os pedidos HTTP ou HTTPS podem ser inter-ceptados e tratados localmente ou podem ser feitos a uma maquinaremota consoante se verificarem ou nao as condicoes expressas noponto 311 E representado um acesso a uma base de dados local(fornecida pelo Gears) mas a sua utilizacao e opcional 45
48 Neste exemplo do modo ldquoaplicacao deciderdquo o teste da ligacao e feitoe feito a cada cinco segundos O resultado deste teste nao reflectesempre o estado real da aplicacao podendo levar a aplicacao a tercomportamentos indesejaveis Na figura assinala-se um perıodo detempo no qual a representacao interna do estado da ligacao nao cor-responde a realidade 46
49 Pagina de visualizacao do detalhe de uma ordem de trabalho 47410 Esquema UML que expressa os casos de uso do WOW Offline no
modo ldquoutilizador deciderdquo 48411 Esquema UML que expressa os casos de uso do WOW Offline no
modo ldquoutilizador deciderdquo 49412 Esquema UML que expressa o acto de recolha de dados em modo
online e offline recorrendo ao servidor (modo online) e ao sistemade armazenamento de dados local fornecido pelo Gears (modo offline) 50
A1 Dialogo apresentado ao utilizador na primeira activacao das funcional-idades offline no Google Docs amp Spreadsheets 61
A2 Na activacao das funcionalidades offline e tambem oferecida a possi-bilidade da criacao de alguns atalhos por exemplo no ambiente detrabalho 62
A3 O Google Docs mantem a todo o momento a possibilidade de alteracaodestas definicoes ou da anulacao dos servicos offline para um dadocomputador 62
A4 Apos a instalacao do Gears qualquer visita ao Remember The Milkdespoleta uma sincronizacao que ocorre automaticamente e sem ne-cessidade de intervencao por parte do utilizador 63
A5 Apos completar a sincronizacao de dados mesmo que a ligacao aInternet seja perdida o Remember the Milk continua disponıvel nobrowser (com excepcao das funcionalidades que pela sua naturezaexigem uma ligacao como por exemplo partilha de tarefas e enviode convites) 63
x
Lista de Tabelas
21 Comparacao entre thin-clients e fat-clients 7
31 Comparacao das funcionalidades oferecidas pelo Adobe AIR para asplataformas web e desktop 30
32 Resumo da utilizacao de tecnologias OWA em algumas web applica-tions consideradas na analise do estado da arte 31
xi
LISTA DE TABELAS
xii
Glossario
fat-client Cliente que nao depende totalmente de umservidor central para as suas actividadesde processamento e possui frequentementedispositivos de armazenamento de dados
6ndash8
thin-client Cliente que depende de um servidor centralpara as suas actividades de processamento
5ndash8
web application Sistema web (servidor rede HTTPbrowser) onde accoes do utilizador(navegacao e introducao de informacao)afectam o estado logico da aplicacao
i iii1ndash311ndash1517ndash1921ndash232728 3336ndash3842 5556
API Application Programming Interface 10 1718 2326 28
ASP Linguagem interpretada pelo servidorque permite a criacao de paginas webdinamicas Desenvolvida pela Microsoft
11
BSD Berkeley Software Distribution 28
CSS Cascading Style Sheets 12 2021 2324 46
DHTML Dynamic HyperText Transfer Protocol 24DOM Document Object Model 10 12
20 2324
DTD Document Type Definition 24
xiii
Glossario
ECMAScript Padrao de linguagem de programacaodefinido pela Ecma International que orig-inou o JavaScript e o JScript
24
Flash Conteudo interactivo de um ficheiro emformato SWF E desenvolvido pela Adobee visualizado atraves do Adobe FlashPlayer
21
Flex Framework baseada em XML e Action-Script desenvolvida pela Adobe para a pro-gramacao de Rich Internet Applications(RIA)
21
GPL GNU General Public License 23
HTML HyperText Markup Language 1 10ndash12 2124ndash2649
HTTP HyperText Transfer Protocol 2 26
JMS E uma API em Java que permite a troca demensagens entre componentes de software
42
JSON JavaScript Object Notation permite atroca de dados codificados num formatode texto de simples leitura
12 1828 34
LGPL GNU Lesser General Public License 23
Mozilla Prism Browser simplificado e ldquointerpretadorrdquo deeXtensible User Interface Language (XUL)(tambem designado por XULRunner) queacolhe web applications sem a interfacegrafica habitual de um browser
25
MPL Mozilla Public License 23
OCA Occasionally Connected Application 39OWA Offline Web Application i iii
2ndash515 1725 2628 3133 3651 5255 56
PDF Portable Document Format 21
xiv
Glossario
PHP Linguagem interpretada pelo servidorque permite a criacao de paginas webdinamicas mas que pode tambem ser in-vocada a partir da linha de comandos
11
pagina web estatica Pagina web que devolve sempre a mesmaresposta a todos os pedidos para todos osutilizadores e em qualquer contexto
5 9
RIA Rich Internet Applications web appli-cations que apresentam funcionalidadessemelhantes as desktop applications masque mantem a informacao no lado do servi-dor
5 1520 28
RSS Really Simple Syndication 27
SLA Service Level Agreement 40SQLite Segundo a definicao oficial SQLite is a
software library that implements a self-contained serverless zero-configurationtransactional SQL database engine
17
SSB Site Specific Browser 25SSL Secure Sockets Layer 22SWF ShockWave Flash 21
URL Uniform Resource Locator 18
VPN Virtual Private Network 38
WOW Work Orders Web Plataforma de gestaode ordens de trabalho e do seu fluxo de-senvolvida pela Critical Software SA
i iii28 3340ndash434551ndash5356
WWW World Wide Web 11 1214
XBL eXtensible Binding Language 24XHTML eXtensible HyperText Markup Language 12XML eXtensible Markup Language 11 12
23 2428
XSLT eXtensible Stylesheet Language Transfor-mation
12
XUL eXtensible User Interface Language xiv23ndash25
xv
Glossario
xvi
Capıtulo 1
Introducao
Neste capıtulo enquadra-se o tema do projecto introduzindo alguns dos conceitos
nos quais se baseia Apresentam-se as motivacoes ambito objectivos e a estrutura
deste documento
11 Enquadramento
A Internet foi originalmente concebida para ser um espaco de partilha de in-
formacao onde pessoas (atraves de maquinas) pudessem comunicar Na sua origem
as paginas eram estaticas constituıdas por texto formatado em HyperText Markup
Language (HTML) e ligadas entre si [BL96] Hoje encontramos conteudos cada vez
mais complexos e dinamicos incluindo som vıdeo ou streams multimedia [Loo06] e
em 2005 foi introduzido por [OrsquoR09] o termo Web 20
De acordo com [Greon] um website pode pertencer a uma ou varias das seguintes
categorias
bull Documento ndash um website essencialmente estatico onde alteracoes a uma
parte do conteudo nao tem implicacoes no seu comportamento
bull Base de dados ndash um directorio de informacao organizada em categorias
bull Aplicacao ndash um website dinamico que utiliza uma linguagem executada ou
interpretada do lado do servidor e que processa as accoes ou informacao in-
troduzida pelo utilizador para fornecer um servico ou nova informacao
A ultima destas categorias constitui aquilo que e normalmente designado por
web application O conceito utilizado ao longo deste documento e o mesmo que
o introduzido por Jim Coallen em [Con99] que define web application como um
1
Introducao
sistema web (servidor rede HyperText Transfer Protocol (HTTP) browser) onde
accoes do utilizador (navegacao e introducao de informacao) afectam o estado logico
da aplicacao A sua definicao tenta estabelecer que uma web application e um
sistema de software com estado de negocio1 e que a sua interface de interaccao com
o utilizador e distribuıdo atraves de um sistema web
12 Motivacao
A quantidade de informacao que e produzida e armazenada com recurso a es-
tas web applications disponıveis online tais como e-mail blogues ou mesmo docu-
mentacao tornam por vezes a disponibilidade de ligacao uma condicao necessaria
a produtividade e como consequencia desta barreira muitos potenciais utilizadores
opoem-se a adopcao de produtos web em detrimento das tradicionais desktop appli-
cations
Assegurar o acesso a uma ligacao de Internet e hoje muito mais facil A Internet
movel e ja uma realidade e encontra-se amplamente divulgada mas continuam a
existir diversas situacoes nas quais os utilizadores estao privados de uma ligacao
a Internet tais como uma viagem de metro ou de aviao ou quando se encontram
deslocados do seu paıs de origem e nao possuem nenhum plano de subscricao
Uma OWA consiste numa web application que para alem de manter todas as
caracterısticas anteriores se mantem disponıvel mesmo na ausencia de uma ligacao
a Internet e surge como uma tentativa de estreitar as barreiras existentes entre a
web e o desktop Isto significa que devera existir um mecanismo capaz de assegurar
a manutencao do estado logico da aplicacao quando a ligacao com o servidor e
quebrada permitindo ao utilizador continuar a utilizar a aplicacao e que sera capaz
de informar o servidor do estado em que a aplicacao se encontra quando a ligacao for
reposta A principal vantagem que advem desta possibilidade e evidente eliminar
a necessidade da existencia de uma ligacao a Internet para que a aplicacao possa ser
utilizada
Por outro lado a vontade de integracao de funcionalidades tıpicas das desktop
applications nas web applications foi um dos principais factores que impulsionou o
desenvolvimento deste conceito uma vez que obrigou a uma reflexao ldquopara alem
do browserrdquo e a uma adaptacao das arquitecturas existentes que permitisse ou o
acesso a funcionalidades disponibilizadas pelo sistema operativo ou pelo menos a
funcionalidades semelhantes Pretende-se com esta aproximacao tornar possıveis
interaccoes entre o desktop e o browser tais como arrastar um ficheiro para um
formulario web de upload de conteudos melhor suporte para o historico do clipboard
ou ainda o acesso ao sistema de ficheiros local Atingir estes objectivos reflecte-se
1NT business state
2
Introducao
num novo paradigma que reune as vantagens das web applications tais como os
updates instantaneos ou o facto de nao ser necessaria nenhuma instalacao e das
desktop applications como por exemplo persistencia no armazenamento de dados
acesso a funcionalidades do sistema operativo ou integracao e interaccao com outras
aplicacoes sejam elas web applications ou desktop applications
13 Ambito
Este projecto foi realizado na Critical Software SA no ambito do Mestrado
Integrado em Engenharia Informatica e Computacao (MIEIC) da Faculdade de En-
genharia da Universidade do Porto (FEUP) entre os meses de Fevereiro e Julho de
2008
14 Objectivos
Sao objectivos deste projecto
1 Estudar e documentar o tema das OWAs acompanhando os ultimos desenvolvi-
mentos nesta materia
2 Analisar o estado da arte fazendo uma analise crıtica e objectiva sobre as
diversas metodologias existentes
3 Implementar uma prova de conceito que permita a execucao offline de uma
web application documentando todo o processo
4 Estudar a possibilidade de permitir interaccao com a aplicacao (insercoes e
alteracoes aos dados) em modo offline
Em resumo o objectivo deste projecto foi estudar documentar e implementar
uma prova de conceito relacionada com o tema Offline Web Applications (OWA)
Este tema embora nao seja totalmente novo ganhou destaque ao longo do ano de
2007 com o surgimento de diversas ferramentas que se destinam a aproximar web
applications das desktop applications
15 Estrutura do documento
Este documento esta organizado em diferentes seccoes apresentando o projecto
numa sequencia logica organizada da seguinte forma
No capıtulo 1 faz-se uma breve apresentacao do conceito OWAs e do contexto em
que surge Apresenta-se tambem a estrutura do documento e definem-se os
termos e acronimos utilizados
3
Introducao
No capıtulo 2 faz-se uma descricao da evolucao das tecnologias que antecedem as
OWAs e das vantagens e desvantagens de cada uma como forma de enquadra-
mento
No capıtulo 3 analisa-se o estado da arte nesta materia Introduzem-se diversas
tecnologias directamente relacionadas com o tema deste projecto exemplos de
aplicacoes que as usam e as razoes que fundamentam as escolhas de tecnologias
efectuadas
O capıtulo 4 contem o desenvolvimento do projecto Analisa-se a plataforma
WOW de gestao integrada de ordens de trabalho a tecnologia escolhida e
a forma como foi utilizada para implementar a capacidade de execucao offline
O capıtulo 5 descreve os resultado obtidos comparando-os com as expectativas
iniciais do projecto e apresenta desenvolvimentos futuros e possibilidades de
continuacaoaplicacao do conhecimento adquirido
No capıtulo 6 apresentam-se as conclusoes
4
Capıtulo 2
Enquadramento do Projecto
Neste capıtulo apresenta-se um breve resumo da evolucao das arquitecturas de
software cliente-servidor e a forma como estas se comparam a evolucao da Inter-
net procurando estabelecer uma analogia entre o percurso de ambas as tecnolo-
gias Compara-se o comportamento e arquitectura dos thin-clients as paginas web
estaticas a evolucao dos fat-clients as paginas interactivas Web 20 e Ajax e
defende-se que as OWA constituem um proximo passo logico e evolutivo aproxi-
mando a web do desktop Referem-se ainda os principais factores que justificam a
importancia das OWAs e a estreita relacao que tem com as Rich Internet Application
(RIA)s
21 Evolucao das arquitecturas de software
Os termos thin-client e fat-client sao utilizados quer para descrever arquitecturas
logicas (de software) quer para descrever arquitecturas fısicas (de hardware) Neste
capıtulo excepto quando seja dada indicacao em contrario estes termos referem-se
sempre a uma arquitectura logica
Adicionalmente quando se trata de arquitecturas cliente-servidor pode-se estu-
dar a arquitectura desenvolvida do sistema como um todo da arquitectura do servi-
dor ou da arquitectura do cliente Para evitar equıvocos em especial na seccao 213
especifica-se em cada caso qual o sistema estudado
211 Thin-clients
Um thin-client e um computador cliente ou software cliente que no contexto
de uma arquitectura cliente-servidor depende de um servidor central para as suas
5
Enquadramento do Projecto
actividades de processamento e proporciona um canal de entrada e saıda de in-
formacao entre o utilizador e o servidor remoto Este termo quando aplicado a
hardware refere-se habitualmente a um computador que se destina a ser utilizado
como cliente de rede sem armazenamento local e com capacidade de processamento
reduzida [Gro02b] mas o conceito que aqui se analisa refere-se a uma arquitectura
de software que remonta ao inıcio das aplicacoes cliente-servidor
No inıcio da historia da computacao terminais ligavam-se directamente a main-
frames responsaveis por todo o processamento Nesta arquitectura era necessario
desenvolver duas aplicacoes distintas uma aplicacao central no servidor (main-
frame) responsavel pela gestao de toda a informacao e por todas as operacoes de
comunicacao e uma aplicacao de visualizacao instalada no cliente (terminal) O
papel destes terminais era apenas disponibilizar ao utilizador um meio de comu-
nicacao (entrada e saıda) e apresentacao dos resultados do servidor Nao tinham
um papel activo no calculo nem na logica de negocio e frequentemente nao tinham
tambem nenhum mecanismo de armazenamento de dados
Como vantagens esta arquitectura apresenta uma reduzida necessidade de con-
figuracao e manutencao do lado do cliente Uma vez que o centro do processamento
e manipulacao de dados ocorre no servidor existe tambem uma centralizacao da
informacao [NJN00] que introduz um ponto crıtico de falha1 Actualizacoes e novas
funcionalidades sao faceis de distribuir uma vez que requerem apenas alteracoes no
servidor [Gro02a]
212 Fat-clients
Contrastando com os thin-clients nesta arquitectura os clientes implementam
ja uma parte da logica de negocio e sao responsaveis pelo processamento de dados
Estes fat-clients vieram responder a necessidade crescente de aplicacoes com um
nıvel de interactividade e capacidade de configuracao maior que as oferecidas pela
arquitectura thin-client descrita na seccao 211 Apesar de manterem a sua de-
pendencia do servidor podem tambem ser executados sem uma conexao activa uma
vez que dispoe de armazenamento de dados local o que lhes confere a capacidade
de persistencia de dados e do estado de execucao entre cada sessao
Foi disponibilizando este controlo sobre o estado da aplicacao bem como acesso
a recursos locais (por exemplo sistema de ficheiros e perifericos) que surgiram as
primeiras verdadeiras desktop applications No entanto cada cliente tinha que ser
separadamente instalado no computador pessoal de cada utilizador que pretendesse
utilizar ou interagir com a aplicacao e uma actualizacao ao servidor implicava in-
variavelmente uma actualizacao manual tambem no cliente Uma vez que nem todos
1NT single point of failure
6
Enquadramento do Projecto
Thin-clients Fat-clientsNao toma parte no processamento dedados nem possui acesso ao sistema deficheiros
Participa activamente no processa-mento de dados recorrendo ao sis-tema de armazenamento local para ar-mazenamento de dados
Nao mantem registo do estado logicoda aplicacao entre duas sessoes de uti-lizacao
O acesso ao armazenamento localpermite-lhe manter registo do estadologico da aplicacao entre duas sessoes
O thin-client nao necessita de qualquerinstalacao estando ldquopronto a utilizarrdquo
E geralmente necessario instalar aaplicacao para poder interagir com oservidor
Qualquer update no servidor reflecte-seimediatamente por todos os clientes
Embora a aplicacao cliente possa aler-tar para existencia de novas versoes asactualizacoes tem que ser manualmenteinstalados pelo cliente
O software do cliente destina-se apenasa apresentacao de dados e comunicacaocom o servidor sendo portanto de sim-ples implementacao
Como o software do cliente toma parteactiva no processamento de dadosa sua implementacao requer cuidadosadicionais
Grande mobilidade uma vez que todaa informacao e mantida no servidor
Parte da informacao podera estar ape-nas do lado cliente pelo que existemalgumas restricoes a sua mobilidade
Tabela 21 Comparacao entre thin-clients e fat-clients
os utilizadores actualizam regularmente as suas aplicacoes o servidor tem que estar
preparado para lidar com versoes antigas2 ou descontinuar os seus servicos a uma
parte da sua comunidade de utilizadores ate que estes actualizem os seus sistemas
Como os utilizadores passam a utilizar os seus recursos locais para armazenamento
de dados as alteracoes que nao sejam sincronizadas com o servidor estao apenas
disponıveis nos seus computadores pessoais o que introduz uma restricao a mobili-
dade
Pode-se afirmar que as vantagens dos thin-clients sao as desvantagens dos fat-
clients e que as vantagens dos fat-clients sao as vantagens dos thin-clients tal como
se ilustra na Tabela 21
213 Arquitecturas cliente-servidor
Introduzidos os termos thin-client e fat-client interessa reafirmar que ambos
podem ser vistos como arquitecturas cliente-servidor Um cliente define-se como
um solicitador de servicos e um servidor como um prestador de servicos tal como
definido por [Sch96] e [Sad97]
2NT backward compatibility
7
Enquadramento do Projecto
As arquitecturas cliente-servidor sao categorizadas pela modularizacao com que
sao desenhadas sendo consideradas as seguintes camadas
1 Interface grafica (front-end) atraves da qual os utilizadores interagem com
a aplicacao Quando este modulo e implementado separadamente dos outros
dois constitui uma aplicacao thin-client por si so uma vez que nao implementa
regras de negocio (embora possa definir validacoes de formularios de insercao de
dados por exemplo) A informacao introduzida pelo utilizador e enviada para
o servidor que processa o seu pedido e retorna uma resposta Este processo
repete-se ate que o utilizador atinja o seu objectivo ou se desligue do sistema
2 A logica de negocio tambem designada por camada intermedia que imple-
menta as regras de aceitacao e validacao de todos os dados introduzidos pelo
utilizador E tambem a plataforma de comunicacao que une a camada superior
de visualizacao com a camada de acesso a dados
3 A camada de dados inclui quer o sistema de persistencia de dados onde sao
armazenados os dados relevantes como tambem os mecanismos necessarios
para a sua pesquisa seleccao e alteracao
Os thin-clients quando observados no seu conjunto de cliente e servidor podem
ser vistos quer como sistemas de duas camadas quer como sistemas de tres camadas
dependendo apenas da forma como o servidor for implementado No caso de na
implementacao do servidor nao se distinguir a camada de acesso a dados da camada
da logica de negocio sao designados por sistemas de duas camadas Caso seja feita
esta distincao sao designados por sistemas de tres camadas Ambos os casos sao
ilustrados na Figura 21
Historicamente os fat-clients eram implementados numa arquitectura em duas
camadas Possuıam apenas um modulo de visualizacao de dados designado por
camada de interface e um modulo que implementava toda a logica de negocio e
regras de acesso a base de dados No entanto com a introducao de ligacoes mais
rapidas e de computadores pessoais com maior capacidade de processamento e so-
bretudo devido a complexidade crescente das aplicacoes a logica de negocio e a
camada de acesso a dados tornaram-se independentes Este modelo e designado por
arquitectura em tres camadas e e ilustrado na Figura 22
22 Evolucao na Internet
Ao analisar a evolucao das arquitecturas das aplicacoes desenvolvidas para a
Internet podemos encontrar um paralelismo com a historia da arquitectura de soft-
ware
8
Enquadramento do Projecto
Figura 21 Arquitectura de um sistema thin-client em duas camadas (a esquerda) e emtres camadas (a direita) Note-se a inclusao do servidor (mainframe) na definicao dascamadas desta arquitectura devido a forte dependencia cliente-servidor
221 Paginas web estaticas
Uma pagina web estatica devolve sempre a mesma resposta a todos os pedidos
para todos os utilizadores e em qualquer contexto utilizando o hipertexto como
forma de ligacao entre diversas paginas estaticas
A informacao e armazenada num servidor e o papel do cliente e apenas a apre-
sentacao da informacao Esta forma de disponibilizacao de informacao pode assim
ser comparada com os thin-clients descritos na seccao 211 o utilizador acede a
um website estatico para visualizar informacao sem que o cliente tome parte no
processamento A unica diferenca e que no caso da web estatica a informacao ap-
resentada e sempre a mesma enquanto que nos thin-clients era frequente existir a
possibilidade de insercao de dados no cliente e apos o seu processamento servidor
nova informacao poderia ser apresentada O hipertexto e utilizado para ligar as
paginas entre si numa rede de conteudos relacionados e a navegacao sıncrona era
feita atraves de cliques do rato a cada clique uma nova pagina era apresentada
Este modelo sıncrono e ilustrado na Figura 23
222 Paginas web interactivas e paginas web dinamicas
O JavaScript e uma linguagem interpretada de scripting que tem os browsers
como principal ambiente de acolhimento Os browsers utilizam uma Application
9
Enquadramento do Projecto
Figura 22 Arquitectura de um fat-client em duas camadas (a esquerda) e em tres camadas(a direita)
Programming Interface (API) publica para criar ldquoobjectosrdquo responsaveis por reflectir
e disponibilizar o Document Object Model (DOM) para o motor de JavaScript
A utilizacao mais frequente desta linguagem e a escrita de funcoes que sao em-
bebidas ou incluıdas em paginas web e que interagem com o DOM Uma vez que o
JavaScript e executado localmente (na maquina do cliente e nao no servidor) e capaz
de responder rapidamente a accoes do utilizador tornando a execucao de aplicacoes
no browser mais fluıdas o JavaScript pode tambem detectar accoes do utilizador
que o HTML nao pode tal como o pressionar de uma tecla
Em Dezembro de 1995 a Netscape Communications adicionou suporte para o
JavaScript no browser Netscape Navigator3 e em Agosto de 1996 o browser Internet
Explorer4 da Microsoft passou a tambem a suportar uma versao semelhante desta
linguagem (hoje todos os principais browsers suportam esta tecnologia)
Esta inovacao permitiu tornar os websites mais interactivos mas a sua utilizacao
esteve confinada apenas a este proposito durante um longo perıodo As paginas
passaram a responder activamente a accoes do utilizador (sendo uma das utilizacoes
3Netscape Communications ndash httpbrowsernetscapecom4Microsoft Internet Explorer ndash httpwwwmicrosoftcomwindowsproductswinfamilyie
10
Enquadramento do Projecto
mais vulgares a validacao de formularios) mas continuaram essencialmente estaticas
O JavaScript ainda nao era nesta altura utilizado para processar dados
Tambem nesta altura (1995ndash96) surgiram linguagens server-side como o PHP
Hypertext Preprocessor (PHP) e Active Server Pages (ASP) e o servidor passou a ter
um processamento de dados introduzidos pelo utilizador mais activo Generalizaram-
se as paginas dinamicas capazes de responder a insercao de dados ou outros pedidos
determinados por accoes do utilizador As paginas tornaram-se aplicacoes web ap-
plications
Uma definicao tradicional de web application e um conjunto de paginas web
logicamente agrupadas e geridas por uma unica entidade que tem como pontos de
entrada formularios de insercao de dados (web forms) Uma web application nao e
mais do que uma aplicacao que e acedida atraves de um browser Tem geralmente
uma arquitectura logica em tres (interface logica de negocio e camada de dados)
camadas e estao armazenadas num servidor
Ha dois tipos de web applications
bull Orientadas a apresentacao Sao web applications que geram paginas web in-
teractivas constituıdas por varios tipos de linguagens de anotacao (por exem-
plo HTML eXtensible Markup Language (XML)) e que apresentam conteudo
dinamico como resposta a pedidos efectuados pelo utilizador
bull Orientadas aos servicos Uma web application orientada aos servicos imple-
menta o ponto de acesso para um ou mais de um web service Sao geralmente
clientes de service oriented web applications
Uma vantagem significativa de implementar uma web application de forma a
suportar as funcionalidades padrao dos browsers e que estas terao o mesmo com-
portamento independentemente da plataforma e do browser a partir do qual serao
acedidas No entanto diferentes implementacoes de browsers devido a diferentes
interpretacoes dos padroes definidos tornam por vezes esta tarefa um pouco mais
complicada existindo inclusivamente na web guioes de compatibilidade para os difer-
entes browsers como [Smi07]
223 Web 20 e Ajax
O termo web 20 descreve uma tendencia de utilizacao e de design observada
na World Wide Web (WWW) com o objectivo de melhorar a criatividade partilha
de informacao e principalmente a colaboracao entre utilizadores Estes conceitos
levaram ao desenvolvimento e evolucao de comunidades online tais como redes so-
ciais wikis e blogues
11
Enquadramento do Projecto
O termo tornou-se mais conhecido apos a primeira conferencia OrsquoReilly Media
Web 20 em 2004 e apesar de sugerir uma nova versao da WWW nao se refere a
qualquer evolucao tecnologica mas apenas a alteracoes a forma como os utilizadores
se servem da web De acordo com Tim OrsquoReilly [OrsquoR06] ldquoWeb 20 e uma revolucao
na industria do software causada pela adopcao da web como uma plataforma e pela
tentativa de entendimento das regras para o sucesso nesta nova plataformardquo
O desenvolvimento da Web 20 serve-se muitas vezes de um outro conceito Ajax
O conceito que hoje conhecemos como Ajax muitas vezes incorrectamente de-
scrito como uma tecnologia foi originalmente criado para permitir o desenvolvimento
de web applications que se assemelhassem ainda mais a aplicacoes de desktop Este
conceito foi melhor descrito por [Gar05] como um conjunto de varias tecnologias
que podem ser utilizadas para melhorar a experiencia do utilizador de uma dada
web application introduzindo a capacidade assıncrona de envio de pedidos ou da
recepcao assıncrona de respostas As tecnologias mais frequentemente envolvidas
sao
bull eXtensible HyperText Markup Language (XHTML) e Cascading Style Sheets
(CSS) padrao para a apresentacao
bull interaccao dinamica atraves do DOM
bull troca e manipulacao de dados utilizando XML e eXtensible Stylesheet Lan-
guage Transformation (XSLT) ou JavaScript Object Notation (JSON)
bull pedidos assıncronos utilizando XMLHttpRequest [vK08]
bull JavaScript utilizado para integrar todas estas tecnologias
E importante frisar que o Ajax nao e um produto nem uma tecnologia E um
termo que descreve a utilizacao de um conjunto de tecnologias para o desenvolvi-
mento de web applications com um elevado grau de interactividade Comparativa-
mente as web applications tradicionais o Ajax introduz uma camada de visualizacao
diferente em tres importantes pontos
1 Do lado do cliente existe um motor que serve de intermediario entre a interface
da aplicacao e o servidor
2 A actividade do utilizador despoleta chamadas JavaScript em vez de um pedido
de pagina directamente ao servidor
3 Informacao codificada em XML em vez de paginas HTML e trocada entre o
servidor e o cliente
12
Enquadramento do Projecto
Isto significa que as paginas que utilizam Ajax contem um motor do lado do
cliente composto por um conjunto de funcoes JavaScript responsavel pela comu-
nicacao com o servidor e por actualizar a interface com o resultado dessa mesma
comunicacao
Na Figura 23 ilustra-se a natureza assıncrona do Ajax quando comparada com
as web applications tradicionais Como se pode observar adicionando um mecan-
ismo Ajax a uma web application eliminam-se diversos tempos de espera associados
a comunicacoes com o servidor uma vez que a interface nao fica ldquobloqueadardquo a es-
pera da resposta Obtem-se assim aplicacoes com um comportamento mais fluido
eliminando tempos de espera entre cada ldquocliquerdquo e melhorando a experiencia do
utilizador
23 Offline Web Applications
A informacao grafica (bem como folhas de estilo e scripts) tais como as ima-
gens que constituem o visual de uma web application e ja tratada de forma especial
pelos cada vez mais avancados sistemas de cache (armazenamento temporario) dos
browsers Mas estes nao sao ainda capazes de guardar conteudo criado pelo uti-
lizador nem de apresentar informacao independentemente do estado da ligacao
Numa altura onde se fala de servicos de Internet wireless municipalizados [Kha]
comunicacoes 3G e ligacoes de banda larga a alta velocidade a ligacao a rede global
continua a nao estar permanentemente disponıvel para os utilizadores Na WWW
encontra-se uma importante parte da informacao e das aplicacoes utilizadas para
criar e editar conteudos Por vezes informacao vital para a produtividade pode
desaparecer subitamente do mapa de acesso de um utilizador quando este entra no
metro num aviao ou mesmo quando se desloca para uma cidade ou paıs diferente
do habitual onde nao subscreve um plano de acesso que lhe garanta a ligacao
Permitir o acesso offline a estes recursos assume assim a sua importancia porque
permitira estender o alcance da informacao a locais onde nunca esteve antes e per-
mitira tambem melhorar o desempenho das web applications colocando informacao
mais perto dos utilizadores reduzindo a transferencia de dados apenas ao essencial
24 Comparacao
Nas evolucoes descritas neste capıtulo 2 pode-se observar que existe um par-
alelismo entre a evolucao das arquitecturas tradicionais cliente-servidor e a evolucao
a que se assiste na web O comportamento e arquitectura dos thin-clients assemelha-
se ao das paginas estaticas no sentido em que o browser nao toma parte em qualquer
13
Enquadramento do Projecto
processamento e serve apenas como uma plataforma de interaccao com o servidor
tal como os clientes descritos na seccao 211
A sua proxima evolucao os fat-clients trouxeram parte da capacidade de pro-
cessamento para o lado do cliente Na web foi tambem esta a inovacao tecnologica
a que se assistiu com a evolucao das tecnologias que permitiram a criacao de ver-
dadeiras aplicacoes e com a introducao do Javascript no browser dando ao cliente
a capacidade de processamento de dados A necessidade da separacao do codigo
em camadas logicas advem da crescente complexidade das web applications Esta
pratica permite entre outras coisas melhorar o processo de desenvolvimento e a
capacidade de manutencao de uma aplicacao
Os fat-clients tem tambem a capacidade de armazenamento de dados o que
permite a persistencia de informacoes entre duas sessoes e que algumas operacoes
sejam executadas sem a necessidade de comunicacao com o servidor Este facto pode
tambem ser uma realidade nas web applications com a adopcao das tecnologias OWA
Neste momento assiste-se a uma utilizacao cada vez maior da web como uma
plataforma de desenvolvimento A capacidade de cooperacao na edicao de conteudos
e a mobilidade proporcionada por esta plataforma sao os principais factores que
alimentam esta mudanca e pela primeira vez as aplicacoes tradicionais tem com-
peticao vinda de web applications A prova do reconhecimento da web como plataforma
de desenvolvimento pode ser retirada da aposta de empresas como a Adobe e Mi-
crosoft que lancaram publicamente ferramentas web complementares a produtos
seus tradicionalmente associados ao desktop ndash Acrobatcom5 e Microsoft Office
Live6 Dotar estas web applications da capacidade de execucao offline significa
aproximar a web e o desktop reunindo ldquoo melhor de dois mundosrdquo
As vantagens da mobilidade possıvel atraves da web a cooperacao na criacao e
edicao de conteudos e a possibilidade de utilizar aplicacoes sempre actualizadas e
sem necessidade de instalacao sao algumas das principais vantagens que promovem
esta mudanca que devido as preocupacoes associadas a usabilidade e experiencia do
utilizador esta fortemente associada ao desenvolvimento de Rich Internet Applica-
tion (RIA)s
5Adobe Acrobatcom httpwwwacrobatcom6Microsoft ndash httpsmallbusinessofficelivecom
14
Enquadramento do Projecto
Figura 23 Comparacao do modelo de web aplications sıncrono paginas estaticas e in-teractivas abordados nas seccoes 221 e 222 com o modelo de web applications Ajax(assıncrono) abordado na seccao 223 Figura adaptada de http www adaptivepath
com
15
Enquadramento do Projecto
16
Capıtulo 3
Estado da arte
Apesar de o conceito das OWAs nao ser absolutamente novo as tecnologias que
o suportam sao recentes Neste capıtulo descrevem-se quatro tecnologias que foram
tidas como principais candidatas para o desenvolvimento deste projecto Descrevem-
se ainda alguns exemplos de web applications que disponibilizam actualmente fun-
cionalidades offline e o processo da escolha da tecnologia a utilizar neste projecto
31 Gears
O Gears1 e uma extensao as funcionalidades do browser introduzido pelo Google
que tem como principal objectivo tornar possıvel a visualizacao de paginas de Inter-
net mesmo sem uma conexao disponıvel Encontra-se disponıvel para as platafor-
mas Windows Macintosh e Linux e oferece uma API de Javascript que permite
a scripts aceder a um mecanismo de armazenamento local baseado numa base de
dados SQLite
311 Arquitectura
Esta ferramenta e constituıda por tres componentes principais
bull LocalServer mdash Intercepta pedidos de paginas web e serve-as localmente
bull Database mdash Uma base de dados relacional construıda sobre SQLite
bull WorkerPool mdash Permite executar operacoes de computacao de uma forma
assıncrona sem afectar a capacidade de resposta e fluidez de execucao da web
application Assemelham-se a processos
1Google Inc ndash Mais informacao em httpgearsgooglecom
17
Estado da arte
LocalServer
O modulo LocalServer e uma cache de Uniform Resource Locators (URLs)
controlada pela web application Quando nao existe uma ligacao a Internet e e
feito um pedido para um URL presente nesta cache o LocalServer intercepta-o e
responde ao pedido localmente a partir do disco rıgido do utilizador A aplicacao
pode utilizar dois tipos diferentes de armazenamento local de URLs
bull ResourceStore ndash serve para capturar URLs utilizando exclusivamente a API
de Javascript disponibilizada para o efeito Uma aplicacao podera criar e
utilizar diversos ResourceStores simultaneamente para capturar ficheiros de
dados que necessitam de ser enderecados por um URL tal como um ficheiro
PDF ou uma imagem
bull ManagedResourceStore ndash serve para capturar um conjunto de URLs que estao
relacionados e que sao declarado num ficheiro de manifesto (especificado em
JSON) e que sao automaticamente actualizados O ManagedResourceStore
permite que o conjunto de recursos necessarios para correr uma web application
seja capturado e mantido actualizado automaticamente
A principal diferenca entre estes dois tipos de armazenamento de URLs e a forma
como sao actualizados os seus conteudos Os conteudos de um ManagedResourceStore
sao actualizados sempre que a versao contida no ficheiro de manifesto for alterada
enquanto que os conteudos de um ResourceStore nunca sao actualizados automati-
camente mas apenas quando for explicitamente ordenado pela aplicacao
O LocalServer e capaz de interceptar e servir localmente pedidos de HTTP e
HTTPS sempre que se reunam as seguintes condicoes
1 O URL encontra-se armazenado num ResourceStore ou ManagedResourceStore
2 O sistema de armazenamento local encontra-se activo (enabled = true) Se
o sistema de armazenamento local tiver o atributo requiredCookie o pedido
devera conter um cookie que lhe corresponda
O LocalServer nao necessita de monitorizar o estado da ligacao para atender aos
pedidos Na verdade sempre que as condicoes previamente enunciadas se verificarem
o LocalServer interceptara os pedidos e independentemente do estado da ligacao
a Internet servi-los-a a partir do disco rıgido local Cabera a aplicacao definir qual
o modo em que pretende executar um pedido (online ou offline) definindo o valor
de verdade da propriedade enabled
18
Estado da arte
Database
O modulo Database permite guardar dados da web application assegurando a
sua persistencia Os dados sao guardados de forma relacional no disco rıgido do uti-
lizador2 de acordo com o modelo de seguranca estabelecido pelo Gears3 significando
que uma aplicacao nao pode aceder a conteudos fora do seu domınio
WorkerPool
Nos web browsers uma operacao pesada de computacao pode tornar a interface
lenta e tornar menos agradavel a experiencia do utilizador O modulo WorkerPool
permite correr operacoes em background sem bloquear a interface com o utilizador
Os scripts executados numa WorkerPool nao activam os mecanismos de seguranca
do browser que mostram a mensagem ldquoA script on this page may be busy or may
have stopped respondingrdquo
O WorkerPool comporta-se como um conjunto de processos em vez de threads
Os Workers nao partilham qualquer estado de execucao o que significa que uma
alteracao a uma variavel num Worker nao afecta em nada a execucao de outro
Worker Alem disso os Workers nao herdam automaticamente nenhum codigo dos
seus pais Cada Worker e membro de um WorkerPool e os Workers podem in-
teragir entre si enviando mensagens em formato de texto ou JSON No entanto ha
tambem algumas limitacoes os Workers nao tem acesso ao DOM e objectos como
window ou document nao se encontram acessıveis Isto e consequencia de os Workers
nao partilharem o estado de execucao Mas tem acesso a todas as funcoes built-in
do Javascript A maioria das funcionalidades do Gears pode tambem ser acedida
atraves de uma variavel global especial definida como googlegearsfactory Para
outras funcionalidades especıficas os Workers podem ldquopedirrdquo a pagina principal para
continuar a execucao atraves do envio de mensagens
Outras funcionalidades
bull HttpRequest ndash Este modulo implementa a especificacao W3C XmlHttpRe-
quest definida em [vK08] tornando-a disponıvel para os workers e para a
pagina principal
bull Timer ndash Este modulo implementa a especificacao de timers tal como descrito
por [Hic08] e torna-os disponıveis para os workers e para a pagina principal
2Consultar httpcodegooglecomapisgearsapi_databasehtmldirectories3Consultar httpcodegooglecomapisgearssecurityhtml
19
Estado da arte
bull Factory ndash Esta classe e utilizada para instanciar todos os outros objectos da
API do Gears atraves do seu metodo create Este metodo pode ser utilizado
com os seguintes parametros
ndash betadatabase
ndash betahttprequest
ndash betalocalserver
ndash betatimer
ndash betaworkerpool
312 Goggle Gears em dispositivos moveis
O Gears esta tambem disponıvel em dispositivos Windows Mobile 5 e 6
Os dispositivos moveis estao pela sua natureza frequentemente desconectados
da Internet Mesmo quando possuem uma ligacao as latencias na transferencia de
dados em redes moveis tornam as aplicacoes pouco fluıdas mas o Gears permite
ultrapassar este obstaculo
O Gears funciona exactamente da mesma forma em dispositivos moveis equipados
com o Windows Mobile 5 e 6 como num computador comum Se uma aplicacao tiver
sido implementado com suporte para o Gears entao tambem estara preparada para
ser executada num dispositivo movel mas as limitacoes dos browsers disponıveis
para dispositivos moveis tem que ser consideradas Isto significa prever as condicoes
que permitam uma boa usabilidade devido aos pequenos ecras destes dispositivos
bem como o seu suporte limitado dos padroes do DOM CSS e JavaScript
32 Adobe AIR
O Adobe AIR4 e um runtime compatıvel com diversos browsers e sistemas opera-
tivos que pretende dar aos programadores a possibilidade de combinar diversas tec-
nologias de producao de conteudos para a Internet no desenvolvimento de Rich Inter-
net Application (RIA)s O Adobe AIR mantem uma relacao com o browser mas es-
tende as suas capacidades e tecnologias permitindo o desenvolvimento de aplicacoes
tambem para o ambiente de trabalho com janelas em tudo semelhantes as do sis-
tema operativo Segundo a Adobe o objectivo e complementar o browser dando
aos utilizadores (mas essencialmente aos programadores e equipas de desenvolvi-
mento) a escolha sobre como distribuir as suas aplicacoes Para este efeito o Adobe
AIR tem uma aproximacao diferente do Gears Em vez de ldquoestenderrdquo o browser
acrescentando-lhe funcionalidades o AIR permite tambem o desenvolvimento de
4Adobe - httpwwwadobecomproductsair
20
Estado da arte
aplicacoes que se destinam a ser executadas fora do ambiente do browser mas uti-
lizando as tecnologias comuns da Internet (por exemplo HTML CSS JavaScript
Flash Flex)[CDGH08]
A utilizacao desta tecnologia permite utilizar o browser ou o proprio runtime
Adobe AIR como plataforma de execucao da aplicacao
Na Tabela 31 faz-se uma comparacao das funcionalidades disponıveis de acordo
consoante se escolha o browser ou o desktop como plataforma base para a aplicacao
Uma vez que as aplicacoes Adobe AIR na plataforma desktop tem um caracter
persistente (sao instaladas no computador do utilizador) o Adobe AIR tem um
modelo de seguranca que se assemelha com o das tradicionais aplicacoes desktop
[Ada08] Este modelo e analisado nas seccoes 321 e 322 O ambiente em que
e executado o browser e restringido a execucao de web applications que podem
ser de varias origens (incluindo de origens anonimas ou sem confianca) O Adobe
AIR proporciona acesso a capacidades como acesso a ficheiros que necessitam da
confianca do utilizador
bull HTML ndash O desenvolvimento de aplicacoes para o Adobe AIR pode ser feito
com recurso a tecnologias de HTML e Ajax comuns utilizando as linguagens
de markup existentes distribuıdas como texto e interpretadas em execucao
(runtime)
bull Flash ndash Outra alternativa sera a utilizacao da linguagem Flash Permite a
renderizacao de graficos vectoriais e audiovıdeo com suporte nativo Utiliza
ActionScript para adicionar maior interactividade com o utilizador
bull Flex ndash O Flex e uma framework open source para o desenvolvimento de RIAs
usando Flash As aplicacoes Flex sao na realidade Flash sendo a principal
diferenca o ambiente de desenvolvimento
Como resultado uma aplicacao AIR podera ser implementada
bull Baseada em Flash ou Flex (aplicacoes cujo conteudo base e em ShockWave
Flash (SWF))
bull Baseada em Flash ou Flex tambem com HTML ou Portable Document Format
(PDF) Aplicacoes cujo conteudo de base e em FlashFlex (SWF) com HTML
(HTML JavaScript CSS) ou conteudo PDF incluıdo
bull Baseada em HTML Aplicacoes cujo conteudo base e em HTML Javascript
CSS
bull Baseada em HTML utilizando tambem FlashFlex ou PDF
21
Estado da arte
Os utilizadores interagem com uma aplicacao AIR da mesma forma que interagem
com outras aplicacoes com janelas nativas do seu sistema operativo O runtime e
instalado uma vez no computador do utilizador e a partir desse momento todas as
aplicacoes AIR terao o mesmo aspecto que qualquer outra aplicacao para o desktop
321 Seguranca
Permitir que uma web application aceda ao disco de armazenamento do utilizador
pode comprometer seriamente a sua seguranca Neste sentido o Adobe AIR tem
suporte para assinaturas digitais (Secure Sockets Layer (SSL)) que podem ser com-
pradas pelas equipas de desenvolvimento que o desejem e cujos certificados serao
apresentados ao utilizador no momento da instalacao Um outro aspecto ainda
relativo a seguranca e o mecanismo de isolamento de cada ambiente (sandbox )
322 Assinatura do codigo
O runtime AIR exige que todas as aplicacoes estejam digitalmente assinadas As
assinaturas digitais de codigo sao um processo que visa garantir a integridade da
aplicacao e a identidade do seu autor no momento da instalacao As equipas de
desenvolvimento podem ldquoassinarrdquo uma aplicacao utilizando um certificado atribuıdo
por uma Entidade Certificadora (Certification Authority) ou atraves de um certifi-
cado individual (self signed certificate) Neste momento o Adobe AIR suporta como
entidades certificadoras a Verisign e a Thawte [Ado08]
O instalador apresenta o nome de quem publica a aplicacao quando o codigo tiver
sido assinado com um certificado que apresente confianca ou que esteja encadeado
com um certificado que tenha ja sido aceite no computador em que se esta a instalar
a aplicacao
As equipas de desenvolvimento podem tambem assinar as aplicacoes com um
certificado auto-atribuıdo (um certificado criado por elas proprias) mas neste caso
o instalador apresentara estas aplicacoes como sendo de uma origem nao verificada
O AIR utiliza a infraestrutura publica de chaves [Ent07] suportada pelo arquivo
local do sistema operativo Para que a origem da aplicacao seja reconhecida o
computador onde a aplicacao AIR esta a ser instalada tem que confiar directamente
no certificado que foi utilizado para assinar a aplicacao ou confiar num certificado
que esteja num encadeamento logico de certificados confiados e que se ligue desta
forma ao certificado utilizado para assinar a aplicacao
Todas as aplicacoes AIR tem caracterısticas em comum independentemente da
tecnologia utilizada para o seu desenvolvimento (HTMLFlexFlash) No ambito
de uma aplicacao AIR existem um conjunto de APIs que estao disponıveis e que
tornam possıvel o acesso ao sistema local (leitura e escrita) e a recursos de rede que
22
Estado da arte
de outra forma nunca estariam acessıveis a partir de uma web application comum
Cada aplicacao AIR possui tambem diferentes nıveis de isolamento chamados secu-
rity sandboxes dependendo do tipo de conteudo que esta a ser carregado e do seu
objectivo
bull Isolamento ao nıvel da aplicacao5 ndash E a raiz de cada aplicacao AIR Este
nıvel de isolamento permite o acesso a APIs privilegiadas e especıficas do
AIR Em contrapartida e negado o acesso a algumas APIs que poderiam ser
facilmente utilizadas de forma maliciosa contra o utilizador final Importacao
dinamica de conteudos remotos e geralmente proibido e as tecnicas e mecan-
ismos de geracao dinamica de codigo sao fortemente restringidas Apenas
conteudo carregado directamente da directoria base da aplicacao podera ser
colocado neste nıvel de isolamento
bull Isolamento nao especıfico da aplicacao6 ndash contem todo o outro conteudo
que nao tenha sido carregado directamente para o isolamento da aplicacao
Isto inclui conteudo local e remoto Este tipo de conteudo nao tem acesso
directo as APIs do AIR e rege-se pelas mesmas regras tal como se tivesse sido
carregado por um browser a partir da mesma localizacao (por exemplo HTML
carregado a partir de um domınio remoto comporta-se da mesma forma que se
fosse acedido a partir do browser)
33 Mozilla Prism
331 XML User Interface Language
O eXtensible User Interface Language (XUL) e uma linguagem de anotacao
baseada em XML desenvolvida pela Mozilla Foundation que opera em aplicacoes
Mozilla multi plataforma tal como o Firefox O motor Gecko e a unica imple-
mentacao completa desta linguagem que foi desenhada sobre padroes web comuns
como CSS JavaScript e o DOM e permite o desenvolvimento de interfaces graficas
utilizando elementos pre-definidos tais como window box page textbox radio
button entre outros Infelizmente o XUL nao possui qualquer especificacao formal
ou implementacoes de inter-operabilidade para outros motores que nao o Gecko No
entanto a sua implementacao e licenciada em codigo aberto pelas licencas GNU Gen-
eral Public License (GPL) GNU Lesser General Public License (LGPL) e Mozilla
Public License (MPL)
Enunciam-se algumas caracterısticas desta linguagem
5NT application sandbox6NT non-application sandbox
23
Estado da arte
Liguagem de anotacao poderosa baseada em componentes (widgets) O ob-
jectivo do XUL e permitir a construcao de aplicacoes multi-plataforma em
claro contraste com o Dynamic HyperText Transfer Protocol (DHTML) que se
destina ao desenvolvimento de paginas web Por esta razao o XUL esta orien-
tado a componentes tais como janelas botoes e etiquetas em vez de paginas
cabecalhos de texto e ligacoes de hipertexto Investir tempo e esforco para
atingir este mesmo resultado em aplicacoes baseadas em DHTML compromete
frequentemente a complexidade e desempenho da aplicacao
Baseado em padroes O XUL e um dialecto XML baseado no padrao W3C XML
10 As aplicacoes escritas em XUL sao tambem baseadas em especificacoes
W3C adicionais como HTML 40 CSS DOM nıvel 1 e 2 JavaScript 15
incluindo ECMA-262 Edition 3 (ECMAscript)
Portabilidade entre plataformas Tal como HTML o XUL foi desenhado para
ser independente da plataforma em que e utilizado tornando as aplicacoes
facilmente portaveis entre sistemas operativos nos quais o Mozilla e suportado
Uma vez que o XUL oferece um nıvel de abstraccao dos componentes graficos
de interface que disponibiliza implementa a premissa ldquoum codigo para todas
as plataformasrdquo A interface grafica de todos os produtos centrais Mozilla
(browser instant messenger livro de enderecos) e escrita em XUL com um
unico codigo base que suporta todas as plataformas Mozilla
Separacao entre o nıvel de apresentacao e a logica de negocio Uma das
maiores preocupacoes no desenvolvimento para a Internet e a forte ligacao
entre estas duas camadas (interface e logica) Isto constitui um problema sig-
nificativo no desenvolvimento de grandes aplicacoes especialmente quando o
desenvolvimento e feito em ambientes de equipa porque as capacidades de de-
senvolvimento destas duas partes da aplicacao estao muitas vezes espalhadas
por diferentes elementos O XUL permite uma clara distincao entre a definicao
da aplicacao cliente e da logica de implementacao (XUL eXtensible Binding
Language (XBL) e JavaScript) apresentacao (CSS e imagens) internacional-
izacao (Document Type Definitions (DTDs) e etiquetas de texto em lınguas
especıficas guardados em ficheiros properties) O esquema grafico e apre-
sentacao de uma aplicacao XUL pode ser alterado de forma independente da
sua logica ou implementacao e a aplicacao pode ainda ser traduzida (interna-
tionalization) de forma independente da sua logica implementacao ou apre-
sentacao Este grau de separacao resulta em aplicacoes que sao mais faceis de
manter pelos programadores e facilmente adaptadas por designers e tradutores
24
Estado da arte
Facil adaptacao Outro benefıcio que advem do nıvel de separacao entre logica
de negocio e apresentacao oferecido pelo XUL e a facilidade com que se pode
adaptar uma aplicacao para diferentes clientes ou grupos de utilizadores Um
programador pode utilizar a mesma aplicacao base e adapta-la consoante as
necessidades atraves de diferentes temas (skins) e ficheiros de lınguas Desta
forma uma aplicacao escrita e desenvolvida em Ingles pode ser rapidamente
traduzida para Portugues e distribuıda com outra aparencia mais apropriada
ao cliente alvo
332 Prism
O Mozilla Prism e um browser simplificado e ldquointerpretadorrdquo de XUL (tambem
designado por XULRunner) que acolhe web applications sem a interface grafica ha-
bitual de um browser Baseia-se num conceito designado por Site Specific Browser
(SSB) Um SSB e uma aplicacao com um browser embebido desenhado para exe-
cutar apenas uma web application Nao possui os menus e barras de ferramentas
habituais Um SSB tem uma integracao com o sistema operativo e com o desktop
muito mais estreita do que uma web application acedida atraves de um browser uma
vez que e executado em janela propria
O Prism resulta de uma experiencia da Mozilla e visa reduzir as diferencas entre
as desktop applications tradicionais e as web applications Um dos aspectos focados e
a experiencia do utilizador Numa apresentacao oficial e dito que ldquo[o Prism] pretende
ser uma ponte entre as diferencas que existem entre as aplicacoes tradicionais de
desktop e as web applications explorando novos modelos de usabilidade enquanto
que a linha que as separa se continua a definirrdquo [Lab07]
34 HTML 5
A especificacao HTML 5 [Hic08] que se encontra em fase de desenvolvimento
pelo grupo WHATWG pretende ser uma norma de substituicao dos padroes HTML
4 XHTML 1x e do DOM2 HTML Uma das propriedades que o distingue das tec-
nologias que pretende substituir e precisamente o suporte para OWA e armazena-
mento de dados no cliente de uma forma relacional Nao sendo propriamente uma
tecnologia ndashmas antes uma especificacao ndashe aqui mencionada por ter servido como
referencia a diversas implementacoes de funcionalidades offline e por se considerar
que venha a ter um impacto significativo nas implementacoes de diversos browsers
Dion Almaer defendeu no seu blogue que o Gears era uma implementacao do
HTML 5 No seu artigo ldquoGears as a bleeding-edge HTML 5 implementationrdquo [Alm08]
o autor diz que ambos ndasho Gears e o HTML 5 ndashpretendem dar a web caracterısticas
25
Estado da arte
semelhantes e nao encontrar motivo de ldquocompeticaordquo entre as duas mas que en-
quanto o HTML 5 e uma especificacao o Gears e uma implementacao
No entanto tambem e verdade que o HTML 5 cobre muitos outros pontos para
alem das OWA que saem completamente fora do ambito do Gears Se esta es-
pecificacao atingir um estado de maturidade que possibilite a sua adopcao pelos
principais browsers tornando nativo do browser o suporte OWA entao deixara de
fazer sentido a existencia de uma extensao como o Gears
A especificacao HTML 5 disponibiliza duas APIs relevantes para o tema das
OWA
1 Uma base de dados baseada em SQL que permite o armazenamento de dados
do lado do cliente
2 Uma ldquocacherdquo HTTP que garante a disponibilidade das aplicacoes mesmo quando
o utilizador nao possui uma ligacao a Internet
Estas caracterısticas sao as bases da tecnologia das OWA e tem correspondencia
com os pontos analisados nas seccoes 311 e 311
35 Web applications que usam funcionalidades offline
Nesta seccao apresentam-se algumas web applications que actualmente disponi-
bilizam funcionalidades offline Estas aplicacoes foram escolhidas para uma analise
mais pormenorizada por utilizarem o Gears que tal como descrito na seccao 4 foi
a tecnologia escolhida para o projecto
351 Google Reader e Google Docs
O Google Reader7 e um leitor de feeds RSS Permite gerir a subscricao de varios
sites simultaneamente que disponibilizem conteudos neste formato e foi a primeira
web application da Google com uma versao offline publicamente acessıvel (desde
Junho de 2007)
O Google Reader implementa o modo ldquoutilizador deciderdquo oferecendo na sua
interface um botao que permite alternar entre os modos online e offline
O Google Docs8 e uma web application que permite a criacao e edicao de doc-
umentos de texto folhas de calculo e apresentacoes Era ja publico desde Janeiro
de 2008 que o Google estava a desenvolver uma versao OWA desta aplicacao mas o
acesso a uma versao experimental so foi possıvel a partir de 31 de Maio de 2008
7Google Reader - httpreadergooglecom8Google Docs - httpdocsgooglecom
26
Estado da arte
A implementacao das funcionalidades offline nestas duas aplicacoes seguiu difer-
entes aproximacoes principalmente porque o Google Reader apresenta ao utilizador
informacoes que sao fornecidas por fontes externas enquanto que no Google Docs
a informacao e criada e editada pelo utilizador sobre a forma de documentos
A diferente origem da informacao implica que no Google Reader seja necessario
prever casos de excepcao tal como existirem demasiados itens que necessitam de
ser transferidos para o cliente Nao observar este ponto causa um problema grave
de usabilidade e para evitar tempos de espera demasiado longos e uma interface
com pouca capacidade de resposta as accoes do utilizador o Google Reader apenas
transfere para o cliente os dois mil itens mais recentes na transicao para o modo
offline
352 Remember the Milk
O Remember The Milk9 e uma web application desenvolvida por uma equipa
Australiana que proporciona funcionalidades de agenda gestao de tempo e de tare-
fas e foi uma das primeiras aplicacoes independentes do Google a adoptar o Gears
para acessos em modo offline Permite que os seus utilizadores facam uma gestao
de tarefas agrupando-as em listas adicionando-lhes campos de informacao adicional
ou dando-lhes informacao geografica (recorrendo ao servico Google Maps10) Entre
a sua lista de funcionalidades encontra-se ainda a possibilidade de importar e ex-
portar eventos no formato iCalendar (ics) etiquetas (tags) em tarefas publicacao
Really Simple Syndication (RSS) e partilha de categorias de tarefas de acordo com
diferentes nıveis de permissoes de acesso definidos pelo utilizador
353 MySpace e WordPresscom
O MySpace uma das maiores social networks na Internet anunciou recente-
mente que vai disponibilizar uma versao do seu cliente de e-mail que utiliza o Gears
para acelerar o seu desempenho Numa fase inicial estara disponıvel apenas para
utilizadores que tenham cinco mil ou mais mensagens na sua caixa de correio e
permitira efectuar pesquisas muito mais rapido que a sua versao online
O servico de blogs Wordpresscom anunciou tambem o inıcio da utilizacao desta
tecnologia com o fim de melhorar o desempenho A versao que utiliza esta tecnologia
descarrega e armazena no cliente um conjunto de imagens e scripts que passam a
ter preferencia sobre os seus congeneres online e que permitem acelerar o processo
de carregamento da aplicacao e visualizacao de blogs
9Remember The Milk ndash httpwwwrememberthemilkcom10Google Maps ndash httpmapsgooglecom
27
Estado da arte
O MySpace e o Wordpresscom sao dois exemplos da utilizacao da tecnologia
OWA para optimizacao de web application ja existentes Sem pretenderem disponi-
bilizar uma versao que seja totalmente offline fazem uso do Gears para armazenar no
cliente parte dos recursos frequentemente acedidos na visualizacao das suas paginas
36 Escolha da tecnologia
Apos a analise das tecnologias apresentada nas seccoes 31 a 34 foi necessario es-
tudar a adequacao de cada uma delas ao projecto em questao Desde logo e possıvel
observar que nem todas se dedicam apenas a OWA Por exemplo o Adobe AIR
apesar de ter suporte para OWA apenas disponibiliza algumas das funcionalidades
identificadas como mais indicadas para a execucao do projecto quando utilizado
na sua vertente desktop tal como exposto na Tabela 31 mas a utilizacao desta
vertente implicaria o desenvolvimento de novas interfaces e de novas formas de co-
municacao (troca de mensagens XML ou JSON) A vertente web do Adobe AIR
foca-se mais especificamente nas Rich Internet Applications e permite a reutilizacao
do codigo ja existente (exigindo naturalmente a sua adaptacao e a implementacao
das funcionalidades pretendidas)
A tecnologia escolhida para a realizacao deste trabalho foi o Gears sendo que
um dos principais factores a influenciar esta opcao foi a liberdade introduzida pela
sua licenca Berkeley Software Distribution (BSD)11
Considerou-se o funcionamento desta ferramenta extremamente adequando a
aplicacao no WOW uma vez que o seu principal objectivo e precisamente tornar
possıvel a execucao offline de uma pagina web e por virtude deste facto o Gears tem
uma API concisa e de simples aplicacao pratica uma vez que nao possui quaisquer
outros elementos distractores O funcionamento do seu ManagedResourceStore ex-
emplificado na Figura 31 com a capacidade de actualizacao de recursos definidos
num ficheiro manifesto especificado em JSON pesou tambem nesta decisao
11Sobre a licenca BSD consultar httpwwwopensourceorglicensesbsd-licensephp e http
wwwlinfoorgbsdlicensehtml
28
Estado da arte
Figura 31 Esquema UML do processo efectuado pelos recursos do Gears do tipoManagedResourceStore para a actualizacao dos conteudos definidos no ficheiro manifesto
29
Estado da arte
Funcionalidade RIAs no browser RIAs no desktop
Disponibilidadeda aplicacao
As aplicacoes podem ser facil-mente exploradas e utilizadas
As aplicacoes quando instal-adas tem maior grau de fun-cionalidades e persistencia
Instalacao Nao e necessario qualquer tipode instalacao
As aplicacoes sao instaladasatraves do browser ou descar-regadas e instaladas comouma aplicacao tradicional
Actualizacoes Aplicacoes sao actualizadascarregando conteudos paraum website
O AIR disponibiliza uma APIque permite que as aplicacoessejam actualizadas de umaforma
Sistemas opera-tivos suportados
As aplicacoes podem ser exe-cutadas em diversos sistemasoperativos e browsers
As aplicacoes sao multi-plataforma e podem serinstaladas e executadas emdiversos sistemas operativos ebrowsers
Linguagens deprogramacao
Javascript e disponibilizadopelo browser e ActionScripte disponibilizado pelo AdobeFlash Player
Maquinas virtuais deJavascript e ActionScriptcompatıveis com o browser
Capacidade deexecucao embackground
As RIAs podem ser execu-tadas numa janela do browser
As aplicacoes podem ser ex-ecutadas em background edisponibilizar notificacoes talcomo uma aplicacao tradi-cional
Persistencia A actividade esta limitada asessao do browser Quando obrowser e encerrado toda ainformacao e descartada
As aplicacoes sao instaladas eestao disponıveis no desktopPodem armazenar informacaolocalmente e estao disponıveisoffline
Integracao com odesktop
Integracao com o desktop lim-itada devido a restricoes im-postas pelo browser
As aplicacoes podem acederao sistema de ficheiro ao clip-board eventos notificacoesetc
Controlo da inter-face com o uti-lizador
As aplicacoes sao acedidasatraves de uma janela dobrowser que tem os seusproprios controlos e visualgrafico
As aplicacoes tem um vi-sual grafico proprio em janelapropria
Armazenamentode dados
As aplicacoes tem armazena-mento limitado que pode serreescrito pelo browser
As aplicacoes tem acesso a to-talidade do espaco disponıvellocalmente e a uma base dedados com a possibilidade deencriptacao
Tabela 31 Comparacao das funcionalidades oferecidas pelo Adobe AIR para as platafor-mas web e desktop
30
Estado da arte
Aplicacao Modo de execucao utilizadoGoogle Reader Utiliza o modo ldquoutilizador deciderdquo disponibilizando
ao utilizador um botao para alternar entre os modosonline e offline Como lida com informacao recol-hida de fontes externas de natureza frequentementeefemera o processo de sincronizacao apenas transfereos dois mil itens mais recentes quando passa ao es-tado offline Neste modo sao ainda guardadas in-formacoes de itens lidos e etiquetas atribuıdas quesao sincronizadas com o servidor quando o utilizadorvoltar a activar estado online
Google Docs Utiliza o modo ldquoaplicacao deciderdquo permitindo que outilizador edite os conteudos de documentos de textofolhas de calculo e de apresentacoes independente-mente do estado da ligacao desde o momento em queas funcionalidades offline sao activadas A aplicacaofaz pequenas sincronizacoes com o servidor sempre quenecessario
Remember the Milk Utiliza um modo hıbrido entre ldquoaplicacao deciderdquo eldquoutilizador deciderdquo A aplicacao encarrega-se da sin-cronizacao de dados mas disponibiliza um controlona sua interface que permite despoletar manualmenteeste processo para situacoes em que o utilizador fez al-teracoes recentes e pretende usufruir das capacidadesoffline imediatamente
MySpace O MySpace anunciou a utilizacao de mecanismos dearmazenamento de dados no cliente com recurso atecnologias OWA para melhorar o desempenho doseu cliente web de correio electronico nomeadamenteno que diz respeito a operacoes de pesquisa e or-denacao Inicialmente esta funcionalidade estara ape-nas disponıvel para utilizadores com cinco mil ou maismensagens na sua caixa de correio mas nao e aindaclaro se sera disponibilizada uma versao totalmenteoffline
Tabela 32 Resumo da utilizacao de tecnologias OWA em algumas web applications con-sideradas na analise do estado da arte
31
Estado da arte
32
Capıtulo 4
Desenvolvimento
Neste capıtulo introduz-se a aplicacao WOW e apresenta-se o estudo que foi
feito da adequacao de cada tecnologia para a implementacao da funcionalidade of-
fline nesta plataforma Fazem-se diversas consideracoes sobre opcoes a tomar na
concepcao de OWAs e problemas comuns na sua implementacao bem como sug-
estoes para os resolver O WOW e uma aplicacao ja existente de gestao de ordens
de trabalho e do fluxo de tarefas numa empresa ou organizacao
41 Como ficar offline
Na maior parte das web applications de hoje nao existe uma camada de dados
real A aplicacao exemplificada na Figura 41 ao longo da sua execucao acede
directamente a sua unica fonte de dados (o servidor) atraves de chamadas Ajax sem
que exista uma separacao clara destas duas camadas
Para que uma web application seja capaz de ser executada sem uma ligacao
activa a Internet e mantenha o seu caracter dinamico torna-se necessario incluir
Figura 41 Exemplo de uma arquitectura de uma web application sem uma camada deabstraccao de dados Figura adaptada de http gears google com
33
Desenvolvimento
Figura 42 Exemplo de uma arquitectura de uma web application com uma camada deabstraccao de dados Figura adaptada de http gears google com
um mecanismo de armazenamento de dados local seja uma base de dados ou a
capacidade de acesso ao disco No entanto este mecanismo introduz dois problemas
1 Qual das fontes de dados utilizar quando um utilizador faz um pedido de
informacao
2 A necessidade de implementar uma camada de acesso a dados que seja coerente
quer se use o servidor remoto ou local
Por exemplo em vez de a aplicacao Ajax fazer um pedido relativo as contas de
todos os utilizadores em formato JSON directamente ao servidor remoto podera ao
inves fazer o pedido a um objecto intermedio da camada de dados Este objecto
demonstrado na Figura 42 sera responsavel por implementar uma interface de
acesso a base de dados e retornar um objecto JavaScript com uma representacao da
resposta do servidor
Mas a existencia de uma segunda fonte de dados torna recomendavel tambem
a implementacao de uma camada de data switching que em funcao da existencia
de conexao a Internet e da necessidade de actualizacao dos dados decide se faz o
pedido ao servidor remoto ou se fornece os dados presentes localmente Este objecto
apresentado na Figura 43 decidira de forma transparente para o utilizador se le ou
escreve os dados localmente ou se os enviapede ao servidor remoto e pode tambem
iniciar o processo de convergencia de dados e de resolucao de conflitos
411 Funcionalidades disponıveis em modo offline
Por razoes praticas e provavel que nem todas as funcionalidades da aplicacao
possam ser disponibilizadas em modo offline E necessario escolher quais as fun-
cionalidades a disponibilizar no modo offline da aplicacao e implementar a logica
que decide quando utilizar a base de dados local ou o servidor remoto Apesar do
acesso a base de dados local ser muito mais rapido do que aceder ao servidor o
acesso local nem sempre e preferido Ha varias razoes que podem tornar necessario
escolher o acesso ao servidor em vez do acesso local
34
Desenvolvimento
Figura 43 Exemplo de uma arquitectura de uma web application com uma camada deabstraccao de dados e um data switch Figura adaptada de http gears google com
1 A informacao pode ter uma natureza efemera e nao fazer sentido guarda-la
localmente Exemplo dados em tempo real da bolsa de valores de Lisboa
2 Algumas aplicacoes lidam com informacao que so faz sentido na presenca de
uma ligacao Exemplo Instant Messaging
3 A aplicacao podera escolher apenas guardar a informacao acedida mais fre-
quentemente Exemplo para o utilizador poder alterar a lıngua de apre-
sentacao da aplicacao os conteudos terao que ser guardados em todas as
lınguas disponibilizadas pela aplicacao O custo de implementacao de algu-
mas funcionalidades pode nao compensar o benefıcio
4 A capacidade de processamento ou de armazenamento de dados pode inviabi-
lizar algumas funcionalidades offline Exemplo se uma dada funcionalidade
necessita de uma capacidade de armazenamento de dados para alem do razoavel
de um computador pessoal para ser util (visualizador de mapas)
42 Modos de execucao
Um aspecto que e necessario estudar para qualquer web application que se deseje
disponibilizar offline prende-se com tres modos de execucao que devem ser consid-
erados
1 Utilizador decide o modo de execucao A aplicacao tem modos distintos
de execucao para os estados online e offline geralmente indicados na interface
com o utilizador O utilizador e informado do estado da ligacao e participa na
alteracao de estado de execucao da aplicacao interagindo com a sua interface
2 Aplicacao decide o modo de execucao Pode ser implementado na propria
aplicacao um mecanismo de deteccao do estado da ligacao (por exemplo atraves
35
Desenvolvimento
de chamadas Ajax periodicas) transitando de estado e sincronizando automati-
camente Desta forma o utilizador nao precisa de participar na alteracao de
estado a menos que exista um conflito de dados que requeira a sua atencao
3 Aplicacao assume sempre o estado offline Outra hipotese sera imple-
mentar uma web application que assume sempre estar na ausencia de uma
ligacao ao servidor de dados Esta aplicacao responde aos pedidos do uti-
lizador efectuando pedidos de informacao ao servidor mas nao dependendo
de uma resposta valida para mostrar a informacao que ja tinha disponıvel an-
teriormente A sincronizacao de dados com o servidor e tentada sempre que
existam dados para submeter e uma accao do utilizador
421 Modo ldquoutilizador deciderdquo
Neste modo de execucao quando a aplicacao esta online comunica com o servidor
remoto quando esta offline comunica com a base de dados local A informacao tem
que ser sincronizada sempre que se muda de modo A principal vantagem desta opcao
e que e a mais simples de implementar mesmo para uma aplicacao ja existente e
portanto uma forma expedita de disponibilizar uma OWA No entanto tem tambem
algumas desvantagens que devem ser consideradas
1 O utilizador tem que se lembrar de fazer a alteracao de estado de execucao
Caso contrario podera estar a trabalhar inadvertidamente numa versao offline
com dados antigos ou nao ter a informacao necessaria se perder subitamente
a ligacao
2 Se a ligacao for intermitente o utilizador tera ou que escolher um dos modos
de execucao ou estar constantemente a trocar
3 Uma vez que a base de dados nao esta sempre actualizada nao podera ser
utilizada para melhorar a rapidez de execucao da aplicacao quando em modo
online
422 Modo aplicacao decide
A deteccao do estado da ligacao pode ser implementada atraves de um pedido
assıncrono ao servidor tal como ilustrado na Figura 44 O resultado deste pedido
definira o estado online (em caso de sucesso) ou offline (em caso de falha) A
sincronizacao de dados podera ser feita sempre que ocorra uma transicao do es-
tado offline para o estado online No entanto este metodo nao se revela eficiente
36
Desenvolvimento
Figura 44 Esquema grafico ilustrando uma OWA executando no browser utilizando ummodo de execucao do tipo ldquoaplicacao deciderdquo com deteccao automatica do estado daligacao via pedidos Ajax assıncronos a cada cinco segundos
para grandes aplicacoes uma vez que requer a troca de mensagens demasiado fre-
quentes com o servidor que se destinam exclusivamente a monitorizacao do estado
da ligacao
423 Modo ldquoaplicacao assume o estado offlinerdquo
Uma aplicacao transparente funciona assumindo sempre que esta em modo of-
fline ou pelo menos que pode perder a ligacao a qualquer momento Neste modo
tira-se o maximo partido do armazenamento local e fazem-se pequenas mas contınuas
sincronizacoes com o servidor sempre que este esteja disponıvel A sincronizacao de
dados tambem e feita sempre que se volta ao estado online
As vantagens de uma web application transparente sao as seguintes
bull Uma melhor experiencia para o utilizador uma vez que este nao tem que se
preocupar com o estado da ligacao ou com a transicao de estados
bull A aplicacao funciona de forma coerente mesmo que a ligacao seja intermitente
bull Uma vez que o armazenamento local e mantido actualizado pode ser utilizado
para melhorar o desempenho da aplicacao
Foram identificadas as seguintes desvantagens
bull E mais difıcil de implementar e a sincronizacao acarreta cuidados especiais
bull E necessario um cuidado adicional para evitar que as operacoes de sincronizacao
frequentes que ocorrem automaticamente nao afectem os tempos de resposta
da aplicacao
bull Os testes a aplicacao sao mais complexos uma vez que a sincronizacao de dados
nao ocorre em resposta a uma accao do utilizador
37
Desenvolvimento
43 Sincronizacao de dados
A sincronizacao de dados consiste na capacidade de identificar e transferir pe-
riodicamente a versao mais actual dos dados entre o cliente e o(s) servidor(es)
Independentemente do modo de execucao escolhido e mesmo do estado da ligacao
do utilizador a informacao armazenada localmente e a informacao armazenada no
servidor estarao por vezes dessincronizadas Isto podera acontecer sempre que por
exemplo
bull O utilizador faz alteracoes em modo offline
bull A informacao e partilhada e pode ser alterada por uma entidade externa
bull A informacao e fornecida por uma entidade externa
Resolver estas diferencas de forma a que a informacao local e remota encontrem
a igualdade chama-se sincronizacao de dados Ha varias aproximacoes possıveis
para este efeito que dependem da natureza da aplicacao cada uma com vantagens
e desvantagens
A capacidade de suportar a mobilidade dos utilizadores torna-se cada vez um
ponto mais importante de uma web application Para uma organizacao de dimensao
global e vital garantir que os seus colaboradores tem acesso a mesma informacao
que tem disponıvel nos seus postos de trabalho mesmo quando estao fora Na maior
parte dos casos estes colaboradores terao acesso a um computador portatil um
desktop Smartphone ou PDA e atraves destes poderao ter acesso a sua informacao
directamente atraves de ligacoes encriptadas Virtual Private Network (VPN) de um
servidor web ou de outro mecanismo de rede
Esta solucao e simples de implementar mas infelizmente para a maioria dos
colaboradores com grande factor de mobilidade nao e satisfatoria As principais
desvantagens sao as seguintes
bull Requisitos de ligacao Para permitir que os utilizadores acedam a sua in-
formacao e necessario garantir a capacidade constante de comunicacao pelo
menos durante o tempo necessario que assegure a sua transferencia
bull Velocidade de ligacao sem persistencia de dados e em ligacoes de fraca
qualidade a usabilidade por vezes torna-se inaceitavel
bull Ponto crıtico de falha Com este tipo de solucao todos os utilizadores de-
pendem da base de dados que armazena informacao vital para o funcionamento
do cliente
38
Desenvolvimento
bull Scalability do servidor A medida que novos utilizadores sao adicionados ao
sistema o desempenho do servidor e afectado levando a necessidade de maior
capacidade de armazenamento eou processamento
De acordo com a documentacao da Microsoft Sync Framework [Mic08] uma
solucao alternativa consiste em implementar uma Occasionally Connected Appli-
cation (OCA) Uma OCA permite a um utilizador remoto continuar a aceder a
sua informacao mesmo depois de perder a ligacao mas em vez de recorrer a um
servidor recorre a informacao armazenada no seu dispositivo local Para preencher
localmente a informacao que o utilizador necessita uma OCA possui mecanismos
de sincronizacao de dados que sao oferecidos por esta framework
431 Quando sincronizar
Uma das solucoes mais simples de implementar passa por disponibilizar um
mecanismo manual que despoleta a sincronizacao Diz-se manual porque e o uti-
lizador que escolhe quando sincronizar e pode ser implementada simplesmente
fazendo o upload de toda a informacao para o servidor e depois fazendo o download
da copia mais recente da informacao antes de voltar a ficar offline Para que esta
seja uma opcao viavel e necessario que
bull O volume de dados seja suficientemente pequeno para que possa ser transferido
do servidor para o cliente num espaco de tempo aceitavel
bull Que o utilizador indique explicitamente que quer mudar para o estado offline
ou online pressionando um botao da interface
Contudo podem ser identificados alguns problemas relacionados com esta abor-
dagem
bull Os utilizadores nem sempre podem prever o estado das suas ligacoes A ligacao
pode-se perder subitamente ou ter um caracter intermitente
bull O utilizador pode esquecer-se de efectuar a sincronizacao
Outra opcao sera conjugar a sincronizacao de dados com o modo de execucao
transparente A sincronizacao ocorre automaticamente em background de forma
nao intrusiva para o utilizador A aplicacao comunica com o servidor regularmente
efectuando pequenas trocas de dados com o objectivo de manter o sincronismo da
informacao local e remota Esta abordagem pode ser implementada com pedidos
Ajax assıncronos e regulares ao servidor o que permite manter a interaccao com a
interface fluıda evitando bloqueios Estes pedidos sao feitos prevendo as situacoes
39
Desenvolvimento
de disponibilidade ou indisponibilidade (timeout) do servidor Uma outra opcao
sera permitir que o servidor comunique essas alteracoes utilizando Comet1 tal como
descrito em [Wil06] e [Rus06] As vantagens destas aproximacoes sao
bull A informacao esta disponıvel a qualquer altura que o utilizador decida ficar
offline ou que a ligacao seja acidentalmente perdida
bull O desempenho da aplicacao pode ser melhorado quando se estiver a utilizar
uma ligacao a Internet lenta uma vez que o acesso a dados locais e mais
eficiente do que a consulta de dados ao servidor
44 WOW
O WOW e uma plataforma integrada de gestao de ordens de trabalho ja ex-
istente e desenvolvida pela Critical Software SA a qual se pretende adicionar a
capacidade de execucao offline Esta aplicacao e extremamente dinamica e con-
figuravel com um conjunto extremamente rico de funcionalidades das quais se
destacam
bull Gestao de Ordens de Trabalho ndash suportando a gestao dos pedidos desde a
sua criacao ate ao seu fecho tomando em conta os diferentes tipos de pedidos
(ordens de trabalho pedidos de informacao melhorias resolucao de problemas
etc) e diferentes tipos de accoes possıveis para cada um (Figura 45)
bull Monitorizacao de alteracoes ndash Historico de mudancas anexos e estados criando
relatorios de alteracao automaticamente (o que por quem e quando)
bull Uso de Service Level Agreements (SLAs) ndash E possıvel associar a um pedido um
SLA que define qual o perıodo de tempo atribuıdo a resolucao de um pedido
controlando e agilizando a resolucao do mesmo
bull Utilizacao de queries de utilizador configuraveis que permitem acesso rapido
a determinadas ordens de trabalho de acordo com o filtro configurado (por
exemplo ldquoPara mimrdquo ldquoPara o Grupordquo ldquoPelo Grupordquo)
bull Gestao do relacionamento entre pedidos
bull Pesquisa e filtragem de ordens de trabalho
bull Exportacao de dados em formatos padrao (PDF DOC ou XLS)
bull Integravel com solucoes externas
40
Desenvolvimento
Figura 45 Detalhe de um conjunto possıvel de estados e respectivas transicoes para umadada ordem de trabalho no WOW desde a sua submissao no sistema ate a sua conclusaoem fecho ou cancelamento Esta figura representa apenas um exemplo ja que o mapa deestados para uma ordem de trabalho e dinamico e pode ser alterado por um administradorFigura retirada de uma brochura promocional do WOW Critical Software SA
A utilizacao de uma ferramenta deste tipo por parte de uma empresa ou orga-
nizacao oferece vantagens quer a gestao de topo quer aos colaboradores individuais
para os colaboradores individuais o WOW e uma aplicacao onde estao registadas
todas as tarefas contribuindo activamente para o desenvolvimento em ambientes
multi-tarefa e para a organizacao pessoal das tarefas de acordo com prioridades
Para a gestao de topo esta ferramenta permite obter uma visao global do estado da
organizacao em termos de tempo gasto por tarefa executada sendo uma mais valia
para a previsao e gestaoalocacao de recursos
45 Visao geral sobre a arquitectura do WOW
O WOW e interessante nao so do ponto de vista de produto como tambem do
ponto de vista de plataforma Existem diversos plug-ins que estendem as funcional-
idades do WOW e existem ate projectos que pretendem usar a arquitectura do
WOW para criar produtos com fins diferentes do inicial (por exemplo o WOW-
Storm ndash um sistema de registo e classificacao social de ideias)
De modo a conseguir ter essa expansibilidade a plataforma WOW assenta sob
uma arquitectura distribuıda modular e expansıvel com uma componente central
ndash o core ndash estruturado em camadas logicas E no core que se situam todas as
1O Comet e um conceito semelhante ao Ajax introduzido por Alex Russel mas no qual e o servidor quetoma a iniciativa de ldquoenviarrdquo os dados ao browser sem que este tenha que efectuar um pedido Tambem econhecido por Ajax Push Reverse Ajax ou HTTP Streaming
41
Desenvolvimento
funcionalidades base da aplicacao quer a nıvel logico funcional e de apresentacao
quer a nıvel de gestao e configuracao
E possıvel a execucao de varias instancias do core simultaneamente em servidores
distintos o que permite a alta escalabilidade e disponibilidade desta aplicacao A
consistencia dos dados fica sempre garantida atraves da partilha da base de dados
e pelo balanceamento dos pedidos uma vez que cada um e encaminhado para uma
unica instancia
O WOW apresenta tambem a vantagem de ser uma plataforma extensıvel E
possıvel adicionar novas caracterısticas a plataforma atraves de componentes que se
podem ser divididos em duas categorias plugins e connectors
Os plugins sao componentes que se encontram no mesmo no fısico que a aplicacao
partilhando do mesmo contexto de execucao do core Sao assim uma forma mais
directa de obter informacao da plataforma visto que nao possuem restricoes de
acesso aos dados nem dependencias externas A arquitectura deste componente tera
assim que permitir varias execucoes instanciadas cada uma associada a um core
Por outro lado os connectors sao componentes que se encontram distribuıdos
comunicando externamente com o core Quer a sua execucao quer a obtencao
dos dados estao assim dependentes de interfaces de comunicacao externas que a
plataforma disponibiliza Estes componentes ao contrario dos plugins sao instan-
ciados unicamente e recorrem ao protocolo de comunicacao Java Messaging Service
(JMS) para comunicar com o core
46 WOW Offline
Para alem das opcoes tomadas relativamente a tecnologia a utilizar surgiu
tambem a necessidade de optar por um dos modos de execucao apresentados na
seccao 42
Das tres opcoes possıveis foi o modo ldquoaplicacao assume o estado offlinerdquo descrito
na seccao 423 que mereceu a maior atencao uma vez que reune as vantagens de
uma experiencia mais positiva para o utilizador (uma vez que este nao tem que
participar activamente na alteracao do modo execucao como descrito na seccao 421)
e nao constitui uma sobrecarga excessiva para servidor (como o modo abordado na
seccao 422)
No entanto esta opcao comprometia a complexidade da implementacao para alem
dos objectivos propostos para este projecto e para cumprir o prazo dado foi tomada
a decisao de implementar o modo ldquoutilizador deciderdquo especificando apenas de forma
teorica o modo ldquoaplicacao assume o estado offlinerdquo
As caracterısticas do Gears foram ja descritas na seccao 31 Na Figura 47
mostra-se a sua forma de funcionamento quando integrado numa web application
42
Desenvolvimento
Nesta figura representa-se o modulo LocalServer do Gears como um ponto de de-
cisao Aqui sao testadas as condicoes que determinam se o pedido sera interceptado e
servido localmente ou se prossegue para uma maquina remota E tambem represen-
tada uma base de dados que corresponde ao modulo Database mas que podera nao
ser utilizada Este modulo tal como o modulo Workerpool tem caracter opcional
e sao utilizados consoante os requisitos da aplicacao
A plataforma WOW lida com mais dados do que e necessario passar para o
lado do cliente Em conformidade com o ja exposto na seccao 411 volta-se a
frisar que nao se pretende recriar toda a logica de negocio nem os conteudos da
base de dados no cliente pela sua complexidade e volume de dados Pretende-se
pelo contrario permitir que os utilizadores tirem partido da capacidade de poder
consultar as suas ordens de trabalho quando nao dispoe de uma ligacao transferindo
apenas o essencial para isto seja possıvel
A pagina inicial do WOW apresenta um resumo das ordens de trabalho abertas
ndash enviadas e recebidas ndash que se pretende permitir visualizar offline (ver Figura 46)
Como prova de conceito foi efectuada uma abordagem pragmatica das varias possi-
bilidades descritas na seccao 42
461 Modo ldquoaplicacao deciderdquo com deteccao automatica da ligacao
A primeira abordagem estudada para a disponibilizacao das funcionalidades of-
fline foi o modo ldquoaplicacao deciderdquo com deteccao automatica de ligacao apresentado
na seccao 422 Para que isto seja possıvel foi implementado um mecanismo de ver-
ificacao periodica do estado da ligacao atraves de chamadas Ajax assıncronas O
resultado destes pedidos determina o estado da aplicacao executando as tarefas de
sincronizacao de dados sempre que pertinente Este metodo embora imediato e
simples de implementar depressa se revelou inadequado para o projecto devido ao
elevado consumo de recursos do servidor que a utilizacao intensiva faz esperar a
comunidade da plataforma WOW no principal cliente excede os 7000 utilizadores
Foi estimado que para uma utilizacao de fluidez aceitavel o estado da ligacao deveria
ser testado a cada cinco segundos Assumindo uma adesao (previsao pessimista) de
1 aos servicos offline assistir-se-ia a cerca de 840 pedidos adicionais por minuto
Mas o principal problema desta aproximacao prende-se com o facto de a ver-
ificacao ser feita em intervalos de tempo discretos levando a possibilidade de a
aplicacao poder ter em dado momento uma representacao errada do seu estado
real da ligacao Este problema e ilustrado na Figura 48 onde se ve claramente a
discrepancia entre o estado real da ligacao e a representacao interna que esta tem
Note-se que nesta janela de tempo qualquer accao do utilizador que exija uma
resposta sıncrona do utilizador leva-lo-a para um ldquobeco sem saıdardquo onde nao tera
43
Desenvolvimento
Figura 46 A pagina inicial do WOW apresenta um resumo das ultimas ordens de trabalhoenviadas e recebidas Na imagem pode-se observar a transicao do estado online para offline
acesso a versao offline porque a aplicacao nao fez a transicao automatica nem acesso
a versao online porque na verdade nao possui uma ligacao O que acontecera nesta
situacao sera uma tentativa de acesso ao servidor por parte da aplicacao numa
altura em que este se encontra indisponıvel e o resultado sera uma mensagem de
ldquopedido excedeu o tempordquo apresentado pelo browser Este e um estado sem retorno
porque apos o browser apresentar esta mensagem todos os recursos JavaScript ficam
indisponıveis tornando impossıvel o regresso ao estado anterior ou o tratamento do
erro de qualquer outra forma No entanto as chamadas Ajax podem ser tratadas de
forma especial para a eventualidade de falha e portanto nao constituem problema
44
Desenvolvimento
Figura 47 Ilustracao do funcionamento do Gears numa web application que utiliza ummotor Ajax Os pedidos HTTP ou HTTPS podem ser interceptados e tratados localmenteou podem ser feitos a uma maquina remota consoante se verificarem ou nao as condicoesexpressas no ponto 311 E representado um acesso a uma base de dados local (fornecidapelo Gears) mas a sua utilizacao e opcional
462 Implementacao do modo ldquoutilizador deciderdquo
Este modo de execucao foi ja descrito na seccao 421 e a sua principal carac-
terıstica e ser o utilizador a decidir se a aplicacao deve utilizar um servidor remoto
ou a maquina local como fornecedor de dados
Relativamente ao WOW o WOW Offline na vertente ldquoutilizador deciderdquo vem
alterar os seus casos de uso dando ao utilizador a possibilidade de alterar o estado
de execucao da aplicacao (entre online e offline) Resta dizer que no modo online se
mantem todas as funcionalidades anteriores e que no modo offline torna-se possıvel
visualizar os conteudos da pagina principal do WOW (Figura 46) e os detalhes das
ordens de trabalho (Figura 49) tal como expressa a Figura 410
Esta aproximacao foi utilizada na prova de conceito do WOW adicionando um
controlo a interface desta aplicacao que permite ao utilizador alternar entre os esta-
dos online e offline Na transicao de online para offline sao descarregados os recursos
necessarios para a execucao desta aplicacao sem recorrer a Internet Para o fazer
45
Desenvolvimento
Figura 48 Neste exemplo do modo ldquoaplicacao deciderdquo o teste da ligacao e feito e feito acada cinco segundos O resultado deste teste nao reflecte sempre o estado real da aplicacaopodendo levar a aplicacao a ter comportamentos indesejaveis Na figura assinala-se umperıodo de tempo no qual a representacao interna do estado da ligacao nao corresponde arealidade
e utilizado um recurso ResourceStore e um ManagedResourceStore (introduzidos
em 311) O primeiro e utilizado para armazenar a pagina principal do WOW ndash do-
ravante designada por homejsp ndash e o segundo e utilizado para armazenar imagens
folhas de estilo CSS e scripts JavaScript
Para a implementacao deste modo de execucao foram identificadas as seguintes
tarefas
1 Guardar informacao que permita a recriacao das paginas que se pretende
disponibilizar offline (utilizando o Gears)
2 Disponibilizar um controlo que permita alterar o estado de execucao atraves
da interaccao com a pagina principal
3 Durante a sincronizacao de dados apresentar o progresso da transferencia de
dados
O primeiro passo consistiu na identificacao de todos os conteudos que sao necessarios
transferir para a execucao offline Foi utilizado um recurso do Gears do tipo
ManagedResourceStore que recorre a um ficheiro manifesto para identificar to-
dos os ficheiros que deve transferir Este recurso e gerido automaticamente pelo
Gears transferindo para o cliente a versao mais recente sempre que e necessario
isto e sempre que exista um ficheiro manifesto com uma identificacao de versao que
seja diferente da actualmente disponıvel no cliente Uma vez identificados todos
ficheiros necessarios para a execucao offline num (ou mais) ficheiros manifesto o
Gears encarrega-se da sua actualizacao mas o preenchimento destes ficheiros man-
ifesto e manual o que se traduz num cuidado extra na manutencao da aplicacao
A forma como esta informacao e guardada deve tambem ser cuidadosamente
estudada A opcao mais flexıvel passa por utilizar o modulo Database apresentado
na seccao 311 e guardar a informacao de uma forma relacional Para a recriacao
das paginas pode ser disponibilizada uma versao HTML da pagina que funciona
46
Desenvolvimento
Figura 49 Pagina de visualizacao do detalhe de uma ordem de trabalho
como template nao possui quaisquer dados e e utilizada apenas em modo offline E
preenchida para cada pedido retirando os dados relevantes da base de dados
O modelo de dados do WOW torna esta opcao extremamente trabalhosa uma
vez que as entidades envolvidas na geracao de cada pagina de informacao sobre
cada ordem de trabalho tem relacoes de dependencia complexas seguindo padroes
muito variaveis Por exemplo em cada ordem de trabalho existe um formulario que
permite a sua progressao de estado com diversos campos opcionais e obrigatorios
este formulario e definido pelo administrador e esta relacionado nao apenas com o
tipo de ordem de trabalho mas tambem com o estado actual em que esta se encontra
e a accao que se pretende realizar O elevado numero de combinacoes de tipos de
ordem de trabalho estados e accoes que existem num dado momento juntamente
com a sua possibilidade de alteracao obrigariam a implementacao de uma logica de
negocio complexa o que esta fora do ambito deste projecto
47
Desenvolvimento
Figura 410 Esquema UML que expressa os casos de uso do WOW Offline no modoldquoutilizador deciderdquo
463 Especificacao do modo ldquoaplicacao assume o estado offlinerdquo
A aproximacao para o modo ldquoaplicacao assume o estado offlinerdquo foi tambem
dividida em varias tarefas
1 Guardar informacao que permita a recriacao da pagina principal do lado do
cliente no estado offline (utilizando o Gears)
2 Dotar a aplicacao do cliente de um mecanismo de deteccao da ligacao
3 Identificar os ldquomomentos chaverdquo em que devera ocorrer sincronizacao de dados
4 Implementar a sincronizacao de dados
A sincronizacao de dados deve ser feita em ambas as transicoes online-offline e
offline-online quer para transferir novos dados do servidor (os pedidos podem ser
alterados por outros utilizadores) quando se transita do estado quer para comunicar
eventuais alteracoes feitas em modo offline
Relativamente ao WOW o WOW Offline na vertente ldquoaplicacao assume o es-
tado offlinerdquo vem alterar os seus casos de uso dando ao utilizador a possibilidade
de activar esta funcionalidade A partir do momento que a funcionalidade esta ac-
tivada o utilizador deve tambem ter a possibilidade de gerir algumas preferencias
relacionadas com privacidade de dados Devera ter a hipotese de desactivar o ar-
mazenamento local e de remover todos os dados ja armazenados tal como descrito
na Figura 411
48
Desenvolvimento
Figura 411 Esquema UML que expressa os casos de uso do WOW Offline no modoldquoutilizador deciderdquo
A primeira vez que o WOW Offline e acedido por um cliente e caso seja detec-
tada a presenca do Gears todos os recursos necessarios a sua execucao sao trans-
feridos Todos os acessos posteriores serao feitos a estes recursos locais (recorda-se
que o Gears pode ser utilizado para os manter actualizados recorrendo ao Managed-
ResourceStore 311)
Atraves do JavaScript e possıvel interceptar os eventos de load e unload da
pagina que sao despoletados sempre que ocorre um re-acesso da mesma (incluindo
a accao refresh comum dos browsers) sempre que esta e abandonada ou ainda ou
ainda se a janela for encerrada
Tal como sugerido na seccao 462 a camada de interface desta aplicacao (cada
pagina individual em HTML) devera ser implementada como sendo um template
para apresentacao de dados sendo totalmente preenchida atraves de funcoes em
JavaScript O objectivo deste ponto e criar um padrao de dados que permita ao
JavaScript preencher os dados em cada pagina (template) independentemente de
qual seja a fonte ndash o servidor remoto ou a maquina local tal como exemplificado
no diagrama da Figura 412 Na figura a aplicacao recorre ao servidor remoto para
obter os dados pretendidos quando se encontra na presenca de uma ligacao mas
para dados que exijam uma carga de processamento pelo servidor este acto pode ser
49
Desenvolvimento
Figura 412 Esquema UML que expressa o acto de recolha de dados em modo online eoffline recorrendo ao servidor (modo online) e ao sistema de armazenamento de dadoslocal fornecido pelo Gears (modo offline)
substituıdo pelo envio de um campo de controlo que se destina a aferir se os dados
locais se encontram actualizados No caso de estarem actualizados a comunicacao
com o servidor pode ser substituıda por uma query a base de dados local
50
Capıtulo 5
Resultados e Futuros
Desenvolvimentos
Todo o estudo feito sobre o tema OWA foi ja abordado ao longo do documento
Neste capıtulo apresentam-se os resultados obtidos na implementacao da prova de
conceito que visava compreender a melhor forma de disponibilizar uma versao of-
fline no WOW uma plataforma de gestao de ordens de trabalho ja existente de-
senvolvida pela Critical Software SA
51 Resultados Obtidos
Os resultados obtidos neste projecto sao extremamente satisfatorios uma vez
que o estudo do tema OWA e a implementacao de uma prova de conceito que o
ilustrasse foi conseguido com sucesso
A funcionalidade offline foi adicionada ao produto WOW da Critical Software
SA permitindo a visualizacao de ordens de trabalho e dos seus detalhes mesmo na
ausencia de uma conexao activa a Internet Embora para a solucao implementada
tenha sido utilizada uma abordagem do tipo ldquoutilizador deciderdquo pretende-se que esta
seja convertida para ldquoaplicacao deciderdquo ou mesmo para uma aproximacao hıbrida
semelhante a utilizada pelas aplicacoes estudadas nas seccoes 351 e 352
Para a sua implementacao descrita no capıtulo 4 foram tomadas decisoes de or-
dem pratica que permitissem tornar o trabalho exequıvel nos prazos dados Tentou-
se sempre que estas decisoes afectassem o mınimo em termos de desempenho e de
experiencia para o utilizador Considera-se que a implementacao do modo offline
com uma transicao entre modos do tipo ldquoutilizador deciderdquo (ver seccao 42) reflecte
o compromisso entre o desempenho pretendido e os recursos disponıveis e para alem
51
Resultados e Futuros Desenvolvimentos
de ser um exemplo eficaz das possibilidades que as OWA podem trazer a aplicacao
WOW desenvolvida pela Critical Software e tambem um estudo que pode ser uti-
lizado para analisar a implementacao desta tecnologia noutros produtos da mesma
empresa
Note-se que o principal objectivo do trabalho era ganhar familiaridade com este
tema entender as suas vantagens e desvantagens e compreender as suas limitacoes
Tudo indica que existam varias possibilidades de implementacao deste paradigma
noutros produtos da Critical Software que pela sua natureza podem tambem tirar
partido da execucao offline
52 Trabalho Futuro
O desenvolvimento do conceito e formas de implementacao de OWA continua
em forte desenvolvimento no entanto a sua adopcao ainda nao e generalizada A
dificuldade da sua implementacao em web applications ja existentes e o principal
obstaculo a sua maior divulgacao
Ha tambem um factor que deve ser tido em consideracao a manutencao de
codigo A implementacao de uma versao offline de uma web application requer
a implementacao das mesmas regras de negocio (ou de uma versao simplificada)
utilizadas no servidor Para que isto seja possıvel e necessario ter em conta a
capacidade de processamento do cliente e o factor de duplicacao de codigo que
tornara a aplicacao mais difıcil de manter uma vez que uma alteracao a logica de
negocio do servidor implica tambem uma alteracao a sua versao offline
A prova de conceito implementada permite ja a visualizacao offline dos pedidos
abertos (enviados e recebidos) que constam na pagina principal (este numero e
fixo e pode ser alterado pelo administrador) Uma funcionalidade desejavel seria a
possibilidade de interaccao com a aplicacao em modo offline e sincronizacao com o
servidor quando existisse uma ligacao disponıvel
Foi estudada a utilizacao do modo de execucao ldquoaplicacao assume o estado of-
flinerdquo descrito em 423 e esta seria a forma desejavel para o WOW Offline no
entanto para que esta opcao seja viavel sera necessaria a implementacao de uma
forma eficiente de sincronizacao e armazenamento de dados de uma forma relacional
Para atingir este objectivo podera ser seguida uma polıtica de automacao do pro-
cesso no qual a versao online da aplicacao gera scripts de criacao para as tabelas
necessarias na base de dados da versao offline (nao existe nenhuma ferramenta para
o fazer portanto seria necessaria a sua implementacao) e no qual as paginas HTML
disponibilizadas pelo servidor aos clientes web (browser) servem como templates de
apresentacao de informacao e sao preenchidas de forma semelhante pelo servidor ndash
quando a aplicacao estiver online ndash ou pelo cliente atraves de funcoes em JavaScript
52
Resultados e Futuros Desenvolvimentos
ndash quando a aplicacao estiver offline No entanto no WOW devido a quantidade de
informacao tratada e devido as complexas relacoes entre as diferentes entidades e
de esperar que a complexidade da implementacao de um mecanismo deste tipo torne
esta aproximacao demasiado custosa
O HTML 5 embora um forte candidato ainda nao esta suficientemente desen-
volvido A sua especificacao ainda tem o caracter de Draft (rascunho) e esta sujeita
a modificacoes e a aceitacao e implementacao por parte dos browsers e portanto
de momento foi desconsiderado No entanto no futuro se esta especificacao atingir
um estado de maturidade que permita a sua adopcao devera ser considerada como
um possıvel caminho a seguir
53
Resultados e Futuros Desenvolvimentos
54
Capıtulo 6
Conclusoes
Neste capıtulo sao apresentadas as conclusoes do projecto e consideracoes finais
relativamente a tecnologia estudada
61 Conclusoes
O rapido desenvolvimento tecnologico faz prever que a disponibilidade de ligacao
a Internet seja cada vez mais facil e mais rapido mas vao continuar a existir lugares
onde o acesso e limitado e onde as OWA podem desempenhar um papel de relevo
Por outro lado esta tecnologia pode tambem ser utilizada para melhorar o desem-
penho de paginas web com uma necessidade elevada de imagens ou outros recursos
dispendiosos em termos de espaco e foram ate estudados dois exemplos da utilizacao
desta vertente desta tecnologia em 353
Acredita-se que as OWAs vem responder a uma necessidade real por parte das
web applications actuais e que a evolucao que representam se compara a que se
assistiu dos thin-clients para os fat-clients em termos de autonomia do servidor
A capacidade de oferecer conteudos dinamicos no browser independentemente da
existencia de uma ligacao reune as vantagens tıpicas das web applications como
ausencia de instalacao e actualizacoes instantaneas com as vantagens das aplicacoes
de desktop em capacidade de processamento e armazenamento de dados na maquina
local
As tecnologias disponıveis ate a data estudadas no ambito deste projecto que
permitem o desenvolvimento de OWAs e que apresentam maior maturidade sao o
Gears e o Adobe AIR Ambas se apresentam sobre a forma de plugins que necessitam
de uma instalacao extra para poderem ser utilizadas Apesar de esta instalacao ser
55
Conclusoes
apenas necessaria uma vez podera constituir um factor de desencorajamento a sua
adopcao
O HTML 5 uma especificacao abordada neste documento na seccao 34 podera
ser uma alternativa que oferece funcionalidades offline a uma web application sem a
necessidade de qualquer instalacao no entanto esta especificacao ainda nao foi aceite
pelos principais browsers ndash o documento que define o HTML 5 ainda tem o estatuto
de Draft ndash e ainda nao e possıvel antecipar quando e que isto podera acontecer
Um dos problemas que surge frequentemente na implementacao de uma versao
offline para uma web application e a necessidade de sincronizacao de dados Quando
a informacao pode ser alterada por varios utilizadores simultaneamente e necessario
prever os conflitos que daı podem surgir e dotar a aplicacao de uma forma de os
resolver ou alertar o utilizador para a necessidade de alteracao dos dados
Em conclusao todos os objectivos propostos para este projecto foram atingidos
A prova de conceito implementada reflecte de forma clara as possibilidades oferecidas
pela tecnologia OWA e sera utilizado no futuro para compreender a melhor forma
de o implementar de forma definitiva no WOW
56
Referencias
[Ada08] Lucas Adamski Introducing Adobe AIR security model Fevereiro de2008 Disponıvel em httpwwwadobecomdevnetairarticles
introduction_to_air_securityhtml acedido em Marco de 2008
[Ado08] Adobe Adobe AIR 10 Security White Paper 2008 Disponıvel emhttpdownloadmacromediacompubairdocumentation1air_
securitypdf acedido em Marco de 2008
[Alm08] Dion Almaer Gears as a bleeding-edge html 5 implementa-tion March 2008 Disponıvel em httpalmaercomblog
gears-as-a-bleeding-edge-html-5-implementation acedido emMarco de 2008
[BL96] Tim Berners-Lee The world wide web Past present and future Agostode 1996 Disponıvel em httpwwww3orgPeopleBerners-Lee
1996ppfhtml acedido em Abril de 2008
[CDGH08] Mike Chambers Daniel Dura Dragos Georgita and Kevin Hoyt AdobeAIR for JavaScript Developers OrsquoReilly Media 2008 Disponıvel emhttponairadobecomfilesAIRforJSDevPocketGuidepdf ace-dido em Abril de 2008
[Con99] Jim Conallen Modeling Web Application Architectures with UML Junho1999 Disponıvel em httpwwwumlorgcnUMLApplicationpdf
webappspdf acedido em Maio de 2008
[Ent07] Entrust What is a public key information 2007 Disponıvel em http
wwwentrustcompkihtm acedido em Junho de 2008
[Gar05] Jesse James Garret Ajax A new approach to web applicationsFebruary 2005 Disponıvel em httpwwwadaptivepathcomideas
essaysarchives000385php acedido em Marco de 2008
[Greon] Philip Greenspun Philip and Alexrsquos Guide to Web Publishing 2003(last revision) Disponıvel em httpphilipgreenspuncompandaacedido em Junho de 2008
[Gro02a] App Design Group Thick vs thin client comparison 2002 Disponıvelem httpwwwdonjacobsvwcomimagesweekendspecials
Thick-vs-Thinpdf acedido em Junho de 2008
57
REFERENCIAS
[Gro02b] Technical Research Group Thin Client Tecnhology - WhitePaper 2002 Disponıvel em httpwwwpicktrgcompubs
thinclientwhitepaperpdf acedido em Junho de 2008
[Gro08] Miniwatts Marketing Group World internet usage March 2008Disponıvel em httpwwwinternetworldstatscomstatshtm ace-dido em Abril de 2008
[Hic08] Ian Hickson HTML 5 Draft Recommendation 2008 Disponıvelem httpwwwwhatwgorgspecsweb-appscurrent-work ace-dido em Marco de 2008
[Kha] Olga Kharif Top 10 municipal wifi plans Disponıvel em http
imagesbusinessweekcomss0608muni_wifiindex_01htm ace-dido em Marco de 2008
[Lab07] Mozilla Labs Prism Outubro 2007 Disponıvel em httplabs
mozillacom200710prism acedido em Marco de 2008
[Loo06] Chris Loosley Rich Internet ApplicationsDesign MeasurementandManagement Challenges 2006 Disponıvel em httpwwwkeynote
comdocswhitepapersRichInternet_5pdf acedido em Maio de2008
[Mic08] Microsoft Introduction to Occasionally Connected Applications us-ing Sync Services for ADONET 2008 Disponıvel em httpmsdn
microsoftcomen-ussyncbb887608aspx acedido em Junho de2008
[Nao08] Erica Naone Offline web applications Abril 2008 Disponıvelem httpwwwtechnologyreviewcomread_articleaspxch=
specialsectionsampsc=emerging08ampid=20245 acedido emAbril de 2008
[NJN00] Jason Nieh Yang S Jae and Naomi Novik A comparison of thin-clientcomputing architectures 2000 Disponıvel em httpwwwnclcs
columbiaedupublicationscucs-022-00pdf acedido em Maio de2008
[OrsquoR06] Tim OrsquoReilly Web 20 compact definition Trying again Dezembro2006 Disponıvel em httpradaroreillycomarchives200612
web-20-compact-definition-tryihtml acedido em Marco de 2008
[OrsquoR09] Tim OrsquoReilly What is Web 20 Design patterns and business modelsfor the Next Generation of Software 20053009 Disponıvel emhttpwwworeillynetcompubaoreillytimnews200509
30what-is-web-20html acedido em Marco de 2008
[Rus06] Alex Russel Comet Low latency data for the browser March Marco2006 Disponıvel em httpalexdojotoolkitorgp=545 acedidoem Marco de 2008
58
REFERENCIAS
[Sad97] Darleen Sadoski Clientserver software architecturesndashan overviewAgosto 1997 Disponıvel em httpwwwseicmuedustr
descriptionsclientserver_bodyhtml acedido em Junho de2008
[Sch96] George Schussel Clientserver past present and future 1996
[Smi07] Kevin C Smith Css filters - will the browser apply the rule July 2007Disponıvel em httpcentriclecomrefcssfilters acedido emMarco de 2008
[vK08] Anne van Kesteren The XMLHttpRequest Object W3C Work-ing Draft 15 Abril 2008 Disponıvel em httpwwww3orgTR
XMLHttpRequest acedido em Abril de 2008
[Wil06] Greg Wilkins Why ajax comet July Julho 2006 Disponıvel emhttpwwwwebtidecomdownloadswhitePaperWhyAjaxhtml ace-dido em Abril de 2008
59
REFERENCIAS
60
Anexo A
Screenshots
Algumas imagens de aplicacoes que utilizam funcionalidades offline ilustrativasda tecnologia abordada neste documento
Figura A1 Dialogo apresentado ao utilizador na primeira activacao das funcionalidadesoffline no Google Docs amp Spreadsheets
61
Screenshots
Figura A2 Na activacao das funcionalidades offline e tambem oferecida a possibilidadeda criacao de alguns atalhos por exemplo no ambiente de trabalho
Figura A3 O Google Docs mantem a todo o momento a possibilidade de alteracao destasdefinicoes ou da anulacao dos servicos offline para um dado computador
62
Screenshots
Figura A4 Apos a instalacao do Gears qualquer visita ao Remember The Milk despoletauma sincronizacao que ocorre automaticamente e sem necessidade de intervencao por partedo utilizador
Figura A5 Apos completar a sincronizacao de dados mesmo que a ligacao a Internetseja perdida o Remember the Milk continua disponıvel no browser (com excepcao dasfuncionalidades que pela sua natureza exigem uma ligacao como por exemplo partilhade tarefas e envio de convites)
63
LISTA DE FIGURAS
46 A pagina inicial do WOW apresenta um resumo das ultimas ordensde trabalho enviadas e recebidas Na imagem pode-se observar atransicao do estado online para offline 44
47 Ilustracao do funcionamento do Gears numa web application que uti-liza um motor Ajax Os pedidos HTTP ou HTTPS podem ser inter-ceptados e tratados localmente ou podem ser feitos a uma maquinaremota consoante se verificarem ou nao as condicoes expressas noponto 311 E representado um acesso a uma base de dados local(fornecida pelo Gears) mas a sua utilizacao e opcional 45
48 Neste exemplo do modo ldquoaplicacao deciderdquo o teste da ligacao e feitoe feito a cada cinco segundos O resultado deste teste nao reflectesempre o estado real da aplicacao podendo levar a aplicacao a tercomportamentos indesejaveis Na figura assinala-se um perıodo detempo no qual a representacao interna do estado da ligacao nao cor-responde a realidade 46
49 Pagina de visualizacao do detalhe de uma ordem de trabalho 47410 Esquema UML que expressa os casos de uso do WOW Offline no
modo ldquoutilizador deciderdquo 48411 Esquema UML que expressa os casos de uso do WOW Offline no
modo ldquoutilizador deciderdquo 49412 Esquema UML que expressa o acto de recolha de dados em modo
online e offline recorrendo ao servidor (modo online) e ao sistemade armazenamento de dados local fornecido pelo Gears (modo offline) 50
A1 Dialogo apresentado ao utilizador na primeira activacao das funcional-idades offline no Google Docs amp Spreadsheets 61
A2 Na activacao das funcionalidades offline e tambem oferecida a possi-bilidade da criacao de alguns atalhos por exemplo no ambiente detrabalho 62
A3 O Google Docs mantem a todo o momento a possibilidade de alteracaodestas definicoes ou da anulacao dos servicos offline para um dadocomputador 62
A4 Apos a instalacao do Gears qualquer visita ao Remember The Milkdespoleta uma sincronizacao que ocorre automaticamente e sem ne-cessidade de intervencao por parte do utilizador 63
A5 Apos completar a sincronizacao de dados mesmo que a ligacao aInternet seja perdida o Remember the Milk continua disponıvel nobrowser (com excepcao das funcionalidades que pela sua naturezaexigem uma ligacao como por exemplo partilha de tarefas e enviode convites) 63
x
Lista de Tabelas
21 Comparacao entre thin-clients e fat-clients 7
31 Comparacao das funcionalidades oferecidas pelo Adobe AIR para asplataformas web e desktop 30
32 Resumo da utilizacao de tecnologias OWA em algumas web applica-tions consideradas na analise do estado da arte 31
xi
LISTA DE TABELAS
xii
Glossario
fat-client Cliente que nao depende totalmente de umservidor central para as suas actividadesde processamento e possui frequentementedispositivos de armazenamento de dados
6ndash8
thin-client Cliente que depende de um servidor centralpara as suas actividades de processamento
5ndash8
web application Sistema web (servidor rede HTTPbrowser) onde accoes do utilizador(navegacao e introducao de informacao)afectam o estado logico da aplicacao
i iii1ndash311ndash1517ndash1921ndash232728 3336ndash3842 5556
API Application Programming Interface 10 1718 2326 28
ASP Linguagem interpretada pelo servidorque permite a criacao de paginas webdinamicas Desenvolvida pela Microsoft
11
BSD Berkeley Software Distribution 28
CSS Cascading Style Sheets 12 2021 2324 46
DHTML Dynamic HyperText Transfer Protocol 24DOM Document Object Model 10 12
20 2324
DTD Document Type Definition 24
xiii
Glossario
ECMAScript Padrao de linguagem de programacaodefinido pela Ecma International que orig-inou o JavaScript e o JScript
24
Flash Conteudo interactivo de um ficheiro emformato SWF E desenvolvido pela Adobee visualizado atraves do Adobe FlashPlayer
21
Flex Framework baseada em XML e Action-Script desenvolvida pela Adobe para a pro-gramacao de Rich Internet Applications(RIA)
21
GPL GNU General Public License 23
HTML HyperText Markup Language 1 10ndash12 2124ndash2649
HTTP HyperText Transfer Protocol 2 26
JMS E uma API em Java que permite a troca demensagens entre componentes de software
42
JSON JavaScript Object Notation permite atroca de dados codificados num formatode texto de simples leitura
12 1828 34
LGPL GNU Lesser General Public License 23
Mozilla Prism Browser simplificado e ldquointerpretadorrdquo deeXtensible User Interface Language (XUL)(tambem designado por XULRunner) queacolhe web applications sem a interfacegrafica habitual de um browser
25
MPL Mozilla Public License 23
OCA Occasionally Connected Application 39OWA Offline Web Application i iii
2ndash515 1725 2628 3133 3651 5255 56
PDF Portable Document Format 21
xiv
Glossario
PHP Linguagem interpretada pelo servidorque permite a criacao de paginas webdinamicas mas que pode tambem ser in-vocada a partir da linha de comandos
11
pagina web estatica Pagina web que devolve sempre a mesmaresposta a todos os pedidos para todos osutilizadores e em qualquer contexto
5 9
RIA Rich Internet Applications web appli-cations que apresentam funcionalidadessemelhantes as desktop applications masque mantem a informacao no lado do servi-dor
5 1520 28
RSS Really Simple Syndication 27
SLA Service Level Agreement 40SQLite Segundo a definicao oficial SQLite is a
software library that implements a self-contained serverless zero-configurationtransactional SQL database engine
17
SSB Site Specific Browser 25SSL Secure Sockets Layer 22SWF ShockWave Flash 21
URL Uniform Resource Locator 18
VPN Virtual Private Network 38
WOW Work Orders Web Plataforma de gestaode ordens de trabalho e do seu fluxo de-senvolvida pela Critical Software SA
i iii28 3340ndash434551ndash5356
WWW World Wide Web 11 1214
XBL eXtensible Binding Language 24XHTML eXtensible HyperText Markup Language 12XML eXtensible Markup Language 11 12
23 2428
XSLT eXtensible Stylesheet Language Transfor-mation
12
XUL eXtensible User Interface Language xiv23ndash25
xv
Glossario
xvi
Capıtulo 1
Introducao
Neste capıtulo enquadra-se o tema do projecto introduzindo alguns dos conceitos
nos quais se baseia Apresentam-se as motivacoes ambito objectivos e a estrutura
deste documento
11 Enquadramento
A Internet foi originalmente concebida para ser um espaco de partilha de in-
formacao onde pessoas (atraves de maquinas) pudessem comunicar Na sua origem
as paginas eram estaticas constituıdas por texto formatado em HyperText Markup
Language (HTML) e ligadas entre si [BL96] Hoje encontramos conteudos cada vez
mais complexos e dinamicos incluindo som vıdeo ou streams multimedia [Loo06] e
em 2005 foi introduzido por [OrsquoR09] o termo Web 20
De acordo com [Greon] um website pode pertencer a uma ou varias das seguintes
categorias
bull Documento ndash um website essencialmente estatico onde alteracoes a uma
parte do conteudo nao tem implicacoes no seu comportamento
bull Base de dados ndash um directorio de informacao organizada em categorias
bull Aplicacao ndash um website dinamico que utiliza uma linguagem executada ou
interpretada do lado do servidor e que processa as accoes ou informacao in-
troduzida pelo utilizador para fornecer um servico ou nova informacao
A ultima destas categorias constitui aquilo que e normalmente designado por
web application O conceito utilizado ao longo deste documento e o mesmo que
o introduzido por Jim Coallen em [Con99] que define web application como um
1
Introducao
sistema web (servidor rede HyperText Transfer Protocol (HTTP) browser) onde
accoes do utilizador (navegacao e introducao de informacao) afectam o estado logico
da aplicacao A sua definicao tenta estabelecer que uma web application e um
sistema de software com estado de negocio1 e que a sua interface de interaccao com
o utilizador e distribuıdo atraves de um sistema web
12 Motivacao
A quantidade de informacao que e produzida e armazenada com recurso a es-
tas web applications disponıveis online tais como e-mail blogues ou mesmo docu-
mentacao tornam por vezes a disponibilidade de ligacao uma condicao necessaria
a produtividade e como consequencia desta barreira muitos potenciais utilizadores
opoem-se a adopcao de produtos web em detrimento das tradicionais desktop appli-
cations
Assegurar o acesso a uma ligacao de Internet e hoje muito mais facil A Internet
movel e ja uma realidade e encontra-se amplamente divulgada mas continuam a
existir diversas situacoes nas quais os utilizadores estao privados de uma ligacao
a Internet tais como uma viagem de metro ou de aviao ou quando se encontram
deslocados do seu paıs de origem e nao possuem nenhum plano de subscricao
Uma OWA consiste numa web application que para alem de manter todas as
caracterısticas anteriores se mantem disponıvel mesmo na ausencia de uma ligacao
a Internet e surge como uma tentativa de estreitar as barreiras existentes entre a
web e o desktop Isto significa que devera existir um mecanismo capaz de assegurar
a manutencao do estado logico da aplicacao quando a ligacao com o servidor e
quebrada permitindo ao utilizador continuar a utilizar a aplicacao e que sera capaz
de informar o servidor do estado em que a aplicacao se encontra quando a ligacao for
reposta A principal vantagem que advem desta possibilidade e evidente eliminar
a necessidade da existencia de uma ligacao a Internet para que a aplicacao possa ser
utilizada
Por outro lado a vontade de integracao de funcionalidades tıpicas das desktop
applications nas web applications foi um dos principais factores que impulsionou o
desenvolvimento deste conceito uma vez que obrigou a uma reflexao ldquopara alem
do browserrdquo e a uma adaptacao das arquitecturas existentes que permitisse ou o
acesso a funcionalidades disponibilizadas pelo sistema operativo ou pelo menos a
funcionalidades semelhantes Pretende-se com esta aproximacao tornar possıveis
interaccoes entre o desktop e o browser tais como arrastar um ficheiro para um
formulario web de upload de conteudos melhor suporte para o historico do clipboard
ou ainda o acesso ao sistema de ficheiros local Atingir estes objectivos reflecte-se
1NT business state
2
Introducao
num novo paradigma que reune as vantagens das web applications tais como os
updates instantaneos ou o facto de nao ser necessaria nenhuma instalacao e das
desktop applications como por exemplo persistencia no armazenamento de dados
acesso a funcionalidades do sistema operativo ou integracao e interaccao com outras
aplicacoes sejam elas web applications ou desktop applications
13 Ambito
Este projecto foi realizado na Critical Software SA no ambito do Mestrado
Integrado em Engenharia Informatica e Computacao (MIEIC) da Faculdade de En-
genharia da Universidade do Porto (FEUP) entre os meses de Fevereiro e Julho de
2008
14 Objectivos
Sao objectivos deste projecto
1 Estudar e documentar o tema das OWAs acompanhando os ultimos desenvolvi-
mentos nesta materia
2 Analisar o estado da arte fazendo uma analise crıtica e objectiva sobre as
diversas metodologias existentes
3 Implementar uma prova de conceito que permita a execucao offline de uma
web application documentando todo o processo
4 Estudar a possibilidade de permitir interaccao com a aplicacao (insercoes e
alteracoes aos dados) em modo offline
Em resumo o objectivo deste projecto foi estudar documentar e implementar
uma prova de conceito relacionada com o tema Offline Web Applications (OWA)
Este tema embora nao seja totalmente novo ganhou destaque ao longo do ano de
2007 com o surgimento de diversas ferramentas que se destinam a aproximar web
applications das desktop applications
15 Estrutura do documento
Este documento esta organizado em diferentes seccoes apresentando o projecto
numa sequencia logica organizada da seguinte forma
No capıtulo 1 faz-se uma breve apresentacao do conceito OWAs e do contexto em
que surge Apresenta-se tambem a estrutura do documento e definem-se os
termos e acronimos utilizados
3
Introducao
No capıtulo 2 faz-se uma descricao da evolucao das tecnologias que antecedem as
OWAs e das vantagens e desvantagens de cada uma como forma de enquadra-
mento
No capıtulo 3 analisa-se o estado da arte nesta materia Introduzem-se diversas
tecnologias directamente relacionadas com o tema deste projecto exemplos de
aplicacoes que as usam e as razoes que fundamentam as escolhas de tecnologias
efectuadas
O capıtulo 4 contem o desenvolvimento do projecto Analisa-se a plataforma
WOW de gestao integrada de ordens de trabalho a tecnologia escolhida e
a forma como foi utilizada para implementar a capacidade de execucao offline
O capıtulo 5 descreve os resultado obtidos comparando-os com as expectativas
iniciais do projecto e apresenta desenvolvimentos futuros e possibilidades de
continuacaoaplicacao do conhecimento adquirido
No capıtulo 6 apresentam-se as conclusoes
4
Capıtulo 2
Enquadramento do Projecto
Neste capıtulo apresenta-se um breve resumo da evolucao das arquitecturas de
software cliente-servidor e a forma como estas se comparam a evolucao da Inter-
net procurando estabelecer uma analogia entre o percurso de ambas as tecnolo-
gias Compara-se o comportamento e arquitectura dos thin-clients as paginas web
estaticas a evolucao dos fat-clients as paginas interactivas Web 20 e Ajax e
defende-se que as OWA constituem um proximo passo logico e evolutivo aproxi-
mando a web do desktop Referem-se ainda os principais factores que justificam a
importancia das OWAs e a estreita relacao que tem com as Rich Internet Application
(RIA)s
21 Evolucao das arquitecturas de software
Os termos thin-client e fat-client sao utilizados quer para descrever arquitecturas
logicas (de software) quer para descrever arquitecturas fısicas (de hardware) Neste
capıtulo excepto quando seja dada indicacao em contrario estes termos referem-se
sempre a uma arquitectura logica
Adicionalmente quando se trata de arquitecturas cliente-servidor pode-se estu-
dar a arquitectura desenvolvida do sistema como um todo da arquitectura do servi-
dor ou da arquitectura do cliente Para evitar equıvocos em especial na seccao 213
especifica-se em cada caso qual o sistema estudado
211 Thin-clients
Um thin-client e um computador cliente ou software cliente que no contexto
de uma arquitectura cliente-servidor depende de um servidor central para as suas
5
Enquadramento do Projecto
actividades de processamento e proporciona um canal de entrada e saıda de in-
formacao entre o utilizador e o servidor remoto Este termo quando aplicado a
hardware refere-se habitualmente a um computador que se destina a ser utilizado
como cliente de rede sem armazenamento local e com capacidade de processamento
reduzida [Gro02b] mas o conceito que aqui se analisa refere-se a uma arquitectura
de software que remonta ao inıcio das aplicacoes cliente-servidor
No inıcio da historia da computacao terminais ligavam-se directamente a main-
frames responsaveis por todo o processamento Nesta arquitectura era necessario
desenvolver duas aplicacoes distintas uma aplicacao central no servidor (main-
frame) responsavel pela gestao de toda a informacao e por todas as operacoes de
comunicacao e uma aplicacao de visualizacao instalada no cliente (terminal) O
papel destes terminais era apenas disponibilizar ao utilizador um meio de comu-
nicacao (entrada e saıda) e apresentacao dos resultados do servidor Nao tinham
um papel activo no calculo nem na logica de negocio e frequentemente nao tinham
tambem nenhum mecanismo de armazenamento de dados
Como vantagens esta arquitectura apresenta uma reduzida necessidade de con-
figuracao e manutencao do lado do cliente Uma vez que o centro do processamento
e manipulacao de dados ocorre no servidor existe tambem uma centralizacao da
informacao [NJN00] que introduz um ponto crıtico de falha1 Actualizacoes e novas
funcionalidades sao faceis de distribuir uma vez que requerem apenas alteracoes no
servidor [Gro02a]
212 Fat-clients
Contrastando com os thin-clients nesta arquitectura os clientes implementam
ja uma parte da logica de negocio e sao responsaveis pelo processamento de dados
Estes fat-clients vieram responder a necessidade crescente de aplicacoes com um
nıvel de interactividade e capacidade de configuracao maior que as oferecidas pela
arquitectura thin-client descrita na seccao 211 Apesar de manterem a sua de-
pendencia do servidor podem tambem ser executados sem uma conexao activa uma
vez que dispoe de armazenamento de dados local o que lhes confere a capacidade
de persistencia de dados e do estado de execucao entre cada sessao
Foi disponibilizando este controlo sobre o estado da aplicacao bem como acesso
a recursos locais (por exemplo sistema de ficheiros e perifericos) que surgiram as
primeiras verdadeiras desktop applications No entanto cada cliente tinha que ser
separadamente instalado no computador pessoal de cada utilizador que pretendesse
utilizar ou interagir com a aplicacao e uma actualizacao ao servidor implicava in-
variavelmente uma actualizacao manual tambem no cliente Uma vez que nem todos
1NT single point of failure
6
Enquadramento do Projecto
Thin-clients Fat-clientsNao toma parte no processamento dedados nem possui acesso ao sistema deficheiros
Participa activamente no processa-mento de dados recorrendo ao sis-tema de armazenamento local para ar-mazenamento de dados
Nao mantem registo do estado logicoda aplicacao entre duas sessoes de uti-lizacao
O acesso ao armazenamento localpermite-lhe manter registo do estadologico da aplicacao entre duas sessoes
O thin-client nao necessita de qualquerinstalacao estando ldquopronto a utilizarrdquo
E geralmente necessario instalar aaplicacao para poder interagir com oservidor
Qualquer update no servidor reflecte-seimediatamente por todos os clientes
Embora a aplicacao cliente possa aler-tar para existencia de novas versoes asactualizacoes tem que ser manualmenteinstalados pelo cliente
O software do cliente destina-se apenasa apresentacao de dados e comunicacaocom o servidor sendo portanto de sim-ples implementacao
Como o software do cliente toma parteactiva no processamento de dadosa sua implementacao requer cuidadosadicionais
Grande mobilidade uma vez que todaa informacao e mantida no servidor
Parte da informacao podera estar ape-nas do lado cliente pelo que existemalgumas restricoes a sua mobilidade
Tabela 21 Comparacao entre thin-clients e fat-clients
os utilizadores actualizam regularmente as suas aplicacoes o servidor tem que estar
preparado para lidar com versoes antigas2 ou descontinuar os seus servicos a uma
parte da sua comunidade de utilizadores ate que estes actualizem os seus sistemas
Como os utilizadores passam a utilizar os seus recursos locais para armazenamento
de dados as alteracoes que nao sejam sincronizadas com o servidor estao apenas
disponıveis nos seus computadores pessoais o que introduz uma restricao a mobili-
dade
Pode-se afirmar que as vantagens dos thin-clients sao as desvantagens dos fat-
clients e que as vantagens dos fat-clients sao as vantagens dos thin-clients tal como
se ilustra na Tabela 21
213 Arquitecturas cliente-servidor
Introduzidos os termos thin-client e fat-client interessa reafirmar que ambos
podem ser vistos como arquitecturas cliente-servidor Um cliente define-se como
um solicitador de servicos e um servidor como um prestador de servicos tal como
definido por [Sch96] e [Sad97]
2NT backward compatibility
7
Enquadramento do Projecto
As arquitecturas cliente-servidor sao categorizadas pela modularizacao com que
sao desenhadas sendo consideradas as seguintes camadas
1 Interface grafica (front-end) atraves da qual os utilizadores interagem com
a aplicacao Quando este modulo e implementado separadamente dos outros
dois constitui uma aplicacao thin-client por si so uma vez que nao implementa
regras de negocio (embora possa definir validacoes de formularios de insercao de
dados por exemplo) A informacao introduzida pelo utilizador e enviada para
o servidor que processa o seu pedido e retorna uma resposta Este processo
repete-se ate que o utilizador atinja o seu objectivo ou se desligue do sistema
2 A logica de negocio tambem designada por camada intermedia que imple-
menta as regras de aceitacao e validacao de todos os dados introduzidos pelo
utilizador E tambem a plataforma de comunicacao que une a camada superior
de visualizacao com a camada de acesso a dados
3 A camada de dados inclui quer o sistema de persistencia de dados onde sao
armazenados os dados relevantes como tambem os mecanismos necessarios
para a sua pesquisa seleccao e alteracao
Os thin-clients quando observados no seu conjunto de cliente e servidor podem
ser vistos quer como sistemas de duas camadas quer como sistemas de tres camadas
dependendo apenas da forma como o servidor for implementado No caso de na
implementacao do servidor nao se distinguir a camada de acesso a dados da camada
da logica de negocio sao designados por sistemas de duas camadas Caso seja feita
esta distincao sao designados por sistemas de tres camadas Ambos os casos sao
ilustrados na Figura 21
Historicamente os fat-clients eram implementados numa arquitectura em duas
camadas Possuıam apenas um modulo de visualizacao de dados designado por
camada de interface e um modulo que implementava toda a logica de negocio e
regras de acesso a base de dados No entanto com a introducao de ligacoes mais
rapidas e de computadores pessoais com maior capacidade de processamento e so-
bretudo devido a complexidade crescente das aplicacoes a logica de negocio e a
camada de acesso a dados tornaram-se independentes Este modelo e designado por
arquitectura em tres camadas e e ilustrado na Figura 22
22 Evolucao na Internet
Ao analisar a evolucao das arquitecturas das aplicacoes desenvolvidas para a
Internet podemos encontrar um paralelismo com a historia da arquitectura de soft-
ware
8
Enquadramento do Projecto
Figura 21 Arquitectura de um sistema thin-client em duas camadas (a esquerda) e emtres camadas (a direita) Note-se a inclusao do servidor (mainframe) na definicao dascamadas desta arquitectura devido a forte dependencia cliente-servidor
221 Paginas web estaticas
Uma pagina web estatica devolve sempre a mesma resposta a todos os pedidos
para todos os utilizadores e em qualquer contexto utilizando o hipertexto como
forma de ligacao entre diversas paginas estaticas
A informacao e armazenada num servidor e o papel do cliente e apenas a apre-
sentacao da informacao Esta forma de disponibilizacao de informacao pode assim
ser comparada com os thin-clients descritos na seccao 211 o utilizador acede a
um website estatico para visualizar informacao sem que o cliente tome parte no
processamento A unica diferenca e que no caso da web estatica a informacao ap-
resentada e sempre a mesma enquanto que nos thin-clients era frequente existir a
possibilidade de insercao de dados no cliente e apos o seu processamento servidor
nova informacao poderia ser apresentada O hipertexto e utilizado para ligar as
paginas entre si numa rede de conteudos relacionados e a navegacao sıncrona era
feita atraves de cliques do rato a cada clique uma nova pagina era apresentada
Este modelo sıncrono e ilustrado na Figura 23
222 Paginas web interactivas e paginas web dinamicas
O JavaScript e uma linguagem interpretada de scripting que tem os browsers
como principal ambiente de acolhimento Os browsers utilizam uma Application
9
Enquadramento do Projecto
Figura 22 Arquitectura de um fat-client em duas camadas (a esquerda) e em tres camadas(a direita)
Programming Interface (API) publica para criar ldquoobjectosrdquo responsaveis por reflectir
e disponibilizar o Document Object Model (DOM) para o motor de JavaScript
A utilizacao mais frequente desta linguagem e a escrita de funcoes que sao em-
bebidas ou incluıdas em paginas web e que interagem com o DOM Uma vez que o
JavaScript e executado localmente (na maquina do cliente e nao no servidor) e capaz
de responder rapidamente a accoes do utilizador tornando a execucao de aplicacoes
no browser mais fluıdas o JavaScript pode tambem detectar accoes do utilizador
que o HTML nao pode tal como o pressionar de uma tecla
Em Dezembro de 1995 a Netscape Communications adicionou suporte para o
JavaScript no browser Netscape Navigator3 e em Agosto de 1996 o browser Internet
Explorer4 da Microsoft passou a tambem a suportar uma versao semelhante desta
linguagem (hoje todos os principais browsers suportam esta tecnologia)
Esta inovacao permitiu tornar os websites mais interactivos mas a sua utilizacao
esteve confinada apenas a este proposito durante um longo perıodo As paginas
passaram a responder activamente a accoes do utilizador (sendo uma das utilizacoes
3Netscape Communications ndash httpbrowsernetscapecom4Microsoft Internet Explorer ndash httpwwwmicrosoftcomwindowsproductswinfamilyie
10
Enquadramento do Projecto
mais vulgares a validacao de formularios) mas continuaram essencialmente estaticas
O JavaScript ainda nao era nesta altura utilizado para processar dados
Tambem nesta altura (1995ndash96) surgiram linguagens server-side como o PHP
Hypertext Preprocessor (PHP) e Active Server Pages (ASP) e o servidor passou a ter
um processamento de dados introduzidos pelo utilizador mais activo Generalizaram-
se as paginas dinamicas capazes de responder a insercao de dados ou outros pedidos
determinados por accoes do utilizador As paginas tornaram-se aplicacoes web ap-
plications
Uma definicao tradicional de web application e um conjunto de paginas web
logicamente agrupadas e geridas por uma unica entidade que tem como pontos de
entrada formularios de insercao de dados (web forms) Uma web application nao e
mais do que uma aplicacao que e acedida atraves de um browser Tem geralmente
uma arquitectura logica em tres (interface logica de negocio e camada de dados)
camadas e estao armazenadas num servidor
Ha dois tipos de web applications
bull Orientadas a apresentacao Sao web applications que geram paginas web in-
teractivas constituıdas por varios tipos de linguagens de anotacao (por exem-
plo HTML eXtensible Markup Language (XML)) e que apresentam conteudo
dinamico como resposta a pedidos efectuados pelo utilizador
bull Orientadas aos servicos Uma web application orientada aos servicos imple-
menta o ponto de acesso para um ou mais de um web service Sao geralmente
clientes de service oriented web applications
Uma vantagem significativa de implementar uma web application de forma a
suportar as funcionalidades padrao dos browsers e que estas terao o mesmo com-
portamento independentemente da plataforma e do browser a partir do qual serao
acedidas No entanto diferentes implementacoes de browsers devido a diferentes
interpretacoes dos padroes definidos tornam por vezes esta tarefa um pouco mais
complicada existindo inclusivamente na web guioes de compatibilidade para os difer-
entes browsers como [Smi07]
223 Web 20 e Ajax
O termo web 20 descreve uma tendencia de utilizacao e de design observada
na World Wide Web (WWW) com o objectivo de melhorar a criatividade partilha
de informacao e principalmente a colaboracao entre utilizadores Estes conceitos
levaram ao desenvolvimento e evolucao de comunidades online tais como redes so-
ciais wikis e blogues
11
Enquadramento do Projecto
O termo tornou-se mais conhecido apos a primeira conferencia OrsquoReilly Media
Web 20 em 2004 e apesar de sugerir uma nova versao da WWW nao se refere a
qualquer evolucao tecnologica mas apenas a alteracoes a forma como os utilizadores
se servem da web De acordo com Tim OrsquoReilly [OrsquoR06] ldquoWeb 20 e uma revolucao
na industria do software causada pela adopcao da web como uma plataforma e pela
tentativa de entendimento das regras para o sucesso nesta nova plataformardquo
O desenvolvimento da Web 20 serve-se muitas vezes de um outro conceito Ajax
O conceito que hoje conhecemos como Ajax muitas vezes incorrectamente de-
scrito como uma tecnologia foi originalmente criado para permitir o desenvolvimento
de web applications que se assemelhassem ainda mais a aplicacoes de desktop Este
conceito foi melhor descrito por [Gar05] como um conjunto de varias tecnologias
que podem ser utilizadas para melhorar a experiencia do utilizador de uma dada
web application introduzindo a capacidade assıncrona de envio de pedidos ou da
recepcao assıncrona de respostas As tecnologias mais frequentemente envolvidas
sao
bull eXtensible HyperText Markup Language (XHTML) e Cascading Style Sheets
(CSS) padrao para a apresentacao
bull interaccao dinamica atraves do DOM
bull troca e manipulacao de dados utilizando XML e eXtensible Stylesheet Lan-
guage Transformation (XSLT) ou JavaScript Object Notation (JSON)
bull pedidos assıncronos utilizando XMLHttpRequest [vK08]
bull JavaScript utilizado para integrar todas estas tecnologias
E importante frisar que o Ajax nao e um produto nem uma tecnologia E um
termo que descreve a utilizacao de um conjunto de tecnologias para o desenvolvi-
mento de web applications com um elevado grau de interactividade Comparativa-
mente as web applications tradicionais o Ajax introduz uma camada de visualizacao
diferente em tres importantes pontos
1 Do lado do cliente existe um motor que serve de intermediario entre a interface
da aplicacao e o servidor
2 A actividade do utilizador despoleta chamadas JavaScript em vez de um pedido
de pagina directamente ao servidor
3 Informacao codificada em XML em vez de paginas HTML e trocada entre o
servidor e o cliente
12
Enquadramento do Projecto
Isto significa que as paginas que utilizam Ajax contem um motor do lado do
cliente composto por um conjunto de funcoes JavaScript responsavel pela comu-
nicacao com o servidor e por actualizar a interface com o resultado dessa mesma
comunicacao
Na Figura 23 ilustra-se a natureza assıncrona do Ajax quando comparada com
as web applications tradicionais Como se pode observar adicionando um mecan-
ismo Ajax a uma web application eliminam-se diversos tempos de espera associados
a comunicacoes com o servidor uma vez que a interface nao fica ldquobloqueadardquo a es-
pera da resposta Obtem-se assim aplicacoes com um comportamento mais fluido
eliminando tempos de espera entre cada ldquocliquerdquo e melhorando a experiencia do
utilizador
23 Offline Web Applications
A informacao grafica (bem como folhas de estilo e scripts) tais como as ima-
gens que constituem o visual de uma web application e ja tratada de forma especial
pelos cada vez mais avancados sistemas de cache (armazenamento temporario) dos
browsers Mas estes nao sao ainda capazes de guardar conteudo criado pelo uti-
lizador nem de apresentar informacao independentemente do estado da ligacao
Numa altura onde se fala de servicos de Internet wireless municipalizados [Kha]
comunicacoes 3G e ligacoes de banda larga a alta velocidade a ligacao a rede global
continua a nao estar permanentemente disponıvel para os utilizadores Na WWW
encontra-se uma importante parte da informacao e das aplicacoes utilizadas para
criar e editar conteudos Por vezes informacao vital para a produtividade pode
desaparecer subitamente do mapa de acesso de um utilizador quando este entra no
metro num aviao ou mesmo quando se desloca para uma cidade ou paıs diferente
do habitual onde nao subscreve um plano de acesso que lhe garanta a ligacao
Permitir o acesso offline a estes recursos assume assim a sua importancia porque
permitira estender o alcance da informacao a locais onde nunca esteve antes e per-
mitira tambem melhorar o desempenho das web applications colocando informacao
mais perto dos utilizadores reduzindo a transferencia de dados apenas ao essencial
24 Comparacao
Nas evolucoes descritas neste capıtulo 2 pode-se observar que existe um par-
alelismo entre a evolucao das arquitecturas tradicionais cliente-servidor e a evolucao
a que se assiste na web O comportamento e arquitectura dos thin-clients assemelha-
se ao das paginas estaticas no sentido em que o browser nao toma parte em qualquer
13
Enquadramento do Projecto
processamento e serve apenas como uma plataforma de interaccao com o servidor
tal como os clientes descritos na seccao 211
A sua proxima evolucao os fat-clients trouxeram parte da capacidade de pro-
cessamento para o lado do cliente Na web foi tambem esta a inovacao tecnologica
a que se assistiu com a evolucao das tecnologias que permitiram a criacao de ver-
dadeiras aplicacoes e com a introducao do Javascript no browser dando ao cliente
a capacidade de processamento de dados A necessidade da separacao do codigo
em camadas logicas advem da crescente complexidade das web applications Esta
pratica permite entre outras coisas melhorar o processo de desenvolvimento e a
capacidade de manutencao de uma aplicacao
Os fat-clients tem tambem a capacidade de armazenamento de dados o que
permite a persistencia de informacoes entre duas sessoes e que algumas operacoes
sejam executadas sem a necessidade de comunicacao com o servidor Este facto pode
tambem ser uma realidade nas web applications com a adopcao das tecnologias OWA
Neste momento assiste-se a uma utilizacao cada vez maior da web como uma
plataforma de desenvolvimento A capacidade de cooperacao na edicao de conteudos
e a mobilidade proporcionada por esta plataforma sao os principais factores que
alimentam esta mudanca e pela primeira vez as aplicacoes tradicionais tem com-
peticao vinda de web applications A prova do reconhecimento da web como plataforma
de desenvolvimento pode ser retirada da aposta de empresas como a Adobe e Mi-
crosoft que lancaram publicamente ferramentas web complementares a produtos
seus tradicionalmente associados ao desktop ndash Acrobatcom5 e Microsoft Office
Live6 Dotar estas web applications da capacidade de execucao offline significa
aproximar a web e o desktop reunindo ldquoo melhor de dois mundosrdquo
As vantagens da mobilidade possıvel atraves da web a cooperacao na criacao e
edicao de conteudos e a possibilidade de utilizar aplicacoes sempre actualizadas e
sem necessidade de instalacao sao algumas das principais vantagens que promovem
esta mudanca que devido as preocupacoes associadas a usabilidade e experiencia do
utilizador esta fortemente associada ao desenvolvimento de Rich Internet Applica-
tion (RIA)s
5Adobe Acrobatcom httpwwwacrobatcom6Microsoft ndash httpsmallbusinessofficelivecom
14
Enquadramento do Projecto
Figura 23 Comparacao do modelo de web aplications sıncrono paginas estaticas e in-teractivas abordados nas seccoes 221 e 222 com o modelo de web applications Ajax(assıncrono) abordado na seccao 223 Figura adaptada de http www adaptivepath
com
15
Enquadramento do Projecto
16
Capıtulo 3
Estado da arte
Apesar de o conceito das OWAs nao ser absolutamente novo as tecnologias que
o suportam sao recentes Neste capıtulo descrevem-se quatro tecnologias que foram
tidas como principais candidatas para o desenvolvimento deste projecto Descrevem-
se ainda alguns exemplos de web applications que disponibilizam actualmente fun-
cionalidades offline e o processo da escolha da tecnologia a utilizar neste projecto
31 Gears
O Gears1 e uma extensao as funcionalidades do browser introduzido pelo Google
que tem como principal objectivo tornar possıvel a visualizacao de paginas de Inter-
net mesmo sem uma conexao disponıvel Encontra-se disponıvel para as platafor-
mas Windows Macintosh e Linux e oferece uma API de Javascript que permite
a scripts aceder a um mecanismo de armazenamento local baseado numa base de
dados SQLite
311 Arquitectura
Esta ferramenta e constituıda por tres componentes principais
bull LocalServer mdash Intercepta pedidos de paginas web e serve-as localmente
bull Database mdash Uma base de dados relacional construıda sobre SQLite
bull WorkerPool mdash Permite executar operacoes de computacao de uma forma
assıncrona sem afectar a capacidade de resposta e fluidez de execucao da web
application Assemelham-se a processos
1Google Inc ndash Mais informacao em httpgearsgooglecom
17
Estado da arte
LocalServer
O modulo LocalServer e uma cache de Uniform Resource Locators (URLs)
controlada pela web application Quando nao existe uma ligacao a Internet e e
feito um pedido para um URL presente nesta cache o LocalServer intercepta-o e
responde ao pedido localmente a partir do disco rıgido do utilizador A aplicacao
pode utilizar dois tipos diferentes de armazenamento local de URLs
bull ResourceStore ndash serve para capturar URLs utilizando exclusivamente a API
de Javascript disponibilizada para o efeito Uma aplicacao podera criar e
utilizar diversos ResourceStores simultaneamente para capturar ficheiros de
dados que necessitam de ser enderecados por um URL tal como um ficheiro
PDF ou uma imagem
bull ManagedResourceStore ndash serve para capturar um conjunto de URLs que estao
relacionados e que sao declarado num ficheiro de manifesto (especificado em
JSON) e que sao automaticamente actualizados O ManagedResourceStore
permite que o conjunto de recursos necessarios para correr uma web application
seja capturado e mantido actualizado automaticamente
A principal diferenca entre estes dois tipos de armazenamento de URLs e a forma
como sao actualizados os seus conteudos Os conteudos de um ManagedResourceStore
sao actualizados sempre que a versao contida no ficheiro de manifesto for alterada
enquanto que os conteudos de um ResourceStore nunca sao actualizados automati-
camente mas apenas quando for explicitamente ordenado pela aplicacao
O LocalServer e capaz de interceptar e servir localmente pedidos de HTTP e
HTTPS sempre que se reunam as seguintes condicoes
1 O URL encontra-se armazenado num ResourceStore ou ManagedResourceStore
2 O sistema de armazenamento local encontra-se activo (enabled = true) Se
o sistema de armazenamento local tiver o atributo requiredCookie o pedido
devera conter um cookie que lhe corresponda
O LocalServer nao necessita de monitorizar o estado da ligacao para atender aos
pedidos Na verdade sempre que as condicoes previamente enunciadas se verificarem
o LocalServer interceptara os pedidos e independentemente do estado da ligacao
a Internet servi-los-a a partir do disco rıgido local Cabera a aplicacao definir qual
o modo em que pretende executar um pedido (online ou offline) definindo o valor
de verdade da propriedade enabled
18
Estado da arte
Database
O modulo Database permite guardar dados da web application assegurando a
sua persistencia Os dados sao guardados de forma relacional no disco rıgido do uti-
lizador2 de acordo com o modelo de seguranca estabelecido pelo Gears3 significando
que uma aplicacao nao pode aceder a conteudos fora do seu domınio
WorkerPool
Nos web browsers uma operacao pesada de computacao pode tornar a interface
lenta e tornar menos agradavel a experiencia do utilizador O modulo WorkerPool
permite correr operacoes em background sem bloquear a interface com o utilizador
Os scripts executados numa WorkerPool nao activam os mecanismos de seguranca
do browser que mostram a mensagem ldquoA script on this page may be busy or may
have stopped respondingrdquo
O WorkerPool comporta-se como um conjunto de processos em vez de threads
Os Workers nao partilham qualquer estado de execucao o que significa que uma
alteracao a uma variavel num Worker nao afecta em nada a execucao de outro
Worker Alem disso os Workers nao herdam automaticamente nenhum codigo dos
seus pais Cada Worker e membro de um WorkerPool e os Workers podem in-
teragir entre si enviando mensagens em formato de texto ou JSON No entanto ha
tambem algumas limitacoes os Workers nao tem acesso ao DOM e objectos como
window ou document nao se encontram acessıveis Isto e consequencia de os Workers
nao partilharem o estado de execucao Mas tem acesso a todas as funcoes built-in
do Javascript A maioria das funcionalidades do Gears pode tambem ser acedida
atraves de uma variavel global especial definida como googlegearsfactory Para
outras funcionalidades especıficas os Workers podem ldquopedirrdquo a pagina principal para
continuar a execucao atraves do envio de mensagens
Outras funcionalidades
bull HttpRequest ndash Este modulo implementa a especificacao W3C XmlHttpRe-
quest definida em [vK08] tornando-a disponıvel para os workers e para a
pagina principal
bull Timer ndash Este modulo implementa a especificacao de timers tal como descrito
por [Hic08] e torna-os disponıveis para os workers e para a pagina principal
2Consultar httpcodegooglecomapisgearsapi_databasehtmldirectories3Consultar httpcodegooglecomapisgearssecurityhtml
19
Estado da arte
bull Factory ndash Esta classe e utilizada para instanciar todos os outros objectos da
API do Gears atraves do seu metodo create Este metodo pode ser utilizado
com os seguintes parametros
ndash betadatabase
ndash betahttprequest
ndash betalocalserver
ndash betatimer
ndash betaworkerpool
312 Goggle Gears em dispositivos moveis
O Gears esta tambem disponıvel em dispositivos Windows Mobile 5 e 6
Os dispositivos moveis estao pela sua natureza frequentemente desconectados
da Internet Mesmo quando possuem uma ligacao as latencias na transferencia de
dados em redes moveis tornam as aplicacoes pouco fluıdas mas o Gears permite
ultrapassar este obstaculo
O Gears funciona exactamente da mesma forma em dispositivos moveis equipados
com o Windows Mobile 5 e 6 como num computador comum Se uma aplicacao tiver
sido implementado com suporte para o Gears entao tambem estara preparada para
ser executada num dispositivo movel mas as limitacoes dos browsers disponıveis
para dispositivos moveis tem que ser consideradas Isto significa prever as condicoes
que permitam uma boa usabilidade devido aos pequenos ecras destes dispositivos
bem como o seu suporte limitado dos padroes do DOM CSS e JavaScript
32 Adobe AIR
O Adobe AIR4 e um runtime compatıvel com diversos browsers e sistemas opera-
tivos que pretende dar aos programadores a possibilidade de combinar diversas tec-
nologias de producao de conteudos para a Internet no desenvolvimento de Rich Inter-
net Application (RIA)s O Adobe AIR mantem uma relacao com o browser mas es-
tende as suas capacidades e tecnologias permitindo o desenvolvimento de aplicacoes
tambem para o ambiente de trabalho com janelas em tudo semelhantes as do sis-
tema operativo Segundo a Adobe o objectivo e complementar o browser dando
aos utilizadores (mas essencialmente aos programadores e equipas de desenvolvi-
mento) a escolha sobre como distribuir as suas aplicacoes Para este efeito o Adobe
AIR tem uma aproximacao diferente do Gears Em vez de ldquoestenderrdquo o browser
acrescentando-lhe funcionalidades o AIR permite tambem o desenvolvimento de
4Adobe - httpwwwadobecomproductsair
20
Estado da arte
aplicacoes que se destinam a ser executadas fora do ambiente do browser mas uti-
lizando as tecnologias comuns da Internet (por exemplo HTML CSS JavaScript
Flash Flex)[CDGH08]
A utilizacao desta tecnologia permite utilizar o browser ou o proprio runtime
Adobe AIR como plataforma de execucao da aplicacao
Na Tabela 31 faz-se uma comparacao das funcionalidades disponıveis de acordo
consoante se escolha o browser ou o desktop como plataforma base para a aplicacao
Uma vez que as aplicacoes Adobe AIR na plataforma desktop tem um caracter
persistente (sao instaladas no computador do utilizador) o Adobe AIR tem um
modelo de seguranca que se assemelha com o das tradicionais aplicacoes desktop
[Ada08] Este modelo e analisado nas seccoes 321 e 322 O ambiente em que
e executado o browser e restringido a execucao de web applications que podem
ser de varias origens (incluindo de origens anonimas ou sem confianca) O Adobe
AIR proporciona acesso a capacidades como acesso a ficheiros que necessitam da
confianca do utilizador
bull HTML ndash O desenvolvimento de aplicacoes para o Adobe AIR pode ser feito
com recurso a tecnologias de HTML e Ajax comuns utilizando as linguagens
de markup existentes distribuıdas como texto e interpretadas em execucao
(runtime)
bull Flash ndash Outra alternativa sera a utilizacao da linguagem Flash Permite a
renderizacao de graficos vectoriais e audiovıdeo com suporte nativo Utiliza
ActionScript para adicionar maior interactividade com o utilizador
bull Flex ndash O Flex e uma framework open source para o desenvolvimento de RIAs
usando Flash As aplicacoes Flex sao na realidade Flash sendo a principal
diferenca o ambiente de desenvolvimento
Como resultado uma aplicacao AIR podera ser implementada
bull Baseada em Flash ou Flex (aplicacoes cujo conteudo base e em ShockWave
Flash (SWF))
bull Baseada em Flash ou Flex tambem com HTML ou Portable Document Format
(PDF) Aplicacoes cujo conteudo de base e em FlashFlex (SWF) com HTML
(HTML JavaScript CSS) ou conteudo PDF incluıdo
bull Baseada em HTML Aplicacoes cujo conteudo base e em HTML Javascript
CSS
bull Baseada em HTML utilizando tambem FlashFlex ou PDF
21
Estado da arte
Os utilizadores interagem com uma aplicacao AIR da mesma forma que interagem
com outras aplicacoes com janelas nativas do seu sistema operativo O runtime e
instalado uma vez no computador do utilizador e a partir desse momento todas as
aplicacoes AIR terao o mesmo aspecto que qualquer outra aplicacao para o desktop
321 Seguranca
Permitir que uma web application aceda ao disco de armazenamento do utilizador
pode comprometer seriamente a sua seguranca Neste sentido o Adobe AIR tem
suporte para assinaturas digitais (Secure Sockets Layer (SSL)) que podem ser com-
pradas pelas equipas de desenvolvimento que o desejem e cujos certificados serao
apresentados ao utilizador no momento da instalacao Um outro aspecto ainda
relativo a seguranca e o mecanismo de isolamento de cada ambiente (sandbox )
322 Assinatura do codigo
O runtime AIR exige que todas as aplicacoes estejam digitalmente assinadas As
assinaturas digitais de codigo sao um processo que visa garantir a integridade da
aplicacao e a identidade do seu autor no momento da instalacao As equipas de
desenvolvimento podem ldquoassinarrdquo uma aplicacao utilizando um certificado atribuıdo
por uma Entidade Certificadora (Certification Authority) ou atraves de um certifi-
cado individual (self signed certificate) Neste momento o Adobe AIR suporta como
entidades certificadoras a Verisign e a Thawte [Ado08]
O instalador apresenta o nome de quem publica a aplicacao quando o codigo tiver
sido assinado com um certificado que apresente confianca ou que esteja encadeado
com um certificado que tenha ja sido aceite no computador em que se esta a instalar
a aplicacao
As equipas de desenvolvimento podem tambem assinar as aplicacoes com um
certificado auto-atribuıdo (um certificado criado por elas proprias) mas neste caso
o instalador apresentara estas aplicacoes como sendo de uma origem nao verificada
O AIR utiliza a infraestrutura publica de chaves [Ent07] suportada pelo arquivo
local do sistema operativo Para que a origem da aplicacao seja reconhecida o
computador onde a aplicacao AIR esta a ser instalada tem que confiar directamente
no certificado que foi utilizado para assinar a aplicacao ou confiar num certificado
que esteja num encadeamento logico de certificados confiados e que se ligue desta
forma ao certificado utilizado para assinar a aplicacao
Todas as aplicacoes AIR tem caracterısticas em comum independentemente da
tecnologia utilizada para o seu desenvolvimento (HTMLFlexFlash) No ambito
de uma aplicacao AIR existem um conjunto de APIs que estao disponıveis e que
tornam possıvel o acesso ao sistema local (leitura e escrita) e a recursos de rede que
22
Estado da arte
de outra forma nunca estariam acessıveis a partir de uma web application comum
Cada aplicacao AIR possui tambem diferentes nıveis de isolamento chamados secu-
rity sandboxes dependendo do tipo de conteudo que esta a ser carregado e do seu
objectivo
bull Isolamento ao nıvel da aplicacao5 ndash E a raiz de cada aplicacao AIR Este
nıvel de isolamento permite o acesso a APIs privilegiadas e especıficas do
AIR Em contrapartida e negado o acesso a algumas APIs que poderiam ser
facilmente utilizadas de forma maliciosa contra o utilizador final Importacao
dinamica de conteudos remotos e geralmente proibido e as tecnicas e mecan-
ismos de geracao dinamica de codigo sao fortemente restringidas Apenas
conteudo carregado directamente da directoria base da aplicacao podera ser
colocado neste nıvel de isolamento
bull Isolamento nao especıfico da aplicacao6 ndash contem todo o outro conteudo
que nao tenha sido carregado directamente para o isolamento da aplicacao
Isto inclui conteudo local e remoto Este tipo de conteudo nao tem acesso
directo as APIs do AIR e rege-se pelas mesmas regras tal como se tivesse sido
carregado por um browser a partir da mesma localizacao (por exemplo HTML
carregado a partir de um domınio remoto comporta-se da mesma forma que se
fosse acedido a partir do browser)
33 Mozilla Prism
331 XML User Interface Language
O eXtensible User Interface Language (XUL) e uma linguagem de anotacao
baseada em XML desenvolvida pela Mozilla Foundation que opera em aplicacoes
Mozilla multi plataforma tal como o Firefox O motor Gecko e a unica imple-
mentacao completa desta linguagem que foi desenhada sobre padroes web comuns
como CSS JavaScript e o DOM e permite o desenvolvimento de interfaces graficas
utilizando elementos pre-definidos tais como window box page textbox radio
button entre outros Infelizmente o XUL nao possui qualquer especificacao formal
ou implementacoes de inter-operabilidade para outros motores que nao o Gecko No
entanto a sua implementacao e licenciada em codigo aberto pelas licencas GNU Gen-
eral Public License (GPL) GNU Lesser General Public License (LGPL) e Mozilla
Public License (MPL)
Enunciam-se algumas caracterısticas desta linguagem
5NT application sandbox6NT non-application sandbox
23
Estado da arte
Liguagem de anotacao poderosa baseada em componentes (widgets) O ob-
jectivo do XUL e permitir a construcao de aplicacoes multi-plataforma em
claro contraste com o Dynamic HyperText Transfer Protocol (DHTML) que se
destina ao desenvolvimento de paginas web Por esta razao o XUL esta orien-
tado a componentes tais como janelas botoes e etiquetas em vez de paginas
cabecalhos de texto e ligacoes de hipertexto Investir tempo e esforco para
atingir este mesmo resultado em aplicacoes baseadas em DHTML compromete
frequentemente a complexidade e desempenho da aplicacao
Baseado em padroes O XUL e um dialecto XML baseado no padrao W3C XML
10 As aplicacoes escritas em XUL sao tambem baseadas em especificacoes
W3C adicionais como HTML 40 CSS DOM nıvel 1 e 2 JavaScript 15
incluindo ECMA-262 Edition 3 (ECMAscript)
Portabilidade entre plataformas Tal como HTML o XUL foi desenhado para
ser independente da plataforma em que e utilizado tornando as aplicacoes
facilmente portaveis entre sistemas operativos nos quais o Mozilla e suportado
Uma vez que o XUL oferece um nıvel de abstraccao dos componentes graficos
de interface que disponibiliza implementa a premissa ldquoum codigo para todas
as plataformasrdquo A interface grafica de todos os produtos centrais Mozilla
(browser instant messenger livro de enderecos) e escrita em XUL com um
unico codigo base que suporta todas as plataformas Mozilla
Separacao entre o nıvel de apresentacao e a logica de negocio Uma das
maiores preocupacoes no desenvolvimento para a Internet e a forte ligacao
entre estas duas camadas (interface e logica) Isto constitui um problema sig-
nificativo no desenvolvimento de grandes aplicacoes especialmente quando o
desenvolvimento e feito em ambientes de equipa porque as capacidades de de-
senvolvimento destas duas partes da aplicacao estao muitas vezes espalhadas
por diferentes elementos O XUL permite uma clara distincao entre a definicao
da aplicacao cliente e da logica de implementacao (XUL eXtensible Binding
Language (XBL) e JavaScript) apresentacao (CSS e imagens) internacional-
izacao (Document Type Definitions (DTDs) e etiquetas de texto em lınguas
especıficas guardados em ficheiros properties) O esquema grafico e apre-
sentacao de uma aplicacao XUL pode ser alterado de forma independente da
sua logica ou implementacao e a aplicacao pode ainda ser traduzida (interna-
tionalization) de forma independente da sua logica implementacao ou apre-
sentacao Este grau de separacao resulta em aplicacoes que sao mais faceis de
manter pelos programadores e facilmente adaptadas por designers e tradutores
24
Estado da arte
Facil adaptacao Outro benefıcio que advem do nıvel de separacao entre logica
de negocio e apresentacao oferecido pelo XUL e a facilidade com que se pode
adaptar uma aplicacao para diferentes clientes ou grupos de utilizadores Um
programador pode utilizar a mesma aplicacao base e adapta-la consoante as
necessidades atraves de diferentes temas (skins) e ficheiros de lınguas Desta
forma uma aplicacao escrita e desenvolvida em Ingles pode ser rapidamente
traduzida para Portugues e distribuıda com outra aparencia mais apropriada
ao cliente alvo
332 Prism
O Mozilla Prism e um browser simplificado e ldquointerpretadorrdquo de XUL (tambem
designado por XULRunner) que acolhe web applications sem a interface grafica ha-
bitual de um browser Baseia-se num conceito designado por Site Specific Browser
(SSB) Um SSB e uma aplicacao com um browser embebido desenhado para exe-
cutar apenas uma web application Nao possui os menus e barras de ferramentas
habituais Um SSB tem uma integracao com o sistema operativo e com o desktop
muito mais estreita do que uma web application acedida atraves de um browser uma
vez que e executado em janela propria
O Prism resulta de uma experiencia da Mozilla e visa reduzir as diferencas entre
as desktop applications tradicionais e as web applications Um dos aspectos focados e
a experiencia do utilizador Numa apresentacao oficial e dito que ldquo[o Prism] pretende
ser uma ponte entre as diferencas que existem entre as aplicacoes tradicionais de
desktop e as web applications explorando novos modelos de usabilidade enquanto
que a linha que as separa se continua a definirrdquo [Lab07]
34 HTML 5
A especificacao HTML 5 [Hic08] que se encontra em fase de desenvolvimento
pelo grupo WHATWG pretende ser uma norma de substituicao dos padroes HTML
4 XHTML 1x e do DOM2 HTML Uma das propriedades que o distingue das tec-
nologias que pretende substituir e precisamente o suporte para OWA e armazena-
mento de dados no cliente de uma forma relacional Nao sendo propriamente uma
tecnologia ndashmas antes uma especificacao ndashe aqui mencionada por ter servido como
referencia a diversas implementacoes de funcionalidades offline e por se considerar
que venha a ter um impacto significativo nas implementacoes de diversos browsers
Dion Almaer defendeu no seu blogue que o Gears era uma implementacao do
HTML 5 No seu artigo ldquoGears as a bleeding-edge HTML 5 implementationrdquo [Alm08]
o autor diz que ambos ndasho Gears e o HTML 5 ndashpretendem dar a web caracterısticas
25
Estado da arte
semelhantes e nao encontrar motivo de ldquocompeticaordquo entre as duas mas que en-
quanto o HTML 5 e uma especificacao o Gears e uma implementacao
No entanto tambem e verdade que o HTML 5 cobre muitos outros pontos para
alem das OWA que saem completamente fora do ambito do Gears Se esta es-
pecificacao atingir um estado de maturidade que possibilite a sua adopcao pelos
principais browsers tornando nativo do browser o suporte OWA entao deixara de
fazer sentido a existencia de uma extensao como o Gears
A especificacao HTML 5 disponibiliza duas APIs relevantes para o tema das
OWA
1 Uma base de dados baseada em SQL que permite o armazenamento de dados
do lado do cliente
2 Uma ldquocacherdquo HTTP que garante a disponibilidade das aplicacoes mesmo quando
o utilizador nao possui uma ligacao a Internet
Estas caracterısticas sao as bases da tecnologia das OWA e tem correspondencia
com os pontos analisados nas seccoes 311 e 311
35 Web applications que usam funcionalidades offline
Nesta seccao apresentam-se algumas web applications que actualmente disponi-
bilizam funcionalidades offline Estas aplicacoes foram escolhidas para uma analise
mais pormenorizada por utilizarem o Gears que tal como descrito na seccao 4 foi
a tecnologia escolhida para o projecto
351 Google Reader e Google Docs
O Google Reader7 e um leitor de feeds RSS Permite gerir a subscricao de varios
sites simultaneamente que disponibilizem conteudos neste formato e foi a primeira
web application da Google com uma versao offline publicamente acessıvel (desde
Junho de 2007)
O Google Reader implementa o modo ldquoutilizador deciderdquo oferecendo na sua
interface um botao que permite alternar entre os modos online e offline
O Google Docs8 e uma web application que permite a criacao e edicao de doc-
umentos de texto folhas de calculo e apresentacoes Era ja publico desde Janeiro
de 2008 que o Google estava a desenvolver uma versao OWA desta aplicacao mas o
acesso a uma versao experimental so foi possıvel a partir de 31 de Maio de 2008
7Google Reader - httpreadergooglecom8Google Docs - httpdocsgooglecom
26
Estado da arte
A implementacao das funcionalidades offline nestas duas aplicacoes seguiu difer-
entes aproximacoes principalmente porque o Google Reader apresenta ao utilizador
informacoes que sao fornecidas por fontes externas enquanto que no Google Docs
a informacao e criada e editada pelo utilizador sobre a forma de documentos
A diferente origem da informacao implica que no Google Reader seja necessario
prever casos de excepcao tal como existirem demasiados itens que necessitam de
ser transferidos para o cliente Nao observar este ponto causa um problema grave
de usabilidade e para evitar tempos de espera demasiado longos e uma interface
com pouca capacidade de resposta as accoes do utilizador o Google Reader apenas
transfere para o cliente os dois mil itens mais recentes na transicao para o modo
offline
352 Remember the Milk
O Remember The Milk9 e uma web application desenvolvida por uma equipa
Australiana que proporciona funcionalidades de agenda gestao de tempo e de tare-
fas e foi uma das primeiras aplicacoes independentes do Google a adoptar o Gears
para acessos em modo offline Permite que os seus utilizadores facam uma gestao
de tarefas agrupando-as em listas adicionando-lhes campos de informacao adicional
ou dando-lhes informacao geografica (recorrendo ao servico Google Maps10) Entre
a sua lista de funcionalidades encontra-se ainda a possibilidade de importar e ex-
portar eventos no formato iCalendar (ics) etiquetas (tags) em tarefas publicacao
Really Simple Syndication (RSS) e partilha de categorias de tarefas de acordo com
diferentes nıveis de permissoes de acesso definidos pelo utilizador
353 MySpace e WordPresscom
O MySpace uma das maiores social networks na Internet anunciou recente-
mente que vai disponibilizar uma versao do seu cliente de e-mail que utiliza o Gears
para acelerar o seu desempenho Numa fase inicial estara disponıvel apenas para
utilizadores que tenham cinco mil ou mais mensagens na sua caixa de correio e
permitira efectuar pesquisas muito mais rapido que a sua versao online
O servico de blogs Wordpresscom anunciou tambem o inıcio da utilizacao desta
tecnologia com o fim de melhorar o desempenho A versao que utiliza esta tecnologia
descarrega e armazena no cliente um conjunto de imagens e scripts que passam a
ter preferencia sobre os seus congeneres online e que permitem acelerar o processo
de carregamento da aplicacao e visualizacao de blogs
9Remember The Milk ndash httpwwwrememberthemilkcom10Google Maps ndash httpmapsgooglecom
27
Estado da arte
O MySpace e o Wordpresscom sao dois exemplos da utilizacao da tecnologia
OWA para optimizacao de web application ja existentes Sem pretenderem disponi-
bilizar uma versao que seja totalmente offline fazem uso do Gears para armazenar no
cliente parte dos recursos frequentemente acedidos na visualizacao das suas paginas
36 Escolha da tecnologia
Apos a analise das tecnologias apresentada nas seccoes 31 a 34 foi necessario es-
tudar a adequacao de cada uma delas ao projecto em questao Desde logo e possıvel
observar que nem todas se dedicam apenas a OWA Por exemplo o Adobe AIR
apesar de ter suporte para OWA apenas disponibiliza algumas das funcionalidades
identificadas como mais indicadas para a execucao do projecto quando utilizado
na sua vertente desktop tal como exposto na Tabela 31 mas a utilizacao desta
vertente implicaria o desenvolvimento de novas interfaces e de novas formas de co-
municacao (troca de mensagens XML ou JSON) A vertente web do Adobe AIR
foca-se mais especificamente nas Rich Internet Applications e permite a reutilizacao
do codigo ja existente (exigindo naturalmente a sua adaptacao e a implementacao
das funcionalidades pretendidas)
A tecnologia escolhida para a realizacao deste trabalho foi o Gears sendo que
um dos principais factores a influenciar esta opcao foi a liberdade introduzida pela
sua licenca Berkeley Software Distribution (BSD)11
Considerou-se o funcionamento desta ferramenta extremamente adequando a
aplicacao no WOW uma vez que o seu principal objectivo e precisamente tornar
possıvel a execucao offline de uma pagina web e por virtude deste facto o Gears tem
uma API concisa e de simples aplicacao pratica uma vez que nao possui quaisquer
outros elementos distractores O funcionamento do seu ManagedResourceStore ex-
emplificado na Figura 31 com a capacidade de actualizacao de recursos definidos
num ficheiro manifesto especificado em JSON pesou tambem nesta decisao
11Sobre a licenca BSD consultar httpwwwopensourceorglicensesbsd-licensephp e http
wwwlinfoorgbsdlicensehtml
28
Estado da arte
Figura 31 Esquema UML do processo efectuado pelos recursos do Gears do tipoManagedResourceStore para a actualizacao dos conteudos definidos no ficheiro manifesto
29
Estado da arte
Funcionalidade RIAs no browser RIAs no desktop
Disponibilidadeda aplicacao
As aplicacoes podem ser facil-mente exploradas e utilizadas
As aplicacoes quando instal-adas tem maior grau de fun-cionalidades e persistencia
Instalacao Nao e necessario qualquer tipode instalacao
As aplicacoes sao instaladasatraves do browser ou descar-regadas e instaladas comouma aplicacao tradicional
Actualizacoes Aplicacoes sao actualizadascarregando conteudos paraum website
O AIR disponibiliza uma APIque permite que as aplicacoessejam actualizadas de umaforma
Sistemas opera-tivos suportados
As aplicacoes podem ser exe-cutadas em diversos sistemasoperativos e browsers
As aplicacoes sao multi-plataforma e podem serinstaladas e executadas emdiversos sistemas operativos ebrowsers
Linguagens deprogramacao
Javascript e disponibilizadopelo browser e ActionScripte disponibilizado pelo AdobeFlash Player
Maquinas virtuais deJavascript e ActionScriptcompatıveis com o browser
Capacidade deexecucao embackground
As RIAs podem ser execu-tadas numa janela do browser
As aplicacoes podem ser ex-ecutadas em background edisponibilizar notificacoes talcomo uma aplicacao tradi-cional
Persistencia A actividade esta limitada asessao do browser Quando obrowser e encerrado toda ainformacao e descartada
As aplicacoes sao instaladas eestao disponıveis no desktopPodem armazenar informacaolocalmente e estao disponıveisoffline
Integracao com odesktop
Integracao com o desktop lim-itada devido a restricoes im-postas pelo browser
As aplicacoes podem acederao sistema de ficheiro ao clip-board eventos notificacoesetc
Controlo da inter-face com o uti-lizador
As aplicacoes sao acedidasatraves de uma janela dobrowser que tem os seusproprios controlos e visualgrafico
As aplicacoes tem um vi-sual grafico proprio em janelapropria
Armazenamentode dados
As aplicacoes tem armazena-mento limitado que pode serreescrito pelo browser
As aplicacoes tem acesso a to-talidade do espaco disponıvellocalmente e a uma base dedados com a possibilidade deencriptacao
Tabela 31 Comparacao das funcionalidades oferecidas pelo Adobe AIR para as platafor-mas web e desktop
30
Estado da arte
Aplicacao Modo de execucao utilizadoGoogle Reader Utiliza o modo ldquoutilizador deciderdquo disponibilizando
ao utilizador um botao para alternar entre os modosonline e offline Como lida com informacao recol-hida de fontes externas de natureza frequentementeefemera o processo de sincronizacao apenas transfereos dois mil itens mais recentes quando passa ao es-tado offline Neste modo sao ainda guardadas in-formacoes de itens lidos e etiquetas atribuıdas quesao sincronizadas com o servidor quando o utilizadorvoltar a activar estado online
Google Docs Utiliza o modo ldquoaplicacao deciderdquo permitindo que outilizador edite os conteudos de documentos de textofolhas de calculo e de apresentacoes independente-mente do estado da ligacao desde o momento em queas funcionalidades offline sao activadas A aplicacaofaz pequenas sincronizacoes com o servidor sempre quenecessario
Remember the Milk Utiliza um modo hıbrido entre ldquoaplicacao deciderdquo eldquoutilizador deciderdquo A aplicacao encarrega-se da sin-cronizacao de dados mas disponibiliza um controlona sua interface que permite despoletar manualmenteeste processo para situacoes em que o utilizador fez al-teracoes recentes e pretende usufruir das capacidadesoffline imediatamente
MySpace O MySpace anunciou a utilizacao de mecanismos dearmazenamento de dados no cliente com recurso atecnologias OWA para melhorar o desempenho doseu cliente web de correio electronico nomeadamenteno que diz respeito a operacoes de pesquisa e or-denacao Inicialmente esta funcionalidade estara ape-nas disponıvel para utilizadores com cinco mil ou maismensagens na sua caixa de correio mas nao e aindaclaro se sera disponibilizada uma versao totalmenteoffline
Tabela 32 Resumo da utilizacao de tecnologias OWA em algumas web applications con-sideradas na analise do estado da arte
31
Estado da arte
32
Capıtulo 4
Desenvolvimento
Neste capıtulo introduz-se a aplicacao WOW e apresenta-se o estudo que foi
feito da adequacao de cada tecnologia para a implementacao da funcionalidade of-
fline nesta plataforma Fazem-se diversas consideracoes sobre opcoes a tomar na
concepcao de OWAs e problemas comuns na sua implementacao bem como sug-
estoes para os resolver O WOW e uma aplicacao ja existente de gestao de ordens
de trabalho e do fluxo de tarefas numa empresa ou organizacao
41 Como ficar offline
Na maior parte das web applications de hoje nao existe uma camada de dados
real A aplicacao exemplificada na Figura 41 ao longo da sua execucao acede
directamente a sua unica fonte de dados (o servidor) atraves de chamadas Ajax sem
que exista uma separacao clara destas duas camadas
Para que uma web application seja capaz de ser executada sem uma ligacao
activa a Internet e mantenha o seu caracter dinamico torna-se necessario incluir
Figura 41 Exemplo de uma arquitectura de uma web application sem uma camada deabstraccao de dados Figura adaptada de http gears google com
33
Desenvolvimento
Figura 42 Exemplo de uma arquitectura de uma web application com uma camada deabstraccao de dados Figura adaptada de http gears google com
um mecanismo de armazenamento de dados local seja uma base de dados ou a
capacidade de acesso ao disco No entanto este mecanismo introduz dois problemas
1 Qual das fontes de dados utilizar quando um utilizador faz um pedido de
informacao
2 A necessidade de implementar uma camada de acesso a dados que seja coerente
quer se use o servidor remoto ou local
Por exemplo em vez de a aplicacao Ajax fazer um pedido relativo as contas de
todos os utilizadores em formato JSON directamente ao servidor remoto podera ao
inves fazer o pedido a um objecto intermedio da camada de dados Este objecto
demonstrado na Figura 42 sera responsavel por implementar uma interface de
acesso a base de dados e retornar um objecto JavaScript com uma representacao da
resposta do servidor
Mas a existencia de uma segunda fonte de dados torna recomendavel tambem
a implementacao de uma camada de data switching que em funcao da existencia
de conexao a Internet e da necessidade de actualizacao dos dados decide se faz o
pedido ao servidor remoto ou se fornece os dados presentes localmente Este objecto
apresentado na Figura 43 decidira de forma transparente para o utilizador se le ou
escreve os dados localmente ou se os enviapede ao servidor remoto e pode tambem
iniciar o processo de convergencia de dados e de resolucao de conflitos
411 Funcionalidades disponıveis em modo offline
Por razoes praticas e provavel que nem todas as funcionalidades da aplicacao
possam ser disponibilizadas em modo offline E necessario escolher quais as fun-
cionalidades a disponibilizar no modo offline da aplicacao e implementar a logica
que decide quando utilizar a base de dados local ou o servidor remoto Apesar do
acesso a base de dados local ser muito mais rapido do que aceder ao servidor o
acesso local nem sempre e preferido Ha varias razoes que podem tornar necessario
escolher o acesso ao servidor em vez do acesso local
34
Desenvolvimento
Figura 43 Exemplo de uma arquitectura de uma web application com uma camada deabstraccao de dados e um data switch Figura adaptada de http gears google com
1 A informacao pode ter uma natureza efemera e nao fazer sentido guarda-la
localmente Exemplo dados em tempo real da bolsa de valores de Lisboa
2 Algumas aplicacoes lidam com informacao que so faz sentido na presenca de
uma ligacao Exemplo Instant Messaging
3 A aplicacao podera escolher apenas guardar a informacao acedida mais fre-
quentemente Exemplo para o utilizador poder alterar a lıngua de apre-
sentacao da aplicacao os conteudos terao que ser guardados em todas as
lınguas disponibilizadas pela aplicacao O custo de implementacao de algu-
mas funcionalidades pode nao compensar o benefıcio
4 A capacidade de processamento ou de armazenamento de dados pode inviabi-
lizar algumas funcionalidades offline Exemplo se uma dada funcionalidade
necessita de uma capacidade de armazenamento de dados para alem do razoavel
de um computador pessoal para ser util (visualizador de mapas)
42 Modos de execucao
Um aspecto que e necessario estudar para qualquer web application que se deseje
disponibilizar offline prende-se com tres modos de execucao que devem ser consid-
erados
1 Utilizador decide o modo de execucao A aplicacao tem modos distintos
de execucao para os estados online e offline geralmente indicados na interface
com o utilizador O utilizador e informado do estado da ligacao e participa na
alteracao de estado de execucao da aplicacao interagindo com a sua interface
2 Aplicacao decide o modo de execucao Pode ser implementado na propria
aplicacao um mecanismo de deteccao do estado da ligacao (por exemplo atraves
35
Desenvolvimento
de chamadas Ajax periodicas) transitando de estado e sincronizando automati-
camente Desta forma o utilizador nao precisa de participar na alteracao de
estado a menos que exista um conflito de dados que requeira a sua atencao
3 Aplicacao assume sempre o estado offline Outra hipotese sera imple-
mentar uma web application que assume sempre estar na ausencia de uma
ligacao ao servidor de dados Esta aplicacao responde aos pedidos do uti-
lizador efectuando pedidos de informacao ao servidor mas nao dependendo
de uma resposta valida para mostrar a informacao que ja tinha disponıvel an-
teriormente A sincronizacao de dados com o servidor e tentada sempre que
existam dados para submeter e uma accao do utilizador
421 Modo ldquoutilizador deciderdquo
Neste modo de execucao quando a aplicacao esta online comunica com o servidor
remoto quando esta offline comunica com a base de dados local A informacao tem
que ser sincronizada sempre que se muda de modo A principal vantagem desta opcao
e que e a mais simples de implementar mesmo para uma aplicacao ja existente e
portanto uma forma expedita de disponibilizar uma OWA No entanto tem tambem
algumas desvantagens que devem ser consideradas
1 O utilizador tem que se lembrar de fazer a alteracao de estado de execucao
Caso contrario podera estar a trabalhar inadvertidamente numa versao offline
com dados antigos ou nao ter a informacao necessaria se perder subitamente
a ligacao
2 Se a ligacao for intermitente o utilizador tera ou que escolher um dos modos
de execucao ou estar constantemente a trocar
3 Uma vez que a base de dados nao esta sempre actualizada nao podera ser
utilizada para melhorar a rapidez de execucao da aplicacao quando em modo
online
422 Modo aplicacao decide
A deteccao do estado da ligacao pode ser implementada atraves de um pedido
assıncrono ao servidor tal como ilustrado na Figura 44 O resultado deste pedido
definira o estado online (em caso de sucesso) ou offline (em caso de falha) A
sincronizacao de dados podera ser feita sempre que ocorra uma transicao do es-
tado offline para o estado online No entanto este metodo nao se revela eficiente
36
Desenvolvimento
Figura 44 Esquema grafico ilustrando uma OWA executando no browser utilizando ummodo de execucao do tipo ldquoaplicacao deciderdquo com deteccao automatica do estado daligacao via pedidos Ajax assıncronos a cada cinco segundos
para grandes aplicacoes uma vez que requer a troca de mensagens demasiado fre-
quentes com o servidor que se destinam exclusivamente a monitorizacao do estado
da ligacao
423 Modo ldquoaplicacao assume o estado offlinerdquo
Uma aplicacao transparente funciona assumindo sempre que esta em modo of-
fline ou pelo menos que pode perder a ligacao a qualquer momento Neste modo
tira-se o maximo partido do armazenamento local e fazem-se pequenas mas contınuas
sincronizacoes com o servidor sempre que este esteja disponıvel A sincronizacao de
dados tambem e feita sempre que se volta ao estado online
As vantagens de uma web application transparente sao as seguintes
bull Uma melhor experiencia para o utilizador uma vez que este nao tem que se
preocupar com o estado da ligacao ou com a transicao de estados
bull A aplicacao funciona de forma coerente mesmo que a ligacao seja intermitente
bull Uma vez que o armazenamento local e mantido actualizado pode ser utilizado
para melhorar o desempenho da aplicacao
Foram identificadas as seguintes desvantagens
bull E mais difıcil de implementar e a sincronizacao acarreta cuidados especiais
bull E necessario um cuidado adicional para evitar que as operacoes de sincronizacao
frequentes que ocorrem automaticamente nao afectem os tempos de resposta
da aplicacao
bull Os testes a aplicacao sao mais complexos uma vez que a sincronizacao de dados
nao ocorre em resposta a uma accao do utilizador
37
Desenvolvimento
43 Sincronizacao de dados
A sincronizacao de dados consiste na capacidade de identificar e transferir pe-
riodicamente a versao mais actual dos dados entre o cliente e o(s) servidor(es)
Independentemente do modo de execucao escolhido e mesmo do estado da ligacao
do utilizador a informacao armazenada localmente e a informacao armazenada no
servidor estarao por vezes dessincronizadas Isto podera acontecer sempre que por
exemplo
bull O utilizador faz alteracoes em modo offline
bull A informacao e partilhada e pode ser alterada por uma entidade externa
bull A informacao e fornecida por uma entidade externa
Resolver estas diferencas de forma a que a informacao local e remota encontrem
a igualdade chama-se sincronizacao de dados Ha varias aproximacoes possıveis
para este efeito que dependem da natureza da aplicacao cada uma com vantagens
e desvantagens
A capacidade de suportar a mobilidade dos utilizadores torna-se cada vez um
ponto mais importante de uma web application Para uma organizacao de dimensao
global e vital garantir que os seus colaboradores tem acesso a mesma informacao
que tem disponıvel nos seus postos de trabalho mesmo quando estao fora Na maior
parte dos casos estes colaboradores terao acesso a um computador portatil um
desktop Smartphone ou PDA e atraves destes poderao ter acesso a sua informacao
directamente atraves de ligacoes encriptadas Virtual Private Network (VPN) de um
servidor web ou de outro mecanismo de rede
Esta solucao e simples de implementar mas infelizmente para a maioria dos
colaboradores com grande factor de mobilidade nao e satisfatoria As principais
desvantagens sao as seguintes
bull Requisitos de ligacao Para permitir que os utilizadores acedam a sua in-
formacao e necessario garantir a capacidade constante de comunicacao pelo
menos durante o tempo necessario que assegure a sua transferencia
bull Velocidade de ligacao sem persistencia de dados e em ligacoes de fraca
qualidade a usabilidade por vezes torna-se inaceitavel
bull Ponto crıtico de falha Com este tipo de solucao todos os utilizadores de-
pendem da base de dados que armazena informacao vital para o funcionamento
do cliente
38
Desenvolvimento
bull Scalability do servidor A medida que novos utilizadores sao adicionados ao
sistema o desempenho do servidor e afectado levando a necessidade de maior
capacidade de armazenamento eou processamento
De acordo com a documentacao da Microsoft Sync Framework [Mic08] uma
solucao alternativa consiste em implementar uma Occasionally Connected Appli-
cation (OCA) Uma OCA permite a um utilizador remoto continuar a aceder a
sua informacao mesmo depois de perder a ligacao mas em vez de recorrer a um
servidor recorre a informacao armazenada no seu dispositivo local Para preencher
localmente a informacao que o utilizador necessita uma OCA possui mecanismos
de sincronizacao de dados que sao oferecidos por esta framework
431 Quando sincronizar
Uma das solucoes mais simples de implementar passa por disponibilizar um
mecanismo manual que despoleta a sincronizacao Diz-se manual porque e o uti-
lizador que escolhe quando sincronizar e pode ser implementada simplesmente
fazendo o upload de toda a informacao para o servidor e depois fazendo o download
da copia mais recente da informacao antes de voltar a ficar offline Para que esta
seja uma opcao viavel e necessario que
bull O volume de dados seja suficientemente pequeno para que possa ser transferido
do servidor para o cliente num espaco de tempo aceitavel
bull Que o utilizador indique explicitamente que quer mudar para o estado offline
ou online pressionando um botao da interface
Contudo podem ser identificados alguns problemas relacionados com esta abor-
dagem
bull Os utilizadores nem sempre podem prever o estado das suas ligacoes A ligacao
pode-se perder subitamente ou ter um caracter intermitente
bull O utilizador pode esquecer-se de efectuar a sincronizacao
Outra opcao sera conjugar a sincronizacao de dados com o modo de execucao
transparente A sincronizacao ocorre automaticamente em background de forma
nao intrusiva para o utilizador A aplicacao comunica com o servidor regularmente
efectuando pequenas trocas de dados com o objectivo de manter o sincronismo da
informacao local e remota Esta abordagem pode ser implementada com pedidos
Ajax assıncronos e regulares ao servidor o que permite manter a interaccao com a
interface fluıda evitando bloqueios Estes pedidos sao feitos prevendo as situacoes
39
Desenvolvimento
de disponibilidade ou indisponibilidade (timeout) do servidor Uma outra opcao
sera permitir que o servidor comunique essas alteracoes utilizando Comet1 tal como
descrito em [Wil06] e [Rus06] As vantagens destas aproximacoes sao
bull A informacao esta disponıvel a qualquer altura que o utilizador decida ficar
offline ou que a ligacao seja acidentalmente perdida
bull O desempenho da aplicacao pode ser melhorado quando se estiver a utilizar
uma ligacao a Internet lenta uma vez que o acesso a dados locais e mais
eficiente do que a consulta de dados ao servidor
44 WOW
O WOW e uma plataforma integrada de gestao de ordens de trabalho ja ex-
istente e desenvolvida pela Critical Software SA a qual se pretende adicionar a
capacidade de execucao offline Esta aplicacao e extremamente dinamica e con-
figuravel com um conjunto extremamente rico de funcionalidades das quais se
destacam
bull Gestao de Ordens de Trabalho ndash suportando a gestao dos pedidos desde a
sua criacao ate ao seu fecho tomando em conta os diferentes tipos de pedidos
(ordens de trabalho pedidos de informacao melhorias resolucao de problemas
etc) e diferentes tipos de accoes possıveis para cada um (Figura 45)
bull Monitorizacao de alteracoes ndash Historico de mudancas anexos e estados criando
relatorios de alteracao automaticamente (o que por quem e quando)
bull Uso de Service Level Agreements (SLAs) ndash E possıvel associar a um pedido um
SLA que define qual o perıodo de tempo atribuıdo a resolucao de um pedido
controlando e agilizando a resolucao do mesmo
bull Utilizacao de queries de utilizador configuraveis que permitem acesso rapido
a determinadas ordens de trabalho de acordo com o filtro configurado (por
exemplo ldquoPara mimrdquo ldquoPara o Grupordquo ldquoPelo Grupordquo)
bull Gestao do relacionamento entre pedidos
bull Pesquisa e filtragem de ordens de trabalho
bull Exportacao de dados em formatos padrao (PDF DOC ou XLS)
bull Integravel com solucoes externas
40
Desenvolvimento
Figura 45 Detalhe de um conjunto possıvel de estados e respectivas transicoes para umadada ordem de trabalho no WOW desde a sua submissao no sistema ate a sua conclusaoem fecho ou cancelamento Esta figura representa apenas um exemplo ja que o mapa deestados para uma ordem de trabalho e dinamico e pode ser alterado por um administradorFigura retirada de uma brochura promocional do WOW Critical Software SA
A utilizacao de uma ferramenta deste tipo por parte de uma empresa ou orga-
nizacao oferece vantagens quer a gestao de topo quer aos colaboradores individuais
para os colaboradores individuais o WOW e uma aplicacao onde estao registadas
todas as tarefas contribuindo activamente para o desenvolvimento em ambientes
multi-tarefa e para a organizacao pessoal das tarefas de acordo com prioridades
Para a gestao de topo esta ferramenta permite obter uma visao global do estado da
organizacao em termos de tempo gasto por tarefa executada sendo uma mais valia
para a previsao e gestaoalocacao de recursos
45 Visao geral sobre a arquitectura do WOW
O WOW e interessante nao so do ponto de vista de produto como tambem do
ponto de vista de plataforma Existem diversos plug-ins que estendem as funcional-
idades do WOW e existem ate projectos que pretendem usar a arquitectura do
WOW para criar produtos com fins diferentes do inicial (por exemplo o WOW-
Storm ndash um sistema de registo e classificacao social de ideias)
De modo a conseguir ter essa expansibilidade a plataforma WOW assenta sob
uma arquitectura distribuıda modular e expansıvel com uma componente central
ndash o core ndash estruturado em camadas logicas E no core que se situam todas as
1O Comet e um conceito semelhante ao Ajax introduzido por Alex Russel mas no qual e o servidor quetoma a iniciativa de ldquoenviarrdquo os dados ao browser sem que este tenha que efectuar um pedido Tambem econhecido por Ajax Push Reverse Ajax ou HTTP Streaming
41
Desenvolvimento
funcionalidades base da aplicacao quer a nıvel logico funcional e de apresentacao
quer a nıvel de gestao e configuracao
E possıvel a execucao de varias instancias do core simultaneamente em servidores
distintos o que permite a alta escalabilidade e disponibilidade desta aplicacao A
consistencia dos dados fica sempre garantida atraves da partilha da base de dados
e pelo balanceamento dos pedidos uma vez que cada um e encaminhado para uma
unica instancia
O WOW apresenta tambem a vantagem de ser uma plataforma extensıvel E
possıvel adicionar novas caracterısticas a plataforma atraves de componentes que se
podem ser divididos em duas categorias plugins e connectors
Os plugins sao componentes que se encontram no mesmo no fısico que a aplicacao
partilhando do mesmo contexto de execucao do core Sao assim uma forma mais
directa de obter informacao da plataforma visto que nao possuem restricoes de
acesso aos dados nem dependencias externas A arquitectura deste componente tera
assim que permitir varias execucoes instanciadas cada uma associada a um core
Por outro lado os connectors sao componentes que se encontram distribuıdos
comunicando externamente com o core Quer a sua execucao quer a obtencao
dos dados estao assim dependentes de interfaces de comunicacao externas que a
plataforma disponibiliza Estes componentes ao contrario dos plugins sao instan-
ciados unicamente e recorrem ao protocolo de comunicacao Java Messaging Service
(JMS) para comunicar com o core
46 WOW Offline
Para alem das opcoes tomadas relativamente a tecnologia a utilizar surgiu
tambem a necessidade de optar por um dos modos de execucao apresentados na
seccao 42
Das tres opcoes possıveis foi o modo ldquoaplicacao assume o estado offlinerdquo descrito
na seccao 423 que mereceu a maior atencao uma vez que reune as vantagens de
uma experiencia mais positiva para o utilizador (uma vez que este nao tem que
participar activamente na alteracao do modo execucao como descrito na seccao 421)
e nao constitui uma sobrecarga excessiva para servidor (como o modo abordado na
seccao 422)
No entanto esta opcao comprometia a complexidade da implementacao para alem
dos objectivos propostos para este projecto e para cumprir o prazo dado foi tomada
a decisao de implementar o modo ldquoutilizador deciderdquo especificando apenas de forma
teorica o modo ldquoaplicacao assume o estado offlinerdquo
As caracterısticas do Gears foram ja descritas na seccao 31 Na Figura 47
mostra-se a sua forma de funcionamento quando integrado numa web application
42
Desenvolvimento
Nesta figura representa-se o modulo LocalServer do Gears como um ponto de de-
cisao Aqui sao testadas as condicoes que determinam se o pedido sera interceptado e
servido localmente ou se prossegue para uma maquina remota E tambem represen-
tada uma base de dados que corresponde ao modulo Database mas que podera nao
ser utilizada Este modulo tal como o modulo Workerpool tem caracter opcional
e sao utilizados consoante os requisitos da aplicacao
A plataforma WOW lida com mais dados do que e necessario passar para o
lado do cliente Em conformidade com o ja exposto na seccao 411 volta-se a
frisar que nao se pretende recriar toda a logica de negocio nem os conteudos da
base de dados no cliente pela sua complexidade e volume de dados Pretende-se
pelo contrario permitir que os utilizadores tirem partido da capacidade de poder
consultar as suas ordens de trabalho quando nao dispoe de uma ligacao transferindo
apenas o essencial para isto seja possıvel
A pagina inicial do WOW apresenta um resumo das ordens de trabalho abertas
ndash enviadas e recebidas ndash que se pretende permitir visualizar offline (ver Figura 46)
Como prova de conceito foi efectuada uma abordagem pragmatica das varias possi-
bilidades descritas na seccao 42
461 Modo ldquoaplicacao deciderdquo com deteccao automatica da ligacao
A primeira abordagem estudada para a disponibilizacao das funcionalidades of-
fline foi o modo ldquoaplicacao deciderdquo com deteccao automatica de ligacao apresentado
na seccao 422 Para que isto seja possıvel foi implementado um mecanismo de ver-
ificacao periodica do estado da ligacao atraves de chamadas Ajax assıncronas O
resultado destes pedidos determina o estado da aplicacao executando as tarefas de
sincronizacao de dados sempre que pertinente Este metodo embora imediato e
simples de implementar depressa se revelou inadequado para o projecto devido ao
elevado consumo de recursos do servidor que a utilizacao intensiva faz esperar a
comunidade da plataforma WOW no principal cliente excede os 7000 utilizadores
Foi estimado que para uma utilizacao de fluidez aceitavel o estado da ligacao deveria
ser testado a cada cinco segundos Assumindo uma adesao (previsao pessimista) de
1 aos servicos offline assistir-se-ia a cerca de 840 pedidos adicionais por minuto
Mas o principal problema desta aproximacao prende-se com o facto de a ver-
ificacao ser feita em intervalos de tempo discretos levando a possibilidade de a
aplicacao poder ter em dado momento uma representacao errada do seu estado
real da ligacao Este problema e ilustrado na Figura 48 onde se ve claramente a
discrepancia entre o estado real da ligacao e a representacao interna que esta tem
Note-se que nesta janela de tempo qualquer accao do utilizador que exija uma
resposta sıncrona do utilizador leva-lo-a para um ldquobeco sem saıdardquo onde nao tera
43
Desenvolvimento
Figura 46 A pagina inicial do WOW apresenta um resumo das ultimas ordens de trabalhoenviadas e recebidas Na imagem pode-se observar a transicao do estado online para offline
acesso a versao offline porque a aplicacao nao fez a transicao automatica nem acesso
a versao online porque na verdade nao possui uma ligacao O que acontecera nesta
situacao sera uma tentativa de acesso ao servidor por parte da aplicacao numa
altura em que este se encontra indisponıvel e o resultado sera uma mensagem de
ldquopedido excedeu o tempordquo apresentado pelo browser Este e um estado sem retorno
porque apos o browser apresentar esta mensagem todos os recursos JavaScript ficam
indisponıveis tornando impossıvel o regresso ao estado anterior ou o tratamento do
erro de qualquer outra forma No entanto as chamadas Ajax podem ser tratadas de
forma especial para a eventualidade de falha e portanto nao constituem problema
44
Desenvolvimento
Figura 47 Ilustracao do funcionamento do Gears numa web application que utiliza ummotor Ajax Os pedidos HTTP ou HTTPS podem ser interceptados e tratados localmenteou podem ser feitos a uma maquina remota consoante se verificarem ou nao as condicoesexpressas no ponto 311 E representado um acesso a uma base de dados local (fornecidapelo Gears) mas a sua utilizacao e opcional
462 Implementacao do modo ldquoutilizador deciderdquo
Este modo de execucao foi ja descrito na seccao 421 e a sua principal carac-
terıstica e ser o utilizador a decidir se a aplicacao deve utilizar um servidor remoto
ou a maquina local como fornecedor de dados
Relativamente ao WOW o WOW Offline na vertente ldquoutilizador deciderdquo vem
alterar os seus casos de uso dando ao utilizador a possibilidade de alterar o estado
de execucao da aplicacao (entre online e offline) Resta dizer que no modo online se
mantem todas as funcionalidades anteriores e que no modo offline torna-se possıvel
visualizar os conteudos da pagina principal do WOW (Figura 46) e os detalhes das
ordens de trabalho (Figura 49) tal como expressa a Figura 410
Esta aproximacao foi utilizada na prova de conceito do WOW adicionando um
controlo a interface desta aplicacao que permite ao utilizador alternar entre os esta-
dos online e offline Na transicao de online para offline sao descarregados os recursos
necessarios para a execucao desta aplicacao sem recorrer a Internet Para o fazer
45
Desenvolvimento
Figura 48 Neste exemplo do modo ldquoaplicacao deciderdquo o teste da ligacao e feito e feito acada cinco segundos O resultado deste teste nao reflecte sempre o estado real da aplicacaopodendo levar a aplicacao a ter comportamentos indesejaveis Na figura assinala-se umperıodo de tempo no qual a representacao interna do estado da ligacao nao corresponde arealidade
e utilizado um recurso ResourceStore e um ManagedResourceStore (introduzidos
em 311) O primeiro e utilizado para armazenar a pagina principal do WOW ndash do-
ravante designada por homejsp ndash e o segundo e utilizado para armazenar imagens
folhas de estilo CSS e scripts JavaScript
Para a implementacao deste modo de execucao foram identificadas as seguintes
tarefas
1 Guardar informacao que permita a recriacao das paginas que se pretende
disponibilizar offline (utilizando o Gears)
2 Disponibilizar um controlo que permita alterar o estado de execucao atraves
da interaccao com a pagina principal
3 Durante a sincronizacao de dados apresentar o progresso da transferencia de
dados
O primeiro passo consistiu na identificacao de todos os conteudos que sao necessarios
transferir para a execucao offline Foi utilizado um recurso do Gears do tipo
ManagedResourceStore que recorre a um ficheiro manifesto para identificar to-
dos os ficheiros que deve transferir Este recurso e gerido automaticamente pelo
Gears transferindo para o cliente a versao mais recente sempre que e necessario
isto e sempre que exista um ficheiro manifesto com uma identificacao de versao que
seja diferente da actualmente disponıvel no cliente Uma vez identificados todos
ficheiros necessarios para a execucao offline num (ou mais) ficheiros manifesto o
Gears encarrega-se da sua actualizacao mas o preenchimento destes ficheiros man-
ifesto e manual o que se traduz num cuidado extra na manutencao da aplicacao
A forma como esta informacao e guardada deve tambem ser cuidadosamente
estudada A opcao mais flexıvel passa por utilizar o modulo Database apresentado
na seccao 311 e guardar a informacao de uma forma relacional Para a recriacao
das paginas pode ser disponibilizada uma versao HTML da pagina que funciona
46
Desenvolvimento
Figura 49 Pagina de visualizacao do detalhe de uma ordem de trabalho
como template nao possui quaisquer dados e e utilizada apenas em modo offline E
preenchida para cada pedido retirando os dados relevantes da base de dados
O modelo de dados do WOW torna esta opcao extremamente trabalhosa uma
vez que as entidades envolvidas na geracao de cada pagina de informacao sobre
cada ordem de trabalho tem relacoes de dependencia complexas seguindo padroes
muito variaveis Por exemplo em cada ordem de trabalho existe um formulario que
permite a sua progressao de estado com diversos campos opcionais e obrigatorios
este formulario e definido pelo administrador e esta relacionado nao apenas com o
tipo de ordem de trabalho mas tambem com o estado actual em que esta se encontra
e a accao que se pretende realizar O elevado numero de combinacoes de tipos de
ordem de trabalho estados e accoes que existem num dado momento juntamente
com a sua possibilidade de alteracao obrigariam a implementacao de uma logica de
negocio complexa o que esta fora do ambito deste projecto
47
Desenvolvimento
Figura 410 Esquema UML que expressa os casos de uso do WOW Offline no modoldquoutilizador deciderdquo
463 Especificacao do modo ldquoaplicacao assume o estado offlinerdquo
A aproximacao para o modo ldquoaplicacao assume o estado offlinerdquo foi tambem
dividida em varias tarefas
1 Guardar informacao que permita a recriacao da pagina principal do lado do
cliente no estado offline (utilizando o Gears)
2 Dotar a aplicacao do cliente de um mecanismo de deteccao da ligacao
3 Identificar os ldquomomentos chaverdquo em que devera ocorrer sincronizacao de dados
4 Implementar a sincronizacao de dados
A sincronizacao de dados deve ser feita em ambas as transicoes online-offline e
offline-online quer para transferir novos dados do servidor (os pedidos podem ser
alterados por outros utilizadores) quando se transita do estado quer para comunicar
eventuais alteracoes feitas em modo offline
Relativamente ao WOW o WOW Offline na vertente ldquoaplicacao assume o es-
tado offlinerdquo vem alterar os seus casos de uso dando ao utilizador a possibilidade
de activar esta funcionalidade A partir do momento que a funcionalidade esta ac-
tivada o utilizador deve tambem ter a possibilidade de gerir algumas preferencias
relacionadas com privacidade de dados Devera ter a hipotese de desactivar o ar-
mazenamento local e de remover todos os dados ja armazenados tal como descrito
na Figura 411
48
Desenvolvimento
Figura 411 Esquema UML que expressa os casos de uso do WOW Offline no modoldquoutilizador deciderdquo
A primeira vez que o WOW Offline e acedido por um cliente e caso seja detec-
tada a presenca do Gears todos os recursos necessarios a sua execucao sao trans-
feridos Todos os acessos posteriores serao feitos a estes recursos locais (recorda-se
que o Gears pode ser utilizado para os manter actualizados recorrendo ao Managed-
ResourceStore 311)
Atraves do JavaScript e possıvel interceptar os eventos de load e unload da
pagina que sao despoletados sempre que ocorre um re-acesso da mesma (incluindo
a accao refresh comum dos browsers) sempre que esta e abandonada ou ainda ou
ainda se a janela for encerrada
Tal como sugerido na seccao 462 a camada de interface desta aplicacao (cada
pagina individual em HTML) devera ser implementada como sendo um template
para apresentacao de dados sendo totalmente preenchida atraves de funcoes em
JavaScript O objectivo deste ponto e criar um padrao de dados que permita ao
JavaScript preencher os dados em cada pagina (template) independentemente de
qual seja a fonte ndash o servidor remoto ou a maquina local tal como exemplificado
no diagrama da Figura 412 Na figura a aplicacao recorre ao servidor remoto para
obter os dados pretendidos quando se encontra na presenca de uma ligacao mas
para dados que exijam uma carga de processamento pelo servidor este acto pode ser
49
Desenvolvimento
Figura 412 Esquema UML que expressa o acto de recolha de dados em modo online eoffline recorrendo ao servidor (modo online) e ao sistema de armazenamento de dadoslocal fornecido pelo Gears (modo offline)
substituıdo pelo envio de um campo de controlo que se destina a aferir se os dados
locais se encontram actualizados No caso de estarem actualizados a comunicacao
com o servidor pode ser substituıda por uma query a base de dados local
50
Capıtulo 5
Resultados e Futuros
Desenvolvimentos
Todo o estudo feito sobre o tema OWA foi ja abordado ao longo do documento
Neste capıtulo apresentam-se os resultados obtidos na implementacao da prova de
conceito que visava compreender a melhor forma de disponibilizar uma versao of-
fline no WOW uma plataforma de gestao de ordens de trabalho ja existente de-
senvolvida pela Critical Software SA
51 Resultados Obtidos
Os resultados obtidos neste projecto sao extremamente satisfatorios uma vez
que o estudo do tema OWA e a implementacao de uma prova de conceito que o
ilustrasse foi conseguido com sucesso
A funcionalidade offline foi adicionada ao produto WOW da Critical Software
SA permitindo a visualizacao de ordens de trabalho e dos seus detalhes mesmo na
ausencia de uma conexao activa a Internet Embora para a solucao implementada
tenha sido utilizada uma abordagem do tipo ldquoutilizador deciderdquo pretende-se que esta
seja convertida para ldquoaplicacao deciderdquo ou mesmo para uma aproximacao hıbrida
semelhante a utilizada pelas aplicacoes estudadas nas seccoes 351 e 352
Para a sua implementacao descrita no capıtulo 4 foram tomadas decisoes de or-
dem pratica que permitissem tornar o trabalho exequıvel nos prazos dados Tentou-
se sempre que estas decisoes afectassem o mınimo em termos de desempenho e de
experiencia para o utilizador Considera-se que a implementacao do modo offline
com uma transicao entre modos do tipo ldquoutilizador deciderdquo (ver seccao 42) reflecte
o compromisso entre o desempenho pretendido e os recursos disponıveis e para alem
51
Resultados e Futuros Desenvolvimentos
de ser um exemplo eficaz das possibilidades que as OWA podem trazer a aplicacao
WOW desenvolvida pela Critical Software e tambem um estudo que pode ser uti-
lizado para analisar a implementacao desta tecnologia noutros produtos da mesma
empresa
Note-se que o principal objectivo do trabalho era ganhar familiaridade com este
tema entender as suas vantagens e desvantagens e compreender as suas limitacoes
Tudo indica que existam varias possibilidades de implementacao deste paradigma
noutros produtos da Critical Software que pela sua natureza podem tambem tirar
partido da execucao offline
52 Trabalho Futuro
O desenvolvimento do conceito e formas de implementacao de OWA continua
em forte desenvolvimento no entanto a sua adopcao ainda nao e generalizada A
dificuldade da sua implementacao em web applications ja existentes e o principal
obstaculo a sua maior divulgacao
Ha tambem um factor que deve ser tido em consideracao a manutencao de
codigo A implementacao de uma versao offline de uma web application requer
a implementacao das mesmas regras de negocio (ou de uma versao simplificada)
utilizadas no servidor Para que isto seja possıvel e necessario ter em conta a
capacidade de processamento do cliente e o factor de duplicacao de codigo que
tornara a aplicacao mais difıcil de manter uma vez que uma alteracao a logica de
negocio do servidor implica tambem uma alteracao a sua versao offline
A prova de conceito implementada permite ja a visualizacao offline dos pedidos
abertos (enviados e recebidos) que constam na pagina principal (este numero e
fixo e pode ser alterado pelo administrador) Uma funcionalidade desejavel seria a
possibilidade de interaccao com a aplicacao em modo offline e sincronizacao com o
servidor quando existisse uma ligacao disponıvel
Foi estudada a utilizacao do modo de execucao ldquoaplicacao assume o estado of-
flinerdquo descrito em 423 e esta seria a forma desejavel para o WOW Offline no
entanto para que esta opcao seja viavel sera necessaria a implementacao de uma
forma eficiente de sincronizacao e armazenamento de dados de uma forma relacional
Para atingir este objectivo podera ser seguida uma polıtica de automacao do pro-
cesso no qual a versao online da aplicacao gera scripts de criacao para as tabelas
necessarias na base de dados da versao offline (nao existe nenhuma ferramenta para
o fazer portanto seria necessaria a sua implementacao) e no qual as paginas HTML
disponibilizadas pelo servidor aos clientes web (browser) servem como templates de
apresentacao de informacao e sao preenchidas de forma semelhante pelo servidor ndash
quando a aplicacao estiver online ndash ou pelo cliente atraves de funcoes em JavaScript
52
Resultados e Futuros Desenvolvimentos
ndash quando a aplicacao estiver offline No entanto no WOW devido a quantidade de
informacao tratada e devido as complexas relacoes entre as diferentes entidades e
de esperar que a complexidade da implementacao de um mecanismo deste tipo torne
esta aproximacao demasiado custosa
O HTML 5 embora um forte candidato ainda nao esta suficientemente desen-
volvido A sua especificacao ainda tem o caracter de Draft (rascunho) e esta sujeita
a modificacoes e a aceitacao e implementacao por parte dos browsers e portanto
de momento foi desconsiderado No entanto no futuro se esta especificacao atingir
um estado de maturidade que permita a sua adopcao devera ser considerada como
um possıvel caminho a seguir
53
Resultados e Futuros Desenvolvimentos
54
Capıtulo 6
Conclusoes
Neste capıtulo sao apresentadas as conclusoes do projecto e consideracoes finais
relativamente a tecnologia estudada
61 Conclusoes
O rapido desenvolvimento tecnologico faz prever que a disponibilidade de ligacao
a Internet seja cada vez mais facil e mais rapido mas vao continuar a existir lugares
onde o acesso e limitado e onde as OWA podem desempenhar um papel de relevo
Por outro lado esta tecnologia pode tambem ser utilizada para melhorar o desem-
penho de paginas web com uma necessidade elevada de imagens ou outros recursos
dispendiosos em termos de espaco e foram ate estudados dois exemplos da utilizacao
desta vertente desta tecnologia em 353
Acredita-se que as OWAs vem responder a uma necessidade real por parte das
web applications actuais e que a evolucao que representam se compara a que se
assistiu dos thin-clients para os fat-clients em termos de autonomia do servidor
A capacidade de oferecer conteudos dinamicos no browser independentemente da
existencia de uma ligacao reune as vantagens tıpicas das web applications como
ausencia de instalacao e actualizacoes instantaneas com as vantagens das aplicacoes
de desktop em capacidade de processamento e armazenamento de dados na maquina
local
As tecnologias disponıveis ate a data estudadas no ambito deste projecto que
permitem o desenvolvimento de OWAs e que apresentam maior maturidade sao o
Gears e o Adobe AIR Ambas se apresentam sobre a forma de plugins que necessitam
de uma instalacao extra para poderem ser utilizadas Apesar de esta instalacao ser
55
Conclusoes
apenas necessaria uma vez podera constituir um factor de desencorajamento a sua
adopcao
O HTML 5 uma especificacao abordada neste documento na seccao 34 podera
ser uma alternativa que oferece funcionalidades offline a uma web application sem a
necessidade de qualquer instalacao no entanto esta especificacao ainda nao foi aceite
pelos principais browsers ndash o documento que define o HTML 5 ainda tem o estatuto
de Draft ndash e ainda nao e possıvel antecipar quando e que isto podera acontecer
Um dos problemas que surge frequentemente na implementacao de uma versao
offline para uma web application e a necessidade de sincronizacao de dados Quando
a informacao pode ser alterada por varios utilizadores simultaneamente e necessario
prever os conflitos que daı podem surgir e dotar a aplicacao de uma forma de os
resolver ou alertar o utilizador para a necessidade de alteracao dos dados
Em conclusao todos os objectivos propostos para este projecto foram atingidos
A prova de conceito implementada reflecte de forma clara as possibilidades oferecidas
pela tecnologia OWA e sera utilizado no futuro para compreender a melhor forma
de o implementar de forma definitiva no WOW
56
Referencias
[Ada08] Lucas Adamski Introducing Adobe AIR security model Fevereiro de2008 Disponıvel em httpwwwadobecomdevnetairarticles
introduction_to_air_securityhtml acedido em Marco de 2008
[Ado08] Adobe Adobe AIR 10 Security White Paper 2008 Disponıvel emhttpdownloadmacromediacompubairdocumentation1air_
securitypdf acedido em Marco de 2008
[Alm08] Dion Almaer Gears as a bleeding-edge html 5 implementa-tion March 2008 Disponıvel em httpalmaercomblog
gears-as-a-bleeding-edge-html-5-implementation acedido emMarco de 2008
[BL96] Tim Berners-Lee The world wide web Past present and future Agostode 1996 Disponıvel em httpwwww3orgPeopleBerners-Lee
1996ppfhtml acedido em Abril de 2008
[CDGH08] Mike Chambers Daniel Dura Dragos Georgita and Kevin Hoyt AdobeAIR for JavaScript Developers OrsquoReilly Media 2008 Disponıvel emhttponairadobecomfilesAIRforJSDevPocketGuidepdf ace-dido em Abril de 2008
[Con99] Jim Conallen Modeling Web Application Architectures with UML Junho1999 Disponıvel em httpwwwumlorgcnUMLApplicationpdf
webappspdf acedido em Maio de 2008
[Ent07] Entrust What is a public key information 2007 Disponıvel em http
wwwentrustcompkihtm acedido em Junho de 2008
[Gar05] Jesse James Garret Ajax A new approach to web applicationsFebruary 2005 Disponıvel em httpwwwadaptivepathcomideas
essaysarchives000385php acedido em Marco de 2008
[Greon] Philip Greenspun Philip and Alexrsquos Guide to Web Publishing 2003(last revision) Disponıvel em httpphilipgreenspuncompandaacedido em Junho de 2008
[Gro02a] App Design Group Thick vs thin client comparison 2002 Disponıvelem httpwwwdonjacobsvwcomimagesweekendspecials
Thick-vs-Thinpdf acedido em Junho de 2008
57
REFERENCIAS
[Gro02b] Technical Research Group Thin Client Tecnhology - WhitePaper 2002 Disponıvel em httpwwwpicktrgcompubs
thinclientwhitepaperpdf acedido em Junho de 2008
[Gro08] Miniwatts Marketing Group World internet usage March 2008Disponıvel em httpwwwinternetworldstatscomstatshtm ace-dido em Abril de 2008
[Hic08] Ian Hickson HTML 5 Draft Recommendation 2008 Disponıvelem httpwwwwhatwgorgspecsweb-appscurrent-work ace-dido em Marco de 2008
[Kha] Olga Kharif Top 10 municipal wifi plans Disponıvel em http
imagesbusinessweekcomss0608muni_wifiindex_01htm ace-dido em Marco de 2008
[Lab07] Mozilla Labs Prism Outubro 2007 Disponıvel em httplabs
mozillacom200710prism acedido em Marco de 2008
[Loo06] Chris Loosley Rich Internet ApplicationsDesign MeasurementandManagement Challenges 2006 Disponıvel em httpwwwkeynote
comdocswhitepapersRichInternet_5pdf acedido em Maio de2008
[Mic08] Microsoft Introduction to Occasionally Connected Applications us-ing Sync Services for ADONET 2008 Disponıvel em httpmsdn
microsoftcomen-ussyncbb887608aspx acedido em Junho de2008
[Nao08] Erica Naone Offline web applications Abril 2008 Disponıvelem httpwwwtechnologyreviewcomread_articleaspxch=
specialsectionsampsc=emerging08ampid=20245 acedido emAbril de 2008
[NJN00] Jason Nieh Yang S Jae and Naomi Novik A comparison of thin-clientcomputing architectures 2000 Disponıvel em httpwwwnclcs
columbiaedupublicationscucs-022-00pdf acedido em Maio de2008
[OrsquoR06] Tim OrsquoReilly Web 20 compact definition Trying again Dezembro2006 Disponıvel em httpradaroreillycomarchives200612
web-20-compact-definition-tryihtml acedido em Marco de 2008
[OrsquoR09] Tim OrsquoReilly What is Web 20 Design patterns and business modelsfor the Next Generation of Software 20053009 Disponıvel emhttpwwworeillynetcompubaoreillytimnews200509
30what-is-web-20html acedido em Marco de 2008
[Rus06] Alex Russel Comet Low latency data for the browser March Marco2006 Disponıvel em httpalexdojotoolkitorgp=545 acedidoem Marco de 2008
58
REFERENCIAS
[Sad97] Darleen Sadoski Clientserver software architecturesndashan overviewAgosto 1997 Disponıvel em httpwwwseicmuedustr
descriptionsclientserver_bodyhtml acedido em Junho de2008
[Sch96] George Schussel Clientserver past present and future 1996
[Smi07] Kevin C Smith Css filters - will the browser apply the rule July 2007Disponıvel em httpcentriclecomrefcssfilters acedido emMarco de 2008
[vK08] Anne van Kesteren The XMLHttpRequest Object W3C Work-ing Draft 15 Abril 2008 Disponıvel em httpwwww3orgTR
XMLHttpRequest acedido em Abril de 2008
[Wil06] Greg Wilkins Why ajax comet July Julho 2006 Disponıvel emhttpwwwwebtidecomdownloadswhitePaperWhyAjaxhtml ace-dido em Abril de 2008
59
REFERENCIAS
60
Anexo A
Screenshots
Algumas imagens de aplicacoes que utilizam funcionalidades offline ilustrativasda tecnologia abordada neste documento
Figura A1 Dialogo apresentado ao utilizador na primeira activacao das funcionalidadesoffline no Google Docs amp Spreadsheets
61
Screenshots
Figura A2 Na activacao das funcionalidades offline e tambem oferecida a possibilidadeda criacao de alguns atalhos por exemplo no ambiente de trabalho
Figura A3 O Google Docs mantem a todo o momento a possibilidade de alteracao destasdefinicoes ou da anulacao dos servicos offline para um dado computador
62
Screenshots
Figura A4 Apos a instalacao do Gears qualquer visita ao Remember The Milk despoletauma sincronizacao que ocorre automaticamente e sem necessidade de intervencao por partedo utilizador
Figura A5 Apos completar a sincronizacao de dados mesmo que a ligacao a Internetseja perdida o Remember the Milk continua disponıvel no browser (com excepcao dasfuncionalidades que pela sua natureza exigem uma ligacao como por exemplo partilhade tarefas e envio de convites)
63
Lista de Tabelas
21 Comparacao entre thin-clients e fat-clients 7
31 Comparacao das funcionalidades oferecidas pelo Adobe AIR para asplataformas web e desktop 30
32 Resumo da utilizacao de tecnologias OWA em algumas web applica-tions consideradas na analise do estado da arte 31
xi
LISTA DE TABELAS
xii
Glossario
fat-client Cliente que nao depende totalmente de umservidor central para as suas actividadesde processamento e possui frequentementedispositivos de armazenamento de dados
6ndash8
thin-client Cliente que depende de um servidor centralpara as suas actividades de processamento
5ndash8
web application Sistema web (servidor rede HTTPbrowser) onde accoes do utilizador(navegacao e introducao de informacao)afectam o estado logico da aplicacao
i iii1ndash311ndash1517ndash1921ndash232728 3336ndash3842 5556
API Application Programming Interface 10 1718 2326 28
ASP Linguagem interpretada pelo servidorque permite a criacao de paginas webdinamicas Desenvolvida pela Microsoft
11
BSD Berkeley Software Distribution 28
CSS Cascading Style Sheets 12 2021 2324 46
DHTML Dynamic HyperText Transfer Protocol 24DOM Document Object Model 10 12
20 2324
DTD Document Type Definition 24
xiii
Glossario
ECMAScript Padrao de linguagem de programacaodefinido pela Ecma International que orig-inou o JavaScript e o JScript
24
Flash Conteudo interactivo de um ficheiro emformato SWF E desenvolvido pela Adobee visualizado atraves do Adobe FlashPlayer
21
Flex Framework baseada em XML e Action-Script desenvolvida pela Adobe para a pro-gramacao de Rich Internet Applications(RIA)
21
GPL GNU General Public License 23
HTML HyperText Markup Language 1 10ndash12 2124ndash2649
HTTP HyperText Transfer Protocol 2 26
JMS E uma API em Java que permite a troca demensagens entre componentes de software
42
JSON JavaScript Object Notation permite atroca de dados codificados num formatode texto de simples leitura
12 1828 34
LGPL GNU Lesser General Public License 23
Mozilla Prism Browser simplificado e ldquointerpretadorrdquo deeXtensible User Interface Language (XUL)(tambem designado por XULRunner) queacolhe web applications sem a interfacegrafica habitual de um browser
25
MPL Mozilla Public License 23
OCA Occasionally Connected Application 39OWA Offline Web Application i iii
2ndash515 1725 2628 3133 3651 5255 56
PDF Portable Document Format 21
xiv
Glossario
PHP Linguagem interpretada pelo servidorque permite a criacao de paginas webdinamicas mas que pode tambem ser in-vocada a partir da linha de comandos
11
pagina web estatica Pagina web que devolve sempre a mesmaresposta a todos os pedidos para todos osutilizadores e em qualquer contexto
5 9
RIA Rich Internet Applications web appli-cations que apresentam funcionalidadessemelhantes as desktop applications masque mantem a informacao no lado do servi-dor
5 1520 28
RSS Really Simple Syndication 27
SLA Service Level Agreement 40SQLite Segundo a definicao oficial SQLite is a
software library that implements a self-contained serverless zero-configurationtransactional SQL database engine
17
SSB Site Specific Browser 25SSL Secure Sockets Layer 22SWF ShockWave Flash 21
URL Uniform Resource Locator 18
VPN Virtual Private Network 38
WOW Work Orders Web Plataforma de gestaode ordens de trabalho e do seu fluxo de-senvolvida pela Critical Software SA
i iii28 3340ndash434551ndash5356
WWW World Wide Web 11 1214
XBL eXtensible Binding Language 24XHTML eXtensible HyperText Markup Language 12XML eXtensible Markup Language 11 12
23 2428
XSLT eXtensible Stylesheet Language Transfor-mation
12
XUL eXtensible User Interface Language xiv23ndash25
xv
Glossario
xvi
Capıtulo 1
Introducao
Neste capıtulo enquadra-se o tema do projecto introduzindo alguns dos conceitos
nos quais se baseia Apresentam-se as motivacoes ambito objectivos e a estrutura
deste documento
11 Enquadramento
A Internet foi originalmente concebida para ser um espaco de partilha de in-
formacao onde pessoas (atraves de maquinas) pudessem comunicar Na sua origem
as paginas eram estaticas constituıdas por texto formatado em HyperText Markup
Language (HTML) e ligadas entre si [BL96] Hoje encontramos conteudos cada vez
mais complexos e dinamicos incluindo som vıdeo ou streams multimedia [Loo06] e
em 2005 foi introduzido por [OrsquoR09] o termo Web 20
De acordo com [Greon] um website pode pertencer a uma ou varias das seguintes
categorias
bull Documento ndash um website essencialmente estatico onde alteracoes a uma
parte do conteudo nao tem implicacoes no seu comportamento
bull Base de dados ndash um directorio de informacao organizada em categorias
bull Aplicacao ndash um website dinamico que utiliza uma linguagem executada ou
interpretada do lado do servidor e que processa as accoes ou informacao in-
troduzida pelo utilizador para fornecer um servico ou nova informacao
A ultima destas categorias constitui aquilo que e normalmente designado por
web application O conceito utilizado ao longo deste documento e o mesmo que
o introduzido por Jim Coallen em [Con99] que define web application como um
1
Introducao
sistema web (servidor rede HyperText Transfer Protocol (HTTP) browser) onde
accoes do utilizador (navegacao e introducao de informacao) afectam o estado logico
da aplicacao A sua definicao tenta estabelecer que uma web application e um
sistema de software com estado de negocio1 e que a sua interface de interaccao com
o utilizador e distribuıdo atraves de um sistema web
12 Motivacao
A quantidade de informacao que e produzida e armazenada com recurso a es-
tas web applications disponıveis online tais como e-mail blogues ou mesmo docu-
mentacao tornam por vezes a disponibilidade de ligacao uma condicao necessaria
a produtividade e como consequencia desta barreira muitos potenciais utilizadores
opoem-se a adopcao de produtos web em detrimento das tradicionais desktop appli-
cations
Assegurar o acesso a uma ligacao de Internet e hoje muito mais facil A Internet
movel e ja uma realidade e encontra-se amplamente divulgada mas continuam a
existir diversas situacoes nas quais os utilizadores estao privados de uma ligacao
a Internet tais como uma viagem de metro ou de aviao ou quando se encontram
deslocados do seu paıs de origem e nao possuem nenhum plano de subscricao
Uma OWA consiste numa web application que para alem de manter todas as
caracterısticas anteriores se mantem disponıvel mesmo na ausencia de uma ligacao
a Internet e surge como uma tentativa de estreitar as barreiras existentes entre a
web e o desktop Isto significa que devera existir um mecanismo capaz de assegurar
a manutencao do estado logico da aplicacao quando a ligacao com o servidor e
quebrada permitindo ao utilizador continuar a utilizar a aplicacao e que sera capaz
de informar o servidor do estado em que a aplicacao se encontra quando a ligacao for
reposta A principal vantagem que advem desta possibilidade e evidente eliminar
a necessidade da existencia de uma ligacao a Internet para que a aplicacao possa ser
utilizada
Por outro lado a vontade de integracao de funcionalidades tıpicas das desktop
applications nas web applications foi um dos principais factores que impulsionou o
desenvolvimento deste conceito uma vez que obrigou a uma reflexao ldquopara alem
do browserrdquo e a uma adaptacao das arquitecturas existentes que permitisse ou o
acesso a funcionalidades disponibilizadas pelo sistema operativo ou pelo menos a
funcionalidades semelhantes Pretende-se com esta aproximacao tornar possıveis
interaccoes entre o desktop e o browser tais como arrastar um ficheiro para um
formulario web de upload de conteudos melhor suporte para o historico do clipboard
ou ainda o acesso ao sistema de ficheiros local Atingir estes objectivos reflecte-se
1NT business state
2
Introducao
num novo paradigma que reune as vantagens das web applications tais como os
updates instantaneos ou o facto de nao ser necessaria nenhuma instalacao e das
desktop applications como por exemplo persistencia no armazenamento de dados
acesso a funcionalidades do sistema operativo ou integracao e interaccao com outras
aplicacoes sejam elas web applications ou desktop applications
13 Ambito
Este projecto foi realizado na Critical Software SA no ambito do Mestrado
Integrado em Engenharia Informatica e Computacao (MIEIC) da Faculdade de En-
genharia da Universidade do Porto (FEUP) entre os meses de Fevereiro e Julho de
2008
14 Objectivos
Sao objectivos deste projecto
1 Estudar e documentar o tema das OWAs acompanhando os ultimos desenvolvi-
mentos nesta materia
2 Analisar o estado da arte fazendo uma analise crıtica e objectiva sobre as
diversas metodologias existentes
3 Implementar uma prova de conceito que permita a execucao offline de uma
web application documentando todo o processo
4 Estudar a possibilidade de permitir interaccao com a aplicacao (insercoes e
alteracoes aos dados) em modo offline
Em resumo o objectivo deste projecto foi estudar documentar e implementar
uma prova de conceito relacionada com o tema Offline Web Applications (OWA)
Este tema embora nao seja totalmente novo ganhou destaque ao longo do ano de
2007 com o surgimento de diversas ferramentas que se destinam a aproximar web
applications das desktop applications
15 Estrutura do documento
Este documento esta organizado em diferentes seccoes apresentando o projecto
numa sequencia logica organizada da seguinte forma
No capıtulo 1 faz-se uma breve apresentacao do conceito OWAs e do contexto em
que surge Apresenta-se tambem a estrutura do documento e definem-se os
termos e acronimos utilizados
3
Introducao
No capıtulo 2 faz-se uma descricao da evolucao das tecnologias que antecedem as
OWAs e das vantagens e desvantagens de cada uma como forma de enquadra-
mento
No capıtulo 3 analisa-se o estado da arte nesta materia Introduzem-se diversas
tecnologias directamente relacionadas com o tema deste projecto exemplos de
aplicacoes que as usam e as razoes que fundamentam as escolhas de tecnologias
efectuadas
O capıtulo 4 contem o desenvolvimento do projecto Analisa-se a plataforma
WOW de gestao integrada de ordens de trabalho a tecnologia escolhida e
a forma como foi utilizada para implementar a capacidade de execucao offline
O capıtulo 5 descreve os resultado obtidos comparando-os com as expectativas
iniciais do projecto e apresenta desenvolvimentos futuros e possibilidades de
continuacaoaplicacao do conhecimento adquirido
No capıtulo 6 apresentam-se as conclusoes
4
Capıtulo 2
Enquadramento do Projecto
Neste capıtulo apresenta-se um breve resumo da evolucao das arquitecturas de
software cliente-servidor e a forma como estas se comparam a evolucao da Inter-
net procurando estabelecer uma analogia entre o percurso de ambas as tecnolo-
gias Compara-se o comportamento e arquitectura dos thin-clients as paginas web
estaticas a evolucao dos fat-clients as paginas interactivas Web 20 e Ajax e
defende-se que as OWA constituem um proximo passo logico e evolutivo aproxi-
mando a web do desktop Referem-se ainda os principais factores que justificam a
importancia das OWAs e a estreita relacao que tem com as Rich Internet Application
(RIA)s
21 Evolucao das arquitecturas de software
Os termos thin-client e fat-client sao utilizados quer para descrever arquitecturas
logicas (de software) quer para descrever arquitecturas fısicas (de hardware) Neste
capıtulo excepto quando seja dada indicacao em contrario estes termos referem-se
sempre a uma arquitectura logica
Adicionalmente quando se trata de arquitecturas cliente-servidor pode-se estu-
dar a arquitectura desenvolvida do sistema como um todo da arquitectura do servi-
dor ou da arquitectura do cliente Para evitar equıvocos em especial na seccao 213
especifica-se em cada caso qual o sistema estudado
211 Thin-clients
Um thin-client e um computador cliente ou software cliente que no contexto
de uma arquitectura cliente-servidor depende de um servidor central para as suas
5
Enquadramento do Projecto
actividades de processamento e proporciona um canal de entrada e saıda de in-
formacao entre o utilizador e o servidor remoto Este termo quando aplicado a
hardware refere-se habitualmente a um computador que se destina a ser utilizado
como cliente de rede sem armazenamento local e com capacidade de processamento
reduzida [Gro02b] mas o conceito que aqui se analisa refere-se a uma arquitectura
de software que remonta ao inıcio das aplicacoes cliente-servidor
No inıcio da historia da computacao terminais ligavam-se directamente a main-
frames responsaveis por todo o processamento Nesta arquitectura era necessario
desenvolver duas aplicacoes distintas uma aplicacao central no servidor (main-
frame) responsavel pela gestao de toda a informacao e por todas as operacoes de
comunicacao e uma aplicacao de visualizacao instalada no cliente (terminal) O
papel destes terminais era apenas disponibilizar ao utilizador um meio de comu-
nicacao (entrada e saıda) e apresentacao dos resultados do servidor Nao tinham
um papel activo no calculo nem na logica de negocio e frequentemente nao tinham
tambem nenhum mecanismo de armazenamento de dados
Como vantagens esta arquitectura apresenta uma reduzida necessidade de con-
figuracao e manutencao do lado do cliente Uma vez que o centro do processamento
e manipulacao de dados ocorre no servidor existe tambem uma centralizacao da
informacao [NJN00] que introduz um ponto crıtico de falha1 Actualizacoes e novas
funcionalidades sao faceis de distribuir uma vez que requerem apenas alteracoes no
servidor [Gro02a]
212 Fat-clients
Contrastando com os thin-clients nesta arquitectura os clientes implementam
ja uma parte da logica de negocio e sao responsaveis pelo processamento de dados
Estes fat-clients vieram responder a necessidade crescente de aplicacoes com um
nıvel de interactividade e capacidade de configuracao maior que as oferecidas pela
arquitectura thin-client descrita na seccao 211 Apesar de manterem a sua de-
pendencia do servidor podem tambem ser executados sem uma conexao activa uma
vez que dispoe de armazenamento de dados local o que lhes confere a capacidade
de persistencia de dados e do estado de execucao entre cada sessao
Foi disponibilizando este controlo sobre o estado da aplicacao bem como acesso
a recursos locais (por exemplo sistema de ficheiros e perifericos) que surgiram as
primeiras verdadeiras desktop applications No entanto cada cliente tinha que ser
separadamente instalado no computador pessoal de cada utilizador que pretendesse
utilizar ou interagir com a aplicacao e uma actualizacao ao servidor implicava in-
variavelmente uma actualizacao manual tambem no cliente Uma vez que nem todos
1NT single point of failure
6
Enquadramento do Projecto
Thin-clients Fat-clientsNao toma parte no processamento dedados nem possui acesso ao sistema deficheiros
Participa activamente no processa-mento de dados recorrendo ao sis-tema de armazenamento local para ar-mazenamento de dados
Nao mantem registo do estado logicoda aplicacao entre duas sessoes de uti-lizacao
O acesso ao armazenamento localpermite-lhe manter registo do estadologico da aplicacao entre duas sessoes
O thin-client nao necessita de qualquerinstalacao estando ldquopronto a utilizarrdquo
E geralmente necessario instalar aaplicacao para poder interagir com oservidor
Qualquer update no servidor reflecte-seimediatamente por todos os clientes
Embora a aplicacao cliente possa aler-tar para existencia de novas versoes asactualizacoes tem que ser manualmenteinstalados pelo cliente
O software do cliente destina-se apenasa apresentacao de dados e comunicacaocom o servidor sendo portanto de sim-ples implementacao
Como o software do cliente toma parteactiva no processamento de dadosa sua implementacao requer cuidadosadicionais
Grande mobilidade uma vez que todaa informacao e mantida no servidor
Parte da informacao podera estar ape-nas do lado cliente pelo que existemalgumas restricoes a sua mobilidade
Tabela 21 Comparacao entre thin-clients e fat-clients
os utilizadores actualizam regularmente as suas aplicacoes o servidor tem que estar
preparado para lidar com versoes antigas2 ou descontinuar os seus servicos a uma
parte da sua comunidade de utilizadores ate que estes actualizem os seus sistemas
Como os utilizadores passam a utilizar os seus recursos locais para armazenamento
de dados as alteracoes que nao sejam sincronizadas com o servidor estao apenas
disponıveis nos seus computadores pessoais o que introduz uma restricao a mobili-
dade
Pode-se afirmar que as vantagens dos thin-clients sao as desvantagens dos fat-
clients e que as vantagens dos fat-clients sao as vantagens dos thin-clients tal como
se ilustra na Tabela 21
213 Arquitecturas cliente-servidor
Introduzidos os termos thin-client e fat-client interessa reafirmar que ambos
podem ser vistos como arquitecturas cliente-servidor Um cliente define-se como
um solicitador de servicos e um servidor como um prestador de servicos tal como
definido por [Sch96] e [Sad97]
2NT backward compatibility
7
Enquadramento do Projecto
As arquitecturas cliente-servidor sao categorizadas pela modularizacao com que
sao desenhadas sendo consideradas as seguintes camadas
1 Interface grafica (front-end) atraves da qual os utilizadores interagem com
a aplicacao Quando este modulo e implementado separadamente dos outros
dois constitui uma aplicacao thin-client por si so uma vez que nao implementa
regras de negocio (embora possa definir validacoes de formularios de insercao de
dados por exemplo) A informacao introduzida pelo utilizador e enviada para
o servidor que processa o seu pedido e retorna uma resposta Este processo
repete-se ate que o utilizador atinja o seu objectivo ou se desligue do sistema
2 A logica de negocio tambem designada por camada intermedia que imple-
menta as regras de aceitacao e validacao de todos os dados introduzidos pelo
utilizador E tambem a plataforma de comunicacao que une a camada superior
de visualizacao com a camada de acesso a dados
3 A camada de dados inclui quer o sistema de persistencia de dados onde sao
armazenados os dados relevantes como tambem os mecanismos necessarios
para a sua pesquisa seleccao e alteracao
Os thin-clients quando observados no seu conjunto de cliente e servidor podem
ser vistos quer como sistemas de duas camadas quer como sistemas de tres camadas
dependendo apenas da forma como o servidor for implementado No caso de na
implementacao do servidor nao se distinguir a camada de acesso a dados da camada
da logica de negocio sao designados por sistemas de duas camadas Caso seja feita
esta distincao sao designados por sistemas de tres camadas Ambos os casos sao
ilustrados na Figura 21
Historicamente os fat-clients eram implementados numa arquitectura em duas
camadas Possuıam apenas um modulo de visualizacao de dados designado por
camada de interface e um modulo que implementava toda a logica de negocio e
regras de acesso a base de dados No entanto com a introducao de ligacoes mais
rapidas e de computadores pessoais com maior capacidade de processamento e so-
bretudo devido a complexidade crescente das aplicacoes a logica de negocio e a
camada de acesso a dados tornaram-se independentes Este modelo e designado por
arquitectura em tres camadas e e ilustrado na Figura 22
22 Evolucao na Internet
Ao analisar a evolucao das arquitecturas das aplicacoes desenvolvidas para a
Internet podemos encontrar um paralelismo com a historia da arquitectura de soft-
ware
8
Enquadramento do Projecto
Figura 21 Arquitectura de um sistema thin-client em duas camadas (a esquerda) e emtres camadas (a direita) Note-se a inclusao do servidor (mainframe) na definicao dascamadas desta arquitectura devido a forte dependencia cliente-servidor
221 Paginas web estaticas
Uma pagina web estatica devolve sempre a mesma resposta a todos os pedidos
para todos os utilizadores e em qualquer contexto utilizando o hipertexto como
forma de ligacao entre diversas paginas estaticas
A informacao e armazenada num servidor e o papel do cliente e apenas a apre-
sentacao da informacao Esta forma de disponibilizacao de informacao pode assim
ser comparada com os thin-clients descritos na seccao 211 o utilizador acede a
um website estatico para visualizar informacao sem que o cliente tome parte no
processamento A unica diferenca e que no caso da web estatica a informacao ap-
resentada e sempre a mesma enquanto que nos thin-clients era frequente existir a
possibilidade de insercao de dados no cliente e apos o seu processamento servidor
nova informacao poderia ser apresentada O hipertexto e utilizado para ligar as
paginas entre si numa rede de conteudos relacionados e a navegacao sıncrona era
feita atraves de cliques do rato a cada clique uma nova pagina era apresentada
Este modelo sıncrono e ilustrado na Figura 23
222 Paginas web interactivas e paginas web dinamicas
O JavaScript e uma linguagem interpretada de scripting que tem os browsers
como principal ambiente de acolhimento Os browsers utilizam uma Application
9
Enquadramento do Projecto
Figura 22 Arquitectura de um fat-client em duas camadas (a esquerda) e em tres camadas(a direita)
Programming Interface (API) publica para criar ldquoobjectosrdquo responsaveis por reflectir
e disponibilizar o Document Object Model (DOM) para o motor de JavaScript
A utilizacao mais frequente desta linguagem e a escrita de funcoes que sao em-
bebidas ou incluıdas em paginas web e que interagem com o DOM Uma vez que o
JavaScript e executado localmente (na maquina do cliente e nao no servidor) e capaz
de responder rapidamente a accoes do utilizador tornando a execucao de aplicacoes
no browser mais fluıdas o JavaScript pode tambem detectar accoes do utilizador
que o HTML nao pode tal como o pressionar de uma tecla
Em Dezembro de 1995 a Netscape Communications adicionou suporte para o
JavaScript no browser Netscape Navigator3 e em Agosto de 1996 o browser Internet
Explorer4 da Microsoft passou a tambem a suportar uma versao semelhante desta
linguagem (hoje todos os principais browsers suportam esta tecnologia)
Esta inovacao permitiu tornar os websites mais interactivos mas a sua utilizacao
esteve confinada apenas a este proposito durante um longo perıodo As paginas
passaram a responder activamente a accoes do utilizador (sendo uma das utilizacoes
3Netscape Communications ndash httpbrowsernetscapecom4Microsoft Internet Explorer ndash httpwwwmicrosoftcomwindowsproductswinfamilyie
10
Enquadramento do Projecto
mais vulgares a validacao de formularios) mas continuaram essencialmente estaticas
O JavaScript ainda nao era nesta altura utilizado para processar dados
Tambem nesta altura (1995ndash96) surgiram linguagens server-side como o PHP
Hypertext Preprocessor (PHP) e Active Server Pages (ASP) e o servidor passou a ter
um processamento de dados introduzidos pelo utilizador mais activo Generalizaram-
se as paginas dinamicas capazes de responder a insercao de dados ou outros pedidos
determinados por accoes do utilizador As paginas tornaram-se aplicacoes web ap-
plications
Uma definicao tradicional de web application e um conjunto de paginas web
logicamente agrupadas e geridas por uma unica entidade que tem como pontos de
entrada formularios de insercao de dados (web forms) Uma web application nao e
mais do que uma aplicacao que e acedida atraves de um browser Tem geralmente
uma arquitectura logica em tres (interface logica de negocio e camada de dados)
camadas e estao armazenadas num servidor
Ha dois tipos de web applications
bull Orientadas a apresentacao Sao web applications que geram paginas web in-
teractivas constituıdas por varios tipos de linguagens de anotacao (por exem-
plo HTML eXtensible Markup Language (XML)) e que apresentam conteudo
dinamico como resposta a pedidos efectuados pelo utilizador
bull Orientadas aos servicos Uma web application orientada aos servicos imple-
menta o ponto de acesso para um ou mais de um web service Sao geralmente
clientes de service oriented web applications
Uma vantagem significativa de implementar uma web application de forma a
suportar as funcionalidades padrao dos browsers e que estas terao o mesmo com-
portamento independentemente da plataforma e do browser a partir do qual serao
acedidas No entanto diferentes implementacoes de browsers devido a diferentes
interpretacoes dos padroes definidos tornam por vezes esta tarefa um pouco mais
complicada existindo inclusivamente na web guioes de compatibilidade para os difer-
entes browsers como [Smi07]
223 Web 20 e Ajax
O termo web 20 descreve uma tendencia de utilizacao e de design observada
na World Wide Web (WWW) com o objectivo de melhorar a criatividade partilha
de informacao e principalmente a colaboracao entre utilizadores Estes conceitos
levaram ao desenvolvimento e evolucao de comunidades online tais como redes so-
ciais wikis e blogues
11
Enquadramento do Projecto
O termo tornou-se mais conhecido apos a primeira conferencia OrsquoReilly Media
Web 20 em 2004 e apesar de sugerir uma nova versao da WWW nao se refere a
qualquer evolucao tecnologica mas apenas a alteracoes a forma como os utilizadores
se servem da web De acordo com Tim OrsquoReilly [OrsquoR06] ldquoWeb 20 e uma revolucao
na industria do software causada pela adopcao da web como uma plataforma e pela
tentativa de entendimento das regras para o sucesso nesta nova plataformardquo
O desenvolvimento da Web 20 serve-se muitas vezes de um outro conceito Ajax
O conceito que hoje conhecemos como Ajax muitas vezes incorrectamente de-
scrito como uma tecnologia foi originalmente criado para permitir o desenvolvimento
de web applications que se assemelhassem ainda mais a aplicacoes de desktop Este
conceito foi melhor descrito por [Gar05] como um conjunto de varias tecnologias
que podem ser utilizadas para melhorar a experiencia do utilizador de uma dada
web application introduzindo a capacidade assıncrona de envio de pedidos ou da
recepcao assıncrona de respostas As tecnologias mais frequentemente envolvidas
sao
bull eXtensible HyperText Markup Language (XHTML) e Cascading Style Sheets
(CSS) padrao para a apresentacao
bull interaccao dinamica atraves do DOM
bull troca e manipulacao de dados utilizando XML e eXtensible Stylesheet Lan-
guage Transformation (XSLT) ou JavaScript Object Notation (JSON)
bull pedidos assıncronos utilizando XMLHttpRequest [vK08]
bull JavaScript utilizado para integrar todas estas tecnologias
E importante frisar que o Ajax nao e um produto nem uma tecnologia E um
termo que descreve a utilizacao de um conjunto de tecnologias para o desenvolvi-
mento de web applications com um elevado grau de interactividade Comparativa-
mente as web applications tradicionais o Ajax introduz uma camada de visualizacao
diferente em tres importantes pontos
1 Do lado do cliente existe um motor que serve de intermediario entre a interface
da aplicacao e o servidor
2 A actividade do utilizador despoleta chamadas JavaScript em vez de um pedido
de pagina directamente ao servidor
3 Informacao codificada em XML em vez de paginas HTML e trocada entre o
servidor e o cliente
12
Enquadramento do Projecto
Isto significa que as paginas que utilizam Ajax contem um motor do lado do
cliente composto por um conjunto de funcoes JavaScript responsavel pela comu-
nicacao com o servidor e por actualizar a interface com o resultado dessa mesma
comunicacao
Na Figura 23 ilustra-se a natureza assıncrona do Ajax quando comparada com
as web applications tradicionais Como se pode observar adicionando um mecan-
ismo Ajax a uma web application eliminam-se diversos tempos de espera associados
a comunicacoes com o servidor uma vez que a interface nao fica ldquobloqueadardquo a es-
pera da resposta Obtem-se assim aplicacoes com um comportamento mais fluido
eliminando tempos de espera entre cada ldquocliquerdquo e melhorando a experiencia do
utilizador
23 Offline Web Applications
A informacao grafica (bem como folhas de estilo e scripts) tais como as ima-
gens que constituem o visual de uma web application e ja tratada de forma especial
pelos cada vez mais avancados sistemas de cache (armazenamento temporario) dos
browsers Mas estes nao sao ainda capazes de guardar conteudo criado pelo uti-
lizador nem de apresentar informacao independentemente do estado da ligacao
Numa altura onde se fala de servicos de Internet wireless municipalizados [Kha]
comunicacoes 3G e ligacoes de banda larga a alta velocidade a ligacao a rede global
continua a nao estar permanentemente disponıvel para os utilizadores Na WWW
encontra-se uma importante parte da informacao e das aplicacoes utilizadas para
criar e editar conteudos Por vezes informacao vital para a produtividade pode
desaparecer subitamente do mapa de acesso de um utilizador quando este entra no
metro num aviao ou mesmo quando se desloca para uma cidade ou paıs diferente
do habitual onde nao subscreve um plano de acesso que lhe garanta a ligacao
Permitir o acesso offline a estes recursos assume assim a sua importancia porque
permitira estender o alcance da informacao a locais onde nunca esteve antes e per-
mitira tambem melhorar o desempenho das web applications colocando informacao
mais perto dos utilizadores reduzindo a transferencia de dados apenas ao essencial
24 Comparacao
Nas evolucoes descritas neste capıtulo 2 pode-se observar que existe um par-
alelismo entre a evolucao das arquitecturas tradicionais cliente-servidor e a evolucao
a que se assiste na web O comportamento e arquitectura dos thin-clients assemelha-
se ao das paginas estaticas no sentido em que o browser nao toma parte em qualquer
13
Enquadramento do Projecto
processamento e serve apenas como uma plataforma de interaccao com o servidor
tal como os clientes descritos na seccao 211
A sua proxima evolucao os fat-clients trouxeram parte da capacidade de pro-
cessamento para o lado do cliente Na web foi tambem esta a inovacao tecnologica
a que se assistiu com a evolucao das tecnologias que permitiram a criacao de ver-
dadeiras aplicacoes e com a introducao do Javascript no browser dando ao cliente
a capacidade de processamento de dados A necessidade da separacao do codigo
em camadas logicas advem da crescente complexidade das web applications Esta
pratica permite entre outras coisas melhorar o processo de desenvolvimento e a
capacidade de manutencao de uma aplicacao
Os fat-clients tem tambem a capacidade de armazenamento de dados o que
permite a persistencia de informacoes entre duas sessoes e que algumas operacoes
sejam executadas sem a necessidade de comunicacao com o servidor Este facto pode
tambem ser uma realidade nas web applications com a adopcao das tecnologias OWA
Neste momento assiste-se a uma utilizacao cada vez maior da web como uma
plataforma de desenvolvimento A capacidade de cooperacao na edicao de conteudos
e a mobilidade proporcionada por esta plataforma sao os principais factores que
alimentam esta mudanca e pela primeira vez as aplicacoes tradicionais tem com-
peticao vinda de web applications A prova do reconhecimento da web como plataforma
de desenvolvimento pode ser retirada da aposta de empresas como a Adobe e Mi-
crosoft que lancaram publicamente ferramentas web complementares a produtos
seus tradicionalmente associados ao desktop ndash Acrobatcom5 e Microsoft Office
Live6 Dotar estas web applications da capacidade de execucao offline significa
aproximar a web e o desktop reunindo ldquoo melhor de dois mundosrdquo
As vantagens da mobilidade possıvel atraves da web a cooperacao na criacao e
edicao de conteudos e a possibilidade de utilizar aplicacoes sempre actualizadas e
sem necessidade de instalacao sao algumas das principais vantagens que promovem
esta mudanca que devido as preocupacoes associadas a usabilidade e experiencia do
utilizador esta fortemente associada ao desenvolvimento de Rich Internet Applica-
tion (RIA)s
5Adobe Acrobatcom httpwwwacrobatcom6Microsoft ndash httpsmallbusinessofficelivecom
14
Enquadramento do Projecto
Figura 23 Comparacao do modelo de web aplications sıncrono paginas estaticas e in-teractivas abordados nas seccoes 221 e 222 com o modelo de web applications Ajax(assıncrono) abordado na seccao 223 Figura adaptada de http www adaptivepath
com
15
Enquadramento do Projecto
16
Capıtulo 3
Estado da arte
Apesar de o conceito das OWAs nao ser absolutamente novo as tecnologias que
o suportam sao recentes Neste capıtulo descrevem-se quatro tecnologias que foram
tidas como principais candidatas para o desenvolvimento deste projecto Descrevem-
se ainda alguns exemplos de web applications que disponibilizam actualmente fun-
cionalidades offline e o processo da escolha da tecnologia a utilizar neste projecto
31 Gears
O Gears1 e uma extensao as funcionalidades do browser introduzido pelo Google
que tem como principal objectivo tornar possıvel a visualizacao de paginas de Inter-
net mesmo sem uma conexao disponıvel Encontra-se disponıvel para as platafor-
mas Windows Macintosh e Linux e oferece uma API de Javascript que permite
a scripts aceder a um mecanismo de armazenamento local baseado numa base de
dados SQLite
311 Arquitectura
Esta ferramenta e constituıda por tres componentes principais
bull LocalServer mdash Intercepta pedidos de paginas web e serve-as localmente
bull Database mdash Uma base de dados relacional construıda sobre SQLite
bull WorkerPool mdash Permite executar operacoes de computacao de uma forma
assıncrona sem afectar a capacidade de resposta e fluidez de execucao da web
application Assemelham-se a processos
1Google Inc ndash Mais informacao em httpgearsgooglecom
17
Estado da arte
LocalServer
O modulo LocalServer e uma cache de Uniform Resource Locators (URLs)
controlada pela web application Quando nao existe uma ligacao a Internet e e
feito um pedido para um URL presente nesta cache o LocalServer intercepta-o e
responde ao pedido localmente a partir do disco rıgido do utilizador A aplicacao
pode utilizar dois tipos diferentes de armazenamento local de URLs
bull ResourceStore ndash serve para capturar URLs utilizando exclusivamente a API
de Javascript disponibilizada para o efeito Uma aplicacao podera criar e
utilizar diversos ResourceStores simultaneamente para capturar ficheiros de
dados que necessitam de ser enderecados por um URL tal como um ficheiro
PDF ou uma imagem
bull ManagedResourceStore ndash serve para capturar um conjunto de URLs que estao
relacionados e que sao declarado num ficheiro de manifesto (especificado em
JSON) e que sao automaticamente actualizados O ManagedResourceStore
permite que o conjunto de recursos necessarios para correr uma web application
seja capturado e mantido actualizado automaticamente
A principal diferenca entre estes dois tipos de armazenamento de URLs e a forma
como sao actualizados os seus conteudos Os conteudos de um ManagedResourceStore
sao actualizados sempre que a versao contida no ficheiro de manifesto for alterada
enquanto que os conteudos de um ResourceStore nunca sao actualizados automati-
camente mas apenas quando for explicitamente ordenado pela aplicacao
O LocalServer e capaz de interceptar e servir localmente pedidos de HTTP e
HTTPS sempre que se reunam as seguintes condicoes
1 O URL encontra-se armazenado num ResourceStore ou ManagedResourceStore
2 O sistema de armazenamento local encontra-se activo (enabled = true) Se
o sistema de armazenamento local tiver o atributo requiredCookie o pedido
devera conter um cookie que lhe corresponda
O LocalServer nao necessita de monitorizar o estado da ligacao para atender aos
pedidos Na verdade sempre que as condicoes previamente enunciadas se verificarem
o LocalServer interceptara os pedidos e independentemente do estado da ligacao
a Internet servi-los-a a partir do disco rıgido local Cabera a aplicacao definir qual
o modo em que pretende executar um pedido (online ou offline) definindo o valor
de verdade da propriedade enabled
18
Estado da arte
Database
O modulo Database permite guardar dados da web application assegurando a
sua persistencia Os dados sao guardados de forma relacional no disco rıgido do uti-
lizador2 de acordo com o modelo de seguranca estabelecido pelo Gears3 significando
que uma aplicacao nao pode aceder a conteudos fora do seu domınio
WorkerPool
Nos web browsers uma operacao pesada de computacao pode tornar a interface
lenta e tornar menos agradavel a experiencia do utilizador O modulo WorkerPool
permite correr operacoes em background sem bloquear a interface com o utilizador
Os scripts executados numa WorkerPool nao activam os mecanismos de seguranca
do browser que mostram a mensagem ldquoA script on this page may be busy or may
have stopped respondingrdquo
O WorkerPool comporta-se como um conjunto de processos em vez de threads
Os Workers nao partilham qualquer estado de execucao o que significa que uma
alteracao a uma variavel num Worker nao afecta em nada a execucao de outro
Worker Alem disso os Workers nao herdam automaticamente nenhum codigo dos
seus pais Cada Worker e membro de um WorkerPool e os Workers podem in-
teragir entre si enviando mensagens em formato de texto ou JSON No entanto ha
tambem algumas limitacoes os Workers nao tem acesso ao DOM e objectos como
window ou document nao se encontram acessıveis Isto e consequencia de os Workers
nao partilharem o estado de execucao Mas tem acesso a todas as funcoes built-in
do Javascript A maioria das funcionalidades do Gears pode tambem ser acedida
atraves de uma variavel global especial definida como googlegearsfactory Para
outras funcionalidades especıficas os Workers podem ldquopedirrdquo a pagina principal para
continuar a execucao atraves do envio de mensagens
Outras funcionalidades
bull HttpRequest ndash Este modulo implementa a especificacao W3C XmlHttpRe-
quest definida em [vK08] tornando-a disponıvel para os workers e para a
pagina principal
bull Timer ndash Este modulo implementa a especificacao de timers tal como descrito
por [Hic08] e torna-os disponıveis para os workers e para a pagina principal
2Consultar httpcodegooglecomapisgearsapi_databasehtmldirectories3Consultar httpcodegooglecomapisgearssecurityhtml
19
Estado da arte
bull Factory ndash Esta classe e utilizada para instanciar todos os outros objectos da
API do Gears atraves do seu metodo create Este metodo pode ser utilizado
com os seguintes parametros
ndash betadatabase
ndash betahttprequest
ndash betalocalserver
ndash betatimer
ndash betaworkerpool
312 Goggle Gears em dispositivos moveis
O Gears esta tambem disponıvel em dispositivos Windows Mobile 5 e 6
Os dispositivos moveis estao pela sua natureza frequentemente desconectados
da Internet Mesmo quando possuem uma ligacao as latencias na transferencia de
dados em redes moveis tornam as aplicacoes pouco fluıdas mas o Gears permite
ultrapassar este obstaculo
O Gears funciona exactamente da mesma forma em dispositivos moveis equipados
com o Windows Mobile 5 e 6 como num computador comum Se uma aplicacao tiver
sido implementado com suporte para o Gears entao tambem estara preparada para
ser executada num dispositivo movel mas as limitacoes dos browsers disponıveis
para dispositivos moveis tem que ser consideradas Isto significa prever as condicoes
que permitam uma boa usabilidade devido aos pequenos ecras destes dispositivos
bem como o seu suporte limitado dos padroes do DOM CSS e JavaScript
32 Adobe AIR
O Adobe AIR4 e um runtime compatıvel com diversos browsers e sistemas opera-
tivos que pretende dar aos programadores a possibilidade de combinar diversas tec-
nologias de producao de conteudos para a Internet no desenvolvimento de Rich Inter-
net Application (RIA)s O Adobe AIR mantem uma relacao com o browser mas es-
tende as suas capacidades e tecnologias permitindo o desenvolvimento de aplicacoes
tambem para o ambiente de trabalho com janelas em tudo semelhantes as do sis-
tema operativo Segundo a Adobe o objectivo e complementar o browser dando
aos utilizadores (mas essencialmente aos programadores e equipas de desenvolvi-
mento) a escolha sobre como distribuir as suas aplicacoes Para este efeito o Adobe
AIR tem uma aproximacao diferente do Gears Em vez de ldquoestenderrdquo o browser
acrescentando-lhe funcionalidades o AIR permite tambem o desenvolvimento de
4Adobe - httpwwwadobecomproductsair
20
Estado da arte
aplicacoes que se destinam a ser executadas fora do ambiente do browser mas uti-
lizando as tecnologias comuns da Internet (por exemplo HTML CSS JavaScript
Flash Flex)[CDGH08]
A utilizacao desta tecnologia permite utilizar o browser ou o proprio runtime
Adobe AIR como plataforma de execucao da aplicacao
Na Tabela 31 faz-se uma comparacao das funcionalidades disponıveis de acordo
consoante se escolha o browser ou o desktop como plataforma base para a aplicacao
Uma vez que as aplicacoes Adobe AIR na plataforma desktop tem um caracter
persistente (sao instaladas no computador do utilizador) o Adobe AIR tem um
modelo de seguranca que se assemelha com o das tradicionais aplicacoes desktop
[Ada08] Este modelo e analisado nas seccoes 321 e 322 O ambiente em que
e executado o browser e restringido a execucao de web applications que podem
ser de varias origens (incluindo de origens anonimas ou sem confianca) O Adobe
AIR proporciona acesso a capacidades como acesso a ficheiros que necessitam da
confianca do utilizador
bull HTML ndash O desenvolvimento de aplicacoes para o Adobe AIR pode ser feito
com recurso a tecnologias de HTML e Ajax comuns utilizando as linguagens
de markup existentes distribuıdas como texto e interpretadas em execucao
(runtime)
bull Flash ndash Outra alternativa sera a utilizacao da linguagem Flash Permite a
renderizacao de graficos vectoriais e audiovıdeo com suporte nativo Utiliza
ActionScript para adicionar maior interactividade com o utilizador
bull Flex ndash O Flex e uma framework open source para o desenvolvimento de RIAs
usando Flash As aplicacoes Flex sao na realidade Flash sendo a principal
diferenca o ambiente de desenvolvimento
Como resultado uma aplicacao AIR podera ser implementada
bull Baseada em Flash ou Flex (aplicacoes cujo conteudo base e em ShockWave
Flash (SWF))
bull Baseada em Flash ou Flex tambem com HTML ou Portable Document Format
(PDF) Aplicacoes cujo conteudo de base e em FlashFlex (SWF) com HTML
(HTML JavaScript CSS) ou conteudo PDF incluıdo
bull Baseada em HTML Aplicacoes cujo conteudo base e em HTML Javascript
CSS
bull Baseada em HTML utilizando tambem FlashFlex ou PDF
21
Estado da arte
Os utilizadores interagem com uma aplicacao AIR da mesma forma que interagem
com outras aplicacoes com janelas nativas do seu sistema operativo O runtime e
instalado uma vez no computador do utilizador e a partir desse momento todas as
aplicacoes AIR terao o mesmo aspecto que qualquer outra aplicacao para o desktop
321 Seguranca
Permitir que uma web application aceda ao disco de armazenamento do utilizador
pode comprometer seriamente a sua seguranca Neste sentido o Adobe AIR tem
suporte para assinaturas digitais (Secure Sockets Layer (SSL)) que podem ser com-
pradas pelas equipas de desenvolvimento que o desejem e cujos certificados serao
apresentados ao utilizador no momento da instalacao Um outro aspecto ainda
relativo a seguranca e o mecanismo de isolamento de cada ambiente (sandbox )
322 Assinatura do codigo
O runtime AIR exige que todas as aplicacoes estejam digitalmente assinadas As
assinaturas digitais de codigo sao um processo que visa garantir a integridade da
aplicacao e a identidade do seu autor no momento da instalacao As equipas de
desenvolvimento podem ldquoassinarrdquo uma aplicacao utilizando um certificado atribuıdo
por uma Entidade Certificadora (Certification Authority) ou atraves de um certifi-
cado individual (self signed certificate) Neste momento o Adobe AIR suporta como
entidades certificadoras a Verisign e a Thawte [Ado08]
O instalador apresenta o nome de quem publica a aplicacao quando o codigo tiver
sido assinado com um certificado que apresente confianca ou que esteja encadeado
com um certificado que tenha ja sido aceite no computador em que se esta a instalar
a aplicacao
As equipas de desenvolvimento podem tambem assinar as aplicacoes com um
certificado auto-atribuıdo (um certificado criado por elas proprias) mas neste caso
o instalador apresentara estas aplicacoes como sendo de uma origem nao verificada
O AIR utiliza a infraestrutura publica de chaves [Ent07] suportada pelo arquivo
local do sistema operativo Para que a origem da aplicacao seja reconhecida o
computador onde a aplicacao AIR esta a ser instalada tem que confiar directamente
no certificado que foi utilizado para assinar a aplicacao ou confiar num certificado
que esteja num encadeamento logico de certificados confiados e que se ligue desta
forma ao certificado utilizado para assinar a aplicacao
Todas as aplicacoes AIR tem caracterısticas em comum independentemente da
tecnologia utilizada para o seu desenvolvimento (HTMLFlexFlash) No ambito
de uma aplicacao AIR existem um conjunto de APIs que estao disponıveis e que
tornam possıvel o acesso ao sistema local (leitura e escrita) e a recursos de rede que
22
Estado da arte
de outra forma nunca estariam acessıveis a partir de uma web application comum
Cada aplicacao AIR possui tambem diferentes nıveis de isolamento chamados secu-
rity sandboxes dependendo do tipo de conteudo que esta a ser carregado e do seu
objectivo
bull Isolamento ao nıvel da aplicacao5 ndash E a raiz de cada aplicacao AIR Este
nıvel de isolamento permite o acesso a APIs privilegiadas e especıficas do
AIR Em contrapartida e negado o acesso a algumas APIs que poderiam ser
facilmente utilizadas de forma maliciosa contra o utilizador final Importacao
dinamica de conteudos remotos e geralmente proibido e as tecnicas e mecan-
ismos de geracao dinamica de codigo sao fortemente restringidas Apenas
conteudo carregado directamente da directoria base da aplicacao podera ser
colocado neste nıvel de isolamento
bull Isolamento nao especıfico da aplicacao6 ndash contem todo o outro conteudo
que nao tenha sido carregado directamente para o isolamento da aplicacao
Isto inclui conteudo local e remoto Este tipo de conteudo nao tem acesso
directo as APIs do AIR e rege-se pelas mesmas regras tal como se tivesse sido
carregado por um browser a partir da mesma localizacao (por exemplo HTML
carregado a partir de um domınio remoto comporta-se da mesma forma que se
fosse acedido a partir do browser)
33 Mozilla Prism
331 XML User Interface Language
O eXtensible User Interface Language (XUL) e uma linguagem de anotacao
baseada em XML desenvolvida pela Mozilla Foundation que opera em aplicacoes
Mozilla multi plataforma tal como o Firefox O motor Gecko e a unica imple-
mentacao completa desta linguagem que foi desenhada sobre padroes web comuns
como CSS JavaScript e o DOM e permite o desenvolvimento de interfaces graficas
utilizando elementos pre-definidos tais como window box page textbox radio
button entre outros Infelizmente o XUL nao possui qualquer especificacao formal
ou implementacoes de inter-operabilidade para outros motores que nao o Gecko No
entanto a sua implementacao e licenciada em codigo aberto pelas licencas GNU Gen-
eral Public License (GPL) GNU Lesser General Public License (LGPL) e Mozilla
Public License (MPL)
Enunciam-se algumas caracterısticas desta linguagem
5NT application sandbox6NT non-application sandbox
23
Estado da arte
Liguagem de anotacao poderosa baseada em componentes (widgets) O ob-
jectivo do XUL e permitir a construcao de aplicacoes multi-plataforma em
claro contraste com o Dynamic HyperText Transfer Protocol (DHTML) que se
destina ao desenvolvimento de paginas web Por esta razao o XUL esta orien-
tado a componentes tais como janelas botoes e etiquetas em vez de paginas
cabecalhos de texto e ligacoes de hipertexto Investir tempo e esforco para
atingir este mesmo resultado em aplicacoes baseadas em DHTML compromete
frequentemente a complexidade e desempenho da aplicacao
Baseado em padroes O XUL e um dialecto XML baseado no padrao W3C XML
10 As aplicacoes escritas em XUL sao tambem baseadas em especificacoes
W3C adicionais como HTML 40 CSS DOM nıvel 1 e 2 JavaScript 15
incluindo ECMA-262 Edition 3 (ECMAscript)
Portabilidade entre plataformas Tal como HTML o XUL foi desenhado para
ser independente da plataforma em que e utilizado tornando as aplicacoes
facilmente portaveis entre sistemas operativos nos quais o Mozilla e suportado
Uma vez que o XUL oferece um nıvel de abstraccao dos componentes graficos
de interface que disponibiliza implementa a premissa ldquoum codigo para todas
as plataformasrdquo A interface grafica de todos os produtos centrais Mozilla
(browser instant messenger livro de enderecos) e escrita em XUL com um
unico codigo base que suporta todas as plataformas Mozilla
Separacao entre o nıvel de apresentacao e a logica de negocio Uma das
maiores preocupacoes no desenvolvimento para a Internet e a forte ligacao
entre estas duas camadas (interface e logica) Isto constitui um problema sig-
nificativo no desenvolvimento de grandes aplicacoes especialmente quando o
desenvolvimento e feito em ambientes de equipa porque as capacidades de de-
senvolvimento destas duas partes da aplicacao estao muitas vezes espalhadas
por diferentes elementos O XUL permite uma clara distincao entre a definicao
da aplicacao cliente e da logica de implementacao (XUL eXtensible Binding
Language (XBL) e JavaScript) apresentacao (CSS e imagens) internacional-
izacao (Document Type Definitions (DTDs) e etiquetas de texto em lınguas
especıficas guardados em ficheiros properties) O esquema grafico e apre-
sentacao de uma aplicacao XUL pode ser alterado de forma independente da
sua logica ou implementacao e a aplicacao pode ainda ser traduzida (interna-
tionalization) de forma independente da sua logica implementacao ou apre-
sentacao Este grau de separacao resulta em aplicacoes que sao mais faceis de
manter pelos programadores e facilmente adaptadas por designers e tradutores
24
Estado da arte
Facil adaptacao Outro benefıcio que advem do nıvel de separacao entre logica
de negocio e apresentacao oferecido pelo XUL e a facilidade com que se pode
adaptar uma aplicacao para diferentes clientes ou grupos de utilizadores Um
programador pode utilizar a mesma aplicacao base e adapta-la consoante as
necessidades atraves de diferentes temas (skins) e ficheiros de lınguas Desta
forma uma aplicacao escrita e desenvolvida em Ingles pode ser rapidamente
traduzida para Portugues e distribuıda com outra aparencia mais apropriada
ao cliente alvo
332 Prism
O Mozilla Prism e um browser simplificado e ldquointerpretadorrdquo de XUL (tambem
designado por XULRunner) que acolhe web applications sem a interface grafica ha-
bitual de um browser Baseia-se num conceito designado por Site Specific Browser
(SSB) Um SSB e uma aplicacao com um browser embebido desenhado para exe-
cutar apenas uma web application Nao possui os menus e barras de ferramentas
habituais Um SSB tem uma integracao com o sistema operativo e com o desktop
muito mais estreita do que uma web application acedida atraves de um browser uma
vez que e executado em janela propria
O Prism resulta de uma experiencia da Mozilla e visa reduzir as diferencas entre
as desktop applications tradicionais e as web applications Um dos aspectos focados e
a experiencia do utilizador Numa apresentacao oficial e dito que ldquo[o Prism] pretende
ser uma ponte entre as diferencas que existem entre as aplicacoes tradicionais de
desktop e as web applications explorando novos modelos de usabilidade enquanto
que a linha que as separa se continua a definirrdquo [Lab07]
34 HTML 5
A especificacao HTML 5 [Hic08] que se encontra em fase de desenvolvimento
pelo grupo WHATWG pretende ser uma norma de substituicao dos padroes HTML
4 XHTML 1x e do DOM2 HTML Uma das propriedades que o distingue das tec-
nologias que pretende substituir e precisamente o suporte para OWA e armazena-
mento de dados no cliente de uma forma relacional Nao sendo propriamente uma
tecnologia ndashmas antes uma especificacao ndashe aqui mencionada por ter servido como
referencia a diversas implementacoes de funcionalidades offline e por se considerar
que venha a ter um impacto significativo nas implementacoes de diversos browsers
Dion Almaer defendeu no seu blogue que o Gears era uma implementacao do
HTML 5 No seu artigo ldquoGears as a bleeding-edge HTML 5 implementationrdquo [Alm08]
o autor diz que ambos ndasho Gears e o HTML 5 ndashpretendem dar a web caracterısticas
25
Estado da arte
semelhantes e nao encontrar motivo de ldquocompeticaordquo entre as duas mas que en-
quanto o HTML 5 e uma especificacao o Gears e uma implementacao
No entanto tambem e verdade que o HTML 5 cobre muitos outros pontos para
alem das OWA que saem completamente fora do ambito do Gears Se esta es-
pecificacao atingir um estado de maturidade que possibilite a sua adopcao pelos
principais browsers tornando nativo do browser o suporte OWA entao deixara de
fazer sentido a existencia de uma extensao como o Gears
A especificacao HTML 5 disponibiliza duas APIs relevantes para o tema das
OWA
1 Uma base de dados baseada em SQL que permite o armazenamento de dados
do lado do cliente
2 Uma ldquocacherdquo HTTP que garante a disponibilidade das aplicacoes mesmo quando
o utilizador nao possui uma ligacao a Internet
Estas caracterısticas sao as bases da tecnologia das OWA e tem correspondencia
com os pontos analisados nas seccoes 311 e 311
35 Web applications que usam funcionalidades offline
Nesta seccao apresentam-se algumas web applications que actualmente disponi-
bilizam funcionalidades offline Estas aplicacoes foram escolhidas para uma analise
mais pormenorizada por utilizarem o Gears que tal como descrito na seccao 4 foi
a tecnologia escolhida para o projecto
351 Google Reader e Google Docs
O Google Reader7 e um leitor de feeds RSS Permite gerir a subscricao de varios
sites simultaneamente que disponibilizem conteudos neste formato e foi a primeira
web application da Google com uma versao offline publicamente acessıvel (desde
Junho de 2007)
O Google Reader implementa o modo ldquoutilizador deciderdquo oferecendo na sua
interface um botao que permite alternar entre os modos online e offline
O Google Docs8 e uma web application que permite a criacao e edicao de doc-
umentos de texto folhas de calculo e apresentacoes Era ja publico desde Janeiro
de 2008 que o Google estava a desenvolver uma versao OWA desta aplicacao mas o
acesso a uma versao experimental so foi possıvel a partir de 31 de Maio de 2008
7Google Reader - httpreadergooglecom8Google Docs - httpdocsgooglecom
26
Estado da arte
A implementacao das funcionalidades offline nestas duas aplicacoes seguiu difer-
entes aproximacoes principalmente porque o Google Reader apresenta ao utilizador
informacoes que sao fornecidas por fontes externas enquanto que no Google Docs
a informacao e criada e editada pelo utilizador sobre a forma de documentos
A diferente origem da informacao implica que no Google Reader seja necessario
prever casos de excepcao tal como existirem demasiados itens que necessitam de
ser transferidos para o cliente Nao observar este ponto causa um problema grave
de usabilidade e para evitar tempos de espera demasiado longos e uma interface
com pouca capacidade de resposta as accoes do utilizador o Google Reader apenas
transfere para o cliente os dois mil itens mais recentes na transicao para o modo
offline
352 Remember the Milk
O Remember The Milk9 e uma web application desenvolvida por uma equipa
Australiana que proporciona funcionalidades de agenda gestao de tempo e de tare-
fas e foi uma das primeiras aplicacoes independentes do Google a adoptar o Gears
para acessos em modo offline Permite que os seus utilizadores facam uma gestao
de tarefas agrupando-as em listas adicionando-lhes campos de informacao adicional
ou dando-lhes informacao geografica (recorrendo ao servico Google Maps10) Entre
a sua lista de funcionalidades encontra-se ainda a possibilidade de importar e ex-
portar eventos no formato iCalendar (ics) etiquetas (tags) em tarefas publicacao
Really Simple Syndication (RSS) e partilha de categorias de tarefas de acordo com
diferentes nıveis de permissoes de acesso definidos pelo utilizador
353 MySpace e WordPresscom
O MySpace uma das maiores social networks na Internet anunciou recente-
mente que vai disponibilizar uma versao do seu cliente de e-mail que utiliza o Gears
para acelerar o seu desempenho Numa fase inicial estara disponıvel apenas para
utilizadores que tenham cinco mil ou mais mensagens na sua caixa de correio e
permitira efectuar pesquisas muito mais rapido que a sua versao online
O servico de blogs Wordpresscom anunciou tambem o inıcio da utilizacao desta
tecnologia com o fim de melhorar o desempenho A versao que utiliza esta tecnologia
descarrega e armazena no cliente um conjunto de imagens e scripts que passam a
ter preferencia sobre os seus congeneres online e que permitem acelerar o processo
de carregamento da aplicacao e visualizacao de blogs
9Remember The Milk ndash httpwwwrememberthemilkcom10Google Maps ndash httpmapsgooglecom
27
Estado da arte
O MySpace e o Wordpresscom sao dois exemplos da utilizacao da tecnologia
OWA para optimizacao de web application ja existentes Sem pretenderem disponi-
bilizar uma versao que seja totalmente offline fazem uso do Gears para armazenar no
cliente parte dos recursos frequentemente acedidos na visualizacao das suas paginas
36 Escolha da tecnologia
Apos a analise das tecnologias apresentada nas seccoes 31 a 34 foi necessario es-
tudar a adequacao de cada uma delas ao projecto em questao Desde logo e possıvel
observar que nem todas se dedicam apenas a OWA Por exemplo o Adobe AIR
apesar de ter suporte para OWA apenas disponibiliza algumas das funcionalidades
identificadas como mais indicadas para a execucao do projecto quando utilizado
na sua vertente desktop tal como exposto na Tabela 31 mas a utilizacao desta
vertente implicaria o desenvolvimento de novas interfaces e de novas formas de co-
municacao (troca de mensagens XML ou JSON) A vertente web do Adobe AIR
foca-se mais especificamente nas Rich Internet Applications e permite a reutilizacao
do codigo ja existente (exigindo naturalmente a sua adaptacao e a implementacao
das funcionalidades pretendidas)
A tecnologia escolhida para a realizacao deste trabalho foi o Gears sendo que
um dos principais factores a influenciar esta opcao foi a liberdade introduzida pela
sua licenca Berkeley Software Distribution (BSD)11
Considerou-se o funcionamento desta ferramenta extremamente adequando a
aplicacao no WOW uma vez que o seu principal objectivo e precisamente tornar
possıvel a execucao offline de uma pagina web e por virtude deste facto o Gears tem
uma API concisa e de simples aplicacao pratica uma vez que nao possui quaisquer
outros elementos distractores O funcionamento do seu ManagedResourceStore ex-
emplificado na Figura 31 com a capacidade de actualizacao de recursos definidos
num ficheiro manifesto especificado em JSON pesou tambem nesta decisao
11Sobre a licenca BSD consultar httpwwwopensourceorglicensesbsd-licensephp e http
wwwlinfoorgbsdlicensehtml
28
Estado da arte
Figura 31 Esquema UML do processo efectuado pelos recursos do Gears do tipoManagedResourceStore para a actualizacao dos conteudos definidos no ficheiro manifesto
29
Estado da arte
Funcionalidade RIAs no browser RIAs no desktop
Disponibilidadeda aplicacao
As aplicacoes podem ser facil-mente exploradas e utilizadas
As aplicacoes quando instal-adas tem maior grau de fun-cionalidades e persistencia
Instalacao Nao e necessario qualquer tipode instalacao
As aplicacoes sao instaladasatraves do browser ou descar-regadas e instaladas comouma aplicacao tradicional
Actualizacoes Aplicacoes sao actualizadascarregando conteudos paraum website
O AIR disponibiliza uma APIque permite que as aplicacoessejam actualizadas de umaforma
Sistemas opera-tivos suportados
As aplicacoes podem ser exe-cutadas em diversos sistemasoperativos e browsers
As aplicacoes sao multi-plataforma e podem serinstaladas e executadas emdiversos sistemas operativos ebrowsers
Linguagens deprogramacao
Javascript e disponibilizadopelo browser e ActionScripte disponibilizado pelo AdobeFlash Player
Maquinas virtuais deJavascript e ActionScriptcompatıveis com o browser
Capacidade deexecucao embackground
As RIAs podem ser execu-tadas numa janela do browser
As aplicacoes podem ser ex-ecutadas em background edisponibilizar notificacoes talcomo uma aplicacao tradi-cional
Persistencia A actividade esta limitada asessao do browser Quando obrowser e encerrado toda ainformacao e descartada
As aplicacoes sao instaladas eestao disponıveis no desktopPodem armazenar informacaolocalmente e estao disponıveisoffline
Integracao com odesktop
Integracao com o desktop lim-itada devido a restricoes im-postas pelo browser
As aplicacoes podem acederao sistema de ficheiro ao clip-board eventos notificacoesetc
Controlo da inter-face com o uti-lizador
As aplicacoes sao acedidasatraves de uma janela dobrowser que tem os seusproprios controlos e visualgrafico
As aplicacoes tem um vi-sual grafico proprio em janelapropria
Armazenamentode dados
As aplicacoes tem armazena-mento limitado que pode serreescrito pelo browser
As aplicacoes tem acesso a to-talidade do espaco disponıvellocalmente e a uma base dedados com a possibilidade deencriptacao
Tabela 31 Comparacao das funcionalidades oferecidas pelo Adobe AIR para as platafor-mas web e desktop
30
Estado da arte
Aplicacao Modo de execucao utilizadoGoogle Reader Utiliza o modo ldquoutilizador deciderdquo disponibilizando
ao utilizador um botao para alternar entre os modosonline e offline Como lida com informacao recol-hida de fontes externas de natureza frequentementeefemera o processo de sincronizacao apenas transfereos dois mil itens mais recentes quando passa ao es-tado offline Neste modo sao ainda guardadas in-formacoes de itens lidos e etiquetas atribuıdas quesao sincronizadas com o servidor quando o utilizadorvoltar a activar estado online
Google Docs Utiliza o modo ldquoaplicacao deciderdquo permitindo que outilizador edite os conteudos de documentos de textofolhas de calculo e de apresentacoes independente-mente do estado da ligacao desde o momento em queas funcionalidades offline sao activadas A aplicacaofaz pequenas sincronizacoes com o servidor sempre quenecessario
Remember the Milk Utiliza um modo hıbrido entre ldquoaplicacao deciderdquo eldquoutilizador deciderdquo A aplicacao encarrega-se da sin-cronizacao de dados mas disponibiliza um controlona sua interface que permite despoletar manualmenteeste processo para situacoes em que o utilizador fez al-teracoes recentes e pretende usufruir das capacidadesoffline imediatamente
MySpace O MySpace anunciou a utilizacao de mecanismos dearmazenamento de dados no cliente com recurso atecnologias OWA para melhorar o desempenho doseu cliente web de correio electronico nomeadamenteno que diz respeito a operacoes de pesquisa e or-denacao Inicialmente esta funcionalidade estara ape-nas disponıvel para utilizadores com cinco mil ou maismensagens na sua caixa de correio mas nao e aindaclaro se sera disponibilizada uma versao totalmenteoffline
Tabela 32 Resumo da utilizacao de tecnologias OWA em algumas web applications con-sideradas na analise do estado da arte
31
Estado da arte
32
Capıtulo 4
Desenvolvimento
Neste capıtulo introduz-se a aplicacao WOW e apresenta-se o estudo que foi
feito da adequacao de cada tecnologia para a implementacao da funcionalidade of-
fline nesta plataforma Fazem-se diversas consideracoes sobre opcoes a tomar na
concepcao de OWAs e problemas comuns na sua implementacao bem como sug-
estoes para os resolver O WOW e uma aplicacao ja existente de gestao de ordens
de trabalho e do fluxo de tarefas numa empresa ou organizacao
41 Como ficar offline
Na maior parte das web applications de hoje nao existe uma camada de dados
real A aplicacao exemplificada na Figura 41 ao longo da sua execucao acede
directamente a sua unica fonte de dados (o servidor) atraves de chamadas Ajax sem
que exista uma separacao clara destas duas camadas
Para que uma web application seja capaz de ser executada sem uma ligacao
activa a Internet e mantenha o seu caracter dinamico torna-se necessario incluir
Figura 41 Exemplo de uma arquitectura de uma web application sem uma camada deabstraccao de dados Figura adaptada de http gears google com
33
Desenvolvimento
Figura 42 Exemplo de uma arquitectura de uma web application com uma camada deabstraccao de dados Figura adaptada de http gears google com
um mecanismo de armazenamento de dados local seja uma base de dados ou a
capacidade de acesso ao disco No entanto este mecanismo introduz dois problemas
1 Qual das fontes de dados utilizar quando um utilizador faz um pedido de
informacao
2 A necessidade de implementar uma camada de acesso a dados que seja coerente
quer se use o servidor remoto ou local
Por exemplo em vez de a aplicacao Ajax fazer um pedido relativo as contas de
todos os utilizadores em formato JSON directamente ao servidor remoto podera ao
inves fazer o pedido a um objecto intermedio da camada de dados Este objecto
demonstrado na Figura 42 sera responsavel por implementar uma interface de
acesso a base de dados e retornar um objecto JavaScript com uma representacao da
resposta do servidor
Mas a existencia de uma segunda fonte de dados torna recomendavel tambem
a implementacao de uma camada de data switching que em funcao da existencia
de conexao a Internet e da necessidade de actualizacao dos dados decide se faz o
pedido ao servidor remoto ou se fornece os dados presentes localmente Este objecto
apresentado na Figura 43 decidira de forma transparente para o utilizador se le ou
escreve os dados localmente ou se os enviapede ao servidor remoto e pode tambem
iniciar o processo de convergencia de dados e de resolucao de conflitos
411 Funcionalidades disponıveis em modo offline
Por razoes praticas e provavel que nem todas as funcionalidades da aplicacao
possam ser disponibilizadas em modo offline E necessario escolher quais as fun-
cionalidades a disponibilizar no modo offline da aplicacao e implementar a logica
que decide quando utilizar a base de dados local ou o servidor remoto Apesar do
acesso a base de dados local ser muito mais rapido do que aceder ao servidor o
acesso local nem sempre e preferido Ha varias razoes que podem tornar necessario
escolher o acesso ao servidor em vez do acesso local
34
Desenvolvimento
Figura 43 Exemplo de uma arquitectura de uma web application com uma camada deabstraccao de dados e um data switch Figura adaptada de http gears google com
1 A informacao pode ter uma natureza efemera e nao fazer sentido guarda-la
localmente Exemplo dados em tempo real da bolsa de valores de Lisboa
2 Algumas aplicacoes lidam com informacao que so faz sentido na presenca de
uma ligacao Exemplo Instant Messaging
3 A aplicacao podera escolher apenas guardar a informacao acedida mais fre-
quentemente Exemplo para o utilizador poder alterar a lıngua de apre-
sentacao da aplicacao os conteudos terao que ser guardados em todas as
lınguas disponibilizadas pela aplicacao O custo de implementacao de algu-
mas funcionalidades pode nao compensar o benefıcio
4 A capacidade de processamento ou de armazenamento de dados pode inviabi-
lizar algumas funcionalidades offline Exemplo se uma dada funcionalidade
necessita de uma capacidade de armazenamento de dados para alem do razoavel
de um computador pessoal para ser util (visualizador de mapas)
42 Modos de execucao
Um aspecto que e necessario estudar para qualquer web application que se deseje
disponibilizar offline prende-se com tres modos de execucao que devem ser consid-
erados
1 Utilizador decide o modo de execucao A aplicacao tem modos distintos
de execucao para os estados online e offline geralmente indicados na interface
com o utilizador O utilizador e informado do estado da ligacao e participa na
alteracao de estado de execucao da aplicacao interagindo com a sua interface
2 Aplicacao decide o modo de execucao Pode ser implementado na propria
aplicacao um mecanismo de deteccao do estado da ligacao (por exemplo atraves
35
Desenvolvimento
de chamadas Ajax periodicas) transitando de estado e sincronizando automati-
camente Desta forma o utilizador nao precisa de participar na alteracao de
estado a menos que exista um conflito de dados que requeira a sua atencao
3 Aplicacao assume sempre o estado offline Outra hipotese sera imple-
mentar uma web application que assume sempre estar na ausencia de uma
ligacao ao servidor de dados Esta aplicacao responde aos pedidos do uti-
lizador efectuando pedidos de informacao ao servidor mas nao dependendo
de uma resposta valida para mostrar a informacao que ja tinha disponıvel an-
teriormente A sincronizacao de dados com o servidor e tentada sempre que
existam dados para submeter e uma accao do utilizador
421 Modo ldquoutilizador deciderdquo
Neste modo de execucao quando a aplicacao esta online comunica com o servidor
remoto quando esta offline comunica com a base de dados local A informacao tem
que ser sincronizada sempre que se muda de modo A principal vantagem desta opcao
e que e a mais simples de implementar mesmo para uma aplicacao ja existente e
portanto uma forma expedita de disponibilizar uma OWA No entanto tem tambem
algumas desvantagens que devem ser consideradas
1 O utilizador tem que se lembrar de fazer a alteracao de estado de execucao
Caso contrario podera estar a trabalhar inadvertidamente numa versao offline
com dados antigos ou nao ter a informacao necessaria se perder subitamente
a ligacao
2 Se a ligacao for intermitente o utilizador tera ou que escolher um dos modos
de execucao ou estar constantemente a trocar
3 Uma vez que a base de dados nao esta sempre actualizada nao podera ser
utilizada para melhorar a rapidez de execucao da aplicacao quando em modo
online
422 Modo aplicacao decide
A deteccao do estado da ligacao pode ser implementada atraves de um pedido
assıncrono ao servidor tal como ilustrado na Figura 44 O resultado deste pedido
definira o estado online (em caso de sucesso) ou offline (em caso de falha) A
sincronizacao de dados podera ser feita sempre que ocorra uma transicao do es-
tado offline para o estado online No entanto este metodo nao se revela eficiente
36
Desenvolvimento
Figura 44 Esquema grafico ilustrando uma OWA executando no browser utilizando ummodo de execucao do tipo ldquoaplicacao deciderdquo com deteccao automatica do estado daligacao via pedidos Ajax assıncronos a cada cinco segundos
para grandes aplicacoes uma vez que requer a troca de mensagens demasiado fre-
quentes com o servidor que se destinam exclusivamente a monitorizacao do estado
da ligacao
423 Modo ldquoaplicacao assume o estado offlinerdquo
Uma aplicacao transparente funciona assumindo sempre que esta em modo of-
fline ou pelo menos que pode perder a ligacao a qualquer momento Neste modo
tira-se o maximo partido do armazenamento local e fazem-se pequenas mas contınuas
sincronizacoes com o servidor sempre que este esteja disponıvel A sincronizacao de
dados tambem e feita sempre que se volta ao estado online
As vantagens de uma web application transparente sao as seguintes
bull Uma melhor experiencia para o utilizador uma vez que este nao tem que se
preocupar com o estado da ligacao ou com a transicao de estados
bull A aplicacao funciona de forma coerente mesmo que a ligacao seja intermitente
bull Uma vez que o armazenamento local e mantido actualizado pode ser utilizado
para melhorar o desempenho da aplicacao
Foram identificadas as seguintes desvantagens
bull E mais difıcil de implementar e a sincronizacao acarreta cuidados especiais
bull E necessario um cuidado adicional para evitar que as operacoes de sincronizacao
frequentes que ocorrem automaticamente nao afectem os tempos de resposta
da aplicacao
bull Os testes a aplicacao sao mais complexos uma vez que a sincronizacao de dados
nao ocorre em resposta a uma accao do utilizador
37
Desenvolvimento
43 Sincronizacao de dados
A sincronizacao de dados consiste na capacidade de identificar e transferir pe-
riodicamente a versao mais actual dos dados entre o cliente e o(s) servidor(es)
Independentemente do modo de execucao escolhido e mesmo do estado da ligacao
do utilizador a informacao armazenada localmente e a informacao armazenada no
servidor estarao por vezes dessincronizadas Isto podera acontecer sempre que por
exemplo
bull O utilizador faz alteracoes em modo offline
bull A informacao e partilhada e pode ser alterada por uma entidade externa
bull A informacao e fornecida por uma entidade externa
Resolver estas diferencas de forma a que a informacao local e remota encontrem
a igualdade chama-se sincronizacao de dados Ha varias aproximacoes possıveis
para este efeito que dependem da natureza da aplicacao cada uma com vantagens
e desvantagens
A capacidade de suportar a mobilidade dos utilizadores torna-se cada vez um
ponto mais importante de uma web application Para uma organizacao de dimensao
global e vital garantir que os seus colaboradores tem acesso a mesma informacao
que tem disponıvel nos seus postos de trabalho mesmo quando estao fora Na maior
parte dos casos estes colaboradores terao acesso a um computador portatil um
desktop Smartphone ou PDA e atraves destes poderao ter acesso a sua informacao
directamente atraves de ligacoes encriptadas Virtual Private Network (VPN) de um
servidor web ou de outro mecanismo de rede
Esta solucao e simples de implementar mas infelizmente para a maioria dos
colaboradores com grande factor de mobilidade nao e satisfatoria As principais
desvantagens sao as seguintes
bull Requisitos de ligacao Para permitir que os utilizadores acedam a sua in-
formacao e necessario garantir a capacidade constante de comunicacao pelo
menos durante o tempo necessario que assegure a sua transferencia
bull Velocidade de ligacao sem persistencia de dados e em ligacoes de fraca
qualidade a usabilidade por vezes torna-se inaceitavel
bull Ponto crıtico de falha Com este tipo de solucao todos os utilizadores de-
pendem da base de dados que armazena informacao vital para o funcionamento
do cliente
38
Desenvolvimento
bull Scalability do servidor A medida que novos utilizadores sao adicionados ao
sistema o desempenho do servidor e afectado levando a necessidade de maior
capacidade de armazenamento eou processamento
De acordo com a documentacao da Microsoft Sync Framework [Mic08] uma
solucao alternativa consiste em implementar uma Occasionally Connected Appli-
cation (OCA) Uma OCA permite a um utilizador remoto continuar a aceder a
sua informacao mesmo depois de perder a ligacao mas em vez de recorrer a um
servidor recorre a informacao armazenada no seu dispositivo local Para preencher
localmente a informacao que o utilizador necessita uma OCA possui mecanismos
de sincronizacao de dados que sao oferecidos por esta framework
431 Quando sincronizar
Uma das solucoes mais simples de implementar passa por disponibilizar um
mecanismo manual que despoleta a sincronizacao Diz-se manual porque e o uti-
lizador que escolhe quando sincronizar e pode ser implementada simplesmente
fazendo o upload de toda a informacao para o servidor e depois fazendo o download
da copia mais recente da informacao antes de voltar a ficar offline Para que esta
seja uma opcao viavel e necessario que
bull O volume de dados seja suficientemente pequeno para que possa ser transferido
do servidor para o cliente num espaco de tempo aceitavel
bull Que o utilizador indique explicitamente que quer mudar para o estado offline
ou online pressionando um botao da interface
Contudo podem ser identificados alguns problemas relacionados com esta abor-
dagem
bull Os utilizadores nem sempre podem prever o estado das suas ligacoes A ligacao
pode-se perder subitamente ou ter um caracter intermitente
bull O utilizador pode esquecer-se de efectuar a sincronizacao
Outra opcao sera conjugar a sincronizacao de dados com o modo de execucao
transparente A sincronizacao ocorre automaticamente em background de forma
nao intrusiva para o utilizador A aplicacao comunica com o servidor regularmente
efectuando pequenas trocas de dados com o objectivo de manter o sincronismo da
informacao local e remota Esta abordagem pode ser implementada com pedidos
Ajax assıncronos e regulares ao servidor o que permite manter a interaccao com a
interface fluıda evitando bloqueios Estes pedidos sao feitos prevendo as situacoes
39
Desenvolvimento
de disponibilidade ou indisponibilidade (timeout) do servidor Uma outra opcao
sera permitir que o servidor comunique essas alteracoes utilizando Comet1 tal como
descrito em [Wil06] e [Rus06] As vantagens destas aproximacoes sao
bull A informacao esta disponıvel a qualquer altura que o utilizador decida ficar
offline ou que a ligacao seja acidentalmente perdida
bull O desempenho da aplicacao pode ser melhorado quando se estiver a utilizar
uma ligacao a Internet lenta uma vez que o acesso a dados locais e mais
eficiente do que a consulta de dados ao servidor
44 WOW
O WOW e uma plataforma integrada de gestao de ordens de trabalho ja ex-
istente e desenvolvida pela Critical Software SA a qual se pretende adicionar a
capacidade de execucao offline Esta aplicacao e extremamente dinamica e con-
figuravel com um conjunto extremamente rico de funcionalidades das quais se
destacam
bull Gestao de Ordens de Trabalho ndash suportando a gestao dos pedidos desde a
sua criacao ate ao seu fecho tomando em conta os diferentes tipos de pedidos
(ordens de trabalho pedidos de informacao melhorias resolucao de problemas
etc) e diferentes tipos de accoes possıveis para cada um (Figura 45)
bull Monitorizacao de alteracoes ndash Historico de mudancas anexos e estados criando
relatorios de alteracao automaticamente (o que por quem e quando)
bull Uso de Service Level Agreements (SLAs) ndash E possıvel associar a um pedido um
SLA que define qual o perıodo de tempo atribuıdo a resolucao de um pedido
controlando e agilizando a resolucao do mesmo
bull Utilizacao de queries de utilizador configuraveis que permitem acesso rapido
a determinadas ordens de trabalho de acordo com o filtro configurado (por
exemplo ldquoPara mimrdquo ldquoPara o Grupordquo ldquoPelo Grupordquo)
bull Gestao do relacionamento entre pedidos
bull Pesquisa e filtragem de ordens de trabalho
bull Exportacao de dados em formatos padrao (PDF DOC ou XLS)
bull Integravel com solucoes externas
40
Desenvolvimento
Figura 45 Detalhe de um conjunto possıvel de estados e respectivas transicoes para umadada ordem de trabalho no WOW desde a sua submissao no sistema ate a sua conclusaoem fecho ou cancelamento Esta figura representa apenas um exemplo ja que o mapa deestados para uma ordem de trabalho e dinamico e pode ser alterado por um administradorFigura retirada de uma brochura promocional do WOW Critical Software SA
A utilizacao de uma ferramenta deste tipo por parte de uma empresa ou orga-
nizacao oferece vantagens quer a gestao de topo quer aos colaboradores individuais
para os colaboradores individuais o WOW e uma aplicacao onde estao registadas
todas as tarefas contribuindo activamente para o desenvolvimento em ambientes
multi-tarefa e para a organizacao pessoal das tarefas de acordo com prioridades
Para a gestao de topo esta ferramenta permite obter uma visao global do estado da
organizacao em termos de tempo gasto por tarefa executada sendo uma mais valia
para a previsao e gestaoalocacao de recursos
45 Visao geral sobre a arquitectura do WOW
O WOW e interessante nao so do ponto de vista de produto como tambem do
ponto de vista de plataforma Existem diversos plug-ins que estendem as funcional-
idades do WOW e existem ate projectos que pretendem usar a arquitectura do
WOW para criar produtos com fins diferentes do inicial (por exemplo o WOW-
Storm ndash um sistema de registo e classificacao social de ideias)
De modo a conseguir ter essa expansibilidade a plataforma WOW assenta sob
uma arquitectura distribuıda modular e expansıvel com uma componente central
ndash o core ndash estruturado em camadas logicas E no core que se situam todas as
1O Comet e um conceito semelhante ao Ajax introduzido por Alex Russel mas no qual e o servidor quetoma a iniciativa de ldquoenviarrdquo os dados ao browser sem que este tenha que efectuar um pedido Tambem econhecido por Ajax Push Reverse Ajax ou HTTP Streaming
41
Desenvolvimento
funcionalidades base da aplicacao quer a nıvel logico funcional e de apresentacao
quer a nıvel de gestao e configuracao
E possıvel a execucao de varias instancias do core simultaneamente em servidores
distintos o que permite a alta escalabilidade e disponibilidade desta aplicacao A
consistencia dos dados fica sempre garantida atraves da partilha da base de dados
e pelo balanceamento dos pedidos uma vez que cada um e encaminhado para uma
unica instancia
O WOW apresenta tambem a vantagem de ser uma plataforma extensıvel E
possıvel adicionar novas caracterısticas a plataforma atraves de componentes que se
podem ser divididos em duas categorias plugins e connectors
Os plugins sao componentes que se encontram no mesmo no fısico que a aplicacao
partilhando do mesmo contexto de execucao do core Sao assim uma forma mais
directa de obter informacao da plataforma visto que nao possuem restricoes de
acesso aos dados nem dependencias externas A arquitectura deste componente tera
assim que permitir varias execucoes instanciadas cada uma associada a um core
Por outro lado os connectors sao componentes que se encontram distribuıdos
comunicando externamente com o core Quer a sua execucao quer a obtencao
dos dados estao assim dependentes de interfaces de comunicacao externas que a
plataforma disponibiliza Estes componentes ao contrario dos plugins sao instan-
ciados unicamente e recorrem ao protocolo de comunicacao Java Messaging Service
(JMS) para comunicar com o core
46 WOW Offline
Para alem das opcoes tomadas relativamente a tecnologia a utilizar surgiu
tambem a necessidade de optar por um dos modos de execucao apresentados na
seccao 42
Das tres opcoes possıveis foi o modo ldquoaplicacao assume o estado offlinerdquo descrito
na seccao 423 que mereceu a maior atencao uma vez que reune as vantagens de
uma experiencia mais positiva para o utilizador (uma vez que este nao tem que
participar activamente na alteracao do modo execucao como descrito na seccao 421)
e nao constitui uma sobrecarga excessiva para servidor (como o modo abordado na
seccao 422)
No entanto esta opcao comprometia a complexidade da implementacao para alem
dos objectivos propostos para este projecto e para cumprir o prazo dado foi tomada
a decisao de implementar o modo ldquoutilizador deciderdquo especificando apenas de forma
teorica o modo ldquoaplicacao assume o estado offlinerdquo
As caracterısticas do Gears foram ja descritas na seccao 31 Na Figura 47
mostra-se a sua forma de funcionamento quando integrado numa web application
42
Desenvolvimento
Nesta figura representa-se o modulo LocalServer do Gears como um ponto de de-
cisao Aqui sao testadas as condicoes que determinam se o pedido sera interceptado e
servido localmente ou se prossegue para uma maquina remota E tambem represen-
tada uma base de dados que corresponde ao modulo Database mas que podera nao
ser utilizada Este modulo tal como o modulo Workerpool tem caracter opcional
e sao utilizados consoante os requisitos da aplicacao
A plataforma WOW lida com mais dados do que e necessario passar para o
lado do cliente Em conformidade com o ja exposto na seccao 411 volta-se a
frisar que nao se pretende recriar toda a logica de negocio nem os conteudos da
base de dados no cliente pela sua complexidade e volume de dados Pretende-se
pelo contrario permitir que os utilizadores tirem partido da capacidade de poder
consultar as suas ordens de trabalho quando nao dispoe de uma ligacao transferindo
apenas o essencial para isto seja possıvel
A pagina inicial do WOW apresenta um resumo das ordens de trabalho abertas
ndash enviadas e recebidas ndash que se pretende permitir visualizar offline (ver Figura 46)
Como prova de conceito foi efectuada uma abordagem pragmatica das varias possi-
bilidades descritas na seccao 42
461 Modo ldquoaplicacao deciderdquo com deteccao automatica da ligacao
A primeira abordagem estudada para a disponibilizacao das funcionalidades of-
fline foi o modo ldquoaplicacao deciderdquo com deteccao automatica de ligacao apresentado
na seccao 422 Para que isto seja possıvel foi implementado um mecanismo de ver-
ificacao periodica do estado da ligacao atraves de chamadas Ajax assıncronas O
resultado destes pedidos determina o estado da aplicacao executando as tarefas de
sincronizacao de dados sempre que pertinente Este metodo embora imediato e
simples de implementar depressa se revelou inadequado para o projecto devido ao
elevado consumo de recursos do servidor que a utilizacao intensiva faz esperar a
comunidade da plataforma WOW no principal cliente excede os 7000 utilizadores
Foi estimado que para uma utilizacao de fluidez aceitavel o estado da ligacao deveria
ser testado a cada cinco segundos Assumindo uma adesao (previsao pessimista) de
1 aos servicos offline assistir-se-ia a cerca de 840 pedidos adicionais por minuto
Mas o principal problema desta aproximacao prende-se com o facto de a ver-
ificacao ser feita em intervalos de tempo discretos levando a possibilidade de a
aplicacao poder ter em dado momento uma representacao errada do seu estado
real da ligacao Este problema e ilustrado na Figura 48 onde se ve claramente a
discrepancia entre o estado real da ligacao e a representacao interna que esta tem
Note-se que nesta janela de tempo qualquer accao do utilizador que exija uma
resposta sıncrona do utilizador leva-lo-a para um ldquobeco sem saıdardquo onde nao tera
43
Desenvolvimento
Figura 46 A pagina inicial do WOW apresenta um resumo das ultimas ordens de trabalhoenviadas e recebidas Na imagem pode-se observar a transicao do estado online para offline
acesso a versao offline porque a aplicacao nao fez a transicao automatica nem acesso
a versao online porque na verdade nao possui uma ligacao O que acontecera nesta
situacao sera uma tentativa de acesso ao servidor por parte da aplicacao numa
altura em que este se encontra indisponıvel e o resultado sera uma mensagem de
ldquopedido excedeu o tempordquo apresentado pelo browser Este e um estado sem retorno
porque apos o browser apresentar esta mensagem todos os recursos JavaScript ficam
indisponıveis tornando impossıvel o regresso ao estado anterior ou o tratamento do
erro de qualquer outra forma No entanto as chamadas Ajax podem ser tratadas de
forma especial para a eventualidade de falha e portanto nao constituem problema
44
Desenvolvimento
Figura 47 Ilustracao do funcionamento do Gears numa web application que utiliza ummotor Ajax Os pedidos HTTP ou HTTPS podem ser interceptados e tratados localmenteou podem ser feitos a uma maquina remota consoante se verificarem ou nao as condicoesexpressas no ponto 311 E representado um acesso a uma base de dados local (fornecidapelo Gears) mas a sua utilizacao e opcional
462 Implementacao do modo ldquoutilizador deciderdquo
Este modo de execucao foi ja descrito na seccao 421 e a sua principal carac-
terıstica e ser o utilizador a decidir se a aplicacao deve utilizar um servidor remoto
ou a maquina local como fornecedor de dados
Relativamente ao WOW o WOW Offline na vertente ldquoutilizador deciderdquo vem
alterar os seus casos de uso dando ao utilizador a possibilidade de alterar o estado
de execucao da aplicacao (entre online e offline) Resta dizer que no modo online se
mantem todas as funcionalidades anteriores e que no modo offline torna-se possıvel
visualizar os conteudos da pagina principal do WOW (Figura 46) e os detalhes das
ordens de trabalho (Figura 49) tal como expressa a Figura 410
Esta aproximacao foi utilizada na prova de conceito do WOW adicionando um
controlo a interface desta aplicacao que permite ao utilizador alternar entre os esta-
dos online e offline Na transicao de online para offline sao descarregados os recursos
necessarios para a execucao desta aplicacao sem recorrer a Internet Para o fazer
45
Desenvolvimento
Figura 48 Neste exemplo do modo ldquoaplicacao deciderdquo o teste da ligacao e feito e feito acada cinco segundos O resultado deste teste nao reflecte sempre o estado real da aplicacaopodendo levar a aplicacao a ter comportamentos indesejaveis Na figura assinala-se umperıodo de tempo no qual a representacao interna do estado da ligacao nao corresponde arealidade
e utilizado um recurso ResourceStore e um ManagedResourceStore (introduzidos
em 311) O primeiro e utilizado para armazenar a pagina principal do WOW ndash do-
ravante designada por homejsp ndash e o segundo e utilizado para armazenar imagens
folhas de estilo CSS e scripts JavaScript
Para a implementacao deste modo de execucao foram identificadas as seguintes
tarefas
1 Guardar informacao que permita a recriacao das paginas que se pretende
disponibilizar offline (utilizando o Gears)
2 Disponibilizar um controlo que permita alterar o estado de execucao atraves
da interaccao com a pagina principal
3 Durante a sincronizacao de dados apresentar o progresso da transferencia de
dados
O primeiro passo consistiu na identificacao de todos os conteudos que sao necessarios
transferir para a execucao offline Foi utilizado um recurso do Gears do tipo
ManagedResourceStore que recorre a um ficheiro manifesto para identificar to-
dos os ficheiros que deve transferir Este recurso e gerido automaticamente pelo
Gears transferindo para o cliente a versao mais recente sempre que e necessario
isto e sempre que exista um ficheiro manifesto com uma identificacao de versao que
seja diferente da actualmente disponıvel no cliente Uma vez identificados todos
ficheiros necessarios para a execucao offline num (ou mais) ficheiros manifesto o
Gears encarrega-se da sua actualizacao mas o preenchimento destes ficheiros man-
ifesto e manual o que se traduz num cuidado extra na manutencao da aplicacao
A forma como esta informacao e guardada deve tambem ser cuidadosamente
estudada A opcao mais flexıvel passa por utilizar o modulo Database apresentado
na seccao 311 e guardar a informacao de uma forma relacional Para a recriacao
das paginas pode ser disponibilizada uma versao HTML da pagina que funciona
46
Desenvolvimento
Figura 49 Pagina de visualizacao do detalhe de uma ordem de trabalho
como template nao possui quaisquer dados e e utilizada apenas em modo offline E
preenchida para cada pedido retirando os dados relevantes da base de dados
O modelo de dados do WOW torna esta opcao extremamente trabalhosa uma
vez que as entidades envolvidas na geracao de cada pagina de informacao sobre
cada ordem de trabalho tem relacoes de dependencia complexas seguindo padroes
muito variaveis Por exemplo em cada ordem de trabalho existe um formulario que
permite a sua progressao de estado com diversos campos opcionais e obrigatorios
este formulario e definido pelo administrador e esta relacionado nao apenas com o
tipo de ordem de trabalho mas tambem com o estado actual em que esta se encontra
e a accao que se pretende realizar O elevado numero de combinacoes de tipos de
ordem de trabalho estados e accoes que existem num dado momento juntamente
com a sua possibilidade de alteracao obrigariam a implementacao de uma logica de
negocio complexa o que esta fora do ambito deste projecto
47
Desenvolvimento
Figura 410 Esquema UML que expressa os casos de uso do WOW Offline no modoldquoutilizador deciderdquo
463 Especificacao do modo ldquoaplicacao assume o estado offlinerdquo
A aproximacao para o modo ldquoaplicacao assume o estado offlinerdquo foi tambem
dividida em varias tarefas
1 Guardar informacao que permita a recriacao da pagina principal do lado do
cliente no estado offline (utilizando o Gears)
2 Dotar a aplicacao do cliente de um mecanismo de deteccao da ligacao
3 Identificar os ldquomomentos chaverdquo em que devera ocorrer sincronizacao de dados
4 Implementar a sincronizacao de dados
A sincronizacao de dados deve ser feita em ambas as transicoes online-offline e
offline-online quer para transferir novos dados do servidor (os pedidos podem ser
alterados por outros utilizadores) quando se transita do estado quer para comunicar
eventuais alteracoes feitas em modo offline
Relativamente ao WOW o WOW Offline na vertente ldquoaplicacao assume o es-
tado offlinerdquo vem alterar os seus casos de uso dando ao utilizador a possibilidade
de activar esta funcionalidade A partir do momento que a funcionalidade esta ac-
tivada o utilizador deve tambem ter a possibilidade de gerir algumas preferencias
relacionadas com privacidade de dados Devera ter a hipotese de desactivar o ar-
mazenamento local e de remover todos os dados ja armazenados tal como descrito
na Figura 411
48
Desenvolvimento
Figura 411 Esquema UML que expressa os casos de uso do WOW Offline no modoldquoutilizador deciderdquo
A primeira vez que o WOW Offline e acedido por um cliente e caso seja detec-
tada a presenca do Gears todos os recursos necessarios a sua execucao sao trans-
feridos Todos os acessos posteriores serao feitos a estes recursos locais (recorda-se
que o Gears pode ser utilizado para os manter actualizados recorrendo ao Managed-
ResourceStore 311)
Atraves do JavaScript e possıvel interceptar os eventos de load e unload da
pagina que sao despoletados sempre que ocorre um re-acesso da mesma (incluindo
a accao refresh comum dos browsers) sempre que esta e abandonada ou ainda ou
ainda se a janela for encerrada
Tal como sugerido na seccao 462 a camada de interface desta aplicacao (cada
pagina individual em HTML) devera ser implementada como sendo um template
para apresentacao de dados sendo totalmente preenchida atraves de funcoes em
JavaScript O objectivo deste ponto e criar um padrao de dados que permita ao
JavaScript preencher os dados em cada pagina (template) independentemente de
qual seja a fonte ndash o servidor remoto ou a maquina local tal como exemplificado
no diagrama da Figura 412 Na figura a aplicacao recorre ao servidor remoto para
obter os dados pretendidos quando se encontra na presenca de uma ligacao mas
para dados que exijam uma carga de processamento pelo servidor este acto pode ser
49
Desenvolvimento
Figura 412 Esquema UML que expressa o acto de recolha de dados em modo online eoffline recorrendo ao servidor (modo online) e ao sistema de armazenamento de dadoslocal fornecido pelo Gears (modo offline)
substituıdo pelo envio de um campo de controlo que se destina a aferir se os dados
locais se encontram actualizados No caso de estarem actualizados a comunicacao
com o servidor pode ser substituıda por uma query a base de dados local
50
Capıtulo 5
Resultados e Futuros
Desenvolvimentos
Todo o estudo feito sobre o tema OWA foi ja abordado ao longo do documento
Neste capıtulo apresentam-se os resultados obtidos na implementacao da prova de
conceito que visava compreender a melhor forma de disponibilizar uma versao of-
fline no WOW uma plataforma de gestao de ordens de trabalho ja existente de-
senvolvida pela Critical Software SA
51 Resultados Obtidos
Os resultados obtidos neste projecto sao extremamente satisfatorios uma vez
que o estudo do tema OWA e a implementacao de uma prova de conceito que o
ilustrasse foi conseguido com sucesso
A funcionalidade offline foi adicionada ao produto WOW da Critical Software
SA permitindo a visualizacao de ordens de trabalho e dos seus detalhes mesmo na
ausencia de uma conexao activa a Internet Embora para a solucao implementada
tenha sido utilizada uma abordagem do tipo ldquoutilizador deciderdquo pretende-se que esta
seja convertida para ldquoaplicacao deciderdquo ou mesmo para uma aproximacao hıbrida
semelhante a utilizada pelas aplicacoes estudadas nas seccoes 351 e 352
Para a sua implementacao descrita no capıtulo 4 foram tomadas decisoes de or-
dem pratica que permitissem tornar o trabalho exequıvel nos prazos dados Tentou-
se sempre que estas decisoes afectassem o mınimo em termos de desempenho e de
experiencia para o utilizador Considera-se que a implementacao do modo offline
com uma transicao entre modos do tipo ldquoutilizador deciderdquo (ver seccao 42) reflecte
o compromisso entre o desempenho pretendido e os recursos disponıveis e para alem
51
Resultados e Futuros Desenvolvimentos
de ser um exemplo eficaz das possibilidades que as OWA podem trazer a aplicacao
WOW desenvolvida pela Critical Software e tambem um estudo que pode ser uti-
lizado para analisar a implementacao desta tecnologia noutros produtos da mesma
empresa
Note-se que o principal objectivo do trabalho era ganhar familiaridade com este
tema entender as suas vantagens e desvantagens e compreender as suas limitacoes
Tudo indica que existam varias possibilidades de implementacao deste paradigma
noutros produtos da Critical Software que pela sua natureza podem tambem tirar
partido da execucao offline
52 Trabalho Futuro
O desenvolvimento do conceito e formas de implementacao de OWA continua
em forte desenvolvimento no entanto a sua adopcao ainda nao e generalizada A
dificuldade da sua implementacao em web applications ja existentes e o principal
obstaculo a sua maior divulgacao
Ha tambem um factor que deve ser tido em consideracao a manutencao de
codigo A implementacao de uma versao offline de uma web application requer
a implementacao das mesmas regras de negocio (ou de uma versao simplificada)
utilizadas no servidor Para que isto seja possıvel e necessario ter em conta a
capacidade de processamento do cliente e o factor de duplicacao de codigo que
tornara a aplicacao mais difıcil de manter uma vez que uma alteracao a logica de
negocio do servidor implica tambem uma alteracao a sua versao offline
A prova de conceito implementada permite ja a visualizacao offline dos pedidos
abertos (enviados e recebidos) que constam na pagina principal (este numero e
fixo e pode ser alterado pelo administrador) Uma funcionalidade desejavel seria a
possibilidade de interaccao com a aplicacao em modo offline e sincronizacao com o
servidor quando existisse uma ligacao disponıvel
Foi estudada a utilizacao do modo de execucao ldquoaplicacao assume o estado of-
flinerdquo descrito em 423 e esta seria a forma desejavel para o WOW Offline no
entanto para que esta opcao seja viavel sera necessaria a implementacao de uma
forma eficiente de sincronizacao e armazenamento de dados de uma forma relacional
Para atingir este objectivo podera ser seguida uma polıtica de automacao do pro-
cesso no qual a versao online da aplicacao gera scripts de criacao para as tabelas
necessarias na base de dados da versao offline (nao existe nenhuma ferramenta para
o fazer portanto seria necessaria a sua implementacao) e no qual as paginas HTML
disponibilizadas pelo servidor aos clientes web (browser) servem como templates de
apresentacao de informacao e sao preenchidas de forma semelhante pelo servidor ndash
quando a aplicacao estiver online ndash ou pelo cliente atraves de funcoes em JavaScript
52
Resultados e Futuros Desenvolvimentos
ndash quando a aplicacao estiver offline No entanto no WOW devido a quantidade de
informacao tratada e devido as complexas relacoes entre as diferentes entidades e
de esperar que a complexidade da implementacao de um mecanismo deste tipo torne
esta aproximacao demasiado custosa
O HTML 5 embora um forte candidato ainda nao esta suficientemente desen-
volvido A sua especificacao ainda tem o caracter de Draft (rascunho) e esta sujeita
a modificacoes e a aceitacao e implementacao por parte dos browsers e portanto
de momento foi desconsiderado No entanto no futuro se esta especificacao atingir
um estado de maturidade que permita a sua adopcao devera ser considerada como
um possıvel caminho a seguir
53
Resultados e Futuros Desenvolvimentos
54
Capıtulo 6
Conclusoes
Neste capıtulo sao apresentadas as conclusoes do projecto e consideracoes finais
relativamente a tecnologia estudada
61 Conclusoes
O rapido desenvolvimento tecnologico faz prever que a disponibilidade de ligacao
a Internet seja cada vez mais facil e mais rapido mas vao continuar a existir lugares
onde o acesso e limitado e onde as OWA podem desempenhar um papel de relevo
Por outro lado esta tecnologia pode tambem ser utilizada para melhorar o desem-
penho de paginas web com uma necessidade elevada de imagens ou outros recursos
dispendiosos em termos de espaco e foram ate estudados dois exemplos da utilizacao
desta vertente desta tecnologia em 353
Acredita-se que as OWAs vem responder a uma necessidade real por parte das
web applications actuais e que a evolucao que representam se compara a que se
assistiu dos thin-clients para os fat-clients em termos de autonomia do servidor
A capacidade de oferecer conteudos dinamicos no browser independentemente da
existencia de uma ligacao reune as vantagens tıpicas das web applications como
ausencia de instalacao e actualizacoes instantaneas com as vantagens das aplicacoes
de desktop em capacidade de processamento e armazenamento de dados na maquina
local
As tecnologias disponıveis ate a data estudadas no ambito deste projecto que
permitem o desenvolvimento de OWAs e que apresentam maior maturidade sao o
Gears e o Adobe AIR Ambas se apresentam sobre a forma de plugins que necessitam
de uma instalacao extra para poderem ser utilizadas Apesar de esta instalacao ser
55
Conclusoes
apenas necessaria uma vez podera constituir um factor de desencorajamento a sua
adopcao
O HTML 5 uma especificacao abordada neste documento na seccao 34 podera
ser uma alternativa que oferece funcionalidades offline a uma web application sem a
necessidade de qualquer instalacao no entanto esta especificacao ainda nao foi aceite
pelos principais browsers ndash o documento que define o HTML 5 ainda tem o estatuto
de Draft ndash e ainda nao e possıvel antecipar quando e que isto podera acontecer
Um dos problemas que surge frequentemente na implementacao de uma versao
offline para uma web application e a necessidade de sincronizacao de dados Quando
a informacao pode ser alterada por varios utilizadores simultaneamente e necessario
prever os conflitos que daı podem surgir e dotar a aplicacao de uma forma de os
resolver ou alertar o utilizador para a necessidade de alteracao dos dados
Em conclusao todos os objectivos propostos para este projecto foram atingidos
A prova de conceito implementada reflecte de forma clara as possibilidades oferecidas
pela tecnologia OWA e sera utilizado no futuro para compreender a melhor forma
de o implementar de forma definitiva no WOW
56
Referencias
[Ada08] Lucas Adamski Introducing Adobe AIR security model Fevereiro de2008 Disponıvel em httpwwwadobecomdevnetairarticles
introduction_to_air_securityhtml acedido em Marco de 2008
[Ado08] Adobe Adobe AIR 10 Security White Paper 2008 Disponıvel emhttpdownloadmacromediacompubairdocumentation1air_
securitypdf acedido em Marco de 2008
[Alm08] Dion Almaer Gears as a bleeding-edge html 5 implementa-tion March 2008 Disponıvel em httpalmaercomblog
gears-as-a-bleeding-edge-html-5-implementation acedido emMarco de 2008
[BL96] Tim Berners-Lee The world wide web Past present and future Agostode 1996 Disponıvel em httpwwww3orgPeopleBerners-Lee
1996ppfhtml acedido em Abril de 2008
[CDGH08] Mike Chambers Daniel Dura Dragos Georgita and Kevin Hoyt AdobeAIR for JavaScript Developers OrsquoReilly Media 2008 Disponıvel emhttponairadobecomfilesAIRforJSDevPocketGuidepdf ace-dido em Abril de 2008
[Con99] Jim Conallen Modeling Web Application Architectures with UML Junho1999 Disponıvel em httpwwwumlorgcnUMLApplicationpdf
webappspdf acedido em Maio de 2008
[Ent07] Entrust What is a public key information 2007 Disponıvel em http
wwwentrustcompkihtm acedido em Junho de 2008
[Gar05] Jesse James Garret Ajax A new approach to web applicationsFebruary 2005 Disponıvel em httpwwwadaptivepathcomideas
essaysarchives000385php acedido em Marco de 2008
[Greon] Philip Greenspun Philip and Alexrsquos Guide to Web Publishing 2003(last revision) Disponıvel em httpphilipgreenspuncompandaacedido em Junho de 2008
[Gro02a] App Design Group Thick vs thin client comparison 2002 Disponıvelem httpwwwdonjacobsvwcomimagesweekendspecials
Thick-vs-Thinpdf acedido em Junho de 2008
57
REFERENCIAS
[Gro02b] Technical Research Group Thin Client Tecnhology - WhitePaper 2002 Disponıvel em httpwwwpicktrgcompubs
thinclientwhitepaperpdf acedido em Junho de 2008
[Gro08] Miniwatts Marketing Group World internet usage March 2008Disponıvel em httpwwwinternetworldstatscomstatshtm ace-dido em Abril de 2008
[Hic08] Ian Hickson HTML 5 Draft Recommendation 2008 Disponıvelem httpwwwwhatwgorgspecsweb-appscurrent-work ace-dido em Marco de 2008
[Kha] Olga Kharif Top 10 municipal wifi plans Disponıvel em http
imagesbusinessweekcomss0608muni_wifiindex_01htm ace-dido em Marco de 2008
[Lab07] Mozilla Labs Prism Outubro 2007 Disponıvel em httplabs
mozillacom200710prism acedido em Marco de 2008
[Loo06] Chris Loosley Rich Internet ApplicationsDesign MeasurementandManagement Challenges 2006 Disponıvel em httpwwwkeynote
comdocswhitepapersRichInternet_5pdf acedido em Maio de2008
[Mic08] Microsoft Introduction to Occasionally Connected Applications us-ing Sync Services for ADONET 2008 Disponıvel em httpmsdn
microsoftcomen-ussyncbb887608aspx acedido em Junho de2008
[Nao08] Erica Naone Offline web applications Abril 2008 Disponıvelem httpwwwtechnologyreviewcomread_articleaspxch=
specialsectionsampsc=emerging08ampid=20245 acedido emAbril de 2008
[NJN00] Jason Nieh Yang S Jae and Naomi Novik A comparison of thin-clientcomputing architectures 2000 Disponıvel em httpwwwnclcs
columbiaedupublicationscucs-022-00pdf acedido em Maio de2008
[OrsquoR06] Tim OrsquoReilly Web 20 compact definition Trying again Dezembro2006 Disponıvel em httpradaroreillycomarchives200612
web-20-compact-definition-tryihtml acedido em Marco de 2008
[OrsquoR09] Tim OrsquoReilly What is Web 20 Design patterns and business modelsfor the Next Generation of Software 20053009 Disponıvel emhttpwwworeillynetcompubaoreillytimnews200509
30what-is-web-20html acedido em Marco de 2008
[Rus06] Alex Russel Comet Low latency data for the browser March Marco2006 Disponıvel em httpalexdojotoolkitorgp=545 acedidoem Marco de 2008
58
REFERENCIAS
[Sad97] Darleen Sadoski Clientserver software architecturesndashan overviewAgosto 1997 Disponıvel em httpwwwseicmuedustr
descriptionsclientserver_bodyhtml acedido em Junho de2008
[Sch96] George Schussel Clientserver past present and future 1996
[Smi07] Kevin C Smith Css filters - will the browser apply the rule July 2007Disponıvel em httpcentriclecomrefcssfilters acedido emMarco de 2008
[vK08] Anne van Kesteren The XMLHttpRequest Object W3C Work-ing Draft 15 Abril 2008 Disponıvel em httpwwww3orgTR
XMLHttpRequest acedido em Abril de 2008
[Wil06] Greg Wilkins Why ajax comet July Julho 2006 Disponıvel emhttpwwwwebtidecomdownloadswhitePaperWhyAjaxhtml ace-dido em Abril de 2008
59
REFERENCIAS
60
Anexo A
Screenshots
Algumas imagens de aplicacoes que utilizam funcionalidades offline ilustrativasda tecnologia abordada neste documento
Figura A1 Dialogo apresentado ao utilizador na primeira activacao das funcionalidadesoffline no Google Docs amp Spreadsheets
61
Screenshots
Figura A2 Na activacao das funcionalidades offline e tambem oferecida a possibilidadeda criacao de alguns atalhos por exemplo no ambiente de trabalho
Figura A3 O Google Docs mantem a todo o momento a possibilidade de alteracao destasdefinicoes ou da anulacao dos servicos offline para um dado computador
62
Screenshots
Figura A4 Apos a instalacao do Gears qualquer visita ao Remember The Milk despoletauma sincronizacao que ocorre automaticamente e sem necessidade de intervencao por partedo utilizador
Figura A5 Apos completar a sincronizacao de dados mesmo que a ligacao a Internetseja perdida o Remember the Milk continua disponıvel no browser (com excepcao dasfuncionalidades que pela sua natureza exigem uma ligacao como por exemplo partilhade tarefas e envio de convites)
63
LISTA DE TABELAS
xii
Glossario
fat-client Cliente que nao depende totalmente de umservidor central para as suas actividadesde processamento e possui frequentementedispositivos de armazenamento de dados
6ndash8
thin-client Cliente que depende de um servidor centralpara as suas actividades de processamento
5ndash8
web application Sistema web (servidor rede HTTPbrowser) onde accoes do utilizador(navegacao e introducao de informacao)afectam o estado logico da aplicacao
i iii1ndash311ndash1517ndash1921ndash232728 3336ndash3842 5556
API Application Programming Interface 10 1718 2326 28
ASP Linguagem interpretada pelo servidorque permite a criacao de paginas webdinamicas Desenvolvida pela Microsoft
11
BSD Berkeley Software Distribution 28
CSS Cascading Style Sheets 12 2021 2324 46
DHTML Dynamic HyperText Transfer Protocol 24DOM Document Object Model 10 12
20 2324
DTD Document Type Definition 24
xiii
Glossario
ECMAScript Padrao de linguagem de programacaodefinido pela Ecma International que orig-inou o JavaScript e o JScript
24
Flash Conteudo interactivo de um ficheiro emformato SWF E desenvolvido pela Adobee visualizado atraves do Adobe FlashPlayer
21
Flex Framework baseada em XML e Action-Script desenvolvida pela Adobe para a pro-gramacao de Rich Internet Applications(RIA)
21
GPL GNU General Public License 23
HTML HyperText Markup Language 1 10ndash12 2124ndash2649
HTTP HyperText Transfer Protocol 2 26
JMS E uma API em Java que permite a troca demensagens entre componentes de software
42
JSON JavaScript Object Notation permite atroca de dados codificados num formatode texto de simples leitura
12 1828 34
LGPL GNU Lesser General Public License 23
Mozilla Prism Browser simplificado e ldquointerpretadorrdquo deeXtensible User Interface Language (XUL)(tambem designado por XULRunner) queacolhe web applications sem a interfacegrafica habitual de um browser
25
MPL Mozilla Public License 23
OCA Occasionally Connected Application 39OWA Offline Web Application i iii
2ndash515 1725 2628 3133 3651 5255 56
PDF Portable Document Format 21
xiv
Glossario
PHP Linguagem interpretada pelo servidorque permite a criacao de paginas webdinamicas mas que pode tambem ser in-vocada a partir da linha de comandos
11
pagina web estatica Pagina web que devolve sempre a mesmaresposta a todos os pedidos para todos osutilizadores e em qualquer contexto
5 9
RIA Rich Internet Applications web appli-cations que apresentam funcionalidadessemelhantes as desktop applications masque mantem a informacao no lado do servi-dor
5 1520 28
RSS Really Simple Syndication 27
SLA Service Level Agreement 40SQLite Segundo a definicao oficial SQLite is a
software library that implements a self-contained serverless zero-configurationtransactional SQL database engine
17
SSB Site Specific Browser 25SSL Secure Sockets Layer 22SWF ShockWave Flash 21
URL Uniform Resource Locator 18
VPN Virtual Private Network 38
WOW Work Orders Web Plataforma de gestaode ordens de trabalho e do seu fluxo de-senvolvida pela Critical Software SA
i iii28 3340ndash434551ndash5356
WWW World Wide Web 11 1214
XBL eXtensible Binding Language 24XHTML eXtensible HyperText Markup Language 12XML eXtensible Markup Language 11 12
23 2428
XSLT eXtensible Stylesheet Language Transfor-mation
12
XUL eXtensible User Interface Language xiv23ndash25
xv
Glossario
xvi
Capıtulo 1
Introducao
Neste capıtulo enquadra-se o tema do projecto introduzindo alguns dos conceitos
nos quais se baseia Apresentam-se as motivacoes ambito objectivos e a estrutura
deste documento
11 Enquadramento
A Internet foi originalmente concebida para ser um espaco de partilha de in-
formacao onde pessoas (atraves de maquinas) pudessem comunicar Na sua origem
as paginas eram estaticas constituıdas por texto formatado em HyperText Markup
Language (HTML) e ligadas entre si [BL96] Hoje encontramos conteudos cada vez
mais complexos e dinamicos incluindo som vıdeo ou streams multimedia [Loo06] e
em 2005 foi introduzido por [OrsquoR09] o termo Web 20
De acordo com [Greon] um website pode pertencer a uma ou varias das seguintes
categorias
bull Documento ndash um website essencialmente estatico onde alteracoes a uma
parte do conteudo nao tem implicacoes no seu comportamento
bull Base de dados ndash um directorio de informacao organizada em categorias
bull Aplicacao ndash um website dinamico que utiliza uma linguagem executada ou
interpretada do lado do servidor e que processa as accoes ou informacao in-
troduzida pelo utilizador para fornecer um servico ou nova informacao
A ultima destas categorias constitui aquilo que e normalmente designado por
web application O conceito utilizado ao longo deste documento e o mesmo que
o introduzido por Jim Coallen em [Con99] que define web application como um
1
Introducao
sistema web (servidor rede HyperText Transfer Protocol (HTTP) browser) onde
accoes do utilizador (navegacao e introducao de informacao) afectam o estado logico
da aplicacao A sua definicao tenta estabelecer que uma web application e um
sistema de software com estado de negocio1 e que a sua interface de interaccao com
o utilizador e distribuıdo atraves de um sistema web
12 Motivacao
A quantidade de informacao que e produzida e armazenada com recurso a es-
tas web applications disponıveis online tais como e-mail blogues ou mesmo docu-
mentacao tornam por vezes a disponibilidade de ligacao uma condicao necessaria
a produtividade e como consequencia desta barreira muitos potenciais utilizadores
opoem-se a adopcao de produtos web em detrimento das tradicionais desktop appli-
cations
Assegurar o acesso a uma ligacao de Internet e hoje muito mais facil A Internet
movel e ja uma realidade e encontra-se amplamente divulgada mas continuam a
existir diversas situacoes nas quais os utilizadores estao privados de uma ligacao
a Internet tais como uma viagem de metro ou de aviao ou quando se encontram
deslocados do seu paıs de origem e nao possuem nenhum plano de subscricao
Uma OWA consiste numa web application que para alem de manter todas as
caracterısticas anteriores se mantem disponıvel mesmo na ausencia de uma ligacao
a Internet e surge como uma tentativa de estreitar as barreiras existentes entre a
web e o desktop Isto significa que devera existir um mecanismo capaz de assegurar
a manutencao do estado logico da aplicacao quando a ligacao com o servidor e
quebrada permitindo ao utilizador continuar a utilizar a aplicacao e que sera capaz
de informar o servidor do estado em que a aplicacao se encontra quando a ligacao for
reposta A principal vantagem que advem desta possibilidade e evidente eliminar
a necessidade da existencia de uma ligacao a Internet para que a aplicacao possa ser
utilizada
Por outro lado a vontade de integracao de funcionalidades tıpicas das desktop
applications nas web applications foi um dos principais factores que impulsionou o
desenvolvimento deste conceito uma vez que obrigou a uma reflexao ldquopara alem
do browserrdquo e a uma adaptacao das arquitecturas existentes que permitisse ou o
acesso a funcionalidades disponibilizadas pelo sistema operativo ou pelo menos a
funcionalidades semelhantes Pretende-se com esta aproximacao tornar possıveis
interaccoes entre o desktop e o browser tais como arrastar um ficheiro para um
formulario web de upload de conteudos melhor suporte para o historico do clipboard
ou ainda o acesso ao sistema de ficheiros local Atingir estes objectivos reflecte-se
1NT business state
2
Introducao
num novo paradigma que reune as vantagens das web applications tais como os
updates instantaneos ou o facto de nao ser necessaria nenhuma instalacao e das
desktop applications como por exemplo persistencia no armazenamento de dados
acesso a funcionalidades do sistema operativo ou integracao e interaccao com outras
aplicacoes sejam elas web applications ou desktop applications
13 Ambito
Este projecto foi realizado na Critical Software SA no ambito do Mestrado
Integrado em Engenharia Informatica e Computacao (MIEIC) da Faculdade de En-
genharia da Universidade do Porto (FEUP) entre os meses de Fevereiro e Julho de
2008
14 Objectivos
Sao objectivos deste projecto
1 Estudar e documentar o tema das OWAs acompanhando os ultimos desenvolvi-
mentos nesta materia
2 Analisar o estado da arte fazendo uma analise crıtica e objectiva sobre as
diversas metodologias existentes
3 Implementar uma prova de conceito que permita a execucao offline de uma
web application documentando todo o processo
4 Estudar a possibilidade de permitir interaccao com a aplicacao (insercoes e
alteracoes aos dados) em modo offline
Em resumo o objectivo deste projecto foi estudar documentar e implementar
uma prova de conceito relacionada com o tema Offline Web Applications (OWA)
Este tema embora nao seja totalmente novo ganhou destaque ao longo do ano de
2007 com o surgimento de diversas ferramentas que se destinam a aproximar web
applications das desktop applications
15 Estrutura do documento
Este documento esta organizado em diferentes seccoes apresentando o projecto
numa sequencia logica organizada da seguinte forma
No capıtulo 1 faz-se uma breve apresentacao do conceito OWAs e do contexto em
que surge Apresenta-se tambem a estrutura do documento e definem-se os
termos e acronimos utilizados
3
Introducao
No capıtulo 2 faz-se uma descricao da evolucao das tecnologias que antecedem as
OWAs e das vantagens e desvantagens de cada uma como forma de enquadra-
mento
No capıtulo 3 analisa-se o estado da arte nesta materia Introduzem-se diversas
tecnologias directamente relacionadas com o tema deste projecto exemplos de
aplicacoes que as usam e as razoes que fundamentam as escolhas de tecnologias
efectuadas
O capıtulo 4 contem o desenvolvimento do projecto Analisa-se a plataforma
WOW de gestao integrada de ordens de trabalho a tecnologia escolhida e
a forma como foi utilizada para implementar a capacidade de execucao offline
O capıtulo 5 descreve os resultado obtidos comparando-os com as expectativas
iniciais do projecto e apresenta desenvolvimentos futuros e possibilidades de
continuacaoaplicacao do conhecimento adquirido
No capıtulo 6 apresentam-se as conclusoes
4
Capıtulo 2
Enquadramento do Projecto
Neste capıtulo apresenta-se um breve resumo da evolucao das arquitecturas de
software cliente-servidor e a forma como estas se comparam a evolucao da Inter-
net procurando estabelecer uma analogia entre o percurso de ambas as tecnolo-
gias Compara-se o comportamento e arquitectura dos thin-clients as paginas web
estaticas a evolucao dos fat-clients as paginas interactivas Web 20 e Ajax e
defende-se que as OWA constituem um proximo passo logico e evolutivo aproxi-
mando a web do desktop Referem-se ainda os principais factores que justificam a
importancia das OWAs e a estreita relacao que tem com as Rich Internet Application
(RIA)s
21 Evolucao das arquitecturas de software
Os termos thin-client e fat-client sao utilizados quer para descrever arquitecturas
logicas (de software) quer para descrever arquitecturas fısicas (de hardware) Neste
capıtulo excepto quando seja dada indicacao em contrario estes termos referem-se
sempre a uma arquitectura logica
Adicionalmente quando se trata de arquitecturas cliente-servidor pode-se estu-
dar a arquitectura desenvolvida do sistema como um todo da arquitectura do servi-
dor ou da arquitectura do cliente Para evitar equıvocos em especial na seccao 213
especifica-se em cada caso qual o sistema estudado
211 Thin-clients
Um thin-client e um computador cliente ou software cliente que no contexto
de uma arquitectura cliente-servidor depende de um servidor central para as suas
5
Enquadramento do Projecto
actividades de processamento e proporciona um canal de entrada e saıda de in-
formacao entre o utilizador e o servidor remoto Este termo quando aplicado a
hardware refere-se habitualmente a um computador que se destina a ser utilizado
como cliente de rede sem armazenamento local e com capacidade de processamento
reduzida [Gro02b] mas o conceito que aqui se analisa refere-se a uma arquitectura
de software que remonta ao inıcio das aplicacoes cliente-servidor
No inıcio da historia da computacao terminais ligavam-se directamente a main-
frames responsaveis por todo o processamento Nesta arquitectura era necessario
desenvolver duas aplicacoes distintas uma aplicacao central no servidor (main-
frame) responsavel pela gestao de toda a informacao e por todas as operacoes de
comunicacao e uma aplicacao de visualizacao instalada no cliente (terminal) O
papel destes terminais era apenas disponibilizar ao utilizador um meio de comu-
nicacao (entrada e saıda) e apresentacao dos resultados do servidor Nao tinham
um papel activo no calculo nem na logica de negocio e frequentemente nao tinham
tambem nenhum mecanismo de armazenamento de dados
Como vantagens esta arquitectura apresenta uma reduzida necessidade de con-
figuracao e manutencao do lado do cliente Uma vez que o centro do processamento
e manipulacao de dados ocorre no servidor existe tambem uma centralizacao da
informacao [NJN00] que introduz um ponto crıtico de falha1 Actualizacoes e novas
funcionalidades sao faceis de distribuir uma vez que requerem apenas alteracoes no
servidor [Gro02a]
212 Fat-clients
Contrastando com os thin-clients nesta arquitectura os clientes implementam
ja uma parte da logica de negocio e sao responsaveis pelo processamento de dados
Estes fat-clients vieram responder a necessidade crescente de aplicacoes com um
nıvel de interactividade e capacidade de configuracao maior que as oferecidas pela
arquitectura thin-client descrita na seccao 211 Apesar de manterem a sua de-
pendencia do servidor podem tambem ser executados sem uma conexao activa uma
vez que dispoe de armazenamento de dados local o que lhes confere a capacidade
de persistencia de dados e do estado de execucao entre cada sessao
Foi disponibilizando este controlo sobre o estado da aplicacao bem como acesso
a recursos locais (por exemplo sistema de ficheiros e perifericos) que surgiram as
primeiras verdadeiras desktop applications No entanto cada cliente tinha que ser
separadamente instalado no computador pessoal de cada utilizador que pretendesse
utilizar ou interagir com a aplicacao e uma actualizacao ao servidor implicava in-
variavelmente uma actualizacao manual tambem no cliente Uma vez que nem todos
1NT single point of failure
6
Enquadramento do Projecto
Thin-clients Fat-clientsNao toma parte no processamento dedados nem possui acesso ao sistema deficheiros
Participa activamente no processa-mento de dados recorrendo ao sis-tema de armazenamento local para ar-mazenamento de dados
Nao mantem registo do estado logicoda aplicacao entre duas sessoes de uti-lizacao
O acesso ao armazenamento localpermite-lhe manter registo do estadologico da aplicacao entre duas sessoes
O thin-client nao necessita de qualquerinstalacao estando ldquopronto a utilizarrdquo
E geralmente necessario instalar aaplicacao para poder interagir com oservidor
Qualquer update no servidor reflecte-seimediatamente por todos os clientes
Embora a aplicacao cliente possa aler-tar para existencia de novas versoes asactualizacoes tem que ser manualmenteinstalados pelo cliente
O software do cliente destina-se apenasa apresentacao de dados e comunicacaocom o servidor sendo portanto de sim-ples implementacao
Como o software do cliente toma parteactiva no processamento de dadosa sua implementacao requer cuidadosadicionais
Grande mobilidade uma vez que todaa informacao e mantida no servidor
Parte da informacao podera estar ape-nas do lado cliente pelo que existemalgumas restricoes a sua mobilidade
Tabela 21 Comparacao entre thin-clients e fat-clients
os utilizadores actualizam regularmente as suas aplicacoes o servidor tem que estar
preparado para lidar com versoes antigas2 ou descontinuar os seus servicos a uma
parte da sua comunidade de utilizadores ate que estes actualizem os seus sistemas
Como os utilizadores passam a utilizar os seus recursos locais para armazenamento
de dados as alteracoes que nao sejam sincronizadas com o servidor estao apenas
disponıveis nos seus computadores pessoais o que introduz uma restricao a mobili-
dade
Pode-se afirmar que as vantagens dos thin-clients sao as desvantagens dos fat-
clients e que as vantagens dos fat-clients sao as vantagens dos thin-clients tal como
se ilustra na Tabela 21
213 Arquitecturas cliente-servidor
Introduzidos os termos thin-client e fat-client interessa reafirmar que ambos
podem ser vistos como arquitecturas cliente-servidor Um cliente define-se como
um solicitador de servicos e um servidor como um prestador de servicos tal como
definido por [Sch96] e [Sad97]
2NT backward compatibility
7
Enquadramento do Projecto
As arquitecturas cliente-servidor sao categorizadas pela modularizacao com que
sao desenhadas sendo consideradas as seguintes camadas
1 Interface grafica (front-end) atraves da qual os utilizadores interagem com
a aplicacao Quando este modulo e implementado separadamente dos outros
dois constitui uma aplicacao thin-client por si so uma vez que nao implementa
regras de negocio (embora possa definir validacoes de formularios de insercao de
dados por exemplo) A informacao introduzida pelo utilizador e enviada para
o servidor que processa o seu pedido e retorna uma resposta Este processo
repete-se ate que o utilizador atinja o seu objectivo ou se desligue do sistema
2 A logica de negocio tambem designada por camada intermedia que imple-
menta as regras de aceitacao e validacao de todos os dados introduzidos pelo
utilizador E tambem a plataforma de comunicacao que une a camada superior
de visualizacao com a camada de acesso a dados
3 A camada de dados inclui quer o sistema de persistencia de dados onde sao
armazenados os dados relevantes como tambem os mecanismos necessarios
para a sua pesquisa seleccao e alteracao
Os thin-clients quando observados no seu conjunto de cliente e servidor podem
ser vistos quer como sistemas de duas camadas quer como sistemas de tres camadas
dependendo apenas da forma como o servidor for implementado No caso de na
implementacao do servidor nao se distinguir a camada de acesso a dados da camada
da logica de negocio sao designados por sistemas de duas camadas Caso seja feita
esta distincao sao designados por sistemas de tres camadas Ambos os casos sao
ilustrados na Figura 21
Historicamente os fat-clients eram implementados numa arquitectura em duas
camadas Possuıam apenas um modulo de visualizacao de dados designado por
camada de interface e um modulo que implementava toda a logica de negocio e
regras de acesso a base de dados No entanto com a introducao de ligacoes mais
rapidas e de computadores pessoais com maior capacidade de processamento e so-
bretudo devido a complexidade crescente das aplicacoes a logica de negocio e a
camada de acesso a dados tornaram-se independentes Este modelo e designado por
arquitectura em tres camadas e e ilustrado na Figura 22
22 Evolucao na Internet
Ao analisar a evolucao das arquitecturas das aplicacoes desenvolvidas para a
Internet podemos encontrar um paralelismo com a historia da arquitectura de soft-
ware
8
Enquadramento do Projecto
Figura 21 Arquitectura de um sistema thin-client em duas camadas (a esquerda) e emtres camadas (a direita) Note-se a inclusao do servidor (mainframe) na definicao dascamadas desta arquitectura devido a forte dependencia cliente-servidor
221 Paginas web estaticas
Uma pagina web estatica devolve sempre a mesma resposta a todos os pedidos
para todos os utilizadores e em qualquer contexto utilizando o hipertexto como
forma de ligacao entre diversas paginas estaticas
A informacao e armazenada num servidor e o papel do cliente e apenas a apre-
sentacao da informacao Esta forma de disponibilizacao de informacao pode assim
ser comparada com os thin-clients descritos na seccao 211 o utilizador acede a
um website estatico para visualizar informacao sem que o cliente tome parte no
processamento A unica diferenca e que no caso da web estatica a informacao ap-
resentada e sempre a mesma enquanto que nos thin-clients era frequente existir a
possibilidade de insercao de dados no cliente e apos o seu processamento servidor
nova informacao poderia ser apresentada O hipertexto e utilizado para ligar as
paginas entre si numa rede de conteudos relacionados e a navegacao sıncrona era
feita atraves de cliques do rato a cada clique uma nova pagina era apresentada
Este modelo sıncrono e ilustrado na Figura 23
222 Paginas web interactivas e paginas web dinamicas
O JavaScript e uma linguagem interpretada de scripting que tem os browsers
como principal ambiente de acolhimento Os browsers utilizam uma Application
9
Enquadramento do Projecto
Figura 22 Arquitectura de um fat-client em duas camadas (a esquerda) e em tres camadas(a direita)
Programming Interface (API) publica para criar ldquoobjectosrdquo responsaveis por reflectir
e disponibilizar o Document Object Model (DOM) para o motor de JavaScript
A utilizacao mais frequente desta linguagem e a escrita de funcoes que sao em-
bebidas ou incluıdas em paginas web e que interagem com o DOM Uma vez que o
JavaScript e executado localmente (na maquina do cliente e nao no servidor) e capaz
de responder rapidamente a accoes do utilizador tornando a execucao de aplicacoes
no browser mais fluıdas o JavaScript pode tambem detectar accoes do utilizador
que o HTML nao pode tal como o pressionar de uma tecla
Em Dezembro de 1995 a Netscape Communications adicionou suporte para o
JavaScript no browser Netscape Navigator3 e em Agosto de 1996 o browser Internet
Explorer4 da Microsoft passou a tambem a suportar uma versao semelhante desta
linguagem (hoje todos os principais browsers suportam esta tecnologia)
Esta inovacao permitiu tornar os websites mais interactivos mas a sua utilizacao
esteve confinada apenas a este proposito durante um longo perıodo As paginas
passaram a responder activamente a accoes do utilizador (sendo uma das utilizacoes
3Netscape Communications ndash httpbrowsernetscapecom4Microsoft Internet Explorer ndash httpwwwmicrosoftcomwindowsproductswinfamilyie
10
Enquadramento do Projecto
mais vulgares a validacao de formularios) mas continuaram essencialmente estaticas
O JavaScript ainda nao era nesta altura utilizado para processar dados
Tambem nesta altura (1995ndash96) surgiram linguagens server-side como o PHP
Hypertext Preprocessor (PHP) e Active Server Pages (ASP) e o servidor passou a ter
um processamento de dados introduzidos pelo utilizador mais activo Generalizaram-
se as paginas dinamicas capazes de responder a insercao de dados ou outros pedidos
determinados por accoes do utilizador As paginas tornaram-se aplicacoes web ap-
plications
Uma definicao tradicional de web application e um conjunto de paginas web
logicamente agrupadas e geridas por uma unica entidade que tem como pontos de
entrada formularios de insercao de dados (web forms) Uma web application nao e
mais do que uma aplicacao que e acedida atraves de um browser Tem geralmente
uma arquitectura logica em tres (interface logica de negocio e camada de dados)
camadas e estao armazenadas num servidor
Ha dois tipos de web applications
bull Orientadas a apresentacao Sao web applications que geram paginas web in-
teractivas constituıdas por varios tipos de linguagens de anotacao (por exem-
plo HTML eXtensible Markup Language (XML)) e que apresentam conteudo
dinamico como resposta a pedidos efectuados pelo utilizador
bull Orientadas aos servicos Uma web application orientada aos servicos imple-
menta o ponto de acesso para um ou mais de um web service Sao geralmente
clientes de service oriented web applications
Uma vantagem significativa de implementar uma web application de forma a
suportar as funcionalidades padrao dos browsers e que estas terao o mesmo com-
portamento independentemente da plataforma e do browser a partir do qual serao
acedidas No entanto diferentes implementacoes de browsers devido a diferentes
interpretacoes dos padroes definidos tornam por vezes esta tarefa um pouco mais
complicada existindo inclusivamente na web guioes de compatibilidade para os difer-
entes browsers como [Smi07]
223 Web 20 e Ajax
O termo web 20 descreve uma tendencia de utilizacao e de design observada
na World Wide Web (WWW) com o objectivo de melhorar a criatividade partilha
de informacao e principalmente a colaboracao entre utilizadores Estes conceitos
levaram ao desenvolvimento e evolucao de comunidades online tais como redes so-
ciais wikis e blogues
11
Enquadramento do Projecto
O termo tornou-se mais conhecido apos a primeira conferencia OrsquoReilly Media
Web 20 em 2004 e apesar de sugerir uma nova versao da WWW nao se refere a
qualquer evolucao tecnologica mas apenas a alteracoes a forma como os utilizadores
se servem da web De acordo com Tim OrsquoReilly [OrsquoR06] ldquoWeb 20 e uma revolucao
na industria do software causada pela adopcao da web como uma plataforma e pela
tentativa de entendimento das regras para o sucesso nesta nova plataformardquo
O desenvolvimento da Web 20 serve-se muitas vezes de um outro conceito Ajax
O conceito que hoje conhecemos como Ajax muitas vezes incorrectamente de-
scrito como uma tecnologia foi originalmente criado para permitir o desenvolvimento
de web applications que se assemelhassem ainda mais a aplicacoes de desktop Este
conceito foi melhor descrito por [Gar05] como um conjunto de varias tecnologias
que podem ser utilizadas para melhorar a experiencia do utilizador de uma dada
web application introduzindo a capacidade assıncrona de envio de pedidos ou da
recepcao assıncrona de respostas As tecnologias mais frequentemente envolvidas
sao
bull eXtensible HyperText Markup Language (XHTML) e Cascading Style Sheets
(CSS) padrao para a apresentacao
bull interaccao dinamica atraves do DOM
bull troca e manipulacao de dados utilizando XML e eXtensible Stylesheet Lan-
guage Transformation (XSLT) ou JavaScript Object Notation (JSON)
bull pedidos assıncronos utilizando XMLHttpRequest [vK08]
bull JavaScript utilizado para integrar todas estas tecnologias
E importante frisar que o Ajax nao e um produto nem uma tecnologia E um
termo que descreve a utilizacao de um conjunto de tecnologias para o desenvolvi-
mento de web applications com um elevado grau de interactividade Comparativa-
mente as web applications tradicionais o Ajax introduz uma camada de visualizacao
diferente em tres importantes pontos
1 Do lado do cliente existe um motor que serve de intermediario entre a interface
da aplicacao e o servidor
2 A actividade do utilizador despoleta chamadas JavaScript em vez de um pedido
de pagina directamente ao servidor
3 Informacao codificada em XML em vez de paginas HTML e trocada entre o
servidor e o cliente
12
Enquadramento do Projecto
Isto significa que as paginas que utilizam Ajax contem um motor do lado do
cliente composto por um conjunto de funcoes JavaScript responsavel pela comu-
nicacao com o servidor e por actualizar a interface com o resultado dessa mesma
comunicacao
Na Figura 23 ilustra-se a natureza assıncrona do Ajax quando comparada com
as web applications tradicionais Como se pode observar adicionando um mecan-
ismo Ajax a uma web application eliminam-se diversos tempos de espera associados
a comunicacoes com o servidor uma vez que a interface nao fica ldquobloqueadardquo a es-
pera da resposta Obtem-se assim aplicacoes com um comportamento mais fluido
eliminando tempos de espera entre cada ldquocliquerdquo e melhorando a experiencia do
utilizador
23 Offline Web Applications
A informacao grafica (bem como folhas de estilo e scripts) tais como as ima-
gens que constituem o visual de uma web application e ja tratada de forma especial
pelos cada vez mais avancados sistemas de cache (armazenamento temporario) dos
browsers Mas estes nao sao ainda capazes de guardar conteudo criado pelo uti-
lizador nem de apresentar informacao independentemente do estado da ligacao
Numa altura onde se fala de servicos de Internet wireless municipalizados [Kha]
comunicacoes 3G e ligacoes de banda larga a alta velocidade a ligacao a rede global
continua a nao estar permanentemente disponıvel para os utilizadores Na WWW
encontra-se uma importante parte da informacao e das aplicacoes utilizadas para
criar e editar conteudos Por vezes informacao vital para a produtividade pode
desaparecer subitamente do mapa de acesso de um utilizador quando este entra no
metro num aviao ou mesmo quando se desloca para uma cidade ou paıs diferente
do habitual onde nao subscreve um plano de acesso que lhe garanta a ligacao
Permitir o acesso offline a estes recursos assume assim a sua importancia porque
permitira estender o alcance da informacao a locais onde nunca esteve antes e per-
mitira tambem melhorar o desempenho das web applications colocando informacao
mais perto dos utilizadores reduzindo a transferencia de dados apenas ao essencial
24 Comparacao
Nas evolucoes descritas neste capıtulo 2 pode-se observar que existe um par-
alelismo entre a evolucao das arquitecturas tradicionais cliente-servidor e a evolucao
a que se assiste na web O comportamento e arquitectura dos thin-clients assemelha-
se ao das paginas estaticas no sentido em que o browser nao toma parte em qualquer
13
Enquadramento do Projecto
processamento e serve apenas como uma plataforma de interaccao com o servidor
tal como os clientes descritos na seccao 211
A sua proxima evolucao os fat-clients trouxeram parte da capacidade de pro-
cessamento para o lado do cliente Na web foi tambem esta a inovacao tecnologica
a que se assistiu com a evolucao das tecnologias que permitiram a criacao de ver-
dadeiras aplicacoes e com a introducao do Javascript no browser dando ao cliente
a capacidade de processamento de dados A necessidade da separacao do codigo
em camadas logicas advem da crescente complexidade das web applications Esta
pratica permite entre outras coisas melhorar o processo de desenvolvimento e a
capacidade de manutencao de uma aplicacao
Os fat-clients tem tambem a capacidade de armazenamento de dados o que
permite a persistencia de informacoes entre duas sessoes e que algumas operacoes
sejam executadas sem a necessidade de comunicacao com o servidor Este facto pode
tambem ser uma realidade nas web applications com a adopcao das tecnologias OWA
Neste momento assiste-se a uma utilizacao cada vez maior da web como uma
plataforma de desenvolvimento A capacidade de cooperacao na edicao de conteudos
e a mobilidade proporcionada por esta plataforma sao os principais factores que
alimentam esta mudanca e pela primeira vez as aplicacoes tradicionais tem com-
peticao vinda de web applications A prova do reconhecimento da web como plataforma
de desenvolvimento pode ser retirada da aposta de empresas como a Adobe e Mi-
crosoft que lancaram publicamente ferramentas web complementares a produtos
seus tradicionalmente associados ao desktop ndash Acrobatcom5 e Microsoft Office
Live6 Dotar estas web applications da capacidade de execucao offline significa
aproximar a web e o desktop reunindo ldquoo melhor de dois mundosrdquo
As vantagens da mobilidade possıvel atraves da web a cooperacao na criacao e
edicao de conteudos e a possibilidade de utilizar aplicacoes sempre actualizadas e
sem necessidade de instalacao sao algumas das principais vantagens que promovem
esta mudanca que devido as preocupacoes associadas a usabilidade e experiencia do
utilizador esta fortemente associada ao desenvolvimento de Rich Internet Applica-
tion (RIA)s
5Adobe Acrobatcom httpwwwacrobatcom6Microsoft ndash httpsmallbusinessofficelivecom
14
Enquadramento do Projecto
Figura 23 Comparacao do modelo de web aplications sıncrono paginas estaticas e in-teractivas abordados nas seccoes 221 e 222 com o modelo de web applications Ajax(assıncrono) abordado na seccao 223 Figura adaptada de http www adaptivepath
com
15
Enquadramento do Projecto
16
Capıtulo 3
Estado da arte
Apesar de o conceito das OWAs nao ser absolutamente novo as tecnologias que
o suportam sao recentes Neste capıtulo descrevem-se quatro tecnologias que foram
tidas como principais candidatas para o desenvolvimento deste projecto Descrevem-
se ainda alguns exemplos de web applications que disponibilizam actualmente fun-
cionalidades offline e o processo da escolha da tecnologia a utilizar neste projecto
31 Gears
O Gears1 e uma extensao as funcionalidades do browser introduzido pelo Google
que tem como principal objectivo tornar possıvel a visualizacao de paginas de Inter-
net mesmo sem uma conexao disponıvel Encontra-se disponıvel para as platafor-
mas Windows Macintosh e Linux e oferece uma API de Javascript que permite
a scripts aceder a um mecanismo de armazenamento local baseado numa base de
dados SQLite
311 Arquitectura
Esta ferramenta e constituıda por tres componentes principais
bull LocalServer mdash Intercepta pedidos de paginas web e serve-as localmente
bull Database mdash Uma base de dados relacional construıda sobre SQLite
bull WorkerPool mdash Permite executar operacoes de computacao de uma forma
assıncrona sem afectar a capacidade de resposta e fluidez de execucao da web
application Assemelham-se a processos
1Google Inc ndash Mais informacao em httpgearsgooglecom
17
Estado da arte
LocalServer
O modulo LocalServer e uma cache de Uniform Resource Locators (URLs)
controlada pela web application Quando nao existe uma ligacao a Internet e e
feito um pedido para um URL presente nesta cache o LocalServer intercepta-o e
responde ao pedido localmente a partir do disco rıgido do utilizador A aplicacao
pode utilizar dois tipos diferentes de armazenamento local de URLs
bull ResourceStore ndash serve para capturar URLs utilizando exclusivamente a API
de Javascript disponibilizada para o efeito Uma aplicacao podera criar e
utilizar diversos ResourceStores simultaneamente para capturar ficheiros de
dados que necessitam de ser enderecados por um URL tal como um ficheiro
PDF ou uma imagem
bull ManagedResourceStore ndash serve para capturar um conjunto de URLs que estao
relacionados e que sao declarado num ficheiro de manifesto (especificado em
JSON) e que sao automaticamente actualizados O ManagedResourceStore
permite que o conjunto de recursos necessarios para correr uma web application
seja capturado e mantido actualizado automaticamente
A principal diferenca entre estes dois tipos de armazenamento de URLs e a forma
como sao actualizados os seus conteudos Os conteudos de um ManagedResourceStore
sao actualizados sempre que a versao contida no ficheiro de manifesto for alterada
enquanto que os conteudos de um ResourceStore nunca sao actualizados automati-
camente mas apenas quando for explicitamente ordenado pela aplicacao
O LocalServer e capaz de interceptar e servir localmente pedidos de HTTP e
HTTPS sempre que se reunam as seguintes condicoes
1 O URL encontra-se armazenado num ResourceStore ou ManagedResourceStore
2 O sistema de armazenamento local encontra-se activo (enabled = true) Se
o sistema de armazenamento local tiver o atributo requiredCookie o pedido
devera conter um cookie que lhe corresponda
O LocalServer nao necessita de monitorizar o estado da ligacao para atender aos
pedidos Na verdade sempre que as condicoes previamente enunciadas se verificarem
o LocalServer interceptara os pedidos e independentemente do estado da ligacao
a Internet servi-los-a a partir do disco rıgido local Cabera a aplicacao definir qual
o modo em que pretende executar um pedido (online ou offline) definindo o valor
de verdade da propriedade enabled
18
Estado da arte
Database
O modulo Database permite guardar dados da web application assegurando a
sua persistencia Os dados sao guardados de forma relacional no disco rıgido do uti-
lizador2 de acordo com o modelo de seguranca estabelecido pelo Gears3 significando
que uma aplicacao nao pode aceder a conteudos fora do seu domınio
WorkerPool
Nos web browsers uma operacao pesada de computacao pode tornar a interface
lenta e tornar menos agradavel a experiencia do utilizador O modulo WorkerPool
permite correr operacoes em background sem bloquear a interface com o utilizador
Os scripts executados numa WorkerPool nao activam os mecanismos de seguranca
do browser que mostram a mensagem ldquoA script on this page may be busy or may
have stopped respondingrdquo
O WorkerPool comporta-se como um conjunto de processos em vez de threads
Os Workers nao partilham qualquer estado de execucao o que significa que uma
alteracao a uma variavel num Worker nao afecta em nada a execucao de outro
Worker Alem disso os Workers nao herdam automaticamente nenhum codigo dos
seus pais Cada Worker e membro de um WorkerPool e os Workers podem in-
teragir entre si enviando mensagens em formato de texto ou JSON No entanto ha
tambem algumas limitacoes os Workers nao tem acesso ao DOM e objectos como
window ou document nao se encontram acessıveis Isto e consequencia de os Workers
nao partilharem o estado de execucao Mas tem acesso a todas as funcoes built-in
do Javascript A maioria das funcionalidades do Gears pode tambem ser acedida
atraves de uma variavel global especial definida como googlegearsfactory Para
outras funcionalidades especıficas os Workers podem ldquopedirrdquo a pagina principal para
continuar a execucao atraves do envio de mensagens
Outras funcionalidades
bull HttpRequest ndash Este modulo implementa a especificacao W3C XmlHttpRe-
quest definida em [vK08] tornando-a disponıvel para os workers e para a
pagina principal
bull Timer ndash Este modulo implementa a especificacao de timers tal como descrito
por [Hic08] e torna-os disponıveis para os workers e para a pagina principal
2Consultar httpcodegooglecomapisgearsapi_databasehtmldirectories3Consultar httpcodegooglecomapisgearssecurityhtml
19
Estado da arte
bull Factory ndash Esta classe e utilizada para instanciar todos os outros objectos da
API do Gears atraves do seu metodo create Este metodo pode ser utilizado
com os seguintes parametros
ndash betadatabase
ndash betahttprequest
ndash betalocalserver
ndash betatimer
ndash betaworkerpool
312 Goggle Gears em dispositivos moveis
O Gears esta tambem disponıvel em dispositivos Windows Mobile 5 e 6
Os dispositivos moveis estao pela sua natureza frequentemente desconectados
da Internet Mesmo quando possuem uma ligacao as latencias na transferencia de
dados em redes moveis tornam as aplicacoes pouco fluıdas mas o Gears permite
ultrapassar este obstaculo
O Gears funciona exactamente da mesma forma em dispositivos moveis equipados
com o Windows Mobile 5 e 6 como num computador comum Se uma aplicacao tiver
sido implementado com suporte para o Gears entao tambem estara preparada para
ser executada num dispositivo movel mas as limitacoes dos browsers disponıveis
para dispositivos moveis tem que ser consideradas Isto significa prever as condicoes
que permitam uma boa usabilidade devido aos pequenos ecras destes dispositivos
bem como o seu suporte limitado dos padroes do DOM CSS e JavaScript
32 Adobe AIR
O Adobe AIR4 e um runtime compatıvel com diversos browsers e sistemas opera-
tivos que pretende dar aos programadores a possibilidade de combinar diversas tec-
nologias de producao de conteudos para a Internet no desenvolvimento de Rich Inter-
net Application (RIA)s O Adobe AIR mantem uma relacao com o browser mas es-
tende as suas capacidades e tecnologias permitindo o desenvolvimento de aplicacoes
tambem para o ambiente de trabalho com janelas em tudo semelhantes as do sis-
tema operativo Segundo a Adobe o objectivo e complementar o browser dando
aos utilizadores (mas essencialmente aos programadores e equipas de desenvolvi-
mento) a escolha sobre como distribuir as suas aplicacoes Para este efeito o Adobe
AIR tem uma aproximacao diferente do Gears Em vez de ldquoestenderrdquo o browser
acrescentando-lhe funcionalidades o AIR permite tambem o desenvolvimento de
4Adobe - httpwwwadobecomproductsair
20
Estado da arte
aplicacoes que se destinam a ser executadas fora do ambiente do browser mas uti-
lizando as tecnologias comuns da Internet (por exemplo HTML CSS JavaScript
Flash Flex)[CDGH08]
A utilizacao desta tecnologia permite utilizar o browser ou o proprio runtime
Adobe AIR como plataforma de execucao da aplicacao
Na Tabela 31 faz-se uma comparacao das funcionalidades disponıveis de acordo
consoante se escolha o browser ou o desktop como plataforma base para a aplicacao
Uma vez que as aplicacoes Adobe AIR na plataforma desktop tem um caracter
persistente (sao instaladas no computador do utilizador) o Adobe AIR tem um
modelo de seguranca que se assemelha com o das tradicionais aplicacoes desktop
[Ada08] Este modelo e analisado nas seccoes 321 e 322 O ambiente em que
e executado o browser e restringido a execucao de web applications que podem
ser de varias origens (incluindo de origens anonimas ou sem confianca) O Adobe
AIR proporciona acesso a capacidades como acesso a ficheiros que necessitam da
confianca do utilizador
bull HTML ndash O desenvolvimento de aplicacoes para o Adobe AIR pode ser feito
com recurso a tecnologias de HTML e Ajax comuns utilizando as linguagens
de markup existentes distribuıdas como texto e interpretadas em execucao
(runtime)
bull Flash ndash Outra alternativa sera a utilizacao da linguagem Flash Permite a
renderizacao de graficos vectoriais e audiovıdeo com suporte nativo Utiliza
ActionScript para adicionar maior interactividade com o utilizador
bull Flex ndash O Flex e uma framework open source para o desenvolvimento de RIAs
usando Flash As aplicacoes Flex sao na realidade Flash sendo a principal
diferenca o ambiente de desenvolvimento
Como resultado uma aplicacao AIR podera ser implementada
bull Baseada em Flash ou Flex (aplicacoes cujo conteudo base e em ShockWave
Flash (SWF))
bull Baseada em Flash ou Flex tambem com HTML ou Portable Document Format
(PDF) Aplicacoes cujo conteudo de base e em FlashFlex (SWF) com HTML
(HTML JavaScript CSS) ou conteudo PDF incluıdo
bull Baseada em HTML Aplicacoes cujo conteudo base e em HTML Javascript
CSS
bull Baseada em HTML utilizando tambem FlashFlex ou PDF
21
Estado da arte
Os utilizadores interagem com uma aplicacao AIR da mesma forma que interagem
com outras aplicacoes com janelas nativas do seu sistema operativo O runtime e
instalado uma vez no computador do utilizador e a partir desse momento todas as
aplicacoes AIR terao o mesmo aspecto que qualquer outra aplicacao para o desktop
321 Seguranca
Permitir que uma web application aceda ao disco de armazenamento do utilizador
pode comprometer seriamente a sua seguranca Neste sentido o Adobe AIR tem
suporte para assinaturas digitais (Secure Sockets Layer (SSL)) que podem ser com-
pradas pelas equipas de desenvolvimento que o desejem e cujos certificados serao
apresentados ao utilizador no momento da instalacao Um outro aspecto ainda
relativo a seguranca e o mecanismo de isolamento de cada ambiente (sandbox )
322 Assinatura do codigo
O runtime AIR exige que todas as aplicacoes estejam digitalmente assinadas As
assinaturas digitais de codigo sao um processo que visa garantir a integridade da
aplicacao e a identidade do seu autor no momento da instalacao As equipas de
desenvolvimento podem ldquoassinarrdquo uma aplicacao utilizando um certificado atribuıdo
por uma Entidade Certificadora (Certification Authority) ou atraves de um certifi-
cado individual (self signed certificate) Neste momento o Adobe AIR suporta como
entidades certificadoras a Verisign e a Thawte [Ado08]
O instalador apresenta o nome de quem publica a aplicacao quando o codigo tiver
sido assinado com um certificado que apresente confianca ou que esteja encadeado
com um certificado que tenha ja sido aceite no computador em que se esta a instalar
a aplicacao
As equipas de desenvolvimento podem tambem assinar as aplicacoes com um
certificado auto-atribuıdo (um certificado criado por elas proprias) mas neste caso
o instalador apresentara estas aplicacoes como sendo de uma origem nao verificada
O AIR utiliza a infraestrutura publica de chaves [Ent07] suportada pelo arquivo
local do sistema operativo Para que a origem da aplicacao seja reconhecida o
computador onde a aplicacao AIR esta a ser instalada tem que confiar directamente
no certificado que foi utilizado para assinar a aplicacao ou confiar num certificado
que esteja num encadeamento logico de certificados confiados e que se ligue desta
forma ao certificado utilizado para assinar a aplicacao
Todas as aplicacoes AIR tem caracterısticas em comum independentemente da
tecnologia utilizada para o seu desenvolvimento (HTMLFlexFlash) No ambito
de uma aplicacao AIR existem um conjunto de APIs que estao disponıveis e que
tornam possıvel o acesso ao sistema local (leitura e escrita) e a recursos de rede que
22
Estado da arte
de outra forma nunca estariam acessıveis a partir de uma web application comum
Cada aplicacao AIR possui tambem diferentes nıveis de isolamento chamados secu-
rity sandboxes dependendo do tipo de conteudo que esta a ser carregado e do seu
objectivo
bull Isolamento ao nıvel da aplicacao5 ndash E a raiz de cada aplicacao AIR Este
nıvel de isolamento permite o acesso a APIs privilegiadas e especıficas do
AIR Em contrapartida e negado o acesso a algumas APIs que poderiam ser
facilmente utilizadas de forma maliciosa contra o utilizador final Importacao
dinamica de conteudos remotos e geralmente proibido e as tecnicas e mecan-
ismos de geracao dinamica de codigo sao fortemente restringidas Apenas
conteudo carregado directamente da directoria base da aplicacao podera ser
colocado neste nıvel de isolamento
bull Isolamento nao especıfico da aplicacao6 ndash contem todo o outro conteudo
que nao tenha sido carregado directamente para o isolamento da aplicacao
Isto inclui conteudo local e remoto Este tipo de conteudo nao tem acesso
directo as APIs do AIR e rege-se pelas mesmas regras tal como se tivesse sido
carregado por um browser a partir da mesma localizacao (por exemplo HTML
carregado a partir de um domınio remoto comporta-se da mesma forma que se
fosse acedido a partir do browser)
33 Mozilla Prism
331 XML User Interface Language
O eXtensible User Interface Language (XUL) e uma linguagem de anotacao
baseada em XML desenvolvida pela Mozilla Foundation que opera em aplicacoes
Mozilla multi plataforma tal como o Firefox O motor Gecko e a unica imple-
mentacao completa desta linguagem que foi desenhada sobre padroes web comuns
como CSS JavaScript e o DOM e permite o desenvolvimento de interfaces graficas
utilizando elementos pre-definidos tais como window box page textbox radio
button entre outros Infelizmente o XUL nao possui qualquer especificacao formal
ou implementacoes de inter-operabilidade para outros motores que nao o Gecko No
entanto a sua implementacao e licenciada em codigo aberto pelas licencas GNU Gen-
eral Public License (GPL) GNU Lesser General Public License (LGPL) e Mozilla
Public License (MPL)
Enunciam-se algumas caracterısticas desta linguagem
5NT application sandbox6NT non-application sandbox
23
Estado da arte
Liguagem de anotacao poderosa baseada em componentes (widgets) O ob-
jectivo do XUL e permitir a construcao de aplicacoes multi-plataforma em
claro contraste com o Dynamic HyperText Transfer Protocol (DHTML) que se
destina ao desenvolvimento de paginas web Por esta razao o XUL esta orien-
tado a componentes tais como janelas botoes e etiquetas em vez de paginas
cabecalhos de texto e ligacoes de hipertexto Investir tempo e esforco para
atingir este mesmo resultado em aplicacoes baseadas em DHTML compromete
frequentemente a complexidade e desempenho da aplicacao
Baseado em padroes O XUL e um dialecto XML baseado no padrao W3C XML
10 As aplicacoes escritas em XUL sao tambem baseadas em especificacoes
W3C adicionais como HTML 40 CSS DOM nıvel 1 e 2 JavaScript 15
incluindo ECMA-262 Edition 3 (ECMAscript)
Portabilidade entre plataformas Tal como HTML o XUL foi desenhado para
ser independente da plataforma em que e utilizado tornando as aplicacoes
facilmente portaveis entre sistemas operativos nos quais o Mozilla e suportado
Uma vez que o XUL oferece um nıvel de abstraccao dos componentes graficos
de interface que disponibiliza implementa a premissa ldquoum codigo para todas
as plataformasrdquo A interface grafica de todos os produtos centrais Mozilla
(browser instant messenger livro de enderecos) e escrita em XUL com um
unico codigo base que suporta todas as plataformas Mozilla
Separacao entre o nıvel de apresentacao e a logica de negocio Uma das
maiores preocupacoes no desenvolvimento para a Internet e a forte ligacao
entre estas duas camadas (interface e logica) Isto constitui um problema sig-
nificativo no desenvolvimento de grandes aplicacoes especialmente quando o
desenvolvimento e feito em ambientes de equipa porque as capacidades de de-
senvolvimento destas duas partes da aplicacao estao muitas vezes espalhadas
por diferentes elementos O XUL permite uma clara distincao entre a definicao
da aplicacao cliente e da logica de implementacao (XUL eXtensible Binding
Language (XBL) e JavaScript) apresentacao (CSS e imagens) internacional-
izacao (Document Type Definitions (DTDs) e etiquetas de texto em lınguas
especıficas guardados em ficheiros properties) O esquema grafico e apre-
sentacao de uma aplicacao XUL pode ser alterado de forma independente da
sua logica ou implementacao e a aplicacao pode ainda ser traduzida (interna-
tionalization) de forma independente da sua logica implementacao ou apre-
sentacao Este grau de separacao resulta em aplicacoes que sao mais faceis de
manter pelos programadores e facilmente adaptadas por designers e tradutores
24
Estado da arte
Facil adaptacao Outro benefıcio que advem do nıvel de separacao entre logica
de negocio e apresentacao oferecido pelo XUL e a facilidade com que se pode
adaptar uma aplicacao para diferentes clientes ou grupos de utilizadores Um
programador pode utilizar a mesma aplicacao base e adapta-la consoante as
necessidades atraves de diferentes temas (skins) e ficheiros de lınguas Desta
forma uma aplicacao escrita e desenvolvida em Ingles pode ser rapidamente
traduzida para Portugues e distribuıda com outra aparencia mais apropriada
ao cliente alvo
332 Prism
O Mozilla Prism e um browser simplificado e ldquointerpretadorrdquo de XUL (tambem
designado por XULRunner) que acolhe web applications sem a interface grafica ha-
bitual de um browser Baseia-se num conceito designado por Site Specific Browser
(SSB) Um SSB e uma aplicacao com um browser embebido desenhado para exe-
cutar apenas uma web application Nao possui os menus e barras de ferramentas
habituais Um SSB tem uma integracao com o sistema operativo e com o desktop
muito mais estreita do que uma web application acedida atraves de um browser uma
vez que e executado em janela propria
O Prism resulta de uma experiencia da Mozilla e visa reduzir as diferencas entre
as desktop applications tradicionais e as web applications Um dos aspectos focados e
a experiencia do utilizador Numa apresentacao oficial e dito que ldquo[o Prism] pretende
ser uma ponte entre as diferencas que existem entre as aplicacoes tradicionais de
desktop e as web applications explorando novos modelos de usabilidade enquanto
que a linha que as separa se continua a definirrdquo [Lab07]
34 HTML 5
A especificacao HTML 5 [Hic08] que se encontra em fase de desenvolvimento
pelo grupo WHATWG pretende ser uma norma de substituicao dos padroes HTML
4 XHTML 1x e do DOM2 HTML Uma das propriedades que o distingue das tec-
nologias que pretende substituir e precisamente o suporte para OWA e armazena-
mento de dados no cliente de uma forma relacional Nao sendo propriamente uma
tecnologia ndashmas antes uma especificacao ndashe aqui mencionada por ter servido como
referencia a diversas implementacoes de funcionalidades offline e por se considerar
que venha a ter um impacto significativo nas implementacoes de diversos browsers
Dion Almaer defendeu no seu blogue que o Gears era uma implementacao do
HTML 5 No seu artigo ldquoGears as a bleeding-edge HTML 5 implementationrdquo [Alm08]
o autor diz que ambos ndasho Gears e o HTML 5 ndashpretendem dar a web caracterısticas
25
Estado da arte
semelhantes e nao encontrar motivo de ldquocompeticaordquo entre as duas mas que en-
quanto o HTML 5 e uma especificacao o Gears e uma implementacao
No entanto tambem e verdade que o HTML 5 cobre muitos outros pontos para
alem das OWA que saem completamente fora do ambito do Gears Se esta es-
pecificacao atingir um estado de maturidade que possibilite a sua adopcao pelos
principais browsers tornando nativo do browser o suporte OWA entao deixara de
fazer sentido a existencia de uma extensao como o Gears
A especificacao HTML 5 disponibiliza duas APIs relevantes para o tema das
OWA
1 Uma base de dados baseada em SQL que permite o armazenamento de dados
do lado do cliente
2 Uma ldquocacherdquo HTTP que garante a disponibilidade das aplicacoes mesmo quando
o utilizador nao possui uma ligacao a Internet
Estas caracterısticas sao as bases da tecnologia das OWA e tem correspondencia
com os pontos analisados nas seccoes 311 e 311
35 Web applications que usam funcionalidades offline
Nesta seccao apresentam-se algumas web applications que actualmente disponi-
bilizam funcionalidades offline Estas aplicacoes foram escolhidas para uma analise
mais pormenorizada por utilizarem o Gears que tal como descrito na seccao 4 foi
a tecnologia escolhida para o projecto
351 Google Reader e Google Docs
O Google Reader7 e um leitor de feeds RSS Permite gerir a subscricao de varios
sites simultaneamente que disponibilizem conteudos neste formato e foi a primeira
web application da Google com uma versao offline publicamente acessıvel (desde
Junho de 2007)
O Google Reader implementa o modo ldquoutilizador deciderdquo oferecendo na sua
interface um botao que permite alternar entre os modos online e offline
O Google Docs8 e uma web application que permite a criacao e edicao de doc-
umentos de texto folhas de calculo e apresentacoes Era ja publico desde Janeiro
de 2008 que o Google estava a desenvolver uma versao OWA desta aplicacao mas o
acesso a uma versao experimental so foi possıvel a partir de 31 de Maio de 2008
7Google Reader - httpreadergooglecom8Google Docs - httpdocsgooglecom
26
Estado da arte
A implementacao das funcionalidades offline nestas duas aplicacoes seguiu difer-
entes aproximacoes principalmente porque o Google Reader apresenta ao utilizador
informacoes que sao fornecidas por fontes externas enquanto que no Google Docs
a informacao e criada e editada pelo utilizador sobre a forma de documentos
A diferente origem da informacao implica que no Google Reader seja necessario
prever casos de excepcao tal como existirem demasiados itens que necessitam de
ser transferidos para o cliente Nao observar este ponto causa um problema grave
de usabilidade e para evitar tempos de espera demasiado longos e uma interface
com pouca capacidade de resposta as accoes do utilizador o Google Reader apenas
transfere para o cliente os dois mil itens mais recentes na transicao para o modo
offline
352 Remember the Milk
O Remember The Milk9 e uma web application desenvolvida por uma equipa
Australiana que proporciona funcionalidades de agenda gestao de tempo e de tare-
fas e foi uma das primeiras aplicacoes independentes do Google a adoptar o Gears
para acessos em modo offline Permite que os seus utilizadores facam uma gestao
de tarefas agrupando-as em listas adicionando-lhes campos de informacao adicional
ou dando-lhes informacao geografica (recorrendo ao servico Google Maps10) Entre
a sua lista de funcionalidades encontra-se ainda a possibilidade de importar e ex-
portar eventos no formato iCalendar (ics) etiquetas (tags) em tarefas publicacao
Really Simple Syndication (RSS) e partilha de categorias de tarefas de acordo com
diferentes nıveis de permissoes de acesso definidos pelo utilizador
353 MySpace e WordPresscom
O MySpace uma das maiores social networks na Internet anunciou recente-
mente que vai disponibilizar uma versao do seu cliente de e-mail que utiliza o Gears
para acelerar o seu desempenho Numa fase inicial estara disponıvel apenas para
utilizadores que tenham cinco mil ou mais mensagens na sua caixa de correio e
permitira efectuar pesquisas muito mais rapido que a sua versao online
O servico de blogs Wordpresscom anunciou tambem o inıcio da utilizacao desta
tecnologia com o fim de melhorar o desempenho A versao que utiliza esta tecnologia
descarrega e armazena no cliente um conjunto de imagens e scripts que passam a
ter preferencia sobre os seus congeneres online e que permitem acelerar o processo
de carregamento da aplicacao e visualizacao de blogs
9Remember The Milk ndash httpwwwrememberthemilkcom10Google Maps ndash httpmapsgooglecom
27
Estado da arte
O MySpace e o Wordpresscom sao dois exemplos da utilizacao da tecnologia
OWA para optimizacao de web application ja existentes Sem pretenderem disponi-
bilizar uma versao que seja totalmente offline fazem uso do Gears para armazenar no
cliente parte dos recursos frequentemente acedidos na visualizacao das suas paginas
36 Escolha da tecnologia
Apos a analise das tecnologias apresentada nas seccoes 31 a 34 foi necessario es-
tudar a adequacao de cada uma delas ao projecto em questao Desde logo e possıvel
observar que nem todas se dedicam apenas a OWA Por exemplo o Adobe AIR
apesar de ter suporte para OWA apenas disponibiliza algumas das funcionalidades
identificadas como mais indicadas para a execucao do projecto quando utilizado
na sua vertente desktop tal como exposto na Tabela 31 mas a utilizacao desta
vertente implicaria o desenvolvimento de novas interfaces e de novas formas de co-
municacao (troca de mensagens XML ou JSON) A vertente web do Adobe AIR
foca-se mais especificamente nas Rich Internet Applications e permite a reutilizacao
do codigo ja existente (exigindo naturalmente a sua adaptacao e a implementacao
das funcionalidades pretendidas)
A tecnologia escolhida para a realizacao deste trabalho foi o Gears sendo que
um dos principais factores a influenciar esta opcao foi a liberdade introduzida pela
sua licenca Berkeley Software Distribution (BSD)11
Considerou-se o funcionamento desta ferramenta extremamente adequando a
aplicacao no WOW uma vez que o seu principal objectivo e precisamente tornar
possıvel a execucao offline de uma pagina web e por virtude deste facto o Gears tem
uma API concisa e de simples aplicacao pratica uma vez que nao possui quaisquer
outros elementos distractores O funcionamento do seu ManagedResourceStore ex-
emplificado na Figura 31 com a capacidade de actualizacao de recursos definidos
num ficheiro manifesto especificado em JSON pesou tambem nesta decisao
11Sobre a licenca BSD consultar httpwwwopensourceorglicensesbsd-licensephp e http
wwwlinfoorgbsdlicensehtml
28
Estado da arte
Figura 31 Esquema UML do processo efectuado pelos recursos do Gears do tipoManagedResourceStore para a actualizacao dos conteudos definidos no ficheiro manifesto
29
Estado da arte
Funcionalidade RIAs no browser RIAs no desktop
Disponibilidadeda aplicacao
As aplicacoes podem ser facil-mente exploradas e utilizadas
As aplicacoes quando instal-adas tem maior grau de fun-cionalidades e persistencia
Instalacao Nao e necessario qualquer tipode instalacao
As aplicacoes sao instaladasatraves do browser ou descar-regadas e instaladas comouma aplicacao tradicional
Actualizacoes Aplicacoes sao actualizadascarregando conteudos paraum website
O AIR disponibiliza uma APIque permite que as aplicacoessejam actualizadas de umaforma
Sistemas opera-tivos suportados
As aplicacoes podem ser exe-cutadas em diversos sistemasoperativos e browsers
As aplicacoes sao multi-plataforma e podem serinstaladas e executadas emdiversos sistemas operativos ebrowsers
Linguagens deprogramacao
Javascript e disponibilizadopelo browser e ActionScripte disponibilizado pelo AdobeFlash Player
Maquinas virtuais deJavascript e ActionScriptcompatıveis com o browser
Capacidade deexecucao embackground
As RIAs podem ser execu-tadas numa janela do browser
As aplicacoes podem ser ex-ecutadas em background edisponibilizar notificacoes talcomo uma aplicacao tradi-cional
Persistencia A actividade esta limitada asessao do browser Quando obrowser e encerrado toda ainformacao e descartada
As aplicacoes sao instaladas eestao disponıveis no desktopPodem armazenar informacaolocalmente e estao disponıveisoffline
Integracao com odesktop
Integracao com o desktop lim-itada devido a restricoes im-postas pelo browser
As aplicacoes podem acederao sistema de ficheiro ao clip-board eventos notificacoesetc
Controlo da inter-face com o uti-lizador
As aplicacoes sao acedidasatraves de uma janela dobrowser que tem os seusproprios controlos e visualgrafico
As aplicacoes tem um vi-sual grafico proprio em janelapropria
Armazenamentode dados
As aplicacoes tem armazena-mento limitado que pode serreescrito pelo browser
As aplicacoes tem acesso a to-talidade do espaco disponıvellocalmente e a uma base dedados com a possibilidade deencriptacao
Tabela 31 Comparacao das funcionalidades oferecidas pelo Adobe AIR para as platafor-mas web e desktop
30
Estado da arte
Aplicacao Modo de execucao utilizadoGoogle Reader Utiliza o modo ldquoutilizador deciderdquo disponibilizando
ao utilizador um botao para alternar entre os modosonline e offline Como lida com informacao recol-hida de fontes externas de natureza frequentementeefemera o processo de sincronizacao apenas transfereos dois mil itens mais recentes quando passa ao es-tado offline Neste modo sao ainda guardadas in-formacoes de itens lidos e etiquetas atribuıdas quesao sincronizadas com o servidor quando o utilizadorvoltar a activar estado online
Google Docs Utiliza o modo ldquoaplicacao deciderdquo permitindo que outilizador edite os conteudos de documentos de textofolhas de calculo e de apresentacoes independente-mente do estado da ligacao desde o momento em queas funcionalidades offline sao activadas A aplicacaofaz pequenas sincronizacoes com o servidor sempre quenecessario
Remember the Milk Utiliza um modo hıbrido entre ldquoaplicacao deciderdquo eldquoutilizador deciderdquo A aplicacao encarrega-se da sin-cronizacao de dados mas disponibiliza um controlona sua interface que permite despoletar manualmenteeste processo para situacoes em que o utilizador fez al-teracoes recentes e pretende usufruir das capacidadesoffline imediatamente
MySpace O MySpace anunciou a utilizacao de mecanismos dearmazenamento de dados no cliente com recurso atecnologias OWA para melhorar o desempenho doseu cliente web de correio electronico nomeadamenteno que diz respeito a operacoes de pesquisa e or-denacao Inicialmente esta funcionalidade estara ape-nas disponıvel para utilizadores com cinco mil ou maismensagens na sua caixa de correio mas nao e aindaclaro se sera disponibilizada uma versao totalmenteoffline
Tabela 32 Resumo da utilizacao de tecnologias OWA em algumas web applications con-sideradas na analise do estado da arte
31
Estado da arte
32
Capıtulo 4
Desenvolvimento
Neste capıtulo introduz-se a aplicacao WOW e apresenta-se o estudo que foi
feito da adequacao de cada tecnologia para a implementacao da funcionalidade of-
fline nesta plataforma Fazem-se diversas consideracoes sobre opcoes a tomar na
concepcao de OWAs e problemas comuns na sua implementacao bem como sug-
estoes para os resolver O WOW e uma aplicacao ja existente de gestao de ordens
de trabalho e do fluxo de tarefas numa empresa ou organizacao
41 Como ficar offline
Na maior parte das web applications de hoje nao existe uma camada de dados
real A aplicacao exemplificada na Figura 41 ao longo da sua execucao acede
directamente a sua unica fonte de dados (o servidor) atraves de chamadas Ajax sem
que exista uma separacao clara destas duas camadas
Para que uma web application seja capaz de ser executada sem uma ligacao
activa a Internet e mantenha o seu caracter dinamico torna-se necessario incluir
Figura 41 Exemplo de uma arquitectura de uma web application sem uma camada deabstraccao de dados Figura adaptada de http gears google com
33
Desenvolvimento
Figura 42 Exemplo de uma arquitectura de uma web application com uma camada deabstraccao de dados Figura adaptada de http gears google com
um mecanismo de armazenamento de dados local seja uma base de dados ou a
capacidade de acesso ao disco No entanto este mecanismo introduz dois problemas
1 Qual das fontes de dados utilizar quando um utilizador faz um pedido de
informacao
2 A necessidade de implementar uma camada de acesso a dados que seja coerente
quer se use o servidor remoto ou local
Por exemplo em vez de a aplicacao Ajax fazer um pedido relativo as contas de
todos os utilizadores em formato JSON directamente ao servidor remoto podera ao
inves fazer o pedido a um objecto intermedio da camada de dados Este objecto
demonstrado na Figura 42 sera responsavel por implementar uma interface de
acesso a base de dados e retornar um objecto JavaScript com uma representacao da
resposta do servidor
Mas a existencia de uma segunda fonte de dados torna recomendavel tambem
a implementacao de uma camada de data switching que em funcao da existencia
de conexao a Internet e da necessidade de actualizacao dos dados decide se faz o
pedido ao servidor remoto ou se fornece os dados presentes localmente Este objecto
apresentado na Figura 43 decidira de forma transparente para o utilizador se le ou
escreve os dados localmente ou se os enviapede ao servidor remoto e pode tambem
iniciar o processo de convergencia de dados e de resolucao de conflitos
411 Funcionalidades disponıveis em modo offline
Por razoes praticas e provavel que nem todas as funcionalidades da aplicacao
possam ser disponibilizadas em modo offline E necessario escolher quais as fun-
cionalidades a disponibilizar no modo offline da aplicacao e implementar a logica
que decide quando utilizar a base de dados local ou o servidor remoto Apesar do
acesso a base de dados local ser muito mais rapido do que aceder ao servidor o
acesso local nem sempre e preferido Ha varias razoes que podem tornar necessario
escolher o acesso ao servidor em vez do acesso local
34
Desenvolvimento
Figura 43 Exemplo de uma arquitectura de uma web application com uma camada deabstraccao de dados e um data switch Figura adaptada de http gears google com
1 A informacao pode ter uma natureza efemera e nao fazer sentido guarda-la
localmente Exemplo dados em tempo real da bolsa de valores de Lisboa
2 Algumas aplicacoes lidam com informacao que so faz sentido na presenca de
uma ligacao Exemplo Instant Messaging
3 A aplicacao podera escolher apenas guardar a informacao acedida mais fre-
quentemente Exemplo para o utilizador poder alterar a lıngua de apre-
sentacao da aplicacao os conteudos terao que ser guardados em todas as
lınguas disponibilizadas pela aplicacao O custo de implementacao de algu-
mas funcionalidades pode nao compensar o benefıcio
4 A capacidade de processamento ou de armazenamento de dados pode inviabi-
lizar algumas funcionalidades offline Exemplo se uma dada funcionalidade
necessita de uma capacidade de armazenamento de dados para alem do razoavel
de um computador pessoal para ser util (visualizador de mapas)
42 Modos de execucao
Um aspecto que e necessario estudar para qualquer web application que se deseje
disponibilizar offline prende-se com tres modos de execucao que devem ser consid-
erados
1 Utilizador decide o modo de execucao A aplicacao tem modos distintos
de execucao para os estados online e offline geralmente indicados na interface
com o utilizador O utilizador e informado do estado da ligacao e participa na
alteracao de estado de execucao da aplicacao interagindo com a sua interface
2 Aplicacao decide o modo de execucao Pode ser implementado na propria
aplicacao um mecanismo de deteccao do estado da ligacao (por exemplo atraves
35
Desenvolvimento
de chamadas Ajax periodicas) transitando de estado e sincronizando automati-
camente Desta forma o utilizador nao precisa de participar na alteracao de
estado a menos que exista um conflito de dados que requeira a sua atencao
3 Aplicacao assume sempre o estado offline Outra hipotese sera imple-
mentar uma web application que assume sempre estar na ausencia de uma
ligacao ao servidor de dados Esta aplicacao responde aos pedidos do uti-
lizador efectuando pedidos de informacao ao servidor mas nao dependendo
de uma resposta valida para mostrar a informacao que ja tinha disponıvel an-
teriormente A sincronizacao de dados com o servidor e tentada sempre que
existam dados para submeter e uma accao do utilizador
421 Modo ldquoutilizador deciderdquo
Neste modo de execucao quando a aplicacao esta online comunica com o servidor
remoto quando esta offline comunica com a base de dados local A informacao tem
que ser sincronizada sempre que se muda de modo A principal vantagem desta opcao
e que e a mais simples de implementar mesmo para uma aplicacao ja existente e
portanto uma forma expedita de disponibilizar uma OWA No entanto tem tambem
algumas desvantagens que devem ser consideradas
1 O utilizador tem que se lembrar de fazer a alteracao de estado de execucao
Caso contrario podera estar a trabalhar inadvertidamente numa versao offline
com dados antigos ou nao ter a informacao necessaria se perder subitamente
a ligacao
2 Se a ligacao for intermitente o utilizador tera ou que escolher um dos modos
de execucao ou estar constantemente a trocar
3 Uma vez que a base de dados nao esta sempre actualizada nao podera ser
utilizada para melhorar a rapidez de execucao da aplicacao quando em modo
online
422 Modo aplicacao decide
A deteccao do estado da ligacao pode ser implementada atraves de um pedido
assıncrono ao servidor tal como ilustrado na Figura 44 O resultado deste pedido
definira o estado online (em caso de sucesso) ou offline (em caso de falha) A
sincronizacao de dados podera ser feita sempre que ocorra uma transicao do es-
tado offline para o estado online No entanto este metodo nao se revela eficiente
36
Desenvolvimento
Figura 44 Esquema grafico ilustrando uma OWA executando no browser utilizando ummodo de execucao do tipo ldquoaplicacao deciderdquo com deteccao automatica do estado daligacao via pedidos Ajax assıncronos a cada cinco segundos
para grandes aplicacoes uma vez que requer a troca de mensagens demasiado fre-
quentes com o servidor que se destinam exclusivamente a monitorizacao do estado
da ligacao
423 Modo ldquoaplicacao assume o estado offlinerdquo
Uma aplicacao transparente funciona assumindo sempre que esta em modo of-
fline ou pelo menos que pode perder a ligacao a qualquer momento Neste modo
tira-se o maximo partido do armazenamento local e fazem-se pequenas mas contınuas
sincronizacoes com o servidor sempre que este esteja disponıvel A sincronizacao de
dados tambem e feita sempre que se volta ao estado online
As vantagens de uma web application transparente sao as seguintes
bull Uma melhor experiencia para o utilizador uma vez que este nao tem que se
preocupar com o estado da ligacao ou com a transicao de estados
bull A aplicacao funciona de forma coerente mesmo que a ligacao seja intermitente
bull Uma vez que o armazenamento local e mantido actualizado pode ser utilizado
para melhorar o desempenho da aplicacao
Foram identificadas as seguintes desvantagens
bull E mais difıcil de implementar e a sincronizacao acarreta cuidados especiais
bull E necessario um cuidado adicional para evitar que as operacoes de sincronizacao
frequentes que ocorrem automaticamente nao afectem os tempos de resposta
da aplicacao
bull Os testes a aplicacao sao mais complexos uma vez que a sincronizacao de dados
nao ocorre em resposta a uma accao do utilizador
37
Desenvolvimento
43 Sincronizacao de dados
A sincronizacao de dados consiste na capacidade de identificar e transferir pe-
riodicamente a versao mais actual dos dados entre o cliente e o(s) servidor(es)
Independentemente do modo de execucao escolhido e mesmo do estado da ligacao
do utilizador a informacao armazenada localmente e a informacao armazenada no
servidor estarao por vezes dessincronizadas Isto podera acontecer sempre que por
exemplo
bull O utilizador faz alteracoes em modo offline
bull A informacao e partilhada e pode ser alterada por uma entidade externa
bull A informacao e fornecida por uma entidade externa
Resolver estas diferencas de forma a que a informacao local e remota encontrem
a igualdade chama-se sincronizacao de dados Ha varias aproximacoes possıveis
para este efeito que dependem da natureza da aplicacao cada uma com vantagens
e desvantagens
A capacidade de suportar a mobilidade dos utilizadores torna-se cada vez um
ponto mais importante de uma web application Para uma organizacao de dimensao
global e vital garantir que os seus colaboradores tem acesso a mesma informacao
que tem disponıvel nos seus postos de trabalho mesmo quando estao fora Na maior
parte dos casos estes colaboradores terao acesso a um computador portatil um
desktop Smartphone ou PDA e atraves destes poderao ter acesso a sua informacao
directamente atraves de ligacoes encriptadas Virtual Private Network (VPN) de um
servidor web ou de outro mecanismo de rede
Esta solucao e simples de implementar mas infelizmente para a maioria dos
colaboradores com grande factor de mobilidade nao e satisfatoria As principais
desvantagens sao as seguintes
bull Requisitos de ligacao Para permitir que os utilizadores acedam a sua in-
formacao e necessario garantir a capacidade constante de comunicacao pelo
menos durante o tempo necessario que assegure a sua transferencia
bull Velocidade de ligacao sem persistencia de dados e em ligacoes de fraca
qualidade a usabilidade por vezes torna-se inaceitavel
bull Ponto crıtico de falha Com este tipo de solucao todos os utilizadores de-
pendem da base de dados que armazena informacao vital para o funcionamento
do cliente
38
Desenvolvimento
bull Scalability do servidor A medida que novos utilizadores sao adicionados ao
sistema o desempenho do servidor e afectado levando a necessidade de maior
capacidade de armazenamento eou processamento
De acordo com a documentacao da Microsoft Sync Framework [Mic08] uma
solucao alternativa consiste em implementar uma Occasionally Connected Appli-
cation (OCA) Uma OCA permite a um utilizador remoto continuar a aceder a
sua informacao mesmo depois de perder a ligacao mas em vez de recorrer a um
servidor recorre a informacao armazenada no seu dispositivo local Para preencher
localmente a informacao que o utilizador necessita uma OCA possui mecanismos
de sincronizacao de dados que sao oferecidos por esta framework
431 Quando sincronizar
Uma das solucoes mais simples de implementar passa por disponibilizar um
mecanismo manual que despoleta a sincronizacao Diz-se manual porque e o uti-
lizador que escolhe quando sincronizar e pode ser implementada simplesmente
fazendo o upload de toda a informacao para o servidor e depois fazendo o download
da copia mais recente da informacao antes de voltar a ficar offline Para que esta
seja uma opcao viavel e necessario que
bull O volume de dados seja suficientemente pequeno para que possa ser transferido
do servidor para o cliente num espaco de tempo aceitavel
bull Que o utilizador indique explicitamente que quer mudar para o estado offline
ou online pressionando um botao da interface
Contudo podem ser identificados alguns problemas relacionados com esta abor-
dagem
bull Os utilizadores nem sempre podem prever o estado das suas ligacoes A ligacao
pode-se perder subitamente ou ter um caracter intermitente
bull O utilizador pode esquecer-se de efectuar a sincronizacao
Outra opcao sera conjugar a sincronizacao de dados com o modo de execucao
transparente A sincronizacao ocorre automaticamente em background de forma
nao intrusiva para o utilizador A aplicacao comunica com o servidor regularmente
efectuando pequenas trocas de dados com o objectivo de manter o sincronismo da
informacao local e remota Esta abordagem pode ser implementada com pedidos
Ajax assıncronos e regulares ao servidor o que permite manter a interaccao com a
interface fluıda evitando bloqueios Estes pedidos sao feitos prevendo as situacoes
39
Desenvolvimento
de disponibilidade ou indisponibilidade (timeout) do servidor Uma outra opcao
sera permitir que o servidor comunique essas alteracoes utilizando Comet1 tal como
descrito em [Wil06] e [Rus06] As vantagens destas aproximacoes sao
bull A informacao esta disponıvel a qualquer altura que o utilizador decida ficar
offline ou que a ligacao seja acidentalmente perdida
bull O desempenho da aplicacao pode ser melhorado quando se estiver a utilizar
uma ligacao a Internet lenta uma vez que o acesso a dados locais e mais
eficiente do que a consulta de dados ao servidor
44 WOW
O WOW e uma plataforma integrada de gestao de ordens de trabalho ja ex-
istente e desenvolvida pela Critical Software SA a qual se pretende adicionar a
capacidade de execucao offline Esta aplicacao e extremamente dinamica e con-
figuravel com um conjunto extremamente rico de funcionalidades das quais se
destacam
bull Gestao de Ordens de Trabalho ndash suportando a gestao dos pedidos desde a
sua criacao ate ao seu fecho tomando em conta os diferentes tipos de pedidos
(ordens de trabalho pedidos de informacao melhorias resolucao de problemas
etc) e diferentes tipos de accoes possıveis para cada um (Figura 45)
bull Monitorizacao de alteracoes ndash Historico de mudancas anexos e estados criando
relatorios de alteracao automaticamente (o que por quem e quando)
bull Uso de Service Level Agreements (SLAs) ndash E possıvel associar a um pedido um
SLA que define qual o perıodo de tempo atribuıdo a resolucao de um pedido
controlando e agilizando a resolucao do mesmo
bull Utilizacao de queries de utilizador configuraveis que permitem acesso rapido
a determinadas ordens de trabalho de acordo com o filtro configurado (por
exemplo ldquoPara mimrdquo ldquoPara o Grupordquo ldquoPelo Grupordquo)
bull Gestao do relacionamento entre pedidos
bull Pesquisa e filtragem de ordens de trabalho
bull Exportacao de dados em formatos padrao (PDF DOC ou XLS)
bull Integravel com solucoes externas
40
Desenvolvimento
Figura 45 Detalhe de um conjunto possıvel de estados e respectivas transicoes para umadada ordem de trabalho no WOW desde a sua submissao no sistema ate a sua conclusaoem fecho ou cancelamento Esta figura representa apenas um exemplo ja que o mapa deestados para uma ordem de trabalho e dinamico e pode ser alterado por um administradorFigura retirada de uma brochura promocional do WOW Critical Software SA
A utilizacao de uma ferramenta deste tipo por parte de uma empresa ou orga-
nizacao oferece vantagens quer a gestao de topo quer aos colaboradores individuais
para os colaboradores individuais o WOW e uma aplicacao onde estao registadas
todas as tarefas contribuindo activamente para o desenvolvimento em ambientes
multi-tarefa e para a organizacao pessoal das tarefas de acordo com prioridades
Para a gestao de topo esta ferramenta permite obter uma visao global do estado da
organizacao em termos de tempo gasto por tarefa executada sendo uma mais valia
para a previsao e gestaoalocacao de recursos
45 Visao geral sobre a arquitectura do WOW
O WOW e interessante nao so do ponto de vista de produto como tambem do
ponto de vista de plataforma Existem diversos plug-ins que estendem as funcional-
idades do WOW e existem ate projectos que pretendem usar a arquitectura do
WOW para criar produtos com fins diferentes do inicial (por exemplo o WOW-
Storm ndash um sistema de registo e classificacao social de ideias)
De modo a conseguir ter essa expansibilidade a plataforma WOW assenta sob
uma arquitectura distribuıda modular e expansıvel com uma componente central
ndash o core ndash estruturado em camadas logicas E no core que se situam todas as
1O Comet e um conceito semelhante ao Ajax introduzido por Alex Russel mas no qual e o servidor quetoma a iniciativa de ldquoenviarrdquo os dados ao browser sem que este tenha que efectuar um pedido Tambem econhecido por Ajax Push Reverse Ajax ou HTTP Streaming
41
Desenvolvimento
funcionalidades base da aplicacao quer a nıvel logico funcional e de apresentacao
quer a nıvel de gestao e configuracao
E possıvel a execucao de varias instancias do core simultaneamente em servidores
distintos o que permite a alta escalabilidade e disponibilidade desta aplicacao A
consistencia dos dados fica sempre garantida atraves da partilha da base de dados
e pelo balanceamento dos pedidos uma vez que cada um e encaminhado para uma
unica instancia
O WOW apresenta tambem a vantagem de ser uma plataforma extensıvel E
possıvel adicionar novas caracterısticas a plataforma atraves de componentes que se
podem ser divididos em duas categorias plugins e connectors
Os plugins sao componentes que se encontram no mesmo no fısico que a aplicacao
partilhando do mesmo contexto de execucao do core Sao assim uma forma mais
directa de obter informacao da plataforma visto que nao possuem restricoes de
acesso aos dados nem dependencias externas A arquitectura deste componente tera
assim que permitir varias execucoes instanciadas cada uma associada a um core
Por outro lado os connectors sao componentes que se encontram distribuıdos
comunicando externamente com o core Quer a sua execucao quer a obtencao
dos dados estao assim dependentes de interfaces de comunicacao externas que a
plataforma disponibiliza Estes componentes ao contrario dos plugins sao instan-
ciados unicamente e recorrem ao protocolo de comunicacao Java Messaging Service
(JMS) para comunicar com o core
46 WOW Offline
Para alem das opcoes tomadas relativamente a tecnologia a utilizar surgiu
tambem a necessidade de optar por um dos modos de execucao apresentados na
seccao 42
Das tres opcoes possıveis foi o modo ldquoaplicacao assume o estado offlinerdquo descrito
na seccao 423 que mereceu a maior atencao uma vez que reune as vantagens de
uma experiencia mais positiva para o utilizador (uma vez que este nao tem que
participar activamente na alteracao do modo execucao como descrito na seccao 421)
e nao constitui uma sobrecarga excessiva para servidor (como o modo abordado na
seccao 422)
No entanto esta opcao comprometia a complexidade da implementacao para alem
dos objectivos propostos para este projecto e para cumprir o prazo dado foi tomada
a decisao de implementar o modo ldquoutilizador deciderdquo especificando apenas de forma
teorica o modo ldquoaplicacao assume o estado offlinerdquo
As caracterısticas do Gears foram ja descritas na seccao 31 Na Figura 47
mostra-se a sua forma de funcionamento quando integrado numa web application
42
Desenvolvimento
Nesta figura representa-se o modulo LocalServer do Gears como um ponto de de-
cisao Aqui sao testadas as condicoes que determinam se o pedido sera interceptado e
servido localmente ou se prossegue para uma maquina remota E tambem represen-
tada uma base de dados que corresponde ao modulo Database mas que podera nao
ser utilizada Este modulo tal como o modulo Workerpool tem caracter opcional
e sao utilizados consoante os requisitos da aplicacao
A plataforma WOW lida com mais dados do que e necessario passar para o
lado do cliente Em conformidade com o ja exposto na seccao 411 volta-se a
frisar que nao se pretende recriar toda a logica de negocio nem os conteudos da
base de dados no cliente pela sua complexidade e volume de dados Pretende-se
pelo contrario permitir que os utilizadores tirem partido da capacidade de poder
consultar as suas ordens de trabalho quando nao dispoe de uma ligacao transferindo
apenas o essencial para isto seja possıvel
A pagina inicial do WOW apresenta um resumo das ordens de trabalho abertas
ndash enviadas e recebidas ndash que se pretende permitir visualizar offline (ver Figura 46)
Como prova de conceito foi efectuada uma abordagem pragmatica das varias possi-
bilidades descritas na seccao 42
461 Modo ldquoaplicacao deciderdquo com deteccao automatica da ligacao
A primeira abordagem estudada para a disponibilizacao das funcionalidades of-
fline foi o modo ldquoaplicacao deciderdquo com deteccao automatica de ligacao apresentado
na seccao 422 Para que isto seja possıvel foi implementado um mecanismo de ver-
ificacao periodica do estado da ligacao atraves de chamadas Ajax assıncronas O
resultado destes pedidos determina o estado da aplicacao executando as tarefas de
sincronizacao de dados sempre que pertinente Este metodo embora imediato e
simples de implementar depressa se revelou inadequado para o projecto devido ao
elevado consumo de recursos do servidor que a utilizacao intensiva faz esperar a
comunidade da plataforma WOW no principal cliente excede os 7000 utilizadores
Foi estimado que para uma utilizacao de fluidez aceitavel o estado da ligacao deveria
ser testado a cada cinco segundos Assumindo uma adesao (previsao pessimista) de
1 aos servicos offline assistir-se-ia a cerca de 840 pedidos adicionais por minuto
Mas o principal problema desta aproximacao prende-se com o facto de a ver-
ificacao ser feita em intervalos de tempo discretos levando a possibilidade de a
aplicacao poder ter em dado momento uma representacao errada do seu estado
real da ligacao Este problema e ilustrado na Figura 48 onde se ve claramente a
discrepancia entre o estado real da ligacao e a representacao interna que esta tem
Note-se que nesta janela de tempo qualquer accao do utilizador que exija uma
resposta sıncrona do utilizador leva-lo-a para um ldquobeco sem saıdardquo onde nao tera
43
Desenvolvimento
Figura 46 A pagina inicial do WOW apresenta um resumo das ultimas ordens de trabalhoenviadas e recebidas Na imagem pode-se observar a transicao do estado online para offline
acesso a versao offline porque a aplicacao nao fez a transicao automatica nem acesso
a versao online porque na verdade nao possui uma ligacao O que acontecera nesta
situacao sera uma tentativa de acesso ao servidor por parte da aplicacao numa
altura em que este se encontra indisponıvel e o resultado sera uma mensagem de
ldquopedido excedeu o tempordquo apresentado pelo browser Este e um estado sem retorno
porque apos o browser apresentar esta mensagem todos os recursos JavaScript ficam
indisponıveis tornando impossıvel o regresso ao estado anterior ou o tratamento do
erro de qualquer outra forma No entanto as chamadas Ajax podem ser tratadas de
forma especial para a eventualidade de falha e portanto nao constituem problema
44
Desenvolvimento
Figura 47 Ilustracao do funcionamento do Gears numa web application que utiliza ummotor Ajax Os pedidos HTTP ou HTTPS podem ser interceptados e tratados localmenteou podem ser feitos a uma maquina remota consoante se verificarem ou nao as condicoesexpressas no ponto 311 E representado um acesso a uma base de dados local (fornecidapelo Gears) mas a sua utilizacao e opcional
462 Implementacao do modo ldquoutilizador deciderdquo
Este modo de execucao foi ja descrito na seccao 421 e a sua principal carac-
terıstica e ser o utilizador a decidir se a aplicacao deve utilizar um servidor remoto
ou a maquina local como fornecedor de dados
Relativamente ao WOW o WOW Offline na vertente ldquoutilizador deciderdquo vem
alterar os seus casos de uso dando ao utilizador a possibilidade de alterar o estado
de execucao da aplicacao (entre online e offline) Resta dizer que no modo online se
mantem todas as funcionalidades anteriores e que no modo offline torna-se possıvel
visualizar os conteudos da pagina principal do WOW (Figura 46) e os detalhes das
ordens de trabalho (Figura 49) tal como expressa a Figura 410
Esta aproximacao foi utilizada na prova de conceito do WOW adicionando um
controlo a interface desta aplicacao que permite ao utilizador alternar entre os esta-
dos online e offline Na transicao de online para offline sao descarregados os recursos
necessarios para a execucao desta aplicacao sem recorrer a Internet Para o fazer
45
Desenvolvimento
Figura 48 Neste exemplo do modo ldquoaplicacao deciderdquo o teste da ligacao e feito e feito acada cinco segundos O resultado deste teste nao reflecte sempre o estado real da aplicacaopodendo levar a aplicacao a ter comportamentos indesejaveis Na figura assinala-se umperıodo de tempo no qual a representacao interna do estado da ligacao nao corresponde arealidade
e utilizado um recurso ResourceStore e um ManagedResourceStore (introduzidos
em 311) O primeiro e utilizado para armazenar a pagina principal do WOW ndash do-
ravante designada por homejsp ndash e o segundo e utilizado para armazenar imagens
folhas de estilo CSS e scripts JavaScript
Para a implementacao deste modo de execucao foram identificadas as seguintes
tarefas
1 Guardar informacao que permita a recriacao das paginas que se pretende
disponibilizar offline (utilizando o Gears)
2 Disponibilizar um controlo que permita alterar o estado de execucao atraves
da interaccao com a pagina principal
3 Durante a sincronizacao de dados apresentar o progresso da transferencia de
dados
O primeiro passo consistiu na identificacao de todos os conteudos que sao necessarios
transferir para a execucao offline Foi utilizado um recurso do Gears do tipo
ManagedResourceStore que recorre a um ficheiro manifesto para identificar to-
dos os ficheiros que deve transferir Este recurso e gerido automaticamente pelo
Gears transferindo para o cliente a versao mais recente sempre que e necessario
isto e sempre que exista um ficheiro manifesto com uma identificacao de versao que
seja diferente da actualmente disponıvel no cliente Uma vez identificados todos
ficheiros necessarios para a execucao offline num (ou mais) ficheiros manifesto o
Gears encarrega-se da sua actualizacao mas o preenchimento destes ficheiros man-
ifesto e manual o que se traduz num cuidado extra na manutencao da aplicacao
A forma como esta informacao e guardada deve tambem ser cuidadosamente
estudada A opcao mais flexıvel passa por utilizar o modulo Database apresentado
na seccao 311 e guardar a informacao de uma forma relacional Para a recriacao
das paginas pode ser disponibilizada uma versao HTML da pagina que funciona
46
Desenvolvimento
Figura 49 Pagina de visualizacao do detalhe de uma ordem de trabalho
como template nao possui quaisquer dados e e utilizada apenas em modo offline E
preenchida para cada pedido retirando os dados relevantes da base de dados
O modelo de dados do WOW torna esta opcao extremamente trabalhosa uma
vez que as entidades envolvidas na geracao de cada pagina de informacao sobre
cada ordem de trabalho tem relacoes de dependencia complexas seguindo padroes
muito variaveis Por exemplo em cada ordem de trabalho existe um formulario que
permite a sua progressao de estado com diversos campos opcionais e obrigatorios
este formulario e definido pelo administrador e esta relacionado nao apenas com o
tipo de ordem de trabalho mas tambem com o estado actual em que esta se encontra
e a accao que se pretende realizar O elevado numero de combinacoes de tipos de
ordem de trabalho estados e accoes que existem num dado momento juntamente
com a sua possibilidade de alteracao obrigariam a implementacao de uma logica de
negocio complexa o que esta fora do ambito deste projecto
47
Desenvolvimento
Figura 410 Esquema UML que expressa os casos de uso do WOW Offline no modoldquoutilizador deciderdquo
463 Especificacao do modo ldquoaplicacao assume o estado offlinerdquo
A aproximacao para o modo ldquoaplicacao assume o estado offlinerdquo foi tambem
dividida em varias tarefas
1 Guardar informacao que permita a recriacao da pagina principal do lado do
cliente no estado offline (utilizando o Gears)
2 Dotar a aplicacao do cliente de um mecanismo de deteccao da ligacao
3 Identificar os ldquomomentos chaverdquo em que devera ocorrer sincronizacao de dados
4 Implementar a sincronizacao de dados
A sincronizacao de dados deve ser feita em ambas as transicoes online-offline e
offline-online quer para transferir novos dados do servidor (os pedidos podem ser
alterados por outros utilizadores) quando se transita do estado quer para comunicar
eventuais alteracoes feitas em modo offline
Relativamente ao WOW o WOW Offline na vertente ldquoaplicacao assume o es-
tado offlinerdquo vem alterar os seus casos de uso dando ao utilizador a possibilidade
de activar esta funcionalidade A partir do momento que a funcionalidade esta ac-
tivada o utilizador deve tambem ter a possibilidade de gerir algumas preferencias
relacionadas com privacidade de dados Devera ter a hipotese de desactivar o ar-
mazenamento local e de remover todos os dados ja armazenados tal como descrito
na Figura 411
48
Desenvolvimento
Figura 411 Esquema UML que expressa os casos de uso do WOW Offline no modoldquoutilizador deciderdquo
A primeira vez que o WOW Offline e acedido por um cliente e caso seja detec-
tada a presenca do Gears todos os recursos necessarios a sua execucao sao trans-
feridos Todos os acessos posteriores serao feitos a estes recursos locais (recorda-se
que o Gears pode ser utilizado para os manter actualizados recorrendo ao Managed-
ResourceStore 311)
Atraves do JavaScript e possıvel interceptar os eventos de load e unload da
pagina que sao despoletados sempre que ocorre um re-acesso da mesma (incluindo
a accao refresh comum dos browsers) sempre que esta e abandonada ou ainda ou
ainda se a janela for encerrada
Tal como sugerido na seccao 462 a camada de interface desta aplicacao (cada
pagina individual em HTML) devera ser implementada como sendo um template
para apresentacao de dados sendo totalmente preenchida atraves de funcoes em
JavaScript O objectivo deste ponto e criar um padrao de dados que permita ao
JavaScript preencher os dados em cada pagina (template) independentemente de
qual seja a fonte ndash o servidor remoto ou a maquina local tal como exemplificado
no diagrama da Figura 412 Na figura a aplicacao recorre ao servidor remoto para
obter os dados pretendidos quando se encontra na presenca de uma ligacao mas
para dados que exijam uma carga de processamento pelo servidor este acto pode ser
49
Desenvolvimento
Figura 412 Esquema UML que expressa o acto de recolha de dados em modo online eoffline recorrendo ao servidor (modo online) e ao sistema de armazenamento de dadoslocal fornecido pelo Gears (modo offline)
substituıdo pelo envio de um campo de controlo que se destina a aferir se os dados
locais se encontram actualizados No caso de estarem actualizados a comunicacao
com o servidor pode ser substituıda por uma query a base de dados local
50
Capıtulo 5
Resultados e Futuros
Desenvolvimentos
Todo o estudo feito sobre o tema OWA foi ja abordado ao longo do documento
Neste capıtulo apresentam-se os resultados obtidos na implementacao da prova de
conceito que visava compreender a melhor forma de disponibilizar uma versao of-
fline no WOW uma plataforma de gestao de ordens de trabalho ja existente de-
senvolvida pela Critical Software SA
51 Resultados Obtidos
Os resultados obtidos neste projecto sao extremamente satisfatorios uma vez
que o estudo do tema OWA e a implementacao de uma prova de conceito que o
ilustrasse foi conseguido com sucesso
A funcionalidade offline foi adicionada ao produto WOW da Critical Software
SA permitindo a visualizacao de ordens de trabalho e dos seus detalhes mesmo na
ausencia de uma conexao activa a Internet Embora para a solucao implementada
tenha sido utilizada uma abordagem do tipo ldquoutilizador deciderdquo pretende-se que esta
seja convertida para ldquoaplicacao deciderdquo ou mesmo para uma aproximacao hıbrida
semelhante a utilizada pelas aplicacoes estudadas nas seccoes 351 e 352
Para a sua implementacao descrita no capıtulo 4 foram tomadas decisoes de or-
dem pratica que permitissem tornar o trabalho exequıvel nos prazos dados Tentou-
se sempre que estas decisoes afectassem o mınimo em termos de desempenho e de
experiencia para o utilizador Considera-se que a implementacao do modo offline
com uma transicao entre modos do tipo ldquoutilizador deciderdquo (ver seccao 42) reflecte
o compromisso entre o desempenho pretendido e os recursos disponıveis e para alem
51
Resultados e Futuros Desenvolvimentos
de ser um exemplo eficaz das possibilidades que as OWA podem trazer a aplicacao
WOW desenvolvida pela Critical Software e tambem um estudo que pode ser uti-
lizado para analisar a implementacao desta tecnologia noutros produtos da mesma
empresa
Note-se que o principal objectivo do trabalho era ganhar familiaridade com este
tema entender as suas vantagens e desvantagens e compreender as suas limitacoes
Tudo indica que existam varias possibilidades de implementacao deste paradigma
noutros produtos da Critical Software que pela sua natureza podem tambem tirar
partido da execucao offline
52 Trabalho Futuro
O desenvolvimento do conceito e formas de implementacao de OWA continua
em forte desenvolvimento no entanto a sua adopcao ainda nao e generalizada A
dificuldade da sua implementacao em web applications ja existentes e o principal
obstaculo a sua maior divulgacao
Ha tambem um factor que deve ser tido em consideracao a manutencao de
codigo A implementacao de uma versao offline de uma web application requer
a implementacao das mesmas regras de negocio (ou de uma versao simplificada)
utilizadas no servidor Para que isto seja possıvel e necessario ter em conta a
capacidade de processamento do cliente e o factor de duplicacao de codigo que
tornara a aplicacao mais difıcil de manter uma vez que uma alteracao a logica de
negocio do servidor implica tambem uma alteracao a sua versao offline
A prova de conceito implementada permite ja a visualizacao offline dos pedidos
abertos (enviados e recebidos) que constam na pagina principal (este numero e
fixo e pode ser alterado pelo administrador) Uma funcionalidade desejavel seria a
possibilidade de interaccao com a aplicacao em modo offline e sincronizacao com o
servidor quando existisse uma ligacao disponıvel
Foi estudada a utilizacao do modo de execucao ldquoaplicacao assume o estado of-
flinerdquo descrito em 423 e esta seria a forma desejavel para o WOW Offline no
entanto para que esta opcao seja viavel sera necessaria a implementacao de uma
forma eficiente de sincronizacao e armazenamento de dados de uma forma relacional
Para atingir este objectivo podera ser seguida uma polıtica de automacao do pro-
cesso no qual a versao online da aplicacao gera scripts de criacao para as tabelas
necessarias na base de dados da versao offline (nao existe nenhuma ferramenta para
o fazer portanto seria necessaria a sua implementacao) e no qual as paginas HTML
disponibilizadas pelo servidor aos clientes web (browser) servem como templates de
apresentacao de informacao e sao preenchidas de forma semelhante pelo servidor ndash
quando a aplicacao estiver online ndash ou pelo cliente atraves de funcoes em JavaScript
52
Resultados e Futuros Desenvolvimentos
ndash quando a aplicacao estiver offline No entanto no WOW devido a quantidade de
informacao tratada e devido as complexas relacoes entre as diferentes entidades e
de esperar que a complexidade da implementacao de um mecanismo deste tipo torne
esta aproximacao demasiado custosa
O HTML 5 embora um forte candidato ainda nao esta suficientemente desen-
volvido A sua especificacao ainda tem o caracter de Draft (rascunho) e esta sujeita
a modificacoes e a aceitacao e implementacao por parte dos browsers e portanto
de momento foi desconsiderado No entanto no futuro se esta especificacao atingir
um estado de maturidade que permita a sua adopcao devera ser considerada como
um possıvel caminho a seguir
53
Resultados e Futuros Desenvolvimentos
54
Capıtulo 6
Conclusoes
Neste capıtulo sao apresentadas as conclusoes do projecto e consideracoes finais
relativamente a tecnologia estudada
61 Conclusoes
O rapido desenvolvimento tecnologico faz prever que a disponibilidade de ligacao
a Internet seja cada vez mais facil e mais rapido mas vao continuar a existir lugares
onde o acesso e limitado e onde as OWA podem desempenhar um papel de relevo
Por outro lado esta tecnologia pode tambem ser utilizada para melhorar o desem-
penho de paginas web com uma necessidade elevada de imagens ou outros recursos
dispendiosos em termos de espaco e foram ate estudados dois exemplos da utilizacao
desta vertente desta tecnologia em 353
Acredita-se que as OWAs vem responder a uma necessidade real por parte das
web applications actuais e que a evolucao que representam se compara a que se
assistiu dos thin-clients para os fat-clients em termos de autonomia do servidor
A capacidade de oferecer conteudos dinamicos no browser independentemente da
existencia de uma ligacao reune as vantagens tıpicas das web applications como
ausencia de instalacao e actualizacoes instantaneas com as vantagens das aplicacoes
de desktop em capacidade de processamento e armazenamento de dados na maquina
local
As tecnologias disponıveis ate a data estudadas no ambito deste projecto que
permitem o desenvolvimento de OWAs e que apresentam maior maturidade sao o
Gears e o Adobe AIR Ambas se apresentam sobre a forma de plugins que necessitam
de uma instalacao extra para poderem ser utilizadas Apesar de esta instalacao ser
55
Conclusoes
apenas necessaria uma vez podera constituir um factor de desencorajamento a sua
adopcao
O HTML 5 uma especificacao abordada neste documento na seccao 34 podera
ser uma alternativa que oferece funcionalidades offline a uma web application sem a
necessidade de qualquer instalacao no entanto esta especificacao ainda nao foi aceite
pelos principais browsers ndash o documento que define o HTML 5 ainda tem o estatuto
de Draft ndash e ainda nao e possıvel antecipar quando e que isto podera acontecer
Um dos problemas que surge frequentemente na implementacao de uma versao
offline para uma web application e a necessidade de sincronizacao de dados Quando
a informacao pode ser alterada por varios utilizadores simultaneamente e necessario
prever os conflitos que daı podem surgir e dotar a aplicacao de uma forma de os
resolver ou alertar o utilizador para a necessidade de alteracao dos dados
Em conclusao todos os objectivos propostos para este projecto foram atingidos
A prova de conceito implementada reflecte de forma clara as possibilidades oferecidas
pela tecnologia OWA e sera utilizado no futuro para compreender a melhor forma
de o implementar de forma definitiva no WOW
56
Referencias
[Ada08] Lucas Adamski Introducing Adobe AIR security model Fevereiro de2008 Disponıvel em httpwwwadobecomdevnetairarticles
introduction_to_air_securityhtml acedido em Marco de 2008
[Ado08] Adobe Adobe AIR 10 Security White Paper 2008 Disponıvel emhttpdownloadmacromediacompubairdocumentation1air_
securitypdf acedido em Marco de 2008
[Alm08] Dion Almaer Gears as a bleeding-edge html 5 implementa-tion March 2008 Disponıvel em httpalmaercomblog
gears-as-a-bleeding-edge-html-5-implementation acedido emMarco de 2008
[BL96] Tim Berners-Lee The world wide web Past present and future Agostode 1996 Disponıvel em httpwwww3orgPeopleBerners-Lee
1996ppfhtml acedido em Abril de 2008
[CDGH08] Mike Chambers Daniel Dura Dragos Georgita and Kevin Hoyt AdobeAIR for JavaScript Developers OrsquoReilly Media 2008 Disponıvel emhttponairadobecomfilesAIRforJSDevPocketGuidepdf ace-dido em Abril de 2008
[Con99] Jim Conallen Modeling Web Application Architectures with UML Junho1999 Disponıvel em httpwwwumlorgcnUMLApplicationpdf
webappspdf acedido em Maio de 2008
[Ent07] Entrust What is a public key information 2007 Disponıvel em http
wwwentrustcompkihtm acedido em Junho de 2008
[Gar05] Jesse James Garret Ajax A new approach to web applicationsFebruary 2005 Disponıvel em httpwwwadaptivepathcomideas
essaysarchives000385php acedido em Marco de 2008
[Greon] Philip Greenspun Philip and Alexrsquos Guide to Web Publishing 2003(last revision) Disponıvel em httpphilipgreenspuncompandaacedido em Junho de 2008
[Gro02a] App Design Group Thick vs thin client comparison 2002 Disponıvelem httpwwwdonjacobsvwcomimagesweekendspecials
Thick-vs-Thinpdf acedido em Junho de 2008
57
REFERENCIAS
[Gro02b] Technical Research Group Thin Client Tecnhology - WhitePaper 2002 Disponıvel em httpwwwpicktrgcompubs
thinclientwhitepaperpdf acedido em Junho de 2008
[Gro08] Miniwatts Marketing Group World internet usage March 2008Disponıvel em httpwwwinternetworldstatscomstatshtm ace-dido em Abril de 2008
[Hic08] Ian Hickson HTML 5 Draft Recommendation 2008 Disponıvelem httpwwwwhatwgorgspecsweb-appscurrent-work ace-dido em Marco de 2008
[Kha] Olga Kharif Top 10 municipal wifi plans Disponıvel em http
imagesbusinessweekcomss0608muni_wifiindex_01htm ace-dido em Marco de 2008
[Lab07] Mozilla Labs Prism Outubro 2007 Disponıvel em httplabs
mozillacom200710prism acedido em Marco de 2008
[Loo06] Chris Loosley Rich Internet ApplicationsDesign MeasurementandManagement Challenges 2006 Disponıvel em httpwwwkeynote
comdocswhitepapersRichInternet_5pdf acedido em Maio de2008
[Mic08] Microsoft Introduction to Occasionally Connected Applications us-ing Sync Services for ADONET 2008 Disponıvel em httpmsdn
microsoftcomen-ussyncbb887608aspx acedido em Junho de2008
[Nao08] Erica Naone Offline web applications Abril 2008 Disponıvelem httpwwwtechnologyreviewcomread_articleaspxch=
specialsectionsampsc=emerging08ampid=20245 acedido emAbril de 2008
[NJN00] Jason Nieh Yang S Jae and Naomi Novik A comparison of thin-clientcomputing architectures 2000 Disponıvel em httpwwwnclcs
columbiaedupublicationscucs-022-00pdf acedido em Maio de2008
[OrsquoR06] Tim OrsquoReilly Web 20 compact definition Trying again Dezembro2006 Disponıvel em httpradaroreillycomarchives200612
web-20-compact-definition-tryihtml acedido em Marco de 2008
[OrsquoR09] Tim OrsquoReilly What is Web 20 Design patterns and business modelsfor the Next Generation of Software 20053009 Disponıvel emhttpwwworeillynetcompubaoreillytimnews200509
30what-is-web-20html acedido em Marco de 2008
[Rus06] Alex Russel Comet Low latency data for the browser March Marco2006 Disponıvel em httpalexdojotoolkitorgp=545 acedidoem Marco de 2008
58
REFERENCIAS
[Sad97] Darleen Sadoski Clientserver software architecturesndashan overviewAgosto 1997 Disponıvel em httpwwwseicmuedustr
descriptionsclientserver_bodyhtml acedido em Junho de2008
[Sch96] George Schussel Clientserver past present and future 1996
[Smi07] Kevin C Smith Css filters - will the browser apply the rule July 2007Disponıvel em httpcentriclecomrefcssfilters acedido emMarco de 2008
[vK08] Anne van Kesteren The XMLHttpRequest Object W3C Work-ing Draft 15 Abril 2008 Disponıvel em httpwwww3orgTR
XMLHttpRequest acedido em Abril de 2008
[Wil06] Greg Wilkins Why ajax comet July Julho 2006 Disponıvel emhttpwwwwebtidecomdownloadswhitePaperWhyAjaxhtml ace-dido em Abril de 2008
59
REFERENCIAS
60
Anexo A
Screenshots
Algumas imagens de aplicacoes que utilizam funcionalidades offline ilustrativasda tecnologia abordada neste documento
Figura A1 Dialogo apresentado ao utilizador na primeira activacao das funcionalidadesoffline no Google Docs amp Spreadsheets
61
Screenshots
Figura A2 Na activacao das funcionalidades offline e tambem oferecida a possibilidadeda criacao de alguns atalhos por exemplo no ambiente de trabalho
Figura A3 O Google Docs mantem a todo o momento a possibilidade de alteracao destasdefinicoes ou da anulacao dos servicos offline para um dado computador
62
Screenshots
Figura A4 Apos a instalacao do Gears qualquer visita ao Remember The Milk despoletauma sincronizacao que ocorre automaticamente e sem necessidade de intervencao por partedo utilizador
Figura A5 Apos completar a sincronizacao de dados mesmo que a ligacao a Internetseja perdida o Remember the Milk continua disponıvel no browser (com excepcao dasfuncionalidades que pela sua natureza exigem uma ligacao como por exemplo partilhade tarefas e envio de convites)
63
Glossario
fat-client Cliente que nao depende totalmente de umservidor central para as suas actividadesde processamento e possui frequentementedispositivos de armazenamento de dados
6ndash8
thin-client Cliente que depende de um servidor centralpara as suas actividades de processamento
5ndash8
web application Sistema web (servidor rede HTTPbrowser) onde accoes do utilizador(navegacao e introducao de informacao)afectam o estado logico da aplicacao
i iii1ndash311ndash1517ndash1921ndash232728 3336ndash3842 5556
API Application Programming Interface 10 1718 2326 28
ASP Linguagem interpretada pelo servidorque permite a criacao de paginas webdinamicas Desenvolvida pela Microsoft
11
BSD Berkeley Software Distribution 28
CSS Cascading Style Sheets 12 2021 2324 46
DHTML Dynamic HyperText Transfer Protocol 24DOM Document Object Model 10 12
20 2324
DTD Document Type Definition 24
xiii
Glossario
ECMAScript Padrao de linguagem de programacaodefinido pela Ecma International que orig-inou o JavaScript e o JScript
24
Flash Conteudo interactivo de um ficheiro emformato SWF E desenvolvido pela Adobee visualizado atraves do Adobe FlashPlayer
21
Flex Framework baseada em XML e Action-Script desenvolvida pela Adobe para a pro-gramacao de Rich Internet Applications(RIA)
21
GPL GNU General Public License 23
HTML HyperText Markup Language 1 10ndash12 2124ndash2649
HTTP HyperText Transfer Protocol 2 26
JMS E uma API em Java que permite a troca demensagens entre componentes de software
42
JSON JavaScript Object Notation permite atroca de dados codificados num formatode texto de simples leitura
12 1828 34
LGPL GNU Lesser General Public License 23
Mozilla Prism Browser simplificado e ldquointerpretadorrdquo deeXtensible User Interface Language (XUL)(tambem designado por XULRunner) queacolhe web applications sem a interfacegrafica habitual de um browser
25
MPL Mozilla Public License 23
OCA Occasionally Connected Application 39OWA Offline Web Application i iii
2ndash515 1725 2628 3133 3651 5255 56
PDF Portable Document Format 21
xiv
Glossario
PHP Linguagem interpretada pelo servidorque permite a criacao de paginas webdinamicas mas que pode tambem ser in-vocada a partir da linha de comandos
11
pagina web estatica Pagina web que devolve sempre a mesmaresposta a todos os pedidos para todos osutilizadores e em qualquer contexto
5 9
RIA Rich Internet Applications web appli-cations que apresentam funcionalidadessemelhantes as desktop applications masque mantem a informacao no lado do servi-dor
5 1520 28
RSS Really Simple Syndication 27
SLA Service Level Agreement 40SQLite Segundo a definicao oficial SQLite is a
software library that implements a self-contained serverless zero-configurationtransactional SQL database engine
17
SSB Site Specific Browser 25SSL Secure Sockets Layer 22SWF ShockWave Flash 21
URL Uniform Resource Locator 18
VPN Virtual Private Network 38
WOW Work Orders Web Plataforma de gestaode ordens de trabalho e do seu fluxo de-senvolvida pela Critical Software SA
i iii28 3340ndash434551ndash5356
WWW World Wide Web 11 1214
XBL eXtensible Binding Language 24XHTML eXtensible HyperText Markup Language 12XML eXtensible Markup Language 11 12
23 2428
XSLT eXtensible Stylesheet Language Transfor-mation
12
XUL eXtensible User Interface Language xiv23ndash25
xv
Glossario
xvi
Capıtulo 1
Introducao
Neste capıtulo enquadra-se o tema do projecto introduzindo alguns dos conceitos
nos quais se baseia Apresentam-se as motivacoes ambito objectivos e a estrutura
deste documento
11 Enquadramento
A Internet foi originalmente concebida para ser um espaco de partilha de in-
formacao onde pessoas (atraves de maquinas) pudessem comunicar Na sua origem
as paginas eram estaticas constituıdas por texto formatado em HyperText Markup
Language (HTML) e ligadas entre si [BL96] Hoje encontramos conteudos cada vez
mais complexos e dinamicos incluindo som vıdeo ou streams multimedia [Loo06] e
em 2005 foi introduzido por [OrsquoR09] o termo Web 20
De acordo com [Greon] um website pode pertencer a uma ou varias das seguintes
categorias
bull Documento ndash um website essencialmente estatico onde alteracoes a uma
parte do conteudo nao tem implicacoes no seu comportamento
bull Base de dados ndash um directorio de informacao organizada em categorias
bull Aplicacao ndash um website dinamico que utiliza uma linguagem executada ou
interpretada do lado do servidor e que processa as accoes ou informacao in-
troduzida pelo utilizador para fornecer um servico ou nova informacao
A ultima destas categorias constitui aquilo que e normalmente designado por
web application O conceito utilizado ao longo deste documento e o mesmo que
o introduzido por Jim Coallen em [Con99] que define web application como um
1
Introducao
sistema web (servidor rede HyperText Transfer Protocol (HTTP) browser) onde
accoes do utilizador (navegacao e introducao de informacao) afectam o estado logico
da aplicacao A sua definicao tenta estabelecer que uma web application e um
sistema de software com estado de negocio1 e que a sua interface de interaccao com
o utilizador e distribuıdo atraves de um sistema web
12 Motivacao
A quantidade de informacao que e produzida e armazenada com recurso a es-
tas web applications disponıveis online tais como e-mail blogues ou mesmo docu-
mentacao tornam por vezes a disponibilidade de ligacao uma condicao necessaria
a produtividade e como consequencia desta barreira muitos potenciais utilizadores
opoem-se a adopcao de produtos web em detrimento das tradicionais desktop appli-
cations
Assegurar o acesso a uma ligacao de Internet e hoje muito mais facil A Internet
movel e ja uma realidade e encontra-se amplamente divulgada mas continuam a
existir diversas situacoes nas quais os utilizadores estao privados de uma ligacao
a Internet tais como uma viagem de metro ou de aviao ou quando se encontram
deslocados do seu paıs de origem e nao possuem nenhum plano de subscricao
Uma OWA consiste numa web application que para alem de manter todas as
caracterısticas anteriores se mantem disponıvel mesmo na ausencia de uma ligacao
a Internet e surge como uma tentativa de estreitar as barreiras existentes entre a
web e o desktop Isto significa que devera existir um mecanismo capaz de assegurar
a manutencao do estado logico da aplicacao quando a ligacao com o servidor e
quebrada permitindo ao utilizador continuar a utilizar a aplicacao e que sera capaz
de informar o servidor do estado em que a aplicacao se encontra quando a ligacao for
reposta A principal vantagem que advem desta possibilidade e evidente eliminar
a necessidade da existencia de uma ligacao a Internet para que a aplicacao possa ser
utilizada
Por outro lado a vontade de integracao de funcionalidades tıpicas das desktop
applications nas web applications foi um dos principais factores que impulsionou o
desenvolvimento deste conceito uma vez que obrigou a uma reflexao ldquopara alem
do browserrdquo e a uma adaptacao das arquitecturas existentes que permitisse ou o
acesso a funcionalidades disponibilizadas pelo sistema operativo ou pelo menos a
funcionalidades semelhantes Pretende-se com esta aproximacao tornar possıveis
interaccoes entre o desktop e o browser tais como arrastar um ficheiro para um
formulario web de upload de conteudos melhor suporte para o historico do clipboard
ou ainda o acesso ao sistema de ficheiros local Atingir estes objectivos reflecte-se
1NT business state
2
Introducao
num novo paradigma que reune as vantagens das web applications tais como os
updates instantaneos ou o facto de nao ser necessaria nenhuma instalacao e das
desktop applications como por exemplo persistencia no armazenamento de dados
acesso a funcionalidades do sistema operativo ou integracao e interaccao com outras
aplicacoes sejam elas web applications ou desktop applications
13 Ambito
Este projecto foi realizado na Critical Software SA no ambito do Mestrado
Integrado em Engenharia Informatica e Computacao (MIEIC) da Faculdade de En-
genharia da Universidade do Porto (FEUP) entre os meses de Fevereiro e Julho de
2008
14 Objectivos
Sao objectivos deste projecto
1 Estudar e documentar o tema das OWAs acompanhando os ultimos desenvolvi-
mentos nesta materia
2 Analisar o estado da arte fazendo uma analise crıtica e objectiva sobre as
diversas metodologias existentes
3 Implementar uma prova de conceito que permita a execucao offline de uma
web application documentando todo o processo
4 Estudar a possibilidade de permitir interaccao com a aplicacao (insercoes e
alteracoes aos dados) em modo offline
Em resumo o objectivo deste projecto foi estudar documentar e implementar
uma prova de conceito relacionada com o tema Offline Web Applications (OWA)
Este tema embora nao seja totalmente novo ganhou destaque ao longo do ano de
2007 com o surgimento de diversas ferramentas que se destinam a aproximar web
applications das desktop applications
15 Estrutura do documento
Este documento esta organizado em diferentes seccoes apresentando o projecto
numa sequencia logica organizada da seguinte forma
No capıtulo 1 faz-se uma breve apresentacao do conceito OWAs e do contexto em
que surge Apresenta-se tambem a estrutura do documento e definem-se os
termos e acronimos utilizados
3
Introducao
No capıtulo 2 faz-se uma descricao da evolucao das tecnologias que antecedem as
OWAs e das vantagens e desvantagens de cada uma como forma de enquadra-
mento
No capıtulo 3 analisa-se o estado da arte nesta materia Introduzem-se diversas
tecnologias directamente relacionadas com o tema deste projecto exemplos de
aplicacoes que as usam e as razoes que fundamentam as escolhas de tecnologias
efectuadas
O capıtulo 4 contem o desenvolvimento do projecto Analisa-se a plataforma
WOW de gestao integrada de ordens de trabalho a tecnologia escolhida e
a forma como foi utilizada para implementar a capacidade de execucao offline
O capıtulo 5 descreve os resultado obtidos comparando-os com as expectativas
iniciais do projecto e apresenta desenvolvimentos futuros e possibilidades de
continuacaoaplicacao do conhecimento adquirido
No capıtulo 6 apresentam-se as conclusoes
4
Capıtulo 2
Enquadramento do Projecto
Neste capıtulo apresenta-se um breve resumo da evolucao das arquitecturas de
software cliente-servidor e a forma como estas se comparam a evolucao da Inter-
net procurando estabelecer uma analogia entre o percurso de ambas as tecnolo-
gias Compara-se o comportamento e arquitectura dos thin-clients as paginas web
estaticas a evolucao dos fat-clients as paginas interactivas Web 20 e Ajax e
defende-se que as OWA constituem um proximo passo logico e evolutivo aproxi-
mando a web do desktop Referem-se ainda os principais factores que justificam a
importancia das OWAs e a estreita relacao que tem com as Rich Internet Application
(RIA)s
21 Evolucao das arquitecturas de software
Os termos thin-client e fat-client sao utilizados quer para descrever arquitecturas
logicas (de software) quer para descrever arquitecturas fısicas (de hardware) Neste
capıtulo excepto quando seja dada indicacao em contrario estes termos referem-se
sempre a uma arquitectura logica
Adicionalmente quando se trata de arquitecturas cliente-servidor pode-se estu-
dar a arquitectura desenvolvida do sistema como um todo da arquitectura do servi-
dor ou da arquitectura do cliente Para evitar equıvocos em especial na seccao 213
especifica-se em cada caso qual o sistema estudado
211 Thin-clients
Um thin-client e um computador cliente ou software cliente que no contexto
de uma arquitectura cliente-servidor depende de um servidor central para as suas
5
Enquadramento do Projecto
actividades de processamento e proporciona um canal de entrada e saıda de in-
formacao entre o utilizador e o servidor remoto Este termo quando aplicado a
hardware refere-se habitualmente a um computador que se destina a ser utilizado
como cliente de rede sem armazenamento local e com capacidade de processamento
reduzida [Gro02b] mas o conceito que aqui se analisa refere-se a uma arquitectura
de software que remonta ao inıcio das aplicacoes cliente-servidor
No inıcio da historia da computacao terminais ligavam-se directamente a main-
frames responsaveis por todo o processamento Nesta arquitectura era necessario
desenvolver duas aplicacoes distintas uma aplicacao central no servidor (main-
frame) responsavel pela gestao de toda a informacao e por todas as operacoes de
comunicacao e uma aplicacao de visualizacao instalada no cliente (terminal) O
papel destes terminais era apenas disponibilizar ao utilizador um meio de comu-
nicacao (entrada e saıda) e apresentacao dos resultados do servidor Nao tinham
um papel activo no calculo nem na logica de negocio e frequentemente nao tinham
tambem nenhum mecanismo de armazenamento de dados
Como vantagens esta arquitectura apresenta uma reduzida necessidade de con-
figuracao e manutencao do lado do cliente Uma vez que o centro do processamento
e manipulacao de dados ocorre no servidor existe tambem uma centralizacao da
informacao [NJN00] que introduz um ponto crıtico de falha1 Actualizacoes e novas
funcionalidades sao faceis de distribuir uma vez que requerem apenas alteracoes no
servidor [Gro02a]
212 Fat-clients
Contrastando com os thin-clients nesta arquitectura os clientes implementam
ja uma parte da logica de negocio e sao responsaveis pelo processamento de dados
Estes fat-clients vieram responder a necessidade crescente de aplicacoes com um
nıvel de interactividade e capacidade de configuracao maior que as oferecidas pela
arquitectura thin-client descrita na seccao 211 Apesar de manterem a sua de-
pendencia do servidor podem tambem ser executados sem uma conexao activa uma
vez que dispoe de armazenamento de dados local o que lhes confere a capacidade
de persistencia de dados e do estado de execucao entre cada sessao
Foi disponibilizando este controlo sobre o estado da aplicacao bem como acesso
a recursos locais (por exemplo sistema de ficheiros e perifericos) que surgiram as
primeiras verdadeiras desktop applications No entanto cada cliente tinha que ser
separadamente instalado no computador pessoal de cada utilizador que pretendesse
utilizar ou interagir com a aplicacao e uma actualizacao ao servidor implicava in-
variavelmente uma actualizacao manual tambem no cliente Uma vez que nem todos
1NT single point of failure
6
Enquadramento do Projecto
Thin-clients Fat-clientsNao toma parte no processamento dedados nem possui acesso ao sistema deficheiros
Participa activamente no processa-mento de dados recorrendo ao sis-tema de armazenamento local para ar-mazenamento de dados
Nao mantem registo do estado logicoda aplicacao entre duas sessoes de uti-lizacao
O acesso ao armazenamento localpermite-lhe manter registo do estadologico da aplicacao entre duas sessoes
O thin-client nao necessita de qualquerinstalacao estando ldquopronto a utilizarrdquo
E geralmente necessario instalar aaplicacao para poder interagir com oservidor
Qualquer update no servidor reflecte-seimediatamente por todos os clientes
Embora a aplicacao cliente possa aler-tar para existencia de novas versoes asactualizacoes tem que ser manualmenteinstalados pelo cliente
O software do cliente destina-se apenasa apresentacao de dados e comunicacaocom o servidor sendo portanto de sim-ples implementacao
Como o software do cliente toma parteactiva no processamento de dadosa sua implementacao requer cuidadosadicionais
Grande mobilidade uma vez que todaa informacao e mantida no servidor
Parte da informacao podera estar ape-nas do lado cliente pelo que existemalgumas restricoes a sua mobilidade
Tabela 21 Comparacao entre thin-clients e fat-clients
os utilizadores actualizam regularmente as suas aplicacoes o servidor tem que estar
preparado para lidar com versoes antigas2 ou descontinuar os seus servicos a uma
parte da sua comunidade de utilizadores ate que estes actualizem os seus sistemas
Como os utilizadores passam a utilizar os seus recursos locais para armazenamento
de dados as alteracoes que nao sejam sincronizadas com o servidor estao apenas
disponıveis nos seus computadores pessoais o que introduz uma restricao a mobili-
dade
Pode-se afirmar que as vantagens dos thin-clients sao as desvantagens dos fat-
clients e que as vantagens dos fat-clients sao as vantagens dos thin-clients tal como
se ilustra na Tabela 21
213 Arquitecturas cliente-servidor
Introduzidos os termos thin-client e fat-client interessa reafirmar que ambos
podem ser vistos como arquitecturas cliente-servidor Um cliente define-se como
um solicitador de servicos e um servidor como um prestador de servicos tal como
definido por [Sch96] e [Sad97]
2NT backward compatibility
7
Enquadramento do Projecto
As arquitecturas cliente-servidor sao categorizadas pela modularizacao com que
sao desenhadas sendo consideradas as seguintes camadas
1 Interface grafica (front-end) atraves da qual os utilizadores interagem com
a aplicacao Quando este modulo e implementado separadamente dos outros
dois constitui uma aplicacao thin-client por si so uma vez que nao implementa
regras de negocio (embora possa definir validacoes de formularios de insercao de
dados por exemplo) A informacao introduzida pelo utilizador e enviada para
o servidor que processa o seu pedido e retorna uma resposta Este processo
repete-se ate que o utilizador atinja o seu objectivo ou se desligue do sistema
2 A logica de negocio tambem designada por camada intermedia que imple-
menta as regras de aceitacao e validacao de todos os dados introduzidos pelo
utilizador E tambem a plataforma de comunicacao que une a camada superior
de visualizacao com a camada de acesso a dados
3 A camada de dados inclui quer o sistema de persistencia de dados onde sao
armazenados os dados relevantes como tambem os mecanismos necessarios
para a sua pesquisa seleccao e alteracao
Os thin-clients quando observados no seu conjunto de cliente e servidor podem
ser vistos quer como sistemas de duas camadas quer como sistemas de tres camadas
dependendo apenas da forma como o servidor for implementado No caso de na
implementacao do servidor nao se distinguir a camada de acesso a dados da camada
da logica de negocio sao designados por sistemas de duas camadas Caso seja feita
esta distincao sao designados por sistemas de tres camadas Ambos os casos sao
ilustrados na Figura 21
Historicamente os fat-clients eram implementados numa arquitectura em duas
camadas Possuıam apenas um modulo de visualizacao de dados designado por
camada de interface e um modulo que implementava toda a logica de negocio e
regras de acesso a base de dados No entanto com a introducao de ligacoes mais
rapidas e de computadores pessoais com maior capacidade de processamento e so-
bretudo devido a complexidade crescente das aplicacoes a logica de negocio e a
camada de acesso a dados tornaram-se independentes Este modelo e designado por
arquitectura em tres camadas e e ilustrado na Figura 22
22 Evolucao na Internet
Ao analisar a evolucao das arquitecturas das aplicacoes desenvolvidas para a
Internet podemos encontrar um paralelismo com a historia da arquitectura de soft-
ware
8
Enquadramento do Projecto
Figura 21 Arquitectura de um sistema thin-client em duas camadas (a esquerda) e emtres camadas (a direita) Note-se a inclusao do servidor (mainframe) na definicao dascamadas desta arquitectura devido a forte dependencia cliente-servidor
221 Paginas web estaticas
Uma pagina web estatica devolve sempre a mesma resposta a todos os pedidos
para todos os utilizadores e em qualquer contexto utilizando o hipertexto como
forma de ligacao entre diversas paginas estaticas
A informacao e armazenada num servidor e o papel do cliente e apenas a apre-
sentacao da informacao Esta forma de disponibilizacao de informacao pode assim
ser comparada com os thin-clients descritos na seccao 211 o utilizador acede a
um website estatico para visualizar informacao sem que o cliente tome parte no
processamento A unica diferenca e que no caso da web estatica a informacao ap-
resentada e sempre a mesma enquanto que nos thin-clients era frequente existir a
possibilidade de insercao de dados no cliente e apos o seu processamento servidor
nova informacao poderia ser apresentada O hipertexto e utilizado para ligar as
paginas entre si numa rede de conteudos relacionados e a navegacao sıncrona era
feita atraves de cliques do rato a cada clique uma nova pagina era apresentada
Este modelo sıncrono e ilustrado na Figura 23
222 Paginas web interactivas e paginas web dinamicas
O JavaScript e uma linguagem interpretada de scripting que tem os browsers
como principal ambiente de acolhimento Os browsers utilizam uma Application
9
Enquadramento do Projecto
Figura 22 Arquitectura de um fat-client em duas camadas (a esquerda) e em tres camadas(a direita)
Programming Interface (API) publica para criar ldquoobjectosrdquo responsaveis por reflectir
e disponibilizar o Document Object Model (DOM) para o motor de JavaScript
A utilizacao mais frequente desta linguagem e a escrita de funcoes que sao em-
bebidas ou incluıdas em paginas web e que interagem com o DOM Uma vez que o
JavaScript e executado localmente (na maquina do cliente e nao no servidor) e capaz
de responder rapidamente a accoes do utilizador tornando a execucao de aplicacoes
no browser mais fluıdas o JavaScript pode tambem detectar accoes do utilizador
que o HTML nao pode tal como o pressionar de uma tecla
Em Dezembro de 1995 a Netscape Communications adicionou suporte para o
JavaScript no browser Netscape Navigator3 e em Agosto de 1996 o browser Internet
Explorer4 da Microsoft passou a tambem a suportar uma versao semelhante desta
linguagem (hoje todos os principais browsers suportam esta tecnologia)
Esta inovacao permitiu tornar os websites mais interactivos mas a sua utilizacao
esteve confinada apenas a este proposito durante um longo perıodo As paginas
passaram a responder activamente a accoes do utilizador (sendo uma das utilizacoes
3Netscape Communications ndash httpbrowsernetscapecom4Microsoft Internet Explorer ndash httpwwwmicrosoftcomwindowsproductswinfamilyie
10
Enquadramento do Projecto
mais vulgares a validacao de formularios) mas continuaram essencialmente estaticas
O JavaScript ainda nao era nesta altura utilizado para processar dados
Tambem nesta altura (1995ndash96) surgiram linguagens server-side como o PHP
Hypertext Preprocessor (PHP) e Active Server Pages (ASP) e o servidor passou a ter
um processamento de dados introduzidos pelo utilizador mais activo Generalizaram-
se as paginas dinamicas capazes de responder a insercao de dados ou outros pedidos
determinados por accoes do utilizador As paginas tornaram-se aplicacoes web ap-
plications
Uma definicao tradicional de web application e um conjunto de paginas web
logicamente agrupadas e geridas por uma unica entidade que tem como pontos de
entrada formularios de insercao de dados (web forms) Uma web application nao e
mais do que uma aplicacao que e acedida atraves de um browser Tem geralmente
uma arquitectura logica em tres (interface logica de negocio e camada de dados)
camadas e estao armazenadas num servidor
Ha dois tipos de web applications
bull Orientadas a apresentacao Sao web applications que geram paginas web in-
teractivas constituıdas por varios tipos de linguagens de anotacao (por exem-
plo HTML eXtensible Markup Language (XML)) e que apresentam conteudo
dinamico como resposta a pedidos efectuados pelo utilizador
bull Orientadas aos servicos Uma web application orientada aos servicos imple-
menta o ponto de acesso para um ou mais de um web service Sao geralmente
clientes de service oriented web applications
Uma vantagem significativa de implementar uma web application de forma a
suportar as funcionalidades padrao dos browsers e que estas terao o mesmo com-
portamento independentemente da plataforma e do browser a partir do qual serao
acedidas No entanto diferentes implementacoes de browsers devido a diferentes
interpretacoes dos padroes definidos tornam por vezes esta tarefa um pouco mais
complicada existindo inclusivamente na web guioes de compatibilidade para os difer-
entes browsers como [Smi07]
223 Web 20 e Ajax
O termo web 20 descreve uma tendencia de utilizacao e de design observada
na World Wide Web (WWW) com o objectivo de melhorar a criatividade partilha
de informacao e principalmente a colaboracao entre utilizadores Estes conceitos
levaram ao desenvolvimento e evolucao de comunidades online tais como redes so-
ciais wikis e blogues
11
Enquadramento do Projecto
O termo tornou-se mais conhecido apos a primeira conferencia OrsquoReilly Media
Web 20 em 2004 e apesar de sugerir uma nova versao da WWW nao se refere a
qualquer evolucao tecnologica mas apenas a alteracoes a forma como os utilizadores
se servem da web De acordo com Tim OrsquoReilly [OrsquoR06] ldquoWeb 20 e uma revolucao
na industria do software causada pela adopcao da web como uma plataforma e pela
tentativa de entendimento das regras para o sucesso nesta nova plataformardquo
O desenvolvimento da Web 20 serve-se muitas vezes de um outro conceito Ajax
O conceito que hoje conhecemos como Ajax muitas vezes incorrectamente de-
scrito como uma tecnologia foi originalmente criado para permitir o desenvolvimento
de web applications que se assemelhassem ainda mais a aplicacoes de desktop Este
conceito foi melhor descrito por [Gar05] como um conjunto de varias tecnologias
que podem ser utilizadas para melhorar a experiencia do utilizador de uma dada
web application introduzindo a capacidade assıncrona de envio de pedidos ou da
recepcao assıncrona de respostas As tecnologias mais frequentemente envolvidas
sao
bull eXtensible HyperText Markup Language (XHTML) e Cascading Style Sheets
(CSS) padrao para a apresentacao
bull interaccao dinamica atraves do DOM
bull troca e manipulacao de dados utilizando XML e eXtensible Stylesheet Lan-
guage Transformation (XSLT) ou JavaScript Object Notation (JSON)
bull pedidos assıncronos utilizando XMLHttpRequest [vK08]
bull JavaScript utilizado para integrar todas estas tecnologias
E importante frisar que o Ajax nao e um produto nem uma tecnologia E um
termo que descreve a utilizacao de um conjunto de tecnologias para o desenvolvi-
mento de web applications com um elevado grau de interactividade Comparativa-
mente as web applications tradicionais o Ajax introduz uma camada de visualizacao
diferente em tres importantes pontos
1 Do lado do cliente existe um motor que serve de intermediario entre a interface
da aplicacao e o servidor
2 A actividade do utilizador despoleta chamadas JavaScript em vez de um pedido
de pagina directamente ao servidor
3 Informacao codificada em XML em vez de paginas HTML e trocada entre o
servidor e o cliente
12
Enquadramento do Projecto
Isto significa que as paginas que utilizam Ajax contem um motor do lado do
cliente composto por um conjunto de funcoes JavaScript responsavel pela comu-
nicacao com o servidor e por actualizar a interface com o resultado dessa mesma
comunicacao
Na Figura 23 ilustra-se a natureza assıncrona do Ajax quando comparada com
as web applications tradicionais Como se pode observar adicionando um mecan-
ismo Ajax a uma web application eliminam-se diversos tempos de espera associados
a comunicacoes com o servidor uma vez que a interface nao fica ldquobloqueadardquo a es-
pera da resposta Obtem-se assim aplicacoes com um comportamento mais fluido
eliminando tempos de espera entre cada ldquocliquerdquo e melhorando a experiencia do
utilizador
23 Offline Web Applications
A informacao grafica (bem como folhas de estilo e scripts) tais como as ima-
gens que constituem o visual de uma web application e ja tratada de forma especial
pelos cada vez mais avancados sistemas de cache (armazenamento temporario) dos
browsers Mas estes nao sao ainda capazes de guardar conteudo criado pelo uti-
lizador nem de apresentar informacao independentemente do estado da ligacao
Numa altura onde se fala de servicos de Internet wireless municipalizados [Kha]
comunicacoes 3G e ligacoes de banda larga a alta velocidade a ligacao a rede global
continua a nao estar permanentemente disponıvel para os utilizadores Na WWW
encontra-se uma importante parte da informacao e das aplicacoes utilizadas para
criar e editar conteudos Por vezes informacao vital para a produtividade pode
desaparecer subitamente do mapa de acesso de um utilizador quando este entra no
metro num aviao ou mesmo quando se desloca para uma cidade ou paıs diferente
do habitual onde nao subscreve um plano de acesso que lhe garanta a ligacao
Permitir o acesso offline a estes recursos assume assim a sua importancia porque
permitira estender o alcance da informacao a locais onde nunca esteve antes e per-
mitira tambem melhorar o desempenho das web applications colocando informacao
mais perto dos utilizadores reduzindo a transferencia de dados apenas ao essencial
24 Comparacao
Nas evolucoes descritas neste capıtulo 2 pode-se observar que existe um par-
alelismo entre a evolucao das arquitecturas tradicionais cliente-servidor e a evolucao
a que se assiste na web O comportamento e arquitectura dos thin-clients assemelha-
se ao das paginas estaticas no sentido em que o browser nao toma parte em qualquer
13
Enquadramento do Projecto
processamento e serve apenas como uma plataforma de interaccao com o servidor
tal como os clientes descritos na seccao 211
A sua proxima evolucao os fat-clients trouxeram parte da capacidade de pro-
cessamento para o lado do cliente Na web foi tambem esta a inovacao tecnologica
a que se assistiu com a evolucao das tecnologias que permitiram a criacao de ver-
dadeiras aplicacoes e com a introducao do Javascript no browser dando ao cliente
a capacidade de processamento de dados A necessidade da separacao do codigo
em camadas logicas advem da crescente complexidade das web applications Esta
pratica permite entre outras coisas melhorar o processo de desenvolvimento e a
capacidade de manutencao de uma aplicacao
Os fat-clients tem tambem a capacidade de armazenamento de dados o que
permite a persistencia de informacoes entre duas sessoes e que algumas operacoes
sejam executadas sem a necessidade de comunicacao com o servidor Este facto pode
tambem ser uma realidade nas web applications com a adopcao das tecnologias OWA
Neste momento assiste-se a uma utilizacao cada vez maior da web como uma
plataforma de desenvolvimento A capacidade de cooperacao na edicao de conteudos
e a mobilidade proporcionada por esta plataforma sao os principais factores que
alimentam esta mudanca e pela primeira vez as aplicacoes tradicionais tem com-
peticao vinda de web applications A prova do reconhecimento da web como plataforma
de desenvolvimento pode ser retirada da aposta de empresas como a Adobe e Mi-
crosoft que lancaram publicamente ferramentas web complementares a produtos
seus tradicionalmente associados ao desktop ndash Acrobatcom5 e Microsoft Office
Live6 Dotar estas web applications da capacidade de execucao offline significa
aproximar a web e o desktop reunindo ldquoo melhor de dois mundosrdquo
As vantagens da mobilidade possıvel atraves da web a cooperacao na criacao e
edicao de conteudos e a possibilidade de utilizar aplicacoes sempre actualizadas e
sem necessidade de instalacao sao algumas das principais vantagens que promovem
esta mudanca que devido as preocupacoes associadas a usabilidade e experiencia do
utilizador esta fortemente associada ao desenvolvimento de Rich Internet Applica-
tion (RIA)s
5Adobe Acrobatcom httpwwwacrobatcom6Microsoft ndash httpsmallbusinessofficelivecom
14
Enquadramento do Projecto
Figura 23 Comparacao do modelo de web aplications sıncrono paginas estaticas e in-teractivas abordados nas seccoes 221 e 222 com o modelo de web applications Ajax(assıncrono) abordado na seccao 223 Figura adaptada de http www adaptivepath
com
15
Enquadramento do Projecto
16
Capıtulo 3
Estado da arte
Apesar de o conceito das OWAs nao ser absolutamente novo as tecnologias que
o suportam sao recentes Neste capıtulo descrevem-se quatro tecnologias que foram
tidas como principais candidatas para o desenvolvimento deste projecto Descrevem-
se ainda alguns exemplos de web applications que disponibilizam actualmente fun-
cionalidades offline e o processo da escolha da tecnologia a utilizar neste projecto
31 Gears
O Gears1 e uma extensao as funcionalidades do browser introduzido pelo Google
que tem como principal objectivo tornar possıvel a visualizacao de paginas de Inter-
net mesmo sem uma conexao disponıvel Encontra-se disponıvel para as platafor-
mas Windows Macintosh e Linux e oferece uma API de Javascript que permite
a scripts aceder a um mecanismo de armazenamento local baseado numa base de
dados SQLite
311 Arquitectura
Esta ferramenta e constituıda por tres componentes principais
bull LocalServer mdash Intercepta pedidos de paginas web e serve-as localmente
bull Database mdash Uma base de dados relacional construıda sobre SQLite
bull WorkerPool mdash Permite executar operacoes de computacao de uma forma
assıncrona sem afectar a capacidade de resposta e fluidez de execucao da web
application Assemelham-se a processos
1Google Inc ndash Mais informacao em httpgearsgooglecom
17
Estado da arte
LocalServer
O modulo LocalServer e uma cache de Uniform Resource Locators (URLs)
controlada pela web application Quando nao existe uma ligacao a Internet e e
feito um pedido para um URL presente nesta cache o LocalServer intercepta-o e
responde ao pedido localmente a partir do disco rıgido do utilizador A aplicacao
pode utilizar dois tipos diferentes de armazenamento local de URLs
bull ResourceStore ndash serve para capturar URLs utilizando exclusivamente a API
de Javascript disponibilizada para o efeito Uma aplicacao podera criar e
utilizar diversos ResourceStores simultaneamente para capturar ficheiros de
dados que necessitam de ser enderecados por um URL tal como um ficheiro
PDF ou uma imagem
bull ManagedResourceStore ndash serve para capturar um conjunto de URLs que estao
relacionados e que sao declarado num ficheiro de manifesto (especificado em
JSON) e que sao automaticamente actualizados O ManagedResourceStore
permite que o conjunto de recursos necessarios para correr uma web application
seja capturado e mantido actualizado automaticamente
A principal diferenca entre estes dois tipos de armazenamento de URLs e a forma
como sao actualizados os seus conteudos Os conteudos de um ManagedResourceStore
sao actualizados sempre que a versao contida no ficheiro de manifesto for alterada
enquanto que os conteudos de um ResourceStore nunca sao actualizados automati-
camente mas apenas quando for explicitamente ordenado pela aplicacao
O LocalServer e capaz de interceptar e servir localmente pedidos de HTTP e
HTTPS sempre que se reunam as seguintes condicoes
1 O URL encontra-se armazenado num ResourceStore ou ManagedResourceStore
2 O sistema de armazenamento local encontra-se activo (enabled = true) Se
o sistema de armazenamento local tiver o atributo requiredCookie o pedido
devera conter um cookie que lhe corresponda
O LocalServer nao necessita de monitorizar o estado da ligacao para atender aos
pedidos Na verdade sempre que as condicoes previamente enunciadas se verificarem
o LocalServer interceptara os pedidos e independentemente do estado da ligacao
a Internet servi-los-a a partir do disco rıgido local Cabera a aplicacao definir qual
o modo em que pretende executar um pedido (online ou offline) definindo o valor
de verdade da propriedade enabled
18
Estado da arte
Database
O modulo Database permite guardar dados da web application assegurando a
sua persistencia Os dados sao guardados de forma relacional no disco rıgido do uti-
lizador2 de acordo com o modelo de seguranca estabelecido pelo Gears3 significando
que uma aplicacao nao pode aceder a conteudos fora do seu domınio
WorkerPool
Nos web browsers uma operacao pesada de computacao pode tornar a interface
lenta e tornar menos agradavel a experiencia do utilizador O modulo WorkerPool
permite correr operacoes em background sem bloquear a interface com o utilizador
Os scripts executados numa WorkerPool nao activam os mecanismos de seguranca
do browser que mostram a mensagem ldquoA script on this page may be busy or may
have stopped respondingrdquo
O WorkerPool comporta-se como um conjunto de processos em vez de threads
Os Workers nao partilham qualquer estado de execucao o que significa que uma
alteracao a uma variavel num Worker nao afecta em nada a execucao de outro
Worker Alem disso os Workers nao herdam automaticamente nenhum codigo dos
seus pais Cada Worker e membro de um WorkerPool e os Workers podem in-
teragir entre si enviando mensagens em formato de texto ou JSON No entanto ha
tambem algumas limitacoes os Workers nao tem acesso ao DOM e objectos como
window ou document nao se encontram acessıveis Isto e consequencia de os Workers
nao partilharem o estado de execucao Mas tem acesso a todas as funcoes built-in
do Javascript A maioria das funcionalidades do Gears pode tambem ser acedida
atraves de uma variavel global especial definida como googlegearsfactory Para
outras funcionalidades especıficas os Workers podem ldquopedirrdquo a pagina principal para
continuar a execucao atraves do envio de mensagens
Outras funcionalidades
bull HttpRequest ndash Este modulo implementa a especificacao W3C XmlHttpRe-
quest definida em [vK08] tornando-a disponıvel para os workers e para a
pagina principal
bull Timer ndash Este modulo implementa a especificacao de timers tal como descrito
por [Hic08] e torna-os disponıveis para os workers e para a pagina principal
2Consultar httpcodegooglecomapisgearsapi_databasehtmldirectories3Consultar httpcodegooglecomapisgearssecurityhtml
19
Estado da arte
bull Factory ndash Esta classe e utilizada para instanciar todos os outros objectos da
API do Gears atraves do seu metodo create Este metodo pode ser utilizado
com os seguintes parametros
ndash betadatabase
ndash betahttprequest
ndash betalocalserver
ndash betatimer
ndash betaworkerpool
312 Goggle Gears em dispositivos moveis
O Gears esta tambem disponıvel em dispositivos Windows Mobile 5 e 6
Os dispositivos moveis estao pela sua natureza frequentemente desconectados
da Internet Mesmo quando possuem uma ligacao as latencias na transferencia de
dados em redes moveis tornam as aplicacoes pouco fluıdas mas o Gears permite
ultrapassar este obstaculo
O Gears funciona exactamente da mesma forma em dispositivos moveis equipados
com o Windows Mobile 5 e 6 como num computador comum Se uma aplicacao tiver
sido implementado com suporte para o Gears entao tambem estara preparada para
ser executada num dispositivo movel mas as limitacoes dos browsers disponıveis
para dispositivos moveis tem que ser consideradas Isto significa prever as condicoes
que permitam uma boa usabilidade devido aos pequenos ecras destes dispositivos
bem como o seu suporte limitado dos padroes do DOM CSS e JavaScript
32 Adobe AIR
O Adobe AIR4 e um runtime compatıvel com diversos browsers e sistemas opera-
tivos que pretende dar aos programadores a possibilidade de combinar diversas tec-
nologias de producao de conteudos para a Internet no desenvolvimento de Rich Inter-
net Application (RIA)s O Adobe AIR mantem uma relacao com o browser mas es-
tende as suas capacidades e tecnologias permitindo o desenvolvimento de aplicacoes
tambem para o ambiente de trabalho com janelas em tudo semelhantes as do sis-
tema operativo Segundo a Adobe o objectivo e complementar o browser dando
aos utilizadores (mas essencialmente aos programadores e equipas de desenvolvi-
mento) a escolha sobre como distribuir as suas aplicacoes Para este efeito o Adobe
AIR tem uma aproximacao diferente do Gears Em vez de ldquoestenderrdquo o browser
acrescentando-lhe funcionalidades o AIR permite tambem o desenvolvimento de
4Adobe - httpwwwadobecomproductsair
20
Estado da arte
aplicacoes que se destinam a ser executadas fora do ambiente do browser mas uti-
lizando as tecnologias comuns da Internet (por exemplo HTML CSS JavaScript
Flash Flex)[CDGH08]
A utilizacao desta tecnologia permite utilizar o browser ou o proprio runtime
Adobe AIR como plataforma de execucao da aplicacao
Na Tabela 31 faz-se uma comparacao das funcionalidades disponıveis de acordo
consoante se escolha o browser ou o desktop como plataforma base para a aplicacao
Uma vez que as aplicacoes Adobe AIR na plataforma desktop tem um caracter
persistente (sao instaladas no computador do utilizador) o Adobe AIR tem um
modelo de seguranca que se assemelha com o das tradicionais aplicacoes desktop
[Ada08] Este modelo e analisado nas seccoes 321 e 322 O ambiente em que
e executado o browser e restringido a execucao de web applications que podem
ser de varias origens (incluindo de origens anonimas ou sem confianca) O Adobe
AIR proporciona acesso a capacidades como acesso a ficheiros que necessitam da
confianca do utilizador
bull HTML ndash O desenvolvimento de aplicacoes para o Adobe AIR pode ser feito
com recurso a tecnologias de HTML e Ajax comuns utilizando as linguagens
de markup existentes distribuıdas como texto e interpretadas em execucao
(runtime)
bull Flash ndash Outra alternativa sera a utilizacao da linguagem Flash Permite a
renderizacao de graficos vectoriais e audiovıdeo com suporte nativo Utiliza
ActionScript para adicionar maior interactividade com o utilizador
bull Flex ndash O Flex e uma framework open source para o desenvolvimento de RIAs
usando Flash As aplicacoes Flex sao na realidade Flash sendo a principal
diferenca o ambiente de desenvolvimento
Como resultado uma aplicacao AIR podera ser implementada
bull Baseada em Flash ou Flex (aplicacoes cujo conteudo base e em ShockWave
Flash (SWF))
bull Baseada em Flash ou Flex tambem com HTML ou Portable Document Format
(PDF) Aplicacoes cujo conteudo de base e em FlashFlex (SWF) com HTML
(HTML JavaScript CSS) ou conteudo PDF incluıdo
bull Baseada em HTML Aplicacoes cujo conteudo base e em HTML Javascript
CSS
bull Baseada em HTML utilizando tambem FlashFlex ou PDF
21
Estado da arte
Os utilizadores interagem com uma aplicacao AIR da mesma forma que interagem
com outras aplicacoes com janelas nativas do seu sistema operativo O runtime e
instalado uma vez no computador do utilizador e a partir desse momento todas as
aplicacoes AIR terao o mesmo aspecto que qualquer outra aplicacao para o desktop
321 Seguranca
Permitir que uma web application aceda ao disco de armazenamento do utilizador
pode comprometer seriamente a sua seguranca Neste sentido o Adobe AIR tem
suporte para assinaturas digitais (Secure Sockets Layer (SSL)) que podem ser com-
pradas pelas equipas de desenvolvimento que o desejem e cujos certificados serao
apresentados ao utilizador no momento da instalacao Um outro aspecto ainda
relativo a seguranca e o mecanismo de isolamento de cada ambiente (sandbox )
322 Assinatura do codigo
O runtime AIR exige que todas as aplicacoes estejam digitalmente assinadas As
assinaturas digitais de codigo sao um processo que visa garantir a integridade da
aplicacao e a identidade do seu autor no momento da instalacao As equipas de
desenvolvimento podem ldquoassinarrdquo uma aplicacao utilizando um certificado atribuıdo
por uma Entidade Certificadora (Certification Authority) ou atraves de um certifi-
cado individual (self signed certificate) Neste momento o Adobe AIR suporta como
entidades certificadoras a Verisign e a Thawte [Ado08]
O instalador apresenta o nome de quem publica a aplicacao quando o codigo tiver
sido assinado com um certificado que apresente confianca ou que esteja encadeado
com um certificado que tenha ja sido aceite no computador em que se esta a instalar
a aplicacao
As equipas de desenvolvimento podem tambem assinar as aplicacoes com um
certificado auto-atribuıdo (um certificado criado por elas proprias) mas neste caso
o instalador apresentara estas aplicacoes como sendo de uma origem nao verificada
O AIR utiliza a infraestrutura publica de chaves [Ent07] suportada pelo arquivo
local do sistema operativo Para que a origem da aplicacao seja reconhecida o
computador onde a aplicacao AIR esta a ser instalada tem que confiar directamente
no certificado que foi utilizado para assinar a aplicacao ou confiar num certificado
que esteja num encadeamento logico de certificados confiados e que se ligue desta
forma ao certificado utilizado para assinar a aplicacao
Todas as aplicacoes AIR tem caracterısticas em comum independentemente da
tecnologia utilizada para o seu desenvolvimento (HTMLFlexFlash) No ambito
de uma aplicacao AIR existem um conjunto de APIs que estao disponıveis e que
tornam possıvel o acesso ao sistema local (leitura e escrita) e a recursos de rede que
22
Estado da arte
de outra forma nunca estariam acessıveis a partir de uma web application comum
Cada aplicacao AIR possui tambem diferentes nıveis de isolamento chamados secu-
rity sandboxes dependendo do tipo de conteudo que esta a ser carregado e do seu
objectivo
bull Isolamento ao nıvel da aplicacao5 ndash E a raiz de cada aplicacao AIR Este
nıvel de isolamento permite o acesso a APIs privilegiadas e especıficas do
AIR Em contrapartida e negado o acesso a algumas APIs que poderiam ser
facilmente utilizadas de forma maliciosa contra o utilizador final Importacao
dinamica de conteudos remotos e geralmente proibido e as tecnicas e mecan-
ismos de geracao dinamica de codigo sao fortemente restringidas Apenas
conteudo carregado directamente da directoria base da aplicacao podera ser
colocado neste nıvel de isolamento
bull Isolamento nao especıfico da aplicacao6 ndash contem todo o outro conteudo
que nao tenha sido carregado directamente para o isolamento da aplicacao
Isto inclui conteudo local e remoto Este tipo de conteudo nao tem acesso
directo as APIs do AIR e rege-se pelas mesmas regras tal como se tivesse sido
carregado por um browser a partir da mesma localizacao (por exemplo HTML
carregado a partir de um domınio remoto comporta-se da mesma forma que se
fosse acedido a partir do browser)
33 Mozilla Prism
331 XML User Interface Language
O eXtensible User Interface Language (XUL) e uma linguagem de anotacao
baseada em XML desenvolvida pela Mozilla Foundation que opera em aplicacoes
Mozilla multi plataforma tal como o Firefox O motor Gecko e a unica imple-
mentacao completa desta linguagem que foi desenhada sobre padroes web comuns
como CSS JavaScript e o DOM e permite o desenvolvimento de interfaces graficas
utilizando elementos pre-definidos tais como window box page textbox radio
button entre outros Infelizmente o XUL nao possui qualquer especificacao formal
ou implementacoes de inter-operabilidade para outros motores que nao o Gecko No
entanto a sua implementacao e licenciada em codigo aberto pelas licencas GNU Gen-
eral Public License (GPL) GNU Lesser General Public License (LGPL) e Mozilla
Public License (MPL)
Enunciam-se algumas caracterısticas desta linguagem
5NT application sandbox6NT non-application sandbox
23
Estado da arte
Liguagem de anotacao poderosa baseada em componentes (widgets) O ob-
jectivo do XUL e permitir a construcao de aplicacoes multi-plataforma em
claro contraste com o Dynamic HyperText Transfer Protocol (DHTML) que se
destina ao desenvolvimento de paginas web Por esta razao o XUL esta orien-
tado a componentes tais como janelas botoes e etiquetas em vez de paginas
cabecalhos de texto e ligacoes de hipertexto Investir tempo e esforco para
atingir este mesmo resultado em aplicacoes baseadas em DHTML compromete
frequentemente a complexidade e desempenho da aplicacao
Baseado em padroes O XUL e um dialecto XML baseado no padrao W3C XML
10 As aplicacoes escritas em XUL sao tambem baseadas em especificacoes
W3C adicionais como HTML 40 CSS DOM nıvel 1 e 2 JavaScript 15
incluindo ECMA-262 Edition 3 (ECMAscript)
Portabilidade entre plataformas Tal como HTML o XUL foi desenhado para
ser independente da plataforma em que e utilizado tornando as aplicacoes
facilmente portaveis entre sistemas operativos nos quais o Mozilla e suportado
Uma vez que o XUL oferece um nıvel de abstraccao dos componentes graficos
de interface que disponibiliza implementa a premissa ldquoum codigo para todas
as plataformasrdquo A interface grafica de todos os produtos centrais Mozilla
(browser instant messenger livro de enderecos) e escrita em XUL com um
unico codigo base que suporta todas as plataformas Mozilla
Separacao entre o nıvel de apresentacao e a logica de negocio Uma das
maiores preocupacoes no desenvolvimento para a Internet e a forte ligacao
entre estas duas camadas (interface e logica) Isto constitui um problema sig-
nificativo no desenvolvimento de grandes aplicacoes especialmente quando o
desenvolvimento e feito em ambientes de equipa porque as capacidades de de-
senvolvimento destas duas partes da aplicacao estao muitas vezes espalhadas
por diferentes elementos O XUL permite uma clara distincao entre a definicao
da aplicacao cliente e da logica de implementacao (XUL eXtensible Binding
Language (XBL) e JavaScript) apresentacao (CSS e imagens) internacional-
izacao (Document Type Definitions (DTDs) e etiquetas de texto em lınguas
especıficas guardados em ficheiros properties) O esquema grafico e apre-
sentacao de uma aplicacao XUL pode ser alterado de forma independente da
sua logica ou implementacao e a aplicacao pode ainda ser traduzida (interna-
tionalization) de forma independente da sua logica implementacao ou apre-
sentacao Este grau de separacao resulta em aplicacoes que sao mais faceis de
manter pelos programadores e facilmente adaptadas por designers e tradutores
24
Estado da arte
Facil adaptacao Outro benefıcio que advem do nıvel de separacao entre logica
de negocio e apresentacao oferecido pelo XUL e a facilidade com que se pode
adaptar uma aplicacao para diferentes clientes ou grupos de utilizadores Um
programador pode utilizar a mesma aplicacao base e adapta-la consoante as
necessidades atraves de diferentes temas (skins) e ficheiros de lınguas Desta
forma uma aplicacao escrita e desenvolvida em Ingles pode ser rapidamente
traduzida para Portugues e distribuıda com outra aparencia mais apropriada
ao cliente alvo
332 Prism
O Mozilla Prism e um browser simplificado e ldquointerpretadorrdquo de XUL (tambem
designado por XULRunner) que acolhe web applications sem a interface grafica ha-
bitual de um browser Baseia-se num conceito designado por Site Specific Browser
(SSB) Um SSB e uma aplicacao com um browser embebido desenhado para exe-
cutar apenas uma web application Nao possui os menus e barras de ferramentas
habituais Um SSB tem uma integracao com o sistema operativo e com o desktop
muito mais estreita do que uma web application acedida atraves de um browser uma
vez que e executado em janela propria
O Prism resulta de uma experiencia da Mozilla e visa reduzir as diferencas entre
as desktop applications tradicionais e as web applications Um dos aspectos focados e
a experiencia do utilizador Numa apresentacao oficial e dito que ldquo[o Prism] pretende
ser uma ponte entre as diferencas que existem entre as aplicacoes tradicionais de
desktop e as web applications explorando novos modelos de usabilidade enquanto
que a linha que as separa se continua a definirrdquo [Lab07]
34 HTML 5
A especificacao HTML 5 [Hic08] que se encontra em fase de desenvolvimento
pelo grupo WHATWG pretende ser uma norma de substituicao dos padroes HTML
4 XHTML 1x e do DOM2 HTML Uma das propriedades que o distingue das tec-
nologias que pretende substituir e precisamente o suporte para OWA e armazena-
mento de dados no cliente de uma forma relacional Nao sendo propriamente uma
tecnologia ndashmas antes uma especificacao ndashe aqui mencionada por ter servido como
referencia a diversas implementacoes de funcionalidades offline e por se considerar
que venha a ter um impacto significativo nas implementacoes de diversos browsers
Dion Almaer defendeu no seu blogue que o Gears era uma implementacao do
HTML 5 No seu artigo ldquoGears as a bleeding-edge HTML 5 implementationrdquo [Alm08]
o autor diz que ambos ndasho Gears e o HTML 5 ndashpretendem dar a web caracterısticas
25
Estado da arte
semelhantes e nao encontrar motivo de ldquocompeticaordquo entre as duas mas que en-
quanto o HTML 5 e uma especificacao o Gears e uma implementacao
No entanto tambem e verdade que o HTML 5 cobre muitos outros pontos para
alem das OWA que saem completamente fora do ambito do Gears Se esta es-
pecificacao atingir um estado de maturidade que possibilite a sua adopcao pelos
principais browsers tornando nativo do browser o suporte OWA entao deixara de
fazer sentido a existencia de uma extensao como o Gears
A especificacao HTML 5 disponibiliza duas APIs relevantes para o tema das
OWA
1 Uma base de dados baseada em SQL que permite o armazenamento de dados
do lado do cliente
2 Uma ldquocacherdquo HTTP que garante a disponibilidade das aplicacoes mesmo quando
o utilizador nao possui uma ligacao a Internet
Estas caracterısticas sao as bases da tecnologia das OWA e tem correspondencia
com os pontos analisados nas seccoes 311 e 311
35 Web applications que usam funcionalidades offline
Nesta seccao apresentam-se algumas web applications que actualmente disponi-
bilizam funcionalidades offline Estas aplicacoes foram escolhidas para uma analise
mais pormenorizada por utilizarem o Gears que tal como descrito na seccao 4 foi
a tecnologia escolhida para o projecto
351 Google Reader e Google Docs
O Google Reader7 e um leitor de feeds RSS Permite gerir a subscricao de varios
sites simultaneamente que disponibilizem conteudos neste formato e foi a primeira
web application da Google com uma versao offline publicamente acessıvel (desde
Junho de 2007)
O Google Reader implementa o modo ldquoutilizador deciderdquo oferecendo na sua
interface um botao que permite alternar entre os modos online e offline
O Google Docs8 e uma web application que permite a criacao e edicao de doc-
umentos de texto folhas de calculo e apresentacoes Era ja publico desde Janeiro
de 2008 que o Google estava a desenvolver uma versao OWA desta aplicacao mas o
acesso a uma versao experimental so foi possıvel a partir de 31 de Maio de 2008
7Google Reader - httpreadergooglecom8Google Docs - httpdocsgooglecom
26
Estado da arte
A implementacao das funcionalidades offline nestas duas aplicacoes seguiu difer-
entes aproximacoes principalmente porque o Google Reader apresenta ao utilizador
informacoes que sao fornecidas por fontes externas enquanto que no Google Docs
a informacao e criada e editada pelo utilizador sobre a forma de documentos
A diferente origem da informacao implica que no Google Reader seja necessario
prever casos de excepcao tal como existirem demasiados itens que necessitam de
ser transferidos para o cliente Nao observar este ponto causa um problema grave
de usabilidade e para evitar tempos de espera demasiado longos e uma interface
com pouca capacidade de resposta as accoes do utilizador o Google Reader apenas
transfere para o cliente os dois mil itens mais recentes na transicao para o modo
offline
352 Remember the Milk
O Remember The Milk9 e uma web application desenvolvida por uma equipa
Australiana que proporciona funcionalidades de agenda gestao de tempo e de tare-
fas e foi uma das primeiras aplicacoes independentes do Google a adoptar o Gears
para acessos em modo offline Permite que os seus utilizadores facam uma gestao
de tarefas agrupando-as em listas adicionando-lhes campos de informacao adicional
ou dando-lhes informacao geografica (recorrendo ao servico Google Maps10) Entre
a sua lista de funcionalidades encontra-se ainda a possibilidade de importar e ex-
portar eventos no formato iCalendar (ics) etiquetas (tags) em tarefas publicacao
Really Simple Syndication (RSS) e partilha de categorias de tarefas de acordo com
diferentes nıveis de permissoes de acesso definidos pelo utilizador
353 MySpace e WordPresscom
O MySpace uma das maiores social networks na Internet anunciou recente-
mente que vai disponibilizar uma versao do seu cliente de e-mail que utiliza o Gears
para acelerar o seu desempenho Numa fase inicial estara disponıvel apenas para
utilizadores que tenham cinco mil ou mais mensagens na sua caixa de correio e
permitira efectuar pesquisas muito mais rapido que a sua versao online
O servico de blogs Wordpresscom anunciou tambem o inıcio da utilizacao desta
tecnologia com o fim de melhorar o desempenho A versao que utiliza esta tecnologia
descarrega e armazena no cliente um conjunto de imagens e scripts que passam a
ter preferencia sobre os seus congeneres online e que permitem acelerar o processo
de carregamento da aplicacao e visualizacao de blogs
9Remember The Milk ndash httpwwwrememberthemilkcom10Google Maps ndash httpmapsgooglecom
27
Estado da arte
O MySpace e o Wordpresscom sao dois exemplos da utilizacao da tecnologia
OWA para optimizacao de web application ja existentes Sem pretenderem disponi-
bilizar uma versao que seja totalmente offline fazem uso do Gears para armazenar no
cliente parte dos recursos frequentemente acedidos na visualizacao das suas paginas
36 Escolha da tecnologia
Apos a analise das tecnologias apresentada nas seccoes 31 a 34 foi necessario es-
tudar a adequacao de cada uma delas ao projecto em questao Desde logo e possıvel
observar que nem todas se dedicam apenas a OWA Por exemplo o Adobe AIR
apesar de ter suporte para OWA apenas disponibiliza algumas das funcionalidades
identificadas como mais indicadas para a execucao do projecto quando utilizado
na sua vertente desktop tal como exposto na Tabela 31 mas a utilizacao desta
vertente implicaria o desenvolvimento de novas interfaces e de novas formas de co-
municacao (troca de mensagens XML ou JSON) A vertente web do Adobe AIR
foca-se mais especificamente nas Rich Internet Applications e permite a reutilizacao
do codigo ja existente (exigindo naturalmente a sua adaptacao e a implementacao
das funcionalidades pretendidas)
A tecnologia escolhida para a realizacao deste trabalho foi o Gears sendo que
um dos principais factores a influenciar esta opcao foi a liberdade introduzida pela
sua licenca Berkeley Software Distribution (BSD)11
Considerou-se o funcionamento desta ferramenta extremamente adequando a
aplicacao no WOW uma vez que o seu principal objectivo e precisamente tornar
possıvel a execucao offline de uma pagina web e por virtude deste facto o Gears tem
uma API concisa e de simples aplicacao pratica uma vez que nao possui quaisquer
outros elementos distractores O funcionamento do seu ManagedResourceStore ex-
emplificado na Figura 31 com a capacidade de actualizacao de recursos definidos
num ficheiro manifesto especificado em JSON pesou tambem nesta decisao
11Sobre a licenca BSD consultar httpwwwopensourceorglicensesbsd-licensephp e http
wwwlinfoorgbsdlicensehtml
28
Estado da arte
Figura 31 Esquema UML do processo efectuado pelos recursos do Gears do tipoManagedResourceStore para a actualizacao dos conteudos definidos no ficheiro manifesto
29
Estado da arte
Funcionalidade RIAs no browser RIAs no desktop
Disponibilidadeda aplicacao
As aplicacoes podem ser facil-mente exploradas e utilizadas
As aplicacoes quando instal-adas tem maior grau de fun-cionalidades e persistencia
Instalacao Nao e necessario qualquer tipode instalacao
As aplicacoes sao instaladasatraves do browser ou descar-regadas e instaladas comouma aplicacao tradicional
Actualizacoes Aplicacoes sao actualizadascarregando conteudos paraum website
O AIR disponibiliza uma APIque permite que as aplicacoessejam actualizadas de umaforma
Sistemas opera-tivos suportados
As aplicacoes podem ser exe-cutadas em diversos sistemasoperativos e browsers
As aplicacoes sao multi-plataforma e podem serinstaladas e executadas emdiversos sistemas operativos ebrowsers
Linguagens deprogramacao
Javascript e disponibilizadopelo browser e ActionScripte disponibilizado pelo AdobeFlash Player
Maquinas virtuais deJavascript e ActionScriptcompatıveis com o browser
Capacidade deexecucao embackground
As RIAs podem ser execu-tadas numa janela do browser
As aplicacoes podem ser ex-ecutadas em background edisponibilizar notificacoes talcomo uma aplicacao tradi-cional
Persistencia A actividade esta limitada asessao do browser Quando obrowser e encerrado toda ainformacao e descartada
As aplicacoes sao instaladas eestao disponıveis no desktopPodem armazenar informacaolocalmente e estao disponıveisoffline
Integracao com odesktop
Integracao com o desktop lim-itada devido a restricoes im-postas pelo browser
As aplicacoes podem acederao sistema de ficheiro ao clip-board eventos notificacoesetc
Controlo da inter-face com o uti-lizador
As aplicacoes sao acedidasatraves de uma janela dobrowser que tem os seusproprios controlos e visualgrafico
As aplicacoes tem um vi-sual grafico proprio em janelapropria
Armazenamentode dados
As aplicacoes tem armazena-mento limitado que pode serreescrito pelo browser
As aplicacoes tem acesso a to-talidade do espaco disponıvellocalmente e a uma base dedados com a possibilidade deencriptacao
Tabela 31 Comparacao das funcionalidades oferecidas pelo Adobe AIR para as platafor-mas web e desktop
30
Estado da arte
Aplicacao Modo de execucao utilizadoGoogle Reader Utiliza o modo ldquoutilizador deciderdquo disponibilizando
ao utilizador um botao para alternar entre os modosonline e offline Como lida com informacao recol-hida de fontes externas de natureza frequentementeefemera o processo de sincronizacao apenas transfereos dois mil itens mais recentes quando passa ao es-tado offline Neste modo sao ainda guardadas in-formacoes de itens lidos e etiquetas atribuıdas quesao sincronizadas com o servidor quando o utilizadorvoltar a activar estado online
Google Docs Utiliza o modo ldquoaplicacao deciderdquo permitindo que outilizador edite os conteudos de documentos de textofolhas de calculo e de apresentacoes independente-mente do estado da ligacao desde o momento em queas funcionalidades offline sao activadas A aplicacaofaz pequenas sincronizacoes com o servidor sempre quenecessario
Remember the Milk Utiliza um modo hıbrido entre ldquoaplicacao deciderdquo eldquoutilizador deciderdquo A aplicacao encarrega-se da sin-cronizacao de dados mas disponibiliza um controlona sua interface que permite despoletar manualmenteeste processo para situacoes em que o utilizador fez al-teracoes recentes e pretende usufruir das capacidadesoffline imediatamente
MySpace O MySpace anunciou a utilizacao de mecanismos dearmazenamento de dados no cliente com recurso atecnologias OWA para melhorar o desempenho doseu cliente web de correio electronico nomeadamenteno que diz respeito a operacoes de pesquisa e or-denacao Inicialmente esta funcionalidade estara ape-nas disponıvel para utilizadores com cinco mil ou maismensagens na sua caixa de correio mas nao e aindaclaro se sera disponibilizada uma versao totalmenteoffline
Tabela 32 Resumo da utilizacao de tecnologias OWA em algumas web applications con-sideradas na analise do estado da arte
31
Estado da arte
32
Capıtulo 4
Desenvolvimento
Neste capıtulo introduz-se a aplicacao WOW e apresenta-se o estudo que foi
feito da adequacao de cada tecnologia para a implementacao da funcionalidade of-
fline nesta plataforma Fazem-se diversas consideracoes sobre opcoes a tomar na
concepcao de OWAs e problemas comuns na sua implementacao bem como sug-
estoes para os resolver O WOW e uma aplicacao ja existente de gestao de ordens
de trabalho e do fluxo de tarefas numa empresa ou organizacao
41 Como ficar offline
Na maior parte das web applications de hoje nao existe uma camada de dados
real A aplicacao exemplificada na Figura 41 ao longo da sua execucao acede
directamente a sua unica fonte de dados (o servidor) atraves de chamadas Ajax sem
que exista uma separacao clara destas duas camadas
Para que uma web application seja capaz de ser executada sem uma ligacao
activa a Internet e mantenha o seu caracter dinamico torna-se necessario incluir
Figura 41 Exemplo de uma arquitectura de uma web application sem uma camada deabstraccao de dados Figura adaptada de http gears google com
33
Desenvolvimento
Figura 42 Exemplo de uma arquitectura de uma web application com uma camada deabstraccao de dados Figura adaptada de http gears google com
um mecanismo de armazenamento de dados local seja uma base de dados ou a
capacidade de acesso ao disco No entanto este mecanismo introduz dois problemas
1 Qual das fontes de dados utilizar quando um utilizador faz um pedido de
informacao
2 A necessidade de implementar uma camada de acesso a dados que seja coerente
quer se use o servidor remoto ou local
Por exemplo em vez de a aplicacao Ajax fazer um pedido relativo as contas de
todos os utilizadores em formato JSON directamente ao servidor remoto podera ao
inves fazer o pedido a um objecto intermedio da camada de dados Este objecto
demonstrado na Figura 42 sera responsavel por implementar uma interface de
acesso a base de dados e retornar um objecto JavaScript com uma representacao da
resposta do servidor
Mas a existencia de uma segunda fonte de dados torna recomendavel tambem
a implementacao de uma camada de data switching que em funcao da existencia
de conexao a Internet e da necessidade de actualizacao dos dados decide se faz o
pedido ao servidor remoto ou se fornece os dados presentes localmente Este objecto
apresentado na Figura 43 decidira de forma transparente para o utilizador se le ou
escreve os dados localmente ou se os enviapede ao servidor remoto e pode tambem
iniciar o processo de convergencia de dados e de resolucao de conflitos
411 Funcionalidades disponıveis em modo offline
Por razoes praticas e provavel que nem todas as funcionalidades da aplicacao
possam ser disponibilizadas em modo offline E necessario escolher quais as fun-
cionalidades a disponibilizar no modo offline da aplicacao e implementar a logica
que decide quando utilizar a base de dados local ou o servidor remoto Apesar do
acesso a base de dados local ser muito mais rapido do que aceder ao servidor o
acesso local nem sempre e preferido Ha varias razoes que podem tornar necessario
escolher o acesso ao servidor em vez do acesso local
34
Desenvolvimento
Figura 43 Exemplo de uma arquitectura de uma web application com uma camada deabstraccao de dados e um data switch Figura adaptada de http gears google com
1 A informacao pode ter uma natureza efemera e nao fazer sentido guarda-la
localmente Exemplo dados em tempo real da bolsa de valores de Lisboa
2 Algumas aplicacoes lidam com informacao que so faz sentido na presenca de
uma ligacao Exemplo Instant Messaging
3 A aplicacao podera escolher apenas guardar a informacao acedida mais fre-
quentemente Exemplo para o utilizador poder alterar a lıngua de apre-
sentacao da aplicacao os conteudos terao que ser guardados em todas as
lınguas disponibilizadas pela aplicacao O custo de implementacao de algu-
mas funcionalidades pode nao compensar o benefıcio
4 A capacidade de processamento ou de armazenamento de dados pode inviabi-
lizar algumas funcionalidades offline Exemplo se uma dada funcionalidade
necessita de uma capacidade de armazenamento de dados para alem do razoavel
de um computador pessoal para ser util (visualizador de mapas)
42 Modos de execucao
Um aspecto que e necessario estudar para qualquer web application que se deseje
disponibilizar offline prende-se com tres modos de execucao que devem ser consid-
erados
1 Utilizador decide o modo de execucao A aplicacao tem modos distintos
de execucao para os estados online e offline geralmente indicados na interface
com o utilizador O utilizador e informado do estado da ligacao e participa na
alteracao de estado de execucao da aplicacao interagindo com a sua interface
2 Aplicacao decide o modo de execucao Pode ser implementado na propria
aplicacao um mecanismo de deteccao do estado da ligacao (por exemplo atraves
35
Desenvolvimento
de chamadas Ajax periodicas) transitando de estado e sincronizando automati-
camente Desta forma o utilizador nao precisa de participar na alteracao de
estado a menos que exista um conflito de dados que requeira a sua atencao
3 Aplicacao assume sempre o estado offline Outra hipotese sera imple-
mentar uma web application que assume sempre estar na ausencia de uma
ligacao ao servidor de dados Esta aplicacao responde aos pedidos do uti-
lizador efectuando pedidos de informacao ao servidor mas nao dependendo
de uma resposta valida para mostrar a informacao que ja tinha disponıvel an-
teriormente A sincronizacao de dados com o servidor e tentada sempre que
existam dados para submeter e uma accao do utilizador
421 Modo ldquoutilizador deciderdquo
Neste modo de execucao quando a aplicacao esta online comunica com o servidor
remoto quando esta offline comunica com a base de dados local A informacao tem
que ser sincronizada sempre que se muda de modo A principal vantagem desta opcao
e que e a mais simples de implementar mesmo para uma aplicacao ja existente e
portanto uma forma expedita de disponibilizar uma OWA No entanto tem tambem
algumas desvantagens que devem ser consideradas
1 O utilizador tem que se lembrar de fazer a alteracao de estado de execucao
Caso contrario podera estar a trabalhar inadvertidamente numa versao offline
com dados antigos ou nao ter a informacao necessaria se perder subitamente
a ligacao
2 Se a ligacao for intermitente o utilizador tera ou que escolher um dos modos
de execucao ou estar constantemente a trocar
3 Uma vez que a base de dados nao esta sempre actualizada nao podera ser
utilizada para melhorar a rapidez de execucao da aplicacao quando em modo
online
422 Modo aplicacao decide
A deteccao do estado da ligacao pode ser implementada atraves de um pedido
assıncrono ao servidor tal como ilustrado na Figura 44 O resultado deste pedido
definira o estado online (em caso de sucesso) ou offline (em caso de falha) A
sincronizacao de dados podera ser feita sempre que ocorra uma transicao do es-
tado offline para o estado online No entanto este metodo nao se revela eficiente
36
Desenvolvimento
Figura 44 Esquema grafico ilustrando uma OWA executando no browser utilizando ummodo de execucao do tipo ldquoaplicacao deciderdquo com deteccao automatica do estado daligacao via pedidos Ajax assıncronos a cada cinco segundos
para grandes aplicacoes uma vez que requer a troca de mensagens demasiado fre-
quentes com o servidor que se destinam exclusivamente a monitorizacao do estado
da ligacao
423 Modo ldquoaplicacao assume o estado offlinerdquo
Uma aplicacao transparente funciona assumindo sempre que esta em modo of-
fline ou pelo menos que pode perder a ligacao a qualquer momento Neste modo
tira-se o maximo partido do armazenamento local e fazem-se pequenas mas contınuas
sincronizacoes com o servidor sempre que este esteja disponıvel A sincronizacao de
dados tambem e feita sempre que se volta ao estado online
As vantagens de uma web application transparente sao as seguintes
bull Uma melhor experiencia para o utilizador uma vez que este nao tem que se
preocupar com o estado da ligacao ou com a transicao de estados
bull A aplicacao funciona de forma coerente mesmo que a ligacao seja intermitente
bull Uma vez que o armazenamento local e mantido actualizado pode ser utilizado
para melhorar o desempenho da aplicacao
Foram identificadas as seguintes desvantagens
bull E mais difıcil de implementar e a sincronizacao acarreta cuidados especiais
bull E necessario um cuidado adicional para evitar que as operacoes de sincronizacao
frequentes que ocorrem automaticamente nao afectem os tempos de resposta
da aplicacao
bull Os testes a aplicacao sao mais complexos uma vez que a sincronizacao de dados
nao ocorre em resposta a uma accao do utilizador
37
Desenvolvimento
43 Sincronizacao de dados
A sincronizacao de dados consiste na capacidade de identificar e transferir pe-
riodicamente a versao mais actual dos dados entre o cliente e o(s) servidor(es)
Independentemente do modo de execucao escolhido e mesmo do estado da ligacao
do utilizador a informacao armazenada localmente e a informacao armazenada no
servidor estarao por vezes dessincronizadas Isto podera acontecer sempre que por
exemplo
bull O utilizador faz alteracoes em modo offline
bull A informacao e partilhada e pode ser alterada por uma entidade externa
bull A informacao e fornecida por uma entidade externa
Resolver estas diferencas de forma a que a informacao local e remota encontrem
a igualdade chama-se sincronizacao de dados Ha varias aproximacoes possıveis
para este efeito que dependem da natureza da aplicacao cada uma com vantagens
e desvantagens
A capacidade de suportar a mobilidade dos utilizadores torna-se cada vez um
ponto mais importante de uma web application Para uma organizacao de dimensao
global e vital garantir que os seus colaboradores tem acesso a mesma informacao
que tem disponıvel nos seus postos de trabalho mesmo quando estao fora Na maior
parte dos casos estes colaboradores terao acesso a um computador portatil um
desktop Smartphone ou PDA e atraves destes poderao ter acesso a sua informacao
directamente atraves de ligacoes encriptadas Virtual Private Network (VPN) de um
servidor web ou de outro mecanismo de rede
Esta solucao e simples de implementar mas infelizmente para a maioria dos
colaboradores com grande factor de mobilidade nao e satisfatoria As principais
desvantagens sao as seguintes
bull Requisitos de ligacao Para permitir que os utilizadores acedam a sua in-
formacao e necessario garantir a capacidade constante de comunicacao pelo
menos durante o tempo necessario que assegure a sua transferencia
bull Velocidade de ligacao sem persistencia de dados e em ligacoes de fraca
qualidade a usabilidade por vezes torna-se inaceitavel
bull Ponto crıtico de falha Com este tipo de solucao todos os utilizadores de-
pendem da base de dados que armazena informacao vital para o funcionamento
do cliente
38
Desenvolvimento
bull Scalability do servidor A medida que novos utilizadores sao adicionados ao
sistema o desempenho do servidor e afectado levando a necessidade de maior
capacidade de armazenamento eou processamento
De acordo com a documentacao da Microsoft Sync Framework [Mic08] uma
solucao alternativa consiste em implementar uma Occasionally Connected Appli-
cation (OCA) Uma OCA permite a um utilizador remoto continuar a aceder a
sua informacao mesmo depois de perder a ligacao mas em vez de recorrer a um
servidor recorre a informacao armazenada no seu dispositivo local Para preencher
localmente a informacao que o utilizador necessita uma OCA possui mecanismos
de sincronizacao de dados que sao oferecidos por esta framework
431 Quando sincronizar
Uma das solucoes mais simples de implementar passa por disponibilizar um
mecanismo manual que despoleta a sincronizacao Diz-se manual porque e o uti-
lizador que escolhe quando sincronizar e pode ser implementada simplesmente
fazendo o upload de toda a informacao para o servidor e depois fazendo o download
da copia mais recente da informacao antes de voltar a ficar offline Para que esta
seja uma opcao viavel e necessario que
bull O volume de dados seja suficientemente pequeno para que possa ser transferido
do servidor para o cliente num espaco de tempo aceitavel
bull Que o utilizador indique explicitamente que quer mudar para o estado offline
ou online pressionando um botao da interface
Contudo podem ser identificados alguns problemas relacionados com esta abor-
dagem
bull Os utilizadores nem sempre podem prever o estado das suas ligacoes A ligacao
pode-se perder subitamente ou ter um caracter intermitente
bull O utilizador pode esquecer-se de efectuar a sincronizacao
Outra opcao sera conjugar a sincronizacao de dados com o modo de execucao
transparente A sincronizacao ocorre automaticamente em background de forma
nao intrusiva para o utilizador A aplicacao comunica com o servidor regularmente
efectuando pequenas trocas de dados com o objectivo de manter o sincronismo da
informacao local e remota Esta abordagem pode ser implementada com pedidos
Ajax assıncronos e regulares ao servidor o que permite manter a interaccao com a
interface fluıda evitando bloqueios Estes pedidos sao feitos prevendo as situacoes
39
Desenvolvimento
de disponibilidade ou indisponibilidade (timeout) do servidor Uma outra opcao
sera permitir que o servidor comunique essas alteracoes utilizando Comet1 tal como
descrito em [Wil06] e [Rus06] As vantagens destas aproximacoes sao
bull A informacao esta disponıvel a qualquer altura que o utilizador decida ficar
offline ou que a ligacao seja acidentalmente perdida
bull O desempenho da aplicacao pode ser melhorado quando se estiver a utilizar
uma ligacao a Internet lenta uma vez que o acesso a dados locais e mais
eficiente do que a consulta de dados ao servidor
44 WOW
O WOW e uma plataforma integrada de gestao de ordens de trabalho ja ex-
istente e desenvolvida pela Critical Software SA a qual se pretende adicionar a
capacidade de execucao offline Esta aplicacao e extremamente dinamica e con-
figuravel com um conjunto extremamente rico de funcionalidades das quais se
destacam
bull Gestao de Ordens de Trabalho ndash suportando a gestao dos pedidos desde a
sua criacao ate ao seu fecho tomando em conta os diferentes tipos de pedidos
(ordens de trabalho pedidos de informacao melhorias resolucao de problemas
etc) e diferentes tipos de accoes possıveis para cada um (Figura 45)
bull Monitorizacao de alteracoes ndash Historico de mudancas anexos e estados criando
relatorios de alteracao automaticamente (o que por quem e quando)
bull Uso de Service Level Agreements (SLAs) ndash E possıvel associar a um pedido um
SLA que define qual o perıodo de tempo atribuıdo a resolucao de um pedido
controlando e agilizando a resolucao do mesmo
bull Utilizacao de queries de utilizador configuraveis que permitem acesso rapido
a determinadas ordens de trabalho de acordo com o filtro configurado (por
exemplo ldquoPara mimrdquo ldquoPara o Grupordquo ldquoPelo Grupordquo)
bull Gestao do relacionamento entre pedidos
bull Pesquisa e filtragem de ordens de trabalho
bull Exportacao de dados em formatos padrao (PDF DOC ou XLS)
bull Integravel com solucoes externas
40
Desenvolvimento
Figura 45 Detalhe de um conjunto possıvel de estados e respectivas transicoes para umadada ordem de trabalho no WOW desde a sua submissao no sistema ate a sua conclusaoem fecho ou cancelamento Esta figura representa apenas um exemplo ja que o mapa deestados para uma ordem de trabalho e dinamico e pode ser alterado por um administradorFigura retirada de uma brochura promocional do WOW Critical Software SA
A utilizacao de uma ferramenta deste tipo por parte de uma empresa ou orga-
nizacao oferece vantagens quer a gestao de topo quer aos colaboradores individuais
para os colaboradores individuais o WOW e uma aplicacao onde estao registadas
todas as tarefas contribuindo activamente para o desenvolvimento em ambientes
multi-tarefa e para a organizacao pessoal das tarefas de acordo com prioridades
Para a gestao de topo esta ferramenta permite obter uma visao global do estado da
organizacao em termos de tempo gasto por tarefa executada sendo uma mais valia
para a previsao e gestaoalocacao de recursos
45 Visao geral sobre a arquitectura do WOW
O WOW e interessante nao so do ponto de vista de produto como tambem do
ponto de vista de plataforma Existem diversos plug-ins que estendem as funcional-
idades do WOW e existem ate projectos que pretendem usar a arquitectura do
WOW para criar produtos com fins diferentes do inicial (por exemplo o WOW-
Storm ndash um sistema de registo e classificacao social de ideias)
De modo a conseguir ter essa expansibilidade a plataforma WOW assenta sob
uma arquitectura distribuıda modular e expansıvel com uma componente central
ndash o core ndash estruturado em camadas logicas E no core que se situam todas as
1O Comet e um conceito semelhante ao Ajax introduzido por Alex Russel mas no qual e o servidor quetoma a iniciativa de ldquoenviarrdquo os dados ao browser sem que este tenha que efectuar um pedido Tambem econhecido por Ajax Push Reverse Ajax ou HTTP Streaming
41
Desenvolvimento
funcionalidades base da aplicacao quer a nıvel logico funcional e de apresentacao
quer a nıvel de gestao e configuracao
E possıvel a execucao de varias instancias do core simultaneamente em servidores
distintos o que permite a alta escalabilidade e disponibilidade desta aplicacao A
consistencia dos dados fica sempre garantida atraves da partilha da base de dados
e pelo balanceamento dos pedidos uma vez que cada um e encaminhado para uma
unica instancia
O WOW apresenta tambem a vantagem de ser uma plataforma extensıvel E
possıvel adicionar novas caracterısticas a plataforma atraves de componentes que se
podem ser divididos em duas categorias plugins e connectors
Os plugins sao componentes que se encontram no mesmo no fısico que a aplicacao
partilhando do mesmo contexto de execucao do core Sao assim uma forma mais
directa de obter informacao da plataforma visto que nao possuem restricoes de
acesso aos dados nem dependencias externas A arquitectura deste componente tera
assim que permitir varias execucoes instanciadas cada uma associada a um core
Por outro lado os connectors sao componentes que se encontram distribuıdos
comunicando externamente com o core Quer a sua execucao quer a obtencao
dos dados estao assim dependentes de interfaces de comunicacao externas que a
plataforma disponibiliza Estes componentes ao contrario dos plugins sao instan-
ciados unicamente e recorrem ao protocolo de comunicacao Java Messaging Service
(JMS) para comunicar com o core
46 WOW Offline
Para alem das opcoes tomadas relativamente a tecnologia a utilizar surgiu
tambem a necessidade de optar por um dos modos de execucao apresentados na
seccao 42
Das tres opcoes possıveis foi o modo ldquoaplicacao assume o estado offlinerdquo descrito
na seccao 423 que mereceu a maior atencao uma vez que reune as vantagens de
uma experiencia mais positiva para o utilizador (uma vez que este nao tem que
participar activamente na alteracao do modo execucao como descrito na seccao 421)
e nao constitui uma sobrecarga excessiva para servidor (como o modo abordado na
seccao 422)
No entanto esta opcao comprometia a complexidade da implementacao para alem
dos objectivos propostos para este projecto e para cumprir o prazo dado foi tomada
a decisao de implementar o modo ldquoutilizador deciderdquo especificando apenas de forma
teorica o modo ldquoaplicacao assume o estado offlinerdquo
As caracterısticas do Gears foram ja descritas na seccao 31 Na Figura 47
mostra-se a sua forma de funcionamento quando integrado numa web application
42
Desenvolvimento
Nesta figura representa-se o modulo LocalServer do Gears como um ponto de de-
cisao Aqui sao testadas as condicoes que determinam se o pedido sera interceptado e
servido localmente ou se prossegue para uma maquina remota E tambem represen-
tada uma base de dados que corresponde ao modulo Database mas que podera nao
ser utilizada Este modulo tal como o modulo Workerpool tem caracter opcional
e sao utilizados consoante os requisitos da aplicacao
A plataforma WOW lida com mais dados do que e necessario passar para o
lado do cliente Em conformidade com o ja exposto na seccao 411 volta-se a
frisar que nao se pretende recriar toda a logica de negocio nem os conteudos da
base de dados no cliente pela sua complexidade e volume de dados Pretende-se
pelo contrario permitir que os utilizadores tirem partido da capacidade de poder
consultar as suas ordens de trabalho quando nao dispoe de uma ligacao transferindo
apenas o essencial para isto seja possıvel
A pagina inicial do WOW apresenta um resumo das ordens de trabalho abertas
ndash enviadas e recebidas ndash que se pretende permitir visualizar offline (ver Figura 46)
Como prova de conceito foi efectuada uma abordagem pragmatica das varias possi-
bilidades descritas na seccao 42
461 Modo ldquoaplicacao deciderdquo com deteccao automatica da ligacao
A primeira abordagem estudada para a disponibilizacao das funcionalidades of-
fline foi o modo ldquoaplicacao deciderdquo com deteccao automatica de ligacao apresentado
na seccao 422 Para que isto seja possıvel foi implementado um mecanismo de ver-
ificacao periodica do estado da ligacao atraves de chamadas Ajax assıncronas O
resultado destes pedidos determina o estado da aplicacao executando as tarefas de
sincronizacao de dados sempre que pertinente Este metodo embora imediato e
simples de implementar depressa se revelou inadequado para o projecto devido ao
elevado consumo de recursos do servidor que a utilizacao intensiva faz esperar a
comunidade da plataforma WOW no principal cliente excede os 7000 utilizadores
Foi estimado que para uma utilizacao de fluidez aceitavel o estado da ligacao deveria
ser testado a cada cinco segundos Assumindo uma adesao (previsao pessimista) de
1 aos servicos offline assistir-se-ia a cerca de 840 pedidos adicionais por minuto
Mas o principal problema desta aproximacao prende-se com o facto de a ver-
ificacao ser feita em intervalos de tempo discretos levando a possibilidade de a
aplicacao poder ter em dado momento uma representacao errada do seu estado
real da ligacao Este problema e ilustrado na Figura 48 onde se ve claramente a
discrepancia entre o estado real da ligacao e a representacao interna que esta tem
Note-se que nesta janela de tempo qualquer accao do utilizador que exija uma
resposta sıncrona do utilizador leva-lo-a para um ldquobeco sem saıdardquo onde nao tera
43
Desenvolvimento
Figura 46 A pagina inicial do WOW apresenta um resumo das ultimas ordens de trabalhoenviadas e recebidas Na imagem pode-se observar a transicao do estado online para offline
acesso a versao offline porque a aplicacao nao fez a transicao automatica nem acesso
a versao online porque na verdade nao possui uma ligacao O que acontecera nesta
situacao sera uma tentativa de acesso ao servidor por parte da aplicacao numa
altura em que este se encontra indisponıvel e o resultado sera uma mensagem de
ldquopedido excedeu o tempordquo apresentado pelo browser Este e um estado sem retorno
porque apos o browser apresentar esta mensagem todos os recursos JavaScript ficam
indisponıveis tornando impossıvel o regresso ao estado anterior ou o tratamento do
erro de qualquer outra forma No entanto as chamadas Ajax podem ser tratadas de
forma especial para a eventualidade de falha e portanto nao constituem problema
44
Desenvolvimento
Figura 47 Ilustracao do funcionamento do Gears numa web application que utiliza ummotor Ajax Os pedidos HTTP ou HTTPS podem ser interceptados e tratados localmenteou podem ser feitos a uma maquina remota consoante se verificarem ou nao as condicoesexpressas no ponto 311 E representado um acesso a uma base de dados local (fornecidapelo Gears) mas a sua utilizacao e opcional
462 Implementacao do modo ldquoutilizador deciderdquo
Este modo de execucao foi ja descrito na seccao 421 e a sua principal carac-
terıstica e ser o utilizador a decidir se a aplicacao deve utilizar um servidor remoto
ou a maquina local como fornecedor de dados
Relativamente ao WOW o WOW Offline na vertente ldquoutilizador deciderdquo vem
alterar os seus casos de uso dando ao utilizador a possibilidade de alterar o estado
de execucao da aplicacao (entre online e offline) Resta dizer que no modo online se
mantem todas as funcionalidades anteriores e que no modo offline torna-se possıvel
visualizar os conteudos da pagina principal do WOW (Figura 46) e os detalhes das
ordens de trabalho (Figura 49) tal como expressa a Figura 410
Esta aproximacao foi utilizada na prova de conceito do WOW adicionando um
controlo a interface desta aplicacao que permite ao utilizador alternar entre os esta-
dos online e offline Na transicao de online para offline sao descarregados os recursos
necessarios para a execucao desta aplicacao sem recorrer a Internet Para o fazer
45
Desenvolvimento
Figura 48 Neste exemplo do modo ldquoaplicacao deciderdquo o teste da ligacao e feito e feito acada cinco segundos O resultado deste teste nao reflecte sempre o estado real da aplicacaopodendo levar a aplicacao a ter comportamentos indesejaveis Na figura assinala-se umperıodo de tempo no qual a representacao interna do estado da ligacao nao corresponde arealidade
e utilizado um recurso ResourceStore e um ManagedResourceStore (introduzidos
em 311) O primeiro e utilizado para armazenar a pagina principal do WOW ndash do-
ravante designada por homejsp ndash e o segundo e utilizado para armazenar imagens
folhas de estilo CSS e scripts JavaScript
Para a implementacao deste modo de execucao foram identificadas as seguintes
tarefas
1 Guardar informacao que permita a recriacao das paginas que se pretende
disponibilizar offline (utilizando o Gears)
2 Disponibilizar um controlo que permita alterar o estado de execucao atraves
da interaccao com a pagina principal
3 Durante a sincronizacao de dados apresentar o progresso da transferencia de
dados
O primeiro passo consistiu na identificacao de todos os conteudos que sao necessarios
transferir para a execucao offline Foi utilizado um recurso do Gears do tipo
ManagedResourceStore que recorre a um ficheiro manifesto para identificar to-
dos os ficheiros que deve transferir Este recurso e gerido automaticamente pelo
Gears transferindo para o cliente a versao mais recente sempre que e necessario
isto e sempre que exista um ficheiro manifesto com uma identificacao de versao que
seja diferente da actualmente disponıvel no cliente Uma vez identificados todos
ficheiros necessarios para a execucao offline num (ou mais) ficheiros manifesto o
Gears encarrega-se da sua actualizacao mas o preenchimento destes ficheiros man-
ifesto e manual o que se traduz num cuidado extra na manutencao da aplicacao
A forma como esta informacao e guardada deve tambem ser cuidadosamente
estudada A opcao mais flexıvel passa por utilizar o modulo Database apresentado
na seccao 311 e guardar a informacao de uma forma relacional Para a recriacao
das paginas pode ser disponibilizada uma versao HTML da pagina que funciona
46
Desenvolvimento
Figura 49 Pagina de visualizacao do detalhe de uma ordem de trabalho
como template nao possui quaisquer dados e e utilizada apenas em modo offline E
preenchida para cada pedido retirando os dados relevantes da base de dados
O modelo de dados do WOW torna esta opcao extremamente trabalhosa uma
vez que as entidades envolvidas na geracao de cada pagina de informacao sobre
cada ordem de trabalho tem relacoes de dependencia complexas seguindo padroes
muito variaveis Por exemplo em cada ordem de trabalho existe um formulario que
permite a sua progressao de estado com diversos campos opcionais e obrigatorios
este formulario e definido pelo administrador e esta relacionado nao apenas com o
tipo de ordem de trabalho mas tambem com o estado actual em que esta se encontra
e a accao que se pretende realizar O elevado numero de combinacoes de tipos de
ordem de trabalho estados e accoes que existem num dado momento juntamente
com a sua possibilidade de alteracao obrigariam a implementacao de uma logica de
negocio complexa o que esta fora do ambito deste projecto
47
Desenvolvimento
Figura 410 Esquema UML que expressa os casos de uso do WOW Offline no modoldquoutilizador deciderdquo
463 Especificacao do modo ldquoaplicacao assume o estado offlinerdquo
A aproximacao para o modo ldquoaplicacao assume o estado offlinerdquo foi tambem
dividida em varias tarefas
1 Guardar informacao que permita a recriacao da pagina principal do lado do
cliente no estado offline (utilizando o Gears)
2 Dotar a aplicacao do cliente de um mecanismo de deteccao da ligacao
3 Identificar os ldquomomentos chaverdquo em que devera ocorrer sincronizacao de dados
4 Implementar a sincronizacao de dados
A sincronizacao de dados deve ser feita em ambas as transicoes online-offline e
offline-online quer para transferir novos dados do servidor (os pedidos podem ser
alterados por outros utilizadores) quando se transita do estado quer para comunicar
eventuais alteracoes feitas em modo offline
Relativamente ao WOW o WOW Offline na vertente ldquoaplicacao assume o es-
tado offlinerdquo vem alterar os seus casos de uso dando ao utilizador a possibilidade
de activar esta funcionalidade A partir do momento que a funcionalidade esta ac-
tivada o utilizador deve tambem ter a possibilidade de gerir algumas preferencias
relacionadas com privacidade de dados Devera ter a hipotese de desactivar o ar-
mazenamento local e de remover todos os dados ja armazenados tal como descrito
na Figura 411
48
Desenvolvimento
Figura 411 Esquema UML que expressa os casos de uso do WOW Offline no modoldquoutilizador deciderdquo
A primeira vez que o WOW Offline e acedido por um cliente e caso seja detec-
tada a presenca do Gears todos os recursos necessarios a sua execucao sao trans-
feridos Todos os acessos posteriores serao feitos a estes recursos locais (recorda-se
que o Gears pode ser utilizado para os manter actualizados recorrendo ao Managed-
ResourceStore 311)
Atraves do JavaScript e possıvel interceptar os eventos de load e unload da
pagina que sao despoletados sempre que ocorre um re-acesso da mesma (incluindo
a accao refresh comum dos browsers) sempre que esta e abandonada ou ainda ou
ainda se a janela for encerrada
Tal como sugerido na seccao 462 a camada de interface desta aplicacao (cada
pagina individual em HTML) devera ser implementada como sendo um template
para apresentacao de dados sendo totalmente preenchida atraves de funcoes em
JavaScript O objectivo deste ponto e criar um padrao de dados que permita ao
JavaScript preencher os dados em cada pagina (template) independentemente de
qual seja a fonte ndash o servidor remoto ou a maquina local tal como exemplificado
no diagrama da Figura 412 Na figura a aplicacao recorre ao servidor remoto para
obter os dados pretendidos quando se encontra na presenca de uma ligacao mas
para dados que exijam uma carga de processamento pelo servidor este acto pode ser
49
Desenvolvimento
Figura 412 Esquema UML que expressa o acto de recolha de dados em modo online eoffline recorrendo ao servidor (modo online) e ao sistema de armazenamento de dadoslocal fornecido pelo Gears (modo offline)
substituıdo pelo envio de um campo de controlo que se destina a aferir se os dados
locais se encontram actualizados No caso de estarem actualizados a comunicacao
com o servidor pode ser substituıda por uma query a base de dados local
50
Capıtulo 5
Resultados e Futuros
Desenvolvimentos
Todo o estudo feito sobre o tema OWA foi ja abordado ao longo do documento
Neste capıtulo apresentam-se os resultados obtidos na implementacao da prova de
conceito que visava compreender a melhor forma de disponibilizar uma versao of-
fline no WOW uma plataforma de gestao de ordens de trabalho ja existente de-
senvolvida pela Critical Software SA
51 Resultados Obtidos
Os resultados obtidos neste projecto sao extremamente satisfatorios uma vez
que o estudo do tema OWA e a implementacao de uma prova de conceito que o
ilustrasse foi conseguido com sucesso
A funcionalidade offline foi adicionada ao produto WOW da Critical Software
SA permitindo a visualizacao de ordens de trabalho e dos seus detalhes mesmo na
ausencia de uma conexao activa a Internet Embora para a solucao implementada
tenha sido utilizada uma abordagem do tipo ldquoutilizador deciderdquo pretende-se que esta
seja convertida para ldquoaplicacao deciderdquo ou mesmo para uma aproximacao hıbrida
semelhante a utilizada pelas aplicacoes estudadas nas seccoes 351 e 352
Para a sua implementacao descrita no capıtulo 4 foram tomadas decisoes de or-
dem pratica que permitissem tornar o trabalho exequıvel nos prazos dados Tentou-
se sempre que estas decisoes afectassem o mınimo em termos de desempenho e de
experiencia para o utilizador Considera-se que a implementacao do modo offline
com uma transicao entre modos do tipo ldquoutilizador deciderdquo (ver seccao 42) reflecte
o compromisso entre o desempenho pretendido e os recursos disponıveis e para alem
51
Resultados e Futuros Desenvolvimentos
de ser um exemplo eficaz das possibilidades que as OWA podem trazer a aplicacao
WOW desenvolvida pela Critical Software e tambem um estudo que pode ser uti-
lizado para analisar a implementacao desta tecnologia noutros produtos da mesma
empresa
Note-se que o principal objectivo do trabalho era ganhar familiaridade com este
tema entender as suas vantagens e desvantagens e compreender as suas limitacoes
Tudo indica que existam varias possibilidades de implementacao deste paradigma
noutros produtos da Critical Software que pela sua natureza podem tambem tirar
partido da execucao offline
52 Trabalho Futuro
O desenvolvimento do conceito e formas de implementacao de OWA continua
em forte desenvolvimento no entanto a sua adopcao ainda nao e generalizada A
dificuldade da sua implementacao em web applications ja existentes e o principal
obstaculo a sua maior divulgacao
Ha tambem um factor que deve ser tido em consideracao a manutencao de
codigo A implementacao de uma versao offline de uma web application requer
a implementacao das mesmas regras de negocio (ou de uma versao simplificada)
utilizadas no servidor Para que isto seja possıvel e necessario ter em conta a
capacidade de processamento do cliente e o factor de duplicacao de codigo que
tornara a aplicacao mais difıcil de manter uma vez que uma alteracao a logica de
negocio do servidor implica tambem uma alteracao a sua versao offline
A prova de conceito implementada permite ja a visualizacao offline dos pedidos
abertos (enviados e recebidos) que constam na pagina principal (este numero e
fixo e pode ser alterado pelo administrador) Uma funcionalidade desejavel seria a
possibilidade de interaccao com a aplicacao em modo offline e sincronizacao com o
servidor quando existisse uma ligacao disponıvel
Foi estudada a utilizacao do modo de execucao ldquoaplicacao assume o estado of-
flinerdquo descrito em 423 e esta seria a forma desejavel para o WOW Offline no
entanto para que esta opcao seja viavel sera necessaria a implementacao de uma
forma eficiente de sincronizacao e armazenamento de dados de uma forma relacional
Para atingir este objectivo podera ser seguida uma polıtica de automacao do pro-
cesso no qual a versao online da aplicacao gera scripts de criacao para as tabelas
necessarias na base de dados da versao offline (nao existe nenhuma ferramenta para
o fazer portanto seria necessaria a sua implementacao) e no qual as paginas HTML
disponibilizadas pelo servidor aos clientes web (browser) servem como templates de
apresentacao de informacao e sao preenchidas de forma semelhante pelo servidor ndash
quando a aplicacao estiver online ndash ou pelo cliente atraves de funcoes em JavaScript
52
Resultados e Futuros Desenvolvimentos
ndash quando a aplicacao estiver offline No entanto no WOW devido a quantidade de
informacao tratada e devido as complexas relacoes entre as diferentes entidades e
de esperar que a complexidade da implementacao de um mecanismo deste tipo torne
esta aproximacao demasiado custosa
O HTML 5 embora um forte candidato ainda nao esta suficientemente desen-
volvido A sua especificacao ainda tem o caracter de Draft (rascunho) e esta sujeita
a modificacoes e a aceitacao e implementacao por parte dos browsers e portanto
de momento foi desconsiderado No entanto no futuro se esta especificacao atingir
um estado de maturidade que permita a sua adopcao devera ser considerada como
um possıvel caminho a seguir
53
Resultados e Futuros Desenvolvimentos
54
Capıtulo 6
Conclusoes
Neste capıtulo sao apresentadas as conclusoes do projecto e consideracoes finais
relativamente a tecnologia estudada
61 Conclusoes
O rapido desenvolvimento tecnologico faz prever que a disponibilidade de ligacao
a Internet seja cada vez mais facil e mais rapido mas vao continuar a existir lugares
onde o acesso e limitado e onde as OWA podem desempenhar um papel de relevo
Por outro lado esta tecnologia pode tambem ser utilizada para melhorar o desem-
penho de paginas web com uma necessidade elevada de imagens ou outros recursos
dispendiosos em termos de espaco e foram ate estudados dois exemplos da utilizacao
desta vertente desta tecnologia em 353
Acredita-se que as OWAs vem responder a uma necessidade real por parte das
web applications actuais e que a evolucao que representam se compara a que se
assistiu dos thin-clients para os fat-clients em termos de autonomia do servidor
A capacidade de oferecer conteudos dinamicos no browser independentemente da
existencia de uma ligacao reune as vantagens tıpicas das web applications como
ausencia de instalacao e actualizacoes instantaneas com as vantagens das aplicacoes
de desktop em capacidade de processamento e armazenamento de dados na maquina
local
As tecnologias disponıveis ate a data estudadas no ambito deste projecto que
permitem o desenvolvimento de OWAs e que apresentam maior maturidade sao o
Gears e o Adobe AIR Ambas se apresentam sobre a forma de plugins que necessitam
de uma instalacao extra para poderem ser utilizadas Apesar de esta instalacao ser
55
Conclusoes
apenas necessaria uma vez podera constituir um factor de desencorajamento a sua
adopcao
O HTML 5 uma especificacao abordada neste documento na seccao 34 podera
ser uma alternativa que oferece funcionalidades offline a uma web application sem a
necessidade de qualquer instalacao no entanto esta especificacao ainda nao foi aceite
pelos principais browsers ndash o documento que define o HTML 5 ainda tem o estatuto
de Draft ndash e ainda nao e possıvel antecipar quando e que isto podera acontecer
Um dos problemas que surge frequentemente na implementacao de uma versao
offline para uma web application e a necessidade de sincronizacao de dados Quando
a informacao pode ser alterada por varios utilizadores simultaneamente e necessario
prever os conflitos que daı podem surgir e dotar a aplicacao de uma forma de os
resolver ou alertar o utilizador para a necessidade de alteracao dos dados
Em conclusao todos os objectivos propostos para este projecto foram atingidos
A prova de conceito implementada reflecte de forma clara as possibilidades oferecidas
pela tecnologia OWA e sera utilizado no futuro para compreender a melhor forma
de o implementar de forma definitiva no WOW
56
Referencias
[Ada08] Lucas Adamski Introducing Adobe AIR security model Fevereiro de2008 Disponıvel em httpwwwadobecomdevnetairarticles
introduction_to_air_securityhtml acedido em Marco de 2008
[Ado08] Adobe Adobe AIR 10 Security White Paper 2008 Disponıvel emhttpdownloadmacromediacompubairdocumentation1air_
securitypdf acedido em Marco de 2008
[Alm08] Dion Almaer Gears as a bleeding-edge html 5 implementa-tion March 2008 Disponıvel em httpalmaercomblog
gears-as-a-bleeding-edge-html-5-implementation acedido emMarco de 2008
[BL96] Tim Berners-Lee The world wide web Past present and future Agostode 1996 Disponıvel em httpwwww3orgPeopleBerners-Lee
1996ppfhtml acedido em Abril de 2008
[CDGH08] Mike Chambers Daniel Dura Dragos Georgita and Kevin Hoyt AdobeAIR for JavaScript Developers OrsquoReilly Media 2008 Disponıvel emhttponairadobecomfilesAIRforJSDevPocketGuidepdf ace-dido em Abril de 2008
[Con99] Jim Conallen Modeling Web Application Architectures with UML Junho1999 Disponıvel em httpwwwumlorgcnUMLApplicationpdf
webappspdf acedido em Maio de 2008
[Ent07] Entrust What is a public key information 2007 Disponıvel em http
wwwentrustcompkihtm acedido em Junho de 2008
[Gar05] Jesse James Garret Ajax A new approach to web applicationsFebruary 2005 Disponıvel em httpwwwadaptivepathcomideas
essaysarchives000385php acedido em Marco de 2008
[Greon] Philip Greenspun Philip and Alexrsquos Guide to Web Publishing 2003(last revision) Disponıvel em httpphilipgreenspuncompandaacedido em Junho de 2008
[Gro02a] App Design Group Thick vs thin client comparison 2002 Disponıvelem httpwwwdonjacobsvwcomimagesweekendspecials
Thick-vs-Thinpdf acedido em Junho de 2008
57
REFERENCIAS
[Gro02b] Technical Research Group Thin Client Tecnhology - WhitePaper 2002 Disponıvel em httpwwwpicktrgcompubs
thinclientwhitepaperpdf acedido em Junho de 2008
[Gro08] Miniwatts Marketing Group World internet usage March 2008Disponıvel em httpwwwinternetworldstatscomstatshtm ace-dido em Abril de 2008
[Hic08] Ian Hickson HTML 5 Draft Recommendation 2008 Disponıvelem httpwwwwhatwgorgspecsweb-appscurrent-work ace-dido em Marco de 2008
[Kha] Olga Kharif Top 10 municipal wifi plans Disponıvel em http
imagesbusinessweekcomss0608muni_wifiindex_01htm ace-dido em Marco de 2008
[Lab07] Mozilla Labs Prism Outubro 2007 Disponıvel em httplabs
mozillacom200710prism acedido em Marco de 2008
[Loo06] Chris Loosley Rich Internet ApplicationsDesign MeasurementandManagement Challenges 2006 Disponıvel em httpwwwkeynote
comdocswhitepapersRichInternet_5pdf acedido em Maio de2008
[Mic08] Microsoft Introduction to Occasionally Connected Applications us-ing Sync Services for ADONET 2008 Disponıvel em httpmsdn
microsoftcomen-ussyncbb887608aspx acedido em Junho de2008
[Nao08] Erica Naone Offline web applications Abril 2008 Disponıvelem httpwwwtechnologyreviewcomread_articleaspxch=
specialsectionsampsc=emerging08ampid=20245 acedido emAbril de 2008
[NJN00] Jason Nieh Yang S Jae and Naomi Novik A comparison of thin-clientcomputing architectures 2000 Disponıvel em httpwwwnclcs
columbiaedupublicationscucs-022-00pdf acedido em Maio de2008
[OrsquoR06] Tim OrsquoReilly Web 20 compact definition Trying again Dezembro2006 Disponıvel em httpradaroreillycomarchives200612
web-20-compact-definition-tryihtml acedido em Marco de 2008
[OrsquoR09] Tim OrsquoReilly What is Web 20 Design patterns and business modelsfor the Next Generation of Software 20053009 Disponıvel emhttpwwworeillynetcompubaoreillytimnews200509
30what-is-web-20html acedido em Marco de 2008
[Rus06] Alex Russel Comet Low latency data for the browser March Marco2006 Disponıvel em httpalexdojotoolkitorgp=545 acedidoem Marco de 2008
58
REFERENCIAS
[Sad97] Darleen Sadoski Clientserver software architecturesndashan overviewAgosto 1997 Disponıvel em httpwwwseicmuedustr
descriptionsclientserver_bodyhtml acedido em Junho de2008
[Sch96] George Schussel Clientserver past present and future 1996
[Smi07] Kevin C Smith Css filters - will the browser apply the rule July 2007Disponıvel em httpcentriclecomrefcssfilters acedido emMarco de 2008
[vK08] Anne van Kesteren The XMLHttpRequest Object W3C Work-ing Draft 15 Abril 2008 Disponıvel em httpwwww3orgTR
XMLHttpRequest acedido em Abril de 2008
[Wil06] Greg Wilkins Why ajax comet July Julho 2006 Disponıvel emhttpwwwwebtidecomdownloadswhitePaperWhyAjaxhtml ace-dido em Abril de 2008
59
REFERENCIAS
60
Anexo A
Screenshots
Algumas imagens de aplicacoes que utilizam funcionalidades offline ilustrativasda tecnologia abordada neste documento
Figura A1 Dialogo apresentado ao utilizador na primeira activacao das funcionalidadesoffline no Google Docs amp Spreadsheets
61
Screenshots
Figura A2 Na activacao das funcionalidades offline e tambem oferecida a possibilidadeda criacao de alguns atalhos por exemplo no ambiente de trabalho
Figura A3 O Google Docs mantem a todo o momento a possibilidade de alteracao destasdefinicoes ou da anulacao dos servicos offline para um dado computador
62
Screenshots
Figura A4 Apos a instalacao do Gears qualquer visita ao Remember The Milk despoletauma sincronizacao que ocorre automaticamente e sem necessidade de intervencao por partedo utilizador
Figura A5 Apos completar a sincronizacao de dados mesmo que a ligacao a Internetseja perdida o Remember the Milk continua disponıvel no browser (com excepcao dasfuncionalidades que pela sua natureza exigem uma ligacao como por exemplo partilhade tarefas e envio de convites)
63