Um Padrão Canônico para Controle de Paralelização em Aplicações de e-science

Transcrição

1 Um Padrão Canônio para Controle de Paralelização em Apliações de e-siene Alexandre R. Nardi 1, Diogo R. B. Nasimento 2, Murilo R. Pontes 2, Thiago T. Seixas 2, Fabiano A. F. Graças 3, João E. Ferreira 4 1 Mirosoft Brasil 12901, Nações Unidas São Paulo SP Brasil 2 Esola Politénia de Pernambuo Universidade de Pernambuo (UPE) 455, Rua Benfia Reife PE Brasil 3 Universidade Salgado de Oliveira (UNIVERSO) 2169, Av. Masarenhas de Moraes Reife PE Brasil 4 Instituto de Matemátia e Estatístia Universidade de São Paulo (USP - SP) 1010, Rua do Matão São Paulo SP Brasil alexandre.nardi@mirosoft.om, {drbn,mrp}@ds.upe.br, tts@poli.upe.br, fabiano.arruda@hotmail.om, jef@ime.usp.br Abstrat. The use of workflow ontrol-flow patterns in e-siene appliations results in produtivity improvement, allowing the sientist to onentrate in his/her own speialization area. However, the use of workflow ontrol-flow patterns for exeution in grids remains an opened question. This paper desribes a anonial pattern ompliant to parallelization senarios, ommonly found in e-siene appliations. It also presents a loosely oupled and extensible solution, to use this and other patterns in grids. As a result, it is expeted greater flexibility in the grid usage and in representing parallelization senarios, helping the sientist tasks. Resumo. O uso de padrões de workflow para ontrole de fluxo em apliações de e-siene resulta em maior produtividade por parte do ientista, permitindo que se onentre em sua área de espeialização. Todavia, o uso de padrões de workflow para paralelização em grades permanee uma questão em aberto. Este texto desreve um padrão anônio que atende a diversos enários de paralelização omumente enontrados em apliações de e- Siene. Apresenta também uma solução de baixo aoplamento e extensível para o uso deste e de outros padrões em grades. Com isso, espera-se maior flexibilidade na utilização de grades e na representação de enários de paralelização, auxiliando o trabalho do ientista. 1. Introdução O uso de padrões de workflow em apliações de e-siene aumenta o número de possibilidades de análises em diversas áreas do onheimento, sem o ônus da omplexidade de implementar os omportamentos enapsulados nos padrões diretamente nas apliações.

2 A fim de reduzir o tempo gasto no proessamento de análises e álulos, pode-se utilizar grades para exeução de tarefas paralelizáveis, Desse modo, o ientista ganha maior agilidade em suas pesquisas e estudos. A partir dessas onstatações, Nardi [1] disute a representação de workflows e a exeução em grade. É feita a apresentação do Padrão Junção Combinada (PJC), que oferee failidade na implementação de diversos dos padrões de ontrole de fluxo propostos por Russell [2]. É apresentada também uma proposta para implementação de uma solução de baixo aoplamento para a utilização desse padrão por apliações de e- Siene e sua exeução em grade. Este novo trabalho omplementa [1], ao detalhar os elementos da arquitetura de baixo aoplamento proposta e desrever as prinipais araterístias da implementação realizada até o momento. Neste texto, a Seção 2 apresenta trabalhos relaionados aos temas workflow, grades e também sobre a exeução de workflows em grades. A Seção 3: revisa o Padrão Junção Combinada (PJC), apresentado iniialmente em [1]; propõe o uso de representação independente de plataforma de desenvolvimento ou exeução, de modo que apliações existentes possam se benefiiar das onstruções elaboradas desritas por Russell [2]; e desreve a arquitetura desta solução, apresentando uma proposta para independênia entre os prinipais elementos da solução - a apliação de e- Siene e os gereniadores de workflow e de grade. A Seção 4 desreve deisões tomadas quanto ao desenvolvimento e apresenta o estado atual da implementação. Por fim, a Seção 5 onlui o trabalho, apresentando os primeiros resultados obtidos e também aponta para os resultados esperados quando do término da implementação. 2. Trabalhos Relaionados Desde a publiação dos padrões de workflow por Aalst [3], itados em diversos trabalhos aadêmios, a análise de ferramentas de workflow passou a onsiderar omo ritério de omparação a implementação ou não dos padrões Soluções de Workflow Existentes Em [3] e [2], Aalst, Russell et al estudam diversos produtos omeriais e linguagens de workflow, dentre os quais Staffware, IBM WebSphere MQ Workflow, FLOWer, COSA, BPMN, BPEL, XPDL, SAP Workflow e FileNet. Cada produto é avaliado quanto à implementação ou não dos padrões de ontrole de fluxo. A mesma análise é realizada em [4] por Aalst, Hofstede e Russell para gereniadores de workflow de ódigo aberto, omo jbpm, OpenWFE e Enhydra Shark. Todavia, o objetivo desses trabalhos não inlui a exeução em grade. Na plataforma Windows existem ainda o BizTalk Server [4], ferramenta para integração de sistemas, que inlui um gereniador de workflow, e o Windows Workflow Foundation (WF) [5], gereniador de workflow inluso no.net Framework [6]. As duas soluções implementam padrões básios de paralelização, também sem prever exeução em grade Soluções de Grade Existentes A diversidade de opções para exeução de sistemas distribuídos pode ser observada em diferentes soluções de grade.

3 O Projeto Globus [7] oferee infra-estrutura para grades geografiamente distribuídas e apresenta Arquitetura Orientada a Serviços, SOA [8]. Como parte das ferramentas e omponentes que o integram está o Globus Toolkit [9]. Este permite que o Globus seja utilizado por meio de serviços web, tornando viável a integração de uma série de apliações, potenialmente em plataformas heterogêneas. Baseado em CORBA [10], o InteGrade [11] oferee uma solução orientada a objetos para distribuição e exeução de apliações em grades, utilizando o tempo oioso dos nós. Carateriza-se por atender a enários em que haja intensa omuniação entre os nós, e os omponentes da apliação são fortemente aoplados. Já o Alhemi [12] baseia-se na Plataforma.NET [6]. É uma infra-estrutura para distribuição de exeução de omponentes.net sobre plataforma Windows Exeução de Workflows em Grade Alguns trabalhos desrevem a exeução de workflows em grades, omo Fahringer em [13], que apresenta a AGWL (Abstrat Grid Workflow Language). Essa linguagem ontém onstruções de paralelização, mas sem menionar padrões mais sofistiados omo os desritos por Russell [2]. Pautasso [14], por sua vez, desreve o uso de padrões em grades. Pautasso propõe um onjunto de padrões para paralelização e fluxo de dados sem detalhar ombinações de possibilidades omo bloqueio e anelamento. Não é, ainda, abordada a omuniação entre os gereniadores de workflow e de grade. Já Prodan [15] propõe uma abordagem para esalonamento dinâmio de workflows por meio de um arquivo om ódigo em Java sobre o Globus Toolkit [9]. Contudo, não trata os padrões de ontrole de fluxo. Condor DAGMan [16] permite a exeução de workflows em grades, podendo ser omplementado por soluções omo o Globus para aumento do poder omputaional. No entanto, esta abordagem não trata, de modo transparente ao usuário, onstruções omplexas omo diversos padrões de ontrole de fluxo. Essa tarefa fia a argo do usuário, que esreve um arquivo de desrição a ser submetido ao Condor [16]. Do mesmo modo, Martlet [17] abstrai a exeução de workflows em grades sem onsiderar os padrões de workflow. A Grid Proess Exeution Language (GPEL), proposta por Wang [18], possui onstruções de paralelização dependentes de grade e sem o uso de padrões. 3. Proposta de Solução Esta proposta visa ofereer interfaes de fáil utilização pelo ientista de áreas que não possuem a omputação omo atividade prinipal. Essas interfaes podem ser empregadas em apliações existentes ou novas, seja para uso de padrões de ontrole de fluxo não existentes nas soluções atuais, seja para melhoria de desempenho om a exeução em grade, ou ambos Revisão do Padrão Junção Combinada (PJC) Dos quarenta e três padrões desritos por Russell [2], vinte e sete se relaionam a ramifiação, sinronização ou múltiplas instânias, podendo se aproveitar da exeução em grades. Por suas similaridades, esta pesquisa, onforme iniialmente apresentado em

4 [1], se propõe a tratar os disriminadores, junções pariais e os padrões para múltiplas instânias. A arquitetura de baixo aoplamento permite a extensão futura a outros padrões, onforme desrito na Seção 3.2. Esses padrões, ao serem ombinados por meio de onfigurações, resultam no modelo apresentado na Figura 1, um padrão anônio denominado Padrão Junção Combinada (PJC). Para auxiliar na omparação om os padrões desritos por Russell [2], foi deidido representar o PJC utilizando Redes de Petri Coloridas (Coloured Petri-Nets CPN). Pronto m,a,n,din,an [A1,,Am],n,din,an Iníio [din] Divisão A 1... A m Junção [an] n Término Permite Novas Instânias Canela Atividades Inompletas o 1 Iniia Nova Instânia Atividade Dinâmia A i Figura 1: Padrão Junção Combinada Russell [2] apresenta o omportamento bloqueante omo solução para evitar que uma atividade de entrada seja exeutada mais de uma vez antes do término da exeução do padrão. Caso o bloqueio não seja implementado, omo no Padrão Disriminador Estruturado (WCP-9), evitar tal forma de exeução passa a ser responsabilidade da apliação que usa o padrão. Caso ontrário, seu omportamento não é previsível. Para que a implementação ofereça padrões que reflitam onjuntos de omportamentos hermétios, o PJC sempre apresenta omportamento bloqueante, diferentemente do apresentado em [1], onde era opional. Desse modo, tira-se da apliação a responsabilidade por permitir ou não o uso do padrão antes que uma exeução anterior tenha sido onluída, aumentando a previsibilidade da exeução. O omportamento da junção ombinada é determinado pelos parâmetros de entrada: Quando a entrada for a tupla (m,a,n,din,an), serão exeutadas m instânias da atividade A; n india o número de atividades que deve ser ompletado para a produção da saída em o 1 ; din determina se é possível aresentar novas instânias dinamiamente durante a exeução; e an india se as demais atividades, após n terem sido ompletadas, devem ou não ser aneladas; Quando a entrada for a tupla ([A 1,...,A m ],n,din,an), a exeução das atividades A 1,...,A m será realizada em paralelo, om n, din e an omo aima.

5 A tabela a seguir ilustra possíveis valores de entrada e o padrão ao qual a ombinação orresponde. Tabela 1: padrões de junção para múltiplas instânias e para atividades distintas Padrão Entrada (m>1) n din an P1 (m,a,n,din,an) 1 não não P2 (m,a,n,din,an) 1 não sim P3 (m,a,n,din,an) 1 sim não P4 (m,a,n,din,an) 1 sim sim P5 (m,a,n,din,an) 1<n<=m não não P6 (m,a,n,din,an) 1<n<=m não sim P7 (m,a,n,din,an) 1<n<=m sim não P8 (m,a,n,din,an) 1<n<=m sim sim WCP-28 ([A1,...Am],n,din,an) 1 não não P9 ([A1,...Am],n,din,an) 1 não sim P10 ([A1,...Am],n,din,an) 1 sim não P11 ([A1,...Am],n,din,an) 1 sim sim WCP-31 ([A1,...Am],n,din,an) 1<n<=m não não P12 ([A1,...Am],n,din,an) 1<n<=m não sim P13 ([A1,...Am],n,din,an) 1<n<=m sim não P14 ([A1,...Am],n,din,an) 1<n<=m sim sim Vale notar que a ombinação dos parâmetros de entrada permite ao PJC representar três tipos de padrões: Padrões previstos por Russell [2]: o Disriminador om bloqueio (WCP-28); o Junção parial om bloqueio (WCP-31). Combinações de padrões mapeados por Russell [2], aresidos de omportamento bloqueante: o P5: junção parial estátia de múltiplas instânias (WCP-34) om bloqueio; o P6: junção parial estátia de múltiplas instânias om anelamento (WCP-35) e bloqueio; o P7: junção parial dinâmia de múltiplas instânias (WCP-36) om bloqueio;

6 o P8: junção parial dinâmia de múltiplas instânias (WCP-36) om bloqueio e anelamento; o P9: disriminador om bloqueio (WCP-28) e anelamento; o P12: junção parial om bloqueio (WCP-31) e anelamento. Padrões não previstos por Russell [2]: 3.2. Arquitetura o P1: disriminador para múltiplas instânias om bloqueio; o P2: disriminador para múltiplas instânias om anelamento e bloqueio; o P3: disriminador dinâmio para múltiplas instânias om bloqueio; o P4: disriminador dinâmio para múltiplas instânias om anelamento e bloqueio; o P10: disriminador dinâmio om bloqueio; o P11: disriminador dinâmio om bloqueio e anelamento; o P13: junção parial dinâmia om bloqueio; o P14: junção parial dinâmia om bloqueio e anelamento. Apliações de e-siene que utilizam as soluções apresentadas na Seção 2 araterizamse por arquiteturas de alto aoplamento. Tais apliações inorporam tarefas omo o gereniamento do fluxo de exeução e a integração do software de grade. Considerando ada apliação isoladamente, esse aoplamento apresenta o inonveniente de não permitir a modifiação de fluxo independentemente do restante do sistema. No entanto, do ponto de vista de desempenho, esse aoplamento não é prejudiial. Ao se observar onjuntos de apliações e as plataformas para seu desenvolvimento e exeução, esse aoplamento difiulta a utilização de padrões que, nesse aso, preisam ser implementados para ada solução. Por exemplo, Russell [2] avalia quatorze produtos omeriais de workflow, identifiando quais ofereem implementações para os padrões de ontrole de fluxo. Essa avaliação foi realizada também em [4] para três gereniadores de workflow de ódigo aberto. Outra limitação deorrente do aoplamento é a impossibilidade de abstração da presença de grade. Ou uma apliação é desenvolvida para uso em grade, e para software espeífio de gereniamento de grade, ou é desenvolvida para ser exeutada sem grade. Essa araterístia faz om que a implementação dos padrões de workflow relaionados à exeução paralela seja espeífia para exeução em grade ou sem ela. A solução de baixo aoplamento idealizada nesta pesquisa e ilustrada na Figura 2, atende a um onjunto mais amplo de enários. Para tal, a presença de amada de abstração em relação ao gereniador de workflow utilizado pela apliação viabiliza a implementação de padrões uma únia vez, podendo ser utilizada por vários produtos de workflow. Do mesmo modo, uma amada genéria om provedores espeífios de aesso a gereniadores de grade, torna possível a integração a soluções para grade e mesmo a exeução sem o uso de grade, sendo possível o uso de equipamentos multiproessados, útil para problemas envolvendo alto tráfego de dados.

7 Figura 2: arquitetura da solução proposta. A área delimitada pela região traejada india os elementos que devem ser implementados. Com o objetivo de tornar a solução desaoplada e independente de plataforma, a arquitetura proposta nesta seção, orientada a serviços (SOA) [8] apresenta o uso de amadas, e sua implementação, desrita na Seção 4, utiliza serviços web omo meanismo de omuniação entre elas Uso de Múltiplas Camadas Os omponentes da solução proposta devem ser independentes, de modo que possam ser substituídos em função da esolha de plataforma e dos gereniadores de workflow e de grade. Tal independênia é obtida a partir de arquitetura em amadas, onforme ilustrado na Figura 2. Os mapas presentes na figura permitem que as seguintes araterístias de exeução sejam onfiguradas antes da exeução, o que tornam esta arquitetura flexível e extensível: Mapa Padrão-Implementação: permite que o Exeutor de Padrões, ao reeber uma requisição da Apliação de e-siene, identifique qual padrão de paralelização deve ser utilizado. Com isso, implementações que possuam otimizações podem ser utilizadas de modo simples; Mapa Grade-Implementação: india ao Integrador Padrão-Grade qual Exeutor Paralelo deve ser utilizado.

8 As interfaes entre as amadas são pré-definidas e a omuniação entre elas realizada por meio de serviços web. Desse modo obtém-se independênia de plataforma. Vale notar, todavia, que essa independênia ainda está sujeita à afinidade de plataforma tanto do gereniador de grade quanto do de workflow Apliação de e-siene Este trabalho se propõe a atender tanto a apliações existentes quanto a novas apliações que envolvam workflows ientífios ontendo tarefas a serem exeutadas paralelamente, om padrões mais sofistiados, omo o PJC. Potenialmente, tal exeução pode ainda ser realizada em grade, dependendo da presença desta e das seguintes araterístias da apliação: As tarefas devem ser independentes umas das outras: desse modo haverá ausênia de omuniação entre os nós. Embora este pressuposto restrinja o universo de problemas que podem ser atendidos, é neessário, uma vez que a omuniação entre os nós depende do software seleionado omo gereniador de grade. Como esta solução foi onebida para uso om diversos gereniadores de grade, pode ser esolhido algum que não possua tal reurso, omo Alhemi [12], por exemplo; Apliação entrada em proessamento ao invés de trânsito de dados: a transferênia intensa de dados de e/ou para os nós pode onerar o sistema, invalidando os benefíios da utilização de grade. Neste aso, pode ser mais apropriado o uso de omputação em luster, que possui barramento de omuniação de alta veloidade; A ritiidade da exeução nos nós da grade, omo garantia de exeução e tolerânia a falhas, pode exigir ontroles adiionais do software gereniador de grade, possivelmente ausentes, omo é o aso do Alhemi [12]. Caso haja neessidade de omuniação entre as atividades sendo exeutadas paralelamente, ou intenso trânsito de dados entre estas, pode-se utilizar implementação espeífia do Exeutor sem Grade, apresentado na Figura 2. Nesse aso, o exeutor pode fazer a distribuição das atividades entre nós de um luster de alto desempenho ou om máquinas multi-proessadas. A fim de reduzir o impato em termos de modifiações nas apliações existentes, as atividades a serem exeutadas paralelamente om uso do PJC devem ser passadas adiante por meio da utilização de serviços web. Conseqüentemente, aumenta-se também o número de apliações que podem ser atendidas por esta proposta, que se torna independente de plataforma de desenvolvimento e exeução, do ponto de vista da apliação Gereniador de Workflow A utilização de onstruções paralelizáveis avançadas, omo o PJC, e a exeução em grade, apliam-se a porções espeífias dentro do fluxo de uma apliação de e-siene. Assim, ambas podem ser onsideradas omo otimizações e sofistiações para tais apliações.

9 Posto isso, faz-se mister que apliações existentes ontinuem funionando om o mesmo gereniador de workflow. Esse é o motivo pelo qual a solução proposta deve ser independente do gereniador esolhido. Para eliminar qualquer possível dependênia de gereniador ou plataforma, as onstruções implementadas, omo é o aso do PJC, devem sê-lo utilizando padrões abertos. Cada onstrução paralela deve ser aionada a partir da apliação de e-siene omo um serviço web, de modo isolado do restante da apliação. Após o retorno da exeução paralela, o fluxo segue para a próxima atividade do workflow Gereniador de Grade A arquitetura proposta, orientada a serviços, garante autonomia às partes da solução. Desse modo, é possível utilizá-la om ou sem a presença de grade, atendendo a enários diversos: Exeução paralela de atividades sem a presença de gereniador de workflow: a apliação pode submeter um onjunto de atividades para exeução paralela. Esse aso é tratado omo um workflow om uma únia onstrução paralela; Aumento das opções de paralelização em workflows: a extensão dos reursos de workflow, om o uso dos padrões om onstruções paralelizáveis avançadas, pode não demandar o uso de software gereniador de grade. Nesse aso, o modelo de paralelização baseado em threads de exeução é apropriado; Aumento de desempenho de porções paralelizáveis da solução: pode ser neessária a presença de gereniador de grade, para padrões onvenionais de paralelização; Aumento das opções de workflow e de desempenho: é a ombinação da extensão dos reursos de paralelização em workflows om a presença da grade Exeutor Genério de Padrões (EGP) Oferee uma interfae omo serviço web para ser hamada pela apliação de e-siene. A partir de onfiguração onstante do Mapa Padrão-Implementação, o exeutor deide qual implementação de padrão deve ser aionada. Então, faz a hamada através de um serviço web. Quando o serviço for onluído, devolve o resultado para a apliação de e- Siene. Esse modelo de serviços permite a implementação de novos padrões, o que onfere extensibilidade à arquitetura. Além disso, novas implementações, potenialmente otimizadas em termos de desempenho ou gereniabilidade, podem ser aresidas, o que pode ontribuir para o uso desta solução em ambientes de maior ritiidade Exeutores Espeífios de Padrões Esta amada ontém implementação para o PJC, e foi onebida para que seja estendida para onter outras implementações, do PJC ou de outros padrões. A implementação dos padrões faz todo o ontrole de exeução do padrão em questão.

10 O PJC é implementado aqui sem o uso de um gereniador de workflow para uidar do fluxo interno do padrão. Essa deisão foi resultado do balanço dos seguintes fatores: O PJC inlui a ombinação de diversos padrões ujo fluxo é determinado, e não deve sofrer modifiações; No iníio do projeto foi ogitado o uso do Windows Workflow Foundation [5], um gereniador de workflows disponível omo parte da plataforma.net [6]. Para que pudesse ser empregado, seu esalonador de tarefas, baseado em threads, teria de ser modifiado ou substituído; O gereniamento da exeução das tarefas é espeífio e deve ser realizado fora do esopo de um gereniador de workflow, ujas tarefas de gereniamento são genérias. Por exemplo, o tratamento de bloqueios não se benefiia da presença de um gereniador de workflow. A estrutura proposta, no entanto, permite que seja realizada implementação do PJC utilizando-se dos reursos que se julgue apropriados, e também permite a inlusão de novos padrões Integrador Padrão-Grade (IPG) Do mesmo modo que o Exeutor de Padrões, este integrador deide, a partir da onfiguração presente no Mapa Grade-Implementação, qual o Exeutor a ser aionado para a exeução das atividades de forma paralela Exeutores para Gereniadores de Grades Neste ponto, qualquer gereniador de grade que ofereça interfae por meio de serviços web pode ser utilizado. Esse é o aso do Globus, que está sendo empregado para os testes da solução. Caso o gereniador de grade não disponibilize interfae om serviços web, ainda assim é possível desenvolver o exeutor, de aordo om as restrições do gereniador de grade. Nesse aso, o exeutor oferee ao IPG uma interfae em serviços web e se omunia om o gereniador da grade usando algum método que este ofereça nativamente. Com isso, aumenta-se o alane da solução. 4. Considerações sobre a Implementação A arquitetura proposta desreve os prinipais elementos e a omuniação entre eles. Esta seção apresenta várias deisões realizadas para que o resultado da implementação possa ser: Utilizado em ambientes heterogêneos, enário este omumente enontrado em instalações aadêmias e omeriais; Flexível o sufiiente para reeber melhorias em módulos espeífios, omo a substituição do algoritmo usado para a implementação do PJC, sem a neessidade de modifiação da solução toda; Substituição de elementos omo os gereniadores de workflow e de grade om baixo impato em termos de mudanças na solução e na apliação de e-siene;

11 Extensível para atender a outros enários de paralelismo, omo por exemplo, novos padrões que sejam neessários; Extensível para permitir o uso da solução om outros gereniadores de workflow ou de grade Uso de Serviços Web Com o objetivo de permitir que a solução seja utilizada em ambientes heterogêneos, optou-se pela disponibilização de interfaes em serviços web. Isso foi feito tanto para interfaes para a exeução das atividades paralelas, nas diversas amadas, omo para retornos, na forma de allbaks. Como a araterístia de apliações que se benefiiam de paralelização em grade é ser onsumidora de UCP ao invés de omuniação ou outros reursos, o impato do uso de serviços web pode ser desprezado. A implementação realizada utiliza o Windows Communiation Foundation (WCF) [19], que possibilitou esta análise através de onfiguração do meanismo de omuniação desaoplada do ódigo do sistema em arquivos de onfiguração. Como otimização na exeução do sistema, este avalia em tempo de exeução a plataforma na qual os omponentes estão instalados. Para omuniação entre amadas na plataforma Windows, é utilizado meanismo binário baseado em hamadas a proedimentos remotos (RPC). Para omuniação em outras plataformas, é utilizado meanismo baseado em serviços web Caraterístias da Solução Proposta A arquitetura proposta foi implementada utilizando o modelo de baixo aoplamento (loose oupling), a fim de garantir maior flexibilidade e extensibilidade à solução. Uma vez definidas as interfaes de omuniação om os diversos elementos externos, estes podem ser substituídos ou aresidos resultando baixo impato no sistema e sua exeução. A fim de garantir maior flexibilidade à solução, que pode ser exeutada na presença ou não do Gereniador de Grade, é forneida a implementação Exeutor sem Grades, que se utiliza de threads de exeução ao invés dos nós da grade Comuniação entre Camadas Comuniação entre a Apliação e o Gereniador de Workflow A Apliação de e-siene se omunia diretamente om o Gereniador de Workflow esolhido para exeução de seu fluxo. Desse modo, não há impatos em apliações préexistentes. Esse meanismo se altera apenas quando houver a neessidade de se exeutar uma tarefa omposta por sub-tarefas em paralelo om o uso do PJC. Nesse aso, a omuniação se dará a partir do envio de representação do padrão no formato Extensible Markup Language, (XML) [21] ao EGP, onforme ilustrado na Figura 3.

12 <PJCAtivity EGP_URL="net.pipe://loalhost/EgpServie/NetNamedPipeBinding" NumberOfInstanes="5" NumberOfReady="3" DynamiInstane="False" CanelAtivities="True" Name="pjAtivity1" xmlns="lr-namespae:wfg.wfgengine.ativities;assembly=wfgativities"> <PJCAtivity.Ativities> <PJCTaskAtivity ResourePath="C:\...\ConsoleAppliation1.exe"... ResoureName="ConsoleAppliation1.exe" Parameters="1 2" Name="pjTaskAtivity1" /> </PJCAtivity.Ativities> </PJCAtivity> Figura 3: representação do PJC no formato XML Interfae entre a Apliação e o EGP O EGP oferee uma API para reeber soliitações de exeução do PJC a partir da Apliação de e-siene. Essa API é bloqueante, retornando apenas após o término da exeução do padrão. Para que uma eventual falha na exeução de alguma tarefa não bloqueie a apliação de e-siene indefinidamente, o Exeutor Espeífio para o PJC deve prever essa possibilidade. Isso é feito por meio de ação não bloqueante deste e do ontrole de exeução por meio de allbaks, onforme detalhado à frente Interfae entre o EGP e a Implementação dos Padrões O EGP atua apenas omo uma ponte genéria entre a apliação e a implementação do padrão sendo hamado (PJC, no ontexto deste trabalho). Conforme desrito em , a implementação do PJC não usará internamente um gereniador de workflow. Contudo, aso alguma outra implementação para o PJC ou para outro padrão deida fazê-lo, não existe relação entre esse gereniador e aquele utilizado pela Apliação de e-siene. Dessa forma, é possível o uso de um gereniador de workflow pela apliação e outro para a exeução do padrão. Isso por um lado minimiza as modifiações em apliações existentes, quando aresidas do uso do padrão; e, por outro lado, exige um gereniador de workflow que permita sobresrever o esalonador apenas para a exeução do padrão, o que elimina qualquer restrição ao uso de um gereniador para a apliação. A interfae de omuniação prevê a exeução bloqueante do padrão Interfae entre a Implementação dos Padrões e o Integrador Padrão-Grade (IPG) O IPG é independente da presença e implementação de Gereniador de Grade. Tal independênia é obtida om a presença dos exeutores, estes sim espeífios para ada Gereniador de Grade. O IPG apresenta-se omo serviço web que é aionado pela implementação dos padrões, para soliitar a exeução paralela de atividades. Deve disponibilizar uma interfae de allbak para que o exeutor utilizado sinalize o término da exeução de ada atividade, de modo que a implementação do padrão possa deidir o próximo passo, omo no aso de anelamento, por exemplo.

13 Interfae entre a o Integrador Padrão-Grade (IPG) e os Exeutores de Grade Deve haver uma implementação de Exeutor para ada Gereniador de Grade que se desejar integrar à solução. A seleção deste exeutor é realizada por meio de arquivo de onfiguração, o Mapa Grade-Implementação Comuniação entre os Exeutores de Grade e o Gereniador de Grade Cada exeutor é responsável por submeter as tarefas à grade e ontrolar sua exeução. Alguns Gereniadores de Grade possuem onstruções para exeução de fluxos. Entretanto, as implementações pesquisadas, omo Prodan em [15], permitem apenas fluxos simples, sem a sofistiação das possibilidades do PJC. Por esse motivo, a solução proposta não utiliza os reursos de workflow que porventura sejam implementados pelos Gereniadores de Grade. O ontrole de exeução pode ser realizado por um ou ambos os modelos a seguir: Modelo push: o Gereniador da Grade ativamente informa, através de hamadas de função de retorno (allbak), o término, bem ou mal-suedido, da exeução da tarefa submetida a determinado nó; Modelo pull: o Gereniador da Grade é passivo, ofereendo função para onsulta da exeução de determinada tarefa em um nó espeífio Considerações sobre o Desempenho A independênia de plataforma obtida pelo trânsito de mensagens que não estejam em formato binário, araterístia do uso de serviços web, apresenta um usto em termos de desempenho. Por esse motivo, a solução proposta neste texto restringe-se a asos em que o tempo da exeução paralela de atividades seja superior em ordem de grandeza ao tempo usado na omuniação entre as amadas apresentadas nas seções seguintes. Do mesmo modo, o tempo de omuniação entre as amadas deve ser desprezível quando omparado ao tempo de proessamento a ser realizado nos nós da grade. Quanto maior o tempo de proessamento, menor o impato da omuniação entre as amadas, quando omparado à exeução monolítia. Como parte deste trabalho, serão realizadas simulações om tempos resentes de proessamento, a fim de melhor restringir a utilização desta solução. 5. Conlusão Existem vários trabalhos ientífios voltados a soluções de workflows em grades e sobre a implementação ou não de padrões de ontrole de fluxo por produtos omeriais ou de ódigo aberto. Todavia, a relação entre os gereniadores de workflow e de grade não foi explorada de modo a permitir que o ientista defina seus fluxos om a utilização de padrões para paralelização que tornem transparente a existênia ou não da grade. Neste trabalho, foi apresentado um padrão para ontrole de fluxo e uma solução de baixo aoplamento que torna transparente a utilização ou não de grade. Isto permite ao ientista ter a efiiênia desejada na solução de problemas e ao mesmo tempo se onentrar nas pesquisas de sua área de atuação sem ter preoupações de ordem operaional.

14 A arquitetura empregada, orientada a serviços, oferee flexibilidade e extensibilidade à solução, ao ontrário dos demais trabalhos neste texto menionados. A implementação, em seu atual estágio, india os seguintes resultados preliminares: Apliações existentes devem sofrer alterações simples para que utilizem o PJC; A presença de grade é abstraída da Apliação de e-siene, eliminando a neessidade do ientista onheer detalhes da utilização de grades; A utilização de allbaks é viável para o PJC sendo exeutado om o Globus. Com o término da implementação e a realização de novos testes, porém om enários reais, espera-se: Identifiar qual o impato do uso de serviços web, quando omparado ao uso de meanismo de omuniação binário entre as amadas da arquitetura desrita; Avaliar o impato do uso da abstração da presença de grade em ondições reais de utilização; Permitir que grupos externos de pesquisa avaliem a omplexidade de se integrar à solução, seja para implementação de novos padrões ou para inluir a integração om outro gereniador de grade. Como próximos passos, planejamos o tratamento de requisitos não funionais, omo segurança, tolerânia a falhas, monitoramento e gereniamento de workflows em grades. A implementação de outros padrões para apoio à exeução de atividades que se omuniquem também foge ao esopo deste trabalho, fiando omo proposta de trabalho futuro. 6. Referênias 1. Padrões para Controle de Fluxo e sua Exeução em Grade. Nardi, Alexandre Riardo and Ferreira, João Eduardo. João Pessoa : Soiedade Brasileira de Computação, e-siene Workshop - SBBD-SBES Vol. 1, pp Russell, Nik, et al. Workflow Control-Flow Patterns - A Revised View. s.l. : BPM Center Report, BPM Workflow Patterns. Aalst, Wil M. P. van der, et al. 1, s.l. : Springer Neitherlands, 2003, Vol. 14, pp ISSN (Print) (Online). 4. Aalst, Wil M. P. van der, Hofstede, Arthur H. M. ter and Russell, Nik. Workflow Patterns - Open Soure Produt Evaluation. Workflow Patterns. [Online] [Cited: 8 12, 2008.] 5. Mirosoft Corporation. BizTalk Server Developer Center. MSDN. [Online] [Cited: 4 14, 2008.] Windows Workflow Foundation. MSDN Library. [Online]

15 7...NET Framework Developer Center. MSDN. [Online] Mirosoft Corporation, [Cited: 4 14, 2008.] 8. Foster, Ian. Globus Toolkit 4.0: Key Conepts. The Globus Alliane. [Online] [Cited: 4 14, 2008.] 9. Erl, Thomas. Servie-Oriented Arhiteture (SOA): Conepts, Tehnology, and Design. s.l. : Prentie Hall, ISBN University of Chiago. The Globus Toolkit Homepage. The Globus Toolkit. [Online] [Cited: 08 06, 2007.] OMG. CORBA v3.0 Speifiation. CORBA v3.0 Speifiation. Needham, MA, USA : s.n., OMG Doument InteGrade: Objet-Oriented Grid Middleware Leveraging Idle Computing Power of Desktop Mahines. Goldhleger, Andrei, et al. s.l. : John Wiley and Sons Ltd., , Conurreny and Computation: Pratie & Experiene, Vol. 16, pp Buyya, Rajkumar and al., et. Alhemi -.NET Grid Computing Framework. Alhemi. [Online] The University of Melbourne, [Cited: 06 19, 2007.] Speifiation of Grid Workflow Appliations with AGWL: An Abstrat Grid Workflow Language. Fahringer, Thomas, Qin, Jun and Hainzer, Stefan. Cardiff : IEEE, Intl.Symposium on Cluster Computing and the Grid CCGrid Parallel Computing Patterns for Grid Workflows. Pautasso, Cesare and Alonso, Gustavo. Paris : IEEE, HPDC Dynami Sheduling of Sientifi Workflow Appliations on the Grid: A Case Study. Prodan, Radu e Fahringer, Thomas. Santa Fe, New Mexio - USA : ACM, ACM Symposium on Applied Computing. p The University of Wisonsin Madison. Condor Projet Homepage. The University of Wisonsin Madison. [Online] [Cited: 07 04, 2007.] Introdution and Evaluation of Martlet, a Sientifi Workflow Language for Abstrated Parallelisation. Goodman, Daniel. Banff, Alberta - Canada : ACM, International World Wide Web Conferene. p A new grid workflow desription language. Wang, Yong, Hu, Chunming and Huai, Jinpeng. Orlando : Proeedings of IEEE International Conferene on Servie Computing 2005 (s2005), Mirosoft Corporation. Windows Communiation Foundation. MSDN Library. [Online] Mirosoft Corporation, [Cited: 4 14, 2008.] W3C. Extensible Markup Language (XML). W3C. [Online] [Cited: 08 14, 2008.]