integração de dados usando ogsa-dai

CENTRO UNIVERSITÁRIO DE VILA VELHA
CURSO DE CIÊNCIA DA COMPUTAÇÃO
INTEGRAÇÃO DE DADOS
USANDO OGSA-DAI
Elmo Laurenzoni Neto
Leonardo de Medeiros Magalhães
Lucas Calvi Costa
Monografia desenvolvida durante a disciplina de Trabalho
de Conclusão de Curso apresentada ao Curso de Ciência
da Computação do Centro Universitário de Vila Velha,
como requisito parcial para a obtenção do título de
Bacharel em Ciência da Computação, sob orientação do
prof. Cristiano Biancardi.
Vila Velha, Junho de 2008
2
ELMO LAURENZONI NETO
LEONARDO DE MEDEIROS MAGALHÃES
LUCAS CALVI COSTA
Integração de dados Usando OGSA-DAI
Monografia do Trabalho de Conclusão de Curso de Graduação em Ciência da Computação
apresentada ao Centro Universitário Vila Velha, como requisito parcial para a obtenção do título de
Bacharel em Ciência da Computação.
Aprovada em ____ de ___________________ de 2008.
COMISSÃO EXAMINADORA
_________________________________________
Prof. Cristiano Biancardi
Mestre em Informática.
Centro Universitário de Vila Velha
Orientador
_________________________________________
Prof. Otacílio Pereira José Pereira
Mestre em Informática.
Centro Universitário de Vila Velha
_________________________________________
Prof. Vinícius Rosalen
Mestre em Ciência da Computação.
Centro Universitário de Vila Velha
3
“Houve um tempo em que se fazia ciência a partir de
quatro elementos: Água, Terra, Fogo e Ar. Naquele tempo
não se sabia que podia fazer qualquer coisa com apenas
dois: Vontade e Determinação.”
<Autor Desconhecido>
4
Dedicamos esse trabalho aos nossos pais, pois sem eles,
nada disso seria possível.
5
AGRADECIMENTOS
Agradecemos aos nossos Pais, pelo apoio e paciência dispensados, por estarem presentes
quando necessitamos e por acreditar em nosso trabalho e potencial.
Ao apoio dos nossos colegas de sala, que sempre nos ajudaram, seja pela troca de
conhecimentos ou pela imensa ajuda na hora das maiores dificuldades.
Ao nosso orientador pela oportunidade concedida, pelo seu apoio e pela suas contribuições
que foram fundamentais para a conclusão desse trabalho.
As nossas namoradas Juliana e Gabriella pela compreensão de não estarmos presentes em
determinados momentos, pelo companheirismo e principalmente pelas ajudas prestadas
para finalizarmos esse trabalho.
A todos aqueles que de alguma forma contribuíram para completar o nosso objetivo.
Por fim, agradecemos principalmente a Deus, por nos dar força para superar as barreiras
que nos impediam e alcançar o nosso objetivo.
RESUMO
Integração de dados promove a junção de dados através de um aplicativo liberando o
usuário da necessidade de integrar dados manualmente. Isto é importante porque,
atualmente, a quantidade de dados disponíveis está cada vez maior sendo necessário
o uso de um sistema capaz de realizar essa integração. Recentemente, ambiente de
Grid tem se mostrado como uma boa alternativa para a utilização, de forma segura,
coordenada, eficiente e transparente, de recursos computacionais geograficamente
dispersos. No que diz respeito à integração de dados em ambiente de Grid tem-se o
OGSA-DAI, um middleware que assiste ao acesso e à integração de dados a partir de
fontes de dados separadas via ambiente de Grid. Neste contexto, este trabalho
apresenta um estudo sobre o middleware OGSA-DAI. Para tanto, o presente trabalho
apresenta uma investigação da arquitetura do OGSA-DAI e a descrição de uma
aplicação para promover a integração de dados de dois Bancos de Dados distintos.
Palavras-chave: Integração de dados; Grid; OGSA-DAI.
7
ABSTRACT
Data integration promotes data junction using a middleware system, freeing the user
from the need to integrate data manually. This is important because nowadays the
amount of data available is getting bigger and bigger, being necessary the use of a
system that is capable of performing this integration. Recently, grid environment has
shown as a good alternative for a safe, coordinate, efficient and transparent way to use
geographically dispersed computational resources. In the matter of data integration
using grid environment we have the OGSA-DAI, a middleware that assists in the data
integration from data sources separated through a grid environment. In this context,
this work presents a study on the middleware OGSA-DAI. To demonstrate its use, the
following work presents an investigation of the OGSA-DAI architecture and the
description of an application to promote the data integration between two different Data
Bases.
Key-words: Integration of data; Grid; OGSA-DAI.
8
LISTA DE FIGURAS
Figura 01 – Middleware para Integração de dados. .................................................... 19
Figura 02 – Wrappers. ................................................................................................ 21
Figura 03 – ConFiguração Básica do CoDINS ............................................................ 32
Figura 04 – O CoDINS e seus Componentes Básicos ................................................ 33
Figura 05 – Arquitetura do CoDINS-G ........................................................................ 34
Figura 06 – Arquitetura do MOCHA ............................................................................ 35
Figura 07 – Arquitetura do OGSA-DPQ ...................................................................... 36
Figura 08 – Interação entre os frameworks OGSA-DPQ e OGSA-DAI. ....................... 37
Figura 09 – Funcionamento do OGSA-DAI. ................................................................ 38
Figura 10 – Arquitetura do OGSA-DAI. ....................................................................... 40
Figura 11 – Data Service Resourse ............................................................................ 41
Figura 12 – Documento de desempenho contendo elemento de sessão (session
element), elemento de atividade (activity element) e um ponto final (end-point). ........ 44
Figura 13 – Exemplo de documento de desempenho. ................................................ 45
Figura 14 – Documento de resposta resultante do documento de desempenho. ........ 45
Figura 15 – Exemplo de Documento de Desempenho enviado de forma Síncrona..... 46
Figura 16 – Documento de resposta contendo os dados resultantes. ......................... 46
Figura 17 – Interação usando uma interface orientada a documentos. ....................... 47
Figura 18 – Exemplo de Entrega de dados. ................................................................ 48
Figura 19 – Resourse File. .......................................................................................... 49
Figura 20 – Consulta realizada pelo Cliente. ............................................................... 50
Figura 21 – Servidor Proxy do OGSA-DAI .................................................................. 51
Figura 22 – DataRequestExecutionResource ............................................................. 51
Figura 23 – SQL Query ............................................................................................... 52
Figura 24 – TupleToWebRowSetCharArrays .............................................................. 52
Figura 25 – CharArraysResize .................................................................................... 53
Figura 26 – DeliverToRequestStatus .......................................................................... 53
9
Figura 27 – Recursos.................................................................................................. 54
Figura 28 – Recursos Passados como Parâmetros .................................................... 54
Figura 29 – Pedido Entregue ao Cliente ..................................................................... 54
Figura 30 – Pedido Disponível .................................................................................... 54
Figura 31 – sqlBag ...................................................................................................... 55
Figura 32 – Consulta realizada pelo sqlBag ................................................................ 55
Figura 33 – Atividade TupleToWebRowSetCharArrays............................................... 56
Figura 34 – TupleToWebRowSetCharArrays.nextResult ............................................ 56
Figura 35 – sqlUpdateStatement ................................................................................ 57
Figura 36 – sqlParameter ........................................................................................... 58
Figura 37 – Esquema da Fonte Relacional “littleblackbook” da Matriz ........................ 60
Figura 38 – Esquema da fonte Relacional “littleblackbook” da Filial. ........................... 61
Figura 39 – Consulta na linguagem SQL. ................................................................... 61
Figura 40 – Diagrama de Implantação ........................................................................ 61
Figura 41 – SQLServer ............................................................................................... 62
Figura 42 – OracleSQL ............................................................................................... 63
Figura 43 – Modelo de grupo de fonte de dados ......................................................... 63
Figura 44 – Modelo de consulta .................................................................................. 64
Figura 45 – Local onde se localiza os driver dos BD’s no OGSA-DAI ......................... 74
Figura 46 – Classpath ................................................................................................. 74
Figura 47 – Comando para criar uma base de dados ................................................. 75
Figura 48 – Comando a ser executado caso o serviço de implementação falhar ........ 75
Figura 49 – Consulta a uma fonte de dados ............................................................... 76
Figura 50 – Comando usado para configurar um servidor .......................................... 76
Figura 51 – MySQLDataResource TupleToWebRowSetCharArrays ........................... 77
Figura 52 – PipelineWorkflow ..................................................................................... 78
Figura 53 – DataRequestExecutionResource ............................................................. 79
Figura 54 – DeliverToRequestStatus .......................................................................... 79
Figura 55 – RequestStatus ......................................................................................... 80
10
Figura 56 – RequestStatus Completo ......................................................................... 80
Figura 57 – Método Principal ...................................................................................... 80
Figura 58 – TupleToWebRowSetCharArrays .............................................................. 81
Figura 59 – Strings Pad .............................................................................................. 81
Figura 60 – TupleToWebRowSetCharArrays Completo .............................................. 82
Figura 61 – Código Completo ..................................................................................... 84
11
LISTA DE TABELAS
Tabela 1 – Tecnologias Suportadas pelo OGSA-DAI .................................................. 38
Tabela 2 – Assessores de dados Fornecidos pelo OGSA-DAI.................................... 46
Tabela 3 – Resultado da Consulta da Matriz (MySQL) ............................................... 65
Tabela 4 – Resultado da Consulta da Filial (Oracle) ................................................... 66
Tabela 5 – Resultado Integrado .................................................................................. 66
Tabela 6 – Drivers de Banco de Dados ...................................................................... 73
Tabela 7 – URI’s de Banco de Dados ......................................................................... 73
12
LISTA DE ABREVIAÇÕES E SIGLAS
API
Application Programming Interface
BD
Banco de Dados
CoDIMS
ConFigurable Data Integration Middleware System
CORBA
Commom Object Request Broker Arquitecture
DAP
Data Access Provider
DB
DataBase
DBA
DataBase Administrator
DBMS
Database Management System
DRER
Data Request Execution Resource
EJB
Enterprise JavaBeans
ERE
Entidade Relacionamento Estendido
GT
Globus Tookit
JDBC
Java Database Connectivity
MOCHA
Middleware Based on a Code Shipping Architecture
OGSA
Open Grid Service Architecture
OGSA-DAI
Open Grid Service Architecture - Data Access and Integration
OGSA-DPQ
Open Grid Service Architecture - Distributed Query Processor
QPC
Query Processing Coordinator
SGBD
Sistema de Gerenciamento de Banco de Dados
SOAP
Service Oriented Architecture Protocol
SQL
Structured Query Language
WSI
Web Services Inter-Operability
WSRF
Web Services Resourses Framework
XML
eXtensible Markup Language
XLS
eXtensible Stylesheet Language
13
SUMÁRIO
1. INTRODUÇÃO........................................................................................................ 16
1.1. Objetivo ............................................................................................................................ 16
1.1.1 Geral ........................................................................................................................... 16
1.1.1 Específico.................................................................................................................... 16
1.2. Organização do Trabalho ................................................................................................. 17
2. CONCEITOS E TECNOLOGIAS............................................................................. 18
2.1. Integração de Dados......................................................................................................... 18
2.1.1. Introdução ................................................................................................................. 18
2.1.2. Middleware para Integração de Dados ..................................................................... 19
2.1.3. Wrappers................................................................................................................... 20
2.1.4. Principais Dificuldades para Integração .................................................................... 21
2.1.5. Conflitos para Integração .......................................................................................... 21
2.1.6. Tipos de Esquema ..................................................................................................... 22
2.1.7. Vantagens e Desvantagens ....................................................................................... 23
2.2. Computação Distribuída ................................................................................................... 24
2.2.1. Definição ................................................................................................................... 24
2.2.2. Cluster ....................................................................................................................... 24
2.3. Grid ................................................................................................................................... 24
2.3.1. Visão Geral ................................................................................................................ 24
2.3.2. Características ........................................................................................................... 26
2.3.3. Benefícios .................................................................................................................. 26
2.3.4. Grid VS Computação Distribuída ............................................................................... 29
2.3.5. Grid VS Cluster .......................................................................................................... 30
3. TRABALHOS RELACIONADOS ............................................................................. 31
3.1. Introdução ........................................................................................................................ 31
3.2. CoDIMS ............................................................................................................................. 31
3.2.1. CoDIMS-G .................................................................................................................. 33
14
3.3. Mocha............................................................................................................................... 35
3.4. OGSA-DPQ ........................................................................................................................ 36
4. OPEN GRID SERVICE ARCHITECTURE – DATA AND INTEGRATION ................ 38
4.1. Introdução ........................................................................................................................ 38
4.2. Arquitetura do OGSA-DAI ................................................................................................. 39
4.2.1. Camada de Dados...................................................................................................... 40
4.2.2. Interface entre a Camada de Dados e a Camada Lógica de Negócios ...................... 40
4.2.3. Camada Lógica de Negócios ...................................................................................... 41
4.2.4. Interface entre a Camada de Lógica de Negócios e a Camada de Aplicação............ 42
4.2.5. Camada de Apresentação ......................................................................................... 43
4.2.6. Camada de Cliente .................................................................................................... 43
4.3. Serviços de Dados............................................................................................................. 43
4.3.1. Operações Usando Dados ......................................................................................... 44
4.4. Recursos de Serviços de Dados ........................................................................................ 46
4.5. Assessor de Recursos de Dados ....................................................................................... 47
4.6. Relacionamento ............................................................................................................... 47
4.7. Especificação Funcional .................................................................................................... 48
4.7.1. Representando uma Fonte de Dados........................................................................ 48
4.7.2. Fluxograma de Execução ........................................................................................... 50
4.8. Modificando um Banco de Dados .................................................................................... 57
4.9. Vantagens ......................................................................................................................... 58
4.10. Desvantagens ................................................................................................................. 59
5. ESTUDO DE CASO ................................................................................................ 60
5.1. Descrição da Aplicação ..................................................................................................... 60
5.2. Resourse File dos Bancos de Dados .................................................................................. 62
5.3. Criando um Grupo de Fonte de Dados ............................................................................. 63
5.4. Criando Uma Consulta...................................................................................................... 64
5.5. Resultado da Consulta ...................................................................................................... 65
15
6. CONCLUSÕES....................................................................................................... 68
REFERÊNCIAS BIBLIOGRÁFICAS ............................................................................ 69
ANEXO A – MANUAL DE INSTRUÇÃO DO OGSA-DAI ............................................. 72
ANEXO B – WORKFLOWS ........................................................................................ 78
ANEXO C – CÓDIGO COMPLETO ............................................................................ 84
ANEXO D – Perguntas e Respostas ........................................................................... 94
16
1. INTRODUÇÃO
Atualmente
está
disponível
um
grande
volume
de
dados,
essencialmente
heterogêneos e distribuídos, devido principalmente à disseminação da Internet e ao
desenvolvimento das redes de alta velocidade. Neste contexto a heterogeneidade se
manifesta sob diferentes formas, tais como: diferentes sistemas operacionais, modelos
de dados (modelo de entidade-relacionamento OO, XML, etc.), servidores de dados,
sistemas de comunicação e hardware. Assim, cresce o número de aplicações que
demandam acesso a tais dados através de uma visão integrada, uniforme e
homogênea, em um tempo cada vez menor.
Com um grande aumento de sistema informatizado espalhados pelo mundo a
integração de dados tem ficado cada vez mais necessária, e conseqüentemente a
implementação de sistemas capazes de tal interação. Assim, é importante conseguir
combinar banco de dados e tecnologias relacionadas para incrementar o uso da
informação.
Recentemente, o ambiente de Grid tem se mostrado como uma boa alternativa para a
utilização, de forma segura, coordenada, eficiente e transparente, de recursos
computacionais geograficamente dispersos.
No que diz respeito à integração de dados em ambiente de Grid tem-se o OGSA-DAI,
que é um middleware que assiste no acesso e na integração de dados a partir de
fontes de dados separadas via ambiente de Grid. Este middleware também concede
ao usuário a facilidade da utilização de serviços web para se comunicar com bancos
de dados espalhados pelo mundo.
1.1.
Objetivos
1.1.1. Geral
O objetivo deste projeto é o estudo do middleware OGSA-DAI e o desenvolvimento de
uma aplicação para integração de dados heterogêneos e distribuídos usando essa
tecnologia.
1.1.2. Específico
•
Estudo do ambiente Grid e integração de dados
•
Investigação da arquitetura do OGSA-DAI e como é feita a integração de dados
do mesmo
•
Configuração e Instalação do OGSA-DAI
•
Análise, projeto e implementação em um estudo de caso usando OGSA-DAI.
17
1.2.
Organização do Trabalho
No capítulo 2 são apresentados alguns conceitos e tecnologias estudadas para a
realização desse estudo, como por exemplo: Integração de Dados, Computação
Distribuída, Cluster, Grid;
No capítulo 3 são apresentados alguns trabalhos sobre integração de dados
heterogêneos e distribuídos, relacionados com o presente trabalho;
O capítulo 4 apresenta o estudo da tecnologia OGSA-DAI, incluindo sua coleção de
componentes para a manipulação de dados e sua coleção de ferramentas para
desenvolver aplicações de clientes.
No capítulo 5 é apresentado o estudo de caso;
No capítulo 6 apresenta a conclusão desse trabalho.
18
2. CONCEITOS E TECNOLOGIAS
Esse capítulo tem como objetivo mostrar o conceito, as vantagem e desvantagens do
uso da integração de dados.
2.1.
Integração de Dados
2.1.1. Introdução
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]. Para tanto, sistemas de integração de dados vêm
sendo desenvolvidos com a finalidade de integrar um grande número de fontes de
dados heterogêneas, desenvolvidas independentemente. O objetivo maior desses
sistemas é liberar o usuário de ter que localizar as fontes de dados, interagir com cada
uma isoladamente e combinar os dados das múltiplas fontes de dados manualmente
[HAKIMPOUR; GEPPERT, 2001; HALEVY, 2003].
Para gerenciar dados em múltiplos bancos de dados, é necessário lidar com a
distribuição dos SGBDs. O acesso integrado a bases de dados distribuídas e
heterogêneas é um dos grandes problemas encontrados pelas organizações, sendo
um dos grandes problemas também na comunidade de banco de dados. Para
proporcionar interoperabilidade entre sistemas heterogêneos, deve-se estabelecer
uma visão global e uniforme para dados e serviços [KALINICHENKO, 1999].
A integração de um modelo global e a adição de uma camada de software são umas
das técnicas utilizadas para integrar a base de dados distribuídos. No primeiro caso, a
definição do modelo conceitual global é realizada através da comparação entre
modelos conceituais locais, identificação de equivalência, identificação e resolução de
conflitos [MÁRCIO PICOSSI SCHNEIDER, 2004]. Já no segundo caso, uma camada
de software providencia a integração a partir da definição de regras entre os
participantes. Esta camada é muitas vezes citada como mediador, e também tem a
finalidade de fundir as informações de fontes de dados heterogêneas removendo
redundâncias e resolvendo inconsistências [PAPAKONSTANTINOU, ABITEBOUL,
1996].
19
2.1.2. Middleware para Integração de Dados
Middleware é um componente de software que tem a finalidade 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]. É uma designação genérica utilizada para se referir ao software
que é executado entre os usuários e o servidor em um sistema de banco de dados
cliente/servidor [JAKOBOVITS, 1997].
Um middleware também pode ser definido como uma camada existente entre o
cliente, a rede, os sistemas operacionais e dos possíveis servidores de recurso, mais
focalizado em servidores de dados.
É constituído, na maioria das vezes, por módulos que possuem APIs de alto nível,
proporcionando a sua integração com sistemas desenvolvidos em diversas linguagens
de programação e APIs de baixo nível, permitindo a independência relativa ao
dispositivo. Seu objetivo é ocultar a heterogeneidade e fornecer um modelo de
programação mais produtivo para os programadores de aplicativos. É composto por
um
conjunto
de
processos
em
um
determinado
grupo
de
computadores,
implementando uma comunicação e oferecendo suporte para compartilhamento de
recursos aos aplicativos distribuídos.
O objetivo de um middleware para integração de dados (Figura 1) é fornecer
informação integrada 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].
Figura 1 – Middleware para Integração de dados
20
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 definidos os esquemas externos, visões, sobre o esquema global,
para atender às necessidades de um grupo específico de usuários ou de aplicações,
ou ainda, por razões de controle de acesso. Para efetuar a tradução entre modelos,
esquema externo para esquema local, são utilizados os wrappers que são os W1, W2,
W3 e Wn na Figura 1 [BIANCARDI, 2005].
2.1.3. 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 [BIANCARDI, SILVERSTRE, BARBOSA, 2005].
Um Wrapper encapsula uma única fonte de dados para que ela possa ser utilizada de
maneira mais conveniente. Através do uso de Wrappers, pode-se transformar uma
fonte de dados em uma forma mais estruturada (BARBOSA, 2001). Os Wappers são
utilizados para apresentar uma interface simples e funcional de uma interface interna
de um banco de dados.
Na Figura 2 são exibidas três fontes de dados, XML, Relacional e Orientado a Objeto
(OO), e utilizado um modelo Global (Relacional) como sendo uma fonte principal, logo
os wappers tem o papel de converter os bancos de dados XML, bancos orientados a
objetos (OO) e fontes de dados relacionais para que possa ser realizada a integração
de dados.
21
Figura 2 – Wrappers
Para realizar a seleção de um Wrapper, 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 [BIANCARDI, 2005].
2.1.4. Principais Dificuldades Para Integração
•
Integrar dados de diferentes SGBDs;
•
Integrar dados que possuem diferentes modelos de banco de dados
(relacional, hierárquico, Objeto-Relacional...);
•
Criar algoritmos que sejam compatíveis na realização de consultas, transações
atualizações e até exclusões nos SGBDs;
•
O sistema requer que exista pelo menos um usuário para gerenciar o sistema,
pois este não pode ser totalmente automatizado, para corrigir problemas no
processo de integração.
2.1.5. Conflitos para Integração
Quando comparamos esquemas de dados heterogêneos irá ocorrer conflito em
esquemas locais. Esses conflitos devem ser tratados durante a integração dos
esquemas ou integração de visões [HEPNER, 1995].
Diferentes nomes podem ser usados para mesma entidade ou entidades diferentes
podem possuir o mesmo nome. A mesma entidade pode ser representada através de
22
diferentes estruturas de atributos ou alguns atributos podem não ser representados.
Entidades podem ser representadas por tabelas em um banco de dados e podem ser
representadas como atributos em outro. Tipos diferentes de dados são atribuídos a
atributos semanticamente equivalentes. Conflitos de escalas ocorrem quando
unidades métricas diferentes são utilizadas em cada sistema, ou diferentes níveis de
precisão são usados. [JAKOBOVITS, 1997].
Em simples integrações de bancos de dados, os conflitos podem ser resolvidos pelo
usuário ou pelo programador envolvido na integração. Para sistemas fortemente
acoplados, os sistemas de integração possuiriam um mapeamento de nomes, tipos,
valores e etc., para que as entidades possam ser representadas ou vistas da mesma
maneira [HEPNER, 1995].
2.1.6. Tipos de Integração
A seguir serão mostrados os três tipos de esquemas considerados no cenário de
integração de dados: Esquema global, esquema de exportação e esquema local.
No esquema global existe somente um único esquema que é utilizado para
manipulação dos dados. Este é gerado a partir dos esquemas semânticos de cada
sistema participante. Sua principal vantagem é o fato do usuário conhecer apenas o
esquema global, e não os outros diversos esquemas. A integração via esquema global
é baseada na integração completa dos esquemas de exportação dos vários bancos de
dados com o objetivo de fornecer uma única visão do banco de dados heterogêneo.
[SCHNEIDER, 2004]. Um esquema exportação representa o subconjunto do esquema
componente que será compartilhado na federação, que significa serviços formados em
grupos. Um banco de dados não precisa disponibilizar para a federação e seus
usuários a sua coleção completa de dados. Além disso, este esquema inclui
informações para controle de acesso relativo a sua acessibilidade para usuários
específicos da federação. Em um esquema local representa o esquema conceitual de
uma fonte de dados componente. Este esquema representa o modelo de dados nativo
do componente, que pode ser um banco de dados relacional, banco de dados
orientado a objetos, arquivo XML, página HTML, entre outros. Portanto, os esquemas
locais componentes da federação podem ser representados seguindo diferentes
modelos de dados. Pode-se disponibilizar um esquema global geral, ou vários
esquemas globais parciais (views) de acordo com as necessidades dos vários
usuários.
Integração de esquemas via bancos de dados federados não precisa ser total, e
depende das necessidades dos usuários. Semelhante à integração via esquema
23
global com a utilização de diversas views sobre o conjunto de dados integrados, mas
cada banco de dados participante tem que conhecer todos os demais. Os bancos de
dados federados podem ser fortemente ou fracamente acoplados, onde o primeiro é
adequado para sistemas que têm por objetivo a leitura e a atualização dos dados, e o
outro é adequado para sistemas que têm por objetivo a leitura dos dados
[SCHNEIDER,2004].
2.1.7. Vantagens e Desvantagens
As principais vantagens do uso de integração de dados são [MOTRO, BUNEMAN,
1981]:
•
Os usuários possuem uma visão exclusiva dos dados integrados;
•
Integram diversas fontes de dados sem que haja a necessidade de modificação
das plataformas tecnológicas existentes;
•
Possibilidade de ampliar a visão da empresa para planejar, analisar e informar,
realizando o cruzamento de dados para extração de informações relevantes,
usando-as para tomar decisões;
•
Possibilita acessar a base de dados e gerar relatórios específicos do negócio; e
•
Promove a melhoria da qualidade dos dados com a padronização, garantindo a
qualidade dos produtos e atendendo as expectativas dos consumidores.
As principais desvantagens são [MOTRO, BUNEMAN, 1981]:
•
A geração de um novo esquema global integrado geralmente altera a
semântica dos atributos e tabelas, portanto após a integração pode ser
necessário alterar os softwares que utilizam o banco de dados, para que estes
possam acessar o novo esquema integrado. Uma solução para este problema
pode ser obtida através de visões e renomeações de atributos e tabelas.
•
Diversos métodos de integração existem para mais de dois bancos de dados:
combinação dois a dois, combinação de todos de uma só vez, entre outros, e
cada método pode definir esquemas globais completamente diferentes
24
2.2.
Computação Distribuída
2.2.1. Definição
Um sistema distribuído é uma coleção de computadores independentes que se
apresenta ao usuário como um sistema único e consistente [TANENBAUM].
Assim, a computação distribuída consiste em adicionar o poder computacional de
diversos computadores interligados por uma rede de computadores ou mais de um
processador trabalhando em conjunto no mesmo computador, para processar
colaborativamente determinada tarefa de forma coerente e transparente, ou seja,
como se apenas um único e centralizado computador estivesse executando a tarefa. A
união desses diversos computadores com o objetivo de compartilhar a execução de
tarefas, é conhecida como sistema distribuído.
2.2.2. Cluster
Um ambiente cluster é formado por um conjunto de computadores, que utiliza-se de
um tipo especial de sistema operacional classificado como sistema distribuido. É
construído muitas vezes a partir de computadores convencionais, sendo que estes
vários computadores são ligados em rede e comunicam-se através do sistema de
forma que trabalham como se fosse uma única máquina de grande porte. Há diversos
tipos de cluster. Um tipo famoso é o cluster da classe Beowulf, constituido por diversos
nós escravos gerenciados por um só computador [BIANCARDI, 2005].
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
[BIANCARDI, 2005].
2.2.3. GRID
2.2.3.1.
Visão Geral
Um Grid pode ser definido de maneira bem abrangente como uma infra-estrutura de
software capaz de interligar e gerenciar diversos recursos computacionais [FOSTER;
KESSELMAN, 2003], distribuídos por uma área geográfica grande, oferecendo ao
usuário, de forma confiável e econômica, o acesso transparente a tais recursos
25
independente de sua localização. Nesse sentido, a tecnologia de Grid visa fornecer o
acesso compartilhado a recursos de computação, de uma maneira que 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 flexí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. Considerando 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
[BIANCARDI, 2005].
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
geograficamente. Mais recentemente, têm-se os recursos de dados, como por
exemplo, os bancos de dados.
Um ambiente Grid deve conter três pontos recomendados [CAMPOS JR, ALVES,
HIRA, ZUFFO]:
•
Coordenação de Recursos não subordinados a um controle centralizado: Um
ambiente de Grid deve coordenar recursos e usuários pertencentes a domínios
distintos;
•
Utilização de interfaces e protocolos com padrões e abertos: Devido os
propósitos das grades computacionais, a utilização de padrões abertos é trivial
para permitir a interoperabilidade com outros sistemas já existentes;
•
Distribuição de qualidade de serviço não trivial: Um ambiente de grade
computacional possibilita o uso coordenado de seus recursos, garantindo a
qualidade de acesso ao mesmo.
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
26
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.
2.2.3.2.
Características
Segundo [GOLDCHLEGER, 2004], podemos citar os seguintes aspectos relacionados
ao Grid:
•
Não substituem sistemas operacionais - Os sistemas de computação em Grid
podem utilizar serviços do sistema operacional, porém são estruturados como
um middleware que provê serviços para os usuários e aplicações do Grid;
•
Podem integrar recursos distribuídos e descentralizados - a maioria dos
sistemas de computação em Grid é capaz de integrar recursos dispersos por
múltiplos domínios administrativos e conectados por redes de grande área.
Essa característica separa os sistemas em Grid dos sistemas em Cluster, uma
vez que estes últimos normalmente são capazes de integrar recursos em
apenas um domínio administrativo;
•
Podem ser utilizados por diversas aplicações - a maioria dos sistemas de
computação em Grid provê serviços que podem ser utilizados por diversas
aplicações, caracterizando uma arquitetura reutilizável;
•
Podem incluir várias plataformas de hardware e software - a maioria dos
sistemas de Computação em Grid pode integrar recursos heterogêneos,
compostos por diversas plataformas de hardware e software. Para tal,
entretanto, o sistema de Computação em Grid deve incluir mecanismos que
lidem com a diversidade de tais plataformas;
•
Adaptabilidade às políticas locais - apesar de integrarem recursos dispersos
por vários domínios administrativos, os sistemas de computação em Grid
devem se adaptar às políticas e restrições de uso de cada um destes domínios.
Por exemplo, é comum o cenário onde o administrador do domínio, apesar de
compartilhar os recursos com outros domínios, deseja priorizar os usuários
locais. Proprietários de estações de trabalho, por exemplo, não aceitam que o
desempenho de suas aplicações sofra devido às aplicações em Grid que
executam em seus recursos.
2.2.3.3.
Benefícios
Segundo [BERSTIS, 2003], os benefícios que o Grid possui são os seguintes:
27
•
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ção 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íficos avançados como um microscópio eletrônico ou um robô. Com isso,
os recursos de uma instituição ou empresa podem ser melhor utilizado,
diminuindo despesas e aumentando a eficiê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íficas, financeiras, 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
fixo de partes independentes, isso torna-se uma barreira que impede sua
escalabilidade. Outra forma de problema encontrado é quando as partes não
28
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 definida 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.
Dentro deste contexto, um Grid poderá, por exemplo, permitir o acesso remoto
a instrumentos científicos altamente especializados e caros. Por exemplo, um
cientista no laboratório A poderá manipular remotamente um telescópio
presente no laboratório B, e receber as imagens captadas através da rede.
Opcionalmente, ele poderá, de maneira transparente, armazenar as imagens
nos equipamentos de grande capacidade do instituto C e, caso necessário,
processar as imagens nos computadores disponíveis nas três instituições.
Também é possível vislumbrar experimentos colaborativos, onde diversos
cientistas
espalhados
por
várias
instituições
colaboram
para realizar
experimentos e simulações. Na indústria, além da possibilidade de se utilizar a
capacidade ociosa de centenas de estações de trabalho já existentes, os Grids
poderão permitir novas formas de colaboração entre os funcionários
espalhados por diversas filiais, por exemplo.
•
Confiabilidade - Existem diversas maneiras de aumentar a confiabilidade em
um sistema computacional. Processadores e discos são duplicados, de modo
29
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 confiança em um sistema,
mas seus altos 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.
2.2.3.4.
GRID VS Computação Distribuída
Computação em grade é um caso em particular da computação distribuída, já que são
orientadas para grandes aplicações, seja com enorme quantidade de dados
transmitidos ou com uma grande capacidade de cálculos, ou ambas. Com a evolução
da tecnologia de Grid, criava a oportunidade de se oferecer serviços sob demanda,
surgindo a idéia de um Grid onde seria possível dispor qualquer serviço computacional
sob demanda. 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 compartilhado de forma confiá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 e EJB, 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 baseados 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
30
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].
2.2.3.5.
GRID VS Cluster
A diferença principal 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 geograficamente, 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 objetivo de esclarecer a definição de Grid, já que se confunde com o significado
real de Grid, foi elaborado um Grid CheckList por Foster [FOSTER, 2002] , onde são
definidas três características básicas, onde pode ser definido se um sistema
computacional pode 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), disponibilidade, 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
é significativamente maior que a soma das partes.
31
3. TRABALHOS RELACIONADOS
3.1.
Introdução
Na literatura da área, são encontrados vários sistemas tentando resolver o problema
de integração de dados. Dentre os trabalhos que mais se relacionam com o tema do
presente trabalho, podemos citar o CoDIMS, MOCHA e o OGSA-DPQ. A seguir, esses
mesmos serão descritos.
3.2.
CoDIMS (ConFigurable Data integration Middleware Systen)
Com o grande aumento de sistemas informatizados espalhados pelo mundo, a
integração de dados tem ficado cada fez mais difícil de ser realizada, sendo cada vez
mais necessária a implementação de sistemas capazes de integrar dados
heterogêneos. O Sistema CoDIMS, tem por objetivo, resolver tal problema de
integração de dados em um ambiente flexível e configurável, permitindo a geração de
sistemas lightweight, onde cada aplicação possui o seu sistema especifico de
integração de dados distribuídos.
Sua principal característica é o fato de ser baseado na técnica de composição de
frameworks, possibilitando, com isso, flexibilidade e configuraçã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. Configurável, de forma que o middleware
pode ser configurado apenas com os componentes necessários para uma aplicação
específica e que seja instanciado de acordo com os requisitos da aplicação e das
características das fontes de dados que se deseja integrar [BIANCARDI, SILVESTRE,
BARBOSA, 2005a].
Os frameworks são componentes que fazem parte da arquitetura de CoDIMS, e
possuem o DIMS (Data Integration Middleware Services). instanciado para
implementar serviços de integração de dados, como por exemplo o gerenciamento de
dados. Os componentes do CoDIMS são implementados como webservices,
possibilitando distribuição do ambiente, execução remota de tarefas e reuso de tais
componentes (TREVISOL 2004).
32
Um modelo global é implementado para que CoDIMS possa realizar a integração de
dados, onde os modelos locais são integrados e mapeados dentro do modelo global.
Figura 3 – Configuração Básica do CoDINS
A Figura 3 mostra os componentes básicos da configuração do CoDIMS. Os
Componentes de Controle, Gerência de Metadados, Processamento de Consultas e
Acesso de Dados são os componentes que devem existir em todas as configurações.
Dependendo do domínio da aplicação para qual está sendo desenvolvida a aplicação,
poderiam estar presentes outros componentes da configuração.
Na Figura 4 é mostrada a configuração básica do CoDIMS assim como uma possível
interação entre os mesmos. O componente Controle é a essência do ambiente
CoDIMS, pelo fato de disponibilizar os mecanismos que implementam as
configurações física e lógica. A configuração física diz respeito à seleção e ao registro
dos componentes que farão parte do sistema a ser configurado, incluindo os serviços
oferecidos e requisitados por cada um destes componentes. A configuração lógica é
modelada através de um mecanismo baseado no conceito de workflow, 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 configurado.
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 fim 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].
33
Figura 4 - O CoDIMS e seus Componentes Básicos [BIANCARDI, 2005]
Para o processo de configuração, customização e modelagem de uma instância do
CoDIMS, são necessárias as etapas de configuração física, configuração lógica e
carga dos metadados1 de acordo com os requisitos de uma aplicação específica. Um
exemplo de instância do framework CoDIMS é o CoDIMS-G (FONTES et al., 2004),
que vem sendo desenvolvida no LNCC2 com o objetivo de suportar aplicações de
visualização científicas executando em um ambiente de Grid.
3.2.1. CoDIMS-G
CoDIMS-G é um sistema de integração de dados e programas gerados a partir da
configuração do CoDIMS [BARBOSA; PORTO; MELO, 2002; BARBOSA, 2001]. Esse
sistema 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 [BIANCARDI,
2005].
A arquitetura do CoDIMS-G, mostrada na Figura 5, é subdividida em vários
componentes. O componente Control administra a comunicação entre os vários
componentes, armazenando, gerenciando, validando e verificando as instâncias de
configuração.
1
2
Para uma descrição mais detalhada do processo de configuração consulte [BARBOSA, 2001].
Laboratório Nacional de Computação Científica - http://www.lncc.br/frame.html
34
Figura 5 – Arquitetura do CoDINS-G [FONTES et al., 2004]
A requisição de um usuário é encaminhada para o componente Controle, que é
enviada 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 especificados 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].
35
3.3.
MOCHA
É um middleware proposto pela universidade de Maryland, projetado para
interconectar fontes de dados distribuídos sobre uma grande área de rede
[RODRIGUES-MARTINEZ; ROSSOUPOULOS, 2000].
Foi projetado para integrar centenas de fontes de dados distribuídas sobre a Web,
tendo sido construído com a idéia de que um middleware para um ambiente distribuído
de larga escala deve ser auto-extensível. Esta extensibilidade permite o envio de
classes Java para os sites remotos de um modo automático, de acordo com as
características das fontes de dados. As classes Java são necessárias para executar
uma sub-consulta no próprio site, diminuindo o tráfego de dados entre o site e o
sistema [PEREIRA BARBOSA, 2001].
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 (BIANCARDI, 2005).
Os principais componentes da arquitetura MOCHA, mostrados na Figura 6, são:
•
Processador de consulta (QPC);
•
Wrappers (DAP);
•
Repositório de código JAVA (Code Repository);
•
Catálogo de armazenamento de metadados (Catalog).
Figura 6 – Arquitetura do Mocha [BIANCARDI, 2005]
A Aplicação Cliente - um applet, um servlet, ou uma Aplicação Java, é usada para
submeter consultas ao sistema; o Coordenador de Processamento de Consultas
(QPC) - fornece serviços tais como análise de consulta, otimização de consulta,
36
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; o 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 filtram os dados sendo acessados); e o
Servidor de Dados - armazena um conjunto de dados de um site em particular.
3.4.
OGSA-DPQ
OGSA-DPQ é 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., 2003].
Figura 7 – Arquitetura do OGSA-DPQ [ALPDEMIR et al., 2003]
Como pode ser observado na Figura 7, o OGSA-DQP usa os serviços oferecidos pelo
framework OGSA-DAI para acessar, de forma homogênea, as fontes de dados,
potencialmente heterogêneas. Em um nível menor, temos a camada GT3 (Globus
Tookit), 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 8 mostra a interação entre os frameworks OGSA-DQP e OGSA-DAI
[BIANCARDI, 2005].
No OGSA-DPQ, instâncias de serviço de execução de consulta são implantadas em
nodos de GRID para implementar paralelismo de programas de usuário. Operadores
algébricos, tal como, exchange e operation-call, implementam comunicação entre
nodos e invocação de programas de usuário, respectivamente [FONTES et al., 2004].
37
Figura 8 - Interação entre os frameworks OGSA-DPQ e OGSA-DAI.
Assim como o OGSA-DAI, o OGSA-DPQ 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-DPQ, e outras pertencentes somente ao OGSA-DPQ.
Uma delas está relacionada com a obtenção dos esquemas das fontes de dados, pois
nenhuma integração de esquema e resolução de conflitos é suportada durante a
importação dos esquemas. Os esquemas importados são simplesmente acumulados e
mantidos localmente. Isso dificulta a vida do usuário final, dado que ele terá grandes
dificuldades para integrar "visualmente" os esquemas e resolver conflitos semânticos
e/ou estruturais entre os mesmos. Uma outra restrição é que o plano de execução de
consulta gerado pelo OGSA-DPQ é estático [FONTES et al., 2004].
Além disso, existe a possibilidade de um ou mais nodos alocados para este plano
estático ficarem sobrecarregados, ou a fonte com a qual eles se comunicam não está
mais respondendo. Neste sentido, no OGSA-DPQ, não é possível fazer uma análise,
em tempo de execução, dos nodos alocados no GRID para que, se necessário, seja
feita uma realocação dos mesmos e a geração de um novo plano.
38
[OGSA-DAI]
4. OPEN GRID SERVICE ARCHITECTURE – DATA
AND INTEGRATION (OGSA-DAI)¹
4.1.
Introdução
A maior parte das empresas utiliza serviços web para se comunicar com o mundo.
Este é um dos motivos pelo qual este middleware foi desenvolvido, pois atualmente
para se manipular bancos de dados é preciso estar conectado diretamente ao mesmo.
Sendo assim foi preciso criar uma estrutura na qual pudesse modificar um banco de
dados pela internet, facilitando o acesso a qualquer hora. Outra necessidade é a de
juntar tipos diferentes de recursos de dados, pois se estes forem diferentes, como por
exemplo, Oracle e MySQL, ficaria impossível a junção dos mesmos.
O OGSA-DAI inclui uma coleção de componentes para a manipulação de dados de
diversas maneiras e também um uma outra coleção de ferramentas para desenvolver
aplicações de clientes. Além disso, umas de suas diversas utilidades seria o fato de
este software ser facilmente modificado, fornecendo ao usuário a opção de adicionar
novas funcionalidades criadas pelo próprio usuário.
Figura 9 – Funcionamento do OGSA-DAI
¹ Este capítulo está baseado no material contido em [OGSA-DAI]
39
Pode-se dizer que o principal foco deste software é na contribuição de um futuro onde
os cientistas da computação possam focar o seu conhecimento na análise e
processamento de dados ao invés de se preocupar na localização física dos dados, na
sua transferência, estrutura e manipulação.
O OGSA-DAI é um middleware, ou seja, um programa que faz a ligação entre outros
softwares (Figura 9). Este software tem como principal característica o fato de
podermos manipular vários recursos de dados ao mesmo tempo. Por exemplo,
podemos utilizar, em um ambiente de Grid, recursos de dados relacionais ou banco de
dados em XML, sendo que estes dados podem ser consultados, alterados, atualizados
e mostrados via web para outros clientes.
O OGSA-DAI suporta um número limitado de tecnologias exemplificadas na Tabela 1.
SGBD
MySQL
IBM DB2
Versão Suportada
Relacional
3.2.3 em diante
---
Microsoft SQL Server
---
Oracle
10g Enterprise Edition 10.2.0.1.0
PostgreSQL
---
EXist
XML
Feito desde 03/12/2005
Sistema de arquivos
Arquivos
---
Observações
Detalhes em www.mysql.com
OGSA-DAI não suporta a
criação ou deleção de bancos
de dados usando BD2 .
Não Suporta a coluna IMAGE
no OGSA-DAI.
OGSA-DAI não suporta a
criação ou deleção de base
de dados usando Oracle.
Detalhes em
www.postgresql.org
É recomendável que a
instalação do eXist ocorra
dentro de um contêiner com
seus próprios serviços Web.
Ex: OMIM, SWISSPROT e
EMBL.
Tabela 1 – Tecnologias Suportadas pelo OGSA-DAI
4.2.
Arquitetura do OGSA-DAI
A arquitetura OGSA-DAÍ, representada na Figura 10, é composta de várias camadas
com suas respectivas funções e finalidades. Dentro destas camadas existem
componentes e entre as camadas existem um tipo de interface.
40
Figura 10 - Arquitetura do OGSA-DAI
4.2.1. Camada de dados (data layer)
De baixo para cima está a camada de dados que consiste dos recursos de dados que
são suportados pelo OGSA-DAI, sendo esses recursos: relacionais, bancos XML,
arquivos e diretórios em formatos conhecidos pelo software.
4.2.2. Interface entre camada de dados e camada lógica de negócio
Entre a camada de dados e a camada de negócio existe uma interface que permite
uma comunicação em ambas as direções de informações. Para que ocorra tal
comunicação é preciso que cada recurso de serviço de dados tenha um assessor de
recursos de dados que irá controlar acesso para um recurso de dados adjacente.
Dentro do OGSA-DAI ainda existe a possibilidade de o usuário construir o seu próprio
assessor de recurso de dados para expor novos tipos de recursos de dados (Figura
11).
41
Figura 11 – Data Service Resource
4.2.3. Camada Lógica de Negócios (Business Logic Layer)
Esta camada do OGSA-DAI contém a funcionalidade do seu núcleo. Esta consiste de
componentes conhecidos como recursos de serviço de dados. Como mostrado na
Figura 10, vários recursos de serviços de dados podem ser instalados para expor
várias fontes de dados. Existe uma relação de 1-1(um para um) entre recursos de
serviços de dados e recursos de dados. Algumas das funcionalidades ou até
responsabilidades de um recurso de serviço de dados são listadas abaixo.
•
Execução de documentos de desempenho – este documento descreve as
ações que um recurso de serviço de dados deve tomar no interesse do cliente.
Cada ação é conhecida como uma atividade. O OGSA-DAI já inclui um número
alto de atividades para que sejam realizadas as operações mais comuns como
queries de base de dados, transformação de dados e entrega de dados.
•
Geração de documentos de resposta – este documento descreve o status da
execução de um documento de desempenho e pode conter resultados em
forma de dados, por exemplo, os resultados de uma query na base de dados.
•
Acesso a recursos de dados – interações com os recursos de dados
acontecem graças ao componente de recursos de dados.
•
Funcionalidade de transporte de dados – dados podem ser transportados de
um recurso de serviço de dados para um cliente ou outro recurso de serviço de
dados qualquer e vice-versa.
•
Gerência de Sessão – seria a criação, acesso e terminação de objetos de
sessão permitindo que estados possam ser guardados através de múltipos
pedidos para o recurso de serviço de dados. Todos os pedidos de documentos
de desempenho são processados dentro de uma sessão. Sessões também
servem para guardar streams que foram usadas pela funcionalidade de
transporte de dados sendo assim conhecidas por sessões stream.
•
Gerência de propriedade – seria a criação, acesso e remoção de propriedades
associadas com os recursos de serviços de dados sendo conhecidos como
propriedades de recursos de serviços de dados. Estes geralmente são usados
42
para expor os datos, por exemplo, o status de um pedido ou um esquema de
recurso de dados adjacente.
4.2.4. Interface entre a camada lógica de negócios e a camada de
apresentação
Esta interface faz a comunicação com as duas camadas adjacentes, lógica de
negócios e de apresentação, em ambas as direções. Ela suporta a chamada de
funcionalidades do OGSA-DAI dentro da camada lógica de negócio de um jeito que é
independente de um ambiente web particular. Quando pedidos de SOAP (Service
Oriented Architecture Protocol) chegam aos serviços de dados do OGSA-DAI, esta
interface é usada para passar informações e instruções para a camada lógica de
negócio e vice-versa. A seguir é mostrado quais os tipos de informações que são
passadas entre estas duas camadas.
Camada de apresentação Camada lógica de negócio
São enviadas informações sobre os nomes dos data service resourses e
•
suas propriedades, vomo também identificações de session streams
Certificado de Proxy do cliente e credenciais em um formato que não
•
depende da web.
•
Documentos de desempenho e dados de clientes.
•
Informação de configuração de recursos de serviços de dados incluindo
drivers para os bancos de dados, URIs dos mesmos, nome e senha de
usuários de base de dados, informação sobre atividades suportadas,
informação sobre sessão de data service resourse recursos de serviços
de dados e simultaneidade suportada.
Camada lógica de negócios Camada de apresentação
•
É passado pela camada de apresentação os documentos de resposta e
resultados em forma de dados.
•
O status do processamento de um pedido dentro de uma sessão em
particular. Isto é conhecido como status de pedido de sessão.
•
Valores para as propriedades de recursos de serviços de dados como
esquemas de um recurso de dados adjacente.
43
•
Informação sobre as atividades que são suportadas pelos recursos de
serviços de dados. Estas atividades são aquelas que podem ser
pedidas pelo usuário usando documentos de desempenho.
4.2.5. Camada de Apresentação (Presentation layer)
Esta camada encapsula a funcionalidade requerida para expor recursos de serviços de
dados usando interfaces que utilizam serviços web. O OGSA-DAI contém dois
conjuntos destas funcionalidades encapsuladas, uma compatível com WSRF (Web
Services Resourses Framework) e a outra com WSI (Web Services Inter-Operability).
4.2.6. Camada de Cliente (Client layer)
Um cliente pode interagir com um data service resourse através de um data service
correspondente.
O OGSA-DAI também inclui um client toolkit Java que proporciona uma API de alto
nível para interação de serviços de dados. Este kit de ferramentas simplifica o
desenvolvimento de aplicações fornecendo meios convenientes de construir e enviar
pedidos e interpretar as respostas subseqüentes. Quando uma aplicação é escrita
usando este kit de ferramentas de ciente, esta poderá interagir e acessar recursos de
dados WSRF e WSI transparentemente.
4.3.
Serviços de Dados
Serviço de dados é um ponto de contato para clientes que queiram acessar, pesquisar
ou atualizar um recurso de dados específico, ou até desempenhar outras ações
relacionadas a dados usando o OGSA-DAI.
Um serviço de dados oferece uma interface que é voltada ao uso de documentos, nela
é aceito o uso de documentos de desempenho pelos clientes e o uso de documentos
de resposta para os clientes. Um serviço de dados oferece um grande número de
operações que permitem que informações sobre o serviço possam ser recuperadas, e
também fornece acesso aos recursos do serviço de dados sendo que estes são
expostos pelo próprio serviço de dados.
44
4.3.1. Operações Usando Dados
-Documento de Desempenho
Documentos de desempenho são usados pelos clientes para instruir recursos de
serviços de dados a desempenhar atividades. Estas atividades incluem consultas e
atualizações, transformação de dados e operações de entrega de dados. Um
documento deste tipo poderia conter, nos casos mais simples, apenas uma simples
query ou até, em casos mais complexos, um aglomerado de requisições de atividades
que podem conter consultas, atualizações, entrega de dados, entre outros.
O fato de podermos juntar várias atividades em apenas um documento é uma grande
vantagem, pois assim não ocorre o imenso fluxo de dados que teríamos caso
tivéssemos que transportar cada atividade usando um pedido ou serviço diferente.
As APIs que são concedidas junto com o OGSA-DAI permitem desenvolvedores Java
construírem aplicações que geram documentos de desempenho e interpretam
documentos de resposta automaticamente. A seguir será descrito a estrutura
subjacente e o conteúdo de documentos de desempenho.
Na Figura 12 podemos ver um documento de desempenho que é expresso usando
XML. A raiz deste documento é o elemento <perform>, logo após vem o elemento
<session>, que é opcional, pois ele pode conter nenhuma ou várias atividades. O
elemento de atividade é aquele que contém tudo que o recurso de dados deverá
realizar. Este deve conter um único valor para o atributo name. Para que várias
atividades possam ser enviadas juntas é preciso que o stream de saída (output
stream) de uma atividade seja referenciado pelo stream de entrada (input stream) da
próxima atividade. Na Figura 13 é exibida um exemplo de documento de desempenho.
Figura 12 - Documento de desempenho contendo elemento de sessão (session element), elemento de
atividade (activity element) e um ponto final (end-point)
45
Figura 13 – Exemplo de documento de desempenho
Sendo assim todos os dados que estiverem entre estas atividades serão entregues de
volta ao cliente através de um documento de resposta.
-Documento de Resposta
Um documento de resposta é usado para responder ao usuário quando este envia um
documento de desempenho para um serviço de dados. O conteúdo deste documento
de resposta pode variar de acordo com o que foi enviado. Por exemplo, o documento
de resposta pode conter dados resultantes de atividades descritas no documento de
desempenho.
Sendo assim, ao receber um documento de resposta o usuário poderá analisá-lo para
saber se ocorreu algum erro ou então para extrair algo que lhe seja de interesse.
Figura 14 - Documento de resposta (dir) resultante do documento de desempenho (esq)
Neste exemplo da Figura 14 podemos observar um documento de desempenho que
utiliza um end-point chamado myActivityOutput, sendo assim este documento será
processado de modo síncrono e por isso o documento de resposta só será enviado de
volta para o cliente quando os pedidos forem todos processados. Analisando mais de
perto o corpo deste documento podemos ver que ele possui um elemento <session>
que contem a identificação da sessão na qual o pedido entrou para ser processado,
um elemento <request> que define o status em que se encontra o pedido, um
elemento <result> para cada uma das atividades contidas no documento e também
46
uma seção denominada CDATA que irá conter os dados que resultaram do
processamento das atividades.
Outro exemplo deste documento pode ser encontrada na Figura 15 e o seu documento
de resposta correspondente na Figura 16.
Caso o documento enviado não contenha nenhum ponto de saída então o
processamento irá ocorrer de forma assíncrona, ou seja, nenhum dado será retornado
no documento de resposta para o usuário e por isso não será mais preciso esperar
que todas as atividades sejam concluídas. Sendo assim este documento poderá ser
enviado assim que o pedido for inicializado. Por causa disso o documento de resposta
resultante somente irá conter elementos do tipo <response> e <request>.
Figura 15 - Exemplo de Documento de Desempenho enviado de forma Síncrona
Figura 16 - Documento de resposta contendo os dados resultantes
4.4.
Recursos de Serviços de Dados
Os recursos de serviços de dados que servem para receber os documentos enviados
pelos serviços de dados e então analisá-los e validá-los. Após isso as atividades são
executadas e então é criado o documento de resposta para que possa ser enviado de
volta para o serviço de dados.
47
Figura 17 - Interação usando uma interface orientada a documentos
Na Figura 17 podemos observar com mais precisão a interação destas camadas
usando documentos para fazer a comunicação entre elas.
4.5.
Assessor de Recursos de Dados
Estes assessores servem para fazer a comunicação entre os recursos de serviços de
dados e os bancos de dados sendo utilizados. Com o assessor de recursos de dados
do OGSA-DAI o usuário pode criar o seu próprio assessor de recurso de dados para
que este possa fazer a comunicação a um banco de dados que ainda não são
suportados pelos assessores listados na Tabela 2.
Assessor de Recurso de Dados
Descrição
Assessores de dados padrões
JDBC Data ResourceAccessor
Fornece acesso a uma única base de dados JDBC
relacional
XMLDB Data Resource Accessor
Fornece acesso a uma única base de dados XML
Files Data Resource Accessor
Fornece acesso a um único sistema de arquivos
Assessores de integração de dados
SQL Multiple Data Resource Accessor
Agrega um ou mais recurso de serviço de dados
Assessores de demonstração
Demo Factory Data Resource Accessor
Exemplo de um assessor que pode criar
dinamicamente recursos de serviços de dados.
Demo Instance Data Resource Accessor
Exemplo de assessor utilizado pelo resurso de
serviço de dados.
Demo Transient Factory Data Resource Accessor
Exemplo que pode criar recursos de serviços de
dados transientes.
Demo Transient Instance Data Resource Accessor
Exemplo de assessor utilizado pelorecurso de
serviço de dados.
Tabela 2 - Assessores de dados fornecidos pelo OGSA-DAI
4.6.
Relacionamento
A seguir será descrito como é o relacionamento entre os serviços de dados (data
service), fontes de serviços de dados (data service resource), assessores de fontes de
48
serviços de dados (data service resource accessors) e as fontes de dados (data
resources), ou seja, será descrita e ilustrada a interação entre eles.
Na Figura 18 podemos identificar vários componentes. A seguir estarão algumas de
suas características.
Primeiramente um serviço de dados (data service) pode expor nenhuma ou várias
fontes de serviço de dados (data service resource). O serviço de dados e a fonte de
serviço de dados (data service resource) precisam estar em um mesmo servidor. Uma
fonte de serviço de dados expõe uma fonte de dados (data resource). A fonte de
dados (data resource) não precisa estar no mesmo servidor que a fonte de serviço de
dados (data service resource). O assessor de fonte de dados (data resource accessor)
gerencia as interações com as fontes de dados em nome da fonte de serviço de
dados.
Uma fonte de serviço de dados possui um conjunto de arquivos de configuração que
especificam as atividades suportadas, informação sobre a sessão e o nome da classe
do assessor de fonte de dados. Um assessor de fontes de dados também possui um
conjunto de arquivos de configuração que fala sobre a fonte de dados relacionada.
Figura 18 – Exemplo de Entrega de dados
4.7.
Especificação Funcional
O objetivo desse capítulo é explicar como o OGSA-DAI se comunica com as fontes de
dados e como ambas se comunicam com o middleware.
4.7.1. Representando uma Fonte de Dados no OGSA-DAÍ
Primeiramente, é preciso obter as informações das fontes de dados desejadas, como
por exemplo, o Driver de cada banco (Tabela 3 – Anexo A), a URI da fonte de dados
(Tabela 4 – Anexo A) e a versão dessa fonte (Tabela 1 – Cap 4). Com isso em mãos é
49
preciso criar um resourse file contendo os argumentos necessários. O passo seguinte
seria realizar o transporte desse arquivo para o servidor Tomcat de sua máquina (Vide
Anexo A).
Uma declaração resourse file (Figura 19) contêm as seguintes informações para o
recurso:
• Resourse ID – Corresponde ao nome do arquivo;
• Resourse Type – Tipo dos nomes dos recursos do OGSA-DAI;
• Creation Time – valor em milissegundos a partir do inicio do evento. Também
pode ser nulo;
• Termination Time – valor em milissegundos a partir do inicio do evento.
Também pode ser nulo;
• Nenhuma ou várias propriedades da persistência do recurso;
o Delimitado por Properties e End;
o Os valores são strings;
• Nenhuma ou várias propriedades de configuração;
o Delimitado pelo Config e End;
o Os valores são strings;
• Nenhuma ou várias propriedades de apoio;
o Delimitado por Activities e End;
id=RESOURCE-ID
type=RESOURCE-TYPE
creationTime=CREATION-TIME
terminationTime=TERMINATION-TIME
PROPERTIES
[NAME=VALUE]*
END
CONFIG
[KEY=VALUE]*
END
ACTIVITIES
[ACTIVITY-NAME=ACTIVITY-ID]*
END
Figura 19 – Resourse File
50
4.7.2. Fluxograma de Execução
O OGSA-DAI possui várias classes que fazem consultas em bancos de dados. Um
URI, um resource file e um comando SQL são os parâmetros necessários para fazer
uma consulta em uma fonte de dados integrada ao OGSA-DAI Client. Todos estes
parâmetros devem estar incluídos numa classe específica do middleware que é
utilizada para fazer acesso ao banco.
O conceito básico é que o cliente irá construir um fluxo de trabalho das atividades que
serão executadas sobre o OGSA-DAI Server. Os dois elementos chaves são as
atividades e o fluxo de trabalho.
As atividades são os módulos básicos do OGSA-DAI. Eles são discretos pacotes que
fazem um passo lógico em um processo. As atividades são divididas em várias
categorias, algumas específicas, outras não. As categorias são as seguintes:
•
Input data delivery – atividade que recupera as entradas remotas nas fontes de
dados.
•
Data Access and collection - atividades que acessa os dados, realizada
normalmente em recursos como bancos de dados.
•
Data transform – atividades que transforma os dados de um formato para o
outro.
•
Output data delivery – atividade que envia dados ao OGSA-DAI.
•
Management and control – atividade que gerencia o OGSA-DAI Server.
Cada categoria contém atividades que se focam em torno de uma tarefa específica e
só estão interessadas em realizar essa tarefa, por exemplo, a atividade SQLQuery lida
com a missão de resgatar um banco de dados SQL e obter um conjunto de resultados.
As principais etapas que terão de ser abordadas através de atividades são os
seguintes:
•
Examina o banco de dados
•
Transforma os resultados para um formato mais utilizável
•
Transforma os resultados para um formato mais eficiente.
•
Mostra os resultados de volta para o cliente.
Para explicar melhor o funcionamento, utilize como base a seguinte consulta mostrada
na Figura 20 realizada pelo cliente.
SELECT * FROM littleblackbook WHERE id <10;
Figura 20 – Consulta realizada pelo cliente
51
Para facilitar a conexão com o servidor, é fornecido um Serverproxy que implementa
um servidor de interface. É necessário saber as URL dos bancos de dados para serem
fornecidos ao servidor.
A Figura 21 é um Proxy da representação de um servidor OGSA-DAI da parte do
cliente. Ele pode ser obtido através de proxies para cada serviço web e, por isso, cada
recurso, implantado sobre o servidor OGSA-DAI.
Server mServer;
public
void
setupServer(String
serverURLStr)
throws
ClientToolkitException,
MalformedURLException
{
mServer = new ServerProxy();
mServer.setDefaultBaseServicesURL(new URL(serverURLStr));
}
Figura 21 - Servidor Proxy do OGSA-DAI
A classe Server fornece um exemplo de métodos de acesso aos proxies que
representam os diferentes recursos disponíveis no servidor do OGSA-DAI. As proxies,
que correspondem aos seis tipos de recursos do OGSA-DAI, são:
•
DataRequestExecutionResource
•
DataSinkResource
•
DataSourceResource
•
DataResource
•
RequestResource
•
SessionResource
A Figura 22 mostra um exemplo de utilização de alguns desses recursos. O primeiro
deles é o DataRequestExecutionResource para um DRER. Seria um pedido de
execução de dados dos recursos que aceita o fluxo de trabalho do cliente e, executa e
retorna estes resultados. Uma DRER pode ser vista como um fluxo de trabalho de
gestão e execução dos recursos.
52
DataRequestExecutionResource mDRER;
public void setupDRER(ResourceID drerID)
throws ServerException, ClientToolkitException
{
mDRER = mServer.getDataRequestExecutionResource(drerID);
}
Figura 22 – DataRequestExecutionResource
Como a ligação básica foi efetuada, as atividades podem ser desenvolvidas para a
utilização. São necessárias quatro atividades:
•
SQLQuery
•
TupleToWebRowSetCharArrays
•
CharArraysResize
•
DeliverToRequestStatus
Ao criar um fluxo de trabalho, todas as entradas e saídas das atividades deverão ser
devidamente conectadas. Caso contrário, ocorrerá um erro no decorrer da execução.
O primeiro passo é criar a atividade SQLQuery. A Figura 23 mostra o código para a
criação da atividade para uma consulta SQL e um recurso de dados.
public SQLQuery makeSQLQuery(ResourceID dataResourceID, String sqlStr)
{
SQLQuery tempQuery = new SQLQuery();
tempQuery.setResourceID(dataResourceID);
tempQuery.addExpression(sqlStr);
return tempQuery;
}
Figura 23 – SQL Query
Os parâmetros do método são os dados ResourceID para o recurso que está a ser
orientada, por exemplo, a um banco de dados MySQL exibidas pelo servidor do
OGSA-DAI e da consulta SQL representada pelo sqlStr. A atividade SQLquery não
verifica o comando SQL antes da execução para que esse comando seja validado.
Esta atividade exige que o método setResourceID seja utilizado para segmentar um
DataResource.
O próximo passo é a criação da atividade TupleToWebRowSetCharArrays. Esta
atividade converte tuples, um conjunto de variáveis, tais como os de saída de uma
consulta de uma atividade web. Esta atividade não tem de ser alvo de um recurso, ela
53
exige que outra atividade verifique a entrada. Nesta fase, apenas uma instância é
criada usando um método semelhante ao do SQLQuery (Figura 24).
Public TupleToWebRowSetCharArrays makeTupleToWebRowSetCharArrays()
{
return new TupleToWebRowSetCharArrays();
}
Figura 24 - TupleToWebRowSetCharArrays
Essa atividade pode causar problema quando utilizado com produtividade via SOAP
HTTP, o meio utilizado para a comunicação cliente-servidor pelo middleware.
A atividade CharArraysResize (Figura 25) reestrutura as matrizes em uma dimensão
que resulta na melhoria da eficiência quando transportá-los via SOAP sobre HTTP. O
tamanho dos arrays pode ser especificado pelo cliente e, se necessário, sintonizado.
Public CharArraysResize makeCharArraysResize()
{
CharArraysResize resize = new CharArraysResize();
resize.addArraySizeInput(5000);
return resize;
}
Figura 25 - CharArraysResize
A entrega de dados no OGSA-DAI, pode ser realizada de várias formas, através de
FTP, GridFTP, SMTP, ou, como na Figura 26, através de uma atividade
DeliverToRequestStatus. Esta atividade assegura que quaisquer dados que serão
recebidos, serão colocadas no pedido de status que é retornado a um cliente por um
DRER quando o seu workflow completa a execução. A atividade de transformação
referida, não tem de ser explicitamente orientados para um recurso.
public DeliverToRequestStatus makeDeliverToRequestStatus(){
return new DeliverToRequestStatus();
}
Figura 26 – DeliverToRequestStatus
Dividir a atividade de entrega de dados permite uma integração mais fácil no corpo
principal do código.
Ao realizar uma consulta específica, como mostrada na Figura 20, a aplicação do
OGSA-DAI deve conter uma atividade chamada grupo de recursos. Somente assim
54
ela poderá direcionar uma consulta SQL para diversas fontes de dados. A atividade
gerada é o CreateResourceGroup. Ela espera que as ID’s dos grupos de recursos
como entradas.
Para o exemplo da Figura 27, existem dois recursos que agrupados em um único
grupo de recurso.
String id1 = "Resource1";
String id2 = "Resource2";
Figura 27 – Recursos
Os IDs dos recursos são colocados em uma string (array) e passado para a atividade
CreateResourceGroup como um parâmetro (Figura 28).
String resources = new String[]{ id1, id2 };
CreateResourceGroup create = new CreateResourceGroup();
create.addResourceIdsAsArray(resources);
Figura 28 – Recursos passados como parâmetros
A lista da Figura 29 mostra um pedido em que a saída da atividade
CreateResourceGroup, que é a identificação do recém criado recurso, é entregue ao
cliente.
DeliverToRequestStatus deliverToRequestStatus1 = new DeliverToRequestStatus();
deliverToRequestStatus1.connectInput(create.getOutput());
PipelineWorkflow createWorkflow = new PipelineWorkflow();
createWorkflow.add(create);
createWorkflow.add(deliverToRequestStatus1);
Figura 29 – Pedido entregue ao cliente
Depois que o pedido tenha sido executado o recurso ID do grupo está disponível a
partir do resultado CreateResourceGroup. (Figura 30)
Drer.execute(createWorkflow, RequestExecutionType.SYNCHRONOUS);
ResourceID groupID = create.nextResult();
Figura 30 – Pedido disponível
55
Após a geração da atividade CreateResourceGroup, outra atividade realiza a consulta
em múltiplos BD’s, chamada de sqlBag, que tem como funcionalidade executar um
comando SQL em todas as fontes listadas em um grupo de fonte de dados.
A atividade sqlBag (Figura 31) possui função de agrupar esquemas de fontes de
dados diferentes. Ao mesmo tempo em que essa atividade dispara a query para os
bancos, o mesmo recebe os resultados e integrando-os em um único resultset.
<sqlBag name="sqlAnd">
<sqlStatement value="SELECT * FROM littleblackbook WHERE id=5"/>
<timeout> 100000 </ timeout>
<sqlBagOutput name="sqlOutput"/>
</sqlBag> </ sqlBag>
Figura 31 – sqlBag
Os elementos da classe são:
•
Name - nome exclusivo para a atividade dentro do escopo de um pedido.
•
sqlStatement (obrigatório) - defini a consulta SQL a ser enviada para as fontes
de dados.
•
timeout (opcional) - a quantidade de tempo dentro dos recursos de dados deve
retornar resultados. Deve ser um número não negativo e longo. Se o valor
fornecido for zero, então o tempo limite é considerado ilimitado. Se o valor for
superior a zero, então é considerado o mínimo entre o valor providenciado e o
máximo tempo limite definido no padrão SQL data resource accessor. Se
nenhum valor for fornecido, então o tempo limite é igual ao tempo limite
definido no SQL data resource accessor.
•
sqlBagOutput (obrigatório) - output stream que produz os resultados da
consulta SQL.
Agora, o novo recurso disponível no CreateResourceGroup pode ser usado como
meta para uma consulta no sqlBag, que executa a consulta.
A criação de uma consulta ao sqlBag é mostrada na Figura 32.
SQLBag query = new SQLBag();
query.setResourceID(groupID);
query.addExpression("SELECT * FROM littleblackbook WHERE id<3");
Figura 32 – Consulta realizada pelo sqlBag
56
Mais de uma expressão SQL podem ser adicionadas como o método da Figura 32,
caso se deseje realizar diversas consultas ao banco.
Na consulta realiza neste trabalho, os resultados são transferidas para a atividade
TupleToWebRowSetCharArrays que os transforma como XML e são entregues (Figura
33).
Após executar o pedido da Figura 36, os resultado podem ser recuperados a partir da
atividade TupleToWebRowSetCharArrays.
Para cada expressão SQL que foi
adicionada ao sqlBag, haverá um conjunto resultado disponível. Cada chamada para
TupleToWebRowSetCharArrays.nextResult() retorna um objeto java.sql.ResultSet para
proporcionar o acesso à linha de base dos resultados, como exemplificado na Figura
34.
TupleToWebRowSetCharArrays tupleToWebRowSet = new
TupleToWebRowSetCharArrays();
tupleToWebRowSet.connectDataInput(query.getDataOutput());
DeliverToRequestStatus deliverToRequestStatus = new DeliverToRequestStatus();
deliverToRequestStatus.connectInput(tupleToWebRowSet.getResultOutput());
PipelineWorkflow pipeline = new PipelineWorkflow();
pipeline.add(query);
pipeline.add(tupleToWebRowSet);
pipeline.add(deliverToRequestStatus);
Figura 33 – Atividade TupleToWebRowSetCharArrays
drer.execute(pipeline, RequestExecutionType.SYNCHRONOUS);
while (tupleToWebRowSet.hasNextResult())
{
ResultSet rs = tupleToWebRowSet.nextResultAsResultSet();
// iterate through the rows of the result set
while (rs.next())
{
... // do something with the result values
}
}
Figura 34 - TupleToWebRowSetCharArrays.nextResult
57
A integração dos resultados das sub-consultas também é realizada pela atividade
sqlBag, que coleta todos os resultados da query e os coloca em um único result set
que também incluirá linhas duplicadas, caso existam.
4.8.
Modificando Um Banco de Dados
O OGSA-DAI permite que modifique o banco de dados para que se possa realizar
algumas atualizações.
Esse tipo de modificação é realizada pela atividade sqlUpdateStatement. Essa
atividade executa uma ou mais seqüências de uma declaração SQL através de uma
conexão JDBC.
O código da Figura 35 mostra um exemplo da utilização da atividade.
<sqlUpdateStatement name="statement">
<!-- value of first parameter -->
<sqlParameter position="1" from="datatoinsert"/>
<!-- value of second parameter -->
<sqlParameter position="2">321</sqlParameter>
<expression>
insert into littleblackbook values ? ?
</expression>
<resultStream name="results"/>
</sqlUpdateStatement>
Figura 35 – sqlUpdateStatement
Os elementos da atividade são:
•
Name: nome exclusivo da atividade dentro escopo de um pedido
•
sqlParameter (zero ou mais): define um parâmetro.
o Position: posição dentro da expressão do elemento
o From (opicional): nome da saída de outra atividade que fornece o valor
desse parâmetro
o Se o valor do From não for especificado, então esse elemento deve
conter o valor do parâmetro.
o A seqüência em que os elementos aparecem é importante quando a
atividade sqlParameter fornecer o valor de mais de um parâmetro. A
seqüência em que os elementos aparecem é a seqüência a ser
entregue (Figura 36).
•
Expression (Obrigatório): declaração da atualização SQL.
58
o A atualização do SQL está dentro desse elemento.
o ?: pode ser usado no lugar de qualquer parâmetro definido no
sqlParameter
•
resultStream (Obrigatório): produz o fluxo da saída do elemento XML que
detém o numero de linhas alteradas.
<sqlParameter position ="1" from="inputStream"/>
<sqlParameter position ="3" from="inputStream"/>
<sqlParameter position ="2" from="inputStream"/>
Figura 36 - sqlParameter
4.9.
Vantagens
Existem muitas razões pelas quais o OGSA-DAI pode ser mais adequado para o
acesso aos dados e integração, requisitados em um ambiente grid. Estas incluem:
•
Adapta-se com modelo grid / web service.
•
O Workflow encapsula múltiplas interações de web services em uma única
interação.
•
Solução para múltiplos acessos aos dados, transformação, distribuição e
integração de cenários sem a necessidade de desenvolver atividades
específicas de aplicativo.
•
Extensa base de dados para consultas, atualizações, transformação e
distribuição.
•
Framework extensível e versátil, ou seja, desenvolvedores podem adicionar ou
personalizar funcionalidades.
•
Plataformas independentes. Roda em qualquer plataforma que suporte Java.
•
Camadas de segurança complementares podem ser fornecidas, se necessário.
Por exemplo, autorização pode ser feito no nível de serviço da web e / ou ao
nível dos recursos.
•
Transparência da localização da base de dados e os tipos de produtos.
•
Programação em uma linguagem neutra. O web services podem ser acessados
a partir de clientes desenvolvidos em qualquer linguagem que suporta
interação com web services.
•
Funciona muito bem com outros middlewares que suportam grid, por exemplo,
Axis / Tomcat e Globus Toolkit.
59
4.10.
Desvantagens
O problema na utilização OGSA-DAI inclui:
•
O acesso via Web é mais lento do que o acesso direto aos dados ou então via
uma aplicação de web service dedicada.
Em particular, OGSA-DAI pode não ser adequado se:
•
Existe uma única fonte de dados que não vai mudar.
•
Não tem nenhuma requisição para transformação de dados.
•
O usuário querer ter um acesso rápido aos dados em um único recurso.
60
5. ESTUDO DE CASO
5.1.
Descrição da Aplicação
Ao realizar uma consulta em seus BD’s, um Banco Privado deseja saber, dentre as
pessoas que já tenham os dados cadastrados em suas fontes, quais os telefones para
eventuais consultas. Essa informação é necessária, pois, na matriz desse banco,
ocorrem diversos telefonemas para cadastramento de habilitação da função de cartão
de crédito para clientes que não a possuem.
Para possibilitar a habilitação, sempre que houver a necessidade, e caso o cliente não
tenha a função em seu cartão, é realizada uma consulta nos dados cadastrais de
todos os clientes que possuem cartão desse banco, para descobrir aqueles que
possuem a função habilitada. Essa consulta só é possível, pois nos cadastros dos
clientes, existe a informação do tipo do cartão. Isso é feito com o objetivo de tentar
estabelecer um contato e solicitar uma possível aderência do cliente.
Entretanto, caso não exista um banco de dados central, e as informações podem estar
presentes em diferentes filiais desse Banco, sempre que existe a necessidade de fazer
este tipo de consulta, é necessário acessar as fontes de dados das filiais e da matriz.
Além disso, os dados podem estar 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 "littleblackbook1", presente na unidade matriz, tem seus dados
armazenados segundo o modelo de dados relacional armazenado em MySQL, como
pode ser visto na Figura 37.
Figura 37 – Esquema da Fonte Relacional “littleblackbook” da Matriz
1
Utilizamos um banco de dados MySQL como base e dentro dele criamos uma tabela chamada
littleblackbook com o auxilio do OGSA-DAI.
61
O banco de dados "littleblackbook", presente nas unidades da filial, tem seus dados
armazenados no modelo de dados relacional em OracleSQL, como pode ser visto na
Figura 38.
Figura 38 – Esquema da fonte Relacional “littleblackbook” da Filial
Como as fontes de dados devem possuir o mesmo esquema, em termos de nome de
tabelas e nome de atributos, uma mesma consulta é encaminhada para cada fonte de
dados a ser integrada (Figura 39).
Figura 39 - Consulta na linguagem SQL
Para realizar a Integração é necessário ter o OGSA-DAI em todas as maquinas. A
Figura 40 ilustra um exemplo de uma aplicação, onde de um lado está o OGSA-DAI
Cliente e do outro lado as duas fontes de dados que serão integradas.
Figura 40 – Diagrama de Implantação
62
5.2.
Resourse File dos Bancos de Dados
Na máquina onde está rodando a aplicação cliente deverá ser criado os arquivos de
recursos (Resource File) de cada banco de dados que se deseja fazer a integração.
Na Figura 41 é mostrado o Resource File necessário para se conectar com banco
MySQL presente na Matriz do banco privado.
id=MySQLDataResource
type=uk.org.ogsadai.DATA_RESOURCE
creationTime=null
terminationTime=null
PROPERTIES
uk.org.ogsadai.resource.dataresource.product=MySQL
uk.org.ogsadai.resource.dataresource.vendor=MySQL
uk.org.ogsadai.resource.dataresource.version=5
END
CONFIG
dai.driver.class=org.gjt.mm.mysql.Driver
dai.data.resource.uri=jdbc:mysql://localhost:3306/ogsadai
dai.login.provider=uk.org.ogsadai.LOGIN_PROVIDER
END
ACTIVITIES
uk.org.ogsadai.SQLQuery=uk.org.ogsadai.SQLQuery
uk.org.ogsadai.SQLUpdate=uk.org.ogsadai.SQLUpdate
uk.org.ogsadai.SQLBulkLoadTuples=uk.org.ogsadai.SQLBulkLoadTuples
uk.org.ogsadai.GetAvailableTables=uk.org.ogsadai.GetAvailableTables
uk.org.ogsadai.SQLParameterisedQuery=uk.org.ogsadai.SQLParameterisedQuery
uk.org.ogsadai.SQLParameterisedUpdate=uk.org.ogsadai.SQLParameterisedUpdate
uk.org.ogsadai.ExtractTableSchema=uk.org.ogsadai.ExtractTableSchema
END
dataResourceClass=uk.org.ogsadai.resource.dataresource.jdbc.JDBCDataResource
Figura 41 - SQLServer
Na Figura 42 é mostrado o Resource File necessário para se conectar com banco
OracleSQL presente na Filial desse banco privado.
63
id=OracleDataResource
type=uk.org.ogsadai.DATA_RESOURCE
creationTime=null
terminationTime=null
PROPERTIES
uk.org.ogsadai.resource.dataresource.product=Oracle
uk.org.ogsadai.resource.dataresource.vendor=Oracle
uk.org.ogsadai.resource.dataresource.version=10g
END
CONFIG
dai.driver.class=oracle.jdbc.driver.OracleDriver
dai.data.resource.uri=jdbc:oracle:thin:@myhost:1521:ogsadai
dai.login.provider=uk.org.ogsadai.LOGIN_PROVIDER
END
ACTIVITIES
uk.org.ogsadai.SQLQuery=uk.org.ogsadai.SQLQuery
uk.org.ogsadai.SQLUpdate=uk.org.ogsadai.SQLUpdate
uk.org.ogsadai.SQLBulkLoadTuples=uk.org.ogsadai.SQLBulkLoadTuples
uk.org.ogsadai.GetAvailableTables=uk.org.ogsadai.GetAvailableTables
uk.org.ogsadai.SQLParameterisedQuery=uk.org.ogsadai.SQLParameterisedQuery
uk.org.ogsadai.SQLParameterisedUpdate=uk.org.ogsadai.SQLParameterisedUpdate
uk.org.ogsadai.ExtractTableSchema=uk.org.ogsadai.ExtractTableSchema
END
dataResourceClass=uk.org.ogsadai.resource.dataresource.jdbc.JDBCDataResource
Figura 42 - OracleSQL
5.3.
Criando um Grupo de Fonte de Dados
Depois de ter adquirido o resource file dos bancos de dados e necessário criar uma
atividade (CreatResourceGroup), onde serão especificadas todas as fontes de dados
que serão integradas (Figura 43).
String id1 = "MySQLDataResource";
String id2 = "OracleDataResource";
String resources = new String[]{ id1, id2};
CreateResourceGroup create = new CreateResourceGroup();
create.addResourceIdsAsArray(resources);
64
DeliverToRequestStatus deliverToRequestStatus1 = new DeliverToRequestStatus();
deliverToRequestStatus1.connectInput(create.getOutput());
PipelineWorkflow createWorkflow = new PipelineWorkflow();
createWorkflow.add(create);
createWorkflow.add(deliverToRequestStatus1);
drer.execute(createWorkflow, RequestExecutionType.SYNCHRONOUS);
ResourceID groupID = create.nextResult();
Figura 43 – Modelo de grupo de fonte de dados
5.4.
Criando uma Consulta
Logo após de ter criado um grupo de fonte de dados é necessário cria outra atividade
que realizara as consultas as fontes de dados que o Banco Privado possui (Figura 44).
SQLBag query = new SQLBag();
query.setResourceID(groupID);
query.addExpression("SELECT * FROM littleblackbook WHERE id<10");
TupleToWebRowSetCharArrays tupleToWebRowSet = new
TupleToWebRowSetCharArrays();
tupleToWebRowSet.connectDataInput(query.getDataOutput());
DeliverToRequestStatus deliverToRequestStatus = new DeliverToRequestStatus();
deliverToRequestStatus.connectInput(tupleToWebRowSet.getResultOutput());
PipelineWorkflow pipeline = new PipelineWorkflow();
pipeline.add(query);
pipeline.add(tupleToWebRowSet);
pipeline.add(deliverToRequestStatus);
drer.execute(pipeline, RequestExecutionType.SYNCHRONOUS);
while (tupleToWebRowSet.hasNextResult())
{
ResultSet rs = tupleToWebRowSet.nextResultAsResultSet();
// itera através das linhas do result set
while (rs.next())
{
65
// Neste local pode-se tratar o resultado da consulta
}
}
createWorkflow.add(deliverToRequestStatus1);
Figura 44 – Modelo de consulta
5.5.
Resultado da Consulta
A Tabela 3 mostra a consulta realizada pelo OGSA-DAÍ na Fonte de dados da Matriz e
Tabela 4 mostra a consulta realizada na Filial.
Nome
| Endereço
| Telefone
Mario Krause
| 45 Krause Avenue, Southampton
|
272940105 | débito
| Tipo_Cartao
Ally Jackson
| 43 Jackson Lane, San Jose
|
27258982 | débito
Tom Thompson
| 17 Thompson Gardens, Winchester
|
273712657 | débito
Craig Atkinson
| 87 Atkinson Street, Edinburgh
|
27972611 | débito
Kostas Atkinson
| 30 Atkinson Street, Edinburgh
| 2712317111 | débito
Craig Thompson
| 122 Thompson Road, San Jose
|
272010467 | débito
Ali Sugden
| 1 Sugden Lane, San Jose
|
273140125 | débito
Mario Krause
| 120 Krause Place, Edinburgh
|
27787831 | débito
Malcolm Dobrzelecki
| 128 Dobrzelecki Street, Edinburgh
|
2742529 | débito
Tom Chue Hong
| 59 Chue Hong Lane, San Jose
|
27112289 | débito
Bartosz Scott
| 26 Scott Place, Edinburgh
|
2737164 | débito
Kostas Anjomshoaa
| 119 Anjomshoaa Crescent, Southampton |
277592124 | débito
Craig Dobrzelecki
| 25 Dobrzelecki Crescent, Southampton
|
277811829 | débito
David Scott
| 89 Scott Avenue, Southampton
|
27125717 | débito
Ali Atkinson
| 40 Atkinson Crescent, Southampton
| 2710662105 | débito
Craig Krause
| 100 Krause Street, Edinburgh
|
273857 | débito
David Antonioletti
| 80 Antonioletti Road, San Jose
|
27577882 | débito
Bartosz Hume
| 35 Hume Drive, Winchester
|
27809757 | débito
Malcolm Theocharopoulos | 2 Theocharopoulos Place, Edinburgh
|
2799311 | débito
Neil Theocharopoulos
| 106 Theocharopoulos Place, Edinburgh
|
278861111 | débito
Malcolm Hume
| 81 Hume Lane, San Jose
|
273610267 | débito
Tabela 3 – Resultado da Consulta na Matriz (MySQL)
66
Nome
Tom Scott
Mario Atkinson
Mike Theocharopoulos
David Anjomshoaa
Mario Illingworth
Mike Sugden
Malcolm Chue Hong
Ali Krause
Bartosz Krause
Bartosz Karasavvas
Ali Chue Hong
Mario Hume
David Anjomshoaa
Ali Scott
Craig Theocharopoulos
Malcolm Karasavvas
Kostas Jackson
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Endereco
58 Scott Crescent, Southampton
86 Atkinson Crescent, Southampton
10 Theocharopoulos Avenue, Southampton
80 Anjomshoaa Crescent, Southampton
120 Illingworth Street, Edinburgh
115 Sugden Road, San Jose
128 Chue Hong Drive, Winchester
6 Krause Place, Edinburgh
27 Krause Place, Edinburgh
95 Karasavvas Gardens, Winchester
61 Chue Hong Lane, San Jose
87 Hume Road, San Jose
105 Anjomshoaa Street, Edinburgh
1 Scott Crescent, Southampton
28 Theocharopoulos Place, Edinburgh
3 Karasavvas Road, San Jose
31 Jackson Lane, San Jose
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Telefone
275692124
274211829
27105717
279162105
271857
27157882
27249757
27409311
2712361111
2754455
2712010267
2711169125
27342931
2773843
27534329
27643689
2762960
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Tipo_Cartao
débito
débito
débito
débito
débito
débito
débito
débito
débito
débito
débito
débito
débito
débito
débito
débito
débito
Tabela 4 – Resultado da Consulta da Filial (Oracle)
Depois
de
ter
especificado
os
banco
de
dados,
ter
criado
a
atividade
CreatResourceGroup, onde nesta atividade é passado todas as informações sobre as
fontes de dados que serão integradas, e de ter criado uma outra atividade (SQLBag)
que realiza consultas ao grupo especificado, a Tabela 5 mostra o resultado desta
consulta realizada nas fontes de dados do Banco Privado.
Nome
| Endereco
| Telefone
| Tipo_Cartao
Mario Krause
| 45 Krause Avenue, Southampton
|
272940105 | débito
Ally Jackson
| 43 Jackson Lane, San Jose
|
27258982 | débito
Tom Thompson
| 17 Thompson Gardens, Winchester
|
273712657 | débito
Craig Atkinson
| 87 Atkinson Street, Edinburgh
|
27972611 | débito
Kostas Atkinson
| 30 Atkinson Street, Edinburgh
| 2712317111 | débito
Craig Thompson
| 122 Thompson Road, San Jose
|
272010467 | débito
Ali Sugden
| 1 Sugden Lane, San Jose
|
273140125 | débito
Mario Krause
| 120 Krause Place, Edinburgh
|
27787831 | débito
Malcolm Dobrzelecki
| 128 Dobrzelecki Street, Edinburgh
|
2742529 | débito
Tom Chue Hong
| 59 Chue Hong Lane, San Jose
|
27112289 | débito
Bartosz Scott
| 26 Scott Place, Edinburgh
|
2737164 | débito
Kostas Anjomshoaa
| 119 Anjomshoaa Crescent, Southampton
|
277592124 | débito
Craig Dobrzelecki
| 25 Dobrzelecki Crescent, Southampton
|
277811829 | débito
David Scott
| 89 Scott Avenue, Southampton
|
27125717 | débito
Ali Atkinson
| 40 Atkinson Crescent, Southampton
| 2710662105 | débito
Craig Krause
| 100 Krause Street, Edinburgh
|
273857 | débito
David Antonioletti
| 80 Antonioletti Road, San Jose
|
27577882 | débito
Bartosz Hume
| 35 Hume Drive, Winchester
|
27809757 | débito
Malcolm Theocharopoulos
| 2 Theocharopoulos Place, Edinburgh
|
2799311 | débito
Neil Theocharopoulos
| 106 Theocharopoulos Place, Edinburgh
|
278861111 | débito
Malcolm Hume
| 81 Hume Lane, San Jose
|
273610267 | débito
67
Tom Scott
| 58 Scott Crescent, Southampton
|
275692124 | débito
Mario Atkinson
| 86 Atkinson Crescent, Southampton
|
274211829 | débito
Mike Theocharopoulos
| 10 Theocharopoulos Avenue, Southampton
|
27105717 | débito
David Anjomshoaa
| 80 Anjomshoaa Crescent, Southampton
|
279162105 | débito
Mario Illingworth
| 120 Illingworth Street, Edinburgh
|
271857 | débito
Mike Sugden
| 115 Sugden Road, San Jose
|
27157882 | débito
Malcolm Chue Hong
| 128 Chue Hong Drive, Winchester
|
27249757 | débito
Ali Krause
| 6 Krause Place, Edinburgh
|
27409311 | débito
Bartosz Krause
| 27 Krause Place, Edinburgh
| 2712361111 | débito
Bartosz Karasavvas
| 95 Karasavvas Gardens, Winchester
|
Ali Chue Hong
| 61 Chue Hong Lane, San Jose
| 2712010267 | débito
2754455 | débito
Mario Hume
| 87 Hume Road, San Jose
| 2711169125 | débito
David Anjomshoaa
| 105 Anjomshoaa Street, Edinburgh
|
27342931 | débito
Ali Scott
| 1 Scott Crescent, Southampton
|
2773843 | débito
Craig Theocharopoulos
| 28 Theocharopoulos Place, Edinburgh
|
27534329 | débito
Malcolm Karasavvas
| 3 Karasavvas Road, San Jose
|
27643689 | débito
Kostas Jackson
| 31 Jackson Lane, San Jose
|
2762960 | débito
Tabela 5 – Resultado Integrado
O resultado mostrado são as duas fontes de dados integradas que foram listadas na
atividade CreatResourceGrup. O SQLBag é o responsável por está realizando a
consulta a estes bancos de dados e é o responsável por integrar os dados enviados
pelas fontes.
68
6. CONCLUSÕES
Computação em Grid tem se tornado muito popular. Muitos projetos têm sido iniciados
para suportar, em parte, a visão de um Grid [FOSTER; KESSELMAN, 1999]. Com
isso, a computação baseada em 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].
Outra tecnologia que tem emergido bastante ultimamente é a integração de dados
feita por um middleware, no nosso caso o OGSA-DAI. Este modo de integrar dados
libera o usuário de ter que gastar muitos recursos para fazer uma integração manual
de dados e mesmo assim ficar limitado a rede local para obter acesso aos dados. O
middleware aqui discutido garante o acesso via Web dos dados mesmo que estes
estejam distribuídos através do mundo, mesmo que sejam de empresas diferentes ou
até mesmo de bancos de dados distintos.
Apesar dessas vantagens ainda existem neste middleware algumas desvantagens na
sua utilização, como por exemplo, a limitação que ele possui em termos de número de
fontes de dados suportadas.
Esse middleware não suporta integração de esquemas diferentes. As fontes de dados
devem possuir o mesmo esquema de tabela, porém, permite que os atributos
possuam tipos diferentes de dados.
Por estarmos utilizando integração de dados em nosso sistema, isto nos oferece
muitas vantagens como o fato de o usuário poder ter uma visão exclusiva dos dados
que foram integrados, e também o fato de que esta integração pode ocorrer sem que
haja a necessidade de modificação das plataformas tecnológicas existentes.
Podemos acrescentar que este middleware chamado OGSA-DAI possui inúmeras
funcionalidades altamente necessárias para serem usadas na maioria das empresas
existentes, fazendo com que ele seja bastante reconhecido por todos.
Futuramente, pode-se utilizar a tecnologia do OGSA-DPQ, sendo um framework de
integração de dados na qual é possível coordenar e incorporar serviços Web para
análise e recuperação de dados, e integrar diferentes tipos de esquemas. Ele utiliza os
serviços
oferecidos
pelo
OGSA-DAÍ
para
geograficamente e com sistemas heterogêneos.
acessar
as
fontes
distribuídas
69
REFERÊNCIAS BIBLIOGRAFICAS
ALDEMIR, N. et al. Ogsa-dqp: A service-based distributed query processor for the
grid. In: UK e-Science All Hands Meeting Nottingham. EPSRC, 2003.
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., 2001. Middleware para Integração de Dados Heterogêneos
Baseado em Composição de Frameworks. Tese de Doutorado, PUC - Rio, Brasil,
2001.
BARBOSA, A. C. P.; PORTO, F.; MELO, R. N. ConFigurable data integration
middleware system. J. Braz. Comp. Soc., v. 8, n. 2, p. 12_19, 2002.
BERSTIS, V. Fundamentals of Grid Computing. Dec 2003. Redbooks.
BIANCARDI, C, 2005. Distribuição e Execução de Wrappers em Ambiente de Grid
para o CoDIMS. Tese de mestrado.
BIANCARDI, C., SILVESTRE, L. J., & BARBOSA, A. C. P., 2005a. Uma abordagem
grid para integração de dados. In Proceedings of the XXVI Iberian Latin-American
Congress on Computational Methods in Engineering CILAMCE 2005
BIANCARDI, C., SILVESTRE, L. J., & BARBOSA, A. C. P., 2005. Uma proposta para
distribuição e execução de wrappers em um ambiente de grid para o codims. In
Proceedings of the WCGA.
BUYYA, R. Grid Computing Info Centre (GRID Infoware). 2002.
CAMPOS JR, M. A., ALVES, H., HIRA, A. Y., ZUFFO, M. K.. Computação em
Gradena Saúde: Proposta de uma Arquitetura Para Interação de Informações
Médicas Distribuídas. São Paulo - SP, Brasil
CASTANO,
S.
et
al.
Ontology-based
integration of
heterogeneous
xml
datasources. In: Proc. of 10th Italian Symposium on Advanced Database Systems SEBD'02. Isola d'Elba, Italy: [s.n.], 2002.
70
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).
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.
FOSTER, I.; KESSELMAN, C. The Grid 2: Blueprint for a New Computing
Infrastructure. Morgan Kaufmann Publishers Inc., 2003.
FOSTER, I.; KESSELMAN, C.; TUECKE, S. Open grid services infrastructure
(OGSI) version 1.0. Global Grid Forum Draft Recommendation, Junho 2003.
GOLDCHLEGER, A. InteGrade: Um Sistema de Middleware para Computação em
Grade Oportunista. Dissertação de Mestrado. USP, São Paulo - SP, Brasil, 2004.
HAKIMPOUR, F. & GEPPERT, A., 2001. Resolving semantic heterogeneity in
schema integration: an ontology based approach. In Proceedings of the
international conference on Formal Ontology in Information Systems, volume 2001, pp.
297–308, USA.
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.
JAKOBOVITS,
REX.
Integrating
Autonomous
Heterogeneous
Information
Sources. Dept. of Computer Science & Engineering, University of Washington. 15 de
Julho de 1997.
KIM, W. (Ed.). Modern database systems: the object model, interoperability, and
beyond. New York, NY, USA: ACM Press/Addison-Wesley Publishing Co., 1995.
MOTRO, A.; BUNEMAN P. Constructing Superviews. In Proc. ACM SIGMOD Int.
Conf. on Management of Data, 1981. http://www.ogsadai.org.uk
71
OGSA-DAI. http://www.ogsadai.org.uk acessado pela última vez em 29 de maio de
2008.
PAPAKONSTANTINOU, Y.; ABITEBOUL, S. GARCIA-MOLINA, H. Object Fusion in
Mediator Systems. Proceedings of the 22nd vldb conference Munbai (Bombay), India,
1996.
PERREIRA BARBOSA, A. C., 2001. Middleware para integração de dados
heterogêneos baseados em composições de frameworks. Tese de Doutorado,
2001, PUC Rio de Janeiro – RJ, Brasil
RODRIGUEZ-MARTINEZ, M.; ROUSSOPOULOS, N. Automatic deployment of
application-specific metadata and code in mocha. In: EDBT'00: Proceedings of the
7th International Conference on Extending Database Technology. [S.l.]: SpringerVerlag, 2000. p. 69_85. ISBN 3-540-67227-3.
SOTOMAYOR, B. The Globus Toolkit 3 Programmer's Tutorial. Dez 2003. Tutorial.
Disponível em: <http://gdp.globus.org/gt3-tutorial/>.
TAKAI, O. K., ITALIANO, I. C., FERREIRA, J. E., 2005. Introdução de banco de
dados: notas de aula. São Paulo – SP, Brasil.
TANENBAUM, A. S. Sistemas distribuídos: Princípios e paradigmas.
TREVISOL,
G.
G.
(2004).
Codims:
Incorporando
nova
abordagem
na
comunicação entre seus componentes. Monografia de Graduação - UFES.
WIEDERHOLD, G. Mediation to deal with heterogeneous data sources. v. 1580,
1999.
72
ANEXO A – MANUAL DO OGSA-DAI
Esse anexo mostra passo a passo os mecanismos necessários para instalação e
configuração do OGSA-DAI.
A. PROGRAMAS NECESSÁRIOS
Para o perfeito funcionamento do middleware OGSA-DAI, é necessário uma serie de
softwares. Abaixo estão listados o software e a versão necessária para o
funcionamento.
a. Jakarta Tomcat
Para usar a distribuição do OGSA-DAI Axis, é necessário a utilização do Jakarta
Tomcat 5.0, podendo realizar o download em http://tomcat.apache.org/download55.cgi#5.0.28. O middleware só foi testado nessa versão e não é compatível com a
versão 5.5.
b. Apache ANT
É recomendada a utilização do ANT versão 1.6 ou superior, podendo realizar o
download em http://ant.apache.org.
c. Java
É
requerido
Java
1.4
ou
1.5,
podendo
realizar
o
download
em
http://java.sun.com/javase/downloads/index.jsp. OGSA-DAI não compila com Java 1.6.
d. Programa de Banco de Dados
É necessário a utilização de um Banco de Dados. Para consulta de quais bancos o
OGSA-DAI suporta, verifique o Capítulo 4 – OGSA-DAI desse artigo.
B. DETALHES DOS BANCOS DE DADOS SUPORTADOS
Cada BD possui diferentes drivers e diferentes URI’s que são requeridas para a
configuração dos bancos, mostrando o caminho para o OGSA-DAI.
a. Drivers dos Bancos de Dados
A tabela 6 são detalhados os drivers necessários para cada banco de dados
compatível com OGSA-DAI.
73
Banco de
Dados
MySQL
IBM DB2
Microsoft
SQL Server
Oracle
PostgreSQL
eXist
Driver
JARs
MySQL Connector
J/2
DB2 JDBC Driver
Microsoft SQL
Server JDBC Driver
Oracle JDBC
Drivers for Java
1.2+
Postgres JDBC
Driver
eXist XMLDB
driver
Classes
mysql-connector-java-5.0.4bin.jar
db2jcc.jar,
db2jcc_licence_cu.jar
mssqlserver.jar, msbase.jar,
msutil.jar
ojdbc14.jar (this may be
distributed in a file with a .zip
- the file can be renamed to
have a .jar extension).
postgresql-8.1-407.jdbc3.jar
org.gjt.mm.mysql.Driver
exist.jar, xmlrpc-1.2patched.jar, xmldb.jar
(xmldb.jar is shipped with
OGSA-DAI).
org.exist.xmldb.DatabaseImpl
com.ibm.db2.jcc.DB2Driver
oracle.jdbc.driver.OracleDriver
oracle.jdbc.driver.OracleDriver
org.postgresql.Driver
Tabela 6 – Drivers de Banco de Dados
b. URI’s dos Bancos de Dados
A Tabela 7 são detalhados as URI’s necessários para cada banco de dados
compatível com OGSA-DAI.
Banco de Dados
Exemplo de URI
MySQL
jdbc:mysql://myhost:3306/daitest
IBM DB2
jdbc:db2://myhost:50000/ogsadai
Microsoft SQL Server
jdbc:microsoft:sqlserver://myhost:1433;DatabaseName=ogsadai
Oracle
jdbc:oracle:thin:@myhost:1521:ogsadai
PostgreSQL
jdbc:postgresql://myhost:5432/ogsadai
eXist
xmldb:exist://myhost:9120/exist/xmlrpc/db/littleblackbook
Tabela 7 – URI’s dos Bancos de Dados
C. Fazendo o Download do OGSA-DA
A Distribuição pode ser baixada do site do OGSA-DAI em http://www.ogsadai.org.uk.
O usuário terá de registrar-se para obter um nome de usuário e senha para acessar os
downloads.
74
D. Criando uma Base de Testes
O OGSA-DAI contém um conjunto de clientes para criar uma base de teste. Para
utilizar esses clientes é preciso obter um driver para o banco de dados e, em seguida,
definir o classpath.
a. Pegando os Drivers do Bancos de Dados
A Tabela 3 contém as informações sobre os bancos de dados suportados pelo OGSADAI e onde se podem obter os drivers dos respectivos bancos.
Deve-se pegar o driver específico com extensão *.JAR para o seu BD e colocar esses
recursos no diretório da distribuição do OGSA-DAI (Figura 45).
OGSA-DAI/thirdparty/lib
Figura 45 – Local onde se localiza os driver dos BD’s no OGSA-DAI
Logo apos o usuário deverá definir a classpath executando o comando da Figura 46
no Prompt de Comando:
$ Setenv.bat
Figura 46 – Classpath
b. Criando uma Base de Testes
OGSA-DAI fornece um conjunto de clientes simples para criar uma tabela chamada
littleblackbook teste de dados que contém quatro colunas:
•
Id - ID único (chave) do tipo INTEGER.
•
Nome - primeiro e apelido do tipo VARCHAR (64).
•
Endereço - endereço do tipo VARCHAR (128).
•
Número de telefone celular do tipo VARCHAR (20).
Para criar uma base de testes, digite o seguinte comando:
o Em DB2: $ Java uk.org.ogsadai.dbcreate.CreateTestDB2DB;
o Em MySQL: $ Java uk.org.ogsadai.dbcreate.CreateTestMySQLDB;
o Em Oracle: $ Java uk.org.ogsadai.dbcreate.CreateTestOracleDB;
o Em PostegreSQL: $ Java uk.org.ogsadai.dbcreate.CreateTestPostgreSQLDB;
o Em SQL Server: $ Java uk.org.ogsadai.dbcreate.CreateTestSQLServerDB
75
E. Implementando OGSA-DAI
Para implantar OGSA-DAI Axis para Tomcat:
Executar o Tomcat e logo depois executar o comando da Figura 47
$ Ant -Dtomcat.dir = / PATH / TO / TOMCAT -Ddai.host = HOST -Ddai.port = PORT
buildDeployWARAndServices
Figura 47 – Comando para criar uma base de dados
Aonde :
PATH / TO / TOMCAT é o caminho para o diretório raiz do Tomcat.
HOST é o acolhimento em que Tomcat está rodando. Este deve ser um bom nome do
host e não localhost.
PORT é a porta em que Tomcat aceita conexões. A porta 8080 e assumida como
padrão.
Um arquivo OGSA-DAI WAR será criado, copiado para o Tomcat. Em seguida, é
implantado um padrão de serviço OGSA-DAI.
Se o serviço de implementação falhar, e o Tomcat não reconhecer o arquivo WAR,
execute o comando da Figura 48.
$ Ant-Dtomcat.dir = / PATH / TO / TOMCAT-Ddai.host = HOST-Ddai.port = PORT
deployServices
Figura 48 – Comando a ser executado caso o serviço de implementação falhar
F. Fazendo teste no servidor
Visite a seguinte link usando um navegador internet:
http://HOST:PORT/dai/services/. Por exemplo: http://localhost:8080/dai/services/.
Onde:
•
HOST é o host em que Tomcat está rodando.
•
PORT é a porta em que Tomcat aceita conexões.
Isto pressupõe que o padrão OGSA-DAI AXIS foi utilizado na implantação.
Se tudo tem corrido bem, você verá uma lista de serviços, incluindo os serviços
OGSA-DAI, mais informação sobre as suas atividades e as suas ligações ao serviço
descrição documentos WSDL.
76
a. A Pagina JSP do OGSA-DAI
Visite a seguinte página usando um navegador internet:
http://HOST:PORT/dai/dai-manager.jsp.
Por exemplo: http://localhost:8080/dai/dai-manager.jsp.
Onde:
•
HOST é o host em que Tomcat está rodando.
•
PORT é a porta em que Tomcat aceita conexões.
Isto pressupõe que o padrão OGSA-DAI foi utilizado na implantação.
Se tudo ocorrer bem você verá informações sobre a versão do OGSA-DAI, a lista de
recursos mobilizados, incluindo o seu recurso de dados, bem como uma lista de
atividades conhecida para o servidor.
b. Realizando uma consulta de teste
A linha de comando da Figura 49 é para executar consultas SQL em uma fonte de
dados e imprimindo os resultados. Você pode especificar o ID da solicitação de dados
da execução dos recursos e o OGSA-DAI irá executar o pedido.
Para executar uma consulta sobre um recurso de dados execute, por exemplo o
seguinte comando:
$ Java uk.org.ogsadai.client.toolkit.example.SQLClient \-u
http://localhost:8080/dai/services/ \-d MyOwnJDBCDataResource \-q "SELECT * FROM
littleblackbook onde id <10"
Figura 49 – Consulta a uma fonte de dados
G. Configurando o Servidor
Para criar um arquivo de recurso relacional createRelationalConfig, execute o
comando da Figura 50.
$ ant -Ddai.db.product=PRODUCT -Ddai.db.vendor=VENDOR -Ddai.db.version=VERSION
\ -Ddai.db.uri=DATABASE-URI -Ddai.db.driver=DATABASE-DRIVER-CLASS \ Ddai.resource.id=RESOURCE-ID createRelationalConfig
Figura 50 – Comando usado para configurar um servidor
77
Isso leva os seguintes argumentos:
•
Dai.db.product - argumento opcional aonde especifica o banco de dados e o
nome do produto.
•
Dai.db.vendor - argumento opcional especificando a base produto.
•
Dai.db.version - argumento opcional aonde especifica o banco de dados e
versão do produto.
•
Dai.db.uri – database da conexão URI. Verifique a Tabela 4 desse artigo.
•
Dai.db.driver - database da classe driver. Verifique a Tabela 3 desse artigo.
•
Dai.resource.id – recurso de dados ID. A identificação dos recursos dos dados
que mostram os dados relacionais. O recurso terá este arquivo ID como o seu
nome.
Por exemplo, a configuração da Figura 51 cria um recurso para os dados do OGSADAI chamado MySQLDataResource que expõe a base de dados do MySQL:
$ Ant-Ddai.db.product = MySQL-Ddai.db.vendor = MySQL-Ddai.db.version = 5 \Ddai.db.uri = jdbc: mysql: / / somehost: 3306/daitest \-Ddai.db . Driver =
org.gjt.mm.mysql.Driver \-Ddai.resource.id = MySQLDataResource
createRelationalConfig
Figura 51 – MySQLDataResource
H. Desistalando o OGSA-DAI
Para desistalar o OGSA-DAI Axis realize as seguintes operações:
1.
Encerre o Tomcat.
2.
Delete os arquivos:
•
PATH / TO / TOMCAT / webapps / dai.
•
PATH / TO / TOMCAT / webapps / dai.war.
•
PATH / TO / TOMCAT / conf / Catalina / localhost / dai.xml.
Onde:
PATH / TO / TOMCAT é o caminho para o diretório da raiz do Tomcat.
Isto pressupõe que o nome do webapps usado quando OGSA-DAI foi implantado foi
executado desse local.
78
ANEXO B – WORKFLOWS
O workflows é um fluxo de trabalho e uma seqüência de atividades que estão ligadas
umas às outras, estas atividades constituem um caminho através do qual irá o controle
de fluxo de dados.
O seguinte método tem como parâmetros as atividades já discutidas e as suas
entradas e saídas conectados adequadamente e adicionadas a um PipelineWorkflow.
A saída do SQLQuery é conectada à entrada do TupleToWebRowSetCharArrays que,
por sua vez, tem sua saída ligada ao CharArraysResize que, por sua vez, tem sua
saída ligada ao DeliverToRequestStatus. Estas atividades são então adicionadas a
todos os fluxos de trabalho utilizando o método acrescentar (Figura 52).
public PipelineWorkflow makePipelineWorkflow(SQLQuery query,
TupleToWebRowSetCharArrays transform,
CharArraysResize
resize, DeliverToRequestStatus delivery)
{
// Create a new pipeline.
PipelineWorkflow tempFlow = new PipelineWorkflow();
// Connect the query output to the transform input.
transform.connectDataInput(query.getDataOutput());
// Connect the transform output to the transform input.
resize.connectDataInput(transform.getResultOutput());
// Connect the transform output to the delivery input.
delivery.connectInput(resize.getOutput());
// Add the activities to the pipeline.
tempFlow.add(query);
tempFlow.add(transform);
tempFlow.add(resize);
tempFlow.add(delivery);
return tempFlow;
}
Figura 52 – PipelineWorkflow
Depois que um fluxo de trabalho foi criado o passo seguinte é o de executá-lo
utilizando o DataRequestExecutionResource (Figura 53).
79
public RequestResource executePipeline(PipelineWorkflow pipe)
throws ServerCommsException,
ServerException,
ResourceUnknownException,
ClientException,
RequestException,
ClientToolkitException
{
return mDRER.execute(pipe, RequestExecutionType.SYNCHRONOUS);
}
Figura 53 – DataRequestExecutionResource
O CTk toma o fluxo de trabalho e envia ao OGSA-DAI para execução de serviço web
que expõe o DRER. O DRER executa o fluxo de trabalho e retorna um pedido de
status. A utilização de uma atividade DeliverToRequestStatus significa que a consulta
retorna os dados do pedido.
Este método retorna um RequestResource em que o CTk o deposita o pedido no
OGSA-DAI servidor. O RequestExecutionType pode ser sincronizado, executa o
método e não retornar até o DRER, sobre o servidor OGSA-DAI, tenha concluído o
fluxo de trabalho ou de execução assíncrono onde o método retorna imediatamente,
mas a DRER sobre o OGSA-DAI servidor irá continuar com o fluxo de trabalho
execução. Em tais casos, o servidor DRER irá criar uma solicitação dos recursos que
o cliente possa, através da enquete RequestResource retornar por este método
A atividade DeliverToRequestStatus irá retornar o status do fluxo de trabalho e os
resultados a partir da sua entrada para a RequestStatus ligado ao objeto.Isto é obtido
através da Figura 54.
RequestResource rr = sqlClient.executePipeline(pipeline);
RequestStatus rs = rr.getRequestStatus();
Figura 54 – DeliverToRequestStatus
Os resultados devem incluir a saída do TupleToWebRowSetCharArrays (os efeitos de
CharArraysResize sejam transparentes em termos de conteúdo dos dados).
A execução do pedido pode ser verificada através da convocação do método
getExecutionStatu e o método RequestStatus sobre o objeto. O código da Figura 55
irá simplesmente imprimir o resultado da execução.
80
RequestStatus rs = rr.getRequestStatus();
System.out.println(rs.getExecutionStatus());
Figura 55 – RequestStatus
E, na maioria dos casos, a Figura 56 deverá ser a saída.
uk.org.ogsadai.resource.request.status.COMPLETED
Figura 56 – RequestStatus completo
Como um exemplo simples de usar os códigos listados, um método principal pode ser
adicionados e utilizado. Lembrando que, a base de serviços URL pode ser alterada,
assim como o comando SQL e os dados dos recursos ID, dependendo do seu servidor
de configuração.
O código da Figura 57 não leva em conta exceções ate este ponto. As primeiras linhas
criam uma consulta SQL e os recursos IDs.
public static void main(String[] args) throws Exception
{
String serverURL = "http://localhost:8080/dai/services/";
ResourceID drerID = new ResourceID("DataRequestExecutionResource");
String sqlStr = "SELECT * FROM littleblackbook WHERE id<3;";
ResourceID dataResourceID = new ResourceID("MySQLDataResource");
SQLClient iSQLClient = new SQLClient();
iSQLClient.setupServer(serverURL);
iSQLClient.setupDRER(drerID);
SQLQuery sqlQ = iSQLClient.makeSQLQuery(dataResourceID, sqlStr);
DeliverToRequestStatus dtrs = iSQLClient.makeDeliverToRequestStatus();
TupleToWebRowSetCharArrays ttwrsca =
iSQLClient.makeTupleToWebRowSetCharArrays();
CharArraysResize car = iSQLClient.makeCharArraysResize();
PipelineWorkflow pwf = iSQLClient.makePipelineWorkflow(sqlQ, ttwrsca, car, dtrs);
RequestResource rr = iSQLClient.executePipeline(pwf);
RequestStatus rs = rr.getRequestStatus();
System.out.println(rs.getExecutionStatus());
}
Figura 57 – Método Principal
81
Antes
de
passar
a
considerar
as
exceções,
a
produção
a
partir
da
TupleToWebRowSetCharArrays pode ser usado de várias maneiras. Isto pode aceder
diretamente à atividade de saída e de obter acesso aos métodos para o formato de
saída resultante em uma tabela.
Primeiro um pequeno método que mostra ao TupleToWebRowSetCharArrays uma
referência direta ao pedido para que ela possa analisá-la. Isso é uma conseqüência da
utilização do CharArraysResize para melhorar o seu rendimento (Figura 58).
private static void setRequestStatus(TupleToWebRowSetCharArrays
tupleToWebRowSet,
DeliverToRequestStatus
deliverToRequestStatus)
{
tupleToWebRowSet.getResultOutput().setDeliverToRequestStatusActivity(deliverToRequ
estStatus);
}
Figura 58 – TupleToWebRowSetCharArrays
A Figura 58 mostra um pequeno método para ajudar a melhorar as strings.
private static String pad(String base, int width)
{
StringBuffer baseBuffer = new StringBuffer(base);
int padLength = width - base.length();
for (int i = 0; i < padLength; i++)
{
baseBuffer.append(" ");
}
return baseBuffer.toString();
}
Figura 59 – strings pad
Depois de escrever o quadro de resultados, a TupleToWebRowSetCharArrays é
acessado diretamente após que o pedido tenha acabado de ser escrito e executando
em uma tabela usando os métodos. O código da Figura 60 irá utilizar o método pad e
escrever a tabela de saída.
82
Public void Printable(TupleToWebRowSetCharArrays tupleToWebRowSet)
throws SQLException,
DataStreamErrorException,
UnexpectedDataValueException,
WebRowSetResultSetParseException,
DataSourceUsageException
{
if (tupleToWebRowSet.hasNextResult())
{
// Get ResultSet.
ResultSet rs = tupleToWebRowSet.nextResultAsResultSet();
// Get ResultSet metadata.
ResultSetMetaData md = rs.getMetaData();
// Get column names and initial column widths.
Int numColumns = md.getColumnCount();
String[] columns = new String[numColumns];
int[] widths = new int[numColumns];
for (int i = 0; i < numColumns; i++)
{
String column = md.getColumnLabel(i + 1);
columns[i] = column;
widths[i] = column.length();
}
// Get ResultSet rows and update column widths also.
Vector rows = new Vector();
while (rs.next())
{
String[] fields = new String[numColumns];
for (int i = 0; i < numColumns; i++)
{
fields[i] = rs.getString(i + 1);
if (fields[i] == null)
{
fields[i] = “null”;
}
widths[i] = Math.max(widths[i], fields[i].length());
83
}
rows.add(fields);
}
rs.close();
// Print column names.
String tableHeading = “| “;
for (int i = 0; i < numColumns; i++)
{
tableHeading += (pad(columns[i], widths[i]) + “ | “);
}
System.out.println(tableHeading);
// Print rows.
For (int j = 0; j < rows.size(); j++)
{
String[] row = (String[])rows.get(j);
String rowString = “| “;
for (int i = 0; i < numColumns; i++)
{
rowString += (pad(row[i], widths[i]) + “ | “);
}
System.out.println(rowString);
}
}
}
Figura 60 – TupleToWebRowSetCharArrays Completo
84
ANEXO C – CODIGO COMPLETO
import java.net.MalformedURLException;
import java.net.URL;
import java.util.Vector;
import java.sql.ResultSet;
import java.sql.ResultSetMetaData;
import java.sql.SQLException;
import uk.org.ogsadai.client.toolkit.DataRequestExecutionResource;
import uk.org.ogsadai.client.toolkit.DataValueIterator;
import uk.org.ogsadai.client.toolkit.PipelineWorkflow;
import uk.org.ogsadai.client.toolkit.RequestExecutionType;
import uk.org.ogsadai.client.toolkit.RequestResource;
import uk.org.ogsadai.client.toolkit.Server;
import uk.org.ogsadai.client.toolkit.ServerProxy;
import uk.org.ogsadai.client.toolkit.activities.block.CharArraysResize;
import uk.org.ogsadai.client.toolkit.activities.delivery.DeliverToRequestStatus;
import uk.org.ogsadai.client.toolkit.activities.sql.SQLQuery;
import uk.org.ogsadai.client.toolkit.activities.transform.TupleToWebRowSetCharArrays;
import uk.org.ogsadai.client.toolkit.exception.ClientException;
import uk.org.ogsadai.client.toolkit.exception.ClientToolkitException;
import uk.org.ogsadai.client.toolkit.exception.RequestException;
import uk.org.ogsadai.client.toolkit.exception.ResourceUnknownException;
import uk.org.ogsadai.client.toolkit.exception.ServerCommsException;
import uk.org.ogsadai.client.toolkit.exception.ServerException;
import uk.org.ogsadai.client.toolkit.exception.DataSourceUsageException;
import uk.org.ogsadai.client.toolkit.exception.DataStreamErrorException;
import uk.org.ogsadai.client.toolkit.exception.UnexpectedDataValueException;
import uk.org.ogsadai.converters.webrowset.WebRowSetResultSetParseException;
import uk.org.ogsadai.resource.ResourceID;
import uk.org.ogsadai.resource.request.RequestStatus;
85
/**
* Example SQL Client
*/
public class SQLClient
{
private Server mServer;
private DataRequestExecutionResource mDRER;
/**
* Constructor
*/
public SQLClient()
{
mServer = null;
mDRER = null;
}
/**
* Method will retrieve an OGSA-DAI server from the parameter
* serverURLstr.
*
* @param serverURLStr
* @throws ClientToolkitException
* @throws MalformedURLException
*/
public void setupServer(String serverURLStr)
throws ClientToolkitException, MalformedURLException
{
mServer = new ServerProxy();
mServer.setDefaultBaseServicesURL(new URL(serverURLStr));
}
/**
86
* Method will get the DRER identified by the ResourceID from the server.
*
* @param drerID
* @throws ClientToolkitException
*/
public void setupDRER(ResourceID drerID)
throws ServerException, ClientToolkitException
{
mDRER = mServer.getDataRequestExecutionResource(drerID);
}
/**
* Method creates a SQLQuery activity for the identified resource
* and given query
* @param dataResourceID
* @param sqlStr
* @return SQLQuery
*/
public SQLQuery makeSQLQuery(ResourceID dataResourceID, String sqlStr)
{
SQLQuery tempQuery = new SQLQuery();
tempQuery.setResourceID(dataResourceID);
tempQuery.addExpression(sqlStr);
return tempQuery;
}
/**
* Creates a new DeliverToRequestStatus activity
* @return DeliverToRequestStatus
*/
public DeliverToRequestStatus makeDeliverToRequestStatus()
{
87
return new DeliverToRequestStatus();
}
/**
* Creates a new TupleToWebRowSetCharArrays activity
* @return TupleToWebRowSetCharArrays
*/
public TupleToWebRowSetCharArrays makeTupleToWebRowSetCharArrays()
{
return new TupleToWebRowSetCharArrays();
}
/**
* Creates a new CharArraysResize activity
* @return CharArraysResize
*/
public CharArraysResize makeCharArraysResize()
{
CharArraysResize resize = new CharArraysResize();
resize.addArraySizeInput(5000);
return resize;
}
/**
*
* Creates a new pipelineworkflow for the three activities.
* Connects the activities, query-transform-delivery
* @param query
* @param transform
* @param delivery
* @return PipelineWorkflow
*/
public PipelineWorkflow makePipelineWorkflow(SQLQuery query,
88
TupleToWebRowSetCharArrays transform,
CharArraysResize resize,
DeliverToRequestStatus delivery)
{
PipelineWorkflow tempFlow = new PipelineWorkflow();
transform.connectDataInput(query.getDataOutput());
resize.connectDataInput(transform.getResultOutput());
delivery.connectInput(resize.getOutput());
tempFlow.add(query);
tempFlow.add(transform);
tempFlow.add(resize);
tempFlow.add(delivery);
return tempFlow;
}
/**
* Executes a pipelineworkflow in a synchronous mode and returns
* a requestResource
*
* @param pipe
* @return RequestResource
* @throws ServerCommsException
* @throws ServerException
* @throws ResourceUnknownException
* @throws ClientException
* @throws RequestException
* @throws ClientToolkitException
*/
public RequestResource executePipeline(PipelineWorkflow pipe)
throws ServerCommsException,
ServerException,
ResourceUnknownException,
ClientException,
89
RequestException,
ClientToolkitException
{
return mDRER.execute(pipe, RequestExecutionType.SYNCHRONOUS);
}
/**
* Prints a table format to standard output using the data from the
* transform activity passed in as parameter.
*
* @param tupleToWebRowSet
* @throws SQLException
* @throws DataStreamErrorException
* @throws UnexpectedDataValueException
* @throws WebRowSetResultSetParseException
* @throws DataSourceUsageException
*/
public void printTable(TupleToWebRowSetCharArrays tupleToWebRowSet)
throws SQLException,
DataStreamErrorException,
UnexpectedDataValueException,
WebRowSetResultSetParseException,
DataSourceUsageException
{
if (tupleToWebRowSet.hasNextResult())
{
// Get ResultSet.
ResultSet rs = tupleToWebRowSet.nextResultAsResultSet();
// Get ResultSet meta data.
ResultSetMetaData md = rs.getMetaData();
// Get column names and initial column widths.
Int numColumns = md.getColumnCount();
String[] columns = new String[numColumns];
90
int[] widths = new int[numColumns];
for (int i = 0; i < numColumns; i++)
{
String column = md.getColumnLabel(i + 1);
columns[i] = column;
widths[i] = column.length();
}
// Get ResultSet rows and update column widths also.
Vector rows = new Vector();
while (rs.next())
{
String[] fields = new String[numColumns];
for (int i = 0; i < numColumns; i++)
{
fields[i] = rs.getString(i + 1);
widths[i] = Math.max(widths[i], fields[i].length());
}
rows.add(fields);
}
rs.close();
// Print column names.
String tableHeading = “| “;
for (int i = 0; i < numColumns; i++)
{
tableHeading += (pad(columns[i], widths[i]) + “ | “);
}
System.out.println(tableHeading);
// Print rows.
For (int j = 0; j < rows.size(); j++)
{
String[] row = (String[])rows.get(j);
String rowString = “| “;
for (int i = 0; i < numColumns; i++)
91
{
rowString += (pad(row[i], widths[i]) + “ | “);
}
System.out.println(rowString);
}
}
}
/**
* Pads out a string to the width given as parameter
* @param base
* @param width
* @return String
*/
private static String pad(String base, int width)
{
StringBuffer baseBuffer = new StringBuffer(base);
int padLength = width – base.length();
for (int i = 0; i < padLength; i++)
{
baseBuffer.append(“ “);
}
return baseBuffer.toString();
}
/**
* Allow TupleToWebRowSetCharArrays access to the request status.
*
* @param transform
* @param delivery
*/
private static void setRequestStatus(TupleToWebRowSetCharArrays
tupleToWebRowSet,
92
DeliverToRequestStatus
deliverToRequestStatus)
{
tupleToWebRowSet.getResultOutput().setDeliverToRequestStatusActivity(deliverToRequ
estStatus);
}
public static void main(String[] args) throws Exception
{
// Setup
String serverURL = “http://localhost:8080/dai/services/”;
ResourceID drerID = new ResourceID(“DataRequestExecutionResource”);
SQLClient iSQLClient = new SQLClient();
ResourceID dataResourceID = new ResourceID(“MySQLDataResource”);
String sqlStr = “SELECT * FROM littleblackbook WHERE id<3;”;
// Server
iSQLClient.setupServer(serverURL);
iSQLClient.setupDRER(drerID);
// Activities Creation
SQLQuery sqlQ = iSQLClient.makeSQLQuery(dataResourceID, sqlStr);
DeliverToRequestStatus dtrs = iSQLClient.makeDeliverToRequestStatus();
TupleToWebRowSetCharArrays ttwrsca =
iSQLClient.makeTupleToWebRowSetCharArrays();
CharArraysResize car = iSQLClient.makeCharArraysResize();
// Workflow and Execution
PipelineWorkflow pwf = iSQLClient.makePipelineWorkflow(sqlQ, ttwrsca, car, dtrs);
RequestResource rr = iSQLClient.executePipeline(pwf);
RequestStatus rs = rr.getRequestStatus();
// outputs
93
System.out.println(rs.getExecutionStatus());
iSQLClient.setRequestStatus(ttwrsca, dtrs);
iSQLClient.printTable(ttwrsca);
}
}
Figura 61 – Código Completo
94
ANEXO D – PERGUNTAS E RESPOSTAS
1 - Como representar uma fonte de dados no OGSA-DAI?
Primeiramente, é preciso obter as informações das fonte de dados desejada, como por
exemplo, a URI da fonte de dados, o driver e a versão desta fonte. Com isso em mãos
é preciso criar um resource file contendo os argumentos necessários. O próximo
passo é fazer o transporte deste resource file para o servidor Tomcat que está
configurado na sua máquina.
2 - Como representar uma consulta no OGSA-DAI para as fontes que estão
sendo integradas?
O OGSA-DAI possui classes que realizam consultas em bancos de dados. Uma URI,
um resource file e um comando SQL são os parâmetros necessários para fazer uma
consulta em uma fonte de dados integrada ao OGSA-DAI. Todos estes parâmetros
devem estar incluídos numa classe específica do OGSA-DAI que é utilizada para fazer
acesso ao banco.
3 - Existe um esquema global para a elaboração de consulta global ou tenho que
consultar o esquema de cada fonte?
O OGSA-DAI não possui a funcionalidade de estar construindo um esquema global,
pois os esquemas de todas as fontes de dados que forem listados no
CreatresourceGrupo devem conter o mesmo esquema, portanto a atividade SQLBag
tem a função de realizar a mesmo consulta SQL a todas as fontes.
4 - Como a consulta é dividida em sub-consultas e enviadas para as fontes de
dados envolvidas?
Não existe um esquema a global, pois todas as fontes devem possuir o mesmo
esquema. Assim a mesma consulta é enviada para todas as fontes através de
atividades oferecidas pelo OGSA-DAI.
Portanto existem atividades no OGSA-DAI capazes de realizar acesso a múltiplos
bancos de dados. A primeira atividade a ser criada e a CreatResourceGrup, nesta
atividade e criado um grupo de banco de dados que serão integrados. Logo após criar
um grupo de banco é necessária criar outra atividade que realize a consulta nas fontes
95
de dados listadas, o SQLBag que tem como funcionalidade executar um comando
SQL em todos os bancos listados na atividade CreatResourceGrup.
5 - Como os resultados das sub-consultas são integrados?
A integração dos resultados das sub-consultas é feita pela atividade SQLBag, que
coleta todos os resultados da query e os coloca em um único result set que também
incluirá linhas duplicadas, caso existam.Caso seja enviado mais do que uma consulta
para as fontes de dados, cada consulta terá o seu result set.
6 - Quais os recursos que o OGSA-DAI oferece para acesso à fonte?
O OGSA-DAI, oferece inúmeras atividades que possibilitam acesso a fontes de dados
heterogêneas. Além de possuir essas atividades o OGSA-DAI libera o usuário de estar
criando novas atividades, pois o OGSA-DAI possui código aberto.
Possibilita ao usuário de estar realizando mudanças nas fontes de dados, como por
exemplo, realizar um up-date, um delete, colocar ou retira linhas ou colunas na tabela.