Anatomia de uma arquitectura Web SIG

Em destaque

Para a parte da comunidade que ainda não deslindou completamente os componentes duma arquitectura WEB SIG e os seus respectivos papéis, aqui vai um pequeno e modesto contributo.

Arquitectura Web SIG

Um Web SIG tem como objectivo fundamental disponibilizar, a uma dada comunidade de utilizadores, acesso facilitado a informação geográfica e a ferramentas de modelação e processamento. Oferece uma arquitectura aberta e distribuída para disseminação de dados espaciais e aplicações Web de processamento na Internet. Esta característica faz com que as organizações facilmente distribuam conteúdos e aplicações de geoprocessamento sem grandes restrições de tempo e custo para os seus utilizadores ou consumidores.

Para implementação duma solução Web SIG empresarial existem várias arquitecturas possíveis, apresentando cada uma deles, obviamente, vantagens e desvantagens, e sendo umas mais apropriadas que outras a determinados contextos organizacionais. Não obstante à configuração final que esta arquitectura possa assumir, existem no entanto, componentes básicos e obrigatórios; que se passam a enumerar e descrever:

 

  • GIS Web Service ArchitectureCliente: tipicamente refere-se ao Web browser na máquina do utilizador. Na esfera Web SIG o Cliente é normalmente o local onde os utilizadores interagem com os dados espaciais ou com as ferramentas de análise espacial. É também o local onde os programas SIG oferecem diferentes formas de output para o utilizador em função de comandos, funções, tarefas e/ou ferramentas que são despoletados por algumas acções executadas no lado do Cliente ou do Servidor e que podem ter alguma lógica de negócio associada.
  • Servidor: a arquitectura de Servidor dum Web SIG geralmente tem quatro componentes: Servidor Web, Servidor Aplicacional, Servidor de Mapas e Servidor de Dados.
  • Servidor Web: é o que responde a pedidos enviados pelo Web browser via HTTP.
  • Servidor Aplicacional: é na sua essência um software que apoia o desenvolvimento, implementação e gestão dum número alargado de aplicações num ambiente distribuído. Actua como middleware que define, mantém e termina uma dada ligação entre o Servidor Web e o Servidor de Mapas. Também gere os pedidos concorrentes e faz o balanceamento de carga entre os Servidores de Mapas. O principal objectivo do Servidor Aplicacional é a separação da lógica de negócio da lógica de apresentação e lógica de dados.
  • Servidor de Mapas: é considerado o “cérebro” de qualquer aplicação Web SIG. Disponibiliza funções SIG tradicionais, como análise espacial, pesquisa – queries – sobre componente alfanumérica ou geométrica dos dados, geoprocessamento, e gera e disponibiliza mapas dinâmicos ao Cliente de acordo com os pedidos dos utilizadores.
  • Servidor de Dados: gere os dados, espaciais ou não espaciais, num sistema de gestão de base de dados relacional ou não relacional. As aplicações Cliente acedem, através dos respectivos intermediários, aos dados através de declarações SQL.

Geralmente os componentes apresentados são implementados numa arquitectura multi-camada, em que as camadas de apresentação, aplicacional e de recursos estão logicamente separadas. No contexto Web SIG o Cliente envia um pedido HTTP para o Servidor Web que o reencaminha para o Servidor Aplicacional. O Servidor Aplicacional responde ao pedido reencaminhando-o para o Servidor de Mapas apropriado gerindo a carga entre os respectivos Servidores de Mapas existentes. O Servidor de Mapas sintetiza o pedido e executa as funções SIG apropriadas requisitando os respectivos dados ao Servidos de Dados.

Arquitectura Servidor ESRI

Fazendo o mapeamento da arquitectura atrás descrita na plataforma de software ESRI, e no contexto duma arquitectura dita tradicional, ou mais usual – do tipo multi-camada – temos algo como:

  • A componente Servidor Web da arquitectura ArcGIS Server actua como Servidor Aplicacional da arquitectura genérica Web SIG apresentada anteriormente, e aloja os Web services e aplicações Web que usam recursos a ser executados nos Servidores SIG. Recebe pedidos dos Clientes e distribui tarefas pelos Servidores SIG.
  • Os Servidores SIG são equivalentes ao Servidor de Mapas na arquitectura genérica Web SIG. Os Servidores SIG alojam recursos SIG, como mapas, globos, roteiros de moradas, e expõem-nos como serviços para as aplicações Cliente. O Servidor SIG é composto por duas partes distintas: o server object manager (SOM) e o (ou os) server object container (SOC). Como o nome indica, o SOM gere os serviços que estão a ser executados no Servidor. Quando um Cliente faz o pedido de um determinado serviço, é o SOM que o providencia i.e. o SOM liga-se a um ou mais SOC. Os SOC alojam serviços que o SOM gere. Dependendo da configuração física da arquitectura Web SIG implementada, o SOM e o, ou os, SOC podem estar instalados na mesma ou em diferentes máquinas.
  • O Servidor de Dados contem os recursos SIG que são publicados como serviços no Servidor SIG.

ArcGIS Server System Architecture

 

Tipicamente as aplicações Cliente são Web, móvel ou Desktop e ligam-se via HTTP aos Web services do ArcGIS Server ou via LAN/WAN aos serviços locais.

Os componentes de software da arquitectura ArcGIS Server podem ser implementados sob diferentes combinações de plataformas suportando tanto os requisitos disponíveis do sistema como capacidade de escalabilidade. Contudo, apesar da flexibilidade, a localização dos diferentes componentes e as configurações de software seleccionadas têm impacto directo na capacidade do sistema, na sua fiabilidade, e performance global.

Arquitectura para pequenas/médias aplicações em Silverlight

Assume-se que o leitor está familiarizado com Silverlight, Custom Controls e C# .net.

O objectivo deste texto consiste em apresentar uma arquitectura para aplicações de pequena/média dimensão em Silverlight.

As características principais que esta arquitectura tenta cumprir são simplicidade, modularidade e facilidade de desenvolvimento. 

Uma aplicação típica é constituída por um conjunto de contextos, cada um populado por um conjunto de controlos, os quais, quando activados, desencadeiam um conjunto de acções que alteram o estado interno da aplicação e actualizam a interface.

Nestes termos, é possível atribuir procedimentos a controlos, sendo estes executados mediante o estado interno da aplicação, e respectivos estímulos efectuado sobre os mesmos (controlos). A maneira mais simples de fazer esta atribuição de procedimentos consiste em especificá-los directamente dentro do corpo (ou classe) do controlo. Infelizmente, esta metodologia dificulta a reutilização de código desenvolvido e promove a replicação de código semelhante, o que por sua vez tem impacto sobre a manutenção, extensão e compreensão da aplicação à medida que esta vai crescendo. Aplicações desenvolvidas em Silverlight não fogem a esta regra. Por esta razão, proponho aqui uma solução que tenta resolver alguns destes problemas. O objectivo desta solução consiste em facilitar uma metodologia de desenvolvimento que promove uma separação entre controlos, contextos e comportamentos.

Neste texto, para simplificar, vamos assumir que a aplicação que queremos desenvolver necessita apenas de botões como controlos e de menus como contextos. Os botões, por sua vez, podem fazer aparecer e desaparecer menus e activar e desactivar outros botões.

Uma vista inicial da aplicação que propomos segue a seguinte estrutura:

clip_image002

É constituída por uma solução Silverlight, um projecto adicional chamado ApplicationFramework e quatro directórios iniciais: Attributes, Behaviours, Controls e Themes.

Continuar a ler