Universidade Federal de Santa Catarina - UFSC Departamento de Informtica e Estatstica INE Curso de Bacharelado em Sistemas de Informao Aluna: Priscilla

a Francielle Poleza Disciplina: Projetos I Professor: Renato Cislaghi Orientador: Frank Augusto Siqueira

Resumo do Artigo: Web Service Composition Transaction Management Abstract

Este artigo tem por objetivo apresentar um modelo de gerenciamento de transao para Web Services a fim de suportar as caractersticas prprias das transaes de negcios suportadas por ela.

Introduo
Um Web Service pode ser descrito como um servio disponvel via internet que conduz transaes. A composio de servios referencia processos de criao customizados de servios a partir de servios existentes atravs de um processo de descoberta dinmica, integrao e execuo de certos servios em uma ordem pr-determinada a fim de satisfazer os requisitos dos usurios (Chakraborty et, al. 2002). Uma Transao envolvendo mltiplos web services composta por vrias sub-transaes autnomas que so abortadas ou efetivadas independentemente. Ou seja, as transaes em Web Services so fracamente acopladas e possivelmente envolvem muitas empresas, podendo durar por longos perodos de tempo e serem imprevisveis o que torna a alocao exclusiva de recursos invivel. Recursos alocados por um grande perodo de tempo podem causar srios problemas. Uma forma de garantir que a to desejada propriedade de tudo ou nada mesmo que a invocao do web service seja executada de forma independente e atravs da noo de compensao, nem todos web services suportam compensao.

Viso Geral
A composio de servios pode ser classificada de vrias maneiras. Para. Chakarborty e Joshi (2001) a composio de servios pode ser classificada em pr-ativa e reativa. Composio de servios pr-ativa consiste na composio pr-compilada ou offline de servios disponveis para formar novos servios. Composio de servios reativa refere-se ao tipo de composio que executada somente atravs requisies ou criaes.

Modelos de Transao
Transaes bsicas ou transaes tradicionais referem-se a transaes que respeitam as propriedades de atomicidade, consistncia, isolao e durabilidade (ACID), enquanto transaes complexas referem-se a transaes extendidas e relaxadas. Transaes extendidas permitem o agrupamento de

suas operaes dentro de estruturas hierrquicas enquanto que transaes relaxadas indicam que um dado modelo de transao relaxa algumas das requisies ACID. Esta seo revisar os modelos de transaes existentes e ento apresentar os Web Services e transaes de negcios existentes.

Modelos de Transaes Extendidas e Relaxadas

A extenso do nvel horizontal ou nico da estrutura das transaes tradicionais foi muito importante para a sua evoluo (Zhang and Jia 1999, Zhand et, al. 1999). Nested Transctions (Transaes aninhadas) - permite que transaes sejam aninhadas dentro de outras transaes formando uma rvore de transaes (Moss 1981). Open Nested Transactions (Transaes aninhadas abertas) relaxa a propriedade de isolao tornando os resultados de efetivao de sub-transaes visveis para as outras transaes do topo do nvel (Wiekum e Schek 1992). The Saga Transaction Model (O modelo de transao Saga) permite que uma transao de longa-durao seja dividida em uma seqncia de sub-transaes (Garcia-Molina e Salem 1987). The Split-Joim Transaction Model (O Modelo de Transao splitjoim) foi projetado para dividir uma transao em duas transaes independentes ou dependentes e depois uni-las a fim de formar uma nica transao (Pu 1988, Pu et, al. 1988). ConTracts um mecanismo de agrupamento de transaes dentro de uma atividade de multi-transao (Ruter 1989). Long-Runnig Activity modelado como um conjunto de unidades de execuo que consistem recursivamente de outras atividades ou transaes (Dayal et, al. 1991).

Web Services e Transaes de Negcios

A diferena entre o sistema de gerenciamento de transaes distribudas e do sistema de gerenciamento de transaes em Web services consiste nos seguintes requisitos: Transaes em web services so frequentemente conduzidas atravs dos limites organizacionais. Isto implica que seus participantes sero independentes e distribudos atravs da internet (Mani e Nagarajan 2002). Transaes em web services podem durar por um longo perodo, entretanto organizaes no podem permitir que seus recursos sejam consumidos imprevisivelmente em um ambiente aberto como a internet. Para resolver os problemas listados acima, alguns protocolos foram propostos e so citados a seguir.

Transaction Internet Protocol - TIP

Trata-se de um protocolo de transporte que permite a comunicao de coordenadores de transaes distribudas sobre a internet (Lyon et, al. 1998, Papazoglou 2003). Este protocolo oferece flexibilidade para o protocolo 2PC baseado em transaes de curta durao, mas ele falha no caso de transaes 2

de negcios de longa-durao. Transaes de negcio consistem em um grande nmero de componentes de transaes, os quais possuem tempos de respostas diferentes, bloqueando deste modo os recursos controlados por transaes de curta durao por um inaceitvel perodo de tempo, tornando indisponvel o processo de novas requisies de servios. Business Transaction Protocol (BTP) Foi projetado para suportar aplicaes independentes de localizao e administrao, que necessitam de suporte transacional diferente do suportado pelas transaes ACID. Segundo Limthanmaphon, Zhang (2004, apud BTP, Potts et, al. 2002, p. 173), os objetivos da especificao BTP resumidamente so os seguintes: Fornecer um modelo de transaes sobre a internet; Integrar sistemas confiveis sobre canais de comunicao no confiveis; Gerenciar o ciclo de vida das transaes e suportar as propriedades ACID; Suportar comunicaes assncronas entre sistemas fracamente acoplados; Fornecer suporte para transaes de longa durao; Coordenar relaes mltiplas e independentes entre transaes e sub-transaes; BTP baseia-se no protocolo commit de duas fases para interaes de curta durao conhecidas com atom, as quais podem ser combinadas e juntas formarem uma grande transao no ACID, conhecidas como cohesion. (LIMTHANMAPHON, ZHANG, 2004). Tentative Hold Protocol (THP) THP um framework aberto, de baixo acoplamento, baseado em mensagens que possibilitam a troca de mensagens entre scios do negcio. O objetivo do THP consiste em tentar facilitar a coordenao automtica de transaes entre vrios negcios. A utilizao do THP est associada aos quatro estados detalhados a seguir: Responding (Resposta) o estado inicial que se d quando a aplicao envia uma mensagem Hold Request; Process (Processo) um estado intermedirio que indica que uma requisio de suporte foi recebida e que um reconhecimento da requisio de suporte foi retornada ao requerente; Active (Ativa) alcanado quando uma requisio de suporte confirmada. Uma mensagem de confirmao enviada ao dono do recurso requisitado; Inactive (Inativa) alcanado quando a tentativa de suporte do estado ativo e invalidado. Uma mensagem de cancelamento de suporte enviada ao cliente ou ao dono do recurso. Web Service Transaction WS-Transaction (Cabrera et, al. 2001) define como os web services coordenam suas atividades em seqncia para assegurar a integridade das operaes bsicas dos bancos de dados. WS-Transaction define dois modelos 3

para as transaes sobre web services: transaes atmicas e transaes de negcios. O modelo de transao atmica (AT) utilizado para coordenar atividades de curta durao executadas dentro de domnios com alto nvel de proteo. Transaes atmicas seguem as propriedades ACID e garantem que todos os participantes tero o mesmo resultado (atmico): todos efetivam a transao ou todos abortam a transao (propriedade tudo ou nada). O modelo de transao de negcio (BA) definido como uma atividade que consiste em uma seqncia de tarefas, onde cada tarefa satisfaz uma restrio de uma transao atmica. Sua principal caracterstica consiste na compensao de transaes.

Web Service Tentativa de Suporte e Modelo de Composio de Compensao de Transao

Os modelos de transaes extendidas e relaxadas apresentadas anteriormente possuem pontos fortes e fracos. Devido ao fato de que nenhuma tecnologia sozinha consegue fornecer uma soluo que suporte com sucesso todas as lgicas de negcios existentes devido a sua complexidade, uma juno de tecnologias se faz necessrio.

Estados da Transao
A figura a seguir apresenta o comportamento do modelo proposto por este artigo. O diagrama consiste de ns, linhas e rtulos (labels). Os ns representam os diferentes estados de cada ao. As linhas representam as transies entre os estados, e os rtulos sobre as linhas correspondem as condies requeridas para a respectiva transio. O estado ativo o estado inicial. Quando a aplicao envia uma mensagem de requisio de suporte (hold) ele entra no estado hold. A tentativa de efetivao (tentative hold) um estado intermedirio que indica que a requisio retornou com sucesso para o requerente. O estado abort alcanado quando a tentativa de suporte no validado.

Figura 1 Diagrama de estados de compensao de transao

Concluso
Este artigo apresentou um modelo de gerenciamento de transaes baseado nos conceitos de tentativa de suporte e de compensao. O modelo tambm suporta o processo de negociao para composio de servios. Resumo do Artigo: Web Service Composition Transaction Management Referncia: LIMTHANMAPHON, Benchaphon; ZHANG, Yanchun. Web Service Composition Transaction Management. In: Fifteenth Australasian Database Conference (ADC2004), 50, 2003. Research and Practice in Information Technology. Dunedin: Australian Computer Society, 2003. V. 27. p. 171-179.