Geração de Processos WS-BPEL com Base em um Algoritmo de Reescrita de Regras

Transcrição

1 UNIVERSIDADE FEDERAL DO RIO GRANDE DO NORTE CENTRO DE CIÊNCIAS EXATAS E DA TERRA DEPARTAMENTO DE INFORMÁTICA E MATEMÁTICA APLICADA PROGRAMA DE PÓS-GRADUAÇÃO EM SISTEMAS E COMPUTAÇÃO MESTRADO ACADÊMICO EM SISTEMAS E COMPUTAÇÃO Geração de Processos WS-BPEL com Base em um Algoritmo de Reescrita de Regras Sidney Soares Marcelino Natal-RN, Brasil Dezembro, 2013

2 Sidney Soares Marcelino Geração de Processos WS-BPEL com Base em um Algoritmo de Reescrita de Regras Dissertação de Mestrado apresentada ao Programa de Pós-Graduação em Sistemas e Computação do Departamento de Informática e Matemática Aplicada da Universidade Federal do Rio Grande do Norte como requisito parcial para a obtenção do grau de Mestre em Sistemas e Computação. Linha de pesquisa: Engenharia de Software PPgSC Programa de Pós-Graduação em Sistemas e Computação DIMAp Departamento de Informática e Matemática Aplicada CCET Centro de Ciências Exatas e da Terra UFRN Universidade Federal do Rio Grande do Norte Orientador Prof. Dr. Umberto Souza da Costa Natal-RN, Brasil Dezembro, 2013

3 Catalogação da Publicação na Fonte. UFRN / SISBI / Biblioteca Setorial Centro de Ciências Exatas e da Terra CCET. Marcelino, Sidney Soares. Geração de processos WS-BPEL com base em um algoritmo de reescrita de regras / Sidney Soares Marcelino. - Natal, f. : il. Orientador: Prof. Dr. Umberto Souza da Costa. Dissertação (Mestrado) Universidade Federal do Rio Grande do Norte. Centro de Ciências Exatas e da Terra. Programa de Pós-Graduação em Sistemas e Computação. 1. Linguagem de programação Dissertação. 2. Serviços web Dissertação. 3. Linguagem de orquestração Dissertação. 4. Reescrita de regras - Dissertação. I. Costa, Umberto Souza da. II. Título. RN/UF/BSE-CCET CDU:

4 !"" ""#"" $"$%&'& """" "()"() )& * #+', *"./*+ 0$ #3/*+ 04)&) $" *"./* ) /*+ 05" 1./* 05" 1."6789:

5

6 Agradecimentos Primeiramente a Deus que permitiu que tudo isso acontecesse, ao longo de minha vida, e não somente nestes anos de estudante, mas que em todos os momentos é o maior mestre que alguém pode conhecer. Aos meu pais, Maria de Lourdes e Cícero Marcelino, meus irmãos Erbene Soares, Edicarlos Soares, Elba Lígia e Simone Soares, que, com muito carinho e apoio, não mediram esforços para que eu chegasse até esta etapa da minha vida. À minha amada esposa que, pacientemente, suportou toda a distância e a saudade, me dando forças para que eu conseguisse alcançar todos os meus objetivos. Ao professor orientador Umberto Souza da Costa por seu apoio e inspiração no amadurecimento dos meus conhecimentos e conceitos que me levaram a execução e conclusão deste mestrado. A todos os meus amigos, em especial Romerito, Janduir, Diego, Helder e Hugo, por terem convivido e compartilhado tantas alegrias comigo. Fazendo essa caminho um pouco menos difícil. Ao amigo Iran Henrique Lustosa, que me apoiou incondicionalmente, me dando conselhos e alento nos momentos mais difíceis desse percurso. Enfim, agradeço aos colegas do Laboratório ForAll, pelas incontáveis horas de conversa e companhia, pela ajuda nos trabalhos e todos os momentos inesquecíveis que passamos juntos.

7

8 Mais vale ser feliz à ter sempre razão

9

10 Resumo Os serviços web são soluções computacionais criadas de acordo com os princípios da Computação Orientada a Serviços e disponibilizadas via Internet. Novos serviços web podem surgir a partir outros pré-existentes, utilizando linguagens de composição. Considerando orquestrações de serviços, onde existe um processo central que coordena todas as operações da aplicação, propomos um método para geração de processos WS-BPEL, a partir de especificações abstratas dotadas de informações de controle. O método proposto permite ao projetista da composição se concentrar em especificações de alto nível, aumentando sua produtividade e gerando especificações independentes de serviços web específicos. O processo de geração de composições se baseia em um algoritmo de reescrita de regras, que foi estendido para dar suporte a informações de controle básicas. Criamos um protótipo do método de refinamento estendido e realizamos experimentos sobre estudos de caso simples. Palavras-chaves: Serviços Web, linguagem de orquestração, WS-BPEL, reescrita de regras.

11

12 Abstract Web services are computational solutions designed according to the principles of Service Oriented Computing. Web services can be built upon pre-existing services available on the Internet by using composition languages. We propose a method to generate WS-BPEL processes from abstract specifications provided with high-level control-flow information. The proposed method allows the composition designer to concentrate on high-level specifications, in order to increase productivity and generate specifications that are independent of specific web services. We consider service orchestrations, that is compositions where a central process coordinates all the operations of the application. The process of generating compositions is based on a rule rewriting algorithm, which has been extended to support basic control-flow information. We created a prototype of the extended refinement method and performed experiments over simple case studies. Key-words: Web service, composite language, WS-BPEL, rule rewriting.

13

14 Lista de Ilustrações Figura 1 Arquitetura Básica de Serviços Web Figura 2 Pilha de Protocolos conceitual de Serviços Web Figura 3 Exemplo do Cenário Figura 4 Fluxo Geral da Proposta Figura 5 Conjunto de arestas Figura 6 Grafo de dependências de C(b?, x!) Figura 7 Conjunto de arestas Figura 8 Conjunto de arestas geradas Figura 9 Estudo de caso Figura 10 Estudo de caso

15

16 Sumário 1 Introdução Trabalhos relacionados Fundamentação Teórica Service-Oriented Computing Web Services Refinamento de Composições de Serviços WS-BPEL Elementos básicos de BPEL4WS Exemplo Geração de Processos WS-BPEL Visão Geral Entrada do processo Identificação de Blocos Funcionalidades Refinamento Geração de Serviços Candidatos Resultados do refinamento Identificador de Dependências de Dados Grafo de Dependência Determinação de Dependência Gerando as estruturas Re-inserção de condicional e interação Regras de Tradução para Código WS-BPEL Geração de código WS-BPEL Experimentos Estudo de caso Conclusões e Trabalhos Futuros Referências APÊNDICE A Exemplo de uma Especificação Abstrata APÊNDICE B Documento XML gerado a partir da saída do refinamento.. 81 APÊNDICE C WSDL do serviço concreto HotelService APÊNDICE D WSDL do serviço concreto Mobile APÊNDICE E Anotações para as operações dos serviços concretos APÊNDICE F Entrada do refinamento para a composição Hotel APÊNDICE G Entrada do refinamento para a composição Mobile

17 APÊNDICE H Composição WS-BPEL Hotel APÊNDICE I Composição WS-BPEL Mobile ANEXO A Exemplo Transação Bancária

18 17 1 Introdução Service-Oriented Architecture (SOA) é um conceito de arquitetura de software que define o uso de serviços para dar suporte a requerimentos de negócio. Em SOA, recursos são disponibilizados a outros participantes em uma rede como serviços que são acessados de forma padronizada [PETRITSCH, 2006]. Service-Oriented Computing (SOC) é o paradigma que, tendo SOA como base, faz uso de serviços para desenvolvimento de aplicações de baixo-custo, interoperáveis e distribuídas [PAPAZOGLOU, 2003]. Pode-se dizer que uma aplicação SOA é formada por um conjunto de serviços simples que, devidamente integrados, formam um só serviço composto. É claramente perceptível que os serviços assumem um importante papel para SOC. Serviços são elementos computacionais que independem de plataforma e linguagem. Com o aumento do uso da internet, esses serviços foram disponibilizados na web, surgindo assim os serviços web. Segundo [BUCCHIARONE; GNESI, 2006] a tecnologia Serviço Web é uma instanciação bastante aceita de SOC que facilita a comunicação e integração tanto dentro como através das fronteiras organizacionais, evitando dificuldades geradas pelo uso de sistemas heterogêneos, como, por exemplo diferentes plataformas ou diferentes linguagens de programação. Os serviços web são construídos com base em uma série de tecnologias padronizadas pela W3C (World Wide Web Consortium) [W3C, 2002], com o objetivo de tornar possível a interoperabilidade destes serviços e possibilitar a integração dos mesmos em composições. O uso de serviços web permite a integração entre aplicações construídas utilizando diferentes tecnologias. O fato de usar tecnologias padronizadas faz com que a arquitetura suporte serviços de diferentes fontes sem dificuldades de integração, promovendo a interoperabilidade dos serviços. Em contrapartida, tais tecnologias são extremamente verbosas, o que torna o uso de serviços menos produtivo que outras propostas. Outra desvantagem do uso de serviços é o desempenho, pois, as aplicações que fazem uso de muitos serviços web são tipicamente menos eficientes, usa vez que a cada invocação de um serviço web, considera-se problemas de latência de rede ou até indisponibilidade de algum serviço. Uma composição de serviços pode ser especificada de duas formas: orquestração ou coreografia [PAPAZOGLOU, 2003]. Na orquestração existe um serviço centralizador, o orquestrador, que gerencia os demais serviços. No caso do uso de coreografia, cada serviço sabe quando executar suas operações e com quem interagir, sem a existência de um serviço centralizador [PELTZ, 2003]. A construção automática de composições baseadas diretamente em serviços concretos está bastante sujeita a falhas devido a indisponibilidade dos serviços concretos disponíveis no UDDI (Universal Description, Discovery and

19 18 Capítulo 1. Introdução Integrationl ) [ZHANG et al., 2002]. Por outro lado, a criação da especificação abstrata é independente dos serviços concretos disponíveis no UDDI. Os serviços dessa especificação abstrata deverão ser instanciados por serviços concretos posteriormente, pouco antes da execução da composição. Dessa forma, serviços indisponíveis serão substituídos sem a necessidade de alteração da especificação abstrata. Este trabalho tem por motivação fornecer ao projetista um método de construção de uma composição a partir de serviços abstratos e de informações de controle básicas. A descrição abstrata de um serviço web mostra características do mesmo sem oferecer referencias as tecnologias empregadas para hospedar ou transferir dados [ERL, 2005]. Com isso, não será necessário se preocupar com quais serviços serão utilizados, pois, depois de todo o processo o projetista terá uma composição real utilizando agora serviços concretos. Uma descrição concreta de um serviço web fundamenta o protocolo físico para possibilitar que a interface abstrata possa se comunicar [ERL, 2005]. Uma proposta de uso de especificações abstratas e refinamento de composições pode ser encontrada em [COSTA et al., 2013]. Neste trabalho, os autores propõem um método que utiliza o algoritmo de reescrita de consultas Minicon [POTTINGER; LEVY, 2000]. Com base nesse método, é possível selecionar os serviços concretos que cobrem as funcionalidades dos serviços abstratos especificados na composição inicial. Esse método considera como entrada especificações de composições de alto nível e um conjunto de serviços concretos disponíveis. Composições de alto nível são descritas como regras de programação lógica adaptadas, e incluem a especificação de requisitos de qualidade. O processo de refinamento produz composições de baixo nível, descritas com base em serviços concretos e atendendo aos requisitos de qualidade. Contudo, nas composições resultantes do processo de refinamento o fluxo de dados é expressado por comunicações simples entre os serviços. Nesse trabalho, o problema de geração automática de composição de serviços distingue quatro passos: 1. Especificação: É usada uma linguagem simples para expressar a especificação em alto nível de uma aplicação. A especificação é composta por sub-tarefas, bem como pela interação entre sub-tarefas e os seus requerimentos de qualidade. Uma sub-tarefa pode ser vista como um serviço abstrato requisitado. 2. Refinamento: É usado um algoritmo que procura uma combinação de serviços concretos que implementam as funcionalidades de cada sub-tarefa em uma especificação de alto-nível. Esse refinamento pode gerar várias combinações. 3. Avaliação: Neste passo ocorre a avaliação das soluções obtidas no passo Codificação: Esta etapa tem o objetivo de gerar composições onde a orquestração é estabelecida. O método utilizado para este fim é o foco principal desta dissertação.

20 1.1. Trabalhos relacionados 19 Considerando os passos descritos anteriormente, neste trabalho nos concentramos nos passos correspondentes a especificação à codificação (passos 1 e 4). No passo de especificação, propomos a inserção de informações de controle de alto nível na especificação da composição. Utilizando os resultado dos passos de refinamento e avaliação de trabalho citado, propomos, também, uma etapa de codificação responsável por traduzir a composição em uma orquestração WS-BPEL [ALVES et al., 2006]. Essa orquestração será gerada a partir da análise da dependência entre as variáveis dos serviços. Esta dissertação tem como objetivo geral construir uma composição WS-BPEL a partir de uma descrição abstrata da composição de serviços. Para realização do objetivo principal, foi necessário dividi-lo em alguns objetivos específicos: Propor uma representação de uma composição em alto nível, dotada de informações de controle; Desmembrar especificações de composições abstratas em especificações suportadas pelo método de refinamento proposto por [COSTA et al., 2013]. Encontrar serviços concretos que correspondam as necessidades funcionais dos serviços abstratos, utilizando um algoritmo de reescrita. Identificar dependências de dados entre os serviços participantes da composição, criando assim um fluxograma de execução dos serviços Re-integrar os serviços concretos obtidos pelo algoritmo de reescrita. Converter essa representação em uma representação WS-BPEL através de uma série de mapeamentos que estabeleceremos neste trabalho. A principal contribuição deste trabalho é fornecer códigos executáveis de composições de serviços partindo de especificações abstratas dos mesmos. Anteriormente, o algoritmo de refinamento produzia apenas uma lista de serviços sem ordem de execução estabelecida. Neste trabalho, definimos o workflow da composição a partir de listas de serviços e informações de controle de alto nível e transformamos esse workflow em processo WS-BPEL. 1.1 Trabalhos relacionados Em [ZHAO; LIU; CHEN, 2010], os autores utilizam um algoritmo de reescrita para refinar especificações de composições de serviços. Na primeira etapa, o método proposto utiliza a semelhança entre serviços abstratos e visões de banco de dados para refinar a composição utilizando o algoritmo do Minicon no contexto de serviços. Serviços abstratos

21 20 Capítulo 1. Introdução são especificados como regras DataLog e tratados como visões de Banco Dados. Neste cenário, os autores consideram uma requisição R a um esquema de banco de dados como uma composição de serviços Q, uma visão V como um serviço S, e um conjunto de visões V como um repositório de serviços. Desta forma, uma composição de serviço Q pode ser considerada uma reescrita da consulta ao banco de dados. No entanto, existem duas diferenças entre serviços e consultas: (i) serviços têm entradas, embora não exista tal conceito em consultas; (ii) submetas na definição da consulta são divididas em dois grupos: pré-condições e efeitos (pós-condições). O processo de refinamento consiste em localizar conjuntos de serviços concretos em um repositório com base em informações semânticas e combinar o conjunto de serviços resultantes para reescrever a consulta abstrata usando serviços concretos. O refinamento gera uma lista de serviços concretos, porém não inclui informações de ordem de execução dos serviços envolvidos. Na segunda etapa, o método proposto constrói processos WS-BPEL utilizando os resultados obtidos na primeira etapa. Para isso, o algoritmo valida as composições criadas na fase anterior, cria planos de composições a partir das dependências dos serviços e por fim gera representações de composições WS-BPEL. Comparado ao método adotado nesta dissertação [COSTA et al., 2013], o trabalho anterior traz como principal diferença o fato de que as pre-condições são passadas para o usuário final, mesmo que não sejam satisfeitas, cabendo ao usuário decidir se usa aquele serviço. Em [COSTA et al., 2013], as pre-condições em consideração no ato da reescrita, de forma que apenas serviços que satisfaçam os requerimentos iniciais participarão da composição final. O trabalho [WHITE, 2005] mostra uma conversão de um modelo BPMN para WS-BPEL. Nele é definida uma série de regras de conversão entre os modelos aplicadas a cada construção da representação BPMN. As regra de conversão entre os modelos BPMN e WS-BPEL são mostradas tanto em representação gráfica quanto textual. Este documento está organizado da seguinte forma: No capítulo 2 é mostrado todo o embasamento teórico da pesquisa. O capítulo 3 explana o método criado nessa dissertação. O capítulo 4 avalia os resultados obtidos pelo método, fazendo uso de um estudo de caso. O capítulo 5 faz as considerações finais deste trabalho e apresenta trabalhos futuros.

22 21 2 Fundamentação Teórica Neste capítulo são apresentados conceitos necessários para a compreensão desde trabalho. A princípio são mostrados conceitos e definições acerca de serviços web, como a arquitetura de sistemas baseados em serviços e a pilha de protocolos web. Aqui é mostrado, também, o algoritmo que foi utilizado para fazer o refinamento das composições abstratas e, por fim, é apresentada a linguagem WS-BPEL, utilizada para descrição de composição de serviços concretos. 2.1 Service-Oriented Computing O paradigma Service-Oriented Computing (SOC) usa serviços para suportar o desenvolvimento de aplicações de baixo custo, interoperáveis, e massivamente distribuídas [PAPAZOGLOU et al., 2007]. O modelo SOC se fundamenta sob a Arquitetura Orientada a Serviços (SOA) [PAPAZOGLOU, 2003]. SOC abrange vários conceitos, protocolos e tecnologias originando uma rede de disciplinas incluindo sistemas de computação distribuída, middleware e arquiteturas de computadores, grid computacional, engenharia de software entre outros. Serviços são os principais componentes de SOC, são elementos computacionais auto-descritivos e independentes de plataforma e linguagem. Serviços executam funções, desde as mais simples até processos de negócios mais complicados[papazoglou, 2003]. A arquitetura proposta torna os serviços interoperáveis permitindo que serviços de diferentes fontes possam ser utilizados na criação de diversas composições Web Services Serviços Web (WS) são unidades auto-contidas e modulares de aplicações lógicas as quais fornecem funcionalidades à outras aplicações via uma conexão com a internet [BUCCHIARONE; GNESI, 2006], podem ser descritos, publicados e descobertos [PAPA- ZOGLOU et al., 2007]. A tecnologia Serviços Web [BUCCHIARONE; GNESI, 2006] é uma instanciação bastante aceita de SOC. Esse serviços são descritos com base em protocolos específicos da Web, como: Universal Description, Discovery and Integration (UDDI) [CHAMPION et al., 2002], Web Services Description Language (WSDL) [CHRISTENSEN et al., 2001] e Simple Object Access Protocol (SOAP) [BOX et al., 2011]. O WS s são baseados em notação XML (extensible Markup Language) para representação e estruturação dos dados nas mensagens enviadas e recebidas. Esses serviços são descritos por uma linguagem WSDL [WEERAWARANA et al., 2005]. WSDL são

23 22 Capítulo 2. Fundamentação Teórica linguagens baseadas em XML que especificam um WS definindo as mensagens que fornecem uma definição abstrata dos dados transmitidos e operações que um WS fornece para transmitir as mensagens. O protocolo utilizado para as chamadas de operações é o SOAP [WEERAWARANA et al., 2005]. UDDI é o protocolo utilizado para publicação, pesquisa, descoberta de serviços web. A Figura 1 mostra como esses protocolos são utilizados na interação entre os serviços. Figura 1 Arquitetura Básica de Serviços Web Fonte: Próprio autor O Provedor de Serviço atua como um vendedor de serviços para o cliente, ele cria a descrição dos serviços e publica para que o Registro de Serviço o torne visível para o cliente. O Cliente do Serviço busca serviços no Registro de Serviço fazendo uso de WSDLs para descrever os serviços. O Registro de Serviço (UDDI) recebe serviços de diferentes Provedores de Serviço e retorna ao cliente, note que essa comunicação também e feita através de WSDL. Depois que o Cliente do Serviço recebe as descrições dos serviços do Registro de Serviço, o mesmo executa a composição desses serviços e criar uma ligação direta com o Provedor de Serviço usando o protocolo SOAP. Pilha de Protocolos Para que haja a comunicação entre as três operações de publicar, buscar e ligar, é necessário fazer uso da pilha de protocolos mostrado na Figura 2. Na figura 2 é mostrado um modelo conceitual da pilha de protocolos de serviços web. As camadas mais altas utilizam recursos fornecidos pelas camadas mais baixas. As barras verticais representam os requerimentos que cada camada deve satisfazer [KREGER, 2001]. A camada Rede é a base da pilha, ela deve garantir que os serviços estejam disponíveis em rede. O protocolo HTTP é o padrão para disponibilidade dos serviços pela internet, porém, outros protocolos podem ser utilizados como SMTP e FTP. A camada de Mensagens Baseadas em XML, utiliza XML como base para o protocolo de mensagem. SOAP é o protocolo usado nessa camada para encapsular a mensagem

24 2.1. Service-Oriented Computing 23 Figura 2 Pilha de Protocolos conceitual de Serviços Web Fonte: [KREGER, 2001] e codificar o nome da operação, devido: (i) Sua capacidade de troca de mensagem em ambientes distribuídos; (ii) utilizar XML para codificação de dados e (iii) usar o protocolo HTTP para transporte. A camada de Descrição de Serviço utiliza linguagens para definir a interface dos serviços, sendo a linguagem WSDL comumente usada para este propósito. Neles são guardadas informações como o que um serviço faz, onde ele é localizado e qual a maneira que ele pode ser invocado. Essas três camadas mais baixas garantem a interoperabilidade das transmissões e comunicação entre os serviços. Na camada Publicação de Serviço é feita a disponibilização de serviços em um repositório. Essa publicação é feita via o protocolo UDDI, que utiliza uma base de descrição de serviços compartilhada por vários clientes. O registro UDDI permite desde uma comunicação simples, onde o documento WSDL é enviado diretamente a um cliente, até comunicações mais complexas, onde provedores publicam os documentos WSDL em repositórios para serem acessados por futuros clientes. A camada Descoberta de Serviço também utiliza do protocolo UDDI para fazer a comunicação, e é responsável por fazer a descoberta dos serviços que estão publicados na camada inferior. Note que, a camada de descoberta depende muito da camada de publicação, pois, não é possível descobrir um serviço sem que ele esteja publicado. A camada Composição de Serviço representa a interação entre serviços, descre-

25 24 Capítulo 2. Fundamentação Teórica vendo suas colaborações e fluxos através de uma linguagem de composição. Hoje WS- BPEL é a linguagem de composição mais utilizada, mas, existem outras com o mesmo objetivo tais como PEWS [BA et al., 2005], Windows Workflow Foundation [CHAPPELL, 2012], Orc Language [KITCHIN et al., 2009], BPELJ [BLOW et al., 2004], BizTalz [MON- TESI et al., 2007]. 2.2 Refinamento de Composições de Serviços Consiste em reescrever composições descritas em termos de serviços abstratos em termos de serviços concretos correspondentes. O método proposto em [COSTA et al., 2013] foi inspirado em um algoritmo chamado Minicon [POTTINGER; LEVY, 2000] criado para reescritas de consultas a banco de dados. Uma composição de serviços para reescrita é escrita da seguinte forma C( t) def A 1 ( t 1 ),..., A n ( t n ), Q 1 ( t 1),..., Q m ( t m), onde: C e A 1,..., A n são nomes de serviços abstratos; os átomos A 1 ( t 1 ),..., A n ( t n ) são as chamadas dos serviços abstratos, onde A 1,..., A n referem-se aos nomes dos serviços; o átomo C( t) é chamado de interface da composição e as tuplas t 1, t 2,..., t n contem variáveis ou constantes; cada Q i é um predicado comparativo para a composição. Os elementos que compõem t são parâmetros, esses parâmetros pode ser de entrada (decorados com? ) e parâmetros de saída (decorados com! ), além disso, existem parâmetros adicionais opcionais (decorados com * ). O método visa reescrever o lado direito da composição (definição da composição) utilizando serviços concretos que implementem as funcionalidades dos abstratos. Para isso, o método possui duas fases: A primeira gera um conjunto de PCD s (Parcial Coverage Descriptors) com informações sobre a cobertura das partes da composição inicial; A segunda fase combina esses PCD s de modo a cobrir toda a especificação. Um PCD D para um serviço S e uma composição C é uma tupla formada S c, h c, ϕ c, G c, Def c, has_opt c, onde: - S c é um serviço concreto definido no conjunto de serviços disponíveis S. - h c é um homomorfismo em S c, usado para igualar variáveis na interface da composição. - ϕ c é um mapeamento parcial de Terms(q) para h c (Terms(S c )), Este mapeamento define a correspondência entre os termos da composição abstrata e os termos da composição da definição dos serviços concretos; - G c Subgoals(C) Qly(C) é o conjunto de serviços abstratos ou restrições de qualidade cobertos pela definição de S usando o mapeamento ϕ c.

26 2.2. Refinamento de Composições de Serviços 25 - Def c é um conjunto de restrições de qualidade os quais não são garantidos pelos serviços concretos disponíveis. - has_opt c é um flag, indicando que algum subgoal de S c que foi definido como opcional pertence a G c. Dada uma composição abstrata C(...) def A 1 (...),..., A n (...), Q 1 (...),..., Q m (...) e cada serviço concreto S i (...) def A i (...),..., A j (...), Q k (...),..., Q l (...), o algoritmo tenta buscar na definição dos serviços concretos S i partes que correspondam aos serviços abstratos na definição da composição C. Com esse processo são criados os PCD s, que definem mapeamentos entre as variáveis dos serviços concretos e as variáveis dos serviços abstratos, conforme apresentado no Exemplo 1. Exemplo 1. Sejam C(x?, y!) def A 1 (x?, x?), A 2 (x?, y!) uma especificação de composição abstrata e S(a?, b?) def A 1 (a?, b?), A 2 (a?) uma especificação de um serviço concreto. Podemos usar a definição de S para cobrir a chamada de A 1 (x?, x?) em C. Para esta chamada podemos definir o PCD D = S, h, ϕ, {A 1 },, false onde h(a) = a, h(b) = a e ϕ(x) = h(a). Algoritmo 1 Construção dos PCDs 1: função contruir PCDs (C, S) 2: PCD := 3: para todo serviço abstrato A na definição de C faça 4: para todo serviço concreto S S faça 5: se existe mapeamento h e ϕ para A na definição de C e S então 6: G := {A}; 7: Def := ; 8: PCD := S, h, ϕ, G, Def, has_opt ; 9: AS := {A A é um serviço abstrato ou requerimento de qualidade em C 10: compartilhando parâmetros com A ou com outros elementos de AS}; 11: PCD_OK := true; 12: enquanto AS e PCD_OK faça 13: A := escolha um serviço abstrato a partir de AS; 14: se h, ϕ podem ser estendidos para cobrir A então 15: Atualize PCD de acordo com h, ϕ, G, Def, has_opt 16: AS := AS - A ; 17: senão 18: PCD_OK := false; 19: fim se 20: fim enquanto 21: se PCD_OK então 22: PCDs := PCDs PCD; 23: fim se 24: fim se 25: fim para 26: fim para 27: fim função O Algoritmo 1 corresponde à primeira fase do refinamento. Esse algoritmo constrói um conjunto de PCDs, dados uma composição abstrata C e um conjunto de especificações de serviços S. Para cada serviço abstrato A na definição de C, o algoritmo tenta criar mapeamentos h e ϕ utilizando os serviços concretos disponíveis. Durante a criação desses mapeamentos (linha 5), o algoritmo testa quais parâmetros da interface de C devem ser

27 26 Capítulo 2. Fundamentação Teórica mapeados apenas para parâmetros que estão na interface da especificação dos serviços concretos ou para parâmetros opcionais. Depois, o algoritmo procura por outros serviços abstratos ou requerimentos de qualidade ligados a A (linha 9). O conjunto AS contem todos os serviço abstratos A que possuem uma dependência de dados em relação a A e não foram ainda mapeados por ϕ para os parâmetros de S. Entre as linhas 12 e 20, o algoritmo verifica se os mapeamentos h e ϕ podem ser estendidos para cobrir A. Se possível, o PCD é atualizado para cobrir A (linha 15) e A é retirado de AS (linha 16). Caso contrário, o PCD deve ser descartado (linha 18). Este processo é repetido até AS se esvazie ou que o PCD seja descartado. Por fim, se o PCD for gerado com sucesso, ele é adicionado ao conjunto dos PCDs (linhas 21-23). O Exemplo 2 ilustra o processo mediante o qual a cobertura de um serviço abstrato implica na cobertura de outros, diante de uma dependência de dados. Exemplo 2. Seja C(y!) def A 1 (x?, y!), A 2 (x!), x 10, y {5, 4, 3} uma composição abstrata. Supomos que S(b!) def A 1 (a?, b!), A 2 (a!), a = 8 seja um serviço concreto disponível. Aqui, a variável x foi mapeada para a variável a que não pertence a interface de S. Quando isso acontece, o serviço concreto deve cobrir todo os predicados da composição os quais possuem a variável x. Porém, o algoritmo não pode construir um PCD que atenda ao requerimento de qualidade x 10, pois, a não obedece os requerimentos de x na composição abstrata. Algoritmo 2 Combina PCDs 1: função Combina PCDs (C, PCDs) 2: Dado C(...) def A 1 (...),..., A n (...), Q 1 (...),..., Q m (...) e 3: PCDs = {..., S, h, ϕ, G, Def, has_opt,...} 4: para todo combinação {PCD 1,...,PCD k } PCDs tal que: 5: (a) {A 1 (...),..., A n (...)} G 1... G k ; (b) i, j.g i G j Def i Def j ; (c) Todas os requerimentos em Def 1... Def j são satisfeitos; (d) Entradas e saídas opcionais devem ser compatíveis. faça 6: para todo variável x Q i tal que Q i /G i... G k faça 7: Pre := ; Pos := ; 8: se x é uma parâmetro de entrada de C então 9: Pre := Pre Q i 10: fim se 11: se x é uma parâmetro de saída de C então 12: Pos := Pos Q i 13: fim se 14: fim para 15: publique Pre C (EC( t) def S 1 ( t 1 ),..., S k ( t k ) Pos 16: fim para 17: fim função

28 2.3. WS-BPEL 27 A segunda etapa do refinamento (Algoritmo 2) combina os PCD s gerados na primeira etapa para produzir composições sobre serviços concretos. Juntos, os serviços da composição concreta devem cobrir toda a definição da composição abstrata C. O Algoritmo 2 tenta reescrever a definição da composição abstrata C procurando subconjuntos de PCDs de modo que: (i) todos os serviços abstratos A 1,..., A n em C sejam cobertos (linha 5 (a)); (ii) não exista sobreposição de cobertura para um mesmo serviço abstrato, exceto para requerimentos de qualidade deferidos (linha 5 (b)); (iii) todos os requerimento de qualidade devem ser garantidos (linha 5 (c)); (iv) parâmetros de saída opcionais devem ser mapeados para parâmetros de entrada opcionais (linha 5 (d)). Para cada subconjunto de PCDs atendendo a estas condições, o algoritmo gera pré e pós-condições considerando requerimentos de qualidade não garantidos pelo conjunto de serviços concretos envolvidos (linhas 6-14). Por fim, as combinações encontradas pelos algoritmo são publicadas na linha 15. Note que os parâmetros de uma composição concreta C (EC( t)) def S 1 ( t 1 ),..., S k ( t k ) são obtidos por meio de uma classe de equivalência EC( t). Parâmetros da interface da composição abstrata que fazem parte da mesma classe de equivalência devem ser igualados na interface da composição concreta correspondente. Exemplo 3. Sejam C(x?, y?, z?) def A 1 (x?, y?, w!), A 2 (w?, z!) uma composição abstrata, S 1 (a?, r!) def A 1 (a?, a?, r!) e S 2 (c?, d!) def A 2 (c?, d!) especificações de serviços concretos. O Algoritmo 1 constrói o seguintes PCDs: D 1 = S 1, h 1, ϕ 1, {A 1 }, false,, onde h 1 é a identidade, ϕ 1 (x) = a, ϕ 1 (y) = a e ϕ 1 (w) = r; D 2 = S 2, h 2, ϕ 2, {A 2 }, false, onde onde h 2 é a identidade, ϕ 2 (w) = c, e ϕ 2 (z) = d. Em D 1 tanto x quanto y correspondem ao mesmo parâmetro. Cada ocorrência de a deve ser reescrita com o termo representativo da classe de equivalência {x, y}. Escolhendo x como termo representativo dessa classe de equivalência (EC({x, y}) = x), podemos gerar a composição concreta C da seguinte forma: C (x?, y?, z?) def S 1 (x?, w!), S 2 (w?, z!). 2.3 WS-BPEL WS-BPEL (Web Services Business Process Execution) é uma linguagem baseada em workflow (fluxo de trabalho) para composição de serviços web utilizando algumas especificações XML [ALVES et al., 2006; KHALAF; MUKHI; WEERAWARANA, 2003]. Linguagens como BPEL4WS permitem a modelagem de padrões de interação e favorecem o reuso de serviços. Em BPEL4WS existem vários tipos de atividades primitivas: as atividades invoke, reply e receive facilitam a interação entre os processos e aplicações participantes na composição, a atividade assign copia um dado de uma variável para outra, a atividade wait faz uma espera por algum tempo, a atividade throw levanta falhas para indicar a ocorrência

29 28 Capítulo 2. Fundamentação Teórica de erros, a atividade terminate finaliza uma instancia inteira da composição enquanto que a atividade empty não faz nada, um exemplo de seu uso é a sincronização de atividades simultâneas. Atividades estruturadas são mais complexas do que atividades primitivas, são elas: Atividade sequence que define uma sequência ordenada de passos; A atividade if para estruturas condicionais; A atividade while para definir loop; Atividade pick para selecionar um entre vários caminhos alternativos; A atividade flow para indicar um conjunto de passos que devem ser executados paralelamente. Por conseguinte, alguns aspectos composicionais podem ser suportados com o uso dessas atividades, como por exemplo, permitir integração flexível, mostrar uma composição como um serviço web, suportar múltiplos padrões de composição, como também suportar gerenciamento de ciclo de vida. BPEL4WS suporta dois estilos diferentes de modelagem de processo: um estilo orientado a grafos, gerando composição usando teoria dos grafos com a criação de nós e arestas, e um estilo baseado em programação estruturada que possibilita a construção de fluxo de controle. Essas duas abordagem garantem mais flexibilidade para que o desenvolvedor construa um modelo da forma mais intuitiva [KHALAF; MUKHI; WEE- RAWARANA, 2003]. Ademais, é possível obter um estilo orientado a grafo a partir de um estilo baseado em programação estruturada (Orientada a blocos) [MENDLING; LASSEN; ZDUN, 2008] Elementos básicos de BPEL4WS Nesta seção serão apresentados alguns exemplos da implementação de BPEL4WS, começando com os elementos mais relevantes da linguagem e terminando com um exemplo (ver [ALVES et al., 2006]) da implementação de um processo em BPEL4WS. O elemento process Este é o principal elemento da linguagem BPEL4WS. Ele define o nome do processo pelo atributo name e usa os namespaces para a definição dos processos relacionados [ERL, 2005]. 1 <process name="timesheetsubmissionprocess" targetnamespace=" 3 xmlns= " 5 business process/" xmlns:bpl=" 7 xmlns:emp=" xmlns:inv=" 9 xmlns:tst="

30 2.3. WS-BPEL 29 xmlns:not=" 11 <partnerlinks> </partnerlinks> <variables> </variables> 17 <sequence> </sequence> </process> Listagem 2.1 Exemplo do elemento process Na Listagem 2.1 os namespaces evitam ambiguidades quanto à definição de nomes iguais, com os namespaces é possível usar nomes iguais pertencentes a origens diferentes. Enquanto que o targetnamespace é usado para definir um namespace associado com todos os elementos declarados, em outras palavras, indica de onde vem os elementos e tipos de dados (schema, element, complextype, sequence, string). Nas linhas 3-10 do trecho acima vê-se os seguintes elementos na declaração de um namespace: xmlns é um atributo reservado em XML que indica que o prefixo associado à URI do namespace; " é o nome do namespace; bpl é um exemplo de prefixo associado a um determinado namespace. Os elementos partnerlinks e partnerlink O elemento partnerlink (mostrado na Listagem 2.2) é responsável em definir o tipo de comunicação do serviço que será participante durante o processo, Os elementos partnerlink são declarados dentro do escopo de <partnerlinks>...<\partnerlinks>. Um serviço partner pode ser o cliente e invocar um serviço de processo, como também pode ser invocado por outro serviço parceiro [ERL, 2005]. O seu conteúdo representa a troca de comunicação entre dois parceiros [ALVES et al., 2006]. O partnerlink também contêm os atributos myrole e partnerrole. O primeiro é usado quando o processo de serviço é invocado por um serviço cliente, e o segundo identifica o serviço parceiro que o processo de serviço invocará. Na Listagem 2.2 logo abaixo existe um atributo partnerlinktype, que será explicado na próxima seção. 1 <partnerlinks> <partnerlink name="client" 3 partnerlinktype="tns:timesheetsubmissiontype" myrole="timesheetsubmissionserviceprovider"/>

31 30 Capítulo 2. Fundamentação Teórica 5 <partnerlink name="invoice" partnerlinktype="inv:invoicetype" 7 partnerrole="invoiceserviceprovider"/> <partnerlink name="timesheet" 9 partnerlinktype="tst:timesheettype" partnerrole="timesheetserviceprovider"/> 11 <partnerlink name="employee" partnerlinktype="emp:employeetype" 13 partnerrole="employeeserviceprovider"/> <partnerlink name="notification" 15 partnerlinktype="not:notificationtype" partnerrole="notificationserviceprovider"/> 17 </partnerlinks> Listagem 2.2 Exemplo do elemento partinerlinks O elemento partnerlinktype Ele identifica os elementos da porttype dos WSDL s referenciados pelos elementos partnerlink dentro da definição do processo. O elemento partnerlinktype pode ser colocado em um documento separado ou até dentro de um documento WSDL. A Listagem 2.3 (linhas 8-13) mostra a definição (usando comando definitions dentro de um documento WSDL) do partnerlink Employee criado na linha 12 da Listagem <definitions name="employee" targetnamespace=" 3 xmlns=" xmlns:plnk=" link/" 5... > 7... <plnk:partnerlinktype name="employeeservicetype" xmlns= 9 " link/"> <plnk:role name="employeeserviceprovider"> 11 <porttype name="emp:employeeinterface"/> </plnk:role> 13 </plnk:partnerlinktype} > </definitions> Listagem 2.3 Exemplo do elemento Exemplo de partnerlinktype

32 2.3. WS-BPEL 31 Além disso, múltiplos elementos partnerlink podem referenciar o mesmo partnerlinktype, o que ajuda quando um serviço se relaciona com muitos outros serviços parceiros. O elemento variables Todo conjunto de mensagens e dados são do tipo schema types, devendo ser armazenadas em variáveis. As propriedades e valores destas variáveis podem ser recuperadas durante a execução do processo via funções da linguagem WS-BPEL (getvariableproperty e getvariabledata). Os tipos de dados que podem ser guardados em variáveis precisam ter um dos três atributos, como mostra a Listagem 2.4: messagetype, element ou type [ERL, 2005]. messagetype: permite que a variável contenha uma mensagem WSDL inteira. element: refere-se a uma construção de um elemento XSD 1. type: Pode ser usado apenas para representar um simpletype XSD (String ou Inteiro). 1 <variables> <variable name="clientsubmission" 3 messagetype="bpl:receivesubmitmessage"/> <variable name="employeehoursrequest" 5 element="getweeklyhoursrequestmessage"/> <variable name="employeehoursresponse" 7 type="xsd:duration"/>... 9 </variables> Listagem 2.4 Exemplo do uso de variáveis em BPEL4WS O elemento invoke Este elemento é usado para identificar a operação de um serviço que será invocado durante a execução do processo. Possui cinco atributos (Listagem 2.5 ) [ERL, 2005]: partnerlink: Nomeia o serviço parceiro pelo seu partnerlink correspondente; porttype: Identifica o elemento porttype do serviço parceiro; operation: É a operação do serviço parceiro ao qual o processo fará requisição; 1 XSD (XML Schema Definition) é uma linguagem baseada no formato XML para definição de regras de validação ( esquemas ) em documentos no formato XML.

33 32 Capítulo 2. Fundamentação Teórica inputvariable: É a mensagem de entrada que será utilizada na comunicação com a operação do serviço parceiro; outputvariable: É usada quando a comunicação é baseada em request-response. 1 <invoke name="validateweeklyhours" partnerlink="employee" 3 porttype="emp:employeeinterface" operation="getweeklyhourslimit" 5 inputvariable="employeehoursrequest" outputvariable="employeehoursresponse"/> Listagem 2.5 O elemento invoke O elemento receive Sua função é permitir que o processo espere por uma mensagem [ALVES et al., 2006]. O elemento receive contem um conjunto de atributos vistos na Listagem 4.8: partnerlink: Identificação do cliente do serviço parceiro. porttype: É o porttype que estará esperando receber a mensagem de requisição do serviço parceiro. operation: É a operação que será recebida pelo processo. variable: A variável que guardará a mensagem requisitada. createinstance: Se o valor deste atributo for configurado como yes, esta recepção em particular será responsável pela criação de uma nova instância do processo. <receive name="receiveinput" 2 partnerlink="client" porttype="tns:timesheetsubmissioninterface" 4 operation="submit" variable="clientsubmission" 6 createinstance="yes"/> Listagem 2.6 O elemento receive O elemento reply Este elemento permite que um processo de negócio envie uma resposta a uma mensagem de entrada. Um elemento reply apresenta os seguintes atributos:

34 2.3. WS-BPEL 33 partnerlink: Identificação do cliente do serviço parceiro. porttype: É o porttype que estará esperando receber a mensagem de requisição do serviço parceiro. operation: É a operação que será recebida pelo processo. variable: Armazena a mensagem que a ser retornada. messageexchange: É opcional, permite que um elemento reply seja explicitamente associado a uma mensagem, que possa receber alguma mensagem (tal como o elemento receive). <reply partnerlink="client" 2 porttype="tns:timesheetsubmissioninterface" operation="submit" 4 variable="timesheetsubmissionresponse"/> Listagem 2.7 O elemento reply Os elementos assign, copy, from e to Estes elementos simplesmente proporcionam a habilidade de copiar valores entre as variáveis disponíveis no processo. <assign> 2 <copy> <from variable="timesheetsubmissionfailedmessage"/> 4 <to variable="employeenotificationmessage"/> </copy> 6 <copy> <from variable="timesheetsubmissionfailedmessage"/> 8 <to variable="managernotificationmessage"/> </copy> 10 </assign> Listagem 2.8 Os elementos assign, copy, from e to O valor da variável indicada pela atividade from (linhas 3 e 7) será armazenado na variável indicada pela atividade to (linhas 4 e 8) em atividades copy (linhas 2 e 6). O bloco <assign> do código acima pode ser inserido em blocos de conteúdo como sequence, switch, etc.

35 34 Capítulo 2. Fundamentação Teórica Os elementos faulthandlers, catch e catchall O elemento faulthandlers é responsável por tratar os erros gerados na execução da composição e pode conter vários elementos catch, cada catch fornece uma exceção para cada tipo de erro gerado durante a execução do processo. <faulthandlers> 2 <catch faultname="somethingbadhappened" faultvariable="timesheetfault"> 4... </catch> 6 <catchall>... 8 </catchall> </faulthandlers> Listagem 2.9 Os elementos faulthandlers, catch e catchall O elemento catchall do código acima pode ser usado para definir um comportamento padrão para manipulação de erros. O catchall é ativado quando o erro encontrado não está definido em nenhum dos catch. Na linha 2, o elemento catch define a execução para um determinado tipo de falha (SomeThingBadHappened). O ambiente faulthandlers é comumente utilizado no final da execução principal da composição. O elemento sequence No escopo do elemento sequence estão organizadas todas as atividades de participarão do processo como um todo, executando essas atividades em uma ordem sequencial e pre-definida. Os elementos pertencentes ao escopo de sequence podem ser aninhados, permitindo sequências dentro de sequencias [ERL, 2005]. 1 <sequence> <receive> 3... </receive> 5 <assign>... 7 </assign> <invoke> 9... </invoke> 11 <reply> </reply>

36 2.3. WS-BPEL 35 </sequence> Listagem 2.10 Elemento sequence O elemento while Permite definir ciclos de execução dentro do processo. Essa atividade define um conjunto de ações que devem ser executadas enquanto uma determinada condição é verificada. <while> 2 <condition>$orderdetails > 100</condition> <scope>...</scope> 4 </while> Listagem 2.11 Elemento while Na Listagem 2.11, a linha 2 define que enquanto a condição $orderdetail > 100 for verdadeira, executa-se a atividade scope na linha 3. O elemento pick Nessa atividade são definidos eventos e ações associadas a cada evento. Esses eventos são esperados pela atividade pick. Uma vez ocorrido um evento, executa-se a ação referente ao mesmo[alves et al., 2006]. A atividade pick ocorre em duas formas (Observar a Listagem 2.12): onmessage refere-se a ação que será executada caso um determinado evento ocorra. Possui os atributos partnerlink, porttype e variable com as mesmas funções dos atributos encontrados na atividade receive. onalarm é um alarme que determina um tempo para algum evento acontecer. Se valor de duração especificado no <for> é zero ou negativo, então o <onalarm> é executado imediatamente. <pick> 2 <onmessage partnerlink="buyer" porttype="orderentry" 4 operation="inputlineitem" variable="lineitem"> 6 <! activity to add line item to order > </onmessage> 8 <onmessage partnerlink="buyer" porttype="orderentry"

37 36 Capítulo 2. Fundamentação Teórica 10 operation="ordercomplete" variable="completiondetail"> 12 <! activity to perform order completion > </onmessage> 14 <! set an alarm to go off 3 days and 10 hours after the last order line > 16 <onalarm> <for> P3DT10H </for> 18 <! handle timeout for order completion > </onalarm> 20 </pick> Listagem 2.12 Elemento pick Observe que as atividades onmessage das linhas 2 e 8 estão esperando operações diferentes (linhas 4 e 10), bem como variáveis diferentes (linhas 5 e 11). Na linha 16, é definido o elemento onalarm, definindo um tempo limite para ocorrer algum evento. Caso o evento não ocorra, será executado o bloco onalarm. Deve haver pelo menos um <onmessage> por cada atividade pick. O pick acaba quando o evento selecionado acabar. O elemento flow A atividade flow define uma série de atividades que podem ocorrer tanto concorrentemente quanto de forma síncrona. Ela termina quando todas as atividades englobadas no flow forem completadas. No exemplo abaixo, as duas atividades invoke são iniciadas concorrentemente quando o flow começar. O flow ficará completo quando o Seller e o Shipper responderem, somente depois disso será executado o transfermoney. <sequence> 2 <flow> <invoke partnerlink="seller"... /> 4 <invoke partnerlink="shipper"... /> </flow> 6 <invoke partnerlink="bank" name="transfermoney"... /> </sequence> Listagem 2.13 Elemento flow O elemento if A atividade if fornece um comportamento condicional. O teste condicional é feito no bloco conditon, e pode ser feito mais de um teste utilizando o comando elseif. Caso

38 2.3. WS-BPEL 37 nenhuma das condições seja verdadeira será executado o bloco else. Vejamos o exemplo abaixo: 1 <if xmlns:inventory=" chain.org/inventory" xmlns:flt=" 3 <condition> bpel:getvariableproperty( stockresult, inventory:level ) > </condition> <flow> 7 <! perform fulfillment work > </flow> 9 <elseif> <condition> 11 bpel:getvariableproperty( stockresult, inventory:level ) >= 0 </condition> 13 <throw faultname="flt:outofstock" variable="restockestimate" /> </elseif> 15 <else> <throw faultname="flt:itemdiscontinued" /> 17 </else> </if> Listagem 2.14 Elemento if Na Listagem 2.14 o flow será executado se a condição bpel:getvariableproperty( stockresult, inventory:level ) > 100 (linha 4) for verdadeira. Caso contrário testa-se novamente com outra condição (linha 10-12) e executa-se o throw da linha 13. Se o segundo teste também for falso será executado o throw da linha 16. Outros elementos de BPEL4WS A seguinte lista [ERL, 2005] fornece uma breve descrição de outros elementos relevantes em BPEL4WS: empty: Permite que declarar que nenhuma atividade deve ocorrer para uma condição particular; exit ou terminate: Elimina a instância do processo; throw: Lança um erro para ser tratado no ambiente faulthandlers wait: Cria um atraso dentro do processo.