Geração de processos WS-BPEL com base em um algoritmo de reescrita de regras

(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

(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

(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, 2013.

117 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.

(4)

" " " " "( ) "( ) ) &

* # + ' ,

---*" . / *+

0$ 1

---2 # 3 / *+

04 ) &) $ " 1

---*" . / *+

0 1

---) / *+

0 5 " 1

. / * 0 5 " 1

(5)

(6)

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 Soa-res, Edicarlos SoaSoa-res, Elba Lígia e Simone SoaSoa-res, 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 con-clusã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.

(7)

(8)

(9)

(10)

Os serviços web são soluções computacionais criadas de acordo com os princípios da Com-putaçã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

(11)

(12)

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 specifi-cations, 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.

(13)

(14)

Figura 1 – Arquitetura Básica de Serviços Web . . . 22

Figura 2 – Pilha de Protocolos conceitual de Serviços Web . . . 23

Figura 3 – Exemplo do Cenário . . . 38

Figura 4 – Fluxo Geral da Proposta . . . 45

Figura 5 – Conjunto de arestas . . . 54

Figura 6 – Grafo de dependências de C(b?, x!) . . . 54

Figura 7 – Conjunto de arestas . . . 55

Figura 8 – Conjunto de arestas geradas . . . 56

Figura 9 – Estudo de caso 1 . . . 66

(15)

(16)

1 Introdução. . . 17

1.1 Trabalhos relacionados . . . 19

2 Fundamentação Teórica . . . 21

2.1 Service-Oriented Computing . . . 21

2.1.1 Web Services . . . 21

2.2 Refinamento de Composições de Serviços . . . 24

2.3 WS-BPEL . . . 27

2.3.1 Elementos básicos de BPEL4WS . . . 28

2.3.2 Exemplo . . . 38

3 Geração de Processos WS-BPEL . . . 43

3.1 Visão Geral . . . 43

3.2 Entrada do processo . . . 44

3.2.1 Identificação de Blocos Funcionalidades . . . 47

3.3 Refinamento . . . 49

3.3.1 Geração de Serviços Candidatos . . . 49

3.3.2 Resultados do refinamento . . . 50

3.4 Identificador de Dependências de Dados . . . 51

3.4.1 Grafo de Dependência . . . 52

3.4.2 Determinação de Dependência . . . 55

3.4.3 Gerando as estruturas . . . 56

3.5 Re-inserção de condicional e interação. . . 57

3.6 Regras de Tradução para Código WS-BPEL . . . 57

3.7 Geração de código WS-BPEL . . . 59

4 Experimentos . . . 65

4.1 Estudo de caso . . . 65

5 Conclusões e Trabalhos Futuros . . . 73

Referências . . . 75

APÊNDICE A Exemplo de uma Especificação Abstrata . . . 79

APÊNDICE B Documento XML gerado a partir da saída do refinamento . . 81

APÊNDICE C WSDL do serviço concreto HotelService . . . 83

APÊNDICE D WSDL do serviço concreto Mobile . . . 93

APÊNDICE E Anotações para as operações dos serviços concretos . . . 101

APÊNDICE F Entrada do refinamento para a composição Hotel . . . 103

(17)

(18)

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 para-digma 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 intero-perabilidade 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.

(19)

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 con-cretos 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 2.

(20)

Considerando os passos descritos anteriormente, neste trabalho nos concentramos nos passos correspondentes a especificação à codificação (passos 1 e 4). No passo de espe-cificaçã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 orquestracomposi-çã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 ser-viç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 com-posiçõ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 ser-viços e informações de controle de alto nível e transformamos esse workflow em processo WS-BPEL.

1.1 Trabalhos relacionados

(21)

são especificados como regras DataLog e tratados como visões de Banco Dados. Neste cenário, os autores consideram uma requisiçãoR 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.

(22)

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 de-senvolvimento de aplicações de baixo custo, interoperáveis, e massivamente distribuídas [PAPAZOGLOU et al., 2007]. O modelo SOC se fundamenta sob a Arquitetura Orien-tada a Serviços (SOA) [PAPAZOGLOU, 2003]. SOC abrange vários conceitos, protocolos e tecnologias originando uma rede de disciplinas incluindo sistemas de computação dis-tribuí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 dife-rentes fontes possam ser utilizados na criação de diversas composições.

2.1.1 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 proto-colos específicos da Web, como:Universal Description, Discovery and Integration (UDDI) [CHAMPION et al.,2002], WebServices Description Language(WSDL) [CHRISTENSEN et al., 2001] e Simple Object Access Protocol (SOAP) [BOX et al., 2011].

(23)

linguagens baseadas em XML que especificam um WS definindo as mensagens que forne-cem 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

OProvedor 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. OCliente do Serviço busca serviços noRegistro de Serviçofazendo 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 oProvedor de Serviço usando o protocolo SOAP.

Pilha de Protocolos

Para que haja a comunicação entre as três operações depublicar,buscar eligar, é necessário fazer uso da pilha de protocolos mostrado na Figura2. Na figura2 é 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 dis-poní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.

(24)

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 am-bientes 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 guar-dadas 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 des-criçã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 re-positó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.

(25)

descre-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 A1(¯t1), ..., An(¯tn), Q1(¯t′1), ..., Qm(¯t′m), onde: C e A1, ..., An são nomes de ser-viços abstratos; os átomosA1(¯t1), ..., An(¯tn) são as chamadas dos serviços abstratos, onde

A1, ..., An referem-se aos nomes dos serviços; o átomo C(¯t) é chamado de interface da composição e as tuplas ¯t1, ¯t2,...,¯tn contem variáveis ou constantes; cada Qi é um predi-cado comparativo para a composição. Os elementos que compõem ¯tsã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 Cove-rage 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

éSc, hc, ϕc, Gc,Defc, has_optcê, onde:

- Sc é um serviço concreto definido no conjunto de serviços disponíveis S.

- hc é um homomorfismo em Sc, usado para igualar variáveis na interface da compo-sição.

- ϕc é um mapeamento parcial de T erms(q) para hc(T erms(Sc)), 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;

(26)

- Defc é um conjunto de restrições de qualidade os quais não são garantidos pelos serviços concretos disponíveis.

- has_optc é umflag, indicando que algum subgoal de Sc que foi definido como opci-onal pertence a Gc.

Dada uma composição abstrataC(...)≡def A1(...), ..., An(...), Q1(....), ..., Qm(...) e cada serviço concreto Si(...) ≡def Ai(...), ..., Aj(...), Qk(....), ..., Ql(...), o algoritmo tenta buscar na definição dos serviços concretosSipartes que correspondam aos serviços abstra-tos 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. SejamC(x?, y!)≡def A1(x?, x?), A2(x?, y!) uma especificação de composição abstrata e S(a?, b?) ≡def A1(a?, b?), A2(a?) uma especificação de um serviço concreto. Podemos usar a definição de S para cobrir a chamada de A1(x?, x?) em C. Para esta chamada podemos definir o PCD D =éS, h, ϕ,{A1},∅,falseê onde h(a) = a, h(b) = a e

ϕ(x) =h(a).

Algoritmo 1 Construção dos PCDs

1: funçãocontruir PCDs (C, S)

2: PCD :=∅

3: para todoserviço abstrato A na definição de Cfaça

4: para todoserviço concreto S∈ Sfaça

5: seexiste mapeamentoheϕpara A na definição de C e Sentã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: enquantoASÓ=∅e PCD_OK faça

13: A’ :=escolhaum serviço abstrato a partir de AS;

14: seh,ϕpodem ser estendidos para cobrir A’então

15: Atualize PCD de acordo comh, ϕ, G,Def, has_opt

16: AS := AS -A’;

17: senão

18: PCD_OK :=false;

19: fim se

20: fim enquanto

21: sePCD_OKentão

22: PCDs := PCDs∪PCD;

23: fim se

24: fim se

25: fim para

26: fim para

27: fim função

O Algoritmo1corresponde à primeira fase do refinamento. Esse algoritmo constrói um conjunto de PCDs, dados uma composição abstrataC 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

(27)

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 deAS (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 Exemplo2ilustra 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 A1(x?, y!), A2(x!), x ≥ 10, y ∈ {5,4,3} uma composição abstrata. Supomos que S(b!) ≡def A1(a?, b!), A2(a!), a = 8 seja um serviço concreto dis-ponível. Aqui, a variávelx 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 2Combina PCDs

1: funçãoCombina PCDs (C, PCDs)

2: DadoC(...)≡def A1(...), ..., An(...), Q1(....), ..., Qm(...) e

3: PCDs ={...,éS, h, ϕ, G,Def, has_optê, ...}

4: para todocombinação {P CD1,...,P CDk} ⊆ PCDs tal que:

5: (a) {A1(...), ..., An(...)} ⊆G1∪...∪Gk; (b) ∀i, j.Gi∩Gj ⊆Defi ∩Defj;

(c) Todas os requerimentos em Def1 ... Defj são satisfeitos; (d) Entradas e saídas opcionais devem ser compatíveis.

faça

6: para todo variávelx ∈Qi tal queQi∈/Gi∪...∪Gk faça

7: P re:=∅;P os:=∅;

8: sex é uma parâmetro de entrada de Centão

9: P re:=P re∪Qi

10: fim se

11: sex é uma parâmetro de saída de Centão

12: P os:=P os∪Qi

13: fim se

14: fim para

15: publique éP reêC′(EC(¯t)≡def S1( ¯t1), ..., Sk( ¯tk)éP osê

16: fim para

(28)

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 Algoritmo2 tenta reescrever a definição da composição abstrataC procurando subconjuntos de PCDs de modo que: (i) todos os serviços abstratos A1, ..., An 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

S1( ¯t1), ..., Sk( ¯tk) 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 A1(x?, y?, w!), A2(w?, z!) uma composição abs-trata, S1(a?, r!) ≡def A1(a?, a?, r!) e S2(c?, d!) ≡def A2(c?, d!) especificações de serviços concretos. O Algoritmo1constrói o seguintes PCDs:D1 =éS1, h1, ϕ1,{A1},false,∅ê, onde

h1 é a identidade,ϕ1(x) =a,ϕ1(y) =aeϕ1(w) = r;D2 =éS2, h2, ϕ2,{A2},false,∅êonde onde h2 é a identidade, ϕ2(w) = c, e ϕ2(z) =d. Em D1 tantox quanto y correspondem ao mesmo parâmetro. Cada ocorrência dea 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 S1(x?, w!), S2(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.

(29)

de erros, a atividadeterminatefinaliza 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: Atividadesequence que define uma sequência ordenada de passos; A atividade if para es-truturas condicionais; A atividadewhile para definir loop; Atividadepick 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 compo-sicionais 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].

2.3.1 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 atributonamee usa osnamespacespara a definição dos processos relacionados [ERL, 2005].

1 <process name="TimesheetSubmissionProcess"

targetNamespace="http://www.xmltc.com/tls/process/"

3 xmlns=

"http://schemas.xmlsoap.org/ws/2003/03/

5 business−process/"

xmlns:bpl="http://www.xmltc.com/tls/process/"

7 xmlns:emp="http://www.xmltc.com/tls/employee/"

xmlns:inv="http://www.xmltc.com/tls/invoice/"

(30)

xmlns:not="http://www.xmltc.com/tls/notification/">

11 <partnerLinks>

...

13 </partnerLinks>

15 ...

</variables>

17 <sequence>

...

19 </sequence>

...

21 </process>

Listagem 2.1 – Exemplo do elemento process

Na Listagem2.1 osnamespacesevitam 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; "http://www.xmltc.com/tls/process/"é 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].

OpartnerLink 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"

(31)

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 daportTypedos 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 Listagem2.3 (linhas 8 - 13) mostra a definição (usando comando definitions dentro de um documento WSDL) dopartnerLink Employee criado na linha 12 da

Lis-tagem2.2.

1 <definitionsname="Employee"

targetNamespace="http://www.xmltc.com/tls/employee/wsdl/"

3 xmlns="http://schemas.xmlsoap.org/wsdl/"

xmlns:plnk="http://schemas.xmlsoap.org/ws/2003/05/partner−link/"

5 ...

>

7 ...

<plnk:partnerLinkTypename="EmployeeServiceType" xmlns= 9 "http://schemas.xmlsoap.org/ws/2003/05/partner−link/">

<plnk:rolename="EmployeeServiceProvider"> 11 <portType name="emp:EmployeeInterface"/>

</plnk:role>

13 </plnk:partnerLinkType} >

...

15 </definitions>

(32)

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 tiposchema types, devendo ser arma-zenadas 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 XSD1_.

• type: Pode ser usado apenas para representar um simpleType XSD (String ou Inteiro).

1 <variables>

<variable name="ClientSubmission"

3 messageType="bpl:receiveSubmitMessage"/>

...

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 partnerLinkcorrespondente;

• 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}

(33)

• 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 <invokename="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 elementoreceive 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 comoyes, esta recepção em particular será responsável pela criação de uma nova instância do processo.

<receivename="receiveInput" 2 partnerLink="client"

portType="tns:TimesheetSubmissionInterface" 4 operation="Submit"

variable="ClientSubmission" 6 createInstance="yes"/>

Listagem 2.6 – O elementoreceive

O elemento reply

(34)

• 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 explicita-mente associado a uma mensagem, que possa receber alguma mensagem (tal como o elemento receive).

<replypartnerLink="client"

2 portType="tns:TimesheetSubmissionInterface"

operation="Submit"

4 variable="TimesheetSubmissionResponse"/>

Listagem 2.7 – O elementoreply

Os elementos assign,copy,from e to

Estes elementos simplesmente proporcionam a habilidade de copiar valores entre as variáveis disponíveis no processo.

2 <copy>

<fromvariable="TimesheetSubmissionFailedMessage"/> 4 <to variable="EmployeeNotificationMessage"/>

</copy>

6 <copy>

<fromvariable="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).

(35)

Os elementosfaultHandlers,catch e catchAll

O elementofaultHandlers é 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.

2 <catch faultName="SomethingBadHappened"

faultVariable="TimesheetFault">

4 ...

</catch>

6 <catchAll>

...

8 </catchAll>

</faultHandlers>

Listagem 2.9 – Os elementosfaultHandlers, catch e catchAll

O elemento catchAll do código acima pode ser usado para definir um compor-tamento padrão para manipulação de erros. OcatchAll é ativado quando o erro encon-trado 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 elementosequenceestão organizadas todas as atividades de partici-parã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>

3 ...

</receive>

5 <assign>

...

7 </assign>

9 ...

</invoke>

11 <reply>

...

(36)

</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 é veri-ficada.

<while>

2 <condition>$orderDetails > 100</condition>

4 </while>

Listagem 2.11 – Elemento while

Na Listagem2.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 atividadepick. Uma vez ocorrido um evento, executa-se a ação referente ao mesmo[ALVES et al., 2006].

A atividadepick 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 atributospartnerLink,portTypeevariablecom as mesmas funções dos atributos encontrados na atividadereceive.

• 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 <onMessagepartnerLink="buyer"

portType="orderEntry" 4 operation="inputLineItem"

variable="lineItem">

6 <!−− activity to addline item toorder−−> </onMessage>

8 <onMessagepartnerLink="buyer"

(37)

10 operation="orderComplete"

variable="completionDetail">

12 <!−− activity toperform order completion−−> </onMessage>

14 <!−−set an alarmtogo off

3 days and 10 hours after the last order line −−>

16 <onAlarm>

18 <!−− handle timeout fororder 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 atividadepick. Opickacaba quando o evento selecionado acabar.

O elemento flow

A atividadeflowdefine uma série de atividades que podem ocorrer tanto concor-rentemente quanto de forma síncrona. Ela termina quando todas as atividades englobadas noflow forem completadas.

No exemplo abaixo, as duas atividades invoke são iniciadas concorrentemente quando oflow começar. O flowficará completo quando o “Seller” e o “Shipper” respon-derem, somente depois disso será executado o “transferMoney”.

2 <flow>

<invokepartnerLink="Seller" ... />

4 <invokepartnerLink="Shipper" ... />

</flow>

6 <invokepartnerLink="Bank" name="transferMoney" ... />

</sequence>

Listagem 2.13 – Elemento flow

O elemento if

(38)

nenhuma das condições seja verdadeira será executado o bloco else. Vejamos o exemplo abaixo:

1 <ifxmlns:inventory="http://supply−chain.org/inventory"

xmlns:FLT="http://example.com/faults">

3 <condition>

bpel:getVariableProperty(’stockResult’,’inventory:level’) > 100

5 </condition>

<flow>

7 <!−− perform fulfillment work−−>

</flow>

9 <elseif>

11 bpel:getVariableProperty(’stockResult’,’inventory:level’) >= 0

</condition>

13 <throw faultName="FLT:OutOfStock" variable="RestockEstimate" />

</elseif>

15 <else>

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 con-dição particular;

• exit ou terminate:Elimina a instância do processo;

• throw: Lança um erro para ser tratado no ambientefaultHandlers

(39)

2.3.2 Exemplo

Para mostrar a combinação dos elementos anteriores afim de criar uma composição, é descrito aqui um exemplo de uma requisição de um cliente por um empréstimo em um banco. Este exemplo, assim como a Figura3e as listagens abaixo foram retidas do trabalho de [KHALAF; MUKHI; WEERAWARANA, 2003].

Figura 3 – Exemplo do Cenário

Fonte: [KHALAF; MUKHI; WEERAWARANA, 2003]

O problema apresentado na Figura 3 mostra uma transação de empréstimo ban-cário, onde o “Costumer” faz uma requisição de um empréstimo ao banco, que por sua vez consulta um outro agente chamado “Credit Loan” para consultar a taxa de crédito do cliente. Em seguida, o banco realiza uma nova consulta ao agente “Loan Service” para consultar os termos do contrato do empréstimo. A próxima atividade do banco é contactar oCostumer, mostrando a taxa e os termos do empréstimo. OCostumer, por fim, responde ao banco de aceita ou não o empréstimo.

O Anexo A mostra o código de uma composição de um serviço do empréstimo bancário solicitado por um cliente. Depois de feita a solicitação pelo cliente, o banco passa um subconjunto de informações do cliente para a agência de avaliação de crédito, que retorna para o banco um relatório de crédito. O banco baseia sua decisão sobre esses dados e responde ao cliente, citando uma taxa de juros para o empréstimo desejado. Então, o cliente pode aceitar ou rejeitar os termos do banco (Figura3).

A linha 5 inicia o processo BPEL4WS com o nome deloanApprovalProcess. As linhas 5 - 11 definem os namespaces, neles são especificados as URI’s dos WSDL’s de cada serviço.

<process name="loanApprovalProcess"

6 targetNamespace="http://mybank.com/loanprocessing"

(40)

8 xmlns="http://schemas.xmlsoap.org/ws/2002/07/business−process/"

xmlns:lns="http://loans.org/wsdl/loan−approval"

10 xmlns:loandef="http://tempuri.org/services/loandefinitions"

xmlns:creditagency="http://creditcompany.com/services/creditagency">

Listagem 2.15 – Composição de serviço usando BPEL

As linhas 13 - 24 definem as variáveis utilizadas na orquestração utilizando o bloco <variables>, são elas customerRequest, creditRequest, creditRating, loanTerms e customerDecision, as variáveis permitem que processos mantenham o estado dos dados e o histórico do processo com base nas mensagens trocadas [ALVES et al., 2006].

14 <variable name="customerRequest"

messageType="loandef:customerRequestMessage"/>

16 <variable name="creditRequest"

messageType="creditagency:creditRequestMessage"/>

18 <variable name="creditRating"

messageType="creditagency:creditRatingMessage"/>

20 <variable name="loanTerms"

messageType="loandef:loanTermsMessage"/>

22 <variable name="customerDecision"

messageType="loandef:customerDecisionMessage"/>

24 </variables>

As linhas 26 - 40 definem os partners (serviços que participa-rão da orquestração), a tag <partner name> (linha 28) define o nome do partner, partnerLinkType define o tipo de conversação entre os partners. Para o partner name="customer" (linha 28) o tipo de conversação é partnerLinkType="lns:creditAgencyLinkType". O lns: se trata do namespace refe-rente ao WSDL apontado em xmlns:lns="http://loans.org/wsdl/loan-approval" (linha 9). Enquanto partnerRole(Linhas 34 e 37) define o papel daquelepartner.

26 <partners>

<!−− the customer who invokes this orchestration as a web service−−>

28 <partner name="customer"

partnerLinkType="lns:loanApprovalLinkType"

30 myRole="approver"/>

<!−− the credit agency service who provides the customer is credit rating−−>

32 <partner name="creditAgencyService"

partnerLinkType="lns:creditAgencyLinkType"

34 partnerRole="creditAgency"/>

(41)

36 <!−− based on the credit rating−−>

<partner name="loanTermDeterminationService"

38 partnerLinkType="lns:loanTermLinkType"

partnerRole="loanTermDecider"/>

40 </partners>

No AnexoA, as linhas 41 - 98 definem a sequência de execução desses partners. Nas linhas 45 - 51, o banco recebe as mensagens do cliente (atividadereceive) chamando o serviço approve via o comando operation (linha 47). 49 - 51 utilizam a atividade correlationspara especificar quais informações das variáveis serão utilizadas.

<receive name="receiveLoanRequest" partner="customer"

46 portType="lns:loanApprovalPT"

operation="approve" variable="customerRequest"

48 createInstance="yes">

50 <correlation set="SSN"initiation="yes">

</correlations>

Nas linhas 55 - 60 é feito o mapeamento dos dados necessários para o tipo de mensagem exigido pelo serviço da agência de crédito (Atividade assign). Em 61 - 67 é usada a atividade invoke para obter a classificação de crédito, invocando o serviço da agencia de crédito, utilizando o serviço checkCredit em operation (linha 64). Em 70 - 75 é utilizada a atividade invoke para obter os termos do empréstimo, invocando a operação"getLoanTerms" (linha 72).

56 <copy>

58 <to variable="creditRequest"part="SSN"/>

</copy>

60 </assign>

<!−− get the credit rating by invoking the credit agency service−−>

62 <invoke name="getCreditRating"partner="creditAgencyService"

portType="creditAgency:creditRatingPT"

64 operation="checkCredit"

inputVariable="creditRequest"

66 outputVariable="creditRating">

</invoke>

68 <!−− get the terms of the loan by invoking the loan determination−−>

(42)

70 <invoke name="getLoanTerms"partner="loanTermDeterminationService"

portType="loandef:loanTermDeterminationPT"

72 operation="getLoanTerms"

inputVariable="creditRating"

74 outputVariable="loanTerms">

</invoke>

Nas linhas 77 - 80 o banco repassa os termos do empréstimo ao cliente, utilizando a atividade reply e chamando a operação approve para que o cliente possa aceitar ou não os termos.

<reply name="replyLoanResponse"partner="customer"

operation="approve" variable="loanTerms"

80 </reply>

Nas linhas 85 - 97 o banco recebe a resposta do cliente (Atividadereceivena linha 85) e, utilizando a atividade reply (linha 92) retorna uma confirmação para o cliente. A linha 96 encerra a sequência e a linha 97 encerra o processo.

<receive name="receiveCustomerDecision" partner="customer"

operation="confirm"variable="customerDecision">

88 <correlations>

90 </correlations>

</receive>

92 <reply name="replyLoanResponse"partner="customer"

portType="lns:loanApprovalPT"

94 operation="confirm"variable="customerDecision"

</reply>

96 </sequence>

</process>

(43)

(44)

3 Geração de Processos WS-BPEL

Neste capítulo é proposta uma solução para o problema de criação de composições de serviços concretos a partir de especificações de serviços abstratos. Este capítulo descreve uma série de passos que vão desde a especificação da composição em alto nível até a geração automática de processos WS-BPEL. Inicialmente, são propostas uma extensão da notação de especificação de composições abstratas tomando como base aquela encontrada em [COSTA et al.,2013] e a adaptação dessas especificações para a entrada do algoritmo de refinamento. Essas especificações são refinadas para listas de serviços concretos. Depois, é feita uma análise de dependências entre os serviços, com isso, identifica-se as estruturas de execução dos serviços. Por fim, é feita a geração de processos WS-BPEL.

3.1 Visão Geral

Este trabalho propõe a criação de processos WS-PBEL a partir de uma composi-ção especificada com base em serviços abstratos. Esta abordagem parte de especificações abstratas de serviços, deixa o projetista mais livre no que se refere a disponibilidade dos serviços concretos.

Partir de uma especificação abstrata para um processo concreto requer alguns passos básicos:

• Refinar os serviços abstratos em serviços concretos. Após o refinamento, tem-se uma lista de serviços concretos que atendem às funcionalidades dos serviços abstratos.

• Analisar as dependências entre os serviços da composição de modo que se possa

identificar o fluxo de execução do serviços. As dependências identificadas comple-mentarão as estruturas de controle explícitas da especificação.

• Traduzir o documento produzido pela identificação das dependências em um

pro-cesso WS-BPEL. Analisando o fluxo de execução gerado no item anterior podemos identificar, nas estruturas, atividades WS-BPEL que correspondem ao fluxo de exe-cução encontrado.

(45)

primeiros. Com os resultados do refinamento, é feita uma análise de dependência entre os serviços concretos para determinar o fluxo de execução da composição. Por fim, as composições fornecidas pelo refinamento são traduzidas em um código WS-BPEL.

Apenas dependências de dados podem ser inferidas na especificação original. O algoritmo de refinamento reescreve uma composição C especificada sobre os seguintes ser-viços abstratos para uma composição C’ especificada sobre serser-viços concretos. A notação de entrada para esse algoritmo não nos permite distinguir instruções de condicionais e de repetição na composição, por se tratar de uma lista simples serviços abstratos. Por exem-plo, seria impossível identificar um possívelif apenas analisando as variáveis de entrada e saída dos serviços, ou seja, sem a intervenção do projetista. Veja abaixo como é a entrada do refinamento original proposta em [COSTA et al., 2013]:

C(x,y)≡def A1(x,w), A2(w,y), A3(x,w), A4(w,y)

Por esta razão, é proposta aqui uma extensão dessa consulta, com a inclusão das estruturasif ewhilepelo usuário. Devido a isso não é possível as inferir apenas analisando as dependências entre as variáveis do serviços, essa indicação é feita no ato da especificação da composição abstrata.

A Figura 4, mostra o fluxo geral de todos os módulos da geração de processos WS-BPEL. Na Figura 4 (a) representa a identificação de blocos de serviços abstratos para entrada no algoritmo. Os módulos (b), (c) e (d) na Figura4 correspondem ao fun-cionamento algoritmo de refinamento. A Figura4(b) prepara as sub-composições para o algoritmo de refinamento. Figura4(c) refina cada sub-composição para serviços concretos. A Figura4 (d) faz a escolha da melhor composição gerada pelo algoritmo. Consideramos a primeira lista de serviços como a melhor, pois, esse não é o foco deste trabalho. A Figura 4(e) representa o módulo de identificação de dependências entre os serviços. Na Figura4 (f) a consulta é reformulada com a inserção das informações de controle originais da con-sulta abstrata, para assim gerar a composição em WS-BPEL (Figura 4 (g)), utilizando o módulo mostrado na Figura 4 (h), que faz conexão com os documentos WSDL dos serviços utilizados na composição.

3.2 Entrada do processo

(46)

Figura 4 – Fluxo Geral da Proposta

sanar o problema gerado pela simplicidade da composição original. Dessa forma, foram adicionadas a composição original instruções de controle como repetição e tomada de decisão.

Na notação estendida, uma composição pode estar na forma de uma lista serviços, na forma de uma estrutura condicional ou na forma de uma estrutura de repetição. Nessa extensão, não é permitida aninhamento de tais estruturas de controle, desse modo não será possível, por exemplo, uma estrutura de repetição conter uma estrutura condicional, ou vice-versa. Abaixo exemplos de como deve ser especificada uma consulta.

Exemplo 4. Composição utilizando uma sequência de serviços:

C1(A?,C!) ≡def A1(A?,X!), A2(X?,Y!) A3(Y?,C!)

(47)

lista representa uma funcionalidade. É importante notar que a ordem desses elementos não especifica necessariamente sua ordem de execução. Cada especificação define apenas as funcionalidade exigidas de cada serviço, assim como, a relação entre os parâmetros desses serviços. Essa relação entre parâmetros define as dependências entre os serviços, por exemplo, o parâmetroXé um parâmetro de saída em A1 e entrada em A2, significando que há uma dependência entre A1 e A2. Uma dependência similar existe entre A2 e A3, com relação ao termoy.

Exemplo 5. Composição utilizando If/else:

C1(A?,C!)≡def if A1(A?,X!) then A2(X?,Y!) A3(Y?,C!) else

A4(X?,Y!) A5(Y?,C!)

No caso da estrutura condicional, utilizamos apenas a estrutura condicional if, que pode ser utilizada sem o complemento doelse. É importante destacar que o serviço que indica a condição do if, neste trabalho, deve fornecer uma única saída, sendo ela do tipo booleano. No Exemplo 5, no serviço A1(A?,X!) a variável de saída X é do tipo booleano.

De maneira análoga ao if, a estrutura de repetição while não permitirá aninha-mento de estrutura e será a única estrutura de repetição a ser usada na especificação das consultas.

Exemplo 6. Composição utilizando while:

C1(A?,C!)≡def while A1(A?,X!) do A2(X?,Y!) A3(Y?,B!) A4(B?,W!) A5(W?,C!)

(48)

3.2.1 Identificação de Blocos Funcionalidades

Esta seção mostra como adaptar a consulta estendida para que seja entrada do algoritmo de refinamento. O algoritmo de refinamento utilizado para fazer a conversão de serviços abstratos para serviços concretos não suporta nenhum tipo de instrução de controle. Com a extensão da linguagem de especificação da composição, gerou-se uma incompatibilidade entre a linguagem de especificação estendida da composição e o tipo entrada do algoritmo de refinamento. O algoritmo de refinamento apenas aceita como en-trada uma composição nos moldes da composição original. Com isso, surgiu a necessidade de identificar lista de serviços independentes na consulta estendida, de modo que ela seja compatível com a entrada do refinamento.

Para essa identificação foi proposta uma divisão da composição estendida em blo-cos, de maneira que cada bloco tenha o formato de uma lista de serviços. Esses blocos de serviços pode ser identificados, segundo a definição da composição, de três formas dis-tintas: (i) pode-se encontrar uma lista de serviço (sem nenhuma instrução de controle), nesse caso, será gerada uma entrada com a interface e os serviços da definição formando assim a entrada do refinamento; (ii) uma estrutura condicional if, formada por três de blocos de funcionalidades, um para os serviços referentes a condição doif, um para o bloco then e outro, opcional, referente ao else; (iii) uma estrutura de repetição while, com dois blocos de funcionalidades, um para a condição de parada e outro para os serviços pertencentes ao bloco da repetição.

Exemplo Demonstrativo

Para demonstrar cada passo da abordagem proposta, criamos dois exemplos des-critos a seguir. O Exemplo 7 corresponde a uma especificação utilizando a estrutura if enquanto o Exemplo 8 corresponde a uma especificação utilizando a estruturawhile.

Exemplo 7. Composição abstrata usando if:

CA1(A?,B?,C!,D!) ≡def if menor(A?,B?,L!) then sub(B?,A?, C!)

add(B?,C?,D!)

else

sub(A?,B?, C!) add(A?,B?,D!)