O Webmaster é um profissional capaz de gerenciar as tarefas tanto de um webdesigner (elaboração do projeto estético e funcional de um web site) quanto de um web developer ( que faz a parte da programação, como sistemas de login, cadastro, área administrativa).

Um webmaster não necessariamente domina tecnologias de programação, desenvolvimento e plataformas CMS. Os responsáveis técnicos pelo layout e pelo sistema do site são em geral respectivamente o web designer e o web developer. O webmaster é a pessoa responsável por tomar as decisões quanto aos trabalhos específicos destes profissionais, bem como por assessorar o proprietário do website quanto a alterações e melhorias no mesmo.

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.

RIAs normalmente:

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

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.

Deficiências e restrições

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.

Dificuldades no Gerenciamento

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.