INTEGRAÇÃO DE DADOS USANDO OGSA-DAI

Transcrição

1 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 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 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 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 4 Dedicamos esse trabalho aos nossos pais, pois sem eles, nada disso seria possível.

5 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.

6 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 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 8 LISTA DE FIGURAS Figura 01 Middleware para Integração de dados Figura 02 Wrappers Figura 03 ConFiguração Básica do CoDINS Figura 04 O CoDINS e seus Componentes Básicos Figura 05 Arquitetura do CoDINS-G Figura 06 Arquitetura do MOCHA Figura 07 Arquitetura do OGSA-DPQ Figura 08 Interação entre os frameworks OGSA-DPQ e OGSA-DAI Figura 09 Funcionamento do OGSA-DAI Figura 10 Arquitetura do OGSA-DAI Figura 11 Data Service Resourse Figura 12 Documento de desempenho contendo elemento de sessão (session element), elemento de atividade (activity element) e um ponto final (end-point) Figura 13 Exemplo de documento de desempenho Figura 14 Documento de resposta resultante do documento de desempenho Figura 15 Exemplo de Documento de Desempenho enviado de forma Síncrona Figura 16 Documento de resposta contendo os dados resultantes Figura 17 Interação usando uma interface orientada a documentos Figura 18 Exemplo de Entrega de dados Figura 19 Resourse File Figura 20 Consulta realizada pelo Cliente Figura 21 Servidor Proxy do OGSA-DAI Figura 22 DataRequestExecutionResource Figura 23 SQL Query Figura 24 TupleToWebRowSetCharArrays Figura 25 CharArraysResize Figura 26 DeliverToRequestStatus... 53

9 9 Figura 27 Recursos Figura 28 Recursos Passados como Parâmetros Figura 29 Pedido Entregue ao Cliente Figura 30 Pedido Disponível Figura 31 sqlbag Figura 32 Consulta realizada pelo sqlbag Figura 33 Atividade TupleToWebRowSetCharArrays Figura 34 TupleToWebRowSetCharArrays.nextResult Figura 35 sqlupdatestatement Figura 36 sqlparameter Figura 37 Esquema da Fonte Relacional littleblackbook da Matriz Figura 38 Esquema da fonte Relacional littleblackbook da Filial Figura 39 Consulta na linguagem SQL Figura 40 Diagrama de Implantação Figura 41 SQLServer Figura 42 OracleSQL Figura 43 Modelo de grupo de fonte de dados Figura 44 Modelo de consulta Figura 45 Local onde se localiza os driver dos BD s no OGSA-DAI Figura 46 Classpath Figura 47 Comando para criar uma base de dados Figura 48 Comando a ser executado caso o serviço de implementação falhar Figura 49 Consulta a uma fonte de dados Figura 50 Comando usado para configurar um servidor Figura 51 MySQLDataResource TupleToWebRowSetCharArrays Figura 52 PipelineWorkflow Figura 53 DataRequestExecutionResource Figura 54 DeliverToRequestStatus Figura 55 RequestStatus... 80

10 10 Figura 56 RequestStatus Completo Figura 57 Método Principal Figura 58 TupleToWebRowSetCharArrays Figura 59 Strings Pad Figura 60 TupleToWebRowSetCharArrays Completo Figura 61 Código Completo... 84

11 11 LISTA DE TABELAS Tabela 1 Tecnologias Suportadas pelo OGSA-DAI Tabela 2 Assessores de dados Fornecidos pelo OGSA-DAI Tabela 3 Resultado da Consulta da Matriz (MySQL) Tabela 4 Resultado da Consulta da Filial (Oracle) Tabela 5 Resultado Integrado Tabela 6 Drivers de Banco de Dados Tabela 7 URI s de Banco de Dados... 73

12 12 LISTA DE ABREVIAÇÕES E SIGLAS API BD CoDIMS CORBA DAP DB DBA DBMS DRER EJB ERE GT JDBC MOCHA OGSA OGSA-DAI OGSA-DPQ QPC SGBD SOAP SQL WSI WSRF XML XLS Application Programming Interface Banco de Dados ConFigurable Data Integration Middleware System Commom Object Request Broker Arquitecture Data Access Provider DataBase DataBase Administrator Database Management System Data Request Execution Resource Enterprise JavaBeans Entidade Relacionamento Estendido Globus Tookit Java Database Connectivity Middleware Based on a Code Shipping Architecture Open Grid Service Architecture Open Grid Service Architecture - Data Access and Integration Open Grid Service Architecture - Distributed Query Processor Query Processing Coordinator Sistema de Gerenciamento de Banco de Dados Service Oriented Architecture Protocol Structured Query Language Web Services Inter-Operability Web Services Resourses Framework extensible Markup Language extensible Stylesheet Language

13 13 SUMÁRIO 1. INTRODUÇÃO Objetivo Geral Específico Organização do Trabalho CONCEITOS E TECNOLOGIAS Integração de Dados Introdução Middleware para Integração de Dados Wrappers Principais Dificuldades para Integração Conflitos para Integração Tipos de Esquema Vantagens e Desvantagens Computação Distribuída Definição Cluster Grid Visão Geral Características Benefícios Grid VS Computação Distribuída Grid VS Cluster TRABALHOS RELACIONADOS Introdução CoDIMS CoDIMS-G... 33

14 Mocha OGSA-DPQ OPEN GRID SERVICE ARCHITECTURE DATA AND INTEGRATION Introdução Arquitetura do OGSA-DAI Camada de Dados Interface entre a Camada de Dados e a Camada Lógica de Negócios Camada Lógica de Negócios Interface entre a Camada de Lógica de Negócios e a Camada de Aplicação Camada de Apresentação Camada de Cliente Serviços de Dados Operações Usando Dados Recursos de Serviços de Dados Assessor de Recursos de Dados Relacionamento Especificação Funcional Representando uma Fonte de Dados Fluxograma de Execução Modificando um Banco de Dados Vantagens Desvantagens ESTUDO DE CASO Descrição da Aplicação Resourse File dos Bancos de Dados Criando um Grupo de Fonte de Dados Criando Uma Consulta Resultado da Consulta... 65

15 15 6. CONCLUSÕES REFERÊNCIAS BIBLIOGRÁFICAS ANEXO A MANUAL DE INSTRUÇÃO DO OGSA-DAI ANEXO B WORKFLOWS ANEXO C CÓDIGO COMPLETO ANEXO D Perguntas e Respostas... 94

16 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 Objetivos 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 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 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 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 Integração de Dados 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 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 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] 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 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] 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 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 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] 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 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] 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 Computação Distribuída 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 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] GRID 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 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 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 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 Benefícios Segundo [BERSTIS, 2003], os benefícios que o Grid possui são os seguintes:

27 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 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 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 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 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] 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 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 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 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 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 metadados 1 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 LNCC 2 com o objetivo de suportar aplicações de visualização científicas executando em um ambiente de Grid 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]. 2 Laboratório Nacional de Computação Científica -

34 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 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 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 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 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 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 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 Versão Suportada Observações Relacional MySQL em diante Detalhes em 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 OGSA-DAI não suporta a criação ou deleção de base de dados usando Oracle. PostgreSQL --- Detalhes em 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.

40 40 Figura 10 - Arquitetura do OGSA-DAI 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 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 41 Figura 11 Data Service Resource 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 42 para expor os datos, por exemplo, o status de um pedido ou um esquema de recurso de dados adjacente 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 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 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) 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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> </ 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 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 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 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 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 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 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 "littleblackbook 1 ", 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.