Sistemas de Gerncia de Workflows: Caractersticas, Distribuio e Excees

Luiz Antnio M. Pereira lpereira@inf.puc-rio.br Marco Antonio Casanova casanova@inf.puc-rio.br PUC-RioInf.MCC11/03 Maro, 2003

Abstract
Workflows can be defined as any set of tasks that have to be executed in a coordinated way, in sequence and/or in parallel, by two or more individuals or teams sharing a common goal. Workflow Management Systems - WfMS - are pieces of software designed to automate, at least, the administrative/coordination tasks associated to workflows execution. In this work we will present the main concepts and characteristics of workflow systems considering, as a first step, centralized environments. Further on in the text, due to the typical necessity of workflows to cross departmental borders within an enterprise and between enterprises, we discuss extensions of WfMS required to allow cooperative work of individuals or teams that are geographically dispersed. In this work we also discuss issues related to possible failures during workflow executions. Keywords: Workflow Systems, Workflow Management Systems, Distributed Workflows, Exceptions in Workflows.

Resumo
Workflows, ou fluxos de trabalho, podem ser definidos como qualquer conjunto de atividades executadas de forma coordenada, em srie e/ou em paralelo, por indivduos ou grupos com um objetivo em comum. Sistemas de Gerncia de Workflow - SGWs - so peas de software que visam automatizar (pelo menos) as atividades de administrao/coordenao relativas execuo de workflows. Neste trabalho apresentamos os principais conceitos e

caractersticas dos sistemas de workflow buscando, em uma primeira etapa, nos ater a ambientes centralizados. Mais adiante, em funo da necessidade tpica dos fluxos de trabalho atravessarem as fronteiras setoriais dentro de uma mesma empresa, e at entre empresas, discutimos extenses necessrias aos SGWs para que estes permitam o trabalho cooperativo de indivduos e equipes situadas em locais geograficamente distantes. Nesse trabalho tambm so discutidas questes quanto a possveis falhas durante a
execuo de workflows.

Palavras-chave: Sistemas de Workflow, Sistemas de Gerncia de Workflows, Workflows Distribudos, Excees em Workflows.

1 Introduo
1.1 Workflows e Sistemas de Workflow: Fundamentos
Existem inmeras definies para workflow na literatura. Segundo o Modelo de Referncia de Workflow da Workflow Management Coalition - WfMC [1], workflow a automao de um processo de negcio, por inteiro ou por partes, durante o qual documentos, informaes e atividades so passadas de um participante para outro para que estes desenvolvam aes respeitando um conjunto de regras procedimentais. Workflow, ou fluxo de trabalho, tambm pode ser definido como [5] qualquer conjunto de atividades executadas de forma coordenada, em srie ou em paralelo, por dois ou mais membros de um grupo de trabalho, visando um objetivo comum. Embora a WfMC considere a possibilidade de um workflow ser manualmente organizado, na prtica a maioria deles o dentro do contexto de um sistema de TI, para prover suporte computadorizado s suas automaes procedimentais. As atividades podem ser executadas em seqncia ou simultaneamente, por diferentes indivduos, ou pela combinao dos dois. Segundo Moro em [5], se somente uma pessoa executar todas as atividades, isso no caracteriza um workflow, na medida em que, como o prprio nome sugere, um processo um workflow se os artefatos1 "fluem" de um indivduo (executor) para outro, produzidos e/ou consumidos pelas diversas atividades do processo. Os participantes de um workflow devem estar colaborando em busca de um objetivo comum, ou seja, projetos independentes no constituem um workflow. Alm disso, workflows no se aplicam unicamente a processos de negcio. Considerando as definies e conceitos comuns em toda na literatura pesquisada, entendemos que um workflow pode ser definido como uma coleo de atividades organizadas para realizar um processo, quase sempre de negcio. Essas atividades podem ser executadas por um ou mais sistemas de computador, por um ou mais agentes humanos ou de software, ou ento por uma combinao destes. Do que consistem, a ordem de execuo e as pr-condies das atividades esto definidas no workflow, sendo que o mesmo capaz ainda de representar a sincronizao das atividades e o fluxo de informaes entre elas. Workflow um conceito intimamente relacionado reengenharia e automao de negcios e de processos de informao em uma organizao [20]. A necessidade de escritrios mais eficientes resultou no conceito de Reengenharia de Processo de Negcio e na tecnologia chamada de Sistemas ou Software de Gerncia de Workflow (SGWs) [2][20] ou, simplesmente, Sistemas de Workflow [3]. SGWs so, em geral, ferramentas colaborativas [26] e provem a automao procedimental de workflows, gerenciando a seqncia de atividades de trabalho e chamando ou invocando os recursos humanos e/ou eletrnicos apropriados, que so associados com as vrias atividades que compem o processo. SGWs definem, gerenciam e executam completamente workflows, atravs da execuo de software
1

Qualquer recurso, fsico ou digital, produzido ou utilizado em uma etapa do processo.

baseada em uma representao da lgica ou modelo (dados, operaes e regras) do workflow no computador. Nesses sistemas as atividades so definidas e agendadas, os recursos necessrios so relacionados e, na medida em que as atividades vo sendo executadas pelos respectivos executores, o sistema trata de coordenar e encaminhar automaticamente os resultados alcanados e os demais recursos necessrios para os executores das atividades seguintes na seqncia.

1.2 Motivao e Objetivos

Nosso grupo de pesquisas concentra-se no estudo de infraestruturas de execuo, armazenamento e recuperao de componentes de ensino a distncia (objetos de aprendizado). No contexto de EAD verifica-se a aplicabilidade das tcnicas de workflow, na medida em que a participao coordenada e colaborativa de alunos, professores e autores deve, idealmente, existir, no s na execuo de um curso, quando participam alunos e professores, como tambm na sua modelagem (preparao), quando participam grupos de professores/autores. Com esse trabalho objetivamos, portanto, fundamentar nossas pesquisas em EAD atravs do estudo das funcionalidades de Sistemas de Gerncia de Workflow e do estudo das questes de distribuio e heterogeneidade de SGWs, considerando, inclusive, a possibilidade de ocorrncia de excees durante a execuo. Em seguida, em um prximo trabalho, estaremos pesquisando objetos de aprendizado (learning objects ou LOs), padres de estruturas, suas composies e operaes. Esses estudos devem nos deixar em posio de, em uma terceira etapa, propormos uma arquitetura otimizada para um ambiente de EAD baseado em workflows, onde os artefatos so objetos de aprendizado e os processos referem-se aplicao e avaliao de contedos de aprendizado.

1.3 Contedo do Trabalho

No captulo 2 apresentaremos as caractersticas gerais dos SGWs, fazendo um breve histrico, e descrevendo seus componentes (atividades, executores, rotas, documentos e regras), categorias, funcionalidades, vantagens e exemplos de SGWs de mercado. No captulo 3 apresentaremos as duas metodologias de modelagem de workflows: as baseadas em comunicao e as baseadas em atividades. Faremos, ao final, uma proposta de modelagem de workflows utilizando os diagramas de atividades da UML.

Os primeiros SGWs atenderam a grupos de poucos usurios em ambientes centralizados. Com a crescente aceitao dos workflows, a tecnologia usada cada vez mais em grandes organizaes, que geram fluxos de trabalho complexos, pesados e que so inerentemente distribudos. Isso nos leva a pensar em estender os SGWs existentes dotando-os de funcionalidades que atendam necessidade de distribuio, gerando SGWs distribudos, ou SGWDs, cuja heterogeneidade deve ser considerada. Esses aspectos so tratados no captulo 4. importante, tambm, considerarmos a possibilidade de ocorrncia de excees durante a execuo de um workflow. Excees podem demandar tratamentos complexos, sobretudo quando ocorrem em ambientes distribudos. Excees so discutidas no captulo 5. Finalmente, diante da possibilidade de aplicarmos as solues j estudadas para problemas de sistemas de gerncia de banco de dados distribudos e heterogneos (SGBDDHs) em SGWDs, no captulo 6 discutiremos as semelhanas entre SGBDs e SGWs2; o primeiro prov software que permite o controle, atravs de um conjunto bem definido de operaes e regras disponveis, sobre dados armazenados, o segundo prov software que permite o controle, tambm via um conjunto bem definido de operaes e regras, sobre processos definidos atravs dos dados que os especificam.

2 - Caractersticas dos Sistemas de Gerncia de Workflow

2.1 - Breve Histria dos Sistemas de Gerncia de Workflow
Os sistemas de workflow tm suas origens a partir das pesquisas em automao de escritrios nos idos anos 70 [3]. O principal foco destas pesquisas estava em oferecer solues sobre como gerar, armazenar, compartilhar e rotear documentos em organizaes, visando diminuio da manipulao de documentos em papel. A partir da dcada de 80, o principal objetivo da tecnologia de workflow passou a ser o de unir-se as chamadas ilhas de trabalho e informao individuais e personalizadas de cada membro (ou pequeno grupo de indivduos) de uma organizao, buscando a integrao das ilhas atravs do roteamento do trabalho entre elas. Nessa poca havia uma preocupao em como definir paradigmas e linguagens para a modelagem de processos de trabalho e em como construir arquiteturas para a implementao de sistemas capazes de melhor interpretar e executar tais processos. Nos anos 90, a tecnologia de sistemas de workflow evoluiu muito rapidamente, atuando, ao mesmo tempo, como causa e conseqncia do tambm rpido crescimento das infra-estruturas de redes de computadores e dos ambientes para interao entre grupos que se formaram em torno dessas infra-estruturas. As recentes questes
2

Sistemas de Gerncia de Workflows tm despertado o interesse da comunidade de pesquisadores da rea de bancos de dados como tm sido estudados em disciplinas relacionadas em universidades do mundo inteiro.

relacionadas ao processamento distribudo e interoperabilidade entre aplicaes trouxeram novos desafios definio e construo de arquiteturas para sistemas de workflow [3]. Hoje, a tecnologia de workflow alcana bem mais do que a reduo do fluxo de documentos em papel nas organizaes. Os conceitos e paradigmas de trabalho em grupo, preconizados pelas pesquisas em CSCW (Computer Supported Collaborative Work - Trabalho Colaborativo Suportado por Computador) e groupware (agendamento de conferncias, correio eletrnico, vdeo conferncia, por exemplo) influenciaram a definio destes sistemas como ferramentas para a coordenao do trabalho de equipes, impulsionando seu desenvolvimento. Alm disso, as necessidades de interao intraorganizacionais estenderam-se para nveis inter-organizacionais (Business-to-Business ou B2B), agora contando com o potencial da WWW. Esse fato levou as pesquisas em workflow a um novo patamar voltado para a definio de arquiteturas distribudas de execuo de processos. O trabalho cooperativo, agora, descentralizado, de forma a permitir: Que cada parte do processo de workflow possa ser executada no local mais apropriado, usando os recursos disponveis desse local; Que cada componente ou fragmento do processo remoto possa progredir o mais independentemente possvel dos outros processos com os quais coordenado; Que os dados locais, o estado de execuo, as ferramentas e as demais partes do processo de workflow possam ser manuseados remotamente, de acordo com esquemas de segurana de acesso pr-definidos.

A flagrante tendncia de utilizao de estaes de trabalho com poderes de computao cada vez maiores e as infra-estruturas de rede cada vez mais velozes e confiveis, corroboram para a perpetuao do cenrio acima descrito.

2.2 - Vantagens do Uso de Sistemas de Gerncia de Workflow

Embora no tenhamos, ainda, uma descrio das funcionalidades tipicamente encontradas nos SGWs, podemos identificar e aplicar ao contexto de fluxos de trabalho uma srie de vantagens genricas entre processos manuais e os resultantes de suas automaes. Algumas vantagens do uso de SGWs podem, com isso, ser destacadas: Diminuio da necessidade circulao de documentos em papel; Possibilidade de acesso remoto por parte dos participantes do grupo; Simplificao das atividades de arquivamento e recuperao de informaes; Rapidez na pesquisa de informaes armazenadas; As informaes dos responsveis por cada atividade do processo so mantidas sempre (automaticamente) atualizadas;

Conhecimento do status do processo a cada instante, possibilitando saber-se quais os participantes esto atuando, quais so os prximos a atuar, e quando, etc.; O SGW coordena a execuo das atividades automaticamente com o uso de agendas e trocas de mensagens eletrnicas com os participantes.

Ainda, de [17]: Eficincia melhorada - A automao de muitos processos de negcios resulta na eliminao de muitos passos desnecessrios; Melhor controle do processo - Um melhor gerenciamento de processos de negcios atingido por meio da padronizao dos mtodos de trabalho e da disponibilidade de registros para auditoria; Melhor atendimento ao cliente - Consistncia nos processos levam uma maior previsibilidade nos nveis de resposta aos clientes; Flexibilidade - O controle dos processos via software permite o re-projeto em linha com as necessidades de mudana no negcio, e Melhoria no processo de negcio - O foco nos processos de negcio levam obteno de processos mais eficientes e simples.

2.3 - Componentes dos Workflows

Os componentes fundamentais de um processo ou fluxo de trabalho so as atividades. Atividades, por sua vez, pressupem que existam atores que as executam (interpretando seus papis), os documentos produzidos e consumidos durante a execuo das atividades, rotas que definem os destinos de cada fluxo de informao e regras que devem ser respeitadas durante a execuo das atividades. Damos, a seguir, uma breve definio de cada um desses componentes.

2.3.1 - Atividades
Uma atividade em um fluxo de trabalho corresponde a uma etapa a ser executada dentro de um processo. necessrio que os SGWs ofeream recursos para a definio dos dados das atividades como, por exemplo, o nome da atividade, seus objetivos, instrues a serem seguidas durante sua execuo e os dados ou documentos necessrios para sua realizao.

2.3.2 - Executores: Indivduos, papis, atores, grupos e agentes

Cada atividade deve ter pelo menos um executor responsvel por sua realizao. Esse executor deve ser devidamente cadastrado como usurio do SGW. A associao do

executor s atividades sob sua responsabilidade pode ser realizada no momento da definio do fluxo de trabalho ou (semi) automaticamente pelo SGW, caso ele conhea os perfis dos executores. Executores podem ser indivduos usurios do SGW especficos (referenciados por seus nomes) ou, idealmente, em funo da tpica rotatividade de pessoal nas organizaes, devem ser referenciados por seus papis. Um papel, representado por um ator (classe de indivduos), caracteriza um conjunto de atributos (perfil) e um conjunto de responsabilidades que os indivduos que os desempenham devem possuir. Indivduos devem ser associados a papis e estes, ento, devem ser associados s atividades. Um mesmo indivduo pode representar vrios papis; um mesmo papel pode ser representado por vrios indivduos. SGWs podem permitir, ainda, que sejam definidos grupos de indivduos responsveis pela execuo de atividades em processos. Dentro de um grupo, cada indivduo pode ainda ter um papel definido. Atividades podem ainda ser executadas por agentes de software (ou agentes computacionais), aplicaes ou dispositivos quaisquer.

2.3.3 - Rotas
A definio de um fluxo de trabalho compreende, tambm, a explicitao do encadeamento de atividades do processo (roteamento). Esse encadeamento ocorre, de um modo geral, segundo um grafo orientado, onde atividades (representadas pelos ns do grafo) podem ser executadas em paralelo, segundo uma ordenao parcial, e/ou seqencialmente, quando o grafo orientado de execuo de atividades particularizar-se em uma seqncia nica de atividades. Expresses de guarda podem ainda ser aplicadas s arestas dos grafos para adicionar-se condies de execuo de parte das atividades. A figura 2.1 ilustra.

2.3.4 - Documentos e Formulrios

Um item importante na definio de um fluxo de trabalho a especificao de quais informaes iro fluir durante a execuo dos processos. Os documentos e demais artefatos manipulados ao longo da execuo dos processos podero ser armazenados em pacotes de trabalho. Documentos podem ser consultados, alterados, armazenados ou retirados dos pacotes de trabalho pelos executores das diversas atividades, conforme regras e permisses definidos a priori. Formulrios tambm podem ser roteados ao longo da execuo de um fluxo de trabalho, onde cada executor responsvel pelo preenchimento/atualizao de um conjunto de informaes.

2.3.5 - Regras
A execuo de qualquer atividade em um ambiente organizado pressupe a aceitao e obedincia a regras pr-estabelecidas. Quando a execuo de atividades dever ser feita de forma coordenada, envolvendo mais de um executor, as regras desempenham uma funo vital para a consecuo do objetivo final de um processo.

Em seqncia

Em paralelo

{AND}

Alternativamente

[C1] [C2] [~C1]

Figura 2.1 - Tipos de rotas em um fluxo de trabalho

Regras dizem respeito a restries e diretrizes impostas por um negcio e/ou pela cultura de uma organizao. Regras definem quais informaes iro transitar pelo fluxo e sob quais condies, ou seja, so atributos que definem de que forma os dados que trafegam no fluxo de trabalho devem ser processados, roteados e controlados pelo sistema de workflow [6]. Regras devem ser informadas ao SGW durante a modelagem do processo.

2.4 - Funcionalidades de um Sistema de Gerncia de Workflow

Um SGW corresponde a um conjunto de ferramentas que auxiliam o projeto e implementam esquemas de definio de fluxos de trabalho, sua instanciao e execuo controlada e a coordenao e integrao das diferentes ferramentas disponveis dentro de um mesmo fluxo de trabalho. No nvel conceitual, os sistemas SGWs devem suportar aplicaes em trs reas funcionais: Funes de tempo de construo (build-time functions): preocupam-se com a definio e modelagem do processo de workflow e suas atividades constituintes; Funes de controle em tempo de execuo (run-time control functions): preocupam-se com gerenciamento de processos de workflow em um dado

ambiente operacional e colocao das vrias atividades nas seqncias apropriadas para serem manuseadas como partes de cada processo; Funes de interao em tempo de execuo (run-time interaction functions): tratam da gerncia da interao dos SGWs com usurios humanos e outros sistemas de TI.

A figura 2.2 abaixo ilustra as relaes entre as principais funes (e respectivas reas funcionais) dos SGWs. Em linhas gerais, aps ter-se conduzido a etapa de anlise do processo de negcio, passa-se definio do processo de trabalho, que significa traduzir do mundo real para uma formalizao computacional processvel atravs do uso de uma ou mais tcnicas de anlise e modelagem [3]. O resultado da definio um modelo ou representao do processo a ser executado. Uma vez definido, um processo pode ser executado atravs da interpretao de sua definio pelo sistema de workflow. Esta interpretao compreende o roteamento das atividades definidas aos atores designados para sua execuo. Cada ator ou participante do processo, por sua vez, necessita interagir com o sistema, no s para realizar as atividades a ele designadas, como tambm para tomar conhecimento de sua necessidade de participao no processo.
Projeto e definio do processo

Anlise do Processo de Negcio

Tempo de construo

Definio do Processo
Tempo de execuo Mudanas no processo Instanciao do processo e controle

Servio de Execuo do Workflow

Interao com usurios e ferramentas de aplicao

Aplicaes e Ferramentas de TI

Figura 2.2 - Categorias das Funcionalidades Tpicas de Sistemas de Gerncia de Workflows

Uma apresentao um pouco mais detalhada dessas funcionalidades, presentes na maioria dos sistemas de workflow disponveis no mercado [3][5], apresentada a seguir.

2.4.1 - Modelagem de fluxos de trabalho

A descrio (ou modelagem) dos processos deve conter todos os dados necessrios sobre as atividades a serem executadas e/ou coordenadas pelo sistema de workflow. Alm dos dados sobre as atividades que compem os processos (usurios encarregados, artefatos utilizados e produzidos nas atividades) deve-se relacionar as operaes que devem ser executadas por cada usurio e as regras, ou condies, que devem ser respeitadas durante a execuo das atividades. Em outras palavras, a definio de um processo a ser automatizado em um sistema de workflow deve conter informaes completas sobre quem tem quais responsabilidades, atravs de quais operaes essas responsabilidades devem/podem ser exercidas, as seqncias em que as operaes devem ser executadas, em que momento (e respectivas tolerncias de tempo) e quais os caminhos que levam e trazem os pacotes de informao necessrios para a execuo de cada atividade.

2.4.2 - Execuo de fluxos de trabalho

Fluxos de trabalho so executados atravs de uma ou mais instncias de execuo das atividades que os compem. Essas atividades so definidas durante a modelagem do processo no SGW e podem ser representadas graficamente atravs de diagramas de atividades da UML (vide captulo 3). O SGW deve acompanhar e coordenar a execuo de cada uma das instncias de execuo das atividades que esto ativas, seguindo o fluxo definido no modelo do processo e encaminhando cada atividade para o(s) executor(es) correspondente(s), compondo sua(s) lista(s) de trabalho. As atividades so executadas nos ambientes de trabalho de cada ator/agente do processo atravs de aplicaes ou ferramentas especficas para a atividade em questo.

2.4.3 - Controle de Interaes

Para a execuo das atividades, os usurios interagem com o SGW selecionando e executando atividades que constam de suas respectivas listas de trabalho. A realizao de uma determinada atividade envolve a manipulao dos documentos estipulados no fluxo de trabalho para anlise de informaes, tomada de decises ou preenchimento de dados. A finalizao de uma atividade por um executor repe o controle de volta ao fluxo, permitindo que o SGW prossiga na busca da concluso do processo. Isso feito atravs do "disparo" de novas atividades, considerando os resultados obtidos at ento.

2.4.4 - Acompanhamento
Recursos para o acompanhamento da execuo de atividades devem ser idealmente providos pelo SGW. Um mecanismo interessante para a visualizao do status de execuo o prprio mapa do processo, onde so apresentadas as atividades j realizadas, as atividades em execuo e as atividades a serem ainda executadas, assim como de quem foram/so as respectivas responsabilidades. Recursos, como estatsticas

de quantidades de insumos requeridos na execuo de atividades especficas, podem tambm estar disponveis atravs da manuteno de uma base de dados que reflita a eficincia e a eficcia dos processos atualmente desempenhados pela organizao.

2.4.5 - Administrao
As atividades de administrao dos processos devem ser executadas por usurios com atribuies especficas para tal. Funes para suspenso, cancelamento de instncias de execuo e alterao de prioridades so exemplos dessas atividades.

2.4.6 - Outras funcionalidades

As funcionalidades apresentadas nos itens anteriores so as chamadas funcionalidades bsicas [3] e devem ser idealmente providas por qualquer SGW. Sistemas comerciais, no entanto, implementam outras funcionalidades que julgam igualmente essenciais, das quais citamos as abaixo. Definio de pesos para grupos: Possibilidade de definio de pesos distintos para cada integrante de um grupo, de forma que uma atividade possa ser designada a um membro do grupo baseada nos pesos definidos; Agente de correio: Possibilidade de execuo de aes baseadas no recebimento de mensagens; Auditoria automtica: Possibilidade de manuteno, em um sistema de gerncia de documentos, de verses dos documentos/formulrios relativos a cada passo do processo; Log das atividades: Possibilidade de registro de cada atividade executada durante os processos, assim como disponibilidade de funes para execuo de consultas e elaborao de estatsticas diversas baseadas nos registros feitos; Sub-processos: Possibilidade de definio de sub-processos de um processo; Viso de carga de trabalho: Possibilidade de determinao da carga de trabalho de cada usurio, permitindo que o administrador do processo determine quantas e de quais tipos so as atividades pendentes para um usurio; Grupos dinmicos: Possibilidade de definio de grupos responsveis por uma atividade no momento de sua execuo, ao invs de no momento da modelagem do processo, apenas.

Apresentaes mais detalhadas dessas e outras funcionalidades podem ser encontradas em [3], [7] e [8].

10

2.5 - Categorias de (Sistemas de) Workflows

Temos dado destaque at ento a workflows que visam a automao de processos de negcio. Workflows desse tipo, em geral, envolvem polticas e prticas bastante bem definidas pelas corporaes que os aplicam. Esses workflows so chamados de workflows de transao ou de produo e suas execues permitem pouca ou nenhuma variao entre instncias de execuo entre a prticas das empresas. So, portanto, caracterizados pelo alto grau de estruturao e do nfase aos processos envolvidos na execuo das atividades. Cabe mencionar tambm outras duas categorias de workflows, que categorizam, em conseqncia, os correspondentes SGWs [5][15]: administrativo ou de roteamento de documentos: baseado, primariamente, nas capacidades dos sistemas de e-mail e suas extenses. Esse tipo de workflow trata tarefas administrativas de rotina e, em geral, estabelece apenas fluxos de informao e faz o roteamento de documentos. Exemplos de workflows administrativos so aprovao de despesas de viagem e aprovao de emprstimos; ad-hoc: Existem muitas tarefas e atividades nas corporaes que so mais orientadas a projeto, envolvendo objetivos e produtos cujos passos e dinmica entre usurios so muito difceis de serem definidos em detalhes e com algum grau de previsibilidade. Usam processos e procedimentos onde se enquadram as ferramentas de groupware e onde no existe uma estrutura pr-definida para o processo, ou esta estrutura pode ser modificada em tempo de execuo. Embora, tambm nesse caso, existam deadlines e objetivos (produtos) bem definidos, as responsabilidades individuais podem ser alteradas. Workflows ad-hoc tendem a envolver executores mais criativos e de mais alto grau de conhecimento. As atividades, vez por outra, prescindem do uso dos SGWs. Um elemento tipicamente importante na execuo desse tipo de workflow o mecanismo de comunicao entre executores. Exemplos de aplicaes: criao de documentos, desenvolvimento de software e campanha de marketing para lanamento de produto.

J Georgakopoulos em [20] caracteriza workflows conforme abaixo (transcrio de [9]): Workflows orientados para pessoas, que envolve pessoas na realizao das tarefas. O suporte do sistema fornecido para facilitar a colaborao e a coordenao entre as pessoas, mas so elas prprias que tm, em ltima anlise, a responsabilidade pela coerncia das aes. Workflows orientados para sistemas so aqueles que consistem em tarefas com uso intenso de computao e tarefas especializadas que podem ser executadas por um computador. Nesse caso, o suporte do sistema substancial e envolve controle da concorrncia e recuperao, execuo automtica de tarefas, notificao etc.

11

Workflows transacionais variam entre workflows orientados para pessoas e workflows orientados para sistemas, e tomam emprestadas caractersticas de ambos. Eles envolvem "execuo coordenada de vrias tarefas que (a) podem envolver pessoas, (b) exigem acesso a sistemas HAD (heterogneos, autnomos e/ou distribudos) e (c) admitem o uso seletivo de propriedades transacionais (isto , propriedades ACID) para tarefas individuais ou workflows inteiros".

SGWs podem, tambm, incorporar apenas parte ou mesclar as funcionalidades mencionadas anteriormente, com vistas s suas aplicaes em reas bastante especficas. Workflows cientficos, por exemplo, lidam, em geral, com processamento massivo ou que consomem e/ou produzem volumes grandes de dados. Podem executar processos bem definidos a priori, mas podem necessitar de mudanas em tempo de execuo, em funo de resultados intermedirios. Nesse caso, tambm, o roteamento desses resultados deve ser definido com critrio, podendo ser alterado em tempo de execuo, em funo do volume dos dados. Da mesma forma, em Ensino Distncia (EAD), os tamanhos dos artefatos manipulados podem ser tais que condicionem, em tempo de execuo, um grau de liberdade maior para uma seqncia de processos (i.e., execuo colaborativa de uma lio ou curso) que tipicamente definido priori.

2.6 SGWs Web-Enabled e Web-Based

SGWs que fornecem interfaces Web so chamados Web-enabled, enquanto que Web-based so chamados os SGWs em cujas tecnologias est presente a tecnologia Web, atravs de interfaces, protocolos de comunicao e recursos tpicos, tanto a nvel de aplicaes clientes quanto de servidoras.

3 - Modelagem de Workflows
3.1 - Metodologias de Modelagem de Workflow
Existem, basicamente, duas classes de metodologias de modelagem de workflow: as baseadas em comunicao e as baseadas em atividades [20]. Nos dois itens a seguir faremos uma apresentao breve dessas duas metodologias. No item 3.2 apresentaremos os diagramas de atividades da UML como formas de modelar workflows atravs de metodologias baseadas em atividades.

3.1.1 - Metodologias de Modelagem Baseadas em Comunicao

As metodologias baseadas em comunicao consideram que o objetivo da (re) engenharia de um processo de negcio o de melhorar a satisfao do cliente. Cada ao no workflow reduzida a um ciclo envolvendo um cliente e um executor e composto por quatro fases, que so: preparao, negociao, execuo e aceitao. Na preparao, um cliente solicita a execuo e um executor se oferece para executar uma ao. Na negociao, cliente e executor concordam com a ao a ser executada e

12

definem os parmetros de satisfao. A ao executada na fase de execuo e, na aceitao, o nvel de satisfao do cliente definido e reportado. Nessas metodologias so definidas relaes clientes-provedores, onde os provedores assumem as responsabilidades pelas execues de aes e cada um deles, possivelmente, repassa a um ou mais outros provedores as responsabilidades de execuo de parte ou do total de suas prprias responsabilidades, gerando, com isso, outros sub-ciclos. Nesses casos, o provedor em uma relao cliente-provedor passa a ser o cliente em outra(s). Esse tipo de modelagem estabelece rvores de delegaes de responsabilidades e de execuo de tarefas, onde a composio dos resultados (das atividades representadas pelas folhas das rvores) prov o objetivo do workflow. As especificaes de workflows que usam essa metodologia no indicam quais atividades podem ser executadas em paralelo ou se existem aes condicionais ou alternativas. Os diagramas de interao da UML (seqncias e colaborao) poderiam ser utilizados nessas metodologias.

3.1.2 - Metodologias de Modelagem Baseadas em Atividades

Metodologias baseadas em atividades objetivam a modelagem do trabalho, e no dos compromissos assumidos entre humanos, conforme nas metodologias baseadas em comunicao, tratadas anteriormente. As metodologias baseadas em atividades caracterizam-se pela definio da coordenao entre atividades, eventualmente considerando pr e ps-condies para suas execues. As atividades, entendidas como processos de transformao quaisquer, podem ser modeladas atravs de composies de sub-atividades a serem executadas ordenadamente (parcialmente ou em seqncia), em paralelo ou de forma recursiva. Existem vrios modelos de especificao de workflows baseados em atividades, dentre eles o de Casati/Ceri, o de gatilhos, o de redes de Petri e o modelo proposto por Barthelmess e Wainer em [21]. O autor prope o uso da UML, atravs de seus diagramas - especialmente o de atividades, para o caso de workflows baseados em atividades - e linguagem de especificao de restries de objetos (OCL - Object Constraint Language), para a modelagem de workflows. Os diagramas de atividades (DA) da UML podem ser utilizados como uma WGDL (Workflow Graphic Definition Language), pois provm elementos de modelagem de processos suficientes para emprego nas metodologias de modelagem baseadas em atividades. Diagramas de atividades permitem definir-se condies de execuo de atividades, iteraes, paralelismo, fluxos de artefatos e atribuio de responsabilidade a executores.

13

3.2 - Modelagem de Workflows Usando os Diagramas de Atividades da UML

A figura 2.1 ilustra alguns dos possveis relacionamentos entre atividades de um processo. Abaixo transcrevemos de [18] os possveis relacionamentos entre atividades, necessrios para a modelagem de workflows atravs de metodologias baseadas em atividades. i. ii. Roteamento seqencial (Sequential Routing), onde atividades so executadas em seqncia, correspondendo a um nico fio de execuo (thread); Roteamento paralelo (Parallel Routing), onde duas ou mais instncias de atividades esto sendo executadas em um mesmo tempo, correspondendo a dois ou mais fios de execuo no SGW; Iterao, que corresponde execuo repetitiva de uma ou mais atividades at que uma dada condio seja alcanada; A diviso-E, necessria para o estabelecimento do roteamento paralelo; A juno-E, que define ponto de sincronismo aps a execuo de atividades em paralelo; A diviso-OU, necessria para introduo de condicionalidades na execuo de rotas (ramos) alternativas, e A juno-OU, que marca a re-convergncia de rotas alternativas de workflows.

iii. iv. v. vi. vii.

Segundo Barthelmess e Wainer em [21], alm desses relacionamentos, tambm precisamos dispor de elementos para a associao de papeis a executores. A Linguagem Unificada de Modelagem (Unified Modeling Language - UML), atravs de Diagramas de Atividades, prov representao grfica capaz de modelar processos usando todos os relacionamentos apresentados acima. O uso dos diagramas de atividades da UML apresenta vantagens, dentre elas [19][23]: padro e incorpora as melhores prticas utilizadas nas empresas de produo de software; Prov uma linguagem que permite o entendimento e utilizao por humanos e por mquinas. Esse aspecto importante, pois facilita a implementao dos modelos; Contempla as necessidades de modelagem de negcios e sistemas de pequenos e simples a grandes e complexos.

A figura 3.1 ilustra o emprego de diagramas de atividades na modelagem de workflows. A figura 3.1(a) so ilustradas seqncias de atividades, alm de iterao, representada pelo "*" no canto superior direito da caixa da Atividade 1. A figura 3.1(b)

14

so ilustrados o ponto de fork, para a execuo concorrente das Atividades 1 e 2, e o ponto de sincronismo, que garante que a Atividade 3 s ser executada aps o trmino das Atividades 1 e 2. A figura 3.1 (c) ilustra desvios condicionais e suas respectivas expresses de guarda (condies). A figura 3.2 ilustra a modelagem de um workflow para processamento de um pedido de compra hipottico. As swimlanes ("raias de natao") enriquecem o modelo, permitindo uma fcil identificao dos papis e das responsabilidades dos executores.

15

Iterao Incio Atividade 1 *

Atividade 2
(a)

Fim

Atividade 0

Fork (diviso-E)

(b)

Atividade 1

Atividade 2

Atividade 3 Sincronismo (juno-E)

Atividade 1 [condio A] [condio C] [condio B] Atividade 2 Atividade 3

Desvio (diviso-OU

(c)

Atividade 4

Atividade 5 Intercalao (juno-OU

Figura 3.1 - Diagramas de Atividades da UML modelando (a) roteamento seqencial, (b) diviso-E e (c) diviso-OU

16

Execucao

Atendimento ao Cliente

Setor Financeiro

Receber o Pedido

Preencher o Pedido

Enviar a Fatura

Entregar o Pedido

Receber o Pagamento

Fechar o Pedido

Figura 3.2 - Uso de Diagramas de Atividade da UML com raias de natao, para a visualizao de responsabilidades e atores [23].

17

4 - Sistemas de Gerncia de Workflows Distribudos e Heterogneos

4.1 - A Necessidade de Distribuio
Um processo de workflow pode envolver milhares de fragmentos de processos, variando de atividades de automao simples coordenao entre processos atravs de diferentes nveis de abstrao. As diversas atividades que compem os processos se enquadram em nveis individual, de grupo, de empresa ou inter-organizacionais. Essas atividades e suas associaes aos executores so fortemente influenciadas pelos recursos que so oferecidos localmente (ferramentas e mecanismos diversos para manusear os diversos artefatos), pelo contexto de trabalho e pela cultura local. Atividades diferentes so, por conta dessas influncias, das imposies polticas e administrativas (restries/regras) e tambm de custos, executadas de forma descentralizada. Intui-se, tambm, que a distribuio de um processo pode levar a uma relao benefcio/custo tima, considerando a utilizao dos recursos tambm distribudos. O trabalho descentralizado sugere que os mdulos componentes dos SGWs sejam processados de forma distribuda, cooperativa e complementar. Colaborando ainda para esse cenrio, a j mencionada crescente aceitao dos SGWs nas organizaes vem resultando em suas aplicaes em processos mais complexos e pesados, contando com grande nmero de executores, possivelmente situados em localizaes geogrficas distantes. A tendncia crescente de integrao de fluxos de trabalhos entre stios distintos de uma mesma organizao e entre organizaes distintas (aplicaes B2B, por exemplo) indica a necessidade de que os SGWs, at ento restritos aos ambientes de uma mesma organizao, possam ser agora integrados em parte ou no total, mantendo ou no suas autonomias. Com isso, alm da distribuio, deve-se considerar a possvel heterogeneidade dos SGDs. A distribuio de atividades e informao entre os participantes , como vimos no captulo 2, uma das funcionalidades ditas bsicas de um SGW. A funo de distribuio pode operar em uma variedade de nveis - de grupos de usurios em um mesmo setor at a operao inter-organizacional - e pode contar com uma variedade de mecanismos de comunicao como correio eletrnico e/ou tecnologia de objetos distribudos. A figura 4.1 abaixo ilustra uma possvel instncia de workflow onde mostrado o aspecto de distribuio.

18

Stio A

...

Aplicaes Agentes

Aplicaes Agentes

R R Stio B

...

Figura 4.1 - Distribuio e compartilhamento de workflows

Na figura acima, os dois servios de workflow, localizados em stios diferentes (A e B) so autnomos e possuem usurios locais e remotos (estes marcados com R). As aplicaes locais a cada stio podem compartilhar bases de dados, que podem ser remotas. Atravs de um mecanismo padronizado de comunicao, uma atividade executada em um dos stios pode gerar artefatos que sero usados em atividade(s) de outro(s) stio(s). Os stios representados podem pertencer a uma mesma organizao ou a organizaes distintas. Os SGWs podem ser, ainda, produtos comerciais distintos. Em outras palavras, o fluxo do trabalho pode envolver a transferncia de atividades entre diferentes vendedores de produtos de workflow para habilitar partes diferentes do processo de negcio a ser desempenhado em plataformas ou sub-redes diferentes e usando produtos especficos para cada estgio dos processos.

4.2 - Consideraes Sobre a Infraestrutura Necessria

As necessidades em termos de infra-estrutura classificam-se em dois tipos: armazenamento e recuperao de dados e comunicao. necessrio, primeiramente, que os diversos artefatos e informaes (estados) sobre as atividades sendo executadas em um workflow sejam mantidas em um ou mais repositrios. A maioria dos SGWs baseada na arquitetura cliente-servidor na qual, mesmo sendo as atividades individuais executadas em ns distintos, artefatos e estados so guardados em um banco de dados centralizado em um dos servidores [26]. Obviamente a alternativa de distribuio desses dados pode ser considerada. Prs e contras de cada uma dessas alternativas so discutidos no item 4.3.

19

Alm de infra-estrutura de armazenamento fundamental dispor-se de uma infra-estrutura de comunicao rpida, confivel e que suporte o estabelecimento de mecanismos seguros (do ponto de vista de segurana da informao), que tornem transparentes as distncias fsicas entre os diversos participantes de um processo. Infra-estruturas de comunicao so teis para o atendimento de necessidades em dois nveis: Para que sejam feitas atualizaes, idealmente em tempo real, da informao para controle de execuo dos SGWs (estados de execues, por exemplo). Dizem, portanto, respeito infra-estrutura necessria para execuo dos SGWs . Necessidades (bvias) de comunicao entre executores, como trocas de mensagens e artefatos. Essas necessidades, muitas das vezes, no so atendidas diretamente pelos SGWs, pois demandam recursos que, em geral, j esto presentes em qualquer plataforma operacional com infra-estrutura de comunicao3. Nesse nvel encontram-se, tambm, as necessidades de troca de artefatos supridas por outros mecanismos nativos das plataformas operacionais modernas, como NFS e compartilhamento em rede de unidades de disco.

4.3 - Processos Distribudos

Muitos esforos em pesquisas tm sido desenvolvidos no sentido de investigarse as tcnicas de partio de sistemas de workflow em componentes e de distribuio desses componentes entre os executores. A execuo distribuda de workflows necessita, entretanto, ser mais estudada [2]. Como vimos, workflows podem ser especificados, grfica ou textualmente, durante a fase de modelagem. No final da modelagem essas especificaes, sejam elas grficas ou textuais, precisam ser convertidas em conjuntos de componentes computveis semanticamente equivalentes que so, ento, distribudos para e pelos servidores de workflows, conforme tambm definido na modelagem ou de forma automatizada, objetivando um custo global de execuo menor e/ou o atendimento de possveis restries. A desvantagem dessa abordagem sua rigidez, j que suas adaptaes dinmica do ambiente, tal como a entrada de um novo servidor no ar, no so facilmente conseguidas. Uma abordagem diferente, adotada no Altavista Works, prov uma flexibilidade maior em tempo de execuo. Isso foi conseguido ao se converter o sistema original, centralizado em um SGW distribudo (SGWD) [2].
3

Alguns SGWs, como o Lotus Notes, implementam, por sobre a infra-estrutura bsica de comunicao provida pelos ambientes operacionais, mecanismos de comunicao mais apropriados para workgroups, como agentes de correio que provm emisso automtica de comprovantes de recebimento de mensagens, por exemplo.

20

Os requisitos gerais para a execuo distribuda de um workflow, apresentados adiante, devem considerar como os dados de tempo de construo so armazenados e acessados, como deve ser controlada a execuo distribuda e, tambm, como so distribudas as atividades.

4.3.1 - Dados de Tempo de Construo (Modelagem)

uma pr-condio bsica que, em SGWDs, os dados de tempo de construo (dados da modelagem ou, em ingls, built-time data) sejam acessveis por todos os participantes ou executores. Durante a associao dinmica de papis a executores, por exemplo, o SGW seleciona a unidade de execuo mais apropriada para um certo papel. Para ser capaz de selecionar um candidato no local, o WMS deve "conhecer" os dados de tempo de construo para um dado workflow. A questo passa ser, ento, como obter a viso global dos dados de tempo de construo? Uma possibilidade prover-se acesso transparente aos dados centralizados, atravs dos servios de acesso compartilhado a dados providos pela prpria rede (compartilhamento de diretrios). Como a consulta aos dados de tempo de construo, durante a execuo de um workflow, feita intensamente, o trfego gerado em rede seria, com isso, muito grande. Alm disso, essa abordagem possui outras desvantagens bem conhecidas: pequena escalabilidade e baixa confiabilidade devida concentrao dos dados em um nico stio. Na medida em que os dados de tempo de construo, em geral, no so volumosos e so pouco alterados durante a execuo de um workflow, uma soluo mais interessante seria a replicao desses dados por todos os participantes. Alm do Altavista Works, outro SGWDs que adota essa soluo o Exotica [2]

4.3.2 - Controle da Execuo Distribuda

A execuo distribuda de um workflow necessita de algum controle centralizado, que depende do tipo de distribuio usado (vide seo adiante). O mnimo de controle que podemos esperar a sincronizao no tempo dos participantes do workflow. Com isso, os relgios dos servidores de workflow s podem divergir dentro de uma dada tolerncia e um cuidado especial com fusos horrios e suas mudanas deve ser tomado.

4.3.3 - Tipos de Execues Distribudas

As formas de se executar workflows distribudos categorizam-se, basicamente, segundo dois tipos: (1) o servidor que iniciou o workflow, denominado de home-server, controla, de forma centralizada, a execuo remota das atividades ou (2) os workflows migram de um servidor para o outro, levando com eles seus estados de execuo. No primeiro caso, o home-server permanece responsvel por sua execuo at que o processo chegue ao final. As diversas atividades podem ser executadas de forma distribuda e o resultado da execuo de qualquer atividade deve ser sempre reportado ao home-server.

21

Como diferentes workflows podem ser criados e iniciados em diversos servidores, essa abordagem considerada parcialmente centralizada e suas principais vantagens so as facilidades de implementao e de monitoramento. No segundo caso (migrao) a instncia de execuo de um workflow leva consigo seu estado a medida em que sua execuo passa de um servidor a outro, no sendo necessrio, ento, um controle de execuo centralizado. Em contrapartida, o espao necessrio para o armazenamento do estado de execuo, que migra de servidor para servidor atravs da rede, pode assumir um tamanho considervel. Esse trfego pode ser reduzido se distribuirmos, antecipadamente, cpias dos dados de tempo de construo e/ou das partes invariantes dos dados. A alternativa de migrao tem a vantagem bvia de que, tanto o cdigo quanto os dados de controle esto localizados em um mesmo stio. A grande desvantagem dessa alternativa a dificuldade de monitoramento j que, para tal, necessrio que se trate toda histria de um processo como parte do estado de execuo do workflow ou pela escolha de um servidor especfico na rede para recepo e armazenamento da mesma (recaindo em caso semelhante ao anterior), com os prs e contras j discutidos dessas alternativas.

Excees provocadas por falhas dos servidores e/ou na infra-estrutura de comunicao podem ser tratadas, no primeiro caso, da seguinte forma: ao iniciar um workflow, o home server mantm uma cpia atualizada do estado do workflow e de seus mecanismos de controle para um outro servidor da rede (com escolha idealmente baseada em redundncia de caminhos de rede) que assumir o controle, caso o home server original falhe. Caso isso venha a ocorrer, o servidor escolhido assume o controle de execuo do workflow, imediatamente escolhendo outro servidor para sua contingncia. No segundo caso, o servidor que passa o controle a outro mantm o estado do workflow armazenado at que este servidor reporte o final de suas tarefas. Caso isso no ocorra, o primeiro pode tomar a deciso de escolher outro, fazendo nova tentativa. As excees devidas a falhas podem ser recursivas (falhas no tratamento de falhas), tornando a soluo bastante complexa. Esse problema idntico ao tratamento de falhas em transaes distribudas em SGHDDs. Trataremos mais do assunto no captulo 5.

4.4 - A Questo da Heterogeneidade

A tecnologia de workflows usada, cada vez mais, em grandes organizaes, na medida em que estas operam com fluxos de trabalho complexos, pesados e, quase invariavelmente, descentralizados. Como conseqncia, essas organizaes necessitam automatizar o gerenciamento desses fluxos de trabalho. Como j mencionamos, a necessidade de interaes intra-organizacionais atravessou as fronteiras dessas organizaes, alcanando nveis inter-organizacionais. Essas relaes, chamadas de Business-to-Business ou B2B, agora contam com o potencial da WWW. Esses dois aspectos nos levam a pensar em estender os SGWs existentes dotando-os de funcionalidades que atendam necessidade de distribuio, gerando, como tambm vimos, SGWs distribudos, ou SGWDs, onde a possibilidade de heterogeneidade dos sistemas participantes deve ser considerada.

22

Caso a arquitetura do SGW consista de uma camada de aplicao que opera sobre um SGBD (convencional ou no) que armazena os estados dos processos e os artefatos, o problema pode se reduzir ao problema de integrao de dados gerenciados por sistemas heterogneos, com diversas solues propostas e outras tantas em estudo. Caso os dados dos workflows sejam gerenciados por SGWs com arquiteturas monolticas e proprietrias, podemos, ainda sim, integr-los usando envoltrias (wrappers), desde que haja aberturas em suas interfaces. A WfMC, atravs da publicao do Modelo de Referncia de Workflow [1], identificou e agrupou em cinco mdulos os componentes de um sistema de workflow genrico, alm das interfaces (APIs e formatos de troca) entre os mesmos, descrevendoos conceitualmente. O objetivo que SGWs de fabricantes diferentes interoperem. Os cinco componentes identificados do origem a 5 interfaces, conforme mostra a figura 4.2 abaixo. O componente central corresponde mquina de execuo do workflow, composto de um ou mais motores. Os demais componentes provm ferramentas para definio dos processos, para administrao e monitoramento da execuo, aplicaes clientes e aplicaes externas invocveis pela mquina de execuo. Essas cinco interfaces agrupadas foram denominadas de WAPI (Workflow APIs and Interchange Formats). Essa arquitetura elimina o problema de heterogeneidade de SGWs, na medida em que os motores dos diferentes SGWs so os nicos componentes que se comunicam diretamente, o que fazem de forma padronizada. Com isso, tambm, a heterogeneidade dos gerenciadores de dados no precisa ser considerada, j que os acessos aos dados de um SGW feito, exclusivamente, atravs do(s) motor(es) do SGW. Alonso et al em [29], entretanto, defente a abordagem contrria: a gerncia de dados deve ser implementada como um conjunto de bancos de dados replicados fracamente sincronizados, a serem usados como repositrio distribudo, comum a todos os stios que participam da execuo de um processo de negcio. A vantagem dessa abordagem, que a carga da manipulao de dados no mais ficaria sobre o motor do workflow, aumentando, com isso, sua capacidade como uma ferramenta de coordenao e permitindo que o gerenciador de dados pudesse suportar funcionalidades adicionais que seriam difceis de serem incorporadas no motor do SGW.

23

Ferramentas de Definio dos Processos

Ferramentas de Administrao e Monitorao

Servio de Execuo do Workflow Motor(es) do workflow

Outros SGWs

Aplicaes Clientes

Aplicaes Invocveis

Figura 4.2 - Modelo de Referncia de Workflow - Componentes e Interface [1]

5 - Excees na Execuo de Workflows

5.1 - Introduo
Tratamentos especiais, sob medida, so necessrios para enfrentar situaes que venham a ocorrer, durante a execuo de um workflow, situaes essas que no foram previstas durante a fase de modelagem [24]. Excees so distanciamentos que ocorrem entre o efetivo estado de execuo de um workflow e a situao normal, definida no projeto do workflow [22]. Podem resultar da falha de um executor (no completando a tarefa no tempo esperado ou completando de forma errada) ou da ocorrncia de um evento no previsto no ambiente. Embora excees possam ser, tambm, descritas sob o ponto de vista organizacional, interessa-nos abord-las enfocando suas repercusses na execuo do SGW. Esforos em pesquisas nessa rea tm focado no uso de mtodos transacionais para garantir a integridade de dados em workflows estruturados (ou transacionais), especialmente quando atividades concorrentes devem compartilhar dados. Outras pesquisas buscam modelos mais robustos e flexveis de deteco e recuperao de falhas para workflows onde o domnio dinmico [25]. Nesse captulo discutiremos a questo das excees que podem ocorrer durante execuo de workflows.

24

5.2 - Classificao de Excees

Segundo Barthelmess [22], as excees podem ser classificadas como a seguir: Excees de Infraestrutura: nessa classe enquadram-se falhas originadas por problema(s) no SGW, por erro de software, por falha na rede de comunicao, pelo fato de estaes, SGBDs ou impressoras estarem offline, etc. Excees de infraestrutura devem ser tratadas pelo prprio SGW, na medida em que dizem respeito, exclusivamente, ao seu prprio funcionamento (e no ao workflow, propriamente dito). Excees de informao: ocorrem quando os requisitos (que podem ter mudado) no correspondem ao que foi modelado. Excees de Dados: excees de dados ocorrem por erros ou ausncia de dados, tipicamente identificados durante a execuo das atividades onde os mesmos so usados. Essas excees so, em geral, tratadas atravs de nova(s) execuo(es) da(s) atividade(s) que os produziram. Excees de Sinal: so produzidas por informao assncrona externa que, de alguma forma, altera o fluxo normal (conforme modelado) de trabalho. Seus tratamentos so diversos, dependendo o workflow. Pode ser necessrio que sejam simplesmente interrompidas algumas atividades em execuo e/ou que sejam desconsiderados os efeitos de atividades que, porventura, j tenham terminado e/ou que sejam executadas outras atividades no necessrias para o fluxo normal de trabalho, ou mesmo que sejam executados workflows inteiros afim de reverterem os efeitos causados pela exceo (workflows ou transaes compensatrias), etc.

5.3 - Atomicidade de Falha em Workflows

Baseado na semntica de um workflow, o projetista do workflow pode especificar os requisitos de atomicidade de falha desse workflow [10]. Caso a noo tradicional de atomicidade de falha seja aplicada, a falha em qualquer tarefa resulta na falha de todo o workflow. Essa noo pode, entretanto, ser relaxada, na medida em que, em alguns casos, a execuo do workflow pode sobreviver falha de execuo de uma ou outra tarefa. Esse conceito pode ser implementado atravs da definio de um conjunto de atividades consideradas vitais que, se falharem, causam a falha de todo o workflow [9]. possvel, tambm, definir-se tarefas de contingncia, que so invocadas se as tarefas principais equivalentes falharem (excees tratveis). Cabe, portanto, ao projetista do workflow a definio do critrio de falhas aceitveis e das possveis tarefas de contingncia, cabendo ao SGW a permanente verificao se o critrio de falhas definido atendido e a instanciao, quando necessria, das tarefas de contingncia. Os possveis estados de trmino de um workflow que atendem ao critrio de falhas aceitvel so chamados de estados de trmino aceitveis. Qualquer outro estado de trmino chamado de estado de trmino no aceitvel, nos quais o critrio de atomicidade de falha estabelecido foi violado.

25

Um estado de trmino aceitvel possui ainda dois sub-estados: consolidado (committed) ou abortado. Um estado de trmino aceitvel consolidado aquele em que o workflow terminou atingindo seus objetivos originais. Caso contrrio, o estado de trmino chamado de estado de trmino aceitvel abortado, cujos efeitos indesejveis da execuo parcial devem ser desfeitos, conforme o critrio de atomicidade de falha estabelecido. Diante de um estado de trmino no aceitvel, o SGW deve procurar trazer o workflow de volta a um estado aceitvel.

5.4 - Recuperao de Workflows Diante de Falhas

O objetivo da recuperao diante de falhas na gerncia de workflows garantir a atomicidade de falha definida em tempo de modelagem [10]. Os procedimentos de recuperao devem garantir que, se uma falha ocorrer durante a execuo do workflow, o mesmo dever ser levado a um estado de trmino aceitvel (abortado ou consolidado) para, da prosseguir, como se a falha no tivesse ocorrido. A recuperao do contexto do ambiente de execuo necessita que sejam recuperadas as informaes de estado do executor e de estado de execuo de cada tarefa no momento anterior falha, o que implica que essas informaes sejam armazenadas usando-se um mecanismo de armazenamento estvel. O mesmo cuidado deve ser tido no armazenamento das filas de mensagens efetivamente transmitidas e recebidas pelos diversos executores at o momento da falha, de forma a evitar-se que, na recuperao, qualquer mensagem seja enviada duas vezes ou que seja esquecida. Embora os requisitos transacionais ACID usuais sejam muito fortes ou mesmo no implementveis em aplicaes de workflow, esses devem satisfazer a um conjunto limitado de propriedades transacionais que garantem que um processo no deixado em um estado inconsistente [10]. Essa abordagem do problema de tratamento de falhas, discutida em [10] sob o ttulo "Workflows Transacionais", baseia-se, como vimos, em pontos de checagem (checkpoints) e em reverso (rollback). A mesma permite o tratamento adequado de falhas para as formas mais estruturadas de workflows, enquanto que para outras, onde o domnio dinmico (onde h mudanas contnuas e imprevisveis do negcio), ou onde a re-execuo, descarte de resultados ou reverso de execuo (undo) de etapas impossvel ou extremamente custoso, so necessrios mtodos mais flexveis de recuperao de falhas. Nesses casos imprescindvel a habilidade de adaptar-se processos, em tempo de execuo, em resposta a falhas ou mudanas no negcio, onde tcnicas de Inteligncia Artificial (IA) podem ser aplicadas [25].

5.5 - Execuo Offline (com Desconexo)

Nas duas definies que apresentamos para workflows esto presentes os conceitos de coordenao e colaborao. Coordenao no s pressupe uma certa ordem de execuo das etapas (colaborao) como, no caso da maioria dos processos (pelo menos os de negcio), necessrio que essa ordem de execuo das atividades gere, para cada etapa,

26

uma correspondncia com pontos de incio e fim em uma escala de tempo. Consideradas as possveis tolerncias de tempo, o SGW deve dispor de mecanismos de alerta/contingncia quando uma colaborao no realizada no tempo previsto, seja por falha no executor, seja por quebra (voluntria ou no) no link de comunicao entre este e os demais executores. Operao com desconexo, por uma razo ou por outra, identificada como uma das muitas maneiras de utilizao dos computadores no futuro [30], sendo bvio que se deva tentar combin-la com workflows. Do ponto de vista do SGW, os dois casos anteriores so idnticos - a colaborao no foi realizada - e a soluo do problema depende do negcio. Em determinados casos a desconexo pode no ser crtica, por exemplo nas situaes em que os SGWs possam estar "preocupados" apenas com o de trmino de uma atividade (horrio e seus resultados), necessitando se sincronizao apenas no final desta, e quando a atividade no compartilha estado com alguma outra sendo executada em outro stio. Nesses casos, a execuo da atividade pode se dar, desde que os artefatos necessrios e o ambiente de execuo estejam disponveis no n que esteja operando sem conexo [26]. Quando tratamos de execuo distribuda de workflows (item 4.3.3), mencionamos que, no caso de migrao, a instncia de execuo de um workflow leva consigo seu estado e os demais artefatos (dados), a medida em que sua execuo passa de um servidor a outro. Essa alternativa (que no a ampla replicao pura e simples de controle e dados) bastante interessante no caso de possibilidade ou necessidade de desconexo, j que cada n de execuo torna-se auto-suficiente em termos de dados e processos. Nossas pesquisas esto voltadas para Ensino Distncia. Nesse contexto entendemos que a aplicao de workflows bastante proveitosa, j que, alm da coordenao das atividades que constituem os mdulos, consenso, modernamente, que a interao dos diversos executores - professores e alunos - deva se dar de forma colaborativa. Atividades como leitura e avaliao individual podem (s vezes devem) ser executadas estando os alunos desconectados do ambiente. Antes de execut-las os alunos se conectam ao ambiente, recebem todo o material necessrio incluindo os mdulos executores, se desconectam, executam as tarefas e, ao final, se conectam novamente, informando ao SGW os resultados de suas atividades.

6 SGWs e SGBDs
H quem considere que SGWs so aplicaes que "rodam" sobre sistemas de gerncia de bancos de dados (SGBDs) [13]. H quem considere que essa abordagem simplifica o projeto de um SGW, mas que a mesma no contempla a natureza distribuda de aplicaes de workflow, impondo srias limitaes em termos de escalabilidade e confiabilidade [29]. H ainda [11] quem procure identificar semelhanas entre SGBDs e SGWs, buscando aplicar as j to bem consolidadas solues dadas para os problemas encontrados em SGBDs nos problemas encontrados em SGWs (vide captulos 4 e 5). Nesse captulo investigaremos essa questo, procurando relacionar algumas das diversas abordagens encontradas na literatura considerando duas perspectivas: estrutura de armazenamento de dados e funcionalidade.

27

No captulo 2 apresentamos as caractersticas dos sistemas de gerncia de workflows, abordando, no item 2.4, as funcionalidades tipicamente disponveis nestes sistemas. Para que possamos identificar as semelhanas entre SGBDs e SGWs devemos, tambm, relacionar as caractersticas e funcionalidades dos SGBDs, o que faremos, de forma resumida, a seguir. Um SGBD uma coleo de arquivos relacionados e um conjunto de programas que permitem que os usurios dos dados os acessem [9]. SGBDs permitem [9][10]: Que os usurios dos dados tenham vises abstratas dos mesmos; Integrar dados operacionais de um empreendimento e proporcionar acesso centralizado, e portanto controlado, a esses dados; Reduzir a redundncia, inconsistncia e dificuldade de acesso de dados; Prover isolamento entre dados e aplicaes que os acessam; Manter a integridade dos dados com respeito a regras estabelecidas; Garantir a atomicidade de transaes; Eliminar a possibilidade de anomalias advindas de acessos concorrentes; Prover acesso aos dados com segurana; Prover mecanismos de recuperao diante de falhas de hardware e de software.

Levando-se em considerao essas caractersticas e funcionalidades, podemos definir SGBDs como sendo conjuntos de componentes de software que provm persistncia, recuperao, compartilhamento, integridade e segurana de dados de forma transparente aos seus usurios. Passando a considerar, tambm, que os dados esto geograficamente dispersos, necessitamos incorporar aspectos provenientes da rea Redes de Computadores, na medida em que a tecnologia de sistemas de bancos de dados distribudos (SGBDDs) a unio das tecnologias de redes e de bancos de dados. "Sistemas de gerncia de bancos de dados distribudos estendem as facilidades usuais de gerncia de dados de tal forma que o armazenamento de um banco de dados possa ser dividido ao longo dos ns de uma rede de comunicao de dados, sem que com isto os usurios percam uma viso integrada do banco" [12]. A idia de utilizar-se SGBDDs atrativa sob muitos aspectos, dentre os quais citamos: SGBDDs permitem que cada setor de uma organizao geograficamente dispersa mantenha controle de seus prprios dados; SGBDDs oferecem compartilhamento a nvel global no uso destes dados; SGBDDs podem diminuir os custos de comunicaes, pois o projeto de distribuio considera, dentre outros aspectos, que os dados devem estar onde so mais usados; SGBDDs facilitam a escalabilidade do sistema como um todo, notadamente quando os comparamos aos sistemas centralizados baseados em equipamentos de grande porte; SGBDDs aumentam a confiabilidade atravs da replicao das partes crticas do banco em mais de um n.

28

Re-visitando a relao das caractersticas e funcionalidades dos SGWs (e SGWDs), podemos observar que, alm dos servios tipicamente oferecidos pelos SGBDs e SGBDDs convencionais necessitamos, para a gerncia automatizada de workflows, de: Um mecanismo que armazene os estados (igualmente dados) dos processos. Capacidade de armazenamento e recuperao de artefatos diversos, de no estruturados a completamente estruturados, e.g., documentos, cdigo executvel, imagens, vdeo, som, arquivos de dados, etc. Capacidade de gerenciar a execuo de processos, escalonando-os, verificando pr-condies estabelecidas para execuo de processos, disparando avisos aos executores, etc.

Em [13] encontramos: "Os sistemas de Gerncia de Workflows atuais usam um Sistema de Gerncia de Bancos de Dados para armazenar descries das atividades e implementar toda a funcionalidade do workflow em mdulos que rodam sobre o SGBD." Em outras palavras, enquanto bancos de dados garantem o armazenamento seguro e fcil acesso a grandes conjuntos de dados, sistemas de gerncia de workflows objetivam o suporte bsico para o fluxo de informao nos mesmos ambientes em que os bancos de dados so usados [28]. importante ressaltar-se que no h um consenso a respeito dos SGWs rodarem sobre SGBDs de mercado. Muitos autores falam em utilizar-se extenses de SGBDs, enquanto outros como em [2], defendem a alternativa de se dispor de uma infraestrutura especfica de gerncia de dados de workflows. Verificamos que sistemas de gerncia de bancos de dados orientados a objetos (SGBDOOs) atendem a boa parte das necessidades de SGWs. Estes possuem, tambm, um carter ativo, pois no necessrio que um usurio sempre acione um comando explicitamente para que o SGW execute ou interrompa uma operao; muitas aes do sistema devem ser executadas quando o mdulo gerenciador percebe determinadas condies. Essa percepo pode ser implementada no prprio SGBD (nesse caso dito ativo) ou atravs de software em uma camada externa que verifica constantemente os estados dos processos. SGWs podem, dessa forma, ser entendidos como uma camada de aplicao que opera sobre uma camada de software que trata do acesso aos dados (esta ltima sendo o software de um SGBD convencional). Podem, tambm, compor-se de uma camada de software menor que opera sobre um SGBD no convencional (OO, Objeto-Relacional, Relacional-Estendito, etc.). Podem, tambm, ser implementados atravs de uma estrutura monoltica composta por camadas conceituais distintas, organizadas exatamente como no modelo de arquitetura ANSI/SPARC de SGBDs. Embora seja um fato bem conhecido que os requisitos para um sistema de workflow em termos de escalabilidade e confiabilidade excedem aos requisitos das

29

tecnologias de banco de dados e de processamento de transaes [27], essas tecnologias esto bastante mais adiantadas que as tecnologias usadas nos motores dos SGWs. Um aspecto importante quanto funcionalidade e que ressalta uma grande diferena entre SGBDs e SGWs que nestes, ao contrrio do que ocorre naqueles, o sistema pode no dispor de todos os elementos para abortar uma transao [28]. Em SGWs, muitas vezes, necessrio que um agente humano participe do tratamento de uma exceo, na medida em que estas podem variar de problemas de hardware/software a mudanas no negcio.

7 - Concluses e Trabalhos Futuros

Neste trabalho apresentamos os principais conceitos e caractersticas dos sistemas de workflow buscando, em uma primeira etapa, nos ater a ambientes centralizados. Mais adiante, em funo na necessidade dos fluxos de trabalho atravessarem as fronteiras setoriais (departamentos, filiais, etc., em uma mesma empresa) e mesmo corporativas (B2B), verificamos a necessidade de estender os SGWs para que permitissem o trabalho cooperativo de equipes situadas em locais geograficamente distantes. Consideramos, para os casos mais gerais, a possibilidade de autonomia local de uso, feita de forma integrada com os demais stios e de forma transparente sob o ponto de vista dos usurios. Essa autonomia com integrao facilitada, hoje em dia, tambm pelo advento da tecnologia de Web Services, que se encontra em voga. Tais requisitos, aliados s solues tipicamente adotadas em SGWDs comerciais, levaram alguns autores a procurarem estabelecer uma correlao desses com SGBDDs, objetivando solues comuns para problemas identificados como comuns. Essas correlaes, entretanto, so pouco teis, na medida em que os problemas que podem ocorrer durante a execuo de fluxos de trabalho pouco estruturados so inmeros, dificilmente previsveis, quase invariavelmente carecem de solues de negcio e que, por essa razo, muitas vezes no so considerados na fase de modelagem. No ficou clara a inadequao de SGBDs comerciais e suas extenses para persistncia dos artefatos tipicamente manipulados pelos SGWs, embora, como afirmamos anteriormente, haja na bibliografia consultada vrias referncias a essas limitaes e inadequaes por parte dos SGBDs comerciais. Essas limitaes no foram justificadas de forma convincente ou sequer explicitadas. Cabe, portanto, que uma experimentao seja feita futuramente. Nesse sentido, iniciamos no TecBD um projeto de implementao do prottipo de um gerenciador de contedo de objetos acadmicos (PSs, PDFs, PPTs, cdigos fontes, etc.) cujo mdulo inicial dever estar concludo at o final desse ano. Mais adiante deveremos, tambm, implementar parte do ambiente que est sendo concebido para o projeto PGL (Partnership in Global Learning), que far o gerenciamento distribudo de objetos de aprendizado e de fluxos de controle na modelagem e execuo de cursos distncia. Ambos os projetos usaro, dentre outros recursos, o DB2 da IBM e suas extenses.

30

Esse trabalho foi elaborado com o propsito de permitir a familiarizao do autor com os conceitos e tcnicas usados em sistemas de workflows, assim como servir como uma abordagem inicial do assunto com vistas ao levantamento dos principais requisitos de persistncia dos artefatos e ambiente de controle dos SGWs.

Referncias Bibliogrficas
[1] [2] [3] [4] [5] [6] [7] Workflow Management Coalition. The Workflow Reference Model, document number TC00-1003, 1995. http://www.wfmc.org/. Bszrmenyi, L.; Groiss, H.; Eisner, R., Adding Distribution to a Workflow Management System. Araujo, R. M.; Borges, M. R. S., Sistemas de Workflow, XX Jornada de Atualizao em Informtica, Congresso da SBC - 2001. Allen, R., Workflow: An Introduction, http://www.wfmc.org/, em novembro/2001 white-paper baixado de

Moro, M. M., "Workflow" em www.inf.ufrgs.br/~mirella/workflow/work.html, acesso em dezembro/2001 CRUZ, T., "Workflow: A Tecnologia que vai revolucionar processos", 2 ed., 2000, Ed. Atlas, So Paulo. ULTIMUS, 1998, 40 Essential Features of Workflow Software You Will Not Find in Lotus Notes, http://www.ultimus-workflow.de/einfwf.htm, acesso em dezembro/2001 ULTIMUS, 1988, Even the Best Form Software Lacks Essential Workflow Features, http://www.ultimus-workflow.de/einfwf.htm, acesso em dezembro/2001 zsu, T., Valduriez, P., Princpio de Sistemas de Bancos de Dados Distribudos, traduo da 2a. edio americana, 2001, Editora Campus. Silberschatz, A., Korth, H., Sudarshan, S., Database System Concepts, 3rd. Edition, 1997, McGraw-Hill. Michirefe, M. S. C., Em Busca de Um Sistema de Gerncia de Workflow Baseado na Tecnologia de Sistemas de Gerncia de Bancos de Dados, Dissertao de Mestrado, Departamento de Informtica, PUC-Rio, dezembro de 1998. Casanova, M. A., Moura, A. V., Princpios de Sistemas de Gerncia de Bancos de Dados Distribudos, edio eletrnica revisada, 1999.

[8]

[9] [10] [11]

[12]

31

[13] [14]

Ailamaki, A., Ioannidis, Y. E., Livny, M., Scientific Workflow Management by Database Management, SSDBM, 1998. Oliveira, T. C.; Mathias Filho; I., Lucena, C. J. P., A Framework Based Approach to Workflow Software Development. Monografias da Cincia da Computao PUC/Rio 2001 Khoshafian, S., Buckiewicz, M., Introduction to Groupware, Workflow, and Workgroup Computing, Wiley, 1995. Ailamaki, A., Ioannidis, Y. E., Livny, M., Scientific Workflow Management by Database Management, 1998. E-workflow - the workflow portal. http://www.e-workflow.org/, acesso em 11/7/2002. Workflow Management Coalition - Terminology & Glossary, document number WFMC-TC-1011, fevereiro de 1999. OMG Unified Modeling Language Specification, Version 1.4, setembro de 2001. Georgakopoulos, D., Amit, S., An Overview of Workflow Management: From Process Modeling to Workflow Automation Infrastructure. Distributed and Parallel Databases, no. 3, 119-152, 1995. Barthelmess, P., Wainer, J., Workflow Modeling, CYTED-RITOS International Workshop on Groupware, Lisboa, Portugal, pp 1-13, setembro de 1995. Barthelmess, P., Wainer, J., Workflow Systems: a few definitions and few suggestions. Proceedings of the 1995 Conference on Supporting Group Work, Milpitas, CA, USA, agosto de 1995. Fowler, M., Scott, K., UML Essencial, Bookman, 2a. edio, 2000. Barthelmess, P., Sistemas de Workflow: Anlise da rea e Proposta de Modelo, dissertao de mestrado apresentada ao Instituto de Computao da UNICAMP, 1996. Myers, K. L., Berry, P. M., At the boundary of workflow and AI, AAAI-99 Workshop on Agent-Based Systems in The Business Context, 1999. Alonso, G, et al, Exotica/FMDC: Handling Disconnected Clients in a Workflow Management System, 3rd International Conference on Cooperative Information Systems, 1995. Alonso, G. Schek, H.. Database Technology in Workflow Environments, Informatik/Informatique, Zeitschrift der schweiz. Informatikorganisationen (Journal of the Swiss Computer Society), 1996.

[15] [16] [17] [18] [19] [20]

[21] [22]

[23] [24]

[25] [26]

[27]

32

[28]

Alonso, G., The Role of Database Technology in Workflow Management Systems. Panel Position Paper, Proceedings of the First IFCIS International Conference on Cooperative Information Systems (CoopIS'96), 1996 Alonso, G., Reinwald, B., Mohan, C., Distributed Data Management in Workflow Environments, Proceedings of the. 7th International Workshop on Research Issues in Data Engineering (RIDE'97), 1997 Alonso, G., Agrawal, D., Abbadi, A., Mohan, C., Functionality and Limitations of Current Workflow Management Systems, 1997.

[29]

[30]

33