Utilização de WEB services em um ambiente de grid computacional

UNIVERSIDADE FEDERAL DE SANTA CATARINA

Utilização de Web Services em Ambientes de Grid Computacional

UNIVERSIDADE FEDERAL DE SANTA CATARINA

DEPARTAMENTO DE INFORMÁTICA E ESTATÍSTICA

CURSO DE CIÊNCIAS DA COMPUTAÇÃO

Título: Utilização de Web Services em ambientes de Grid Computacional

Autor: Vitor Hugo Vargas Horewicz Orientador: Mario A. R. Dantas Banca Examinadora:

Carlos B. Westphall José Eduardo De Lucca Palavras-Chave:

DEDICATÓRIA

AGRADECIMENTOS

SUMÁRIO

1 Introdução...9

2 Computação distribuída...11

2.1 Sistemas paralelos ou multiprocessados...11

2.2 Sistemas distribuídos ou multicomputadores...12

2.3 Meta Sistemas e metacomputação...12

2.4 Clusters...13

2.5 Computação peer to peer...14

2.6 Processamento paralelo oportunístico na Internet...15

3 Grids Computacionais e Web Services...16

3.1 O problema do grid e as organizações virtuais...17

3.2 O surgimento das Organizações Virtuais...19

3.3 Tecnologia e arquitetura do grid...20

3.4 Descrição da arquitetura do grid...21

3.4.1 Fabric: interfaces para controle local...22

3.4.2 Conectividade: comunicando-se de forma segura e efetiva...22

3.4.3 Recursos: compartilhando recursos individuais...23

3.4.4 Coletiva: coordenando recursos múltiplos...23

3.4.5 Aplicações...23

3.5 Segurança em ambientes de grid computacional...24

3.6 Comentários sobre JAVA, JINI, CORBA e DCOM...24

3.7 Questões referentes aos ambientes de grid computacional...24

3.8 Web Services...25

4 Projeto e ambiente de desenvolvimento...30

4.1 Especificar uma interface de serviços...30

4.2 Gerar código de suporte ao Grid Service...31

4.3 Implementar o serviço...32

4.4 Distribuir o serviço...32

4.5 Um cliente para testar o Grid Service...34

5 Decisões de projeto...35

5.1 Linguagem JAVA...35

5.2 Sistema operacional GNU/Linux...36

5.3 Middleware Globus Toolkit...36

5.3.1 O que é o Globus Toolkit...37

5.3.2 Componentes do núcleo do Globus Toolkit...38

5.4 Ambiente de desenvolvimento...38

5.4.1 Hardware...38

5.4.2 Software...39

6 Trabalhos futuros e conclusão...40

6.2 Trabalhos futuros...40 6.1 Conclusão...40 ANEXOS...43 Math.java...43 MathService.wsdl...43 MathPortType.java...47 MathServiceGridLocator.java...47 MathService.java...48 MathServiceLocator.java...49 MathServiceSoapBindingStub.java...52 MathImpl.java...56

MathClient.java...61 MathClient2.java...61 Artigo sobre o projeto...62

Índice de tabelas

Tabela 1 - Parâmetros WSDL...33 Tabela 2 - Configuração de hardware utilizada...39 Tabela 3 - Configuração de software utilizada...39

Índice de Figuras

Figura 1 - Camadas da arquitetura de protocolo do Globus...22

Figura 2 - Exemplo de invocação de um web service...26

Figura 3 - Arquitetura de um web service...27

Figura 4 - Componentes de um Grid Service...29

RESUMO

O presente trabalho é uma introdução aos ambientes de Grid Computacional, apresentando-os como uma plataforma para execução de aplicações paralelas.

No primeira parte é feita uma breve análise histórica. Quais fatores levaram ao desenvolvimento das tecnologias abordadas no trabalho e quem pode vir a se beneficiar destas inovações.

Na segunda parte são apresentados conceitos teóricos sobre computação distribuída. Diversos tipos de computação distribuída são analisados para enfatizar as diferenças entre estas soluções e os grids computacionais.

Na terceira parte finalmente é definido o que é um grid computacional. Ilustra-se em que situações pode ser empregado, especificando “o problema do grid”. A tecnologia envolvida e a arquitetura desses ambientes também é analisada. Na conclusão desta parte os aspectos de segurança, comparações com outras tecnologias de computação distribuída e os equívocos resultantes da ignorância dos conceitos são analisados.

A seguir, na quarta parte, é mostrado o que são os Web Services e o seu papel neste novo paradigma de computação distribuída.

A quinta parte apresenta um roteiro para o desenvolvimento de aplicações para ambientes de grid computacional, os Grid Services, com referências aos módulos da aplicação exemplo desenvolvida para o trabalho.

Na sétima parte são listadas as decisões de projeto, o que motivou na escolha de determinada plataforma de software para a confecção deste trabalho.

Na oitava parte as especificações técnicas de equipamentos e software são listadas.

Conclui-se o trabalho com os rumos que podem ser seguidos para projetos futuros e é feita uma avaliação da situação atual da pesquisa e emprego da tecnolgia em ciência, engenharia e indústria.

1 Introdução

A partir da década de 1980 iniciou-se um processo desencadeado pela popularização dos chamados computadores pessoais. A computação tornou-se onipresente, passando a compor o ambiente de escritórios e residências. Ao mesmo tempo em laboratórios e universidades uma outra revolução tomava lugar, a pilha de protocolos TCP/IP cada vez mais era reconhecida como um padrão de interconexão.

Naturalmente aquilo que era utilizado apenas nos ambientes de pesquisa tornou-se tecnologia de mercado, culminando na década seguinte com a “Internet”. Aliado a iniciativas de empreendedores visionários e a massivos investimentos por parte das empresas de computação e áreas afins, criou-se uma euforia em torno dessa infra-estrutura de telecomunicações. O parque recursos computacionais foi vertiginosamente ampliado na esperança de se obter lucros nessa nova empreitada comercial, um novo ramo de negócios que convencionou-se chamar indústria de tecnologia da informação.

Porém por diversos motivos o ritmo de crescimento da economia mundial não atendeu as expectativas. Mesmo com o aumento da complexidade da economia, de escala e do volume de dados, percebeu-se que o investimento em equipamentos foi excessivo e parte destes recursos estava agora ociosa.

Surgiu a necessidade de se justificar todo o capital investido.

Porém, há uma modalidade de problemas e aplicações que, seja pela sua complexidade ou pelo grande volume de dados envolvidos, não podem ser solucionados pelos tradicionais sistemas computacionais providos de um único processador.

As soluções tradicionais para essa classe de problemas passam pelo emprego de supercomputadores, mainframes ou clusters. Foi nesse momento que os olhos da indústria de tecnologia da informação se voltaram novamente para os laboratórios e universidades.

A comunidade de computação distribuída e de computação de alto desempenho estava pesquisando um novo conceito que permitiria o compartilhamento de recursos e o trabalho colaborativo sem que novos gastos fossem feitos.

A pesquisa de ambientes de grid computacional viria a permitir a concretização desses objetivos. A intenção da pesquisa desses ambientes seria permitir que computadores pessoais, estações de trabalho, mainframes e supercomputadores, mas também instrumentos, como sensores meteorológicos ou microscópios eletrônicos pudessem ser conectados e seu uso compartilhado.

Voltando um pouco no tempo, para compreender melhor a situação atual. O surgimento dos termos Grid e grid computacional e as idéias por trás dos conceitos que esses termos evocam não são novas. Compartilhamento de recursos computacionais é a idéia central por trás desses termos e

conceitos e remonta as décadas de 1960 e 1970, nessa época a computação era dominada por computadores mainframes e compartilhados por organizações inteiras.

Mas foi por volta de 1965, quando os desenvolvedores do sistema operacional Multics apresentaram uma visão de computação como uma utilidade[1]. Os recursos poderiam ser acessados da mesma forma que a eletricidade, a água ou o gás; algo que o cliente se conecta e paga de acordo com a quantidade utilizada. É a partir dessa analogia que hoje o termo Grid é utilizado para descrever essa determinada classe de sistema distribuído que será o objeto de estudo neste trabalho.

De acordo com Alvarenga[2], a palavra grid, como verbete da língua inglesa é utilizada em referência a rede de energia elétrica (geração, transmissão e distribuição). Esta rede é a infra-estrutura que possibilita o uso da energia elétrica de forma consistente, generalizada, barata e confiável.

A pesquisa de ambientes de grid computacional atrai muita atenção, pois apesar de incerto, o seu futuro é muito promissor.

A intenção deste trabalho é esclarecer o conceito de grid computacional em meio a euforia que existe com relação ao tema. Alguns autores, céticos quanto a aplicação dos grids não o definem apropriadamente. Será mostrado que existe uma classe de problemas muito específica que podem ser solucionados com o emprego dessa infraestrutura.

Inicialmente será feita uma distinção entre outras formas de computação distribuída como: metacomputação, computação em cluster, peer to peer e computação de internet.

Será mostrado como a utilização de “web services” é adequada para o desenvolvimento de aplicações e serviços a serem executados nesses ambientes ou plataformas de execução.

Um objetivos do trabalho é apresentar um modelo de desenvolvimento de aplicações/serviços para os ambientes de grid computacional. Serão apresentados exemplos desenvolvidos, justificativas para a escolha de determinadas tecnologias e rumos futuros desse ramo de pesquisa da ciência da computação.

2 Computação distribuída

Atualmente quando tem-se um problema cuja solução não é facilmente atingida devido a magnitude dos cálculos a serem executados uma das alternativas é interligar recursos computacionais, seja em uma empresa ou instituição acadêmica. Esta alternativa é chamada computação distribuída, este termo a grosso modo, se refere a um sistema onde muitos processadores trabalham em um problema juntos.

Alguns dos benefícios resultantes do uso de sistemas distribuídos ou paralelos são:

• compartilhamento de recursos;

• aumento de velocidade de processamento;

• confiabilidade;

• comunicação;

Neste contexto as grids computacionais são apenas mais uma forma de computação distribuída. Existem outros exemplos de computação distribuída, alguns destes são descritos abaixo.

2.1 Sistemas paralelos ou multiprocessados

Estes sistemas possuem mais de um processador se comunicando, compartilhando barramento, clock e às vezes memória e dispositivos periféricos. Esta categoria de sistemas é conhecida como sistemas fortemente acoplados (tightly coupled systems)[3].

Existem diversas razões para a utilização destes sistemas. Uma das vantagens é o aumento de vazão (throughput). Pelo aumento do número de processadores espera-se obter um maior volume de trabalho em um período de tempo menor. O aumento de velocidade com n processadores, no entanto, é inferior a n. Quando múltiplos processadores cooperam em uma tarefa, existe um overhead inerente na manutenção das partes trabalhando em conjunto. Esse overhead e a contenção no uso de recursos compartilhados reduz a expectativa de ganho pelo uso dos processadores adicionais.

Multiprocessadores podem significar economia quando comparados a múltiplos sistemas individuais, pois eles podem compartilhar periféricos, fontes de energia, etc.

Outra razão para o emprego de sistemas multiprocessados é o aumento de confiabilidade. Se as funções puderem ser apropriadamente distribuídas entre os processadores, então a falha de um

processador não irá causar a parada do sistema, apenas o tornará lento. Se houverem 10 processadores e um deles falhar, então os nove remanescentes podem dividir uma parcela do trabalho executado pelo processador que falhou. Dessa forma o sistema irá ter uma execução apenas 10% mais lenta, ao invés de falhar por completo. A capacidade de proporcionar serviço proporcional ao nível de hardware remanescente é chamada de “degradação graciosa”(graceful degradation). Sistemas que são desenvolvidos para operar com degradação graciosa são chamado de tolerantes à falhas (fault tolerant).

2.2 Sistemas distribuídos ou multicomputadores

Em contraste com os sistemas fortemente acoplados, sistemas distribuídos não compartilham memória ou o clock. Cada processador possui sua memória local, se comunicam através de linhas de comunicação como barramentos de alta velocidade ou linhas telefônicas. Esta categoria de sistemas é chamada de sistemas fracamente acoplados (loosely coupled systems) ou sistemas distribuídos (distributed systems).

Os processadores em um sistema distribuído podem variar em tamanho e função. Podem incluir pequenos microprocessadores, estações de trabalho, minicomputadores e grandes computadores de propósito geral. Estes processadores são referenciados por diversos nomes como sites, nodos, computadores, dependendo do contexto em que são mencionados.

2.3 Meta Sistemas e metacomputação

Metacomputação é o antecessor imediato dos ambientes de grid computacional. O termo descreve projetos focalizados na interconexão de supercomputadores a fim de utilizar seu poder de processamento combinado.

É neste contexto que se encaixam os meta sistemas, ou seja, sistemas computacionais distribuídos compostos por um grupo de computadores autônomos, interligados por uma rede hierárquica[4].

Segundo Silberschatz, uma rede hierárquica é composta por “sites” organizados sob a forma de uma árvore[3]. Este tipo de organização é utilizada em redes corporativas. Por exemplo, empresas terceirizadas locais são interligadas com escritórios regionais. Escritórios regionais são interligados com as filiais dos estados. As filiais dos estados são interligadas com a matriz em Brasília.

Cada “site” possui um único nó pai e alguns (ou possivelmente nenhum) filho. Neste ambiente, nós pais e filhos se comunicam diretamente. Outras formas de comunicação passa pelos níveis superiores e depois desce pela hierarquia.

Infelizmente, escrever software para estes sistemas é difícil, primeiramente o programador deve lidar com toda a complexidade inerente a qualquer sistema de programação paralela: gerenciamento de comunicação e sincronização, escalonamento e um número potencial de tarefas independentes além de decomposição e distribuição de dados. Em um sistema heterogêneo estas tarefas se tornam ainda mais difíceis, havendo ainda o problema adicional da conversão de dados.

Mais detalhadamente, um meta sistema é um sistema distribuído composto por hosts heterogêneos (tanto processadores paralelos quanto arquiteturas convencionais), possivelmente controlados por entidade computacionais distintas, e interligados por uma conexão de rede irregular, com possíveis disparidades de latência e largura de banda. Algumas sub-redes podem ser regulares, facilmente analisáveis, enquanto outras podem ser irregulares.

Algumas sub-redes podem ser máquinas paralelas ou clusters dedicadas exclusivamente ao uso do meta sistema, outras podem transportar tráfego aleatório, por exemplo, tráfego internet.

A visão do usuário de um meta sistema ideal é aquela de uma poderosa máquina virtual, monolítica que proporciona serviços de armazenamento e processamento de dados. O usuário não precisa se preocupar com os detalhes da máquina, tipo do processador, forma de representação dos dados e localização física dos processadores e dados ou com a existência de usuários concorrentes.

O usuário não vê fronteiras no sistema, apenas objetos, tanto objetos de aplicação, ou seja executáveis, quanto objetos de dados, como arquivos. A localização e representação destes objetos é escondida.

2.4 Clusters

Segundo Alvarenga, um cluster é um tipo de sistema distribuído cujos elementos de processamento são computadores “inteiros” (computadores pessoais, workstations) e que é visto e usado como se fosse um recurso computacional único e indivisível[2].

Um cluster é diferente de um grid computacional, Buyya esclarece: “se acontece o compartilhamento de recursos gerenciado por um único sistema global, sincronizado e centralizado, então é um cluster. Em um cluster todos os nós trabalham cooperativamente, em um objetivo comum e o objetivo é a alocação de recursos executada por um gerente centralizado e global. Em Grid, cada nó possui seu próprio gerente de recursos e política de alocação[5].” Outras características que distinguem um cluster de um ambiente de grid computacional são os aspectos de homogeneidade e baixa dispersão dos elementos de processamento que compõem este arranjo.

• pertence a um domínio administrativo único e por isso é utilizado para resolver problemas de interesse de uma determinada empresa ou grupo de pesquisa;

• externamente é visto como um recurso computacional único. Seus elementos de processamento não possuem identidade própria, sendo apenas engrenagens de uma entidade maior, o cluster;

• a latência nas comunicações é baixa (da ordem de centenas de µs, ou menor);

• a taxa de transmissão disponível é elevada (a partir de dezenas de Mbps até, atualmente, dezenas de Gbps);

• pode se beneficiar de protocolos de comunicação mais eficientes entre seus elementos de processamento, pois a rede de interconexão, pertence a um mesmo domínio administrativo;

• a segurança na comunicação entre elementos de processamento diminui de importância, chegando mesmo a ser desnecessária, caso a rede de interconexão (intracluster) seja desacoplada da rede de acesso ao cluster;

• pode-se ter homogeneidade de hardware e software nos elementos de processamento, o que facilita a programação;

• sua escalabilidade é limitada.

2.5 Computação peer to peer

Computação peer to peer permite que computadores troquem arquivos ou outros dados (por exemplo, uma conversa através de um cliente de mensagens instantâneas) sem que esses dados precisem trafegar por um servidor.

Segundo Shirky, “ peer to peer é uma classe de aplicações que se beneficia dos recursos disponíveis nas extremidades da Internet, sejam estes recursos armazenamento, ciclos de processamento, conteúdo ou mesmo presença humana. Acessar estes recursos descentralizados implica operação em um ambiente de interconexão instável e resolução de endereços imprevisível, os agentes peer to peer (...) devem ter significativa ou total autonomia de servidores”[6].

Se analisada de forma ortodoxa a computação peer to peer não irá atender aos requisitos que definem um sistema distribuído, mas seus princípios de operação são utilizados em sistemas que atendem a esses requisitos.

2.6 Processamento paralelo oportunístico na Internet

O processamento paralelo na Internet é um tipo de arranjo para computação distribuída chamado “ cycle scavenging” ou, em uma tradução livre vasculhamento de ciclos de processamento[1]. A aplicação conta com a utilização de recursos computacionais ociosos para o completamento de uma tarefa. Naturalmente o processamento paralelo oportunístico na Internet não é uma estratégia viável para todas as tarefas computacionais.

Segundo Alvarenga, os problemas que melhor se adaptam a esta solução devem possuir as seguintes características[2]:

• ter granularidade grande, permitindo explorar o paralelismo no nível de processo ou tarefa;

• ser fracamente acoplado, devendo haver predomínio da computação sobre a comunicação;

• fazer uso intensivo de CPU;

• necessitar pouca largura de banda na comunicação;

• ser tolerante a alta latência;

3 Grids Computacionais e Web Services

Grid computing se distingue da computação distribuída tradicional pelo seu foco no compartilhamento de recursos em larga escala, aplicações inovadoras e, em alguns casos, orientação a computação de alto desempenho.

Segundo Cirne, um grid computacional é um sistema que fornece poder computacional sob demanda e de forma transparente, conceitua o grid como uma “plataforma para execução de aplicações paralelas.[7]” O autor enumera cinco pontos que diferenciam o grid de outros sistemas de computação distribuída:

• heterogeneidade nos componentes do grid;

• alta dispersão geográfica, grids podem ter escala mundial;

• compartilhamento, no sentido de que o grid não pode ser dedicado a uma [única] aplicação;

• múltiplos domínios administrativos, grids podem congregar recursos de várias instituições;

• controle distribuído, tipicamente não há uma única entidade que tenha controle sobre todo o grid.

Um levantamento de requisitos mais genérico foi feito por Foster. Ele afirma que um grid é um sistema que:

• Coordena recursos que não estão sujeitos a um controle centralizado: um grid integra e coordena recursos e usuários que habitam domínios distintos (por exemplo um computador pessoal e um computador central, unidades administrativas distintas de uma mesma empresa ou empresas diferentes) e lida com questões como segurança, políticas e contas de usuários. Do contrário não se trata de um grid, mas apenas um sistema de gerenciamento local;

• Utiliza protocolos e interfaces genéricos, abertos e padronizados: se não for desta forma trata-se de um sistema específico com muitas restrições que vão de encontro com um aspecto básico de um grid, a heterogeneidade;

• Disponibiliza diversas modalidades de qualidade de serviço (QoS): um grid deve permitir que os recursos que o compõem sejam utilizados de maneira coordenada atendendo a diversos parâmetros de qualidade de serviço, como tempo de resposta, vazão, disponibilidade e segurança. Deve permitir a co-alocação de recursos (recursos alocados que convocam outros recursos).

3.1 O problema do grid e as organizações virtuais

Os pesquisadores dos ambientes de grid computacional acreditam que a utilização efetiva dessa forma de computação distribuída se dará através de “Organizações Virtuais.”

Atualmente não existe “O Grid”, pelo menos não da mesma forma que todos os roteadores, servidores e enlaces de rede formam aquilo que chamamos de “A Internet”; ou ainda da mesma forma que todos os servidores HTTP e os arquivos neles hospedados formam “A Web”[8]. O que existe é um certo número de grupos que mantém infraestruturas de grids para seus propósitos, estes grupos chamados “Organizações Virtuais”. Exemplos dessas organizações virtuais são a EU DataGrid, NASA Information Power Grid, NSF Alliance, NPACI Technology Grids e a Asia-Pacific Grid. Todas elas utilizam a mesma tecnologia, portanto poderiam teoricamente funcionar como "o Grid" caso viessem a operar em conjunto.

A tecnologia de computação distribuída existente hoje, não atende a determinados requisitos que as grids computacionais se propõem a solucionar. Por exemplo, a Internet proporciona comunicação e troca de informação entre computadores, mas não permite que seja feita a utilizacão coordenada de recursos computacionais em localidades remotas.

Portanto o surgimento das Organizações Virtuais e de necessidades que seriam melhor atendidas com um conjunto de tecnologias inexistentes levou ao aprimoramento de idéias latentes nas comunidades de processamento de alto desempenho e de computação distribuída culminando com o surgimento dos ambientes de grid computacional. O problema real e específico subjacente a este conceito é o compartilhamento coordenado e a solução de problemas em Organizações Virtuais

dinâmicas e multi-institucionais[9].

Neste contexto, compartilhamento, não se trata unicamente de arquivos, mas de acesso direto a computadores, programas, dados e outros recursos a medida que forem necessários por um numero crescente de novas estratégias adotadas pela indústria, ciência e engenharia.

Este compartilhamento e, necessariamente, altamente controlado, afirma o autor. Com provedores e consumidores de recursos definindo clara e cuidadosamente o que e compartilhado, quem tem permissão para compartilhar e as condições sob as quais o compartilhamento ocorre.

Reiterando, um conjunto de indivíduos e/ou instituições definido por essas regras forma uma Organização Virtual.

Um cenário típico para o emprego das grids computacionais seria uma organização que conta com serviços terceirizados por outras entidades, e, todas juntas, estão engajadas em um grande projeto. Precisam compartilhar dados e recursos para atingir suas metas no menor prazo e com maior economia possíveis.

Exemplos seriam um fabricante de veículos que reune seus fornecedores de pecas, de serviços e consultores para elaborar o planejamento para a inauguração de uma nova fábrica montadora; outra situação seriam membros de um consorcio industrial reunidos para a construção de uma nova aeronave.

De forma geral listar tipos de aplicações que se beneficiariam do uso de grids computacionais [10]:

• computação sob demanda ou computação just-in-time: computação sob demanda disponibiliza recursos que geralmente são necessários por curtos períodos de tempo e em freqüências irregulares. Quando este tipo de recurso é requisitado, normalmente é necessário imediatamente. Devido ao fato desses recursos serem necessários de forma esparsa, pode não haver uma boa justificativa para possuir estes recursos. Em um ambiente de grid, muitos usuários podem compartilhar estes recursos com baixo custo;

• computação orientada a dados (data-intensive computing): o grid deve solucionar o escalonamento e configuração dos fluxos de grandes volumes de dados.

• computação colaborativa (collaborative computing): permite a construção de laboratórios sem paredes, permite ampliar as interações entre humanos e recursos computacionais que possam estar geograficamente dispersos.

• computação de alta taxa de rendimento (high-throughput computing): envolve a execução do maior número possível de tarefas em um determinado período de tempo.

• supercomputação distribuída: um dos objetivos das grids computacionais é resolver problemas, que não poderiam ser solucionados em um único sistema, pela agregação de recursos localizados em diferentes locais. A supercomputação distribuída pode ser um componente de outras aplicações de grid como computação sob demanda e computação colaborativa.

Assim sendo, a questão do Grid pode ser definida como o compartilhamento flexível, seguro e coordenado de recursos entre grupos dinâmicos de indivíduos, instituições e dispositivos, chamados “ Organizações Virtuais”(Virtual Organizations).

3.2 O surgimento das Organizações Virtuais

Organizações Virtuais possuem o poder de mudar dramaticamente a forma como usamos computadores para resolver problemas, da mesma forma que a WEB mudou a forma como trocamos informações[9].

A necessidade de se engajar em processos colaborativos e fundamental para diversas disciplinas e atividades, não estando limitada as ciências, engenharia ou aos negócios. E graças a esta ampla aplicabilidade que o conceito de Grids Computacionais é importante.

Esse arranjo de indivíduos e instituições possui certos condicionantes ou aspectos relevantes para seu sucesso:

• “ distrustful participants”: participantes desconfiados tendo que compartilhar software, computadores, dados, sensores, etc;

• compartilhamento de recursos condicional: cada proprietário de recursos os torna disponíveis sujeitos a restrições de quando, onde e o que pode ser feito. Por exemplo, um participante de uma organização virtual pode permitir aos seus parceiros a invocação de uma simulação apenas para problemas considerados simples;

• definição de restrições de acesso: requer o uso de mecanismos para o estabelecimento de políticas de autenticação (quem acessa) e autorização (o que acessa);

• natureza de relações de compartilhamento: são definidas por quais recursos podem ser acessados, a qualidade desses recursos e as políticas que governam o acesso. Devido a falta de conhecimento prévio sobre como um recurso será utilizado, algumas informações como métricas de performance, estimativas e limitações (qualidade de serviço), podem fazer parte das condições para compartilhamento.

Foster afirma que os ambientes de Organizações Virtuais devem possuir as seguintes características[9]:

• Log on único: o usuário deve autenticar-se perante o sistema uma única vez e desfrutar de acesso aos recursos da camada Fabric (maiores detalhes na seção 3.4 Descrição da arquitetura do grid) sem intervenção posterior;

• Delegação: as permissões de um usuário devem ser herdadas pelos pelos processos que ele executa e estes processos podem delegar um subconjunto de suas permissões para outros processos.

• Integração com diversas soluções de segurança locais;

• Relações de confiança orientadas a usuário.

3.3 Tecnologia e arquitetura do grid

A natureza das tecnologias envolvidas com grid passa por ferramentas que dêem suporte ao gerenciamento de credenciais e políticas quando o poder computacional se espalhar por múltiplas instituições; por protocolos e serviços que permitam o acesso remoto seguro a dados e a recursos computacionais; mecanismos que ofereçam informação e permitam a configuração de serviços e recursos; e finalmente serviços de gerenciamento de dados que permitam a localização e o transporte de conjuntos de dados entre sistemas de armazenamento e aplicações.

Portanto, o estabelecimento, gerenciamento e uso intensivo de relações de compartilhamento requer uma nova tecnologia. Foster estrutura a discussão desta tecnologia em termos de uma arquitetura do Grid, que identifica os componentes fundamentais do sistema, seu propósito e função e como ocorre sua interação[11].

A operação efetiva de uma organização virtual requer a possibilidade do estabelecimento de relações de compartilhamento entre quaisquer participantes. Portanto, interoperabilidade é um tema central. Em um ambiente de rede, interoperabilidade significa protocolos comuns. Logo, a arquitetura do Grid, é primeiramente e acima de tudo, uma arquitetura de protocolos.

A definição de um protocolo (1)especifica como os elementos de um sistema distribuído interagem uns com os outros a fim de alcançar um comportamento especifico e (2)a estrutura da informação trocada durante esta interação. Uma vez que os protocolos governam a interação entre os componentes, e não a interação desses componentes, o controle local e preservado.

Os protocolos definem mecanismos para negociar, estabelecer, gerenciar e utilizar as relações de compartilhamento que definem as organizações virtuais. Esses protocolos devem idealmente serem abertos e seguir padrões. Como já foi parcialmente mencionado, os padrões permitem

extensibilidade, interoperabilidade, portabilidade e compartilhamento de código.

E necessário garantir que as relações de compartilhamento sejam iniciadas entre partes arbitrarias, acomodando novos participantes dinamicamente, diversas plataformas, idiomas e ambientes de programação. Neste contexto os mecanismos são de pouca utilidade se não forem

definidos e implementados para operar além dos limites organizacionais, políticas operacionais e tipos de recursos.

Além de protocolos, compõem a arquitetura os pacotes de desenvolvimento de software (SDK's – Software Development Kits) e interfaces de programação de aplicações (API's – Application Programming Interfaces).

Outra característica presente em um ambiente de grid computacional adequado é a possibilidade de se coordenar processos e tarefas através de múltiplos recursos. Esta característica é chamada

co-escalonamento (coscheduling).

3.4 Descrição da arquitetura do grid

A arquitetura do Grid e definida em camadas. Nas camadas inferiores há um numero reduzido de abstrações e protocolos, sobre as quais são implementados os comportamentos de alto nível[12].

Em cada camada tem-se protocolos bem definidos que provem acesso a alguns serviços úteis, como por exemplo, descobrimento e gerenciamento de recursos, acesso a dados, entre outros. API's também podem estar presentes nestas camadas, em cuja implementação esta definida a troca de mensagens de protocolo com os serviços apropriados para a execução das ações desejadas.

Para completude, existem ainda protocolos inter-grid, que permitem a interoperabilidade entre diferentes tecnologias de grid.

Uma variedade de recursos é definida na camada Fabric. Sobre esta camada os protocolos de recursos e conectividade (Resource and Connectivity) facilitam o compartilhamento de recursos individuais. Finalmente, na camada coletiva (Collective) podem ser construídos uma variedade de serviços globais e comportamentos específicos de aplicações. Esta camada tem este nome pois envolve o uso coordenado de múltiplos recursos.

A figura seguinte mostra a arquitetura das camadas do protocolo do Globus Toolkit e as interações entre elas.

3.4.1 Fabric: interfaces para controle local

A camada Fabric e que, em primeira instância, disponibiliza os recursos compartilhados. Um recurso pode ser uma entidade lógica, como um sistema de arquivos distribuído, um cluster computacional ou um conjunto distribuído de computadores. Os componentes da camada Fabric implementam as operações locais, especificas a cada um dos recursos, sejam elas operações físicas ou lógicas. Existe uma relação entre as funções implementadas pela camada Fabric e as operações de compartilhamento. Funcionalidades melhores nesta camada permitem operações de compartilhamento mais sofisticadas. Por exemplo, o suporte a reservas antecipadas de recursos neste nível, permitem a serviços em camadas superiores efetuar o “co-escalonamento”, ou seja, a agregação de recursos para o cumprimento de determinada tarefa.

Foster afirma que os recursos devem, no mínimo, implementar mecanismos de consulta, que permitam descobrir sua estrutura, estado e capacidades, e de gerenciamento, proporcionem algum controle da qualidade de serviço.

3.4.2 Conectividade: comunicando-se de forma segura e efetiva

A camada de conectividade define o cerne dos protocolos de comunicação e autenticação necessários para as transações de rede especificas ao Grid. Os protocolos de comunicação permitem a troca de dados entre os componentes da camada Fabric. Os protocolos de autenticação atuam sobre os protocolos de comunicação e oferecem serviços para verificar a identidade de usuários e de recursos.

Figura 1 - Camadas da arquitetura de protocolo do Globus

Os requisitos colocados para comunicação incluem transporte, roteamento e nomeação. Esses protocolos são baseados na pilha de protocolos TCP/IP, mais especificamente nas camadas de rede (IP, ICMP), transporte(TCP, UDP) e aplicação(DNS, OSPF, RSVP)[13].

Os aspectos de segurança da camada de Conectividade devem, na medida do possível, serem baseados em padrões vigentes.

3.4.3 Recursos: compartilhando recursos individuais

Os protocolos da camada de Recursos são responsáveis por negociar, iniciar, monitorar, controlar, auditar e finalmente efetuar o “pagamento” das operações de compartilhamento. São encarregados apenas de recursos individuais e ignoram completamente questões de atomicidade e estado global de coleções distribuídas, isso é tarefa da camada Coletiva.

Estes protocolos fazem chamadas a funções implementadas pela camada Fabric. Os mecanismos desejáveis da camada Fabric sumarizam as características principais requeridas dos protocolos da camada de Recursos.

Há duas classes primárias de protocolos na camada de Recursos: protocolos de informação e protocolos de gerenciamento.

3.4.4 Coletiva: coordenando recursos múltiplos

Esta camada não se associa a um recurso especifico mas captura as interações entre coleções de recursos.

Como esta camada esta posicionada no topo da pilha de protocolos ela pode implementar uma ampla variedade de comportamentos de compartilhamento sem que seja necessária a especificação de novos requisitos aos recursos sendo compartilhados. Ela se utiliza das funcionalidades oferecidas pelas camadas inferiores.

3.4.5 Aplicações

A última camada na arquitetura do Grid compreende as aplicações. de usuários que operam no ambiente de uma Organização Virtual. As aplicações. são construídas em termos de (e efetuam chamadas aos) serviços implementados em qualquer camada.

3.5 Segurança em ambientes de grid computacional

Questões de segurança na arquitetura de grid computacional proposta pelo OGSA e implementada pela OGSI são tratados de forma bastante sofisticada.

Organizações Virtuais que utilizam o middleware Globus têm a sua disposição um módulo para a implantação de uma autoridade certificadora para emissão de certificados a usuários autorizados a utilizar os serviços do ambiente e hosts autorizados a oferecer os recursos.

3.6 Comentários sobre JAVA, JINI, CORBA e DCOM

Poderia ser questionado se outras tecnologias para computação distribuída não seriam soluções para os problemas que o grid se propõe a solucionar. O argumento conclusivo é que estas alternativas não enfrentam adequadamente todos os desafios aos quais o grid se prontifica.

Java oferece tecnologia para o desenvolvimento orientado a objetos de aplicações portáveis[8]. CORBA (Common Object Request Broker Architecture) define uma Linguagem de Definição de Interfaces (IDL) para interoperabilidade entre linguagens, um serviço de chamadas de procedimentos remotos e outros serviços especializados, como um corretor para localização de recursos.

DCOM (Distributed Component Object Model) da Microsoft oferece diversos serviços como chamadas a procedimentos remotos, serviço de diretórios e um sistema de arquivos distribuído.

Porém todas essas tecnologias não lidam diretamente com a questão de alta performance e problemas decorrentes da heterogeneidade desta classe de ambientes distribuídos.

3.7 Questões referentes aos ambientes de grid computacional

“ O Grid é uma fonte para poder de processamento gratuito”.

Uma idéia equivocada referente aos recursos ociosos em um ambiente de grid computacional é acreditar que eles estarão publicamente disponíveis. Essa crença é alimentada pela mídia quando afirma que os ambientes de grid computacional são a nova geração da Internet. Os recursos computacionais não permanecem publicamente disponíveis como arquivos ou páginas web em servidores FTP ou HTTP. Cada ponto em um grid mantém controle sobre o acesso aos seus recursos. Ao instalar os componentes do grid o administrador do sistema cria um arquivo de mapeamento que contem relações entre as credenciais de grid e contas de usuário locais. As únicas

pessoas autorizadas a submeter tarefas aos recursos são aquelas cujas credenciais de grid estão listadas no arquivo de mapeamento. Todas as submissões são registradas localmente via syslog.

“ O Grid torna os supercomputadores monolíticos supérfluos.”

A categoria de aplicações que são passíveis de serem executadas em um grid são fracamente acopladas, data intensive (cálculos computacionais intensivos) e que dependam pouco de comunicação via rede. O grid não irá substituir os supercomputadores, será mais uma alternativa para uma determinada categoria de problemas.

3.8 Web Services

O termo Web Services surgiu no ano de 2000 com a introdução de tecnologias como SOAP, WSDL e UDDI. Mais recentemente o termo Arquitetura Orientada a Serviços (SOA – Service Oriented Architecture) foi cunhado para descrever a abordagem completa da construção de sistemas distribuídos fracamente acoplados, com um conhecimento mínimo compartilhado entre os componentes do sistema[14].

De acordo com o Grupo de Trabalho de Arquitetura de Web Services do W3C (W3C Web

Services Architecture Working Group – WS-ARCH):

“ Um Web Service é um sistema de software desenvolvido para dar suporte a interação de máquinas através de uma rede. Possui uma descrição de interface passível de processamento escrita em WSDL. Outros sistemas podem interagir com o Web Service da maneira descrita pela sua interface usando mensagens SOAP, tipicamente transportadas usando HTTP e serialização XML, em conjunto com outros padrões relacionados a Web.”

Uma arquitetura orientada a serviços define um sistema distribuído no qual agentes, chamados serviços, são coordenados pelo envio e recebimento de mensagens. Citando o WS-ARCH novamente:

“ Uma SOA é um tipo específico de sistema distribuído no qual os agentes são serviços. Um serviço é um agente de software que executa operações bem definidas (isto é, fornece um serviço) e pode ser invocado fora do contexto de um aplicação maior. (...) Os seus usuários devem se preocupar apenas com a descrição da interface do serviço. Os serviços possuem interfaces endereçáveis e se comunicam através de protocolos e formatos de dados padrão.

A grosso modo, Web Services representam apenas mais uma tecnologia de computação distribuída, como CORBA (Common Object Requestor Brokering Architecture), RMI (Remote

Method Invocation) e EJB (Enterprise Java Beans). Esta tecnologia permite a criação de

aplicações que sigam o paradigma de programação cliente/servidor[15].

Um exemplo simples de um Web Service seria um repositório de dados que é acessado remotamente por computadores clientes, em localizações remotas, com sistemas operacionais possivelmente diferentes e arquiteturas distintas. Os clientes efetuam uma requisição de serviço, o servidor pode efetuar alguma computação sobre os dados e retornar um resultado. Ou ainda um serviço de consulta a previsão do tempo ou de análise de uma carteira de ações fictícia. A figura seguinte exemplifica o processo de invocação de um web service.

Apesar desta descrição também poder conceituar uma página web, a diferença está no fato de que estas páginas apresentam informações para que pessoas possam ler. A informação disponível através de um Web Service é única e exclusivamente acessada por um programa, nunca diretamente por uma pessoa. Apesar dos Web Services contarem com tecnologias Web amplamente difundidas (HTTP, por exemplo), não há, necessariamente, relação com navegadores Web ou HTML. A próxima figura mostra a arquitetura de um web service.

Existem algumas vantagens na utilização de Web Services em detrimento de outras tecnologias, como CORBA, RMI e EJB. Podem ser citadas[15]:

• Web Services são independentes de plataforma e linguagem, pois utilizam o padrões XML. Isto significa que um programa cliente pode ser programado em C++ e ser executado no Microsoft Windows, enquanto o Web Service pode ser programado em Java e ser executado em Linux.

• Web Services utilizam o protocolo HTTP para transmissão de mensagens. Isto é uma vantagem caso se deseje desenvolver aplicações para uso na Internet.

A fim de desmistificar a euforia que existe em torno da utilização de Web Services, podem ser citadas algumas desvantagens da sua utilização[15]:

• Overhead. A transmissão de todos os dados em um formato XML não é tão eficaz quanto utilizar um código binário proprietário. O que se ganha em portabilidade, perde-se em eficiência. Mesmo assim, este overhead é aceitável para a maioria das aplicações, mas provavelmente não será utilizado em aplicações críticas em real-time.

• Versatilidade deficiente. Atualmente, Web Services não é uma tecnologia versátil, pois permite apenas formas básicas de invocação de serviços. CORBA, por exemplo, oferece aos programadores diversas funcionalidades, como persistência, transações, gerenciamento de ciclo de vida, etc.

Figura 3 - Arquitetura de um web service

Existe ainda um outra característica que distingue os Web Services. Enquanto CORBA e EJB são orientado para sistemas distribuídos fortemente acoplados, onde cliente e servidor são muito dependentes um do outro, os Web Services são orientados a sistemas fracamente acoplados. O cliente não precisa ter um conhecimento prévio do Web Service até que faça a sua invocação. Sistemas fortemente acoplados são ideais para aplicações em redes locais. Os Web Services, no entanto, atendem muito bem aos requisitos e aplicações Internet, como aquelas utilizadas em ambientes de Grid Computacional.

Apesar dos web services se apresentarem, em tese, como uma boa solução para equacionar o problema de executar aplicações sobre a infra-estrutura da Internet usando clientes e servidores fracamente acoplados, eles não possuem determinadas características importantes para serem considerados um solução definitiva.

Quando uma série de transações deve ser executada, freqüentemente, o resultado de uma etapa é utilizado em etapas subseqüentes. Por exemplo, operações em um banco de dados ou cálculos matemáticos. Um web service não tem a capacidade de armazenar essas informações entre uma invocação e outra. Ou seja, eles não armazenam informações de estado, são stateless.

Quando dois usuários acessam uma página da Internet com conteúdo dinâmico, a funcionalidade do servidor que previne que o conteúdo de um usuário seja apresentado a outro é chamada de controle de sessão. Após sua invocação por um cliente, a informação que foi utilizada continua disponível no Web Service mesmo após o término de uma invocação, criando problemas de segurança e continuidade. A priori, um web service não mantém esse tipo de controle, os web services são “não-transientes.”

Para solucionar problemas como os apresentados acima surgiram os grid services, com aprimoramentos que os tornam adequados para o suporte à aplicações em ambientes de grid computacional.

A forma encontrada para aprimorar os web services passa pelo emprego de idéias comuns à engenharia de software, os design patterns. A proposta foi utilizar o Factory Pattern, que permite criar uma instância do web service para cada invocação de cliente.

Essas características importantes para que os web services sejam utilizados em ambientes de grid computacional devem ser incorporadas na versão 2.0 da WSDL. Portanto no futuro não haverá diferença entre web services e grid services.

4 Projeto e ambiente de desenvolvimento

A implementação de aplicações para ambientes de grid computacional utilizando web

services, ou Grid Services, pode seguir duas abordagens: herdar características de uma classe

esqueleto ou usar um modelo de delegação, no qual as solicitações são delegadas a algumas classes chamadas provedores de operações[16].

Neste trabalho a aplicação desenvolvida irá herdar toda a funcionalidade necessária para operar em um ambiente de grid computacional da API oferecida pelo framework do Globus Toolkit. Para este trabalho foi desenvolvido um exemplo de Grid Service. A aplicação desenvolvida é capaz de efetuar operações aritméticas simples.

O desenvolvimento de um Grid Service pode ser dividido em etapas[17]:

• Especificar uma interface de serviços;

• Gerar código de suporte ao Grid Service;

• Implementar o serviço;

• Distribuir o serviço.

Cada uma dessas etapas será explicada separadamente.

4.1 Especificar uma interface de serviços

O primeira etapa ao desenvolver um Grid Service é especificar a sua interface de serviço, ou

PortType[15]. Inicialmente não é necessário saber os detalhes do serviço, ou seja, que algoritmos

serão utilizados ou quais bancos de dados serão acessados, apenas o que este serviço irá oferecer. Aqui são definidos os métodos ou funções utilizados pelo serviço e quais parâmetros eles recebem.

Esta especificação é escrita usando um tipo de XML, o WSDL (Web Services Description Language). Duas abordagens podem ser utilizadas: definir a interface em JAVA e gerar a interface em WSDL ou escrever diretamente a interface em WSDL.

Escrever a interface em JAVA e gerar seu equivalente em WSDL é mais fácil, porém há um inconveniente. Quando são utilizados tipos complexos de dados, diferentes dos tipos padrão do JAVA, como int, float e char, podem ocorrer inconsistências no mapeamento da interface JAVA e WSDL. Portanto, é aconselhável escrever a interface diretamente em WSDL, usando a sintaxe

GWSDL (Grid Web Service Description Language). A diferença entre Web Services e Grid Services reside basicamente nas pequenas diferenças entre a sintaxe WSDL e GWSDL, em outras palavras, nos aprimoramentos do GWSDL. Lembrando que o GWSDL é uma solução temporária, enquanto a versão 2.0 do WSDL não é homologada pelo W3C.

A geração de uma interface WSDL é feita usando-se uma ferramenta chamada Apache Axis JAVA2WSDL.

Exemplos de interfaces definidas tanto em JAVA quanto em WSDL/GWSDL podem ser encontradas nos anexos sob os títulos Math.java e MathService.wsdl.

4.2 Gerar código de suporte ao Grid Service

Da mesma forma que em outras tecnologias para computação distribuída, como RMI, CORBA e EJB, os Web Services contam com o uso de stubs[15]. Os stubs são componentes de software responsáveis por toda a comunicação de rede e pela manipulação das mensagens SOAP.

O framework Globus Toolkit prevê dois modelos de desenvolvimento de Grid Services, top

down e bottom up. No modelo top down parte-se de uma interface escrita em WSDL e no modelo bottom up o primeiro passo é a interface JAVA. Em ambos os modelos o resultado final desta etapa

é um conjunto interfaces compatíveis com o padrão JAX-RPC (JAVA API for XML-based RPC), usado para realizar um mapeamento entre os tipos XML e os tipos do JAVA mantendo a funcionalidade proporcionada pelas chamadas a procedimentos remotos.

Nos anexos, sob os títulos MathPortType.java, MathServiceGridLocator.java,

vistos exemplos de stubs que posteriormente serão incorporados aos programas cliente e servidor da aplicação.

4.3 Implementar o serviço

O primeiro etapa na implementação de um Grid Service, e o que de fato o torna uma aplicação desta categoria, é a inclusão de classes que lhe emprestem funcionalidade para responder chamadas de procedimentos remotos, criação e destruição de instâncias, manipulação de mensagens SOAP. Estas classes foram geradas na etapa anterior e também são oferecidas pelo framework[15].

No serviço desenvolvido neste trabalho são explicitamente feitas duas inclusões no código principal do serviço: GridServiceImpl e MathPortType.

Em seguida é necessário escrever um construtor para o serviço. E finalmente são implementados os métodos descritos na interface (JAVA ou WSDL).

O código completo da aplicação pode ser encontrado nos anexos sob o título MathImpl.java.

4.4 Distribuir o serviço

Até este ponto tem-se uma interface de serviço escrita em JAVA, seu equivalente escrito em WSDL, vários arquivos que formam os stubs e a implementação propriamente dita do serviço. A última etapa é agrupar todos estes componentes e torná-los disponíveis em um servidor web que seja habilitado para operar em um ambiente de grid computacional. Esta etapa é chamada de distribuição (deployment).

Para maior compreensão pode-se ainda dividir esta etapa em três tarefas[17]:

• escrever um descritor de distribuição;

• incluir todos os arquivos em um pacote gar;

• instalar o pacote gar em um GSHE (Grid Service Hosting Environment), ou seja um servidor web habilitado a operar um ambiente de grid computacional.

Um dos componentes chave desta fase de distribuição do serviço é um arquivo chamado

descritor de distribuição (deployment descriptor)[15]. Este arquivo orienta o servidor web, GSHE,

na maneira que deve publicar o Grid Service. O descritor de distribuição é escrito em uma linguagem chamada WSDD (Web Services Deployment Descriptor).

O descritor de distribuição da aplicação deste projeto pode ser encontrado sob o título

Math.wsdd junto aos anexos.

Na tabela abaixo são apresentados os parâmetros reconhecidos pelo GSHE do framework Globus Toolkit:

<service name= nome>

Aqui é definido o nome pelo qual o serviço será acessível. Terá o formato <URL no ambiente do grid>/nome, o formato da URL é tipicamente http://<host>:<porta>/ogsa/services

<parameter name= “name”...> Uma descrição do serviço. (opcional)

<parameter name= “className”...> O parâmetro className especifica uma classe ou interface que possui métodos públicos em

correspondência com todas as operações wsdl.

<parameter name= “baseClassName”...> Especifica o nome da classe principal que implementa o Grid Service. Se é idêntico ao className pode ser ignorado. (opcional)

<parameter name= “operationProviders”...> A lista de classes que devem ser carregadas como provedores de operações. A ordem de listagem dos provedores é a mesma em que eles devem ser carregados. (opcional)

<parameter name= “persistent” ...> Este parâmetro diferencia o grid service dos web services comuns em execução no servidor. Se este parâmetro não estiver presente o grid service será tratado como um web service comum.

<parameter name= “schemaPath”...> Indica ao framework a localização do arquivo de interface de serviço WSDL.

<parameter name= “instance schemaPath”...> No caso de um grid service que utiliza o padrão factory é necessário indicar neste parâmetro a

localização do arquivo de interface do serviço que irá ser criado.

<parameter name= “handlerClass”...> Indica o nome da classe que efetua despachos, no caso do Globus é

org.globus.ogsa.handlers.RPCURIProvider <parameter name= “factoryCallBack”...> Este parâmetro aponta para uma classe que

implementa a interface usada para criar instâncias de serviços.

Tabela 1 - Parâmetros WSDL

A segunda tarefa a ser executada nesta etapa de distribuição do serviço é incluir os arquivos em um pacote gar. O Globus Toolkit utiliza o Apache Ant para automatizar este processo.

Apache Ant é uma ferramenta para fazer o build de aplicações baseadas em JAVA compostas por múltiplos arquivos. Funciona da mesma forma que o Make para aplicações baseadas em C ou C++. O Make funciona utilizando Makefiles, o Ant opera seguindo as instruções contidas em arquivos build.xml.

A inclusão dos arquivos do Grid Service em um pacote gar é descrita no arquivo build.xml que se encontra nos anexos.

A terceira etapa, instalação do pacote gar no ambiente de grid computacional, também será executada e automatizada em conjunto pelo Ant. A descrição desta etapa está no mesmo arquivo

build.xml.

4.5 Um cliente para testar o Grid Service

Afim de testar o Grid Service apresentado serão utilizados dois cliente. O primeiro para demonstrar a possibilidade de se criar instâncias distintas a cada invocação do Grid Service. O segundo cliente demonstra característica de memória de estado de um Grid Service, a cada execução do cliente o valor de uma variável é incrementado em seu valor anterior[15].

Para escrever um cliente basta incluir as classes que formam os stubs e o GSH do serviço. GSH é o Grid Service Handle, o nome dado para a URL (Uniform Resource Locator) única de cada Grid Service.

O código dos clientes pode ser verificado nos anexos sob os nomes MathClient.java e

5 Decisões de projeto

A seguir serão apreentadas alguns argumentos que justificaram as escolhas das plataformas de software e hardware utilizadas para este projeto.

5.1 Linguagem JAVA

O desenvolvimento das aplicações poderia ser feito em Python, CORBA, Perl ou mesmo Matlab, mas por diversas razões foi utilizada a linguagem JAVA. Gregor Lawszweski sintetiza muito bem os motivos que justificam a escolha de JAVA como opção para o desenvolvimento de aplicações para ambientes de Grid Computacional[16].

• A linguagem: Java como uma linguagem de programação possui algumas características fundamentais de suporte à engenharia de software para projetos de larga escala como empacotamento(JAR), abordagem orientada a objeto, herança simples, coleta de lixo e tipos de dados unificados. Ainda, como o suporte a threads e mecanismos de controle de concorrência fazem parte da linguagem, existe a possibilidade de expressar paralelismo diretamente no mais baixo nível de usuário.

• Biblioteca de classes: Java oferece uma ampla variedade de bibliotecas de classe incluindo funções essenciais, como a comunicação através de sockets e acesso via SSL.

• Componentes: uma arquitetura de componentes é fornecida pelos JavaBeans e Enterprise JavaBeans, permitindo o desenvolvimento de programas baseados em componentes.

• Implantação: o bytecode Java permite implantação simples através de navegadores web.

• Portabilidade: “escreva uma vez, execute em qualquer lugar.”

• Manutenção: Java contem uma ferramenta para geração automática de documentação, além disso componentes escritos como JavaBeans podem ser integrados em IDEs comerciais.

• Desempenho: Fornecedores de software demonstraram que o desempenho em aplicações específicas pode se aproximar de C ou FORTRAN.

• Dispositivos: Smart cards baseados em Java, PDAs e dispositivos inteligentes podem proporcionar uma expansão do ambiente para cientistas usando o Grid.

• A Indústria: o suporte da indústria de TI torna Java merecedora de atenção no momento da escolha de um ambiente para o desenvolvimento de aplicações para o Grid.

• A Comunidade: inúmeras universidades no mundo estão ensinando Java aos seus estudantes.

5.2 Sistema operacional GNU/Linux

Outra escolha que poderia ser feita é quanto ao sistema operacional. Para as tarefas de desenvolvimento e teste poderia ser utilizado qualquer sistema UNIX-like ou Microsoft Windows. Porém para que o ambiente anfitrião e softwares servidores pudessem ser executados havia a necessidade de ser um sistema UNIX-like, esta é uma limitação que está sendo corrigida e em versões futuras o Globus Toolkit poderá ser executado em qualquer plataforma.

Sendo assim, o sistema operacional escolhido foi o GNU/Linux.

5.3 Middleware Globus Toolkit

A construção de Grids Computacionais não é uma tarefa simples. Pode-se destacar três características que corroboram o fato:

• Grids são potencialmente muito grandes;

• Grids são heterogêneas em múltiplos níveis. Os recursos de hardware que formam o núcleo dos grids computacionais são muito heterogêneos, os computadores, dispositivos de armazenamento, redes, etc. No âmbito do software, linguagens ou paradigmas de programação, versões de sistemas operacionais, bibliotecas e compiladores também tornam os sistemas computacionais essencialmente diferentes. Recursos como bancos de dados adicionam heterogeneidade no âmbito das aplicações. Finalmente, a propriedade destes recursos está distribuída por diversos domínios administrativos, o que resulta em heterogeneidade em políticas de administração destes recursos.

• Grids são altamente dinâmicas. Os múltiplos domínios administrativos contribuem para esta característica. A disponibilidade de recursos se altera em uma base contínua a medida que eles são adicionados, removidos, atualizados e movimentados no interior do grid. Finalmente, a falha de recursos é a regra e não a exceção.

Os ambientes de grid computacional existentes atualmente são resultado de iniciativas para a elaboração de middleware que permita sua configuração. Seu objetivo é conectar redes, workstations, computadores pessoais ou quaisquer outros recursos em um sistema que permita a abstração de arquiteturas diferentes, sistemas operacionais ou localização física. Cada recurso é um elemento independente, podendo atuar ora como servidor, ora como cliente.

Middleware são programas que conectam duas ou mais aplicações através de uma rede. Mais especificamente, o termo se refere a uma camada de serviços que reside entre a rede e aplicações para o gerenciamento de recursos e dados, localização destes recursos, acesso e segurança.

As iniciativas mais significativas no desenvolvimento de middleware para a construção de ambientes de grid computacional são o Condor-G, o Legion e o Globus Toolkit.

Neste trabalho será utilizado o Globus Toolkit para a construção de um ambiente de grid computacional. Este ambiente será utilizado para demonstrar como aplicações podem utilizar conceitos de web services, como a WSDL (Web Services Definition Language), para usufruir da infra-estrutura criada por grids.

O Globus Toolkit é um conjunto de componentes que podem ser utilizados tanto independentemente quanto juntos. É desenvolvido sob uma licença GPL, é software livre, e usado como base para diversos produtos comerciais. Atualmente o Globus Toolkit é o padrão da indústria para a implantação de testbeds (ambientes de teste) de grid computacional. Sua construção é orientada por padrões que são adotados por outras arquiteturas de grid. Esses padrões são descritos em duas publicações, Open Grid Services Architecture e Open Grid Services Infrastructure.

Os serviços oferecidos pelo GT3 são apresentados por interfaces que estão em conformidade com a OGSI (Open Grid Services Infrastructure). Apesar destas interfaces serem implementadas em Java, os serviços ainda apresentam alto desempenho, pois seu back-end é codificado em C.

5.3.1 O que é o Globus Toolkit

Um conjunto de serviços e bibliotecas de software para dar suporte a Grids e aplicações de Grids. Há software para segurança, infraestrutura de informação, gerenciamento de recursos, gerenciamento de dados, comunicação, detecção de erros e portabilidade.

Há um conjunto de componentes que compõe o núcleo do Globus, estes componentes serão descritos em seguida. Para cada um há uma API (Application Programmer Interface - Interface de Programação de Aplicação) codificada em C e ferramentas de linha de comando. Para algumas há classes em Java.

Além destes componentes do núcleo há protótipos de componentes de alto nível e serviços. Finalmente existe um grande número de iniciativas para o desenvolvimento de frameworks e aplicações científicas e de engenharia.

5.3.2 Componentes do núcleo do Globus Toolkit

Globus Resource Allocation Manager (GRAM) permite alocação de recursos e criação de processos, monitoramento e gerenciamento de serviços. Sua tarefa é repassar requisições expressas em uma Linguagem de Especificação de Recursos (RSL - Resource Specification Language) em comandos para computadores e escalonadores locais.

Grid Security Infrastructure (GSI) oferece um esquema de autenticação única com suporte a um controle local de permissões de acesso e mapeamento de usuários do Grid para identidades locais. Permite a utilização de smart cards.

Monitoring and Discovery Service (MDS) é um serviço de informação que combina mecanismos de descoberta de dados com LDAP (Lightweight Directory Access Protcol). Permite acesso homogêneo a, por exemplo, configuração de servidores, status de rede ou localização de conjuntos de dados replicados.

Global Access Secondary Storage (GASS) permite leitura e escrita de dados locais a programas sendo executados em localidades remotas.

Heartbeat Monitor (HBM) permite a detecção de falhas em componentes do sistema ou processados por administradores de sistemas e usuários comuns.

5.4 Ambiente de desenvolvimento

O ambiente de hardware e software utlizado é descrito nas seções seguintes.

5.4.1 Hardware

Processador

Intel Pentium IV HyperThreading com SMP habilitado, o que permitiu ao kernel do sistema

operacional identificar uma máquina com dois processadores.

Memória secundária 80 GB

Memória principal 512 MB DDR 400MHz

Tabela 2 - Configuração de hardware utilizada

5.4.2 Software

O software utilizado para desenvolvimento de aplicações e realização de testes está descrito abaixo:

Sistema operacional GNU/Linux

Kernel 2.4.22 SMP

Linguagem de desenvolvimento JAVA 1.4.2_02

Middleware de Grid Globus Toolkit v.3.0.2

IDE VIM – Vi IMproved

Build Tool Apache Ant 1.5.4