Cristiano Biancardi
Distribuição e Execução de Wrappers em
Ambiente de Grid para o CoDIMS
Vitória - ES
2005
Cristiano Biancardi
Distribuição e Execução de Wrappers em
Ambiente de Grid para o CoDIMS
Dissertação apresentada ao Programa de
Pós-Graduação em Informática do Centro
Tecnológico da Universidade Federal do Espírito Santo, como requisito parcial para obtenção do Grau de Mestre em Informática, na
área de concentração em Banco de Dados.
Orientador:
Prof. Dr. Álvaro C. P. Barbosa
Universidade Federal do Espírito Santo - UFES
Centro Tecnológico
Departamento de Informática
Vitória - ES
2005
Distribuição e Execução de Wrappers em
Ambiente de Grid para o CoDIMS.
COMISSÃO EXAMINADORA
Prof. Dr. Álvaro Cesar Pereira Barbosa
Universidade Federal do Espírito Santo
Orientador
Prof. Dr. Bruno Richard Schulze
Laboratório Nacional de Computação Cientíca
Membro Externo
Prof. Dr. José Gonçalves Pereira Filho
Universidade Federal do Espírito Santo
Membro Interno
Vitória, 21 de junho de 2005.
Dedico esta dissertação aos meus pais, cujo exemplo de
honestidade, trabalho, companheirismo e perseverança
tem sido um norteador para a minha vida. Obrigado por tudo.
Amo vocês.
Agradecimentos
A Deus, pela vida, pelas conquistas e por me dar forças para superar os obstáculos
encontrados no decorrer desses anos.
Ao professor, orientador e amigo Álvaro Cesar Pereira Barbosa pela oportunidade
concedida, pelos ensinamentos e pelas valiosas contribuições no fechamento deste trabalho.
Ao amigo Leonardo Jose Silvestre, companheiro de Mestrado, Graduação, alojamento
(seção 12) e república (ÊtaNóis), pelas inúmeras horas de discussões (e bota inúmeras) que
foram fundamentais para a conclusão deste trabalho e pelos momentos de descontração
(é mui difíci).
Ao meu irmão Edson, por acreditar em mim, pela oportunidade concedida e pela
ajuda constante no decorrer da minha vida, valeu mano!
A minha irmã Rosângela e ao meu cunhado José Ailton dos Santos, pela ajuda e por
me ter como exemplo para os seus lhos.
A minha irmã Maristela, pelo incentivo constante.
Aos meus tios Sinval e Emília, pela ajuda e incentivo. E aos seus lhos, Vinícius,
Thiago e Gabriel, pelo bem querer. Vocês são a minha segunda família.
Aos amigos do LPRM e do mestrado, Gustavo Gaburro, Rodrigo Bonfá, Ricardo Rios,
Camilo, Roberto e Adilson, pela troca de conhecimento e pelos inúmeros momentos de
descontração.
Aos demais professores do DI/UFES, em especial Saulo Bortolon e Davidson Cury,
pelo conhecimento recebido.
A todos aqueles que direta ou indiretamente contribuiram para a realização deste
trabalho.
E nalmente, a Daniele Marinho, pela compreensão em minhas ausências, pelo carinho, pelo companheirismo e por sempre me dar forças e me incentivar nos momentos
difíceis. Sua contribuição foi fundamental para a realização deste trabalho.
Os ignorantes, acham que sabem de tudo, privam-se de
um dos maiores prazeres da vida: APRENDER.
Autor desconhecido
Resumo
Nos dias de hoje, a quantidade de dados disponíveis vem aumentando consideravelmente. Assim, é cada vez mais notável a necessidade de sistemas capazes de prover acesso
integrado a esses dados. Na tentativa de solucionar esse problema, sistemas middleware
de integração de dados, tal como o CoDIMS (Congurable Data Integration Middleware
System), vem sendo desenvolvidos com o objetivo de fornecer, a partir de fontes de dados
essencialmente heterogêneas e distribuídas, uma visão única, uniforme e homogênea.
Para isso, os dados a serem integrados devem ser convertidos para um único modelo de
dados, utilizado pelo sistema integrador e chamado modelo de dados comum. Esta função
é desempenhada pelos wrappers, que, além disso, fazem a comunicação com as fontes de
dados. Na versão atual do CoDIMS, os wrappers estão implementados internamente
no componente de Acesso aos Dados, e executando em um mesmo servidor. Isso causa
sobrecarga deste servidor e, conseqüentemente, um overhead na execução das consultas.
Dentro deste contexto, este trabalho tem por nalidade desacoplar os wrappers do
componente Acesso aos Dados e alocá-los em um ambiente distribuído, mais precisamente,
em um Grid, podendo utilizar de uma maneira consistente, transparente e segura múltiplos
recursos computacionais distribuídos. Isso é feito através da criação de uma camada de
Wrapper -Grid, que estende os serviços Grid dentro do cenário de integração de dados.
Com essa abordagem cria-se a possibilidade de reduzir a sobrecarga do servidor Acesso
aos Dados através da execução, em paralelo, dos wrappers e das sub-consultas. Além disso,
armazena os conjuntos-resultado provenientes da execução das sub-consultas nas fontes
de dados em um ambiente distribuído, permitindo executar o PEC (Plano de Execução
de Consutlas) de forma distribuída.
Abstract
Nowadays the amount of available data is increasing substantially. Thus, the need
of systems to provide integrated access to these data is notable. Middleware systems for
data integration, such as CoDIMS (Congurable Data Integration Middleware System),
are being developed in the attempt to solve this problem. The goal is to supply, from
heterogeneous and distributed data sources, an unique, homogeneous and uniform vision.
To achieve this goal, the data to be integrated must be converted to an unique data
model, used by the integrator system, and called common data model. Wrappers do
this task and communicate with the data sources. The current version of CoDIMS, the
wrappers and Data Access component are in the same server, because the wrappers are
implemented internally in the Data Access component. Thus, generating overload of this
server and overhead in the execution of queries.
In this context, this work has the purpose to decouple wrappers from the Data Access
component and allocate them in a distributed environment, more precisely in a Grid.
Making it is possible to use multiple distributed computational resources in a consistent,
transparent and secure way. To do this, Wrapper-Grid layer was created. It extends the
Grid services inside the data integration scene. This approach makes it possible to reduce
the overload of the Data Access server, with the parallel execution of wrappers and the
sub-quereis. Morover, the result-sets originated from the execution of the sub-queries are
stored in a distributed environment, allowing the query execution plan to be execute in a
distributed form.
Lista de Figuras
1
Camanda intermediária - Middleware. . . . . . . . . . . . . . . . . . . . . . 18
2
Middleware para Integração de Dados. . . . . . . . . . . . . . . . . . . . . 19
3
Wrappers em um sistema integrador . . . . . . . . . . . . . . . . . . . . . . 20
4
Uma possível conguração do CoDIMS (BARBOSA, 2001). . . . . . . . . . 21
5
O CoDIMS e seus componentes básicos. . . . . . . . . . . . . . . . . . . . . 22
6
Arquitetura do CoDIMS-G (FONTES et al., 2004). . . . . . . . . . . . . . . 28
7
Arquitetura de Serviço do OGSA-DAI (OPEN. . . , 2004a). . . . . . . . . . . 29
8
Serviços OGSA-DAI (OPEN. . . , 2004a). . . . . . . . . . . . . . . . . . . . . 30
9
Framework OGSA-DAI: Interação cliente - OGSA-DAI(QI, 2004). . . . . . 30
10
Camada arquitetural do OGSA-DQP (ALPDEMIR et al., 2003a). . . . . . . 31
11
Interação entre os frameworks OGSA-DQP e OGSA-DAI (OPEN. . . , 2004b). 32
12
Interações durante uma execução de consulta no OGSA-DQP (ALPDEMIR
et al., 2003a). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
33
13
Arquitetura do MOCHA(RODRIGUEZ-MARTINEZ; ROUSSOPOULOS, 2000). 34
14
Arquitetura do MOCHA - RMI. . . . . . . . . . . . . . . . . . . . . . . . . 35
15
Arquitetura do SkyQuery (MALIK et al., 2003). . . . . . . . . . . . . . . . 36
16
Arquitetura de um Grid e seu relacionamento com a arquitetura de protocolo da Internet (FOSTER; KESSELMAN; TUECKE, 2001). . . . . . . . . . 46
17
Arquitetura de um Grid na visão dos programadores de aplicações (FOSTER; KESSELMAN; TUECKE, 2001). . . . . . . . . . . . . . . . . . . . . .
49
18
Uma visão geral do sistema Globus Toolkit (FERREIRA et al., 2002). . . . 50
19
O processo de invocação de um Web Service (SOTOMAYOR, 2003). . . . . 53
20
Tipos de portTypes que um Grid Service pode estender (SOTOMAYOR,
2003). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
21
Interação entre as partes componentes (SOTOMAYOR, 2003).
. . . . . . . 55
22
Arquitetura do CoDIMS sem Grid . . . . . . . . . . . . . . . . . . . . . . . 58
23
Arquitetura do CoDIMS em um ambiente de Grid. . . . . . . . . . . . . . 58
24
Interação entre os sub-componentes do Processmento de Consultas com os
components do CoDIMS. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
25
Interação entre a MEC, Acesso aos Dados(AD) e os wrappers para execução
do PEC. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
26
Fila de sub-consultas a serem executadas. . . . . . . . . . . . . . . . . . . . 61
27
Wrapper Grid Component (WGC). . . . . . . . . . . . . . . . . . . . . . . 62
28
Em cada WGC existem WSs para todas as fontes. . . . . . . . . . . . . . . 63
29
Criação de uma instância WS. . . . . . . . . . . . . . . . . . . . . . . . . . 64
30
Fila de sub-consultas já executadas. . . . . . . . . . . . . . . . . . . . . . . 65
31
Processo de execução de sub-consutlas de forma assíncrona. . . . . . . . . . 65
32
Exemplo de execução de uma consulta. . . . . . . . . . . . . . . . . . . . . 67
33
Dependência entre os pacotes AcessoDados, ProcessamentoConsulta e Wrap-
per -Grid. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68
34
Classes do pacote AcessoDados. . . . . . . . . . . . . . . . . . . . . . . . . 69
35
Classe FachadaAcessoDados do pacote AcessoDados. . . . . . . . . . . . . 69
36
Classe ExecutaSubConsulta do pacote AcessoDados. . . . . . . . . . . . . . 70
37
Classe ExecutaWrapperThread do pacote AcessoDados. . . . . . . . . . . . 71
38
Classe NoticaMec do pacote AcessoDados.
39
Classe ConcretObservable do pacote AcessoDados. . . . . . . . . . . . . . . 71
40
Classes do pacote Wrapper -Grid. . . . . . . . . . . . . . . . . . . . . . . . 72
41
Classe WrapperBDImpl do pacote WrapperGrid. . . . . . . . . . . . . . . . 72
42
Classes do pacote ProcessamentoConsulta. . . . . . . . . . . . . . . . . . . 73
. . . . . . . . . . . . . . . . . 71
43
Classe MEC do pacote ProcessamentoConsulta. . . . . . . . . . . . . . . . 74
44
Diagrama de Classes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75
45
Diagrama de sequência . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76
46
DTD da fonte XML "ambulatorio". . . . . . . . . . . . . . . . . . . . . . . 78
47
Esquema da fonte relacional "paciente".
48
Esquema global visto pelos usuários. . . . . . . . . . . . . . . . . . . . . . 79
49
Consulta enviada ao CoDIMS, na linguagem SQL. . . . . . . . . . . . . . . 79
50
Sub-consulta enviada ao wrapper relacional. . . . . . . . . . . . . . . . . . 80
51
Sub-consulta enviada ao wrapper XML. . . . . . . . . . . . . . . . . . . . . 80
52
Sub-consulta no modelo de dados nativo da fonte (fonte relacional). . . . . 81
53
Infra-estrutura de teste - wrappers centralizados. . . . . . . . . . . . . . . . 82
54
Infra-estrutura de teste - wrappers centralizados - dividida em camadas. . . 83
55
Descrição do serviço Grid WrapperWSImpl em GWSDL. . . . . . . . . . . 84
56
Descrição do serviço Grid WrapperBDImpl em GWSDL. . . . . . . . . . . 85
57
Infra-estrutura de teste - wrappers distribuídos. . . . . . . . . . . . . . . . 86
58
Infra-estrutura de teste - wrappers distribuídos - dividida em camadas. . . 87
59
Gráco de comparação entre as duas abordagens: Centralizada concor-
. . . . . . . . . . . . . . . . . . . 78
rente; Distribuída. Fontes de dados: Bancos relacionais. . . . . . . . . . . . 89
60
Gráco de comparação entre as duas abordagens: Centralizada concorrente; Distribuída. Conjuntos-resultado com tamanho xos. . . . . . . . . . 89
Lista de Tabelas
1
Comparação entre os sistemas. . . . . . . . . . . . . . . . . . . . . . . . . . 37
2
Conguração das partes integrantes da infra-estrutura de teste centralizada. 82
3
Conguração das partes integrantes da infra-estrutura de teste distribuída.
86
Lista de abreviaturas e siglas
CoDIMS
Congurable Data Integration Middleware System
DAISGR
Data Access and Integration Service Group Registry
DAP
Fornecedor de Acesso aos Dados
DQEP
Plano de execução de consulta distrubuído
GDQS
Grid Distributed Query Service
GDS
Grid Data Services
GDSF
Grid Data Services Factories
GQES
Grid Query Evaluation Service
GSH
Grid Service Handle
GSR
Grid Service Reference
GWSDL
Grid Web Services Description Language
MDC
Modelo de Dados Comum
MEC
Máquina de Execução de Consultas
MM
Gerenciador de Metadados
OGSA
Open Grid Services Architecture
OGSI
Open Grid Services Infrastructure
OV
Organização Virtual
PEC
Plano de Execução de Consutlas
QE
Máquina de Consulta
QEM
Gerenciador da Máquina de Execução
QO
Otimizador de Consulta
QPC
Coordenador de Processamento de Consultas
SDE
Service Data Elements
SGBDs
Sistemas Gerendiadores de Banco de Dados
UDDI
Universal Description, Discover and Integration
UML
Unied Modeling Language
URI
Uniform Resource Identier
WGC
Componentes Wrapper Grid
WSDL
Web Services Description Language
Sumário
1 Introdução
1.1
16
Contexto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
1.1.1
Middleware para Integração de Dados . . . . . . . . . . . . . . . . . 17
1.1.2
Wrappers
1.1.3
CoDIMS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
1.2
Motivação do Trabalho . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
1.3
Objetivo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
1.4
Contribuições Esperadas . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
1.5
Metodologia de Trabalho . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
1.6
Organização da Dissertação . . . . . . . . . . . . . . . . . . . . . . . . . . 26
2 Trabalhos Relacionados
27
2.1
Introdução . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
2.2
CoDIMS-G . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
2.3
OGSA-DAI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
2.4
OGSA-DQP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
2.5
MOCHA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
2.6
SkyQuery . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
3 Conceitos e Tecnologias
3.1
38
GRID . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
3.1.1
Benefícios de um Grid . . . . . . . . . . . . . . . . . . . . . . . . . 39
3.2
Grid vs Computação Distribuída
. . . . . . . . . . . . . . . . . . . . . . . 42
3.3
Grid vs Cluster . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
3.3.1
Deciência . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
3.3.2
Componentes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
3.3.3
3.3.2.1
Recursos . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
3.3.2.2
Descrição da Arquitetura de Grid . . . . . . . . . . . . . . 45
Ferramentas de Desenvolvimento . . . . . . . . . . . . . . . . . . . 49
3.3.3.1
Globus Toolkit . . . . . . . . . . . . . . . . . . . . . . . . 49
4 Especicação Funcional
57
4.1
A Camada de Wrapper-Grid do CoDIMS . . . . . . . . . . . . . . . . . . . 57
4.2
Componente Wrapper Grid - WGC . . . . . . . . . . . . . . . . . . . . . . 60
5 Modelagem
5.1
5.2
68
Diagramas de Pacotes e de Classes . . . . . . . . . . . . . . . . . . . . . . 68
5.1.1
Classes do pacote AcessoDados . . . . . . . . . . . . . . . . . . . . 68
5.1.2
Classes do pacote Wrapper-Grid . . . . . . . . . . . . . . . . . . . . 71
5.1.3
Classes do pacote ProcessamentoConsulta . . . . . . . . . . . . . . 73
Diagrama de Sequência . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74
6 Estudo de Caso
77
6.1
Descrição da Aplicação . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77
6.2
Cenários de teste . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81
6.3
6.2.1
Centralizado . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81
6.2.2
Distribuído . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83
Resultados . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87
7 Conclusões
91
7.1
Conclusões gerais . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91
7.2
Contribuições . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92
7.3
Trabalhos Futuros . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93
Referências
96
16
1
Introdução
1.1 Contexto
Com a globalização da economia, a internacionalização das empresas, o aumento dos
negócios e com a conseqüente competitividade de mercado, surgiu a necessidade da criação de mecanismos que atendam aos requisitos deste novo cenário, em um tempo cada
vez menor. O advento da Internet e a criação das redes de alta velocidade viabilizaram
uma diminuição das distâncias no que se refere à localização das fontes de dados. Dentro
deste cenário, torna-se necessário prover uma infra-estrutura de suporte às aplicações que
demandem uma visão integrada dos dados que estão armazenados em diferentes fontes,
que podem estar localizados em diferentes partes dentro de uma empresa, em diferentes empresas localizadas em um mesmo país ou em países distintos, e armazenados em
plataformas operacionais diferentes (HAKIMPOUR; GEPPERT, 2001). Na tentativa de
fornecer uma solução para esse problema, sistemas de integração de dados vêm sendo
desenvolvidos.
A integração de dados de múltiplas fontes é um problema que vem demandando pesquisa na comunidade de Banco de Dados por mais de uma década (SHETH; LARSON,
1990; LITWIN; MARK; ROUSSOPOULOS, 1990; SILBERSCHATZ; ZDONIK, 1997; ABITEBOUL et al., 2003; HALEVY, 2003; BIANCARDI; SILVESTRE; BARBOSA, 2004; ZIEGLER;
DITTRICH, 2004), tendo recebido, nos últimos anos, um impulso signicativo, devido à
necessidade de se integrar a grande quantidade de informação disseminada. Integração
de dados refere-se a combinar dados heterogêneos e distribuídos de forma que uma única
visão, uniforme e homogênea, seja apresentada para o usuário (HAKIMPOUR; GEPPERT,
2001).
As plataformas operacionais de integração de dados, são, geralmente, formadas por sistemas de hardware e software distribuídos, heterogêneos e autônomos. A heterogeneidade
se manifesta sob diferentes formas, tais como: diferentes sistemas operacionais, modelos
de dados, servidores de dados, sistemas de comunicação e hardware. Já a autonomia está
17
relacionada ao fato de cada sistema operar sob um controle local. A distribuiçâo, heterogeneidade e autonomia são representadas como dimensões ortogonais entre si (ÖZSU;
VALDURIEZ, 2001; HASSELBRING, 2000).
Muitas aplicações necessitam de informações de diversas fontes, onde os dados relacionados podem diferir tanto na representação quanto na tecnologia utilizada para o armazenamento. Diversos tipos de soluções para o problema de integração de dados têm sido
propostas. Historicamente, pode-se destacar os Sistemas de Gerenciamento de Bancos de
Dados Heterogêneos (SGBDH) (LITWIN; MARK; ROUSSOPOULOS, 1990; SHETH; LARSON, 1990; THOMAS et al., 1990; PITOURA; BUKHRES; ELMAGARMID, 1995; SILBERSCHATZ; ZDONIK, 1997; CONRAD et al., 1997) e os Sistemas Mediadores (WIEDERHOLD;
GENESERETH, 1997; WIEDERHOLD, 1998). Mais recentemente, sistemas integradores
têm sido classicados, de uma maneira geral, como middleware para integração de dados
(BARBOSA, 2001; HAAS; MILLER; AL., 1999; RODRIGUEZ-MARTINEZ; ROUSSOPOULOS, 2000). Isto porque, para a integração destes dados, a maioria dos sistemas propostos
apresenta uma arquitetura semelhante às denidas nos ambientes cliente/servidor de três
camadas: uma representando as fontes de dados a serem interligadas; outra representando as aplicações clientes; e a camada intermediária com a função de integração de
dados, surgindo então o conceito de middleware para integração de dados (BARBOSA,
2001).
1.1.1
Middleware para Integração de Dados
Middleware é um componente de software que tem a nalidade de interligar processos
clientes a processos servidores, disponibilizando um conjunto de serviços e visando reduzir
a complexidade do desenvolvimento e da execução de uma aplicação (BARBOSA, 2001).
Também pode ser visto como uma ferramenta que libera os desenvolvedores de se envolver
com detalhes de cada fonte (LINTHICUM, 1997), sendo uma camada que existe entre
a aplicação cliente e as complexidades da rede, do sistema operacional e dos possíveis
servidores de recursos, em particular os servidores de dados (Figura 1).
Um middleware deve possuir interfaces padronizadas e protocolos de comunicação
para possibilitar a distribuição, portabilidade e interoperabilidade entre aplicações. A
descrição de uma interface é composta pelas assinaturas completas das operações (métodos) oferecidas, incluindo o nome, tipo do valor de retorno, tipos dos parâmetros e
exceções.
O objetivo de um middleware para integração de dados é fornecer informação inte-
18
Figura 1: Camanda intermediária - Middleware.
grada sem a necessidade de se integrar as fontes de dados, ou seja, um mediador permite
a interoperação de informação, somente selecionando resultados derivados das fontes de
dados (KIM, 1995) (WIEDERHOLD, 1999). Ele permite o acesso e a recuperação de dados relevantes de múltiplas fontes heterogêneas, a abstração e a transformação dos dados
recuperados (homogeneização), a integração dos dados e o seu processamento para disponibilizar o resultado, liberando assim o seu usuário de enviar a consulta diretamente para
as fontes de dados, de conhecer detalhes e de interagir, individualmente, com elas.
Para viabilizar a integração de dados, torna-se necessário realizar a integração de
esquemas (RAHM; BERNSTEIN, 2001). O problema é que os esquemas dos diferentes
bancos de dados componentes podem estar expressos em diferentes modelos de dados.
Assim, torna-se necessário, inicialmente, transformar todos os esquemas para um mesmo
modelo de dados, denominado de Modelo de Dados Comum (MDC). No caso de sistemas
componentes não baseados em banco de dados, deverá existir um mecanismo que simule
a existência de um esquema (metadados) para permitir o processo de integração. O esquema conceitual de cada banco de dados componente é denominado de esquema local.
Este esquema, expresso no modelo de dados do sistema componente, deve ser transformado para o MDC para poder ser integrado. O esquema derivado desta transformação
é denominado de esquema de exportação. Um esquema global (ou federado ), descrito no
MDC, é então criado pela integração de múltiplos esquemas de exportação. Finalmente,
são denidos os esquemas externos (visões ) sobre o esquema global, para atender às necessidades de um grupo especíco de usuários ou de aplicações, ou ainda, por razões de
19
controle de acesso. Para efetuar a tradução entre modelos (esquema externo para esquema
local ) são utilizados os wrappers (W1, W2, W3 e Wn na Figura 2).
Figura 2: Middleware para Integração de Dados.
1.1.2
Wrappers
São programas que encapsulam fontes de dados e são usados para fazer a tradução
entre o modelo de dados comum, utilizado no sistema integrador, e o modelo de dados de
cada fonte. Por exemplo, para se integrar três fontes, sendo a primeira XML, a segunda
Relacional e a terceira Orientada a Objetos, assumindo o modelo global com sendo Relacional, deve-se primeiro converter de XML e OO para Relacional possibilitando realizar
a integração (Figura 3). Tal conversão é realizada pelos wrappers. Além disso, eles são
utilizados para prover a comunicação com as fontes de dados.
Segundo (OBJECT. . . , 1997) os wrappers podem ser classicados em classes, de acordo
com as suas funcionalidades:
• Genérica: refere-se às operações de acordo com o tipo de fonte de dados. Por
exemplo, conversões de consulta SQL3 para SQL;
20
Figura 3: Wrappers em um sistema integrador
• Fonte especíca: diz respeito às operações de acordo com o conteúdo da fonte de
dados. Por exemplo, operações sobre o esquema da fonte de dados;
• Estrutura de controle: corresponde ao modo em que as requisições e as respostas
são passadas. Por exemplo, uma fonte de dados pode ser traduzida por um wrapper
assíncrono que armazena respostas até que uma requisição seja efetuada;
• Relatórios de erros: wrappers podem retornar erros para quem o chamou, noticando
mensagens de erro gerada pela fonte de dados, como por exemplo: erro de conversão
para o formato desejado ou erro de uma operação de recuperação;
• Chamada para serviços externos: wrappers podem chamar serviços externos para
executar serviços mais complexos do que aqueles executados pelo wrapper. Um
exemplo seria o uso de uma máquina de ontologia externa para transformar semanticamente uma consulta antes de ser encaminhada para o wrapper da fonte.
Para realizar a seleção de wrappers, a ser usado pelo middleware, devem ser analisadas
quais as fontes de dados serão tratadas pelos mesmos, se elas estão bem documentadas,
quais são as suas funções, como foram construídas e as arquiteturas internas das fontes.
Além disso, é importante ter em mente o local no qual os wrappers irão executar. Assim,
os wrappers são de fundamental importância para os sistemas middleware de integração
de dados.
21
1.1.3 CoDIMS
O CoDIMS (Congurable Data Integration Middleware System ) (BARBOSA, 2001;
BARBOSA; PORTO; MELO, 2002; TREVISOL, 2004) é um middleware para integração
de dados que vem sendo desenvolvido pelo grupo de pesquisa em Banco de Dados da
Universidade Federal do Espírito Santo - UFES. Sua principal característica é o fato de
ser baseado na técnica de composição de frameworks, possibilitando, com isso, exibilidade e conguração, podendo ser adaptado para ser utilizado em diversos domínios de
aplicação que exigem diferentes tipos de serviços (BARBOSA, 2001). Flexível, no sentido
de que permite: integrar diferentes fontes de dados; utilizar diferentes técnicas de comunicação, tanto entre os componentes internos quanto com as fontes de dados; possibilitar
a utilização de diferentes modelos de dados internamente. Congurável, de forma que
o middleware pode ser congurado apenas com os componentes necessários para uma
aplicação especíca e que seja instanciado de acordo com os requisitos da aplicação e das
características das fontes de dados que se deseja integrar.
Figura 4: Uma possível conguração do CoDIMS (BARBOSA, 2001).
A Figura 4 mostra uma possível conguração do CoDIMS. Os componentes Controle, Gerência de Metadados, Processamento de Consultas e Acesso aos Dados são os
componentes básicos, ou seja, aqueles que devem existir em todas as congurações. Já
os componentes Gerência de Regras, Gerência de Transação, Controle de Concorrência
poderiam não estar presentes, dependendo do domínio da aplicação para o qual está sendo
gerado o sistema. Já aplicações mais complexas, como por exemplo aquelas que tratam
dados no formato de multimídia, podem requisitar novas funcionalidades, que devem ser
incorporadas quando do processo de conguração, através da inclusão de novos compo-
22
nentes.
Na Figura 5, é mostrada uma conguração do CoDIMS com seus componentes básicos,
assim como as possíveis interações entre os mesmos. O componente Controle é a essência
do ambiente CoDIMS, pelo fato de disponibilizar os mecanismos que implementam as
congurações física e lógica. A conguração física diz respeito à seleção e ao registro dos
componentes que farão parte do sistema a ser congurado, incluindo os serviços oferecidos
e requisitados por cada um destes componentes. A conguração lógica é modelada através
de um mecanismo baseado no conceito de workow, sendo responsável por efetuar um
escalonamento dos serviços, ou seja, determinar a seqüência de execução dos serviços
oferecidos pelos componentes necessários para o processamento de um comando submetido
ao sistema congurado. O componente Gerência de Metadados é responsável por gerenciar
os esquemas envolvidos no processo de integração de dados. O componente Processamento
de Consulta analisa, re-escreve, otimiza e executa as consultas de usuário submetidas ao
sistema. Por m o componente Acesso aos Dados é responsável por, através dos wrappers,
traduzir e encaminhar as sub-consultas a serem executadas sobre as fontes de dados e
recuperar os resultados das mesmas. É importante ressaltar que, na versão atual do
CoDIMS, seus componentes são implementados como Web Services (TREVISOL, 2004).
Figura 5: O CoDIMS e seus componentes básicos.
Para o processo de conguração, customização e modelagem de uma instância do
CoDIMS, são necessárias as etapas de conguração física, conguração lógica e carga dos
metadados
1
de acordo com os requisitos de uma aplicação especíca. Um exemplo de
instância do framework CoDIMS é o CoDIMS-G (FONTES et al., 2004), que vem sendo
1 Para
uma descrição mais detalhada do processo de conguração consulte (BARBOSA, 2001).
23
desenvolvida no LNCC
2
com o objetivo de suportar aplicações de visualização cientícas
executando em um ambiente de Grid.
Congurada uma certa instância do CoDIMS, um usuário, através de uma aplicação
Web, submete sua consulta, que é repassada para a camada de Integração. Nesta camada, o componente Controle é responsável por receber a consulta e repassá-la para o
componente Processamento de Consultas. Este componente interpreta e analisa a consulta global recebida, produz as sub-consultas que serão submetidas a cada uma das fontes
de dados, gera um plano de execução global otimizado e procede a execução da consulta.
As sub-consultas geradas são encaminhadas para o componente Acesso aos Dados que,
por sua vez, as repassa para os wrappers. Estes exercem papel de tradução entre modelos e comunicação com as fontes, ou seja, recebem do componente Acesso aos Dados
uma sub-consulta no MDC do CoDIMS, convertem-na para o modelo da respectiva fonte,
interagem com a fonte gerando o resultado da sub-consulta, convertem o resultado para
o MDC e o enviam para o componente Acesso aos Dados, que repassa o mesmo para o
componente Processamento de Consulta para que seja feita a composição do resultado
nal, a partir dos resultados das diversas sub-consultas.
No processo atual de desenvolvimento do CoDIMS, estão sendo avaliadas e incorporadas técnicas recentes ou difundidas, objetivando, por exemplo, aprimorar a execução das
sub-consultas pelos wrappers.
1.2 Motivação do Trabalho
A integração de dados heterogêneos e distribuídos tem recebido grande atenção da
comunidade de pesquisa em banco de dados. Na literatura, diversos sistemas e propostas
são encontrados, focando em tal problema. O número considerável de soluções pode,
erroneamente, indicar um problema já resolvido. Pelo contrário, é um tópico importante,
com diversas questões em aberto, o que pode ser observado por publicações recentes
(ZIEGLER; DITTRICH, 2004).
Uma das questões é: como incrementar o desempenho dos sistemas de integração?
Para isso, é importante tirar vantagem dos recursos disponíveis, distribuídos no ambiente.
Isso pode ser feito pela distribuição das funcionalidades do sistema, tais como processamento de consultas e execução de wrappers. Para tanto, é importante que sejam avaliadas, dentre as abordagens de computação distribuída, aquelas que permitam uma melhor
2 Laboratório
Nacional de Computação Cientíca - http://www.lncc.br/frame.html
24
utilização dos recursos disponíveis, possibilitando a distribuição de funcionalidades e, conseqüentemente, a execução paralela de tarefas. Por sua vez, um ambiente computacional
de Grid (FOSTER et al., 2002; FOSTER, 2002) é aquele no qual aplicações podem utilizar,
de forma segura, coordenada, efetiva e transparente, recursos computacionais múltiplos
que podem estar dispersos geogracamente. Considerando que o ambiente de integração
de dados é essencialmente distribuído, e que as execuções dos wrappers são independentes
entre si, o uso da tecnologia de Grid mostra-se como uma boa opção. No que diz respeito
aos bancos de dados, têm sido propostos padrões para o desenvolvimento de serviços Grid
de banco de dados, com foco principalmente em prover acesso consistente a bancos de
dados existentes e autônomos (GRIDFORUM, 2004).
Na versão atual do CoDIMS, os wrappers estão implementados internamente no componente Acesso aos Dados, e executando em um mesmo servidor. Isso acarreta sobrecarga
desse servidor, quando os conjuntos-resultado provenientes das sub-consultas, executadas
nas fontes de dados, começam a crescer. Isso porque existe uma concorrência pelos recursos de uma única máquina, gerando lentidão na sua execução e, conseqüentemente, no
sistema integrador como um todo.
Dessa forma, no caso dos wrappers, torna-se interessante que os mesmos possam ser
executados em máquinas distribuídas, para:
• reduzir a carga do servidor Acesso aos Dados;
• serem executados em paralelo;
• permitir executar, em paralelo, as sub-consultas a serem encaminhadas a cada fonte
de dados;
• permitir armazenar o conjunto resultado proveniente da execução de cada subconsulta em um ambiente distribuído, permitindo o uso de transações distribuídas
(ÖZSU; VALDURIEZ, 2001) durante a execução do Plano de Execução de Consultas
(PEC).
Assim, os sistemas de integração de dados, tal como o CoDIMS, podem se beneciar
de um ambiente de Grid para obter um melhor desempenho, pela alocação de wrappers
em nós de Grid para que os mesmos possam ser executados em paralelo.
25
1.3 Objetivo
O objetivo principal deste trabalho é incorporar ao CoDIMS uma sistemática de distribuição e execução de wrappers em um ambiente distribuído, de forma que se possa
utilizar de uma maneira consistente, transparente e segura múltiplos recursos computacionais distribuídos, visando com isso um melhor desempenho do sistema como um todo e
uma redução do tempo de resposta na execução das consultas.
1.4 Contribuições Esperadas
Este trabalho apresenta uma proposta para estender o CoDIMS com um mecanismo
de distribuição, alocação e execução de seus wrappers em um ambiente de Grid, através da incorporação de uma nova camada denominada Wrapper-Grid. A partir desta
abordagem, espera-se os seguintes resultados: execução em paralelo das sub-consultas a
serem encaminhadas a cada fonte de dados; execução em paralelo dos wrappers, através
da alocação destes em um ambiente distribuído, mais precisamente alocação de instâncias
Wrapper-Services em nós de um Grid; disponibilização dos conjuntos resultados oriundos
das fontes de dados em um ambiente distribuído, proporcionando a execução distribuída
do PEC, objetivando um melhor desempenho; especicação e incorporação da camada de
Wrapper -Grid e do seus componentes (Componentes Wrappers -Grid); redução da carga
do servidor Acesso aos Dados; criação de uma infra-estrutura de Grid; implementação
de um protótipo com relação ao estudo de caso; implementação de uma la para troca
de mensagens entre os componentes Processamento de Consultas (MEC) e o componente
Acesso aos Dados, permitindo a execução assíncrona e distribuída do PEC.
1.5 Metodologia de Trabalho
Para a realização deste trabalho foi necessário um estudo profundo sobre o tema de
integração de dados heterogêneos e distribuídos, e sobre os trabalhos mais diretamente
relacionados, vericando seus pontos positivos e deciências. Além disso, foram analisadas as algumas tecnologias de computação distribuída levando em consideração as suas
vantagens e desvantagens, objetivando com isso escolher a mais adequada para ser usada
neste trabalho. Após este passo, foi criada uma infra-estrutura de Grid com a nalidade
de suportar a distribuição das funcionalidades do CoDIMS e criados serviços Grid que
encapsulam as funcionalidades dos wrappers. Foram estudados alguns padrões de pro-
26
jeto para a implementação de um mecanismo de noticação assíncrono através de las
de mensagens para a execução de sub-consultas. Foi elaborada a especicação funcional,
a respectiva modelagem em UML (Unied Modeling Language ) e a implementação do
presente trabalho. Por m, foram denidas estratégias para a execução de testes com o
objetivo de vericar a eciência da sistemática proposta.
1.6 Organização da Dissertação
O restante deste trabalho é organizado nos seguitnes capítulos:
• No capítulo 2, são apresentados e discutidos alguns trabalhos existentes na literatura
sobre a integração de dados heterogêneos e distribuídos, relacionados com o presente
trabalho;
• No capítulo 3, são apresentados alguns conceitos e tecnologias estudadas para a
realização deste trabalho, tais como: Computação distribuída, Cluster, Grid, Servico
Web, Serviço Grid, OGSA, OGSI, Globus Toolkit ;
• No capítulo 4, é apresentada a especicação funcional deste trabalho, descrevendo
a arquitetura do CoDIMS em ambiente de Grid; a camada de Wrapper - Grid e seus
componentes; e o seu funcionamento;
• No capítulo 5, é apresentada a modelagem UML do trabalho, bem como a descrição
das principais classes;
• No capítulo 6, é apresentado um estudo de caso;
• No capítulo 7, é apresentada uma síntese do trabalho realizado, suas principais
contribuições e a indicação de alguns trabalhos futuros para a continuidade desta
pesquisa.
Por m, são listadas as referências utilizadas.
27
2
Trabalhos Relacionados
2.1 Introdução
Na literatura da área, são encontrados diversos sistemas e propostas tentando resolver
o problema de integração de dados. Dentre eles e mais diretamente relacionados à proposta do presente trabalho, ou seja, que buscam distribuir funcionalidades, encontram-se:
CoDIMS-G (PORTO et al., 2004; FONTES et al., 2004; SILVA et al., 2004), OGSA-DAI
(ATKINSON; BAXTER; HONG, 2002; OPEN. . . , 2004a), OGSA-DQP (ALPDEMIR et al.,
2003a; OPEN. . . , 2004b), MOCHA (MIDDLEWARE. . . , 2000; RODRIGUEZ-MARTINEZ;
ROUSSOPOULOS, 2000; RODRIGUEZ-MARTINEZ et al., 2000; MART; ROUSSOPOULOS,
2000) e SkyQuery (MALIK et al., 2003). A seguir, os mesmos serão descritos em maiores
detalhes.
2.2 CoDIMS-G
O CoDIMS-G (PORTO et al., 2004; FONTES et al., 2004; SILVA et al., 2004) é um
sistema de integração de dados e programas gerado a partir de uma conguração do CoDIMS (BARBOSA; PORTO; MELO, 2002; BARBOSA, 2001), que vem sendo desenvolvido
no LNCC. Também pode ser visto como um serviço de integração de dados e programas
para Grid, o qual fornece para os usuários um acesso transparente para dados e programas
distribuídos no Grid, assim como gerenciamento e alocação de recursos dinâmicos. Nele
também é proposto um novo algoritmo de escalonamento de nós e projetada uma máquina
de consulta distribuída adaptativa para o ambiente de Grid. Assim, no CoDIMS-G, os
usuários podem expressar consultas que combinam processamento distribuído de dados
com a invocação de programas sobre os mesmos.
A arquitetura do CoDIMS-G pode ser observada na Figura 6. Nela, o componente
Controle (Control ) armazena, gerencia, valida e verica uma instância de conguração.
O Controle orquestra a comunicação entre os componentes. Usuários acessam o serviço
28
Figura 6: Arquitetura do CoDIMS-G (FONTES et al., 2004).
através uma aplicação Web. A requisição de um usuário é encaminhada para o componente Controle, que a envia para o componente Analisador (Parser ). Este transforma
a requisição do usuário em uma representação de grafo de consulta. O Otimizador de
Consulta (Query Optimizer - QO) recebe o grafo e gera um plano de execução de consulta distribuído (DQEP), usando um modelo de custo baseado em estatísticas de dados e
programas armazenadas no Gerenciador de Metadados (Metadata Manager - MM). Para
DQEPs que incluem operações para a avaliação de programas de uso paralelo, o otimizador chama o componente Escalonador (Scheduler - SC). Este último acessa o MM para
capturar o histórico de desempenho de execução de nós do Grid e custos de avaliação de
programas de usuário, além de estatísticas dos resultados intermediários. Baseado nas
estatísticas coletadas, o SC aplica um algoritmo de escalonamento de nós do Grid para
encontrar um sub-conjunto de nós a serem alocados pelo gerenciador da máquina de execução (Query Engine Manager - QEM), onde serão executados os programas do usuário.
O QEM é responsável por implantar os serviços da máquina de execução de consulta (QE)
nos nós especicados no DQEP, e gerenciar os seus ciclos de vida durante a execução da
consulta. O QEM gerencia o desempenho, em tempo real, dos QEs por consultar as estatísticas de vazão de dados e decidir por realocação, em tempo de execução, das QEs
com um plano re-otimizado. Os QEs são implementados como instâncias do framework
de execução de consulta (AYRES; PORTO; MELO, ). Cada QE recebe um fragmento de
um DQEP completo, e é responsável pela instanciação dos operadores e pelo controle de
execução, incluindo a comunicação com outros fragmentos para recuperação das tuplas.
Como parte do DQEP, o operador scan acessa as fontes de dados com wrappers, que
preparam os dados de acordo com o formato de dados comum.
O CoDIMS-G está voltado para o desenvolvimento de soluções para problemas de
29
aplicações cientícas, tal como o desenvolvimento de um serviço para suportar um estágio
de processamento de aplicações de visualização cientíca que simulam um uxo de uído
através de um caminho (PORTO et al., 2004). Nesse sentido, o CoDIMS-G usa o ambiente
de Grid para a execução em paralelo de programas sobre uma grande base de dados, não
tendo o objetivo de ser uma extensão do CoDIMS de forma a adaptá-lo, de maneira mais
geral, ao ambiente de Grid para efetuar integração de dados essencialmente heterogêneos
e distribuídos.
2.3 OGSA-DAI
O projeto OGSA-DAI (Open Grid Service Architecture Data Access and Integration )
(ATKINSON; BAXTER; HONG, 2002; OPEN. . . , 2004a) visa construir um middleware
para ajudar no acesso e integração de dados a partir de fontes de dados via Grid. Ele
permite a representação de banco de dados como serviços Grid, que são então acessíveis a
partir de outras máquinas de uma maneira segura e transparente. Com isso o OGSA-DAI
possibilita expor as fontes de dados para o mundo, baseando-se na abordagem de serviços
Grid, tendo como base o middleware Globus Tookit (GLOBUS, 2004). A gura 7 ilustra
a arquitetura de serviço do OGSA-DAI.
Figura 7: Arquitetura de Serviço do OGSA-DAI (OPEN. . . , 2004a).
Três principais tipos de serviços (Figura 8) são denidos para descoberta e acesso
a recursos: Data Access and Integration Service Group Registry (DAISGR), Grid Data
Services Factories (GDSF) e o Grid Data Services (GDS). O DAISGR é um serviço persistente que fornece a informação necessária para clientes descobrirem serviços e recursos
dinamicamente. O DAISGR lista as GDSFs que fornecem um método persistente para a
criação de GDSs. A gura 8 representa este procedimento.
O GDS fornece uma representação transiente e statefull de alguns recursos de dados
30
Figura 8: Serviços OGSA-DAI (OPEN. . . , 2004a).
ou serviços, sob os quais um número de atividades pré-denidas podem ser executadas
(MUNRO, 2004). Ele representa um link primário para o banco de dado sendo acessado,
podendo ser usado para funções de acesso, integração e entrega de dados. Assim, uma
instância de GDS pode interagir com um banco de dados para criar, recuperar, atualizar ou
remover dados. O GDS é a contribuição central do OGSA-DAI (ALPDEMIR et al., 2003b).
O cliente interage com o GDS por enviar um documento escrito em XML, chamado de
Perform. Este documento contém descrições de uma ou mais atividades que o GDS deverá
executar. A Figura 9 ilustra o framework básico do OGSA-DAI para a interação com
um cliente.
Figura 9: Framework OGSA-DAI: Interação cliente - OGSA-DAI(QI, 2004).
Apesar do OGSA-DAI ser uma implementação de referência sobre acesso e integração
de dados do Global Grid Forum (GLOBAL. . . , 2004), neste trabalho não é feito o uso do
mesmo pois, não foram encontradas as funcionalidades de tradução de modelos, mapeamentos e conversões. Segundo (ATKINSON, 2004), muitos desaos importantes ainda
permanecem em aberto OGSA-DAI, como, por exemplo: adaptação automática de esquemas e transformação nos dados em resposta à mudanças nas fontes; otimização integrada
de computação, gerenciamento e movimentação de dados; apresentação em alto nível de
transformação, composição, análise de dados e operações.
31
2.4 OGSA-DQP
OGSA-DQP (Open Grid Service Architecture - Distributed Query Processor ) (ALPDEMIR et al., 2003a; OPEN. . . , 2004b) é um framework de integração de dados e orquestração
de serviços no qual é possível fazer a coordenação e a incorporação de serviços Web para
efetuar análise e recuperação de dados (ALPDEMIR et al., 2003a).
Figura 10: Camada arquitetural do OGSA-DQP (ALPDEMIR et al., 2003a).
Como pode ser observado na Figura 10, o OGSA-DQP usa os serviços oferecidos
pelo framework OGSA-DAI para acessar, de forma homogênea, as fontes de dados, potencialmente heterogênas. Em um nível menor, temos a camada GT3, que é usada tanto
pelo OGSA-DAI quanto pelo OGSA-DQP para criação de instâncias, acesso do estado
e gerenciamento do tempo de vida das instâncias de serviços. A Figura 11 mostra a
interação entre os frameworks OGSA-DQP e OGSA-DAI.
No OGSA-DQP, instâncias de serviço de execução de consulta são implantadas em nós
de Grid para implementar paralelismo de programas de usuário. Operadores algébricos,
tais como exchange e operation-call, implementam comunicação entre nós e invocação de
programas de usuário, respectivamente.
Para cumprir com as suas funções, OGSA-DQP fornece dois serviços: O Grid Dis-
tributed Query Service (GDQS) e o Grid Query Evaluation Service (GQES). O GDQS é
construído sobre o Polar* (SMITH et al., 2002), encapsulando as funcionalidades de compilação e otimização. O GDQS fornece uma interface primária para o usuário e atua como
um coordenador entre a máquina de otimização/compilação de consultas e as instâncias
GQES. O GQES, por outro lado, é usado para avaliar um sub-plano de consulta associado
a ele pelo GDQS. O número de instâncias GQES e sua localização no Grid é especicado
pelo GDQS baseado nas decisões tomadas pelo otimizador, e representado como um escalonamento para partições de consulta (sub-planos). As instâncias GDES são criadas e
32
Figura 11: Interação entre os frameworks OGSA-DQP e OGSA-DAI (OPEN. . . , 2004b).
escalonadas dinamicamente e suas interações coordenadas pelo GDQS.
Um cliente, assim como no OGSA-DAI, pode submeter uma consulta embutida dentro de um documento XML chamado Perform. Essa consulta é compilada e otimizada
dentro de um plano de execução de consulta, cujas partições são escalonadas para serem
executadas em diferentes instâncias GQES. O GDQS usa esta informação para criar instâncias GQES em seus nós de execução, e dispacha os sub-planos para serem executados
em seus respectivos GQES. GQES podem interagir com outras instâncias GDS para obter
dados. Os resultados se propagam através das instâncias GQES até alcançarem o cliente.
Esta visão geral das interações durante uma execução de consulta poder ser observada na
Figura 12.
Assim como o OGSA-DAI, o OGSA-DQP possui algumas restrições que devem ser
explicadas. Dentre elas estão as que foram herdadas do próprio OGSA-DAI, já que o
mesmo é utilizado pelo OGSA-DQP, e outras pertencentes somente ao OGSA-DQP. Uma
delas está relacionada com a obtenção dos esquemas das fontes de dados, pois nenhuma
integração de esquemas e resolução de conitos é suportada durante a importação dos
esquemas. Os esquemas importados são simplesmente acumulados e mantidos localmente.
Isso pode ocasionar diculdades ao usuário nal, pois ele terá que integrar, de maneira
manual, os esquemas e resolver conitos semânticos e/ou estruturais entre os mesmos. Um
outra restrição diz respeito ao plano de execução de consulta gerado pelo OGSA-DQP, o
33
Figura 12: Interações durante uma execução de consulta no OGSA-DQP (ALPDEMIR et
al., 2003a).
qual é estático. Além disso, existe a possibilidade de um ou mais nós alocados para este
plano estático carem sobrecarregados, ou a fonte com a qual eles se comunicam não estar
mais respondendo. Neste sentido, no OGSA-DQP, não é possível fazer uma análise, em
tempo de execução, dos nós alocados no Grid para que, se necessário, seja feita a geração
de um novo plano e a realocação dos seus operadores.
2.5 MOCHA
MOCHA (Middleware Based On a Code SHipping Architecture ) (MIDDLEWARE. . . ,
2000) é um sistema middleware projetado para interconectar fontes de dados distribuídas sobre uma grande área de rede (RODRIGUEZ-MARTINEZ et al., 2000). MOCHA é
construído baseado na noção de que um middlware, para um ambiente distribuído, deve
ser auto-extensível (RODRIGUEZ-MARTINEZ; ROUSSOPOULOS, 2000). Isso signica que
novos tipos de dados e operadores especícos de uma aplicação, necessários para o processamento de uma consulta, são implantados em sites remotos de uma maneira automática
pelo sistema middleware. No MOCHA, isto é realizado através do envio de classes Java,
implementando estes tipos ou operadores, para o site remoto, onde eles podem ser usados
para manipular dados de seu interesse. Todas as classes Java são primeiro armazenadas
em um ou mais repositórios de dados, a partir do qual são posteriormente recuperados e implantados de acordo com suas necessidades. O objetivo principal da idéia de
34
implantação automática de código é suprir a necessidade por componentes de processamento especícos da aplicação em sites remotos que não os fornecem. Assim, MOCHA
capitaliza-se em sua habilidade de implantação de código automática para fornecer um
serviço de processamento de consulta eciente. Pelo fato de enviar código de operadores
de consulta, MOCHA pode produzir planos ecientes que colocam poderosos operadores
de redução de dados (ltros) para executarem nas fontes de dados, diminuindo com isso
o tráfego que dados entre o site e o sistema.
A motivação do MOCHA é que os dados armazenados em diversos sites são baseados
em tipos de dados complexos, e que a Web tem se tornado, de fato, uma interface de usuário para aplicações em rede. Assim, os usuários necessitam de uma solução que permita,
facilmente, integrar os clientes baseados em Web e visualizar os dados disponibilizados
pelos mesmos.
Figura 13: Arquitetura do MOCHA(RODRIGUEZ-MARTINEZ; ROUSSOPOULOS, 2000).
A arquitetura do MOCHA, mostrada na Figura 13, é composta de quatro componentes principais: Aplicação Cliente - um applet, um servlet ou uma aplicação Java usada
para submeter consultas ao sistema; Coordenador de Processamento de Consultas (QPC)
- fornece serviços tais como análise de consulta, otimização de consulta, escalonamento
de operador de consulta, gerenciamento de catálogo e execução de consulta, além de ser
o responsável por implantar todas as funcionalidades necessárias para o cliente e para
os sites remotos, a partir dos quais os dados serão extraídos; Fornecedor de Acesso aos
Dados (DAP) - fornece ao QPC um mecanismo de acesso uniforme para uma fonte de
dados remota, e executa alguns dos operadores na consulta (aqueles que ltram os dados
sendo acessados); e o Servidor de Dados - armazena um conjunto de dados de um site em
35
particular. A comunicação entre os seus componentes, Figura 14, é feita usando RMI
(Remote Method Invocation ).
Figura 14: Arquitetura do MOCHA - RMI.
No MOCHA, pode-se enxergar os DAPs como sendo wrappers. Os mesmos têm capacidade de processamento de consulta, podendo utilizar tipos de dados e operadores
especícos de uma aplicação, necessários para o processamento de uma consulta, os quais
são implantados nos DAPs de uma maneira automática pelo sistema middleware. Para
cada tipo de fonte existe um DAP especíco. Nesse sentido um DAP só pode acessar a
sua fonte. Além disso, os DAPs são previamente instalados em máquinas, podendo ser
no próprio site remoto ou próximo a ele, nos quais irão executar. Como as máquinas nas
quais os DAPs estão instalados podem car sobrecarregadas e um DAP não pode acessar
outras fontes diferentes daquela a qual está associado, o sistema integrador pode ter sua
execução afetada, dado que o QPC pode car parado esperando os dados proveniente de
um DAP que está com o processamento lento ou até mesmo parado. Além disso, os DAPS
não possuem a funcionalidade de tradução entre modelos.
2.6 SkyQuery
SkyQuery (MALIK et al., 2003) é um middleware que busca criar uma federação de
bancos de dados na área de astronomia que estão separados geogracamente. Ele possui
uma interface Web que permite aos astrômonos efetuarem consultas sobre dados espaciais
armazenados em bancos de dados participantes da federação. Web Services são implantados em cada banco de dados, sendo a principal interface de comunicação e encapsulamento
tanto para o processador de consulta quanto para o tradutor de fontes de dados.
36
Figura 15: Arquitetura do SkyQuery (MALIK et al., 2003).
A sua arquitetura (Figura 15) é baseada em wrapper-mediator, sendo implementada
através de Web Services. Esta possui três componentes principais, que são: os Clientes,
o Portal e os SkyNodes. O Portal é o mediador e os SkyNodes contém os wrappers que
encapsulam os bancos de dados. Os Clientes são interfaces Web que aceitam consultas
de usuários e repassam para o Portal. O Portal faz a mediação entre os Clientes e os
SkyNodes. Isso é feito por aceitar as consultas dos usuários e coordenar os SkyNodes com
o intuito de avaliá-las. Cada SkyNode implementa serviços que atuam como wrappers,
encapsulando os SGBDs (Sistemas Gerenciadores de Banco de Dados) e outros detalhes
especícos da plataforma na qual eles estão executando.
Em cada SkyNode existem APIs (Applications Programs Interfaces ) que são especícas para cada banco de dados que o mesmo manipula, sendo utilizadas para fornecer
acesso aos dados e metadados do banco de dados associado ao SkyNode. Assim, um SkyNode apresenta uma visão uniforme para o Portal. Contudo, pelo fato de cada SkyNode
encapsular um banco de dados distinto, não é possível que um SkyNode faça o acesso
a outro banco de dados senão aquele ao qual está associado. Ele também não possui a
funcionalidade de tradução de modelos. Além disso e, tal com o CoDIMS-G, o SkyQuery
é um middleware para uma aplicação especíca, no caso, para a integração de dados astronômicos. O mesmo não está voltado para a integração de dados em um contexto mais
geral.
O MOCHA e o Skyquery, utilizam uma abordagem de distribuição de wrappers baseada, respectivamente, no uso de RMI (Remote Method Invocation ) e de Web Services.
RMI apresenta alguns problemas com relação a tráfego sobre http e rewalls, além de cli-
37
A
B
C
D
E
F
G
H
CoDIMS-G
não
não
não
não
sim
não
Grid
não
Tabela 1: Comparação entre os sistemas.
OGSA-DAI/DPQ MOCHA
SkyQuery
sim
sim
sim
não
não
não
não
não
sim
restrita
restrita
restrita
não
não
não
não
sim
não
Grid
RMI
Web Service
sim
sim
sim
CoDIMS
não
sim
não
sim
sim
não
Grid
sim
ente e servidor serem fortemente acoplados e terem que ser desenvolvidos em Java. O uso
de Web Services resolve esse problema. Estes, entretanto, não são muito versáteis, pelo
fato de não oferecerem suporte para serviços de persistência, noticação, gerenciamento
de ciclo de vida, transações, recursos etc.
Para facilitar o entendimento, na tabela 1, é feito uma comparação das funcionalidades dos sistemas apresentados. Por questão de espaço foi utilizada a seguinte legenda: AMonolítico, B- Integração de esquema e Resolução de conitos, C- Aplicação Especíca,
D- Funcionalidades de Wrappers, E- Realocação de instância de serviço, F- Problema com
Firewall, G- Tecnologia de computação distribuída, H- Integração de Dados.
De forma diferente dos trabalhos descritos neste capítulo, o CoDIMS apresenta-se
como um sistema integrador completo, provendo facilidades de resolução de conitos
através de integração de esquemas, com conseqüente elaboração de um esquema global.
Além disso, os wrappers são implementados através da utilização de Grid Services, que
podem ser vistos como uma evolução de Web Services, o que permite adicionar ao CoDIMS
uma sistemática para a alocação e execução de wrappers em nós de Grid. Isso possibilita
a execução distribuída e paralela do Plano de Execução de Consultas (PEC), tornando
possível um melhor desempenho do sistema como um todo.
Além dos sistemas explicados anteriormente, existem na literatura diversos outros
para integração de dados. Contudo, estes sistemas não possuem as características de
exibilidade e conguração apresentadas no CoDIMS (BARBOSA, 2001), nem uma distribuição dos wrappers . Um estudo sobre os mesmos pode ser encontrado em (SILVESTRE;
BIANCARDI; BARBOSA, 2004).
38
3
Conceitos e Tecnologias
3.1 GRID
Um é Grid uma infra-estrutura de hardware e software que permite acesso a capacidades computacionais geogracamente distribuídas, de forma conável, consistente,
econômica e transparente. O conceito é relativamente antigo (meados da década de
90), contudo, vem sendo apresentado com uma nova dinâmica (FOSTER; KESSELMAN,
1997, 1999; FOSTER; KESSELMAN; TUECKE, 2001), em que se pode utilizar a capacidade
de computação dos recursos disponíveis a serem compartilhados (ex. armazenamento,
CPU) sem ter que se preocupar de onde vem e como é mantida, fazendo uma metáfora às
redes elétricas, nas quais um usuário utiliza a eletricidade sem ao menos saber na qual ela
foi gerada, sendo totalmente transparente aos seus usuários. Nesse sentido a tecnologia
de Grid visa fornecer o acesso compartilhado a recursos de computação, de uma maneira
a quem for utilizá-los não necessite de conhecer os detalhes dos componentes computacionais envolvidos, onde eles estão localizados, como gerenciá-los, como corrigir erros ou
mesmo como efetuar uma atualização. Dessa forma, a infra-estrutura Grid conecta diversos recursos de hardware, software e dados através de uma rede, fornecendo um acesso
exível e seguro para aplicações e dados (MALAIKA; EISENBERG; MELTON, 2003).
A tecnologia de Grid possibilita agregar recursos computacionais variados e dispersos
em um único supercomputador virtual, acelerando a execução de um variado tipo de
aplicações e diminuindo custos com o uso de recursos compartilhados. Em um Grid, os
serviços podem ser executados em diferentes nós com o objetivo de balancear a carga de
trabalho e aumentar o desempenho.
Grid visa suportar a demanda das organizações virtuais para um compartilhamento
coordenado de recursos e a resolução de problemas em escala global, tais como aquelas que necessitam de computação intensiva e que manipulam muitos dados (GOBLE;
ROURE, 2002). Um Organização Virtual (OV) (FOSTER; KESSELMAN; TUECKE, 2001)
pode ser vista como uma infra-estrutura que habilita o compartilhamento de recursos de
39
forma coordenada, transparente, segura e exível entre coleções dinâmicas de indivíduos
ou instituições, ou seja, chama-se de Organização Virtual quando existem participantes
que desejam compartilhar recursos para poder concluir uma tarefa. Além disso, o compartilhamento está além de apenas troca de documentos, podendo envolver acesso direto
a software remoto, computadores, dados, sensores dentre outros recursos.
De uma forma simples, um ambiente de Grid é aquele no qual as aplicações podem
utilizar múltiplos recursos computacionais que podem estar distribuídos geogracamente.
Mais recentemente, tem-se os recursos de dados, como por exemplo os bancos de dados.
Levando em consideração que cada nó de um Grid executa tarefas distintas, as aplicações mais adequadas ao Grid são as que possuem tarefas independentes, ou seja, tarefas
que não dependem da execução de outras e podem ser executadas em qualquer ordem e,
a princípio, em qualquer nó do Grid.
Da mesma maneira que a Internet, a computação em Grid teve seu desenvolvimento
nas comunidades acadêmica e de pesquisa. Entre os fatores que inuenciaram o seu
desenvolvimento, podem ser considerados importantes:
• o fato de pesquisas incluírem um grande número de pesquisadores e estes, geralmente, encontrarem-se em locais dispersos, notou-se a necessidade de criar um ambiente computacional para compartilhar recursos e resultados dinamicamente;
• a importância de escalonar serviços e dados facilmente, para poder acomodar uma
quantia cada vez maior de dados e poder computacional;
• redução de custos.
Esses requisitos são suportados pela arquitetura dos Grids, na qual é possível escalonar, de maneira dinâmica, os recursos computacionais. Além disso, um Grid pode englobar
máquinas localizadas em lugares diferentes, utilizando seus recursos ociosos. Com isso, é
possível utilizar hardware comum, não sendo necessário fazer a utilização de máquinas de
grande porte como supercomputadores.
3.1.1 Benefícios de um Grid
Com relação aos benefícios que o Grid pode trazer, pode-se citar, segundo (BERSTIS,
2003), os seguintes:
40
• Explorar recursos subutilizados e recursos adicionais: A princípio, uma aplicação
pode ser executada em qualquer máquina que faça parte de um Grid, desde que esta
possua acesso a determinados recursos solicitados pela aplicação. Pode-se escolher
esta máquina utilizando-se diversos parâmetros, como por exemplo: a que estiver
com menor carga de processamento, a que possuir disponível certo tipo de dispositivo
ou determinados dados.
Existem alguns tipos de aplicações que podem melhor utilizar as características
dos Grids. Um exemplo seria o de aplicações que exigem grande processamento de
dados e pouca interação com o usuário, podendo ser melhor escalonadas através do
Grid. Além dos recursos de processamento, muitas máquinas também possuem seus
discos rígidos subutilizados. Assim, o Grid pode ser utilizado como um Data Grid,
alocando o espaço disponível como se fosse um disco apenas. Outra forma de alocar
o espaço seria dividir os dados de forma que as aplicações possam ser executadas
em uma máquina mais próxima de onde se encontram os dados que processa, ou
para garantir uma maior disponibilidade caso alguma máquina falhe.
Diversos outros recursos podem ser compartilhados em um Grid. Para uma aplicação que demande um maior acesso à Internet, por exemplo, pode-se dividir o
trabalho entre outras máquinas que também possuam acesso à rede, acelerando os
resultados. Outros exemplos podem abranger uma impressora remota com maior
qualidade, um gravador de DVD ou equipamentos médicos e cientícos avançados
como um microscópio eletrônico ou um robô. Com isso, os recursos de uma instituição ou empresa podem ser melhor utilizados, diminuindo despesas e aumentando a
eciência e a competitividade.
• Capacidade de processamento paralelo: Outra característica interessante é a possibilidade de melhor utilizar o processamento paralelo através de Grids. Em alguns
tipos de aplicações tais como cientícas, nanceiras, processamento de imagens e simulações, a utilização de processamento paralelo pode trazer bastante ganhos com
relação ao desempenho. Uma aplicação que faça uso de algoritmos e técnicas de
programação paralela pode ser dividida em partes menores e estas podem ser separadas e processadas independentemente. Cada uma destas partes de código pode
ser executada em uma máquina distinta no Grid, melhorando o desempenho.
Existem algumas barreiras que podem impedir que uma aplicação utilize todo este
potencial. Por exemplo, se a aplicação deve ser dividida em um número xo de partes
independentes, isso torna-se uma barreira que impede sua escalabilidade. Outra
41
forma de problema encontrado é quando as partes não podem ser completamente
independentes e precisam comunicar-se entre si, causando uma possível espera para
que as comunicações sejam sincronizadas ou o tempo necessário para as mensagens
serem transmitidas. Essas características devem ser levadas em conta no momento
de se utilizar a funcionalidade de processamento paralelo, mas isso não impede a
grande utilização dos Grids como uma excelente arquitetura para o processamento
paralelo.
• Dispositivos e Organizações Virtuais: A colaboração entre os mais diversos tipos
de usuários e aplicações é outra capacidade que pode ser desenvolvida com o advento dos Grids. Recursos e máquinas podem ser agrupados e trabalharem juntos
formando o que pode ser chamado de uma Organização Virtual (OV).
Uma OV (FOSTER; KESSELMAN; TUECKE, 2001) é uma entidade que compartilha
recursos através do Grid, utilizando uma determinada política de compartilhamento.
Uma OV varia tremendamente em seus propósitos, escopo, tamanho, duração, estrutura, comunidade e sociologia. Pode ser denida de acordo com sua área de
pesquisa ou de negócio, juntando usuários e aplicações com propósitos semelhantes,
colaborando em prol de uma razão comum, como por exemplo: empresas, centros de
pesquisa e universidades. Esses recursos podem abranger processamento, dados, licenças, entre outros, e podem ser virtualizados para melhor interoperabilidade entre
os participantes do Grid.
• Conabilidade: Existem diversas maneiras de aumentar a conabilidade em um
sistema computacional. Processadores e discos são duplicados, de modo que caso
um falhe o outro assuma seu lugar, fontes de energia e circuitos redundantes, geradores elétricos, entre outros. Todas estas formas comprovadamente aumentam
a disponibilidade e a conança em um sistema, mas seus custos podem torná-las
impraticáveis. Utilizando-se uma abordagem baseada em Grids, com máquinas espalhadas em diversos lugares diferentes, quando uma falha atinge uma parte do Grid
as demais podem continuar sua operação normalmente. Sistemas de gerenciamento
podem executar novamente processos importantes caso seja detectada alguma falha ou estes podem ser executados redundantemente para garantir sua consistência.
Dados podem ser duplicados ou separados em diversas partes através do Grid, aumentando sua disponibilidade. Um grande avanço nessa área serão sistemas que
podem automaticamente detectar uma falha e tomar as medidas necessárias para
contornar o problema.
42
3.2 Grid vs Computação Distribuída
De uma maneira geral, computação distribuída é um conceito que vem dos anos 80
e 90, e consiste na possibilidade de resolver um determinado problema computacional
através da utilização de recursos distribuídos geogracamente, utilizando diferentes plataformas de hardware ou diferentes sistemas operacionais, podendo pertencer a diferentes
empresas ou instituições.
Grid é um caso particular da computação distribuída, uma vez que são orientados para
aplicações que precisam de uma grande capacidade de cálculos ou enormes quantidades
de dados transmitidos, ou ambas. Além disso, com a evolução da tecnologia de grids
percebeu-se que a composição automática de um conjunto de recursos para servir uma
aplicação criava a oportunidade de oferecer serviços sob demanda. Assim, surgiu a idéia
de um Grid onde seja possível prover sob demanda qualquer serviço computacional (não
somente serviços para computação de alto desempenho). O Grid, portanto, seria uma
rede na qual o individuo se conecta para obter serviços computacionais que agregam
recursos sob demanda (ex.: ciclos, armazenamento, software, periféricos, etc) (CIRNE;
NETO, 2005).
A computação distribuída passa a ser uma computação em Grid no momento em
que existe uma infra-estrutura de hardware e software que permita criar a ilusão de
um supercomputador virtual, em grande escala, facilmente gerenciável e com uma grande
quantidade de recursos (ciclos de CPU, dados, dispositivos de armazenamento etc.) sendo
compartilhados de forma conável, consistente, econômica e persistente, possibilitando,
com isso, coordenar os trabalhos a serem processados e garantir a qualidade de serviço
(BERSTIS, 2003).
Algumas tecnologias de computação distribuídas, tais como CORBA (Commom Ob-
ject Request Broker Arquitecture ) e EJB (Enterprise JavaBeans ), são voltadas para sistemas distribuídos altamente acoplados, nos quais cliente e servidor são muito dependentes
um do outro. Tecnologias de Grid se distinguem destas pelo fato de serem baseadas no
conceito de Grid Services, uma evolução de Web Services, o que implica em sistemas fracamente acoplados, nos quais um cliente pode não ter conhecimento do serviço até que
ele o invoque. Nesse sentido, sistemas distribuídos altamente acoplados são ideais para
aplicações intranet, enquanto que Grid são mais adequados para alcançar as demandas
de uma aplicação Internet (SOTOMAYOR, 2003).
43
3.3 Grid vs Cluster
Um ambiente de Cluster constitui um sistema formado por hardware e software conectados em um único local, usado exclusivamente para resolver os problemas computacionais
de uma determinada organização. Assim, em um Cluster, os recursos são gerenciados por
uma entidade central, e os computadores agem como se fossem um único dispositivo.
A principal diferença entre Grid e Cluster (BUYYA, 2002) está relacionada ao modo
como é feito o gerenciamento dos recursos, ou seja, se o compartilhamento de recursos é
gerenciado por um único sistema global, sincronizado e centralizado, então é um Cluster.
Em um Cluster, todos os nós trabalham cooperativamente em um objetivo comum, e a
alocação de recursos é executada por um gerente centralizado e global. Em um Grid, os
recursos estão distribuídos geogracamente, sendo que os donos desses recursos possuem
autonomia para fazer o gerenciamento local. A alocação dos recursos é feita pelos usuários
do Grid, e os nós executam diferentes tarefas relacionadas a objetivos distintos. Um Grid
pode ser encarado como sendo uma evolução do Cluster, dado que os recursos deste
podem ser compartilhados pelo Grid. Assim, um Grid é mais heterogêneo, complexo e
distribuído.
Com o intuito de esclarecer a denição de Grid, já que, constantemente se confude o
real signicado do que é Grid, Foster elaborou um Grid CheckList (FOSTER, 2002), no
qual são denidas três características básicas para que um sistema computacional possa
ser chamado de Grid:
• Recursos coordenados que não se sujeitam a um controle centralizado: Sistemas em
Grid podem englobar recursos entre os mais variados tipos, desde o desktop de um
usuário até um supercomputador. Pode haver um controle local em uma empresa,
mas não existe um controle central para todo o Grid;
• Utilizar padrões abertos, interfaces e protocolos de propósito geral: A utilização
de protocolos e padrões abertos é essencial para que os sistemas em Grid possam
realizar funções fundamentais como autenticação, autorização, descoberta de recursos e acesso a eles, sem perder a capacidade de escalar e interagir com diferentes
plataformas de hardware e software ;
• Prover o mínimo em qualidade de serviços: Sistemas em Grid permitem que os recursos sejam utilizados de forma coordenada com o objetivo de alcançar qualidades
de serviço como por exemplo - tempo de resposta, throughput (vazão), disponibi-
44
lidade, segurança e/ou a co-alocação de recursos para se adequar às exigências do
usuário. Assim, a utilidade de um sistema combinado é signicativamente maior
que a soma das partes.
3.3.1 Deciência
Uma deciência com relação à computação em Grid está relacionada a redes de computadores com baixa taxa de transmissão de dados. Isso constitui uma espécie de gargalo
com relação àquelas aplicações que necessitam transferir grandes quantidades de dados.
Assim, a multiplicidade das velocidades das diversa redes de computadores implica em alguns pontos de gargalo, o que acaba comprometendo o desempenho do supercomputador
virtual.
3.3.2 Componentes
3.3.2.1 Recursos
Um Grid pode ser visto como uma coleção de máquinas que compartilham diversos
tipos de recursos. Dentre os principais tipos de recursos, passíveis de compartilhamento,
pode-se destacar:
• Computação: Ciclos de CPU é o recurso mais comumente compartilhado em um
ambiente de Grid. Os processadores podem variar em velocidade, arquitetura, plataforma de software e ter outros fatores associados, tais como memória e armazenamento. Existem três formas de explorar os recursos computacionais em um Grid.
O primeiro é executar uma aplicação em qualquer máquina disponível do Grid,
independentemente de onde esteja localizada. A segunda é quebrar o aplicativo
em partes menores para que estas possam ser executadas paralelamente através do
Grid. E a terceira é executar uma tarefa que precisa rodar várias vezes em diferentes
máquinas do Grid.
Grids que utilizam principalmente os recursos computacionais disponíveis são comumente chamados de Grids computacionais.
• Armazenamento: A utilização do espaço de armazenamento de cada máquina integrante de um Grid aumenta a capacidade de armazenamento como um todo, além
de aumentar o desempenho, compartilhamento e conabilidade dos dados. A utilização desse espaço de armazenamento facilita a localização de determinado arquivo,
45
sendo que este pode estar dividido em partes menores e espalhado pelas máquinas
participantes, contornando problemas como tamanho máximo de arquivo em algum
sistema operacional. Sistemas de gerenciamento podem duplicar dados em várias
máquinas provendo uma redundância. Podem também utilizar essa informação no
momento de designar uma máquina para executar uma aplicação, escolhendo a que
estiver com os dados requisitados por esta.
Grids que utilizam o espaço de armazenamento como principal recurso compartilhado são comumente chamados de Data Grids.
• Comunicações: Através do Grid, pode-se compartilhar conexões, tanto internas
quanto externas. Contudo, a velocidade das comunicações pode inuenciar na execução de diversas tarefas. Algumas aplicações precisam processar um grande número de dados e estes podem não se encontrar na máquina (nó) onde será executada.
Neste caso, os dados devem ser enviados através do Grid, sendo que a velocidade
desta transmissão pode inuenciar no desempenho. Para tentar resolver este problema, máquinas com conexões ociosas podem ser utilizadas para enviar partes
destes dados, para não causar uma contenção.
Grids que utlizam a capacidade de comunicação como principal recurso compartilhado são comumente referenciados como Network Grids ou Delivery Grids.
• Software e licenças: Alguns softwares possuem licenças caras e seria impraticável
sua instalação em todas as máquinas do Grid. Assim, requisições para utilizar estes
softwares seriam direcionadas para as máquinas que os possuem instalados. Deste
modo, pode-se realizar uma melhor utilização das licenças adquiridas.
3.3.2.2 Descrição da Arquitetura de Grid
Em (FOSTER; KESSELMAN; TUECKE, 2001) é descrita a arquitetura de um Grid.
Contudo, não é feita uma enumeração completa de todos os protocolos requeridos, assim como serviços, APIs (Application Program Interface ) e SDKs (Software Development
Kits ). Somente são identicados os requerimentos para as classes de componentes. A arquitetura de um Grid é denida como uma pilha de protocolos, semelhante à arquitetura
de protocolos da Internet, como pode ser visto na Figura 16.
A seguir será feita uma breve descrição sobre cada camada.
• Fabric : Interfaces para controle local
46
Figura 16: Arquitetura de um Grid e seu relacionamento com a arquitetura de protocolo
da Internet (FOSTER; KESSELMAN; TUECKE, 2001).
Esta camada fornece funcionalidades com as quais o compartilhamento de recursos
pelo Grid torna-se possível. Implementa operações locais e especícas para cada tipo
de recurso compartilhado pelo Grid, fornecendo suporte às funções das camadas
superiores. Conceitualmente, os recursos precisam ter implementados no mínimo
dois mecanismos importantes para seu melhor aproveitamento no Grid. O primeiro
é um mecanismo chamado enquiry, que permite descobrir sua estrutura, estado e
capacidades. O segundo é um mecanismo de gerenciamento de recurso que busca
efetuar algum tipo de controle sobre a qualidade do serviço fornecido.
Para cada tipo de recurso passível de ser compartilhado através do Grid, a camada
Fabric implementa algumas funções especícas:
Recursos computacionais: mecanismos para iniciar programas e monitorar sua
execução são necessários. Além disso, é importante possibilitar gerenciamento
sobre os recursos alocados para determinada aplicação, e fornecer informações
sobre características de hardware, software e carga de processamento.
Recursos de armazenamento: basicamente são necessárias funções que permitam adicionar e retirar arquivos. Também é necessária a existência de mecanismos de gerenciamento que permitam controle sobre os recursos alocados para
a transferência de dados como espaço, taxa de transferência do disco e da rede,
CPU etc. Fornecer informações sobre as características de hardware, software,
espaço em disco disponível e taxa de transferência.
Recursos de rede: gerenciamento sobre os recursos alocados para transferências de rede, como por exemplo, a taxa de transferência. Também fornece
informações sobre as características da rede e sua carga.
47
• Connectivity : Comunicação fácil e segura
A camada Connectivity dene os protocolos de comunicação e de segurança necessários para transações de rede especícas de Grid, permitindo troca entre recursos da
camada Fabric. Fornece também protocolos de autenticação e serviços de segurança
criptografada para vericar a identidade de usuários e recursos.
As necessidades supridas pela camada incluem transporte, roteamento e nomeação.
Atualmente, estes protocolos são mapeados para a pilha de protocolos TCP/IP:
especicamente Internet (IP e ICMP), transporte (TCP e UDP) e aplicação (DNS,
OSPF). As soluções de autenticação para as Organizações Virtuais devem possuir
no mínimo algumas características básicas, são elas:
Single sign on : os usuários devem se autenticar uma só vez e ter acesso a
múltiplos recursos denidos pela camada Fabric, não necessitando se autenticar
em cada um deles.
Delegação: um programa executado por um usuário tem acesso aos mesmos
recursos que este usuário está autorizado a utilizar. E, um programa pode,
opcionalmente delegar alguns direitos a outros programas em execução.
Integração com sistemas de segurança locais: cada recurso pode implementar
soluções de segurança localmente, tal como Unix security. As soluções de
segurança do Grid devem ser capazes de interoperar com estes sistemas.
• Resource : Compartilhando recursos simples
A camada Resource utiliza as funcionalidades da camada Connectivity para a negociação segura, monitoramento, controle e contabilização de operações de compartilhamento em recursos individuais. Utiliza também a camada Fabric para acessar e
controlar dispositivos locais.
Existem apenas dois tipos de protocolos que são denidos por esta camada:
Protocolos de informação: usados para obter informações sobre a estrutura e
o estado dos recursos, como conguração, carga de trabalho atual e política de
uso.
Protocolos de gerenciamento: usados para negociar acesso a um recurso compartilhado, como por exemplo, os requisitos do recurso e as operações necessárias para a criação de um processo ou acesso a um dado. Podem também
monitorar o estado de uma operação e ter controle sobre ela.
48
• Collective : Coordenando múltiplos recursos
Diferentemente da camada Resource, que interage com um recurso simples, a camada Collective fornece protocolos e serviços que não estão associados a um recurso
especíco e sim a coleções destes. Para isto, ela disponibiliza algumas facilidades de
compartilhamento:
Serviços de diretório: facilita aos integrantes de Organizações Virtuais descobrir a existência e propriedades de recursos compartilhados. Estes recursos
podem ser localizados por nome e outros atributos como tipo, disponibilidade
e carga.
Serviços de co-alocação e agendamento: permitem que recursos possam ser
alocados para determinado propósito e o agendamento de tarefas em recursos
apropriados.
Serviços de monitoramento e diagnóstico: recursos podem ser monitorados em
relação a falhas, utilização indevida e sobrecarga, por exemplo.
Serviços de replicação de dados: suporte a gerenciamento dos recursos de armazenamento para maximizar a performance de acesso a dados. Pode-se monitorar tempo de resposta, conabilidade e custos.
Sistemas de programação compatíveis com Grids: habilita a utilização de modelos de programação conhecidos no ambiente de Grids, usando serviços como
busca e alocação de recursos, segurança etc. Um exemplo seria a implementação de Message Passing Interface (MPI) no ambiente de Grid.
Alguns componentes desta camada podem ser especícos para determinada Organização Virtual ou domínio de aplicações. Por exemplo, um protocolo para alocação
de um tipo especíco de dispositivos de rede que esta organização possui. Outros
componentes podem ser mais generalizados, como um serviço de replicação que gerencia uma coleção internacional de dispositivos de armazenamento para diversas
Organizações Virtuais. De qualquer forma, o importante é que os protocolos e in-
terfaces de programação sejam baseados em padrões abertos para evitar problemas
de integração.
• Applications :
A camada nal da arquitetura de um Grid compreende as aplicações de usuário que
operam dentro de um ambiente de Grid. A Figura 17 demonstra a arquitetura
de Grid pelo ponto de vista de um programador de aplicações. As aplicações são
49
construídas através da utilização de serviços providos por cada camada. Em cada
uma destas, existem protocolos denidos que fornecem serviços como gerenciamento
e localização de recursos, acesso a dados, entre outros.
Figura 17: Arquitetura de um Grid na visão dos programadores de aplicações (FOSTER;
KESSELMAN; TUECKE, 2001).
3.3.3 Ferramentas de Desenvolvimento
Existem algumas ferramentas disponíveis que habilitam o desenvolvimento de aplicativos que fazem uso da arquitetura de Grids. Dentre elas, a que tem alcançado grande
popularidade, principalmente por ser desenvolvida a partir de padrões abertos e mantida
por comunidades de programadores, é o Globus Toolkit (GLOBUS, 2004).
3.3.3.1 Globus Toolkit
O Globus Toolkit é um conjunto de ferramentas e bibliotecas de software que dão
suporte à arquitetura e às aplicações em Grid. É um projeto desenvolvido pelo Argnone
National Laboratory (ANL) e pela University of Southern California. É mantido por
uma comunidade de programadores, The Globus Alliance (GLOBUS, 2004), e é baseada
em arquiteturas e códigos abertos. Com ele é possível implementar segurança, busca de
informações, gerenciamento de recursos e de dados, comunicação, detecção de falhas e
portabilidade (DANTAS; ALLEMAND; PASSOS, 2003). Segundo (FOSTER; KESSELMAN,
1997), os serviços no Globus são baseados em um modelo conhecido como Hourglass
(Ampulheta). Nesta analogia, os serviços locais encontram-se na parte inferior da ampulheta, enquanto que os serviços globais estão na parte superior. Os serviços fornecidos
pelo Globus cam localizados no gargalo da ampulheta. Os componentes do conjunto
50
de ferramentas Globus podem ser usados tanto independentemente quanto em conjunto
no desenvolvimento de aplicações e de ferramentas de programação em Grid. Para cada
componente existe uma API em linguagem C ou Java denida para facilitar o uso pelos
desenvolvedores. A Figura 18 demonstra a estrutura do Globus Toolkit.
Figura 18: Uma visão geral do sistema Globus Toolkit (FERREIRA et al., 2002).
As versões mais atuais do Globus Toolkit (GT) (versão 3 em diante) são baseadas
no conceito de Grid Services, uma expansão do conceito de Web Services. Os principais
conceitos e padrões nos quais está baseado o GT3, versão usada neste trabalho, serão
discutidos a seguir.
• OGSA (Open Grid Services Architecture ): Como mencionado anteriormente, a utilização de padrões é uma das principais necessidades para que os sistemas em Grid
sejam amplamente utilizados. A arquitetura da computação em Grid é denida pela
OGSA, desenvolvida pelo Global Grid Forum (GGF) (GLOBAL. . . , 2004).
OGSA dene uma arquitetura aberta, padrão e comum para aplicações baseadas
em Grid. A sua principal meta é padronizar aqueles serviços relacionados com aplicações Grid, tais como: serviços de gerenciamento de trabalho, serviços de gerenciamento de recursos, serviços de segurança etc. Para tanto é especicado um conjunto
de interfaces padrão para estes serviços. Nesse sentido OGSA tem sido proposta
como uma infraestrutura para aplicações e sistemas que requerem a integração e
gerenciamento de serviços dentro de organizações virtuais dinâmicas, heterogêneas
e distribuídas. É baseada nos padrões já denidos para os Web Services e considera um serviço em um Grid como um Web Service com algumas particularidades
51
denidas através da linguagem padrão chamada WSDL (Web Services Description
Language ), com pequenas extensões. Isto é importante porque fornece uma maneira
de acessar um serviço em Grid usando padrões abertos e consolidados, como SOAP,
XML e WS-Security. Além disso, padronizam a pesquisa, identicação e utilização
de novos serviços conforme forem sendo adicionados ao Grid.
• OGSI (Open Grid Services Infrastructure ): É a especicação concreta da arquitetura
OGSA. É baseado nas tecnologias de Grids e Web Services, chamados Grid Services,
e dene como construir, gerenciar e expandir um serviço.
• Web Services : São a base para o conceito de Grid Services e, por sua vez, a base
para o OGSI, OGSA e o GT3. Web Services é uma tecnologia de computação
distribuída que permite a criação de aplicações cliente/servidor usando como plataforma de comunicação protocolos abertos e amplamente conhecidos como o HTTP
e o XML. Desta forma, pode-se executar um serviço através de uma Intranet ou
mesmo Internet, ocultando do cliente detalhes relativos a implementação (serviço
desenvolvido em Java, C++ etc) e plataforma (servidor Linux, Windows, Unix ou
em um mainframe), bastando ao cliente conhecer a URL através da qual o serviço
pode ser acessado, e as interfaces de seus métodos.
Os Web Services são denidos pelo W3C (World Wide Web Consortium ) , denindo
uma maneira padronizada para descrevê-los, o WSDL (Web Sevice Description Lan-
guage ) . Basicamente este padrão dene como são descritos os métodos, parâmetros,
tipos de dados, protocolo de transporte e URI (Uniform Resource Identier) de um
serviço. Para um Web Service ser acessado, o mesmo precisa ser publicado em um
servidor. Também deve existir uma forma através da qual possam ser realizadas
pesquisas em busca de um determinado serviço. Para suprir estas necessidades, o
W3C deniu um padrão chamado UDDI (Universal Description, Discover and In-
tegration). Um protocolo padrão para comunicação também foi denido, o SOAP
(Simple Object Access Protocol), sendo baseado em XML e usando o HTTP como
transporte.
Mas porque não usar tecnologias como RMI, CORBA, EJBs etc para criar uma aplicação baseada em serviços Web. O que fazem os Web Services especias? Segundo
(SOTOMAYOR, 2003), estes tem certas vantagens com relação as outras tecnologias
de computação distribuída. Web Services são independentes de plataforma e linguagem, pelo fato de usarem XML. Isto signica que um programa cliente pode ser
implementado em C++ e executar em um sistema operacional Windows, enquanto
52
que o Web Service é programado em Java e está executando em um servidor Linux.
Além disso, a maioria dos Web Services usam HTTP para transmitir mensagens
(tal como os serviços de resquest e response ). Isto é uma grande vantagem para
a construção de aplicações Web, por que a maioria dos proxies e rewalls não trabalham bem com tráfego sobre HTTP (tal como CORBA que tem problemas com
rewalls ).
Web Services também possuem desvantagens. Uma delas é o overhead pois, a
transmissão de dados é feita usando XML que é, obviamente, menos eciente do que
usar um código binário proprietário. Tal como Java, o que se ganha em portabilidade
perde-se em eciência. Apesar disso, este overhead é usualmente aceitável para a
maioria das aplicações. Contudo, será difícil encontrar aplicações críticas de tempo
real que usam Web Services (SOTOMAYOR, 2003). Um outra desvantagem é que
Web Services não são muito versáteis, desde que eles não oferecam suporte para
serviços de persistência, noticação, gerenciamento de ciclo de vida, transações etc.
Mais adiante, será explicado que os Grid Services dão suporte para este leque de
versatilidade.
Entretanto existe uma importante caracterítica que distingue Web Services das outras tecnologias de computação distribuída. Enquanto tecnologias tal como CORBA
e EJB são voltadas para sistemas distribuídos altamente acoplados, onde cliente e
servidor são muito dependentes um do outro, Web Services são mais adequados para
sistemas fracamente acoplados, onde cliente pode não ter conhecimento, a priori, do
serviço até que ele o invoque. Sistemas distribuídos altamente acoplados são ideais
para aplicações intranet, e não para aplicações Web. Web Services, são mais adequadas para alcançar as demandas de uma aplicação Internet-wide, tal como aplicações
orientadas a Grid (SOTOMAYOR, 2003).
Desde que Web Services são a base para Grid Services, entender o seu funcionamento é de fundamental importância para usar o Globus Toolkit 3 e programar
Grid Services. A Figura 19 mostra o processo de invocação de um Web Service.
1) O cliente utiliza o Registro UDDI para descobrir onde o serviço desejado
está sendo fornecido;
2) O Registro UDDI responde ao cliente com o endereço do serviço na forma
de um URI que aponta para o servidor que fornece o serviço desejado. Um
exemplo de URI: http://webservices.mysite.com/clima/br/ClimaService;
3) Com esta informação o cliente conhece a localização do serviço, mas ainda
53
Figura 19: O processo de invocação de um Web Service (SOTOMAYOR, 2003).
não sabe como invocá-lo. Então, o cliente pergunta ao servidor como pode
invocar o serviço desejado;
4) O servidor responde ao cliente enviando um documento WSDL, que descreve
a interface do serviço, ou seja, seus métodos, parâmetros e tipos de dados;
5) De posse destas informações, o cliente sabe como invocar o serviço, sendo que
esta invocação pode ser realizada usando-se diversos protocolos. O protocolo
padrão para esta função é o SOAP. O cliente então faz a chamada ao serviço
usando o mesmo;
6) O serviço responde então com uma resposta SOAP, encapsulando os dados
no padrão XML.
Como mencionado anteriormente, Web Service é a tecnologia escolhida para aplicações distribuídas cujos clientes e servidores são fracamente acoplados. Isto faz
com que seja a escolha natural para a construção de aplicações baseadas em Grid.
Entretando, é importante lembrar que Web Services têm certas limitações, fazendo
com que estes não sejam muito apropriados para a construção de aplicações Grid.
Para contornar essas limitações, surgiram os Grid Services, que são basicamente
Web Services com características e serviços melhorados.
• Grid Services : São baseados no conceito de Web Services com algumas particulari-
54
dades e mecanismos denidos pelo OGSI. As principais melhorias introduzidas pelos
Grid Services são:
Factory : usam uma abordagem de Factory para a criação de instâncias de
serviços. Ao contrário de ter um serviço compartilhado por todos os usuários,
tem-se uma fábrica central responsável por criar instâncias desse serviço sob
demanda. Assim, quando um cliente quer efetuar uma operação deste serviço,
ele se comunica com a sua instância do serviço. Quando um cliente necessita
de uma nova instância, ou de destruir uma, ele requisita à fábrica.
Naming : da mesma maneira que um Web Service possui uma URI associada
a ele, o Grid Service possui uma identicação, conhecida como Grid Service
Handle (GSH). Assim como uma URI é o único modo de identicar um único
Web Service, o GSH também deve identicar um único Grid service. O GSH
não fornece informações detalhadas sobre o Grid Service, apenas seu endereço.
Desta forma, para conhecer os detalhes e requisitos de comunicação com o
serviço, uma GSH é mapeada a um Grid Service Reference (GSR). Então,
um GSH aponta para um Grid Service e o GSR especica como deve ser a
comunicação com este serviço. Como o GT3 usa a tecnologia de Web Services,
SOAP é usado como meio de comunicação entre os serviço e um documento
WSDL é usado para a descrição necessária pelo GSR. Resumindo, o GSR nada
mais é do que um documento WSDL entregue usando SOAP.
Data Service : uma instância de um Grid Service pode possuir uma coleção de
dados estruturados associados a ela e que podem ser acessados pelos usuários
do serviço. Estes dados, chamados de Service Data Elements (SDE), podem
ser pesquisados e alterados pelos usuários. A especicação OGSI dene alguns
tipos padrões de SDE que podem ser usados pelos Grid Services, sendo que
um Grid Service geralmente possui alguns destes SDEs quando é instanciado.
Notication : o mecanismo de noticação permite que um serviço seja uma fonte
de noticação, e que este envie mensagens para aqueles clientes interessados
na ocorrência de determinado evento.
Lifecycle Management : a especicação OGSI dene o ciclo de vida de um
serviço como o tempo desde a criação de uma instância até a sua destruição. A
criação da instância pode ser realizada pelo cliente ao requisitar ao mecanismo
Factory. O processo de destruição pode ser feito ao invocar o método da
instância responsável por esta tarefa. Outra forma do ciclo de vida é quando
55
o cliente instancia o serviço por um tempo determinado. Quando este período
expira, se o cliente não rearmar o interesse pela utilização, a instância do
serviço é destruída.
portType Extension : um Web Service disponibiliza suas interfaces (operações
que ele pode executar) através de um documento WSDL. A interface é usualmente chamada de portType. Um Web Service normal pode ter apenas um
portType. Grid Services, por outro lado, suportam a extensão de portTypes,
o que signica que é possível denir um portType como uma extensão de um
portType que já existe. Em geral um Grid Service pode estender três tipos de
portTypes (vide Figura 20).
Figura 20: Tipos de portTypes que um Grid Service pode estender (SOTOMAYOR, 2003).
A Figura 21 exemplica os conceitos OGSA, OGSI, Web Service e a ferramenta
Globus Toolkit interagem para a criação de um Grid Service.
Figura 21: Interação entre as partes componentes (SOTOMAYOR, 2003).
56
• WSRF/GT4
Com a evolução da arquitetura de Web Services, e tendo em vista que toda a base
de Grid Services tem origem nas tecnologias para Web Services, foi preciso ocorrer
um renamento em alguns aspectos da especicação OGSI (CIRNE; NETO, 2005).
A principal crítica estava relacionada aos mecanismos de endereçamento para os
serviços, por exemplo: Grid Service Handler e Grid Service Reference. Objetivando
fornecer um mecanismo de endereçamento independente da camada de transporte,
surgiu o WS-Addressing (CZAJKOWSKI et al., 2004).
Além dessa, outras características da especicação OGSI necessitavam ser alteradas
para poder acompanhar a evolução da tecnologia Web Service. Nesse sentido, é
criado o WSRF (Web Service Resource Framework ), que é basicamente o resultado
do renamento de OGSI objetivando aproveitar a existência dos novos padrões que
surgiram para Web Services (e.g. WS-Addressing, WS-Notication ) e assimilar a
demanda da comunidade Web Services.
Uma outra medida importante diz respeito a recuperação da compatibilidade com as
ferramentas existentes para XML e Web Services, já que OGSI usa GWSDL, o qual
provê acréscimos se compadaro ao WSDL 1.1. Contudo, estes acréscimos estarão
disponíveis nas versões WSDL 1.2/2.0. Ao contrário de OGSI, ao invés de estender
a denição de portType WSDL 1.1, ou mesmo esperar pelo portType da nova versão
WSDL 2.0, WS-Resource Framework utiliza puramente WSDL 1.1, o que garante
compatibilidade com as ferramentas existentes para Web Services.
Alguns entusiastas da área de Web Services, em geral, argumentam que Web Services
não devem manter estado ou ter instâncias. Ou seja, Atualmente, OGSI modela um
recurso que mantém estado como um Web Service que encapsula o estado do recurso.
WS-Resource Framework modica esse modelo para criar uma distinção explícita
entre serviço e entidades que mantém estado e são manipuladas através do serviço.
Esta composição é denominada WS-Resource pelo padrão WSRF, que introduz a
idéia de recursos que mantém estados e podem ser acessados através de Web Services
via o uso convencional de WS-Addressing.
Em linhas gerais, a evolução de OGSI se deu em três fases: introdução do conceito
de WS-Resource ; divisão de funcionalidades em várias especicações melhorando
a compatibilidade com ferramentas usadas para Web Service ; e nalmente, uma
melhoria nos mecanismos de noticação. O padrão WSRF deve se materializar, de
forma estável, através do lançamento do Globus toolkit 4.
57
4
Especicação Funcional
4.1 A Camada de Wrapper-Grid do CoDIMS
Como já ressaltado anteriormente, na versão atual do CoDIMS (BARBOSA, 2001),
os wrappers estão instalados no mesmo servidor e implementados internamente no componente Acesso aos Dados. Isso acarreta sobrecarga deste servidor, gerando lentidão na
execução das consultas. Com o intuito de solucionar este problema, neste trabalho é dada
uma maior ênfase na elaboração de uma sistemática que possibilite a distribuição e execução de wrappers em um ambiente distribuído (nós de um Grid), objetivando melhorar o
desempenho do CoDIMS como um todo. Isso é feito através da criação de uma camada de
Wrapper -Grid que é composta por Componentes Wrapper Grid (WGCs). Nesta camada,
os Wrappers Services irão desempenhar suas funcionalidades, que são: comunicação com
as fontes de dados e tradução entre modelos. Além desse, outros serviços são necessários,
tais como: noticação, armazenamento etc.
A arquitetura original do CoDIMS (Figura 22) é dividida em três camadas: Apresentação, Integração e Fontes de Dados. Com a incorporação da camada de Wrapper -Grid
(BIANCARDI; SILVESTRE; BARBOSA, 2005), o CoDIMS agora possui uma arquitetura
de quatro camadas, que são: Apresentação, Integração, Wrapper -Grid e Fontes de Dados
(Figura 23).
Através de uma aplicação cliente, um usuário de uma instância do CoDIMS submete
sua consulta, que é repassada para a camada de Integração. Nesta camada, o componente Controle é responsável por receber a consulta e repassá-la para o componente
Processamento de Consulta. Este componente transforma uma consulta escrita em uma
linguagem de alto nível (por exemplo SQL), disponibilizada pelo sistema integrador, em
uma estratégia eciente de execução, considerando, por exemplo, as características das
fontes de dados. O Processamento de Consulta
1
(Figura 24) deve interpretar e analisar
(Analisador) a consulta global recebida, produzir as sub-consultas (Reescritor) que serão
1 Uma
descrição mais detalhada de cada sub-componente pode ser encontrada em (BARBOSA, 2001).
58
Figura 22: Arquitetura do CoDIMS sem Grid .
Figura 23: Arquitetura do CoDIMS em um ambiente de Grid.
59
submetidas a cada uma das fontes de dados, gerar um plano de execução global otimizado
(Otimizador) e proceder a execução da consulta e a composição dos resultados parciais
(Processador - MEC (PINHEIRO, 2004)) vindos de cada fonte.
Figura 24: Interação entre os sub-componentes do Processmento de Consultas com os
components do CoDIMS.
O Plano de Execução de Consultas (PEC) gerado pelo Otimizador é implementado
através de uma árvore de consulta. Cada folha desta árvore armazena uma sub-consulta
que deve ser encaminhada, através da MEC, para ser executada em uma fonte de dados
a qual está relacionada.
A capacidade do CoDIMS de integrar dados heterogêneos e distribuídos se dá, em
parte, devido ao comportamento do componente Acesso aos Dados que, através dos wrap-
pers, consegue acessar as fontes locais nos seus diversos formatos. Para tanto, cada subconsulta gerada pelo componente Processamento de Consulta deve ser enviada ao componente Acesso aos Dados através da MEC. Na implementação atual do CoDIMS este
envio é feito de maneira síncrona, ou seja, para cada folha do PEC é estabelecida uma
comunicação com o componente Acesso aos Dados e enviada a sub-consulta. Essa comunicação perdura até o término da recuperação do conjunto-resultado dessa sub-consulta.
Isso segue para todas as folhas do PEC, de forma que nenhuma outra folha (sub-consulta)
possa ser processada fora da ordem estabelecida (caminhamento nesta árvore). A gura
25 ilustra esse processo de execução.
Este trabalho traz uma nova abordagem que elimina essa deciência. É possível,
para cada folha do PEC, ser feita uma chamada assíncrona ao componente Acesso aos
Dados. Nesse componente existe uma la de sub-consultas a serem executadas. As
mensagens a serem inseridas nessa la contêm as seguintes informações: identicador da
consulta, identicador da sub-consulta e info-sub-consulta, que contém a sub-consulta
propriamente dita (embutida em XML e representada segundo o padrão estabelecido em
60
Figura 25: Interação entre a MEC, Acesso aos Dados(AD) e os wrappers para execução
do PEC.
(PINHEIRO, 2004)), além de outras informações. O identicador da consulta é necessário
pois, futuramente, pensa-se em estender o CoDIMS de forma a suportar um ambiente
multi-usuário. Um exemplo de la pode ser visto na Figura 26.
Uma sub-consulta a ser executada é enviada pela MEC ao componente Acesso aos
Dados, neste ela é inserida no nal da la de execução de sub-consultas. Sempre que uma
inserção é realizada nessa la, uma noticação é feita ao observador da mesma, indicando
que existe uma nova sub-consulta que deve ser executada. Para tanto, é preciso recuperar
os dados armazenados na la. O observador recupera os dados da sub-consulta a ser
executada seguindo a ordem imposta pela la. Para proceder essa execução, é preciso
enviar esses dados para a camada de Wrapper -Grid, que é formada pelos Componentes
Wrapper Grid (WGCs) (BIANCARDI; SILVESTRE; BARBOSA, 2005) (Figura 27).
Como um dos objetivos é paralelizar a execução das sub-consultas e as tarefas desempenhadas pelos wrappers, é criada uma thread para cada sub-consulta a ser enviada para
a camada mencionada, de forma que as sub-consultas sejam encaminhadas de maneira
assíncrona, já que isso deve ser feito para todas as sub-consultas provenientes da MEC.
4.2 Componente Wrapper Grid - WGC
WGC (Figura 27) é um componente que visa auxiliar o processo de integração de
dados heterogêneos e distribuídos. Na base deste componente é usado o Globus Toolkit
61
Figura 26: Fila de sub-consultas a serem executadas.
62
(GLOBUS, 2004), que é uma implementação de referência OGSA (FOSTER; GANNON,
2003). Um WGC estende os serviços Grid para suportar as seguintes funcionalidades
dentro do cenário de integração de dados:
Figura 27: Wrapper Grid Component (WGC).
• publicar os serviços do componente;
• encapsular as funcionalidades básicas de um wrapper em um Wrapper Service - WS;
• gerenciar o ciclo de vida de instâncias de WS;
• noticar o componente Acesso aos Dados quando uma sub-consulta for nalizada;
• armazenar o conjunto resultado gerado por uma sub-consulta em um nó do Grid;
• processar uma sub-consulta;
• fornecer informações sobre o nó (capacidade ociosa de processamento, memória e
armazenamento);
• outros serviços podem ser adicionados para aplicações especícas.
Para que seja feita a utilização de um WGC, é necessário fazer a instalação do mesmo
em um nó do Grid. Com o objetivo de possibilitar a escolha de qual nó (onde existe um
WGC instalado) irá executar uma determinada instância de um WS especíco, em um
WGC existem WSs para todas as fontes de dados envolvidas na conguração do CoDIMS
(Figura 28). Para cada fonte de dados que faz parte de um sistema congurado (instância
63
do CoDIMS), deve haver um WS especíco e publicado no componente Metadados. Convém ressaltar que a complexidade de um WS está relacionada à diculdade de tradução
da linguagem do sistema congurado para a linguagem da fonte de dados e a forma de
acesso à ela.
Figura 28: Em cada WGC existem WSs para todas as fontes.
Antes de o componente Acesso aos Dados encaminhar uma sub-consulta a um WGC,
é preciso que o mesmo escolha em qual nó, com maior ociosidade, uma instância WS
será alocada. Para isso, o componente Acesso aos Dados faz uma análise do estado
atual dos nós, levando em consideração fatores como: CPU, memória, capacidade de
armazenamento, largura de banda da rede, comunicação entre as máquinas etc. Para
obter estas informações, Acesso aos Dados consulta os WGCs instalados nos nós do Grid.
Vale lembrar que outros tipos de informações como estatísticas das fontes (tempo médio
de acesso, capacidade de processamento e complexidade de tradução) também devem
ser levadas em consideração para fazer essa alocação, dado que para um nó com grande
capacidade de processamento é mais interessante alocar uma instância WS, por exemplo,
associada a fontes que possuam uma maior capacidade de processamento sendo possível
aproveitar, ao máximo, a ociosidade do nó. Para obter essas informações, o componente
Acesso aos Dados deve consultar o componente Metadados.
Escolhido o nó, o componente Acesso aos Dados recupera de info-sub-consulta, qual o
WS associado a fonte a ser consultada (para cada fonte existe um diferente WS associado),
a sub-consulta e as informações de acesso à fonte (URL, usuário, senha, porta etc). Em
seguida, o mesmo faz a alocação da instância WS no respectivo nó, situado na camada
de Wrapper -Grid, com a sua sub-consulta, a ser encaminhada à fonte, bem como as
informações de acesso à fonte. Nesta camada, as seguintes tarefas são desempenhadas
64
após a criação da instância WS: tradução da sub-consulta do modelo global para o modelo
de dados nativo da fonte; comunicação com a fonte de dados; encaminhamento da subconsulta para a fonte de dados. A gura 29 ilustra quais passos o componente Acesso
aos Dados deve seguir para a criação de uma instância WS.
Figura 29: Criação de uma instância WS.
Vale ressaltar que para aquelas fontes que não possuem capacidade de processamento
de consulta, um WS poderia efetuar esse processamento. Na fonte de dados, a subconsulta é processada e, ao término, o conjunto resultado é transmitido para a camada
de Wrapper -Grid, mais precisamente para o nó no qual foi criada a instância do serviço.
Após a transmissão, é feita a tradução de modelos do conjunto-resultado (conversão do
modelo nativo da fonte para o modelo de dados global) e, logo após, é feita uma noticação ao componente Acesso aos Dados, para que este possa indicar o término da execução
da sub-consulta à MEC. Nessa noticação, são enviadas as seguintes informações: identicador da consulta, identicador da sub-consulta e localização (endereço do nó, diretório
e nome do arquivo) do conjunto-resultado da sub-consulta em questão. Isso é necessário
para que a MEC tenha o conhecimento de quais sub-consultas foram nalizadas e assim
possa executar o seu PEC Global. No componente Acesso aos Dados existe uma la
responsável por armazenar essas informações e, sempre que uma nova informação é inserida, é feita uma noticação à MEC. Tal sistemática garante que os conjuntos-resultado
65
provenientes da execução de cada sub-consulta quem armazenados em diferentes nós do
Grid, permitindo, assim, a continuidade da execução do PEC de forma distribuída e, conseqüentemente, possibilitando a execução paralela das suas operações internas (junções,
uniões etc.). Um exemplo de la pode ser visto na Figura 30.
Figura 30: Fila de sub-consultas já executadas.
Na gura 31 é mostrado o processo de execução de sub-consultas descrito anteriormente.
Figura 31: Processo de execução de sub-consutlas de forma assíncrona.
Para resumir a especicação funcional do CoDIMS, a Figura 32 ilustra todo o uxo
de execução de uma consulta. Alguns detalhes como por exemplo, mensagens das las,
66
foram omitidos por questão de espaço. Nesta gura existe uma enumeração dos passos
para a execução completa de uma consulta.
• 1 - usuário submete uma consulta, através de uma aplicação cliente, à camada de
apresentação;
• 2 - componente Controle recebe a consulta e encaminha para o componente Processamento de Consulta (PC);
2.1 - PC consulta o componente Metadados para obter informações sobre mapeamentos, existência de tabelas e atributos, Wrapper Services, informações de
acesso a fontes e estatísticas para desempenhar as funcionalidades de Analisar
(2.2), Reescrever (2.3) e Otimizar (2.4) a consulta global;
2.5 - é feito o envio das sub-consultas para o componente Acesso aos Dados
(AD) e a composição dos conjuntos-resultado provenientes da execução das
sub-consultas;
• 3 - AD recebe as sub-consultas e armazena em uma la de execução de consultas.
Para cada sub-consulta inserida, é feita uma análise da ociosidade dos nós, alocada
uma instância WS no nó escolhido e encaminhada a sub-consulta;
• 4 - é feita a tradução da consulta do modelo global para o modelo local e estabelecida
uma comunicação com a fonte de dados. Em seguida, a sub-consulta é encaminhada
para a fonte (4.1);
• 5 - a fonte processa a sub-consulta e retorna o resultado para o WGC associado a
instância WS gerenciando esta sub-consulta (5.1);
• 6 - recuperar o conjunto-resultado vindo da fonte e efetuar a tradução entre modelo
do mesmo e armazena este resultado no nó;
• 7 - após armazenar o conjunto-resultado, a instância WS notica AD indicando o
término da execução da sub-consulta;
• 8 - AD notica a MEC indicando o término da execução da sub-consulta, bem como
fornece informações de acesso ao conjunto-resultado gerado por esta sub-consulta;
• 9 - Ao término da composição dos conjuntos-resultados, PC encaminha os resultado
nal para o Controle que por sua vez repassa para o Cliente.
67
Figura 32: Exemplo de execução de uma consulta.
68
5
Modelagem
5.1 Diagramas de Pacotes e de Classes
A Figura 33 mostra o diagrama de pacotes e a dependência entre eles, no caso
AcessoDados, ProcessamentoConsulta e Wrapper -Grid.
Figura 33: Dependência entre os pacotes AcessoDados, ProcessamentoConsulta e Wrapper -Grid.
Essa dependência existe, pois o pacote Acesso aos Dados necessita de elementos denidos no pacote Wrapper -Grid para que seja possível fazer a interação entre as camadas de
Integração e Wrapper -Grid. Já o pacote ProcessamentoConsulta necessita elementos denidos no pacote AcessoDados para poder executar as sub-consultas e efetuar a composição
dos conjuntos-resultados de cada uma destas. Essa interação se dá, por exemplo, através
da criação de instâncias de serviços Grid e da noticação de execuções de sub-consultas
já processadas.
A seguir serão descritas as principais classes de cada pacote.
5.1.1 Classes do pacote AcessoDados
A Figura 34, mostra as classes do pacote AcessoDados e como elas se relacionam.
69
Figura 34: Classes do pacote AcessoDados.
• FachadaAcessoDados : Esta classe (Figura 35) é constituída pelos seguintes atributos: laMsg, contém as informações sobre as sub-consultas a serem processadas nas
fontes de dados; ec, que é responsável por disparar um processo para a execução de
uma sub-consulta; e objObserver, que contém o observador de laMsg. Com relação
aos seus métodos, setMsg tem por nalidade inserir informações sobre uma nova
sub-consulta em laMsg e, após isso, noticar o observador da la para que ele
dispare um processo que inicie a execução da sub-consulta.
Figura 35: Classe FachadaAcessoDados do pacote AcessoDados.
• ExecutaSubConsulta : Esta classe (Figura 36) é constituída pelos seguintes atributos: listaIn, contém as informações sobre as sub-consultas a serem processadas nas
fontes de dados; listaOut, contém as informações sobre todas as sub-consultas já
processadas nas fontes de dados; index, um índice controlador da próxima consulta
a ser executada; notMec, responsável por noticar a MEC (Máquina de Execução
de Consultas) com informações sobre o resultado da execução de uma sub-consulta;
ewt, representa os processos a serem disparados para criar instância(s) de Wrapper
Service que irão executar sub-consultas. Dentre os seus métodos alocaWrapperService é responsável por analisar a ociosidade dos nós que fazem parte do Grid levando
em consideração fatores como, uso de CPU e memória, estatística de consultas e
disponibilidade da fonte, para que seja possível alocar a instância de um Wrapper
70
Service, a ser criada, em um nó menos sobrecarregado; getWarpperService tem por
nalidade descobrir qual Wrapper Service é responsável por uma fonte a ser acessada; handleEvent dispara um processo que cria uma instância de Wrapper Service
para proceder a execução da sub-consulta, de acordo com as informações dadas pelos
dois métodos anteriores.
Figura 36: Classe ExecutaSubConsulta do pacote AcessoDados.
• ExecutaWrapperThread : Esta classe (Figura 37) é constituída pelos seguintes atributos: conObj, que contém o observador de listaOut ; listaOut, que contém as informações sobre as sub-consultas já processadas nas fontes de dados; infoLista, que
representa as informações sobre uma sub-consulta a ser processada; site, que é a
localização do nó do Grid; ServiceLocator, que representa a localização do serviço
e ser executado; servico, instância do serviço criado. Dentre os seus métodos: run,
método executado quando um processo desta classe é disparado, para tanto Exe-
cutaWrapperThread estende a classe Thread ; executaServico, cria a instância do
Wrapper Service para processar a sub-consulta na fonte; geraSubConsulta, retorna
a sub-consulta no modelo da fonte; getInfoAcesso, retorna informações sobre como
acessar a fonte de dados da sub-consulta.
• NoticaMec : Esta classe (Figura 38) é constituída pelos seguintes atributos: laOutMsg, representa todas as sub-consultas já processadas nas fontes de dados;
index, um índice controlador da próxima consulta a ser executada. Dentre os métodos: handleEvent ; envia uma mensagem para a MEC noticando o término da
execução de uma sub-consulta.
• ConcretObservable : Esta classe (Figura 39) possui o seguinte atributo: observers,
uma lista que contém os observadores relacionados com uma instância da classe ConcretObservable. Dentre os seus métodos: addObserver(obsrNewObserver, adiciona
71
Figura 37: Classe ExecutaWrapperThread do pacote AcessoDados.
Figura 38: Classe NoticaMec do pacote AcessoDados.
um observador a observers ; removeObserver, remove um observador de observers ;
notifyObservers, notica todos os observadores de uma instância de ConcretObservable presentes em observers. Para desempenhar essa nalidade, essa classe implementa o pattern Observer (JAVACAMP, 2005).
Figura 39: Classe ConcretObservable do pacote AcessoDados.
5.1.2 Classes do pacote Wrapper-Grid
A Figura 40, mostra as classes do pacote Wrapper -Grid e como elas se relacionam.
• WrapperBDimpl : Esta classe (Figura 41) implementa um serviço Grid - (Wrapper
Service ) - para uma fonte de dados. Ela é constituída pelos seguintes atributos:
72
Figura 40: Classes do pacote Wrapper -Grid.
consultaXML, contém os dados necessários, encapsulados em XML, para gerar uma
sub-consulta a ser processada na fonte; nomeArqResultado, nome do arquivo no qual
será armazenado o conjunto resultado; infoAcesso, contém os dados de acesso da
fonte. Dentre os métodos: conecta, estabelece uma conexão com a fonte de dados;
shutDown, fecha a conexão com a fonte; subConsulta, executa a sub-consulta na fonte
e recupera o resultado; transformaModelo, aplica a transformação de modelos de
dados no conjunto-resultado gerado (modelo nativo da fonte para o modelo global);
parserDados, recupera de infoAcesso os dados de acesso a fonte. Esta classe estende
GridServiceImpl e implmenta WrapperPortType. Estas classes contêm a denição
e implementação dos métodos necessários para que seja possível criar um serviço
Grid.
Figura 41: Classe WrapperBDImpl do pacote WrapperGrid.
73
• WrapperServiceGridLocator : criada quando do processo de geração do serviço Grid.
É utilizada no pacote AcessoDados, possibilitando encontrar um Wrapper Service
implantado em um nó do Grid.
5.1.3 Classes do pacote ProcessamentoConsulta
A Figura 42, mostra as classes do pacote ProcessamentoConsulta e como elas se
relacionam.
Figura 42: Classes do pacote ProcessamentoConsulta.
• MEC : Esta classe (Figura 43) contém o Plano de Execução de Consultas (PEC)
com as sub-consultas a serem executadas nas fontes de dados. Nesta classe existe
uma la, laSubCons, com as informações das sub-consultas já executadas. Existe
um observador, objObserver, para esta la, que notica a existência de conjuntosresultado já processados para que a MEC possa executar as operações internas do
PEC de forma distribuída. O método setMsg insere informações nesta la sobre as
sub-consultas já processadas.
Na Figura 44, é mostrado o diagrama de classes envolvendo as classes dos três pacotes
acima e como as mesmas se relacionam.
A modelagem das classes foi feita usando a linguagem UML (Unied Modeling Lan-
guage ) através da ferramenta JUDE Community 1.4.3 (MANAGEMENT, 2005).
74
Figura 43: Classe MEC do pacote ProcessamentoConsulta.
5.2 Diagrama de Sequência
O objetivo deste diagrama (Figura 45) é descrever as comunicações necessárias entre
objetos para a realização da execução de uma consulta. Assim, neste diagrama é feito, ao
longo de uma linha de tempo, a sequência de comunicações entre objetos.
75
Figura 44: Diagrama de Classes
76
Figura 45: Diagrama de sequência
77
6
Estudo de Caso
6.1 Descrição da Aplicação
Um hospital deseja saber, em um tempo hábil, dentre aquelas pessoas que já tiveram passagem por ele, aquelas que são doadoras de sangue para um determinado tipo
sangüíneo. Essa informação é necessária pois, na unidade de emergência desse hospital,
ocorrem, com frequência, casos em que pacientes necesitam fazer uma transfusão de sangue. Apesar disso, nem sempre existe um determinado tipo sangüíneo disponível em seu
banco de sangue.
Para tentar resolver esse problema, sempre que existe a necessidade de sangue por
algum paciente e este sangue não está disponível, é feita uma consulta nos dados cadastrais
de todos os pacientes, para descobrir aqueles que possuem o tipo sangüíneo desejado.
Essa consulta é possível pois, nos dados cadastrais dos pacientes existem informações do
tipo sangüíneo e se o paciente está apto a doar. Isso é feito com o objetivo de tentar
estabelecer um contato e solicitar uma possível doação nos casos de maior emergência.
Caso seja encontrado um doador, uma ambulância é deslocada até a residência do mesmo
para que o sangue seja recolhido.
Contudo, sempre que existe a necessidade de fazer este tipo de consulta, é necessário acessar as fontes de dados do ambulatório e da enfermaria, já que não existe um
banco de dados central e as informações podem estar presentes em uma e/ou em outra
destas unidades do hospital. Além disso, os dados estão armazenados em dois tipos de
fontes, possuindo representações diferentes, já que foram desenvolvidos de uma maneira
independente. Assim, é necessário o acesso e a integração destas duas fontes de dados,
distribuídas e heterogêneas, de forma que uma única visão, uniforme e homogênea, seja
fornecida.
A base de dados "ambulatorio", presente na unidade ambulatório, tem seus dados
armazenados segundo o modelo de dados XML, como pode ser visto na Figura 46.
78
Figura 46: DTD da fonte XML "ambulatorio".
O banco de dados "paciente", presente na unidade enfermaria, tem seus dados armazenados no modelo de dados relacional, como pode ser visto na Figura 47.
Figura 47: Esquema da fonte relacional "paciente".
Para resolver este problema, foi criada uma instância do CoDIMS com seus componentes básicos. Considerando o modelo de dados dessa instância como sendo relacional,
o esquema integrado disponibilizado para consultas é conforme a Figura 48.
Suponha que a seguinte consulta (Figura 49), no formato SQL, seja enviada ao
CoDIMS. Com esta consulta, deseja-se saber quais pessoas estão aptas a doar sangue,
sendo que o tipo sanguíneo deve ser O+.
Após a execução das tarefas de análise, reescrita e otimização, será gerado um plano
de execução de consulta (PEC) otimizado contendo as sub-consultas a serem processadas,
bem como as operações a serem aplicadas sobre os conjuntos-resultado vindos de cada
79
Figura 48: Esquema global visto pelos usuários.
Figura 49: Consulta enviada ao CoDIMS, na linguagem SQL.
fonte de dados. Este PEC é enviado à máquina de execução de consultas (MEC) para ser
executado. Como o modelo de dados integrador é relacional, as sub-consultas são geradas
no formato relacional, encapsuladas em XML segundo o padrão denido em (PINHEIRO,
2004). Estas sub-consultas chegam aos wrappers, relacional e XML, conforme as guras
50 e 51, respectivamente .
Na sub-consulta da Figura 50, nomep, cidade, uf e telefone representam os atributos
a serem recuperados da fonte de dados paciente, segundo a condição estabelecida: edoador
= 'sim' e tiposanguineo = 'O+'.
Na sub-consulta da Figura 51, rst_name, last_name, cidade, estado e fone representam os atributos a serem recuperados da fonte de dados ambulatorio, segundo a condição
estabelecida: edoador = "sim"e tiposanguineo = 'O+'.
O wrapper relacional irá transformar a sub-consulta da Figura 50 em uma consulta
compreendida pela fonte de dados relacional, como pode ser visto na Figura 52. Essa
sub-consulta será processada pela fonte de dados relacional, e esta retornará um conjuntoresultado, no modelo de dados local, para o wrapper relacional. Este efetua a tradução do
conjunto-resultado para o modelo global, e converte os atribuitos locais para atribuitos
80
Figura 50: Sub-consulta enviada ao wrapper relacional.
Figura 51: Sub-consulta enviada ao wrapper XML.
81
globais levando em consideração os mapeamentos (correspodências) entre os mesmos, por
exemplo: no caso do atributo nomep, ele deveria ser mapeado para os atributos rst_name
e last_name. Por m, o wrapper gera um arquivo XML com essas informações.
Figura 52: Sub-consulta no modelo de dados nativo da fonte (fonte relacional).
Caso a fonte de dados não possua capacidade de processamento de consulta, o wrapper
extrai os atributos e as condições da sub-consulta, recupera todos os dados da fonte através
de um serviço Web, por exemplo, e faz o seu processamento segundo as condições. Isso é
feito para a sub-consulta da Figura 51, já que a fonte ambulatório não possui capacidade
de processamento de consulta.
6.2 Cenários de teste
Objetivando comparar a situação atual do CoDIMS (wrappers implementados internamente no componente Acesso aos Dados e executando em um mesmo servidor) com
este trabalho (a incorporação da camada de Wraper -Grid na arquitetura do CoDIMS e a
conseqüente execução, em paralelo, dos wrappers ), foram criados dois cenários de teste,
descritos a seguir.
6.2.1 Centralizado
O primeiro cenário de teste diz respeito a uma aplicação com processamento centralizado dos wrappers. Essa aplicação foi implementada levando em consideração a necessidade de efetuar o compartilhamento dos recursos de uma única máquina. Foram
implementadas duas classes que encapsulam as funcionalidades de wrappers XML e relacional, repectivamente. Estas classes estendem a classe Thread para que seja possível
executar os wrappers (XML e relacional) concorrentemente, possibilitando, assim, o uso
compartilhado/concorrente dos recursos da máquina (memória, CPU etc). Nesta aplicação foram disparados dois threads, um para o wrapper XML e outro para o wrapper
relacional. Cada wrapper tem por nalidade montar a sub-consulta no modelo da fonte,
acessar a fonte de dados à qual está associado, encaminhar a sub-consulta, recuperar
82
Tabela 2: Conguração das partes integrantes da infra-estrutura de teste centralizada.
Conguração
Camada
CAMBURI
PIII-850Mhz, 512M RAM
Wrappers Centralizados
GURIRI
PIII-850Mhz, 490M RAM
Fontes de Dados - SGBD
SETIBA
DURON-950Mhz, 512M RAM Fontes de Dados - serviço Web
HUB
10/100 Mbps
SWITCH
10/100 Mbps
-
o conjunto-resultado proveniente da execução da sub-consulta e efetuar a tradução de
modelo.
A infra-estrutura de teste pode ser vista na Figura 53. Na Figura 54, é mostrada uma
visão por camada da infra-estrutura de teste. Na Tabela 2 são mostradas as congurações
das partes integrantes desta infra-estrutura: máquinas, hub e switch.
Figura 53: Infra-estrutura de teste - wrappers centralizados.
A ferramenta de software utilizada na implementação foi o pacote Java J2SE Deve-
lopment Kit (JDK) 1.5.0.
83
Figura 54: Infra-estrutura de teste - wrappers centralizados - dividida em camadas.
6.2.2 Distribuído
O segundo cenário de teste está relacionado ao processamento distribuído dos wrap-
pers. Nesse sentido, foi implementada uma aplicação através da qual foi possível fazer
o uso dos recursos distribuídos. Para tanto, foi feita a instalação do middleware Globus
Toolkit 3.2 em duas máquinas, constituindo dois nós de Grid. Também foram implementados dois serviços Grid que encapsulam as funcionalidades de wrappers XML e relacional.
A descrição destes serviços, em GWSDL, é mostrada nas Figuras 55 e 56.
Este cenário poderia ser implementado através de outras tecnologias de computação
distribuída, tais como: CORBA, Web Services etc. Contudo, conforme discutido no
capítulo 3, essas tecnologias possuem algumas deciências com relação à computação
em Grid. Assim, como a pretensão é ter os wrappers compartilhando recursos dispersos
geogracamente em escala global, nada mais natural que utilizar um Grid.
A infra-estrutura de teste é mostrada na Figura 57. Na Figura 58, é mostrada uma
visão por camada da infra-estrutura de teste. Na tabela 3 são mostradas as congurações
das partes integrantes desta infra-estrutura: máquinas, hub e switch. O Hub possui 8
portas sendo que 7 estão em uso. Já o Switch possui 24 portas sendo que 12 estão em
uso.
Na máquina COSTA está instalado o Tomcat 5.5.7, que é utilzado para a implantação do componente Acesso aos Dados. Este componente é implementado através de um
Web Service, usando Apache Soap-RPC (TREVISOL, 2004). Nas máquinas CAMBURI
e ITAUNAS está instalado o Globus Toolit 3.2 (GLOBUS, 2004) e estão implantados os
84
Figura 55: Descrição do serviço Grid WrapperWSImpl em GWSDL.
85
Figura 56: Descrição do serviço Grid WrapperBDImpl em GWSDL.
86
Figura 57: Infra-estrutura de teste - wrappers distribuídos.
Tabela 3: Conguração das partes integrantes da infra-estrutura de teste distribuída.
Conguração
Camada
COSTA
PIII-450Mhz, 256M RAM
Integração
CAMBURI
PIII-850Mhz, 512M RAM
Wrapper -Grid
ITAUNAS
PIII-850Mhz, 380M RAM
Wrapper -Grid
GURIRI
PIII-850Mhz, 490M RAM
Fonte de Dados - SGBD
SETIBA
DURON-950Mhz, 512M RAM Fonte de Dados - serviço Web
HUB
10/100 Mbps
SWITCH
10/100 Mbps
-
87
Figura 58: Infra-estrutura de teste - wrappers distribuídos - dividida em camadas.
Wrapper Services desenvolvidos neste trabalho: fonte relacional (paciente) e XML (ambulatório). Na máquina GURIRI está instalado o SGBD Postgresql 7, que é responsável
pelo gerenciamento do banco de dados relacional. Na máquina SETIBA, está instalado o
Tomcat 5.5.7, que é utilizado para a implantação de um Web Service que foi desenvolvido
usando Apache Soap-RPC e tem por objetivo gerenciar (fornecer acesso aos dados) a fonte
de dados XML. Além disso, também existe instalado nesta máquina o SGBD Postgresql 7
para gerenciar a fonte ambulatório, só que agora representada usando o modelo relacional.
Com exceção da máquina SETIBA, que possui o sistema operacional Red Hat 8, todas as
outras máquinas possuem o sistema operacional Suse 9.0 instalado.
6.3 Resultados
Na descrição da aplicação, foi considerado apenas o cenário onde existe uma fonte
de dados relacional e outra XML. Para que os testes possam ser melhor analisados será
considerado um outro caso onde as duas fontes são relacionais.
Os testes foram feitos da seguinte forma: os conjuntos gerados pelas fontes de dados
possuem o mesmo tamanho, sendo que este tamanho aumenta para cada nova execução do teste. Possuindo o mesmo tamanho, aumenta-se a concorrência pelos recursos
computacionais, no caso da abordagem centralizada, já que, dependendo do tempo de
88
resposta das fontes de dados, os conjuntos a serem processados poderão chegar praticamente juntos. Com isso, os processos executando instâncias de diferentes wrappers terão
que desempenhar a tarefa de tradução de modelos com uma maior concorrência. No caso
da abordagem distribuída, não existirá essa concorrência pelos recursos computacionais
em uma única máquina, pois os processos iniciam as instâncias dos wrappers de forma
que elas executem em máquinas distribuídas, no caso, nós de um Grid.
Os resultados obtidos a partir dos testes feitos podem ser visualizados nos grácos
das Figuras 59 e 60. Nos testes, foram medidos os tempos de execução de cada wrapper
em separado. Assim, o tempo gasto pela aplicação, no que diz respeito a execução dos
wrappers, é indicado pelo maior tempo de execução. Por exemplo, no gráco da Figura
59, o tempo gasto para processar 1500 linhas na abordagem centralizado é 7,40 segundos
e, na abordagem distribuída, é 2,30 segundos.
Observando o gráco da Figura 59, pode-se concluir que: para pequenos conjuntos
de dados (até 300 linhas), a serem processados pelos wrappers, a abordagem centralizada
mostra-se mais eciente. Contudo, a partir deste ponto, a abordagem distribuída começa
a ser mais eciênte. Isso porque, na abordagem centralizada, quanto maior o conjunto de
dados a ser processado, maior será a concorrência pelo uso dos recursos computacionais.
Isso não acontece na abordagem distribuída, pois os wrappers estão executando em máquinas distintas. Uma mesma seqüência de testes foi feita em dias e horários diferentes.
Todos os resultados obtidos sinalizaram que quando aumenta o número de linhas maior
o tempo gasto.
Vale lembrar que não foi utilizada uma infra-estrutura dedicada de rede e de máquinas, ou seja, usuários do laboratório 1 , onde os testes foram realizados, poderiam estar
utilizando as máquinas no momento em que os testes estivessem executando. Além disso,
os testes foram feitos em dias distintos, ou seja, em um dia foi executado o cenário centralizado e em outro dia o cenário distribuído. Assim, como pode ser observado no gráco
da Figura 60, que mostra a execução das duas abordagens (centralizada e distribuída)
em diferentes horários, mas com os mesmos conjuntos-resultado (BD - 5000 linhas e XML
- 2000 linhas), os tempos de execução dos wrappers se mantêm praticamente os mesmos,
possuindo uma pequena variação. Isso mostra que a capacidade ociosa das máquinas,
a partir das quais está sendo feito o uso compartilhado dos recursos distribuídos, pode
contribuir, na abordagem distribuída, para a melhora no desempenho do CoDIMS. Uma
mesma seqüência de testes foi feita em dias diferentes mas nos mesmos horários. Todos
1 Laboratório
de Pesquisa em Redes e Multimídia - LPRM
89
Figura 59: Gráco de comparação entre as duas abordagens: Centralizada concorrente;
Distribuída. Fontes de dados: Bancos relacionais.
Figura 60: Gráco de comparação entre as duas abordagens: Centralizada concorrente;
Distribuída. Conjuntos-resultado com tamanho xos.
90
os resultados obtidos sinalizaram uma pequena alteração no tempo de execução, contudo
os mesmos se mantiveram praticamente os mesmos.
91
7
Conclusões
7.1 Conclusões gerais
Computação Grid tem se tornado muito popular, e muitos projetos tem sido iniciados para suportar, em parte, a visão de um Grid (FOSTER; KESSELMAN, 1999). Com
isso, a computação Grid tem emergido como um importante novo campo, distinto da
computação distribuída convencional, dado que o seu foco está no compartilhamento de
recursos, onde a principal idéia é criar a ilusão de um supercomputador virtual, em grande
escala, facilmente gerenciável e com uma grande quantidade de recursos (ciclos de CPU,
dados, dispositivos de armazenamento etc) sendo compartilhados (BERSTIS, 2003). Os
dispositivos podem estar em uma mesma sala ou distribuídos através do mundo, podem
estar utilizando diferentes plataformas de hardware ou diferentes sistemas operacionais, e
podem pertencer a diferentes empresas ou instituições.
Neste contexto, sistemas como Globus toolkit estão sendo desenvolvidos para fornecer
um conjunto de serviços Grid básicos, seguindo o padrão OGSI. Para suportar aplicações
em integração de dados, cujos dados são essecialmente heterogêneos e distribuídos, outros
tipos de serviços, tais como aqueles característicos de um wrapper, podem ser adaptados
para o ambiente de Grid.
Assim, o objetivo deste trabalho é a especicação e a implementação de uma nova camada, Wrapper -Grid, incorporada ao CoDIMS. Esta camada é composta por Componentes Wrapper -Grid (WGCs), os quais estão instalados em nós de um Grid, e implementam
serviços Grid que encapsulam as funcionalidades de wrappers. Isso possibilita a execução,
em paralelo, dos wrappers, já que estes são alocados para executar em nós de um Grid.
O objetivo principal dessa abordagem é o aumento de eciência do CoDIMS, já que, em
sua versão atual, os wrappers são implementados internamente no componente Acesso aos
Dados e instalados em um mesmo servidor, gerando sobrecarga deste servidor e lentidão
na execução das sub-consultas.
92
Em cada WGC existem Wrappers-Services para todas as fontes de dados que fazem
parte de uma conguração do CoDIMS. Com isso, é possível criar uma instância de um
Wrapper-Service, para uma fonte especíca, no nó que esteja com maior capacidade ociosa,
aproveitando os recursos disponíveis e distribuídos.
Uma alteração fundamental, feita no componente Acesso aos Dados, foi a criação de
um mecanismo de noticação. Esse mecanismo permite que as sub-consultas provenientes
do componente Processamento de Consulta, mais precisamente da MEC, sejam executadas
em paralelo. Além disso, o mecanismo permite que a MEC possua a informação de quais
são os conjuntos-resultado que já foram processados pelos Wrappers-Services e, assim a
mesma pode proceder o processamento de suas operações internas (junções, uniões etc)
segundo os princípios de banco de dados distribuídos.
Os resultados obtidos mostram que, para aquelas aplicações nas quais os conjuntosresultado proveniente das fontes de dados são pequenos, a utilização da versão original do
CoDIMS mostra-se satisfatória. Contudo, para aquelas aplicações nas quais os conjuntosresultado são razoavelmente grandes, e tendem a crescer mais, a nova abordagem do
CoDIMS apresentada neste trabalho é mais interessante, pois o tempo de resposta é
consideravelmente menor. Assim, quanto maior o conjunto-resultado, mais signicativa é
a diferença entre as abordagens, no que diz respeito ao tempo de execução da aplicação.
7.2 Contribuições
Em geral, as contribuições deste trabalho, para a integração de dados, são:
• execução em paralelo das sub-consultas a serem encaminhadas a cada fonte de dados;
• execução em paralelo dos wrappers, através da alocação destes em um ambiente
distribuído, mais precisamente alocação de instâncias Wrapper-Services em nós de
um Grid;
• disponibilização dos conjuntos resultados oriundos das fontes de dados em um ambiente distribuído, proporcionando a execução distribuída do PEC, objetivando um
melhor desempenho;
Com relação ao projeto CoDIMS, as principais contribuições estão relacioandas a:
• especicação e incorporação da camada de Wrapper -Grid e do seus componentes
(Componentes Wrappers -Grid);
93
• redução da carga do servidor Acesso aos Dados;
• criação de uma infra-estrutura de Grid;
• implementação de um protótipo com relação ao estudo de caso;
• implementação de uma la para troca de mensagens entre os componentes Processamento de Consultas (MEC) e o componente Acesso aos Dados, permitindo a
execução assíncrona e distribuída do PEC.
7.3 Trabalhos Futuros
No decorrer do desenvolvimento, surgiram alguns assuntos que não haviam sidos discutidos e pensados anteriormente, mas que agora devem ser explorados. Estes assuntos
estão relacionados tanto com o aperfeiçoamento deste trabalho como com melhorias que
devem ser feitas no CoDIMS.
• Realocação de instâncias
Devido à necessidade de realizar uma realocação de instâncias Wrapper Services
em tempo de execução, torna-se interessante que o componente Acesso aos Dados
possua a função de monitorar a vazão de cada sub-consulta. Quando identicada
sobrecarga de um nó, uma nova instância será criada para ser executada em um
outro nó do Grid. Contudo, a instância antiga poderá continuar executando pois,
para fontes com grande capacidade de processamento, pode acontecer de, apesar
de a nova instância estar executando em um nó menos sobrecarregado, a instância
antiga nalizar a sua execução antes da nova. Nesse sentido, é necessário abortar a
execução de uma instância caso o resultado já tenha sido gerado por outra. Dessa
forma, o componente que gerar primeiro o resultado deverá noticar o componente
Acesso aos Dados para que ele possa abortar a execução de instâncias Wrapper
Services idênticas às da sub-consulta em questão.
• Envio de código especíco de aplicação
Uma outra funcionalidade a ser adicionada no CoDIMS para Grid seria a implantação automática de código especíco de uma aplicação realizado através do envio
de classes Java para componentes WGCs. Para fontes de dados que não possuam
capacidade de execução de consulta, classes Java serão responsáveis por efetuar o
processamento da sub-consulta. Todas as classes Java serão primeiro armazenadas
94
em um repositório de código, presente no componente Acesso aos Dados, a partir
do qual serão posteriormente recuperadas e implantadas, de acordo com sua necessidade.
• MEC distribuída
Implementar uma nova versão da Máquina de Execução de Consulta, com suporte
a execução distribuída de consultas, já que, com a adição da camada de Wrapper Grid, os conjuntos-resultado cam armazenados em um ambiente distribuído, e a
MEC pode aproveitar isso para promover a execução distribuída do seu plano de
execução de consultas;
• Efeturar testes mais elaborados
Novos testes devem ser feitos envolvendo: mais fontes de dados; fonte de dados, por
exemplo um banco relacional, com mais de uma tabela; diferentes tipos de fontes de
dados, como por exemplo - orientada a objetos, planilhas, páginas Web, dados geográcos etc.; fontes com uma grande quantidade de dados; utilização de um número
maior de máquinas com mais recursos; implantação dos serviços desenvolvidos em
diferentes nós de um Grid pertencentes a outras instituições, de forma que se possa
ter uma Organização Virtual em escala global e com recursos mais poderosos. Além
disso, usar esta nova abordagem do CoDIMS em uma aplicação mais concreta do
mundo real;
• Novos wrappers
Para que se possa efetuar testes envolvendo diferentes tipos de fontes, será necessário
desenvolver wrappers para outros tipos de fontes de dados e implementá-los como
serviço Grid;
• Implementação do CoDIMS multi-usuário
Isso é possível pois, com a camada de Wrapper -Grid, diferentes instâncias de Wrappers-
Services podem ser criadas para diferentes usuários, o que possibilita uma independência em suas execuções. Assim, pode-se ter diferentes usuários executando
diferentes consultas ao mesmo tempo;
• Envio de Código de wrapper
Neste trabalho, para que todos os nós do Grid possam suportar todos os tipos de
Wrappers, é preciso implantar todos os Wrapper Services em todos os nós. Assim,
sempre que um novo serviço for criado, o mesmo terá que ser implantado em todos
95
os nós. Uma maneira de resolver isso seria, ao invés de ter os serviços implantados,
enviar uma classe Java que implementa o serviço, a partir do componente Acesso
aos Dados, ao nó no qual o mesmo será executando. Para que isso seja possível, é
necessário a criação de um modelo de alocação que indique qual o melhor nó para
alocar um serviço. Assim, ganha-se em independência de localização. Contudo,
testes devem ser feitos para vericar se esse envio não irá afetar o desempenho do
sistema, especialmente se estiver sendo considerado um CoDIMS multi-usuário e se
existem muitas realocações de instâncias de serviços;
• OGSA-DAI
Avaliar versões mais recentes do OGSA-DAI, vericando se os desaos apontados
por (ATKINSON, 2004) no capítulo 2, já foram incorporados ao mesmo. Em caso
positivo, analisar quais seriam as alterações a serem feitas neste trabalho de forma
a suportar o uso do OGSA-DAI. Isso é interessante pois, através do OGSA-DAI
muitas pesquisas têm sido realizadas e muitos problemas têm sido resolvidos dentro
do cenário de integração de dados. Além disso, é uma implementação de referência
do Global Grid Forum que suporta diversos tipos de fontes de dados como, por
exemplo: MySQL, Oracle, IBM DB2, PostgreSQL,Microsoft SQL Server dentre
outras.
• Globus Toolkit 4
Migrar da versão 3.2 para a versão 4.0 do Globus Toolkit, visando obter vantagens de
suas novas características, como por exemplo o padrão WSRF descrito no capítulo
3.
96
Referências
ABITEBOUL, S. et al. The lowell database research self assessment. May 2003.
Disponível em: <http://research.microsoft.com/~Gray/lowell/>. Acesso em: 25 abril
2005.
ALPDEMIR, N. et al. Ogsa-dqp: A service-based distributed query processor for the
grid. In: . UK e-Science All Hands Meeting Nottingham. EPSRC, 2003. Disponível em:
<http://twiki.mygrid.org.uk/twiki/pub/Mygrid/AllHands2003Local/114.pdf>. Acesso
em: 25 abril 2005.
ALPDEMIR, N. et al. Service-based distributed querying on the grid. In: 1st
International Conference on Service Oriented Computing (ISOC). [S.l.]: Springer Verlag,
2003. p. 467482.
ATKINSON, M. SPECIAL THEME: GRIDS THE NEXT GENERATION. october
2004. ERCIM - the European Research Consortium for Informatics and Mathematics.
Disponível em: <http://www.globus.org/alliance/publications/papers.php>. Acesso em:
25 abril 2005.
ATKINSON, M.; BAXTER, R.; HONG, N. Grid Data Access and Integration in OGSA.
2002. EPCC, University of Edinburgh. Disponível em: <http://www.cs.man.ac.uk/griddb/papers/OGSA-DAI-spec-1.2.pdf>. Acesso em: 25 abril 2005.
AYRES, F.; PORTO, F.; MELO, R. An Extensible Query Execution Engine for
Supporting New Query Execution Models. To appear in LNCS 2004.
BARBOSA, A. C. P. Middleware para Integração de Dados Heterogêneos Baseado em
Composição de Frameworks. Tese (Doutorado) PUC-Rio, Brasil, Maio 2001.
BARBOSA, A. C. P.; PORTO, F.; MELO, R. N. Congurable data integration
middleware system. J. Braz. Comp. Soc., v. 8, n. 2, p. 1219, 2002.
BERSTIS, V. Fundamentals of Grid Computing. Dec 2003. Redbooks. Disponível em:
<http://www.redbooks.ibm.com/redpapers/pdfs/redp3613.pdf>. Acesso em: 25 abril
2005.
BIANCARDI, C.; SILVESTRE, L. J.; BARBOSA, A. C. P. Integração de dados
heterogêneos em ambiente web. In: ESCOLA REGIONAL DE INFORMáTICA ERI. RJ/ES, 2004. Disponível em: <http://codims.lprm.inf.ufes.br/publicacoes.html>.
Acesso em: 25 abril 2005.
BIANCARDI, C.; SILVESTRE, L. J.; BARBOSA, A. C. P. A CoDIMS based proposal
for distribution and execution of wrappers in a grid environment. In: Proceedings of the
III Workshop on Computational Grids and Applications (WCGA 2005). [S.l.: s.n.], 2005.
In Portuguese.
97
BUYYA, R. Grid Computing Info Centre (GRID Infoware). 2002. Disponível em:
<http://www.gridcomputing.com/>. Acesso em: 25 abril 2005.
CIRNE, W.; NETO, E. S. Grids Computacionais: Da Computação de Alto Desempenho a
Serviços sob Demanda. 2005. Minicursos - Simpósio Brasileiro de Redes de Computadores
(SBRC). Disponível em: <http://walfredo.dsc.ufcg.edu.br/papers/SBRC.2005.v18.pdf>.
Acesso em: 25 abril 2005.
CONRAD, S. et al. Research issues in federated database systems: report of efdbs '97
workshop. SIGMOD Rec., ACM Press, v. 26, n. 4, p. 5456, 1997.
CZAJKOWSKI, K. et al. From open grid services infrastructure to ws-resource
framework: Refactoring & evolution. 2004. Global Grid Forum Draft Recommendation.
Disponível em: <http://www.globus.org/alliance/publications/papers.php>. Acesso em:
25 abril 2005.
DANTAS, M. A. R.; ALLEMAND, J. N. C.; PASSOS, L. B. C. An evaluation of globus
and legion software environments. In: International Conference on Computational
Science. [S.l.: s.n.], 2003. p. 963970.
FERREIRA, L. et al. Introduction to Grid Computing with Globus. dec 2002. Redbook.
Disponível em: <www.redbooks.ibm.com/redbooks/pdfs/sg246895.pdf>. Acesso em: 25
abril 2005.
FONTES, V. et al. CoDIMS-G: a data and program integration service for the grid. In:
Proceedings of the 2nd workshop on Middleware for grid computing. [S.l.]: ACM Press,
2004. p. 2934.
FOSTER, I. What is the Grid? A Three Point Checklist. jul 2002. Disponível em:
<http://www-fp.mcs.anl.gov/ foster/Articles/WhatIsTheGrid.pdf>. Acesso em: 25 abril
2005.
FOSTER, I.; GANNON, D. The Open Grid Services Architecture Platform. 2003. Disponível em: <Disponível em http://www.globalgridforum.org/Meetings/ggf7/drafts/draftggf-ogsa-platform-2.pdf>. Acesso em: 25 abril 2005.
FOSTER, I.; KESSELMAN, C. Globus: A metacomputing infrastructure toolkit. The
International Journal of Supercomputer Applications and High Performance Computing,
v. 11, n. 2, p. 115128, Summer 1997.
FOSTER, I.; KESSELMAN, C. The grid: Blueprint for a new computing infrastructure.
. San Francisco, CA, USA: MORGAN-KAUFMANN, 1999. cap. 11, p. 259278.
In:
FOSTER, I. et al. The physiology of the grid: An open grid services architecture for
distributed system integration. Open Grid Service Infrastructure WG, Global Grid Forum
-, june 2002. Disponível em: <www.globus.org/research/papers/ogsa.pdf>. Acesso em:
25 abril 2005.
FOSTER, I.; KESSELMAN, C.; TUECKE, S. The anatomy of the Grid: Enabling
scalable virtual organizations. Lecture Notes in Computer Science, v. 2150, 2001.
Disponível em: <www.globus.org/research/papers/anatomy.pdf>. Acesso em: 25 abril
2005.
98
GLOBAL Grid Forum. 2004. Disponível em: <http://www.gridforum.org/>. Acesso em:
25 abril 2005.
GLOBUS. The Globus Toolkit. 2004. Disponível em: <www.globus.org>. Acesso em: 25
abril 2005.
GOBLE, C.; ROURE, D. D. The grid: an application of the semantic web. SIGMOD
Rec., ACM Press, v. 31, n. 4, p. 6570, 2002.
GRIDFORUM. Database Access and Integration Services WG - DAIS-WG. 2004.
Disponível em: <https://forge.gridforum.org/projects/dais-wg>. Acesso em: 25 abril
2005.
HAAS, L. M.; MILLER, R. J.; AL., B. N. et. Transforming Heterogeneous
Data with Database Middleware: Beyond Integration. 1999. Disponível em:
<http://www.almaden.ibm.com/cs/garlic/debull99.ps>. Acesso em: 25 abril 2005.
HAKIMPOUR, F.; GEPPERT, A. Resolving semantic heterogeneity in schema
integration: an ontology based approach. In: Proceedings of the international conference
on Formal Ontology in Information Systems. USA: [s.n.], 2001. v. 2001, p. 297308.
HALEVY, A. Y. Data integration: A status report. In: Proceedings of 10th Conference
on Database Systems for Business Technology and the Web (BTW 2003). Germany:
[s.n.], 2003. p. 2429.
HASSELBRING, W. Information system integration. Commun. ACM, ACM Press,
v. 43, n. 6, p. 3238, 2000.
JAVACAMP. About Design Pattern. 2005. Disponível em:
<http://www.javacamp.org/designPattern/>. Acesso em: 25 abril 2005.
KIM, W. (Ed.). Modern database systems: the object model, interoperability, and beyond.
New York, NY, USA: ACM Press/Addison-Wesley Publishing Co., 1995.
LINTHICUM, D. S. Next Generation Middleware. 1997. Disponível em:
<http://www.dbmsmag.com/9709d14.html>. Acesso em: 25 abril 2005.
LITWIN, W.; MARK, L.; ROUSSOPOULOS, N. Interoperability of multiple autonomous
databases. ACM Comput. Surv., ACM Press, v. 22, n. 3, p. 267293, 1990.
MALAIKA, S.; EISENBERG, A.; MELTON, J. Standards for databases on the grid.
SIGMOD Rec., ACM Press, v. 32, n. 3, p. 92100, 2003.
MALIK, T. et al. Skyquery: A web service approach to federate databases. In: CIDR.
[s.n.], 2003. Disponível em: <http://www-db.cs.wisc.edu/cidr2003/program/p17.pdf>.
Acesso em: 25 abril 2005.
MANAGEMENT, E. S. A Java/UML Object-Oriented Design Tool. may 2005. Disponível
em: <http://codims.inf.ufes.br/sistIntDados.pdf>. Acesso em: 25 abril 2005.
MART, M. iguez; ROUSSOPOULOS i. MOCHA: A selfextensible database middleware system for distributed data sources. 2000. Disponível em:
<citeseer.ist.psu.edu/293006.html>. Acesso em: 06 set. 2004.
99
MIDDLEWARE Based On a Code SHipping Architecture (MOCHA). 2000. Disponível
em: <http://www.cs.umd.edu/projects/mocha/>. Acesso em: 03 dec. 2004.
MUNRO, C. Developing a C Client Toolkit for OGSA-DAI. Dissertação (Mestrado) University of Edinburgh, 2004. Disponível em:
<http://www.epcc.ed.ac.uk/msc/dissertations/dissertations-0304/1021818_12b1.1.pdf>. Acesso em: 25 abril 2005.
OBJECT Services and Consulting - Wrappers. 1997. Disponível em:
<http://www.objs.com/survey/wrap.htm>. Acesso em: 25 abril 2005.
OPEN Grid Services Architecture - Data Access and Integration - OGSA-DAI. 2004.
Disponível em: <http://www.ogsadai.org.uk>. Acesso em: 25 abril 2005.
OPEN Grid Services Architecture - Distributed Query Processor - OGSA-DPQ. 2004.
Disponível em: <http://www.ogsadai.org.uk/dqp/>. Acesso em: 25 abril 2005.
PINHEIRO, F. S. Incorporando uma máquina de execução de consultas ao CoDIMS.
Dec 2004. Monograa de Conclusão de Curso, Universidade Federal do Espírito Santo UFES.
PITOURA, E.; BUKHRES, O.; ELMAGARMID, A. Object orientation in multidatabase
systems. ACM Comput. Surv., ACM Press, v. 27, n. 2, p. 141195, 1995.
PORTO, F. et al. Codims: An adaptable middleware system for scientic visualization
in grids. Journal Concurrency and Computation: Practice and Experience, v. 16, n. 5, p.
515522, 2004.
QI, K. Data integration scenarios in OGSA-DAI. Dissertação
(Mestrado) University of Edinburgh, 2004. Disponível em:
<http://www.epcc.ed.ac.uk/msc/dissertations/dissertations-0304/2562964_12b1.2.pdf>. Acesso em: 25 abril 2005.
RAHM, E.; BERNSTEIN, P. A. A survey of approaches to automatic schema matching.
VLDB Journal: Very Large Data Bases, v. 10, n. 4, p. 334350, December 2001.
Disponível em: <citeseer.ist.psu.edu/rahm01survey.html>.
RODRIGUEZ-MARTINEZ, M.; ROUSSOPOULOS, N. Mocha: a self-extensible
database middleware system for distributed data sources. In: Proceedings of the 2000
ACM SIGMOD international conference on Management of data. [S.l.]: ACM Press,
2000. p. 213224.
RODRIGUEZ-MARTINEZ, M. et al. Mocha: A database middleware system featuring
automatic deployment of application-specic functionality. In: CHEN, W.; NAUGHTON,
J. F.; BERNSTEIN, P. A. (Ed.). Proceedings of the 2000 ACM SIGMOD International
Conference on Management of Data, May 16-18, 2000, Dallas, Texas, USA. [S.l.]: ACM,
2000. p. 594.
SHETH, A. P.; LARSON, J. A. Federated database systems for managing distributed,
heterogeneous, and autonomous databases. ACM Comput. Surv., ACM Press, v. 22, n. 3,
p. 183236, 1990.
100
SILBERSCHATZ, A.; ZDONIK, S. Database systems-breaking out of the box. SIGMOD
Rec., ACM Press, v. 26, n. 3, p. 3650, 1997.
SILVA, V. F. V. da et al. An adaptive parallel query processing middleware for the grid.
To appear in Concurrency and Computation: Practice and Experience (Special Issue),
16(5), 2004.
SILVESTRE, L. J.; BIANCARDI, C.; BARBOSA, A. C. P. Sistemas para Integração de
Dados Heterogêneos. 2004. Disponível em: <http://codims.inf.ufes.br/sistIntDados.pdf>.
Acesso em: 25 abril 2005.
SMITH, J. et al. Distributed query processing on the grid. In: Proceedings of the Third
International Workshop on Grid Computing. [S.l.]: Springer-Verlag, 2002. p. 279290.
SOTOMAYOR, B. The Globus Toolkit 3 Programmer's Tutorial. Dez 2003. Tutorial.
Disponível em: <http://gdp.globus.org/gt3-tutorial/>. Acesso em: 25 abril 2005.
THOMAS, G. et al. Heterogeneous distributed database systems for production use.
ACM Comput. Surv., ACM Press, v. 22, n. 3, p. 237266, 1990.
TREVISOL, G. G. CoDIMS: Incorporando Nova Abordagem na Comunicação entre seus
Componentes. June 2004. Monograa de Conclusão de Curso, Universidade Federal do
Espírito Santo - UFES.
WIEDERHOLD, G. Value-added Middleware: Mediators. 1998. Disponível em:
<http://www-db.stanford.edu/pub/gio/1998/dbpd.html>. Acesso em: 25 abril 2005.
WIEDERHOLD, G. Mediation to deal with heterogeneous data sources. v. 1580, 1999.
WIEDERHOLD, G.; GENESERETH, M. The conceptual basis for mediation services.
IEEE Expert, v. 12, n. 5, p. 3847, Sep/Oct 1997.
ZIEGLER, P.; DITTRICH, K. R. Three decades of data integration - all problems
solved? In: JACQUART, R. (Ed.). 18th IFIP World Computer Congress (WCC 2004),
Volume 12, Building the Information Society. Toulouse, France, August 22-27: Kluwer,
2004. (IFIP International Federation for Information Processing, v. 156), p. 312.
ÖZSU, M. T.; VALDURIEZ, P. Princípios de Sistemas de Banco de Dados Distribuídos.
Rio de Janeiro - RJ: Editora Campus, 2001.