C A P Í T U L O  1



Apresentando as Aplicações
de Internet Rica (RIAs)

O kit de ferramentas para Web do Google (Google Web Toolkit - GWT) é um framework de código aberto, que facilita a criação
de RIAs para desenvolvedores Java. Você pode usar seus conhecimentos para criar “fat clients” que podem ser implantados, como
aplicações web. Estas aplicações, com formato desktop, são, normalmente, escritas em JavaScript, visando o melhor aproveita-
mento da enorme base instalada de browsers da web. Mas o JavaScript é uma linguagem bem diferente do Java (seu nome foi
escolhido por razões de marketing) e, portanto, precisa de diferentes práticas de desenvolvimento.
Entretanto, o GWT permite que você desenvolva aplicações JavaScript em Java! Isto é obtido através da parte mais importante
do GWT, o compilador de Java para JavaScript. Este compilador traduz o seu código Java em JavaScript, executado no browser
do usuário. Como bônus, o GWT consegue lidar com a maioria dos quirks dos navegadores, permitindo que você se concentre
em escrever um código que faça algo.
Este livro objetiva mostrar como usar o GWT na construção de RIAs. Porém, antes de apresentar o GWT, detalhadamente,
precisamos, primeiro, fornecer um pouco de perspectiva histórica. Se você já está familiarizado com o funcionamento interno
da web ou se já está ciente das vantagens que o Ajax tem, comparado com as outras abordagens para a criação de RIAs, (como
o Flex), sinta-se à vontade para pular este capítulo e começar a partir do capítulo 2, que faz a introdução do GWT.
Este capítulo fornece um breve histórico dos sistemas de software, como normalmente interagimos com eles, e como tor-
namos eles disponíveis aos usuários. Apresentamos diferentes tipos de aplicativos, incluindo RIAs, e descrevemos o Ajax como
um dos meios para a criação de RIAs. Finalmente, comparamos diferentes abordagens para o desenvolvimento de RIAS, antes
de nos concentrar em uma em particular, no próximo capítulo: o GWT

Uma Breve História

Sistemas de Software já estão entre nós por vária décadas, mas só recentemente podemos dizer que começaram a ser usados
por milhões de pessoas no mundo todo. Não faz nem vinte anos, quando a maioria das aplicações de software eram somente
usadas por profissionais treinados, hoje, a maioria das pessoas no mundo interagem diretamente com uma ou mais aplicações
diariamente. Este enorme e rápido crescimento no número de usuários de computadores não poderia ter acontecido sem o
grande avanço na facilidade de uso e nas técnicas de interface que se seguiram.

Aplicações Cliente/Servidor Aplicações Web Ricas

Experiência
do Usuário

Aplicações Mainframe Aplicações Web

Eficiência no Custo
Figura 1-1.  Uma vista geral da história de aplicações de software.

1
2 C apítulo 1    A pr e s e n ta n d o a s A plica ç õ e s d E I n t e r n e t R I C A ( R I A s )

Recordando o passado, é difícil acreditar que havia gente que realmente achava divertido interagir com os primeiros com-
putadores (ainda que eu tenha que brigar com alguns que ainda usam Vim). A maioria que se lembra dos terminais de “tela
verde” vai admitir que trabalhar com um comando prompt não era geralmente a experiência mais agradável. Entrando com um
comando no teclado, dando Enter, e esperando pela saída aparecer na tela nunca vai constituir um rich client (ainda que, para
tarefas de certos usuários, seja essa, ainda, a forma apropriada e até mais produtiva).
Para evitar confusão, vamos descrever o que caracteriza um rich client. A “riqueza” do cliente está determinada pelo modelo
de interação que o cliente oferece ao usuário. Um modelo rico de interação com o usuário é o que oferece suporte para uma
variedade de métodos de entrada e que responde intuitivamente e dentro de um prazo razoável. Tal qual uma regra prática, para
ser considerado rica, a interação do usuário deverá ser tão boa quanto a mais atualizada geração de aplicativos desktop, como
editores de texto e planilhas. Isto inclui características como providenciar meios diferentes de interação (como exemplo, usando
o teclado e o mouse para navegação, edição inline e arrastar e soltar) e retorno visual (por exemplo, a mudança do formato do
cursor, anúncios em cores diferentes e mostrando botões e janelas em destaque).
A passagem daqueles velhos tipos de aplicação para aplicações ricas da web, que este livro trata, foi longa e gradual. A figura 1-1
mostra uma visão geral do estágio principal desta mudança e vai servir de base para a nossa breve história. Podemos distinguir, a
grosso modo, quatro estágios na evolução dos softwares de aplicação. A seta mostra o caminho destes estágios, através do tempo.

Aplicações Mainframe
Começando por volta de 1960, as aplicações mainframe, cujos usuários tenham acesso por meio de cartões perfurados e termi-
nais lsater (ou emulações de terminais), estabeleceram o primeiro estágio de aplicações de software. Os terminais “tela verde”
(os monitores monocromáticos da maioria dos terminais e dos antigos PCs) disponibilizavam uma interface de usuário baseada
em texto, para interação com a parte servidor da aplicação. Uma interface baseada em texto, obviamente, não permite intera-
tividade rica, como arrastar e soltar ou feedback instantâneo ao mesmo tempo que o usuário está digitando. De mais a mais,
as aplicações dos terminais não conseguem fornecer a melhor resposta, pois a entrada do usuário deve sempre ser processado
pelo servidor antes que o retorno esteja disponível ao usuário.
De uma perspectiva custo-benefício, aplicações mainframe sempre foram criticadas por ter custos de manutenção crescen-
tes que são o resultado de um círculo vicioso de falta de documentação e a dificuldade de fazer upgrade. A aplicação tinha de
ser desenvolvida para o sistema operacional específico onde seria implantada, e, possívelmente, dependendo no número de
sistemas operacionais suportados, resultando em uma maior base de código.

Aplicações Cliente/Servidor
À medida que os computadores pessoais se tornaram mais populares, as pessoas começaram a ter mais poderes em suas mesas.
Com esta revolução, veio a mudança da UI, baseada na linha de comando para uma UI mais próxima ao desktop, resultando no
modelo WIMP (janelas, ícones, menus e dispositivos como o mouse) inventado na Xerox PARC nos meados de 1970. Ainda que as
primeiras adoções pela Apple e Microsoft fossem pobres, elas permitiram aos desenvolvedores criar aplicações com características
de interação com o usuário mais ricas. O poder gráfico das máquinas desktop permitiu que as aplicações se tornassem mais amigá-
veis, com um retorno visual melhorado. No entanto, estas aplicações ainda necessitavam de um processamento e armazenamento
de dados centralizado, portanto, precisando interagir com um servidor central, sendo que, daí, veio o termo cliente/servidor.
Em termos de custo, não houve uma melhora substancial, pois, além do desenvolvimento do software do lado servidor, agora
também o lado cliente teria de ser desenvolvida. E sendo que os requisitos para o lado cliente normalmente ditavam suporte
para vários sistemas operacionais, houve um aumento maior nos custos de desenvolvimento e manutenção. Outro fator de
aumento de custos foi que o software, não era executado em um lugar central, mas sim em numerosas máquinas individuais,
toda versão nova de software necessitava de atualização em todas as máquinas onde estava instalado.

Aplicações Web
Ao mesmo tempo que as aplicações de software eram desenvolvidas no servidor central, ou em torno dele, a Internet e a Web
estavam se tornando populares e se espalhando. A Web, originalmente, era para ser uma plataforma para permitir que pessoas
pudessem compartilhar informações, publicando documentos e, através de hiperlinks, fazer referência cruzada deles. À medida
que o uso da Web se tornou mais abrangente, mais e mais pessoas começaram a ter softwares em suas máquinas que podiam
interagir com esta estrutura de documentos. O navegador web permitia funcionalidades comuns, como ir e vir através do his-
tórico da navegação e marcar determinadas páginas para uma futura recuperação. Mas a principal vantagem era que, ao invés
de ter vendedores de software tendo de criar versões específicas de suas aplicações para sistemas operacionais diferentes, eles
tinham esta enorme base instalada ao seu dispor. Se ao menos eles pudessem entrar nisso!
Para que se possa entender os próximos passos da evolução dos aplicativos de software, precisamos olhar mais detalha-
damente a estrutura e os procedimentos internos da Web. Os navegadores Web entregam documentos formatados, usando a
Hypertext Markup Language (HTML) (www.w3.org/HTML). Eles encontram o documento que o usuário quer, usando um uniform
resource locator (URL) (http://www.w3.org/Adressing) e usa um Hypertext Transfer Protocol (HTTP) (http://www.w3.org/Protocols)
para recuperar o documento de um servidor web remoto.
Este é um importante conceito da Web: na verdade, todos os documentos residem em um ou mais servidores Web, e o nave-
gador web (o cliente) recupera o documento do servidor. Ele então lê o documento HTML, aplicando as regras de formatação
definidas no arquivo (discutido mais tarde) e o transfere para a tela, para a leitura do usuário.
 C apítulo 1    A pr e s e n ta n d o a s A plica ç õ e s d E I n t e r n e t R I C A ( R I A s ) 3

A enorme popularidade da Web é, em grande parte, devida a ela ser única: só há uma Web, para onde quer que vá e seja qual
for a plataforma que você use. E, além disso, a Web está definida por um punhado de padrões industriais sem fins lucrativos que
são definidas e gerenciadas por entidades, como a World Wide Web Consortium (W3C) que estão à disposição em http://www.
w3.org) e a Internet Engineering Task Force (IETF) (http://www.ietf.org), que impediu vendedores individuais, como a Microsoft,
de se apoderar da Web através de extensões proprietárias. A Web funciona somente por que pessoas aceitam os padrões que
os navegadores podem implementar, aos quais provedores de conteúdo e desenvolvedores de aplicativos podem aderir. Não
somente o HTML, mas outros padrões, como o Cascading Style Sheets (CSS) (http://www.w3.org/Style/CSS ), Document Object
Model (DOM) (http://www.w3.org/DOM), Scalable Vector Graphics (SVG), e Portable Network Graphics (PNG) (http://www.w3.org/
Graphics/PNG) têm contribuido para o sucesso da Web. A maioria destes padrões serão discutidos ao longo deste livro.
Ao invés de usar somente a Web para entregar documentos HMTL estáticos aos usuários, alguém veio com a ideia de permitir
que os usuários solicitassem documentos gerados dinamicamente. Desse modo, por exemplo, o usuário aproveitaria os navegadores
web (já instalados) para pesquisar estatísticas em tempo real ou conteúdos pessoais. É aqui, neste ponto, que nasce a aplicação Web.
Uma aplicação web é a que reside em um servidor central e pode ser acessada por usuários que já possuam navegadores web.
Em uma perspectiva eficaz de custo, esta era uma ótima forma de desenvolvimento de software. Você desenvolve e fornece
a aplicação uma só vez, ao invés de ter de instalar aplicações clente em cada máquina de usuário, o cliente já tem todo o soft-
ware necessário pré-instalado. E quando você desenvolve uma versão nova de sua aplicação, só tem de trocar a versão central,
e porque todos os clientes interagem com a versão central, eles estarão automaticamente recebendo a nova versão.
No entanto, de um ponto de vista da riqueza, as coisas voltaram aos tempos do mainframe. Ao invés de ter a experiência
rica do desktop do usuário, permitindo múltiplos meios de interação, resposta e feedback visual, as coisas foram de novo para
o modelo de interação “entre-com-comando-e-espere”. Toda ação em um aplicativo web resulta em uma chamada ao servidor,
para gerar a próxima página ou documento. Portanto, como um cliente, você emite um comando, clicando em um link ou sub-
metendo um formulário, e então você talvez tenha de esperar centenas de milisegundos, ou até segundos, para receber a página/
documento de volta do servidor. Enquanto isso se passa, você não tem meios de interagir com a aplicação.
Ainda que exista um retrocesso óbvio, em termos de uso, o custo-beneficio, grandemente melhorado, tornou as aplicações
na web a mais popular aplicação de software, hoje em dia.

Aplicações Ricas da Web

Ainda que aplicações web tenham se tornado, de fato, o padrão para o desenvolvimento de software, elas são, na maioria dos
casos, usadas para desenvolver aplicações de propósito geral que estão publicamente disponíveis. Apesar disso, temos nume-
rosas aplicações que dependem, pesadamente, da interação rica com o usuário para completar tarefas do dia-a-dia, elas são
desenvolvidadas como aplicações cliente/servidor. A razão disso é óbvia, à medida que a Web e sua abordagem de documentos
centralizados não permitem ao usuário uma interação rica. Imagine uma aplicação do tipo planilha na Web, onde toda vez que
você entra ou modifica dados em uma célula, você tenha de esperar que a página seja toda recarregada com os valores recalcu-
lados. Isso se torna pior quando a comunicação entre cliente e servidor passa por uma rede pública, tipicamente gerando um
tempo de espera maior entre pedidos e respostas. Um tempo de espera grande para um retorno pode conduzir a um bloqueio
da aplicação e, portanto, não-aplicável para realizar um trabalho diário de uma pessoa. Portanto, esse tipo de aplicação, até
recentemente, permaneceu no domínio do cliente/servidor, alavancando a capacidade de uma aplicação verdadeiramente rica,
mas ainda carregando o fardo de ser um alvo em diferentes ambientes.
É aqui que o Ajax entra para resolver esta questão, ao permitir a desenvolvedores criar aplicações user-friendly e ainda colher
o beneficio de poder disponibilizar a aplicação na Web.

Apresentando o Ajax
Conforme foi esboçado nas seções anteriores, desenvolvedores precisavam de uma forma de desenvolver aplicações interativas
e ao mesmo tempo poder disponibilizar essas aplicações na web. O Ajax preenche exatamente essa necessidade. Por exemplo,
desenvolvedores podem usar o Ajax para prover uma funcionalidade que busca e mostra sugestões apropriadas à medida que
os usuários entram com dados em um campo de entrada. Eles também podem codificar poderosas aplicações de chat baseadas
na Web, que não necessitam de um refresh em toda a página, enquanto o usuário está teclando uma nova mensagem.
O Ajax faz isso tudo usando o JavaScript, no navegador, para modificar diretamente a UI, usando o objeto XMLHttpRequest,
que será discutido mais tarde, para se comunicar com o servidor sem dar refresh na página inteira. Então, usa a informação
retornada do servidor, normalmente em XML ou outro tipo de formato de texto, para atualizar a UI.
Antes mesmo que o termo Ajax fosse cunhado, desenvolvedores já estavam desenvolvendo aplicações como as descritas,
usando características específicas dos navegadores (como o LiveConnect Netscape http://developer.mozilla.org/en/docs/LiveCon-
nect). Mas só foi depois que Jesse James Garret cunhou o termo em seu artigo “Ajax: A New Approach to Web Applications” (http://
www.adaptivepath.com/publications/essays/archives/000385.php) que esse modelo para desenvolver aplicações realmente decolou.
Apesar que hoje Ajax seja uma palavra que não significa nada, Garret sugeriu que ela fosse um acrônimo para Asynchronous
JavaScript and XML. Vamos nos deter em cada um dos componentes deste acrônimo para poder entender o que é o Ajax.

Assíncrono
Para se entender, a principal diferença que há entre as aplicações Ajax e as que foram desenvolvidas antes do apareceimento
do Ajax, temos de olhar, atentamente, como os usuários interagem com as aplicações web. Figura 1-2 ilustra isto para uma apli-
4 C apítulo 1    A pr e s e n ta n d o a s A plica ç õ e s d E I n t e r n e t R I C A ( R I A s )

cação web típica. O usuário inicia fazendo um pedido em uma página web. O servidor processa o pedido e devolve o resultado
para o navegador, onde ele é, subsequentemente, disponibilizado para o usuário. Uma aplicação web típica só permitirá ao
usuário fazer um limitado número de coisas. O usuário pode fornecer dados de entrada através do uso de widgets de formulário
(clicando num link ou botão para submeter a informação) ou solicitando uma nova página. O resultado de ambas as ações é
que o usuário terá que esperar o servidor retornar a resposta. Nesse meio tempo, o usuário não tem acesso à aplicação. Este é o
chamado modelo síncrono de interação. Toda interação com o usuário é interrompida até que o servidor retorne a resposta, só
então o usuário pode continuar a usar a aplicação.

Cliente
Usuário Usuário Usuário
Interação Interação Interação

Resposta

Resposta
Pedido

Pedido
Rede

Servidor

Processamento Processamento
do Lado Servidor do Lado Servidor

Tempo
Figura 1-2.  O modelo de interação da uma aplicação web típica.

Ainda que seja aceitável este modelo para navegação através de páginas web (digamos, em um site de notícias), é inviável
para aplicações do dia-a-dia, como nossa planilha no exemplo anterior. É inaceitável no caso de uma aplicação tipo planilha,
modificando um dado e então tendo que esperar o servidor retornar os valores recalculados de uma fórmula. Primeiro, você
quer continuar interagindo com a planilha, enquanto o resultado da ação é recalculado. Ainda mais importante: você também
quer evitar o recebimento e nova renderização da página inteira. Isso causa um overhead extra porque o servidor tem que
regerar a página inteira, e ela será enviada através da rede e o navegador tem que gerar a página inteira, novamente.
Seria muito melhor se pudéssemos só atualizar as células relevantes na planilha. É aí que o modelo assíncrono entra no
jogo, preenchendo os espaços vazios (buracos) na interação e permitindo que o usuário continue interagindo com a aplicação,
enquanto ações anteriores são manipuladas pelo servidor. Este modelo é mostrado na Figura 1-3.
O problema com a interação mostrada na Figura 1-3 é a quebra do modelo clássico Web do pedido de página por HTTP
pelo HTML, cuja simplicidade é uma de suas maiores forças. O modo de fazer isso sem perder mais do que ganhamos é com
o Ajax engine, uma camada entre a interação do usuário e a comunicação com o servidor. Este engine roda dentro do navega-
dor e delega ações ao servidor enquanto manipula os resultados. Pelo fato que o engine despacha chamadas para o servidor e
disponibiliza resultados para o usuário, o usuário pode, nesse período, continuar interagindo com a aplicação. Em razão que
o engine adere aos mesmos padrões, o modelo Web permanence intacto.
Para implementar esse modelo assíncrono, precisamos de uma forma de enviar pedidos para o servidor de modo assíncrono,
sem fazer uma atualização de página. Como já foi anteriormente mencionado, a Web, originalmente, foi criada para estabelecer
conexões entre documentos e navegação entre eles. Portanto, nem a Web nem seus padrões suportam, diretamente, operações
do tipo Ajax. Entretanto, desenvolvedores são pessoas criativas e se houver um meio, ele será usado para conseguir fazer o
trabalho. Sucede que havia um meio de se fazer estes chamados assíncronos dos navegadores, só que não em uma forma de
navegaçao independente. O Microsoft Internet Explorer vem com um controle Active embutido (XmlHttpRequest), que poderia
ser usado para fazer uma chamada assíncrona. Mozilla/Firefox contém mecanismos próprios similares, também chamados,
convenientemente, de XmlHttpRequest, somente implementados como um objeto nativo. Ambos os mecanismos são similares
na forma que você os usa. Isto possibilitou que os desenvolvedores usassem o modelo assíncrono em aplicações que rodam na
maioria dos navegadores. Isso tornou, rapidamente, o Ajax bem popular.

Nota  Ainda que o uso de XmlHttpRequest, ora como um componente Active ou como um objeto nativo, é de longe, a forma mais popular para
enviar chamadas assíncronas ao servidor, há outras formas. Dois exemplos de outros mecanismos remotos: estão usando um iframe escondido e
adicionando dinamicamente uma tag script no cabeçalho do documento.
 C apítulo 1    A pr e s e n ta n d o a s A plica ç õ e s d E I n t e r n e t R I C A ( R I A s ) 5

Navegador
Usuário
Interação

Atualização

Atualização
Atualização

Atualização
Ação

Ação
Ajax
Engine Processamento Processamento
no Cliente no Cliente

Resposta

Resposta
Pedido

Pedido
Rede

Servidor
Processamento Processamento Processamento

no Lado Servidor no Lado Servidor no Lado Servidor

Evento
Externo

Tempo
Figura 1-3.  O modelo de uma aplicação Ajax de interação.

JavaScript
O JavaScript é uma linguagem de script criada por Brendan Ech quando ele estava trabalhando na Netscape. Originalmente, se
chamava Mocha e mais tarde LiveScript, mas foi renomeada Javascript por volta de 1995. Ainda que o nome sugira o contrário, a
linguagem é bem diferente da linguagem de programação Java, ainda que elas compartilhem, como ancestral comum, a sintaxe
do C. O JavaScript foi, provavelmente, nomeado a partir do Java por razões mercadológicas como parte da aliança estratégica
entre a Sun Microsystems e a Netscape. Alguns dizem que usaram Java no nome para dar ao JavaScript uma aura de ser a nova
linguagem “quente” de programação na web. É por causa do suporte no Netscape que o JavaScript se tornou a linguagem de script
com maior suporte entre os navegadores. A Microsoft começou a desenvolver seu próprio dialeto denominado JScript, porém,
mais tarde, passou a dar suporte ao JavaScript. Em 1966, JavaScript se submeteu a padronização, resultando nas especificações
ECMAScript com o JavaScript como uma das implementações, os outros sendo o ActionScript (muito usado pelo Adobe) e JScript,
que ainda é usado para o Active Scripting da Microsoft.
O JavaScript é uma linguagem dinâmica, francamente tipada, baseada em protótipos com funções de primeira classe. Suporta
a sintaxe da programação C estruturada, inclusive comandos de laço (loops), comandos de switch e assim por diante. Uma exceção
é que ele não suporta escopo em nível de bloco.
Para ter uma ideia melhor do JavaScript, vamos dar uma olhada na Listagem 1-1, que mostra uma página HTML simples que
usa o JavaScript para mostrar ao usuário um alerta com um valor que o usuário forneceu em um campo de entrada.

Listagem 1-1.  Exemplo de um JavaScript Embutido em uma Página HMTL

<html>
<head>
<title>JavaScript sample</title>
<script type=”text/javascript”>
function handleButtonClick() {
var input = document.getElementById(‘query’);
alert(‘Query: ‘ + input.value);
}
</script>
</head>
<body>
Query:
<input id=”query” type=”text” value=””/>
<button onclick=”handleButtonClick()”>Show</button>
</body>
</html
6 C apítulo 1    A pr e s e n ta n d o a s A plica ç õ e s d E I n t e r n e t R I C A ( R I A s )

O fragmento de JavaScript na Listagem 1-1 se parece muito com Java e é fácil entender o que o código está tentando alcançar.
No entanto, você deveria, também, notar as diferenças sutis, como as variáveis e declaração de funções. Felizmente, como verá
pelo resto deste capítulo, você não precisará saber mais sobre o JavaScript se quiser desenvolver RIAs usando GWT.
Caso queira saber mais sobre o JavaScript, tente o JavaScript 1.5 User’s Guide (http://developer.mozilla.org/en/docs/Core_
JavaScript_1.5_Guide), Beginning JavaScript with DOM Scripting and Ajax: From Novice to Professional by Christian Heilmann
(Apress, 2006), and Pro JavaScript Techniques by John Resig (Apress, 2006).

XML
Extensible Markup Language (XML) se tornou popular no mundo dos desenvolvedores como um meio de transferir dados de
uma forma que independa de linguagens. Basicamente, uma linguagem de marcação é a que emprega tags com a descrição de
como o conteudo é para ser estruturado, disponibilizado ou formatado. Por exemplo, o fragmento XML na Listagem 1-2 descreve
a estrutura de um menu.

Listagem 1-2.  Exemplo de um XML Descrevendo uma Estrutura de Menu

<?xml version=”1.0” encoding=”UTF-8”?

<menu>
<item id=”1”>
<description>
A menu item
</description>
</item>
<item id=”2”>
<description>
Another menu item
</description>
</item>
</menu>

Como se pode ver, a informação na Listagem 1-2 está estruturada de forma hierárquica. O XML é uma forma simplificada do
Standard Generalized Markup Language (SGML). Ambos SGML e XML são linguagens de metamarcação, permitindo que você
defina sua própria linguagem de marcação. Uma aplicação de SGML é HTML, conforme é mostrado na Figura 1-4. Listagem 1-3
mostra algum conteúdo textual de marcação usando HTML.

Listagem 1-3.  Exemplo de Conteúdo Contendo Marcação HMTL

<div>
<h1>New version of GWT released</h1>
<p>
Last night, word reached us that a new version of the hugely popular
application development framework by Google^TM is released.
<br>
More information:
<a href=”http://code.google.com/webtoolkit”>
http://code.google.com/webtoolkit
</a>
</p>
<p>Sept. 21, 2008</p>
</div>

Basicamente, HTML fornece um conjunto de tags pré-definidas que os desenvolvedores podem usar para adicionar marca-
ção de informação ao conteúdo. Note que no HTML, você não pode usar suas próprias tags. Portanto, mudando, por exemplo,
a mudança da tag h1 para name resultaria que o interpretador falhasse ou simplesmente ignorasse a tag.
É aí que o XML entra: ele permite você definir suas próprias tags. XML permite formas diferentes de descrever a estrutura
de seu documento através de schemas. Existem diferentes linguagens schema para o XML, incluindo o Document Type Defini-
tion (DTD), que fornece um grupo limitado de funcionalidades e um XML Schema mais poderoso. Mas como estas descrições
de documentos são opcionais, podemos, facilmente, seguir sem elas. Então, o conteúdo da Listagem 1-3 poderia ser expresso,
usando XML, conforme está mostrado na Listagem 1-4.
 C apítulo 1    A pr e s e n ta n d o a s A plica ç õ e s d E I n t e r n e t R I C A ( R I A s ) 7

Listagem 1-4.  Conteúdo Contendo Marcações XML

<newsitem>
<name>New version of GWT released</name>
<description>
Last night, word reached us that a new version of the
hugely popular application development framework by
Google^TM is released.
</description>
<link>http://code.google.com/webtoolkit</link>
<date>Sept. 21, 2008</date>
</newsitem>

Se formos comparar as Listagens 1-4 e 1-3, vamos notar que o XML adiciona maior valor na semântica do texto. Conforme
seu nome é soletrado, XML também é uma linguagem de marcação. Mas diferente do HMTL, que usa a marcação para propósitos
únicos bem-definidos, XML é também uma linguagem para a definição de linguagens de marcação. Ela agrega valor à semântica
do texto ao descrever o conteúdo das tags. Ainda assim, poderíamos escrever um interpretador que usa a informação semântica
descrita pelas tags e usá-la para formatar a informação para o usuário.
Mesmo que pareça isso, HTML não é uma extensão do XML. Isso é porque, ao contrário do XML, HTML, permite tags únicas:
tags de abertura, sem tags de fechamento, como a <br> na Listagem 1-3. Isso é permitido no SGML, mas não no XML; no XML,
cada abertura de tag deverá ter uma tag de fechamento correspondente ou então deveria ser uma tag vazia: deveria ser <br></
br> ou <br/>. Para que o HTML seja mais facilmente validado e acessível para mais dispositivos e plataformas, o Extensible.
Hypertext Markup Language (XHTML) se tornou, recentemente, popular. Isto combina os grupos de tags definidas no HTML
com a sintaxe mais restrita do XML, permitindo uma fácil validação e interpretação. A Figura 1-4 dá uma ideia geral de todas as
linguagens de marcação que estivemos discutindo até agora.
Antes de olharmos o XML e mais especificamente como ela é usada no Ajax, vamos divagar por um momento. Como já foi
mencionado, a Web funciona graças a padrões estabelecidos. Um destes padrões é o Document Object Model (DOM): ver http://
www.w3.org/DOM/. Esta plataforma e interface independente de linguagem permite que scripts e programas, dinamicamente,
acessem e atualizem o conteúdo, a estrutura e o estilo de documentos (por exemplo, documentos XML e HTML). O DOM repre-
senta um documento como uma árvore hierárquica de nós que podem ser acessados e manipulados. Todos os navegadores que
suportam JavaScript usam o DOM para representar e retornar documentos HTML. Isto permite que os desenvolvedores usem o
JavaScript para inspecionar e modificar o documento e desse modo também a UI. Se olharmos lá atrás, na Listagem 1-1, podemos
ver o quanto usamos DOM para acessar o campo de entrada e recuperar o seu valor. Usamos o método getElementById(String)
do JavaScript na representação do DOM, da página do HMTL.

SGML

HTML XML

XHTML

Figura 1-4.  SGML e uma seleção de suas sub-linguagens.

Conforme mencionado anteriormente, o XML permite a transferência de dados em um tipo de intercâmbio. Isto é exatamente
o que é usado pelas aplicações Ajax. Permite você transferir dados do cliente para o servidor e vice-versa. Isto torna fácil para
a plataforma do lado do cliente ser bem diferente da plataforma do lado servidor. Por exemplo, enquanto o lado cliente está
escrevendo em JavaScript a parte servidor pode estar escrevendo em qualquer linguagem de programação possível. Portanto,
XML se apresentava como um formato de transferência de dados ideal, quando o Ajax foi criado. No entanto, como veremos na
seção seguinte, isso se mostrou incorreto.
8 C apítulo 1    A pr e s e n ta n d o a s A plica ç õ e s d E I n t e r n e t R I C A ( R I A s )

Do AJAX para o Ajax

Até aqui, discutimos os principais components que, no passado, geraram o acrônimo AJAX. No entanto, em 2006, Garrett rede-
finiu o AJAX como Ajax (um nome simples, que não significa nada em particular).
Por que ele fez essa mudança e por que é importante discutir isso aqui? Primeiro, vamos olhar porque ele fez a mudança.
Depois de muitos anos desenvolvendo aplicações baseadas neste novo paradigma, dois de três componentes se expandiram,
além de seu contexto original. O primeiro, asynchronous, permaneceu igual, ainda que ele fosse implementado mais e mais sem
o uso dos objetos XmlHttpRequest que, originalmente, foi o maior catalizador por trás de todo o movimento. Mas os outros dois,
JavaScript e XML, estavam se expandindo lentamente. Como veremos na próxima seção, outras abordagens, como o Flex, usam
linguagem diferente do JavaScript para escrever seus scripts no ambiente do browser. Flex, por exemplo, usa o ActionScript para
fazer scripts (http://www.adobe.com/devnet/actionscript), mas também tem suporte para outras linguagens script.
Então, a parte JavaScript do acrônimo AJAX não era mais válida. Mas, ainda mais óbvio, era a necessidade da mudança da
parte XML do acrônimo. Acontece que o XML deixou de ser a melhor opção para a troca de dados entre o cliente e o servidor. É
óbvio que, em alguns casos, você poderia usar o XHTML para se comunicar com o conteúdo e colocá-lo, diretamente, dentro da
página, mas isto se torna inconveniente quando se está movendo dados normais. Isto é mais devido ao fato que os navegadores
têm a tendência de trabalhar de modo diferente com o XML, nos dois casos, porque as APIs tendem a ser diferentes, mas ainda
mais importante pelo fato que a performance pode ser muito diferente.
Portanto, depois de usar o XML no início, os desenvolvedores começaram a procurar por alternativas. Eles basicamente
acharam três alternativas ao XML:

• Um protocolo proprietário — tanto um protocolo textual ou código binário que permitisse a comunicação de dados
entre o cliente e o servidor. A vantagem de ter um protocolo proprietário é que se pode, com facilidade, otimizar tanto o
tamanho quanto a velocidade.
• JavaScript Object Notation (JSON) — JSON é um formato leve de troca de dados, baseado em pares de nomes/valores.
Originalmente baseado em JavaScript, e implementado como um subgrupo dele, JSON é uma boa ponte entre um cliente
usando JavaScript a uma implementação do servidor usando Java. Para mais informações, acesse: http://www.json.org.
• JavaScript Puro — ao invés de usar um protocolo específico, você poderia usar o JavaScript puro na rede. Ainda que esta
seja a mais poderosa e flexível opção (porque você pode usar todas as características e a sintaxe fornecida pela lingua-
gem), ela requer que o servidor gere JavaScript. Como a parte servidor é geralmente escrita em uma linguagem que não
é JavaScript, esta opção não é recomendada. É melhor usar algum tipo de formato de interface de troca, como o JSON.

Cada solução tem suas vantagens e desvantagens, mas, se olharmos a maioria das aplicações Ajax, hoje, devemos concluir
que o XML não é mais o formato de transferência de dados mais frequentemente usado. Então, Garrett redefiniu Ajax como
um nome e não mais como um acrônimo. Ele definiu Ajax como uma aplicação desenvolvida para a Web, usando DHTML (ver
barra lateral) e fazendo um tipo de comunicação de maneira assíncrona com o servidor. Essa é o tipo de aplicação que você
aprenderá a desenvolver, neste livro.

HTML DINÂMICO (DHTML)

O termo DHTML descreve o uso de várias das tecnologias já vistas, para a criação, de web sites interativos e animados. O DHTML combina a lingua-
gem estática do tipo marcação (como o HTML), com uma linguagem tipo script (como o JavaScript) no lado cliente, uma linguagem de apresentação
(como a CSS) e o DOM. A combinação dessas tecnologias permite que você, dinamicamente, mude a aparência e o comportamento de uma página
web. Mais recentemente, o DHTML está sendo também chamado de DOM Scripting, apesar que isso, de certa forma, restringe o sentido do termo.

Vantagens e Desvantagens do RIAs

Antes de explorar diferentes abordagens para a criação de RIAs, vamos, primeiro, ver as vantagens e desvantagens, em compa-
ração às aplicações clássicas da web. Nos capítulos anteriores, já tocamos em alguns desses pontos.

Benefícios Trazidos pelo RIA

Além do óbvio, benefícios intrínsecos ao se criar uma aplicação rica para a Internet, temos, também, a lista a seguir de be-
nefícios adicionais:
• Não necessita de instalação — a aplicação é baixada automaticamente e roda dentro do navegador. O software que ver-
dadeiramente roda a aplicação já está instalado na máquina do cliente.
• As atualizações são automáticas — novas versões da aplicação são baixadas automaticamente, toda vez que se visita a
página da aplicação na rede.
 C apítulo 1    A pr e s e n ta n d o a s A plica ç õ e s d E I n t e r n e t R I C A ( R I A s ) 9

• Independe de Plataforma — uma aplicação rica na Internet pode, potencialmente, rodar em qualquer plataforma e sis-
tema operacional, contanto que tenha um navegador e uma conexão à Internet.
• Maior segurança — as aplicações rodam em um ambiente restrito de um navegador web e são, portanto, menos sujeitas
a causar danos do que aplicações que precisam ser instaladas.
• Melhor resposta — pois nem todas as ações do usuário requerem comunicação como o servidor, aplicações ricas na
Internet tendem a reagir mais rápido que as clássicas aplicações da Internet.
• Mais evolutiva — uma grande parte do trabalho computacional, bem como a manutenção do estado do processo, pode
ser descarregado ao cliente, de forma que o servidor possa tratar de muito mais usuários. E sem precisar manter estados
ou pelo menos não tantos.
• Maior eficiência na rede — em clássicas aplicações da Internet, toda ação de usuário necessita que o servidor gere, nova-
mente, a página completa e mande-a através de rede. No caso da aplicação de Internet rica, toda UI da aplicação só precisa
ser comunicada uma vez. Todos os demais pedidos ao servidor só necessitam que o dado corrente seja enviado ao cliente.

Falhas do RIA
Normalmente, com coisas boas, junto, temos alguns inconvenientes. O mesmo acontece com o Ajax e na criação de aplicações
de Internet ricas. A seguir algumas das limitações:

• Necessita do JavaScript ou plug-in específico — porque a aplicação completa roda através do interpretador JavaScript no
cliente, o que sucede quando o cliente desliga, completamente, o JavaScript? Normalmente, a aplicação faz pouca coisa
ou não faz nada. Ter um plano de backup para esses usuários é uma coisa óbvia, mas aí então você terá de manter duas
aplicações separadas, o que está longe do ideal.
• Não tem acesso a recursos do sistema — como as aplicações rodam dentro de um navegador, elas estão limitadas quanto
aos recursos que elas podem acessar. Por exemplo, uma aplicação Ajax não pode acessar o sistema de arquivos do cliente.
• Difícil para os engines de pesquisa atingir indexação plena — devido ao que a maioria dos engines de consulta não (ain-
da não) suportam aplicações que fazem atualizações parciais de páginas ou usam plug-ins específicos, como o Flash, a
maioria das aplicações de Internet ricas são, pobremente, indexadas por engines de busca. Os maiores engines de busca
planejam melhorar o suporte para este tipo de aplicações, à medida que a sua popularidade aumenta, mas sempre será
difícil indexá-las o suficiente.
• Problemas de Acessibilidade — atualizações parciais de páginas usando JavaScript ou um plug-in específico podem
quebrar a acessibilidade. O maior e mais conhecido problema é que as leitoras de telas existentes não manejam isso cor-
retamente. Ainda que as leitoras de telas tentem a fornecer um suporte melhor, desenvolvedores de aplicações deveriam
sempre ter, em mente, quando forem desenvolver aplicações e ainda mais quando forem do tipo rica na Internet, porque
acessibilidade é fácil de ser rompida.
• Dependência de conexão Internet - porque essas aplicações são servidas pela Web e rodam em um navegador, elas ne-
cessitam, pelo menos, uma conexão inicial com a Internet. Mas, mesmo durante o uso, uma comunicação com a Internet
é necessária para se comunicar com o servidor. Quando a conexão (temporariamente) não está disponível, a maioria das
aplicações rica na Internet falham, não funcionam. Entretanto, há tentativas para se usar os services locais fornecidos
pelo navegador para um armazenamento temporário enquanto uma conexão não se encontra disponível.

Quando é Que Você Deve Usar o Ajax?

Baseado nos benefícios e inconvenientes mostrados na seção anterior, estamos fortemente inclinados a acreditar que as apli-
cações de Internet rica não são para todas as aplicações. Mas há orientações que indicam quando construir uma aplicação de
Internet rica e quando se manter no desenvolvimento do tipo aplicação web clássico o que você vem fazendo já há algum tempo.
Considere a lista a seguir:

• Você quer desenvolver uma aplicação que os usuários necessitam usar diariamente e gastam bastante tempo usando-a.
• Tarefas de negócios que contam com uma resposta direta da aplicação para melhoria da produtividade.
• A maioria senão todas as aplicações, necessitam autenticação e autorização do usuário, então nestes casos a indexação
pelos engines de busca não é uma alta prioridade.
• É certo assumir que o JavaScript já esteja disponível ou é aceitável solicitar aos usuários que o acionem antes de usar
a aplicação.

Achamos que se a sua aplicação segue estes pré-requisitos, a preferência deveria ser dada a uma aplicação de Internet rica.
Assumindo que você tem uma aplicação em mente (pelo menos na mente), olhemos as diferentes abordagens que estão dispo-
níveis para o desenvolvimento dessas aplicações.
10 C apítulo 1    A pr e s e n ta n d o a s A plica ç õ e s d E I n t e r n e t R I C A ( R I A s )

As Diferentes Abordagens para a Construção de RIAs

Para construir estas aplicações da Internet rica, precisamos de uma maneira fácil de desenvolver o código que roda nos na-
vegadores e um modo de se chamar o servidor remotamente. Vamos olhar ligeiramente as diferentes abordagens disponíveis.
Note que isto não foi destinado a ser uma exaustiva listagem de todas as soluções e frameworks, mas só um destaque das
diferentes abordagens.

Escrever JavaScript Manualmente

A primeira, e mais largamente, usada forma de desenvolver aplicações Ajax é pegando uma aplicação web normal e adi-
cionar funcionalidades do Ajax através de codificação em JavaScript. Você, normalmente, usaria bibliotecas pré-existentes
que permitiriam você manter o foco em coisas realmente importantes enquanto usasse características já conhecidas, como
uso remoto e classes de conveniência para manipulação da interface. Geralmente, há quatro preocupações no que tange
essa abordagem:

• JavaScript não é Java — usando JavaScript para desenvolver aplicações é totalmente diferente que desenvolver
aplicações em Java. Não são só duas linguagens distintas, com seus conceitos e contrução próprios, mas também
requerem um conjunto diferente de ferramentas. Mesmo que seja prazeroso para os desenvolvedores aprender uma
nova linguagem, essa, talvez, não seja a melhor escolha partindo de uma perspectiva de negócios. A solução óbvia
seria contratar desenvolvedores de JavaScript profissionais; só que bons desenvolvedores de JavaScript realmente
experientes são difíceis de achar.
• Browser quirks — o maior desafio e provavelmente a atividade que mais consome tempo no desenvolvimento de apli-
cações Ajax é a codificaçao que manipule todas as diferenças entre os navegadores e até mesmo entre versões diferentes
do mesmo navegador. Um bom desenvolvedor de JavaScript deveria saber todos essas estravagâncias de cor.
• Bibliotecas demais — assumindo que você não quer reinventar a roda, você saí a procura de bibliotecas que lhe dê as
características básicas que necessita. Mas onde começar e qual é a que você deve escolher para o seu projeto particular?
Até a hora que este texto foi escrito, AjaxPatterns.org listou 42 frameworks de propósito múltiplo e 51 frameworks Java
Ajax, que dá um total de 93 frameworks para a criação de sua aplicação.
• Bibliotecas resolvem só parte do Quebra-cabeça — escolher uma biblioteca, geralmente, não é suficiente, normalmente,
elas resolvem parte do quebra-cabeça quando só um aspecto da criação de aplicações Ajax. Uma pode conter funciona-
lidades básicas para ações remotas, enquanto outra fornece widgets, e uma terceira trata dos efeitos visuais. Então você
acaba com um número de frameworks diferentes que você tem de amarrar, formando uma só aplicação.
Esta abordagem é viável quando se limita a adição de funcionalidades Ajax a uma aplicação web tradicional. Mas levando
em conta esses cuidados, não sugerimos que use esta abordagem para desenvolver aplicações de Internet rica como as
que foram discutidas anteriormente.

Flex
Adobe Flex é um conjunto de ferramentas para o desenvolvimento de aplicações de Internet rica, na plataforma proprietá-
ria Adobe Flash. O Flash, sozinho, oferece muito mais que você poderia obter com o HTML em termos de interatividade em
tempo real. No entanto, desenvolvendo aplicações ricas em Flash é desafiante e intuitivo para desenvolvedores de núcleo.
A ferramenta de desenvolvimento do Flash está preparada para designers, desenvolvendo em um timeline é um estranho
conceito para aplicações que não são movidas pelo tempo mas por ações de seus usuários. Flex remove aquela barreira de
entrada, fornecendo uma forma programática de desenvolver RIAs. Ainda que a plataforma Flex, originalmente, tenha sido
desenvolvida, pela Macromedia, em 2004, como um produto comercial, Adobe abriu partes do código fonte, em 2007, depois
de ter adquirido a Macromedia.
Quando desenvolver aplicações ricas na Internet rica, usando Flex, você usa ferramentas fornecidas pela Adobe. O bom disso
tudo é que o Flex vem com muitas funcionalidades embutidas, como widgets, arrastar e soltar, gráficos vetoriais e animações.
Isto deve acelerar, em muito, seu desenvolvimento, especialmente se você for familiar com o Flash e o ActionScript.
A principal vantagem ao usar Flex é que você desenvolve aplicações para rodar dentro do ambiente controlado pelo plug-in
do Flash. E, por isso, você não tem que levar em conta o quirk mode do navegador. Por outro lado, o plug-in deve estar instalado
no computador do cliente, o que pode não ser verdadeiro em alguns ambientes bloqueados, como escolas e agências governa-
mentais. Alguns puristas também sentem que o Flex não é um verdadeiro framework de aplicação Ajax, porque ele não aderiu
aos padrões usados normalmente para criar aplicações Ajax, como o XHTML e JavaScript.
Em fevereiro de 2008, Adobe liberou o runtime Adobe AIR, que permite que aplicações desenvolvidas em Flex sejam im-
plementadas como aplicações desktop locais, enquanto ainda gozavam dos benefícios do Ajax, como instalação e atualização
contínua. O principal benefício do AIR é que ele dá aos desenvolvedores de aplicações o melhor de dois mundos: você pode
usar o modelo de implantação da aplicação web enquanto ainda consegue, se precisar, integração no desktop. Uma cobertura
maior e mais detalhes do Flex e um guia de como melhorar a velocidade, podem ser encontrados no The Essential Guide to Flex
3 by Charles E. Brown (Friends of ED, 2008).
 C apítulo 1    A pr e s e n ta n d o a s A plica ç õ e s d E I n t e r n e t R I C A ( R I A s ) 11

O Adobe Flex, especialmente depois do lançamento do Adobe AIR, é uma boa opção para o desenvolvimento de aplicações
de Internet rica. Especialmente quando você não consegue ficar sem características de integração do desktop, como notificação
ao usuário, integração na inicialização, processamento em segundo plano e (a mais importante) acesso ao sistema, de arquivos
local. Flex é uma grande opção. No entanto, lembrem-se que mesmo sendo, na sua maior parte, um código-fonte aberto, ele
ainda necessita que os usuários instalem seus plug-ins proprietários antes de usar suas aplicações desenvolvidas em Flex.
Mais informações sobre o Flex podem ser encontradas em http://www.adobe.com/products/flex e mais sobre Adobe AIR pode
ser encontrado em http://www.adobe.com/products/air.

Applets Java e JavaFX

Outra abordagem na criação de aplicações de Internet rica é usar applets Java ou mais recentemente JavaFX. A parte mais
interessante do JavaFX, para nossos propósitos, é o JavaFX Script, uma linguagem script para a fácil criação de mídia rica
e conteúdo interativo. No entanto, está embutida na plataforma de desenvolvimento Java, então se você quiser implantar
aplicações JavaFX na Web, você está, na realidade, implantando um applet Java, porém desenvolvido com JavaFX. Portanto,
vamos discutir applets nesta seção e só destacar que ele também cobre aplicações escritas em JavaFX.
O principal benefício de um applet Java é um programa em Java que roda no lado cliente. Ainda que haja algumas restrições
de seguranças óbvias quando se roda a partir do navegador, você pode fazer o que quiser com o applet Java, por exemplo se
conectar ao servidor de origem e criar threads. Você pode até desfazer todas as restrições de segurança através de uma assina-
tura digital e solicitando ao usuário permissões adicionais, como acesso ao sistema de arquivos local. Portanto, se você quer
criar uma aplicação de Internet rica, esta parece ser a solução ideal. Mais informações detalhadas, podem ser encontradas
em JavaFX Script: Dynamic Java Scripting for Rich Internet/Client-side Applications by James L. Weaver (Apress, 2007).
O principal problema com applets Java e JavaFX é a necessidade de um Java Runtime Environment ( JRE) a ser instalado
no cliente. O JRE tem uma base instalada menor do que, por exemplo, o Flash Player. Outra preocupação é que, depen-
dendo dos requisitos e do tempo de desenvolvimento, você talvez precise de uma versão diferente do JRE. Indo adiante, ao
contrário do Flash Player, o JRE ocupa um espaço de download substancial de 14Mb para instalação offline na plataforma
Windows, no momento da gravação. Tabela 1-1 fornece uma visão geral da penetração no Mercado e tamanho de downlo-
ads dos pacotes discutidos nesta seção. Mais informações detalhadas sobre applets Java e JavaFX, podem ser encontradas
em http://java.sun.com/javafx.

Silverlight
O Silverlight é a tentativa recente da Microsoft de fornecer uma plataforma similar ao Flash. Está restrita a um subconjunto do
.NET framework e, portanto, deverá ser mais adequado para o desenvolvimento de aplicações de Internet ricas. Mesmo que
o Silverlight esteja começando a chamar a atenção, ele ainda tem um longo caminho pela frente até que se possa considerar
como uma alternativa séria ao Flash. Neste momento, a maior barreira ao Silverlight é expandir a sua base instalada. Até agora,
sua penetração no Mercado é quase nula. Mas como o Adobe, que levou muitos anos para que suas ações atingissem o corrente
valor no mercado, é bem provável que leve bastante tempo antes que o Silverlight possa começar a desafiar o Flash.
Outro problema que surge quando se desenvolve aplicações de Internet ricas com o Silverlight, é que os executáveis só estão
disponíveis para plataforma a Windows. Não se pode prever, para um futuro próximo, nenhum usuário Mac ou Linux usando
aplicações desenvolvidas com Silverlight. Também, o tamanho do download do Silverlight é maior do que o do Flash. Por estas
razões, não consideramos que o Silverlight seja uma opção séria para o desenvolvimento de aplicações de Internet ricas, até este
momento pelo menos, e não até que adquira uma base instalada considerável e que a Microsoft libere runtimes para usuários
Mac e Linux. Mais informações e detalhes sobre o Silverlight, podem ser encontradas em http://www.silverlight.net.

Tabela 1-1.  Penetração de Mercado de Instalação das Soluções e Tamanho do Download

Product Market Penetração (Arredondado) Download Size (in Mb)

Flex/Flash 99% 1.5

Java/JavaFX 85% 14
Silverlight 0% 10

OpenLaszlo
Outro produto que queremos destacar é o OpenLaszlo, liberado por Lazlo Systems sob a Common Public License. A abordagem
do OpenLazlo define sua UI na sua própria linguagem de programação LZX. LZX, basicamente, é o XML com trechos de código
JavaScript embutidos, descrevendo a lógica da aplicação. OpenLaszlo então pega as definições do UI e gera uma aplicação de
Internet rica. As versões anteriores somente permitiam que a aplicação fosse traduzida em uma aplicação Flash funcional e
completa. Isso cria os mesmos problemas encontrados na abordagem do Flex. Mas começando da versão 4 do OpenLaszlo,
agora ele suporta a tradução da UI em uma aplicação DHTML. A última versão também suporta compilações entre plataformas
embutidas, como celulares e outros dispositivos.
12 C apítulo 1    A pr e s e n ta n d o a s A plica ç õ e s d E I n t e r n e t R I C A ( R I A s )

O principal problema com o OpenLaszlo é que ele requer que toda a lógica das aplicações seja escrita em JavaScript. Isso
remete ao mesmos problemas discutidos na seção sobre JavaScript (código adicional). Mas, OpenLaszlo reinvindica que elimi-
nou um bom número de problemas de incompatibilidades entre os navegadores, porque o compilador, hoje, está ciente deles
(veja Figura 1-5).

Flash Player
SWF (Qualquer
Navegador)

Código da
Compilador DHTML
Aplicação DHTML
OpenLazslo Navegador
(em LZX)

Embutidos Mobile
Runtimes Phones

Figura 1-5.  Código de aplicação OpenLaszlo compilado para diferentes formatos de saída.

Para mais informações sobre o OpenLaszlo, veja http://www.openlaszlo.org.

Echo2
O Echo é outra abordagem para o desenvolvimento de Aplicações de Internet Rica. A versão estável, no momento, que estamos é a
Echo2. Echo2 vem com uma boa abordagem para a construção destas aplicações, ela permite que você escreva-as em Java. No Echo2,
você escreve um servlet que cuida de todos os pedidos de usuários e cria uma aplicação única para cada usuário. Uma aplicação
é criada extendendo a classe ApplicationInstance. Esta instância da aplicação determina a UI da aplicação e cuida dos eventos do
usuário. Porque uma nova instância da aplicação é criada para cada usuário, também ela guarda todos os estados. Internamente,
a instância da aplicação está armazenada na seção do usuário. O framework Echo parte para uma abordagem revolucionária para
desenvolver Aplicações de Internet Rica. Mas, na nossa opinião, há principalmente dois problemas com o Echo2:

• (Quase) toda ação do usuário resulta em um acesso ao servidor — por causa da forma que o Echo2 trabalha internamen-
te, mantendo o estado servidor na seção do usuário, toda ação que o usuário realize precisa ser comunicada ao servidor.
Na nossa opinião, uma aplicação de internet rica deveria se comunicar com o servidor somente quando necessário. Em
outras palavras, a aplicação deveria rodar só no navegador e somente se comunicar com o servidor quando tivesse que
recuperar dados ou realizar uma ação no lado servidor ou ambos.
• Mantém todos os estados no servidor — por natureza, uma Aplicações de Internet Rica mantém a maioria, se não todos,
os estados no cliente. Isso torna possível offload do servidor e uma melhor escalabilidade. Uma coisa que aprendemos, no
passar dos anos, desenvolvendo aplicações Java que manejam grande número de usuários, é que você deveria manter o
mínimo possível de estados no servidor. Construindo aplicações ricas no lado cliente torna em grande parte isso possível,
mas sentimos que o Echo2 dificulta isso quando mantém a maioria dos estados no servidor.

Mais detalhes e informações, podem ser encontradas em http://echo.nextapp.com/site/echo2.

GWT
Como o GWT é o assunto deste livro e será apresentado com detalhes no próximo capítulo, não nos aprofundaremos aqui.
Mas olhando o GWT em contraste com as soluções que aqui foram discutidas previamente, há duas principais coisas que
merecem nota. Primeiro de tudo, GWT se parece um bocado com OpenLaszlo no sentido que a aplicação que você desenvolve
no GWT eventualmente será compilada em uma aplicação DHTML e vai rodar integralmente no navegador usando XHMTL
e JavaScript.
Porém, a principal vantagem que o GWT tem sobre, por exemplo, o OpenLaszlo é que, ao invés de definir sua UI em XML e
JavaScript, as aplicações são desenvolvidas em Java. Então, para os desenvolvedores Java, isto naturalmente cai com naturali-
dade. Você pode usar novamente sua experiência e conhecimento técnico, IDE favorita e ferramentas de desenvolvimento. O
benefício de usar GWT sobre as outras ferramentas, como Echo2 é que o código GWT compila completamente a parte cliente
da aplicação JavaScript e não faz só uma proxy para aplicação Java no servidor.
O concorrente mais sério do GWT é o Flex. Mas, na nossa opinião, GWT possue duas vantagens: Primeiro é um código-fonte
totalmente aberto, ao passo que o Flex é um código-fonte parcialmente aberto e, segundo, uma aplicação GWT compilada roda
em qualquer navegador moderno (assumindo que o JavaScript esteja rodando) enquanto que a aplicação Flex só roda nos sis-
temas onde o Flash player está instalado.
 C apítulo 1    A pr e s e n ta n d o a s A plica ç õ e s d E I n t e r n e t R I C A ( R I A s ) 13

Resumo
Neste capítulo, apresentamos o conceito de uma Aplicação de Internet Rica (RIA) e mostramos de onde ele surgiu, dando al-
gum background histórico. Fomos das aplicações em Mainframe, com as terríveis experiências de seus usuários e sua limitada
relação custo/benefício até a aplicação de internet rica que são superiores em ambos os aspectos. A seguir, introduzimos Ajax,
discutindo cada letra do acrônimo original e mostrando porque não é mais um acrônimo. Mais importante ainda, discutimos
as vantagens e desvantagens do uso do Ajax, para o desenvolvimento de RIAs, e apresentamos algumas orientações, mostrando
quais aplicações se prestam melhor para o Ajax. Por fim, demos nossa contribuição em diversas abordagens para a criação de
aplicações Ajax, apresentando algumas estratégias diferentes, juntas com sua forças e fraquezas. Isso revelou porque acredita-
mos que o GWT seja a melhor solução disponível atualmente para desenvolvimento de de RIAs, e porque o resto do livro trata
do GWT e não uma das outras tecnologias. No próximo capítulo, vamos apresentar o GWT com mais detalhes, mostrando um
layout de uma típica aplicação GWT. Apresentaremos, também, um exercício com uma aplicação que construiremos, gradati-
vamente, no curso deste livro.