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

UNIVERSIDADE FEDERAL DE SANTA CATARINA

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

Vitor Hugo Vargas Horewicz

UNIVERSIDADE FEDERAL DE SANTA CATARINADEPARTAMENTO DE INFORMÁTICA E ESTATÍSTICACURSO 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:

grid computing, web services, OGSI, Globus Toolkit, computação distribuída

Florianópolis, 5 de Fevereiro de 2004

DEDICATÓRIA

Para Waldemir e Elaine

AGRADECIMENTOS

Sinceros agradecimentos ao Prof. Mario Dantas pelo exemplo e inspiração.

SUMÁRIO1 Introdução..........................................................................................................................................92 Computação distribuída...................................................................................................................11

2.1 Sistemas paralelos ou multiprocessados..................................................................................112.2 Sistemas distribuídos ou multicomputadores..........................................................................122.3 Meta Sistemas e metacomputação...........................................................................................122.4 Clusters....................................................................................................................................132.5 Computação peer to peer.........................................................................................................142.6 Processamento paralelo oportunístico na Internet...................................................................15

3 Grids Computacionais e Web Services...........................................................................................163.1 O problema do grid e as organizações virtuais........................................................................173.2 O surgimento das Organizações Virtuais.................................................................................193.3 Tecnologia e arquitetura do grid..............................................................................................203.4 Descrição da arquitetura do grid..............................................................................................21

3.4.1 Fabric: interfaces para controle local...............................................................................223.4.2 Conectividade: comunicando-se de forma segura e efetiva.............................................223.4.3 Recursos: compartilhando recursos individuais...............................................................233.4.4 Coletiva: coordenando recursos múltiplos.......................................................................233.4.5 Aplicações........................................................................................................................23

3.5 Segurança em ambientes de grid computacional.....................................................................243.6 Comentários sobre JAVA, JINI, CORBA e DCOM...............................................................243.7 Questões referentes aos ambientes de grid computacional......................................................243.8 Web Services...........................................................................................................................25

4 Projeto e ambiente de desenvolvimento..........................................................................................304.1 Especificar uma interface de serviços......................................................................................304.2 Gerar código de suporte ao Grid Service.................................................................................314.3 Implementar o serviço.............................................................................................................324.4 Distribuir o serviço..................................................................................................................324.5 Um cliente para testar o Grid Service......................................................................................34

5 Decisões de projeto..........................................................................................................................355.1 Linguagem JAVA....................................................................................................................355.2 Sistema operacional GNU/Linux.............................................................................................365.3 Middleware Globus Toolkit.....................................................................................................36

5.3.1 O que é o Globus Toolkit.................................................................................................375.3.2 Componentes do núcleo do Globus Toolkit.....................................................................38

5.4 Ambiente de desenvolvimento.................................................................................................385.4.1 Hardware..........................................................................................................................385.4.2 Software...........................................................................................................................39

6 Trabalhos futuros e conclusão.........................................................................................................406.2 Trabalhos futuros.....................................................................................................................406.1 Conclusão.................................................................................................................................40

ANEXOS............................................................................................................................................43Math.java.......................................................................................................................................43MathService.wsdl..........................................................................................................................43MathPortType.java........................................................................................................................47MathServiceGridLocator.java........................................................................................................47MathService.java...........................................................................................................................48MathServiceLocator.java...............................................................................................................49MathServiceSoapBindingStub.java...............................................................................................52MathImpl.java................................................................................................................................56Math.wsdd......................................................................................................................................57Build.xml.......................................................................................................................................58

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

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

Índice de FigurasFigura 1 - Camadas da arquitetura de protocolo do Globus...............................................................22Figura 2 - Exemplo de invocação de um web service........................................................................26Figura 3 - Arquitetura de um web service..........................................................................................27Figura 4 - Componentes de um Grid Service.....................................................................................29Figura 5 - Modelos de desenvolvimento de Grid Services.................................................................31

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

8

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

9

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.

10

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

11

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.

12

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.

Um cluster típico apresenta as seguintes características[2]:

13

• 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].

14

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;

• não ter que cumprir prazos rigorosos de execução.

15

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;

16

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

17

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.

18

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;

19

• 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

20

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.

21

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.

22

Figura 1 - Camadas da arquitetura de protocolo doGlobus

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.

23

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 é a próxima geração da Internet”[9].

“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

24

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.

25

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.

26

Figura 2 - Exemplo de invocação 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.

27

Figura 3 - Arquitetura de um webservice

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.

28

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.

29

Figura 4 - Componentes de um Grid Service

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

30

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,

MathService.java, MathServiceLocator.java e MathServiceSoapBindingStub.java podem ser

31

Figura 5 - Modelos de desenvolvimento de Grid Services

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

32

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 dogrid>/nome, o formato da URL é tipicamentehttp://<host>:<porta>/ogsa/services

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

<parameter name= “className”...> O parâmetro className especifica uma classe ouinterface que possui métodos públicos emcorrespondência com todas as operações wsdl.

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

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

<parameter name= “persistent” ...> Este parâmetro diferencia o grid service dos webservices comuns em execução no servidor. Se esteparâ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 deinterface de serviço WSDL.

<parameter name= “instance schemaPath”...> No caso de um grid service que utiliza o padrãofactory é necessário indicar neste parâmetro alocalização do arquivo de interface do serviço que iráser criado.

<parameter name= “handlerClass”...> Indica o nome da classe que efetua despachos, no casodo Globus éorg.globus.ogsa.handlers.RPCURIProvider

<parameter name= “factoryCallBack”...> Este parâmetro aponta para uma classe queimplementa a interface usada para criar instâncias deserviç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.

33

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

MathClient2.java.

34

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.

35

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

36

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

37

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

O sistema computacional utilizado para realizar os testes está descrito abaixo:

38

ProcessadorIntel Pentium IV HyperThreading com SMP

habilitado, o que permitiu ao kernel do sistemaoperacional 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

Tabela 3 - Configuração de software utilizada

39

6 Trabalhos futuros e conclusão

Nas seções seguintes orientações para trabalhos futuros e a conclusão.

6.2 Trabalhos futuros

Uma das possibilidades mais fascinantes da pesquisa com grids é a possibilidade de poder trazer

todo o poder computacional para dentro de dispositivos móveis como PDA's ou telefones celulares.

Este avanço é possível e já existem tecnologias que permitem que este salto seja dado.

O protocolo SyncML permite a sincronização de dispositivos móveis com servidores através de

protocolo WAP, SMS ou GPRS. Estes pontos de acesso poderiam estar presentes em Grid Portals,

que são interfaces Web para os recursos de um ambiente de Grid Computacional. Diversas artigos

documentam a criação e manutenção de um Grid Portal.

Grid computacionais também poderiam ser acessadas a partir de qualquer ponto de conexão

com a Internet e a autenticação e subseqüente autorização poderia ser garantida e verificada por

smart cards. O suporte a esses dispositivos já existe na GSI.

Outro rumo que a pesquisa poderia tomar é no desenvolvimento de infraestruturas para o

gerenciamento e acesso de alto desempenho a grandes quantidades de dados (terabytes ou

petabytes).

E finalmente o aprimoramento da infraestrutura de gerenciamento de recursos para suporte ao

monitoramento fim a fim e tolerância a falhas através de um escalonamento de rede, agendamento

antecipado ("advance reservations") e autorização baseado em políticas.

6.1 Conclusão

Toda nova tecnologia atravessa um Ciclo de Euforia[18] composto por cinco fases: novidade,

euforia, desilusão, esclarecimento e produtividade. Isso não é diferente com a tecnologia que

envolve a construção e operação dos ambientes de grid computacional, que nessa etapa se encontra

muito próxima do pico de euforia.

Porém a possibilidade e realizar efetiva computação colaborativa, computação de alto

desempenho a um custo reduzido, outsourcing de recursos computacionais e os benefícios que

diversos ramos da indústria e ciência podem vir a usufruir, exigem que o papel da comunidade de

cientistas da computação seja no sentido de torná-la uma tecnologia produtiva o mais brevemente

possível.

40

Os esforços na definição de padrões estão sendo liderados pelo Global Grid Forum, que

contribui com uma infraestrutura que já é utilizada de fato em aplicações de mercado e centros de

pesquisa, o Globus Toolkit. Numerosos desenvolvedores estão se dedicando à tarefa de tornar cada

vez mais fácil e rápido o desenvolvimento de novas aplicações e a migração de sistemas legados

para este novo paradigma.

Neste trabalho foi construído e configurado com exito um ambiente de grid computacional; foi

desenvolvida uma aplicação exemplo e definidas linhas mestras para o desenvolvimento futuro de

outras aplicações mais complexas. Deve ser visto como uma introdução ao desenvolvimento de

aplicações nesta área resultante da convergência da computação distribuída e da computação de alto

desempenho. O tema já ensinado em universidades brasileiras e constantemente visitado por artigos,

tutoriais e workshops nos congressos de computação.

A plataforma de software para operação dos ambientes de grid computacional é em grande parte

oferecida sob a licença de software livre ou bastante permissivas garantindo que governos,

instituições e empresas tenham acesso à tecnologia.

Assim é apenas uma questão de tempo para sua popularização e adoção em ambientes diversos.

41

Referências bibliográficas

[1] CERN, Grid Café, 2003, http://gridcafe.web.cern.ch/gridcafe.

[2] Alvarenga, Anderson T. H.; Dissertation; Um ambiente para processamento paralelo

oportunístico na Internet, 2003

[3] Silberschatz, A.; Peterson, J., Operating Systems Concepts, 1985.

[4] Grimshaw, Andrew S.; Article; Metasystems: An Approach Combining Parallel Processing

and Heterogeneous Distributed Computing Systems.

[5] Buyya, Rakumar, GRIDInfoware, 2003, http://www.gridcomputing.com.

[6] Shirky, Clay, What is P2P...and what isn't?, 2000, http://www.openp2p.com.

[7] Cirne, Walfredo; Article; Grids Computacionais: Arquiteturas, Tecnologias, Aplicações.

[8] Globus Alliance, Globus FAQ, 2003, http://www.globus.orb/about/faq.html.

[9] Foster, I.;Tuecke, S.; Journal; The Anatomy of the Grid: Enabling Scalable Virtual

Organizations, 2001.

[10] Leinberber, W.; Article; Information Power Grid: The New Frontier in Parallel Computing?.

[11] Foster, I.; Kesselman, J.; Nick J.; Tuecke, S.; Article; The Phisiology of the Grid: An Open

Grid Services Architecture for Distributed Systems Integration.

[12] Tuecke, S.; Czajkowski, K.; Foster, I.; Frey, J.; Graham, S.; Kesselman, C.; Maguire, T.;

Sandholm, T.; Vanderbilt, P.; Snelling, D.; Techn. documentation; Open Grid Services

Infrastructure. 2003.

[13] Dantas, M.A.R., Tecnologias de Redes de Comunicação e Computadores, 2002.

[14] Foster, I.; Frey, J.; Graham, S.; Tuecke, S.; Czajkowski, K.; Ferguson, D.; Leymann, F.; Nally,

M.; Storey, T.; Vambenepe, W.; Weerawarana, S.; Article; Modeling Stateful Resources with Web

Services.

[15] Sotomayor, B., The Globus Toolkit 3 Programmer's Tutorial, 2003, http://www.casa-

sotomayor.net/gt3-tutorial.

[16] Laszewski, G.; Foster, I.; Gawor, J.; Lane, P.; Article; A Java Commodity Grid Kit.

[17] Globus Alliance; Techn. documentation; Java Programmer's Guide Core Framework. 2003.

[18] Gartner Group, Hype Cycles, 1995, http://www.gartner.com/pages/story.php.id.8795.s.8.jsp.

42

ANEXOS

Nos itens seguintes e apresentada a listagem dos códigos fontes da aplicação exemplo

desenvolvida neste trabalho.

Math.java

package gt3tutorial.core.factory.impl;

public interface Math{ public void soma(int a); public void subtracao(int a); public int getValue();}

MathService.wsdl

<?xml version="1.0" encoding="UTF-8"?><wsdl:definitions targetNamespace="http://first.core.gt3tutorial/Math"

xmlns="http://schemas.xmlsoap.org/wsdl/"xmlns:apachesoap="http://xml.apache.org/xml-soap"xmlns:gridservicesoapbinding="http://www.gridforum.org/namespaces/2003/03/OGSI/bindings" xmlns:impl="http://first.core.gt3tutorial/Math"xmlns:intf="http://first.core.gt3tutorial/Math"xmlns:soapenc="http://schemas.xmlsoap.org/soap/encoding/"xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/"xmlns:wsdlsoap="http://schemas.xmlsoap.org/wsdl/soap/"xmlns:xsd="http://www.w3.org/2001/XMLSchema"><wsdl:importlocation="../schema/ogsi/ogsi_bindings.wsdl"namespace="http://www.gridforum.org/namespaces/2003/03/OGSI/bindings"/>

<wsdl:message name="multiplyRequest">

<wsdl:part name="in0" type="xsd:int"/>


</wsdl:message>

<wsdl:message name="subtractResponse">

<wsdl:part name="subtractReturn" type="xsd:int"/>

</wsdl:message>

<wsdl:message name="divideRequest">



43

</wsdl:message>

<wsdl:message name="addResponse">

<wsdl:part name="addReturn" type="xsd:int"/>

</wsdl:message>

<wsdl:message name="addRequest">



</wsdl:message>

<wsdl:message name="subtractRequest">



</wsdl:message>

<wsdl:message name="multiplyResponse">

<wsdl:part name="multiplyReturn" type="xsd:int"/>

</wsdl:message>

<wsdl:message name="divideResponse">

<wsdl:part name="divideReturn" type="xsd:float"/>

</wsdl:message>

<wsdl:portType name="MathPortType">

<wsdl:operation name="add" parameterOrder="in0 in1">

<wsdl:input message="impl:addRequest" name="addRequest"/>

<wsdl:output message="impl:addResponse" name="addResponse"/>

</wsdl:operation>

<wsdl:operation name="divide" parameterOrder="in0 in1">

<wsdl:input message="impl:divideRequest" name="divideRequest"/>

<wsdl:output message="impl:divideResponse" name="divideResponse"/>

</wsdl:operation>

<wsdl:operation name="multiply" parameterOrder="in0 in1">

<wsdl:input message="impl:multiplyRequest" name="multiplyRequest"/>

<wsdl:output message="impl:multiplyResponse"

44

name="multiplyResponse"/>

</wsdl:operation>

<wsdl:operation name="subtract" parameterOrder="in0 in1">

<wsdl:input message="impl:subtractRequest" name="subtractRequest"/>

<wsdl:output message="impl:subtractResponse"name="subtractResponse"/>

</wsdl:operation>

</wsdl:portType>

<wsdl:binding name="MathServiceSoapBinding" type="impl:MathPortType">

<wsdlsoap:binding style="rpc"transport="http://schemas.xmlsoap.org/soap/http"/>

<wsdl:operation name="add">

<wsdlsoap:operation soapAction=""/>

<wsdl:input name="addRequest">

<wsdlsoap:bodyencodingStyle="http://schemas.xmlsoap.org/soap/encoding/"namespace="http://first.core.gt3tutorial/Math" use="encoded"/>

</wsdl:input>

<wsdl:output name="addResponse">


</wsdl:output>

</wsdl:operation>

<wsdl:operation name="divide">


<wsdl:input name="divideRequest">


</wsdl:input>

<wsdl:output name="divideResponse">


45

</wsdl:output>

</wsdl:operation>

<wsdl:operation name="multiply">


<wsdl:input name="multiplyRequest">


</wsdl:input>

<wsdl:output name="multiplyResponse">


</wsdl:output>

</wsdl:operation>

<wsdl:operation name="subtract">


<wsdl:input name="subtractRequest">


</wsdl:input>

<wsdl:output name="subtractResponse">


</wsdl:output>

</wsdl:operation>

</wsdl:binding>

<wsdl:service name="MathService">

<wsdl:port binding="impl:MathServiceSoapBinding" name="MathService">

<wsdlsoap:addresslocation="http://localhost/ogsa/services/core/first/MathService"/>

</wsdl:port>

46

<wsdl:port binding="gridservicesoapbinding:GridServiceSOAPBinding"name="GridServiceSOAPBindingPort"><wsdlsoap:addresslocation="http://localhost/ogsa/services/core/first/MathService"/></wsdl:port></wsdl:service>

</wsdl:definitions>

MathPortType.java

/** * MathPortType.java * * This file was auto-generated from WSDL * by the Apache Axis WSDL2Java emitter. */

package gt3tutorial.core.first.Math;

public interface MathPortType extends java.rmi.Remote { public int add(int in0, int in1) throws java.rmi.RemoteException; public float divide(int in0, int in1) throws java.rmi.RemoteException; public int multiply(int in0, int in1) throws java.rmi.RemoteException; public int subtract(int in0, int in1) throws java.rmi.RemoteException;}

MathServiceGridLocator.java

/** * MathServiceGridLocator.java * * This file was auto-generated from WSDL * by the Apache Axis WSDL2Java emitter. */


public class MathServiceGridLocator extendsorg.globus.ogsa.impl.core.service.ServiceLocator implementsorg.globus.ogsa.GridLocator { public gt3tutorial.core.first.Math.MathPortType getMathService

(org.gridforum.ogsi.HandleType handle) throws org.gridforum.ogsi.FaultType,org.globus.ogsa.GridServiceException { setStubClass

(gt3tutorial.core.first.Math.MathServiceSoapBindingStub.class); return (gt3tutorial.core.first.Math.MathPortType) getServicePort

(handle); } public gt3tutorial.core.first.Math.MathPortType getMathService

(org.gridforum.ogsi.LocatorType locator) throws org.gridforum.ogsi.FaultType,org.globus.ogsa.GridServiceException { setStubClass

(gt3tutorial.core.first.Math.MathServiceSoapBindingStub.class); return (gt3tutorial.core.first.Math.MathPortType) getServicePort

(locator);

47

} public gt3tutorial.core.first.Math.MathPortType getMathService

(java.net.URL url) throws org.globus.ogsa.GridServiceException { setStubClass

(gt3tutorial.core.first.Math.MathServiceSoapBindingStub.class); return (gt3tutorial.core.first.Math.MathPortType) getServicePort(url); } public org.gridforum.ogsi.GridService getGridServiceSOAPBindingPort

(org.gridforum.ogsi.HandleType handle) throws org.gridforum.ogsi.FaultType,org.globus.ogsa.GridServiceException { setStubClass

(org.gridforum.ogsi.bindings.GridServiceSOAPBindingStub.class); return (org.gridforum.ogsi.GridService) getServicePort(handle); } public org.gridforum.ogsi.GridService getGridServiceSOAPBindingPort

(org.gridforum.ogsi.LocatorType locator) throws org.gridforum.ogsi.FaultType,org.globus.ogsa.GridServiceException { setStubClass

(org.gridforum.ogsi.bindings.GridServiceSOAPBindingStub.class); return (org.gridforum.ogsi.GridService) getServicePort(locator); } public org.gridforum.ogsi.GridService getGridServiceSOAPBindingPort

(java.net.URL url) throws org.globus.ogsa.GridServiceException { setStubClass

(org.gridforum.ogsi.bindings.GridServiceSOAPBindingStub.class); return (org.gridforum.ogsi.GridService) getServicePort(url); }

}

MathService.java

/** * MathService.java * * This file was auto-generated from WSDL * by the Apache Axis WSDL2Java emitter. */


public interface MathService extends javax.xml.rpc.Service { public java.lang.String getMathServiceAddress();

public gt3tutorial.core.first.Math.MathPortType getMathService() throwsjavax.xml.rpc.ServiceException;

public gt3tutorial.core.first.Math.MathPortType getMathService(java.net.URL portAddress) throws javax.xml.rpc.ServiceException; public java.lang.String getGridServiceSOAPBindingPortAddress();

public org.gridforum.ogsi.GridService getGridServiceSOAPBindingPort()throws javax.xml.rpc.ServiceException;

public org.gridforum.ogsi.GridService getGridServiceSOAPBindingPort(java.net.URL portAddress) throws javax.xml.rpc.ServiceException;}

48

MathServiceLocator.java

/** * MathServiceLocator.java * * This file was auto-generated from WSDL * by the Apache Axis WSDL2Java emitter. */


public class MathServiceLocator extends org.apache.axis.client.Serviceimplements gt3tutorial.core.first.Math.MathService {

// Use to get a proxy class for MathService private final java.lang.String MathService_address =

"http://localhost/ogsa/services/core/first/MathService";

public java.lang.String getMathServiceAddress() { return MathService_address; }

// The WSDD service name defaults to the port name. private java.lang.String MathServiceWSDDServiceName = "MathService";

public java.lang.String getMathServiceWSDDServiceName() { return MathServiceWSDDServiceName; }

public void setMathServiceWSDDServiceName(java.lang.String name) { MathServiceWSDDServiceName = name; }

public gt3tutorial.core.first.Math.MathPortType getMathService() throwsjavax.xml.rpc.ServiceException { java.net.URL endpoint; try { endpoint = new java.net.URL(MathService_address); } catch (java.net.MalformedURLException e) { throw new javax.xml.rpc.ServiceException(e); } return getMathService(endpoint); }

public gt3tutorial.core.first.Math.MathPortType getMathService(java.net.URL portAddress) throws javax.xml.rpc.ServiceException { try { gt3tutorial.core.first.Math.MathServiceSoapBindingStub _stub = new

gt3tutorial.core.first.Math.MathServiceSoapBindingStub(portAddress, this); _stub.setPortName(getMathServiceWSDDServiceName()); return _stub; } catch (org.apache.axis.AxisFault e) { return null; } }

49

// Use to get a proxy class for GridServiceSOAPBindingPort private final java.lang.String GridServiceSOAPBindingPort_address =

"http://localhost/ogsa/services/core/first/MathService";

public java.lang.String getGridServiceSOAPBindingPortAddress() { return GridServiceSOAPBindingPort_address; }

// The WSDD service name defaults to the port name. private java.lang.String GridServiceSOAPBindingPortWSDDServiceName =

"GridServiceSOAPBindingPort";

public java.lang.String getGridServiceSOAPBindingPortWSDDServiceName() { return GridServiceSOAPBindingPortWSDDServiceName; }

public void setGridServiceSOAPBindingPortWSDDServiceName(java.lang.Stringname) { GridServiceSOAPBindingPortWSDDServiceName = name; }

public org.gridforum.ogsi.GridService getGridServiceSOAPBindingPort()throws javax.xml.rpc.ServiceException { java.net.URL endpoint; try { endpoint = new java.net.URL(GridServiceSOAPBindingPort_address); } catch (java.net.MalformedURLException e) { throw new javax.xml.rpc.ServiceException(e); } return getGridServiceSOAPBindingPort(endpoint); }

public org.gridforum.ogsi.GridService getGridServiceSOAPBindingPort(java.net.URL portAddress) throws javax.xml.rpc.ServiceException { try { org.gridforum.ogsi.bindings.GridServiceSOAPBindingStub _stub = new

org.gridforum.ogsi.bindings.GridServiceSOAPBindingStub(portAddress, this); _stub.setPortName(getGridServiceSOAPBindingPortWSDDServiceName()); return _stub; } catch (org.apache.axis.AxisFault e) { return null; } }

/** * For the given interface, get the stub implementation. * If this service has no port for the given interface, * then ServiceException is thrown. */ public java.rmi.Remote getPort(Class serviceEndpointInterface) throws

javax.xml.rpc.ServiceException { try { if

(gt3tutorial.core.first.Math.MathPortType.class.isAssignableFrom(serviceEndpointInterface)) { gt3tutorial.core.first.Math.MathServiceSoapBindingStub _stub =

50

new gt3tutorial.core.first.Math.MathServiceSoapBindingStub(new java.net.URL(MathService_address), this); _stub.setPortName(getMathServiceWSDDServiceName()); return _stub; } if (org.gridforum.ogsi.GridService.class.isAssignableFrom

(serviceEndpointInterface)) { org.gridforum.ogsi.bindings.GridServiceSOAPBindingStub _stub =

new org.gridforum.ogsi.bindings.GridServiceSOAPBindingStub(new java.net.URL(GridServiceSOAPBindingPort_address), this); _stub.setPortName(getGridServiceSOAPBindingPortWSDDServiceName

()); return _stub; } } catch (java.lang.Throwable t) { throw new javax.xml.rpc.ServiceException(t); } throw new javax.xml.rpc.ServiceException("There is no stub

implementation for the interface: " + (serviceEndpointInterface == null ?"null" : serviceEndpointInterface.getName())); }

/** * For the given interface, get the stub implementation. * If this service has no port for the given interface, * then ServiceException is thrown. */ public java.rmi.Remote getPort(javax.xml.namespace.QName portName, Class

serviceEndpointInterface) throws javax.xml.rpc.ServiceException { if (portName == null) { return getPort(serviceEndpointInterface); } String inputPortName = portName.getLocalPart(); if ("MathService".equals(inputPortName)) { return getMathService(); } else if ("GridServiceSOAPBindingPort".equals(inputPortName)) { return getGridServiceSOAPBindingPort(); } else { java.rmi.Remote _stub = getPort(serviceEndpointInterface); ((org.apache.axis.client.Stub) _stub).setPortName(portName); return _stub; } }

public javax.xml.namespace.QName getServiceName() { return new javax.xml.namespace.QName

("http://first.core.gt3tutorial/Math", "MathService"); }

private java.util.HashSet ports = null;

public java.util.Iterator getPorts() { if (ports == null) { ports = new java.util.HashSet(); ports.add(new javax.xml.namespace.QName("MathService")); ports.add(new javax.xml.namespace.QName

51

("GridServiceSOAPBindingPort")); } return ports.iterator(); }

}

MathServiceSoapBindingStub.java

/** * MathServiceSoapBindingStub.java * * This file was auto-generated from WSDL * by the Apache Axis WSDL2Java emitter. */


public class MathServiceSoapBindingStub extends org.apache.axis.client.Stubimplements gt3tutorial.core.first.Math.MathPortType { private java.util.Vector cachedSerClasses = new java.util.Vector(); private java.util.Vector cachedSerQNames = new java.util.Vector(); private java.util.Vector cachedSerFactories = new java.util.Vector(); private java.util.Vector cachedDeserFactories = new java.util.Vector();

static org.apache.axis.description.OperationDesc [] _operations;

static { _operations = new org.apache.axis.description.OperationDesc[4]; org.apache.axis.description.OperationDesc oper; oper = new org.apache.axis.description.OperationDesc(); oper.setName("add"); oper.addParameter(new javax.xml.namespace.QName("", "in0"), new

javax.xml.namespace.QName("http://www.w3.org/2001/XMLSchema", "int"),int.class, org.apache.axis.description.ParameterDesc.IN, false, false); oper.addParameter(new javax.xml.namespace.QName("", "in1"), new

javax.xml.namespace.QName("http://www.w3.org/2001/XMLSchema", "int"),int.class, org.apache.axis.description.ParameterDesc.IN, false, false); oper.setReturnType(new javax.xml.namespace.QName

("http://www.w3.org/2001/XMLSchema", "int")); oper.setReturnClass(int.class); oper.setReturnQName(new javax.xml.namespace.QName("", "addReturn")); oper.setStyle(org.apache.axis.enum.Style.RPC); oper.setUse(org.apache.axis.enum.Use.ENCODED); _operations[0] = oper;

oper = new org.apache.axis.description.OperationDesc(); oper.setName("divide"); oper.addParameter(new javax.xml.namespace.QName("", "in0"), new



("http://www.w3.org/2001/XMLSchema", "float")); oper.setReturnClass(float.class);

52

oper.setReturnQName(new javax.xml.namespace.QName("","divideReturn")); oper.setStyle(org.apache.axis.enum.Style.RPC); oper.setUse(org.apache.axis.enum.Use.ENCODED); _operations[1] = oper;

oper = new org.apache.axis.description.OperationDesc(); oper.setName("multiply"); oper.addParameter(new javax.xml.namespace.QName("", "in0"), new



("http://www.w3.org/2001/XMLSchema", "int")); oper.setReturnClass(int.class); oper.setReturnQName(new javax.xml.namespace.QName("",

"multiplyReturn")); oper.setStyle(org.apache.axis.enum.Style.RPC); oper.setUse(org.apache.axis.enum.Use.ENCODED); _operations[2] = oper;

oper = new org.apache.axis.description.OperationDesc(); oper.setName("subtract"); oper.addParameter(new javax.xml.namespace.QName("", "in0"), new



("http://www.w3.org/2001/XMLSchema", "int")); oper.setReturnClass(int.class); oper.setReturnQName(new javax.xml.namespace.QName("",

"subtractReturn")); oper.setStyle(org.apache.axis.enum.Style.RPC); oper.setUse(org.apache.axis.enum.Use.ENCODED); _operations[3] = oper;

}

public MathServiceSoapBindingStub() throws org.apache.axis.AxisFault { this(null); }

public MathServiceSoapBindingStub(java.net.URL endpointURL,javax.xml.rpc.Service service) throws org.apache.axis.AxisFault { this(service); super.cachedEndpoint = endpointURL; }

public MathServiceSoapBindingStub(javax.xml.rpc.Service service) throwsorg.apache.axis.AxisFault { if (service == null) { super.service = new org.apache.axis.client.Service(); } else { super.service = service; }

53

}

private org.apache.axis.client.Call createCall() throwsjava.rmi.RemoteException { try { org.apache.axis.client.Call _call = (org.apache.axis.client.Call) super.service.createCall(); if (super.maintainSessionSet) { _call.setMaintainSession(super.maintainSession); } if (super.cachedUsername != null) { _call.setUsername(super.cachedUsername); } if (super.cachedPassword != null) { _call.setPassword(super.cachedPassword); } if (super.cachedEndpoint != null) { _call.setTargetEndpointAddress(super.cachedEndpoint); } if (super.cachedTimeout != null) { _call.setTimeout(super.cachedTimeout); } if (super.cachedPortName != null) { _call.setPortName(super.cachedPortName); } java.util.Enumeration keys = super.cachedProperties.keys(); while (keys.hasMoreElements()) { java.lang.String key = (java.lang.String) keys.nextElement(); _call.setProperty(key, super.cachedProperties.get(key)); } return _call; } catch (java.lang.Throwable t) { throw new org.apache.axis.AxisFault("Failure trying to get the

Call object", t); } }

public int add(int in0, int in1) throws java.rmi.RemoteException { if (super.cachedEndpoint == null) { throw new org.apache.axis.NoEndPointException(); } org.apache.axis.client.Call _call = createCall(); _call.setOperation(_operations[0]); _call.setUseSOAPAction(true); _call.setSOAPActionURI(""); _call.setSOAPVersion

(org.apache.axis.soap.SOAPConstants.SOAP11_CONSTANTS); _call.setOperationName(new javax.xml.namespace.QName

("http://first.core.gt3tutorial/Math", "add"));

setRequestHeaders(_call); setAttachments(_call); java.lang.Object _resp = _call.invoke(new java.lang.Object[] {new

java.lang.Integer(in0), new java.lang.Integer(in1)});

if (_resp instanceof java.rmi.RemoteException) { throw (java.rmi.RemoteException)_resp; }

54

else { extractAttachments(_call); try { return ((java.lang.Integer) _resp).intValue(); } catch (java.lang.Exception _exception) { return ((java.lang.Integer)

org.apache.axis.utils.JavaUtils.convert(_resp, int.class)).intValue(); } } }

public float divide(int in0, int in1) throws java.rmi.RemoteException { if (super.cachedEndpoint == null) { throw new org.apache.axis.NoEndPointException(); } org.apache.axis.client.Call _call = createCall(); _call.setOperation(_operations[1]); _call.setUseSOAPAction(true); _call.setSOAPActionURI(""); _call.setSOAPVersion


("http://first.core.gt3tutorial/Math", "divide"));



if (_resp instanceof java.rmi.RemoteException) { throw (java.rmi.RemoteException)_resp; } else { extractAttachments(_call); try { return ((java.lang.Float) _resp).floatValue(); } catch (java.lang.Exception _exception) { return ((java.lang.Float)

org.apache.axis.utils.JavaUtils.convert(_resp, float.class)).floatValue(); } } }

public int multiply(int in0, int in1) throws java.rmi.RemoteException { if (super.cachedEndpoint == null) { throw new org.apache.axis.NoEndPointException(); } org.apache.axis.client.Call _call = createCall(); _call.setOperation(_operations[2]); _call.setUseSOAPAction(true); _call.setSOAPActionURI(""); _call.setSOAPVersion


("http://first.core.gt3tutorial/Math", "multiply"));


55


if (_resp instanceof java.rmi.RemoteException) { throw (java.rmi.RemoteException)_resp; } else { extractAttachments(_call); try { return ((java.lang.Integer) _resp).intValue(); } catch (java.lang.Exception _exception) { return ((java.lang.Integer)


public int subtract(int in0, int in1) throws java.rmi.RemoteException { if (super.cachedEndpoint == null) { throw new org.apache.axis.NoEndPointException(); } org.apache.axis.client.Call _call = createCall(); _call.setOperation(_operations[3]); _call.setUseSOAPAction(true); _call.setSOAPActionURI(""); _call.setSOAPVersion


("http://first.core.gt3tutorial/Math", "subtract"));



if (_resp instanceof java.rmi.RemoteException) { throw (java.rmi.RemoteException)_resp; } else { extractAttachments(_call); try { return ((java.lang.Integer) _resp).intValue(); } catch (java.lang.Exception _exception) { return ((java.lang.Integer)


}

MathImpl.java

package gt3tutorial.core.factory.impl;

import org.globus.ogsa.impl.ogsi.GridServiceImpl;import gt3tutorial.core.factory.Math.MathPortType;import java.rmi.RemoteException;

56

public class MathImpl extends GridServiceImpl implements MathPortType{ private int value = 0;

public MathImpl() { super("Grid Service Exemplo para Operações Aritméticas"); }

public void add(int a) throws RemoteException { value = value + a; } public void subtract(int a) throws RemoteException { value = value - a; } public int getValue() throws RemoteException { return value; }}

Math.wsdd

<?xml version="1.0"?><deployment name="defaultServerConfig"

xmlns="http://xml.apache.org/axis/wsdd/" xmlns:java="http://xml.apache.org/axis/wsdd/providers/java">

<service name="tutorial/core/factory/MathFactoryService"provider="Handler" style="wrapped"> <parameter name="name" value="MathService Factory"/> <parameter name="instance-name" value="MathService Instance"/> <parameter name="instance-schemaPath" value="schema/gt3tutorial.core.factory/Math/MathService.wsdl"/> <parameter name="instance-baseClassName" value="gt3tutorial.core.factory.impl.MathImpl"/>

 <parameter name="allowedMethods" value="*"/> <parameter name="persistent" value="true"/> <parameter name="className" value="org.gridforum.ogsi.Factory"/> <parameter name="baseClassName" value="org.globus.ogsa.impl.ogsi.PersistentGridServiceImpl"/> <parameter name="schemaPath" value="schema/ogsi/ogsi_factory_service.wsdl"/> <parameter name="handlerClass" value="org.globus.ogsa.handlers.RPCURIProvider"/> <parameter name="factoryCallback" value="org.globus.ogsa.impl.ogsi.DynamicFactoryCallbackImpl"/>

57

<parameter name="operationProviders" value="org.globus.ogsa.impl.ogsi.FactoryProvider"/> </service></deployment>

Build.xml

<?xml version="1.0"?>

<project default="all" basedir=".">



<property file="build.properties"/> <property file="${user.home}/build.properties"/>

<path id="classpath"> <pathelement location="${java.home}/../lib/tools.jar"/>

<pathelement location="./"/> <pathelement location="${build.dest}"/> <fileset dir="lib"> <include name="*.jar"/> </fileset> <fileset dir="${ogsa.root}/lib"> <include name="*.jar"/> </fileset> <pathelement path="${java.class.path}"/> </path>

<property name="src.dir" value="./"/> <property name="build.dir" value="./build"/> <property name="build.lib" value="${build.dir}/lib"/> <property name="build.stubs" value="${build.dir}/stubs"/> <property name="build.dest" value="${build.dir}/classes"/> <property name="build.schema" value="${build.dir}/schema"/> <property name="build.services" value="${ogsa.root}/build-services.xml"/> <property name="build.packages" value="${ogsa.root}/build-packages.xml"/> <property name="schema.origin" value="${ogsa.root}/schema"/> <property name="stubs.dest" value="../stubs"/> <property file="${ogsa.root}/ogsa.properties"/> <property name="mapping.file" value="namespace2package.mappings"/>

<target name="copyFiles"> <mkdir dir="${build.dest}"/> <mkdir dir="${build.lib}"/> <mkdir dir="${build.schema}"/> <mkdir dir="${build.stubs}"/> <mkdir dir="${lib.dir}"/> 

58

<copy toDir="${build.schema}"> <fileset dir="${schema.origin}"/> </copy> <available file="${mapping.file}" property="mapping.file.present"/> </target>

<target name="mergeMapping" if="mapping.file.present"> <ant antfile="${build.services}" target="mergePackageMapping" /> </target>

<target name="setenv" depends="copyFiles,mergeMapping" />

<target name="generateWSDLfromJava" if="java.interface" depends="setenv"> <property name="schema.file" value="${interface.name}Service.wsdl"/> <ant antfile="${build.services}" target="generateWSDL"> <property name="interface" value="${package.dir}/impl/${interface.name}.

java"/> <property name="interface.package" value="${package}.impl"/>  <property name="interface.dir" value="${package.dir}/impl"/> <property name="generated.dir" value="${package}"/> </ant> </target>

<target name="generateWSDLfromGWSDL" if="gwsdl.interface" depends="setenv"> <property name="schema.file" value="${interface.name}_service.wsdl"/>

<copy todir="${build.schema}/${package}/${interface.name}"overwrite="true"> <fileset dir="${package.dir}/schema"/> </copy>

<ant antfile="${build.services}" target="GWSDL2WSDL"> <property name="build.schema.dir" value="${package}/${interface.name}"/> <property name="wsdl.root" value="${interface.name}"/> </ant>

<ant antfile="${build.services}" target="generateBinding"> <property name="binding.root" value="${interface.name}"/> <property name="build.schema.dir" value="${package}/${interface.name}"/> <property name="porttype.wsdl" value="${interface.name}.wsdl"/> </ant> </target>



<target name="stubs" unless="stubs.present" depends="setenv,generateWSDLfromJava, generateWSDLfromGWSDL"> <ant antfile="${build.services}" target="generateStubs">

59

<property name="schema.file.dir" value="${package}/${interface.name}"/> <property name="schema.file" value="${schema.file}"/> </ant> </target>

<target name="compileStubs" depends="stubs"> <javac srcdir="${build.stubs}" destdir="${build.dest}" debug="${debug}" deprecation="${deprecation}" classpathref="classpath"> </javac> </target>

<target name="compile" depends="compileStubs"> <javac srcdir="${package.dir}/impl" destdir="${build.dest}"

debug="${debug}" deprecation="${deprecation}" classpathref="classpath"> </javac> </target>

<target name="stubjar" depends="compile"> <jar jarfile="${build.lib}/${package}.${interface.name}-stub.jar"

basedir="${build.dest}" > <include name="**/${package.dir}/**" /> <exclude name="**/${package.dir}/impl/**" /> <exclude name="**/${package.dir}/client/**" /> <exclude name="**/${package.dir}/schema/**" /> </jar> </target>

<target name="jar" depends="stubjar"> <jar jarfile="${build.lib}/${package}.${interface.name}.jar"

basedir="${build.dest}" > <include name="**/${package.dir}/impl/**" /> <exclude name="**/${package.dir}/impl/${interface.name}.class" /> </jar> </target>

<target name="gar" depends="jar"> <copy todir="${build.lib}"> <fileset dir="${lib.dir}"> <include name="**/*.jar"/> </fileset> </copy> <ant antfile="${build.packages}" target="makeGar"> <property name="gar.name" value="${build.lib}/${package}.${interface.

name}.gar"/> <property name="garlib.dir" value="${build.lib}"/> <property name="garserverdeployment.file" value="${package.dir}/

${interface.name}.wsdd"/> <property name="garschema.origin" value="${build.schema}/${package}"/> <property name="garschema.path" value="${package}"/> </ant> </target>

<target name="compileClient" depends="setenv"> <javac srcdir="${src.dir}" destdir="${build.dest}" debug="${debug}" deprecation="${deprecation}" classpathref="classpath">

60

</javac> </target>

<target name="clean"> <delete dir="${build.dir}"/> </target>

<target name="all" depends="gar"/>

</project>

MathClient.java

package gt3tutorial.core.factory.client;

import gt3tutorial.core.factory.Math.MathServiceGridLocator;import gt3tutorial.core.factory.Math.MathPortType;import java.net.URL;

public class MathClient{ public static void main(String[] args) { try { URL GSH = new java.net.URL(args[0]); int a = Integer.parseInt(args[1]);

MathServiceGridLocator mathServiceLocator = newMathServiceGridLocator(); MathPortType math = mathServiceLocator.getMathService(GSH);

math.add(a); System.out.println("Somado o valor: " + a);

int value = math.getValue();

System.out.println("Valor atual: " + value);

}catch(Exception e) { System.out.println("ERRO!"); e.printStackTrace(); } }}

MathClient2.java

package gt3tutorial.core.factory.client;

import org.gridforum.ogsi.OGSIServiceGridLocator;import org.gridforum.ogsi.GridService;import org.gridforum.ogsi.Factory;

61

import org.gridforum.ogsi.LocatorType;import org.globus.ogsa.utils.GridServiceFactory;

import gt3tutorial.core.factory.Math.MathServiceGridLocator;import gt3tutorial.core.factory.Math.MathPortType;

import java.net.URL;

public class MathClient2{ public static void main(String[] args) { try { URL GSH = new java.net.URL(args[0]); int a = Integer.parseInt(args[1]);

OGSIServiceGridLocator gridLocator = new OGSIServiceGridLocator(); Factory factory = gridLocator.getFactoryPort(GSH); GridServiceFactory mathFactory = new GridServiceFactory(factory);

LocatorType locator = mathFactory.createService(); MathServiceGridLocator mathLocator = new MathServiceGridLocator(); MathPortType math = mathLocator.getMathService(locator);

math.add(a); System.out.println("Valor somado: " + a);

int value = math.getValue(); System.out.println("Valor atual: " + value); GridService gridService = gridLocator.getGridServicePort(locator); gridService.destroy(); }catch(Exception e) { System.out.println("ERRO!"); e.printStackTrace(); } }}

Artigo sobre o projeto

A partir da página seguinte é apresentado um artigo escrito sobre o mesmo tema do projeto

62

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

Documents

Transcript of Utilização de Web Services em Ambientes de Grid ...