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 October 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). 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 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 a 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 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.

• Equilibrio 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 imbutida 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.

Interface com o Usuário

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).

RIAs podem utilizar XForms para melhorar sua funcionalidade.

 

Ferramentas de desenvolvimento e funcionalidades para usuário necessárias para RIA

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.