de Workflow Baseado em Agentes Móveis

Transcrição

1 Suporte à Especificação da WfMC no MABflow, um Sistema de Workflow Baseado em Agentes Móveis Wagner Saback Dantas, Flávio Morais Assis Silva 1 Laboratório de Sistemas Distribuídos Departamento de Ciência da Computação Universidade Federal da Bahia Av. Ademar de Barros, s/n, Campus de Ondina Salvador, Bahia wgsaback@im.ufba.br, fassis@ufba.br Resumo. O estudo de workflows, processos de negócio ou fluxos de trabalho, confere um trato estrutural a modelos os quais, em síntese, descrevem um conjunto de tarefas que é realizado em organizações e atendem a um conjunto de regras específicas. A fim de oferecer um suporte ao conhecimento desses fluxos, uma representação por meio de ontologia é fundamental, dentre outros fatores, para a especificação e execução posterior dos processos, além de uma possível interoperabilidade entre variados sistemas gerenciadores desses workflows. Neste trabalho, foram estabelecidas novas definições dos principais elementos do workflow e desenvolvidos alguns componentes da nova versão do sistema MABflow, um sistema de workflow baseado em agentes móveis, em desenvolvimento no LaSiD/DCC/UFBA. As definições são baseadas no modelo de referência da Workflow Management Coalition (WfMC), instituição voltada para o estabelecimento de padrões para interoperabilidade entre produtos de workflow. Com o suporte à especificação da WfMC, o MABflow melhora em funcionalidade devido à sua capacidade de operar com ferramentas de especificação de sistemas de gerenciamento de workflows, útil em aplicações reais. Além disso, o MABflow tem sido usado no LaSiD na investigação de problemas decorrentes no desenvolvimento de sistemas distribuídos. Palavras-chave: Agentes Móveis, Workflows, Especificação da Wf MC Abstract. In general terms, a workflow corresponds to a modelling of a business process. Typically a workflow consists of a set of tasks that must be executed according to a set of rules (among them are rules to determine the sequence in which the tasks are to be executed, how tasks must be synchronized, etc.). In the context of workflows, ontologies are a fundamental conceptual tool for introducing knowledge about the workflow itself and its environment. In particular, the use of ontologies has been proposed for: (i) the specification and execution of workflows (ii) supporting the interoperability among different workflows management systems. This paper presents and describes the main components of a new version of MABflow, a mobile agent-based workflow management systems, under development at LaSiD/DCC/UFBA. Among the main features of this new version is the integration of support for the ontology for workflow management systems defined by the Workflow Management Coalition (WfMC), an organization whose goal is to promote the interoperability between workflow management systems. Supporting the WfMC standards improves the functionality and usefulness of the system (fundamental for using it to model real

2 applications) and makes the system interoperable with independently developed workflow management specification tools. MABflow has been a useful system at LaSiD to investigate the problems which arise in the development of large and dynamic distributed systems. Keywords: Mobile Agents, Workflows, WfMC Specification 1. Introdução A realização de processos de negócio ou workflows, que basicamente envolvem distintos entes computacionais, requer o uso de modelos que reflitam o universo de termos (e suas correlações) pertencentes aos processos em questão. Isto se acentua ainda mais com os esforços oriundos das linhas de pesquisa em groupware e CSCW (Computer Software Colaborative Work), além da proximidade do contexto do workflow com a rede mundial de computadores, a Internet, através de novos modelos relacionais nas organizações em geral [2]. Ontologias, através da representação do conhecimento, provêem um alicerce necessário para tal cenário. Uma vez que todas as informações relevantes aos processos de negócio podem ser descritas, sistemas de workflow conseguem interpretá-las e usá-las durante suas execuções. Como meio para implementação dos sistemas de workflow, agentes móveis determinam a execução das tarefas no contexto do processo de negócio. Ademais, são capazes de contornar as heterogeneidades no ambiente de execução, sejam sistemas operacionais ou arquitetura de computadores distintos, e passíveis de contemplar os requisitos de conhecimento e conseqüente tradução dos fluxos. O trabalho corrente oferece uma esquematização dos principais elementos presentes em fluxos de trabalho e seu uso no desenvolvimento de uma nova versão do MABflow, um sistema de workflow com agentes móveis. Nesta nova versão, a especificação dos processos de negócio seguem o modelo de referência da Workflow Management Coalition, a Wf MC [17], o que permite no MABflow a integração com ferramentas de especificação de sistemas de gerenciamento de workflows. A Wf MC é uma organização que congrega entidades envolvidas com workflows (empresas, pessoas físicas, etc.) e que visa à padronização da terminologia do workflow. Na seção a seguir, será abordada conceitualmente a ontologia base para definição das informações do fluxo de trabalho em seus principais aspectos e formas de representação. Em seguida, serão apresentados conceitos relacionados aos processos de negócio ou workflows e o modelo de referência da Wf MC (seção 3). Posteriormente, serão apresentados conceitos básicos sobre agentes móveis e sua relação com sistemas de workflow (seção 4), e a implementação de fato do suporte à especificação da Wf MC no MABflow (seção 5). Por último, comentários finais (seção 6). 2. Ontologia De acordo com [11], ontologia é segundo o aristotelismo, parte da filosofia que tem por objeto o estudo das propriedades mais gerais do ser, apartada da infinidade de determinações que, ao qualificá-lo particularmente, ocultam sua natureza plena e íntegra. Na computação, mais especificamente na inteligência artificial, a ontologia, também citada como ontologia de domínio, é uma visão delimitada do mundo haja vista um subconjunto do conhecimento [10]. Assim, o que existe é o que pode ser representado dentro de um agrupamento menor do conhecimento, funcionando a ontologia como uma especificação explícita de

3 uma conceitualização [10]. A aparição da ontologia decorre do estudo dos fenômenos incidentes no mundo e uma posterior esquematização não ambígua dos mesmos, com o objetivo de representá-los, analisar seus principais elementos e relações entre estes Construção de Ontologias O processo de construção de uma ontologia origina-se da percepção de um domínio de aplicação desejado, seguida de uma tentativa de descrição deste domínio diminuído por meio de uma definição mais formal. Termos essenciais, seus significados e relacionamentos no âmbito escolhido estão prescritos nesta definição. Uma simplificação do processo descrito pode ser vista na Figura 1. Conhecimento Coletivo Senso Comum Domínio de Aplicação Legenda (1) Visão do mundo delimitada; (2) Conceitualização do domínio de aplicação; (3) Expressão via ontologia (especificação formal); (4) Representação da ontologia via linguagem; (5) Uso em programas/sistemas que necessitem de base de conhecimento. Ontologia de Domínio Figura 1: Processo simplificado de criação de ontologias de domínio As decisões tomadas durante todo o procedimento descrito exigem o conhecimento do sub-universo de informação envolvido. Com efeito, a ontologia será tão melhor descrita à proporção que os seus criadores tiverem uma noção maior do âmbito-alvo. Isto é, o sucesso na criação de uma ontologia está diretamente ligado ao quão seus autores são conhecedores das características principais, dos elementos constituintes, dos fatores interligantes e das prováveis excepcionalidades Benefícios No sentido geral, uma ontologia suplanta a necessidade de se representar informações particulares em certos setores de interesse. Dentre os usos da ontologia estão: base de conhecimento para especificações de aplicações [20], retorno de informação em sistemas [12] e elemento de integração entre sistemas heterogêneos, ou, em um sentido mais geral, entre pessoas e máquinas [20]. Assim, a reprodução do conhecimento em uma ontologia de domínio somada à possibilidade de operação entre os que utilizam esta ontologia, resulta na geração colaborativa de definições importantes a respeito de uma área de aplicação, bem como no aprendizado, refinamento e reuso da informação correspondente. Uma discussão neste sentido pode ser encontrada em [16]. Conseqüentemente, a ontologia proporciona o surgimento de padrões, como o modelo de referência da Wf MC para sistemas de workflow [18]. Pressupondo-se uma adoção total à ontologia em questão, não há preocupação com estruturas de dados e linguagem de programação usadas, já que os dados trafegados conseguem ser assimilados por todos os sistemas previstos para uma mesma ontologia.

4 3. Processos de Negócio (Workflows) Embora não exista um denominador comum sobre o conceito de workflow na literatura [8], podemos definir um workflow a princípio como a modelagem de um processo de negócio formado por um conjunto de tarefas que determina o alcance de um objetivo global. Este processo agrega um conjunto de informações (processos de informação) ou materiais (processos materiais) [8]. As informações são manipuladas durante o próprio fluxo segundo regras definidas, no intuito de se alcançar os objetivos de negócio [2] e reflete a automação de um processo de negócio, em parte ou em seu todo, onde documentos, informações ou tarefas são passados de um participante para outro a fim de serem executados conforme um conjunto de regras [18]. Um sistema de gerenciamento de workflow (WfMS), citado também aqui como sistema de workflow, é o software encarregado em interpretar, criar, executar, coordenar e monitorar fluxos de trabalho [2]. Nele, existem ferramentas necessárias que contemplam cada uma destas funcionalidades com o propósito de automatizar o workflow em vista. Organização Fluxo de trabalho III Sistema de Workflow I II Especificação do processo Figura 2: Ilustração do processo de automatização de um workflow Durante o processo de automatização de um workflow (Figura 2), o WfMS atua a partir do passo II. O passo I simboliza a especificação do processo de negócio (atividades, executores, condições de realização das atividades, etc.) e é traçado pela organização que utilizará mais tarde o WfMS. Neste planejamento inicial, define-se cada requisito e peculiaridade do processo de negócio, incluindo recursos a serem manipulados, participantes e critérios para cada operação envolvida no contexto. Um documento final, isto é, uma especificação do processo, possivelmente gerada por alguma ferramenta própria para modelagem de processos, retratará formalmente todos os pontos discutidos e acordados por aquela organização. A interpretação do modelo projetado (passo II da Figura 2) originará um modelo de fluxo de trabalho, o qual, através de uma máquina de execução (engine), criará instâncias [2] ou casos [6] do processo (passo III da Figura 2). Uma visualização externa, que pode ser implementada por um módulo de administração em separado, determinará o estado do processo através de certas informações, como a transação que está sendo realizada ou um indicador de qual é o estado genérico do processo Elementos Principais Um workflow envolve um conjunto de componentes que servem como modelobase para a automatização do mesmo. Atividades, participantes, políticas de realização do fluxo e transições entre atividades são alguns dos elementos principais de um workflow.

5 Uma atividade é uma unidade de execução dentro do workflow. São elementos transformadores dentro do workflow, agindo nas informações do processo de negócio em questão (documentos, por exemplo). Pode ser realizada em uma única etapa de execução (atividade atômica), embora haja atividades não atômicas ou abstratas [6]. As atividades podem estar dispostas em seqüência (atividades dependentes entre si), em paralelo (atividades não dependentes entre si) ou alternativas (uma atividade é executada ao invés de outras em um mesmo momento) [2]. Transições são passagens ou conexões entre cada atividade prevista no fluxo de trabalho. Atuam na determinação das etapas seguintes workflow, confirmando suas etapas que já estão executadas e promovendo a sincronização e o seqüenciamento das operações. Comumente, definem condições ou regras cuja avaliação (verdadeiro ou falso) aponta a próxima atividade do processo de negócio que será realizada. Além de atividades e transições, participantes compõem também o workflow. Incumbem-se de executar as atividades às quais estão ligados conforme uma designação pertencente ao modelo da organização. Presumivelmente, podem se apresentar como um ente humano, um grupo simbólico formado por entes humanos (ou não) e outros grupos simbólicos ou uma máquina. Em algumas situações, não executam literalmente uma atividade em especial, como em tarefas que apenas roteam o fluxo de trabalho O Modelo de Referência da WfMC Uma vez que os WfMS estabeleceram-se como a tecnologia para implementação de processos de negócio, diferentes produtos surgiram oferecerendo funcionalidades para representação e automatização dos fluxos de trabalho. Mas, requisitos de reaproveitamento e continuidade dos processos implantados nas organizações poderiam não ser cumpridos pelo grau de especialização e escassez de uma representação em comum nos WfMS existentes. Assim, uma padronização que identificasse os pontos principais percebidos nos sistemas de workflow era necessária. Através de um padrão estabelecido, seriam atingidas a flexibilidade no uso de qualquer WfMS, permitindo a interoperabilidade entre os mesmos, inclusive na união de sistemas que contemplassem características diferentes, e a facilidade de uso do workflow em vários produtos comerciais [8]. O modelo de referência da Wf MC [17] objetiva suplantar esse quadro, definindo os principais componentes nos sistemas de workflow e as interfaces onde os mesmos conseguem interoperar entre si. Enumeradas de 1 a 5, as interfaces compreendem as ferramentas de definição de processo (interface 1), a comunicação com aplicações workflow cliente (interface 2), com chamadas a aplicações (interface 3), com outros WfMS (interface 4) e com ferramentas de administração e monitoramento (interface 5). Neste trabalho, será tratada apenas a primeira interface [18], que define a comunicação do WfMS com ferramentas de especificação de processos de negócio. Nesta interface, é especificado o formato de especificação e troca de processo de negócio, a Workflow Process Definition Language (WPDL). O trabalho conta também com uma interface do WfMS com chamadas a aplicações (interface 3). Entretanto, tal interface não segue a especificação da Wf MC Workflow Process Definition Language (WPDL) A WPDL é o formato para definição e troca de processo de negócio entre WfMS (ou entre a engine de um WfMS e uma ferramenta de especificação) que seguem o padrão de referência da Wf MC e a gramática usada para sua descrição. Sua representação é independente de uma arquitetura de computador específica, e a transmissão decorrente da troca do processo independe do meio de transmissão utilizado para transporte do modelo.

6 Na WPDL, encontram-se as definições dos principais elementos que estruturam um workflow (atividades, participantes, transições, etc.) e suas relações (conforme o meta-modelo mínimo mostrado na Figura 3), além do modelo de processo. O modelo de processo é o contexto que contém um ou mais processos de negócio e mais alguns componentes do workflow em comum a estes processos de negócio. Além das definições dos elementos do workflow e do modelo de processo, mecanismos de extensibilidade para inclusão de informações de um WfMS em particular estão presentes. Definição do Processo do Workflow Consiste em Consiste em Dados Relevantes do Workflow Participantes Aplicação do Workflow Atividade do Workflow Informação de Transição do Workflow Pode usar Pode usar É realizado por Pode Chamar De Para Pode usar Figura 3: Meta-modelo mínimo (simplificado) previsto pela Wf MC Para os WfMS que suportam a WPDL como padrão de troca de processos de negócio, dois paradigmas referentes à importação e exportação de documentos de processo de negócio são sugeridos: filtros locais ao mesmo podem traduzir da sua representação para o padrão Wf MC e vice-versa, ou um servidor central encarregar-se-ia de fazê-lo. Entretanto, espera-se que o WfMS implemente, além da importação de um arquivo com o processo de negócio em seu formato particular, obviamente, a exportação deste formato para o padrão Wf MC. 4. Agentes Móveis Agente móvel ou agente é um componente de software, o qual, mediante um processo de negócio e informações internos, consegue caminhar autonomamente em um ambiente distribuído 1 (uma rede de computadores). Neste ambiente, o agente pode cooperar com outros agentes e até interagir com o usuário a depender do seu nível de inteligência, realizando tarefas em cada um dos nós da rede, com o propósito de se cumprir um objetivo final maior. Agentes também são capazes de executar e migrar para nós da rede desconsiderando suas peculiaridades, como sistemas operacionais, interfaces de comunicação e arquiteturas de hardware, podendo mudar o seu comportamento mediante alguma situação inusitada como a desconexão de algum ponto na rede de computadores [4][19]. Um agente é formado por dados internos, utilizados pelo agente durante sua execução, código (instruções do agente) e metadados (informações sobre o agente, como seu estado global) [4]. A partir do processo de negócio descrito no agente e de seus metadados, agentes conseguem decidir dinamicamente em qual localidade executará [19]. Com isto, ao contrário de outros modelos de computação distribuída, nos agentes móveis, o fluxo de execução se move pelo ambiente distribuído [4], dirigindo-se à localidade no ambiente distribuído cuja fonte de dados é relevante à realização da tarefa em questão e não para a que disparou inicialmente o agente (como em arquiteturas cliente/servidor [19], por exemplo). 1 O ambiente genérico onde os agentes executam, a agência e o sistema de agentes são também conhecidos por DAE (Distributed Agent Environment), sistema de agente e tipo de sistema de agente respectivamente segundo o padrão MASIF da OMG [4]

7 Denominamos uma agência o lugar lógico dentro do ambiente distribuído onde ocorrem as etapas do ciclo de vida de um agente [4]. Na agência, um agente basicamente pode ser criado, executado, transferido e replicado em agentes filhos. Uma agência, assim como o agente, possui um identificador único em todo o ambiente distribuído. Quando o agente é movido de uma localidade para outra dentro do ambiente distribuído, sua execução é interrompida na agência origem, o mesmo juntamente com sua estrutura é movido para a agência destino e sua execução continua na agência destino. Sistema de Agentes é a tecnologia que fornece a funcionalidade necessária para suportar o ciclo de vida de agentes. Pode permitir uma ou mais linguagens de programação para programação de agentes, sendo algumas de domínio público, como Java é o caso do Voyager e IBM Aglets, dentre outros e outras desenvolvidas ou estendidas para agentes, como Telescript (linguagem telescript) e D Agents (extensões das linguagens Tcl/Tk e Java). Uma breve descrição sobre sistemas de agentes e discussões acerca de linguagens de programação para agentes pode ser encontrada em [4] Agentes Móveis e Workflows Agentes móveis e workflows estão relacionados a partir do momento que instâncias de processos de negócio e do seu modelo de organização adjacente podem ser interpretadas e efetuadas por agentes escalados para tal fim. Neste caso, os elementos deste processo são convertidos em similares no paradigma de agentes móveis, sendo a base de especificação de um workflow igualmente uma base de especificação para a coordenação de um agente [9]. Em um cenário, a sequência de atividades a serem executadas dentro do fluxo de trabalho, tratadas uma a uma em agências distintas ou não no ambiente distribuído, é feita por um agente que a percorre coordenadamente, interagindo com usuários e aplicações legadas se fosse necessário. Deste modo, o agente móvel executor incorpora um participante válido no modelo da organização [9] à proporção que realiza uma atividade que é designada àquele participante no workflow. Para o caso de várias subtarefas independentes serem processadas em paralelo dentro de uma atividade, agentes filhos cooperantes relacionados ao agente primário podem ser criados. As transições do workflow são demarcadas como as passagens entre atividades. Cada transição é representada pela mudança de agências, caso a execução entre duas atividades contíguas ocorra em locais distintos na rede, ou na permanência em uma mesma agência. Nestas conexões, condições expressas pelo modelo organizacional subordinado ao processo de negócio podem ser testadas por intermédio dos metadados do agente ou de outros dados internos. Informações sobre o processo como um todo (status, agência atual, etc.) podem ser obtidas retornando-se dados do agente representante, como um histórico (rota realizada, participantes envolvidos, condições avaliadas, etc.) das etapas realizadas. E a ubiqüidade requisitada em certas organizações na realização de seus workflows, observado pela presença de outros dispositivos computacionais como laptops, notebooks, PDAs, etc., é alcançada. 5. Implementação do Suporte à Especificação da WfMC no MABflow MABflow é um sistema de workflow baseado em agentes móveis desenvolvido pelo Laboratório de Sistemas Distribuídos (LaSiD/DCC/UFBA). Em sua primeira versão, agentes em código Java são gerados a partir de definições em XML (EXtended Markup Language) embasadas numa gramática de processo de negócio bem simples em formato DTD (Document Type Definition), que descreve os elementos básicos de um workflow suportado. O ambiente de execução de agentes é implementado pelo Voyager, e a extração

8 das informações do processo de negócio em arquivo XML, necessárias para construção do agente representante, é conseguida via DXML (Dynamic XML), uma outra ferramenta da Objectspace, mesma empresa que desenvolve o Voyager. Mais informações sobre esta versão do MABflow podem ser encontradas em [7]. O trabalho corrente consiste em uma nova versão do MABflow que suporta a especificação prevista no modelo de referência da Wf MC através de um novo DTD. Este DTD segue a gramática WPDL (vide seção 3.6.2) em substituição ao DTD da versão anterior do MABflow. Assim, da mesma forma como antes, agentes são convertidos em código Java, só que na observância agora do modelo de referência da Wf MC. Isso faz do MABflow um sistema capaz de compartilhar documentos de definição de workflows com outros WfMS e ferramentas de especificação de workflows, como ferramentas UML, por exemplo, definindo-se agentes MABflow a partir de especificações UML [5]. Ao mesmo tempo, novas funcionalidades foram incluídas: a integração ao GMAS (Generic Management Agent System), um framework igualmente concebido no La- SiD/DCC/UFBA [3] que oferece serviços fundamentais para o manuseio de agentes; um servidor de ontologias para fornecimento de informações inerentes ao fluxo de trabalho [14], como a indicação dos prováveis atores de uma atividade no workflow; e uma nova estrutura do código do agente gerado a partir de sua definição em XML, baseado em listas de elementos do workflow especificado (atividades, transições, etc.) Tecnologias Usadas Na concepção do MABflow, algumas questões relativas à tecnologia foram consideradas: Tecnologias para organização e coleta de informações do workflow: a estruturação e coleta de informações do processo de negócio a ser executado pelo agente móvel induz a presença de um formato de dados e de ferramentas capazes de retornar informações presentes em tal formato. O uso do XML como formato reconhecido para estruturação de informações independente de plataforma computacional, e do digester 2, baseado no padrão de análise XML SAX, cobrem a premissa citada, e com a vantagem de serem tecnologias abertas ao público 3. Ambiente de execução dos agentes: o arcabouço para execução dos agentes é forneceido pelo GMAS, construído também em Java. O GMAS oferece interfaces genéricas desvinculadas de uma implementação particular de sistema de agentes, caso da versão inicial do MABflow que utiliza diretamente o Voyager. Na sua versão atual, o GMAS mapeia cada uma das suas chamadas padrões em chamadas do Voyager, permitindo o MABflow futuramente ser mapeado em outros sistemas de agentes construídos em Java, como o IBM Aglets ou Grasshopper, por exemplo. O GMAS, juntamente com um sistema de agentes mapeado, fornece funcionalidades como serviço de persistência, desconexão, nomes e visualização amigável dos agentes em uma interface gráfica O Agente MABflow Na sua primeira versão [7], um agente do MABflow possui em sua estrutura código, dados e estado de execução, onde: Código: conjunto de instruções a serem executadas pelo agente durante sua execução; 2 Digester é uma ferramenta do subprojeto commons pertencente ao projeto apache: jakarta.apache.org/commons/digester.html 3 XML é um padrão da World Wide Web Consortium, a W3C, e o digester tem como selo a licença apache que permite o seu uso gratuito.

9 Dados: variáveis usadas durante as atividades do workflow e que são especificadas no XML de definição do agente, ou propriedades dos agentes informadas quando da sua criação (identificador do agente, identificação da agência central, identificação do agente pai, etc.). Estado: o estado de execução do agente, reflexo de como está a execução do workflow. O agente móvel está descrito em Java por uma classe de dados, uma interface pública e uma classe principal do agente. Nesta nova versão, o agente MABflow compreende também em seu conjunto de dados um conjunto de listas, onde cada lista representa um elemento do workflow em especial (atividades, participantes, transições, etc.), onde cada lista está também descrita como uma classe Java Criação e Execução de Agentes MABflow A criação do agente MABflow supõe a existência de um documento do fluxo de trabalho em XML, conforme um arquivo de definições preestabelecido (DTD). Neste DTD, parcialmente mostrado, estão as definições básicas de todos os elementos do workflow suportados, de acordo com o padrão Wf MC. Os principais elementos definidos são: Modelo (elemento Model): define um modelo de negócio, contexto no qual se inserem o(s) processo(s) de negócio. Incorpora um conjunto de propriedades que são compartilhadas entre um ou mais processos de negócios posteriormente definidos. Único para cada documento XML criado; Workflow (elemento Workflow): demarca um processo de negócio. É nele que são definidos os elementos de um workflow (atividades, transições, participantes, etc.). Pode haver um ou mais em um documento XML; Atividade (elemento Activity): simboliza uma atividade dentro de um processo de negócio em especial. Pode haver uma ou mais atividades; Transição (elemento Transition): uma transição entre atividades de um workflow definido. Podem existir uma ou mais transições em um processo de negócio. O número de agentes móveis criados de um único arquivo XML varia com o número de fluxos de trabalho definidos (elemento XML Workflow). Esses processos de negócio utilizam elementos de workflow em comum do modelo de processo organizacional (elemento XML Model), como participantes, por exemplo. O processo de criação do agente começa quando os dados de um processo de negócio em especial (caso haja mais de um especificado) e do modelo de processo correspondente são descritos em um arquivo de entrada XML. Através de um construtor de agente Java que implementa classes do digester, todas as informações do workflow no XML de entradas são validadas pelo DTD do MABflow, capturadas e escritas em representações Java dos dados do agente (passo A da Figura 4). Esses códigos-fonte Java são compilados (passo B da Figura 4), e suas classes correspondentes são postas em execução no ambiente de execução do GMAS, gerando um agente móvel propriamente dito com o conhecimento do workflow (passo C da Figura 4). A classe principal do agente gerado implementa métodos padrões utilizados pelo agente durante sua execução. Esses métodos padrões utilizam métodos oferecidos pelo GMAS, que realizam o mapeamento para alguma funcionalidade correspondente no sistema de agentes utilizado pelo GMAS. Da mesma forma, as classes de dados, interface e classe principal do agente MABflow estende classes de dados, interface e de agente móvel do GMAS. Nesta mesma classe principal, o processo de negócio do agente é o mesmo para qualquer workflow em XML definido, variando apenas as listas pertencentes ao agente, ao contrário da primeira versão que possuía um único bloco de código Java

10 + Passo A DTD do MABflow segundo a WfMC Definição em XML do workflow Passo B Código-fonte em Java do agente e suas listas de elementos do workflow Classes Java compiladas Passo C Ambiente de execução GMAS Figura 4: Processo de criação e execução de um agente do MABflowusando um DTD segundo o padrão da Wf MC variável para cada XML especificado. Isto facilita possíveis operações de captura do estado do agente (transformar o código Java de um agente do MABflow no seu XML de definição) e o entendimento do código do agente mesmo quando o mesmo representa um workflow mais complexo, com um grande número de atividades e transições, por exemplo. O processo de negócio do agente móvel, presente na classe principal criada, prevê a manipulação básica do agente, usando sua lista de atividades e transições. As atividades não precisam ser especificadas em documento XML na ordem em que possivelmente serão executadas, tampouco as transições entre atividades. Assume-se a premissa aqui de que a primeira atividade a ser realizada é aquela que não possui transições de chegada (informação encontrada em cada atividade pertencente à lista de atividades). A execução do workflow propriamente dito é realizada percorrendo essa lista de atividades em um laço, cuja condição de parada se dá quando uma das seguintes situações é atendida: 1. Quando todas as atividades foram executadas, não restando mais alguma atividade a ser executada (caso trivial); 2. Quando se encontra um indicativo de laço infinito real, isto é, o agente já percorreu todas as atividades possíveis de serem executadas e não conseguiu executar nenhuma dessas; 3. Quando ocorre alguma exceção gerada durante a execução do agente. Por exemplo, quando um agente se move para uma agência não ativa, isto é, uma agência cujo endereço não foi identificado pelo agente durante sua locomoção. Neste caso, o agente volta para a agência onde iniciou sua execução. Durante a execução do workflow, o serviço de ontologias, acessado via RMI (Remote Method Invocation), é requisitado pelo agente à medida que uma nova atividade é detectada para ser executada. Em cada requisição, o agente solicita ao servidor de ontologias o endereço da agência, identificado pelo nome da máquina (ou endereço IP) e o número da porta onde a agência executa na máquina, passando a identificação da atividade a ser executada. O uso de tal serviço traz alguns benefícios como a não definição direta de participantes de workflows (o par IP ou nome da agência e sua porta de execução) em atividades para um agente do MABflow (caso da primeira versão do sistema, onde, se a agência previamente especificada não existisse mais, uma modificação na definição XML do processo de negócio e uma nova geração de um agente MABflow eram necessárias).

11 6. Conclusões O workflow encena um papel fundamental na modelagem de processos de negócio organizacionais. Sua importância reside, dentre outros benefícios, na reengenharia dos processos modelados, embora muitas vezes implique uma mudança radical na filosofia estabelecida e, com efeito, na modificação do modo de operação, nem sempre bem vista por aqueles que participam dos processos [8] [2]. Agentes móveis emergem em muitos contextos de computação distribuída como um paradigma recomendável para implementação de workflows. Com agentes representando o conhecimento de fluxos de trabalho, cuja definição de seus principais elementos é fornecida por uma ontologia (caso da Wf MC via a WPDL), a engenharia de construção de sistemas de workflow pode ser repensada e evoluída, abrindo os horizontes para o desenvolvimento de novas aplicações voltadas para processos de negócio. Este trabalho tem como resultado imediato uma nova versão do sistema MABflow, cujo desenvolvimento tem servido de ajuda ao LaSiD na pesquisa e verificação de questões relacionadas ao desenvolvimento de sistemas distribuídos. Esta nova versão inclui uma série de características novas, oferecendo ao MABflow, por exemplo, extensibilidade no uso de mais de um sistema de agente em Java através do GMAS, e interoperabilidade com outros sistemas de workflow na adoção do padrão da Wf MC nas definições de processo. O trabalho também reflete a convergência de três aspectos: a ontologia, o workflow e os agentes móveis. Assim, através da especificação da Wf MC (ontologia) servindo como base de conhecimento, documentos de definições de processo de negócio (workflow) podem ser criados e executados por agentes móveis que detêm o conhecimento dos mesmos. Referências [1] ALLEN, Rob. Workflow: An Introduction. Disponível em: < org/standards/docs/workflow_an_introduction.pdf > Acesso em: 18 dez [2] ARAÚJO, Renata Mendes de; BORGES, Marcos Roberto da Silva. Sistemas de Workflow. In: XXI CONGRESSO DA SOCIEDADE BRASILEIRA DE COMPUTAÇÃO, 2001, Fortaleza, Ceará. Anais do XXI Congresso da Sociedade Brasileira de Computação, Fortaleza, Ceará: SBC, Volume 2, páginas ISBN [3] ARGOLLO, Siddartha Lourenço. GMAS: Um Framework Genérico para o Desenvolvimento de Aplicações Baseadas em Agentes Móveis Monografia do curso de especlização avançada em sistemas distribuídos - Laboratório de Sistemas Distribuídos, Universidade Federal da Bahia. [4] ASSIS SILVA, Flávio M. Assis. Agentes Móveis. Anais da EINE 99 (Escola de Informática da Sociedade Brasileira de Computação - Edição Nordeste), nov [5] ASSIS SILVA, Flávio M. Assis ; SILVA, Paulo Sérgio da; SANTOS, Neima Prado dos; LIMA SANTOS, Jorge A.; CORREIA JR., Afrânio T.; SELCH, João Carlos; LUZ, Sérgio; ARGOLLO, Siddartha L.. Executing Workflows with Mobile Agents from UML Specifications. In: V WORKSHOP DE COMPUTAÇÃO SEM FIO E COM- PUTAÇÃO MÓVEL, 2003, São Lourenço, Minas Gerais. Anais do V Workshop de Computação Sem Fio e Computação Móvel, São Lourenço, Minas Gerais: [6] BARTHELMESS, Paulo. Sistemas de Workflow: Análise da Área e Proposta de Modelo folhas. Dissertação de Mestrado - Instituto de Computação, Universidade Estadual de Campinas, Campinas, São Paulo, 1996.

12 Disponível em: < Publications/Thesis/TESE.pdf >. Acesso em 18 dez [7] CORREIA JR. Afrânio Tavares; ASSIS SILVA, Flávio M. de; SELCH, João Carlos Lago; LUZ, Sérgio Eduardo Barreto da. MABflow (Mobile Agent Based Workflow) Manual de Instalação e Utilização, versão folhas. Laboratório de Sistemas Distribuídos (LaSiD), Universidade Federal da Bahia, Salvador, Bahia. [8] GEORGAKOPOULOS, Diimitrios; HORNICK, Mark; SHETH, Amit. An Overview of Workflow Management: From Process Modeling to Workflow Automation Infrastructure. Distributed and Parallel Databases, The Netherlands, volume 3, páginas , [9] GRISS, Martin L.; CHEN, Quiming; OSTERWEIL, Leon J.; BOLCER, Gregory A.; KESSLER, Robert R.. Panel: "Agents and Workflow An Intimitate Connection, or just friends?". In: TOOLS99 USA, 1999, Santa Barbara, USA. Disponível em: < >. Acessado em 18 dez [10] GRUBER, Thomas R.. Towards Principles for the Design of Ontologies used for Knowledge Sharing. In: INTERNATIONAL WORKSHOP ON FORMAL ONTOLOGY, 1993, Padova, Italy. [11] HOUAISS, Antônio; VILLAR, Mauro de Salles ; FRANCO, Francisco Manoel de Mello. Dicionário Houaiss da Língua Portuguesa. 1 a edição. Rio de Janeiro, Editora Objetiva. ISBN X [12] HOUSTIUS, Catherine. ARION: An Advanced Lightweight Architeture for Accessing Scientific Collections: A Federated, Open and Scalable Architecture for a Digital Library and Scientific Collections. Disponível em: < http: //delos-noe.iei.pi.cnr.it/activities/internationalforum/ All-Projects/RomeSlides/ARION.pdf >. Acesso em: 18 dez [13] PLESMUS, Charles. Introduction to Workflow. Workflow Management Coalition - Wf MC. Disponível em: < introduction_to_workflow02.pdf >. Acesso em: 18 dez [14] REIS JUNIOR, Paulino Batista; GERBASE, Vitor Tunes. Suporte à Ontologia no MABflow Monografia do curso de especlização avançada em sistemas distribuídos - Laboratório de Sistemas Distribuídos, Universidade Federal da Bahia. [15] RUBINSTEIN, Marcelo Gonçalves Rubinstein. Agentes Móveis no Gerenciamento de Redes Tese de Doutorado - Universidade Federal do Rio de Janeiro, Rio de Janeiro, Disponível em: < html >. Acesso em: 18 dez [16] SWARTOUT, Bill. Future Directions in Knowledge Based Systems. ACM Computing Surveys, [17] WORKFLOW MANAGEMENT COALITION. The Workflow Reference Model, Disponível em: < pdf >. Acesso em: 18 dez [18] WORKFLOW MANAGEMENT COALITION. Process Definition Interchange, Process Model, Disponível em: < docs/tc-1016-p_v11_if1_process_definition_interchange. pdf > Acesso em: 18 dez [19] WONG, David; PACIOREK, Noemi; MOORE, Dana. Java-based Mobile Agents. Communications of the ACM, volume 42, número 3, páginas , 1999.

13 [20] ZYL, Julieanne Van; CORBETT, Dan. Population of a Framework for Understanding and Classifying Ontology Applications. Disponível em: < dia.fi.upm.es/workshop/ecai00/10.pdf >. Acesso em: 18 dez