Detecção e recuperação de falhas para a máquina de redução de grafos PEWS-AM

!" #$ %

) *+

*+

*

%

,- '

%

%

%

& '

. '/

$ 0 %

#1

,) 2 3 '#,

4 # 2 5678

*+

José Sueney de Lima

Detecção e Recuperação de Falhas para a Máquina de

Redução de Grafos PEWS-AM

Dissertação de Mestrado apresentada ao Pro-grama de Pós-Graduação em Sistemas e Computação do Departamento de Informá-tica e MatemáInformá-tica Aplicada da Universidade Federal do Rio Grande do Norte, como requi-sito para a obtenção do grau de Mestre em Ciências da Computação

Universidade Federal do Rio Grande do Norte Ű UFRN

Centro de Ciências Exatas e da Terra Ű CCET

Departamento de Informática e Matemática Aplicada Ű DIMAp

Programa de Pós-graduação em Sistemas de Computação Ű PPgSC

Orientador: Umberto Souza da Costa

Dissertação de Mestrado sob o título Detecção e Recuperação de Falhas para a Máquina de Redução de Grafos PEWS-AM apresentada por José Sueney de Lima e aceita pelo 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, sendo aprovada por todos os membros da banca examinadora abaixo especiĄcada:

_____________________________

Umberto Souza da Costa - Doutor

Presidente

DIMAp Ű Departamento de Informática e Matemática Aplicada UFRN Ű Universidade Federal do Rio Grande do Norte

_____________________________

Martin Alejandro Musicante - Doutor

Examinador

DIMAp Ű Departamento de Informática e Matemática Aplicada UFRN Ű Universidade Federal do Rio Grande do Norte

_____________________________

Regina Maria Motz Carrano - Doutora

Examinador

URep Ű Universidad de la República

Agradecimentos

Resumo

Serviços Web são unidades de software que permitem o acesso a um ou mais recursos, dando suporte à implantação de processos de negócios na Web. Eles permitem a inte-ração através de interfaces bem-deĄnidas, utilizando-se de protocolos padrões da Web, tornando possível a comunicação entre entidades implementadas em diferentes tipos de plataformas. Em virtude dessas características, Serviços Web podem ser integrados com o objetivo de formar aplicações mais robustas, com baixo acoplamento entre serviços, através de composições. Serviços Web estão sujeitos a falhas, situações indesejadas que podem comprometer o processo de negócio parcialmente ou mesmo totalmente. Falhas podem ocorrer tanto na concepção de composições quanto na execução das mesmas. Em virtude disso, é essencial a criação de mecanismos que tornem a execução das composições de serviços mais robusta e tratem falhas. EspeciĄcamente, propomos o suporte à recupe-ração de falhas em composições de serviços descritas na linguagem PEWS e executadas sobre PEWS-AM, uma implementação criada a partir da noção de grafos. Para o suporte à recuperação de falhas em PEWS-AM, estendemos as especiĄcações PEWS e adapta-mos as regras de tradução e redução de grafos desta máquina. Estas contribuições foram realizadas tanto no modelo da máquina abstrata quanto no nível da implementação.

Abstract

Web services are software units that allow access to one or more resources, supporting the deployment of business processes in the Web. They use well-deĄned interfaces, using web standard protocols, making possible the communication between entities implemented on diferent platforms. Due to these features, Web services can be integrated as services compositions to form more robust loose coupling applications. Web services are subject to failures, unwanted situations that may compromise the business process partially or completely. Failures can occur both in the design of compositions as in the execution of compositions. As a result, it is essential to create mechanisms to make the implementation of service compositions more robust and to treat failures. SpeciĄcally, we propose the sup-port for fault recovery in service compositions described in PEWS language and executed on PEWS-AM, an graph reduction machine. To support recovery failure on PEWS-AM, we extend the PEWS language speciĄcation and adapted the rules of translation and reduction of graphs for this machine. These contributions were made both in the model of abstract machine as at the implementation level.

Lista de ilustrações

Figura 1 Ű Padrão de Interação entre entidades da arquitetura de Serviços Web . . 22

Figura 2 Ű Pilha de protocolos de Serviços Web [20] . . . 23

Figura 3 Ű Tradução da operação S( ¯I,O¯) para grafos . . . 38

Figura 4 Ű Tradução da operação P1|| P2 para grafos . . . 39

Figura 5 Ű Tradução da operação P1;P2 para grafos . . . 40

Figura 6 Ű Tradução de uma escolha não-determinística para grafos . . . 41

Figura 7 Ű Tradução de uma estrutura condicional simples para grafos . . . 41

Figura 8 Ű Tradução de uma estrutura de repetição para grafos . . . 42

Figura 9 Ű Transformação de entrada e saída de serviços . . . 44

Figura 10 Ű Transformação de uma escolha não-determinística . . . 46

Figura 11 Ű Transformação de uma estrutura de repetição . . . 46

Figura 12 Ű Demonstração do uso do Retry . . . 49

Figura 13 Ű Demonstração do uso do Rebinding . . . 54

Figura 14 Ű Rebinding - Geração de Vértices e Arestas . . . 55

Figura 15 Ű Rebinding - Diminuição do número de vértices . . . 56

Figura 16 Ű Rebinding - Diminuição do número de arestas . . . 56

Figura 17 Ű Demonstração do uso do Restructure . . . 60

Figura 18 Ű Exemplo de composição de serviços com caminhos alternativos . . . 62

Figura 19 Ű Aplicação do Restructure . . . 63

Figura 20 Ű Classes TInt e TString . . . 68

Figura 21 Ű Hierarquia de classes do pacote pews.grafos . . . 70

Figura 22 Ű a) Formação do grafo sem o Sync; b) Formação do grafo com o Sync; . 72 Figura 23 Ű Hierarquia de classes do pacote pews.grafos na Máquina Estendida . . 73

Figura 24 Ű Exemplo de Ąnal de subcomposição . . . 77

Figura 25 Ű Exemplo aninhamento de blocos . . . 80

Figura 26 Ű Exemplo de saída do arquivo texto com aninhamento de + . . . 81

Figura 27 Ű Forma de Impressão dos vértices . . . 86

Figura 28 Ű Figuras geradas pela execução de uma composição. . . 88

Figura 29 Ű Lista de operações dos Serviços Web . . . 90

Figura 30 Ű Resposta gerada pelo Serviço RespostaUsuarioFigura . . . 90

Figura 31 Ű Geração da imagem da composição pelo GraphViz . . . 92

Figura 32 Ű Exemplo de entrada e saída de um código no GraphViz . . . 113

Figura 33 Ű Exemplo de inserção de atributos para vértices e arestas . . . 114

Figura 34 Ű Exemplo de ligação entre vértices normais e vértices de clusters . . . . 115

Sumário

1 INTRODUÇÃO . . . 17

1.1 Objetivos e Contribuições . . . 18

1.2 Estrutura do Documento . . . 19

2 FUNDAMENTAÇÃO TEÓRICA . . . 21

2.1 Service-Oriented Computing . . . 21

2.1.1 Conceitos Básicos . . . 21

2.1.2 Pilha de Protocolos . . . 22

2.2 Falhas em Serviços Web . . . 26

2.2.1 ClassiĄcação de Falhas . . . 26

2.2.2 Recuperação de Falhas . . . 27

2.3 PEWS . . . 33

2.3.1 A Linguagem de Composição . . . 33

2.3.2 Máquina de Redução de Grafos. . . 36

2.3.2.1 Regras de Tradução . . . 37

2.3.2.2 Regras de Redução . . . 42

3 RECUPERAÇÃO DE FALHAS EM PEWS-AM . . . 47

3.1 ClassiĄcação de Falhas . . . 47

3.2 Reinvocação do Serviço . . . 48

3.2.1 Alterações para suporte ao Retry. . . 49

3.2.2 Alterações na Máquina de Redução de Grafos . . . 50

3.3 Substituição do Serviço . . . 53

3.3.1 Alterações da gramática para o suporte ao Rebinding . . . 54

3.3.2 Alterações da Máquina de Redução de Grafos . . . 55

3.4 Reorganização do Processo . . . 60

3.4.1 Alterações da gramática para o suporte ao Restructure . . . 61

3.4.2 Alterações na Máquina de Redução de Grafos . . . 62

4 IMPLEMENTAÇÃO . . . 67

4.1 A Máquina de Redução Original . . . 67

4.2 A Máquina de Redução Estendida . . . 71

4.3 Otimizações realizadas . . . 78

4.3.1 Geração de um arquivo texto . . . 79

4.3.2 Correção na redução de vértices de blocos . . . 79

4.3.3 Inserção do tipo STRING . . . 81

5 EXPERIMENTAÇÃO . . . 89

5.1 Descrição do Estudo de Caso . . . 89

5.2 EspeciĄcação da Composição em PEWS . . . 90

5.3 Casos de Teste . . . 92

5.4 Resultados obtidos. . . 94

5.4.1 Caso 1 . . . 94

5.4.2 Caso 2 . . . 95

5.4.3 Caso 3 . . . 96

5.4.4 Caso 4 . . . 99

5.5 Conclusão dos Experimentos . . . 100

6 CONCLUSÃO . . . 103

Referências . . . 107

APÊNDICE A Ű Código do arquivo Pews.jacc . . . 111

APÊNDICE B Ű Uso do GraphViz em PEWS-AM . . . 113

APÊNDICE C Ű Atributos e métodos das classes da Máquina Es-tendida PEWS-AM . . . 117

17

1 INTRODUÇÃO

Nos dias atuais, a infraestrutura oferecida pela Web faz com que muitas organi-zações a adotem como meio para publicar seus serviços, com o objetivo de dar suporte a seus processos de negócio. Elas buscam velocidade de desenvolvimento, interoperabili-dade, escalabiliinteroperabili-dade, reuso e facilidade de acesso. Estes princípios deĄnem o paradigma SOC (Service-Oriented Computing) [26]. A unidade básica em SOC são os serviços, que representam aplicações fornecidas pelos provedores e permitem a composição de processos de negócio pela descoberta e invocação através da rede. Serviços podem ter suas fucionali-dades integradas, formando aplicações através de composições de serviços. SOC possibilita a construção de aplicações robustas e o suporte à heterogeneidade dos serviços, uma vez que a comunicação entre eles independe da plataforma ou tecnologia nas quais estes foram construídos.

Serviços Web são a mais promissora implementação de SOC [20], sendo estes uni-dades de software que fornecem um conjunto de operações através de interfaces bem deĄnidas, sendo acessíveis através de protocolos padrões da Web. Serviços Web têm por objetivo permitir a interoperabilidade e ter uma representação uniforme entre os serviços presentes na Web. O modelo de Serviços Web propõe o suporte a interações de forma sistemática e utiliza-se de modelos de infra-estrutura existente [10].

Um dos grandes desaĄos na utilização dos Serviços Web é a integração de métodos de gerenciamento para suporte a falhas [37]. Aplicações devem garantir a conĄabilidade na execução, devendo apresentar mecanismos que garantam a eĄcácia do processo de negócio e possíveis soluções para ocorrência de falhas. O tratamento dessas falhas não é algo trivial, visto o ambiente dinâmico em que são implantados os serviços. A dinamicidade dos Serviços Web faz com que eles possam trabalhar durante intervalos de tempo longos ou simplesmente tornem-se indisponíveis. Falhas podem ocorrer em diversos momentos da execução de uma composição, tornando inviável a adoção de ações humanas para detecção e tratamento. Diversos são os motivos que podem causar uma falha em um determinado Serviço Web, como queda no serviço, passagem de dados errônea, entre outros. Portanto, são necessários meios providos pelo designer de uma composição de serviços que garantam a conĄabilidade e a segurança do processo.

reconexão com o mesmo serviço em caso de falha ou troca deste por um outro equivalente; criação de execuções alternativas para substituir trechos da composição que contém falhas, entre outros. A maioria das abordagens criam modelos teóricos de tratamento de falhas, sem a especiĄcação de protótipos. Uma das vantagens do nosso trabalho é a adoção e aplicação de uma abordagem num protótipo real de um sistema de execução de Serviços Web.

1.1 Objetivos e Contribuições

Propomos neste trabalho a implementação de mecanismos de recuperação de fa-lhas, implementados como uma extensão de um sistema de execução de composições de serviços, especiĄcadas na linguagem de composições PEWS. O sistema de execução des-crito corresponde a uma máquina de redução de grafos, chamada PEWS-AM [8]. Na versão estendida da máquina de redução de grafos, o designer da composição pode optar pela execução da máquina no formato antigo (sem recuperação de falhas) ou utilizá-la com os mecanismos implementados. Sendo este o objetivo principal, utilizaremos a seguinte metodologia:

1. Extensão da linguagem PEWS para a especiĄcação dos métodos de recuperação de falhas;

2. Implementação dos mecanismos de recuperação de falhas na máquina de redução PEWS-AM, permitindo a futura inserção de outros mecanismos de detecção e re-cuperação;

3. Integração da máquina de redução de grafos com o Graphiz [13], um software de vizualização de grafos abstratos, capaz de representar informações estruturadas, a Ąm de gerar uma representação gráĄca da execução das composições de serviços;

4. Revisão bibliográĄca sobre as abordagens utilizadas para o tratamento de falhas em Serviços Web por diversos trabalhos;

1.2. Estrutura do Documento 19

1.2 Estrutura do Documento

21

2 FUNDAMENTAÇÃO TEÓRICA

Neste capítulo, apresentaremos a fundamentação do nosso trabalho. Na primeira parte, faremos uma revisão sobre a Computação Orientada a Serviços, mostrando os principais conceitos relacionados a esse paradigma. Em seguida, apresentaremos o conceito de falhas e as classiĄcações comumente encontradas na literatura no contexto de Serviços Web. Por Ąm, apresentaremos a linguagem de composição PEWS e suas características principais. Abordaremos, também, as máquinas de redução de grafos, dando ênfase à máquina de redução PEWS-AM.

2.1 Service-Oriented Computing

A Computação Orientada a Serviços (do inglêsService Oriented Computing) pro-põe o desenvolvimento de aplicações massivamente distribuídas, interoperáveis e de baixo custo. Ela traz como vantagens o fraco acoplamento entre serviços, desenvolvimento base-ado em padrões, integração de aplicações, disponibilização de recursos sem a necessidade do conhecimento da implementação do serviço, entre outras [25]. Segundo este paradigma, as aplicações podem ser desenvolvidas utilizando unidades de software de diferentes pro-vedores, potencialmente executadas sobre plataformas heterogêneas.

2.1.1

Conceitos Básicos

Para que existam formas de consolidar as pesquisas e esforços atuais em SOC, é necessário o conhecimento sobre alguns dos principais pontos deste paradigma [27]: fundamentos, composições de serviços, gestão e monitoramento de serviços.

A entidade básica do paradigma SOC é o serviço. Este é um módulo de software implantando em plataformas de redes acessíveis pela Web, que pode ser invocado através da rede. Eles podem desempenhar funções que vão desde responder pedidos simples a executar processos de negócio soĄsticados, sendo autônomos e de baixo acoplamento [27]. Os Serviços Web são módulos de software que possuem interfaces que descrevem uma coleção de operações [20] e permitem implantar e dar acesso a funções de negócio através da Web, sendo a implementação mais bem sucedida de SOC.

intera-ção entre o provedor e o utilizador de um serviço pode ser intermediada por um registro de serviços. A Figura 1 apresenta o diagrama de interação entre estas três entidades.

Figura 1 Ű Padrão de Interação entre entidades da arquitetura de Serviços Web

O provedor de serviço é a entidade que disponibiliza o Serviço na Web, ou seja, o proprietário responsável pela descrição do serviço. O solicitante de serviço é o usuário que deseja utilizar determinado serviço presente na rede, ou seja, a entidade que deseja invocar um serviço e iniciar uma interação. Já oregistro de serviçosé um repositório que é usado para pesquisa de serviços, onde provedores publicam as descrições de seus serviços e solicitantes fazem uma busca para obter informações disponíveis no registro (descrição e informações de comunicação). O registro de serviços não é uma entidade obrigatória na arquitetura, visto que solicitantes podem já conhecer todas as informações referentes ao provedor, não necessitando da consulta ao registro para conseguir o vínculo.

As operações de interação entre as três entidades citadas acima são: publish, rea-lizada entre o provedor e o registro, onde o primeiro publica informações do seu serviço em um determinado repositório, sendo o UDDI [23] o tipo de diretório de serviços mais utilizado; discovey, que é realizada entre o requisitante e o registro, onde o primeiro faz uma busca pelas descrições dos serviços no registro através de sua descrição WSDL [23]; e binding, realizada entre um solicitante e um provedor, onde o primeiro solicita o vín-culo com o serviço para o acesso às suas funcionalidades, sendo SOAP [23] o protocolo característico dessa operação.

Segundo [20], o ciclo de vida dos Serviços Web é constituído pelas seguintes fases: construção, que inclui o desenvolvimento e teste, além da deĄnição da interface e da implementação do serviço;implantação, que inclui a publicação do serviço em um ambiente de execução; início, fase responsável pela ocorrência da disponibilidade para operações de vínculo, estando já totalmente implantado e operacional; e gerenciamento, que inclui a administração do aplicativo de Serviço Web, cobrindo características como: segurança, disponibilidade, desempenho, etc.

2.1.2

Pilha de Protocolos

2.1. Service-Oriented Computing 23

estruturada em camadas, onde as camadas mais baixas dão suporte às camadas superi-ores. Numa visão geral sobre a arquitetura de Serviços Web, podemos observar a pilha conceitual [20] e os detalhes existentes em sua estrutura de acordo com a Ągura 2.

Figura 2 Ű Pilha de protocolos de Serviços Web [20]

Camada de Rede

Serviços precisam ser disponibilizados na rede para que possam ser invocados por seus solicitantes, e esta funcionalidade é dada pela primeira camada da pilha de protoco-los (rede). O protocolo HTTP (Hypertext Transfer Protocol) [11] é o mais utilizado para essa comunicação. Podem ser utilizados critérios (desempenho, disponibilidade, etc.) para escolher a tecnologia, permitindo que os Serviços Web aproveitem a infra-estrutura exis-tente de alto nível de redes, sendo isso transparente ao desenvolvedor do serviço. Outros protocolos podem ser utilizados no nível de rede, com o FTP (File Transfer Protocol) [30], SMTP (Simple Mail Transfer Protocol) [29], entre outros, em virtude de que a escolha do protocolo dependerá de requisitos da aplicação.

Camada de Mensagens

A camada de mensagens é responsável por fornecer meios para troca de mensagens através da linguagem XML e do protocolo SOAP [6], sendo o mesmo simples, padronizado para documentos em mensagens XML, e por dar suporte a operações feitas entre as entidades dos Serviços Web, além da troca de mensagens em ambientes distribuídos. Segundo [20], SOAP pode ser usado em combinação com uma variedade de protocolos de rede (HTTP, SMTP, FTP, etc).

Descrição de Serviços

a chave para tornar a arquitetura de Serviços Web de baixo acoplamento, reduzindo a quantidade de compartilhamento necessário e a programação personalizada. A descrição do serviço, combinada com a infra-estrutura SOAP, encapsula detalhes da comunicação entre o solicitante e o provedor de serviço [20].

Segundo [10], WSDL e SOAP são a base dos Serviços Web, pois resolvem os problemas básicos subjacentes ao desenvolvimento dos mesmos; dessa forma, podemos concluir que as três primeiras camadas garantem um nível de operabilidade básico para os Serviços Web.

Publicação de Serviços

A camada de publicação de serviços é responsável por tornar um serviço visível na rede. Uma descrição de serviço pode ser publicada usando uma variedade de mecanismos. Um deles é a publicação direta, onde o provedor de serviços envia a descrição do serviço diretamente ao solicitante do serviço, ocorrendo após dois parceiros de negócios concor-darem com os termos de realização de negócios eletrônicos através da Web. Outra forma é apublicação dinâmica, onde os documentos WSDL são enviados para um repositório e podem ser recuperados pelos solicitantes.

A principal tecnologia utilizada é o UDDI (Universal Description, Discovery and Integration) [23], que permite localizar, descrever e registrar serviços, amplamente utili-zada no compartilhamento de informações pelos usuários.

Descoberta de Serviços

A camada de descoberta de serviço tem sua função dependente da camada ante-rior. Solicitantes de serviços podem encontrar Serviços Web durante duas fases diferentes do ciclo de vida de uma aplicação Űtempo de design etempo de execução. Qualquer meca-nismo que permita acesso à descrição do serviço, tornando-o disponível para o aplicativo em tempo de execução, pode ser considerado um método de descoberta. Bons mecanismos de descoberta precisam suportar consultas que encontrem interfaces através de vários pa-râmetros, como: tipo (com base num modelo WSDL), informações debinding(protocolos), taxonomia do serviço, informações de negócios, entre outros [20].

Composição de Serviços

Por Ąm, a camada de composição de serviço descreve como são realizadas as co-municações entre serviços. Nessa camada, existe uma variedade de linguagens que podem ser usadas para descrever a interação entre serviços. Entre as linguagens de composição de serviços, destacamosWSCI(Web Service Choreography Interface) [3],BPML(Bussiness Process Modeling Language) [33], BPEL (Bussiness Process Execution Language) [18] e

2.1. Service-Oriented Computing 25

apresentada em detalhes em uma próxima seção deste capítulo, dada sua importância no contexto do trabalho proposto.

Serviços Web podem ser combinados em processos de alto nível através das com-posições de serviços. Nesse sentido, é necessário que haja um tipo de interação entre os serviços para que eles realizem o processo de negócio. Os dois padrões de interação mais utilizados atualmente são os padrões de orquestração e coreograĄa de serviços. A orquestração é um tipo de modelagem de composição de serviços em que existe um pro-cesso central que comanda todas as ações de comunicação, sendo chamado de propro-cesso de negócio executável (orquestrador) [28]. O processo central é responsável por comandar toda a lógica de negócio e a ordem de execução das tarefas. As orquestrações devem ser dinâmicas, Ćexíveis e adaptáveis, a Ąm de atender à lógica de negócios.

Por outro lado, a coreograĄa é uma modelagem que descreve uma colaboração entre uma coleção de serviços com um objetivo comum, acompanhando tipicamente sequências de mensagens que ocorrem entre os Serviços Web, sendo um processo mais colaborativo [28]. Em uma coreograĄa, não há um processo central que controle toda a lógica de negócio, ou seja, é um tipo de interação distribuída e descentralizada, onde cada serviço sabe como agir na ocorrência de determinados eventos, pois o conhecimento é espalhado pelo sistema. CoreograĄas também são chamadas de processos de negócios abstratos.

Camadas Transversais

Existem três camadas transversais presentes na pilha de Serviços Web: Qualidade de Serviço, Gerenciamento e Segurança. Essas características devem estar presentes em todas as camadas horizontais, desde a camada de rede até a camada de Ćuxo de serviços, em virtude das necessidades impostas pela adaptação dos Serviços Web na integração com a internet [1]. A qualidade de serviço se preocupa com a forma como o serviço é provido ao solicitante, buscando, através da veriĄcação de requisitos não-funcionais, responder às necessidades dos clientes. Alguns desses requisitos são: acessibilidade, desempenho, dis-ponibilidade e custo. A segurança desperta uma atenção especial, principalmente quando relacionada a um meio tão dinâmico quanto a Web. É necessário garantir a integridade e privacidade das mensagens enviadas, bem como a autenticidade das transações realizadas entre solicitantes e provedores.

possibilitando escolher os melhores provedores de serviços).

2.2 Falhas em Serviços Web

Serviços Web apresentam-se hoje como uma solução para suprir as necessidades de processos de negócio via Web. Uma das causas da atratividade dos Serviços Web é a sua dinamicidade, entretanto, este é um fato que também pode gerar a ocorrência de falhas. Falhas são manifestações que se originam de um ou mais erros e fazem com que um serviço apresente um comportamento diferente do padrão esperado [21]. Em Serviços Web, falhas podem ocorrer em diversas fases do desenvolvimento de aplicações, desde o design até o tempo de execução. Considerando a pilha de protocolos, falhas podem se originar desde a camada de rede até a camada de composição de serviços.

2.2.1

Classificação de Falhas

Em [32], é feita uma revisão sobre os motivos de falhas em composições de Servi-ços Web, divididas em duas categorias, relacionadas a serviServi-ços:falhas funcionais e falhas não-funcionais. As falhas funcionais envolvem problemas como mal funcionamento do serviço (erros ocorridos no próprio serviço, ou seja, devido ao seu processamento interno errôneo), indisponibilidade do serviço, problemas de compatibilidade de software (forma-tos de entrada e saídas diferentes), mudança de contex(forma-tos (mudança de dispositivo de acesso, por exemplo), etc. As falhas não-funcionais são causadas portime-outs de respos-tas, atraso da rede, entradas e tipos de dados inesperados, etc. Já em [37], uma outra classiĄcação é dada a falhas ocorridas em Serviços Web, onde as mesmas são divididas em oito categorias. Apesar de existirem mais categorizações de falhas, utilizaremos a classi-Ącação apresentada neste último trabalho como principal referencial nesta proposta, por julgar sua abordagem mais especiĄca. A seguir, apresentamos um resumo das categorias de falhas consideradas em [37]:

• Disponibilidade Ű Usuários podem encontrar falhas na conexão com o serviço.

2.2. Falhas em Serviços Web 27

• Concorrência Ű Serviços disponíveis para acessos na rede podem ter diferentes

níveis de escalabilidade. Um serviço pode ser utilizado por mais de um cliente, em qualquer momento, e isto pode causar problemas de simultaneidade. Outro tipo de cenário é quando um serviço é usado como um recurso que precisa ser adquirido.

• DependênciaŰ Serviços atômicos são independentes de outros serviços, entretanto,

ao serem colocados para trabalhar em conjunto em uma composição, criam uma relação de dependência em relação ao processo de negócio. Isso torna a execução de determinados serviços dependentes, por exemplo, da saída de outros serviços. Esse fato pode gerar problemas já na formação da composição, quando, por exemplo, um designer não faz uma análise detalhada das entradas e saídas dos serviços, ligando serviços que possuem tipos incompatíveis. Isso pode tornar a composição inoperável, ou até mesmo errônea, no caso em que isso não seja detectado e o serviço realize o processamento com os dados errados;

• Inconsistência Ű Um provedor de serviços pode decidir alterar os descritores de

alguns dos seus serviços. Essas mudanças podem afetar a forma de acesso. Se o descritor é alterado durante o tempo de execução, um cliente que já está usando o serviço pode obter resultados inesperados devido ao novo descritor. Essa alteração também pode fazer um serviço se comportar de forma diferente do que é proposto a fazer;

• Composição Ű Esse tipo de falha pode ocorrer no design da composição. Durante a concepção de uma composição, serviços que oferecem informações incompatíveis entre si são forçados a trabalhar juntos;

• ParciaisŰ Esse tipo de falha pode ocorrer quando, por exemplo, durante a execução paralela de vários serviços, cuja sincronização é feita no Ąnal da execução destes, um dos serviços não responde, sendo que a composição é feita de forma a considerar, após determinado tempo, apenas as respostas dos serviços Ąnalizados. Apesar da composição ter sido Ąnalizada, os dados recebidos estão incompletos, o que pode gerar falhas na intepretação dos dados;

• Outras falhas Ű Essa última categoria engloba outras falhas que não podem ser categorizadas com a classiĄcação acima. Podemos citar: falhas de QoS (tempo de resposta alto, custo alto, etc.) , falhas de não-cumprimento de contrato de servi-ços (serviservi-ços desrespeitam restrições que estavam designadas no contrato entre o requisitante e o provedor), etc;

2.2.2

Recuperação de Falhas

execução a um estado de correção anterior à ocorrência da falha, onde podemos citar os métodos transacionais [37]. Já o método forward tenta levar a execução para um estado seguro e conĄável a partir do ponto onde ocorreu o erro, onde encontramos as redes de auto-cura [39].

Métodos transacionais seguem a propriedade característica de transações, que é a propriedade ACID [37], cujas características são especiĄcadas abaixo:

• Atomicidade Ű Tem a idéia de indivisibilidade, ou seja, a execução é única, não

podendo ser dividida em partes;

• Consistência Ű A execução cumpre todas as regras invariantes do sistema sem a

violação das mesmas;

• Isolamento Ű A execução atual não interfere em outra execução;

• Durabilidade Ű Operações realizadas não podem ser desfeitas, mesmo quando há

falha depois da conĄrmação da execução;

Transações podem ser classiĄcadas comorasas ouaninhadas. Uma transação rasa é uma transação normal que irá ser concluída apenas quando o objetivo principal for atingido, seguindo estritamente as características ACID. Em composições de Serviços Web, seguir as características ACID não é uma tarefa fácil. Por exemplo, uma falha na execução pode comprometer o processo de negócio de forma que todo o processo anterior tenha que ser desfeito. Isso viola a característica da durabilidade, uma vez que esta não permite ŞdesfazerŤ operações. Em outro caso, considerando que o princípio da atomicidade refere-se à composição inteira, e não a um serviço individual, a execução só será válida se todos os serviços cumprirem suas tarefas. Por isso, astransações aninhadas podem obter melhores resultados no âmbito de Serviços Web. Elas tem a característica de dividir a transação completa (neste caso, a composição) em sub-transações. Neste caso, a atomicidade é relacionada com serviços presentes na composição, não estando a execução correta associada apenas ao término da execução da composição inteira. Apesar disso, de acordo com [39], abordagens transacionais não são adequadas para a composição de Serviços Web por duas razões principais:(i)gerenciar transações ao longo de um sistema distribuído não é uma tarefa fácil, e (ii) abordagens baseadas em transações geralmente envolvem bloqueio de recursos, não sendo viáveis em um ambiente de Serviços Web.

2.2. Falhas em Serviços Web 29

de detecção de falhas, que podem utilizar dois tipos de estratégias: detecção estática e detecção dinâmica de erros.

Na detecção estática, erros devem ser identiĄcados antes da execução. Em [24], é proposta uma análise automatizada que se utiliza de redes de Petri [22]. Entretanto, diversos erros não podem ser detectados usando essa estratégia, como erros de disponi-bilidade (não é possível prever se um serviço acionado na composição estará disponível durante a execução) e erros de QoS (serviços podem não cumprir o que foi prometido durante a fase de construção dos contratos). Já a estratégia de detecção dinâmica permite que falhas sejam detectadas durante a execução da composição. Uma proposta foi dada em [44], onde restrições de QoS foram usadas como forma de garantir a estabilidade ao compor Serviços Web. Entretanto, esta estratégia parece estar mais preocupada com a qualidade não-funcional do serviço, e não com a realização do Ćuxo de execução propria-mente. Observamos que as características das redes de auto-cura são mais adaptáveis no âmbito de Serviços Web do que os métodos transacionais.

Muitos trabalhos [35], [17], [41], [43], [44], [5] foram realizados para tentar lidar com a ocorrência de falhas sobre Serviços Web. Para um melhor entendimento deste trabalho, é importante que tenhamos um conhecimento prévio sobre o estado da arte de mecanismos de recuperação de falhas em Serviços Web. Uma breve revisão sobre os trabalhos realizados na área é mostrada a seguir.

Em [35], é realizada uma melhoria em um framework que se propõe a tratar da recuperação de falhas de negócios através do monitoramento das orquestrações expressas em BPEL [18]. Os desenvolvedores Ącam responsáveis por criar as orquestrações em BPEL, dar um conjunto de pré e pós-condições para invocações de serviços (contratos de serviços), e especiĄcar um conjunto de propriedades de regularidade (invariantes representadas por interações requeridas e proibidas entre serviços). Um mecanismo de compensação é então acrescentado ao programa BPEL para a criação de planos de recuperação, um conjunto de passos para execução de novas atividades que dê ao sistema a possibilidade de tratar erros e retornar a um estado de processamento esperado pelo cliente.

No pré-processamento, o programa BPEL é enriquecido com as informações de compensação, criadas a partir dos contratos e das propriedades de regularidade. Quando a orquestração é executada, monitores de serviços são executados em paralelo com a apli-cação do usuário, onde estes monitores podem parar a execução da apliapli-cação caso detectem algum erro, vindo da violação dos contratos ou do não-cumprimento das propriedades de regularidade. A partir do atual estado de erro, são retornados planos de recuperação. No caso de haver mais de um plano possível de recuperação para um determinado estado, o framework dá a possibilidade do usuário escolher qual plano será utilizado de acordo com algum critério (por exemplo, o plano mais curto, o plano de menor custo, etc.).

um conjunto de módulos dedicados que fazem parte de umainterface de controle, garan-tindo o monitoramento do comportamento do Serviço Web, a captura e a recuperação de erros. Dois passos são identiĄcados nessa abordagem: (i) Modelagem do Serviço Web usando dois comportamentos, chamados comportamento operacional (ilustra a lógica de negócios que sustenta o funcionamento de um Serviço Web) e decomportamento de con-trole (expõe as ações a serem executadas, juntamente com as suas devidas restrições), e (ii) Monitoramento da execução de um Serviço Web usando a interface de controle que Ąca entre os dois comportamentos citados anteriormente. Os módulos presentes na inter-face de controle contemplaminterpretação, monitoramento, resolução eadaptação, sendo eles, respectivamente: MAM (Mapping Module), um repositório de dados e schemas XML que resulta do mapeamento entre os comportamentos de controle e operacional; CMM (Conversation Management Module), responsável por instanciar, gerenciar e veriĄcar as mensagens de conversação que são trocadas entre os dois comportamentos; ERM (Error Recovery Module), receptor de alertas de erros submetidos pelo CMM e também respon-sável por tomar ações de correção; e TMM (Transition Management Module), responsável por armazenar as transições dos comportamentos (transição de um estado para o ou-tro no mesmo comportamento) e informações sobre as operações de negócios (restrições, descrição funcional, implementação e execução).

Quando o ERM recebe um alerta, ele recupera o estado de execução do MAM, bem como os detalhes da mensagem de falha, indicando que existe um problema de execução reportado pelo CMM. Dessa forma, o CMM sincroniza com o MAM e o TMM para recuperar informações relacionadas ao cenário atual e as operações no estado de controle que são afetadas por este erro. O ERM consulta a sua base de padrões comparando a mensagem recebida com padrões ŞnormaisŤ e padrões ŞerrôneosŤ, de modo que o aspecto relacionado com este erro é detectado. Se o padrão já está no banco de dados, o ERM consulta sua base para ver se um erro semelhante já foi tratado e resolvido. Em caso aĄrmativo, o ERM envia uma solução para o CMM e TMM para implantação. Caso contrário, o ERM seleciona o aspecto associado. Em seguida, envia a solução para o módulo de TMM aplicá-lo. No caso em que o padrão de erro não exista, o ERM acrescenta esse novo padrão para a base de padrões e envia um alerta para o desenvolvedor do Serviço Web, pedindo a sua atribuição (novo padrão) a um ou muitos aspectos. Após a aplicação da solução, o ERM atualiza os seus casos bases.

2.2. Falhas em Serviços Web 31

recuperação de Serviços Web semânticos baseados em OWL-S. A ideia da abordagem é fornecer mecanismos que permitam ao designer descrever situações que possam levar a um estado errôneo. Dois tipos de restrições são deĄnidas: hard constraints (violações de restrições, ou seja, não-cumprimento de invariantes que podem afetar a eĄcácia do pro-cesso de negócio) e soft constraints (eventos que não necessariamente afetam a eĄcácia, mas necessitam ser tratados para o bom funcionamento do processo).

Para o tratamento desoft constraints, são usados os eventHandlers, entidades cri-adas para tratar determincri-adas ocorrências, sem a necessidade da terminação do processo que o gerou. Já para o tratamento de hard constraints, são criados osCV-handlers (mani-puladores de violação de restrição, do inglês constraint violation handlers), que associam violações de condições a ações de tratamento apropriadas, Ąnalizando o processo no qual a restrição foi desrespeitada. Um exemplo simples é mostrado abaixo [43]:

1. CompositeProcess(BuyItem)

2. CV-Handler(BuyItemStarted + 1min) { 3. compensate; retry(3);

4. }

5. }

Neste exemplo, um processoCompositeProcess tem um CV-handler que é dispa-rado quando uma determinada ação demora mais de um minuto a responder, a partir de sua chamada (BuyItemStarted + 1min). A partir daí, duas ações de recuperação podem ser tomadas (compensate() e retry(3)). O framework visa fornecer bases sólidas para uma rápida recuperação, tendo pretensões futuras de introduzir políticas de recuperação, capazes de fornecer regras genéricas que facilitam o processo de recuperação e também regras especíĄcas de contexto.

não-funcionais; um nível de provimento do serviço (l), que contém características das pro-priedadesdelay, custo ebenefício, representadas por e(s,l), c(s,l)eb(s,l); e uma restrição em relação ao delay total do processo (R). O primeiro algoritmo é usado na seguinte situação: no caso de haver um processo em execução, caminhos alternativos devem ser utilizados caso o caminho ótimo esteja indisponível. O segundo algoritmo é utilizado em outra situação: para novas instâncias de processos, os caminhos que levam a uma situação de falha devem ser retirados do grafo. Caso processos de negócios anteriores tenham sido executados e foram detectados caminhos que levavam a uma falha, esses caminhos devem ser excluídos.

Em [5], são propostas duas formas para recuperação de falhas em composição de Serviços Web, chamadas de DPD (Defensive Design Project) e SRTM (Service Run-Time Monitoring). DPD é uma estratégia que consiste em criar o Ćuxo do processo de tal modo a dar-lhe possibilidades de se recuperar de certos tipos de falhas que são muito comuns em tempo de execução. Determinadas falhas podem ser facilmente tratadas com o uso de um processo de design inteligente . A aplicação desta técnica por ser exempliĄcada com uma falha comum em sistemas dinâmicos: a ocorrência detime-outs. De acordo com o tipo de falha, podemos realizar um projeto de design que possar tomar diferentes atitudes:

• Quedas de serviços tendem, algumas vezes, a ser momentâneas. Se isso realmente aconteceu, uma nova solicitação pode ser tentada e a comunicação pode ser estabe-lecida entre o solicitante e o provedor;

• Mudanças de nome são difíceis de serem detectadas. Portanto, consideramos que o serviço não mais existe e podemos tentar a comunicação com outro serviço que possa participar da composição sem prejuízos ao solicitante.

Já SRTM utiliza um monitor externo, que deve ser capaz de veriĄcar o cum-primento das características funcionais e não-funcionais do contrato (especiĄcação dos deveres dos serviços na composição) estabelecido entre os solicitantes e os provedores. Os autores investigam como monitorar composições de serviços dinâmicos através dos con-tratos, e propõem duas implementações de monitoramento: a primeira oferece todos os recursos de uma linguagem de programação, onde é explorada uma linguagem orientada a objetos; a segunda está mais preocupada com com a especiĄcação e oferece constru-ções, a Ąm de especiĄcar asserções (dados ou informações tidas como verdadeiras). Três tipos de falhas são utilizadas como base para o estudo: time-outs, erros externos e vio-lação de contratos. Por Ąm, o método descreve três métodos que podem ser úteis para realização a recuperação de um sistema. Os três métodos propostos para recuperação de falhas são: Reinvocação de Serviços (Retry), Substituição de serviço (Rebinding)

2.3. PEWS 33

No Apêndice D deste documento, apresentamos uma tabela que contém um resumo sobre os trabalhos levantados e alguns critérios de diferenciação entre os mesmos. Apesar de serem parte da revisão bibliográĄca deste documento, os trabalhos [32] e [37] assumem um caráter mais classiĄcatório de falhas e suas características não se encaixam nos itens deĄnidos pela tabela. Dessa forma, os mesmos foram omitidos do apêndice.

2.3 PEWS

Interfaces de Serviços Web são geralmente escritas usando WSDL, que tem a ca-pacidade de especiĄcar serviços estaticamente. Entretanto, quando desejamos atribuir determinadas características a um conjunto de serviços (por exemplo, sequência de exe-cução, interações entre serviços, manipulação de dados entre serviços), necessitamos de outros formalismos que dêem suporte a esses fatores [4].

Em [4], foi proposta uma linguagem de composição de serviços baseada em Predi-cate Path Expressions [2], sendo a mesma denominada PEWS (Path Expression for Web Services). Esta linguagem pode complementar linguagens de descrição de interfaces de serviços (tais como WSDL), sendo usada não só na especiĄcação de Serviços Web sim-ples ou numa composição, mas também como uma linguagem de implementação deles [4]. Ainda segundo [4], PEWS serve como um guia para a implementação de um sistema e de todas as operações envolvidas no mesmo. As path expressions são usadas para res-tringir as sequências de operações e condições para a execução de operações de serviços através de uma especiĄcação simples. Segundo [2], o uso de predicados aumenta o ní-vel de expressividade, permitindo um maior controle de acesso ao objeto que está sendo manipulado.

2.3.1

A Linguagem de Composição

No contexto de PEWS, predicados são extensões que podem ser aplicadas a path expressions com o intuito de aumentar sua expressividade. Podemos ver o aumento no ní-vel de expressividade com o seguinte exemplo: usando apenaspath expressions, desejamos que um uma ação a ocorra zero ou mais vezes, sendo seguida de uma operação paralela simples entre b e c. Através do operador de sequência Ş.Ť, do operador de paralelismo Ş||Ť e do operador que indica zero ou mais vezes Ş∗Ť, podemos representar essa expressão da seguinte forma:

a∗ _{. (b || c)}

cseja executada, de acordo com a avaliação de um condiçãoP, onde sePretorna um valor true, b é executado, e se P retorna um valor false, c é executado. Vejamos o exemplo abaixo:

a∗ _{. ([P]b || [not P] c)}

Como vemos acima, houve um aumento na expressividade dapath expression com a extensão dada pelo uso de predicados, sendo esta a proposta de PEWS. A sintaxe PEWS é deĄnida pela seguinte gramática [4]:

(1) interface = JportType def∗ _pathK

(2) path = JopnameK | Jpath ‘.’ pathK | Jpath ‘+’ pathK Jpath ‘k’ pathK Jpath∗_{K J‘{’ path ‘}’K}

J‘[’ pred ‘]’ pathK

(3) pred = J ‘true’ K | J ‘false’ K | J ‘not’ pred K |

J pred boolOp predK | J arith-expr relOp arith-expr K

(4) def = J ‘def’ var ‘=’ arith-expr K

(5) portType = J operation+ K

(6) operation = J opname ‘(’ opArg ‘)’ K

(7) opArg = J‘in:’ msgName K | J ’out:‘ msgName K |

J‘in-out:’ msgName ‘,’ msgName K |

J‘out-in:’ msgName ‘,’ msgName K

(8) msgName = (9) opName =

-(10) arith-expr = JvarK | Jarith-expr arithOp arith-exprK | J‘now()’K J‘act (’ opname ‘).val’K | J ‘act (’ opname ‘).time’ K |

J ‘term (’ opname ‘).val’K | J‘term (’ opname ‘).time’K

(11) boolOp = (12) relOp = (13) arithOp = (14) var =

2.3. PEWS 35

dos mesmos pela lógica da gramática. Por exemplo, boolOp indica operadores booleanos, ou seja, operador de conjunção (and) e disjunção (or), enquanto arithOp representa os operadores aritméticos, ou seja, soma (+), subtração (-), e assim por diante.

Uma interface tem sua deĄnição como sendo um conjunto de uma ou mais opera-ções (portType), uma sequência de deĄnições (def), seguido de uma path expression (path). O elemento portType é o responsável por descrever uma ou mais interface de chamada de serviços, ou seja, os bindings de uma ou mais operações (representadas por operation+), onde são descritos o nome do serviço e os argumentos de entrada e de saída referentes a este serviço (indicado por (6)e(7)). Já na deĄniçãodef, é possível declarar variáveis inteiras para que sejam usadas posteriormente nos predicados, onde o valor das variáveis é obtido pela avaliação de expressões aritméticas que envolvem contadores pre-deĄnidos, sendo eles: req,acteterm[4]. Cada um deles possui um par de inteiros, vale time, onde o primeiro representa o próprio contador, e o segundo indica o momento em que o contador foi modiĄcado. A semântica destes contadores está fora do escopo deste trabalho.

A abstração path pode representar: chamadas a serviços (JopnameK), operações seqüenciais (Jpath . pathK), escolhas (Jpath + pathK), operações paralelas (Jpath || pathK), zero ou mais operações sequenciais de um objeto (Jpath∗_K), repetições paralelas (J{path}K) e operações com predicados (J[pred] pathK), conceituadas a seguir:

• JopnameK Ű Representa uma chamada a um determinado serviço, de nome opname;

• Jpath1 . path2K Ű Representa uma sequência de operações, onde as operações presentes em path2 só terão sua execução iniciada no momento em que todas as operações de path1 Ąnalizarem;

• Jpath1 + path2K Ű Escolha entre a execução de path1 epath2, cuja decisão pode ser determinada por predicados;

• Jpath1 || path2K Ű Operação paralela entre path1e path2, onde as operações de ambos podem ser executadas simultaneamente;

• Jpath∗_K Ű Representa a execução sequencial de zero ou mais vezes das operações deĄnidas por path;

• J{path}K Ű Repetição paralela da operação path;

Exemplo: Consideremos um armazém, cujas operações englobam receber um

pe-dido, enviar uma conta, receber um pagamento e enviar o recibo, representados respec-tivamente por order, bill, payment e receipt. Suponha que, após o recebimento do pedido, o pagamento deve ser feito dentro de 48 horas após a conta ser enviada. Se o prazo não for respeitado, todo o processo é abortado. Considerandotpay como a variável que contém o intervalo de tempo entre o recebimento do pedido e o pagamento, uma possível path expression, utilizando a sintaxe de PEWS mostrada acima, é a seguinte:

(order.bill.([tpay ≤ 48h] payment.receipt + [tpay > 48h] abortOperation))∗

As operações order e bill são realizadas sequencialmente. Logo após, são utili-zados predicados antes da execução das operaçõespayment.receipteabortOperation, representando uma escolha. Sendo eles avaliados, as operações executadas corresponderão à guarda cujo resultado da avaliação retornartrue. Se o valor da variável tpay é menor ou igual a 48h, as operaçõespayment e receipt são executadas; caso contrário, o operação abortOperation (que representa o cancelamento do processo) é executada.

PEWS possui uma variante chamada XPEWS [4], que é a versão de PEWS na linguagem XML. PEWS possui um front-end e um back-end, onde o front-end é um editor PEWS implementado como uma extensão para a plataforma Eclipse que inclui um veriĄcador de tipos e um gerador para transformação de PEWS em XPEWS. Oback-end tem a capacidade de gerar classes Java a partir de um programa XPEWS e adicionar restrições comportamentais a documentos WSDL. Não entraremos em detalhes sobre a sintaxe de XPEWS, pois não é o foco do nosso trabalho.

2.3.2

Máquina de Redução de Grafos

Uma das formas de representar tanto Serviços Web como uma composição deles é através do uso de grafos, usados muitas vezes para deĄnir processos em workĆow [31]. Vértices podem representar os serviços propriamente ditos, enquanto as arestas podem ser responsáveis por representar as relações de dependências de execução dos serviços. Para a execução de composições utilizando esta estrutura, podem ser utilizadas as máquinas de redução de grafos, uma técnica que utiliza regras pré-deĄnidas para a transformação da estrutura inicial dos grafos (em termos de serviços, uma composição) através de reduções, a Ąm de chegar a um ponto em que a estrutura não possa mais ser transformada por nenhuma das regras pré-deĄnidas [19].

2.3. PEWS 37

através de uma especiĄcação PEWS, onde são aplicadas um conjunto deregras de tradução para a formação de uma grafo. Sobre este grafo, são aplicadas um conjunto de regras de redução. A partir da especiĄcação da orquestração, as regras de tradução transformam o estado atual do grafo, realizando reduções de tal forma que o grafo não possa ser mais reduzido. No ato da realização das reduções, os processos de negócios relacionados aos serviços também são executados.

2.3.2.1 Regras de Tradução

Para podermos especiĄcar composições, é necessário o uso de uma gramática. Dessa forma, utilizaremos uma variante de PEWS, proposta em [8]. A linguagem usada tem uma estrutura que é representada pela gramática abaixo:

P ::= S( ¯I,O¯) | P1 || P2 | P1 ; P2 | [E1]P1 + [E2]P2 | IF[E1]P1 | unf old | unf olding P1

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 | E1 <E2

O símbolos não-terminaisP eE representam, respectivamente, os serviços de uma

orquestração e as expressões aritméticas e booleanas da variante da linguagem PEWS. A partir desta gramática, é possível realizar as seguintes operações:

• S( ¯I,O¯) Ű Chamadas a serviços, com ¯I representando as variáveis de entrada do serviço e ¯O representando as variáveis de saída;

• P1 || P2 Ű Paralelismo entre serviços, onde as operações realizadas em P1 ocor-rem simultaneamente as de P2, respeitadas algumas restrições que serão mostradas posteriormente;

• P1 ; P2 Ű Sequência entre serviços, onde qualquer operação em P2 só é executada após o término de todas as operações de P1;

• [E1]P1 + [E1]P2 Ű Escolhas não determinísiticas, onde a execução de P1 ou P2 depende da avaliação das expressões aritméticas E1 e E2 que retornam valores booleanos;

• U nf olding P1 Ű Repetições de P1, onde toda a ocorrência do símbolo terminal unfold representa o local onde deve ser repetido o procedimento de P1;

• ExpressõesŰ Representam os conhecidos identiĄcadores (id), números (n), e as

ex-pressões aritméticas, relacionais e booleanas (E1+E2,E1−E2,E1 < E2,E1 and E2, etc.).

Para a construção do grafo, precisamos transformar cada uma das estruturas acima num conjunto de vértices e arestas. O conjunto de vértices será representado porV, onde cada vértice é uma entidade que será avaliada de acordo com determinadas regras (cha-madas a serviços, expressões condicionais, etc.). As arestas são as estruturas que ligarão vértices e relacionarão os mesmos colocando restrições quanto à avaliação. Representare-mos arestas com o símbolo Ş7→Ť. Em PEWS-AM, são descritos dois tipos de restrições: restrições de Ćuxo de controle e restrições de Ćuxo de dados. As restrições de Ćuxo de controle determinam o Ćuxo de execução dos serviços através de arestas de controle, re-presentadas por Ac e as restrições de Ćuxo de dados representam as dependências de algumas variáveis dos vértices em relação a outros através de arestas de dependência, representadas porAd. O termo indegree(v) é usado para representar o número de arestas que chegam av, ou seja, a soma das arestas de controle − indegreec(v) − e as arestas de dependência − indegreed(v). Sendo assim, a deĄnição de grafos é representada por

hV, Ac, Adi, sendo V o conjunto de vértices, Ac as arestas de controle e Ad as arestas de dependência. Para a tradução da linguagem variante de PEWS, é usada a função T.

Veremos agora como é feita a tradução de uma composição de serviços P para grafos. A regra de tradução para uma chamada a serviço é feita da seguinte forma:

TJS( ¯I,O¯)K =D{w:S! ¯I, w′ :_S? ¯_O},{w7→w′_},∅E

Uma chamada a serviço é traduzida para um grafo de dois vértices, w e wŠ, que representam, respectivamente, expressões de entrada para o serviço S (S! ¯I) e variáveis

de saída do serviço S (S? ¯O). Uma aresta de controle é criada entre esses dois vértices,

garantindo que os dados resultantes da execução da operaçãoS! ¯I serão armazenados nas

variáveis da operação ¯O. Isso é mostrado na Ągura 3.

2.3. PEWS 39

Para a tradução de uma operação em paralelo, consideremosTJP1K=hV′, A′_c, A′_di e TJP2K=hV′′, A′′_c, A′′_di. Dessa forma temos a seguinte tradução:

TJP1||P2K = hV′ ∪V′′, A′_c ∪A′′_c, A′_d ∪A′′_d ∪Δd′ ∪ Δd′′i

Os vértices resultantes representam a união dos vértices dos dois grafos,P1 e P2. Como eles estão executando em paralelo, não existem arestas de controle adicionais, por-tanto, o conjunto de arestas de controle é formado pela união das arestas de controle dos dois grafos. Apesar de estarem executando em paralelo, é possível que a execução de um vértice dependa de alguma variável que está presente na operação de algum vértice do outro grafo. Isso gera possíveis arestas de dependência entre esses dois vértices. As possíveis arestas de dependência de dados são deĄnidas por Δd′ e Δ_d′′, descritos abaixo:

Δd′ =_{{v1 7→v2} | _v1 :_S1? ¯_O∈V′ _∧

[(v2 :S2! ¯I ∈V′′ ∧ ∃x∈V ars( ¯I).x∈V ars( ¯O)) ∨ (v2 :E ∈V′′ ∧ ∃x∈V ars(E).x∈V ars( ¯O))]}

Δd′ =_{{v2 7→v1} | _v2 :_S2? ¯_O∈V′ _∧

[(v1 :S1! ¯I ∈V′′ ∧ ∃x∈V ars( ¯I).x∈V ars( ¯O)) ∨ (sev1 :E ∈V′′ ∧ ∃x∈V ars(E).x∈V ars( ¯O))]}

Para que haja uma aresta de dependência de um vértice w para um vértice w′, é preciso que w seja um vértice de saída de serviço (S? ¯O). Já o vértice w′ tem de utilizar alguma dessas variáveis de w, sendo, portanto, um vértice que possui expressões para

avaliação. Existem dois possíveis casos:(i)w′ é uma chamada de serviços (_S! ¯_I) que utiliza variáveis de saída do vértice w, ou (ii) w′ é uma expressão que é usada em um vértice Ş+Ť. A Ągura 4 mostra como seria graĄcamente a tradução desta operação.

Figura 4 Ű Tradução da operação P1|| P2 para grafos

Da mesma forma, para a tradução de uma operação em sequência, consideremos TJP1K =hV′, A′_c, A′_di e TJP2J=hV′′, A′′_c, A′′_di. Dessa forma temos a seguinte tradução:

Os vértices resultantes representam a união dos vértices dos dois grafos, P1 e

P2. Como eles estão executando em sequência, as atividades de P2 só podem começar a executar quando todas as atividades deP1 tiverem terminado, ou seja, haverá uma aresta de controle dos vértices deP1 para os vértices deP2 que possuemindegreec = 0, indicado por Δc. A criação de arestas de dependência entre os dois grafos é igual a forma de criação

do paralelismo entre serviço, mostrado anteriormente:

Δc={v1 7→v2 |v1 ∈V′, v2 ∈V′′, indegree_c = 0} Δd′ =_{{v1 7→v2 | v1} :_S1? ¯_{O ∈V}′ _∧

[(v2 :S2! ¯I ∈V′′ ∧ ∃x∈V ars( ¯I).x∈O¯)∨ (v2 :E ∈V′′ ∧ ∃x∈V ars(E).x∈O¯)]}

Figura 5 Ű Tradução da operação P1;P2 para grafos

Na tradução de uma escolha não-determinística, consideremosTJP1K=hV′, A′_c, A′_di eTJP2K=hV′′, A′′_c, A′′_di. Neste caso, temos:

TJ[E1]P1 + [E2]P2K= hV′_∪V′′_{∪ {v} : +_{, v1} :_{E1, v2} :_{E2}, A}′

c∪A′′c ∪Δ, A′d∪A′′di

Os vértices resultantes representam a união dos vértices dos dois grafos, P1 e P2, com a adição de mais 3 vértices: v, v1 e v2. O vértice v representa uma escolha não-determinística entre os vértices v1 e v2, que são expressões. Devido a isto, as arestas de controle são representadas pela união das arestas de controle já existentes em P1 e P2, adicionando-se duas arestas a mais, que saem de v para v1 e v2 (indicados por Δ), além das arestas que partem dos vérticesv1 e v2 para, respectivamente, os vértices de V1 e V2 que possuem indegreec = 0. As arestas de dependência são formadas apenas pela união entre as arestas de dependência dos grafosP1 eP2:

Δ ={v 7→v1, v 7→v2} ∪Δ′∪Δ′′

Δ′ =_{{v1 7→w |w∈V}′_{, indegree}c(_w) = 0_} Δ′′ =_{v

2.3. PEWS 41

Figura 6 Ű Tradução de uma escolha não-determinística para grafos

A tradução de uma expressão condicional simples é bem parecida com a transfor-mação da escolha não-determinística, mostrada anteriormente. Portanto, seja TJP1K = hV′_{, A}′

c, A′di em:

TJIF[E1]P1K= hV′_{∪ {v} : +_{, v}

1 :E1, v2 :f alse}, A′_c∪ {v 7→v1, v 7→v2} ∪Δ, A′_di

Os vértices resultantes representam a união dos vértices do grafo P1 e mais 3 vértices:v,v1 ev2. O vérticev representa uma escolha não-determinística entre os vértices

v1 ev2, que são expressões. Entretanto, a expressão de v2 já é avaliada como sendo falsa, ou seja, a mesma está descartada. Devido a isto, as arestas de controle são representadas pela união das arestas de controle já existentes emP1, adicionando-se duas arestas a mais, que saem de v para v1 e v2, além das arestas que partem dos vértices v1 para os vértices de V1 que possuem indegree_c=0, representadas por Δ, mostrado abaixo. Isto é descrito na Ągura 7:

Δ ={v1 7→w | w′ ∈V′, indegreec(w′) = 0}

Figura 7 Ű Tradução de uma estrutura condicional simples para grafos

Por Ąm, para a tradução de uma estrutura de repetição, consideremos TJP1K = hV, Ac, Adi. Vejamos abaixo:

TJU nf olding P1K=h{V[v :µ], Ac∪Δ, Adi

Os vértices resultantes representam a união dos vértices do grafoP1 com o vértice especial µ (M u), que representará o início de um laço. As arestas de controle são

que saem de µ para os vértices de V que possuem indegreec = 0, representadas por Δ. As arestas de dependência são as arestas já existentes em P1:

Δ ={v 7→w | w′ _∈V′_{, indegree}

c(w′) = 0}

Figura 8 Ű Tradução de uma estrutura de repetição para grafos

A tradução de um vértice do tipo unf oldnão envolve a criação de arestas. É ape-nas criado o vértice que irá representar pontos especíĄcos onde o controle é transferido para o início da iteração, deĄnida pelo vérticeµ.

2.3.2.2 Regras de Redução

Tendo traduzido a gramática de PEWS para uma notação de grafos, regras de avaliação podem ser aplicadas aos vértices para reduzir o grafo original, produzido pelas regras de tradução. Segundo [8], a máquina abstrata que corresponde ao estado inicial do grafo logo após a transformação PEWS tem a seguinte conĄguração:

hhV, Ac, Adi, ρ, I, Oi

A expressão hV, Ac, Adi faz referência aos vértices, arestas de controle e arestas de dependência do grafo. São acrescentados mais três elementos:

• Um ambiente ρ, responsável por manter a consistência e durabilidade das variáveis, representado por um identiĄcador, o vértice que lhe atribuiu um valor, e o respectivo valor. Uma expressão ρ[x,v,k] indica que a variávelx é um identiĄcador cujo valor é

k e esse valor foi atribuído pelo vérticev;

• Um bufer de parâmetros de entrada I, composto por uma operação, um vértice e uma lista de valores. Uma expressãoI[S,v,¯t] indica que o serviço S enviou uma lista

de valores ¯t para ser utilizada pelo vértice v;

2.3. PEWS 43

e irá avaliar uma lista de valores ¯t e, posteriormente, enviará o resultado para ser

utilizado pelo vértice v;

Os vértices candidatos a serem reduzidos inicialmente são: chamadas e retornos de serviços (S! ¯I e S? ¯O), escolhas não-determinísitcas Ş+Ť (que comporta também os

condicionais) e o vértice de repetição.

Uma chamada de serviço é deĄnida por D

V[v1 :S! ¯I, v2 :S? ¯O], Ac[v1 7→v2], A_d E

. Essa representação corresponde ao primeiro elemento da máquina abstrata. A avaliação dessa entrada é a seguinte:

DD

V[v1 :S! ¯I, v2 :S? ¯O], Ac[v1 7→v2], Ad E

, ρ, I, OE

=⇒ DD

V[v2 :S? ¯O], A_c, A_d E

, ρ, I, O[S, v2, Eval( ¯I)] E

, onde indegree(v1) = 0

Como vemos acima, Ąca explícito o fato de que nenhuma aresta está chegando no vértice v1, estando o mesmo pronto para ser avaliado, além de que o vérticev2 receberá a resposta da chamadaS! ¯I. Na redução, as variáveis de entrada presentes em ¯Isão avaliadas através de Eval( ¯I). O vértice v2 receberá o resultado da avaliação das entradas realiza-das por v1 e, portanto aparecerá dentro do parâmetro O. Com a avaliação feita, tanto o vértice avaliado quanto as arestas que saem desse vértice do grafo são retirados deste. Seguindo o mesmo raciocínio, vemos abaixo a avaliação da respectiva saída de serviço e a representação gráĄca na Ągura 9.

DD

V[v2 :S? ¯O], A_c, A_d E

, ρ, I[S, v1, t], O E

=⇒

hhV, Ac− {v2 7→_c v′|v′ ∈V}, A_d− {v2 7→_dv′|v′ ∈V}i, ρ′, I, Oi, onde

indegree(v2) = 0

ρ′ =_ρ[(_x

i, v2, ki | 1≤i≤n)],

¯

O =< x1, ..., xn >, ¯

t=< k1, ..., k_n >

A conĄguração usada na saída deS! ¯I é utilizada na entrada deS? ¯O. O parâmetro

I contém o serviçoS, o vértice que está atribuindo esses valores à saída (v1) e a avaliação dos valores de v1 (Eval( ¯I)), que se transformaram numa tupla de variáveis ¯t. Com esses dados, é possível avaliar a saída de serviço S? ¯O. Como resultado, temos: todos os vértices do grafo V; todas as arestas de controle e de dependência, com a exclusão das arestas que saíam do vértice v2; um novo ambiente de variáveis ρ′, que contém as variáveis de saída

¯