Ricardo Manuel Meira Ferrão Luis. Análise de Sistemas para Especificação de Workflow baseados em XML. Escola de Engenharia Departamento de Informática

Transcrição

1 Escola de Engenharia Departamento de Informática Ricardo Manuel Meira Ferrão Luis Análise de Sistemas para Especificação de Workflow baseados em XML Tese de Mestrado Mestrado de Informática Trabalho realizado sob a orientação do Professor Doutor José Carlos Ramalho Setembro de 2006

2

3 AGRADECIMENTOS Aos meus pais e avó, pelo grande apoio e incentivo que me deram durante todos estes anos de estudo e pelos sacrifícios que fizeram para sustentar a minha formação. Sei que estão orgulhosos de mim por ter concluído mais esta fase, e este trabalho é em parte para vós. Pela confiança que me incutiram ao longo dos meus anos de vida, sei que é a vós que devo o facto de ser aquilo que sou hoje. À minha namorada, pelo apoio e paciência que teve ao longo destes meses de estudo, análise, estruturação e elaboração desta tese. Que suportou as minhas ausências, bem como as minhas presenças. Aos meus colegas e amigos, pelo grande apoio e ânimo que me transmitiram durante esta e outras fases complicadas da minha vida. Ao meu orientador, pela sua disponibilidade e paciência nestes dois anos de trabalho árduo. À instituição, pela oportunidade que me proporcionou em realizar esta tese. Por fim, a todas as pessoas que de uma maneira ou de outra contribuíram para que esta tese chegasse ao fim. O meu sincero agradecimento a todos eles. III

4

5 DEDICATÓRIA Dedico esta tese, antes de mais, ao meu falecido avô, Manuel Fernandes Gomes Meira, que me criou, educou e que sempre me tratou como um filho. Para ti um interminável obrigado. Jamais terei palavras para te agradecer Dedico-o, também, de forma reflexiva a mim próprio. V

6

7 RESUMO Análise de Sistemas para Especificação de Workflow baseados em XML Este trabalho teve como objectivo inicial a analise e comparação das linguagens XML existentes para a especificação de Workflow. Para tal, numa primeira fase foram investigadas as tecnologias de Workflow a nível de arquitectura, desenho e funcionamento através da sua observação (vistas). Numa segunda etapa, analisaram-se pormenorizadamente algumas das linguagens mais representativas da área: XRL, WWF, CBPEL, XPDL, estabeleceu-se um estudo comparativo segundo os padrões de Workflow normalizados pelo Workflow Managment Coalition, apontando desvantagens e vantagens em cada uma delas. No final, e com base no estudo comparativo produzido, calculou-se um denominador comum das várias linguagens que se materializou numa linguagem de anotação que satisfaz os padrões mais representativos. Implementou-se também um tradutor, uma aplicação que utiliza esse estudo para realizar as várias conversões através de uma base de conhecimentos, podendo a tradução ser efectuada directamente entre linguagens Workflow ou através do denominador comum implementado, aproveitando desta forma os benefícios e ferramentas de suporte de cada uma das tecnologias de Workflow existentes. PALAVRAS-CHAVE Workflow, XML, Denominador Comum VII

8

9 ABSTRACT System Analysis for Workflow Specification based in XML The initial purpose of this work was the analysis and comparison between the existing XML languages for Workflow specification. For that, in a first phase, Workflow technologies where investigated in architecture, design and functionality level through its observation (views). In a second stage, some of the most representative languages of this area where analyzed in detail: XRL, WWF, CBPEL, XPDL, a comparative study was established according to standards of Workflow normalized by Workflow Managment Coalition, pointing the disadvantages and advantages in each technology. At the end, and on the basis of the produced comparative study, a common denominator was calculated for these languages, materialized in a markup language that satisfies the standards of the most representative Workflow languages. A translator was also produced. It s an application that uses this study to establish conversions between Workflow languages directly or through the implemented common denominator, using the benefits and tools that support each one of the existing Workflow technologies. KEYWORDS Workflow, XML, Common Denominator IX

10

11 PREFÁCIO Três anos após concluir a Licenciatura em Engenharia Informática no ramo de Sistemas e Computadores no Instituto Superior de Engenharia do Porto resolvi iniciar um processo de reciclagem com a realização do Mestrado em Informática. Nesse intermédio tive contacto com o mercado de trabalho, desenvolvi dezenas de projectos de inovação tecnológica e tive outras tantas acções de formação profissional, mas sempre senti a falta da formação de carácter acentuadamente científico. A pósgraduação permitiu-me consolidar os conhecimentos adquiridos até então e despertar para novos desafios, preenchendo a lacuna do saber mais a montante. Na altura de escolher um tema para a elaboração da tese, não tive dúvidas e aceitei um desafio na área do Workflow. Um desafio diferente porque, apesar de alguma incidência no desenvolvimento de projectos Web durante a minha carreira profissional, nunca tinha investigado profundamente esta área, o que constituiu a motivação, mais do que suficiente, para intervir activamente nesta investigação. A experiência profissional, o conhecimento das tecnologias de mercado e todo o know-how apreendido durante a licenciatura foram postos em prática para obter os melhores resultados possíveis e conseguir produzir um trabalho com qualidade, sem desiludir os docentes, os colegas e os companheiros que me fizeram crescer com a Informática. XI

12

13 NOTAÇÃO Alguns dos elementos (termos, expressões, imagens, código, etc.) apresentados ao longo deste documento não serão integralmente traduzidos para português para evitar deturpações do seu significado com a tradução imprecisa ou aproximada dos termos técnicos originais em inglês, tais elementos serão representados de forma diferente, especificamente em Negrito (Ex: Routes). Desta forma, o leitor também ficará familiarizado com os termos e expressões originais que são utilizadas nas demais bibliografias acerca esta matéria. XIII

14

15 ÍNDICE 1 INTRODUÇÃO OBJECTIVOS ESTRUTURA DA DISSERTAÇÃO ENQUADRAMENTO TEÓRICO EXTENSIBLE MARKUP LANGUAGE (XML) WORKFLOW CARACTERÍSTICAS NUM SISTEMA WORKFLOW TIPOS DE MODELOS WORKFLOW WORKFLOW MANAGMENT COALITION WORKFLOW REFERENCE MODEL WORKFLOW ENGINE REQUISITOS TÍPICOS NUMA APLICAÇÃO BASEADA EM WORKFLOW WORKFLOW FRAMEWORK ORCHESTRATION VISTAS TIPOS DE VISTAS PETRI NET AGENTES PRINCIPAIS ACTIVIDADES NUM CENÁRIO DE COMÉRCIO ELECTRÓNICO TIPOS DE AGENTES COOPERAÇÃO DE AGENTES COM MENSAGENS XML CONSIDERAÇÕES GERAIS REFLEXÃO SOBRE WORKFLOW PADRÕES DE WORKFLOW PADRÕES BÁSICOS NO CONTROLO DE FLOW (BASIC CONTROL FLOW PATTERNS) PADRÃO 1 SEQUÊNCIA (SEQUENCE) PADRÃO 2 SEPARAÇÃO EM PARALELO (PARALLEL SPLIT) PADRÃO 3 SINCRONIZAÇÃO (SYNCHRONIZATION) PADRÃO 4 ESCOLHA EXCLUSIVA (EXCLUSIVE CHOICE) PADRÃO 5 FUSÃO SIMPLES (SIMPLE MERGE) RAMIFICAÇÕES AVANÇADAS E SINCRONIZAÇÃO DE PADRÕES (ADVANCED BRANCHING AND SYNCHRONIZATION PATTERNS) PADRÃO 6 ESCOLHA MÚLTIPLA (MULTI-CHOICE) PADRÃO 7 FUSÃO SÍNCRONA (SYNCHRONIZING MERGE) PADRÃO 8 FUSÃO MÚLTIPLA (MULTI-MERGE) PADRÃO 9 DESCRIMINADOR (DISCRIMINATOR) PADRÕES DE REPETIÇÃO E PADRÕES TERMINAIS (STRUCTURAL PATTERNS) PADRÃO 10 CICLOS OPCIONAIS (ARBITRARY CICLES) PADRÃO 11 FINALIZAÇÃO IMPLÍCITA (IMPLICIT TERMINATION)...44 XV

16 3.4 PADRÕES QUE ENVOLVEM INSTÂNCIAS MÚLTIPLAS (PATTERNS INVOLVING MULTIPLE INSTANCES) PADRÃO 12 INSTÂNCIAS MÚLTIPLAS SEM SINCRONIZAÇÃO (MULTIPLE INSTANCES WITHOUT SYNCHRONIZATION) PADRÃO 13 INSTÂNCIAS MÚLTIPLAS COM CONHECIMENTOS DE DESIGN TIME À PRIORI (MULTIPLE INSTANCES WITH A PRIORI DESIGN TIME KNOWLEDGE) PADRÃO 14 INSTÂNCIAS MÚLTIPLAS COM CONHECIMENTOS DE RUNTIME À PRIORI (MULTIPLE INSTANCES WITH A PRIORI RUNTIME KNOWLEDGE) PADRÃO 15 INSTÂNCIAS MÚLTIPLAS SEM CONHECIMENTOS DE RUNTIME À PRIORI (MULTIPLE INSTANCES WITHOUT A PRIORI RUNTIME KNOWLEDGE) PADRÕES BASEADOS EM ESTADOS (STATE-BASED PATTERNS) PADRÃO 16 ESCOLHA DIFERIDA (DEFERRED CHOICE) PADRÃO 17 ENCAMINHAMENTO PARALELO SEM ORDENAÇÃO (INTERLEAVED PARALLEL ROUTING) PADRÃO 18 FINALIDADE (MILESTONE) PADRÕES DE CANCELAMENTO (CANCELLATION PATTERNS) PADRÃO 19 CANCELA ACTIVIDADE (CANCEL ACTIVITY) PADRÃO 20 CANCELA CASO (CANCEL CASE) CONCLUSÕES TECNOLOGIAS EXISTENTES XML PROCESS DEFINITION LANGUAGE (XPDL) BPMN CONCLUSÕES EXCHANGEABLE ROUTING LANGUAGE (XRL) SURGIMENTO E MOTIVAÇÃO NA UTILIZAÇÃO DO XRL MODELAÇÃO DE XRL ARQUITECTURA DO XRL ELEMENTO ROUTE CONCLUSÕES BIZTALK BIZTALK MESSAGING BIZTALK ORCHESTRATION CONCLUSÕES WINDOWS WORKFLOW FOUNDATION FUNCIONALIDADE MOTOR (ENGINE) WORKFLOW XML UM WORKFLOW FRAMEWORK PARA DIVERSAS APLICAÇÕES A UTILIZAÇÃO DO WINDOWS WORKFLOW FOUNDATION CARACTERÍSTICAS DOS WORKFLOWS SEQUENCIAL WORKFLOWS TRANSACÇÕES STATE MACHINE WORKFLOWS COMUNICAÇÃO COM APLICAÇÕES EXTERNAS AO WORKFLOW OBJECTOS DE CONSTRUÇÃO NO WINDOWS WORKFLOW FOUNDATION CONCLUSÕES ELECTRONIC BUSINESS XML (EBXML)...75 XVI

17 4.6 PROCESS INTERCHANGE FORMAT - XML (PIF-XML) PROCESS SPECIFICATION LANGUAGE (PSL) A LINGUAGEM (LANGUAGE) O MODELO TEÓRICO (MODEL THEORY) A PROVA TEÓRICA (PROOF THEORY) SIMPLE WORKFLOW ACCESS PROTOCOL (SWAP) BUSINESS PROCESS EXECUTION LANGUAGEM (BPEL) COMMON BUSINESS PROCESS EXECUTION LANGUAGEM (CBPEL) DADOS E PARCEIROS INTERACÇÕES E CONTROLE DE FLUXO FULLXML WF-XML XML PIPELINE LANGUAGES XML PIPELINE DEFINITION LANGUAGE (XPDL) XML PIPELINE LANGUAGE (XPL) CONCLUSÕES CASO DE ESTUDO (REQUISIÇÕS DE MATERIAL) DESCRIÇÃO DO CASO DE ESTUDO IMPLEMENTAÇÃO EM WWF ESQUEMATIZAÇÃO DO WORKFLOW EM WWF XOML RESULTANTE DO WWF IMPLEMENTAÇÃO EM XRL/FLOWER DTD UTILIZADO NO XRL/FLOWER WORKFLOW EM XRL TRADUÇÃO DE XRL PARA PETRI NET RESULTADO PETRI NET CONCLUSÕES COMPARAÇÕES SEGUNDO OS PADRÕES DE WORKFLOW ESTUDO COMPARAÇÃO SEGUNDO OS PADRÕES DO WFMC COMPARAÇÃO ENTRE LINGUAGENS DE WORKFLOW SEGUNDO OS PADRÕES MAIS REPRESENTATIVOS CONCLUSÕES DENOMINADOR COMUM ESTRUTURA DO TRADUTOR ESTRUTURA DO DENOMINADOR COMUM (LINGUAGEM RML) FUNCIONAMENTO FICHEIROS UTILIZADOS APLICAÇÃO RML-TRANSLATOR CONCLUSÕES XVII

18 8 CONCLUSÃO REFLEXÃO SÍNTESE RETROSPECTIVA E TESE FUTURAS IMPLEMENTAÇÕES BIBLIOGRAFIA E REFERÊNCIAS XVIII

19 ÍNDICE DE FIGURAS FIGURA 1. FIGURA 2. FIGURA 3. WORKFLOW REFERENCE MODEL...29 MODELAÇÃO PETRI NET DE UM EMPREGADO DE CAFÉ...33 SÍMBOLOS UTILIZADOS NO DTD NAS CONSTRUÇÕES PETRI NET...33 FIGURA 4. A TAREFA EM PETRI NET...33 FIGURA 5. FIGURA 6. ARQUITECTURA DE UMA AGENTE DINÂMICO...36 COMÉRCIO ELECTRÓNICO ATRAVÉS DA AUTOMATIZAÇÃO COM AGENTES MÚLTIPLOS...37 FIGURA 7. PADRÕES DE ESCOLHA MÚLTIPLA...42 FIGURA 8. PADRÕES DE FUSÃO MÚLTIPLA...43 FIGURA 9. FIGURA 10. IMPLEMENTAÇÃO DE UM DISCRIMINADOR (2-OUT-OF-3)...43 IMPLEMENTAÇÃO DE UM CICLO OPCIONAL...44 FIGURA 11. ESTRATÉGIAS NA IMPLEMENTAÇÃO DE UMA ESCOLHA DIFERIDA...46 FIGURA 12. OPÇÕES NA IMPLEMENTAÇÃO DE ENCAMINHAMENTO PARALELO SEM ORDENAÇÃO...47 FIGURA 13. ESTRATÉGIAS NA IMPLEMENTAÇÃO DE UMA FINALIDADE...48 FIGURA 14. ARQUITECTURA DO PROCESS DEFINITION INTERCHANGE...52 FIGURA 15. ARQUITECTURA DO XRL/FLOWER...54 FIGURA 16. ARQUITECTURA DO BIZTALK...57 FIGURA 17. FIGURA 18. FIGURA 19. TROCA DE MENSAGENS NO BIZTALK...58 VISÃO GERAL DO BIZTALK...59 FUNCIONALIDADE DO WORKFLOW NO WINDOWS WORKFLOW FOUNDATION...61 FIGURA 20. RELAÇÃO DAS ACTIVIDADES COM O WORKFLOW NO WWF...63 FIGURA 21. WORKFLOW DESIGNER NO VISUAL STUDIO FIGURA 22. FIGURA 23. FIGURA 24. COMPONENTES DO WINDOWS WORKFLOW FOUNDATION...66 SEQUENCIAL WORKFLOW...67 STATE MACHINE WORKFLOW...69 FIGURA 25. OBJECTOS DE CONSTRUÇÃO NO WINDOWS WORKFLOW FOUNDATION.71 FIGURA 26. FIGURA 27. A HIERARQUIA DAS CLASSES DO PIF...77 WORKFLOW DAS REQUISIÇÕES DE MATERIAL DA ETAP...91 FIGURA 28. WORKFLOW EM WWF (1/2)...92 XIX

20 FIGURA 29. WORKFLOW EM WWF (2/2)...93 FIGURA 30. PETRI NET NO XRL/FLOWER FIGURA 31. SCHEMA DO RML_TRADUTOR.XSD FIGURA 32. ELEMENTO TRADUCAO FIGURA 33. ELEMENTO PADRAO FIGURA 34. FIGURA 35. SCHEMA DO RML_DENOMINADOR.XSD ELEMENTOS DO DENOMINADOR COMUM (RML) FIGURA 36. ÍCONE DA APLICAÇÃO RML-TRANSLATOR FIGURA 37. AMBIENTE DE TRABALHO DO RML-T FIGURA 38. FIGURA 39. FIGURA 40. FIGURA 41. FIGURA 42. FIGURA 43. ABRIR UM TRADUTOR (INSTÂNCIA) ABRIR O FICHEIRO ORIGEM (DEPOIS DE DEFINIR/ABRIR O TRADUTOR).118 ABRIR LISTAGEM COM AS TAGS (NOTAÇÕES) DO FICHEIRO ORIGEM TRADUÇÃO PARA A LINGUAGEM DESTINO LISTAGEM COM AS TAGS (NOTAÇÕES) DESTINO E ERROS GERADOS GRAVAÇÃO DO FICHEIRO DESTINO FIGURA 44. INFORMAÇÃO SOBRE O AUTOR, DATA E VERSÃO DA APLICAÇÃO FIGURA 45. SAIR DA APLICAÇÃO FIGURA 46. BARRA DE MENUS XX

21 SIGLAS ASAP Asynchronous Service Access Protocol ASP Active Server Pages ASP.Net Active Server Pages.Net AWSP Asynchronous Web Services Protocol B2B Business to Business BizTalk Business Talk BPEL Business Process Execution Language C-BPEL Common Business Process Execution Language C# C Sharp DTD Document Type Definition EAI Enterprise Application Integration ebxml Electronic Business XML FullXML Full-featured and Full-customizable web portal based on XML HTTP Hypertext Transfer Protocol HTTPS Hypertext Transfer Protocol Secure PIF-XML Process Interchange Format - XML PSL Process Specification Language SGBD Sistema Gestor de Base de Dados SMTP Simple Mail Transfer Protocol SOAP Simple Object Access Protocolo SWAP Simple Workflow Access Protocol URL Uniform Resource Locator VB.Net Visual Basic.Net W3C World Wide Web Consortium WfMC Workflow Managment Coalition WinFX Windows Workflow Foundation WS-BPEL Web Services - Business Process Execution Language WWF Windows Workflow Foundation XML Extensible Markup Language XPDL XML Process Definition Language XRL exchangeable Routing Language XSL extensible Stylesheet Language XXI

22

23 1 INTRODUÇÃO O estudo meramente teórico de sistemas de Workflow baseados em XML pode revelar-se incompleto se não tivermos à nossa disposição uma aplicação ou serviço capaz de demonstrar a interacção entre linguagens e tecnologias distintas. Com base neste princípio, desenvolvi a teoria de que seria possível conceber um denominador comum, com interfaces textuais simples e objectivas, para ajudar os produtores e os utilizadores de Workflows compreenderem, reutilizarem documentos XML e desta forma beneficiarem do melhor que existe em cada uma das tecnologias actuais. Este estudo está focado essencialmente para o domínio de Workflows Institucionais, isto é, centralizado no fluxo de processos. O Workflow Documental foi parcialmente desconsiderado nesta análise porque a documentação que flui no workflow, em princípio, deverá ser independente da linguagem de especificação de workflow e por isso é torna-se irrelevante nesta dissertação. A ideia primordial do projecto é investigar as linguagens e tecnologias existentes dentro deste domínio, comparar os padrões normalizados segundo o Workflow Managment Coalition, e propor uma arquitectura aplicacional para suportar um denominador comum, dinamicamente apoiado por um modelo de translação de notações concebido para a tradução apoiada de linguagens de especificação de Workflows. Por outras palavras, trata-se de uma Análise de Sistemas para Especificação de Workflow baseados em XML. 23

24 CAPÍTULO 1 INTRODUÇÃO 1.1 OBJECTIVOS Os objectivos que dirigiram o trabalho ao longo da dissertação foram os seguintes: Analisar pormenorizadamente algumas das linguagens mais representativas da área: XRL, WWF, CBPEL; Estudar os padrões de Workflow standard existentes; Estabelecer um estudo comparativo entre linguagens segundo os padrões de Workflow, apontando desvantagens e vantagens de cada linguagem; Calcular e implementar um denominador comum e especificar uma linguagem de anotação para esse denominador; Desenvolver uma primeira versão do denominador comum (tradutor), com interfaces textuais simples; Estabelecer recomendações com o objectivo de uniformizar as ontologias de Workflow existentes em XML, promovendo a troca e a partilha documental futura. 1.2 ESTRUTURA DA DISSERTAÇÃO Esta dissertação encontra-se dividida em 9 capítulos que passo a descrever. O primeiro capítulo, Introdução, é um ensaio introdutório que propicia uma visão do trabalho efectuado e destaca as mais importantes etapas no desenvolvimento da análise, estudo e dissertação. No segundo capítulo, Enquadramento Teórico, procuro apresentar uma análise exaustiva dos conteúdos disponíveis na Internet, nomeadamente artigos científicos, abstracts, drafts, documentos críticos, comentários, linguagens de marcação, linguagens, protocolos, técnicas e tecnologias, de forma a elucidar o leitor desta dissertação acerca do seu tema e conteúdos propostos para esta tese. 24

25 CAPÍTULO 1 INTRODUÇÃO No terceiro capítulo, Padrões de Workflow, pretendo definir e caracterizar os padrões de workflow segundo o Workflow Managment Coalition, perceber como funcionam em termos de processos, regras e actividades, bem como, identificar o conjunto de padrões a que pertencem. No quarto capítulo, Tecnologias Existentes, procuro identificar e abordar um conjunto de normas, linguagens, protocolos e tecnologias que, embora sejam recentes, já existem e têm características e funcionamentos próprios. No quinto capítulo, Caso de Estudo, demonstro o fluxo de dados, tarefas e a interacção com os intervenientes num processo de Workflow institucional, esboçando todo o processo de Workflow, desde as actividades disponíveis, passando por todos os controlos de fluxos e tarefas realizadas por entidades inerentes ao processo. As Comparações Segundo os Padrões de Workflow, sexto capítulo, têm como objectivo realçar os prós, insuficiências e os contras das linguagens de workflow estudadas. Após a análise dos estudos e comparações, descrevo no sétimo capítulo, Denominador Comum, a linguagem criada e o tradutor que foi desenvolvido para servir de ponte entre as linguagens Workflow existentes. No final deste estudo, no oitavo capítulo, disserto sobre a verificação da hipótese avançada e sobre o cumprimento dos objectivos iniciais propostos, apontando as principais conclusões. No nono capítulo, Bibliografia e Referências, estão enumerados os livros, artigos científicos, abstracts, drafts, documentos críticos e comentários que serviram de estudo ou base para esta dissertação. 25

26 2 ENQUADRAMENTO TEÓRICO Neste capítulo, apresenta-se uma análise exaustiva dos conteúdos disponíveis na Internet, nomeadamente artigos científicos, abstracts, drafts, documentos críticos, comentários e convém de certo modo evidenciar e explicar algumas das linguagens de marcação, linguagens, protocolos, técnicas e tecnologias, de forma a elucidar o leitor desta dissertação acerca do seu tema e conteúdos propostos para esta tese. 2.1 EXTENSIBLE MARKUP LANGUAGE (XML) Podemos considerar o XML uma MML (Meta-markup Language), uma linguagem de anotação descritiva extensível, tendo, portanto, todas as características que tornam desejável este tipo de linguagens: independência relativamente às plataformas de software e de hardware utilizadas, longevidade, baixos custos de manutenção e facilidade na utilização. É uma linguagem que fornece um formato para a descrição de dados estruturados. O XML é uma metalinguagem que em qualquer momento permite o acrescentar de novos elementos à linguagem, o que torna esta linguagem numa linguagem aberta e sem limitações do ponto de vista de extensibilidade [1]. O XML pode desta forma servir como instrumento para viabilizar a troca de dados nos fluxos de trabalho. E como? Através de documentos que identificam os eventos ou tarefas a serem executadas, as notações para o controlo de fluxos de tarefas, as notações que permitem a interacção com web services (response e reply) e a utilização de web services como mecanismos de comunicação com outros intervenientes no workflow. 26

27 CAPÍTULO 2 ENQUADRAMENTO TEÓRICO Nesta dissertação, o XML é a linguagem de anotação utilizada pela generalidade das tecnologias de workflow estudadas. O XML também foi utilizado na construção do denominador comum. 2.2 WORKFLOW Workflow é a automação de processos, onde as actividades são passadas de um participante para o outro de acordo com um conjunto de regras definidas. O conceito de Workflow foi concebido de acordo com a noção de processos. Permite que processos possam ser passados de uma pessoa para outra de acordo com algumas regras. A gestão de workflow possui um conjunto de ferramentas para administração e monitorização, para controle de aplicações, queries ou instruções invocadas e ferramentas de análise e construção de fluxos e processos. As ferramentas utilizadas para a gestão de workflows apresentam algumas falhas. Essas ferramentas não podem descrever processos de excepções, as suas interacções são poucos flexíveis e não apresentam escalabilidade [22]. Um workflow pode ser também definido como um conjunto de actividades/negócios que são sequenciadas numa ordem específica de modo a obter um particular objectivo do negócio [2]. Um Sistema de Workflow pode ser interpretado como um sistema de informação responsável pela transição (fluxo/flow) de documentos de um utilizador para outro de acordo um conjunto de regras predefinidas no negócio em causa [4][5] CARACTERÍSTICAS NUM SISTEMA WORKFLOW Um Sistema Workflow é constituído por: Routes Caminhos entre conjuntos de objectos criando o workflow, podem ser lineares, circulares ou paralelos; Rules Definem condições necessárias para permitir a passagem ao estado (state) seguinte; 27

28 CAPÍTULO 2 ENQUADRAMENTO TEÓRICO Roles Definem as funções das pessoas ou programas envolvidos no workflow; Task Acções que são conduzidas pelo workflow, as tarefas podem ser acarretadas pelos utilizadores ou programas definidos no Role do workflow TIPOS DE MODELOS WORKFLOW Process-oriented workflows Utilizados para automatizar processos cuja estrutura está bem definida e estável durante um período de tempo, normalmente coordena sub-processos executados por máquinas e que requerem um envolvimento mínimo por parte das pessoas intervenientes nesse processo; Workflows específicos São menos direccionados e são utilizados mais na coordenação de tarefas (tasks). Podem ser alterados ao longo do tempo e são mais difíceis de administrar WORKFLOW MANAGMENT COALITION The Workflow Managment Coalition (WfMC) é uma organização não lucrativa (nonprofit) que existe desde 1993, esta organização é composta por utilizadores, analistas, vendedores e grupos de investigação de diversas universidades. A sua missão é promover e desenvolver a utilização de workflow através da utilização de standards para software, interacção e conectividade entre produtos workflow [6] WORKFLOW REFERENCE MODEL A Figura 1 demonstra a arquitectura do WfMC (Workflow Management Coalition) que está centrada à volta do motor do workflow (workflow engine). As diversas interfaces apresentadas foram parcialmente especificadas pelo WfMC. Infelizmente algumas semânticas destas interfaces não foram disponibilizadas e algumas equipas de desenvolvimento criaram as suas próprias especificações. As aplicações cliente podem aceder ao workflow engine através da rede (network). As ferramentas de 28

29 CAPÍTULO 2 ENQUADRAMENTO TEÓRICO definição de processos (process definition tools) permitem especificar os processos. As ferramentas de administração (administration tools) são utilizadas para gerir o workflow engine. Existe também suporte para serviços adicionais. O WfMC permite também aceder a outros serviços de workflow através da interface 4 da Figura 1 baseado em XML. Esta especificação é denominada Wf-XML WORKFLOW ENGINE Figura 1. Workflow Reference Model O Workflow Engine é responsável por parte (ou por todo) do ambiente de controlo em tempo real (Realtime Control Environment) de um serviço específico REQUISITOS TÍPICOS NUMA APLICAÇÃO BASEADA EM WORKFLOW Os requisitos típicos numa aplicação baseada em workflow normalmente incluem: A aptidão para tomar decisões consoante as regras do negócio. Isto inclui regras simples, tais como decisões tipo sim ou não baseadas numa caixa de validação e regras mais complexas, tais como análises de conjuntos de dados para obter uma decisão não definitiva mas perto da decisão final. 29

30 CAPÍTULO 2 ENQUADRAMENTO TEÓRICO Formas de comunicar com outras aplicações e outros sistemas externos ao workflow. Por exemplo, um pedido é recebido por parte de outra aplicação, isto requer comunicações usando web services ou outras tecnologias. Métodos de interacção com pessoas. Neste caso, um gestor (utilizador) deve aprovar ou validar algumas decisões. Deve existir uma interface que permita a interacção de um utilizador com a aplicação. A possibilidade de manter um estado (state) durante a existência do workflow, especialmente quando pessoas estão envolvidas. Um workflow por demorar bastante tempo até que esteja finalizado e um utilizador pode ir de férias ou de fim-de-semana. O sistema deve de ser escalável de modo a ter a possibilidade de desactivar um workflow, mantendo o seu estado (state) e depois ter a capacidade de reactivar o workflow, carregando o seu estado e fluir para o passo seguinte. Estes requisitos são fundamentais em workflows, mas um workflow framework deverá poder oferecer mais do que isto [19] WORKFLOW FRAMEWORK Um workflow framework é uma plataforma que deverá dispor de ferramentas de suporte para facilitar a construção e visualização gráfica de workflows, deverá ter também modelos ou passos predefinidos de workflow para facilitar as tarefas do utilizador, bem como, sistemas de monitorização de processos e passos em tempo real. Assim sendo, um Workflow Framework deverá: Ter a capacidade de criar passos predefinidos de workflows que são utilizados num determinado domínio sem ter que escrever código para declarar alguns comportamentos. Oferecer ferramentas para criar, alterar e manipular workflows graficamente, permitindo a ilustração das actividades, dos passos e da relação entre eles. 30

31 CAPÍTULO 2 ENQUADRAMENTO TEÓRICO A habilidade de monitorizar workflows em execução, examinando os seus passos em tempo real. A possibilidade de alterar instâncias de um workflow em execução, como por exemplo a necessidade de adicionar uma nova actividade ou passo no workflow. Isto acontece normalmente que existe a interacção de um utilizador com o sistema workflow. 2.3 ORCHESTRATION O termo orchestration é tipicamente utilizado para referir a coordenação de trabalho realizado exclusivamente por software. É importante distinguir este conceito comparativamente ao conceito de workflow. O workflow envolve também pessoas no fluxo de trabalho [3]. 2.4 VISTAS Sempre que surge uma especificação de algo ou alguma coisa, nós, seres humanos, gostamos de esquematizar esse conteúdo. Desde os tempos primórdios, a espécie humana gosta de deixar testemunhos das suas experiências através de desenhos, pinturas ou esquemas como uma forma de explicar ou demonstrar aquilo que presenciou ou idealizou. Por muito bem estruturado e pormenorizado que esteja algo descrito, entendemos muito melhor a sua demonstração gráfica, quer através de figuras, quer através de diagramas. Por exemplo, utilizamos organigramas para demonstrar a estrutura organizacional de uma empresa, fluxogramas para demonstrar algoritmos de programação e até uns riscos para marcar a pontuação um jogo de cartas de sueca. Desta ideologia provêm expressões como: Queres que te faça um desenho? ou Uma imagem diz mais que mil palavras. Nos workflows ou sequências de tarefas podemos também demonstrar fluxos através esquemas, que neste caso apelidados de vistas. Existem alguns tipos de vistas que podem ser utilizados para demonstrar workflows que passo a descrever neste capítulo. 31

32 CAPÍTULO 2 ENQUADRAMENTO TEÓRICO TIPOS DE VISTAS De cima Tenta visualizar a totalidade de um flow ou apenas uma parte dele, tendo em conta uma visão geral, de cima para baixo, como se tratasse de um mapa topográfico. Podem-se utilizar representações gráficas, por exemplo o Petri Net, para tentar visualizar e/ou representar o flow [9]. Esta vista procura especificar a estruturar dos fluxos de informação, por vezes tornase inconcebível representar um workflow ou parte dele devido à existência de um número indeterminado de ligações entre actividades Abstracta Não tem como finalidade visualizar ou representar o flow como um todo mas apenas se preocupa com o que fazer mediante o ambiente que o rodeia. Este modelo pretende construir uma vista abstracta de processos de negócio, separado da tecnologia e de ferramentas associadas ao seu desenvolvimento. Pretende-se com este tipo de vista especificar soluções para interfaces que inicialmente são definidas em termos abstractos e só depois especificar as tecnologias necessárias para desenvolver as interfaces PETRI NET O Petri net é representado graficamente por rectângulos e círculos. Os rectângulos são transitions (transições), isto é, tarefas a serem executadas. Os círculos são utilizados para representar o state (estado) do workflow, isto é, places (locais). As setas entre places e transitions são utilizadas para especificar relações [10]. 32

33 CAPÍTULO 2 ENQUADRAMENTO TEÓRICO Figura 2. Modelação Petri Net de um empregado de café Figura 3. Símbolos utilizados no DTD nas construções Petri Net Figura 4. A tarefa em Petri Net 2.5 AGENTES Este capítulo surgiu com o propósito de definir e distinguir os diversos intervenientes num negócio. E o porquê de um negócio ou cenário de comércio electrónico? Porque actualmente a vasta maioria das aplicações ou linguagens de workflow ou apenas de 33

34 CAPÍTULO 2 ENQUADRAMENTO TEÓRICO controlo de fluxos estão viradas para esta área extremamente lucrativa. E os agentes para que servem? Servem essencialmente para enumerar e diferenciar tipos de intervenientes e as suas características no processo de workflow ou num fluxo de tarefas. Numa primeira fase identifiquei objectivos e as principais actividades de qualquer tipo de negócio, depois enumerei e distingui os diferentes tipos de agentes que poderão existir num workflow ou fluxo e a cooperação que poderá existir entre eles. Finalmente descrevi algumas considerações referentes às linguagens existentes, à evolução e tendência que se verifica e o percurso ideal para salvaguardar a cooperação entre agentes desenvolvidos em aplicações, tecnologias ou linguagens distintas PRINCIPAIS ACTIVIDADES NUM CENÁRIO DE COMÉRCIO ELECTRÓNICO Como em qualquer negócio, convém em primeiro lugar identificar os objectivos e as principais actividades do negócio antes de partir para uma solução determinista. As principais actividades no comércio electrónico podem ser definidas como as seguintes: Identificar requisitos; Negociar de produtos; Negociar com os vendedores; Fazer acordos/negócios; Fazer compras; Fazer pagamento de transacções. Os agentes podem também serem usados para descobrir parceiros de negócio e reagir a um conjunto de mudanças. 34

35 CAPÍTULO 2 ENQUADRAMENTO TEÓRICO TIPOS DE AGENTES Agentes Dependentes Trajectos Predefinidos Estes agentes respondem aos pedidos tendo em conta uma estrutura, trajecto ou rota preestabelecida. Sabem o que fazer quando algo conhecido lhes é solicitado, estão programados para isso, mas simplesmente ignoram ou bloqueiam quando surge um acontecimento ou requisição inesperada. Esta técnica prima no aspecto organizativo de encaminhamento e na facilidade da optimização de tarefas. Como desvantagem, peca na falta de flexibilidade, maleabilidade e adaptabilidade no tratamento de casos opacos Agentes Independentes (ou Autónomos) Teoria do Caos Na Mitologia grega, o Caos era considerado o estado não organizado, ou o nada, de onde todas as coisas surgiam, onde não podemos criar uma ordem perfeita, mas sim esquecer todas as limitações do pensamento mecanista e compreendermos a harmonia do Caos que nos rodeia e aprenderemos a viver nele. Desta forma, apenas reagimos ao ambiente que nos rodeia sem a preocupação de seguir um pensamento estruturado e predefinido. Este é o outro método que pode ser adoptado na filosofia de comportamentos e na troca de informação em sistemas de Workflow baseados em XML Web Services. Existe a independência dos agentes, relativamente uns aos outros, pois não existe uma rota predefinida por onde deverá correr a informação. Cada agente é autónomo e está programado para reagir com os pedidos que lhe são feitos, reagindo assim com o ambiente que o rodeia, abstraindo-se de todo o processo estruturado. Esta técnica tem como vantagem a sua maleabilidade e adaptabilidade e torna-se mais simples de programar porque não necessita de conhecer e obedecer a uma estrutura e a uma rota predefinida. Acaba por pecar no aspecto organizativo de encaminhamento e na optimização de tarefas Agentes Mistos (ou Compostos) Implementação Composta Estes tipos de agentes não são totalmente dependentes de rotas preestabelecidas nem estão completamente abstraídos aos elementos estranhos que os rodeiam, isto é, visam 35

36 CAPÍTULO 2 ENQUADRAMENTO TEÓRICO seguir um conjunto de trajectos predefinidos mas sempre que surgir algo inesperado, tentam reagir como um agente independente e autónomo Agentes Dinâmicos A maioria dos softwares que utilizam agentes já contém funções predefinidas o que poderá ser insuficiente para satisfazer as necessidades do comércio electrónico pois não é possível alterar o comportamento dos agentes dinamicamente. Já existem infraestruturas que suportam as modificações de comportamento em agentes de comércio electrónico, o agente é tratado como um objecto web associado a uma URL e o formato das mensagens é XML. Um agente dinâmico contém uma parte fixa e uma parte variável: Parte fixa contém o suporte necessário para a gestão de comunicações distribuídas; Parte variável contém o suporte para trocar informação, conhecimento e programas, bem como executá-los. Figura 5. Arquitectura de uma agente dinâmico Através de mensagens, os agentes dinâmicos podem mostrar e trocar o seu conhecimento, habilidade e intenção, apresentar pedidos e trocar objectos. Eles podem também movimentar-se para comunicar melhor e gerir os seus interesses através de determinadas acções. Os agentes dinâmicos comunicam utilizando o XML, podem trocar diferentes sintaxes e interpretadores para executarem tarefas em diferentes domínios [11]. 36

37 CAPÍTULO 2 ENQUADRAMENTO TEÓRICO Figura 6. Comércio electrónico através da automatização com agentes múltiplos Agentes como objectos web Os agentes como objectos web podem ser conectados à Internet e serem acedidos via HTTP ou XML. Tipicamente estão de certa forma ligados a um servidor web. Um agente contém pelo menos uma página web (HTML ou XML) que fornece uma interface que pode ser acedido por qualquer browser. Por exemplo, um agente que tem a função de vendedor pode mostrar informação acerca do que vendeu, a que preço, a quem e quando. Um utilizador autorizado pode alterar os preços via web browser [12]. As operações de requisição podem ser feitas através de métodos GET ou POST via HTTP COOPERAÇÃO DE AGENTES COM MENSAGENS XML Problema: A sintaxe das mensagens XML varia de domínio para domínio, de aplicação para aplicação, o que dificulta a troca de mensagens entre modelos de domínios distintos. Uma solução pode ser a troca, não só dos dados, mas também dos metadados através dos DTD s, trocando os correspondentes interpretadores de forma a compreenderem a informação recebida. 37

38 CAPÍTULO 2 ENQUADRAMENTO TEÓRICO CONSIDERAÇÕES GERAIS Recentemente têm surgido um conjunto de linguagens para descrever processos de workflow ou apenas processos de negócio, algumas mais elaboradas, outras mais simplistas e ainda outras mais viradas para dentro, isto é, para outras tecnologias ou aplicações utilizadas dentro do mesmo sistema operativo ou dentro do mesmo grupo organizacional. Têm aparecido linguagens como o Windows Workflow Foundation, ebxml, exml, BPEL, CBPEL, WS-BPEL, XRL, entre outras, mas nenhuma respeita totalmente os padrões de workflow que já estão instituídos pelo Workflow Managment Coalition desde a década de 90, que tentam definir um standard para a notação workflow. Linguagens e tecnologias de workflow recentes, como é o caso do Microsoft Windows Workflow Foundation, são demasiado virados para o próprio umbigo, já que têm tarefas como UpdateData, SelectData, WaitForData e WaitForQuery dentro do próprio workflow que estão voltadas sobretudo para sistemas gestores de base de dados (SGBD) da Microsoft, como o Microsoft Access ou Microsoft SQL Server. Podem dizer que a linguagem query SQL é utilizada em quase todos os SGBD, mas estas tarefas são notoriamente desenvolvidas para SGBD da Microsoft. E se quiser aceder a dados que estão num suporte MySQL, por exemplo, como é que faço? Por outro lado, já implementam XOML, que não é mais do que XML, como suporte aos workflows gerados. Esta implementação que utiliza XML traduz uma melhoria significativa nas plataformas Microsoft, já que utiliza um suporte que é conhecido por todos nós. Outra mais-valia são as ferramentas de suporte que o WWF apresenta, desde a possibilidade de esboçar um esquema workflow que gera automaticamente a notação XML a ela associada ou vice-versa, como a possibilidade de interacção com outras aplicações ou tecnologias (linguagens de programação e SGBD) Microsoft. Linguagens como ebxml, exml, CBPEL, WS-BPEL ou QualquerCoisa-BPEL, variantes ou acrescentos à linguagem BPEL apenas vêm emaranhar e particularizar o desenvolvimento de fluxos de controlo, não workflows, numa e apenas numa área de acção. Não deixam de ser muito boas num determinado sector, como é o comércio electrónico, mas não podem ser utilizadas noutras implementações fora dessa área de acção. 38

39 CAPÍTULO 2 ENQUADRAMENTO TEÓRICO Outras linguagens, como o XRL, são simplistas, provavelmente demasiado simplistas, faltam-lhes alguns padrões de workflow e pecam nas ferramentas de suporte ao workflow que são demasiado arcaicos ou estão simplesmente ausentes. Em suma, devemos abstrair o workflow do negócio ou das tecnologias existentes, isto é, das tarefas especificas do exercício ou das aplicações ou sistema operativo, independentemente de se tratar de um sistema de comércio electrónico ou outra actividade qualquer que necessite de um workflow para o especificar. Um send é uma tarefa (task), um SelectData também é um task, ou seja, quase tudo que não interessa directamente ao fluxo de tarefas do workflow pode ser considerado um task ou um event e desta forma o workflow pode ser utilizado tanto para um processo de negócio como para esquematizar o processo de o lavar e o estender da roupa lavada. Não devemos entrar demasiado em promenores da actividade ou negócio senão estamos apenas a desenvolver linguagens demasiado especificas para uma determinada área, menosprezando outras actividades que também podem utilizar o workflow para definir o seus fluxos de tarefas. 2.6 REFLEXÃO SOBRE WORKFLOW Podemos interpretar Workflow como uma automação de processos, onde as actividades são passadas de um participante para o outro de acordo com um conjunto de regras definidas. Que Orchestration é tipicamente utilizado para referir a coordenação de trabalho realizado exclusivamente por software sem a necessidade do envolvimento de pessoas no processo, logo Orchestration não é Workflow. Podemos resumir que o XML pode ser um instrumento para viabilizar a troca de dados nos fluxos de trabalho através de notações que identificam os eventos ou tarefas a serem executadas, notações para o controlo de fluxos de tarefas, notações que permitem a interacção com web services (response e reply) e os Web Services são um dos mecanismos de comunicação com outros intervenientes no workflow. 39

40 3 PADRÕES DE WORKFLOW Neste capitulo definem-se e caracterizam-se os padrões de workflow segundo o Workflow Managment Coalition. Neste contexto é essencial conhecer os padrões de Workflow existentes, perceber como funcionam em termos de processos, regras e actividades, bem como, identificar o conjunto de padrões a que pertencem. 3.1 PADRÕES BÁSICOS NO CONTROLO DE FLOW (BASIC CONTROL FLOW PATTERNS) Nesta secção descrevem-se os padrões elementares no processo de controlo e desenho de workflow. O primeiro padrão a considerar é a sequência [13] PADRÃO 1 SEQUÊNCIA (SEQUENCE) Descrição: Uma actividade num processo de workflow fica activo depois da conclusão de outra actividade no mesmo processo. Sinónimos: Sequential routing, serial routing. Os próximos dois padrões podem ser utilizados na distribuição em paralelo PADRÃO 2 SEPARAÇÃO EM PARALELO (PARALLEL SPLIT) Descrição: É um ponto (nó) no processo de workflow onde uma única linha de controlo se divide em múltiplas linhas de controlo que podem ser executadas em paralelo, fazendo com que as actividades sejam executadas em simultâneo ou numa ordem aleatória. 40

41 CAPÍTULO 3 PADRÕES DE WORKFLOW Sinónimos: AND-split, parallel routing, fork PADRÃO 3 SINCRONIZAÇÃO (SYNCHRONIZATION) Descrição: É um ponto (nó) no processo de workflow onde múltiplos subprocessos/actividades convergem para uma única linha de controlo, fazendo a sincronização de múltiplas linhas. Sinónimos: AND-join, rendezvous, synchronizer PADRÃO 4 ESCOLHA EXCLUSIVA (EXCLUSIVE CHOICE) Descrição: É um ponto (nó) no processo de workflow onde, baseado numa decisão ou informação de controlo workflow, uma de múltiplas ligações é seleccionado. Sinónimos: XOR-split, conditional routing, switch, decision PADRÃO 5 FUSÃO SIMPLES (SIMPLE MERGE) Descrição: É um ponto (nó) no processo de workflow onde dois ou mais subprocessos/actividades convergem para uma única linha de controlo sem qualquer tipo de sincronização. Sinónimos: XOR-join, asynchronous join, merge. 3.2 RAMIFICAÇÕES AVANÇADAS E SINCRONIZAÇÃO DE PADRÕES (ADVANCED BRANCHING AND SYNCHRONIZATION PATTERNS) Nesta secção descrevem-se os padrões avançados de sincronização no processo de controlo e desenho de workflow [14] PADRÃO 6 ESCOLHA MÚLTIPLA (MULTI-CHOICE) Descrição: É um ponto (nó) no processo de workflow baseado numa decisão ou num workflow controle onde um conjunto de ligações é escolhido. Sinónimos: Conditional routing, selection, OR-split. 41

42 CAPÍTULO 3 PADRÕES DE WORKFLOW Figura 7. Padrões de Escolha Múltipla PADRÃO 7 FUSÃO SÍNCRONA (SYNCHRONIZING MERGE) Descrição: É um ponto (nó) no processo de workflow onde dois ou mais subprocessos/actividades convergem para uma única linha de controlo. Nesta fusão pressupõe-se que se mais que uma actividade foi executada em paralelo então é necessária sincronização na sua fusão, senão não necessita de sincronização. Sinónimos: Synchronizing join PADRÃO 8 FUSÃO MÚLTIPLA (MULTI-MERGE) Descrição: É um ponto (nó) no processo de workflow onde dois ou mais subprocessos/actividades convergem para uma única linha de controlo sem sincronização. Se mais que uma actividade for executada em paralelo, possivelmente em concorrência, então a actividade seguinte à fusão é executada por todas as ligações recebidas. 42

43 CAPÍTULO 3 PADRÕES DE WORKFLOW Figura 8. Padrões de Fusão Múltipla PADRÃO 9 DESCRIMINADOR (DISCRIMINATOR) Descrição: É um ponto (nó) no processo de workflow que espera pela conclusão de um dos sub-processos/actividades antes de activar a actividade seguinte. Figura 9. Implementação de um discriminador (2-out-of-3) 43

44 CAPÍTULO 3 PADRÕES DE WORKFLOW 3.3 PADRÕES DE REPETIÇÃO E PADRÕES TERMINAIS (STRUCTURAL PATTERNS) Nesta secção descrevem-se os padrões de repetição existentes nos processos de workflow, bem como os padrões terminais que finalizam processos ou actividades PADRÃO 10 CICLOS OPCIONAIS (ARBITRARY CICLES) Descrição: É um ponto (nó) no processo de workflow onde uma ou mais actividades se podem repetir ciclicamente. Sinónimos: Loop, iteration, cycle. Figura 10. Implementação de um ciclo opcional PADRÃO 11 FINALIZAÇÃO IMPLÍCITA (IMPLICIT TERMINATION) Descrição: Um sub-processo/actividade deve terminar quando não existe nada mais que fazer, sem que o workflow esteja em deadlock. 44

45 CAPÍTULO 3 PADRÕES DE WORKFLOW 3.4 PADRÕES QUE ENVOLVEM INSTÂNCIAS MÚLTIPLAS (PATTERNS INVOLVING MULTIPLE INSTANCES) Nesta secção descrevem-se os padrões que envolvem instâncias múltiplas no processo de controlo e desenho de workflow PADRÃO 12 INSTÂNCIAS MÚLTIPLAS SEM SINCRONIZAÇÃO (MULTIPLE INSTANCES WITHOUT SYNCHRONIZATION) Descrição: Neste caso existe a possibilidade de criar múltiplas instâncias de uma actividade, isto é, existe a facilidade de criar novos threads. Cada thread é independente e não precisa de sincronização. Sinónimos: Multi threading without synchronization, Spawn off facility PADRÃO 13 INSTÂNCIAS MÚLTIPLAS COM CONHECIMENTOS DE DESIGN TIME À PRIORI (MULTIPLE INSTANCES WITH A PRIORI DESIGN TIME KNOWLEDGE) Descrição: Neste caso para um processo, uma actividade é activada várias vezes. É conhecido em design time o número de vezes que a actividade é activada PADRÃO 14 INSTÂNCIAS MÚLTIPLAS COM CONHECIMENTOS DE RUNTIME À PRIORI (MULTIPLE INSTANCES WITH A PRIORI RUNTIME KNOWLEDGE) Descrição: Neste caso para um processo, uma actividade é activada várias vezes. É desconhecido em design time o número de vezes que a actividade é activada mas pode ser conhecido em runtime PADRÃO 15 INSTÂNCIAS MÚLTIPLAS SEM CONHECIMENTOS DE RUNTIME À PRIORI (MULTIPLE INSTANCES WITHOUT A PRIORI RUNTIME KNOWLEDGE) Descrição: Neste caso para um processo, uma actividade é activada várias vezes. É desconhecido em design time e runtime o número de vezes que a actividade activada. A diferença em relação ao padrão anterior (padrão 14) é que enquanto algumas 45

46 CAPÍTULO 3 PADRÕES DE WORKFLOW instâncias estão a ser executadas ou já estão completadas, novas instâncias podem ser criadas. 3.5 PADRÕES BASEADOS EM ESTADOS (STATE-BASED PATTERNS) Nesta secção descrevem-se os padrões baseados em estados no processo de controlo e desenho de workflow. Este tipo de workflow é utilizado quando não sabemos à partida o número exacto de eventos ou quando o número de probabilidades impossibilita definir caminhos possíveis no workflow PADRÃO 16 ESCOLHA DIFERIDA (DEFERRED CHOICE) Descrição: É um ponto (nó) no processo de workflow onde, baseado em múltiplas alternativas, uma de múltiplas ligações é seleccionado. Sinónimos: External choice, implicit choice, deferred XOR-split. Figura 11. Estratégias na implementação de uma escolha diferida 46

47 CAPÍTULO 3 PADRÕES DE WORKFLOW PADRÃO 17 ENCAMINHAMENTO PARALELO SEM ORDENAÇÃO (INTERLEAVED PARALLEL ROUTING) Descrição: Um conjunto de actividades é executada sem qualquer ordem e não podem ser executadas em simultâneo, isto é, numa sequência sem ordem. Sinónimos: Unordered sequence. Figura 12. Opções na implementação de encaminhamento paralelo sem ordenação 47

48 CAPÍTULO 3 PADRÕES DE WORKFLOW PADRÃO 18 FINALIDADE (MILESTONE) Descrição: A activação de uma actividade depende do seu estado, isto é, a actividade só é activada se um objectivo foi conseguido e ainda não expirou. Sinónimos: Test arc, deadline, state condition, withdraw message. Figura 13. Estratégias na implementação de uma finalidade 3.6 PADRÕES DE CANCELAMENTO (CANCELLATION PATTERNS) Nesta secção descrevem-se os padrões utilizados no cancelamento de actividades no desenho de workflow PADRÃO 19 CANCELA ACTIVIDADE (CANCEL ACTIVITY) Descrição: Uma actividade que está activa é desactivada. Sinónimos: Withdraw activity. 48

49 CAPÍTULO 3 PADRÕES DE WORKFLOW PADRÃO 20 CANCELA CASO (CANCEL CASE) Descrição: Uma instância de workflow é removida completamente caso algo seja ou não seja determinado. Sinónimos: Withdraw case. 3.7 CONCLUSÕES A definição e caracterização dos padrões de workflow constitui um factor essencial na análise e implementação de workflows. A sua padronização permite compreender detalhadamente cada tipo de fluxo existente. A normalização destes padrões de workflow deverá servir como base a todos as tecnologias e linguagens que utilizam Workflows, devendo tratar-se de um standard universal. Esta análise permitirá comparar as linguagens mais comuns com estes padrões e verificar se estas se encontram em conformidade com esta norma. Os padrões também servirão como base de sustentação ao denominador comum entre linguagens de workflow. 49

50 4 TECNOLOGIAS EXISTENTES Apesar de existir pouco informação acerca de Workflow com XML e esta ser uma abordagem recente no que diz respeito às ciências computacionais e à gestão de conteúdos, já existe um conjunto de normas, linguagens, protocolos e tecnologias que abordam esta matéria. 4.1 XML PROCESS DEFINITION LANGUAGE (XPDL) O WfMC publicou o XML Process Definition Language (XPDL), isto é, XML que descreve o processo de negócio (modelo referencial), um workflow standard. O XPDL é actualmente o padrão utilizado na maioria das ferramentas de BPM, mais utilizado que a especificação BPEL. A história de sucesso da WfMC e os anos de desenvolvimento da especificação fizeram com que fosse utilizado em diversas plataformas de processos ao longo dos anos. O XPDL é um dos padrões mais antigos do mercado, encontra-se actualmente na versão 2.0 e foi desenvolvido pela WfMC (Workflow Management Coalition), uma associação internacional com mais de 300 membros associados que promove o Workflow desde Em termos técnicos, o XPDL é um padrão XML de descrição de regras de processos de negócios. A sua especificação baseia-se na descrição de um conjunto de actividades relacionadas entre si através de transições. A actividade significa uma unidade de trabalho que será processada por um recurso (um participante/utilizador/actor) e/ou uma aplicação computacional. 50