CENTRO UNIVERSITRIO DE VILA VELHA

CURSO DE CINCIA DA COMPUTAO

INTEGRAO DE DADOS USANDO OGSA-DAI

Elmo Laurenzoni Neto Leonardo de Medeiros Magalhes Lucas Calvi Costa

Monografia desenvolvida durante a disciplina de Trabalho de Concluso de Curso apresentada ao Curso de Cincia da Computao do Centro Universitrio de Vila Velha, como requisito parcial para a obteno do ttulo de Bacharel em Cincia da Computao, sob orientao do prof. Cristiano Biancardi.

Vila Velha, Junho de 2008

ELMO LAURENZONI NETO LEONARDO DE MEDEIROS MAGALHES LUCAS CALVI COSTA

Integrao de dados Usando OGSA-DAI

Monografia do Trabalho de Concluso de Curso de Graduao em Cincia da Computao apresentada ao Centro Universitrio Vila Velha, como requisito parcial para a obteno do ttulo de Bacharel em Cincia da Computao.

Aprovada em ____ de ___________________ de 2008.

COMISSO EXAMINADORA

_________________________________________ Prof. Cristiano Biancardi Mestre em Informtica. Centro Universitrio de Vila Velha Orientador

_________________________________________ Prof. Otaclio Pereira Jos Pereira Mestre em Informtica. Centro Universitrio de Vila Velha

_________________________________________ Prof. Vincius Rosalen Mestre em Cincia da Computao. Centro Universitrio de Vila Velha

Houve um tempo em que se fazia cincia a partir de quatro elementos: gua, Terra, Fogo e Ar. Naquele tempo no se sabia que podia fazer qualquer coisa com apenas dois: Vontade e Determinao. <Autor Desconhecido>

Dedicamos esse trabalho aos nossos pais, pois sem eles, nada disso seria possvel.

AGRADECIMENTOS

Agradecemos aos nossos Pais, pelo apoio e pacincia 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 contribuies que foram fundamentais para a concluso desse trabalho. As nossas namoradas Juliana e Gabriella pela compreenso de no estarmos presentes em determinados momentos, pelo companheirismo e principalmente pelas ajudas prestadas para finalizarmos esse trabalho. A todos aqueles que de alguma forma contriburam para completar o nosso objetivo. Por fim, agradecemos principalmente a Deus, por nos dar fora para superar as barreiras que nos impediam e alcanar o nosso objetivo.

RESUMO
Integrao de dados promove a juno de dados atravs de um aplicativo liberando o usurio da necessidade de integrar dados manualmente. Isto importante porque, atualmente, a quantidade de dados disponveis est cada vez maior sendo necessrio o uso de um sistema capaz de realizar essa integrao. Recentemente, ambiente de Grid tem se mostrado como uma boa alternativa para a utilizao, de forma segura, coordenada, eficiente e transparente, de recursos computacionais geograficamente dispersos. No que diz respeito integrao de dados em ambiente de Grid tem-se o OGSA-DAI, um middleware que assiste ao acesso e integrao 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 investigao da arquitetura do OGSA-DAI e a descrio de uma aplicao para promover a integrao de dados de dois Bancos de Dados distintos.

Palavras-chave: Integrao de dados; Grid; OGSA-DAI.

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.

LISTA DE FIGURAS
Figura 01 Middleware para Integrao de dados. .................................................... 19 Figura 02 Wrappers. ................................................................................................ 21 Figura 03 ConFigurao Bsica do CoDINS ............................................................ 32 Figura 04 O CoDINS e seus Componentes Bsicos ................................................ 33 Figura 05 Arquitetura do CoDINS-G ........................................................................ 34 Figura 06 Arquitetura do MOCHA ............................................................................ 35 Figura 07 Arquitetura do OGSA-DPQ ...................................................................... 36 Figura 08 Interao 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 sesso (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 Sncrona..... 46 Figura 16 Documento de resposta contendo os dados resultantes. ......................... 46 Figura 17 Interao usando uma interface orientada a documentos. ....................... 47 Figura 18 Exemplo de Entrega de dados. ................................................................ 48 Figura 19 Resourse File. .......................................................................................... 49 Figura 20 Consulta realizada pelo Cliente. ............................................................... 50 Figura 21 Servidor Proxy do OGSA-DAI .................................................................. 51 Figura 22 DataRequestExecutionResource ............................................................. 51 Figura 23 SQL Query ............................................................................................... 52 Figura 24 TupleToWebRowSetCharArrays .............................................................. 52 Figura 25 CharArraysResize .................................................................................... 53 Figura 26 DeliverToRequestStatus .......................................................................... 53

9
Figura 27 Recursos.................................................................................................. 54 Figura 28 Recursos Passados como Parmetros .................................................... 54 Figura 29 Pedido Entregue ao Cliente ..................................................................... 54 Figura 30 Pedido Disponvel .................................................................................... 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 Implantao ........................................................................ 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 BDs 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 servio de implementao falhar ........ 75 Figura 49 Consulta a uma fonte de dados ............................................................... 76 Figura 50 Comando usado para configurar um servidor .......................................... 76 Figura 51 MySQLDataResource TupleToWebRowSetCharArrays ........................... 77 Figura 52 PipelineWorkflow ..................................................................................... 78 Figura 53 DataRequestExecutionResource ............................................................. 79 Figura 54 DeliverToRequestStatus .......................................................................... 79 Figura 55 RequestStatus ......................................................................................... 80

10
Figura 56 RequestStatus Completo ......................................................................... 80 Figura 57 Mtodo Principal ...................................................................................... 80 Figura 58 TupleToWebRowSetCharArrays .............................................................. 81 Figura 59 Strings Pad .............................................................................................. 81 Figura 60 TupleToWebRowSetCharArrays Completo .............................................. 82 Figura 61 Cdigo Completo ..................................................................................... 84

11

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

12

LISTA DE ABREVIAES 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

SUMRIO
1. INTRODUO........................................................................................................ 16 1.1. Objetivo ............................................................................................................................ 16 1.1.1 Geral ........................................................................................................................... 16 1.1.1 Especfico.................................................................................................................... 16 1.2. Organizao do Trabalho ................................................................................................. 17 2. CONCEITOS E TECNOLOGIAS............................................................................. 18 2.1. Integrao de Dados......................................................................................................... 18 2.1.1. Introduo ................................................................................................................. 18 2.1.2. Middleware para Integrao de Dados ..................................................................... 19 2.1.3. Wrappers................................................................................................................... 20 2.1.4. Principais Dificuldades para Integrao .................................................................... 21 2.1.5. Conflitos para Integrao .......................................................................................... 21 2.1.6. Tipos de Esquema ..................................................................................................... 22 2.1.7. Vantagens e Desvantagens ....................................................................................... 23 2.2. Computao Distribuda ................................................................................................... 24 2.2.1. Definio ................................................................................................................... 24 2.2.2. Cluster ....................................................................................................................... 24 2.3. Grid ................................................................................................................................... 24 2.3.1. Viso Geral ................................................................................................................ 24 2.3.2. Caractersticas ........................................................................................................... 26 2.3.3. Benefcios .................................................................................................................. 26 2.3.4. Grid VS Computao Distribuda ............................................................................... 29 2.3.5. Grid VS Cluster .......................................................................................................... 30 3. TRABALHOS RELACIONADOS ............................................................................. 31 3.1. Introduo ........................................................................................................................ 31 3.2. CoDIMS ............................................................................................................................. 31 3.2.1. CoDIMS-G .................................................................................................................. 33

14
3.3. Mocha............................................................................................................................... 35 3.4. OGSA-DPQ ........................................................................................................................ 36 4. OPEN GRID SERVICE ARCHITECTURE DATA AND INTEGRATION ................ 38 4.1. Introduo ........................................................................................................................ 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 Lgica de Negcios ...................... 40 4.2.3. Camada Lgica de Negcios ...................................................................................... 41 4.2.4. Interface entre a Camada de Lgica de Negcios e a Camada de Aplicao............ 42 4.2.5. Camada de Apresentao ......................................................................................... 43 4.2.6. Camada de Cliente .................................................................................................... 43 4.3. Servios de Dados............................................................................................................. 43 4.3.1. Operaes Usando Dados ......................................................................................... 44 4.4. Recursos de Servios de Dados ........................................................................................ 46 4.5. Assessor de Recursos de Dados ....................................................................................... 47 4.6. Relacionamento ............................................................................................................... 47 4.7. Especificao Funcional .................................................................................................... 48 4.7.1. Representando uma Fonte de Dados........................................................................ 48 4.7.2. Fluxograma de Execuo ........................................................................................... 50 4.8. Modificando um Banco de Dados .................................................................................... 57 4.9. Vantagens ......................................................................................................................... 58 4.10. Desvantagens ................................................................................................................. 59 5. ESTUDO DE CASO ................................................................................................ 60 5.1. Descrio da Aplicao ..................................................................................................... 60 5.2. Resourse File dos Bancos de Dados .................................................................................. 62 5.3. Criando um Grupo de Fonte de Dados ............................................................................. 63 5.4. Criando Uma Consulta...................................................................................................... 64 5.5. Resultado da Consulta ...................................................................................................... 65

15
6. CONCLUSES....................................................................................................... 68 REFERNCIAS BIBLIOGRFICAS ............................................................................ 69 ANEXO A MANUAL DE INSTRUO DO OGSA-DAI ............................................. 72 ANEXO B WORKFLOWS ........................................................................................ 78 ANEXO C CDIGO COMPLETO ............................................................................ 84 ANEXO D Perguntas e Respostas ........................................................................... 94

16

1. INTRODUO
Atualmente est disponvel um grande volume de dados, essencialmente heterogneos e distribudos, devido principalmente disseminao 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 comunicao e hardware. Assim, cresce o nmero de aplicaes que demandam acesso a tais dados atravs de uma viso integrada, uniforme e homognea, em um tempo cada vez menor. Com um grande aumento de sistema informatizado espalhados pelo mundo a integrao de dados tem ficado cada vez mais necessria, e conseqentemente a implementao de sistemas capazes de tal interao. Assim, importante conseguir combinar banco de dados e tecnologias relacionadas para incrementar o uso da informao. Recentemente, o ambiente de Grid tem se mostrado como uma boa alternativa para a utilizao, de forma segura, coordenada, eficiente e transparente, de recursos computacionais geograficamente dispersos. No que diz respeito integrao de dados em ambiente de Grid tem-se o OGSA-DAI, que um middleware que assiste no acesso e na integrao de dados a partir de fontes de dados separadas via ambiente de Grid. Este middleware tambm concede ao usurio a facilidade da utilizao de servios 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 aplicao para integrao de dados heterogneos e distribudos usando essa tecnologia. 1.1.2. Especfico Estudo do ambiente Grid e integrao de dados Investigao da arquitetura do OGSA-DAI e como feita a integrao de dados do mesmo Configurao e Instalao do OGSA-DAI Anlise, projeto e implementao em um estudo de caso usando OGSA-DAI.

17
1.2. Organizao do Trabalho

No captulo 2 so apresentados alguns conceitos e tecnologias estudadas para a realizao desse estudo, como por exemplo: Integrao de Dados, Computao Distribuda, Cluster, Grid; No captulo 3 so apresentados alguns trabalhos sobre integrao de dados heterogneos e distribudos, relacionados com o presente trabalho; O captulo 4 apresenta o estudo da tecnologia OGSA-DAI, incluindo sua coleo de componentes para a manipulao de dados e sua coleo de ferramentas para desenvolver aplicaes de clientes. No captulo 5 apresentado o estudo de caso; No captulo 6 apresenta a concluso desse trabalho.

18

2. CONCEITOS E TECNOLOGIAS
Esse captulo tem como objetivo mostrar o conceito, as vantagem e desvantagens do uso da integrao de dados. 2.1. Integrao de Dados

2.1.1. Introduo Integrao de dados refere-se a combinar dados heterogneos e distribudos de forma que uma nica viso, uniforme e homognea, seja apresentada para o usurio [HAKIMPOUR; GEPPERT; 2001]. Para tanto, sistemas de integrao de dados vm sendo desenvolvidos com a finalidade de integrar um grande nmero de fontes de dados heterogneas, desenvolvidas independentemente. O objetivo maior desses sistemas liberar o usurio de ter que localizar as fontes de dados, interagir com cada uma isoladamente e combinar os dados das mltiplas fontes de dados manualmente [HAKIMPOUR; GEPPERT, 2001; HALEVY, 2003]. Para gerenciar dados em mltiplos bancos de dados, necessrio lidar com a distribuio dos SGBDs. O acesso integrado a bases de dados distribudas e heterogneas um dos grandes problemas encontrados pelas organizaes, sendo um dos grandes problemas tambm na comunidade de banco de dados. Para proporcionar interoperabilidade entre sistemas heterogneos, deve-se estabelecer uma viso global e uniforme para dados e servios [KALINICHENKO, 1999]. A integrao de um modelo global e a adio de uma camada de software so umas das tcnicas utilizadas para integrar a base de dados distribudos. No primeiro caso, a definio do modelo conceitual global realizada atravs da comparao entre modelos conceituais locais, identificao de equivalncia, identificao e resoluo de conflitos [MRCIO PICOSSI SCHNEIDER, 2004]. J no segundo caso, uma camada de software providencia a integrao a partir da definio de regras entre os participantes. Esta camada muitas vezes citada como mediador, e tambm tem a finalidade de fundir as informaes de fontes de dados heterogneas removendo redundncias e resolvendo inconsistncias [PAPAKONSTANTINOU, ABITEBOUL, 1996].

19
2.1.2. Middleware para Integrao de Dados Middleware um componente de software que tem a finalidade de interligar processos clientes a processos servidores, disponibilizando um conjunto de servios e visando reduzir a complexidade do desenvolvimento e da execuo de uma aplicao [BARBOSA; 2001]. uma designao genrica utilizada para se referir ao software que executado entre os usurios e o servidor em um sistema de banco de dados cliente/servidor [JAKOBOVITS, 1997]. Um middleware tambm pode ser definido como uma camada existente entre o cliente, a rede, os sistemas operacionais e dos possveis servidores de recurso, mais focalizado em servidores de dados. constitudo, na maioria das vezes, por mdulos que possuem APIs de alto nvel, proporcionando a sua integrao com sistemas desenvolvidos em diversas linguagens de programao e APIs de baixo nvel, permitindo a independncia relativa ao dispositivo. Seu objetivo ocultar a heterogeneidade e fornecer um modelo de programao mais produtivo para os programadores de aplicativos. composto por um conjunto de processos em um determinado grupo de computadores, implementando uma comunicao e oferecendo suporte para compartilhamento de recursos aos aplicativos distribudos. O objetivo de um middleware para integrao de dados (Figura 1) fornecer informao integrada sem a necessidade de se integrar as fontes de dados, ou seja, um mediador permite a interoperao de informao, somente selecionando resultados derivados das fontes de dados [KIM, 1995] [WIEDERHOLD, 1999].

Figura 1 Middleware para Integrao de dados

20

Para viabilizar a integrao de dados, torna-se necessrio realizar a integrao 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 necessrio, inicialmente, transformar todos os esquemas para um mesmo modelo de dados, denominado de Modelo de Dados Comum (MDC). No caso de sistemas componentes no baseados em banco de dados, dever existir um mecanismo que simule a existncia de um esquema, metadados, para permitir o processo de integrao. 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 transformao denominado de esquema de exportao. Um esquema global, ou federado, descrito no MDC, ento criado pela integrao de mltiplos esquemas de exportao. Finalmente, so definidos os esquemas externos, vises, sobre o esquema global, para atender s necessidades de um grupo especfico de usurios ou de aplicaes, ou ainda, por razes de controle de acesso. Para efetuar a traduo entre modelos, esquema externo para esquema local, so utilizados os wrappers que so os W1, W2, W3 e Wn na Figura 1 [BIANCARDI, 2005]. 2.1.3. Wrappers So programas que encapsulam fontes de dados e so usados para fazer a traduo 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. Atravs do uso de Wrappers, pode-se transformar uma fonte de dados em uma forma mais estruturada (BARBOSA, 2001). Os Wappers so utilizados para apresentar uma interface simples e funcional de uma interface interna de um banco de dados. Na Figura 2 so exibidas trs 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 integrao de dados.

21

Figura 2 Wrappers

Para realizar a seleo de um Wrapper, a ser usado pelo middleware, devem ser analisadas quais as fontes de dados sero tratadas pelos mesmos, se elas esto bem documentadas, quais so as suas funes, como foram construdas e as arquiteturas internas das fontes [BIANCARDI, 2005]. 2.1.4. Principais Dificuldades Para Integrao Integrar dados de diferentes SGBDs; Integrar dados que possuem diferentes modelos de banco de dados (relacional, hierrquico, Objeto-Relacional...); Criar algoritmos que sejam compatveis na realizao de consultas, transaes atualizaes e at excluses nos SGBDs; O sistema requer que exista pelo menos um usurio para gerenciar o sistema, pois este no pode ser totalmente automatizado, para corrigir problemas no processo de integrao. 2.1.5. Conflitos para Integrao Quando comparamos esquemas de dados heterogneos ir ocorrer conflito em esquemas locais. Esses conflitos devem ser tratados durante a integrao dos esquemas ou integrao de vises [HEPNER, 1995]. Diferentes nomes podem ser usados para mesma entidade ou entidades diferentes podem possuir o mesmo nome. A mesma entidade pode ser representada atravs de

22
diferentes estruturas de atributos ou alguns atributos podem no 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 so atribudos a atributos semanticamente equivalentes. Conflitos de escalas ocorrem quando unidades mtricas diferentes so utilizadas em cada sistema, ou diferentes nveis de preciso so usados. [JAKOBOVITS, 1997]. Em simples integraes de bancos de dados, os conflitos podem ser resolvidos pelo usurio ou pelo programador envolvido na integrao. Para sistemas fortemente acoplados, os sistemas de integrao 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 Integrao A seguir sero mostrados os trs tipos de esquemas considerados no cenrio de integrao de dados: Esquema global, esquema de exportao e esquema local. No esquema global existe somente um nico esquema que utilizado para manipulao dos dados. Este gerado a partir dos esquemas semnticos de cada sistema participante. Sua principal vantagem o fato do usurio conhecer apenas o esquema global, e no os outros diversos esquemas. A integrao via esquema global baseada na integrao completa dos esquemas de exportao dos vrios bancos de dados com o objetivo de fornecer uma nica viso do banco de dados heterogneo. [SCHNEIDER, 2004]. Um esquema exportao representa o subconjunto do esquema componente que ser compartilhado na federao, que significa servios formados em grupos. Um banco de dados no precisa disponibilizar para a federao e seus usurios a sua coleo completa de dados. Alm disso, este esquema inclui informaes para controle de acesso relativo a sua acessibilidade para usurios especficos da federao. 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, pgina HTML, entre outros. Portanto, os esquemas locais componentes da federao podem ser representados seguindo diferentes modelos de dados. Pode-se disponibilizar um esquema global geral, ou vrios esquemas globais parciais (views) de acordo com as necessidades dos vrios usurios. Integrao de esquemas via bancos de dados federados no precisa ser total, e depende das necessidades dos usurios. Semelhante integrao via esquema

23
global com a utilizao 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 tm por objetivo a leitura e a atualizao dos dados, e o outro adequado para sistemas que tm por objetivo a leitura dos dados [SCHNEIDER,2004]. 2.1.7. Vantagens e Desvantagens As principais vantagens do uso de integrao de dados so [MOTRO, BUNEMAN, 1981]: Os usurios possuem uma viso exclusiva dos dados integrados; Integram diversas fontes de dados sem que haja a necessidade de modificao das plataformas tecnolgicas existentes; Possibilidade de ampliar a viso da empresa para planejar, analisar e informar, realizando o cruzamento de dados para extrao de informaes relevantes, usando-as para tomar decises; Possibilita acessar a base de dados e gerar relatrios especficos do negcio; e Promove a melhoria da qualidade dos dados com a padronizao, garantindo a qualidade dos produtos e atendendo as expectativas dos consumidores. As principais desvantagens so [MOTRO, BUNEMAN, 1981]: A gerao de um novo esquema global integrado geralmente altera a semntica dos atributos e tabelas, portanto aps a integrao pode ser necessrio alterar os softwares que utilizam o banco de dados, para que estes possam acessar o novo esquema integrado. Uma soluo para este problema pode ser obtida atravs de vises e renomeaes de atributos e tabelas. Diversos mtodos de integrao existem para mais de dois bancos de dados: combinao dois a dois, combinao de todos de uma s vez, entre outros, e cada mtodo pode definir esquemas globais completamente diferentes

24
2.2. Computao Distribuda

2.2.1. Definio Um sistema distribudo uma coleo de computadores independentes que se apresenta ao usurio como um sistema nico e consistente [TANENBAUM]. Assim, a computao distribuda 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 unio desses diversos computadores com o objetivo de compartilhar a execuo de tarefas, conhecida como sistema distribudo. 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. construdo muitas vezes a partir de computadores convencionais, sendo que estes vrios computadores so ligados em rede e comunicam-se atravs do sistema de forma que trabalham como se fosse uma nica mquina de grande porte. H diversos tipos de cluster. Um tipo famoso o cluster da classe Beowulf, constituido por diversos ns 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 organizao. Assim, em um Cluster, os recursos so 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. Viso 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], distribudos por uma rea geogrfica grande, oferecendo ao usurio, de forma confivel e econmica, o acesso transparente a tais recursos

25
independente de sua localizao. Nesse sentido, a tecnologia de Grid visa fornecer o acesso compartilhado a recursos de computao, de uma maneira que quem for utiliz-los no necessite de conhecer os detalhes dos componentes computacionais envolvidos, onde eles esto localizados, como gerenci-los, como corrigir erros ou mesmo como efetuar uma atualizao. Dessa forma, a infra-estrutura Grid conecta diversos recursos de hardware, software e dados atravs de uma rede, fornecendo um acesso flexvel e seguro para aplicaes e dados [MALAIKA; EISENBERG; MELTON, 2003]. A tecnologia de Grid possibilita agregar recursos computacionais variados e dispersos em um nico supercomputador virtual, acelerando a execuo de um variado tipo de aplicaes e diminuindo custos com o uso de recursos compartilhados. Em um Grid, os servios podem ser executados em diferentes ns com o objetivo de balancear a carga de trabalho e aumentar o desempenho. Considerando que cada n de um Grid executa tarefas distintas, as aplicaes mais adequadas ao Grid so as que possuem tarefas independentes, ou seja, tarefas que no dependem da execuo de outras e podem ser executadas em qualquer ordem e, a princpio, em qualquer n do Grid [BIANCARDI, 2005]. De uma forma simples, um ambiente de Grid aquele no qual as aplicaes podem utilizar mltiplos recursos computacionais que podem estar distribudos geograficamente. Mais recentemente, tm-se os recursos de dados, como por exemplo, os bancos de dados. Um ambiente Grid deve conter trs pontos recomendados [CAMPOS JR, ALVES, HIRA, ZUFFO]: Coordenao de Recursos no subordinados a um controle centralizado: Um ambiente de Grid deve coordenar recursos e usurios pertencentes a domnios distintos; Utilizao de interfaces e protocolos com padres e abertos: Devido os propsitos das grades computacionais, a utilizao de padres abertos trivial para permitir a interoperabilidade com outros sistemas j existentes; Distribuio de qualidade de servio no trivial: Um ambiente de grade computacional possibilita o uso coordenado de seus recursos, garantindo a qualidade de acesso ao mesmo. Esses requisitos so suportados pela arquitetura dos Grids, na qual possvel escalonar, de maneira dinmica, os recursos computacionais. Alm disso, um Grid pode englobar mquinas localizadas em lugares diferentes, utilizando seus recursos

26
ociosos. Com isso, possvel utilizar hardware comum, no sendo necessrio fazer a utilizao de mquinas de grande porte como supercomputadores. 2.2.3.2. Caractersticas

Segundo [GOLDCHLEGER, 2004], podemos citar os seguintes aspectos relacionados ao Grid: No substituem sistemas operacionais - Os sistemas de computao em Grid podem utilizar servios do sistema operacional, porm so estruturados como um middleware que prov servios para os usurios e aplicaes do Grid; Podem integrar recursos distribudos e descentralizados - a maioria dos sistemas de computao em Grid capaz de integrar recursos dispersos por mltiplos domnios administrativos e conectados por redes de grande rea. Essa caracterstica separa os sistemas em Grid dos sistemas em Cluster, uma vez que estes ltimos normalmente so capazes de integrar recursos em apenas um domnio administrativo; Podem ser utilizados por diversas aplicaes - a maioria dos sistemas de computao em Grid prov servios que podem ser utilizados por diversas aplicaes, caracterizando uma arquitetura reutilizvel; Podem incluir vrias plataformas de hardware e software - a maioria dos sistemas de Computao em Grid pode integrar recursos heterogneos, compostos por diversas plataformas de hardware e software. Para tal, entretanto, o sistema de Computao em Grid deve incluir mecanismos que lidem com a diversidade de tais plataformas; Adaptabilidade s polticas locais - apesar de integrarem recursos dispersos por vrios domnios administrativos, os sistemas de computao em Grid devem se adaptar s polticas e restries de uso de cada um destes domnios. Por exemplo, comum o cenrio onde o administrador do domnio, apesar de compartilhar os recursos com outros domnios, deseja priorizar os usurios locais. Proprietrios de estaes de trabalho, por exemplo, no aceitam que o desempenho de suas aplicaes sofra devido s aplicaes em Grid que executam em seus recursos. 2.2.3.3. Benefcios

Segundo [BERSTIS, 2003], os benefcios que o Grid possui so os seguintes:

27
Explorar recursos subutilizados e recursos adicionais - A princpio, uma aplicao pode ser executada em qualquer mquina que faa parte de um Grid, desde que esta possua acesso a determinados recursos solicitados pela aplicao. Pode-se escolher esta mquina utilizando-se diversos parmetros, como por exemplo: a que estiver com menor carga de processamento, a que possuir disponvel certo tipo de dispositivo ou determinados dados. Existem alguns tipos de aplicao que podem melhor utilizar as caractersticas dos Grids. Um exemplo seria o de aplicaes que exigem grande processamento de dados e pouca interao com o usurio, podendo ser melhor escalonadas atravs do Grid. Alm dos recursos de processamento, muitas mquinas tambm possuem seus discos rgidos subutilizados. Assim, o Grid pode ser utilizado como um Data Grid, alocando o espao disponvel como se fosse um disco apenas. Outra forma de alocar o espao seria dividir os dados de forma que as aplicaes possam ser executadas em uma mquina mais prxima de onde se encontram os dados que processa, ou para garantir uma maior disponibilidade caso alguma mquina falhe. Diversos outros recursos podem ser compartilhados em um Grid. Para uma aplicao que demande um maior acesso Internet, por exemplo, pode-se dividir o trabalho entre outras mquinas que tambm possuam acesso rede, acelerando os resultados. Outros exemplos podem abranger uma impressora remota com maior qualidade, um gravador de DVD ou equipamentos mdicos e cientficos avanados como um microscpio eletrnico ou um rob. Com isso, os recursos de uma instituio ou empresa podem ser melhor utilizado, diminuindo despesas e aumentando a eficincia e a competitividade. Capacidade de processamento paralelo - Outra caracterstica interessante a possibilidade de melhor utilizar o processamento paralelo atravs de Grids. Em alguns tipos de aplicaes tais como cientficas, financeiras, processamento de imagens e simulaes, a utilizao de processamento paralelo pode trazer bastante ganhos com relao ao desempenho. Uma aplicao que faa uso de algoritmos e tcnicas de programao paralela pode ser dividida em partes menores e estas podem ser separadas e processadas independentemente. Cada uma destas partes de cdigo pode ser executada em uma mquina distinta no Grid, melhorando o desempenho. Existem algumas barreiras que podem impedir que uma aplicao utilize todo este potencial. Por exemplo, se a aplicao deve ser dividida em um nmero fixo de partes independentes, isso torna-se uma barreira que impede sua escalabilidade. Outra forma de problema encontrado quando as partes no

28
podem ser completamente independentes e precisam comunicar-se entre si, causando uma possvel espera para que as comunicaes sejam sincronizadas ou o tempo necessrio para as mensagens serem transmitidas. Essas caractersticas devem ser levadas em conta no momento de se utilizar a funcionalidade de processamento paralelo, mas isso no impede a grande utilizao dos Grids como uma excelente arquitetura para o processamento paralelo. Dispositivos e Organizaes Virtuais - A colaborao entre os mais diversos tipos de usurios e aplicaes outra capacidade que pode ser desenvolvida com o advento dos Grids. Recursos e mquinas podem ser agrupados e trabalharem juntos formando o que pode ser chamado de uma Organizao Virtual (OV). Uma OV [FOSTER, KESSELMAN, TUECKE; 2001] uma entidade que compartilha recursos atravs do Grid, utilizando uma determinada poltica de compartilhamento. Uma OV varia tremendamente em seus propsitos, escopo, tamanho, durao, estrutura, comunidade e sociologia. Pode ser definida de acordo com sua rea de pesquisa ou de negcio, juntando usurios e aplicaes com propsitos semelhantes, colaborando em prol de uma razo comum como, por exemplo, empresas, centros de pesquisa e universidades. Esses recursos podem abranger processamento, dados, licenas, 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 cientficos altamente especializados e caros. Por exemplo, um cientista no laboratrio A poder manipular remotamente um telescpio presente no laboratrio B, e receber as imagens captadas atravs da rede. Opcionalmente, ele poder, de maneira transparente, armazenar as imagens nos equipamentos de grande capacidade do instituto C e, caso necessrio, processar as imagens nos computadores disponveis nas trs instituies. Tambm possvel vislumbrar experimentos colaborativos, onde diversos cientistas espalhados por vrias instituies colaboram para realizar experimentos e simulaes. Na indstria, alm da possibilidade de se utilizar a capacidade ociosa de centenas de estaes de trabalho j existentes, os Grids podero permitir novas formas de colaborao entre os funcionrios espalhados por diversas filiais, por exemplo. Confiabilidade - Existem diversas maneiras de aumentar a confiabilidade em um sistema computacional. Processadores e discos so duplicados, de modo

29
que caso um falhe o outro assuma seu lugar, fontes de energia e circuitos redundantes, geradores eltricos, entre outros. Todas estas formas comprovadamente aumentam a disponibilidade e a confiana em um sistema, mas seus altos custos podem torn-las impraticveis. Utilizando-se uma abordagem baseada em Grids, com mquinas espalhadas em diversos lugares diferentes, quando uma falha atinge uma parte do Grid, as demais podem continuar sua operao normalmente. Sistemas de gerenciamento podem executar novamente processos importantes caso seja detectada alguma falha ou estes podem ser executados redundantemente para garantir sua consistncia. Dados podem ser duplicados ou separados em diversas partes atravs do Grid, aumentando sua disponibilidade. Um grande avano nessa rea sero sistemas que podem automaticamente detectar uma falha e tomar as medidas necessrias para contornar o problema. 2.2.3.4. GRID VS Computao Distribuda

Computao em grade um caso em particular da computao distribuda, j que so orientadas para grandes aplicaes, seja com enorme quantidade de dados transmitidos ou com uma grande capacidade de clculos, ou ambas. Com a evoluo da tecnologia de Grid, criava a oportunidade de se oferecer servios sob demanda, surgindo a idia de um Grid onde seria possvel dispor qualquer servio computacional sob demanda. O Grid, portanto, seria uma rede na qual o individuo se conecta para obter servios computacionais que agregam recursos sob demanda (ex.: ciclos, armazenamento, software, perifricos, etc) [CIRNE; NETO, 2005]. A computao distribuda passa a ser uma computao em Grid no momento em que existe uma infra-estrutura de hardware e software que permita criar a iluso de um supercomputador virtual, em grande escala, facilmente gerencivel e com uma grande quantidade de recursos (ciclos de CPU, dados, dispositivos de armazenamento etc.) sendo compartilhado de forma confivel, consistente, econmica e persistente, possibilitando, com isso, coordenar os trabalhos a serem processados e garantir a qualidade de servio [BERSTIS, 2003]. Algumas tecnologias de computao distribudas, tais como CORBA e EJB, so voltadas para sistemas distribudos altamente acoplados, nos quais cliente e servidor so muito dependentes um do outro. Tecnologias de Grid se distinguem destas pelo fato de serem baseados no conceito de Grid Services, uma evoluo de Web Services, o que implica em sistemas fracamente acoplados, nos quais um cliente pode no ter conhecimento do servio at que ele o invoque. Nesse sentido, sistemas

30
distribudos altamente acoplados so ideais para aplicaes intranet, enquanto que Grid so mais adequados para alcanar as demandas de uma aplicao Internet [SOTOMAYOR, 2003]. 2.2.3.5. GRID VS Cluster

A diferena 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, ento um Cluster. Em um Cluster, todos os ns trabalham cooperativamente em um objetivo comum, e a alocao de recursos executada por um gerente centralizado e global. Em um Grid, os recursos esto distribudos geograficamente, sendo que os donos desses recursos possuem autonomia para fazer o gerenciamento local. A alocao dos recursos feita pelos usurios do Grid, e os ns executam diferentes tarefas relacionadas a objetivos distintos. Um Grid pode ser encarado como sendo uma evoluo do Cluster, dado que os recursos deste podem ser compartilhados pelo Grid. Assim, um Grid mais heterogneo, complexo e distribudo. Com o objetivo de esclarecer a definio de Grid, j que se confunde com o significado real de Grid, foi elaborado um Grid CheckList por Foster [FOSTER, 2002] , onde so definidas trs caractersticas bsicas, onde pode ser definido se um sistema computacional pode ser chamado de Grid: Recursos coordenados que no se sujeitam a um controle centralizado: Sistemas em Grid podem englobar recursos entre os mais variados tipos, desde o desktop de um usurio at um supercomputador. Pode haver um controle local em uma empresa, mas no existe um controle central para todo o Grid; Utilizar padres abertos, interfaces e protocolos de propsito geral: A utilizao de protocolos e padres abertos essencial para que os sistemas em Grid possam realizar funes fundamentais como autenticao, autorizao, descoberta de recursos e acesso a eles, sem perder a capacidade de escalar e interagir com diferentes plataformas de hardware e software; Prover o mnimo em qualidade de servios: Sistemas em Grid permitem que os recursos sejam utilizados de forma coordenada com o objetivo de alcanar qualidades de servio como, por exemplo, tempo de resposta, throughput (vazo), disponibilidade, segurana e/ou a co-alocao de recursos para se adequar s exigncias do usurio. Assim, a utilidade de um sistema combinado significativamente maior que a soma das partes.

31

3. TRABALHOS RELACIONADOS
3.1. Introduo

Na literatura da rea, so encontrados vrios sistemas tentando resolver o problema de integrao 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 sero descritos. 3.2. CoDIMS (ConFigurable Data integration Middleware Systen)

Com o grande aumento de sistemas informatizados espalhados pelo mundo, a integrao de dados tem ficado cada fez mais difcil de ser realizada, sendo cada vez mais necessria a implementao de sistemas capazes de integrar dados heterogneos. O Sistema CoDIMS, tem por objetivo, resolver tal problema de integrao de dados em um ambiente flexvel e configurvel, permitindo a gerao de sistemas lightweight, onde cada aplicao possui o seu sistema especifico de integrao de dados distribudos. Sua principal caracterstica o fato de ser baseado na tcnica de composio de frameworks, possibilitando, com isso, flexibilidade e configurao, podendo ser adaptado para ser utilizado em diversos domnios de aplicao que exigem diferentes tipos de servios [Barbosa, 2001]. Flexvel, no sentido de que permite: integrar diferentes fontes de dados; utilizar diferentes tcnicas de comunicao, tanto entre os componentes internos quanto com as fontes de dados; possibilitar a utilizao de diferentes modelos de dados internamente. Configurvel, de forma que o middleware pode ser configurado apenas com os componentes necessrios para uma aplicao especfica e que seja instanciado de acordo com os requisitos da aplicao e das caractersticas das fontes de dados que se deseja integrar [BIANCARDI, SILVESTRE, BARBOSA, 2005a]. Os frameworks so componentes que fazem parte da arquitetura de CoDIMS, e possuem o DIMS (Data Integration Middleware Services). instanciado para implementar servios de integrao de dados, como por exemplo o gerenciamento de dados. Os componentes do CoDIMS so implementados como webservices, possibilitando distribuio do ambiente, execuo remota de tarefas e reuso de tais componentes (TREVISOL 2004).

32
Um modelo global implementado para que CoDIMS possa realizar a integrao de dados, onde os modelos locais so integrados e mapeados dentro do modelo global.

Figura 3 Configurao Bsica do CoDINS

A Figura 3 mostra os componentes bsicos da configurao do CoDIMS. Os Componentes de Controle, Gerncia de Metadados, Processamento de Consultas e Acesso de Dados so os componentes que devem existir em todas as configuraes. Dependendo do domnio da aplicao para qual est sendo desenvolvida a aplicao, poderiam estar presentes outros componentes da configurao. Na Figura 4 mostrada a configurao bsica do CoDIMS assim como uma possvel interao entre os mesmos. O componente Controle a essncia do ambiente CoDIMS, pelo fato de disponibilizar os mecanismos que implementam as configuraes fsica e lgica. A configurao fsica diz respeito seleo e ao registro dos componentes que faro parte do sistema a ser configurado, incluindo os servios oferecidos e requisitados por cada um destes componentes. A configurao lgica modelada atravs de um mecanismo baseado no conceito de workflow, sendo responsvel por efetuar um escalonamento dos servios, ou seja, determinar a seqncia de execuo dos servios oferecidos pelos componentes necessrios para o processamento de um comando submetido ao sistema configurado. O componente Gerncia de Metadados responsvel por gerenciar os esquemas envolvidos no processo de integrao de dados. O componente Processamento de Consulta analisa, re-escreve, otimiza e executa as consultas de usurio submetidas ao sistema. Por fim o componente Acesso aos Dados responsvel por, atravs 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 verso atual do CoDIMS, seus componentes so implementados como Web Services [TREVISOL, 2004].

33

Figura 4 - O CoDIMS e seus Componentes Bsicos [BIANCARDI, 2005]

Para o processo de configurao, customizao e modelagem de uma instncia do CoDIMS, so necessrias as etapas de configurao fsica, configurao lgica e carga dos metadados1 de acordo com os requisitos de uma aplicao especfica. Um exemplo de instncia do framework CoDIMS o CoDIMS-G (FONTES et al., 2004), que vem sendo desenvolvida no LNCC2 com o objetivo de suportar aplicaes de visualizao cientficas executando em um ambiente de Grid. 3.2.1. CoDIMS-G CoDIMS-G um sistema de integrao de dados e programas gerados a partir da configurao do CoDIMS [BARBOSA; PORTO; MELO, 2002; BARBOSA, 2001]. Esse sistema pode ser visto como um servio de integrao de dados e programas para Grid, o qual fornece para os usurios um acesso transparente para dados e programas distribudos no Grid, assim como gerenciamento e alocao de recursos dinmicos. Nele tambm proposto um novo algoritmo de escalonamento de ns e projetada uma mquina de consulta distribuda adaptativa para o ambiente de Grid. Assim, no CoDIMS-G, os usurios podem expressar consultas que combinam processamento distribudo de dados com a invocao de programas sobre os mesmos [BIANCARDI, 2005]. A arquitetura do CoDIMS-G, mostrada na Figura 5, subdividida em vrios componentes. O componente Control administra a comunicao entre os vrios componentes, armazenando, gerenciando, validando e verificando as instncias de configurao.
1 2

Para uma descrio mais detalhada do processo de configurao consulte [BARBOSA, 2001]. Laboratrio Nacional de Computao Cientfica - http://www.lncc.br/frame.html

34

Figura 5 Arquitetura do CoDINS-G [FONTES et al., 2004]

A requisio de um usurio encaminhada para o componente Controle, que enviada para o componente Analisador (Parser). Este transforma a requisio do usurio em uma representao de grafo de consulta. O Otimizador de Consulta (Query Optimizer - QO) recebe o grafo e gera um plano de execuo de consulta distribudo (DQEP), usando um modelo de custo baseado em estatsticas de dados e programas armazenadas no Gerenciador de Metadados (Metadata Manager - MM). Para DQEPs que incluem operaes para a avaliao de programas de uso paralelo, o otimizador chama o componente Escalonador (Scheduler - SC). Este ltimo acessa o MM para capturar o histrico de desempenho de execuo de ns do Grid e custos de avaliao de programas de usurio, alm de estatsticas dos resultados intermedirios. Baseado nas estatsticas coletadas, o SC aplica um algoritmo de escalonamento de ns do Grid para encontrar um sub-conjunto de ns a serem alocados pelo gerenciador da mquina de execuo (Query Engine Manager - QEM), onde sero executados os programas do usurio. O QEM responsvel por implantar os servios da mquina de execuo de consulta (QE) nos ns especificados no DQEP, e gerenciar os seus ciclos de vida durante a execuo da consulta. O QEM gerencia o desempenho, em tempo real, dos QEs por consultar as estatsticas de vazo de dados e decidir por realocao, em tempo de execuo, das QEs com um plano re-otimizado. Os QEs so implementados como instncias do framework de execuo de consulta [AYRES; PORTO; MELO].

35
3.3. MOCHA

um middleware proposto pela universidade de Maryland, projetado para interconectar fontes de dados distribudos sobre uma grande rea de rede [RODRIGUES-MARTINEZ; ROSSOUPOULOS, 2000]. Foi projetado para integrar centenas de fontes de dados distribudas sobre a Web, tendo sido construdo com a idia de que um middleware para um ambiente distribudo de larga escala deve ser auto-extensvel. Esta extensibilidade permite o envio de classes Java para os sites remotos de um modo automtico, de acordo com as caractersticas das fontes de dados. As classes Java so necessrias para executar uma sub-consulta no prprio site, diminuindo o trfego de dados entre o site e o sistema [PEREIRA BARBOSA, 2001]. A motivao do MOCHA que os dados armazenados em diversos sites so baseados em tipos de dados complexos, e que a Web tem se tornado, de fato, uma interface de usurio para aplicaes em rede. Assim, os usurios necessitam de uma soluo 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, so: Processador de consulta (QPC); Wrappers (DAP); Repositrio de cdigo JAVA (Code Repository); Catlogo de armazenamento de metadados (Catalog).

Figura 6 Arquitetura do Mocha [BIANCARDI, 2005]

A Aplicao Cliente - um applet, um servlet, ou uma Aplicao Java, usada para submeter consultas ao sistema; o Coordenador de Processamento de Consultas (QPC) - fornece servios tais como anlise de consulta, otimizao de consulta,

36
escalonamento de operador de consulta, gerenciamento de catlogo e execuo de consulta, alm de ser o responsvel por implantar todas as funcionalidades necessrias para o cliente e para os sites remotos, a partir dos quais os dados sero extrados; 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 integrao de dados e orquestrao de servios no qual possvel fazer a coordenao e a incorporao de servios Web para efetuar anlise e recuperao 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 servios oferecidos pelo framework OGSA-DAI para acessar, de forma homognea, as fontes de dados, potencialmente heterogneas. Em um nvel menor, temos a camada GT3 (Globus Tookit), que usada tanto pelo OGSA-DAI quanto pelo OGSA-DQP para criao de instncias, acesso do estado e gerenciamento do tempo de vida das instncias de servios. A Figura 8 mostra a interao entre os frameworks OGSA-DQP e OGSA-DAI [BIANCARDI, 2005]. No OGSA-DPQ, instncias de servio de execuo de consulta so implantadas em nodos de GRID para implementar paralelismo de programas de usurio. Operadores algbricos, tal como, exchange e operation-call, implementam comunicao entre nodos e invocao de programas de usurio, respectivamente [FONTES et al., 2004].

37

Figura 8 - Interao entre os frameworks OGSA-DPQ e OGSA-DAI.

Assim como o OGSA-DAI, o OGSA-DPQ possui algumas restries que devem ser explicadas. Dentre elas esto as que foram herdadas do prprio OGSA-DAI, j que o mesmo utilizado pelo OGSA-DPQ, e outras pertencentes somente ao OGSA-DPQ. Uma delas est relacionada com a obteno dos esquemas das fontes de dados, pois nenhuma integrao de esquema e resoluo de conflitos suportada durante a importao dos esquemas. Os esquemas importados so simplesmente acumulados e mantidos localmente. Isso dificulta a vida do usurio final, dado que ele ter grandes dificuldades para integrar "visualmente" os esquemas e resolver conflitos semnticos e/ou estruturais entre os mesmos. Uma outra restrio que o plano de execuo de consulta gerado pelo OGSA-DPQ esttico [FONTES et al., 2004]. Alm disso, existe a possibilidade de um ou mais nodos alocados para este plano esttico ficarem sobrecarregados, ou a fonte com a qual eles se comunicam no est mais respondendo. Neste sentido, no OGSA-DPQ, no possvel fazer uma anlise, em tempo de execuo, dos nodos alocados no GRID para que, se necessrio, seja feita uma realocao dos mesmos e a gerao de um novo plano.

38
[OGSA-DAI]

4. OPEN GRID SERVICE ARCHITECTURE DATA AND INTEGRATION (OGSA-DAI)

4.1. Introduo

A maior parte das empresas utiliza servios 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 impossvel a juno dos mesmos. O OGSA-DAI inclui uma coleo de componentes para a manipulao de dados de diversas maneiras e tambm um uma outra coleo de ferramentas para desenvolver aplicaes de clientes. Alm disso, umas de suas diversas utilidades seria o fato de este software ser facilmente modificado, fornecendo ao usurio a opo de adicionar novas funcionalidades criadas pelo prprio usurio.

Figura 9 Funcionamento do OGSA-DAI

Este captulo est baseado no material contido em [OGSA-DAI]

39
Pode-se dizer que o principal foco deste software na contribuio de um futuro onde os cientistas da computao possam focar o seu conhecimento na anlise e processamento de dados ao invs de se preocupar na localizao fsica dos dados, na sua transferncia, estrutura e manipulao. O OGSA-DAI um middleware, ou seja, um programa que faz a ligao entre outros softwares (Figura 9). Este software tem como principal caracterstica o fato de podermos manipular vrios 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 nmero limitado de tecnologias exemplificadas na Tabela 1.
SGBD MySQL IBM DB2 Microsoft SQL Server Oracle PostgreSQL EXist Verso Suportada Relacional 3.2.3 em diante ----10g Enterprise Edition 10.2.0.1.0 --XML Feito desde 03/12/2005 Observaes Detalhes em www.mysql.com OGSA-DAI no suporta a criao ou deleo de bancos de dados usando BD2 . No Suporta a coluna IMAGE no OGSA-DAI. OGSA-DAI no suporta a criao ou deleo de base de dados usando Oracle. Detalhes em www.postgresql.org recomendvel que a instalao do eXist ocorra dentro de um continer com seus prprios servios Web. Ex: OMIM, SWISSPROT e EMBL.

Sistema de arquivos

Arquivos ---

Tabela 1 Tecnologias Suportadas pelo OGSA-DAI

4.2.

Arquitetura do OGSA-DAI

A arquitetura OGSA-DA, representada na Figura 10, composta de vrias camadas com suas respectivas funes e finalidades. Dentro destas camadas existem componentes e entre as camadas existem um tipo de interface.

40

Figura 10 - Arquitetura do OGSA-DAI

4.2.1. Camada de dados (data layer) De baixo para cima est a camada de dados que consiste dos recursos de dados que so suportados pelo OGSA-DAI, sendo esses recursos: relacionais, bancos XML, arquivos e diretrios em formatos conhecidos pelo software. 4.2.2. Interface entre camada de dados e camada lgica de negcio Entre a camada de dados e a camada de negcio existe uma interface que permite uma comunicao em ambas as direes de informaes. Para que ocorra tal comunicao preciso que cada recurso de servio 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 usurio construir o seu prprio assessor de recurso de dados para expor novos tipos de recursos de dados (Figura 11).

41

Figura 11 Data Service Resource

4.2.3. Camada Lgica de Negcios (Business Logic Layer) Esta camada do OGSA-DAI contm a funcionalidade do seu ncleo. Esta consiste de componentes conhecidos como recursos de servio de dados. Como mostrado na Figura 10, vrios recursos de servios de dados podem ser instalados para expor vrias fontes de dados. Existe uma relao de 1-1(um para um) entre recursos de servios de dados e recursos de dados. Algumas das funcionalidades ou at responsabilidades de um recurso de servio de dados so listadas abaixo. Execuo de documentos de desempenho este documento descreve as aes que um recurso de servio de dados deve tomar no interesse do cliente. Cada ao conhecida como uma atividade. O OGSA-DAI j inclui um nmero alto de atividades para que sejam realizadas as operaes mais comuns como queries de base de dados, transformao de dados e entrega de dados. Gerao de documentos de resposta este documento descreve o status da execuo 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 interaes com os recursos de dados acontecem graas ao componente de recursos de dados. Funcionalidade de transporte de dados dados podem ser transportados de um recurso de servio de dados para um cliente ou outro recurso de servio de dados qualquer e vice-versa. Gerncia de Sesso seria a criao, acesso e terminao de objetos de sesso permitindo que estados possam ser guardados atravs de mltipos pedidos para o recurso de servio de dados. Todos os pedidos de documentos de desempenho so processados dentro de uma sesso. Sesses tambm servem para guardar streams que foram usadas pela funcionalidade de transporte de dados sendo assim conhecidas por sesses stream. Gerncia de propriedade seria a criao, acesso e remoo de propriedades associadas com os recursos de servios de dados sendo conhecidos como propriedades de recursos de servios de dados. Estes geralmente so usados

42
para expor os datos, por exemplo, o status de um pedido ou um esquema de recurso de dados adjacente. 4.2.4. Interface entre a camada lgica de negcios e a camada de apresentao Esta interface faz a comunicao com as duas camadas adjacentes, lgica de negcios e de apresentao, em ambas as direes. Ela suporta a chamada de funcionalidades do OGSA-DAI dentro da camada lgica de negcio de um jeito que independente de um ambiente web particular. Quando pedidos de SOAP (Service Oriented Architecture Protocol) chegam aos servios de dados do OGSA-DAI, esta interface usada para passar informaes e instrues para a camada lgica de negcio e vice-versa. A seguir mostrado quais os tipos de informaes que so passadas entre estas duas camadas. Camada de apresentao Camada lgica de negcio

So enviadas informaes sobre os nomes dos data service resourses e suas propriedades, vomo tambm identificaes de session streams Certificado de Proxy do cliente e credenciais em um formato que no depende da web. Documentos de desempenho e dados de clientes. Informao de configurao de recursos de servios de dados incluindo drivers para os bancos de dados, URIs dos mesmos, nome e senha de usurios de base de dados, informao sobre atividades suportadas, informao sobre sesso de data service resourse recursos de servios de dados e simultaneidade suportada.

Camada lgica de negcios

Camada de apresentao

passado pela camada de apresentao os documentos de resposta e resultados em forma de dados. O status do processamento de um pedido dentro de uma sesso em particular. Isto conhecido como status de pedido de sesso. Valores para as propriedades de recursos de servios de dados como esquemas de um recurso de dados adjacente.

43
Informao sobre as atividades que so suportadas pelos recursos de servios de dados. Estas atividades so aquelas que podem ser pedidas pelo usurio usando documentos de desempenho. 4.2.5. Camada de Apresentao (Presentation layer) Esta camada encapsula a funcionalidade requerida para expor recursos de servios de dados usando interfaces que utilizam servios web. O OGSA-DAI contm dois conjuntos destas funcionalidades encapsuladas, uma compatvel 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 atravs de um data service correspondente. O OGSA-DAI tambm inclui um client toolkit Java que proporciona uma API de alto nvel para interao de servios de dados. Este kit de ferramentas simplifica o desenvolvimento de aplicaes fornecendo meios convenientes de construir e enviar pedidos e interpretar as respostas subseqentes. Quando uma aplicao escrita usando este kit de ferramentas de ciente, esta poder interagir e acessar recursos de dados WSRF e WSI transparentemente. 4.3. Servios de Dados

Servio de dados um ponto de contato para clientes que queiram acessar, pesquisar ou atualizar um recurso de dados especfico, ou at desempenhar outras aes relacionadas a dados usando o OGSA-DAI. Um servio 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 servio de dados oferece um grande nmero de operaes que permitem que informaes sobre o servio possam ser recuperadas, e tambm fornece acesso aos recursos do servio de dados sendo que estes so expostos pelo prprio servio de dados.

44
4.3.1. Operaes Usando Dados -Documento de Desempenho Documentos de desempenho so usados pelos clientes para instruir recursos de servios de dados a desempenhar atividades. Estas atividades incluem consultas e atualizaes, transformao de dados e operaes 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 requisies de atividades que podem conter consultas, atualizaes, entrega de dados, entre outros. O fato de podermos juntar vrias atividades em apenas um documento uma grande vantagem, pois assim no ocorre o imenso fluxo de dados que teramos caso tivssemos que transportar cada atividade usando um pedido ou servio diferente. As APIs que so concedidas junto com o OGSA-DAI permitem desenvolvedores Java construrem aplicaes que geram documentos de desempenho e interpretam documentos de resposta automaticamente. A seguir ser descrito a estrutura subjacente e o contedo 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 aps vem o elemento <session>, que opcional, pois ele pode conter nenhuma ou vrias atividades. O elemento de atividade aquele que contm tudo que o recurso de dados dever realizar. Este deve conter um nico valor para o atributo name. Para que vrias atividades possam ser enviadas juntas preciso que o stream de sada (output stream) de uma atividade seja referenciado pelo stream de entrada (input stream) da prxima atividade. Na Figura 13 exibida um exemplo de documento de desempenho.

Figura 12 - Documento de desempenho contendo elemento de sesso (session element), elemento de atividade (activity element) e um ponto final (end-point)

45

Figura 13 Exemplo de documento de desempenho

Sendo assim todos os dados que estiverem entre estas atividades sero entregues de volta ao cliente atravs de um documento de resposta. -Documento de Resposta Um documento de resposta usado para responder ao usurio quando este envia um documento de desempenho para um servio de dados. O contedo 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 usurio poder analis-lo para saber se ocorreu algum erro ou ento 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 sncrono 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 identificao da sesso 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 tambm

46
uma seo 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 no contenha nenhum ponto de sada ento o processamento ir ocorrer de forma assncrona, ou seja, nenhum dado ser retornado no documento de resposta para o usurio e por isso no ser mais preciso esperar que todas as atividades sejam concludas. 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 Sncrona

Figura 16 - Documento de resposta contendo os dados resultantes

4.4.

Recursos de Servios de Dados

Os recursos de servios de dados que servem para receber os documentos enviados pelos servios de dados e ento analis-los e valid-los. Aps isso as atividades so executadas e ento criado o documento de resposta para que possa ser enviado de volta para o servio de dados.

47

Figura 17 - Interao usando uma interface orientada a documentos

Na Figura 17 podemos observar com mais preciso a interao destas camadas usando documentos para fazer a comunicao entre elas. 4.5. Assessor de Recursos de Dados

Estes assessores servem para fazer a comunicao entre os recursos de servios de dados e os bancos de dados sendo utilizados. Com o assessor de recursos de dados do OGSA-DAI o usurio pode criar o seu prprio assessor de recurso de dados para que este possa fazer a comunicao a um banco de dados que ainda no so suportados pelos assessores listados na Tabela 2.
Assessor de Recurso de Dados Descrio Assessores de dados padres 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 integrao de dados SQL Multiple Data Resource Accessor Agrega um ou mais recurso de servio de dados Assessores de demonstrao Demo Factory Data Resource Accessor Exemplo de um assessor que pode criar dinamicamente recursos de servios de dados. Demo Instance Data Resource Accessor Exemplo de assessor utilizado pelo resurso de servio de dados. Demo Transient Factory Data Resource Accessor Exemplo que pode criar recursos de servios de dados transientes. Demo Transient Instance Data Resource Accessor Exemplo de assessor utilizado pelorecurso de servio de dados.
Tabela 2 - Assessores de dados fornecidos pelo OGSA-DAI

4.6.

Relacionamento

A seguir ser descrito como o relacionamento entre os servios de dados (data service), fontes de servios de dados (data service resource), assessores de fontes de

48
servios de dados (data service resource accessors) e as fontes de dados (data resources), ou seja, ser descrita e ilustrada a interao entre eles. Na Figura 18 podemos identificar vrios componentes. A seguir estaro algumas de suas caractersticas. Primeiramente um servio de dados (data service) pode expor nenhuma ou vrias fontes de servio de dados (data service resource). O servio de dados e a fonte de servio de dados (data service resource) precisam estar em um mesmo servidor. Uma fonte de servio de dados expe uma fonte de dados (data resource). A fonte de dados (data resource) no precisa estar no mesmo servidor que a fonte de servio de dados (data service resource). O assessor de fonte de dados (data resource accessor) gerencia as interaes com as fontes de dados em nome da fonte de servio de dados. Uma fonte de servio de dados possui um conjunto de arquivos de configurao que especificam as atividades suportadas, informao sobre a sesso e o nome da classe do assessor de fonte de dados. Um assessor de fontes de dados tambm possui um conjunto de arquivos de configurao que fala sobre a fonte de dados relacionada.

Figura 18 Exemplo de Entrega de dados

4.7.

Especificao Funcional

O objetivo desse captulo explicar como o OGSA-DAI se comunica com as fontes de dados e como ambas se comunicam com o middleware. 4.7.1. Representando uma Fonte de Dados no OGSA-DA Primeiramente, preciso obter as informaes 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 verso dessa fonte (Tabela 1 Cap 4). Com isso em mos

49
preciso criar um resourse file contendo os argumentos necessrios. O passo seguinte seria realizar o transporte desse arquivo para o servidor Tomcat de sua mquina (Vide Anexo A). Uma declarao resourse file (Figura 19) contm as seguintes informaes 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. Tambm pode ser nulo; Termination Time valor em milissegundos a partir do inicio do evento. Tambm pode ser nulo; Nenhuma ou vrias propriedades da persistncia do recurso; o Delimitado por Properties e End; o Os valores so strings; Nenhuma ou vrias propriedades de configurao; o Delimitado pelo Config e End; o Os valores so strings; Nenhuma ou vrias propriedades de apoio; o Delimitado por Activities e End;
id=RESOURCE-ID type=RESOURCE-TYPE creationTime=CREATION-TIME terminationTime=TERMINATION-TIME PROPERTIES [NAME=VALUE]* END CONFIG [KEY=VALUE]* END ACTIVITIES [ACTIVITY-NAME=ACTIVITY-ID]* END
Figura 19 Resourse File

50
4.7.2. Fluxograma de Execuo O OGSA-DAI possui vrias classes que fazem consultas em bancos de dados. Um URI, um resource file e um comando SQL so os parmetros necessrios para fazer uma consulta em uma fonte de dados integrada ao OGSA-DAI Client. Todos estes parmetros devem estar includos numa classe especfica do middleware que utilizada para fazer acesso ao banco. O conceito bsico que o cliente ir construir um fluxo de trabalho das atividades que sero executadas sobre o OGSA-DAI Server. Os dois elementos chaves so as atividades e o fluxo de trabalho. As atividades so os mdulos bsicos do OGSA-DAI. Eles so discretos pacotes que fazem um passo lgico em um processo. As atividades so divididas em vrias categorias, algumas especficas, outras no. As categorias so 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 contm atividades que se focam em torno de uma tarefa especfica e s esto interessadas em realizar essa tarefa, por exemplo, a atividade SQLQuery lida com a misso de resgatar um banco de dados SQL e obter um conjunto de resultados. As principais etapas que tero de ser abordadas atravs de atividades so os seguintes: Examina o banco de dados Transforma os resultados para um formato mais utilizvel Transforma os resultados para um formato mais eficiente. Mostra os resultados de volta para o cliente.

Para explicar melhor o funcionamento, utilize como base a seguinte consulta mostrada na Figura 20 realizada pelo cliente.
SELECT * FROM littleblackbook WHERE id <10;
Figura 20 Consulta realizada pelo cliente

51

Para facilitar a conexo com o servidor, fornecido um Serverproxy que implementa um servidor de interface. necessrio saber as URL dos bancos de dados para serem fornecidos ao servidor. A Figura 21 um Proxy da representao de um servidor OGSA-DAI da parte do cliente. Ele pode ser obtido atravs de proxies para cada servio web e, por isso, cada recurso, implantado sobre o servidor OGSA-DAI.
Server mServer; public { mServer = new ServerProxy(); mServer.setDefaultBaseServicesURL(new URL(serverURLStr)); }
Figura 21 - Servidor Proxy do OGSA-DAI

void

setupServer(String

serverURLStr)

throws

ClientToolkitException,

MalformedURLException

A classe Server fornece um exemplo de mtodos de acesso aos proxies que representam os diferentes recursos disponveis no servidor do OGSA-DAI. As proxies, que correspondem aos seis tipos de recursos do OGSA-DAI, so: DataRequestExecutionResource DataSinkResource DataSourceResource DataResource RequestResource SessionResource

A Figura 22 mostra um exemplo de utilizao de alguns desses recursos. O primeiro deles o DataRequestExecutionResource para um DRER. Seria um pedido de execuo 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 gesto e execuo dos recursos.

52
DataRequestExecutionResource mDRER; public void setupDRER(ResourceID drerID) throws ServerException, ClientToolkitException { mDRER = mServer.getDataRequestExecutionResource(drerID); }
Figura 22 DataRequestExecutionResource

Como a ligao bsica foi efetuada, as atividades podem ser desenvolvidas para a utilizao. So necessrias quatro atividades: SQLQuery TupleToWebRowSetCharArrays CharArraysResize DeliverToRequestStatus

Ao criar um fluxo de trabalho, todas as entradas e sadas das atividades devero ser devidamente conectadas. Caso contrrio, ocorrer um erro no decorrer da execuo. O primeiro passo criar a atividade SQLQuery. A Figura 23 mostra o cdigo para a criao 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 parmetros do mtodo so 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 no verifica o comando SQL antes da execuo para que esse comando seja validado. Esta atividade exige que o mtodo setResourceID seja utilizado para segmentar um DataResource. O prximo passo a criao da atividade TupleToWebRowSetCharArrays. Esta atividade converte tuples, um conjunto de variveis, tais como os de sada de uma consulta de uma atividade web. Esta atividade no tem de ser alvo de um recurso, ela

53
exige que outra atividade verifique a entrada. Nesta fase, apenas uma instncia criada usando um mtodo 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 comunicao cliente-servidor pelo middleware. A atividade CharArraysResize (Figura 25) reestrutura as matrizes em uma dimenso que resulta na melhoria da eficincia quando transport-los via SOAP sobre HTTP. O tamanho dos arrays pode ser especificado pelo cliente e, se necessrio, 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 vrias formas, atravs de FTP, GridFTP, SMTP, ou, como na Figura 26, atravs de uma atividade DeliverToRequestStatus. Esta atividade assegura que quaisquer dados que sero recebidos, sero colocadas no pedido de status que retornado a um cliente por um DRER quando o seu workflow completa a execuo. A atividade de transformao referida, no 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 integrao mais fcil no corpo principal do cdigo. Ao realizar uma consulta especfica, como mostrada na Figura 20, a aplicao do OGSA-DAI deve conter uma atividade chamada grupo de recursos. Somente assim

54
ela poder direcionar uma consulta SQL para diversas fontes de dados. A atividade gerada o CreateResourceGroup. Ela espera que as IDs 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 so colocados em uma string (array) e passado para a atividade CreateResourceGroup como um parmetro (Figura 28).
String resources = new String[]{ id1, id2 }; CreateResourceGroup create = new CreateResourceGroup(); create.addResourceIdsAsArray(resources);
Figura 28 Recursos passados como parmetros

A lista da Figura 29 mostra um pedido em que a sada da atividade CreateResourceGroup, que a identificao do recm 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 disponvel a partir do resultado CreateResourceGroup. (Figura 30)
Drer.execute(createWorkflow, RequestExecutionType.SYNCHRONOUS); ResourceID groupID = create.nextResult();
Figura 30 Pedido disponvel

55
Aps a gerao da atividade CreateResourceGroup, outra atividade realiza a consulta em mltiplos BDs, 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 funo de agrupar esquemas de fontes de dados diferentes. Ao mesmo tempo em que essa atividade dispara a query para os bancos, o mesmo recebe os resultados e integrando-os em um nico resultset.

<sqlBag name="sqlAnd"> <sqlStatement value="SELECT * FROM littleblackbook WHERE id=5"/> <timeout> 100000 </ timeout> <sqlBagOutput name="sqlOutput"/> </sqlBag> </ sqlBag>
Figura 31 sqlBag

Os elementos da classe so: Name - nome exclusivo para a atividade dentro do escopo de um pedido. sqlStatement (obrigatrio) - 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 nmero no negativo e longo. Se o valor fornecido for zero, ento o tempo limite considerado ilimitado. Se o valor for superior a zero, ento considerado o mnimo entre o valor providenciado e o mximo tempo limite definido no padro SQL data resource accessor. Se nenhum valor for fornecido, ento o tempo limite igual ao tempo limite definido no SQL data resource accessor. sqlBagOutput (obrigatrio) - output stream que produz os resultados da consulta SQL. Agora, o novo recurso disponvel no CreateResourceGroup pode ser usado como meta para uma consulta no sqlBag, que executa a consulta. A criao de uma consulta ao sqlBag mostrada na Figura 32.
SQLBag query = new SQLBag(); query.setResourceID(groupID); query.addExpression("SELECT * FROM littleblackbook WHERE id<3");
Figura 32 Consulta realizada pelo sqlBag

56
Mais de uma expresso SQL podem ser adicionadas como o mtodo da Figura 32, caso se deseje realizar diversas consultas ao banco. Na consulta realiza neste trabalho, os resultados so transferidas para a atividade TupleToWebRowSetCharArrays que os transforma como XML e so entregues (Figura 33). Aps executar o pedido da Figura 36, os resultado podem ser recuperados a partir da atividade TupleToWebRowSetCharArrays. Para cada expresso SQL que foi adicionada ao sqlBag, haver um conjunto resultado disponvel. Cada chamada para TupleToWebRowSetCharArrays.nextResult() retorna um objeto java.sql.ResultSet para proporcionar o acesso linha de base dos resultados, como exemplificado na Figura 34.
TupleToWebRowSetCharArrays tupleToWebRowSet = new TupleToWebRowSetCharArrays(); tupleToWebRowSet.connectDataInput(query.getDataOutput()); DeliverToRequestStatus deliverToRequestStatus = new DeliverToRequestStatus(); deliverToRequestStatus.connectInput(tupleToWebRowSet.getResultOutput()); PipelineWorkflow pipeline = new PipelineWorkflow(); pipeline.add(query); pipeline.add(tupleToWebRowSet); pipeline.add(deliverToRequestStatus);
Figura 33 Atividade TupleToWebRowSetCharArrays

drer.execute(pipeline, RequestExecutionType.SYNCHRONOUS); while (tupleToWebRowSet.hasNextResult()) { ResultSet rs = tupleToWebRowSet.nextResultAsResultSet(); // iterate through the rows of the result set while (rs.next()) { ... // do something with the result values } }
Figura 34 - TupleToWebRowSetCharArrays.nextResult

57
A integrao dos resultados das sub-consultas tambm realizada pela atividade sqlBag, que coleta todos os resultados da query e os coloca em um nico result set que tambm incluir linhas duplicadas, caso existam. 4.8. Modificando Um Banco de Dados

O OGSA-DAI permite que modifique o banco de dados para que se possa realizar algumas atualizaes. Esse tipo de modificao realizada pela atividade sqlUpdateStatement. Essa atividade executa uma ou mais seqncias de uma declarao SQL atravs de uma conexo JDBC. O cdigo da Figura 35 mostra um exemplo da utilizao 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 so: Name: nome exclusivo da atividade dentro escopo de um pedido sqlParameter (zero ou mais): define um parmetro. o Position: posio dentro da expresso do elemento o From (opicional): nome da sada de outra atividade que fornece o valor desse parmetro o Se o valor do From no for especificado, ento esse elemento deve conter o valor do parmetro. o A seqncia em que os elementos aparecem importante quando a atividade sqlParameter fornecer o valor de mais de um parmetro. A seqncia em que os elementos aparecem a seqncia a ser entregue (Figura 36). Expression (Obrigatrio): declarao da atualizao SQL.

58
o A atualizao do SQL est dentro desse elemento. o ?: pode ser usado no lugar de qualquer parmetro definido no sqlParameter resultStream (Obrigatrio): produz o fluxo da sada do elemento XML que detm 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 razes pelas quais o OGSA-DAI pode ser mais adequado para o acesso aos dados e integrao, requisitados em um ambiente grid. Estas incluem:

Adapta-se com modelo grid / web service. O Workflow encapsula mltiplas interaes de web services em uma nica interao. Soluo para mltiplos acessos aos dados, transformao, distribuio e integrao de cenrios sem a necessidade de desenvolver atividades especficas de aplicativo. Extensa base de dados para consultas, atualizaes, transformao e distribuio. Framework extensvel e verstil, ou seja, desenvolvedores podem adicionar ou personalizar funcionalidades. Plataformas independentes. Roda em qualquer plataforma que suporte Java. Camadas de segurana complementares podem ser fornecidas, se necessrio. Por exemplo, autorizao pode ser feito no nvel de servio da web e / ou ao nvel dos recursos. Transparncia da localizao da base de dados e os tipos de produtos. Programao em uma linguagem neutra. O web services podem ser acessados a partir de clientes desenvolvidos em qualquer linguagem que suporta interao com web services. Funciona muito bem com outros middlewares que suportam grid, por exemplo, Axis / Tomcat e Globus Toolkit.

59
4.10. Desvantagens

O problema na utilizao OGSA-DAI inclui:

O acesso via Web mais lento do que o acesso direto aos dados ou ento via uma aplicao de web service dedicada.

Em particular, OGSA-DAI pode no ser adequado se:

Existe uma nica fonte de dados que no vai mudar. No tem nenhuma requisio para transformao de dados. O usurio querer ter um acesso rpido aos dados em um nico recurso.

60

5. ESTUDO DE CASO
5.1. Descrio da Aplicao

Ao realizar uma consulta em seus BDs, um Banco Privado deseja saber, dentre as pessoas que j tenham os dados cadastrados em suas fontes, quais os telefones para eventuais consultas. Essa informao necessria, pois, na matriz desse banco, ocorrem diversos telefonemas para cadastramento de habilitao da funo de carto de crdito para clientes que no a possuem. Para possibilitar a habilitao, sempre que houver a necessidade, e caso o cliente no tenha a funo em seu carto, realizada uma consulta nos dados cadastrais de todos os clientes que possuem carto desse banco, para descobrir aqueles que possuem a funo habilitada. Essa consulta s possvel, pois nos cadastros dos clientes, existe a informao do tipo do carto. Isso feito com o objetivo de tentar estabelecer um contato e solicitar uma possvel aderncia do cliente. Entretanto, caso no exista um banco de dados central, e as informaes podem estar presentes em diferentes filiais desse Banco, sempre que existe a necessidade de fazer este tipo de consulta, necessrio acessar as fontes de dados das filiais e da matriz. Alm disso, os dados podem estar armazenados em dois tipos de fontes, possuindo representaes diferentes, j que foram desenvolvidos de uma maneira independente. Assim, necessrio o acesso e a integrao destas duas fontes de dados, distribudas e heterogneas, de forma que uma nica viso, uniforme e homognea, seja fornecida. A base de dados "littleblackbook1", presente na unidade matriz, tem seus dados armazenados segundo o modelo de dados relacional armazenado em MySQL, como pode ser visto na Figura 37.

Figura 37 Esquema da Fonte Relacional littleblackbook da Matriz

Utilizamos um banco de dados MySQL como base e dentro dele criamos uma tabela chamada

littleblackbook com o auxilio do OGSA-DAI.

61
O banco de dados "littleblackbook", presente nas unidades da filial, tem seus dados armazenados no modelo de dados relacional em OracleSQL, como pode ser visto na Figura 38.

Figura 38 Esquema da fonte Relacional littleblackbook da Filial

Como as fontes de dados devem possuir o mesmo esquema, em termos de nome de tabelas e nome de atributos, uma mesma consulta encaminhada para cada fonte de dados a ser integrada (Figura 39).

Figura 39 - Consulta na linguagem SQL

Para realizar a Integrao necessrio ter o OGSA-DAI em todas as maquinas. A Figura 40 ilustra um exemplo de uma aplicao, onde de um lado est o OGSA-DAI Cliente e do outro lado as duas fontes de dados que sero integradas.

Figura 40 Diagrama de Implantao

62
5.2. Resourse File dos Bancos de Dados

Na mquina onde est rodando a aplicao cliente dever ser criado os arquivos de recursos (Resource File) de cada banco de dados que se deseja fazer a integrao. Na Figura 41 mostrado o Resource File necessrio para se conectar com banco MySQL presente na Matriz do banco privado.
id=MySQLDataResource type=uk.org.ogsadai.DATA_RESOURCE creationTime=null terminationTime=null PROPERTIES uk.org.ogsadai.resource.dataresource.product=MySQL uk.org.ogsadai.resource.dataresource.vendor=MySQL uk.org.ogsadai.resource.dataresource.version=5 END CONFIG dai.driver.class=org.gjt.mm.mysql.Driver dai.data.resource.uri=jdbc:mysql://localhost:3306/ogsadai dai.login.provider=uk.org.ogsadai.LOGIN_PROVIDER END ACTIVITIES uk.org.ogsadai.SQLQuery=uk.org.ogsadai.SQLQuery uk.org.ogsadai.SQLUpdate=uk.org.ogsadai.SQLUpdate uk.org.ogsadai.SQLBulkLoadTuples=uk.org.ogsadai.SQLBulkLoadTuples uk.org.ogsadai.GetAvailableTables=uk.org.ogsadai.GetAvailableTables uk.org.ogsadai.SQLParameterisedQuery=uk.org.ogsadai.SQLParameterisedQuery uk.org.ogsadai.SQLParameterisedUpdate=uk.org.ogsadai.SQLParameterisedUpdate uk.org.ogsadai.ExtractTableSchema=uk.org.ogsadai.ExtractTableSchema END dataResourceClass=uk.org.ogsadai.resource.dataresource.jdbc.JDBCDataResource
Figura 41 - SQLServer

Na Figura 42 mostrado o Resource File necessrio para se conectar com banco OracleSQL presente na Filial desse banco privado.

63
id=OracleDataResource type=uk.org.ogsadai.DATA_RESOURCE creationTime=null terminationTime=null PROPERTIES uk.org.ogsadai.resource.dataresource.product=Oracle uk.org.ogsadai.resource.dataresource.vendor=Oracle uk.org.ogsadai.resource.dataresource.version=10g END CONFIG dai.driver.class=oracle.jdbc.driver.OracleDriver dai.data.resource.uri=jdbc:oracle:thin:@myhost:1521:ogsadai dai.login.provider=uk.org.ogsadai.LOGIN_PROVIDER END ACTIVITIES uk.org.ogsadai.SQLQuery=uk.org.ogsadai.SQLQuery uk.org.ogsadai.SQLUpdate=uk.org.ogsadai.SQLUpdate uk.org.ogsadai.SQLBulkLoadTuples=uk.org.ogsadai.SQLBulkLoadTuples uk.org.ogsadai.GetAvailableTables=uk.org.ogsadai.GetAvailableTables uk.org.ogsadai.SQLParameterisedQuery=uk.org.ogsadai.SQLParameterisedQuery uk.org.ogsadai.SQLParameterisedUpdate=uk.org.ogsadai.SQLParameterisedUpdate uk.org.ogsadai.ExtractTableSchema=uk.org.ogsadai.ExtractTableSchema END dataResourceClass=uk.org.ogsadai.resource.dataresource.jdbc.JDBCDataResource
Figura 42 - OracleSQL

5.3.

Criando um Grupo de Fonte de Dados

Depois de ter adquirido o resource file dos bancos de dados e necessrio criar uma atividade (CreatResourceGroup), onde sero especificadas todas as fontes de dados que sero integradas (Figura 43).
String id1 = "MySQLDataResource"; String id2 = "OracleDataResource"; String resources = new String[]{ id1, id2}; CreateResourceGroup create = new CreateResourceGroup(); create.addResourceIdsAsArray(resources);

64
DeliverToRequestStatus deliverToRequestStatus1 = new DeliverToRequestStatus(); deliverToRequestStatus1.connectInput(create.getOutput()); PipelineWorkflow createWorkflow = new PipelineWorkflow(); createWorkflow.add(create); createWorkflow.add(deliverToRequestStatus1); drer.execute(createWorkflow, RequestExecutionType.SYNCHRONOUS); ResourceID groupID = create.nextResult();
Figura 43 Modelo de grupo de fonte de dados

5.4.

Criando uma Consulta

Logo aps de ter criado um grupo de fonte de dados necessrio cria outra atividade que realizara as consultas as fontes de dados que o Banco Privado possui (Figura 44).
SQLBag query = new SQLBag(); query.setResourceID(groupID); query.addExpression("SELECT * FROM littleblackbook WHERE id<10"); TupleToWebRowSetCharArrays tupleToWebRowSet = new TupleToWebRowSetCharArrays(); tupleToWebRowSet.connectDataInput(query.getDataOutput()); DeliverToRequestStatus deliverToRequestStatus = new DeliverToRequestStatus(); deliverToRequestStatus.connectInput(tupleToWebRowSet.getResultOutput()); PipelineWorkflow pipeline = new PipelineWorkflow(); pipeline.add(query); pipeline.add(tupleToWebRowSet); pipeline.add(deliverToRequestStatus); drer.execute(pipeline, RequestExecutionType.SYNCHRONOUS); while (tupleToWebRowSet.hasNextResult()) { ResultSet rs = tupleToWebRowSet.nextResultAsResultSet(); // itera atravs das linhas do result set while (rs.next()) {

65
// Neste local pode-se tratar o resultado da consulta } } createWorkflow.add(deliverToRequestStatus1);
Figura 44 Modelo de consulta

5.5.

Resultado da Consulta

A Tabela 3 mostra a consulta realizada pelo OGSA-DA na Fonte de dados da Matriz e Tabela 4 mostra a consulta realizada na Filial.

Nome Mario Krause Ally Jackson Tom Thompson Craig Atkinson Kostas Atkinson Craig Thompson Ali Sugden Mario Krause Malcolm Dobrzelecki Tom Chue Hong Bartosz Scott Kostas Anjomshoaa Craig Dobrzelecki David Scott Ali Atkinson Craig Krause David Antonioletti Bartosz Hume Neil Theocharopoulos Malcolm Hume

| Endereo | 45 Krause Avenue, Southampton | 43 Jackson Lane, San Jose | 17 Thompson Gardens, Winchester | 87 Atkinson Street, Edinburgh | 30 Atkinson Street, Edinburgh | 122 Thompson Road, San Jose | 1 Sugden Lane, San Jose | 120 Krause Place, Edinburgh | 128 Dobrzelecki Street, Edinburgh | 59 Chue Hong Lane, San Jose | 26 Scott Place, Edinburgh | 25 Dobrzelecki Crescent, Southampton | 89 Scott Avenue, Southampton | 40 Atkinson Crescent, Southampton | 100 Krause Street, Edinburgh | 80 Antonioletti Road, San Jose | 35 Hume Drive, Winchester | 106 Theocharopoulos Place, Edinburgh | 81 Hume Lane, San Jose

| Telefone | | | | | | | | | | | | | | | | | |

| Tipo_Cartao

272940105 | dbito 27258982 | dbito 273712657 | dbito 27972611 | dbito 272010467 | dbito 273140125 | dbito 27787831 | dbito 2742529 | dbito 27112289 | dbito 2737164 | dbito 277592124 | dbito 277811829 | dbito 27125717 | dbito 273857 | dbito 27577882 | dbito 27809757 | dbito 2799311 | dbito 278861111 | dbito 273610267 | dbito

| 2712317111 | dbito

| 119 Anjomshoaa Crescent, Southampton |

| 2710662105 | dbito

Malcolm Theocharopoulos | 2 Theocharopoulos Place, Edinburgh

Tabela 3 Resultado da Consulta na Matriz (MySQL)

66
Nome Tom Scott Mario Atkinson Mike Theocharopoulos David Anjomshoaa Mario Illingworth Mike Sugden Malcolm Chue Hong Ali Krause Bartosz Krause Bartosz Karasavvas Ali Chue Hong Mario Hume David Anjomshoaa Ali Scott Craig Theocharopoulos Malcolm Karasavvas Kostas Jackson | | | | | | | | | | | | | | | | | | Endereco 58 Scott Crescent, Southampton 86 Atkinson Crescent, Southampton 10 Theocharopoulos Avenue, Southampton 80 Anjomshoaa Crescent, Southampton 120 Illingworth Street, Edinburgh 115 Sugden Road, San Jose 128 Chue Hong Drive, Winchester 6 Krause Place, Edinburgh 27 Krause Place, Edinburgh 95 Karasavvas Gardens, Winchester 61 Chue Hong Lane, San Jose 87 Hume Road, San Jose 105 Anjomshoaa Street, Edinburgh 1 Scott Crescent, Southampton 28 Theocharopoulos Place, Edinburgh 3 Karasavvas Road, San Jose 31 Jackson Lane, San Jose | | | | | | | | | | | | | | | | | | Telefone 275692124 274211829 27105717 279162105 271857 27157882 27249757 27409311 2712361111 2754455 2712010267 2711169125 27342931 2773843 27534329 27643689 2762960 | | | | | | | | | | | | | | | | | | Tipo_Cartao dbito dbito dbito dbito dbito dbito dbito dbito dbito dbito dbito dbito dbito dbito dbito dbito dbito

Tabela 4 Resultado da Consulta da Filial (Oracle)

Depois

de

ter

especificado

os

banco

de

dados,

ter

criado

atividade

CreatResourceGroup, onde nesta atividade passado todas as informaes sobre as fontes de dados que sero integradas, e de ter criado uma outra atividade (SQLBag) que realiza consultas ao grupo especificado, a Tabela 5 mostra o resultado desta consulta realizada nas fontes de dados do Banco Privado.

Nome Mario Krause Ally Jackson Tom Thompson Craig Atkinson Kostas Atkinson Craig Thompson Ali Sugden Mario Krause Malcolm Dobrzelecki Tom Chue Hong Bartosz Scott Kostas Anjomshoaa Craig Dobrzelecki David Scott Ali Atkinson Craig Krause David Antonioletti Bartosz Hume Malcolm Theocharopoulos Neil Theocharopoulos Malcolm Hume

| Endereco | 45 Krause Avenue, Southampton | 43 Jackson Lane, San Jose | 17 Thompson Gardens, Winchester | 87 Atkinson Street, Edinburgh | 30 Atkinson Street, Edinburgh | 122 Thompson Road, San Jose | 1 Sugden Lane, San Jose | 120 Krause Place, Edinburgh | 128 Dobrzelecki Street, Edinburgh | 59 Chue Hong Lane, San Jose | 26 Scott Place, Edinburgh | 119 Anjomshoaa Crescent, Southampton | 25 Dobrzelecki Crescent, Southampton | 89 Scott Avenue, Southampton | 40 Atkinson Crescent, Southampton | 100 Krause Street, Edinburgh | 80 Antonioletti Road, San Jose | 35 Hume Drive, Winchester | 2 Theocharopoulos Place, Edinburgh | 106 Theocharopoulos Place, Edinburgh | 81 Hume Lane, San Jose

| Telefone | | | | | | | | | | | | | | | | | | |

| Tipo_Cartao

272940105 | dbito 27258982 | dbito 273712657 | dbito 27972611 | dbito 272010467 | dbito 273140125 | dbito 27787831 | dbito 2742529 | dbito 27112289 | dbito 2737164 | dbito 277592124 | dbito 277811829 | dbito 27125717 | dbito 273857 | dbito 27577882 | dbito 27809757 | dbito 2799311 | dbito 278861111 | dbito 273610267 | dbito

| 2712317111 | dbito

| 2710662105 | dbito

67
Tom Scott Mario Atkinson Mike Theocharopoulos David Anjomshoaa Mario Illingworth Mike Sugden Malcolm Chue Hong Ali Krause Bartosz Krause Bartosz Karasavvas Ali Chue Hong Mario Hume David Anjomshoaa Ali Scott Craig Theocharopoulos Malcolm Karasavvas Kostas Jackson | 58 Scott Crescent, Southampton | 86 Atkinson Crescent, Southampton | 10 Theocharopoulos Avenue, Southampton | 80 Anjomshoaa Crescent, Southampton | 120 Illingworth Street, Edinburgh | 115 Sugden Road, San Jose | 128 Chue Hong Drive, Winchester | 6 Krause Place, Edinburgh | 27 Krause Place, Edinburgh | 95 Karasavvas Gardens, Winchester | 61 Chue Hong Lane, San Jose | 87 Hume Road, San Jose | 105 Anjomshoaa Street, Edinburgh | 1 Scott Crescent, Southampton | 28 Theocharopoulos Place, Edinburgh | 3 Karasavvas Road, San Jose | 31 Jackson Lane, San Jose Tabela 5 Resultado Integrado | | | | | | | | | 275692124 | dbito 274211829 | dbito 27105717 | dbito 279162105 | dbito 271857 | dbito 27157882 | dbito 27249757 | dbito 27409311 | dbito 2754455 | dbito

| 2712361111 | dbito | 2712010267 | dbito | 2711169125 | dbito | | | | | 27342931 | dbito 2773843 | dbito 27534329 | dbito 27643689 | dbito 2762960 | dbito

O resultado mostrado so as duas fontes de dados integradas que foram listadas na atividade CreatResourceGrup. O SQLBag o responsvel por est realizando a consulta a estes bancos de dados e o responsvel por integrar os dados enviados pelas fontes.

68

6. CONCLUSES
Computao em Grid tem se tornado muito popular. Muitos projetos tm sido iniciados para suportar, em parte, a viso de um Grid [FOSTER; KESSELMAN, 1999]. Com isso, a computao baseada em Grid tem emergido como um importante novo campo, distinto da computao distribuda convencional, dado que o seu foco est no compartilhamento de recursos, onde a principal idia criar a iluso de um supercomputador virtual, em grande escala, facilmente gerencivel e com uma grande quantidade de recursos (ciclos de CPU, dados, dispositivos de armazenamento etc.) sendo compartilhados [BERSTIS, 2003]. Outra tecnologia que tem emergido bastante ultimamente a integrao de dados feita por um middleware, no nosso caso o OGSA-DAI. Este modo de integrar dados libera o usurio de ter que gastar muitos recursos para fazer uma integrao manual de dados e mesmo assim ficar limitado a rede local para obter acesso aos dados. O middleware aqui discutido garante o acesso via Web dos dados mesmo que estes estejam distribudos atravs do mundo, mesmo que sejam de empresas diferentes ou at mesmo de bancos de dados distintos. Apesar dessas vantagens ainda existem neste middleware algumas desvantagens na sua utilizao, como por exemplo, a limitao que ele possui em termos de nmero de fontes de dados suportadas. Esse middleware no suporta integrao de esquemas diferentes. As fontes de dados devem possuir o mesmo esquema de tabela, porm, permite que os atributos possuam tipos diferentes de dados. Por estarmos utilizando integrao de dados em nosso sistema, isto nos oferece muitas vantagens como o fato de o usurio poder ter uma viso exclusiva dos dados que foram integrados, e tambm o fato de que esta integrao pode ocorrer sem que haja a necessidade de modificao das plataformas tecnolgicas existentes. Podemos acrescentar que este middleware chamado OGSA-DAI possui inmeras funcionalidades altamente necessrias para serem usadas na maioria das empresas existentes, fazendo com que ele seja bastante reconhecido por todos. Futuramente, pode-se utilizar a tecnologia do OGSA-DPQ, sendo um framework de integrao de dados na qual possvel coordenar e incorporar servios Web para anlise e recuperao de dados, e integrar diferentes tipos de esquemas. Ele utiliza os servios oferecidos pelo OGSA-DA para acessar as fontes distribudas geograficamente e com sistemas heterogneos.

69

REFERNCIAS BIBLIOGRAFICAS
ALDEMIR, N. et al. Ogsa-dqp: A service-based distributed query processor for the grid. In: UK e-Science All Hands Meeting Nottingham. EPSRC, 2003. AYRES, F.; PORTO, F.; MELO, R. An Extensible Query Execution Engine for Supporting New Query Execution Models. To appear in LNCS 2004. BARBOSA, A. C. P., 2001. Middleware para Integrao de Dados Heterogneos Baseado em Composio de Frameworks. Tese de Doutorado, PUC - Rio, Brasil, 2001. BARBOSA, A. C. P.; PORTO, F.; MELO, R. N. ConFigurable data integration middleware system. J. Braz. Comp. Soc., v. 8, n. 2, p. 12_19, 2002. BERSTIS, V. Fundamentals of Grid Computing. Dec 2003. Redbooks. BIANCARDI, C, 2005. Distribuio e Execuo de Wrappers em Ambiente de Grid para o CoDIMS. Tese de mestrado. BIANCARDI, C., SILVESTRE, L. J., & BARBOSA, A. C. P., 2005a. Uma abordagem grid para integrao de dados. In Proceedings of the XXVI Iberian Latin-American Congress on Computational Methods in Engineering CILAMCE 2005 BIANCARDI, C., SILVESTRE, L. J., & BARBOSA, A. C. P., 2005. Uma proposta para distribuio e execuo de wrappers em um ambiente de grid para o codims. In Proceedings of the WCGA. BUYYA, R. Grid Computing Info Centre (GRID Infoware). 2002. CAMPOS JR, M. A., ALVES, H., HIRA, A. Y., ZUFFO, M. K.. Computao em Gradena Sade: Proposta de uma Arquitetura Para Interao de Informaes Mdicas Distribudas. So Paulo - SP, Brasil CASTANO, S. et al. Ontology-based integration of heterogeneous xml

datasources. In: Proc. of 10th Italian Symposium on Advanced Database Systems SEBD'02. Isola d'Elba, Italy: [s.n.], 2002.

70
CIRNE, W.; NETO, E. S. Grids Computacionais: Da Computao de Alto Desempenho a Servios sob Demanda. 2005. Minicursos - Simpsio Brasileiro de Redes de computadores (SBRC). FONTES, V. et al. Codims-g: a data and program integration service for the grid. In: Proceedings of the 2nd Workshop on Middleware for Grid Computing. [S.l.]: ACM Press, 2004. FOSTER, I.; KESSELMAN, C. The Grid 2: Blueprint for a New Computing Infrastructure. Morgan Kaufmann Publishers Inc., 2003. FOSTER, I.; KESSELMAN, C.; TUECKE, S. Open grid services infrastructure (OGSI) version 1.0. Global Grid Forum Draft Recommendation, Junho 2003. GOLDCHLEGER, A. InteGrade: Um Sistema de Middleware para Computao em Grade Oportunista. Dissertao de Mestrado. USP, So Paulo - SP, Brasil, 2004. HAKIMPOUR, F. & GEPPERT, A., 2001. Resolving semantic heterogeneity in schema integration: an ontology based approach. In Proceedings of the international conference on Formal Ontology in Information Systems, volume 2001, pp. 297308, USA. HALEVY, A. Y. Data integration: A status report. In: Proceedings of 10th Conference on Database Systems for Business Technology and the Web (BTW 2003). Germany: [s.n.], 2003. JAKOBOVITS, Julho de 1997. KIM, W. (Ed.). Modern database systems: the object model, interoperability, and beyond. New York, NY, USA: ACM Press/Addison-Wesley Publishing Co., 1995. MOTRO, A.; BUNEMAN P. Constructing Superviews. In Proc. ACM SIGMOD Int. Conf. on Management of Data, 1981. http://www.ogsadai.org.uk REX. Integrating Autonomous Heterogeneous Information

Sources. Dept. of Computer Science & Engineering, University of Washington. 15 de

71
OGSA-DAI. http://www.ogsadai.org.uk acessado pela ltima vez em 29 de maio de 2008. PAPAKONSTANTINOU, Y.; ABITEBOUL, S. GARCIA-MOLINA, H. Object Fusion in Mediator Systems. Proceedings of the 22nd vldb conference Munbai (Bombay), India, 1996. PERREIRA BARBOSA, A. C., 2001. Middleware para integrao de dados heterogneos baseados em composies de frameworks. Tese de Doutorado, 2001, PUC Rio de Janeiro RJ, Brasil RODRIGUEZ-MARTINEZ, M.; ROUSSOPOULOS, N. Automatic deployment of application-specific metadata and code in mocha. In: EDBT'00: Proceedings of the 7th International Conference on Extending Database Technology. [S.l.]: SpringerVerlag, 2000. p. 69_85. ISBN 3-540-67227-3. SOTOMAYOR, B. The Globus Toolkit 3 Programmer's Tutorial. Dez 2003. Tutorial. Disponvel em: <http://gdp.globus.org/gt3-tutorial/>. TAKAI, O. K., ITALIANO, I. C., FERREIRA, J. E., 2005. Introduo de banco de dados: notas de aula. So Paulo SP, Brasil. TANENBAUM, A. S. Sistemas distribudos: Princpios e paradigmas. TREVISOL, G. G. (2004). Codims: Incorporando nova abordagem na

comunicao entre seus componentes. Monografia de Graduao - UFES. WIEDERHOLD, G. Mediation to deal with heterogeneous data sources. v. 1580, 1999.

72

ANEXO A MANUAL DO OGSA-DAI

Esse anexo mostra passo a passo os mecanismos necessrios para instalao e configurao do OGSA-DAI. A. PROGRAMAS NECESSRIOS Para o perfeito funcionamento do middleware OGSA-DAI, necessrio uma serie de softwares. Abaixo esto listados o software e a verso necessria para o funcionamento. a. Jakarta Tomcat Para usar a distribuio do OGSA-DAI Axis, necessrio a utilizao do Jakarta Tomcat 5.0, podendo realizar o download em http://tomcat.apache.org/download55.cgi#5.0.28. O middleware s foi testado nessa verso e no compatvel com a verso 5.5. b. Apache ANT recomendada a utilizao do ANT verso 1.6 ou superior, podendo realizar o download em http://ant.apache.org. c. Java requerido Java 1.4 ou 1.5, podendo realizar o download em http://java.sun.com/javase/downloads/index.jsp. OGSA-DAI no compila com Java 1.6. d. Programa de Banco de Dados necessrio a utilizao de um Banco de Dados. Para consulta de quais bancos o OGSA-DAI suporta, verifique o Captulo 4 OGSA-DAI desse artigo. B. DETALHES DOS BANCOS DE DADOS SUPORTADOS Cada BD possui diferentes drivers e diferentes URIs que so requeridas para a configurao dos bancos, mostrando o caminho para o OGSA-DAI. a. Drivers dos Bancos de Dados A tabela 6 so detalhados os drivers necessrios para cada banco de dados compatvel com OGSA-DAI.

73
Banco de Dados MySQL IBM DB2 Microsoft SQL Server Oracle Driver JARs Classes

MySQL Connector J/2 DB2 JDBC Driver Microsoft SQL Server JDBC Driver Oracle JDBC Drivers for Java 1.2+ Postgres JDBC Driver eXist XMLDB driver

PostgreSQL eXist

mysql-connector-java-5.0.4bin.jar db2jcc.jar, db2jcc_licence_cu.jar mssqlserver.jar, msbase.jar, msutil.jar ojdbc14.jar (this may be distributed in a file with a .zip - the file can be renamed to have a .jar extension). postgresql-8.1-407.jdbc3.jar exist.jar, xmlrpc-1.2patched.jar, xmldb.jar (xmldb.jar is shipped with OGSA-DAI).

org.gjt.mm.mysql.Driver com.ibm.db2.jcc.DB2Driver oracle.jdbc.driver.OracleDriver oracle.jdbc.driver.OracleDriver

org.postgresql.Driver org.exist.xmldb.DatabaseImpl

Tabela 6 Drivers de Banco de Dados

b. URIs dos Bancos de Dados A Tabela 7 so detalhados as URIs necessrios para cada banco de dados compatvel com OGSA-DAI.

Banco de Dados MySQL IBM DB2 Microsoft SQL Server Oracle PostgreSQL eXist

Exemplo de URI jdbc:mysql://myhost:3306/daitest jdbc:db2://myhost:50000/ogsadai jdbc:microsoft:sqlserver://myhost:1433;DatabaseName=ogsadai jdbc:oracle:thin:@myhost:1521:ogsadai jdbc:postgresql://myhost:5432/ogsadai xmldb:exist://myhost:9120/exist/xmlrpc/db/littleblackbook

Tabela 7 URIs dos Bancos de Dados

C. Fazendo o Download do OGSA-DA A Distribuio pode ser baixada do site do OGSA-DAI em http://www.ogsadai.org.uk. O usurio ter de registrar-se para obter um nome de usurio e senha para acessar os downloads.

74
D. Criando uma Base de Testes O OGSA-DAI contm um conjunto de clientes para criar uma base de teste. Para utilizar esses clientes preciso obter um driver para o banco de dados e, em seguida, definir o classpath. a. Pegando os Drivers do Bancos de Dados A Tabela 3 contm as informaes sobre os bancos de dados suportados pelo OGSADAI e onde se podem obter os drivers dos respectivos bancos. Deve-se pegar o driver especfico com extenso *.JAR para o seu BD e colocar esses recursos no diretrio da distribuio do OGSA-DAI (Figura 45).
OGSA-DAI/thirdparty/lib
Figura 45 Local onde se localiza os driver dos BDs no OGSA-DAI

Logo apos o usurio dever definir a classpath executando o comando da Figura 46 no Prompt de Comando:
$ Setenv.bat
Figura 46 Classpath

b. Criando uma Base de Testes OGSA-DAI fornece um conjunto de clientes simples para criar uma tabela chamada littleblackbook teste de dados que contm quatro colunas:

Id - ID nico (chave) do tipo INTEGER. Nome - primeiro e apelido do tipo VARCHAR (64). Endereo - endereo do tipo VARCHAR (128). Nmero de telefone celular do tipo VARCHAR (20).

Para criar uma base de testes, digite o seguinte comando: o Em DB2: $ Java uk.org.ogsadai.dbcreate.CreateTestDB2DB; o Em MySQL: $ Java uk.org.ogsadai.dbcreate.CreateTestMySQLDB; o Em Oracle: $ Java uk.org.ogsadai.dbcreate.CreateTestOracleDB; o Em PostegreSQL: $ Java uk.org.ogsadai.dbcreate.CreateTestPostgreSQLDB; o Em SQL Server: $ Java uk.org.ogsadai.dbcreate.CreateTestSQLServerDB

75
E. Implementando OGSA-DAI Para implantar OGSA-DAI Axis para Tomcat: Executar o Tomcat e logo depois executar o comando da Figura 47
$ Ant -Dtomcat.dir = / PATH / TO / TOMCAT -Ddai.host = HOST -Ddai.port = PORT buildDeployWARAndServices
Figura 47 Comando para criar uma base de dados

Aonde : PATH / TO / TOMCAT o caminho para o diretrio raiz do Tomcat. HOST o acolhimento em que Tomcat est rodando. Este deve ser um bom nome do host e no localhost. PORT a porta em que Tomcat aceita conexes. A porta 8080 e assumida como padro. Um arquivo OGSA-DAI WAR ser criado, copiado para o Tomcat. Em seguida, implantado um padro de servio OGSA-DAI. Se o servio de implementao falhar, e o Tomcat no reconhecer o arquivo WAR, execute o comando da Figura 48.
$ Ant-Dtomcat.dir = / PATH / TO / TOMCAT-Ddai.host = HOST-Ddai.port = PORT deployServices
Figura 48 Comando a ser executado caso o servio de implementao falhar

F. Fazendo teste no servidor Visite a seguinte link usando um navegador internet: http://HOST:PORT/dai/services/. Por exemplo: http://localhost:8080/dai/services/. Onde: HOST o host em que Tomcat est rodando. PORT a porta em que Tomcat aceita conexes.

Isto pressupe que o padro OGSA-DAI AXIS foi utilizado na implantao. Se tudo tem corrido bem, voc ver uma lista de servios, incluindo os servios OGSA-DAI, mais informao sobre as suas atividades e as suas ligaes ao servio descrio documentos WSDL.

76
a. A Pagina JSP do OGSA-DAI Visite a seguinte pgina usando um navegador internet: http://HOST:PORT/dai/dai-manager.jsp. Por exemplo: http://localhost:8080/dai/dai-manager.jsp. Onde:

HOST o host em que Tomcat est rodando. PORT a porta em que Tomcat aceita conexes.

Isto pressupe que o padro OGSA-DAI foi utilizado na implantao. Se tudo ocorrer bem voc ver informaes sobre a verso do OGSA-DAI, a lista de recursos mobilizados, incluindo o seu recurso de dados, bem como uma lista de atividades conhecida para o servidor. b. Realizando uma consulta de teste A linha de comando da Figura 49 para executar consultas SQL em uma fonte de dados e imprimindo os resultados. Voc pode especificar o ID da solicitao de dados da execuo dos recursos e o OGSA-DAI ir executar o pedido. Para executar uma consulta sobre um recurso de dados execute, por exemplo o seguinte comando:
$ Java uk.org.ogsadai.client.toolkit.example.SQLClient \-u http://localhost:8080/dai/services/ \-d MyOwnJDBCDataResource \-q "SELECT * FROM littleblackbook onde id <10"
Figura 49 Consulta a uma fonte de dados

G. Configurando o Servidor Para criar um arquivo de recurso relacional createRelationalConfig, execute o comando da Figura 50.
$ ant -Ddai.db.product=PRODUCT -Ddai.db.vendor=VENDOR -Ddai.db.version=VERSION \ -Ddai.db.uri=DATABASE-URI -Ddai.db.driver=DATABASE-DRIVER-CLASS \ Ddai.resource.id=RESOURCE-ID createRelationalConfig
Figura 50 Comando usado para configurar um servidor

77
Isso leva os seguintes argumentos:

Dai.db.product - argumento opcional aonde especifica o banco de dados e o nome do produto. Dai.db.vendor - argumento opcional especificando a base produto. Dai.db.version - argumento opcional aonde especifica o banco de dados e verso do produto. Dai.db.uri database da conexo URI. Verifique a Tabela 4 desse artigo. Dai.db.driver - database da classe driver. Verifique a Tabela 3 desse artigo. Dai.resource.id recurso de dados ID. A identificao dos recursos dos dados que mostram os dados relacionais. O recurso ter este arquivo ID como o seu nome.

Por exemplo, a configurao da Figura 51 cria um recurso para os dados do OGSADAI chamado MySQLDataResource que expe a base de dados do MySQL:
$ Ant-Ddai.db.product = MySQL-Ddai.db.vendor = MySQL-Ddai.db.version = 5 \Ddai.db.uri = jdbc: mysql: / / somehost: 3306/daitest \-Ddai.db . Driver = org.gjt.mm.mysql.Driver \-Ddai.resource.id = MySQLDataResource createRelationalConfig
Figura 51 MySQLDataResource

H. Desistalando o OGSA-DAI Para desistalar o OGSA-DAI Axis realize as seguintes operaes: 1. 2. Encerre o Tomcat. Delete os arquivos:

PATH / TO / TOMCAT / webapps / dai. PATH / TO / TOMCAT / webapps / dai.war. PATH / TO / TOMCAT / conf / Catalina / localhost / dai.xml.

Onde: PATH / TO / TOMCAT o caminho para o diretrio da raiz do Tomcat. Isto pressupe que o nome do webapps usado quando OGSA-DAI foi implantado foi executado desse local.

78

ANEXO B WORKFLOWS
O workflows um fluxo de trabalho e uma seqncia de atividades que esto ligadas umas s outras, estas atividades constituem um caminho atravs do qual ir o controle de fluxo de dados. O seguinte mtodo tem como parmetros as atividades j discutidas e as suas entradas e sadas conectados adequadamente e adicionadas a um PipelineWorkflow. A sada do SQLQuery conectada entrada do TupleToWebRowSetCharArrays que, por sua vez, tem sua sada ligada ao CharArraysResize que, por sua vez, tem sua sada ligada ao DeliverToRequestStatus. Estas atividades so ento adicionadas a todos os fluxos de trabalho utilizando o mtodo acrescentar (Figura 52).
public PipelineWorkflow makePipelineWorkflow(SQLQuery query, TupleToWebRowSetCharArrays transform, resize, DeliverToRequestStatus delivery) { // Create a new pipeline. PipelineWorkflow tempFlow = new PipelineWorkflow(); // Connect the query output to the transform input. transform.connectDataInput(query.getDataOutput()); // Connect the transform output to the transform input. resize.connectDataInput(transform.getResultOutput()); // Connect the transform output to the delivery input. delivery.connectInput(resize.getOutput()); // Add the activities to the pipeline. tempFlow.add(query); tempFlow.add(transform); tempFlow.add(resize); tempFlow.add(delivery); return tempFlow; }
Figura 52 PipelineWorkflow

CharArraysResize

Depois que um fluxo de trabalho foi criado o passo seguinte o de execut-lo utilizando o DataRequestExecutionResource (Figura 53).

79
public RequestResource executePipeline(PipelineWorkflow pipe) throws ServerCommsException, ServerException, ResourceUnknownException, ClientException, RequestException, ClientToolkitException { return mDRER.execute(pipe, RequestExecutionType.SYNCHRONOUS); }
Figura 53 DataRequestExecutionResource

O CTk toma o fluxo de trabalho e envia ao OGSA-DAI para execuo de servio web que expe o DRER. O DRER executa o fluxo de trabalho e retorna um pedido de status. A utilizao de uma atividade DeliverToRequestStatus significa que a consulta retorna os dados do pedido. Este mtodo retorna um RequestResource em que o CTk o deposita o pedido no OGSA-DAI servidor. O RequestExecutionType pode ser sincronizado, executa o mtodo e no retornar at o DRER, sobre o servidor OGSA-DAI, tenha concludo o fluxo de trabalho ou de execuo assncrono onde o mtodo retorna imediatamente, mas a DRER sobre o OGSA-DAI servidor ir continuar com o fluxo de trabalho execuo. Em tais casos, o servidor DRER ir criar uma solicitao dos recursos que o cliente possa, atravs da enquete RequestResource retornar por este mtodo A atividade DeliverToRequestStatus ir retornar o status do fluxo de trabalho e os resultados a partir da sua entrada para a RequestStatus ligado ao objeto.Isto obtido atravs da Figura 54.
RequestResource rr = sqlClient.executePipeline(pipeline); RequestStatus rs = rr.getRequestStatus();
Figura 54 DeliverToRequestStatus

Os resultados devem incluir a sada do TupleToWebRowSetCharArrays (os efeitos de CharArraysResize sejam transparentes em termos de contedo dos dados). A execuo do pedido pode ser verificada atravs da convocao do mtodo getExecutionStatu e o mtodo RequestStatus sobre o objeto. O cdigo da Figura 55 ir simplesmente imprimir o resultado da execuo.

80
RequestStatus rs = rr.getRequestStatus(); System.out.println(rs.getExecutionStatus());
Figura 55 RequestStatus

E, na maioria dos casos, a Figura 56 dever ser a sada.

uk.org.ogsadai.resource.request.status.COMPLETED
Figura 56 RequestStatus completo

Como um exemplo simples de usar os cdigos listados, um mtodo principal pode ser adicionados e utilizado. Lembrando que, a base de servios URL pode ser alterada, assim como o comando SQL e os dados dos recursos ID, dependendo do seu servidor de configurao. O cdigo da Figura 57 no leva em conta excees ate este ponto. As primeiras linhas criam uma consulta SQL e os recursos IDs.
public static void main(String[] args) throws Exception { String serverURL = "http://localhost:8080/dai/services/"; ResourceID drerID = new ResourceID("DataRequestExecutionResource"); String sqlStr = "SELECT * FROM littleblackbook WHERE id<3;"; ResourceID dataResourceID = new ResourceID("MySQLDataResource"); SQLClient iSQLClient = new SQLClient(); iSQLClient.setupServer(serverURL); iSQLClient.setupDRER(drerID); SQLQuery sqlQ = iSQLClient.makeSQLQuery(dataResourceID, sqlStr); DeliverToRequestStatus dtrs = iSQLClient.makeDeliverToRequestStatus(); TupleToWebRowSetCharArrays ttwrsca = iSQLClient.makeTupleToWebRowSetCharArrays(); CharArraysResize car = iSQLClient.makeCharArraysResize(); PipelineWorkflow pwf = iSQLClient.makePipelineWorkflow(sqlQ, ttwrsca, car, dtrs); RequestResource rr = iSQLClient.executePipeline(pwf); RequestStatus rs = rr.getRequestStatus(); System.out.println(rs.getExecutionStatus()); }
Figura 57 Mtodo Principal

81
Antes de passar a considerar as excees, a produo a partir da

TupleToWebRowSetCharArrays pode ser usado de vrias maneiras. Isto pode aceder diretamente atividade de sada e de obter acesso aos mtodos para o formato de sada resultante em uma tabela. Primeiro um pequeno mtodo que mostra ao TupleToWebRowSetCharArrays uma referncia direta ao pedido para que ela possa analis-la. Isso uma conseqncia da utilizao do CharArraysResize para melhorar o seu rendimento (Figura 58).
private static void setRequestStatus(TupleToWebRowSetCharArrays tupleToWebRowSet, DeliverToRequestStatus deliverToRequestStatus) { tupleToWebRowSet.getResultOutput().setDeliverToRequestStatusActivity(deliverToRequ estStatus); }
Figura 58 TupleToWebRowSetCharArrays

A Figura 58 mostra um pequeno mtodo para ajudar a melhorar as strings.

private static String pad(String base, int width) { StringBuffer baseBuffer = new StringBuffer(base); int padLength = width - base.length(); for (int i = 0; i < padLength; i++) { baseBuffer.append(" "); } return baseBuffer.toString(); }
Figura 59 strings pad

Depois de escrever o quadro de resultados, a TupleToWebRowSetCharArrays acessado diretamente aps que o pedido tenha acabado de ser escrito e executando em uma tabela usando os mtodos. O cdigo da Figura 60 ir utilizar o mtodo pad e escrever a tabela de sada.

82
Public void Printable(TupleToWebRowSetCharArrays tupleToWebRowSet) throws SQLException, DataStreamErrorException, UnexpectedDataValueException, WebRowSetResultSetParseException, DataSourceUsageException { if (tupleToWebRowSet.hasNextResult()) { // Get ResultSet. ResultSet rs = tupleToWebRowSet.nextResultAsResultSet(); // Get ResultSet metadata. ResultSetMetaData md = rs.getMetaData(); // Get column names and initial column widths. Int numColumns = md.getColumnCount(); String[] columns = new String[numColumns]; int[] widths = new int[numColumns]; for (int i = 0; i < numColumns; i++) { String column = md.getColumnLabel(i + 1); columns[i] = column; widths[i] = column.length(); } // Get ResultSet rows and update column widths also. Vector rows = new Vector(); while (rs.next()) { String[] fields = new String[numColumns]; for (int i = 0; i < numColumns; i++) { fields[i] = rs.getString(i + 1); if (fields[i] == null) { fields[i] = null; } widths[i] = Math.max(widths[i], fields[i].length());

83
} rows.add(fields); } rs.close(); // Print column names. String tableHeading = | ; for (int i = 0; i < numColumns; i++) { tableHeading += (pad(columns[i], widths[i]) + | ); } System.out.println(tableHeading); // Print rows. For (int j = 0; j < rows.size(); j++) { String[] row = (String[])rows.get(j); String rowString = | ; for (int i = 0; i < numColumns; i++) { rowString += (pad(row[i], widths[i]) + | ); } System.out.println(rowString); } } }
Figura 60 TupleToWebRowSetCharArrays Completo

84

ANEXO C CODIGO COMPLETO

import java.net.MalformedURLException; import java.net.URL; import java.util.Vector; import java.sql.ResultSet; import java.sql.ResultSetMetaData; import java.sql.SQLException;

import uk.org.ogsadai.client.toolkit.DataRequestExecutionResource; import uk.org.ogsadai.client.toolkit.DataValueIterator; import uk.org.ogsadai.client.toolkit.PipelineWorkflow; import uk.org.ogsadai.client.toolkit.RequestExecutionType; import uk.org.ogsadai.client.toolkit.RequestResource; import uk.org.ogsadai.client.toolkit.Server; import uk.org.ogsadai.client.toolkit.ServerProxy; import uk.org.ogsadai.client.toolkit.activities.block.CharArraysResize; import uk.org.ogsadai.client.toolkit.activities.delivery.DeliverToRequestStatus; import uk.org.ogsadai.client.toolkit.activities.sql.SQLQuery; import uk.org.ogsadai.client.toolkit.activities.transform.TupleToWebRowSetCharArrays; import uk.org.ogsadai.client.toolkit.exception.ClientException; import uk.org.ogsadai.client.toolkit.exception.ClientToolkitException; import uk.org.ogsadai.client.toolkit.exception.RequestException; import uk.org.ogsadai.client.toolkit.exception.ResourceUnknownException; import uk.org.ogsadai.client.toolkit.exception.ServerCommsException; import uk.org.ogsadai.client.toolkit.exception.ServerException; import uk.org.ogsadai.client.toolkit.exception.DataSourceUsageException; import uk.org.ogsadai.client.toolkit.exception.DataStreamErrorException; import uk.org.ogsadai.client.toolkit.exception.UnexpectedDataValueException; import uk.org.ogsadai.converters.webrowset.WebRowSetResultSetParseException; import uk.org.ogsadai.resource.ResourceID; import uk.org.ogsadai.resource.request.RequestStatus;

85
/** * Example SQL Client */ public class SQLClient { private Server mServer; private DataRequestExecutionResource mDRER;

/** * Constructor */ public SQLClient() { mServer = null; mDRER = null; }

/** * Method will retrieve an OGSA-DAI server from the parameter * serverURLstr. * * @param serverURLStr * @throws ClientToolkitException * @throws MalformedURLException */ public void setupServer(String serverURLStr) throws ClientToolkitException, MalformedURLException { mServer = new ServerProxy(); mServer.setDefaultBaseServicesURL(new URL(serverURLStr)); }

/**

86
* Method will get the DRER identified by the ResourceID from the server. * * @param drerID

* @throws ClientToolkitException */ public void setupDRER(ResourceID drerID) throws ServerException, ClientToolkitException { mDRER = mServer.getDataRequestExecutionResource(drerID); }

/** * Method creates a SQLQuery activity for the identified resource * and given query * @param dataResourceID * @param sqlStr * @return SQLQuery */ public SQLQuery makeSQLQuery(ResourceID dataResourceID, String sqlStr) { SQLQuery tempQuery = new SQLQuery(); tempQuery.setResourceID(dataResourceID); tempQuery.addExpression(sqlStr); return tempQuery; }

/** * Creates a new DeliverToRequestStatus activity * @return DeliverToRequestStatus */ public DeliverToRequestStatus makeDeliverToRequestStatus() {

87
return new DeliverToRequestStatus(); }

/** * Creates a new TupleToWebRowSetCharArrays activity * @return TupleToWebRowSetCharArrays */ public TupleToWebRowSetCharArrays makeTupleToWebRowSetCharArrays() { return new TupleToWebRowSetCharArrays(); }

/** * Creates a new CharArraysResize activity * @return CharArraysResize */ public CharArraysResize makeCharArraysResize() { CharArraysResize resize = new CharArraysResize(); resize.addArraySizeInput(5000); return resize; }

/** * * Creates a new pipelineworkflow for the three activities. * Connects the activities, query-transform-delivery * @param query * @param transform * @param delivery * @return PipelineWorkflow */ public PipelineWorkflow makePipelineWorkflow(SQLQuery query,

88
TupleToWebRowSetCharArrays transform, CharArraysResize resize, DeliverToRequestStatus delivery) { PipelineWorkflow tempFlow = new PipelineWorkflow(); transform.connectDataInput(query.getDataOutput()); resize.connectDataInput(transform.getResultOutput()); delivery.connectInput(resize.getOutput()); tempFlow.add(query); tempFlow.add(transform); tempFlow.add(resize); tempFlow.add(delivery); return tempFlow; }

/** * Executes a pipelineworkflow in a synchronous mode and returns * a requestResource * * @param pipe * @return RequestResource * @throws ServerCommsException * @throws ServerException * @throws ResourceUnknownException * @throws ClientException * @throws RequestException * @throws ClientToolkitException */ public RequestResource executePipeline(PipelineWorkflow pipe) throws ServerCommsException, ServerException, ResourceUnknownException, ClientException,

89
RequestException, ClientToolkitException { return mDRER.execute(pipe, RequestExecutionType.SYNCHRONOUS); }

/** * Prints a table format to standard output using the data from the * transform activity passed in as parameter. * * @param tupleToWebRowSet * @throws SQLException * @throws DataStreamErrorException * @throws UnexpectedDataValueException * @throws WebRowSetResultSetParseException * @throws DataSourceUsageException */ public void printTable(TupleToWebRowSetCharArrays tupleToWebRowSet) throws SQLException, DataStreamErrorException, UnexpectedDataValueException, WebRowSetResultSetParseException, DataSourceUsageException { if (tupleToWebRowSet.hasNextResult()) { // Get ResultSet. ResultSet rs = tupleToWebRowSet.nextResultAsResultSet(); // Get ResultSet meta data. ResultSetMetaData md = rs.getMetaData(); // Get column names and initial column widths. Int numColumns = md.getColumnCount(); String[] columns = new String[numColumns];

90
int[] widths = new int[numColumns]; for (int i = 0; i < numColumns; i++) { String column = md.getColumnLabel(i + 1); columns[i] = column; widths[i] = column.length(); } // Get ResultSet rows and update column widths also. Vector rows = new Vector(); while (rs.next()) { String[] fields = new String[numColumns]; for (int i = 0; i < numColumns; i++) { fields[i] = rs.getString(i + 1); widths[i] = Math.max(widths[i], fields[i].length()); } rows.add(fields); } rs.close(); // Print column names. String tableHeading = | ; for (int i = 0; i < numColumns; i++) { tableHeading += (pad(columns[i], widths[i]) + | ); } System.out.println(tableHeading); // Print rows. For (int j = 0; j < rows.size(); j++) { String[] row = (String[])rows.get(j); String rowString = | ; for (int i = 0; i < numColumns; i++)

91
{ rowString += (pad(row[i], widths[i]) + | ); } System.out.println(rowString); } } }

/** * Pads out a string to the width given as parameter * @param base * @param width * @return String */ private static String pad(String base, int width) { StringBuffer baseBuffer = new StringBuffer(base); int padLength = width base.length(); for (int i = 0; i < padLength; i++) { baseBuffer.append( ); } return baseBuffer.toString(); }

/** * Allow TupleToWebRowSetCharArrays access to the request status. * * @param transform * @param delivery */ private static void setRequestStatus(TupleToWebRowSetCharArrays tupleToWebRowSet,

92
DeliverToRequestStatus deliverToRequestStatus) { tupleToWebRowSet.getResultOutput().setDeliverToRequestStatusActivity(deliverToRequ estStatus); }

public static void main(String[] args) throws Exception { // Setup String serverURL = http://localhost:8080/dai/services/; ResourceID drerID = new ResourceID(DataRequestExecutionResource); SQLClient iSQLClient = new SQLClient(); ResourceID dataResourceID = new ResourceID(MySQLDataResource); String sqlStr = SELECT * FROM littleblackbook WHERE id<3;;

// Server iSQLClient.setupServer(serverURL); iSQLClient.setupDRER(drerID);

// Activities Creation SQLQuery sqlQ = iSQLClient.makeSQLQuery(dataResourceID, sqlStr); DeliverToRequestStatus dtrs = iSQLClient.makeDeliverToRequestStatus(); TupleToWebRowSetCharArrays ttwrsca = iSQLClient.makeTupleToWebRowSetCharArrays(); CharArraysResize car = iSQLClient.makeCharArraysResize();

// Workflow and Execution PipelineWorkflow pwf = iSQLClient.makePipelineWorkflow(sqlQ, ttwrsca, car, dtrs); RequestResource rr = iSQLClient.executePipeline(pwf); RequestStatus rs = rr.getRequestStatus();

// outputs

93
System.out.println(rs.getExecutionStatus()); iSQLClient.setRequestStatus(ttwrsca, dtrs); iSQLClient.printTable(ttwrsca); } }
Figura 61 Cdigo Completo

94

ANEXO D PERGUNTAS E RESPOSTAS

1 - Como representar uma fonte de dados no OGSA-DAI? Primeiramente, preciso obter as informaes das fonte de dados desejada, como por exemplo, a URI da fonte de dados, o driver e a verso desta fonte. Com isso em mos preciso criar um resource file contendo os argumentos necessrios. O prximo passo fazer o transporte deste resource file para o servidor Tomcat que est configurado na sua mquina. 2 - Como representar uma consulta no OGSA-DAI para as fontes que esto sendo integradas? O OGSA-DAI possui classes que realizam consultas em bancos de dados. Uma URI, um resource file e um comando SQL so os parmetros necessrios para fazer uma consulta em uma fonte de dados integrada ao OGSA-DAI. Todos estes parmetros devem estar includos numa classe especfica do OGSA-DAI que utilizada para fazer acesso ao banco. 3 - Existe um esquema global para a elaborao de consulta global ou tenho que consultar o esquema de cada fonte? O OGSA-DAI no possui a funcionalidade de estar construindo um esquema global, pois os esquemas de todas as fontes de dados que forem listados no CreatresourceGrupo devem conter o mesmo esquema, portanto a atividade SQLBag tem a funo de realizar a mesmo consulta SQL a todas as fontes.

4 - Como a consulta dividida em sub-consultas e enviadas para as fontes de dados envolvidas? No existe um esquema a global, pois todas as fontes devem possuir o mesmo esquema. Assim a mesma consulta enviada para todas as fontes atravs de atividades oferecidas pelo OGSA-DAI. Portanto existem atividades no OGSA-DAI capazes de realizar acesso a mltiplos bancos de dados. A primeira atividade a ser criada e a CreatResourceGrup, nesta atividade e criado um grupo de banco de dados que sero integrados. Logo aps criar um grupo de banco necessria criar outra atividade que realize a consulta nas fontes

95
de dados listadas, o SQLBag que tem como funcionalidade executar um comando SQL em todos os bancos listados na atividade CreatResourceGrup.

5 - Como os resultados das sub-consultas so integrados? A integrao dos resultados das sub-consultas feita pela atividade SQLBag, que coleta todos os resultados da query e os coloca em um nico result set que tambm incluir linhas duplicadas, caso existam.Caso seja enviado mais do que uma consulta para as fontes de dados, cada consulta ter o seu result set. 6 - Quais os recursos que o OGSA-DAI oferece para acesso fonte? O OGSA-DAI, oferece inmeras atividades que possibilitam acesso a fontes de dados heterogneas. Alm de possuir essas atividades o OGSA-DAI libera o usurio de estar criando novas atividades, pois o OGSA-DAI possui cdigo aberto. Possibilita ao usurio de estar realizando mudanas nas fontes de dados, como por exemplo, realizar um up-date, um delete, colocar ou retira linhas ou colunas na tabela.