Dissertacao Luis Nakamura

Utilizao de web semntica para seleo de
informaes de web services no registro UDDI

uma abordagem com qualidade de servio
Luis Hideo Vasconcelos Nakamura
SERVIO DE PS-GRADUAO DO ICMC-USP
Data de Depsito:
Assinatura:________________________
______

informaes de web services no registro UDDI
uma abordagem com qualidade de servio
Luis Hideo Vasconcelos Nakamura
Orientador: Prof. Dr. Marcos Jos Santana
Dissertao apresentada ao Instituto de Cincias

Matemticas e de Computao - ICMC-USP, como parte
dos requisitos para obteno do ttulo de Mestre em
Cincias - Cincias de Computao e Matemtica
Computacional. VERSO REVISADA
USP So Carlos
Fevereiro de 2012
Ficha catalogrfica elaborada pela Biblioteca Prof. Achille Bassi

e Seo Tcnica de Informtica, ICMC/USP,
com os dados fornecidos pelo(a) autor(a)
NN163u
u
Nakamura, Luis Hideo Vasconcelos

informaes no registro UDDI uma abordagem com
qualidade de servio / Luis Hideo Vasconcelos
Nakamura; orientador Marcos Jos Santana. -- So
Carlos, 2011.
148 p.
Dissertao (Mestrado - Programa de Ps-Graduao em
Cincias de Computao e Matemtica Computacional) -Instituto de Cincias Matemticas e de Computao,
Universidade de So Paulo, 2011.
1. Servios Web. 2. Web Semntica. 3. Qualidade de
Servios. 4. Avaliao de Desempenho. I. Santana,
Marcos Jos, orient. II. Ttulo.
Agradecimentos
Agradeo inicialmente a Deus pela existncia, por estar ao meu lado

principalmente nos momentos mais difceis, pelas oportunidades que colocou em meu caminho e por me conceder nimo, fora e coragem para superar os problemas e vencer mais uma etapa na minha vida. Agradeo a
minha esposa, dria, que sempre me apoiou e incentivou durante esta jornada. Agradeo tambm a minha famlia, em especial aos meus pais, Pedro
e Carmem, pelo carinho, apoio, pacincia e compreenso.
Quero agradecer, em especial, ao meu orientador prof. Dr. Marcos Santana pela sua orientao e motivao como orientador. Pela sua dedicao e
experincia transmitida como professor e pessoa. E tambm pelo o seu apoio
em momentos de deciso. Quero agradecer tambm as professoras Regina e
Sarita pelos conselhos e conhecimentos transmitidos. Ao professor Jlio Estrella, que tambm muito contribuiu com ideias e sugestes neste trabalho de
mestrado e tambm pela sua prontido, sempre pronto para participar, colaborar e contribuir. Agradeo aos demais professores do mestrado: Mnaco,
Kalinka, Paulo Srgio, Jo Ueyama e aos meus professores de graduao, em
especial ao professor Marco Antnio, que muito contriburam com a minha
formao.
Agradeo tambm aos meus amigos que residem em So Carlos, Vagner
Sousa, Ricardo Cezar (Amaral) e Valdir Sousa que me ajudaram no incio
do curso durante minha vinda So Carlos. Aos meus amigos e colegas da
CI&T e IBM que muito me incentivaram nesta nova trilha que escolhi para
minha vida.
Agradeo muito aos meus amigos do LaSDPC, pelo apoio, simpatia,
hospitalidade e amizade. Um forte abrao a estes meus amigos: Bruno
Guazzelli, Paulo (Ipuiuna), Bruno Tardiolle, Maycon Leone, Pedro Prado,
Daniel Pigatto, Edwin Choquehuanca, Pedro Nobile, Bruno Faial, Douglas Rodrigues, Roni Apaza, Joo Paulo Orlando, Fabiano Texeira, Ricardo
Nogueira, Loureno Perreira, Alessandro Nakamuta, Ren Pinto, Dionsio
Leite, Adriana Centurion, Thiago Caproni, Mrio Machado e Jlio Estrella.
Agradeo a Universidade de So Paulo e a todos os seus funcionrios,
especialmente aos do ICMC. E tambm a todos aqueles que contriburam de
alguma forma para a realizao bem sucedida deste projeto.
Quero agradecer tambm FAPESP pelo apoio financeiro concedido
para a realizao deste trabalho.
i
Resumo
S te projeto de mestrado aborda a utilizao de recursos da Web Semn-
tica na seleo de informaes sobre Web Services no registro UDDI

(Universal Description, Discovery, and Integration). Esse registro
possui a limitao de apenas armazenar informaes funcionais de Web Services. As informaes no funcionais que incluem as informaes de qualidade de servio (QoS - Quality of Service) no so contempladas e dessa
forma dificulta a escolha do melhor servio pelos clientes. Neste projeto,
a representao da base de conhecimento com informaes sobre os provedores, clientes, acordos, servios e a qualidade dos servios prestados foi
feita por meio de uma ontologia. Essa ontologia utilizada pelo mdulo
UDOnt-Q (Universal Discovery with Ontology and QoS) que foi projetado
para servir de plataforma para algoritmos de busca e composio de servios
com qualidade. Embora a utilizao de semntica possa ser empregada para
a composio e automatizao de servios, o foco deste trabalho a garantia de qualidade de servio em Web Services. Os algoritmos desenvolvidos
empregam recursos da Web Semntica para classificar e selecionar os Web
Services adequados de acordo com as informaes de qualidade que esto
armazenados na ontologia. O mdulo e os algoritmos foram submetidos a
avaliaes de desempenho que revelaram problemas de desempenho com
relao a abordagem adotada durante o processo de inferncia da ontologia.
Tal processo utilizado para a classificao das informaes dos elementos
presentes na ontologia. Contudo, uma vez que as informaes foram inferidas, o processo de busca e seleo de servios comprovou a viabilidade de
utilizao do mdulo e de um dos seus algoritmos de seleo.
iii
Abstract
master project addresses the use of Semantic Web resources in

the selection of information about Web Services in UDDI registry
(Universal Description, Discovery, and Integration). This registry
has the limitation of only storing functional information of Web Services.
The nonfunctional information that includes the quality of service information (QoS - Quality of Service) is not covered and thus it is complicate to
choose the best service for customers. In this project, the representation of
the knowledge base with information about the providers, customers, agreements, services and quality of services has been made through an ontology.
This ontology is used by the module UDOnt-Q (Universal Discovery with
Ontology and QoS) that was designed to serve as a platform for search algorithms and composition of services with quality. Although the use of semantics can be adopted for the composition and automation of services, the
focus of this work is to guarantee quality of service in Web Services. The
developed algorithms employ Semantic Web resources to classify and select
the appropriate Web Services according to the quality information that is
stored in the ontology. The module and the algorithms have been subjected
to performance evaluations that revealed performance problems in relation
to the approach taken during the ontology inference process. This process
is used for classification of information of the elements present in the ontology. However, since the information was inferred, the process of search
and selection services proved the viability of using the module and one of its
selection algorithms.
H is
Sumrio
Agradecimentos
Resumo
iii
Abstract
Lista de Siglas
1
Introduo
1.1 Consideraes Iniciais
1.2 Contextualizao . . .
1.3 Trabalhos Relacionados
1.4 Motivao e Objetivos
1.5 Estrutura . . . . . . . .
xv
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
1
1
2
3
5
6
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
Web Services
2.1 Consideraes Iniciais . . . . . . . . . . . .
2.2 Arquitetura Orientada a Servios (SOA) . . .
2.3 Padres Fundamentais de Web Services . . .
2.4 Arquitetura de Web Services . . . . . . . . .
2.5 Qualidade de Servio aplicada Web Services
2.6 Consideraes Finais . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
7
. 7
. 7
. 8
. 9
. 11
. 12
.
.
.
.
.
.
.
15
15
15
17
18
24
25
26
Ontologia e Web Semntica

3.1 Consideraes Iniciais . . . . . . . . . . . . .
3.2 Ontologia . . . . . . . . . . . . . . . . . . . .
3.3 Web Semntica . . . . . . . . . . . . . . . . .
3.4 A OWL - Web Ontology Language . . . . . . .
3.5 A OWL-S - Semantic Markup for Web Services
3.6 Ontologia, Web Semntica e Web Services . . .
3.7 Consideraes Finais . . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
Ontologia do UDOnt-Q
29
4.1 Consideraes Iniciais . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
4.2 Desenvolvimento da Ontologia do UDOnt-Q . . . . . . . . . . . . . . . . . . . . . 30
4.2.1 Methontology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
vii
4.3
4.4
5
4.2.2 Metodologia de Noy e McGuinness . . . . . . . .

4.2.3 Ferramentas para o desenvolvimento da Ontologia
Elementos da Ontologia do UDOnt-Q . . . . . . . . . . .
Consideraes Finais . . . . . . . . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
32
34
37
41
UDOnt-Q - Universal Discovery with Ontology and QoS

5.1 Consideraes Iniciais . . . . . . . . . . . . . . . . . .
5.2 Metodologia e Ferramentas . . . . . . . . . . . . . . . .
5.2.1 Metodologia gil (Agile) . . . . . . . . . . . . .
5.2.2 Ferramentas . . . . . . . . . . . . . . . . . . . .
5.3 Componentes e Estrutura . . . . . . . . . . . . . . . . .
5.3.1 Componente Util . . . . . . . . . . . . . . . . .
5.3.2 Componente Command Components (CC) . . .
5.3.3 Componente UDDI Components (UC) . . . . . .
5.3.4 Componente Ontology Components (OC) . . . .
5.3.5 Componente Common Information Shared (CIS)
5.3.6 Estrutura dos Componentes do UDOnt-Q . . . .
5.4 Consideraes Finais . . . . . . . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
43
43
43
44
44
48
49
49
51
51
53
53
56
Avaliao de Desempenho
6.1 Consideraes Iniciais . . . . . . . . . . . . . . . .
6.2 Configurao do Ambiente de Testes . . . . . . . . .
6.3 Planejamento de Experimentos . . . . . . . . . . . .
6.4 Avaliao de Desempenho dos Experimentos . . . .
6.4.1 Clculo da Influncia dos Fatores . . . . . .
6.5 Anlise dos Resultados . . . . . . . . . . . . . . . .
6.5.1 Anlise dos Resultados das Ontologias . . .
6.5.2 Anlise dos Resultados do Mdulo UDOnt-Q
6.6 Consideraes Finais . . . . . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
57
57
57
60
63
66
67
67
67
97
Concluses
7.1 Concluso Geral . . . . . .
7.2 Contribuies . . . . . . .
7.2.1 Produo Cientfica
7.3 Trabalhos Futuros . . . . .
Anexos
ANEXO. 1.
ANEXO. 2.
ANEXO. 3.
ANEXO. 4.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
99
99
100
101
101
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
111
114
120
128
130
viii
Lista de Figuras
2.1
2.2
2.3
2.4
Colaboraes em uma arquitetura orientada a servios (Traduzido de (Endrei et al.,

2004)). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Modelo bsico de uma arquitetura orientada a servios. . . . . . . . . . . . . . .
Pilha da Arquitetura de um Web Services. Adaptado de (W3C, 2004d). . . . . . .
Web Service utilizando WSLA - Traduzido de (IBM, 2009). . . . . . . . . . . . .
3.1
3.2
3.3
3.4
3.5
3.6
Exemplo de representao de Domnios. . . . . . . . . . . . . . . . . . . . .

Grafo representando os componentes bsicos de um arquivo RDF. . . . . . . .
Arquitetura da Web Semntica (Berners-Lee, 2000) . . . . . . . . . . . . . . .
Arquitetura alternativa da Web Semntica (Antoniou e Harmelen, 2008) . . . .
Viso Taxonmica das classes: owl:Thing e owl:Nothing (Fisher et al., 2009) .
Exemplos de Cabealho, Classe, Sub-Classe, Instncia de Classe ou Indivduo
Propriedade em OWL (Martimiano, 2006) . . . . . . . . . . . . . . . . . . . .
3.7 Exemplo de propriedade Transitiva . . . . . . . . . . . . . . . . . . . . . . .
3.8 Exemplo de propriedade Simtrica . . . . . . . . . . . . . . . . . . . . . . . .
3.9 Exemplo de propriedade Funcional . . . . . . . . . . . . . . . . . . . . . . .
3.10 Exemplo de propriedade Funcional . . . . . . . . . . . . . . . . . . . . . . .
3.11 Topo do nvel de uma ontologia de servio. Traduzido de (Martin et al., 2004).
.
.
.
.
.
e
.
.
.
.
.
.
. 8
. 9
. 10
. 12
.
.
.
.
.
17
18
19
19
20
.
.
.
.
.
.
22
23
23
23
24
24
4.1
4.2
4.3
4.4
Modelo abstrato da relao entre o cliente, mdulo, algoritmos e a ontologia. . . . 29

Mapeamento da Hierarquia de Classes do UDOnt-Q. (Nakamura et al., 2011a) . . 35
Parte da aba de propriedades entre classes (Object Properties). . . . . . . . . . . . 35
Restries de Equivalncia da classe QoSGold. . . . . . . . . . . . . . . . . . . . 39
5.1
5.2
5.3
5.4
5.5
5.6
5.7
5.8
Arquitetura do Jena (Carroll et al., 2004). . . . . . . . . . . . . . . . . . . . . . .

Componente Util. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Componente Command Components (CC). . . . . . . . . . . . . . . . . . . . . .
Sub-componente QoS Components (QC). . . . . . . . . . . . . . . . . . . . . . .
Componente UDDI Components (UC). . . . . . . . . . . . . . . . . . . . . . . .
Componente Ontology Components (OC). . . . . . . . . . . . . . . . . . . . . . .
Componente Common Information Shared (CIS). . . . . . . . . . . . . . . . . . .
Estrutura resumida do Mdulo com os seus componentes (Nakamura et. al, 2011a).
6.1
6.2
Viso resumida dos elementos de software utilizados no ambiente de testes. . . . . 59

Viso resumida dos elementos de hardware utilizados. . . . . . . . . . . . . . . . 64
ix
47
49
50
50
52
53
53
54
6.3
6.4
6.5
6.6
6.7
6.8
6.9
6.10
6.11
6.12
6.13
6.14
6.15
6.16
6.17
6.18
6.19
6.20
6.21
6.22
6.23
6.24
6.25
6.26
6.27
6.28
Comportamento do processamento de Inferncia da Ontologia com 30 Clientes e

300, 600, 900 e 1200 Servios (PE-Ontologia). . . . . . . . . . . . . . . . . . . .
Comportamento do processamento de Inferncia da Ontologia com 200,400, 600
e 800 Pizzas (PE-Pizza). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Comportamento do processamento de Inferncia da Ontologia com 300, 600, 900
e 1200 Servios (PE-Ontologia) (Nakamura et al., 2011b). . . . . . . . . . . . .
Comportamento do processamento de Inferncia da Ontologia com 200, 400, 600
e 800 Pizzas (PE-Pizza) (Nakamura et al., 2011b). . . . . . . . . . . . . . . . . .
Grfico em Linha de comparao do Comportamento do processamento de Inferncia com 200, 400, 600 e 800 Pizzas (PE-Pizza) com um Comportamento Linear
Hipottico (Nakamura et al., 2011b). . . . . . . . . . . . . . . . . . . . . . . . .
Tempo de Busca (TB) utilizando os algoritmos com 15 clientes (CJE-1). . . . . .
Tempo de Resposta para o Cliente (RTC) utilizando os algoritmos com 15 clientes
(CJE-1). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
(CJE-1). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Porcentagem de Influncia de cada fator no tempo de busca (TB) do mdulo durante os experimentos (CJE-1). . . . . . . . . . . . . . . . . . . . . . . . . . . .
(CJE-2). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
(CJE-2). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Tempo de Busca (TB) utilizando os algoritmos com 30 clientes e todos os servios
(CJE-1 e 2). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Comparao no Tempo de Busca (TB) dos CJE-1 e CJE-3 utilizando os algoritmos
com 30 clientes e 600 servios. . . . . . . . . . . . . . . . . . . . . . . . . . . .
Comparao no Tempo de Busca (TB) dos CJE-2 e CJE-4 utilizando os algoritmos
com 30 clientes e 1200 servios. . . . . . . . . . . . . . . . . . . . . . . . . . . .
Comparao do Tempo de Busca (TB) entre o CJE-1 x CJE-5 utilizando 15 clientes,
300 servios e o algoritmo OntAlgorithmSPARQL. . . . . . . . . . . . . . . . . .
(CJE-5). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
(CJE-5). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
68
69
69
70
70
71
72
72
73
74
75
75
76
76
77
78
79
80
81
81
82
83
84
85
85
86
6.29 Porcentagem da carga de processamento (CPU-Load) do mdulo durante os experimentos (CJE-5). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

6.30 Tempo de Busca (TB) utilizando os algoritmos com 15 clientes (CJE-6). . . . .
6.31 Tempo de Busca (TB) utilizando os algoritmos com 30 clientes (CJE-6). . . . .
6.32 Tempo de Resposta para o Cliente (RTC) utilizando os algoritmos com 15 clientes
(CJE-6). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
(CJE-6). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
6.34 Porcentagem de Influncia de cada fator no tempo de busca (TB) do mdulo durante os experimentos (CJE-6). . . . . . . . . . . . . . . . . . . . . . . . . . .
6.35 Porcentagem da carga de processamento (CPU-Load) do mdulo durante os experimentos (CJE-6). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
(CJE-7). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
(CJE-7). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
6.38 Porcentagem de Influncia de cada fator no tempo de resposta nos clientes (RTC)
durante os experimentos (CJE-7). . . . . . . . . . . . . . . . . . . . . . . . . .
(CJE-8). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
(CJE-8). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
6.41 Porcentagem de Influncia de cada fator no tempo de resposta nos clientes (RTC)
durante os experimentos (CJE-8). . . . . . . . . . . . . . . . . . . . . . . . . .
xi
. 87
. 88
. 89
. 90
. 90
. 91
. 92
. 93
. 93
. 94
. 95
. 96
. 97
Lista de Tabelas
2.1
Atributos de QoS para Web Services (Lee e Shin, 2008) . . . . . . . . . . . . . . . 13
6.1
6.2
6.3
6.4
6.5
6.6
6.7
Elementos de Hardware . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Elementos de Software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Fator e nveis relativos ao PE-Ontologia . . . . . . . . . . . . . . . . . . . . . .
Fator e nveis relativos ao PE-Pizza . . . . . . . . . . . . . . . . . . . . . . . .
Fator e nveis relativos ao PE-Modulo . . . . . . . . . . . . . . . . . . . . . . .
Fatores Fixos e possveis nveis relativos ao PE-Modulo . . . . . . . . . . . . .
Projeto Fatorial Completo para Avaliao de Desempenho do Mdulo com 300 e
600 Servios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Projeto Fatorial Completo para Avaliao de Desempenho do Mdulo com 300 e
1200 Servios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Conjuntos de Experimentos do PE-Modulo . . . . . . . . . . . . . . . . . . . .
Fatorial completo 23 e Mdias do Tempo de Busca (TB) do CJE-1 . . . . . . . .
6.8
6.9
6.10
6.11
6.12
6.13
6.14
6.15
xiii
.
.
.
.
.
.
58
58
61
62
62
63
. 65
.
.
.
.
.
.
.
.
65
65
73
78
86
91
94
97
Lista de Siglas
API -
Application Programming Interface
B2B -
Business-to-Business
BPEL -
Business Process Execution Language
CERN -
Conseil Europen pour la Recherche Nuclaire
DL
Description Logics
DNS -
Domain Name System
EAI -
Enterprise Application Integration
FTP -
File Transfer Protocol
HTTP HP
HyperText Transfer Protocol

Hewlett-Packard
IBM -
International Business Machines
IDE -
Integrated Development Environment
IEEE IP KACTUS
MIT OASIS OWL
Institute of Electrical and Electronics Engineers

Internet Protocol
Knowledge About Complex Technical systems for multiple USe
Massachusetts Institute of Technology
Organization for the Advancement of Structured Information Standards
Web Ontology Language
QoS -
Quality of Service
RDF -
Resource Description Framework
RDF-S -
Resource Description Framework Schema
xv
SaaS -
Software-as-a-Service
SLA -
Service Level Agreement
SMTP -
Simple Mail Transfer Protocol
SOA -
Service Oriented Architecture
SOAP SPARQL TI -
Simple Object Access Protocol

SPARQL Protocol and RDF Query Language
Tecnologia da Informao
TOVE -
TOronto Virtual Enterprise
UDDI -
Universal, Discovery, Description and Integration
UDOnt-Q -
Universal Discovery with Ontology and QoS
URI -
Uniform Resource Identifier
W3C -
World Wide Web Consortium
WS WSARCH -
Web Service
Web Services Architecture
WSDL -
Web Services Description Language
WSLA -
Web Service Level Agreement
XML -
eXtensible Markup Language
xvi
C APTULO
1
Introduo
1.1
Consideraes Iniciais
A World Wide Web (referida nesta dissertao por Web) foi concebida pelo fsico Tim BernersLee em 1989, no Centro Europeu para Pesquisa Nuclear, o CERN (Lee e Fischetti, 1997). Anteriormente ao advento da Web, a Internet era um reduto de pesquisadores ligados a universidades,
governos e indstrias (Tanenbaum, 2003).
A Web facilitou o acesso informao tornando-a mais disponvel a vrias pessoas ao redor
do mundo. Nesse sentido as informaes geograficamente distribudas so acessadas de forma
mais simples e ampla. O contexto que envolve a Web, de forma geral, vem passando por diversas
modificaes que vo desde a criao e alterao de protocolos at as aplicaes que nela residem.
A nova verso da Web foi batizada por Web 2.0 e engloba as aplicaes de nova gerao, com mais
contedo dinmico e provendo maior interatividade com os usurios (Murugesan, 2007).
Algumas das possibilidades para prover mais interao e dinamismo constituem as tarefas assncronas e interao com outros sistemas ou aplicaes. A Internet formada por um conjunto
de sistemas, aplicaes e implementaes diferentes e a interao entre esses sistemas no uma
tarefa simples, que requer a adoo de um padro para a formalizao de um protocolo. Os Web
Services permitem a realizao de interoperabilidade em nvel de aplicao na interao mquina
a mquina sobre uma comunicao em rede (Bhakti e Abdullah, 2010) e essa caracterstica fez
com que eles se tornassem uma soluo atrativa para os problemas de integrao entre sistemas na
Internet.
Um Web Service uma soluo de software projetada para dar suporte a interaes mquinapara-mquina, fornecendo uma interface descrita em um formato baseado em XML (eXtensible
1
1.2. CONTEXTUALIZAO
Markup Language), denominado WSDL (Web Services Description Language). Outros sistemas
interagem com um Web Service da maneira prevista por sua descrio usando mensagens SOAP
(Simple Object Access Protocol), que tambm so baseados em XML. Geralmente o protocolo
utilizado para o transporte o HTTP com uma serializao XML em conjunto com outros padres
relacionados Web (W3C, 2004d). Para a publicao e descoberta dos provedores e de seus
servios empregado o registro UDDI (Universal Description, Discovery, and Integration).
Os Web Services tm sido amplamente utilizados por vrios segmentos, tanto na academia
como em empresas, os quais tm investido em pesquisas com o propsito de melhorar a interoperabilidade, a eficincia, a segurana e o suporte QoS (Quality of Service).
A ampla aplicabilidade de Web Services incentiva a pesquisa sobre a incluso de qualidade de
servio (QoS). Algumas empresas tm trabalhado com o modelo SaaS (Software-as-a-Service), no
qual a aplicao no mais hospedada no host cliente, mas sim cedida como um servio de modo
que sua utilizao pode ou no ser cobrada (Goh et al., 2007). Nesse sentido, alm da qualidade
de software, o cliente passar a exigir qualidade de servio. importante destacar que o cliente
no necessariamente o usurio final. Um cliente pode ser outra empresa ou outra aplicao e
assim ser estendido a outros conceitos tais como: B2B (Business-to-Business) e EAI (Enterprise
Application Integration).
H na literatura vrias propostas de aplicao de QoS em Web Services, onde algumas tentam
utilizar semntica na busca de informaes em Web Services. Alguns autores apresentam a utilizao de ontologias com o objetivo de alcanar resultados mais positivos, como nos trabalhos de
(Papaioannou et al., 2006), (Tran, 2008), (Maximilien e Singh, 2004), (Fakhfakh et al., 2008) e
(Aklouf e Rezig, 2009). Segundo Tran (2008) a ontologia pode apoiar o descobrimento da informao de QoS com grandes detalhes. Ela tambm pode facilitar vrios servios participantes, os
quais expressam suas ofertas e demandas de QoS em diferentes nveis de expectativa (Tran, 2008).
1.2
Contextualizao
Os Web Services so baseados em uma arquitetura orientada a servios - SOA (Service Oriented
Architeture) que tem a vantagem de ser escalvel e flexvel. Os componentes de uma arquitetura
orientada a servios para Web Service, como o WSDL, o protocolo SOAP e o UDDI so baseados
em XML, o que facilita a integrao entre sistemas e aplicaes diferentes, pois vrias plataformas
e linguagens de programao so capazes de trabalhar com XML. Um dos protocolos de transporte mais empregados para a transferncia de mensagens SOAP o HTTP (HyperText Transfer
Protocol) que geralmente faz uso da porta 80, a qual na maioria dos firewalls no bloqueada.
Todas essas vantagens fazem com que os Web Services se tornem um forte candidato para
solucionar o problema da integrao de sistemas e aplicaes na Internet. Vrias empresas tm
investido e participado do desenvolvimento e de pesquisas em Web Services. A IBM, Hewlett-
CAPTULO 1. INTRODUO
Packard - HP e a Microsoft, so alguns exemplos da indstria de TI (Tecnologia da Informao)

que identificaram o potencial dos Web Services para resolver problemas de interoperabilidade.
Alm da interoperabilidade, outra preocupao com relao qualidade de servio prestada
pelos provedores. Os clientes tm a opo de escolher servios com a mesma funcionalidade em
diferentes provedores. Quando o cliente conhece e tem contato com os provedores de servios, ele
pode se informar da qualidade de servio (QoS) prestada e estabelecer acordos de nveis de servios
(SLA - Service Level Agreement). At mesmo dentro de uma corporao podem existir servios
similares com mesma funcionalidade, porm com requisitos no funcionais (QoS) diferentes.
Quando o cliente no conhece os provedores ele pode consultar o registro UDDI (Universal
Description, Discovery, and Integration) e obter informaes sobre os servios e provedores. Contudo, esse registro armazena apenas informaes funcionais, portanto no h nenhuma informao
de QoS que auxilie o cliente na escolha do servio desejado (Tran e Tsuji, 2009). Alm disso,
diversos provedores podem compartilhar o mesmo registro UDDI com o objetivo de contemplar
um maior nmero servios que atendam aos mais diversificados tipos de clientes (os mais e os
menos exigentes). A garantia do servio prestado por esses provedores estabelecida em acordos
de nveis de servios que buscam garantir a qualidade desejada de cada perfil de cliente. Este
trabalho de mestrado est inserido dentro desse escopo, propondo o emprego de recursos da Web
Semntica como soluo para essa limitao do registro UDDI.
1.3
Trabalhos Relacionados
A ampla e iminente proliferao de Web Services despertou o interesse do meio acadmico e

da indstria em relao ao suporte qualidade de servio. Aplicaes do tipo B2B, EAI e SaaS
geralmente precisam disponibilizar pelo menos um mnimo de QoS. Algumas propostas ((Tavares
e Westphall, 2006), (Xu et al., 2007), (Lee, 2008), (Ye et al., 2009), (Estrella et al., 2010), (Yuansheng et al., 2010), (Rajendran e Balasubramanie, 2010)) foram sugeridas nos ltimos anos visando
um melhor suporte QoS, como a criao de novos componentes1 e arquiteturas.
Essas propostas so vlidas, pois em uma arquitetura de Web Services so os provedores que
disponibilizam os servios e, consequentemente, so os responsveis por garantir a qualidade adequada. Porm, mesmo que cada um dos provedores em particular garanta certo nvel de QoS para
os seus servios, acontece muitas vezes o problema de os clientes no conhecerem, ainda, esses
provedores e, neste caso, podem ser levados a iniciar uma pesquisa no registro UDDI. Contudo,
tanto o padro do registro UDDI como o padro da WSDL falham na descoberta dinmica de
servios baseada em qualidade de servio, pois contam apenas com algumas operaes funcionais
de descoberta e publicao de Web Services e um conjunto de descries sintticas e estticas da
interface do servio respectivamente (Kritikos e Plexousakis, 2007). Portanto, por padro, eles no
1
Geralmente prximo ou dentro do UDDI.
1.3. TRABALHOS RELACIONADOS
contm informaes detalhadas de QoS para cada servio. Nesse sentido, ainda surge a questo de
como determinar quais servios possuem um nvel de QoS aceitvel pelo cliente.
Com base nessa preocupao com a qualidade de servios em Web Services, alguns outros
trabalhos, tais como (Papaioannou et al., 2006), (Tran, 2008), (Maximilien e Singh, 2004), (Aklouf
e Rezig, 2009), (Ma et al., 2010), (Baocai et al., 2010), (Wu e Guo, 2011) e (Tsai et al., 2011),
abordam o emprego da semntica com ontologias para realizar a classificao dos servios, tendo
como base propriedades de QoS.
Em relao ao emprego de ontologias, no trabalho de Luo et. al. (2006) foi proposto um
mtodo de utilizao da OWL-S com o registro UDDI para a obteno de semntica (Luo et al.,
2006). Nenhuma alterao no registro UDDI foi necessria, apenas a criao de mdulos residentes
nas mquinas clientes (client-side) que tiram proveito das capacidades da semntica. Contudo, no
houve preocupao em relao qualidade de servio e, como utilizou a OWL-S, no apresentou
uma nova ontologia e no houve uma avaliao do desempenho observado.
O trabalho de Baocai et. al. (2010) tambm considera a utilizao da OWL-S, porm complementa a descoberta de servios com auxlio de uma ontologia de QoS (QoS Ontology) utilizada
por um framework para a descoberta automtica dos servios adequados. Porm, esse trabalho no
considera os acordos de nveis de servios (SLA) e no apresenta resultados de desempenho.
No trabalho de Fakhfakh et. al. (2008) apresentada uma ontologia baseada no modelo
SLA. Trata-se de um trabalho interessante que utiliza as obrigaes acordadas em contratos, mas
no apresenta resultados que possam ser avaliados em termos de desempenho e de eficincia na
obteno de QoS.
Os pesquisadores Wu e Guo (2011) propem a utilizao de agentes inteligentes providos pelo
framework JADE2 (Java Agent DEvelopment Framework) na descoberta de Web Services. Apesar
do emprego de agentes ser interessante, o artigo no descreve em detalhes a ontologia utilizada, os
experimentos executados no detalham os elementos de software e no h registros dos elementos
de hardware utilizados. Os resultados obtidos so interessantes e indicam que quanto maior o
nmero de servios, maior o tempo de classificao mas, por outro lado, o tempo de descoberta
mais vantajoso utilizando-se essa abordem. Apesar de algumas semelhanas com os resultados
deste trabalho de mestrado, comparaes no podem ser feitas de forma expressiva em funo da
ausncia de detalhes que no foram publicados.
A proposta de Tsai, Hwang e Tang (2011) consiste em uma abordagem hbrida entre o uso
de ontologia e tcnicas de recuperao de informaes baseadas em textos, para descoberta automtica de Web Services. Porm, nessa proposta as informaes sobre a qualidade de servio dos
Web Services no so mencionadas.
De forma geral, apesar do embasamento terico, poucos so os trabalhos relacionados que contemplam a descoberta de servios baseados em QoS e ainda associam a parte de acordo de nveis de
servios (SLA). Alm disso, nem todos esses trabalhos relatam os resultados de forma adequada,
2
http://jade.tilab.com/
CAPTULO 1. INTRODUO
alguns no apresentam informaes de desempenho e outros no apresentam um desenvolvimento

prtico.
1.4
Motivao e Objetivos
Apesar de ser uma rea que nos ltimos anos est em destaque e em constante investigao e
pesquisa, os Web Services ainda podem ser explorados em diversas vertentes, em funo de sua
natureza distribuda.
A maior aceitao e utilizao de Web Services proporcionaram uma maior preocupao com
o desempenho, confiabilidade e segurana dos mesmos. Porm todos estes pontos e alguns outros
como interoperabilidade, tempo de resposta, custo, etc., podem ser englobados dentro do suporte
QoS para as aplicaes. Embora vrias pesquisas tenham sido desenvolvidas e diversos artigos
tenham sido publicados, conforme apresentados na seo anterior, poucos propuseram a adoo de
um ambiente prximo do real e a realizao de testes que obtivessem resultados a serem analisados.
Nesse sentido, o objetivo deste projeto de mestrado a utilizao de Web Semntica na seleo
de informaes no registro UDDI, mas tambm vista ao suporte QoS. Para realizar esta tarefa, a
utilizao de ontologia ser adotada para auxiliar nas classificaes de informaes referentes ao
contexto de Web Services com QoS. Dessa forma, ao invs do cliente requisitar informaes ao
registro UDDI, ele deve inicialmente consultar o mdulo UDOnt-Q (desenvolvido neste trabalho)
que realiza a busca por servios baseando-se em determinados nveis ou parmetros de QoS. O
provedor de servios deve manter atualizado os nveis ou parmetros de QoS de seus servios.
Alm disso, este trabalho tambm contempla a parte dos acordos de tipo SLA envolvidos, para
determinar o nvel de QoS de cada cliente. Esses contratos garantem a prestao do servio,
especificando claramente o custo, benefcios e punies do no cumprimento do acordo (Fakhfakh
et al., 2008).
Alguns trabalhos relacionados, citados anteriormente, enfatizam apenas o desenvolvimento de
ontologias para agregar QoS e no apresentam resultados que justifiquem ou no a sua utilizao.
Alguns trabalhos propem uma implementao prtica, mas no relatam detalhes de desenvolvimento e informaes de desempenho. Neste trabalho foi implementado um mdulo para servir de
plataforma para algoritmos que empregam semntica para determinar quais servios do UDDI so
mais adequados s requisies de QoS dos clientes. Os algoritmos adotados utilizam informaes
presentes em uma ontologia, a qual representa o mundo real de uma arquitetura de Web Services
com QoS. Alm do desenvolvimento prtico da ontologia, do mdulo e de seus algoritmos, foi
tambm realizada uma avaliao de desempenho criteriosa cujos resultados so apresentados no
decorrer desta dissertao.
1.5. ESTRUTURA
1.5
Estrutura
Esta dissertao est organizada da seguinte forma:

No Captulo 2 so apresentadas informaes sobre Web Services, seus conceitos, fundamentos e arquitetura. O conhecimento prvio sobre Web Services necessrio para o desenvolvimento deste trabalho, uma vez que a proposta garantir qualidade para estes servios. Alm
disso, as informaes armazenadas, selecionadas e recuperadas do registro UDDI so referentes aos provedores de Web Services e tambm informaes desses prprios servios. Por
fim, ainda neste captulo, destinado um espao para a aplicao de qualidade de servio
(QoS) em Web Services.
No Captulo 3 so apresentados os conceitos de Web Semntica e Ontologia. O conhecimento de ambos os assuntos indispensvel para atingir o objetivo do projeto de pesquisa
considerado nesta dissertao. A explicao do conceito de ontologia realizada utilizandose um exemplo baseado em domnios. apresentada uma reviso bibliogrfica sobre Web
Semntica, abordando os principais fundamentos e ferramentas utilizadas.
No Captulo 4 so apresentados o desenvolvimento e a estrutura da ontologia criada para
servir de base de conhecimento para os mecanismos semnticos.
No Captulo 5 caracterizada a estrutura geral do mdulo UDOnt-Q, no qual sero discutidos os seus componentes. Tambm sero abordadas as implementaes dos algoritmos
de busca. O funcionamento da busca e seleo por parte do mdulo e seus algoritmos so
detalhados neste captulo.
No Captulo 6 discutida a avaliao de desempenho do mdulo e seus algoritmos. Nesse
captulo so apresentadas algumas etapas que foram seguidas para a realizao dos experimentos, como por exemplo; a configurao do ambiente, o planejamento dos experimentos
e a anlise dos resultados obtidos.
O Captulo 7 reservado para as concluses obtidas com o desenvolvimento deste trabalho.
As principais contribuies geradas por este trabalho sero apresentadas em conjunto com
sugestes para projetos futuros.
Finalmente so apresentadas as Referncias Bibliogrficas utilizadas para a elaborao
desta monografia.
No decorrer desta dissertao, o leitor ir notar que algumas imagens e tabelas foram traduzidas ou adaptadas para facilitar o entendimento do contedo. No entanto, algumas outras foram
mantindas em seu formato e idioma (ingls) original de acordo como foram publicadas.
C APTULO
2
Web Services
2.1
Paralelamente ao avano do potencial de processamento e do aumento da largura de banda, a

Web evoluiu na direo de proporcionar um ambiente vivel para a criao de aplicaes robustas e
complexas. Essa evoluo estabeleceu um novo cenrio composto de aplicaes com jogos on-line,
internet-banking, comrcio eletrnico, pginas com contedo dinmico e interao multimdia,
entre outras. Dessa forma, a Web deixou de ser uma ferramenta apenas para a troca de arquivos e
composta basicamente de pginas estticas.
Com o aumento de aplicaes na Internet, tambm aumentou a necessidade de comunicao
entre elas. Contudo, o nmero de aplicaes diferentes, construdas em ambientes operacionais
distintos e escritas em linguagens heterogneas tornou-se um obstculo para tal interao. Os Web
Services constituem uma soluo apresentada para a interao entre aplicaes. O objetivo deste
captulo uma breve apresentao sobre os Web Services, abordando informaes sobre a sua
arquitetura, os padres fundamentais e a qualidade de servio relacionada.
2.2
Arquitetura Orientada a Servios (SOA)
A Arquitetura Orientada a Servios (SOA - Service-oriented Architecture) estabelece um modelo arquitetnico que busca utilizar servios como principais meios para aprimorar a eficincia, a
agilidade e a produtividade de uma empresa (Erl, 2009). SOA no uma arquitetura concreta, no
um framework ou uma ferramenta. SOA pode ser tomada como um conceito ou um paradigma
7
2.3. PADRES FUNDAMENTAIS DE WEB SERVICES
que, quando considerado, pode levar ao projeto de uma arquitetura concreta de software (Josuttis,
2008).
SOA prope um estilo de arquitetura para a construo de sistemas de informao atravs de
combinaes de servios (Komoda, 2006). A composio de servios um fator importante dentro
de uma arquitetura orientada a servios. Uma composio de servio consiste em um conjunto
ordenado de servios (Erl, 2009), que melhora a flexibilidade e o reuso de servios dentro da
arquitetura orientada a servios.
A Figura 2.1 ilustra as colaboraes entre servios de uma arquitetura SOA, onde as colaboraes entre as entidades seguem o paradigma procure, conecte e invoque ( find, bind and
invoke), no qual o servio consumidor realiza uma localizao dinmica, consultando o registro
de servios a fim de encontrar um que atenda os seus critrios. Assim, caso exista tal servio,
o registro fornece um contrato de interface e o endereo do servio desejado. Por fim, o servio
consumidor conecta a um servio provedor e consome o servio. A descrio do servio deve ser
publicada no registro pelo servio provedor, para que o servio possa ser descoberto e acessado
pelo servio consumidor (Endrei et al., 2004).
Figura 2.1: Colaboraes em uma arquitetura orientada a servios (Traduzido de (Endrei et al.,
2004)).
2.3
Padres Fundamentais de Web Services
Os Web Services so uma implementao da arquitetura SOA (Erradi e Maheshwari, 2005),

a qual proporciona interoperabilidade, independncia de ambiente operacional e linguagem de
programao tornando a sua adoo mais atraente para a indstria de TI. Um modelo de Web
Service possui interaes entre trs entidades, que so o provedor de servios, o registro de servios
e o consumidor de servios. A Figura 2.2 apresenta o modelo de uma SOA implementado para
Web Services e seus componentes.
CAPTULO 2. WEB SERVICES
9
Registro
UDDI
WSDL
WSDL
Busca
Publicao
Requisio
Cliente
Provedor
SOAP
Figura 2.2: Modelo bsico de uma arquitetura orientada a servios.

Os Web Services so compostos de basicamente trs padres:
Protocolo SOAP (Simple Object Access Protocol): o protocolo utilizado para troca de
mensagens entre Web Services, permitindo a comunicao de forma simples e independente
de linguagem ou plataforma (Papazoglou e Georgakopoulos, 2003).
Linguagem WSDL (Web Services Description Language): trata-se de uma linguagem utilizada para prover uma interface de descrio dos servios de um Web Service. Ela especifica
como o servio deve ser acessado e quais os mtodos disponveis (Thomas et al., 2003).
Registro UDDI (Universal Description, Discovery, and Integration): constitui um diretrio
(uma base de dados ou registro) que contm as descries de Web Services, utilizado para
localizar e publicar os servios neste registro (Farkas e Charaf, 2003).
2.4
Arquitetura de Web Services
Padronizao um ponto importante dentro de uma arquitetura SOA, pois proporciona interoperabilidade, alm de facilitar a implementao e o reuso. Esses padres esto presentes na
arquitetura de Web Services, a qual composta por no mnimo um servidor que disponibiliza seus
servios na rede e por clientes que acessam esses servios. Contudo, os agentes que iro utilizar
os servios necessitam de informaes para localizar o servidor prestador do servio e determinar
os parmetros exigidos. Para isso, o servidor deve publicar esses dados no registro UDDI que,
10
2.4. ARQUITETURA DE WEB SERVICES
por sua vez, pode conter informaes de vrios servios de um mesmo servidor ou de servidores
distintos. A WSDL utilizada para publicao do servio por parte do servidor e encontrada na
pesquisa por parte do agente consumidor. Uma vez que o agente consumidor possui as informaes
necessrias sobre o servidor e o servio, que so encontradas na WSDL, ele realiza a requisio
atravs do envio de uma mensagem encapsulada pelo protocolo SOAP.
Outro ponto a ser considerado que componentes e sistemas legados tambm podem exercer
o papel de consumidores de um Web Service, desde que sejam capazes de se comunicar utilizando
os padres dos Web Services (Erl, 2009). Utilizando-se os padres estabelecidos possvel a
comunicao entre aplicaes de diferentes implementaes, inclusive proprietrias. As aplicaes
podem ser escritas, por exemplo, em Java, .NET, PHP, entre outras.
A pilha da arquitetura de um Web Service composta por vrias camadas que vo desde o nvel
de transporte at a camada de processo, conforme mostra a Figura 2.3.
Figura 2.3: Pilha da Arquitetura de um Web Services. Adaptado de (W3C, 2004d).

Basicamente a pilha da arquitetura formada pelas seguintes camadas:
1. Processos: Essa camada responsvel pelo gerenciamento e coordenao dos processos
entre os servios que compe o Web Services. A linguagem BPEL (Business Process Execution Language) utilizada na especificao dos processos de negcio e as suas relaes com
os Web Services.
2. Descries: A camada de descrio contm a semntica formal para representar as mensagens que os Web Services podem entender, descrevendo as restries de dados dentro das
11
mensagens. Alm disso, essa camada tem como responsabilidade definir a maneira como os
Web Services so acessados (Tavares, 2009). Acrescenta-se ainda, que esta camada utiliza
arquivos WSDL para a descrio de servios, para o formato das mensagens, tipo de dados,
protocolos de transporte, etc.
3. Mensagens: A camada de mensagem permite que a troca de mensagens seja feita em um
ambiente descentralizado e distribudo de forma interopervel. (Toyohara, 2009). A mensagem pode ser serializada em um arquivo XML seguindo as especificaes do protocolo
SOAP.
a. Extenses SOAP: So as extenses do protocolo SOAP. O protocolo SOAP pode
ser modificado para suportar novas assinaturas e especificaes dentro do seu padro
XML, como por exemplo: WS-Reliability, WS-Addressing, WS-Attachments, etc.
b. SOAP: o protocolo SOAP, baseado em XML.
4. Comunicao ou Transporte: especifica os protocolos de rede utilizados na troca de mensagens entre clientes e provedores de servio. Dentre os principais protocolos, destacam-se
o HTTP, SMTP, FTP, entre outros (Tavares, 2009).
Apesar de muitas pesquisas e estudos realizados desde sua criao, esta soluo ainda est em
fase de maturao. A W3C mantm um domnio de pesquisa voltado Web Services denominado:
Web Services Activity"3 , em que uma parte dos trabalhos relacionados esto voltados proviso
de QoS e Segurana.
A pesquisa por melhores resultados em qualidade de servio deve ser contnua, uma vez que
a indstria de TI sempre busca melhor atender aos seus clientes, desenvolvendo produtos com
melhor qualidade e preo. Em uma rede como a Internet, a proviso de QoS em termos de desempenho, disponibilidade e segurana essencial, e ao mesmo tempo no uma tarefa trivial, em
funo da dinamicidade da Web.
2.5
Qualidade de Servio aplicada Web Services
Segundo Lee e Shin (2008) a qualidade de servio (QoS) um desafio crtico e importante
devido Internet ser uma rede dinmica e de natureza imprevisvel. Alm disso, a QoS pode ser
definida como uma combinao de vrias qualidades ou propriedades de um servio. Apesar das
propriedades de qualidade de servios no serem funcionais, elas so necessrias quando o servio
fornecido pelo provedor deve atender a certas qualificaes exigidas pelos clientes.
Prover qualidade de servio no uma tarefa trivial, alm disso, h a dvida se o provedor de
servios est atuando para garantir o nvel de qualidade de servio exigido. Para solucionar este
3
http://www.w3.org/2002/ws/
12
2.6. CONSIDERAES FINAIS
problema, a IBM desenvolveu um framework denominado WSLA (Web Service Level Agreements)
para especificao e monitoramento de acordos de nveis de servios (SLA - Service Level Agreement) para Web Services (IBM, 2009). Anlogo ao SLA, a WSLA um acordo entre um provedor
de servio e um cliente que define as obrigaes das partes envolvidas (Lee e Shin, 2008).
A WSLA complementa a definio do servio estabelecida na WSDL. Enquanto a WSDL
define a interface do Web Service, o WSLA define a forma de avaliar e mensurar as caractersticas
de desempenho acordadas (em contrato, por exemplo, SLA). Tanto o cliente como o provedor
de servio executam o gerenciamento de monitoramento em suas infra-estruturas. Cada parte
responsvel por mensurar as mtricas de diversas fontes, por exemplo, o cliente deve mensurar se
os valores dos parmetros de qualidade de servio foram alcanados (IBM, 2009). A Figura 2.4
exibe a estrutura de um Web Service utilizando WSLA.
Figura 2.4: Web Service utilizando WSLA - Traduzido de (IBM, 2009).

A abordagem de utilizar ou no acordos, como o WSLA, fica a cargo das partes envolvidas.
Para prover qualidade de servio no necessariamente preciso um acordo formal, o provedor
pode desenvolver mecanismos que busquem garantir a qualidade de servio e fornec-los aos seus
clientes com a inteno de oferecer um diferencial a mais que os seus concorrentes. Ento, independente de acordos serem firmados, algumas diretrizes devem ser tomadas quando se pretende
fornecer qualidade de servio; uma delas definir quais atributos (ou propriedades) de QoS sero
atendidos e definir os valores (ou nveis) desses atributos. Alguns dos principais atributos de QoS
para Web Services citados por Lee e Shin (2008) so apresentados na Tabela 2.1:
2.6
Consideraes Finais
Neste captulo, foram apresentadas informaes sobre Web Services, seus conceitos, fundamentos e arquitetura. Os Web Services so implementaes da arquitetura orientada a servios
(SOA) que ganharam destaque nos ltimos anos. Devido rpida popularizao dos Web Services na indstria de TI e no meio acadmico, notou-se a necessidade de garantir a qualidade
dos Web Services. Alguns trabalhos relacionados foram citados, argumentando essa necessidade.
Um exemplo de soluo para garantia de QoS, o WSLA, foi comentado e finalmente alguns dos
13
Tabela 2.1: Atributos de QoS para Web Services (Lee e Shin, 2008)
Atributo de QoS
Descrio
Tempo de Resposta
Tempo que um servio leva para completar uma tarefa.
Latncia
Tempo necessrio para iniciar um servio requisitado.
Vazo
Taxa de processamento de um servio para atender a solicitao.
Escalabilidade
o aumento da vazo em um dado intervalo de tempo.
Disponibilidade
Consiste em o Web Service estar presente ou pronto para
utilizao.
Acessibilidade
Aspecto da qualidade de um Web Service que representa o
grau de capacidade de atender uma solicitao.
Capacidade
o nmero de requisies concorrentes que um servio permite.
Preciso
Taxa de erro de um servio durante um intervalo de tempo.
Robustez
Taxa de erro de um servio durante um intervalo de tempo.
Estabilidade
Taxa de mudana da interface do servio.
Custo
o custo envolvido na utilizao de um servio.
Segurana
Define se o servio oferece mecanismos de confidencialidade, integridade
e autenticao.
Confiabilidade
Determina se o servio oferece mecanismos confiveis para a
garantia de entrega de mensagens.
Integridade
Aspecto de qualidade de como um Web Service mantm a veracidade de
interaes de acordo com a fonte.
Desempenho
o aspecto de qualidade medido entre os termos de vazo e latncia.
Interoperabilidade Determina se o servio compatvel com os perfis de interoperabilidade.
parmetros (atributos ou propriedades) de QoS para Web Services foram listados. Alguns desses
atributos sero considerados neste projeto, pois esto presentes na literatura e so amplamente
utilizados pelas empresas de TI.
C APTULO
3
Ontologia e Web Semntica
3.1
Este captulo aborda dois conceitos importantes para o desenvolvimento desta dissertao de
mestrado que so Ontologia e Web Semntica aplicados aos Web Services. A Web Semntica
est sendo explorada nos ltimos anos, juntamente com o emprego de ontologias, para definir um
vocabulrio mais rico e aperfeioar a eficincia de mecanismos semnticos.
Neste captulo so apresentados alguns conceitos sobre Ontologia (Seo 3.2) e Web Semntica
(Sees 3.3 e 3.4), aplicados no contexto de Web Services (Seo 3.5). Na Seo 3.6, feita uma
associao de todos os conceitos e, finalmente, na Seo 3.7 so apresentadas as consideraes
finais deste captulo.
3.2
Ontologia
Ontologia um conceito que teve origem nos estudos filosficos. O termo ontologia a composio de dois ramos: onto (ser) e logia (estudo); ou seja, a ontologia pode ser considerada o
estudo do ser em uma nfase existencial.
O termo ontologia, que ficou restrito Filosofia durante anos (Carase, 2005), comeou a ser
empregado na cincia da computao a partir do final dos anos 70 (Martimiano, 2006). Com
base no conceito do estudo do ser, as ontologias facilitam a descrio dos seres, estudando suas
caractersticas, capacidades, relacionamentos, etc. Nesse contexto, pode-se notar quo importante
as ontologias so para a criao de semnticas.
15
16
3.2. ONTOLOGIA
As ontologias podem ento ser utilizadas para a criao de um vocabulrio baseado em um

determinado domnio de conhecimento, o qual pode ser compartilhado e re-utilizado. Este vocabulrio pode ser fornecido de forma explcita e com um grau de formalidade suficiente, o qual
permite o seu processamento por agentes computacionais. O grau de formalidade pode variar, e
segundo Uschold e Gruninger (1996), esse grau de formalidade pode ter quatro nveis (Uschold e
Gruninger, 1996):
Altamente Informal: utiliza livremente a linguagem natural para expressar o vocabulrio.
Semi-Informal: utiliza a linguagem natural, porm de uma forma restrita e estruturada com
bastante clareza, reduzindo assim a ambiguidade.
Semi-formal: utiliza uma linguagem artificial definida formalmente para expressar o vocabulrio.
Rigorosamente formal: os termos so definidos minuciosamente atravs de semnticas
formais, teoremas e provas que garantam a solidez e completude.
A utilizao de ontologias em cincias de computao geralmente limitada em domnios.
Esses domnios de conhecimento podem ser compartilhados e auxiliam na interoperabilidade semntica. Segundo Noy e McGuinness (2001), uma ontologia uma descrio formal e explcita dos
conceitos de um domnio de conhecimento, das suas propriedades (atributos e relacionamentos)
e restries (Noy e McGuinness, 2001). A Figura 3.1 demostra uma diviso de domnios, na
qual existe o domnio Hardware, que possui os subdomnios Perifricos e Computadores,
que por sua vez tambm contm outros subdomnios; Disp Entrada, Disp Sada, Pessoal e
Grande Porte.
Esses domnios foram descritos em uma forma que segue a viso top-down, podendo tambm
serem descritos na ordem inversa, ou seja, na viso bottom-up. Esses dois tipos de vises so
interessantes no momento de se modelar uma ontologia. A combinao de ambos (top-down e
bottom-up) tambm pode ser explorada. Alm disso, na mesma Figura 3.1 possvel observar o
domnio Informtica, o qual est relacionado com o domnio Hardware. importante destacar
que os domnios tambm podem ter propriedades, como o caso do domnio Hardware com as
seguintes propriedades: Chips, Circuitos, Transistores, Fios, Sensores, Etc.
Para desenvolver uma ontologia de forma organizada preciso uma metodologia. H diversas metodologias que podem ser empregadas tais como: Methontology (Lopez et al., 1997),
metodologia de Noy e McGuinness (2001), KACTUS (Knowledge About Complex Technical systems for multiple USe) (Bernaras et al., 1996), TOVE (TOronto Virtual Enterprise) (Gruninger e
Fox, 1995), etc. No desenvolvimento deste trabalho de mestrado est sendo considerada a Methontology (Lopez et al., 1997) em paralelo com a metodologia de Noy e McGuinness (2001) cujo ttulo
Ontology Development 101: A Guide to Creating Your First Ontology. A escolha por essas
metodologias justificada no captulo 4, onde se descreve o desenvolvimento da ontologia.
CAPTULO 3. ONTOLOGIA E WEB SEMNTICA
17
Perifricos
Disp. Sada
Disp Entrada
HARDWARE
Computadores
Pessoal
Informtica
Grande Porte
Chips
Circuitos
Transistores
Fios
Sensores
Etc
Possu
Faz parte
Domnios
Figura 3.1: Exemplo de representao de Domnios.
3.3
Web Semntica
A Web uma das maiores fontes de informao existente atualmente, sendo, portanto, importante interpretar, selecionar (ou classificar) e analisar o seu contedo. Para que mquinas (computadores) consigam tamanha proeza necessrio que elas sejam capazes de no apenas ler as
informaes, mas compreender do que se trata.
A W3C (World Wide Web Consortium) tem incentivado as pesquisas em Web Semntica. Ela
prope uma viso pioneira, na qual a informao pode ser entregue de forma explcita, proporcionando que as mquinas consigam processar e integrar informaes de uma maneira mais fcil
sugerindo assim a utilizao da Web Semntica (W3C, 2004c).
Para representar as informaes na Web, a W3C desenvolveu um framework denominado RDF
(Resource Description Framework), que permite adicionar informaes sobre determinado recurso
na Web (uma pgina, por exemplo). Dessa forma, possvel adquirir no apenas o contedo, mas
tambm informaes capazes de atribuir uma semntica quele recurso (W3C, 2004c).
A estrutura de qualquer expresso em RDF uma coleo baseada em triplas compostas por
Sujeito, Predicado e Objeto. Um conjunto de triplas denominado grafo RDF (W3C, 2004c). A
Figura 3.2 exibe os trs componentes bsicos de um arquivo RDF, no qual a Pgina 1 o Sujeito,
a Pgina 2 o Objeto e uma propriedade em comum (creator - criador) o Predicado.
18
3.4. A OWL - WEB ONTOLOGY LANGUAGE

Predicado
Sujeito
Objeto
Pgina 1
Propriedade em Comum
Pgina 2
<dc:creator>Luis Nakamura</dc:creator>
Figura 3.2: Grafo representando os componentes bsicos de um arquivo RDF.
O RDF baseado em XML, e permite a representao de relaes entre objetos, possuindo
melhores funcionalidades para representar semntica. Os documentos RDF so compostos por
declaraes sobre os recursos ou objetos representados, porm cada declarao composta pelo
objeto, por uma propriedade e o valor dessa propriedade, que pode ser at mesmo outro objeto.
Da mesma forma que o XML, o RDF tambm permite que agentes computacionais interpretem o
significado dos dados por meio das tags associadas a ele (Martimiano, 2006).
O RDF no prov nenhum mecanismo para descrever as propriedades, to pouco descrever
as relaes entre estas propriedades e outros recursos. O responsvel por obter essa respectiva
semntica o Esquema RDF (RDF Schema), que define classes e propriedades que podem ser
usadas para descrever as classes, propriedades e outros recursos (W3C, 2004b).
Alm disso, pesquisadores notaram algumas limitaes no RDF e RDFS (RDF Schema). Em
Heflin (2001), relatado que o RDF no possui um mecanismo para uma definio geral de axiomas (Heflin, 2001). Segundo Broeksta (2001), as primitivas definidas no RDF Schema no
provm uma semntica formal, e a expressividade dessas primitivas no suficiente para o desenvolvimento de modelos ontolgicos puros e de raciocnio (Broekstra et al., 2001). Dessa forma,
foi necessria a criao da linguagem OWL (Web Ontology Language), que estende o conceito do
RDF para criao de ontologias.
3.4
A OWL - Web Ontology Language
A OWL (Web Ontology Language) uma linguagem projetada para uso em aplicaes que precisam processar o contedo da informao e no apenas apresentar essas informaes para os seres
humanos. A OWL proporciona uma maior interpretabilidade do contedo da Web pelas mquinas
(computadores) do que com XML, RDF e RDF Schema, disponibilizando um vocabulrio adicional com uma semntica formal (W3C, 2004c).
19
Com a OWL possvel adicionar vocabulrios mais ricos para descrever as classes, os relacionamentos entre classes, comparao entre classes, restries de cardinalidade e as caractersticas das propriedades (Martimiano, 2006).
A linguagem OWL fornece trs subdivises, cada uma para uso especfico (W3C, 2004c):
OWL Lite: trata-se de uma definio simples de hierarquia de classes e com poucas restries de propriedades.
OWL DL (Description Logics): trata-se de uma definio de OWL que oferece funcionalidades expressivas. Permite a utilizao dos construtores da OWL, porm possui algumas
restries, mantendo a completude computacional (capacidade de ser processada) e a tomada
de deciso em um tempo finito. A OWL DL um meio termo entre a OWL Lite e a OWL
Full, e est baseada em lgicas de descrio (DL). Muitos adotam essa subdiviso como
padro para desenvolvimento.
OWL Full: a OWL mais completa, e apresenta todos os construtores disponveis sem
restrio e independente da sintaxe do RDF. Por ser muito abrangente, no h garantia que
um software seja capaz de interpretar a ontologia criada com a OWL Full.
Tim Berners-Lee apresentou em 2000 uma arquitetura em pilha (tambm denominada de camadas do bolo - layer cake), representada na Figura 3.3, para explicar os diferentes protocolos
e os desafios da Web Semntica (Berners-Lee, 2000). Segundo Antoniou e Harmelen (2008), a
camada de ontologia instanciada com duas alternativas: a OWL e uma linguagem baseada em
regras (Rules) (Antoniou e Harmelen, 2008). A Figura 3.4 mostra um modelo atualizado de pilha
da Web Semntica no qual as camadas abstratas propostas por Berners-Lee so representadas
por algumas das atuais linguagens utilizadas na rea.
Figura 3.3: Arquitetura da Web Semntica

(Berners-Lee, 2000)
Figura 3.4: Arquitetura alternativa da Web

Semntica (Antoniou e Harmelen, 2008)
Na OWL, h duas classes fundamentais: owl:Thing e owl:Nothing. A owl:Thing representa a

classe de todos os indivduos e todo recurso que uma instncia de uma classe implicitamente
20
um membro da owl:Thing. A owl:Nothing representa uma classe vazia, uma classe que no possui
membros. A classe owl:Thing a classe mais geral, enquanto a owl:Nothing a classe mais
especfica possvel; a Figura 3.5 demostra uma viso taxonmica dessas classes (Fisher et al.,
2009).
Figura 3.5: Viso Taxonmica das classes: owl:Thing e owl:Nothing (Fisher et al., 2009)
Dessa forma, todas as classes de uma ontologia em OWL so subclasses da classe owl:Thing.
As classes owl:Class e rdfs:subClassOf so utilizadas para a criao de hierarquia entre classes na
OWL. A OWL tambm fornece algumas formas de descrever propriedades (adicionando semntica). Existem diversas propriedades disponveis na linguagem OWL das quais pode-se destacar
(Antoniou e Harmelen, 2008):
Propriedades de Elementos:
Propriedade de Objeto (owl:ObjectProperty): Propriedade que relaciona objetos
outros objetos.
Propriedade de Tipo de Dados (owl:DatatypeProperty): Propriedade que relaciona
objetos a tipos de dados. A OWL utiliza os tipos de dados prescritos no XML Schema.
Propriedade Inversa (owl:inverseOf): Propriedade que determina que uma determinada propriedade inversa (contrria) a outra propriedade existente.
Propriedade Equivalente (owl:equivalentProperty): Propriedade que define que uma
determinada propriedade equivalente a outra propriedade existente.
Propriedades de Restries (owl:Restriction): Uma restrio deve ser relacionada a uma
propriedade existente, essa propriedade definida no atributo owl:onProperty:
Todos os Valores De (owl:allValuesFrom): Propriedade utilizada para especificar a
classe com os possveis valores de uma propriedade (especificada em owl:onProperty).
21
Tenha o Valor (owl:hasValue): Propriedade que especifica o valor que a propriedade

(especificada em owl:onProperty) deve ter.
Algum Valor De (owl:someValuesFrom): Propriedade utilizada para especificar a classe
e a ocorrncia de pelo menos um dos valores dentre os possveis de uma propriedade.
Cardinalidade Mnima (owl:minCardinality): Indica o valor mnimo existente em
um relacionamento. Pode utilizar datatypes para expressar restries, por exemplo:
nonNegativeInteger.
Cardinalidade Mxima (owl:maxCardinality): Indica o valor mximo existente em
um relacionamento. Tambm pode utilizar datatypes para expressar restries.
Propriedades Especiais:
Propriedade Transitiva (owl:TransitiveProperty): Define que uma propriedade transitiva. Por exemplo, se uma propriedade p dita transitiva e relaciona a classe A com a
classe B (A p B) e tambm relaciona a classe B com a classe C (B p C),e ento, sendo
transitiva, ela garante a relao entre A e C (A p C) (Fisher et al., 2009).
Propriedade Simtrica (owl:SymmetricProperty): Define a simetria entre as classes.
Por exemplo, se uma propriedade p dita simtrica e relaciona as classes A e B (A p
B) ento ela tambm garante a simetria de B e A (B p A) (Fisher et al., 2009).
Propriedade Funcional (owl:FunctionalProperty): Define uma propriedade que tem
ao menos um valor para cada objeto (Antoniou e Harmelen, 2008). Uma propriedade
funcional pode ser associada a apenas um nico valor para um indivduo em particular. Por exemplo, a data de nascimento; um indivduo pode ter apenas uma data de
nascimento.
Propriedade Funcional Inversa (owl:InverseFunctionalProperty): Define uma propriedade para a qual dois diferentes objetos no podem ter o mesmo valor (Antoniou
e Harmelen, 2008). Um exemplo uma propriedade CPF, em que diferentes indivduos no podem ter o mesmo valor de CPF.
Um exemplo de Classe, Sub-Classe, Instncia da Classe ou Indivduo e Propriedade em um
arquivo de ontologia OWL so apresentados na Figura 3.6. No incio do arquivo, tipicamente, h
um cabealho que define os espaos de nomes XML (namespaces XML- xmlns) que especificam
os vocabulrios utilizados (Smith et al., 2004).
Na Figura 3.6, as duas primeiras linhas (11 e 12) do cabealho referem-se ao namespace do
vocabulrio da ontologia corrente (wine), sendo a primeira linha (11) o namespace geral da ontologia corrente, que implica que qualquer nome declarado nesse espao pertence a ele, a menos
que esse nome tenha uma referncia para outro espao de nomes. J a segunda linha (12) define
um prefixo (vin) que associado ao namespace da ontologia para referenciar definies do vocabulrio (Martimiano, 2006). A terceira linha (13) associa o namespace corrente com o URI do
22
Figura 3.6: Exemplos de Cabealho, Classe, Sub-Classe, Instncia de Classe ou Indivduo e

Propriedade em OWL (Martimiano, 2006)
namespace xml da ontologia food (comida) e a quarta linha (14) associa a ontologia owl, que
permite a utilizao dos elementos prefixados com owl: (Classes, Propriedades citadas anteriormente), esse namespace convencionalmente includo e utilizado para introduzir o vocabulrio
OWL. Os demais namespaces (linhas 15, 16 e 17) so associados para indicar elementos de prefixo rdf, rdfs e xsd que definem vocabulrios das linguagens RDF, RDF-Schema e XML-Schema
respectivamente.
As propriedades especiais citadas anteriormente so exemplificadas pelas Figuras 3.7, 3.8, 3.9
e 3.10. A Figura 3.7 apresenta um exemplo de uma propriedade Transitiva, cujo ID tem o valor de
locatedIn (localizado em). No exemplo h trs regies (geogrficas) que so: a cidade de So
Carlos, o Estado de So Paulo e o pas Brasil. O Estado de So Paulo (SaoPauloEstado) est
localizado no Brasil e esses dois indivduos esto relacionados pela propriedade transitiva locatedIn, essa mesma propriedade relaciona os indivduos SaoCarlos e SaoPauloEstado, sinalizando
que So Carlos est localizada no Estado de So Paulo. Assim, por meio dessa propriedade transitiva possvel relacionar So Carlos com Brasil implicando que So Carlos est localizada no
Brasil, uma vez que So Carlos est localizada no Estado de So Paulo e este est localizado no
Brasil.
A Figura 3.8 possui um exemplo de propriedade simtrica, cujo ID adjacentRegion (regio
adjacente). Essa propriedade define a simetria entre duas instncias que no exemplo a Regio de
So Carlos (SaoCarlosRegion) e a Regio de Araraquara (AraraquaraRegion), a propriedade
adjacentRegion por ser simtrica, torna os dois indivduos adjacentes. Outro exemplo clssico
23
Figura 3.7: Exemplo de propriedade Transitiva

de propriedade simtrica seria uma propriedade de ID igual a marriedto (casado com) relacionando dois indivduos que so casados.
Figura 3.8: Exemplo de propriedade Simtrica

A Figura 3.9 mostra um exemplo de propriedade funcional de ID igual a hasMayor (tem
prefeito), que relaciona um domnio City" (cidade) com um Mayor (prefeito) e dessa
forma esta propriedade implica que uma cidade pode ter apenas um prefeito.
Figura 3.9: Exemplo de propriedade Funcional

A propriedade biologicalMotherOf (me biolgica de) na Figura 3.10 um exemplo de
uma propriedade funcional inversa. Essa propriedade relaciona um domnio Woman (mulher)
com um Human (humano). De uma perspectiva inversa nota-se que o ser humano deve ter
apenas um elemento dentro do domnio mulher o qual seria sua me biolgica (W3C, 2004a).
Todas essas propriedades e outras caractersticas sobre a OWL demonstram o quo eficaz essa
linguagem pode ser para gerar semntica e para apoiar a representao de ontologias. O sucesso da
24
3.5. A OWL-S - SEMANTIC MARKUP FOR WEB SERVICES
Figura 3.10: Exemplo de propriedade Funcional

linguagem OWL fez com que ela se tornasse o padro utilizado pela comunidade de Web Semntica, especialmente para descrever ontologias (Isotani et al., 2009). Por esse motivo essa linguagem
foi a escolhida para o desenvolvimento da ontologia proposta neste trabalho.
3.5
A OWL-S - Semantic Markup for Web Services
A partir da criao da OWL, vrias ontologias foram desenvolvidas. Um exemplo a OWLS (Martin et al., 2004) que prope uma semntica para Web Services. A OWL-S baseada em
classes e possui a classe servio sendo o ponto de referncia para a declarao de um Web
Service. Na Figura 3.11, possvel observar o topo do nvel de uma ontologia de servio, em
que so observadas a classe Servio, a classe ServioFundamento, a classe ServioPerfil e a
classe ServioModelo (Traduzido de (Martin et al., 2004)).
Figura 3.11: Topo do nvel de uma ontologia de servio. Traduzido de (Martin et al., 2004).
A classe Servio representa o servio Web em si e est relacionada s classes ServioPerfil,
ServioFundamento e ServioModelo por intermdio das propriedades apresenta, suporta
e descritopor, respectivamente. Essas trs classes esto envolvidas com as seguintes funes
(Martin et al., 2004):
ServioPerfil: Classe que possui propriedades com informaes sobre o servio, como
nome, descrio, categoria, classificao e parmetros.
ServioModelo: Classe que descreve como o cliente pode consumir o servio e conhecer
o passo a passo do processo at obter os resultados. Informa se um servio simples ou
composto.
25
ServioFundamento: Classe que especifica detalhes de como o servio pode ser acessado.
Geralmente especifica o protocolo de comunicao, o formato das mensagens, as portas de
comunicao, etc.
A OWL-S um exemplo de ontologia, reconhecido pela W3C, para servios web como um
todo. Contudo, outros exemplos de ontologias podem ser desenvolvidos com objetivos mais especficos.
3.6
Ontologia, Web Semntica e Web Services
As ontologias tm sido utilizadas em vrias reas na cincia da computao, geralmente naquelas que necessitam de elaborao de conhecimento, semntica e interoperabilidade, como por
exemplo, em sistemas inteligentes e de tomada de deciso. Cada rea cria e utiliza ontologias
da melhor forma que atenda s suas necessidades. Uma ontologia aborda um domnio de conhecimento, os quais geralmente variam de uma rea para outra.
Em Sistemas Distribudos a ontologia empregada em aplicaes que necessitam compartilhar
conhecimento e obter semntica. Segundo Zhou et. al. (2005), a semntica aplicada Web uma
soluo para os processos de descoberta de servios de forma automtica; para isso, necessrio
que os dados no sejam apenas lidos por mquinas, mas tambm compreendidos(Zhou et al.,
2005). Como os Web Services so implementaes da arquitetura SOA, podem ser largamente
utilizados por aplicaes como Grades Computacionais (Grids), Intercmbio Eletrnico, Servios
de Monitoramento, Computao nas Nuvens, etc.
Contudo, a expanso da utilizao dos Web Services proporciona preocupao com a qualidade
de servio. Prover QoS em Web Services no uma tarefa trivial (Lee e Shin, 2008). Clientes,
provedores, registros de servios (UDDIs) e outros elementos que compem uma arquitetura de
Web Service geralmente esto distribudos em regies geogrficas diferentes e esto sujeitos a
sofrer interferncias. Um exemplo pode ser quando um provedor de servio ficar indisponvel e
nenhuma informao passada ao UDDI. Nesse caso, esse provedor e sua lista de servios no
ficaro disponveis para o cliente, que ao tentar acess-los se deparar com um erro. Outro exemplo
quando o cliente necessita da garantia de que um servio disponha de uma caracterstica de QoS,
e identificar qual servio ou provedor fornece essa caracterstica se torna um desafio.
Uma soluo para o primeiro problema um sistema de monitoramento, cuja funo seria
monitorar os provedores de servios e, quando estivessem indisponveis, a lista de servios relacionada a tal provedor seria excluda. Outra soluo, ainda para o primeiro problema a soluo
proposta na WSARCH (Estrella, 2010), que monitora os provedores de servios e envia as requisies dos usurios apenas para os servidores que garantam o requisito de QoS desejado. Para o
segundo problema uma soluo mais elaborada deve ser empregada. No seria vantajoso consumir
o servio de tempos em tempos para avaliar a qualidade de servio. Uma soluo obrigar o
provedor de servio a se monitorar e garantir a QoS exigida pelos clientes. Para isso, h acordos
26
do tipo WSLA entre empresas e clientes. Sendo assim, pode ocorrer ento o cenrio no qual o
cliente deseja um servio com certos parmetros de QoS e os provedores garantem que os servios
tero tais caractersticas. A questo descobrir quais so os servios que atendem s caractersticas exigidas. Alm disso, preciso classificar uma enorme variedade de servios com diversos
tipos de parmetros e mtricas de QoS diferentes. Soma-se a isso a criao de uma semntica que
decida quais servios se enquadram nas necessidades do usurio.
Para tentar apresentar solues a tais problemas, vrias pesquisas tm sido desenvolvidas
visando a criao e utilizao de ontologias (Papaioannou et al., 2006), (Tran, 2008), (Maximilien
e Singh, 2004), (Fakhfakh et al., 2008) e (Aklouf e Rezig, 2009). Definir claramente as tarefas que
devem ser realizadas um passo importante para o desenvolvimento de ontologias, uma vez que
no existe um consenso sobre qual metodologia deve ser seguida. Normalmente desenvolvedores
acabam criando suas prprias ontologias (Martimiano, 2006).
Para exemplificar, considera-se um Web Service que tenha duas implementaes disponveis
que realizam a fatorao de um nmero. O provedor classificou essas duas implementaes de
servios em dois domnios diferentes, uma com um servio em um servidor dedicado e tolerante
a falhas, com replicao e segurana garantida (domnio com proviso de QoS), e o outro em um
servidor compartilhado vulnervel a vrios problemas (domnio sem proviso de QoS). Depois de
classificado, o provedor resolveu cobrar pelo servio no servidor dedicado. Quando o cliente requisitar a lista de servios disponveis no UDDI, sero retornados dois servios. Sem informaes
suficientes ou sem a utilizao de ontologias para criar uma semntica, o cliente no poderia saber
qual servio possui mais garantias de QoS e qual tem o menor custo.
Neste exemplo, surge uma soluo mais simples, que seria avisar o cliente de que o servio
localizado no IP ou DNS pr-definido possui um preo superior, pois tem garantias de qualidade
de servio. uma soluo, mas no interessante, pois na prtica servidores dedicados hospedam
mais de um servio e cada um pode ter custos diferentes que envolvam tecnologias e recursos
diferentes. Uma melhor soluo seria empregar ontologias para classificar os servios e prover
um contexto semntico para que os clientes possam acessar os servios de acordo com as suas
necessidades de uma forma mais dinmica e automtica.
3.7
Consideraes Finais
Este captulo inicialmente abordou o conceito de Ontologia, posteriormente o relacionou com

Web Semntica e por fim associou os dois assuntos com Web Services. O conceito de ontologia
aplicvel na informtica quando relacionado ao mapeamento de domnios. A Web Semntica
foi apresentada e exemplificada com tecnologias utilizadas de forma sucinta, uma vez que esse
assunto abrange uma enorme quantidade de conceitos e existem diversas fontes disponveis. Alm
disso, a Web Semntica continua a evoluir e um grande volume de dados tornou-se disponvel
nos ltimos anos (Oren et al., 2009). Foi dado um enfoque para a linguagem OWL, a qual foi
27
utilizada neste projeto e tambm para demonstrar a sua capacidade de utilizao e criao de
semntica. O captulo tambm apresentou uma argumentao sobre a utilizao de Web Semntica
com ontologia para um enfoque baseado na qualidade de servios em Web Services.
C APTULO
4
Ontologia do UDOnt-Q
4.1
Este captulo descreve a ontologia que foi desenvolvida especialmente para o mdulo UDOnt-Q
(Universal Discovery with Ontology and QoS). O mdulo e os algoritmos de busca sero explicados no prximo captulo. A ontologia um elemento importante neste projeto de mestrado, pois
nela que ficam armazenadas as informaes de qualidade de servios que so acessadas pelos
algoritmos. Esses por sua vez, tm a funo de encontrar os melhores servios para os clientes. A
Figura 4.1 exibe um modelo abstrato da relao entre o cliente, mdulo, algoritmos e a ontologia.
Mdulo UDOnt-Q
Cliente
Algoritmos
Ontologia
Figura 4.1: Modelo abstrato da relao entre o cliente, mdulo, algoritmos e a ontologia.
Na seo 4.2 so apresentados os processos de desenvolvimento da ontologia, conceitos e
ferramentas utilizados. Na seo 4.3 so citados os elementos (classes, subclasses, propriedades)
29
30
4.2. DESENVOLVIMENTO DA ONTOLOGIA DO UDONT-Q
que compem a ontologia. Nessa mesma seo explicada a organizao dos elementos a fim
de representar uma arquitetura para Web Services com qualidade de servio. A seo 4.4 reserva
espao para as consideraes finais a respeito deste captulo.
4.2
Desenvolvimento da Ontologia do UDOnt-Q
O desenvolvimento da ontologia seguiu os procedimentos propostos em duas metodologias:

Methontology (Lopez et al., 1997) e Metodologia de Noy e McGuinness (Noy e McGuinness,
2001).
4.2.1
Methontology
A escolha pela Methontology foi influenciada pelo fato desta ser uma metodologia baseada no
padro IEEE 1074-1995 para desenvolvimento de software (Martimiano, 2006). Essa metodologia
consiste em um mtodo estruturado para construir ontologias a partir do zero. Ela leva em considerao o ciclo de vida das ontologias4 , propondo um prottipo evolutivo composto pelas seguintes
fases (Lopez et al., 1997) (Lopez et al., 1999):
1. Aquisio do Conhecimento (Knowledge Acquisition): Esta atividade independente no
processo de desenvolvimento da ontologia, porm coincide com outras atividades. A maior
parte da aquisio de conhecimento feita simultaneamente com a fase de especificao de
requisitos. Os especialistas (experts), livros, figuras, tabelas e at mesmo outras ontologias
so fontes de conhecimento que podem ser consultados. Podem-se utilizar algumas tcnicas durante este processo, como por exemplo: troca de ideias (brainstorming), entrevistas,
anlises formais e informais de textos, etc.
2. Especificao (Specification): O principal objetivo desta fase a criao de um documento
de especificaes estrito em linguagem natural utilizado para caracterizar a ontologia como:
Informal, Semi-Formal ou Formal. Alm da formalidade, o propsito e escopo (domnio) de
cada termo da ontologia devem ser includos.
3. Conceituao (Conceptualization): Nesta atividade, o domnio do conhecimento estruturado em um modelo conceitual que descreve o problema e a sua soluo em termos do
vocabulrio de domnio identificado na atividade de especificao da ontologia. Portanto,
facilitando o usurio final a identificar se a ontologia til ou no sem precisar inspecionar
o cdigo fonte. Adicionalmente, possvel verificar o escopo e a completude de vrias
ontologias, alm da capacidade de reuso e compartilhamento.
4
Segundo Lopez et al. (1997), o ciclo de vida das ontologias composto por: Especificao, Conceituao,
Formalizao, Integrao, Implementao e Manuteno.
CAPTULO 4. ONTOLOGIA DO UDONT-Q
31
4. Integrao (Integration): A atividade de Integrao tem o objetivo de acelerar o processo

de construo da ontologia considerando o reuso de definies j construdas em outras
ontologias ao invs de iniciar do zero. O resultado dessa atividade um documento de
integrao que se resume a informaes sobre a meta-ontologia que ser utilizada e sobre os
termos os cujas definies esto sendo utilizadas.
5. Implementao (Implementation): Para a atividade de implementao de ontologias requerido o uso de ambiente de desenvolvimento que d suporte meta-ontologia e s ontologias selecionadas na fase de integrao. O ambiente deve realizar anlises (sintticas
e lxicas), possuir um editor (para adicionar, remover ou modificar definies), um navegador (browser) para inspecionar as ontologias e suas definies, um pesquisador (searcher)
para procurar por definies mais apropriadas e um validador para detectar inconsistncias,
incompletude e redundncia de conhecimento.
6. Avaliao (Evaluation): A avaliao a realizao de um julgamento tcnico das ontologias. Ela agrupa dois termos: Verificao (Verification) e Validao (Validation). A verificao se refere ao processo tcnico que garante a exatido de uma ontologia. A validao
garante que as ontologias, o ambiente de software e a documentao correspondam ao sistema suposto.
7. Documentao (Documentation): A atividade de documentao feita durante todo o processo de desenvolvimento da ontologia. A cada fase gerado um documento, por exemplo,
aps a fase de aquisio do conhecimento, um documento aquisio do conhecimento
gerado. Esse processo repetido at a fase de Avaliao.
O desenvolvimento da ontologia procurou seguir o ciclo de vida proposto anteriormente e a
execuo de cada fase foi realizada da seguinte forma:
1. Aquisio do Conhecimento: O conhecimento sobre o domnio referente arquitetura de
Web Services com qualidade de servio foi obtido da leitura e anlise de livros, artigos e
at mesmo da ontologia da OWL-S. Outra fonte de conhecimento utilizada foi atravs de
entrevistas e troca de ideias com especialistas da rea de sistemas distribudos (professores,
alunos de doutorado e mestrado). A concluso dessa fase foi que uma ontologia menos
complexa que da OWL-S poderia ser desenvolvida levando em considerao a parte de acordos de nveis de servios (SLA) entre os clientes e provedores de servio. Os detalhes da
aquisio de conhecimento foram obtidos paralelamente fase de Especificao.
2. Especificao: Na fase de especificao foram descritos para cada termo (elemento) da
ontologia a sua formalizao, escopo (domnio) e propsito. Esta fase foi til para definir
os elementos que compem a ontologia, detalhando informaes e especificando a funo
(propsito) de cada um deles. O resultado dessa fase foi a criao de um documento de
especificaes que se encontra ao final deste trabalho (Anexo 1).
32

3. Conceituao: Nesta fase foram criados diversos documentos buscando-se modelar o conceito da ontologia a fim de represent-la facilitando o seu entendimento para os usurios.
Alguns desses documentos recomendados por Lopez et al.(1999) so: Glossrio de Termos
(Glossary of Terms), rvore de Classificao de Conceitos (Concept-Classification Tree),
Diagramas de Relaes Binrias (Binary-Relations Diagrams), Dicionrio de Conceitos
(Concept Dictionary), Tabelas de Relaes Binrias (Binary-Relations Tables), Tabela de
Instncias (Instance Table) e Tabela de Atributos das Instncias (Instance-attribute Table).
Todos esses documentos fornecem informaes relevantes antes do processo de implementao da ontologia e esto disponveis no final deste trabalho (Anexo 2).
4. Integrao: Esta etapa no foi considerada no desenvolvimento da ontologia do UDOnt-Q,
pois, ela foi projetada para ser simples e servir apenas como base de conhecimento para
o mdulo UDOnt-Q. Portanto, ela foi criada a partir do zero e no houve integrao com
outras ontologias.
5. Implementao: A recomendao de Lopez et al. (1999) era a utilizao do ODE (Ontology
Design Environment) para apoiar o projetista de ontologias no desenvolvimento da ontologia. Porm, uma ferramenta mais atual e amplamente conhecida para o desenvolvimento de
ontologias o Protg5 . A escolha pelo Protg justificada pelo fato dele trabalhar com
a linguagem OWL (apresentada no captulo anterior). Mais informaes sobre o Protg e
sobre a implementao da ontologia esto na subseo 4.2.3.
6. Avaliao: A ontologia foi submetida a avaliaes por meio da anlise tcnica de seus desenvolvedores e tambm por meio de verificaes e validaes feitas pelo Protg em conjunto
com mquinas de inferncias (racionalizadores - reasoners). Esta fase foi til para correes
e eliminao de termos (elementos e classes) desnecessrios. Por exemplo, inicialmente na
ontologia havia classes de tipos (TypeClass) que definiam um tipo para cada servio, cliente
e qualidade de servio. Essas classes de tipo foram substitudas por subclasses que possuem
caractersticas que determinam um tipo especfico de cliente, servio e QoS.
7. Documentao: Esta fase foi cumprida e resultou em diversos documentos e informaes
que esto apresentados neste captulo e em alguns anexos deste trabalho.
4.2.2
Metodologia de Noy e McGuinness
A Metodologia de Noy e McGuinness (2001) tambm teve influncia no desenvolvimento da

ontologia deste projeto, principalmente na parte de implementao. O documento Ontology Development 101: A Guide to Creating Your First Ontology que expe uma metodologia para a
criao de ontologias tambm um guia prtico de desenvolvimento. Portanto, alm de todo o contedo terico, esse documento tambm oferece exemplos de desenvolvimento prtico, utilizando
5
http://protege.stanford.edu/
33
a ferramenta Protg. Essa mesma ferramenta, em uma verso mais atualizada, foi emprega no
desenvolvimento da ontologia do UDOnt-Q.
Os autores dessa metodologia afirmam que: no h nenhum modo correto ou metodologia
para o desenvolvimento de ontologias (Noy e McGuinness, 2001). Contudo, eles propem um
possvel processo de desenvolvimento baseado em sete etapas, como descritas a seguir (Noy e
McGuinness, 2001):
1. Determinar o domnio e escopo da ontologia (Determine the domain and scope of the
ontology): Nesta etapa os autores propem que os projetistas de ontologias respondam a
algumas perguntas bsicas com o objetivo de determinar o domnio e escopo da ontologia.
2. Considerar o reuso de ontologias existentes (Consider reusing existing ontologies): Os
autores argumentam que muitas ontologias j esto disponveis em formato eletrnico e
encorajam que sejam reutilizadas.
3. Enumerar os termos importantes na ontologia (Enumerate important terms in the ontology): Documentar uma lista de todos os termos que os projetistas de ontologias desejam
pode ser til para criar afirmaes sobre eles ou explic-los para um usurio. preciso
acrescentar informaes sobre os termos e quais so as suas propriedades.
4. Definir as classes e a hierarquia de classe (Define the classes and the class hierarchy):
Os conceitos da ontologia podem ser classificados ou agrupados em classes e subclasses que
podem definir uma taxonomia proporcionando uma hierarquia de classe. Os autores citam
trs propostas para o desenvolvimento da hierarquia de classe (Uschold e Gruninger, 1996):
a. Top-Down: O desenvolvimento inicia pela definio dos conceitos mais gerais no
domnio da ontologia e seguem at os conceitos mais especficos.
b. Bottom-Up: o contrrio do Top-Down: o desenvolvimento inicia pela definio
dos conceitos mais especficos no domnio da ontologia e seguem at os conceitos mais
gerais.
c. Combination: O desenvolvimento segue uma combinao das duas propostas anteriores: Top-Down e Bottom-Up.
5. Definir as propriedades (slots) das classes - (Define the properties of classes-slots): As
propriedades das classes (slots) devem ser definidas com o objetivo de prover informao
suficiente para responder a questes sobre o domnio da ontologia.
6. Definir as facetas para as propriedades (slots) (Define the facets of the slots): As propriedades (slots) podem ter facetas diferentes para descrever caractersticas como: tipo de
valor (Value Type) ou tipo de dado, por exemplo: String, Number, Boolean, etc., cardinalidade (Cardinality) e domnio e variao (Domain and Range) que relaciona a propriedade
com classes e tipos de instncias respectivamente.
34

7. Criar Instncias (Create instances): A ltima etapa proposta pelos autores a criao de
instncias de classes, tambm chamados de indivduos da ontologia. Um indivduo de uma
classe possui todas as atribuies (propriedades) de sua classe, ele utilizado na representao de seres do mundo real (dentro do escopo/domnio definido).
possvel notar algumas semelhanas entre as duas metodologias que foram estudas para o
desenvolvimento da ontologia deste trabalho. A etapa 1 da metodologia de Noy e McGuinness
sintetiza as fases 1 e 2 da Methontology. A etapa 2 correspondente fase 4 da Methontology.
As etapas restantes podem se comparadas s fases 3 e 5 da Methontology. Apesar da Metodologia
de Noy e McGuinness no ter fases especficas para as etapas 6 e 7 da Methontodoly, no decorrer
do documento atividades semelhantes so comentadas. Por outro lado, o documento rico em
sugestes e exemplos prticos, guiando o desenvolvedor na criao de sua primeira ontologia.
4.2.3
Ferramentas para o desenvolvimento da Ontologia
Para o desenvolvimento da ontologia foram utilizadas trs ferramentas: o Protg, o racionalizador Pellet6 e uma aplicao denominada UDOnt-Q WorkLoad. Esta ltima foi desenvolvida
em Java com recursos da Web Semntica para agilizar o processo de criao de indivduos na
ontologia.
4.2.3.1 Protg
Para a criao da ontologia com a linguagem OWL foi utilizada a ferramenta Protg criada
pelo Centro de Pesquisas para Informtica Biomdica da Universidade de Stanford (Gennari et al.,
2002). A ontologia desenvolvida foi salva em um arquivo, cujo nome UDOnt-Q_Ontology.owl
e disponibilizada por meio de uma URI: http://localhost:8080/ontologies/UDOnt-Q_Ontology.owl
no servidor Web Apache.
Inicialmente uma ontologia em OWL criada no Protg possui uma classe padro (default)
denominada Thing (owl:Thing), que constitui a classe raiz dentro de uma hierarquia de classes
na ontologia; todas outras classes criadas ficam abaixo da classe Thing. A Figura 4.2 mostra a
hierarquia de classes da ontologia do UDOnt-Q mapeada pelo plugin OWLViz7 .
O primeiro passo da implementao da ontologia foi a criao das classes. Adotou-se a proposta Top-Down, para o desenvolvimento da hierarquia de classes. Alm disso, foram criadas propriedades (slots) para o relacionamento entre as classes (Object Properties) e propriedades entre
classes e dados (Data Properties). O Protg disponibiliza abas para a criao de tais propriedades,
nas quais podem ser especificados os domnios e variaes (domain and ranges).
6
http://clarkparsia.com/pellet
OWLViz um OWL plugin para Protg, ele permite a visualizao e a navegao incremental da hieraquia
de classes em OWL, permitindo a comparao da hierarquia de classe afirmada (asserted) e da hierarquia de classe
inferida (inferred) (http://www.co-ode.org/downloads/owlviz/).
7
35
Figura 4.2: Mapeamento da Hierarquia de Classes do UDOnt-Q. (Nakamura et al., 2011a)

A Figura 4.3 exibe uma parte da aba para criao de propriedades entre classes (Object Properties).
Figura 4.3: Parte da aba de propriedades entre classes (Object Properties).

O Protg tambm possui uma aba especfica para a criao de indivduos, onde, o desenvolvedor pode criar, excluir e manipular dados de indivduos. Pode-se definir um tipo para o indivduo,
36
por exemplo, indicando que ele representa uma instncia de uma determinada classe. As classes,
propriedades e indivduos criados na ontologia so explicados em mais detalhes na seo 4.3.
Alm de facilitar e agilizar a criao de ontologias, o Protg tambm conta com outro ponto
interessante que a existncia de mquinas de inferncias (racionalizador - reasoners). Elas oferecem diversos servios, que permitem realizar diversas consultas e validaes na ontologia. A
mquina de inferncia utilizada neste trabalho foi a Pellet e mais detalhes sobre ela so apresentados na prxima subseo.
4.2.3.2 Pellet
Pellet escrita em Java e possui seu cdigo aberto sob uma licena de utilizao liberal 8 . Ele
avalia ontologias desenvolvidas com a linguagem OWL DL (OWL Description Logics), verificando
se essas ontologias esto de acordo com os servios de inferncia definidos pela lgica de descrio
(DL), denominados (Sirin et al., 2007):
Consistncia: Assegura que uma ontologia no contm qualquer fato contraditrio.
Conceito de satisfao: Verifica se possvel uma classe possuir instncias. Se a classe
no satisfaz, ento a definio de uma instncia da classe causar a inconsistncia de toda a
ontologia.
Classificao: Processa as relaes entre as classes e subclasses para determinar a hierarquia.
Realizao: Considera as classes mais especficas que um indivduo pertence, encontrando
assim as instncias (tipos diretos - direct types) de um indivduo.
Dessa forma, a mquina de inferncia Pellet oferece recursos teis para avaliar ontologias criadas na linguagem OWL-DL. Por este motivo ela foi adicionada ao Protg e utilizada no processo
de desenvolvimento da ontologia e na criao do mdulo UDOnt-Q.
4.2.3.3 UDOnt-Q WorkLoad
Para representar um ambiente real pode ser necessria a criao de diversos indivduos de diferentes tipos (classes). A criao manual de uma grande quantidade de indivduos por meio da ferramenta Protg uma tarefa trabalhosa, principalmente se eles possurem diversas propriedades
de objetos e dados.
A ferramenta UDOnt-Q WorkLoad foi desenvolvida com o objetivo de acelerar o processo de
criao de indivduos. Ela foi desenvolvida com na linguagem Java e faz uso de um componente
8
Pellet est sob a licena AGPL v. 3 (http://www.fsf.org/licensing/licenses/agpl-3.0.html)
37
denominado (CIS - Common Information Shared) pertencente ao mdulo que ser apresentado
no captulo 5.
O funcionamento dessa ferramenta apresentado no final da prxima seo, pois para o melhor
entendimento interessante ter conhecimento dos elementos e propriedades da ontologia.
4.3
Elementos da Ontologia do UDOnt-Q
A ontologia destinada ao mdulo UDOnt-Q foi criada com o intuito de representar os principais
elementos participantes do domnio de uma arquitetura de Web Services com QoS. Alguns desses
elementos merecem destaque (Nakamura et al., 2011a):
Clients: Os clientes so os elementos que requisitam servios com qualidade, para isso eles
assinam acordos com os provedores de servios.
Providers: Os provedores de servios devem prover os servios web com a qualidade adequada, caso contrrio podem estar sujeitos a penalidades e/ou multas.
Services: Representam os Web Services que so providos pelos provedores, eles tambm
so consumidos pelos clientes. Os Web Services devem ser analisados e suas caractersticas funcionais e principalmente as no funcionais (valores e atributos de QoS) devem ser
especificados.
Agreements: So os acordos estabelecidos entre os clientes e os provedores. O acordo de
um cliente indica qual a QoS desejada por ele.
QoS: a qualidade de servio pertencente a um determinado servio ou aquela contratada
em um determinado acordo, ela contm nveis e atributos de qualidade.
Cada um dos elementos representado por uma classe na ontologia do UDOnt-Q que pode
ter subclasses, constituindo assim uma hierarquia de classes. Alm disso, elas podem estar relacionadas entre si ou relacionadas com dados por meio de propriedades (Object/Data Properties).
Essas propriedades podem ter atributos ou caractersticas que expressam informaes sobre o relacionamento e, dessa forma, a mquina poder ser capaz de entender o significado semntico do
relacionamento criado por uma propriedade. A linguagem OWL utilizada no desenvolvimento da
ontologia possui propriedades que permitem expressar tais informaes.
As propriedades que relacionam classes (Object Properties) na ontologia so:
hasQoS: uma propriedade funcional que relaciona a classe Agreement com a classe QoS.
Ela implica que um Acordo deve estar relacionado com apenas uma QoS (tem QoS). A
propriedade inversa a esta a isQoSOf.
38
4.3. ELEMENTOS DA ONTOLOGIA DO UDONT-Q

hasAgreement: uma propriedade funcional que relaciona a classe Client com a classe
Agreement. Ela indica que um Cliente deve estar relacionado com apenas um acordo (tem
acordo). A propriedade inversa a esta a isAgreementOf.
hasService: uma propriedade que pode relacionar a classe Provider com a classe Service
(tem Servio). Esta classe no funcional, podem existir provedores com mais de um
servio e tambm provedores que no disponham de nenhum servio. A propriedade inversa
a esta a isServiceOf.
hasServiceQoS: uma propriedade funcional que relaciona a classe Service com a classe
QoS (tem Servio QoS). Ela exige que um Servio esteja relacionado com uma QoS. A
propriedade inversa a esta a isServiceQoSof.
Alm das propriedades de objetos, tambm foram criadas diversas propriedades que relacionam
dados (Data Properties). O objetivo principal dessas propriedades armazenar informaes sobre
as instncias de classes (indivduos) na ontologia. Portanto, a maior parte do conhecimento da
ontologia est localizada em propriedades de dados instanciadas nos indivduos. Alguns exemplos
de propriedades de dados so:
hasServiceName: propriedade com o tipo de dado String que utilizada para armazenar
o nome de um individuo da classe Service.
hasClientAddress: propriedade com o tipo de dado String que utilizada para armazenar
o endereo (IP) de um indivduo da classe Client.
hasServiceAddress: propriedade com o tipo de dado String que utilizada para armazenar
o endereo (IP) de um indivduo da classe Service.
hasResponse_TimeContentValue: propriedade com o tipo de dado Double que utilizada para armazenar o valor (nvel) de tempo de resposta (em milissegundos) de um indivduo da classe QoS. Dessa forma, pode-se informar ou recuperar, o nvel do atributo tempo
de resposta de uma determinada qualidade de servio. Essa qualidade pode ser tanto de um
acordo estabelecido entre os clientes e os provedores, como a qualidade de um servio que
foi previamente analisado pelo provedor.
Para cada atributo de QoS h uma propriedade de dado correspondente na ontologia e diversas
outras que agregam informaes sobre os seus elementos (Clientes, Servios, Provedores, etc.).
Das cinco classes, quatro delas possuem trs subclasses, conforme exibe a Figura 4.2 na seo
anterior. As classes Client, Service e QoS possuem trs subclasses que correspondem aos clientes,
servios e qualidades de servio do tipo ouro (Gold), prata (Silver) e bronze (Bronze) respectivamente. O que determina se um servio pertence a uma determinada subclasse a sua QoS (relacionado pela propriedade hasServiceQoS), ou seja, se um servio est relacionado a uma QoSGold
39
ento ele inferido como sendo um ServiceGold. Da mesma forma, o cliente est relacionado a
um acordo (Agreement) que pode pertencer a uma das trs subclasses (HeavyAgreement, MediumAgreement e LightAgreement). Cada acordo est relacionado a uma QoS que determina a sua
subclasse, ou seja, se um acordo est relacionado com a QoSGold ento ele inferido como um
HeavyAgreement, pois a QoSGold exige que o acordo seja rigoroso. Para determinar se uma QoS
Gold, Silver ou Bronze a mquina de inferncia deve verificar os valores (nveis) dos atributos de
cada QoS e por meio de comparaes com as restries de Equivalncias de Classes, assim ela
determina qual a subclasse desta QoS. A ideia de utilizar restries para equivalncias de classes
foi motivada por exemplos em um tutorial que faz uso da ontologia Pizza 9 . A Figura 4.4 exibe um
exemplo das restries de equivalncia da subclasse QoSGold. As restries (ou condies) para
que qualquer outro elemento da ontologia seja um elemento equivalente a classe QoSGold so as
seguintes (Nakamura et al., 2011a):
Ter a classe QoS como classe pai (superclass) ou ser subclasse de QoS.
Ter o valor da propriedade hasResponse_timeContentValue menor ou igual a 500.00 ( significa que o tempo de resposta deve ser menor ou igual a 500 milissegundos).
Possuir o valor da propriedade hasCostContentValue maior ou igual a 1.00 (significa ter o
custo maior ou igual a 1 unidade monetria).
Possuir o valor da propriedade hasAvailabilityContentValue maior ou igual a 98.00 (significa ter uma disponibilidade do servio maior ou igual a 98% do tempo).
Figura 4.4: Restries de Equivalncia da classe QoSGold.

Da mesma forma existem restries de equivalncias de classe para as subclasses QoSSilver e
QoSBronze. Porm os valores dos intervalos em cada propriedade so diferentes. No caso da subclasse QoSSilver os valores dos atributos de QoS devem estar em um intervalo entre (between) dois
9
A ontologia Pizza (http://www.co-ode.org/ontologies/pizza/pizza.owl) um exemplo utilizado no tutorial pela

Universidade de Manchester na Edio 1.2 de Maro de 2009 o qual exibe um exemplo da utilizao de equivalncia
de classe por restries de propriedades de dados. Este exemplo est localizado no Captulo 5 desse tutorial (Holger
et al., 2009).
40
4.3. ELEMENTOS DA ONTOLOGIA DO UDONT-Q
valores, sendo o limite superior o valor mnimo do atributo da QoSGold e o limite inferior o valor
mximo do atributo da QoSBronze. Por exemplo, para equivalncia com a subclasse QoSBronze
as restries exigiam que a propriedade hasResponse_timeContentValue tivesse valor maior que
1000 (1 segundo), a propriedade hasAvailabilityContentValue valor menor que 95 (disponibilidade menor que 95%) e a propriedade hasCostContentValue tivesse um valor menor que 0.50
(custo menor que 0.50 de uma unidade monetria). Para a equivalncia com a subclasse QoSSilver
as restries exigem que as propriedades tenham valores limitados. Os valores do limite superior
devem estar abaixo dos valores das propriedades da subclasse QoSGold e os valores do limite
inferior devem estar acima dos valores das propriedades da subclasse QoSBronze.
Uma vez consistente a ontologia pode ser utilizada como base de conhecimento para buscas
semnticas e a classificao por meio da inferncia permite que novos indivduos possam ser criados para representar o mundo real sem a necessidade de serem previamente rotulados com relao
a sua qualidade, pois um servio pode ser criado na ontologia como sendo um individuo da classe
Service (superclass) que possui uma qualidade de servio genrica (individuo da classe QoS (superclass)). Dessa forma, no momento que a mquina de inferncia inferir sobre a ontologia, ela
ir analisar as restries e classificar esse indivduo como equivalente a uma das trs subclasses
(realizando assim o processo de classificao).
Para encontrar o servio adequado, o algoritmo deve primeiramente buscar o indivduo que
representa o cliente dentro da ontologia. Para isso, ele compara o atributo de endereo do cliente
na ontologia (hasClientAddress) com o IP recuperado pelo mdulo. Aps encontrar o cliente
na ontologia, deve-se buscar o seu acordo e a partir dele possvel identificar a QoS acordada.
Quando inferida, esta QoS ser equivalente a uma das trs subclasses (QoSGold ou QoSSilver ou
QoSBronze), o algoritmo deve busca os servios que possuam QoS na mesma subclasse da QoS
do acordo do cliente.
Dessa forma, a seleo de servios com qualidade realizada sem a preocupao de uma
anlise humana, basta que as QoSs dos servios sejam cadastradas corretamente e que os limites e
intervalos que classificam os acordos sejam coerentes nas restries de equivalncia de classe de
cada subclasse de QoS.
Diversos indivduos podem ser criados na ontologia para representar os provedores, servios,
clientes, acordos, QoS do mundo real. Apesar da criao de indivduos no Protg ser simples, em
grande quantidade esta atividade torna-se muito trabalhosa, entediante e consequentemente poder
ocasionar erros. Por esse motivo, foi desenvolvida a ferramenta (UDOnt-Q WorkLoad) citada
anteriormente na subseo 4.2.3.3.
Nessa ferramenta, os indivduos, propriedades e suas respectivas informaes so criados de
forma incremental e alguns valores de propriedades de dados so atribudos de forma aleatria.
Contudo, os valores aleatrios devem estar dentro de um intervalo definido pelo o desenvolvedor.
Por exemplo, foram criados indivduos de servios: USPService1, USPService2, USPService3,
... , USPService1200; para cada individuo de servio foram criados indivduos de QoS: USPService1QoS, USPService2QoS, USPService3QoS, ... , USPService1200QoS, que foram relaciona-
41
dos pela propriedade hasServiceQoS. Cada indivduo de QoS possui um valor (nvel) do atributo
Tempo de Resposta que informado em uma propriedade de dado (hasResponse_TimeContentValue).
Este valor, gerado aleatoriamente, deve estar dentro de um intervalo definido pelo desenvolvedor.
Assim, pode-se inferir e definir quais sero as classes dos servios e das qualidades de servio. Da
mesma forma so criados os outros elementos e propriedades da ontologia.
No Anexo 3 desta monografia possvel observar como foi feita a criao de alguns elementos
da ontologia.
4.4
Consideraes Finais
Neste quarto captulo foram apresentadas as duas metodologias utilizadas no desenvolvimento

da ontologia proposta para o mdulo UDOnt-Q. As ferramentas utilizadas para a implementao
da ontologia tambm foram descritas. Ao final os elementos da ontologia foram explicados em
conjunto com o funcionamento semntico que o algoritmo deve seguir para selecionar Web Services com a qualidade de servio acordada pelos clientes.
C APTULO
5
UDOnt-Q - Universal Discovery with
Ontology and QoS
5.1
Este captulo aborda o desenvolvimento de um mdulo denominado UDOnt-Q (Universal Discovery with Ontology and QoS) com a funo de pesquisar servios no registro de servios (UDDI)
baseando-se em parmetros de QoS. Para realizar tal pesquisa, o mdulo faz uso de recursos da
Web Semntica e da ontologia apresentada no captulo anterior. Na seo 5.2 so apresentados
brevemente a metodologia e as ferramentas utilizadas para o desenvolvimento do UDOnt-Q. Na
seo 5.3 so apresentados os componentes e a estrutura do mdulo. Na seo 5.4 so apresentadas
as consideraes finais deste captulo.
5.2
Metodologia e Ferramentas
Em uma arquitetura para Web Services com QoS h diversas informaes sobre os provedores,
servios, acordos e clientes que geralmente no esto disponveis, e quando esto nem sempre esto
organizadas de uma forma explcita com uma semntica que permita que agentes computacionais
faam inferncias e tomem decises como, por exemplo, qual(is) o(s) melhor(es) servio(s) que
atende(m) a um acordo de um determinado cliente? Uma opo para organizar tais informaes
da ltima forma descrita por meio da criao de ontologias. Portanto, as ontologias podem representar uma base de conhecimento. Contudo, seria muito trabalhoso para o ser humano acessar e
43
44
5.2. METODOLOGIA E FERRAMENTAS
verificar informaes na ontologia manualmente. Esse problema aumenta dependendo do tamanho

da ontologia e caso seja necessrio realizar inferncias de algumas informaes, o espao temporal
para isso seria enorme e poderia resultar em erros.
Para solucionar tais problemas, empresas como a HP e grupos de pesquisa em Web Semntica desenvolveram APIs e ferramentas para que as ontologias fossem utilizadas, manipuladas e
inferidas por programas de computador. Um exemplo de API para acesso e manipulao de ontologia o Jena, discutido na subseo 5.2.2. Outra ferramenta, comentada anteriormente na seo
4.2.3, o Pellet, utilizado para realizar validaes, verificaes e inferncias na ontologia. Porm,
para fazer uso dessas ferramentas se fez necessrio o desenvolvimento do mdulo UDOnt-Q. Pelo
fato dos cdigos fontes do Jena e Pellet serem implementados na linguagem Java, o mdulo tambm foi desenvolvido nesta mesma linguagem para facilitar a integrao entre eles. Alm disso,
a linguagem Java amplamente utilizada em trabalhos acadmicos, pois ela livre, produtiva,
orientada a objetos e multi-plataforma.
5.2.1
Metodologia gil (Agile)
A metodologia gil (Agile) de desenvolvimento de software prope a utilizao de processos

mais integrados e geis entre a equipe de desenvolvimento e o cliente promovendo entregas contnuas (ou incrementais) de software com algum valor agregado. Essa metodologia no se prende
tanto s documentaes e as informaes de maior valor so passadas diretamente pelos clientes.
Segundo Ambler (2002), h quatro declaraes de valores que definem o manifesto gil (Ambler,
2002):
Indivduos e interaes acima de processos e ferramentas;
Software funcional acima de documentao compreensiva;
Colaborao do cliente acima da negociao do contrato;
Respondendo as mudanas acima de seguir um plano;
O desenvolvimento do mdulo UDOnt-Q foi baseado na metodologia gil e a opo por sua
utilizao justificada por proporcionar uma maior interao, facilidade de alteraes no decorrer
do desenvolvimento e, principalmente, resultados mais rpidos com entregas continuas de partes
funcionais que agregam valor ao produto final. Uma parte da documentao mnima produzida
neste trabalho de mestrado apresentada na seo 5.3.
5.2.2
Ferramentas
Diversas ferramentas foram empregadas para o desenvolvimento do mdulo. Alm do ambiente integrado de desenvolvimento (IDE - Integrated Development Environment), que no caso deste
CAPTULO 5. UDONT-Q - UNIVERSAL DISCOVERY WITH ONTOLOGY AND QOS
45
projeto foi utilizado o Eclipse10 , outras bibliotecas foram utilizadas como, por exemplo, drivers de
conexo para acesso ao banco de dados MySQL11 .
As principais ferramentas utilizadas pelo o mdulo que merecem destaque so:
Pellet: Mquina de Inferncia (racionalizador - reasoner) Pellet foi comentada anteriormente na seo 4.2.3. Acrescenta-se ainda que Pellet na verso 2.2.2 possui um pacote
especfico para consultas em arquivos OWL-DL (pellet-query-src.jar). Nesse pacote, dentro
do namespace (com.clarkparsia.pellet.sparqldl) h classes que permitem realizar, programaticamente, consultas na ontologia com a linguagem SPARQL-DL (SPARQL Query for
OWL-DL) (Sirin e Parsia, 2007). Essa linguagem uma variao da linguagem de consulta SPARQL (SPARQL Protocol and RDF Query Language) (Prudhommeaux e Seaborne,
2008). Ambas possuem algumas semelhanas com a linguagem de consulta SQL (Structured
Query Language). SPARQL uma recomendao proposta pela W3C que se baseia no conceito dos padres de triplas do grafo RDF e sua semntica est centrada na correspondncia
nas triplas do grafo RDF (Sirin e Parsia, 2007). Contudo, h questes de compatibilidade
entre as consultas com SPARQL e bancos de dados OWL-DL. Por esse motivo, a SPARQLDL foi proposta com uma sintaxe abstrata especfica para ela, que define uma semntica
baseada no modelo terico da OWL-DL. Alm disso, um mapeamento realizado dessa sintaxe abstrata para a forma de grafo RDF (Sirin e Parsia, 2007) (Malik et al., 2010). O fato de
a ontologia criada ser na linguagem OWL e a prvia incluso dos pacotes do Pellet no mdulo justificam a utilizao da linguagem de consulta SPARQL-DL em um dos algoritmos
de busca do UDOnt-Q.
Jena: Framework ou API de desenvolvimento de aplicaes com Web Semntica, discutido
na subseo 5.2.2.
log4j: O log4j uma ferramenta que ajuda o programador no registro de informaes de
sada (logs) (Log4j, 2101). Desenvolvida pela Apache Software Foundation, o log4j um
pacote de classes em Java que, quando utilizado por um programa, permite que as sadas de
informaes sejam impressas tanto no console como em arquivos. O programador tem a
opo de escolher o nvel (level) de cada log (por exemplo: ALL, DEBUG, TRACE, INFO,
WARM, ERROR, OFF) a fim de rotular o tipo de mensagem de sada. No mdulo foram
utilizados os nveis DEBUG e ERROR durante os testes iniciais, para verificar valores de
parmetros e eventuais erros respectivamente. Posteriormente, os nveis ALL e OFF foram
utilizados durante os experimentos para ora registrar qualquer tipo sada (debug, error, etc.)
e ora no registrar as sadas respectivamente.
10
http://www.eclipse.org/
Por exemplo, o driver mysql-connector-java permite que aplicaes em Java acessem o banco de dados MySQL.
Ele est disponvel em http://www.mysql.com/products/connector/
11
46
5.2. METODOLOGIA E FERRAMENTAS

jUDDI: O jUDDI uma implementao em Java do UDDI12 , possui o seu cdigo aberto e
pode trabalhar com diversos tipos de banco de dados como, por exemplo o MySQL, Oracle,
DB2, entre outros, para armazenar informaes de Web Services.
Ganglia: O Ganglia um monitor de sistemas escalvel e distribudo (Massie et al., 2003),
que possui uma comunicao ponto-a-ponto entre os ns mestre e escravos e, por este motivo, ele utilizado em federaes de clusters (Estrella, 2010) (Matos, 2009). Assim, ele foi
utilizado neste trabalho para monitorar as mquinas dos provedores de servio. Os ns escravos monitoram os provedores de servios e coletam algumas informaes de desempenho
(CPU e Memria). Tais informaes so enviadas ao n mestre, que as disponibiliza em formato XML, em uma determinada porta previamente configurada. Logo, o mdulo abre uma
conexo TCP via socket e recupera essas informaes, que sero teis na escolha do melhor
provedor de servio, pois, no caso de dois servios com QoS semelhantes, o mdulo poder
optar por escolher o provedor que estiver menos sobrecarregado naquele determinado instante.
5.2.2.1 Jena
O framework Jena largamente utilizado para desenvolvimento de aplicaes com Web semntica em Java, provendo suporte para os padres RDF e RDFS, assim como para as linguagens OWL
e SPARQL (Martimiano, 2006). O Jena teve incio no laboratrio de pesquisa sobre Web Semntica da HP (Hewlett-Packard)13 , est escrito em Java e teve seu cdigo aberto comunidade open
source14 .
As recomendaes de Web semntica para RDF, RDFS e OWL tm como ncleo o grafo RDF
(Tripla: Sujeito, Predicado, Objeto). Da mesma forma, o Jena 15 igualmente centrado no grafo
RDF. O RDFS e o OWL so vistos como transformaes grafo a grafo, produzindo grafos de tripla
virtual (Carroll et al., 2004).
O Jena fornece uma API (Application Programming Interface) para criao e manipulao
desses grafos. Essa API possui classes de objetos para representar grafos, recursos, propriedades
e literais. As interfaces representando recursos, propriedades e literais so denominadas Resource,
Property e Literal, respectivamente. No Jena, um grafo chamado de modelo, e formado por um
conjunto de triplas (Statements), sendo representado pela interface Model.
A arquitetura do Jena, conforme mostrada na Figura 5.1, dividida em trs camadas (Carroll
et al., 2004):
12
O UDDI uma especificao elaborada pela OASIS (http://www.oasis-open.org)

http://www.hpl.hp.com/semweb/
14
http://www.openjena.org/
15
Referenciado internamente na HP como Jena2 (segunda verso do Jena).
13
47
Graph Layer - Camada baseada na sintaxe abstrata do RDF, fazendo uso de triplas como a
estrutura de dados universal (Triples as the Universal Data Structure). Esta camada simplifica a implementao:
- Do armazenamento de triplas, tanto em memria como em um armazenamento persistente16 .
- De vises como triplas em somente leitura (read-only) dos dados que no so triplas,
por exemplo, dados lidos a partir de uma hierarquia de um sistema de arquivos, ou de uma
pgina da Web.
- De triplas virtuais correspondentes aos resultados dos processos de inferncia sobre
algum outro conjunto de triplas como premissas.
Model Layer - Camada que mantm a Model API como a principal abstrao do grafo
RDF; essa API utilizada pelo programador da aplicao, fornecendo um conjunto mais
rico de mtodos para as operaes com os grafos (Model interface) e com os ns (Resource
interface). Alm disso, a API DAML forma uma API de Ontologia (Ontology API).
EnhGraph Layer - Camada que fornece um ponto de extenso para prover vises de grafos
e ns para criao de APIs. Permite mltiplas vises de grafos e ns que podem ser utilizados
simultaneamente.
Figura 5.1: Arquitetura do Jena (Carroll et al., 2004).

Para a manipulao de Web Semntica com ontologias, o Jena possui uma API denominada
Ontology API. Essa API inclui suporte para trabalhar com ontologias em linguagens como RDFS
16
O Jena oferece suporte aos SGBDs (Sistema Gerenciador de Base de Dados): MySql, Oracle e PostgreSQL.
48
5.3. COMPONENTES E ESTRUTURA
e OWL, sendo que cada linguagem tem um perfil (profile), o qual lista as construes permitidas e
as URIs das classes e propriedades. O perfil est vinculado a um modelo de ontologia, que uma
verso do modelo de classe do Jena estendido. O modelo geral permite acesso s declaraes nas
colees de dados do RDF. A interface OntModel estende esse modelo geral e adiciona suporte para
os tipos de objetos esperados em uma ontologia como, por exemplo, classes (em uma hierarquia
de classes), propriedades (em uma hierarquia de propriedades) e indivduos (instncias de uma ou
mais classes) (Carroll et al., 2004).
Portanto, o Jena permite aos desenvolvedores manipular e criar os dados semnticos programaticamente, baseados no grafo RDF e com extenso para a linguagem OWL-DL, a qual foi
utilizada no desenvolvimento da ontologia do UDOnt-Q. Essas caractersticas influenciaram na escolha por usar esse framework neste trabalho, na criao de algoritmos para realizar a manipulao
da ontologia criada no Protg. Duas verses foram utilizadas para a criao de dois algoritmos:
A verso 2.3, pois, disponibiliza a linguagem de consulta RDQL (RDF Data Query Language) criada para extrair informaes de grafos RDF. Essa consulta trata o grafo RDF como
dado, puramente, no fazendo distino entre triplas bsicas e inferidas (Seaborne, 2004a).
Dessa forma, a linguagem de consulta RDQL foi utilizada para a criao de um algoritmo
de busca do mdulo. Contudo, segundo o prprio Seaborne (2004), os novos programadores
devem utilizar a linguagem de consulta SPARQL por ser mais recente e sofisticada que a
RDQL (Seaborne, 2004b). Assim, a linguagem SPARQL-DL foi utilizada neste trabalho.
A verso 2.6.3 foi utilizada como padro no desenvolvimento do algoritmo de busca que
utiliza as classes disponveis na API do Jena. Mais detalhes sobre os algoritmos de busca
por Web Services com QoS so apresentados na prxima seo deste captulo.
5.3
Componentes e Estrutura
O Mdulo UDOnt-Q foi criado com o intuito de servir de base para os algoritmos de busca
e seleo semntica de Web Services com QoS. As informaes sobre os acordos entre clientes e
provedores, bem como a qualidade de servio e seus atributos esto em uma base de conhecimento
que est representada pela ontologia discutida anteriormente no Captulo 4.
Este mdulo foi projetado para ser reutilizvel e configurvel aceitando novos algoritmos (no
apenas semnticos) exigindo o mnimo de alteraes em cdigo-fonte. Ele foi desenvolvido com
a linguagem de programao Java para que possa ser portvel para diversas plataformas.
O UDOnt-Q est divido em componentes (pacotes - java packages), sendo que cada componente executa uma determinada funo dentro do mdulo e alguns pacotes possuem dependncias
entre si. Ao final do desenvolvimento de um componente, o mesmo foi submetido a testes unitrios
visando a minimizar a ocorrncia de erros. O mdulo composto por cinco componentes: Util,
Command Components (CC), UDDI Components (UC), Ontology Components (OC) e Common Information Shared (CIS).
5.3.1
49
Componente Util
O componente Util (Figura 5.2) composto por classes teis que so utilizadas por outras classes do mdulo para realizar tarefas teis e necessrias. Por exemplo, foram desenvolvidos
mecanismos de logs para registrar erros e informaes em arquivos no disco (para isso, este componente utilizou a ferramenta Log4J). Tambm foi criado outro mecanismo com a funo de registrar
resultados de desempenho em um banco de dados (mySQL).
Toda a parte de configurao do mdulo feita neste componente, por meio da Classe Config,
que herda o conceito de propriedades da classe java.util.Properties. Dessa forma, um arquivo de
configurao pode ser utilizado pelo mdulo para armazenar e recuperar informaes tais como:
endereo de conexo com o banco de dados, localizao do arquivo da ontologia, endereo, usurio
e senha para acesso no registro UDDI e qual algoritmo de busca o mdulo deve utilizar. Alm
disso, esto presentes diversos mtodos teis como, por exemplo, mtodos para o tratamento de
strings.
Util
Util
Config
db
UdontQDb
Constants
log
Util
UdontQLog
br.usp.udontq.util
Figura 5.2: Componente Util.
5.3.2
Componente Command Components (CC)
O componente Command Components (CC) (Figura 5.3) contm classes criadas para comandar, analisar e direcionar as requisies dos clientes, para que sejam atendidas por outras classes
de outros componentes do mdulo. As configuraes carregadas na inicializao do mdulo so
utilizadas pelas classes deste componente a fim de instncia os componentes e classes adequados.
Este componente possui um pacote (package) que constitui um sub-componente denominado
QoS Components (QC) (Figura 5.4). A funo do QoS Components auxiliar o Command
Components na anlise da qualidade dos servios dos provedores. Em caso de um empate en-
50

Command Components (CC)
Orchestrator
Factory
Orchestrator
OntOrchestrator
Analiser
AnaliserFactory
AnaliserResult
OntAnaliser
br.usp.udontq.cc
Figura 5.3: Componente Command Components (CC).

tre servios de mesma QoS, a implementao da classe abstrata QoSInformer ir decidir qual o
melhor servio baseado em informaes constantemente recolhidas dos provedores de servios por
um monitor. Neste projeto foi utilizado o monitor de sistemas Ganglia, portanto a classe concreta
QoSInformerGanglia foi implementada e utilizada. Porm, outras classes podem ser adicionadas
ao QC para utilizar outros monitores exigindo simples modificaes no cdigo-fonte.
QoS Components (QC)
QoSInformerFactory
QoSInformer
QoSInformerGanglia
QoSInformerGangliaResult
br.usp.udontq.qc
Figura 5.4: Sub-componente QoS Components (QC).

Para a escolha do melhor servio so consideradas informaes sobre a carga da CPU e a
utilizao de memria nos provedores de servios. O provedor escolhido ser aquele que, naquele
momento, encontra-se menos carregado, conforme a Equao (5.1):
P C = (100 P CP U IDLE) 3 + (100
M EN F REE 100
)2
M EN T OT AL
(5.1)
51
Onde:
PC o percentual de carga.
PCPUIDLE o percentual de CPU ociosa.
MENFREE a quantidade de memria RAM livre.
MENTOTAL a quantidade total de memria no provedor.
Dessa forma observa-se que, de acordo com a Equao 1, a porcentagem de CPU ocupada (100
- CPU Ociosa) tem peso 3 e a de memria ocupada (100 - regra de trs para obter a porcentagem
de memria livre) tem peso 2. O provedor que tiver o menor PC ser escolhido, em caso de um
novo empate o primeiro provedor da lista ser considerado.
5.3.3
Componente UDDI Components (UC)
O componente UDDI Components (UC) (Figura 5.5) rene as classes com a funo de prover
o acesso a informaes no registro UDDI. Tambm permite que novos Web Services e provedores
sejam cadastrados no registro.
A classe principal desenvolvida foi a UddiRequest. Ela recebe as requisies feitas ao registro
UDDI e por meio da classe abstrata UddiAbstration so instanciadas classes de manuteno do
registro UDDI de acordo com a sua implementao especificada no arquivo de configurao. Para
este projeto foi desenvolvida apenas a classe JuddiImpl que possui mtodos de interatividade com
a implementao do registro UDDI da Apache Software Foundation, denominado jUDDI (java
UDDI). Algumas classes do pacote jUDDI foram utilizadas para facilitar a interao com esse
registro. Outras classes para interagir com outras implementaes de outros registros UDDI podem
ser facilmente adicionadas a este sistema, exigindo-se o mnimo de alterao no cdigo-fonte.
5.3.4
Componente Ontology Components (OC)
O componente Ontology Components (OC) (Figura 5.6) contm as classes de algoritmos para
a busca semntica por Web Services com QoS. A busca pode ser executada por meio de trs algoritmos:
OntAlgorithmObject: Este algoritmo realiza a busca utilizando as classes fornecidas pelo
Jena. Ele cria instncias de objetos com as informaes da ontologia. Dessa forma, a
pesquisa feita por meio de interaes (loops) na lista de objetos at que se encontrem
os clientes, servios, provedores e QoS adequados. O algoritmo recebe dois parmetros de
entrada que so o endereo IP do cliente e o nome do Web Service que ele desejada. Com
52

UDDI Components (UC)
UddiRequest
UddiMaintance
UddiAbstraction
JuddiImpl
br.usp.udontq.cc
Figura 5.5: Componente UDDI Components (UC).

o endereo IP o algoritmo localiza os dados do cliente na ontologia e logo em seguinda indentifica tambm qual a sua classe (ClientGold, ClientSilver ou ClientBronze). De acordo
com a classe do cliente, o algoritmo seleciona apenas os servios com a QoS correspondente
e que tenham o mesmo nome que foi passado como parmetro de entrada. Dessa forma,
as respostas so inseridas em uma estrutura de dados (Web Service, Descrio do Provedor
Endereo IP do Provedor) que retornada ao mdulo.
OntAlgorithmRDQL: utiliza a linguagem de consulta RDQL para consultar informaes na
ontologia, opera com algumas semelhanas a uma consulta SQL (Structured Query Language). O funcionamento desse algoritmo semelhante ao do OntAlgorithmObject, porm
a busca feita por uma query que considera os parmetros de entrada como filtros na clusula
where.
OntAlgorithmSPARQL: este algoritmo faz uso do pacote que consulta o Pellet e que permite
a utilizao da linguagem de consulta SPARQL-DL para consultar informaes na ontologia. O funcionamento desse algoritmo semelhante ao do OntAlgorithmRDQL, porm h
diferenas nos recursos utilizados e na sintaxe da query de consulta.
importante enfatizar que o mdulo flexvel e permite a troca de um algoritmo por outro sem
a necessidade de alteraes no cdigo. Alm disso, novos algoritmos podem ser desenvolvidos e
facilmente adicionados ao pacote, pois, foram utilizados alguns padres de desenvolvimento e
primitivas da linguagem Java (instncia nica (singleton), fbricas, interfaces e classes abstratas)
durante a construo de todo o mdulo.
53
Ontology Components (OC)
OntMaintenance
OntService
OntProvider
OntAlgorithmObject
OntAlgorithm
OntAlgorithmRDQL
OntClient
OntQoS
OntAlgorithmSPARQL
OntResult
OntBulkServices
br.usp.udontq.oc
Figura 5.6: Componente Ontology Components (OC).
5.3.5
Componente Common Information Shared (CIS)
O componente Common Information Shared (CIS) (Figura 5.7) prov uma classe com mtodos para a manuteno das informaes na ontologia e, consequentemente, no registro UDDI. Por
exemplo, caso um provedor disponibilize um novo servio ele deve cadastr-lo na ontologia e tambm no registro UDDI. Por meio dos mtodos dessa classe possvel realizar as duas tarefas de
forma conjunta.
CommonInformationShared (CIS)
CommonInformationShared
br.usp.udontq.cis
Figura 5.7: Componente Common Information Shared (CIS).
5.3.6
Estrutura dos Componentes do UDOnt-Q
Os componentes do UDOnt-Q formam um conjunto de funcionalidades que precisam ser utilizados (importadas) por uma classe principal que seja executvel. Esse software executvel deve
estar disponvel para os clientes que buscam os Web Services com QoS. Das diversas possibilidades
54
de acesso que poderiam ser utilizadas pelos clientes para acessar o mdulo (Socket, RMI (Remote
Method Invocation), etc.), optou-se por transformar o mdulo em um Web Service para garantir a
interoperabilidade de acesso pelos mais diversos clientes.
O Web Service criado possui uma operao (mtodo) denominada GetWSDL na qual o cliente
passa como parmetro apenas o nome do servio que deseja. Contudo, esse mtodo foi sobrecarregado (overloading) para a incluso de um parmetro com o endereo de Internet (IP). No
primeiro mtodo no preciso passar o IP do cliente como parmetro, pois, esse endereo recuperado do contexto da mensagem de conexo HTTP. Porm, a sobrecarga do mtodo foi necessria
porque durante os testes realizados uma mquina cliente, por meio de threads, simula ser vrios
clientes que executam requisies concorrentes ao mdulo.
A Figura 5.8 exibe resumidamente a estrutura completa do mdulo como um Web Service sendo
consumido por um cliente, enquanto monitora diversos provedores (Nakamura et al., 2011a).
UDOnt-Q Module
Command
Components (CC)
1
Client
UDDI Components (UC)

6
Orchestrator
UddiRequest
7
Ontology Components (OC)

3
Analiser
OntMaintenance
Util
0a
4
4a
0b
4c
QoSInformer
Common Information Shared (CIS)
4b
4b
Ganglia
Provider 1
4b
Ganglia
0
Ganglia
Provider 2
Ganglia
Provider 3
.............
Provider N
4b
0
0
Figura 5.8: Estrutura resumida do Mdulo com os seus componentes (Nakamura et. al, 2011a).
A sequencia do funcionamento do UDOnt-Q tambm exibida na Figura 5.8. Tal funcionamento dado pelos seguintes passos (Nakamura et al., 2011a):
0. A princpio os provedores de servios devem implementar a classe do componente CIS
para que possam registrar os seus servios tanto no registro UDDI (0a), como na ontologia
(0b).
55
1. O mdulo fornecido como um Web Service que consumido pelo cliente que informa
o nome do servio desejado. Opcionalmente o endereo IP do cliente tambm poder ser
fornecido, caso contrrio o mesmo recuperado pelo contexto da mensagem de conexo
HTTP.
2. O componente CC encaminha a requisio para a anlise a fim de verificar qual componente de busca ser utilizado. Neste trabalho, o componente desenvolvido para realizar a
busca o OC, porm outros componentes podem ser desenvolvidos e acoplados facilmente
ao mdulo.
3. O componente OC recebe as informaes e instancia o algoritmo de busca (por exemplo:
OntAlgoritmObject ou OntAlgoritmSPARQL) que est indicado no arquivo de configurao
do mdulo. Dessa forma, baseando-se no acordo determina-se a QoS contratada pelo cliente
e tambm quais servios atendem aos requisitos dessa QoS. O resultado da busca um
conjunto de dados composto pelo: o nome do servio, o nome do provedor e o endereo do
provedor.
4. O CC recebe e analisa o resultado da busca feita pelo algoritmo. A anlise consiste em
verificar se h um ou mais servios que atendam requisio do cliente. Existindo apenas um, esse servio retornado classe Orchestrator e o sistema continuar o fluxo (item
5). Caso haja mais de um registro, o sistema pode seguir dois fluxos que dependem da
opo de monitoramento indicada no arquivo de configurao. Caso a opo esteja desativada (disabled), o primeiro resultado da lista ser retornado. Porm, caso a opo esteja
ativa (enabled) a lista de resultados encaminhada para o sub-componente QC. A classe
QoSInformer analisar os estados atuais dos provedores que estavam presentes na lista de
resultados (4a, 4b e 4c) e ir escolher aquele que estiver menos sobrecarregado.
5. A classe Orchestrator recebe o resultado, recupera o nome do servio e do provedor e
encaminha para o componente UC.
6. O componente UC procede com a pesquisa no registro UDDI, procurando a WSDL do
servio daquele determinado provedor.
7. A WSDL retornada ao componente CC que a repassa ao cliente.
8. O cliente recebe a WSDL do servio que possui a qualidade contratada e a partir dela
possvel determinar a localizao do servio e posteriormente utiliz-lo. A resposta Null
enviada ao cliente caso nenhum servio que atenda a sua necessidade seja encontrado.
Durante todo o fluxo da Figura 5.8, eventuais erros so registrados e informaes de desempenho so coletadas para que uma futura avaliao de desempenho seja conduzida.
56
5.4
Consideraes Finais
Neste captulo foi apresentado o desenvolvimento do mdulo UDOnt-Q. A metodologia e ferramentas utilizadas no processo de desenvolvimento do mdulo, juntamente com os componentes,
a estrutura e o funcionamento do mdulo, foram tpicos abordados neste capitulo que permitiram o seu melhor entendimento. Aps as correes de alguns erros encontrados durante a fase de
testes, o prottipo do mdulo ficou pronto para ser submetido a uma avaliao de desempenho. A
avaliao de desempenho do mdulo e de seus algoritmos discutida no prximo captulo.
C APTULO
6
Avaliao de Desempenho
6.1
Este captulo aborda a avaliao de desempenho do prottipo do UDOnt-Q. Essa avaliao

considera os algoritmos de busca OntAlgoritmObject e OntAlgoritmSPARQL durante os experimentos. O objetivo deste captulo analisar o comportamento do mdulo quando submetido a
diversas requisies concorrentes. Algumas variveis de respostas so analisadas, como por exemplo, o tempo para a localizao de servios e a vazo do mdulo, o tempo de resposta para o cliente
obter a descrio de interface do servio (WSDL) e a sobrecarga de processamento causada pela
utilizao do mdulo em algumas situaes.
6.2
Configurao do Ambiente de Testes
A configurao do ambiente de testes detalha os elementos de hardware e software utilizados

nos experimentos. Tais informaes so importantes porque facilitam a reproduo do ambiente
utilizado durante os testes. Alm disso, essas informaes visam a impedir comparaes incorretas, pois em alguns casos uma simples alterao pode fornecer resultados completamente diferentes. Nesse contexto, na Tabela 6.1 possvel visualizar a infraestrutura computacional utilizada
na avaliao de desempenho do prottipo do mdulo UDOnt-Q.
Complementando os elementos de hardware descritos na Tabela 6.1, a Tabela 6.2 lista os principais elementos de software utilizados no desenvolvimento e tambm na avaliao de desempenho
do mdulo.
57
58
6.2. CONFIGURAO DO AMBIENTE DE TESTES

Tabela 6.1: Elementos de Hardware
Componente
Provedores de
Servios
Quantidade
5
Clientes
UDOnt-Q
UDDI
Configurao
Intel QuadCore Q6000 (2.4GHz)
2GB de RAM
HD 120GB, 7200RPM
Intel QuadCore Q9400(2.66GHz)
4GB de RAM
HD 500GB, 7200RPM
Intel QuadCore Q9400(2.66GHz)
8GB de RAM
HD 320GB, 7200RPM
Descrio
Fornecer os
Web Services
Requisitar os Web
Services com QoS
Mdulo de busca
Registro de Informaes
Tabela 6.2: Elementos de Software

Elemento
Linux Ubuntu
Server
Apache Web
Server
Descrio
Sistema Operacional
Utilizao
Sistema Operacional
Servidor Web
da Apache
Apache Tomcat
Continer de
Servlets
Apache Axis2
Motor (engine) de
processamento SOAP
jUDDI
UDDI da OASIS
desenvolvido pela
(Apache em Java)
Mquina Virtual Java
Armazenamento e
disponibilizao da
ontologia via URL
Hospeda os servios
(Mdulo, jUDDI e)
Provedores
Troca de mensagens
entre clientes,
mdulo, UDDI
e provedores
Repositrio de
informaes de
Web Services
Todos componentes
Java Virtual
Machine (JVM)
MySQL Server
Pellet
Jena
Log4J
Sistema Gerenciador
de Bancos de
Dados (SGBD)
Mquina de inferncia
semntica
Framework que fornece
uma API para a manipulao de ontologias
Biblioteca desenvolvida pela Apache que
fornece uma API para
o registro de logs
Verso
Ubuntu 10.04
Kernel 2.6.32-26
2.2.14
6.0.26
1.4.1
0.9rc4
1.6.0_22
Gravao dos
resultados de
desempenho
Inferir informaes
nas ontologias
Executar buscas
semnticas
5.1.41-3
ubuntu12.8
Gravao de logs de
rastreamento (trace),
aviso (warnings)
e erros (errors)
no Mdulo
1.2.16
2.2.2
2.6.3
Alm dos elementos de software citados na Tabela 6.2, importante salientar que tambm
foram utilizados: o mdulo com os componentes desenvolvidos neste projeto, as aplicaes clientes
e uma aplicao para gerao de carga de trabalho nos provedores de servio. Essa ltima aplicao, denominada ProviderWorkLoad, foi criada com o intuito de gerar carga de trabalho do tipo
CAPTULO 6. AVALIAO DE DESEMPENHO
59
CPU-Bound, no permitindo que a CPU fique ociosa durante os experimentos. Ela composta
por operaes matemticas (exponenciais e divises) dentro de laos aninhados na ordem O(n4 ).
Essas operaes so executadas de tempos em tempos de forma aleatria, as variveis que representam as bases e os expoentes tambm so geradas aleatoriamente dentro de um limite. Dessa
forma, espera-se que a carga de trabalho dos provedores no seja a mesma, evitando que o mdulo
sempre escolha o mesmo provedor.
A Figura 6.1 resume a disposio dos softwares utilizados no ambiente de testes. A seta na
cor Preta representa a interao do cliente com o mdulo ao fazer a sua requisio. A seta na cor
Verde indica a consulta do mdulo a uma URL (ontologia) no servidor Web Apache. A gravao
de logs em disco feita com a utilizao do log4j. Para a gravao dos resultados de desempenho
foram desenvolvidas e executadas stored procedures, gravando assim os dados no banco de dados
MySql (seta Marrom).
Apache2
v
URL :Ontologia
DBLog (MySql)
FileLog (log4j)
Apache Tomcat
Axis2
jUDDI
UDOnt-Q Module
Cliente
Legenda:
Cliente UDOnt-Q
UDOnt-Q Apache2
UDOnt-Q Log
UDOnt-Q Ganglia
Provedor UDOnt-Q
UDOntQ jUDDI
Ganglia
Provedor 1
Ganglia
Provedor 2
Ganglia
Provedor 3
Ganglia
.............
Provedor N
Figura 6.1: Viso resumida dos elementos de software utilizados no ambiente de testes.
Quando a funcionalidade de monitoramento dos provedores est ativa e h mais de um servio
como resultado, o mdulo passa a considerar as informaes fornecidas pelo monitor Ganglia. A
interao do mdulo com o Ganglia est representada pelas setas na cor Amarela. Os provedores
podem atualizar a ontologia (e o registro UDDI) por meio de mtodos da classe do componente
CIS. As setas Vermelhas esboam esta interao. importante relembrar que o mdulo um
conjunto de componentes que tem um Web Service como interface de acesso e, por este motivo, o
mdulo precisa ser implantado (deploy) em um continer de Servlets (Apache Tomcat) onde poder
60
6.3. PLANEJAMENTO DE EXPERIMENTOS
ser acessado pelos clientes. O Axis2 exigido, pois este Web Service utiliza o protocolo SOAP
para a troca de informaes. Por fim, a seta na cor Azul representa a comunicao entre o mdulo
e o jUDDI na consulta de dados funcionais (WSDL). O jUDDI, o Axis2 e consequentemente o
mdulo so aplicaes que para seu funcionamento precisam estar inseridas em um servidor de
aplicaes que neste caso o Apache Tomcat.
6.3
Planejamento de Experimentos
Antes de iniciar o processo de avaliao de desempenho do mdulo foi realizado o planejamento de experimentos. O planejamento tem como objetivo obter o mximo de informaes com
um nmero mnimo de experimentos (Jain, 1991), constituindo uma etapa fundamental em que
preciso definir quais so as informaes e em que condies e quantidade elas devem ser coletadas
em um determinado experimento (Estrella, 2010).
O planejamento de experimentos pode facilitar o entendimento do comportamento de desempenho do mdulo em determinadas situaes. Durante o planejamento de experimentos buscam-se
identificar quais sero as variveis de respostas do sistema que devero ser analisadas; por exemplo, se o tempo de resposta importante ento ele deve ser considerado como uma varivel de
resposta e, portanto, deve ser coletado durante os experimentos.
Outro ponto que deve ser identificado o que ser avaliado, quais os fatores que influenciam
no desempenho do sistema e quais nveis desses fatores podem ser interessantes. Por exemplo, o
fator nmero de usurios de um sistema interessante e as diversas quantidades de usurios so
os nveis desse fator. Alm disso, pode haver fatores de menor influncia no sistema, chamados de
fatores secundrios. interessante tambm informar o nmero de vezes que os experimentos so
repetidos, ou seja, replicados, pois uma nica replicao pode estar sujeita a interferncias que
podem no ser comum no ambiente analisado (Jain, 1991).
Aps analisar a influncia de cada fator, tambm possvel verificar a interao entre eles. O
resultado dessas interaes interessante, pois algumas vezes um fator isolado no exerce uma
influncia significativa, porm quando combinado a outro resulta em uma interao onde a sua
influncia considervel no sistema avaliado.
Segundo Jain (1991), das diversas tcnicas existentes para realizar o planejamento de experimentos as mais utilizadas so: o planejamento simples, o planejamento fatorial completo e o
planejamento fatorial parcial. A tcnica adotada neste projeto foi o planejamento fatorial completo, que utiliza todas as combinaes possveis de todos os fatores e nveis escolhidos para a
avaliao. Essa tcnica mais trabalhosa que as demais, contudo, permite que os fatores sejam
avaliados, sendo assim possvel identificar as interaes e influncias entre eles (Jain, 1991).
Um fato importante ocorreu durante a execuo dos experimentos do mdulo UDOnt-Q. Notouse uma caracterstica interessante de comportamento do processo de classificao e realizao (inferncia) da ontologia por parte do reasoner Pellet. Quando foram adicionados mais indivduos
61
na ontologia, maiores foram os tempos de processamento para a classificao e realizao (inferncia). Esse aumento j era esperado, pois haveria mais informaes a serem analisadas, porm a
intensidade do aumento no parecia seguir um comportamento linear.
Sendo assim, decidiu-se avaliar tambm esse processo de classificao e realizao (inferncia)
da ontologia. Esse fato passou despercebido durante a fase de testes do mdulo devido ao pequeno
nmero de indivduos na ontologia utilizada para os testes unitrios. Esse problema foi detectado
quando se adotou o nmero de servios cadastrados como um fator para os experimentos. Alm
disso, estabeleceu-se a dvida se esse comportamento ocorria devido s caractersticas da ontologia criada. A fim de sanar essa dvida, foi escolhida uma ontologia clssica para analisar o seu
comportamento com vrios indivduos. A ontologia Pizza, comentada na seo 4.3, inspirou a criao da ontologia para o mdulo e foi escolhida para a comparao. Dessa forma, foram criados
trs Planejamentos de Experimentos (PE) para este trabalho:
Planejamento de Experimentos para a avaliao de desempenho do processo de classificao
e realizao (inferncia) da ontologia do mdulo utilizando o processo de inicializao do
mdulo com a configurao padro do reasoner Pellet (PE-Ontologia).
Planejamento de Experimentos para avaliao de desempenho do processo de classificao e
realizao (inferncia) da ontologia Pizza utilizando o processo de inicializao do mdulo
com a configurao padro do reasoner Pellet (PE-Pizza).
Planejamento de Experimentos para a avaliao de desempenho do mdulo UDOnt-Q no
processo de busca por Web Services com QoS (PE-Mdulo).
No PE-Ontologia a varivel de resposta analisada o tempo de resposta para que a ontologia
fique disponvel para utilizao. Essa varivel o tempo gasto para que o mdulo leia, classifique,
faa a inferncia e carregue na memria do servidor a ontologia processada. Os experimentos desta
avaliao foram replicados 10 vezes e o fator e os nveis considerados esto listados na Tabela 6.3.
Tabela 6.3: Fator e nveis relativos ao PE-Ontologia
Fator
Nmero de Servios
Nveis
300, 600, 900 e 1200
Descrio
Nmeros de Servios (indivduos) cadastrados na
ontologia so classificados em Gold,Silver e Bronze.
Eles esto divididos igualmente entre os cinco provedores tambm cadastrados na ontologia
O PE-Pizza semelhante ao PE-Ontologia, porm trata-se de outra ontologia com quantidades

de indivduos diferentes. Os experimentos dessa avaliao tambm foram replicados 10 vezes e o
fator e nveis considerados esto listados na Tabela 6.4.
No PE-Mdulo a varivel de resposta analisada o Tempo de Busca (TB) que considera o
tempo gasto pelo mdulo para encontrar o melhor servio por meio da busca semntica na ontologia e incluir tambm o tempo para a consulta no registro UDDI recuperando a WSDL. Ou seja,
62
6.3. PLANEJAMENTO DE EXPERIMENTOS

Tabela 6.4: Fator e nveis relativos ao PE-Pizza
Fator
Nmero de Pizzas
Nveis
200, 400, 600 e 800
Descrio
Nmeros de Pizzas (indivduos) cadastrados na
ontologia. Eles esto divididos igualmente entre
dois grupos, pizza com alta calorias (HighCaloriePizza) e pizzas com baixas (LowCaloriePizza).
o TB o tempo necessrio para o mdulo executar os passos do item 2 at o item 7 da Figura

5.8. Neste ponto, a ontologia j foi processada (classificada e inferida) e armazenada na memria
durante a inicializao do servidor.
No PE-Modulo, os experimentos desta avaliao foram replicados 30 vezes e os fatores e os
nveis considerados esto listados na Tabela 6.5.
Tabela 6.5: Fator e nveis relativos ao PE-Modulo
Fator
Nmero de Servios
(Fator A)
Nveis
300, 600 e 1200
Nmeros de Clientes
(Fator B)
Algoritmo de Busca
(Fator C)
15 e 30
OntAlgorithmObject e
OntAlgorithmSPARQL
Descrio
Nmeros de Servios (indivduos) cadastrados na
ontologia. Eles esto divididos igualmente
entre os cinco provedores cadastrados na ontologia e so classificados em Gold, Silver e Bronze.
Nmeros de Clientes cadastrados na ontologia.
Tambm so classificados em Gold, Silver e Bronze.
Apenas os dois principais algoritmos de busca
com semntica sero avaliados. O algoritmo
OntAlgorithmRDQL no foi utilizado devido o
mdulo utilizar a verso 2.6.3 do Jena, a qual
no possui suporte para a linguagem RDQL.
Alm dos principais fatores destacados na Tabela 6.5, outros fatores foram fixados (Fatores
Fixos) durante os experimentos do mdulo (PE-Modulo). Esses fatores fixos e seus possveis
nveis esto listados na Tabela 6.6.
Os fatores da Tabela 6.6 so denominados fixos, pois durante cada experimento utilizado
(fixado) apenas um nvel, no ocorrendo alterao de nveis no mesmo experimento. Dessa forma,
estes fatores no sero considerados nos clculos de influncia de fatores (Seo 6.4.1).
A escolha de todos os fatores e nveis deve ser feita antes da inicializao do mdulo, por meio
do seu arquivo de configurao. Alm disso, a configurao do ambiente pode sofrer algumas
alteraes de um experimento para outro, como por exemplo, a alterao do nmero de servios
cadastrados no registro UDDI (Fator A) e o nmero de threads que devem ser disparadas concorrentemente nas mquinas clientes (Fator B). Essa ltima configurao necessria, pois os
elementos de hardware disponveis, listados na Tabela 6.1, no so suficientes para representar 15
e 30 clientes. Por esse motivo, foi preciso criar threads nas mquinas clientes para que representassem o nmero proposto de requisies concorrentes nos experimentos (cinco ou dez threads por
cliente).
63
Tabela 6.6: Fatores Fixos e possveis nveis relativos ao PE-Modulo

Fator
Nmero de Atributos de QoS
(AQ)
Nveis
3e2
Gravao de Log
(GL)
Monitorao pelo Ganglia
(MG)
ON e OFF
Monitorao de Carga
(MC)
ON e OFF
ON e OFF
Descrio
Indica o nmero de atributos de QoS utilizados como
propriedades para a classificao no processo de equivalncia de classe durante a inferncia da ontologia. Os
atributos so Tempo de Resposta, Disponibilidade e Custo.
No caso de apenas 2 atributos, o atributo Custo no foi
considerado.
Indica se o mdulo gravar ou no arquivos de logs.
Indica se o mdulo dever ou no consultar
as informaes do Ganglia em caso da busca retornar
mais de um servio com a QoS adequada.
Indica se a monitorao da carga de trabalho (CPU)
da mquina na qual o mdulo executa estar ativa ou
no. Um script em Perl foi utilizado para armazenar
os valores de CPU a cada segundo. Para minimizar
a influncia da carga gerada por eventuais rotinas
do Sistema Operacional foram considerados apenas
os valores superiores a 1% de utilizao de CPU.
A Figura 6.2 exibe a disposio dos elementos de hardware utilizados nos experimentos. As
threads criadas consomem o servio do UDOnt-Q para descobrir qual Web Service atende a sua
exigncia de QoS. Nos experimentos realizados, sempre haver mais de um servio que atende a
essa exigncia na ontologia 17 e a opo de monitoramento poder ou no estar ativa. Caso esteja,
o mdulo ir sempre consultar os resultados dos servidores a cada requisio.
6.4
Avaliao de Desempenho dos Experimentos
A avaliao de desempenho dos planejamentos PE-Ontologia e PE-Pizza possuem apenas um

fator a ser considerado em cada um deles. O objetivo identificar qual o comportamento dos
tempos gastos para os processos de realizao (classificao e inferncia), conforme o nmero de
indivduos aumenta na ontologia. Portanto, cada nvel do fator corresponde a um experimento
isolado. Dessa forma, foram realizados quatro experimentos para o PE-Ontologia e o PE-Pizza.
Cada um foi repetido 10 (dez) vezes, obtendo-se um total de 40 (quarenta) testes para ambos. Os
resultados obtidos e a anlise do comportamento desses experimentos so apresentados na prxima
seo.
Por outro lado, a avaliao de desempenho do planejamento PE-Mdulo mais complexa que
as anteriores. Conforme mostra a Tabela 6.5, h trs fatores (A, B e C) que variam em dois e trs
nveis. Alm disso, h tambm quatro fatores que so fixos durante cada conjunto de experimento
(CJE) do PE-Modulo. Um conjunto de experimento consiste em realizar experimentos com todas
17
No Anexo 3 desta monografia possvel observar a composio e ordenao dos Web Services cadastrados na
ontologia do UDOnt-Q.
64
6.4. AVALIAO DE DESEMPENHO DOS EXPERIMENTOS
C1
Clientes
C2
Servidores
C3
S1
requisies
monitorao
...
Servidor
UDOnt-Q
S2
Sn
Figura 6.2: Viso resumida dos elementos de hardware utilizados.

as possibilidades dos fatores que variam, utilizando dois nveis para cada fator, e fixando uma
opo de cada fator fixo.
Dessa forma, o PE-Modulo composto por 8 conjuntos de experimentos (CJE), cada um deles
composto por trs fatores que variam em 2 (dois) nveis, e tambm por um conjunto especfico
de fatores (nveis) fixos. A escolha por dois nveis nos experimentos justificada pelo fato da
maioria dos fatores possurem apenas dois nveis (com exceo do fator A). Essa escolha tambm
visa possibilitar o clculo do fatorial completo 2k que limita que cada fator (k) tenha no mximo
dois nveis. O clculo e anlise da influncia dos fatores (subseo 6.4.1) tambm so facilitados
com o emprego do fatorial completo 2k . Cada variao de fator e nvel corresponde a um novo
experimento que deve ser analisado. Dessa forma, o projeto fatorial completo para cada conjunto
de experimentos do mdulo de 23 possveis combinaes.
Os oito conjuntos de experimentos (CJE) so baseados em dois projetos de fatorial completo
2 , denominados FC300-600 e FC300-1200 exibidos nas Tabelas 6.7 e 6.8 respectivamente. Os
conjuntos de experimentos mpares so baseados no FC300-600 e os pares no FC300-1200.
k
Esses dois projetos de fatorial completo (FC300-600 e FC300-1200) foram reproduzidos alterandose alguns fatores que permaneceram fixos durante os experimentos de cada conjunto. Foram utilizadas quatro combinaes de fatores fixos totalizando os oito conjuntos de experimentos descritos
na Tabela 6.9.
A varivel de resposta relativa carga de trabalho gerada pela utilizao do mdulo (consumo
de CPU) registrada apenas nos conjuntos de experimentos nos quais a monitorao de carga
65
Tabela 6.7: Projeto Fatorial Completo para Avaliao de Desempenho do Mdulo com 300 e 600
Servios
Experimento
1
2
3
4
5
6
7
8
A (N.Servios)
300
300
300
300
600
600
600
600
B (N. Clientes)
15
15
30
30
15
15
30
30
C (Algoritmo)
OntAlgorithmObject
OntAlgorithmSPARQL
OntAlgorithmObject
OntAlgorithmSPARQL
OntAlgorithmObject
OntAlgorithmSPARQL
OntAlgorithmObject
OntAlgorithmSPARQL
Tabela 6.8: Projeto Fatorial Completo para Avaliao de Desempenho do Mdulo com 300 e
1200 Servios
Experimento
1
2
3
4
5
6
7
8
A (N.Servios)
300
300
300
300
1200
1200
1200
1200
B (N. Clientes)
15
15
30
30
15
15
30
30
C (Algoritmo)
OntAlgorithmObject
OntAlgorithmSPARQL
OntAlgorithmObject
OntAlgorithmSPARQL
OntAlgorithmObject
OntAlgorithmSPARQL
OntAlgorithmObject
OntAlgorithmSPARQL
Tabela 6.9: Conjuntos de Experimentos do PE-Modulo

N. Exp
1
2
3
4
5
6
7
8
Conjunto de
Experimento
FC300-600
FC300-1200
FC300-600
FC300-1200
FC300-600
FC300-1200
FC300-600
FC300-1200
Fatores Fixos durante os Experimentos

Nmero de AtriGravao de
Monitorao
Monitorao
butos de QoS (AQ)
Log (GL)
pelo Ganglia (MG) de Carga (MC)
3
ON
OFF
OFF
3
ON
OFF
OFF
2
ON
OFF
OFF
2
ON
OFF
OFF
2
ON
ON
ON
2
ON
ON
ON
2
OFF
OFF
OFF
2
OFF
OFF
OFF
(MC) estiver ativa (ON). Quando a gravao de log (GL) estiver desativada (OFF) no possvel
registrar o tempo de busca (TB) do mdulo, pois no so salvos registros de desempenho. Contudo,
os clientes armazenam os tempos de respostas (RTC - Response Time in the Client) que podem ser
avaliados. importante recapitular que a ontologia sempre ter mais de um servio que atendem
s necessidades do cliente. Portanto, quando a monitorao pelo Ganglia (MG) estiver ativa (ON)
o mdulo dever verificar qual o provedor menos sobrecarregado naquele instante.
66
6.4.1
6.4. AVALIAO DE DESEMPENHO DOS EXPERIMENTOS
Clculo da Influncia dos Fatores
No caso da avaliao de desempenho do mdulo existem trs fatores (A, B e C). Para se obter a
influncia de cada um desses fatores nas condies especificadas preciso calcular a influncia dos
fatores no sistema avaliado. Para determinar a influncia de cada fator, possvel empregar-se um
modelo de regresso (Jain, 1991). O modelo para o projeto fatorial 23 empregado nos experimentos
deste trabalho, apresentado na Equao (6.1).
y = q0 + qA xA + qB xB + qC xC + qAB xAB + qBC xBC + qAC xAC + qABC xABC
(6.1)
O prximo passo substituir no modelo os valores (yi ) das variveis de resposta obtidos nos
experimentos. Dessa forma, obtm-se os valores de q0 , qA , qB , qC , qAB , qBC , qAC e qABC . A
Soma dos Quadrados Total (SST) desses valores (qi ) fornece a variao total das variveis de
resposta dos experimentos e, consequentemente, as variaes devidas influncia dos fatores e de
suas interaes. A equao da Soma dos Quadrados Total (SST) ou a Variao Total dada pela
Equao (6.2) (Jain, 1991):
2
SST =
2
X
(yi y)2
(6.2)
i=1
Na Equao (6.2), a varivel y a mdia dos valores das variveis de resposta obtidas em todas
as replicaes dos experimentos. Portanto, ao realizar a substituio de todos 23 experimentos
obtm-se a Equao (6.3):
2
2
2
2
y = 23 (qA2 + qB2 + qC2 + qAB
+ qAC
+ qBC
+ qABC
)
(6.3)
A ltima etapa determinar a influncia de um determinado fator, para isso preciso dividir
a soma dos quadrados do fator pela soma dos quadrados total (Jain, 1991). Por exemplo, no caso
do fator (A) o clculo seria SSA/SST. Portanto, no experimento utilizado, a frmula de SSA
apresentada na Equao (6.4):
SSA = 23 qA2
(6.4)
67
Os resultados obtidos na avaliao de desempenho e as influncias dos fatores so apresentados

na prxima seo.
6.5
Anlise dos Resultados
Os planejamentos de experimentos apresentados na seo 6.3 foram realizados de acordo com

a avaliao de desempenho da seo 6.4. Os resultados coletados durante os planejamentos das
ontologias (PE-Ontologia e PE-Pizza) foram analisados e o comportamento resultante desses
resultados discutido na subseo 6.5.1. Os resultados do planejamento de experimento do mdulo
(PE-Modulo), a anlise desses resultados e a influncia dos fatores so apresentados na subseo
6.5.2.
6.5.1
Anlise dos Resultados das Ontologias
Com relao anlise comportamental do processo de inferncia das ontologias, podem-se observar nas Figuras 6.3 e 6.4 que para ambas o tempo gasto com esse processo aumentou conforme
o nmero de indivduos (Servios ou Pizzas) cadastrados crescia. Para essa anlise, fixou-se o
nmero de clientes cadastrados na ontologia em 30.
Os resultados em grficos em linhas, conforme exibem as Figuras 6.5 e 6.6, permitem uma
viso mais clara da comparao dos resultados (Nakamura et al., 2011a).
Esses resultados mostram um avano progressivo no aumento do tempo de resposta (TR) do
mdulo durante o processo de inferncia utilizando-se trs atributos de QoS para a equivalncia de
classe. Embora as ontologias no possam ser comparadas, pois h diferentes nmeros de triplas
RDF, classes, indivduos, propriedades, etc., o comportamento para ambas no linear. A Figura
6.7 faz uma comparao entre o comportamento do processo de inferncia e de classificao da
ontologia Pizza com um comportamento linear hipottico e exibe um aumento considervel quando
a ontologia possui um maior nmero de indivduos (Nakamura et al., 2011b).
Esse comportamento pode ser justificado pelo fato do racionalizador Pellet ocupar apenas um
ncleo dos quatro disponveis na CPU durante esse processo. Alm disso, uma anlise superficial no cdigo fonte do racionalizador constatou a existncia de diversas chamadas de mtodos
recursivos que exigem processamento e memria. Dessa forma, alguns dos recursos disponveis
no so utilizados em sua totalidade com eficincia enquanto outros podem chegar ao mximo de
utilizao (Nakamura et al., 2011b).
6.5.2
Anlise dos Resultados do Mdulo UDOnt-Q
Apesar do tempo de resposta para o processo de inferncia ser longo, ele executado apenas
uma vez, durante a inicializao do mdulo. Os resultados posteriores so referentes ao tempo
68
6.5. ANLISE DOS RESULTADOS

TR Ontologia 30 Clientes & 300,600,900,1200 Servios
Mdia (seg)
Intervalo Confiana (seg)
1290,13
1300
1300
1268,38
1200
1200
1100
1100
1000
1000
900
900
800
800
729,32
719,24
700
700
600
600
500
500
400
400
320,39
314,89
300
300
200
100
200
84,12
81,36
82,74
317,64
724,28
1279,25
300 Servios
600 Servios
900 Services
1200 Servios
100
Figura 6.3: Comportamento do processamento de Inferncia da Ontologia com 30 Clientes e

300, 600, 900 e 1200 Servios (PE-Ontologia).
de busca (TB) do mdulo por servios com qualidade. Os resultados de cada conjunto de experimentos (Tabela 6.9) foram analisados e comparados. Devido grande quantidade de resultados,
percebeu-se a necessidade de omitir aqueles que so semelhantes de um experimento para outro
com o objetivo de apresentar somente os resultados mais interessantes nesta seo. Contudo, os
resultados podem ser encontrados na integra no Anexo 4 desta monografia. Portanto, essa medida evita a repetio de informaes que no revelam novidades, principalmente para aqueles
resultados que so estatisticamente iguais. Apenas alguns comentrios, informando essa igualdade
estatstica dos resultados, sero mencionados nos momentos adequados.
As prximas duas primeiras subsees (6.5.2.1 e 6.5.2.2) apresentam os resultados dos conjuntos de experimentos 1 e 2 respectivamente. Nestes dois conjuntos de experimentos foram mantidos
os mesmos nveis dos outros fatores com exceo dos nveis do fator Nmero de Servios. Como
eles so os primeiros conjuntos de experimentos apresentados nenhum resultado foi omitido e na
subseo 6.5.2.2 so feitas algumas comparaes entre eles.
Nas subsees 6.5.2.3 e 6.5.2.4 so discutidos os resultados dos conjuntos de experimentos 3 e
4 respectivamente. Esses experimentos so semelhantes aos experimentos 1 e 2 respectivamente.
69
TR Pizza Ontologia - 200,400,600,800 Individuals

Mdia (seg)
Intervalo de Confiana (seg)
400
375,47
365,49
350
300
400
350
300
250
250
228,46
222,58
200
200
150
150
116,58
112,10
100
50
100
41,44
40,08
40,76
114,34
225,52
370,48
200 Pizzas
400 Pizzas
600 Pizzas
800 Pizzas
50
Figura 6.4: Comportamento do processamento de Inferncia da Ontologia com 200,400, 600 e

800 Pizzas (PE-Pizza).
TR Ontologia 30 Clientes & 300,600,900,1200 Servios
Mdia (seg)
1400
1279,25
Y - Tempo em Segundos
1200
1000
800
724,28
600
400
317,64
200
82,74
0
300 Servios 600 Servios 900 Services 1200 Servios
Figura 6.5: Comportamento do processamento de Inferncia da Ontologia com 300, 600, 900 e
1200 Servios (PE-Ontologia) (Nakamura et al., 2011b).
As subsees 6.5.2.5 e 6.5.2.6 apresentam resultados com a funo de monitoramento por parte
do monitor Ganglia ativada. Nestes experimentos 5 e 6 so mantidos todos os fatores e nveis dos
experimentos 1 e 2, com a diferena de que nos experimentos 5 e 6 todos os fatores fixos esto
ativados (Gravao de Log, Monitorao de Carga e Monitorao de QoS pelo Ganglia).
70

Grfico em Linha
M dia (se g)
400,0000
06
370,48
350,0000
300,0000
250,0000
01
225,52
200,0000
150,0000
93
114,33
100,0000
50,0000
9
40,757
0,0000
200 Individuals
400 Individuals
600 Individuals
800 Individuals
X - Nmero de Individuals
Figura 6.6: Comportamento do processamento de Inferncia da Ontologia com 200, 400, 600 e
800 Pizzas (PE-Pizza) (Nakamura et al., 2011b).
Grfico em Linha
Mdia (seg)
Linear Hipottico(seg)
400
370,48
350
300
250
225,52
200
150
122,27
100
40,76
50
163,03
114,34
81,52
40,76
0
200 Individuals
400 Individuals
600 Individuals
800 Individuals
X - Nmero de Individuals
Figura 6.7: Grfico em Linha de comparao do Comportamento do processamento de

Inferncia com 200, 400, 600 e 800 Pizzas (PE-Pizza) com um Comportamento Linear Hipottico
(Nakamura et al., 2011b).
As subsees 6.5.2.7 e 6.5.2.8 contm resultados dos conjuntos de experimentos 7 e 8 que
mantm todos os fatores e nveis dos experimentos 5 e 6 respectivamente. Porm, os fatores fixos
foram desativados (Gravao de Log, Monitorao de Carga e Monitorao de QoS pelo Ganglia).
Dessa forma, possvel verificar e comparar alguns resultados entre os conjuntos de experimentos
71
com os recursos do mdulo ativados e desativados. Contudo, o fato da gravao do log estar
desativada permite apenas comparar os tempos de resposta do cliente, pois o mdulo deixa de
registrar qualquer informao de tempo ou desempenho no arquivo de log e na base de dados.
6.5.2.1 Conjunto de Experimentos 1
Neste conjunto de experimentos possvel analisar os resultados dos experimentos obtidos
com 300 e 600 servios (Fator A), 15 e 30 clientes (Fator B) e ambos os algoritmos (Fator C).
Ainda neste conjunto de experimentos so considerados os fatores fixos de acordo com a Tabela
6.9.
A Figura 6.8 exibe a variao no tempo de busca (TB) quando o nmero de servios duplicado, passando de 300 para 600 servios. Utilizando o algoritmo OntAlgorithmObject possvel
observar que um aumento de 100% no nmero de servios ocasiona em um aumento por volta de
50% no tempo de busca. Com o algoritmo OntAlgorithmSPARQL essa diferena muito maior.
Ainda na Figura 6.8 observa-se uma grande variao do tempo de busca (TB) quando o algoritmo
OntAlgorithmObject substitudo pelo algoritmo OntAlgorithmSPARQL.
TB 15 Clientes - 300x600 Servios - OntAlgorithmObject x OntAlgorithmSPARQL
M dia (seg)
Intervalo de
Confiana(seg)
1,4000
1,3827
1,4000
1,3000
1,3039
1,3000
1,2000
1,2000
1,1000
1,1000
1,0000
1,0000
0,9000
0,9000
0,8000
0,8000
0,7000
0,7000
0,6000
0,6000
0,5000
0,5000
0,4359
0,4000
0,4000
0,4107
0,3000
0,3000
0,2000
0,1000
0,0000
0,1134
0,1061
0,1097
300 Object
0,2000
0,1616
0,1510
0,1000
0,1563
0,4233
1,3433
600 Object
300 SPARQL
600 SPARQL
0,0000
Figura 6.8: Tempo de Busca (TB) utilizando os algoritmos com 15 clientes (CJE-1).
O algoritmo OntAlgorithmSPARQL leva um tempo muito maior que o algoritmo OntAlgorithmObject para encontrar o melhor servio para o cliente. Uma das razes para essa diferena de
desempenho que o OntAlgorithmObject teve seu desenvolvimento baseado especificamente para
a ontologia do UDOnt-Q, enquanto o OntAlgorithmSPARQL exige pacotes adicionais para o seu
funcionamento os quais permitem uma certa flexibilidade em alteraes na estrutura da ontologia
(uma alterao exige apenas a reformulao da query de consulta).
Uma variao um pouco maior no tempo de busca (TB) exibida na Figura 6.9, ainda utilizando
300 e 600 servios com ambos os algoritmos. Porm, para obter esses resultados foram feitas 30
72
requisies de clientes concorrentes. Observam-se que os tempos de busca com 30 clientes so

maiores do que com 15 clientes. Esse resultado j era esperado, pois quanto maior o nmero de
requisies de clientes maior a carga de trabalho imposta ao mdulo.
M dia (seg)
Intervalo de Confiana
(seg)
3,0000
2,831
3,000
2,720
2,0000
2,000
1,132
1,082
1,0000
0,0000
1,000
0,299
0,285
0,2921
0,372
0,348
0,3601
1,1070
2,7756
300 Object
600 Object
300 SPARQL
600 SPARQL
0,000
A Figura 6.10 exibe os tempos de resposta para os 15 clientes (RTC) obterem a resposta do
mdulo com 300 e 600 servios utilizando ambos os algoritmos.
RTC 15 Clientes - 300x600 Servios - OntAlgorithmObject x OntAlgorithmSPARQL
Mdia (seg)
2.00000
1.69680
1.60665
1.00000
1.01000
0.73371
0.67712
0.41119
0.36059
0.00000
0.46600
0.41474
0.38589
0.44037
0.70541
1.65172
300 Object
600 Object
300 SPARQL
600 SPARQL
0.01000
Figura 6.10: Tempo de Resposta para o Cliente (RTC) utilizando os algoritmos com 15 clientes
(CJE-1).
O RTC o tempo contabilizado desde o incio da requisio at a chegada da resposta no cliente
(desde a etapa 1 at a 8 da Figura 5.8). Portanto, esse tempo inclui o tempo de busca (TB) da Figura
73
6.8, o tempo de processamento para o empacotamento e desempacotamento da mensagem SOAP

alm do tempo gasto no trfego dos dados na rede. Observa-se que a diferena nos tempos de 300
e 600 servios minimizada devido incluso dos tempos citados anteriormente, mas o resultado
com 300 servios ainda estatisticamente menor do que o resultado com 600 servios.
A Figura 6.11 exibe os tempos de resposta para os 30 clientes (RTC) obterem uma resposta
do mdulo utilizando os algoritmos OntAlgorithmObject e OntAlgorithmSPARQL com 300 e 600
servios. Em concordncia aos resultados da Figura 6.9, o desempenho do OntAlgorithmObject
permaneceu melhor que o do OntAlgorithmSPARQL, mesmo envolvendo outros tempos (processamento SOAP e transmisso na rede) neste resultado.
Mdia (seg)
(seg)
4,0000
4.00000
3.16654
3,0000
3.04992
2,0000
3.00000
2.00000
1.45295
1.37757
1,0000
0,0000
1.00000
0.62319
0.57485
0,5990
0.72722
0.65395
0,6906
1,4153
3,1082
300 Object
600 Object
300 SPARQL
600 SPARQL
0.00000
(CJE-1).
As mdias dos tempos de resposta para os clientes (RTC) foram utilizadas para calcular a
vazo (Throughput) do mdulo. A Tabela 6.10 lista as possibilidades do fatorial completo 23 com
as mdias dos tempos de busca (TB) do mdulo, as mdias dos tempos de resposta para os clientes
(RTC) e a partir dessas mdias so calculadas as vazes. A Figura 6.12 exibe as porcentagens de
influncia de cada fator durante a execuo dos experimentos na busca por servios com qualidade.
Tabela 6.10: Fatorial completo 23 e Mdias do Tempo de Busca (TB) do CJE-1
Experimento
1
2
3
4
5
6
7
8
Fator A
(N. Servios)
300
300
300
300
600
600
600
600
Fator B
(N. Clientes)
15
15
30
30
15
15
30
30
Fator C
(Algoritmo)
Object
SPARQL
Object
SPARQL
Object
SPARQL
Object
SPARQL
TB Mdia
0,10972
0,42332
0,29207
1,10697
0,15632
1,34331
0,36009
2,77555
RTC Mdia
0,38589
0,70541
0,59902
1,41526
0,44037
1,65172
0,69058
3,10823
Throughput
2,59
1,42
1,67
0,71
2,27
0,61
1,45
0,32
74

BC
ABC
6,48% 1,14% A (N. Servios)
AC
13,25%
15,82%
AB
1,28%
B (N. Clientes)
13,55%
A (N. Servios)
B (N. Clientes)
C (Algoritmo)
AB
AC
BC
ABC
C (Algoritmo)
48,46%
Figura 6.12: Porcentagem de Influncia de cada fator no tempo de busca (TB) do mdulo
durante os experimentos (CJE-1).
Analisando os resultados da Tabela 6.10 e as porcentagens de influncia de cada fator na Figura
6.12 possvel notar que o fator C (Algoritmo) com 48,46% o que exerce maior influncia nos
experimentos. Esse resultado era previsto, pois grande a discrepncia dos tempos de resposta de
um algoritmo para outro. O segundo fator que mais influenciou foi o fator A (Nmero de Servios)
com 15,82%, seguido pelo fator B (Nmero de Clientes) com 13,55%. Esses dois ltimos fatores
exercem uma influncia considervel no sistema e podem aumentar conforme o nmero de servios
e clientes aumenta. No Conjunto de Experimentos 2, descrito na prxima seo, ser possvel
observar a influncia do fator A com um nmero maior de servios. Na quarta e quinta posies
ficaram as combinaes de fatores AC com 13,25% e BC com 6,48% respectivamente, observandose que as combinaes que envolveram o fator C apresentaram maior influncia, com exceo da
combinao dos fatores ABC com 1,14%. A combinao AB ficou com 1,28% de influncia nos
experimentos.
Neste conjunto de experimentos a Monitorao de Carga (MC) estava inativa (OFF) e por esse
motivo no h resultados sobre a carga de processamento do mdulo.
O segundo conjunto de experimentos semelhante ao primeiro, com a diferena de que o fator
A tem 300 e 1200 servios ao invs de 300 e 600 servios. Portanto, esse experimento utiliza o
fatorial completo da Tabela 6.8 e os mesmos fatores fixos do primeiro conjunto de experimentos
conforme descrito na Tabela 6.9.
Seguindo a mesma sequencia do primeiro conjunto de experimentos, a Figura 6.13 exibe a
variao no tempo de busca (TB) quando o nmero de servios quadruplicado, passando de
300 para 1200 servios. Utilizando o algoritmo OntAlgorithmObject possvel observar que um
75
aumento de 300 para 1200 servios ocasiona em um aumento de aproximadamente 150% no tempo
de busca. Nota-se que o algoritmo OntAlgorithmObject manteve seu desempenho muito melhor
que o algoritmo OntAlgorithmSPARQL. H uma grande diferena no intervalo de tempo entre
as busca feitas com os algoritmos, a justificativa a mesma dada no conjunto de experimentos
1 (CJE-1). Porm, o problema se agrava quando o nmero de servios maior, como o caso
dos resultados com 1200 servios. Para que a exibio do grfico no ficasse desproporcional,
utilizou-se a escala logartmica.
M dia (seg)
Intervalo de
Confiana(seg)
10,0000
6.12816
5.78996
1,0000
0,1000
10.00000
1.00000
0.11338
0.10607
0.25418
0.23714
0.43594
0.41070
5,9591
0.10000
0,2457
0,4233
0,1097
0,0100
0.01000
300 Object
1200 Object
300 SPARQL
1200 SPARQL
A Figura 6.14, tambm em escala logartmica, exibe um aumento no tempo de busca (TB)
quando o nmero de clientes concorrentes duplicado. Correspondente aos resultados da Figura
6.9, esse aumento devido ao enfileiramento das requisies, pois o mdulo atende uma requisio
por vez.
M dia (seg)
(seg)
12.90370
12.37230
10,0000
1.13225
1.08169
1,0000
0.29897
0.28516
0.47976
0.45354
1.00000
12,6380
1,1070
0,1000
0,2921
10.00000
0.10000
0,4667
0,0100
0.01000
300 Object
1200 Object
300 SPARQL
1200 SPARQL
76
Com relao ao tempo de resposta para o cliente (RTC), observa-se um comportamento similar
ao do conjunto de experimentos 1 (CJE-1). A Figura 6.15 mostra esse tempo com 300 e 1200
servios utilizando ambos os algoritmos para atender a 15 requisies de clientes correntes. Assim
como no conjunto de experimentos 1, a diferena do tempo de resposta para o cliente entre as
quantidades de servios minimizada pelo fato deste tempo considerar outros tempos como, por
exemplo, o tempo de processamento das mensagens SOAP.
Mdia (seg)
(seg)
10,0000
6.39163
6.04674
1,0000
0.41119
0.36059
0,1000
0,3859
0.60757
0.52852
10.00000
1.00000
0.73371
0.67712
6,2192
0,5680
0,7054
1200 Object
300 SPARQL
0.10000
0,0100
0.01000
300 Object
1200 SPARQL
(CJE-2).
Os resultados da Figura 6.16, apresentados com escala logartmica, exibem um aumento no
tempo de busca (TB) quando o nmero de requisies dos clientes dobrado, passando de 15
clientes para 30 clientes. Esses resultados eram esperados, pois o mesmo efeito aconteceu quando
o tempo de busca aumentou devido duplicao do nmero de requisies.
Mdia (seg)
(seg)
13.27549
12.72870
10,0000
1,0000
0,1000
0.62319
0.57485
0,5990
0.89704
0.81641
1.45295
1.37757
10.00000
1.00000
13,0021
0,8567
1,4153
0.10000
0,0100
0.01000
300 Object
1200 Object
300 SPARQL
1200 SPARQL
(CJE-2).
77
Reunindo alguns resultados do primeiro conjunto de experimentos com os resultados deste

segundo possvel realizar uma comparao entre os tempos de busca com os trs nveis do Fator
A (Nmero de Servios: 300, 600 e 1200). Essa unio est ilustrada na Figura 6.17 que exibe os
resultados dos tempos de busca (TB) para 30 clientes concorrentes.
TB 30 Clientes - 300x600x1200 Servios - OntAlgorithmObject x OntAlgorithmSPARQL
Mdia (seg)
(seg)
100,0000
100,0000
12,9037
12,3723
10,0000
1,0000
0,2990
0,2852
0,3718
0,3484
0,4798
0,4535
1,1323
1,0817
10,0000
2,8309
2,7202
1,0000
12,6380
2,7756
0,1000
0,2921
0,3601
0,4667
300 Object
600 Object
1200 Object
1,1070
0,1000
0,0100
0,0100
300 SPARQL
600 SPARQL
1200 SPARQL
Figura 6.17: Tempo de Busca (TB) utilizando os algoritmos com 30 clientes e todos os servios
(CJE-1 e 2).
Analisando os resultados da Figura 6.17 fica clara a vantagem do algoritmo OntAlgorithmObject sobre o algoritmo OntAlgorithmSPARQL. Os resultados mostram que o primeiro leva menos
tempo para localizar/selecionar os servios desejados, mesmo precisando procurar em um nmero
maior de servios cadastrados. Ou seja, o algoritmo OntAlgorithmObject mais rpido buscando
em 1200 servios do que o algoritmo OntAlgorithmSPARQL buscando em apenas 300 servios.
A Tabela 6.11 exibe as possibilidades do fatorial completo 23 com as mdias dos tempos de
busca (TB) do mdulo, as mdias dos tempos de resposta para os clientes (RTC) e a partir dessas
mdias so calculadas as vazes (Throughput). Na Figura 6.18 so exibidas as porcentagens de
influncia de cada fator durante a execuo dos experimentos na busca por servios com qualidade.
Os resultados da Tabela 6.11 em conjunto com as porcentagens de influncia de cada fator na
Figura 6.18 exibem o fator C (Algoritmo), que com 32,14% de influncia, o fator que exerce
maior influncia nos experimentos. Esse resultado era esperado, pois da mesma forma que ocorreu
no CJE-1 foi grande a discrepncia dos tempos de resposta entre um algoritmo e outro. O segundo
fator que mais influenciou foi o fator A (Nmero de Servios) com 26,84% ficando a frente da
combinao dos fatores AC com quase 24,96%. Esses resultados indicam que, nos nveis e fatores
escolhidos para a anlise, os fatores C e A so os que exercem influncia considervel no sistema.
O Fator B (Nmero de Clientes) ficou com apenas 5,36% de influncia, embora essa influncia no
seja to representativa quando comparada aos outros fatores (C e A). O fator B com nveis maiores,
como por exemplo, 15 e 150 clientes (10 vezes mais) provavelmente ter uma influncia maior no
78

Experimento
1
2
3
4
5
6
7
8
Fator A
(N. Servios)
300
300
300
300
1200
1200
1200
1200
AC 24,96%
Fator B
(N. Clientes)
15
15
30
30
15
15
30
30
Fator C
(Algoritmo)
Object
SPARQL
Object
SPARQL
Object
SPARQL
Object
SPARQL
TB Mdia
0,10972
0,42332
0,29207
1,10697
0,24566
5,95906
0,46665
12,638
RTC Mdia
0,38589
0,70541
0,59902
1,41526
0,568
6,2192
0,8567
13,0021
Throughput
2,59
1,42
1,67
0,71
1,76
0,16
1,17
0,08
BC 4,31% ABC 3,15%

A (N. Servios) 26,84%
B (N. Clientes) 5,36%

AB 3,24%
A (N. Servios)
B (N. Clientes)
C (Algoritmo)
AB
AC
BC
ABC
C (Algoritmo) 32,14%
sistema. As outra combinaes BC (4,31%), AB (3,24%) e ABC (3,15%) compe a porcentagem
restante da influncia do conjunto de experimento 2.
Da mesma forma que o conjunto de experimento 1 (CJE-1), a Monitorao de Carga (MC)
estava inativa (OFF), portanto no h resultados sobre a carga de processamento no mdulo.
O conjunto de experimentos 3 (CJE-3) similar ao primeiro conjunto de experimentos (CJE-1)
e apenas se diferenciam quanto ao fator fixo: Nmero de Atributos de QoS (AQ). No CJE-1 foram
utilizados 3 (trs) atributos de QoS para classificar os servios como Gold, Silver e Bronze. Por
outro lado, no CJE-3 foram utilizados apenas 2 (dois) atributos conforme exibe a Tabela 6.9.
Os resultados desse terceiro conjunto de experimento (CJE-3) so estatisticamente iguais aos
resultados dos primeiro conjunto de experimento (CJE-1). Portanto, seria repetitiva a exibio de
grficos e resultados deste experimento. Devido a essa igualdade estatstica pode-se afirmar que a
79
adio (ou a remoo) de apenas um atributo de QoS no exerce influncia significativa nos experimentos efetuados. Contudo, a possvel adio de vrios atributos poder exercer mais influncia,
principalmente no processo de inferncia por parte do reasoner. No entanto, a realizao de novos
experimentos para averiguar essa suposio proposta para trabalhos futuros.
Para exemplificar a igualdade estatstica, a Figura 6.19 exibe uma comparao entre alguns
resultados dos CJE-1 e CJE-3. Analisando os grficos dessa Figura 6.19 possvel notar que para
qualquer que seja o algoritmo utilizado com 30 clientes e 600 servios (nmero mximo de clientes
e servios) as mdias obtidas em cada conjunto de experimentos esto sobrepostas aos intervalos
de confiana.
TB 30 Clientes - 600 Servios - Todos Algoritmos - CJE-1 x CJE3
Mdia (seg)
3,0000
(seg)
2,8309
2,8606
2,7202
2,7453
3,0000
2,0000
2,0000
1,0000
1,0000
0,0000
0,3718
0,3484
0,3601
0,3717
0,3356
0,3537
2,7756
2,8030
600 Object CJE-1
600 Object CJE-3
600 SPARQL - CJE-1
600 SPARQL CJE-3
0,0000
Figura 6.19: Comparao no Tempo de Busca (TB) dos CJE-1 e CJE-3 utilizando os algoritmos
com 30 clientes e 600 servios.
A Figura 6.20 apresenta os resultados do clculo da influncia da varivel de resposta Tempo
de Busca (TB) desse terceiro conjunto de experimento. Os resultados da influncia dos fatores
neste CJE-3 so muito prximos aos resultados do CJE-1 devido igualdade estatstica. Alm
disso, uma tabela com a completude dos resultados obtidos no CJE-3 encontra-se no Anexo 4
desta monografia.
80
BC 6,64% ABC 1,39%

AC 13,41%
AB 1,42%
A (N. Servios)
B (N. Clientes)
C (Algoritmo)
AB
AC
BC
ABC
A Monitorao de Carga (MC) estava inativa (OFF) neste conjunto de experimento. Portanto,
no h resultados sobre a carga de processamento imposta pelo mdulo para serem analisados.
O mesmo comportamento que ocorreu com o conjunto de experimentos 3 (CJE-3) em relao
ao CJE-1 se repetiu para o conjunto de experimento 4 (CJE-4) em relao ao CJE-2. Os resultados
obtidos foram estatisticamente iguais utilizando-se 3 (trs) ou 2 (dois) atributos de QoS no fator
fixo: Nmero de Atributos de QoS (AQ).
Novamente para exemplificar, os resultados obtidos com os dois algoritmos utilizando-se os
maiores nveis dos fatores (30 clientes e 1200 servios) foram comparados. Esses resultados, em
escala logartmica, esto ilustrados no grfico da Figura 6.21. Anlogo aos resultados da Figura
6.19, os resultados nessa Figura 6.21 demostram que as mdias obtidas para os experimentos de
mesmo algoritmo esto muito prximas e sobrepostas aos intervalos de confiana, mesmo em
conjunto de experimentos diferentes.
81
TB 30 Clientes - 1200 Servios - Todos Algoritmos - CJE-2 x CJE4

Mdia (seg)
(seg)
12,9037
12,3723
10,0000
12,7083
12,1803
1,0000
10,0000
1,0000
0,4798
0,4535
0,4725
0,4552
0,4667
0,4638
1200 Object CJE-2
1200 Object CJE-4
12,6380
12,4443
0,1000
0,1000
0,0100
0,0100
1200 SPARQL CJE-2
1200 SPARQL CJE-4
Figura 6.21: Comparao no Tempo de Busca (TB) dos CJE-2 e CJE-4 utilizando os algoritmos
com 30 clientes e 1200 servios.
A Figura 6.22 exibe os resultados dos clculos da influncia da varivel de resposta Tempo de
Busca (TB) desse quarto conjunto de experimentos. A influncia dos fatores neste CJE-4 quase
a mesma do CJE-2 por causa da igualdade estatstica entre eles. No Anexo 4 desta monografia h
uma tabela com a completude dos resultados obtidos no CJE-4.
AC 25,26%
BC 4,06% ABC 2,98%

AB 3,04%
A (N. Servios)
B (N. Clientes)
C (Algoritmo)
AB
AC
BC
ABC
O fator fixo Monitorao de Carga (MC) continuou inativo (OFF) neste conjunto de experimento. Dessa forma, no foi possvel coletar dados sobre a carga de processamento imposta pelo
mdulo.
82

O quinto conjunto de experimentos (CJE-5) manteve os mesmos fatores e nveis do CJE-3 . O
que diferencia o CJE-3 do CJE-5 que neste ltimo a opo de monitoramento dos provedores estava ativada. Alm disso, um script em perl permaneceu em execuo no servidor do mdulo neste
quinto conjunto de experimentos com o objetivo de monitorar o consumo mdio de processamento
durante a descoberta e a seleo de servios com qualidade.
Dessa forma, todos os fatores fixos neste conjunto de experimentos estavam ativos em concordncia com a Tabela 6.9. Devido a ativao desses fatores os resultados obtidos no foram
estatisticamente iguais aos resultados dos conjuntos de experimentos 1 e 3. O monitoramento de
carga pelo script escrito em perl no acrescenta uma grande sobrecarga ao sistema, porm mantm
o processador sempre ativo. Por outro lado, o monitoramento dos provedores exige um processamento extra para o mdulo. O sistema deve consultar periodicamente o estado dos provedores
utilizando o Ganglia. Alm disso, o mdulo deve consultar tais informaes com o objetivo de
selecionar o melhor provedor naquele determinado momento. Essa seleo feita em todas as requisies dos clientes, pois sempre haver mais de um servio compatvel com a qualidade exigida
pelo cliente.
importante relembrar que os fatores que variam neste CJE-5 so os mesmos dos CJE-1, ou
seja, foram utilizados 300 e 600 servios (Fator A), 15 e 30 clientes (Fator B) e os dois algoritmos
(Fator C).
A Figura 6.23 exibe a variao no tempo de busca (TB) quando o nmero de servios alterado de 300 para 600 servios com 15 requisies simultneas. Os resultados indicam que o
comportamento foi o mesmo do CJE-1 com a diferena das mdias dos tempos de buscas serem
um pouco maiores. Esse resultado era esperado, pois no CJE-5 h uma sobrecarga extra em razo
da monitorao e seleo dos provedores a cada requisio.
Mdia (seg)
1,6000
1,5222
1,5000
1,4441
1,4000
1,6000
1,5000
1,4000
1,3000
1,3000
1,2000
1,2000
1,1000
1,1000
1,0000
1,0000
0,9000
0,9000
0,8000
0,8000
0,7000
0,7000
0,6000
0,6000
0,5000
0,5000
0,4020
0,3788
0,4000
0,3000
0,2000
0,1000
0,0000
0,1526
0,1450
0,1488
300 Object
0,4000
0,3000
0,1978
0,1847
0,2000
0,1912
0,3904
1,4831
600 Object
300 SPARQL
600 SPARQL
0,1000
0,0000
83
Entretanto, o resultado do tempo mdio de busca com 15 clientes, 300 servios e algoritmo
OntAlgorithmSPARQL, em especfico, apresentou um tempo de busca menor em comparao ao
seu correspondente no CJE-1 (Figura 6.24).
TB - 15 Clientes - 300 Servios - OntAlgorithmSPARQL - CJE-1 x CJE-5
Mdia (seg)
(seg)
0,5000
0,5000
0,4359
0,4000
0,4107
0,4020
0,3000
0,2000
0,4000
0,3788
0,3000
0,4233
0,3904
0,1000
0,2000
0,1000
0,0000
0,0000
300 SPARQL Exp1
300 SPARQL Exp5
Figura 6.24: Comparao do Tempo de Busca (TB) entre o CJE-1 x CJE-5 utilizando 15 clientes,
300 servios e o algoritmo OntAlgorithmSPARQL.
Uma explicao plausvel para esse fato devida configurao de economia de energia adotada. A verso do sistema operacional utilizada nos experimentos permite que um gerenciador
regule as frequncias disponveis do processador de acordo com polticas de energia/desempenho
pr-definidas. Por exemplo, o regulador powersave configura estatisticamente o processador para
trabalhar na menor frequncia disponvel. Por outro lado, o regulador performance faz o contrrio
e configura o processador na maior frequncia disponvel. A partir do kernel 2.6.10, o regulador
padro o ondemand, que foi adicionado com a capacidade de alterar a frequncia do processador
dinamicamente de acordo com a sua utilizao (Hopper, 2009). H outros reguladores (politicas)
de gerenciamento de energia disponveis (Hopper, 2009). Porm o regulador ondemand o foco
de interesse para justificar o resultado obtido.
O regulador ondemand configura em princpio a menor frequncia disponvel e permanece
monitorando a utilizao do processador. Caso a utilizao ultrapasse o limite, o regulador deve
selecionar a frequncia mais elevada disponvel. Caso a monitorao indique que a utilizao est
abaixo do limite, ento o regulador ir diminuir a frequncia para a prxima disponvel. Se o
processador ainda continuar sendo subutilizado, novamente o regulador diminuir a frequncia at
que se atinja a menor frequncia disponvel (Hopper, 2009).
A mquina que hospeda o mdulo UDOnt-Q dispe de um processador (Intel QuadCore Q9400)
cuja arquitetura permite a utilizao de duas frequncias (2.00GHz e 2.66GHz). Na configurao
de gerenciamento de energia padro, ou seja, empregando o regulador ondemand, os experimentos
que exigiam menor processamento (experimentos com 300 e 600 servios e utilizando o algoritmo
OntAlgorithmObject) conseguiram ser atendidos rapidamente sem atingir o limite de processamento (2.00GHz) imposto para a troca de frequncia. Contudo, a partir da utilizao do algoritmo
OntAlgoritmoSPARQL, agregando a monitorao e seleo dos provedores, o limite foi ultrapassado em algum momento e a frequncia do processador foi alterada pelo regulador para a maior
84
(2.66GHz). Devido a esse aumento de frequncia o tempo de busca, em mdia, foi menor do que
o mesmo tempo correspondente no conjunto de experimento 1 (CJE-1).
Para os demais resultados que utilizam o algoritmo OntAlgoritmoSPARQL o tempo de busca
mdio no CJE-5 foi maior pois mesmo que tenha ocorrido um aumento na frequncia do processador, esse aumento no foi suficiente para compensar a carga de imposta (600 ou 1200 servios
e/ou 30 clientes) ao ponto de diminuir ou igualar o tempo de busca.
As afirmaes do pargrafo anterior so as possveis causas que justificam o resultado para um
tempo de busca menor. Essa perturbao no ambiente de testes no estava prevista e, portanto
a frequncia do processador durante os experimentos no foi registrada. Contudo, as taxas de
utilizao dos processadores foram coletadas e o comportamento dos resultados na Figura 6.29
refora a hiptese defendida para tal resultado. O comportamento e os resultados da Figura 6.29
sero explicados mais adiante nesta subseo.
Nos resultados apresentados na Figura 6.25 foram utilizados 30 clientes simultneos ao invs
de apenas 15. Entretanto, no houve problemas com o experimento com a configurao de 30
clientes, 300 servios e o algoritmo OntAlgorithmSPARQL. Provavelmente a troca de frequncia
favoreceu no tempo mdio de busca, mas neste caso no foi suficiente para obter um tempo menor
ou igual ao seu correspondente no CJE-1.
Mdia (seg)
(seg)
4,0000
4.00000
3,5000
3.23786
3.10524
3,0000
3.50000
3.00000
2,5000
2.50000
2,0000
2.00000
1,5000
1,0000
0,5000
0,0000
1.50000
1.34368
1.27707
1.00000
0.39409
0.37456
0,3843
0.47235
0.44863
0,4605
1,3104
3,1715
300 Object
600 Object
300 SPARQL
600 SPARQL
0.50000
0.00000
Novamente, o comportamento com 30 clientes foi anlogo ao comportamento do CJE-1, porm
os tempos mdios aumentaram devido mesma sobrecarga extra que foi discutida anteriormente.
As anlises de desempenho desse quinto conjunto de experimentos (CJE-5) refletem quelas feitas
no primeiro (CJE-1). Por exemplo, nota-se que o algoritmo OntAlgorithmObject mais eficiente
que o OntAlgorithSPARQL. Alm disso, o fato de dobrar o nmero de clientes manteve um aumento acima de 100% nos tempos de buscas obtidos.
85
Os resultados dos tempos de resposta nos clientes (RTC) seguiram o mesmo padro do tempo
de busca (TB). Relembrando que o RTC envolve a soma do tempo de busca, o tempo de transferncia de dados pela rede e o tempo de processamento para empacotamento (parser) e desempacotamento da mensagem SOAP.
A Figura 6.26 exibe as mdias dos tempos de respostas obtidos nas repeties do experimento
utilizando 15 clientes, 300 servios, 600 servios e ambos os algoritmos.
Mdia (seg)
(seg)
2,0000
2,0000
1,7996
1,7131
1,0000
1,0000
0,6847
0,4375
0,4006
0,0000
0,5240
0,6313
0,4615
0,4191
0,4928
0,6580
1,7564
300 Object
600 Object
300 SPARQL
600 SPARQL
0,0000
(CJE-5).
A Figura 6.27 complementa os resultados anteriores e exibe os tempos de resposta nos clientes
(RTC) sendo considerados 30 clientes concorrentes
Mdia (seg)
(seg)
4,0000
4.00000
3.57764
3.43336
3,0000
3.00000
2,0000
1,0000
0,0000
2.00000
1.69874
1.61828
0.80634
0.72750
1.00000
0.84474
0.77726
0,7669
0,8110
1,6585
3,5055
300 Object
600 Object
300 SPARQL
600 SPARQL
0.00000
(CJE-5).
86
Analisando e comparando os resultados das Figuras 6.26 e 6.27, nota-se um aumento no tempo
mdio de resposta quando se adotou 30 clientes. Essa conduta semelhante ao que ocorreu no
conjunto de experimentos 1 (CJE-1).
A Tabela 6.12 lista as possibilidades do fatorial completo 23 das mdias dos tempos de busca
(TB), as mdias dos tempos de resposta para os clientes (RTC). A partir dessas mdias so calculadas as vazes (Throughput). Na Figura 6.28 possvel observar o resultado do clculo da
influncia dos fatores para a varivel de resposta Tempo de Busca (TB) do CJE-5.
Experimento
1
2
3
4
5
6
7
8
Fator A
(N. Servios)
300
300
300
300
600
600
600
600
Fator B
(N. Clientes)
15
15
30
30
15
15
30
30
Fator C
(Algoritmo)
Object
SPARQL
Object
SPARQL
Object
SPARQL
Object
SPARQL
TB Mdia
0,14883
0,39042
0,38433
1,31037
0,19123
1,48313
0,46049
3,17155
RTC Mdia
0,41908
0,65803
0,76692
1,65851
0,49277
1,75636
0,811
3,5055
Throughput
2,39
1,52
1,3
0,6
2,03
0,57
1,23
0,29
BC
ABC
7,44%
0,91% A (N. Servios)
AC
13,51%
15,86%
AB
1,08%
B (N. Clientes)
16,28%
A (N. Servios)
B (N. Clientes)
C (Algoritmo)
AB
AC
BC
ABC
C (Algoritmo)
44,92%
Analisando-se as porcentagens de influncia de cada fator da Figura 6.28, observa-se que o
fator C (Algoritmo), com 44,92% de influncia, o que est com a maior porcentagem nos experimentos. Durante todos os conjuntos de experimentos, o fator C (Algoritmo) tem apresentado a
maior influncia nos clculos. A variao no tempo de busca quando os algoritmos so trocados
maior que qualquer variao dos outros fatores. No CJE-1 o fator A obteve uma influncia um
pouco maior com 48,46%.
87
O segundo fator em ordem de influncia neste CJE-5, com 16,28%, foi o fator B (Nmero
de Clientes), seguido pelo fator A (Nmero de Servios) com 15,86% de influncia. possvel
observar que houve uma inverso da posio entre esses fatores em comparao com o CJE-1. No
CJE-5 o fator B ficou a frente do fator A por causa da Monitorao pelo Ganglia (MG) que estava
ativa. Devido a essa monitorao, cada requisio do cliente exigia um tempo e processamento
extra para monitorar e selecionar os provedores adequados naquele instante. Esse fato aumentou a
influncia do fator B (Nmero de clientes/Nmero de requisies) no sistema.
As interaes entre fatores complementam o restante da porcentagem da influncia, a interao
AC ficou com 13,51%, BC com 7,44%, AB com 1,08% e ABC com 0,91%.
Neste quinto conjunto de experimento (CJE-5), o fator fixo Monitorao de Carga (MC) estava
ativo (ON). Neste caso, foi possvel coletar dados sobre a carga de processamento imposta pelo
mdulo. Esses dados foram analisados gerando os resultados da Figura 6.29.
A anlise dos resultados da carga de processamento indica que preciso uma maior taxa de
processamento para o algoritmo OntAlgorithmSPARQL. Enquanto o consumo dos processadores
com o algoritmo OntAlgorithmObject no ultrapassa a taxa de 20%, com o algoritmo OntAlgorithmSPARQL essa taxa inicia em quase 30% e chega prximo dos 70%. O OntAlgorithmObject
mais eficiente para as cargas impostas e os resultados de vazo apresentados na Tabela 6.12
endossam essa afirmao.
Mdia (%)
Intervalo de Confiana (%)
80,00
71,65
70,00
60,00
63,36
57,36
50,00
47,07
47,28
40,00
37,85
32,38
30,00
25,82
21,87
20,00
18,08
17,35
13,37
10,00
0,00
9,19
7,74
8,46
15x300
Object
13,77
10,65
12,01
29,10
52,32
15,92
19,61
42,46
67,51
15x600
Object
15x300
Sparql
15x600
Sparql
30x300
Object
30x600
Object
30x300
Sparql
30x600
Sparql
Figura 6.29: Porcentagem da carga de processamento (CPU-Load) do mdulo durante os

experimentos (CJE-5).
88

No sexto conjunto de experimentos comparado com o CJE-5 h a diferena que o fator A possui
300 e 1200 servios ao invs de 300 e 600 servios. Os fatores fixos, Gravao de Log (GL),
Monitorao pelo Ganglia (MG) e Monitorao de Carga (MC) permaneceram ativos. Dessa
forma, esse conjunto de experimentos 6 seguiu a configurao da Tabela 6.9.
Os resultados dos tempos de busca (TB) com 15 clientes desse conjunto de experimentos so
apresentados na Figura 6.30 em escala logartmica.
Mdia (seg)
(seg)
10,0000
10,0000
6,2855
5,8835
1,0000
1,0000
0,3288
0,3095
0,1000
0,4020
0,3788
0,1526
0,1450
6,0845
0,1000
0,3191
0,3904
1200 Object
300 SPARQL
0,1488
0,0100
0,0100
300 Object
1200 SPARQL
possvel afirmar que os resultados dos tempos de busca com 15 clientes desse CJE-6 so
maiores que os tempos de busca do CJE-2, com exceo do experimento com 1200 servios e o
algoritmo OntObjectSPARQL. Comparando ambos os experimentos em seus respectivos conjuntos,
observam-se que as mdias dos resultados obtidos esto sobrepostas aos intervalos de confiana.
Isso indica que o fato das monitoraes estarem ativas no foi suficiente para superar a grande
variao de tempo exercida neste experimento em especifico. Portanto, a sobrecarga gerada pelas
monitoraes aumenta os tempos mdios de busca, porm no possvel afirmar que eles so
estatisticamente diferentes considerando um intervalo de confiana de 95%.
Por outro lado, utilizando-se a escala logartmica, a Figura 6.31 exibe os resultados com 30
clientes concorrentes deste CJE-6 e apresenta um tempo de busca (TB) maior no experimento
com 1200 servios e o algoritmo OntObjectSPARQL do que o seu correspondente no CJE-2. Isso
significa que, com 30 clientes a sobrecarga imposta pelas monitoraes teve um efeito mais significativo no tempo de busca (TB), pois, o nmero de requisies diretamente proporcional
quantidade de vezes que o mdulo precisa analisar e selecionar o melhor provedor. Ou seja, quanto
89
maior o nmero de requisies, maior ser a sobrecarga no mdulo e, consequentemente, maior

ser o tempo de busca.
Os resultados dos tempos de buscas apresentados nas Figuras 6.30 e 6.31 esto proporcionalmente de acordo os resultados do CJE-2, confirmando as anlises que indicam o algoritmo OntAlgorithmObject como o mais eficiente e que a variao do nmero de clientes e de servios
proporciona um aumento no linear nos resultados.
Mdia (seg)
(seg)
15,7474
15,0837
10,0000
1,0000
0,8063
0,7275
0,9119
0,8463
1,6987
1,6183
10,0000
1,0000
15,4156
0,1000
0,7669
0,8791
300 Object
1200 Object
1,6585
0,1000
0,0100
0,0100
300 SPARQL
1200 SPARQL
Os resultados dos tempos de resposta para os clientes (RTC) esto exibidos na Figura 6.32.
importante lembrar que esse tempo envolve principalmente o tempo de transmisso das informaes pela rede e o tempo de processamento das mensagens SOAP, tanto do lado do mdulo
como do lado do cliente. Os tempos mdios de resposta para os clientes neste sexto conjunto de
experimentos so maiores que os seus correspondentes no CJE-2. Dessa forma, a anlise estatstica
indica que de acordo com os resultados obtidos nestes conjuntos de experimentos, pode-se afirmar
que eles so estatisticamente diferentes.
Os resultados de RTC com 15 clientes de cada experimento (Figura 6.32) tambm so estatisticamente diferentes.
Na Figura 6.33 so exibidos os tempos de respostas com 30 clientes simultneos. O comportamento e a anlise desses resultados so praticamente os mesmos dos resultados com 15 clientes.
Porm, o tempo mdio de resposta para o cliente foi maior em cada um dos experimentos.
A Tabela 6.13 lista o fatorial completo 23 das mdias dos tempos de busca (TB) do mdulo,
as mdias dos tempos de resposta para os clientes (RTC) e a partir dessas ltimas mdias so
calculadas as vazes (Throughput).
90

Mdia (seg)
(seg)
10,0000
10,0000
6,6488
6,2455
1,0000
0,6851
0,6004
0,4375
0,4006
1,0000
0,6847
0,6313
6,4472
0,1000
0,4191
0,6428
0,6580
1200 Object
300 SPARQL
0,1000
0,0100
0,0100
300 Object
1200 SPARQL
(CJE-6).

Mdia (seg)
(seg)
15,7474
15,0837
10,0000
1,0000
0,8063
0,7275
0,9119
0,8463
1,6987
1,6183
10,0000
1,0000
15,4156
0,1000
0,7669
0,8791
300 Object
1200 Object
1,6585
0,1000
0,0100
0,0100
300 SPARQL
1200 SPARQL
(CJE-6).
As porcentagens de influncia de cada fator durante a execuo dos experimentos na busca por
servios so exibidas na Figura 6.34.
Os resultados apresentados na Tabela 6.13 resumem as observaes discutidas no decorrer
desta subseo. A porcentagem de influncia de cada fator foi calculada, conforme exibe a Figura
6.34. Em concordncia com os resultados dos outros conjuntos de experimentos, neste sexto conjunto o fator C (Algoritmo) foi novamente o que mais influencia nos experimentos executados.
Esse fator obteve 29,84% de influncia ficando frente do fator A (Nmero de Servios) com
25,39% e a interao entre fatores AC com 23,68%. Ao contrrio do que houve com a influncia
91

Experimento
1
2
3
4
5
6
7
8
Fator A
(N. Servios)
300
300
300
300
1200
1200
1200
1200
Fator B
(N. Clientes)
15
15
30
30
15
15
30
30
Fator C
(Algoritmo)
Object
SPARQL
Object
SPARQL
Object
SPARQL
Object
SPARQL
TB Mdia
0,14883
0,39042
0,38433
1,31037
0,31912
6,08451
0,55112
15,03554
RTC Mdia
0,4191
0,658
0,7669
1,6585
0,6428
6,4472
0,8791
15,4156
Throughput
2,39
1,52
1,3
0,6
1,56
0,16
1,14
0,06
no CJE-5, o fator A manteve a segunda posio. Esse resultado era previsto, pois o nmero de
servios entre os conjuntos de experimentos 5 e 6 so diferentes, enquanto no CJE-5 a avaliao
considerou at 600 servios, o CJE-6 considerou at 1200 servios.
BC 5,75%
AC 23,68%
ABC 4,20%

AB 4,19%
A (N. Servios)
B (N. Clientes)
C (Algoritmo)
AB
AC
BC
ABC
O fator fixo Monitorao de Carga (MC) estava ativo (ON) neste conjunto de experimentos.
Os resultados sobre a carga de processamento imposta pelo mdulo durante os experimentos esto
exibidos na Figura 6.35.
92

Mdia (%)
Intervalo de Confiana (%)
100,00
88,94
90,00
85,59
80,86
80,00
74,73
70,00
60,00
50,00
47,07
40,00
33,04
32,38
37,85
30,00
22,36
20,00
27,08
25,82
18,08
17,53
10,00
0,00
13,77
9,19
7,74
8,46
19,95
29,10
77,79
15,92
30,06
42,46
87,26
15x300
Object
15x1200
Object
15x300
Sparql
15x1200
Sparql
30x300
Object
30x1200
Object
30x300
Sparql
30x1200
Sparql
Figura 6.35: Porcentagem da carga de processamento (CPU-Load) do mdulo durante os

experimentos (CJE-6).
Novamente, a anlise dos resultados dessa carga de processamento confirma que preciso uma
maior taxa de processamento para o algoritmo OntAlgorithmSPARQL. Quando h 1200 servios e
30 clientes concorrentes a taxa de processamento fica prxima dos 90% de utilizao dos processadores, enquanto o algoritmo OntAlgorithmObject, na pior situao, tem uma taxa de processamento por volta dos 30%. Dessa forma, o OntAlgorithmObject mais eficiente e de acordo com
os resultados apresentados na Tabela 6.13 ele tambm possui uma melhor vazo.
O stimo conjunto de experimentos (CJE-7) semelhante ao conjunto de experimentos 5 (CJE5) com a diferena de que os fatores fixos de monitorao foram todos desativados, incluindo o
fator fixo Gravao de Log (GL) que registra informaes sobre o mdulo, em especial informaes de desempenho. Por esse motivo, no foi possvel registrar o tempo de busca do mdulo,
sendo que os nicos registros coletados foram os tempos de resposta nos clientes (RTC).
Os resultados dos tempos de resposta para 15 clientes neste stimo conjunto de experimentos
so exibidos na Figura 6.36.
93
RTC 15 Clientes - 300x600 Servios -OntAlgorithmObject x OntAlgorithmSPARQL

Mdia (seg)
2,0000
2.00000
1.30854
1.23181
1,0000
1.00000
0.62028
0.46103
0.34354
0.33728
0,0000
0.58174
0.39971
0,3404
0,4304
0,6010
1,2702
300 Object
600 Object
300 SPARQL
600 SPARQL
0.00000
(CJE-7).
Analisando-se os resultados da Figura 6.36 verificou-se que os experimentos que utilizam o algoritmo OntAlgorithmObject possuem um desempenho melhor. Esse comportamento o mesmo
dos outros conjuntos de experimentos e, alm disso, quanto maior o nmero de servios, maior
o tempo de resposta. Os resultados de tempo de resposta nos 15 clientes do CJE-7 so estatisticamente inferiores aos resultados dos outros conjuntos de experimentos correspondentes (CJE-1 e
CJE-5). Esse resultado faz sentido, pois neste stimo conjunto de experimentos no h sobrecarga
imposta por nenhuma monitorao. Os resultados para 30 clientes concorrentes so exibidos na
Figura 6.37 e mantm os mesmo princpios dos resultados com 15 clientes. A diferena que os
tempos com 30 clientes so maiores.
Mdia (seg)
(seg)
4,0000
4.00000
2.98253
3,0000
3.00000
2.85980
2,0000
2.00000
1,0000
0,0000
0.57200
0.50870
0,5403
300 Object
0.68170
0.94945
0.88661
1.00000
0.59743
0,6396
0,9180
2,9212
600 Object
300 SPARQL
600 SPARQL
0.00000
(CJE-7).
94
A Tabela 6.14 lista o fatorial completo 23 das mdias dos tempos de resposta para os clientes
(RTC) e a partir dessas mdias so calculadas as vazes (Throughput).
Fator A
(N. Servios)
300
300
300
300
600
600
600
600
Experimento
1
2
3
4
5
6
7
8
Fator B
(N. Clientes)
15
15
30
30
15
15
30
30
Fator C
(Algoritmo)
Object
SPARQL
Object
SPARQL
Object
SPARQL
Object
SPARQL
RTC Mdia
0,34041
0,60101
0,54035
0,91803
0,43037
1,27018
0,63956
2,92117
Throughput
2,94
1,66
1,85
1,09
2,32
0,79
1,56
0,34
Os resultados apresentados na Tabela 6.14 facilitam a visualizao da superioridade do algoritmo OntAlgorithmObject na velocidade de atendimento das requisies e, consequentemente, na
vazo. As porcentagens de influncia dos fatores foram calculadas e esto apresentadas na Figura
6.38.
AC
15,37%
ABC
BC
6,06% 4,37%
AB
4,50%
A (N. Servios)
20,40%
B (N. Clientes)
14,08%
A (N. Servios)
B (N. Clientes)
C (Algoritmo)
AB
AC
BC
ABC
C (Algoritmo)
35,22%
Figura 6.38: Porcentagem de Influncia de cada fator no tempo de resposta nos clientes (RTC)
Os resultados de influncia neste CJE-7 foram calculados considerando-se os tempos de respostas nos clientes. Observa-se que o fator C (Algoritmo) novamente o fator que mais tem
influncia no sistema com 35,22%. Na segunda posio ficou o fator A (Nmero de Servios) com
20,40, seguido pela interao entre os fatores A e C (AC) com 15,37%. O fator B (Nmero de
Clientes) aparece em quarto lugar com 14,08% e as demais interaes complementam o restante
da influncia. Nota-se que o clculo da influncia confirma que a variao de utilizao de um algoritmo por outro tem impacto nos resultados. A discrepncia de desempenho entre os algoritmos
95
justifica essa maior influncia. A quantidade de clientes concorrentes no teve muito impacto neste
CJE-7. Pelo contrrio, foi minimizada pela inativao dos monitoramentos e dos registradores de
log e desempenho, pois, a cada requisio no foi mais preciso registrar logs em arquivos ou base
de dados e nem monitorar e selecionar provedores dinamicamente. Por outro lado, no foi possvel coletar dados de carga de processamento. Alm disso, no possvel realizar um processo
de depurao de erros, embora esses no tenham ocorrido durante os experimentos, pois todas as
requisies foram atendidas.
O oitavo conjunto de experimentos (CJE-8) complementa o stimo conjunto de experimentos
(CJE-7). Conforme a Tabela 6.9, a diferena entre eles est apenas nos nveis do fator A (Nmeros
de Servios) e, consequentemente, essa diferena afeta os resultados do clculo de influncia dos
fatores.
Na ausncia dos dados coletados pela Gravao de Log (GL) foi possvel recuperar resultados
apenas do Tempo de Resposta dos Clientes (RTC). Os resultados para 15 clientes concorrentes
considerando 300 ou 1200 servios com ambos os algoritmos esto exibidos em escala logartmica
na Figura 6.39.
Mdia (seg)
10,0000
10,0000
6,3097
5,9756
1,0000
1,0000
0,5827
0,3435
0,3373
0,4974
0,6203
0,5817
0,5400
0,6010
1200 Object
300 SPARQL
6,1427
0,3404
0,1000
0,1000
300 Object
1200 SPARQL
(CJE-8).
Da mesma forma que nos outros conjuntos de experimentos, aqueles experimentos que foram
executados utilizando o algoritmo OntAlgorithmObject tiveram um melhor tempo de resposta. A
quantidade de nmero de servios e o tempo de resposta tm uma relao direta, ou seja, quanto
maior o nmero de servios maior ser o tempo de resposta. Contudo, esse aumento no segue um
padro linear, isso significa que dobrar ou quadruplicar o nmero de servios no ir necessariamente aumentar o tempo de resposta em duas ou quatros vezes respectivamente.
96
A anlise dos resultados com 30 clientes semelhante quela com 15 clientes. Porm, os tempos de resposta so maiores devido ao aumento da carga de trabalho imposta por mais requisies
concorrentes. A Figura 6.40, em escala logartmica, exibe os resultados dos tempos de resposta do
mdulo com 30 clientes, 300 ou 1200 servios e ambos os algoritmos de busca.
RTC 30 Clientes - 300x1200 Servios -OntAlgorithmObject x OntAlgorithmSPARQL
Mdia (seg)
(seg)
12,8146
12,2433
10,0000
1,0000
0,7684
0,5720
0,9494
0,8866
12,5290
10,0000
1,0000
0,6957
0,5087
0,5403
0,7320
0,9180
0,1000
0,1000
300 Object
1200 Object
300 SPARQL
1200 SPARQL
(CJE-8).
O resultado do tempo de resposta para 30 clientes com 1200 Servios e o algoritmo OntAlgorithmSPARQL inviabiliza a utilizao do mdulo nessas condies, pois, trata-se de um tempo de
espera demasiadamente alto por parte do usurio (cliente). Neste oitavo conjunto de experimento
no foi possvel coletar informaes sobre a taxa de processamento da mquina que hospeda o
mdulo, porm relembrando que o resultado correspondente no CJE-6 (que atingiu quase 90% de
utilizao dos processadores) foi de 15,41 segundos na mdia, enquanto neste conjunto de experimentos (CJE-8) foi de 12,52 segundos na mdia. Portanto, considerando esse exemplo (o pior caso
com o maior nmero de servios, o maior nmero de clientes e o pior algoritmo) nota-se que h
uma pequena influncia dos fatores fixos de monitorao e de gravao de informaes (logs e desempenho). Contudo, as porcentagens de influncia dos fatores fixos no puderam ser calculadas,
pois embora eles variem de estado (ativo ou inativo) entre um conjunto de experimento e outro,
dentro do mesmo conjunto de experimento eles estavam fixos. Variar estes fatores fixos dentro dos
conjuntos de experimentos seria preciso o clculo do fatorial completo de 27 , criando assim uma
quantidade de possibilidades com 128 experimentos diferentes.
A Tabela 6.15 lista esse fatorial completo 23 das mdias dos tempos de resposta para os clientes
(RTC) e com base nessas mdias so calculadas as vazes (Throughput).
Com base nos resultados da Tabela 6.15 foi possvel calcular a influncia dos fatores que podem
ser observados na Figura 6.41.
97

Experimento
1
2
3
4
5
6
7
8
Fator A
(N. Servios)
300
300
300
300
1200
1200
1200
1200
BC 3,70%
AC 26,06%
Fator B
(N. Clientes)
15
15
30
30
15
15
30
30
Fator C
(Algoritmo)
Object
SPARQL
Object
SPARQL
Object
SPARQL
Object
SPARQL
RTC Mdia
0,34041
0,60101
0,54035
0,91803
0,54003
6,14269
0,73204
12,52897
Throughput
2,94
1,66
1,85
1,09
1,85
0,16
1,37
0,08
ABC 3,43%

AB 3,41%
A (N. Servios)
B (N. Clientes)
C (Algoritmo)
AB
AC
BC
ABC
Figura 6.41: Porcentagem de Influncia de cada fator no tempo de resposta nos clientes (RTC)
Analisando os resultados da Figura 6.41 verifica-se que, apesar de porcentagens diferentes,
as posies dos principais fatores foram as mesmas da Figura 6.41. O fator C (Algoritmo) teve
a maior influncia no sistema com 30,18%. Na segunda posio ficou o fator A (Nmero de
Servios) com 28,55%, seguido pela interao entre os fatores A e C (AC) com 26,06%. O fator B
(Nmero de Clientes) aparece em quarto lugar com 4,67% e as demais interaes complementam
o restante da influncia. Nota-se que o fator A neste CJE-8 teve um aumento quando comparado
ao seu correspondente no CJE-7, pois o experimento considerou um nmero maior de servios
cadastrados na ontologia e no registro UDDI.
6.6
Consideraes Finais
Este captulo abordou a avaliao de desempenho do mdulo UDOnt-Q. A configurao do

ambiente foi apresentada detalhando-se os recursos de software e hardware utilizados. Foram
98
realizados e executados trs planejamentos de experimentos, dois deles focados no processo de

realizao (inferncia e classificao) das ontologias do mdulo proposto nesta dissertao e a
Pizza. O terceiro planejamento corresponde aos diversos conjuntos de experimentos que visam
analisar os tempos de busca do mdulo, resposta ao cliente e de vazo com relao a esse tempo de
resposta. Alm disso, em alguns conjuntos de experimentos foi possvel identificar a sobrecarga
de processamento exercida com a utilizao do mdulo.
Os resultados dos dois primeiros planejamentos abrem uma discusso sobre a utilizao da
abordagem de restries de equivalncia de classes para ontologias que possuem diversos indivduos associados classe ou subclasse dessas restries, pois o tempo necessrio para o processo
de realizao afetado de forma no linear quando o nmero de indivduos aumenta.
Com relao anlise dos resultados do terceiro planejamento, verificou-se que o fator C (Algoritmo) o que tem mais influncia no sistema. Nesse ponto, notou-se que o algoritmo OntAlgorithmObject possui melhor desempenho e eficincia que o OntAlgoritmSPARQL, devido aos
motivos comentados anteriormente.
De forma geral, as concluses sobre as anlises dos resultados e propostas de melhorias sero
discutidas no capitulo de Concluses.
C APTULO
7
Concluses
7.1
Concluso Geral
Neste projeto de mestrado diversas atividades de fundamental importncia foram realizadas,

antes mesmo da concepo da ontologia e desenvolvimento do mdulo UDOnt-Q. Uma delas foi
a pesquisa sobre metodologias de desenvolvimento de ontologias, seguida de uma aprendizagem
prtica nesse contexto. Outras atividades, que tambm demandaram pesquisa, foram o estudo de
ordem terica e prtica sobre assuntos relacionados Web Semntica.
O contexto deste trabalho est inserido em arquiteturas SOA, considerando a seleo de algumas informaes de qualidade de servio de Web Services a fim de classific-los por meio de
recursos da Web Semntica. Dessa forma, os servios adequados podem ser selecionados, antes da
busca por informaes funcionais no registro UDDI. Portanto, os conhecimentos adquiridos sobre
Web Semntica e Ontologia foram direcionados para a utilizao prtica no desenvolvimento do
projeto.
O desenvolvimento da ontologia uma das contribuies deste trabalho. Outras ontologias
poderiam ter sido utilizadas, como por exemplo, a OWL-S. Mas, optou-se pela criao de uma ontologia nova, que alm de acrescentar o conhecimento e aprendizado na elaborao e desenvolvimento de ontologias, pode tambm ser mais simples e ter um propsito especifico para atender s
necessidades dos algoritmos na seleo de Web Services. Alm disso, quando a elaborao do projeto estava em fase inicial, verificou-se que a OWL-S uma ontologia complexa dividida em trs
nveis (camadas) e que algumas informaes se repetem entre elas. Esse fato poderia prolongar o
tempo de desenvolvimento dos algoritmos inviabilizando a concluso do projeto de mestrado.
99
100
7.2. CONTRIBUIES
Aps a concluso da parte de desenvolvimento, uma das maiores preocupaes foi manter o
ambiente de teste configurado corretamente para que os testes fossem realizados com sucesso. Foi
preciso certificar-se de que os arquivos de configuraes estavam corretos e que as quantidades de
clientes e servios estavam de acordo com os experimentos. Dos trs algoritmos desenvolvidos,
os dois escolhidos para a avaliao de desempenho foram testados exaustivamente e, assim como
o mdulo UDOnt-Q, provaram ser funcionais, com o algoritmo OntAlgorithmObject sendo mais
eficiente em termos de tempo de busca do servio, tempo de resposta ao cliente, vazo e eficincia
de processamento. A vantagem do algoritmo OntAlgoritmSPARQL que ele pode ser facilmente
adaptado para outras ontologias, pois basicamente preciso a alterao da query de consulta e
possveis ajustes no retorno da informao que a ontologia oferece. Porm, os resultados mostram
que, nas condies propostas, esse algoritmo o menos eficiente.
Dessa forma, este estudo produziu resultados importantes em relao a uma abordagem multidisciplinar para solucionar um problema de qualidade em um sistema distribudo, como o caso de
uma arquitetura SOA para Web Services. A execuo de uma avaliao de desempenho serviu no
apenas para verificar o desempenho do projeto proposto, mas tambm para quantificar e destacar
as vantagens e desvantagens da utilizao de alguns recursos da rea de Web Semntica na busca
por garantir a QoS adequada em Web Services.
7.2
Contribuies
As principais contribuies deste projeto de mestrado foram o desenvolvimento e avaliao

de um mdulo e seus algoritmos que fazem uso de recursos da Web Semntica na seleo de Web
Services com qualidade. O mdulo UDOnt-Q mostrou-se funcional e de fcil adaptao para servir
de plataforma para diversos tipos de algoritmos. Alm disso, o mdulo disponibiliza diversos
recursos de gravao de logs de erros e informaes de desempenho que podem ser utilizados
para diversas pesquisas que consideram a utilizao de novos algoritmos na parte de seleo e
composio de servios. O mdulo foi construdo em componentes, o que permite que outros
projetos faam uso do mdulo por completo ou ento utilizar apenas os seus componentes. Por
exemplo, pode-se utilizar o componente UC (UDDI Components) para acesso ao registro UDDI.
Os trs algoritmos desenvolvidos com recursos da Web Semntica para seleo de servios
fazem parte da contribuio deste trabalho. Os algoritmos OntAlgorithmObject e OntAlgorithmSPARQL
foram submetidos a uma avaliao de desempenho e as suas vantagens e desvantagens foram destacadas. O algoritmo OntAlgorithmObject provou ser o mais eficiente e poder ser utilizado em um
ambiente de produo. Alm desses algoritmos, h trabalhos de mestrado e iniciao cientfica em
andamento no grupo de pesquisa que, ou esto utilizando, ou planejam utilizar o mdulo UDOnt-Q
como plataforma para seus experimentos.
A avaliao de desempenho do processo de inferncia da ontologia conforme as configuraes
adotadas (abordagem utilizando: restries de equivalncia de classes, a mquina de inferncia
CAPTULO 7. CONCLUSES
101
Pellet e um grande nmero de indivduos) apresentou resultados interessantes, porm limitam a

escalabilidade. Esses resultados indicam a necessidade de uma proposta alternativa para o processo
de inferncia quando se pretende trabalhar com um grande nmero de indivduos ou quando esse
nmero aumenta constantemente.
Esta dissertao de mestrado abordou tema estratgico na rea de Sistemas Distribudos, utilizando recursos de Web Semntica e Ontologia que caracterizaram, assim, um projeto multidisciplinar. O conhecimento adquirido na rea de Web Semntica abre, dentro do grupo de pesquisa, um
novo espao para trabalhos que possam utilizar a Web Semntica na soluo de vrios problemas
em sistemas distribudos.
7.2.1
Produo Cientfica
Este projeto de mestrado permitiu a produo inicial de dois artigos que foram publicados em
eventos cientficos e uma monografia, publicada como Notas Didticas, no mbito do ICMC, como
listados a seguir:
- NAKAMURA, L. H. V. ; ESTRELLA, J. C. ; SANTANA, M. J. ; SANTANA, R. H. C.
Semantic Web and Ontology applied to Web Services Discovery with QoS. Proceedings of the
12th Brazilian Symposium on Computer Systems of High Performance (IEEE), 2011, Vitria, ES,
Brazil.
- NAKAMURA, L. H. V. ; ESTRELLA, J. C. ; SANTANA, M. J. ; SANTANA, R. H. C.
Using Semantic Web for Selection of Web Services with QoS. Proceedings of the 17th Brazilian
Symposium on Multimedia and the Web, 2011. Florianpolis, SC, Brazil.
- NAKAMURA, L. H. V.; ESTRELLA, J. C.; SANTANA M. J.; SANTANA R. H. C. Desenvolvimento de Web Services com Eclipse. Notas Didticas - ICMC-USP, 2011, So Carlos,
SP.
7.3
Trabalhos Futuros
As contribuies alcanadas neste projeto de mestrado so significativas, pois apresentam resultados adequados do emprego de Web Semntica na seleo de Web Services com QoS. Alm
disso, os resultados obtidos nas avaliaes de desempenho podem ser comparados com outras
propostas e as aplicaes desenvolvidas utilizadas em novos projetos. Em sequncia ao trabalho
desenvolvido, podem ser adotadas algumas melhorias para a obteno de novos resultados. Sendo
assim, para trabalhos futuros destacam-se as seguintes sugestes:
Realizar uma anlise mais detalhada nos cdigos e bibliotecas do mdulo, Jena e Pellet a
fim de encontrar a razo do comportamento do algoritmo OntAlgorithmSPARQL.
102
7.3. TRABALHOS FUTUROS
Utilizar outra mquina de inferncia para verificar se o comportamento no processo de inferncia sofre grandes variaes. Por exemplo, substituindo o Pellet pelo FaCT++18 .
O fato da mquina de inferncia Pellet ocupar apenas um ncleo durante o processo de
inferncia leva necessidade de mais investigao visando soluo para esse problema. Por
exemplo, utilizando-se conceitos de computao concorrente (paralela) pretende-se realizar
uma decomposio de dados e dividir tais dados em vrios elementos de processamentos,
para que sejam executados em um modelo mestre-escravo. Dessa forma, a ontologia seria
replicada para cada provedor e em cada cpia da ontologia haveria apenas os indivduos
(servios, acordos, clientes, etc.) do provedor que ela representa (decomposio de dados).
Cada cpia da ontologia com seus respectivos indivduos seriam associados a uma instncia
da mquina de inferncia Pellet. O mdulo (mestre) daria incio ao processo de inferncia
distribudo em paralelo uma vez que cada instncia do Pellet (escravo) estaria associada a
um ncleo de processamento.
Alterar o cdigo da mquina de inferncia Pellet para que utilize todos os recursos computacionais disponveis pode ser outra soluo, contudo analisando parte do cdigo fonte do
Pellet notou-se que h muitos mtodos recursivos o que tornam esta tarefa no trivial.
Novos algoritmos de seleo e composio de servios podem ser desenvolvidos e avaliados
com o auxilio do mdulo UDOnt-Q.
Novos fatores, nveis e variveis de respostas podem ser considerados em futuras avaliaes
de desempenho. Por exemplo, pode-se analisar o tempo gasto pelo mdulo (mais especificamente pelo componente CIS) quando os provedores precisam cadastrar as informaes no
funcionais (QoS) na ontologia e as funcionais no registro UDDI.
Novas ferramentas e recursos podem ser substitudos para verificar a sua influncia no desempenho. Por exemplo, substituir o SGBD MySQL pelo PostgreSQL19 , o software de
monitoramento distribudo Ganglia pelo Nagios20 ou ainda o framework Jena pela OWL
API21 .
Outras tcnicas de anlise de desempenho alternativas ao processo de regresso com a anlise
pelo fatorial completo podem ser utilizadas. Por exemplo, pode-se utilizar futuramente a
Anlise de Varincia com Mltiplos Fatores (ANOVA N-WAY).
Finalmente, melhorias podem ser implementadas no mdulo referente parte de segurana
e tolerncia a falhas.
18
http://owl.man.ac.uk/factplusplus/
http://www.postgresql.org/
20
http://www.nagios.org/
21
http://owlapi.sourceforge.net/
19
Referncias
A KLOUF, Y.; R EZIG , E. An ontological approach for dynamic functionality-based web services
discovery using expert systems. In: Applications of Digital Information and Web Technologies,
2009. ICADIWT 09. Second International Conference on the, 2009, p. 187 192.
A MBLER , S. Agile modeling: Effective practices for extreme programming and the unified process. New York, NY, USA: John Wiley & Sons, Inc., 2002.
A NTONIOU , G.; H ARMELEN , F. V. Semantic web primer, 2nd edition. MIT Press, 2008.
BAOCAI , Y.; H UIRONG , Y.; P ENGBIN , F.; L IHENG , G.; M INGLI , L. A framework and qos
based web services discovery. In: Software Engineering and Service Sciences (ICSESS), 2010
IEEE International Conference on, 2010, p. 755 758.
B ERNARAS , A.; L ARESGOITI , I.; C ORERA , J. Building and reusing ontologies for electrical network applications. Proceedings of the European Conference on Artificial Intelligence
(ECAI96), p. 298302, 1996.
B ERNERS -L EE , T. Semantic web on xml - semantic web - xml2000. Disponvel em: http:
//www.w3.org/2000/Talks/1206-xml2k-tbl/. ltimo acesso: 14/12/2009, 2000.
B HAKTI , M.; A BDULLAH , A. Design of an autonomic services oriented architecture.
Information Technology (ITSim), 2010 International Symposium, 2010, p. 805 810.
In:
B ROEKSTRA , J.; K LEIN , M.; D ECKER , S.; F ENSEL , D.; H ARMELEN , F.; H ORROCKS , I. Enabling knowledge representation on the web by extending rdf schema. In: In Proceedings of
the Tenth International World Wide Web Conference (WWW10), Hong Kong, 2001.
C ARASE , S. J. Uma ontologia funcional de reputao para agentes. Dissertao de mestrado
em engenharia eltrica, Escola Politcnica da Universidade de So Paulo - USP, So Paulo, SP,
2005.
103
104
REFERNCIAS
C ARROLL , J. J.; D ICKINSON , I.; D OLLIN , C.; R EYNOLDS , D.; S EABORNE , A.; W ILKINSON ,
K. Jena: implementing the semantic web recommendations. In.Proceedings of the 13th international World Wide Web conference on Alternate track papers and posters, 2004.
E NDREI , M.; A NG , J.; A RSANJANI , A.; C HUA , S.; C OMTE , P.; K ROGDAHL , P.;
L UO , M.; N EWLING , T.
Patterns: Service-oriented architecture and web services.
IBM Redbooks, disponvel em: http://www.redbooks.ibm.com/redbooks/pdfs/
sg246303.pdf. ltimo acesso: 15/12/2009, 2004.
E RL , T. Soa princpios de design de servios. Pearson Prentice Hall PTR, 2009.
E RRADI , A.; M AHESHWARI , O. A broker-based approach for improving web services reliability.
In: IEEE International Conference on Web Services (ICWS05), 2005.
E STRELLA , J.; T OYOHARA , R.; K UEHNE , B.; TAVARES , T.; S ANTANA , R.; S ANTANA , M.;
B RUSCHI , S. A performance evaluation for a qos-aware service oriented architecture. In:
Services (SERVICES-1), 2010 6th World Congress on, 2010, p. 260 267.
E STRELLA , J. C. Wsarch: Uma arquitetura para proviso de web services com qualidade de
servio. Tese de doutorado, ICMC-USP, So Carlos, SP, 2010.
FAKHFAKH , K.; C HAARI , T.; TAZI , S.; D RIRA , K.; J MAIEL , M. A comprehensive ontologybased approach for sla obligations monitoring. The Second International Conference on Advanced Engineering Computing and Applications in Sciences, 2008.
FARKAS , P.; C HARAF, H.
p. 912, 2003.
Web services planning concepts.
Journal Of .net Technologies,
F ISHER , M.; B LACE , R.; H EBELER , J.; P EREZ -L OPEZ , A. Semantic web programming. Wiley,
2009.
G ENNARI , J. H.; M USEN , M. A.; F ERGERSON , R. W.; G ROSSO , W. E.; C RUBZY, M.; E RIKS SON , H.; N OY, N. F.; T U , S. W. The evolution of protg: An environment for knowledgebased systems development. International Journal of Human-Computer Studies, 2002.
G OH , C. M.; L EE , S. P.; H E , W.; TAN , P. S. Web 2.0 concepts and technologies for dynamic
b2b integration. In: Emerging Technologies and Factory Automation - ETFA, IEEE, 2007.
G RUNINGER , M.; F OX , M. S. Methodology for design and evaluation of ontologies. In: Proceedings of Workshop on basic Ontological Issues in Knowledge Sharing, 1995.
H EFLIN , J. D. Towards the semantic web: Knowledge representation in a dynamic, distributed
environment. Tese de doutorado, University of Maryland, Maryland - USA, 2001.
REFERNCIAS
105
H OLGER , K.; R ECTOR , A.; S TEVENS , R.; W ROE , C.; J UPP, S.; M OULTON , G.;
D RUMMOND , N.
A Practical Guide To Building OWL Ontologies Using Protg 4 and CO-ODE Tools Edition 1.2.
The University Of Manchester, disponvel
em: http://owl.cs.manchester.ac.uk/tutorials/protegeowltutorial/
resources/ProtegeOWLTutorialP4_v1_2.pdf, 2009.
H OPPER , J. Reduza o consumo de energia do linux, parte 1: Subsistema cpufreq. Disponvel em:
http://www.ibm.com/developerworks/br/linux/library/l-cpufreq-1/. ltimo acesso: 14/09/2011,
2009.
IBM Web service level agreements (wsla) project. Disponvel em: http://www.research.
ibm.com/wsla/about.html. ltimo acesso: 10/12/2009, 2009.
I SOTANI , S.; M IZOGUCHI , R.; B ITTENCOURT, I. I.; C OSTA , E. D . B. Estado da arte em web
semntica e web 2.0: Potencialidades e tendncias da nova gerao de ambientes de ensino na
internet. Revista Brasileira de Informtica na Educao, v. 17, p. 3042, 2009.
JAIN , R. The art of computer systems performance analysis: techniques for experimental design,
measurement, simulation, and modeling. Wiley, 1991.
J OSUTTIS , N. M. SOA na prtica - A Arte da Modelagem de Sistemas Distribudos. 1st. ed.
Oreilly, 2008.
KOMODA , N. Service oriented architecture (soa) in industrial systems. In: IEEE International
Conference on Industrial Informatics, IEEE, 2006.
K RITIKOS , K.; P LEXOUSAKIS , D. Requirements for qos-based web service description and
discovery. In: Computer Software and Applications Conference, 2007. COMPSAC 2007. 31st
Annual International, 2007, p. 467 472.
L EE , S.; S HIN , D. Web service qos in multi-domain. In: Proceedings of Advanced Communication Technology, - ICACT, 2008.
L EE , T. B.; F ISCHETTI , M. Weaving the web - the original design and ultimate destiny of the
world wide web, by its inventor. ISBN 006251587X, 1997.
L EE , Y. Quality-context based soa registry classification for quality of services. In: Proceedings
of the 2008 IEEE International WorkShop on Semantic Computing and Applications, IEEE,
2008.
L OPEZ , M.; G OMEZ -P EREZ , A.; S IERRA , J.; S IERRA , A. Building a chemical ontology using
methontology and the ontology design environment. Intelligent Systems and their Applications,
IEEE, v. 14, n. 1, p. 37 46, 1999.
106
REFERNCIAS
L OPEZ , M. F.; G OMEZ -P EREZ , A.; J URISTO , N. METHONTOLOGY: from Ontological Art
towards Ontological Engineering. In: Proceedings of the AAAI97 Spring Symposium, Stanford,
USA, 1997, p. 3340.
L UO , J.; M ONTROSE , B.; K IM , A.; K HASHNOBISH , A.; K ANG , M. Adding owl-s support to
the existing uddi infrastructure. In: IEEE International Conference on Web Services (ICWS06),
IEEE, 2006.
M A , C.; S ONG , M.; X U , K.; Z HANG , X. Web service discovery research and implementation
based on semantic search engine. In: Web Society (SWS), 2010 IEEE 2nd Symposium on, 2010,
p. 672 677.
M ALIK , S.; G OEL , A.; M ANIKTALA , S. A comparative study of various variants of sparql in
semantic web. In: Computer Information Systems and Industrial Management Applications
(CISIM), 2010 International Conference on, 2010, p. 471 474.
M ARTIMIANO , L. A. F. Sobre a estruturao de informao em sistemas de segurana computacional: o uso de ontologia. Tese de doutorado em cincias de computao e matemtica
computacional, ICMC-USP, So Carlos, SP, 2006.
M ARTIN , D.; B URSTEIN , M.; H OBBS , J.; L ASSILA , O.; M C D ERMOTT, D.; M C I LRAITH ,
S.; NARAYANAN , S.; PAOLUCCI , M.; PARSIA , B.; PAYNE , T.; S IRIN , E.; S RINI VASAN , N.; S YCARA , K.
Owl-s: Semantic markup for web services. Disponvel em:
http://www.w3.org/Submission/OWL-S/. ltimo acesso: 14/08/2009, 2004.
M ASSIE , M. L.; C HUN , B. N.; C ULLER , D. E. The ganglia distributed monitoring system:
Design, implementation and experience. Parallel Computing, v. 30, p. 2004, 2003.
M ATOS , J. Distribuio de carga flexvel e dinmica para provedores de web services. Dissertao de mestrado, ICMC - Universidade de So Paulo, So Carlos, SP, 2009.
M AXIMILIEN , E. M.; S INGH , M. P. A framework and ontology for dynamic web services
selection. IEEE Internet Computing, 2004.
M URUGESAN , S. Understanding web 2.0. IT Professional, v. 9, n. 4, p. 3441, 2007.
NAKAMURA , L. V.; E STRELLA , J. C.; S ANTANA , M. J.; S ANTANA , R. H. C. Semantic web
and ontology applied to web services discovery with qos. Proceedings of the 12th Brazilian Symposium on Computer Systems of High Performance (IEEE), 2011, Vitria, ES, Brasil.,
2011a.
NAKAMURA , L. V.; E STRELLA , J. C.; S ANTANA , M. J.; S ANTANA , R. H. C. Using semantic
web for selection of web services with qos. Proceedings of the 17th Brazilian Symposium on
Multimedia and the Web, Florianpolis, SC, Brazil, 2011b.
REFERNCIAS
107
N OY, N. F.; M C G UINNESS , D. L. Ontology development 101: A guide to create your first
ontology. Relatrio Tcnico, Knowledge System Laboratory - Stanford University, 2001, 2001.
O REN , E.; KOTOULAS , S.; A NADIOTIS , G.; S IEBES , R.; T EIJE , A.; H ARMELEN , F. Marvin:
Distributed reasoning over large-scale semantic web data. Web Semant., v. 7, p. 305316, 2009.
PAPAIOANNOU , I. V.; T SESMETZIS , D. T.; ROUSSAKI , I. G.; A NAGNOSTOU , M. E. A qos
ontology language for web-services. Proceedings of the 20th International Conference on
Advanced Information Networking and Applications (AINA06), 2006.
PAPAZOGLOU , M. P.; G EORGAKOPOULOS , D. Service-oriented computing. Communications
of the ACM. October 2003/Vol. 46, No. 10, 2003.
P RUD HOMMEAUX , E.; S EABORNE , A. Sparql query language for rdf.
http://www.w3.org/TR/rdf-sparql-query/. ltimo acesso: 05/03/2011, 2008.
Disponvel em:
R AJENDRAN , T.; BALASUBRAMANIE , P. An optimal agent-based architecture for dynamic

web service discovery with qos. In: Computing Communication and Networking Technologies
(ICCCNT), 2010 International Conference on, 2010, p. 1 7.
S EABORNE , A.
RDQL - A Query Language for RDF.
http://www.w3.org/Submission/RDQL/ ltimo acesso: 19/04/2009, 2004a.
Disponvel em:
S EABORNE , A.
A programmers introduction to rdql.
Disponvel
http://jena.sourceforge.net/tutorial/RDQL/ ltimo acesso: 19/04/2009, 2004b.
em:
S IRIN , E.; PARSIA , B. Sparql-dl: Sparql query for owl-dl. In: In 3rd OWL Experiences and
Directions Workshop (OWLED-2007, 2007.
S IRIN , E.; PARSIA , B.; G RAU , B. C.; K ALYANPUR , A.; K ATZ , Y. Pellet: A practical owl-dl
reasoner. ACM - Journal of Web Semantics, 2007.
S MITH , M. K.; W ELTY, C.; M C G UINNESS , D. L. Owl web ontology language- guide.
Disponvel em: http://www.w3.org/TR/owl-guide/. ltimo acesso: 14/08/2009, 2004.
TANENBAUM , A. S. Redes de computadores. 4th. ed. Editora Campus, 2003.
TAVARES , R. K.; W ESTPHALL , C. B. An architecture to provide qos in web services. In: Communications Society subject matter experts for publication in the IEEE ICC 2006 proceedings,
IEEE Computer Society, 2006.
TAVARES , T. C. Caracterizao de cargas de trabalho para avaliao de desempenho em web
services. Dissertao de mestrado, Universidade de So Paulo, So Carlos, SP, 2009.
T HOMAS , J. P.; T HOMAS , M.; G HINEA , G. Modeling of web services flow. In: Proceedings of
the IEEE International Conference on E-Commerce (CEC03), IEEE Computer Society, 2003.
108
REFERNCIAS
T OYOHARA , R. K. T. Construindo web services para avaliao de desempenho de uma arquitetura orientada a servios com qos. Qualificao de mestrado, USP - Universidade de So
Paulo, So Carlos, SP, 2009.
T RAN , V. X.; T SUJI , H.
A survey and analysis on semantic in qos for web services.
In.Proceedings of the international Conference on Advanced Information Networking and Applications, 2009.
T RAN , X. V. Ws-qosonto: A qos ontology for web services. In: In: 2008 IEEE International
Symposium on Service-Oriented System Engineering, IEEE International Symposium, 2008.
T SAI , Y.-H.; H WANG , S.-Y.; TANG , Y. A hybrid approach to automatic web services discovery.
In: Service Sciences (IJCSS), 2011 International Joint Conference on, 2011, p. 277 281.
U SCHOLD , M.; G RUNINGER , M. Ontologies: principles, methods and applications. Knowledge Engineering Review, 93155 p., 1996.
W3C Owl web ontology language reference. Disponvel em: http://www.w3.org/TR/owl-ref/
ltimo acesso: 21/04/2009, 2004a.
W3C Resource description framework (rdf): Concepts and abstract syntax. Disponvel em:
http://www.w3.org/TR/2004/REC-rdf-concepts-20040210/ ltimo acesso: 21/04/2009, 2004b.
W3C Web ontology language overview. Disponvel em: http://www.w3.org/TR/owl-features/
ltimo acesso: 21/04/2009, 2004c.
W3C Web services architecture. Disponvel em: http://www.w3.org/TR/2004/NOTE-ws-arch20040211/ ltimo acesso: 19/04/2009, 2004d.
W U , H.; G UO , C. The research and implementation of web service classification and discovery
based on semantic. In: Computer Supported Cooperative Work in Design (CSCWD), 2011 15th
International Conference on, 2011, p. 381 385.
X U , Z.; M ARTIN , P.; P OWLEY, W.; Z ULKERNINE , F. Reputation-enhanced qos-based web
services discovery. Proceedings of the 2007 IEEE International Conference on Web Services
(ICWS), 2007.
Y E , G.; W U , C.; Y UE , J.; C HENG , S. A qos-aware model for web services discovery. Proceedings of the 2009 First International Workshop on Education Technology and Computer Science,
2009.
Y UAN - SHENG , L.; X IAO , H.; Y U , W.; S I - XIN , S. Research on a web services discovery model
framework. In: Computational Intelligence and Software Engineering (CiSE), 2010 International Conference on, 2010, p. 1 4.
REFERNCIAS
109
Z HOU , C.; C HIA , L.; L EE , B. Qos measurement issues with daml-qos ontology. Proceedings
of the 2005 IEEE International Conference on e-Business Engineering (ICEBE05), 2005.
110
REFERNCIAS
ANEXOS
111
113
114
ANEXO 1.
ANEXO 1
Documentos de Especificaes da Ontologia
DOCUMENTO DE ESPECIFICAO DE REQUISITO DA ONTOLOGIA

Domnio: Clientes
Data: 15 de fevereiro de 2010.
Conceitualizado por: Luis H. V. Nakamura / Jlio C. Estrella.
Implementado por: Luis H. V. Nakamura.
Propsito: Ontologia sobre os clientes que solicitam os Web Services. Esta ontologia pode ser utilizada
para obter informaes a respeito dos clientes, por exemplo, o nome do cliente e qual a sua sub-classe:
ClientGold, ClientSilver e ClientBronze.
Nvel de Formalidade: Semi-formal.
Escopo: Lista de clientes atendidos pelo UDOnt-Q o nmero de clientes varivel. Limitados em trs
sub-classes: Gold, Silver, Bronze. Cada classe possui um acordo que estabelece um nvel de qualidade de
servio (QoS) exigido pelos clientes.
Lista de conceitos: Clientes, Acordos e QoS.
Informaes a respeito das propriedades dos clientes: Nome (Name), Descrio
(Description), Endereo (Address).
Fonte de Conhecimento:
Especialistas:
Jlio C. Estrella
Luis H. V. Nakamura
Artigos:
LEE, S.; SHIN, D. Web service qos in multi-domain. In: Proceedings of Advanced
Communication Technology, - ICACT, 2008.
Web sites:
Web
service
level
agreements
(wsla)
project.
Disponvel
em:
http://www.research.ibm.com/wsla/about.html. ltimo acesso: 10/12/2009, 2009.
Teses:
ESTRELLA, J. C. Wsarch: Uma arquitetura para proviso de web services com grids e
qualidade de servio. Tese de doutorado, ICMC-USP, So Carlos, SP, 2010.
Livros:
ERL, T. Soa princpios de design de servios. Pearson Prentice Hall PTR, 2009.
JOSUTTIS, N. M. SOA na prtica - A Arte da Modelagem de Sistemas Distribudos. 1st.
ed. Oreilly, 2008.
115

Domnio: Acordo
Propsito: Ontologia sobre os acordos existentes que so definidos nas classes dos clientes, os quais
solicitam os Web Services. Esta ontologia pode ser utilizada para obter informaes a respeito dos
acordos, por exemplo, tipo do acordo (Light, Medium, Heavy).
Escopo: Lista de acordos que podem estar estabelecidos nas classes dos clientes. Cada classe tem um
acordo relacionado, cada acordo tem uma sub-classe (LightAgreement, MediumAgreement e
HeavyAgreement) estabelece relao com QoS a qual contm os nveis (valores) dos parmetros de
qualidade de servio (QoS).
Lista de conceitos: Acordos (Light, Medium, Heavy), parmetros e valores de QoS.
Informaes a respeito das propriedades dos acordos: Nome (Name) e Descrio
(Description).
Especialistas:
Jlio C. Estrella
Luis H. V. Nakamura
Artigos:
Web sites:
Web
service
level
agreements
(wsla)
project.
Disponvel
em:
Livros:
ed. Oreilly, 2008.
116
ANEXO 1.

Domnio: Qualidade de Servio (QoS)
Propsito: Ontologia sobre a qualidade de servio (QoS) dos Web Services que so solicitados pelos
clientes. Esta ontologia pode ser utilizada para obter informaes a respeito da qualidade de servio dos
Web Services, por exemplo, a disponibilidade de utilizao de um determinado Web Service.
Escopo: Lista de parmetros de qualidade de servios que podem ser prestados em um Web Service
pelos provedores, nmero fixo de 16 parmetros 1.
Lista de conceitos: Qualidade de servio, Parmetros (atributos ou propriedades), Nveis (ou
valores), sub-classes: QoSGold, QoSSilver e QoSBronze. O que determina a qual sub-classe uma QoS
pertence so as restries de classes equivalentes criadas na ontologia e os nveis (valores) que um
atributo de QoS possui. Por exemplo, caso a restrio de classe equivalente indique que:
Todas as QoS que tenham o atributo Response_Time (tempo de resposta) menor que 1 (um)
segundo sero equivalentes a classe QoSGold.
Todas as QoS que tenham o atributo Response_Time (tempo de resposta) entre 1 e 3 segundos
sero equivalentes a classe QoSSilver.
Todas as QoS que tenham o atributo Response_Time (tempo de resposta) maior que 3 segundos
sero equivalentes a classe QoSBronze.
Isso implique que toda classe QoS que tenha o atributo Response_Time com um determinado valor
(nvel) ser classificado em uma das trs sub-classes quando a ontologia for inferida.
Especialistas:
Jlio C. Estrella
Luis H. V. Nakamura
Artigos / Documentos:
Holger, K., Rector, A., Stevens, R., Wroe, C., Jupp, S., Moulton, G., and Drummond, N.
(2009). A Practical Guide To Building OWL Ontologies Using Protg 4 and CO-ODE
Tools Edition 1.2.
Web sites:
Web
service
level
agreements
(wsla)
project.
Disponvel
em:
Parmetros: Tempo de resposta, Latncia, Vazo, Escalabilidade, Disponibilidade, Confiabilidade, Acessibilidade,

Capacidade, Preciso, Robustez, Estabilidade, Custo, Segurana, Integridade, Desempenho e Interoperabilidade.
117

Domnio: Servios
Propsito: Ontologia sobre os Web Services que so solicitados pelos clientes. Esta ontologia pode ser
utilizada para obter informaes a respeito dos servios, por exemplo, o nome do servio.
Escopo: Lista de servios prestados pelos provedores um nmero varivel.
Lista de conceitos: Web services, QoS, WSDL.
Informaes a respeito das propriedades dos servios: Nome (Name), Descrio
(Description), Endereo (Address), Empresa/Instituio responsvel (Company), principal
Desenvolvedor responsvel (Developer), interface WSDL (Interface).
Especialistas:
Jlio C. Estrella
Luis H. V. Nakamura
Artigos:
Web sites:
Web
service
level
agreements
(wsla)
project.
Disponvel
em:
Teses:
Livros:
ed. Oreilly, 2008.
118
ANEXO 1.

Domnio: Provedores
Propsito: Ontologia sobre os provedores de Web Services que atendem as requisies dos clientes. Esta
ontologia pode ser utilizada para obter informaes a respeito dos provedores de servios, por exemplo,
nome do provedor.
Escopo: Lista de provedores dentro da arquitetura, o nmero de provedores varivel. A relao de
cardinalidade entre os provedores e os servios de zero para muitos.
Lista de conceitos: Provedor, Servio.
Informaes a respeito das propriedades dos provedores: Nome (Name), Endereo (Address),
Empresa/Instituio responsvel (Company).
Especialistas:
Jlio C. Estrella
Luis H. V. Nakamura
Artigos:
Web sites:
Web
service
level
agreements
(wsla)
project.
Disponvel
em:
Teses:
Livros:
ed. Oreilly, 2008.
119
120
ANEXO 2.
ANEXO 2
Documentos da Conceituao da Ontologia

Glossrio de Termos GT (Glossary of Terms)
Nome
Descrio
Agreement
(Acordo)
Acordo estabelecido entre o consumidor do servio (cliente) e o provedor de

servio a respeito da Qualidade de Servio (QoS) prestada. Cada acordo
possui uma subclasse (Agreement[SubClass]). O que determina a subclasse
do Acordo a subclasse de QoS relacionada a ele.
[SubClass]Agree O acordo (Agreement) pode ter sub-classes so os tipos que um acordo pode
ment (Subassumir. No escopo desta ontologia existem trs sub-classes de acordos: 1)
Classes do
LightAgreement, 2) MediumAgreement e 3) HeavyAgreement, que
Acordo)
determinam o nvel de rigorosidade do acordo. Sendo o Light aqueles que
possuem parmetros de QoS com valores menos rigorosos, o Heavy com
valores mais rigorosos e o Medium um meio termo. A ontologia deve ser
extensvel para aceitar novas sub-classes de Acordos.
Client (Cliente ou O cliente ou consumidor pode tanto ser um usurio quanto um agente
Consumidor do computacional de uma empresa. (EAI, B2C e B2B). O cliente deve estar
Servio)
relacionado a um nico Acordo.
Client[SubClass] Os clientes so subdividos em classes (grupos), cada classe tem um tipo e um
(Sub-Classe de
acordo relacionado. Dependendo do tipo de acordo o cliente pode ser um
Clientes)
ClientGold (HeavyAgreement), ClientSilver (MediumAgreement) ou
ClientBronze (LightAgreement).
Provider
Os provedores (servidores) de servios so (geralmente) empresas que
(Provedores ou prestam servios web (Web Services). A utilizao desses servios poder ou
Servidores)
no envolver custos financeiros. Os provedores so responsveis por publicar
os servios disponveis no registro UDDI e quando existir um acordo deve
cumpri-lo caso contrrio poder haver a penalidade de multa. Os servios
que possuem parmetros e nveis de QoS so monitorados constantemente
pelos provedores que ficam responsveis pode garantir a qualidade de
servio e manter as bases de informaes (UDDI e Ontologia) atualizadas
quanto a estas informaes. A escolha final do servio quando existirem
mais de um servio que atenda as requisies de QoS pode ser determinada
por agentes externos de monitoramento, portanto informaes relevantes,
como por exemplo, o endereo do provedor, devem est presentes na
ontologia.
Service (Web
Os Web Services so prestados pelos provedores e consumidos pelos
Service)
clientes. A lista de servios se encontra no registro UDDI. Os servios esto
associados classe QoS, ou seja os servios tm QoS (parmetros de QoS).
Service[Class]
Assim como os Acordos, os Web Services so subdividos em trs subclasses
(Sub-Classe de
(ServiceGold, ServiceSilver e ServiceBronze), a classificao em cada uma
Web Service)
dessas subclasses depende do seu relacionamento com a subclasse de QoS.
Por exemplo, QoSGold infere em um ServiceGold, QoSSilver infere em um
ServiceSilver e QoSBronze infere em um ServiceBronze.
QoS
QoS Qualidade de Servio, a qualidade de servio composta por

parmetros (atributos). Cada parmetro tem um nvel (valor) e um tipo de
dado. So os servios (Web Services) e o Acordos que dispem de QoS. Os
atributos de QoS sero aqueles especificados na Tabela de QoS (Lee e Shin,
2008).
121
rvore de Classificao de Conceitos (Concept-Classification Tree)

Thing
|
| --- Agreement
|
|
|
|- Heavy Agreement
|
|- Medium Agreement
|
|- Light Agreement
|
| --- Provider
|
| --- Client
|
|
|
|- ClientGold
|
|- ClientSilver
|
|- ClientBronze
|
| --- Service
|
|- ServiceGold
|
|- ServiceSilver
|
|- ServiceBronze
|
| --QoS
|- QoSGold
|- QoSSilver
|- QoSBronze
122
ANEXO 2.
Diagramas de Relaes Binrias (Binary-Relations Diagrams)
123
Dicionrio de Conceitos (Concept Dictionary)

Nome do
Conceito
Agreement
Sinnimo
Instncias
Atributos
Relaes
Acrnimo/
Sigla
Agmt
[Name]Agreement
QoS
AgreementFine
AgreementName
hasQoS,
isAgreementOf
Client
Agent
[Name]Client
hasAgreement
Provider
[Name]Provider
Service
[Name]Service
QoS
[Name]QoS
ClientName,
ClientDescription,
ClientAddress,
Agreement
ProviderName,
ProviderAddress,
ProviderCompany,
Services
ServiceName,
ServiceDescription,
ServiceAddress,
ServiceCompany,
ServiceDeveloper,
ServiceInterface,
QoS
Provider
Accessibility
Accuracy
Availability
Capacity
Cost
Integrity
Interoperability
Latency
Performance
Reliability
Response Time
Robustness
Scalability
Security
Stability
Throughput
hasService
hasServiceQoS
IsServiceQoSof
IsQoSOf
124
ANEXO 2.
Tabelas de Relaes Binrias (Binary-Relations Tables)

Nome da Relao
Conceito fonte
Cardinalidade Fonte
Conceito Alvo
Cardinalidade Alvo
Propriedades Matemticas
Relao inversa
hasAgreement
Client
(1,1)
Agreement
(1,1)
isAgreementOf
Nome da Relao
Conceito fonte
Cardinalidade Fonte
Conceito Alvo
Cardinalidade Alvo
Relao inversa
hasQoS
Agreement
(1,1)
QoS
(1,1)
isQoSOf
Nome da Relao
Conceito fonte
Cardinalidade Fonte
Conceito Alvo
Cardinalidade Alvo
Relao inversa
hasService
Provider
(1,n)
Service
(n,1)
isServiceOf
Nome da Relao
Conceito fonte
Cardinalidade Fonte
Conceito Alvo
Cardinalidade Alvo
Relao inversa
hasServiceQoS
Service
(1,1)
QoS
(1,1)
isServiceQoSof
125
Tabela de Instncias (Instance Table)1

Instncia
[ClientName]Agreement
(Acordos)
Instncia
[Name]Client[Number]
(Clientes)
Instncia
[Name]Provider[Number]
(Provedores)
Instncia
[Name]Service[Number]
(Servios)
Instncia
[Name]Service[Number]QoS
Atributo
hasName
hasFine
hasQos
Valor
[Name]Agreement
(Double) Valor da Multa
[ClientName]QoS
Atributo
hasClientDescription
hasClientAddress
hasClientName
hasAgreement
Valor
(String)
(String) Endereo IP
(String) Mesmo da Instncia
[ClientName]Agreement
Atributo
hasProviderName
hasProviderAddress
hasProviderCompany
hasService
Valor
(String) Endereo IP
(String) USP[Number]
[Name]Service[Number]
Atributo
hasServiceName
hasServiceAddress
hasServiceInterface
hasServiceDescription
hasServiceDeveloper
hasServiceCompany
hasServiceQoS
Valor
(String) Endereo IP
(String) WSDL
(String)
(String) Luis Nakamura
(String) USP[Number]
[Name]Service[Number]QoS
Atributo
Todos os atributos da tabela
de QoS (Lee e Shin, 2008):
Valor
(Double) Nvel do atributo
de QoS.
has[atributo]ContentValue
(QoS dos Servios)
Instncia
[NameClient]QoS
Atributo
Todos os atributos da tabela
de QoS (Lee e Shin, 2008):
Valor
(Double) Nvel do atributo
de QoS.
has[atributo]ContentValue
(QoS dos Clientes)
No so listadas todas as instncias, pois na ontologia h mais de mil instncias (por exemplo, ontologia com 1200
servios e 30 clientes). Apenas o padro e valores adotados so exibidos.
126
ANEXO 2.
Tabelas de Atributos das Instncias (Instance-Attribute Table)

Nome do atributo
Tipo de Valor (Tipo de dado)
Intervalo de valores
Valor Padro
Cardinalidade
hasAgreementFine
Double
(1,1)
Nome do atributo
Valor Padro
Cardinalidade
hasAgreementName
String
(1,1)
Nome do atributo
Valor Padro
Cardinalidade
hasClientName
String
(1,1)
Nome do atributo
Valor Padro
Cardinalidade
hasClientAddess
String
(1,1)
Nome do atributo
Valor Padro
Cardinalidade
hasClientDescription
String
(1,1)
Nome do atributo
Valor Padro
Cardinalidade
hasServiceCompany
String
(1,1)
Nome do atributo
Valor Padro
Cardinalidade
hasServiceDeveloper
String
(1,1)
Nome do atributo
Valor Padro
Cardinalidade
hasServiceInterface
String
(1,1)
Nome do atributo
Valor Padro
Cardinalidade
hasServiceAddress
String
(1,1)
Nome do atributo
Valor Padro
Cardinalidade
hasServiceDescription
String
(1,1)
127
Nome do atributo
Valor Padro
Cardinalidade
hasServiceName
String
(1,1)
Nome do atributo
Valor Padro
Cardinalidade
hasProviderAddress
String
(1,1)
Nome do atributo
Valor Padro
Cardinalidade
hasProviderCompany
String
(1,1)
Nome do atributo
Valor Padro
Cardinalidade
hasProviderName
String
(1,1)
Nome do atributo
Valor Padro
Cardinalidade
has[Atributo_de_QoS]ContentValue
Double
(1,1)
Nome do atributo
Valor Padro
Cardinalidade
hasAgreement
Agreement
(1,1)
Nome do atributo
Valor Padro
Cardinalidade
hasQoS
QoS
(1,1)
Nome do atributo
Valor Padro
Cardinalidade
hasService
Service
(1,n)
Nome do atributo
Valor Padro
Cardinalidade
hasServiceQoS
QoS
(1,1)
128
ANEXO 3.
ANEXO 3
Anexo 3.1 - Criao de alguns elementos da ontologia do mdulo UDOnt-Q
Os primeiros elementos criados na ontologia do mdulo UDOnt-Q foram os provedores. Cinco
provedores foram cadastrados, este nmero foi escolhido pelo fato dos experimentos contarem
apenas com cinco servidores disponveis. Para atender a todas as possibilidades dos experimentos
foram criados vrios arquivos da mesma ontologia. Para o fator nmero de clientes h duas opes:
15 clientes e 30 clientes. Portanto, hora foram cadastrados 15 clientes hora 30 clientes na ontologia.
Para facilitar a execuo dos experimentos foram criados dois arquivos da ontologia para atender
essas duas possibilidades.
Na ontologia com 15 clientes foram criados:
1 Cliente Gold.
7 Clientes Silver.
7 Clientes Bronze.
Na ontologia com 30 clientes foram criados:
1 Cliente Gold.
15 Clientes Silver.
14 Clientes Bronze.
Para a criao de cada cliente na ontologia foi criado um acordo para ser associado a ele.
Seguindo essa sequencia, para cada acordo criado foi criada uma QoS.
O nmero de Web Services cadastrados na ontologia pode assumir trs valores (300,600 e 1200)
dependendo do experimento executado. Novamente, para facilitar os experimentos foram criadas
trs variaes do arquivo da ontologia. Para cada uma dessas variaes havia duas opes para o
nmero de clientes (15 e 30). Dessa forma, foram criados seis arquivos da ontologia.
Para cada Web Service cadastrado foi criada e associada uma QoS que quando inferida seria
classificada em uma subclasse do tipo Gold, Silver ou Bronze. Os valores dos atributos de cada
QoS foram gerados aleatoriamente, porm esses valores ficam dentro de um limite pr-definido
pelo programador. Dessa forma, o programado poderia determinar qual seria a subclasse de QoS
daquela determinada QoS que estava sendo criado e consequentemente a subclasse do Web Service.
Apenas uma pequena quantidade de Web Services poderia se encaixar na pesquisa dos algoritmos do UDOnt-Q. Portanto, o programador definiu que apenas 10% dos servios teriam o nome
de busca utilizados pelos clientes, os outros servios teriam outro nome diferente do nome de
servio que os clientes desejavam. Como nos experimentos houve requisies de vrios tipos de
129
clientes (Gold, Silver, Bronze) os servios foram igualmente divididos nestas trs categorias. A
figura a seguir exibe um exemplo da forma de como foram criados as QoS e Web Services para a
ontologia com 300 servios. Analisando a figura a seguir, nota-se que o programador cadastrava
os servios em cinco ciclos de 60, totalizando 300 servios. Em cada ciclo de 60 servios foram
cadastrados 6 (seis) servios com o nome procurado e outros 54 com outro nome. No total so
300 servios, porm apenas 30 servios possuem o nome da busca (10%) e esto divididos nas
trs subclasses (10 por subclasse). Da mesma forma as ontologias com 600 e 1200 servios foram
criadas.
60 Servios
1 ... 9 Servios
Gold
10 ... 18 Servios
Silver
19 ... 27 Servios
Bronze
28 e 29 Servios
Gold
30 e 31 Servios
Silver
32 e 33 Servios
Bronze
34 ... 42 Servios
Gold
43 ... 51 Servios
Silver
52 ... 60 Servios
Bronze
Outro
Nome
Nome da
Busca
X5
300
Servios
Outro
Nome
Esquema da criao de 300 servios na ontologia.
130
ANEXO 4.
ANEXO 4
Anexo 4.1 - Resultados dos Conjuntos de Experimentos (CJE) 3 e 4
Fatorial completo 23 e Mdias do Tempo de Busca (TB)do CJE-3

Experimento
1
2
3
4
5
6
7
8
Fator A
(N. Servios)
300
300
300
300
600
600
600
600
Fator B
(N. Clientes)
15
15
30
30
15
15
30
30
Fator C
(Algoritmo)
Object
SPARQL
Object
SPARQL
Object
SPARQL
Object
SPARQL
TB Mdia
0,10664
0,42057
0,29714
1,09020
0,15821
1,32245
0,35368
2,80296
RTC Mdia
0,36866
0,72796
0,59309
1,42669
0,46365
1,61105
0,68893
3,22292
Throughput
2,71
1,37
1,69
0,70
2,16
0,62
1,45
0,31
Fatorial completo 23 e Mdias do Tempo de Busca (TB)do CJE-4

Experimento
1
2
3
4
5
6
7
8
Fator A
(N. Servios)
300
300
300
300
1200
1200
1200
1200
Fator B
(N. Clientes)
15
15
30
30
15
15
30
30
Fator C
(Algoritmo)
Object
SPARQL
Object
SPARQL
Object
SPARQL
Object
SPARQL
TB Mdia
0,10664
0,42057
0,29714
1,09020
0,24107
6,02424
0,46384
12,44431
RTC Mdia
0,3687
0,7280
0,5931
1,4267
0,5830
6,3147
0,8131
12,8750
Throughput
2,71
1,37
1,69
0,70
1,72
0,16
1,23
0,08

Dissertacao Luis Nakamura

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Dissertacao Luis Nakamura

Uploaded by

Copyright:

Available Formats

Utilizao de web semntica para seleo de

informaes de web services no registro UDDI

SERVIO DE PS-GRADUAO DO ICMC-USP

Utilizao de web semntica para seleo de

Luis Hideo Vasconcelos Nakamura

Orientador: Prof. Dr. Marcos Jos Santana

Dissertao apresentada ao Instituto de Cincias

Ficha catalogrfica elaborada pela Biblioteca Prof. Achille Bassi

Nakamura, Luis Hideo Vasconcelos

Agradeo inicialmente a Deus pela existncia, por estar ao meu lado

S te projeto de mestrado aborda a utilizao de recursos da Web Semn-

tica na seleo de informaes sobre Web Services no registro UDDI

master project addresses the use of Semantic Web resources in

Ontologia e Web Semntica

4.2.2 Metodologia de Noy e McGuinness . . . . . . . .

UDOnt-Q - Universal Discovery with Ontology and QoS

Colaboraes em uma arquitetura orientada a servios (Traduzido de (Endrei et al.,

Exemplo de representao de Domnios. . . . . . . . . . . . . . . . . . . . .

Modelo abstrato da relao entre o cliente, mdulo, algoritmos e a ontologia. . . . 29

Arquitetura do Jena (Carroll et al., 2004). . . . . . . . . . . . . . . . . . . . . . .

Viso resumida dos elementos de software utilizados no ambiente de testes. . . . . 59

Comportamento do processamento de Inferncia da Ontologia com 30 Clientes e

6.29 Porcentagem da carga de processamento (CPU-Load) do mdulo durante os experimentos (CJE-5). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Atributos de QoS para Web Services (Lee e Shin, 2008) . . . . . . . . . . . . . . . 13

Application Programming Interface

Business Process Execution Language

Conseil Europen pour la Recherche Nuclaire

Domain Name System

Enterprise Application Integration

File Transfer Protocol

HyperText Transfer Protocol

International Business Machines

Integrated Development Environment

MIT OASIS OWL

Institute of Electrical and Electronics Engineers

Resource Description Framework

Resource Description Framework Schema

Service Level Agreement

Simple Mail Transfer Protocol

Service Oriented Architecture

Simple Object Access Protocol

TOronto Virtual Enterprise

Universal, Discovery, Description and Integration

Universal Discovery with Ontology and QoS

Uniform Resource Identifier

World Wide Web Consortium

Web Services Description Language

Web Service Level Agreement

eXtensible Markup Language

Packard - HP e a Microsoft, so alguns exemplos da indstria de TI (Tecnologia da Informao)

A ampla e iminente proliferao de Web Services despertou o interesse do meio acadmico e

Geralmente prximo ou dentro do UDDI.

1.3. TRABALHOS RELACIONADOS

alguns no apresentam informaes de desempenho e outros no apresentam um desenvolvimento

Esta dissertao est organizada da seguinte forma:

Paralelamente ao avano do potencial de processamento e do aumento da largura de banda, a

Arquitetura Orientada a Servios (SOA)

2.3. PADRES FUNDAMENTAIS DE WEB SERVICES

Padres Fundamentais de Web Services

Os Web Services so uma implementao da arquitetura SOA (Erradi e Maheshwari, 2005),

CAPTULO 2. WEB SERVICES

Figura 2.2: Modelo bsico de uma arquitetura orientada a servios.

Arquitetura de Web Services

2.4. ARQUITETURA DE WEB SERVICES