You are on page 1of 127

CENTRO ESTADUAL DE EDUCAO TECNOLGICA PAULA SOUZA MESTRADO EM TECNOLOGIA

CELSO HENRIQUE PODEROSO DE OLIVEIRA

UMA PROPOSTA PARA IMPLANTAO DE ALGORITMO DE PLANEJAMENTO PARA BUSCAS DE BANCO DE DADOS EM GRID COMPUTACIONAL

SO PAULO DEZEMBRO DE 2006

CELSO HENRIQUE PODEROSO DE OLIVEIRA

UMA PROPOSTA PARA IMPLANTAO DE ALGORITMO DE PLANEJAMENTO PARA BUSCAS DE BANCO DE DADOS EM GRID COMPUTACIONAL

Dissertao apresentada como exigncia parcial para obteno do Ttulo de Mestre em Tecnologia no Centro Estadual de Educao Tecnolgica Paula Souza, no Programa de Mestrado em Tecnologia: Gesto Desenvolvimento e Formao, sob orientao do Prof. Dr. Maurcio Amaral de Almeida.

SO PAULO DEZEMBRO DE 2006

O48p

Oliveira, Celso Henrique Poderoso de Uma proposta para implantao de algoritmo de planejamento para buscas de banco de dados em grid computacional / Celso Henrique Poderoso de Oliveira. So Paulo, 2006. 114 f. + anexos Dissertao (Mestrado) Centro Estadual de Educao Tecnolgica Paula Souza, 2006. 1.Tecnologia da informao gesto e desenvolvimento. 2. Grid Computing. 3. OGSA-DAI. 4. Banco de dados. 5. Web Services. 6. Inteligncia Artificial. I. Ttulo. CDU 681.3:007

Voc no pode ensinar nada a um homem; voc pode apenas ajud-lo a encontrar a resposta dentro dele mesmo. Galileu Galilei

Resumo
OLIVEIRA, C. H. P. Uma proposta para implantao de algoritmo de planejamento para buscas de banco de dados em grid computacional. 2006. Dissertao (Mestrado) Centro Estadual de Educao Tecnolgica Paula Souza. O objetivo deste trabalho contribuir com a utilizao de grid computacional atravs da melhoria de servios de integrao dos sistemas gerenciadores de banco de dados neste ambiente. As Grids Computacionais tem sido utilizadas no meio acadmico como uma alternativa utilizao de computadores de alto desempenho por permitir que se utilize o poder de processamento de diversos microcomputadores em uma arquitetura distribuda. As aplicaes cientficas, por serem altamente paralelizveis, tm tirado proveito deste ambiente. A maior parte das aplicaes cientficas utilizam arquivos simples para armazenamento de dados. Alguns processos das aplicaes comerciais tambm podem ser paralelizveis e, portanto, podem tirar proveito da grid computacional. Contudo o mesmo no pode ser dito do meio de armazenamento. Este tipo de aplicao utiliza sistemas gerenciadores de banco de dados para armazenamento de dados. Integrar os produtos comerciais na grid tem demandado grande esforo da comunidade acadmica e comercial. A utilizao dos padres e a adequao aos middlewares disponveis so fundamentais para esta integrao. H mecanismos que permitem vincular os sistemas gerenciadores de banco de dados em uma grid computacional, mas diversos servios precisam ser desenvolvidos e adaptados. Foi elaborada uma pesquisa dos fundamentos da grid, dos sistemas gerenciadores de banco de dados e dos algoritmos da inteligncia artificial. Com base nos middlewares disponveis, identificou-se aquele que oferece alguns servios de integrao e foi acrescentado um servio especfico para planejamento de utilizao de recursos. Este trabalho estabelece um servio de planejamento de utilizao de banco de dados em uma grid computacional. Para isso utiliza algoritmos especficos da Inteligncia Artificial e o middleware que fornece os principais servios de acesso e manipulao em banco de dados. Palavras-Chave: Grid Computing, OGSA-DAI, Banco de dados, Web Services, Inteligncia Artificial

Abstract
OLIVEIRA, C. H. P. A computational planning algorithm proposal for implantation to database query in grid computing environment. 2006. Dissertao (Mestrado) - Centro Estadual de Educao Tecnolgica Paula Souza. The objective of this work is to contribute with the improvement of grid computing through integration services of the database management systems in this environment. The grid computing has been used in academic applications as an alternative to the use of high performance computers because it allows the equivalent power of processing of diverse microcomputers in a distributed architecture. Because scientific applications are highly parallelized, they have taken off advantage of this environment. Most of the scientific applications use simple archives for data storage. Some commercial applications processes also can be parallelized and, therefore, they can take off the same advantage of grid computing. However the same it cannot be said about the storage. This type of application uses database management systems for data storage. To integrate the commercial products in the grid has demanded great academic and commercial communities effort. The use of grid standards and adequacy to middlewares are very important for this integration. The middlewares have mechanisms that allow tying the database management systems in the grid, but many services need to be developed and adapted. A research of the grid beddings, the database management systems and of the artificial intelligence algorithms was elaborated. specific service for scheduling. This work establishes a computational scheduling service of database systems in the grid. For this it uses specific artificial intelligence algorithms and the middleware that Keywords: Grid Computing, OGSA-DAI, Databases, Web Services, Artificial Intelligence. supplies the main services of access and manipulation in database systems. Based on available grid middlewares, it was identified the one that offers some integration services with databases and it was added a

Lista de Figuras
Figura 2.1:Arquitetura de Grid Computacional....................................................................... 23 Figura 2.2: Modelo OGSA. Fonte: OGSA.............................................................................. 30 Figura 3.1: Estrutura de um Banco de Dados Virtual............................................................. 37 Figura 3.2: Arquitetura da Oracle............................................................................................ 40 Figura 3.3: Arquitetura da IBM............................................................................................... 40 Figura 4.1: Exemplo de Plano de Busca.................................................................................. 69 Figura 4.2: Algoritmo proposto em Gounaris(2004)............................................................... 71 Figura 5.1: Entradas e Sadas do sistema planejador............................................................... 76 Figura 5.2: Diagrama de Caso de Uso da proposta.................................................................. 79 Figura 5.3: Algoritmo proposto.............................................................................................. 81 Figura 5.4: Problema de Planejamento de Banco de Dados em Grid...................................... 83 Figura 6.1: Planejamento de Ordem Parcial de Consultas Complexas............................. ...... 85 Figura 6.2: POP com Restrio de Recursos e Monitoramento.............................................. 86 Figura 6.3: Algoritmo POP para elaborar o Plano de Execuo.............................................. 91 Figura 6.4: Algoritmo para Submisso................................................................................... 92 Figura 6.5: Submisso de buscas com Algoritmo POP com Restrio de Recursos e Monitoramento........................................................................................................................ 93 Figura 6.6: Mtrica do banco de dados orclCPoderoso.......................................................... 95 Figura 6.7: Mtrica do banco de dados MySQLCPoderoso................................................... 95 Figura 6.8: Mtrica do banco de dados orclFamilia................................................................ 96 Figura 7.1: Comparativo da Implementao dos Algoritmos................................................ 105 Figura 7.2: Ganho percentual entre as buscas com trs recursos no segundo algoritmo e dois recursos no primeiro algoritmo.............................................................................................. 106 Figura 8.1: Proposta de Repositrio de Planejamento........................................................... 109

Sumrio 1 Introduo ............................................................................................................. 12 1.1 Tema e problema ............................................................................................ 14 1.2 Objetivo.......................................................................................................... 14 1.3 Planejamento com IA...................................................................................... 14 1.4 Metodologia.................................................................................................... 15 1.5 Estrutura do Trabalho...................................................................................... 15 Parte I: Fundamentao Terica ........................................................................... 16 2 Grid Computacional............................................................................................... 16 2.1 Antecedentes................................................................................................... 16 2.1.1 Computao Distribuda........................................................................... 16 2.1.2 Redes de Computadores ........................................................................... 17 2.1.3 Sistemas Distribudos ............................................................................... 18 2.2 Grid Computacional........................................................................................ 18 2.2.1 Abrangncia............................................................................................. 19 2.2.2 Identificao ............................................................................................ 20 2.2.3 Uso .......................................................................................................... 20 2.2.4 Vantagens do Ambiente ........................................................................... 21 2.3 Arquitetura...................................................................................................... 21 2.3.1 Organizao Virtual ................................................................................. 22 2.4 Desenvolvimento de Sistemas em ambientes distribudos................................ 24 2.4.1 Ambiente de Programao........................................................................ 25 2.4.2 Ferramentas.............................................................................................. 26 2.4.3 Middleware .............................................................................................. 26 2.5 Middleware para Grid Computacional............................................................. 27 2.5.1 Open Grid Services Architecture (OGSA) e Open Grid Services Infrastructure (OGSI)................................................................................................... 29 2.6 Desenvolvimento para uma Grid Computacional............................................. 33 2.7 Descrio de Servios em Grid Computacional ............................................... 34 2.7.1 Ontologias................................................................................................ 34 2.7.3 Ontologias para descrio de recursos do Grid ......................................... 34 2.7.4 Arquitetura de Grids a partir de Ontologias .............................................. 34 3 Banco de Dados em Grid Computacional............................................................... 36 3.1 Data Grids....................................................................................................... 37

3.2 SGBD comerciais ........................................................................................... 38 3.3 SGBD Distribudos e Virtuais ......................................................................... 41 3.3.1 Banco de Dados e Distribuio................................................................. 41 3.3.2 Servio de Busca Distribuda.................................................................... 41 3.3.3 Replicao Seletiva .................................................................................. 41 3.4 Requisitos de um Banco de Dados em Grid..................................................... 42 3.4.1 Desafios ................................................................................................... 44 3.5 Servios de Acesso a Banco de Dados............................................................. 45 3.5.1 Servio de Banco de Dados ...................................................................... 46 3.5.2 Padronizao............................................................................................ 48 3.6 OGSA, OGSA-DAIS e OGSA-DAI ................................................................ 50 3.6.1 Virtualizao dos Dados........................................................................... 51 3.6.2 Representao .......................................................................................... 52 3.6.3 Implementao......................................................................................... 53 3.6.4 Servios e Interfaces de Dados ................................................................. 53 3.6.5 DataDescription ....................................................................................... 54 3.6.5.1 DataAccess........................................................................................ 54 3.6.5.2 DataFactory....................................................................................... 55 3.6.5.3 DataManegement .............................................................................. 56 3.7 Utilizao do WS-Agreement.......................................................................... 56 3.8 OGSA-DQP.................................................................................................... 57 4 Planejamento em Grid Computacional................................................................... 60 4.1 Inteligncia Artificial e Banco de Dados em Grid............................................ 60 4.1.1 Sistema Multi-agente ou Grid de agentes.................................................. 61 4.1.2 Escalonamento ......................................................................................... 61 4.1.3 Alternativas de Planejamento ................................................................... 62 4.1.4 Planejadores baseados em Restries ....................................................... 63 4.1.5 Fatores importantes para programao de recursos em Grid ..................... 63 4.1.6 As atividades como um problema de Planejamento .................................. 64 4.1.6 Planejamento de Ordem Parcial................................................................ 65 4.1.8 Gerenciamento de trabalho....................................................................... 66 4.1.9 Tcnica de Planejamento aplicada a bancos de dados da Grid................... 67 4.2 Auto-gerenciamento em SGBD....................................................................... 68 4.3 Soluo DQP .................................................................................................. 68

10

4.4 Crtica............................................................................................................. 71 Parte II: Proposta ................................................................................................... 73 5 Especificao do Problema .................................................................................... 73 5.1 Justificativa do uso de IA ................................................................................ 74 5.2 Arquitetura Orientada a Servios..................................................................... 75 5.3 Fases do Planejador......................................................................................... 75 5.4 Objetivo.......................................................................................................... 77 5.5 Pr-condies e Efeitos ................................................................................... 77 5.6 Heurstica ....................................................................................................... 77 5.7 Restries ....................................................................................................... 78 5.8 Regras de Busca.............................................................................................. 78 5.9 Proposta de Implementao............................................................................. 79 5.9.1Algoritmos e Heurstica............................................................................. 79 5.9.2 Algoritmo proposto .................................................................................. 81 6 Metodologia .......................................................................................................... 84 6.1 Mdulo Desenvolvido..................................................................................... 86 6.1.1 Identificao dos recursos disponveis...................................................... 87 6.1.2 Separao dos elementos do comando SELECT (parse)........................... 88 6.1.3 Vinculao dos recursos com as tabelas.................................................... 88 6.1.4 Verificao de Mtricas dos recursos........................................................ 89 6.1.5 Seleo dos recursos que executaro as buscas ......................................... 90 6.1.5.1 Plano de Ordem Parcial (POP) .............................................................. 90 6.1.5.2 Plano de Ordem Parcial com Restrio de Recursos e Monitoramento... 92 6.1.6 Unio das buscas e apresentao do resultado .......................................... 93 6.2 Bases de Dados utilizadas ............................................................................... 93 6.2.1 Base de dados Exemplo do OGSA-DAI ................................................... 93 6.2.2 Bio-informtica ........................................................................................ 94 Parte III: Resultados .............................................................................................. 95 7 Testes Realizados .................................................................................................. 95 7.1 Base de dados OGSA-DAI .......................................................................... 96 7.1.1 Resultado do Planejamento na terceira consulta........................................ 97 7.2 Base de dados Bio-informtica.................................................................... 97 7.2.1 Resultado do Planejamento com dois recursos em POP ............................ 98

11

7.2.2 Resultado do Planejamento com dois recursos em POP com Restrio de Recursos e Monitoramento......................................................................................... 100 7.2.3 Resultado do Planejamento com trs recursos em POP com Restrio de Recursos e Monitoramento ......................................................................................... 102 8 Concluso............................................................................................................ 107 9 Trabalhos Futuros ................................................................................................ 109 10 Referncias ........................................................................................................ 111 Glossrio ................................................................................................................ 114 Anexo A Estrutura da Tabela de Mtrica ............................................................. 118 Anexo B Estrutura das Tabelas de Teste .............................................................. 119 Anexo C Roteiro de Instalao do Ambiente........................................................ 124

12

1 Introduo
As Grids Computacionais aparecem como uma alternativa bem-sucedida de otimizao do uso de recursos em um ambiente distribudo. Por este motivo vrios Centros de Pesquisa no mundo todo tm estudado formas de melhorar o desempenho das aplicaes e aumentar a quantidade de servios disponibilizados pelo ambiente. A idealizao desse ambiente se deu a partir da necessidade de se trabalhar com os recursos computacionais como se fossem servios disponibilizados aos usurios. Atendendo a tendncia de se trabalhar de maneira distribuda, os recursos computacionais podem estar dispersos na rede e serem alocados para realizar uma atividade durante o tempo em que estiverem ociosos. O poder computacional dessa soluo equipara-se a supercomputadores, pois que so utilizadas dezenas e muitas vezes centenas de computadores para realizar as operaes [Chede, 2005]. Para isso criou-se uma infra-estrutura capaz de realizar o intercmbio de informaes entre os recursos. Esta infra-estrutura denomina-se middleware. Atravs do middleware possvel alocar dinamicamente os recursos e vincul-los a tarefas que, depois de processadas, retornam o resultado final a quem solicitou, independente de onde tenha sido realizado o processamento [Foster, 2001]. A evoluo das tcnicas de desenvolvimento de sistemas permitiu que se criassem servios espalhados pela rede. Com um servio de diretrios eficiente, os servios so localizados e disponibilizados para os usurios. Isso resolve o problema do processamento dos dados. A maior parte das aplicaes em uso na Grid Computacional, por serem sistemas de anlise de dados cientficos, utilizam arquivos de dados ao invs de banco de dados [Watson et al., 2003]. Em grande parte isso acontece porque os gerenciadores de bancos de dados no esto adaptados para trabalhar adequadamente neste ambiente. O ambiente para o qual foram criados os gerenciadores est direcionado para uso comercial. H mecanismos de agilizao do processo de busca e facilidade na programao de rotinas especficas para tratamento de dados. Est comprovado que as aplicaes cientficas podem alcanar melhor desempenho se utilizarem bancos de dados por estes serem otimizados para a realizao de tarefas intrnsecas do processamento de dados [Nieto-Santisteban et al, 2004].

13

Estabelecer o uso de bancos de dados em um ambiente de Grid Computacional tem requisitado muito esforo e pesquisa e a integrao dos gerenciadores certamente dar um passo decisivo para a utilizao da Grid Computacional [Watson et al, 2003]. O desenvolvimento baseado em servios apresenta-se como o mais adequado para estabelecer um mecanismo de acesso e controle dos recursos de banco de dados [Watson et al., 2003]. Como esta arquitetura indica o que deve ser feito e no como ser implementado, utilizar web services para descrever o que pode ser realizado por cada banco de dados mais adequado dentro do objetivo bsico da Grid Computacional que a distribuio dos recursos computacionais. O grupo DAIS (Data Access and Integration Services) do GGF (Global Grid Forum) tem trabalhado na definio dos requisitos de integrao dos bancos de dados com a Grid Computacional. A idia central criar padro de acesso a qualquer banco de dados que realize o intercmbio entre as informaes necessrias para as aplicaes e o acesso e manipulao dos dados nos bancos de dados comerciais. O DAIS trabalha com um framework para os recursos de dados com objetivo de criar um padro de servio baseado na OGSA (Open Grid Service Architecture) [OGSI-GGF, 2005]. A OGSA a arquitetura bsica para implementao de servios em uma Grid Computacional. Esta arquitetura est baseada na SOA (Service Oriented Architecture). A proposta baseada em quatro interfaces: Descrio de Dados, Acesso aos Dados, Fbrica dos Dados e Gerenciamento dos Dados. Segundo esta proposta, qualquer servio que implemente pelo menos uma dessas interfaces considerado um servio de dados. O foco principal do grupo est nas trs primeiras interfaces. A quarta interface (gerenciamento dos dados) tem a responsabilidade de especificar como a virtualizao dos dados est construda e deve prover as operaes de configurao, controle e poltica de acesso aos dados. A virtualizao de dados a possibilidade de se trabalhar com conjuntos de dados desvinculados da implementao fsica. responsabilidade dessa interface definir os servios que sero utilizados para atender aos requisitos de virtualizao, gerenciamento e compartilhamento dos recursos. Desta forma necessrio identificar quais recursos esto disponveis, programar a utilizao dos mesmos e controlar a execuo do servio. Como h outros grupos que trabalham nessa interface, este no o foco de estudo do grupo. Em paralelo, um grupo tem desenvolvido um middleware que garante o acesso aos servios disponveis de cada banco de dados da Grid, mas sem reduzir a capacidade de processamento dos recursos.

14

O grupo DAIS criou um middleware, OGSA-DAI (Data Access and Integration), para permitir a disponibilizao de servios de banco de dados. Esta soluo baseia-se na OGSA que, por sua vez, est baseado na OGSI (Open Grid Service Infrastructure) [OGSA-DAI, 2006]. Desta forma, uma arquitetura baseada em uma infra-estrutura permite que se estabeleam os mecanismos de integrao com os banco de dados e indicam quais servios podem ser realizados em determinado contexto. O usurio solicita ao OGSA-DAI aquilo que necessrio realizar no banco de dados e este se incumbe de entregar a requisio aos recursos que foram especificados.

1.1 Tema e problema


O tema sob o qual versa o presente trabalho o uso de Gerenciadores de Banco de Dados em Grid Computacional e o problema o planejamento de utilizao dos recursos com base nos comandos de busca em Banco de Dados distribudos em Grid Computacional.

1.2 Objetivo
O objetivo deste trabalho criar um sistema que intercepte as requisies do usurio, pois atualmente o usurio deve indicar o recurso e o comando de busca. Tambm dever verificar quais recursos h no ambiente. Ao interceptar o comando e identificar os recursos, o sistema dever subdividi-lo para que as buscas sejam particionadas e paralelizadas sempre que possvel. Depois de escalonada a busca e estabelecido o fluxo de trabalho necessrio para atender as requisies do usurio, o sistema dever submet-la ao OGSA-DAI que realizar a o trabalho de intercmbio com os gerenciadores de banco de dados. Espera-se que, ao final do trabalho, o desempenho da pesquisa do usurio ser melhor e haver ganho de produtividade na utilizao do ambiente.

1.3 Planejamento com IA


Para realizar o trabalho de planejamento sero utilizados algoritmos de Inteligncia Artificial com objetivo de achar a melhor soluo possvel dentro do espao de estados disponvel. Os principais gerenciadores de bancos de dados fornecem informaes do recurso onde est instalado e estas informaes serviro para estabelecer uma heurstica compatvel com a necessidade de processamento da atividade. O sistema planejador dever estar baseado nas mais recentes discusses sobre a viabilidade e aplicabilidade da teoria de programao de restries para programao de recursos em ambientes distribudos.

15

1.4 Metodologia
A metodologia utilizada ser o teste emprico da soluo proposta. Poder ser medida a eficincia da soluo atravs da submisso e interceptao do comando de busca na OGSADAI e na verificao dos comandos de busca submetidos ao ambiente.

1.5 Estrutura do Trabalho


O trabalho est dividido em 5 captulos: Grid Computacional: so comparadas as diversas formas de computao distribuda e apresentados os principais conceitos relacionados Grid Computacional. Os principais middlewares disponveis sero identificados e ser dada uma nfase especial no OGSA e OGSA-DAI. Banco de Dados em Grid: faz uma abordagem conceitual do que se espera de um banco de dados em Grid e as diversas formas que podem ser utilizados os bancos de dados em ambiente distribudo. Identifica uma soluo que tem uma proposta parecida com a deste trabalho (OGSA-DQP ). Planejamento em Grid: ser feita uma reviso quanto aos mtodos de programao de recursos com variveis de restrio e sero estudadas formas de implementao da soluo proposta. Sero estabelecidos os mecanismos bsicos para realizar o planejamento dos servios na OGSA-DAI e as heursticas que se adaptam ao modelo proposto. Proposta: especifica a proposta apresentada por este trabalho, mesclando todos os conceitos para estabelecer um algoritmo bsico para o planejamento proposto. Implementao da Soluo e Avaliao: discute os aspectos bsicos dos resultados alcanados.

16

Parte I: Fundamentao Terica 2 Grid Computacional


2.1 Antecedentes
2.1.1 Computao Distribuda
Uma Grid Computacional uma srie de servios para processamento e armazenamento de dados em um ambiente de Computao Distribuda. Diversas formas de distribuir processamento e armazenamento tem sido desenvolvidas ao longo da evoluo da computao. Como os processadores tm evoludo em menor velocidade nas ltimas dcadas devido s limitaes fsicas dos componentes utilizados [Dantas, 2005], o processamento distribudo procura contornar esta situao ao ampliar os equipamentos envolvidos no processamento dos dados. Ainda segundo Dantas [Dantas, 2005], a computao distribuda de alto desempenho pode ser entendida como um segmento da computao que tem como objetivo a melhoria do desempenho das aplicaes distribudas e paralelas, utilizando-se de complexas infra-estruturas computacionais. Inicialmente os computadores trabalhavam de maneira isolada. Depois passaram a operar em redes departamentais que, por sua vez, se interligavam aos grandes servidores. O resultado desta implementao, contudo, estava aqum do esperado e houve a necessidade de distribuir o processamento e armazenamento de dados. Da descentralizao para a distribuio do processamento, processo que ainda est em fase de amadurecimento, os ganhos tm sido mais satisfatrios [Oliveira, 2004]. Inicialmente os servidores departamentais foram interligados em um ambiente nico em muitos casos substituindo computadores de grande porte. O processo de agrupamento, conhecido por clustering, de servidores possibilita distribuir o processamento e armazenamento. Do ponto de vista do cliente da aplicao h um nico servidor fornecendo dados e processamento rede, mas na realidade os diversos servidores disponveis esto encapsulados pela tecnologia. Em caso de falha em um servidor, outro automaticamente assume a tarefa que estava sendo executada. O poder de processamento dos servidores passou a competir com equipamentos de maior porte. Naturalmente este processo trouxe maior segurana e velocidade ao processamento dos dados e, ento, os sistemas de misso crtica comearam a serem utilizados nestes servidores. A caracterstica bsica de um cluster

17

permitir a distribuio de tarefas entre os servidores, mas esta tecnologia est restrita a um nico (e limitado) ambiente fsico e tem um nico proprietrio [Dantas, 2005]. O gerenciamento dos recursos de um cluster centralizado. As principais caractersticas de um cluster, segundo [Dantas, 2005]: - Equipamentos dedicados exclusivamente ou no execuo de tarefas. - Componentes de hardware ou software homogneos ou heterogneos; - Limita-se at as fronteiras da organizao; - Redes de conexo compartilhada, ponto-a-ponto ou hbrida; - Orientadas a aplicaes de alto desempenho. Desta forma, pode-se entender cluster como sistemas de dois ou mais servidores que trabalham como se fossem um nico para realizar processamento com alto volume de requisies. utilizado para processamento paralelo, com balanceamento de carga e tolerncia a falhas.

2.1.2 Redes de Computadores


Devido centralizao do processamento e limitao tecnolgica, os computadores de grande porte realizavam todo processamento, armazenamento e distribuio de dados pela rede. Os terminais de usurio no tinham qualquer capacidade de processamento. Serviam apenas como uma interface para o que era processado pelo computador central. Na dcada de 1970, devido a necessidade de comunicao mais rpida entre os meios acadmicos de pesquisa, foi desenvolvido o email. Os protocolos de rede evoluram rapidamente e, ainda nesta dcada, so disponibilizados a Ethernet e o TCP/IP. Este ltimo deu o passo fundamental para a proliferao da era da Internet, j em um passado mais recente. A partir do momento em que os computadores pessoais foram difundidos, cada usurio comeou a realizar algum processamento local. Houve necessidade de compartilhar recursos, como discos para armazenamento, impressoras, etc. Foram criadas as redes locais. Na dcada de 80 estabelece-se o padro WWW e HTML. Os navegadores da Internet se popularizam com o conceito de Web e seus respectivos servios. Novos padres se estabelecem para fazer frente a crescente necessidade de integrao do ambiente. Com a ampla utilizao da Internet, a banda de comunicao vem sendo aumentada para melhorar o desempenho e acesso grande rede de computadores. Atualmente boa parte dos centros de pesquisa e at mesmo dos usurios comuns j tm acesso a Internet utilizando banda larga [Oliveira e Almeida, 2005].

18

A Internet o ambiente natural para o processamento de uma Grid Computacional. Pode-se dizer que a Grid s conseguiu o avano atual devido a massificao da Internet.

2.1.3 Sistemas Distribudos


As aplicaes que potencialmente podem ser utilizadas neste ambiente so as distribudas e as paralelas. Aplicaes distribudas so as que utilizam recursos distribudos, portanto podem ou no guardar relao entre si. Neste caso, uma aplicao pode ser executada independente das outras aplicaes e o desempenho delas ser completamente particular. J as aplicaes paralelas so as que se subdividem em pores menores. Estas pores so distribudas entre processadores distintos e, naturalmente, guardam interdependncia entre si. Ao final do processamento a unio destas pores produzir um nico resultado [Dantas, 2005]. Ao se utilizar diversos recursos computacionais dispersos na rede e com pouco uso, obtm-se ganhos considerveis sobre o investimento realizado. De qualquer forma, necessrio que se dedique um esforo para resolver alguns problemas especficos de um ambiente distribudo [Dantas, 2005]: Segurana: aplicativos executados remotamente podem estar expostos a indivduos ou processos no autorizados. Retardo de comunicao: a comunicao entre os servidores pode ser dificultada ou impedida devido a restries na rede. Disponibilidade dos recursos: em ambientes distribudos pode-se, eventualmente, perder o contato com os servidores. Compatibilidade dos pacotes de software: a diferena entre processamento, sistema operacional e compiladores, entre outros, pode dificultar ou at mesmo impedir a realizao do servio.

2.2 Grid Computacional


Ainda na dcada de 1960, imaginou-se que o acesso s informaes e ao processamento seria realizado da mesma forma como hoje em dia utilizamos a energia eltrica ou o telefone. Da mesma forma como no se precisa de uma usina geradora de energia em casa para ter acesso energia eltrica, tambm no haveria necessidade de um computador para ter acesso ao processamento e armazenamento de dados [Oliveira, 2004]. Este tipo de computao deveria ser elaborado exatamente como as malhas de energia eltrica. Assim, quando fosse necessrio utilizar um recurso, simplesmente o usurio deveria

19

se conectar a grandes servidores que forneceriam todo poder de processamento e armazenamento. Haveria uma taxa que seria paga de acordo com o uso, exatamente como acontece nos servios de telefonia ou energia eltrica. Para uma primeira definio, pode-se entender uma Grid Computacional como um grupo de recursos heterogneos, distribudos e integrados que compartilha diversos recursos como se fossem um nico e que utilizam redes de altssima velocidade [Foster, 2001]. um ambiente em que se permite balanceamento de carga, segurana de acesso e tolerante a falhas. A diferena bsica entre uma Grid e um cluster est na descentralizao, amplitude e heterogeneidade dos recursos e servios que so utilizados para prover o processamento e armazenamento de dados em uma rede. O gerenciamento de uma Grid realizado de maneira descentralizada, normalmente pelo dono do recurso. Em [Dantas, 2005] h uma comparao com os servios de telefonia: cada operadora seria um cluster, pois gerencia seus recursos de maneira centralizada. A interligao entre dois usurios de diferentes operadoras se d atravs de protocolos combinados entre elas. Este , portanto, um servio prestado, exatamente como os servios de uma Grid Computacional. No h um gerenciamento centralizado, pois cada operadora responde individualmente pelo servio que presta e disponibiliza. De qualquer forma, deve estar claro que o limite entre um e outro tnue e pode ser facilmente confundido. Pode-se entender que, baseado nas definies clssicas de uma Grid Computacional, um nico computador pessoal uma Grid ou que, por estar conectado a uma rede local, esteja em uma Grid de clusters ou ainda que, por permitir o armazenamento em diversos recursos, esteja em uma Grid de armazenamento [Foster, 2002]. Como se nota, possvel obter diversas definies de Grid Computacional e todas tm um certo grau de coerncia mesmo que completamente dspares.

2.2.1 Abrangncia
Uma Grid Computacional pode ser formada a partir de diversos nveis de utilizao. Conceitualmente divide-se em [Chede, 2005]: Local: so Grids internas de uma nica empresa. A configurao pode ser vista como um cluster, com gerncia de ambiente nico [Dantas, 2005]. Tambm conhecida por intragrid, enterprise ou campus. Regional: so Grids formadas entre empresas parceiras ou que tenham interesse comum. Nesse caso deve haver mais de uma organizao envolvida. Tambm conhecida por extragrid ou partner.

20

Global: so Grids amplas, formadas por redes interligadas com abrangncia em diversas localidades. Pode ser composta por centenas ou milhares de organizaes. Tambm conhecida por intergrid.

2.2.2 Identificao
Para determinar se uma tecnologia est vinculada Grid Computacional ou no, devese identificar [Foster, 2002]: Recursos no devem estar subordinados a um controle central: uma vez que a Grid integra diversos recursos, usurios e domnios, caso esteja vinculado a um controle nico, tem-se um sistema de gerenciamento local e no uma Grid. Utilizao de protocolos e interfaces padronizadas, de uso mltiplo e aberto: como a Grid trabalha com recursos heterogneos, necessrio adotar padres abertos de comunicao. Do contrrio haver um sistema de aplicao especfica. Entrega de servios de alta qualidade: o objetivo da Grid fornecer poder de processamento e armazenamento onde se integrem diversos recursos dispersos pela rede. Caso o resultado final no seja melhor que a soma das partes, no faz sentido utiliz-la.

2.2.3 Uso
Podemos dividir as aplicaes que podem extrair vantagens na utilizao de uma Grid Computacional em dois grandes grupos: Cientficos: utilizados para sintetizao de teorias e modelos, representa a maior quantidade de Grids ativas atualmente. O desafio tem sido o de unir diversos conhecimentos e processar as informaes em altas velocidades. Dado que as fontes de informao encontram-se dispersas, necessrio que haja integrao entre elas para se chegar a resultados satisfatrios [Gil, 2004]. Uso Geral: diversas empresas e segmentos podero fazer uso da Grid Computacional para otimizar o uso dos recursos computacionais, diminuindo significativamente o investimento em novos equipamentos. Alm disso, alguns processos empresariais tendem a utilizar altas cargas de processamento: simulaes e cenrios esto entre estas aplicaes [Watson, 2003] e [Nieto-Santisteban et al, 2004]. Uma Grid Computacional deve ter o menor nmero possvel de pr-requisitos, visto que o objetivo integrar recursos heterogneos. Por agregar estes recursos, possvel melhorar a colaborao entre os diversos usurios e recursos disponveis.

21

2.2.4 Vantagens do Ambiente


Os sistemas acadmicos e profissionais esto cada vez mais complexos, tanto em funcionamento quanto na necessidade de gerenciamento. Manter uma estrutura de manuteno e atualizao de equipamentos no fcil e muito menos barato. Ao aproveitar os recursos em sua totalidade, espera-se que a necessidade de aquisio de grandes servidores seja menor. Atualmente em algumas Grids Computacionais, possvel atingir o poder de processamento de um supercomputador ao se utilizar centenas de computadores interligados [Chede, 2005]. Acrescente-se o fato de que a maior parte do parque instalado dos computadores de qualquer organizao, seja ela cientfica ou no, est subutilizada. Normalmente utiliza-se, em mdia, 20% da capacidade de processamento do parque instalado de computadores [Chede, 2005]. Durante o pico de utilizao, os servidores ultrapassam 70% da capacidade de processamento. Isso reflete uma realidade no mercado atual de servidores: compram-se servidores pelo pico de utilizao e no pela mdia. Ao utilizar completamente o potencial de todos os computadores da organizao, ser possvel adquirir recursos computacionais pela mdia e no mais pelo pico [Oliveira, 2004]. Os benefcios da utilizao de uma Grid Computacional estaro focados em aspectos de desempenho, qualidade e custo, visto que, ser utilizada a totalidade dos recursos de processamento da organizao. Alm disso, a disponibilidade dos recursos, a escalabilidade das aplicaes e o gerenciamento sero melhorados devido s caractersticas distribudas desta tecnologia.

2.3 Arquitetura
Devido ao ambiente heterogneo, necessrio que se estabeleam padres para permitir a interoperabilidade entre os recursos das organizaes virtuais. Mesmo as tecnologias que so utilizadas para computao distribuda, como Enterprise JavaBeans (EJB) e Common Object Request Broker Architecture (CORBA), no possuem mecanismos adequados para organizaes virtuais. Os Storage Service Providers (SSP) permitem o compartilhamento do armazenamento, mas os clientes esto interligados por Virtual Private Network (VPN). O que se quer com uma Grid o compartilhamento dos recursos ociosos de maneira descentralizada. Apesar de ser possvel realizar as mesmas atividades atravs dos mecanismos da computao distribuda, esta tem como principal caracterstica a centralizao, alm de possuir menor flexibilidade e controle de compartilhamento.

22

2.3.1 Organizao Virtual


Entende-se como um grupo de organizaes ou indivduos que compartilham recursos de forma controlada. Desta forma os membros da comunidade podem colaborar entre si para atingir o objetivo compartilhado [Foster, 2001]. Ao agir por interesses comuns, empresas e pessoas podem definir o que, como e quando compartilhar tais recursos. Isso quer dizer que teremos uma Grid apenas quando permitimos que outras pessoas ou empresas acessem nossos recursos (processamento, armazenamento, etc.) de maneira controlada e segura. As Organizaes Virtuais so formadas por interesses comuns. Pode-se considerar as empresas, centros de pesquisa e universidades como exemplos de Organizaes Virtuais [Dantas, 2005]. Desta forma, o compartilhamento dos recursos sero mais prximos s redes ponto-a-ponto (P2P) do que s do ambiente cliente-servidor. Um computador cliente pode servir a um computador central, trocando completamente sua funo na rede. Um computador cliente pode se utilizar de outro computador cliente para realizar o processamento que por sua vez pode solicitar dados que estejam no computador central [Foster, 2001]. Este o aspecto mais importante de colaborao em uma Organizao Virtual. necessrio que haja controle e informaes sobre os recursos para que a Grid tenha condies de encaminhar servios para serem executados. Mtricas de desempenho, prioridade, expectativas e limitaes de cada recurso, escalonamento e balanceamento de tarefas so extremamente importantes quando se trabalha com Organizaes Virtuais [Foster, 2001]. Fica claro que a utilizao dos recursos computacionais mais racional ao se utilizar o conceito de Organizao Virtual e Grid. H possibilidade de um uso mais adequado para a largura de banda, os processadores remotos, espao para armazenamento e memria [Dantas, 2005]. Em [Foster, 1999] h uma proposta de modelo de arquitetura para Grids (figura 2.1).

23

Aplicaes

Coletivo

Recursos

Conectividade

Ambiente

Figura 2.1: Arquitetura de Grid Computacional [Foster, 1999]

Os cinco nveis propostos so: Ambiente: responsvel pela operao local em cada um dos recursos. Implementa mecanismos de negociao, solicitao, gerenciamento e monitoramento do recurso. Monitora a qualidade do servio (QoS). Fazem parte deste nvel recursos computacionais (estado e programao de equipamentos e softwares), sistemas de armazenamento (espao disponvel e utilizao de banda), catlogos (busca e atualizao de dados), recursos de rede (caractersticas e carga) e sensores. H independncia entre as funes e as operaes de compartilhamento [Foster, 2001]. Conectividade: estabelece, atravs de protocolos, a comunicao (TCP/IP, UCP e DNS) e autenticao (inclusive criptografia) para transaes de rede. Como est entre as camadas ambiente e recursos, responsvel por construir os servios de comunicao atravs da implementao de mecanismos de segurana e controle de acesso (usurios e recursos). Algumas das caractersticas mais importantes da camada de conectividade so [Foster, 2001]: o Entrada nica (single sign-on): usurios devem se autenticar uma nica vez e ter acesso a todos recursos necessrios na Grid, como em uma organizao virtual. o Delegao: sistemas devem ser executados sob os direitos do usurio e deve haver possibilidade de delegar a outros programas os mesmos direitos.

24

o Integrao com segurana local: no deve sobrepor os direitos especficos do recurso utilizado. o Relacionamento garantido: caso um usurio necessite utilizar mais de um recurso para os quais os direitos tenham sido atribudos, isso deve ser feito sem que os recursos tenham que interagir entre eles para garantir este acesso. O controle da Grid e no dos recursos. Recursos: implementa protocolos de comunicao e autenticao que requisitam funes do nvel de ambiente para controlar os recursos locais. Estabelece o acesso aos recursos utilizando-se da camada de conectividade. Trabalha com cada recurso individualmente. Esta camada responsvel pela negociao, inicializao, monitoramento, controle, bilhetagem e pagamento pelos recursos utilizados. H duas classes nesta camada [Foster, 2001]: o Protocolos de Informao: obtm informaes da estrutura como configurao, carga atual e poltica de utilizao. o Protocolo de Gerenciamento: negocia o acesso ao recurso compartilhado, como requerimentos, criao ou acesso aos dados. Coletivo: responsvel pela troca de mensagens entre os recursos. Estabelece servios de diretrio (descoberta dos recursos disponveis na organizao virtual), alocao (programao dos recursos utilizados), diagnsticos (falhas, ataques e sobrecarga), replicao (armazenamento, disponibilidade, desempenho, tempo de resposta e custo), colaborao (troca de grande volume de dados entre organizaes virtuais) e autorizao (poltica da organizao virtual de acesso aos recursos). Utiliza-se de Application Programming Interfaces (API) e Software Development Kits (SDK) especficas para facilitar a programao no middleware [Foster, 2001]. Aplicao: so os sistemas executados pelos usurios e que utilizam a organizao virtual para realizar as operaes. As aplicaes podem requisitar servios de qualquer outra camada, atravs de protocolos ou APIs e SDKs. Isto especificado pelo framework utilizado [Foster, 2001].

2.4 Desenvolvimento de Sistemas em ambientes distribudos


Em [Dantas, 2005], h uma proposta para classificao de ambientes de software distribudos. Conforme salienta o autor, no uma taxonomia, mas permite entender a maneira como os sistemas distribudos so desenvolvidos. A classificao feita por: Ambiente de Programao, Ferramentas e Middleware.

25

2.4.1 Ambiente de Programao


natural que o desenvolvimento de um sistema que ser operado em um ambiente centralizado diferente de um que atue em ambiente distribudo. Os recursos, em um ambiente distribudo, nem sempre esto disposio do interessado. Alguns fatores afetam o desempenho das aplicaes distribudas: segurana e autenticao, largura de banda, rede de comunicao entre computadores clientes e servidores, diferentes configuraes de sistemas operacionais, compiladores das linguagens de programao, etc. Os servios Web (Web Services) so utilizados na Internet para compartilhar a lgica de negcios e so teis para desenvolver sistemas distribudos. Estes servios tm como caracterstica bsica a utilizao de protocolos que facilitam a execuo das aplicaes em redes, sistemas e equipamentos heterogneos. Dentre os principais padres, destacam-se o HyperText Transfer Protocol (HTTP) , a linguagem eXtensible Markup Language (XML) e o Web Service Description Language (WSDL). O XML uma linguagem de marcao de dados. Atravs da marcao possvel definir, transmitir, validar e interpretar os dados. Os principais protocolos utilizados so: Simple Object Access Protocol (SOAP) e Universal Description Discovery and Integration (UDDI). O SOAP um protocolo que tem como base o XML e utilizado para troca de mensagens pela Internet. As mensagens podem ser transmitidas via HTTP, SMTP e MIME. Ao utiliz-lo em sistemas distribudos, deve-se levar em considerao o fato deste no ser um protocolo orientado a estado (stateless) e no ter coleta de lixo [Dantas, 2005]. Isso pode gerar problemas para identificao da sesso. A mesma preocupao deve ser tomada com a segurana, visto que no h uma preocupao especfica do protocolo nesse aspecto. J o UDDI utilizado como um diretrio distribudo. Isso faz com que sejam possveis a localizao e descoberta dos servios atravs da Internet. Com um servidor UDDI possvel que uma empresa possua mltiplas verses dos servios disponveis e estabelea critrios de segurana [UDDI, 2005]. O XML utilizado para marcar os dados, o WSDL para descrio, o SOAP para transferncia e o UDDI para listar os servios. Os servios so importantes porque indicam os protocolos e implementam um comportamento. Servios padronizados para cada uma das necessidades da Grid permitem aos participantes de uma Organizao Virtual saber o que se pode realizar com o recurso oferecido.

26

Por fim, as APIs e SDKs so importantes para que os desenvolvedores possam abstrair as necessidades dos recursos, facilitando a criao de aplicaes disponveis para a Grid. Percebe-se que, desta forma, os servios trabalham em conjunto com os protocolos e no como uma alternativa criao destes [Foster, 2001]. Uma das alternativas utilizao de servios Web o Parallel Virtual Machine (PVM). Este ambiente um pacote que realiza a organizao de computadores com arquiteturas heterogneas ou no para programao paralela. divido em duas camadas: uma biblioteca para programao paralela e o ambiente computacional. O desenvolvedor atua na camada da biblioteca e o programa resolve a distribuio no ambiente. Possui um aspecto visual que facilita a identificao e acompanhamento dos servios executados. Podem ser utilizados nos sistemas operacionais Windows e Unix [Dantas, 2005]. Outra alternativa a utilizao do Message Passing Interface (MPI) que tem as mesmas caractersticas do PVM e tambm utilizada para criar aplicaes que sejam executadas em paralelo. O MPI suporta o modelo Single Program Multiple Data (SPMD) e tem pode ser utilizado em diferentes ambientes operacionais.

2.4.2 Ferramentas
De acordo com [Dantas, 2005], pode-se considerar ferramentas de software os pacotes que auxiliam a instalao distribuda dos programas, gerenciamento dos recursos, escalonamento, balanceamento, monitorao e acompanhamento dos processos. Pode ser facilmente confundida com o middleware, pois este composto por ferramentas de um escopo maior. As ferramentas so responsveis por gerenciar um ambiente composto por diversos sistemas operacionais que, por sua vez, no tm responsabilidade alm do gerenciamento de seus prprios recursos e processos. O tipo de aplicao que obtm melhores resultados nesse ambiente so as que possuem uma variao sistemtica de carga dos computadores e as que fazem muitas operaes de entrada e sada de dados [Dantas, 2005]. Essas ferramentas so conhecidas por Resource Management and Systems (RMS). Alguns exemplos: LSF (Platform Computing), Codine (Sun), Loadlever (IBM) e Condor (Universidade de Wisconsin).

2.4.3 Middleware
O middleware guarda alguma semelhana com as ferramentas, mas so mais completas. Com isso possvel realizar as tarefas em um ambiente amigvel e com maior controle e recursos. Este ambiente permite realizar mais facilmente as tarefas de submisso de

27

aplicaes, gerenciamento de recursos e servios distribudos, controle de acesso e permisso de instalao de pacotes [Dantas, 2005]. Dentro dessa categoria h sistemas de imagem nica. A funo bsica desses sistemas abstrair complemente a execuo (em que computador ou recurso) se executa a aplicao. Com isso possvel reduzir o tempo despendido no gerenciamento do sistema e aumentar o grau de confiana na execuo do servio. Alguns exemplos: OSCAR (Open Cluster Group), Glunix e Sprite (Universidade de Berkeley), OpenMosix (Universidade Hebrew), Unixware (SCO) e Solaris MC (Sun).

2.5 Middleware para Grid Computacional


Entende-se middleware como sendo um software que conecta duas ou mais aplicaes. um conceito diferente de importar e exportar dados, pois o middleware se conecta s aplicaes, lendo e enviando as informaes necessrias para o processamento. De acordo com Foster [Foster, 2001], um middleware para Grid seria a unio de protocolos, servios, APIs e SDKs. A Grid Computacional , portanto, um meio de comunicao, troca de informaes e compartilhamento de recursos entre aplicaes. fundamental a existncia de middleware para permitir a interoperabilidade entre as organizaes virtuais. As organizaes virtuais, para existir, precisam de mecanismos de descoberta, identidade, autorizao e compartilhamento [Foster, 2001]. H alguns middlewares disponveis. Pode-se notar que alguns trabalham em uma camada mais baixa de servios e outros complementam com servios especficos. Entre eles, destacam-se: Globus Toolkit, Storage Resource Broker, Gridbus, Alchemi e Legion. O Alchemi um framework que permite criar um ambiente de Grid com o mnimo de esforo (plug & play), segundo o prprio grupo define. uma ferramenta de open-souce (cdigo aberto) que permite a execuo de aplicaes na Grid. O GridBus um acrnimo de GRID e BUSiness. O objetivo criar tecnologias que integrem Grids com negcios. Espera-se disponibilizar um ambiente baseado em especificaes open-source adequado para aplicaes de eScience e eBusiness em uma viso de arquitetura orientada a servios (SOA) e computao colaborativa. Utiliza recursos disponibilizados pelo Globus Toolkit e do Alchemi para aprimorar servios especficos do escopo do projeto [GridBus, 2005].

28

O Globus um conjunto de ferramentas que realiza o trabalho de conectar e gerenciar recursos. o principal middleware utilizado e formado por um consrcio de vrias empresas de tecnologia interessadas em disseminar a utilizao das Grids Computacionais. Utiliza o GridFTP como mecanismo bsico de acesso e transferncia de dados e foi integrado a um banco de dados chamado Objectivity apenas para copiar objetos armazenados. integrado ao Grid Security Infrastructure (GSI) que prov os servios de segurana da Grid, entre eles o controle de acesso [Globus, 2005]. O Globus Resource Allocation Manager (GRAM) responsvel pela interface do middleware com os recursos locais e o Metacomputing Directory Services (MDS) realiza a localizao e informao dos recursos (servio de diretrio). O Storage Resource Broker (SRB) foi projetado para permitir que aplicaes pudessem acessar informaes distribudas. um middleware cliente-servidor que foi projetado para permitir que as aplicaes pudessem acessar informaes distribudas em recursos heterogneos. Possui um servidor de metadados que permite vincular o nome lgico com a localizao fsica dos arquivos e contm mecanismos de cobrana por uso e acesso alm de guardar informaes de usurios e recursos. Este middleware capaz de selecionar, criar e manter rplica dos dados, requisito importante quando se trabalha com distribuio de dados. Apesar de haver alguma tendncia a utiliz-lo em conjunto com bancos de dados para distribuio de informaes, h algumas limitaes que precisam ser vencidas, como a transferncia dos dados para o servidor. Esse processo tende a gerar perda no desempenho e diminuir a escalabilidade das aplicaes [SRB, 2005]. O Legion um projeto da Universidade da Virgnia que utilizou o paradigma da orientao a objeto para processamento paralelo e distribudo. Segundo o stio Legion [Legion, 2005], o sistema tem alta escalabilidade, facilidade de programao, tolerncia a falhas, segurana e autonomia. O sistema permite criar um computador virtual, com os recursos do computador recebendo o tratamento como se fosse objeto. A interpretao de um arquivo dada da mesma maneira, ou seja, como objetos de persistncia [Dantas, 2005]. Os demais middlewares tm utilizao e caractersticas especficas que no diferem muito do objetivo dos anteriores. A grande vantagem na utilizao de um middleware que, devido a padronizao, pode-se agregar diversos recursos Grid. Em Wang [Wang et al., 2005], identifica-se um equipamento que serve como um grande armazenador de dados integrado ao middleware Globus. Por ter integrao com o GSI e com o GridFTP, permite o acesso de clientes s informaes de maneira mais eficiente e segura.

29

2.5.1 Open Grid Services Architecture (OGSA) e Open Grid Services Infrastructure (OGSI)
A infra-estrutura (OGSI) trabalha em conjunto com a arquitetura (OGSA) da Grid para permitir a interao entre os aplicativos dos usurios e os servios Web (Web Services). Pode-se entender a OGSI como um conjunto de especificaes WSDL que define padres de interface e aes para a OGSA [Dantas, 2005]. Os servios podem ser persistentes (longa durao, com busca de aplicaes distribudas) ou transientes (curta durao, com criao e destruio dinmica). Os servios Web concentram-se no primeiro grupo e os servios de Grid em ambos. Um elemento fundamental nos servios de Grid o Service Data Element (SDE). O SDE responsvel pela consulta, adio e remoo das instncias de servio de Grid. OGSA um conjunto de definies, conceitos e tecnologia de servios para Web. O objetivo principal estabelecer uma padronizao no desenvolvimento de software para Grids. Este padro faz com que os servios (compartilhamento, acesso e gerncia de recursos) de uma Grid possam ter uma abordagem comum. Com isso facilitado o desenvolvimento de aplicaes. Outro ponto importante que, com esta arquitetura, possvel garantir uma alta disponibilidade, acesso seguro e distribudo alm de uma grande escalabilidade dos recursos [Dantas, 2005]. A figura 2.2 mostra o modelo OGSA.

30

Aplicativos do usurio

Servios OGSA: criao, registro, notificao e gerncia OGSA

OGSI

Web Services

Host

Protocolos

Figura 2.2: Modelo OGSA. Fonte: OGSA.

A opo pelos Web Services esto intimamente relacionados possibilidade de integrao e distribuio dos servios, mesmos quando os recursos so heterogneos. Os Web Services so independentes de linguagem de programao e sistema operacional e, no caso da OGSA, utilizado para criar um framework para sistemas distribudos baseados na Open Grid Services Infrastructure (OGSI) [OGSI, 2003]. A OGSA fornece a descrio do ambiente utilizando Web Services Description Language (WSDL) e uma coleo de interfaces padro dos servios. Este mecanismo permite um padro para criao, identificao, comportamento e descoberta de instncia de servios. A coordenao da distribuio dos servios fica sob responsabilidade desta arquitetura. Por sua vez o WSDL utiliza o XML para descrever os Web Services [Watson, 2002]. Tambm so utilizados: protocolo Simple Object Access Protocol (SOAP) e Web Services Inspections Language (WSInspection). A OGSI estende as definies de WSDL e XML para agregar conceitos de servios Web orientadas a estado (stateful), notificao assncrona para troca de estado, referncia a instncias de servios, colees de instncias de servios e estado dos servios de dados [OGSI, 2003].

31

Na OGSA, define-se um modelo que represente os recursos reais e lgicos da Grid. Esse modelo composto pelos elementos bsicos dos servios disponibilizados, como processadores, unidades de disco e memria. Os servios de Grid (Grid Services) so especificaes de interfaces e procedimentos [Dantas, 2005]. Todo Grid Service um Web Service, mas o inverso no verdadeiro [OGSI, 2003]. Para se ter uma viso ampla do framework, sero especificadas as principais funes disponveis e importantes para este trabalho. Os principais conceitos so [OGSI, 2003]: Grid Service Description: indica como o cliente pode interagir com as instncias de servios. Serve para descrever a interface de servio (portType) e para descoberta de servios (provavelmente atravs da semantic Web). Grid Service Instance: pode utilizar mais que uma descrio (GSD). Cada instncia retm informaes que indicam como interagir com o servio. Possui um ou mais Grid Service Handle e uma ou mais referncias (Grid Service References). Declarao do tempo de vida: cada instncia pode ter um tempo de vida diferente. H atributos XML especficos para indicar o tempo de vida esperado para os servios. As principais propriedades da infra-estrutura so [OGSI, 2003]: GridService Factory (GSF): responsvel por criar uma nova instncia do servio. Como definio da instncia, possvel atribuir parmetros no momento da criao. GridServiceHandle (GSH): o identificador nico do servio de Grid retornado na criao da instncia. apenas o nome, portanto no permite a localizao e comunicao do cliente com o servio. vlido para todo ciclo de vida da instncia do servio. GridServiceReference (GSR): estabelece a comunicao com os servios da Grid. Contm o protocolo e o endereo de rede que permite localizar o servio. Nota-se que esta propriedade funciona como um ponteiro que indica a localizao do servio. Como depende do protocolo, se utilizar RMI/IIOP, o GSR assumir o formato IOR. Se utilizar SOAP, assumir o respectivo documento WSDL. Pode se tornar invlido durante o ciclo de vida do servio. Por este motivo, um GSH pode se relacionar a diversos GSR. A resoluo que deve ocorrer entre GSH e GSR realizada pelo HandleResolver portType.

32

Um servio de Grid uma instncia enderevel que implementa uma ou mais interfaces portType de um WSDL [OGSI, 2003]. Todos os servios de Grid devem implementar esta interface. Esta portType semelhante a um base Object class de uma linguagem orientada a objetos: encapsula o procedimento padro do componente. O procedimento encapsulado est relacionado a busca e atualizao do conjunto de servio de dados. Portanto, realiza operaes bsicas de gerenciamento na instncia do servio da Grid [OGSI, 2003]. Esta interface responsvel por especificar quais conjuntos de servios, dados e elementos descrevem as propriedades e capacidades dos servios da Grid [Dantas, 2005]. Alguns exemplos de declaraes de servios de dados so: interface: estabelece relao com a instncia do servio; gridServiceHandle: indica zero ou mais GSH para a instncia; gridServiceReference: indica um ou mais GSR para a instncia. Um valor do servio de dados deve ser a representao WSDL do GSR; terminationTime: indica quando a instncia ir ser encerrada. Alguns exemplos de operaes nos portTypes dos servios de Grid so: findServiceData: realiza a busca na instncia e retorna a descrio do servio; setServiceData: modifica um SDE, desde que permitido, e a informao da respectiva descrio. Esta modificao afetar a instncia do servio; requestTerminationAfter: faz com que seja alterada a hora de encerramento do servio. Indica o tempo mais recente para encerramento do servio; requestTerminationBefore: tambm altera a hora de encerramento do servio, mas indica o tempo mais distante para que isso ocorra; destroy: encerra o servio. H ainda um servio para notificao (Notification portType) , cujo objetivo distribuir mensagens entre as instncias de servios da Grid. O Factory portType serve para que uma instncia do servio solicite a criao de um nova instncia. Ele inicia o processo de vinculao com o GSH. Por fim, h o ServiceGroup que mantm as informaes sobre o grupo de servios da Grid. Este grupo um dos elementos responsveis pela identificao da federalizao de servios ou simplesmente pela identificao dos servios existentes em um diretrio ou ndice. Trs portTypes implementam a interface: ServiceGroup, ServiceGroupEntry e ServiceGroupRegistration.

33

2.6 Desenvolvimento para uma Grid Computacional


Uma Grid Computacional uma grande Organizao Virtual (OV) porque rene todos os recursos espalhados pela rede como se fosse um nico. Isso faz com que seja possvel aumentar o desempenho das aplicaes e a capacidade de armazenamento. Sistemas que necessitam de um alto poder de processamento e armazenamento so os que mais se beneficiam do uso da Grid. Quanto mais o processamento puder ser paralelizado ou distribudo, melhor ser o desempenho da aplicao na Grid. A evoluo que tem ocorrido no desenvolvimento de sistemas, em especial nas aplicaes distribudas baseadas em servios, faz com que a utilizao das Grids Computacionais seja vivel. Com aplicaes baseadas em servios no necessrio depender de um nico tipo de recurso, como sistema operacional, rede ou armazenamento. Quando um servio no est disponvel, outro assume automaticamente seu lugar. O processamento no interrompido com a perda de um recurso. Outra grande vantagem na utilizao de servios est no fato de este ser uma entidade que prov compatibilidade atravs do uso de mensagens, com facilidade para descrever, localizar e utilizar outros servios [Watson et al, 2002]. Os servios baseados na Web tm interface definida em padres abertos, como XML. Isso faz com que diferentes tipos de sistemas possam ser integrados [Chede, 2005]. Neste momento, o desenvolvimento de aplicaes baseado em Web Services cada vez mais utilizado. Web Services definem uma tcnica para descrever o acesso aos componentes de sistemas (servios) com mtodos para descoberta e protocolos de acesso. Ao serem utilizados em uma Grid Computacional, as interfaces e modelos utilizados pelos Web Services necessitam suporte ao gerenciamento distribudo, incluindo servios temporrios e seus respectivos ciclos de vida e estgio. Tanto a Grid quanto os Web Services no interferem no modelo ou linguagem de programao e nem no sistema operacional utilizado [Gil, 2004]. O modelo de Grid Computacional uma tendncia quando se fala em ambiente distribudo e atender melhor s necessidades dos usurios. Contudo, h uma srie de etapas que se devem ultrapassar para que isso se torne realidade. Padres devem ser estabelecidos para que as aplicaes possam trocar informaes e os servidores tenham condies de compreender as requisies e enviar os resultados. As Grids evoluram rapidamente de uma infra-estrutura altamente dependente de configuraes especficas para um ambiente virtual nico e dinmico. A utilizao dos Web Services trouxe muitos ganhos para os desenvolvedores por adotar padres, mas, por outro

34

lado, tem gerado uma competio de como implementar a arquitetura e quais padres seguir [Baker et al., 2005].

2.7 Descrio de Servios em Grid Computacional


A caracterstica bsica do acesso e restries de acesso aos recursos est em definir quais so as condies que devem ser satisfeitas. A partir do acesso necessrio estabelecer um contrato de servio entre o fornecedor e o consumidor para garantir a ambos as condies de fornecimento e utilizao do recurso. Os protocolos so fundamentais nesse acordo para definir forma e comportamento esperados [Pernas e Dantas, 2004].

2.7.1 Ontologias
Define-se como o desenvolvimento de um vocabulrio que contm conceitos relativos ao domnio de aplicao. uma especificao formal (interpretvel por mquina) e explcita de uma conceituao (modelo abstrato de um fenmeno do mundo) compartilhada (captada por um grupo). Os componentes de uma ontologia so: classes (expressa qualquer coisa sobre a qual alguma coisa dita); relaes (interao entre a classe e o domnio); funes (um nico elemento se relaciona com os elementos anteriores) e axiomas (sentenas verdadeiras) [Pernas e Dantas, 2004]. Ao se utilizarem as ontologias possvel proporcionar um entendimento amplo sobre as caractersticas e propriedades de suas classes e relacionamentos.

2.7.3 Ontologias para descrio de recursos do Grid


Utilizam-se axiomas para determinar o conhecimento sobre o recurso e seu funcionamento. Alm disso, os recursos so descritos por: metadados (guardam informaes sobre os recursos computacionais) e vises semnticas (retorna informaes sobre o funcionamento no momento da pesquisa) [Pernas e Dantas, 2004]. Desta forma, natural que todos os recursos do Grid devem estar presentes nos metadados e as vises semnticas, sendo dinmicas, devem refletir a situao do recurso.

2.7.4 Arquitetura de Grids a partir de Ontologias


A ontologia proposta atua nos servios de diretrios do Grid. As consultas realizadas para localizao dos recursos so feitas com base no vocabulrio definido na ontologia. A ontologia se localiza em uma camada parte do Grid uma vez que as solicitaes atuam

35

inicialmente nos metadados que consultam as vises semnticas para retornar informaes sobre os recursos disponveis [Pernas e Dantas, 2004].

36

3 Banco de Dados em Grid Computacional


As principais aplicaes em uso na Grid so baseadas em arquivo de dados porque esta tem sido mais utilizada no meio acadmico e cientfico [Watson, 2003]. Neste meio praticamente no h utilizao de sistemas gerenciadores de banco de dados (SGBD). Por outro lado, as aplicaes comerciais utilizam os SGBD em larga escala devido facilidade de manipulao e controle, especialmente em dados transacionais, que a linguagem SQL (Structured Query Language) oferece. Um requisito bsico para que a Grid Computacional possa extrapolar o uso no meio acadmico e ser tambm utilizado por empresas comerciais a necessidade de se integrar aos principais sistemas gerenciadores de bancos de dados. At o momento, poucos trabalhos tm explorado essas formas de integrao [Watson, 2003], mas os que estudam a adoo de SGBD nas aplicaes em Grid, demonstram que h ganhos significativos mesmo em aplicaes estritamente cientficas [Santisteban et al., 2004]. A constatao que se faz dessa experincia que os SGBDs possuem melhores meios de filtro de dados, indexao e pode utilizar paralelismo nas buscas. Ao concentrar as atividades dos pesquisadores na cincia e ao se deixar que o SGBD cuide da complexidade de acesso e gerenciamento de dados, o ganho de produtividade significativamente aumentado. No meio acadmico uma Grid Computacional trabalha com um volume muito grande de dados. Fala-se que, em um futuro prximo, ser alcanado o patamar de petabytes de informao [Chede, 2005]. Ao se optar pela utilizao de SGBD ser possvel manter os dados com maior segurana, obter melhor desempenho e encapsular processos complexos necessrios para manipulao de arquivos de dados. Os SGBDs possuem recursos muito mais potentes do que os sistemas baseados em arquivos de dados. Alm do simples armazenamento de dados, os SGBDs garantem maior segurana e agilidade ao processo. Por este motivo necessrio criar condies de integrao Grid e esta integrao no deve diminuir os recursos utilizados pelas aplicaes comerciais. De outra forma, a adoo da Grid pela comunidade no acadmica estar prejudicada. Parece consenso entre os principais estudiosos do assunto que no se deve criar um novo banco de dados para ser utilizado na Grid Computacional [Watson, 2003]. Isso demandaria tempo e esforos que j foram feitos. O que se tem feito buscar criar algum mecanismo semelhante a um protocolo e que permitisse realizar os principais servios dos bancos de dados, tirando o mximo proveito dos servios da Grid Computacional. A este

37

mecanismo que, conforme analisado anteriormente, deve ser baseado em servios, d-se o nome de Banco de Dados Federalizado ou Banco de Dados Virtual (figura 3.1). Tanto no meio acadmico e cientfico como no ambiente empresarial, necessrio trabalhar com dados estruturados, semi-estruturados e no estruturados. Este Banco de Dados Virtual deve prever a utilizao desses tipos de dados. O mecanismo sugerido guarda alguma semelhana com os padres ODBC e JDBC, mas h interesse em no limitar ou nivelar por baixo os bancos de dados, como acontece com estas APIs (Application Program Interface). Como a arquitetura proposta baseada em servios, os produtos devero indicar o que se pode ou no realizar [Watson, 2003]. Imagina-se que, com a adoo crescente das Grids Computacionais por parte das empresas, haver interesse por parte das empresas fornecedoras de SGBDs de portar seus produtos para o Banco de Dados Virtual [Watson, 2003].

Infra-estrutura da Grid Computacional

Banco de Dados Virtual

Oracle

SQL Server

DB2

PostGreSQL

Figura 3.1 Nesta estrutura, o Banco de Dados Virtual se encarrega de armazenar e distribuir as informaes entre os bancos de dados que estiverem na Grid Computacional. As aplicaes devem se comunicar com o Banco de Dados Virtual e ele resolve as demais questes. A comunicao do banco de dados virtual pode se dar com dados estruturados, semi-estruturados ou no estruturados.

3.1 Data Grids


Utiliza-se este termo para indicar qualquer tipo de acesso seguro a dados armazenados em uma Grid. assim que os dados podem ser distribudos geograficamente e com

38

mecanismos de acesso e recuperao de maneira transparente. Cada n da Grid responsvel pela disponibilizao e controle de seus recursos. Podem utilizar diferentes tecnologias e meios de armazenamento [Chede, 2005]. O principal objetivo dos Data Grids permitir que haja acesso controlado aos dados distribudos. [Chede, 2005] cita as tentativas de realizar este controle atravs de sistemas de arquivos, como NFS (Network File System) e protocolos de transferncia, como FTP (File Transfer Protocol). Mesmo utilizando mais seguros como as VPNs (Virtual Private Network), este mecanismo esbarra em diversas limitaes que precisam ser transpostas para utilizao em Grid. Chede [Chede, 2005] cita a utilizao do AFS (Andrew File System) que se utiliza do Kerberos para criar um mecanismo que permite maior controle e distribuio de arquivos. Cita ainda o Avaki Data Grid que se prope a implementar uma camada de servios para acesso a dados distribudos. Todas estas tentativas, contudo, esbarram na utilizao de arquivos de dados. Isso pode resolver uma parte do problema, mas efetivamente no resolve o ponto central que a utilizao de banco de dados comerciais em ambiente de Grid.

3.2 SGBD comerciais


A plataforma bsica para disponibilizar um SGBD em uma Grid Computacional formada por [Oracle, 2005 e IBM, 2005]: Cluster: permite que mais de um gerenciador de banco de dados, do mesmo fornecedor, seja instalado em diferentes servidores. Estes bancos de dados devem ser compartilhados e administrados como se fossem um nico. Pode ou no haver mecanismos de replicao dos dados para garantir a disponibilidade da informao e a paralelizao das transaes para agilizar a recuperao de dados. Auto-gerenciamento e auto-ajuste: como no possvel determinar a carga de trabalho de cada computador clusterizado, o SGBD deve ser capaz de gerenciar e ajustar-se demanda de dados e processamento. Sabe-se que cada gerenciador possui caractersticas prprias que permitem melhorar o prprio desempenho. Normalmente este servio realizado por um profissional, no caso o Administrador de Banco de Dados (DBA). Como em uma Grid a demanda no contnua e nem previsvel, no se pode depender exclusivamente de um profissional para realizar esta tarefa. Deve-se criar um repositrio que armazene os dados histricos da utilizao do banco e, com base no volume de dados e utilizao, so feitas alteraes nos parmetros do SGBD para otimizar o desempenho (figura 3.2).

39

Armazenamento auto-gerenciado: um mecanismo que permite o acesso a dados que no estejam fisicamente no mesmo servidor onde est instalado o SGBD, ou, caso esteja, no dependa do sistema operacional para gerenci-lo. Com este mecanismo possvel distribuir os dados em diferentes servidores, sendo, contudo, gerenciado pelo prprio SGBD e no pelo sistema operacional. Isso faz com que a carga e armazenamento de dados possam estar distribudos atravs de diversos computadores. Este mecanismo permite que o prprio SGBD replique os dados que julgar necessrio para diminuir a interferncia de um profissional. Isso faz com que a segurana da informao seja aumentada, mais ou menos como acontece com RAID (figura 3.2). Federalizao: com o banco de dados federalizado permitido o acesso a qualquer dado distribudo pela Grid computacional, seja ele estruturado ou no. H possibilidade de acesso a diferentes bancos de dados e as consultas so otimizadas baseadas em custo (CBO). Esta estrutura garante a possibilidade de distribuir o armazenamento e processamento sem se importar onde, qual dialeto SQL, como est armazenado ou qual protocolo se deve utilizar. O funcionamento da estrutura do banco de dados federalizado : o cliente utiliza JDBC, ODBC ou Web Service para interagir com o banco de dados. Este, por sua vez, comunica-se com a fonte de dados (pode ser interna ou externa). Quando o dado for processado, o banco de dados federalizado retorna a informao a quem solicitou. H uma preocupao em armazenar metadados das fontes no relacionais. Com isso, novos acessos so otimizados com uso de heursticas especficas (figura 3.3).

40

Cluster

GRID

Auto-gerenciamento e auto-ajuste

Armazenamento auto-gerenciado

Figura 3.2 Arquitetura da Oracle: o banco de dados se encaixa em uma Grid Computacional atravs da clusterizao de servidores, do armazenamento auto-gerenciado e dos mecanismos de auto-gerenciamento e auto-ajuste. Para se comunicar com outras fontes de dados, utiliza o Oracle Streams.

Figura 3.3 Arquitetura da IBM: as aplicaes comunicam-se com o banco de dados federalizado utilizando interfaces JDBC, ODBC ou Web Services. O banco de dados federalizado se comunica com as demais fontes de dados [IBM, 2006].

41

3.3 SGBD Distribudos e Virtuais


A Grid um ambiente para processamento distribudo, conforme amplamente discutido anteriormente. A arquitetura de servios foi criada para atuar neste ambiente. Bancos de dados virtuais, contudo, no possuem tcnicas especficas para integrar a arquitetura de servios em um ambiente de Grid. Algumas consideraes [Watson, 2002]:

3.3.1 Banco de Dados e Distribuio


Em um banco de dados distribudo, as informaes esto dispersas em um determinado nmero de sites. O controle, contudo, centralizado em algum destes sites. Em um banco de dados federalizado (ou virtual), cada qual, apesar de estar igualmente disperso, possui autonomia total sobre suas operaes. As fontes de informaes so escondidas da complexidade da implementao. Um banco de dados distribudo ou federalizado pode ser visto como um servio que permite a solicitao de informaes armazenadas. Desenvolver servios para bancos de dados virtuais passa a ser importante para uso nas configuraes da Grid. O desenvolvimento de servios padronizados para acesso aos atuais bancos de dados trar um grande benefcio. A alocao de recursos no middleware poder se utilizar destes servios para avaliar a distribuio de buscas.

3.3.2 Servio de Busca Distribuda


Uma aplicao da Grid pode se conectar a diversos bancos de dados ao mesmo tempo. Cada busca poder extrair dados de um nico banco de dados. As solicitaes das aplicaes precisam ser subdivididas para realizar a busca em mais de um banco de dados. O que uma busca distribuda deve fazer permitir que buscas individuais possam ser realizadas em vrios bancos de dados. O sistema deve ser responsvel pela otimizao das buscas. Uma arquitetura para o desenvolvimento e aplicao do servio de busca distribudo ser til porque pode ser disponibilizado e acessado como qualquer servio de banco de dados e pode utilizar as facilidades de descoberta, integrao e busca de servios de banco de dados.

3.3.3 Replicao Seletiva


As Grids possuem mecanismos de replicao dos dados, da mesma forma como os bancos de dados tambm possuem. Regras podem ser impostas a vises materializadas das tabelas replicadas. Um servio de notificao pode ser utilizado para indicar que houve modificaes na viso e esta modificao pode ser propagada automaticamente. Os servios

42

de replicao de banco de dados podem ser indicados na interface do servio. O conhecimento acerca da replicao dos dados pode ser til para o servio de programao de recursos da Grid. Outros servios relacionados replicao podem ser criados para integrar diferentes fornecedores de bancos de dados. Desta forma, o servio de busca, entrega e armazenamento de dados poder ser otimizado.

3.4 Requisitos de um Banco de Dados em Grid


Os sistemas gerenciadores de banco de dados (SGBD) alcanaram um nvel de complexidade bastante alto. Isso faz com que a Grid Computacional tenha que fornecer mecanismos complexos para efetuar buscas e controlar transaes. Cada implementao de banco de dados possui uma estrutura prpria de gerenciamento e segurana que deve se integrar s aplicaes da Grid. Por outro lado, pelo conceito de Grid, no admissvel que se utilize uma nica implementao de banco de dados, como Oracle, SQL Server ou DB2. necessrio integrar diferentes produtos e faz-los trabalhar como se fossem um nico. Dessa forma, deve ser possvel utilizar em uma mesma Grid, alm dos servidores citados, servidores livres como PostGreSQL e MySQL. Por outro lado, necessrio que os SGBD no se limitem a um nico middleware. As principais necessidades de integrao entre uma Grid Computacional e um banco de dados so [Watson, 2003]: Segurana: a Grid possui uma estrutura prpria de identificao dos usurios, como o Grid Security Infrastructure. Este mecanismo une os usurios em uma Organizao Virtual, porm autenticada e com critrios rgidos de segurana. Os gerenciadores de bancos de dados devem integrar a segurana da Grid com seus mecanismos prprios e garantir que os usurios tenham acesso s informaes necessrias para suas aplicaes. Em um ambiente empresarial, a utilizao do banco de dados previsvel uma vez que os usurios dos sistemas so conhecidos (funcionrios da empresa, por exemplo) e h controle na utilizao e acesso aos dados. Em uma Grid ocorre exatamente o contrrio: no se sabe quem utilizar nem quando o recurso ser utilizado. Programao: cada banco de dados possui sua prpria linguagem de programao. Tem sido tentada a padronizao das linguagens de programao de banco de dados desde a verso SQL de 1999. Os principais produtos do mercado j possuem

43

linguagens prprias de programao e podero se adaptar ao padro, mas dificilmente iro aderir completamente a este [Oliveira, 2002]. Contudo, necessrio que haja uma forma nica de comunicao e isso inclui a programao dos bancos de dados. A Grid, como foi visto, utiliza prioritariamente servios baseados em Web (Web Services) para descoberta, execuo e encerramento. Os fornecedores de banco de dados devero indicar quais servios podero executar e em qual padro. Com isso as aplicaes podero requisitar tais servios nos bancos de dados. Monitoramento de Desempenho: deve haver uma forma nica de avaliar como e quando um servio entregue e em que prazo ser devolvido. Se isso no for possvel, a Grid Computacional no ter condies de avaliar e estimar o prazo de entrega do servio quele que solicitou o processamento. Atualmente no h um padro entre os SGBD que garantam a uniformidade dessa informao. Os bancos habilitados Grid devero possuir mecanismos de auto-ajuste e autocontrole que permitam dimensionar a carga de servio atual, prevista e o tempo esperado para execuo do servio que foi submetido. Programao de Uso: to importante quanto o monitoramento, a programao de uso para em ambiente de Grid necessrio. Nem sempre a necessidade de processamento se d imediatamente. Deve haver forma adequada de programar o uso futuro. Deve-se levar em considerao a utilizao mdia e prever a disponibilidade futura do recurso. Custo: potencialmente os servios disponibilizados em uma Grid sero cobrados no futuro. Com isso necessrio estabelecer uma forma nica para calcular o quanto de processamento e armazenamento est sendo utilizado. Escalabilidade: uma Grid Computacional demanda volumes de dados muito grandes, chegando a 1 Terabyte por hora em algumas aplicaes atuais. Devido a este alto volume, desejvel que o banco de dados possa paralelizar o processamento. Na rea de metadados, o SGBD indicaria Grid como localizar e permitir acesso aos dados. Os sistemas baseados em Grid so semelhantes aos de data warehouse na forma, mas potencialmente podem envolver muito mais usurios e com a requisio de um volume de dados muito maior. Disponibilizao de Metadados: atualmente localizar dados na Grid Computacional relativamente simples, visto que basta mapear logicamente onde os dados esto localizados fisicamente. Com diversos bancos de dados isso tende a ser mais complicado. Por este motivo, necessrio indicar em diversos metadados espalhados

44

pela Grid onde est a informao necessria para depois acessar a informao. Somese a esta complexidade o processamento de transaes entre os diversos bancos de dados e a necessidade de replicar dados, para resolver eventuais problemas de queda de servidores. Por outro lado, os atuais SGBD disponibilizam para as aplicaes tpicas de uma Grid Computacional diversas possibilidades que atualmente no existem. Entre elas pode-se destacar: o gerenciamento dos dados que deixam de ser responsabilidade da aplicao e passam para o gerenciador de banco de dados; o gerenciamento dos recursos do servidor, uma vez que a maior parte dos gerenciadores j tem mecanismos de integrao com o equipamento e sistema operacional; cpias de segurana dos dados armazenados, visto que possuem diversos mecanismos para agilizar e controlar este processo; replicao de dados controlada pelo mesmo servidor e, finalmente, o controle de concorrncia e transaes dos dados. Alm destes, possvel adaptar-se informaes que so utilizadas pelos SGBD e disponibiliz-las para os middlewares. Isso inclui o inventrio dos recursos, manuteno de regras especficas de controle e acesso aos dados com o objetivo de agilizar o processo de consulta e criao de um repositrio do projeto para facilitar a busca e intercmbio de informaes entre pesquisadores.

3.4.1 Desafios
Os grandes desafios de aplicaes robustas para atuar em uma Grid Computacional e que podem ser extrapolados para a utilizao de SGBD so classificados por [Gil, 2004]: Captura do conhecimento: identificao dos recursos disponveis: SGBDs, dados, relacionamentos entre os dados e entre os SGBDs e a capacidade de processamento e armazenamento de cada servidor. Utilidade: deve haver plano de conteno para falhas de equipamentos, sistemas operacionais e SGBD. Da mesma forma necessrio estabelecer uma poltica para utilizao dos recursos da Grid. Deve-se prever formas de diminuir o trabalho dos usurios das aplicaes, facilitando a programao (schedule) de utilizao dos recursos. Robustez: deve-se prever o maior nvel de utilizao dos servidores para cada servio requisitado. Os servidores devem, preferencialmente, estar disponveis 24 horas por dia e 7 dias por semana. Isso envolve sistema operacional, software de rede e SGBD.

45

Acesso: a quantidade de usurios em aplicaes tpicas da Grid Computacional muito grande. Estes usurios esto dispersos em Organizaes Virtuais. O controle de acesso e permisses fundamental para o sucesso de uma aplicao em Grid. Escala: quando se fala em Grid Computacional, as necessidades so muito grandes. Processamento, armazenamento e a quantidade de usurios so altssimos. Os dados, por segurana e velocidade, precisam estar dispersos e muitas vezes replicados para agilizar o processamento e a busca. Para atender estes requisitos, necessrio definir um sistema de fluxo de trabalho (workflow) adequado para determinar o uso dos recursos e o caminho a seguir em caso de falhas.

3.5 Servios de Acesso a Banco de Dados


Uma vez que set torna necessrio utilizar banco de dados em ambiente de Grid computacional, deve-se estabelecer claramente a forma que a integrao entre o middleware e os bancos de dados sero realizados. Segundo Watson [Watson, 2002], ao se utilizar servios para esta finalidade determina-se o que ser realizado e no como fazer. Assim, no importa onde ou por quem ser realizada a operao, mas sim o retorno da solicitao. Este o objetivo de criar os servios virtuais, que permitiro realizar buscas, atualizaes e coordenao de transaes entre diversos bancos de dados. Para o usurio, contudo, deve haver total transparncia de como este processo se desenvolve. Watson [Watson, 2002] prope um desenvolvimento em estgios de um conjunto de servios para bancos de dados em Grid. Desta forma pode-se adotar padres de integrao entre bancos de dados. Assim, quanto maior o nmero de pessoas envolvidas, melhor ser o resultado. Dentro do escopo da proposta, necessrio conceituar um servio de banco de dados. Entende-se servio como uma entidade de rede que prov condies para troca de mensagens. Padres de servios Web (Web Services) especificam facilidades para descrever, descobrir e utilizar servios. Um destes padres o Web Services Description Language (WSDL) que utiliza o XML para descrever tais servios. So utilizadas especificaes WSDL para tipos (definio do tipo de dado para descrever a informao trocada), mensagens (definio dos dados enviados e recebidos do servio) e tipo porta (operao suportada pelo servio. Para cada operao, inclui nome, entrada, sada e mensagens de falha). A definio do WSDL fornece informaes do que o servio poder realizar e informaes de onde e como as mensagens sero enviadas.

46

A utilizao do termo interface servir para se referir a um conjunto de tipos, mensagens e portas que descrevem uma caracterstica especfica do servio.

3.5.1 Servio de Banco de Dados


Entende-se um Servio de Banco de Dados como qualquer servio que suporte uma interface de banco de dados. Pode ser persistente ou implementada atravs de um gerenciador de banco de dados. Com visto, os servios no indicam como a informao ser armazenada e tambm no especificam o formato ou modelo de armazenamento (relacional, objeto, XML, etc.). As operaes bsicas da interface de servio do banco de dados so: IN: parmetro de entrada OUT: parmetro de sada OPTIN e OPTOUT: parmetros opcionais de entrada e sada As operaes devem ser atmicas, isto , ou so executadas completamente ou no realizam trabalho algum. Como as transaes geralmente so muito grandes, h necessidade de controle para interrupes e gerenciamento de falhas. A estrutura para busca, atualizao e carga de dados se d em trs fases: Preparao e validao: a operao verificada para garantir a consistncia e o modelo de dados do banco de dados. Aplicao: tempo em que as atualizaes ou busca so efetuadas e os resultados construdos. Entrega de Resultado: quando os resultados so disponibilizados para o requisitante. O primeiro passo normalmente leva o mesmo tempo que a soma dos outros dois. Em caso de erro, o parmetro de sada resultHandle indica de maneira assncrona quando houve problemas durante o processamento. Os parmetros para busca, atualizao, carga e modificao sempre vm acompanhados da notao padro, que pode se utilizar da linguagem SQL, e o comando no formato especificado. H um parmetro para indicar o tempo de expirao do comando. Quando no for especificado, este deve ter um contedo padro. Um ltimo parmetro refere-se ao controle de transaes. opcional, o que indica que, em caso de haver necessidade de controlar a transao entre diversas operaes, ele deve ser informado. Outro ponto importante a se considerar so os mecanismos de entrega [Watson, 2002]. O sistema de entrega deve existir para transporte de um grande volume de dados. Deve ser complementar a protocolos e servios existentes no middleware, como GridFTP. Uma

47

interface possvel para os sistemas de entrega deve conter trs operaes: origem dos dados, canal de comunicao e entrega. No canal de comunicao indicado: mecanismo de entrega, destino e opo para expirao do comando. Um sistema mais completo deve conter mecanismos de encriptao, mapeamento para o formato de conduo dos dados antes e depois da entrega e indicador de progresso do servio. O controle de transaes essencial para SGBD [Watson, 2002]. H outros mecanismos de controle de transaes atravs de padres de servios, como J2EE e OMG. A definio de uma interface bsica envolve o incio, gravao ou abandono das transaes. O retorno do identificador nico da transao dever ser utilizado pelos comandos de banco de dados, conforme visto anteriormente. Para controlar transaes que envolvam mais de um banco de dados, necessrio que mais um servio seja acrescentado e outro modificado. O servio modificado o do incio da transao, visto que h necessidade de indicar um tempo de expirao para que no haja alocao desnecessria do recurso. O novo servio ser uma preparao para gravao. Este servio til para utilizar o protocolo de gravao em duas fases (two-fase commit). Uma Grid computacional necessita de alguns outros controles que normalmente no so necessrios para os bancos de dados, mesmo quando trabalham de maneira distribuda. So eles: Colaborao multi-site com troca de mensagens assncronas. Embora haja em bancos de dados distribudos, pela caracterstica da Grid, pode haver necessidade especfica como parte da execuo concorrente da aplicao. As operaes da Grid so compostas por processos que podem ser de diversas regies de controle. Normalmente em banco de dados, os processos de transao so relativos a um nico recurso. H, contudo, SGBD que realizam o mesmo controle quando trabalham distribudos. As transaes de banco de dados normalmente so de grande volume e de pequena durao. Em operaes na Grid, as transaes podem ser de longa durao. Para descoberta de servio na Grid, necessrio estabelecer informaes bsicas que facilitem este processo: Descrio de contedo: deve conter as informaes relacionadas aos objetos que o banco de dados mantm. Deve indicar desde quais so as tabelas, ndices, relacionamentos e tipos de objetos armazenados, at as estatsticas destes objetos,

48

proprietrio das informaes e critrios de segurana de acesso. Desta forma ser possvel agilizar os processos de busca e transaes. Descrio da capacidade: devem indicar quais so os recursos disponveis para serem utilizados. Assim, a linguagem, transaes e conexes so exemplos deste tipo de informao.

3.5.2 Padronizao
Fica claro que h necessidade de estabelecer padres entre os bancos de dados para que estes possam ser utilizados em uma Grid Computacional. A padronizao passa pelo estabelecimento de protocolos de comunicao que contenham basicamente: acesso aos metadados dos SGBD para localizao de dados e execuo de comandos transacionais, controle de acesso aos dados, notificao de onde est e quanto tempo poder durar uma determinada transao, programao de recursos, estabelecimento de servios a serem oferecidos e definio de custo e segurana no apenas no acesso aos dados, mas tambm quanto poltica de backup e recuperao de dados. O escopo da proposta segue alguns parmetros aceitveis tanto do ponto de vista da Grid Computacional quanto dos SGBD [Watson, 2002]: Independncia de Grid: no deve estar vinculada a um middleware especfico. Atualmente as Grids evoluem rapidamente e vincular a uma nica implementao pode ser catico por utilizar um conjunto especfico de funcionalidades e ferramentas que no estejam disponveis para todas implementaes. No criar um novo Banco de Dados: estabelecer mecanismos de controle de transaes, buscas e outros servios que existem nos principais SGBD. Os bancos de dados mais completos, contudo, tero maior aderncia Grid e os demais vo precisar se adaptar s necessidades. Independncia de Banco de Dados: no se deve seguir uma implementao nica para modelo de dados, comandos transacionais e programao de banco de dados. Conforme visto, a idia bsica criar um banco de dados virtual que se integre aos SGBD atuais e que tenha servios para oferecer ao ambiente computacional. Com isso, os SGBD poderiam informar o nvel de integrao e como resolveriam determinadas questes. Este banco de dados virtual tomaria a deciso de utilizar ou no um ou outro SGBD. Os principais servios estariam relacionados com a distribuio dos dados, busca distribuda e replicao seletiva de dados [Watson, 2002].

49

A padronizao passa necessariamente pela integrao com os recursos disponveis nos middlewares, como GridFTP e GSI abordados anteriormente. Pode-se utilizar outros padres especficos de banco de dados, como a linguagem SQL e os padres de comunicao de objetos definidos pela ODMG (Object Database Management Group). Segundo [Watson, 2003], a utilizao de APIs semelhantes ao JDBC, mas orientada a servio podem oferecer uma maior integrao aos middlewares. As caractersticas dos servios de dados so: Metadata: o objetivo ter um nome lgico e fsico do banco de dados e uma definio dos servios que podem ser oferecidos Grid. Busca: padronizar uma forma de acesso aos dados que possa ser estendido para cada implementao de SGBD. Com isso cada fornecedor poder, baseado no padro, realizar internamente o servio de busca. Transao: as transaes podem ser executadas em diferentes implementaes de banco de dados. H necessidade de controlar as transaes que foram distribudas nos diversos SGBD. Atualmente os produtos comerciais j realizam este trabalho, mas necessrio compartilhar a informao no middleware para que se possa distribuir o processo. Essa distribuio passa necessariamente pela criao de rplicas dos dados armazenados. Transferncias de Lotes de Dados: as buscas podem ser paralelizadas para garantir maior velocidade e disponibilidade da informao. necessrio que se criem mecanismos para unir as informaes depois de processadas para que se d um resultado nico ao usurio. Notificao: deve ser possvel atravs de mecanismos automticos, como gatilhos, informar Grid sobre modificaes ocorridas na base de dados. Com isso, havendo registro do interesse nas informaes daquela base de dados por parte dos clientes, estes podero ser notificados da mudana. Escalonamento dos recursos: deve ser possvel requisitar recursos para processamento das informaes. Os recursos passam por computadores e banda de comunicao at o conjunto de dados que sero analisados. O gerenciamento desta programao e a alocao dos recursos devem ser realizados e planejados com eficcia atravs de um fluxo consistente de trabalho.

50

Custo: o SGBD deve ser capaz de medir o custo da informao coletada, seja para efeito de dimensionamento de tempo e desempenho ou at mesmo para uma eventual cobrana pelo recurso utilizado. Navegao: deve haver uma interface que facilite a utilizao e programao direta dos recursos.

3.6 OGSA, OGSA-DAIS e OGSA-DAI


A evoluo para uma arquitetura orientada a servio possvel devido infra-estrutura de rede disponvel e a criao de organizaes virtuais torna-se possvel atravs do modelo de distribuio de servios [Alpdemir, 2003]. A abordagem baseada em servios para acesso aos dados no possui um alto nvel de acoplamento e possui pouca granularidade. J a tecnologia de processamento de buscas possui um alto nvel de coeso. Isso acaba por gerar um impacto em aplicaes distribudas. Por este motivo necessrio estabelecer mecanismos de controle que possibilitem a realizao do servio de acesso aos dados de maneira satisfatria. O Open Grid Services Architecture (OGSA) um conjunto de definies de servios web. O OGSA fornece: descrio da capacidade da grid utilizando WSDL, coleo de interfaces padro dos servios da grid. Este documento faz uma proposta para uma coleo de servios de bancos de dados no contexto da OGSA [Watson, 2002]. Um servio de dados (Grid Data Service) da OGSA (Open Grid Services Architecture) um servio da Grid que implementa um ou mais interfaces para acesso ou gerenciamento de recursos distribudos. Os servios de dados so construdos sobre a OGSI (Open Grid Services Infrastructure) que estende os Web Services para incorporar mecanismos de gerenciamento e controle da Grid [Foster, 2003] e [Alpdemir, 2003]. Para estabelecer um limite claro entre o que e o que no um servio de dados foram definidas quatro interfaces bsicas de dados para se implementar em diferentes comportamentos. Estas interfaces representam portas especficas do WSDL. Qualquer servio que implemente uma destas interfaces considerado um Web service compatvel com a OGSI. As quatro interfaces so [Foster, 2003]: DataDescription: define um elemento do servio de dados da OGSI que so fundamentais para virtualizao de dados encapsuladas por um servio de dados. DataAccess: prov operaes de acesso e modificao de contedo dos dados virtualizados encapsulados por um servio de dados. DataFactory: prov operaes para criar um novo servio de dados em uma nova virtualizao de dados herdada de outra virtualizao do servio de dados.

51

DataManegement: operaes para monitorar e gerenciar os servios de dados da virtualizao de dados, incluindo os recursos necessrios para execuo do servio. O grupo DAIS (Data Access and Integration Services) trabalha atualmente na

definio dos servios de bancos de dados. Para isso foram utilizadas as quatro interfaces de dados citadas anteriormente e que devem ser implementadas para atender aos comportamentos dos bancos de dados. Segundo [Alpdemir, 2003], o principal objetivo do OGSA-DAI (Data Access and Integration) criar uma infra-estrutura para entrega de servios de alta qualidade e que agreguem valor ao gerenciamento de dados da Grid, especificamente nos Grid Database Services (GDS). Os componentes servem tanto para acesso quanto para integrao dos dados. Desta forma, os Grid Services (GS) so estendidos nos seguintes servios e portas: Grid Data Service Registry (GDSR): serve para publicao dos GDS. Os servios so registrados e so utilizados para descrever um servio que um subconjunto de um SDE. Deve ser capaz de indicar s instncias dos servios registrados eventuais mudanas ocorridas em seu domnio. Grid Data Service Factory (GDSF): cria instncias GDS para finalidades especficas. Grid Data Service (GDS): aceita uma solicitao que instrui a instncia GDS a interagir com o banco de dados para criar, recuperar, atualizar ou excluir dados. Grid Data Transport (GDT): realiza o transporte de dados entre instncias do GDS.

3.6.1 Virtualizao dos Dados


Um ponto importante nessa abordagem a necessidade de virtualizao dos dados. Um sistema distribudo pode conter dados armazenados em fontes de dados diferentes e dispersas, com sintaxes prprias de acesso, gerenciados por diversos mecanismos e disponibilizados atravs de vrios protocolos e interfaces. Mesmo com as particularidades de cada fonte de dados, possvel, atravs da virtualizao, criar interfaces orientadas a servio para permitir o acesso dos clientes. Portanto, a virtualizao dos dados um termo aplicado para designar uma interface orientada a servio que permite o acesso a uma ou mais fontes de dados [Foster, 2003]. Pode ser simples, quando disponibiliza uma interface do sistema de armazenamento ou complexa, quando transforma de uma para outra forma de armazenamento. Pode ainda ser um conjunto de dados de uma nica fonte de dados ou de vrias fontes federalizadas. Cada servio de dados possui um nome especfico que permite a descoberta de seus respectivos atributos. Com isso possvel utilizar mecanismos prprios da Grid

52

Computacional para descobrir tais servios. possvel utilizar mecanismos prprios da OGSI para determinar o tempo de vida do servio. Em alguns casos o servio pode ser criado e destrudo, mesmo que o recurso continue existindo fisicamente. Em outros casos possvel que a prpria existncia dos dados dependa do servio executado, tendo um incio, meio e fim definido pela Grid Computacional. Com isso as sesses de cada cliente so gerenciadas pela Grid e podem ser requisitadas ao mesmo tempo por diversos clientes de diferentes formas. Pode se realizar o processamento seqencial de cada solicitao, prevendo mecanismos de controle de concorrncia na prpria interface. Um recurso de dados virtualizado por um servio de dados que encapsulado por uma implementao da interface e no nem visvel nem acessvel por outros usurios do servio. Naturalmente a fonte de dados pode ser acessada por outros mecanismos externos OGSA, mas, nesse caso, no fazem parte da Grid. O gerenciador do recurso (por exemplo, o banco de dados) realiza a comunicao com os servios de dados e possui caractersticas prprias que independem do modelo de servios da Grid [Foster, 2003].

3.6.2 Representao
Qualquer servio de dados tem um nome global nico e um Service Data Elements (SDE) que permite a descoberta dos atributos do servio. Um SDE descreve os principais parmetros da virtualizao e as operaes realizadas pelos servios da Grid. Estas operaes permitem que os clientes verifiquem o acesso aos dados, utilizem operaes adequadas, derivem novos dados dos antigos e gerenciem a virtualizao dos dados. Um determinado servio de dado poder implementar diversas interfaces da OGSI, mas dever, conforme visto, utilizar pelo menos uma das quatro interfaces bsicas. Foi estabelecido um framework para o servio de dados definidos na OGSA que determina [Foster, 2003] e [Alpdemir, 2003]: Estado do servio de dados: utiliza a SDE para permitir pesquisa e descoberta via mecanismos padronizados. Pode ser utilizado para descrever os metadados a respeito da virtualizao de dados (Grid Service Registry GSR). Nomes Globais: cada servio de dados tem um nome nico durante todo seu tempo de vida. Normalmente o nome global utilizado para se obter as informaes necessrias execuo das atividades da organizao virtual e para se comunicar com os servios de dados (Grid Service Handle GSH).

53

Gerenciamento de ciclo de vida: h diversos tipos de servios e diversas formas de persistncia de objetos. Em alguns servios, os dados sero criados fora do middleware mas se utilizaro deste para mapear recursos persistentes. Outros podero criados dinamicamente para um aplicativo especfico e tero ciclo de vida finito (criado, utilizado e destrudo) e gerenciado atravs da OGSI. Nota-se que o ciclo de vida depender da definio do servio e de sua implementao. Sesses como servios temporrios: servios de dados exploram os servios temporrios da Grid para gerenciar sesses de clientes. Um servio de dados pode ser acessado por diversos clientes e deve lidar com solicitaes concorrentes em diversas de formas. Isso inclui a serializao das solicitaes e o controle de concorrncia das transaes. Notificao: grid services distribudos podem notificar um ao outro de maneira assncrona sempre que houver uma mudana significativa no prprio estado.

3.6.3 Implementao
O mapeamento da virtualizao de dados para o recurso determinado pela implementao do servio. Um recurso ir virtualizar seus dados atravs de um servio encapsulado e no ser visvel nem acessvel para outros usurios a no ser pelas operaes descritas no servio. Naturalmente os dados podero ser acessados por mecanismos externos OGSA, como arquivos de Entrada e Sada ou JDBC. Porm o acesso externo est fora do escopo do middleware e no ter controle ou gerenciamento pela Grid. O gerenciador do recurso mediar o acesso aos dados encapsulados pelo servio para prover a virtualizao da instncia de dado na infra-estrutura da Grid. O gerenciador de dados no faz parte da arquitetura do modelo, mas pode ser til para descrever os servios de dados e como eles se relacionaro com os dados, conforme abordado anteriormente. Tambm poder auxiliar na descrio dos servios, dos dados disponveis (metadados) e nas demais informaes teis para execuo dos aplicativos dos usurios.

3.6.4 Servios e Interfaces de Dados


Um servio de dados implementa uma ou mais interfaces associada a um comportamento para manipulao dos dados virtualizados. Cada interface de dados estende uma interface WS-Agreement que, por sua vez, estende um servio da OGSI. Cada interface de dado pode ser especializada por um tipo particular da virtualizao de dados. Um servio

54

de dados pode implementar vrias combinaes destas interfaces. As interfaces especificadas so [Foster, 2003]:

3.6.5 DataDescription
So utilizadas para informar clientes sobre os detalhes dos servios da virtualizao de dados. Desta forma, os clientes podem realizar requisies para as interfaces de DataAccess, DataFactory e DataManagement suportadas pelo servio. Esta interface vai definir SDEs comuns entre as virtualizaes de dados. As descries da interface podem ser genricas (tabela, coluna, tipo de dado, etc.) ou especficas do domnio (modelo climtico, anlise financeira, etc.).

3.6.5.1 DataAccess
Esta interface prov operaes para acesso e modificao do contedo do servio de dados virtualizado. Um conjunto de dados so dados armazenados em algum computador e disponveis atravs de algum mecanismo ou padro, como XML. Esta terminologia (conjunto de dados) refere-se a uma sintaxe e no ao servio. Estes conjuntos aparecem como parmetros de entrada ou sada para a interface DataAccess. Alguns exemplos desta especificao: SQLAccess: buscas e atualizaes SQL realizadas em virtualizaes de dados relacionais. Esta interface pode ser stateless que indica que as buscas devem retornar um conjunto de dados completo e as atualizaes sero realizadas com o conjunto de dados fornecido. Para criar um conjunto de resultados incrementais, pode-se utilizar uma interface baseada em cursor (stateful). A interface SQLFactory poderia ser utilizada para criar um novo servio de dados que contm o resultado virtualizado e que implemente interfaces RowSetDescription e CursorRowSetAccess. A seguir so listados exemplos desta interface. Acredita-se que futuramente outros sero necessrios e complementaro esta lista. CursorRowSetAccess: acesso de um cursor para uma linha do dado virtualizado. uma interface stateful o que significa que uma operao pode afetar o comportamento de operaes futuras. Com isso uma operao que recupere N linhas atualizar o cursor no conjunto de linhas e, logo, as operaes seguintes no tero o mesmo resultado. XMLCollectionAccess: acesso a uma coleo de dados XML virtualizados atravs do XPath, XQuery e XUpdate. Esta uma interface stateless que pode ser combinada com

55

a interface XMLCollectionFactory para criar um servio de dados stateful para recuperao incremental de dados. StreamAccess: operaes de leitura e gravaes incrementais em uma virtualizao de dados. uma interface stateful que ser criada em um servio criado pela interface DataFactory. FileAccess: uma extenso do StreamAccess que permite ler e gravar em dados virtualizados no formato Posix e no formato texto. uma interface stateful que ser criada em um servio criado pela interface DataFactory. BlockAccess: operaes de leitura e escrita em blocos de dados (posio e tamanho) em uma virtualizao de dados. uma interface stateless. TransferSourceAccess, TransferSinkAccess: pontos finais para multi-protocolos e transferncias entre dois servios de dados. uma interface stateful para configurar e gerenciar a criao de um conjunto de dados que seja visto como uma virtualizao de dados.

3.6.5.2 DataFactory
Esta interface suporta a requisio para criar um novo servio de dados de onde a virtualizao de dados derivada. O servio que implementa a DataFactory responsvel pela derivao da virtualizao dos dados do servio original. A solicitao para a DataFactory resulta na criao do servio de dado e retorna o Grid Service Handle (GSH). Este GSH pode ser utilizada pelos solicitantes para direcionar buscas a qualquer interface implementada pelo servio. Cada instncia tem seu prprio ciclo de vida, servio de dados e estado. importante frisar que esta interface no contm os dados fsicos. Utilizao: deve ser utilizado para criar um nome para a virtualizao de dados (cada dado virtualizado tem um nome nico definido atravs da GSH, mas no possui o dado em si), criar uma sesso para um cliente (algumas formas de acesso necessitam de sesses stateful e no so criadas por convenincia, mas para agilizar as operaes) e para criar uma virtualizao de dados vazia (necessria quando se quer adicionar elementos gerados pelo processo). Utilizao do AgreementProvider: a interface DataFactory define termos do acordo que so importantes para todos os servios de dados. Cada extenso define termos adicionais que so importantes para um servio especfico que criado atravs de uma extenso do DataFactory.

56

Extenso: os exemplos de extenso para o DataFactory so os mesmos apresentados no DataAccess. So eles: FileSelectionFactory (criao de outro servio de sistema de arquivo para um subconjunto de arquivos no servio principal); SQLFactory (novo servio de dados virtualizado que um subconjunto de uma viso do banco de dados); XMLCollectionFactory (semelhante ao SQLFactory, mas para uso com XML); TransferFactory (utilizado para transferncia de dados com a interface TransferSourceAccess e TransferSinkAccess) e CollectionSelectionFactory (cria um novo servio de dados com os dados virtualizados de um dos recursos). Outros devero ser definidos futuramente. Federalizao: cria um virtualizao de dados relacionais que integra os dados de diversos servios de dados relacionais. Um DataFactory deve ser utilizado para criar o novo servio federalizado com uma virtualizao relacional vazia. A seguir, uma combinao de operaes de DataAccess e DataManagement ser utilizada para acrescentar dados na nova fonte virtualizada. O DataAccess criar cpias dos dados no servio federalizado ao passo que o DataManagement realizar o mapeamento de cada pedao da virtualizao. As operaes de DataAcess utilizaro este mapeamento para realizar as operaes necessrias. Por definio, uma Organizao Virtual deve conter um servio de dados especfico que represente todos os outros servios de dados utilizados por ela.

3.6.5.3 DataManegement
O principal objetivo desta interface permitir aos clientes especificar como os dados virtualizados em diversas fontes so construdos. Deve prover operaes de configurao e poltica de controle para acesso base e os acordos que os solicitantes devem negociar com os servios de dados. Esta interface deve definir SDEs relacionadas s virtualizaes de dados, recursos e gerenciadores de recursos. Desta forma, os clientes podem monitorar o estgio do servio e o desempenho entre outras mtricas.

3.7 Utilizao do WS-Agreement


Este acordo crtico para o funcionamento dos servios. Todos os acessos aos dados so regidos pelos acordos. O WS-Agreement composto por 3 componentes [Foster, 2003]: Linguagem do acordo que prov um framework para expressar termos do acordo entre consumidor e provedor do servio.

57

AgreementProvider Interface: estende a linguagem para instanciar o acordo com o provedor do servio. Agreement Interface: estende o servio da OGSI para prover operaes de monitoramento e renegociao dos termos do acordo. A interface DataFactory estende a interface AgreementProvider enquanto as interfaces

DataDescription, DataAccess e DataManagement estendem a interface Agreement. Os termos podem ser gerais ou especficos para estender a interface DataFactory e pode enderear, por exemplo, como as novas virtualizaes de dados devem ser derivadas das fontes principais, definir desempenho e caractersticas de qualidade do novo servio, como os acordos sero monitorados para garantir os termos acordados e as informaes para bilhetagem.

3.8 OGSA-DQP
Para demonstrar a possibilidade de implementao dos servios de dados, foi criado o servio de processamento distribudo de buscas (Distributed Query Processing DQP). O objetivo do DQP prover uma maneira de implementar linguagens declarativas e de alto nvel para acesso e anlise de dados alm de permitir a facilidade de gerenciamento de recursos que uma Grid computacional possui [Smith, 2003]. Em uma situao onde h mais de um banco de dados em ambiente distribudo interessante possuir um mecanismo de gerenciamento de alto nvel. O DQP pode ser utilizado em vrios contextos: sistemas de banco de dados distribudos, banco de dados federalizados e em middlewares para processo de busca. A arquitetura proposta consiste em cumprir duas principais funes: compilar e executar a busca. Uma Grid possui mecanismos que facilitam este processo [Smith, 2003]: Dicionrio de dados que descreve o armazenamento remoto dos dados e verifica os recursos disponveis; Scheduler que permite distribuir a execuo nos recursos disponveis; Identificao dos usurios; Padronizao atravs de protocolos. O DQP utiliza duas fontes de informao para alocar os recursos: o otimizador de busca estima o custo de execuo de cada parte da busca (o que permite identificar eventuais gargalos de processamento) e o middleware que informa quais recursos esto disponveis. Para o planejamento da busca utilizado o OQL (Object Query Language) por ser um bom modelo para representar dados intermedirios e para dividir o trabalho entre os recursos.

58

Na primeira fase um n produz um plano de busca como se a execuo fosse realizada em um nico processador. Na segunda fase, o plano dividido em subplanos que so alocados em recursos computacionais pelo scheduler. O responsvel pela execuo do plano o sistema Polar*. Segundo [Smith, 2003], o Polar um servidor de banco de dados paralelo e nele que a lgica de distribuio da busca realizada. Em [Smith, 2003], h sugestes para que se estabeleam mtricas mais adequadas para distribuio do servio alm das existentes, como velocidade de CPU, dimensionamento de memria esttica e disponvel (dinmica). Alm disso, h indcios de que se pode melhorar a lgebra dos operadores fsicos, aumentar as informaes do sistema utilizadas pelo planejador do sistema, explorar algoritmos mais poderosos de programao de recursos e realizar testes de desempenho em mais bancos de dados e com maior volume de dados armazenados. Baseado no DQP foi construdo o OGSA-DQP, que um framework de servio de Grid para integrao e anlise de dados. Segundo [Alpdemir, 2003-2], o OGSA-DQP um sistema de fluxo de dados distribudos de alto desempenho que utiliza a abstrao de orientao a servios dos recursos de uma Grid e assume que os dados podem ser acessados atravs de interfaces. Utiliza dois servios para atingir o objetivo: Grid Distributed Query Service (GDQS) e o Grid Query Evaluation Service (GQES). O GDQS prov a interface de comunicao com o usurio e o GQES avalia a busca submetida ao GDQS. A quantidade de instncias GQES utilizadas depender basicamente das decises tomadas pelo otimizador de busca. O processo de criao da sesso de busca inicia pela busca e descoberta de recursos, mas no est disponvel na verso atual do sistema. Utiliza-se um arquivo XML com a lista dos recursos disponveis para uso que inclui o nome do schema de cada banco de dados. O GDQS obtm os metadados relacionados a cada recurso da lista. Para cada instncia GDQS so realizadas a compilao, otimizao, particionamento e programao de uso da busca. Cada partio atribuda a um n de execuo. A partir desta atribuio sero criados tantos GQES quanto necessrios. A coordenao do processo fica por conta do GDQS. O GDQS semelhante raiz, o GDS so as folhas e o GQES so o meio [Alpdemir, 2003-2]. Pode-se notar que o OGSA-DQP uma extenso do DQP, pois utiliza o otimizador baseado no Polar*. Com isso houve um significativo avano em direo utilizao de buscas distribudas em um ambiente de Grid computacional, mas o servio de busca, alocao e programao de utilizao dos recursos esto fora do middleware. A Grid Computacional ainda no est completamente adaptada para receber os SGBDs e estes, por sua vez, no esto suficientemente padronizados para trabalhar na Grid. A

59

Grid foi criada para ser um ambiente distribudo. Os SGBD foram criados para atender aos usurios de uma organizao. Para resolver esse descompasso, necessrio estabelecer (e seguir) padres que possibilitem a integrao entre ambos. As recentes pesquisas apontam para a criao de um banco de dados virtual, onde os servios de banco de dados possam ser disponibilizados atravs da Grid. Esses servios devem seguir padres internacionalmente aceitos, em especial os Web Services e baseados nos conceitos da OGSA. Dessa forma fica garantida a possibilidade de computao distribuda e possvel garantir a entrega do servio atravs da Grid, com mecanismos de versionamento e expirao. S isso, porm, no capaz de resolver todas as questes. Os dados estaro disponveis em servidores que por sua vez podem se utilizar de outros dispositivos para armazen-los. Saber onde esses dados esto, distribuir e encerrar o servio parte do problema. Da mesma forma como em outras reas j se pensa em definir um gerenciador que coordene e fiscalize a execuo dos servios, ser necessrio faz-lo com os SGBDs.

60

4 Planejamento em Grid Computacional


Uma das reas que mais demandam esforos da comunidade acadmica de pesquisa a de Planejamento em Grid Computacional. Como h uma disperso de recursos pela rede necessrio planejar a utilizao eficaz para garantir a otimizao das tarefas. Coordenar as responsabilidades dos recursos, localiz-los, program-los e recuperar as respostas so exemplos de atividades comuns em um ambiente de Grid Computacional. Para resolver problemas de planejamento utilizam-se tcnicas de Inteligncia Artificial. De acordo com [Freuder et al., 2005], o problema de planejamento compreende uma descrio do estado inicial, uma descrio parcial dos objetivos e um conjunto de aes que mapeiam a transformao dos elementos de um estado para outro. O problema pode ser aprimorado com questes relacionadas a aspectos temporais, incertezas ou otimizao de algumas propriedades. Como soluo tem-se uma seqncia de aes que levam do estado inicial at o objetivo. Esta soluo conhecida por plano. A busca por uma soluo pode ser obtida pela idealizao de um objetivo como, por exemplo, a minimizao das aes tomadas. No h, em problemas clssicos de planejamento, necessidade de minimizao ou maximizao de funes lineares e normal se utilizar o procedimento de branch-and-bound para localizar a soluo, mesmo em caso de restries. Apesar de haver estudos que indicam a necessidade de se criar uma infraestrutura para o fluxo de trabalho para Grid [Cybok, 2004], no se tem visto a aplicao de solues especficas.

4.1 Inteligncia Artificial e Banco de Dados em Grid


O uso da Inteligncia Artificial muito importante para a integrao de um SGBD com a Grid. Atualmente a Grid capaz de localizar componentes para atingir os objetivos desejados. possvel localizar dados de entrada, rplicas e combinar requerimentos dos componentes com os recursos disponveis. necessrio, porm, estender essas funcionalidades com representaes que capturem o conhecimento atual do ambiente e disponibilize esta informao para que planejadores possam coordenar as aes atravs da Grid.

61

4.1.1 Sistema Multi-agente ou Grid de agentes


Conforme visto, as caractersticas que identificam a tecnologia de Grid so: habilidade de coordenar recursos atravs de controle no centralizado, utilizao de padres abertos para protocolos e interface e entrega com alta qualidade de servio [Foster, 2002]. As diferenas entre sistemas multi-agentes e a Grid de agentes que este ltimo disponibiliza servios de diretrio, balanceamento de carga e distribuio de servio (com todas regras para inferir na distribuio de servio e negociao com outros agentes), endereamento e protocolo de comunicao, roteamento de mensagens, segurana e visualizao [Assuno et al, 2004]. Uma Grid de agentes possui quatro camadas: a primeira so os recursos, a segunda os agentes que realizam a interface com os recursos, a terceira so os servios oferecidos e na quarta esto os agentes que utilizam os recursos da primeira camada. A ao das aplicaes do cliente se realiza na quarta camada [Assuno et al, 2004]. Esta estrutura est coerente com a adoo da OGSA e com a integrao atravs de Web Services.

4.1.2 Escalonamento
Segundo [Dantas, 2005], escalonamento a atribuio de tarefas aos recursos computacionais para minimizar o tempo de execuo das aplicaes. Seguindo a abordagem proposta por [Casavant e Kuhl, 1988], os mtodos de escalonamento so divididos em local e global. Neste caso de estudo, contudo, interessa o escalonamento global porque se podem aplicar seus mtodos em sistemas distribudos. O escalonamento global divide-se em: Esttico: a atribuio dos processos realizada no incio do planejamento e no possvel alter-lo durante a execuo do mesmo. Apesar de ser possvel realizar buscas em todo espao de soluo, tanto em amplitude como em profundidade, o mais comum utilizar heursticas para encontrar uma soluo quase tima. Dinmico: os processos so alocados e acompanhados, o que permite que se faam modificaes durante a execuo dos mesmos. possvel realizar o balanceamento de cargas entre os processadores. As decises quanto ao balanceamento podem ser tomadas de forma centralizada ou distribudas. O escalonamento pode ser cooperativo ou no. A forma cooperativa se d quando as decises a respeito do balanceamento se derem de forma no independente. Essa abordagem cooperativa observada quando todos os elementos interagem com objetivo de atingir uma meta global para o sistema.

62

4.1.3 Alternativas de Planejamento


Tcnicas de restrio tem sido amplamente pesquisadas para solucionar problemas de planejamento de Inteligncia Artificial [Freuder et al., 2005]. Ainda segundo [Freuder et al, 2005], as unidades fundamentais dos frameworks baseados em restries so as variveis e as restries (entidade que restringe o valor das variveis). Em geral no se deve misturar a especificao do problema com o controle de busca. Isso porque as condies de busca que influenciam o planejamento podem mudar de um momento para outro e, por isso, nem sempre podem ser definidas antecipadamente. Os principais frameworks so [Freuder et al., 2005]: SAT (Satisfiability): utiliza frmulas proposicionais e restrio de variveis booleanas. Desta forma, utiliza-se duas variveis relacionadas com operadores not, or e and. Para situaes que envolvam tempo no adequado, pois, por utilizar variveis booleanas, mostra apenas diferenas qualitativas. IP (Integer Programming): utiliza funes lineares de valores inteiros para armazenar resultados de deciso. Acha-se a soluo com o procedimento de branch-and-bound, como em uma rvore de busca. Uma busca em toda rvore causaria problemas, mas com o uso de problemas subdivididos em partes menores e com as respectivas restries e solues, normalmente acha-se a soluo utilizando uma pequena parte dos ns. Mesmo assim, em problemas mais complexos, pode haver um estouro na necessidade de memria e tempo de execuo. Pode indicar resultados quantitativos e qualitativos. No permite a definio de aes concorrentes. CP (Constraint Programming): os problemas so descritos como problema de satisfao de restries que consiste na utilizao de variveis associadas a um domnio e a um conjunto de restries. Desta forma no se restringem os tipos de restries, mas sim as variveis de domnio finito. A semntica utilizada mais natural e prtica do que as anteriores. A satisfao de restrio uma busca por variveis que satisfaam as restries definidas. Caso se queira otimizar o processo, basta acrescentar uma varivel que defina a qualidade da soluo. A busca pela maximizao desta varivel tentar localizar uma alternativa de maior qualidade. Devido s caractersticas anteriores, este framework adequado para planejamento que envolva tempo e recursos, pois permite a identificao de resultados qualitativos, quantitativos e aes concorrentes.

63

4.1.4 Planejadores baseados em Restries


H trs categorias desse tipo de planejador [Freuder et al., 2005]: Planejamento com a indicao da restrio: utiliza as restries em rvores de subplanos e possui uma interao limitada entre a soluo de restries e o processo de planejamento. A tarefa reduzida a um pequeno nmero de atividades no nvel mais baixo seguinte [Russell e Norvig, 2004]. Isso faz com que o custo computacional seja menor. til para planejamentos tticos, onde os procedimentos de soluo so conhecidos antecipadamente. Quando utilizado em conjunto com restries baseadas em ontologias, oferece condies satisfatrias de entendimento por parte dos usurios. Planejamento com grafos mximos: tenta identificar todas as possibilidades de execuo das aes e coloca em um grafo. So criados subplanos que podem ser interpretados com a sintaxe booleana do SAT. A vantagem ter condies de avaliar todo o plano, mas fica naturalmente limitada a possibilidade de soluo para problemas complexos. til para problemas que necessitam de um nmero pequeno de variveis. Captura do plano com a programao de restries: no cria um estrutura de planejamento que verifique todas as possibilidades de ao. So definidas as restries estruturais que definem os pontos de em que o plano deve tomar uma deciso e a busca inclui a melhor alternativa ao grafo como parte da soluo. A busca pode variar entre a satisfao ou otimizao dos valores das variveis e a estrutura do grafo. Desta forma o plano pode ser criado com base em todos os aspectos do plano de busca.

4.1.5 Fatores importantes para programao de recursos em Grid


De acordo com Ranganathan [Ranganathan e Foster, 2003] alguns dos fatores mais importantes para programar recursos em Grid Computacional so: utilizao do recurso, tempo de resposta, poltica global e local de acesso e escalabilidade. Neste trabalho foram identificados quatro parmetros importantes que afetam o desempenho em ambiente de Grid: banda de rede, padres de acesso de usurios, qualidade da informao utilizada para realizar o trabalho e a relao entre o tempo de processamento e tamanho dos dados para determinar a importncia da localizao dos dados. A contribuio mais importante desse trabalho est na constatao que o processamento dos dados devem ser realizados no prprio recurso onde os dados se encontram. Segundo os autores, outros trabalhos tratavam isso de maneira independente. Com

64

isso o volume de trfego de rplica de dados consideravelmente diminudo. Isso traz benefcios para a rede como um todo e aumenta a velocidade de processamento dos dados.

4.1.6 As atividades como um problema de Planejamento


Podem-se identificar dois possveis ambientes para aplicao das tcnicas de Inteligncia Artificial para banco de dados em Grid: o planejamento clssico e o no-clssico. Considera-se o planejamento clssico para ambientes observveis, determinsticos, finitos, estticos e discretos. O planejamento no-clssico est relacionado aos ambientes parcialmente observveis ou estocsticos [Russel e Norvig 2004]. De acordo com Blythe [Blythe et al, 2004], atribuir uma srie de atividades em um fluxo de trabalho e alocar recursos a cada atividade um problema de planejamento de Inteligncia Artificial. Cada componente que faz parte do fluxo de trabalho modelado como um operador de planejamento. Os efeitos e precondies dos operadores refletem a dependncia de dados entre as entradas e sadas do programa e as necessidades e restries dos recursos em termos de equipamento e software. O plano determinar a ordem de execuo das atividades atravs das entradas e sadas esperadas. Em um ambiente de Grid Computacional, pode-se imaginar estes dois cenrios. Se houver uma organizao virtual com recursos identificados e limitados, por exemplo, possvel ter um ambiente de aplicao para o planejamento clssico. Atualmente o que se tem realizado em Grid este tipo de planejamento com algumas variaes. Em um ambiente de Grid possvel se deparar com informaes incompletas e incorretas, o que indicaria um planejamento no-clssico [Russell e Norvig, 2004]. Contudo as experincias tm se restringido a realizar o planejamento com o ambiente que se pode observar no momento em que este elaborado. Desta forma, as definies da arquitetura de planejamento so: Estado Inicial ou Representao de estados: deve indicar quais recursos esto disponveis para os usurios, estimar a largura de banda entre os recursos e disponibilizar a descrio do metadado. Em geral, contudo, so condies lgicas que representam um estado com literais positivos. Um recurso poderia estar representado por Disponvel (ou Indisponvel), Com Programao Futura (ou Sem Programao Futura), Com Dados (ou Sem Dados), etc. Representao de objetivos: estado parcialmente representado por literais bsicos positivos. Em um recurso pode-se ter como objetivo Com_Dados Programao_Futura ou ainda utilizando funes, como Programado( banco A,

65

servio A, data A). Esta representao pode ser estabelecida com a indicao da atividade e o recurso que devero ou podero ser utilizados. Representao de aes: uma ao especificada com base nas precondies e nos resultados obtidos depois da execuo. Exemplo: Ao(Programar( b1, s1, d1), PRECOND: Ter(b1) Ter(s1) Disponvel(b1,t1) EFECT: Disponvel(b1,t1) Programado(b1,s1,d1)) Onde, b1 um banco de dados, s1 um servio a ser executado e t1 a data de programao do recurso. Em Blythe [Blythe et al, 2004] pode-se encontrar uma soluo implementada em trs fases: preparar a especificao do problema inicial atravs da solicitao de informaes da Grid, planejamento das atividades utilizando tcnicas de Inteligncia Artificial e interpretar o plano de sada gerado pelo sistema. Para realizar o planejamento foram utilizadas heursticas locais com objetivo de maximizar a execuo do plano. Em resumo, para uma Grid Computacional deve-se definir como objetivo o comando de busca e indicar como operadores os recursos disponveis, com suas respectivas heursticas. O plano retorna a seqncia de atividades a serem executadas, com vinculao dos componentes e respectivos recursos. Este plano deve conter comentrios sobre os motivos de utilizao do recurso [Gil et al 2004]. Dessa forma, facilita-se a eventual troca de seqncia por parte do usurio.

4.1.6 Planejamento de Ordem Parcial


De acordo com Russel e Norvig [Russell e Norvig, 2004], o planejamento de ordem parcial realizado a partir da insero de pelo menos duas aes em um plano, sem especificar qual ao deve ser executada primeiro. implementado atravs de uma busca no espao de planos de ordem parcial. As aes sero, portanto, executadas sobre os planos atravs da adio de novos passos. Ainda assim pode haver uma restrio na ordenao dos planos, sem prejuzo na paralelizao das aes. Isso ir gerar um conjunto de vnculos entre os planos estabelecidos atravs de precondies e resultados. A grande vantagem deste planejamento est em se atribuir aes bsicas e independentes que, quando analisadas, podem ser estabelecidos pontos fictcios de incio e de

66

fim. A paralelizao da ao do plano pode ocorrer sem prejuzo para o plano como um todo. Com a finalizao das aes, alcana-se o objetivo final do plano. Abre-se tambm a possibilidade de se utilizar heursticas para determinar qual melhor plano de execuo. Em um ambiente de recursos heterogneos e limitados, importante que se possa considerar possveis restries.

4.1.8 Gerenciamento de trabalho


O problema de programar recursos em ambiente de Grid Computacional diferente da programao de recursos em ambientes multiprocessados ou clusters [Ranganathan e Foster, 2003]. A localizao dos recursos podem ser comprometida pela distncia entre eles e a velocidade da rede pode ser sensivelmente pior do que em um ambiente restrito. Cada recurso pode ter polticas de acesso completamente diferentes e que devem ter maior precedncia em relao aos servios da Grid. As caractersticas da Grid envolvem um ambiente dinmico com flutuaes na utilizao e disponibilidade dos recursos. Por este motivo o planejador deve realizar o planejamento no exato momento em que chegam as solicitaes, com objetivo de utilizar e maximizar os recursos disponveis. Esta mesma constatao foi utilizada por [Blythe et al, 2004] para implantar sua soluo e est de acordo com os princpios do planejamento clssico. A arquitetura proposta em [Ranganathan e Foster, 2003] prev a utilizao de trs mdulos para realizar a programao dos recursos: Programador Externo: o usurio submete as solicitaes e o programador decide para qual site remoto enviar a atividade. Para isso deve utilizar informaes especficas do local que enviar a solicitao. Programador Local: decide como programar as atividades alocadas nos recursos locais. Neste momento pode-se priorizar ou recusar alguns tipos de atividades. Programador de Dados: deve manter os dados que so mais acessados e eventualmente replic-los para outros sites. Por outro lado, em uma situao considerada ideal, as principais responsabilidades de um sistema gerenciador da Grid so [Gil et al 2004]: fiscalizar o desenvolvimento e execuo das atividades programadas, coordenar atividades que tenham sido submetidas por diversas programaes e aplicar as regras que garantam a execuo das atividades dentro do tempo necessrio. Ainda de acordo com Gil [Gil et al, 2004], em um ambiente genrico de Grid Computacional, o gerenciador deve ser um agente dinmico que controla as mudanas em

67

funo de uma eventual queda de servidores ou atraso na divulgao de resultado em funo de um aumento imprevisto da carga de trabalho. Isso abre a possibilidade de utilizao de algoritmos especficos que utilizem o planejamento no-clssico. A programao pode ser modificada durante o processamento das demais informaes. O prprio gerenciador deve ser capaz de prever algumas dessas ocorrncias (desde que haja informaes disponveis sobre a indisponibilidade e utilizao sazonal em nveis mais altos) e criar buscas distribudas. Durante a execuo do servio, como em alguns processos o tempo consumido muito grande, deve ser possvel ao usurio localizar o estgio das atividades programadas. A partir dessa informao, o usurio mais uma vez poder interferir no processo e modificar a seqncia ou utilizao de recursos. Desta forma, uma soluo que se apresenta vivel analisar periodicamente a submisso dos servios a cada recurso. Quando um recurso estiver disponvel e ainda houver servios a submeter, este ser utilizado. Naturalmente isto pode gerar uma alterao no planejamento inicial, mas, devido s circunstncias e dinmica do processo, pode ser uma alternativa vivel. Esta tcnica, denominada Monitoramento e Replanejamento de Execuo [Russell e Norvig, 2004], permite que se utilize qualquer tcnica de planejamento para se construir um plano, mas, atravs do monitoramento da execuo, verifica constantemente se este est sendo executado da melhor maneira possvel. Quando algo sai errado ou simplesmente sai do previsto inicialmente, possvel utilizar outra alternativa que se apresente vivel. Um fato que est estabelecido que no se devem programar recursos simplesmente atravs da localizao de processadores ociosos, em especial quando for necessria a replicao de dados. Pode-se, por outro lado, analisar os dados que so mais requisitados e propor uma poltica de replicao o que permite que em outra programao a informao mais requisitada esteja disponvel em outros sites.

4.1.9 Tcnica de Planejamento aplicada a bancos de dados da Grid


Como as aes atmicas de pesquisas em um banco de dados podem ser descritas pelo comando SELECT em uma nica tabela, utilizar o Planejamento de Ordem Parcial para definir um plano bsico de ao uma alternativa vivel. Isso faz com que cada busca seja submetida a um nico banco de dados, o que otimiza o processo de pesquisa. Este particionamento de uma busca complexa em diversas buscas simples e em diversos bancos de dados pode se dar em paralelo, o que agiliza o resultado da busca final. possvel, tambm, monitorar o ambiente aps a submisso da busca em todos os bancos de dados disponveis. Quando o primeiro banco de dados encerrar o processamento

68

das linhas da tabela, recebe uma nova busca, mesmo que isso contrarie o plano inicial proposto. Quando no houver mais buscas a serem submetidas, basta aguardar a finalizao dos processos em todos os bancos de dados para, em seguida, reunir o resultado das buscas simples. O plano pode utilizar heursticas especficas da Grid ou do prprio banco de dados para definir a ordem de execuo do plano, mas deve-se considerar que o plano poder ser modificado em caso de monitoramento dos recursos. No final da execuo do plano deve-se unir as diversas buscas em uma nica para fornecer o resultado ao usurio.

4.2 Auto-gerenciamento em SGBD


Outra questo relevante para tomada de deciso do sistema planejador de banco de dados em Grid a necessidade de um repositrio com a situao atual do recurso alm de dados armazenados que indiquem a utilizao passada. Os principais SGBDs comerciais possuem um padro timo de desempenho. necessrio um mecanismo que ajuste a situao atual com estes padres. O histrico de utilizao importante para informar ao gerenciador qual e quando ocorre o pico de utilizao do recurso. Isto no deve impedir que usurios experientes possam otimizar manualmente o desempenho dos SGBDs. Os prprios SGBDs devem fornecer, via metadados, informaes relevantes dessa utilizao, permitindo que o gerenciador decida como e quando utiliz-lo. Mecanismos de backup e recuperao de falhas devem estar automatizados para diminuir a possibilidade de perda de informaes.

4.3 Soluo DQP


A soluo proposta por Gounaris [Gounaris et al, 2004] indica uma forma de escalonar o uso de SGBDs de uma Grid Computacional com base no Processamento de Buscas Paralelas (DQP). A soluo recupera buscas escritas em OQL (Object Query Language) e transforma em um plano de busca que gera um grafo em formato de rvore. Os vrtices da rvore representam os operadores bsicos da busca e as margens o fluxo de dados (figura 4.1). As trs formas clssicas de paralelismo em banco de dados so: Independente: ocorre quando h pares de subplanos de busca independentes, ou seja, os subplanos no dependem um do outro.

69

Pipelined: ocorre quando a sada de um operador utilizada por outro operador conforme aquele gerado. Neste caso ambos os operadores so executados em concorrncia. Particionada: um operador fsico do plano de busca tem vrias cpias sendo que cada uma delas processa um subconjunto de dados.

Figura 4.1: Exemplo de Plano de Busca [Gounaris et al, 2004]

Segundo os autores, mesmo em sistemas homogneos, achar o maior grau de paralelismo diminui a eficincia da utilizao dos recursos e diminui o desempenho da aplicao como um todo. Eles identificam que o problema de escalonamento da Grid est no fato de no limitar o grau de paralelismo, em no determinar quantas e quais mquinas utilizar e qual parte do plano de busca cada recurso pode realizar. Entende-se a eficincia da paralelizao de buscas a possibilidade de realizar o paralelismo de buscas em ambientes heterogneos com inmeros recursos e balancear o desempenho e eficincia na utilizao desses recursos. A busca de uma heurstica eficiente compreende a combinao de recursos, a distribuio da carga de trabalho e a otimizao dos planos de busca. O algoritmo proposto est representado na figura 4.2. O algoritmo composto por dois laos. O mais externo poder ser repetido at o limite do nmero de operadores de busca. O interno poder ser repetido at o limite do nmero de computadores disponveis na Grid. Atravs deste algoritmo, um plano de busca otimizado de um nico n particionado, resultado da transformao da busca especificada via OQL pelo Polar*, os computadores candidatos para realizarem a operao e uma varivel que tem o objetivo de estabelecer o limite para a melhoria do desempenho so os parmetros de entrada. As heursticas utilizadas para selecionar os computadores candidatos envolvem: poder de processamento (CPU),

70

memria, velocidade de I/O, velocidade de conexo, proximidade. Essas heursticas so extradas da Grid Computacional atravs do [GrADS, 2006]. O processo se inicia com o plano de busca. Este plano deve preferencialmente no ter paralelismo. O plano separado em cada um dos subplanos de busca, o que gera um particionamento da busca original. Cada operador identificado no plano de busca atribudo a um computador. Os operadores podem ser: Operadores de troca (que encapsulam o paralelismo e envolvem comunicao e esto representados na figura 1 por Exchange); Chamadas de operaes (que encapsulam funes definidas pelo usurio e esto representados na figura 1 como operation_call); varredura (que herdam os custos de entrada e sada e esto representados na figura 1 como scan); Projeto (que indicam corte nos dados e esto representados como Project) e Demais operadores como unies (joins), utilizao de CPU e comunicao entre outros que indicam custo para realizar a operao. Depois de particionada a busca, aumenta-se um grau para cada parte do subplano de busca em um determinado tempo de execuo. Passe-se a estimar o custo do subplano de busca: aloca-se um recurso com base na localizao do dado. O recurso somente ser alocado onde os dados estejam disponveis, ou seja, no h previso de utilizao de rplicas no algoritmo. A anlise de viabilidade de particionamento da busca feita para cada operador da busca. Inicia-se pelo operador de maior custo e o computador disponvel para execuo desta parte da busca. Se o aumento do desempenho for maior que o limite estabelecido no parmetro de entrada do algoritmo, aumenta-se um grau de paralelismo e estima-se novamente o custo da busca com a nova formatao do plano. Este processo feito sucessivamente at que se extraia um plano de busca dentro dos limites impostos pelo parmetro do algoritmo. Com esse algoritmo possvel localizar um plano de busca vivel e que no demande muito tempo de planejamento. Quanto menor for o limite informado como parmetro, mais perto do timo estar o resultado e maior ser o tempo de preparao do plano. De acordo com os autores improvvel que este algoritmo funcione bem em processamentos massivos.

71

Figura 4.2: Algoritmo proposto em [Gounaris et al, 2004]

Os resultados alcanados na implementao do algoritmo esto relacionados identificao do custo da busca: Atribuio de um custo para cada plano de busca paralelo Atribuio de um custo para cada operador fsico do plano de busca Diminuio da influncia entre o custo e o algoritmo de programao Ao especificar melhor os custos de uma busca, possvel estabelecer heursticas que permitam aprimorar o modelo.

4.4 Crtica
A soluo proposta pelo DQP apresenta relevncia considervel dentro do que se prope a realizar. Contudo, no stio DQP [OGSA-DQP, 2006] encontra-se uma srie de limitaes para o projeto. Dentre os quais destacam-se: No pesquisam os metadados dos computadores envolvidos na busca e estas informaes no so utilizadas durante o escalonamento. Com isso toda heurstica fica prejudicada. Suporte apenas ao MySQL. As buscas esto restritas a alguns tipos de dados (long, integer, string, double e float) e no suporta tipos de dados como: date, time, etc. Suporte a buscas escritas em OQL. Esta no uma linguagem padro de busca utilizada pelo pblico no-acadmico. Naturalmente h uma dificuldade em reescrever todas as buscas dentro desse novo padro. As buscas devem ter todas as tabelas na clusula FROM e unidas pela clusula WHERE. S h suporte ao uso de AND na clusula WHERE. No se pode utilizar o OGSA-DAI para indicar servios de dados do OGSA-DQP. Est limitado aos SGBDs do computador onde est instalado o OGSA-DQP.

72

Estas limitaes esto relacionadas basicamente a no utilizao do padro proposto pelo OGSA-DAI. A comunidade acadmica e at comercial tem dado preferncia utilizao de padres para evitar limitaes e necessidade de adaptao a novos modelos. O OGSADQP est baseado no projeto Polar* que responsvel pelo particionamento da busca. Isso aumenta a complexidade de instalao e configurao do ambiente. O OGSA-DAI no um trabalho concludo, mas tem sido aprimorado ao longo dos anos de acordo com o grupo de trabalho OGSA-DAIS que pretende estabelecer o padro de acesso e manipulao em banco de dados. A prpria documentao do projeto incentiva que se estendam os padres para necessidades complementares. Com isso, possvel fazer com que os avanos realizados a cada nova verso possam ser incorporados ao processo de escalonamento e planejamento dos recursos que o middleware capaz de identificar. Ao se idealizar uma soluo com a utilizao de tcnicas de IA, o sistema de planejamento deve receber como entrada o objetivo a ser alcanado, representado por um comando de busca e uma biblioteca de recursos que se pode utilizar para modificar o estado. Os recursos devem ser capazes de indicar a respectiva representao do estado atual, como nvel de utilizao, velocidade e metadados de cada SGBD disponvel na Grid. Antes mesmo de planejar a execuo da atividade, necessrio subdividir o comando de busca (query) em partes que possam ser executadas em paralelo, extraindo, desta forma, o mximo dos recursos disponveis. necessrio saber os recursos que se pode contar antes da submisso da tarefa e quais informaes esto disponveis em cada um dos recursos (metadados). Cada ao deve ter uma descrio do estado (pr-condio) e uma descrio das mudanas de estado (efeitos). Aps estas atividades, a utilizao de tcnicas de planejamento de distribuio de trabalho necessria para: determinar qual SGBD realizar o trabalho, localizar e utilizar eventuais rplicas dos dados necessrios, determinar quando pode ser esperado o retorno da informao, recuper-la, uni-la s diversas subconsultas para produzir um resultado nico e determinar alternativas em caso de falha de um ou mais recursos. Estas informaes devem estar disponveis para o planejador. O sistema deve ser desenvolvido sob uma arquitetura orientada a servios para que se maximize a adoo e integrao com diversos tipos de sistema. Tecnicamente, ao adotar esta estrutura, possvel combinar os SGBDs em um espao de estados com heurstica.

73

Parte II: Proposta 5 Especificao do Problema


O problema de coordenar as atividades para gerar um fluxo de aes a serem executadas e a vinculao das aes aos recursos que iro execut-las atravs de um middleware pode ser formulado como um problema de planejamento que pode ser solucionado com algoritmos de Inteligncia Artificial. O objetivo criar um mecanismo que possa estar entre as solicitaes do usurio e a execuo nos diversos bancos de dados disponveis na Grid Computacional. Portanto evita-se fixar em um nico tipo de busca ou problema. Basicamente sabe-se que o planejador deve se basear em um middleware que j exista e tenha suporte s principais atividades de um banco de dados alm de no ter vnculo exclusivo com uma nica implementao comercial de banco de dados. Isso faz com que haja necessidade de estabelecer uma interface nica para qualquer tipo de banco de dados. Sabe-se que a melhor forma de realizar trabalhos em uma Grid Computacional estabelecer o desenvolvimento baseado em servios. A integrao com os middlewares disponveis importante para que no se limite e se permita a evoluo da aplicao da soluo. Em aplicaes relacionadas a um SGBD possvel identificar duas maneiras bsicas para especificar o que deve ser feito: a execuo de comandos DML/DQL (Data Manipulation Language e Data Query Language) e execuo de procedimentos armazenados. No caso de um procedimento armazenado a especificao deve ser mais rigorosa, visto que dever definir a lgica do processo. Esta definio foge ao escopo deste trabalho porque ainda no h um padro definido para linguagens de programao para banco de dados em Grid Computacional. Uma alternativa que se mostra vivel a utilizao da linguagem Java em SGBD. J possvel escrever cdigos em Java no banco de dados Oracle, no PostGreSQL e no DB2 da IBM. No SQL Server 2005 possvel utilizar o C# para criar funes estendidas. De qualquer forma, este no o problema principal, visto que necessrio manter uma biblioteca de funes e procedimentos vinculados aos SGBD para que estes possam executar as funes. O problema principal est em estabelecer a comunicao com diversos SGBD e permitir que se localize e manipule dados em qualquer dos recursos disponveis da Grid. Uma vez estabelecida a comunicao e ao permitir a manuteno e recuperao de dados na Grid, o problema central estar equacionado.

74

Por outro lado, o grupo de trabalho envolvido na definio dos servios da Grid Computacional (OGSA-DAIS) j definiu a estrutura para manipulao de dados o que viabiliza a soluo apresentada. A implementao de parte das solues idealizadas j uma realidade e existe um middleware (OGSA-DAI) que possibilita estabelecer a integrao entre solicitaes e recursos.

5.1 Justificativa do uso de IA


O problema de planejamento do uso de banco de dados em um ambiente distribudo pode ser especificado a partir da disponibilidade das informaes. Em um banco de dados relacional, como as informaes so extradas de tabelas e estas tabelas esto, potencialmente, presentes em diversos bancos de dados atravs de mecanismos de replicao, pode-se realizar buscas que visem maximizar o uso dos recursos. Contudo a soluo para este problema em um ambiente completamente observvel, como o caso de clusters, tem sido amplamente discutida na comunidade acadmica e os resultados, representados por produtos comerciais, tem sido satisfatrios. Isto se d porque em clusters, diferentemente do que ocorre em Grid Computacional, o ambiente detm completo controle sobre a distribuio dos dados. Em uma Grid Computacional o desafio est em estabelecer o uso dos recursos de maneira dinmica, sem enxergar todos os bancos de dados como extenses de um nico ambiente. Em bancos de dados relacionais, a unidade bsica de pesquisa o comando SELECT. Consultas complexas e filtros exigem maior esforo do banco de dados. Paralelizar as buscas tem se mostrado um mecanismo eficiente em ambientes de produo. Mesmo que se considere uma Organizao Virtual como um ambiente completamente observvel, nem sempre sabemos a localizao exata das tabelas visto que podem estar em diversos bancos de dados. O espao de estados deve ser observado sempre que se propor uma submisso de trabalhos (recursos disponveis para realizar as buscas). Pode-se utilizar o Planejamento de Ordem Parcial para realizar e separar as aes bsicas do plano, visto que cada consulta simples tratada como uma ao independente e paralelizvel. O fato de se paralelizar as buscas particionadas permite que se maximize o uso dos recursos dentro de uma Organizao Virtual. Definir as etapas bsicas do processo, como verificar o espao de estados, apurar mtricas, vincular bancos de dados e tabelas e, por fim, identificar os comandos bsicos de busca para determinar pr-condies e efeitos, so tarefas que podem ser resolvidas atravs de algoritmos de IA.

75

O monitoramento se faz necessrio para acompanhar os resultados e retornar a informao ao usurio. O monitoramento pode, inclusive, fazer com que eventuais falhas do sistema planejador sejam corrigidos em tempo de processamento. Como se pode inferir, o uso dos algoritmos de planejamento desenvolvidos ao longo do tempo com as tcnicas de IA contribuem para resolver o problema da submisso das buscas. Algoritmos de monitoramento e at mesmo algoritmos de planejamento condicionais podem ser utilizados para potencializar a eficincia do sistema planejador.

5.2 Arquitetura Orientada a Servios


Para que o desenvolvimento siga o padro de arquitetura orientada a servios, as necessidades do usurio devem ser descritas atravs do que deve ser feito. Uma vez que a linguagem SQL tambm baseada no mesmo princpio, pois esconde a complexidade da operao de como ser manipulada a informao nos arquivos fsicos, a prpria estrutura do comando SELECT poder ser utilizada. Ao formular o comando SELECT, o usurio define: a.) Em qual(ais) tabela(s) a informao est b.) Quais colunas ele precisa c.) Quais linhas ele precisa d.) Indica o relacionamento entre as tabelas (quando for mais de uma) e.) Indica a ordem pela qual se quer enxergar o resultado f.) Indica eventuais agrupamentos da informao g.) Impor condies para filtrar as linhas que devem retornar

5.3 Fases do Planejador


O sistema planejador ser dividido em quatro partes principais: Interceptar as requisies do usurio que so enviadas para o middleware Solicitar ao middleware as informaes dos recursos disponveis na Grid Computacional Especificar o domnio do problema de acordo com os padres da Inteligncia Artificial e planejar a execuo Programar os recursos e distribuir as solicitaes fruto do planejamento para que o middleware execute nos SGBDs.

76

A figura 1 demonstra as entradas e sadas esperadas pelo planejador. Deve haver um processo que identifique o estado atual dos recursos e outro para definir as necessidades do usurio. Ambos servem para iniciar o processo de planejamento. A identificao dos recursos e a forma de comunicao com os SGBDs sero delegadas ao OGSA-DAI. As necessidades do usurio devero estar especificadas dentro do formato utilizado na OGSA-DAI. O usurio informa sua necessidade de busca complexa dentro da estrutura proposta na OGSA-DAI. O planejador solicita ao middleware informaes dos recursos disponveis e verifica quais recursos possuem as tabelas necessrias para execuo do comando. O planejador particiona a busca em comandos que possam ser executados paralelamente em diversos SGBD e vincula aos recursos disponveis. Aps o estabelecimento do fluxo de trabalho, o servio ser enviado Grid Computacional para ser processado nos gerenciadores de bancos de dados. Terminado o processo, o planejador une as linhas retornadas e devolve ao usurio que solicitou a busca. Recursos SGBD

Necessidades do Usurio
Busca Complexa Resultado

Recursos e Mtricas

Planejador
Busca Resultados

OGSA-DAI

Figura 5.1 Entradas e Sadas do sistema planejador

Para isso necessrio especificar os objetivos, pr-condies e efeitos esperados, estabelecer uma heurstica vlida e consistente com o objetivo, excluir as restries identificadas pelo usurio e implementar regras de busca. A heurstica deve ser estabelecida com base nas informaes dos recursos e so representadas pelas mtricas na figura 5.1.

77

5.4 Objetivo
Cada elemento do comando SELECT ser um componente que demandar uma ao pelo planejador. Cada elemento ser, portanto, um operador do planejamento. O objetivo ser o conjunto de dados definidos nas colunas do comando.

5.5 Pr-condies e Efeitos


Para cada uma das aes propostas no sistema planejador haver pr-condies que, aps o processamento, geraro os efeitos para a nova etapa. Desta forma, ao se comear a ao baseado na consulta complexa, obtm-se as consultas particionadas. Ao unir as consultas particionadas e os recursos disponveis, possvel extrair as mtricas e vincular os bancos de dados que possuem as tabelas para realizar as buscas. Com base nas mtricas, bancos de dados e buscas, pode-se efetuar o planejamento de ordem parcial. As pr-condies e os efeitos de cada busca sero definidos pela localizao dos dados nas tabelas. Note-se que as tabelas, por fazerem parte de um ambiente tipicamente distribudo, podero estar replicadas em alguns servidores de banco de dados. A localizao da informao deve se dar atravs do metadados da Grid. O planejador indicar a ordem na qual as aes devero ser realizadas para atingir o objetivo. Com o resultado final de cada uma das buscas particionadas, possvel unir o resultado para apresentao final ao usurio.

5.6 Heurstica
A transferncia de dados pela rede deve ser modelada como um operador do planejamento e deve compor o custo da ao, juntamente com o custo estimado do processamento no banco de dados, com o poder de processamento do computador onde est instalado o SGBD, memria disponvel e espao no HD. O custo da transferncia de dados pode ser medida pela banda e proximidade dos ns da rede. Quanto maior a banda menor o custo de transferncia. Quanto mais prximo, menor o custo. Deve ser definido um operador para indicar qual limite mnimo de banda dever ser descartada em funo do volume de trfego de dados esperado. O custo do processamento da consulta no banco de dados deve basear-se, sempre que possvel, no padro de cada recurso. Deve-se priorizar a utilizao de CBO (Cost-Based Optimizer) em favor do RBO (Rule-Based Optimizer) pela maior confiabilidade que o primeiro confere.

78

O custo do banco de dados composto por uma srie de parmetros disponveis nas implementaes comerciais dos produtos. Mede-se basicamente por trs aspectos: a.) Percentual utilizado da CPU b.) Velocidade de entrada e sada de dados c.) Uso e limitao de memria voltil Para que se tenha maior segurana na qualidade do recurso, ser utilizado, sempre que a informao estiver disponvel no banco de dados, o MTBF (Mean Time Between Failure) que indica o tempo mdio de falhas. Estas informaes sero mantidas por processos especficos de cada SGBD sempre que possvel e compor o pacote de instalao da soluo. A inteno criar um mecanismo independente de outros servios da Grid (como MDS), pois que estes trazem informaes muito mais vinculadas aos servidores e nada sobre o banco de dados. A simplificao da estrutura de busca fundamental para agilizar o processo de escalonamento e planejamento de utilizao dos recursos.

5.7 Restries
Um planejador deve prever as restries de hardware e software [Blythe et al, 2004]. No caso de bancos de dados relacionais a maior parte destes requisitos esto encapsulados. As limitaes de hardware normalmente envolvem um tipo especfico de equipamento, memria ou espao em disco e as de software esto vinculadas utilizao da linguagem SQL, um padro para gerenciadores de bancos de dados. O sistema operacional tambm escondido pelo SGBD. Portanto, para um planejador de aes em gerenciadores de banco de dados, basta que se defina qual ou quais implementaes sero utilizadas. O estado inicial do ambiente ser definido pela informao dos gerenciadores de bancos de dados disponveis, pelas mtricas extradas dos recursos e pelo custo estimado do processamento da consulta.

5.8 Regras de Busca


O sistema planejador dever verificar todos os espaos de estados possveis dadas as restries do usurio e as condies identificadas na Grid Computacional. A escolha ser sempre baseada na soluo que demande menor tempo de processamento e permita maior possibilidade de desvio em caso de falhas.

79

5.9 Proposta de Implementao


Utilizou-se a UML porque uma linguagem adequada para modelar sistemas orientados a servios. A figura 5.2 identifica cada uma das atividades que o sistema planejador deve realizar e os atores que fazem parte do processo. Optou-se por utilizar um caso de uso para a execuo do planejamento recebendo apenas as requisies do usurio e casos de uso que obrigatoriamente sero executados para: descobrir os recursos presentes na Grid Computacional, recuperar mtricas dos bancos de dados e realizar o particionamento do comando SELECT. Como estes casos de uso podero ser utilizados em outras funes do ambiente, eles foram modelados separadamente. A Grid Computacional, por ser o prprio ambiente, no foi modelada como um ator ou mesmo caso de uso.

Figura 5.2 Diagrama de Caso de Uso da proposta

5.9.1Algoritmos e Heurstica
O algoritmo utilizado para criar o plano ser o planejamento de ordem parcial com monitoramento. Isso porque cada um dos algoritmos possui caractersticas que podero ser utilizadas isoladamente ou em conjunto, dado que um planejamento um exerccio de anlise das possveis combinaes de aes para atingir o resultado esperado [Russel e Norvig 2004]. No planejamento de ordem parcial possvel indicar a seqncia de ao sobre os planos. Assim possvel dividir o planejamento em tpicos (planos) independentes e que podem ser executados internamente ou em paralelo em qualquer ordem. Naturalmente necessrio estabelecer as restries de ordenao e os vnculos causais entre os planos.

80

Normalmente necessrio buscar uma srie de informaes dispersas em diferentes tabelas no banco de dados antes de se consolidar os resultados para apresentao. A busca pode ser realizada em diversas tabelas, em diversos bancos de dados, simultaneamente, sem necessidade de uma ordem pr-estabelecida. A nica restrio que isso seja feito antes da consolidao de dados. No caso especfico da Grid Computacional, onde possvel dividir o problema em uma srie de pequenos objetivos (sub-objetivos serializveis [Russel e Norvig 2004]), acredita-se que o agente ser suficientemente rpido para controlar as aes dispersas na Grid. O grafo de planejamento estabelecido em nveis que representam perodos de tempo. Cada nvel possui um conjunto de literais e aes relacionados e ser possvel extrair uma heurstica do resultado do grafo [Russel e Norvig 2004]. Em um planejamento de banco de dados em Grid, possvel utilizar o grafo de planejamento para identificar se uma determinada seqncia de aes ir ou no produzir o efeito desejado (se ou no possvel executar o plano) e determinar se h aes ou situaes que so mutuamente exclusivas. Alm da heurstica que pode ser extrada do grafo de planejamento, importante estabelecer restries para os recursos computacionais. Estas restries determinaro a ordem e a prioridade no uso dos bancos de dados. Um banco de dados relacional depende basicamente de quatro situaes: processador, rede, memria e meio de armazenamento fsico (E/S). A heurstica dever conter estes elementos em uma proporo que cada implementao de banco de dados dever determinar. A proposta que cada fornecedor de banco de dados fornea a proporo de utilizao de cada recurso, inclusive com a limitao imposta pelas necessidades dos usurios internos da organizao [Foster et al 2001]. Uma medida importante para tomada de deciso do planejador o MTBF (Mean Time Between Failures). Este nmero indica o tempo mdio de falha de um determinado recurso (disco rgido, por exemplo). Alguns gerenciadores de bancos de dados possuem mtricas que permitem identificar o nvel de falha de perifricos, a ltima falha ocorrida e o nvel de utilizao histrico do banco de dados. Estas informaes permitiro ao planejador inferir sobre a confiabilidade de determinado recurso e, eventualmente, propor caminhos alternativos de execuo do plano. Com estas informaes dos SGBDs aliadas ao grafo de planejamento ser possvel otimizar a seqncia tendo como base o tempo estimado de execuo. A soluo poder ser formulada em um problema de satisfao de restries booleano e poder ser resolvido com o

81

algoritmo de conflito mnimo. A codificao proposicional envolve a definio do estado inicial, objetivo, axiomas sucessores, de precondies e de excluso de aes (ou restrio de estados). Dessa forma, qualquer modelo que atenda sentena proposicional ser um plano vlido para o problema [Russel e Norvig 2004]. As codificaes proposicionais so complexas e podem consumir grande volume de recursos [Russel e Norvig 2004]. Os smbolos de ao seriam suficientemente grandes para inviabilizar a aplicao desta tcnica. Portanto necessrio reduzi-lo e, no caso do banco de dados em Grid, utilizar redes semnticas com predicados binrios. Dessa forma, cada argumento ser descrito e analisado separadamente [Gil et al 2004]. A identificao de uma nica varivel de cada SGBD para indicar quanto h de disponibilidade do recurso, simplificar a utilizao da lgica proposicional na elaborao do plano de ao.

5.9.2 Algoritmo proposto


Com base nas diretrizes expostas, o algoritmo proposto para criar o plano de trabalho est estabelecido como proposto na figura 5.3.
Entrada (estado inicial): Consulta Complexa Processo: LER recursos para objetos (operadores de planejamento) LER consulta << Separar itens da consulta em consultas simples >> - tabelas da clusula FROM - joins PARA cada item de consulta <<LER quais recursos possuem tabela>> BUSCAR no dicionrio de dados dos recursos ARMAZENAR mtricas do recurso (mtrica_recurso) PARA cada tabela (pr-condio) PARA cada recurso SE tabela est no dicionrio de dados CRIA recurso_tabela PARA cada recurso_tabela PARA cada mtrica_recurso SE mtrica(recurso 1) > mtrica(recurso 2) CRIA base de consulta no recurso SUBMETE buscas UNE resultados Sada (objetivo): Resultado da consulta complexa Figura 5.3: Algoritmo proposto.

O algoritmo contm trs laos: o primeiro executado com base na separao dos itens da busca; o segundo em cada uma das tabelas especificadas na busca; e por fim, aps o

82

vnculo do recurso com a tabela, verifica o recurso com melhor mtrica para realizar o planejamento. Como parmetro de entrada, ser interceptado recebida a consulta complexa no middleware (OGSA-DAI). Sero solicitadas ao middleware informaes sobre quais so os recursos (bancos de dados) disponveis na Grid. Com base nestas informaes, sero lidos os recursos para os objetos e importados os objetos de consulta. Um mtodo ir separar cada uma das tabelas e respectivas colunas de busca. Deste mtodo retornaro, alm das tabelas e colunas, as unies entre as tabelas e as eventuais funes a serem utilizadas no banco de dados. Para cada item da consulta, sero identificados quais bancos de dados esto disponveis para busca. Ser possvel extrair mtricas de desempenho do banco de dados. Em seguida para cada tabela necessria para realizar a consulta sero identificados os recursos disponveis. Isso ser feito atravs de uma busca no dicionrio de dados do banco de dados. Para cada uma das tabelas j vinculadas a cada um dos possveis recursos, dever ser verificada a mtrica extrada do banco de dados. Os recursos com melhor mtrica recebero o comando de busca para se submeter ao middleware. Cada item do processo possui como pr-requisito o resultado da etapa anterior. O efeito de cada etapa, por sua vez, apontar para um estado especfico necessrio para etapa seguinte, conforme pode ser observado na figura 5.4. A submisso das buscas particionadas, por serem atmicas, podem se realizar em paralelo.

83

Iniciar( Em(Busca Complexa) ^ Em(Recursos Disponveis) ) Objetivo( Em(Resultado Busca) ) Ao( Separar(Busca Complexa) ) PRECOND: Em (Busca Complexa) EFFECT: Em (Buscas Simples) Ao( ApurarMtrica( Recursos Disponveis ) ) PRECOND: Em (Recursos Disponveis) EFFECT: Em (Mtrica) Ao( VincularBusca(Buscas Simples, Recursos Disponveis) ) PRECOND: Em (Busca Simples, Mtrica) EFFECT: Em (Busca, Recurso) Ao( SubmeterBusca( Busca, Recurso ) ) PRECOND: Em (Busca, Recurso) EFFECT: Em (Resultado Busca) Ao( MostrarResultado (Resultado Busca) ) PRECOND: Em (SubmeterBusca) EFFECT: Em (Resultado Final)
Figura 5.4 Descrio do Problema de Planejamento de Banco de Dados em Grid

No final do processo haver uma srie de tabelas temporrias que sero unificadas no comando complexo para oferecer o resultado final ao usurio. O usurio continuar criando o programa para processamento no middleware dentro dos padres propostos pelo ambiente e receber o resultado final sem a necessidade de modificar o que feito atualmente. Toda complexidade de transformar o comando e extrair o resultado ficar sob a responsabilidade do sistema. No se corre o risco de estourar o tempo de planejamento, visto que o limite do algoritmo est no nmero de tabelas da busca e no nmero de recursos disponveis. A menos que haja um volume extremamente grande de recursos, o tempo de processamento deve ser coerente com o ganho na distribuio do processamento. Uma outra vantagem do algoritmo que, caso no haja recurso disponvel para tratar a solicitao como, por exemplo, uma ou mais tabelas no estarem presentes nos recursos disponveis, este ser interrompido.

84

6 Metodologia
Com base na especificao proposta, foi elaborado um sistema que atende mais aos requisitos de planejamento do que de escalonamento, utilizando a tcnica de planejamento de ordem parcial, com decomposio de aes, mas sem a restrio de recursos. Um segundo sistema foi desenvolvido para monitorar o ambiente e aguardar o resultado da primeira submisso em todos os recursos disponveis para, assim que o primeiro recurso encerrar o processo, receber novas submisses, se houver. Visto que em sistemas gerenciadores de banco de dados o tempo de resposta de uma busca submetida pode variar em funo da quantidade de linhas e colunas processadas, memria disponvel e carga de processamento do servidor e, que, quando a busca processada, pode-se obter uma resposta completa positiva ou negativa, no h como se determinar prazos a para execuo deste tipo de tarefa. Portanto o que se pretende realizar est restrito a uma tarefa de planejamento e submisso das buscas. No h restries aplicveis ao modelo, visto que ou a informao pode estar disponvel ou no. Como a busca pode ser realizada em um ambiente completamente observvel, optou-se por esta forma de planejamento. Antes de iniciar o planejamento, realizada uma busca para identificar a existncia ou no das tabelas em cada um dos bancos de dados disponveis. Quando houver a tabela no banco, a busca ser realizada e, a princpio, as linhas sero retornadas. A partir desta premissa, foram identificados dois cenrios distintos: Planejamento de Ordem Parcial: a partir da decomposio do comando SELECT em seus elementos bsicos, possvel realizar simultaneamente tantas instrues quantas forem possveis sem que haja necessidade de ordem pr-estabelecida. Ao final de cada comando SELECT, as linhas sero unidas para retornar o resultado final da busca, conforme pode ser visto na figura 6.1.

85

Iniciar

Consulta Complexa Consulta Simples 1 Consulta Simples 2 Consulta Simples n

Unio das linhas

Terminar

Figura 6.1: Planejamento de Ordem Parcial de Consultas Complexas

Planejamento Condicional com Restrio de Recursos e Monitoramento: parte-se do Planejamento de Ordem Parcial, mas verifica-se a possibilidade de haver menos recursos disponveis do que o nmero de buscas a serem submetidas. Isso ocorrer somente caso seja uma busca com mais de 2 tabelas. Quando isto acontecer, o planejador monitorar as buscas submetidas a todos os bancos de dados e o primeiro que encerrar o processo receber novas buscas para execuo, conforme mostra a figura 6.2.

86

Iniciar

Consulta Complexa

Plano Reparao

Consulta Simples 1

Consulta Simples 2

Consulta Simples n

Unio das linhas

Terminar

Figura 6.2: Planejamento de Ordem Parcial com Restrio de Recursos e Monitoramento

No primeiro teste (Planejamento de Ordem Parcial), assume-se que, mesmo que o sistema gerenciador de banco de dados venha a realizar mais de uma busca ao mesmo tempo, isso no representa uma restrio. Os gerenciadores de banco de dados atuais so capazes de executar as buscas submetidas sem ter que interromper a execuo de uma busca para implementar a outra. No segundo teste (Planejamento Condicional com Monitoramento), submetem-se todas as buscas simples em todos bancos disponveis e aguarda-se o primeiro banco a encerrar a busca. O banco que encerrou a busca inicia, ento, a prxima busca do planejamento.

6.1 Mdulo Desenvolvido


A partir da instalao do ambiente, iniciou-se a criao do mdulo para realizar o planejamento da utilizao dos recursos e com a utilizao dos dois bancos de dados disponveis. A plataforma de desenvolvimento escolhida foi o Java. Por haver uma srie de exemplos disponveis no ambiente Java para a realizao de buscas, foram analisadas todas as

87

possibilidades e APIs disponveis para criao do mdulo. Assim, o ambiente de desenvolvimento escolhido foi o Eclipse verso 3.0, por ter total compatibilidade com o Java e no ser dependente de um distribuidor especfico. O middleware OGSA-DAI no possui um mecanismo de paralelizao das buscas em diferentes bancos de dados (DataServices). possvel, atravs da verso atual, submeter as buscas em paralelo, desde que se utilize um nico banco de dados. Quando o processo encerrado e controle retorna atividade que, ento, pode submeter nova busca. Como isso no atendia o que era proposto realizar, foi necessrio criar um mecanismo que estabelecesse as buscas atravs de Threads. Uma classe foi criada para implementar a Thread e reter algumas informaes importantes para acompanhar o andamento das consultas. Desta forma foi possvel notar que, mesmo em DataServices diferentes o sistema conseguia acrescentar dados em todas as tabelas temporrias ao mesmo tempo. Por haver uma srie de exemplos disponveis no ambiente para realizao de buscas, foram analisadas todas as possibilidades e APIs disponveis para criao do mdulo. O mdulo foi desenvolvido em uma nica classe, cujos mtodos so: getResources: localiza e retorna os recursos disponveis no middleware. splitSelect: divide o comando SELECT com base nas tabelas de busca. checkDataResources: verifica a existncia de cada uma das tabelas de busca em cada um dos recursos disponveis. getMetrics: verifica a mtrica de cada recurso disponvel. isWhereAlias: verifica a existncia de apelidos nas tabelas de busca. tableMetadata: verifica a existncia da tabela no metadados dos recursos envolvidos. metric: avalia a mtrica dos recursos envolvidos na busca. DTOutputStream e performBulkLoad: para unir as buscas e fornecer o resultado final.

6.1.1 Identificao dos recursos disponveis


O mtodo getResources localiza, a partir da Universal Resource Locator (URL) do servio de dados da OGSA-DAI quais so os recursos que esto disponveis naquele momento. So utilizadas funes especficas da API do middleware para localizar e identificar os recursos.

88

6.1.2 Separao dos elementos do comando SELECT (parse)


O mtodo splitSelect recebe o comando SELECT que ser executado, exatamente como os usurios e as aplicaes normalmente submetem ao banco de dados. Foi criado um pequeno mecanismo de transformao de consultas complexas em pequenas consultas, cada uma com uma nica tabela. Desta forma cada comando SELECT poder ser submetido a um banco de dados para execuo. No houve necessidade de se criar um mecanismo complexo de parse, visto que o objetivo deste trabalho foi testar algoritmos de planejamento do uso dos bancos de dados (recursos). A primeira etapa do processo separar as colunas do comando SELECT. Depois so separadas as tabelas da clusula FROM. As tabelas so separadas com e sem os apelidos, para facilitar a criao das buscas isoladas. Neste mesmo instante so acrescentados os nomes das tabelas temporrias que sero criadas antes de fornecer o resultado final da busca, aps a execuo paralela nos diferentes bancos de dados. Na seqncia verifica-se a existncia ou no da clusula WHERE. Caso exista, procura-se inicialmente identificar e separar a(s) clusula(s) de unio das tabelas. Com isso possvel acrescentar outras clusulas que no interfiram na unio das tabelas, como comparaes atravs de operadores relacionais e outras clusulas como AND e OR. Para este processo, utiliza-se o mtodo isWhereAlias. Cumprida esta etapa, inicia-se a criao dos comandos SELECT j particionados com objetivo de se obter apenas um comando para cada tabela. Em paralelo a este processo, utiliza-se o comando para criar a tabela temporria que ser utilizada para execuo e transporte dos dados de cada comando SELECT. Caso no comando SELECT criado existam variveis a serem substitudas (identificadas com o smbolo de interrogao), o comando recebe uma varivel booleana para, antes da submisso da busca no banco de dados, realizar a substituio. No final do mtodo, obtm-se uma coleo com as tabelas, seus respectivos comandos de busca, existncia ou no de parmetros, o comando de criao da tabela temporria e, quando for o caso, a clusula de unio entre as tabelas envolvidas na busca.

6.1.3 Vinculao dos recursos com as tabelas


O mtodo checkDataResources recebe como parmetros as tabelas, os recursos e a URL que fazem parte da busca.

89

Para cada uma das tabelas envolvidas na busca, identificam-se quais bancos de dados a possui. Para isto realizada uma busca simples no dicionrio de dados de cada banco de dados. A ltima verso da OGSA-DAI possui algumas funes que retornam metadados dos bancos de dados disponveis no ambiente, mas ainda com informaes muito precrias. Ao consultar a documentao da verso, nota-se que h uma inteno do grupo para criar um mecanismo completo de extrao das informaes de metadados nos diversos bancos de dados. Enquanto estas funes no so disponibilizadas pelo ambiente, foi criado um mtodo tableMetadata para realizar a busca das informaes para este sistema no dicionrio de dados de cada banco de dados utilizado. Este mtodo pode ser facilmente adaptado para todos os demais bancos de dados que se utilize na Organizao Virtual. Ao final do mtodo, uma coleo ser retornada com cada uma das tabelas que fazem parte da busca e com os respectivos recursos que permitem sua localizao.

6.1.4 Verificao de Mtricas dos recursos


O mtodo getMetrics recebe a relao de recursos que podem fazer parte da busca e a URL do ambiente. As principais mtricas que podem ser extradas de um banco de dados, conforme mencionado anteriormente, so: memria disponvel (voltil e no voltil), velocidade e disponibilidade do processador e velocidade de rede. Cada banco de dados possui mecanismos prprios para apurar estas mtricas. Como a opo deste trabalho foi utilizar o prprio banco de dados para extrair as mtricas e no utilizar mtricas da Grid Computacional (como MDS) por se acreditar que cada gerenciador dispe de condies mais eficazes para extrair esta informao, criou-se uma tabela em cada um dos gerenciadores de banco de dados para armazenar e facilitar a busca das mtricas. A estrutura desta tabela est no Anexo A deste trabalho. Com base nisso, atribui-se um valor de referncia, o maior valor possvel (quando for o caso) e um peso especfico. Caso o valor de referncia j seja um ndice, como percentual de uso do processador, no h necessidade de especificar o maior valor possvel, visto que este ser 100%. Contudo, a banda de rede pode ter um valor de referncia e ter um valor limite (largura da banda). Este valor de referncia ser transformado em um ndice atravs da frmula: 1 (x/y) onde: x o valor de referncia y o valor limite.

90

Ao se atribuir um peso a cada um dos ndices, pode-se identificar uma mtrica especfica de cada recurso disponvel na Grid. Este ndice calculado atravs do mtodo metric. A vantagem de se utilizar uma tabela para armazenar a mtrica a possibilidade de utilizar recursos do prprio banco de dados, como a criao de gatilhos, para automatizar o processo de atualizao dos dados do servidor. Isso faz com que estes dados reflitam a disponibilidade do banco de dados com maior preciso. Outra vantagem a possibilidade de se utilizar mtricas adequadas a cada tipo de recurso, sem forar uma padronizao que poderia desvirtuar a escolha de um recurso em detrimento de outro. Por exemplo, caso o uso de memria seja mais eficiente em um banco de dados do que em outro, ou haja mecanismos de agilizao de rede, pode-se atribuir um peso maior para um recurso em particular. Esta idia contribui com o conceito de Organizao Virtual, visto que cada membro da comunidade responsvel pela disponibilizao e organizao dos seus prprios recursos. No final do processo, tem-se um ndice que indica a mtrica de cada recurso que pode ser utilizado na busca.

6.1.5 Seleo dos recursos que executaro as buscas


Com base nas informaes capturadas nos processos anteriores possvel realizar a seleo dos recursos mais adequados para realizar as buscas particionadas. No final deste processo tem-se o plano de execuo da busca. Deve-se notar que o algoritmo prev a utilizao de todos os recursos envolvidos na busca. Com isso, a mtrica ser importante para determinar quais bancos de dados sero priorizados na submisso das buscas. Caso o nmero de comandos SELECTs retornados depois do paticionamento (consultas) seja inferior ao nmero de bancos de dados disponveis, somente os bancos com maior mtrica sero utilizados. Caso o nmero de consultas seja superior ao nmero de bancos de dados, todos sero utilizados, sem importar a disponibilidade (mtrica) do banco de dados. 6.1.5.1 Plano de Ordem Parcial (POP) Como a busca est separada na menor unidade possvel de busca (uma nica tabela), inicia-se o processo de planejamento com a utilizao do conceito de Ordem Parcial. Desta forma possvel paralelizar as aes que no possuem dependncia entre elas. Isto o que acontece quando se submete cada uma das buscas em diferentes bancos de dados. Ao final das

91

consultas e com o resultado das linhas recuperadas, possvel unir as aes isoladas para compor o resultado final. O Plano de Execuo ser armazenado em uma coleo com trs colunas: o recurso, o comando e a tabela temporria que dever ser criada. Parte-se da coleo com os recursos que podem atender s buscas. Para cada recurso envolvido na busca onde possvel se executar o mesmo comando, verifica-se qual o recurso com maior disponibilidade (mtrica). O mdulo evita que se concentre todas as buscas em um nico recurso (o de maior disponibilidade) ao forar a troca do recurso utilizado a cada comando. Desta forma, o nmero mnimo que ser obtido na paralelizao da busca ser o mesmo nmero de servidores de banco de dados disponveis. Assim, caso haja uma busca com duas tabelas e apenas dois servidores, cada servidor realizar uma busca, independente da disponibilidade (mtrica). Quando h mais buscas do que recursos disponveis, o algoritmo tende a indicar a busca no recurso que tenha maior disponibilidade. Quando houver mais recursos do que buscas, o sistema ir priorizar os que tiverem melhores mtricas. A figura 6.3 demonstra o algoritmo utilizado. mDistrib= checkDataResources() mMetric = getMetrics() Para cada mDistrib Se Busca Diferente Atualiza Recursos Utilizados Fim-Se Para cada mMetric/Recurso Se (Mtrica do Recurso melhor) e (Recurso no Utilizado) mSubmit <- Recurso Fim-Se Fim-Para Fim-Enquanto
Figura 6.3: Algoritmo POP para elaborar o Plano de Execuo

Baseado no Plano de Execuo, o primeiro algoritmo proposto submete as buscas com base nos recursos disponveis. A figura 6.4 demonstra o algoritmo de submisso.

92

Baseado no Plano de Execuo Para cada Recurso Baseado no Plano de Execuo Para cada Busca Submete Busca Inicia Thread Fim-Para Fim-Para Enquanto Threads em Andamento Fim-Enquanto
Figura 6.4: Algoritmo para Submisso

Com a seqncia de recursos e comandos para execuo, o mdulo submete as buscas a cada um dos recursos atravs de uma atividade de Bulk Load presente no middleware. Foi escolhida esta opo, pois necessrio criar tabelas temporrias para realizar a unio das linhas retornadas em cada um dos comandos submetidos. Esta unio acontecer no recurso mais disponvel (melhor mtrica). O processo de bulk load assume a responsabilidade de executar a busca e alimentar as tabelas temporrias. Para isso utilizam-se os mtodos DTOutputStream e performBulkLoad. Antes de submeter as buscas, eventuais parmetros so associados aos comandos para que estes possam filtrar as linhas que devero ser retornadas. No final deste processo as tabelas temporrias esto alimentadas com o resultado das buscas em cada um dos gerenciadores de banco de dados. 6.1.5.2 Plano de Ordem Parcial com Restrio de Recursos e Monitoramento Partindo do Plano de Ordem Parcial j estabelecido, muda-se o foco da atribuio para as buscas e no para os recursos. Com isso enquanto houver recursos disponveis, submete-se as buscas em paralelo. Quando o nmero de recursos se esgotar, o mdulo aguarda a liberao de qualquer recurso para ento submeter ao recurso disponvel. Isso implica, na maior parte das vezes, em uma mudana no plano original estabelecido. O motivo da mudana no plano que a submisso original obedece ao critrio da disponibilidade do recurso (mtrica) o que no quer dizer que o recurso mais disponvel ir encerrar a consulta mais rapidamente. Outros fatores influenciam o tempo de durao da busca: volume de dados analisados, transferncia de dados entre os bancos de dados, etc. A figura 6.5 demonstra o algoritmo utilizado.

93

Baseado no Plano de Execuo Enquanto houver Busca no Plano Para cada n disponvel Monta Busca para recurso disponvel Submete Busca Inicia Thread Retira Busca do Plano de Execuo Indica n como no disponvel Fim-Para Enquanto Threads em Andamento Fim-Enquanto Indica n como disponvel Fim-Enquanto
Figura 6.5: Submisso de buscas com Algoritmo POP com Restrio de Recursos e Monitoramento

A forma de acompanhamento da submisso, criao de tabelas temporrias, unio de resultados so realizados da mesma forma que no algoritmo anterior.

6.1.6 Unio das buscas e apresentao do resultado


Com as tabelas temporrias criadas e disponveis no recurso de melhor mtrica, o comando completo definido pelo usurio no incio do processo submetido. O resultado da busca fica disponibilizado para tratamento pelo ambiente ou pelo usurio final. No final do processo as tabelas temporrias so excludas do gerenciador de banco de dados.

6.2 Bases de Dados utilizadas


As bases de dados de testes foram: Base de dados exemplo que vem com o middleware Base de dados relativamente complexa de uma seqncia de DNA com quatro tabelas

6.2.1 Base de dados Exemplo do OGSA-DAI


Inicialmente composto por uma nica tabela LITTLEBLACKBOOK com um milho de linhas, acrescentou-se uma segunda tabela DEPEND com cerca de quinhentas linhas. Ambas tabelas continham uma coluna em comum (ID). As duas tabelas estavam disponveis no banco de dados Oracle e somente a tabela LITTLEBLACKBOOK estava disponvel no MySQL. Por no conter dados complexos e no haver um rigor de exigncia na qualidade dos dados extrados, esta base foi utilizada na fase de testes iniciais [OGSA-DAI, 2006]. As estruturas das tabelas esto no Anexo B deste trabalho.

94

6.2.2 Bio-informtica
A escolha deste modelo deveu-se complexidade e volume dos dados armazenados em uma seqncia de DNAs. H um grande nmero de atributos envolvidos em cada uma das tabelas o que representa um desafio de anlise do resultado dos dados, conforme pode ser observado no Anexo B deste trabalho. Os dados foram extrados do trabalho de Shipp [Shipp et al, 2002] e podem ser obtidos atravs de um arquivo-texto e uma planilha Excel na Internet. O arquivo-texto contm valores de expresses genticas. So 7.129 atributos e 58 modelos. Como h muitos atributos, estes so representados como linhas e os modelos como colunas. Na planilha Excel h informaes clnicas dos modelos de Linfoma utilizados no estudo. H trs tabelas bsicas: LYMPH_OUTCOME, LYMPH_EXP e LYMPH_MAP. A primeira armazena o resultado de dados clnicos. Um resultado positivo indicado que houve cura e o negativo que no houve. Nesta tabela h 58 linhas. A segunda tabela armazena valores genticos de expresso para cada modelo e tem origem no processamento das seqncias de DNA. Nesta tabela h 7.129 linhas. A terceira armazena as descries da identificao dos genes criadas na importao dos dados. Nesta tabela h 7.129 linhas. A quarta tabela do modelo (LYMPH_TEMP) a que possui o maior nmero de linhas (413.482) e resultado do cruzamento dos dados das tabelas anteriores para armazenar os dados originais da expresso gentica. Como h ligao entre cada uma das tabelas, esta base de dados foi escolhida por permitir que se possa testar as buscas com duas, trs ou quatro tabelas simultaneamente.

95

Parte III: Resultados 7 Testes Realizados


Instalou-se o middleware OGSA-DAI verso WSI-2.2 no TomCat 5.0.28. A infra-estrutura de instalao foi: um servidor Pentium IV, 3.2 Ghz HT, com 1 GB de memria RAM e 80 GB de disco rgido. O sistema operacional Windows XP Professional, service pack 2. Inicialmente foi utilizado um sistema gerenciador de banco de dados Oracle 10g (10.0.2) e o sistema gerenciador de banco de dados MySQL 5.0. Um segundo servidor, Pentim IV, 1.1 Ghz, com 750MB de memria RAM e 80 GB de disco rgido e com Windows XP Professional instalado foi utilizado. Neste servidor foi instalado um banco de dados Oracle 10g (10.2.0). Todos foram instalados no mesmo servidor e disponibilizados ao middleware atravs dos mecanismos especificados no ambiente. O roteiro de instalao do ambiente consta no Anexo C deste trabalho. Para descrever os resultados alcanados com os testes, as duas fases de teste foram separadas de acordo com a base de dados utilizada, quais sejam: Base de Dados OGSA-DAI Base de Dados Bio-informtica A mtrica dos recursos, para efeitos de testes, foi estabelecida com os valores apresentados nas tabelas 6.5, 6.6 e 6.7: Servidor 1: Oracle (orclCPoderoso):

Figura 6.6:Mtrica do banco de dados orclCPoderoso.

Como resultado, a mtrica calculada para este recurso foi 0.8744554811491747. MySQL (MySQLCPoderoso):

96

Figura 6.7:Mtrica do banco de dados MySQLCPoderoso.

Como resultado, a mtrica calculada para este recurso foi 0.9806323399999999. Servidor 2: Oracle (orclFamilia):

Figura 6.8:Mtrica do banco de dados orclFamilia.

Como resultado, a mtrica calculada para este recurso foi 0.8706755500000001.

7.1 Base de dados OGSA-DAI


O ambiente de teste limitou-se aos servidores onde foi instalado o OGSA-DAI , de acordo com a descrio anterior. Aps a execuo do sistema com a utilizao dos dados desta base, os resultados foram obtidos a partir das seguintes buscas:
i) select a.id, a.name from littleblackbook a ii) select a.id, a.name from littleblackbook a where a.id>=? and a.id<? iii) select a.id, a.name, b.lbb_id, b.name from littleblackbook a, depend b where a.id = b.lbb_id and a.id>=? and a.id<?

A primeira consulta teve o objetivo de checar o retorno das linhas de dados, sem haver preocupao com a paralelizao ou distribuio da consulta. O resultado obtido foi de acordo com o esperado, visto que as linhas deveriam ser retornadas como uma busca usual em bancos de dados. A segunda consulta procurou incluir e testar a submisso de comandos de busca com parmetros. O padro OGSA-DAI utiliza o smbolo de interrogao para indicar quais parmetros dever ser submetido ao banco de dados. Mais uma vez, os resultados estiveram dentro do esperado, visto que o ambiente conseguiu identificar o momento da substituio dos parmetros e retornou somente as linhas dentro do intervalo especificado. A terceira consulta, por envolver duas tabelas, permitiu observar o comportamento do mdulo frente a uma situao de paralelizao de busca. No primeiro teste desabilitou-se um dos dois bancos de dados disponveis na grid. Com isso o escalonador no teve alternativa seno utilizar o nico banco de dados disponvel. O sistema no foi capaz, contudo, de

97

submeter a consulta como era originalmente. A busca foi dividida em dois comandos SELECT, um para cada tabela, e submeteu ambas ao mesmo banco de dados. 7.1.1 Resultado do Planejamento na terceira consulta Este teste possibilitou analisar o desempenho do algoritmo de planejamento. Neste teste foi habilitado o segundo banco de dados, portanto a busca poderia ser submetida aos dois recursos disponveis na grid. Em uma primeira etapa a tabela LITTLEBLACKBOOK estava presente em ambos bancos de dados e a tabela DEPEND estava somente no banco de dados Oracle. Durante a execuo da busca, o planejador utilizou para o primeiro comando de busca o MySQL, por possuir melhor mtrica, e o Oracle para o segundo comando. Quando se acrescentou o terceiro recurso, no houve modificao no plano de submisso, visto que o terceiro recurso possui uma mtrica inferior s dos demais recursos. Foi possvel constatar que o mdulo buscou o tabela existente no MySQL, mesmo quando a mtrica no era favorvel. Isso se deve ao fato de que o algoritmo procura dividir a busca entre diversos recursos (maximizao do uso dos recursos atravs da paralelizao da busca). Como uma das tabelas no estava presente em todos os recursos, esta tabela teria que ser localizada no outro gerenciador de banco de dados. A busca da nica tabela presente nos dois bancos de dados era submetida ao MySQL e a outra no Oracle. Ao se colocar a tabela DEPEND em ambos os recursos, o resultado do planejamento priorizou o MySQL para a primeira busca e em seguida o Oracle, por ser o servidor com menor disponibilidade.

7.2 Base de dados Bio-informtica


O ambiente de teste tambm limitou-se aos servidores onde foi instalado o OGSADAI e os bancos de dados descritos anteriormente. As buscas utilizadas para os testes foram:
iv) select a.gene_id, a.accession, b.gene_id, b.sample_id from lymph_map a, lymph_exp b where a.gene_id = b.gene_id v) select a.gene_id, a.accession, b.gene_id, b.sample_id, c.sample_id, c.status from lymph_map a, lymph_exp b, lymph_outcome c where

a.gene_id = b.gene_id and b.sample_id = c.sample_id vi) select b.gene_id, b.sample_id, c.sample_id, c.status from lymph_exp b, lymph_outcome c where b.sample_id = c.sample_id

98

vii) select a.gene_id, a.accession, d.gene_id, d.dlbc1 from lymph_map a, lymph_temp d where a.gene_id = d.gene_id viii) select a.gene_id, a.accession, b.gene_id, b.sample_id, d.dlbc1 from lymph_map a, lymph_exp b, lymph_temp d where a.gene_id = b.gene_id and a.gene_id = d.gene_id ix) select a.gene_id, a.accession, b.gene_id, b.sample_id, c.sample_id, c.status, d.dlbc1 from lymph_map a, lymph_exp b, lymph_outcome c, lymph_temp d where a.gene_id = b.gene_id and b.sample_id =

c.sample_id and a.gene_id = d.gene_id

Todas as buscas tiveram o objetivo de verificar o comportamento do planejamento que foi realizado pelo mdulo. Para isso utilizou-se apenas consultas que envolvessem unio regular de tabelas (joins). Os testes dividiram-se em duas etapas: Dois recursos habilitados (banco de dados Oracle e MySQL do servidor principal) Trs recursos habilitados (alm dos anteriores o banco de dados Oracle do outro servidor) 7.2.1 Resultado do Planejamento com dois recursos em POP Como se pode notar, os planejador se comportou conforme esperado, visto que sempre que houve o mesmo nmero de recursos e de buscas, todos foram utilizados. Sempre que havia mais buscas do que recursos, aquele que possua melhor mtrica foi utilizado no Plano. Todos os planos foram submetidos em paralelo em cada recurso disponvel e os tempos utilizados so os fornecidos pela prpria linguagem durante a execuo do cdigo. Para a busca (i), os resultados foram:
Plano Original: MySQLCPoderoso SELECT A.GENE_ID,A.ACCESSION FROM LYMPH_MAP A orclCPoderoso SELECT B.GENE_ID,B.SAMPLE_ID FROM LYMPH_EXP B Incio: 12:22:46 Executando Query em Paralelo Executando (MySQLCPoderoso) Executando (orclCPoderoso) Executada Query em Paralelo Resposta: COMPLETO Trmino: 12:32:56

Para a busca (ii), os resultados foram:


Plano Original: MySQLCPoderoso SELECT A.GENE_ID,A.ACCESSION FROM LYMPH_MAP A orclCPoderoso SELECT B.GENE_ID,B.SAMPLE_ID FROM LYMPH_EXP B

99

MySQLCPoderoso SELECT C.SAMPLE_ID,C.STATUS FROM LYMPH_OUTCOME C Incio: 12:09:43 Executando Query em Paralelo Executando (MySQLCPoderoso) Executando (orclCPoderoso) Executando (MySQLCPoderoso) Executada Query em Paralelo Resposta: COMPLETO Trmino: 12:19:45

Para a busca (iii), os resultados foram:


Plano Original: MySQLCPoderoso SELECT B.GENE_ID,B.SAMPLE_ID FROM LYMPH_EXP B orclCPoderoso SELECT C.SAMPLE_ID,C.STATUS FROM LYMPH_OUTCOME C Incio: 12:45:11 Executando Query em Paralelo Executando (MySQLCPoderoso) Executando (orclCPoderoso) Executada Query em Paralelo Resposta: COMPLETO Trmino: 12:55:18

Para a busca (iv), os resultados foram:


Plano Original: MySQLCPoderoso SELECT A.GENE_ID,A.ACCESSION FROM LYMPH_MAP A orclCPoderoso SELECT D.GENE_ID,D.DLBC1 FROM LYMPH_TEMP D Incio: 13:43:53 Executando Query em Paralelo Executando (MySQLCPoderoso) Executando (orclCPoderoso) Executada Query em Paralelo Resposta: COMPLETO Trmino: 13:44:14

Para a busca (v), os resultados foram:


Plano Original: MySQLCPoderoso SELECT A.GENE_ID,A.SAMPLE_ID FROM LYMPH_EXP A orclCPoderoso SELECT B.GENE_ID,B.ACCESSION FROM LYMPH_MAP B MySQLCPoderoso SELECT D.DLBC1,D.GENE_ID FROM LYMPH_TEMP D Incio: 14:46:06

100

Executando Query em Paralelo Executando (orclCPoderoso) Executando (MySQLCPoderoso) Executando (MySQLCPoderoso) Executada Query em Paralelo Resposta: COMPLETO Trmino: 14:56:14

Para a busca (vi), os resultados foram:


Plano Original: MySQLCPoderoso SELECT A.GENE_ID,A.ACCESSION FROM LYMPH_MAP A orclCPoderoso SELECT B.GENE_ID,B.SAMPLE_ID FROM LYMPH_EXP B MySQLCPoderoso SELECT C.SAMPLE_ID,C.STATUS FROM LYMPH_OUTCOME C orclCPoderoso SELECT D.DLBC1 FROM LYMPH_TEMP D Incio: 15:03:38 Executando Query em Paralelo Executando (orclCPoderoso) Executando (orclCPoderoso) Executando (MySQLCPoderoso) Executando (MySQLCPoderoso) Executada Query em Paralelo Resposta: COMPLETO Trmino: 15:13:50

7.2.2 Resultado do Planejamento com dois recursos em POP com Restrio de Recursos e Monitoramento O algoritmo se comportou como o algoritmo anterior, mas o Plano de execuo no foi submetido imediatamente. Optou-se por realizar o teste com duas tabelas uma nica vez, visto que no acrescentaria muito para esta pesquisa. Como se pode constatar no tempo de execuo da busca (i), o tempo de execuo foi praticamente o mesmo. Isso se deve ao fato de a busca ser realizada em paralelo em dois diferentes bancos de dados em qualquer uma das situaes. Como foi realizado o monitoramento dos recursos, pode-se notar que nas buscas (ii), (v) e (vi) os resultados foram consideravelmente menores. Nota-se que o Plano de Execuo sofreu alteraes durante o processamento das consultas (v) e (vi). Isso se deveu ao planejador inicialmente ter a informao somente sobre quais so os recursos disponveis e suas respectivas mtricas. Conforme o recurso encerrava seu trabalho, ele estava disponvel para realizar nova busca, independente da mtrica do recurso.

101

Outro fato observador foi que, quanto maior o volume de linhas processadas pelo recurso e quanto mais cedo a busca for submetida, maior o ganho no tempo de processamento. Isso pode ser notado na busca (v) em relao busca (vi). Todos os planos foram submetidos em paralelo em cada recurso disponvel e os tempos utilizados so os fornecidos pela prpria linguagem durante a execuo do cdigo. Para a busca (i), os resultados foram:
Plano Original: MySQLCPoderoso SELECT B.GENE_ID,B.ACCESSION FROM LYMPH_MAP B orclCPoderoso SELECT D.GENE_ID,D.DLBC1 FROM LYMPH_TEMP D Incio: 15:30:34 Executando MySQLCPoderoso Executando orclCPoderoso Executando Query em Paralelo Executada Query em Paralelo Resposta: COMPLETO Trmino: 15:40:43

Para a busca (ii), os resultados foram:


Plano Original: MySQLCPoderoso SELECT A.GENE_ID,A.SAMPLE_ID FROM LYMPH_EXP A orclCPoderoso SELECT B.GENE_ID,B.ACCESSION FROM LYMPH_MAP B MySQLCPoderoso SELECT C.SAMPLE_ID,C.STATUS FROM LYMPH_OUTCOME C Trmino: 16:29:21 Executando orclCPoderoso( LYMPH_EXP ) Executando MySQLCPoderoso( LYMPH_MAP ) Encerrei recurso MySQLCPoderoso Executando MySQLCPoderoso( LYMPH_OUTCOME ) Encerrei recurso MySQLCPoderoso Executando Query em Paralelo Executada Query em Paralelo Resposta: COMPLETO Trmino: 16:39:01

Para a busca (v), os resultados foram:


Plano Original: MySQLCPoderoso SELECT B.GENE_ID,B.ACCESSION FROM LYMPH_MAP B orclCPoderoso SELECT A.GENE_ID,A.SAMPLE_ID FROM LYMPH_EXP A MySQLCPoderoso SELECT D.DLBC1,D.GENE_ID FROM LYMPH_TEMP D Incio: 15:55:08

102

Executando orclCPoderoso( LYMPH_EXP ) Executando MySQLCPoderoso( LYMPH_MAP ) Encerrei recurso MySQLCPoderoso Executando MySQLCPoderoso( LYMPH_TEMP ) Encerrei recurso MySQLCPoderoso Executando Query em Paralelo Executada Query em Paralelo Resposta: COMPLETO Trmino: 16:04:06

Para a busca (vi), os resultados foram:


Plano Original: MySQLCPoderoso SELECT B.GENE_ID,B.SAMPLE_ID FROM LYMPH_EXP B orclCPoderoso SELECT A.GENE_ID,A.ACCESSION FROM LYMPH_MAP A MySQLCPoderoso SELECT C.SAMPLE_ID,C.STATUS FROM LYMPH_OUTCOME C orclCPoderoso SELECT D.DLBC1 FROM LYMPH_TEMP D Incio: 16:17:53 Executando orclCPoderoso( LYMPH_MAP ) Executando MySQLCPoderoso( LYMPH_EXP ) Encerrei recurso orclCPoderoso Executando orclCPoderoso( LYMPH_OUTCOME ) Encerrei recurso orclCPoderoso Executando orclCPoderoso( LYMPH_TEMP ) Encerrei recurso orclCPoderoso Executando Query em Paralelo Executada Query em Paralelo Resposta: COMPLETO Trmino: 16:27:37

7.2.3 Resultado do Planejamento com trs recursos em POP com Restrio de Recursos e Monitoramento O algoritmo se comportou como esperado quando se adicionou mais um recurso. Algumas consideraes importantes dizem respeito no utilizao do recurso de menor mtrica quando havia menos buscas do que recursos (i). Por outro lado, utilizou todos os recursos quando havia trs consultas (ii) e (v). Para estas buscas no houve um ganho significativo no desempenho porque havia uma grande disparidade entre o nmero de linhas das tabelas. Como h uma grade tabela e as outras so menores, o tempo total da busca gira em torno do tempo da maior busca.

103

Contudo, para a consulta (vi) pode-se notar que houve um ganho ao se esperar pelo recurso mais disponvel para submeter a ltima busca. Neste mesmo teste pode-se notar uma alterao no plano de execuo que normalmente no seria o mais provvel. Como o recurso com menor mtrica encerrou o trabalho mais rapidamente, ele recebeu a responsabilidade de processar as linhas da ltima tabela da busca. Para a busca (i), os resultados foram:
Plano Original: MySQLCPoderoso SELECT A.GENE_ID,A.SAMPLE_ID FROM LYMPH_EXP A orclCPoderoso SELECT B.GENE_ID,B.ACCESSION FROM LYMPH_MAP B Incio: 13:42:37 Executando MySQLCPoderoso( LYMPH_EXP ) Executando orclCPoderoso( LYMPH_MAP ) Executando Query em Paralelo Executada Query em Paralelo Resposta: COMPLETO Trmino: 13:52:45

Para a busca (ii), os resultados foram:


Plano Original: MySQLCPoderoso SELECT A.GENE_ID,A.SAMPLE_ID FROM LYMPH_EXP A orclCPoderoso SELECT B.GENE_ID,B.ACCESSION FROM LYMPH_MAP B orclFamilia SELECT C.SAMPLE_ID,C.STATUS FROM LYMPH_OUTCOME C Incio: 13:59:18 Executando MySQLCPoderoso( LYMPH_EXP ) Executando orclCPoderoso( LYMPH_MAP ) Executando orclFamilia( LYMPH_OUTCOME ) Executando Query em Paralelo Executada Query em Paralelo Resposta: COMPLETO Trmino: 14:08:56

Para a busca (v), os resultados foram:


Plano Original: MySQLCPoderoso SELECT A.GENE_ID,A.SAMPLE_ID FROM LYMPH_EXP A orclCPoderoso SELECT B.GENE_ID,B.ACCESSION FROM LYMPH_MAP B orclFamilia SELECT D.DLBC1,D.GENE_ID FROM LYMPH_TEMP D Incio: 18:14:20 Executando MySQLCPoderoso( LYMPH_EXP ) Executando orclCPoderoso( LYMPH_MAP )

104

Executando orclFamilia( LYMPH_TEMP ) Executando Query em Paralelo Executada Query em Paralelo Resposta: COMPLETO Trmino: 18:23:17

Para a busca (vi), os resultados foram:


Plano Original: MySQLCPoderoso SELECT A.GENE_ID,A.ACCESSION FROM LYMPH_MAP A orclCPoderoso SELECT B.GENE_ID,B.SAMPLE_ID FROM LYMPH_EXP B orclFamilia SELECT C.SAMPLE_ID,C.STATUS FROM LYMPH_OUTCOME C MySQLCPoderoso SELECT D.DLBC1 FROM LYMPH_TEMP D Incio: 18:44:09 Executando MySQLCPoderoso( LYMPH_MAP ) Executando orclCPoderoso( LYMPH_EXP ) Executando orclFamilia( LYMPH_OUTCOME ) Encerrei orclFamilia Executando orclFamilia( LYMPH_TEMP ) Executando Query em Paralelo Executada Query em Paralelo Resposta: COMPLETO Trmino: 18:53:46

Os resultados comparativos das buscas, utilizando dois recursos com o primeiro algoritmo e dois e trs recursos com o segundo algoritmo esto comparados na figura 7.1.

105

T empo de Consulta
0:10:22 0:10:05 0:09:48 0:09:30 Tempo 0:09:13 0:08:56 0:08:38 0:08:21 0:08:04 Dois Recursos, Algoritmo Um Dois Recursos, Algoritmo Dois Trs Recursos, Algoritmo Dois i (2 t) 0:10:10 0:10:09 0:10:08 ii (3 t) 0:10:02 0:09:40 0:09:38 v (3 t) 0:10:08 0:08:58 0:08:57 vi (4 t) 0:10:12 0:09:44 0:09:37 Dois Recursos, Algoritmo Um Dois Recursos, Algoritmo Dois Trs Recursos, Algoritmo Dois

Consulta

Figura 7.1: Comparativo da Implementao dos Algoritmos

Fica claro que o segundo algoritmo possui um desempenho melhor em todas as situaes e apresenta melhores resultados conforme aumentam o nmero de recursos envolvidos na busca. Isto pode ser comprovado pela figura 7.2. Na figura 7.2 pode-se notar que houve um ganho percentual em todas as consultas analisadas quando se comparou a utilizao de trs recursos com o segundo algoritmo com dois recursos no primeiro algoritmo. O ganho no foi maior na busca com quatro tabelas porque a quarta tabela da busca possui poucas linhas (vi). Na consulta (v) as tabelas pesquisadas foram as que possuem maior nmero de linhas, isso fez com que o ganho fosse maior do que na busca (ii), mesmo com o mesmo nmero de tabelas.

106

Ganho Percentual com Trs Recursos nos Dois Algoritmos

12,00% 10,00% 8,00% 6,00% 4,00% 2,00% 0,00% i (2 t) ii (3 t) Consulta Percentual v (3 t) vi (4 t) Percentual

Figura 7.2: Ganho percentual entre as buscas com trs recursos no segundo algoritmo e dois recursos no primeiro algoritmo

107

8 Concluso
O trabalho apresentou a comparao entre os algoritmos propostos e demonstrou a viabilidade do uso de qualquer um dos dois, com uma tendncia a utilizao do segundo algoritmo para sistemas que utilizem um maior nmero de buscas e recursos. Os testes mostraram que as Grids Computacionais so uma alternativa para otimizar o uso de recursos em um ambiente distribudo. Os Bancos de Dados, por serem importantes recursos computacionais, comeam a serem utilizados, ainda que de maneira insipiente, na Grid. Com novas pesquisas envolvendo Bancos de Dados e Grids, ser possvel melhorar o atendimento aos processos que envolvem estes recursos. Tanto o meio acadmico quanto o empresarial poder se beneficiar da unio destas tecnologias. Atualmente possvel utilizar o OGSA-DAI, middleware desenvolvido para prover os servios de banco de dados, que funciona agregado ao Globus, o principal produto de Grid Computacional. Apesar dos esforos para atender s demandas, ainda h muitas atividades de banco de dados que no so realizadas. Isso abre um campo enorme para aprimorar o produto e realizar novas pesquisas. O OGSA-DQP um destes produtos. Ele permite realizar buscas particionadas em banco de dados com a utilizao do OGSA-DAI. Contudo h diversas limitaes no ambiente proposto. Novas prticas puderam ser testadas neste trabalho e mostraram que se pode utilizar a mesma infra-estrutura do OGSADAI, com pequenas alteraes, e alcanar resultados satisfatrios. O objetivo deste trabalho foi o de criar um sistema que interceptasse as requisies do usurio e, aps verificar quais recursos h disponveis no ambiente, subdividir as buscas complexas em buscas particionadas, mais simples. O plano de execuo deveria prever a paralelizao de cada uma das buscas particionadas. Foi necessrio criar um interpretador de comandos SELECT (parse) para realizar o particionamento da busca. Como a arquitetura utilizada na Grid Orientada a Servios, podese utilizar qualquer outro particionador que atenda aos requisitos do mdulo, sem prejuzo do algoritmo proposto. Esta pesquisa demonstrou a aplicao de tcnicas de planejamento que envolve o campo da Inteligncia Artificial. O objetivo de utilizar a Inteligncia Artificial foi achar a melhor soluo possvel dentro do espao de estados disponvel, neste caso representado pelos gerenciadores de bancos de dados. A partir dos conceitos de Planejamento de Ordem Parcial e depois abrindo mo da Restrio de Recursos e Monitoramento da Submisso do Plano de

108

Execuo, pode-se implementar um algoritmo que maximiza o uso dos recursos disponveis na Organizao Virtual. Este trabalho trouxe a contribuio de levantar algumas consideraes sobre a utilizao de mtricas especficas para bancos de dados. As mtricas so importantes heursticas que podem ser utilizadas para tomar a melhor deciso no momento da criao do plano de execuo. Foi dado um enfoque diferente do utilizado na Grid Computacional que a utilizao de um servio de informaes sobre o volume de processamento e disponibilidade de armazenamento (MDS). Como os bancos de dados possuem uma caracterstica prpria, esta caracterstica foi explorada para propor uma alternativa ao MDS. De qualquer forma, mesmo que se opte por utilizar o MDS, o algoritmo no perde suas caractersticas. A mtrica utilizada pode ser substituda pelo MDS sem prejuzo do planejamento proposto. Como foi utilizado o padro da OGSA-DAI, pode-se utilizar todos os bancos de dados que estiverem disponveis na Grid e no h limitao no uso de OR ou AND na clusula WHERE. Com o teste realizado nos dois algoritmos implementados, observou-se que a utilizao do Plano de Ordem Parcial adequada para realizar o plano de execuo das buscas. Como em um ambiente de Grid h restrio no uso de recursos, o monitoramento mostrou-se satisfatrio para melhorar o plano de execuo criado inicialmente. Com isso, o algoritmo no s maximizou o uso dos recursos como tambm implementou o plano da melhor maneira possvel. Isso faz com que uma das premissas do planejamento em Grid fosse atendida: acompanhamento dos servios submetidos ao ambiente.

109

9 Trabalhos Futuros
O presente trabalho sugere diversas opes de prosseguimento. A seguir lista-se uma srie de elementos que podem ser explorados por pesquisadores: Criar um repositrio para manter dados histricos de utilizao dos recursos. Isso ir colaborar com a heurstica do planejador e permitir criar rplicas de dados para as informaes mais solicitadas. Criar um planejador para manter um repositrio com o resultado do planejamento. Criar um repositrio do planejador para manter o histrico de utilizao dos recursos. Desta forma ser possvel refinar o processo de seleo de recursos e ajustar o tempo de processamento das aes uma vez que possvel comparar o valor indicado pelo gerenciador de banco de dados com o tempo efetivamente despendido, conforme figura 8.1.

Recursos

Necessidades do Usurio

Repositrio

Planejador

OGSA-DAI

Figura 8.1: Proposta de Repositrio de Planejamento

Criar um metadados de todos os recursos disponveis na OGSA-DAI. Permitir que se trabalhe com parte das linhas das tabelas replicadas. Estabelecer uma ontologia especfica para descoberta e localizao de gerenciadores de banco de dados. Aprimorar a heurstica atravs da identificao da carga de trabalho atual e projeo da carga futura de utilizao do banco de dados.

110

Criar um agente de planejamento contnuo. Ser necessrio criar uma base de conhecimento e leitura constante do ambiente atual. Criar um sistema multiagente que permita agir de maneira cooperativa a partir do plano proposto. Estabelecer um Planejamento Condicional, onde se possa submeter as consultas a um recurso sem utilizar o artifcio de criar tabelas temporrias. Desta forma, pode-se testar a hiptese de que, ao no se criar tabelas temporrias no recurso que ser responsvel pela unio dos dados para apresentao final, a consulta ser executada mais rapidamente. Deve ser possvel checar a quantidade de consultas que podem obter este benefcio, pois, visto que pelo menos uma tabela estar obrigatoriamente no recurso que unir as consultas, pode ser vivel submeter no mnimo duas tabelas a este recurso. Isso far com que apenas a partir de trs tabelas seja utilizado a grid computacional. Com estas implementaes, ser possvel realizar o planejamento de consultas de

forma mais completa e prxima das necessidades da rea acadmica e profissional, alm de complementar os servios disponibilizados pelo OGSA-DAI.

111

10 Referncias
[Alchemi, 2005] Alchemi. http://www.alchemi.net. Disponvel em outubro de 2005. [Alpdemir, 2003] Alpdemir, M. N.; Mukherjee, A.; Paton, N. W.; Watson, P.; Fernandes, A. A. A.; Gounaris, A.; Smith, J. Service-Based Distributed Querying on the Grid. : 2003. [Alpdemir, 2003b] Alpdemir, M. N.; Mukherjee, A.; Paton, N. W.; Watson, P.; Fernandes, A. A. A.; Gounaris, A.; Smith, J.; Sakellariou, R.; Li, Peter. Using OGSA-DQP to Support Scientific Applications for the Grid. : 2003. [Assuno et al, 2004] Assuno, M. D.; Koch, F. e Westphall, C. B.Building Complex Application Using Grid of Agents. Universidade Federal de Santa Catarina: 2004. [Baker et al, 2005] Baker, M.; Apon, A.; Ferner, C. e Brown, J. Emerging Grid Standards. Computer, vol. 38, n 4, pg. 43-50: 2005. [Blythe et al, 2004] Blythe, J.; Deelman, E. e Gil, Y. Planning and Metadata on the Computational Grid. Em: AAAI Spring Symposium on Semantic Web Services: 2004. [Casavant e Kuhl, 1988] Casavant, T. L. e Kuhl, J. G. A Taxonomy of Scheduling in General-Purpose Distributed Computing Systems Em: IEEE Transactions on Software Engineering, v.14, n. 2, p. 141-154: 1988. [Chede, 2005] Chede, C. T. Grid Computing: um novo paradigma computacional. Ed. Brasport. So Paulo: 2005. [Cybok, 2004] Cybok, D. A Grid Workflow Infrastructure Em: Global Grid Forum 2004 Special Issue of Concurrency and Computation: Practice and Experience: 2004. [Dantas, 2005] Dantas, M. Computao Distribuda de Alto Desempenho. Ed. Axcel. Rio de Janeiro: 2005. [Foster, 1999] Foster, I.; Kesselman, C. The Grid: Blueprint for a New Computing Infrastructure. San Francisco, CA, USA: Morgan Kaufmann Publishers: 1999. [Foster, 2001] Foster, I. ; Kesselman, C. e Tuecke, S. The Anatomy of the Grid: Enabling Scalable Virtual Organizations. International J. Supercomputer Applications, vol 15(3): 2001 [Foster, 2002] Foster, I. What is the Grid? A three point checklist. GRIDToday, Daily News And Information For the Global Grid Community: 2002.

112

[Foster, 2003] Foster, I.; Tuecke, S. e Unger, J. OGSA Data Services. Em: http://www.ggf.org: 2003. Acessado em julho de 2005. [Freuder et al., 2005] Freuder, A. N.; Freuder, E. C.; Fourer, R.; Giunchiglia, E.; Goldman, R. P.; Kautz, H.; Rintanen, J. e Tate, A. Constraint Programming. Em: IEEE Intelligent Systems, maro/abril de 2005 p. 62 a 72: 2005. [Gil, 2004] Gil, Y. ; Deelman, E.; Blythe, J.; Kasselman, C. e Tangmunarunkit, H. Artificial Intelligence and Grids: Workflow Planning na Beyond. Em: IEEE Intelligent Systems vol 19, n 1 janeiro/fevereiro de 2004 p. 26 a 33: 2004. [Globus, 2005] Globus Toolkit. http://www.globus.org. Acessado em fevereiro de 2005. [Gounaris et al, 2004] Gounaris, A.; Sakellariou, R.; Paton, Norman W.; Fernandes, Alvaro A. A. Resource Scheduling for Parallel Query Processing on Computational Grids. Em: 5th International Workshop on Grid Computing (GRID 2004). IEEE Computer Society: 2004. [GrADS, 2006] GrADS Grid Analysis and Display System. Disponvel em:

http://grads.iges.org/grads/. Acessado em janeiro de 2006. [GridBus, 2005] GridBus. http://www.gridbus.org. Acessado em outubro de 2005. [IBM, 2005] IBM homepage. http://www.ibm.com. Acessado em fevereiro de 2005. [Legion, 2005] Legion. http://www.cs.virginia.edu/~legion/. Acessado em outubro de 2005. [OGSA, 2006] OGSA homepage. http://www.globus.org/ogsa/. Acessado em janeiro de 2006. [OGSA-DAI, 2006] OGSA-DAI OGSA Data Access and Integration. Em:

http://www.ogsadai.org.uk/. Acessado em janeiro de 2006. [OGSA-DQP, 2006] OGSA-DQP OGSA Database Query Processing. Em

http://www.ogsadai.org.uk/about/ogsa-dqp/. Acessado em janeiro de 2006. OGSI. GGF (2003). Open Grid Services Infrastructure Version 1.0. [Oliveira, 2002] Oliveira, Celso H. P. SQL Curso Prtico. Ed. Novatec. So Paulo: 2002. [Oliveira, 2004] Oliveira, Celso H. P. Tecnologia de Grid Computing utilizando Banco de Dados Oracle. IV CBCOMP. Itaja: 2004. [Oliveira e Almeida, 2005] Oliveira, Celso H. P. e Almeida, Maurcio A. Padro de Banco de Dados Virtual em Grade Computacional. 2 CONTECSI. So Paulo: 2005. [Oracle, 2005] Oracle homepage. http://www.oracle.com. Acessado em fevereiro de 2005.

113

[Pernas e Dantas, 2004] Pernas, A. M. e Dantas, M. A. R. Ontologias Aplicadas Descrio de Recursos em Ambientes de Grid. Revista Infocomp Revista da Cincia da Computao, Volume 3, Nmero 2, pp 26-31: 2004. [Ranganathan e Foster, 2003] Ranganathan, Kavitha e Foster, Ian Simulation Studies of Computation and Data Scheduling Algorithms for Data Grids. Em: Journal of Grid Computing, Volume 1 p. 53-62: 2003. [Russel e Norvig 2004] Russell, Stuard e Norvig, Peter. Inteligncia Artificial. Ed. Campus. Rio de Janeiro: 2004. [Nieto-Santisteban et al, 2004] Nieto-Santisteban, M. A., Szalay, A., Thakar, A. R., OMullane, W. J. When Databases Systems Meet the Grid. Johns Hopkins University Microsoft Research: 2004. [Shipp et al, 2002] Shipp, M. A. et al. Diffuse Large B-Cell Lymphoma Outcome Prediction by Gene Expression Profiling and Supervised Machine Learning. Em: Nature Medicine, vol. 8, n 1, pp 68-74: 2002. [Smith, 2003] Smith, J.; Gounaris, A.; Watson, P.; Paton, N. W.; Fernandes, A. A. A.; Sakellariou, R. Distributed Query Processing on the Grid. Em: The International Journal of High Performance Computing Applications, vol. 17, n 4, pp 353-367: 2003. [SRB, 2005] SRB homepage. http://www.sdsc.edu/srb/. Acessado em fevereiro de 2005. [UDDI, 2005] UDDI. http://www.uddi.org. Acessado em outubro de 2005. [Wang et al, 2005] Wang, F.; Helian, N. Cluster Computing and Grid 2005 Works in Progress: Grid-Oriented Storage. IEEE Distributed Systems Online, vol. 6, n 9: 2005 [Watson, 2002] Watson, P.; Paton, N.; Atkinson, M.; Dialani, V.; Pearson, D. e Storey, T. Database Access and Integration Services on the Grid. Em: Fourth Global Grid Forum (GGF-4): 2002. http://www.nesc.ac.uk/technical_papers/dbtf.pdf. Acessado em julho de 2005. [Watson, 2003] Watson, P. Database and the Grid. Em: Grid Computing: Making the Global Infrastructure a Reality. John Wiley & Sons Inc: 2003.

114

Glossrio
Alchemi: um framework que permite criar um ambiente de grid. API: Application Program Interface um conjunto de rotinas, protocolos e ferramentas para desenvolvimento de sistemas. CBO: Cost-Based Optimizer uma forma de otimizao de buscas presente em alguns SGBDs. Como a otimizao realizada com base no custo da busca, possvel obter resultados melhores do que quando se utiliza a otimizao baseada em regras. Clustering: o processo de distribuio de tarefas entre servidores em um ambiente distribudo com restrio a um nico e limitado ambiente fsico. O controle e gerenciamento so realizados de maneira centralizada. Do ponto de vista do usurio, tido como um nico recurso independente da quantidade de servidores envolvidos. CORBA: Common Object Request Broker Architecture possibilita que haja comunicao entre objetos, independente da linguagem de programao ou sistema operacional utilizados. Com isso a troca de dados entre sistemas distribudos simplificada. muito utilizada em linguagens de programao orientadas a objetos. CP: Constraint Programming consiste na soluo de problemas de satisfao de restries atravs de variveis associadas a um domnio e a um conjunto de restries. um framwork adequado para planejamento que envolve tempo e recursos para identificar resultados qualitativos, quantitativos e aes concorrentes. DAIS: Data Access and Integration Services um grupo do Grid Global Frum que tem trabalhado na definio de requisitos de integrao dos servios de bancos de dados com a grid computacional. Framework: estrutura de sistema que d subsdio para que outro sistema seja desenvolvido. Normalmente um framework inclui uma srie de programas de apoio, bibliotecas de cdigo e fragmentos de cdigo que so utilizados para facilitar o desenvolvimento de sistemas. GDS: Grid Data Service o servio responsvel pela comunicao com o banco de dados. GDSF: Grid Data Service Factory responsvel pela criao de instncias dos servios de dados da grid. GDSR: Grid Data Service Registry responsvel pela publicao dos servios de dados da grid.

115

GDT: Grid Data Transport realiza o transporte de dados entre instncias dos servios de dados da grid. GGF: Global Grid Forum uma comunidade formada por usurios, desenvolvedores e fornecedores que tm pesquisado as melhores prticas e especificaes dos padres para grid computacional. Globus: principal middleware de grid disponvel. um conjunto de ferramentas que realiza o trabalho de conectar e gerenciar recursos distribudos. GRAM: Globus Resource Allocation Manager o responsvel pela interface do Globus com os recursos dos computadores locais. Grid: um grupo de recursos heterogneos, distribudos e integrados que so vistos como um nico recurso computacional sem restrio para rea de atuao. O controle e gerenciamento so realizados de maneira descentralizada. GridBus: tem como objetivo integrar tecnologias que permitam a integrao entre a grid e as empresas de negcios. GridFTP: mecanismo de acesso e transferncia de dados disponvel no Globus. GSF: Grid Service Factory responsvel pela criao de uma nova instncia de servio na grid. GSH: Grid Service Handle o identificador nico de um servio da grid. No contm a localizao e no permite, isoladamente, a comunicao com o servio. GSI: Grid Security Infrastructure o conjunto de servios responsveis pela segurana da grid. Est integrado ao Globus e permite, entre outros, o controle de acesso aos recursos. GSR: Grid Service Reference contm o protocolo e o endereo de cada servio para que se estabelea a comunicao entre os servios da grid. IP: Integer Programming um framework que utiliza funes lineares para achar solues em uma rvore de busca. uma tcnica de Inteligncia Artificial para programao de restries. JDBC: Java Database Connectivity uma API do Java para execuo de comandos SQL em banco de dados. Legion: um sistema que funciona como um computador virtual, com desenvolvimento baseado em orientao a objeto e que tem alta escalabilidade, facilidade de programao e tolerante a falhas. MDS: Metacomputing Directory Services o servio de diretrio da grid que permite a localizao e recuperao das informaes dos recursos disponveis.

116

Middleware: software que conecta duas ou mais aplicaes atravs da leitura e envio de dados necessrios ao processamento. MTBF: Mean Time Between Failures o tempo mdio entre falhas de um componente. uma medida que determina o tempo mdio em horas que se pode confiar em um hard disk ou uma impressora, por exemplo. ODBC: Open Database Connectivity um driver que permite s aplicaes acessar os dados armazenados em SGBD. ODMG: Object Database Management Group foi um grupo que at 2001 estabeleceu padres para acesso a dados sob o paradigma da orientao a objeto. Atualmente o ODBMS (Object Database Management Systems) d continuidade ao projeto. OGSI: Open Grid Services Infrastructure um conjunto de especificaes WSDL que define padres de interface e de aes para a OGSA. OGSA: Open Grid Services Architecture um conjunto de definies, conceitos e tecnologia de servios Web que so construdos sobre a OGSI. OGSA-DAI: Data Access and Integration um projeto para desenvolver um middleware para integrar o banco de dados em uma grid computacional. O mesmo nome dado ao produto que permite a utilizao de recursos de banco de dados relacionais e XML em grid computacional. OGSA-DQP: Data Query Processor um produto criado para realizar o processamento de servios distribudos de busca. baseado no projeto Polar*. OQL: Object Query Language uma linguagem de busca semelhante ao SQL, mas com recursos especiais para tratar objetos complexos, valores e mtodos. P2P: Peer-to-peer um ambiente distribudo onde cada estao da rede tem as mesmas capacidades e responsabilidades. Permite o compartilhamento de recursos entre as estaes. Polar*: um projeto derivado do Polar (Parallel Object-oriented database) que tem pesquisado meios de integrar servios de busca distribuda na grid. SAT: Satisfiability um framework utilizado em Inteligncia Artificial que, atravs de frmulas proposicionais e restrio de variveis, permite a programao atravs de restries. SDE: Service Data Elements descreve os parmetros da virtualizao de dados e as operaes realizadas pelos servios de dados da grid. SDK: Software Development Kit um pacote utilizado para desenvolver sistemas para uma determinada plataforma. formado por uma ou mais APIs.

117

SGBD: Sistema Gerenciador de Banco de Dados um conjunto de programas responsvel pelo armazenamento, alterao e extrao de informaes em um banco de dados. So produtos, comercializados ou no, que utilizam a memria (voltil e no voltil) e a capacidade de processamento dos computadores para gerenciar os dados armazenados. SOA: Service-Oriented Architecture uma arquitetura onde os servios so definidos atravs de uma linguagem de descrio e interfaces que tm como objetivo a realizao de processos de negcio. SOAP: Simple Object Access Protocol um protocolo de troca de mensagens baseado em XML utilizado para transportar informaes de Web Services. SQL: Structured Query Language a linguagem padro para manipulao de dados em banco de dados relacionais e objeto-relacionais. SRB: Storage Resource Broker um middleware cliente-servidor projetado para permitir que as aplicaes pudessem acessar informaes distribudas em recursos heterogneos. SSP: Storage Service Providers so provedores de servios de compartilhamento de armazenamento de dados atravs de VPN. UDDI: Universal Description Discovery and Integration um diretrio distribudo estabelecido na Internet e serve para descoberta de servios. Pode ser comparado a um catlogo telefnico. UML: Unified Modeling Language uma linguagem de uso geral para especificao de sistemas de processamento de dados orientados a objeto. VPN: Virtual Private Network uma rede criada a partir de servios pblicos de comunicao de dados. Prov o acesso controlado e fornece mecanismos de segurana atravs de encriptao do trfego de dados para garantir que somente pessoas autorizadas possam ter acesso rede. XML: eXtensible Markup Language uma linguagem onde os desenvolvedores podem criar suas prprias marcaes. Isso permite que se estabeleam padres, mecanismos de transmisso, interpretao e validao dos dados contidos no arquivo. Web Service: um padro de integrao de aplicaes atravs da Internet. utilizado em aplicaes comerciais para comunicao entre classes de negcios e clientes sem a necessidade de um amplo conhecimento sobre a base tecnolgica utilizada em qualquer um dos ambientes envolvidos. WSDL: Web Services Description Language uma linguagem em formato XML utilizada para descrever a troca de mensagens atravs de Web Services.

118

Anexo A Estrutura da Tabela de Mtrica


Os comandos para criao da tabela de mtrica so:

/** * Tabela de Armazenamento de Mtricas * ORACLE */

create table dai_metric ( metric_id number, metric_name varchar2(100), metric_desc varchar2(200), value number, maxvalue number, match number );

create sequence sqmetric;

/** * Tabela de Armazenamento de Mtricas * MySQL */

create table dai_metric ( metric_id integer auto_increment, metric_name varchar(100), metric_desc varchar(200), value integer, maxvalue integer, match integer );

119

Anexo B Estrutura das Tabelas de Teste


Os comandos para criao das tabelas de teste so:

/** Criao no Banco de Dados Oracle */ DROP TABLE lymph_outcome PURGE; CREATE TABLE lymph_outcome (sample_id VARCHAR2(6), full_ipi surtime status outcome VARCHAR2(20), NUMBER, VARCHAR2(20), VARCHAR2(1));

DROP TABLE lymph_map PURGE; CREATE TABLE lymph_map (gene_id NUMBER,

description CLOB, accession VARCHAR2(4000));

DROP TABLE lymph_temp PURGE; CREATE TABLE lymph_temp (gene_id NUMBER, DLBC1 DLBC2 DLBC3 DLBC4 DLBC5 DLBC6 DLBC7 DLBC8 DLBC9 DLBC10 DLBC11 DLBC12 DLBC13 NUMBER, NUMBER, NUMBER, NUMBER, NUMBER, NUMBER, NUMBER, NUMBER, NUMBER, NUMBER, NUMBER, NUMBER, NUMBER,

120

DLBC14 DLBC15 DLBC16 DLBC17 DLBC18 DLBC19 DLBC20 DLBC21 DLBC22 DLBC23 DLBC24 DLBC25 DLBC26 DLBC27 DLBC28 DLBC29 DLBC30 DLBC31 DLBC32 DLBC33 DLBC34 DLBC35 DLBC36 DLBC37 DLBC38 DLBC39 DLBC40 DLBC41 DLBC42 DLBC43 DLBC44 DLBC45 DLBC46 DLBC47

NUMBER, NUMBER, NUMBER, NUMBER, NUMBER, NUMBER, NUMBER, NUMBER, NUMBER, NUMBER, NUMBER, NUMBER, NUMBER, NUMBER, NUMBER, NUMBER, NUMBER, NUMBER, NUMBER, NUMBER, NUMBER, NUMBER, NUMBER, NUMBER, NUMBER, NUMBER, NUMBER, NUMBER, NUMBER, NUMBER, NUMBER, NUMBER, NUMBER, NUMBER,

121

DLBC48 DLBC49 DLBC50 DLBC51 DLBC52 DLBC53 DLBC54 DLBC55 DLBC56 DLBC57 DLBC58

NUMBER, NUMBER, NUMBER, NUMBER, NUMBER, NUMBER, NUMBER, NUMBER, NUMBER, NUMBER, NUMBER);

/** Criao no Banco de Dados MySQL */

CREATE TABLE IF NOT EXISTS LYMPH_EXP ( GENE_ID INTEGER, SAMPLE_ID VARCHAR(6), GENE_EXP INTEGER ) ;

CREATE VARCHAR(6),

TABLE

IF

NOT

EXISTS

lymph_outcome

(sample_id

full_ipi surtime status outcome

VARCHAR(20), INTEGER, VARCHAR(20), VARCHAR(1));

CREATE TABLE IF NOT EXISTS lymph_map (gene_id description LONGTEXT, accession

INTEGER,

VARCHAR(4000));

CREATE TABLE IF NOT EXISTS lymph_temp (gene_id INTEGER,

122

DLBC1 DLBC2 DLBC3 DLBC4 DLBC5 DLBC6 DLBC7 DLBC8 DLBC9 DLBC10 DLBC11 DLBC12 DLBC13 DLBC14 DLBC15 DLBC16 DLBC17 DLBC18 DLBC19 DLBC20 DLBC21 DLBC22 DLBC23 DLBC24 DLBC25 DLBC26 DLBC27 DLBC28 DLBC29 DLBC30 DLBC31 DLBC32 DLBC33 DLBC34

INTEGER, INTEGER, INTEGER, INTEGER, INTEGER, INTEGER, INTEGER, INTEGER, INTEGER, INTEGER, INTEGER, INTEGER, INTEGER, INTEGER, INTEGER, INTEGER, INTEGER, INTEGER, INTEGER, INTEGER, INTEGER, INTEGER, INTEGER, INTEGER, INTEGER, INTEGER, INTEGER, INTEGER, INTEGER, INTEGER, INTEGER, INTEGER, INTEGER, INTEGER,

123

DLBC35 DLBC36 DLBC37 DLBC38 DLBC39 DLBC40 DLBC41 DLBC42 DLBC43 DLBC44 DLBC45 DLBC46 DLBC47 DLBC48 DLBC49 DLBC50 DLBC51 DLBC52 DLBC53 DLBC54 DLBC55 DLBC56 DLBC57 DLBC58

INTEGER, INTEGER, INTEGER, INTEGER, INTEGER, INTEGER, INTEGER, INTEGER, INTEGER, INTEGER, INTEGER, INTEGER, INTEGER, INTEGER, INTEGER, INTEGER, INTEGER, INTEGER, INTEGER, INTEGER, INTEGER, INTEGER, INTEGER, INTEGER);

124

Anexo C Roteiro de Instalao do Ambiente


Os comandos para instalao do ambiente so: Opo 1: Instalao sob o Globus Toolkit verso 4: ROTEIRO INSTALAO GT4 ====================== - Descompactar GT4 - Adicionar varivel de ambiente GLOBUS_LOCATION (c:\gt4) - Instalar JDK 1.4 ou superior - Instalar ANT - Instalar TOMCAT - Inicializar TOMCAT - Deploy no TOMCAT: c: cd\gt4 ant -f share/globus_wsrf_common/tomcat/tomcat.xml deploySecureTomcat -Dtomcat.dir="c:\Tomcat" # Startup no TOMCAT ant -f share/globus_wsrf_common/tomcat/tomcat.xml war Dwar.file=c:\gt4\gt4.war

- Copiar c:\GT4\LIB\AXIS-URL.JAR para TOMCAT_DIR\COMMON\LIB

ROTEIRO INSTALAO ANT ====================== Descompactar em um diretrio (adicionar varivel de

ambiente ANT_HOME - c:\ant) - Adicionar o BIN no PATH (c:\ant\bin) - JAVA_HOME=c:\java\jdk1.5.0 - Copiar JUNIT.JAR (dentro de JUNIT.ZIP) para f:\ant\lib

ROTEIRO INSTALAO TOMCAT

125

========================= - Instalar em c:\Tomcat - Executvel (admin/admin) - Se no der porta 8080, colocar 8081 - CATALINA_HOME=C:\Tomcat

TESTES: ======= bin\globus-start-container -nosec ant -f share/globus_wsrf_test/runtests.xml runServer Dtests.jar = %GLOBUS_LOCATION%/lib/wsrf_test_interop.jar

ant -f share/globus_wsrf_test/runtests.xml runServer Dtests.jar = %GLOBUS_LOCATION%/lib/wsrf_test_unit.jar DbasicTestsOnly = true Opo 2: Instalao no Axis

INSTALAO DO AXIS ================== - Copiar WEBAPPS/AXIS para C:\Tomcat\WebApps\ - Descompactar (JAF-1_0_2-UPD2.ZIP) activation.jar no C:\Tomcat\WebApps\Axis\WEB-INF\lib - Descompactar (JAVAMAIL-1_3_3_3_01.ZIP) mail.jar no C:\Tomcat\WebApps\Axis\WEB-INF\lib - Descompactar (XML-SECURITY-BIN-1_3_0.ZIP) xmlsec1.3.0.jar no C:\Tomcat\WebApps\Axis\WEB-INF\lib - Copiar C:\Java\jdk1.5.0\lib\TOOLS.JAR para C:\Tomcat\common\lib - Criar variveis de ambiente para AXIS_HOME=c:\axis AXIS_LIB=%AXIS_HOME%\lib AXISCLASSPATH=%AXIS_LIB%\axis.jar;%AXIS_LIB%\jaxrpc.jar;%A XIS_LIB%\commons-discovery-0.2.jar;%AXIS_LIB%\commons-logging-

126

1.0.4.jar;%AXIS_LIB%\activation.jar;%AXIS_LIB%\mail.jar;%AXIS_ LIB%\saaj.jar;%AXIS_LIB%\axis-ant.jar;%AXIS_LIB%\log4j1.2.8.jar;%AXIS_LIB%\log4j-properties.jar;%AXIS_LIB%\wsdl4j1.5.1.jar Para ambos os casos, instalar e testar o OGSA-DAI ( necessrio substituir o diretrio correto, ou wsrf ou axis nos comandos a seguir).

INSTALAO DO OGSA-DAI ====================== - Descompactar binrio fornecido no diretrio cd\ogsadai-axis ant install -Ddai.container = %CATALINA_HOME%

ant deployService -Ddai.container = %CATALINA_HOME% Ddai.service.name = ogsadai/DataService -Ddai.service.config=y

-- RESTART no TOMCAT ant listResourcesClient -Ddai.url = http://localhost:8080/axis/services/ogsadai/DataService

-- Copiar JARs do BD para o diretrio C:\OGSADAI\DRIVERS -- Deploy Resource: ant deployResource -Ddai.container = %CATALINA_HOME% Ddai.resource.file = data.service.resource.propertiesOracle

ant deployResource -Ddai.container = %CATALINA_HOME% Ddai.resource.file = data.service.resource.propertiesMySQL

-- Expose Resource: ant exposeResource -Ddai.container = %CATALINA_HOME% Ddai.service.name = ogsadai/DataService -Ddai.resource.id = orclCPoderoso

127

ant exposeResource -Ddai.container = %CATALINA_HOME% Ddai.service.name = ogsadai/DataService -Ddai.resource.id = MySQLCPoderoso

-- RESTART no TOMCAT ant listResourcesClient -Ddai.url = http://localhost:8080/axis/services/ogsadai/DataService