ads:
Leonardo Lacerda Alves
Avalia¸c˜ao de Servi¸cos Web do Open
Geospatial Consortium para
Infra-estruturas de Dados Espaciais
Disserta¸c˜ao de Mestrado apresentada ao Pro-
grama de P´os-Gradua¸c˜ao em Inform´atica da
Pontif´ıcia Universidade Cat´olica de Minas
Gerais, como requisito parcial para a ob-
ten¸c˜ao do grau de Mestre em Inform´atica.
Belo Horizonte
Fevereiro de 2007
ads:
Livros Grátis
http://www.livrosgratis.com.br
Milhares de livros grátis para download.
Resumo
Interoperabilidade ´e um fator essencial para os sistemas de informa¸c˜ao geogr´aficos (SIG).
Nos ´ultimos anos, pesquisas e esfor¸cos para suportar interoperabilidade evolu´ıram da
troca offline de arquivos padronizados para a consolida¸c˜ao dos reposit´orios online de da-
dos espaciais, levando `as primeiras iniciativas de tratamento de aspectos semˆanticos de
dados geoespaciais. O Open Geospatial Consortium (OGC) tem proposto um conjunto de
padr˜oes com a inten¸c˜ao de promover interoperabilidade atrav´es do uso de servi¸cos. En-
tretanto, quest˜oes relacionadas com tolerˆancia a falhas, implementa¸c˜ao independente de
provedores, suporte a transa¸c˜oes demoradas e ass´ıncronas, privacidade e outras refletem
a necessidade de estudos e discuss˜oes adicionais. Esta pesquisa concentra-se na imple-
menta¸c˜ao de interoperabilidade atrav´es de servi¸cos e no papel das arquiteturas orientadas
a servi¸cos para a implementa¸c˜ao e difus˜ao das infra-estruturas de dados espaciais urbanas
(LSDI).
´
E apresentado um prot´otipo, o qual foi projetado para testar o modelo abstrato
de servi¸cos e informa¸c˜ao geogr´afica atrav´es da implementa¸c˜ao de um caso de uso real.
Como conclus˜ao, s˜ao indicados melhoramentos que mostram-se ´uteis para o desenvolvi-
mento de clientes de SIG e LSDI, para a comunica¸c˜ao entre servidores e clientes magros,
al´em de capazes de habilitar clientes a suportarem mecanismos de tolerˆancia a falhas sem
dependˆencia de provedores.
ads:
Abstract
Interoperability is one of the most important challenges related to GIS. Through the
last years, research on interoperability has evolved from the simple off-line exchange of
standardized-format files, through the establishment of spatial data clearinghouses, and
to the first initiatives in the treatment of semantic aspects of data. The Open Geospa-
tial Consortium (OGC) has proposed a numbe r of standards to that respect, with the
intention of promoting interoperability through the use of s ervices. However, issues re-
garding fault tolerance, server-independent implementation, delayed-time transactions,
privacy, and others reflec t the need for further study and discussion. This work discusses
the current status of service-oriented architectures as applied to interoperable GIS, or,
more specifically, to the implementation of local spatial data infrastructures (LSDI). A
prototype designed to test the services abstract model by simulating a real-world use case
is presented. Our conclusions indicate that some improvements may be helpful in the
development of GIS/LSDI clients, as well as in the communication between thin clients
and servers, supporting delayed-time transactions through asynchronous communication,
and enabling clients to support fault-tolerant mechanisms without provider-dependent
solutions.
ii
Mi dediˆcas ˆci tiun laboron por
Gepatroj kaj Fernanda
tiuj kiuj helpas min tra la vera vojo
iii
Agradecimentos
A participa¸c˜ao neste curso e a realiza¸c˜ao dos muitos trabalhos que esta disserta¸c˜ao sin-
tetiza deu-se com a ajuda de muitos, sem os quais meu esfor¸co seria maior e mais dif´ıcil.
Logo, deixo registrado meus agradecimentos:
• aos muitos deuses que colaboraram com este trabalho, em especial agrade¸co ao meu
Pai por ter aguardado com paciˆencia que eu conclu´ısse tais atividades.
• `a minha m˜ae, ao meu pai, meu irm˜ao Leonel e minha noiva Fernanda, os quais
doaram seu tempo e se abdicaram do meu tempo para eles, incondicionalmente.
• ao meu orientador, Prof. Dr. Clodoveu Augusto Davis Jr; com quem pude aprender
pelo exemplo de responsabilidade, prontid˜ao e diligˆencia.
• `a turma do doce de leite: Michelle, Anne, Jos´e Geraldo, Cristiano, Pedro, Sandro
e Wanderley. E aos colegas Fabr´ıcio, Gustavo, Sebasti˜ao, K´atia, Caroline, Cl´audio,
Marcelo, Uir´a, Reinaldo, Carlos e F´abio.
• `aqueles que foram me us professores durante o curso: Mark Alan, Ana Maria, Lucila
e S´ılvio Jamil. E `aqueles que contribu´ıram com inspiradoras conversas: Marcos
Andr´e Gon¸calves, Ricardo Poley e Marco T´ulio.
• `a Giovana e `a Priscila, da secretaria acadˆemica, por terem sido gentis e prontas para
nos ajudar.
• ao Pedro Felipe que participou dos nossos experimentos.
• ao pessoal do setor de inform´atica por terem dado suporte aos nossos trabalhos:
Marco Aur´elio, Leonardo Vilela, Bruno, Emanuel e Marcus Vin´ıcius.
• `as institui¸c˜oes que financiaram o meu curso: A Coordena¸c˜ao de Aperfei¸coamento
de Pessoal de N´ıvel Superior (CAPES), a Pontif´ıcia Universidade Cat´olica de Mi-
nas Gerais (PUC-MG) e a Funda¸c˜ao Comunit´aria de Ensino Superior de Itabira
(Funcesi).
iv
• `a banca da defesa de disserta¸c˜ao, a qual contribuiu para melhorar o meu trabalho e
foi constitu´ıda pelos professores: Jos´e Lu´ıs Braga, Marco T´ulio de Oliveira Valente
e Clodoveu Augusto Davis Jr.
• aos referees anˆonimos dos eventos Geoinfo 2005, Geoinfo 2006 e ACM GIS 2006,
pelas cr´ıticas essenciais.
• `as demais pessoas que torceram por mim.
v
Sum´ario
Lista de Figuras viii
Lista de Tabelas ix
1 Introdu¸c˜ao 1
1.1 Motiva¸c˜ao . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
1.2 Justificativa . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.3 Objetivo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.4 Metodologia . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.5 Estrutura . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
2 Trabalhos R elacionados 7
2.1 Interoperabilidade entre SIG . . . . . . . . . . . . . . . . . . . . . . . . . . 7
2.2 Reposit´orios de Informa¸c˜ao Geogr´afica . . . . . . . . . . . . . . . . . . . . 8
2.3 Geoportais . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
2.4 Infra-estruturas de Dados Espaciais . . . . . . . . . . . . . . . . . . . . . . 11
2.4.1 Infra-estruturas de Dados Espaciais de E scopo Urbano . . . . . . . 13
2.5 Servi¸cos Web . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
2.5.1 Padr˜oes da Ind´ustria para Servi¸cos Web . . . . . . . . . . . . . . . 16
2.5.2 Servi¸cos Web G eoespaciais . . . . . . . . . . . . . . . . . . . . . . . 17
3 Metodologia e Infra-estrutura de Avalia¸c˜ao 20
3.1 Cen´ario de Implementa¸c˜ao e Estudo de Caso . . . . . . . . . . . . . . . . . 20
3.2 Infra-estrutura de Dados Espaciais Urbanos . . . . . . . . . . . . . . . . . 22
3.2.1 Servi¸cos de Alto N´ıvel . . . . . . . . . . . . . . . . . . . . . . . . . 22
3.2.2 Implementa¸c˜ao 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
vi
3.2.3 Implementa¸c˜ao 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
3.2.4 Clientes para o Sistema de Informa¸c˜ao Geogr´afico . . . . . . . . . . 25
3.3 Servi¸cos Implementados . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
3.3.1 Servi¸cos OGC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
3.3.2 Servi¸cos N˜ao-OGC . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
3.3.3 Banco de Dados Geogr´afico . . . . . . . . . . . . . . . . . . . . . . 28
3.4 Limita¸c˜oes Identificadas . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
3.4.1 Requisitos N˜ao-Funcionais . . . . . . . . . . . . . . . . . . . . . . . 32
3.4.2 Transparˆencia de Acesso . . . . . . . . . . . . . . . . . . . . . . . . 34
3.4.3 Transparˆencia de Localiza¸c˜ao . . . . . . . . . . . . . . . . . . . . . 38
3.4.4 Transparˆencia de Migra¸c˜ao . . . . . . . . . . . . . . . . . . . . . . . 42
3.4.5 Transparˆencia de Reloca¸c˜ao . . . . . . . . . . . . . . . . . . . . . . 44
3.4.6 Transparˆencia de Replica¸c˜ao . . . . . . . . . . . . . . . . . . . . . . 46
3.4.7 Transparˆencia de Persistˆencia . . . . . . . . . . . . . . . . . . . . . 48
3.4.8 Transparˆencia de Falha . . . . . . . . . . . . . . . . . . . . . . . . . 50
3.4.9 Transparˆencia de Transa¸c˜ao . . . . . . . . . . . . . . . . . . . . . . 52
3.4.10 Avalia¸c˜ao: Transparˆencias no Desenvolvimento de Clientes . . . . . 54
4 Servi¸cos de Infra-estrutura Projetados 58
4.1 Data Exchange Service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
4.2 Client Access Service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
4.3 Transaction Control Service . . . . . . . . . . . . . . . . . . . . . . . . . . 64
4.4 Implementa¸c˜ao 3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68
4.5 Avalia¸c˜ao . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69
5 Conclus˜oes 72
5.1 Resultados . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73
5.2 Principais Contribui¸c˜oes . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74
5.3 Trabalhos Futuros . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76
Referˆencias 78
A Transaction Control Service 85
A.1 Entrada . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85
vii
A.2 Formato em XML Schema . . . . . . . . . . . . . . . . . . . . . . . . . . . 88
A.3 Transformador . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89
B Esquemas de Servi¸cos Web Geoespaciais 92
B.1 WSDL Geocoder n˜ao-padr˜ao . . . . . . . . . . . . . . . . . . . . . . . . . . 92
B.2 WSDL Directory n˜ao-padr˜ao . . . . . . . . . . . . . . . . . . . . . . . . . . 95
B.3 WSDL WFS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98
B.4 WSDL WMS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101
B.5 Schema Route n˜ao-padr˜ao . . . . . . . . . . . . . . . . . . . . . . . . . . . 102
viii
Lista de Figuras
2.1 Geoportais como componentes de SDI [DA05] . . . . . . . . . . . . . . . . 10
2.2 A vis˜ao “Blocos de Montar” das SDI [RWHJ00] . . . . . . . . . . . . . . . 13
2.3 Modelo conceitual de servi¸cos [DA07] . . . . . . . . . . . . . . . . . . . . . 15
3.1 Amostra de resultado do processamento de uma consulta . . . . . . . . . . 22
3.2 Distribui¸c˜ao f´ısica dos servi¸cos implementados . . . . . . . . . . . . . . . . 23
3.3 Implementa¸c˜ao 1, onde h´a a intermedia¸c˜ao de um provedor . . . . . . . . . 24
3.4 Implementa¸c˜ao 2, onde o cliente acessa diretamente os servi¸cos alvo . . . . 25
3.5 Modelo OMT-G do banco de dados geogr´aficos usado . . . . . . . . . . . . 29
4.1 Uso do Data Exchange Service na Invoca¸c˜ao de um Servi¸co Replicado [AD06] 59
4.2 Diagrama de Seq¨uˆencia em UML para um Sistema com DXS [AD06] . . . . 60
4.3 Cliente sem um Endere¸co IP V´alido usando Comunica¸c˜ao baseada em
HTTP [AD06] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
4.4 Cliente com um Endere¸co IP V´alido usando Comunica¸c˜ao baseada em
HTTP [AD06] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
4.5 Cliente sem um Endere¸co IP V´alido usando um Gateway como Mediador
[AD06] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
4.6 Implementa¸c˜ao 3, onde o cliente acessa diretamente os servi¸cos-alvo mas
adota um DXS para armazenamento tempor´ario . . . . . . . . . . . . . . . 70
ix
Lista de Tabelas
3.1 RNF da transparˆencia de acesso e t´ecnicas de satisfa¸c˜ao . . . . . . . . . . . 35
3.2 RNF da transparˆencia de localiza¸c˜ao e t´ecnicas de satisfa¸c˜ao . . . . . . . . 40
3.3 RNF da transparˆencia de migra¸c˜ao e t´ecnicas de satisfa¸c˜ao . . . . . . . . . 42
3.4 RNF da transparˆencia de reloca¸c˜ao e t´ecnicas de satisfa¸c˜ao . . . . . . . . . 44
3.5 RNF da transparˆencia de replica¸c˜ao e t´ecnicas de satisfa¸c˜ao . . . . . . . . 47
3.6 RNF da transparˆencia de persistˆencia e t´ecnicas de satisfa¸c˜ao . . . . . . . 49
3.7 RNF da transparˆencia de falha e t´ecnicas de satisfa¸c˜ao . . . . . . . . . . . 51
3.8 RNF da transparˆencia de transa¸c˜ao e t´ecnicas de satisfa¸c˜ao . . . . . . . . . 53
1
Cap´ıtulo 1
Introdu¸c˜ao
Sistemas de Informa¸c˜ao Geogr´aficos (SIG) s˜ao sistemas para coleta, edi¸c˜ao, armazena-
mento, an´alise, gerenciamento e integra¸c˜ao de dados com atributos associados a alguma
localiza¸c˜ao na Terra. S˜ao constitu´ıdos basicamente por equipamentos (hardware), progra-
mas de computador (software), t´ecnicas e pessoas, os quais s˜ao usados como instrumento
de apoio a decis˜ao em governos, empresas, pesquisas cient´ıficas e, atualmente, at´e mesmo
em atividades pessoais ou dom´esticas [CCD
+
05].
A tecnologia de SIG beneficia in´umeras aplica¸c˜oes, que passam pelo controle de tr´afego
em cidades e rodovias, redu¸c˜ao do custo de log´ıstica de produtos, sistemas de roteamento
em ve´ıculos particulares, at´e o controle efetivo de ´areas de plantio e preserva¸c˜ao ambiental.
Al´em destas, SIG tˆem sido usados tamb´em para estimular a participa¸c˜ao de cidad˜aos
comuns na administra¸c˜ao municipal [Gho01].
1.1 Motiva¸c˜ao
Como sistemas de computa¸c˜ao, SIG s˜ao acess´ıveis atrav´es de aparelhos comuns tais
como computadores pessoais, celulares e PDAs (Personal Digital Assistants), bem como
atrav´es de dispositivos espec´ıficos, tais como navegadores GPS
1
, os quais tˆem se tornado
populares em pa´ıses desenvolvidos e em grandes centros urbanos. O acesso a esses sistemas
atrav´es de computadores pessoais tem se popularizado atrav´es de softwares cada vez mais
amig´aveis, como o Google Earth, e sites Web tais como Google Maps
2
, Yahoo Maps
3
e
MapLink
4
.
1
GPS ´e sigla de Global Positioning System, um sistema de loc aliza¸c˜ao mundial que usa referˆencias de
uma constela¸c˜ao de sat´elites artificiais para determinar posi¸c˜oes na superf´ıcie terrestre.
2
URL: maps.google.com/
3
URL: maps.yahoo.com/
4
URL: maplink.uol.com.br/
CAP´ıTULO 1. INTRODUC¸
˜
AO 2
De fato, aplica¸c˜oes de SIG s˜ao crescentes na medida em que dados geogr´aficos tornam-
se dispon´ıveis e novas tecnologias s˜ao difundidas para melhorar a forma de aquisi¸c˜ao,
processamento, an´alise e sa´ıda de informa¸c˜ao geogr´afica [AD07]. Conseq¨uentemente, as
dificuldades atuais para implementa¸c˜ao, gerenciamento, distribui¸c˜ao e uso amplos de SIG
n˜ao favorecem a disponibilidade de informa¸c˜ao e aplica¸c˜oes e portanto s˜ao lacunas impor-
tantes para pesquisas na ´area de geoinform´atica.
1.2 Justificativa
Apesar da significativa oferta de informa¸c˜ao geogr´afica atualmente, boa parte dos
fenˆomenos de interesse para as aplica¸c˜oes ´e dinˆamica, ou seja, mudam com tal freq¨uˆencia
que seus dados precisam ser constantemente atualizados e coletados novamente. Isso
ocorre com especial ˆenfase em espa¸cos urbanos, os quais crescem continuamente, tˆem sua
organiza¸c˜ao f´ısica alterada e sofrem a influˆencia de diversas a¸c˜oes causadoras de mudan¸cas,
tais como a legisla¸c˜ao de uso e ocupa¸c˜ao do solo, as regras de circula¸c˜ao de ve´ıculos, a
distribui¸c˜ao de atividades econˆomicas e outras.
´
E evidente que a atualiza¸c˜ao de dados
sobre fenˆomenos com tais caracter´ısticas ´e algo trabalhoso e custoso.
Freq¨uentemente, a necessidade de informa¸c˜ao desse tipo ´e compartilhada por mais de
uma organiza¸c˜ao, o que possibilita o compartilhamento dos dados coletados e minimiza
custos relativos a atividades redundantes de coleta, tratamento do dado geoespacial e
at´e mesmo seu armazenamento [DA05]. No entanto, esse potencial para a colabora¸c˜ao
por meio do compartilhamento de dados ´e muitas vezes prejudicado pela e xistˆencia de
diferentes formas de modelar o racioc´ınio geogr´afico sobre o mesmo espa¸co, ou seja, um in-
div´ıduo pode modelar residˆencias como pontos, enquanto outro as define como pol´ıgonos.
Essa aparente incompatibilidade entre alternativas de representa¸c˜ao poderia ser resolvida
atrav´es de iniciativas de padroniza¸c˜ao em que a representa¸c˜ao mais detalhada fosse ado-
tada. Em muitos casos, a convers˜ao de uma representa¸c˜ao com mais detalhes para outra
com menos detalhes ´e poss´ıvel, mas o contr´ario n˜ao ´e igualmente poss´ıvel [DL99]. Assim,
uma vez que a representa¸c˜ao computacional de um objeto ou fenˆomeno ´e uma simpli-
fica¸c˜ao do fenˆomeno geogr´afico real, certos detalhes s˜ao perdidos na representa¸c˜ao e n˜ao
podem ser inferidos a partir do dado geogr´afico j´a coletado, o que aumenta a responsa-
bilidade da coordena¸c˜ao de esfor¸cos de coopera¸c˜ao entre institui¸c˜oes para garantir que
um dado geogr´afico compartilhado seja ´util para todos os participantes. Por outro lado,
n˜ao ´e vi´avel fazer com que todo dado seja coletado com um n´ıvel de detalhamento muito
grande, p elo alto custo de implementa¸c˜ao, dificuldades de manuten¸c˜ao e pelo fato de n˜ao
ser simples antecipar necessidades futuras dos usu´arios.
CAP´ıTULO 1. INTRODUC¸
˜
AO 3
Neste contexto, ´e do interesse de todos os participantes de uma iniciativa de com-
partilhamento de dados geogr´aficos que exista compatibilidade tecnol´ogica e semˆantica
entre os dados provenientes das diferentes institui¸c˜oes envolvidas. A parcela tecnol´ogica
da quest˜ao, apesar de ter sido mais intensivamente estudada, ainda causa muitos pro-
blemas, pois as institui¸c˜oes usam diferentes softwares, tecnologias de bancos de dados
e sistemas de referˆencia geogr´afica, diferen¸cas estas sempre muito comuns. A parcela
semˆantica ainda est´a sendo investigada, n˜ao existindo at´e o momento uma solu¸c˜ao defi-
nitiva [FM05]. A e ssa capacidade de funcionamento interdependente, colaborativo e com
trocas transparentes de dados denominamos interoperabilidade.
Uma das iniciativas mais recentes de promover interoperabilidade foi coordenada pelo
Open Geospatial Consortium (OGC), o qual tem proposto padr˜oes para o uso de servi¸cos
no compartilhamento de informa¸c˜ao geogr´afica [Per03]. No entanto, a defini¸c˜ao e espe-
cifica¸c˜ao original do OGC de servi¸cos para acesso a informa¸c˜ao geoespacial antecedem e
diferem da defini¸c˜ao e especifica¸c˜ao de servi¸cos Web desenvolvida pelo World Wide Web
Consortium (W3C) [Whi05]. Logo, alcan¸car a interoperabilidade efetiva entre SIG e ou-
tros sistemas n˜ao geogr´aficos por meio do uso de servi¸cos em rede depende de ajustes
entre as propostas do OGC e do W3C, os quais est˜ao em andamento [Son04].
Enquanto esses ajustes n˜ao s˜ao completados, observam-se dificuldades quando se busca
implementar interoperabilidade atrav´es de servi¸cos. Quest˜oes tais como baixa tolerˆancia
a falhas, dependˆencia de provedores de servi¸cos geogr´aficos, dificuldade de execu¸c˜ao de
tarefas demoradas, ausˆencia de parˆametros de privacidade e outras refletem a necessidade
de mais estudos e discuss˜oes.
A existˆencia dos padr˜oes OGC indica um grande p otencial para o desenvolvimento de
sistemas de informa¸c˜ao geogr´aficos de perfil bem dife rente dos atuais sistemas monol´ıticos.
Torna-se poss´ıvel conceber SIG interoper´aveis e distribu´ıdos em rede, constitu´ıdos de
m´odulos altamente especializados e fracamente acoplados. No entanto, s˜ao escassos os
estudos sobre o desenvolvimento de sistemas distribu´ıdos em conformidade com os padr˜oes
da OGC [SKK06]. Apesar da significativa disponibilidade de servi¸cos OGC para fins de
distribui¸c˜ao de dados de escala nacional ou regional em muitos pa´ıses do mundo [Ref06], e
da correspondente – ou latente – demanda de clientes para esses servi¸cos, n˜ao se conhece
a disponibilidade de servi¸cos espec´ıficos para regi˜oes geograficamente menores, tais como
estados e cidades.
CAP´ıTULO 1. INTRODUC¸
˜
AO 4
1.3 Objetivo
Esta pesquisa concentra-se na implementa¸c˜ao de interoperabilidade atrav´es de servi¸cos
e no papel das arquiteturas orientadas a servi¸cos para a implementa¸c˜ao e difus˜ao das infra-
estruturas de dados espaciais urbanas (LSDI, do inglˆes Local Spatial Data Infrastructures).
A maioria das infra-estruturas de dados espaciais (SDI, do inglˆes Spatial Data In-
frastructures) atualmente conhecidas, como, por exemplo, o projeto “Infrastructure for
Spatial Information in Europe” (INSPIRE) da Comunidade Europ´eia e o National Spatial
Data Infrastructure (NSDI), dos Estados Unidos, referem-se a dados de escopo continental
ou nacional, mas as LSDI contˆem conjuntos potencialmente mais complexos e detalha-
dos de dados geogr´aficos [NBFRW04, RWHJ00, AD06], e portanto envolvem um n´umero
maior de tipos de servi¸cos, os quais podem ser usados atrav´es de dispositivos diversos,
tais como PDAs, telefones celulares e computadores pessoais.
Assim, o objetivo deste trabalho ´e investigar a adequa¸c˜ao dos padr˜oes OGC para a im-
plementa¸c˜ao de (1) sistemas de informa¸c˜ao geogr´aficos baseados em dados compartilhados
em rede, (2) infra-estruturas de dados es paciais de ˆambito local, e (3) softwares-cliente
para tais SIG e LSDI.
Os objetivos espec´ıficos deste trabalho incluem:
• Implementar um prot´otipo de SDI e SIG interoper´aveis, com informa¸c˜oes de uma
regi˜ao metropolitana, de acordo com as especifica¸c˜oes da OGC;
• Avaliar a adequa¸c˜ao da arquitetura orientada a servi¸cos proposta pela OGC para a
implementa¸c˜ao de servi¸cos geogr´aficos no contexto de aplica¸c˜oes urbanas reais;
• Investigar se h´a requisitos da OGC que n˜ao podem ser facilmente atendidos no de-
senvolvimento de softwares-cliente, considerando o interesse de manter tais clientes
independentes da SDI desenvolvida e de dispor de clientes destinados para diferentes
tipos de dispositivos de acesso a servi¸cos geogr´aficos, tais como PDAs, celulares e
computadores pessoais comuns.
1.4 Metodologia
A avalia¸c˜ao de adequa¸c˜ao e conformidade dos padr˜oes OGC com as tecnologias de
desenvolvimento de softwares-cliente de SIG para diferentes LSDI deu-se por meio de
uma prova de conceito, constru´ıda em quatro fases interdependentes:
1. Revis˜ao da literatura
CAP´ıTULO 1. INTRODUC¸
˜
AO 5
2. Defini¸c˜ao de um cen´ario de implementa¸c˜ao
Foi definido um cen´ario baseado em um contexto urbano, com dados reais da cidade
de Belo Horizonte, Minas Gerais, e com necessidades reais de usu´arios. Foi utilizado
um cen´ario preliminar definido no Modelo de Referˆencia da OGC (ORM, do inglˆes
OGC Reference Model) [Per03] denominado Consumer Travel Assistance Scenario.
3. Desenvolvimento de Prot´otipo
Foi desenvolvido um prot´otipo composto por servi¸cos da arquitetura OWS (OGC
Web Services), um provedor de servi¸cos que integra os servi¸cos Web da OGC e
clientes para estes servi¸cos, todos em conformidade com o modelo abstrato proposto
pela OGC (OGC Abstract Model). O prot´otipo foi confrontado com os requisitos
e as diferentes perspectivas definidas no ORM. Os clientes s˜ao dois: um que usa o
provedor de servi¸cos diretamente e os servi¸cos Web da OGC indiretamente, e outro
que usa os servi¸cos Web da OGC diretamente, sem usar o provedor de servi¸cos como
intermedi´ario.
4. Especializa¸c˜ao da Arquitetura OWS (OGC Web Services)
Para sanar as limita¸c˜oes identificadas, f oram desenvolvidos servi¸cos de infra-estrutu-
ra complementares e tamb´em foram implementados outros servi¸cos da OGC , em um
modelo de processo em espiral. Usando tais servi¸cos, foi implementada uma nova
vers˜ao do prot´otipo para assegurar que as limita¸c˜oes observadas foram sanadas.
1.5 Estrutura
Este trabalho est´a organizado em cinco cap´ıtulos.
O Cap´ıtulo 2 apresenta conceitos fundamentais sobre SIG, trabalhos relacionados `a
interoperabilidade entre SIG, sobre Infra-estruturas de Dados Espaciais (SDI) em geral,
e Infra-estruturas de Dados Espaciais Locais (LSDI) em particular, o que inclui as id´eias
de implementa¸c˜ao e configura¸c˜ao de tais infra-estruturas por meio de servi¸cos Web.
O Cap´ıtulo 3 organiza os requisitos e aspectos mais importantes dos servi¸cos Web
geoespaciais especificados pela OGC e do prot´otipo de SIG desenvolvido. Os requi-
sitos n˜ao-funcionais selecionados s˜ao introduzidos no desenvolvimento dos servi¸cos de
infra-estrutura e dos softwares-cliente. Finalmente, s˜ao identificadas e apresentadas as
limita¸c˜oes dos servi¸cos e softwares-cliente no que se refere aos requisitos n˜ao-funcionais
propostos pela OGC no ORM.
No Cap´ıtulo 4, s˜ao discutidas as funcionalidades requeridas para uma LSDI que n˜ao s˜ao
atendidas pelos servi¸cos propostos no arcabou¸co OWS. Estas funcionalidades s˜ao apresen-
CAP´ıTULO 1. INTRODUC¸
˜
AO 6
tadas atrav´es de novos servi¸cos de inf ra-estrutura que resolvem as limita¸c˜oes identificadas
no cap´ıtulo 3.
No Cap´ıtulo 5, s˜ao apresentados os principais resultados e contribui¸c˜oes deste trabalho,
e indicadas algumas dire¸c˜oes de pesquisas futuras.
Finalmente, s˜ao apresentadas as referˆencias bibliogr´aficas e o apˆendice, este dividido
em duas partes. A primeira parte do apˆendice re´une interfaces e formatos dos servi¸cos
OGC modificados neste trabalho, enquanto a segunda parte exp˜oe documentos de amos-
tra, especifica¸c˜ao de formato e regras de transforma¸c˜ao do servi¸co Transaction Control
Service.
7
Cap´ıtulo 2
Trabalhos Relacionados
2.1 Interoperabilidade entre SIG
Organiza¸c˜oes com necessidade de compartilhar informa¸c˜ao geogr´afica normalmente
dependem de ferramentas e t´ecnicas de tradu¸c˜ao de dados. Isso deve-se ao fato de que
cada organiza¸c˜ao potencialmente usa um software diferente para seu SIG [DA05]. No
passado houve esfor¸cos para estabelecer um formato ne utro de arquivo com o intuito de
favorecer o intercˆambio de dados geogr´aficos. Desta forma, a necessidade de tradu¸c˜ao
de dados entre formatos se restringiria apenas a convers˜oes bidirecionais entre qualquer
formato e aquele formato intermedi´ario [LCdQ01].
Por´em, essa t´ecnica limita-se a aspectos sint´aticos e pode apresentar dificuldades de
compatibiliza¸c˜ao semˆantica dos dados.
´
E poss´ıvel que tais formatos neutros n˜ao tenham
se popularizado exatamente por este motivo, embora um n´umero significativo de tradu-
tores tenham sido desenvolvidos e difundidos entre usu´arios de geoinforma¸c˜ao, alguns
utilizando-se de formatos intermedi´arios enquanto outros convertendo dados diretamente
entre formatos propriet´arios.
Adicionalmente, o uso de tradu¸c˜ao n˜ao adaptou-se facilmente ao ambiente online, pois
manteve a necessidade da opera¸c˜ao offline (exportar-converter-importar). Conseq¨uente-
mente, problemas de sincroniza¸c˜ao tornam-se comuns, uma vez que m´ultiplas c´opias do
mesmo dado s˜ao distribu´ıdas em momentos diferentes, com dif´ıcil controle de r´eplicas e
alto custo de armazenamento [DA05].
De fato, apenas formatos de troca definidos por for¸ca de lei ou regulamenta¸c˜oes go-
vernamentais foram mais usados neste processo de tradu¸c˜ao de dados. Um exemplo ´e
o SDTS (Spatial Data Transfer Standard) nos EUA [Uni98]. Mas, na pr´atica, esse pro-
cesso acontece segundo pr´aticas difundidas na comunidade da ferramenta de SIG onde o
usu´ario se encontra, onde alguns poucos formatos tornam-se mais comuns que outros e
CAP´ıTULO 2. TRABALHOS RELACIONADOS 8
onde as limita¸c˜oes da tradu¸c˜ao entre formatos e as principais t´ecnicas para san´a-las s˜ao
bem conhecidas [ LCdQ02].
No entanto, al´em dos aspectos t´ecnicos relacionados `a troca de arquivos, muitos outros
aspectos s˜ao importantes para estabelecer o intercˆambio efetivo de informa¸c˜ao geogr´afica
entre sistemas de informa¸c˜ao vistos como sistemas s´ocio-t´ecnicos. Estes aspectos incluem
pol´ıticas de uso da informa¸c˜ao e direitos sobre a mesma, proce dimentos comuns de dispo-
nibiliza¸c˜ao, atualiza¸c˜ao e transferˆencia de dados, defini¸c˜oes sobre quais dados s˜ao b´asicos
e como extens˜oes s˜ao gerenciadas entre a comunidade de usu´arios, al´em de outros [DF06].
Todo este conjunto de aspectos s´ocio-t´ecnicos constitui um acordo de coopera¸c˜ao entre
usu´arios – institui¸c˜oes e pessoas – que objetivam compartilhar dados e contribuir entre
si, onde especialidades e interesses definem responsabilidades sobre a atualiza¸c˜ao da in-
forma¸c˜ao compartilhada. Por´em, o cerne desses acordos de coopera¸c˜ao s˜ao as pol´ıticas,
procedimentos e regras de dissemina¸c˜ao da informa¸c˜ao entre os participantes, o que deter-
mina caracter´ısticas sempre muito pr´oprias para cada grupo de participantes [FCOM06].
No entanto, diferentemente das infra-estruturas de dados espaciais, as quais ser˜ao
tratadas na se¸c˜ao
2.4, os acordos de coopera¸c˜ao possuem em comum a necessidade de um
controle centralizado sobre as pol´ıticas ao mesmo tempo em que apresentam um controle
descentralizado sobre a informa¸c˜ao, onde cada participante tem controle sobre um grupo
espec´ıfico de dados, e cada qual atribui aos dados apenas aquilo que se mostra conveniente
aos seus objetivos particulares. Conseq¨uentemente, isso exige que os usu´arios se adaptem
`as necessidades do propriet´ario dos dados, e n˜ao que os dados se adaptem `as necessidades
dos participantes [DF06].
Com o prop´osito de reduzir o atraso entre a produ¸c˜ao da informa¸c˜ao por um partici-
pante do acordo de coopera¸c˜ao e sua dissemina¸c˜ao para todos os outros participantes, os
reposit´orios e geoportais s˜ao mecanismos t´ecnicos importantes. Mas para a necessidade
de abstra¸c˜ao da informa¸c˜ao geogr´afica e atendimento dos interesses de m´ultiplos usu´arios
com diferentes prop´ositos, as infra-estruturas de dados espaciais constituem um avan¸co.
2.2 Reposit´orios de Informa¸c˜ao Geogr´afica
A partir dos recursos tecnol´ogicos citados e do estabelecimento de acordos de coo-
pera¸c˜ao, muitas agˆencias nacionais de mapeamento criaram reposit´orios de informa¸c˜ao
geogr´afica. Esses reposit´orios s˜ao componentes voltados para a Internet que facilitam
o acesso aos dados geoespaciais, concentrando-os em um ´unico local, onde dados de di-
versas fontes podem ser encontrados. Esses reposit´orios tamb´em oferecem servi¸cos para
pesquisa, visualiza¸c˜ao e organiza¸c˜ao de dados espaciais [CBRW04], e dessa forma permi-
CAP´ıTULO 2. TRABALHOS RELACIONADOS 9
tem que provedores de dados tornem seus dados dispon´ıveis e conhecidos aos usu´arios,
atrav´es de descri¸c˜oes sobre os dados (metadados) e instru¸c˜oes sobre como acess´a-los e
us´a-los.
De acordo com Crompvoets et al [CBRW04], h´a diferentes defini¸c˜oes para o que ´e
um reposit´orio de informa¸c˜ao geogr´afica. Mais recentemente, tais reposit´orios tˆem sido
descritos de forma similar ao conceito de portais Web, e definidos como um local onde
servi¸cos s˜ao divulgados ou atrav´es do qual esses servi¸cos s˜ao acessados [INS02]. A ˆenfase
em servi¸cos ´e recente se comparada a defini¸c˜oes anteriores, baseadas na combina¸c˜ao entre
ferramentas t´ecnicas, mecanismos de coopera¸c˜ao interinstitucional e quest˜oes comerciais
[FGD97].
O primeiro reposit´orio de informa¸c˜ao geogr´afica conhecido foi criado pelo Comitˆe Fe-
deral de Dados Geogr´aficos (FGDC, do inglˆes Federal Geographic Data Committee), em
1994 nos EUA [DA05]. Esta iniciativa tinha o objetivo de principalmente reduzir esfor¸cos
redundantes na coleta de dados. Mais tarde, no Brasil, a primeira fonte de dados espa-
ciais publicamente dispon´ıveis na Internet tornou-se operacional: o projeto GeoMinas
1
[DA05]. O GeoMinas consolidou um grande trabalho de descoberta, cataloga¸c˜ao, preparo
e dissemina¸c˜ao de dados usados no estado de Minas Gerais [DA06]. Seus grupos tem´aticos
discutiram a cria¸c˜ao de um cat´alogo distribu´ıdo de metadados, um formato de intercˆambio
de dados, o conte´udo de um mapa-base do estado, e pesquisas sobre meios tecnol´ogicos
adicionais para dissemina¸c˜ao de informa¸c˜ao, incluindo SIG baseados na Web, ainda na
primeira metade da d´ecada de 1990.
Exemplos de reposit´orios de informa¸c˜ao geogr´afica em outros pa´ıses do mundo s˜ao
o National Geospatial Data Clearinghouse (EUA)
2
, GIgateway (Reino Unido)
3
, Natio-
naal Clearinghouse Geo-Informatie (Holanda)
4
, e o Australian Spatial Data Directory
(Austr´alia)
5
. Entretanto, entre 67 reposit´orios analisados e comparados entre si por
Crompvoets et al (2004) [ CB RW04], foi percebida a existˆencia de uma insatisfa¸c˜ao cres-
cente entre usu´arios desse tipo de servi¸co em rela¸c˜ao `as suas funcionalidades. Esse estudo
ent˜ao indicou que o foco deveria mudar de uma vis˜ao orientada a dados para uma vis˜ao
orientada aos usu´arios e aplica¸c˜oes, algo que pode ser alcan¸cado pelo uso de arquiteturas
orientadas a servi¸cos em infra-estruturas de dados espaciais [BC05, DA05].
1
URL: http://www.geominas.mg.gov.br/
2
URL: http://fgdc.ftw.nrcs.usda.gov/
3
URL: http://www.gigateway.org.uk/
4
URL: http://www.ncgi.nl/
5
URL: http://asdd.ga.gov.au/
CAP´ıTULO 2. TRABALHOS RELACIONADOS 10
2.3 Geoportais
A palavra portal tem sido usada nos ´ultimos anos com o significado geral de um “ponto
de entrada” para informa¸c˜ao e servi¸cos dispon´ıveis na Web, isto ´e, um Web site atrav´es
do qual outros sites s˜ao encontrados. Portais s˜ao cole¸c˜oes organizadas ou referˆencias a
´ıtens de interesse dos usu´arios. Aplicando este conceito a geoinforma¸c˜ao, um geoportal ´e,
portanto, um “Web-site que apresenta-se como ponto de entrada para conte´udo geogr´afico
na Web” [Tai05]. As funcionalidades de interesse dos geoportais incluem (1) descoberta
de fontes de informa¸c˜ao e cont´eudo, e (2) acesso on-line a aplica¸c˜oes.
Exemplos de geoportais existentes s˜ao o Geospatial One-Stop nos EUA, o National
Geospatial Data Framework [BLM05] e o MultiAgency Geographic Information for the
Countryside (MAGIC) [AEMS05], ambos do Reino Unido, e o EU-Geoportal, este como
parte do proj eto INSPIRE (Infrastructure for Spatial Information in Europe) [INS02].
Figura 2.1: Geoportais como componentes de SDI [DA05]
Como geoportais s˜ao normalmente associados a uma ou mais infra-estruturas de da-
dos espaciais, ´e importante estabelecer uma distin¸c˜ao de conceitos. Considera-se que uma
SDI ´e formada pela confluˆencia de diversos provedores de dados geogr´aficos, cada qual
garantindo acesso a dados atrav´es de servi¸cos Web espec´ıficos [Wor04]. Para selecionar
quais dados e, como conseq¨uˆencia, quais servi¸cos devem ser acessados para atender a uma
CAP´ıTULO 2. TRABALHOS RELACIONADOS 11
necessidade, o usu´ario busca por dados e servi¸cos geogr´aficos em um reposit´orio. Natural-
mente, os provedores de tais dados e servi¸cos necessitam ter metadados correspondentes
previamente inclu´ıdos neste reposit´orio. No caso de um usu´ario humano, pesquisas s˜ao
feitas interativamente atrav´es de um geoportal, possivelmente usando interfaces de pes-
quisa e outras ferramentas interativas; no caso de um software-cliente, isto pode ser feito
atrav´es de um servi¸co Web de cat´alogo. Portanto, geoportais podem ser considerados
componentes de uma SDI, o que ´e ilustrado na figura 2.1.
2.4 Infra-estruturas de Dados Espaciais
Infra-estruturas de Dados Espaciais (SDI, do inglˆes Spatial Data Infrastructures) cons-
tituem um conjunto de pol´ıticas, tecnologias e padr˜oes que relacionam uma comunidade
de usu´arios de geoinforma¸c˜ao e atividades de suporte para produ¸c˜ao e gerenciamento de
informa¸c˜ao geogr´afica [PWE99]. A id´eia por tr´as das SDI envolve eliminar esfor¸cos re-
dundantes e reduzir custos de produ¸c˜ao atrav´es do compartilhamento de recursos, tanto
relacionados a dados novos quanto a dados existentes. Para atender a esse prop´osito, ´e
muito importante que v´arios parceiros, tendo interesses comuns, aceitem regras e sejam
autorizados a fazer uso de dados ou informa¸c˜ao produzidos por outros [CFRW01].
De acordo com Maguire e Longley [ML05], a express˜ao “infra-estrutura de dados
espaciais” foi proposta pelo Mapping Sciences Committee do National Research Council
dos EUA em 1993. Ela f oi usada inicialmente para descrever o provimento de acesso
padronizado a informa¸c˜ao geogr´afica, mas muito do debate sobre o conceito reflete o
conte´udo ideal de uma SDI nacional (ou National SDI, NSDI, que ´e tamb´em a sigla da
National Spatial Data Infrastructure norte-americana, criada em 1994).
Muitas iniciativas de cria¸c˜ao de reposit´orios de informa¸c˜ao geogr´afica evolu´ıram para
o que Masser [Mas99] chama de “primeira gera¸c˜ao de infra-estruturas de dados espaciais”,
ao mesmo tempo em que observa que o uso do termo “infra-estrutura” indica a existˆencia
de alguma coordena¸c˜ao para formula¸c˜ao e implementa¸c˜ao de pol´ıticas. Exemplos incluem
a Australian SDI da Austr´alia
6
, a Canadian Geospatial Data Infrastructure do Canad´a
7
,
o Sistema Nacional de Informa¸c˜ao Geogr´afica de Portugal
8
e a National Spatial Data
Infrastructure dos EUA
9
.
A primeira gera¸c˜ao de SDI concentra-se em garantir um escopo tem´atico amplo, o
que est´a de acordo com os objetivos que permitem uma analogia entre SDI e outros tipos
6
URL: http://www.ga.gov.au/nmd/asdi/
7
URL: http://www.geoconnections.org/
8
URL: http://snig.igeo.pt/
9
URL: http://www.fgdc.gov/nsdi/nsdi.html
CAP´ıTULO 2. TRABALHOS RELACIONADOS 12
de infra-estrutura, particularmente o objetivo de financiar o desenvolvimento econˆomico
atrav´es da garantia do acesso a produtos e se rvi¸cos publicamente dispon´ıveis e de m´ultiplos
usos. “Publicamente dispon´ıveis” n˜ao significa “suportado pelo governo”, o que implica
que servi¸cos em uma SDI podem, indistintamente, ser providos pelo governo, pela ini-
ciativa privada ou at´e mesmo por cidad˜aos, e portanto podem ser suportados atrav´es
de taxas, por algum fundo governamental ou por outros tipos de arranjos econˆomicos.
Apesar das SDI serem condutoras de desenvolvimento econˆomico, algumas das iniciativas
analisadas por Masser [Mas99] n˜ao garantem acesso ao setor privado, ou o fazem pela co-
bran¸ca de uma taxa de uso como meio de recuperar algum ou todos os custos de cria¸c˜ao e
dissemina¸c˜ao de dados. Por outro lado, existe um requisito legal americano que determina
que os dados de suas agˆencias sejam gratuitos para o p´ublico.
Muitas li¸c˜oes foram aprendidas na primeira gera¸c˜ao de SDI. Como Maguire e Longley
[ML05] observam, nos EUA o foco foi predominantemente t´ecnico, como resultado do
controle centralizado do USGS (United States Geological Survey, Servi¸co Geol´ogico dos
EUA). Isto resultou na carˆencia de aten¸c˜ao a aplica¸c˜oes potenciais, o que contribuiu para
uma aceita¸c˜ao insatisfat´oria em setores privados e do governo.
Um passo adicional foi poss´ıvel pela r´apida evolu¸c˜ao de sistemas de informa¸c˜ao ba-
seados na Web nos ´ultimos anos. Nos EUA, a iniciativa NSDI passou por uma revis˜ao
em 2002, quando passou a ser chamada Geospatial One-Stop (GOS) e objetivou prover
acesso abrangente a informa¸c˜ao geogr´afica atrav´es de um portal Web
10
. Esta iniciativa
inaugurou o atual conceito de geoportais [ML05, Tai05].
Guiando o processo de padroniza¸c˜ao de tecnologia e, conseq¨uentemente, definindo os
elementos-chave para infra-estruturas de dados espaciais, diversos padr˜oes foram propos-
tos pela OGC, atrav´es de um framework chamado OGC Reference Model [Per03]. Este
framework foi implementado com informa¸c˜oes sobre estados, pa´ıses e sobre regi˜oes co-
muns a mais de um pa´ıs [Dee06, Dem06, Sky06], sendo que casos de SDI urbanas s˜ao
ainda escassos. Al´em do mais, muitos deles n˜ao est˜ao em conformidade com os padr˜oes
da OGC [TAM03, KSR05, MRZW06, DF06].
Adicionalmente, SDI podem ser implementadas por meio de cadeias de servi¸cos [Ala03]
e componentes de software integrados [GGR05] os quais s˜ao encontrados atrav´es de geo-
portais [ML05]. A ˆenfase em servi¸cos tem crescido desde a emergˆencia de servi¸cos Web
e da ado¸c˜ao de arquiteturas orientadas a servi¸co (AOS) [HS05, LPD05]. A ado¸c˜ao de
servi¸cos Web para garantir acesso direto a dados ´e a mais importante distin¸c˜ao entre SDI
de primeira e de segunda gera¸c˜ao.
10
URL: http://www.geodata.gov
CAP´ıTULO 2. TRABALHOS RELACIONADOS 13
2.4.1 Infra-estruturas de Dados Espaciais de Escopo Urbano
Considerando a existˆencia de interoperabilidade entre diferentes SIG, a informa¸c˜ao
geogr´afica de um ou v´arios parceiros pode ser consolidada e assim formar um imp ortante
conjunto de recursos para a tomada de decis˜ao no governo de uma regi˜ao espec´ıfica,
como uma cidade, ou em n´ıveis mais elevados de administra¸c˜ao, como um estado ou pa´ıs.
Neste caso, SDI podem ser vistas como um conjunto de “pe¸cas de montar” [RWHJ00], e
hierarquias de SDI s˜ao constru´ıdas nesse conjunto atrav´es do intercˆambio e consolida¸c˜ao
da informa¸c˜ao proveniente de diferentes organiza¸c˜oes. Assim, ´e constitu´ıda uma rede de
fontes de informa¸c˜ao geogr´afica, cada qual com abrangˆencia de cidades, estados, pa´ıses,
e por fim regi˜oes maiores, chegando at´e o n´ıvel global, como pode ser visto na figura
2.2. Nessa hierarquia, as camadas inferiores provˆeem informa¸c˜ao detalhada que auxilia
na constru¸c˜ao e consolida¸c˜ao dos n´ıveis superiores [JSTW02, Man06].
Figura 2.2: A vis˜ao “Blocos de Montar” das SDI [RWHJ00]
Denominamos as SDI que comportam detalhes de uma ´area urbana como infra-estru-
turas de dados espaciais urbanas (LSDI, do inglˆes Local Spatial Data Infrastructures), as
quais est˜ao na base de uma SDI global, como ilustrado na figura 2.2. Outra particularidade
das SDI urbanas ´e o potencial de reunir um numeroso grup o de usu´arios, cada qual com
necessidades distintas [DF06]. Esta caracter´ıstica ´e respons´avel por um aumento no n´ıvel
de complexidade do desenvolvimento e distribui¸c˜ao de uma LSDI [BEK
+
00, Mas05]. De
fato, LSDI possuem valor para todos os outros n´ıveis de infra-estrutura como fontes de
informa¸c˜ao detalhada [RWHJ00], e sua implementa¸c˜ao deve pautar-se por demandas de
novos grupos de usu´arios da informa¸c˜ao geogr´afica, tais como turistas [KSR05], cidad˜aos
[NBFRW04], pequenas organiza¸c˜oes [TAM03] e outros [DF06, Mas05, MRZW06].
No entanto, o foco em SDI urbanas ´e recente, se comparado a estudos sobre SDI nacio-
nais, regionais e globais [DA05]. SDI urbanas cresceram muito cedo e muito rapidamente
em alguns pa´ıses [BEK
+
00], muitas vezes sob a forma de SIG urbanos, antes mesmo da
CAP´ıTULO 2. TRABALHOS RELACIONADOS 14
padroniza¸c˜ao de mecanismos de interoperabilidade. Assim, os esfor¸cos de padroniza¸c˜ao
come¸caram nos n´ıveis mais elevados de SDI, deixando LSDI heterogˆeneas e com dificul-
dades de acoplamento entre si e entre estas e as SDI de n´ıveis superiores [JSTW02].
De fato, as SDI, em qualquer n´ıvel de detalhe, apresentam numerosas possibilidades
de uso de servi¸cos para encapsular dados de m´ultiplas fontes, e desta forma alcan¸car
interoperabilidade real entre diferentes SIG. A importˆancia de servi¸cos para estas infra-
estruturas inclusive levou Bernard e Craglia [BC05] a proporem uma nova tradu¸c˜ao para a
sigla SDI como Service-Driven Infrastructures (ou Infra-estruturas Dirigidas a Servi¸cos).
2.5 Servi¸cos Web
Todos os esfor¸cos anteriores de interoperabilidade ainda dependem de troca de dados
offline, o que torna obrigat´orio o uso de r´eplicas distribu´ıdas por todos os usu´arios da
informa¸c˜ao, exige maior espa¸co para armazenamento, pode apresentar dificuldade de con-
trole de vers˜oes e de r´eplicas inconsistentes, al´em de causar um atraso entre a atualiza¸c˜ao
da informa¸c˜ao e sua disponibiliza¸c˜ao para os usu´arios.
Uma forma de minimizar estas dificuldades d´a-se pela troca direta de dados entre
sistemas atrav´es de uma rede de computadores, de modo que dados s˜ao requisitados dire-
tamente de sua fonte, sem armazenamento tempor´ario e em sua vers˜ao mais atualizada.
Adicionalmente, o desenvolvimento de software baseado em componentes tem sido alvo
de muito interesse devido ao seu potencial em reduzir custo e tempo de desenvolvimento,
e devido ao interesse na implanta¸c˜ao de sistemas distribu´ıdos, os quais suportam a troca
direta de dados [DA07]. De fato, um dos mais interessantes desenvolvimentos neste campo
´e a emergˆencia de arquiteturas orientadas a servi¸co (SOA). SOA representam arquitetu-
ras atrav´es das quais aplica¸c˜oes s˜ao projetadas pela composi¸c˜ao de servi¸cos, os quais s˜ao
tarefas bem definidas, repetitivas e normalmente dirigidas a dados. As SOA, por´em, mu-
dam o foco em dados que atualmente existe em sistemas de informa¸c˜ao para um foco em
processos de alto n´ıvel fracamente acoplados.
A base das SOA ´e constitu´ıda por servi¸cos, com suas descri¸c˜oes e opera¸c˜oes fundamen-
tais tais como publica¸c˜ao, pesquisa, sele¸c˜ao e invoca¸c˜ao. Adicionalmente, SOA suportam
aplica¸c˜oes maiores pela melhor distribui¸c˜ao de dados e de capacidade de process amento,
pois facilitam a aloca¸c˜ao de programas e outros recursos computacionais distribu´ıdos em
redes de computadores. Nesta arquitetura, servi¸cos s˜ao auto-contidos, o que significa
que informa¸c˜oes sobre o servi¸co, incluindo funcionalidades, interfaces e comportamento,
podem ser obtidas atrav´es de fun¸c˜oes padronizadas oferecidas pelo pr´oprio servi¸co.
Produtores, provedores, cat´alogos e consumidores de servi¸co s˜ao os atores, ou enti-
CAP´ıTULO 2. TRABALHOS RELACIONADOS 15
dades de neg´ocio, que participam do modelo conceitual de servi¸cos (Figura 2.3), onde a
publica¸c˜ao ´e executada por um provedor de servi¸co, e consiste na cria¸c˜ao de uma descri¸c˜ao
do servi¸co em WSDL (o que inclui s eus m´etodos, os quais se referem `as funcionalidades
do mesmo) e a publica nos portais de pesquisa na Web. Estes portais usam um servi¸co de
registro para catalogar os servi¸cos de terceiros juntamente com detalhes sobre os mesmos
que permitem aos consumidores encontr´a-los. Ent˜ao, consumidores e produtores podem
selecionar estes servi¸cos utilizando-se do servi¸co de registro padronizado para procur´a-los
e tamb´em para obter o descritor de servi¸co em WSDL. Atrav´es da informa¸c˜ao presente
no descritor WSDL, um software-cliente pode ser criado para as opera¸c˜oes de invoca¸c˜ao.
Neste ponto, o cliente pode realizar comunica¸c˜ao direta com o provedor de servi¸co atrav´es
da Internet, usando os protocolos HTTP e SOAP e invocando os m´etodos do servi¸co
que foram definidos no documento WSDL. As invoca¸c˜oes terminam com a recep¸c˜ao da
resposta esperada do servi¸co em uma linguagem de formata¸c˜ao, como ´e o caso do XML.
Figura 2.3: Modelo conceitual de servi¸cos [DA07]
Consumidores de servi¸co podem criar software-clientes os quais acessam servi¸cos atra-
v´es de uma rede de comunica¸c˜ao. Al´em disso, os consumidores podem tornar-se produ-
tores quando agregam servi¸cos de um ou mais provedores em uma cadeia, para oferecer
resultados de um servi¸co comp osto para seus parceiros. Tais cadeias de servi¸co s˜ao trans-
parentes para os consumidores que as usam.
CAP´ıTULO 2. TRABALHOS RELACIONADOS 16
Adicionalmente, servi¸cos podem ser implementados independentemente de linguagens
de programa¸c˜ao ou ambientes de computa¸c˜ao particulares de provedor, tecnologias essas
que garantem a independˆencia entre provedores (que executam os servi¸cos) e consumidores
(que invocam os servi¸cos). Assim, servi¸cos tornam-se uma alternativa interessante para
alcan¸car interoperabilidade entre sistemas de informa¸c˜ao diferentes.
Particularmente em aplica¸c˜oes geoespaciais, um mecanismo de interoperabilidade pode
ser implementado a partir de padr˜oes de codifica¸c˜ao espec´ıficos para dados geogr´aficos.
Isto favorece a integra¸c˜ao de diversas fontes de informa¸c˜ao geogr´afica sem a necessidade
dos procedimentos exportar-converter-importar, comuns no passado dos SIG.
O conceito de servi¸cos Web ´e derivado do conceito de servi¸cos em redes de compu-
tadores, no qual um servi¸co corresponde a uma fun¸c˜ao ou a uma interface entre duas
camadas de abstra¸c˜ao no projeto de redes [DA07]. Neste contexto, uma camada de baixo
n´ıvel oferece servi¸co para uma camada de n´ıvel superior e a camada de n´ıvel superior n˜ao
´e afetada caso algumas propriedades das camadas inferiores sejam modificadas. A id´eia
de isolamento de detalhes t´ecnicos espec´ıficos atrav´es do uso de diferentes n´ıveis de abs-
tra¸c˜ao tamb´em se aplica no projeto de sistemas operacionais, sistemas de gerenciamento
de banco de dados, projeto de software e em sistemas distribu´ıdos.
As primeiras iniciativas de desenvolver sistemas distribu´ıdos, na d´ecada de 1990, ado-
taram um conjunto limitado de tecnologias (protocolos de rede, sistemas operacionais e
linguagens de programa¸c˜ao), com o objetivo de reduzir dificuldades de implementa¸c˜ao.
Este foi o caso de implementa¸c˜oes baseadas em chamadas remotas de procedimentos (re-
mote procedure calls, RPC). Entretanto, era ainda necess´ario permitir que os sistemas
baseados em linguagens de programa¸c˜ao diferentes ou desenvolvidos para sistemas ope-
racionais diferentes trocassem dados diretamente entre si [TA90]. Os pr´oximos passos
para garantir interoperabilidade entre sistemas heterogˆeneos envolveram esfor¸cos j´a cita-
dos anteriormente, como transferˆencia de dados com convers˜ao de formatos e defini¸c˜ao de
formatos espec´ıficos para intercˆambio em determinados dom´ınios, o que inclui o dom´ınio
de geoinforma¸c˜ao.
2.5.1 Padr˜oes da Ind´ustria para Servi¸cos Web
Os servi¸cos Web pertencem a uma classe espec´ıfica que usa padr˜oes abertos de Inter-
net, tais como conex˜ao e comunica¸c˜ao atrav´es de Hypertext Transfer Protocol (HTTP) e
Simple Object Access Protocol (SOAP), identifica¸c˜ao atrav´es de Uniform Resource Iden-
tifier (URI), formata¸c˜ao de conte´udo atrav´es de Extensible Markup Language (XML), e
descri¸c˜oes dos servi¸cos definidas atrav´es da Web Services Definition Language (WSDL).
CAP´ıTULO 2. TRABALHOS RELACIONADOS 17
A World Wide Web Consortium (W3C) ´e a organiza¸c˜ao que coordena o desenvolvi-
mento de padr˜oes populares tais como a Standard Generalized Markup Language (SGML)
e a Hypertext Markup Language (HTML), lan¸cadas respectivamente em 1986 e 1993, e
que propˆos em 1998 a linguagem XML como o padr˜ao que poderia servir como principal
formato de intercˆambio entre aplica¸c˜oes baseadas em Internet.
No campo dos sistemas de informa¸c˜ao geogr´aficos, a Open Geospatial Consortium
(OGC) foi criada em 1994 e tem liderado iniciativas de interoperabilidade no dom´ınio da
geoinforma¸c˜ao desde ent˜ao. Entre as iniciativas da OGC est´a a Geographic Markup Lan-
guage (GML), uma gram´atica XML para especifica¸c˜ao e codifica¸c˜ao de dados geogr´aficos,
publicada no ano 2000.
Em outra linha de de senvolvimento, alguns protocolos baseados em XML foram de-
senvolvidos com o objetivo de representar interfaces de m´etodos remotos (´e o caso da
WSDL, em 2002) e de representar invoca¸c˜oes (´e o caso do SOAP, em 2003). Tais proto-
colos tornaram-se a base tecnol´ogica dos primeiros servi¸cos Web.
2.5.2 Servi¸cos Web Geoespaciais
Enquanto servi¸cos Web gen´ericos provˆeem interoperabilidade entre sistemas de diferen-
tes dom´ınios, servi¸cos Web geoespaciais introduzem propriedades geoespaciais a servi¸cos
e d˜ao um passo a frente para facilitar a troca de dados e servi¸cos geogr´aficos entre ins-
titui¸c˜oes atrav´es da Internet, o que ´e garantido pela distribui¸c˜ao de recursos geogr´aficos
entre v´arias fontes de dados. Assim, servi¸cos Web geoes paciais podem reduzir esfor¸cos
redundantes que ocorrem quando dados espaciais s˜ao criados e disseminados, ao mesmo
tempo em que contribuem para o reuso de c´odigo entre diferentes aplica¸c˜oes.
Basicamente, servi¸cos Web geoespaciais diferem dos servi¸cos Web gen´ericos pela pre-
sen¸ca de dados geogr´aficos como entrada (por exemplo, um retˆangulo envolvente), como
sa´ıda (por exemplo, um mapa-base de uma cidade), no processamento (por exemplo,
verificar se duas ruas se cruzam), ou na combina¸c˜ao entre os anteriores.
A OGC propˆos uma arquitetura para distribui¸c˜ao de dados e funcionalidades ge-
ogr´aficos atrav´es da Internet, a qual abrange formatos de dados, m´etodos e especifica¸c˜ao
de interfaces para os diferentes servi¸cos que a constituem. Esta arquitetura ´e chamada
OpenGIS Services Framework [Per03]. A OGC tamb´em conduziu uma iniciativa para
especifica¸c˜ao de um conjunto de servi¸cos espe c´ıficos para ambientes urbanos chamado
Open Location Service (OpenLS) [
Mab04], no qual servi¸cos tais como diret´orio (servi¸co de
“p´aginas amarelas”), roteamento, geocodifica¸c˜ao e outros s˜ao agrupados. Outros servi¸cos
de alto-n´ıvel para ambientes urbanos foram propostos em [DA05] e a variedade de pos-
CAP´ıTULO 2. TRABALHOS RELACIONADOS 18
sibilidades de usar tais servi¸cos urbanos na constru¸c˜ao de aplica¸c˜oes ´uteis e compactas ´e
extensa.
No entanto, o OpenGIS Services Framework n˜ao usa necessariamente os padr˜oes de
servi¸cos Web mais comuns, tais como SOAP e WSDL. A ado¸c˜ao destes padr˜oes ´e inclusive
desej´avel para garantir interoperabilidade entre servi¸cos Web gen´ericos e servi¸cos Web
da OGC. Ao inv´es de usar Universal Description, Discovery and Integration (UDDI),
a OGC prop˜oe o uso de servi¸cos de cat´alogo para as opera¸c˜oes de publica¸c˜ao, pesquisa
e sele¸c˜ao [Son04]. Os servi¸cos Web da OGC tamb´em tˆem interfaces espec´ıficas para
invoca¸c˜ao conforme o objetivo de alto-n´ıvel do servi¸co, sendo que as interfaces n˜ao s˜ao
anotadas em descritores (em WSDL, por exemplo) por terem a assinatura padronizada.
Esta alternativa cria dificuldades para a indexa¸c˜ao e procura por s ervi¸cos em cat´alogos
n˜ao OGC. Al´em disso, alguns servi¸cos da OGC usam GML para codificar e distribuir
dados, enquanto servi¸cos Web comuns usam XML gen´erico, o que na verdade n˜ao ´e uma
grande diferen¸ca, uma vez que GML ´e derivada da XML [Per03]. Definitivamente, as
principais diferen¸cas existentes entre servi¸cos da W3C e da OGC devem ser sanadas t˜ao
logo seja poss´ıvel, pois isto incentivaria a ado¸c˜ao dos padr˜oes propostos por ambas as
organiza¸c˜oes de uma forma mais ampla [Son04].
Alguns servi¸cos fundamentais foram especificados pela OGC, como servi¸cos para regis-
tro, composi¸c˜ao, visualiza¸c˜ao e codifica¸c˜ao de informa¸c˜ao geoespacial. Estes podem ent˜ao
ser combinados para formar sistemas de informa¸c˜ao distribu´ıdos com fun¸c˜oes geogr´aficas
importantes. Os principais servi¸cos s˜ao descritos em seguida.
Web Feature Se rvice: provˆe uma interface para inserir, selecionar, atualizar e re-
mover fei¸c˜oes geogr´aficas (objetos).
Web Coverage Service: provˆe acesso a geocampos de forma semelhante ao Web
Feature Service. Por´em, sua resposta n˜ao representa imagens de geocampos, mas detalhes
sobre os mesmos.
Web Gazetteer Service: estende o Web Feature Service com recursos para a imple-
menta¸c˜ao de interfaces para gazetteers [SDB
+
05].
Web Registry Service e OpenGIS Catalog Service (OCS): implementam um
servi¸co com funcionalidade similar ao UDDI para servi¸cos Web.
Web Coordinate Transformation Service : provˆe um algoritmo que converte co-
ordenadas de objetos geogr´aficos entre diferentes sistemas de referˆencia geoespacial.
Web Map Service: produz mapas para a Web. Mapas, neste servi¸co, s˜ao imagens e
n˜ao apresentam os dados geogr´aficos, mas apenas uma representa¸c˜ao pronta.
Web Terrain Service: similar ao Web Map Service, este servi¸co cria representa¸c˜oes
em trˆes dimens˜oes de superf´ıcies. Tanto este servi¸co quanto o Web Map Service produzem
CAP´ıTULO 2. TRABALHOS RELACIONADOS 19
representa¸c˜oes em formatos de imagem ou em formatos vetoriais tais como o formato
Scalable Vector Graphics (SVG).
Interfaces de servi¸cos Web tem sido desenvolvidas pela OGC at´e mesmo para redes
de sensores, sob os nomes Sensor Collection Service e Sensor Planning Service
[Ope]. Estes servi¸cos, al´em de outros, consolidam uma arquitetura aberta e flex´ıvel, a
qual encontra aplica¸c˜ao em situa¸c˜oes muito similares `aquelas discutidas para SDI. Al´em
dos argumentos citados anteriormente para SDI, as infra-estruturas de dados espaciais
devem ainda ser distribu´ıdas, suportar m´ultiplas aplica¸c˜oes e m´ultiplos clientes de dife-
rentes tipos, ser compostas por m´ultiplas fontes de dados, ser gerenciadas por mais de
um grupo para manuten¸c˜ao dos dados, conseq¨uentemente em um ambiente computaci-
onal heterogˆeneo. Adicionalmente, n˜ao ´e adequado que uma SDI imponha a ado¸c˜ao de
produtos espec´ıficos aos seus participantes mas, ao contr´ario, que apenas determine um
conjunto m´ınimo de padr˜oes a serem seguidos. Estes padr˜oes precisam ser largamente
aceitos, e os padr˜oes t´ıpicos de Internet, como os que foram mencionados nesta se¸c˜ao,
atendem adequadamente este quesito.
No entanto, mesmo se os servi¸cos Web geoespaciais adotassem integralmente os pa-
dr˜oes da OGC e da W3C, as dificuldades t´ecnicas de implementa¸c˜ao de SDI e SIG dis-
tribu´ıdos n˜ao necessariamente seriam reduzidas. Um exemplo disso ´e a necessidade que
SIG tˆem de requisitar informa¸c˜oes de processamento mais demorado, em sua maioria, o
que apresenta peculiaridades se comparados a outros tipos de sistemas de informa¸c˜ao.
Neste caso, como os servi¸cos da W3C [Wor04] usam o protocolo HTTP em sua camada
de aplica¸c˜ao, e este protocolo suporta apenas chamadas s´ıncronas, este fato representa
um problema quando transa¸c˜oes longas existem.
Algumas iniciativas tentaram emular comunica¸c˜ao ass´ıncrona em servi¸cos Web atrav´es
do uso de listeners que recebem respostas e as encaminham para o cliente que a requisitou
[RLT05], normalmente sobre protocolos diferentes do HTTP [BCPR04], como o protocolo
de correio eletrˆonico SMTP [CPD06]. Todavia, at´e onde foi pesquisado, nenhum padr˜ao
permite comunica¸c˜ao ass´ıncrona usando apenas os padr˜oes de servi¸cos Web.
Com rela¸c˜ao a informa¸c˜ao geogr´afica especificamente, as especifica¸c˜oes de servi¸cos
Web da OGC [Whi05] descrevem fun¸c˜oes e componentes, dentre os quais comunica¸c˜ao
ass´ıncrona ´e suportada apenas por servi¸cos de sensores [Ope] como o Web Notification
Service, mas nenhum protocolo de comunica¸c˜ao foi definido nesta especific a¸c˜ao.
Al´em da necessidade do exemplo, outros requisitos s˜ao essenciais para o desenvolvi-
mento de SDI e SIG interoper´aveis atrav´es de servi¸cos Web. A adequa¸c˜ao dos servi¸cos
Web para o atendimento desses requisitos ´e avaliada no pr´oximo cap´ıtulo.
20
Cap´ıtulo 3
Metodologia e Infra-estrutura de
Avalia¸c˜ao
O objetivo desta pes quisa ´e investigar a adequa¸c˜ao dos padr˜oes OGC para a imple-
menta¸c˜ao de sistemas de informa¸c˜ao geogr´aficos baseados em dados compartilhados em
rede, infra-estruturas de dados espaciais de ˆambito local e softwares-cliente para tais SIG
e LSDI, assim como definido na se¸c˜ao 1.3.
Para a consecu¸c˜ao da investiga¸c˜ao, um cen´ario de uso foi especificado na se¸c˜ao 3.1. Em
seguida, na se¸c˜ao 3.2 foi especificado um prot´otipo de infra-estrutura de dados espaciais
e de SIG urbano, onde tamb´em s˜ao apresentadas duas situa¸c˜oes de teste, a primeira
com a intermedia¸c˜ao por um provedor de servi¸cos geogr´aficos incompat´ıvel com o OGC
e a segunda implementa¸c˜ao com o uso direto de servi¸cos geogr´aficos compat´ıveis com
o OGC por parte do cliente. Na se¸c˜ao 3.3 foram detalhados os servi¸cos geoespaciais
implementados e o banco de dados geogr´afico adotado. Finalmente, s˜ao apresentadas as
limita¸c˜oes identificadas na se¸c˜ao 3.4, a partir das duas situa¸c˜oes no cen´ario ilustrado.
3.1 Cen´ario de Implementa¸c˜ao e Estudo de Caso
O Modelo de Referˆencia do OGC [Per03] define um cen´ario de uso intitulado “as-
sistˆencia a viagem do cliente” (consumer travel assistance) [p. 83] atrav´es do qual um
consumidor de informa¸c˜ao geogr´afica usa um dispositivo m´ovel, onde h´a um cliente de
SIG, para (1) obter sua posi¸c˜ao atual ou localiza¸c˜ao; (2) obter um endere¸co de destino,
dado um n´umero de telefone; (3) obter uma localiza¸c˜ao, dado o endere¸co de destino; (4)
obter uma rota entre a origem e o destino; (5) determinar as condi¸c˜oes de tr´afego, clima
e condi¸c˜oes da rodovia ao longo do caminho; e finalmente (6) obter avisos em tempo real
sobre as condi¸c˜oes da viagem. O cen´ario de us o serve como gabarito para espe cifica¸c˜ao e
CAP´ıTULO 3. METODOLOGIA E INFRA-ESTRUTURA DE AVALIAC¸
˜
AO 21
testes de sistemas distribu´ıdos [Pre05].
Esta tarefa requer um conjunto significativo de dados geogr´aficos, os quais possi-
velmente pertencem a diferentes provedores de informa¸c˜ao. Um modelo computacional
poss´ıvel ´e garantido pela presen¸ca de provedores deste tipo de servi¸co que intermedeiam
todas as transa¸c˜oes entre o cliente e os servi¸cos, enquanto tamb´em ´e poss´ıvel que o cliente
ocupe-se das requisi¸c˜oes e recep¸c˜ao de respostas dos diversos servi¸cos que c omp˜oem a
tarefa. Em ambos os casos h´a impactos diretos no desempenho do cliente e na facilidade
com a qual softwares-cliente s˜ao desenvolvidos para um SIG qualquer.
Para nossa prova de conceito, detalhamos e estendemos o cen´ario “assistˆencia a viagem
do cliente”, por´em retiramos os passos 5 e 6 do cen´ario original. Essas altera¸c˜oes no
cen´ario de uso tiveram o objetivo de deslocar a complexidade de servi¸cos de alto n´ıvel n˜ao
especificados at´e o momento pelo OGC para aqueles servi¸cos que j´a possuem especifica¸c˜ao
aprovada. Dessa maneira, foi reduzida a influˆencia de decis˜oes de projeto e implementa¸c˜ao
desta pesquisa sobre aqueles servi¸cos para os quais o OGC n˜ao emitiu especifica¸c˜oes de
implementa¸c˜ao. O cen´ario do ORM alterado possui os passos enumerados abaixo e ´e
ilustrado na Figura 3.1.
1. Obter a posi¸c˜ao de origem ou localiza¸c˜ao do cliente ao fornecer um dos seguintes
dados: um telefone fixo pr´oximo, um cruzamento entre pelo menos dois logradouros,
ou uma referˆencia baseada em nome ou local conhecido (Informa¸c˜ao A na Figura
3.1).
2. Obter um endere¸co de destino, dado um n´umero de telefone.
3. Obter a localiza¸c˜ao de destino, dado o endere¸co de destino (Informa¸c˜ao B na Figura
3.1).
4. Obter uma lista de pontos de interesse pr´oximos `a localiza¸c˜ao de destino (Informa¸c˜ao
C na Figura 3.1, representada pelo conjunto de pontos no interior do c´ırculo).
5. Selecionar um ponto de interesse (Informa¸c˜ao D na Figura 3.1).
6. Obter uma rota entre a p osi¸c˜ao de origem e a posi¸c˜ao de destino, passando obriga-
toriamente pelo ponto de interesse (Informa¸c˜ao E na Figura 3.1, representada por
uma linha que parte do ponto de origem e segue at´e o ponto de destino).
A implementa¸c˜ao de dois modelos de computa¸c˜ao ´e descrita nas pr´oxima se¸c˜ao e as
limita¸c˜oes identificadas a partir desta implementa¸c˜ao s˜ao discutidas na se¸c˜ao 3.4.
CAP´ıTULO 3. METODOLOGIA E INFRA-ESTRUTURA DE AVALIAC¸
˜
AO 22
Figura 3.1: Amostra de resultado do processamento de uma consulta
3.2 Infra-estrutura de Dados Espaciais Urbanos
3.2.1 Servi¸cos de Alto N´ıvel
O exemplo de infra-estrutura de dados espaciais urbanos utiliza-se de informa¸c˜oes
geogr´aficas dispon´ıveis sobre a cidade de Belo Horizonte (MG). Apesar de as informa¸c˜oes
terem sido usadas na forma como est˜ao dispon´ıveis na cidade, a LSDI j´a existente n˜ao
´e compat´ıvel com os servi¸cos do OGC e baseia-se em um acordo de coopera¸c˜ao entre
diferentes organiza¸c˜oes p´ublicas, privadas e na troca offline de arquivos centralizados em
um reposit´orio mantido pelas organiza¸c˜oes participantes do convˆenio [DF06].
A LSDI de testes ´e composta por alguns dos servi¸cos de n´ıvel conceitual propostos
originalmente no estudo de Davis Jr e Alves [DA05], os quais s˜ao discriminados abaixo.
• Dois servi¸cos do tipo Mapa-base, servindo o segundo para simples replica¸c˜ao;
• Um servi¸co do tipo Roteamento;
• Dois servi¸cos do tipo Geocodifica¸c˜ao, servindo o segundo como substituto n˜ao equi-
valente ao primeiro;
• Um servi¸co do tipo Diret´orio para n´umeros de telefone;
CAP´ıTULO 3. METODOLOGIA E INFRA-ESTRUTURA DE AVALIAC¸
˜
AO 23
• Um servi¸co do tipo Diret´orio para empresas;
• Um servi¸co do tipo Localiza¸c˜ao Pessoal;
• Um servi¸co personalizado para intermediar a comunica¸c˜ao entre os servi¸cos anteri-
ores e os softwares-cliente;
• Um servi¸co de Cat´alogo.
Cada um deles foi implementado como um servi¸co independente dos outros, mas em
alguns casos compartilhando o ambiente do mesmo servidor HTTP, como ilustrado na
Figura 3.2. O servi¸co personalizado foi desenvolvido para representar o papel de um
integrador de servi¸cos em cadeias, sobre as quais o software-cliente n˜ao possui qualquer
controle.
Figura 3.2: Distribui¸c˜ao f´ısica dos se rvi¸cos implementados
Os servi¸cos de n´ıvel conceitual foram implementados sobre servi¸cos propostos pelo
CAP´ıTULO 3. METODOLOGIA E INFRA-ESTRUTURA DE AVALIAC¸
˜
AO 24
OGC em suas especifica¸c˜oes OGC Web Services e Open Location Services, o que ser´a
tratado na se¸c˜ao 3.3.
3.2.2 Implementa¸c˜ao 1
Atrav´es da primeira implementa¸c˜ao ´e avaliada a facilidade com a qual s˜ao desenvol-
vidos servi¸cos Web regulares, no padr˜ao W3C, derivados dos servi¸cos Web geoespaciais
propostos pelo OGC, ao mesmo tempo em que se avalia o desenvolvimento de clientes
que us am servi¸cos gen´ericos ao inv´es de servi¸cos padr˜ao OGC. Nesse caso, o cliente usa
o servi¸co Web derivado, e cada novo servi¸co desse tipo exige altera¸c˜oes no cliente que o
utiliza.
O conjunto de fun¸c˜oes do servi¸co derivado ´e exposto para o cliente atrav´es de sua
respectiva interface, e funciona como uma API para os servi¸cos primitivos, pr´oprios ou de
terceiros, adotados pelo provedor.
A Figura 3.3 mostra um servidor denominado I ntegrador, onde localiza-se o servi¸co
derivado, e a segunda camada de servidores, onde localizam-se as fontes originais de
informa¸c˜ao e fun¸c˜oes geogr´aficas.
Figura 3.3: Implementa¸c˜ao 1, onde h´a a intermedia¸c˜ao de um provedor
Ao implementar esse modelo, o cliente n˜ao conhece a existˆencia da segunda camada
de servidores e servi¸cos e n˜ao possui controle sobre os mesmos.
CAP´ıTULO 3. METODOLOGIA E INFRA-ESTRUTURA DE AVALIAC¸
˜
AO 25
3.2.3 Implementa¸c˜ao 2
Diferentemente da primeira implementa¸c˜ao, na segunda n˜ao s˜ao constru´ıdos servi¸cos
Web derivados, ou seja, somente servi¸cos Web geoespaciais s˜ao disponibilizados por seus
respectivos provedores, os quais s˜ao acessados diretamente pelos softwares-cliente. Assim,
uma vez que esses servi¸cos s˜ao padronizados, o suporte a novas fun¸c˜oes padronizadas nos
servi¸cos n˜ao provoca altera¸c˜oes no software-cliente. Por esse motivo, atrav´es desta imple-
menta¸c˜ao foi avaliada principalmente a facilidade com a qual s˜ao desenvolvidos softwares-
cliente para servi¸cos primitivos. A Figura 3.4 mostra a camada onde localizam-se as fontes
originais de informa¸c˜ao e fun¸c˜oes geogr´aficas.
Figura 3.4: Implementa¸c˜ao 2, onde o cliente acessa diretamente os servi¸cos alvo
O que diferencia a primeira da segunda implementa¸c˜ao ´e principalmente o fato de que
o segundo cliente usa interfaces comuns a todos os servi¸cos compat´ıveis com o OWS e o
OpenLS, isto ´e, temos um cliente universal. No primeiro caso, temos um cliente fortemente
dependente de um provedor de servi¸cos, ou seja, trata-se de um cliente espec´ıfico para
uma aplica¸c˜ao.
3.2.4 Clientes para o Sistema de Informa¸c˜ao Geogr´afico
Os softwares-cliente s˜ao resp ons´aveis pelo uso de servi¸cos primitivos e ou derivados
(compostos). Entretanto, os softwares-cliente reais s˜ao destinados a dispositivos com dife-
rentes capacidades de processamento, armazenamento e comunica¸c˜ao, sendo classificados
na literatura como magros, ricos ou gordos, em fun¸c˜ao da parcela de funcionalidades man-
tidas no cliente e no servidor [Pre05]. As defini¸c˜oes clientes magro e cliente gordo tamb´em
CAP´ıTULO 3. METODOLOGIA E INFRA-ESTRUTURA DE AVALIAC¸
˜
AO 26
s˜ao dadas aos pr´oprios dispositivos, com rela¸c˜ao `as suas capacidades de processamento,
armazenamento e comunica¸c˜ao.
Os dispositivos com menor capacidade de processamento s˜ao classificados como clien-
tes magros. S˜ao normalmente alimentados por uma bateria e tˆem capacidade de energia
limitada. Ao me smo tempo, estes dispositivos tamb´em tˆem limita¸c˜oes de mem´oria prin-
cipal e mem´oria secund´aria. Um exemplo s˜ao os telefones celulares modernos com uma
m´aquina virtual Java espec´ıfica (KVM). Esses equipamentos normalmente demandam
servi¸cos remotos atrav´es de um meio de comunica¸c˜ao de alto custo, se comparado a redes
de comunica¸c˜ao corporativas e dom´esticas.
Como clientes ricos s˜ao classificados dispositivos nos quais h´a um processador mais
r´apido e a capacidade de mem´oria principal e mem´oria secund´aria pode ser estendida. Es-
ses clientes normalmente possuem recursos computacionais s uficientes para manter parte
da aplica¸c˜ao no pr´oprio dispositivo, enquanto outra parte do processamento ´e realizada
remotamente. Os meios de comunica¸c˜ao normalmente usados s˜ao os mesmos de clien-
tes magros, mas em alguns casos redes corporativas e dom´esticas s˜ao usadas. Exemplos
de dispositivos assim s˜ao os Personal Digital Assistants e alguns telefones celulares es-
pec´ıficos.
Por fim, como clientes gordos s˜ao classificados dispositivos com capacidade de pro-
cessamento, armazenamento e de energia superiores ao necess´ario por aplica¸c˜oes comuns.
Normalmente s˜ao computadores pessoais, com alimenta¸c˜ao cont´ınua de energia e equipa-
dos com disco r´ıgido. Assim, mesmo computadores pessoais em movimento (notebooks
alimentados por bateria e utilizando-se de uma rede sem fio) s˜ao clientes gordos, uma vez
que a velocidade de processamento ´e mais relevante nesta classifica¸c˜ao.
Nos trˆes casos, o projeto de um software-cliente para um SIG deve ser dimensionado
em fun¸c˜ao da capacidade do dispositivo que o executar´a. Para os experimentos, foi desen-
volvido um ´unico software-cliente que implementa as funcionalidades como cliente magro
mas n˜ao possui restri¸c˜oes no processamento, mem´oria, armazenamento e capacidade de
comunica¸c˜ao de dados, pois os requisitos do modelo abstrato n˜ao s˜ao relacionados direta-
mente a essas vari´aveis.
3.3 Servi¸cos Implementados
3.3.1 Servi¸cos OGC
As especifica¸c˜oes OWS e OpenLS atendem aos requisitos do Modelo de Referˆencia
do OGC, o qual divide-se em dois n´ıveis de abstra¸c˜ao: modelo abstrato, onde servi¸cos
CAP´ıTULO 3. METODOLOGIA E INFRA-ESTRUTURA DE AVALIAC¸
˜
AO 27
possuem requisitos e um comportamento gen´erico n˜ao dependente das tecnologias atuais; e
modelo de implementa¸c˜ao, onde ´e e specificado como os servi¸cos s˜ao desenvolvidos atrav´es
das tecnologias de software atualmente dispon´ıveis.
Os servi¸cos OGC implementados foram Web Feature Service, OpenGIS Catalog Ser-
vice, Web Map Service, Geocoder Service e Route Service, sendo os dois ´ultimos do con-
junto OpenLS [Ope05b, Ope05a, Mab04]. As fun¸c˜oes destes e de outros servi¸cos do OGC
j´a foram apresentadas na se¸c˜ao 2.5.2.
Os servi¸cos foram codificados em linguagem Java e o framework Apache Axis foi usado
para dar suporte `as mensagens SOAP como servi¸cos Web, os quais s˜ao executados em
servidores HTTP Apache Tomcat.
3.3.2 Servi¸cos N˜ao-OGC
Para o desenvolvimento de um prot´otipo que atendesse ao cen´ario de uso da se¸c˜ao 3.1
e a implementa¸c˜ao dos servi¸cos de alto n´ıvel especificados na se¸c˜ao 3.2.1, um conjunto de
fun¸c˜oes n˜ao compreendidas pelos servi¸cos do OGC foi projetado e implementado.
O agrupamento de fun¸c˜oes em servi¸cos foi baseada no prop´osito de cada uma, ao
mesmo tempo em que cada grupo deveria ser reunido em um ´unico componente ou con-
junto de componentes de software, o que favoreceria a implanta¸c˜ao das fun¸c˜oes.
O primeiro grupo foi denominado Data Exchange Service (DXS) e foi implementado
como um s ervi¸co Web capaz de servir como reposit´orio de informa¸c˜ao geoespacial trocada
entre os servi¸cos OGC primitivos e os clientes. O objetivo do grupo ´e principalmente
provˆer persistˆencia de dados e conseq¨uentemente permitir a recupera¸c˜ao de informa¸c˜ao
em uma segunda chamada, a qual ´e isolada da invoca¸c˜ao onde ´e realizada a requisi¸c˜ao ao
servi¸co geoespacial. O servi¸co ser´a detalhado na se¸c˜ao 4.1.
O segundo grupo foi denominado Client Access Service (CAS) e torna o cliente apto
a responder por requisi¸c˜oes de outros clientes e de servi¸cos, como se o cliente fosse um
servidor. O grupo foi projetado como um comportamento similar ao de servidores HTTP,
o que torna poss´ıvel que invoca¸c˜oes sejam realizadas e recebidas pelo cliente, da mesma
forma. O comportamento ser´a detalhado na se¸c˜ao 4.2.
O terceiro grupo foi denominado Transaction Control Service (TCS) e foi implemen-
tado como um compilador XSLT que converte uma especifica¸c˜ao de alto n´ıvel em XML
para um c´odigo espec´ıfico de uma LSDI, onde s˜ao introduzidos os servi¸cos geoespaciais
necess´arios. Finalmente, o c´odigo espec´ıfico pode ser traduzido para c´odigo execut´avel,
em uma linguagem de programa¸c˜ao alvo, no qual j´a s˜ao introduzidas particularidades do
software-cliente e do dispositivo-cliente, como por exemplo a necessidade de uso do DXS.
CAP´ıTULO 3. METODOLOGIA E INFRA-ESTRUTURA DE AVALIAC¸
˜
AO 28
O servi¸co ser´a explicado na se¸c˜ao 4.3.
Finalmente, todos os servi¸cos, compat´ıveis ou n˜ao com o OGC, compartilharam o
mesmo esquema conceitual de banco de dados, o qual ´e especificado na pr´oxima se¸c˜ao.
3.3.3 Banco de Dados Geogr´afico
Os dados geogr´aficos usados pelos servi¸cos Web foram armazenados em um servidor de
banco de dados baseado no SGBD PostgreSQL com a extens˜ao e spacial PostGIS. Atrav´es
dessa extens˜ao espacial, algumas opera¸c˜oes espaciais foram omitidas dos servi¸cos Web e
mantidas sob responsabilidade do SGBD, as quais s˜ao:
• asgml, para sa´ıda de dados geogr´aficos no formato da GML
• distance, para c´alculo de distˆancia entre coordenadas geogr´aficas
• geomunion, para consolida¸c˜ao ou agrupamento de objetos geogr´aficos
• intersection, para obten¸c˜ao de regi˜ao resultado da interse¸c˜ao de dois pol´ıgonos
• point, para sa´ıda de dados geogr´aficos no format latitude/longitude
• setsrid, para atribui¸c˜ao de identifica¸c˜ao de sistema de referˆencia geoespacial aos
pol´ıgonos obtidos de diferentes provedores
• touches, para verifica¸c˜ao de cruzamento de ruas
• transform, para transforma¸c˜ao de sistema de referˆencia geoespacial
Al´em disso, o SGBD foi compartilhado entre todos os servi¸c os Web implementados, o
que ampliou nosso foco na troca de mensagens e na implementa¸c˜ao das funcionalidades
espec´ıficas dos diferentes tip os de servi¸co OGC.
A figura 3.5 apresenta as entidades presentes no SGBD por meio do modelo OMT-
G [CCD
+
05]: nomes de logradouro, trechos de logradouro, estabelecimentos comerciais,
bairros, regionais, endere¸cos e pontos de referˆencia.
3.4 Limita¸c˜oes Identificadas
O documento do Modelo de Referˆencia do OGC [Per03] define cinco perspectivas para
o projeto de SIG dis tribu´ıdos, as perspectivas Organizacional, Informacional, Computa-
cional, de Engenharia e Tecnol´ogica , cada qual abrangendo um conjunto de propriedades
CAP´ıTULO 3. METODOLOGIA E INFRA-ESTRUTURA DE AVALIAC¸
˜
AO 29
Figura 3.5: Modelo OMT-G do banco de dados geogr´aficos usado
e requisitos do sistema. A perspectiva Organizacional descreve um sistema segundo seus
prop´ositos dentro de uma organiza¸c˜ao, ou seja, a l´ogica de neg´ocio representa uma de
suas descri¸c˜oes mais importantes. Em seguida, a perspectiva Informacional descreve um
sistema conforme seu conte´udo, tipos de informa¸c˜ao, propriedades dos dados, principais
fluxos entre unidades organizacionais, al´em de outros aspectos importantes. A perspec-
tiva Computacional, por sua vez, descreve o sistema atrav´es de suas fun¸c˜oes, opera¸c˜oes,
rotinas e transforma¸c˜oes sobre os dados e informa¸c˜oes. Somente a perspectiva de Enge-
nharia assume a natureza distribu´ıda do sistema e relaciona os objetos das perspectivas
anteriores a componentes de software distribu´ıdos em uma rede de computadores. Por´em,
tais componentes de software ainda s˜ao abstratos, independentes de tecnologia e apenas
CAP´ıTULO 3. METODOLOGIA E INFRA-ESTRUTURA DE AVALIAC¸
˜
AO 30
s˜ao materializados em c´odigo execut´avel atrav´es da pr´oxima perspectiva. Finalmente,
a perspectiva Tecnol´ogica define como os componentes de software s˜ao implementados,
implantados e como funcionam em um conjunto de computadores, onde, no contexto dos
SIG distribu´ıdos, a tecnologia de servi¸cos Web ´e a mais comum.
Dentre outros objetivos, a perspectiva de Engenharia oculta aspectos complexos de
parte do software, onde tais aspectos mostrem-se irrelevantes ao seu prop´osito.
´
E fre-
quentemente o caso de recursos de seguran¸ca, recupera¸c˜ao em caso de falhas, controle de
privacidade, otimiza¸c˜ao de custos de comunica¸c˜ao, implementa¸c˜ao de especificidades de
diferentes tipos de dispositivos-cliente, e outros.
Atrav´es do desenvolvimento de clientes de SIG para os servi¸cos e para o cen´ario especi-
ficado nas se¸c˜oes anteriores, foram identificadas limita¸c˜oes de projeto e de implementa¸c˜ao
das transparˆencias definidas pelo ORM na perspectiva de Engenharia, que s˜ao:
• Transparˆencia de acesso, que oculta diferen¸cas na representa¸c˜ao de dados e proto-
colos de acesso;
• Transparˆencia de localiza¸c˜ao, que oculta a localiza¸c˜ao f´ısica de um componente de
software;
• Transparˆencia de migra¸c˜ao, que oculta de um componente de software detalhes de
reloca¸c˜ao dele pr´oprio;
• Transparˆencia de reloca¸c˜ao, que oculta das interfaces detalhes sobre reloca¸c˜ao de
outras interfaces usadas pelas primeiras;
• Transparˆencia de replica¸c˜ao, a qual ocupa-se de detalhes sobre a cria¸c˜ao de r´eplicas
consistentes para aumentar o desempenho e a disponibilidade do sistema;
• Transparˆencia de persistˆencia, a qual ocupa-se da cria¸c˜ao e uso de objetos no lado
do servidor;
• Transparˆencia de falha, que oculta falhas e recupera¸c˜oes do sistema diante dessas
falhas;
• Transparˆencia de transa¸c˜ao, que oculta detalhes sobre a coordena¸c˜ao de tarefas
entre um grupo de componentes de software.
Algumas das transparˆencias, como transparˆencia de acesso, s˜ao providas por servi¸cos
de infra-estrutura tais como o domain name system (DNS). Outras por´em, mostram-
se mais dif´ıceis de implementar e suportar, tais como as transparˆencias de migra¸c˜ao ou
reloca¸c˜ao [Per03].
CAP´ıTULO 3. METODOLOGIA E INFRA-ESTRUTURA DE AVALIAC¸
˜
AO 31
S˜ao discutidas nesta se¸c˜ao as limita¸c˜oes identificadas atrav´es da implementa¸c˜ao 1
(I1), se¸c˜ao 3.2.2, e da implementa¸c˜ao 2 (I2), se¸c˜ao 3.2.3. E stas limita¸c˜oes referem-se `as
transparˆencias citadas anteriormente e foram analisadas s obre os requisitos n˜ao-funcionais
(RNF) da perspectiva de Engenharia definidos no ORM [Per03]. Para a an´alise foi uti-
lizada a t´ecnica proposta em [MCN92], atrav´es da qual tornaram-se expl´ıcitos os RNF e
as t´ecnicas de satisfa¸c˜ao, que s˜ao os mecanismos de suporte a estes RNF. Por´em, uma
t´ecnica de satisfa¸c˜ao que suporta um RNF pode prejudicar outro. Portanto, pelo resul-
tado dos impactos positivos e negativos de determinadas t´ecnicas de satisfa¸c˜ao em RNF
diversos, se deve renegociar requisitos e prioridades com os participantes ou usu´arios de
um sistema, com o objetivo de torn´a-lo adequado para todos.
Ap´os o nome de cada t´ecnica de satisfa¸c˜ao pode haver um elemento composto por um
´unico par de colchetes . A inclus˜ao de um nome de entidade entre colchetes (Ex: [cliente],
[WFS], etc) indica o componente de software ao qual pertence o RNF afetado, sendo que
[cliente] ´e a entidade do RNF caso o nome da entidade seja omitido.
Nas pr´oximas se¸c˜oes s˜ao dis cutidos estes RNF de cada transparˆencia desejada para
o projeto de uma SDI. Inicialmente, na se¸c˜ao 3.4.1, s˜ao apresentados os RNF identifi-
cados nas especifica¸c˜oes do OGC e avaliados neste trabalho. Na se¸c˜ao 3.4.2 ´e discutida
a transparˆencia de acesso, pela qual s˜ao usados protocolos de acesso a dados e servi¸cos
remotos. Em seguida, na se¸c˜ao 3.4.3 ´e discutida a transparˆencia de localiza¸c˜ao, a qual
´e suportada principalmente pelo servi¸co de rede domain name system. Na se¸c˜ao 3.4.4 ´e
discutida a transparˆencia de migra¸c˜ao que trata da reloca¸c˜ao de componentes de soft-
ware sem associar complexidade a implementa¸c˜ao destes componentes. Em seguida, na
se¸c˜ao 3.4.5 ´e apresentada a transparˆencia de reloca¸c˜ao, a qual oculta a complexidade do
processo de acessar componentes que sofrem migra¸c˜ao. Na se¸c˜ao 3.4.6 ´e discutida a trans-
parˆencia de replica¸c˜ao, pela qual r´eplicas s˜ao produzidas para aumentar a disponibilidade
e desempenho do sistema sem aumento da complexidade. A transparˆencia de persistˆencia
´e apresentada na se¸c˜ao 3.4.7, onde o armazenamento e manipula¸c˜ao de objetos remotos
foram avaliados. A transparˆencia de falha ´e apresentada na se¸c˜ao 3.4.8, onde mecanismos
de recupera¸c˜ao e suporte a disponibilidade em caso de falhas de software e hardware foram
experimentados. E finalmente, na se¸c˜ao 3.4.9 ´e discutida a transparˆencia de transa¸c˜ao,
pela qual s˜ao constru´ıdos mecanismos de coordena¸c˜ao de tarefas entre componentes de
software distribu´ıdos. Na se¸c˜ao 3.4.10, ´e realizada e discutida uma avalia¸c˜ao sobre o im-
pacto dos mec anismos proj etados, para todas as transparˆencias anteriores, no processo de
desenvolvimento de softwares-cliente para estas infra-estruturas.
CAP´ıTULO 3. METODOLOGIA E INFRA-ESTRUTURA DE AVALIAC¸
˜
AO 32
3.4.1 Requisitos N˜ao-Funcionais
Para cada componente de software especificado apresentam-se requisitos n˜ao-funciona-
is (RNF), os quais podem ser definidos como fatores impl´ıcitos de qualidade de software
que podem ser medidos de forma indireta [Pre05]. Os RNF avaliados para os servi¸cos
prototipados s˜ao descritos abaixo.
Auditabilidade de componentes refere-se `a capacidade de o cliente verificar as pro-
priedades de componentes de software e de informa¸c˜ao internos a uma cadeia de servi¸cos,
o que atualmente s´o ´e poss´ıvel em um modelo de computa¸c˜ao totalmente horizontal, se m
uso de servi¸cos compostos, o que ´e similar ao modelo da implementa¸c˜ao 2 definido na
se¸c˜ao 3.2.3. Atrav´es desse mo de lo, o c liente tem acesso direto aos servi¸cos Web e tem
como controlar diretamente parˆametros tais como desempenho e qualidade de informa¸c˜ao.
A medida deste RNF se d´a pela disponibilidade ou indisponibilidade dos metadados sobre
os componentes usados por servi¸cos Web geoespaciais invocados.
Controle sobre componentes refere- se `a capacidade de obten¸c˜ao de informa¸c˜ao
sobre componentes servi¸cos a partir do cat´alogo. A medida deste RNF se d´a pela possibi-
lidade de realizar a recupera¸c˜ao de informa¸c˜ao sobre servi¸co no cat´alogo a partir da URI
do servi¸co.
Economia de comunica¸c˜ao refere-se ao n´umero de invoca¸c˜oes realizadas pelo cliente
para obter resultado de um servi¸co Web geoespacial. O n´umero adequado de invoca¸c˜oes ´e
dependente da t´ecnica, da transparˆencia associada e ´e informado para cada experimento.
Economia de espa¸co refere-se ao n´umero de n´os da ´arvore de deriva¸c˜ao XML, sendo
considerado adequado o n´umero m´ınimo de n´os para a codifica¸c˜ao da informa¸c˜ao ge-
ogr´afica segundo o padr˜ao do OGC para cada servi¸co.
Economia de processamento refere-se ao n´umero de invoca¸c˜oes para requisi¸c˜ao,
obten¸c˜ao do estado da requisi¸c˜ao e obten¸c˜ao do resultado final.
´
E considerado adequado
uma ´unica invoca¸c˜ao de cada tipo e ´e considerado negativo o aumento do n´umero de
invoca¸c˜oes para obten¸c˜ao do estado (pronto ou n˜ao pronto) da requisi¸c˜ao.
Facilidade de implementa¸c˜ao refere-se `a necessidade de introdu¸c˜ao de c´odigo adi-
cional para desempenhar alguma tarefa.
´
E considerado c´odigo adicional a cria¸c˜ao de
classes que n˜ao pertencem ao dom´ınio da aplica¸c˜ao e s˜ao necess´arias para, por exemplo,
manipular dados no formato da GML, implementar um servidor HTTP, etc.
Facilidade de opera¸c˜ao refere-se `a necessidade de intera¸c˜ao com o usu´ario.
´
E con-
siderado adequado o n´umero m´ınimo de intera¸c˜ao para cada transparˆencia e inadequado
a introdu¸c˜ao de qualquer interface adicional com o usu´ario.
Flexibilidade de endere¸camento trata da obrigatoriedade ou n˜ao de um endere¸co
IP v´alido ou de um nome de dom´ınio v´alido.
´
E considerado adequada a n˜ao obrigatorie-
CAP´ıTULO 3. METODOLOGIA E INFRA-ESTRUTURA DE AVALIAC¸
˜
AO 33
dade de um endere¸co IP v´alido.
Flexibilidade de escolha de protocolo de comunica¸c˜ao entre o cliente e o
servi¸co refere-se a independˆencia entre o cliente, os protocolos de comunica¸c˜ao e o servi¸co.
A medida deste RNF ´e o n´umero de protocolos capazes de implementar a comunica¸c˜ao,
sendo considerado adequado o n´umero trˆes, que corresponde ao n´umero de protocolos
usados na avalia¸c˜ao.
Flexibilidade de opera¸c˜ao refere-se ao grau de personaliza¸c˜ao do software-cliente
para o uso de uma determinada cadeia de servi¸cos. A medida ´e formulada pelo n´umero
de servi¸cos que podem ser introduzidos em tempo de execu¸c˜ao na cadeia de servi¸cos.
Independˆencia de provedor refere-se a independˆencia entre o cliente e os provedores
de servi¸cos compostos (n˜ao padronizados).
´
E considerado adequado que um cliente use
um segundo provedor sem mudan¸cas em seu pr´oprio c´odigo.
Independˆencia de rede refere-se a independˆenc ia entre o cliente, os protocolos de co-
munica¸c˜ao e a rede de comunica¸c˜ao atrav´es da qual o cliente comunica-se com os servi¸cos.
Est´a diretamente relacionado com o RNF flexibilidade de endere¸cam ento e est´a em n´ıvel
adequado quando o cliente pode adotar um protocolo diferente daquele usado pelo servi¸co.
Independˆencia de tecnologia refere-se a indepe ndˆencia entre a tecnologia usada
para implementar o software cliente e a tecnologia usada para implementar o servi¸co
geoespacial.
´
E considerado adequado quando a tecnologia de implementa¸c˜ao em ambos ´e
diferente.
Responsabilidade sobre workflow refere-se ao grau de participa¸c˜ao do cliente no
processo de encadeamento de servi¸cos Web geoespaciais, tolerˆancia e recupera¸c˜ao a falhas e
troca de informa¸c˜ao entre servi¸cos usados.
´
E medido pelo n´umero de fluxos de informa¸c˜ao
de sentido servi¸coX, cliente, servi¸coY.
Velocidade de acesso refere-se `a janela de tempo necess´ario para que um cliente
reconhe¸ca que o resultado de sua requisi¸c˜ao est´a dispon´ıvel no servi¸co, em uma chamada
ass´ıncrona.
´
E medido pelo tamanho da janela e est´a diretamente relacionado ao RNF
economia de comunica¸c˜ao. O n´ıvel adequado ´e uma janela de tamanho 0, quando o
cliente ´e notificado sobre a prontid˜ao do resultado assim que o mesmo torna-se dispon´ıvel
no servi¸co.
Velocidade de r ecupera¸c˜ao refere-se ao n´umero de invoca¸c˜oes necess´arias para que
um cliente reinicie (e processe at´e o ponto de falha) ou esteja preparado para continuar
o processamento de uma cadeia de servi¸cos geoespaciais caso um dos componentes falhe.
´
E considerado adequado o n´umero de invoca¸c˜oes necess´arias para encontrar um servi¸co
substituto ou uma r´eplica.
CAP´ıTULO 3. METODOLOGIA E INFRA-ESTRUTURA DE AVALIAC¸
˜
AO 34
3.4.2 Transparˆencia de Acesso
A transparˆencia de acesso refere-se a aspectos tais como protocolo de comunica¸c˜ao
de dados e formato de representa¸c˜ao de dados trocados entre diferentes componentes de
software atrav´es de uma rede de computadores. Os seguintes protocolos podem ser usados
para servi¸cos Web geoespaciais: HTTP sem SOAP [ Whi05], HTTP com SOAP [Son04],
SMTP [CPD06], UDP [Per03]. Os formatos de representa¸c˜ao de dados s˜ao baseados em
XML, sendo que normalmente s˜ao usados documentos GML [Whi05].
Os requisitos n˜ao funcionais (RNF) considerados foram economia de comunica¸c˜ao, eco-
nomia de espa¸co, economia de processamento, facilidade de implementa¸c˜ao, flexibilidade
de endere¸camento, flexibilidade de escolha de protocolo de comunica¸c˜ao entre o cliente e o
servi¸co, independˆencia de provedor, independˆencia de rede e velocidade de acesso, os quais
s˜ao apresentados na tabela 3.1 juntamente com as t´ecnicas de satisfa¸c˜ao implementadas.
Na tabela, os s´ımbolos + e − indicam impactos positivos e negativos, respectivamente,
das t´ecnicas de satisfa¸c˜ao (colunas) sobre os RNF (linhas).
Em I1(ver figura 3.3), o servi¸co que faz a intermedia¸c˜ao entre servi¸cos primitivos e
o cliente foi chamado de servi¸co composto, constru´ıdo por um provedor ou integrador de
servi¸cos, enquanto que cada servi¸co da segunda camada, do OGC, foi chamado servi¸co
primitivo. Na I2 (ver figura 3.4), s´o h´a servi¸cos primitivos em conformidade com o OGC.
HTTP com GET O processo de invoca¸c˜ao atrav´es do m´etodo GET do protocolo
HTTP (sem SOAP), foi implementado assim como especificado pelo OGC para todos os
servi¸cos geoespaciais avaliados, com resposta em XML e GML [Whi05]. Ao RNF economia
de comunica¸c˜ao, o protocolo HTTP com m´etodo GET oferece comunica¸c˜ao orientada a
conex˜ao, sem suporte a assincronicidade. Desse modo, quando o tempo necess´ario para
resposta dos servi¸cos primitivos para o cliente (em I2) foi aumentado, foi implementado um
comportamento ass´ıncrono de invocar, aguardar, perguntar por prontid˜ao e obter resposta
quando pronto. No entanto, como a atividade de perguntar por prontid˜ao inicia-se pelo
cliente, se perce beu um n´umero de invoca¸c˜oes intermedi´arias maior que 1, o que ´e negativo.
Em I1, esse mesmo comportamento foi implementado entre o cliente e o integrador (servi¸co
composto), quando obteve-se o mesmo resultado. A comunica¸c˜ao entre o servi¸co composto
e os servi¸cos primitivos em I1 n˜ao foi avaliada por n˜ao afetar o cliente com rela¸c˜ao a este
RNF.
Quando confrontado com o RNF facilidade de implementa¸c˜ao, o uso de HTTP com
GET exigiu codifica¸c˜ao adicional nos clientes tanto no modelo I1 quanto I2, uma vez que
a codifica¸c˜ao e as restri¸c˜oes de tipo dos parˆametros passados na URI do servi¸co devem
ser convertidos e verificados pelo cliente, al´em de essas propriedades serem definidas pelo
CAP´ıTULO 3. METODOLOGIA E INFRA-ESTRUTURA DE AVALIAC¸
˜
AO 35
RNF HTTP
com
GET
HTTP
com
SOAP
SMTP UDP XML/
GML
Inte-
gra-
dor
CAS CAS
Ga-
teway
Economia de
comunica¸c˜ao
- - + + + +
Economia de
espa¸co
-
Economia de
processamen-
to
+ + + +
Facilidade de
implementa-
¸c˜ao
- + - + + + - +
Flexibilidade
de endere¸ca-
mento
+ + - - - +
Flexibilidade
de escolha de
protocolo de
acesso
+ - +
Independˆencia
de provedor
+ + + + - + +
Independˆencia
de rede
-
Velocidade
de acesso
- - + + + + +
Tabela 3.1: RNF da transparˆencia de acesso e t´ecnicas de satisfa¸c˜ao
desenvolvedor do software, o que ´e negativo.
O RNF flexibilidade de endere¸camento no cliente foi suportado pelo protocolo HTTP
com GET quando o cliente possu´ıa e quando n˜ao possu´ıa um endere¸co IP v´alido, o que
deve-se ao fato de o HTTP ser orientado a conex˜ao e as respostas serem encaminhadas
atrav´es desta conex˜ao, sem o uso do I P para o roteamento.
Al´em disso, uma vez que o protocolo HTTP sem SOAP ´e adotado como padr˜ao pelo
OGC, o RNF independˆencia de provedor foi suportado, ao n˜ao impor qualquer necessidade
de mudan¸cas de c´odigo no software-cliente.
O RNF velocidade de acesso foi medido apenas em transa¸c˜oes longas de servi¸cos geoes-
paciais, quando foi emulada assincronicidade. Para isso, foi considerado adequado quando
o cliente conhecia sobre a prontid˜ao do resultado t˜ao longo este tornava-se dispon´ıvel no
servi¸co e conseq¨uentemente poss´ıvel de ser obtido pelo cliente. Com a implementa¸c˜ao
CAP´ıTULO 3. METODOLOGIA E INFRA-ESTRUTURA DE AVALIAC¸
˜
AO 36
de HTTP o cliente devia invocar o servi¸co para perguntar por prontid˜ao, o que afeta os
RNF economia de comunica¸c˜ao e velocidade de acesso, de modo que quando foi redu-
zido o n ´umero de invoca¸c˜oes o RNF velocidade de acesso foi afetado negativamente; e
mantˆe-lo no n´ıvel adequado apenas foi poss´ıvel pelo aumento do n´umero de invoca¸c˜oes
intermedi´arias, com os efeitos negativos j´a conhecidos para o RNF economia de comu-
nica¸c˜ao
HTTP com SOAP Pela implementa¸c˜ao do protocolo SOAP sobre HTTP [Son04], o
RNF economia de espa¸co, que n˜ao havia sofrido nenhum impacto sem o protocolo SOAP,
foi afetado negativamente pelo fato de este protocolo ter acrescentado pelo menos um
nodo (do envelope SOAP ) n˜ao associado com o esquema OGC na ´arvore de deriva¸c˜ao e m
XML.
No entanto, o RNF facilidade de implementa¸c˜ao foi afetado positivamente por nenhum
c´odigo adicional ter sido introduzido no cliente uma vez que o middleware Apache Axis e
a biblioteca padr˜ao da linguagem de programa¸c˜ao adotada foram suficientes. Por outro
lado, a simples ado¸c˜ao de SOAP sobre HTTP n˜ao afetou outros requisitos importantes,
como velocidade de acesso e economia de comunica¸c˜ao, tornando a maior facilidade de
implementa¸c˜ao a ´unica diferen¸ca percebida.
SMTP A substitui¸c˜ao do protocolo HTTP (s´ıncrono) pelo protocolo SMTP (ass´ıncro-
no), usado para correio eletrˆonico, foi experimentada sobre a proposta de Chung et al
[CPD06] e em seguida pela constru¸c˜ao de um servidor SMTP no cliente, o que favoreceu
o RNF economia de comunica¸c˜ao ao reduzir o n´umero de invoca¸c˜oes intermedi´arias para
0, apesar de exigir ao cliente manter-se online.
O RNF economia de processamento foi ent˜ao afetado positivamente uma vez que ne-
nhum processamento intermedi´ario de verifica¸c˜ao de prontid˜ao ocorreu.
No entanto, o RNF facilidade de implementa¸c˜ao foi afetado negativamente pela ne-
cessidade de transformar o cliente em servidor SMTP, o que exigiu a implementa¸c˜ao de
c´odigo adicional n˜ao relacionado ao dom´ınio da aplica¸c˜ao.
O RNF flexibilidade de endere¸camento tamb´em foi afetado negativamente, pois o cli-
ente como servidor SMTP exige o uso de um endere¸co IP v´alido, o que tornou-o dispon´ıvel
para o servi¸co remoto.
Finalmente, o RNF velocidade de acesso foi afetado positivamente, pois uma noti-
fica¸c˜ao de prontid˜ao do servi¸co para o cliente foi e ncaminhada imediatamente ap´os a
disponibilidade da resposta, com vantagem sobre as t´ecnicas de satisfa¸c˜ao anteriores ao
n˜ao afetar negativamente o RNF economia de comunica¸c˜ao.
CAP´ıTULO 3. METODOLOGIA E INFRA-ESTRUTURA DE AVALIAC¸
˜
AO 37
UDP O segundo protocolo ass´ıncrono implementado foi o UDP, o qual apresentou as
mesmas propriedades do protocolo SMTP, explicado anteriormente. A ´unica diferen¸ca foi
ter afetado negativamente o RNF independˆencia de rede, pelo fato de mensagens UDP
exigirem um endere¸co IP v´alido para o roteamento, al´em de normalmente serem descar-
tados por servidores do tipo firewall, por quest˜oes de seguran¸ca, no trˆansito de mensagens
da extranet para a rede local.
XML/GML A ado¸c˜ao de XML e sua linguagem derivada GML para codifica¸c˜ao afetou
positivamente o RNF facilidade de implementa¸c˜ao ao n˜ao introduzir c´odigo adicional
no cliente para troca de informa¸c˜ao geogr´afica entre servi¸cos e o cliente. Nos clientes,
implementados nas linguagens Java [HC01a, HC01b] e PHP [AB03], foi p oss´ıvel usar
apenas m´etodos de manipula¸c˜ao de XML dispon´ıveis na biblioteca padr˜ao das respectivas
linguagens.
Integrador Especificamente na implementa¸c˜ao 1 (I1), o papel de integrador foi avali-
ado e afetou positivamente o RNF facilidade de implementa¸c˜ao ao n˜ao introduzir c´odigo
adicional no cliente para comunica¸c˜ao entre os servi¸cos primitivos e o cliente.
Adicionalmente, o RNF flexibilidade de escolha de protocolo de acesso para o cli-
ente tamb´em foi impactado positivamente por permitir ao servi¸co composto responder
ao c liente atrav´es de todos os protocolos avaliados (HTTP, SMTP e UDP), simultanea-
mente, e ao cliente receber resposta em qualquer destes protocolos, por´em com preju´ızo
da universalidade do software-cliente, pois o RNF independˆencia de provedor foi afetado
negativamente devido a interface do servi¸co composto n˜ao ser padronizada.
O RNF velocidade de acesso pˆode ser suportado em I1 atrav´es do uso dos protocolos
SMTP e UDP, apenas, sem afetar o RNF economia de comunica¸c˜ao portanto.
CAS e CAS gateway A implementa¸c˜ao e atendimento dos RNF em equil´ıbrio no
cliente d´a-se pelo grupo de funcionalidades denominado CAS, o qual tamb´em pode ser
implementado em um proxy neutro denominado CAS gateway. O RNF economia de
comunica¸c˜ao foi ent˜ao afetado positivamente, pois o CAS emulou assincronicidade ao
introduzir o comportamento de servidor HTTP no cliente (semelhante ao comportamento
de servidor SMTP). Dessa forma, n˜ao houve invoca¸c˜ao intermedi´aria entre as invoca¸c˜oes
de pedido e obten¸c˜ao de resposta. O CAS gateway, por sua vez, possibilitou implementar
o envio de notifica¸c˜oes por meio de um protocolo mais simples (UDP), transferindo para
um proxy neutro a responsabilidade de receber notifica¸c˜oes do servi¸co geoespacial, o que
´e vi´avel em I1 e I2.
CAP´ıTULO 3. METODOLOGIA E INFRA-ESTRUTURA DE AVALIAC¸
˜
AO 38
Conseq¨uentemente, os RNF economia de processamento (n´umero de invoca¸c˜oes in-
termedi´arias igual a 0), facilidade de implementa¸c˜ao (permitiu usar UDP entre cliente e
CAS gateway sem introdu¸c˜ao de c´odigo adicional para implementar um servidor HTTP
ou SMTP), flexibilidade de endere¸camento (cliente pˆode recebe r resposta ass´ıncrona sem
endere¸co IP v´alido) foram afetados positivamente.
O RNF flexibilidade de escolha de protocolo de acesso foi suportado de forma similar ao
suporte dado pelo integrador, por´em sem preju´ızo para o RNF independˆencia de provedor,
uma vez que as func ionalidades s˜ao implementadas no cliente ou no gateway adotado pelo
cliente, sendo esse gateway tamb´em independente dos provedores de servi¸cos primitivos.
Finalmente, por emular assincronicidade e o cliente ser notificado sobre a prontid˜ao da
resposta imediatamente ap´os sua disponibilidade no servi¸co, o RNF velocidade de acesso
foi afetado positivamente.
3.4.3 Transparˆencia de Localiza¸c˜ao
A transparˆencia de localiza¸c˜ao refere-se a localiza¸c˜ao f´ısica dos diversos componentes
de software que constituem o sistema de informa¸c˜ao geogr´afico, o que ´e formado por
clientes, servi¸cos Web gen´ericos (WS), servi¸cos Web geoespaciais (GWS), servidores de
bancos de dados (BD), e outros.
Os requisitos n˜ao funcionais (RNF) considerados foram economia de comunica¸c˜ao,
economia de espa¸co, facilidade de implementa¸c˜ao, facilidade de opera¸c˜ao, flexibilidade de
endere¸camento [cliente, servi¸co, BD], flexibilidade de escolha de protocolo de comunica¸c˜ao
entre o cliente e o servi¸co e independˆencia de provedor, os quais s˜ao apresentados na
tabela 3.2 juntamente com as t´ecnicas de satisfa¸c˜ao imple mentadas.
Um componente importante para qualquer sistema distribu´ıdo ´e o servi¸co de rede do-
main name system (DNS), respons´avel pela tradu¸c˜ao de nomes de dom´ınio para endere¸cos
de Internet, ou endere¸cos IP (Internet Protocol). Atrav´es do DNS, e ndere¸cos IP podem
ser alterados, o que ´e atualizado em tabelas DNS distribu´ıdas. Este componente ´e essen-
cial e sua indisponibilidade exige o uso do e ndere¸co IP do servidor em formato num´erico.
Entretanto, o DNS n˜ao participou de nossos experimentos, apesar de suportar os RNF fle-
xibilidade de endere¸camento [s ervi¸co], flexibilidade de endere¸camento [BD], facilidade de
implementa¸c˜ao [cliente] e facilidade de opera¸c˜ao [cliente], devido a possibilidade de se usar
endere¸co IP dinˆamico com um nome de dom´ınio fixo, al´em da facilidade de configura¸c˜ao
para o usu´ario.
IP A localiza¸c˜ao do cliente ´e importante no contexto dos SIG, especialmente quando
este cliente solicita uma informa¸c˜ao por meio de um protocolo n˜ao orientado a conex˜ao
CAP´ıTULO 3. METODOLOGIA E INFRA-ESTRUTURA DE AVALIAC¸
˜
AO 39
(como o UDP), e o servidor deve encaminhar a resposta para seu endere¸co IP. Com rela¸c˜ao
ao endere¸camento IP, h´a duas possibilidades para o cliente: o cliente tem um IP v´alido,
´unico e acess´ıvel na Internet; ou o cliente n˜ao tem um IP v´alido, isto ´e, o cliente pertence
a uma rede privada (intranet) e acessa a rede p´ublica atrav´es de um IP compartilhado
por todos os clientes da rede privada. No primeiro caso, o cliente ´e acess´ıvel e tem as
mesmas propriedades de servidores de rede. Enquanto segundo caso, o cliente ´e inacess´ıvel
diretamente a partir da rede p´ublica, e qualquer requisi¸c˜ao realizada por aquele cliente tem
a resposta interceptada por um componente da rede privada que faz o encaminhamento
conforme pol´ıticas dessa rede, as quais podem aceitar ou rejeitar determinados servi¸cos,
protocolos e dados.
O segundo caso ´e o mais comum, o que afeta diretamente os RNF flexibilidade de
endere¸camento [cliente] e flexibilidade de escolha de protocolo de comunica¸c˜ao entre o
cliente e o servi¸co [cliente]. No entanto, a primeira t´ecnica de satisfa¸c˜ao implementada foi
a ado¸c˜ao de um IP v´alido para o cliente, atrav´es do qual o cliente pode receber notifica¸c˜oes
a partir de qualquer qualquer localiza¸c˜ao da Internet.
Primeiramente, foi observado que o RNF economia de comunica¸c˜ao foi afetado posi-
tivamente ao permitir que c lientes e servi¸cos fossem conhecidos pelo mesmo IP v´alido e
est´atico sem que buscas em um cat´alogo fossem realizadas a cada invoca¸c˜ao.
O RNF economia de espa¸co, por sua vez, foi afetado negativamente pela imposi¸c˜ao de
conhecer e armazenar r´eplicas e servi¸cos substitutos estaticamente no c´odigo do software-
cliente, embora a possibilidade de fazˆe-lo fosse desej´avel (identificadores est´aticos de
servi¸cos).
Por outro lado, o RNF facilidade de implementa¸c˜ao do cliente foi afetado de forma
positiva ao favorecer o acesso ao cliente, por outros clientes ou pelos servi¸cos, fazendo
com que o cliente se tornasse provedor de parˆametros e feedback. Quando as respostas a
requisi¸c˜oes eram longas, foi implementado um padr˜ao ass´ıncrono de respostas o que foi
favorecido pela existˆencia de um endere¸co IP v´alido para o cliente. Isto tamb´em impactou
positivamente o RNF facilidade de implementa¸c˜ao do servi¸co, pois nenhum mecanismo de
atualiza¸c˜ao de IP para as respostas ass´ıncronas foi implementado, o que seria necess´ario
quando o cliente entrava em modo de espera e quando retornava ao modo online receberia
um endere¸co IP diferente do primeiro.
Por´em, a implementa¸c˜ao desta t´ecnica de satisfa¸c˜ao afetou negativamente o RNF
flexibilidade de ende re¸camento, pois o funcionamento do cliente para obten¸c˜ao de respostas
ass´ıncronas s´o foi poss´ıvel com o uso de endere¸cos IP v´alidos, e foi mais f´acil pelo uso de
endere¸cos IP est´aticos.
Com a atribui¸c˜ao de um endere¸co IP v´alido, est´atico ou dinˆamico, todos os protocolos
CAP´ıTULO 3. METODOLOGIA E INFRA-ESTRUTURA DE AVALIAC¸
˜
AO 40
analisados puderam ser implementados (HTTP, SMTP e UDP), o que afetou positiva-
mente o RNF flexibilidade de escolha de protocolo de acesso no cliente e no servi¸co.
RNF IP Bookmark Cat´alogo Integrador CAS CAS
Ga-
teway
Economia de
comunica¸c˜ao
+ + - +
Economia de
espa¸co
- - + +
Facilidade de
implementa-
¸c˜ao
+ - + + - +
Facilidade
de imple-
menta¸c˜ao
[servi¸co]
+ + +
Facilidade de
opera¸c˜ao
- + +
Flexibilidade
de en-
dere¸camento
- +
Flexibilidade
de escolha de
protocolo de
acesso
+ + - +
Flexibilidade
de escolha
de protocolo
de acesso
[servi¸co]
+ + + +
Independˆencia
de provedor
+ + + - + +
Tabela 3.2: RNF da transparˆencia de localiza¸c˜ao e t´ecnicas de satisfa¸c˜ao
Finalmente, o RNF independˆencia de provedor foi suportado pela implementa¸c˜ao
transparente de troca de mensagens atrav´es dos proto colos analisados, sem mudan¸cas
no software-cliente, especificamente na implementa¸c˜ao 2.
Bookmark Com rela¸c˜ao aos servi¸cos Web e a complexidade de localiza¸c˜ao destes pelo
cliente, foi usado o endere¸co est´atico (URI) de servi¸cos diretamente no c´odigo-fonte do
cliente, o que ´e denominado aqui como bookmark.
CAP´ıTULO 3. METODOLOGIA E INFRA-ESTRUTURA DE AVALIAC¸
˜
AO 41
Os RNF economia de comunica¸c˜ao, economia de espa¸co e independˆencia de provedor
foram afetados de forma similar `a produzida pela t´ecnica de satisfa¸c˜ao IP. No entanto, a
implementa¸c˜ao do carregamento do bookmark produziu efeito negativo no RNF facilidade
de implementa¸c˜ao do cliente, pela necessidade de implementar uma estrutura interna
de dados para r´eplicas e implementar uma interface de atualiza¸c˜ao pelo usu´ario, o que
tamb´em impactou negativamente o RNF facilidade de opera¸c˜ao.
Cat´alogo O uso de cat´alogos de servi¸cos foi outro mecanismo que auxiliou a loca-
liza¸c˜ao de servi¸cos, especialmente quando estes tinham nomes de dom´ınio ou endere¸cos
IP dinˆamicos, ou ainda quando o pr´oprio cliente moveu-se de uma LSDI para outra e
usou servi¸cos de regi˜oes diferentes. Neste ´ultimo caso, o cat´alogo de servi¸cos geogr´aficos
foi ent˜ao usado para requisitar o IP de servi¸cos de mesmo tipo, por´em de LSDI diferentes,
quando o cliente informava um retˆangulo envolvente diferente daquele no qual estava em
requisi¸c˜oes anteriores.
Isso permitiu a localiza¸c˜ao de servi¸cos em tempo de execu¸c˜ao, por meio de buscas no
cat´alogo j´a padronizado, sem a participa¸c˜ao de integradores e sem o armazenamento de
endere¸cos no interior do c´odigo do software-cliente (RNF economia de espa¸co, facilidade
de implementa¸c˜ao, facilidade de opera¸c˜ao e independˆencia de provedor foram afetados
positivamente), por´em a introdu¸c˜ao de transa¸c˜oes espec´ıficas para localiza¸c˜ao dos servi¸cos
de interesse afetou o RNF economia de comunica¸c˜ao.
Integrador Ao avaliar esta transparˆencia na I1, o integrador de servi¸cos se mostrou
´util ao esconder os se rvi¸cos primitivos do cliente e transferir para si a responsabilidade de
localiza¸c˜ao destes servi¸cos, ao contr´ario da t´ecnica de cat´alogo. Isso afetou positivamente
o RNF economia de comunica¸c˜ao e todos os outros anteriormente citados para a t´ecnica
de cat´alogo, com exce¸c˜ao do RNF independˆencia de provedor, uma vez que o cliente n˜ao
teve controle sobre os servi¸cos primitivos usados pelo servi¸co composto. Adicionalmente,
quando o servidor que possui o papel de integrador reside na mesma rede do cliente,
n˜ao h´a problema de o cliente n˜ao possuir IP v´alido na Internet, o que tamb´em afetou
positivamente o RNF flexibilidade de endere¸camento [cliente].
CAS e CAS gateway Mesmo quando o integrador de servi¸cos n˜ao participou da im-
plementa¸c˜ao, como no caso da I2, o servi¸co de cat´alogo de servi¸cos foi adequado para
localiza¸c˜ao dos servi¸cos primitivos, assumindo parte do papel do integrador da I1. No
entanto, algumas facilidades s˜ao desej´aveis para a localiza¸c˜ao de clientes, especialmente
no contexto da I2, onde ´e maior a importˆancia de um IP v´alido da Internet. Assim,
CAP´ıTULO 3. METODOLOGIA E INFRA-ESTRUTURA DE AVALIAC¸
˜
AO 42
s˜ao esperadas melhorias nos RNF facilidade de implementa¸c˜ao [cliente, servi¸co] para su-
porte de respostas ass´ınc ronas, RNF flexibilidade de endere¸camento [cliente], flexibilidade
de escolha de protocolo de acesso [cliente, servi¸co] e independˆencia de provedor. Esses
requisitos foram atendidos pelo grupo de funcionalidades do Client Access Service.
O RNF facilidade de implementa¸c˜ao do cliente foi afetado positivamente por um proxy
neutro com as funcionalidades do CAS, atrav´es do qual notifica¸c˜oes sobre a prontid˜ao do
servi¸co s˜ao enviadas para o cliente, as quais foram encaminhadas pelo proxy ao cliente
mesmo quando o cliente mudou de endere¸co IP local, uma vez que o proxy local tem acesso
privilegiado a tabela de endere¸cos IP. O mesmo RNF para o servi¸co tamb´em foi afetado
positivamente ao possibilitar respostas ass´ıncronas e possibilitar reduzir as exigˆencias de
tempo para respostas a clientes com baixa capacidade de energia.
O RNF flexibilidade de escolha de protocolo de acesso para o cliente foi afetado po-
sitivamente pela atribui¸c˜ao da responsabilidade de intermedia¸c˜ao ao proxy, enquanto a
comunica¸c˜ao entre o proxy neutro e o cliente tornou-se mais flex´ıvel, sendo poss´ıvel im-
plementar protocolos mais simples como o UDP e at´e mesmo protocolos mais espec´ıficos
como o SMS (Short Messages System), das redes de telefonia m´ovel celular.
Finalmente, o RNF independˆencia de provedor foi afetado positivamente (ao contr´ario
do produzido pela t´ecnica de Integrador), por deixar as responsabilidades de interme-
dia¸c˜ao do integrador em um proxy neutro poss´ıvel de ser padronizado e fornecer servi¸co
a m´ultiplos provedores de servi¸co Web geoespacial.
3.4.4 Transparˆencia de Migra¸c˜ao
Esta transparˆencia refere-se a capacidade de reloca¸c˜ao de componentes de software
sem que complexidade seja adicionada nos pr´oprios componentes.
Os requisitos n˜ao funcionais (RNF) considerados foram economia de comunica¸c˜ao,
facilidade de implementa¸c˜ao e independˆencia de provedor, os quais s˜ao apresentados na
tabela 3.3 juntamente com as t´ecnicas de satisfa¸c˜ao imple mentadas.
RNF HTTP UDP Integrador DXS
Economia de
comunica¸c˜ao
+ + + +
Facilidade de
implementa-
¸c˜ao
- - - +
Independˆencia
de provedor
+ + - +
Tabela 3.3: RNF da transparˆencia de migra¸c˜ao e t´ecnicas de satisfa¸c˜ao
CAP´ıTULO 3. METODOLOGIA E INFRA-ESTRUTURA DE AVALIAC¸
˜
AO 43
HTTP A implementa¸c˜ao do protocolo de comunica¸c ˜ao HTTP com SOAP em processos
longos exigiu invoca¸c˜oes em duas chamadas, a primeira para requisi¸c˜ao e a segunda para
obten¸c˜ao do resultado. No entanto, para reduzir o n´umero de invoca¸c˜oes com objetivo de
conhecer o estado de prontid˜ao do resultado, foi implementado o envio de notifica¸c˜ao do
servi¸co para o cliente.
Na I2, sem intermedia¸c˜ao do integrador, o servi¸co informava o cliente atrav´es de tran-
sa¸c˜oes HTTP dirigidas ao cliente (cliente implementado como servidor HTTP). Por´em,
com a motiva¸c˜ao da altera¸c˜ao de endere¸co IP do cliente (cliente em movimento ou cliente
em modo de espera), o cliente foi obrigado a informar o novo endere¸co IP ao servi¸co,
com apenas uma invoca¸c˜ao a cada troca de endere¸co, o que afetou positivamente o RNF
economia de comunica¸c˜ao.
No entanto, o RNF facilidade de implementa¸c˜ao foi afetado negativamente pela neces-
sidade de controle pelo cliente sobre cada transa¸c˜ao, com introdu¸c˜ao de c´odigo adicional
n˜ao relacionado ao dom´ınio da aplica¸c˜ao.
O RNF independˆencia de provedor foi afetado positivamente pela n˜ao necessidade de
um controle centralizado de endere¸co IP do cliente para notifica¸c˜ao aos s ervi¸cos em uso
(em processamento) pelo cliente.
UDP A substitui¸c˜ao do protocolo HTTP pelo protocolo UDP n˜ao retirou do cliente a
necessidade de informar ao servi¸co em processamento a mudan¸ca de endere¸co, uma vez
que a notifica¸c˜ao (agora em UDP) era redirecionada para o endere¸co IP que o cliente tinha
no momento da primeira invoca¸c˜ao. Conseq¨uentemente, nenhuma mudan¸ca nos RNF foi
percebida.
Integrador Em nosso contexto, os componentes que migraram foram os clientes, o que
muitas vezes j´a ´e tratado por protocolos espec´ıficos nas redes de GPRS (General Packet
Radio Services) da telefonia m´ovel, com transferˆencia de pacotes at´e o dispositivo m´ovel
por meio de um controle centralizado na CCC (Central de Comuta¸c˜ao e Controle). Esta
tecnologia n˜ao foi avaliada, apesar do padr˜ao de controle ter sido emulado na I1, atrav´es
do Integrador.
O ´unico resultado percebido, com rela¸c˜ao `as t´ecnicas anteriores, foi um impacto ne-
gativo no RNF independˆencia de provedor, devido a necessidade de introdu¸c˜ao de c´odigo
n˜ao padronizado nos componentes de software.
DXS A manuten¸c˜ao do RNF economia de comunica¸c˜ao e o suporte do RNF inde-
pendˆencia de provedor foi garantido por meio de um mecanismo neutro, o DXS, para o
CAP´ıTULO 3. METODOLOGIA E INFRA-ESTRUTURA DE AVALIAC¸
˜
AO 44
qual respostas s˜ao encaminhadas a partir dos servi¸cos, e de onde s˜ao obtidas as respostas
pelo cliente.
O RNF facilidade de implementa¸c˜ao do cliente tamb´em foi afetado positivamente ao
n˜ao introduzir qualquer c´odigo no software-cliente, exigindo apenas invoca¸c˜oes em duas
chamadas, a primeira para requisi¸c˜ao e a segunda para obten¸c˜ao do resultado diretamente
no DXS.
3.4.5 Transparˆencia de Reloca¸c˜ao
Esta transparˆencia refere-se a reloca¸c˜ao de interfaces de servi¸cos usadas por outros
servi¸cos ou por clientes finais, isto ´e, refere-se a invoca¸c˜ao de servi¸cos que migraram de
um local para outro sem mudan¸cas substanciais nos clientes destes servi¸cos.
Os requisitos n˜ao funcionais (RNF) considerados foram economia de comunica¸c˜ao,
economia de processamento, facilidade de implementa¸c˜ao, independˆencia de provedor e
independˆencia de tecnologia [cliente, servi¸co], os quais s˜ao apresentados na tabela 3.4
juntamente com as t´ecnicas de satisfa¸c˜ao implementadas.
A migra¸c˜ao de servi¸cos n˜ao ´e prevista pelo OGC, embora seja prevista neste trabalho
por meio de aplica¸c˜oes para os servi¸cos Data Exchange Service e Client Access Service
, atrav´es dos quais clientes podem ser usados como provedores de informa¸c˜ao geogr´afica
para outros clientes e mesmo para servi¸cos que coletam informa¸c˜ao em tempo real. Esta
transparˆencia muitas ve zes depende da transparˆencia de replica¸c˜ao, na pr´oxima se¸c˜ao.
RNF Acesso
Direto
Integrador CAS
Gateway
Economia de
comunica¸c˜ao
- + -
Economia
de processa-
mento
- + -
Facilidade de
implementa-
¸c˜ao
- + -
Independˆencia
de provedor
+ + +
Independˆencia
de tecnologia
- + +
Tabela 3.4: RNF da transparˆencia de reloca¸c˜ao e t´ecnicas de satisfa¸c˜ao
Duas possibilidades de reloca¸c˜ao, neste sentido, se relacionam com os dados (reloca¸c˜ao
da fonte de dados) e com fun¸c˜oes (reloca¸c˜ao de servi¸cos). Em nosso cen´ario, a reloca¸c˜ao ´e
CAP´ıTULO 3. METODOLOGIA E INFRA-ESTRUTURA DE AVALIAC¸
˜
AO 45
materializada principalmente em balanceamento de carga, quando o cliente ´e redirecionado
transparentemente para outro servidor de dados ou fun¸c˜oes, seja este servidor uma r´eplica
ou substituto do servi¸co requisitado. Uma terceira p ossibilidade de reloca¸c˜ao se relaciona
com o movimento da fonte de dados, no caso de provedores de dados m´oveis tais como
redes de geosensores sem fio e clientes m´oveis usados como provedores de informa¸c˜ao em
tempo real.
Acesso Direto O terceiro caso, relacionado ao cliente m´ovel como servi¸co de informa¸c˜ao
geogr´afica, exige que o novo endere¸co IP seja informado para outros clientes e servi¸cos
atrav´es do envio de mensagens, sendo que, dispensado o integrador na I2, uma mensa-
gem ´e enviada para cada mudan¸ca de endere¸co IP, o que afetou o RNF economia de
comunica¸c˜ao para o cliente real.
O RNF economia de processamento tamb´em foi afetado negativamente devido a ne-
cessidade de alterar o endere¸co f´ısico do servi¸co no cliente para as pr´oximas invoca¸c˜oes.
Adicionalmente, isso produziu efeito negativo nos RNF facilidade de implementa¸c˜ao, em
fun¸c˜ao da introdu¸c˜ao de c´odigo espec´ıfico para atualiza¸c˜ao de IP, e independˆencia de tec-
nologia, devido a necessidade de comunica¸c˜ao ass´ıncrona para notifica¸c˜ao aos clientes e a
conseq¨uente imposi¸c˜ao de alguns protocolos ou funcionalidades ao cliente.
No entanto, o RNF independˆencia de provedor foi afetado positivamente na I2, pela n˜ao
participa¸c˜ao do integrador da I1, apesar de n˜ao haver interface padronizada de notifica¸c˜ao
ao cliente sobre mudan¸cas de endere¸co do servi¸co.
Integrador Na I2, atividades de mudan¸ca de endere¸co dos servi¸cos primitivos foram
atribu´ıdas integralmente ao integrador, as quais tornaram-se transparentes para o cli-
ente. Neste contexto, o servi¸co continua a acessar o servi¸co primitivo atrav´es do servi¸co
composto, ou ainda atrav´es de um “apelido” dado `aquele servi¸co pelo integrador. Toda
altera¸c˜ao de endere¸co ´e informada ao integrador, sem trocas de mensagens entre o servi¸co
primitivo e o cliente, o que afetou positivamente os RNF economia de comunica¸c˜ao e
economia de processamento.
Como nenhuma informa¸c˜ao ´e dada ao cliente e nenhuma mudan¸ca de comportamento
´e exigida do cliente, os RNF facilidade de implementa¸c˜ao e independˆencia de tecnologia
s˜ao igualmente afetados de forma positiva.
Finalmente, ao implementar o integrador como um proxy neutro, atrav´es do qual os
servi¸cos primitivos s˜ao acessados indiretamente por meio de um “apelido” fixo, compor-
tamento este que pode ser implementado no integrador ou at´e mesmo no cat´alogo de
servi¸cos, o RNF independˆencia de provedor tamb´em foi afetado positivamente, pois a
CAP´ıTULO 3. METODOLOGIA E INFRA-ESTRUTURA DE AVALIAC¸
˜
AO 46
presen¸ca do integrador tamb´em se tornou transparente ao cliente, sem afetar os demais
RNF.
De volta `a I2, foi implementado um proxy com as funcionalidades do Client Access
Service, sendo que as responsabilidades de reloca¸c˜ao retornaram para o cliente. Isso
afetou os RNF economia de comunica¸c˜ao, economia de processamento e facilidade de
implementa¸c˜ao pelas mesmas raz˜oes impostas pela t´ecnica de Acesso Direto.
A ´unica vantagem desta t´ecnica sobre a de Acesso Direto foi o efeito positivo sobre o
RNF independˆencia de tecnologia, uma vez que o CAS retirou as restri¸c˜oes de protocolo
para o recebimento de mensagens ass´ıncronas do servi¸co para o proxy, e deste para o
cliente.
No entanto, ´e poss´ıvel concluir que o papel de integrador em I2 (como um proxy
neutro) ´e superior as outras t´ecnicas e apenas n˜ao se aplica em certos contextos, tais
como aqueles nos quais s˜ao usados apenas clientes gordos.
3.4.6 Transparˆencia de Replica¸c˜ao
A transparˆencia de replica¸c˜ao refere-se a cria¸c˜ao de r´eplicas consistentes para aumentar
o dese mpenho e a disponibilidade do sistema. Podem ser replicados os dados ou os ban-
cos de dados geogr´aficos (BD), os servidores f´ısicos de um mesmo provedor, ou servi¸cos
geogr´aficos em provedores diferentes, sendo que estes ´ultimos n˜ao devem ser necessari-
amente consistentes mas apenas equivalentes. Podem ainda ser replicados servi¸cos de
infra-estrutura tais como cat´alogos de servi¸cos e o servi¸co Domain Name System (DNS)
para atribui¸c˜ao de endere¸cos de Internet a dom´ınios.
Os requisitos n˜ao funcionais (RNF) considerados foram economia de comunica¸c˜ao,
economia de processamento, facilidade de implementa¸c˜ao, facilidade de opera¸c˜ao e inde-
pendˆencia de provedor, os quais s˜ao apresentados na tabela 3.5 juntamente com as t´ecnicas
de satisfa¸c˜ao implementadas.
Integrador A transferˆencia de responsabilidade sobre r´eplicas para o provedor de ser-
vi¸cos compostos (caso da I1) foi suficiente para assegurar o suporte aos RNF economia
de comunica¸c˜ao, economia de processamento, facilidade de implementa¸c˜ao e facilidade de
opera¸c˜ao, pois o controle sobre falhas e ado¸c˜ao de r´eplicas foi atribu´ıdo integralmente
ao integrador e tornou-se transparente para o cliente, apesar de prejudicar o RNF in-
dependˆencia de provedor, uma vez que n˜ao havia mecanismos de verifica¸c˜ao sobre quais
servi¸cos foram usados pelo integrador e a quais fornecedores tais servi¸cos pertencem. Isto
´e particularmente importante para definir qualidade e consistˆencia das r´eplicas, o que
torna-se poss´ıvel pelo acess o a informa¸c˜oes do cat´alogo ou pelo acesso direto aos servi¸cos.
CAP´ıTULO 3. METODOLOGIA E INFRA-ESTRUTURA DE AVALIAC¸
˜
AO 47
RNF Integrador Bookmark Cat´alogo TCS
Economia de
comunica¸c˜ao
+ + - -
Economia
de processa-
mento
+ - + -
Facilidade de
implementa-
¸c˜ao
+ - + +
Facilidade de
opera¸c˜ao
+ - + +
Independˆencia
de provedor
- + + +
Tabela 3.5: RNF da transparˆencia de replica¸c˜ao e t´ecnicas de satisfa¸c˜ao
Bookmark Ao retirar o papel de integrador, foi atribu´ıdo ao cliente o papel de invocar
r´eplicas em caso de indisponibilidade. No entanto, o endere¸co de servi¸cos n˜ao indica
r´eplicas uniformemente e o conhecimento sobre sua existˆencia e as URI correspondentes
deviam ser conhecidas antecipadamente.
Um modelo de bookmark interno ao software-cliente foi implementado e afetou negati-
vamente os RNF economia de processamento, devido a necessidade de controle de falhas e
carregamento de interfaces de r´eplicas, facilidade de implementa¸c˜ao, devido a introdu¸c˜ao
de URI de r´eplicas no c´odigo do software-cliente e necessidade de cria¸c˜ao de interface de
atualiza¸c˜ao com o usu´ario, e tamb´em o RNF facilidade de opera¸c˜ao, nos casos em que
URI mudavam e o usu´ario devia fazer atualiza¸c˜oes.
O RNF independˆencia de provedor, por sua vez, foi afetado positivamente devido ao
acesso direto ao cat´alogo, aos servi¸cos e seus respectivos servi¸cos s ubstitutos e r´eplicas.
Cat´alogo Ao contr´ario do bookmark, o cat´alogo tamb´em foi usado como fonte de in-
forma¸c˜ao sobre r´eplicas, o que mostrou-se negativo para o RNF economia de comunica¸c˜ao.
Por´em, todos os outros RNF foram afetados positivamente atrav´es da busca por r´eplicas no
cat´alogo, remotamente e da n˜ao necessidade de introduzir r´eplicas no c´odigo do software-
cliente nem de criar interface de atualiza¸c˜ao para o usu´ario.
TCS Implementar mecanismos mais robustos de uso de r´eplicas sem prejudicar requisi-
tos tais como economia de comunica¸c˜ao, economia de processamento e independˆencia de
provedor ´e desej´avel. Al´em disso tais requisitos impactam diferentemente em diferentes
contextos e dispositivos, o que impede que uma configura¸c˜ao ´unica seja a ideal sempre.
CAP´ıTULO 3. METODOLOGIA E INFRA-ESTRUTURA DE AVALIAC¸
˜
AO 48
Isto pode ser atendido automaticamente pelo Transaction Control Service o qual permite
configurar tais requisitos para diferentes contextos e dispositivos.
O cliente recebeu quatro c´odigos compat´ıveis com as t´ecnicas Integrador, Bookmark
e Cat´alogo, e o quarto c´odigo foi respons´avel por combinar os RNF para favorecˆe-los em
uma distribui¸c˜ao diferente daquelas criadas pelas t´ecnicas de satisfa¸c˜ao anteriores. Pelo
c´odigo constru´ıdo, a busca em um cat´alogo foi realizada em caso de falhas, o que im-
pactou negativamente o RNF economia de comunica¸c˜ao, deixou o tratamento de falhas a
cargo do cliente, o que afetou negativamente o RNF economia de processamento, permitiu
atualiza¸c˜ao da lis ta de servi¸cos substitutos no cliente atrav´es do cat´alogo e introduziu o
quarto c´odigo automaticamente no software-cliente, o que favoreceu os RNF facilidade de
implementa¸c˜ao e facilidade de opera¸c˜ao, al´em de ter mantido o acesso direto aos servi¸cos
(sem integrador) para o cliente, o que afetou de forma positiva o RNF independˆencia de
provedor.
3.4.7 Transparˆencia de Persistˆe ncia
Esta transparˆencia refere-se a cria¸c˜ao e uso de objetos no lado do servidor, o que princi-
palmente melhora o desempenho de espa¸co e processamento em componentes distribu´ıdos
de software.
Os requisitos n˜ao funcionais (RNF) considerados foram economia de comunica¸c˜ao [cli-
ente, servi¸co], economia de espa¸co [cliente, servi¸co], economia de processamento, facilidade
de implementa¸c˜ao [cliente, servi¸co], independˆencia de provedor e independˆencia de tecno-
logia [cliente, servi¸co], os quais s˜ao apresentados na tabela 3.6 juntamente com as t´ecnicas
de satisfa¸c˜ao implementadas.
As transparˆencias e suas t´ecnicas de satisfa¸c˜ao adotadas muitas vezes interferem umas
nas outras. Este ´e o caso do suporte a persistˆencia no lado do servidor para uma maior
tolerˆancia a falhas. Para isto, ´e essencial que o estado das transa¸c˜oes seja armazenado
em diferentes componentes distribu´ıdos pela rede, especialmente na presen¸ca de meios de
comunica¸c˜ao inst´aveis ou caros.
Como ilustra¸c˜ao, se uma opera¸c˜ao qualquer falha ap´os uma seq¨uˆencia longa de ope-
ra¸c˜oes no interior de uma cadeia de servi¸cos, o cliente deve rastrear o servi¸co que falhou,
selecionar uma r´eplica e invoc´a-la dinamicamente sem o reenvio de dados, que j´a est˜ao
em algum meio remoto, ou a inicializa¸c˜ao de toda a cadeia de servi¸cos.
Framework Mas isto n˜ao ´e trivial de se implementar, uma vez que as incompatibili-
dades entre servi¸cos OGC e servi¸cos W3C dificultam o uso de mecanismos prontos de
persistˆencia oferecidos por servidores de aplica¸c˜ao (.NET ou J2EE, por exemplo). Por´em,
CAP´ıTULO 3. METODOLOGIA E INFRA-ESTRUTURA DE AVALIAC¸
˜
AO 49
como tais mecanismos s˜ao projetados para servidores de aplica¸c˜ao espec´ıficos, ´e uma
hip´otese v´alida que alguns deles possam prejudicar o RNF independˆencia de tecnologia
[cliente, servi¸co].
Com isso, o RNF economia de comunica¸c˜ao ´e afetado negativamente, pois servi¸cos n˜ao
podem acessar outros servi¸cos incompat´ıveis para recuperar dados persistentes, e na I2,
com acesso direto, o cliente ´e obrigado a armazenar uma identifica¸c˜ao para recupera¸c˜ao
do dado persistente, em tipo diferente quando comparadas diferentes tecnologias, o que
tamb´em afeta negativamente o RNF economia de espa¸co.
Como uma parcela de tarefas ´e transferida para o lado do servidor, a ado¸c˜ao de um
framework favorece os RNF economia de processamento e facilidade de implementa¸c˜ao
do cliente e do servi¸co, apesar de afetar negativamente o RNF independˆencia de provedor,
uma vez que cada provedor pode adotar uma tecnologia diferente.
RNF Framework Integrador Servi¸co
OGC
DXS
Economia de co-
munica¸c˜ao [cliente,
servi¸co]
- + - +
Economia de
espa¸co [cliente,
servi¸co]
- + + +
Economia de pro-
cessamento
+ + + +
Facilidade de
implementa¸c˜ao
[cliente]
+ + + +
Facilidade de
implementa¸c˜ao
[servi¸co]
+ + + +
Independˆencia de
provedor
- - + +
Independˆencia de
tecnologia [cliente]
- + + +
Independˆencia de
tecnologia [servi¸co]
- + + +
Tabela 3.6: RNF da transparˆencia de persistˆencia e t´ecnicas de satisfa¸c˜ao
Integrador A I1 concentrou responsabilidades por persistˆencia no integrador, afetando
de forma positiva o RNF independˆencia de tecnologia, mas com conseq¨uente impacto ne-
CAP´ıTULO 3. METODOLOGIA E INFRA-ESTRUTURA DE AVALIAC¸
˜
AO 50
gativo no RNF independˆencia de provedor, uma vez que o OGC n˜ao definiu interfaces para
objetos remotos. Foram ent˜ao atribu´ıdos identificadores para transa¸c˜oes, possibilitando
solicitar o reenvio de uma resposta j´a recebida e solicitar uma resposta ass´ıncrona atrav´es
de uma segunda chamada (transa¸c˜oes longas), atrav´es do fornecimento do identificador
da primeira invoca¸c˜ao.
Esse procedimento afetou positivamente os RNF economia de comunica¸c˜ao, economia
de espa¸co, apesar da responsabilidade de armazenar os identificadores, economia de pro-
cessamento, poss´ıvel pela capacidade de reuso de dados previamente processados e n˜ao
conclu´ıdos devido a ocorrˆencia de falhas, facilidade de implementa¸c˜ao, por implementar
persistˆencia totalmente do lado do integrador, e finalmente independˆencia de tecnologia,
ao deixar apenas a responsabilidade de armazenamento de identificadores de transa¸c˜ao
para o cliente.
Servi¸co OGC Na I2 foi tamb´em experimentado deixar a responsabilidade de per-
sistˆencia para o servi¸co, o que j´a existe para o servi¸co de roteamento, atrav´es do qual
´e poss´ıvel recuperar trechos da rota ap´os se ter percorrido alguma parte do pe rcurso.
Todo esfor¸co na I2 fez com que a responsabilidade do workflow fosse atribu´ıda ao
cliente, equiparando esta t´ecnica `a t´ecnica Framework, exceto pelo RNF independˆencia
de tecnologia no cliente, o qual foi afetado positivamente por criar a possibilidade do
controle de persistˆencia de dados atrav´es de simples identificadores de transa¸c˜ao.
DXS Em seguida, tal recurso foi movido dos servi¸cos primitivos para um servi¸co gen´eri-
co, respons´avel por receber respostas de servi¸cos primitivos, armazen´a-las e encaminh´a-las
ao cliente sempre que solicitado, o que ´e suportado pelo Data Exchange Service. Isto se
mostrou adequado para todos os RNF, inclusive para o RNF economia de comunica¸c˜ao
[cliente] no contexto da I2, o qual ainda n˜ao havia sido afetado positivamente naquele
modelo de computa¸c˜ao, ao permitir o encadeamento de servi¸cos em um workflow atrav´es
do qual a resposta de um servi¸co serve como parˆametro para o pr´oximo da cadeia de
servi¸cos.
3.4.8 Transparˆencia de Falha
Esta transparˆencia refere-se a recupera¸c˜ao do sistema e suporte a disponibilidade caso
falhas ocorram nos componentes que atendem o sistema, tais como falhas nas redes de
computadores, paradas de software, nega¸c˜ao de acesso a servi¸co, e outros.
Os requisitos n˜ao funcionais (RNF) considerados foram auditabilidade de componentes,
economia de comunica¸c˜ao, economia de espa¸co, economia de processamento, facilidade
CAP´ıTULO 3. METODOLOGIA E INFRA-ESTRUTURA DE AVALIAC¸
˜
AO 51
de implementa¸c˜ao, independˆencia de provedor e velocidade de recupera¸c˜ao, os quais s˜ao
apresentados na tabela 3.7 juntamente com as t´ecnicas de satisfa¸c˜ao implementadas.
RNF Integrador Bookmark Cat´alogo TCS DXS
Auditabilidade
de componentes
- + +
Economia de co-
munica¸c˜ao
+ - - +
Economia de
espa¸co
+ - - +
Economia de
processamento
- + + +
Facilidade de
implementa¸c˜ao
+ - + + +
Independˆencia
de provedor
- + + + +
Velocidade de
recupera¸c˜ao
- - +
Tabela 3.7: RNF da transparˆencia de falha e t´ecnicas de satisfa¸c˜ao
A implementa¸c˜ao de tolerˆancia a falhas, fator importante para viabilizar o uso de
sistemas de informa¸c˜ao geogr´aficos no suporte a aplica¸c˜oes de miss˜ao cr´ıtica, ´e garantida
por meio de servi¸cos OGC tanto em I1 quanto em I2.
Integrador No entanto, na I1 o integrador ´e respons´avel pela implementa¸c˜ao de to-
lerˆancia a falhas, sem qualquer mecanismo de auditoria (o que ´e obrigat´orio: RNF audi-
tabilidade de componentes) para o cliente. Assim, o cliente n˜ao tem como validar, testar
e comparar dois provedores no aspecto de tolerˆancia a falhas. Apesar disso, os RNF
economia de comunica¸c˜ao, economia de espa¸co e facilidade de implementa¸c˜ao foram be-
neficiados pela transferˆencia de responsabilidade do cliente para o Integrador. Finalmente,
o principal RNF prejudicado foi a independˆencia de provedor, uma vez que qualquer dis-
cordˆancia com as pol´ıticas de tolerˆancia a falhas s´o pode ser resolvida pela ado¸c˜ao de
outro provedor, o que se mostra dif´ıcil por ausˆencia de padroniza¸c˜ao das interfaces de
servi¸cos compostos.
Bookmark Ao transferir a responsabilidade sobre a tolerˆancia a falhas para o cliente,
o controle de r´eplicas e substitutos foram primeiramente armazenados no cliente estati-
camente, atrav´es da t´ecnica bookmark. A simples transferˆencia favoreceu os RNF audita-
bilidade de componentes, ao permitir acesso aos metadados dos servi¸cos, e independˆencia
CAP´ıTULO 3. METODOLOGIA E INFRA-ESTRUTURA DE AVALIAC¸
˜
AO 52
de provedor, pois foram usadas apenas interfaces padronizadas dos servi¸cos primitivos.
No entanto, quando servi¸cos foram induzidos a falhar, os RNF economia de comu-
nica¸c˜ao, economia de espa¸co, economia de processamento e velocidade de recupera¸c˜ao
foram impactados negativamente, pois o cliente ocupou-se do reenvio dos parˆametros
originais ao reiniciar o workflow, do armazenamento dos parˆametros e resultados inter-
medi´arios j´a processados para controle do workflow e do processamento e transmiss˜ao das
informa¸c˜oes intermedi´arias para evitar a reinicializa¸c˜ao do workflow. Adicionalmente, o
RNF facilidade de implementa¸c˜ao tamb´em foi afetado negativamente, pela necessidade
de definir estaticamente os servi¸cos substitutos e r´eplicas.
Cat´alogo A introdu¸c˜ao do cat´alogo de servi¸cos possibilitou encontrar servi¸cos substi-
tutos ou r´eplicas dinamicamente, o que f avoreceu o RNF facilidade de implementa¸c˜ao, o
que permitiu selecionar novos servi¸cos a partir da regi˜ao geoespacial `a qual est˜ao asso-
ciados e das funcionalidades oferecidas pelos servi¸cos primitivos, sem contudo e liminar a
necessidade de reenvio de informa¸c˜ao e controle do workflow.
TCS e DXS Assim, um servi¸co baseado no Data Exchange Service foi usado para
eliminar a necessidade de reenvio de informa¸c˜ao em caso de falhas, quando parˆametros
e resultados ficaram armazenados no servidor DXS. Isso afetou positivamente os RNF
economia de comunica¸c˜ao, economia de espa¸co e economia de processamento, al´em do
RNF velocidade de recupera¸c˜ao pela n˜ao necessidade de reenvio dos parˆametros originais
e da possibilidade de recuperar-se de falhas sem a reinicializa¸c˜ao de todo o workflow.
Toda a complexidade associada ao workflow e o DXS foi gerada automaticamente como
c´odigo execut´avel pelo cliente atrav´es do servi¸co TCS, o qual finalmente favoreceu os RNF
economia de processamento e principalmente facilidade de implementa¸c˜ao.
3.4.9 Transparˆencia de Transa¸c˜ao
Esta transparˆencia refere-se a coordena¸c˜ao de tarefas entre grupos de componentes
de software, o que atribui uma semˆantica de processo (workflow) baseada na ordem das
invoca¸c˜oes, mesmo no caso de falhas ou na ocorrˆencia de decis˜oes do usu´ario via intera¸c˜oes
com o sistema.
Os requisitos n˜ao funcionais (RNF) considerados foram controle sobre componentes,
economia de comunica¸c˜ao, economia de processamento, facilidade de implementa¸c˜ao, fle-
xibilidade de opera¸c˜ao, independˆencia de provedor e responsabilidade sobre workflow, os
quais s˜ao apresentados na tabela 3.8 juntamente com as t´ecnicas de satisfa¸c˜ao implemen-
tadas.
CAP´ıTULO 3. METODOLOGIA E INFRA-ESTRUTURA DE AVALIAC¸
˜
AO 53
Integrador Na I1, toda a coordena¸c˜ao do workflow de um servi¸co geogr´afico ficou sob
a responsabilidade do integrador de servi¸cos, apesar de ainda ser permitido ao software-
cliente reunir cadeias de servi¸co (de um ou mais integradores) em um workflow do cliente.
Essa retirada de responsabilidade do cliente para o integrador (em I1) afetou negativa-
mente o RNF controle sobre componentes, uma vez que n˜ao h´a uma interface padronizada
para acesso indireto aos metadados dos servi¸cos primitivos. No entanto, essa situa¸c˜ao
beneficiou o RNF economia de comunica¸c˜ao, ao reduzir para 0 o n´umero de invoca¸c˜oes do
tr´afego intermedi´ario entre a primeira invoca¸c˜ao e a obten¸c˜ao do resultado final, o RNF
economia de processamento, ao deixar para o integrador toda a responsabilidade sobre o
processamento intermedi´ario, e beneficiou o RNF facilidade de implementa¸c˜ao, ao retirar
c´odigo do software-cliente e equipar´a-lo a categoria de “cliente magro”.
Por outro lado, o RNF flexibilidade de opera¸c˜ao foi afetado negativamente devido ao
fato de o cliente n˜ao ser capaz de redefinir o workflow segundo suas necessidades. O RNF
independˆencia de provedor foi afetado pela mesma propriedade, pois quaisquer mudan¸cas
de workflow, qualidade de servi¸co ou outra caracter´ıstica exigiu a mudan¸ca de servi¸co
composto, de outro integrador. Finalmente, o RNF responsabilidade sobre workflow foi
afetada negativamente pelo fato de o cliente n˜ao foi capaz de testar diferentes workflows
e assegurar atributos importantes como privacidade e tolerˆancia a falhas.
RNF Integrador TCS DXS
Controle sobre
componentes
- +
Economia de comu-
nica¸c˜ao
+ - +
Economia de pro-
cessamento
+ - +
Facilidade de im-
plementa¸c˜ao
+ + +
Flexibilidade de
opera¸c˜ao
- +
Independˆencia de
provedor
- +
Responsabilidade
sobre workflow
- +
Tabela 3.8: RNF da transparˆencia de transa¸c˜ao e t´ecnicas de satisfa¸c˜ao
TCS e DXS Ao atribuir as resp onsabilidades citadas ao cliente, o impacto sobre os
RNF ´e exatamente o oposto, o que ´e negativo para os RNF economia de comunica¸c˜ao
CAP´ıTULO 3. METODOLOGIA E INFRA-ESTRUTURA DE AVALIAC¸
˜
AO 54
e economia de processamento, requisitos essenciais para os clientes magros e ricos, e ´e
tamb´em negativo para o RNF facilidade de implementa¸c˜ao. O equil´ıbrio de responsabi-
lidades entre os lados de cliente e de servidor s´o ´e poss´ıvel com a ado¸c˜ao conjunta dos
servi¸cos Transaction Control Service e Data Exchange Service, sendo que a parcela de
contribui¸c˜ao de cada um ´e mostrada na matriz de adjacˆencia representada na tab ela 3.8,
onde o DXS melhorou os RNF economia de comunica¸c˜ao, economia de processamento e
facilidade de implementa¸c˜ao, ao manter os resultados preliminares ou intermedi´arios no
lado do servidor, em um reposit´orio tempor´ario, ao evitar que manipula¸c˜ao de fluxos de
dados extensos acontecessem no cliente e finalmente ao facilitar o encaminhamento de
respostas de um servi¸co para outro servi¸co, o qual os recebe como parˆametros. O TCS,
por sua vez, resolveu as limita¸c˜oes encontradas anteriormente nos RNF flexibilidade de
opera¸c˜ao, independˆencia de provedor e responsabilidade sobre workflow, ao facilitar o de-
senvolvimento de clientes no contexto de I2 e introduzir c´odigo do DXS automaticamente.
3.4.10 Avalia¸c˜ao: Transparˆencias no Desenvolvimento de Clien-
tes
A implementa¸c˜ao 1 (I1), descrita na se¸c˜ao 3.2.2, imp˜oe o uso de um provedor co-
nhecido que intermedeia a comunica¸c˜ao entre o software-cliente e os v´arios servi¸cos e
servidores que comp˜oem a LSDI. Por outro lado, a implementa¸c˜ao 2 (I2), descrita na
se¸c˜ao 3.2.3, n˜ao usa esse provedor conhecido e obriga o cliente a acessar diretamente os
v´arios servi¸cos e servidores, bem como a processar toda a informa¸c˜ao geogr´afica obtida
durante as requisi¸c˜oes.
Com essas diferen¸cas, o primeiro padr˜ao tornou simples o desenvolvimento de clien-
tes e servidores com requisitos de engenharia importantes. No entanto, o mesmo padr˜ao
introduziu dependˆencia excessiva dos clientes em rela¸c˜ao a provedores de servi¸cos, especi-
almente em situa¸c˜oes onde n˜ao h´a informa¸c˜ao sobre os recursos (pr´oprios e de terceiros)
usados pelos provedores.
Por outro lado, o segundo padr˜ao de distribui¸c˜ao tornou poss´ıvel ao cliente o acesso aos
metadados das fontes originais. No entanto, essa abordagem exigiu o abandono do papel
de “integrador de servi¸cos”, do qual se ocupa o provedor no suporte aos RNF economia
de comunica¸c˜ao e economia de processamento, principalmente. De uma maneira geral,
o padr˜ao causou, para o cliente, um aumento dos custos de tr´afego e processamento de
dados intermedi´arios, uma vez que o cliente tornou-se respons´avel por requisi¸c˜oes a v´arios
servi¸cos e, uma vez que ele recebe as respectivas respostas, algumas opera¸c˜oes sobre estes
dados intermedi´arios s˜ao necess´arias antes do encaminhamento destes como entrada para
CAP´ıTULO 3. METODOLOGIA E INFRA-ESTRUTURA DE AVALIAC¸
˜
AO 55
os pr´oximos servi¸cos da cadeia de servi¸cos. Mas este padr˜ao tamb´em possibilitou monito-
rar e definir parˆametros e requisitos de engenharia no lado do cliente e, conseq¨uentemente,
aumentou a independˆencia e do cliente em rela¸c˜ao aos provedores de servi¸co e permitiu a
adequa¸c˜ao do workflow a capacidade do dispositivo onde o cliente ´e executado.
Modulariza¸c˜ao
Funcionalidade e dados s˜ao encapsulados em servi¸cos Web diretamente em seus prove-
dores ou fornecedores originais. No entanto, percebeu-se que a I1 exigiu a cria¸c˜ao de tantos
servi¸cos n˜ao-OGC quantas fossem as necessidades urbanas espec´ıficas apresentadas. Dessa
maneira, novas especializa¸c˜oes de servi¸co tornaram-se dif´ıceis e fortemente dependentes
de uma solu¸c˜ao sem possibilidade de atendimento das es pecifica¸c˜oes do OWS e OpenLS
(Perspectiva Tecnol´ogica do ORM). Isso ´e resultado da impossibilidade de se construir
um cliente magro que invoque diretamente os servi¸cos do OGC, por estes servi¸cos impo-
rem um tr´afego intermedi´ario maior do que estes clientes s˜ao capazes de manipular, como
descrito na transparˆencia de acesso, se¸c˜ao 3.4.2.
Por´em, a constru¸c˜ao de sistemas modulares no provedor (em I1) ´e garantida pela im-
plementa¸c˜ao e invoca¸c˜ao de servi¸cos assim como especificados pelo OGC, pois o integrador
de servi¸cos tem maior flexibilidade de implementa¸c˜ao que um cliente magro em I2. Por
outro lado, um cliente gordo em I2 pode manter a propriedade de modularidade em um
n´ıvel adequado ao n˜ao possuir as limita¸c˜oes presentes no cliente magro, e neste caso tem
capacidade compar´avel a de um provedor.
Personaliza¸c˜ao de Sistemas
H´a dois usu´arios poss´ıveis para um servi¸co Web geoespacial: desenvolvedores de novos
servi¸cos (enfatizado em I1) e desenvolvedores de softwares-cliente (enfatizado em I2), o
que representou o principal foco desta pesquisa.
Desenvolvedores implementam softwares-cliente pela invoca¸c˜ao de servi¸cos Web su-
portados por provedores de servi¸co ou pela invoca¸c˜ao de servi¸cos primitivos do OGC
diretamente, sem intermedi´arios. No primeiro caso, percebeu-se a dificuldade de garantir
a universalidade do software-cliente, uma vez que os servi¸cos n˜ao s˜ao padronizados em
seu n´ıvel conceitual (perspectiva Organizacional do ORM).
No segundo caso, ´e poss´ıvel garantir a universalidade do software-cliente, mas com
dificuldades no mapeamento da perspectiva de Engenharia para a perspectiva Tecnol´ogica,
isto ´e, na implementa¸c˜ao de componentes de software adequados para a variedade de
aplica¸c˜oes-cliente e dispositivos-cliente, especialmente no contexto urbano dos servi¸cos de
CAP´ıTULO 3. METODOLOGIA E INFRA-ESTRUTURA DE AVALIAC¸
˜
AO 56
localiza¸c˜ao.
Dessa forma, h´a dificuldades na personaliza¸c˜ao de sistemas concomitante `a garan-
tia de universalidade do cliente de acesso a informa¸c˜ao geogr´afica e `a transparˆencia no
desenvolvimento destes para a grande variedade de aplica¸c˜oes geogr´aficas demandadas
hoje.
Controle de Exce¸c˜oes
Servi¸cos compostos ou clientes gordos tendem a usar somente servi¸cos primitivos, o
que facilita o controle de exce¸c˜oes e permite ao servi¸co ou cliente saber qual servi¸co falhou.
Ao mesmo tempo, torna-se poss´ıvel a sele¸c˜ao de r´eplicas para a substitui¸c˜ao do servi¸co
indispon´ıvel.
Entretanto, a rastreabilidade de falhas em tempo de execu¸c˜ao pelo cliente ´e compro-
metida na I1, quando o controle de exce¸c˜oes ´e realizado integralmente pelo provedor de
servi¸cos invocado, e n˜ao pelo cliente. Isto tem impacto sobre a valida¸c˜ao de indicadores
de tolerˆancia a falhas certificados pelos provedores, e impede o cliente de obter resultados
parciais da opera¸c˜ao, como visto na transparˆencia de falha.
Adicionalmente, caso o cliente opte por usar uma r´eplica do provedor indispon´ıvel, o
reenvio dos parˆametros originais ´e obrigat´orio, mas estes nem sempre est˜ao dispon´ıveis
(por exemplo, no caso de uma rede de sensores geogr´aficos sem fio) ou o reenvio p ode ter
custo de comunica¸c˜ao elevado (por exemplo, no caso de clientes m´oveis).
Encadeamento Dinˆamico de Servi¸cos
A invoca¸c˜ao de r´eplicas, servi¸cos concorrentes e servi¸cos compat´ıveis de outra LSDI ´e
poss´ıvel para servi¸cos compostos (na I1) e para clientes (na I2). Por´em, na I1, clientes
dependem de servi¸cos compostos que definem a sua cadeia de servi¸cos internamente, sem
controle e mecanismos de monitoramento por parte do cliente. Enquanto que na I2,
clientes magros s˜ao prejudicados pela necessidade da recep¸c˜ao de respostas dos servi¸cos
para o encaminhamento destes aos pr´oximos servi¸cos da sua cadeia. Em se tratando de
servi¸cos Web geoespaciais, isso significa a retransmiss˜ao de um volume significativo de
dados.
Logo, a substitui¸c˜ao do papel do servi¸co composto por um mecanismo de cria¸c˜ao
dinˆamica de cadeias de servi¸co ´e ´util por permitir aos clientes de diferentes tipos acessarem
servi¸cos geogr´aficos de diferentes formas, aproveitando as vantagens dos provedores de
servi¸cos compostos e levando responsabilidade sobre um conjunto expressivo de aspectos
para o cliente.
CAP´ıTULO 3. METODOLOGIA E INFRA-ESTRUTURA DE AVALIAC¸
˜
AO 57
Suporte a Transa¸c˜oes Longas
Outro aspecto tecnol´ogico (perspectivas de Engenharia e Tecnol´ogica) que limita o
projeto de sistemas de informa¸c˜ao reais ´e a falta de suporte a comunica¸c˜ao ass´ıncrona,
quando o protocolo HTTP ´e usado.
Isto ´e particularmente s´erio no contexto de clie ntes m´oveis, para os quais o custo de
comunica¸c˜ao e energia ´e maior.
Clientes Universais para LSDI
Todos os aspectos citados anteriormente conduzem a um equil´ıbrio entre os benef´ıcios
e dificuldades decorrentes da ado¸c˜ao da I1 ou da I2, portanto tornando dif´ıcil uma escolha
direta. Uma conseq¨uˆencia disso no mundo real ´e a predominˆancia de servi¸cos espec´ıficos
para dispositivos espec´ıficos, al´em da ado¸c˜ao de interfaces n˜ao padronizadas para adi¸c˜ao
de recursos necess´arios a aplica¸c˜oes geogr´aficas comuns.
Predominam, no mercado atual, softwares geogr´aficos propriet´arios (para diversos dis-
positivos e para um conjunto sempre limitado de regi˜oes), e verifica-se a dificuldade de
se implementar novos softwares, principalmente softwares-cliente, para toda e qualquer
LSDI, em conformidade com os padr˜oes do OGC [UCF
+
05].
Atrav´es dos servi¸cos de infra-estrutura propostos na pr´oxima se¸c˜ao, pretende-se im-
plementar as altera¸c˜oes julgadas necess´arias nos servi¸cos primitivos OGC e nos servi¸cos
compostos n˜ao OGC, com o objetivo de dar suporte `as propriedades e aos RNF citados
anteriormente.
58
Cap´ıtulo 4
Servi¸cos de Infra-estrutura
Projetados
Dadas as necessidades de aplica¸c˜oes urbanas de informa¸c˜ao geogr´afica, assim como an-
tecipadas no cap´ıtulo anterior, e as principais limita¸c˜oes de servi¸cos Web geoespaciais
especificados pela OGC, foram desenvolvidos como parte deste trabalho alguns servi¸cos
de infra-estrutura que solucionam as limita¸c˜oes de engenharia encontradas.
Estes servi¸cos foram constru´ıdos a partir de um processo de desenvolvimento em es-
piral [Boe98] da implementa¸c˜ao 2 (Se¸c˜ao 3.2.3), de modo que funcionalidades de servi¸c os
em conformidade com a OGC eram implementadas na medida em que se mostravam ne-
cess´arias no cen´ario de uso, juntamente com servi¸cos complementares que representassem
fun¸c˜oes e modelos n˜ao suportados por servi¸cos padronizados.
O primeiro servi¸co, denominado Data Exchange Service, ´e usado para suporte de
persistˆencia entre clientes e servidores. O segundo, denominado Client Access Service,
´e usado para troca de informa¸c˜ao e controle de acesso direto a clientes por servidores e
outros c lientes. O terceiro, denominado Transaction Control Service, ´e usado por clientes e
servidores para melhorar aspectos de engenharia, tais como recupera¸c˜ao em caso de falhas,
cria¸c˜ao dinˆamica de cadeias de servi¸co, defini¸c˜ao de workflow em alto-n´ıvel e outros. Esses
servi¸cos ser˜ao detalhados nas se¸c˜oes a seguir.
4.1 Data Exchange Service
O Data Exchange Service (DXS) suporta comunica¸c˜ao entre clientes e servidores,
entre servidores (comunica¸c˜ao de servidor para servidor) e entre clientes (comunica¸c˜ao de
cliente para cliente). O comportamento do DXS ´e an´alogo a uma mem´oria tempor´aria,
onde dados podem ser armazenados e recuperados livremente. Seu objetivo ´e reduzir
CAP´ıTULO 4. SERVIC¸ OS DE INFRA-ESTRUTURA PROJETADOS 59
o volume de dados na intera¸c˜ao entre clientes e servidores, al´em de minimizar o custo
de conex˜ao na invoca¸c˜ao de servi¸cos e recupera¸c˜ao de dados, at´e mesmo quando falhas
ocorrem.
Um exemplo de a¸c˜ao do DXS ´e ilustrado na figura 4.1, onde h´a um Servi¸co A com
duas r´eplicas, Servi¸co A’ e Servi¸co A”, o que aumenta a disponibilidade do servi¸co durante
invoca¸c˜oes por clientes. Iniciamente, os parˆametros de requisi¸c˜ao s˜ao enviados e armaze-
nados para o DXS (1). Em seguida, uma ordem de invoca¸c˜ao ´e definida pelo cliente na
forma de um workflow (2). O processo de invoca¸c˜ao (3) inicia-se pelo Servi¸co A e usa os
servi¸cos A’ ou A” caso falhas ocorram. Em qualquer caso, os parˆametros s˜ao recuperados
a partir do DXS (4) e os resultados parciais e final s˜ao armazenados tamb´em no DXS para
recupera¸c˜ao posterior por outro servi¸co ou pelo cliente (5).
Figura 4.1: Uso do Data Exchange Service na Invoca¸c˜ao de um Servi¸co Replicado [AD06]
O DXS trabalha de trˆes formas diferentes. A primeira forma efetivamente estabelece
comunica¸c˜ao ass´ıncrona entre o cliente e o servi¸co alvo. O DXS intermedeia a comu-
nica¸c˜ao e faz com que o cliente n˜ao necessite aguardar online por uma resposta do servi¸co
alvo. Quando o processamento ´e conclu´ıdo, o cliente recebe uma notifica¸c˜ao do DXS, que
informa que j´a ´e poss´ıvel recuperar o resultado final.
O DXS tamb´em funciona como um reposit´orio tempor´ario para respostas intermedi´arias
em uma cadeia de servi¸cos. Resultados intermedi´arios ou parciais s˜ao mantidos no DXS
para o benef´ıcio de servi¸cos ao longo da cadeia, mas ao cliente s´o ´e permitido acessar o
resultado final quando este torna-se dispon´ıvel.
CAP´ıTULO 4. SERVIC¸ OS DE INFRA-ESTRUTURA PROJETADOS 60
Adicionalmente, o DXS suporta tolerˆancia a falhas, uma vez que ele mant´em in-
forma¸c˜ao sobre o estado da cadeia de servi¸cos com seus respectivos resultados parciais.
Com isso, recupera¸c˜ao e continuidade de processamento s˜ao poss´ıveis pela reinvoca¸c˜ao do
servi¸co que falhou, utilizando os parˆametros armazenados. Assim, n˜ao se ne cessita reini-
ciar toda a cadeia de servi¸cos, e s˜ao minimizados os reenvios de informa¸c˜ao do cliente para
os servi¸cos-alvo. Isso ´e particularmente importante em servi¸cos geogr´aficos, nos quais o
volume de dados que circula entre cliente e servidor pode ser expressivo.
Em todos os casos, o DXS funciona como um reposit´orio de parˆametros e respostas de
servi¸cos e pode ser introduzido em qualquer workflow, o qual deve ser constitu´ıdo apenas
por servi¸cos geogr´aficos com interfaces em conformidade com o OGC.
Na figura 4.2 ´e apresentado um diagrama de seq¨uˆencia em UML correspondente ao
cen´ario de uso descrito na se¸c˜ao 3.1, onde se exp˜oe a participa¸c˜ao do DXS entre o cliente
e os servi¸cos geoespaciais de alto-n´ıvel usados.
Figura 4.2: Diagrama de Seq¨uˆencia em UML para um Sistema com DXS [AD06]
A mensagens enumeradas como 1 e 7, entre o cliente e o DXS, correspondem aos
mesmos processos gen´ericos 1 e 5 ilustrados na figura 4.1, as quais iniciam o processamento
e coletam o resultado final, respectivamente.
As mensagens 2, 3, 4, 5 e 6 invocam os servi¸cos de interesse no in´ıcio do proc esso,
quando o cliente passa a aguardar pelo processamento enquanto os servi¸cos mantˆem-se
CAP´ıTULO 4. SERVIC¸ OS DE INFRA-ESTRUTURA PROJETADOS 61
em execu¸c˜ao. Como os servi¸cos Locating e Telephone s˜ao executados em paralelo, as
mensagens 2.1, 2.2, 3.1 e 3.2 podem ocorrer em qualquer ordem.
Finalmente, as mensagens de 4.1 a 6.2 ocorrem seq¨uencialmente. Nota-se que todo o
tr´afego intermedi´ario passaria pelo cliente caso o DXS estivesse ausente. Entretanto, como
o DXS assume o lugar do cliente neste intervalo, tal tr´afego intermedi´ario ´e retirado do
cliente, o qual reassume sua fun¸c˜ao ao final. Al´em disso, algumas invoca¸c˜oes na cadeia de
servi¸cos ocorrem em paralelo e reduzem o tempo de espera e reduzem o custo de controle
para o cliente, uma vez que a responsabilidade pela recep¸c˜ao de respostas foi transferida
para o DXS.
Portanto, em uma defini¸c˜ao informal, o DXS tem a fun¸c˜ao de interceptar respostas de
servi¸cos e encaminh´a-las para outros servi¸cos (incluindo outros DXS) ou para o cliente.
Neste sentido, os custos de comunica¸c˜ao para clientes gordos e ricos ´e o mesmo que
sem o uso do DXS, enquanto que o custo para clientes magros ´e reduzido. Entretanto,
o tamanho da linha-da-vida do cliente, assim como ilustrada na figura 4.2, permanece
o mesmo, independentemente da presen¸ca ou n˜ao do DXS. Conseq¨uentemente, o DXS
oferece vantagens somente quando o cliente tem limita¸c˜oes de energia, tem alto custo de
comunica¸c˜ao ou ´e mais lento que o servidor do DXS.
´
E poss´ıvel implementar persistˆencia semelhante a suportada pelo DXS atrav´es do uso
de servi¸cos Web simples , mas uma interface padronizada, que trabalha como um servi¸co de
infra-estrutura, ´e importante para assegurar a independˆencia entre clientes e provedores
de servi¸cos OGC.
Por outro lado, o DXS pode apresentar alguns problemas de seguran¸ca, tais como
acesso n˜ao autorizado a dados por terceiros. Melhorias no protocolo podem assegurar
controle de acesso eficaz, quando somente servi¸cos participantes de uma cadeia de servi¸cos
recuperam dados intermedi´arios e nem mesmo ao cliente ´e permitido acessar dados privi-
legiados ou informa¸c˜ao confidencial [BBC04].
4.2 Client Access Service
Como mencionado na s e¸c˜ao anterior, o Data Exchange Service permite comunica¸c˜ao
ass´ıncrona entre o cliente e os servi¸cos-alvo, ao permitir aos servi¸cos o encaminhamento
de seus resultados para o servidor do DXS, e ao cliente recuperar os resultados a partir do
DXS em qualquer momento. Entretanto, invoca¸c˜oes ass´ıncronas n˜ao s˜ao suportadas em
servi¸cos Web da W3C por meio do protocolo HTTP [BCPR04, RLT05]. Entre os servi¸cos
OGC, somente o Web Notification Service implementa invoca¸c˜oes ass´ıncronas, apesar de
este servi¸co n˜ao usar o protocolo HTTP [Ope].
CAP´ıTULO 4. SERVIC¸ OS DE INFRA-ESTRUTURA PROJETADOS 62
C´odigo 1 Uma Chamada que Retorna um identificador de Transa¸c˜ao
transac tionID =
service . do ( params );
Em um contexto urbano, servi¸cos ass´ıncronos s˜ao necess´arios quando h´a processos
demorados em cadeias de servi¸co. Esse ´e frequentemente o caso de servi¸cos baseados
em um grande volume de dados geogr´aficos. Eles s˜ao tamb´em necess´arios em aplica¸c˜oes
espec´ıficas, tais como o uso de se rvidores para enviar dados a clientes atrav´es de comu-
nica¸c˜ao n˜ao orientada a conex˜ao.
C´odigo 2 Obten¸c˜ao do Resultado do Servi¸co
while (! service . isReady ( trans act ionID ))
self . sleep (1000);
result = service . get ( trans act ionID );
Apesar de o cliente usualmente n˜ao possuir um endere¸co IP (Internet Protocol) v´alido,
ele sempre ´e capaz de acessar recursos por meio do protocolo HTTP. Entretanto, sem um
endere¸co IP v´alido ele ´e inacess´ıvel a partir de outros clientes ou servi¸cos, e recebe dados
somente durante suas conex˜oes de requisi¸c˜ao. Uma alternativa ´e o cliente invocar um
m´etodo de um servi¸co que retorna um ID de transa¸c˜ao mas n˜ao retorna o resultado final,
o que ´e ilustrado no c´odigo 1. Somente ap´os algum per´ıodo de tempo, uma nova invoca¸c˜ao
´e realizada para obten¸c˜ao do resultado final, quando o ID de transa¸c˜ao ´e fornecido como
parˆametro, assim como ilustrado no c´odigo 2.
C´odigo 3 Cliente define um M´etodo de Recep¸c˜ao de Notifica¸c˜ao para quando o Resultado
estiver Dispon´ıvel
transac tionID =
service . do ( responseMethod , responseURI ,
params )
Recuperar os resultados s´o ´e poss´ıvel quando o processamento estiver conclu´ıdo; po-
r´em, ao cliente n˜ao ´e dado conhecer o tempo que o processamento realmente consome.
Dessa forma, o cliente consome recursos para monitorar o estado do processamento do
servi¸co esperado. A figura 4.3 apresenta este padr˜ao de comunica¸c˜ao.
Se o cliente tem um endere¸co IP v´alido e implementa fun¸c˜oes de servidores HTTP, o
cliente pode aguardar off-line pelo fim do processamento at´e o momento em que recebe
uma notifica¸c˜ao do servi¸co, informando sobre a disponibilidade do resultado. O c´odigo
CAP´ıTULO 4. SERVIC¸ OS DE INFRA-ESTRUTURA PROJETADOS 63
Figura 4.3: Cliente sem um Endere¸co IP V´alido usando Comunica¸c˜ao baseada em HTTP
[AD06]
3 ilustra uma chamada que e specifica o m´etodo de resposta (HTTP, SMTP, SMS, etc) e
uma URI como parte de seus parˆametros.
Figura 4.4: Cliente com um Endere¸co IP V´alido usando Comunica¸c˜ao baseada em HTTP
[AD06]
A figura 4.4 mostra o protocolo de comunica¸c˜ao descrito, enquanto o c´odigo 4 ilustra
a ´ultima chamada do cliente ao servi¸co para obten¸c˜ao do resultado final.
O ´ultimo padr˜ao discutido ´e dependente de um gateway local, tal como um servi¸co
DXS, e pode ser adotado (1) quando o cliente n˜ao tem um endere¸co IP v´alido, (2) quando
o cliente est´a protegido por um servidor firewall ou (3) quando espera-se que o cliente
n˜ao seja identificado. Nestes casos, o c liente acessa o servi¸co alvo direta ou indiretamente,
mas a notifica¸c˜ao sobre a disponibilidade dos resultados ocorre entre o gateway escolhido
e o cliente, como ilustrado na figura 4.5. O cliente implementa o c´odigo 3 e o c´odigo 4.
Ao fornecimento de fun¸c˜oes de servidor HTTP (sem ou com IP v´alido) d´a-se o nome
de Client Access Service (CAS). O Client Access Service oferece meios de usar clientes
CAP´ıTULO 4. SERVIC¸ OS DE INFRA-ESTRUTURA PROJETADOS 64
C´odigo 4 Aguardar por Notifica¸c˜oes do Gateway or outro Servi¸co
while ( self . waiting ( t ransacti onID )) {
// do nothing
}
result = service . get ( trans act ionID );
Figura 4.5: Cliente sem um Endere¸co IP V´alido usando um Gateway como Mediador
[AD06]
como sensores e como servidores para outros clientes, al´e m de meios para habilitar o
cliente a trabalhar como um provedor de Data Exchange Service (especialmente no caso
de clientes gordos), o que ´e ´util em aplica¸c˜oes nas quais o cliente envia resposta ao servi¸co
a partir da experiˆencia do usu´ario [Gio06], e particularmente ´util nas situa¸c˜oes em que um
cliente envia dados para outros clientes pr´oximos, sem que os dados passem pelo servi¸co
de origem. Em todos os casos, o cliente pode prover alguma informa¸c˜ao para outros
clientes e servi¸cos e suportar estas funcionalidades com adequado n´ıvel de seguran¸ca e
privacidade.
4.3 Transaction Control Service
Atrav´es dos dois servi¸cos apresentados anteriormente, pode-se melhorar a capacidade
de processamento de um cliente de informa¸c˜ao geogr´afica. Entretanto, estes servi¸cos ainda
n˜ao atendem ao desafio de desenvolver um cliente gen´erico, que funcione em diferentes
LSDI. Al´em disso, a implementa¸c˜ao de algumas caracter´ısticas, tais como tolerˆancia a
falhas e transparˆencia no desenvolvimento de clientes, s˜ao de responsabilidade do servidor
ou de provedores espec´ıficos de informa¸c˜ao geogr´afica. Transferir esta responsabilidade
CAP´ıTULO 4. SERVIC¸ OS DE INFRA-ESTRUTURA PROJETADOS 65
para o cliente ´e conveniente em alguns casos, especialmente para clientes m´oveis em um
contexto urbano.
Um cliente universal, apto a acessar transparentemente diferentes LSDI, deve ser in-
dependente de cadeias de servi¸co espec´ıficas. Neste caso, quando o cliente se encontra
em um local distante ele pode carregar e executar uma cadeia de servi¸cos diferente para
obten¸c˜ao de informa¸c˜oes locais. Com iss o, embora servi¸cos possam estar prontamente
dispon´ıveis no interior de cadeias, seria melhor que cada servi¸co estivesse dispon´ıvel indi-
vidualmente para o cliente e fosse listado em um cat´alogo p´ublico. Dessa forma, a sele¸c˜ao
de servi¸cos e a forma¸c˜ao de cadeias de servi¸cos pode ocorrer dinamicamente sempre que
o cliente necessite acess´a-los.
O Transaction Control Service (TCS) executa transforma¸c˜oes em um c´odigo que des-
creve uma cadeia de servi¸cos gen´erica e em alto n´ıvel para produzir uma cadeia de servi¸cos
totalmente funcional, a qual serve para um contexto particular. O c´odigo gen´erico define
um workflow b´asico que ´e seguido pelo cliente durante a execu¸c˜ao de uma tarefa. Por´em,
apesar de tratar de workflow, o nome transaction (transa¸c˜ao) foi adotado por este con-
junto de funcionalidades. Isto se justifica pelo fato de o OGC definir uma transa¸c˜ao como
uma unidade l´ogica de trabalho constitu´ıda por uma ou mais opera¸c˜oes de manipula¸c˜ao
de dados, isto ´e, uma transa¸c˜ao ´e um conjunto de uma ou mais invoca¸c˜oes com leitura
e escrita de dados, sem que estas opera¸c˜oes atendam `as propriedades de atomicidade,
consistˆencia, isolamento e persistˆencia [Ope05b].
Atrav´es do TCS, o desenvolvedor de software-cliente define parˆametros que tornam
poss´ıvel a compila¸c˜ao do c´odigo de alto n´ıvel citado e o c´odigo execut´avel espec´ıfico para
o cliente. Estes parˆametros s˜ao (1) a lista de servi¸cos dispon´ıveis, o que representa a
LSDI escolhida, (2) o c´odigo que define a ordem de invoca¸c˜ao, (3) as dependˆencias das
invoca¸c˜oes, isto ´e, quais servi¸cos s˜ao pr´e-requisito de outros e (4) o tipo de cliente para o
qual o c´odigo execut´avel ser´a gerado.
O tipo de cliente, especificamente, serve como gabarito para os requisitos n˜ao-funcio-
nais que devem ser atendidos para aquele cliente. No entanto, n˜ao se trata de um gabarito
est´atico mas um conjunto flex´ıvel e personaliz´avel de atributos, o que favorece a defini¸c˜ao
de tantos gabaritos quantos tipos de clientes existam, para que o workflow seja adaptado
`a disponibilidade de servi¸cos na LSDI e `as necessidades pr´oprias de cada software-cliente.
Atrav´es dos c´odigos 5, 6 e 7 ´e apresentado o resultado do us o do TCS para a convers˜ao
do c´odigo abstrato (C´odigo 5) em c´odigo gen´erico (C´odigo 6), e finalmente em uma cadeia
de servi¸cos espec´ıfica para um cliente magro, no ce n´ario de assistˆencia a viagem (C´odigo
7). O principal objetivo deste servi¸co ´e portanto assegurar que nem o cliente nem o desen-
volvimento do servi¸co sejam dependentes do contexto local, isto ´e, sejam independentes
CAP´ıTULO 4. SERVIC¸ OS DE INFRA-ESTRUTURA PROJETADOS 66
de pec uliaridades dos servi¸cos que estiverem dispon´ıveis em cada localidade, e que este
arranjo possa ser refeito com flexibilidade caso mudan¸cas ocorram no contexto.
O c´odigo 5 ´e apresentado como um pse udoc´odigo, apesar de ser especificado em XML.
Nele est˜ao presentes quatro blocos, sendo o primeiro e o terceiro com intera¸c˜ao obrigat´oria
entre a cadeia de servi¸cos e o software-cliente, por necessidade de intera¸c˜ao com o usu´ario.
No segundo blo c o, tornam-se expl´ıcitas duas condi¸c˜oes, o paralelismo da obten¸c˜ao da lo-
caliza¸c˜ao do cliente e da obten¸c˜ao da lista de pontos de interesse pr´oximos ao destino.
Adicionalmente, a fun¸c˜ao location(target) mostra a dependˆencia da fun¸c˜ao de obten¸c˜ao
de pontos de interesse com rela¸c˜ao a esta fun¸c˜ao que retorna a localiza¸c˜ao do destino ba-
seada em uma indica¸c˜ao dada pelo usu´ario (como por exemplo um endere¸co textual ou
um n´umero de telefone). No ´ultimo bloco de c´odigo, a mesma fun¸c˜ao location(target)
´e usada, sendo que em sua invoca¸c˜ao anterior n˜ao foi usado um identificador para “arma-
zenar” o retorno (uma vari´avel, em linguagem de programa¸c˜ao). Dessa forma, ou haver´a
uma reinvoca¸c˜ao do servi¸co ou pode ser usado o mesmo valor anterior, dependendo da
semˆantica da fun¸c˜ao em quest˜ao, o que ´e definido por interven¸c˜ao do programador.
C´odigo 5 C´odigo abstrato, independente de servi¸cos e tecnologia
// Interacao com o usuario , controle com software - cliente
target = client . from ();
myLoca tion = client . from ();
// Comandos paralelos sem interacao com usuario
myLoc = location ( myLocation , Td irectory ) |
p = pointsOfI nte res t ( location ( target ) , Tdirectory );
// I nteracoes com o cliente , controle com software - cliente
client . to (p );
p2 = client . from ();
// Comandos nao int erativo s
query ( Troute , myLoc , p2 , location ( target ));
O c´odigo 6, por sua vez, apresenta mudan¸cas no c´odigo anterior ao inserir o servi¸co
Data Exchange Service em todas as invoca¸c˜oes. Para obter a localiza¸c˜ao myLoc (do c´odigo
anterior), ´e usada uma chave retornada pelo m´etodo location, a qual ´e armazenada no
identificador com nome alterado myLocAd. Ao contr´ario deste primeiro m´etodo, o segundo
location retorna a chave antes mesmo da invoca¸c˜ao, a qual ´e encaminhada para o m´etodo
pointsOfInterest, portanto a chave ´e criada pelo objeto dxs local atrav´es do m´etodo
dxs.setItem(0). O resultado da invoca¸c˜ao do servi¸co correspondente ao location ser´a
CAP´ıTULO 4. SERVIC¸ OS DE INFRA-ESTRUTURA PROJETADOS 67
armazenado no servidor DXS, e o servi¸co de diret´orio obter´a este resultado para usar como
seu pr´oprio parˆametro. Antes disso, o servi¸co de diret´orio retornar´a um endere¸co atrav´es
do qual seu res ultado poder´a ser obtido pelo cliente, e este endere¸co ser´a armazenado no
identificador pAd. A intera¸c˜ao com o cliente se mant´em com os m´etodos antigos, mas s´o
ocorre ap´os o resultado do servi¸co de diret´orio estar dispon´ıvel. Como no c´odigo anterior
est´a definido que os pontos de interesse ser˜ao usados pelo cliente, o resultado do servi¸co
´e recuperado para o ambiente local e ser´a manipulado diretamente pelo software-cliente.
Finalmente, o ponto escolhido pelo usu´ario, atrav´es do software-cliente, ´e armazenado
do identificador p2 no servidor DXS, e o seu endere¸co no DXS em p2Ad ser´a enviado
para o servi¸co de roteamento, juntamente com os resultados da localiza¸c˜ao do cliente
(myLocAd) e do destino (location(target, dxs.setItem(0)).
´
E importante observar
que se o destino for um objeto m´ovel e conseq¨uentemente houver necessidade de atualizar
o resultado da invoca¸c˜ao anterior, isto ocorrer´a neste exemplo, pois h´a reinvoca¸c˜ao do
servi¸co de localiza¸c˜ao e o resultado ´e armazenado no mesmo espa¸co do DXS. Para que n˜ao
ocorra reinvoca¸c˜ao, o c´odigo precisaria ser alterado manualmente de location(target,
dxs.setItem(0)) para dxs.getId(0).
O c´odigo espec´ıfico deve implementar um comportamento de invoca¸c˜oes que seja mais
eficiente para o cliente [RCV06], o que deve ser projetado de acordo com as ne cessidades do
cliente e particularidades da LSDI. Como exemplo, no trecho de c´odigo 7, ´e demonstrada
a necessidade do cliente de obter a localiza¸c˜ao do destino pelo servi¸co mais r´apido, sendo
que qualquer dos servi¸cos armazena a resposta no servidor DXS, em um mesmo espa¸co
remoto no servidor DXS com endere¸co indexado no objeto dxs pelo m´etodo setItem(0).
Os servi¸cos dos servidores da prefeitura (cityHall), da companhia telefˆonica (teleCo),
da associa¸c˜ao comercial local (coAssociation) e de um guia de turismo (tourismGuide)
s˜ao invocados ao mesmo tempo, e a primeira resposta ficar´a dispon´ıvel para o servi¸co
invocado atrav´es do m´etodo pointsOfInterest, para o qual ´e informado o endere¸co do
DXS retornado pelo m´etodo dxs.getId(0).
Com os servi¸cos apresentados, clientes de LSDI podem ser implementados de acordo
com os requisitos informacionais e computacionais do OGC para servi¸cos Web geoespaci-
ais, reduzindo a introdu¸c˜ao de aspectos tecnol´ogicos no c´odigo do cliente. Assim, clientes
gordos, ricos e magros podem ser implementados transparentemente, seus requisitos par-
ticulares s˜ao indicados por um workflow gen´erico que muda facilmente quando o cliente
se move de uma localidade para outra e quando estes mesmos clientes tˆem sua capacidade
alterada. Diferentes workflows s˜ao ent˜ao especificados para cada infra-estrutura urbana
por seus participantes e ainda para cada tipo de cliente por seu fabricante, o que habilita
o software-cliente a adquirir comportamentos diferentes a partir do contexto.
CAP´ıTULO 4. SERVIC¸ OS DE INFRA-ESTRUTURA PROJETADOS 68
C´odigo 6 C´odigo gen´erico adaptado para uma LSDI mas independente de tecnologia
// Ini cia lizac ao
load Services ( addr );
DXSSer vice dxs = new DXSServ ice ();
dxs . start ();
// Interacao com o usuario , controle com software - cliente
// Progr amado r deve alterar os metodos de entrada de dados
target = client . from ();
myLoca tion = client . from ();
// Comandos paralelos sem interacao com usuario
myLocAd = location ( myLocation , Tdirectory , dxs ) |
pAd =
po int sOf Int ere st ( location ( target , dxs . setItem (0)) , Tdirectory , dxs );
// Interac oes com o cliente , controle com software - cliente
dxs . waitItem ( pAd );
client . to ( dxs . getItem ( pAd ));
p2 = client . from ();
p2Ad = dxs . store ( p2 );
// Comandos nao int erativo s
query ( Troute , myLocAd , p2Ad , locat ion ( target , dxs . setItem (0)));
4.4 Implementa¸c˜ao 3
Esta se¸c˜ao apresenta uma implementa¸c˜ao voltada para a avalia¸c˜ao da facilidade com a
qual s˜ao desenvolvidos clientes de LSDI que usam diretamente servi¸cos Web geoespaciais
propostos pela OGC. Por´em, nesta implementa¸c˜ao j´a s˜ao introduzidas funcionalidades
dos servi¸cos Data Exchange Service , Client Access Service e Transaction Control Service
com o objetivo de sanar as limita¸c˜oes descritas na se¸c˜ao 3.4.
A Figura 4.6 ilustra o modelo implementado em apenas duas c amadas, sendo a pri-
meira do cliente e a segunda no servidor, onde localizam-se as fontes originais de in-
forma¸c˜ao e func ionalidades geogr´aficas. O Data Exchange Service ´e adicionado em uma
camada l´ogica, de onde assumir´a algumas das fun¸c˜oes do cliente durante o processamento
dos servi¸cos-alvo.
Nesta implementa¸c˜ao, o cliente procura por novos servi¸cos e os seleciona atrav´es de
um cat´alogo de metadados universal. Portanto, o cliente e o servidor DXS conhecem a
interface de cada servi¸co usado.
CAP´ıTULO 4. SERVIC¸ OS DE INFRA-ESTRUTURA PROJETADOS 69
C´odigo 7 Trecho de c´odigo espec´ıfico adaptado para uma LSDI e para um cliente magro
// Comandos paralelos sem interacao com usuario
myLocAd = cityHall . location ( myLocation , Tdirectory , dxs );
cityHall . location ( target , dxs . setItem (0));
teleCo . location ( target , dxs . setItem (0));
coAssoc iation . location ( target , dxs . setItem (0));
tour ismGuide . location ( target , dxs . setItem (0));
pAd = cityHall . po int sOf Int erest ( dxs . getId (0) , Tdirectory , dxs );
O DXS foi implementado como um servi¸co que recebe dados em GML e XML, re-
torna uma identifica¸c˜ao, armazena os dados recebidos e os devolve caso solicitado em
outra invoca¸c˜ao. O CAS foi implementado como um padr˜ao (pattern) diretamente no
cliente, o qual responde por requisi¸c˜oes HTTP e recebe a notifica¸c˜ao de outros clientes
ou servidores atrav´es de invoca¸c˜oes a partir destes. O TCS, por sua vez, foi prototipado
como um documento XSLT que faz sucessivas transforma¸c˜oes em um documento XML
e devolve m´etodos Java prontos para a implementa¸c˜ao de clientes que usam os servi¸cos
Web geoespaciais de interesse.
4.5 Avalia¸c˜ao
No cap´ıtulo 3 foram avaliadas as especifica¸c˜oes do modelo abstrato da OGC para
servi¸cos Web geoespaciais dos conjuntos OpenLS e OWS, e, a partir das limita¸c˜oes en-
contradas e apresentadas na se¸c˜ao 3.4, foram desenvolvidos os servi¸cos especificados no
presente cap´ıtulo.
A avalia¸c˜ao inicial foi desenvolvida sobre a implementa¸c˜ao de dois modelos que s˜ao
(a) 1 Cliente para 1 Provedor e n Servidores de servi¸cos OGC, onde h´a um provedor que
intermedeia recursos de outros provedores, estando estes ´ultimos em conformidade com
os servi¸cos OGC (Figura 3.3), e (b) 1 Cliente para n Servidores, onde o cliente executa
todas as tarefas relacionadas ao acesso a servi¸cos Web e processamento da informa¸c˜ao
geogr´afica (Figura 3.4).
Ap´os as duas primeiras implementa¸c˜oes, foram separados os problemas de projeto dos
problemas tecnol´ogicos encontrados. Os problemas de projeto foram ent˜ao agrupados em
trˆes conjuntos, que constituem os servi¸cos Data Exchange Service , Client Access Service
e Transaction Control Service . Finalmente, a avalia¸c˜ao foi baseada no modelo (b) de
duas camadas com a inclus˜ao do DXS, o que foi especificado e verificado na se¸c˜ao 4.4.
CAP´ıTULO 4. SERVIC¸ OS DE INFRA-ESTRUTURA PROJETADOS 70
Figura 4.6: Implementa¸c˜ao 3, onde o cliente acessa diretamente os servi¸cos-alvo mas adota
um DXS para armazenamento tempor´ario
Pela implementa¸c˜ao dos recursos reunidos no Data Exchange Service , o tr´afego in-
termedi´ario de dados foi eliminado do cliente durante o proce ssamento independente de
intera¸c˜oes com o usu´ario. Adicionalmente, quando introduzidas falhas por meio de inter-
ven¸c˜oes no ambiente de execu¸c˜ao, nenhum dado previamente processado foi perdido.
Entretanto, n˜ao foram observados efeitos para os RNF economia de comunica¸c˜ao,
economia de processamento, economia de espa¸co e velocidade de acesso durante o per´ıodo
de processamento no qual havia intera¸c˜ao com o usu´ario, quando h´a novos parˆametros
para a cadeia de servi¸co advindos diretamente do cliente.
Atrav´es do Client Access Service, os RNF economia de comunica¸c˜ao e velocidade de
acesso foram melhorados pela elimina¸c˜ao do uso da rede de computadores pelo cliente
durante o per´ıodo de processamento do servi¸co remoto. Isso tornou-se poss´ıve l pelo fato
de que o cliente passou a ser informado sobre o estado de prontid˜ao do servi¸co.
O CAS emulou comunica¸c ˜ao ass´ıncrona atrav´es da atribui¸c˜ao da fun¸c˜ao de servidor
HTTP ao cliente, o que se mostrou invi´avel em certas condi¸c˜oes (como no caso em que o
cliente n˜ao possui um endere¸co IP v´alido). O mesmo comportamento tornou-se poss´ıvel
CAP´ıTULO 4. SERVIC¸ OS DE INFRA-ESTRUTURA PROJETADOS 71
pelo uso de um protocolo diferente do HTTP para o envio de uma mensagem ao cliente,
ap´os a qual o cliente reinvoca o servidor atrav´es do protocolo HTTP para obter o resultado
final.
Finalmente, atrav´es do Transaction Control Service foi poss´ıvel a compila¸c˜ao de m´e-
todos espec´ıficos para dispositivos e clientes, de forma transparente, a partir de uma
defini¸c˜ao de alto-n´ıvel em XML. Esse servi¸co pˆode funcionar como um compilador que
transforma um documento XML em m´etodos Java de acordo com o workflow definido
pelo desenvolvedor, dado um conjunto de requisitos do cliente.
Os m´etodos Java resultantes incluem o uso do servidor DXS quando este se faz ne-
cess´ario, como por exemplo na implementa¸c˜ao de c´odigo para clientes magros. Assim, foi
poss´ıvel a constru¸c˜ao de c´odigo de alto-n´ıvel para clientes gordos, ricos e magros trans-
parentemente, o qual pode ser transformado em c´odigo espec´ıfico para dispositivos em
atendimento aos requisitos de cada tipo de dispositivo.
72
Cap´ıtulo 5
Conclus˜oes
Assim como definido no Cap´ıtulo 1, o principal objetivo desta disserta¸c˜ao foi avaliar a
adequa¸c˜ao de servi¸cos assim como especificados pela OGC nos conjuntos OWS e OpenLS
para a implementa¸c˜ao de sistemas de informa¸c˜ao geogr´aficos de ˆambito urbano e imple-
menta¸c˜ao de clientes para estes mesmos sistemas. No entanto, o foco foi dado principal-
mente a requisitos n˜ao funcionais de engenharia de sofware, como uma forma de investigar
a facilidade de desenvolvimento e, conseq¨uentemente, a contribui¸c˜ao desses padr˜oes para
a difus˜ao de aplica¸c˜oes geogr´aficas de escopo urbano.
Apesar de SDI possuirem v´arios n´ıveis de detalhamento e complexidade, que v˜ao desde
SDI corporativas at´e a SDI global, a padroniza¸c˜ao de interfaces de servi¸cos foi realizada
tendo em vista principalmente SDI nacionais e regionais. Com isso, esperava-se fomentar
o desenvolvimento da SDI global, como uma ´unica infra-estrutura que permitisse que os
SIG de todo o mundo cooperassem entre si, assim como ocorre com a Internet em rela¸c˜ao
a redes de computadores menores. Inevitavelmente, SDI locais e corporativas n˜ao imple-
mentaram os padr˜oes da OGC nos ´ultimos anos, e em alguns casos, sequer os protocolos
da W3C foram adotados. Com isso, in´umeras SDI se desenvolveram como “ilhas”, aten-
dendo apenas aos requisitos de seus usu´arios locais, o que dificulta a integra¸c˜ao destas
ilhas entre si, e a integra¸c˜ao destas com n´ıveis acima, como com a SDI nacional na qual
deveriam estar inseridas.
O que n˜ao representava um problema h´a dez anos atr´as, atualmente, com o advento e
difus˜ao de softwares para computadores pessoais (por exemplo, o Google Earth), que re´une
uma grande comunidade de usu´arios que colecionam pontos de interesse (normalmente
urbanos), e outros softwares de localiza¸c˜ao para ve´ıculos, PDAs e celulares, a importˆancia
das LSDI foi ampliada. Isto deve-se principalmente ao fato de que as LSDI devem servir
como fonte de informa¸c˜ao detalhada sobre as diversas regi˜oes do planeta, o que s´o ´e
poss´ıvel quando estas se integram `as NSDI e `a GSDI.
CAP´ıTULO 5. CONCLUS
˜
OES 73
Os resultados da pesquisa, apresentados na se¸c˜ao 5.1, referem-se a aspectos relaciona-
dos `a classifica¸c˜ao das limita¸c˜oes encontradas, `a modelagem de cen´ario de uso adotado
para avalia¸c˜ao e ao prot´otipo desenvolvido como prova de conceito.
As contribui¸c˜oes da disserta¸c˜ao s˜ao descritas em seguida, na se¸c˜ao 5.2, onde s˜ao enu-
merados os trˆes servi¸cos desenvolvidos, os quais agrupam as t´ecnicas de satisfa¸c˜ao usadas
para reduzir as limita¸c˜oes identificadas e para melhorar a facilidade de desenvolvimento
de SIG urbanos.
Finalmente, na se¸c˜ao 5.3 s˜ao apontadas algumas indica¸c˜oes da dire¸c˜ao para a qual no-
vos estudos podem ser conduzidos, os quais devem contribuir principalmente para reduzir
as diferen¸cas entre os padr˜oes de servi¸cos Web geo e spaciais da OGC e os de servi¸cos Web
gen´ericos da W3C.
5.1 Resultados
Neste trabalho, foram avaliados aspectos de engenharia das especifica¸c˜oes OGC Web
Services e Open Location Services, ambas definidas pela OGC, tendo sido considerada
tamb´em a especifica¸c˜ao de Web services definida pela W3C, todas aplicadas a sistemas
de informa¸c˜ao geogr´aficos de escopo urbano. Por meio da implementa¸c˜ao de um prot´otipo
composto por servi¸cos geogr´aficos e clientes foram identificadas limita¸c˜oes para o desen-
volvimento de SIG distribu´ıdos, tais como ausˆencia de mecanismos de tolerˆancia a falhas
padronizados e clientes fortemente dependentes de provedores, dentre outras. Uma vez
que a disponibilidade de softwares-cliente contribui para a difus˜ao de LSDI, a facilidade
com a qual estes clientes s˜ao desenvolvidos ´e muito importante.
Algumas solu¸c˜oes para as limita¸c˜oes encontradas foram agrupadas em novos servi¸cos
de infra-estrutura, os quais facilitam o desenvolvimento de clientes universais n˜ao de-
pendentes de fornecedores espec´ıficos para LSDI [AD06]. Entretanto, tais servi¸cos n˜ao
constituem propostas para a OGC, eles apenas sintetizam e demonstram as limita¸c˜oes
encontradas.
A modelagem do cen´ario de uso real foi mapeada em servi¸cos de perspectiva computa-
cional (WMS, WFS, WCS, etc) ap´os ter sido especificada como um conjunto de servi¸cos
de alto n´ıvel na perspectiva de neg´ocio (mapa-base, roteamento, diret´orio de empresas,
etc). Com isso, esta pesquisa experimentou a modelagem de LSDI proposta por Davis Jr
e Alves [DA06].
O prot´otipo, por sua vez, se baseou no modelo abstrato de servi¸cos da OGC, o que
adicionalmente possibilita us´a-lo como instrumento de an´alise para outras quest˜oes re-
lacionadas a OGC em esfor¸cos futuros de pesquisa. Al´em dos servi¸cos desenhados, esta
CAP´ıTULO 5. CONCLUS
˜
OES 74
pesquisa organizou alguns dos requisitos n˜ao funcionais dos principais servi¸cos da OWS
e OpenLS o que poder´a ser estendido em pr´oximos trabalhos.
De fato, as especifica¸c˜oes da OGC mostraram-se inadequadas para a implementa¸c˜ao
de SIG urbanos assim como desenvolvidos de outras formas, como pela ado¸c˜ao de pacotes
propriet´arios de desenvolvimento e pela imposi¸c˜ao de interfaces n˜ao-padronizadas. Um
passo na dire¸c˜ao das LSDI deve ser dado pela OGC, para garantir uma ado¸c˜ao ampla de
seus padr˜oes e fomentar a consolida¸c˜ao da SDI global [Rei05].
5.2 Principais Contribui¸c˜oes
Os servi¸cos da LSDI e o SIG espec´ıfico foram constru´ıdos iterativamente sobre o cen´ario
de uso especificado na se¸c˜ao 3.1 e requisitos n˜ao funcionais definidos no ORM [Per03] na
perspectiva de Engenharia. Durante a implementa¸c˜ao, para cada regra de correla¸c˜ao que
influenciava negativamente algum dos requisitos n˜ao funcionais, uma t´ecnica de satisfa¸c˜ao
era aplicada, por meio da reimplementa¸c˜ao do servi¸co em conformidade com a OGC, da
implementa¸c˜ao de um outro servi¸co OGC, ou pela implementa¸c˜ao de funcionalidades
adicionais, em um ou mais servi¸cos, que pudessem reduzir o impacto negativo percebido.
Essas funcionalidades adicionais foram organizadas em grupos segundo os requisitos
n˜ao funcionais para os quais eram de stinadas. Os trˆes grupos foram ent˜ao definidos como
Data Exchange Service (DXS), Client Access Service (CAS) e Transaction Control Service
(TCS).
O Servi¸co de Intercˆambio de Dados (DXS) provˆe a fun¸c˜ao de persistˆencia, envolvendo
provedores de servi¸co e o espa¸co de armazenamento local do cliente. Com o DXS se tem
um servi¸co neutro, atrav´es do qual a cadeia de servi¸cos troca parˆametros e resultados de
seu processamento interno, sem uso do canal de comunica¸c˜ao do cliente e sem atribui¸c˜ao
da responsabilidade pela recep¸c˜ao de resultados intermedi´arios ao cliente.
As cadeias de servi¸cos geogr´aficos, atualmente, s˜ao constru´ıdas em um servi¸co remoto,
seja ele geogr´afico (OGC) ou um servi¸co gen´erico (baseado nas especifica¸c˜oes W3C). Estas
cadeias j´a se beneficiam da capacidade de comunica¸c˜ao entre servidores. Entretanto, ca-
deias de servi¸cos da W3C muitas vezes s˜ao orquestradas por clientes, que s˜ao integralmente
respons´aveis pelas invoca¸c˜oes, recep¸c˜ao de resultados intermedi´arios e encaminhamento
destes resultados aos pr´oximos servi¸cos da cadeia. Essa segunda condi¸c˜ao n˜ao necessa-
riamente exige que o dispositivo onde reside o software cliente tenha capacidade similar
a de servidores, mas exige no m´ınimo que n˜ao existam certas restri¸c˜oes, tais como custo
elevado de comunica¸c˜ao e baixa capacidade de energia, comuns a dispositivos para os
quais SIG s˜ao ferramentas ´uteis (celulares, GPS, PDAs, e outros).
CAP´ıTULO 5. CONCLUS
˜
OES 75
Em ambos os casos, o software cliente (e o usu´ario, conseq¨uentemente) tem alguma
capacidade de escolha. Se cadeias de servi¸cos s˜ao constru´ıdas diretamente em um prove-
dor, o cliente pode trocar os servi¸cos internos `a cadeia pela escolha de outro provedor ou
outro servi¸co do mesmo provedor, isto ´e, troca-se toda a cadeia de servi¸cos. Por´em, se a
cadeia de servi¸co ´e constru´ıda dinamicamente pelo cliente, tem-se maior flexibilidade, pois
servi¸cos constituintes da cadeia podem ser substitu´ıdos por outros servi¸cos compat´ıveis
com facilidade, inclusive em tempo de execu¸c˜ao, o que ´e ´util quando o cliente muda de
regi˜ao ou quando os parˆametros de seguran¸ca, qualidade e custo s˜ao alterados. Al´em
disso, se a cadeia ´e responsabilidade do cliente, outros requisitos tais como tolerˆancia a
falhas tamb´em s˜ao transferidos para o cliente. Isso traz vantagens e desvantagens, pois
adquire-se alguma independˆencia de provedores, mas exige-se a inclus˜ao de c´odigo que
n˜ao pertence ao dom´ınio da aplica¸c˜ao.
Mesmo assim, o DXS auxilia na transferˆencia da responsabilidade pela orquestra¸c˜ao
da cadeia para o cliente ao assumir a fun¸c˜ao de atender os requisitos n˜ao funcionais.
Dessa forma ele permite reduzir o reenvio de parˆametros iniciais em caso de falhas da
cadeia de servi¸cos e permite o aproveitamento de resultados intermedi´arios quando ape-
nas algum componente da cadeia falha, o que ´e ´util at´e mesmo para clientes gordos.
Por´em, as principais vantagens s˜ao para clientes magros e ricos, os quais normalmente
apresentam restri¸c˜oes mais s´erias de energia, armazenamento, comunica¸c˜ao e capacidade
de processamento.
Por meio do servi¸co de acesso ao cliente (CAS) foi poss´ıvel emular assincronicidade
em invoca¸c˜oes usando o protocolo de aplica¸c˜ao HTTP. Este servi¸co foi incorporado ao
cliente, o qual passou a se comportar como um servidor HTTP, com fun¸c˜ao de respon-
der por requisi¸c˜oes de qualquer outro cliente ou servidor. Diferentemente do servi¸co de
intercˆambio de dados, o servi¸co de acesso ao cliente n˜ao ´e um servi¸co Web. Portanto,
sua implementa¸c˜ao constituiu um comportamento introduzido no cliente e avaliado para
o suporte a transa¸c˜oes longas, muito comuns no contexto de SIG, onde h´a volume maior
de dados e dificuldades particulares de indexa¸c˜ao.
Outro conjunto de fun¸c˜oes avaliado pertence ao grupo do servi¸co de controle de
transa¸c˜oes (TCS), constitu´ıdo basicamente por transformadores de c´odigo de alto n´ıvel
para c´odigo de programa¸c˜ao. Atrav´es deste servi¸co foi poss´ıvel experimentar a introdu¸c˜ao
das novas funcionalidades de forma autom´atica no cliente, possibilitando a implementa¸c˜ao
transparente de clientes para diferentes dispositivos como gordos, ricos ou magros. A
importˆancia deste servi¸co est´a associada a capacidade de implementa¸c˜ao de clientes ade-
quados para SIG urbanos, todos por´em em conformidade com os padr˜oes da OGC, o que
favorece a consolida¸c˜ao de uma inf ra-estrutura global de dados espaciais, dentre outras
CAP´ıTULO 5. CONCLUS
˜
OES 76
coisas [Rei05].
Portanto, esta disserta¸c˜ao propˆos um conjunto de novos se rvi¸cos, os quais facilitam o
desenvolvimento de clientes de informa¸c˜ao geogr´afica para sistemas baseados em LSDI, e
conseq¨uentemente contribuem para melhorar a implementa¸c˜ao e difus˜ao de LSDI como
fontes de informa¸c˜ao detalhada para SDI nacionais, regionais e global.
5.3 Trabalhos Futuros
Foram identificadas trˆes dire¸c˜oes principais para trabalho futuro. Primeiramente
discute-se o uso potencial de clientes como provedores de informa¸c˜ao geogr´afica. Em
seguida, prop˜oem-se melhoramentos de engenharia para o desenvolvimento de servi¸cos
geogr´aficos. Finalmente, sup˜oe-se a possibilidade de desenvolvimento de novos servi¸cos
de alto n´ıvel para LSDI, melhorando a t´ecnica de modelagem, e desenvolvimento de um
novo prot´otipo baseado no modelo de implementa¸c˜ao da OGC para favorecer outros es-
tudos nas perspectivas computacional e tecnol´ogica.
O cliente de informa¸c˜ao geogr´afica, se visto como um servidor de parˆametros para a
cadeia de servi¸cos, torna-se potencialmente o provedor de v´arios tipos de informa¸c˜ao. In-
forma¸c˜oes coletadas diretamente pelo usu´ario, como estado de tr´afego [TJH05] juntamente
com dados previamente coletados de outras fontes, qualidade percebida de informa¸c˜ao,
ontologias sobre seus interesses, observa¸c˜oes ambientais [Gio06], posi¸c˜ao geogr´afica atuali-
zada e outras, todas podem ser transmitidas para outros usu´arios ou melhorar a qualidade
da informa¸c˜ao fornecida por um provedor de servi¸cos. Dessa maneira, algumas aplica¸c˜oes
tornam-se poss´ıveis, como planejamento de rotas mais preciso pela informa¸c˜ao trocada
com outros usu´arios, controle de qualidade de servi¸co em provedores, uma melhor gerˆencia
de tr´afego por meio de ve´ıculos que servem como sensores em tempo-real, dentre outras.
Aplica¸c˜oes geogr´aficas atrav´es de dispositivos celulares, PDAs e outros podem ser exe-
cutadas atrav´es de comunica¸c˜ao cliente-servidor ou conex˜oes peer-to-peer. No caso de
conex˜oes peer-to-peer, quando a disponibilidade de energia n˜ao for limitada, pode-se me-
lhorar o tempo de resposta das aplica¸c˜oes [WZK05] uma vez que dados anteriormente
coletados por outros usu´arios estar˜ao imediatamente dispon´ıveis [GWZ04]. A comu-
nica¸c˜ao peer-to-peer aproxima-se muito do comportamento do Client Access Service e
serve para impleme ntar este padr˜ao. Servi¸cos de geocodifica¸c˜ao, roteamento e servi¸cos de
localiza¸c˜ao podem ainda ser adaptados para objetos geogr´aficos m´oveis, tais como ve´ıculos
(de transporte p´ublico, de emergˆencia ou particulares) ou pessoas (por exemplo, por meio
de telefones celulares ou GPS). No entanto, estudos adicionais sobre tais aplica¸c˜oes s˜ao
requeridos por envolverem quest˜oes relacionadas a seguran¸ca e privacidade.
CAP´ıTULO 5. CONCLUS
˜
OES 77
Uma quest˜ao de pesquisa relacionada a engenharia de SIG envolve determinar como
parˆametros de tolerˆancia a falhas podem ser definidos e negociados atrav´es de contratos
de disponibilidade, os quais podem ser automaticamente verificados por meio de buscas
no interior das cadeias de servi¸co, quando s˜ao identificados pontos de falha comuns entre
um servi¸co e seus substitutos. Isso ´e especialmente importante em emergˆencias, aplica¸c˜oes
de miss˜ao cr´ıtica e outras [Onc05]. Esta mesma quest˜ao pode ser estendida para outros
aspectos, tais como privacidade e desempenho.
Uma segunda quest˜ao em desenvolvimento de SIG refere-se `as descri¸c˜oes de cadeias
de servi¸co ou workflow. Em alguns casos, ´e ´util que servi¸cos sejam localizados e dinami-
camente carregados no interior de uma cadeia de servi¸cos, como no caso de servi¸cos de
roteamento quando rotas passam por regi˜oes n˜ao cobertas por fontes de dados selecio-
nadas. Portanto, melhorias adicionais devem ser feitas nos mecanismos de descri¸c˜ao de
cadeias de servi¸co e em mecanismos que permitam transformar tais descri¸c˜oes em c´odigo.
Novos meios de avalia¸c˜ao de LSDI s˜ao tamb´em essenciais para o desenvolvimento de
SIG urbanos como componentes das NSDI. Davis Jr e Alves (2005) [DA05] prop˜oem v´arios
servi¸cos de alto n´ıvel que constituem e permitem modelar uma LSDI ao considerar neces-
sidades espec´ıficas para aplica¸c˜oes geogr´aficas urbanas. O arcabou¸co pode ser estendido
pela proposi¸c˜ao de novos servi¸cos relacionados a esse n´ıvel de infra-estrutura de dados
especiais.
Finalmente, ´e importante buscar a cria¸c˜ao de um ambiente de desenvolvimento de
prot´otipos e avalia¸c˜ao de LSDI, pois tal ambiente pode possibilitar observa¸c˜oes e experi-
mentos em padr˜oes da OGC atuais e futuros, assim como possibilitar estudos adicionais
sobre v´arios aspectos relacionados a problemas reais que limitam a ado¸c˜ao em larga es-
cala de LSDI compat´ıveis, tais como privacidade dos usu´arios de SIG, desempenho das
aplica¸c˜oes, seguran¸ca, disponibilidade e outros.
78
Referˆencias
[AB03] Leonardo Lacerda Alves and Fabricio Roulin Bittencout. PHP: Conceitos
essenciais para implementa¸c˜ao de aplica¸c˜oes web. 7 Faces, 4(1):193–208,
2003.
[AD06] Leonardo Lacerda Alves and Clodoveu Augusto Davis J´unior. Interopera-
bility through Web Services: Evaluating OGC Standards in Client Deve-
lopment f or Spatial Data Infrastructures. In VIII Brazilian Symposium on
Geoinformatics Proceedings, pages 193–208. INPE, November 2006.
[AD07] Leonardo Lacerda Alves and Clodoveu Augusto Davis J´unior. Evaluation of
OGC Web Services for Local Spatial Data Infrastructures and for Develop-
ment of Geographic Information Systems Clients, volume 1. Springer, S.L.,
2007.
[AEMS05] D. Askew, S. Evans, R. Matthews, and P. Swanton. Magic: a geoportal
for the english c ountryside. Computers, Environment and Urban Systems,
29(1):71–85, 2005.
[Ala03] Nadine Alameh. Chaining geographic information web s ervices. IEEE In-
ternet Computing, 7(5):22–29, 2003.
[BBC04] A. Belussi, E. Bertino, and B. Catania. An authorization model for geo-
graphical maps. In GIS’04 Proceedings, pages 82–91. ACM, November 2004.
[BC05] Lars Bernard and Max Craglia. SDI – From Spatial Data Infrastructure
to Service Driven Infrastructure. In Research Workshop on Cross-learning
between Spatial Data Infrastructures and Information Infrastructures, 2005.
[BCPR04] M. Brambilla, S. Ceri, M. Passamani, and A. Riccio. Managing asynchro-
nous web services interactions. In Web Services, 2004. Proceedings. IEEE
International Conference on, pages 80–87. IEEE , November 2004.
REFER
ˆ
ENCIAS 79
[BEK
+
00] Ian D. Bishop, Francisco J. Escobar, Sadasivam Karuppannan, Ksemsan
Suwarnarat, Ian P. Williamson, Paul M. Yates, and Haider W. Yaqub. Spa-
tial data infrastructures for cities in developing countries: Lessons from the
Bangkok experience. Cities, 17(2):85–96, April 2000.
[BLM05] P. Beaumont, P. A. Longley, and D. J. Maguire. Geographic information
portals: a uk perspective. Computers, Environment and Urban Systems,
29(1):49–69, 2005.
[Boe98] B. Boehm. Using the winwin spiral model: A case study. Computer,
31(7):33–44, July 1998.
[CBRW04] J. Crompvoets, A. Bregt, A. Rajabifard, and I. Williamson. Assessing the
worldwide developments of national spatial data clearinghouses. Internati-
onal Journal of Geographical Information Science, 18(7):665–689, 2004.
[CCD
+
05] Marco Antˆonio Casanova, Gilberto Cˆamara, Clodoveu A. Davis Junior, Lu-
bia Vinhas, and Gilberto Rib eiro de Queiroz. Bancos de Dados Geogr´aficos,
volume 1. Espa¸coGeo, Curitiba, 2005.
[CFRW01] Tai On Chan, Mary-Ellen Feeney, Abbas Rajabifard, and Ian Williamson.
The dynamic nature of spatial data infrastructures: A method of descriptive
classification. Geomatica, 55(1):65–72, 2001.
[CPD06] S. Chung, J. R. Pan, and S. Davalos. A special web service mechanism:
Asynchronous .NET web services. In Telecommunications, 2006. AICT-
ICIW ’06. International Conference on Internet and Web Applications and
Services/Advanced International Conference on, pages 212–212. IEEE, Fe-
bruary 2006.
[DA05] Clodoveu Augusto Davis J´unior and Leonardo Lacerda Alves. Local s pa-
tial data infrastructures based on a service-oriented architecture. In VII
Brazilian Symposium on Geoinformatics Proceedings, pages 84–89. INPE,
November 2005.
[DA06] Clodoveu Augusto Davis J´unior and Leonardo Lacerda Alves. Infra-
estruturas de dados espaciais: Potencial para uso local. IP. Inform´atica
P´ublica , 8(1), Mar¸co 2006.
REFER
ˆ
ENCIAS 80
[DA07] Clodoveu Augusto Davis J´unior and Leonardo Lacerda Alves. GeoSpatial
Web Services. Book chapter in: Encyclopedia of Geographic Information
Systems, to appear. Springer-Verlag, 1st edition, 2007.
[Dee06] Deegree. Deegree Project (WMS, WFS, WCS, iGeoPortal, deeJUMP). Lat/-
Lon GmbH http://www.deegree.org, 2006.
[Dem06] Demis. Demis Web Map Server. Demis http://www.demis.nl/, 2006.
[DF06] Clodoveu A. Davis J´unior and Frederico Fonseca. Considerations from the
development of a local spatial data infrastructure. Information Technology
for Development, 12(4):273–290, 2006.
[DL99] Clodoveu Augusto Davis Junior and Alberto Henrique Frade Laender. Mul-
tiple representations in GIS: materialization through map generalization,
geometric, and spatial analysis operations. In ACM GIS’99: Proceedings of
7th International Symposium on Advances in Geographic Information Sys-
tems, pages 60–65, New York, NY, USA, 1999. ACM Press.
[FCOM06] Frederico Fonseca, Gilberto Cˆamara, H Onsrud, and A M Monteiro.
Networks of Innovation and the Establishment of a Spatial Data Infras-
tructure in Brazil. Information Technology for Development, 12(4):255–272,
2006.
[FGD97] FGDC Federal Geographic Data Committee. Metadata to Clearinghouse
Hands-On Tutorial, Washington, DC, 1997.
[FM05] Frederico T. Fonseca and James E. Martin. Toward an alternative notion of
information systems ontologies: Information engineering as a hermeneutic
enterprise. Journal of the American Society for Information Science and
Technology, 56(1):46–57, 2005.
[GGR05] Carlos Granell, Michael Gould, and Francisco Ramos. Service composition
for SDIs: Integrated components creation. In Proceedings of II Internation
on Geographic Information Management, August 2005.
[Gho01] Rina Ghose. Use of information technology for community empowerment:
transforming geographic information systems into community information
systems. Transactions in GIS, 2(5):141–163, January 2001.
REFER
ˆ
ENCIAS 81
[Gio06] Francisco Luiz Pomp´eia Gioielli. Tecnologias e padr˜oes abertos para o
dom´ınio geogr´afico na web: um estudo em ecoturismo. Master’s thesis,
Instituto Nacional de Pesquisas E spaciais, S˜ao Jos´e dos Campos, INPE-
13779-TDI/1053, 2006.
[GWZ04] Jihong Guan, Leichun Wang, and Shuigeng Zhou. Enabling GIS services
in a P2P environment. In Computer and Information Technology, 2004.
CIT ’04. The Fourth International Conference on, pages 776 – 781. IEEE,
September 2004.
[HC01a] Cay S. Horstmann and Gary Cornell. Core Java 2: Volume I - Fundamentos.
Makron Books, 1st edition, 2001.
[HC01b] Cay S. Horstmann and Gary Cornell. Core Java 2: Volume II - Advanced
Features. Prentice Hall PTR, 5th edition, 2001.
[HS05] Michael N. Huhns and Munindar P. Singh. Service-oriented computing: Key
concepts and principles. IEEE Internet Computing, 9(1):75–81, 2005.
[INS02] INSPIRE Architecture and Standards Working Group. INSPIRE Architec-
ture and Standards Position Paper, Brussels, Comission of the European
Community, 2002.
[JSTW02] Steve Jacoby, Jessica Smith, Lisa Ting, and Ian Williamson. Developing
a common spatial data infrastructure between state and local government:
An australian case study. International Journal of Geographical Information
Science, 16(4):305–322, 2002.
[KSR05] P. Kumar, V. Singh, and D. Reddy. Advanced traveler information system
for Hyderabad City. Intelligent Transportation Systems, IEEE Transactions
on, 6(1):26–37, March 2005.
[LCdQ01] P. Lima, Gilberto Cˆamara, and Gilberto R. de Queiroz. Intercˆambio de
Dados Geogr´aficos: Modelos, Formatos e Conversores. In III Workshop
Brasileiro de Geoinform´atica, November 2001.
[LCdQ02] P. Lima, Gilberto Cˆamara, and Gilberto R. de Queiroz. Ge oBR: Intercˆambio
Sint´atico e Semˆantico de Dados Espaciais. In IV Brazilian Symposium on
Geoinformatics, November 2002.
REFER
ˆ
ENCIAS 82
[LPD05] J. Lieberman, T. Pehle, and M. Dean. Semantic Evolution of Geospatial
Web Services. In W3C Workshop on Framewo rks for Semantic Web Services,
2005.
[Mab04] Marwa Mabrouk. OpenGIS Location Services (OpenLS): Core Services,
OGC document 03-006r3. OGC, Wayland, 2004.
[Man06] W. H. Erik De Man. Understanding SDI; complexity and institutionaliza-
tion. International Journal of Geographical Information Science, 20(3):329–
343, March 2006.
[Mas99] Ian Masser. All shapes and sizes: The first generation of national spatial data
infrastructures. International Journal of Geographical Information Science,
13(1):67–84, 1999.
[Mas05] Ian Masser. Some priorities for SDI related research. In Proceedings of the
FIG Working Week and GSDI 8: From Pharaohs to Geinformatics, Cairo,
Egypt, page 11. FIG, April 2005.
[MCN92] John Mylopoulos, Lawrence Chung, and Brian Nixon. Representing and
using non-functional requirements: a process-oriented approach. Software
Engineering, 18(6):483–497, 1992.
[ML05] David J. Maguire and Paul A. Longley. The emergence of geoportals and
their role in spatial data infrastructures. Computers, Environment and Ur-
ban Systems, 29(1):3–14, 2005.
[MRZW06] A. Mansourian, A. Rajabifard, M. J. Valadan Zoej, and I. Williamson. Using
SDI and web-based system to facilitate disaster management. Computers &
Geosciences, 32(3):303–315, April 2006.
[NBFRW04] Zorica Nedovic-Budic, Mary-Ellen F. Feeney, Abbas Rajabifard, and Ian
Williamson. Are SDIs serving the needs of local planning? case study of
Victoria, Australia and Illinois, USA. Computers, Environment and Urban
Systems, 28(4):329–351, July 2004.
[Onc05] Richard Onchaga. Towards Quality-aware Composition of Geo-services. In
Proceedings of the FIG Working Week and GSDI 8: From Pharaohs to Gein-
formatics, page 11. GSDI Association, April 2005.
REFER
ˆ
ENCIAS 83
[Ope] Open Geospatial Consortium. Sensor Web Enablement Architecture, OGC
document 05-090. OGC, Wayland.
[Ope05a] Open Geospatial Consortium. OGC Catalogue Services Specification, OGC
document 04-021r3. OGC, USA, 2005.
[Ope05b] Open Geospatial Consortium. Web Feature Service Implementation Specifi-
cation, OGC document 04-094. OGC, USA, 2005.
[Per03] George Percivall. OGC Reference Model OGC 03-040. Open Geospatial
Consortium, Inc, 2003.
[Pre05] Roger S. Pressman. Engenharia de Software. McGraw Hill, 5th edition,
2005.
[PWE99] Andrew Phillips, Ian Williamson, and Chukwudozie Ezigbalike. Spatial data
infrastructure concepts. The Australian Surveyor, 44(1):20–28, 1999.
[RCV06] Jose Ge raldo Ribeiro Junior, Glauber Tadeu S. Carmo, and Marco Tulio O.
Valente. Invocation of replicated web services using smart proxies. In Web-
Media ’06: Proceedings of the 12th Brazilian symposium on Multimedia and
the web, pages 138–147, New York, NY, USA, 2006. ACM Press.
[Ref06] Refractions Research. OGC Survey. Refractions http : //
www.refractions.net / white papers / ogcsurvey, Victoria, C anada, 2006.
[Rei05] Mark Reichardt. GSDI Depends on Widespread Adoption of OGC Stan-
dards. In Proceedings of the FIG Working Week and GSDI 8: From Phara-
ohs to Geinformatics, page 12. GSDI Association, April 2005.
[RLT05] M. Ruth, Feng Lin, and Shengru Tu. A client-side framework enabling
callbacks from web services. In Web Services, 2005. ECOWS 2005. Third
IEEE European Conference on, page 12. IEEE, November 2005.
[RWHJ00] Abbas Rajabifard, Ian P. Williamson, Peter Holland, and Glenn Johnstone.
From local to global SDI initiatives: a pyramid of building blocks. In IV
Global Spatial Data Infrastructure Conference Proceedings, March 2000.
[SDB
+
05] L. A. Souza, C. A. Davis J´unior, K. A. V. Borges, T. M. Delboni, and
A. H. F. Laender. The Role of Gazetteers in Geographic Knowledge Disco-
very on the Web. In (LA Web 2005): Proceedings of the 3rd Latin American
Web Congress, 2005.
REFER
ˆ
ENCIAS 84
[SKK06] Marius Scholten, Ralf Klamma, and Christian Kiehle. Evaluating perfor-
mance in spatial data infrastructures for geoprocessing. IEEE Internet Com-
puting, 10(5):34–41, 2006.
[Sky06] Skylab. J2ME OGC WMS Client. Skylab http :// www . skylab-
mobilesystems . com / en / products / j2me wms client . html, 2006.
[Son04] J. Sonnet. OWS 2 Common Architecture: WSDL, SOAP e UDDI. OGC,
Wayland, 2004.
[TA90] B. H. Tay and A. L. Ananda. A survey of remote procedure calls. ACM
Operating Systems Review, 24(3):68–79, July 1990.
[Tai05] M. G. Tait. Implementing geoportals: Applications of distributed gis. Com-
puters, Environment and Urban Systems, 29(1):33–47, 2005.
[TAM03] Jan Turkstra, Nelly Amemiya, and Jose Murgia. Local spatial data infras-
tructure, Trujillo-Peru. Habitat International, 27(1):669–682, 2003.
[TJH05] Xiaofeng Tao, Changjun Jiang, and Yaojun Han. Applying SOA to intelli-
gent transportation system. In Proceedings of the 2005 IEEE International
Conference on Services Computing, pages 101–104. IEEE, July 2005.
[UCF
+
05] Helton Nogueira Uchoa, Renata Juliana Cristal Coutinho, Paulo Ro-
berto Ferreira, Luiz Carlos Teixeira Coelho Filho, and Jorge Lu´ıs Nunes
e Silva Brito. Arquitetura OpenGis Baseada em Software Livre para Solu¸c˜ao
de Geoprocessamento. In Anais do XXII Congresso Brasileiro de Cartogra-
fia, 2005.
[Uni98] United States Geological Survey. Spatial Data Transfer Standard, 1998.
[Whi05] Arliss Whiteside. OpenGIS Web Services Common Specification, OGC do-
cument 05-008. OGC, Wayland, 2005.
[Wor04] World Wide Web Consortium. Web Services Architecture W3C Working
Group Note (Feb. 11 2004). W3C. www.w3.org/TR/2004/NOTE-ws-arch-
20040211/, 2004.
[WZK05] Haojun Wang, Roger Zimmermann, and Wei-Shinn Ku. ASPEN: An adap-
tive spatial peer-to-peer network. In GIS’05 Proceedings, pages 230–239.
ACM, November 2005.
85
Apˆendice A
Transaction Control Service
A.1 Entrada
O documento XML seguinte apresenta o pseudoc´odigo apresentado no cap´ıtulo 4 em
seu formato de entrada original.
<?xml version="1.0"?>
<?xml-stylesheet type="text/xsl" href="java.xslt"?>
<transaction xmlns:xsi="http://www.w3.org/2001/XMLSchema -in stan ce"
xsi:noNamespaceSchemaLocation="tcs.xsd">
<comm>
<type>input</type>
<value>target</value>
</comm>
<comm>
<type>input</type>
<value>myLocation</value>
</comm>
<comm>
<comm>
<type>invocation</type>
<alias>myLocAd</alias>
<params>
<param>myLocation</param>
<param>Tdirectory</param>
<param>dxs</param>
</params>
<service>location</service>
</comm>
<comm>
<type>invocation</type>
<params>
<param>target</param>
<param>
<comm>
<type>dxs</type>
<method>set</method>
AP
ˆ
ENDICE A. TRANSACTION CONTROL SERVICE 86
<value>0</value>
</comm>
</param>
</params>
<service>cityHall.location</service>
</comm>
<comm>
<type>invocation</type>
<params>
<param>target</param>
<param>
<comm>
<type>dxs</type>
<method>set</method>
<value>0</value>
</comm>
</param>
</params>
<service>teleCo.location</service>
</comm>
<comm>
<type>invocation</type>
<params>
<param>target</param>
<param>
<comm>
<type>dxs</type>
<method>set</method>
<value>0</value>
</comm>
</param>
</params>
<service>coAssociation.location</service>
</comm>
<comm>
<type>invocation</type>
<params>
<param>target</param>
<param>
<comm>
<type>dxs</type>
<method>set</method>
<value>0</value>
</comm>
</param>
</params>
<service>tourismGuide.location</service>
</comm>
<comm>
<type>invocation</type>
<alias>pAd</alias>
<params>
<param>
<comm>
<type>dxs</type>
AP
ˆ
ENDICE A. TRANSACTION CONTROL SERVICE 87
<method>get</method>
<value>0</value>
</comm>
</param>
<param>Tdirectory</param>
<param>dxs</param>
</params>
<service>pointsOfInterest</service>
</comm>
</comm>
<comm>
<type>dxs</type>
<method>wait</method>
<value>pAd</value>
</comm>
<comm>
<type>output</type>
<value>
<comm>
<type>dxs</type>
<method>get</method>
<value>pAd</value>
</comm>
</value>
</comm>
<comm>
<type>input</type>
<value>p2</value>
</comm>
<comm>
<type>dxs</type>
<method>store</method>
<alias>p2Ad</alias>
<value>p2</value>
</comm>
<comm>
<type>invocation</type>
<params>
<param>Troute</param>
<param>myLocAd</param>
<param>p2Ad</param>
<param>
<comm>
<type>dxs</type>
<method>get</method>
<value>0</value>
</comm>
</param>
</params>
<service>query</service>
</comm>
</transaction>
AP
ˆ
ENDICE A. TRANSACTION CONTROL SERVICE 88
A.2 Formato em XML Schema
O c´odigo seguinte apresenta o formato em XML Schema para a entrada do Transaction
Control Service.
<?xml version="1.0" encoding="UTF-8"?>
<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema">
<xs:simpleType name="T_type">
<xs:restriction base="xs:string">
<xs:enumeration value="dxs"/>
<xs:enumeration value="input"/>
<xs:enumeration value="invocation"/>
<xs:enumeration value="output"/>
</xs:restriction>
</xs:simpleType>
<xs:simpleType name="T_service">
<xs:restriction base="xs:string">
<xs:enumeration value="cityHall.location"/>
<xs:enumeration value="coAssociation.location"/>
<xs:enumeration value="location"/>
<xs:enumeration value="pointsOfInterest"/>
<xs:enumeration value="query"/>
<xs:enumeration value="teleCo.location"/>
<xs:enumeration value="tourismGuide.location"/>
</xs:restriction>
</xs:simpleType>
<xs:simpleType name="T_method">
<xs:restriction base="xs:string">
<xs:enumeration value="get"/>
<xs:enumeration value="set"/>
<xs:enumeration value="store"/>
<xs:enumeration value="wait"/>
</xs:restriction>
</xs:simpleType>
<xs:simpleType name="T_alias">
<xs:restriction base="xs:string">
<xs:enumeration value="myLocAd"/>
<xs:enumeration value="p2Ad"/>
<xs:enumeration value="pAd"/>
</xs:restriction>
</xs:simpleType>
<xs:complexType name="T_value" mixed="true">
<xs:sequence>
<xs:element ref="comm" minOccurs="0"/>
</xs:sequence>
</xs:complexType>
<xs:complexType name="T_transaction">
<xs:sequence>
<xs:element ref="comm" maxOccurs="unbounded"/>
</xs:sequence>
</xs:complexType>
<xs:complexType name="T_params">
<xs:sequence>
<xs:element ref="param" maxOccurs="unbounded"/>
AP
ˆ
ENDICE A. TRANSACTION CONTROL SERVICE 89
</xs:sequence>
</xs:complexType>
<xs:complexType name="T_param" mixed="true">
<xs:sequence>
<xs:element ref="comm" minOccurs="0"/>
</xs:sequence>
</xs:complexType>
<xs:complexType name="T_comm">
<xs:choice>
<xs:element ref="comm" maxOccurs="unbounded"/>
<xs:sequence>
<xs:element ref="type"/>
<xs:choice>
<xs:element ref="value"/>
<xs:sequence>
<xs:element ref="alias" minOccurs="0"/>
<xs:element ref="params"/>
<xs:element ref="service"/>
</xs:sequence>
<xs:sequence>
<xs:element ref="method"/>
<xs:element ref="alias" minOccurs="0"/>
<xs:element ref="value"/>
</xs:sequence>
</xs:choice>
</xs:sequence>
</xs:choice>
</xs:complexType>
<xs:element name="value" type="T_value"/>
<xs:element name="type" type="T_type"/>
<xs:element name="transaction" type="T_transaction"/>
<xs:element name="service" type="T_service"/>
<xs:element name="params" type="T_params"/>
<xs:element name="param" type="T_param"/>
<xs:element name="method" type="T_method"/>
<xs:element name="comm" type="T_comm"/>
<xs:element name="alias" type="T_alias"/>
</xs:schema>
A.3 Transformador
O c´odigo seguinte apresenta o do c umento XSLT para transforma¸c˜ao do documento
de entrada do Transaction Control Service para c´odigo execut´avel. O XSLT apresentado
representa o transformador da entrada para a linguagem Java.
<?xml version="1.0" encoding="UTF-8"?>
<xsl:stylesheet version="2.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform"
xmlns:xs="http://www.w3.org/2001/XMLSchema"
xmlns:fn="http://www.w3.org/2005/xpath-functions">
<xsl:output method="xml" version="1.0" encoding="UTF-8" indent="yes"/>
<xsl:template match="/">
<body>
AP
ˆ
ENDICE A. TRANSACTION CONTROL SERVICE 90
<p>// Inicializacao<br/>
loadServices(addrCatalog);<br/>
DXSService dxs = new DXSService();<br/>
dxs.start();</p>
<xsl:for-each select="/transaction/comm">
<p>
<xsl:apply-templates select="."/>;
</p>
</xsl:for-each>
<!-- <xsl:apply-templates select="/transaction/comm"/> -->
<p>// Fechamento</p>
</body>
</xsl:template>
<xsl:template match="comm">
<xsl:choose>
<xsl:when test="type=’invocation’">
<xsl:apply-templates select="alias"/>
<xsl:value-of select="service"/>(<xsl:apply-templates select="params"/>)
</xsl:when>
<xsl:when test="type=’input’">
// Interacao com o usuario - Programador deve de fini r entrada/saida<br/>
<xsl:value-of select="value"/> = client.from()
</xsl:when>
<xsl:when test="type=’output’">
// Interacao com o usuario - Programador deve de fini r entrada/saida
<br/>client.to(<xsl:value-of select="value"/>
<xsl:apply-templates select="comm"/>)
</xsl:when>
<xsl:when test="type=’dxs’">
<xsl:choose>
<xsl:when test="method=’store’">
<xsl:apply-templates select="alias"/>dxs.store(<xsl:val ue-o f
select="value"/>)
</xsl:when>
<xsl:when test="method=’wait’">
<xsl:apply-templates select="alias"/>dxs.waitItem(<xsl: valu e-of
select="value"/>)
</xsl:when>
<xsl:when test="method=’get’">
<xsl:apply-templates select="alias"/>dxs.getItem(<xsl:v alue -of
select="value"/>)
</xsl:when>
<xsl:when test="method=’set’">
<xsl:apply-templates select="alias"/>dxs.setItem(<xsl:v alue -of
select="value"/>)
</xsl:when>
</xsl:choose>
</xsl:when>
<xsl:otherwise>
// Comandos paralelos<br/>
<xsl:for-each select="comm">
<xsl:apply-templates select="."/><xsl:if test="position() != last()">;<br/>
</xsl:if>
</xsl:for-each>
</xsl:otherwise>
AP
ˆ
ENDICE A. TRANSACTION CONTROL SERVICE 91
</xsl:choose>
</xsl:template>
<xsl:template match="alias">
<xsl:value-of select="."/> =
</xsl:template>
<xsl:template match="params">
<xsl:for-each select="param">
<xsl:choose>
<xsl:when test="not(comm)">
<xsl:value-of select="."/>
<xsl:if test="position() != last()">, </xsl:if>
</xsl:when>
<xsl:otherwise>
<xsl:apply-templates select="comm"/>
<xsl:if test="position() != last()">, </xsl:if>
</xsl:otherwise>
</xsl:choose>
</xsl:for-each>
</xsl:template>
</xsl:stylesheet>
92
Apˆendice B
Esquemas de Servi¸cos Web
Geoespaciais
B.1 WSDL Geocoder n˜ao-padr˜ao
O c´odigo seguinte apresenta o WSDL para servi¸cos do tipo Geocoder n˜ao-padr˜ao
usados no experimento.
<?xml version="1.0" encoding="UTF-8"?>
<wsdl:definitions targetNamespace=
"http://localhost:8080/axis/services/Geocoder_BasemapA"
xmlns:apachesoap="http://xml.apache.org/xml-soap"
xmlns:impl=
"http://localhost:8080/axis/services/Geocoder_BasemapA"
xmlns:intf=
"http://localhost:8080/axis/services/Geocoder_BasemapA"
xmlns:soapenc="http://schemas.xmlsoap.org/soap/encoding/"
xmlns:tns1="urn:BeanService"
xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/"
xmlns:wsdlsoap="http://schemas.xmlsoap.org/wsdl/soap/"
xmlns:xsd="http://www.w3.org/2001/XMLSchema">
<!--WSDL created by Apache Axis version: 1.3
Built on Oct 05, 2005 (05:23:37 EDT)-->
<wsdl:types>
<schema targetNamespace="urn:BeanService"
xmlns="http://www.w3.org/2001/XMLSchema">
<import namespace="http://schemas.xmlsoap.org/soap/encod ing/ "/>
<complexType name="GeocoderFeatureRequest">
<sequence>
<element name="featureType" nillable="true" type="xsd:string"/>
<element name="query1" nillable="true" type="xsd:string"/>
<element name="query2" nillable="true" type="xsd:string"/>
</sequence>
</complexType>
<complexType name="GeocoderFeatureResponse">
<sequence>
AP
ˆ
ENDICE B. ESQUEMAS DE SERVIC¸ OS WEB GEOESPACIAIS 93
<element name="builderNumber" nillable="true" type="xsd:string"/>
<element name="cityName" nillable="true" type="xsd:string"/>
<element name="countryName" nillable="true" type="xsd:string"/>
<element name="element" nillable="true" type="xsd:string"/>
<element name="featureType" nillable="true" type="xsd:string"/>
<element name="geometry" nillable="true" type="xsd:string"/>
<element name="landmarkTitle" nillable="true" type="xsd:string"/>
<element name="lat" type="xsd:double"/>
<element name="lon" type="xsd:double"/>
<element name="neighborhood" nillable="true" type="xsd:string"/>
<element name="organizationName" nillable="true" type="xsd:string"/>
<element name="postalCode" nillable="true" type="xsd:string"/>
<element name="stateName" nillable="true" type="xsd:string"/>
<element name="streetName" nillable="true" type="xsd:string"/>
<element name="telephoneNumber" nillable="true" type="xsd:string"/>
<element name="telephoneSubscriber" nillable="true" type="xsd:string"/>
<element name="x" type="xsd:double"/>
<element name="y" type="xsd:double"/>
</sequence>
</complexType>
<complexType name="GeocoderFeatureTypeDescriptor">
<sequence/>
</complexType>
<complexType name="GeocoderCapabilities">
<sequence/>
</complexType>
</schema>
</wsdl:types>
<wsdl:message name="getFeatureResponse">
<wsdl:part name="getFeatureReturn" type="tns1:GeocoderFeatureResponse"/>
</wsdl:message>
<wsdl:message name="describeFeatureTypeResponse">
<wsdl:part name="describeFeatureTypeReturn"
type="tns1:GeocoderFeatureTypeDescriptor"/>
</wsdl:message>
<wsdl:message name="describeFeatureTypeRequest">
</wsdl:message>
<wsdl:message name="getFeatureResponse1">
<wsdl:part name="getFeatureReturn"
type="tns1:GeocoderFeatureResponse"/>
</wsdl:message>
<wsdl:message name="getCapabilitiesRequest">
</wsdl:message>
<wsdl:message name="getFeatureRequest">
<wsdl:part name="geocoderFeatureRequest"
type="tns1:GeocoderFeatureRequest"/>
</wsdl:message>
<wsdl:message name="getCapabilitiesResponse">
<wsdl:part name="getCapabilitiesReturn"
type="tns1:GeocoderCapabilities"/>
</wsdl:message>
<wsdl:message name="getFeatureRequest1">
</wsdl:message>
<wsdl:portType name="Geocoder_BasemapA">
AP
ˆ
ENDICE B. ESQUEMAS DE SERVIC¸ OS WEB GEOESPACIAIS 94
<wsdl:operation name="getFeature"
parameterOrder="geocoderFeatureRequest">
<wsdl:input message="impl:getFeatureRequest"
name="getFeatureRequest"/>
<wsdl:output message="impl:getFeatureResponse"
name="getFeatureResponse"/>
</wsdl:operation>
<wsdl:operation name="getFeature">
<wsdl:input message="impl:getFeatureRequest1"
name="getFeatureRequest1"/>
<wsdl:output message="impl:getFeatureResponse1"
name="getFeatureResponse1"/>
</wsdl:operation>
<wsdl:operation name="describeFeatureType">
<wsdl:input message="impl:describeFeatureTypeRequest"
name="describeFeatureTypeRequest"/>
<wsdl:output message="impl:describeFeatureTypeResponse"
name="describeFeatureTypeResponse"/>
</wsdl:operation>
<wsdl:operation name="getCapabilities">
<wsdl:input message="impl:getCapabilitiesRequest"
name="getCapabilitiesRequest"/>
<wsdl:output message="impl:getCapabilitiesResponse"
name="getCapabilitiesResponse"/>
</wsdl:operation>
</wsdl:portType>
<wsdl:binding name="Geocoder_BasemapASoapBinding"
type="impl:Geocoder_BasemapA">
<wsdlsoap:binding style="rpc"
transport="http://schemas.xmlsoap.org/soap/http"/>
<wsdl:operation name="getFeature">
<wsdlsoap:operation soapAction=""/>
<wsdl:input name="getFeatureRequest">
<wsdlsoap:body
encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"
namespace="http://DefaultNamespace" use="encoded"/>
</wsdl:input>
<wsdl:output name="getFeatureResponse">
<wsdlsoap:body
encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"
namespace="http://localhost:8080/axis/services/Geocoder_BasemapA"
use="encoded"/>
</wsdl:output>
</wsdl:operation>
<wsdl:operation name="getFeature">
<wsdlsoap:operation soapAction=""/>
<wsdl:input name="getFeatureRequest1">
<wsdlsoap:body
encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"
namespace="http://DefaultNamespace" use="encoded"/>
</wsdl:input>
<wsdl:output name="getFeatureResponse1">
<wsdlsoap:body
encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"
namespace="http://localhost:8080/axis/services/Geocoder_BasemapA"
AP
ˆ
ENDICE B. ESQUEMAS DE SERVIC¸ OS WEB GEOESPACIAIS 95
use="encoded"/>
</wsdl:output>
</wsdl:operation>
<wsdl:operation name="describeFeatureType">
<wsdlsoap:operation soapAction=""/>
<wsdl:input name="describeFeatureTypeRequest">
<wsdlsoap:body
encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"
namespace="http://DefaultNamespace" use="encoded"/>
</wsdl:input>
<wsdl:output name="describeFeatureTypeResponse">
<wsdlsoap:body
encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"
namespace="http://localhost:8080/axis/services/Geocoder_BasemapA"
use="encoded"/>
</wsdl:output>
</wsdl:operation>
<wsdl:operation name="getCapabilities">
<wsdlsoap:operation soapAction=""/>
<wsdl:input name="getCapabilitiesRequest">
<wsdlsoap:body
encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"
namespace="http://DefaultNamespace" use="encoded"/>
</wsdl:input>
<wsdl:output name="getCapabilitiesResponse">
<wsdlsoap:body
encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"
namespace="http://localhost:8080/axis/services/Geocoder_BasemapA"
use="encoded"/>
</wsdl:output>
</wsdl:operation>
</wsdl:binding>
<wsdl:service name="Geocoder_BasemapAService">
<wsdl:port
binding="impl:Geocoder_BasemapASoapBinding"
name="Geocoder_BasemapA">
<wsdlsoap:address
location="http://localhost:8080/axis/services/Geocoder_BasemapA"/>
</wsdl:port>
</wsdl:service>
</wsdl:definitions>
B.2 WSDL Directory n˜ao-padr˜ao
O c´odigo seguinte apresenta o WSDL para servi¸cos do tipo Directory n˜ao-padr˜ao
usados no experimento.
<?xml version="1.0" encoding="UTF-8"?>
<wsdl:definitions targetNamespace="http://localhost:8080 /ax is/D irec tory .jws "
xmlns:apachesoap="http://xml.apache.org/xml-soap"
xmlns:impl="http://localhost:8080/axis/Directory.jws"
xmlns:intf="http://localhost:8080/axis/Directory.jws"
xmlns:soapenc="http://schemas.xmlsoap.org/soap/encoding/"
AP
ˆ
ENDICE B. ESQUEMAS DE SERVIC¸ OS WEB GEOESPACIAIS 96
xmlns:tns1="http://DefaultNamespace" xmlns:wsdl="http:/ /sch emas .xml soap .or g/ws dl/"
xmlns:wsdlsoap="http://schemas.xmlsoap.org/wsdl/soap/"
xmlns:xsd="http://www.w3.org/2001/XMLSchema">
<!--WSDL created by Apache Axis version: 1.3
Built on Oct 05, 2005 (05:23:37 EDT)-->
<wsdl:types>
<schema targetNamespace="http://DefaultNamespace"
xmlns="http://www.w3.org/2001/XMLSchema">
<import namespace="http://schemas.xmlsoap.org/soap/encod ing/ "/>
<complexType name="DirectoryFeatureRequest">
<sequence>
<element name="featureType" nillable="true" type="xsd:string"/>
<element name="query1" nillable="true" type="xsd:string"/>
<element name="query2" nillable="true" type="xsd:string"/>
</sequence>
</complexType>
<complexType name="DirectoryFeatureResponse">
<sequence>
<element name="builderNumber" nillable="true" type="xsd:string"/>
<element name="cityName" nillable="true" type="xsd:string"/>
<element name="countryName" nillable="true" type="xsd:string"/>
<element name="element" nillable="true" type="xsd:string"/>
<element name="featureType" nillable="true" type="xsd:string"/>
<element name="geometry" nillable="true" type="xsd:string"/>
<element name="landmarkTitle" nillable="true" type="xsd:string"/>
<element name="lat" type="xsd:double"/>
<element name="lon" type="xsd:double"/>
<element name="neighborhood" nillable="true" type="xsd:string"/>
<element name="organizationName" nillable="true" type="xsd:string"/>
<element name="postalCode" nillable="true" type="xsd:string"/>
<element name="stateName" nillable="true" type="xsd:string"/>
<element name="streetName" nillable="true" type="xsd:string"/>
<element name="telephoneNumber" nillable="true" type="xsd:string"/>
<element name="telephoneSubscriber" nillable="true" type="xsd:string"/>
<element name="x" type="xsd:double"/>
<element name="y" type="xsd:double"/>
</sequence>
</complexType>
<complexType name="DirectoryFeatureTypeDescriptor">
<sequence/>
</complexType>
<complexType name="DirectoryCapabilities">
<sequence/>
</complexType>
</schema>
</wsdl:types>
<wsdl:message name="getCapabilitiesRequest">
</wsdl:message>
<wsdl:message name="describeFeatureTypeRequest">
</wsdl:message>
<wsdl:message name="getFeatureResponse1">
<wsdl:part name="getFeatureReturn"
type="tns1:DirectoryFeatureResponse"/>
</wsdl:message>
<wsdl:message name="getFeatureRequest1">
AP
ˆ
ENDICE B. ESQUEMAS DE SERVIC¸ OS WEB GEOESPACIAIS 97
</wsdl:message>
<wsdl:message name="describeFeatureTypeResponse">
<wsdl:part name="describeFeatureTypeReturn"
type="tns1:DirectoryFeatureTypeDescriptor"/>
</wsdl:message>
<wsdl:message name="getFeatureResponse">
<wsdl:part name="getFeatureReturn"
type="tns1:DirectoryFeatureResponse"/>
</wsdl:message>
<wsdl:message name="getFeatureRequest">
<wsdl:part name="geocoderFeatureRequest"
type="tns1:DirectoryFeatureRequest"/>
</wsdl:message>
<wsdl:message name="getCapabilitiesResponse">
<wsdl:part name="getCapabilitiesReturn"
type="tns1:DirectoryCapabilities"/>
</wsdl:message>
<wsdl:portType name="Directory">
<wsdl:operation name="getFeature"
parameterOrder="geocoderFeatureRequest">
<wsdl:input message="impl:getFeatureRequest"
name="getFeatureRequest"/>
<wsdl:output message="impl:getFeatureResponse"
name="getFeatureResponse"/>
</wsdl:operation>
<wsdl:operation name="getFeature">
<wsdl:input message="impl:getFeatureRequest1"
name="getFeatureRequest1"/>
<wsdl:output message="impl:getFeatureResponse1"
name="getFeatureResponse1"/>
</wsdl:operation>
<wsdl:operation name="describeFeatureType">
<wsdl:input message="impl:describeFeatureTypeRequest"
name="describeFeatureTypeRequest"/>
<wsdl:output message="impl:describeFeatureTypeResponse"
name="describeFeatureTypeResponse"/>
</wsdl:operation>
<wsdl:operation name="getCapabilities">
<wsdl:input message="impl:getCapabilitiesRequest"
name="getCapabilitiesRequest"/>
<wsdl:output message="impl:getCapabilitiesResponse"
name="getCapabilitiesResponse"/>
</wsdl:operation>
</wsdl:portType>
<wsdl:binding name="DirectorySoapBinding" type="impl:Directory">
<wsdlsoap:binding style="rpc"
transport="http://schemas.xmlsoap.org/soap/http"/>
<wsdl:operation name="getFeature">
<wsdlsoap:operation soapAction=""/>
<wsdl:input name="getFeatureRequest">
<wsdlsoap:body
encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"
namespace="http://DefaultNamespace" use="encoded"/>
</wsdl:input>
<wsdl:output name="getFeatureResponse">
AP
ˆ
ENDICE B. ESQUEMAS DE SERVIC¸ OS WEB GEOESPACIAIS 98
<wsdlsoap:body
encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"
namespace="http://localhost:8080/axis/Directory.jws"
use="encoded"/>
</wsdl:output>
</wsdl:operation>
<wsdl:operation name="getFeature">
<wsdlsoap:operation soapAction=""/>
<wsdl:input name="getFeatureRequest1">
<wsdlsoap:body
encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"
namespace="http://DefaultNamespace" use="encoded"/>
</wsdl:input>
<wsdl:output name="getFeatureResponse1">
<wsdlsoap:body encodingStyle="http://schemas.xmlsoap.or g/so ap/e ncod ing/ "
namespace="http://localhost:8080/axis/Directory.jws" us e="e ncod ed"/ >
</wsdl:output>
</wsdl:operation>
<wsdl:operation name="describeFeatureType">
<wsdlsoap:operation soapAction=""/>
<wsdl:input name="describeFeatureTypeRequest">
<wsdlsoap:body encodingStyle="http://schemas.xmlsoap.or g/so ap/e ncod ing/ "
namespace="http://DefaultNamespace" use="encoded"/>
</wsdl:input>
<wsdl:output name="describeFeatureTypeResponse">
<wsdlsoap:body encodingStyle="http://schemas.xmlsoap.or g/so ap/e ncod ing/ "
namespace="http://localhost:8080/axis/Directory.jws" us e="e ncod ed"/ >
</wsdl:output>
</wsdl:operation>
<wsdl:operation name="getCapabilities">
<wsdlsoap:operation soapAction=""/>
<wsdl:input name="getCapabilitiesRequest">
<wsdlsoap:body encodingStyle="http://schemas.xmlsoap.or g/so ap/e ncod ing/ "
namespace="http://DefaultNamespace" use="encoded"/>
</wsdl:input>
<wsdl:output name="getCapabilitiesResponse">
<wsdlsoap:body encodingStyle="http://schemas.xmlsoap.or g/so ap/e ncod ing/ "
namespace="http://localhost:8080/axis/Directory.jws" us e="e ncod ed"/ >
</wsdl:output>
</wsdl:operation>
</wsdl:binding>
<wsdl:service name="DirectoryService">
<wsdl:port binding="impl:DirectorySoapBinding" name="Directory">
<wsdlsoap:address location="http://localhost:8080/axis/D irec tor y.jw s"/>
</wsdl:port>
</wsdl:service>
</wsdl:definitions>
B.3 WSDL WFS
O c´odigo seguinte apresenta o WSDL para servi¸cos do tipo Web Feature Service
usados no experimento.
<?xml version="1.0" encoding="UTF-8"?>
AP
ˆ
ENDICE B. ESQUEMAS DE SERVIC¸ OS WEB GEOESPACIAIS 99
<wsdl:definitions targetNamespace="http://localhost:8080 /ax is/w fs.j ws"
xmlns:apachesoap="http://xml.apache.org/xml-soap"
xmlns:impl="http://localhost:8080/axis/wfs.jws"
xmlns:intf="http://localhost:8080/axis/wfs.jws"
xmlns:soapenc="http://schemas.xmlsoap.org/soap/encoding/"
xmlns:tns1="http://DefaultNamespace"
xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/"
xmlns:wsdlsoap="http://schemas.xmlsoap.org/wsdl/soap/"
xmlns:xsd="http://www.w3.org/2001/XMLSchema">
<!--WSDL created by Apache Axis version: 1.3
Built on Oct 05, 2005 (06:10:28 EDT)-->
<wsdl:documentation xmlns:dc="http://purl.org/dc/element s/1. 1/" >
<dc:description>
HTTP/1.1 protocol bindings for WFS interfaces.
</dc:description>
<dc:date>2004-06-07</dc:date>
</wsdl:documentation>
<wsdl:import namespace="http://www.opengis.net/wfs/reque sts"
location="./wfs-xml-interfaces.wsdl"/>
<wsdl:binding name="wfs-POST" type="wfs-req:wfs">
<wsdl:documentation>
wfs interface bound to the HTTP/1.1 POST method.
</wsdl:documentation>
<http:binding verb="POST"/>
<wsdl:operation name="wfs.getCapabilities">
<http:operation location="wfs/http"/>
<wsdl:input>
<mime:mimeXml/>
</wsdl:input>
<wsdl:output>
<mime:mimeXml/>
</wsdl:output>
<wsdl:fault name="ServiceExceptionReport">
<mime:mimeXml/>
</wsdl:fault>
</wsdl:operation>
<wsdl:operation name="wfs.describeFeatureType">
<http:operation location="wfs/http"/>
<wsdl:input>
<mime:mimeXml/>
</wsdl:input>
<wsdl:output>
<mime:mimeXml/>
</wsdl:output>
<wsdl:fault name="ServiceExceptionReport">
<mime:mimeXml/>
</wsdl:fault>
</wsdl:operation>
<wsdl:operation name="wfs.getFeature">
<http:operation location="wfs/http"/>
<wsdl:input>
<mime:mimeXml/>
</wsdl:input>
AP
ˆ
ENDICE B. ESQUEMAS DE SERVIC¸ OS WEB GEOESPACIAIS 100
<wsdl:output>
<mime:mimeXml/>
</wsdl:output>
<wsdl:fault name="ServiceExceptionReport">
<mime:mimeXml/>
</wsdl:fault>
</wsdl:operation>
<wsdl:operation name="wfs.getFeatureWithLock">
<http:operation location="wfs/http"/>
<wsdl:input>
<mime:mimeXml/>
</wsdl:input>
<wsdl:output>
<mime:mimeXml/>
</wsdl:output>
<wsdl:fault name="ServiceExceptionReport">
<mime:mimeXml/>
</wsdl:fault>
</wsdl:operation>
<wsdl:operation name="wfs.getGMLObject">
<http:operation location="wfs/http"/>
<wsdl:input>
<mime:mimeXml/>
</wsdl:input>
<wsdl:output>
<mime:mimeXml/>
</wsdl:output>
<wsdl:fault name="ServiceExceptionReport">
<mime:mimeXml/>
</wsdl:fault>
</wsdl:operation>
<wsdl:operation name="wfs.lockFeature">
<http:operation location="wfs/http"/>
<wsdl:input>
<mime:mimeXml/>
</wsdl:input>
<wsdl:output>
<mime:mimeXml/>
</wsdl:output>
<wsdl:fault name="ServiceExceptionReport">
<mime:mimeXml/>
</wsdl:fault>
</wsdl:operation>
<wsdl:operation name="wfs.transaction">
<http:operation location="wfs/http"/>
<wsdl:input>
<mime:mimeXml/>
</wsdl:input>
<wsdl:output>
<mime:mimeXml/>
</wsdl:output>
<wsdl:fault name="ServiceExceptionReport">
<mime:mimeXml/>
</wsdl:fault>
</wsdl:operation>
AP
ˆ
ENDICE B. ESQUEMAS DE SERVIC¸ OS WEB GEOESPACIAIS 101
</wsdl:binding>
</wsdl:definitions>
B.4 WSDL WMS
O c´odigo seguinte apresenta o WSDL para servi¸cos do tipo Web Map Service usados
no experimento.
<?xml version="1.0" encoding="UTF-8"?>
<wsdl:definitions targetNamespace="http://localhost:8080 /ax is/w ms.j ws"
xmlns:apachesoap="http://xml.apache.org/xml-soap"
xmlns:impl="http://localhost:8080/axis/wms.jws"
xmlns:intf="http://localhost:8080/axis/wms.jws"
xmlns:soapenc="http://schemas.xmlsoap.org/soap/encoding/"
xmlns:tns1="http://DefaultNamespace"
xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/"
xmlns:wsdlsoap="http://schemas.xmlsoap.org/wsdl/soap/"
xmlns:xsd="http://www.w3.org/2001/XMLSchema">
<!--WSDL created by Apache Axis version: 1.3
Built on Oct 05, 2005 (05:35:12 EDT)-->
<wsdl:documentation>
</wsdl:documentation>
<wsdl:import namespace="http://www.opengis.net/wms/reque sts "
location="./wms-xml-interfaces.wsdl"/>
<wsdl:binding name="WMS_SOAP_Binding"
type="wms-req:WMS_XML_Port">
<soap:binding style="document"
transport="http://schemas.xmlsoap.org/soap/http"/>
<wsdl:operation name="GetCapabilities">
<soap:operation/>
<wsdl:input>
<soap:body use="literal"/>
</wsdl:input>
<wsdl:output>
<soap:body use="literal"/>
</wsdl:output>
<wsdl:fault name="exception">
<soap:fault name="exception" use="literal"/>
</wsdl:fault>
</wsdl:operation>
<wsdl:operation name="GetMap">
<soap:operation/>
<wsdl:input>
<soap:body use="literal"/>
</wsdl:input>
<wsdl:output>
<mime:content type="image/*"/>
</wsdl:output>
<wsdl:fault name="exception">
<soap:fault name="exception" use="literal"/>
</wsdl:fault>
</wsdl:operation>
</wsdl:binding>
</wsdl:definitions>
AP
ˆ
ENDICE B. ESQUEMAS DE SERVIC¸ OS WEB GEOESPACIAIS 102
B.5 Schema Route n˜ao-padr˜ao
O c´odigo seguinte apresenta o formato em XML Schema para os tipos do Route n˜ao-
padr˜ao usados na avalia¸c˜ao. O formato ´e baseado no servi¸co Route padr˜ao e altera
principalmente os valores default.
<?xml version="1.0" encoding="UTF-8"?>
<schema targetNamespace="http://www.opengis.net/xls"
xmlns:gml="http://www.opengis.net/gml"
xmlns="http://www.w3.org/2001/XMLSchema"
xmlns:xls="http://www.opengis.net/xls"
elementFormDefault="qualified" version="1.1">
<import namespace="http://www.opengis.net/gml" schemaLocation="gml4xls.xsd"/>
<include schemaLocation="XLS.xsd"/>
<element name="DetermineRouteRequest"
type="xls:DetermineRouteRequestType"
substitutionGroup="xls:_RequestParameters">
<annotation>
<documentation>Specifies the Determine Route request
parameters.</documentation>
</annotation>
</element>
<complexType name="DetermineRouteRequestType">
<annotation>
<documentation>Defines the Determine Route request
parameters.</documentation>
</annotation>
<complexContent>
<extension base="xls:AbstractRequestParametersType">
<sequence>
<choice>
<element ref="xls:RouteHandle">
<annotation>
<documentation>Reference to a proviously determined
route stored at the Route Determination Service
server.</documentation>
</annotation>
</element>
<element ref="xls:RoutePlan"/>
</choice>
<element ref="xls:RouteInstructionsRequest" minOccurs="0">
<annotation>
<documentation>Request parameters for turn-by-turn
route directions and advisories formatted for
presentation.</documentation>
</annotation>
</element>
<element ref="xls:RouteGeometryRequest" minOccurs="0">
<annotation>
<documentation>Request parameters for route
geometry.</documentation>
</annotation>
</element>
AP
ˆ
ENDICE B. ESQUEMAS DE SERVIC¸ OS WEB GEOESPACIAIS 103
<element ref="xls:RouteMapRequest" minOccurs="0"/>
</sequence>
<attribute name="provideRouteHandle" type="boolean"
use="optional" default="false">
<annotation>
<documentation>Requests the return of a route
handle.</documentation>
</annotation>
</attribute>
<attribute name="distanceUnit" type="xls:DistanceUnitType"
use="optional" default="M">
<annotation>
<documentation>Specifies the unit for measuring
distance.</documentation>
</annotation>
</attribute>
</extension>
</complexContent>
</complexType>
<element name="RoutePlan" type="xls:RoutePlanType">
<annotation>
<documentation>The criteria upon which a route is
determined.</documentation>
</annotation>
</element>
<complexType name="RoutePlanType">
<annotation>
<documentation>Defines the criteria upon which a route
is determined.</documentation>
</annotation>
<sequence>
<element ref="xls:RoutePreference"/>
<element ref="xls:WayPointList"/>
<element ref="xls:AvoidList" minOccurs="0"/>
</sequence>
<attribute name="useRealTimeTraffic" type="boolean"
use="optional" default="true">
<annotation>
<documentation>Specifies whether to use real time traffic
information when determining the best route.</documentation>
</annotation>
</attribute>
<attribute name="expectedStartTime" type="dateTime" use="optional">
<annotation>
<documentation>Specifies the date and time at which travel
is expected to begin. Specified in the format YYYY-MM-DD
HH:MM. Defaults to current date and time.</documentation>
</annotation>
</attribute>
<attribute name="expectedEndTime" type="dateTime" use="optional">
<annotation>
<documentation>Specifies the date and time at which travel
is expected to end. The format for the end time is
specified as Duration</documentation>
</annotation>
AP
ˆ
ENDICE B. ESQUEMAS DE SERVIC¸ OS WEB GEOESPACIAIS 104
</attribute>
</complexType>
<element name="AvoidList" type="xls:AvoidListType">
<annotation>
<documentation>The list of areas, locations, and types of
features in which the route should avoid passing
through.</documentation>
</annotation>
</element>
<complexType name="AvoidListType">
<annotation>
<documentation>Defines the list of areas, locations, and
types of features in which the route should avoi d
passing through.</documentation>
</annotation>
<sequence>
<element ref="xls:AOI" minOccurs="0" maxOccurs="unbounded">
<annotation>
<documentation>List of geographic areas to
avoid.</documentation>
</annotation>
</element>
<element ref="xls:_Location" minOccurs="0" maxOccurs="unbounded">
<annotation>
<documentation>List of locations to
avoid.</documentation>
</annotation>
</element>
<element ref="xls:AvoidFeature" minOccurs="0" maxOccurs="unbounded"/>
</sequence>
</complexType>
<element name="RouteMapRequest" type="xls:RouteMapRequestType">
<annotation>
<documentation>The request parameters for route maps.</documentation>
</annotation>
</element>
<complexType name="RouteMapRequestType">
<annotation>
<documentation>Defines the request parameters for route maps.</documentation>
</annotation>
<sequence>
<element name="Output" type="xls:RouteMapOutputType" maxOccurs="unbounded"/ >
</sequence>
</complexType>
<complexType name="RouteMapOutputType">
<annotation>
<documentation>Defines the rendered route map output parameters.</documentation>
</annotation>
<sequence>
<element name="BBoxContext" type="gml:EnvelopeType" minOccurs="0">
<annotation>
<documentation>Rectangular area to be displayed in the
rendered map. If not specified, defaults to full
route.</documentation>
</annotation>
AP
ˆ
ENDICE B. ESQUEMAS DE SERVIC¸ OS WEB GEOESPACIAIS 105
<!-- type="xls:BoxType" -->
</element>
</sequence>
<attribute name="width" type="nonNegativeInteger">
<annotation>
<documentation>pixel width of the resulting map</documentation>
</annotation>
</attribute>
<attribute name="height" type="nonNegativeInteger">
<annotation>
<documentation>pixel height of the resulting map</documentation>
</annotation>
</attribute>
<attribute name="format" type="string">
<annotation>
<documentation>mime type describing the encoding</documentation>
</annotation>
</attribute>
<attribute name="BGcolor" type="string" use="optional"/>
<attribute name="transparent" type="boolean" use="optional"/>
<attribute name="style" type="xls:RouteMapStyleType" use="optional"/>
</complexType>
<simpleType name="RouteMapStyleType">
<annotation>
<documentation>A route map can be either an overview
or a maneuver</documentation>
</annotation>
<restriction base="string">
<enumeration value="Overview">
<annotation>
<documentation>Used to describe the map showing
the full route</documentation>
</annotation>
</enumeration>
<enumeration value="Maneuver">
<annotation>
<documentation>Used to describe the map showing a
particular maneuver (often the maneuver corresponds
to a single instruction)</documentation>
</annotation>
</enumeration>
</restriction>
</simpleType>
<element name="RouteInstructionsRequest"
type="xls:RouteInstructionsRequestType">
<annotation>
<documentation>The request parameters for turn-by-turn
route instructions and travel advisories formatted for
presentation.</documentation>
</annotation>
</element>
<complexType name="RouteInstructionsRequestType">
<annotation>
<documentation>Defines the request parameters for
turn-by-turn route instructions and travel
AP
ˆ
ENDICE B. ESQUEMAS DE SERVIC¸ OS WEB GEOESPACIAIS 106
advisories formatted for presentation.</documentation>
</annotation>
<attribute name="format" type="string"
use="optional" default="text/plain">
<annotation>
<documentation>The preferred format of the route
instructions, specified as a mime type.
</documentation>
</annotation>
</attribute>
<attribute name="provideGeometry" type="boolean"
use="optional" default="false"/>
<attribute name="provideBoundingBox" type="boolean"
use="optional" default="false"/>
</complexType>
<element name="RouteGeometryRequest"
type="xls:RouteGeometryRequestType">
<annotation>
<documentation>The request parameters for route
geometry.</documentation>
</annotation>
</element>
<complexType name="RouteGeometryRequestType">
<annotation>
<documentation>Defines the request parameters for
route geometry.</documentation>
</annotation>
<sequence>
<element name="BoundingBox"
type="gml:EnvelopeType" minOccurs="0">
<annotation>
<documentation>Rectangular area of route for which
the geometry is requested. If not specified,
defaults to full route.</documentation>
</annotation>
<!-- type="xls:BoxType" -->
</element>
</sequence>
<attribute name="scale" type="positiveInteger"
use="optional" default="1">
<annotation>
<documentation>Maximum scale at which the route will
be displayed. Expressed as a ratio of world unit s to
a device unit. For example 1:50000 would be specified
as 50000.</documentation>
</annotation>
</attribute>
<attribute name="provideStartingPortion"
type="boolean" use="optional" default="false">
<annotation>
<documentation>If true, return the geometry of the
starting portion of the route contained within the
specified bounding area, up to the specified maximum
number of points. If false, return the geometry of
the complete route contained within the specified
AP
ˆ
ENDICE B. ESQUEMAS DE SERVIC¸ OS WEB GEOESPACIAIS 107
area, reducing the accuracy of the geometry as
necessary to not exceed the specified maximum
number of points.</documentation>
</annotation>
</attribute>
<attribute name="maxPoints"
type="positiveInteger" use="optional" default="100">
<annotation>
<documentation>Maximum number of geometric points
to return.</documentation>
</annotation>
</attribute>
</complexType>
<element name="DetermineRouteResponse"
type="xls:DetermineRouteResponseType"
substitutionGroup="xls:_ResponseParameters">
<annotation>
<documentation>Specifies the Determine Route response
parameters.</documentation>
</annotation>
</element>
<complexType name="DetermineRouteResponseType">
<annotation>
<documentation>Defines the Determine Route response
parameters.</documentation>
</annotation>
<complexContent>
<extension base="xls:AbstractResponseParametersType">
<sequence>
<element ref="xls:RouteHandle" minOccurs="0">
<annotation>
<documentation>Reference to the route stored at
the Route Determination Service server.</documentation>
</annotation>
</element>
<element ref="xls:RouteSummary">
<annotation>
<documentation>Response for requested
route summary.</documentation>
</annotation>
</element>
<element ref="xls:RouteGeometry" minOccurs="0">
<annotation>
<documentation>Response for requested
route geometry.</documentation>
</annotation>
</element>
<element ref="xls:RouteInstructionsList" minOccurs="0">
<annotation>
<documentation>Response for requested
route instructions.</documentation>
</annotation>
</element>
<element ref="xls:RouteMap" minOccurs="0" maxOccurs="unbounded">
AP
ˆ
ENDICE B. ESQUEMAS DE SERVIC¸ OS WEB GEOESPACIAIS 108
<annotation>
<documentation>Response list for
requested route maps.</documentation>
</annotation>
</element>
</sequence>
</extension>
</complexContent>
</complexType>
<element name="RouteMap" type="xls:RouteMapType">
<annotation>
<documentation>A route map.</documentation>
</annotation>
</element>
<complexType name="RouteMapType">
<annotation>
<documentation>Defines a route map.</documentation>
</annotation>
<complexContent>
<extension base="xls:MapType">
<attribute name="description" type="string">
<annotation>
<documentation>Allows the route instruction to be
matched with a RouteMapType. For
example "maneuver 1"</documentation>
</annotation>
</attribute>
</extension>
</complexContent>
</complexType>
<element name="AvoidFeature" type="xls:AvoidFeatureType">
<annotation>
<documentation>Type of feature to avoid when
determining the route.</documentation>
</annotation>
</element>
<simpleType name="AvoidFeatureType">
<annotation>
<documentation>Enumeration of types of features
to avoid when determining the route.</documentation>
</annotation>
<restriction base="string">
<enumeration value="Highway">
<annotation>
<documentation>Minimize the use of highways.</documentation>
</annotation>
</enumeration>
<enumeration value="Tollway">
<annotation>
<documentation>Minimize tolls.</documentation>
</annotation>
</enumeration>
</restriction>
</simpleType>
<simpleType name="RoutePreferenceType">
AP
ˆ
ENDICE B. ESQUEMAS DE SERVIC¸ OS WEB GEOESPACIAIS 109
<annotation>
<documentation>Enumeration of preferences
to be taken into consideration when determining
the route.</documentation>
</annotation>
<restriction base="string">
<enumeration value="Fastest">
<annotation>
<documentation>Minimize the travel
time by vehicle.</documentation>
</annotation>
</enumeration>
<enumeration value="Shortest">
<annotation>
<documentation>Minimize the travel
distance by vehicle.</documentation>
</annotation>
</enumeration>
<enumeration value="Pedestrian">
<annotation>
<documentation>Best route by foot.</documentation>
</annotation>
</enumeration>
</restriction>
</simpleType>
<element name="RoutePreference" type="xls:RoutePreferenceType">
<annotation>
<documentation>Preference to be taken into
consideration when determining the route.</documentation>
</annotation>
</element>
</schema>
Livros Grátis
( http://www.livrosgratis.com.br )
Milhares de Livros para Download:
Baixar livros de Administração
Baixar livros de Agronomia
Baixar livros de Arquitetura
Baixar livros de Artes
Baixar livros de Astronomia
Baixar livros de Biologia Geral
Baixar livros de Ciência da Computação
Baixar livros de Ciência da Informação
Baixar livros de Ciência Política
Baixar livros de Ciências da Saúde
Baixar livros de Comunicação
Baixar livros do Conselho Nacional de Educação - CNE
Baixar livros de Defesa civil
Baixar livros de Direito
Baixar livros de Direitos humanos
Baixar livros de Economia
Baixar livros de Economia Doméstica
Baixar livros de Educação
Baixar livros de Educação - Trânsito
Baixar livros de Educação Física
Baixar livros de Engenharia Aeroespacial
Baixar livros de Farmácia
Baixar livros de Filosofia
Baixar livros de Física
Baixar livros de Geociências
Baixar livros de Geografia
Baixar livros de História
Baixar livros de Línguas
Baixar livros de Literatura
Baixar livros de Literatura de Cordel
Baixar livros de Literatura Infantil
Baixar livros de Matemática
Baixar livros de Medicina
Baixar livros de Medicina Veterinária
Baixar livros de Meio Ambiente
Baixar livros de Meteorologia
Baixar Monografias e TCC
Baixar livros Multidisciplinar
Baixar livros de Música
Baixar livros de Psicologia
Baixar livros de Química
Baixar livros de Saúde Coletiva
Baixar livros de Serviço Social
Baixar livros de Sociologia
Baixar livros de Teologia
Baixar livros de Trabalho
Baixar livros de Turismo
