WebGIS: Arquitetura de aplicações corporativas – Parte 1

A construção de uma aplicação WebGIS simples está cada vez mais  próxima de usuários que não sabem programar nenhuma linha de código (serviços como ArcGIS Online, Mapbox e CartoDB estão aí para provar esta teoria). Quando o objetivo é simplesmente ver um mapa temático, realmente esta solução é mais do que suficiente para suprir a necessidade.

Porém quando estamos em um ambiente corporativo outras questões precisam ser abordadas como: controle de acesso, auditoria, estatísticas, log e outros tantos pontos que nós analistas de sistemas lidamos no nosso cotidiano. Como construir então um software GIS na Web que atenda aos requisitos corporativos?

Proposta de arquitetura WebGIS

A arquitetura de uma solução é uma abstração de como devemos interligar componentes (seja computacional ou humano)  para resolver um problema específico. Para isso costuma-se utilizar diagramas para materializar uma proposta arquitetural. No nosso caso, será uma proposta de como uma solução WebGIS pode ser construída de tal maneira que consiga atender aos diversos requisitos de um ambiente corporativo.

arquitetura-webgis

 

A proposta acima separa a construção da solução em camadas, com o objetivo de separar claramente as responsabilidades e deixar o processo de desenvolvimento mais simples, permitindo inclusive a utilização de diferentes profissionais atuando na camada na qual é especialista sem trazer tantos impactos nas outras camadas.

Resumidamente os objetivos de cada camada são:

  • Camada de Apresentação: Responsável por montar a interface do usuário e exibir exibição dos mapas. Com a adoção mais forte do HTML 5, a criação de interfaces ricas através do uso de Javascript e CSS se tornou um padrão de facto. E não se enganem: a complexidade da codificação desta camada é muito alta (ainda tem alguém aí pensando que não é necessário o uso de construção e testes automatizados em Javascript? Espero que não!)

 

  • Camada de Negócio: É onde está a inteligência do sistema, onde a maioria dos requisitos serão atendidos. Todas as integrações com outros sistemas dentro de uma corporação estão nesta camada (existem casos que a própria camada de apresentação pode interagir com outros sistemas através de APIs REST, por exemplo). Esta camada fica hospedada em servidores de aplicação (IIS, Tomcat, Weblogic, etc) e são chamadas diretamente pela Camada de Apresentação.

 

  • Proxy: Faz parte da Camada de Negócio, porém precisa de uma menção especial. É através dela que será possível controlar o acesso à Camada GIS, fornecendo a possibilidade de realizar controles que atualmente a maioria dos produtos do mercado não fornecem nativamente (exemplo: permitir que somente algumas feições sejam exibidas ao usuário com determinado perfil na aplicação). Como depende diretamente dos recursos da Camada de Negócio, conceitualmente foi deixada nesta camada. Esta camada é chamada diretamente pela Camada de Aplicação.

 

  • Camada GIS: Camada que é responsável pelas rotinas de geoprocessamento do nosso WebGIS. Geralmente utilizamos algum outro software para o fornecimento dos geoserviços que serão utilizados pela aplicação. Lembrando que os geoserviços não se resumem a produzir mapas, podendo conter a disponibilização de feições vetoriais e matriciais, realização de geoprocessamento e outras diversas operações.

 

  • Camada de Banco de Dados: É onde serão armazenados os dados transacionais e geográficos. Apesar de parecer mais uma camada simples, existem diversos aspectos que temos que considerar numa solução corporativa (como a escolha do formato de armazenamento das geometrias que pode influenciar nos requisitos de interoperabilidade, caso existam).

Os próximos posts tratarão especificamente sobre cada camada, discutindo sua importância na solução final e quais alternativas de ferramentas e produtos podemos utilizar. Todos os softwares mencionados estarão no Índice de Geotecnologias para referência futura. Até mais!

Deixe um comentário