janeiro 19, 2007
URLs hierárquicos e intuitivos
Com o advento da web2.0 (cada vez mais virada para os utilizadores), cada vez faz mais sentido criar estruturas de URLs que sejam intuitivas, fáceis de identificar, permanentes (tal como os conteúdos para onde estes apontam) e que possam ser manipuladas pelos utilizadores. Para além de promoverem a usabilidade, facilitam a utilização de páginas de entrada alternativas e mais apropriadas a cada utilizador; assim, é facilmente defensável que ao favorecer mecanismos de navegação alternativos (que não os que o site disponibiliza), o utilizador acaba por encontrar mais rapidamente os recursos que procura.
Uma outra preocupação que deve ser tida em consideração na criação da estratégia de navegação é a sua organização, tendo em conta que os URLs nunca devem desaparecer (tal como os recursos a que se referem), e a estrutura ser hierárquica, facilitando a navegação dos critérios mais genéricos para os mais específicos.
Numa estrutura adequada de URLs, só são utilizados parâmetros para a componente dinâmica em formulários; caso contrário, existe uma camada de abstracção que garante que o acesso a /automoveis/alfa romeo/ é passado correctamente à componente aplicacional (em oposição a /listar.asp?tipo=1&marca=3).
Se a estrutura criação da estrutura de navegação tiver em consideração estas preocupações, conseguimos atingir alguns objectivos interessantes:
estrutura legível e hierárquica
Se a estrutura de navegação for legível e hierárquica, os utilizadores facilmente assimilam a estrutura e os conteúdos disponibilizados.
URLs devem poder ser guardados/memorizados
Se os URLs forem facilmente memorizados, é natural que os visitantes consigam navegar mais facilmente e atingir mais rapidamente o seu objectivo; se o utilizador procura automóveis da marca alfa romeo, deve ser possível fazê-lo utilizando o URL /automoveis/alfa romeo/ e não /listar.asp?tipo=1&marca=3. Para além disso, grande parte dos ataques a aplicações web passa pela manipulação de parâmetros (que de outra forma deixa de ser possível)...
URLs devem poder ser adivinhados
Se o visitante quer procurar livros de banda desenhada, deve ser possível adivinhar a forma mais rápida de chegar ao que procura experimentando através do acesso a /comprar/livros/bd/, /livros/bd/, /banda-desenhada/, etc.
URLs devem esconder a complexidade aplicacional e organização de conteúdos
As alterações de infra-estrutura aplicacional ocorrem cada vez com mais frequência, tendo em conta a evolução de funcionalidades. Isso implica que a hierarquia de URLs também é alterada (/prod/comprar.php?tipo=66&prod=3 passa a /op/int/compra.jsp?SID=e873h4d8776d73), traduzindo-se em alterações visíveis e indesejadas para os visitantes (que só querem chegar rapidamente ao que procuram). Assim, a camada de abstracção deve ser responsável por traduzir o acesso aos dados entre aplicações, mantendo a estrutura visível para os visitantes.
É ainda possível pré-gerar versões estáticas dos conteúdos gerados dinamicamente, e servi-los se existirem no formato estático, libertando a componente aplicacional de algum trabalho.
Apresentar alternativas
Se não existir correspondência entre um URL e um determinado recurso, devem ser apresentadas alternativas ao visitante, de forma a detectar potenciais erros e garantir que o utilizador é direccionado para os conteúdos apropriados.
Estes objectivos podem facilmente ser atingidos com componentes tecnológicas que existem, são fiáveis mas tipicamente são pouco utilizadas. Os mecanismos de reescrita de URLs potenciam outros objectivos, como por exemplo balanceamento, distribuição de conteúdos por vários serviços internos, criação de friendly urls, SEO, etc. e a sua utilização só tem como requisito tempo para definir uma estratégia...possivelmente com a consulta do capítulo 9, onde são abordadas algumas configurações básicas do mecanismo de reescrita.
Publicado por scorpio às 09:55 AM | Comentários (0) | TrackBack
janeiro 06, 2007
arquitectura web para balanceamento
As infra-estruturas web actuais conjugam a necessidade de servir conteúdos estáticos (documentos, imagens, filmes, som, etc) com a componente aplicacional. É típico de um mesmo serviço web garantir as duas funcionalidades, em particular com tecnologias PHP, Perl, Python, sendo visível a degradação de desempenho com o aumento da sua utilização, uma vez que servir conteúdos dinâmicos implica a utilização de mais recursos (memória, tempo de processador, acesso a disco) do que servir conteúdos estáticos.
Tirando partido de uma funcionalidade específica do mod_rewrite, é possível segmentar as duas funções (servir conteúdos estáticos e executar a componente dinâmica), possibilitando simultaneamente uma melhoria de desempenho e menor utilização de recursos sem quaisquer alterações na componente aplicacional.
Para o conseguir, é necessário caracterizar pelo menos uma das componentes (estática ou dinâmica) no que diz respeito ao espaço de URIs, de forma a parametrizar o mecanismo que garante a divisão de pedidos. Tipicamente, esta caracterização é efectuada com base nas extensões dos ficheiros que correspondem à componente aplicacional (.pl, .php, .jsp, etc). Um outro requisito é a instalação de um serviço web que recebe todos os pedidos (apache com suporte mod_rewrite e mod_proxy) e a activação do serviço relativo à componente aplicacional num outro porto. Na prática, o primeiro serviço recebe todos os pedidos, aplica algumas regras aos pedidos e decide se deve servir de imediato os pedidos (tipicamente, conteúdos estáticos) ou se solicita o resultado dos mesmos pedidos ao servidor aplicacional.
Para efeitos de exemplo, vamos assumir que a componente aplicacional é garantida por ficheiros com a extensão jsp e que o serviço aplicacional está à escuta no porto 8080. A configuração do serviço web de frontend (que receve todos os pedidos) deverá ser semelhante ao seguinte:
<VirtualHost *:80>
ServerName apache.superbofh.org
ServerAlias www.apache.superbofh.org
...
...
DocumentRoot /srv/vhosts/apache.superbofh.org
RewriteEngine On
RewriteRule ^/(.*\.jsp.*)$ http://%{HTTP_HOST}:8080/$1 [P,L]
RewriteRule ^/?$ http://%{HTTP_HOST}:8080/default.html [P,L]
</VirtualHost>
Esta configuração garante que os conteúdos estáticos (e/ou outros que não os servidos pelos .jsp) são servidos rapidamente, e os pedidos da componente aplicacional são passados ao servidor correspondente. Para além disso, a configuração não publicita o facto de se estar a utilizar serviços diferentes para garantir as duas funções; caso seja pretendido que os clientes se apercebam deste facto, bastará alterar as flags das regras de reescrita (substituir o P por um R).
Publicado por scorpio às 12:24 PM | Comentários (0) | TrackBack
dezembro 12, 2006
monitorizar apache
É possível monitorizar o comportamento do apache, recorrendo às informações disponibilidadas pelos módulos info e status. Estes dois módulos, que podemos mapear em URIs específicos (por omissão /server-info e /server-status, respectivamente) possibilitam a análise da configuração activa (via web) e do estado do servidor web, em tempo real.
A informação disponibilizada por este último módulo permite-nos, por exemplo, saber quantos pedidos por segundo estão a ser efectuados, qual a largura de banda utilizada, quantos processos do servidor web existem actualmente, quais estão activos / em espera, em que estado está cada um dos pedidos efectuados, qual a origem dos pedidos, a que virtualhost foram feitos os pedidos, etc.
Um exemplo deste mecanismo está disponível no próprio servidor da ASF: server-status.
Uma vez que é possível analisar em tempo real o estado do servidor web através destes mecanismos, é também possível guardar um histórico de comportamentos, de forma a que possam ser detectados problemas pela análise de padrões.
Uma das ferramentas que o permite fazer é o apache.mrtg, que utiliza gráficos gerados pela biblioteca RRD para traçar os perfis relativos à evolução de vários parâmetros.
Nota:Para monitorizar o servidor apache através deste mecanismo é necessário activar o parâmetro ExtendedStatus na configuração global.
Publicado por scorpio às 12:21 PM | Comentários (0) | TrackBack
dezembro 06, 2006
Controlar os robots
Se analisarem com alguma atenção os registos do servidor web, rapidamente chegarão à conclusão que o número de acessos efectuados por bicharada (crawlers, robots ou spiders) é cada vez maior. Se não forem domesticados, estes automatismos podem facilmente sobrecarregar os servidores web e impedir que os utilizadores legítimos consigam utilizar os serviços.
Actualmente, estão registados cerca de 300 destes mecanismos na base de dados de robots na web, o que quer dizer que é possível identificar os objectivos de cada um, bem como a sua forma de funcionamento. Ainda assim, existe um número enorme que não está registado e cujo comportamento pode causar problemas.
Os mecanismos existentes para controlar este tipo de acessos passam pela configuração do servidor web, tipicamente com o mecanismo conhecido como robots.txt. Para tirar partido deste mecanismo, basta criar um ficheiro com este nome na raiz do servidor web (ou do virtualhost em questão) e incluir a configuração relativa a cada robot. Segue-se um exemplo:
User-Agent: GetURL.rexx v1.05
Disallow: /adm
Disallow: /images
User-Agent: Nutch
Disallow: /configuracao
Publicado por scorpio às 10:03 PM | Comentários (0) | TrackBack
Configurar páginas de erro
Tipicamente, as páginas de erro dos serviços web são as páginas instaladas por omissão. Para além de não serem particularmente intuitivas para o utilizador, também não são adaptadas a cada site e não ajudam o utilizador a encontrar o que procura. Descrevemos abaixo algumas regras de boas práticas para a criação de páginas de erro, e porque é importante criá-las.
Tendo em conta que se pretende que os utilizadores não encontrem um beco sem saída se depararem com um erro, faz sentido que a página de erro tenha uma referência directa (e indicada com clareza) para a página principal e/ou para o mapa do site, de forma a que a navegação não seja interrompida quando o utilizador se depara com o erro.
Para além disso, é importante dar a possibilidade ao utilizador de tentar chegar rapidamente ao seu destino. Assim, é interessante que as páginas de erro tenham um formulário de pesquisa (para pesquisas locais) e uma pequena mensagem a descrever o problema.
Se possível, a página de erro deve tentar encontrar possíveis razões para o problema (erro na componente aplicacional, recurso não encontrado, pequenos erros de sintaxe, etc) de forma a que o estigma do erro não fique do lado do utilizador.
Se pelo menos algumas destas medidas forem seguidas, o nosso site ficará um pouco mais agradável para o utilizador, e conseguirá manter o utilizador a navegar no nosso site mais tempo - que é o que todos queremos, naturalmente.
Publicado por scorpio às 07:06 PM | Comentários (0) | TrackBack