Introdução à Composição de Serviços Web

Transcrição

1 Capítulo 8 Introdução à Composição de Serviços Web Julio Cesar Damasceno Abstract A service composition permits that services from different providers are put together to create a more sophisticated service. The present work aims to present the technologies and tools that supports the concept of web service composition, and presents how these concepts and technologies can be in the development and execution of a composition. Resumo Uma composição de serviços permite que serviços de diferentes provedores sejam colocados juntos para criar um serviço mais sofisticado. Este trabalho tem como objetivo apresentar as tecnologias e ferramentas que sustentam o conceito de composição de serviços web, e apresentar como tais conceitos e tecnologias podem ser utilizados no desenvolvimento e execução de uma composição Introdução Computação Orientada a Serviços (Service Oriented Computing) e SOA (Service Oriented Architecture) [36, 40] são conceitos importantes na área de sistemas distribuídos que têm sido amplamente utilizados em projetos e pesquisas relacionadas a serviços [31]. Em SOC/SOA, a funcionalidade da aplicação é descrita de tal forma que permite seu uso no desenvolvimento de aplicações que integram funcionalidades de outras aplicações, o que é conhecido como composição de serviços ou serviços compostos. Cada serviço encapsula a funcionalidade da aplicação tornando-a disponível através de uma interface. Além disto, serviços são normalmente autônomos e heterogêneos no sentido de que executam sobre diferentes plataformas e pertencem a diferentes organizações. SOC e SOA têm tido um papel importante no modelo de negócio de software conhecido como SaaS (Software as Service) [22]. SaaS é um modelo de disponibilização de aplicações no qual as empresas (fornecedores de software) desenvolvem, hospedam, operam e fornecem o software a outras empresas (consumidoras) que pagam para usar

2 a aplicação e não para possuí-las. Na prática, as empresas consumidoras alugam uma funcionalidade que é disponibilizada remotamente, por exemplo, através da Internet. Muitas empresas têm disponibilizado suas principais competências na Internet como uma coleção de serviços conhecidos como Web Services. Web Services de organizações diferentes ou da mesma organização são combinados para formar o que é conhecido como serviço Business-to-Business (B2B). Colaborações B2B comumente demandam interações de longa duração guiadas por um modelo de processo explícito. Por exemplo, um serviço de gerenciamento financeiro pode ser criado compondo serviços mais especializados para pagamentos, cálculo de taxas e gerenciamento de moeda. A composição de serviços é uma das áreas de maior interesse de pesquisa da atualidade. A motivação geral para composição de serviços está relacionada a dois pontos principais: possibilidade de criação de serviços mais elaborados a partir de serviços já existentes e a possibilidade de integração de negócios [11, 27, 39]. Na prática, a composição permite que serviços de diferentes provedores sejam colocados juntos para criar serviços mais sofisticados. A importância da composição de serviços tem sido reconhecida na comunidade de pesquisa da Internet devido a sua flexibilidade na construção de aplicações a partir de serviços primitivos e de uma forma plug-and-play [37, 5, 35, 7]. Neste cenário foi proposto o padrão WS-BPEL Web Services Business Process Execution Language [30]. Basicamente, este padrão é uma linguagem focada na execução de processos de negócio, permitindo que vários Web Services trabalhem de forma conjunta com o objetivo de executar uma tarefa relacionada ao negócio. Este trabalho visa apresentar as tecnologias e ferramentas que sustentam o conceito de Composição de Serviços Web, e apresentar como tais conceitos e tecnologias podem ser utilizados no desenvolvimento e execução de uma composição. O restante do trabalho está assim dividido: Seção 8.2 introduz os conceitos básicos e tecnologias associados a este trabalho. Os aspectos relacionados à arquitetura orientada a serviços (SOA), aos Web Services, aos processos de negócio (Business Processes) e a composição de serviços serão detalhados. Na Seção 8.3 é mostrado. Por fim, na Seção são mostradas as principais ferramentas disponíveis no mercado para a Composição de Serviços Conceitos Básicos Nessa seção serão introduzidos os conceitos e tecnologias básicos para o entendimento do restante desse trabalho. Inicialmente será dada uma visão geral sobre a arquitetura orientada a serviços (SOA - Service-Oriented Architecture), logo em seguida será abordada as tecnologias relacionadas. A composição de serviços, em especial de Web Services, também é apresentada nesta seção. Os processos de negócio são apresentados, e sua relação com a composição de Web Services é analisada. Por fim será feita uma introdução á linguagem de execução de processos de negócios para Services, WSBPEL Arquitetura Orientado à Serviços(SOA) Um dos requisitos mais importantes durante a implantação de Sistemas de Informação pelas empresas é a integração com outros sistemas. Para isso devemos encontrar uma maneira flexível, extensível e compatível com os sistemas que já existem, uma vez que

3 estes sistemas muitas vezes ultrapassa os limites da empresa. Realizar a substituição de sistemas legados tendo em vista a incorporação de novas tecnologias e requisitos pode trazer riscos ao funcionamento de aplicação, além de ter, em geral, um alto custo associado [24]. Em SOA, a unidade mais básica é o Serviço, que são entidades que provem alguma funcionalidade. A partir desses serviços e de suas interfaces novos serviços podem ser construídos. Como se pode reparar, as palavras chave para esse tipo de arquitetura são: integração e reuso [31, 36]. Web Services são um exemplo de como essa arquitetura está se difundindo rapidamente. E isso se deve ao fato dessa tecnologia usar de soluções simples para resolver problemas relacionados à integração entre aplicações. Web Services usam protocolos baseados em XML (extensible Markup Language) [8]: SOAP:ISimple Object Access Protoco) [28], WSDL:(Web Services Description Language) [14] sobre HTTP (Hypertext Transfer Protocol)[18] pra realizar a comunicação. Isso garante total independência de Sistemas Operacionais e Linguagens de Programação. E, por se tratar de um serviço, essa entidade mantém um baixo acoplamento com outros serviços e aplicações. SOA é mais do que apenas um conjunto de tecnologias e não está diretamente relacionada com qualquer tecnologia, embora seja mais freqüentemente implementada com Web Services. Os Web Services são a tecnologia mais apropriada para a realização de SOA. A Figura 8.1 mostra resumidamente a realização de SOA através de Web Services. Figura 8.1: Realização de SOA através de Web Services No entanto, apenas a utilização dos Web Services não é adequada para a construção de SOA. Web Services devem ser utilizados acordo com os conceitos definidos por SOA[34]: Serviços: fornecem a funcionalidade do negócio, como uma aplicação para cotação de passagens áreas;

4 Interfaces auto-descritas: os serviços são consumidos, utilizados, através de suas interfaces. A interface de um serviço define um conjunto de operações públicas juntamente com suas assinaturas. A interface é separa da implementação, autodescritiva e independente de plataforma; Troca de mensagens: operações são definidas como um conjunto de mensagens. Mensagens especificam os dados que serão trocados e os descreve em linguagem e plataforma independente utilizando XML Schemas [17]; Comunicação síncrona e assíncrona: a troca de mensagem é realizada através de um protocolo de transporte, como SOAP. Os "consumidores"dos serviços, ou clientes, podem invocar as operações de modo síncrona ou assíncrono. No modo assíncrono o cliente, após invocar a operação em um serviço, ficará travado aguardando a resposta desta operação. Enquanto no modo assíncrono, o cliente não recebe uma resposta do serviço e sim uma confirmação de que a mensagem foi recebida com sucesso, não ficando preso durante o processamento da mesma. Caso seja necessário uma resposta o cliente deverá disponibilizar uma operação (callback) na sua interface para recebê-la. Baixo acoplamento: conseguido através do uso das interfaces auto-descritas, troca de dados estruturados e suporte para comunicação síncrona e assíncrona. Serviços fracamente acoplados são serviços que expõem apenas as dependências necessárias. Mínimas dependências fazem com que as mudanças em outros serviços que dependem ou utilizam sejam também mínimas. Registro de serviços: visando automatizar a busca e simplificar a busca por serviços, informações sobre tais serviços são mantidas em um repositório de serviços. Os provedores de serviços registram seus serviços e os consumidores, quando necessário, fazem a busca nesse repositório. O UDDI Universal Description, Discovery and Integration [29] é um exemplo deste registro de serviços. Qualidade de serviços: atributos de qualidade normalmente estão associados à serviços, tais como segurança, confiabilidade, gerenciamento, transação, entre outros. No contexto de Wb Services estes atributos fornecidos pelos padrões WS-*[33]: WS-Security, WS-Addressing, WS-Coordination, etc. Composição de serviços em processo de negócios: serviços devem ser compostos de uma maneira específica seguindo uma conjuntos de regras de forma a prover suporte aos processos de negócio. Para execução do processo de negócio é utilizada uma linguagem dedicada, BPEL (Business Process Execution Language) e uma engine [25]. Um sistema orientado a serviços basicamente possui três papéis: consumidores de serviços (ou clientes), provedores dos serviços (ou servidores) e repositório (ou serviços de registro/localização). O consumir acessa o provedor através de uma interface padrão. Devido ao baixo acoplamento, mesmo que a implementação do serviço sofra alguma alteração, o cliente não irá ser afetado. A Figura 8.2 mostra os papéis(funções) de um sistema orientado a serviços.

5 Figura 8.2: SOA - Papéis e Funções As tecnologias relacionadas com serviços e Web Services, instâncias mais populares de serviços, serão abordadas nas próximas seções Web Services As arquiteturas tradicionais de sistemas distribuídos acoplam fortemente várias de seus componentes à aplicação, fato esse que as tornam frágeis diante do dinamismo que as novas aplicações requerem[1]. No contexto da Web os sistemas distribuídos são colocados em crise, pois não acompanham as mudanças referentes às necessidades do negócio e devido ao forte acoplamento e interdependência das suas partes. Para solucionar estes problemas surgiram os Web Services, uma proposta inovadora que descrevia de forma padrão interfaces para componentes de software e como acessá-las através de protocolos padrões e interoperáveis, além de fornecer mecanismos para a descoberta de novos serviços. A premissa básica para o sucesso dos Web Services foi a sua independência de linguagens e de sistemas operacionais. A Figura 8.3 mostra uma visão geral das principais características dos Web Services. Conceitualmente, um Web Service fornece um modo alternativo para expor a lógica por trás de aplicação ou serviço para clientes heterogêneos. Clientes executando em sistemas distintos podem acessar programaticamente as funcionalidades da aplicação expostas por um Web Service de um modo padrão. Um Web Service é independente de plataforma e de linguagem de programação pois usa protocolos padrões para comunicação e transferência de dados. Os clientes não precisam estar na mesma plataforma ou sistema operacional para um Web Service e normalmente não precisam ter nenhum conhecimento sobre a sua implementação ou plataforma de execução, necessita conhecer apenas a interface do Web Service ou WSDL (Web Services Description Language) [14]. A pilha de protocolos associados aos Web Services é formada por protocolos de rede responsáveis pela definição, localização, implementação e troca de mensagens.

6 Figura 8.3: Visão Geral dos Web Services Podemos agrupá-los em quatro camadas: busca, descrição, comunicação e transporte conforme mostrado na Figura 8.4. Figura 8.4: Camadas de Protocolo dos Web Services Os protocolos da camada de busca são responsáveis pelo registro e pela busca de Web Services em um repositório de serviços. O principal protocolo desta camada é O UDDI (Universal Description, Discovery and Integration) [29], que fornece um framework para descrever, buscar e integrar serviços na Web, funcionando de maneira análoga à uma lista telefônica. O UDDI utiliza várias APIs (Application Programming Interfaces) para ajudar na publicação e busca dos Web Services em um repositório de serviços. Conforme mostrado na Figura 8.5 o provedor de serviços responsável por manter o serviço cria a descrição do Web Service (WSDL) e publica a mesma no repositório

7 UDDI. O Cliente faz uma busca no repositório, onde obtém o WSDL do serviço, a partir do qual cria um cliente e finalmente comunica-se com o serviço. Figura 8.5: Visão Geral do UDDI Aplicações clientes precisam entender um Web Service antes de acessá-lo. Para isso é necessário que o Web Service seja descrito em um formato padrão para que possa ser utilizado por diferentes aplicações e em diferentes plataformas. WSDL 1.1 é uma especificação da W3C (World Wide Web Consortium) que fornece uma linguagem para descrever Web Services. Um documento WSDL é um documento XML que contém todas as informações necessárias para conectar ao Web Service. A Listagem 8.1 mostra um documento WSDL. Listagem 8.1: Documento WSDL <?xml version="1.0" encoding="utf-8"?> <wsdl:definitions targetnamespace=" <wsdl:types> <xs:schema attributeformdefault="qualified" elementformdefault=" qualified" targetnamespace=" </xs:schema> </wsdl:types> <wsdl:message name="getadicaorequest"> <wsdl:part name="parameters" element="ns:getadicao" /> </wsdl:message> <wsdl:message name="getadicaoresponse"> <wsdl:part name="parameters" element="ns:getadicaoresponse" /> </wsdl:message> <wsdl:message name="interruptedexception">

8 <wsdl:part name="parameters" element="ns:interruptedexception" /> </wsdl:message> <wsdl:porttype name="somadorserviceporttype"> <wsdl:operation name="getadicao"> <wsdl:input message="ns:getadicaorequest" wsaw:action="urn: getadicao" /> <wsdl:output message="ns:getadicaoresponse" wsaw:action="urn: getadicaoresponse" /> </wsdl:operation> </wsdl:porttype> <wsdl:binding name="somadorservicesoap11binding" type="ns: SomadorServicePortType"> <soap:binding transport=" style="document" /> <wsdl:operation name="getadicao"> <soap:operation soapaction="urn:getadicao" style="document" /> <wsdl:input> <soap:body use="literal" /></wsdl:input> <wsdl:output> <soap:body use="literal" /> </wsdl:output> </wsdl:operation> </wsdl:binding> <wsdl:service name="somadorservice"> <wsdl:port name="somadorservicehttpsoap11endpoint" binding="ns: SomadorServiceSoap11Binding"> <soap:address location=" WSSomadorService/services/SomadorService. SomadorServiceHttpSoap11Endpoint/" /> </wsdl:port> </wsdl:service> </wsdl:definitions> Os elementos de um WSDL podem ser agrupados logicamente em dois diferentes grupos: descrições concretas e abstratas ou funcional e não funcional respectivamente. A definição da interface abstrata provê uma descrição genérica dos Web Services, contendo informações reusáveis sobre o serviço como formato de mensagens, tipos de dados e tipos de protocolo. A definição abstrata é formada pelos seguintes elementos: types: contém o tipo dos dados, definidos na forma de XML Schemas, a ser utilizado na troca de mensagens; message: unidade utilizada na troca de mensagens. Cada mensagem possui parâmetros de entra e saída definidos por elementos filhos chamados part; operation: definição abstrata de uma operação para a mensagem, como o nome da operação/método, assim como as mensagens de entrada/saída referente aos parâmetros da operação do serviço; porttype: porta, no contexto de Web Services é um único Web Service. O elemento porttype é o conjunto de todas as operações que um Web Service possui.

9 Os serviços descritos na interface abstrata precisam ser implementados. A definição concreta especifica detalhes, como o protocolo a ser utilizado e o endereço de rede onde o Web Services está localizado. A definição concreta é composta pelos seguintes elementos: bindding: define os requisitos para a chamada do método, como o formato e o protocolo de transporte utilizado na troca de mensagens de cada elemento abstrato porttype; service: utilizado para descrever os endpoints, que são localizações na rede de onde os Web Services podem ser acessados. O elemento filho endpoint, também chamado elemnto port, especifica o endereço IP da real implementação do Web Service. Na camada de comunicação o protocolo SOAP (Simple Object Access Protocol) [28] é uma das tecnologias mais importantes relacionadas ao contexto de Web Service. SOAP pode ser usado sobre quaisquer protocolos de transpore. Quando utilizado sobre HTTP ele pode atravessar firewalls, que em geral, liberam o tráfego na porta 80 do servidor HTTP, assim SOAP pode ser utilizado onde protocolos baseados em chamada remota não poderiam, pois utilizam um porta padrão que não está liberado no firewalls, como o RMI [21]. A unidade básica de transmissão SOAP é o elemento XML envelope, responsável por descrever o conteúdo da mensagem fornecendo informações sobre como processar esse conteúdo. O envelope possui dois elementos filhos: header que possui informações e controle e o body que contém o corpo da mensagem XML conforme mostrado na figura Figura 8.6: Representação XML do SOAP

10 Processos de Negócio (Business Proccess) Processos de negócio podem ser definidos como uma coleção de invocações de serviços e atividades relacionadas que produzem um resultado de negócio, tanto para uma única empresa ou diversas outras[24]. Desta maneira os processos a criação e a execução de processos de negócio está estreitamente relacionada com a composição de serviços. Um dos principais objetivos dos processos de negócio é a integração de sistemas, parceiros comerciais e usuários corporativos através de processos computacionais, visando redução de custo, melhoria da eficiência profissional Composição de Serviços O reuso é uma das principais idéias definidas pelo SOA, onde sistemas complexos podem ser desenvolvidos utilizando serviços mais básicos. Como exemplo de uma composição de serviços podemos citar um conversor de monetário que tem como requisito a conversão de dolar americano para euro. Existe um Web Service que faz a conversão de dolar pra real e outro que faz a conversão de real para euro, então uma composição é criada utilizando esses dois conversores. A criação de uma aplicação orientada à serviços não é diferente da programação imperativa tradicional, exceto pelo fato de ser estarmos trabalhando essencialmente de forma distribuída e que a principal linguagem de criação de composição de serviços é baseada em XML. Essa linguagem se chama-se WS-BPEL Web Services Business Process Execution Language [30] e vem sendo largamente utilizada pela indústria para descrever composições de serviços. Na Seção a linguagem WSBPEL será abordada com mais detalhes. Web Services podem ser combinados de diferentes maneiras para formar uma composição de serviços. Os principais modos são: seqüencial, paralela e com escolha. Na composição seqüencial, Figura 8.7 (a), o serviço WS2 só será invocado depois que o WS1 terminar a sua execução. Na composição com escolha, Figura 8.7 (b), apenas um dos serviços é escolhido para ser executado. Esta escolha é feita por um critério específico representado na figura por (C). Por fim, na composição paralela, Figura 8.7 (c), os dois serviços são executados de maneira simultânea. Figura 8.7: Formas Básicas de Composições

11 WS-BPEL (Web Services Business Process Execution Language) A linguagem WS-BPEL é um padrão criado pela OASIS (Organization for the Advancement of Structured Information Standards) para a execução de processos de negócio, descrevendo como ocorre o relacionamento entre os diversos Web Services participantes da composição. A primeira versão de BPEL foi desenvolvida em agosto de 2002 pela IBM, BEA, e Microsoft, após a SAP e a Siebel juntarem ao consorcio de estava desenvolvendo foi lançado em março de 2003 a versão 1.1 [4]. Em abril de 2003 a OASIS recebeu uma versão para padronização e em abril de 2007 foi lançado oficialmente a versão de 2.0 como o nome de WS-BPEL 2.0 [30]. A versão do WS-BPEL 2.0 será a utilizada no restante deste trabalho. A programação com WS-BPEL é parecida com a programação das linguagens de programação já existentes, na medida em que ela oferece determinados tipos de construções como estruturas de repetição, estruturas condicionais, variáveis e atribuições. Este fato possibilita que o processo de negócio seja visto como uma algoritmo. Porém, o uso desses recursos é bem simples e limitado, objetivando a facilidade de uso e aprendizagem da mesma. Uma composição de serviços especificada em WS-BPEL é vista como um serviço, ou seja quem uso um processo de negócio definido em WS-BPEL não tem ciência que na verdade está utilizando vários serviços para realizar uma determinada operação. Por ser um Web Service, a composição necessita ter sua interface baseada no padrão WSDL, troca de mensagens com outros web services através do padrão SOAP e pode ser cadastrado em um repositório UDDI para fins de consulta. O padrão WS-BPEL assume que os serviços participantes da composição estejam descritos usando WSDL. A propriedade mais importante de WS-BPEL está relacionada à invocação de Web Services. BPEL permite que as operações de um Web Service sejam invocadas sincronamente ou assincronamente de uma maneira mais fácil. Estas operações podem ser invocadas seqüencialmente ou paralelamente. As funcionalidades mais importantes de WS- BPEL podem estão listadas logo abaixo: descrever a lógica dos processos de negócio através da composição de serviços; tratar as invocações de operações de modo síncrono ou assíncrono; invocar serviços de maneira seqüencial ou paralela. prover mecanismos para tratar erros durante a invocação de serviços; manter atividades de longa duração (transacionais), assim como interrompe-las; reiniciar uma composição que foi interrompida ou apresentou erros; agendar a execução de atividades e definir a ordem em que elas irão executar;

12 8.3. Composição de Serviços Web com WSBPEL Nesta seção, são discutidas as principais partes de uma composição de serviços definida em WS-BPEL. Num cenário típico de BPEL, um processo de negócio recebe uma requisição. Para processá-lo, a composição invoca os Web Services e finalmente responde o cliente que originou a chamada. O conhecimento profundo de WSDL e das tecnologias relacionadas é estritamente necessário durante o desenvolvimento de composição com WS-BPEL, pois a comunicação com os outros Web Services é fortemente ligada com a descrição WSDL dos mesmos. Essas relações são chamadas de ligações parceiras ou partner links. A Figura 8.8 mostra a relação entre a composição BPEL e os partner links. Figura 8.8: Comunicação entre a Composição BPEL e os Partner Links Conceitos Fundamentais de WSBPEL Os principais elementos de um documento WS-BPEL são enumerados logo abaixo e em seguia, na Listagem 8.2, será mostrado um fragmento de uma composição BPEL. import: utilizado para importar o WSDL de todos os Web Services envolvidos na composição; partnerlinks: contem uma coleção de elementos filhos partnerlink que informa a localização dos servidores onde estão disponibilizados os Web Services. Cada elemento partnerlink representa um Web Service, chamado de parceiro; variables: utilizados para armazenar as mensagens que são trocadas entre o processo BPEL e os parceiros ou para manter alguma informação durante a execução do processo; sequence: usado para definir um conjunto de atividades que serão invocadas em seqüencia;

13 flow: usado para definir um conjunto de atividades que serão invocadas em paralelo; receive: aguarda um cliente invocar o processo de negócio através do envio de uma mensagem. É o ponto de entrada da composição, ou seja, está relacionada à operação que foi definida no WSDL da composição; invoke: representa a invocação de uma operação em outro Web Service; assign: utilizada para a manipulação das variáveis; reply: usado para enviar a resposta de uma operação que foi chamada sincronamente. Listagem 8.2: Principais Elementos da Linguagem WS-BPEL 1 <?xml version="1.0" encoding="utf-8"?> 2 <process exitonstandardfault="yes" name="calculadoraservice" suppressjoinfailure="yes" targetnamespace=" br/ercemapi/calculadora"> 3 <import... /> 4 <partnerlinks> 5 <partnerlink>... </partnerlink> 6 </partnerlinks> 7 <variables> 8 <variable>... </variable> 9 </variables> 10 <sequence name="sequencial"> 11 <receive createinstance="yes" name="receiveinput" operation=" numbergeneration" partnerlink="initializer" porttype="tns: CalculadoraPortType" variable="servicerequest" /> 12 <assign>... </assign> 13 <invoke inputvariable="divisaorequest" operation="getdivisao" outputvariable="divisaoresponse" partnerlink="divisorinvoke" porttype="div:divisorserviceporttype" /> 14 </sequence> 15 <flow name="paralelo"> 16 <invoke inputvariable="multiplicacaorequest" outputvariable=" multiplicacaoresponse" operation="getmultiplicacao" partnerlink="multiplicadorinvoke" porttype="mul: MultiplicadorServicePortType"/> 17 <invoke inputvariable="geradoraleatoriorequest" outputvariable=" geradoraleatorioresponse" operation="getnumeroaleatorio" partnerlink="geradoraleatorioinvoke" porttype="gel: GeradorAleatorioServicePortType"/> 18 </flow> 19 <sequence name="respota"> 20 <reply name="replyoutput" operation="numbergeneration" partnerlink="initializer" porttype="tns:calculadoraporttype" variable="serviceresponse" /> 21 </sequence> 22 </process>

14 Caso ocorram falhas durante a execução do processo de negócio a tag <faulthandlers> deve ser utilizada para capturar falhas (eventos inesperados, erros, etc.) e tentar reverter a situação, a fim de que o trabalho seja finalizado. Em um processo de negócio, várias situações podem gerar problemas, desde a indisponibilidade momentânea de serviços até erros na própria lógica do processo. Em muitos processos de negócios, não se pode terminar toda a execução dos mesmos em uma única transação atômica, principalmente porque os processos exigem longo tempo de execução no qual várias transações processadas criam efeitos persistentes antes do processo ser completado. No WS-BPEL, a tag <compensationhandlers> reverte atividades completadas. Ele é bastante utilizado associado ao <faulthandler>, situação na qual ele possibilita que atividades já realizadas (inclusive com resultados armazenados) em um processo de negócio que apresentou algum tipo de erro em sua execução sejam canceladas e retorne ao estado inicial. Para a execução de um processo de negócio baseado no padrão WS-BPEL, é necessária a existência de um ambiente de execução específico para esta tarefa. As Engines WS-BPEL são responsáveis por disponibilizarem tal ambiente. Pode-se afirmar que a engine é o motor que executa a lógica de negócio especificada na aplicação, invocando as operações definidas pela mesma. Cada execução de um serviço composto é denominada uma instância da composição. Podem existir diversas instâncias ao mesmo tempo, e cabe também a Engine o gerenciamento dessa questão. Sob um ponto de vista arquitetural, a Engine gerencia a execução de um ou vários processos WS-BPEL. Por sua vez, os processos são compostos basicamente por atividades, que implementam a funcionalidade desejada do negócio. O foco desta Engine é a execução de processos executáveis Definição da Composição de Serviços Para demonstrar como um processo de negócio é descrito em WS-BPEL, será definido um simples processo de negócio para um sistema de empréstimo. Neste cenário o cliente requisita um empréstimo informando seu nome, CPF, valor do empréstimo e em quantidade de parcelas. O processo de negócio primeiramente verifica se o cliente já é cadastro. Supõe-se que exista um Web Service que faça está verificação. Em seguida, será verificado seu o CPF do cliente está possui alguma restrição de crédito, para isso supõe-se que existam Web Services para fazer esta consulta ao SPC e Serasa. Finalmente é feita uma análise da solicitação de empréstimo para o cliente, caso ele não tenha nenhuma restrição de crédito. Para o estudo de caso proposto foi construído um processo BPEL síncrono, para manter a simplicidade. Também foi assumido que todos os Web Services envolvidos são síncronos. A Figura 8.9 ilustra a definição da composição para o sistema de empréstimo. A composição inicia sua execução quando receba uma chamada no endpoint relativo à operação de solicitação de empréstimo, pois a composição também é um Web Service e para isso um WSDL deve ser definido. Após receber a invocação através do elemento BPEL <receive> o Web Service ClienteWS é chamado sincronamente para validar os dados do cliente, ao receber a resposta, sendo 1 para válido e 0 para inválido. Caso

15 Figura 8.9: Exemplo de Processo WS-BPEL para Solicitação de Emprestimos o cliente seja válido os Web Services SerasaWS e SPCWS são chamados paralelamente para verificar se o cliente possui alguma restrição de débito. Se não houver nenhuma restrição, o Web Service EmprestimoWS é chamado para concessão do empréstimo e, após receber o resultado, uma resposta é enviada ao cliente através do elemento <reply>. A Listagem 8.3 mostra os fragmentos mais importantes do código fonte para o estudo de caso expressa em WS-BPEL 2.0 Listagem 8.3: Processo de Negócio Empréstimo em WS-BPEL <?xml version="1.0" encoding="utf-8"?> <bpws:process exitonstandardfault="yes" name="solicitacaemprestimo" suppressjoinfailure="yes" targetnamespace=" ufpe.br">... <bpws:sequence name="main"> <bpws:receive createinstance="yes" name="recebesolicitação" operation="process" partnerlink="me" porttype="tns: SolicitacaEmprestimo" variable="input" /> <bpws:assign name="preparacpf" validate="yes">... </bpws: assign> <bpws:invoke inputvariable="validaclienterequest" name=" validacliente" operation="validacliente" outputvariable=" validaclienteresponse" partnerlink="customerinvoke" porttype ="ns:customerserviceporttype" /> <bpws:if name="clientevalido"> <bpws:flow name="flow">

16 <bpws:sequence name="verifcadebitoserasa"> <bpws:assign name="preparaserasa" validate="yes">... </ bpws:assign> <bpws:invoke inputvariable="serasainput" name=" invocaserasa" operation="possuidebito" outputvariable ="serasaoutput" partnerlink="serasainvoke" porttype=" ns0:serasaserviceporttype" /> </bpws:sequence> <bpws:sequence name="verifcadebitospc"> <bpws:assign name="preparaspc" validate="yes">... </ bpws:assign> <bpws:invoke inputvariable="spcinput" name="invocaspc" operation="possuidebito" outputvariable="spcoutput" partnerlink="spcinvoke" porttype="ns2: SPCServicePortType" /> </bpws:sequence> </bpws:flow> <bpws:condition><![cdata[$validaclienteresponse.parameters/ns: return=1]]></bpws:condition> </bpws:if> <bpws:if name="possuidebito"> <bpws:sequence name="solicitacaoemprestimo"> <bpws:invoke inputvariable="emprestimoinput" name=" invocaemprestimo" operation="validaemprestimo" outputvariable="emprestimooutput" partnerlink=" emprestimoinvoke" porttype="ns1: EmprestimoServicePortType" /> <bpws:assign name="preparaemprestimo" validate="yes">... </bpws:assign> </bpws:sequence> <bpws:condition><![cdata[$serasaoutput.parameters/ns0:return=0 and $spcoutput.parameters/ns2:return=0]]></bpws:condition > </bpws:if> <bpws:assign name="prepararesposta" validate="yes">.. </bpws: assign> <bpws:reply name="replyoutput" operation="process" partnerlink=" me" porttype="tns:solicitacaemprestimo" variable="output" /> </bpws:sequence> </bpws:process> Por fim a Figura 8.10 mostra a modelagem completa do estudo de caso Ferramentas para Composição de Serviços Nesta seção será descrito todo o ferramental existente na atualidade que trabalha com composição de serviços e com isso saberemos o que já tem sido feito e o que pode ser melhorado com relação a essas técnicas. A Figura 8.11 mostra um resumo das principais ferramentas existentes no mercado.

17 Figura 8.10: Processo de Negócio Completo Descrito em WS-BPEL JOpera Dando inicio a análise das ferramentas sobre composição de serviços vamos falar sobre o JOpera[32]. O JOpera é uma ferramenta de modelagem e execução de composição de serviços projetado como um plugin do Eclipse, que é uma plataforma de aplicações em geral. O JOpera usa uma linguagem proprietária para representar uma composição chamada JVCL (The JOpera Visual Composition Language) [10]. Esta linguagem é baseada em XML sendo considerada uma linguagem de mais alto nível em comparação com outras linguagens de descrição/execução de composições de serviço, como WS-BPEL. Ela foi projetada para não compor apenas Web Services, mas também serviços em outras tecnologias. A modelagem das composições com o JOpera é baseada em diagramas de fluxo de dados. O sistema de controle de cada atividade da composição é feito através de

18 Figura 8.11: Ferramentas Para Composição de Serviços duas construções muito simples mas igualmente poderosas presentes em cada atividade: Activation e Condition. O Activation define quais atividades são pré-requisitos para que uma atividade possa executar. Essa construção é usada para definir, entre outras coisas, condições de seqüencialidade e paralelismo entre as atividades da composição. Já a construção Condition é usada para definir quando uma atividade deve executar ou não levando em consideração o estado atual das variáveis da composição visto que os pré-requisitos definidos no Activation já foram alcançados. O Deploy e a execução de uma composição são feitos internamente à ferramenta. O JOpera não necessita de nenhum servidor Web ou de qualquer outra ferramenta para executar as suas composições. Antes de executar a composição, a JVCL é transformada em código Java para depois ser efetivamente executada pela Engine do JOpera. A Engine é interna ao JOpera. Além disso, a Engine do JOpera possui um Web Service de controle onde se pode visualizar diversas informações das composições que estão executando no momento, bem como implantar ou remover composições remotamente. As interfaces que são usadas pelo JOpera são descritas em WSDL padrão. Essa característica indica uma preocupação dos projetistas com a compatibilidade das composições criadas pelo JOpera. O JOpera possui a funcionalidade de depuração onde cada passo da composição, cada transição entre as atividades são visualizadas e a ferramenta mantém para o desenvolvedor informações sobre as variáveis envolvidas em cada operação. Outra característica dessa ferramenta é o fato de ela estar sendo sempre melhorada inclusive sendo usada para outros tipos de serviços mais específicos, como é o caso do suporte que ela fornece à GridServices [15].

19 NetBeans (Módulo BPEL) O NetBeans [6] é uma das ferramentas mais completas do mercado. Ela possui módulos para se trabalhar com uma infinidade de linguagens de programação, (Java, C/C++, Ruby, entre outros), tecnologias (Hibernate, Struts, JSF, entre outras) e com diversos tipo de aplicações. Um desses módulos é SOA. Com esse módulo a ferramenta se transforma numa plataforma para composição de Web Services. O NetBeans se encaixa no grupo de ferramentas que, a nível de modelagem da composição, fornece apenas uma interface gráfica para a linguagem em que as composições são descritas, ou seja, essa ferramenta fornece um novo tipo de visualização para uma composição em BPEL. Esse tipo de abordagem exige que o desenvolvedor da composição precise ter um conhecimento considerável da linguagem de execução em questão, no caso WS-BPEL. Para executar as composições criadas, o NetBeans já vem integrado com um Servidor de Aplicação desenvolvido pela Sun Microsystems chamado GlassFish[20]. O NetBeans possui um módulo voltado para a construção e execução de testes. Esse módulo já faz parte do NetBeans para BPEL e se baseia em ferramentas de testes de unidade, como JUnit [26], para realizar testes em composições de Web Services. Esses testes funcionam de forma parecida com os testes JUnit. O NetBeans monta uma requisição SOAP com os dados arbitrários fornecidos pelo usuário, essa requisição é então enviada para o Web Service que retorna uma resposta um XML que será analisado pela ferramenta que vai comparar com uma espécie de gabarito e assim informar se o resultado está correto ou não, fazendo assim o teste "passar"ou "falhar", respectivamente. WebRatio O WebRatio [2] é uma ferramenta que essencialmente é usada para a criação de aplicações Web (em HTML, por exemplo) e até Web Services. Mas, como na criação de Web Services ela também pode usar outros Web Services (criando assim uma composição) essa ferramenta também pode ser utilizada para composição de serviços. O WebRatio possui uma interface bem diferente das outras ferramentas. Até porque o foco dessa ferramenta é diferente. A interface sai bem da linha das ferramentas baseadas em BPEL e chega a se aproximar um pouco do JOpera por ser algo mais genérico mas, por outro lado, o grande numero de elementos que são usados apenas para a criação de Aplicações Web deixa pouco familiar para programadores de composições. A forma de estruturar a seqüência com que as operações são realizadas é feita graficamente usando setas que conectam operações que são feitas seqüencialmente. A linguagem de execução utilizada pelo WebRatio é a WebML [12]. Essa linguagem é utilizada para modelagem visual de aplicações Web, através dela e de uma série de transformações o WebRatio consegui gerar aplicações web tipicamente MVC (Model View Controller ) [3] em várias tecnologias (Java/JSP, AJAX, HTML, XHTML). O WebRatio possui um servidor Web integrado, o Apache Tomcat [13]. Com o Tomcat, o WebRatio pode implantar as aplicações que foram geradas através das transformações do WebML. Uma dos artefatos criados pelo WebRatio automaticamente é o WSDL de todas os Web Sevices que ele cria.

20 Como o foco da ferramenta é a criação de aplicações Web que não envolvem muita programação ou regras de negócio, ela não possui uma ferramenta de Debug muito bem elaborada como visto nas outras ferramentas. Oracle solucion (Oracle SOA Suite + JDeveloper) A Oracle também está interessada nesse tipo de arquitetura de software (SOA), tanto que criou um conjunto de ferramentas e aplicativos que foram concebidos para suportar esse tipo de aplicação. Esse conjunto de ferramentas "100 percent standards-based" (100% baseadas em padrões) promete ser totalmente inter-operável com infra-estruturas legadas de qualquer empresa. Esse é o Oracle SOA Suite [9], um conjunto de aplicações que dá suporte a construção, implantação e gerenciamento de composição de serviços. O JDeveloper é uma ferramenta também da Oracle, totalmente integrada com o SOA Suite, que oferece recursos para o desenvolvimento de composições de serviço utilizando um poderoso editor gráfico e que gera código BPEL para a composição. Como mencionado anteriormente, o JDeveloper tem uma poderosa e rica interface gráfica. Vale reparar as semelhanças entre os editores gráficos do JDeveloper e do NetBeans, os editores gráficos, as formas em que os componentes são dispostos no editor, as formas que eles são instanciados pelo usuário, tudo isso é muito parecido. Elas diferem mais na hora de detalhar os atributos ou funcionalidades dos componentes BPEL da composição. O NetBeans consegui ser ainda mais "gráfico"que o JDeveloper, o JDeveloper ainda contém muitas coisas que não são resolvidas graficamente, ou seja, essas coisas necessitam de um conhecimento maior da linguagem WS-BPEL. Outra semelhança com o NetBeans é que as duas ferramentas trabalham com WS- BPEL gerando código diretamente para WS-BPEL e as suas interfaces gráficas são totalmente ligadas a essa linguagem de execução. Essa ferramenta reforça mais uma vez a importância de BPEL na indústria. Mas, mais uma vez, temos uma ferramenta que não aumenta o nível de abstração em relação à linguagem de execução em que ela vai ser definida posteriormente. Todo o suporte para execução da composição criada pelo JDeveloper é dado pelo SOA Suite e suas aplicações. Dentro do SOA Suite tem, dentre outras coisas, uma Engine de execução desenvolvida pela Oracle para executar BPEL. O JDeveloper possui uma ferramenta de testes bastante interessante. Os testes são divididos em dois tipos: Unit Tests e Composite Test. Todos os dois tipos de teste são baseados no JUnit e consiste em analisar a resposta de um método através do conhecimento prévio de suas entradas. A diferença entre o Unit e o Composite Test é que no Unit Test o comportamento dos partners é apenas simulado e fazem parte dos parâmetros do teste; no caso do Composite Test os partners são realmente invocados, esse teste é uma simulação da composição no mundo real. O JDeveloper tem uma ferramenta que verifica quanto da composição é "coberta"pelos casos de teste, ou seja, quais as possibilidades que estão sendo previstas pelo engenheiro de teste.

21 ActiveVOS Designer O ActiveVOS Designer [16] é o sucessor da ferramenta Active BPEL Designer da empresa Active Endpoints. O Active BPEL Designer é uma ferramenta muito conhecida na comunidade [23]. Assim como na versão anterior, o ActiveVOS Designer é uma ferramenta que facilita a criação de uma composição apenas através de uma abstração de BPEL por uma interface gráfica.o manuseio da sua interface gráfica exige do usuário um conhecimento grande a respeito de BPEL. Diferentemente de sua antiga versão, o ActiveVOS Designer agora trabalha com uma Engine de execução BPEL externa, o ActiveVOS Server. No processo de depuração (Debug) as aplicações BPEL Designer e e BPEL Server são conectadas para prover tal funcionalidade para o usuário. Nessa nova versão foi criado um sistema de testes chamados de B-Unit (Business Unit) como uma variante do sistema de testes de unidade, JUnit. Que funciona de maneira semelhante ao JUnit onde uma entrada é fornecida à composição e a saída esperada é comparada com a saída que efetivamente é dada pela Composição. Assim como o NetBeans, essa ferramenta não possui um nível de abstração muito alto para a construção de Composição de Serviços. Não utiliza modelos. Eclipse (BPEL Project) O projeto BPEL [19] da plataforma Eclipse é um projeto ainda em fase de desenvolvimento. Hoje, ele ainda não possui arquivos binários. Só é possível executar essa ferramenta baixando o código fonte diretamente do repositório CVS (Concurrent Version System) [38] de desenvolvimento e compilá-la para depois executar. Um dos pontos fortes dessa ferramenta pretende prover é o suporte total para as especificações de WS-BPEL 2.0 [30] que é uma versão mais recente dessa linguagem de execução. Por esta em fase de construção ainda não possui algumas funcionalidades comuns entre ferramentas de composição, como, por exemplo, DEBUG. A interface gráfica dessa ferramenta é comparável com outras ferramentas, como WebRatio, funcionando apenas como um editor para BPEL.

22 Referências [1] Jorge Abilio Abinader and Rafael Dueire Lins. Web Services em Java. Brasport, 1st edition, [2] Roberto Acerbis, Aldo Bongio, Stefano Butti, Stefano Ceri, Fulvio Ciapessoni, Carlo Conserva, Piero Fraternali, and Giovanni Toffetti Carughi. WebRatio, an innovative technology for web application development. In Web Engineering, volume 3140 of Lecture Notes in Computer Science. Springer Berlin / Heidelberg, [3] Deepak Alur, Dan Malks, and John Crupi. Core J2EE Patterns: Best Practices and Design Strategies (2nd Edition). Prentice Hall PTR, 2 edition, [4] Tony Andrews, Francisco Curbera, Hitesh Dholakia, Yaron Goland, Johannes Klein, Frank Leymann, Kevin Liu, Dieter Roller, Doug Smith, Satish Thatte, Ivana Trickovic, and Sanjiva Weerawarana. Business Process Execution Language for Web Services Version 1.1. Technical report, BEA, IBM, Microsoft, SAP AG and Siebel Systems, may [5] Manu De Backer, Guido Dedene, and Jacques Vandenbulcke. Web services composition, execution and visualization. International Conference on Program Comprehension, 0:264, [6] Heiko Böck. The Definitive Guide to NetBeans Platform. Apress, [7] Boualem Benatallah, Quan Z. Sheng, and Marlon Dumas. The self-serv environment for web services composition. IEEE Internet Computing, 7(1):40 48, [8] Tim Bray, Jean Paoli, and C. M. Sperberg-McQueen. XML 1.0 recommendation. first edition of a recommendation, W3C, feb [9] Heidi Buelow, Manas Deb, Jayaram Kasi, Demed LHer, and Prasen Palvankar. Getting Started With Oracle SOA Suite 11g R1 A Hands-On Tutorial. Packt Publishing, [10] G. Alonso C. Pautasso. The JOpera Visual Composition Language. Journal of Visual Languages and Computing (JVLC), 16: , [11] Luca Cardelli and Rowan Davies. Service combinators for web computing. IEEE Transactions on Software Engineering, 25(3): ,

23 [12] Stefano Ceri, Piero Fraternali, and Aldo Bongio. Web Modeling Language (WebML): A Modeling Language for Designing Web Sites. Computer Netwwork, 33(1-6): , [13] Vivek Chopra, Sing Li, and Jeff Genender. Professional Apache Tomcat 6 (WROX Professional Guides). Wrox, 1 edition, [14] Erik Christensen, Francisco Curbera, Greg Meredith, and Sanjiva Weerawarana. Web service definition language (wsdl). Technical report, W3C, March [15] Carmela Comito, Domenico Talia, and Paolo Trunfio. Grid services: principles, implementations and use. Int. J. Web Grid Serv., 1(1):48 68, [16] Active Endpoints. Activevos designer. Available: activevos.com/products-activevos.php, [17] David C. Fallside and Priscilla Walmsley. XML schema part 0: Primer second edition. W3C recommendation, W3C, October [18] R. Fielding, J. Gettys, J. Mogul, H. Frystyk, L. Masinter, P. Leach, and T. Berners- Lee. Hypertext transfer protocol HTTP/1.1. Technical report, The Internet Society, June [19] The Eclipse Foundation. Eclipse bpel designer. [20] Antonio Goncalves. Beginning Java EE 6 Platform with Glass- Fish 3: From Novice to Professional. Apress, 1 edition, [21] William Grosso. Java RMI. O Reilly Media, Inc., 1st edition, [22] Dean Jacobs. Enterprise software as service. Queue, 3(6):36 42, [23] F.A.A. Lins, J.C. dos Santos, and N.S. Rosa. Improving Transparent Adaptability in Web Service Composition. In Proc. IEEE International Conference on Service-Oriented Computing and Applications SOCA 07, pages 80 87, [24] F.A.A. Lins, J.C. Santos Junior, and N.S. Rosa. Adaptive web service composition. SIGSOFT Softw. Eng. Notes, 32(4):6, [25] Panagiotis Louridas. Orchestrating web services with bpel. IEEE Software, 25(2):85 87,

24 [26] Vincent Massol and Ted Husted. JUnit in Action. Manning Publications, [27] Nikola Milanovic and Miroslaw Malek. Current solutions for web service composition. IEEE Internet Computing, 8(6):51 59, [28] N. Mitra. Soap version 1.2, w3c recommendation, 24 june Technical Report August 9, W3C, [29] S. Oasi. Oasis uddi specifications version 3. Technical report, OASIS, [30] OASIS. Web services business process execution language. Technical report, Organization for the Advancement of Structured Information Standards, April [31] Michael P. Papazoglou, Paolo Traverso, Schahram Dustdar, and Frank Leymann. Service-Oriented Computing Research Roadmap. Technical report, Tilburg University, Tilburg, The Netherlands, [32] Cesare Pautasso and Gustavo Alonso. Jopera: A toolkit for efficient visual composition of web services. Int. J. Electron. Commerce, 9(2): , [33] Jothy Rosenberg and David Remy. Securing Web Services with WS-Security: Demystifying WS-Security, WS-Policy, SAML, XML Signature, and XML Encryption. Sams, May [34] Poornachandra Sarang, Matjaz Juric, and Benny Mathew. Business Process Execution Language for Web Services BPEL and BPEL4WS 2nd Edition. Packt Publishing, 2nd edition, [35] Maurice ter Beek, Antonio Bucchiarone, and Stefania Gnesi. Web service composition approaches: From industrial standards to formal methods. Internet and Web Applications and Services, International Conference on, 0:15, [36] W.T. Tsai, Yinong Chen, Gary Bitter, and Dorina Miron. Introduction to Service-Oriented Computing. In IFIP International Federation for Information Processing 2004, pages , [37] Wil M.P. van der Aalst, Marlon Dumas, and Arthur H.M. ter Hofstede. Web service composition languages: Old wine in new bottles? EUROMICRO Conference, 0:298,