InGriDE: Um Ambiente Integrado de
Desenvolvimento para Computa¸c˜ao em Grade
Eduardo Leal Guerra
Proposta de disserta¸c˜ao apresentada ao Instituto de Matem´atica e Estat´ıstica da
Universidade de S˜ao Paulo
como requisito parcial para qualica¸c˜ao de Mestre em Ciˆencia da Computa¸c˜ao.
Orientador: Prof. Dr. Alfredo Goldman
23 de janeiro de 2006
Resumo
Computa¸c˜ao em Grade tem se desenvolvido como um modelo computacional de nova gera¸c˜ao tanto no mundo cient´ıfico, quanto no comercial. A dissemina¸c˜ao desta tecnologia incentivou o desenvolvimento de v´arias ferramentas com o objetivo de faci- litar o acesso aos recursos da Grade. Entretanto, nenhuma dessas ferramentas fornece um ambiente completo que atenda as necessidades dos usu´ario e que se preocupe com a portabilidade das aplica¸c˜oes. Neste trabalho propomos InGriDE (Integrated Grid Development Environment), um ambiente integrado de desenvolvimento (IDE) para Computa¸c˜ao em Grade, que tem como objetivo fornecer ferramentas que facilitem todo o ciclo de desenvolvimento das aplica¸c˜oes de Grade. InGriDE foi desenvolvida usando o arcabou¸co Eclipse e baseado no modelo da Grid Application Toolkit (GAT), com o intuito de fornecer facilidade de uso e portabilidade. Atrav´es desta IDE esperamos aumentar a dissemina¸c˜ao da Computa¸c˜ao em Grade junto `a conunidade de usu´arios.
Sum´ ario
Resumo 2
1 Introdu¸c˜ao 5
2 Sistemas de Computa¸c˜ao em Grade 6
2.1 Condor . . . 7
2.2 Legion . . . 8
2.3 Globus . . . 9
2.4 SETI@home . . . 10
2.4.1 BOINC . . . 11
2.5 ProActive . . . 11
2.6 MyGrid . . . 12
2.6.1 OurGrid . . . 13
2.7 GridLab . . . 13
2.7.1 Grid Application Toolkit (GAT) . . . 14
3 Ferramentas para Computa¸c˜ao em Grade 16 3.1 Workflows . . . 17
3.1.1 P-GRADE . . . 18
3.2 Problem Solving Environments (PSEs) . . . 21
3.2.1 Triana . . . 21
3.3 Portais . . . 23
3.3.1 GridSphere . . . 24
3.4 Parameter Sweep Applications (PSAs) . . . 27
3.4.1 ILab . . . 27
3.5 Outras . . . 28
3.5.1 Interactive Control and Debugging of Distribution (ICD2) . . . 28
3.5.2 GT4IDE . . . 30
3.5.3 GriDE . . . 31
4 Descri¸c˜ao do Problema 32 5 Integrated Grid Development Environment (InGriDE) 33 5.1 InteGrade . . . 34
5.1.1 Ferramentas Existentes . . . 35
5.2 Eclipse . . . 37
5.3 Arquitetura . . . 38
5.3.1 Vis˜ao Geral . . . 38
5.3.2 Projeto de InGriDE . . . 38 5.4 Funcionalidades . . . 40 5.5 Integra¸c˜ao com outras Grades . . . 42
6 Plano de Trabalho 44
6.1 Descri¸c˜ao das Atividades . . . 44 6.2 Cronograma . . . 44
Referˆencias 45
1 Introdu¸c˜ ao
O crescimento da Internet e os avan¸cos nas tecnologias dos computadores e das redes vem mudando a forma como cientistas e engenheiros fazem computa¸c˜ao e como a sociedade gerencia a informa¸c˜ao. Essas novas tecnologias permitem a interliga¸c˜ao de v´arios recursos geograficamente distribu´ıdos, com o objetivo de serem utilizados como um ´unico e poderoso recurso. Este novo paradigma ´e popularmente chamado Computa¸c˜ao em Grade (Grid Computing) [PL05]. A Computa¸c˜ao em Grade e a uti- liza¸c˜ao da infra-estrutura global da Grade apresentou desafios significantes em todos os n´ıveis incluindo modelos conceituais e de implementa¸c˜ao, projeto e desenvolvimento de aplica¸c˜oes, sistemas de programa¸c˜ao, infra-estrutura e servi¸cos, gerenciamento de recursos, redes, e seguran¸ca.
A r´apida emergˆencia da Computa¸c˜ao em Grade como o paradigma dominante na computa¸c˜ao distribu´ıda vem acontecendo principalmente com o desenvolvimento de infra-estrutura e servi¸cos com a constru¸c˜ao dos Sistemas de Computa¸c˜ao em Grade, ou Grades Computacionais, ou middlewares. Uma Grade Computacional ´e uma infra- estrutura de software capaz de interligar e gerenciar diversos recursos distribu´ıdos ge- ograficamente, com o objetivo de oferecer ao usu´ario da Grade acesso transparente a estes recursos, independente de sua localiza¸c˜ao [GKG+04]. As principais Grades Com- putacionais, encabe¸cadas pelo sistema Globus, ser˜ao descritas na se¸c˜ao 2.
Apesar das Grades Computacionais fornecerem servi¸cos para o acesso aos recursos da Grade, este acesso ´e quase sempre complexo, exigindo que o usu´ario se ocupe com os detalhes do ambiente computacional. Visando facilitar este acesso, v´arias ferramentas vem sendo desenvolvidas neste sentido. Essas ferramentas caracterizam-se por agregar diferentes funcionalidades ao sistema de computa¸c˜ao base, fornecendo abstra¸c˜oes de diferentes n´ıveis. As principais iniciativas com mais alto n´ıvel de abstra¸c˜ao, e que mais se aproximam dos usu´arios s˜ao apresentadas na se¸c˜ao 3.
Atualmente, os principais usu´arios da Grade s˜ao cientistas desenvolvedores de a- plica¸c˜oes que n˜ao s˜ao especialistas na ´area de Computa¸c˜ao em Grade. Esses usu´arios n˜ao precisam, e nem tem o interesse, de conhecer os detalhes da estrutura da Grade para utiliz´a-la, o uso deve ser o mais f´acil poss´ıvel. Conforme a discuss˜ao apresentada na se¸c˜ao 4, as atuais ferramentas para a intera¸c˜ao com a Grade n˜ao atendem a esta necessidade pois cada uma se det´em em alguma funcionalidade espec´ıfica, n˜ao sendo integradas. Isso obriga o usu´ario a lidar com diversas delas para alcan¸car os seus objetivos, gerando um ambiente complexo de desenvolvimento. Outra problema dessas ferramentas ´e que normalmente suas funcionalidades e as aplica¸c˜oes escritas usando seus recursos s˜ao direcionadas a ambientes de execu¸c˜ao espec´ıficos. Todas essas limita¸c˜oes criam obst´aculos para a dissemina¸c˜ao da Computa¸c˜ao em Grade junto `a comunidade de usu´arios.
InGriDE ´e um ambiente integrado de desenvolvimento (IDE) para Computa¸c˜ao em Grade que visa resolver o problema descrito acima, fornecendo ferramentas integradas em um ´unico ambiente para atender todas as etapas do ciclo de desenvolvimento das aplica¸c˜oes de Grade. InGriDE, apresentado em detalhes na se¸c˜ao 5, est´a sendo cons- tru´ıdo usando o popular arcabou¸co para cria¸c˜ao de IDEs Eclipse [GB04], que se tem mostrado bastante ´util na integra¸c˜ao das ferramentas. Para atender `as quest˜oes de portabilidade, a arquitetura de InGriDE foi projetada baseada no modelo de portabi- lidade da Grid Application Toolkit (GAT) [ADG+05] do projeto GridLab. Na camada de mais baixo n´ıvel estamos utilizando como estudo de caso o middleware InteGrade, desenvolvido no nosso pr´oprio grupo de pesquisa.
Para viabilizar a nossa solu¸c˜ao em tempo h´abil, ao inv´es de utilizar GAT, criaremos uma solu¸c˜ao simplificada que utilizar´a uma interface que ser´a um subconjunto de GAT e que ter´a mapeamento direto para omiddleware InteGrade. As funcionalidades a serem oferecidas por InGriDE foram definidas levando em considera¸c˜ao as funcionalidades das ferramentas encontradas na literatura e um levantamento de necessidades feito junto aos integrantes do grupo de pesquisa do InteGrade.
Na primeira fase de desenvolvimento do projeto, j´a realizada, foram desenvolvidas algumas funcionalidades para atender `as necessidades da comunidade do projeto Inte- Grade, mas sem obedecer a arquitetura proposta neste documento. Na segunda fase do projeto desenvolveremos a nossa interface simplificada, adaptaremos o c´odigo atual `a nova arquitetura, faremos melhorias nas funcionalidades existentes, e incluiremos novas.
Esperamos como resultado deste trabalho fazer a defini¸c˜ao de uma arquitetura para uma IDE gen´erica para Computa¸c˜ao em Grade e disponibilizar o c´odigo de InGriDE como um primeiro passo para a cria¸c˜ao desta IDE. Al´em disso, esperamos fazer algumas contribui¸c˜oes com funcionalidades espec´ıficas do middleware InteGrade no enriqueci- mento da GAT. Para o projeto InteGrade planejamos a disponibiliza¸c˜ao de uma IDE que atenda `as necessidades de seus usu´arios, e um portal comportlets compat´ıveis com a especifica¸c˜ao JSR168 [jsr06].
2 Sistemas de Computa¸c˜ ao em Grade
A dissemina¸c˜ao da Computa¸c˜ao em Grade propiciou o surgimento de diversos sis- temas desenvolvidos tanto pela ind´ustria quanto pela comunidade acadˆemica [PL05].
Nesta se¸c˜ao apresentaremos alguns dos principais sistemas de Computa¸c˜ao em Grade existentes, em ordem cronol´ogica de cria¸c˜ao, analisando as suas principais caracter´ısticas.
Deixaremos a apresenta¸c˜ao do projeto GridLab para o final por se tratar n˜ao somente de uma Grade Computacional, mas tamb´em de um integrador de Grades.
2.1 Condor
Condor [TTL04, con05] ´e um sistema distribu´ıdo para computa¸c˜ao intensiva que provˆe mecanismos de gerenciamento de tarefas, escalonamento, esquema de priorida- des, e monitoramento e gerenciamento de recursos. O sistema ´e o mais antigo aqui apresentado, tendo seu in´ıcio em 1988 na Universidade de Wisconsin-Madison como derivado de um sistema ainda mais antigo, RemoteUnix [Lit87], que possibilitava a integra¸c˜ao e o uso remoto de esta¸c˜oes de trabalho. O sistema vem sendo utilizado em centenas de organiza¸c˜oes tanto no meio acadˆemico quanto na ind´ustria.
O principal objetivo de Condor ´e utilizar os recursos computacionais ociosos dis- pon´ıveis em esta¸c˜oes de trabalho para executar programas (Computa¸c˜ao Oportunista [LBRT97]), preservando o propriet´ario do recurso de perdas de desempenho. Esta carac- ter´ıstica requer do sistema mecanismos flex´ıveis suficientes que permitam a adapta¸c˜ao do sistema `as frequentes mudan¸cas do ambiente.
Um desses mecanismos ´e o chamado de ClassAds [RLS98], um conjunto de ex- press˜oes que s˜ao usadas para descrever tanto requisitos de execu¸c˜ao de uma aplica¸c˜ao, quanto ofertas de recursos. Essas express˜oes s˜ao pares do tipo (atributo, valor) e podem incluir n´umeros, strings e intervalos, entre outros. Essas informa¸c˜oes s˜ao utilizadas no processo de execu¸c˜ao de uma aplica¸c˜ao onde um componente do Condor emparelha os ClassAds de requisi¸c˜oes com ClassAds de recursos dispon´ıveis, identificando as com- patibilidades (Matchmaking). Atrav´es deste mecanismo, Condor pode identificar um recurso adequado para a execu¸c˜ao remota da aplica¸c˜ao.
Em virtude da disponibilidade intermitente dos recursos compartilhados utilizados por Condor, faz-se necess´ario um mecanismo que garanta o progresso das aplica¸c˜oes mesmo que as m´aquinas com aplica¸c˜oes em execu¸c˜ao tornem-se indispon´ıveis. Condor utiliza t´ecnicas de checkpointing [LTBL97] para resolver este problema. Este meca- nismo salva periodicamente o estado da aplica¸c˜ao e quando uma m´aquina torna-se indispon´ıvel, todo o estado da aplica¸c˜ao pode ser recuperado de umcheckpoint pr´evio.
Este mecanismo permite tamb´em que uma tarefa seja migrada de uma m´aquina para outra.
Um dos problemas que ocorrem na execu¸c˜ao de aplica¸c˜oes em Grades ´e a dificuldade no gerenciamento de recursos relacionados `a esta execu¸c˜ao, tais como arquivos de en- trada e sa´ıda. A solu¸c˜ao de Condor para este problema ´e a utiliza¸c˜ao de um mecanismo de chamadas remotas de m´etodos, que permite que opera¸c˜oes efetuadas na m´aquina na qual a aplica¸c˜ao executa sejam de fato efetuadas na m´aquina que solicitou a execu¸c˜ao.
Uma biblioteca reimplementa parte das chamadas de sistema (I/O), fazendo-as serem executadas remotamente.
A arquitetura original de Condor foi projetada para gerenciar um pequeno grupo de m´aquinas (Condor Pools) localizadas em uma rede local, pertencentes a um ´unico
dom´ınio administrativo. Entretanto, com a prolifera¸c˜ao dos aglomerados Condor, surgiu a necessidade de interconectar esses aglomerados. A primeira solu¸c˜ao desenvolvida foi denominadaGateway Flocking [ELvD+96]. Nessa solu¸c˜ao, em cada aglomerado Condor
´e adicionado um novo m´odulo, o gateway, respons´avel pela integra¸c˜ao do aglomerado com os demais. Esta solu¸c˜ao n˜ao se mostrou t˜ao pr´atica por dificultar a manuten¸c˜ao dos protocolos de Condor, sendo substitu´ıda pelo Direct Flocking, uma solu¸c˜ao bem mais simples que permite que usu´arios de outros dom´ınios administrativos executem aplica¸c˜oes, fornecendo um compartilhamento a n´ıvel de usu´ario. Apesar de adotada na pr´atica, esta solu¸c˜ao apresenta problemas de escalabilidade. Outra solu¸c˜ao surgiu com a populariza¸c˜ao das grades Globus: o projeto Condor desenvolveu Condor-G [FTL+02], que ´e o casamento das tecnologias de Condor com Globus. Do projeto Globus foi usado o protocolo seguro de comunica¸c˜ao inter-dom´ınio e o acesso padronizado a uma variedade de sistemas remotos de processamento. Do Condor foi usada a parte de aloca¸c˜ao e submiss˜ao de tarefas, recupera¸c˜ao de erros e a cria¸c˜ao de um ambiente de execu¸c˜ao amig´avel.
Al´em dessas caracter´ısticas Condor fornece mecanismos para execu¸c˜ao de aplica¸c˜oes paralelas baseadas em MPI e PVM. No entanto, o suporte a aplica¸c˜oes MPI ´e limitado a execu¸c˜ao em recursos dedicados [Wri01].
2.2 Legion
Legion [GW97, leg05] ´e um Sistema de Meta-computa¸c˜ao [SC92], ou seja, um am- biente que visa a integra¸c˜ao de v´arios recursos computacionais espalhados na rede de forma a transparecer ao usu´ario como um ´unico e poderoso computador. As seme- lhan¸cas entre os Sistemas de Meta-computa¸c˜ao e os de Computa¸c˜ao em Grade fizeram ambos convergirem, sendo o ´ultimo termo mais utilizado atualmente. Portanto, Legion pode ser considerado um sistema de Computa¸c˜ao em Grade. O projeto teve in´ıcio em 1993 na Universidade de Virg´ınia, com desenvolvimento iniciado em 1996 e a primeira implanta¸c˜ao ocorrendo em 1997.
A constru¸c˜ao de Legion passou por uma longa fase de an´alise de requisitos e projeto do sistema. Isto ocorreu principalmente pela estrutura de sua arquitetura: uma camada b´asica que provˆe servi¸cos para uma camada de servi¸cos de mais alto n´ıvel. Este estrutura contrasta com o projeto do Globus Toolkit vers˜ao 2, que baseava-se em um conjunto de servi¸cos razoavelmente independentes, e se parece com a vers˜ao 3 com sua arquitetura OGSA/OGSI.
A principal caracter´ıstica de Legion ´e sua arquitetura ser baseada no paradigma de orienta¸c˜ao a objetos, onde todas as entidades do sistema, desde computadores at´e servi¸cos s˜ao representados por objetos. Estes objetos utilizam os servi¸cos da camada b´asica fornecida por Legion. Essa arquitetura resultou em um modelo elegante e flex´ıvel
que fornece, dentre outras coisas, escalabilidade (milh˜oes de hosts), interoperabilidade entre objetos escritos em diferentes linguagens de programa¸c˜ao, etc.
O crescimento do uso de Legion unido ao sucesso do Globus Toolkit deu origem ao projeto chamado Legion-G [Dep03]. Este projeto consiste basicamente no sistema Legion utilizando o Globus como uma infra-estrutura de baixo n´ıvel. A integra¸c˜ao dos dois sistema era interessante para o aproveitamento dos pontos positivos de cada um.
Em dezembro de 2001 foi feita uma demonstra¸c˜ao de uma aplica¸c˜ao usando a infra- estrutura MPI do Globus e o LegionFS [WWHG01], um componente do sistema de arquivos distribu´ıdo de Legion.
O projeto Legion foi encerrado em 2001, quando a empresa Avaki adquiriu os direitos legais de Legion. O projeto mudou de nome para o mesmo da empresa, que removeu alguns servi¸cos mas manteve a arquitetura original. Em 2005 a Sybase adquiriu a Avaki com inten¸c˜ao de expandir sua atua¸c˜ao no mercado de integra¸c˜ao de dados, e hoje comercializa uma solu¸c˜ao chamadaSybase Avaki Enterprise Information Integration 1 que provˆe uma vis˜ao integrada de dados distribu´ıdos, atrav´es de uma camada ´unica.
2.3 Globus
O sistema Globus [Glo05, FK97] ´e um sistema de Computa¸c˜ao em Grade que prop˜oe um tratamento vertical integrado entre aplica¸c˜oes, middleware e rede. A id´eia ´e dis- ponibilizar uma infra-estrutura b´asica que possa ser usada na constru¸c˜ao de servi¸cos de mais alto n´ıvel. O Globus ´e atualmente o maior e mais importante projeto na
´area de Computa¸c˜ao em Grade. Sua comunidade chamada Globus Alliance ´e formada por diversas institui¸c˜oes de pesquisa, al´em contar com o apoio da ind´ustria atrav´es de empresas como IBM e Microsoft.
O sistema de Computa¸c˜ao em Grade mantido pela Globus Alliance ´e denominado Globus Toolkit. Iniciado em 1998 com sua vers˜ao 1.0, passando pela 2.0 em 2002, e pela 3.0 em 2003, atualmente encontra-se na vers˜ao 4.0. A vers˜ao 2 do Globus Toolkit (GT2) foi a primeira vers˜ao mais s´olida e amplamente usada. Esta vers˜ao caracterizava- se por um conjunto de servi¸cos para a constru¸c˜ao de sistemas e aplica¸c˜oes de Grade.
Os principais servi¸cos incluem o servi¸co de informa¸c˜ao, denominado MDS (Monitoring and Discovery Service), o servi¸co de gerenciamento de recursos, representado princi- palmente pelo Globus Resource Allocation Manager (GRAM), e o servi¸co seguran¸ca, o GSI (Globus Security Infrastructure).
A vers˜ao 3 do Globus Toolkit (GT3) apresentou uma profunda mudan¸ca na con- cep¸c˜ao do sistema. O toolkit deixou de ser uma cole¸c˜ao de ferramentas e servi¸cos definidos apenas no ˆambito do projeto Globus, e passou a implementar a arquitetura
1http://www.sybase.com/products/developmentintegration/avakieii
OGSA/OGSI. AOpen Grid Services Architecture (OGSA) e a Open Grid Services In- frastructure (OGSI) [FKNT02] definidas pelo comitˆe formado pelo Global Grid Forum [Ggf05] e algumas outras empresas tem o objetivo de definir uma arquitetura padr˜ao que permita a constru¸c˜ao de sistemas de Computa¸c˜ao em Grade, possibilitando a in- teroperabilidade entre diferentes Grades. A arquitetura proposta fundamenta-se em servi¸cos implementados em Web Services [BHM+04] que provˆeem funcionalidades a usu´arios e aplica¸c˜oes atrav´es da troca de mensagens. Em GT3, alguns servi¸cos do GT2 est˜ao dispon´ıveis baseados neste novo padr˜ao.
A vers˜ao 4 do Globus Toolkit (GT4) [Fos05b, Fos05a], dispon´ıvel a partir de abril de 2005, representou um avan¸co significativo em rela¸c˜ao `a implementa¸c˜ao das funcio- nalidades de Web Services dispon´ıvel no GT3 em termos de componentes fornecidos, funcionalidade, conformidade com padr˜oes, usabilidade e qualidade da documenta¸c˜ao.
Alguns desses avan¸cos ocorreram gra¸cas `a coordena¸c˜ao entre as comunidades de Com- puta¸c˜ao em Grade e de Web Services, que identificaram um conjunto de requisitos comuns, o que levou `a formula¸c˜ao da especifica¸c˜ao conhecida como Web Service Re- source Framework (WSRF) [wsr05], que pode ser considerada um refinamento da OGSI.
A especifica¸c˜ao WSRF ´e seguida pelo GT4 e define como fornecer servi¸cos para a Grade usando implementa¸c˜oes em Web Services. Atualmente o GT4 inclui servi¸cos e bibliote- cas para monitoramento, busca e gerenciamento de recursos, seguran¸ca, gerenciamento de arquivos, dentre outros.
2.4 SETI@home
SETI@home [ACK+02, set05] ´e um projeto que utiliza computadores pessoais es- palhados pelo mundo, interconectados pela Internet, para busca de inteligˆencia extra- terrestre atrav´es da an´alise de ondas de r´adio capturadas por um r´adio-telesc´opio ins- talado no observat´orio de Arecibo. O projeto foi proposto por David Gedye em 1995 e desenvolvido na Universidade da Calif´ornia em Berkley. Originou-se da necessidade de um poder computacional que dificilmente seria obtido atrav´es do uso de supercompu- tadores dedicados. SETI@home foi originalmente colocado em produ¸c˜ao em maio de 1999.
A id´eia do sistema ´e dividir uma enorme quantidade de dados em pequenas unidades de 350 KB chamadas de unidades de trabalho (workunits). Essas unidades de trabalho s˜ao disponibilizadas para os clientes processarem uma por vez. Na comunica¸c˜ao entre clientes e o servidor ´e usado o protocolo HTTP, que facilita a passagem por firewalls.
N˜ao h´a comunica¸c˜ao entre os clientes, e estes podem operar no modo desconectado.
O projeto alcan¸cou um grande sucesso atingindo mais de 4,5 milh˜oes de usu´ario, sendo 600 mil ativos [set05]. ´E considerado o problema que recebeu mais tempo de computa¸c˜ao na hist´oria. Alguns fatores contribu´ıram para este sucesso tais como a
facilidade de instala¸c˜ao e o fornecimento de informa¸c˜oes aos usu´ario sobre o andamento do projeto e sobre resultados obtidos. Um ponto negativo do sistema ´e sua limita¸c˜ao `a apenas um tipo de aplica¸c˜ao.
2.4.1 BOINC
O sistema BOINC (Berkeley Open Infrastructure for Network Computing) [And04, boi05] foi criado com intuito de utilizar os pontos positivos do projeto SETI@home e apresentar solu¸c˜oes para suas limita¸c˜oes. Desenvolvido pelo mesmo grupo de pesquisa, BOINC ´e uma plataforma de sistemas distribu´ıdos para uso de recursos computacionais de terceiros (Public-Resource Distributed Computing) que possibilita a constru¸c˜ao de diversas aplica¸c˜oes, ao contr´ario de SETI@home. Essas aplica¸c˜oes que executam em BOINC devem ser do tipo BOTs acompanhando a id´eia de seu antecessor.
A estrutura de BOINC aproveitou algumas id´eias de SETI@home e introduziu o conceito de Projeto, que ´e um conjunto de programas tanto do lado servidor quanto do lado cliente que visam resolver um determinado problema. Cada projeto tem seus servidores pr´oprios, geram as suas unidades de trabalho e fornecem componentes para verifica¸c˜ao de resultados e tratamento de unidades processadas. Um usu´ario pode participar de v´arios projetos simultaneamente, especificando quanto de seus recursos deseja compartilhar com cada um.
O projeto aprimorou diversos aspectos que eram deficientes em SETI@home. O mecanismo decheckpointing foi introduzido permitindo que o estado da aplica¸c˜ao fosse salvo e retomado posteriormente. Diversos mecanismos de seguran¸ca foram desenvolvi- dos tais como: (1) redundˆancia para impedir falsifica¸c˜ao de resultados, (2) assinatura de c´odigo para impedir a distribui¸c˜ao forjada de aplica¸c˜oes e (3) limite do tamanho m´aximo do arquivo de sa´ıda para impedir ataques do tipo de nega¸c˜ao de servi¸co.
2.5 ProActive
ProActive [BCH+02, pro05] ´e uma biblioteca Java para computa¸c˜ao paralela, dis- tribu´ıda e concorrente com mobilidade e seguran¸ca, que permite a simplifica¸c˜ao da programa¸c˜ao de aplica¸c˜oes que s˜ao distribu´ıdas em redes locais, aglomerados ou em Grades. O projeto foi criado em 2002 pelo grupo OASIS do INRIA Sophia Antipolis e ´e um dos principais componentes do cons´orcio ObjectWeb [obj05], possuindo atualmente mais de 15 membros. O software ´e distribu´ıdo sob licen¸ca LGPL e encontra-se na vers˜ao 3.0, lan¸cada em novembro de 2005.
O principal objetivo de ProActive ´e abstrair do programador tarefas de baixo n´ıvel nesses ambientes. Para alcan¸car tal objetivo foi criado um arcabou¸co que fornece um alto n´ıvel de abstra¸c˜ao. ProActive ´e independente da camada de comunica¸c˜ao
encaixando-se acima destas. A atual implementa¸c˜ao possibilita o uso de trˆes diferentes tipos: RMI, JINI e protocolos baseados em XML. Isso possibilita a biblioteca interope- rar com v´ariospadr˜oes (de facto) tais como Globus, Unicore, entre outros.
O modelo de distribui¸c˜ao e atividade de ProActive utiliza mecanismos que objeti- vam a simplicidade e a reutiliza¸c˜ao de sistemas de objetos distribu´ıdos e concorrentes.
A biblioteca baseia-se no padr˜aoActive Object, que define uma entidade (active object) que encapsula acesso remoto ao objeto, um servidor de requisi¸c˜oes e um agente m´ovel.
Uma aplica¸c˜ao constru´ıda usando ProActive ´e composta por um conjunto dessas en- tidades. Cada active object tem a sua pr´opria thread de controle e decide em qual ordem atender `as chamadas de m´etodos que chegam. Estas, por sua vez, s˜ao automati- camente armazenadas em uma fila de requisi¸c˜oes pendentes. As chamadas de m´etodos enviadas aos active objects s˜ao sempre ass´ıncronas com future objects transparentes e sincroniza¸c˜ao gerenciada por um mecanismo conhecido comowait-by-necessity [Car93].
A biblioteca provˆe ainda uma forma de migrar qualquer active object de uma m´aquina virtual Java para outra.
ProActive fornece ainda um mecanismo de comunica¸c˜ao em grupo [BBC02] que se beneficia das funcionalidades dos active objects para fazer chamadas remotas ass´ıncronas para um grupo de objetos. Outra funcionalidade importante s˜ao os descritores de im- planta¸c˜ao em XML [BCH+02], que permitem abstrair do c´odigo fonte da aplica¸c˜ao qualquer configura¸c˜ao de software e hardware da implanta¸c˜ao. Isso possibilita a im- planta¸c˜ao de uma aplica¸c˜ao em qualquer lugar sem a necessidade de altera¸c˜ao no seu c´odigo fonte. ´E poss´ıvel tamb´em tornar uma aplica¸c˜ao tolerante `a falhas atrav´es do mecanismo de checkpoint dispon´ıvel em duas op¸c˜oes de protocolo: Communication- Induced Checkpointing (CIC) e Pessimistic Message Logging (PML) [BCDH05].
Um vez que uma aplica¸c˜ao esteja em execu¸c˜ao, o usu´ario pode utilizar uma fer- ramenta de visualiza¸c˜ao e monitora¸c˜ao chamada IC2D (Interactive Control and De- bugging of Distribution) que possibilita a visualiza¸c˜ao de aspectos como topologia e comunica¸c˜ao, permitindo o controle e a modifica¸c˜ao da execu¸c˜ao. Essa ferramenta ser´a apresentada com mais detalhes na se¸c˜ao 3.
2.6 MyGrid
O MyGrid [WC03, our05] ´e um ambiente para a execu¸c˜ao de aplica¸c˜oes em recursos computacionais distribu´ıdos. A id´eia de MyGrid ´e simplificar o processo de implanta¸c˜ao da Grade, a ponto de permitir que os usu´arios possam implantar uma Grade nos seus recursos dispon´ıveis sem a necessidade de um administrador. O sistema vem sendo desenvolvido pela Universidade Federal de Campina Grande, com o apoio da empresa Hewlett-Packard.
O foco deste projeto restringi-se apenas `as aplica¸c˜oes do tipoBag-of-Tasks (BOTs).
Uma aplica¸c˜ao BOT ´e composta por uma ou mais tarefas que podem ser executa- das de forma independente, ou seja, n˜ao existe comunica¸c˜ao entre as tarefas. O fraco acoplamento deste tipo de aplica¸c˜ao simplifica a execu¸c˜ao na Grade pois reduz con- sideravelmente problemas de coordena¸c˜ao. Apesar de ser uma solu¸c˜ao minimalista se comparada `as abordagens de outros sistemas de grades, esse tipo de aplica¸c˜ao ´e extre- mamente ´util em diversas ´areas tais como biologia computacional, processamento de imagens, entre outros.
Um ponto negativo de MyGrid ´e que seu escalonador de tarefas n˜ao utiliza in- forma¸c˜oes sobre a disponibilidade detalhada dos recursos e sobre as necessidades das aplica¸c˜oes. Ele trabalha apenas com duas informa¸c˜oes: a quantidade de m´aquinas dis- pon´ıveis e a quantidade de tarefas de uma aplica¸c˜ao. Neste esquema n˜ao ´e poss´ıvel especificar um intervalo com a quantidade m´ınima de mem´oria ou de CPU a serem utilizados na execu¸c˜ao.
2.6.1 OurGrid
OurGrid [ACBR03] ´e uma gradepeer-to-peer na qual ospeers doam os seus recursos computacionais ociosos em troca do acesso aos recursos ociosos de outrospeers quando precisarem. Criado pelo mesmo grupo de MyGrid, o objetivo do projeto acompanha a id´eia de permitir a usu´arios de aplica¸c˜oes BOTs obterem f´acil acesso e uso a recursos computacionais, mas com a diferen¸ca de fornecer um mecanismo para a utiliza¸c˜ao de recursos de terceiros. O sistema ´e software livre distribu´ıdo sob licen¸ca GPL, e est´a em produ¸c˜ao desde dezembro de 2004. Atualmente conta com 500 m´aquinas, sendo considerada uma das maiores grades computacionais no Brasil.
A arquitetura de OurGrid beneficia-se dos componentes desenvolvidos no projeto MyGrid, tendo acrescentado estruturas chamadas peers, que s˜ao respons´aveis por im- plementar a l´ogica de compartilhamento dos recursos na rede peer-to-peer. OurGrid utiliza um modelo econˆomico de rede de favores no qual um site doa os seus recursos ociosos como favor, esperando ser priorizado quando necessitar de favores da comu- nidade. Este modelo foi projetado de forma descentralizada atrav´es dos peers, o que fornece maior simplicidade para implanta¸c˜ao e escalabilidade.
2.7 GridLab
O GridLab [ADD+03] ´e um dos maiores projetos de pesquisa na Europa na ´area de desenvolvimento de ferramentas e middlewares para o ambiente de Grade. Fundado pela Comiss˜ao Europ´eia, sua comunidade inclui uma d´uzia de institui¸c˜oes de pesquisa incluindo grupos da Europa e dos Estados Unidos, dentre eles o Laborat´orio Nacional de Argonne em Illinois, Universidade de Cardiff e as empresas HP e Sun. GridLab fornece
um conjunto de servi¸cos de Grade direcionados `as necessidades das aplica¸c˜oes, cobrindo diversas dessas funcionalidades tais como gerenciamento dinˆamico de recursos, monito- ramento, gerenciamento de dados, seguran¸ca, servi¸cos adaptativos, dentre outros. Estes servi¸cos s˜ao acessados atrav´es da Grid Application Toolkit (GAT) [ADG+05] (descrita em detalhes na pr´oxima se¸c˜ao), que permite que as aplica¸c˜oes acessem servi¸cos de Gri- dLab, recursos, bibliotecas espec´ıficas e ferramentas de uma forma que os usu´arios finais e desenvolvedores de aplica¸c˜oes possam construir e executar aplica¸c˜oes na Grade sem terem que se preocupar com detalhes do ambiente de execu¸c˜ao. Conforme veremos a seguir, o uso de GAT na arquitetura de GridLab permite que este sistema n˜ao seja visto apenas como um sistema de Computa¸c˜ao em Grade, e sim uma esp´ecie de ambiente integrador de Grades.
O principal objetivo deste projeto ´e diminuir a distˆancia existente entre as aplica¸c˜oes e os middlewares de Grade, provendo uma camada entre eles. A constru¸c˜ao desta camada foi feita baseado-se nas experiˆencias dotestbed pan-Europeu [ADG+01]. Desta forma, o projeto ´e fortemente baseado nas necessidades das aplica¸c˜oes, identificadas atrav´es do envolvimento com grupos de aplica¸c˜oes reais. Isto qualificou o projeto para o desenvolvimento de uma camada que reflita diretamente as necessidades reais dos usu´arios e desenvolvedores de aplica¸c˜oes para a Grade. O c´odigo da implementa¸c˜ao ´e software livre e est´a dispon´ıvel no website do projeto2.
2.7.1 Grid Application Toolkit (GAT)
GAT ´e uma interface de programa¸c˜ao unificada, simples e de alto n´ıvel para a infra-estrutura de Grade. O projeto e a implementa¸c˜ao dessa API foi guiado pelas necessidade de aplica¸c˜oes reais, incluindo um conjunto de requisitos comuns `a uma gama de aplica¸c˜oes de diferentes dom´ınios, abrangendo centenas de cen´arios de usu´arios. O principal objetivo de GAT ´e desacoplar a aplica¸c˜ao do middleware de grade e de seus servi¸cos. Essa id´eia ´e similar a de MPI [For94], mas em um n´ıvel mais alto de abstra¸c˜ao (Grade).
O projeto de GAT est´a dividido em duas partes (Figura 1) : o GAT engine (GAT Layer) e osGAT adaptors (Service Layer e Core Layer). A API exposta para a aplica¸c˜ao deve ser independente do middleware de grade, portanto toda comunica¸c˜ao da aplica¸c˜ao com GAT ´e feita atrav´es de GAT engine. Essa, por sua vez, encaminha as chamadas aos GAT adaptors que s˜ao elementos modulares que provˆeem acessos `as funcionalidades espec´ıficas ao middleware de grade atual. Neste modelo, existem dois tipos de Adap- tors, os que s˜ao para os servi¸cos do GridLab, e os de terceiros, implementados para outros middlewares de grade. Portanto, para que um middleware converse com GAT
´e necess´ario apenas que sejam desenvolvidos os adaptors espec´ıficos a este middleware.
2http://www.gridlab.org
Com isso, uma aplica¸c˜ao desenvolvida usando a GAT API que executava usando servi¸cos do middleware GridLab, pode passar a ser executava em outro middleware sem que seja necess´ario mudar uma linha de c´odigo.
Figura 1: A Arquitetura de GAT dentro de GridLab.
A implementa¸c˜ao de GAT tem como requisitos a facilidade de uso, suporte `a diferen- tes linguagem de programa¸c˜ao e suporte `a diferentes middlewares. Usa o paradigma de orienta¸c˜ao a objetos [DGM03], est´a implementada em C, mas com um wrapper C++.
Recentemente os autores criaram um novo grupo no GGF chamado SAGA [GGF03], que objetiva o desenvolvimento de uma API simples e padronizada para qualquer Grade, misturando os conceitos de GAT com os de outros participantes do GGF.
Os sistemas de Computa¸c˜ao em Grade vistos nesta se¸c˜ao podem ser analisamos em dois grupos que tem prop´ositos diferentes. No primeiro grupo est˜ao os sistemas chamados oportunistas, que utilizam recursos computacionais ociosos dispon´ıveis em esta¸c˜oes de trabalho. Neste grupo est˜ao o Condor, projeto mais antigo que se destaca pelo seu suporte `a aplica¸c˜oes paralelas e os seus mecanismos de ClassAds e checkpoin- ting para lidar com o dinˆamico ambiente da Grade. O projeto BOINC, sucessor de Setti@Home, tamb´em entra nessa grupo apresentando um interessante modelo para atender aplica¸c˜oes BOTs que visam utilizar recursos de terceiros.
O segundo grupo, formado pelos sistemas considerados Grades Computacionais tra- dicionais, traz como carro chefe o Globus. Este sistema, entre todos, ´e o que tem o uso mais difundido, ´e o ´unico que implementa o padr˜ao OGSA na vers˜ao GT3 e WSRF na vers˜ao GT4, e tamb´em oferece suporte `a aplica¸c˜oes paralelas. Em virtude da sua ampla dissemina¸c˜ao, o Globus Toolkit tem um conjunto enorme de ferramentas desen- volvidas, fato que ´e de especial interesse para o nosso trabalho. Ainda neste grupo est˜ao o Legion, que antes de acabar apresentou uma elegante e flex´ıvel arquitetura ori- entada a objetos; o MyGrid/OurGrid, com um modelo que fornece simplicidade para implanta¸c˜ao e escalabilidade atendendo aplica¸c˜oes BOTs; e ProActive, uma biblioteca que cria uma camada de mais alto n´ıvel e se encaixa em diferentes Grades fornecendo funcionalidades como seguran¸ca, mobilidade e comunica¸c˜ao em grupo para o usu´ario da Grade abstraindo a complexidade do ambiente.
Finalmente, separamos GridLab dos demais sistemas por este n˜ao ser apenas uma Grade Computacional, e sim uma esp´ecie de ambiente integrador de Grades. At´e onde conhecemos, n˜ao existe na literatura um sistema similar com o mesmo grau de amadu- recimento que GridLab.
3 Ferramentas para Computa¸c˜ ao em Grade
Existem atualmente muitas ferramentas dispon´ıveis para os diferentes sistemas de Computa¸c˜ao em Grade [KDK+03, Sch02, TSWR03, ABD+01, nov04, gri06c, YMBW00, CB03]. Essas ferramentas caracterizam-se por agregar diferentes funcionalidades ao middleware, facilitando o acesso aos recursos e servi¸cos da Grade. Nesta se¸c˜ao apre- sentaremos essas ferramentas analisando como elas se encaixam nos sistemas de com- puta¸c˜ao em grade, o que oferecem e quais os seus tipos.
A atua¸c˜ao das ferramentas no ambiente distribu´ıdo da Grade pode ocorrer no lado servidor, cliente ou em ambos. Um grupo especial dessas ferramentas chamado de Grid Computing Environments(GCEs) [FPGT03, Fox03] ouGrid application-level tools [BCDM04], engloba essencialmente as ferramentas que atuam no lado cliente e tem o objetivo de abstrair a complexidade da Grade permitindo aos usu´arios uma f´acil intera¸c˜ao com o conjunto de recursos distribu´ıdos na Grade.
Os GCEs normalmente oferecem aos usu´arios e desenvolvedores de aplica¸c˜oes para a Grade dois grupos de funcionalidades [FPGT03]: (1) ambiente de programa¸c˜ao, que normalmente est´a integrados `as bibliotecas de runtime dos sistemas de Computa¸c˜ao em Grade espec´ıficos; (2) ferramentas para intera¸c˜ao com os servi¸cos da Grade.
Os diferentes GCEs que fornecem o segundo grupo de funcionalidades, o fazem atrav´es do acesso aos servi¸cos da Grade, criando abstra¸c˜oes de diferentes n´ıveis. Alguns GCEs s˜ao constru´ıdos baseados nas abstra¸c˜oes fornecidas por outros GCEs. Isso forma
uma arquitetura organizada em camadas onde os GCEs que fornecem abstra¸c˜oes de mais alto n´ıvel est˜ao mais pr´oximos dos usu´arios da Grade, disponibilizando interfaces com o usu´ario tanto de linha de comando quanto gr´aficas.
Em nosso estudo daremos ˆenfase `a estas ferramentas que est˜ao mais pr´oximas do usu´ario. Na nossa an´alise consideraremos principalmente as funcionalidade fornecidas pelas ferramentas, deixando de lado o modelo computacional utilizado na integra¸c˜ao com o sistema de grade. Apresentaremos as ferramentas classificadas em grupos de- finidos baseados na taxonomia proposta por Foster [], que categoriza as ferramentas de Computa¸c˜ao em Grade de acordo com a atividade principal a qual se destinam.
Na categoria a qual nosso trabalho tem interese, a Grid Application Execution Envi- ronment, trˆes subcategorias foram definidas: ambientes para constru¸c˜ao de Workflows, Portais e ambientes espec´ıficos para aplica¸c˜oes param´etricas (Parameter Sweep Appli- cations (PSAs)). Apresentados por Foster dentro da categoriaWorkflows, os ambientes de solu¸c˜ao de problemas (Problem-Solving Environments (PSEs)) ser˜ao apresentados no nosso trabalho como uma categoria separada para ressaltar suas caracter´ısticas es- pec´ıficas. A classifica¸c˜ao das ferramentas foi feita de acordo com a funcionalidade mais marcante da mesma, portanto uma ferramenta pode incluir (e quase sempre inclui) caracter´ısticas de mais de um grupo. Em fun¸c˜ao da grande quantidade de ferramentas dispon´ıveis, apresentaremos em detalhe apenas uma ferramenta para cada grupo.
3.1 Workflows
Umworkflow consiste de um conjunto de m´odulos de software com entrada e sa´ıda bem definidas, conectados de forma ordenada para alcan¸car um determinado obje- tivo [BCDM04]. Atualmente os workflows tem uma grande importˆancia tanto na ´area acadˆemica quanto na ind´ustria, pois as aplica¸c˜oes de hoje n˜ao s˜ao mais entidades mo- nol´ıticas, e sim workflows complexos. A Grade, pela adequa¸c˜ao de sua arquitetura
`a este modelo, torna-se uma candidata natural para o ambiente de execu¸c˜ao destas aplica¸c˜oes. Este casamento permite que um m´odulo da aplica¸c˜ao execute em um n´o da grade e a sa´ıda desta execu¸c˜ao sirva de entrada para outro m´odulo que executar´a em outro n´o.
Em virtude desse casamento, v´arios projetos na ´area de grades desenvolveram in- terfaces gr´aficas para a cria¸c˜ao de aplica¸c˜oes de workflow. Um levantamento n˜ao aca- bado de v´arias dessas ferramentas est´a sendo feito por Slominski [SvL05]. Apesar da quantidade consider´avel de projetos, ainda n˜ao existe uma linguagem padr˜ao para a especifica¸c˜ao dos workflows para as aplica¸c˜oes de grade. O grupo de pesquisaWorkflow Management (WFM-RG) do Global Grid Forum [Ggf06] tem trabalhado nesse sen- tido, focando em v´arios aspectos do gerenciamento do workflow no ambiente de Grade.
Atualmente, as linguagens usadas na especifica¸c˜ao dos workflows nas ferramentas di-
recionadas a ambientes de grade s˜ao a Grid Services Flow Language (GSFL), Service Workflow Language (SWFL) e aGrid Workflow Execution Language (GWEL) [LB05b].
Todas estas linguagens foram definidas baseadas nas linguagens de composi¸c˜ao de web services, aWeb Services Flow Language (WSFL) [Ley01] ou aBusiness Process Execu- tion Language for Web Services (BPEL4WS) [And03].
O projeto TENT [Sch02] ´e um exemplo de ferramenta que provˆe um ambiente para a cria¸c˜ao e execu¸c˜ao de aplica¸c˜oes de workflow. A ferramenta permite que o usu´ario desenvolva a sua aplica¸c˜ao, submeta-a para execu¸c˜ao e a controle, al´em de permitir a visualiza¸c˜ao dos resultados. A ferramenta foi escrita na linguagem Java na sua maior parte, fornece uma interface gr´afica, e gerencia a computa¸c˜ao em recursos distribu´ıdos usando os servi¸cos de CORBA [OMG02]. TENT utiliza os servi¸cos de Globus (Se¸c˜ao 2.3) para a execu¸c˜ao na Grade.
DAGman [DAG05] ´e um sistema meta-escalonador bastante popular que possibilita a execu¸c˜ao de aplica¸c˜oes de workflow no sistema Condor (Se¸c˜ao 2.1). DAGMan gerencia as dependˆencias das tarefas de acordo com um grafo direcionado ac´ıclico (Directed Acyclic Graph - DAG), otimizando a ordem da execu¸c˜ao das tarefas.
Seguindo a tendˆencia do padr˜ao OGSA, o projeto XCAT [KG04] baseia-se em um modelo de programa¸c˜ao baseado em componentes chamado Commom Component Ar- chitecture (CCA) [AGG+99] que prop˜oe construir aplica¸c˜oes atrav´es da composi¸c˜ao de componentes de software. XCAT usa uma abordagem na qual um componente CCA ´e modelado como um conjunto de servi¸cos de Grade, permitindo que componentes CCA sejam acess´ıveis para cliente da Grade. O projeto ´e baseado no sistema Globus (Se¸c˜ao 2.3) e na API Cog Kit [LGL+02], e usa RMI sobre XSOAP para a comunica¸c˜ao. Para intera¸c˜ao com usu´ario fornece uma interface de linha de comando.
A seguir apresentamos P-GRADE, que apesar de ser uma ferramena propriet´aria, foi escolhida para representar os ambientes para constru¸c˜ao de workflows por ser a ferramenta desta categoria mais rica em funcionalidades. Al´em disso, P-GRADE utiliza tanto Globus quanto Condor como middleware de Grade.
3.1.1 P-GRADE
P-GRADE (Parallel Grid Runtime and Application Development Environment) [KDK+03, p-g06] ´e uma ferramenta que fornece um conjunto integrado de ferramen- tas de programa¸c˜ao para o desenvolvimento de aplica¸c˜oes a serem executadas tanto em sistemas de computa¸c˜ao distribu´ıdos homogˆeneos quanto heterogˆeneos, tais como supercomputadores, clusters e Grades. P-GRADE foi desenvolvido pelo instituto de pesquisa h´ungaroMTA SZTAKI Computer and Automation tendo como principal pes- quisador Peter Kacsuk. O sistema j´a foi testado no Hungariann Supercomputing Grid e tˆem sido intensamente usado em v´arias universidades no Reino Unido, Hungria e
Polˆonia.
A id´eia de P-GRADE ´e fornecer um ambiente gr´afico de alto n´ıvel que omita os detalhes de baixo n´ıvel de v´arias APIs de programa¸c˜ao dos sistemas distribu´ıdos e seja capaz de gerar c´odigo PVM, MPI ou GAT (Se¸c˜ao 2.7.1) de acordo com a plataforma atual de execu¸c˜ao. Para alcan¸car tal objetivo fornece v´arias ferramentas que permitem, entre outras coisas, a cria¸c˜ao de workflows. A cria¸c˜ao das aplica¸c˜oes ´e feita usando a linguagem GRAPNEL (GRAphical Process NEt Language) [KDF96] junto com o editor gr´afico GRED (Figura 2). GRAPNEL ´e uma linguagem h´ıbrida onde a parte gr´afica ´e usada para definir as atividades paralelas da aplica¸c˜ao e a parte textual ´e usada para descrever as atividades sequenciais. Na parte gr´afica os processo s˜ao representados por componentes gr´aficos no formato de retˆangulos e a troca de mensagens entre os processos s˜ao representadas por setas. A parte textual ´e usada para fornecer a l´ogica dos processos atrav´es de codifica¸c˜ao nas linguagens C/C++ ou Fortran.
Figura 2: Diferentes vis˜oes do editor GRED.
As funcionalidades de P-GRADE fornecem suporte `as fases de projeto, edi¸c˜ao, execu¸c˜ao e monitoramento da aplica¸c˜ao, e baseiam-se em trˆes aspectos do ponto de vista do usu´ario final da Grade. O primeiro aspecto ´e a cria¸c˜ao de aplica¸c˜oes para a Grade, levando em considera¸c˜ao a portabilidade do programa escrito. Para este as-
pecto P-GRADE fornece um compilador que gera c´odigo PVM, MPI e futuramente GAT a partir da nota¸c˜ao gr´afica definida pelo usu´ario. O segundo aspecto est´a relaci- onado `a execu¸c˜ao de programas paralelos na Grade. P-GRADE gera processos para a execu¸c˜ao nos sistemas Condor, Condor-G e Globus-2. O outro aspecto considerado ´e a migra¸c˜ao de processos de aplica¸c˜oes paralelas. P-GRADE fornece um mecanismo de checkpointing e migra¸c˜ao para programas PVM quando estes est˜ao sendo executados como processos Condor ou Condor-G.
Diante da necessidade de monitorar a migra¸c˜ao de aplica¸c˜oes paralelas na Grade, o grupo de pesquisa do P-GRADE desenvolveu uma infra-estrutura atrav´es da adapta¸c˜ao para ambientes heterogˆeneos da j´a existente GRM/PROVE [BKPV01], antes restrita ao monitoramento em ambientes homogˆeneos. O resultado disso foi a cria¸c˜ao de uma ferramenta gen´erica para monitoramento em Grades chamada Mercury [gri06a], que foi desenvolvida e inserida no projeto GridLab (Se¸c˜ao 2.7). O uso desta ferramenta possibilita ao P-GRADE, por exemplo, disponibilizar a visualiza¸c˜ao do gr´afico de barras horizontais da Figura 3. Neste gr´afico cada barra equivale a um processo da aplica¸c˜ao paralela e as setas entre as barras representam a troca de mensagens entre os processos.
Figura 3: Visualiza¸c˜ao da execu¸c˜ao de uma aplica¸c˜ao paralela.
Atualmente o mecanismo deruntime de workflow utilizado por P-GRADE ´e o Con- dor DAGMan. Entretanto, est´a prevista a cria¸c˜ao de um Grid Application Manager gen´erico que possibilite a execu¸c˜ao de uma aplica¸c˜ao de workflow em diferentes Grades.
Um portal P-GRADE foi desenvolvido para o acesso via web `as funcionalidade da camada de workflow, bem como `a submiss˜ao de aplica¸c˜oes.
3.2 Problem Solving Environments (PSEs)
Um PSE ´e um sistema que provˆe todas as facilidades computacionais necess´arias para resolver uma determinada classe de problemas [GHR94]. No contexto de com- puta¸c˜ao em grade, os PSEs s˜ao GCEs com um conjunto de funcionalidades espec´ıficas para um determinado dom´ınio de aplica¸c˜ao tais como qu´ımica, biomedicina ou as- trof´ısica. Esse tipo de ferramenta tˆem se mostrado extremamente eficiente na disse- mina¸c˜ao da computa¸c˜ao em grade junto `a comunidade cient´ıfica [BCDM04].
Um exemplo de PSE ´e o projeto Cactus [ABD+01], que atrav´es de uma arquitetura modular e paralela, fornece um arcabou¸co para constru¸c˜ao de aplica¸c˜oes para diversas
´areas da ciˆencia e engenharia tais como modelagem clim´atica, engenharia qu´ımica e astrof´ısica. A arquitetura modular de Cactus permite o uso de Globus (Se¸c˜ao 2.3) ou GridLab (Se¸c˜ao 2.7) como middleware de grade. Al´em disso, o projeto fornece uma interface web para intera¸c˜ao do usu´ario com a Grade.
O projeto Proteus [CCSV03] ´e um PSE para aplica¸c˜oes de Bioinform´atica. Esse projeto define uma metodologia baseada em ontologias para a descri¸c˜ao das aplica¸c˜oes de bioinform´atica no formato de workflows de componentes de softwares distribu´ıdos.
A arquitetura de Proteus ´e baseada em um sistema de grade que usa como base o sistema Globus (Se¸c˜ao 2.3). Os usu´arios de Proteus podem utilizar o ambiente visual VEGA [CCTT02] para projetar e executar suas aplica¸c˜oes na forma de workflows.
A seguir apresentamos Triana como a ferramenta representante dos PSEs. Triana, junto com Cactus, s˜ao os PSEs mais populares e utilizados pela comunidade, al´em de ambos serem software livre. Optamos por Triana pela sua maior quantidade de funcionalidades dispon´ıveis.
3.2.1 Triana
Triana [TSWR03, Tea05] ´e um PSE software livre desenvolvido na Universidade de Cardiff que fornece uma interface gr´afica bastante intuitiva para a composi¸c˜ao de aplica¸c˜oes. A arquitetura de Triana ´e composta por componentes plug´aveis chamados units que oferecem as funcionalidades do ambiente. O desenvolvedor constr´oi suas aplica¸c˜oes compondo os units dispon´ıveis atrav´es da interface gr´afica da ferramenta que funciona da mesma forma que as ferramentas de workflow apresentadas na se¸c˜ao
3.1. Em virtude do seu uso por cientistas de diversas ´areas tais como an´alise de dados, processamento de imagens e texto, j´a existe uma biblioteca com mais de 500 units abrangendo diversas aplica¸c˜oes. Al´em disso, Triana pode ser estendido atrav´es da cria¸c˜ao deunits com novas funcionalidades.
A interface gr´afica de Triana (Figura 4) ´e uma aplica¸c˜ao Java e consiste de quatro componentes principais que juntos comp˜oem o ambiente de desenvolvimento. Neste am- biente o desenvolvedor monta a sua aplica¸c˜ao utilizando as funcionalidades dispon´ıveis no ambiente.
Figura 4: Interface Gr´afica do Triana.
Triana oferece tamb´em facilidades para computa¸c˜ao distribu´ıda, nosso principal interesse. Os componentes para computa¸c˜ao distribu´ıda est˜ao divididos em duas cate- gorias: orientados a servi¸co (service-oriented) e os orientados a Grade (grid-oriented).
A primeira categoria ´e formada pelos componentes de servi¸cosPeer-to-Peer ouweb ser- vices, que s˜ao acess´ıveis remotamente. A segunda inclui os componentes utilizados na intera¸c˜ao com os servi¸cos das grades computacionais, que ser˜ao objeto de nosso estudo.
Os componentes grid-oriented utilizam a API GridLab GAT (Se¸c˜ao 2.7.1) para acessar os componentes distribu´ıdos das grades computacionais. Conforme descrito anteriormente, o uso dessa API permite que os componentes de Triana sejam desen- volvidos independente da grade computacional. O estado atual de desenvolvimento de GAT permite que a submiss˜ao de tarefas no ambiente do Triana possa ser feita tanto
para o servi¸co GRMS de GridLab ou para o GRAM de Globus. Quando o suporte de GAT `a submiss˜ao de tarefas para o Condor estiver dispon´ıvel, Triana j´a estaria pronto para submeter tarefas para esta grade.
O uso desses componentesgrid-oriented permite ao usu´ario submeter uma aplica¸c˜ao para execu¸c˜ao na Grade, monitorar o seu estado e at´e interromper uma execu¸c˜ao. Essa monitora¸c˜ao pode ser retomada inclusive ap´os o usu´ario desativar a aplica¸c˜ao cliente e reativ´a-la. Em virtude de ter nascido em um ambiente onde as simula¸c˜oes s˜ao muito utilizadas, o ambiente tamb´em oferece componentes que facilitam esse processo. Um bom exemplo s˜ao os que facilitam m´ultiplas submiss˜oes com diferentes parˆametros.
3.3 Portais
O termo portal ainda n˜ao est´a uniformemente definido na comunidade da Ciˆencia da Computa¸c˜ao. Algumas vezes representa um conjunto de computadores integrados, espa¸cos de com´ercio eletrˆonico ou de informa¸c˜ao [Fox00, FF99, Sma01]. O uso do termo na computa¸c˜ao em grade ´e feito com o significado mais usado: um servi¸co para uma comunidade, com um ´unico ponto de acesso a um sistema integrado, fornecendo informa¸c˜oes, dados, aplica¸c˜oes e servi¸cos.
UmPortal de Grade (Grid Portal) ´e um portal especializado, direcionado a usu´arios de Grades em produ¸c˜ao [LPW04]. Um portal deste tipo fornece informa¸c˜oes sobre o estado de recursos e servi¸cos da Grade. A interface do portal permite que os usu´arios sejam poupados de grande parte da complexidade relacionada aos servi¸cos da Grade.
Isso permite que algumas tarefas como a implanta¸c˜ao de uma aplica¸c˜ao em uma Grade em produ¸c˜ao seja facilitada ao m´aximo.
Osportais de grade n˜ao se restringem apenas `as tecnologias usadas em portais web comuns. Alguns m´odulos espec´ıficos para a intera¸c˜ao com a Grade s˜ao necess´arios para atender `as necessidades dos usu´arios. Em virtude disso, algumas tecnologias espec´ıficas para o desenvolvimento de portais de grade surgiram. Li e Baker [LB04, LB05a] fizeram uma revis˜ao de v´arios portais (web) dispon´ıveis para a Grade. Eles destacaram trˆes gera¸c˜oes de tecnologias de portal que s˜ao descritas a seguir.
A primeira gera¸c˜ao de portais de grade focou seus esfor¸cos na defini¸c˜ao das funcio- nalidades da interface gr´afica e os servi¸cos necess´arios para atendˆe-las tais como auten- tica¸c˜ao de usu´ario, submiss˜ao de tarefas, monitoramento de recursos e transferˆencias de dados. Outra caracter´ıstica marcante dos portais desta gera¸c˜ao foi o uso restrito do Globus como middleware. As limita¸c˜oes destes portais eram a falta de personaliza¸c˜ao das funcionalidades (eram fixas) e o uso dos servi¸cos de Grade restrito aos de Globus.
Alguns arcabou¸cos para cria¸c˜ao de portais chegaram a ser criados como o GridPort 2.0 [gri06c] e o Grid Portal Development Kit (GPDK) [gpd06], mas era complicado para os usu´arios finais construirem portais que atendessem `as necessidades dos seus requisitos
espec´ıficos fazendo uso destes arcabou¸cos.
A segunda gera¸c˜ao de portais faz uso do conceito dePortlets [pat06], que s˜ao servi¸cos personaliz´aveis que rodam no servidor web. O conte´udo de um portlet ´e normalmente agregado ao conte´udo de outrosportlets para formar a p´agina de um portal. Atrav´es do uso desta tecnologia ´e poss´ıvel construir portais com funcionalidades personaliz´aveis, reutilizar portlets de terceiros, entre outras vantagens. Atualmente os portlets tem re- cebido uma crescente aten¸c˜ao tanto da comunidade de computa¸c˜ao em grade quanto da ind´ustria. Com o intuito de definir padr˜oes para a interoperabilidade entre portlets de diferentes fornecedores dois grupos tem trabalho neste sentido. O primeiro, o JCP (Java Community Process) [jcp06] tem trabalhado na JSR168 3 [jsr06], uma API es- pec´ıfica para portais baseados na linguagem Java, O segundo, o OASIS (Organization for the Advancement of Structured Information Standards) [oas06] tem trabalhado na defini¸c˜ao da WSRP (Web Services for Remote Portlets) [BBC+03], uma API universal que permite a portais de qualquer tipo usar portlets de qualquer tipo. Atualmente, a especifica¸c˜ao JSR168 ´e a mais usada em virtude do predom´ınio da linguagem Java em ambientes servidores.
Umportlet de umportal de grade n˜ao ´e apenas umportlet integrado ao portal, mas ´e um componente associado a um servi¸co de Grade na sua retaguarda (Figura 5). A este tipo especial de portlet chamamos de Portlet de Grade (Grid Portlet). Um portal de grade constru´ıdo a partir de portlets de grade pode fornecer ao usu´ario a possibilidade de integrar servi¸cos de Grade fornecidos por diferentes middlewares. Esta gera¸c˜ao de portais ´e o atual estado da arte em portais de grade sendo GridSphere (apresentado a seguir) uma das ferramentas mais utilizadas na constru¸c˜ao de portlets de grade. A terceira gera¸c˜ao, ainda em fase de pesquisa, estende o uso de portlets adicionando anota¸c˜oes semˆanticas.
A emergˆencia de OGSA como padr˜ao na constru¸c˜ao de grades computacionais ori- entadas a servi¸co, faz com que o desenvolvimento deportletsdeva levar em considera¸c˜ao este padr˜ao. Os futurosportlets devem ser compat´ıveis com OGSA, o que significa que estes portlets devem ser associados a servi¸cos de Grade desenvolvidos e implantados atrav´es de um middleware compat´ıvel com OGSA.
3.3.1 GridSphere
GridSphere [nov04, gri06d] ´e um portal de grade de segunda gera¸c˜ao que provˆe a implementa¸c˜ao de um arcabou¸co de portlet baseado na API de portlets da IBM e compat´ıvel com a especifica¸c˜ao da JSR168. GridSphere permite que desenvolvedores criem aplica¸c˜oes web baseadas em portlets, n˜ao restritas a Grades, que podem ser executadas e administradas nocontainer deportlets de Gridsphere.
3JSR: Java Specification Request
Figura 5: Arquitetura de um portal de segunda gera¸c˜ao.
GridSphere foi desenvolvido baseado nas li¸c˜oes aprendidas em projetos de portais de Grade anteriores, tais como Grid Portal Development Kit (GPDK) e Astrophysics Scientific Collaboratory (ASC). O projeto GridLab (Se¸c˜ao 2.7) vem sendo usado como prot´otipo inicial para o levantamento das necessidades dos usu´arios do portal GridLab.
Entretanto, a arquitetura de GridSphere foi projetada como um arcabou¸cocaixa-branca e com intenso uso de padr˜oes de projeto. Isso resultou em uma arquitetura modular o suficiente para atender `as necessidades da vasta comunidade fora do escopo do projeto GridLab.
O arcabou¸co fornece um conjunto deportletsb´asicos que oferecem as funcionalidades b´asicas necess´arias para o uso de um portal. Osportlets b´asicos oferecem funcionalida- des como o login, requisi¸c˜ao de contas de usu´ario, gerenciamento de contas de usu´ario, gerenciamento de permiss˜oes de usu´ario e gerenciamento de portlets, permitindo ao usu´ario a adi¸c˜ao ou remo¸c˜ao deportlets `a sua ´area de trabalho.
O projeto GridSphere oferece suporte a funcionalidades relacionadas `a Grade atrav´es de uma m´odulo chamado Grid Portlets [RNW05]. Grid Portlets foi disponibilizado em junho de 2005 e vem sendo constru´ıdo a partir dos portlets b´asicos do arcabou¸co GridSphere. O objetivo ´e fornecer um arcabou¸co para o desenvolvimento de portlets de grade. Grid Portlets fornece como implementa¸c˜ao base o suporte ao Globus Toolkit 2 (GT2) e, distribu´ıda separadamente, uma implementa¸c˜ao para o GT3 e GT4. A ar- quitetura modular facilita o desenvolvimento de implementa¸c˜oes que atendam a outras grades computacionais. Os principais portlets deGrid Portlets s˜ao descritos a seguir:
• Gerenciamento de credenciais e autentica¸c˜ao ´unica: fornece suporte `a delega¸c˜ao de credenciais a um portal atrav´es do Credential Retrieval Portlet e permite que usu´arios fa¸cam a autentica¸c˜ao na Grade usando essas credenciais;
• Acesso a Recursos: acesso aos recursos da Grade atrav´es do Resource Browser Portlet (Figura 6), que permite visualiza¸c˜ao dos servi¸cos, softwares e contas dis- pon´ıveis nestes recursos;
Figura 6: Resource Browser Portlet exibindo detalhes de um recurso.
• Submiss˜ao de tarefas: permite a submiss˜ao e monitoramento das tarefas em re- cursos computacionais remotos. O Job Submission Portlet disponibiliza tamb´em a visualiza¸c˜ao do hist´orico das tarefas e o recebimento de notifica¸c˜oes no t´ermino das tarefas;
• Gerenciamento de arquivos: o File Browser Portlet (Figura 7) permite a na- vega¸c˜ao em sistemas de arquivos remotos. Al´em de fornecer suporte a comandos b´asicos (listar, renomear, criar pasta, etc.), esteportlet pode ser usado para upload e download de arquivos em recursos remotos. O File Activity Portlet permite ao usu´ario monitorar o progresso de tarefas com arquivos como upload.
O uso de GridSphere tem se disseminado rapidamente pela comunidade de com- puta¸c˜ao em grade. O motivo disso ´e a sua facilidade de instala¸c˜ao, suporte a perso- naliza¸c˜oes e sua boa documenta¸c˜ao. V´arios projetos adotaram GridSphere como a sua plataforma para desenvolvimento de portal de grade al´em de GridLab, dentre eles est˜ao o UK E-Science Program [ESC06], D-Grid [DGR06] e P-GRADE (Se¸c˜ao ??).
Figura 7: Transferˆencia de arquivos usando o File Browser Portlet.
3.4 Parameter Sweep Applications (PSAs)
PSAs s˜ao aplica¸c˜oes compostas por um conjunto de tarefas computacionais pratica- mente independentes, ou seja, com pouca sincroniza¸c˜ao ou dependˆencia de dados entre si [BCDM04]. Este tipo de aplica¸c˜ao normalmente tem as suas tarefas executadas em diferentes n´os, onde cada uma pode receber parˆametros de entrada e conjunto de dados diferentes. Este modelo simplificado aparece frequentemente em v´arios ´areas da ciˆencia e da engenharia tais como bioinform´atica, simula¸c˜ao de eventos discretos, computa¸c˜ao gr´afica, astronomia, etc.
As caracter´ısticas espec´ıficas deste tipo de aplica¸c˜ao a faz uma grande candidata a executar na Grade. O fraco acoplamento entre as tarefas a torna mais tolerante `a latˆencia da rede, elas s˜ao mais suscet´ıveis a mecanismos de tolerˆancia a falhas, e em geral necessitam de um grande poder computacional.
As ferramentas desenvolvidas para facilitar as tarefas dos desenvolvedores dessas aplica¸c˜oes se concentraram em mecanismos de escalonamento e instrumentos para im- planta¸c˜ao na Grade. Nimrod/G [AGK00] fornece um escalonador baseado em economia computacional e permite a especifica¸c˜ao declarativa das PSAs, ILAB (apresentado na pr´oxima se¸c˜ao) fornece uma interface com o usu´ario de alto n´ıvel, AppLeS Parame- ter Sweep Template (APST) [CB03] realiza o escalonamento tanto nos dados quanto na computa¸c˜ao das aplica¸c˜oes e fornece um bom mecanismo para implanta¸c˜ao, mas disponibiliza apenas uma interface b´asica com o usu´ario.
Em virtude de fornecer a interface gr´afica com o usu´ario de mais alto n´ıvel das ferramentas estudadas desta categoria, apresentamos em detalhes a seguir o ILAB.
3.4.1 ILab
ILab [YMBW00, ila06] ´e uma ferramenta para a cria¸c˜ao, execu¸c˜ao e monitoramento de estudos param´etricos (parametric studies), uma situa¸c˜ao espec´ıfica de execu¸c˜ao de
PSAs. O desenvolvimento desta ferramenta foi motivada pelas necessidades dos ci- entistas do Ames Research Institute da NASA em automatizar tarefas relacionadas `a execu¸c˜ao de aplica¸c˜oes que necessitavam de estudos parˆam´etricos. ILab foi projetado para ser uma ferramenta amig´avel e f´acil de usar, fornecendo uma interface gr´afica com o usu´ario (GUI) de alto n´ıvel. O sistema foi desenvolvido na linguagem Perl [PER06] e Tk [TK06], e usa atualmente o sistema Globus como middleware de Grade.
Oestudo param´etrico ´e uma situa¸c˜ao de execu¸c˜ao de uma PSA, geralmente da ´area cient´ıfica ou de engenharia, onde a execu¸c˜ao da aplica¸c˜ao com diferentes conjuntos de parˆametros de entrada ´e importante para o problema. Nesta situa¸c˜ao o cientista se depara com diversas tarefas repetitivas que podem ser automatizadas. Al´em disso, a necessidade de analisar o resultado das execu¸c˜oes com seus respectivos conjuntos de parˆametros, fazer pequenas mudan¸cas e submeter novamente s˜ao exemplos de neces- sidades dos usu´arios deste tipo de aplica¸c˜ao. Desta forma, o estudo das ferramentas desenvolvidas por ILab ´e bastante pertinente ao nosso trabalho.
As funcionalidades fornecidas por ILab direcionadas para estudos param´etricos in- cluem: a parametriza¸c˜ao de valores de arquivos de entrada, que facilita a constru¸c˜ao de um conjunto de arquivos de entrada (Figura 8); a possibilidade de mascarar algu- mas execu¸c˜oes, ou seja, evitar a execu¸c˜ao de determinadas combina¸c˜oes de parˆametros;
visualiza¸c˜ao de resultados; gera¸c˜ao de scripts; gera¸c˜ao de arquivos espec´ıficos para sub- miss˜ao no sistema Globus; dentre outras.
3.5 Outras
Nesta se¸c˜ao apresentamos algumas ferramentas interessantes que n˜ao se encaixam em nenhum dos grupos descritos acima, e tem alguma rela¸c˜ao importante com o nosso trabalho. Come¸caremos por ICD2 do projeto ProActive, que apresenta uma interface gr´afica rica em funcionalidades de monitoramento e controle das aplica¸c˜oes de ProAc- tive. Em seguida veremos GT4IDE e Gride, que utilizam a plataforma Eclipse para fornecer um ambiente de desenvolvimento, ambos baseados no Globus.
3.5.1 Interactive Control and Debugging of Distribution (ICD2)
IC2D [BBC+01, ic206] ´e um ambiente gr´afico para monitoramento e controle de aplica¸c˜oes constru´ıdas usando a biblioteca ProActive (Se¸c˜ao 2.5). O ambiente fornece ao programador instrumentos para visualizar as ocorrˆencias internas de uma aplica¸c˜ao ProActive em tempo de execu¸c˜ao e ainda permite que ele controle interativamente o mapeamento de tarefas a m´aquinas, tanto na cria¸c˜ao das tarefas quanto ap´os, realizando migra¸c˜oes. O objetivo da ferramenta ´e ajudar os usu´arios a implantar, monitorar e controlar a execu¸c˜ao de aplica¸c˜oes ProActive em plataformas distribu´ıdas, incluindo as
Figura 8: Tela de Parametriza¸c˜ao do ILab.
Grades.
As funcionalidades de monitoramento e controle de IC2D s˜ao oferecidas `as aplica¸c˜oes desenvolvidas usando a biblioteca ProActive sem a necessidade de qualquer modifica¸c˜ao.
IC2D pode ser usado nos ambientes de execu¸c˜ao atendidos por ProActive: RMI, Jini ou Globus.
IC2D fornece trˆes tipos de ferramentas: visualiza¸c˜ao gr´afica, visualiza¸c˜ao textual, e controle e monitoramento. O primeira inclui a visualiza¸c˜ao gr´afica de m´aquinas, m´aquinas virtuais Java, topologia de Active Objects, estado dos objetos (executando, esperando) e a migra¸c˜ao deles. A segunda exibe a lista de eventos e de mensagens trocadas pelos objetos. O terceiro permite o controle interativo do mapeamento objeto- m´aquina na cria¸c˜ao, execu¸c˜ao passo a passo e a migra¸c˜ao deActive Objects em execu¸c˜ao arrastando-os graficamente. A Figura 9 ilustra uma aplica¸c˜ao em execu¸c˜ao no ambiente IC2D.
O projeto ProActive iniciou o desenvolvimento doProActive Eclipse plugin [pro06], um plugin da plataforma Eclipse para facilitar o desenvolvimento de aplica¸c˜oes que usem a biblioteca ProActive. No entanto, o desenvolvimento est´a no in´ıcio e poucas funcionalidades est˜ao dispon´ıveis.
Figura 9: Vis˜ao geral de uma aplica¸c˜ao em execu¸c˜ao monitorada por IC2D.
3.5.2 GT4IDE
GT4IDE [gt406] ´e uma ferramenta desenvolvida como um plugin da plataforma Eclipse [ecl06] que visa facilitar o desenvolvimento de WSRF 4 Java Web Services. A id´eia ´e fornecer aos desenvolvedores de servi¸cos para o middleware Globus Toolkit 4 um ambiente que integre todos os passos desde a codifica¸c˜ao `a implanta¸c˜ao destes Web Services. Atualmente GT4IDE encontra-se em fase alfa e o seu uso n˜ao ´e recomendado para ambientes de produ¸c˜ao.
As funcionalidade fornecidas por GT4IDE incluem gera¸c˜ao de arquivos dos servi¸cos baseado em parˆametros fornecidos pelos usu´arios, gera¸c˜ao de c´odigo Java, sincroniza¸c˜ao entre c´odigo Java e o arquivo WSDL e a gera¸c˜ao do arquivo de implanta¸c˜ao GAR.
4Web Services Resource Framework
3.5.3 GriDE
GriDE [SSP+03, gri06b] ´e um ambiente integrado de desenvolvimento (IDE) para computa¸c˜ao em grade que visa fornecer em uma ´unica ferramenta recursos para o de- senvolvimento, depura¸c˜ao, execu¸c˜ao e monitoramento de aplica¸c˜oes de grade. Esta ferramenta, desenvolvida no Asia Pacific Science and Technology Center da Sun Mi- crosystem, foi projetada como um m´odulo da plataforma NetBeans IDE [net06], que fornece um arcabou¸co para a cria¸c˜ao de IDEs.
As funcionalidades j´a dispon´ıveis de GriDE incluem a submiss˜ao de tarefas na grade, busca de recursos na grade e monitoramento das tarefas submetidas com recupera¸c˜ao de resultados. Al´em disso, existe ainda algumas fun¸c˜oes preliminares de um editor de workflow para a grade. Todas essas funcionalidades s˜ao realizadas atualmente basea- das no Globus, mas no futuro poder˜ao utilizar servi¸cos de outras grades. O c´odigo da implementa¸c˜ao atual ´e fechado mas promete se tornar c´odigo-aberto em breve.
Nesta se¸c˜ao vimos as principais funcionalidades dispon´ıveis nas atuais ferramentas de Computa¸c˜ao em Grade. Na categoria de ambientes para workflows, vimos a cons- tru¸c˜ao de aplica¸c˜oes usando componentes gr´aficos, que apesar de n˜ao ter ainda uma linguagem padronizada, promete crescer bastante usando pesquisas da ´area de pro- grama¸c˜ao baseada em componentes da Engenharia de Software. Vimos os PSEs, que oferecem recursos de reutiliza¸c˜ao de software para a constru¸c˜ao de aplica¸c˜oes restritas a um dom´ınio espec´ıfico. Apesar de normalmente serem dependentes de um ambiente de execu¸c˜ao, os PSEs s˜ao bastante eficientes na dissemina¸c˜ao da Computa¸c˜ao em Grade junto `a comunidade cient´ıfica. Os Portais, apesar de n˜ao atenderem a fase de cons- tru¸c˜ao das aplica¸c˜oes, s˜ao a principal ferramenta usada na intera¸c˜ao com a Grade. O ambiente web, familiar ao usu´ario, facilita o seu uso e dissemina¸c˜ao, al´em de ser muito pr´atico, pois n˜ao necessita de instala¸c˜ao. O uso dos portais personaliz´aveis que usam a tecnologia de portlets vem crescendo bastante, mostrando o sucesso dos portais junto
`a comunidade. Na ´ultima categoria apresentada, os PSAs, vimos funcionalidades es- pec´ıficas que s˜ao importantes por atenderem uma grande comunidade de usu´arios: os desenvolvedores deaplica¸c˜os param´etricas.
Por fim, vimos ferramentas interessantes que n˜ao se encaixaram em nenhuma das categorias da nossa classifica¸c˜ao. Primeiramente vimos as funcionalidades de IC2D para monitoramento e controle de aplica¸c˜oes que usam a biblioteca ProActive. Em seguida vimos os projetos GT4IDE e Gride, ambos baseados no sistema Globus e que, como o nosso projeto, usa a plataforma Eclipse para fornecer uma ambiente de desenvolvimento.
E importante salientar a diferen¸ca entre os dois: GT4IDE visa fornecer um ambiente´ para a constru¸c˜ao de servi¸cos para a Grade, e Gride fornece uma IDE para facilitar todas as fases do ciclo de desenvolvimento de aplica¸c˜oes.
Na pr´oxima se¸c˜ao descreveremos o problema que este trabalho visa solucionar, ana- lisando as dificuldades existentes para a utiliza¸c˜ao da Grade por parte dos usu´arios e desenvolvedores de aplica¸c˜oes.
4 Descri¸c˜ ao do Problema
O not´orio desenvolvimento da computa¸c˜ao em Grade deve-se principalmente ao grande interesse na utiliza¸c˜ao dos valiosos recursos oferecidos pelas Grades. V´arios esfor¸cos tˆem sido feitos para fornecer uma infra-estrutura (middleware) que disponibilize o acesso `a estes recursos. Entretanto, em virtude da complexidade computacional do ambiente, a forma de acesso aos servi¸cos oferecidos pelos middlewares ainda ´e muito complexa para o usu´ario da Grade, haja visto que este usu´ario normalmente ´e um cientista desenvolvedor de aplica¸c˜oes.
As principais necessidades dos usu´arios da Grade incluem atividades relacionadas `a constru¸c˜ao de suas aplica¸c˜oes e `a intera¸c˜ao com os servi¸cos da Grade para a submiss˜ao, monitoramento e controle, e a obten¸c˜ao dos resultados da execu¸c˜ao. Conforme visto na se¸c˜ao 3, os portais (Se¸c˜ao 3.3) fornecem ferramentas que vem atendendo cada vez melhor `a quest˜ao da intera¸c˜ao com os servi¸cos da Grade. Entretanto, os t´ıpicos portais fornecem pouco suporte ao usu´ario na constru¸c˜ao de suas aplica¸c˜oes. Os ambientes de workflow (Se¸c˜ao 3.1), por sua vez, fornecem suporte nas atividades de constru¸c˜ao das aplica¸c˜oes, mas a maioria peca pela falta de portabilidade das aplica¸c˜oes constru´ıdas nestes ambientes, que normalmente s˜ao desenvolvidas para um middleware de Grade espec´ıfico. A exce¸c˜ao a este caso ´e o projeto P-GRADE (Se¸c˜ao 3.1.1) que fornece gera¸c˜ao de c´odigo somente para o sistema Globus, mas prevˆe futuramente a gera¸c˜ao de c´odigo para GAT (Se¸c˜ao 2.7.1). Outras ferramentas como o GT4IDE (Se¸c˜ao 3.5.2) e o comercial IBM Grid Toolbox [IBM06] fornecem um ambiente de desenvolvimento, mas restrito `a constru¸c˜ao e implanta¸c˜ao de servi¸cos para a Grade. J´a o projeto Gride (Se¸c˜ao 3.5.3), apesar de fornecer ferramentas para o ciclo completo de desenvolvimento de aplica¸c˜oes, ´e espec´ıfico para o sistema Globus.
Esta carˆencia de uma ferramenta para v´arios middlewares, na qual o usu´ario dis- ponha de recursos para realizar todas as atividades que comp˜oem o ciclo completo de desenvolvimento e que permita a constru¸c˜ao de aplica¸c˜oes port´aveis, gera um cen´ario no qual este usu´ario utiliza v´arias ferramentas n˜ao integradas que atendem `a diferentes necessidades. Neste cen´ario ´e poss´ıvel encontrar usu´arios realizando tarefas de forma n˜ao automatizada (e.g. ssh). A situa¸c˜ao piora quando a mesma aplica¸c˜ao deve execu- tar em um novo middleware de Grade: al´em de ter que utilizar novas ferramentas, o usu´ario tem que reescrever sua aplica¸c˜ao para adequ´a-la ao novo ambiente de execu¸c˜ao.
Acreditamos que o f´acil acesso aos recursos da Grade unido `a portabilidade das
