CAPTULO 1

Apresentando as Aplicaes de Internet Rica (RIAs)

kit de ferramentas para Web do Google (Google Web Toolkit - GWT) um framework de cdigo aberto, que facilita a criao de RIAs para desenvolvedores Java. Voc pode usar seus conhecimentos para criar fat clients que podem ser implantados, como aplicaes web. Estas aplicaes, com formato desktop, so, normalmente, escritas em JavaScript, visando o melhor aproveitamento da enorme base instalada de browsers da web. Mas o JavaScript uma linguagem bem diferente do Java (seu nome foi escolhido por razes de marketing) e, portanto, precisa de diferentes prticas de desenvolvimento. Entretanto, o GWT permite que voc desenvolva aplicaes JavaScript em Java! Isto obtido atravs da parte mais importante do GWT, o compilador de Java para JavaScript. Este compilador traduz o seu cdigo Java em JavaScript, executado no browser do usurio. Como bnus, o GWT consegue lidar com a maioria dos quirks dos navegadores, permitindo que voc se concentre em escrever um cdigo que faa algo. Este livro objetiva mostrar como usar o GWT na construo de RIAs. Porm, antes de apresentar o GWT, detalhadamente, precisamos, primeiro, fornecer um pouco de perspectiva histrica. 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 criao de RIAs, (como o Flex), sinta-se vontade para pular este captulo e comear a partir do captulo 2, que faz a introduo do GWT. Este captulo fornece um breve histrico dos sistemas de software, como normalmente interagimos com eles, e como tornamos eles disponveis aos usurios. Apresentamos diferentes tipos de aplicativos, incluindo RIAs, e descrevemos o Ajax como um dos meios para a criao de RIAs. Finalmente, comparamos diferentes abordagens para o desenvolvimento de RIAS, antes de nos concentrar em uma em particular, no prximo captulo: o GWT

Uma Breve Histria

Sistemas de Software j esto entre ns por vria dcadas, mas s recentemente podemos dizer que comearam a ser usados por milhes de pessoas no mundo todo. No faz nem vinte anos, quando a maioria das aplicaes de software eram somente usadas por profissionais treinados, hoje, a maioria das pessoas no mundo interagem diretamente com uma ou mais aplicaes diariamente. Este enorme e rpido crescimento no nmero de usurios de computadores no poderia ter acontecido sem o grande avano na facilidade de uso e nas tcnicas de interface que se seguiram.

Aplicaes Cliente/Servidor

Aplicaes Web Ricas

Experincia do Usurio

Aplicaes Mainframe Ecincia no Custo

Aplicaes Web

Figura 1-1. Uma vista geral da histria de aplicaes de software.

1

C A P T U L O 1 A P R e s e n TA n d O A s A P L I C A e s d e I n T e R n e T R I C A ( R I A s )

Recordando o passado, difcil acreditar que havia gente que realmente achava divertido interagir com os primeiros computadores (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 no era geralmente a experincia mais agradvel. Entrando com um comando no teclado, dando Enter, e esperando pela sada aparecer na tela nunca vai constituir um rich client (ainda que, para tarefas de certos usurios, seja essa, ainda, a forma apropriada e at mais produtiva). Para evitar confuso, vamos descrever o que caracteriza um rich client. A riqueza do cliente est determinada pelo modelo de interao que o cliente oferece ao usurio. Um modelo rico de interao com o usurio o que oferece suporte para uma variedade de mtodos de entrada e que responde intuitivamente e dentro de um prazo razovel. Tal qual uma regra prtica, para ser considerado rica, a interao do usurio dever ser to boa quanto a mais atualizada gerao de aplicativos desktop, como editores de texto e planilhas. Isto inclui caractersticas como providenciar meios diferentes de interao (como exemplo, usando o teclado e o mouse para navegao, edio inline e arrastar e soltar) e retorno visual (por exemplo, a mudana do formato do cursor, anncios em cores diferentes e mostrando botes e janelas em destaque). A passagem daqueles velhos tipos de aplicao para aplicaes ricas da web, que este livro trata, foi longa e gradual. A figura 1-1 mostra uma viso geral do estgio principal desta mudana e vai servir de base para a nossa breve histria. Podemos distinguir, a grosso modo, quatro estgios na evoluo dos softwares de aplicao. A seta mostra o caminho destes estgios, atravs do tempo.

Aplicaes Mainframe
Comeando por volta de 1960, as aplicaes mainframe, cujos usurios tenham acesso por meio de cartes perfurados e terminais lsater (ou emulaes de terminais), estabeleceram o primeiro estgio de aplicaes de software. Os terminais tela verde (os monitores monocromticos da maioria dos terminais e dos antigos PCs) disponibilizavam uma interface de usurio baseada em texto, para interao com a parte servidor da aplicao. Uma interface baseada em texto, obviamente, no permite interatividade rica, como arrastar e soltar ou feedback instantneo ao mesmo tempo que o usurio est digitando. De mais a mais, as aplicaes dos terminais no conseguem fornecer a melhor resposta, pois a entrada do usurio deve sempre ser processado pelo servidor antes que o retorno esteja disponvel ao usurio. De uma perspectiva custo-benefcio, aplicaes mainframe sempre foram criticadas por ter custos de manuteno crescentes que so o resultado de um crculo vicioso de falta de documentao e a dificuldade de fazer upgrade. A aplicao tinha de ser desenvolvida para o sistema operacional especfico onde seria implantada, e, possvelmente, dependendo no nmero de sistemas operacionais suportados, resultando em uma maior base de cdigo.

Aplicaes Cliente/Servidor
medida que os computadores pessoais se tornaram mais populares, as pessoas comearam a ter mais poderes em suas mesas. Com esta revoluo, veio a mudana da UI, baseada na linha de comando para uma UI mais prxima 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 adoes pela Apple e Microsoft fossem pobres, elas permitiram aos desenvolvedores criar aplicaes com caractersticas de interao com o usurio mais ricas. O poder grfico das mquinas desktop permitiu que as aplicaes se tornassem mais amigveis, com um retorno visual melhorado. No entanto, estas aplicaes 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, no houve uma melhora substancial, pois, alm do desenvolvimento do software do lado servidor, agora tambm o lado cliente teria de ser desenvolvida. E sendo que os requisitos para o lado cliente normalmente ditavam suporte para vrios sistemas operacionais, houve um aumento maior nos custos de desenvolvimento e manuteno. Outro fator de aumento de custos foi que o software, no era executado em um lugar central, mas sim em numerosas mquinas individuais, toda verso nova de software necessitava de atualizao em todas as mquinas onde estava instalado.

Aplicaes Web
Ao mesmo tempo que as aplicaes 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 informaes, publicando documentos e, atravs de hiperlinks, fazer referncia cruzada deles. medida que o uso da Web se tornou mais abrangente, mais e mais pessoas comearam a ter softwares em suas mquinas que podiam interagir com esta estrutura de documentos. O navegador web permitia funcionalidades comuns, como ir e vir atravs do histrico da navegao e marcar determinadas pginas para uma futura recuperao. Mas a principal vantagem era que, ao invs de ter vendedores de software tendo de criar verses especficas de suas aplicaes 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 prximos passos da evoluo dos aplicativos de software, precisamos olhar mais detalhadamente 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 usurio 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 navegador web (o cliente) recupera o documento do servidor. Ele ento l o documento HTML, aplicando as regras de formatao definidas no arquivo (discutido mais tarde) e o transfere para a tela, para a leitura do usurio.

C A P T U L O 1 A P R e s e n TA n d O A s A P L I C A e s d e I n T e R n e T R I C A ( R I A s )

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, alm disso, a Web est definida por um punhado de padres industriais sem fins lucrativos que so definidas e gerenciadas por entidades, como a World Wide Web Consortium (W3C) que esto disposio 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 atravs de extenses proprietrias. A Web funciona somente por que pessoas aceitam os padres que os navegadores podem implementar, aos quais provedores de contedo e desenvolvedores de aplicativos podem aderir. No somente o HTML, mas outros padres, 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) tm contribuido para o sucesso da Web. A maioria destes padres sero discutidos ao longo deste livro. Ao invs de usar somente a Web para entregar documentos HMTL estticos aos usurios, algum veio com a ideia de permitir que os usurios solicitassem documentos gerados dinamicamente. Desse modo, por exemplo, o usurio aproveitaria os navegadores web (j instalados) para pesquisar estatsticas em tempo real ou contedos pessoais. aqui, neste ponto, que nasce a aplicao Web. Uma aplicao web a que reside em um servidor central e pode ser acessada por usurios 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 aplicao uma s vez, ao invs de ter de instalar aplicaes clente em cada mquina de usurio, o cliente j tem todo o software necessrio pr-instalado. E quando voc desenvolve uma verso nova de sua aplicao, s tem de trocar a verso central, e porque todos os clientes interagem com a verso central, eles estaro automaticamente recebendo a nova verso. No entanto, de um ponto de vista da riqueza, as coisas voltaram aos tempos do mainframe. Ao invs de ter a experincia rica do desktop do usurio, permitindo mltiplos meios de interao, resposta e feedback visual, as coisas foram de novo para o modelo de interao entre-com-comando-e-espere. Toda ao em um aplicativo web resulta em uma chamada ao servidor, para gerar a prxima pgina ou documento. Portanto, como um cliente, voc emite um comando, clicando em um link ou submetendo um formulrio, e ento voc talvez tenha de esperar centenas de milisegundos, ou at segundos, para receber a pgina/ documento de volta do servidor. Enquanto isso se passa, voc no tem meios de interagir com a aplicao. Ainda que exista um retrocesso bvio, em termos de uso, o custo-beneficio, grandemente melhorado, tornou as aplicaes na web a mais popular aplicao de software, hoje em dia.

Aplicaes Ricas da Web

Ainda que aplicaes web tenham se tornado, de fato, o padro para o desenvolvimento de software, elas so, na maioria dos casos, usadas para desenvolver aplicaes de propsito geral que esto publicamente disponveis. Apesar disso, temos numerosas aplicaes que dependem, pesadamente, da interao rica com o usurio para completar tarefas do dia-a-dia, elas so desenvolvidadas como aplicaes cliente/servidor. A razo disso bvia, medida que a Web e sua abordagem de documentos centralizados no permitem ao usurio uma interao rica. Imagine uma aplicao do tipo planilha na Web, onde toda vez que voc entra ou modifica dados em uma clula, voc tenha de esperar que a pgina seja toda recarregada com os valores recalculados. Isso se torna pior quando a comunicao entre cliente e servidor passa por uma rede pblica, 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 aplicao e, portanto, no-aplicvel para realizar um trabalho dirio de uma pessoa. Portanto, esse tipo de aplicao, at recentemente, permaneceu no domnio do cliente/servidor, alavancando a capacidade de uma aplicao verdadeiramente rica, mas ainda carregando o fardo de ser um alvo em diferentes ambientes. aqui que o Ajax entra para resolver esta questo, ao permitir a desenvolvedores criar aplicaes user-friendly e ainda colher o beneficio de poder disponibilizar a aplicao na Web.

Apresentando o Ajax
Conforme foi esboado nas sees anteriores, desenvolvedores precisavam de uma forma de desenvolver aplicaes interativas e ao mesmo tempo poder disponibilizar essas aplicaes na web. O Ajax preenche exatamente essa necessidade. Por exemplo, desenvolvedores podem usar o Ajax para prover uma funcionalidade que busca e mostra sugestes apropriadas medida que os usurios entram com dados em um campo de entrada. Eles tambm podem codificar poderosas aplicaes de chat baseadas na Web, que no necessitam de um refresh em toda a pgina, enquanto o usurio 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 pgina inteira. Ento, usa a informao 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 aplicaes como as descritas, usando caractersticas especficas dos navegadores (como o LiveConnect Netscape http://developer.mozilla.org/en/docs/LiveConnect). 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 aplicaes realmente decolou. Apesar que hoje Ajax seja uma palavra que no significa nada, Garret sugeriu que ela fosse um acrnimo para Asynchronous JavaScript and XML. Vamos nos deter em cada um dos componentes deste acrnimo para poder entender o que o Ajax.

Assncrono
Para se entender, a principal diferena que h entre as aplicaes Ajax e as que foram desenvolvidas antes do apareceimento do Ajax, temos de olhar, atentamente, como os usurios interagem com as aplicaes web. Figura 1-2 ilustra isto para uma apli-

C A P T U L O 1 A P R e s e n TA n d O A s A P L I C A e s d e I n T e R n e T R I C A ( R I A s )

cao web tpica. O usurio inicia fazendo um pedido em uma pgina web. O servidor processa o pedido e devolve o resultado para o navegador, onde ele , subsequentemente, disponibilizado para o usurio. Uma aplicao web tpica s permitir ao usurio fazer um limitado nmero de coisas. O usurio pode fornecer dados de entrada atravs do uso de widgets de formulrio (clicando num link ou boto para submeter a informao) ou solicitando uma nova pgina. O resultado de ambas as aes que o usurio ter que esperar o servidor retornar a resposta. Nesse meio tempo, o usurio no tem acesso aplicao. Este o chamado modelo sncrono de interao. Toda interao com o usurio interrompida at que o servidor retorne a resposta, s ento o usurio pode continuar a usar a aplicao.

Cliente
Usurio Interao Usurio Interao Usurio Interao

Resposta

Rede

Servidor
Processamento do Lado Servidor Processamento do Lado Servidor

Tempo
Figura 1-2. O modelo de interao da uma aplicao web tpica. Ainda que seja aceitvel este modelo para navegao atravs de pginas web (digamos, em um site de notcias), invivel para aplicaes do dia-a-dia, como nossa planilha no exemplo anterior. inaceitvel no caso de uma aplicao tipo planilha, modificando um dado e ento tendo que esperar o servidor retornar os valores recalculados de uma frmula. Primeiro, voc quer continuar interagindo com a planilha, enquanto o resultado da ao recalculado. Ainda mais importante: voc tambm quer evitar o recebimento e nova renderizao da pgina inteira. Isso causa um overhead extra porque o servidor tem que regerar a pgina inteira, e ela ser enviada atravs da rede e o navegador tem que gerar a pgina inteira, novamente. Seria muito melhor se pudssemos s atualizar as clulas relevantes na planilha. a que o modelo assncrono entra no jogo, preenchendo os espaos vazios (buracos) na interao e permitindo que o usurio continue interagindo com a aplicao, enquanto aes anteriores so manipuladas pelo servidor. Este modelo mostrado na Figura 1-3. O problema com a interao mostrada na Figura 1-3 a quebra do modelo clssico Web do pedido de pgina por HTTP pelo HTML, cuja simplicidade uma de suas maiores foras. O modo de fazer isso sem perder mais do que ganhamos com o Ajax engine, uma camada entre a interao do usurio e a comunicao com o servidor. Este engine roda dentro do navegador e delega aes ao servidor enquanto manipula os resultados. Pelo fato que o engine despacha chamadas para o servidor e disponibiliza resultados para o usurio, o usurio pode, nesse perodo, continuar interagindo com a aplicao. Em razo que o engine adere aos mesmos padres, o modelo Web permanence intacto. Para implementar esse modelo assncrono, precisamos de uma forma de enviar pedidos para o servidor de modo assncrono, sem fazer uma atualizao de pgina. Como j foi anteriormente mencionado, a Web, originalmente, foi criada para estabelecer conexes entre documentos e navegao entre eles. Portanto, nem a Web nem seus padres suportam, diretamente, operaes do tipo Ajax. Entretanto, desenvolvedores so 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 assncronos dos navegadores, s que no em uma forma de navegaao independente. O Microsoft Internet Explorer vem com um controle Active embutido (XmlHttpRequest), que poderia ser usado para fazer uma chamada assncrona. Mozilla/Firefox contm mecanismos prprios similares, tambm chamados, convenientemente, de XmlHttpRequest, somente implementados como um objeto nativo. Ambos os mecanismos so similares na forma que voc os usa. Isto possibilitou que os desenvolvedores usassem o modelo assncrono em aplicaes 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 assncronas ao servidor, h outras formas. Dois exemplos de outros mecanismos remotos: esto usando um iframe escondido e adicionando dinamicamente uma tag script no cabealho do documento.

Resposta

Pedido

Pedido

C A P T U L O 1 A P R e s e n TA n d O A s A P L I C A e s d e I n T e R n e T R I C A ( R I A s )

Navegador
Usurio Interao

Atualizao

Atualizao

Atualizao

Ajax Engine

Processamento no Cliente

Atualizao

Resposta

Resposta

Ao

Ao

Processamento no Cliente

Pedido

Pedido

Rede

Servidor
Processamento no Lado Servidor Processamento no Lado Servidor Processamento no Lado Servidor

Evento Externo

Tempo
Figura 1-3. O modelo de uma aplicao Ajax de interao.

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 contrrio, a linguagem bem diferente da linguagem de programao Java, ainda que elas compartilhem, como ancestral comum, a sintaxe do C. O JavaScript foi, provavelmente, nomeado a partir do Java por razes mercadolgicas como parte da aliana estratgica 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 programao 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 comeou a desenvolver seu prprio dialeto denominado JScript, porm, mais tarde, passou a dar suporte ao JavaScript. Em 1966, JavaScript se submeteu a padronizao, resultando nas especificaes ECMAScript com o JavaScript como uma das implementaes, os outros sendo o ActionScript (muito usado pelo Adobe) e JScript, que ainda usado para o Active Scripting da Microsoft. O JavaScript uma linguagem dinmica, francamente tipada, baseada em prottipos com funes de primeira classe. Suporta a sintaxe da programao C estruturada, inclusive comandos de lao (loops), comandos de switch e assim por diante. Uma exceo que ele no suporta escopo em nvel de bloco. Para ter uma ideia melhor do JavaScript, vamos dar uma olhada na Listagem 1-1, que mostra uma pgina HTML simples que usa o JavaScript para mostrar ao usurio um alerta com um valor que o usurio forneceu em um campo de entrada. Listagem 1-1. Exemplo de um JavaScript Embutido em uma Pgina 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

C A P T U L O 1 A P R e s e n TA n d O A s A P L I C A 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 fcil entender o que o cdigo est tentando alcanar. No entanto, voc deveria, tambm, notar as diferenas sutis, como as variveis e declarao de funes. Felizmente, como ver pelo resto deste captulo, voc no precisar saber mais sobre o JavaScript se quiser desenvolver RIAs usando GWT. Caso queira saber mais sobre o JavaScript, tente o JavaScript 1.5 Users 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 marcao a que emprega tags com a descrio 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 informao na Listagem 1-2 est estruturada de forma hierrquica. O XML uma forma simplificada do Standard Generalized Markup Language (SGML). Ambos SGML e XML so linguagens de metamarcao, permitindo que voc defina sua prpria linguagem de marcao. Uma aplicao de SGML HTML, conforme mostrado na Figura 1-4. Listagem 1-3 mostra algum contedo textual de marcao usando HTML. Listagem 1-3. Exemplo de Contedo Contendo Marcao 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 marcao de informao ao contedo. Note que no HTML, voc no pode usar suas prprias tags. Portanto, mudando, por exemplo, a mudana 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 prprias tags. XML permite formas diferentes de descrever a estrutura de seu documento atravs de schemas. Existem diferentes linguagens schema para o XML, incluindo o Document Type Definition (DTD), que fornece um grupo limitado de funcionalidades e um XML Schema mais poderoso. Mas como estas descries de documentos so opcionais, podemos, facilmente, seguir sem elas. Ento, o contedo da Listagem 1-3 poderia ser expresso, usando XML, conforme est mostrado na Listagem 1-4.

C A P T U L O 1 A P R e s e n TA n d O A s A P L I C A e s d e I n T e R n e T R I C A ( R I A s )

Listagem 1-4. Contedo Contendo Marcaes 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 semntica do texto. Conforme seu nome soletrado, XML tambm uma linguagem de marcao. Mas diferente do HMTL, que usa a marcao para propsitos nicos bem-definidos, XML tambm uma linguagem para a definio de linguagens de marcao. Ela agrega valor semntica do texto ao descrever o contedo das tags. Ainda assim, poderamos escrever um interpretador que usa a informao semntica descrita pelas tags e us-la para formatar a informao para o usurio. Mesmo que parea isso, HTML no uma extenso do XML. Isso porque, ao contrrio 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 no no XML; no XML, cada abertura de tag dever ter uma tag de fechamento correspondente ou ento deveria ser uma tag vazia: deveria ser <br></ br> ou <br/>. Para que o HTML seja mais facilmente validado e acessvel 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 fcil validao e interpretao. A Figura 1-4 d uma ideia geral de todas as linguagens de marcao 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 graas a padres estabelecidos. Um destes padres 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 contedo, a estrutura e o estilo de documentos (por exemplo, documentos XML e HTML). O DOM representa um documento como uma rvore hierrquica de ns 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 tambm a UI. Se olharmos l atrs, na Listagem 1-1, podemos ver o quanto usamos DOM para acessar o campo de entrada e recuperar o seu valor. Usamos o mtodo getElementById(String) do JavaScript na representao do DOM, da pgina do HMTL.

SGML

HTML

XML

XHTML

Figura 1-4. SGML e uma seleo de suas sub-linguagens. Conforme mencionado anteriormente, o XML permite a transferncia de dados em um tipo de intercmbio. Isto exatamente o que usado pelas aplicaes Ajax. Permite voc transferir dados do cliente para o servidor e vice-versa. Isto torna fcil 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 programao possvel. Portanto, XML se apresentava como um formato de transferncia de dados ideal, quando o Ajax foi criado. No entanto, como veremos na seo seguinte, isso se mostrou incorreto.

C A P T U L O 1 A P R e s e n TA n d O A s A P L I C A 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 acrnimo AJAX. No entanto, em 2006, Garrett redefiniu o AJAX como Ajax (um nome simples, que no significa nada em particular). Por que ele fez essa mudana e por que importante discutir isso aqui? Primeiro, vamos olhar porque ele fez a mudana. Depois de muitos anos desenvolvendo aplicaes baseadas neste novo paradigma, dois de trs componentes se expandiram, alm 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 trs de todo o movimento. Mas os outros dois, JavaScript e XML, estavam se expandindo lentamente. Como veremos na prxima seo, 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 tambm tem suporte para outras linguagens script. Ento, a parte JavaScript do acrnimo AJAX no era mais vlida. Mas, ainda mais bvio, era a necessidade da mudana da parte XML do acrnimo. Acontece que o XML deixou de ser a melhor opo 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 contedo e coloc-lo, diretamente, dentro da pgina, mas isto se torna inconveniente quando se est movendo dados normais. Isto mais devido ao fato que os navegadores tm a tendncia 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 incio, os desenvolvedores comearam a procurar por alternativas. Eles basicamente acharam trs alternativas ao XML: Um protocolo proprietrio tanto um protocolo textual ou cdigo binrio que permitisse a comunicao de dados entre o cliente e o servidor. A vantagem de ter um protocolo proprietrio 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 implementao do servidor usando Java. Para mais informaes, acesse: http://www.json.org. JavaScript Puro ao invs de usar um protocolo especfico, voc poderia usar o JavaScript puro na rede. Ainda que esta seja a mais poderosa e flexvel opo (porque voc pode usar todas as caractersticas e a sintaxe fornecida pela linguagem), ela requer que o servidor gere JavaScript. Como a parte servidor geralmente escrita em uma linguagem que no JavaScript, esta opo no recomendada. melhor usar algum tipo de formato de interface de troca, como o JSON. Cada soluo tem suas vantagens e desvantagens, mas, se olharmos a maioria das aplicaes Ajax, hoje, devemos concluir que o XML no mais o formato de transferncia de dados mais frequentemente usado. Ento, Garrett redefiniu Ajax como um nome e no mais como um acrnimo. Ele definiu Ajax como uma aplicao desenvolvida para a Web, usando DHTML (ver barra lateral) e fazendo um tipo de comunicao de maneira assncrona com o servidor. Essa o tipo de aplicao que voc aprender a desenvolver, neste livro.

HtmL DiNmiCO (DHtmL)

O termo DHTML descreve o uso de vrias das tecnologias j vistas, para a criao, de web sites interativos e animados. O DHTML combina a linguagem esttica do tipo marcao (como o HTML), com uma linguagem tipo script (como o JavaScript) no lado cliente, uma linguagem de apresentao (como a CSS) e o DOM. A combinao dessas tecnologias permite que voc, dinamicamente, mude a aparncia e o comportamento de uma pgina web. Mais recentemente, o DHTML est sendo tambm 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 criao de RIAs, vamos, primeiro, ver as vantagens e desvantagens, em comparao s aplicaes clssicas da web. Nos captulos anteriores, j tocamos em alguns desses pontos.

Benefcios Trazidos pelo RIA

Alm do bvio, benefcios intrnsecos ao se criar uma aplicao rica para a Internet, temos, tambm, a lista a seguir de benefcios adicionais: No necessita de instalao a aplicao baixada automaticamente e roda dentro do navegador. O software que verdadeiramente roda a aplicao j est instalado na mquina do cliente. As atualizaes so automticas novas verses da aplicao so baixadas automaticamente, toda vez que se visita a pgina da aplicao na rede.

C A P T U L O 1 A P R e s e n TA n d O A s A P L I C A e s d e I n T e R n e T R I C A ( R I A s )

Independe de Plataforma uma aplicao rica na Internet pode, potencialmente, rodar em qualquer plataforma e sistema operacional, contanto que tenha um navegador e uma conexo Internet. Maior segurana as aplicaes rodam em um ambiente restrito de um navegador web e so, portanto, menos sujeitas a causar danos do que aplicaes que precisam ser instaladas. Melhor resposta pois nem todas as aes do usurio requerem comunicao como o servidor, aplicaes ricas na Internet tendem a reagir mais rpido que as clssicas aplicaes da Internet. Mais evolutiva uma grande parte do trabalho computacional, bem como a manuteno do estado do processo, pode ser descarregado ao cliente, de forma que o servidor possa tratar de muito mais usurios. E sem precisar manter estados ou pelo menos no tantos. Maior eficincia na rede em clssicas aplicaes da Internet, toda ao de usurio necessita que o servidor gere, novamente, a pgina completa e mande-a atravs de rede. No caso da aplicao de Internet rica, toda UI da aplicao 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 criao de aplicaes de Internet ricas. A seguir algumas das limitaes: Necessita do JavaScript ou plug-in especfico porque a aplicao completa roda atravs do interpretador JavaScript no cliente, o que sucede quando o cliente desliga, completamente, o JavaScript? Normalmente, a aplicao faz pouca coisa ou no faz nada. Ter um plano de backup para esses usurios uma coisa bvia, mas a ento voc ter de manter duas aplicaes separadas, o que est longe do ideal. No tem acesso a recursos do sistema como as aplicaes rodam dentro de um navegador, elas esto limitadas quanto aos recursos que elas podem acessar. Por exemplo, uma aplicao Ajax no pode acessar o sistema de arquivos do cliente. Difcil para os engines de pesquisa atingir indexao plena devido ao que a maioria dos engines de consulta no (ainda no) suportam aplicaes que fazem atualizaes parciais de pginas ou usam plug-ins especficos, como o Flash, a maioria das aplicaes de Internet ricas so, pobremente, indexadas por engines de busca. Os maiores engines de busca planejam melhorar o suporte para este tipo de aplicaes, medida que a sua popularidade aumenta, mas sempre ser difcil index-las o suficiente. Problemas de Acessibilidade atualizaes parciais de pginas usando JavaScript ou um plug-in especfico podem quebrar a acessibilidade. O maior e mais conhecido problema que as leitoras de telas existentes no manejam isso corretamente. Ainda que as leitoras de telas tentem a fornecer um suporte melhor, desenvolvedores de aplicaes deveriam sempre ter, em mente, quando forem desenvolver aplicaes e ainda mais quando forem do tipo rica na Internet, porque acessibilidade fcil de ser rompida. Dependncia de conexo Internet - porque essas aplicaes so servidas pela Web e rodam em um navegador, elas necessitam, pelo menos, uma conexo inicial com a Internet. Mas, mesmo durante o uso, uma comunicao com a Internet necessria para se comunicar com o servidor. Quando a conexo (temporariamente) no est disponvel, a maioria das aplicaes rica na Internet falham, no funcionam. Entretanto, h tentativas para se usar os services locais fornecidos pelo navegador para um armazenamento temporrio enquanto uma conexo no se encontra disponvel.

Quando Que Voc Deve Usar o Ajax?

Baseado nos benefcios e inconvenientes mostrados na seo anterior, estamos fortemente inclinados a acreditar que as aplicaes de Internet rica no so para todas as aplicaes. Mas h orientaes que indicam quando construir uma aplicao de Internet rica e quando se manter no desenvolvimento do tipo aplicao web clssico o que voc vem fazendo j h algum tempo. Considere a lista a seguir: Voc quer desenvolver uma aplicao que os usurios necessitam usar diariamente e gastam bastante tempo usando-a. Tarefas de negcios que contam com uma resposta direta da aplicao para melhoria da produtividade. A maioria seno todas as aplicaes, necessitam autenticao e autorizao do usurio, ento nestes casos a indexao pelos engines de busca no uma alta prioridade. certo assumir que o JavaScript j esteja disponvel ou aceitvel solicitar aos usurios que o acionem antes de usar a aplicao. Achamos que se a sua aplicao segue estes pr-requisitos, a preferncia deveria ser dada a uma aplicao de Internet rica. Assumindo que voc tem uma aplicao em mente (pelo menos na mente), olhemos as diferentes abordagens que esto disponveis para o desenvolvimento dessas aplicaes.

10

C A P T U L O 1 A P R e s e n TA n d O A s A P L I C A 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 Construo de RIAs

Para construir estas aplicaes da Internet rica, precisamos de uma maneira fcil de desenvolver o cdigo que roda nos navegadores e um modo de se chamar o servidor remotamente. Vamos olhar ligeiramente as diferentes abordagens disponveis. Note que isto no foi destinado a ser uma exaustiva listagem de todas as solues e frameworks, mas s um destaque das diferentes abordagens.

Escrever JavaScript Manualmente

A primeira, e mais largamente, usada forma de desenvolver aplicaes Ajax pegando uma aplicao web normal e adicionar funcionalidades do Ajax atravs de codificao em JavaScript. Voc, normalmente, usaria bibliotecas pr-existentes que permitiriam voc manter o foco em coisas realmente importantes enquanto usasse caractersticas j conhecidas, como uso remoto e classes de convenincia para manipulao da interface. Geralmente, h quatro preocupaes no que tange essa abordagem: JavaScript no Java usando JavaScript para desenvolver aplicaes totalmente diferente que desenvolver aplicaes em Java. No so s duas linguagens distintas, com seus conceitos e contruo prprios, mas tambm requerem um conjunto diferente de ferramentas. Mesmo que seja prazeroso para os desenvolvedores aprender uma nova linguagem, essa, talvez, no seja a melhor escolha partindo de uma perspectiva de negcios. A soluo bvia seria contratar desenvolvedores de JavaScript profissionais; s que bons desenvolvedores de JavaScript realmente experientes so difceis de achar. Browser quirks o maior desafio e provavelmente a atividade que mais consome tempo no desenvolvimento de aplicaes Ajax a codificaao que manipule todas as diferenas entre os navegadores e at mesmo entre verses diferentes do mesmo navegador. Um bom desenvolvedor de JavaScript deveria saber todos essas estravagncias de cor. Bibliotecas demais assumindo que voc no quer reinventar a roda, voc sa a procura de bibliotecas que lhe d as caractersticas bsicas que necessita. Mas onde comear 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 propsito mltiplo e 51 frameworks Java Ajax, que d um total de 93 frameworks para a criao de sua aplicao. Bibliotecas resolvem s parte do Quebra-cabea escolher uma biblioteca, geralmente, no suficiente, normalmente, elas resolvem parte do quebra-cabea quando s um aspecto da criao de aplicaes Ajax. Uma pode conter funcionalidades bsicas para aes remotas, enquanto outra fornece widgets, e uma terceira trata dos efeitos visuais. Ento voc acaba com um nmero de frameworks diferentes que voc tem de amarrar, formando uma s aplicao. Esta abordagem vivel quando se limita a adio de funcionalidades Ajax a uma aplicao web tradicional. Mas levando em conta esses cuidados, no sugerimos que use esta abordagem para desenvolver aplicaes de Internet rica como as que foram discutidas anteriormente.

Flex
Adobe Flex um conjunto de ferramentas para o desenvolvimento de aplicaes de Internet rica, na plataforma proprietria 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 aplicaes ricas em Flash desafiante e intuitivo para desenvolvedores de ncleo. A ferramenta de desenvolvimento do Flash est preparada para designers, desenvolvendo em um timeline um estranho conceito para aplicaes que no so movidas pelo tempo mas por aes de seus usurios. Flex remove aquela barreira de entrada, fornecendo uma forma programtica de desenvolver RIAs. Ainda que a plataforma Flex, originalmente, tenha sido desenvolvida, pela Macromedia, em 2004, como um produto comercial, Adobe abriu partes do cdigo fonte, em 2007, depois de ter adquirido a Macromedia. Quando desenvolver aplicaes 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, grficos vetoriais e animaes. 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 aplicaes para rodar dentro do ambiente controlado pelo plug-in do Flash. E, por isso, voc no 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 no ser verdadeiro em alguns ambientes bloqueados, como escolas e agncias governamentais. Alguns puristas tambm sentem que o Flex no um verdadeiro framework de aplicao Ajax, porque ele no aderiu aos padres usados normalmente para criar aplicaes Ajax, como o XHTML e JavaScript. Em fevereiro de 2008, Adobe liberou o runtime Adobe AIR, que permite que aplicaes desenvolvidas em Flex sejam implementadas como aplicaes desktop locais, enquanto ainda gozavam dos benefcios do Ajax, como instalao e atualizao contnua. O principal benefcio do AIR que ele d aos desenvolvedores de aplicaes o melhor de dois mundos: voc pode usar o modelo de implantao da aplicao web enquanto ainda consegue, se precisar, integrao 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 A P T U L O 1 A P R e s e n TA n d O A s A P L I C A 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 lanamento do Adobe AIR, uma boa opo para o desenvolvimento de aplicaes de Internet rica. Especialmente quando voc no consegue ficar sem caractersticas de integrao do desktop, como notificao ao usurio, integrao na inicializao, processamento em segundo plano e (a mais importante) acesso ao sistema, de arquivos local. Flex uma grande opo. No entanto, lembrem-se que mesmo sendo, na sua maior parte, um cdigo-fonte aberto, ele ainda necessita que os usurios instalem seus plug-ins proprietrios antes de usar suas aplicaes desenvolvidas em Flex. Mais informaes 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 criao de aplicaes de Internet rica usar applets Java ou mais recentemente JavaFX. A parte mais interessante do JavaFX, para nossos propsitos, o JavaFX Script, uma linguagem script para a fcil criao de mdia rica e contedo interativo. No entanto, est embutida na plataforma de desenvolvimento Java, ento se voc quiser implantar aplicaes JavaFX na Web, voc est, na realidade, implantando um applet Java, porm desenvolvido com JavaFX. Portanto, vamos discutir applets nesta seo e s destacar que ele tambm cobre aplicaes escritas em JavaFX. O principal benefcio de um applet Java um programa em Java que roda no lado cliente. Ainda que haja algumas restries de seguranas 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 restries de segurana atravs de uma assinatura digital e solicitando ao usurio permisses adicionais, como acesso ao sistema de arquivos local. Portanto, se voc quer criar uma aplicao de Internet rica, esta parece ser a soluo ideal. Mais informaes 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 preocupao que, dependendo dos requisitos e do tempo de desenvolvimento, voc talvez precise de uma verso diferente do JRE. Indo adiante, ao contrrio do Flash Player, o JRE ocupa um espao de download substancial de 14Mb para instalao offline na plataforma Windows, no momento da gravao. Tabela 1-1 fornece uma viso geral da penetrao no Mercado e tamanho de downloads dos pacotes discutidos nesta seo. Mais informaes 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 aplicaes de Internet ricas. Mesmo que o Silverlight esteja comeando a chamar a ateno, ele ainda tem um longo caminho pela frente at que se possa considerar como uma alternativa sria ao Flash. Neste momento, a maior barreira ao Silverlight expandir a sua base instalada. At agora, sua penetrao no Mercado quase nula. Mas como o Adobe, que levou muitos anos para que suas aes atingissem o corrente valor no mercado, bem provvel que leve bastante tempo antes que o Silverlight possa comear a desafiar o Flash. Outro problema que surge quando se desenvolve aplicaes de Internet ricas com o Silverlight, que os executveis s esto disponveis para plataforma a Windows. No se pode prever, para um futuro prximo, nenhum usurio Mac ou Linux usando aplicaes desenvolvidas com Silverlight. Tambm, o tamanho do download do Silverlight maior do que o do Flash. Por estas razes, no consideramos que o Silverlight seja uma opo sria para o desenvolvimento de aplicaes de Internet ricas, at este momento pelo menos, e no at que adquira uma base instalada considervel e que a Microsoft libere runtimes para usurios Mac e Linux. Mais informaes e detalhes sobre o Silverlight, podem ser encontradas em http://www.silverlight.net. tabeLa 1-1. Penetrao de Mercado de Instalao das Solues e Tamanho do Download Product Flex/Flash Java/JavaFX Silverlight market Penetrao (arredondado) 99% 85% 0% Download size (in mb) 1.5 14 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 prpria linguagem de programao LZX. LZX, basicamente, o XML com trechos de cdigo JavaScript embutidos, descrevendo a lgica da aplicao. OpenLaszlo ento pega as definies do UI e gera uma aplicao de Internet rica. As verses anteriores somente permitiam que a aplicao fosse traduzida em uma aplicao Flash funcional e completa. Isso cria os mesmos problemas encontrados na abordagem do Flex. Mas comeando da verso 4 do OpenLaszlo, agora ele suporta a traduo da UI em uma aplicao DHTML. A ltima verso tambm suporta compilaes entre plataformas embutidas, como celulares e outros dispositivos.

12

C A P T U L O 1 A P R e s e n TA n d O A s A P L I C A 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 lgica das aplicaes seja escrita em JavaScript. Isso remete ao mesmos problemas discutidos na seo sobre JavaScript (cdigo adicional). Mas, OpenLaszlo reinvindica que eliminou um bom nmero de problemas de incompatibilidades entre os navegadores, porque o compilador, hoje, est ciente deles (veja Figura 1-5).
Flash Player (Qualquer Navegador)

SWF

Cdigo da Aplicao (em LZX)

Compilador OpenLazslo

DHTML

DHTML Navegador

Embutidos Runtimes

Mobile Phones

Figura 1-5. Cdigo de aplicao OpenLaszlo compilado para diferentes formatos de sada. Para mais informaes sobre o OpenLaszlo, veja http://www.openlaszlo.org.

Echo2
O Echo outra abordagem para o desenvolvimento de Aplicaes de Internet Rica. A verso estvel, no momento, que estamos a Echo2. Echo2 vem com uma boa abordagem para a construo destas aplicaes, ela permite que voc escreva-as em Java. No Echo2, voc escreve um servlet que cuida de todos os pedidos de usurios e cria uma aplicao nica para cada usurio. Uma aplicao criada extendendo a classe ApplicationInstance. Esta instncia da aplicao determina a UI da aplicao e cuida dos eventos do usurio. Porque uma nova instncia da aplicao criada para cada usurio, tambm ela guarda todos os estados. Internamente, a instncia da aplicao est armazenada na seo do usurio. O framework Echo parte para uma abordagem revolucionria para desenvolver Aplicaes de Internet Rica. Mas, na nossa opinio, h principalmente dois problemas com o Echo2: (Quase) toda ao do usurio resulta em um acesso ao servidor por causa da forma que o Echo2 trabalha internamente, mantendo o estado servidor na seo do usurio, toda ao que o usurio realize precisa ser comunicada ao servidor. Na nossa opinio, uma aplicao de internet rica deveria se comunicar com o servidor somente quando necessrio. Em outras palavras, a aplicao deveria rodar s no navegador e somente se comunicar com o servidor quando tivesse que recuperar dados ou realizar uma ao no lado servidor ou ambos. Mantm todos os estados no servidor por natureza, uma Aplicaes de Internet Rica mantm a maioria, se no todos, os estados no cliente. Isso torna possvel offload do servidor e uma melhor escalabilidade. Uma coisa que aprendemos, no passar dos anos, desenvolvendo aplicaes Java que manejam grande nmero de usurios, que voc deveria manter o mnimo possvel de estados no servidor. Construindo aplicaes ricas no lado cliente torna em grande parte isso possvel, mas sentimos que o Echo2 dificulta isso quando mantm a maioria dos estados no servidor. Mais detalhes e informaes, podem ser encontradas em http://echo.nextapp.com/site/echo2.

GWT
Como o GWT o assunto deste livro e ser apresentado com detalhes no prximo captulo, no nos aprofundaremos aqui. Mas olhando o GWT em contraste com as solues 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 aplicao que voc desenvolve no GWT eventualmente ser compilada em uma aplicao DHTML e vai rodar integralmente no navegador usando XHMTL e JavaScript. Porm, a principal vantagem que o GWT tem sobre, por exemplo, o OpenLaszlo que, ao invs de definir sua UI em XML e JavaScript, as aplicaes so desenvolvidas em Java. Ento, para os desenvolvedores Java, isto naturalmente cai com naturalidade. Voc pode usar novamente sua experincia e conhecimento tcnico, IDE favorita e ferramentas de desenvolvimento. O benefcio de usar GWT sobre as outras ferramentas, como Echo2 que o cdigo GWT compila completamente a parte cliente da aplicao JavaScript e no faz s uma proxy para aplicao Java no servidor. O concorrente mais srio do GWT o Flex. Mas, na nossa opinio, GWT possue duas vantagens: Primeiro um cdigo-fonte totalmente aberto, ao passo que o Flex um cdigo-fonte parcialmente aberto e, segundo, uma aplicao GWT compilada roda em qualquer navegador moderno (assumindo que o JavaScript esteja rodando) enquanto que a aplicao Flex s roda nos sistemas onde o Flash player est instalado.

C A P T U L O 1 A P R e s e n TA n d O A s A P L I C A e s d e I n T e R n e T R I C A ( R I A s )

13

Resumo
Neste captulo, apresentamos o conceito de uma Aplicao de Internet Rica (RIA) e mostramos de onde ele surgiu, dando algum background histrico. Fomos das aplicaes em Mainframe, com as terrveis experincias de seus usurios e sua limitada relao custo/benefcio at a aplicao de internet rica que so superiores em ambos os aspectos. A seguir, introduzimos Ajax, discutindo cada letra do acrnimo original e mostrando porque no mais um acrnimo. Mais importante ainda, discutimos as vantagens e desvantagens do uso do Ajax, para o desenvolvimento de RIAs, e apresentamos algumas orientaes, mostrando quais aplicaes se prestam melhor para o Ajax. Por fim, demos nossa contribuio em diversas abordagens para a criao de aplicaes Ajax, apresentando algumas estratgias diferentes, juntas com sua foras e fraquezas. Isso revelou porque acreditamos que o GWT seja a melhor soluo disponvel atualmente para desenvolvimento de de RIAs, e porque o resto do livro trata do GWT e no uma das outras tecnologias. No prximo captulo, vamos apresentar o GWT com mais detalhes, mostrando um layout de uma tpica aplicao GWT. Apresentaremos, tambm, um exerccio com uma aplicao que construiremos, gradativamente, no curso deste livro.