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.
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
“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.”
Dedicamos esse trabalho aos nossos pais, pois sem eles, nada disso seria possível.
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.
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.
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.
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 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 56 – RequestStatus Completo ... 80
Figura 57 – Método Principal ... 80
Figura 58 – TupleToWebRowSetCharArrays ... 81
Figura 59 – Strings Pad ... 81
Figura 60 – TupleToWebRowSetCharArrays Completo ... 82
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
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
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 ... 182.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.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
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
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
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.
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].
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].
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.
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
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
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
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
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
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
• 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
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
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
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.
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).
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].
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
Para uma descrição mais detalhada do processo de configuração consulte [BARBOSA, 2001].
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].
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,
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].
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.
[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
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 Versão Suportada Observações
Relacional
MySQL 3.2.3 em diante Detalhes em www.mysql.com
IBM DB2 --- OGSA-DAI não suporta a
criação ou deleção de bancos de dados usando BD2 .
Microsoft SQL Server --- Não Suporta a coluna IMAGE
no OGSA-DAI.
Oracle 10g Enterprise Edition 10.2.0.1.0 OGSA-DAI não suporta a
criação ou deleção de base de dados usando Oracle.
PostgreSQL --- Detalhes em
www.postgresql.org XML
EXist Feito desde 03/12/2005 É recomendável que a
instalação do eXist ocorra dentro de um contêiner com seus próprios serviços Web. Arquivos
Sistema de arquivos --- 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.
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).
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
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.
• 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.
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)
