$n

UNIVERSIDADE SALVADOR UNIFACS

PROGRAMA DE PS-GRADUAO EM SISTEMAS E
COMPUTAO
MESTRADO ACADMICO EM SISTEMAS E COMPUTAO

HERBERT MONTEIRO SOUZA

UM SERVIO DE PUBLICAO E DESCOBERTA DE SERVIOS

PARA INFRA-ESTRUTURAS DE MONITORAMENTO DE REDE

Salvador
2007

HERBERT MONTEIRO SOUZA

UM SERVIO DE PUBLICAO E DESCOBERTA DE SERVIOS

PARA INFRA-ESTRUTURAS DE MONITORAMENTO DE REDE

Dissertao apresentada ao Programa de PsGraduao em Sistemas e Computao da

Universidade Salvador UNIFACS, como
requisito parcial para obteno do ttulo de Mestre.
Orientador: Prof. Dr. Jos Augusto Suruagy
Monteiro
Co-orientador: Prof. Leobino Nascimento Sampaio

Salvador
2007

FICHA CATALOGRFICA
(Elaborada pelo Sistema de Bibliotecas da Universidade Salvador - UNIFACS)

Souza, Herbert Monteiro

Um servio de publicao e descoberta de servios para infra-estrutura
de monitoramento de rede / Herbert Monteiro Souza. - 2007.
164 f. : il.
Dissertao (Mestrado) - Universidade Salvador UNIFACS.
Mestrado em Sistemas de Computao, 2007.
Orientadora: Prof. Dr. Jos Augusto Suruagy Monteiro
1 .Servios. Web 2. XML. 3. Redes e Sistemas Distribudos. 4.
Arquitetura de Redes e Computadores. I. Monteiro, Jos Augusto Suruagy,
orient. II. Ttulo.
CDD: 004.048

TERMO DE APROVAO

HERBERT MONTEIRO SOUZA

UM SERVIO DE PUBLICAO E DESCOBERTA DE

SERVIOS PARA INFRA-ESTRUTURAS DE
MONITORAMENTO DE REDES

Dissertao aprovada como requisito parcial para obteno do grau de Mestre em

Sistemas e Computao, Universidade Salvador UNIFACS, pela seguinte banca
examinadora:

Jos Augusto Suruagy Monteiro Orientador ___________________________________

Ph. D. em Cincia da Computao, University of California - UCLA
Universidade Salvador UNIFACS
Joberto Srgio Barbosa Martins______________________________________________
Doutor em Cincia da Computao, Universit Paris VI
Universidade Salvador UNIFACS
Daniela Barreiro Claro _________________________________________________
Doutora em Informtica, Universit Angers, UA, Frana
Universidade Federal da Bahia UFBA

Salvador, 20 de Dezembro de 2007

Dedico este trabalho aos meus pais, Gildsio e

Delenice, a minha namorada Maria Margarete, aos
meus irmos Gilbert e Isabele e aos meus
sobrinhos Diego, Duda e Rayssa

AGRADECIMENTOS

Muitas pessoas contriburam para que eu superasse mais uma etapa importante da
minha carreira. No entanto, eu no poderia deixar de agradecer primeiro ao alicerce da minha
vida. O homem ao qual eu procuro ser a sua semelhana, e que motivado por essa procura eu
continuo a vencer. Obrigado Deus!
Ao meu orientador Prof. Suruagy, que desde a poca da graduao se tornou para
mim um exemplo de profissional, pela confiana depositada para realizar este trabalho e
muitos outros em nosso grupo de pesquisa, pela orientao dada neste trabalho e por me
inserir no meio cientfico da pesquisa.
Ao Prof. Leobino, pela co-orientao valiosa neste trabalho, pelo incentivo que me
fez lembrar as minhas responsabilidades, pela companhia na elaborao dessa dissertao e
pelo apoio realizado na pesquisa.
A minha namorada Margarete, pela compreenso em relao ausncia no perodo
de construo deste trabalho.
A RNP e FAPESB, pelo apoio financeiro, pela infra-estrutura de equipamentos e pela
importncia dada ao nosso grupo de pesquisa.
Ao meu amigo e colega de mestrado Ivo Kenji, que pelo fato de conduzir seus
trabalhos em paralelo me ajudou muito na tomada de decises e elaborao desta dissertao.
Ao meu amigo e colega de pesquisa Rafael Costa, pela ajuda na correo deste
trabalho e pelo companheirismo na pesquisa.
Aos meus colegas de pesquisa e amigos Dimitri, Cayo, Marcelo, Priscilla e Walter,
pelo apoio no laboratrio, pela descontrao nos momentos de tenso e pelo apoio nas
pesquisas realizadas no grupo.
A toda equipe do NUPERC, que manteve toda infra-estrutura em funcionamento para
a realizao deste trabalho. Gostaria de agradecer tambm a Jane e Izabel, pelo
acompanhamento nas questes acadmicas durante o perodo do mestrado.
Finalmente a todos os meus amigo e membros da minha famlia que sempre
estiveram e esto ao meu lado.

Disse-lhe Jesus: Porque me viste, Tom, creste;

bem-aventurados os que no viram e creram.
cf. Joo 20, 29

RESUMO
As infra-estruturas de monitoramento em redes de computadores vm adotando como padro
a arquitetura orientada a servios (SOA) com a inteno de oferecer servios de medio em
mltiplos domnios administrativos. Para usufruir de todas as vantagens do SOA necessrio
tambm utilizar todos os trs componentes fundamentais desta arquitetura, ou seja, o
consumidor, o provedor de servios e tambm a tecnologia de publicao e descoberta para
sanar o problema de localizao e acesso aos servios. Neste sentido existe atualmente uma
forte tendncia para a utilizao de Servios Web como a tecnologia para a implantao dos
servios nas infra-estruturas de monitoramento. E neste aspecto que este trabalho est
focado, ou seja, ele prope um Servio de Publicao e Descoberta voltado para Servios
Web de monitoramento de redes. Antes desta proposta foi necessrio verificar os padres e
tecnologias disponveis que possivelmente podem auxiliar a construo do servio proposto.
Portanto so apresentadas as arquiteturas orientadas a servios, enfatizando a publicao e
descoberta. Tambm mostrado alguns padres que definem servios de publicao e
descoberta como o UDDI e o ebXML, bem como as tecnologia para desenvolvimento e
implantao da SOA. O UDDI um componente crucial para um bom uso de Servios Web,
pois cria uma interface padro que possibilita que as aplicaes localizem rapidamente,
facilmente e dinamicamente os Servios Web na Internet. Este trabalho usa na sua proposta
este padro como base do servio de publicao e descoberta e incorpora nas funcionalidades
do UDDI as caractersticas dos Servios Web e das infra-estruturas de monitoramento. Assim,
caractersticas como: nomenclaturas, tipos, funcionalidades e etc., podem ser usadas como
taxonomias para facilitar a interao com o Servio de Publicao e Descoberta proposto.
Pesquisando todas as caractersticas que envolvem as infra-estruturas de monitoramento em
relao publicao e descoberta de servios e verificando as peculiaridades que envolvem os
Servios Web de monitoramento, foi possvel definir, desenvolver e testar um Servio de
Publicao e Descoberta para Servios Web de medio. Este servio faz parte dos
componentes da infra-estrutura de monitoramento piPEs-BR/GFD e pode ser utilizada por
qualquer aplicao que deseja localizar e descobrir os Servio Web dessa infra-estrutura.
Palavras-chave: Servios Web. XML. Redes e Sistemas Distribudos. Arquitetura de redes e
computadores.

ABSTRACT
The network performance monitoring infrastructures have been adopting the service oriented
architecture (SOA) standard with the intention of offering measurement services in multiple
administrative domains. To enjoy all the benefits of SOA it is also necessary to use the three
components of this architecture, in other words, the service provider, the consumer and the
publish and discovery technology to solve the problem of services search and access. In this
way there is currently a strong trend towards the use of Web Services as a technology for
deployment of services in network monitoring infrastructures. And this is where this work is
focused, in other words, it proposes a Publish and Discovery Service to the network
monitoring Web Services. Before of this proposal it was necessary to verify the standards and
technologies available that could make possible the construction of the proposed service.
Therefore we present the service oriented architectures, emphasizing the publication and
discovery. It is also shown some standards that define services, publishing and discovery as
UDDI and ebXML, and the technologies for development and deployment of SOA. The
UDDI is a key component for a good use of Web services, because it creates standard
interfaces that enables the applications quickly, easily and dynamically locate Web Services
on the Internet. This work uses in its proposal this standard as the basis of the service
publication and discovery and incorporates the UDDI features in the network monitoring Web
services characteristics and the monitoring infrastructure characteristics. Thus, characteristics
such as: classifications, types, features and so on, can be used as taxonomy to facilitate
interaction with the Discovery and Publication Service proposed. Researching of all the
features that involve the monitoring infrastructure in relation to the publication and discovery
of services and verifying the peculiarities that involving the Web Services Web, it was
possible to define, develop and test a service for Publishing and Discovery of network
monitoring Web Services. This service is part of the of the piPEs-BR/GFD infrastructure and
can be used by any application that want discover or publish the piPEs-BR/GFD Web
Services.
Keywords: Web Service. XML. Network Computer and Distributed Systems. Computer
network architecture.

LISTA DE FIGURAS

Figura 1.1 - Arquitetura do piPEs-BR ...................................................................................... 18

Figura 2.1 - Arquitetura Orientada a Servios .......................................................................... 28
Figura 2.2 - Funcionamento do ebXML ................................................................................... 35
Figura 2.3 - Componentes do UDDI ........................................................................................ 37
Figura 3.1 - Arquitetura do GFD .............................................................................................. 48
Figura 3.2 - Cenrio de medies com a infra-estrutura pingER ............................................. 53
Figura 3.3 - de visualizao da MonALISA ............................................................................. 54
Figura 3.4 - Interao entre os diversos componentes do MonALISA .................................... 55
Figura 3.5 - Componentes do prottipo perfSONAR 1.0 ......................................................... 57
Figura 3.6 - Estrutura da mensagem NMWG ........................................................................... 58
Figura 3.7 - Arquitetura do piPEs-BR/GFD ............................................................................. 61
Figura 4.1 - Classificao dos servios pelo tipo ..................................................................... 69
Figura 4.2 - Caractersticas de rede usadas para descrever o comportamento dos dispositivos
de redes ..................................................................................................................................... 71
Figura 4.3 - Modelo de dados ................................................................................................... 75
Figura 4.4 - Exemplo de relacionamento de taxonomias ......................................................... 77
Figura 4.5 - Exemplo das taxonomias criadas .......................................................................... 77
Figura 4.6 - Estrutura macro do Servio de Publicao e Descoberta proposto ...................... 82
Figura 5.1 - Arquitetura do Servio de Publicao e Descoberta ............................................. 87
Figura 5.2 - Diagrama de componentes do padro perfSONAR .............................................. 88
Figura 5.3 - de seqncia do Servio de Publicao e Descoberta........................................... 92
Figura 5.4 - Mapeamento da mensagem NMWG nos componentes do UDDI ........................ 93
Figura 5.5 - Diagrama de classe bsico para a biblioteca de acesso ao UDDI ......................... 95
Figura 5.6 - Arquitetura da biblioteca de acesso ao UDDI ...................................................... 96
Figura 5.7 - Cenrio de testes n 1 ........................................................................................... 97
Figura 5.8 - Cdigo usado na aplicao de testes do cenrio n 1 ........................................... 98
Figura 5.9 - Cenrio de testes n 2 ............................................................................................ 99
Figura 5.10 - Comparao de desempenho entre o LS-UDDI e o LS-XML .......................... 101
Figura 9.1 - Tela de acesso ao Servio de Publicao e Descoberta ...................................... 116
Figura 9.2 - Tela de configurao ........................................................................................... 117
Figura 9.3 - Tela do UDDI Browser ....................................................................................... 118

LISTA DE TABELAS

Tabela 10.1 - Resultado dos testes realizados com o LS-UDDI.

Tabela 10.2 - Resultado dos testes realizados com o LS-XML.

119
119

LISTA DE QUADROS

Quadro 2.1 - Exemplo de conjunto de caractersticas de um servio

39
Quadro 4.1 - Informaes de tipos de servios do piPEs-BR/GFD
68
Quadro 4.2 - Nomenclatura padro de vrias combinaes de caractersticas
70
Quadro 4.3 - Componentes do UDDI usados no servio de publicao e descoberta do piPEsBR/GFD
74
Quadro 5.1 - Nveis de Log do sistema
90

SUMRIO

1 INTRODUO

16

1.1 CONTEXTO

16

1.2 JUSTIFICATIVAS

23

1.3 PROBLEMA E OBJETIVO

24

1.4 APRESENTAO

25

2 ARQUITETURA ORIENTADA A SERVIOS SOA

27

2.1 INTRODUO

27

2.2 SOA: PUBLICANDO E DESCOBRINDO SERVIOS

29

2.3 SERVIOS WEB

30

2.3.1 Web Service Definition Language WSDL

32

2.4 PADRES PARA PUBLICAO E DESCOBERTA DE SERVIOS

32

2.4.1 ebXML - Comrcio Eletrnico usando XML

33

2.4.2 Universal Description Discovery and Integration UDDI

35

2.4.2.1 Componentes do UDDI

37

2.4.2.2 Categorizao de servios

39

2.4.2.3 UDDI verso trs

41

2.5 TECNOLOGIAS PARA DESENVOLVIMENTO E IMPLANTAO DE SOA

42

2.5.1 Apache Axis

42

2.5.2 JUDDI

43

2.5.3 UDDI4J

44

2.5.4 Web Sphere

44

2.5.5 Apache Tomcat

45

2.6 CONSIDERAES

45

3 INFRA-ESTRUTURAS DE MONITORAMENTO

47

3.1 GENERAL FRAMEWORK DESIGN (GFD)

47

3.2 INFRA-ESTRUTURAS DE MONITORAMENTO

51

3.2.1 PingER

51

3.2.2 MonALISA

53

3.2.3 perfSONAR

55

3.2.4 piPEs-BR/GFD

59

3.2.4.1 Descrio dos mdulos

61

3.3 CONSIDERAES

62

4 PUBLICAO E DESCOBERTA DE SERVIOS DE MONITORAMENTO

66

4.1 INTRODUO

66

4.2 CARACTERSTICAS DOS SERVIOS DE MONITORAMENTO

67

4.2.1 Classificao por tipo de servio

68

4.2.2 Usando a hierarquia das caractersticas de medies em redes

69

4.3 PADRES E TECNOLOGIAS A SEREM UTILIZADOS

72

4.4 MODELO DE DADOS

73

4.5 TAXONOMIAS NOS SERVIOS DE MONITORAMENTO

75

4.6 SERVIO DE PUBLICAO E DESCOBERTA PROPOSTO

78

4.6.1 Requisitos do piPEs-BR/GFD

78

4.6.2 Funcionalidades

80

4.6.3 Projeto do Servio de Publicao e Descoberta

82

4.6.4 Integrao com outras infra-estruturas

83

4.7 CONSIDERAES

83

5 PROTTIPO DESENVOLVIDO

85

5.1 INTRODUO

85

5.2 DESCRIO E DESENVOLVIMENTO DO PROTTIPO

87

5.2.1 Lookup Service UDDI Type - LS-UDDI

88

5.2.2 Biblioteca de acesso ao UDDI

92

5.3 TESTES

97

5.3.1 Cenrio de teste n 1

97

5.3.2 Cenrio de teste n 2

98

5.4 AVALIAO DOS RESULTADOS

100

6 CONSIDERAES FINAIS

104

6.1 CONCLUSO

104

6.2 CONTRIBUIES

106

6.3 TRABALHOS FUTUROS

107

REFERNCIAS

109

APNDICE A - EXEMPLO DE UTILIZAO DO UDDI4J

112

APNDICE B MENSAGEM UTILIZADA NO TESTE DO CENRIO NO 1

114

APNDICE C CLIENTES DE ACESSO AO PROTTIPO DESENVOLVIDO

116

APNDICE D RESULTADOS OBTIDOS NOS TESTES DO CENRIO NO 1

119

16

1 INTRODUO

Este captulo apresenta o contexto em que o trabalho est inserido; as justificativas para a
realizao do trabalho; o problema identificado e os objetivos a serem alcanados.

1.1

CONTEXTO

O uso de mecanismos de monitoramento no auxlio ao gerenciamento de redes de

computadores, bem como no suporte de usurios para executarem suas aplicaes; uma
realidade, pois cada vez mais a demanda por informaes sobre as condies da rede vem
aumentando. Esses mecanismos de averiguao e acompanhamento, inicialmente se
limitavam a ferramentas de medio e ferramentas para anlise dos dados medidos. Ao longo
do tempo, as ferramentas de medies foram bastante difundidas e usadas. Logo, o cenrio de
medies nas redes de computadores se resume ao uso de um conjunto de ferramentas de
medio que visam suprir demandas especficas de usurios, obtendo somente medidas fim-afim. No monitoramento fim-a-fim as informaes coletadas so referentes a um caminho
(conexo) entre dois hosts distintos, sem levar em considerao os dispositivos que compem
o caminho como: enlaces, roteadores, switches e etc.

S que o uso de ferramentas para a coleta de dados fim-a-fim, geralmente no fornece as

informaes necessrias para identificar e solucionar problemas no caminho entre os pontos
fim-a-fim. Logo, os usurios continuam sofrendo com problemas de conectividade e
desempenho que podem ocorrer na sua prpria mquina, na rede local ou nos dispositivos de
rede que fazem parte do caminho fim-a-fim. Contudo, necessrio implementar mecanismos
que possibilitem tambm fornecer informaes sobre pontos intermedirios de interesse que
compem um caminho fim-a-fim.

Assim, a partir desta necessidade de se obter o mximo possvel de informaes ao longo de

um caminho fim-a-fim e fornec-las a um amplo conjunto de aplicaes e usurios, tornou-se
necessria a criao de servios de monitorao. Estes servios fariam uso de diversas
ferramentas e tcnicas de medies existentes em vrios pontos das redes, sendo que todo o

17

processo de medio abstrado pelos usurios. Assim, tanto um usurio com pouco
conhecimento sobre redes de computadores (usurio leigo), como um usurio avanado
(administrador de rede), poderiam usufruir das funcionalidades desses servios de
monitoramento. Logo, esses servios teriam a difcil tarefa de receber solicitaes de dados de
medio, manipular as ferramentas para coletar os dados solicitados, tratar os dados e fornecer
os mesmos da forma desejada ao requisitante, sendo que todo esse processo deve ser realizado
com segurana, dinamicidade e de forma controlada.

Com esta finalidade, apareceram no meio acadmico algumas iniciativas para propor e
desenvolver infra-estruturas de monitoramento que agregassem as funcionalidades citadas.
Essas infra-estruturas so caracterizadas por operar de forma distribuda, pois para reunir o
mximo de informao necessrio abranger o maior nmero possvel de pontos das redes.
No cenrio internacional possvel citar a iniciativa de desempenho fim-a-fim E2Epi-End to
End performance initiative da Internet21, a atividade de pesquisa em Medio e Monitorao
de Desempenho (JRA1) da Gant22 e os estudo realizado pelo Grupo de Trabalho de
Medies em Redes de Computadores (GT-Medies3) da Rede Nacional de Ensino e
Pesquisa (RNP4), que buscam utilizar e desenvolver mecanismos de averiguao e
acompanhamento que auxiliem no diagnstico mais preciso dos problemas, bem como na sua
caracterizao para deteco futuras.

Numa tentativa inicial de disponibilizar uma infra-estrutura desse tipo, a Internet2 em 2003
definiu e iniciou o desenvolvimento do performance initiative Performance Environment
system (piPEs) (BOYD, 2002) que utiliza diversas ferramentas para coletar e disponibilizar
dados de medies. J no cenrio nacional, o GT-Medies, em paralelo, iniciou suas
pesquisas no desenvolvimento de uma infra-estrutura de monitoramento para os seus usurios,
pois o grupo j possua uma grande experincia com as tcnicas, mtricas, ferramentas e
dados de medies. O GT-Medies ao verificar um interesse em comum com a iniciativa do
piPEs e ao verificar tambm que o prottipo do piPEs desenvolvido pela Internet2 no ficaria

Internet2 End-to-End Performance Initiative um grupo de pesquisa da rede acadmica norte americana
(Internet2) que procura solucionar problemas de desempenho nas redes.
2

GN2 - JRA1 - Performance Measurement and Monitoring, projeto iniciado pela rede acadmica europia
(Gant2) para pesquisar sobre medies em redes.
3

Grupo de Trabalho apoiado pela RNP para disponibilizar mecanismo de monitoramento em sua rede.

Rede acadmica brasileira que apia o GT-Medies.

18

pronto dentro do cronograma do GT-Medies, resolveu ento, desenvolver uma verso da

infra-estrutura piPEs, de acordo com as necessidades da RNP e de acordo com a experincia
do grupo com o cenrio de medies. Assim surgiu a verso denominada piPEs-BR
(SAMPAIO e outros, 2006), cuja arquitetura pode ser visualizada na Figura 1.1.

Figura 1.1 - Arquitetura do piPEs-BR

Fonte: Sampaio e outros (2006)

A Figura 1.1 mostra a verso inicial da arquitetura do piPEs-BR onde possvel visualizar cada
um de seus componentes constituintes. No lado esquerdo da figura encontram-se as interfaces
de acesso infra-estrutura e os possveis usurios. Na parte central esto os componentes que
gerenciam a infra-estrutura e mais direita encontram-se os componentes que manipulam as
ferramentas de medio e armazenam dados. Assim, o piPEs-BR disponibiliza para a RNP
uma infra-estrutura que realiza as medies atravs das ferramentas, armazena os dados
medidos e disponibiliza esses dados para os usurios. No piPEs-BR a comunicao entre
componentes feita preferencialmente via Servios Web (do ingls Web Service (ALONSO e
outros, 2004), o que demonstra que o GT-Medies j se preocupava com interoperabilidade
entre tecnologias. Um exemplo que possvel citar a interface com o cliente de visualizao
que disponibilizava Servios Web para que qualquer cliente de visualizao (com qualquer
tecnologia) pudesse interagir com a infra-estrutura.

19

As infra-estruturas piPEs e piPEs-BR alm de fornecer informaes fim-a-fim pretendem

fornecer tambm informaes em pontos estratgicos ao longo desses caminhos fim-a-fim.
Esse tipo de abordagem pode envolver vrios domnios administrativos diferentes, pois a
origem e destino de um caminho fim-a-fim podem estar em domnios diferentes. Assim, essas
duas infra-estruturas so caracterizadas pelo uso de pontos de medio (Measurement Point MP), onde so obtidos os dados de medio, seja atravs da execuo de vrias ferramentas
de medio ou atravs da coleta de dados. Essa abordagem do uso de pontos de medies
ajuda no alcance de mltiplos domnios com as medies, pois os pontos podem estar
situados em domnios diferentes. No entanto, as questes que envolvem medies em
mltiplos domnios vo alm, pois, cada domnio possui suas peculiaridades e restries,
modificando assim o cenrio em que a medio est inserida. Logo, existe uma carncia por
infra-estruturas de monitoramento padronizadas que sejam flexveis e adaptveis aos:
domnios administrativos diferentes, s aplicaes dos usurios finais, bem como s
ferramentas que fazem uso dos dados de medies, tais como ferramentas de execuo de
testes, gerenciamento, visualizao, etc.

O interesse em alcanar mltiplos domnios com as medies e utilizar componentes

distribudos para obter informaes ao longo de um caminho fim-a-fim, provocou uma forte
tendncia para que as infra-estruturas de monitoramento adotassem o conceito de uma
Arquitetura Orientada a Servios (do ingls Service Oriented Architecture - SOA)
(PAPAZOGLOU, 2003), onde as funcionalidades so fornecidas atravs de servios bem
definidos. O uso da arquitetura SOA possibilita a criao de componentes (ou mdulos) que
disponibilizam suas funcionalidades atravs de servios. Esses componentes podem ser
distribudos ao longo das redes, viabilizando assim a coleta de informaes em pontos
especficos de um caminho fim-a-fim.

O uso de uma arquitetura baseada em servios facilita o alcance de mltiplos domnios, pois
componentes de domnios diferentes podem simplesmente interagir atravs de servios
padronizados, independendo da tecnologia utilizada. Existe uma forte tendncia para a
utilizao de Servios Web como a tecnologia para a implantao desses servios nas infraestruturas de monitoramento. Isso com o intuito de reduzir os problemas de interoperabilidade
das aplicaes, fazendo com que cada componente exponha as suas funcionalidades em forma
de Servios Web bem definidos, e conseqentemente utilizando a Web como o principal meio
de comunicao.

20

Os Servios Web geralmente so descritos por meio de informaes tcnicas, em documentos

escritos em XML (eXtensible Markup Language5) que usam uma linguagem especifica
chamada de WSDL (Web Services Description Language) (ROY, 2001). Essas informaes
que so descritas atravs da linguagem WSDL possibilitam adquirir o conhecimento
necessrio para acessar o servio, pois a descrio possui as informaes de acesso ao Servio
Web tais como: endereo de conexo, parmetros de entrada e sada, e etc. O uso do XML
para descrever as informaes do servio e realizar a comunicao entre os Servios Web e
seus usurios, possibilita a padronizao do acesso e a independncia de tecnologias
semelhantes entre a comunicao dos envolvidos.

Com os Servios Web sendo uma promessa para integrao entre as ferramentas de medio e
na interoperabilidade entre componentes das infra-estruturas de mltiplos domnios, surgiram
diversos trabalhos na rea. Como exemplo possvel citar Sampaio e Suruagy (SAMPAIO;
SURUAGY, 2004) que propuseram um modelo de medies por fluxo de trfego orientado a
servios em que foram definidos e implementados servios de manipulao de medidas
relacionadas aos fluxos de aplicaes em redes IP. E ainda, Williamson (WILLIAMSON,
2001) que publicou um estudo relatando a importncia da medio e relatando algumas
questes importantes no cenrio de medies, como o alcance em mltiplos domnios e a
necessidade de padres.

Assim a tendncia das infra-estruturas em seguir as definies para uma Arquitetura

Orientada a Servios pode ser comprovada pelo fato de que a Internet2 e a Gant2 em 2005,
procura de solues inovadoras, iniciaram um trabalho conjunto no sentido de definir um
ambiente comum de medio que pudesse ser implantado nas redes nacionais de ensino e
pesquisa (National Research and Education Networks - NRENs) associadas. Dentro deste
esforo, foi elaborado um documento, chamado de General Framework Design GFD
(BOOTE, 2005), que detalha uma arquitetura orientada a servios (SOA) para uma infraestrutura de medies de desempenho em redes IP. Atualmente, est sendo desenvolvido um
prottipo batizado de PERFormance Service Oriented Network monitoring ARchitecture
(perfSONAR) (HANEMANN, 2005) com a finalidade de testar e validar concretamente, os
servios definidos no GFD e que servir de base para a infra-estrutura a ser implantada nas
NRENs.

Linguagem de marcao que descreve objetos chamados XML.

21

No cenrio nacional, o GT-Medies tambm vislumbrou a necessidade de transformar sua

infra-estrutura de monitoramento em orientada a servios e multidomnio, pois a infraestrutura piPEs-BR j era formada por vrios componentes desenvolvidos e utilizados
separadamente que se comunicavam entre si, necessitando assim de uma padronizao na
comunicao e a transformao das funcionalidades de cada componente em servios para
facilitar a comunicao e o uso dessas funcionalidades. Outro fator que levou ao GTMedies tambm seguir essa tendncia o fato de que, num futuro prximo, as infraestruturas

de domnios

diferentes

pudessem

se comunicar e

compartilhar

suas

funcionalidades. Logo, o GT-Medies decidiu adaptar sua infra-estrutura, o piPEs-BR, para

seguir as definies contidas no documento GFD criando assim uma nova infra-estrutura que
passou a ser chamada de piPES-BR/GFD.

Ao planejar o desenvolvimento do piPEs-BR/GFD, o GT-Medies exps para os grupos de

pesquisadores do perfSONAR as suas intenes. Essa iniciativa do GT-Medies foi bem
recebida, e logo o grupo foi convidado para participar do desenvolvimento do perfSONAR 6.
Como o GT-Medies teve a preocupao em no ser um esforo concorrente, definiu e
desenvolveu componentes que no eram previstos no perfSONAR, agregando assim mais
funcionalidades s duas infra-estruturas.

A arquitetura GFD prov vrios mdulos que formam a infra-estrutura de monitoramento e

disponibilizam suas funcionalidades atravs de servios bem definidos. Dentre esses
componentes existe o Servio de Publicao e Descoberta que ser utilizado como repositrio
de informaes sobre todos os Servios Web da infra-estrutura. O uso de Servios Web
basicamente envolve um provedor de servios, que disponibiliza suas funcionalidades em
forma de servios, e pelo menos um consumidor dos servios prestados, que atravs das
descries disponibilizadas pelo provedor, obtm as informaes tcnicas de como acess-los.
No entanto, a fim de se obter um maior dinamismo nestas solues, necessrio desenvolver
os trs componentes da arquitetura orientada a servios (SOA), ou seja, no somente o
consumidor e provedor de servios como tambm um Servio de Publicao e Descoberta (ou
Service Broker).

Desenvolvimento dos servios de monitoramento especificados no documento GFD.

22

O Servio de Publicao e Descoberta possibilita aos usurios de Servios Web uma busca
por um ou mais servios desejados de acordo com suas necessidades. Essa busca envolve por
parte do Servio de Publicao e Descoberta, o fornecimento das informaes tcnicas
necessrias para a identificao e acesso ao Servio Web desejado. Alm da localizao
(descoberta) o Servio de Publicao e Descoberta possibilita que os Servios Web se
registrem (publiquem), possibilitando assim a descoberta. Geralmente o Servio de
Publicao e Descoberta implantado atravs do Universal Description Discovery and
Integration (UDDI) (CURBERA, 2002) que faz parte de um conjunto de padres para
Servios Web definidos por organizaes internacionais.

UDDI um padro criado pela Organization for the Advancement of Structured Information
Standards (OASIS7), que utiliza outros padres como XML e HTTP suportados pelo World
Wide Web Consortium's (W3C8) e pelo Internet Engineering Task Force (IETF9). O UDDI
formado por normas que definem um Servio de Publicao e Descoberta de Servios Web.
Esse padro tambm fornece definies para Application Programming Interfaces (APIs) que
podem ser utilizadas por diversos sistemas para interagir com o servio e acessar as
funcionalidades do registro UDDI. De forma resumida, UDDI um conjunto de tecnologias e
funcionalidades para armazenar e prover informaes (principalmente de acesso) sobre
Servios Web, seguindo uma especificao em comum. Na grande maioria dos estudos
disponveis, ao se falar em publicao e descoberta usa-se o UDDI como padro. Assim, o
fato da tecnologia ser bastante difundida, possuir uma grande aceitao, existir trabalhos
acadmicos utilizando a mesma e prometendo realizar a publicao e descoberta de qualquer
tipo de Servio Web, foram alguns dos fatores que contriburam para a escolha dessa
tecnologia para ser usada neste trabalho.

Mas s esses fatores no justificam o uso da publicao e descoberta de Servios Web nas
infra-estruturas de monitoramento, tampouco o uso do UDDI como padro para esse tipo de
servio. Portanto, preciso pesquisar e verificar os benefcios da publicao e descoberta e,
conseqentemente, do UDDI no escopo das infra-estruturas de medio. Logo, na prxima
seo sero apresentadas algumas justificativas para este fim.
7

Organizao internacional sem fins lucrativos de padronizao de servios.

Consrcio que desenvolve padres usados na criao e interpretao de contedos para a Web.

Comunidade internacional de projetistas, fabricantes, fornecedores, operadores e pesquisadores de redes de

computadores, interessados com a evoluo da arquitetura da Internet e o seu funcionamento perfeito.

23

1.2

JUSTIFICATIVAS

A tendncia das infra-estruturas de monitoramento de operar em redes de padres abertos o

que implica na relao entre domnios diferentes (multidomnio). Devido a isto, essas infraestruturas esto seguindo as definies de uma arquitetura orientada a servios (SOA) e
adotando o uso de Servios Web para abstrair detalhes tcnicos, que dificultam ou impedem a
comunicao entre ferramentas, tcnicas de medies e clientes de visualizao. Como a
arquitetura SOA possui um Servio de Publicao e Descoberta (Service Broker) como um de
seus componentes, fica evidente que para um bom funcionamento das infra-estruturas de
monitoramento necessrio propor esse componente para realizar a localizao dos Servios
Web. Um servio desse tipo torna visvel aos usurios, os Servios Web das infra-estruturas
de monitoramento, possibilitando assim dinamizar o acesso aos Servios Web e localizar um
servio desejado.

Assim, a experincia do GT-Medies com o uso de seu primeiro prottipo de infra-estrutura

de medies o piPEs-BR, o qual j disponibilizava alguns Servios Web, mostrou que para
facilitar o acesso dos clientes aos Servios Web seria necessrio criar um mecanismo que
dinamizasse esse acesso. Pois o uso de Servios Web sem o auxilio da Publicao e
Descoberta implica na definio esttica das formas de acesso aos Servios Web, ou seja, em
arquivos de configuraes ou no cdigo fonte da aplicao usuria (SAMPAIO e outros,
2006). Assim, ao usar as informaes de acesso aos Servios Web de forma esttica, pode
ocorrer que as informaes que esto sendo utilizadas no sejam compatveis, pois esses tipos
de informao mudam constantemente. Por exemplo, ao disponibilizar uma nova verso de
um Servio Web, as informaes de acesso como: parmetros, nome do servio ou endereo
de acesso geralmente so modificadas. Logo, essa abordagem implica em que toda vez que as
informaes de acesso forem alteradas, o cliente fica impossibilitado de acessar o Servio
Web, sendo que para voltar a acessar o Servio Web, ser preciso descobrir as novas
informaes e alterar informaes desatualizadas.

Por outro lado, a partir do uso da

publicao e descoberta as informaes so buscadas em um componente independente,

possibilitando assim que essas informaes possam ser facilmente atualizadas.

Outra justificativa para a realizao desse trabalho que geralmente antes de usar um Servio
Web, os usurios normalmente desejam saber algumas informaes tais como: se esse servio

24

existe, se o servio atende s suas exigncias, onde esse servio est localizado e os requisitos
para usar esse servio. Ainda assim possvel que exista mais de um Servio Web que atenda
as exigncias do usurio ou atenda parcialmente essas exigncias. Para fornecer essas
informaes, realizar a localizao, ajudar na escolha e uso do Servio Web necessrio usar
uma tecnologia que considere todas essas informaes e que de certa forma classifique esses
Servios Web. Neste contexto, o servio de Publicao e Descoberta tem a finalidade de
fornecer as informaes desejadas pelos usurios antes que este escolha e use determinado
Servio Web.

O padro UDDI possibilita a publicao e descoberta de qualquer tipo de Servio Web,

abrangendo questes tais como a troca de mensagens, definio de funcionalidades,
armazenamento de informaes e a interao com outros componentes. Ou seja, ele
disponibiliza um Servio de publicao e Descoberta, confivel, padronizado, estvel que
tambm pode ser utilizado para fornecer informaes dos Servios Web de monitoramento da
infra-estrutura piPEs-BR/GFD (MONTEIRO e outros, 2007).

Na prxima seo ser abordado o problema a ser atacado neste trabalho, bem como o
principal objetivo deste estudo.

1.3

PROBLEMA E OBJETIVO

O principal problema atacado neste trabalho como utilizar o conceito de Publicao e

Descoberta de Servios da arquitetura SOA e o padro UDDI no escopo das infra-estruturas
de monitoramento de redes de computadores. Atualmente o uso das normas UDDI se
restringe ao cenrio do comrcio eletrnico, ocasionando uma falta de material na literatura
que envolva a publicao e descoberta em outros escopos. Na literatura, ao se falar em
publicao e descoberta, geralmente o UDDI citado como o padro para Servios Web que
prov essas funcionalidades. Outro ponto importante que, para usar a publicao e
descoberta nas infra-estruturas de monitoramento, necessrio considerar as caractersticas
dos Servios Web utilizados e os requisitos dos clientes dos mesmos.
Portanto, o objetivo principal deste trabalho propor e desenvolver um Servio de
Publicao e Descoberta para a infra-estrutura de monitoramento piPEs-BR/GFD. Para este

25

fim ser necessrio: desenvolver o servio usando a tecnologia padro de Servios Web
UDDI, levar em considerao as necessidades da infra-estrutura piPEs-BR/GFD, especificar
um modelo de dados sobre o padro UDDI para Servios Web de medies, desenvolver uma
biblioteca de acesso ao servio que facilite o acesso ao mesmo, possibilitar a inter-operao
com outras infra-estruturas e produzir um estudo comparativo entre as implementaes
disponveis e a realizada neste trabalho.

Para conseguir esse objetivo foi elaborada uma estrutura de tpicos neste documento que tem
o intuito de facilitar o entendimento deste trabalho. Logo, essa estrutura pretende abordar a
Arquitetura Orientada a Servios, a qual o Servio de Publicao e Descoberta est inserido,
mostrar as infra-estruturas de monitoramento levando em considerao a Publicao e
Descoberta de Servio Web, descrever as tecnologias disponveis, apresentar a proposta de
um Servio de Publicao e Descoberta para Servio Web de medies, relatar o
desenvolvimento do servio proposto e observar os resultados obtidos com a pesquisa.
Portanto, na prxima seo ser apresentada essa estrutura, bem como o que se pretende com
cada captulo.

1.4

APRESENTAO

Este trabalho est organizado em seis captulos, este o primeiro deles e contm o contedo
introdutrio para ambientar e informar ao leitor qual a proposta do trabalho.

No segundo captulo sero abordados os aspectos que envolvem a Arquitetura Orientada a

Servios (SOA), pois, a Publicao e Descoberta de Servios Web faz parte do contexto desse
tipo de arquitetura. Assim, o segundo captulo explicar o que SOA e abordar algumas
tecnologias e padres que implementam e do suporte a este tipo de arquitetura. importante
frisar que neste captulo que ser apresentado um dos assuntos principais desse trabalho que
o padro UDDI.
Segue-se o terceiro captulo, onde sero abordadas as caractersticas que envolvem as infraestruturas de monitoramento, enfatizando como as mais importantes infra-estruturas utilizam,
no seu escopo, um servio de Publicao e Descoberta de Servios Web.

26

O quarto captulo apresenta a proposta para a soluo do problema abordado neste trabalho
que a definio de um Servio de Publicao e Descoberta de Servios Web de
monitoramento. Nesse capitulo sero apresentadas dentre outras, as caractersticas, a
estrutura, e as funcionalidades do servio.

J no captulo cinco ser apresentado o prottipo desenvolvido do servio proposto neste

trabalho, que tem como finalidade validar o servio proposto e possibilitar a publicao e
descoberta dos Servios Web da infra-estrutura de monitoramento piPEs-BR/GFD.

Finalmente, o captulo seis aborda as questes conclusivas tiradas da pesquisa reportada nesta
dissertao, bem como so identificados e propostos trabalhos futuros utilizando o servio
proposto.

27

2 ARQUITETURA ORIENTADA A SERVIOS SOA

Este captulo aborda a Arquitetura Orientada a Servios (Service Oriented Architecture SOA), onde a Publicao e Descoberta est inserida. O intuito deste captulo abordar as
tecnologias e padres que esto envolvidos com SOA.

2.1

INTRODUO

O uso das definies contidas na arquitetura SOA para transformar funcionalidades em

servios, atualmente uma realidade. H algum tempo atrs se iniciavam na literatura
algumas vertentes tentando dar mais importncia ao uso das funcionalidades dos softwares
(TUNER e outros, 2002) (BENNETT e outros, 2000) e, conseqentemente, assumindo que os
mesmos so provedores de servios. Hoje em dia possvel ver novas vertentes que utilizam
as definies de SOA para criar novos conceitos como a Consumer-Centric Service-Oriented
Architecture - CCSOA (TSAI e outros, 2006) e possvel ver tambm que a arquitetura SOA
est sendo aplicada at em dispositivos mveis (Mobile SOA: Service Orientation on
Lightweight Mobile Devices) (TERGUJEFF e outros, 2007).

A Arquitetura Orientada a Servios um tipo de arquitetura de sistemas distribudos que tem

como base tornar as aplicaes provedoras de servios (PAPAZOGLOU, 2003). Basicamente,
a arquitetura possui trs elementos: um cliente de servios, um provedor de servios e um
repositrio de informaes sobre os mesmos. A funcionalidade de cada elemento est descrita
a seguir. Na Figura 2.1 possvel ver a interao entre esses elementos, onde existe uma
seqncia lgica de acontecimentos.

28

Figura 2.1 - Arquitetura Orientada a Servios

Nota: Elaborao do autor (2007).

As funcionalidades dos trs principais elementos da SOA so:

a) cliente - So os usurios do servio disponibilizado. Podem ser quaisquer

aplicaes, at mesmo uma aplicao que disponibiliza outros servios. Envia
requisies ao servio iniciando o ciclo de comunicao, esperando como
resposta o resultado do que foi solicitado;
b) provedor de servios - o fornecedor de servios que pode conter um ou
mais servios que so disponibilizados para os clientes. Por sua vez recebe as
solicitaes, interpreta e responde ao solicitante;
c) publicao e descoberta (Service Broker) - O Service Broker armazena
informaes sobre os servios, possibilitando assim para os clientes conhecer o
servio antes de utiliz-lo. O Service Broker tem um papel fundamental no
funcionamento da arquitetura, pois facilita a descoberta dinmica dos servios
por parte dos clientes.

Um dos requisitos da SOA que os elementos que a compem devem inter-operar, mesmo
que sejam sistemas ou linguagens de programao diferentes (PAPAZOGLOU, 2003). Isso

29

deve ser feito via comunicao com protocolos padro, introduzindo assim a tecnologia de
Servios Web, comumente usada para fazer essa integrao, pois a mesma utiliza os
protocolos da Internet que so independentes de plataforma e linguagens de programao. J
para o Service Broker existe um padro Web chamado UDDI e que bem utilizado. Para
finalizar, abordando o lado do cliente, a tecnologia bastante utilizada o Apache Axis10 que
disponibiliza um conjunto de solues para a construo de Servios Web e clientes de
acesso.

2.2

SOA: PUBLICANDO E DESCOBRINDO SERVIOS

Um dos componentes da SOA que vem sendo bastante desenvolvido e utilizado o Service
Broker, chamado neste trabalho de Servio de Publicao e Descoberta. Esse aumento no foco
do Servio de Publicao e Descoberta se deve aceitao da abordagem de transformar as
funcionalidades dos softwares em servios, pois, assim que o nmero de servios aumentou a
necessidade, por parte dos consumidores, de descobrir o servio ficou mais evidente. Outro
fator que contribuiu bastante para o aumento no interesse para a publicao de servios a
necessidade de dinamizar o acesso aos servios.

Desenvolver uma aplicao que disponibiliza suas funcionalidades atravs de servios sem o
uso da publicao e descoberta possvel e at aceito em alguns casos como: uma aplicao
que possui poucos servios, no existir freqentes mudanas no acesso aos servios e se todos
os servios forem de um mesmo proprietrio, pois nesses trs casos os servios so bem
conhecidos e existe pouca possibilidade de mudana no cenrio. Como essa combinao de
fatores pouco provvel, um Servio de Publicao e Descoberta torna-se indispensvel em
longo prazo. Assim, a tendncia de disponibilizar mais Servios Web crescente, bem como a
mudana nas formas de acesso aos servios e o uso de servios de outras estruturas
inevitvel (ex. mudana de URL (Uniform Resource Locator) de acesso que freqente e o
alcance de domnios diferentes).

10

Implementao do protocolo Simple Object Access Protocol (SOAP) descrito pelo w3c.

30

Atualmente esse cenrio de aplicaes com muitos servios disponibilizados para uma grande
quantidade de usurios espalhados pelas redes to presente, que as principais pesquisas
sobre a publicao e descoberta esto envolvendo a utilizao de mais de um Servio de
Publicao e Descoberta interagindo entre si (ZURAWSKI e outros, 2007). A utilizao de
vrios Servios de Publicao e Descoberta possui o intuito de abranger mais usurios (ou
domnios), aumentar a disponibilidade e melhorar o desempenho. Um exemplo de servio que
possibilita o uso de mltiplos Servios de Publicao e Descoberta o definido no padro
UDDI em sua verso trs.

2.3

SERVIOS WEB

Para melhor definir o que so Servios Web, primeiro se faz necessrio definir servios em
computao. Servio um programa ou componente de software em um dado ambiente que
prov e gerencia acesso a recursos que so essenciais para outras entidades. importante
ressaltar que a noo de recurso nessa definio bastante genrica. O recurso pode ser um
hardware ou um software. J o Servio Web faz parte de uma classe especial de servios onde
a principal caracterstica a interoperabilidade (APTE; MEHTA, 2002).

Os Servios Web funcionam em redes de computadores e so suportados por um framework

especifico. O framework prov meios de descrever e descobrir o servio, interagir com o
servio e numa forma mais sofisticada integrar Servios Web com outros Servios Web.

Uma das caractersticas principais dos Servios Web que as tecnologias relacionadas tm
como base o uso da linguagem XML, que utilizada para a comunicao entre as aplicaes,
descrio e definio de tipos complexos de dados, descrio dos servios e publicao e
descoberta dos mesmos. Essas aplicabilidades do XML geralmente so implantadas pelas
seguintes tecnologias: a linguagem Web Services Description Language (WSDL); o protocolo
Simple Object Access Protocol (SOAP) (BOX e outros, 2000); e o padro UDDI. Essas
tecnologias fazem parte do framework de Servios Web que por sua vez visa possibilitar o
acesso aos mesmos.

31

Contudo, o acesso a um Servio Web pode ser feito de duas maneiras. O primeiro tipo de
acesso via passagem de parmetros, ou seja, o cliente realiza uma requisio a um
determinado servio passando os parmetros de entrada e esperando assim os parmetros de
sada. O segundo tipo de acesso feito via troca de documentos padronizados. Nesse caso o
cliente ir fornecer ao servio um documento padronizado que geralmente contm a
funcionalidade desejada e os parmetros necessrios. Nesse tipo de abordagem possvel que
uma aplicao disponibilize apenas um servio padro, que recebe os documentos padres,
verifica a solicitao e realiza a operao. Um exemplo claro dos dois tipos pode ser descrito
assim:

a) passagem de parmetros - Um usurio deseja obter a mdia de suas notas

escolares. Esse usurio precisa utilizar um servio que realize a soma de suas
notas, esse servio recebe como parmetros as notas. Depois o usurio ter que
usar um servio que realiza a diviso entre o total de pontos com a quantidade,
logo esse servio recebe como parmetros o somatrio das notas e a quantidade
de notas;
b)

troca de documentos - O mesmo usurio que deseja obter a mdia de

suas notas escolares pode utilizar um servio chamado mdia, que recebe um
documento que contm no seu interior a solicitao para a soma de todas as
notas (que tambm esto no documento) e que depois realize a diviso pela
quantidade de notas. importante frisar que nesse caso somente um servio
disponibilizado.

Outro componente importante do Servio Web o ponto de acesso (do ingls Access Point),
como comumente chamado. O ponto de acesso um URI (Uniform Resource Identifier) que
nomeia o endereo onde deve ser realizada a conexo com o servio.

Existe um mecanismo no cenrio de Servios Web que de extrema importncia para a

Publicao e Descoberta. Esse mecanismo o WSDL que descreve as caractersticas tcnicas
do Servio Web. Essa descrio pode ser usada para conhecer previamente o servio, o que
semelhante a uma das funcionalidades do Servio de Publicao e Descoberta que tem a
finalidade de fornecer informaes sobre os Servios Web.

32

2.3.1 Web Service Definition Language WSDL

O WSDL uma linguagem baseada em XML que descreve em documentos, os Servios Web
disponibilizados por uma aplicao. Ou seja, recomendado que ao disponibilizar um Servio
Web, seja disponibilizado tambm um documento WSDL que descreve como os usurios
podem realizar requisies ao servio. Essas descries fornecem a forma de interao e os
requisitos necessrios para a comunicao, o que as deixam transparentes no que diz respeito
plataforma e linguagem de programao para o cliente.

Outro uso bastante conhecido do documento WSDL na criao dinmica de clientes de

acesso ao servio. Dependendo da estrutura e forma de acesso compatvel com o servio
possvel, atravs de um documento WSDL, construir automaticamente uma aplicao que
possa usar o Servio Web normalmente. Isso possvel devido ao fato de que no WSDL so
descritas as informaes de acesso ao servio como: o URI do ponto de acesso, os parmetros
de entrada e sada e etc.

O WSDL importante para publicao e descoberta, pois as informaes contidas no

documento WSDL fazem parte das informaes fornecidas por um Servio de Publicao e
Descoberta aos usurios. Essas informaes so consideradas bsicas para o acesso ao
servio. Alguns padres de Servio de Publicao e Descoberta como o UDDI possuem
elementos que fazem analogia ao documento WSDL e at mesmo usam mecanismos para
armazenar as informaes de um documento WSDL (APTE; MEHTA, 2002). Contudo, o
UDDI e o WSDL tm funes semelhantes quando o assunto fornecer informaes de
acesso ao Servio Web. No entanto, essa semelhana no passa deste ponto, pois o WDSL
no possibilita a localizao dinmica do servio.

2.4

PADRES PARA PUBLICAO E DESCOBERTA DE SERVIOS

A Publicao e Descoberta de Servios conhecida como Service Broker na arquitetura

orientada a servios e, s vezes, comumente chamada por UDDI, pois possvel se
confundir entre UDDI, que um padro que utiliza normas para definir um Servio de

33

Publicao e Descoberta, com o prprio Service Broker, que um conceito. Essa confuso se
d pelo fato da especificao UDDI ser considerada a tecnologia padro Web na Publicao e
Descoberta de Servios Web, fazendo com que ao se falar na Publicao e Descoberta de
Servios, automaticamente se fale em UDDI.

Contudo, os Servios de Publicao e Descoberta gerenciam uma base de dados com as

informaes de acesso a Servios Web, independendo se esses servios fazem parte da mesma
aplicao ou de vrias aplicaes em contextos diferentes. Essas informaes so usadas na
identificao e acesso aos Servios Web. Portanto, um Servio de Publicao e Descoberta
armazena informaes do tipo: o URI do ponto de acesso ao servio web, os parmetros de
entrada e os parmetros de sada. Outras informaes podem tambm ser adquiridas no
servio de publicao e descoberta, isso vai depender de quem especifica o servio e com que
finalidade.

Na literatura existem alguns padres que so usados para a publicao e descoberta de

servios. Alguns desses padres tm um foco especfico, por exemplo, o ebXML
(HOFREITER e outros, 2002) que usado especificamente para a publicao e descoberta de
servios de comrcio eletrnico (do ingls eBusiness). Existem tambm outras definies que
foram elaboradas para realizar a publicao e descoberta de forma genrica, ou seja, para
qualquer tipo de Servio Web. A seguir sero descritas duas especificaes existentes.

2.4.1 ebXML - Comrcio Eletrnico usando XML

Geralmente no cenrio do comrcio eletrnico, as aplicaes disponibilizam suas

funcionalidades atravs de servios possibilitando a realizao de transaes comerciais. Essa
abordagem facilita o processo, pois nesse tipo de transao existe uma interao entre
diversos elementos, por exemplo, em uma simples venda por carto, onde preciso a
autorizao da operadora, verificao da disponibilidade do produto dentre outros. Assim,
dentro do escopo de comrcio eletrnico h um grande interesse em disponibilizar servios
para que o cliente e outras empresas possam realizar transaes atravs de servios
padronizados e bem definidos.

34

O Electronic Business using eXtensible Markup Language (ebXML) um padro para

Servios Web definido pela OASIS, que fornece um conjunto de especificaes que permitem
s empresas administrar seus negcios na Internet. Dentre essas especificaes existe uma que
define como publicar e descobrir Servios Web automaticamente para serem utilizados nos
processos de negcios. Outra funcionalidade que faz parte deste conjunto de especificaes
a padronizao de mensagens e tipos de dados atravs de um Schema XML prprio
(HOFREITER e outros, 2002). Isso auxilia na troca mensagens entre o registro ebXML e os
usurio do mesmo que podem ser os Servios Web de comrcio eletrnico ou os usurios
comuns. Uma caracterstica que tambm pode ser encontrada nas especificaes do ebXML
que todo o processo envolvendo o registro ebXML deve ser realizado de forma segura e
confivel. Atualmente a especificao do ebXML se encontra na verso trs.

O padro ebXML tambm define um protocolo para a troca de mensagens XML baseadas em
servios de comrcio eletrnico. Essas mensagens contm informaes empresariais
necessrias para acessar um servio de comrcio eletrnico disponibilizado por uma empresa.
Basicamente o protocolo definido no ebXML um conjunto de camadas estendidas do SOAP.
No entanto, essas camadas tentam prover duas funcionalidades no suportadas pelo SOAP
que a confiabilidade e a segurana (HOFREITER e outros, 2002).

Na Figura 2.2 possvel ver a utilizao do ebXML, onde esto enumerados os passos de um
exemplo clssico. Na figura temos a Empresa A que deseja desenvolver um servio e ao
mesmo tempo utilizar um servio de ebXML existente. No passo 1 a Empresa A para
desenvolver um servio precisa saber os detalhes necessrios para desenvolver um servio de
acordo com as especificaes de negcio do registro ebXML. Logo, a Empresa requisita esses
detalhes. Com os detalhes em mos, a Empresa A desenvolve o servio no passo 2 e
consecutivamente registra as informaes sobre esse servio no passo 3. Neste ponto, o
servio disponibilizado pela Empresa A se torna visvel para todos os usurios do mesmo
registro ebXML. Continuando no exemplo da Figura 2.2, existe agora uma Empresa B que, por
exemplo, ao acessar o registro ebXML verificou que existe um servio fornecido pela
Empresa A que satisfaz suas necessidades. Logo, no passo 4, a Empresa B consulta sobre a
Empresa A e recupera as informaes sobre o servio oferecido pela Empresa A. Depois de
manipular e verificar as informaes sobre o servio oferecido, a Empresa B concorda com o
esquema de negcios da Empresa A atravs de identificaes e validaes no passo 5. E para

35

finalizar, de posse das informaes adquiridas no registro ebXML, a Empresa B pode ento
usar o servio da Empresa A, normalmente, no passo 6.

Figura 2.2 - Funcionamento do ebXML

Nota: Elaborao do autor (2007).

2.4.2 Universal Description Discovery and Integration UDDI

O UDDI um componente chave para um bom uso de Servios Web, pois cria uma interface
padro que possibilita que as aplicaes localizem rapidamente, facilmente e dinamicamente
os Servios Web na Internet (APTE; MEHTA, 2002). O UDDI pode ser utilizado em
diferentes contextos, pois as suas definies procuram no especificar o tipo de servio a ser
publicado.

O UDDI uma iniciativa que foi implantada como projeto de pesquisa por vrias companhias
interessadas em discutir questes relacionadas integrao entre sistemas de computao.
Logo, essa iniciativa definiu um padro Web que prov uma especificao para um Servio de
Publicao e Descoberta de Servios Web. Esse padro tambm definiu APIs (Application
Programming Interfaces) que so usadas como interfaces de acesso ao UDDI e podem ser

36

utilizadas por diversos sistemas para interagir com o UDDI e acessar suas funcionalidades.
Essa interao ocorre da seguinte forma: os Servios Web acessam o UDDI para registrar
suas informaes de acesso e identificao; j os usurios desses servios acessam o UDDI
para localizar essas informaes.

Numa viso de alto nvel, as informaes sobre os Servios Web que so registradas no UDDI
so classificadas em trs categorias principais:

a) pginas brancas (White Pages) - So as informaes gerais sobre o

proprietrio dos servios, como por exemplo, nome do proprietrio, descrio
desse proprietrio, informaes de contato, endereo e outros. importante
lembra que o proprietrio pode ser uma empresa, uma pessoa, uma instituio
de ensino e etc;
b)

pginas amarelas (Yellow Pages) - Aqui so armazenadas as

informaes genricas dos servios, por exemplo, nome, descrio, tipo e etc.
Aqui possvel usar a classificao do servio atravs de taxonomias;

c) pginas verdes (Green Pages) - Esta categoria armazena as informaes

tcnicas sobre o servio, como por exemplo, a URI de acesso ao servio, o tipo
de protocolo, os parmetros necessrios e etc.

A primeira verso do UDDI, a 1.0, foi desenvolvida pela Microsoft, IBM e Ariba, e foi
anunciada em setembro de 2000. Desde o anncio inicial a tecnologia cresceu e, em maio de
2001, foi lanada a primeira implementao, o UDDI Registry. Em junho de 2001 foi
anunciada a verso 2.0 das normas UDDI, incluindo novas caractersticas e funcionalidades.
Em agosto de 2003 foi lanada a verso 3 das especificaes UDDI, a qual se encontra em
utilizao atualmente. Algumas funcionalidades da verso 2 e 3 sero detalhadas no decorrer
deste trabalho.

A especificao do padro UDDI consiste em um Schema XML que define uma estrutura de
dados que armazena as informaes sobre os Servios Web. Sendo que o UDDI tambm
descreve uma especificao para o desenvolvimento de uma API de acesso. Juntos, o Schema
e a API formam um modelo bsico para a publicao de informao sobre um grande nmero
de Servios Web.

37

Contudo, as informaes contidas no UDDI que esto distribudas nas pginas branca, verde e
amarela, so implementadas, na prtica, em formato XML atravs de quatros componentes
bsicos: o businessEntity, businessService, bindingTemplate e o tModel. Esses componentes
sero descritos na prxima subseo.

2.4.2.1 Componentes do UDDI

O UDDI possui um conjunto de componentes onde as informaes sobre os Servios Web so

distribudas. Alguns autores chamam esse conjunto de componentes de estrutura de dados.
Realmente esse conjunto de componentes remete a uma estrutura de dados de uma base de
dados relacional, mas geralmente esses componentes so demonstrados visualmente sem levar
em considerao as caractersticas de uma estrutura de dados como os relacionamentos,
ndices, atributos e outros. Na Figura 2.3 possvel ver os componentes principais e seus
relacionamentos.

Figura 2.3 - Componentes do UDDI

Nota: Elaborao do autor (2007).

38

a) business entity - Componente que armazena as informaes sobre o

proprietrio de um conjunto de servios. Um registro UDDI pode conter mais
de um Business Entity. Logo, ao consultar sobre um determinado servio web
necessrio informar tambm a identificao do Business Entity. Por exemplo,
se em um registro UDDI existirem dois Business Entities (UNIFACS e
UFBA), ao consultar um servio nesse registro necessrio informar na
solicitao, que o servio procurado pertence entidade UNIFACS ou UFBA.
Um Business Entity armazena informaes como: nome, descrio, contato,
endereo e etc.;
b) business service - O Business Service o servio propriamente dito. Nele so
armazenadas informaes genricas do servio tais como nome e descrio;
c) binding template - O Binding Template armazena informaes tcnicas do
servio como: ponto de acesso, URI do WSDL, tipo da URL do ponto de
acesso (ex. HTTP ou FTP), parmetros e etc. Essas informaes so
consideradas as informaes de acesso, pois para acessar um servio
imprescindvel saber a URI do ponto de acesso do servio, os parmetros de
entrada e os parmetros de sada, caso houver;
d) tModel - Fornecer informaes sobre os Servios Web tambm s uma das
funcionalidades do UDDI. Outra funcionalidade a possibilidade de armazenar
informaes que sejam significativamente especficas e diversificadas, para
serem bastante teis durante a busca. O tModel o componente do UDDI que
possui diversas funcionalidades, sendo que a principal identificar o servio
atravs de referncias e armazenamento de informaes especficas, fazendo
com que o mesmo seja nico ou faa parte de um grupo. O tModel utilizado
como um tipo de marcador que identifica os servios atravs de uma
caracterstica do mesmo. Por exemplo, um servio de vendas pode ser
categorizado por diversas caractersticas tais como: venda a varejo ou atacado,
venda a vista ou a prazo, venda de roupas ou de comidas e etc. Com essa
variedade de caractersticas possvel com o tModel criar uma estrutura de
categorizao ou taxonomia onde uma ou mais dessas caractersticas
identificam o servio;
e) category bag - Usado para armazenar um conjunto de caractersticas que
categorizam um servio. composto por um par de informaes que so o
nome da caracterstica e o valor. Como exemplo, possvel citar um servio de

39

lavagem de carros, que possui as seguintes caractersticas: lava os carros com

um jato de gua, realiza polimento com cera cristal, limpa o interior do carro
com aspirador e etc. Nesse caso esse conjunto de caractersticas seria
armazenado no Category Bag do servio de lavagens de carro, como pode ser
visto na Quadro 2.1.

Caractersticas
Lavagem
Polimento
Limpeza de interior

Category Bag
Valor
Jato de gua
Cera cristal
Aspirador

Quadro 2.1 - Exemplo de conjunto de caractersticas de um servio

Nota: elaborao do autor (2007).

Contudo, possvel dizer que esses componentes so divididos em dois grupos: um que
armazena as informaes genricas dos servios e outro que armazena as informaes
especficas dos Servios Web. Assim, num registro UDDI podem existir vrios servios que
so semelhantes em relao s informaes genricas, sendo que com o auxlio dos
componentes tModel e Category Bag existe a possibilidade de diferenciar ou at relacionar
esses servios. Em nosso exemplo possvel que no registro UDDI existam vrios servios
que realizem a lavagem de carros, mas dentre esses servios tambm possvel pesquisar, por
um que seja identificado pelo fato de possuir em seu Category Bag referncias a tModels e
valores que o diferenciam dentre os outros. Como, o fato de realizar polimento com cera
cristal, lavagem com jato de gua ou utilizar o aspirador.

2.4.2.2 Categorizao de servios

As informaes presentes nos componentes tModel e Category Bag do UDDI do suporte

para o uso das taxonomias. Taxonomia a cincia que estuda a classificao ou categorizao
de uma determinada coisa (XIMENES, 1998). No UDDI a taxonomia classifica Servios Web
de acordo com determinadas caractersticas especficas do servio, possibilitando que a
pesquisa do mesmo seja baseada em uma determinada categoria (ex. de produto, ou de
localizao geogrfica). Essas taxonomias podem ser normatizadas, que so definidas atravs
de normas internacionais ou privadas que so criadas para suprir uma necessidade prpria,

40

permitindo que sejam desenvolvidas taxonomias para quaisquer tipos de categorizao

(PINTO e outros, 2003).

Assim, qualquer estrutura no uso dos tModels para categorizar um servio pode ser
considerada uma taxonomia. Por exemplo, ao categorizar um servio pelo seu tipo e
subtipo, possvel considerar essa categorizao uma taxonomia de tipo, onde um servio
possui um tipo genrico e um subtipo que especifica o servio. Portanto, a categorizao
citada uma taxonomia privada que foi criada pelo operador do registro UDDI para
categorizar um servio de acordo com o seu tipo. Essa taxonomia considerada hierrquica,
onde o tipo o ancestral do subtipo. Assim, um tModel considerado filho faz referncia
ao seu pai, possibilitando saber que existe uma ou mais caractersticas especficas que
podem ajudar na escolha do servio. possvel citar como exemplo, o Servio de
Armazenamento definido no GFD (Measurement Archive - MA), que pode ser caracterizado
pelo tModel tipo com valor MA, que por sua vez referenciado pelo seu filho um tModel
subtipo. Como um MA um servio de armazenamento, podemos considerar o seu
subtipo o formato em que os dados so armazenados, por exemplo, RRD ou XML.

Contudo, na especificao do UDDI existem algumas taxonomias normatizadas que so

conhecidas no cenrio de classificao de indstrias ou produtos. Para demonstrar um tipo de
taxonomia normatizada que o padro UDDI utiliza possvel citar a taxonomia ISO 3166
(tambm conhecida como geo taxonomia) para a categorizao geogrfica de servios. Essa
taxonomia possibilita associar servios a localizaes cuja granularidade varia entre pases e
dependentes (que podem ser estados). Por exemplo, o nmero de identificao do Brasil na
taxonomia ISO 3166 076. Ao se pretender usar a taxonomia ISO 3166 para os servio de um
registro UDDI preciso criar um tModel para a norma ISO e armazenar o valor
correspondente norma ISO no servio. Portanto, ao categorizar um servio situado no
Brasil, necessrio armazenar o valor referente ao Brasil na norma ISO 3166 que o nmero
076 e fazer com que o servio aponte para o tModel referente norma ISO. Ao tentar
localizar um servio pela norma ISSO 3166 o usurio dever buscar todos os servios que
apontam para o tModel da norma e que possuem o valor desejado.

41

2.4.2.3 UDDI verso trs

Todas as caractersticas citadas anteriormente esto inseridas na verso dois do padro UDDI.
Mas, preciso tambm mencionar neste trabalho as funcionalidades existentes na verso trs
do padro UDDI, pois essa verso ser bastante til para trabalhos futuros que podem ser
realizados com os resultados desta dissertao.

A verso trs do padro UDDI possui como principal caracterstica o incentivo ao uso do
UDDI bem como ao dos Servios Web. Pois essa verso traz alguns recursos de segurana e
uso de mltiplos registros. Ou seja, servios de publicao e descoberta interagindo entre si,
trocando informaes e localizando servios situados em outros registros.

Em relao segurana o UDDI verso trs introduz assinaturas digitais para fornecer
segurana adicional. Cada servio de publicao e descoberta pode ser assinado digitalmente,
aprimorando a integridade e a confiana dos dados de UDDI. Lembrando que j na verso
dois o UDDI utiliza um mecanismo de autenticao baseado em usurio e senha.

J em relao ao uso de vrios servios de publicao e descoberta interagindo entre si, o

UDDI verso trs implementa funcionalidades que possibilitam a replicao de dados entre as
bases. Assim, dentro de um domnio, possvel utilizar vrios servios do UDDI que
interagem entre si replicando suas informaes. Essa replicao formada por um anel lgico
de servios de publicao e descoberta, onde qualquer membro desse anel, ao verificar que
seus registros foram alterados, replica essa informao ao longo do anel at que todos
possuam a mesma informao.

Outro avano no UDDI verso trs que esse anel citado pode interagir com outros servios.
Por exemplo, um conjunto de servios UDDI da RNP que formam um anel lgico de
replicao capaz de eleger um lder entre eles e fazer com que esse lder tambm replique
suas informaes com outro lder que est implantado na Internet2. Assim, um usurio do
servio de publicao e descoberta da Internet2, poderia descobrir servios publicados nos
servios de publicao e descoberta instalados na RNP. Sendo que essa funcionalidade
tambm possibilita a restrio na replicao dos dados, ou seja, um UDDI pode somente
replicar parte das informaes, ou replicar um conjunto reduzido de Servios Web.

42

2.5

TECNOLOGIAS PARA DESENVOLVIMENTO E IMPLANTAO DE SOA

Existem algumas tecnologias proprietrias ou open source que do suporte para desenvolver e
implantar aplicaes orientadas a servios. Essas tecnologias so importantes para este
trabalho, pois algumas delas sero usadas no prottipo desenvolvido. Essas tecnologias
tambm so importantes pelo fato de serem as mais usadas no meio acadmico, fazendo parte
assim do contexto em que o trabalho se encontra.

2.5.1 Apache Axis

Apache Axis (ALMAER, 2002) um framework para desenvolvimento e implantao de

Servios Web. Dentre as funcionalidades do Apache Axis a principal a implementao do
Simple Object Access Protocol (SOAP) especificado pelo W3C.

Segundo Gudgin (2007, p.6), o SOAP :

SOAP is a lightweight protocol for exchanging structured information in a
decentralized, distributed environment. It is an XML based protocol that consists of
three parts: an envelope that defines a framework for describing what is in a
message and how to process it, a set of encoding rules for expressing instances of
application-defined data types, and a convention for representing remote procedure
calls and responses.

Desenvolvido pela Apache Foundation, o Apache Axis comumente usado no suporte e

desenvolvimento de Servios Web. Usado juntamente com um servidor de aplicativos
disponibiliza interfaces capazes de receber mensagens via protocolo SOAP, que so usadas
como requisies de servios. Essa tecnologia de extrema importncia, pois a grande
maioria dos softwares de cdigo livre relacionados com a arquitetura SOA a usam. Por
exemplo, as infra-estruturas citadas anteriormente o piPEs-BR/GFD e o perfSONAR, ou at
mesmo a implementao do padro UDDI, o JUDDI, que ser descrito na prxima subseo.

O Apache Axis tambm disponibiliza bibliotecas que viabilizam funcionalidades para

desenvolver clientes e realizar requisies aos servios. Ou seja, essa tecnologia disponibiliza
um conjunto de solues para desenvolver, implantar e acessar Servios Web.

43

2.5.2 JUDDI

JUDDI uma implementao de cdigo aberto em JAVA das especificaes contidas no

padro UDDI para Servios Web. Desenvolvido pela Apache Foundation se encontra na
verso 0.9, a qual implementa a verso dois do padro UDDI. Desenvolvida especificamente
para Web, pode ser usada com qualquer servidor de aplicativos que suporte a verso 2.1 ou
anterior do servlet API11. Contudo, o JUDDI um servio de publicao e descoberta que
disponibiliza suas funcionalidades atravs de Servios Web, utiliza mensagens XML para
comunicao e implementa seus Servios Web via tecnologia Apache Axis, citada
anteriormente.

Como o Servio de Publicao e Descoberta tambm conhecido como registro ou base de

informaes de Servios Web, o JUDDI tambm utiliza uma base de dados externa, para
armazenar as informaes dos servios. Portanto, possvel dizer que o JUDDI suporta as
mais conhecidas bases de dados relacionais open source do mercado.

O ponto chave do armazenamento de informaes no JUDDI que, mesmo recebendo as

informaes a serem armazenadas em formato XML, o JUDDI consegue, atravs do Schema
XML definido no UDDI, transformar os elementos das mensagens em objetos JAVA que
facilitam a manipulao e a insero das informaes em uma base de dados relacional.

Essa implementao bem relacionada na literatura, pois se trata de uma soluo gratuita que
estvel e contemplam todas as funcionalidades do UDDI verso 2.0, que podem ser
consideradas as funcionalidades bsicas para um servio de publicao e descoberta. Outra
vantagem do JUDDI o fato de ser open source e possuir uma boa documentao, o que
possibilita modificaes.

11

Protocolos e servidor de componentes independente de plataforma escrito em JAVA. Sun Microsystems, The
Java servlet API Whitepaper.

44

2.5.3 UDDI4J

O UDDI4J12 uma biblioteca JAVA de cdigo aberto que prov acesso ao UDDI.
Desenvolvida pela IBM, uma biblioteca de fcil manuseio que envia requisies a um
registro UDDI solicitando as funcionalidades oferecidas por esse registro.

O UDDI4J utiliza o protocolo SOAP baseado em XML (via tecnologia Apache Axis) para
enviar mensagens e transformar os elementos das mensagens XML em objetos JAVA. Um
usurio que deseja localizar um servio, ou um prprio servio que deseja se registrar no
UDDI pode usar a biblioteca UDDI4J e realizar essas operaes.

Outro exemplo de uso para a biblioteca UDDI4J a possibilidade de se construir uma

interface sobre essa biblioteca de acordo com as caractersticas do servio. Por exemplo, o
desenvolvedor para facilitar o acesso ao UDDI para os usurios pode criar novos objetos
(tipo, descrio, nome e etc.) que abstraem os nomes e caractersticas dos objetos do UDD4J
que so anlogos aos elementos do UDDI. Logo, o usurio no precisa saber detalhes do
UDDI como: bindingTemplates, tModel e etc.

2.5.4 Web Sphere

O Web Sphere (COLGRAVE, 2004) um conjunto de softwares da IBM que oferece: uma
infra-estrutura para desenvolver e disponibilizar aplicaes, a integrao entre essas
aplicaes, a possibilidade de reuso e de estender funcionalidades de outras aplicaes,
gerncia de processos de negcios, automao e integrao para comrcio eletrnico e
solues para dispositivos mveis. Muitas dessas funcionalidades oferecidas so baseadas na
arquitetura SOA ou so usadas para implantar arquiteturas SOA. Um exemplo que o Web
Sphere possui uma implementao das normas UDDI.

O Web Sphere foi desenvolvido para tentar suprir todas as questes que envolvem aplicaes
Web. O Web Sphere possui seu prprios servidores, suas ferramentas para desenvolver
12

Biblioteca JAVA de acesso ao registro UDDI.

45

aplicaes e bibliotecas, ferramentas para desenvolver servios, barramento de servios e

ferramentas que do suporte a arquitetura SOA. O UDDI foi inserido no Web Sphere a partir
da sua verso 6.0 e j essa verso implementa o UDDI na sua verso mais atual. Assim o Web
Sphere se torna uma soluo completa para a implementao, disponibilizao, descoberta e
publicao de Servios Web.

2.5.5 Apache Tomcat

Desenvolvido pela Apache Foundation, o Tomcat um servidor de aplicativos JAVA para

Web. uma implementao de software livre que possui cdigo aberto e basicamente suporta
as tecnologias JavaServer Pages.

Atualmente grande parte das aplicaes que disponibilizam Servios Web utiliza o Tomcat
como Servidor Web para disponibilizar os servios e receber as requisies. Um dos motivos
pra essa escolha sua estabilidade, pois ao longo dos anos o software vem sendo utilizado e
recomendado pelo fato de j ser utilizados em ambientes de produo de forma satisfatria.

importante citar o Tomcat, pois ele ser o servidor que ir disponibilizar o prottipo
desenvolvido neste trabalho bem como a implementao JUDDI.

2.6

CONSIDERAES

Neste captulo foram apresentados alguns padres e tecnologias que esto envolvidos com as
arquiteturas orientadas a servios. Nele foi possvel observar o componente da SOA, o Service
Broker, e a sua importncia para a arquitetura. Foram apresentados tambm alguns padres
que definem o Service Broker e que podem ser usados no escopo deste trabalho. Portanto, este
captulo tambm apresentou o padro usado neste trabalho, o UDDI, bem como as suas
funcionalidades e caractersticas.

46

Para pesquisar sobre as peculiaridades dos Servios Web de monitoramento, preciso

previamente saber as caractersticas dos servios Web de forma genrica. Sendo assim, esse
captulo mostrou o assunto Servios Web, descrevendo suas caractersticas e definies, bem
como exemplos de seu uso. Outro ponto abordado nos Servios Web foi a utilizao do
WSDL na publicao e descoberta. O WSDL assim como o servio de publicao e
descoberta possui informaes de acesso ao servio, logo o WSDL pode ser usado no auxilio
a publicao e descoberta com suas informaes.

Outro ponto abordado neste captulo, que como este trabalho prope um Servio de
Publicao e Descoberta utilizando o padro UDDI; necessrio ento apresentar as possveis
tecnologias a serem usadas no escopo desse servio.
Com a leitura do captulo de Arquitetura Orientada a Servios SOA, possvel observar que
existem padres e tecnologias que podem ser utilizados na criao de um Servio de
Publicao e Descoberta de Servios Web. Sendo que, para disponibilizar a publicao e
descoberta para os Servios Web de monitoramento necessrio um desenvolvimento a parte,
que considere as caractersticas dos Servios Web de monitoramento, bem como as
caractersticas dos usurios dos Servios Web de monitoramento.

47

3 INFRA-ESTRUTURAS DE MONITORAMENTO

Atualmente existem diversas infra-estruturas de monitoramento de redes e, como j

mencionado, existe uma forte tendncia para o uso da Arquitetura Orientada a Servios
(SOA) na estrutura dessas infra-estruturas. Existem tambm algumas infra-estruturas que no
seguem as especificaes de uma arquitetura orientada a servios, mas que usam Servios
Web para fornecer algumas de suas funcionalidades.

Este captulo aborda um ponto importante no cenrio de medies em redes de computadores

que o General Framework Design (GFD). Neste captulo tambm sero descritas algumas
funcionalidades,

estrutura

aplicao

das

mais

importantes

infra-estruturas

de

monitoramento, onde tambm sero analisados nessas infra-estruturas, aspectos tais como o
uso da arquitetura orientada a servios e a publicao e descoberta, caso se aplique. Essa
abordagem extremamente necessria, pois, a publicao e descoberta proposta neste
trabalho est inserida no contexto das infra-estruturas de monitoramento, mais precisamente
no piPEs-BR/GFD e perfSONAR.

3.1

GENERAL FRAMEWORK DESIGN (GFD)

Hoje em dia as redes empregam diversas ferramentas para monitorar uma variedade de
caractersticas da rede, desde uma simples conexo a uma anlise detalhada de um protocolo.
Assim, os mecanismos usados para realizar testes, coletar dados e at mesmo apresentar esses
dados para os usurios diferem entre si de acordo com o domnio em que est sendo utilizado.
O modo de acesso, assim como as polticas de acesso a esses dados tambm diferem em
domnios administrativos diferentes.

Contudo, um gerente de rede que deseja detectar o baixo desempenho em uma conexo fim-afim geralmente no possui condies de detectar o problema ao longo do caminho, pois
necessria a utilizao de vrios mecanismos ou pontos que possam desdobrar esse caminho
para detectar com preciso o local do problema. Outro fator que esse caminho pode

48

percorrer domnios administrativos diferentes e logicamente o gerente de um domnio pode

no ter acesso aos dados de outro domnio. Isso faz com que o gerente no tenha uma viso
global do trajeto fim-a-fim e sim uma viso somente do seu domnio.

Para tentar solucionar problemas como os citados anteriormente, a Internet2 e Gant2 se

uniram para definir uma infra-estrutura de monitoramento para que as medies atinjam
mltiplos domnios. Essa definio est contida em um documento chamado de General
Framework Design (GFD). O objetivo principal do GFD detalhar e definir uma camada de
middleware entre as ferramentas de visualizao e as ferramentas de medies existentes
entre os domnios. Na Figura 3.1 possvel ver essa camada. Essa camada seria disponibilizada
por uma arquitetura orienta a servios (vide Captulo de Arquitetura Orientada a Servios
SOA).

Figura 3.1 - Arquitetura do GFD

Fonte: HANEMANN (2005).

Num cenrio onde um administrador de rede deseja monitorar o status e o desempenho das
redes e, por sua vez, um usurio comum tambm possui o mesmo desejo, mas com finalidade
diferente, pode receber como mecanismo para o fornecimento das informaes necessrias,
uma infra-estrutura implementada de acordo com as definies contidas no GFD. Pois essa
infra-estrutura deve ser capaz de fornecer informaes localizadas em pontos especficos da
rede possibilitando administradores identificar possveis problemas, bem como informaes

49

que auxiliem os usurios no uso de suas aplicaes com o auxlio de dados de medies fima-fim. Contudo, a infra-estrutura de monitoramento deve ser capaz de receber vrios tipos de
requisies como: execuo de testes, armazenamento de dados, recuperao de dados e
outros. Essas requisies so solicitaes aos servios disponibilizados pela infra-estrutura
que podem estar aglomerados em um nico componente ou em vrios, como exemplo um
servio de armazenamento de dados que armazena e recupera dados.

Os principais servios descritos no GFD so: Ponto de Medio (Measurement Point - MP),
servio de armazenamento (Measurement Archive - MA), servio de publicao e descoberta
(Lookup Service - LS), servio de transformao (Transformation Service - TS), servio de
topologia (Topology Service - TopS) e o protetor de recursos (Resource Protector - RP).

a) armazenamento de medies - O Servio de Armazenamento (Measurement

Archive - MA) usado para guardar os dados histricos de medio em um
arquivo ou em uma base de dados. Um arquivo pode ser, por exemplo, dados
armazenados em um arquivo com a extenso txt, ou uma base de dados pode
ser Round Robin Database (RRD). Geralmente o MA pode armazenar dados
medido por um ponto de medio ou dados transformados pelo servio de
transformao. O MA pode simplesmente tambm armazenar dados que foram
medidos por um dispositivo que no faz parte da infra-estrutura. Por exemplo,
dados coletados de um roteador que so armazenados em uma base RRD e que
acessada pelo MA, disponibilizando assim esses dados.
Este servio deve ser projetado para possuir uma alta disponibilidade para
poder disponibilizar os dados para os clientes. Isso pode ser feito de muitas
maneiras, includo a escolha de softwares e hardware de tima confiana,
fazendo backup das informaes, proporcionando redundncia dos dados e
recuperao de falhas;
b) Publicao e Descoberta - altamente incomodo e difcil descobrir a
localizao e as funcionalidade de um servio que pode estar at em domnios
diferentes. O Lookup Service (LS) permite os usurios descobrirem os servios
(MA, MP, TS, etc.), alm de descobrir tambm informaes sobre as
funcionalidades do servio e suas caractersticas. O LS fornece para o usurio
todas as informaes necessrias para acessar o servio. Essencialmente o LS
age como um diretrio de servios, onde os servios possam se publicar e os

50

usurios possam localizar esses servios. Algumas dessas informaes podem

ser escondidas dependendo da permisso do usurio.
O Lookup Service um componente chave da infra-estrutura de monitoramento
porque ele torna possvel o uso dos servios de forma dinmica e
independente, tornando o Servio Web uma parte visvel da infra-estrutura;
c) Autenticao - Alguns domnios podem restringir ou oferecer uma forma
diferenciada no acesso a algumas funcionalidades dos servios, para um grupo
de usurios. O Servio de Autenticao (Authentication Service - AS) prov a
funcionalidade de autenticao (AuthN) para a infra-estrutura, assim como a
autorizao para usar um determinado servio ou somente algumas de suas
funcionalidades. Com as informaes fornecidas pelo LS, o servio local pode
permitir acesso a um conjunto de suas funcionalidades para um usurio de
acordo com o grupo ao qual ele faz parte;
d) Transformao - O Servio de Transformao (Transformation Service - TS)
usado para fazer a traduo, correlao e filtragem dos dados entre os outros
servios da infra-estrutura. Pode ser usado para executar qualquer funo em
cima dos dados. Pode atuar nos dados dos produtores, por exemplos os MPs,
ou nos consumidores, por exemplo, clientes de visualizao. Existem vrias
funcionalidades que podem ser inseridas no servio de transformao. Um
exemplo a agregao de dados. Por exemplo, um servio de transformao
pode comprimir uma srie de dados atuais coletados de forma bem detalhada e
transform-los em dados histricos que podem ser uma mdia de um intervalo
maior;
e) Topologia - O Servio de Topologia (Topology Service - TopS) responsvel
por tornar as informaes de topologia da rede disponveis para a infraestrutura de monitoramento. Geralmente os clientes de visualizao fazem uso
dessa informao de topologia para criar mapas das redes. Num primeiro
estgio o TopS pode focalizar na camada do IP. Uma verso mais refinada que
pode se aprofundar ainda mais na topologia da rede pode ser desenvolvida
gradativamente.
O TopS ir coletar informaes de topologia de diversas fontes como, por
exemplo, de dispositivos de redes e usa um algoritmo para deduzir essa
topologia. O servio de rede pode tambm refletir a camada de rede, isso uma

51

descrio no nvel de domnios. Essas informaes de topologia tambm

podem conter informaes geogrficas como coordenadas de GPS;
O servio de topologia tambm deve ser capaz de informar dados de
proximidades entre as peas que compem a topologia ou at a distncia entre
servios da infra-estrutura. Por exemplo, um usurio gostaria de saber qual o
ponto de medio mais prximo do seu computador para realizar testes.
f) Protetor de Recursos - O Protetor de Recursos (Resource Protector - RP) atua
como um rbitro, limitando o uso de dados de medies nas redes. o RP
quem libera a execuo de qualquer teste pelos componentes da infra-estrutura.
Por exemplo, em um canal de 1Mbps possvel atribuir no RP que desse total
somente 100kbps sero disponibilizados para dados de medio. Se esse teto
for atingido, o RP no liberar a execuo de novos testes naquele canal ou
testes que passam por aquele canal. O RP deve somente limitar o uso de
recursos em enlaces pequenos ou enlaces sobrecarregados.

3.2

INFRA-ESTRUTURAS DE MONITORAMENTO

3.2.1 PingER

A infra-estrutura Ping End-to-end Reporting (pingER) (MATTHEWS; COTTRELL, 2000)

baseada na ferramenta ping, que uma ferramenta muito familiar para os administradores de
rede e que tambm bastante usada por usurios de redes. Basicamente a infra-estrutura
gerencia um conjunto de medidores (servidores), que dependendo da configurao enviam
pacotes ICMP (Internet Control Message Protocol) (POSTEL, 1981) para pontos (sistemas
finais ou roteadores) especficos da rede usando a ferramenta ping, para monitorar o
desempenho entre domnios.

O pinGER capaz de medir o percentual de pacotes perdidos e o tempo de resposta (Round

Trip Time - RTT)13 entre dois ou mais pontos. Atualmente o projeto pingER possui vrios

13

RTT o tempo total para que um pacote (ou datagrama) seja enviado e retorne origem.

52

hosts e medidores espalhados pelas rede de computadores em vrios pases, medindo

constantemente. Essas informaes so disponibilizadas na Internet para que usurios das
redes possam obt-las.

A arquitetura do pingER composta por trs componentes. Na Figura 3.2 esses componentes
podem ser visualizados, bem como a relao entre os mesmo. J a descrio de cada
componente pode ser feita assim:

a) medidor remoto - um simples ponto que de forma passiva responde aos

pings. Esse host s precisa possuir alguns requisitos como disponibilidade e
permisso para responder solicitao de ecos do ICMP;
b) medidor - Possui uma ferramenta chamada PinGER Monitoring Tool, a qual
executa a ferramenta ping, para fazer testes at os Medidores Remotos. Ela
tambm envia para o armazenador os resultados das medies. O Medidor
tambm faz algumas anlises dos dados medidos, isso de acordo com as
configuraes. Essas anlises consistem em: gerao de grficos dirios,
gerao de grfico 3D composto pela hora do dia, o host que est sendo testado
e a mtrica medida. A anlise tambm realiza mdias mensais que enfatizam os
horrios de pico das medidas e previses com base em dados histricos.
importante salientar que o envio das informaes para o armazenador feito
via Servios Web;
c) armazenador - Esse componente responsvel por armazenar os dados
coletados pelos medidores e por realizar operaes sobre esses dados, sendo
que numa viso mais global como: compor os dados, analisar dados e etc. O
armazenador disponibiliza servios web para que os medidores possam
armazenar os dados coletados. E, por sua vez, disponibilizam essas
informaes via web.

53

Figura 3.2 - Cenrio de medies com a infra-estrutura pingER

Fonte: MATTHEWS (2000).

3.2.2 MonALISA

A MonALISA (Monitoring Agents using a Large Integrated Services Architecture) um

framework que prov um sistema de servios de monitorao distribudo, usando as
tecnologias JINI/JAVA14 e WSDL/SOAP e est baseado em uma Arquitetura Dinmica de
Servios Distribudos (do ingls Dynamic Distributed Services Architecture - DDSA)
(NEWMAN e outros, 2001). A MonALISA formada por componentes que agem como um
sistema independente, provendo informaes a serem descobertas e utilizadas pelos demais
usurios clientes. Esse sistema composto por dois componentes principais: o servio
MonALISA (MonALISA Service) e o cliente MonALISA (MonALISA Client) onde o servio
responsvel pelas medies e publicao dos dados e o cliente encarregado de realizar a
visualizao dos dados fornecidos pelo servio.

Assim, o servio MonALISA contm mdulos que realizam coleta de dados ou testes com
ferramentas de medio. Apesar de ser uma ferramenta proprietria, existe ainda a
possibilidade de desenvolver mdulos para disponibilizar outros tipos de dados. Ao se

14

Pgina Web do JINI, disponvel em http://www.jini.org

54

desenvolver mdulos adicionais para o MonALISA, necessrio que estes sejam

desenvolvidos em linguagem Java. Neste caso, esses mdulos so classes que herdam
funcionalidades de outras classes do prprio servio MonALISA.
Basicamente, cada servio MonALISA pode ser composto por uma ou mais Farms, que o
nome dado a um conjunto de mdulos, onde essas Farms realizam a coleta de dados em
dispositivos ou executa ferramentas de medio tais como o Ping e o IPerf15. Essas Farms
so visualizadas no cliente MonALISA como pontos na superfcie de um globo terrestre, e
que quando so selecionados fornece as informaes do servio MonALISA correspondente.
A Figura 3.3 mostra a tela de um cliente MonALISA.

Figura 3.3 - de visualizao da MonALISA

Nota: elaborao do autor (2007).

Na Figura 3.4 possvel ver a interao entre todos os elementos envolvidos com o
MonALISA. Ao lado direito possvel ver o cliente de visualizao (cliente MonALISA), que
como passo inicial conecta em um servio de busca e coleta as informaes necessrias para
acessar e exibir no globo as Farms existentes. Com esse procedimento completo, o cliente
pode conectar em cada Farm (servio monALISA) e requisitar os dados disponveis. No

15

Ferramenta de monitoramento que mensura a largura de banda disponvel entre dois computadores.

55

centro da figura, possvel ver o servio MonALISA e como ele interage com as ferramentas
e dispositivos atravs de seu mdulos.

Figura 3.4 - Interao entre os diversos componentes do MonALISA

Nota: elaborao do autor (2007).

3.2.3 perfSONAR

O perfSONAR (Performance focused Service Oriented Network monitoring Architecture) o

prottipo de validao do framework GFD. O perfSONAR est sendo desenvolvido pela
Internet2, Gant2 e recentemente juntaram-se ao grupo pesquisadores da RNP e ESnet. Numa
abordagem inicial, o grupo definiu que para a primeira verso do prottipo seriam
disponibilizados apenas dois servios e um cliente de visualizao. Os elementos
disponibilizados na verso 1.0 foram:

a) Measurement Archive RRD - Servio que armazena dados coletado por

dispositivos da rede (roteadores) no formato RRD. Esses dados so referentes a

56

utilizao das interfaces desse dispositivos, assim o MA-RRD disponibiliza o

nvel de utilizao das interfaces dos dispositivos de rede;
b) Lookup Service XML - Servio de publicao e descoberta de Servios Web,
que utiliza base de dados XML para armazenar as informaes sobre os
Servios Web;
c) perfSONARUI - Cliente de visualizao que faz acesso ao MA-RRD e
disponibiliza grficos com os dados das interfaces.

Com a chegada do GT-Medies da RNP e pesquisadores da ESnet para juntar esforos, a

verso 2 do perfSONAR incorporou vrios pontos de medio, dentre eles o MP de linha de
comando (CLMP - Command Line Measurement Point) desenvolvido pelo GT-Medies.
Outro novo servio do perfSONAR 2.0 o Measurement Archive SQL onde so armazenados
os dados medidos pelo CLMP. Na Figura 3.5 possvel ver um exemplo da estrutura e
interao dos componentes do perfSONAR na sua verso 1.0. Nessa figura, o elemento mais a
esquerda formado pelos dispositivos onde so coletados os dados, que no caso da verso 1.0
do perfSONAR se trata dos dados de utilizao das interfaces de equipamentos de redes. O
prximo componente uma base de dados que armazena os dados de medies no formato
RRD, que por sua vez fornece esses dados para o MA. Todavia, o perfSONARUI, que o
cliente de visualizao pode localizar o MA utilizando o Servios LS (publicao e
descoberta) e assim recuperar os dados medidos via MA.

O perfSONAR usa um protocolo prprio para a troca de mensagens na comunicao interna e

externa. Esse protocolo baseado em mensagens XML SOAP que seguem os padres
definidos pelo Network Measurement Working Group (NMWG16) do Open Grid Forum
(OGF17), para medies em redes de computadores. Logo, as mensagens de comunicao
usada no perfSONAR so chamadas de mensagens do tipo NMWG.

16

Grupo de pesquisa internacional em redes de computadores.

17

Comunidade de padronizao para grid computacionais.

57

Figura 3.5 - Componentes do prottipo perfSONAR 1.0

Nota: elaborao do autor (2007).

O esquema NMWG distribui as informaes dos dados de medies em elementos bsicos

chamados de Metadata e Data, onde o Metadata contm informaes consideradas genricas
que identificam um conjunto de dados de medies. J o objeto Data armazena o dado
propriamente dito, ou seja, pode ser um valor ou uma informao especfica. Esses elementos
podem ser combinados formando um conjunto de informaes que podem ser analisadas
facilmente. Na Figura 3.6 possvel ver esses dois elementos e suas relaes.

Como exemplo possvel utilizar uma mensagem que contm o resultado de uma requisio
de dados de medio unidirecional entre dois pontos. Onde o Metadata, por exemplo, pode
conter as informaes entres os dois pontos, o intervalo de tempo medido, a ferramenta usada
e etc. J a informao contida no elemento Data seria o valor da medio. Caso o resultado
contenha mais de um valor de medio, estes valores estaro distribudos em mais de um
elemento Data.

58

Figura 3.6 - Estrutura da mensagem NMWG

Nota: elaborao do autor (2007).

A seguir sero descritos os componentes da verso 1.0 do perfSONAR:

a) Measurement Archive RRD (MA RRD) - O MA RRD foi inicialmente

desenvolvido para armazenar e disponibilizar dados de utilizao de interfaces
de dispositivos de redes, especificamente roteadores. Essa abordagem foi
adotada pelo simples fato de que uma grande parte das redes acadmicas
possui uma base de dados em RRD com os dados de utilizao das interfaces
dos roteadores que compem as redes acadmicas. O MA RRD basicamente
faz a interface de acesso padro do perfSONAR, disponibilizando alguns
servios para recuperar esses dados
Atualmente existe verses da base RRD do perfSONAR que trabalham de
forma mais genrica. Ou seja, possibilitam o armazenamento e o fornecimento
de dados RRD independendo da sua origem. Esses dados podem ser obtidos
atravs de uma ferramenta de medio que deseja utilizar as vantagens de uma
base RRD. Podem ser tambm dados de uma ferramenta de medio passiva
que geralmente se relacionam bem com as bases RRD devido quantidade de
informao e outros;
b) Lookup Service XML Type (LS-XML) - O LS-XML realiza a publicao e
descoberta de Servios Web do perfSONAR. O LS pode receber mensagens
solicitando o registro, consulta, alterao e remoo de informaes sobre
servios web. Cada Servio Web possui um conjunto de informaes que so

59

armazenadas periodicamente pelos prprios Servios Web. Essas informaes

so armazenadas em uma base de dados XML, onde a implementao usada
dessa base denominada de eXist18. A escolha desse tipo de base de dados se
deu pelo simples fato de que as mensagens contendo as informaes sobre o
Servio Web j so escritas em XML. Desse modo o armazenamento se
torna simples, pois possvel extrair parte da prpria mensagem e armazenar
diretamente na base de dados. Esse tipo de abordagem dispensa a manipulao
dos dados, o que facilita a programao em vrios aspectos. Mas, tambm traz
alguns problemas para o servio, como a no verificao se os dados esto
corretos;
c) perfSONARUI - A PerfSONARUI (HANEMANN, 2006) uma ferramenta de
visualizao desenvolvida em JAVA, que teve como finalidade inicial
demonstrar as funcionalidades do perfSONAR. Basicamente a ferramenta
recupera dados do servio de armazenamento MA e os disponibiliza
graficamente para os usurios. Vale ressaltar que como prottipo inicial o
perfSONAR possua apenas o MA-RRD, logo o perfSONARUI possua apenas
a visualizao para esses tipos de dados. Sendo que existem previses de
disponibilizao de outros tipos de informaes.

Atualmente o perfSONARUI no usa os Lookup Service para localizar os servios usados. O

perfSONAUI possui as informaes de acesso aos servios armazenadas em arquivos de
configurao ou na prpria codificao. Isto quer dizer que qualquer alterao nas
informaes de acesso aos servios a ferramenta deixa de ser funcional a menos que seja
reinstalada com as novas informaes.

3.2.4 piPEs-BR/GFD

A infra-estrutura de monitoramento de redes de computadores piPEs-BR/GFD uma

evoluo da arquitetura piPEs-BR desenvolvida no primeiro ano do GT-Medies. A idia
por trs do piPEs-BR/GFD disponibilizar um conjunto de softwares que siga as

18

Implementao de uma base de dados XML nativo.

60

especificaes contidas no General Framework Design (GFD). possvel dizer tambm que
o piPEs-BR/GFD a verso brasileira do perfSONAR, que leva em considerao a
experincia do GT-Medies na RNP. Outro fator que justifica a afirmao de que o piPEsBR/GFD uma verso brasileira do perfSONAR que o GT-Medies ao vislumbrar um
interesse em comum com os grupos de pesquisa da Internet2 e Gant2 em desenvolver uma
infra-estrutura com base no GFD decidiu desenvolver em sua infra-estrutura de
monitoramento componentes diferentes dos previstos no perfSONAR. Tendo essa meta em
vista o GT-Medies exps suas intenes aos grupos desenvolvedores do perfSONAR. Deste
modo, o GT foi convidado para participar no desenvolvimento do perfSONAR, agregando
assim seus mdulos desenvolvidos ao prottipo. Assim, o perfSONAR e o piPEs-BR/GFD
so infra-estruturas que se completam, onde uma pode usar os mdulos da outra, devido
padronizao das mensagens e ao uso de servios Web assim como definido na SOA.

O piPEs-BR/GFD composto por um conjunto de mdulos que visam contemplar as

funcionalidades de: agendamento de testes, execuo de testes, armazenamento, autorizao e
visualizao de dados medidos. Inicialmente, em termos de prottipo, o GT-Medies
desenvolveu para a RNP um mdulo de armazenamento, um servio de publicao e
descoberta, um ponto de medio e um cliente de visualizao. Estes mdulos interagem entre
si atravs de servios Web, disponibilizando e requisitando servios com funcionalidades
especficas e bem definidas. A arquitetura do piPEs-BR/GFD pode ser vista na Figura 3.7,
bem como a interao entre os mdulos. Os principais mdulos do piPEs-BR/GFD so: o
Ponto de Medio de Linha de Comando (Command Line Measurement Point - CLMP), na
figura representado apenas por MP (X, Y e Z), o mdulo de armazenamento de dados de
medio (Measurement Archive Sql) que na figura representado pela sigla MA e uma base
de dados de medio, o servio de publicao e descoberta UDDI (Lookup Service UDDI
Type - LS-UDDI) e a ferramenta de visualizao Internet Computer Eye - ICE (KOGA e
outros, 2007). Cada um desses componentes sero descritos a seguir.

61

Figura 3.7 - Arquitetura do piPEs-BR/GFD

Fonte: SAMPAIO e outros (2007).

3.2.4.1 Descrio dos mdulos

a) CLMP - Ponto de Medio de Linha de Comando - O ponto de medio cria

os dados de monitoramento a partir da realizao de testes de medies ativa
ou passiva19. No caso do CLMP ele disponibiliza uma interface para realizar
teste de medies ativas atravs das ferramentas de linha comando, ou seja,
ferramentas cuja interao se d atravs da linha de comando da interface
shell20 do sistema operacional. OWAMP21, IPERF e PING so exemplos de
ferramentas de linha de comando.
O CLMP capaz de receber requisies de testes sob demanda e requisies
para agendamento de testes. Esse agendamento pode ser usado para configurar

19

Nas medies passivas so coletadas informaes sobre todos os pacotes que trafegam na rede sem provocar
nenhuma interferncia no trfego. Nas medies ativas so gerados pacotes de teste e monitorado o
desempenho para os mesmos atravs da rede.
20
21

Software que faz o intermdio entre o Sistema Operacional e o usurio.

Ferramenta que implementa o One-Way Active Measurement Protocol e fornece perda de pacotes, variao do
atraso e o atraso entre dois computadores. O OWAMP fornece dados de medio unidirecional, o qual para ser
coletado; precisa de sincronismo entre os envolvidos.

62

testes regulares ou executar teste em um horrio especfico desejado pelo

usurio. Outra funcionalidade do CLMP armazenar no mdulo de
armazenamento, o MA, os resultados dos testes agendados. Assim como os
outros mdulos do piPEs-BR/GFD, o CLMP realiza o registro de suas
informaes de acesso no Servio de Publicao e Descoberta;
b) armazenamento de medies com Sql - MA-Sql - Mdulo responsvel por
armazenar dados de medio. A origem desses dados diversificada o que
torna a abrangncia do MA em relao ao armazenamento bastante ampla. O
MA pode armazenar os dados medidos pelos pontos de medio, pode
armazenar dados coletado de dispositivos de redes, pode armazenar dados
provenientes de ferramentas de monitoramento e pode armazenar dados
modificados por um servio de transformao;
c) servio de publicao e descoberta - O servio de publicao e descoberta do
piPEs-BR/GFD proposto neste trabalho, logo maiores informaes podem ser
obtidas no Captulo de Publicao e Descoberta de Servios de
Monitoramento;
d) Internet Computer network Eye - ICE - A idia inicial do ICE era somente de
prover acesso a diferentes mtricas de desempenho, prover acesso aos servios
do piPEs-BR e demonstrar visualmente os dados provenientes desse acessos.
Com a inteno de tornar possvel que outras aplicaes tambm pudessem ter
acesso ao piPEs-BR/GFD, o ICE incorporou a arquitetura FLAVOR (KOGA e
outros, 2007) que permite o desenvolvimento de bundles OSGI (MARPLES;
KRIENS, 2001) que podem ser reusados e estendidos por outras aplicaes que
desejam incorporar as funcionalidades do ICE (KOGA e outros, 2007).

3.3

CONSIDERAES

O uso de uma determinada infra-estrutura depende diretamente da demanda de informao

por parte dos usurios e administradores das redes, pois existem no mercado diversas opes,
para diversas finalidades. No entanto, possvel afirmar que devido a um interesse maior por
parte dos usurios em informaes de medies diversificadas, as infra-estruturas que
abrangem vrias mtricas, usam vrias ferramenta e que atingem vrios domnios fazem parte

63

das solues inovadoras em medies em redes de computadores. Isso pode ser explicado
tambm pelo interesse de vrias redes acadmicas e de pesquisa em apoiar o projeto do
perfSONAR.

A infra-estrutura pingER pelo fato de usar somente uma ferramenta, o ping, s atinge uma
parte dos usurios de redes. Por exemplo, os usurios de grids computacionais que desejam
saber principalmente o atraso entre os computadores. Isso difere de usurios de voz sobre IP
que alm do atraso desejam saber tambm qual a banda disponvel. Outro fator que pode
restringir o nmero de usurios para o pingER o fato de a ferramenta ping s fornecer
informaes bidirecionais, o que pode no satisfazer um administrador de rede que deseja
saber em que sentido do link est ocorrendo perdas, por exemplo.

No entanto na infra-estrutura pingER possvel observar o uso de Servios Web nos

componentes que so distribudos em domnios diferentes, mas essa infra-estrutura no utiliza
os trs componentes integrantes da arquitetura orientada a servios. Para auxiliar a localizao
dos Servios Web por parte dos usurios necessrio utilizar um Servio de Publicao e
Descoberta. O pingER faz o que comumente infra-estruturas que no implementa os trs
componentes da SOA fazem: armazena em um arquivo XML as informaes de acesso aos
Servios Web. Esse tipo de abordagem faz com que parte da infra-estrutura pare de funcionar
caso as informaes de acesso aos Servios Web mudem. Por exemplo, o Medidor ao tentar
armazenar as informaes coletadas no armazenador via Servios Web pode no obter xito,
isso porque a URI de acesso ao Servio Web do medidor pode ter mudado (o que comum) e
as informaes de acesso contidas no arquivo XML esto desatualizadas. Com o uso do
UDDI na infra-estrutura pingER, problemas como esse seriam sanados, pois essa operao
iria ser automatizada.

J na infra-estrutura MonALISA ocorre um fato diferente em relao publicao e

descoberta. Como visto na Figura 3.4, a MonALISA possui um servio de publicao e
descoberta, mas esse servio baseado na tecnologia JINI. O JINI um conjunto de
mecanismos para a construo de arquiteturas orientadas a servios, disponibilizando
ferramentas, bibliotecas JAVA e definindo um modelo de programao para desenvolver
aplicaes seguras e distribudas. Resumindo, o JINI prov um conjunto de solues para a
construo de uma arquitetura orientada a servios, contemplando os trs componentes da
SOA. Assim, o JINI possibilita o desenvolvimento de servios, proporciona a publicao e

64

descoberta dos mesmos e possibilita tambm o desenvolvimento de clientes que os utilizem.

importante salientar que os servios disponibilizados pelo JINI no so Servios Web.

Alm do mais, o servio de publicao e descoberta da MonALISA uma soluo

proprietria e s pode ser utilizado por clientes e servios da prpria infra-estrutura
MonALISA. Isso implica em que nenhuma outra aplicao pode utilizar as funcionalidades da
MonALISA. Outro ponto a ser ressaltado que no servio de publicao e descoberta do JINI
no existe a possibilidade de utilizar mltiplos servios de publicao e descoberta. O uso de
mltiplos servios de publicao e descoberta possibilita maior disponibilidade do servio,
pois existem mais de uma opo. Outra vantagem que servios de publicao e descoberta
em domnios diferentes podem interagir e trocar informaes, possibilitando a localizao de
servios em domnios diferentes.

Por outro lado, os desenvolvedores do perfSONAR ao decidir qual a melhor opo para a
publicao e descoberta para sua infra-estrutura, optaram por desenvolver um servio prprio.
Nos seus estudos outra tecnologia poderia ser usada, o UDDI, mas o receio de que
futuramente o UDDI no suportasse novas funcionalidades e caractersticas, fez com que a
sua escolha no fosse recomendada. Isso aconteceu mesmo existindo implementaes do
padro UDDI de cdigo aberto que possibilitam modificaes.

Assim, o servio de publicao e descoberta do perfSONAR chamado de Lookup Service

XML (LS-XML). O LS-XML implementa as funcionalidades bsicas de um servio de
publicao e descoberta, o que pode ser considerado como uma nova implementao de um
Servio de Publicao e Descoberta. Sendo que o LS-XML no implementa a verificao das
informaes, o controle de insero e o uso de ndices, que so caractersticas implcitas nas
base de dados relacionais. Ou seja, vrias funcionalidades que a UDDI prov, no so
implementadas no LS-XML, o que lhe deixa em desvantagem em relao ao UDDI. Outro
fator que importante relatar no LS-XML o fato de usar uma base de dados XML. A base
de dados XML por no possuir mecanismos de indexao, relacionamento e outros pode obter
um desempenho baixo nas consultas de servios. No entanto, o uso de base de dados XML
torna o armazenamento de dados flexvel, pois com a utilizao de Schemas XML possvel
criar variaes no formato dos dados a serem armazenados. Por exemplo, no caso do LSXML do perfSONAR existe a possibilidade de criar estruturas com o uso de vrios objetos
Metadata e Data.

65

Estas consideraes reforam o objetivo principal deste trabalho que o de propor e

desenvolver um Servio de Publicao e Descoberta para a infra-estrutura piPEs-BR/GFD
utilizando uma implementao da tecnologia UDDI. Pois possvel ver que as solues
existentes de publicao e descoberta para as infra-estruturas de monitoramento apresentam
algumas desvantagens em relao a uma soluo usando o padro UDDI, como o uso de uma
base de dados XML que possui baixo desempenho, a no verificao dos dados contidos nas
requisies e o difcil acesso. Sendo que o UDDI um padro para Servios Web para esse
tipo de finalidade, e que no seu desenvolvimento j esto includas inmeras funcionalidades
envolvidas na publicao e descoberta de Servios Web.

preciso salientar tambm que para existir a interao do servio de publicao e descoberta
proposto com outras infra-estruturas de monitoramento, desejvel que o mesmo possua uma
interface padro para que a comunicao entre as infra-estruturas possa ocorrer independente
da tecnologia utilizada. Assim, essa interface de comunicao deve seguir o padro proposto
pelo perfSONAR, o qual define que a comunicao feita entre os componentes realizada
atravs de mensagens XML definidas por um esquema padro que, neste caso, o NMWG.
Logo, este trabalho tambm tem como objetivo fazer com que o servio de publicao e
descoberta proposto utilize essa interface padro com troca de mensagens NMWG.

66

4 PUBLICAO E DESCOBERTA DE SERVIOS DE MONITORAMENTO

Este captulo aborda questes que envolvem a Publicao e Descoberta de Servios no mbito
de medies em redes de computadores, pois existem caractersticas pertinentes rea de
medies como: nomenclaturas existentes, tipo de servios, forma de acesso e etc., que devem
ser levadas em considerao e que diferem de uma simples Publicao e Descoberta de
Servios. Essas questes sero usadas no prottipo desenvolvido e so de extrema
importncia para o entendimento do mesmo. Sendo que como o prottipo desenvolvido utiliza
o padro UDDI para Publicao e Descoberta de Servios Web, algumas das questes
abordadas abrangem tambm aspectos relacionados ao UDDI.

4.1

INTRODUO

Como visto nos captulos anteriores, o Servio de Publicao e Descoberta um componente

importante para as infra-estruturas de monitoramento. Mas, para disponibilizar um Servio de
Publicao e Descoberta eficiente, disponvel, confivel e que possa ser utilizado em vrios
domnios diferentes, necessrio ir alm de simplesmente implantar uma das tecnologias de
Publicao e Descoberta existentes. Muitas variveis envolvem os Servios Web de
monitoramento e essas variveis devem ser levadas em considerao na definio,
desenvolvimento e implantao de um Servio de Publicao e Descoberta. Para isso,
necessrio pesquisar as caractersticas que envolvem os Servios Web de monitoramento,
verificar as necessidades dos usurios dos Servios Web de monitoramento em relao
descoberta desses servios, determinar as tecnologias a serem usadas e definir o Servio de
Publicao e Descoberta de acordo com os tipos de usurio.

Uma questo principal que envolve os Servios Web de monitoramento sua classificao. A
classificao facilita a identificao do servio e ajuda a distinguir um nico servio ou um
grupo de servios com caractersticas semelhantes ou que por algum motivo esto
relacionados. Essa classificao de extrema importncia para a Publicao e Descoberta,
pois atravs dessa classificao possvel criar uma estrutura de informaes que facilite a

67

identificao dos servios e, conseqentemente, a descoberta dos mesmos. Como exemplo,

possvel citar o UDDI que possibilita usar informaes caractersticas dos servios para criar
taxonomias que so usadas como ndice nas descobertas dos servios.

J no cenrio dos Servios Web de monitoramento, o Network Measurement Working Group

(NMWG), definiu um padro que prope uma nomenclatura entre as caractersticas de
medies em redes de computadores (LOWEKAMP, 2004). A motivao para a criao dessa
nomenclatura foi facilitar a comunicao entre componentes. Esse tipo de trabalho facilita a
identificao dos servios de monitoramento, pois alguns servios possuem como
caracterstica principal uma dessas informaes contidas na hierarquia. Um exemplo que pode
ser citado um servio que fornece dados de medio unidirecional (oneway), logo a
caracterstica oneway que est contida na hierarquia pode ser usada como um ndice na
pesquisa em um Servio de Publicao e Descoberta.

Outro ponto que envolve a publicao e descoberta de servios de monitoramento quais

tecnologias podem ser usadas para o seu desenvolvimento e implantao. Em resumo, este
trabalho usou as tecnologias consideradas padres de Servios Web, seja para disponibilizar
servios, desenvolver clientes e publicar e descobrir esses servios. Ao longo deste trabalho
possvel verificar justificativas implcitas para o uso destas tecnologias e ao longo deste
captulo tambm sero abordadas algumas das vantagens de usar essas tecnologias.

4.2

CARACTERSTICAS DOS SERVIOS DE MONITORAMENTO

Alm das caractersticas definidas pelo NMWG, existem outras informaes que categorizam
o Servio Web de monitoramento. E mais especificamente os Servios Web da infra-estrutura
piPEs-BR/GFD. Nesta seo sero descritas as caractersticas dos Servios Web de
monitoramento e de que forma essas caractersticas podem ser utilizadas na publicao e
descoberta.

68

4.2.1 Classificao por tipo de servio

Foi verificado que nos servios disponibilizados pelos piPEs-BR/GFD existe em comum uma
classificao lgica que identifica o servio. Essa classificao pode ser considerada como o
tipo do servio. No Quadro 4.1 apresentada a lista desses tipos e seus respectivos servios.
Logo, essas informaes foram usadas para categorizar os Servios Web do piPEs-BR/GFD
no Servio de Publicao e Descoberta proposto neste trabalho.

Tipos de servios do piPEs-BR/GFD e perfSONAR

Tipo
Sigla
Descrio
Measurement Point
MP
Ponto de medio
Measurement Archive
MA
Mdulo de armazenamento de dados
Round Robin Database
RRD
Tipo de base de dados que usa o conceito
Structured Query
SQL
Linguagem de pesquisa declarativa para
Language
banco de dados relacional
SNMP Measurement Point
SNMP MP Disponibiliza Servios Web para acessar
dispositivos que suportam SNMP
Alcatel NMS Measurement
NMS MP
Recupera dados medidos pelo Alcatel's
Point
Network Management System
Command Line
CL MP
Ponto de medio que executa ferramentas
Measurement Point
via linha de comando
Telnet/SSH Measurement
TELNET MP Usado para conectar de forma segura em
Point
dispositivos para recuperar informaes
Ping Measurement Point
PING MP
Ponto de medio que usa a ferramenta ping
BWCTL Measurement
BWCTL MP Ponto de medio que utiliza a ferramenta
Point
BWCTL
E2EMon Measurement
E2EMon MP MP que coleta dados do E2E Monitoring
Point
System
Command Measurement
C MP
Usado para executar qualquer tipo de
Point
comando em dispositivos remotos
Hades Measurement Point HADES MP Disponibiliza os dados de medies do Hades
(IPPM).
G3 Measurement Archive
G3 MA
Semelhante ao RRD MA
Quadro 4.1 - Informaes de tipos de servios do piPEs-BR/GFD
Nota: elaborao do autor (2007).

A idia construir uma hierarquia com as informaes de tipo. Onde o nvel dessa hierarquia
depende da especificao da informao. Um exemplo a ser citado o servio Measurement
Point, que como informao raiz possui o tipo MP que a abreviao de seu tipo
propriamente dito. Como existem vrias implementaes do MP, para vrias ferramentas de
medio e mtricas diferentes, possvel utilizar mais nveis na hierarquia. Assim, o prximo
nvel do MP nessa hierarquia se refere basicamente tecnologia do MP, por exemplo, o

69

Command Line Measurement Point (CLMP) que o MP que executa ferramentas de medio
via linha de comando. E sendo ainda mais especfico na classificao do MP, possvel usar
mais um nvel de identificao, como a ferramenta utilizada nesse MP, que no exemplo do
CLMP poderia ser identificado pela ferramenta OWAMP. Na Figura 4.1 possvel ver um
exemplo dessa classificao.

Figura 4.1 - Classificao dos servios pelo tipo

Nota: elaborado pelo autor (2007).

4.2.2 Usando a hierarquia das caractersticas de medies em redes

O Network Measurement Working Group (NMWG) props um conjunto padronizado de

caractersticas de redes e a classificao hierrquica dessas caractersticas. A motivao do
NMWG para realizar este trabalho foi a necessidade de interao entre vrios sistemas de
Grid que manipulam informaes de medio e que ao trocarem essas informaes
precisavam que as mesmas fossem identificadas. A padronizao dessas caractersticas
tambm facilita a criao de um esquema para a descrio dos dados de monitoramento.

Portanto, o NMWG identificou vrios tipos de caractersticas que envolvem medies em

redes, definiu uma nomenclatura e estabeleceu uma hierarquia entre essas informaes. O
resultado desse trabalho pode ser visto na Figura 4.2, onde esto representadas as caractersticas
identificadas e a hierarquia dessas caractersticas. possvel observar na figura que essas

70

caractersticas abrangem vrios aspectos dos dispositivos de redes, desde as mtricas que
influem sobre os dispositivos, at parmetros de confiabilidade como o perodo mdio entre
falhas (do ingls Mean time between failures - MTBF22) dos dispositivos ou enlaces.

Para a nomenclatura ficou definido que essas caractersticas devem ser escritas sempre com
letras minsculas, exceto quando o nome da caracterstica possuir mais de uma palavra. As
nomenclaturas que englobam as caractersticas da Figura 4.2 podem ser vistas no Quadro 4.2.

path.delay.roundTrip
path.loss.oneWay
path.loss.roundTrip
path.bandwidth.Utilized
hostToHostPath.bandwidth.achievable
hostToHostPath.hoplist
router.bandwidth.utilized
hop.delay.oneWay.jitter

path.delay.oneWay
path.packetReordering
hop.packetReordering
node.queue.length
router.queue.discipline
switch.forwarding.forwardingTable
router.bandwidth.capacity
autonomousSystem.delay.oneWay

Quadro 4.2 - Nomenclatura padro de vrias combinaes de caractersticas

Nota: elaborao do autor (2007).

Essa padronizao, atravs das caractersticas de redes, faz com que componentes possam
interagir utilizando a mesma linguagem. Um exemplo bastante demonstrativo que pode ser
citado o servio de MP que pode fornecer informaes de atraso (delay). Logo, um cliente
que deseja requisitar a um MP que realize testes de atraso unidirecional pode simplesmente na
requisio enviar uma mensagem contendo a solicitao de dados do tipo path.delay.oneWay.

22

Parmetro utilizado para descrever a confiabilidade.

71

Figura 4.2 - Caractersticas de rede usadas para descrever o comportamento dos dispositivos de redes
Fonte: LOWEKAMP (2004).

Ao deparar com essa hierarquia e nomenclatura, fica claro que possvel usar algumas dessas
caractersticas para identificar os Servios Web de monitoramento. Logo, foi decidido usar
essas caractersticas no Servio de Publicao e Descoberta proposto como mais uma opo
para identificar os Servios Web e assim facilitar a descoberta de servios.

possvel tambm usar o trabalho realizado pelo NMWG para criar taxonomias que
categorizem um grupo de servios, como os servios do tipo delay, que um conjunto de
servios que fornecem tambm o atraso do tipo Round Trip, One Way e Jitter. Assim se um
usurio deseja utilizar Servios Web que fornecem todos os tipos de delay, a nica
caracterstica a ser buscada no Servio de Publicao e Descoberta o prprio delay. Mais
informaes sobre as taxonomias criadas para o servio proposto neste trabalho poder ser
visto nas sees seguintes.

As caractersticas citadas anteriormente tambm podem ser usadas como ndices para
identificar um ou mais servios. Assim, possvel identificar um grupo de servios que, por
exemplo, pode estar relacionado com uma ferramenta de medio especfica ou relacionado a
uma mtrica.

72

4.3

PADRES E TECNOLOGIAS A SEREM UTILIZADOS

Para disponibilizar um Servio de Publicao e Descoberta preciso verificar se as solues

disponveis (padres, tecnologias, etc.) podem contemplar os requisitos desejados de acordo
com o escopo em que o servio ser disponibilizado. Por exemplo, a tecnologia ebXML (vide
captulo de Arquitetura Orientada a Servios SOA) no se aplica neste trabalho devido ao
fato de ser direcionada somente ao comrcio eletrnico. Portanto este trabalho, como j
relatado anteriormente, usa como base o padro Web para Publicao e Descoberta, o UDDI
(vide captulo de Arquitetura Orientada a Servios SOA). As motivaes para a escolha do
UDDI podem ser enumeradas da seguinte forma:

1. O UDDI a tecnologia padro para publicao e descoberta de servios;

2. O UDDI define um Servio de Publicao e Descoberta para Servios Web de
forma genrica. Ou seja, o UDDI no especifica o cenrio de utilizao,
podendo ser utilizado para publicar e descobrir qualquer tipo de Servio Web
em qualquer contexto;
3. Na literatura, UDDI sinnimo de publicao e descoberta. Muitos trabalhos
usam o UDDI em detrimento de outras solues.
4. Existem muitos trabalhos envolvendo o UDDI em diferentes escopos (ex.
(PINTO e outros, 2003), (ZHOU e outros, 2003) e (KAWAMURA e outros,
2004);
5. O uso do UDDI no escopo de medies uma iniciativa inovadora;
6. Um estudo prvio sobre o UDDI mostrou que o mesmo pode ser utilizado no
cenrio de medies, em especfico no piPEs-BR/GFD (MONTEIRO e outros,
2007).

Outras tecnologias e padres so usados na proposta deste trabalho. Dentre elas possvel
citar os Servios Web que iro realizar interface com o exterior, JAVA que ser utilizada
como linguagem de desenvolvimento e as padronizaes definidas pelo NMWG em relao a
mensagens de comunicao e classificao hierrquica das caractersticas de medies.

73

4.4

MODELO DE DADOS

Para utilizar o UDDI no cenrio de medies em redes de computadores, necessrio definir

quais componentes do UDDI sero usados e quais informaes sobre os Servios Web de
medio esses componentes iro armazenar. Alguns desses componentes possuem o tipo de
informao a ser armazenada predefinida, por exemplo, o componente Binding Template
(vide seo Componentes do UDDI) que armazena o Ponto de Acesso do servio. Logo, as
informaes que so comuns a qualquer Servio Web sero armazenadas nos locais
designados pelos componentes do UDDI e outras informaes especficas dos servios de
medies devem ser distribudas nos componentes de forma a possibilitar o entendimento e a
descoberta dos servios. Neste trabalho estamos chamando essa atividade de modelagem de
dados, j que esse tipo de ao semelhante modelagem de dados de bases de dados.

Basicamente algumas informaes podem ser consideradas padro, ou seja, comum para
qualquer servio, so elas: nome, ponto de acesso, descrio, parmetros e etc. Mas existem
informaes especficas que diferem de servio para servio e que devem ser distribudas nos
componentes do UDDI. O componente Category Bag do UDDI foi concebido para armazenar
essas informaes especficas. O prprio nome do componente explica o seu uso, pois as
informaes especficas de um servio geralmente o categorizam. No Quadro 4.3 esto
listados os componentes que sero usados no Servio de Publicao e Descoberta do piPEsBR/GFD. Nela possvel observar tambm as informaes que sero armazenadas e
exemplos dessa informao.

Componentes
Campos
Business
Nome
Entity
Operador
URL
Descrio

Business
Service

Nome

Descrio

Descrio
Nome da entidade
proprietria dos servios
Usurio responsvel pela
gerncia dos servios
URL onde o servio est
disponvel
Descrio do registro UDDI

Armazena o nome do servio

do piPEs-BR/GFD e pode ser
usado como identificador
Descrio sobre o servio

Exemplo
UNIFACS, RNP
Herbert
uddi.unifacs.br
UDDI responsvel por
publicar e descobrir os
servios web da UNIFACS
MA UNIFACS, MP UFSC

Servio de armazenamento de
dados de utilizao

74

Componentes
Campos
Binding
Ponto de
Template
acesso

Descrio

Category Bag Indefinido

tModel

Nome

Descrio
URL do ponto de acesso ao
servio. No piPEs-BR/GFD
essa a principal informao
de acesso
Descrio tcnica do servio

Esse componente possui o

nmero de informaes
armazenadas varivel. A
quantidade de informao
depende do tipo do servio.
Aqui so armazenadas
informaes adicionais
Como o tModel um ndice
seu nome usado como
chave para identificar um
servio. Foram criados
tModels de acordo com as
caractersticas dos servios

Exemplo
http://mu.dante.org.uk:8080
/axis/services

Esse servio funciona atravs

de troca de mensagens
NMWG.
No caso de um Servio do
tipo MA-RRD as informaes
so: IP das interfaces dos
roteadores, capacidade da
interface, o tipo da interface e
o nome da interface.
MA, MP, CLMP, SQL, RRD,
PATH, DELAY, ONEWAY,
ROUTER

Quadro 4.3 - Componentes do UDDI usados no servio de publicao e descoberta do piPEs-BR/GFD

Nota: elaborao do autor (2007).

A Figura 4.3 melhora o entendimento sobre os componentes do UDDI e os seus

relacionamentos, pois mostra a modelagem usada na proposta deste trabalho. Nesta
modelagem possvel ver a entidade proprietria de servios (Business Entity) a qual pode
possuir um ou mais Servios Web em seu registro. J um Servio Web pode ser relacionado
com um ou mais componentes do tipo tModel possibilitando assim o uso de identificadores
(tModel) para categorizar o servio. O Servio Web propriamente dito (Business Service)
possui apenas um componente do tipo Biding Template, pois as informaes de acesso a um
servio no caso do piPEs-BR/GFD so nicas. J o Binding Template pode possuir um ou
mais Category Bags o que permite que um servio tambm possa ser categorizado por mais
de um conjunto de informaes especficas.

75

Figura 4.3 - Modelo de dados

Nota: elaborado pelo autor (2007).

4.5

TAXONOMIAS NOS SERVIOS DE MONITORAMENTO

Para Apte e Mehta (APT; MEHTA, 2002) taxonomia um sistema de categorizao. A qual
denota uma abordagem formal usada para categorizar qualquer conjunto de entidades. Alguns
exemplos de taxonomia so:

a) sistema Norte Americano de Classificao Industrial (do ingls North

American Industry Classification System - NAICS);
b) padro de classificao universal para servios e produtos (do ingls Universal
Standard Products and Service Classification - UNSPSC);

76

c) classificao com base em caractersticas geogrficas (do ingls Geographical

- Geo23).

As taxonomias citadas so normatizadas, ou seja, foram concebidas em forma de normas

internacionais. Elas so comumente usadas para classificar servios disponibilizados por
indstrias, pois foram desenvolvidas especialmente para identificar produtos que na maioria
das vezes so fabricados ou vendidos por essas indstrias. Nos servios de monitoramento
possvel usar algumas das taxonomias normatizadas como a Geographical que normatizada
na ISO 3166 e identifica geograficamente onde o servio est localizado. Assim instituies
de localizaes diferentes podem realizar medies e localizar servios situados em
localizaes diferentes. Essa abordagem pode ser uma analogia ao uso de medies e
mltiplos domnios. Assim, num ambiente mais refinado seria possvel utilizar a taxonomia
geogrfica junto com uma taxonomia prpria que categoriza o Servio Web de acordo com o
domnio a que o mesmo faz parte.

As taxonomias no UDDI so representadas por um conjunto de objetos tModel que formam

uma hierarquia de informaes, onde um tModel pode estar relacionado com outros
possibilitando assim localizar informaes em qualquer nvel da hierarquia. Na Figura 4.4
possvel visualizar um exemplo simples de uma taxonomia reapresentadas por tModels.
possvel observar tambm na figura as informaes contidas nesses tModels. Assim, se um
usurio deseja localizar todos os servios pertencentes ao domnio do NUPERC, s localizar
todos os servios que fazem referncia a esse tModel. possvel ainda saber quais outros
servios esto relacionados com os servios do domnio do NUPERC, pois ao localizar o
tModel NUPERC ser verificado que o mesmo pertence (ou faz referncia) ao tModel RNP.
Esse tipo de abordagem facilita, por exemplo, a medio em mltiplos domnios, pois em uma
medio fim-a-fim que passa por mais de um domnio, possvel localizar os servios
envolvidos nesse caminho, solicitando assim a cada domnio as informaes necessrias para
compor a medio fim-a-fim.

23

Geralmente so usadas as coordenadas geogrficas ou a norma ISO 3166, vide subseo de Categorizao de
servios.

77

Figura 4.4 - Exemplo de relacionamento de taxonomias

Nota: elaborado pelo autor (2007).

Para o Servio de Publicao e Descoberta proposto, foram criadas taxonomias privadas

baseadas nas informaes sobre os Servios Web. Assim foram cridas duas taxonomias, uma
com base na classificao por tipo (seo 4.2.1) e outra com base na hierarquia das
caractersticas de medies em redes de computadores do NMWG (seo 4.2.2). Ao consultar
um servio, o usurio pode utilizar as informaes da classificao do NMWG ou as
caractersticas de tipo dos servios. Por exemplo, possvel localizar um ou mais servios que
fornecem a perda de pacotes em um caminho buscando pelos servios que fazem referncia
aos tModels path, loss e oneWay. Na Figura 4.5 possvel visualizar as taxonomias criadas e as
informaes que as mesmas contm e o relacionamento entre as informaes.

Figura 4.5 - Exemplo das taxonomias criadas

Nota: elaborao do autor (2007).

78

4.6

SERVIO DE PUBLICAO E DESCOBERTA PROPOSTO

As informaes apresentadas nas sees anteriores possibilitam realizar a definio de um

Servio de Publicao e Descoberta para infra-estruturas de monitoramento. Essas
informaes tambm possibilitam observar que o servio proposto ir utilizar o padro para a
Publicao e Descoberta de Servios Web (UDDI). O servio proposto ir disponibilizar duas
taxonomias para ajudar na consulta de servios e distribuir nos componentes do UDDI as
informaes necessrias para acessar e identificar os Servios Web da infra-estrutura de
monitoramento piPEs-BR/GFD.

Contudo, outros pontos devem ser relatados, como os requisitos do piPEs-BR/GFD, a

definio clara das funcionalidades do servio, o design interno do servio e a interface de
acesso ao servio. Alguns desses pontos tambm esto citados na introduo deste trabalho,
pois os mesmos fazem parte das motivaes, justificativas e objetivos.

4.6.1 Requisitos do piPEs-BR/GFD

Com a experincia no desenvolvimento da infra-estrutura de monitoramento piPEs-BR e a

adaptao do piPEs-BR para seguir as definies do documento GFD, alguns requisitos foram
demandados para a definio do Servio de Publicao e Descoberta do piPEs-BR/GFD.
Esses requisitos vo desde os requisitos bsicos como a prpria publicao e descoberta at
requisitos

como:

facilidade

de

acesso,

bom

desempenho,

interfaces

amigveis,

interoperabilidade com outras infra-estruturas e utilizao em domnios administrativos

diferentes.

O principal requisito a ser atendido pelo Servio de Publicao e Descoberta o que se pode
chamar de requisitos bsicos que so: registrar, consultar, remover e alterar os Servios Web
disponibilizados pela infra-estrutura piPEs-BR/GFD. Para atender essas demandas pode ser
utilizado o padro UDDI, pois o padro define essas funcionalidades e tantas outras mais.

79

Um problema observado no uso do padro UDDI o fato de os usurios terem que possuir
um conhecimento interno da tecnologia para poder utilizar suas funcionalidades. Para
solucionar esse problema preciso elaborar uma biblioteca de acesso ao UDDI que facilite
para os usurios o acesso ao mesmo. O UDDI pelo fato de ter sua nomenclatura prpria de
seus componentes como: bindingTemplate, serviceDetail, InstanceDetails, InstanceParms,
TModelInstanceDetails, BusinessService e BusinessList, pode assustar os usurios dos
servios de medio. Os usurios de medies esto acostumados com nomes de ferramentas,
mtricas e tcnicas de medio como: Access point, network characteristic, event type,
interface, parameters, delay, oneway e etc. Contudo, preciso elaborar uma biblioteca que
abstraia os nomes dos componentes do UDDI e apresente para os usurios termos j
conhecidos.

Outra funcionalidade dessa biblioteca a criao de mecanismos de consultas que tambm

vo abstrair os mtodos de consultas disponibilizados pelas tecnologias que implementam o
UDDI. Ou seja, sero criados diversos tipos de consultas para tentar atender todas as
possibilidades de combinao de dados e utilizao das taxonomias disponveis. Com essa
biblioteca o usurio ser capaz de registrar servios, consultar servios e remover servios
registrados de uma forma mais amigvel.

Outro requisito do piPes-BR/GFD de um bom desempenho em relao ao tempo de resposta

pelo Servio de Publicao e Descoberta, pois os principais usurios do servio de Publicao
e Descoberta sero clientes de visualizao de dados e esse tipo de aplicao geralmente
usada pelos usurios das redes. Logo, um cliente de visualizao que interage com a infraestrutura piPEs-BR-GFD alm dos acessos ao Servio de Publicao e Descoberta ir utilizar
outros servios da infra-estrutura. Contudo, se o servio possuir um baixo desempenho poder
ocasionar um descontentamento por parte do usurio.

Finalizando os requisitos do piPEs-BR/GFD possvel citar a operao em domnios

diferentes, ou seja os Servios de Publicao e Descoberta implantados em mltiplos
domnios devem interagir uns com os outros, possibilitando a localizao de servios em
domnios diferentes e conseqentemente possibilitando realizar medies num caminho fima-fim que passa por um ou mais domnios. O prprio fato de estar seguindo as definies do
GFD, o qual transforma em mdulos os componentes da infra-estrutura e transforma as
funcionalidades da infra-estrutura de monitoramento em servios, faz com que esse requisito

80

seja atendido. Outra recomendao para possibilitar o alcance em mltiplos domnios

tambm seguir as definies de comunicaes adotadas pelo perfSONAR, a qual utiliza
mensagens XML padronizadas pelo esquema definido pelo NMWG e que foi relatado na
seo 3.2.3. O fato de seguir as definies do perfSONAR possibilita a criao de um novo
Servio de Publicao e Descoberta que pode ser usado tanto pelo perfSONAR quanto pelo
piPEs-BR/GFD. Assim esse servio chamado de Lookup Service UDDI Type. Logo, as
infra-estruturas de monitoramento podem interagir entre si trocando informaes sobre os
seus Servios Web, possibilitando acessar servios de medio disponveis em mltiplos
domnios administrativos (MONTEIRO e outros, 2007).

4.6.2 Funcionalidades

Para atender os requisitos citados anteriormente, o Servio de Publicao e Descoberta deve

possuir funcionalidades bem definidas. Essas funcionalidades so:

a) registro de servios - O servio deve receber solicitaes de registro de

Servios Web. Para prover essa funcionalidade preciso: verificar se o servio
j existe, verificar se a solicitao contm a quantidade mnima de informao
para registro, registrar o servio e responder solicitao com sucesso ou
falha. O registro de servio tambm pode ser considerado uma alterao, pois
ao verificar que o servio j existe, o mesmo considerado uma alterao;
b) consulta de servios - O servio deve receber solicitaes de consultas de
servios. A consulta deve ser realizada por informaes predefinidas que so
utilizadas como identificadores dos servios como: as taxonomias, nomes,
ponto de acesso e etc.;
c) alterao de servios - A alterao do servio considerada um novo registro
de servio, ou seja, ao receber uma solicitao de alterao, ser consultado se
o servio realmente existe. Caso o servio exista, o registro antigo removido
e feito um registro novo;
d) remoo de servios - O Servio de publicao e descoberta deve ser capaz de
receber uma solicitao de remoo, identificar o servio a ser removido e
remover o mesmo. Essa funcionalidade assim como a de consulta deve utilizar

81

ndices para identificar o servio a ser removido. Logo, se a remoo for

apenas de um servio, o identificador a ser utilizado deve ser nico. Ao
pretender remover um grupo de servios possvel utilizar um identificado que
rotule, por exemplo, um grupo de servios. Para isso assim como na consulta
sero usados os mecanismos de identificao como taxonomias e informaes
especficas;
e) disponibilidade dos servios - Para manter uma base atualizada de
informaes sobre servios Web, necessrio verificar se as informaes
registradas pertencem a Servios Web que esto funcionando. Assim, um
usurio ao consultar informaes sobre um Servio Web ter a garantia de que
pelo menos o servio est disponvel. Isso pode ser proporcionado mantendo
um tempo de vida (do ingls lifetime) para os registros, obrigando a todos os
Servios Web se registrarem automaticamente de tempos em tempos. Ou seja,
ao se registrar no Servio de Publicao e descoberta, o Servio Web recebe
um tempo de vida. Assim, para que suas informaes sejam mantidas no
registro, o servio Web deve realizar um novo registro antes que seu tempo de
vida esgote. O servio de publicao e descoberta, por sua vez, deve verificar
periodicamente os tempos de vida esgotados. E ao verificar que um tempo de
vida se esgotou, deve remover as informaes referentes ao respectivo servio
Web;
f) verificao de status - Os usurios do servio de publicao e descoberta
desejam saber se o servio est funcionando a contento. Logo, o servio de
publicao e descoberta deve receber requisies de informaes de status. O
status do servio de publicao e descoberta pode ser verificado de diversas
maneiras. Numa verso inicial, o status ser considerado a disponibilidade da
base de dados e a disponibilidade do prprio servio de publicao e
descoberta em receber requisies e responder mesma. Assim ser feita uma
pequena consulta de servio e, ao verificar o sucesso, o status do servio ser
considerado OK.

82

4.6.3 Projeto do Servio de Publicao e Descoberta

Como j citado anteriormente, o Servio de Publicao e Descoberta ser composto por uma
aplicao principal que o servio propriamente dito, duas interfaces de acesso, o padro web
UDDI e uma base de dados relacional. As interfaces de acesso sero formadas pela biblioteca
de acesso ao servio e a interface de Servio Web no padro perfSONAR. Na Figura 4.6
possvel ter uma viso geral da estrutura do servio proposto de publicao e descoberta.
Sendo que a interface de Servios Web faz parte da aplicao principal e aciona os mtodos
da aplicao para executar a funcionalidade solicitada na requisio.

Figura 4.6 - Estrutura macro do Servio de Publicao e Descoberta proposto

Nota: elaborao do autor (2007).

Por ser uma viso macro, na figura no possvel visualizar o processo que realizado dentro
do servio de publicao e descoberta, ou seja, todo o processo que feito antes de realizar as
operaes no UDDI. Esse processo consiste em: tratamento das mensagens, identificao da
funcionalidade solicitada, criao de objeto, execuo de funes, gerao de log,
manipulao de dados e construo de mensagens. Sendo que no prximo captulo, sero
apresentadas informaes tcnicas do desenvolvimento que detalham melhor esse processo.
Outra questo que pode ser observada na figura o acesso direto ao UDDI via biblioteca de
acesso.

A biblioteca de acesso ao UDDI que tambm faz parte dos resultados deste trabalho tem a
inteno de facilitar e melhorar o desempenho no acesso ao UDDI, pois o acesso via

83

biblioteca possibilita uma comunicao direta do UDDI, onde algumas operaes que so
feitas no servio de publicao e descoberta passam a ser realizadas no usurio. Outra
vantagem a simplificao do acesso, pois a biblioteca tambm abstrai os detalhes tcnicos
do acesso via interface de Servios Web. Esses detalhes tcnicos so dentre outros, as
mensagens XML e a padronizao do NMWG.

4.6.4 Integrao com outras infra-estruturas

Um dos objetivos deste trabalho e uma grande vantagem do servio de publicao e

descoberta proposto, o fato de ele ser inter-opervel com outras infra-estruturas de
monitoramento, ou melhor, inter-opervel com qualquer outra aplicao que deseje consultar
informaes sobre os servios Web do piPEs-BR/GFD. Mas, em relao s infra-estruturas
piPEs-BR/GFD e perfSONAR, a inteno que os usurios das duas infra-estruturas usem o
servio proposto indiferentemente da tecnologia utilizada. Assim no importa para o usurio
se o servio de publicao e descoberta usa uma base de dados XML ou usa o padro UDDI.

Essa inter-operao pode ser alcanada utilizando um padro no acesso aos servios, ou seja,
na interface de acesso. Contudo, existe uma padronizao que define mensagens de requisio
e resposta criadas pelos desenvolvedores do perfSONAR. Essa padronizao utiliza o
esquema criado pelo NMWG para facilitar a manipulao das informaes de medies.
Logo, um servio bem definido tem que ser hbil de reconhecer as mensagens de requisio
referente s suas funcionalidades. Para exemplificar utilizando as mensagens padro do
perfSONAR, o servio de publicao e descoberta proposto poder inter-operar com clientes
tanto do piPEs-BR/GFD como do perfSONAR, pois as mensagens de requisio e respostas
so as mesmas.

4.7

CONSIDERAES

O uso do padro UDDI como base do Servio de Publicao e Descoberta neste trabalho
poupa a definio e desenvolvimento de muitas questes relacionadas. Como exemplo

84

possvel citar o controle na insero dos dados, autenticao, controle de erros e etc. Mas, por
outro lado, existe bastante trabalho a se fazer nas questes que envolvem quais informaes
sobre os servios sero armazenadas, na distribuio das informaes, na criao das
taxonomias e etc. Logo, o trabalho mais intelectual em relao definio do que tcnico
em relao a escolhas de tecnologias e desenvolvimento.

Contudo, com as questes abordadas neste captulo possvel visualizar as funcionalidades e

caractersticas do servio proposto. Para concluir o entendimento sobre o servio podemos
defini-lo como um Servio de Publicao e Descoberta que utiliza o padro UDDI e contar
com duas formas de acesso. Sendo forma de acesso atravs de uma biblioteca que abstrai
detalhes tcnicos e outra via uma interface de Servio Web. Onde a interface Web expe as
funcionalidades do servio via troca de mensagens XML padronizadas pelo perfSONAR.

Mas, para que essa proposta tornasse realidade foi necessrio desenvolver um prottipo que
implementasse as definies contidas neste captulo. Esse prottipo tem o intuito de validar a
proposta deste trabalho e integra os componentes do piPEs-BR/GFD usado como prottipo na
rede da RNP. Assim, no prximo captulo sero relatados os detalhes tcnicos contidos no
desenvolvimento do prottipo do servio de publicao e descoberta proposto neste trabalho.

85

5 PROTTIPO DESENVOLVIDO

Este trabalho aps pesquisar assuntos que envolvem a publicao e descoberta dos Servios
Web de monitoramento, elaborou no captulo anterior, um Servio de Publicao e
Descoberta para Servios Web de monitoramento. Porm, para finalizar o estudo e
disponibilizar uma pesquisa consistente, foi desenvolvido um prottipo com base nas
definies estabelecidas. Neste captulo sero apresentados os detalhes tcnicos do prottipo
desenvolvido, bem como a motivao para o seu desenvolvimento, as tecnologias utilizadas,
testes realizados com o prottipo e as consideraes sobre o que foi desenvolvido e avaliado.

5.1

INTRODUO

Como resultado da pesquisa sobre Publicao e Descoberta de Servios Web de monitorao

de redes, foi desenvolvido um prottipo denominado atualmente por Lookup Service UDDI
Type. Esse prottipo tem como finalidade validar os estudos realizados e comprovar que
possvel realizar a publicao e descoberta de Servios Web para as infra-estruturas piPEsBR/GFD e perfSONAR utilizando o padro UDDI. Outro objetivo desse prottipo integrar o
conjunto de componentes desenvolvidos pelo GT-Medies da RNP da infra-estrutura piPEsBR/GFD. Assim, o GT-Medies pode disponibilizar para a RNP uma verso inicial do
piPEs-BR/GFD, para que possa ser utilizado como prottipo na sua rede.

Contudo, para desenvolver esse prottipo preciso escolher as tecnologias a serem utilizadas,
definir um modelo de dados bsico e desenvolver a aplicao. Algumas tecnologias j foram
abordadas neste trabalho, mas as tecnologias que sero utilizadas foram escolhidas pelo fato
de atender os requisitos do servio proposto. Assim, possvel citar as principais tecnologias
utilizadas tais como: o JUDDI, UDDI4J, JAVA, Apache Axis, Apache Tomcat e outras.
bom lembrar tambm que o desenvolvimento seguir as definies usadas para o
desenvolvimento do perfSONAR. Ou seja, ser utilizada a comunicao via mensagens
padronizadas e a utilizao de funcionalidades semelhantes, onde a complexidade do
prottipo ser mais acentuada no tratamento das mensagens e interao com o UDDI.

86

O prottipo desenvolvido composto por duas implementaes, uma o servio de

publicao e descoberta propriamente dito e a outra a biblioteca de acesso ao UDDI. Logo,
o resultado so duas aplicaes distintas, mas com as mesmas finalidades. Como linguagem
de programao para desenvolvimento dessas duas aplicaes foi escolhida JAVA, devido a
existirem implementaes como bibliotecas, que facilitam e do suporte ao seu
desenvolvimento. Sendo que para o acesso via interface de Servios Web, indiferente para o
usurio qual linguagem de programao e plataforma sejam utilizadas.

A Figura 5.1 apresenta a arquitetura do servio de publicao e descoberta em camadas, onde a

primeira camada a interface com o usurio que feita via Servios Web. J a segunda
camada so as funcionalidades do servio, que no captulo anterior foram bem definidas. Na
figura possvel ver tambm que na camada de Aes, existe a possibilidade de se adicionar
novas funcionalidades, ou seja, mais uma ao. A terceira camada outro produto deste
trabalho, a biblioteca de acesso ao UDDI desenvolvida em JAVA. bom relembrar que uma
aplicao pode utilizar diretamente a biblioteca de acesso ao UDDI e eliminar as duas
primeiras camadas. Mas isso implica num acesso sem o padro perfSONAR. As trs camadas
citadas anteriormente foram elaboradas e desenvolvidas neste trabalho e fazem parte do
Servio de Publicao e Descoberta proposto. Sendo que as camadas seguintes so
tecnologias existentes que fazem parte e do suporte ao servio proposto. A quarta camada a
implementao do UDDI da Apache Foundation, o JUDDI e na quinta camada est base de
dados relacional proporcionando todas as funcionalidades de armazenamento de dados.

87

Figura 5.1 - Arquitetura do Servio de Publicao e Descoberta

Nota: elaborao do autor (2007).

5.2

DESCRIO E DESENVOLVIMENTO DO PROTTIPO

Nesta seo apresentada a descrio do desenvolvimento do prottipo proposto. Esse

prottipo est dividido em duas implementaes, uma o servio propriamente dito (Lookup
Service UDDI Type - LS-UDDI) e o outra a biblioteca de acesso ao UDDI. Essa seo
tambm nomeia o Servio de Publicao e Descoberta desenvolvido de Lookup Service UDDI
Type (LS-UDDI), essa atitude para significar que o Servio de Publicao e Descoberta
tambm pode ser utilizado na infra-estrutura perfSONAR, que nomeou o seu servio de
Lookup Service XML Type (LS-XML). Isso possvel, pois ambos os servios seguem o
mesmo padro de comunicao e utilizam as mesmas mensagens de comunicao, alm de
possui tambm as mesmas funcionalidades.

88

5.2.1 Lookup Service UDDI Type - LS-UDDI

O desenvolvimento seguindo o padro utilizado no perfSONAR consiste na construo de um

servio genrico. A inteno de se desenvolver um servio genrico de criar um servio que
possa ser implementado e estendido para qualquer tipo de servio especfico como o Ponto de
Medio, Servio de Armazenamento e o prprio Servio de Publicao e Descoberta. Assim,
os desenvolvedores dos servios especficos podem reutilizar o cdigo, o que facilita e acelera
o seu desenvolvimento.

Contudo, a estrutura de qualquer componente do perfSONAR ou piPEs-BR/GFD

semelhante, s diferindo nas aes realizadas. Na Figura 5.2 possvel ver o diagrama de
componentes do servio genrico definido no perfSONAR. A figura mostra seis
componentes, sendo que quatro so considerados principais e dois como componentes de
ajuda.

Figura 5.2 - Diagrama de componentes do padro perfSONAR

Nota: elaborao do autor (2007).

Os componentes principais so:

a) RequestHandler - uma classe que implementa o servio Web propriamente

dito. Ela possui um mtodo chamado acceptCall(), que recebe os Documentos
XML (org.w3c.DOM.Document) que enviado pelos usurios. Essa classe
responsvel por acionar os componentes seguintes que realizam as operaes
do Servio de Publicao e Descoberta. No final, esse componente retorna para

89

o usurio tambm um Documento XML (org.w3c.DOM.Document) com a

resposta da requisio;
b) MessageHandler - um componente utilizado para construir um objeto com
as caractersticas do tipo de servio que est sendo solicitado na mensagem.
Como j dito anteriormente, um servio no perfSONAR considerado de certa
forma genrico, ou seja, ele comum para qualquer mdulo (ponto de
medio, mdulo de armazenamento, publicao e descoberta e etc.) do
perfSONAR. Sendo que durante a seqncia lgica do software, identificado
que tipo de mdulo a requisio est solicitando. Para ser mais claro, na
mensagem de requisio existe um item que informa que servio est sendo
solicitado, que, por exemplo, podem ser publicao e descoberta, ponto de
medio, armazenamento e etc. E o MessageHandler responsvel por criar
um objeto (mensagem) que possui as caractersticas para o tipo de servio
solicitado. Lembrando que esse objeto construdo com o auxlio do esquema
NMWG;
c) ServiceEngine - A principal atribuio do ServiceEngine acionar a
funcionalidade que est sendo solicitada na mensagem. Aps a identificao de
que servio (ponto de medio, mdulo de armazenamento, publicao e
descoberta e etc.) est sendo requisitado, necessrio identificar qual
funcionalidade desse servio tambm est sendo solicitada. O ServiceEngine
faz essa identificao e aciona a funcionalidade desejada;
d) InformationReader - um componente utilizado para consultar em base de
dados algumas informaes referentes funcionalidade. Ou seja, se existe uma
caracterstica especfica que utilizada durante o processo do servio, essa
informao

pode

ser

armazenada

consultada

pelo

componente

InformationReader.

E os componentes de ajuda so:

a) Property Reader - responsvel por ler em arquivos de configurao as

propriedades do respectivo servio, ou seja, recuperar em arquivos
informaes do tipo: localizao de bibliotecas, informao e conexo a base
de dados e etc;

90

b) Logging - Realiza a construo de arquivos de Log onde so gerados registros

de eventuais acontecimentos durante a execuo do software. O Log dividido
em cinco nveis. No Quadro 5.1 possvel ver esses nveis e suas informaes.

Nvel
1
2

3
4
5

Nome
Info

Descrio
Usado para orientar os usurio e desenvolvedores em relao s operaes
realizadas pela aplicao
Debug Utilizado pelos desenvolvedores no auxlio ao desenvolvimento. Serve
como artifcio de programao e ajuda na localizao de falhas nos
algoritmos, para verificar a seqncia de um algoritmo e etc.
Warn So sinais de avisos que no so considerados erro. Exemplo, uma tentativa
de conexo invlida, que pode ser uma tentativa de invaso
Erro
Relata os erros ocorridos, como: falha na conexo da base de dados, falha
no servio, falha nas informaes de configurao e etc.
Fatal Erro fatal registro de quando a aplicao parou inesperadamente, ou teve
que ser finalizada.

Quadro 5.1 - Nveis de Log do sistema

Nota: elaborao do autor (2007).

A Figura 5.3 proporciona um melhor entendimento das funcionalidades de cada componente.

Essa figura traz um diagrama de seqncia referente estrutura do Servio de Publicao e
descoberta proposto com uma analogia ao servio genrico. Contudo, preciso salientar que
esse diagrama foi construdo com base no diagrama do servio genrico, logo para cada
servio especfico, o mesmo pode ser alterado de acordo com as caractersticas do servio
especfico. O fluxo representado na figura pode ser descrito assim:

a) a requisio recebida pelo componente requestHandle. Sendo que a

requisio um documento XML (org.w3c.DOM.Document) que convertido
em objetos atravs de Parser XML24. Ento, o requestHandle utiliza o
dispositivo MessageHandle Factory para identificar o tipo de mensagem
(armazenamento, ponto de medio, armazenamento e etc.) e construir um
objeto do tipo MessageHandler com as informaes contidas na mensagem.
Finalizando o componente requestHandle aciona o MessageHandle passando o
objeto MessageHandler. No cenrio deste trabalho possvel dizer que o
requestHandle identificou que a mensagem para o servio de publicao e
descoberta;
24

O Parser XML tem como funo principal validar um documento XML, podendo tambm utilizar como
parmetro de validao um XML Schema. utilizado tambm para criao de objetos de acordo com estrutura
do documento XML.

91

b) agora necessrio identificar que tipo de funcionalidade do Servio de

Publicao e Descoberta a requisio est solicitando. Assim, o componente
MessageHandler ao manipular a mensagem e identificar o tipo da requisio
(consulta, insero, remoo e etc.), utiliza o dispositivo ServiceEngine
Factory que faz parte do componentes ServiceEngine, para criar um objeto do
tipo ServiceEngine apropriado (com as informaes especficas contidas na
solicitao) e acionar o componente ServiceEngine apropriado. Para
exemplificar possvel dizer que nesse passo onde os servios especficos
(armazenamento, ponto de medio, armazenamento e etc.) comeam a
aparecer. Pois, ao identificar o tipo de solicitao criado o objeto
ServiceEngine referente ao servio especfico. E o ServiceEngine que
executar as funes necessrias para atender funcionalidade solicitada;
c) o Componente ServiceEgine por sua vez tenta invocar as funes referentes
(consulta, insero, remoo e etc.) informao contida no objeto que foi
recebido o ServiceEngine. O Componente ServiceEngine tambm pode acionar
o Componente InformationReader, para saber se existe alguma informao
especfica a ser passada na hora de invocar as funcionalidades desejadas. o
Componente ServiceEngine que tambm ir decidir se a resposta a ser enviada
para o usurio o resultado da solicitao ou uma mensagem de erro;
d) ao tentar invocar uma ao o ServiceEgine aciona as classes de acesso ao
UDDI de acordo com a ao solicitada. Essas classes utilizam a biblioteca de
acesso desenvolvida para acessar de fato o UDDI atravs da funo Inquiry().

92

Figura 5.3 - de seqncia do Servio de Publicao e Descoberta

Fonte: ZURAWSKI e outros (2007).

Para finalizar, os componentes que envolvem o servio, com o resultado de suas solicitaes,
compem a mensagem que ser enviada como resposta para o usurio. Assim, cada
componente incorpora na mensagem as informaes que fazem parte de suas funcionalidades.
No final, essa mensagem convertida em um documento XML para que possa ser enviada
para o usurio.

5.2.2 Biblioteca de acesso ao UDDI

A biblioteca de acesso ao UDDI foi desenvolvida em JAVA utilizando alguns dos

mecanismos das linguagens de programao orientada a objetos. Isso tudo para facilitar a
manipulao das informaes por parte dos usurios dos servios de medies. A biblioteca
possui uma estrutura formada por objetos que fazem um mapeamento das informaes
contidas no esquema do NMWG para informaes de medies em redes de computadores.
Na Figura 5.4 possvel ver esse mapeamento, onde esquerda se encontra um exemplo de
uma mensagem definida com o esquema NMWG e direita essas informaes armazenadas

93

na estrutura de componentes do padro UDDI. Logo, os principais objetos da biblioteca so:

service, metadata e data.

Figura 5.4 - Mapeamento da mensagem NMWG nos componentes do UDDI

Nota: elaborao do autor (2007).

Assim, como o Servio de publicao e Descoberta, a biblioteca de acesso disponibiliza as

seguintes funcionalidades:

a) publish - Conhecida como Registro no LS UDDI Type, responsvel por

publicar os servios no UDDI;
b) unpublish - a remoo dos servios publicados;
c) find - Localizao dos servios;
d) change - Alterao de um servio j publicado.

Para acionar as funcionalidades do JUDDI, a Biblioteca de acesso utiliza outra biblioteca

denominada UDDI4J. A UDDI4J disponibiliza uma interface que abstrai a conexo com o
UDDI, mas ela segue o padro definido pelo UDDI. Ou seja, utiliza os componentes do

94

UDDI, junto com a nomenclatura desses componentes. Isso pode dificultar o entendimento
por parte do usurio. Logo, a biblioteca proposta neste trabalho utiliza termos conhecido pelos
usurios de servios de medies como nome de ferramentas e mtricas.

Como a biblioteca foi desenvolvida para simplificar para os usurios, foi decido desenvolver
somente trs mtodos que podem ser acessados pelos usurios. O primeiro mtodo o mais
importante e denominado de findService. O mtodo findService como a traduo de seu
nome j diz, utilizado para realizar a descoberta de Servios Web. Para realizar a descoberta
o findService recebe como parmetros at 6 valores que so:

a) lsKey - Possibilita a consulta pelo identificador do perfSONAR;

b) uddiKey - Possibilita a localizao de um servio atravs da chave fornecida
pelo UDDI;
c) type - Possibilita a busca por tipo de servio. Recorda-se que essa busca utiliza
os objetos tModel do padro UDDI;
d) name - Possibilita a busca pelo nome do servio;
e) id - Possibilita a busca por informaes contidas em taxonomias como:
caracterstica de rede e outras;
f) keepAlive - Possibilita a busca de servio com o tempo de vida invlido.

Ainda falando sobre o mtodo findService, se o mesmo no receber nenhum parmetro

assume que a consulta deve retornar todos o servios contidos no repositrio. Outro mtodo
importante o publishService, que recebe como parmetro um objeto do tipo Service que est
descrito na Figura 5.5. O publishService fornece as funcionalidades de publicao e alterao
do servio. Assim, se o servio que o usurio pretende publicar j existir no registro, o
mtodo publishService considerar que se trata de uma alterao.

95

Figura 5.5 - Diagrama de classe bsico para a biblioteca de acesso ao UDDI

Nota: elaborao do autor (2007).

O terceiro e ltimo mtodo o unPublishService, que recebe como parmetro um

identificador do UDDI ou do perfSONAR para realizar a remoo de um servio especfico.
Ou seja, para remover um Servio Web preciso saber a sua identificao. Caso o usurio
no possua a identificao, o usurio deve realizar uma consulta prvia para receber essa
identificao.

Na Figura 5.6 possvel ver o acesso ao servio utilizando a biblioteca, bem como a arquitetura
dessa biblioteca. J a Figura 5.5 mostra o diagrama de classes da biblioteca. Essas duas figuras
possibilitam o entendimento do funcionamento da biblioteca. Outro exemplo que pode ajudar

96

no entendimento do uso da biblioteca o trecho de cdigo no APNDICe A que mostra a

utilizao da biblioteca na publicao de um servio.

Figura 5.6 - Arquitetura da biblioteca de acesso ao UDDI

Nota: elaborao do autor (2007).

O Servio de Publicao e Descoberta foi desenvolvido e pode ser obtido no site do GTMedies. Onde possvel encontrar tambm explicaes sobre o mesmo. possvel tambm
obter no site o cdigo fonte da primeira verso do servio e assim desenvolver novas
funcionalidades ou at mesmo usar como mtodo de aprendizagem no uso do UDDI e
perfSONAR.

Finalizando, para validar o prottipo desenvolvido necessrio realizar testes. Com esses
testes possvel verificar se todas as funcionalidades desenvolvidas esto sendo
implementadas a contento, alm de verificar tambm o comportamento do software em uma
possvel utilizao em produo, pois o intuito tambm desse prottipo integr-lo infraestrutura que ser implantada na RNP. Na prxima seo sero apresentados os testes
realizados no prottipo do Servio de Publicao e Descoberta proposto.

97

5.3

TESTES

5.3.1 Cenrio de teste n 1

Para testar o prottipo desenvolvido, foram usados dois cenrios. O primeiro cenrio foi
implantado num laboratrio em uma rede local sem muita interferncia de trfego externo.
Esse cenrio foi escolhido por dois motivos. O primeiro motivo o fato de testar o prottipo
numa ambiente controlado. O segundo motivo de existir a possibilidades de realizar os
mesmos testes com o servio de publicao e descoberta do perfSONAR o Lookup Service
XML Type, que utiliza outros mtodos e assim poder comparar o resultado entre os dois
servios. Na Figura 5.7 possvel ver o cenrio de testes 1.

Figura 5.7 - Cenrio de testes n 1

Nota: elaborao do autor (2007).

Ainda sobre o cenrio de testes n 1, possvel dizer que o mesmo consistiu em testar as
funcionalidades de remoo, publicao e alterao. A consulta no foi relacionada devido ao
fato de que nas trs funcionalidades citadas a consulta realizada automaticamente, pois
preciso localizar o servio antes para poder remover e alterar. J na insero, a consulta
realizada para verificar se o servio j existe. Assim, foi desenvolvida uma aplicao cliente
que requisita essas funcionalidades no servio de publicao e descoberta utilizando a
interface de Servios Web no padro perfSONAR.

Essa aplicao bastante simples, antes de realizar a solicitao marcado o instante de

tempo inicial e ao receber a resposta do servio marcado o instante de tempo final. Com os
dois resultados em mos s verificar o tempo que levou para que a aplicao fosse atendida

98

pelo Servio de Publicao e Descoberta. No Figura 5.8 possvel ver na linguagem de

programao JAVA a simplicidade do teste.

Figura 5.8 - Cdigo usado na aplicao de testes do cenrio n 1

Nota: elaborao do autor (2007).

Outro ponto importante a ser citado no cenrio n 1 em relao s informaes que foram
usadas nas requisies. O teste que relatado neste trabalho utilizou as informaes referentes
ao servio de armazenamento de dados de medies o Measurement Archive (MA). Para ser
mais especfico, o tipo de MA utilizado foi o MA-RRD que armazena dados de utilizao de
enlaces dos dispositivos de redes (ex. roteador) em uma base de dados RRD. Assim, no caso
especfico dos dados de utilizao, quanto mais enlaces, maior a quantidade de informao a
ser armazenada, pois no esquema NMWG para dados de utilizao, cada interface de rede dos
dispositivos deve estar representada na mensagem. A mensagem utilizada no teste possui um
objeto Metadata que descreve as informaes genricas do servio e um objeto Data para
cada interface de rede que faz parte da coleta de dados de medio. Ou seja, caso um MA
esteja armazenando dados de utilizao de dez roteadores e cada roteador possuir cem
interfaces, a mensagem de registro que deve ser enviada para o Servio de Publicao e
Descoberta deve conter um Metadata e mil objetos Data representando as interfaces. A
mensagem utilizada no teste pode ser visualizada no APNDICe A.

5.3.2 Cenrio de teste n 2

O segundo cenrio testa o Servio de Publicao e Descoberta na rede da RNP e tem o intuito
de verificar como o servio se comporta, publicando e descobrindo Servios Web funcionais
implantados na RNP. Assim possvel verificar com os usurios o nvel de satisfao em
relao publicao e descoberta. Para o teste no backbone da RNP foi utilizada a infra-

99

estrutura disponibilizada por projetos pilotos como o infra-estrutura compartilhada entre

Europa e Amrica Latina (EELA, do nome em ingls). O GT-Medies foi requisitado pela
RNP para implantar parte da sua infra-estrutura de monitoramento para fornecer alguns dados
de medies nas redes que participam do projeto EELA. Na Figura 5.9 possvel ver detalhes
do cenrio n 2, nesta figura esto representados os Pontos de Medio implantados, o
Servio de Publicao e Descoberta e o Servio de Armazenamento dos dados de medio.
Nesta figura tambm possvel visualizar as redes envolvidas nos testes e quem fazem parte
do projeto piloto do EELA, envolvendo redes europias e latino americanas (RedIRIS,
CLARA, CUDI, UNAM RNP e CIEMAT).

Assim, todos os Servios Web disponibilizados pela infra-estrutura de medio piPEsBR/GFD instalada na RNP foram configurados para se registrarem periodicamente no servio
instalado tambm no backbone da RNP.

Figura 5.9 - Cenrio de testes n 2

Nota: elaborao do autor (2007).

100

Contudo o segundo cenrio proporciona verificar se as funcionalidades do Servio de

Publicao e Descoberta esto sendo fornecidas, desde as funcionalidades principais como o
registro, remoo, alterao, consulta e keepalive, at as funcionalidades como
gerenciamento, sistemas de log e outros. Esse teste tambm possui a finalidade de validar a
verso desenvolvida, mostrando que ela pode ser usada. Outro benefcio desse teste ajustar a
configurao do servio e observar coisas do tipo: qual o intervalo de tempo que deve ser
utilizado para verificar os tempos de vida dos servios registrados e realizar a remoo dos
servios inativos, verificar se os servios esto se registrando continuamente e em um tempo
satisfatrio para que seu registro no seja removido e etc.

Na Figura 5.9 possvel ver tambm que os componentes da infra-estrutura piPEs-BR/GFD

esto espalhados pelas redes onde o maior nmero de componentes so os pontos de medio
do tipo de linha de comando o CL-MP. Outros componentes so os mdulos de
armazenamento que armazenam os dados medidos por esses pontos. Assim, todos esses
componentes foram configurados para realizar a publicao de suas informaes de acesso no
Servio de Publicao e Descoberta situado em Salvador. Assim, foram obtidos resultados
que sero explicados e comentado na prxima seo.

5.4

AVALIAO DOS RESULTADOS

Uma das motivaes de realizar os testes no cenrio n1, foi o fato de j existir um teste desse
tipo com o Lookup Service XML Type do perfSONAR (LS-XML). Nesse teste os
desenvolvedores do perfSONAR identificaram um problema que pode ser considerado grave.
O desempenho do LS-XML com uma quantidade pequena de informaes se demonstrou
satisfatrio, mas medida que a quantidade de informao foi crescendo, o desempenho do
servio caiu drasticamente. Lembrando que o teste foi realizado com mensagens com
informaes sobre o servio de armazenamento de dados de utilizao dos dispositivos de
redes (MA-RRD) e que o aumento de informao causado pelo aumento do nmero de
interfaces dos dispositivos monitorados, o que comum em um backbone com muitos
roteadores.

101

Assim que esses resultados foram divulgados, os desenvolvedores direcionaram sua ateno
para o desempenho da outra aplicao para a Publicao e Descoberta que pode ser utilizada
no perfSONAR e que tambm o resultado deste trabalho. Assim, os mesmos testes foram
realizados no Servio de Publicao e Descoberta do piPEs-BR/GFD, o Lookup Service
UDDI Type (LS-UDDI). E os resultados, apesar de serem esperados, comprovaram uma das
justificativas para a realizao deste trabalho que o bom desempenho do servio. A Figura
5.10

mostra graficamente os resultados dos testes realizados. Foram realizados sete testes para

as funcionalidades de publicao, alterao e remoo, onde a cada teste ocorreu uma

elevao na quantidade de informao. O primeiro teste foi realizado com uma mensagem de
MA-RRD com apenas uma interface e consecutivamente com um objeto Metadata e um
objeto Data. J no segundo teste a quantidade de interfaces foi aumentada para dez e
conseqentemente o nmero de objetos Data mudou para dez. O terceiro teste com 50
interfaces e assim por diante, at chegar ao stimo teste que utilizou mil interfaces. Os dados
coletados podem ser vistos no apndice dD.

Figura 5.10 - Comparao de desempenho entre o LS-UDDI e o LS-XML

Nota: elaborao do autor (2007).

102

O testes mostram que na publicao de servios ambas as implementaes obtiveram

resultados semelhantes, mas nas operaes de alterao e remoo, o LS-UDDI medida que
a quantidade de informaes aumenta se demonstrou mais veloz do que o LS-XML. Existem
duas explicaes que se complementam para esses resultados. A primeira o fato das bases
de dados relacionais serem comprovadamente mais rpidas do que as bases XML, isso
devido ao uso de mecanismos como ndices e relacionamentos das bases relacionais. A
segunda explicao que a partir do momento em que se envolve a consulta de servios na
operao, o LS-UDDI com sua base de dados relacional possui um desempenho melhor. Ou
seja, na publicao de servio existe uma consulta que para verificar se o servio j existe,
mas essa consulta relativamente simples. J na remoo e alterao de um servio tambm
existe a consulta de servios, mas a complexidade aumenta medida que a quantidade de
objetos Data aumenta.

Ao remover ou alterar um servio com o LS-XML, a base de dados XML ao localizar o

Metadata correspondente ao servio que ser alterado ou removido, precisa localizar tambm
os objetos Datas que pertencem tambm ao servio. No caso de somente uma interface, a
busca realizada pela base XML por apenas um objeto Data na base de dados. No caso de
mil interfaces, a base XML tem que localizar mil objetos Datas, o que extremamente
dispendioso para esse tipo de base que no possui os mecanismos utilizados por uma base de
dados relacional. Como pode ser visto no Apndice bB, a base XML apenas usa uma
informao de identificao (ID) para relacionar os objetos Data com os Metadatas. Assim,
toda vez que for necessrio localizar um objeto Data preciso percorrer toda a base de dados
procura do objeto com o ID correspondente.

J os testes realizados no cenrio n 2 comprovam que todas as funcionalidades desenvolvidas

no Servio de Publicao e Descoberta proposto esto sendo cumpridas, pois os usurios das
ferramentas de medio ao tentarem localizar os servios das infra-estruturas piPEs-BR/GFD
reportaram sucesso na operao, comprovando assim a dinamizao no uso dos servios Web.
Outro resultado obtido com os testes realizados foi o perfeito funcionamento do sistema de
Log, o qual reportou satisfatoriamente todas as vezes que foi acionado. O sistema de Log
gerou um histrico das operaes realizadas sobre o Servio de Publicao e Descoberta,
reportou tambm os erros ocorridos o que ajudou na configurao dos clientes em relao ao
uso errados das mensagens ou na forma de acesso.

103

Utilizando ferramentas de visualizao e at mesmo consultando a base de dados foi possvel

verificar que todos os servios web da infra-estrutura pipEs-BR/GFD instalados no backbone
da RNP se registraram com todas as informaes desejada no servio. Foi possvel verificar
tambm a eficincia do sistema de keepalive, pois por problemas de hardware alguns pontos
de medio durante o perodo de teste pararam de se registrar no Servio de Publicao e
Descoberta e foram automaticamente removidos aps o trmino dos seus tempos de vida.

Um teste importante que foi realizado, mas no utilizou nenhum tipo de cenrio foi o teste da
biblioteca de acesso ao UDDI. A ferramenta de visualizao Internet Computer Eye (ICE)
tambm desenvolvida pelo GT-Medies da RNP realiza a descoberta de servio atravs das
duas interfaces ficando a escolha a critrio do usurio. Os testes de acesso na localizao dos
servios atravs da biblioteca tambm foram satisfatrios, pois a ferramenta ICE no
apresentou nenhum problema na sua utilizao. No apndice cC so apresentadas algumas
telas que mostram a interface de acesso ao LS-UDDI no ICE.

Em relao avaliao das tecnologias utilizadas, importante comear com a aplicao base
o JUDDI. O JUDDI se demonstrou uma aplicao bastante estvel, pois nos testes realizados
aps a sua instalao no ocorreu nenhum problema. Outro fato importante de ressaltar que
o JUDDI implementa realmente todas as funcionalidades do padro UDDI na sua verso
nmero dois, pois utilizamos um cliente de acesso a qualquer implementao do padro
UDDI chamado de UDDI Browser25 que mostra todas as funcionalidades disponveis na
implementao do UDDI ao qual est sendo feito o acesso. Foi testado no JUDDI tambm o
sistema de autenticao o qual feito por usurio e senha registrados no prprio JUDDI.
Logo, o JUDDI apesar de s implementar a verso dois do padro UDDI, pode ser utilizado
tranqilamente para a Publicao e Descoberta de Servios Web de monitoramento. As outras
tecnologias so bastante conhecidas nos cenrios de medio e dispensam avaliaes como: a
Apache Axis, Apache Tomcat, JAVA e outras.

25

Interface grfica de acesso ao UDDI desenvolvida em JAVA.

104

6 CONSIDERAES FINAIS

Neste captulo so apresentadas as concluses obtidas com a realizao deste trabalho.

Portanto possvel dizer que este trabalho contribuiu para a descoberta de como utilizar o
conceito de Publicao e Descoberta de Servios da arquitetura SOA e o padro UDDI no
escopo das infra-estruturas de monitoramento de redes de computadores. Este captulo
tambm apresenta as contribuies efetivas deste trabalho, bem como as possibilidades de
continuao da pesquisa como trabalhos futuros.

6.1

CONCLUSO

Na introduo deste trabalho foram levantadas questes que comprovam a necessidade de um

Servio de Publicao e Descoberta para auxiliar os usurios de Servios Web das infraestruturas de monitoramento. Pois os usurios dos Servios Web possuem as seguintes
demandas: acessar dinamicamente os Servios Web, alcanar Servios Web em domnios
administrativos diferentes e possibilidade de realizar a escolha do Servio Web a ser utilizado.
Essas questes instigam a realizao de uma pesquisa para saber como utilizar a Publicao e
Descoberta no cenrio dos Servios Web de monitoramento. O que direciona a pesquisa para
a tentativa de utilizar o padro web UDDI para Publicao e Descoberta de Servios Web nas
infra-estruturas de medies para auxiliar os seus usurios. Assim, no Captulo 2 foram
apresentadas as possveis tecnologias e padres que podem ser usados na soluo dos
problemas relatados. Logo, este trabalho focou seus esforos na soluo desses problemas
com o intuito de planejar, desenvolver e testar um Servio de Publicao e Descoberta com
essas caractersticas.

Mas antes do planejamento, foi preciso verificar as principais infra-estruturas de

monitoramento e observar o que essas infra-estruturas j possuem ou pretendem em relao
Publicao e Descoberta de Servios. Assim, no Captulo 3 foi verificado que poucas infraestruturas de monitoramento utilizam um servio para disponibilizar informaes sobre
Servios Web e as que os possuem optaram ou por desenvolver seu prprio servio ou utilizar

105

uma soluo que resolva somente as necessidades internas da infra-estrutura. Como exemplo
podemos citar o perfSONAR e a MonALISA onde, respectivamente, uma desenvolveu um
novos servio e a outra utilizou uma tecnologia que no possibilita que os servios sejam
acessados por aplicaes externas.

Contudo, com os resultados obtidos na pesquisa, ficou comprovada a possibilidade de se usar

o padro UDDI no cenrio de medies em redes de computadores utilizando a
implementao JUDDI. Um dos receios em relao ao uso do UDDI para publicao e
descoberta de servio de monitoramento o fato de ter que modificar o cdigo fonte da
aplicao que implementa o UDDI (JUDDI), caso o mesmo no contemplasse todas as
funcionalidades previstas ou funcionalidades futuras. Realmente em relao a novas
funcionalidades que podem aparecer no futuro, o padro pode no contemplar e a necessidade
de se alterar o cdigo fonte da implementao seria inevitvel. Assim, essa uma
flexibilidade que o UDDI no possui, mas os estudos comprovam que todas as
funcionalidades previstas para publicao e descoberta de servio web de monitoramento
foram atendidas.

Entretanto, o servio de publicao e descoberta utilizando o padro UDDI demonstrou, nos

testes realizados neste trabalho, que possui um melhor desempenho em relao soluo com
base de dados XML. Isso um fator importante no caso de Servios Web de monitoramento,
pois a tendncia em relao quantidade de informaes sobre os servio sempre de
aumentar, dado que as redes de computadores esto sempre em evoluo seja no aumento da
quantidade de dispositivos que na evoluo nos hardwares instalados. Logo, possvel prever
que a quantidade de informaes que sero armazenadas no servio de publicao e
descoberta ir aumentar medida que as redes evoluem.

Os resultados deste trabalho tambm verificaram que o Servio de Publicao e Descoberta

alm de tornar dinmico o acesso aos Servios Web, faz com que os servios web se tornem
visveis para qualquer usurio. Ou seja, o Servio de Publicao e Descoberta se transforma
em uma vitrine de servios, onde os usurios escolhem o servio que mais lhes agrada. Isso
pde ser verificado a partir das aplicaes cliente com o ICE (vide Apndice A), onde foi
desenvolvido um mdulo para acesso ao UDDI que possibilita uma visualizao dos servios
publicados em uma estrutura de diretrios com as informaes dos servios. Assim, o usurio
poderia escolher nessa estrutura o servio que atende as suas necessidades.

106

6.2

CONTRIBUIES

A principal contribuio deste trabalho a soluo do problema de como utilizar o conceito

de Publicao e Descoberta de Servios da arquitetura SOA e a tecnologia UDDI no escopo
das infra-estruturas de monitoramento. Neste trabalho, foram descritas as caractersticas que
envolvem essa soluo, tendo sido proposto um Servio de Publicao e Descoberta de
Servios Web que atende os requisitos especficos dos Servios Web de monitoramento e o
desenvolvimento de um prottipo que alm de validar o servio proposto, pode ser utilizado
em produo. Um servio de publicao e descoberta com um desempenho no atendimento
das requisies bastante satisfatrio, abrangendo as funcionalidades definidas e que
proporciona outras funcionalidades que melhoram o processo.

Mas esse trabalho contribuiu tambm com outros fatores que sero descritos a seguir. Assim,
outra contribuio a biblioteca de acesso ao UDDI que tambm segue o padro perfSONAR
e torna o acesso mais amigvel para os usurios. A biblioteca pode ser obtida na pgina Web
do GT-Medies e utilizada por qualquer aplicao JAVA que deseja localizar os Servio
Web da infra-estrutura piPEs-BR/GFD.

Contudo, o fato que ser descrito a seguir pode at no ser considerado como uma
contribuio, mas correto afirmar que este trabalho inovador no que diz respeito
Publicao e Descoberta de Servios Web de monitoramento, pois na literatura no existe
registro de pesquisas semelhantes, onde o padro UDDI inserido no cenrio de medies, o
que demonstra a importncia deste trabalho. Esse fato tambm comprova que este trabalho ir
servir como base para outros estudos na rea e at mesmo para dar suporte a outras
tecnologias. Assim, sero relatadas na prxima seo, as possibilidades de continuao da
pesquisa na rea bem como a utilizao do material pesquisado junto com outras tecnologias
que do suporte s infra-estruturas de monitoramento.

107

6.3

TRABALHOS FUTUROS

Como trabalho futuro possvel realizar verificao da verso trs do padro UDDI que
possibilita mltiplos registros do UDDI, ou seja, possibilita montar uma estrutura de registros
UDDI, que descentralizam o servio, aumentando assim a disponibilidade e facilita tambm a
utilizao das infra-estruturas em mltiplos domnios. O uso do UDDI em domnios
diferentes com a sua verso dois possvel, mas ao tentar localizar um servio que faz parte
de um domnio diferente, o usurio teria que utilizar o UDDI desse domnio diferente. Com o
uso da verso trs, os registros UDDI replicam suas informaes entre si possibilitando que o
usurio de um UDDI de um determinado domnio possa localizar o servio de outro domnio
simplesmente perguntando ao UDDI de seu domnio. Logo ele no precisa conhecer os outros
registros que fazem parte das infra-estruturas de monitoramento.

Contudo, como a inteno das infra-estruturas de monitoramento a de operar em domnios

administrativos diferentes, o estudo da verso trs do padro UDDI poderia ser realizado para
verificar se o mesmo atende os requisitos em relao ao uso multidomnios das infraestruturas de monitoramento. E assim torna possvel a evoluo do Servio de Publicao e
Descoberta proposto neste trabalho.

Atualmente a Internet tambm est sendo povoada por uma grande quantidade de servios,
assim tambm surgiu a necessidade de que esses servios interoperem entre si. Outra
necessidade que aparece com essa grande quantidade de servios a escolha correta do
servio, que atende as necessidades do usurio. A localizao de servios remete a um
problema de semntica, pois ao se tentar localizar um servio, geralmente se abstraem as
caractersticas semnticas que envolvem os servios e que os diferenciam. Utilizando somente
o padro UDDI, no possvel atribuir valores semnticos aos servios. Logo existe um
esforo na literatura para estudar a descoberta de servios com base nas funcionalidades
providas pelos mesmos. Paolucci (PAOLUCCI, 2002) afirma que para solucionar este
problema necessrio utilizar uma linguagem que expresse as funcionalidades do servio,
incorporando valores semnticos aos servios. Conseqentemente ele props a utilizao da
linguagem de descrio de servios DAML-S junto com o padro UDDI para atribuir valores
semnticos nas descries dos Servios Web.

108

Logo, como trabalho futuro tambm possvel verificar a utilizao de mecanismos que
atribuem valores semnticos na descoberta de servios para o cenrio dos Servios Web de
monitoramento, melhorando assim a localizao dos servios de acordo com as necessidades
dos usurios. Pois, como j visto neste trabalho, os Servios Web de monitoramento possuem
muitas caractersticas que o identificam e que podem ser utilizadas.

Assim como a semntica, existem outros mecanismos que podem ser utilizados para otimizar
e facilitar o acesso aos servios Web. Um desses mecanismos a Composio de Servios
(SRIVASTAVA; KOEHLER, 2003). A composio de servios basicamente possibilita a
construo de um novo servio a partir de outros servios. Um exemplo clssico para explicar
a composio de servio faz uma analogia a um agente de viagens, o qual compe vrios
servios para proporcionar apenas um servio para o cliente que a viagem. Um agente de
viagens fornece pacotes de viagens para os usurios, por trs desses pacotes o agente de
viagens precisa acionar outros servios para compor o servio final. Assim, o agente rene
servios como: reserva de hotis, compra de passagens, reserva de guias tursticos e passeio,
etc.

Um exemplo da utilizao da composio de servios nas infra-estruturas de monitoramento

pode ser descrito da seguinte maneira: a infra-estrutura de monitoramento proporciona
informaes de medio entre vrios pontos. Um usurio deseja saber a informao de
medio entre dois pontos e no caminho entre esse dois pontos existem vrios servios que
fornecem informaes em partes deste caminho. A infra-estrutura de monitoramento poder
compor com esses servios um servio final que utiliza esses servios intermedirios, para
que o usurio no tenha que consultar todos esses servios no caminho. Logo uma pesquisa
sobre a utilizao de composio de servio nas infra-estruturas de monitoramento faz parte
dos possveis trabalhos futuros dessa dissertao.

109

REFERNCIAS

ALMAER, D. Creating Web Services with Apache Axis. mai. 2002. Disponvel em:
<Http://www.onjava.com/pub/a/onjava/2002/06/05/axis.html>. Acesso em: 14 set. 2006.
ALONSO, G. et al. Web Services: concepts, architectures and applications. 1. ed.
Heidelberg: Springer, 2004, 354 p.
APTE, N.; MEHTA, T. UDDI: Building Registry-based Web Services Solutions. 1. ed.
Upper Saddle River: Prentice Hall, 2002. 448 p. HP Professional Series.
BENNETT, K. et al. Service-based software: the future for flexible software. In: ASIAPACIFIC SOFTWARE ENGINEERING CONFERENCE, 7, 2000, Singapore. Anais p.
214 - 221.
BOOTE, J. et al. Deliverable DJ.1.2.1: GEANT2 General Monitoring Framework Design,
v.5,
jun.
2005.
Disponvel
em:
<
https://wiki.man.poznan.pl/perfsonarmdm/images/perfsonar-mdm/9/95/GN2-05-057v5.pdf>. Acesso em: 15 set. 2005.
BOX, D. et al. Simple object access protocol (SOAP) 1.1, mai. 2000. Disponvel em:
http://www.w3.org/TR/SOAP/>. Acesso em: 10 jan. 2006.
BOYD, E. L. et al. E2E piPEline: End-to-End Performance Initiative Performance
Environment
System
Architecture.
jul.
2002.
Disponvel
em:
<http://e2epi.internet2.edu/e2epipe11.shtml>. Acesso em: 20 ago. 2006.
COLGRAVE, J.; AKKIRAJU, R.; GOODWIN, R. External matching in uddi. In: IEEE
INTERNATIONAL CONFERENCE ON WEB SERVICES, 2, 2004, San Diego. Anais p
226-233.
CURBERA, F. et al. Unraveling the web services web: an introduction to soap, wsdl, and
uddi. IEEE Internet Computing, Los Alamitos, v. 6, n. 2, p. 86-93, mar./abr. 2002.
GUDGIN, M. et al. SOAP Version 1.2 part 1: Messaging Framework. Abr. 2007.
Disponvel em: <http://www.w3.org/tr/soap12-part1> Acesso em: 15 mai. 2007.
HANEMANN, A. et al. Perfsonar: A service oriented architecture for multi-domain network
monitoring. In: INTERNATIONAL CONFERENCE ON SERVICE ORIENTED
COMPUTING (ICSOC), 3, 2005, Amsterdan. Anais Heidelberg: Springer, 2005. p. 241254.
HANEMANN, A. et al. Complementary visualization of perfsonar network performance
measurements. In: INTERNATIONAL CONFERENCE ON INTERNET SURVEILLANCE
AND PROTECTION (ICISP), 1, 2006, Cte dAzur. Anais p. 6-6.
HOFREITER, B.; HUEMER, C.; KLAS, W. ebxml: Status, research issues, and obstacles. In:
INTERNATIONAL WORKSHOP ON RESEARCH ISSUES IN DATA ENGINEERING,
12, 2002, San Jose. Anais p. 57-67.

110

KARN, P.; PARTRIDGE, C. Improving round-trip time estimates in reliable transport

protocols. ACM SIGCOMM Computer Communication Review, New York, v. 25, n. 1, p.
66-74, jan. 1994.
KAWAMURA, T. et al. Public Deployment of Semantic Service Matchmaker with UDDI
Business Registry. In: INTERNATIONAL SEMANTIC WEB CONFERENCE (ISWC), 3,
2004, Hiroshima. Anais Heidelberg: Springer, 2004. p. 752-766.
KOGA, I. K.; SAMPAIO, L.; MONTEIRO, J. A. S. Flavor: A dynamic and open framework
for the development of network measurement access and visualization tools. In: SIMPSIO
BRASILEIRO DE REDES DE COMPUTADORES, 25, 2007, Belm. Anais... p. 665-678
KOGA, I. K. et al. Ice: A flexible network monitoring access environment. In: SIMPSIO
BRASILEIRO DE REDES DE COMPUTADORES E SISTEMAS DISTRIBUDOS, 25,
2007, Belm. Anais p. 1181-188.
LOWEKAMP, B et al. A hierarchy of network performance characteristics for grid
applications and services. Disponvel em: < http://www.ggf.org/documents/GFD.23.pdf>.
Acesso em: mai. 2005.
MARPLES, D.; KRIENS, P. The Open Services Gateway Initiative: An Introductory
Overview. IEEE Communication Magazine. Los Alamitos, v. 39, n. 12, p. 110-114, dez.
2001.
MATTHEWS, W.; COTTREL, L. The PingER project: Active internet performance
monitoring for the HENP community. IEEE Communications Magazine. Los Alamitos,v.
38, n. 5, p. 130-136, mai. 2000.
SOUZA, H. M. et al. Uma infra-estrutura para publicao e descoberta de servios de
monitoramento de rede. In: SIMPSIO BRASILEIRO DE REDES DE COMPUTADORES
E SISTEMAS DISTRIBUDOS, 25, 2007, Belm. Anais... p. 679-692.
NEWMAN, H. B.; LEGRAND, I. C.; BUNN, J. J. A distributed agent-based architecture for
dynamic services. In: COMPUTING IN HIGH ENERGY AND NUCLEAR PHYSICS
(CHEP), 1, 2001, Beijing. Anais p. 3-7.
NEWMAN, H. et al. Monalisa: An agent based, dynamic service system to monitor, control
and optimize grid based applications. In: COMPUTING IN HIGH ENERGY AND
NUCLEAR PHYSICS (CHEP), 4, 2004, Interlaken. Anais p. 87-92.
PAOLUCCI, M. et al. Importing the semantic web in uddi. In: INTERNATIONAL
WORKSHOP ON WEB SERVICES, E-BUSINESS, AND THE SEMANTIC WEB, 2, 2002,
Toronto. Anais Heidelberg: Springer, 2002 p. 225 236.
PAPAZOGLOU, M. Service-oriented computing: Concepts, characteristics and directions. In:
INTERNATIONAL
CONFERENCE
ON
WEB
INFORMATION
SYSTEMS
ENGINEERING (WISE), 4, 2003, Rome. Anais p. 3-12.
PINTO, H.; BOAS, N. V.; JOS, R. Utilizao do uddi no suporte na descoberta de servios
baseados na localizao. In: XML: APLICAES E TECNOLOGIAS ASSOCIADAS
(XATA), 1, 2003, Braga. Anais... p. 13-21.

111

POSTEL, J. Internet Control Message Protocol, mai.

<ftp://ftp.ietf.org/rfc/rfc0791.txt>. Acesso em: 16 jun. 2006.

1981.

Disponvel

em:

ROY, J.; RAMANUJAN, A. Understanding web services. IT Professional, Los Alamitos. v.

3, n. 6, p. 69-73, nov. 2001.
SAMPAIO, L. et al. pipes-br: Uma arquitetura para a medio de desempenho em redes ip.
In: SIMPSIO BRASILEIRO DE REDES DE COMPUTADORES, 24, 2006, Curitiba.
Anais p. 32-43.
SAMPAIO, L.; SURUAGY, J. A. M. A service-based flow traffic measurement management
model for ip networks. In: WORKSHOP ON END-TO-END MONITORING TECHNIQUES
AND SERVICES (E2EMON), 2, 2004, San Diego. Anais p. 55-61.
SRIVASTAVA, B.; KOEHLER, J. Web service composition: Current solutions and open
problems. In: INTERNATIONAL CONFERENCE ON AUTOMATED PLANNING AND
SCHEDULING (ICAPS), 13, 2003, Trento. Anais p. 155-161.
TERGUJEFF, R. et al. Mobile soa: Service orientation on lightweight mobile devices. In:
IEEE INTERNATIONAL CONFERENCE ON WEB SERVICES (ICWS), 5, 2007, Salt Lake
City. Anais p. 1224-1225.
TSAI, W. T. et al. Consumer-Centric Service-Oriented Architecture: A New Approach. In:
INTERNATIONAL
WORKSHOP
ON
COLLABORATIVE
COMPUTING,
INTEGRATION, AND ASSURANCE, 2, 2006, Gyeongju. Anais Washington, DC: IEEE
Computer Society, p. 175-180
TURNER, M.; BUDGEN, D.; BRERETON, P. Turning software into a service. In:
PENNINE RESEARCH FORUM, 1, 2002, Manchester. Anais p.38-44.
WILLIAMSON, C. Internet traffic measurement. Internet Computing IEEE, Manchester, v.
5, n. 1, p. 70-74, nov. 2001.
XIMENES, S. B. Dicionrio da lngua portuguesa. 3. ed. So Paulo: Ediouro Publicaes,
1998.
ZHOU, C. et al. UX - An Architecture Providing QoS-Aware and Federated Support for
UDDI. In: INT. CONF. ON WEB SERVICES, 1, 2003, Las Vegas. Anais p.104-109.
ZURAWSKI, J. et al. Hierarchically federated registration and lookup within the perfsonar
framework. In: INTERNATIONAL SYMPOSIUM ON INTEGRATED NETWORK
MANAGEMENT, 10, 2007, Munich. Anais p. 705-708

112

APNDICE A - EXEMPLO DE UTILIZAO DO UDDI4J

PUBLICAO DE UM SERVIO
\\Cria o objeto Parameters com as informaes de conexo no UDDI
Parameters para = new Parameters();
para.setInquiryURL("http://200.128.80.179:8080/juddi/inquiry");
para.setPublishURL("http://200.128.80.179:8080/juddi/publish");
para.setUserid("herbert");
para.setPassword("xxxxxxx");
para.setTransportClassName("org.uddi4j.transport.ApacheAxisTransport");
para.setLogEnabled("false");
para.setHandlerPackageName("com.sun.net.ssl.internal.www.protocol");
para.setSecurityClassName("com.sun.net.ssl.internal.ssl.Provider");
para.setBusinessName("Sample Business");
para.setServiceName("Sample Service");
para.setTmodelName("Sample TModel");
para.setAssertionRelationship("peer-peer");
para.setBusiness("LS");
\\Cria o objeto Publish para executar a publicao
Publish app = new Publish(para);
\\Cria o objeto principal Service
Service service = new Service();
\\Cria o objeto Metadata que ser inserido no objeto Service
MetaDataService metaData= new MetaDataService();
\\Cria o objeto Data que ser inserido no objeto Service
DataService data= new DataService();
\\Como existe a possibilidade de existir mais de um objeto Data
Vector dataVector = new Vector();
\\Cria os elementos que fazem parte do objeto Data
Element ele = new Element();
Element ele1 = new Element();
Element ele2 = new Element();
Element ele3 = new Element();
\\Insere os parmetros no objeto Metadata
metaData.setAccessPoint("http://200.237.193.2:8080/axis/services/CLMPService","http");
metaData.setServiceDescription("MP comand line");
metaData.setServiceName("mpcl-pop-sc");
metaData.setServiceType("CLMP");
\\Insere os parmetros nos objetos Element

113

ele.setElement("Host Name");
ele.setValue("gtmed-ndt.pop-sc.rnp.br");
ele1.setElement("If Name");
ele1.setValue("eth0");
ele2.setElement("Capacity");
ele2.setValue("100000000");
ele3.setElement("Event Type");
ele3.setValue("utilization");
\\Insere os objetos Element no objeto Data
data.setDataElements(ele);
data.setDataElements(ele1);
data.setDataElements(ele2);
data.setDataElements(ele3);
\\Insere o objeto Data no vetor de Data
dataVector.add(data);
\\Insere os objetos Metadata e Data no objeto Service
servi.setDataService(dataVector);
servi.setMetadataService(metaData);
servi.setLocalizationService("POP-SC");
servi.setKeepAlive("1212121");
\\Executa o mtodo de publicao
app2.publishService(servi);

114

APNDICE B MENSAGEM UTILIZADA NO TESTE DO CENRIO NO 1

MENSAGEM DE REGISTRO DE UM SERVIO DO TIPO MA-RRD

<!-- Purpose: -->
<!-- Version: $Id: LSRegisterRequest.xml 792 2006-02-21 -->
<nmwg:message type="LSRegisterRequest"
id="msg1"
xmlns:perfsonar="http://ggf.org/ns/nmwg/tools/
org/perfsonar/1.0/"
xmlns:nmwg="http://ggf.org/ns/nmwg/base/2.0/"
xmlns:psservice="http://ggf.org/ns/nmwg/tools/
org/perfsonar/service/1.0/"
xmlns:nmwgt="http://ggf.org/ns/nmwg/topology/2.0/"
xmlns:netutil="http://ggf.org/ns/nmwg/
characteristic/utilization/2.0/">
<nmwg:metadata id="serviceLookupInfo">
<perfsonar:subject id="commonParameters" xmlns:perfsonar=
"http://ggf.org/ns/nmwg/tools/org/perfsonar/1.0/">
<psservice:service id="serviceParameters"
xmlns:psservice="http://ggf.org/ns/nmwg/tools/
org/perfsonar/service/1.0/">
<psservice:serviceName>
My_test_MA
</psservice:serviceName>
<psservice:accessPoint>
http://reed.man.poznan.pl:8080/axis/services/MA
</psservice:accessPoint>
<psservice:serviceType>MA</psservice:serviceType>
<psservice:serviceDescription>
This is my testing MA
</psservice:serviceDescription>
</psservice:service>
</perfsonar:subject>
</nmwg:metadata>
<nmwg:data id="data0" metadataIdRef="serviceLookupInfo">
<nmwg:metadata id="meta1">
<perfsonar:subject id="subj1" xmlns:perfsonar=
"http://ggf.org/ns/nmwg/tools/org/perfsonar/1.0/">
<nmwgt:interface xmlns:nmwgt=
"http://ggf.org/ns/nmwg/topology/2.0/">
<nmwgt:hostName>
atlang-hstnng.abilene.ucaid.edu
</nmwgt:hostName>
<nmwgt:ifName>unknown</nmwgt:ifName>

115

<nmwgt:ifDescription>
hstn:oc192(p2p)::show:intracloud
</nmwgt:ifDescription>
<nmwgt:ifAddress type="ipv4">
198.32.8.34
</nmwgt:ifAddress>
<nmwgt:direction>in</nmwgt:direction>
<nmwgt:capacity>10000000000</nmwgt:capacity>
</nmwgt:interface>
</perfsonar:subject>
<nmwg:eventType>utilization</nmwg:eventType>
</nmwg:metadata>
</nmwg:data>
</nmwg:message>

116

APNDICE C CLIENTES DE ACESSO AO PROTTIPO DESENVOLVIDO

INTERNET COMPUTER EYE (ICE)

O ICE possui a funcionalidade de acessar o Servio de Publicao e Descoberta desenvolvido
atravs da biblioteca de acesso ao UDDI. Essa funcionalidade permite a visualizao e
remoo dos Servios Web que esto registrados no Servio de Publicao e Descoberta. A
visualizao disponibilizada em forma de estrutura de diretrios, que segue a estrutura de
informaes do Servio Web. possvel tambm adicionar o Servio de Publicao e
Descoberta que ser acessado. Essas funcionalidades podem ser vistas na Figura 9.1 e Figura 9.2.

Figura 9.1 - Tela de acesso ao Servio de Publicao e Descoberta

Nota: elaborao do autor (2007).

117

Figura 9.2 - Tela de configurao

Nota: elaborao do autor (2007).

UDDI BROWSER
Alm do ICE, outro software foi utilizado para acessar o Servio de Publicao e Descoberta
desenvolvido. O software utilizado foi o UDDI browser, que realiza todas as operaes
disponveis para um UDDI na sua verso dois. Essas operaes so: consulta, insero,
remoo e alterao. Na Figura 9.3 possvel ver o UDDI Browser acessando o Servio de
Publicao e Descoberta.

118

Figura 9.3 - Tela do UDDI Browser

Nota: elaborao do autor (2007).

119

APNDICE D RESULTADOS OBTIDOS NOS TESTES DO CENRIO NO 1

SERVIO DE PUBLICAO E DESCOBERTA LS-UDDI E LS-XML

Tabela 10.1 - Resultado dos testes realizados com o LS-UDDI.
LS-UDDI
INTERFACES
1
10
50
100
200
400
1000

REGISTRAR
0,685
0,862
1,423
2,186
3,923
6,998
19,18

ALTERAR
0,775
0,941
1,89
3,033
5,686
10,999
33,893

REMOVER
0,195
& 0,272
0,635
1,057
1,922
3,904
9,475

Nota: elaborao do autor (2007)

A
Tabela 10.1 e a Tabela 10.2, ajudam no entendimento dos testes realizados no cenrio
de testes n 1. Pois aqui so apresentados os dados coletados nos testes de desempenho entre o
LS-UDDI e o LS-XML.

Tabela 10.2 - Resultado dos testes realizados com o LS-XML.

LS-XML
INTERFACES
1
10
50
100
200
400
1000
Nota: elaborao do autor (2007)

REGISTRAR
0,25
0,3
0,52
3,61
2,49
7,77
10,38

ALTERAR
0,68
4,92
23.49
51,69
112,17
266,95
476,85

REMOVER
0,25
4,34
22,75
49,94
108,83
X
X