CAPÍTULO 2 ARQUITETURAS CLIENTE-SERVIDOR PARA DISSEMINAÇÃO DE DADOS GEOGRÁFICOS: UMA REVISÃO

Transcrição

1 CAPÍTULO 2 ARQUITETURAS CLIENTE-SERVIDOR PARA DISSEMINAÇÃO DE DADOS GEOGRÁFICOS: UMA REVISÃO Existem várias maneiras com as quais dados geográficos podem ser distribuídos pela Internet, todas fundamentadas no modelo cliente-servidor (Plewe,1997). A Figura 2.1 apresenta a arquitetura básica de um sistema cliente-servidor. Esta arquitetura é constituída de programa cliente, denominado navegador, que se comunica com o servidor através de um protocolo HTTP ( Hyper Text Transfer Protocol ) e faz uma requisição. O servidor processa a requisição e retorna o endereço de uma página HTML ( Hyper Text Markup Language ) através de uma URL ( Universal Resource Locator ) que é então enviada ao cliente. Cliente Requisições de URL Servidor Navegador Páginas HTML, imagens Servidor HTTP Arquivos Figura 2.1 Arquitetura de um projeto cliente-servidor clássico. FONTE: Modificada de Plewe (1997). O modelo utilizado para disseminação de dados geográficos é normalmente uma extensão do conceito cliente-servidor conhecido como servidor multi camada ( multi-tiered ). Nesta 6

2 arquitetura, o cliente pode ser um navegador da Internet (com programas acoplados) ou um SIG. O servidor multi camada consiste de um programa servidor de HTTP e um programa servidor de dados geográficos. Quando é feita uma requisição ao servidor, a mensagem é enviada pela Internet ao programa servidor de HTTP. O servidor de HTTP reconhece esta mensagem e passa os parâmetros para execução para o servidor de dados geográficos. O servidor de dados geográficos, executa os processamentos e retorna os resultados ao servidor HTTP, que por sua vez os envia ao cliente. Os dados que o servidor HTTP envia ao cliente devem estar num formato que possa ser entendido pelo navegador, por um programa acoplado a este, ou um applet JAVA, conforme a arquitetura do sistema utilizado. A Figura 2.2 apresenta os componentes típicos de uma arquitetura multicamada. Cliente Navegador SIG Disco Local Requisições de URL Páginas HTML, imagens, dados geográficos. Servidor Servidor HTTP Servidor de Dados Repositório de Dados Figura 2.2 O Modelo cliente-servidor multi camada. FONTE: Modificada de Plewe (1997). As estratégias de implementação podem estar concentradas no lado do servidor, onde é feito o processamento das requisições e o retorno dos dados ao cliente, concentrados no lado cliente, onde os usuários são capazes de realizar alguma manipulação local, ou distribuída em sistemas híbridos em que os processos podem ser combinados para satisfazer necessidades específicas (Foote,1997). 7

3 2.1 ARQUITETURAS CLIENTE-SERVIDOR PARA DADOS GEOGRÁFICOS DISPONÍVEIS NA INTERNET Nos últimos anos vem crescendo o número de iniciativas para publicação de dados geográficos na Internet. Estas iniciativas implementam serviços que variam desde simples servidores de arquivos com dados geográficos que podem ser transferidos pelos usuários, a sistemas sofisticados que permitem seleções utilizando linguagens de consulta espaciais e buscas por metadados. Em sua maioria estes serviços estão baseados nas arquiteturas de Servidores de Mapas, Clientes de Apresentação, Cliente-Servidor de Dados Geográficos, ou variações sobre elas. Neste tópico vamos discutir estas 3 arquiteturas SERVIDORES REMOTOS DE MAPAS Neste tipo de arquitetura os mapas podem ser estáticos, ou seja, gerados previamente por sistemas de informação geográfica e inseridos em páginas HTML para consultas, ou dinâmicos, onde o usuário pode estabelecer alguns parâmetros para sua visualização tais como região geográfica, planos de interesse e simbologia a ser utilizada. Usualmente os mapas estáticos são convertidos por sistemas de informações geográficas para um formato de imagem padrão tal como GIF ou JPEG e posteriormente inseridos em páginas HTML que poderão ser acessadas pelos usuários. Pode se utilizar também o formato vetorial, porém estes formatos exigem que seja instalado um programa acoplado ao navegador para sua visualização. Esta operação de instalação necessita ser efetuada somente uma vez e a partir daí serão habilitadas as interações com dados em formatos tais como CGM e DXF que são bastante difundidos para intercâmbio de dados. Para os casos onde são transferidos arquivos de imagem entre o servidor e o cliente de dados geográficos a alternativa mais utilizada para diminuir o volume de dados é a compactação para formatos de arquivos tais como GIF ou JPEG. Outra alternativa que pode ser utilizada em conjunto com a compactação é o pré-processamento de arquivos de 8

4 imagem para serem transferidos conforme a escala de apresentação no cliente. O trabalho de Evans (1996) apresenta um esquema em que imagens de ortofotos de tamanho original de 8.000x8.000 pixels são recortados em 16 partes de 2.000x2.000 pixels, que são posteriormente recortadas em 16 partes de 500x500 pixels. As imagens originais de 8.000x8.000 pixels são reamostradas em 16 vezes, e as intermediárias de 2.000x2.000 pixels são reamostradas em 4 vezes gerando imagens resultantes de 500x500 pixels. As imagens armazenadas no servidor que serão transferidas ao cliente tem tamanho fixo de 500x500 pixels e representam 3 níveis para visualização. O primeiro nível apresenta a imagem original reamostrada em 16 vezes e uma grade que permite ao usuário selecionar qual das 16 partes dela deseja visualizar no próximo nível de apresentação. Este esquema se repete para o segundo nível e para cada seleção do usuário é transferido um arquivo de 500x500 pixels entre o servidor e o cliente. A quantidade de níveis utilizada para uma aplicação vai determinar o número de arquivos que deverão ser armazenadas no servidor para representar uma unidade de região definida. No caso das ortofotos para representação de cada imagem original de 8.000x8.000 pixels são necessários 273 ( ) arquivos de 500x500 pixels. Este número muito grande de arquivos pode trazer problemas para organização e manutenção dos dados no servidor. A Figura 2.3 apresenta o esquema de divisão de uma ortofoto original em partes pixels 500 pixels pixels Figura 2.3 Esquema de divisão de uma ortofoto de 8.000x8.000 pixels. FONTE: Evans (1996). 9

5 Para os casos onde se utilizam arquivos vetoriais para representação de dados geográficos existem também propostas de formatos compactados para seu armazenamento tal como o TWF (TECGRAF Web Format) (Ferreira,1998). Segundo Ferreira, A comparação com arquivos GIF indica que a técnica proposta é boa para resoluções de apresentação por volta de 4.096x4.096 pixels. Isto é, se a resolução é pequena, por exemplo 512x512, o arquivo GIF é definitivamente menor. Por outro lado, para resoluções muito grandes (32.768x32.768), quase nenhum segmento de poligonal pode ser codificado como uma cadeia de bits e a estratégia proposta perderá sua principal vantagem. No caso de mapas dinâmicos existe um pouco mais de flexibilidade, onde o usuário pode definir certos parâmetros para sua apresentação tais como: os temas que serão incluídos, a escala, a localização e em alguns serviços até mesmo a simbologia a ser adotada. Os mapas podem ser gerados diretamente pelo SIG ou por um outro programa escrito especificamente para este propósito, denominado gerador de mapas. Esta arquitetura é mais adequada para usuários pouco capacitados e que queiram obter informações simples, tais como localizar um ponto em um mapa de ruas da cidade ou saber a distância aproximada entre dois locais para programar uma viagem. Um dos primeiros serviços a utilizar esta arquitetura foi disponibilizado em 1991 pelo U.S. Census Bureau denominado TIGER (TIGER,2000). Ele gera mapas temáticos de dados estatísticos do censo dos Estados Unidos. Outro pioneiro também nesta área foi o Map Server desenvolvido pelo Xerox PARC ( Palo Alto Research Center ) e disponibilizado em 1993 (Xerox,2000). O Socioeconomic Data and Application Center dos Estados Unidos possui também uma aplicação em HTML que tem como objetivo auxiliar os usuários a sintetizar e aplicar ciências naturais e dados socioeconômicos em suas pesquisas, atividades educacionais, análises e tomadas de decisão (SEDAC,2000). Esta aplicação utiliza um conjunto de formulários em HTML onde o usuário é capaz de selecionar parâmetros a respeito de seus dados de interesse. Ao receber os parâmetros 10

6 submetidos pelo usuário o servidor utiliza-os para gerar uma mapa em formato GIF que será enviado como resposta para ser visualizado pelo usuário. São enviados também arquivos de descrições e estatísticas, em formato previamente escolhido pelo usuário, para complementar o entendimento do mapa gerado. As Figuras 2.4 e 2.5 mostram respectivamente um formulário para seleção de alguns parâmetros do mapa e o resultado obtido. Figura 2.4 Formulário do SEDAC para visualização de mapas. 11

7 Figura 2.5 Mapa resultante no SEDAC. Nesta categoria de servidores remotos existem diversos outros serviços disponíveis na Internet. Uma das aplicações mais comuns é de localização de endereços já implantada em vários aglomerados metropolitanos espalhados pelo mundo. Como por exemplo o Street Finder para a área da Baía de São Francisco nos Estados Unidos (SF,2000). Seguindo a mesma linha existe também o MapQuest (MapQuest,2000) que é um guia de ruas dentro dos Estados Unidos que dentre seus serviços permite ao usuário localizar um determinado endereço e até mesmo calcular a distância entre dois endereços fornecidos. Este serviço também possui uma versão do tipo clientes de apresentação em JAVA que será abordada adiante. Outra aplicação também interessante é o How Far is It (HF,2000) que permite calcular a distância em linha reta entre duas localidades usando dados do US Census Bureau, e uma lista suplementar de cidades ao redor do mundo, encontrando então as coordenadas dos dois lugares, a distância entre eles e fornecendo uma mapa mostrando os 12

8 locais usando o Map Server da Xerox. A Figura 2.6 apresenta o resultado de uma pesquisa da distância entre São Paulo e Rio de Janeiro. Figura 2.6 Resultado da pesquisa de distâncias entre São Paulo e Rio de Janeiro no How Far is It. A Figura 2.7 apresenta um mapa mostrando as duas localidades em destaque com a cor vermelha para as localidades selecionadas. Este serviço é bastante interessante pelo fato de se utilizar de outros serviços já disponíveis para gerar os resultados solicitados pelo usuário. 13

9 Figura 2.7 Mapa Gerado pelo Map Server como resultado de uma pesquisa no How Far is It CLIENTES DE APRESENTAÇÃO Neste tipo de arquitetura todos os dados são transmitidos do servidor para o cliente. Esta transferência pode ser de forma imediata, ou seja, não é fornecida nenhuma opção ao cliente e os dados são transferidos assim que se estabelece a conexão cliente-servidor, ou opcional, onde o cliente tem a possibilidade de escolher o conjunto de dados com os quais deseja trabalhar. Com os dados já transferidos para o ambiente do cliente, podem ser disponibilizadas as operações sobre eles tais como busca por atributos, buscas espaciais, definição de zonas, classificação, mostrar mapas e até mesmo efetuar edição dos dados. 14

10 Nesta arquitetura para que o cliente tenha a capacidade de interação com os dados geográficos é necessária a utilização de um programa acoplado ao navegador ou um applet JAVA que efetue estas funções. O servidor, em grande parte dos casos, não necessita de funções especializadas ficando somente responsável pelo armazenamento e transmissões dos dados aos clientes. A Figura 2.8 apresenta os componentes básicos de uma arquitetura cliente de apresentação. CLIENTE Navegador + Applet ou+ Programa Acoplado Dados Geográficos Solicitação de Dados SERVIDOR Servidor HTTP Arquivos Figura 2.8 Componentes básicos de uma arquitetura de cliente de apresentação. Uma aplicação do tipo cliente de apresentação desenvolvida no INPE é o SpringWeb (Freitas,1997). No SpringWeb os dados são todos transferidos inicialmente para a máquina do cliente utilizando um arquivo no formato texto. Este arquivo especifica os elementos de apresentação do mapa tais como linhas, polígonos, imagens e seu conjunto de atributos. Ao 15

11 usuário é fornecida uma interface que possibilita a seleção dos elementos que ele deseja visualizar. Esta interface possui funções de zoom, vôo e seleção de dados para visualização de seus atributos. A Figura 2.9 apresenta a interface do SpringWeb para dados do projeto ProArco (INPE/DPI,2000 C ) que tem como objetivo apresentar focos de queimada na região amazônica. Figura 2.9 Interface do SpringWeb. O SpringWeb utiliza um formato próprio para armazenamento de seus dados. Isto exige que dados produzidos em SIGs comerciais necessitem de um processo de conversão antes que possam ser utilizados. 16

12 Um outro tipo de cliente de apresentação pode acessar diretamente dados em formatos já existentes produzidos por SIGs comerciais tais como o Java Spatial Data Viewer (SDV,2000) e o JAVA shpclient (shpclient,2000) que são capazes de visualizar arquivos do tipo Shapefiles da ESRI. O clientes de apresentação são muito utilizados em mapas turísticos interativos. Um exemplo deste tipo de aplicação é o Virtual NYC (2000) que permite navegar sobre um mapa da cidade de Nova York e realizar uma série de interações sobre ele. A Figura 2.10 apresenta uma das interfaces do Virtual NYC. Figura 2.10 Interface do Virtual NYC. 17

13 2.1.3 CLIENTE-SERVIDOR DE DADOS GEOGRÁFICOS Nesta arquitetura, tanto o cliente como o servidor possuem programas especializados que se comunicam trocando mensagens e dados geográficos. Esta arquitetura é mais versátil que os Servidores Remotos de Mapas e Clientes de Apresentação podendo incorporar funções realizadas por ambos, distribuindo de forma mais adequada à aplicação quais funções ficam no cliente e quais funções ficam no servidor. Este balanceamento de funções é a principal vantagem desta arquitetura em relação as outras. Um outra vantagem é a capacidade de estabelecer um protocolo entre o cliente e o servidor que minimize a transmissão desnecessária de dados geográficos entre ambos. Para algumas implementações, há necessidade de instalação prévia de um programa acoplado ao navegador. A transferência deste programa pela Internet pode ser demorada e sua instalação pode ser complexa para usuários menos especializados. Um exemplo desta arquitetura pode ser encontrado em Vianna (2000), que descreve uma implementação utilizando as tecnologias JAVA ( Applet/Servlet ) e COM para a visualização de dados geográficos. Muitos fornecedores de SIG tem trabalhado em versões de partes de seus sistemas para JAVA. As principais razões são o fato de JAVA ser uma linguagem independente de plataforma e poder se combinar facilmente com as tecnologias de Internet. Os aplicativos em JAVA podem ser desenvolvidos com a capacidade de interagir tanto com dados matriciais como vetoriais. Alguns fornecedores oferecem soluções completas e configuráveis para o cliente e servidor, como o caso da PGS (2000) ( Profissional Geo Systems ) que tem um visualizador de dados geográficos denominado Lava GIS Browser desenvolvido totalmente em JAVA. No lado do servidor a PGS oferece o Magma Geodata Publisher que é capaz de conectar um servidor de HTTP com vários repositórios de dados geográficos. 18

14 2.2 RESUMO Neste capítulo foram apresentadas as principais arquiteturas para disseminação de dados geográficos. Estas arquiteturas podem estar concentradas no lado cliente, no lado servidor, ou ser um híbrido entre ambas distribuindo as funções entre o cliente e o servidor. As arquiteturas Cliente-Servidor de Dados Geográficos possuem uma maior versatilidade e podem trazer vantagens nas suas implementações tais como permitir maior interatividade e capacidade de processamento utilizando os dados transferidos ao cliente. A Tabela 2.1 apresenta uma comparação entre as principais vantagens e desvantagens das arquiteturas apresentadas. Tabela Comparativo entre as características entre configurações do tipo Servidores Remotos de Mapas e Clientes de Apresentação. Tipos de Sistema Vantagens Desvantagens Servidor Remoto de Mapas Cliente de Apresentação Cliente- Servidor de Dados Geográficos Concentração de softwares e dados em uma única máquina. Mais fácil de controlar o acesso à informação. Mais fácil de manter a integridade e atualização dos dados. Os usuários podem ter acesso a bancos de dados complexos que seriam difíceis de manter em suas máquinas. Reduz a Quantidade de dados que devem ser transmitidos pela Internet. Melhor Distribuição das atividades que devem ser realizadas no cliente e no servidor. Melhor comunicação entre cliente e servidor. Maior interatividade por parte do usuário. 19 A cada atividade do cliente é necessário um tráfego pela rede. O servidor pode ficar sobrecarregado por muitas requisições simultâneas. As aplicações não se aproveitam da capacidade de processamento do cliente. A instalação inicial do software no a cliente pode levar muito tempo devido ao tamanho do programa. O lado cliente deve ter boa capacidade de processamento. As vezes é necessário a instalação prévia de um programa no cliente para possibilitar a conexão com o servidor.

15 Ao optar-se por um cliente-servidor com mais ou menos funcionalidade algumas funções vão migrando de um lado para outro do sistema. A Figura 2.11 mostra esta migração conforme se caminha no sentido de uma estratégia a outra. De maneira geral as funções de apresentação devem estar associadas ao cliente, utilizando um navegador de mercado, com ou sem um programa acoplado, ou um aplicativo dedicado a esta tarefa. A geração dos elementos para apresentação devem ficar no lado que tenha maior capacidade de armazenamento e processamento, que normalmente é o servidor. Menos Funcionalidade Cliente Mais Funcionalidade CLIENTE CLIENTE CLIENTE Visualização Visualização Visualização Interpretação Interpretação Interpretação Geração de Elementos para Visualização Geração de Elementos para Visualização Geração de Elementos para Visualização SERVIDOR SERVIDOR SERVIDOR Mais Funcionalidade Servidor Menos Funcionalidade Figura 2.11 Migração de funções para a arquitetura cliente-servidor. FONTE: Modificada de OpenGis Map Server Interface (OpenGis,2000 B ). No próximo capítulo será apresentada a arquitetura proposta por este trabalho. 20