Uma máquina de redução de grafos para serviços web

Catalogação da Publicação na Fonte. UFRN / SISBI / Biblioteca Setorial Centro de Ciências Exatas e da Terra – CCET.

Carvalho, Daniel Aguiar da Silva.

Uma máquina de redução de grafos para serviços web / Daniel Aguiar da Silva Carvalho. - Natal, 2013.

81 f. : il.

Orientador: Prof. Dr. Martin Alejandro Musicante. Co-orientador: Prof. Dr. Alberto Pardo.

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. Sistemas distribuídos – Dissertação. 2. Serviços web – Dissertação. 3. Linguagens de orquestração de serviços – Dissertação. 4. Linguagem de composição PEWS – Dissertação. 5. Máquinas de redução de grafos – Estatística – Dissertação. I. Musicante, Martin Alejandro. II. Pardo, Alberto. III. Título.

Serviços web são software acessíveis através da Internet que disponibilizam funcionalidades a serem usadas por aplicações. Hoje, é natural reutilizar ser-viços de terceiros para compor novos serser-viços. Este processo de composição pode acontecer em dois estilos, denominados orquestração e coreografia. A coreografia representa uma colaboração entre serviços os quais conhecem a aplicação à qual pertencem e o momento exato para executarem. Já a or-questração possui um processo central, o orquestrador, que coordena todas as operações da aplicação. É neste contexto que este trabalho se encaixa, propondo um modelo abstrato para a execução de orquestrações de serviços. Com esta finalidade, será definida uma máquina de redução de grafos para a implementação de orquestrações de serviços especificadas em uma variante da linguagem de composição PEWS. Ademais, um protótipo desta máquina (em Java) será construído como prova de conceito.

Web services are software accessible via the Internet that provide functi-onality to be used by applications. Today, it is natural to reuse third-party services to compose new services. This process of composition can occur in two styles, calledorchestration and choreography. A choreography represents a collaboration between services which know their partners in the composi-tion, to achieve the service’s desired functionality. On the other hand, an orchestration have a central process (the orchestrator) that coordinates all application operations. Our work is placed in this latter context, by propo-sing an abstract model for running service orchestrations. For this purpose, a graph reduction machine will be defined for the implementation of ser-vice orchestrations specified in a variant of the PEWS composition language. Moreover, a prototype of this machine (in Java) is built as a proof of concept.

1 Introdução 5

2 Fundamentação 10

2.1 Serviços Web . . . 10

2.1.1 Arquitetura Orientada a Serviços . . . 11

2.1.2 Conceitos Básicos . . . 12

2.1.3 A Pilha de Protocolos e Padrões . . . 13

2.1.4 Noções de Composição deWeb Services: Orquestração e Coreografia . . . 16

2.2 Linguagens para Orquestração . . . 18

2.2.1 BPEL . . . 18

2.2.2 PEWS . . . 20

2.2.3 Outras Linguagens . . . 27

2.3 Máquinas de Redução de Grafos . . . 28

3 PEWS-AM: Arquitetura e Implementação 33 3.1 Visão Geral . . . 33

3.2 Regras de Tradução . . . 34

3.3 Configuração da Máquina Abstrata . . . 43 3.4 Relação de Avaliação . . . 44 3.5 Implementação . . . 53

4 Prova de Conceito 61

5 Conclusões 68

2.1 Interação ideal para a Arquitetura Orientada a Serviço. . . 11

2.2 Interação entre cliente e serviço [37]. . . 12

2.3 Pilha de ProtocolosWeb Services [41]. . . 14

2.4 Exemplo de orquestração de Serviços Web [35]. . . 16

2.5 Exemplo de coreografia de serviços web [35]. . . 17

2.6 Programa PEWS referente ao exemplo 1. . . 23

2.7 Exemplo 2. . . 24

2.8 Exemplo de redução de grafo. Os valores de saída (output) estão abaixo de cada grafo [30]. . . 30

3.1 Tradução de uma operação S(E, X). . . 37

3.2 Tradução de uma composição em paralelo. . . 39

3.3 Tradução de uma composição em sequência. . . 40

3.4 Tradução de uma escolha não-determinística. . . 41

3.5 Tradução de umworkflow condicional. . . 42

3.6 Tradução de umunfolding. . . 43

3.7 Redução de uma chamada S!E. . . 46

3.8 Redução de uma operação de saída S?X. . . 47

3.9 Primeira situação de redução de um vértice +. . . 48

3.10 Segunda situação de redução de um vértice +. . . 49

3.11 Terceira situação de redução de um vértice +. . . 51

3.12 Redução de um vértice µ(Mu). . . 52

3.13 Diagrama de classes compacto de PEWS-AM. . . 54

3.14 Código parcial da classe Vertice. . . 55

3.15 Código parcial das classes Chamadae Expr. . . 56

3.16 Código parcial das classes Retornoe Variavel. . . 56

3.17 Código parcial da classe OutputInput. . . 57

3.18 Código parcial da classe Expressao eenum Operador. . . 57

3.19 Código parcial da classe Grafo. . . 58

3.20 Código parcial da classe Maquina. . . 59

4.1 Exemplo de programa PEWS que implementa o sistema de monitoramento. . . 63

Introdução

Atualmente, usar sistemas distribuídos é algo comum tanto em ambientes acadêmicos como em ambientes empresariais [60]. Isto se deve, por exemplo, à visibilidade global de acesso às informações, uma maior automação, pro-cessos de negócios mais eficientes e à evolução na segurança de comunicação através da web. Neste contexto, houve um avanço considerável das tecno-logias para a Internet o que, consequentemente, proporcionou uma série de inovações as quais modificaram a maneira como as informações e os negócios de empresas são gerenciados [64]. Isto gerou uma mudança de paradigma no desenvolvimento de aplicações distribuídas, adotando aplicações indepen-dentes e fracamente acopladas, no lugar do método tradicional de construção deste tipo de sistema, o qual usa aplicações rigidamente acopladas [23, 59].

Neste âmbito, surge uma nova arquitetura para a implementação de sis-temas, a arquitetura orientada a serviços (SOA) [23], a qual é uma forma de organizar o software em um conjunto de serviços. Uma tecnologia que per-mite a integração e implementação de aplicações seguindo esta arquitetura

são os serviços web (do inglês, web services). Os serviços web são software independentes, modularizados, acessíveis através da web que disponibilizam um conjunto de funcionalidades para aplicações [64]. A característica mar-cante desta tecnologia é a independência de plataforma. Isto quer dizer que um cliente programado em uma determinada linguagem e sendo executado em um determinado sistema se comunica com um servidor construído em uma outra linguagem e funcionando em outro ambiente. Para garantir esta independência, na implementação de serviços web se utilizam padrões adota-dos pela indústria como SOAP [70] e WSDL [16]. O SOAP é utilizado como protocolo para troca de mensagens e o WSDL como padrão para definir in-terfaces e mecanismos para comunicação com serviços.

Nesta nova organização das aplicações, muitas empresas apenas desen-volvem a lógica principal do seu negócio e utilizam serviços de terceiros para outras funcionalidades (não menos importantes) [55]. Este processo de reuti-lizar serviços pré-existentes para construir novos serviços, chamado de com-posição de serviços, é naturalmente adequado, visto que além dos serviços implementarem funcionalidades específicas e independentes, a reusabilidade é uma das vantagens atingíveis a partir da SOA.

As linguagens para a composição de serviços viabilizam estes dois esti-los de modelagem. A linguagem padrão para a composição de serviços é a Linguagem de Execução de Processo de Negócios para Serviços (Business

Process Execution Language for Web Services) (BPEL4WS ou BPEL) [3], mas é importante saber que existem outras como, por exemplo, PEWS [7], ORC [40], Windows Workflow Foundation (WF) [58], entre outras.

Em um contexto diferente do qual se encontram os serviçosweb, estão as máquinas de redução de grafos. Elas são uma técnica onde uma expressão é representada na forma de um grafo e, a partir de regras de reescrita definidas previamente, esta expressão é transformada para formas intermediárias até que ela não possa ser mais reduzida [39]. Estas máquinas foram amplamente utilizadas para a implementação de linguagens funcionais como, por exemplo, a Máquina SKI [65], a Máquina G [30], Alice [57] entre outras.

Grafos tem sido usados na representação de serviços web. Por exemplo, definir grafos para estruturar processos em workflows é um método utilizado para a composição de serviços [55]. BPEL é um exemplo de linguagem que permite a especificação de um processo na forma de um grafo dirigido, todavia várias abordagens possibilitam o mesmo como [55, 58, 53, 74, 73, 27], entre outros. Estes grafos proveem uma maneira natural e intuitiva para definir processos em workflows [42]. É interessante observar que as máquinas de redução de grafos parecem ser adequadas à implementação de serviços web, porém desconhecemos a existência de pesquisas que as utilizem como forma de implementar este tipo serviços.

um lado, vários trabalhos como, por exemplo, [40, 42, 11, 47, 69] abordam a análise abstrata do problema da orquestração de serviços, baseando-se em diferentes formalismos para definir a orquestração e solucionar alguns proble-mas como a sincronização, paralelismo, transações etc. E no outro extremo, encontram-se as implementações das orquestrações [19, 9, 14, 58]. Assim, esta dissertação tem duas grandes motivações: (i) encurtar a distância que existe entre a definição formal da orquestração de serviços e a sua implemen-tação; e (ii) propor um modelo formal de execução para a orquestração de serviços web.

Este modelo formal de execução que será apresentado no decorrer desta dissertação vai ser utilizado como especificação para a implementação do back-end da linguagem de composição PEWS. Esta foi escolhida, pois é uma linguagem de orquestração criada e desenvolvida por pesquisadores da UFRN em conjunto com outros (Université d’Orléans1

). Além do mais, PEWS pos-sui construtores comuns a outras linguagens de orquestração, similar a BPEL, que permitem descrições claras e simples de orquestrações de serviços.

Os objetivos do nosso trabalho incluem:

a) Propor uma máquina de redução de grafos para implementação da or-questração de serviços web;

b) Especificar uma variante da linguagem PEWS para a orquestração de serviços web (Esta linguagem é representativa de uma grande classe de linguagens de orquestração, a qual inclui BPEL);

c) Propor regras de tradução desta variante de PEWS para os grafos tratados

1

pela máquina; e

d) Desenvolver um protótipo da máquina como prova de conceito.

Fundamentação

Este capítulo trata de temas relacionados ao assunto geral do trabalho. Estes são: serviços web, PEWS, máquinas de redução de grafos e gramáticas de grafos.

2.1

Serviços Web

A busca, por parte das empresas, pela realização de negócios via Web, vi-sando alcançar mais automação, processos eficientes e visibilidade global, vem ocasionando uma mudança de paradigma no desenvolvimento de aplicações distribuídas, adotando aplicações independentes e fracamente acopladas, no lugar do método tradicional de construções deste tipo de sistemas, o qual usa aplicações rigidamente acopladas [64]. Neste contexto surgiu a tecno-logia dos web services - ou Serviços Web - que proporcionam a integração e implementação de sistemas seguindo a Arquitetura Orientada a Serviços (Software-Oriented Architecture - SOA) [26]. As próximas seções tratam de

conceitos fundamentais relacionados aos serviços web.

2.1.1

Arquitetura Orientada a Serviços

Os serviços web encontram-se inseridos no contexto da Arquitetura Orien-tada a Serviços (SOA) a qual é uma maneira de organizar o software em um conjunto de serviços que estão interconectados e acessíveis através de interfa-ces e protocolos de mensagens. Ao utilizar a SOA, uma série de vantagens são atingíveis como reusabilidade, integração, interoperabilidade, arquitetura e soluções simples, padronização para a representação de dados (usando XML), agilidade organizacional, entre outras [23].

Figura 2.1: Interação ideal para a Arquitetura Orientada a Serviço.

figura 2.1 [54]. Os clientes, através de operações de procura, buscam por descrições de serviços nos registros de serviços e usam a descrição para se conectar a um provedor de serviços para interagir com a implementação do serviço. O provedor de serviços define descrições de serviços e as publica para um cliente ou para um registro de serviços o qual disponibiliza as descrições para clientes.

2.1.2

Conceitos Básicos

Serviços web são software independentes, modularizados, acessíveis atra-vés da Web que disponibilizam um conjunto de funcionalidades para apli-cações [64]. Diferentes serviços podem se encontrar em servidores distintos e cada operação de um serviço é executado ao ser requisitado por um cliente. A mensagem de requisição enviada pelo cliente contém informações relevan-tes sobre o serviço como: o identificador do serviço, o nome da operação e parametros de entrada (se houver). Após a requisição, o serviço é executado e uma mensagem de resposta contendo o resultado da operação é enviada para o cliente [37]. Este modelo de interação entre cliente e serviço pode ser visto na figura 2.2.

Figura 2.2: Interação entre cliente e serviço [37].

programado em uma determinada linguagem e sendo executado em um de-terminado sistema se comunica com um servidor construído em uma outra linguagem e funcionando em outro ambiente [37]. Para isto, o modelo per-mite a publicação e o acesso a serviços na Internet [64] através de uma série de operações que incluem: criação, descrição, publicação, descoberta, invoca-ção, binding (conexão), cancelamento, composição, gerenciamento, monito-ramento, billing (cobrança) e segurança de serviços. Esse modelo nada mais é do que uma instância da arquitetura orientada a serviços apresentada na figura 2.1.

2.1.3

A Pilha de Protocolos e Padrões

Para garantir que as operações de publicar, procurar e conectar aconteçam de forma interoperável, a adoção de uma arquitetura em diversas camadas, denominada pilha de protocolos de serviços web se faz necessária [13, 41]. A figura 2.3 apresenta esta pilha conceitual dos serviços web, na qual as ca-madas superiores são construídas a partir de funcionalidades providas pelas camadas inferiores. O bloco à direita contém requisitos que devem ser abor-dados em cada camada e, o texto à esquerda, indica as tecnologias padrões que são usadas em cada camada.

Figura 2.3: Pilha de Protocolos Web Services [41].

páginas web.

A próxima camada utiliza XML (eXtensible Markup Language) [71] como base para o protocolo de mensagem. SOAP (Simple Object Access

Proto-col) [70] foi o protocolo escolhido para esta camada pelas seguintes razões [41]: (i) é um protocolo para troca de mensagens em ambientes distribuídos; (ii) utiliza XML para codificação de dados e HTTP como protocolo de trans-porte; e (iii) ele envelopa a mensagem e especifica a codificação da operação e os parâmetros.

infor-malmente propriedades como o que um serviço faz, onde ele está localizado e como ele é invocado.

As três camadas descritas formam a base para uma arquitetura onde o acesso e utilização de qualquer serviço web ocorre de forma interoperável. Já as camadas seguintes, de publicação e descoberta, podem ser implementadas com uma variedade de tecnologias [41].

A publicação de um serviço consiste no ato de disponibilizar um docu-mento WSDL para um cliente. O exemplo mais simples da implementação desta camada é a publicação direta na qual um documento WSDL é enviado diretamente a um cliente. Uma outra alternativa, ocorre quando provedores de serviços publicam documentos WSDL em repositórios para serem acessa-dos posteriormente por clientes. A principal tecnologia utilizada para estes repositórios é o UDDI (Universal Description, Discovery, Integration) que utiliza uma base de registro compartilhada por diferentes clientes, permi-tindo descrever, registrar e localizar serviços [13]. É importante notar que a camada de descoberta depende diretamente da camada de publicação uma vez que serviços não podem ser descobertos se não foram publicados anteri-ormente.

que ela permite a composição de serviços a partir da descrição de processos de negócios. BPEL é o padrão mais usado nos dias de hoje, mas outras lin-guagens existem para este fim, como, por exemplo, PEWS [7], ORC [40] ou

Windows Workflow Foundation [15].

2.1.4

Noções de Composição de

Web Services

_:

Orques-tração e Coreografia

A composição de serviço web a partir de operações disponibilizadas por ou-tros serviços web envolve questões de integração de aplicações e suas funci-onalidades [35]. A combinação de serviços para a criação destes serviço web

compostos pode ocorrer de duas formas: a orquestração e a coreografia.

Figura 2.4: Exemplo de orquestração de Serviços Web [35].

ser visto na figura 2.4, este serviço controlador, o orquestrador ou mediador, está ligado a todos os serviços que fazem parte da composição, invocando todas as operações necessárias, mas estes serviços “terceirizados” não tem o conhecimento a respeito da aplicação a qual fazem parte, ou seja, desconhe-cem o motivo pelo qual o orquestrador realizou a chamada a uma de suas operações [35].

Ao contrário da orquestração, a coreografia (ver figura 2.5) não possui um processo central. Ela consiste em uma colaboração de serviços que têm um objetivo comum [8]. Cada serviço participante desta composição sabe quando deve executar, a hora para enviar uma mensagem, as mensagens que serão trocadas e com quem interagir. A coreografia é um processo de negócio público, ou seja, todo serviço tem o conhecimento da aplicação a qual faz parte [35].

Figura 2.5: Exemplo de coreografia de serviços web [35].

a coreografia, possui algumas vantagens como [35]: (i) todo o gerenciamento da aplicação está centralizado em um único componente Isto facilita a imple-mentação e a complexidade de entendimento das interações entre os serviços; (ii) os serviços da composição não estão cientes da aplicação maior à qual são participantes; e (iii) o orquestrador pode, em situações de falhas, incluir cenários alternativos.

2.2

Linguagens para Orquestração

Esta seção trata de algumas linguagens que possibilitam a orquestração de serviços web. BPEL, que é considerada a linguagem padrão, e PEWS, que é a linguagem utilizada neste trabalho, terão subseções específicas. Outras linguagens serão apresentadas na seção 2.2.3.

2.2.1

BPEL

Web Services Business Process Execution Language(WS-BPEL, BPEL4WS ou BPEL) [3, 19] é uma linguagem para especificar comportamentos em pro-cessos de negócios baseada em serviços web. BPEL é uma linguagem de composição de serviços web baseada em workflow (Fluxo de trabalho) [38].

estilos de modelagem, o projetista tem flexibilidade para escolher aquela que se adapte melhor aos seus requisitos.

A linguagem permite especificar dois tipos de processos de negócios: os abstratos e os executáveis [3]. Os últimos definem o comportamento de um participante em uma interação de negócio. Os primeiros descrevem um pro-cesso que não tem a intenção de ser executado e deve omitir detalhes opera-cionais que estão especificados em processos executáveis.

Uma composição em BPEL é um processo (process). Os serviços que se comunicam com estes processos são denominados participantes (partners) e as ações realizadas por estes estão definidas na forma de uma atividade (activity) [12]. As atividades podem ser primitivas (ou básicas) ou estrutu-radas. As básicas incluem: invoke, reply e receive, que são primitivas

para troca de mensagens; wait, para esperar por algum tempo (pausa do

processo); assign, para fazer copia de dados; throw, para tratamento de

ex-ceções; terminate, para finalizar a instância da composição; e empty, para

não executar nada [38]. Estas atividades básicas podem ser combinadas usando as seguintes atividades estruturadas: sequence, usada para

especi-ficar um sequência de passos; switch, para condicionais; while, para loop;

pick, para executar algum caminho alternativo ou aguardar por eventos

ex-ternos; flow, para expressar o parelelismo entre atividades; e links, que

podem ser usadas junto a flow para indicar dependências entre as

2.2.2

PEWS

Path Expressions for Web Services (PEWS) [7] é uma linguagem para definir o comportamento de serviços web compostos. A implementação de serviços web utiliza linguagens como, por exemplo, o WSDL para a descrever os ser-viços. PEWS aparece como uma extensão destas linguagens [12]. Através da incorporação das predicate path expressions [4] para o contexto dos serviços web, a linguagem permite definir e especificar comportamentos para serviços. Ademais, PEWS propõe-se não somente a ser uma linguagem para especifi-car serviços, mas também para implementá-los. Isto é possível, pois permite programar as ações relacionadas ao processamento de dados de um serviço.

Predicate Path Expressions [4] foram incialmente propostas como uma ferramenta sincronização de processos concorrentes onde a sincronização é especificada como uma sequência de operações permitidas em um objeto.

Path Expressions são construções em linguagens de programação que regem a sequência de operações realizadas por objetos (no contexto deste trabalho, entenda-se por serviços) como, por exemplo, a path expression:

a*;(b ||c)

a;([B]b + [not B]c)

Onde define-se que a execução de b ou c depende do valor (Verdadeiro ou Falso) do predicado B e deve ser precedida pela execução de a.

A ideia em PEWS é adaptar a proposta de Andler [4], trazendo as

Predi-cate Path Expressions para o contexto dos serviços web. A estrutura de um programa PEWS (P) é definida como:

P ::= S(E, X)|P1kP2 |P1 ;P2 |[E1]P1+ [E2]P2

| if [E1]P1 |unfold |unfolding P1

E ::= id|n |t|E₁+E₂ |E₁−E₂ |E₁∗E₂ |E₁/E₂ | −E₁

| E1 and E2 |E1 or E2 |not E1 |E1 == E2 |E1 ≤E2

| E1 < E2 |(E1)|S .{act, req, term}.{time n}

Segundo a gramática acima, um programa PEWS é composto por path

expressions as quais representam os serviços que estão sendo definidos pelo programa. As path expressions estão definidas por P na gramática acima. Elas podem conter: (i) operações S (E, X), nas quais E é uma tupla de expressões (parâmetros) de entrada para a operação e X é uma tupla de variáveis (parâmetros) de saída; (ii) composição em paralelo (P1kP2); (iii) composição em sequencia forte P1 ; P2, onde todas as operações deP1devem ser executadas antes de qualquer operação de P2; (iv) uma escolha não-determinística (+) [E1]P1 + [E2]P2, ondeE1 e E2 representam guardas para

condicional de um serviço if [E₁] P₁ onde P₁ só poderá ser executado seE₁

for verdadeiro; e (vi) loops (repetições) são representados pelos construtores

unfolding P e unfold1

. O unfolding P quando avaliado substituirá todas as ocorrências de unfold dentro deP (corpo da iteração) por unfolding P1.

A gramática paraE define expressões aritméticas e booleanas. Oid é um identificador; n, um valor numérico; e t, um valor-verdade. Neste contexto, a linguagem fixa alguns contadores de predicados que são definidos como um par (val, time) de inteiros associados. O primeiro termo do par, o val, representa o contador em si. Já o segundo, o time, guarda o momento da última modificação do contador. Para cada operação (S) de um serviço web

existem três contadores2

:

• req(S): o componenteval representa o número de vezes que a operação

O foi requisitada. O componente Time indica o momento da última requisição.

• act(S): o componente val representa o número de vezes que a operação

O começou a ser executada. O componente Time indica o momento da última ativação do serviço.

• term(S): o componenteval representa o número de vezes que a operação

O foi executada e finalizada. O componente Time indica o momento da última conclusão do serviço.

Exemplo 1: De forma a ilustrar como PEWS pode ser utilizado para a especificar e para descrever serviços web, considere o exemplo retirado de [7].

1

O operador * das path expressions de [4] foi substituído por este construtor.

2

Em uma loja, suponha que o pagamento deverá ser feito dentro de 48 horas

após o envio da fatura. Se este prazo não for respeitado, todo o processo é

abortado. Um possível programa PEWS que poderia descrever esta situação seria: unfolding( fazerPedido(produto, confirmacao); enviarConta(produto, nroPedido); receberPagamento(nroPedido, nroOrdem); time(now, horaAtual); time(enviarConta, horaDaFatura); ([horaAtual - horaDaFatura <= 48]

emitirRecibo(nroPedido, nroOrdem) + [horaAtual - horaDaFatura > 48]

emitirEstorno(nroPedido, nroOrdem) ); unfold

)

Figura 2.6: Programa PEWS referente ao exemplo 1.

Neste exemplo acima, o processo de realizar um pedido (fazerPedido),

enviar conta (enviarConta) e receber pagamento (receberPagamento) está

inserido em uma iteração definida pelo construtor unfolding.

A operaçãotimetem como retorno uma hora. Esta operação é executada

duas vezes em sequência: uma enviando como parâmetro anow para

recupe-rar e armazenar a hora atual na variável horaAtual; e outra, enviando como

parâmetro enviarConta para recuperar e armazenar a hora que a fatura

foi gerada na variável horaDaFatura. Após isto, os predicados que

apare-cem nas expressões [horaAtual - horaDaFatura <= 48] e [horaAtual

re-alizado fora do prazo das 48h, um estorno é emitido. Em ambos os casos, inicia-se novamente o processo de compra. Note que o construtor unfold é

responsável por trazer o controle de volta ao inicio da iteração.

Serviços web são, por princípio, aplicações que serão invocadas por outras aplicações na web. Por conta disto, se faz conveniente ter uma versão XML da linguagem. No caso de PEWS, a sua versão XML recebeu o nome de XPEWS [7]. XPEWS é um documento no formato XML que complementa a descrição de serviços, que estão em um documento WSDL, adicionando restrições comportamentais.

Exemplo 2: Considere a especificação a seguir:

showMap ||

( hotelInformation;(reservationRoom || carRental); museumInformation

)

Figura 2.7: Exemplo 2.

O trecho de código acima representa a especificação de uma composição de serviços para recuperar informações turísticas sobre uma cidade como hotéis, lugares para entretenimento e agências para locação de carros3

. Esta orquestração define que a execução do método showMap ocorre em paralelo

com a execução de um sub-programa no qual o método hotelInformation

é executado em sequência junto com a execução em paralelo dos métodos

reservationRoom e carRental. No final, estes métodos são seguidos da

execução do método museumInformation.

3

O código abaixo apresenta o documento XPEWS referente ao exemplo 2. Nele pode-se notar o elemento raiz <envelope>. Em um documento

XPEWS, neste elemento estão definidos os comportamentos possíveis para um serviço. Por exemplo, é possível especificar diferentes ordens em que operações que manipulam um serviço são acessadas. No exemplo em questão, tem-se definido o comportamento para o a orquestração de serviços a qual recupera informações turísticas.

<envelope xmlns="http://consiste.dimap.ufrn.br" xsi:schemaLocation="http://consiste.dimap.ufrn.br pews.xsd"> <behaviour name="new_file" xmlns:namespaceA= "http:\\www.dimap.ufrn.br/MapsService.wsdl" xmlns:namespaceB= "http:\\www.dimap.ufrn.br/HotelInformationService.wsdl" xmlns:namespaceC= "http:\\www.dimap.ufrn.br/CarRentalService.wsdl" xmlns:namespaceD= "http:\\www.dimap.ufrn.br/MuseumInformationService.wsdl" xmlns:namespaceE= "http:\\www.dimap.ufrn.br/OtherCarRentalService.wsdl" xmlns:namespaceF= "http:\\www.dimap.ufrn.br/OtherHotelInformationService.wsdl"> <operations>

<operation name="showMap" portType="portType" refersTo="namespaceA:showMap"/>

<operation name="reservationRoom" portType="portType" refersTo="namespaceB:reservationRoom"/> <operation name="carRental" portType="portType"

refersTo="namespaceC:carRental"/>

refersTo="namespaceB:hotelInformation"/> <operation name="museumInformation" portType="portType"

refersTo="namespaceD:museumInformation"/> <operation name="otherCarRental" portType="portType"

refersTo="namespaceE:carRental"/>

<operation name="otherHotelInformation" portType="portType" refersTo="namespaceF:hotelInformation"/> </operations> <pathExp> <par> <operation name="showMap"/> <seq> <operation name="hotelInformation"/> <par> <operation name="reservationRoom"/> <operation name="carRental"/> </par> <operation name="museumInformation"/> </seq> </par> </pathExp> </behaviour> </envelope>

A maneira como um cliente interage com um serviço está definida no elemento <behaviour>. Esta interação é definida pela path expression, re-presentada pelo elemento <pathExp>. Este elemento possui dois atributos. O name que é o identificador do próprio elemento e o target que refere-se a

O ambiente PEWS é constituído por duas partes: um front-end e um

back-end. O front-end está construído como um plugin para a plataforma Eclipse, o Editor PEWS. Ele provê suporte à programação em PEWS, au-xiliando ao usuário a gerar documentos XPEWS que serão utilizados pelo

back-end para coordenar os serviços [51]. Oback-end é composto por um ve-rificador de tipos e um gerador de código Java a partir de programas XPEWS. Todavia é importante saber que esta parte do ambiente contém problemas que tornam o seu uso impossível, devido a isto esta parte será substituída pela máquina de redução de grafos proposta neste trabalho.

2.2.3

Outras Linguagens

As duas linguagens apresentadas nas seções anteriores não são as únicas que permitem a composição de serviços web. Existem muitas outras propostas na bibliografia. Algumas outras linguagens de composição são:

Windows Workflow Foundation (WF) [15, 58]: é umframework parte da plataforma windows para desenvolvedores (Windows Plataform for

Develo-pers). Ele possibilita a construção de aplicações baseadas emworkflows onde é possível coordenar interações entre serviços. O conceito básico usado neste modelo é a atividade (activity). Um workflow funciona como um container

de atividades onde é possível expressar explicitamente fluxos de controle;

Orc Language [40, 1, 18]: é uma linguagem para construir aplicações

serviços;

BPELJ (BPEL for Java) [9]: é uma solução para construção de processos de negócio na qual as duas linguagens, BPEL e Java, são usadas juntas, tor-nando possível inserir trechos de código Java, denominados Java snippets, em definições de processos BPEL;

JOLIE (Java Orchestration Language Interpreter Engine) [50]: é um orques-trador de serviços web. Para tornar o desenvolvimento de aplicações mais amigável ao programador, a sintaxe da linguagem é baseada em C e Java ao invés do trabalho em XML;

Entre várias outras [5, 43, 17, 68, 42, 47, 11, 69, 21, 61, 56, 14].

2.3

Máquinas de Redução de Grafos

O termo Redução de Grafos, proposto inicialmente por Wadsworth [72], refere-se a uma técnica na qual uma expressão (redutível) é substituída por sua forma reduzida. Em detalhes, uma expressão é representada como um grafo orientado onde existe a noção de nó raiz. Cada nó pode representar, por exemplo, uma chamada de função com seus nós sucessores representando os argumentos para esta função. Este grafo será transformado durante a execução da expressão, sendo que cada sub-grafo avaliado será substituído por uma expansão do mesmo ou pelo valor da expressão. Este processo de substituição é realizado repetidamente até que o grafo alcance a sua forma normal, ou seja, tenha sido reduzido a um valor.

programa-ção. Isto se deve ao compartilhamento de sub-expressões comuns que são representadas na forma de um único grafo o qual será reduzido uma única vez [6, 32].

Para um melhor entendimento, considere o exemplo retirado de [30], abaixo.

Exemplo: Dado o programa funcional escrito em uma linguagem com avaliação preguiçosa (lazy evaluation) a seguir.

letrec from n = n.from(succ n) in from 0

O resultado deste programa é a lista potencialmente infinita dos números naturais. Para este exemplo, Johnsson [30] considerou como forma normal (ou canônica) para uma expressão quando ela assumir valores inteiros, cons-tantes booleanas, lista de expressões e.e’ e aplicação de funçõesf e1...em onde f é uma função que leva menos argumentos do que os m possíveis. No

programa, succé uma função sucessor pré-definida e ’.’ é um operador para construção de lista, sua justaposição indica uma aplicação de função.

A figura 2.8 apresenta o processo de redução de grafos para este programa. Nela o símbolo ’@’ denota a aplicação de função.

Aplicando-se a regra de reescrita da funçãofrom, a expressão inicial 2.8(a)

é transformada para 2.8(b) onde temos uma referência para o inteiro 0 que substituiu o parâmetro ’n’ da regra. Em 2.8(b), a expressão está em sua forma normal. Agora, o inteiro 0 pode ser um valor de saída (output) e o nó raiz do grafo (.) é retirado como pode ser visualizado em 2.8(c). Novamente, a regra from deve ser aplicada ao grafo que está em sua forma normale.e’.

Figura 2.8: Exemplo de redução de grafo. Os valores de saída (output) estão abaixo de cada grafo [30].

é mostrado em 2.8(e). Em 2.8(f), 1 é o resultado como saída e o nó raiz é novamente retirado do grafo. Este processo é repetido indefinidamente.

De acordo com [39] existem dois estilos de máquinas de redução de grafos: a pura e a programada. Elas se diferenciam no momento da escolha do próximo passo da redução. A máquina de redução pura tem a propriedade de que a seleção do próximo passo da redução é derivado dinamicamente da expressão atual em cada etapa da sequência de reduções [52]. Exemplos de máquinas puras são as que possuem arquitetura baseada no λ-calculo

máquinas programadas, os passos da redução são derivados da expressão original através de uma análise estática do programa. Um exemplo deste tipo de máquina é a máquina G [30].

PEWS-AM: Arquitetura e

Implementação

Este capítulo destina-se a descrever a arquitetura e a implementação de PEWS-AM (Acrônimo de PEWSAbstract Machine), uma máquina de redu-ção de grafos para a implementaredu-ção de orquestrações de serviços web. Nas próximas seções, serão apresentadas uma visão geral da máquina abstrata, a gramática utilizada, as regras de tradução desta gramática para grafos, as regras de redução destes grafos e questões pertinentes à implementação.

3.1

Visão Geral

Usar grafos para representar composições de serviços é uma abordagem co-mum a várias soluções de middleware para serviços web, tanto para fins acadêmicos como na indústria [7, 55]. Na maioria destas abordagens, a re-presentação do grafo é utilizada para gerar um programa o qual executa a

semântica do serviço.

Neste trabalho, diferentemente dessas abordagens, propõe-se a interpre-tação direta do grafo que representa a composição. Isso é possível devido a um conjunto de regras de tradução as quais implementam o comportamento de cada construtor do programa o qual descreve a composição.

Assim, a máquina abstrata é definida mediante dois elementos principais: (i) um conjunto de regras de tradução (definidas pela função de tradução

T que traduz os programas PEWS em grafos); e (ii) um conjunto de re-gras de redução de grafos (para executar a orquestração). A execução de um programa PEWS corresponde à aplicação repetida de regras de redução, partindo do grafo gerado pela funçãoT, até obter um grafo que não possa ser reduzido usando as regras da máquina. A próxima seção apresentará como é realizada a tradução de um programa para os grafos utilizados pela máquina abstrata.

3.2

Regras de Tradução

P ::= S(E, X)| P1 k P2 |P1 ;P2 | [E1]P1+ [E2]P2

| if[E₁]P₁ | unfold |unfolding P₁

E ::= id|n |t|E1+E2 |E1−E2 |E1∗E2 |E1/E2 | −E1

| E1 and E2 |E1 or E2 |not E1 |E1 == E2 |E1 ≤E2

| E₁ < E₂

Esta linguagem é uma variante da linguagem PEWS. Esta variante destaca-se pela troca explícita de dados possibilitada pelo construtor S(E, X). De acordo com a gramática, um programa (P) é formado por path expressions

que representam os serviços os quais estão sendo definidos para uma com-posição. Neste programa é possível especificar: operações, composições em sequência, composições em paralelo, escolhas não-determinísticas, condici-onais e repetições. Ademais, expressões aritméticas e booleanas formadas a partir de identificadores de variáveis e operadores aritméticos, lógicos e relacionais estão definidas na gramática E.

É importante notar que a estrutura de um programa (P) impõe dois tipos de restrições as quais definem diretamente da ordem em que a operações são chamadas dentro do serviço definido pela composição. Estas são:

compo-nente da construção devem ser executadas após o término da execução de todas as operações do primeiro componente.

Restrições de fluxo de dados: Estas restrições são impostas pela ordem em que as variáveis são atribuídas e utilizadas dentro de um programa. Por exemplo, à uma variável X de um programa, deve ser atribuído um valor antes que esta seja utilizada em uma expressão.

Devido a estas restrições, neste trabalho utiliza-se outra definição para grafos representados por hV, Ac, Adi, a qual inclui um conjunto de vértices e dois tipos de arestas: (i) arestas de controle (Ac) que representam as restri-ções de fluxo de controle; e (ii) arestas de dependência (Ad) que representam as restrições de fluxo de dados.

Ao longo do trabalho usaremos as seguintes funções:

• indegreec(v) devolve o número de arestas de controle que chegam no vértice v.

• indegreed(v) devolve o número de arestas de dependência que chegam no vértice v.

• indegree(v) = indegreec(v) + indegreed(v).

A regra de tradução de uma operação S(E, X), com E representando uma tupla de expressões de entrada e X uma tupla de variáveis de saída, é traduzida para o grafo:

T[[S(E, X)]] = h {w :S!E, w′ _{:S?X}, {w7→w}′_},∅i

O grafo resultante (ver figura 3.1) é composto por dois vértices, o w e w’, que contém, respectivamente, expressões de entrada e variáveis de saída. O conjunto das arestas de controle é formado somente uma aresta que parte dew

aw’. Esta aresta garante que dados resultantes da execução da operaçãoS!E serão armazenados nas variáveis da operação X. O conjunto das arestas de dependência de dados é vazio visto que este tipo de vértice resolve variáveis. Então, vértices que possuem expressões são os candidatos a possuírem arestas de dados originadas de vérticesS?X. Note que o único vértice mínimo (raiz) do grafo definido neste caso é w.

Figura 3.1: Tradução de uma operação S(E, X).

e P₂ é expressa a seguir.

T[[P1kP2]] =

let _T[[P

1]] =hV′, A′c, A′di

T[[P2]] =hV′′, A′′c, A′′di

in _hV′_∪V′′_{, A}′

c∪A′′c, A′d∪A′′d∪∆′d∪∆′′di

where _∆′

d={v1 7→v2| v1 :S1?X ∈V′, se v2 :S2!E ∈V′′ e

∃x∈Vars(E). x∈X ou se v2 :E ∈V′′

e ∃x∈V ars(E), x∈X}

∆′′

d ={v₂ 7→v₁|v₂ :S₂?X ∈V′′, se v₁ :S₁!E ∈V′

e ∃x∈Vars(E). x∈X ou v₁ :E ∈V′

e ∃x∈Vars(E). x∈X}.

No grafo gerado (Figura 3.2), o conjunto dos vértices é formado pela união dos conjuntos dos vértices de cada um dos grafos correspondentes aP₁ eP₂. O conjunto de arestas de controle Ac é formado pelas arestas de controle de ambos grafos. E o conjunto de arestas de dependência será formado pelo conjunto de arestas de dependência de ambos os grafos unidos às arestas de dependências entre vértices v1 7→v2, tais que o conteúdo do vértice v1 é

S1?X e o conteúdo do vértice v2 é E ou S2!E, tal que uma das variáveis X aparece em E. Estes arcos indicam que alguma variável da tupla de variáveis

X retornada a uma operação S1 é utilizada em uma expressão condicionalE ou em uma chamada S₂!E. Note que estas arestas podem partir tanto deP₁

para P2 como de P2 para P1.

Figura 3.2: Tradução de uma composição em paralelo.

serviços é expressa a seguir:

T[[P1;P2]] =

let _{T[[P1]] =hV}′_{, A}′

c, A′di

T[[P₂]] =hV′′_{, A}′′

c, A′′di

in _hV′_∪V′′_{, A}′

c∪A′′c ∪∆c, A′d∪A′′d∪∆di

where _∆c ={v₁ 7→v₂|v₁ ∈V′, v₂ ∈V′′, indegreec(v₂) = 0},

∆d={v₁ 7→v₂| v₁ :S?X ∈V′, se v₂ :E ∈V′′ e

∃x∈Vars(E). x∈X ou se v2 :S!E ∈V′′

e ∃x∈Vars(E). x∈X}.

No grafo (Figura 3.3), o conjunto dos vértices V é formado pela união dos conjuntos de vérticesV’ eV”. O conjunto das arestas de controleAc é a união dos conjuntosA’c eA”c, adicionando-se as arestas de controle que partem de cada vértice deV’ para os vértices deV” que são candidatos a serem avaliados (expresso pela função indegreec(v₂) = 0, que indica que o vértice não possui arestas de controle chegando a ele). O conjunto de arestas de dependência

Figura 3.3: Tradução de uma composição em sequência.

A regra de tradução de uma escolha não-determinística entre dois serviços

P1 e P2 é apresentada a seguir.

T[[[E1]P1+[E2]P2]] =

let _{T[[P1]] =hV}′_{, A}′

c, A′di

T[[P2]] =hV′′, A′′c, A′′di

in _hV′ _∪V′′_{∪ {v : +, v}

1 :E1, v2 :E2}, A′c∪A′′c ∪∆, A′d∪A′′d i

where _{∆ ={v 7→v1, v 7→v2} ∪∆}′_∪∆′′

∆′ _={v

1 7→w| w∈V′, indegreec(w) = 0}

∆′′_={v

2 7→w| w∈V′′, indegreec(w) = 0}

No grafo (Figura 3.4), o conjunto dos vértices é formado pela união dos conjuntos de vértices dos ramos do construtor, ao qual são adicionados mais três vértices (v, v₁ e v₂). O vértice v contem o símbolo + para indicar a escolha e os vértices v₁ e v₂ contém as expressões condicionais (E₁ e E₂) que irão ou não permitir a execução do grafo correspondente. O conjunto das arestas de controle Ac é formado pela união das arestas de controle dos grafos correspondestes a P1 e P2, adicionando-se as arestas que vão de v a

avaliação em P₁ e as arestas que vão de v₂ aos vértices candidatos em P₂. Note que a funçãoindegree é novamente utilizada para verificar se há arestas chegando ao vértice.

Figura 3.4: Tradução de uma escolha não-determinística.

A regra de tradução de um serviço condicional é apresentada a seguir:

T[[if[E₁]P₁]] =

let _{T[[P]] = hV, A}c, Adi

in _{hV ∪ {v : +, v1 :E, v2 :f alse}, A}c∪ {v 7→v₁, v 7→v₂} ∪ ∆, Ad i

where _{∆ = {v1 7→w|w∈V, indegree}c(w) = 0}

conjunto das arestas de controle são adicionadas as arestas que vão de v av₁

e v₂, bem como as que partem de v₁ até os vértices candidatos a avaliação do grafo correspondente a P1. E as arestas de dependência Ad.

Figura 3.5: Tradução de umworkflow condicional.

A regra de tradução de um unfold consiste em criar somente um vértice e marcá-lo como sendo do tipo unfold. Estes vértices representam pontos específicos onde o controle é transferido para o inicio da iteração (loop). Eles são usados juntamente com construtores unfolding.

A regra de tradução dounfolding está apresentada abaixo:

T[[unfolding P₁]] =

let _{T[[P1]] = hV, A}c, Adi

in _{hV ∪ {v :µ}, A}c∪ {v 7→w|w∈V, indegreec(w) = 0}, Adi

O grafo resultante (Figura 3.6) é formado pelo conjunto dos vértices V

arestas que vão deµaté os vértices candidatos a avaliação do grafo (indegree

zero) e as arestas de dependência Ad.

Figura 3.6: Tradução de umunfolding.

3.3

Configuração da Máquina Abstrata

PEWS-AM é uma máquina de redução de grafos pura, a qual receberá como entrada o grafo gerado pelas regras de tradução da seção 3.2, a partir de uma composição de serviços. A configuração da máquina é uma quádrupla como definido a seguir:

hhV, Ac, Adi, ρ, I, Oi

um valor, valor); I (input), é um buffer de parâmetros entrada formada de triplas (operação, vértice, lista de valores); e O (output), é um buffer de parâmetros saída formada por triplas (operação, vértice, lista de valores). Na próxima seção serão apresentadas as regras de redução de grafos executados pela máquina.

3.4

Relação de Avaliação

A relação de avaliação é fornecida através de regras de redução que serão aplicadas aos grafos que foram definidos na seção anterior. O processo de avaliação é iniciado sob alguns vértices “especiais”, ou seja, os vértices que são candidatos a serem reduzidos. Estes vértices podem ser: S!E (chamadas a serviços);S?X(saída de serviços); o vértice + (presente em composições onde existe escolha não-determinística de serviços e em operações condicionais); e vértices µ(presentes em iterações).

Para apresentar as regras de redução de grafos utiliza-se a configuração apresentada na seção anterior (3.3). A notação utilizada para as regras é a seguinte: dada uma configuração inicial (CI), se determinadas condições (presentas na cláusula where) forem satisfeitas, obtém-se (indicado pelo sím-bolo =⇒) uma configuração final (CF). A seguir um exemplo para ilustrar:

hCIi

=⇒

hCFi

A seguir estão apresentadas seis regras de redução de grafos definidas para a máquina abstrata. Para cada regra utilizaremos a notação mencionada acima juntamente com um ilustração para facilitar a compreensão.

Regra 1: Considere a regra de avaliação de uma chamada a um serviço

S!E apresentada a seguir.

hhV[v₁ :S!E, v₂ :S?X], Ac[v₁ 7→v₂], Adi, ρ, I, Oi

=⇒

hhV[v2 :S?X], Ac, Adi, ρ, I, O[(S, v₂, Eval(E))]i

where _indegree(v

1) = 0.

Figura 3.7: Redução de uma chamada S!E.

Regra 2: Considere a regra de avaliação de uma operação de saídaS?X.

hhV[v1 :S?X], Ac, Adi, ρ, I[(S, v₁, t)], Oi

=⇒

hhV, Ac− {v₁ 7→v₂|v₂ ∈V}, Ad− {v₁ 7→v₂|v₂ ∈V}i, ρ′, I, Oi

where _indegreec(v₁) = 0

ρ′ _=ρ[(x

i, v₁, ki|1≤i≤n)],

X=< x1, ..., xn >,

t=< k1, ..., kn> .

Nesta configuração inicial (Figura 3.8 - Lado esquerdo), o grafo contém um vértice v1 que é uma operação S?X de um serviço e na lista de entrada tem-se uma terna contendo o nome do serviço S, o vérticev1 e o conjunto de valores t procedentes da saídaS. Se indegreec(v₁) = 0, ou seja, se a operação de chamada a S relativa ao v1 já foi avaliada, a avaliação da operação S?X resulta em uma configuração final (Figura 3.8 - Lado direito) onde o vértice

valores da tupla t.

Figura 3.8: Redução de uma operação de saída S?X.

Regra 3: A avaliação de um vértice + pode ocorrer de três maneiras distintas. A primeira situação está descrita a seguir. Considere a regra de avaliação de um vértice + seguido de uma condição E ainda não avaliada.

hhV[v1 : +, v2 :E], Ac[v₁ 7→v₂], Adi, ρ, I, Oi

=⇒

hhhV[v1 : +, v2 :Eval(E)], Ac[v₁ 7→v₂], Adi, ρ, I, Oi

where _{indegree(v1) = 0}

indegreec(v₂) = 1

indegreed(v₂) = 0

Nesta configuração inicial (Figura 3.9 - Lado esquerdo), o grafo contém um vértice v1 que indica a operação + e um vértice v2 que contém uma expressão condicional ainda não avaliada. Uma aresta de controle v₁ 7→ v₂

do vértice v₂ é substituída por Eval (E) (avaliação da expressão E).

Figura 3.9: Primeira situação de redução de um vértice +.

Regra 4: A segunda situação para a avaliação de um vértice + ocorre quando na configuração inicial existe um vértice + seguido de uma expressão avaliada como verdadeira (true). Considere a regra de avaliação a seguir.

hhV[v : +, v₁ :true, v₂ :E], Ac[v 7→v₁, v 7→v₂], Adi, ρ, I, Oi

=⇒

hG′_{, ρ, I, Oi}

where _{indegree(v) = 0}

V′ _{={w∈V(T[[[E}

1]P1+[E2]P2]]) |v2 7→∗c w}

G′ _{=hV, A}

c, Adi \V′

expressão E). As arestas de controle v 7→ v₁ e v 7→ v₂ ligam o vértice + às suas expressões guarda. Nesta situação onde existe uma expressão avaliada como verdadeira, o valor das outras (mesmo que verdadeiras também) não serão importantes para a avaliação e serão removidas do grafo juntamente com os seus subgrafos correspondentes. Estando o vértice + pronto para ser avaliado (ou seja, indegreec(v) = 0), o grafo resultante (Figura 3.10 -Lado direito) G’ consiste no grafo original removendo-se os vértices v e v1, bem como a aresta que os ligava, e restringindo-se os vértices do conjunto

V’ que são os vértices acessíveis a partir de v₂ em zero ou mais passos o que, neste caso, inclui também o vérticev2. Esta restrição de grafo (indicada por \) consiste em remover os vértices e arestas de controle e dependência correspondentes a eles.

Figura 3.10: Segunda situação de redução de um vértice +.

(false). Considere a regra de avaliação a seguir.

hhV[v : +, v1 :false, v2 :false], Ac[v 7→v₁, v 7→v₂], Adi, ρ, I, Oi

=⇒

hG′_{, ρ, I, Oi}

where _{indegree(v) = 0}

V′ _{={w∈V(T[[[E}

1]P1+[E2]P2]])|v 7→∗c w}

G′ _{=hV, A}

c, Adi \V′

Figura 3.11: Terceira situação de redução de um vértice +.

Regra 6: Considere a regra de avaliação de vérticesµos quais represen-tam os iterações/recursões.

hG, ρ, I, Oi

=⇒

hhG[wGw

]h{v},∅,∅ii, ρ, I, Oi

where _{G=hV[v :µ], A}c, Adi

indegreec(v) = 0

Gw

=hVw , Aw

c, A w di

Nesta regra, w representa todos os vértices unfold atingíveis a partir de

v por arestas de controle que não são atingíveis por outros vérticesunfolding

que fazem parte do grafoT[[unfolding P₁]]. Gw

dependência. G[wGw

] é o grafo formado pela substituição de cada vértice

w porGw .

Considerando a configuração inicial (Figura 3.12 - Lado esquerdo), o con-junto de vértices do grafo contém um vérticeµ(Mu) pronto para ser avaliado (ou seja, indegree(µ) = 0). O grafo resultante (Figura 3.12 - Lado direito) da avaliação deste vértice conterá o conjunto dos vértices de G (removendo-se o vértice µ) unidos ao conjunto de vértices Vw

. O conjunto final de arestas de controle é formado pelas arestas de controle do grafo originalAc (removendo as arestas de controle que ligavam µ a outros vértices do grafo) unidas as arestas de controle Aw

c criadas no momento da cópia dos vértices de G w

. O conjunto final das arestas de dependência é formado pelas arestas de depen-dênciaAdunidas as arestas de dependênciaA

w

d criadas no momento da cópia dos vértices de Gw

.

3.5

Implementação

A implementação da PEWS-AM é feita através de um programa na lingua-gem Java. Para criar o parser que traduz os programas segundo a gramática que foi definida (e também de acordo com as regras de tradução definidas na seção 3.2) para a estrutura em grafos que serão executados pela máquina, utilizou-se o Jacc [31]. O Jacc (acrônimo de Just another compiler -

com-piler for Java) é um gerador de parsers para Java similar (e com sintaxe compatível) ao Yacc [29] (gerador de parser para a linguagem C).

A figura 3.13 apresenta a hierarquia de classes da implementação da má-quina. A estrutura em grafos gerada peloparser está implementada de acordo com esta hierarquia. No decorrer desta seção serão apresentados trechos de código Java referentes às classes implementadas para a máquina. Note que, para não tornar a leitura cansativa, estes trechos não contem todo o código implementado. Eles servem somente para apresentar um noção de como foi realizada a implementação.

A superclasse Token1

é uma classe abstrata que deve ser retornada em cada passo da recursão do parser. Existem seis classes que implementam os distintos vértices utilizados pela máquina. São elas: (i) Chamada que

representam os vértices S!E; (ii) Retornoque representam os vértices S?X;

(iii)Somaque representam os vértices +; (iv)Exprque representam os vértices

que contêm somente as expressões guardas que estão ligadas aos vértices

Soma; (v) Mu que representam os vértices µ; e (vi) Unfold que representam

1

Por uma limitação da ferramenta Jacc, a classe Token _{foi criada. Todas as classes}

Figura 3.13: Diagrama de classes compacto de PEWS-AM.

os vértices unfold.

As classesSoma,MueUnfold não contém atributos e métodos específicos.

Elas herdam somente os atributos e métodos da classe abstrata Vertice

(Figura 3.18).

A classeVerticecontêm sete atributos. inDegreeControlee

inDegree-Dependencia são inteiros que representam, respectivamente, o número de

arestas de controle e o número de arestas de dependência que chegam ao vér-tice. A lista de vértices listaDeControle representa os vértices acessíveis a

partir de arestas de controle que partem deste vértice e alistaDeDependencia

contém referências aos vértices que dependem de variáveis do programa PEWS

atribuídas neste vértice. Os inteiroshashcodeMu,hashcodeVariavelehashcodeSOMA

to-public abstract class Vertice extends Token {

private int inDegreeControle; private int inDegreeDependencia;

private List<Vertice> listaDeControle; private List<Vertice> listDeDependencia; private int hashcodeMu;

private int hashcodeVariavel; private int hashcodeSOMA;

...

}

Figura 3.14: Código parcial da classe Vertice.

dos os seus sucessores acessíveis a partir de arestas de controle deverão ter o atributo hashcodeMu igual ao seu códigohash (um inteiro identificador do objeto).

A diferença entre as classes Expr e Chamada está somente no atributo

nomeDaOperacaoda classeChamadaque identifica a operação que será

execu-tada. O atributo expressoescontém as expressões aritméticas ou booleanas

que serão utilizadas nestes vértices. Isto pode ser visto na figura 3.15. A classe Retorno contém somente uma lista de variáveis indicada pelo

atributo listaDeVariaveis. Cada objeto Variavel contém um nome, um

hashcode (um identificador de qual vértice pode utilizá-la) e um valor (Figura 3.16.

As listas de variáveis da classe Retornosão preenchidas com as

informa-ções da classe OutputInput (Figura 3.17). Objetos desta classe são criados

no momento da execução de vérticesChamada, onde uma nova instância deste

public class Chamada extends Vertice {

private String nomeDaOperacao; private Expressao expressoes;

... }

public class Expr extends Vertice {

private Expressao expressoes;

}

Figura 3.15: Código parcial das classes Chamada eExpr.

public class Retorno extends Vertice {

private List<Variavel> listaDeVariaveis;

...

}

public class Variavel {

private String nome; private int hashcode; private int valor; }

Figura 3.16: Código parcial das classes Retornoe Variavel.

serviço. Objetos da classe OutputInput representam os buffers de entrada e saída utilizados pela máquina.

A classe Expressao (Figura 3.14) contém a árvore sintática das

expres-sões aritméticas e booleanas. Os atributos direita e esquerda do tipo Token

public class OutputInput {

private String operacao;

private Vertice verticeOrigem; private Vertice verticeDestino;

private List<Variavel> listaDeVariaveis;

...

}

Figura 3.17: Código parcial da classe OutputInput.

atributo operador é umenumeration que traz como constantes os operadores para uma expressão.

public class Expressao extends Token {

private Token direita; private Token esquerda; private Operador operador;

private List<Expressao> parametrosDeEntrada;

...

}

public enum Operador {

SOMA, MULT, SUB, DIV, MAIOR, MENOR, MAIORIGUAL, MENORIGUAL, AND, OR, NOT, IGUALIGUAL

}

Figura 3.18: Código parcial da classe Expressao e enum Operador.

A classeGrafoé responsável por construir a estrutura em grafos que será

executada pela máquina de redução. Um grafo é representado na forma de listas de adjacência. Dessa forma, a classeGrafotem como atributo uma lista

listas de vértices adjacentes. Uma lista para indicar as arestas de controle e outra para as arestas de dependência. Esta classe contém também uma série de métodos para construir o grafo.

public class Grafo extends Token{

private List<Vertice> listaDeVertices;

/* S(E, X) */

public Grafo(Token servico, Token expr, Token variavel){ ...

}

... }

Figura 3.19: Código parcial da classe Grafo.

A classeMaquinaimplementa as regras de redução de grafos definidas na

seção 3.4. A partir da estrutura fornecida pela classeGrafo, o métodorunda

classe Maquinaé responsável pelo processo de executar o grafo. Este método

escolhe um vértice pronto para ser avaliado, ou seja, um vértice com os atribu-tosinDegreeControle (número de arestas de controle chegando ao vértice) e

inDegreeDependencia (número de arestas de dependência chegando ao

vér-tice) zero. De acordo com o tipo de vértice escolhido para a redução, uma sequência de ações, as quais estão em conformidade com as regras descritas na seção 3.4, são executadas. Ao final da execução de cada vértice, o método

runé chamado novamente até que não existam mais vértices que possam ser

executados.

Na figura 3.20, é possível ver de maneira sucinta a classeMaquinana qual

o atributo todosOsVertices contém os vértices que formam a estrutura em

serem executados. A lista de objetos OutputInput é preenchida a cada

exe-cução de um vértice Chamada. As variáveis atribuídas por vértices Retorno

são adicionadas a uma lista de variáveis a qual chama-se ambiente.

public class Maquina extends Token{

private List<Vertice> todosOsVertices; private List<Vertice> minimals;

private List<OutputInput> listaDeOutIn; private List<Variavel> ambiente;

private Set<Vertice> listaDeDeUnfolds;

private Map<Vertice, Vertice> parOriginalCopia;

private void run() { }

private void executar(Vertice vertice) { }

private void atualizarMinimals() { }

...

}

Figura 3.20: Código parcial da classe Maquina.

Por fim, os atributos listaDeUnfolds e parOriginalCopia são listas

utilizadas para a avaliação de vértices Mu. Para evitar que mais de uma

cópia de todo o corpo do Mu seja feita para um mesmo Unfold, no

mo-mento da execução, cada vértice Unfold atingível a partir das arestas de

controle de um vérticeMuque não seja atingível por outroMu é adicionado ao

Set<Vertice> listaDeDeUnfolds (Note que este tipo de coleção não

per-mite duas entradas com o mesmo valor). E, o Map<Vertice, Vertice>

parOriginalCopia guarda os pares de vértices (original, cópia) criados no

momento da cópia dos vértices que fazem parte do corpo de um Mu. Isto

Prova de Conceito

Com o intuito de validar a máquina de redução de grafos para a orquestração de serviços web construída, um programa exemplo foi definido. Este exemplo apresenta grande parte dos construtores da variante da linguagem PEWS especificada na seção 3.2.

O programa proposto é um sistema de monitoramento climático. Este, sob determinadas condições, deverá emitir alertas no Twitter. O sistema deve monitorar a temperatura de uma certa região, definida e fixa, através da medição e cálculo da média de temperatura de três cidades distintas. Esta medição é realizada periodicamente a cadak segundos definido previamente. Ao mesmo tempo, cada vez que a média estiver fora de um intervalo (por exemplo, entre 10 e 30 graus), o sistema deve emitir um alerta.

Para construir este sistema, quatro serviços foram implementados: Storage,

Delay, Weather e Twitter. Storage é um serviço que permite armazenar,

recuperar e atualizar uma variável (que representa a média das temperatu-ras). Ele possui três operações: initVar (String nome) que inicia uma

variável com o nome que é passado como parâmetro e retorna o identifica-dor desta variável; load(int identificador) que retorna o valor

armaze-nado na variável com o identificador passado como parâmetro; estore (int

identificador, int valorMedia) que atualiza o valor da variável

(refe-rente ao identificador) com o novo valor passado como parâmetro.

O serviço Delay é o serviço responsável por definir o período de tempo

o qual a aplicação ficará esperando até a próxima medição de temperatura. Este serviço possui somente uma operação, wait (int segundos), que faz com que o programa espere o tempo (em segundos) passado como parâmetro.

Weatheré o serviço que retorna a temperatura de uma cidade. Este

ser-viço é formado por uma operação, getTemp(String cidade), que retorna o

valor da temperatura para a cidade passada como parâmetro. Esta opera-ção se comunica a outro serviço externo, GlobalWeather1

, para recuperar a informação de todo o clima da cidade e filtrar somente a temperatura.

Por último, o serviçoTwitter2

realiza o envio de um alerta para um perfil (configurado previamente) no Twitter. Este serviço possui uma operação,

tweet(String alerta), que atualiza o status deste perfil com a mensagem

de alerta passada como parâmetro.

A orquestração de serviços (Conferir figura 4.13

) implementa este sistema de monitoramento.

A execução deste exemplo na máquina construiu um grafo com 29 vértices

1

http://www.webservicex.net/globalweather.asmx?WSDL

2

Para a implementação do serviço Twitter_{, a biblioteca Twitter4J foi}

utili-zada. Informações a respeito desta biblioteca podem ser encontradas no site: http://twitter4j.org/en/index.html.

3

initVar(Media, id); (unfolding(

(getTemp(Natal, X) || getTemp(Fortaleza, Y) || getTemp(Recife, Z)); store(id; (X+Y+Z)/3, s1);

wait(1, w1); unfold ) )|| (unfolding( load(id, M);

(IF [(M < 10) or (M > 30)]

([M < 10] tweet("Alerta: Low temperature", t1) + [M > 30] tweet("Alerta: High temperature", t2)); wait(2, w2);

unfold ) ) )

Figura 4.1: Exemplo de programa PEWS que implementa o sistema de mo-nitoramento.

de acordo com as regras de tradução apresentadas na seção 3.2 (contagem estática após a tradução).

As dependências entre vértices foram criadas corretamente. Por exem-plo, para a operação load (id, M) dois vértices foram criados: um do tipo

Chamada, que invoca a operação load passando como parâmetro a variável id; e outro do tipo Retorno, que armazenará o resultado da execução

da-quele vértice (Chamada) na variável M. Esta variável id somente é resolvida

pelo vértice Retorno criado para a operação initVar (Media, id). Isto

implica a execução do vértice RetornodeinitVarprioritariamente antes da

execução do vérticeChamadadeload. Isto garantiu que cada passo durante a

Como a orquestração para este sistema está baseada em iterações, de-finidas pelos construtores unfolding, que se repetem a cada certo período

de tempo (definido previamente) se torna impossível quantificar o número de reduções realizadas para esta orquestração. Todavia, analisando-se so-mente uma iteração realizada verifica-se que foram executadas 17 reduções assim como esperado. Note também que esse número de reduções pode variar dependendo das condições estabelecidas para o segundo unfolding.

A aplicação desta prova de conceito mostrou também que as regras de redução implementadas estão em acordo com as regras apresentadas na seção 3.4 e, mais importante, destacou pontos sutis nestas regras. Por exemplo, considere este trecho do código da orquestração para ilustrar:

[M < 10] tweet("Alerta: Low temperature", t1) +

[M > 30] tweet("Alerta: High temperature", t2);

wait(2, w2);

A figura 4.2 (Lado esquerdo) apresenta uma versão compacta do grafo construído para o trecho de código acima. Note que, devido à execução em sequência com o vértice wait, para cada vértice criado para a escolha não-determinística uma aresta de controle em sentido ao vértice wait é inserida. Considerando que a expressão verdadeira é M < 10, é importante que no

Figura 4.2: Exemplo compacto da redução de uma escolha.

grafo após a redução. Esta relação de pertinência entre o vértice + e seus vértices filhos originais é criada no momento da tradução onde guarda-se nos vértices filhos o identificador do seu pai (+). Uma situação parecida acontece com o vérticeMu(que representa o unfolding) uma vez que os vértices filhos

originais deste devem conter o identificador do pai (Mu) para evitar que no

momento da sua execução somente os vértices filhos originais sejam copiados para o unfold.

Afim de avaliar os resultados obtidos com a implementação, alguns pa-râmetros estáticos e dinâmicos foram analisados para o programa gerado. Estes parâmetros são:

• Linhas de código (LDC) representam o número de linhas de código no programa gerado;

• Quantidade de métodos criados (QMC) é o número de métodos criados no programa gerado;