Esta página cita fontes, mas que não cobrem todo o conteúdo. Ajude a inserir referências (Encontre fontes: ABW  • CAPES  • Google (N • L • A)). (Outubro de 2010)

Aplicações de Internet Rica (da sigla em inglês RIA - Rich Internet Application) são Aplicações Web que tem características e funcionalidades de softwares tradicionais do tipo Desktop. RIA típicos transferem todo o processamento da interface para o navegador da internet, porém mantém a maior parte dos dados (como por exemplo, o estado do programa, dados do banco) no servidor de aplicação.^[1]

RIAs normalmente:

• Rodam em um navegador, ou não necessitam de Instalação
• Rodam localmente em um ambiente seguro chamado sandbox

O termo Aplicação de Internet Rica foi introduzido pela Macromedia em março de 2002, embora o seu conceito já tenha tido outras denominações anteriores, tais como:

• Remote Scripting, pela Microsoft, em 1998
• X Internet, pela Forrester Research em Outubro de 2000
• Cliente (Web) Rico
• Aplicação Web Rica

Aplicações web tradicionais centralizam todo seu código em torno de uma arquitetura de Cliente-servidor e um cliente magro. Todo o processamento é realizado no servidor, e o cliente apenas utiliza uma tela estática (neste caso em HTML). A grande desvantagem deste sistema é que a interação com a aplicação deve ser feita através do servidor, onde os dados são enviados para o servidor, são respondidos e a página é recarregada no cliente como resposta. Utilizando uma tecnologia uma aplicação-cliente que possa executar instruções no computador do usuário, RIAs podem reduzir significativamente o número de sincronizações e aumentar a interatividade com o cliente. Esta diferença pode ser verificada fazendo uma analogia entre terminal e mainframe e servidor de aplicação/Cliente Gordo.

Os padrões na Internet foram evoluindo lenta e continuamente ao longo do tempo para acomodar estas técnicas, por isso é difícil traçar uma linha entre aquilo que constitui um RIA e o que não faz parte de um RIA. Porém, todos os RIAs compartilham uma característica: eles introduzem uma camada intermediária de código, chamada normalmente de client engine, entre o usuário e o servidor. Este client engine é normalmente carregado no início da aplicação, e pode ser acrescido de outras atualizações do código que são baixadas enquanto a aplicação ainda está rodando. O client engine atua como uma extensão do navegador, e é responsável pela renderização da interface de aplicação do usuário e fazer a comunição com o servidor.

O que pode ser feito em um RIA é limitado pela robustez do sistema utilizado no cliente. Mas, em geral, o client engine está programado para executar funções que o seu desenvolvedor acredita que irão reforçar alguns aspectos da interface do usuário, ou melhorar a sua resposta ao manusear certas interações com o usuário, em comparação com a execução da aplicação em um navegador da Web padrão.

Porque os RIAs empregam um client engine para interagir com o usuário? Entre os motivos estão:

• Riqueza: É possível oferecer à interface do usuário características que não podem ser obtidos utilizando apenas o HTML disponível no navegador para aplicações Web padrão. Esta capacidade de poder incluir qualquer coisa no lado do cliente, incluindo o arraste e solte, utilizar uma barra para alterar dados, cálculos efetuados apenas pelo cliente e que não precisam ser enviados de volta para o servidor, como por exemplo, uma calculadora básica de quatro operações.
• Melhor resposta: A interface é mais reativa a ações do usuário do que em aplicações Web padrão que necessitam de uma constante interação com um servidor remoto. Com isto os RIAs levam o usuário a ter a sensação de estarem utilizando uma aplicação desktop.
• Equilíbrio entre Cliente/Servidor: A carga de processamento entre o Cliente e Servidor torna-se mais equilibrada, visto que o servidor web não necessita realizar todo o processamento e enviar para o cliente, permitindo que o mesmo servidor possa lidar com mais sessões de clientes concomitantemente.
• Comunicação assíncrona: O client engine pode interagir com o servidor de forma assíncrona—desta forma, uma ação na interface realizada pelo usuário como o clique em um botão ou link não necessite esperar por uma resposta do servidor, fazendo com que o usuário espere pelo processamento. Talvez o mais comum é que estas aplicações, a partir de uma solicitação, antecipe uma futura necessidade de alguns dados, e estes são carregados no cliente antes de o usuário solicite-os, de modo a acelerar uma posterior resposta. O site Google Maps utiliza esta técnica para, quando o usuário move o mapa, os segmentos adjacentes são carregados no cliente antes mesmo que o usuário mova a tela para estas áreas.
• Otimização da rede: O fluxo de dados na rede também pode ser significativamente reduzida, porque um client engine pode ter uma inteligência embutida maior do que um navegador da Web padrão quando decidir quais os dados que precisam ser trocados com os servidores. Isto pode acelerar a solicitações individuais ou reduzir as respostas, porque muitos dos dados só são transferidos quando é realmente necessário, e a carga global da rede é reduzida. Entretanto, o uso destas técnicas podem neutralizar, ou mesmo reverter o potencial desse benefício. Isto porque o código não pode prever exatamente o que cada usuário irá fazer em seguida, sendo comum que tais técnicas baixar dados extras, para muitos ou todos os clientes, cause um tráfego desnecessário.

As deficiências e restrições associadas aos RIAs são:

• Sandbox: Os RIAs são executado dentro de um Sandbox, que restringe o acesso a recursos do sistema. Se as configurações de acesso aos recursos estiverem incorretas, os RIAs podem falhar ou não funcionar corretamente.
• Scripts desabilitados: JavaScripts ou outros scripts são muitas vezes utilizados. Se o usuário desativar a execução de scripts em seu navegador, o RIA poderá não funcionar corretamente, na maior parte das vezes.
• Velocidade de processamento no cliente: Para que as aplicações do lado do cliente tenha independência de plataforma, o lado do cliente muitas vezes são escritos em linguagens interpretadas, como JavaScript, que provocam uma sensível redução de desempenho. Isto não é problema para linguagens como Java, que tem seu desempenho comparado a linguagens compiladas tradicionais, ou com o Flash, em que a maior parte das operações são executas pelo código nativo do próprio Flash.
• Tempo de carregamento da aplicação: Embora as aplicações não necessitem de serem instaladas, toda a inteligência do lado cliente (ou client engine) deve ser baixada do servidor para o cliente. Se estiver utilizando um web cache, esta carga deve ser realizada pelo menos uma vez. Dependendo do tamanho ou do tipo de solicitação, o carregamento do script pode ser demasiado longo. Desenvolvedores RIA podem reduzir este impacto através de uma compactação dos scripts, e fazer um carregamento progressivo das páginas, conforme ela forem sendo necessárias.
• Perda de Integridade: Se a aplicação-base é X/HTML, surgem conflitos entre o objetivo de uma aplicação (que naturalmente deseja estar no controle de toda a aplicação) e os objetivos do X/HTML (que naturalmente não mantém o estado da aplicação). A interface DOM torna possível a criação de RIAs, mas ao fazê-lo torna impossível garantir o seu funcionamento de forma correta. Isto porque um cliente RIA pode modificar a estrutura básica, sobrescrevendo-a, o que leva a uma modificação do comportamento da aplicação, causando uma falha irrecuperável ou crash no lado do cliente. Eventualmente, este problema pode ser resolvido através de mecanismos que garantam uma aplicação do lado cliente com restrições e limitar o acesso do usuário para somente os recursos que façam parte do escopo da aplicação. (Programas que executam de forma nativa não tem este problema, porque, por definição, automaticamente possui todos os direitos de todos os recursos alocados).
• Perda de visibilidade por Sites de Busca: Sites de busca podem não ser capazes de indexar os textos de um RIA.
• Dependência de uma conexão com a Internet: Enquanto numa aplicação desktop ideal permite que os seus usuários fiquem ocasionalmente conectados, passando de uma rede para outra, hoje (em 2007), um típico RIA requer que a aplicação fique permanentemente conectada à rede.

Com a advento das tecnologias RIA introduziu-se consideravelmente novas complexidades dentro de uma aplicação web. Aplicações web tradicionais eram construídas usando somente o HTML padrão, sendo sua arquitetura relativamente simples e com estruturas e opções limitadas de desenvolvimento, possuía um design relativamente simples para ser gerenciado. Para uma pessoa ou organização usar tecnologias RIA em uma aplicação web, a complexidade acrescida torna-se indispensável um design mais rígido, com testes, dimensionamento da aplicação e suporte.

Usar uma tecnologia RIA é muitas vezes um novo desafio para o SLM, ainda não totalmente solucionado. SLM não só se preocupa em manter seu foco nos desenvolvedores e aplicativos, e raramente suas práticas são percebidas pelos usuários da aplicação, mas são vitais para o sucesso da entrega de uma aplicação online.

• Grande complexidade torna o desenvolvimento mais difícil: A capacidade de mover o código para o cliente dá aos designers e desenvolvedores muito mais liberdade criativa. Mas, em contrapartida, o desenvolvimento torna-se muito mais complexo, e a probabilidade de erros e defeitos aumenta, o que exige testes mais complexos. Com isso, o processo de desenvolvimento de software torna-se mais longo, independentemente do processo ou metodologia específica empregada. Alguns desses problemas podem ser atenuados com a utilização de frameworks de desenvolvimento, para padronizar as características principais do design e desenvolvimento RIA. Aumentar a complexidade implica também prolongar o processo de testes, pois aumenta o número de casos de usos a ser testado. Testes incompletos ou deficientes reduzem a qualidade do software e sua confiabilidade durante a utilização. Pode-se dizer que o comentário acima não se aplica especificamente à tecnologia RIA, mas a complexidade em geral. Por exemplo, este argumento foi utilizado quando a Apple e a Microsoft anunciou a independência da GUI na década de 1980, ou mesmo quando a Ford anunciou o Modelo T. No entanto, os seres humanos têm mostrado uma notável capacidade de absorver os avanços tecnológicos ao longo de décadas, senão séculos.
• Arquitetura RIA quebra paradigmas de uma página Web: Aplicações web tradicionais podem ser vistas como uma série de páginas, cada uma com solicitações distintas de carregamento, inicializadas por uma requisição HTTP GET. Este modelo pode ser caracterizado como um paradigma de uma página web. RIAs invalida este modelo, introduzindo comunicações assíncronas adicionais para apoiar uma melhor resposta da interface para o usuário. Em RIAs, o tempo para completar o download de uma página já não corresponde como algo que um usuário vê como importante, porque o client engine pode prever a necessidade de carregar previamente alguns conteúdos para uso futuro. Novas técnicas de medição devem ser concebidas para poder mensurar um RIA, para poder a analisar se o tempo de resposta reflete na experiência do usuário. Na ausência de normas e ferramentas para tal, desenvolvedores RIA devem ter suas próprias técnicas para poder produzir os dados necessários para a medição SLM.
• Comunicação assíncrona torna mais difícil para isolar potenciais problemas: Paradoxalmente, as ações empreendidas para melhorar a aplicação e torná-las mais amigáveis tornam-na mais difícil de avaliar, compreender, reportá-las, e gerenciar. Algumas RIAs não emitem qualquer outra requisição HTTP GET ao navegador após o carregamento da primeira página, usando solicitações assíncrona realizadas pelo client engine para inciar os carregamentos necessários. O client engine pode ser programado para baixar continuamente novos conteúdos e atualizá-los na tela, ou (em aplicativos usando programação Comet) o novo conteúdo vai sendo baixado sem que a conexão com o navegador nunca se feche. Nestes casos, o conceito de "baixar uma página" já não é mais aplicável. Essas novas técnicas mais complexas tornam mais difíceis de se medir e subdividir os tempos de respostas de uma aplicação, um requisito fundamental para o isolamento de um problema e o seu gerenciamento.
• O uso do client engine torna a medição do tempo de resposta mais difícil: Para aplicações tradicionais web, o tamanho de um software pode ser medido tanto na máquina do cliente ou em uma máquina próxima do servidor, desde que o nível do fluxo do trafego da rede TCP e HTTP possa ser observado. Como estes protocolos são síncronos e previsíveis, um sniffing pode ler e interpretar os pacotes de dados, e inferir o tempo de resposta através do rastreamento das mensagens HTTP e TCP. Mas uma arquitetura RIA reduz esta capacidade de inferir o tempo de resposta, pois o client engine rompe a comunicação entre usuários e servidores separando a comunicação em dois ciclos assíncronos: um ciclo externo (usuário para client engine) e interno (client engine para servidor). Ambos os ciclos são importantes porque não funcionam sozinhos, e é este tipo de relacionamento que define o comportamento da aplicação. Mas como este relacionamento depende do design da aplicação, que (em geral) não pode ser medida por uma ferramenta de medição, especialmente esta que observa somente um dos ciclos. Assim sendo, uma medição mais completa de um RIA só pode ser obtido usando ferramentas que residem no cliente e que possam observar os dois ciclos.

RIAs ainda estão em estágios iniciais de desenvolvimento e aprovação do usuário. Há uma série de restrições e requisitos que ainda permanecem:

• Navegadores: Muitos RIAs necessitam de modernos navegadores da internet para poderem rodar corretamente. A utilização de JavaScript avançado deve estar presente no navegador, pois RIAs utilizam técnicas como XMLHttpRequest para a comunicação cliente-servidor, além de DOM scripting e técnicas de Cascading Style Sheets avançado para enriquecer a interface do cliente.
• Padronização: Diferenças entre navegadores podem dificultar a programação de um RIA que possa rodar na maior parte dos navegadores. A consistência da Plataforma Java, particularmente depois da versão 1.1, pôde simplificar esta tarefa através do uso de applets.
• Ferramentas de desenvolvimento: Alguns frameworks de Ajax e outros produtos como a linguagem de programação Curl, Adobe Flex e Microsoft Silverlight auxiliam com um ambiente de desenvolvimento integrado a construção de RIAs.
• Conceitos de acessibilidade: Novos conceitos de interatividade necessitam de novas técnicas que delimitem a acessibilidade da aplicação.
• Utilização do usuário: Muitos usuários estão acostumados com os padrões de uma aplicação web tradicionais e suas funcionalidades (como o botão voltar do navegador) que podem ter efeitos diferentes ou indesejáveis em aplicações RIA.

Embora desenvolver aplicações para rodar em um navegador web seja muito mais limitado, difícil e com um processo desenvolvimento confuso do que um desenvolvimento de uma aplicação do tipo desktop, os esforços são, muitas vezes justificado porque:

• Não necessita de instalação—a distribuição e atualizações das aplicações é realizada no servidor.
• Atualizações/implementações de novas versões são automáticas.
• Usuários pode utilizar a aplicação de qualquer computador com uma conexão com a internet, e normalmente é indiferente o sistema operacional que o computador está rodando.
• Aplicativos baseados na web são geralmente menos propensos a uma infecção de vírus do que um executável rodando na máquina.

A primeira grande linguagem com a habilidade tecnológica para rodar códigos no lado do cliente e interpretado pela maioria dos clientes web foi o JavaScript. Embora ele fosse relativamente limitado no início, combinado com o desenvolvimento em DHTML, tornou possível criar sistemas RIA sem o uso de uma solução no lado do cliente. Ajax é um novo termo que ficou conhecido para se referir a esta combinação de técnicas e que recentemente tem sido amplamente utilizada em projetos do Google, como o Gmail e o Google Maps. No entanto, criar grandes aplicações com este tipo de framework é muito complexo, com muitas tecnologias que devem interagir entre si, e que requerem compatibilidade com vários tipos de navegadores. Para facilitar o desenvolvimento de aplicativos, muitos programas de código aberto que utilizam frameworks do Ajax estão sendo desenvolvidos, e são tão completos quanto frameworks comerciais.

Adobe Flash é uma outra ferramenta para desenvolvimento de RIAs. É uma tecnologia multiplataforma e poderosa para criar aplicações. Adobe Flex provê a opção de criar interfaces em Flash, sendo compilados em MXML. A Adobe atualmente está trabalhando no intuito de aprimorar suas tecnologias com o Adobe AIR, que une HTML (incluindo Ajax), Flash para aplicações e PDFs. Dentre as RIAS utilizadas no mercado hoje, o adobe Flex é o que mais vem crescendo. Adobe Flex utiliza a linguagem MXML para gerar interfaces, ActionScript para sua programação front-end e uma outra linguagem para back-end, as mais usadas como back-end são php, java, ruby, pearl e python. Mas também é possível utilizar mais linguagens. Utilizando o plugin do flash acaba com o problema de incompatibilidade com os navegadores. A visão do Adobe Flex é foco no usuário e não na máquina, trazendo assim o conceito de web 2.0 com interativade de usuário mais à tona.

O Microsoft Silverlight pode ser considerado um subproduto do Windows Presentation Foundation (WPF), pois como o WPF, o Silverlight utiliza XAML. Portanto, desenvolvedores com experiências anteriores em desenvolvimento na plataforma .NET 3.0 e XAML não terão muitas dificuldades em desenvolver aplicações no Silverlight, que possui uma interface atraente e de fácil utilização.

Para que as aplicações possam ser executadas no lado do cliente, é necessário instalar um pequeno complemento (plug-in) com cerca de 2 Mb (o Silverlight Runtime), para que seja possível a execução do programa. Existe um outro complemento chamado Moonlight que está disponível também para plataformas Linux. A Microsoft tem planos de ampliar o leque de suporte para outras plataformas.

Utilizar os controles ActiveX em HTML é uma forma muito poderosa para desenvolver aplicativos ricos. No entanto, só são garantidos para funcionar corretamente no Internet Explorer, uma vez que nenhum outro browser até este momento possui suporte para ActiveX. Além disso, o ActiveX não é executado no sandbox. Portanto, eles são alvos potenciais para vírus e malwares, tornando-os de alto riscos para segurança.

Até o momento da redação deste texto, o Adobe Flash Player para o Internet Explorer é implementado como um controle ActiveX para ambientes Microsoft, bem como o plug-in multi-plataforma do Netscape. Só se a corporação tiver padronizado utilizar o Internet Explorer como o principal navegador, o ActiveX é por si só uma boa escolha para construir aplicações corporativas.

OpenLaszlo é uma plataforma de código aberto desenvolvido pela Laszlo Systems Inc.. O servidor OpenLaszlo compila programas escritos em linguagem LZX (uma mistura de tags XML e JavaScript), com em DHTML (também conhecido como AJAX) ou Adobe Flash bytecode, que atualmente suporta Flash7 e Flash8. O servidor - que inicialmente era um software proprietário - teve seu código aberto em Outubro de 2004 graças a uma licença pública. Ele é a única Aplicação Rica de Internet que é capaz de compilar em dois diferentes runtimes a partir do mesmo código base.

Alternativas para o Java e JVM para RIAs não faltam; há três aplicativos disponíveis: Curl, Rebol e Smalltalk. Curl facilita o controle com dados persistentes do lado do Cliente, Rebol não necessita de um browser e Seaside para Smalltalk utiliza uma pequena extensão do Smalltalk para proporcionar a criação de páginas ricas para web. Todas as três alternativas são muito mais maduras do que as opções existentes hoje e tão antigas quanto o Java e JVM.

A Sun Microsystems é responsável pelo desenvolvimento do JavaFX, uma família de produtos baseada na tecnologia Java e concebido para proporcionar uma maior interatividade e já pode ser encontrada em uma ampla variedade de dispositivos, incluindo computadores pessoais (em forma de applets e clientes do tipo stand-alone) set-top boxes, dispositivos móveis e dispositivos que usam a tecnologia Blu-Ray. A plataforma JavaFX será inicialmente composta por JavaFX Script e JavaFX Mobile. Criado pelo engenheiro da Sun Chris Oliver como um projeto despojado, JavaFX Script possibilita o desenvolvimento rápido de interfaces ricas em 2D e utiliza uma sintaxe declarativa, semelhante ao SVG. A Sun possui planos para liberar JavaFX Script como um projeto de código fonte aberto, mas o JavaFX Mobile será um produto comercial disponível através de uma licença OEM para operadoras e os fabricantes.

Java applets são códigos executados em páginas HTML padrão e geralmente são incializados automaticamente quando a página Web é aberta no navegador web. Eles possuem acesso à tela (dentro de uma área designada pela página HTML), bem como à placa de som, teclado e mouse de qualquer computador onde a página da Web é aberta, e acesso à Internet, proporcionando um ambiente sofisticado capaz e de executar tarefas em tempo real.

Em vez de HTML/XHTML, novas linguagens para a construção de interfaces do usuário podem ser utilizadas em RIAs. Por exemplo, a Fundação Mozilla utiliza o XML-based user interface markup language XUL - isto poderia ser usado em RIAs embora restringiria o seu uso para navegadores Mozilla, uma vez que esta plataforma não é padrão entre os navegadores. O W3C criou o Web Application Formats Working Group, cuja missão inclui o desenvolvimento de tais normas de padronização. O projeto original DARPA no MIT, que resultou na W3C também proporcionou a criação do Curl, que já está na versão 5,0.

Interfaces RIAs também podem se tornar mais ricos, através da utilização scripts de elementos gráficos vetoriais escaláveis (embora nem todos os navegadores podem renderizar nativamente ainda), bem como o Synchronized Multimedia Integration Language (SMIL).

Com funcionalidades operando no lado do usuário, como Javascript e DHTML, as aplicações RIA podem operar sobre uma ampla gama de sistemas operarionais e funcionalidades de servidores web.

• Flickr do Yahoo!, gestão de fotos ;
• Gmail do Google, e-mail ;
• Google Maps do Google, mapa interativo ;
• Deezer, site de streaming para escutar música gratuita;
• Pixlr, Editor on-line de imagens (uma versão gratuita do Photoshop online) http://www.pixlr.com/

• Adobe AIR
• Adobe Flex
• Ajax
• Push Technology or server push
• Curl
• Dojo Toolkit
• Echo
• Google Web Toolkit (GWT)
• IT Mill Toolkit
• Java
• JavaFX
• List of Rich Internet applications
• Remote Scripting
• Seaside for Smalltalk
• Single page application
• Windows Presentation Foundation
• ZK Framework
• Microsoft Silverlight
• Remote XUL

Referências

• The W3C Rich Web Clients Activity
• Macromedia March 2002 requirements for Rich Internet Applications: (500K PDF or HTML abstract^{[ligação inativa]})
• October 2000 Forrester Opinion Pieceon what they then called the "X Internet".
• Necessity of methodologies to model rich Internet applications: Preciado, J.C.; Linaje, M.; Sanchez, F.; Comai, S.
• Hello World Rich Internet Application (RiA) Recipe Background
• The Universal Desktop - A Rich Internet Application blog on ZDNet

• Portal das tecnologias de informação