: : www.mundoj.com.br : :
O Comet é uma das formas de desenvolvimento do AJAX Reverso, tecnologia na qual o cliente Web não precisa realizar as tradicionais requisições para que o servidor responda a informações atualizadas. Este fator promove uma aproximação ao modelo ideal de transações de informações em que todos os clientes envolvidos em uma mesma aplicação podem manter-se atualizados desde a primeira modificação de conteúdo. Este artigo descreve a utilização da tecnologia Comet, implementada pelo framework DWR, aplicada em um software de leilão virtual como exemplo.
Comet com DWR
AJAX Reverso
baseado em
Aprenda a trabalhar com o AJAX Reverso, técnica ainda pouco explorada
que proporciona aos sistemas Web a funcionalidade de atualizar os clientes
conforme o servidor tem seu estado modificado.
om a evolução da internet, as aplicações Web tornaram-se comuns no cotidiano. Hoje, muitas das aplicações Desktop são portadas para a Web devido a sua praticida-de e facilidapraticida-de praticida-de utilização, já que dispensa a instalação e granpraticida-de parte da configuração. Dentre as várias tecnologias utilizadas para portar as aplicações para Web, o AJAX já tem seu espaço garan-tido.
O AJAX possibilita que sejam carregados apenas os componentes solicitados pelo usuário, e não a página completa como no méto-do tradicional de requisição e resposta. Com isso, o usuário ganha em desempenho, interatividade e menor sobrecarga no servidor. No AJAX Reverso, o servidor fica responsável em atualizar o clien-te (usuário), já que o usuário não precisa fazer nenhum tipo de requisição para que o servidor envie uma resposta.
Este artigo tem como objetivo demonstrar a criação de um leilão virtual, onde cada usuário dará um lance e será mostrado apenas o maior. Será desenvolvido com tecnologia JavaServer Faces, além da utilização do Framework DWR para implementar a função do AJAX Reverso. Quando o maior lance for enviado, o servidor é responsável em atualizar todos os usuários, sem que eles façam uma requisição para isso. Para melhor entendimento do artigo, sugere-se conhecimentos na arquitetura cliente/servidor utilizada na Internet, assim como da tecnologia AJAX, porém todos os con-ceitos são revisados.
O presente artigo está organizado da seguinte forma: primeira-mente, será explicado sobre o AJAX e como ele mudou o modelo tradicional da Web (requisições/respostas). Em seguida, será contextualizado o AJAX Reverso e, principalmente, o Comet junto com os frameworks que possibilitam sua implementação. Ao final, será apresentado um exemplo de como implementar o Comet com o framework DWR e um exemplo com JSF.
Estado de São Paulo. Possui certificação SCJP, é docente na Universidade do Estado de Minas Gerais (UEMG) e na FATEC de São José do Rio Preto. Junto com outros colaboradores mantém o site http://www.patternizando.com.br, para a discussão de desenvolvimento de software.
desenvolvedor pela Net-Fit e também é colaborador do http://www.patternizando.com.br.
AJAX
A tecnologia AJAX (Asynchronous Javascript And XML) é uma das maiores aliadas na aproximação entre o ambiente Web e o Desktop. O conceito de AJAX foi criado por Jesse James Garrett em um artigo on-line publicado em fevereiro de 2005. Com o AJAX, é possível que o navegador carregue conteúdo do servidor sem recarregar a página completamente. Apenas os componentes requisitados pelo cliente são carregados, evitando um grande uso de tráfego de dados e melhorando o desempenho das aplicações e tornando-as mais rápidas e próximas das aplicações Desktop. Além disso, este permite que várias requisições sejam feitas simul-taneamente, trabalhando em cada parte da página, propiciando ao usuário maior agilidade e facilidade na utilização do sistema aderindo melhor aos requisitos de usabilidade. O AJAX consiste em requisições assíncronas manipuladas no cliente por meio de JavaScript, nas quais o mesmo provê o tratamento da requisição ao servidor e reposta de forma a ajustar o conteúdo recebido sem a necessidade de uma total atualização da página. Assim, o AJAX faz com que as interfaces das aplicações Web se tornem semelhan-tes às das aplicações Desktop.
O AJAX tem como objetivo maximizar a interação entre os usu-ários e as aplicações Web, tornando-as mais simplificadas e com ganho em desempenho. Com isso, uma das maiores vantagens das aplicações Web que utilizam o AJAX é que todas as requisições e respostas são tratadas por JavaScript, que é responsável por atuali-zar partes específicas da página a partir da resposta e, para utilizá-lo, é necessário apenas possuir um dos navegadores atuais já que oferecem suporte a essa tecnologia, como, por exemplo, Mozilla Firefox, Internet Explorer, Google Chrome, Opera ou Safari.
Figura 1. Modelo tradicional síncrono para Internet.
Figura 2. Modelo baseado em AJAX.
Figura 3. Modelo baseado em Comet.
A comparação entre as figuras 1 (Modelo tradicional) e 2 (Modelo baseado em AJAX) apresenta claramente a diferença entre uma conexão feita com as requisições tradicionais (sempre precisando de uma requisição para que o servidor possa responder) e uma conexão feita com AJAX (o servidor pode enviar a resposta de forma assíncrona). Na figura 3, é apresentado um modelo no qual o cliente não requisita atualização, porém, conforme demanda (evento) do servidor é realizada uma transferência de informação. Outro detalhe a ser observado na figura 3 é que a ligação entre cliente e servidor é mantida pelo Comet, sendo transparente ao cliente o uso do mesmo.
Com o Comet, aplicações que atualizam dados continuamente como salas de bate-papo Web, por exemplo, podem se beneficiar de menor carga nos servidores.
: : www.mundoj.com.br : :
“CLICK” para disparar uma requisição que será contemplada com uma resposta atualizada do servidor. O exemplo de uma sala de bate-papo, para o caso do modelo sem AJAX exigiria um evento do cliente, tal qual um click de botão ou a solução tradicional dos refreshs (atualizações) periódicas de todo o seu conteúdo. Já para o caso da figura 2 uma área específica poderia ser atualizada com as técnicas comentadas na figura 1, no entanto a exigência de um evento seria mantida.
AJAX Reverso
Comet
Diferenciando-se um pouco do AJAX comum, com o AJAX Re-verso o servidor é capaz de enviar informações ao cliente sem que o mesmo tenha feito uma requisição. É realizada uma conexão diferenciada com o servidor, permitindo-o enviar respostas aos clientes sem que estes tenham que fazer novas requisições. Esse tipo de comunicação cliente-servidor pode ajudar muito os sis-temas Web a ficarem mais dinâmicos e com maior usabilidade, além de garantir que a informação seja mostrada ao cliente em tempo real.
Há três maneiras de implementar o AJAX Reverso, são elas: Polling, Piggyback e Comet.
t 1PMMJOH consiste em o cliente, em intervalos de tempo fre-quentes e regulares, perguntar ao servidor se há alguma nova atualização. Mesmo não havendo nenhuma informação ao cliente, gera tráfego e processamento desnecessários no ser-vidor. Isso apenas simula a técnica do AJAX Reverso, já que mesmo que feito de forma pré-programada, o cliente faz re-quisições constantes ao servidor.
t 1JHHZCBDL um pouco mais interessante que o Polling, pois quando o servidor, por exemplo, tiver que enviar ao cliente uma mensagem, ele espera o cliente fazer uma nova requisição e, junto com a resposta, envia a nova mensagem, gerando me-nos tráfego que o Polling. Essa técnica não é adequada quando o usuário precisa da informação com urgência, pois o servidor aguarda uma nova requisição para enviar as informações junto com a resposta.
t $PNFU abre uma conexão com o servidor e a deixa aberta para que o mesmo possa enviar as informações quando neces-sário. O Comet será mais bem abordado no próximo tópico. Os frameworks que suportam o AJAX Reverso, em sua maioria, dão a possibilidade de trabalhar utilizando as três técnicas indivi-dualmente ou até mesmo simultaneamente.
Comet é uma das maneiras de implementar o AJAX Reverso ge-rando menor tráfego e processamento já que o cliente vai receber a mensagem apenas quando ela estiver disponível.
Em outras palavras, sem o Comet, o cliente teria que fazer as re-quisições a cada período fixo de tempo. Se forem curtos, o servi-dor pode sobrecarregar e, se forem longos, as atualizações podem estar atrasadas, já que o cliente não vai ter acesso à informação assim que disponível. Basicamente, o Comet pode ser dividido em duas formas:
t -POH 1PMMJOH utiliza conexões HTTP de longa duração e quando a informação estiver disponível será enviada, fechan-do a conexão com o servifechan-dor. O cliente receberá a informação
e abrirá uma nova conexão para aguardar o próximo envio do servidor. O grande problema é que pode gerar excesso de processamento nas aberturas e fechamentos das conexões. t 4USFBNJOH o navegador abre uma conexão com o servidor e
é mantida aberta mesmo após o envio de cada informação. A vantagem é que o servidor consome muito pouco recurso para que essa conexão fique aberta, mas caso haja uma queda na conexão, poderá haver algum atraso nas informações, pois o servidor terá que abrir uma nova conexão.
Em ambas as formas do Comet, o servidor é capaz de enviar novas informações ao cliente assim que disponível, gerando menos tráfego e processamento desnecessário. No entanto, quando o tipo de con-teúdo disponibilizado pelo servidor não requer o broadcast da in-formação, ou seja, não precisa de sincronização de todos os clientes em tempo real, o custo de manter ativas as ligações com o servidor podem comprometer o desempenho do mesmo. O desempenho do servidor é comprometido uma vez que a ligação com cada cliente é mantida por uma thread ativa, ou seja, a troca de informações com o cliente aloca recursos de processamento e sincronização que pode comprometer a escalabilidade da aplicação.
Para Saber Mais
A edição 14 da MundoJ traz o artigo “AJAX – Desenvolvendo uma Web mais interativa”. No qual se apresenta conceitos desta tecnologia, como também usos e vantagens. A edição 22 da MundoJ também trouxe diversos artigos que exploraram diferentes questões sobre o assunto, como desempenho e segurança. Na edição 31, o artigo “Grizzly e Comet – AJAX Reverso com Escalabilidade” demonstra a criação de uma aplicação utilizando o AJAX Reverso.
Frameworks que implementam o Comet
Para implementação do AJAX Reverso, existem alguns frameworks que permitem essa funcionalidade. Segue uma pequena descrição de alguns deles:
t %83 %JSFDU8FC3FNPUJOH é um framework Open Sour-ce desenvolvido em Java e Javascript com o objetivo de facili-tar o acesso a uma classe Java que utiliza o AJAX. Com ele, a comunicação via AJAX de uma classe Java é feita de maneira simples, pois é possível executar os métodos destas classes dentro do próprio Javascript utilizando apenas uma linha de código. Isso facilita a chamada de Javascript para Java e vice-versa. O DWR é capaz de integrar-se a vários frameworks Java e Javascript, além de ser totalmente compatível com o AJAX Reverso. Ele também implementa o AJAX de forma cross-bro-wser (funciona em vários brocross-bro-wsers) e é o que será utilizado neste artigo por motivos de estabilidade, documentação ampla e integração com JSF de forma simples.
t "UNPTQIFSF o Atmosphere é Open Source e baseado no fra-mework POJO utilizando Inversão de Controle (IoC) com o objetivo de simplificar a criação de aplicações em Comet para
Implementação do projeto com DWR (Direct
Web Remoting)
Configuração do DWR
servidores Java Web-Based que suportem a especificação Ser-vlet 2.3, como, por exemplo, Tomcat, Jetty, GlassFish, Weblo-gic, Grizzly, JBossWeb e JBoss, Resin etc.
t ;, é um framework Open Source que permite que sejam desenvolvidas aplicações com interfaces ricas para a Web, re-duzindo o tempo que seria gasto já que é necessária pouca programação. O ZK conta com uma equipe bastante prestativa para ajudar os usuários que têm dúvidas e uma de suas maio-res características é a simplicidade. Além de ser totalmente compatível com o AJAX Reverso, o ZK tem facilidade na in-tegração com outros frameworks e tem uma documentação muito bem detalhada.
Para demonstrar o uso do DWR em um projeto, foi desenvolvida uma aplicação-exemplo que consiste em um leilão virtual em que cada usuário cadastra o seu lance e automaticamente tem o valor replicado para todos os clientes presentes no mesmo evento.
Como dito anteriormente, o DWR é um framework Java que per-mite a interatividade entre navegador e servidor e suas respectivas requisições de forma simples. Para utilizá-lo em um projeto é necessário usar a biblioteca dwr.jar (neste artigo foi utilizada a versão 3 RC1). Outra biblioteca necessária é a Apache Commons, incorporada ao projeto através do arquivo commons-logging.jar, sendo que a versão utilizada foi a 1.1.1, última até a edição desta revista. Esta última biblioteca é pré-requisito para obter as infor-mações sobre o estado da aplicação em tempo de execução. Vale à pena ressaltar que alguns problemas já relacionados à versão 2.0 do DWR têm solução prevista na versão 3.0 que ainda está na situação de Release Candidate.
Todas as configurações do DWR, como padrão, são realizadas no arquivo dwr.xml que deve estar no diretório WEB-INF da aplicação Web. Este arquivo por padrão tem a seguinte estrutura apresentada na Listagem 1.
Listagem 2. Implementação dwr.xml utilizada no projeto. 3.0//EN” “http://directwebremoting.org/schema/dwr30.dtd”> <dwr> <allow> <filterclass=”...”/>
<createcreator=”...” javascript=”...”/> <convertconverter=”...” match=”...”/> </allow> <signatures> ... </signatures> </dwr> <?xml version=”1.0” encoding=”UTF-8”?>
<!DOCTYPE dwr PUBLIC “-//GetAhead Limited//DTD Direct Web Remoting 3.0//EN” “http://getahead.org/dwr//dwr30.dtd”>
<dwr> <allow>
<createcreator=”new” javascript=”LanceMB”> <paramname=”class” value=”LanceMB” /> </create>
</allow> </dwr>
Onde o arquivo dwr.xml tem as seguintes sessões:
- <allow> define quais classes serão utilizadas e quais são os filtros que estão ativos para o projeto atual;
- <create> a classe que tenha métodos baseados na implementa-ção AJAX do DWR precisará especificar seu criador e método Javascript;
- <convert> é a tag que especifica todos os parâmetros que po-dem ser convertidos. Uma vez que estamos falando de requisi-ções HTML, todo conteúdo trocado é baseado em texto, assim operações de conversão devem ser realizadas. Muitas conver-sões já são automáticas, como, por exemplo, tipos primitivos e suas classes wrapper, String, Date inclusive Collections. No entanto, existe a possibilidade de especificação de conversão, inclusive de novos tipos;
- <signatures> o dwr utiliza reflexão para implementar o pro-cesso de conversão. Quando a informação sobre a conversão
não está disponível, a compo-sição da assinatura auxilia no processo de conversão indi-cando quais são os tipos a se-rem convertidos baseados no tipo assinado.
Para o projeto desenvolvido para este artigo, o dwr.xml foi configu-rado conforme a Listagem 2.
: : www.mundoj.com.br : :
Configuração do aplicativo Web
Conforme definido o dwr.xml, é necessário configurar o Servlet do DWR. Para isso, basta acrescentar a codificação conforme a Listagem 3. Nesta listagem também é possível verificar que o
Listagem 3. Implementação web.xml com dwr.
Listagem 5. Importações necessárias para utilização do DWR.
<servlet>
<servlet-name>dwr-invoker</servlet-name>
<servlet-class>org.directwebremoting.servlet.DwrServlet</servlet-class>
<init-param>
<param-name>activeReverseAJAXEnabled</param-name> <param-value>true</param-value>
</init-param>
</servlet> <servlet-mapping>
<servlet-name>dwr-invoker</servlet-name> <url-pattern>/dwr/*</url-pattern> </servlet-mapping>
<listener>
<listener-class>org.directwebremoting.servlet.DwrListener </listener-class>
</listener>
<scripttype=”text/javascript” src=”#{facesContext.externalContext. requestContextPath}/dwr/interface/LanceMB.js”></script> <scripttype=”text/javascript” src=”#{facesContext.externalContext. requestContextPath}/dwr/engine.js”></script>
<scripttype=”text/javascript” src=”#{facesContext.externalContext. requestContextPath}/dwr/util.js”></script>
Um detalhe importante foi a necessidade da inserção da classe DwrListener. Sem a mesma, o projeto era renderizado, porém o servidor capturava algumas exceções do tipo NullPoin-terException em eventos assíncronos. Com a declaração do listener citado, a exceção foi solucionada.
Implementação do exemplo com
JSF – Página xhtml
A próxima etapa envolve a configu-ração das páginas que farão parte do mecanismo AJAX proposto. Como já comentado, o projeto proposto do lei-lão deverá manter atualizados todos os clientes a cada lance. O procedimento é: na tela principal o participante pre-enche o seu nome e realiza o lance, como na figura 4.
Figura 4. Cadastro de lance.
Para a implementação da página, foi utilizada a implementação 2.0 do JSF e seus componentes AJAX, porém a mesma não é pré-requisito para utilização do DWR.
Para Saber Mais
A edição 42 da MundoJ traz o artigo “Frameworks RIA para JSF lado a lado – Entrada de Dados”. Onde são descritas as diferenças não só nos componentes de entrada de dados como descrito no título, mas também a instalação dos frameworks utilizados neste artigo e sua compatibilidade de navegadores.
A codificação da página para entrada e exibição dos lances, con-forme mostrado na figura 4, está disponível na Listagem 4. Alguns pontos devem ser observados com relação ao código da Listagem 3, entre eles, o atributo onload que, ao capturar o evento de carregamento da página, executa a função fncOnLoad(). Esta é a função que define o comportamento de AJAX Reverso para as requisições desta página, ou seja, acrescenta o cliente na lista de atualizações por parte do servidor. Portanto, é imprescindível a associação do body ao método:
dwr.engine.setActiveReverseAJAX(true);
Outras implementações necessárias são as importações dos scripts engine.js e utils.js, que são utilizadas para encapsular a interface gerada dinamicamente e trazem também uma lista de funções para atualização das informações via Javascript. A última importação relevante ao uso do DWR é a da interface criada dinamicamente a partir da classe habilitada a manipular as requisições. Essa clas-se é gerada pelo DWR apenas virtualmente, estando disponível para o servidor enquanto a aplicação estiver ativa. Tal classe foi configurada no dwr.xml, conforme Listagem 2. As importações comentadas estão em destaque na Listagem 5.
Melhor Lance Dono do Lance Seu Lance Seu Nome:
---Listagem 6. Classe ManagedBean LanceMB.
<?xml version=’1.0’ encoding=’UTF-8’ ?>
<!DOCTYPE html PUBLIC “-//W3C//DTD XHTML 1.0 Transitional//EN” “http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd”>
<htmlxmlns=”http://www.w3.org/1999/xhtml” xmlns:h=”http://java.sun.com/jsf/html” xmlns:f=”http://java.sun.com/jsf/core”> <h:head>
<title>AJAX Reverso MundoJ</title>
<scripttype=”text/javascript” src=”#{facesContext.externalContext. requestContextPath}/dwr/interface/LanceMB.js”>
</script>
<scripttype=”text/javascript” src=”#{facesContext.externalContext. requestContextPath}/dwr/engine.js”>
</script>
<scripttype=”text/javascript” src=”#{facesContext.externalContext. requestContextPath}/dwr/util.js”>
</script>
<scripttype=”text/javascript”> function fncOnLoad() {
dwr.engine.setActiveReverseAJAX(true); }
function receberLance(melhorlance, donolance) { dwr.util.byId(“melhorlance”).innerHTML = melhorlance; dwr.util.byId(“donolance”).innerHTML = donolance; }
function darLance() {
var nome = dwr.util.getValue(“nome”); var valor = dwr.util.getValue(“valor”); LanceMB.enviarLance(nome, valor); }
</script> </h:head>
<h:bodyonload=”fncOnLoad();”> <h:formprependId=”false”> <center>
<h:panelGridcolumns=”1”>
<h:outputTextvalue=”Melhor Lance” />
<h:outputTextvalue=”---” id=”melhorlance” /> <h:outputTextvalue=”Dono do Lance” />
<h:outputTextvalue=”---” id=”donolance” /> </h:panelGrid>
<h:panelGridcolumns=”5”>
<h:outputTextvalue=”Seu Nome:” /> <h:inputTextid=”nome”/> <h:outputTextvalue=”Seu Lance” /> <h:inputTextid=”valor”/> <f:ajaximmediate=”true”>
<h:commandButtonvalue=”Dar Lance!” onclick=”darLance();” /> </f:ajax> </h:panelGrid> </center> </h:form> </h:body> </html> import javax.faces.bean.ManagedBean; import javax.faces.bean.ViewScoped; import org.directwebremoting.Browser; import org.directwebremoting.ScriptSessions; @ManagedBean(name = “lanceMB”) @ViewScoped
publicclass LanceMB implements java.io.Serializable {
publicvoidenviarLance(String nome, String valor) { try {
final String melhorlance = valor; final String donolance = nome;
Browser.withCurrentPage(newRunnable() { @Override
publicvoidrun() {
ScriptSessions.addFunctionCall(“receberLance”, melhorlance, donolance);
} });
} catch (Exception e) {
thrownewRuntimeException(e); }
} }
como parâmetro da engine DWR, que por sua vez recebeu os dados, no caso deste projeto, de um ManagedBean JSF2.0. Já a função darLance() invoca a interface LanceMB e utiliza o método enviarLance() encaminhando ao ManagedBean os parâmetros nome e valor do lance enviados por meio da página-cliente.
Implementação do exemplo com JSF –
Managed Bean
A codificação da ManagedBean LanceMB pode ser verificada na Listagem 6, onde se observa a implementação do método enviarLance(String nome, String valor). Com relação à codificação desta ManagedBean, algumas considerações podem ser feitas. Para a integração com o DWR foram utilizadas duas classes: Browser e ScriptSessions. Estas possibilitam a detecção e troca de mensagens entre o servidor e o cliente A primeira delas é a classe que exe-cuta o trabalho de fazer a ligação entre as páginas e as classes no servidor, definindo através de seus métodos quais páginas devem ser vinculadas por aquela chamada. Já a classe ScriptSessions é a que realiza o trabalho de passar valores do servidor para a página escolhida, seja chamando funções ou apenas definindo atributos. O escopo escolhido para a ManagedBean foi o @ViewScoped, pois associa o ciclo de vida da ManagedBean ao da página de origem das requisições. Vale ressaltar que não é necessário utilizar o JSF para utilização do DWR, a seleção desta tecnologia foi apenas para demonstrar a técnica do AJAX Reverso com outra tecnologia que promove o foco do projeto nos eventos da camada view.
: : www.mundoj.com.br : :
Na figura 5 é ilustrado o lance de um participante, chamado “Par-ticipante 1”, junto com mais dois par“Par-ticipantes. O par“Par-ticipante 1 foi simulado no navegador Google Chrome, sendo os outros dois
participantes simulados no FireFox e Internet Explorer, respecti-vamente.
Figura 5. Simulação de lance na implementação de leilão.
O download do projeto pode ser feito a partir da página: http://www.patternizando.com.br/ajax-reverso-baseado-em-comet-com-dwr
Considerações finais
São conhecidas outras formas de implementação que tentam al-cançar a mesma funcionalidade de deixar os clientes no mesmo estado que o servidor, como nos refreshs automáticos ainda muito utilizados. Porém, esse tipo de técnica pode ser ineficaz pelo alto consumo de banda ou algum atraso na atualização das informa-ções.
A implementação do Comet pode ser feita em diversas linguagens de programação. Na linguagem Java, existem vários frameworks disponíveis no mercado capazes de auxiliar o desenvolvedor a alcançar esse objetivo. Utilizando o DWR, essa implementação se torna fácil, pois é necessário apenas incluir sua biblioteca no projeto e algumas configurações básicas, que são comuns em qualquer framework utilizado.
Para produzir este artigo, esperava-se que fosse possível utilizar o framework Primefaces, que além de ser um conjunto de com-ponentes AJAX utilizado para aplicações RIA, possui a funciona-lidade de AJAX Reverso. Mas ainda há uma instabifunciona-lidade nessa funcionalidade do Primefaces, que deve ser corrigida na versão 2.3, planejada ainda para o começo de 2011. Espera-se que a nova versão venha com essa instabilidade solucionada, já que a com-binação dessas funcionalidades em apenas um framework seria muito útil para os desenvolvedores, possibilitando até um novo estudo abordando essa implementação. Destacando novamente que o DWR tem para sua versão 3.0 uma proposta de solução para seus problemas de escalabilidade, e atualmente a 3.0 está em Release Candidate.
O Comet tende a ser mais utilizado nas aplicações em geral, já que trata as requisições de forma diferente do padrão Web e que mais frameworks tenham total compatibilidade com o AJAX Reverso, o que resulta em novas possibilidades de codificação para os de-senvolvedores.
GUJ – Discussões sobre o tema do artigo e
assuntos relacionados
Discuta este artigo com 100 mil outros
desenvolvedores em www.guj.com.br/MundoJ
t '305" )BOEFSTPO3FWFSTF"+"9%83 $0.&5%JTQPOÓWFMFN IUUQ XXXIBOEFSTPOGSPUBDPNCSSFWFSTFBKBYEXSDPNFU "DFTTP FN EFTFUFNCSPEF
t $"7"-&30 1FESP(SJ[[MZF$PNFUo"+"93FWFSTPDPN&TDBMBCJMJEBEF 3FWJTUB .VOEP+ FEJÎÍP QÈHT B QVCMJDBEP FN TFUFNCSP EF t %83 %JTQPOÓWFM FN IUUQEJSFDUXFCSFNPUJOHPSHEXSEPXOMPBET JOEFYIUNM "DFTTPFNEFKBOFJSPEF t "5.041)&3&%JTQPOÓWFMFN IUUQBUNPTQIFSFKBWBOFU "DFTTPFN EFPVUVCSPEF t ;,%JTQPOÓWFMFN IUUQEPDT[LPTTPSHXJLJ%PDVNFOUBUJPO "DFT TPFNEFPVUVCSPEF t '305"