Gerenciador de Dados Compartilhados entre Processos de Negócio: Data-Control Process para WED-tool

Transcrição

1 Gerenciador de Dados Compartilhados entre Processos de Negócio: Data-Control Process para WED-tool Rafael Liberato 12, André L. Schwerz 12, Osvaldo K. Takai 2, João E. Ferreira 2 1 Universidade Tecnológica Federal do Paraná (UTFPR) Caixa Postal Campo Mourão PR Brasil 2 Instituto de Matemática e Estatástica Universidade de São Paulo (USP) São Paulo SP Brasil {liberato,andreluis}@utfpr.edu.br {takai,jef}@ime.usp.br Abstract. WED-tool is one based on the WED-flow approach that allows the modeling and executing instances of business processes integrating events, conditions, transitions and data states. This paper presents a reformulation of WED-tool aiming to provide data sharing among instances. The main contribution of this paper is the development of a manager able to process concurrent requests based on linearizability as a correctness condition. Furthermore, this paper presents an alternative of concurrency control based on Escrow Method for enumerate data item that significantly increases the processing capacity of the requests. Resumo. WED-tool é uma ferramenta baseada na abordagem WED-flow que permite a modelagem e execução de instâncias de processos de negócio integrando eventos, condições, transições e estados de dados. Este artigo apresenta uma reformulação da WED-tool com o objetivo de proporcionar o compartilhamento de dados entre instâncias. A principal contribuição desse artigo é o desenvolvimento de um gerenciador capaz de processar requisições concorrentes seguindo a consistência linear como condição de corretude. Além disso, este artigo apresenta uma alternativa de controle baseada no Método Escrow para item de dados quantificáveis que aumenta significantemente a capacidade de processamento das requisições. 1. Introdução A evolução dos processos de negócio tem evidenciado novos desafios no desenvolvimento de grandes aplicações. Mais especificamente, é um desafio comum projetar processos que acessam itens de dados compartilhados. No modelo transacional clássico [Haerder and Reuter 1983] uma execução concorrente pode impor longas esperas por itens de dados devido ao bloqueio garantido pela propriedade de isolamento. Dessa forma, a comunidade de científica tem apresentado importantes contribuições na concepção de modelos transacionais avançados com o intuito de superar os limites impostos pela rigidez do isolamento. Entretanto, evitar os efeitos colaterais do isolamento ainda é uma motivação atual, uma vez que romper com suas fronteiras conduz para uma série de desafios ainda não solucionados. 26

2 O modelo SAGAS [Garcia-Molina and Salem 1987] foi um dos pioneiros ao explorar os limites das propriedades transacionais clássicas apresentando o conceito de compensação. O Método Transacional Escrow [O Neil 1986] apresenta um controle de concorrência de item de dados quantificáveis. Essa abordagem supera o bloqueio aplicado a um item de dado, desde que o sistema mantenha o conhecimento sobre as atualizações e garanta que elas serão efetivadas em qualquer ordem posteriormente. O Open Nested Transaction [Weikum and Schek 1992] expõe dados entre operações abstratas comutativas e o ConTract Model [Wächter and Reuter 1991] usa de invariantes para manter a consistência entre os processos de negócio. A abordagem WED-flow, inicialmente proposta em [Ferreira et al. 2010] e expandida em [Ferreira et al. 2012], foi implementada na WED-tool [Garcia et al. 2012]. As principais funcionalidades do núcleo dessa ferramenta são (i) definição e manutenção de processos de negócio; (ii) controle de execução de instâncias dos processos de negócio; e (iii) gerenciamento de recuperação. Entretanto, a ferramenta não disponibiliza um mecanismo no qual instâncias compartilhem itens de dados. Este trabalho apresenta uma reestruturação da WED-tool que possibilita o desenvolvimento de um gerenciador de dados compartilhados entre instâncias de processos por meio da comunicação via estados de dados. As operações sobre os dados compartilhados são executadas por um processo especializado data-control process. De forma intuitiva, o data-control process executa ou rejeita operações requisitadas pelas instâncias mantendo a história de execução linearmente consistente 1 [Herlihy and Wing 1990]. O compartilhamento de itens de dados amplia a abrangência da WED-tool tornando-a uma ferramenta robusta capaz de atuar em diferentes contextos. Uma visão geral da abordagem WED-flow é descrita na próxima seção. Os detalhes da concepção do data-control process são descritos na Seção 3. Na Seção 4 é descrito a modelagem WED-flow de processos de negócio que concorrem pelo mesmo item de dado. A Seção 5 apresenta os resultados dos experimentos. Por fim, as considerações finais são apresentadas na Seção A abordagem WED-flow: uma visão geral O WED-flow [Ferreira et al. 2010] é uma abordagem para modelagem e implementação de processos de negócio que integra eventos, condições, transições e estados de dado. A abordagem é baseada em três importantes regras: (i) um conjunto de transições que modifica o estado de dado atual e consistente gerando um novo estado consistente e atual; (ii) qualquer estado de dado que é consultado, modificado ou gerado por uma transição deve ser explicitamente representado e permanentemente armazenado; e (iii) todas transições que alteram os estados de dados são disparadas por um evento quando um conjunto de condições for satisfeita. As definições da abordagem WED-flow são descritas em [Ferreira et al. 2012]. Entretanto, devido à restrição de espaço, somente aquelas diretamente relacionadas a este artigo são descritas a seguir. WED-attributes: cada aplicação possui um conjunto de atributos que serão utilizados para definir o fluxo de tarefas e que serão alterados durante a execução do processo. Com isso, denotamos por WED-attributes a tupla A = a 1,a 2,...,a n, onde cadaa i (com 1 i n) é um atributo de interesse da aplicação. 1 Linearizability 27

3 WED-state: um WED-state é uma tupla v 1,v 2,...,v n, onde v i (com 1 i n) é um valor para o i-ésimo atributo de A. Se considerarmos os WED-attributes como atributos de uma relação de um banco de dados, um WED-state é uma tupla específica (ou seja, uma linha) dessa relação. O conjunto S é o conjunto de todos os possíveis WED-states de uma aplicação e é definido formalmente por S = { v 1,v 2,...,v n i [1;n],v i domain(a i )}, no qual a i é o i-ésimo atributo de A e domain(a i ) é o conjunto de valores que esse atributo pode assumir. WED-condition: uma WED-condition é um conjunto de predicados definidos sobre os WED-attributes de uma aplicação. O conjunto C representa o conjunto de todas as WED-conditions definidas para a aplicação. Sendo s S um WEDstate e c C uma WED-condition, dizemos que s satisfaz c se os valores dos atributos de s tornam os predicados decverdadeiros. WED-transition: uma WED-transition t é uma função t : S S, ou seja, uma função que recebe um WED-state como entrada e produz outro WED-state como saída. Uma WED-transition pode ser vista como uma transação convencional que é implementada como um passo SAGA. A especificação de uma WED-transition t inclui um conjunto de atributos U t = {u 1,u 2,...,u m }, tal que u i (com 1 q m n) é um elemento de A, o qual indica quais atributos são atualizados por t. Denotamos por T o conjunto de todas as WED-transitions definidas para a aplicação. WED-trigger: um WED-trigger é um par g = c,t, no qual c é uma WEDcondition e t uma WED-transition. Quando um WED-state s S satisfaz a condição c, g é responsável por disparar a transição t. O conjunto G representa o conjunto de todos os WED-triggers definidos para a aplicação. WED-flow: um WED-flow é uma tripla G,c i,c f, ondeg G é um conjunto de WED-triggers ec i ec f são WED-conditions. A condiçãoc i é a condição inicial do WED-flow, a qual define o conjunto de WED-states iniciais válidos, e a condição c f é a condição final do WED-flow, a qual define o conjunto de WED-states finais válidos. História de uma Instância WED-flow: uma entrada no histórico registra a execução de uma WED-transition e pode ser representada pela 4-tupla c,t,s i,s o, em que: s c S indica o WED-state que satisfaz a condição que disparout; t T é a WED-transition (passo SAGA) executada; s i S indica o WED-state fornecido como entrada parat; e s o S indica o WED-state gerando como saída det. Na próxima seção é apresentado como o data-control process foi concebido para a WEDtool usando os construtores semânticos da abordagem WED-flow. 3. Data-control process A ferramenta WED-tool é implementada na linguagem de programação Ruby sendo apoiada pelo arcabouço Ruby on Rails. A reformulação da ferramenta é proposta com o objetivo de permitir o compartilhamento de dados por meio da comunicação entre processos de negócio. Essa nova característica conduziu para a concepção do data-control process. Para exemplificar o funcionamento desse processo, a Figura 1 apresenta uma representação gráfica e a história de execução de uma instância do processo de negócio wf_venda. 28

4 Figura 1. (a) Representação gráfica da comunicação entre processos. (b) Histórias de execução da instância e do data-control process. Essa instância requisita ao data-control process efetuar uma remoção de 10 unidades de um determinado produtop1. A nova implementação da WED-tool inclui a modelagem e a execução de WEDtriggers especiais chamadas de WED-triggers comunicantes. A implementação dessas WED-triggers comunicantes permite a ferramenta realizar a comunicação entre instâncias de processos com o data-control process. Essa WED-trigger é disparada pela instância origem quando um estado de dado satisfizer sua WED-condition. O disparo da WEDtrigger implica na execução de uma WED-transition responsável por estimular o datacontrol process e um novo estado de dado em seu histórico de execução. Esse estímulo indica a requisição para execução de uma operação sobre o item de dado. A Figura 1 ilustra a WED-trigger comunicante t in sendo disparada a fim de requisitar uma operação de remoção gerando o WED-state E s1. Todas as requisições para operar sobre o item de dados são armazenadas no histórico de execução do data-control process. Uma vez que as requisições são armazenadas na história de execução do datacontrol process, o próximo passo é o processamento das operações. As operações requisitadas são aceitas ou rejeitadas respeitando a consistência linear. Cada operação que atua sobre o item de dado é implementada por uma WED-trigger. Essa WED-trigger é disparada se a execução da operação não violar a consistência linear. Caso contrário, a execução é rejeitada. Em ambos os casos, um WED-state é gerado representando o resultado da requisição. Na Figura 1 a WED-trigger t indica a execução da operação e o WED-stateE s2 indica o resultado da execução. Por fim, o data-control process executa uma WED-trigger comunicante que transfere o resultado da requisição para a instância do processo requisitante. Na Figura 1 a WED-triggert out é responsável pela comunicação sobre o resultado da operação. Critério de corretude. As operações são executadas baseadas na consistência linear. A consistência linear é uma condição de corretude para objetos concorrentes que explora a semântica dos tipos de dados abstratos. A consistência linear provê que cada operação aplicada por um processo concorrente seja efetivada em algum ponto entre sua requisição e a sua resposta, implicando que o significado das operações sobre objetos concorrentes pode ser expresso por meio de pré e pós-condições. Por exemplo, para operações add(x, qty) e remove(x, qty) sobre um item de dado x os seguintes axiomas representam as pré e a pós-condições para que as operações sejam executadas com sucesso. 29

5 Neste exemplo, a pré-condição true para a operação add(x, qty) indica que ela pode ser executada para qualquer estado do banco da dados. Isso implica que não há restrições para adicionar itens ao estoque. No entanto, para a operação remove(x, qty) o saldo no estoque deve se manter positivo após a sua execução. A pós-condição para ambas operações é um novo valor para o item de dado x. Note que as requisições são especificadas pelas assinaturas add(x, qty) e remove(x, qty) e a resposta é indicada por Ok() quando a operação é bem sucedida. Para obter histórias de execução linearizáveis são adotadas duas políticas de processamento das requisições. As especificidades de cada uma delas são discutidas a seguir. Política sequencial. Todas as requisições são armazenadas sequencialmente na história de execução do data-control process. Ou seja, as requisições são mantidas na ordem em que foram solicitadas. Ao seguir a política sequencial, assume-se que cada requisição é processada de forma isolada e sequencial seguindo a ordem de solicitação. Essa política é aplicada irrestritamente a qualquer classe de operações. Política escrow. Essa política é baseada no Método Escrow [O Neil 1986]. Este método é restrito à uma classe operações que envolvam incremento ou decremento de valores. Duas operações quaisquer dessa classe podem ser executadas paralelamente desde que o resultado da primeira não interfira do resultado da segunda. Por exemplo, duas operações deremove(x,qty) podem ser executados paralelamente desde que exista saldo suficiente para atender a ambas. Embora restrita a um classe de operações essa abordagem reduz consideravelmente o gargalo no processamento das requisições. 4. Exemplo: um armazém de produtos Para exemplificar o funcionamento do data-control process e da comunicação com as instâncias dos processos de negócio é utilizado um cenário de um armazém de produtos. As regras de negócio do armazém são abstraídas e simplificadas para atender as operações genéricas comuns em um controle de estoque tais como: entrada via aquisição e saída via atendimento. Sem perda de generalidade, as requisições lidam com um único produto representado por P 1. Vale ressaltar que esse exemplo pode ser especializado para atender diferentes produtos em outros cenários. Dessa forma, há dois processos de negócio que devemos considerar: (i) o processo responsável por receber requisições de venda de produtos para diversos clientes e (ii) o processo dedicado a repor o estoque por meio da compra de produtos. Os processos são chamados de wf_compra e wf_venda, respectivamente. Comum a ambos os processos, o data-control process é um conjunto de WED-triggers dedicadas a gerenciar os itens de dados específicos controlados pelo armazém. A Figura 1(a) retrata o histórico de execução das instâncias E1 e E2 do processo wf_compra. O WED-state S c1 representa aquisição de 10 unidades do produto P1 realizada pela instância E1. S c1 satisfaz a condição da WED-trigger comunicante que traduz essa requisição para o data-control process pela escrita do WED-state S c2 (veja Figura 1(b)). O S c2 dispara a transição responsável por atribuir o valor ao estoque gerando o 30

6 Figura 2. (a) Histórico de execução de duas instâncias do processo wf-compra. (b) Histórico de execução do data-control process. (c) Histórico de execução de três instâncias do processo wf-venda. WED-state S c3. Nesse momento, a WED-trigger comunicante do data-control process traduz o resultado das operações gerando um novo WED-state S c4 no histórico de execução de E1. Uma vez que o estoque está atualizado, a instância pode então terminar sua execução escrevendo o S c5. A instânciae2 apresenta comportamento similar. O histórico de execução das instâncias do wf_venda é ilustrado pela Figura 1(c). São três instâncias requisitando remover 10, 20 e 5 unidades do estoque. Primeiro, a instância R1 remove 10 unidades do produto P1 entre os estados S v1 e S v5. Segundo, a instância R2 deseja remover 20 unidades de P 1, porém, devido à indisponibilidade do estoque, R2 tem sua requisição rejeitada. Terceiro, a instância R3 deseja remover 5 unidades do produto P1 que, nesse caso, é executada pois nesse momento o estoque foi reposto pela instânciae2. 5. Experimentos Nesta seção são apresentados os experimentos executados para avaliar a viabilidade do data-control process ao lidar com processos de negócio concorrentes. Os testes foram realizados no sistema operacional Ubuntu instalado em um computador com processador Intel Core i3 de 2.40 Ghz e com 4GB de memória RAM. Configuração. Os processos wf_compra e wf_venda, descritos na Seção 4, foram utilizados para conduzir os experimentos. Para intensificar a concorrência, os processos solicitam a entrada e saída de um único produto com valores aleatórios. Após ter recebido a resposta, a instância finaliza sua execução. Nesse experimento o data-control process foi submetido a diferentes cargas de requisições. Inicialmente foram submetidas requisições de instâncias. Em seguida, a carga foi incrementada em por quatro vezes até chegar a instâncias. Além disso, as cargas foram submetidas em ambas políticas de processamento das requisições. Resultados. A Figura 3(a) ilustra o tempo gasto para execução de todas as instâncias em cada carga. Esse tempo é aferido pela diferença entre o instante em que a primeira instância da carga iniciou e o instante em que a última finalizou. Na política sequencial, o tempo gasto para executar instâncias foi de 710 segundos e para executar instâncias foi de segundos. Na política escrow, o tempo gasto para executar instâncias foi de 714 segundos e para executar as requisições de instâncias foi 31

7 Figura 3. (a) Tempo de execução por carga. (b) Média do tempo de execução das instâncias. de segundos. A Figura 3(b) ilustra a média aritmética do tempo de execução das instâncias em cada carga. Na política sequencial, o tempo médio de execução da carga de instâncias foi de 189 segundos enquanto que a média para a carga de instâncias foi de segundos. Na política escrow, o tempo médio de execução da carga de instâncias foi de 7 segundos enquanto que a média para a carga de instâncias foi de 9 segundos. Discussão. No experimento do tempo de execução por carga ilustrado pela Figura 3(a), observa-se que tanto na política sequencial quanto na política escrow o tempo é proporcional ao número de instâncias. Esse comportamento ocorre porque as instâncias executam os mesmos passos. Independente da forma com que o data-control process atende as requisições, o tempo de execução das instâncias será proporcional à quantidade executada. No experimento da média do tempo de execução das instâncias ilustrado na Figura 3(b), as políticas se diferem substancialmente. A média da política sequencial é proporcional ao número de instâncias. Ou seja, quanto mais instâncias estão em execução, maior é o tempo que cada instância leva para executar. Esse comportamento é desencadeado por um gargalo ocasionado no data-control process ao atender sequencialmente todas as instâncias. A instância requisita a operação e aguarda a resposta. Neste ponto, o data-control process não suporta a vazão das requisições emitidas pelas instâncias e atrasa o envio da resposta. Esse atraso impacta diretamente no tempo de execução das instâncias. No entanto, a política escrow reduz significativamente a média do tempo de execução das instâncias. A redução é alcançada pela execução paralela de requisições. Dessa forma, a média do tempo execução se mantém constante perante as diferentes cargas de requisições. É importante ressaltar que essa política não é equivalente às estratégias de paralelismo que somente visam à otimização (comumente utilizadas em Sistemas Distribuídos). O método escrow provê um paralelismo supervisionado, no qual é garantido que a execução paralela não causará inconsistências. Em resumo, o data-control process é capaz de atender instâncias que concorrem por objetos compartilhados. O processamento sequencial das requisições apresenta um gargalo que impacta no tempo médio de execução das instâncias. Ou seja, as instâncias ficam ociosas por um período de tempo que é proporcional a quantidade de instâncias atendidas. O método escrow melhora significativamente o tempo de resposta do data-control process para as instâncias. Essa melhora representa uma constância no tempo médio de execução das instâncias. É importante ressaltar que a abordagem deve ser submetida a outros experimentos considerando diferentes aplicações e configurações de software. 32

8 6. Considerações Finais Embora a comunidade científica tenha apresentado importantes contribuições para o tratamento dos dados compartilhados entre processos de negócio, a propriedade de isolamento ainda se mostra rígida para cenários que exigem a exposição dos resultados intermediários. Em tais cenários, o compartilhamento de dados por meio da comunicação entre processos via estados de dados é uma evolução da abordagem WED-flow capaz de atender essa exposição. Neste trabalho, apresentamos uma nova implementação da ferramenta WED-tool que reformula a primeira versão de seu núcleo de modo a proporcionar o compartilhamento de dados para processos de negócio. Como trabalho futuro, pretende-se realizar experimentos aplicando a abordagem em aplicações reais e estabelecer meios para recuperação em caso de desistência ou cancelamento. Agradecimentos Este trabalho tem apoio financeiro da FAPESP (Fundação de Amparo à Pesquisa do Estado de São Paulo) por meio do projeto de pesquisa e do CNPq (Conselho Nacional de Desenvolvimento Científico e Tecnológico) por meio do projeto de pesquisa Este artigo também recebeu apoio da Fundação Araucária. Referências Ferreira, J. E., Braghetto, K. R., Takai, O. K., and Pu, C. (2012). Transactional recovery support for robust exception handling in business process services. In Proceedings of 19th International Conference on Web Services (ICWS), pages IEEE. Ferreira, J. E., Takai, O. K., and Pu, S. M. C. (2010). Reducing exception handling complexity in business process modeling and implementation: the wed-flow approach. In Proceedings of the 2010 International Conference on On the Move to Meaningful Internet Systems - Volume Part I, OTM 10, pages Springer. Garcia, M. O., Braghetto, K. R., Pu, C., and Ferreira, J. E. (2012). An implementation of a transaction model for business process systems. Journal of Information and Data Management, 3(3):271. Garcia-Molina, H. and Salem, K. (1987). Sagas. In Proceedings of the 1987 ACM SIG- MOD International Conference on Management of Data, SIGMOD 87, pages , New York, NY, USA. ACM. Haerder, T. and Reuter, A. (1983). Principles of transaction-oriented database recovery. ACM Computing Surveys (CSUR), 15(4): Herlihy, M. P. and Wing, J. M. (1990). Linearizability: A correctness condition for concurrent objects. ACM Transactions on Programming Languages and Systems (TO- PLAS), 12(3): O Neil, P. E. (1986). The escrow transactional method. ACM Transactions on Database Systems (TODS), 11(4): Wächter, H. and Reuter, A. (1991). The contract model. Data Engineering, 14(1): Weikum, G. and Schek, H.-J. (1992). Database transaction models for advanced applications. chapter Concepts and applications of multilevel transactions and open nested transactions, pages Morgan Kaufmann Publishers Inc., San Francisco, CA, USA. 33