Padrões para Controle de Fluxo e sua Execução … padrões, o que se mostra adequado para seus...

Padrões para Controle de Fluxo e sua Execução em Grade

Alexandre R. Nardi1, João E. Ferreira

2

1Microsoft Brasil

12901, Nações Unidas – 04578-000 – São Paulo – SP – Brasil

2Instituto de Matemática e Estatística – Universidade de São Paulo (USP - SP)

1010, Rua do Matão – 05508-900 – São Paulo – SP – Brasil

[email protected], [email protected]

Abstract. Submission of e-Science problems to be solved by computational

grids has been focused by recent research. Solutions studied to integrate to

grid software, however, allow representing a limited number of control-flow

possibilities, forcing the user to write code to lead with several cases. Wil van

der Aalst has identified a set of forty-three workflow control-flow patterns,

including twenty-seven related to branching, synchronization or multiple

instances. This paper proposes integration between workflow and grid

management systems, which allow running scientific workflows from a

graphical modeling of workflow patterns by the scientist.

Resumo. A submissão de problemas de e-Science para execução em grades

tem sido alvo de estudos recentes. As soluções estudadas para integração com

gerenciadores de grade, contudo, permitem apenas a representação de um

número restrito de possibilidades de controle de fluxo, obrigando o usuário a

desenvolver código para tratamento de diversos casos. Wil van der Aalst

identificou um conjunto de quarenta e três padrões para controle de fluxo, dos

quais vinte e sete são referentes a ramificação, sincronização ou múltiplas

instâncias. Este trabalho propõe uma integração entre os gerenciadores de

workflow e grade, que permita a execução de workflows científicos a partir da

modelagem gráfica dos padrões de workflow pelo cientista.

1. Introdução

Problemas de e-Science tipicamente podem ser representados como workflows

científicos, como ocorre em áreas como astronomia, química e genética. O cientista

estabelece hipóteses utilizando algoritmos que resolvam problemas complexos em um

fluxo. A execução dos algoritmos pode então ser realizada em uma grade para as

unidades que forem paralelizáveis, a fim de obter o resultado em tempo que seja

aceitável.

Nesse contexto, existem duas necessidades fundamentais no dia-a-dia de cientistas, que

não são totalmente cobertas pelas soluções analisadas até o momento [1]: a

representação de padrões de workflows de modo completo e preciso; e a abstração da

utilização de software de grade.

A representação de workflows pode ser realizada de diversas formas, como: redes de

Petri coloridas [2]; expressões de álgebra de processos – como NPDL [3]; linguagens

baseadas em comandos em texto – como XPDL; ou workflow graphs [4]. Várias

abordagens são analisadas em [5], que descreve vantagens e desvantagens de cada uma.

2007 e-Science Workshope-Science

19

Aalst emprega redes de Petri coloridas (CPN – Colour Petri Networks) para descrever

os padrões, o que se mostra adequado para seus propósitos, ou seja, visualização e

entendimento. Contudo, por sua característica intuitiva, de simples compreensão, foi

escolhida a representação por meio de workflow graphs, baseado na arquitetura WASA

(Workflow-based architecture to support Scientific Applications), descrita por Medeiros

[6] como uma solução para aplicações científicas baseadas em workflows e utilizada em

produtos comerciais como IBM MQSeries Workflow e InConcert. Quanto à

implementação, foi selecionado o Windows Workflow Foundation (WF) [7], um

gerenciador de workflows gratuito e extensível que permite a representação de

workflows a partir de uma variação de workflow graphs, sobre o qual serão

implementados alguns padrões de controle de fluxo previstos por Wil van der Aalst et al

[1], conforme descrito neste texto.

Para o cientista, a utilização da grade é um recurso para aumentar o desempenho do

processamento, reduzindo o tempo total. Assim, tal tarefa, embora complexa, é

meramente técnica: o cientista deveria ser especialista em sua área e fornecer o

algoritmo específico de sua pesquisa, ao invés de utilizar parte de seu tempo pensando

em execução em grade. Contudo, aqui surge a questão de integração do gerenciador de

workflow com o gerenciador de grade. Os gerenciadores de workflow estudados

possuem estratégia própria para escalonamento de tarefas a serem executadas

paralelamente. Desse modo, deve ser possível estender o escalonador para utilizar

estratégias distintas a fim de atender aos cenários de presença ou ausência de grade.

Esta pesquisa pretende oferecer recursos para cobrir essas duas necessidades, ou seja,

transparência da presença de grade para o cientista e a integração dos gerenciadores de

workflow e de grade. Desse modo, a representação de workflows deve ser realizada sem

que o cientista precise conhecer álgebra de processos ou linguagens de workflow. A

apresentação dos padrões de workflow deve ser feita tal que possam ser utilizados pelo

cientista para representar o problema de sua área de pesquisa de forma mais intuitiva, e

pretende-se abstrair a interação com software de grade, fazendo com que sua presença

seja informada como uma configuração do sistema. Embora tenha sido escolhido o

Alchemi [8], um gerenciador de grade de código aberto, para os testes, a arquitetura

proposta é aplicável a outros gerenciadores por meio de uma interface de integração

baseada em serviços, de sorte a não haver perda de generalidade.

2. Trabalhos Relacionados

Desde a publicação dos padrões de workflow por Aalst [9], citados em diversos

trabalhos acadêmicos, a análise de ferramentas de workflow passou a considerar como

critério de seleção a implementação ou não dos padrões.

No entanto, poucas publicações, como Pautasso [10], descrevem o uso de padrões em

grades. Pautasso propõe um conjunto de padrões para paralelização e fluxo de dados

sem detalhar combinações de possibilidades como bloqueio e cancelamento. Não é,

ainda, abordada a comunicação entre os gerenciadores de workflow e de grade.

Prodan [11] propõe uma abordagem para escalonamento dinâmico de workflows por

meio de um arquivo com código em Java sobre o Globus Toolkit [12]. Contudo, não

trata os padrões de controle de fluxo.


20

Condor DAGMan [13] permite a execução de workflows em grades, podendo ser

complementado por soluções como o Globus para aumento do poder computacional. No

entanto, esta abordagem não trata de modo transparente ao usuário construções

complexas como diversos padrões de controle de fluxo, ficando essa tarefa por conta do

usuário, que escreve um arquivo de descrição a ser submetido ao Condor. O mesmo

ocorre com Martlet [14], que abstrai a execução de workflows em grades sem

considerar os padrões de workflow.

3. Padrões para Controle de Fluxo Aplicáveis a Grades

Dos quarenta e três padrões descritos por Aalst [1], vinte e sete se relacionam a

ramificação, sincronização ou múltiplas instâncias, podendo se aproveitar da execução

em grades. Por suas similaridades, este trabalho se propõe a tratar os seguintes:

(WCP-9) Discriminador Estruturado

(WCP-28) Discriminador com Bloqueio

(WCP-29) Discriminador com Cancelamento

(WCP-30) Junção Parcial Estruturada

(WCP-31) Junção Parcial com Bloqueio

(WCP-32) Junção Parcial com Cancelamento

(WCP-34) Junção Parcial Estática para Múltiplas Instâncias

(WCP-35) Cancelamento de Junção Parcial de Múltiplas Instâncias

(WCP-36) Junção Parcial Dinâmica para Múltiplas Instâncias

O processo de modelagem por parte do cientista deve abstrair quaisquer aspectos

intrínsecos da representação formal dos padrões. Aalst procura representar cada padrão

em Redes de Petri Coloridas (CPN), de modo a simplificar sua compreensão. Por

exemplo, a Figura 1 apresenta uma representação do padrão “(WCP-9) Discriminador

Estruturado”, apropriada para compreensão do padrão e seu funcionamento.

Figura 1: representação do padrão "Discriminador Estruturado" usando CPN (Fonte: [1])


21

Para a modelagem de seu fluxo, o cientista necessita apenas uma construção em que o

comportamento esteja identificado pelo nome ou código do padrão, como na Figura 2.

O gerenciador de workflows que será utilizado nos testes permite a construção de

elementos visuais que são funcionalmente equivalentes.

Figura 2: construção a ser utilizada pelo cientista

3.1. Uma Variação em Padrões de Paralelização

No tocante à implementação, a presença de número elevado de padrões pode ser

confusa e deixar de atender ao requisito de simplicidade de utilização por parte do

usuário. Segundo Aalst [2], diversos padrões são especializações de outros. Dessa

forma, no modelo físico podem ser combinados e oferecerem seu comportamento

associado a pré-condições que dependam de parâmetros de entrada.

A fim de facilitar a implementação, os padrões referentes a paralelização, destacados na

listagem da seção 3. podem ser combinados no modelo apresentado na Figura 3. Desse

modo, pode-se propor um único algoritmo que implemente os casos previstos por Aalst

e outros não previstos, em decorrência da combinação. Denominamos esse modelo de

“padrão Junção Combinada”.

Para auxiliar na comparação com os padrões descritos por Aalst, foi decidido

representar aqui também utilizando CPN. Contudo, workflow graphs permitem que

cientistas de outras áreas representem seus fluxos de modo mais flexível [5], sendo mais

apropriados para a implementação.

i1

im

WCP-9 o1

c

c

c

CID

CID

CID


22

Figura 3: junção combinada

O comportamento da junção combinada é determinado pelos parâmetros de entrada:

Quando a entrada for a tupla (m,A,n,b,din,canc), serão executadas m instâncias

da atividade A; n indica o número de atividades que deve ser completado para a

produção da saída em o1; b indica se o padrão deve se comportar de modo

bloqueante; din determina se é possível acrescentar novas instâncias

dinamicamente durante a execução; e canc indica se as demais atividades, após n

terem sido completadas, devem ou não ser canceladas;

Quando a entrada for a tupla ([A1,...,Am],n,b,din,canc), a execução das

atividades A1,...,Am será realizada em paralelo, com n, b, din e canc como

acima.

As tabelas a seguir ilustram possíveis valores de entrada e o padrão ao qual a

combinação corresponde.

Tabela 1: padrões de junção para múltiplas instâncias. Entrada com a tupla (m,A,n,b,din,canc), com m>1

Padrão A n b din canc

WCP-34 + 1<n<=m não não não

WCP-35 + 1<n<=m não não sim

WCP-36 + 1<n<=m não sim não

i1

início

A1

p’1

join

p’2

[]

completo

o1

ativo

contador

pronto

inicia

instância

desabilita

criação de

instância

Permite

novas instâncias

c

m,A,n,b,din,canc

[A1,…,Am],n,b,din,canc x’c

(x=m or x=n)

and

[not(elt(c,pc))]

c

(m-x)’c

c

Initcases()

c

(c,m+1)

(c,m)

c

c

c

[din]

c

(c,m)

(c,m)

c

c

c

c

Amc

c

cc

c

pi

Aic

c

pi1

t1c

not(b) or

[not(elt((c,1),cs))]

pim

tmc

not(b) or

[not(elt((c,m),cs))]

p1

pm

c

c

entradas

utilizadas(c,1)::cs

(c,m)::cs

cs

cs

c

(c,m)

delcid(c,cs)

cs

pc(c,x)

c::pc

(c,x)

c::pc del(c,pc)

Si

Sm

S1

c[canc]

pc

[canc]

c[canc]

pc[canc]

c

[canc]

pc

[canc]

c

c

c


23

Padrão A n b din canc

P1 + 1 não não não

P2 + 1 não não sim

P3 + 1 não sim não

P4 + 1 não sim sim

P5 + 1 sim não não

P6 + 1 sim não sim

P7 + 1 sim sim não

P8 + 1 sim sim sim

P9 + 1<n<=m não sim sim

P10 + 1<n<=m sim não não

P11 + 1<n<=m sim não sim

P12 + 1<n<=m sim sim não

P13 + 1<n<=m sim sim sim

o

Tabela 2: padrões de junção para atividades distintas. Entrada com a tupla ([A1,...Am],n,b,din,canc), com m>1

Padrão n b din canc

WCP-9 1 não não não

WCP-28 1 sim não não

WCP-29 1 não não sim

WCP-30 1<n<=m não não não

WCP-31 1<n<=m sim não não

WCP-32 1<n<=m não não sim

P14 1 sim não sim

P15 1 não sim não

P16 1 sim sim não

P17 1 não sim sim

P18 1 sim sim sim

P19 1<n<=m sim não sim

P20 1<n<=m não sim não

P21 1<n<=m sim sim não

P22 1<n<=m não sim sim


24

Padrão n b din canc

P23 1<n<=m sim sim sim

Vale notar que, dos trinta e dois possíveis casos, vinte e três não foram a priori

mapeados por Aalst [1]. Contudo, cada um possui especificidades que podem ser

empregadas, como nos exemplos a seguir:

P1: discriminador para múltiplas instâncias;

P2: discriminador com cancelamento para múltiplas instâncias;

P3: discriminador dinâmico para múltiplas instâncias;

P4: discriminador dinâmico com cancelamento para múltiplas instâncias;

P5: discriminador com bloqueio para múltiplas instâncias;

P6: discriminador com bloqueio e cancelamento para múltiplas instâncias;

P7: discriminador dinâmico com bloqueio para múltiplas instâncias;

P8: discriminador dinâmico com bloqueio e cancelamento para múltiplas instâncias;

P9: junção parcial dinâmica com cancelamento para múltiplas instâncias;

P10: junção parcial estática com bloqueio para múltiplas instâncias;

P11: junção parcial estática com bloqueio e cancelamento para múltiplas instâncias;

P12: junção parcial dinâmica com bloqueio para múltiplas instâncias;

P13: junção parcial dinâmica com bloqueio e cancelamento para múltiplas instâncias;

P14: discriminador com bloqueio e cancelamento;

P15: discriminador dinâmico;

P16: discriminador dinâmico com bloqueio;

P17: discriminador dinâmico com cancelamento;

P18: discriminador dinâmico com bloqueio e cancelamento;

P19: junção parcial estática com bloqueio e cancelamento;

P20: junção parcial dinâmica;

P21: junção parcial dinâmica com bloqueio;

P22: junção parcial dinâmica com cancelamento;

P23: junção parcial dinâmica com bloqueio e cancelamento.

4. Comunicação entre os Gerenciadores do Workflow e da Grade

No caso de grade, Aalst não aborda o assunto, uma vez que não percorre elementos de

execução. Na implementação aqui sugerida, é preciso descrever em que momento e de

que forma pode haver interação entre o gerenciador de execução de workflow e o

gerenciador de execução da grade, e como se dá a comunicação entre eles.

Em uma solução orientada a serviços, o gerenciador do workflow deve se comunicar

com o gerenciador da grade de modo fracamente acoplado. Para isso, a arquitetura

proposta inclui uma camada intermediária, um middleware denominado Integrador

Workflow-Grade, ou IWG, para realizar tal comunicação.

O papel do IWG é oferecer uma interface a ser utilizada pelo gerenciador do workflow

como alternativa ao modelo de execução paralela deste quando a grade estiver presente.


25

Ao mesmo tempo, o IWG utiliza agente específico para o gerenciador de grade que

estiver sendo utilizado. A Figura 4 ilustra os elementos que compõem a solução.

Figura 4: visão geral dos elementos da solução

O processo de execução, desde a representação de workflows e dos padrões em si até

sua submissão à grade e coleta de resultados, é:

A partir de uma representação gráfica utilizando-se workflow graphs, o cientista

pode definir a aplicação de e-Science utilizando os padrões, implementados e

expostos como extensão ao gerenciador de workflows;

O gerenciador de workflows então utiliza o IWG para decidir se deve utilizar

seu escalonador padrão ou se deve acionar o gerenciador da grade;

O gerenciador da grade, uma vez acionado, distribui a aplicação a ser executada

nos nós, através dos agentes de grade;

Em cada nó, pode haver um sub-workflow a ser executado, e então o processo se

repete localmente, sendo que o IWG novamente utiliza o gerenciador da grade,

que pode estar em outra máquina, para redistribuir o processamento;

Quando o processamento em um nó estiver concluído, o gerenciador da grade

informa o IWG do nó chamador;

O IWG então repassa a conclusão da tarefa ao gerenciador de workflow, e a

execução continua desse modo até que o workflow inicial seja concluído.

4.1. Um Exemplo – Simulações Climáticas com o Projeto GENIE

Existem diversos cenários para ilustrar a utilização de workflows e grades, seja em e-

Science ou na indústria. Os casos que envolvem conjuntos de simulações em múltiplas

Gerenciador da

Grade

Aplicação de

eScience

Gerenciador de

Workflow

IWGAgente de Grade

Gerenciador de

Workflow

IWG

Agente de Grade

Gerenciador de

Workflow

IWG


26

etapas são apropriados para este fim, pois eles apresentam características de workflow e

de grade.

O Projeto GENIE (Grid-ENabled Integrated Earth) [15] utiliza grades para realização de

simulações climáticas a partir da entrada de variações em fatores como, por exemplo,

emissão de dióxido de carbono e redução na camada de ozônio. Tais simulações

utilizam algoritmos de cálculo complexos que podem se aproveitar da presença de

grade. Por exemplo, determinação de qual a influência das emissões de dióxido de

carbono nas correntes marítimas do Oceano Atlântico. É sabido que a concentração de

dióxido de carbono na atmosfera afeta a temperatura do planeta, com impacto no

derretimento de gelo nos pólos. Esses fatores podem causar variação de densidade na

água dos oceanos, que depende diretamente da temperatura e da salinidade.

Outros elementos, como extensão de terra, cobertura de gelo, atmosfera, também são

influenciados por mudanças climáticas, e a realização das simulações pode ser dividida

em regiões para avaliar impactos localizados, como o caso da corrente marítima ou a

evolução das regiões de florestas.

Diversos workflows podem ser definidos, dados os vários cenários de simulação, como

o exemplo acima, e permitem a utilização de padrões e dos recursos da grade. Com isso,

é possível validar a implementação dos padrões para controle de fluxo e a integração

entre os gerenciadores de workflow e da grade.

5. Conclusão

Existem vários trabalhos científicos voltados a soluções de workflows em grades e

sobre a implementação ou não de padrões de controle de fluxo por produtos comerciais

ou de código aberto. Todavia, a relação entre os gerenciadores de workflow e de grade

não foi explorada de modo a permitir que o cientista defina seus fluxos com a utilização

de padrões para paralelização de modo a tornar transparente a existência ou não da

grade.

Foi realizada a implantação do Alchemi, solução para gerenciamento de grade, em

quatrocentas e vinte máquinas nas instalações do SENAC/SP. Sobre esta base será

construída e testada a solução descrita neste texto. O resultado esperado inclui a redução

da complexidade da definição de workflows pelo cientista e a integração dos

gerenciadores de workflow e grade de modo transparente ao cientista.

Referências 1. Russell, Nick, et al. Workflow Control-Flow Patterns - A Revised View. s.l. : BPM Center

Report, 2006. BPM-06-22.

2. Aalst, Wil M. P. van der e Mulyar, Nataliya. Workflow Patterns. [Online] 2005. [Citado em:

19 de 06 de 2007.] http://www.workflowpatterns.com/documentation/index.php.

3. Braghetto, Kelly Rosa, Ferreira, João Eduardo e Pu, Calton. Using Control-Flow Patterns for

Specifying Business Processes in Cooperative Environments. Seoul : ACM, 2007. SAC. 1-59593-

480-4.


27

4. Weske, Mathias. Workflow Management Systems: Formal Foundation, Conceptual Design,

Implementation Aspects. Habilitation Thesis, Universität Münster . 2000.

5. Aalst, Wil M. P. van der, Weske, Mathias e Wirtz, Guido. Advanced Topics in Workflow

Management: Issues, Requirements, and Solutions. 3, Austin : s.n., 2003, Journal of Integrated

Design and Process Science, Vol. 7.

6. Medeiros, Claudia Bauzer, et al. Workflow Management in Geoprocessing Applications.

Washington : ACM, 1998. Proceedings of the 6th ACM international symposium on Advances

in geographic information systems GIS '98 . 1-58113-115-119.

7. Microsoft Corporation. Windows Workflow Foundation. MSDN Library. [Online] 2007.

http://msdn2.microsoft.com/en-us/library/ms735967.aspx.

8. Buyya, Rajkumar e al., et. Alchemi - .NET Grid Computing Framework. Alchemi. [Online] The

University of Melbourne, 2006. [Citado em: 19 de 06 de 2007.] http://www.alchemi.net/.

9. Aalst, Wil M. P. van der, et al. Workflow Patterns. s.l. : Springer Neitherlands, 2003, Vol. 14,

pp. 5-51. ISSN 0926-8782 (Print) 1573-7578 (Online).

10. Pautasso, Cesare e Alonso, Gustavo. Parallel Computing Patterns for Grid Workflows.

Paris : IEEE, 2006. HPDC 2006.

11. Prodan, Radu e Fahringer, Thomas. Dynamic Scheduling of Scientific Workflow

Applications on the Grid: A Case Study. Santa Fe, New Mexico - USA : ACM, 2005. ACM

Symposium on Applied Computing. p. 8.

12. University of Chicago. The Globus Toolkit Homepage. The Globus Toolkit. [Online] 2007.

[Citado em: 06 de 08 de 2007.] http://www.globus.org/toolkit/.

13. The University of Wisconsin Madison. Condor Project Homepage. The University of

Wisconsin Madison. [Online] 2007. [Citado em: 04 de 07 de 2007.]

http://www.cs.wisc.edu/condor/.

14. Goodman, Daniel. Introduction and Evaluation of Martlet, a Scientific Workflow Language

for Abstracted Parallelisation. Banff, Alberta - Canada : ACM, 2007. International World Wide

Web Conference. p. 10.

15. Prize, Andrew R., et al. Collaborative study of GENIEfy Earth System Models using scripted

database workflows in a Grid-enabled PSE. s.l. : National e-Science Centre, 2006. Proceedings

of the UK e-Science All Hands Conference 2006. pp. 574-582. 0-9553988-0-0.

16. Eder, Johann, Gruber, Wolfgang e Pichler, Horst. Transforming Workflow Graphs.


28

Padrões para Controle de Fluxo e sua Execução … padrões, o que se mostra adequado para seus...

Documents

Transcript of Padrões para Controle de Fluxo e sua Execução … padrões, o que se mostra adequado para seus...