PEWS-RT, um Sistema de Tempo de Execução para a Linguagem PEWS

Transcrição

1 Universidade Federal do Rio Grande do Norte Centro de Ciências Exatas e da Terra Departamento de Informática e Matemática Aplicada Programa de Pós-Graduação em Sistemas e Computação Mestrado Acadêmico em Sistemas e Computação PEWS-RT, um Sistema de Tempo de Execução para a Linguagem PEWS Handerson Bezerra Medeiros Natal-RN Julho/2013

2 Handerson Bezerra Medeiros PEWS-RT, um Sistema de Tempo de Execução para a Linguagem PEWS Dissertação de Mestrado apresentada ao Programa de Pós-Graduação em Sistemas e Computação do Departamento de Informática e Matemática Aplicada da Universidade Federal do Rio Grande do Norte como requisito parcial para a obtenção do grau de Mestre em Sistemas e Computação. Linha de pesquisa: Engenharia de Software Orientador Prof. Dr. Martin Alejandro Musicante PPgSC Programa de Pós-Graduação em Sistemas e Computação DIMAp Departamento de Informática e Matemática Aplicada CCET Centro de Ciências Exatas e da Terra UFRN Universidade Federal do Rio Grande do Norte Natal-RN Julho/2013

3

4 Dissertação de Mestrado sob o título PEWS-RT, um Sistema de Tempo de Execução para a Linguagem PEWS apresentada por Nome completo do autor 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 especicada: Prof. Dr. Martin Alejandro Musicante Presidente DIMAp Departamento de Informática e Matemática Aplicada UFRN Universidade Federal do Rio Grande do Norte Prof. Dr. Umberto Souza da Costa Examinador DIMAp Departamento de Informática e Matemática Aplicada UFRN Universidade Federal do Rio Grande do Norte Prof. Dr. André Luís de Medeiros Santos Examinador CIn Centro de Informática Universidade Federal de Pernambuco Natal-RN, 17 de Julho de 2013.

5 Dedico esse trabalho a todos que me deram forças e ânimo para nalizar mais essa jornada.

6 Agradecimentos Agradeço ao Prof. Dr. Martin Alejandro Musicante que me orientou por esses dois anos na UFRN, as lições que aprendi contigo são as mesmas que um pai passa para um lho, agradeço de coração a todos os puxões de orelha que foram necessários para que me mantivesse em linha. Pelos conselhos e que me guiaram no caminho certo e não me deixaram desanimar, pela amizade e companheirismo. Me tornei um admirador de seu trabalho muito obrigado. A todos os professores do DIMAp, aos quais tive contato, pois foram de grande contribuição para a minha formação, tanto como estudante e como pessoa. Agradeço também aos meus amigos de sala, aos amigos que z na UFRN, agora vejo que todos os puxões de orelha e as broncas que levei de vocês e principalmente os incentivos, tudo teve um efeito positivo em minha vida, a caminhada foi longa mas consegui chegar até o m dessa etapa. Aos amigos que junto comigo fazem a Hissatsu: Gabriel Santos, Erick Dennel, Antônio Luis e Prentice Geovanni, agradeço por todas as aventuras que passamos juntos, todos os momentos em que eu estressado procurei vocês para tentar desopilar um pouco e colocar a cabeça no lugar, a todos os conselhos e todos os momentos em que buscando ou damos força um para o outro. A minha família pelo apoio e conança e em especial a minha mãe Maria Aparecida Bezerra, que desde sempre me incentivou a andar pelo caminho da bondade e nunca parar de estudar. A minha noiva Tainá, que foi uma das joias preciosas que encontrei nesses anos no Mestrado, tive a grande sorte conhecê-la, namorar e hoje estamos noivos e ainda temos muitos caminhos a trilhar. Obrigado morena por me fazer feliz a cada dia, me ajudar nos momentos difíceis, me apoiar e pelo enorme carinho que tens por mim, te amo. Por m, a todas as pessoas que eu tive contato, que me ajudaram nessa jornada e que contribuíram na construção de meu caráter. Agradeço a todos vocês, essa conquista de hoje cada um de vocês tem participação nisso.

7 Um barco no ancoradouro, está seguro. Mas não foi para isso que os barcos foram feitos. William Shedd

8 PEWS-RT, um Sistema de Tempo de Execução para a Linguagem PEWS Autor: Handerson Bezerra Medeiros Orientador(a): Prof. Dr. Martin Alejandro Musicante Resumo Serviços web são aplicações de baixo acoplamento que utilizam documentos XML como forma de integração de sistemas heterogêneos. Tais documentos são usados em especicações como SOAP, WSDL e UDDI que estabelecem, respectivamente, padrões integrados para a representação de mensagens, descrição e publicação de serviços, facilitando assim, a interoperabilidade de sistemas heterogêneos. Muitas vezes um só serviço não atende às necessidades dos usuários, portanto, novos sistemas podem ser concebidos a partir da composição de dois ou mais serviços, motivando o desenvolvimento da SOA - arquitetura orientada a serviços. Paralelo a esse cenário, tem-se a linguagem PEWS (Predicate path-expres-sions for Web Services), que especica o comportamento de como operações de serviços web são executadas em uma composição de serviços. O desenvolvimento da linguagem PEWS é dividido em duas partes: front-end e back-end. A partir de um programa PEWS, o front-end realiza a análise léxica, sintática e semântica das composições e por m gera código XML. O backend tem como função executar a composição PEWS. Este trabalho visa: (i) Implementar o back-end de PEWS mediante o uso de ferramentas do.net Framework para executar programas PEWS usando a tecnologia Windows Workow Foundation (ii) reformular a arquitetura proposta para o sistema de tempo de execução da linguagem. Palavras-chave: Serviços web, Composição de Serviços, PEWS, Sistema de tempo de execução.

9 PEWS-RT, System Runtime for Language PEWS Author: Handerson Bezerra Medeiros Supervisor: Prof. Dr. Martin Alejandro Musicante Abstract Web services are loosely coupled applications that use XML documents as a way of integrating distinct systems on the internet. Such documents are used by in standards such as SOAP, WSDL and UDDI which establish, respectively, integrated patterns for the representation of messages, description, and publication of services, thus facilitating the interoperability between heterogeneous systems. Often one single service does not meet the users needs, therefore new systems can be designed from the composition of two or more services. This which is the design goal behind the of the Service Oriented Architecture. Parallel to this scenario, we have the PEWS (Predicate Path-Expressions for Web Services) language, which species behavioural specications of composite web service interfaces.. The development of the PEWS language is divided into two parts: front-end and back-end. From a PEWS program, the front-end performs the lexical analysis, syntactic and semantic compositions and nally generate XML code. The function of the back-end is to execute the composition PEWS. This master's dissertation work aims to: (i) reformulate the proposed architecture for the runtime system of the language, (ii) Implement the back-end for PEWS by using.net Framework tools to execute PEWS programs using the Windows Workow Foundation. Keywords: Web services, Service Composition, PEWS, Runtime systems.

10 Lista de guras 1 Documento XML p Estrutura em formato de árvore p Pilha da estrutura dos serviços web, (KREGER, 2001) p Composição de serviço PEWS p Arquivo gerado a partir do arquivo PEWS da Figura p Plugin PEWS Editor ativo, (POTRICH, 2006) p Arquitetura back-end PEWS (MUSICANTE; POTRICH; CARRERO, 2008). p Processo de negocio BPEL (PROJECT, 2013) p Exemplo de processo de negócio, (THOM, 2002) p Alguns tipos de rotas de uxo de trabalho, (FILHO, 2002) p XML Ola Mundo!, (GRONER, 2009) p Estrutura do XML em DOM da Figura 11 (GRONER, 2009) p Extensibilidade da IDE Eclipse, Fonte: (MACHINES, 2003) p Similaridade entre linguagens estruturadas e de uxo de trabalho.... p Exemplo de um Workow criado no Visual Studio p Composição de serviços Temperatura Twitter p Documento PEWS modicado da Figura p Arquitetura do back-end PEWS-RT p Diagrama de classes compacto da ferramenta PEWS-RT p Processo para a criação do código executável p Exemplo de composição PEWS p Acessando a ferramenta PEWS-RT através do menu lateral p. 61

11 23 Acessando a ferramenta PEWS-RT com um documento XML aberto.. p Mensagem da ferramenta PEWS-RT p Adicionando caminho das ferramentas WSDL.exe e Windows Compiler workow p Documento XPEWS p Documento XOML gerado pela ferramenta PEWS-RT p Parte do documento demo.cs gerado pela ferramenta p Parte do documento demo.cs, gerado pela ferramenta p Informe sobre o local onde se encontram os os documentos gerados... p Informe sobre algum tipo de erro do Windows Compiler Workow.... p Postagem no twitter resultado da composição de serviços p Documento PEWS para o estudo de caso p Resultado da execução do estudo de caso p Documento PEWS para o estudo de caso p Resultado da execução do estudo de caso p Documento PEWS para o estudo de caso p Resultado da execução do estudo de caso p. 76

12 Lista de tabelas 1 Propriedades dos nós p Relacionamento entre os construtores PEWS e atividades Workow... p Resultado das métricas para as os três estudos de caso p Resultado das métricas para os documentos XML p Resultado das métricas para as ferramentas PEWS-RT e PEWS-AM.. p Resultado das métricas para os documentos XML p. 79

13 Lista de abreviaturas e siglas DIMAp Departamento de Informática e Matemática Aplicada UFRN Universidade Federal do Rio Grande do Norte HTTP HyperText Transfer Protocol HTML HyperText Transfer Protocol WFMC Workow Management Coalition

14 Sumário 1 Revisão Bibliográca p Denição e Manipulação de Dados p XML p Estrutura dos documentos XML p Namespaces p Serviços WEB p Arquitetura dos Serviços Web p Composição de Serviços Web p PEWS p XPEWS p Implementação da linguagem PEWS p BPEL p Fluxo de Trabalho (Workow) p Elementos primários de um Fluxo de Trabalho p Limitações p Ferramentas p Analisadores XML p DOM p Eclipse p NET Framework p WSDL.exe p. 38

15 Windows Compiler workow p Windows Workow Foundation p Implementações de Serviços Web p Desenvolvimento de Serviços WEB Usando IDE's p Desenvolvimento de Serviços Web usando ASP.NET com o Visual Studio p Desenvolvimento de Serviços Web usando o Eclipse.. p Desenvolvimento de Serviços Web usando Frameworks..... p Web Service Modeling Framework (WSMF) p Banshee p Apache CXF p C2Serve p Conclusões p PEWS-RT p Modicação na linguagem PEWS p Visão geral p Arquitetura da ferramenta PEWS-RT p Diagrama de classes da ferramenta PEWS-RT p Funcionamento da ferramenta de tempo de execução PEWS-RT.... p Mapeamento p Leitura do documento XPEWS p Obtenção de informações sobre serviços usados na composição p Obtenção de informações sobre as operações usadas na composição p Vericação da existência de constantes na composição p Tratamento do node pathexp do documento XPEWS. p. 58

16 Criação de um documento XOML correspondente ao arquivo XPEWS p Geração de Código p Geração de classes proxy p Geração classes C# auxiliares p Geração do executável p Executando a ferramenta PEWS-RT p Conclusões p Estudo de Caso p Serviços Usados nos Estudos de Casos p Operações Usadas nos Estudos de Caso p Estudo de Caso p Estudo de Caso p Estudo de Caso p Analise sobre os estudos de caso p Comparando a ferramenta PEWS-RT p Conclusão p. 79 Referências p. 81

17 15 1 Revisão Bibliográca Este capítulo apresenta os conceitos teóricos e ferramentas que foram utilizados para o desenvolvimento deste trabalho. No decorrer deste capítulo, serão abordadas as principais ideias sobre denição e manipulação de dados usando XML, serviços web, uma linguagem que especica o comportamento das operações de serviços web chamada PEWS e algumas ferramentas usadas para realizar esse trabalho, como: DOM (TITTEL, 2003), Eclipse IDE (FOUNDATION, 2003), Visual Studio (GRIFFITHS; FLANDERS; SELLS, 2003) e Windows Workow Foundation (NAGEL et al., 2008). 1.1 Denição e Manipulação de Dados As seções a seguir mostrarão as tecnologias utilizadas para a denição e manipulação de dados semi-estruturados XML Segundo (DEITEL, 2001) após a surgimento da Web, houve a necessidade de formular uma linguagem de marcação que descrevesse e desse suporte à troca de dados, através dos métodos de entrega HTTP (HyperText Transfer Protocol) 1. A exibição de documentos na rede era realizada através do HTML (HyperText Transfer Protocol) (RECOMMENDATION, 1999), porém, os padrões existentes eram insucientes para que os dados dos documentos fossem descritos e compartilhados. XML (Extensible Markup Language) (QUIN, 2012) é uma metalinguagem projetada para criar linguagens de marcação que pode descrever dados de diferentes tipos ( DEITEL, 2001). Criada em 1998 pelo W3C 2, é usada para descrever documentos e dados em um padrão com regras denidas. Seu formato é baseado em textos que denem dados 1 Protocolo de aplicação responsável pelo tratamento de pedidos respostas entre clientes e servidor World Wide Web 2

18 16 organizados na forma de árvores, podendo ser transportados através de protocolos padrões da Internet. A criação da XML teve como objetivo propor uma linguagem de marcação formal, concisa e extensível, possível de ser lida por software, para ser utilizada em diversos âmbitos da tecnologia, com distribuição ampla na internet e de fácil compreensão (BENZ, 2003). A XML, bem como a HTML, são baseadas na SGML (Standard Generalized Markup Language) (CONNOLLY, 1995). Na criação da XML, o W3C combinou as características básicas de separação de dados proporcionadas pelo formato SGML com tags 3 em formato similar ao proposto pela HTML (JR, 2012). Diferentemente da HTML, que é usada para a visualização de conteúdo de páginas web, limitando o autor dos documentos ao uso de suas marcações já pré denidas, a XML armazena e dene dados, permitindo a criação de suas próprias marcações. A linguagem XML fornece uma ferramenta de uso geral que pode ser usada para denir modos de descrever e capturar conteúdos de todos os tipos como por exemplo: árvores genealógicas, fórmulas matemáticas ou químicas, transações de e-commerce, ou seja, praticamente qualquer tipo de informação técnica ou textual (TITTEL, 2003, p. 182). Como a XML tem o propósito de ser uma linguagem de marcação de conteúdo, podese especicar quais são os dados mediante o uso de tags. Por exemplo, podemos querer criar uma relação de CDs que contenha título, artista, faixas, gravadoras etc Estrutura dos documentos XML Um dos objetivos do W3C na formulação da XML foi de que os dados presentes no documento sejam auto descritíveis e suas tags informem o tipo de informação que está por vir. A XML usa o conceito de árvore para ampliar o entendimento e obtenção dos dados, tratando cada elemento como uma sub-árvore ou uma folha da mesma. O W3C estabeleceu regras de formatação dos documentos XML pra declarar e denir os elementos que o compõe. Essas regras devem ser respeitadas para que o documento seja bem formatado (W3SCHOOLS, 1999). Os documentos XML são compostos de marcações ou tags, que são textos encontrados entre os caracteres '<' e '>'. Existem tags que indicam a abertura de uma marcação, por 3 Estruturas de linguagem de marcação que consistem em breves instruções, tenso uma marca de início e outra de m

19 17 exemplo <telefone> e tags que indicam o seu fechamento </telefone>. De acordo com (BENZ, 2003), cada documento XML tem uma estrutura lógica e uma estrutura concreta. A estrutura lógica dene o uso dos elementos, atributos, tipos de dados e outros componentes utilizados em XML. A estrutura concreta fornece os dados que vão dentro dos elementos, tais como texto, imagens, conforme for denido. Figura 1: Documento XML. A divisão física e lógica da estrutura do documento XML pode ser observada no documento da Figura Na parte lógica temos os rótulos (tags), exemplo deste é: <convidado>...</convidado>, e outros nomes, como id=01. Na parte física, temos os dados que aparecem no documento, como por exemplo: "Marcos Antônio Silva". Na Figura se tem o elemento <convidado> que possui os elementos lhos <nome>, <telefone> e < >. Os elementos de um documento XML podem conter atributos: nome e valor que se encontram dentro da tag de início de um elemento. No caso da Figura , o "id"é um atributo do elemento <convidado>, cujo valor é "01". Todo documento XML deve conter apenas um elemento raiz, que contém todos os valores e/ou outros elementos. Na Figura esse elemento é <lista>. Figura 2: Estrutura em formato de árvore. Na Figura 2 vemos um exemplo de como podemos visualizar os dados descritos na

20 18 Figura em formato de árvore Namespaces Uma das vantagens de usar a XML para denir dados é a exibilidade na criação de tags customizadas para descrever uma informação. De acordo com (BENZ, 2003), com o passar do tempo, os autores da XML perceberam que os primeiros criadores da XML não tinham previsto o conito entre tags. Por exemplo, uma aplicação utiliza um XML que contém uma tag <manga>... </manga> para denir dados da fruta manga, e essa mesma aplicação usa a mesma tag para denir dados de tamanhos diferentes de mangas de camisas, isso faz com que ocorra um conito de elementos. O recurso utilizado para resolver esse conito chama-se namespace. Segundo (BENZ, 2003), namespace é um método para separar e identicar nomes de elementos duplicados em um documento XML, denindo um prexo para as tags e os seus atributos. A declaração do namespace tem a seguinte sintaxe: xmlns:prefix = "URI" Para resolver conitos de tags, é utilizado um atributo reservado: xmlns. O nome do atributo após xmlns é um prexo exclusivo que identica o nome do namespace denido. Uma vez que o namespace é declarado, ele pode ser referenciado através do seu prexo em nomes de outros elementos. Note que a URI que identica o namespace é apenas para referenciar (isto é, ela não precisa existir sicamente na internet). Outro exemplo pode ser visto na W3C 4 para ilustrar um conito de tags. 1.2 Serviços WEB Com a evolução da internet, as páginas web adquiriram capacidade de acionar programas capazes de processar informações dinâmicas provenientes de bancos de dados e outras fontes geradoras (BIH, 2006). Esse fato provocou o surgimento de várias soluções, no lado servidor e cliente, para a construção de aplicações que são capazes de extrair dados de várias fontes e disponibilizá-los através dos navegadores Web (MATTERN; WOODS, 2006). Devido à ausência de padrões, várias empresas passaram a interagir na internet através de soluções proprietárias para trocar informações entre sistemas diferentes que pudessem se comunicar através de padrões simples e públicos (ENGLANDER., 2002; CHAPPELL; 4

21 19 JEWELL, 2002; MARKS; WERRELL, 2003). A resposta para essa demanda é o que propõe a tecnologia de Serviços Web (Web Service), relacionada com padrões abertos e pertencente a Arquitetura Orientada a Serviços (SOA) (DARDAILLER, 2007; BERTINO et al., 2008). Serviços web são aplicações de baixo acoplamento, com componentes reutilizáveis feitos para serem acessados pela Internet (MCGOVERN SAMEER TYAGI; MATTHEW, 2003). São aplicações identicadas por URIs (LEE, 1998), cujas interfaces e ligações são capazes de serem denidas, descritas e descobertas por artefatos XML. Serviços web permitem interações com outras aplicações usando mensagens na forma de documentos XML ( SCH- LIMMER, 2002; BOOTH et al., 2004; CHAPPELL; JEWELL, 2002; GOTTSCHALK et al., 2002). Esses serviços abstraem detalhes de implementação, permitindo que sejam acessados independentemente das plataformas de hardware ou software nas quais foram implementados Arquitetura dos Serviços Web A arquitetura dos serviços web (FERRIS; CHAMPION; HOLLANDE, 2002) é baseada nas interações entre três entidades: provedor de serviços, registro de serviços e consumidor de serviços (WEERAWARANA et al., 2005; CHAPPELL; JEWELL, 2002). A interação dessas três entidades é dada como: um provedor de serviço publica um serviços e informa do registro de serviço qual e onde esse serviço está; o consumidor pesquisa um serviço, com base na especicação das necessidades de uma aplicação, no registro de serviços; o registro informa ao consumidor a localização de um provedor para tal serviço. Para permitir que essas três operações sejam realizadas de maneira interoperável, foi denida a pilha de protocolos dos serviços web que contempla na sua estrutura diferentes tipos de padrões para cada camada (KREGER, 2001; MARKS; WERRELL, 2003; GOTTS- CHALK et al., 2002). A Figura mostra de maneira conceitual a estrutura da pilha dos serviços web. A base da pilha conceitual dos serviços web é a rede (KREGER, 2001) (camada de transporte). Os serviços web devem ser disponibilizados na rede para que possam ser acessados publicamente por consumidores de serviço na Internet; tais serviços web geralmente utilizam protocolos de rede nessa base da pilha, sendo o HTTP o protocolo padrão (MCGOVERN SAMEER TYAGI; MATTHEW, 2003). A camada de mensagens é baseada em XML. Para se comunicar com outros serviços web é usado o protocolo SOAP (Simple Object Access Protocol) (W3C, 2004), projetado para invocar aplicações remotas através de RPC (Remote Procedure Calls - Chamadas

22 20 Figura 3: Pilha da estrutura dos serviços web, (KREGER, 2001). Remotas de Procedimento) ou trocas de mensagens, em um ambiente independente de plataforma e linguagem de programação (WEERAWARANA et al., 2005). Através da utilização de uma linguagem (XML) e mecanismo de transporte (HTTP) padrões, o SOAP garante a interoperabilidade e intercomunicação entre diferentes sistemas ( ENGLANDER., 2002). A camada de descrição de serviços apresenta WSDL (Web Services Description Language) (CHRISTENSEN et al., 2001) como padrão para manter a interoperabilidade em serviços web, denindo, assim, a interface e os mecanismos de interação dos serviços (CHAPPELL; JEWELL, 2002). WSDL é um documento em formato XML e tem como função a descrição de serviços web. Uma aplicação que deseje utilizar serviços web deve conhecer como e que tipo de informação deve trocar com eles e como as aplicações podem acessá-los via SOAP (ALONSO et al., 2006; CERAMI, 2002). A camada de publicação de serviços dene estaticamente uma descrição do serviço e sua publicação. Repositórios UDDI (Universal Description, Discovery and Integration) publicam e enviam diretamente o documento WSDL para o serviço consumidor ( MCGOVERN SAMEER TYAGI; MATTHEW, 2003). Esses dados podem ser descobertos e pesquisados por quem está à procura de serviços adequados para resolver algum problema especíco. A camada de descoberta de serviços da pilha de protocolos da Figura inclui o uso das descrições do serviço (WSDL) e a publicação dessas descrições em repositórios que usam a tecnologia UDDI (MARKS; WERRELL, 2003; MCGOVERN SAMEER TYAGI;

23 21 MATTHEW, 2003; KREGER, 2001). O consumidor do serviço web pesquisa e localiza no diretório UDDI descrições de serviços web compatíveis com uma determinada necessidade (WEERAWARANA et al., 2005; GOTTSCHALK et al., 2002). Após um serviço ser localizado, o consumidor precisa processar a descrição (WSDL) do serviço escolhido para poder gerar requisições SOAP para interagir com a implementação dos serviços web (WEERAWARANA et al., 2005). A camada de composição referencia a uma coleção de serviços com nalidade de atingir um objetivo em particular. Aplicações completas podem ser tratadas como uma junção de diversos serviços e não mais serem escritas individualmente, subseção 1.3. Novos serviços podem ser criados a partir da existência de outros, compondo ou recompondo aplicações sem modicar código preexistente. De acordo com (KREGER, 2001) para atenderem a exigências de infra-estrutura atuais do e-business, os serviços web devem fornecer requisitos para gestão, segurança e qualidade de serviço. Esses requisitos então nas camadas verticais da Figura e devem ser tratadas em cada camada da pilha. As soluções para as camadas de gestão, segurança e qualidade de serviço podem ser independentes umas das outras. 1.3 Composição de Serviços Web Diversos serviços Web estão disponíveis na Internet, podendo ser utilizados para atingir objetivos e facilitar a interação entre sistemas heterogêneos. Contudo, cada um desses serviços possui uma utilidade limitada a sua funcionalidade. Por exemplo, se um usuário deseja fazer uma viagem, não é suciente comprar uma passagem de avião. Ele deve, também, considerar fazer uma reserva em um hotel na cidade de destino, alugar um carro, procurar lugares de entretenimento, etc. O usuário necessitaria executar cada uma dessas ações utilizando serviços individualmente, o que poderia levar bastante tempo para conciliar estas atividades (CLARO; ALBERS; HAO, 2005). A atividade de compor serviços web refere-se à capacidade de combinar serviços web em um uxo de negócio (SILVA, 2007). Cada uma dessas funcionalidades, apresentadas no exemplo acima, podem estar em um serviço web diferente sendo combinados em um único processo de negócio. Dois termos comumente utilizados na coordenação da execução de serviços são orquestração e coreograa (JORDAN, 2007). Tais termos, descrevem dois aspectos diferentes utilizados pelos padrões para tratar da criação de processos de negócio a partir da inte-

24 22 gração de serviços Web: Orquestração: é a composição de serviços para criar um novo serviço, havendo um orquestrador central que age como um controlador que coordena a chamada de outros serviços (SILVA, 2007). Coreograa: Sem a existência de um controlador, as interações entre os participantes é pré-determinada através da troca de mensagem entre os serviços disparando eventos, e os serviços são executados conforme os eventos ocorrem. (MICHELS, 2007). Há uma série de linguagens propostas para especicar uxos de processos de negócios, dentre elas podemos destacar: WSBPWL (OASIS, 2012), PEWS (BA; FERRARI; MU- SICANTE, 2011), BPEL (IBM, 2007; LIU; KHALAF; CURBERA, 2004), XLANG (THATTE, 2001), WSCL (BANERJI et al., 2007), ORC (TAN, 2010). A seguir, são mostradas duas linguagens de composição: PEWS, que é a linguagem trabalhada neste trabalho e BPEL, que é uma linguagem padrão para especicar processos de negócios dentro de web services PEWS PEWS (Predicate path-expression for Web Services ) é uma linguagem utilizada para especicar o comportamento de serviços web compostos são executadas (BA; ALVES; MU- SICANTE, 2006). Dado um conjunto de operações (métodos), pertencentes a um ou mais serviços web, uma nova composição de serviços pode ser implementado seguindo uma descrição do comportamento das operações de outros serviços. A descrição do comportamento das operações dos serviços web em PEWS é feita através das Predicate Path Expressions (BRITO, 2006), que são uma extensão das Path Expressions (ANDLER, 1979). Path Expressions são ferramentas para sincronização de processos concorrentes, restringindo as sequências permitidas das operações em um objeto. Por exemplo, dada as operações a, b e c, a expressão a.(b c) dene que a execução em paralelo da operação b e c deve ser executada precedida de zero ou mais execuções de a. Predicate Path Expressions estende e preserva as vantagens do conceito de Path Expressions, adicionando mais recursos como os predicados e variáveis (POTRICH, 2006), permitindo assim, um melhor controle de acesso e manipulação a uma operação. Por exemplo, o predicado a.([p ]b + [notp ]c) indica que uma das expressões b e c devem ser

25 23 executadas de acordo com a valor (verdadeiro ou falso) do predicado P depois de zero ou mais execuções de a (BA; ALVES; MUSICANTE, 2006). A linguagem PEWS dene 3 contadores de predicados (act, term, req) para cada operação Op no programa. Cada um desses contadores é composto por um par: um número natural val, que representa o valor do próprio contador, e um timestamp time, indicando o momento em que o contador foi modicado pela última vez. Assim, para uma operação M: act(m).val: Descreve o número de vezes que a operação M começou a executar. act(m).time: Indica o momento da última execução da operação. term(m).val: Descreve o número de vezes que a operação M nalizou sua execução. term(m).time: Indica o momento da última conclusão da operação. req(m).val: Descreve o número de vezes que a operação M foi requisitada. req(m).time: Indica o momento da última requisição da operação. Em PEWS, uma path expression combina os nomes das operações do serviço web com operadores que podem indicar: sequência (.), escolha não determinística ( ), paralelismo ( ) e prexo de predicado ([...]...), descrevendo a ordem e restrições condicionais sobre as operações de serviços web. Um programa PEWS é denido como: 1. Uma sequência de namespaces(ns), cada namespace declara em qual endereço estarão disponibilizados os documentos WSDL que descrevem os serviços e suas operações; 2. Uma sequência de alias (apelidos) para cada operação usada na composição. Com essa estratégia, apenas denindo apelidos diferentes, se torna possível usar operações, de diferentes provedores, que possuam nomes iguais; 3. Denição de constantes para serem usadas na composição; 4. A composição é nalizada com uma path-expression, que irá descrever como será o comportamento das operações.

26 24 Figura 4: Composição de serviço PEWS. No documento da Figura 4 pode ser visto um exemplo de um programa em PEWS: nas linhas 1 e 2, se encontra a denição dos namespaces PortalMusica e PortalArtistas, que apontam para o endereço de seus respectivos documentos WSDL; nas linhas 4, 5 e 6 são denidos os alias buscaralbum, buscarfaixa, e ouvirmusica para as operações buscaralbumartista, buscarfaixaalbun, e ouvirmusica, respectivamente, que irão ser usadas na composição, e qual namespace ele pertence; por m, na linha 8 se encontra a path-expression que, nesse caso, indica que três operações serão executadas em sequencia XPEWS Para facilitar a manipulação de composições de serviços web, é necessária uma versão da linguagem PEWS que faça uma representação concreta e padronizada. Com este intuito, criou-se uma versão XML de PEWS, chamada XPEWS. XPEWS é uma linguagem que faz uma descrição detalhada em XML das interfaces de um documento WSDL com base no comportamento denido em PEWS (POTRICH, 2006). O documento XPEWS tem como nó raiz o nó <envelope> que irá conter todos os outros nós para representar a composição. Dentre esses outros nós, podem-se destacar mais três nós: behaviour, operation e pathexp. O elemento behaviour possui dois atributos: xmlns: declara um namespace que referencia a um documento WSDL, podendo assim usar vários provedores de conteúdo em uma única composição de serviços; e o atributo name que é o nome da composição. O elemento operation declara quais operações serão utilizadas na composição; é composto pelos atributo name e porttype, que informa qual porttype contém a operação; e o atributo refersto associa a operação a um método de um namespace declarado no elemento behavior. O elemento pathexp informa qual é o comportamento da composição PEWS. O arquivo XPEWS gerado, pela ferramenta descrita em (MUSICANTE; POTRICH; CAR- RERO, 2008) a partir da representação de PEWS, apresentado na Figura 4, é mostrado

27 25 na Figura Figura 5: Arquivo gerado a partir do arquivo PEWS da Figura Implementação da linguagem PEWS A implementação da PEWS está em seu estágio inicial de desenvolvimento. O sistema é formado por um front-end e um back-end. O front-end é um editor dirigido pela sintaxe da linguagem e programas PEWS, implementado como uma extensão do plugin para a plataforma Eclipse (ECLIPSE, 2005). O back-end é a parte que ca responsável pela execução dos programas escritos em PEWS. Front-End O PEWS Editor 5 (POTRICH, 2006) é o front-end da linguagem PEWS. Foi desenvolvido na forma de plugin para a plataforma de desenvolvimento Eclipse e tem como nalidade facilitar a criação e edição de composições PEWS, realizando análise léxica, sintática e semântica das composições e por m gerar o código XPEWS. A Figura mostra o PEWS Editor, ele é composto por: Menu de contexto: acessado ao clicarmos com o botão direito do mouse sobre uma composição PEWS no explorador de pacotes ou sobre o arquivo que esteja sendo editado (item 1 da Figura ). O menu ca encarregado de executar o compilador para vericar a composição e gerar o arquivo XPEWS. Editor: são mostrados os recursos como sintaxe colorida para que sejam visualizados palavras reservadas da linguagem, strings e comentários adicionados à composição de maneira diferenciada (item 2 da Figura ); 5

28 26 Visualização de marcação de erros encontrados durante a análise da composição, para facilitar a localização pelo usuário (item 3 da Figura ); Figura 6: Plugin PEWS Editor ativo, (POTRICH, 2006). Back-end A implementação de um sistema de tempo de execução para uma linguagem de composição de serviços web como PEWS é uma tarefa desaadora. Durante o desenvolvimento da linguagem PEWS, alguns autores (MUSICANTE; POTRICH, 2006; BA; FERRARI; MUSI- CANTE, 2011) propuseram versões para a arquitetura do back-end da linguagem PEWS. O back-end da linguagem PEWS deve ler o documento XPEWS e a implementação em java das operações gerando um novo programa que pode ser registrado em um servidor web. O back-end também contém um sistema de tempo de execução para implementar os operadores e os construtores presentes na linguagem PEWS. A Figura 7 mostra uma visão do modelo da arquitetura proposta em (MUSICANTE; POTRICH; CARRERO, 2008) para desenvolver o sistema de tempo de execução para PEWS. A parte inferior da Figura 7 é composta por serviços web e suas descrições de interfaces WSDL. O Code Generator (Figura 7) é responsável pela geração de código PEWS e sua

29 27 Figura 7: Arquitetura back-end PEWS (MUSICANTE; POTRICH; CARRERO, 2008). representação em XML. O módulo Compositor utiliza uma descrição do comportamento da execução das operações dos serviços Web, dada por um documento XPEWS presente no módulo PEWS Program, e gera um Skeleton de classes que implementam a composição do serviço, podendo ser registrado em um servidor web. No Run-time system, da Figura 7, se encontra o resultado da composição (módulo Composition) que é registrado em um provedor de serviços (módulo Service Provider) cando disponível para que programas clientes possam utilizar suas funcionalidades usando o protocolo SOAP para comunicação (camada superior Client Application). Um protótipo de back-end foi implementado, usando a arquitetura descrita na Figura 7. Nesse protótipo o Skeleton gerado pelo back-end é um conjunto de classes Java que usam recursos de comunicação síncrona, para a passagem de mensagens aos operadores PEWS implementados. A m de habilitar tais recursos, foi usada a biblioteca JCSP (WELCH et al., 2010) de comunicação de processos em Java, a qual é uma implementação de primitivas de CSP na linguagem Java permitindo que sistemas possam ser projetados usando primitivas de sincronização CSP: canais, eventos e construtores de paralelismo e escolha. Essa implementação do back-end apresenta grandes problemas práticos, pois a biblioteca JCSP só funciona localmente, não permitindo uma implementação que use serviços web remotos, com isso, só obtiveram uma implementação parcial da linguagem. Até o presente momento, o único back-end que veio a ter sucesso foi o A PEWS- AM (CARVALHO, 2013) que é uma ferramenta que propõe um modelo abstrato para a execução de orquestrações de serviços na linguagem PEWS. Para isso, esta ferramenta

30 28 dene uma máquina de redução de grafos para a implementação de orquestrações de serviços especicadas em uma variante da linguagem de composição PEWS. Neste trabalho, propõe-se a interpretaçã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. De acordo com (CARVALHO, 2013) a máquina abstrata é denida mediante dois elementos principais: (i) um conjunto de regras de tradução (denidas pela função de tradução T que traduz os programas PEWS em grafos); e (ii) um conjunto de regras 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ção T, até obter um grafo que não possa ser reduzido usando as regras da máquina. PEWS-AM é uma máquina de redução de grafos, a qual receberá como entrada o grafo gerado pelas regras de tradução a partir de uma composição de serviços ( CARVALHO, 2013). A implementação da PEWS-AM é feita usando linguagem Java para criar o parser que traduz os programas segundo a gramática que foi denida para a estrutura em grafos que são executados pela máquina de redução. Essa tarefa de tradução é feita usando a ferramenta Jacc(JONES, 2012)(acrônimo de Just another compiler - compiler for Java). O presente trabalho apresenta outra solução para essas referências mediante a proposta de um ambiente de tempo de execução para PEWS construído usando ferramentas de uso comum na indústria BPEL BPEL (Business Process Execution Language) é uma linguagem baseada em XML utilizada para denição e execução de um processo de negócio através da orquestração de web services. Este processo é organizado através de atividades, que podem ser utilizadas para receber uma requisição no processo, invocar serviços ou retornar a resposta do processo ao serviço externo (BLANVALET et al., 2006). BPEL é a junção de duas linguagens de workow Web Services Flow Language (WSFL) (LEYMANN, 2001) e XLANG (THATTE, 2001). WSFL é uma linguagem da IBM para a descrição de composição de web services. XLANG é uma linguagem da Microsoft para especicação de troca de mensagens entre web services oferecendo uma forma para orquestrar aplicações (MOREIRA et al., 2011). A junção dessas duas linguagens possibilita dois tipos de modelagem de processos: um baseado em grafos orientados, onde a compo-

31 29 sição é realizada a partir da denição de nós e arestas; e outra que usa das vantagens da programação estruturada, onde blocos de controle complexos implicam, implicitamente, em controle de uxos (KHALAF; MUKHI; WEERAWARANA, 2003). Dessa forma, usando um destes estilos de modelagem, o projetista tem exibilidade para escolher aquela que se adapte melhor aos seus requisitos (CARVALHO, 2013). 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 denidas na forma de uma atividade (activity) (CARRERO, 2006). As atividades podem ser básicas ou estruturadas, onde o conjunto de atividades estruturadas é utilizado para agrupar atividades básicas dentro de estruturas de uxo, resultando em estruturas complexas. As atividades básicas incluem: invoke: invoca uma operação no serviço web; receive: recebe a mensagem de uma fonte externa; reply: envia uma resposta para uma fonte externa; waiting: realiza uma pausa por um período especicado; assign: utilizada para copiar dados; throw: levanta erros na execução do processo; terminate: naliza a execução de uma instância do serviço (IBM, 2007). As atividades estruturadas podem ser: sequence: dene a ordem de sequência na execução; switch: para lógica condicional; while: para laços loop; pick: para executar algum caminho alternativo ou aguardar por eventos externos; flow: para executar atividades em paralelos; links, que podem ser usadas junto a flow para indicar dependências entre as atividades concorrentes; scope: dene um escopo para agrupamento de atividades, criação de variáveis locais, tratamento pelo mesmo manipulador de erro (fault-handler) e levantamento de exceções (IBM, 2007). A Figura 8 mostra exemplo de um processo de negocio utilizando algumas atividades BPEL através da ferramenta BPEL Designer (PROJECT, 2013). 1.4 Fluxo de Trabalho (Workow) De acordo com a WFMC uxo de trabalho é a automação de um processo de negócio durante o qual documentos, informações ou atividades são passadas de um participante para outro para a realização de alguma ação, de acordo com um conjunto de regras e procedimentos (FISCHER; COALITION, 2002). Fluxo de trabalho também pode ser denido como um conjunto coordenado de atividades (sequenciais ou paralelas) que são interligadas com o objetivo de alcançar uma meta comum.

32 30 Figura 8: Processo de negocio BPEL (PROJECT, 2013). Um exemplo de uxo de trabalho ocorre ao pedir uma pizza. O cliente faz o pedido da pizza desejada ao caixa. O caixa passa essa informação para o pizzaiolo, que reúne ingredientes e coloca uma pizza no forno. O pizzaiolo entrega uma pizza para o caixa, que coleta pagamento, entrega a pizza, completando o uxo de trabalho. Um workow é uma representação virtual de um trabalho real (CURCIN; GHANEM; GUO, 2009; YAN; BEJAN, 2001). Processos de negócios são um conjunto de um ou mais procedimentos ou atividades relacionadas, que coletivamente atinge um objetivo de negócio ou uma meta, dentro do contexto de uma estrutura organizacional que dene papéis funcionais e relações ( ZS- CHORNACK, 2003). As atividades englobadas nos processos podem variar de programas de computadores até atividades humanas. Figura 9: Exemplo de processo de negócio, (THOM, 2002). A Figura 9 ilustra o processo de licenciamento ambiental de uma determinada organização. O processo inicia com a entrada de documentos no setor de protocolo. Após, a solicitação de licenciamento é analisada por um técnico do setor de análise técnica.

33 31 Neste momento, pode ser necessária uma vistoria, a qual implica em uma análise laboratorial. O resultado desta análise laboratorial é considerado na análise técnica. O processo é nalizado com a emissão da licença. Os processos são denidos para dar um nome a um conjunto de atividades (sequenciais ou paralelas) que estão relacionadas em cumprir um determinado objetivo (NICOLAO, 1998). Uma atividade é conceituada como uma descrição de um conjunto de itens de trabalho que realiza um passo lógico dentro de um processo, contribuindo para o cumprimento desse processo (FISCHER; COALITION, 2002) Elementos primários de um Fluxo de Trabalho Um uxo de trabalho precisa ser montado sobre as denições de quem faz o quê, de que forma, quando, e quais os caminhos que levam e trazem os pacotes de dados e informações. Para determinar essas características, são denidos alguns elementos que compõem um uxo de trabalho, como: Atividade: É a entidade que representa as unidades de trabalho, as ações que interagem com aplicativos externos, com o próprio uxo de trabalho, com uxos de trabalho externos e com pessoas. Pode fornecer dados de entrada e de saída, atores, eventos que disparam ações etc (ZSCHORNACK, 2003). Ator: É o responsável pela execução de uma ou mais atividades pertencentes ao uxo de trabalho (THOM, 2002). Papéis: Conjunto de participantes (atores) que possuem um mesmo leque de habilidades que os tornam aptos a executarem a atividade relacionada ao papel (BARROS, 1997). Regras: São elementos que denem de que forma os dados que trafegam no uxo de trabalho devem ser processados, roteados e controlados pelo uxo de trabalho. Rota: Caminho lógico que o uxo percorre, podendo ser sequencial, paralelo, bifurcado, em forma de laço. A Figura 10 mostrar como é a representação de algumas das rotas em um uxo de trabalho.

34 32 Figura 10: Alguns tipos de rotas de uxo de trabalho, (FILHO, 2002) Limitações De acordo com (NICOLAO, 1998; GEORGAKOPOULOS; HORNICK; SHETH, 1995; FILHO, 2002), uxos de trabalho apresentam algumas limitações: Interoperabilidade: uxos de trabalho incorporam interpretações distintas sobretudo dos processos de negócio, tornando praticamente impossível descrever sistemas diferentes, mesmo diante de esforços de padronização de organizações tais como o WFMC (FISCHER; COALITION, 2002); Independência de linguagem: outro ponto sobre interoperabilidade, uxos de trabalho geralmente apresentam-se bastante dependentes da linguagem de especicação do uxo de trabalho, conseguindo, deste modo, apenas executar uxos de trabalho descritos em uma linguagem especíca. Escalabilidade: a maioria dos sistemas foi originalmente planejada para dar suporte a um pequeno número de usuários em cooperação. O aumento da demanda em face à popularização destes sistemas muitas vezes aponta a necessidade de re-projeto; Arquitetura centralizada: uxos de trabalho normalmente são construídos com uma única máquina de execução, acessada por todos os usuários de todos os uxos de trabalho correntemente em execução. Esses item passa a ser seu principal gargalo;

35 Ferramentas Foi utilizado algumas ferramentas de uso na industria para a elaboração desse trabalho, foram elas: DOM, Eclipse IDE, Windows Workow Foundation, WSDL.exe, Windows Compiler Workow. A ferramenta DOM foi usada em nosso trabalho na subseção, Nossa ferramenta faz a leitura de um documento XPEWS, visando obter informações sobre os serviços, operações e comportamento de uma composição de serviços PEWS. Nossa ferramenta foi projetada para complementar a ferramenta PEWS Editor ( PO- TRICH, 2006) e ambos são plugins para a plataforma Eclipse IDE. Usamos algumas ferramentas disponibilizadas pelo.net Framework, para compor a PEWS-RT, foram elas: (i) Windows Workow Foundation (WF) é um modelo de uxo de trabalho que trabalhamos para a partir dele gerar o executável da composição PEWS; (ii) WSDL.exe que cria classes C# para acessar serviços web remotamente; (iii) Windows Compiler Workow que compila uxo de trabalho WF gerando um executável desse uxo. A seguir, estão as descrições das ferramentas utilizadas nesse trabalho. No capítulo 2, se encontra com maior detalhamento o papel dessas ferramentas em nosso trabalho Analisadores XML De acordo com (VELOSO, 2007), para manipular documentos no formato XML, de maneira que se tenha acesso a todos os elementos que constituem esse documento, precisamos ter em mãos algumas ferramentas que nos permitirão realizar o parsing desses documentos. Essas ferramentas são chamadas de parsers de XML, normalmente, implementados na forma de API's (Interface de Programação de Aplicações). Um XML Parser lê um arquivo XML, separando os elementos, atributos e dados de texto, para criar uma representação desse arquivo na forma de árvore. A partir dessa representação poderemos iniciar sua análise e manipulação. A primeira tarefa do analisador é vericar a sintaxe de um documento XML e certicar se o documento é bem formado. A segunda tarefa, para alguns parsers, é procurar um arquivo de esquema para a validação do documento XML e validá-lo com base na descrição de como devem ser utilizados nele os elementos, atributos etc.

36 DOM Document Object Model (DOM? Modelo de Objetos para Documentos) fornece um conjunto de objetos e métodos para representar documentos em linguagem de marcação para hipertexto (HTML) e em linguagem de marcação extensível (XML). Ele cria um modelo padrão de como esses objetos podem ser combinados, bem como uma interface padrão para acessá-los e manipulá-los (VELOSO, 2007). A API (interface de programação de aplicações) DOM (ORACLE, 2010) é uma recomendação ocial da W3C, representando a estrutura de árvore do XML com raízes, elementos e atributos alinhados na forma de árvore de objetos DOMo. Cada nó da árvore DOM representa um item correspondente ao documento XML lido; O nó raiz DOM sempre coincide com o elemento raiz do documento original e os outros nós da árvore estão localizados por sua relação com o nó raiz; em seguida, depois desse mapeamento, a árvore DOM é carregada na memória do computador para que seja manipulada. DOM, simplica a manipulação do conteúdo de um documento XML, pois não há limitação na ordem em que as estruturas do documento são processadas 6, o que torna possível navegar em qualquer ordem pelo documento, permitindo acrescentar dados, removê-los e consultá-los. Cada nó dessa árvore pode ser acessado diretamente. Mas, devido ao fato de DOM ler e criar toda a estrutura do documento XML em uma árvore na memória é possível ocorrer um alto consumo de recursos da máquina. Para ilustrar a construção estrutural de como é montada uma árvore DOM, tomemos como exemplo o documento XML da Figura 11. Figura 11: XML Ola Mundo!, (GRONER, 2009). Existem objetos para representação de elementos, atributos, entidades, textos, entre outros. O objeto básico do DOM é o nó (Node). Ele é um objeto de uso geral na árvore e, portanto, os objetos DOM são sub-classes do objeto Node. A Figura mostra como é a estrutura hierárquica em forma de árvore do XML da Figura 11 e os alguns métodos utilizados pela API DOM para acessar os nós, valores e atributos do documento XML. 6 Outras formas de processar documentos XML possuem a restrição de ser necessário percorrer a árvore do documento na ordem imposto pelo seu texto

37 35 Figura 12: Estrutura do XML em DOM da Figura 11 (GRONER, 2009). A Tabela , mostra alguns componentes da API DOM usados na Figura 11 para manipulação de documentos XML. Tabela 1: Propriedades dos nós. Nome Descrição NodeType Retorna o tipo do nó. NodeName Retorna nome do nó. NodeValue Retorna ou altera o valor do nó Atributes Retorna os atributos do elemento FirstChild Retorna o primeiro nó lho Eclipse Na área de desenvolvimento de software, tem havido uma necessidade de ferramentas para ajudar a escrever, compilar, depurar e implantar aplicações (RANDOLPH et al., 2010). O Eclipse é uma plataforma de software livre para criar um ambiente de desenvolvimento integrado (IDE) composta por ferramentas para a construção, implantação e gestão do ciclo de vida de software (GEER, 2005). Disponível para as plataformas windows, linux e Mac OS, o Eclipse é uma IDE de desenvolvimento não só para a plataforma java, mas para outras linguagens também, como o C++, C e PHP.

38 36 Todos os componentes do Eclipse, exceto seu núcleo, foram desenvolvidos como plugins (GEER, 2005). Fazendo com que sua arquitetura seja extensível, permitindo que terceiros criem ferramentas para serem integrados ao ambiente (CLAYBERG; RUBEL, 2006). Os plugins podem vir na forma de produtos e/ou ferramentas podendo serem estendidos por outros produtos e/ou ferramenta. Por exemplo, podemos estender editor de texto simples para criar um editor XML. Na Figura pode-se ver como a estrutura da plataforma Eclipse é montada. Figura 13: Extensibilidade da IDE Eclipse, Fonte: (MACHINES, 2003). Nessa estrutura podemos destacar algums componentes, como: Plugins PDE (Plug-in Development Environment), fornece ferramentas que automatizam a criação, manipulação, depuração e implementação de plugins para o Eclipse; Workspace, responsável pelo gerenciamento dos recursos disponíveis para os plugins, visando a gerência e modicação de projetos, pastas e arquivos, denindo como tratar os arquivos e outros itens dos projetos; Workbench, responsável pela interface com o usuário, denindo ações da barra de ferramentas e do menu, operações de arrastar e soltar, assistentes e editores personalizados; Plugins JDT (Java Development Tools), estendem o workbench da plataforma, fornecendo recursos para edição, visualização, compilação, depuração e execução do código Java; Dentre as ferramentas que o Eclipse IDE oferece, podemos destacar algumas, como: Ferramentas para escrever, compilar, depurar, testar, e editar os programas escritos em Java;

39 37 Desenvolvimento de plugins para o Eclipse; Editor gráco para HTML, JSP e JSF; Desenvolvimento de seu aplicativo da Web; Ferramentas de gerenciamento de banco de dados; Ferramentas para modelagem quem usam notações UML; Aplicações JavaScript; Ferramentas para desenvolvimento de serviços Web; Suporte a servidores de aplicação: Tomcat e GlassFish; Ferramentas para criação e visualização de arquivos NET Framework Na tentativa de atenuar a crescente complexidade de desenvolvimento de software, a Microsoft lançou um conjunto de ferramentas para o desenvolvimento de software: Microsoft.NET Framework. O.NET Framework é um ambiente para o desenvolvimento, execução e implantação de aplicativos e serviços Web. O ambiente integra linguagens de programação, como: VB.NET (Visual Basic), C#, C++, F# e linguagens cujo compilador esteja de acordo com a CLS (Common Language Specication) (NAGEL et al., 2008). O.NET Framework tem dois componentes principais: Common Language Runtime (CLR) e a Biblioteca de classes(class library). Common Language Runtime é um ambiente de execução de aplicações que oferece um conjunto de serviços ao código executado sobre o.net Framework, tais como: gestão de memória e de objetos, integração entre linguagens, vericação de segurança do código, compilação e execução do código. Este componente é responsável também por controle de versões e garbage colector (MSDN, 2012c). Biblioteca de classes(class library) é uma coleção de classes orientadas a objeto de tipos reutilizáveis integradas com a CLR, usadas para desenvolver aplicativos em linha de comando (CLI), aplicativos por interface gráca (GUI), Serviços do Windows, ASP.NET, Web Forms, Serviços Web, Windows Presentation Foundation, Windows Communications Foundation e Windows Workow Foundation (MSDN, 2012c).

40 38 Um programa é escrito em uma das linguagens de programação disponíveis para a plataforma; o código fonte gerado e compilado gerando um código intermediário em uma linguagem chamada MSIL (Microsoft Intermediate Language). Este código fonte gera um arquivo na linguagem Assembly, gerado de acordo com o tipo de projeto: Arquivos Executáveis EXE; Biblioteca de Funções DLL; Páginas Web ASPX; Web Service em formato ASMX (BUKOVICS, 2007). O.NET Framework fornece algumas ferramentas de linha de comando para auxiliar nas tarefas de compilação e implantação, como geração de executáveis (MSDN, 2012b), dentre elas, duas foram utilizadas nessa proposta: WSDL.exe e Windows Compile Work- ow.exe: WSDL.exe A ferramenta WSDL.exe gera código C# a partir de documentos WSDL de Serviços Web e esquemas XSD. Ao iniciar o WSDL.exe, informa-se o documento WSDL que descreve um serviço web, para que possa ser gerada uma classe proxy para o serviço web. Essa classe ca encarregada de expor os métodos do serviço informado e realizar a comunicação entre a aplicação e o serviço. Quando o método é chamado, os dados que irão ser transmitidos são convertidos em XML, sendo enviados pela rede usando o protocolo SOAP. O servidor web interpreta o pedido e responde através de outro documento XML. Ao receber a resposta do servidor, o documento XML com a resposta é convertido novamente em forma binária para que a aplicação possa usar a informação recebida (SCRIBNER, 2007) Windows Compiler workow O compilador de linha de comando de uxo de trabalho Windows Compiler workow (WFC) é usado para compilar uxos de trabalho e atividades do Workow Foundation a partir de um documento de uxo de trabalho (.XOML) e documentos C# ou Visual Basic, para gerar um executável do uxo (MSDN, 2012d). Quando os uxos de trabalho são compilados, os seguintes procedimentos são realizados: uma validação é realizada com o objetivo encontrar erros de sintaxe nas atividades do uxo de trabalho; uma classe é gerada a partir da denição do documento XOML que é introduzido no compilador; classes com código C# são gerados para ajudar com a execução em tempo de execução das atividades e gerenciamento das mesmas ( MSDN,

41 a). A saída deste processo é uma dll.net assembly. Essa dll pode ser implantada para executar o uxo de trabalho Windows Workow Foundation Windows Workow Foundation (WF) é um modelo de uxo de trabalho orientado a sistema integrante do.net Framework 3.0 usado para denir, executar e gerenciar aplicativos que usam uxos de trabalho XOML (NAGEL et al., 2008). O WF vem apoiar o trabalho de desenvolvimento de aplicativos que usam a tecnologia Microsoft, de forma a evitar escrever tanto a lógica de negócio, quanto a implementação, diretamente em C#, Visual Basic.NET ou outra linguagem.net (ALLEN, 2006). Com o WF, o resultado foi uma separação entre a lógica do negócio e a sua implementação. A lógica do negócio passa ser denida na forma de workows (uxo de trabalho) enquanto o código gerado a partir desde uxo é criado e adicionado em arquivos C#. Nem todo uxo de trabalho envolve seres humanos. Um uxo de trabalho pode ocorrer entre duas aplicações de software distribuídas (YAN; BEJAN, 2001; BARRETT; HOWLEY; DUGGAN, 2011). Por exemplo, duas aplicações de gestão de conteúdo podem necessitar seguir um conjunto especíco de passos e regras de sincronização para que o conteúdo seja gerado (LONG; BAKER; FUNG, 1999). Algumas características do Workow Foundation são (EISENBERG, 2008): Podem executar e coordenar trabalhos que necessitam de uma longa duração; Existe uma infra-estrutura integrada para monitorar processos em execução. O mesmo diagrama gráco que executa workow é usado para ilustrar a sua etapa atual no processo, os passos anteriores executados, e os caminhos de conclusão. Fluxos de trabalhos em WF são stateful, ou seja, guardam estado; Podem ser modicados dinamicamente durante a execução quando novas condições requisitarem que o uxo de trabalho se comporte de maneira diferente do que quando foi criado; WF suporta uxos de trabalho sequenciais para sistemas com lógica sequencial e uxos de trabalho de máquina de estados para sistemas com lógica baseada em eventos;

42 40 WF permitem uma descrição de sua lógica como um uxograma; A aplicação baseada em workow criada usando WF possui construtores estruturados: Ele mantém o estado, recebe entrada e envia a saída, fornece controle de uxo e executa o código que executa o trabalho da aplicação (MYERS, 2007). A Figura mostra uma comparação entre código numa linguagem estruturada e o código em WF. Nela podemos vericar que os mesmos mecanismos de entrada e saída de dados, escolha, laço presentes na programação estruturada estão presentes também na Workow Foundation. Figura 14: Similaridade entre linguagens estruturadas e de uxo de trabalho. O WF dene e executa processos utilizando um conjunto de blocos de construção chamados de activities (atividades) (NAGEL et al., 2008) (WF fornece um design que, por padrão, está hospedado dentro do Visual Studio, permitindo arrastar e soltar atividades na superfície de design para criar um modelo de Workow). O Workow Foundation é constituído como uma série de atividades que são executadas através do Workow Runtime (BUKOVICS, 2007). Uma atividade, por exemplo, pode enviar um , atualizar uma linha em um banco de dados, ou executar uma operação no back-end do sistema.

43 41 É dito que uma atividade é composta quando essa atividade é constituída por outras atividades, sendo essas atividades chamadas de atividades lhas. É dito que uma atividade é simples quando ela não é composta por outras atividades. Existem no Visual Studio diversos de atividades, as quais estão divididas nas seguintes categorias: Custom Workow Logic: CodeActivity, atividade simples, destinada a adicionar linhas de código ao workow para ser executado; Flow Control: atividades de controle de uxo, como: múltiplas escolhas (IfElseActivity) expressas por códigos ou regras; loop no uxo a partir de uma determinada condição (WhileActivity); Executar o uxo em uma ordem denida (SequenceActivity); Interromper temporariamente a execução do Workow por um determinado período de tempo (DelayActivity); Executar duas ou mais atividades ao mesmo tempo (ParallelActivity); Criar e executar múltiplas copias de uma atividade (ReplicatorActivity) entre outras; State Management: Atividades que são usadas para denir, inicializar, nalizar e mudança entre diferente estados de maquina de estados; Event Handling: Contem atividades que manipulam eventos; Local Service Communication: As atividades dessa categoria são usadas na comunicação entre workows e serviços locais; Rules: categoria usada para associar o workow com um conjuntos de regras que podem agir sobre campos ou propriedades do workfow; Web Services: habilita o workow para invocar e interagir com serviços web; Transactions, Compensation, and Synchronization : Permite denir uma única unidade de trabalho que engloba varias atividades, permitindo sincronização, escopo de transação 7 e compensação de variáveis 8. Exceptions and Error Handling: Atividades usadas para lançar (CallExternalMethodActivity) e lidar com as exceções dentro de um workow. 7 Se uma exceção não tratada é lançada por qualquer atividade lha nesse escopo, é feito o rollback nessa transação, fazendo com que todas as modicações realizadas por esta no escopo sejam rejeitadas. 8 capacidade de desfazer ações que tenham concluído com êxito.

44 42 A Figura representa um workow, criado no Visual Studio, utilizando algumas atividades: CodeActivity (item 1); IfElseActivity (item 2) que através de condições, expressas por códigos ou regras, direciona o uxo para um de seus branchs 9 (item 2a e 2b); WhileActivity (item 3); DelayActivity (item4) e por ultimo CallExternalMethodActivity (item5). Figura 15: Exemplo de um Workow criado no Visual Studio. Além dessas atividades, linguagens de domínio especíco podem ser geradas pela criação de atividades personalizadas. Assim como as atividades, o design do workow também pode ser personalizado (EISENBERG, 2008). 9 ramicações

45 Implementações de Serviços Web Como citado na sessão 1.2, o conceito serviços web está associado à aplicações de baixo acoplamento, com componentes reutilizáveis disponibilizando funcionalidades através de interfaces programáveis feitas para serem acessados pela internet. Esse capitulo é dedicado a apresentar outras implementações, am de poder comparar como o cenário de ferramentas voltadas para serviços web. São mostradas algumas IDES's e frameworks para a construção de serviços web: IDES's e frameworks Desenvolvimento de Serviços WEB Usando IDE's Existem algumas ferramentas de apoio ao desenvolvimento de serviços web propondo agilizar e facilitar o processo na criação, edição e publicação de serviços web, por exemplo: Visual Studio IDE e Eclipse IDE Desenvolvimento de Serviços Web usando ASP.NET com o Visual Studio O Visual Studio permite criar serviços Web que usam ASP.NET. A IDE fornece uma ferramenta chamada Visual Web Developer, que gera todo o código necessário para referenciar e usar serviços Web locais ou externo (WALKASP, 2012). Tais serviços são construídos em cima do.net Framework e da common language runtime. O Visual Studio fornece uma ferramenta chamada Web references para auxiliar no desenvolvimento dos aplicativos cliente de serviços web. Web references fornece acesso a um recurso disponível em um serviço web através de protocolos, como SOAP e HTTP (MICROSOFT, 2012b). Em seguida, é gerada uma classe proxy para representar localmente as funcionalidades de um serviço Web (MICROSOFT, 2012a). Essa classe proxy dene métodos que representam os métodos expostos pelo serviço web referenciado. Criando uma instância da classe proxy gerada, o aplicativo pode chamar os métodos do serviço Web como se o serviço fosse um componente disponível localmente. Em tempo de execução, uma chamada para um método do objeto proxy é processada e codicada como uma mensagem de solicitação SOAP. Se o serviço Web não suporta SOAP, a classe de proxy usa HTTP GET e POST. A mensagem é então enviada para o serviço Web de destino para processamento. Se a descrição do serviço dene uma mensagem de resposta, o objeto de proxy processa esta mensagem e retorna uma resposta ao seu pedido (MICROSOFT, 2012b).

46 Desenvolvimento de Serviços Web usando o Eclipse A IDE Eclipse fornece uma estrutura de ações, preferências, geradores de código e ambientes para ajudar os usuários criar, publicar, descobrir, consumir e testar serviços web a partir de Java beans, enterprise beans (EJB) ou documentos WSDL. O eclipse possui ferramentas (Web tools) que ajudam no desenvolvimento de aplicações Web, para que seja possível congurar essas aplicações como serviços Web. É possível também adicionar e usar servidores web, para testar e implantar os serviços web criados. Além dessas ferramentas, o Eclipse disponibiliza outras ferramentas para ajudar com os seguintes aspectos da desenvolvimento de serviços Web: Procurar os registros UDDI ou documentos WSDL's para localizar e integrar serviços web. Empacotar artefatos existentes como serviços SOAP e descrevê-los em WSDL. Os assistentes para serviços Web ajudam a gerar um proxy de cliente Java para serviços web descritos em WSDL e gerar Java bean skeletons a partir do WSDL. Implantar (Deploy) serviços Web. Testar Serviços web rodando localmente ou remotamente, a m de obter um feedback instantâneo. Ferramentas para auxiliar na criação de aplicativos Clientes para serviço Web (Web service client application) para consumir um serviço web. Publicar serviços Web em um repositório UDDI v2 ou v3 Business Registry, anunciando seus serviços web de forma que outras empresas e clientes possam acessá-los Desenvolvimento de Serviços Web usando Frameworks Um Framework é um conjunto de bibliotecas ou classes que fornecem um conjunto de funcionalidades para um domínio especico, na qual um projeto do software pode ser baseado e desenvolvido. A seguir são listados alguns frameworks usados para criação de serviços web.

47 Web Service Modeling Framework (WSMF) Web Modeling Framework Service (FENSEL; BUSSLER, 2002) fornece o modelo conceitual para desenvolver e descrever serviços web e composição de serviços. Segundo ( FENSEL; BUSSLER, 2002) o WSMF foi proposto para serviços web baseados em E-commerce que necessitam de uma estrutura de modelagem centrada em torno de dois princípios : Separa os vários componentes que realizam uma aplicação de E-commerce. Serviço que faz a mediação entre as interações dos componentes permitindo a conversa entre eles de uma forma escalável. O WSMF consiste em quatro principais elementos diferentes: (I) ontologias que fornecem a terminologia utilizada por outros elementos para representar um conceito e os relacionamentos; (II) Goal Repositories que denem os problemas que devem ser resolvidos pelos serviços da web através de pré e pós condições; (III) descrições serviços web que denem vários aspectos (nome, nalidade, pré e pós condições das estrutura de dados de entrada e saída de dados e etc ) de um serviço web; (IV) mediadores fazem a mediação entre as interações dos componentes usados na lógica de negócios do serviço web permitindo a conversa entre eles de uma forma escalável (FENSEL; BUSSLER, 2002) Banshee A ferramenta Banshee tem o objetivo de auxiliar o desenvolvimento de serviços web cliente, podendo ser capaz de converter objetos Java para XML, e enviar strings XML para serviços. A conversão para XML é feita através de conversores, que podem ser personalizados (JAXB, XStream e XMLBeans) (SAUDATE, 2011). Compatível com SOAP (versões 1.1 e 1.2) e serviços REST, o banshee possui ferramentas que facilitam o manuseio dos serviços Web seguros (como https, certicados, usando WS-Security ou autenticação HTTP), timeouts, tratamento de exceções, bem como alterar dinamicamente endereços de serviços Apache CXF Apache CXF é um framework para a construção de serviços web open source. CXF auxilia a construir e desenvolver serviços usando APIs, como JAX-WS e JAX-RS. Esses

48 46 serviços usam uma variedade de protocolos, como SOAP, XML, HTTP, REST, ou CORBA (APACHE, 2010a). CXF inclui um conjunto de recursos amplo, focado em alguns padrões de serviços web, como: WS-I Basic Prole, WSDL, WS-Addressing, WS-Policy, WS-ReliableMessaging, WS-Security, WS-SecurityPolicy, WS-Secure Converstation, e WS-Trust ( APACHE, 2010b). Esse framework inclui algumas extensões que propõem facilitar o desenvolvimento de novos serviços, gerado automaticamente o código a partir de classes bean Java. Inclui uma interface que suporta desenvolvimento de serviços clientes a partir de um documento WSDL (APACHE, 2010b) C2Serve Criado sob o conceito de desenvolvimento orientado a testes, o C2Serve é um framework feito em C++ que permite criar um serviço Web REST, fornecendo métodos que manipulam as solicitações HTTP de um serviço REST: GET, POST, PUT e DELETE. Além disso, o framework prevê multithreading sendo capaz de lidar com múltiplas solicitações ao mesmo tempo (C2SERVE, 2009a). As principais características desse framework são (C2SERVE, 2009b): Criar conexão de soquete e ouve as solicitações de entrada. Analisar pedidos de acordo com o protocolo HTTP. Combine as solicitações HTTP para recursos e métodos de REST. Fornecer classes e interfaces para criar recursos REST. Fornecer classes e interfaces para ler e escrever entidades HTTP. Permitir denir caminhos e parâmetros de consulta. Permite estender as funcionalidade básica do core do framework para ajustar as necessidades do desenvolvedor. 1.7 Conclusões Esse capítulo apresentou os conceitos teóricos e ferramentas que foram utilizados para o desenvolvimento deste trabalho.

49 47 Foi apresentado as denições, usos e estrutura da linguagem de marcação XML. Comentamos também acerca dos conceitos e aplicabilidade dos serviços web, que são aplicações de baixo acoplamento, com componentes reutilizáveis feitos para serem acessados pela Internet usando mensagens na forma de documentos XML. A partir da limitação de um serviço web ser restrito a sua funcionalidade e da necessidade dos sistemas poderem ter diversas funcionalidades, apresentamos o conceito de composição de serviços, que é a capacidade de combinar serviços web em um uxo de negócio, apresentado algumas linguagens que utilizam esse tipo de composição, dentre elas, a linguagem PEWS que é o nosso objeto de estudo. Em seguida, foram apresentados conceitos sobre uxos de trabalho, seus elementos e modelos. Após essa parte, apresentamos as ferramentas utilizadas para a realização deste trabalho: (I) DOM para analisar documentos XML; (II) IDE de desenvolvimento Eclipse; (III) WSDL.exe para criar classes proxy; (IV) Windows Compiler workow para compilar de uxos de trabalho XOML; (V) Windows Workow Foundation (WF) que dene, executa e gerencia aplicativos que usam uxos de trabalho XOML. Por m, foram apresentadas ferramentas usadas na industria para a construção de serviços web.

50 48 2 PEWS-RT Conforme citado na seção 1.3.1, programas escritos na linguagem PEWS implementam composições de serviços web. O projeto de desenvolvimento dessa linguagem está organizada em volta de dois componentes principais: front-end e back-end. O back-end, executa a composição descrita na linguagem PEWS (MUSICANTE; POTRICH; CARRERO, 2008). Este capitulo irá apresentar a ferramenta que desenvolvemos em nosso trabalho, como uma alternativa para o back-end da linguagem PEWS, o PEWS-RT (PEWS runtime). Iremos mostrar uma visão geral da nossa ferramenta, sua arquitetura, seu funcionamento e por m, executar a ferramenta mostrando seu uso pratico. 2.1 Modicação na linguagem PEWS A proposta inicial de PEWS em (MUSICANTE; POTRICH, 2006) não considera explicitamente o uso de parâmetros de entrada e saída das operações que fazem parte da composição de serviços, isto é, a versão original da linguagem lidava apenas com o uxo de trabalho. A partir do uso prático da linguagem foi comprovada a conveniência de se adicionar o uxo de dados nos programas escritos em PEWS (BA; ALVES; MUSICANTE, 2006). A nossa proposta implementa mudanças no proposito original da linguagem visando sanar esse problema. Na prática, os métodos dos serviços web necessitam de entrada e saída de dados para executar uma determinada função. Outra necessidade encontrada é a de que pode-se usar as constantes PEWS como parâmetros de entrada e saida das operações, e vimos a necessidade de tipa-las. A versão de PEWS usada no front-end (POTRICH, 2006) não suporta tais necessidades. A versão da linguagem PEWS considerada neste trabalho é denida com a seguinte gramática, na qual o simbolo P é o simbolo de partida e gera os programas da linguagem.

51 49 P ::= Ns Alias Const P ath Ns ::= (ns id = url) Alias ::= (alias id = porttype/id in id) Const ::= (def T ype id = E) P ath ::= id(i;o) P ath.p ath P ath P ath while(e) {P ath} [E]P ath wait(e) E ::= n E 1 E 2 E 1 E 1 and E 2 E 1 or E 2 not E 1 E 1 == E 2 E 1 E 2 E 1 < E 2 term.(id).time term.(id).val req.(id).time req.(id).val act.(id).time act.(id).val I ::= (id) E O ::= id T ype ::= int string De acordo com a gramática acima, um programa PEWS P é composto por namespaces (N Ss), operações de serviços (Alias), constantes (Const) e as path-expressions (P ath). Um namespace é denido por um endereço (url) que irá ser referenciada através de um id único. Um Alias é identicado por um id que representa o nome local para a operação presente em um serviço web, o segundo id é o nome externo da operação no serviço web e o terceiro id é o namespace do serviço usado no programa PEWS. Uma constante (Const) é denida por um tipo T ype, que pode ser um inteiro int ou uma string, e um id único e um valor para esse identicador. As path-expressions P ath podem ser denidas denidas por: (i) Alias das operações id(i; O), nas quais I é uma lista de parâmetros de entrada e uma variável O receberá o retorno da operação; (ii) uma sequência de operações (P ath. P ath); (iii) operações em paralelo (P ath P ath); (iv) laço (while) que é composto de uma expressão lógica E que é avaliada no inicio do laço para vericar se é permitido ou não executar uma path;

52 50 (v) comandos com guarda ([E]P ath) que executam, ou não, uma operação de um serviço; (vi) operação wait que pausa por um determinado tempo (E) a execução da composição. As expressões E são denidas por: numeral n, operações matemáticas E 1 E 2, operações lógicas (<,>,<=,>=, and, or, not), operadores (term, req, act) da linguagem PEWS. Para exemplicar a nova gramática que denimos, usamos uma composição com dois serviços: um que mostra a temperatura de uma determinada região, alias Temperatura, e outro que publica uma mensagem em um perl no twitter, alias Twitter, ambos no item 1 na Figura 2.1. Figura 16: Composição de serviços Temperatura Twitter. De cada um desses serviços é usada uma operação: pegartemp, que é um alias para a operação buscartemperatura pertencente ao serviço Temperatura e a operação tuitar, que é um alias para a operação tweet do serviço Twitter, item 2 na Figura2.1. Através da PEWS, o comportamento da composição é dado pela execução em sequencia das operações: pegartemp e em seguida tuitar, item 3 na Figura2.1. As modicações na linguagem PEWS podem ser vistas na comparação entre os programas das Figuras 2.1 (original) e Figura 2.1 (nossa proposta). Tais modicações foram: O suporte a tipagem das constantes, item 1 da Figura 2.1; Entrada e saída das operações, item 2 da Figura 2.1. A notação que denimos para entrada e saída das operações é da seguinte forma: nome da operação, abertura de parênteses, parâmetros de entrada separados por virgula, um ponto e virgula para separar quais são os parâmetros de entrada e de saída, parâmetro de saída e, por m, o fechamento do parênteses. Por exemplo: nomedaoperacao(), nomedaoperacao(in1), nomedaoperacao(in1; out1), nomedaoperacao(in1, in2; out1), outro exemplo é o item 2 da Figura 2.1.

53 Visão geral Figura 17: Documento PEWS modicado da Figura 2.1. A ferramenta de tempo de execução PEWS-RT (PEWS Run Time) tem como função gerar programas de baixo nível, em formato suportado pela tecnologia Workow Foundation, a partir de composições de serviços descritas em código PEWS. Essa ferramenta se apresenta na forma de um plugin para a plataforma eclipse com a nalidade de, junto com o front-end, completar o projeto de desenvolvimento da linguagem PEWS. No exemplo da seção 1.3, temos um usuário desejando planejar uma viagem acessando apenas uma aplicação única com as seguintes funcionalidades: vendas de passagens de avião, reservas em hotéis na cidade de destino, aluguéis de carros, procura de lugares de entretenimento e etc. Tal sistema, pode ser criado utilizando a linguagem PEWS, compondo serviços que disponibilizem as funcionalidades necessárias. Pode-se observar que a composição segue uma sequência de atividades que produzem um resultado, ou seja, a aplicação segue um uxo determinado de trabalho. De acordo com (POTRICH, 2006), as composições de serviços web e os padrões de processo de workow (HAHN et al., 2013) estão relacionados no sentido que ambos estão focados na gerência do uxo de execução de trabalho. A partir dessa característica de uxo de trabalho e da necessidade de ter uma ferramenta que faça a execução da composição PEWS, escolhemos o Windows Workow Foundation (WF) 1, um framework que utiliza uxo de trabalho, para compor nossa ferramenta. Além desse ponto, o WF foi escolhido de acordo com as seguintes opções: (i) implementa alguns desses padrões de processo de workow, como: Sequence, Parallel split, Synchronization, Exclusive choice, Simple merge, Arbitrary cycles, Cancel Activity ; (ii) implementa construtores que são similares aos operadores de sequência (.), paralelismo ( ) e repetição (*) da linguagem PEWS. A Tabela 2.2, mostra como é o relacionamento entre os construtores PEWS e as 1 Para mais informações, ver seção

54 52 atividades Workow Foundation, esse relação é dada pela semelhança de funcionalidade que ambas expressam. Tabela 2: Relacionamento entre os construtores PEWS e atividades Workow. Construtores PEWS Atividades Workow Sequence (.) SequenceActivity Parallel split ( ) ParallelActivity Wait DelayActivity IfElseActivity Operações com guarda While WhileActivity Ao longo do desenvolvimento foram encontrados algumas diculdades, que precisaram ser solucionadas: Executar o uxo de trabalho sem o auxilio de IDE; Fazer a comunicação entre a aplicação criada e os serviços web usados na composição PEWS; Implementar os contadores act, req e term da PEWS; Tratar operações com guarda; Representar o comportamento da composição PEWS no formato de uxo de trabalho Workow Foundation; Gerar o executável da composição. Ao longo das próximas seções, são mostradas as soluções para as diculdades acima. 2.3 Arquitetura da ferramenta PEWS-RT Como foi dito na subseção , foi proposta uma arquitetura (MUSICANTE; PO- TRICH; CARRERO, 2008) para o back-end da linguagem PEWS, Figura 7, porém as tecnologias usadas para a criação do back-end proposto não são usadas em nosso trabalho, tornando partes dessa arquitetura sem utilidade. Por isso, elaboramos uma nova arquitetura com algumas modicações para que tornasse viável nossa implementação.

55 53 A Figura 2.3 mostra uma visão em camadas do modelo da arquitetura que usamos para desenvolver o sistema de tempo de execução. A camada inferior é composta por serviços web e seus documentos WSDL's. Figura 18: Arquitetura do back-end PEWS-RT. A camada de Geração de código compreende as funcionalidades de geração de código para gerar um programa executável de uma composição PEWS. O Documento XPEWS é o programa de entrada que o back-end recebe para iniciar esse processo de geração. O módulo Analisador XPEWS se encarrega de analisar o documento XPEWS para obter informações sobre os serviços, operações e o comportamento que tem a composição de serviços e criar um documento contendo tal comportamento em formato Workow Foundation (documento XOML). O módulo Gerador Csharp gera documentos C# através das informações que foram obtidas no módulo Analisador XPEWS. A camada Runtime é responsável pela criação do programa executável da composição. O módulo Compositor cria o programa executável da composição PEWS usando os documentos C# gerados pelas camadas anteriores. Por m, no modulo Executáveis se encontra o executável da composição que foi gerado pela back-end PEWS-RT.

56 Diagrama de classes da ferramenta PEWS-RT Na Figura 2.4 podemos ver o diagrama das classes que compõem a ferramenta PEWS- RT. Figura 19: Diagrama de classes compacto da ferramenta PEWS-RT. A estrutura do PEWS-RT está dividida em três pacotes principais: Analisador_PEWS, que realiza análises nos documentos WSDL e XPEWS; Gerador_Csharp, responsável por gerar arquivos C# e o pacote compositor que gera o executável em Workow Foundation de uma composição PEWS. O pacote Tools consiste em classes usadas gerar código C# e ler e salvar arquivos. No pacote Analisador_PEWS temos: (i) A classe inicial da ferramenta é a Main que lê um documento XPEWS iniciando todo o processo de análises para gerar um programa executável da composição PEWS; (ii) A classe AnalisadorPEWSXML é responsável por analisar o comportamento da composição para gerar o documento XOML com comportamento similar, vericar quais serviços, operações e constantes são usadas na composição PEWS e tratar das operações com guarda; (iii) A classe AnalisadorWSDL, através da URL pertencente a um serviço web, recupera um documento WSDL para fazer uma aná-

57 55 lise na interface de uma determinada operação desse serviço. O resultado dessa análise informa se a operação requer ou não parâmetros de entrada e/ou saída de dados, quantos são e quais os tipos deles. No pacote Tools, a classe Operacoes gera código C# para as operações relacionais (<, >, <=, >=,!=, ==), lógicas (and, or, not) e aritméticas (+, -, *, /), usadas nas operações com guarda nas composições PEWS. A classe MetodosServiços é utilizada para guardar informações de uma operação de serviços como: alias da operação, alias e URL do serviço ao qual ele pertencente, e se a operação requer parâmetros de entrada e saída. A classe IOArquivo é responsável pela leitura e escrita de documentos. No pacote Gerador_CSharp, a classe GeradorCSharp gera: (I) classes proxy; (II) classes C# das operações dos serviços usadas na composição e (III) classe C# Main, que é referenciada pelo arquivo XOML, contendo funções que chamam as operações usadas na composição PEWS. No pacote compositor, a classe Run_time é encarregada de chamar o Windows Compiler Workow para compilar os documentos que foram gerados pela nossa ferramenta e gerar o executável da composição. 2.5 Funcionamento da ferramenta de tempo de execução PEWS-RT Todo o processo para a criação do código executável da composição PEWS é feito a partir de três passos: Mapeamento, Geração de Código e Geração do Executável. A Figura 2.5 ilustra esses processos. O processo de mapeamento é a fase em que a ferramenta recebe como entrada um documento XPEWS contendo uma composição PEWS em formato XML e usa a ferramenta DOM para criar uma árvore de dados com o objetivo de manipular esse documento XML. Após a construção dessa árvore, é realizada uma análise para obter os serviços, operações e constantes usadas na composição, bem como obter o comportamento dessa composição. Com esses dados, nossa ferramenta cria um documento XOML contendo a composição de serviços em formato Workow Foundation. O processo de geração de código é a fase em que a ferramenta recebe o resultado da análise realizada no processo anterior e, a partir dela, gera documentos C#, como: (I) classes proxy, geradas pela ferramenta wsdl.exe, que são interfaces para os serviços externos

58 56 Figura 20: Processo para a criação do código executável. usados na composição; (II) classe Main que contém os métodos que são referenciados pelo documento XOML para que o runtime do Workow Foundation execute e (III) classes C# que implementam os contadores PEWS para cada operação distinta usada na composição. O processo de geração do programa executável é a fase em que a ferramenta recebe os documentos produzidos no processo anterior, faz uso da ferramenta wfc.exe para compilalos e gera o programa de baixo nível que implementa a composição PEWS usada no inicio do processo. Figura 21: Exemplo de composição PEWS. Cada documento gerado pela ferramenta possui um papel importante no programa nal. Por exemplo: digamos que temos uma composição PEWS que usa uma operação X de um serviço Y, Figura 2.5, nossa ferramenta recebe essa composição e gera os seguintes documentos: documento.xoml contendo o comportamento da composição PEWS da Figura 2.5 em formato WF; main.cs: contêm as operações que são referenciadas no documento XOML para o

59 57 runtime do Workow Foundation executar; yservice.cs: classe proxy que serve como interface entre a aplicação e o serviço externo Y usado na composição PEWS; x.cs: responsável por implementar a operação X do serviço Y usada na composição, bem como, implementar os contadores PEWS para essa operação. A execução do código gerado se comporta da seguinte forma: (I) em tempo de execução o runtime do Workow Foundation lê o documento XOML e começa a executar o workow de acordo com as atividades presentes nele; (II) A primeira atividade é a de executar um método C# X, esse método se encontra no documento mais.cs. No corpo do método X, existe uma chamada para a classe x.cs, que implementa contadores PEWS e possui uma chamada para a classe proxy yservice.cs; (III) A classe yservice.cs envia e recebe informações para o serviço web externo, enquanto a classe x.cs atualiza seus atributos que representam os contadores PEWS. Abaixo, esses processos são detalhados, informando quais classes da ferramenta (Figura 2.4), são usadas para cada função Mapeamento A seguir, é descrito o processo de mapeamento mostrado na Figura Leitura do documento XPEWS O primeiro passo da PEWS-RT é a leitura de um documento XPEWS, visando a geração de programas executáveis. A classe Main (Figura 2.4) é a classe encarregada desta função Obtenção de informações sobre serviços usados na composição Em seguida, é feita uma busca no arquivo XPEWS com a nalidade de encontrar quais são os serviços usados na composição, para obter informações sobre as operações existentes nesse serviço. Cada URL e alias de um serviço encontrado é guardado em um HashMap chamado aliasservicosewsdl, da classe AnalisadorPewsXml (Figura 2.4) para uma posterior consulta.

60 Obtenção de informações sobre as operações usadas na composição No nós <operations> de um documento XPEWS encontram-se as operações dos serviços usados na composição. Nesses nodos é feita uma análise das entradas e/ou saída de dados. A classe AnalisadorPewsXml é encarregada de fazer essa análise. Para cada operação encontrada no nó <operations> é criado um objeto MetodoServico com o nome dessa operação encontrada, seu alias e o alias do serviço ao qual ele pertence. Com o alias do serviço que foi encontrado, é feita uma consulta no HashMap aliasservicosewsdl para obter a URL do serviço. Com essa URL, é feita uma requisição para recuperar o documento WSDL do serviço, com a nalidade de obter informações da interface das operações pertencentes a esse serviço. A classe AnalisadorWSDL faz essa análise, descobrindo se a operação requer alguma entrada e/ou saída de dados, armazenando no objeto MetodoServico as informações pertinentes à entrada e saída dessa operação e quais os tipo desses dados (inteiro ou string). Em seguida, esse objeto é guardado em uma lista chamada listmetodosservico para que possa ser consultado posteriormente Vericação da existência de constantes na composição É vericada no documento XPEWS a existência de constantes na composição. Caso haja ocorrência das constantes, é guardado o nome da constante e seu respectivo tipo para uma consulta posterior em um HashMap hashconstantes na classe AnalisadorPewsXml, da Figura Tratamento do node pathexp do documento XPEWS No nó <pathexp> de um documento XPEWS, se encontra o comportamento da composição PEWS em formato XML, a PEWS-RT faz uma análise para gerar código C# para cada um dos construtores, operações com guarda, constantes e as operações dos serviços usadas na composição PEWS, além de identicar o comportamento dessa composição. A classe AnalisadorPewsXml ( Figura 2.4) é responsável por essa análise. Cada construtor encontrado é passado para uma função que retorna a respectiva atividade Workow Foundation, sendo essa atividade armazenada em um StringBuilder chamada conteudo para uma consulta posterior. Durante essa análise do comportamento da composição, pode-se encontrar operações

61 59 com guarda. Para esses casos, é usada a classe Operacoes, Figura 2.4, que irá analisar a operação com guarda e gerar a correspondente condição em código C# Criação de um documento XOML correspondente ao arquivo XPEWS Neste passo é usado o StringBuilder conteudo, populado no passo anterior, para gerar um documento XOML, que conterá a composição de serviços descrita inicialmente em XPEWS em formato de uxo de trabalho Geração de Código A seguir, é descrito detalhadamente o processo de geração de código mostrado na Figura Geração de classes proxy Neste passo, irão ser geradas as classes proxy para cada uma das operações usadas na composição, que servirão como interfaces para a comunicação entre o uxo de trabalho gerado pela ferramenta e os serviços externos usados na composição, classe Analisador- PewsXml (Figura 2.4), é responsável por realizar este passo. A função gerarproxywsdl, da classe AnalisadorPewsXml, faz uma consulta ao Hash- Map aliasservicosewsdl. Cada URL pertencente de um serviço encontrado nessa consulta, é recebida como parâmetro de entrada pela ferramenta wsdl.exe que irá gerar as classes proxy Geração classes C# auxiliares Além das classes proxy que foram geradas, após o passo acima, são geradas outras classes C# as quais implementam o sistema de tempo de execução da composição. A classe responsável por este passo é a GeradorCSharp, da Figura 2.4. Um dos desaos deste trabalho foi o de implementar os contadores act, req e term da linguagem PEWS. Para solucionar tal problema, a ferramenta cria uma classe C# para cada operação encontrada. Essa classe contém atributos do tipo int e Datetime que representam tais contadores, e à medida que uma operação é executada, tais atributos vão sendo atualizados. Por m, essa classe C# criada possui um método que chama outro pertencente à classe proxy para executar a operação do serviço web.

62 60 No documento XOML que foi gerado, tem-se um atributo chamado Class que referencia a uma classe C# main pertencendo a um determinado namespace 2. Essa classe main, contém métodos que são referenciados no documento XOML para o runtime do Workow Foundation executar Geração do executável O processo de geração do executável mostrado na Figura 2.5 é iniciado a partir do momento que todos os passos anteriores são executados com sucesso. Nesse momento é feita uma chamada ao Windows Compiler Workow , para compilar as classes C# que foram geradas nos passos anteriores e o documento de uxo de trabalho, gerando assim, um programa executável contendo a composição de serviços. Esse passo é realizado pela classe GeradorCSharp. 2.6 Executando a ferramenta PEWS-RT Para exemplicar os passos acima, esta seção irá demostrar a ferramenta PEWS-RT em execução. Para isso, elaboramos uma uma composição PEWS que publica em um perl da rede social Twitter a temperatura de uma determinada cidade. Essa composição está na Figura 2.1. Tal composição tem como função pegar a temperatura da cidade de Natal e vericar se a temperatura for maior que 30 graus informar no perl do Twitter tal temperatura. Para iniciar leitura do documento XPEWS, a PEWS-RT disponibiliza alguns menus acessíveis através da plataforma Eclipse. Esses menus são acionados ao reagir com as seguintes interações do usuário: Na árvore de arquivos do eclipse, ao clicar com o botão direito do mouse em cima de um documento XML, item 1 da Figura 2.6. Ao clicar com o botão direito do mouse em um documento XML aberto no editor de texto do Eclipse, item 1 da Figura 2.6. Ao ser aberto o menu a partir de tais interações, entre as opções que aparecem na tela, está uma denominado PEWSRT (item 2 das Figura 2.6 e 2.6) com um submenu denominado Gerar Executável (item 3 das Figura 2.6 e 2.6). Ao clicar nesse submenu, 2 declara um escopo que contém um conjunto de objetos relacionados

63 61 é acionado o gatilho que executa o método para a leitura do documento XPEWS. O documento XPEWS que irá ser lido para a composição da Figura 2.1 se encontra na Figura 2.6. Figura 22: Acessando a ferramenta PEWS-RT através do menu lateral. Como dito nas subseções e , a PEWS-RT usa as ferramentas WSDL.exe e Windows Compiler workow para compor suas funções. Por isso, a PEWS-RT precisa do local físico de onde essas ferramentas se encontram na maquina do usuário para poder executa-las. Porém cada computador pode instalar esses programas em locais diferentes, ocasionando mal funcionamento de nossa ferramenta. Para solucionar esse problema, a PEWS-RT possui diretivas que guardam esses locais. Ao iniciar o processo de geração do execução, a ferramenta acessa essas diretivas para obter o caminho das ferramentas, caso não tenha essa informação, o plugin informa ao usuário que ele precisa entrar com esses dados, Figura 2.6. Após esse aviso, deve-se acessar o menu informado pela ferramenta, Figura 2.6. Nesse menu, é aberto uma aba com dois campos: WSDL.exe e WCF.exe, onde irá ser informado o caminho para a PEWS-RT acessar tais ferramentas, Figura 2.6. Em seguida, são obtidas informações sobre quais serviços são usados na composição, esses serviços se encontram, nas linhas 3 e 4 do documento na Figura 2.6.

64 62 Figura 23: Acessando a ferramenta PEWS-RT com um documento XML aberto. Figura 24: Mensagem da ferramenta PEWS-RT. Figura 25: Adicionando caminho das ferramentas WSDL.exe e Windows Compiler workow.