Uma arquitetura de baixo acoplamento para execução de padrões de controle de fluxo em grades

Transcrição

1 Uma arquitetura de baixo aoplamento para exeução de padrões de ontrole de fluxo em grades Alexandre Riardo Nardi Tese apresentada ao Instituto de Matemátia e Estatístia da Universidade de São Paulo para obtenção do título de Doutor em Ciênias Programa: Ciênia da Computação Orientador: Prof. Dr. João Eduardo Ferreira São Paulo, maio de 2009

2 Uma arquitetura de baixo aoplamento para exeução de padrões de ontrole de fluxo em grades Este exemplar orresponde à redação final da tese, devidamente orrigida, defendida por Alexandre Riardo Nardi e aprovada pela omissão julgadora. São Paulo, 27 de maio de 2009 Comissão Julgadora: Prof. Dr. João Eduardo Ferreira (orientador) IME/USP Prof. Dr. Philippe Olivier Alexandre Navaux UFRGS Prof. Dr. Dunan Dubugras Aloba Ruiz PUC/RS Prof. Dr. Luiano Antonio Digiampietri EACH/USP Prof. Dr. Franiso Carlos da Roha Reverbel IME/USP ii

3 iii Para Ednilza, Pedro e Natália

4 Agradeimentos Em primeiro lugar, agradeço ao Prof. Dr. João Eduardo Ferreira, meu orientador, pela atenção e metiulosidade om que teeu observações no transorrer deste trabalho mas, aima de tudo, pela ompreensão das difiuldades profissionais que enfrentamos durante o desenvolvimento desta pesquisa. À minha esposa, Ednilza, pelo arinho, inentivo e paiênia, muito obrigado! E agradeço também aos pequenos Pedro e Natália, meus filhos que, apesar da poua idade, permitiram que o papai se dediasse a este projeto. Obrigado ao Prof. Dr. Franiso Carlos da Roha Reverbel, que me aompanha desde os tempos do mestrado e que, juntamente om o Prof. Dr. Roberto Hirata, a quem também agradeço, fez rítias ao trabalho durante a qualifiação, que ertamente ontribuíram para melhorar a qualidade desta tese. Minha gratidão também à equipe de Reife que me ajudou om boa parte da implementação da parte prátia deste trabalho, impresindível para validar a arquitetura aqui proposta: Thiago Seixas, Diogo Burgos, Murilo Pontes (que ajudou muito na integração om o Ourgrid) e espeialmente ao Fabiano Arruda Ferreira das Graças, om quem tive longas disussões madrugadas adentro. Voês foram fundamentais para que este trabalho pudesse se realizar. Aos professores Dr. Philippe Olivier Alexandre Navaux e Dr. Niolas Bruno Maillard da Universidade Federal do Rio Grande do Sul, que ofereeram suas instalações para realização de testes que validassem este trabalho, e ao Dr. Roberto Souto, do Instituto Naional de Pesquisas Espaiais, pelas disussões e pelo empenho em realizar testes om dados reais, o meu muito obrigado! Um agradeimento espeial, que aqui não poderia faltar, vai para a Opus Software e para a Mirosoft Brasil, que proporionaram flexibilidade sufiiente para que eu pudesse ursar o doutorado. E também ao Prof. Dr. Carlos Humes Junior, pelas orientações iniiais, quando ainda estava avaliando o melhor aminho aadêmio a seguir. Por ompartilharem um pouo de seu onheimento omigo, agradeço aos professores do IME, e aos olegas por assistirem às minhas palestras e seminários. Aos meus amigos e familiares, agradeço pelo apoio e interesse em me ouvir falar sobre o urso. Enfim, a todas as pessoas que de alguma forma ontribuíram para a realização deste trabalho, seja por me ouvirem, por lerem o texto em suas versões inompletas ou ainda por se interessarem pelo assunto, meu sinero agradeimento. iv

5 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 apresenta uma arquitetura de baixo aoplamento e extensível, para permitir a exeução de padrões om ou sem a presença de grade, de modo transparente ao ientista. Desreve também o Padrão Junção Combinada, que atende a diversos enários de paralelização omumente enontrados em apliações de e-siene. Com isso, espera-se auxiliar o trabalho do ientista, ofereendo maior flexibilidade na utilização de grades e na representação de enários de paralelização. Palavras-have: workflow, grade, ontrol-flow, padrões, e-siene, workflows ientífios v

6 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 researh area. However, the use of workflow ontrol-flow patterns for exeution in grids remains an opened question. This work presents a loosely oupled and extensible arhiteture, allowing use of patterns with or without grids, transparently to the sientist. It also desribes the Combined Join Pattern, ompliant to parallelization senarios, ommonly found in e-siene appliations. As a result, it is expeted to help the sientist tasks, giving him or her greater flexibility in the grid usage and in representing parallelization senarios. Keywords: workflow, grid, ontrol-flow, pattern, e-siene, sientifi workflows vi

7 Sumário Índie de Figuras... x Índie de Tabelas... xiii Lista de Abreviaturas e Siglas... xiv Capítulo 1 - Introdução Motivação Objetivos Justifiativas Contribuições deste Trabalho Organização do Texto Convenções Tipográfias... 4 Capítulo 2 - Fundamentos Workflow Padrões (Patterns) Padrões de Workflow Redes de Petri Redes de Petri Coloridas Workflow Nets Conlusão Capítulo 3 - Trabalhos Relaionados Soluções de Workflow Existentes Soluções de Grade Existentes Berkeley Open Infrastruture for Network Computing (BOINC) Projeto Globus Ourgrid InteGrade Alhemi Considerações sobre as Soluções de Grade Exeução de Workflows em Grade Abstrat Grid Workflow Language (AGWL) e ASKALON Padrões de Workflow para Grades Condor, Condor-G, DAGMan, Pegasus e GriPhyN VDS vii

8 3.3.4 Grid Proess Exeution Language (GPEL) e CROWN FlowEngine Considerações sobre a Exeução de Workflows em Grades Conlusão Capítulo 4 - Padrões de Workflow Paralelizáveis Padrões de Workflow Relaionados (WCP-2) Divisão Paralela (WCP-3) Sinronização Disriminadores Junções Pariais Padrões para Múltiplas Instânias O Padrão Junção Combinada (PJC) Construção do PJC Conlusão Capítulo 5 - Uma Arquitetura de Baixo Aoplamento Arquitetura Uso de Múltiplas Camadas Apliação de e-siene Gereniador de Workflow Gereniador de Grade Elementos Constituintes do Middleware Conlusão Capítulo 6 - Considerações sobre a Implementação Ambiente de Desenvolvimento Uso de Serviços Web - Interoperabilidade Comuniação om Serviços - Endpoints Hospedagem de Serviços Web Proxies e a Utilização de Endpoints Comuniação entre Camadas Relação entre a Apliação, o Gereniador de Workflow e o Gereniador de Grade Interfae Disponibilizada pelo EGP Interfae entre o EGP e os EEPs Interfaes entre os EEPs e o IPG Interfaes entre o IPG e os EGGs Comuniação entre o EGG e o Gereniador de Grade Transferênia de Arquivos Baixo Aoplamento Extensibilidade e Flexibilidade Integração a um Gereniador de Workflow viii

9 6.7 Conlusão Capítulo 7 - Testes e Resultados Obtidos Apliações para Testes Soma de Dois Números Inteiros Cálulo Aproximado de π Torres de Hanoi Brazilian Regional Atmospheri Modeling System - BRAMS [71] Submissão de Atividades ao EGG para Threads Submissão de Atividades ao EGG para Ourgrid Testes de Funionalidade Testes de Desempenho Desempenho em Função da Duração das Atividades Desempenho em Função do Número de Atividades Desempenho em Função do Número de Arquivos Desempenho em Função do Tamanho dos Arquivos Testes de Independênia de Plataforma Testes de Extensibilidade Testes de Desaoplamento Conlusão Capítulo 8 - Conlusão Prinipais Contribuições Sugestões de Trabalhos Futuros Apêndie A - Diagramas de Classes da Implementação A.1 Interfaes e Classes Utilizadas e Expostas pelo EGP A.2 Interfaes e Classes Utilizadas e Expostas pelos EEPs A.3 Interfaes e Classes Utilizadas e Expostas pelo IPG A.4 Interfaes e Classes Utilizadas e Expostas pelos EGGs Apêndie B - Modelo de Dados para Persistênia do PJC Referênias ix

10 Índie de Figuras Figura 1: diagrama de estados ilustrando as etapas de uma linha de produção 12 Figura 2: representação das atividades de aloação e desaloação de reursos Figura 3: Rede de Petri mostrando o fluxo da fabriação de arros Figura 4: maração M 1, obtida a partir da maração da Figura Figura 5: PT-net om maração M 0, representando a linha de montagem de dois modelos de veíulos Figura 6: maração M 1, diretamente atingível a partir de M Figura 7: maração M 2, diretamente atingível a partir de M Figura 8: CPN equivalente à PT-net da Figura Figura 9: maração equivalente à da Figura Figura 10: arquitetura do Globus Toolkit 4 [32] Figura 11: elementos onstituintes do Ourgrid Toolkit [34] Figura 12: exemplo dos omponentes do InteGrade em federação [37] Figura 13: arquitetura do Alhemi [39] Figura 14: proessamento pelo ASKALON de workflows definidos em AGWL [40] Figura 15: arquitetura do ASKALON [41] Figura 16: representação de grafo dirigido aílio no DAGMan Figura 17: grafo aílio dirigido da Figura 16 om informações de fluxo de dados Figura 18: representação, transformação e exeução de workflows em grades (Adaptado de [51]) Figura 19: arquitetura do CROWN FlowEngine [57] Figura 20: representação do padrão "Disriminador Estruturado" usando CPN [2] Figura 21: onstrução a ser utilizada pelo ientista Figura 22: Padrão Divisão Paralela Figura 23: Padrão Sinronização Figura 24: ombinação do uso dos padrões Divisão Paralela e Sinronização Figura 25: Padrão Disriminador Estruturado e Padrão Divisão Paralela Figura 26: Padrão Disriminador om Bloqueio Figura 27: Padrão Disriminador om Canelamento Figura 28: Padrão Junção Parial Estruturada Figura 29: Padrão Junção Parial om Bloqueio [2] Figura 30: Padrão Junção Parial om Canelamento [2] Figura 31: Padrão Junção Parial Dinâmia para Múltiplas Instânias. Adaptado de [2] Figura 32: representação simplifiada do Padrão Junção Combinada Figura 33: Junção Parial om Bloqueio e Canelamento Figura 34: Padrão Junção Combinada x

11 Figura 35: arquitetura da solução proposta. A área delimitada pela região traejada india os elementos que ompõem o middleware desenvolvido neste trabalho Figura 36: diagrama de seqüênia da requisição de exeução do PJC no Ourgrid Figura 37: relação entre o IPG, o Stub para EGG e a implementação dos EGGs Figura 38: transferênia de arquivos entre os servidores Figura 39: representação de uma máquina de estados simples utilizando workflow graphs om WF Figura 40: representação do PJC em workflow graphs Figura 41: Portal GridSphere para gereniamento de jobs BRAMS Figura 42: exemplo de saída produzida pelo BRAMS Figura 43: apliação para submissão de atividades ao middleware Figura 44: exeução de simulações om BRAMS sem o middleware Figura 45: exeução de simulações om BRAMS e om o middleware Figura 46: desempenho do middleware em função da duração de atividades Ο(n) e Ο(2n) Figura 47: desempenho do middleware em função do número de atividades Figura 48: desempenho do middleware em função do número de arquivos de entrada om uma atividade Figura 49: desempenho do middleware em função do número de arquivos de entrada om dez atividades Figura 50: desempenho do middleware em função do número de arquivos de saída om uma atividade Figura 51: desempenho do middleware em função do número de arquivos de saída om dez atividades Figura 52: desempenho do middleware em função do tamanho dos arquivos. 123 Figura 53: interfae IEgp exposta pelo EGP e lasse EgpServie, que a implementa Figura 54: lasses internas para tratamento do Mapa Padrão-Implementação 131 Figura 55: proxy utilizado pelo EGP para aessar os EEPs Figura 56: interfaes expostas pelo EEP e lasse EepPjServie, que as implementa Figura 57: lasses internas ao EEP para PJC, que realizam persistênia de estado do padrão Figura 58: proxy utilizado pelos EEPs para aessar o IPG Figura 59: lasses para o ontrato de dados utilizado pelo EEP para o PJC Figura 60: interfaes expostas pelo IPG e lasse IpgServie, que as implementa Figura 61: lasses utilizadas pelo IPG para transferênia de arquivos usando SSH Figura 62: lasses internas para tratamento do Mapa Grade-Implementação. 136 Figura 63: proxy utilizado pelo IPG para aessar os EEPs Figura 64: proxy utilizado pelo IPG para aessar os EGGs Figura 65: lasses para o ontrato de dados utilizado pelo IPG xi

12 Figura 66: interfae IEggIpg exposta pelo EGP e lasse EggThreadServie, que a implementa Figura 67: lasse interna do EggThreadServie, para gereniamento das threads de exeução Figura 68: proxy utilizado pelos EGGs para aessar o IPG Figura 69: lasses para o ontrato de dados utilizado pelo EGG de threads (sem grade) Figura 70: modelo de dados para armazenar o estado das exeuções do PJC xii

13 Índie de Tabelas Tabela 1: operações da interfae GridMahine Tabela 2: padrões de junção para múltiplas instânias e para atividades distintas Tabela 3: omparação entre os bindings ofereidos pelos serviços implementados Tabela 4: testes funionais em laboratório Tabela 5: testes de desempenho em função da duração das atividades Tabela 6: testes de desempenho em função do número de atividades Tabela 7: testes de desempenho em função do número de arquivos de entrada om uma atividade Tabela 8: testes de desempenho em função do número de arquivos de entrada om dez atividades Tabela 9: testes de desempenho em função do número de arquivos de saída om uma atividade Tabela 10: testes de desempenho em função do número de arquivos de saída om dez atividades Tabela 11: testes de desempenho em função do tamanho dos arquivos Tabela 12: testes de independênia de plataforma xiii

14 Lista de Abreviaturas e Siglas AGWL Abstrat Grid Workflow Language CPN Coloured Petri-Net EGP Exeutor Genério de Padrões GPEL Grid Proess Exeution Language IPG Integrador Padrão-Grade NPDL Navigation Plan Desription Language PJC Padrão Junção Combinada RPC Remote Proedure Call SGWF - Sistema Gereniador de Workflow SOA Servie-Oriented Arhiteture UCP Unidade Central de Proessamento WASA Workflow-based Arhiteture to support Sientifi Appliations WCF Windows Communiation Foundation WCP Workflow Control-Flow Patterns WDP Workflow Data Patterns WF Windows Workflow Foundation WRP Workflow Resoure Patterns XAML Extensible Appliation Markup Language XML Extensible Markup Language XPDL XML Proess Definition Language xiv

15 Introdução Capítulo 1 Introdução O avanço nas indústrias de hardware e software nos últimos 40 anos possibilitou a utilização da omputação em diversas áreas da iênia, a que se hama e-siene, omo astronomia, químia, genétia e agriultura, entre outras. As apliações desenvolvidas ontribuem para a validação de hipóteses estabeleidas pelos ientistas. Dessa forma, agilizam os resultados e, onseqüentemente, as análises e as pesquisas. Tipiamente, essas apliações ontêm workflows ientífios, om fluxos simples ou omplexos, onstituídos por onjuntos de atividades a serem exeutadas seguindo padrões, dentre os quais os seqüeniais e os paralelos. Pode haver também dependênia, utilização de reursos e tráfego de dados para e entre as atividades. Cada padrão pode ser implementado diretamente pelo ientista. Todavia, omo os padrões apresentam omportamentos que se repetem, podem ser enapsulados e ofereidos ao ientista omo parte de soluções de workflow. Assim, a utilização dos padrões torna-se mais simples. Além disso, permite que o ientista de outras áreas, que não seja a de omputação, possa empregar seu tempo em suas pesquisas, ao invés de oupá-lo na onstrução de infra-estrutura para testar suas teorias ou oneitos. Wil van der Aaslt et al. [1] realizaram estudos voltados à identifiação de padrões de workflow em apliações de e-siene. Nesse trabalho, avaliaram quatorze produtos, omparando-os quanto à disponibilidade de implementação dos padrões. A partir desse trabalho, novos estudos têm sido realizados envolvendo padrões de workflow, omo o de Russell et al. [2], que identifiou outros padrões, diversos sendo espeializações dos desritos iniialmente por Aalst. 1

16 Introdução Embora os padrões simplifiquem o uso de workflows pelos ientistas, existem ainda alguns desafios. O primeiro deles é a representação de workflows, que pode ser realizada de diversas formas, omo: redes de Petri oloridas (CPN Coloured Petri-Nets) [3]; expressões de álgebra de proessos omo NPDL [4]; linguagens baseadas em omandos em texto omo XPDL [5]; ou workflow graphs [6]. Várias abordagens são analisadas em [7], que desreve vantagens e desvantagens de ada uma. Do ponto de vista da omputação, para ada solução de workflow e para ada representação, os padrões devem ser novamente implementados, o que oferee baixo índie de reaproveitamento de ódigo. O tempo gasto no proessamento de análises e álulos é outro ponto relevante, prinipalmente se onsiderado para exeução de atividades paralelamente. Para atender a essa questão, tem-se lançado mão do uso de software para omputação em grades, lusters ou equipamentos multiproessados. Tal software, entretanto, aresenta novo fator de omplexidade a ser onsiderado, o que onera o tempo de pesquisas e análises e exige onheimento espeializado. Esta pesquisa, apoiada pela Mirosoft Brasil e Mirosoft Researh, propõe a arquitetura de um middleware para a utilização dos padrões de workflow para apliações de e-siene. Essas apliações podem ou não ter atividades sendo exeutadas paralelamente em grades, o que é aqui apresentado de modo transparente ao ientista. 1.1 Motivação No ontexto de apliações de e-siene, existem duas neessidades fundamentais no dia-a-dia de ientistas, que não são totalmente obertas pelas soluções analisadas até o momento [2]: 1) a representação de padrões de workflows de modo simples e integrado ao gereniador de workflow já utilizado; 2) abstração da utilização de software de grade. Para o ientista, a utilização da grade é um reurso para aumentar o desempenho do proessamento, reduzindo o tempo total. Assim, tal tarefa, embora omplexa, é meramente ténia: o ientista deveria ser espeialista em sua área e forneer o algoritmo espeífio de sua pesquisa, ao invés de utilizar parte de seu tempo pensando em exeução em grade. 1.2 Objetivos Esta pesquisa pretende ofereer reursos para obrir as duas neessidades aima, ou seja, a integração às apliações existentes do uso de padrões de workflow para paralelização e a transparênia da presença de grade para o 2

17 Introdução ientista. Desse modo, a representação de workflows deve ser realizada sem que o ientista preise onheer álgebra de proessos, redes de Petri ou linguagens de workflow. A apresentação dos padrões de workflow deve ser feita de tal modo que estes possam ser utilizados pelo ientista para representar o problema de sua área de pesquisa de forma mais intuitiva, e pretende-se abstrair a interação om software de grade, fazendo om que sua presença seja informada omo uma onfiguração do sistema. 1.3 Justifiativas 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. Esse é o aso de padrões de paralelização omo os desritos por Russell et al. em [2]. O uso de grades para exeução de tarefas paralelizáveis, por sua vez, reduz o tempo gasto no proessamento de análises e álulos, ofereendo ao ientista maior agilidade em suas pesquisas e estudos. Russell et al [2] não avaliam nem propõem a exeução dos padrões em grades. Ao possibilitar o uso dos padrões de modo integrado, porém om baixo aoplamento, às grades, esta pesquisa oferee uma abordagem mais ompleta para o ientista que desenvolve pesquisas em e-siene. Embora o prinipal interesse deste trabalho sejam apliações de e-siene, workflows omeriais também podem se benefiiar dos oneitos aqui apresentados e disutidos. 1.4 Contribuições deste Trabalho Como resultado desta pesquisa, espera-se ofereer uma arquitetura de baixo aoplamento para exeução de padrões de ontrole de fluxo, potenialmente om a utilização de grades. Tal arquitetura resulta nos seguintes benefíios: Failita o uso de padrões de workflow por ientistas que não tenham informátia omo sua área de pesquisa; Permite a exeução de padrões de paralelização em lusters, grades ou equipamentos multi-proessados; Oferee infra-estrutura extensível para ser omplementada om a implementação de outros padrões além dos aqui apresentados; 3

18 Introdução Permite que outros grupos de pesquisa utilizem outras soluções de grades, também por meio da extensibilidade da solução aqui proposta. 1.5 Organização do Texto Os prinipais oneitos utilizados neste trabalho são brevemente revistos no Capítulo 2. O Capítulo 3 apresenta diversos trabalhos aadêmios e produtos omeriais relaionados a esta pesquisa. No Capítulo 4 são desritos os padrões de ontrole de fluxo definidos por Russell et al em [2], que podem se benefiiar de exeução paralela. É então feita a apresentação do Padrão Junção Combinada, uja implementação unifia diversos desses padrões. O Capítulo 5 apresenta a arquitetura em amadas que permite o desaoplamento entre a apliação de e-siene e o gereniador de grade. Essa arquitetura foi implementada em um middleware, om interfaes e serviços web desritos no Capítulo 6. Para validar os benefíios propostos pelo middleware e para analisar o impato no desempenho resultante de sua utilização, o Capítulo 7 apresenta os resultados de um onjunto de testes e os enários em que foram realizados. Por fim o Capítulo 8 enerra este texto apresentando as onlusões e prinipais ontribuições de nossa proposta. Complementam este trabalho o Apêndie A, que desreve os modelos de lasses dos serviços que integram o middleware, e o Apêndie B, que apresenta o modelo de dados utilizado pela implementação do Padrão Junção Combinada. 1.6 Convenções Tipográfias Neste texto foram utilizadas as seguintes onvenções tipográfias: Termos em inglês 1 são grafados em itálio; Trehos de ódigo utilizam a fonte Courier New, tamanho 9; No orpo do texto, referênias a termos utilizados em ódigo fonte ou palavras reservadas apareem om a fonte Courier New, tamanho Alguns termos empregados no texto foram propositadamente deixados em inglês. 4

19 Fundamentos Capítulo 2 Fundamentos Os trabalhos ientífios envolvendo workflows e padrões utilizam termos e oneitos espeífios, neessários para manter a onsistênia entre os grupos de pesquisa sobre esses temas. Neste apítulo, apresentamos a terminologia que será utilizada nos demais apítulos do texto. A Seção 2.1 expliita o que são workflows, e desreve as diferenças entre workflows ientífios e workflows de negóio. Na Seção 2.2 são apresentados a importânia e os ganhos om o uso de padrões, entrando em maior detalhe quanto aos padrões de workflow. Na Seção 2.3 é apresentada uma visão informal sobre Redes de Petri, amplamente utilizadas no Capítulo 4 na representação de padrões de workflow usados em paralelização de tarefas, e para desrever omo tais padrões foram ombinados, onstituindo o Padrão Junção Combinada. 2.1 Workflow A neessidade por sistemas apazes de isolar o fluxo de tarefas na automatização de proessos de esritório foi identifiada nos anos Até então, tanto o fluxo quanto as demais atividades eram ontidas num mesmo sistema ou apliação. Com isso, havia difiuldades na manutenção dos fluxos, exigindo o desenvolvimento de nova versão dos sistemas a ada mudança de fluxo, o que era omum no enário em questão. Ao separar o fluxo do restante do sistema, ganhou-se flexibilidade e agilidade quando modifiações eram neessárias. Além disso, aos profissionais espeialistas em áreas de negóios, puderam ser atribuídas as 5

20 Fundamentos responsabilidades por essas tarefas, sem que fossem neessários onheimentos de programação. O tema ganhou a atenção de diversas empresas, que onstituíram a Workflow Management Coallition (WfMC) [8] em Essa organização tem onduzido estudos e publiado diversos padrões sobre workflows e sistemas para gereniá-los. Segundo a WfMC, um workflow pode ser definido omo A automação de um proesso de negóio, no todo ou em partes, no qual doumentos, informações ou tarefas são passados de um partiipante a outro para ser proessado, de aordo om um onjunto de regras proedurais. Essa abordagem pode ser entendida tanto no âmbito de um sistema quanto no ontexto da onvivênia entre diversos sistemas que devam ser utilizados para perfazer as tarefas de um dado proesso de negóio. Um exemplo deste último aso é a integração entre sistemas de gereniamento de estoque, vendas, ompras e finaneiro, todos desempenhando sua função dentro do proesso de vendas de produtos em uma empresa no segmento varejista. Vale notar que essa utilização estende-se a interações B2B (business-to-business), em que empresas ompartilham informações e serviços, omo oorre no Sistema de Pagamentos Brasileiro (SPB) [9]. Nesse aso, as instituições finaneiras preisam troar mensagens para que operações entre elas possam ser realizadas de aordo om as diretrizes impostas pelo Bano Central do Brasil. Além das apliações para sistemas de negóios, workflows também fazem parte do enário ientífio, que aresenta algumas omplexidades, omo: Fluxos om grande número de etapas, omum no proessamento de tarefas omo oorre em bioinformátia, químia, astronomia, agronomia, entre outras; Volatilidade dos fluxos, que devem poder ser alterados freqüentemente, na avaliação de hipóteses ientífias; Neessidade de parametrização para grande número de tarefas: por exemplo, em busas por padrões no genoma; Monitoramento e aompanhamento da exeução, que deve levar em onta a dinamiidade dos fluxos; Exeução em ambientes ujos reursos sejam desonheidos a priori. Desse modo, existem duas ategorias de workflows bem definidas: workflows de negóio e workflows ientífios. Cada uma possui suas partiularidades, mas vale notar que uma solução que atenda a enários ientífios geralmente também se aplia a enários de negóio. Uma exeção fia por onta da heterogeneidade de ambiente e tenologias, omum prinipalmente no ontexto de proessos de negóios entre empresas (B2B). Em [10], Barga e Gannon apresentam essas araterístias de workflows de negóio e ientífios, no âmbito também de outros aspetos, omo a existênia de transações de longa duração, mais omuns em enários ientífios. Os autores 6

21 Fundamentos ainda ontextualizam os workflows de negóio omo tratando do forneimento de serviços para lientes, um uso distinto da realização de experimentos, omo é o aso dos workflows ientífios. No que diz respeito à representação de workflows, utilizaremos neste texto uma variação das Redes de Petri, denominada Workflow Net. Ambas são desritas e definidas mais à frente neste apítulo. 2.2 Padrões (Patterns) A busa por maiores oportunidades de reuso tem sido uma onstante em várias áreas do onheimento. A Revolução Industrial pode ser onsiderada um maro na padronização de proessos de produção, om a automatização de tarefas repetitivas. Até então, os proessos eram manuais, resultando em longo tempo para fabriação de produtos, inexistênia de padronização das peças produzidas, altos ustos de produção e do produto final. A adoção de proedimentos industriais automatizados e sua evolução soluionaram esses problemas, mostrando a importânia da padronização. Nesse sentido, um padrão (pattern) representa uma estratégia para soluionar problemas reorrentes. Cada padrão enapsula onheimento de modo independente de implementação. O mesmo se aplia à área da omputação. Um exemplo é a onepção de subrotinas parametrizáveis, utilizadas onstantemente em diversos paradigmas de programação, omo a estruturada ou a orientada a objetos. Existem exemplos também em níveis mais elevados de abstração, omo a onepção e o reonheimento de padrões arquiteturais, usados fundamentalmente para maior ontrole e previsibilidade de desempenho, segurança, esalabilidade, disponibilidade, entre outros requisitos que são onsiderados prinipalmente para sistemas rítios. O uso de padrões aumenta o índie de reutilização de ódigo ao representar enários, ondições e ações espeífias em diversos asos que se repetem. Com isso, espera-se ser possível o desenvolvimento de ódigo mais robusto e de mais alta qualidade. Embora padrões tenham sido apresentados omo um oneito arquitetural em 1977 por Christopher Alexander et al [11], sua popularização veio em 1994, quando Gamma et al [12] ompilaram um onjunto de vinte e três padrões para uso no desenvolvimento de sistemas. Esse trabalho é tido omo leitura obrigatória sobre reutilização de software, no qual os padrões são propostos e exemplifiados em três ategorias: Padrões para riação, usados quando da instaniação de objetos. Um exemplo desta ategoria é o padrão Singleton, que se aplia quando for neessário riar uma instânia únia de um objeto; 7

22 Fundamentos Padrões estruturais, que tratam da omposição de lasses e objetos, omo é o aso do padrão Bridge, que desaopla a abstração da implementação de uma lasse, portanto permitindo que ambas possam evoluir de modo independente; Padrões omportamentais, que tratam da omuniação entre objetos. Por exemplo, o padrão Iterator permite que se navegue pelos elementos de um objeto sem expor sua representação interna. Em [13], Martin Fowler apresenta um onjunto de inqüenta e um padrões arquiteturais, frequentemente presentes em apliações empresariais, divididos em dez ategorias: Padrões para Lógia de Domínio, que desrevem modelos de apliações, levando em onta um balaneamento entre o proesso de desenvolvimento e a produtividade. Um exemplo é o padrão de desenvolvimento Domain Model, que se aplia a proessos mais sofistiados e omplexos. O padrão Transation Sript, por sua vez, aplia-se a desenvolvimento de sistemas mais simples, que não demandem grandes formalismos em sua onepção, omo sistemas ou apliações periférias e auxiliares; Padrões de Arquitetura para Fontes de Dados: referem-se a usos omuns de onjuntos de dados, omo linhas, no padrão Row Data Gateway, ou tabelas, omo no padrão Table Data Gateway; Padrões Objeto-Relaionais: são três ategorias om padrões para representar objetos em entidades relaionais, omo nos padrões Foreign Key Mapping e Repository; Padrões para Apresentação Web, que estão entre os mais populares e tratam da representação e uso de elementos de interfae om o usuário. Um exemplo é o padrão Model View Controller, que separa os modelos a serem apresentados onforme indiado dinamiamente pelo ontrolador. Esse padrão é partiularmente útil para apliações multi-plataforma e/ou multi-dispositivo de apresentação; Padrões para Distribuição: tratam do envio de dados entre amadas da apliação, omo o padrão Data Transfer Objet, que foi utilizado na implementação da arquitetura proposta neste trabalho; Padrões de Conorrênia para Operações Offline, omo é o aso do padrão Optimisti Offline Lok, usado para garantir onorrênia otimista aos reursos envolvidos na operação offline; Padrões para Sessão, usados no gereniamento de estado de objetos e omponentes, omo no padrão Client Session State; Padrões Base, omo Mapper e Gateway. Esses dois exemplos de usos de padrões e o suesso em sua adoção e popularidade ilustram a importânia do tema. A seguir serão apresentadas 8

23 Fundamentos algumas onsiderações sobre a reutilização de elementos omumente vistos em representações de workflows Padrões de Workflow Em 1999, Wil van der Aalst e Arthur ter Hofstede se uniram em torno de uma iniiativa para identifiar, doumentar e avaliar padrões em fluxos: a Workflow Patterns Initiative [14]. O objetivo om esse esforço foi auxiliar o desenvolvimento de tenologias voltadas para proessos, de modo a estabeleer ritérios para o desenvolvimento e omparação entre elas. Do mesmo modo omo em outras áreas, as diversas atividades dentro de um workflow podem ser vistas omo padrões, refletindo omportamentos omuns em enários de proessos de negóios ou apliações de e-siene. A fim de atender a tais enários, Aalst et al [1] propuseram quatro ategorias de padrões para workflow, relativas à natureza das operações a serem realizadas, que foram denominadas perspetivas pelos autores: Padrões para Controle de Fluxo (Workflow Control-Flow Patterns WCP): um onjunto proposto em [1] ontendo vinte padrões que apresentam enários omuns na seqüênia de exeução dos passos de um workflow. No mesmo trabalho, Aalst et al fizeram um levantamento omparando diversos produtos gereniadores de workflow quanto à disponibilidade ou não de ada padrão. Essa publiação serviu omo base para avaliação de sistemas gereniadores de workflow (SGWF), sejam omeriais ou para fins ientífios. Posteriormente, Russell, Aalst et al [2] identifiaram diversas espeializações de padrões, e as separaram em novos padrões, ompletando um total de quarenta e três, lassifiados em oito sub-ategorias: o Padrões Básios: identifiam e desrevem as operações triviais de um fluxo, omo seqüênia, divisão paralela, sinronização e esolha exlusiva; o Padrões Avançados para Ramifiação e Sinronização: detalham diversas possibilidades para exeução de ramifiações omo disriminadores e junções pariais, inluindo tratamento de atividades pendentes. Por exemplo, no Padrão Junção Parial om Canelamento é estudado o aso de exeução paralela de um onjunto de atividades; a saída deve ser produzida assim que um número determinado de atividades tiver sido onluído, sendo que as demais reebem sinalização para que sejam aneladas. Pela natureza paralela da exeução de tais padrões, apropriada para exeução em grades, esses padrões foram esolhidos para o desenvolvimento deste trabalho; 9

24 Fundamentos o Padrões para Múltiplas Instânias: são um aso espeífio de padrões para ramifiação e sinronização. Aqui, todas as atividades são instânias de uma mesma atividade. Por exemplo, a exeução de diversas busas genômias que possam ser realizadas paralelamente. O algoritmo de busa é o mesmo, havendo variação apenas nos parâmetros de entrada; o Padrões Baseados em Estado: quando a relação entre atividades a serem exeutadas dependerem de estado, o ontrole do fluxo deve prever situações de onorrênia e ordem de exeução. Isso oorre, por exemplo, quando diversas atividades puderem ser exeutadas em seqüênia, porém em qualquer ordem. Outros usos são a mara de um ponto na exeução do fluxo (milestone) ou a esolha postergada (deferred hoie), em que a esolha depende do estado de uma variável do ambiente de exeução; o Padrões para Canelamento e Conlusão Forçada: alguns padrões avançados para ramifiação e sinronização tratam do anelamento de atividades no enário em que um onjunto de atividades tenha sido onluído, permitindo o prosseguimento do fluxo, e as atividades restantes devam ser aneladas. Aqui, são tratados padrões de anelamento isoladamente, partiularmente úteis em situações de tratamento de exeções. O Padrão de Conlusão Forçada permite que, a partir de informações externas, as atividades pendentes sejam onluídas. Por exemplo, diversos testes om amostras devem ser feitos paralelamente. Após erto período, o usuário soliita ao sistema que anele os testes que não foram onluídos, forçando o término da exeução paralela; o Padrões para Iteração: tratam ilos e laços, inluindo reursão; o Padrões para Terminação: para os asos em que é neessário saber da onlusão da exeução do fluxo, seja implíita ou explíita. No primeiro aso, o sistema infere o término da exeução; já no segundo, o usuário expliitamente informa o término; o Padrões para Gatilhos: para os asos em que um sinal externo identifia o prosseguimento ou não do fluxo. Há dois padrões: transiente, em que a atividade deve estar pronta para exeução no momento do disparo do gatilho, sob o riso do sinal ser perdido; ou persistente, que espera até que a atividade esteja pronta para então onsumir o sinal do gatilho; 10

25 Fundamentos Padrões para Reursos (Workflow Resoure Patterns WRP): segundo [15], reursos são entidades apazes de realizar algum trabalho. Podem ser lassifiados omo humanos e não-humanos, em função da dependênia de pessoas. Por exemplo, um supervisor que aprova uma tarefa é um Reurso Humano, enquanto threads de exeução são Reursos Não-Humanos. Exemplos de Padrões de Reursos são a autorização e a separação de tarefas; Padrões para Dados (Workflow Data Patterns WDP): se propõem a desrever de que modo dados podem ser representados e utilizados em workflows. Russell et al [16] desrevem 39 padrões, divididos em quatro grupos, ilustrados omo segue: o Visibilidade de Dados: dados aessíveis pelo workflow apenas no ontexto de uma tarefa espeífia loais ou globais, por exemplo; o Interação de Dados: dados fluindo do ambiente para um aso do workflow. Um aso pode ser entendido omo uma instânia do workflow; o Transferênia de Dados: entrada, saída, passados por valor ou por referênia, por exemplo; o Roteamento Baseado em Dados: a partir de um determinado valor, uma pré-ondição de uma tarefa onduz o fluxo para erta atividade. Padrões para Manipulação de Exeções (Exeption Handling Patterns). Russell et al [17] apresentam um arabouço de lassifiação para exeções onsiderando três elementos que, ombinados, geram 135 possibilidades de omportamentos: o Como o item que gerou a exeção será manipulado: são quinze possibilidades aventadas omo, por exemplo, seguir em frente usando o mesmo reurso aloado, falhar ou ofereer esse item para outro reurso; o Como outros itens no mesmo aso serão manipulados: Russell et al vislumbraram três possibilidades ontinuar o aso orrente, remover o aso orrente e remover todos os asos; o Qual ação de reuperação deve ser empregada, dentre três possíveis: nada, desfazer ou ompensar. Este trabalho aborda os Padrões para Controle de Fluxo (Workflow Control- Flow Patterns WCP). Os padrões que foram seleionados omo parte do esopo deste estudo são apresentados na seção

26 Fundamentos 2.3 Redes de Petri São modelos gráfios para representação e estudo de proessamento onorrente. Neste trabalho, as Redes de Petri são utilizadas omo uma ferramenta para apresentação e ilustração de workflows e padrões para ontrole de fluxo. Por isso, optou-se aqui em se fazer uma introdução informal sobre o assunto, e então apresentar definições formais para as Redes de Petri, que podem ser omplementadas em [18], onde são definidas várias propriedades e araterístias dessas redes, mas que não são utilizadas neste texto. Existem diagramas para representação de fluxos baseados em estados ou então em atividades. As Redes de Petri ombinam esses dois tipos de diagramas, obtendo ao mesmo tempo as mudanças de estado e as atividades que fazem as transições de um estado a outro. A seqüênia de figuras abaixo ilustra um diagrama de estados e um diagrama de atividades, ambos baseados no mesmo exemplo: a representação de uma linha de produção de automóveis, na qual há quatro atividades a serem realizadas e três tipos de profissionais distintos. Essas atividades podem ser a montagem de pára-brisa, instalação de motores para operação dos vidros e ligação do sistema elétrio ao meânio. Os profissionais poderiam ser ténios em vidraçaria, elétria ou meânia. Os estados demaram o ponto de um arro na linha de produção. A Figura 1 2 apresenta um estágio iniial da linha de montagem de um arro do Modelo a e três estados adiionais, mostrando a utilização dos reursos em ada estado. Por exemplo, a Etapa 1 pode ser a instalação de vidros nas portas, e o reurso r 1 pode ser um ténio em vidraçaria. O estado iniial é indiado pela seta vazada, que também informa o número de unidades neste exemplo arros a serem proessadas. Modelo a Iníio Etapa 1 um r1 Etapa 2 um r2 Etapa 3 dois r2 um r3 x unidades Reursos: um r1 três r2 um r3 Figura 1: diagrama de estados ilustrando as etapas de uma linha de produção 2 As figuras desta seção foram baseadas nas figuras de Kurt Jensen em [18] 12

27 Fundamentos A Figura 2, por sua vez, representa o mesmo proesso de fabriação de arros, porém sob a ótia da aloação e desaloação de reursos. Modelo a Aloar um r1 Aloar um r2 Desaloar um r1 Aloar um r2 um r3 Desaloar tudo x unidades Reursos: um r1 três r2 um r3 Figura 2: representação das atividades de aloação e desaloação de reursos Para a representação do proesso de fabriação de arros, ambos os diagramas desempenham seus papéis, e são omplementares. Uma Rede de Petri, que ombina as informações desses diagramas, é um grafo dirigido G = (V, A), no qual V é um onjunto de vérties e A é um onjunto de arestas. O onjunto V possui dois tipos de vérties (também denominados nós): L, um onjunto ontendo os lugares ou estados da rede; e T, o onjunto de transições ou ainda atividades, ações ou tarefas 3. DEFINIÇÃO 2.1 (Rede de Petri): uma Rede de Petri é uma tripla (L, T, A), em que: L é um onjunto finito de lugares; T é um onjunto finito de transições, L T ; A LT T L é um onjunto de arestas. A Figura 3 é uma Rede de Petri que mostra os lugares omo írulos (por vezes são mostrados omo ovais) e as transições omo retângulos. Existem sete lugares, sendo quatro representando os estágios de utilização de reursos e três representando a quantidade de reursos disponíveis. Uma Rede de Petri om esses elementos é hamada PT-net (sendo que P representa lugares plaes e T representa transições transitions). Na próxima seção será apresentada uma Rede de Petri om araterístias adiionais, a Rede de Petri Colorida, ou CPN Coloured Petri Net. 3 Os termos atividades, ações e tarefas serão utilizados omo sinônimos no restante deste texto 13

28 Fundamentos Modelo a E1a E2a E3a E4a T1a T2a T3a T4a r1 r2 r3 Figura 3: Rede de Petri mostrando o fluxo da fabriação de arros 2 As bolinhas no interior dos lugares são hamadas maras. Uma distribuição das maras pelos lugares é denominada maração. Na Figura 3, as duas maras em E 1a indiam que há dois arros a serem fabriados, e as maras nos reursos r 1, r 2 e r 3 indiam o número de ada tipo de reurso. As setas dirigidas nas PT-nets são hamadas arestas ou aros. Elas indiam o fluxo de um nó a outro. Cada elemento da rede pode ainda ser lassifiado omo de entrada ou saída de aordo om as setas. Por exemplo, a transição T 1a possui dois aros de entrada onetando-a om os lugares de entrada E 1a e r 1. Do mesmo modo, T 1a possui um aro de saída que a oneta om o lugar de saída E 2a. Usa-se a notação l para representar o onjunto de transições de entrada do lugar l. De modo análogo, l denota o onjunto de transições de saída do lugar l, t e t sendo os onjuntos de lugares de entrada e saída, respetivamente, da transição t. Em uma PT-net, uma transição é dita habilitada quando todos os seus aros de entrada vierem de lugares om o número de maras maior ou igual ao número apontado no aro. Por onvenção, esse número pode ser omitido quando for igual a um. As transições habilitadas em uma determinada maração são indiadas por seu ontorno em negrito. Na Figura 3, apenas T 1a está habilitada. Os elementos até aqui desritos ompõem a representação sintátia das PT-nets. A semântia, ou seja, o omportamento das PT-nets, é desrita a seguir. Uma PT-net pode ser interpretada omo um jogo de tabuleiro em que uma maração iniial india o iníio do jogo, e as peças são as maras. A regra para movimentação das peças é: a ada jogada, maras são removidas dos lugares de entrada de uma ou mais transições habilitadas; então tais transições têm suas atividades realizadas e maras são inseridas nos lugares de saída de aordo om o que a transição indiar. Diz-se que uma transição oorre quando estiver habilitada e tanto a retirada de maras dos lugares de entrada, a realização de atividades da transição e a produção de maras nos lugares de saída aonteerem. Desse modo, sendo a maração da Figura 3 hamada M 0, a oorrênia da transição T 1a produz a maração M 1, apresentada na Figura 4: foram removidas 14

29 Fundamentos maras de E 1a e r 1, T 1a teve sua atividade exeutada que poderia ser a oloação dos vidros nas portas do veíulo, neste exemplo e então foi produzida uma mara em E a2. Neste ponto, a transição T 2a passa a estar habilitada. Modelo a E1a E2a E3a E4a T1a T2a T3a T4a r1 r2 r3 Figura 4: maração M 1, obtida a partir da maração da Figura 3 2 O exemplo até aqui apresentado mostra uma únia transição habilitada para ada maração. No entanto, podem existir múltiplas transições habilitadas em uma PT-net, que podem ou não oorrer. A Figura 5 apresenta uma PT-net para a linha de montagem de dois modelos de veíulos, que ompartilham o mesmo onjunto de reursos. Esta maração, hamada aqui de M 0, possui duas transições habilitadas: T 1a e T 1b. Modelo a E1a E2a E3a E4a T1a T2a T3a T4a 2 r1 r2 r3 2 E1b E2b E3b E4b E5b T1b T2b T3b T4b T5b Modelo b Figura 5: PT-net om maração M 0, representando a linha de montagem de dois modelos de veíulos Diz-se que uma maração M 1 é diretamente atingível a partir de M 0 quando puder ser obtida om a oorrênia de uma ou mais transições habilitadas de M 0. Desse modo, as marações M 1 e M 2 mostradas na Figura 6 e na Figura 7, respetivamente, são diretamente atingíveis a partir de M 0. 15

30 Fundamentos Modelo a E1a E2a E3a E4a T1a T2a T3a T4a 2 r1 r2 r3 2 E1b E2b E3b E4b E5b T1b T2b T3b T4b T5b Modelo b Figura 6: maração M 1, diretamente atingível a partir de M 0 Modelo a E1a E2a E3a E4a T1a T2a T3a T4a 2 r1 r2 r3 2 E1b E2b E3b E4b E5b T1b T2b T3b T4b T5b Modelo b Figura 7: maração M 2, diretamente atingível a partir de M 0 As transições T 1a e T 2b, em M 2, embora estejam habilitadas, não podem oorrer simultaneamente, uma vez que não há maras sufiientes em r 1. Todavia, as transições T 1a e T 1b podem oorrer em paralelo, dizendo-se que estão onorrentemente habilitadas. Ainda, vale notar que em M 2 há maras sufiientes para que T 1b oorra duas vezes. Nesse aso, diz-se que essa transição pode oorrer onorrentemente om ela mesma. Este texto utiliza ainda o oneito de passo: um multi-onjunto de transições onorrentemente habilitadas a partir de uma maração. Multionjuntos são onjuntos nos quais um elemento pode apareer mais de uma vez. Por exemplo, o passo (step) S 1 = {T 1a } está habilitado em M 2. Do mesmo modo, os seguintes passos estão habilitados em M 2 : S 2 = {T 1b } S 3 = {T 2b } S 4 = {T 1a, T 1b } 16

31 Fundamentos S 5 = {T 1b, T 1b }, indiando duas oorrênias de T 1b S 6 = {T 1b, T 2b } S 7 = {T 1b, T 1b, T 2b } Vale notar ainda que as atividades das transições onorrentemente habilitadas são independentes, de modo que a ordem em que oorrerem em um determinado passo é irrelevante. Outra representação para passos é o uso de oefiientes indiando o número de vezes em que uma transição está habilitada: S 1 = T 1a S 2 = T 1b S 3 = T 2b S 4 = T 1a + T 1b S 5 = 2 T 1b S 6 = T 1b + T 2b S 7 = 2 T 1b + T 2b Redes de Petri Coloridas As PT-nets são intuitivas e de fáil ompreensão para sistemas pequenos, omo o ilustrado na Figura 5. Nesse exemplo, a PT-net desreve o proesso de fabriação de dois modelos de veíulos, usando três tipos de reursos. Extrapolando este exemplo para a produção de trinta modelos usando quinze tipos de reursos, hega-se a uma rede muito menos legível, dado o número de repetições de atividades e estados nesse aso, enquanto há duas atividades T 1 (T 1a e T 1b ) na rede da Figura 5, para o novo enário haveria até trinta atividades T 1, sendo uma para ada modelo. Desse modo, pode-se onluir que as PT-nets tornam-se ilegíveis para sistemas grandes ou omplexos. Dessa neessidade de simplifiação da representação da rede, surgiram as Redes de Petri Coloridas, ou CPNs. Uma CPN possui alguns elementos adiionais que ofereem maior flexibilidade quando da representação de proessos e workflows. O elemento iniialmente aresido foi a distinção das maras através de ores. Uma or permite que um dado seja arregado om uma mara. Esse dado pode ser simples omo um número inteiro, ou omplexo omo tuplas om elementos de tipos distintos. O tipo de dado que uma mara pode assumir é denominado onjunto de ores. O uso de ores nas CPNs é análogo ao dos tipos de dados em linguagens de programação. Do mesmo modo, os onjuntos de ores identifiam o domínio de valores que as maras podem assumir. 17

32 Fundamentos A CPN apresentada na Figura 8 é análoga à PT-net da Figura 5. Houve redução no número de estados e transições, e um arésimo de informações nos aros. Os pontos que ilustram araterístias espeífias das CPNs são: O retângulo no anto superior esquerdo india as diferentes maras (identifiadas por ores) e seus tipos: o Modelo: é uma enumeração omposta pelos elementos a e b, e indiam que modelo de automóvel está sendo produzido; o Qtdd: india a quantidade de veíulos a ser produzido; o P: é um par que representa o modelo sendo produzido e o número de veíulos daquele modelo que já foi produzido; o R: é a quantidade de reursos disponíveis; o x e i : variáveis usadas durante a operação da CPN para passar o modelo e que unidade estão sendo produzidos. A maração orrente é indiada pelas expressões junto aos lugares, ontendo o número de maras de ada tipo, omo 2 (a,0) + 3 (b,0) para o lugar E 1 e 3 r para r 2, por exemplo; Quando houver uma únia mara de um determinado tipo em um lugar ou aro, o algarismo 1 pode ser omitido, omo o ilustrado no aro que vai de r 2 a T 3 ; Expressões ondiionais nos aros, indiando o ontexto a ser satisfeito; Restrições nas transições, omo [x=b] em T 5, que devem ser satisfeitas para que as atividades de uma transição sejam exeutadas. Aqui, T 5 será exeutada se e somente se for aionada pela linha de produção do modelo b. Por exemplo, é o que aontee no seguinte enário: o modelo a possui vidros manuais, o modelo b possui vidros elétrios, e T 5 é a montagem do equipamento de vidros elétrios. Logo, T 5 só deve ser exeutada para o modelo b. 18

33 Fundamentos olor Modelo = {a,b}; olor Qtdd = int; olor P = Modelo * Qtdd; olor R = {r}; var x: Modelo; var i: Qtdd; 1'r 3'r R r1 R r2 R r3 If x=b then 1'r If x=b then 1'r else empty else empty If x=b then 1'r else empty If x=a then 1'r else empty r 2'r If x=b then 1'r else empty 1'r 2'(a,0) + 3'(b,0) If x=a then 1'r else empty P If x=a then 1'r else empty P E1 T1 E2 T2 E3 T3 E4 T4 E5 (x,i) (x,i) (x,i) (x,i) (x,i) (x,i) (x,i) (x,i) (x,i) P If x=a then 1'(a,i+1) else empty If x=a then 1'r else empty P If x=a then 1'r else empty P If x=b then 1'r else empty T5 [x=b] If x=b then 1'(b,i+1) else empty Figura 8: CPN equivalente à PT-net da Figura 5 Do mesmo modo que para as PT-nets, a ada passo, uma ou mais transições são exeutadas e maras são movimentadas. A Figura 9 apresenta maração equivalente à da Figura 6, M 1. olor Modelo = {a,b}; olor Qtdd = int; olor P = Modelo * Qtdd; olor R = {r}; var x: Modelo; var i: Qtdd; 3'r R r1 R r2 R r3 If x=b then 1'r If x=b then 1'r else empty else empty If x=b then 1'r else empty If x=a then 1'r else empty r 2'r If x=b then 1'r else empty 1'r If x=a then 1'r else empty If x=a then 1'r else empty 1'(a,0) + 3'(b,0) P P P P E1 T1 (x,i) (x,i) E2 T2 E3 T3 E4 T4 E5 (x,i) P 1'(a,0) (x,i) (x,i) (x,i) (x,i) (x,i) (x,i) If x=a then 1'(a,i+1) else empty If x=a then 1'r else empty If x=a then 1'r else empty If x=b then 1'r else empty T5 [x=b] If x=b then 1'(b,i+1) else empty Figura 9: maração equivalente à da Figura 6 Nesse aso, assim omo para M 1, a transição T 1 está habilitada para o modelo b e T 2 para o modelo a. As definições e omandos aqui ilustrados seguem a sintaxe da linguagem CPN ML, desrita em [18]. Os elementos da linguagem CPN ML utilizados neste texto e que não foram expliitados nesta seção, são os seguintes: Mara sem tipo, denotada pelo símbolo () sobre um aro. É usada quando for neessário indiar apenas a presença de uma mara, independentemente do tipo. Assim, o domínio da or desta mara é olor X = unit, indiando um únio valor, representado por (). Por exemplo, informa a gerênia da fábria após dez arros terem sido 19

34 Fundamentos fabriados, para ontrole da produção e então segue produzindo outros arros. Para isso, não é neessário um tipo espeífio de mara, pois independe do modelo do arro; Tipo de dado proedente da entrada. É a delaração em um lugar, para uma or do mesmo tipo das que vêm omo entrada, e é denotada por olor X = input. É usado prinipalmente om listas de valores. Por exemplo, a ada arro produzido, insere o número do hassi em uma lista. O tipo da mara é o mesmo da entrada; Definições e operações sobre listas: o [] : lista vazia; o x::y : insere o elemento x na lista y; o elt(x,y) : devolve verdadeiro se x está ontido na lista y, ou falso, aso ontrário; o del(x,y) : enontra e remove o elemento x da lista y Workflow Nets Uma PT-net pode ser utilizada para representar proessos de workflow. Neste aso, essa rede é hamada Workflow net, ou WF-net. Diferentemente das PT-nets, uma WF-net deve representar uma exeução isolada de um proesso. DEFINIÇÃO 2.2 (WF-net): uma Rede de Petri PN = (L, T, A) é uma WF-net (workflow net) se e somente se: Existe um únio lugar de entrada i L, tal que i ; Existe um únio lugar de saída o L, tal que o ; Cada nó da rede x L T deve estar em um aminho do lugar de entrada i ao lugar de saída o. Neste texto são utilizadas CPNs ou WF-nets na representação de padrões. Para a implementação, ontudo, esta proposta possibilita a integração do middleware ao gereniador de workflow de preferênia do usuário. O grau de integração pode variar em função dos reursos para extensão ofereidos pelo gereniador. Por exemplo, pode ser possível desde apenas utilizar serviços web a partir de um workflow desenvolvido em uma determinada ferramenta, até aresentar novas atividades por meio de interfae gráfia. Nesse último aso, a representação de padrões fia restrita àquela disponibilizada pela ferramenta. Para demonstrar essa integração, omo parte do desenvolvimento foi onstruído um módulo para integração ao Windows Workflow Foundation [19], que baseia sua interfae gráfia em workflow graphs [20]. 20

35 Fundamentos 2.4 Conlusão Alguns dos termos apresentados neste apítulo, omo workflows e padrões, possuem definições informais, o que pode resultar em interpretações diferentes de oneitos baseados em tais termos. Por esse motivo, este apítulo apresentou a semântia que é adotada no restante deste texto. Além disso, os fundamentos de Redes de Petri e uma visão geral sobre os Padrões de Workflow também foram apresentados, no intuito de failitar a leitura dos próximos apítulos. 21

36 Trabalhos Relaionados Capítulo 3 Trabalhos Relaionados A arquitetura desrita neste texto possibilita a exeução de padrões de workflow em grades, de modo a simplifiar o uso desses reursos, no toante à representação de padrões e ao uso de grades. Existem trabalhos aadêmios e omeriais sobre ada um desses assuntos: padrões, workflows e grades. Este apítulo desreve o estado da arte sobre esses temas e identifia, para ada trabalho, os pontos omplementados por este estudo. Neste apítulo, além dos trabalhos relaionados aos temas workflows e grades, são também apresentados aqueles sobre a exeução de workflows em grades. 3.1 Soluções de Workflow Existentes Aalst et al [1] publiaram padrões de workflow itados em diversos trabalhos aadêmios. Posteriormente, Russell et al [2] estenderam o onjunto de padrões, riando diversas espeializações para os padrões desritos em [1]. Em ambas publiações, os autores estudaram 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 foi avaliado quanto à implementação ou não dos padrões de ontrole de fluxo. A mesma análise é realizada em [21] 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. 22

37 Trabalhos Relaionados Sistemas gereniadores de workflows ientífios, omo Kepler [22], Taverna [23] e Triana [24], por sua vez, usam abordagem orientada a fluxo de dados ao invés de fluxo de ontrole, não possuindo implementações de padrões de paralelização. Na plataforma Windows existem o BizTalk Server [25], ferramenta para integração de sistemas, que inlui um gereniador de workflow, e o Windows Workflow Foundation (WF) [19], gereniador de workflow inluso no.net Framework [26]. As duas soluções implementam padrões básios de paralelização, também sem prever exeução em grade. 3.2 Soluções de Grade Existentes Existem diversas soluções para exeução de apliações distribuídas em grades, o que olabora para a melhoria de desempenho da solução omo um todo. Tal diversidade de opções pode ser observada em diferentes soluções de grade Berkeley Open Infrastruture for Network Computing (BOINC) Em 1999 foi lançado o projeto SETI@Home [27], que proura por vida extraterrestre utilizando tempo oioso de omputadores na Internet. Essa solução tornou-se popular, e se arateriza por ser de propósito espeífio, não sendo apliável para outros enários. A partir de 2005, o SETI@Home passou a utilizar o BOINC [28], que possui propósito geral, mas não possui onstruções espeífias para exeução paralela. A utilização do BOINC é feita a partir de API esrita em C Projeto Globus O Projeto Globus [29] oferee infra-estrutura para grades geografiamente distribuídas e apresenta Arquitetura Orientada a Serviços, SOA [30]. Como parte das ferramentas e omponentes que o integram está o Globus Toolkit [31]. 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. Seguindo o modelo liente-servidor, o Globus apresenta um onjunto de omponentes, ilustrado na Figura 10. É uma solução robusta, no toante à sua ompletude, e é utilizada em diversas instalações, sendo amplamente refereniada em trabalhos aadêmios. Os ontêineres Java, Python e C permitem que sejam aresidos novos serviços ao servidor. Com isso, torna-se possível utilizar o Globus para o 23

38 Trabalhos Relaionados desenvolvimento em soluções vertiais, omo saúde, finanças e outros segmentos espeífios. Figura 10: arquitetura do Globus Toolkit 4 [32] Ourgrid Desenvolvido pela equipe do Laboratório de Sistemas Distribuídos da Universidade Federal de Campina Grande, o Ourgrid [33] é um gereniador de grade que se baseia em modelo peer-to-peer, e se aplia a tarefas que sejam onsumidoras de reursos de modo independente umas das outras. Apliações desse tipo são denominadas bag-of-tasks appliations. Exemplos de apliações indiadas para uso do Ourgrid são: mineração de dados, previsão de lima, estudos genétios, simulações de Monte Carlo e proessamento de imagens, entre outros. Os prinipais apelos do Ourgrid são sua simpliidade de implantação e a poua buroraia para que uma instituição possa aderir à rede, uma vez que não são neessários ertifiados ou protoolos de federação de identidade. O Ourgrid é distribuído gratuitamente sob o lieniamento GPL, em um onjunto denominado Ourgrid Toolkit. Este é omposto por três elementos prinipais, onforme a Figura 11: Ourgrid Community: agrega um onjunto de instituições que implantaram o Ourgrid. Cada instituição possui um servidor om o Ourgrid Peer instalado. Este, por sua vez, é o responsável pela aloação de tarefas nos nós da grade da instituição; 24

39 Trabalhos Relaionados MyGrid: é a interfae do Ourgrid om o usuário, através do qual as Tarefas, agrupadas em Jobs, são submetidas à grade. Cada MyGrid deve estar assoiado a um Ourgrid Peer; Swan: é um modelo de sandbox, que isola a exeução das tarefas no nó da grade, dos demais apliativos e reursos do nó, inlusive aesso à rede. Figura 11: elementos onstituintes do Ourgrid Toolkit [34] Cada Ourgrid Peer aessa os reursos de seus nós através de uma interfae hamada GridMahine. O onjunto de funções dessa bibliotea, apresentado na Tabela 1, é bastante reduzido, simplifiando a utilização. Operação Ping run putfile getfile kill Desrição Tabela 1: operações da interfae GridMahine Avalia a disponibilidade de um nó da grade Submete um job para um nó da grade Armazena dados em um nó da grade Reupera dados de um nó da grade Canela um job 25

40 Trabalhos Relaionados Os testes realizados neste trabalho utilizaram o Ourgrid, onforme desrito nas seções Comuniação entre o EGG e o Gereniador de Grade e Submissão de Atividades ao EGG para Ourgrid InteGrade Baseado em CORBA [35], o InteGrade [36] 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 sejam fortemente aoplados. Os prinipais elementos que o ompõem são os apresentados na Figura 12. Figura 12: exemplo dos omponentes do InteGrade em federação [37] 26

41 Trabalhos Relaionados O InteGrade pode ser utilizado dentro de um luster ou em modelo de federação, para integração om outras instalações. O projeto foi desenvolvido e testado por um onjunto de universidades brasileiras: IME-USP, PUC/RJ, UFMS, UFG e UFMA. Cada luster possui: Cluster Resoure Manager (GC na Figura 12), responsável pelo gereniamento do luster e pela omuniação om outros lusters; Resoure Providers (PR na Figura 12): são os nós da grade, que ofereem seus reursos para ompartilhamento. Os prinipais tipos de apliações que podem ser exeutadas no InteGrade são: As que seguem o Modelo BSP (Bulk Synhronous Parallel), proposto pela Universidade de Oxford, por intermédio da BSPLib, uma bibliotea disponível em C e Fortran; As que se omuniam usando MPI. O InteGrade usa uma implementação que modifia a MPICH2; Apliações Bag-of-Tasks (onforme apresentado na seção 3.2.3) Alhemi Baseado na Plataforma.NET [26], o Alhemi [38] é uma infra-estrutura para distribuição de exeução de omponentes.net sobre plataforma Windows. A arquitetura do Alhemi, ilustrada na Figura 13, segue o modelo de um distribuidor de tarefas para os nós da grade, denominado Alhemi Manager. Em ada nó deve haver um serviço para exeução das tarefas, hamado Alhemi Exeutor. A submissão de tarefas (Grid Threads) para exeução na grade pode ser feita de dois modos: Diretamente pela apliação liente em.net, usando uma bibliotea de lasses, a Alhemi.NET API; Pelo envio de apliações exeutáveis, usando um arquivo de onfiguração em XML, no qual são expliitados os exeutáveis e seus parâmetros. Esse envio pode ser feito usando uma interfae para onsole, a Alhemi Console Interfae, ou ainda por intermédio do Alhemi Cross-Platform Manager, uma interfae baseada em serviços web. Por se tratar de uma arquitetura baseada na plataforma.net, pode ser utilizada para redes onde os nós possuam Windows e o.net Framework instalados. 27

42 Trabalhos Relaionados É possível a integração om outras plataformas e soluções por meio de serviços web forneidos pelo Alhemi Cross-Platform Manager. Assim, uma tarefa esrita em plataforma diferente da.net, omo Java, por exemplo, pode ser enviada e exeutada nos nós da grade gereniada pelo Alhemi. Apliação de e-business Apliação de e-siene Apliação de e-engineering Apliação de e-commere Exeutáveis pré-ompilados Alhemi.NET API Alhemi Jobs (representação em XML) Alhemi Console Interfae Alhemi Cross- Platform Manager Grid Threads (objetos.net) Alhemi Manager Alhemi Exeutor Alhemi Exeutor... Alhemi Exeutor Equipamentos baseados em Windows om.net Framework Figura 13: arquitetura do Alhemi [39] Considerações sobre as Soluções de Grade Os itens aima ilustram diversas soluções om meanismos de aesso e reursos distintos. Apesar disso, todos apresentam interfaes que podem ser enapsuladas em um serviço web e disponibilizadas de um modo padrão. Por isso, a arquitetura desenvolvida neste trabalho pode operar om qualquer implementação de grade dentre as aima. Como prova de oneito, o desenvolvimento aqui proposto e realizado utilizou o Ourgrid, que está em uso pelo Grupo de Proessamento Paralelo e Distribuído da Universidade Federal do Rio Grande do Sul, onde parte dos testes foram realizados. 28

43 Trabalhos Relaionados Foi desenvolvido também um omponente para exeução de apliações paralelas sem o uso de grade, demonstrando a flexibilidade da arquitetura proposta. 3.3 Exeução de Workflows em Grade Alguns trabalhos desrevem a exeução de workflows em grades Abstrat Grid Workflow Language (AGWL) e ASKALON Apresentado por Fahringer et al em [40], a AGWL ontém onstruções de paralelização, sem menionar padrões mais sofistiados omo os desritos por Russell et al [2]. A AGWL permite a representação de workflows em XML, de modo independente de plataforma ou implementação. A Figura 14 mostra omo a AGWL é utilizada pelo ASKALON [41], um ambiente para desenvolvimento e exeução de workflows em grades. 29

44 Trabalhos Relaionados AGWL Composição Compilação CGWL Reifiação Exeução de workflows Esalonador do Workflow Envia e usa reursos da grade Exeução Grade Figura 14: proessamento pelo ASKALON de workflows definidos em AGWL [40] Trata-se de um proesso om três etapas: omposição, reifiação e exeução. O workflow é definido em AGWL na etapa de omposição. Na reifiação, a representação abstrata é então onretizada. Isso é feito através da ompilação do workflow em AGWL pelo ASKALON para CGWL (Conrete Grid Workflow Language), uma linguagem dependente de implementação, que aresenta elementos omo tipos de dados. Nesta etapa são ainda realizadas otimizações, ao prourar onverter atividades seqüeniais em paralelas, por exemplo. Então, na fase de exeução, o exeutor de workflow do ASKALON esalona as tarefas e as envia para a infra-estrutura de grade para exeução. Existem três onstruções para paralelismo - parallel, parallelfor e parallelforeah - onforme apresentado a seguir. Nenhuma delas enapsula o funionamento de padrões mais elaborados desritos por Russell et al [2]. O esquema ompleto da AGWL está disponível em [42]. 30

45 Trabalhos Relaionados <parallel name= name > <datains name= name (soure= soure )?> (<value> value as XML </value>)? </datains>* <setion> <ativity>+ </setion>+ <dataouts name= name soure= soure />* </parallel> <parallelfor name= name > <datains name= name (soure= soure )?> (<value> value as XML </value>)? </datains>* <loopcounter name= name type= type from= from to= to (step= step )? /> <loopbody> <ativity>+ </loopbody>+ <dataouts name= name soure= soure />* </parallelfor> <parallelforeah name= name > <datains name= name (soure= soure )?> (<value> value as XML </value>)? </datains>* <loopelement name= name type= type olletion= olletion /> <loopbody> <ativity>+ </loopbody>+ <dataouts name= name soure= soure />* </parallelforeah> A Figura 15 identifia os elementos onstituintes da arquitetura do ASKALON, desde a definição do workflow em AGWL até sua interfae om a infra-estrutura da grade. É uma Arquitetura Orientada a Serviços [30], que proura abstrair a presença da grade do usuário. Utiliza o Globus [31] omo gereniador de grade. 31

46 Trabalhos Relaionados Figura 15: arquitetura do ASKALON [41] Em [43], Prodan e Fahringer apresentam um algoritmo para esalonamento dinâmio de workflows por meio de um arquivo om ódigo em Java sobre o Globus Toolkit [31]. Os autores utilizaram a ferramenta ZENTURIO [44] para representação e exeução dos workflows, e a linguagem ZEN, baseada em diretivas, semelhante à OpenMP Padrões de Workflow para Grades Pautasso e Alonso desrevem em [45] o uso de padrões em grades. Eles propõem 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 omo permitir a extensão da arquitetura para inluir outros padrões de paralelização. Na solução desrita por Pautasso e Alonso, a exeução paralela de tarefas é dividida em dois padrões: simples e de dados. O padrão simples se aplia a asos em que não há ompartilhamento de informações entre as tarefas sendo exeutadas em paralelo. O paralelismo de dados, por sua vez, onsiste em dividir o onjunto de dados a ser proessado por uma tarefa em diversas porções para proessamento por instânias daquela tarefa. Esse modelo aplia-se a 32

47 Trabalhos Relaionados neessidades triviais de omputação. 4 Este padrão se relaiona om os padrões de múltiplas instânias desritos por Aalst em [2] Condor, Condor-G, DAGMan, Pegasus e GriPhyN VDS Condor ( [46], [47]) é um sistema gereniador de arga, onstituído de um esalonador para distribuição de tarefas. Condor atende a requisitos de indisponibilidade, fazendo a migração de tarefas quando um determinado reurso for requisitado para outra tarefa. Um enário em que o Condor é utilizado é no uso de reursos oiosos. Ao ontrário do paradigma de Computação de Alto Desempenho, os autores posiionam o Condor omo sendo para Computação de Alto Rendimento (throughput). A diferença está no fato do primeiro se destinar a tarefas que onsumam reursos por urtos períodos de tempo, omo previsão do tempo, enquanto o segundo se aplia para uso dos reursos por meses, omo simulações de Monte Carlo para análise de riso [48]. O onjunto de máquinas gereniadas pelo Condor é hamado Condor Pool. A fim de estender o alane do Condor para que possa utilizar reursos de outras grades, foi riado o Condor-G ( [49], [50]), que oferee uma interfae de gereniamento para os nós de uma grade que utilize o Globus. Para que o Condor possa tratar da exeução de tarefas que apresentam dependênias, foi desenvolvido o DAGMan ( [47], [46]). Isso é feito pela análise de informações de dependênia para Grafos Dirigidos Aílios (DAG), por meio de uma linguagem delarativa própria, exemplifiada na Figura 16. As relações de dependênia são definidas através de delarações PARENT/CHILD. A B C JOB A a.ondor JOB B b.ondor JOB C.ondor JOB D d.ondor PARENT A CHILD B C PARENT B C CHILD D D Figura 16: representação de grafo dirigido aílio no DAGMan 4 Em inglês, usa-se o termo embarrassingly parallel omputations para se referir a álulos que possam ser obtidos simplesmente dividindo os dados de entrada em porções que sofram o mesmo proessamento. Um exemplo disso é o álulo aproximado de π, onforme apresentado na Seção

48 Trabalhos Relaionados O DAGMan não possui elementos para representação de fluxo de dados. Assim, deve ser omplementado quanto ao mapeamento de workflows em grades, momento em que é neessário identifiar tal fluxo e disponibilidade ou aloação de dados. A Figura 17 apresenta o mesmo DAG da Figura 16, aresido de informações de dados nos aros do grafo. Foi também inluída informação de que tarefa deve ser exeutada em ada nó, para ilustrar o fato de uma mesma tarefa, t2, poder ser exeutada em diversos pontos do fluxo om parâmetros distintos - neste exemplo em B e C. arq.a A.t1 arq.b1 arq.b2 B.t2 C.t2 arq.1 arq.2 D.t3 arq.d Figura 17: grafo aílio dirigido da Figura 16 om informações de fluxo de dados Para o mapeamento de workflows em grades, prinipalmente sob a ótia dos dados neessários para o proessamento das tarefas nos nós da grade, o Pegasus ( [51], [52]) Planning for Exeution in Grids se integra ao DAGMan e ao Globus. Pegasus utiliza omo entrada um DAX DAG in XML, que é uma representação de grafos dirigidos aílios em XML. A partir daí, produz um workflow onreto, om o mapeamento das tarefas e reursos aos nós da grade. O DAX pode ser esrito diretamente pelo usuário, ou ainda ser obtido da transformação de outra linguagem, omo o GriPhyN Virtual Data System (VDS) ( [51], [53]), anteriormente denominado Chimera. A Figura 18 mostra a relação entre o GriPhyN VDS, Pegasus, Condor DAGMan e Globus. A partir da representação do workflow em Virtual Data Language (VDL) [54], o GriPhyN VDS gera um workflow abstrato que pode então ser ofereido ao Pegasus. Este onsulta serviços de disponibilidade de reursos e loalização de dados do Globus: o Monitoring and Disovery Servie (MDS) e o Replia Loator Servie (RLS). Com isso, gera um workflow onreto que é submetido ao DAGMan. Por sua vez, este determina a seqüênia de Jobs a serem enviados para exeução pelo Globus. 34

49 Trabalhos Relaionados Globus Redução Jobs (Exeução) VDL GriPhyN VDS Pegasus Workflow Workflow DAGMan Abstrato Conreto (DAX) (DAG) Figura 18: representação, transformação e exeução de workflows em grades (Adaptado de [51]) O treho de ódigo abaixo ilustra o workflow da Figura 17 representado em VDL. TR india a definição de transformações que serão realizadas nos dados. Em t1 e t2, os dados de entrada serão proessados pelas apliações app1 e app2, respetivamente, produzindo suas saídas. O mesmo aontee em t3, porém om a apliação que realizará a transformação sendo onheida em tempo de exeução (om valor padrão app3), o que onfere maior flexibilidade e dinamismo aos workflows. DV representa derivações, em que o mapeamento das transformações é desrito em ada nó do grafo, isto é, em ada tarefa do workflow. TR t1( output b[], input a ) { app = "/usr/bin/app1"; arg = "-i "${input:a}; arg = "-o "${output:b}; } TR t2( output b, input a ) { app = "/usr/bin/app2"; arg = "-i "${input:a}; arg = "-o "${output:b}; } TR t3( output b, input a2, input a1, none name="/usr/bin/app3" ) { app = ${none:name}; arg = "-i "${input:a1}" "${input:a2}; arg = "-o "${output:b}; } DV ], a=@{input:"arq.a"} ); DV B->t2( b=@{output:"arq.1"}, a=@{input:"arq.b1"} ); DV C->t2( b=@{output:"arq.2"}, a=@{input:"arq.b2"} ); DV D->t3( ] ); Após o proessamento pelo GriPhyN VDS, é gerada a seguinte representação em DAX, que finalmente resulta nas instruções onstantes da Figura 16. As maras <hild> indiam a dependênia entre as tarefas do workflow. 35

50 Trabalhos Relaionados <job id="id000001" name="t1" dv-name="a"> <argument> -a "/usr/bin/app1" -i <filename file="arq.a"/> -o <filename file="arq.b1"/> <filename file="arq.b2"/> </argument> <uses file="arq.a" link="input" > <uses file="arq.b1" link="output" > <uses file="arq.b2" link="output" > </job> <job id="id000002" name="t2" dv-name="b"> <argument> -a "/usr/bin/app2" -i <filename file="arq.b1"/> -o <filename file="arq.1"/> </argument> <uses file="arq.b1" link="input" > <uses file="arq.1" link="output" > </job> <job id="id000003" name="t2" dv-name="c"> <argument> -a "/usr/bin/app2" -i <filename file="arq.b2"/> -o <filename file="arq.2"/> </argument> <uses file="arq.b2" link="input" > <uses file="arq.2" link="output" > </job> <job id="id000004" name="t3" dv-name="d"> <argument> -a "/usr/bin/app3" -i <filename file="arq.1"/> <filename file="arq.2"/> -o <filename file="arq.d"/> </argument> <uses file="arq.1" link="input" > <uses file="arq.2" link="input" > <uses file="arq.d" link="output" > </job> <hild ref="id000002"> <parent ref="id000001"/> </hild> <hild ref="id000003"> <parent ref="id000001"/> </hild> <hild ref="id000004"> <parent ref="id000002"/> <parent ref="id000003"/> 36

51 Trabalhos Relaionados </hild> Embora esta solução funione tanto om Condor Pools quanto om o Globus, ainda assim é de alto aoplamento. Não há indiações de omo inluir outros gereniadores de grade. Além disso, não há tratamento de padrões mais elaborados de workflow para paralelização, omo os previstos por Russell et al [2], fiando a implementação de tais padrões por onta do usuário Grid Proess Exeution Language (GPEL) e CROWN FlowEngine Wang [55] propôs a Grid Proess Exeution Language (GPEL) om onstruções de paralelização dependentes de grade e sem o uso de padrões. A GPEL é uma extensão da BPEL4WS [56], que inlui nesta elementos para exeução em grades, espeifiamente a atividade parallel, uja definição é: <omplextype name="tparallel"> <omplexcontent> <extension base="gpel:tativity"> <sequene> <group ref="gpel:ativity" maxours="unbounded"/> </sequene> </extension> </omplexcontent> </omplextype> A atividade parallel não permite onfigurações para representação dos padrões de workflow desritos por Russell et al [2]. Em [57], Zeng et al apresentam o CROWN FlowEngine, uma implementação de GPEL, uja arquitetura é ilustrada na Figura 19. Vale notar a presença de serviços para persistênia, transações e gereniamento de reursos, tidos pelo Grid Workflow Forum [58] omo alguns dos elementos que diferem um workflow para grades de um workflow para uso sem grades. 37

52 Trabalhos Relaionados Figura 19: arquitetura do CROWN FlowEngine [57] Considerações sobre a Exeução de Workflows em Grades A exeução de workflows em grades apresenta um onjunto de peuliaridades, identifiadas e analisadas por Wang et al [55], onsiderando ada atividade em um workflow omo um serviço a ser enviado à grade: Definição da ordem de exeução de serviços, inluindo seqüênia, paralelismo, esolha e repetição; Definição de troa de dados entre os serviços e uso de ahe; Suporte a WSRF [59], que tem se tornado padrão para utilização de reursos em ambiente om uso de serviços web; Capaidade de exeução de serviços em ambiente de alto desempenho, omo lusters; Meanismo de suporte a interações om grandes quantidades de dados; Suporte a alternativas de assoiação (binding) de serviços a nós da grade. Isso se deve à natureza diversa de apliações a serem exeutadas, e também da dinamiidade das grades quanto à disponibilidade de reursos. Há diversas espeifiações de linguagens para desrição de workflows ( [56], [60], [5]), algumas onsiderando uso em grades ( [55], [40]). Além disso, há várias implementações que permitem a exeução de workflows em grades ( [43], [47]), sendo que as analisadas neste trabalho não tratam de padrões elaborados omo os apresentados por Russell et al em [2]. Outro ponto ausente é o 38

53 Trabalhos Relaionados tratamento simultâneo do baixo aoplamento e da extensibilidade das soluções propostas. Por exemplo, nenhum dos trabalhos avaliados apresenta desaoplamento entre os gereniadores de workflow e de grade. 3.4 Conlusão As seções anteriores apresentam diversos trabalhos sobre padrões, workflows e grades. No entanto, onforme desrito nas onsiderações de ada seção, nenhum desses trabalhos apresenta laramente uma arquitetura desaoplada e extensível, no que diz respeito à utilização pela apliação de e- Siene, integração a diversos gereniadores de workflow, esolha de utilizar ou não um gereniador de grade e, em aso afirmativo, permitir optar pelo que for mais onveniente. O tratamento de padrões de workflow por diversos gereniadores, apresentados na seção 3.1, não leva em onsideração a presença de grade. Além disso, não é apresentado algum modo de implementar um novo padrão e integrá-lo a um gereniador de workflow existente. A doumentação dos gereniadores de grade apresentados na seção 3.2 não trata padrões ou integração a gereniadores de workflow. Embora existam trabalhos relaionando workflow e grades, desritos na seção 3.3, estes apresentam arquiteturas de alto aoplamento, sendo espeífias para um determinado gereniador. Além disso, não tratam padrões de paralelização omo os desritos em [2]. Este trabalho omplementa os apresentados neste apítulo, ao forneer uma únia solução que possui as seguintes araterístias: Representação dos padrões de paralelização independentemente da presença de um gereniador de workflow; Failidade de integração da implementação dos padrões a um gereniador de workflow; Padrões podem ou não ser exeutados em grade; Liberdade de esolha do gereniador de grade; Abstração da presença de grade para o usuário; Extensibilidade da solução, om a possibilidade de inluir ou substituir módulos para tratamento de outros padrões e para integração a gereniadores de workflow e grade. 39

54 Padrões de Workflow Paralelizáveis Capítulo 4 Padrões de Workflow Paralelizáveis O apítulo anterior apresentou a importânia do uso de padrões, e menionou o trabalho de Aalst, Russell et al ( [14], [3], [21], [1], [2]) no sentido de identifiá-los e exemplifiá-los. Vários desses padrões se referem à exeução paralela de tarefas, o que os torna andidatos naturais à análise para exeução em grades, lusters ou em equipamentos multi-proessados. Neste apítulo, são desritos um padrão de divisão paralela e dez padrões de sinronização apresentados por Russell et al em [2]. A partir desses padrões, foi onebido o Padrão Junção Combinada, apresentado ao final do apítulo, e que oferee um onjunto extenso de opções às apliações de workflow. 4.1 Padrões de Workflow Relaionados A arquitetura proposta neste trabalho, desrita na Seção 5.1, possibilita a exeução em grade. Este trabalho implementa dois grupos de situações: Quando não houver a presença de grade: atende ao uso de padrões para paralelização a serem exeutados em modelo om múltiplas threads, potenialmente aloadas em proessadores distintos; Quando houver gereniador de grade: neste trabalho, a flexibilidade da arquitetura permitiu a seleção e utilização do Ourgrid [33], gereniador de grade em uso pelo Grupo de Proessamento Paralelo e Distribuído da Universidade Federal do Rio Grande do Sul. Não está inluso no esopo, ontudo, o gereniamento da exeução quanto a tolerânia a falhas ou outros aspetos não funionais. 40

55 Padrões de Workflow Paralelizáveis No toante aos padrões de workflow, o baixo aoplamento e a estruturação da arquitetura em amadas vide Seção permitem a adição de implementação de padrões a qualquer tempo. Assim, foi possível seleionar um onjunto de padrões para implementar, de modo a permitir a validação e os testes da arquitetura. Dos quarenta e três padrões desritos por Russell et al [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, expostas nesta seção, este trabalho se propõe a tratar o padrão (WCP-2) Divisão Paralela, e os seguintes padrões de sinronização: (WCP-3) Sinronização; (WCP-9) Disriminador Estruturado; (WCP-28) Disriminador om Bloqueio; (WCP-29) Disriminador om Canelamento; (WCP-30) Junção Parial Estruturada; (WCP-31) Junção Parial om Bloqueio; (WCP-32) Junção Parial om Canelamento; (WCP-34) Junção Parial Estátia para Múltiplas Instânias; (WCP-35) Canelamento de Junção Parial de Múltiplas Instânias; (WCP-36) Junção Parial Dinâmia para Múltiplas Instânias. No restante deste apítulo, serão utilizadas Redes de Petri Coloridas (CPN) para representar e exemplifiar o funionamento de ada padrão. Uma vez implementados, os padrões devem exibir interfae simplifiada ao ientista, enapsulando os detalhes de sua operação. Portanto, o proesso de modelagem por parte do ientista deve abstrair quaisquer aspetos intrínseos da representação formal dos padrões. Por exemplo, a Figura 20 mostra uma representação do padrão (WCP-9) Disriminador Estruturado, apropriada para ompreensão do padrão e seu funionamento desrito mais adiante neste apítulo. 41

56 Padrões de Workflow Paralelizáveis i1 T1 im Tm q1 1' () junção o1 q3 () Unit (m-1) () ompleto q2 Figura 20: representação do padrão "Disriminador Estruturado" usando CPN [2] Essa representação é ompleta para forneer o fluxo de exeução. Todavia, é inadequada para o ientista, que neessita apenas modelar seu fluxo informando as entradas e saídas do padrão. Desse modo, uma representação omo a da Figura 21 é mais apropriada. O gereniador de workflows utilizado nos testes permite a onstrução de elementos visuais que são funionalmente equivalentes. i1 WCP-9 o1 im Figura 21: onstrução a ser utilizada pelo ientista As próximas seções revisam os padrões de workflow desritos por Russell et al [2]. As figuras foram adaptadas de modo a tornar explíita a semelhança entre os padrões. Tal semelhança justifia a esolha desses padrões para a implementação neste trabalho, onforme desrito em (WCP-2) Divisão Paralela É o padrão que expliita a possibilidade de exeução em grade. As saídas deste padrão são as entradas para os padrões de sinronização, desritos nas próximas seções. Na Figura 22, i 1 representa o iníio da exeução do padrão, que realiza o disparo das atividades a serem exeutadas em paralelo, a partir 42

57 Padrões de Workflow Paralelizáveis das transições {T 1,...,T m }. O término da exeução do padrão oorre quando ada lugar de saída {o 1,...,o m } reeber uma mara. i1 Divisão p1 T1 o1 pm Tm om Figura 22: Padrão Divisão Paralela Este padrão faz parte do onjunto de padrões básios identifiados por Aalst et al [1], sendo implementado por todas as soluções de workflow itadas no Capítulo 3. Este texto assume a exeução assínrona das atividades assoiadas às transições {T 1,...,T m }, fiando os padrões de sinronização responsáveis por verifiar quando essas tarefas tenham sido onluídas. Desse modo, logo que uma atividade é oloada em exeução por T i, om (1 i m), uma mara é depositada em o i. Essa suposição é importante para garantir o funionamento dos padrões de sinronização (WCP-3) Sinronização É o padrão mais simples para junção (sinronização) dos fluxos de exeução paralela de atividades. As entradas deste padrão são as saídas do padrão Divisão Paralela. Na Figura 23, {i 1,...,i m } representam o iníio da exeução do padrão, que realiza a junção das tarefas exeutadas em paralelo, sendo que {T 1,...,T m } representam o término das atividades dos ramos de entrada do padrão. O lugar o 1 representa o término da exeução do padrão. i1 T 1 q1 Junção o1 im T m qm Figura 23: Padrão Sinronização 43

58 Padrões de Workflow Paralelizáveis Este padrão também faz parte do onjunto de padrões básios identifiados por Aalst et al [1], sendo implementado por todas as soluções de workflow itadas no Capítulo 3. A Figura 24 ilustra a utilização ombinada dos padrões Divisão Paralela e Sinronização. (WCP-2) Divisão Paralela (WCP-3) Sinronização i1 Divisão p1 T1 oi1 T 1 q1 Junção o1 pm Tm oim T m qm Figura 24: ombinação do uso dos padrões Divisão Paralela e Sinronização As transições {T 1,...,T m } indiam o iníio da exeução das atividades a elas assoiadas. Assim, por exemplo, a atividade da transição T i é oloada em exeução e, ao mesmo tempo, uma mara é inserida em oi i 5. Nesse aso, a transição T i apenas oorrerá quando tal atividade tiver sido onluída Disriminadores Caraterizam-se pela produção de saída quando uma das atividades em paralelo tiver sido onluída (WCP-9) Disriminador Estruturado Assim omo os demais padrões de sinronização, o Disriminador Estruturado trabalha juntamente om o padrão Divisão Paralela (WCP-2), onforme ilustrado na Figura 25. O funionamento do padrão é: iniialmente existe uma mara em i 1, e uma mara sem tipo, identifiada por (), em q 3. Esta última ontrola o momento em que a transição junção pode oorrer, onforme desrito a seguir. Um onjunto de atividades {A 1,...,A m } a serem exeutadas paralelamente é submetido ao padrão WCP-2. Essas atividades são oloadas em exeução nas transições {T 1,...,T m } e maras são inseridas nos loais de saída {oi 1,...,oi m }. 5 oi i representa ambos a saída de T j na Divisão Paralela e a entrada para T j na Sinronização 44

59 Padrões de Workflow Paralelizáveis (WCP-2) Divisão Paralela (WCP-9) Disriminador Estruturado i1 [A1,,Am] Divisão p1 pm T1 Tm oi1 oim T 1 T m q1 1' () junção o1 q3 () Unit (m-1) () ompleto q2 Figura 25: Padrão Disriminador Estruturado e Padrão Divisão Paralela Quando uma dessas atividades for onluída, por exemplo A i, a transição T i oorrerá e o lugar q 1 reeberá uma mara, habilitando a transição junção e produzindo a saída o 1. Nesse momento, q 2 reeberá uma mara, e a transição ompleto aguardará o reebimento das (m-1) demais maras, vindas de q 1, à medida que as demais atividades forem onluídas. Quando isso oorrer, uma mara sem tipo será inserida no lugar q 3, habilitando o padrão a ser novamente utilizado (WCP-28) Disriminador om Bloqueio A apliação que utiliza o padrão Disriminador Estruturado é responsável por garantir que nova exeução no mesmo proesso não seja possível até que todas as tarefas tenham sido onluídas. Caso esse uidado não seja tomado, uma nova exeução da(s) tarefa(s) que tenha(m) sido onluída(s) será possível, om onseqüênias que o padrão não prevê. Por exemplo, seja um onjunto {A 1,..., A m } de testes genétios a serem realizados para avaliar uma hipótese diagnóstia para uma determinada doença. Caso um dos testes seja positivo, digamos A i, a transição T i oorre, indiando a onfirmação da hipótese diagnóstia e o onjunto de testes pode ser realizado para outro paiente isso é obtido ao inserir uma mara em q 1, habilitando a transição junção (que também irá onsumir a mara sem tipo de q 3 ). Antes que os demais testes sejam onluídos, os dados de outro paiente são submetidos ao proessamento. Nesse momento, o teste A i passa a ser realizado para o novo paiente. Caso tal teste se onfirme ainda antes dos testes do primeiro paiente serem onluídos, uma mara será inserida em q 1. Porém, omo neste aso a atividade junção não estará habilitada (pois a mara sem tipo em q 3 foi onsumida ao término do teste A i do primeiro paiente), essa nova mara será onsumida quando a transição ompleto for realizada, de modo que a saída o 1 não será produzida. 45

60 Padrões de Workflow Paralelizáveis Para que essa situação não oorra, existem duas possibilidades: a apliação garantir que o padrão somente será utilizado após ompletar a exeução de todas as atividades; ou o padrão ser aresido de onstruções que garantam esse omportamento, dito bloqueante. Neste último aso, o padrão resultante é previsto por Russell et al [2] omo (WCP-28) Disriminador om Bloqueio. Ilustrado na Figura 26 6, este padrão ontém elementos para não permitir que uma exeução seja possível antes do término da exeução anterior, de modo independente da apliação. Esses elementos, representados pelas transições {t 1,...,t m } e pela lista s, garantem ao padrão o omportamento bloqueante. A lista ontém um identifiador para ada lugar de entrada oi i. Quando o padrão for aionado pela primeira, vez, a lista estará vazia, tendo sido iniializada no lugar entradas em uso. Assim que a atividade A k for oloada em exeução pela transição T k, uma mara será inserida em oi k. Como o elemento k não está na lista (até o momento vazia), oorrerão as seguintes ações: t k será habilitado; uma mara será inserida em i k ; e k será inserido na lista s. Caso seja feita nova tentativa de uso do padrão, essa exeução fia bloqueada pelas atividades estarem na lista. Apenas quando as tarefas da primeira exeução forem onluídas, a lista será esvaziada (aro de ompleto para entradas em uso ), permitindo a nova exeução. Desse modo, não há interferênia entre as exeuções do padrão. oi1 oim t1 [not(elt(1,s))] 1::s m::s tm [not(elt(m,s))] s s ent. em uso i1 [] Input im T 1 T m q1 1' () junção o1 () q3 Unit [] (m-1) () ompleto q2 Figura 26: Padrão Disriminador om Bloqueio. Adaptado de [2]. Trata-se de uma espeialização do Padrão Disriminador Estruturado. Aqui, o padrão independe da apliação no ontrole de exeuções suessivas. 6 Para simpliidade desta e das demais figuras relativas aos padrões, foi omitida a representação do padrão Divisão Paralela. Os elementos desse padrão ({A 1,...,A m } e {T 1,...,T m }) ontinuarão a ser refereniados no texto para exemplifiar a exeução dos demais padrões 46

61 Padrões de Workflow Paralelizáveis (WCP-29) Disriminador om Canelamento Ao produzir a saída o 1, o Padrão Disriminador Estruturado aguarda que todas as demais atividades sejam onluídas para então poder ser novamente utilizado. Todavia, quando essa espera for desneessária, o padrão pode ser oloado em prontidão novamente ao sinalizar às demais atividades que seu resultado será desartado. Esse omportamento é partiularmente útil em enários de alta onorrênia pelo uso do padrão, aumentando sua disponibilidade. Por exemplo, a análise de riso operaional de uma fábria pode demandar manutenção orretiva quando um dentre dez possíveis indiadores ultrapassar determinado limite. Quando isso oorrer, a manutenção será realizada, independentemente dos demais indiadores. Este padrão oferee esse omportamento, e é ilustrado na Figura 27. oi1 S1 T 1 () q1 1' junção o1 oim T m () () Sm q3 () Unit (m-1) () ompleto q2 Figura 27: Padrão Disriminador om Canelamento. Adaptado de [2]. Em relação ao Padrão Disriminador Estruturado, existem duas diferenças: a inlusão de atividades {S 1,...,S m } e novos aros, ligando q 3 às transições {T 1,...,T m }. Uma atividade S i é exeutada durante o anelamento, quando a atividade A i orrespondente não for mais neessária. Tal S i pode representar uma atividade de desfazimento ou ompensação, ou ainda simplesmente não fazer ação espeífia, servindo nesse aso apenas para oloar o padrão novamente em estado de prontidão. 47

62 Padrões de Workflow Paralelizáveis Os novos aros, por sua vez, impedem a exeução das transições {T 1,...,T m } após uma delas ter sido ompletada. O funionamento do padrão é: à medida em que as atividades {A 1,...,A m } são oloadas em exeução, maras são inseridas nos lugares {oi 1,...,oi m }. Quando uma atividade A i for onluída, a transição T i irá oorrer. Para isso, irá onsumir as maras em oi i e em q 3. Então uma mara será inserida em q 1 e outra em q 3, habilitando a transição junção. No próximo passo de exeução, esta transição pode oorrer, ou ainda outra transição T k, aso a atividade A k tenha sido onluída. Embora o padrão não determine qual dessas transições irá oorrer primeiro, ele garante que a transição junção oorra em algum momento, uma vez que o número de atividades é finito. Assim que a transição junção oorrer, o 1 reeberá uma mara, permitindo o prosseguimento do fluxo. A partir daí, o padrão proede ao anelamento das demais atividades. Como o lugar q 3 estará sem mara, o padrão não poderá reonheer o término de outras atividades, ou seja, q 1 só poderá reeber maras vindas das transições de anelamento. Ao mesmo tempo, q 2 reeberá uma mara, habilitando as transições de anelamento assoiadas às atividades que ainda não foram onluídas (as que possuírem mara nos lugares oi de entrada). Uma por vez, as transições de anelamento onsomem a mara de q 2, possivelmente enviam algum sinal de anelamento de atividade, e inserem uma mara em q 1 e outra em q 2, habilitando outra transição de anelamento. Esse proesso se repete até que todas as maras de entrada tenham sido onsumidas. Então a transição ompleto será habilitada e poderá oloar uma mara sem tipo em q 3, habilitando o padrão para ser novamente utilizado Junções Pariais São padrões semelhantes aos disriminadores, sendo uma forma mais genéria daqueles. Aqui, a saída o 1 é produzida quando n (n m) atividades tiverem sido onluídas. Os disriminadores são junções pariais em que n= (WCP-30) Junção Parial Estruturada Semelhantes aos Disriminadores Estruturados, a únia diferença é a transição junção ser habilitada quando n atividades dentre {A 1,...,A m } tiverem sido onluídas. A transição ompleto permanee sendo habilitada quando as demais atividades forem onluídas. Enquanto nos disriminadores eram (m-1) atividades, nas junções pariais esse número é (m-n). O padrão é representado na Figura 28, onde essas modifiações podem ser observadas nos aros que saem de q 1. 48

63 Padrões de Workflow Paralelizáveis oi1 T 1 oim T m q1 n () junção o1 q3 () Unit (m-n) () ompleto q2 Figura 28: Padrão Junção Parial Estruturada. Adaptado de [2]. A menos dos pontos aima, o funionamento deste padrão é idêntio ao desrito na seção Vale notar que os Disriminadores Estruturados representam uma espeialização deste padrão (WCP-31) Junção Parial om Bloqueio Do mesmo modo que os Disriminadores om Bloqueio, tornam o padrão independente da apliação, no toante ao tratamento de bloqueios de exeução de atividades antes do término da exeução anterior, onforme ilustrado na Figura 29. oi1 oim t1 [not(elt(1,s))] 1::s m::s tm [not(elt(m,s))] s s ent. em uso i1 [] Input im T 1 T m q1 n () junção o1 [] () q3 Unit (m-n) () ompleto q2 Figura 29: Padrão Junção Parial om Bloqueio [2]. 49

64 Padrões de Workflow Paralelizáveis Exeto pelo fato das transições junção e ompleto serem habilitadas quando houver n e (m-n) maras em q 1, respetivamente, o funionamento deste padrão é idêntio ao desrito na seção (WCP-32) Junção Parial om Canelamento Semelhante aos Disriminadores om Canelamento, permite a reutilização do padrão após n tarefas terem sido onluídas, anelando as demais, onforme a Figura 30. oi1 S1 T 1 () () q1 n junção o1 oim T m () Sm q3 () Unit (m-n) () ompleto q2 Figura 30: Padrão Junção Parial om Canelamento [2]. Exeto pelo fato das transições junção e ompleto serem habilitadas quando houver n e (m-n) maras em q 1, respetivamente, o funionamento deste padrão é idêntio ao desrito na seção Padrões para Múltiplas Instânias São aqueles em que as atividades a serem exeutadas em paralelo são instânias de uma mesma atividade. Muitas vezes são utilizados em ontexto de omputações triviais, onforme onstatado por Pautasso [45], mais espeifiamente quando as instânias puderem ser exeutadas independentemente umas das outras. 50

65 Padrões de Workflow Paralelizáveis (WCP-34) Junção Parial Estátia para Múltiplas Instânias Embora Russell et al [2] apresentem este omo um novo padrão, trata-se de uma espeialização do Padrão Junção Parial Estruturada, em que as atividades a serem exeutadas possuem mesmo ódigo, ou seja, são instânias de uma mesma atividade, possivelmente om parâmetros distintos. A Figura 28 se aplia para ilustrar este padrão, sem modifiações (WCP-35) Junção Parial de Múltiplas Instânias om Canelamento Embora Russell et al [2] apresentem este omo um novo padrão, trata-se de uma espeialização do Padrão Junção Parial om Canelamento, em que as atividades a serem exeutadas possuem mesmo ódigo, ou seja, são instânias de uma mesma atividade, possivelmente om parâmetros distintos. A Figura 30 se aplia para ilustrar este padrão, sem modifiações (WCP-36) Junção Parial Dinâmia de Múltiplas Instânias É uma extensão da Junção Parial Estátia de Múltiplas Instânias. Aqui, é possível exeutar novas instânias da atividade em questão, antes que o padrão tenha produzido a saída o 1. Um exemplo de uso deste padrão é no ontexto de ontrole sismográfio por meio de sensores. Cada ponto de heagem pode onter um sensor de reserva, a ser aionado dinamiamente aso o sensor prinipal apresente alguma falha. Mostrado na Figura 31, este padrão apresenta as seguintes diferenças em relação à Junção Parial Estátia de Múltiplas Instânias: O lugar Permite novas instânias é o responsável por reeber omandos externos ao padrão para riação de novas instânias; A transição Iniia instânia é responsável por exeutar uma nova instânia da atividade em questão, semelhante ao funionamento das atividades {T 1,...,T m } do padrão Divisão Paralela. Assim, uma nova instânia da atividade é riada e oloada em exeução, ao mesmo tempo que uma mara é inserida no lugar oi i. A transição T i estará habilitada quando a atividade for ompletada; Este padrão permite que novas instânias sejam riadas apenas enquanto a transição junção não for exeutada. Para que esse omportamento seja garantido, o lugar Não permite novas instânias reebe uma mara apenas quando a transição desabilita riação de instânias for exeutada. 51

66 Padrões de Workflow Paralelizáveis O funionamento do padrão é o mesmo do Padrão Junção Parial Estátia de Múltiplas Instânias, exeto pelos seguintes pontos: Iniialmente o lugar Permite novas instânias possui uma mara e o número iniial de instânias sendo exeutadas em paralelo, omo resultado da exeução do Padrão Divisão Paralela. Desse modo, as transições Iniia instânia e desabilita riação de instânias estão habilitadas; Quando houver um omando externo para riação de instânias, a transição Iniia instânia dispara nova instânia e, ao mesmo tempo, insere uma mara em oi i, habilitando a transição T i, que aguardará o término da exeução da atividade. Uma mara então é oloada em Permite novas instânias, atualizando o número de instânias om o valor (,m+1) no aro de entrada desse lugar; Do mesmo modo que para o Padrão Junção Parial Estátia de Múltiplas Instânias, à medida que as atividades terminam sua exeução, maras são depositadas em q 1 ; Para que a transição junção seja habilitada, a transição desabilita riação de instânias neessita oorrer, momento em que o número total de instânias é informado ao lugar Não permite novas instânias ; Quando a transição junção oorrer, uma mara é inserida em o 1, permitindo o prosseguimento do fluxo. Ao mesmo tempo, o número de instânias é informado a q 2 e à transição ompleto, que então aguarda o término da exeução das atividades restantes. 52

67 Padrões de Workflow Paralelizáveis oi1 T 1 Não permite novas inst. (,m) oim T m q1 n junção o1 () oii T i q3 () Unit (,m) Iniia instânia (m-n) () ompleto (,m) q2 (,m) (,m+1) Permite novas inst. (,m) (,m) desabilita riação inst. (,m) Figura 31: Padrão Junção Parial Dinâmia para Múltiplas Instânias. Adaptado de [2]. T i aguarda a onlusão da exeução de uma instânia dinamiamente riada. Este padrão pode ter seu uso estendido para a exeução de atividades distintas, uma vez que nada impede que isso oorra. Desse modo, atende à seguinte situação: um onjunto de testes para tentar onfirmar uma hipótese diagnóstia é iniiado, sendo que alguns desses testes podem ser de longa duração. Para onfirmar a hipótese supõe-se que ino destes devem ser positivos. Após o iníio dos testes, um novo método pode surgir e deve ser então testado, sem que o proesso preise ser reomeçado. 4.2 O Padrão Junção Combinada (PJC) No toante à implementação, a presença de número elevado de padrões pode ser onfusa e deixar de atender ao requisito de simpliidade de utilização por parte do usuário. Segundo Aalst et al [3], diversos padrões são espeializações de outros, o que pode ser onstatado na seção anterior. Dessa forma, no modelo físio, esses padrões podem ser ombinados e ofereerem 53

68 Padrões de Workflow Paralelizáveis seu omportamento assoiado a pré-ondições que dependam de parâmetros de entrada. A fim de failitar a implementação, os padrões referentes a paralelização, destaados na Seção 4.1 podem ser ombinados no modelo apresentado de modo simplifiado na Figura 32. Desse modo, pode-se propor um únio algoritmo que implemente os asos previstos por Aalst et al, além de outros não previstos, em deorrênia da ombinação. Denominamos esse modelo de Padrão Junção Combinada, ou PJC. 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 32: representação simplifiada do Padrão Junção Combinada Para auxiliar na omparação om os padrões desritos por Aalst, foi deidido representar aqui também utilizando CPN. Contudo, workflow graphs permitem que ientistas de outras áreas representem seus fluxos de modo mais flexível [7], sendo mais apropriados para a utilização dos padrões a partir de alguma ferramenta om interfae gráfia. No que diz respeito a omportamento bloqueante, definido na Seção , Russell et al [2] apresentam os padrões de modo didátio, evitando ombinar este reurso om outros, omo anelamento. Além disso, afirmam que o uso de padrões sem bloqueios pode resultar em omportamento imprevisível, e não apresentam enários de uso para este aso. Tal uso ainda exige que a apliação que utiliza os padrões evite o aionamento destes antes do término da exeução anterior. Este trabalho onsidera que padrões devem refletir onjuntos de omportamentos hermétios. Assim, quanto menor a dependênia entre seu funionamento e variáveis externas, maior a previsibilidade sobre sua exeução. Por esse motivo, o PJC sempre apresenta omportamento bloqueante, tirando 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. 54

69 Padrões de Workflow Paralelizáveis 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. A tabela a seguir ilustra possíveis valores de entrada e o padrão ao qual a ombinação orresponde. Tabela 2: 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 Padrão Junção Combinada representar três tipos de padrões: Padrões previstos por Russell et al [2]: o Disriminador om bloqueio (WCP-28); o Junção parial om bloqueio (WCP-31). Combinações de padrões mapeados por Russell et al [2], aresidos de omportamento bloqueante: o P5: junção parial estátia de múltiplas instânias (WCP-34) om bloqueio; 55

70 Padrões de Workflow Paralelizáveis 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; 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 et al [2]: 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 Construção do PJC O Padrão Junção Combinada foi idealizado a partir da apliação inremental dos oneitos espeífios de ada padrão de Aalst. Esta seção apresenta omo o PJC pode ser obtido a partir do Padrão Junção Parial om Bloqueio (WCP-31), aresido de anelamento e da possibilidade de adição dinâmia de atividades Junção Parial om Bloqueio Desrito e ilustrado na Seção , foi o ponto de partida, dadas as seguintes araterístias: Inlui os disriminadores, sendo um aso mais genério; Faz o tratamento de bloqueio. O PJC deve atender ao maior onjunto de enários possível. Desse modo, optou-se por eliminar a dependênia da apliação quanto à utilização bloqueante; Inlui o Padrão Junção Parial Estátia de Múltiplas Instânias (WCP-34). 56

71 Padrões de Workflow Paralelizáveis Canelamento Russell et al [2] desreveram a Junção Parial om Canelamento (WCP- 32) de modo independente da Junção Parial om Bloqueio (WCP-31), dado seu objetivo de isolamento dos diversos padrões. Aqui, a finalidade é a implementação dos padrões. Por esse motivo, a esolha reaiu na ombinação de padrões. Neste ponto, Bloqueio e Canelamento estão ombinados, onforme a Figura 33. oi1 oim t1 [not(elt(1,s))] 1::s m::s tm [not(elt(m,s))] s s ent. em uso [] i1 [] Input im S1 T 1 T m S1 q1 (m-n) () () () q3 n () () Unit junção o1 ompleto q2 Figura 33: Junção Parial om Bloqueio e Canelamento. Para melhor ompreensão desta figura, reomenda-se a análise prévia de ada um dos padrões aima ombinados, onforme as seções e Adição Dinâmia de Atividades Permite o arésimo de novas atividades antes que as demais tenham sido onluídas, onforme desrito em Ao ontrário do que Russell et al [2] previram, aqui é possível riar novas atividades também para o aso de instânias distintas. Como exemplo da utilização deste reurso, onsidere a realização de um onjunto de testes genétios. Antes que esses testes sejam onluídos, o que pode levar potenialmente semanas, o ientista deide realizar também um novo teste. Isso é possível sem que seja neessário interromper ou esperar a onlusão dos testes em andamento. Existe portanto um aumento na 57

72 Padrões de Workflow Paralelizáveis flexibilidade desta solução, omo alternativa a fluxos previamente onheidos, o que pode ser útil prinipalmente em asos de experimentação ientífia, omo no exemplo supraitado. Com a inlusão da possibilidade de adiionar dinamiamente novas atividades, hega-se à representação ompleta do padrão, mostrada na Figura 34. oi1 oim t1 [not(elt(1,s))] 1::s m::s tm [not(elt(m,s))] s s ent. em uso i1 [] Input im S1 T 1 T m Sm q1 () () n Não permite novas inst. (,m) junção o1 T i () () (,m) Iniia instânia Permite novas inst. (,m+1) (,m) [] oii Si (m-n) () ompleto q3 () Unit q2 (,m) desabilita riação inst. (,m) Figura 34: Padrão Junção Combinada Para melhor ompreensão desta figura, reomenda-se a análise prévia da Figura 33 e do Padrão Junção Parial Dinâmia de Múltiplas Instânias (WCP- 36), onforme a seção Vale ainda notar que a importânia desta representação ompleta refere-se à implementação do PJC. Caso o objetivo seja apenas de ompreender o padrão, a Figura 32 é sufiiente. Para o ientista, que é o usuário do padrão, a simpliidade de representação, omo a da Figura 21, é apropriada. 58

73 Padrões de Workflow Paralelizáveis 4.3 Conlusão Cada padrão apresentado nas seções anteriores ilustra um omportamento espeífio, omo bloqueio, anelamento, número de atividades onluídas para produção de saída, e assim por diante. O número de padrões onsiderados, ao serem disponibilizados através da implementação da arquitetura desrita no Capítulo 5 ofereem aos gereniadores de workflows mais reursos do que possuem isoladamente, prinipalmente se for onsiderada exeução em grades. A representação dos padrões em CPN e a apresentação isolada de ada padrão, permitem boa ompreensão, sendo didátia e lara. Tais araterístias são apropriadas para a modelagem oneitual e lógia dos padrões. Entretanto, do ponto de vista físio, a implementação de ada padrão de modo isolado aresenta omplexidade de manutenção. Isso se deve à redundânia de ódigo, dado que os padrões apresentados possuem grande similaridade, omo fia laro a partir de uma omparação entre as figuras da seção 4.1. Para soluionar a questão, foi riado o Padrão Junção Combinada (PJC), uma proposta para a representação e implementação onjunta desses padrões. No ontexto da arquitetura apresentada no Capítulo 5, o PJC exemplifia omo a implementação de um padrão se assoia aos demais elementos, ofereendo flexibilidade e extensibilidade à solução. 59

74 Uma Arquitetura de Baixo Aoplamento Capítulo 5 Uma Arquitetura de Baixo Aoplamento Para que uma solução para exeução de padrões de workflows em grades seja utilizada no maior número de enários possível, sua arquitetura deve ser de baixo aoplamento, pois isso onfere independênia de gereniadores de workflow e grades à apliação. A solução, por sua vez, ganha em flexibilidade e extensibilidade. Esse baixo aoplamento é obtido por meio de interfaes, expostas à apliação de e-siene, ao gereniador de workflow e ao gereniador de grade esolhidos. Isso é feito por meio de serviços web, que fazem uma ponte entre a apliação e sua exeução. Esses serviços são dispostos em um middleware om amadas de abstração que permitem o uso dos padrões nos seguintes enários: Em apliações existentes, om ou sem uso de gereniadores de workflow, aresenta a possibilidade de uso de padrões de ontrole de fluxo para paralelização. Este uso não é inteiramente ontido nas prinipais soluções de workflow analisadas por Russell et al [2]; Em novas apliações, oferee a flexibilidade de esolha e substituição dos gereniadores de workflow e de grade a qualquer tempo, demandando pouo esforço de adaptação através de onfigurações do middleware; A amada que abstrai a presença de gereniador de grade permite que uma apliação de e-siene utilize os padrões de workflow em equipamentos multi-proessados e posteriormente seja inserida no ontexto de grades. Este apítulo desreve esta arquitetura, onebida portanto om o intuito de garantir a independênia entre os prinipais elementos da solução: a apliação de e-siene e os gereniadores de workflow e de grade. 60

75 Uma Arquitetura de Baixo Aoplamento Cada amada do middleware proposto é detalhada, de modo que seja possível ter uma visão abrangente da solução. 5.1 Arquitetura Apliações de e-siene que utilizam as soluções apresentadas no Capítulo 3 araterizam-se 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 et al [2] avaliam quatorze produtos omeriais de workflow, identifiando quais ofereem implementações para os padrões de ontrole de fluxo. 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 a 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 35, 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 multi-proessados, útil para asos envolvendo alto tráfego de dados. 61

76 Uma Arquitetura de Baixo Aoplamento Figura 35: arquitetura da solução proposta. A área delimitada pela região traejada india os elementos que ompõem o middleware desenvolvido neste trabalho. Com o objetivo de tornar a solução desaoplada e independente de plataforma, a arquitetura proposta nesta seção, orientada a serviços (SOA) [30], apresenta o uso de amadas, e sua implementação, desrita no Capítulo 6, utiliza serviços web omo meanismo de omuniação entre elas Uso de Múltiplas Camadas Os omponentes da solução proposta são independentes, de modo a poderem 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 35. As amadas que aresentam abstrações para garantir a independênia supraitada são o Exeutor Genério de Padrões (EGP) e o Integrador Padrão- Grade (IPG). Ambos funionam de modo análogo ao ODBC (Open Database Connetivity) [61], amada de abstração de bano de dados, amplamente utilizada em ambientes de programação. O ODBC é omposto por duas amadas: uma genéria, ofereida às apliações lientes, e outra om drivers espeífios para diversos gereniadores de banos de dados, omo Orale, SQL 62

77 Uma Arquitetura de Baixo Aoplamento Server, DB/2, Progress,... O EGP e o IPG são amadas genérias, que se omuniam om amadas ontendo módulos espeífios: Exeutor Genério de Padrões (EGP): abstrai a implementação de um padrão de workflow e também da presença de grade da apliação de e-siene. Esta deve utilizar uma interfae do EGP para submeter um onjunto de tarefas e informar qual padrão deve ser utilizado. O EGP é o responsável por identifiar onde se loaliza a implementação do padrão, e então enaminhar a requisição àquela. Para tornar o uso do EGP independente de plataforma ou implementação, sua interfae é disponibilizada à apliação de e- Siene omo um serviço web, e as informações a ele enviadas o são no formato XML; Integrador Padrão-Grade (IPG): abstrai a presença de gereniador de grade das implementações dos padrões de workflow. O IPG é uma amada genéria que oferee uma interfae independente do gereniador de grade. A implementação de um determinado padrão, omo o PJC, por exemplo, utiliza um serviço web disponibilizado pelo IPG. Este possui as seguintes funionalidades: o Enaminhar arquivos a serem utilizados omo entrada, a partir da loalização indiada pela apliação liente até o equipamento onde se enontra o Exeutor para o Gereniador de Grade (EGG) a ser utilizado; o Identifiar se um gereniador de grade deve ser utilizado e, em aso positivo, enaminhar a requisição a ele. Em aso negativo, a requisição é enaminhada a um módulo que exeuta as atividades em threads, podendo se aproveitar dos reursos de equipamentos multi-proessados, se disponíveis; o Monitorar a exeução das atividades na grade ou nas threads. À medida em que estas são onluídas, informar o término à implementação do padrão, para que este proeda onforme sua heurístia. 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 dos gereniadores de grade e 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. 63

78 Uma Arquitetura de Baixo Aoplamento 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 possam 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 utilizado algum que não possua tal reurso, omo Alhemi [38], 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 [38]. 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 35. 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. Consequentemente, 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. 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. 64

79 Uma Arquitetura de Baixo Aoplamento 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 Elementos Constituintes do Middleware A arquitetura da solução proposta define um middleware omposto por dois grupos de amadas: EGP/Exeutores Espeífios de Padrões e IPG/Exeutores para Gereniadores de Grades. A presença de dois grupos é importante aqui, pois ada um deles garante a abstração de um elemento diferente na exeução, aumentando o grau de desaoplamento, onforme desrito na Seção Exeutor Genério de Padrões (EGP) Oferee uma interfae omo serviço web para ser hamada pela apliação de e-siene, para submissão de atividades e onsulta quanto ao seu resultado. 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. 65

80 Uma Arquitetura de Baixo Aoplamento 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. O ódigo a seguir ilustra um exemplo de entrada que o EGP reebe da apliação de e-siene, ao submeter atividades para exeução: <WorkflowGrid EGP_URI=" Grid="Ourgrid" Pattern="PJC" ClientAddress=" "> <Attributes DynamiInstane="False" CanelAtivities="True" NumberOfReady="5" /> <ParallelAtivities> <ParallelAtivity AtivityId="1" Name="A1"> <Parameters> <Parameter ParameterId="1" Diretion="input" Type="ommand" Value="T1.sh 5 5" /> <Parameter ParameterId="2" Diretion="input" Type="file" Value="T1.sh" /> <Parameter ParameterId="3" Diretion="input" Type="file" Value="I1a.txt" /> <Parameter ParameterId="4" Diretion="input" Type="file" Value="I1b.txt" /> <Parameter ParameterId="5" Diretion="output" Type="file" Value="O1.zip" /> </Parameters> </ParallelAtivity> <ParallelAtivity AtivityId="n" Name="An"> <Parameters> <Parameter ParameterId="1" Diretion="input" Type="ommand" Value="Tn.sh " /> <Parameter ParameterId="2" Diretion="input" Type="file" Value="Tn.sh" /> <Parameter ParameterId="3" Diretion="input" Type="file" Value="In.txt" /> <Parameter ParameterId="4" Diretion="output" Type="file" Value="Ona.txt" /> <Parameter ParameterId="5" Diretion="output" Type="file" Value="Onb.zip" /> </Parameters> </ParallelAtivity> 66

81 Uma Arquitetura de Baixo Aoplamento </ParallelAtivities> </WorkflowGrid> No exemplo, o elemento WorkflowGrid identifia o uso do EGP om os seguintes atributos: EGP_URI: em que se enontra o EGP, que potenialmente pode estar em um equipamento remoto; Grid: india qual gereniador de grade deve ser utilizado. Para uso em equipamentos multi-proessados, sem grade, deve ser utilizado o valor Gridless ; Pattern: india que padrão de ontrole de fluxo deve ser utilizado; ClientAddress: endereço do servidor de arquivos que a apliação liente utiliza para armazenar arquivos de entrada e de saída. Os atributos do padrão indiado em Pattern são identifiados no elemento Attributes. Os itens deste elemento, bem omo todos os demais elementos desta representação em XML variam onforme o padrão em questão. Os desritos a seguir referem-se ao PJC: DynamiInstane (din na Seção 4.2): india se o padrão aeita a inlusão de novas instânias; NumberOfReady (n na Seção 4.2): india o número de atividades que preisam ser onluídas para a produção da saída o 1 (na Seção 4.2), enerrando o uso do PJC; CanelAtivities (an na Seção 4.2): india que proedimento adotar quanto às demais atividades em exeução, quando NumberOfReady atividades tenham sido onluídas. Se for true, anela tais atividades. Caso ontrário, não toma nenhuma medida adiional. O elemento ParallelAtivities é uma oleção de elementos ParallelAtivity, ada um representando uma atividade a ser exeutada paralelamente às demais, om os seguintes atributos: AtivityId: identifiador para uma atividade. É neessário para que o padrão seja posteriormente informado do término da exeução da atividade; Name: nome da atividade. É um atributo opional, que pode ser utilizado pelo usuário para armazenar alguma informação que lhe seja relevante. 67

82 Uma Arquitetura de Baixo Aoplamento Cada ParallelAtivity ontém uma oleção Parameters de parâmetros para a atividade. Cada parâmetro é denotado pelo elemento Parameter, que possui os seguintes atributos: ParameterId: identifiador do parâmetro; Diretion: india se parâmetro é de entrada ou de saída; Type: define um parâmetro omo sendo um arquivo ou omo o omando a ser exeutado pelo Exeutor para o Gereniador de Grade (EGG); Value: é o nome do arquivo ou o omando a ser exeutado. A ombinação dos atributos Diretion e Type permite identifiar os três tipos de parâmetros existentes: 1) arquivos de entrada; 2) arquivos de saída; 3) omando a ser exeutado pela atividade. Com relação ao tereiro tipo, vale a seguinte semântia: Uma vez que o omando a ser exeutado é também um arquivo, este preisa ser enviado para que o EGG possa utilizá-lo. Assim, deve existir um parâmetro om Type= file e Diretion= input, que orresponda a este arquivo. Neste exemplo, isto pode ser observado no segundo parâmetro de ada atividade; Para Type= ommand, o ampo Value ontém o omando e seus parâmetros no formato de adeia de arateres; Quando for utilizado o EGG para exeução sem grade, desrito na Seção , o ampo Value ontém apenas os parâmetros. Nesse aso, a bibliotea ontendo a implementação da lasse a ser hamada pelo EGG deve ser o primeiro parâmetro om Type= file e Diretion= input. Para representar múltiplas instânias de uma mesma atividade, deve haver tantas seções ParallelAtivity quanto for o número de instânias, sendo que estas podem ter arquivos de entrada, saída e parâmetros distintos. Com isso, o PJC permite que sejam exeutadas diversas atividades, sendo parte delas instânias de uma mesma atividade. Com relação à dinâmia deste exemplo, serão exeutadas paralelamente n atividades A 1,..., A n, sendo que o padrão deverá produzir sua saída quando quaisquer ino tiverem sido ompletadas. As demais atividades deverão ser notifiadas para que possam ser aneladas. O padrão a ser exeutado é o PJC, no gereniador de grade Ourgrid. A apliação que submeteu o XML para exeução reebe um identifiador únio que deve ser utilizado para posteriormente onsultar o resultado. 68

83 Uma Arquitetura de Baixo Aoplamento A partir do XML aima, o EGP onsultará o Mapa Padrão-Implementação, que possui o seguinte formato: <EGP> <onfiguration> <mapping> <Pj binding="netnamedpipebinding" uri="net.pipe://loalhost/pjengine/netnamedpipebinding" /> <OtherPatternUri binding="nettpbinding" uri="tp://loalhost:3040/otherpatternengine/tpbinding" /> </mapping> </onfiguration> </EGP> No mapa, o elemento Pj india onde se enontra a implementação do PJC. O elemento OtherPatternUri ilustra o loal da implementação de algum outro padrão. O ódigo a seguir ilustra o retorno devolvido pelo EGP à apliação de e- Siene, quando esta soliita o resultado, a partir do identifiador únio devolvido no proesso de submissão: <WorkflowGridResult> <ParallelAtivities> <ParallelAtivity AtivityId="1" Status="Completed" Result="10" /> <ParallelAtivity AtivityId="n" Status="Caneled" Result="" /> </ParallelAtivities> </WorkflowGridResult> De modo análogo ao da submissão de atividades, o elemento WorkflowGridResult ontém uma oleção ParallelAtivities. Esta possui um onjunto de elementos ParallelAtivity, ada um ontendo o resultado da exeução de uma atividade, denotado pelos seguintes atributos: AtivityId: identifiador da atividade, de mesmo valor do enviado no XML de submissão; Status: india a situação da atividade, podendo assumir os valores: o Running: a atividade está sendo exeutada; o Completed: exeução onluída; o Caneled: exeução anelada. Result: é uma adeia de arateres que ontém o resultado da exeução, que pode ser utilizado para omplementar os resultados onstantes dos arquivos de saída. 69

84 Uma Arquitetura de Baixo Aoplamento Exeutores Espeífios de Padrões (EEP) Esta amada ontém implementações para os padrões de ontrole de fluxo. Neste trabalho, ontém uma implementação para o PJC, embora tenha sido onebida para que seja estendida de modo a onter outras implementações, seja do PJC ou de outros padrões. 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 [19], um gereniador de workflows disponível omo parte da plataforma.net [26]. 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, a análise de anelamento e a exeução das tarefas para esse fim, não se benefiiam da presença de um gereniador de workflow. A arquitetura 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. O EEP interpreta o XML reebido, e então envia as atividades a serem exeutadas ao IPG. Além disso, o EEP deve ofereer uma interfae ao IGP, para que este informe o resultado das atividades, à medida que forem sendo onluídas. Desse modo, é possível para o EEP tomar deisões omo soliitar ao IPG o anelamento de atividades, quando NumberOfReady tiverem sido onluídas Integrador Padrão-Grade (IPG) Do mesmo modo que o Exeutor Genério de Padrões, EGP, este integrador é uma amada genéria. Neste aso, entretanto, abstrai o gereniador de grade dos Exeutores Espeífios de Padrões, EEPs. Um EEP envia um onjunto de atividades que devem ser exeutadas paralelamente, e então pede ao IPG que as exeute. 70

85 Uma Arquitetura de Baixo Aoplamento A partir da informação de que gereniador de grade utilizar, o IPG onsulta o Mapa Grade-Implementação, que ontém o endereço do Exeutor de Gereniador de Grade. Tal informação está presente no elemento Grid do XML enviado pela apliação de e-siene, que é repassado até o IPG. O formato do mapa é: <IPG> <onfiguration> <ProviderMapping> <GridLessProvider binding="netnamedpipebinding" uri="net.pipe://loalhost/eggthreadservie/netnamedpipebinding" /> <OurGridProvider binding="nettpbinding" uri="tp://loalhost:3040/ourgridprovider/tpbinding" /> <GlobusProvider binding="basihttpbinding" uri=" /> <AlhemiProvider binding="netnamedpipebinding" uri="tp://loalhost:3042/alhemiprovider/tpbinding" /> </ProviderMapping> <PatternMapping> <PjPattern binding="netnamedpipebinding" uri="net.pipe://loalhost/pjengine/netnamedpipebinding" /> </PatternMapping> </onfiguration> </IPG> No mapa, o elemento ProviderMapping identifia o endereço de ada gereniador de grade. O elemento GridLessProvider india uma implementação que exeuta as atividades paralelamente sem o uso de grade. O elemento PatternMapping india o endereço do EEP, para que o IPG seja apaz de informar o término da exeução das atividades. A presença desse elemento permite que a solução seja utilizada em modo assínrono, partiularmente interessante para fluxos om tarefas de longa duração, omo dias ou semanas Exeutores para Gereniadores de Grades (EGG) Para que um gereniador de grade possa ser integrado ao middleware, basta que ofereça alguma interfae para que seja utilizado por meio de programação, omo APIs (Appliation Programming Interfaes) ou serviços web, por exemplo. Esse é o aso de todos os gereniadores de grade de propósito geral desritos na Seção 3.2. No aso do Ourgrid, utilizado nos testes, é ofereida nativamente uma API em Java para omuniação om o gereniador. Desse modo, o EGG para o 71

86 Uma Arquitetura de Baixo Aoplamento Ourgrid é um serviço web, desenvolvido em Java, portanto podendo ser utilizado pelo IPG e também apaz de utilizar a API menionada. Com isso, aumenta-se o alane da solução, em termos de gereniadores de grade que podem ser utilizados. 5.2 Conlusão Além dos enários de exeução desritos na introdução deste apítulo, as atividades sendo paralelamente exeutadas podem ser de urta ou longa duração. Esse fator é determinante para a esolha do modo de omuniação - sínrono ou assínrono - entre as amadas do middleware e de lá para a apliação de e-siene e o gereniador de grade. No primeiro aso, ou seja, sínrono, ada amada deve esperar o retorno da amada seguinte para então prosseguir, fiando portanto bloqueada durante a exeução. Embora de implementação mais simples, esse modo de exeução restringe-se a atividades de urta duração. Isso porque um serviço utilizado sinronamente fiaria indisponível até o final de sua exeução, sendo impróprio para uso onorrente. Em enários om grades, nos quais é omum a exeução de atividades que podem durar de minutos a semanas, é indiado o uso de omuniação assínrona. Nesse aso, o ontrole de exeução pode ser realizado por um ou ambos os modelos a seguir: Modelo push: o serviço hamado assinronamente utiliza uma função de retorno (allbak) forneida pela apliação que o hamou para informar ativamente o término de sua exeução; Modelo pull: o serviço hamado assinronamente é passivo, ofereendo função para que a apliação hamadora possa onsultar o término da exeução. A omuniação da apliação de e-siene om o middleware é assínrona, seguindo o modelo pull. Esta opção foi realizada para reduzir impatos na apliação liente. Para o modelo push, a apliação teria de ofereer uma interfae para que o middleware pudesse hamar a função de allbak, o que aumentaria a omplexidade das modifiações a realizar para integrá-los. Neste apítulo foram desritas as amadas que ompõem esta arquitetura de baixo aoplamento, e os prinipais elementos expostos pelo middleware que implementa esta arquitetura, omo arquivos de onfiguração, entradas e saídas. No próximo apítulo esta arquitetura é detalhada do ponto de vista da implementação, ofereendo subsídio para a realização de testes para avaliar as hipóteses de desempenho, extensibilidade, independênia de plataforma e de baixo aoplamento até aqui apresentadas. 72

87 Considerações sobre a Implementação Capítulo 6 Considerações sobre a Implementação A arquitetura proposta desreve os prinipais elementos e a omuniação entre eles. Este apítulo 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; 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. 6.1 Ambiente de Desenvolvimento Com o objetivo de ilustrar a independênia de plataforma de desenvolvimento, os módulos desta solução foram desenvolvidos usando dois onjuntos de ferramentas e linguagens: Plataforma.NET: permite a riação de serviços a serem exeutados sobre o Windows. As ferramentas utilizadas foram: 73

88 Considerações sobre a Implementação o Mirosoft Visual Studio 2008 Professional Edition: ambiente de desenvolvimento; o Código desenvolvido na linguagem Visual C#, utilizando os seguintes reursos do.net Framework 3.5 [26]: Windows Communiation Foundation (WCF) [62] e Windows Workflow Foundation (WF) [19]. Este último foi utilizado para demonstrar omo integrar um gereniador de workflow à solução; o O serviço que ontém a implementação do PJC utiliza o Mirosoft SQL Server 2008 para armazenar o estado da exeução, garantindo esalabilidade ao uso do padrão; o Para aesso a dados e para geração de log de eventos foram utilizados bloos de apliação da Enterprise Library 4.1 [63]. Plataforma Java: permite a riação de serviços a serem exeutados em múltiplas plataformas. Foram desenvolvidos serviços para Windows e Linux. As ferramentas utilizadas foram: o NetBeans 3.5 [64]: ambiente de desenvolvimento; o Glassfish v3 [65]: servidor de apliações, usado para hospedar os serviços desenvolvidos em Java. o Código desenvolvido na liguagem Java, sobre a JRE Uso de Serviços Web - Interoperabilidade Com o objetivo de permitir que a solução seja utilizada nos ambientes heterogêneos desritos na seção anterior, optou-se pela disponibilização de interfaes em serviços web Comuniação om Serviços - Endpoints A omuniação entre um serviço e seu onsumidor é realizada por meio de estruturas denominadas endpoints. Estes ofereem aesso às funionalidades do serviço, e são onstituídos por três elementos: endereço, modo de assoiação e ontrato. Um endpoint pode ser espeifiado imperativamente, no ódigo tanto do serviço quanto da apliação onsumidora, ou delarativamente, usando-se arquivos de onfiguração. Com o objetivo de tornar o uso dos serviços web mais flexível e reduzir o aoplamento, optou-se por este segundo aso. Desse modo, o ódigo do middleware não preisa ser modifiado na eventualidade de mudança do endpoint de seus serviços. Por exemplo, pode ser neessário transferir um serviço para ser disponibilizado em outro endereço. Para isso, basta alterar o arquivo de onfiguração da apliação que utiliza o serviço. 74

89 Considerações sobre a Implementação Endereço do Serviço É uma URI (Uniform Resoure Identifier) que permite loalizar o servidor e a porta em que um serviço se enontra. Por exemplo, o Exeutor Genério de Padrões (EGP) poderia estar loalizado em: Assoiação ao Serviço - Bindings É um onjunto de onfigurações que determina omo o serviço e a apliação que o utiliza se omuniam. Dentre as onfigurações estão: o tipo de protoolo de transporte, omo HTTP, TCP ou Named Pipe; o formato de odifiação das mensagens, texto ou binário; o meanismo de segurança das mensagens, omo uso de Seure Sokets Layer (SSL) ou segurança SOAP. Os bindings indiam que espeifiações WS-* [66] devem ser utilizadas, podendo ainda se limitar ao Web Servies Basi Profile [67]. A Tabela 3 ompara os três tipos de bindings utilizados neste trabalho. Binding Tabela 3: omparação entre os bindings ofereidos pelos serviços implementados BasiHttpBinding WSHttpBinding NetNamedPipeBinding Interoperabilidade WS-Basi Profile WS-*.NET Esopo de Comuniação Formato de Mensagem Entre máquinas Entre máquinas Intra máquina Texto Texto Binário Segurança Não Mensagem Transporte Desempenho ++ + (menos efiiente) +++ (mais efiiente) Os reursos apresentados para ada binding orrespondem às suas onfigurações padrão. Algumas onsiderações om relação aos bindings: NetNamedPipeBinding: é o mais efiiente, otimizado em termos de tamanho e formato de mensagens. Entretanto, restringe-se à omuniação om serviços desenvolvidos om o WCF, portanto espeífios para a plataforma Windows. Além disso, permite omuniação apenas dentro de uma mesma máquina. Seu uso neste trabalho permite otimizar a omuniação entre os elementos do middleware que tenham sido desenvolvidos em Visual C#; 75

90 Considerações sobre a Implementação BasiHttpBinding: menos efiiente do que o anterior, permite a omuniação entre máquinas e entre plataformas. Na implementação, foi utilizado em dois asos: para omuniação entre a apliação de e-siene e o middleware; e entre o IPG (desenvolvido em Visual C#) e o Exeutor para Ourgrid (desenvolvido em Java). Entretanto, todos os demais serviços desenvolvidos usando Visual C# também disponibilizam este binding, o que permite a substituição de qualquer serviço por outra implementação, possivelmente realizada em outra plataforma; WSHttpBinding: é o menos efiiente dos três, uma vez que o tamanho das mensagens é maior, por inluir elementos de segurança. Todos os serviços desenvolvidos disponibilizam este tipo de binding, para permitir que os serviços sejam usados em enários om requisitos de segurança. A seleção por qual binding utilizar é realizada em arquivos de onfiguração Contrato É a interfae que o serviço implementa, e que pode ser disponibilizada por este na linguagem WSDL (Web Servies Desription Language). Trata-se de uma linguagem em formato XML, sendo independente da plataforma de desenvolvimento da apliação onsumidora. Para aesso ao WSDL de um serviço, adiiona-se o texto?wsdl ao final do endereço do serviço. Por exemplo, seja a interfae IEgp, disponibilizada pelo EGP onforme definição abaixo, em Visual C#: [ServieContrat()] publi interfae IEgp { [OperationContrat] string ExeuteWorkflow(string xml, string pattern); } // Outras operações Uma vez disponível omo serviço no endereço exemplifiado na Seção , é possível requisitar o WSDL do EGP utilizando-se o endereço: Esta requisição devolve o seguinte resultado, aqui apresentado apenas parialmente, a fim de simplifiar a leitura: <?xml version="1.0" enoding="utf-8"?> 76

91 Considerações sobre a Implementação <wsdl:definitions name="egpservie" targetnamespae=" > <wsdl:message name="iegp_exeuteworkflow_inputmessage"> <wsdl:part name="parameters" element="tns:exeuteworkflow" /> </wsdl:message> <wsdl:message name="iegp_exeuteworkflow_outputmessage"> <wsdl:part name="parameters" element="tns:exeuteworkflowresponse"/> </wsdl:message> <wsdl:porttype name="iegp"> <wsdl:operation name="exeuteworkflow"> <wsdl:input wsaw:ation=" message="tns:iegp_exeuteworkflow_inputmessage" /> <wsdl:output wsaw:ation=" message="tns:iegp_exeuteworkflow_outputmessage" /> </wsdl:operation> <!-- Outras operações --> </wsdl:porttype> <wsdl:binding name="basihttpbinding_iegp" type="tns:iegp"> <soap:binding transport=" /> <wsdl:operation name="exeuteworkflow"> <soap:operation soapation=" style="doument" /> <wsdl:input> <soap:body use="literal" /> </wsdl:input> <wsdl:output> <soap:body use="literal" /> </wsdl:output> </wsdl:operation> </wsdl:binding> <!-- Outros bindings --> <wsdl:servie name="egpservie"> <wsdl:port name="basihttpbinding_iegp" binding="tns:basihttpbinding_iegp"> <soap:address loation=" BasiHttpBinding"/> </wsdl:port> <!-- Outras portas --> </wsdl:servie> 77

92 Considerações sobre a Implementação </wsdl:definitions> Os elementos destaados em negrito apresentam as mensagens e endereços para hamadas das operações. O binding BasiHttpBinding_IEGP orresponde à disponibilização da interfae IEgp de aordo om o Web Servies Basi Profile. Na implementação foram riados outros bindings, omitidos na listagem aima Hospedagem de Serviços Web Para que um serviço web tenha seus endpoints ativos, ou seja, prontos para reeber requisições das apliações lientes, é neessário que seja inorporado a alguma apliação exeutável. Tal apliação é denominada hospedeira, e as possibilidades de hospedagem variam dependendo da plataforma. A mais omum é a hospedagem em servidores web, omo Apahe, Internet Information Server, Tomat ou Glassfish, por exemplo. A limitação desta forma, entretanto, é o fato de tais servidores web serem apazes de tratar apenas endpoints baseados em HTTP, omo o basihttpbinding ou o wshttpbinding. Para que seja possível ofereer outros bindings, omo o netnamedpipebinding, existem outras alternativas, omo apliações onsole ou serviços de ativação, ambos dependentes de plataforma. Nos testes desta solução foram utilizados: Glassfish, para hospedagem do serviço orrespondente ao Exeutor para o Ourgrid, desenvolvido em Java e hospedado em equipamento om Linux; Serviço no Windows, para hospedagem os demais serviços, desenvolvidos em Visual C# e que, adiionalmente aos bindings baseados em HTTP, ofereem binding baseado em Named Pipes. A disponibilização em servidores web é realizada ao implantar um serviço web no servidor, e não demanda esrita de ódigo adiional. É o que oorre no aso do uso do Glassfish. No entanto, para que um serviço Windows ou outro ontêiner seja utilizado, seu ódigo deve expliitamente arregar e desarregar tal serviço. O ódigo a seguir foi extraído do serviço Windows desrito aima: namespae WSHost { publi partial lass MiddlewareHost : ServieBase { ServieHost egpservie; ServieHost pjengineservie; ServieHost ipgservie; ServieHost eggthreadservie; 78

93 Considerações sobre a Implementação ServieHost eggourgridstubservie; publi MiddlewareHost() { } // Start the web servies hosts proteted override void OnStart(string[] args) { egpservie = new ServieHost(typeof(EgpServie)); egpservie.open(); pjengineservie = new ServieHost(typeof(PJCEngineServie)); pjengineservie.open(); ipgservie = new ServieHost(typeof(IpgServie)); ipgservie.open(); eggthreadservie = new ServieHost(typeof(EggThreadServie)); eggthreadservie.open(); } eggourgridstubservie = new ServieHost(typeof(EggOurgridStubServie)); eggourgridstubservie.open(); } // Stop web servies hosts proteted override void OnStop() { eggourgridstubservie.close(); eggthreadservie.close(); ipgservie.close(); pjengineservie.close(); egpservie.close(); } stati lass Program { // Starts the Middleware Host servie. 79

94 Considerações sobre a Implementação } } stati void Main() { ServieBase[] ServiesToRun; ServiesToRun = new ServieBase[] { new MiddlewareHost() }; ServieBase.Run(ServiesToRun); } A lasse ServieHost é utilizada para arregar serviços web e disponibilizar seus endpoints. Conforme desrito em 6.2.1, isso pode ser feito imperativamente ou delarativamente. Neste último aso tem-se um menor aoplamento, uma vez que modifiações nos endpoints podem ser realizadas sem a neessidade de reompilação da apliação hospedeira. Para tanto, esta baseia-se na definição em XML dos endpoints dos serviços web. O ódigo abaixo é parte do arquivo de onfiguração que a apliação hospedeira utiliza para arregar os serviços do middleware. Vale notar a disponibilização de dois endpoints, om endereços e bindings distintos. Todavia, o ontrato é o mesmo, ou seja, as assinaturas dos métodos e os tipos empregados pelo liente são os mesmos, independentemente do endpoint utilizado. <system.serviemodel> <servies> <servie name="wfg.egp.servies.egpservie"> <endpoint address= " binding="basihttpbinding" ontrat="wfg.egp.interfaes.iegp" /> <endpoint address="net.pipe://loalhost/egpservie" binding="netnamedpipebinding" ontrat="wfg.egp.interfaes.iegp" /> </servie> <!-- Outros serviços --> </servies> 80

95 Considerações sobre a Implementação </system.serviemodel> O EGP, ilustrado aima, pode ser aessado por uma apliação liente que utilize o basihttpbinding, de modo independente de plataforma de desenvolvimento ou exeução. Assim, é possível ter a apliação liente desenvolvida em Java, Visual C#, C++ ou outra linguagem que dê suporte à utilização de serviços web. Além disso, pode ser exeutada em Linux, Windows ou outro sistema operaional. Adiionalmente, pode-se reduzir a arga de omuniação entre a apliação e o EGP utilizando-se o netnamedpipebinding. Para isso, é neessário que a apliação seja desenvolvida em.net e exeutada na mesma máquina em que se enontra o serviço Proxies e a Utilização de Endpoints As operações ofereidas pelos serviços podem ser identifiadas em tempo de exeução, a partir da definição em WSDL. Entretanto, tal uso é omplexo, e não oferee reursos para análise de ódigo em tempo de ompilação. Para ontornar essas questões, as implementações de serviços web ofereem geradores de ódigo liente que, a partir do WSDL de um serviço, onstroem proxies - lasses que enapsulam omplexidades das espeifiações de serviços web. O ódigo abaixo é parte do proxy gerado pelo Visual Studio, a partir do WSDL do EGP apresentado na Seção : // // <auto-generated> // This ode was generated by a tool. // Runtime Version: // // Changes to this file may ause inorret behavior and will be lost // if the ode is regenerated. // </auto-generated> // [System.CodeDom.Compiler.GeneratedCodeAttribute("System.ServieModel", " ")] [System.ServieModel.ServieContratAttribute(ConfigurationName="IEgp")] publi interfae IEgp { 81

96 Considerações sobre a Implementação [System.ServieModel.OperationContratAttribute( Ation=" ReplyAtion=" string ExeuteWorkflow(string xml, string pattern); } // Outras operações [System.CodeDom.Compiler.GeneratedCodeAttribute("System.ServieModel", " ")] publi interfae IEgpChannel : IEgp, System.ServieModel.IClientChannel { } [System.Diagnostis.DebuggerStepThroughAttribute()] [System.CodeDom.Compiler.GeneratedCodeAttribute("System.ServieModel", " ")] publi partial lass EgpClient : System.ServieModel.ClientBase<IEgp>, IEgp { publi EgpClient() { } publi EgpClient(string endpointconfigurationname) : base(endpointconfigurationname) { } publi EgpClient(string endpointconfigurationname, string remoteaddress) : base(endpointconfigurationname, remoteaddress) { } publi EgpClient(string endpointconfigurationname, System.ServieModel.EndpointAddress remoteaddress) : base(endpointconfigurationname, remoteaddress) { } publi EgpClient(System.ServieModel.Channels.Binding binding, System.ServieModel.EndpointAddress remoteaddress) : 82

97 Considerações sobre a Implementação { } base(binding, remoteaddress) publi string ExeuteWorkflow(string xml, string pattern) { return base.channel.exeuteworkflow(xml, pattern); } } // Outros métodos A partir do proxy aima, a apliação liente pode utilizar a interfae IEGP e a lasse EGPClient, sem a neessidade de onheer os detalhes de omuniação om a infra-estrutura de serviços web, omo a presença de anais (hannel), por exemplo. O treho de ódigo a seguir ilustra omo esse proxy pode ser utilizado para instaniar o serviço web e utilizar o método ExeuteWorkflow: publi string Exeute(string xml, string pattern, string egpuri, string egpbinding) { Binding l_egpbinding = null; EgpClient l_egp; swith (egpbinding) { ase "BasiHttpBinding : l_egpbinding = new BasiHttpBinding(); break; ase "NetNamedPipeBinding": l_egpbinding = new NetNamedPipeBinding(); break; } } l_egp = new EgpClient(l_egpBinding, new EndpointAddress(egpUri)); return l_egp.exeuteworkflow(xml, pattern); 83

98 Considerações sobre a Implementação 6.3 Comuniação entre Camadas Toda omuniação entre os elementos da solução, desde a apliação liente (e-siene) até o Exeutor para Gereniador de Grade (EGG) utilizado, é realizada por meio do uso de serviços web, sendo algumas hamadas sínronas e outras assínronas. O diagrama da Figura 36 ilustra a seqüênia de mensagens e hamadas quando do envio de requisição a partir da apliação, para uso do PJC no Ourgrid. No diagrama foi utilizada a seguinte onvenção: Flehas om linha heia ( ): hamada; Flehas om linhas traejadas ( ): retorno; Flehas om terminação vazada superior ( ): omuniação assínrona; Retiênias (...): indiam uma série de hamadas do mesmo tipo. Por exemplo, diversas hamadas ao método RunJob entre o EGG e o Gereniador da Grade, para submissão das atividades à grade para exeução. A dinâmia ilustrada na figura é a seguinte: 1. A apliação utiliza o método ExeuteWorkflow do EGP, que identifia o Exeutor Espeífio de Padrão (EEP) a ser utilizado e enaminha a ele a requisição e a representação em XML das atividades a exeutar, de aordo om o formato desrito na Seção ; 2. O EEP, neste aso para o PJC, assinronamente utiliza o método Exeute do Integrador Padrão-Grade (IPG) para envio das atividades, agora representadas no objeto Job. Além disso, o padrão gera um identifiador únio para a requisição, que é repassado pelo EGP à apliação liente, que pode prosseguir seu fluxo. Desse modo, a implementação realizada para o PJC funiona assinronamente em relação à apliação liente, evitando que esta fique bloqueada até o final da exeução; 3. No IPG é identifiado o Exeutor para Gereniador de Grade (EGG) a ser utilizado, e também são realizadas transferênias de arquivos de entrada que serão neessários para o proessamento da tarefa; 4. O EGG então utiliza método nativo do Gereniador de Grade empregado, para envio da tarefa a ser exeutada. Neste exemplo, é o método AddJob, disponibilizado pelo Ourgrid; 5. Assinronamente, o EGG soliita ao Gereniador de Grade que proesse paralelamente as tarefas enviadas. Para o Ourgrid, é o método RunJob; 84

99 Considerações sobre a Implementação 6. Quando uma tarefa for onluída, o EGG aiona o IPG, e de lá o EEP, para informar o término da exeução da tarefa; 7. O padrão (EEP) prossegue em sua heurístia. Para o PJC, é verifiado se o número de atividades a ser onluído foi atingido. Em aso positivo, se as demais atividades tiverem que ser aneladas, envia ao IPG essa soliitação, om o método CanelAll, que é repassado até o EEG para o Ourgrid, que então utiliza o método CanelJob. A qualquer tempo, após reeber o identifiador da requisição, a apliação liente pode utilizar o método IsExeuting (que não onsta da figura) do EGP, para questionar se a exeução do padrão está onluída. Além disso, o liente pode soliitar o estado das atividades de um job, utilizando o método GetWorkflowState do EGP, que devolve uma representação em XML, onforme desrito na Seção

100 Considerações sobre a Implementação Apliação de e-siene EGP EEP (PJC) IPG EGG (Ourgrid) Gereniador de Grade ExeuteWorkflow ExeutePattern workflowid workflowid ExeutePattern Exeute Exeute ExeuteAsyn RunJob UpdateWorkflowStatus... UpdateWorkflowStatus UpdateWorkflowStatus... UpdateWorkflowStatus... RunJob CanelAll UpdateWorkflowStatus... UpdateWorkflowStatus CanelAll UpdateWorkflowStatus... UpdateWorkflowStatus CanelJob... CanelJob Figura 36: diagrama de seqüênia (UML) da requisição de exeução do PJC no Ourgrid As seções a seguir detalham as interfaes de omuniação disponibilizadas em ada serviço Relação entre a Apliação, o Gereniador de Workflow e o Gereniador de Grade A relação entre a Apliação de e-siene, o Gereniador de Workflow e o Gereniador de Grade omumente se enquadra em um dentre os seguintes enários: 86

101 Considerações sobre a Implementação A apliação não utiliza Gereniador de Workflow e utiliza Gereniador de Grade: neste aso, a apliação utiliza reursos do Gereniador de Grade, que podem ser APIs ou serviços web, por exemplo. Desse modo, a apliação torna-se espeífia para uso desse gereniador, dado o alto aoplamento entre eles. A substituição ou utilização onomitante om outros gereniadores é geralmente trabalhosa e omplexa, demandando onheimentos espeífios por parte do desenvolvedor da apliação; A apliação utiliza Gereniador de Workflow e não utiliza Gereniador de Grade. Este enário geralmente se aplia para tornar mais flexível a modifiação em fluxos de exeução, em que não há neessidade de omputação distribuída. Aplia-se também para o aso de paralelismo em equipamentos om múltiplos proessadores, se houver neessidade de alto desempenho; A apliação utiliza Gereniadores de Workflow e de Grade. Este enário pode ser dividido em dois, dependendo da integração entre os gereniadores: o Quando não há integração, ou seja, os gereniadores são utilizados diretamente pela apliação. Aqui o aoplamento entre a apliação e os gereniadores é o mais alto dentre todos os enários apresentados; o Quando há integração. Neste aso, a apliação utiliza onstruções de paralelização do gereniador de workflow e este se omunia om o gereniador de grade, fazendo a abstração e, portanto, o desaoplamento entre a apliação e o gereniador de grade. No entanto, as soluções analisadas neste estudo e desritas no Capítulo 3 apresentam alto aoplamento entre os gereniadores de workflow e de grades. Os servios do middleware, ujas interfaes são desritas nas próximas seções, promovem o desaoplamento desses elementos, permitindo que sejam utilizados em quaisquer dos enários aima Interfae Disponibilizada pelo EGP O EGP oferee a interfae IEgp, exposta no serviço web EpgServie, para reeber soliitações de exeução de padrões. Essa interfae possui três operações, om a seguinte semântia: ExeuteWorkflow: reebe a representação em XML do padrão a ser utilizado, onforme esquema definido na Seção Esta operação onsulta o arquivo de onfiguração do EGP e, enaminha a requisição ao EEP orrespondente ao padrão informado no atributo Pattern do elemento WorkflowGrid do XML, onforme 87

102 Considerações sobre a Implementação exemplifiado na Seção Devolve um identifiador para ser utilizado pela apliação liente nas demais operações; IsExeutingWorkflow: reebe o identifiador de uma soliitação de exeução de padrão, e devolve um valor booleano que india o término ou não da exeução daquele; GetWorkflowState: reebe o identifiador de uma soliitação de exeução de um padrão, e devolve uma representação em XML da situação das atividades do padrão submetido para exeução, onforme esquema definido na Seção A geração de identifiador únio pela operação ExeuteWorkflow garante o isolamento entre exeuções de padrões. Desse modo, resolve-se a questão de interferênia entre exeuções desrita em , om o mesmo resultado, enquanto isolamento, que a solução baseada em bloqueios proposta por Russell et al em [2]. Entretando, uma implementação sem bloqueios permite que o padrão seja exeutado de modo assínrono, resultando em maior disponibilidade Interfae entre o EGP e os EEPs O EGP atua omo uma ponte genéria entre a apliação e o EEP do padrão sendo hamado, omo o PJC. Para garantir essa generalidade, o EEP deve onter as operações da interfae IEepEgp: ExeutePattern: reebe do EGP a representação em XML do padrão e o identifiador únio para posteriores onsultas da situação da exeução do padrão. Esta operação é assínrona, e realiza as seguintes tarefas: o Constrói uma instânia da lasse Job: uma representação do padrão reebido, desrevendo o onjunto de atividades a serem exeutadas paralelamente - essa lasse é apresentada no Apêndie A; o Persiste o objeto Job em bano de dados, para ganho de esalabilidade e tolerânia a falhas. O modelo de dados e a definição dos proedimentos para aesso a ele são apresentados no Apêndie B; o Enaminha o objeto Job, sem os elementos espeífios do padrão, para o IPG. IsExeutingPattern: reebe o identifiador de uma soliitação de exeução de padrão, onsulta o bano de dados e devolve um valor booleano que india o término ou não da exeução do padrão; 88

103 Considerações sobre a Implementação GetPatternState: reebe o identifiador de uma soliitação de exeução de um padrão, e devolve uma representação em XML da situação das atividades do padrão submetido para exeução, onforme esquema definido na Seção No aso do PJC, essa interfae é ofereida ao EGP no serviço web EepPjServie. A exeução assínrona segue o modelo pull, reduzindo exigênias sobre a apliação liente, onforme desrito na Seção 5.2. A importânia do omportamento assínrono ser implementado no EEP, permite que haja EEPs sínronos ou assínronos, e essa deisão deve ser do EEP. Caso o assinronismo fosse implementado no EGP, todos os padrões possuiriam omportamento assínrono, restringindo a solução a este enário. Quanto à persistênia em bano de dados desrita aima, ela é espeífia do PJC, podendo não existir na implementação de outros EEPs que sejam integrados ao middleware Interfaes entre os EEPs e o IPG Os EEPs e o IPG se omuniam em duas vias: Ida: quando o EEP utiliza serviços do IPG. Nesse aso, o EEP tem à sua disposição as operações da interfae IIpgEep, implementadas pelo IPG e ofereidas no serviço IpgServie: o Exeute: para soliitação de exeução de um padrão. Reebe uma instânia da lasse Job. Então providenia o envio dos arquivos de entrada neessários para exeução das atividades do job, identifia o Exeutor para Gereniador de Grade (EGG) a utilizar, e enaminha a requisição a este; o CanelAll: identifia o EGG a utilizar e enaminha soliitação para anelamento de todas as atividades de um job, que não tenham sido onluídas. Volta: quando o IPG utiliza serviços do EEP. Nesse aso, o IPG utiliza a seguinte operação da interfae IEepIpg, na implementação do EEP, ofereida no serviço web EepPjServie, no aso do PJC: o UpdatePatternState: reebe o resultado da exeução de uma atividade e atualiza o bano de dados. Então, de aordo om a heurístia do padrão, deide o próximo passo a realizar. Para o PJC, esse passo pode ser o anelamento das atividades que não foram onluídas. Nesse aso, o EEP então utiliza a operação CanelAll desrita aima. 89

104 Considerações sobre a Implementação Interfaes entre o IPG e os EGGs Deve haver uma implementação de Exeutor para ada Gereniador de Grade (EGG) que se desejar integrar à solução. A seleção deste exeutor é realizada pelo IPG usando um arquivo de onfiguração, o Mapa Grade- Implementação, onforme desrito e exemplifiado na Seção Para que o IPG e o EGG se omuniquem existem duas interfaes, usadas em função da via de omuniação: Ida: quando o IPG utiliza serviços do EGG. Nesse aso, o IPG utiliza uma das seguintes operações da interfae IEggIpg, ofereidas nesta implementação pelos serviços EggOurgridServie (no aso do Ourgrid) e EggThreadServie (no aso de não haver gereniador de grade, em que o atributo Grid do elemento WorkflowGrid possui o valor Gridless, onforme desrito na Seção ): o Exeute: para soliitação de exeução paralela de um onjunto de atividades. Reebe uma instânia da lasse Job. Então utiliza elementos espeífios do gereniador de grade para proeder à submissão das atividades para a grade - ou então threads, no aso do EggThreadServie. Essa submissão é realizada assinronamente. Dependendo do gereniador de grade esolhido é utilizado o modelo push ou pull para monitorar o término da exeução de ada atividade. Para o Ourgrid, é usado o modelo pull. Já o EggThreadServie utiliza o modelo push; o CanelAll: a partir do identifiador do job, soliita ao gereniador da grade o anelamento de todas as atividades que não tiverem sido onluídas. Volta: quando o EGG utiliza serviços do IPG. Nesse aso, o EGG utiliza a seguinte operação da interfae IIpgEgg, na implementação do IPG, ofereida no serviço web IpgServie: o UpdateWorkflowState: hamado pelo EGG para omuniar o resultado da exeução de uma atividade, tenha sido ela ompletada ou anelada Comuniação entre o EGG e o Gereniador de Grade Cada EGG é responsável por submeter as atividades ao gereniador de grade e ontrolar sua exeução. No entanto, a submissão das atividades aos nós da grade, bem omo o envio e reepção de arquivos de entrada e saída aos 90

105 Considerações sobre a Implementação nós, neessários à exeução as atividades, são responsabilidade do gereniador da grade. Assim, esta solução onsidera as seguintes responsabilidades: O middleware (IPG) é responsável por transferir os arquivos de entrada, de um job do servidor de arquivos onde se enontra a apliação liente, ao servidor de arquivos onde se loalizam o serviço ou API ofereidos pelo gereniador de grade e o EGG para este gereniador; O Gereniador de Grade é responsável por enviar esses arquivos aos nós da grade, onde as atividades serão exeutadas; O Gereniador de Grade deve transferir os arquivos produzidos pela exeução das atividades nos nós da grade para loal espeifiado pelo EGG; O IPG então é responsável por repassar os arquivos de saída ao servidor de arquivos onde estiver a apliação liente. Alguns Gereniadores de Grade possuem onstruções para exeução de fluxos. Entretanto, as implementações pesquisadas, omo Prodan em [43], 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. Como parte desta implementação, foram onstruídos dois EGGs, desritos a seguir EGG para o Ourgrid Este EGG omunia-se om o MyGrid (desrito na Seção 3.2.3) que, por sua vez, é o responsável pela omuniação om os nós da grade. Ao ontrário dos demais serviços web, desenvolvidos utilizando Visual C#, este EGG foi desenvolvido em Java, a fim de permitir a omuniação om o Ourgrid, por meio da utilização de API em Java. A esolha do Ourgrid e a implementação deste EGG possibilitam também demonstrar a interoperabilidade dos serviços desenvolvidos em diferentes plataformas. Assim omo todo EGG, este deve implementar a interfae IEggIpg desrita na Seção 6.3.5, a ser disponibilizada ao IPG por intermédio do proxy EggIpgClient, apresentado no Apêndie A, gerado pela ferramenta de desenvolvimento. Todavia, diferentes ferramentas geram implementações diferentes, ou seja, o proxy gerado pelo Visual Studio é diferente do proxy gerado pelo NetBeans. Isso não inorre em maiores preoupações em um enário de alto aoplamento em que, durante o desenvolvimento da apliação que utiliza o serviço web, é riada uma referênia a este e o proxy é então gerado. Nesse aso, quando outra implementação do serviço for desenvolvida, a apliação liente deve ser atualizada para que utilize o novo proxy. 91

106 Considerações sobre a Implementação Entretanto, no enário de baixo aoplamento aqui proposto, esse proesso de desenvolvimento não é apropriado. A inlusão de novos EGGs não pode demandar reompilação do IPG. Assim, o mesmo proxy deve poder ser utilizado pelo IPG para aesso a qualquer EGG. Para soluionar essa questão, foi riada uma implementação de um serviço web na mesma plataforma de desenvolvimento do IPG, e que expõe a interfae IEggIpg. Essa implementação, hamada Stub, deve ser forneida em onjunto om o EGG, e seu únio papel é viabilizar a omuniação entre plataformas. A Figura 37 apresenta a relação entre o IPG, o Stub e o EGG. IPG (Visual C#) EGG Stub (Visual C#) EGG (Visual C#) EGG (Java) Figura 37: relação entre o IPG, o Stub para EGG e a implementação dos EGGs Vale notar que, aso o IPG seja substituído por implementação em uma plataforma X (Java, por exemplo), os EGGs desenvolvidos em plataformas diferentes daquela (Visual C#, COBOL,...) devem ser aessados pelo IPG através de Stubs desenvolvidos na plataforma X EGG para Exeução sem Grade Este EGG, implementado usando Visual C#, utiliza threads para exeutar as atividades de um job. O ódigo para exeução de ada atividade deve estar em uma bibliotea de ligação dinâmia (DLL) esrita em Visual C#, que implemente a interfae ITask abaixo: namespae IThreadStub { 92

107 Considerações sobre a Implementação } publi interfae ITask { string Exeute(Parameter[] params); } Além disso, para que seja possível a omuniação om o EGG no que diz respeito ao aompanhamento da exeução da atividade e para o envio de omando de anelamento, essa bibliotea deve onter o seguinte ódigo mínimo: publi lass Task : ITask { // true when running and false otherwise (ompleted) private bool m_running = true; // This destrutor will be alled when finishing the thread // used to dispath Exeute. // It ould be for both: ompleted or when being anelled ~Task() { // This test allows to know if this instane is being // destroyed as result of anelling or not if (m_running) // Canelling ations else // Completed (post exeution) ations } // To be alled by the EGG to run the ativity publi string Exeute(Parameter[] params) { // Put your ode to do the ativity here! } } // After ompleting, set m_running to indiate // that proessing has been finished m_running = false; return // string to be returned; 93

108 Considerações sobre a Implementação O destrutor da lasse Task permite que esta tenha onheimento de seu eventual anelamento, útil para exeução de ações de desfazimento previstas no PJC, ou outro padrão que envie omando de anelamento. O método Exeute, por sua vez, é onde deve ser inserido o ódigo a exeutar. Reebe os parâmetros da atividade em questão, podendo então ler e gravar arquivos de entrada e saída, respetivamente. Opionalmente, o método pode devolver uma representação em texto do resultado da exeução. Este reurso é partiularmente útil para a exeução paralela de álulos que devolvam valores simples Desenvolvimento de Outros EGGs Com base no ódigo dos dois EGGs anteriores, o desenvolvimento de outros EGGs torna-se uma tarefa que depende do onheimento dos reursos de ada gereniador de grade ou tipo de atividade a exeutar. Por exemplo, é possível o desenvolvimento de outros EGGs que não demandem uso de grade, para serem mais genérios do que o apresentado na Seção , ou ainda para atenderem a neessidades espeífias. Alguns enários em que tais EGGs seriam neessários são: EGG para atividades desenvolvidas em Java: deve reeber o aminho de um arquivo om extensão lass ou jar e então o EGG o oloa em exeução; EGG para atividades que utilizem CORBA: nesse aso, o EGG pode utilizar as onfigurações de POA mais adequadas antes de aionar o objeto ou omponente CORBA; EGG para exeução de atividades em linha de omando: genério por permitir uma grande variedade de omandos. Entretanto, limitase a exeução de omandos que variam em função do sistema operaional em que o EGG é exeutado. Cada novo EGG deve forneer doumentação que desreva os enários em que pode ser utilizado, bem omo suas restrições. Por exemplo, um EGG para linha de omando poderia não permitir reepção de omando de anelamento, o que potenialmente o tornaria inompatível ou, ao menos, limitado, para uso om o PJC. Os EGGs desritos nas seções anteriores são ompatíveis om todas as funionalidades do PJC. 6.4 Transferênia de Arquivos É o meanismo mais omum e simples para envio e reepção de dados aos nós das grades, utilizados por diversos gereniadores, onforme pode ser 94

109 Considerações sobre a Implementação observado nos apresentados na Seção 3.2. Por esse motivo, foi esolhido aqui também. Para que o envio de arquivos seja feito de modo seguro e independentemente da apliação de e-siene ter aesso direto ao servidor onde estiver o Gereniador da Grade, o middleware assumiu essa tarefa. O IPG é a amada responsável por esse tratamento de arquivos pois, desse modo, garante-se que nem os EEPs nem os EGGs tenham que onheer esse proesso. Dessa forma, um novo EEP ou um novo EGG não neessitam tratar arquivos. No middleware, aredita-se que essas amadas sejam as que virão a sofrer mais modifiações, prinipalmente om a inlusão de EEPs e EGGs. Já o IPG deve ser modifiado apenas para orreções de possíveis erros de implementação, para inlusão de tratamento de requisitos não funionais, omo a tolerânia a falhas, ou ainda para ser substituído por implementação em outra plataforma, omo Java, por exemplo, aso se deseje utilizar o IPG sobre o Linux. O tratamento de arquivos deve utilizar protoolos abertos, que possuam implementação para os sistemas operaionais sobre os quais os elementos da solução serão exeutados. Espeifiamente, apliação de e-siene, IPG e EGG/Gereniador de Grade. Por isso, optou-se pelo uso de Seure Shell (SSH) [68] e Seure Copy (SCP). Por onstrução, o equipamento onde a apliação de e-siene é exeutada deve ser o servidor de arquivos de entrada e saída. Do mesmo modo, o EGG deve ser exeutado no mesmo equipamento do elemento do Gereniador de Grade utilizado para submissão de atividades (por exemplo, o MyGrid, no aso do Ourgrid). A Figura 38 ilustra a omuniação entre esses equipamentos. Servidor SSH 1 (apliação de e- Siene) 1 - Arquivos de entrada para o Job 2 - Arquivos de entrada para o Job Servidor SSH 2 (EGG e MyGrid) 4 - Arquivos de saída de uma atividade Servidor de arquivos om IPG 3 - Arquivos de saída de uma atividade Figura 38: transferênia de arquivos entre os servidores O IPG iniia a onexão SSH para troa de arquivos. Cada servidor de arquivos deve possuir o serviço servidor do SSH. As flehas na figura indiam o fluxo de arquivos, e são realizadas as seguintes operações: 1. Em uma únia onexão SSH é enviado um omando de transferênia para ada arquivo de entrada; 95

110 Considerações sobre a Implementação 2. Em uma únia onexão SSH é enviado um únio omando para transferir todos os arquivos de entrada; 3. Quando ada atividade for onluída, é aberta uma onexão SSH e é enviado um omando para transferir todos os arquivos de saída de uma únia vez; 4. Para ada atividade onluída, é aberta uma onexão SSH e é enviado um omando de transferênia para ada arquivo de saída. Desse modo, é minimizado o número de onexões e omandos para transferênia de arquivos, reduzindo o impato sobre o desempenho da solução, prinipalmente para quando for utilizado em enários em que o tempo de exeução de atividades for da ordem de segundos, mesma ordem do tempo para estabeleimento de onexão SSH. Para a implementação e testes, foi usado o OpenSSH [69], tanto no Linux quanto no Windows. 6.5 Baixo Aoplamento Extensibilidade e Flexibilidade A arquitetura proposta foi implementada utilizando modelo de baixo aoplamento (loose oupling) baseado em serviços web, a fim de garantir maior flexibilidade e extensibilidade à solução. Uma vez definidas as interfaes de omuniação om os diversos elementos externos, e entre as amadas, onforme apresentado na Seção 6.3, estes podem ser substituídos ou aresidos resultando baixo impato no sistema e sua exeução. Como exemplos do baixo aoplamento entre as amadas, estão: Utilização do EGP para desaoplamento entre a apliação de e- Siene e a implementação de padrões (EEPs). Desse modo, a utilização de novos EEPs pela apliação requer somente a atualização do atributo Pattern no XML enviado ao EGP; Do mesmo modo, a utilização de EGGs demanda apenas a atualização do atributo Grid no mesmo XML; A inlusão de um novo EEP no middleware, por sua vez, exige atualização no Mapa Padrão-Implementação (Seção ); Analogamente, a inlusão de novo EGG exige atualização no Mapa Grade-Implementação (Seção ); A substituição da implementação de uma amada pode ser realizada sem modifiar as demais amadas do middleware, aso o endereço em seus endpoints não seja alterado; ou as modifiações nas amadas adjaentes se restringem à atualização desses endereços. 96

111 Considerações sobre a Implementação Por exemplo, pode ser inluído no IPG tratamento espeífio para transferênia de arquivos quando todos os equipamentos envolvidos estiverem na mesma rede loal, aumentando signifiativamente o desempenho em relação ao uso de SCP. Isso pode ser feito sem alterações nas amadas adjaentes. Para atender a um maior número de enários, resultando em uma solução mais flexível, a arquitetura proposta permite a inlusão ou modifiação de elementos do middleware, onforme desrito nos itens aima. 6.6 Integração a um Gereniador de Workflow Conforme desrito na introdução do Capítulo 5, a apliação pode ou não utilizar um Gereniador de Workflow para representar e exeutar as atividades envolvidas em seus proessos. A implementação realizada pode ser apliada a esses dois enários. O primeiro aso, isto é, sem uso de gereniador de workflow, exige que a representação em XML das atividades a serem exeutadas paralelamente seja gerada pela apliação de e-siene e enviada ao EGP. Embora pouo automatizada - o desenvolvedor da apliação deve, aqui, odifiar a riação do XML - essa tarefa é de baixa omplexidade. Esta solução é partiularmente indiada quando já houver uma apliação om interfae gráfia para que o ientista onfigure as atividades que deverão ser exeutadas paralelamente. É o que oorre om o uso da Load Generation Tool, desrita na Seção e om o uso do GridSphere, apresentado na Seção Já o segundo aso permite a extensão dos padrões ofereidos pelo Gereniador de Workflow a ser ou sendo utilizado. Para a implementação de apliações para testes, foi seleionado o Windows Workflow Foundation (WF) [19], um gereniador de workflows gratuito e extensível. Contudo, vale notar que a solução proposta pode ser integrada a qualquer gereniador de workflow que esteja em uso, desde que permita a exeução de atividades que hamem serviços web. O WF permite a inlusão de novas atividades, ditas personalizadas. Estas podem ser utilizadas para grafiamente representar os elementos a serem exeutados omo parte dos passos em um workflow. Foi, então, desenvolvida uma atividade personalizada, para representar o PJC. Essa atividade é a responsável por riar o XML e por enviá-lo ao EGP. No toante à representação gráfia dos padrões, ao invés de utilizar Redes de Petri Coloridas, omo Aalst et al [14] e Russell et al [2], o WF utiliza uma variação de workflow graphs, baseado na arquitetura WASA (Workflow-based arhiteture to support Sientifi Appliations), desrita por Medeiros [70] omo uma solução para apliações ientífias baseadas em workflows e utilizada em 97

112 Considerações sobre a Implementação produtos omeriais omo IBM MQSeries Workflow e InConert. A Figura 39 apresenta a representação de uma máquina de estados simples, omposta por três atividades para iniialização, exeução e onlusão. Esta apliação é hamada WorkflowPJC, e foi utilizada para realização de testes funionais e para testes de integração do middleware a gereniadores de workflow, desritos no Capítulo 7. Figura 39: representação de uma máquina de estados simples utilizando workflow graphs om WF A atividade RealizaTestesEmParalelo utiliza a atividade personalizada PJC, para representação gráfia das atividades a serem exeutadas paralelamente, ilustrada na Figura 40. O PJC está destaado, e podem ser observadas as propriedades de exeução, ao lado direito: CanelAtivities; DynamiInstane; 98

113 Considerações sobre a Implementação EGP_URI; Grid; NumberOfReady; Pattern. Essas propriedades orrespondem aos atributos da representação em XML, desritos na Seção Figura 40: representação do PJC em workflow graphs 99

114 Considerações sobre a Implementação 6.7 Conlusão Este apítulo apresentou os elementos implementados, uja omuniação baseia-se em serviços web. Também desreveu omo é realizada a transferênia de arquivos, omum em enários de utilização de gereniadores de grades. Durante o desenvolvimento da implementação, esses dois fatores apresentaram-se omo os mais relevantes em termos de impato no desempenho do middleware. Isso deveu-se ao fato da 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, apresentar um usto em termos de desempenho. Por esse motivo, o próximo apítulo desreve um onjunto de testes que medem o impato que o uso de serviços web e a transferênia de arquivos produzem sobre o desempenho. Além disso, são testadas as funionalidades da implementação, e outros elementos não funionais, omo extensibilidade, independênia de plataforma e baixo aoplamento. 100

115 Testes e Resultados Obtidos Capítulo 7 Testes e Resultados Obtidos No intuito de validar a implementação e as hipóteses desritas neste texto, foi realizado um onjunto de testes, que podem ser divididos nos seguintes grupos: Testes funionais, para avaliar o omportamento do middleware quanto à orretude de resultados; Testes de desempenho, que visaram avaliar o tempo empregado pelo middleware para omuniação entre as amadas e para a transferênia de arquivos. Entretanto, esses testes não pretendem demonstrar ganhos de desempenho om utilização de Gereniadores de Grade, e sim da arga imposta pelo uso do middleware; Testes de independênia de plataforma: para omprovar o funionamento da solução em plataformas homogêneas e heterogêneas, tanto de desenvolvimento quanto de exeução; Testes de extensibilidade, nos quais foram inseridos um EEP e um EGG àqueles iniialmente existentes; Testes de desaoplamento, nos quais uma apliação liente pode ser testada om EGGs distintos, mostrando desaoplamento entre a apliação e o Gereniador de Grades. Foi realizado ainda um teste de exeução de atividades om e sem o uso de Gereniador de Workflow pela apliação liente. Quando pertinente, serão apresentadas as onfigurações de hardware e de software utilizadas. Os testes foram realizados para dois enários: laboratório e real. O primeiro era omposto por exeuções paralelas de três apliações simples: soma de dois números inteiros, álulo de π e Torres de Hanoi - essas apliações foram utilizadas de diversas formas para avaliar o funionamento do middleware e a 101

116 Testes e Resultados Obtidos arga de omuniação entre suas amadas. O enário real é uma apliação que utiliza o Ourgrid para previsão meteorológia, atualmente em uso pelo Instituto Naional de Pesquisas Espaiais (INPE). Ele permite a realização dos demais testes e avaliar o funionamento do middleware em produção, bem omo a arga imposta por ele para transferênia de arquivos, mais intensa neste aso. 7.1 Apliações para Testes As três apliações implementadas possuem tempos de exeução em ordens de grandeza distintos, sendo que sua ombinação permite a realização dos seguintes testes funionais: Uso dos EEPs om uma únia atividade; Uso dos EEPs om diversas instânias de uma mesma atividade; Uso dos EEPs om atividades distintas. Cada um dos testes aima, detalhados nesta seção, permite validar a orretude de resultados, arga de omuniação entre amadas do middleware e a evolução desta arga em função do número de atividades sendo exeutadas. Esses testes foram realizados om o EGG para exeução sem grade, uma vez que este EGG permite fazer testes om o middleware, sem interferênia nos resultados em função de gereniadores de grades. Cada apliação é implementada em uma bibliotea semelhante à desrita na Seção Soma de Dois Números Inteiros É um algoritmo trivial, om tempo de exeução Ο 1. A lasse que implementa esta apliação é a mesma apresentada na listagem da Seção , porém om o seguinte ódigo no método Exeute: // To be alled by the EGG to run the ativity publi string Exeute(string args) { string[] a = args.split(' '); int x = int.parse(a[0]); int y = int.parse(a[1]); // After ompleting, set m_running to indiate // that proessing has been finished m_running = false; 102

117 Testes e Resultados Obtidos } return (x + y).tostring(); Esse algoritmo permite avaliar o tempo de omuniação entre as amadas do middleware em função do número de atividades. O middleware foi implementado om diversos pontos de omuniação assínrona e uso de threads. A depuração de um programa om tais araterístias não é trivial, uma vez que diversos fatores externos podem afetar o fluxo de exeução de suas threads. Alguns exemplos desses fatores são: a exeução dentro e fora do ambiente de desenvolvimento; om ou sem símbolos para depuração; o uso de reursos para produção de log de exeução; ou ainda a exeução onomitante de outras apliações ou serviços/daemons. O retorno pratiamente imediato deste algoritmo permite maximizar o tempo utilizado para gereniamento dessas threads, oloando-as pratiamente ao mesmo tempo em exeução. Além disso, as instânias desta apliação retornarão ao middleware assim que forem oloadas em exeução, fazendo om que as amadas do middleware sejam hamadas diversas vezes em urto intervalo de tempo, o que auxilia no teste do isolamento de seções rítias utilizadas em diversos pontos do ódigo do middleware Cálulo Aproximado de π É um algoritmo om tempo de exeução Ο n. A lasse que implementa esta apliação é a mesma apresentada na listagem da Seção , porém om o seguinte ódigo no método Exeute: // To be alled by the EGG to run the ativity publi string Exeute(string args) { string[] a = args.split(' '); int numsteps = int.parse(a[0]); double step = 1.0 / (double)numsteps; double sum = 0.0; double x; for (int i = 1; i <= numsteps; i++) { x = (i - 0.5) * step; sum = sum / (1.0 + x * x); } // After ompleting, set m_running to indiate 103

118 Testes e Resultados Obtidos } // that proessing has been finished m_running = false; return (step * sum).tostring(); O tempo de exeução linear permite que seja testado um enário omumente enontrado em apliações de e-siene: a exeução paralela de um onjunto de atividades om tempos de exeução semelhantes, e que terminam em momentos próximos. Com isso, é possível testar o omportamento do middleware om atividades sendo onluídas minutos após terem sido iniiadas Torres de Hanoi É um algoritmo om tempo de exeução Ο 2 n. A lasse que implementa esta apliação é a mesma apresentada na listagem da Seção , porém om o seguinte ódigo no método Exeute: private Int64 m_nummoves = 0; // To be alled by the EGG to run the ativity publi string Exeute(string args) { string[] a = args.split(' '); } int x = int.parse(a[0]); Hanoi(x, 1, 2, 3); // After ompleting, set m_running to indiate // that proessing has been finished m_running = false; return m_nummoves.tostring(); private void Hanoi(int tam, int A, int B, int C) { if (tam > 0) { Hanoi(tam - 1, A, C, B); if (m_nummoves < Int64.MaxValue) m_nummoves++; // Move from A to C - this ould be written to a text file Hanoi(tam - 1, B, A, C); } } 104

119 Testes e Resultados Obtidos O tempo de exeução exponenial permite validar a apliação do middleware para a exeução de atividades que são onluídas em momentos próximos ou não - algumas podem ser onluídas em segundos, enquanto outras podem demorar dias Brazilian Regional Atmospheri Modeling System - BRAMS [71] É um sistema destinado aos entros de previsão meteorológia brasileiros, desenvolvido em onjunto por ATMET (Atmospheri, Meteorologial and Environment Tehnologies [72]), IME/USP (Instituto de Matemátia e Estatístia/Universidade de São Paulo [73]), IAG/USP (Instituto Astronômio e Geofísio/Universidade de São Paulo [74]) e CPTEC/INPE (Centro de Previsão de Tempo e Estudos Climátios/Instituto Naional de Pesquisas Espaiais [75]). Destinado à exeução sobre Linux, baseia-se no RAMS (Regional Atmospheri Modeling System [76]), desenvolvido por ATMET e grupos de pesquisa que inluem ientistas da Colorado State University. A prinipal diferença entre o RAMS e o BRAMS é a inlusão de araterístias tropiais a este último, omo o tratamento de nuvens to tipo úmulos, tornando o sistema mais adequado para uso pelos entros metereológios brasileiros. Além disso, melhorias no desempenho para exeução serial e paralela também foram realizadas, onforme [77]. O objetivo do sistema é forneer um modelo preditivo para simulação de ondições atmosférias em regiões geográfias de dimensões variadas, desde regiões irunvizinhas a determinada idade, a maro regiões omo Sul ou Centro-Oeste, por exemplo. Esse sistema é atualmente utilizado pelo CPTEC/INPE e foi também utilizado pelo grupo de Proessamento Paralelo e Distribuído do Instituto de Informátia da Universidade Federal do Rio Grande do Sul [77]. A esolha do BRAMS omo apliação de e-siene para validação da arquitetura aqui exposta reaiu nos seguintes fatos: É uma apliação araterístia de e-siene, om o ientista voltado à sua área de pesquisa, ao invés de questões relaionadas a informátia; O BRAMS pode ser utilizado om ou sem a presença de software gereniador de grade. A equipe da UFRGS utilizou o BRAMS om Globus e om Ourgrid, fazendo os ajustes neessários para exeução om um ou outro gereniador. Essa experiênia permitiu avaliar as hipóteses de simpliidade de integração e transparênia do middleware em relação ao gereniador de grade; 105

120 Testes e Resultados Obtidos Ajustes na resolução dos modelos a serem gerados permitiram a realização de testes om atividades om duração variável, de minutos a horas. O BRAMS ria modelos limátios a partir da exeução de sripts que utilizam arquivos de entrada e produzem arquivos de saída. Para failitar a onfiguração do modelo a ser riado, a equipe do CPTEC/INPE desenvolveu e utiliza uma apliação web denominada GridSphere, ilustrada na Figura 41. Figura 41: Portal GridSphere para gereniamento de jobs BRAMS As informações sobre as simulações, aqui denominadas jobs, fiam armazenadas em um bano de dados Postgres. Quando o botão Exeutar na figura aima for pressionado, o estado da simulação (job) que estiver seleionada será alterado para LIBERADA. Para que a simulação seja então realizada, um daemon 7, a intervalos regulares, onsulta o bano de dados à proura de jobs nesse estado. Então faz as seguintes atividades, para tais jobs: Altera o estado do job para EXECUTANDO ; Prepara os dados para submissão ao Ourgrid, riando um arquivo hamado Job Definition File, ou JDF; 7 Daemons são apliações que monitoram algum reurso. Na plataforma Windows, são hamadas serviços 106

121 Testes e Resultados Obtidos Utiliza uma API desenvolvida em Java para submeter a exeução da simulação ao Ourgrid; Aguarda a onlusão do proessamento do BRAMS pelo Ourgrid; Quando terminar, altera o estado da simulação para CONCLUíDA ; Armazena os arquivos de saída no loal indiado. A imagem apresentada na Figura 42 ilustra um dos arquivos produzidos pelo BRAMS omo resultado da exeução de uma simulação. Figura 42: exemplo de saída produzida pelo BRAMS Os arquivos JDF utilizados pelo Ourgrid, permitem a onfiguração de um job, que pode onter uma ou mais tarefas (tasks). O exemplo abaixo ilustra um JDF tipiamente utilizado para riação de um modelo BRAMS: job : label task : init : RECLIRSrun : put /home/portalrelirs/200102m01/ramsin-sf $PLAYPEN/RAMSIN-sf put /home/portalrelirs/200102m01/ramsin-vfile $PLAYPEN/RAMSIN-vfile put /home/portalrelirs/200102m01/ramsin-initial $PLAYPEN/RAMSIN-initial put /home/portalrelirs/200102m01/ramspostseriesuperfiie.inp $PLAYPEN/ramspostSerieSuperfiie.inp put /home/portalrelirs/200102m01/ramspostmedianiveis.inp 107

122 Testes e Resultados Obtidos $PLAYPEN/ramspostMediaNiveis.inp put /home/portal/setfileenv $PLAYPEN/setFileEnv put /home/portal/ambiente-og.sh $PLAYPEN/ambiente-og.sh remote : sh ambiente-og.sh 288 /home/portalrelirs/200102m01 10 final : get $PLAYPEN/resultados.tar.gz /home/portalrelirs/200102m01/resultados.tar.gz get $PLAYPEN/output.tar.gz /home/portalrelirs/200102m01/output.tar.gz get $PLAYPEN/pospro.tar.gz /home/portalrelirs/200102m01/pospro.tar.gz get $PLAYPEN/history.tar.gz /home/portalrelirs/200102m01/history.tar.gz get $PLAYPEN/resultados-iph.tar.gz /home/portalrelirs/200102m01/resultados-iph.tar.gz get $PLAYPEN/desriptorSerieSuperfiie3.tar.gz /home/portalrelirs/200102m01/desriptorseriesuperfiie3.tar.gz get $PLAYPEN/dpiniio.txt /home/portalrelirs/200102m01/dpiniio.txt get $PLAYPEN/dpfinal.txt /home/portalrelirs/200102m01/dpfinal.txt get $PLAYPEN/tpiniio.txt /home/portalrelirs/200102m01/tpiniio.txt get $PLAYPEN/tpfinal.txt /home/portalrelirs/200102m01/tpfinal.txt get $PLAYPEN/status /home/portalrelirs/200102m01/status As seções init e final possuem instruções para ópia de arquivos de entrada e saída, respetivamente. A seção remote ontém o omando de exeução do sript do BRAMS que gera o modelo limátio. Quanto ao tratamento de arquivos, quando o BRAMS é exeutado pelo Ourgrid, o omponente Peer proura pelos arquivos de entrada e os distribui para o nó da grade onde aquela tarefa será exeutada. Essa transferênia é feita utilizando SSH e SCP, mesmo método empregado pelo middleware, apresentado na Seção 6.4. Vale notar que, assim omo oorre om a representação em XML do padrão no middleware, aqui um dos arquivos de entrada ontém o sript a ser exeutado - última linha om omando put no exemplo aima. No middleware, para a exeução de atividade que esteja em uma bibliotea (DLL), o primeiro parâmetro de entrada do tipo file é a bibliotea em si, onforme desrito na Seção Submissão de Atividades ao EGG para Threads Para a realização dos testes om atividades distintas, foi utilizada a apliação WorkflowPJC, apresentada na Seção 6.6. Já para os testes envolvendo múltiplas instânias de uma mesma atividade, a interfae daquela apliação é inadequada, devido ao tratamento de parâmetros para grande quantidade de instânias. Por esse motivo, foi desenvolvida uma apliação liente, hamada Load Generation Tool (LGT), ilustrada na Figura

123 Testes e Resultados Obtidos Figura 43: apliação para submissão de atividades ao middleware A atividade ujas instânias serão submetidas ao middleware é definida no ampo Ativity. Esse e os demais ampos apresentados na figura aima são mapeados nos atributos dos elementos da representação do padrão em XML. O ampo Parameters possui os parâmetros a serem enviados a ada instânia da atividade, separados pelo aratere. Desse modo, a primeira instânia reeberá os parâmetros 1 1, a segunda 2 2, e assim por diante, análogo à apliação WorkflowPJC desrita na Seção 6.6. Esse omportamento permanee o mesmo até ino instânias, o que permite a realização de testes básios de funionalidade. No entanto, diferentemente daquela apliação, para um número de instânias superior a esse limite, o primeiro parâmetro é repetido para todas as instânias, o que failita a interação om o usuário para testes envolvendo dezenas ou entenas de atividades a serem proessadas pelo middleware. O exemplo da Figura 43 refere-se à apliação de Soma de Números Inteiros, desrita na Seção 7.1.1, e produz a seguinte entrada para o middleware: <WorkflowGrid EGP_URI=" Grid="Gridless" Pattern="PJC" ClientAddress="loalhost"> <Attributes DynamiInstane="False" CanelAtivities="False" NumberOfReady="5" /> <ParallelAtivities> <ParallelAtivity AtivityId="1" Name=""> <Parameters> 109

124 Testes e Resultados Obtidos <Parameter ParameterId="1" Diretion="input" Type="ommand" Value="1 1" /> <Parameter ParameterId="2" Diretion="input" Type="file" Value="/ygdrive/C/ThreadStub/bin/Debug/ThreadStub.dll" /> </Parameters> </ParallelAtivity> <ParallelAtivity AtivityId="2" Name=""> <Parameters> <Parameter ParameterId="1" Diretion="input" Type="ommand" Value="2 2" /> <Parameter ParameterId="2" Diretion="input" Type="file" Value="/ygdrive/C/ThreadStub/bin/Debug/ThreadStub.dll" /> </Parameters> </ParallelAtivity> <ParallelAtivity AtivityId="3" Name=""> <Parameters> <Parameter ParameterId="1" Diretion="input" Type="ommand" Value="3 3" /> <Parameter ParameterId="2" Diretion="input" Type="file" Value="/ygdrive/C/ThreadStub/bin/Debug/ThreadStub.dll" /> </Parameters> </ParallelAtivity> <ParallelAtivity AtivityId="4" Name=""> <Parameters> <Parameter ParameterId="1" Diretion="input" Type="ommand" Value="4 4" /> <Parameter ParameterId="2" Diretion="input" Type="file" Value="/ygdrive/C/ThreadStub/bin/Debug/ThreadStub.dll" /> </Parameters> </ParallelAtivity> <ParallelAtivity AtivityId="5" Name=""> <Parameters> <Parameter ParameterId="1" Diretion="input" Type="ommand" Value="5 5" /> <Parameter ParameterId="2" Diretion="input" Type="file" Value="/ygdrive/C/ThreadStub/bin/Debug/ThreadStub.dll" /> </Parameters> </ParallelAtivity> </ParallelAtivities> </WorkflowGrid> 110

125 Testes e Resultados Obtidos Cada instânia é representada omo uma atividade, de aordo om o desrito na Seção Assim, são produzidos ino elementos ParallelAtivity que diferem apenas no atributo AtivityId e nos atributos Value dos elementos Parameter. Observe que o atributo Value de ada elemento Parameter do tipo ommand ontém os parâmetros a serem passados ao método Exeute da lasse Task (Seção ) do primeiro arquivo de entrada - aquele om o menor valor no atributo ParameterId, om Diretion= input e Type= file. O exemplo da figura produz o seguinte resultado: <WorkflowGridResult> <ParallelAtivities> <ParallelAtivity AtivityId="1" Status="Completed" Result="2" /> <ParallelAtivity AtivityId="2" Status="Completed" Result="4" /> <ParallelAtivity AtivityId="3" Status="Completed" Result="6" /> <ParallelAtivity AtivityId="4" Status="Completed" Result="8" /> <ParallelAtivity AtivityId="5" Status="Completed" Result="10" /> </ParallelAtivities> </WorkflowGridResult> São realizados aqui dois tipos de testes: funionalidade e arga. No primeiro, é verifiado o omportamento do middleware e os resultados produzidos, gravados em arquivo texto seguindo formato XML onforme desrito na Seção No segundo, foram submetidas quantidades resentes de atividades, a fim de avaliar o desempenho e impato produzidos pela presença do middleware Submissão de Atividades ao EGG para Ourgrid Para os testes em enário real, foram submetidos jobs BRAMS ao Ourgrid, utilizando o middleware. Para isso, o daemon desrito na Seção foi modifiado. O iníio do proesso ontinua o mesmo, om a utilização do GridSphere para onfiguração dos jobs e armazenamento desta no Postgres. Então o daemon passa a utilizar o EGP para submissão e para onsulta da situação de uma exeução. Essa requisição transita pelas amadas do middleware, até hegar ao EGG para o Ourgrid. Este, por sua vez, utiliza a API do Ourgrid para submeter o job. A Figura 44 ilustra o fluxo de exeução sem o uso do middleware. Todos os apliativos foram esritos em Java e a exeução se dá sobre Linux. 111

126 Testes e Resultados Obtidos GridSphere Postgres Daemon MyGrid Figura 44: exeução de simulações om BRAMS sem o middleware A Figura 45 mostra em que ponto da exeução o middleware é utilizado. Neste aso, os serviços do middleware foram implementados em Visual C# e são exeutados sobre Windows, à exeção do EGG para Ourgrid, desenvolvido em Java e exeutado sobre Linux. GridSphere Postgres Middleware Daemon EGP EGG para Ourgrid MyGrid Figura 45: exeução de simulações om BRAMS e om o middleware Os testes utilizando o BRAMS om a equipe da UFRGS permitiram avaliar a perepção do usuário no toante à independênia de software gereniador de grade que o middleware proporiona. Além disso, permitiu também validar o uso do middleware em plataformas heterogêneas, desrito mais adiante neste apítulo. 112

127 Testes e Resultados Obtidos 7.2 Testes de Funionalidade Para avaliar a orretude do middleware e do PJC, foram realizados os testes onstantes da Tabela 4. Tabela 4: testes funionais em laboratório # Apliação Atividades n (number of ready) 1 WorkflowPJC 1 x Soma 1 false 2 WorkflowPJC 1 x Soma 1 true 3 WorkflowPJC 5 x Soma 3 false 4 WorkflowPJC 5 x Soma 3 true 5 WorkflowPJC 5 x Hanoi false 6 WorkflowPJC 5 x Hanoi true 7 WorkflowPJC 2 x Soma x Hanoi x π x x true 8 LGT 1000 x Soma false Canela demais atividades Os testes 1 e 2 são triviais, e avaliam o funionamento básio da omuniação entre as amadas do middleware. Devolvem o estado ompleted para a atividade exeutada. Os testes 3 e 4 ilustram uma peuliaridade da implementação: omo as atividades são exeutadas rapidamente, todas serão onluídas antes que o middleware tenha enviado o omando de anelamento. Quando uma atividade for onluída, seu estado deve ser enviado do EGG para o IPG, e de lá para o EPP, no qual o padrão deide se deve ou não enviar uma requisição de anelamento. Nesse tempo, todas as demais atividades terminam sua exeução. Consequentemente, todas as atividades apareem om o estado ompleted, independentemente do valor do atributo CanelAtivities. Os testes 5 e 6 utilizam o algoritmo de Torres de Hanoi om número de disos que promove maior espaço de tempo entre a onlusão das atividades. Nesse enário é possível validar a orretude do anelamento e do retorno do PJC. Para ambos, assim que três atividades forem onluídas, o método IsExeuting do EGP, hamado pela apliação liente, devolve false. Então, a hamada de GetWorkflowStatus devolverá essas três atividades om estado ompleted, e as demais dependerão do valor do atributo CanelAtivities. 113

128 Testes e Resultados Obtidos O teste 7 ilustra a exeução de dez atividades, sendo duas para Soma, quatro para Torres de Hanoi e quatro para álulo de π. As duas somas terminam rapidamente, e então três álulos de π e uma exeução das Torres de Hanoi também onluem. As demais atividades são então aneladas. Finalmente, o teste 8 submete uma arga bastante grande de atividades que serão onluídas em urto intervalo de tempo, gerando arga na omuniação entre as amadas do middleware. Esse teste permitiu identifiar possíveis timeouts e gargalos durante o desenvolvimento da solução, que foram devidamente eliminados. 7.3 Testes de Desempenho A utilização do middleware impõe um onjunto de tarefas que impatam o desempenho final da exeução, quando omparado à exeução de solução sem o middleware. Essas tarefas podem ser lassifiadas omo: Comuniação e proessamento dos serviços web, que inlui o algoritmo do PJC e o aesso deste ao bano de dados, gereniamento da exeução das atividades pelo EGG utilizado e os tempos de instaniar e aionar os serviços das amadas do middleware; Tratamento de arquivos, onforme desrito na Seção 6.4, que inlui a transferênia de arquivos de entrada e saída, e a riação e remoção de diretórios temporários. Esta seção apresenta o resultado de um onjunto de testes, para os quais foram realizadas três medições de tempo (em segundos), que ompõem o tempo total de uma exeução (T total ): 1) tempo utilizado para tratamento de arquivos (T arq ); 2) tempo para o proessamento das atividades (T ativ ); 3) tempo utilizado em omuniação e proessamento de serviços web (T om ). Desse modo, tem-se: T total = T arq + T ativ + T om Os testes foram realizados onsiderando os fatores que poderiam levar o middleware a impatar o desempenho da apliação sendo submetida: Duração das atividades; Número de atividades; Número de arquivos de entrada; Número de arquivos de saída; 114

129 Testes e Resultados Obtidos Tamanho dos arquivos de entrada; Tamanho dos arquivos de saída. As próximas seções desrevem os testes realizados em função desses elementos. Esses testes foram realizados om o middleware e as apliações de teste em um únio omputador, om a seguinte onfiguração: Notebook Dell D830 Latitude Memória: 4 GB; CPU: Intel Core 2 Duo GHz Diso Rígido: Hitahi HTS K9A300 Sistema Operaional: Windows Vista Enterprise 32-bits, om SP2 Embora a distribuição dos elementos da solução em diversos equipamentos tenham impato no desempenho, isso se dá de modo linear em função da veloidade e utilização da rede. Por esse motivo, tal enário foi empregado para Testes de Independênia de Plataforma e de Desaoplamento, mas não para Testes de Desempenho Desempenho em Função da Duração das Atividades Aqui foi utilizado o Load Generation Tool para submissão de atividades om duração linear e exponenial. Para o primeiro aso, a atividade é o álulo de π, e, para o segundo, as Torres de Hanoi. A Tabela 5 apresenta os dados obtidos neste teste. 115

130 Testes e Resultados Obtidos Tabela 5: testes de desempenho em função da duração das atividades (tempos em segundos) # Atividade Parâmetro T om T arq T ativ T total 1 Cálulo de π Cálulo de π Cálulo de π Cálulo de π Cálulo de π Torres de Hanoi Torres de Hanoi Torres de Hanoi Torres de Hanoi Torres de Hanoi Como pode ser observado da tabela aima e na Figura 46, T om e T arq são pratiamente onstantes, resultando no desempenho do middleware ser diretamente proporional ao T ativ. Isso deve-se ao fato de T ativ não ser afetado pela utilização ou não do middleware, uma vez que essas atividades são exeutadas fora do middleware. Por isso, o impato do middleware no tempo de exeução das apliações independe da duração das atividades. Desse modo, todos os demais testes de desempenho foram realizados em função de outros fatores, e usando atividades simples Tativ Tarq Tom Figura 46: desempenho (em segundos) do middleware em função da duração de atividades Ο(n) e Ο(2 n ) 116

131 Testes e Resultados Obtidos Desempenho em Função do Número de Atividades Aqui foi utilizado o Load Generation Tool para submissão de número de atividades variando de 1 a 100. A atividade esolhida foi a Soma de Dois Números Inteiros. A Tabela 6 apresenta os dados obtidos neste teste. Tabela 6: testes de desempenho em função do número de atividades (tempos em segundos) # Número de Atividades T om T arq T ativ T total Como pode ser observado da tabela aima, T ativ é pratiamente onstante, valendo zero, uma vez que é o tempo de exeução do número de somas igual ao número de atividades. Assim, para o teste 11, é o tempo de realização de 100 somas de números inteiros. Conforme o gráfio da Figura 47, pode ser observado que T om é pratiamente desprezível, e que T arq é linear em função do número de atividades Tativ Tarq Tom Figura 47: desempenho (em segundos) do middleware em função do número de atividades 117

132 Testes e Resultados Obtidos Desempenho em Função do Número de Arquivos A heurístia para transferênia de arquivos de entrada e saída minimiza o número de onexões SSH e de omandos SCP, onforme desrito na Seção 6.4. Desse modo, o tempo de exeução varia em função do número de arquivos, mas sendo adiionalmente dependente do tipo de arquivo (entrada ou saída) e do número de atividades. Os testes desta seção avaliam omo é o desempenho do middleware onsiderando tais fatores. Para esses testes foi utilizado o Load Generation Tool, todos utilizando a Soma de Dois Números Inteiros. Pelo fato de T ativ ser pratiamente zero, foi omitido das tabelas e gráfios dos próximos testes. 118

133 Testes e Resultados Obtidos Variação do Número de Arquivos de Entrada om Uma Atividade Estes testes onsideram a variação de 10 a 100 arquivos de entrada, em múltiplos de 10 arquivos. O tamanho dos arquivos é fixo em 10KB ada. Foi utilizada uma únia atividade. A Tabela 7 apresenta os dados obtidos neste teste. Tabela 7: testes de desempenho em função do número de arquivos de entrada om uma atividade (tempos em segundos) # Número de Arquivos T om T arq T total Conforme o gráfio da Figura 48, pode ser observado que T om é pratiamente onstante, e que T arq é linear em função do número de arquivos Tarq Tom Figura 48: desempenho (em segundos) do middleware em função do número de arquivos de entrada om uma atividade 119

134 Testes e Resultados Obtidos Variação do Número de Arquivos de Entrada om Diversas Atividades Estes testes onsideram a variação de 10 a 100 arquivos de entrada, em múltiplos de 10 arquivos. O tamanho dos arquivos é fixo em 10KB ada. Os arquivos foram distribuídos igualmente em dez atividades. A Tabela 8 apresenta os dados obtidos neste teste. Tabela 8: testes de desempenho em função do número de arquivos de entrada om dez atividades (tempos em segundos) # Número de Arquivos T om T arq T total Conforme o gráfio da Figura 49, pode ser observado que T om é pratiamente onstante, e que T arq é linear em função do número de arquivos Tarq Tom Figura 49: desempenho (em segundos) do middleware em função do número de arquivos de entrada om dez atividades 120

135 Testes e Resultados Obtidos Variação do Número de Arquivos de Saída om Uma Atividade Estes testes onsideram a variação de 10 a 100 arquivos de saída, em múltiplos de 10 arquivos. O tamanho dos arquivos é fixo em 10KB ada. Foi utilizada uma únia atividade. A Tabela 9 apresenta os dados obtidos neste teste. Tabela 9: testes de desempenho em função do número de arquivos de saída om uma atividade (tempos em segundos) # Número de Arquivos T om T arq T total Conforme o gráfio da Figura 50, pode ser observado que T om é pratiamente onstante, e que T arq é linear em função do número de arquivos Tarq Tom Figura 50: desempenho (em segundos) do middleware em função do número de arquivos de saída om uma atividade 121

136 Testes e Resultados Obtidos Variação do Número de Arquivos de Saída om Diversas Atividades Estes testes onsideram a variação de 10 a 100 arquivos de saída, em múltiplos de 10 arquivos. O tamanho dos arquivos é fixo em 10KB ada. Os arquivos foram distribuídos igualmente em dez atividades. A Tabela 10 apresenta os dados obtidos neste teste. Tabela 10: testes de desempenho em função do número de arquivos de saída om dez atividades (tempos em segundos) # Número de Arquivos T om T arq T total Conforme o gráfio da Figura 51, pode ser observado que T om é pratiamente onstante, e que T arq é linear em função do número de arquivos Tarq Tom Figura 51: desempenho (em segundos) do middleware em função do número de arquivos de saída om dez atividades 122