UNIVERSIDADE FEDERAL DO ABC PROGRAMA DE PÓS-GRADUAÇÃO EM CIÊNCIA DA COMPUTAÇÃO DISSERTAÇÃO DE MESTRADO REINALDO DE SOUZA GONZAGA UMA ABORDAGEM ARQUITETURAL PARA A ORQUESTRAÇÃO DINÂMICA DE SERVIÇOS Santo André 2014
PROGRAMA DE PÓS-GRADUAÇÃO EM CIÊNCIA DA COMPUTAÇÃO DISSERTAÇÃO DE MESTRADO REINALDO DE SOUZA GONZAGA UMA ABORDAGEM ARQUITETURAL PARA A ORQUESTRAÇÃO DINÂMICA DE SERVIÇOS Dissertação de Mestrado apresentada ao Programa de Pós-Graduação em Ciência da Computação da Universidade Federal do ABC UFABC como requisito parcial para a obtenção do Título de Mestre em Ciência da Computação. Orientadora: Prof.ª Dr.ª Fabiana Soares Santana Santo André 2014
UMA ABORDAGEM ARQUITETURAL PARA A ORQUESTRAÇÃO DINÂMICA DE SERVIÇOS Reinaldo de Souza Gonzaga Área de Concentração: Ciência da Computação Linha de Pesquisa: Arquitetura de Software Banca Examinadora: Prof.ª Dra. Fabiana Soares Santana UFABC Orientadora e Presidente Prof. Dr. Edson Pinheiro Pimentel UFABC Titular Interno Prof. Dr. Pedro Luiz Pizzigatti Corrêa POLI-USP Titular Externo Prof. Dr. Luiz Carlos da Silva Rozante UFABC Suplente Interno Prof.ª Dra Anarosa Alves Franco Brandão POLI-USP Suplente Externo
Este exemplar foi revisado e alterado em relação à versão original, de acordo com as observações levantadas pela banca no dia da defesa, sob responsabilidade única do autor e com a anuência de seu orientador. Santo André, de de 20. Assinatura do autor: Assinatura do orientador:
FICHA CATALOGRÁFICA Gonzaga, Reinaldo de Souza. UMA ABORDAGEM ARQUITETURAL PARA A ORQUESTRAÇÃO DINÂMICA DE SERVIÇOS. Gonzaga, R. S. -- Santo André, 2014. 48 p. DISSERTAÇÃO DE MESTRADO - Centro de Matemática, Computação e Cognição, Universidade Federal do ABC. 1.Arquitetura de Software; 2. Arquiteturas Orientadas a Serviço; 3. Orquestração Dinâmica de Serviços. I. Universidade Federal do ABC; II. Centro de Matemática, Computação e Cognição.
Agradecimentos A todas as pessoas que direta ou indiretamente foram impactadas pela minha ausência no convívio social, mas que compreenderam que o motivo era justo e necessário. À Fabiana, que consegue a incrível proeza de ser mais boazinha do que minha avó. Sua paciência e disponibilidade para me ajudar desmitificaram o conceito que eu tinha de um orientador antes de iniciar o mestrado. Aos amigos e chefes do trabalho, que permitiram a minha ausência em diversas ocasiões.
Resumo A arquitetura orientada a serviços (SOA Service Oriented Architecture) é um paradigma amplamente utilizado na engenharia de software para prover soluções de software reutilizáveis e integráveis baseadas em serviços. O barramento de serviços (ESB Enterprise Service Bus) é uma das estruturas mais importantes para as soluções baseadas em SOA, pois é responsável por conectar e intermediar todas as comunicações entre aplicações e serviços. A seleção dinâmica de serviços é um problema complexo e a grande maioria das soluções existentes são eficazes somente quando atendidas premissas para os serviços que não condizem com a realidade dos padrões de especificação de serviços existentes. Este trabalho apresenta uma proposta de solução arquitetural para incorporar a seleção dinâmica de serviços aos ESBs e permitir a incorporação das diversas soluções para seleção dinâmica de serviços propostas sem alterar os atuais padrões de serviços. Além da nova proposta arquitetural, o trabalho apresenta os resultados de um estudo de caso onde a proposta arquitetural foi incorporada ao Mule ESB, no qual um algoritmo para seleção de serviços baseado em tabelas de decisão adaptativas foi desenvolvido e inserido. Os resultados obtidos nos testes com a solução implementada foram promissores. Palavras-chave: Seleção dinâmica de serviços, SOA, ESB.
Abstract Service oriented architecture (SOA) is a widely applied paradigm in software engineering to provide reusable and integrable software solutions based on services. The Enterprise Service Bus (ESB) is one of the most important structures for SOA-based solutions because it is responsible for connecting and mediating all communication between applications and services. Dynamic service selection is a complex problem and most existing solutions to it are effective only when met assumptions for services that do not match the reality of the standards defined for the existing services. This work presents an architectural proposal to embed dynamic selection of services into ESBs to allow the incorporation of the various solutions proposed for dynamic service selection without changing the current services standards. In addition to the new architectural proposal, the work presents the results of a case study where the architectural proposal was incorporated into the Mule ESB and an algorithm for dynamic service selection based on adaptive decision tables was developed and implemented. The results with the implemented solution were promising. Keywords: Dynamic service selection, SOA, ESB.
Sumário Lista de Figuras... 12 Lista de Tabelas... 13 Lista de Siglas... 14 1 Introdução... 15 1.1 Descrição do problema... 17 1.2 Objetivos... 18 1.2.1. Objetivo Geral... 18 1.2.2. Objetivos Específicos... 18 1.3 Metodologia... 18 2 Revisão Bibliográfica... 21 2.1 Arquitetura de Software... 21 2.2 Arquitetura Orientada a Serviços (SOA)... 22 2.3 ESB (Enterprise Service Bus)... 26 2.4 Trabalhos Relacionados... 29 3 Proposta Arquitetural para o Barramento de Serviços... 34 3.1 Algoritmo para Seleção de Serviços... 34 3.2 Proposta Arquitetural de Alteração do ESB... 37 4 Estudo de Caso: Implementação da Solução Proposta aplicando Algoritmo Baseado em Tabelas de Decisão Adaptativas... 40 4.1 Implementação da Solução Proposta... 40 4.2 Execução e Testes da Solução... 45 4.2.1. Teste de Sucesso... 47
4.2.2. Teste de Tempo de Resposta... 50 4.2.3. Teste de Indisponibilidade... 52 5 Conclusão... 56 Referências Bibliográficas... 57 Apêndice A... 61
Lista de Figuras Figura 1: Evolução dos paradigmas de arquitetura... 22 Figura 2: Fluxo de uma arquitetura SOA... 23 Figura 3: Etapas para aplicação de SOA... 26 Figura 4: Entreprise Service Bus... 27 Figura 5: Estrutura interna de um ESB... 28 Figura 6: Fluxo de integração através do ESB... 29 Figura 7: Exemplo de consulta utilizando linguagem SWSQL... 31 Figura 8: Proposta de solução arquitetural... 39 Figura 9: Desenvolvimento do ESB... 41 Figura 10: Arquivo com metadados dos serviços disponíveis... 43 Figura 11: Web Services utilizados... 46 Figura 12: Trecho de código executado pelos Web Services... 46 Figura 13: Aplicação cliente... 47 Figura 14: Aplicação cliente... 48 Figura 15: Classificação e status dos serviços disponíveis... 49 Figura 16: Resultado na aplicação cliente... 49 Figura 17: Aplicação cliente... 50 Figura 18: Classificação e status dos serviços disponíveis... 51 Figura 19: Classificação e status dos serviços disponíveis... 52 Figura 20: Resultado na aplicação cliente... 52 Figura 21: Aplicação cliente... 53 Figura 22: Classificação e status dos serviços disponíveis... 53 Figura 23: Classificação e status dos serviços disponíveis... 54 Figura 24: Resultado na aplicação cliente... 55
Lista de Tabelas Tabela 1: Tabela de decisão adaptativa... 35 Tabela 2: Algoritmo de seleção dinâmica... 36 Tabela 3: Exemplo de variáveis de qualidade de serviços... 36 Tabela 4: Exemplo de tabela de decisão adaptativa preenchida... 37
Lista de Siglas ESB FTP HTTP IEEE JDBC MOM OWL POP3 QOS REST SMTP SOA SOAP SOC TCP TI UDDI UDP UMO Enterprise Service Bus File Transfer Protocol Hypertext Transfer Protocol Instituto de Engenheiros Eletricistas e Eletrônicos Java Database Connectivity Message Oriented Middleware Web Ontology Language Post Office Protocol Quality of service Representational state transfer Simple Mail Transfer Protocol Service Oriented Architecture Simple Object Access Protocol Service Oriented Computing Transmission Control Protocol Tecnologia da Informação Universal Description, Discovery and Integration User Datagram Protocol Universal Message Object
15 1 Introdução A constante evolução do hardware tem disponibilizado um grande poder computacional para as aplicações de software. Entretanto, para que as aplicações de software consigam usufruir adequadamente deste poder computacional, é necessário aumentar a produtividade de software (FOX; PATTERSON, 2012). As linguagens de programação de alto nível, a criação de sintaxes mais simples e intuitivas e o uso de ferramentas e ambientes para automatizar o desenvolvimento de software, dentre outros, são alternativas para aumentar a produtividade, pois transferem grande parte dos processos manuais e repetitivos do desenvolvedor para o computador. Dentre os processos de aumento de produtividade no desenvolvimento de software, o reuso é um conceito fundamental (GRISS, 1997). O reuso pode ser aplicado ao código, à arquitetura e também aos processos relacionados ao desenvolvimento de software. Paradigmas como programação orientada a objetos e computação orientada a serviços podem trazer ganhos significativos para a produtividade através do reuso e da integração de componentes (FOX; PATTERSON, 2012). A evolução dos paradigmas arquiteturais tem se apresentado como um dos principais conceitos em discussões sobre como a computação pode suportar o desenvolvimento, o controle e a gestão de negócios. O valor dos projetos de integração de uma empresa ou organização é diretamente proporcional à sua complexidade (BASS, CLEMENTS e KAZMAN, 2003), ou seja, quanto mais abrangente e complexo tornam-se os softwares de uma organização, maior é a dificuldade e o trabalho para a organização de seus componentes. Organizações deparam-se diariamente com a necessidade de maximizar o uso de seus recursos e, consequentemente, existe uma grande expectativa em torno da redução de custos associados ao desenvolvimento e aquisição de software (ENDREI et al. 2004). Além da redução de custos, os critérios para avaliar a evolução dos paradigmas arquiteturais compreendem a facilidade para a manutenção dos sistemas corporativos, as melhorias na escalabilidade dos sistemas, o potencial de reuso e a capacidade de integração e
16 interoperabilidade. O paradigma computacional orientado a serviços (SOC Service Oriented Computing) permite a execução de transações através de diversas plataformas, provendo a interoperabilidade de software. Arquitetura orientada a serviços (SOA Service Oriented Architecture) é um paradigma arquitetural para SOC (HUHNS; SINGH, 2005). A adoção de SOA geralmente requer um grande esforço financeiro e computacional. Entretanto, os custos com o desenvolvimento das aplicações tendem a diminuir ao longo do tempo, devido à aplicação de reuso em larga escala, inclusive de sistemas legados (ENDREI et al. 2004) (MACKENZIE et al., 2006). Apesar dos benefícios proporcionados pela arquitetura de software baseada em serviços, existem também problemas que surgem com a sua adoção. A maioria destes problemas está relacionada à gestão e orquestração dos serviços e à sua qualidade. A orquestração de serviços trata da execução de processos de negócio definidos a partir da interação entre serviços computacionais internos e externos ao ambiente empresarial (PELTZ, 2003). A qualidade dos serviços (QoS Quality of Service) pode ser representada por variáveis como disponibilidade, segurança, tempo de resposta e tempo de processamento, entre outros (LIU et al., 2004; MENASCÉ, 2002). A gestão e orquestração de serviços em aplicações baseadas em SOA podem ser realizadas através de uma solução conhecida como barramento de serviços (ESB Enterprise Service Bus). Alguns dos aspectos mais relevantes que um ESB deve prover são a seleção e execução de serviços de forma automática (CASATI et al., 2004). Em uma solução baseada em serviços, pode existir mais de uma opção de serviços, providos por provedores diferentes, que executam a mesma funcionalidade. Dessa forma, seria possível efetuar a seleção de serviços de maneira dinâmica, ou seja, em tempo de execução; e não através de serviços pré-definidos na fase de desenvolvimento da aplicação. Diversas técnicas podem ser aplicadas para a escolha de um serviço ou conjunto de serviços a partir de uma lista de serviços existentes para a mesma funcionalidade. Porém, é importante notar que muitas variáveis que aferem a qualidade dos serviços podem sofrer alterações com o tempo, o que pode afetar o seu desempenho e, por consequência, o desempenho da aplicação (SANTANA et al., 2009). Diversas propostas para a seleção dinâmica de serviços foram apresentadas (SHAIKHALI et al., 2003; SCHMIDT et al., 2005; YU; REIFF-MARGANIEC, 2008; DUJMOVIC, 1973; YAGER, 1988; TOMA et al., 2007; PATHAK et al., 2005; LIN et al., 2004; SOYDAN BILGIN; SINGH, 2004; CAVERLEE et al., 2004; FENG et al., 2007;
17 SANTANA et al., 2009b; YANG et al., 2005; CASATI et al., 2004; MATAI; HAN, 2007. A partir da análise das propostas apresentadas, pode-se notar que, além de não existir um padrão entre elas, adotam premissas para o seu funcionamento que não estão presentes nas especificações de serviços existentes. Por exemplo, os algoritmos propostos nas soluções estudadas pressupõem a existência de atributos de qualidade de serviço que não fazem parte da especificação padrão de web services, ou seja, esses algoritmos estão baseados em informações não disponíveis para a maioria dos serviços disponíveis na Internet e apenas uma mudança nos padrões atuais permitiria a adoção dessas soluções. Da mesma forma, os ESBs não estão preparados para implementar essas soluções. Para se obter uma solução mais abrangente e genérica para o problema da seleção dinâmica de serviços, é preciso ou redefinir os padrões para publicação de serviços na Internet ou prover uma alteração na arquitetura dos ESBs para que a seleção de serviços possa ser feita com base em informações armazenadas ou inferidas localmente sobre os serviços utilizados. Dessa forma, a implementação das soluções propostas para a seleção dinâmica de serviços se torna viável e os ESBs podem fazer a seleção dinâmica de serviços de forma independente e mais eficiente. 1.1 Descrição do problema Durante a análise dos problemas existentes relacionados com a infraestrutura e com as aplicações para soluções orientadas a serviços, foi observado que o ranqueamento e a seleção dinâmica de serviços são áreas de pesquisa que ainda não estão devidamente contempladas pelas ferramentas ou propostas disponíveis. O ranqueamento e a seleção dinâmica de serviços se aplicam principalmente aos casos em que existem diversos provedores de serviços que oferecem a mesma competência. Nesses casos, variáveis como tempo de resposta, tempo de execução do serviço, disponibilidade, confiabilidade e custo do serviço devem ser consideradas para definir qual dos serviços providos deve ser utilizado (BERANDER et al., 2005; FENG et al., 2007). A orquestração de serviços pode ser feita de forma dinâmica, decidindo e selecionando o serviço a ser utilizado no momento de sua instanciação. Iniciativas para a seleção e orquestração dinâmica de serviços foram apresentadas, envolvendo áreas de pesquisa que variam de ontologias a algoritmos em grafos, mas estas
18 iniciativas se restringem a soluções algorítmicas que consideram determinadas hipóteses sobre os serviços que não são válidas universalmente. Por exemplo, existem hipóteses sobre a descrição dos serviços usando ontologias e sobre os atributos de qualidade, que infelizmente ainda não são a realidade da maioria dos serviços registrados disponíveis no mercado e, como ainda não fazem parte de nenhum padrão definido pelo W3C [http://www.w3.org/] ou equivalente, talvez nunca sejam incorporados aos web services. 1.2 Objetivos 1.2.1. Objetivo Geral Este trabalho tem como objetivo principal propor uma solução arquitetural para incorporar a seleção dinâmica de serviços aos ESBs disponíveis no mercado. 1.2.2. Objetivos Específicos Implementar a solução arquitetural proposta em um ESB de mercado. Incorporar o algoritmo de seleção baseado em tabelas de decisão adaptativas (SANTANA et al., 2009b) na solução implementada. Permitir, a partir da solução proposta, que diversos algoritmos possam ser incorporados aos ESBs através da mesma solução arquitetural, tornando-os mais flexíveis e eficientes do ponto de vista da seleção dinâmica de serviços. Executar uma série de experimentos com a solução implementada, para avaliar o comportamento da orquestração de serviços pelo ESB. 1.3 Metodologia Segundo os conceitos propostos por Silva e Menezes (2005), este trabalho está classificado da seguinte forma: Quanto à natureza do trabalho: Aplicado, pois é destinado a uma aplicação prática
19 para orquestração dinâmica de serviços. Quanto à forma de abordagem: Qualitativa, pois a abordagem proposta não utiliza modelos quantitativos na sua analise e desenvolvimento. Quanto aos objetivos do trabalho: Exploratório, pois consiste em levantamento bibliográfico sobre o tema seguido de uma proposta de abordagem e implementação. Quanto aos procedimentos técnicos: Experimental, pois determina um objeto de estudo, selecionando as principais variáveis que o influenciam e definindo as formas de controle e de observação dos efeitos que estas variáveis exercem no objeto. A partir da classificação definida acima, a metodologia adotada e que gerou este trabalho seguiu as seguintes etapas: 1. Revisão bibliográfica da literatura relacionada, incluindo livros, artigos de conferências, periódicos e especificações. O conteúdo detalhado desta etapa está descrito no capítulo 02. Além da bibliografia baseada em livros dos principais autores sobre o tema, foram também pesquisados sites de artigos científicos e anais relacionados ao tema para uma exposição mais atual sobre o estado da arte em torno do assunto. 2. Análise de trabalhos relacionados ao problema abordado. 3. Estudo de tecnologias: XML, Web Services, SOAP, WSDL. Para desenvolver formas de se seleção dinâmica de serviços. Java. Para desenvolvimento de componentes arquiteturais e da camada lógica de Web Services. Ferramentas disponíveis no mercado para barramento de serviços (ESB). 4. Projeto de uma solução para o problema estudado. 5. Implementação da solução proposta e projetada, através de um estudo de caso prático. 6. Preparação de ambientes e cenários para testar a solução implementada. 7. Testes com a solução desenvolvida. 8. Avaliação dos resultados obtidos. 9. Elaboração da dissertação. Para o desenvolvimento das aplicações foram utilizadas as seguintes ferramentas: 1. MuleSoft - Versão 3.4
20 Ferramenta ESB open source para integração de aplicações e orquestração de serviços em arquiteturas SOA. 2. NetBeans IDE - Versão 7.4 Ferramenta de código-fonte aberto para desenvolvimento de aplicações Java web, desktop e móveis. O trabalho está organizado da seguinte maneira: O capitulo 1 apresenta uma introdução apresentando a descrição do problema abordado, a justificativa e os objetivos deste trabalho. O capitulo 2 apresenta uma revisão bibliográfica sobre os conceitos necessários para o desenvolvimento do trabalho. Entre eles, estão conceitos sobre arquitetura de software orientada a serviços e barramento de serviços, além de uma seção que discute trabalhos relacionados à seleção dinâmica de serviços. O capitulo 3 apresenta a proposta para a solução do problema de orquestração dinâmica de serviços e o estudo de caso desenvolvido para ilustrar a aplicação e teste da solução proposta. Por fim, o capitulo 4 apresenta as conclusões do trabalho bem como possíveis trabalhos futuros relacionados ao tema.
21 2 Revisão Bibliográfica Neste capítulo são apresentados os principais conceitos presentes na literatura relacionados à arquitetura de software, arquitetura orientada a serviços e barramento de serviços, além de uma revisão bibliográfica das soluções propostas para a orquestração dinâmica de serviços. 2.1 Arquitetura de Software Arquitetura de um software é o conjunto de estruturas compostas pelos elementos de software, suas propriedades externamente visíveis e o relacionamento entre eles. Ela também pode ser entendida como a abstração das informações presentes nos elementos que compõem o software e que não estão diretamente relacionados com a sua interação com os demais elementos (BASS et al., 2003). Padrão arquitetural é a descrição dos elementos de uma arquitetura, seus relacionamentos e suas restrições. Um modelo de referência em arquitetura de software estipula um padrão de decomposição de um problema conhecido em partes menores, as quais devem resolver o problema de forma cooperativa. Arquitetura de referência é o mapeamento do modelo de referência sobre os elementos de software, que implementam as funcionalidades definidas no modelo de referência de maneira cooperativa. Padrões arquiteturais, modelos de referência e arquiteturas de referência não são arquiteturas, mas sim conceitos que capturam os elementos de uma arquitetura de software (SANTANA, 2009). A orientação a serviços é recomendada principalmente para sistemas que apresentem fortes requisitos de interoperabilidade e integração, especialmente no caso de integração de aplicações desenvolvidas com tecnologias diferentes, uma vez que os serviços podem ser expandidos e integrados conforme a necessidade.
22 O desenvolvimento de aplicações baseadas em SOC (Service Oriented Computing) permite a integração de serviços disponibilizados por provedores distribuídos em todo o mundo. Logo, as aplicações podem ser projetadas baseadas em processos de negócios, que representam as etapas para solucionar o problema computacional. Durante a execução de um processo de negócio, é possível integrar diversos e diferentes sistemas, disponíveis em diferentes provedores, e as etapas do processo podem ser providas por provedores internos ou externos (SANTANA et al., 2009). A evolução do ambiente corporativo exigiu ao longo do tempo também uma evolução dos paradigmas arquiteturais existentes. Necessidades como flexibilidade e agilidade no atendimento de requisitos de negócio e facilidade na integração de diferentes aplicações e sistemas de maneira financeiramente viavel para o negócio refletiram nos paradigmas arquiteturais, que por sua vez, evoluiram para adaptar-se às necessidades do cenario teconológico atual. A figura 1 demonstra esta evolução ocorrida na linha do tempo, partindo do paradigma de arquitetura monolítico, no qual toda a aplicação era desenvolvida em um único bloco, contendo base de dados, interface do usuário, lógica de negócios, etc; evoluindo para outros modelos como cliente servidor; 3 camadas, nas quais há separação entre as camadas de dados, lógica de negócios e interface com os usuários; até chegar a uma arquitetura baseada em serviços, tida como mais evoluida comparada as anteriores, uma vez que atende requisitos como facilidade de reuso, integração, manutenção, dentre outros. Monolítico Estruturado Cliente Servidor 3 Camadas N Camadas Serviços Figura 1: Evolução dos paradigmas de arquitetura 2.2 Arquitetura Orientada a Serviços (SOA) SOA (Service Oriented Architecture) é um paradigma de arquitetura relacionado ao conceito de computação orientada a serviços (HUHNS; SINGH, 2005), que tem sido amplamente adotado em projetos de desenvolvimento de softwares com o objetivo de tornálos reutilizáveis e com alta capacidade de integração (MACKENZIE et al., 2006).
23 Em uma arquitetura SOA, os componentes de software são denominados serviços e são providos geralmente em repositórios centrais, onde podem ser consultados e consumidos (STAL, 2002). SOA geralmente faz uso de web services para disponibilização e utilização de serviços. Neste padrão de arquitetura, um web service é um serviço que pode ser identificado e acessado através de uma URI (Uniform Resource Indentifier) específica na web. A iteração entre web services geralmente utiliza as tecnologias SOAP (Simple Object Access Protocol), XML (extensible Markup Language) e WSDL (Web Services Description Language), que é responsável pela descrição do serviço (PAPAZOGLOU, 2007). Os serviços providos através de web services, bem como suas respectivas descrições, podem ser armazenados nos repositórios conhecidos como UDDI, onde podem ser consultados e consequentemente consumidos. A Figura 2 exemplifica o fluxo dos conceitos de uma arquitetura baseada em serviços, onde podemos visualizar um provedor de serviços, que registra seus serviços em um repositório central. As aplicações consumidoras de serviços podem então consultar estes repositórios para descobrir serviços disponíveis e informações de como se conectar a um provedor de serviços específico. Uma vez determinado o provedor, a aplicação consumidora pode então obter a descrição do serviço que especifica como o serviço pode ser utilizado. Repositório de Serviços Consumidores de Serviços Provedores de Serviços Figura 2: Fluxo de uma arquitetura SOA Aplicações SOA compostas por componentes de serviço associam interfaces de serviços e lógica de negócios em um modelo conceitual único, tornando possível a extensão, especialização e criação de novas aplicações (PAPAZOGLOU, 2007). Conforme explanado anteriormente, tecnologias orientadas a serviços propiciam diversos benefícios aos cenários tecnológicos atuais das organizações. Como algumas destas
24 vantagens é possível citar: Encapsulamento SOA provê uma camada de abstração que possibilita ao negócio encapsular seus sistemas legado através de serviços, que permite continuar a utilização destes recursos sem a necessidade de reconstruí-los do zero. Isolamento da complexidade do desenvolvimento Em uma arquitetura baseada em serviços, a integração e interface para o desenvolvimento é baseado em torno da especificação do serviço. Isto provê transparência no desenvolvimento do serviço e minimiza impactos em casos de alterações de infraestrutura e implementações, ou seja, disponibilizando às demais camadas envolvidas no sistema uma interface de comunicação definida através da especificação dos serviços, é possível isolar a parte complexa do desenvolvimento. Agilidade de desenvolvimento A capacidade de aproveitamento de componentes e serviços reduz o tempo de desenvolvimento existente no ciclo de vida de novas aplicações, permitindo ao negócio um menor tempo entre a análise de um produto e sua disponibilização no mercado. Redução de custos e aumento de reuso A flexibilidade proporcionada pelo desenvolvimento orientado a serviços resulta em menor duplicação de recursos, maior potencial de reuso e consequentemente uma maior redução de custos. Entretanto, arquitetura orientada a serviços não é uma bala de prata para todos os problemas existentes no desenvolvimento de softwares. Além disto, a migração para SOA não é uma tarefa fácil, sendo recomendada uma abordagem de migração ou adoção em etapas. Aplicações SOA compostas por componentes de serviço associam interfaces de serviços e lógica de negócios em um modelo conceitual único, tornando possível a extensão, especialização e criação de novas aplicações (PAPAZOGLOU, 2007). Uma abordagem prática para SOA é apresentada por (ENDREI et al. 2004), através de um método composto por sete etapas que descrevem as principais atividades necessárias para a implementação de uma solução baseada em SOA. A Figura 3, extraída de Endrei et al. (2004), ilustra estas etapas. A primeira etapa é responsável pela decomposição do problema através de áreas funcionais, as quais são decompostas em processos e subprocessos de negócios para
25 identificação de casos de uso que são potencias candidatos a serviços. A próxima etapa (que está diretamente ligada a primeira e por isto identificada como etapa 1b na figura) é responsável pelo mapeamento e interação com os sistemas legados. Na segunda etapa, deve ser feita a construção do modelo de serviços. A etapa três corresponde à analise dos subsistemas, onde deve ser feito o refinamento dos casos de uso, analisando o fluxo do processo de todos os subsistemas com o intuito de identificar potenciais candidatos a componentes de negócio e suas funcionalidades. A quarta etapa é onde deve ser feita a alocação dos serviços, definindo em que componente o serviço será implementado. Na etapa cinco, deve ser elaborada a especificação dos componentes que estão no escopo do projeto, bem como seus serviços, regras, atributos e dependências. Na sexta etapa, os componentes especificados até o momento devem ser estruturados através da adoção de padrões arquiteturais. Na etapa sete deve ser executado o mapeamento tecnológico, onde são definidas as estratégias para implementação dos componentes e serviços.
26 1A Identificação do Domínio 3 Análise dos Sub Sistemas Modelo de Serviços 2 Componentes dos Sistemas Legados 1B 4 Alocação dos Serviços 5 Especificação dos Componentes Estruturação baseada nos padrões arquiteturais 6 Repositório de Componentes de Serviços 7 Mapeamento Tecnológico Repositório de Serviços Figura 3: Etapas para aplicação de SOA Uma arquitetura SOA facilita a gestão de sistemas corporativos, melhorando a escalabilidade e reduzindo custos através da colaboração e reuso de soluções (MACKENZIE et al., 2006). 2.3 ESB (Enterprise Service Bus) O cenário tecnológico atual da maioria das organizações é composto por centenas de aplicações, as quais muitas vezes são constituídas por diferentes tecnologias. Entretanto, para atender as necessidades de negócio destas organizações, deveria ser possível que suas aplicações operassem de maneira integrada. A implementação de uma solução baseada em SOA para estes cenários requer uma estrutura para gerenciar serviços (CHAPPELL, 2004;
27 MENGE, 2007), conhecida como Barramento Empresarial de Serviços ou Enterprise Service Bus, ESB. Conforme ilustrado na Figura 4, um barramento de serviços funciona como um middleware que conecta e intermedia todas as comunicações entre consumidores e provedores de serviços, servidores de banco de dados, servidores de aplicações, sistemas legados, servidores de email e sistemas cliente, entre outros. Figura 4: Entreprise Service Bus Existem diferentes definições formais para o conceito de ESB na literatura. Segundo (MENGE, 2007), ESB é um padrão de infraestrutura de integração distribuído e baseado em mensagens, ou seja, utiliza-se o conceito conhecido como MOM (Message-Oriented Middleware) para gerenciar as aplicações conectadas a ele através de mensagens assíncronas. ESBs são normalmente constituídos por estruturas conhecidas como containers de serviços distribuídos através de um ambiente de rede. Conforme podemos visualizar na Figura 5, adaptada de Menge (2007), containers são disponibilizados no barramento de mensagens armazenando componentes de integração como roteadores, transmissores, adaptadores de aplicações, entre outros mecanismos de comunicação. As aplicações são conectadas ao barramento através de adaptadores ou outros mecanismos que implementem o conceito de mensagens como MOM.
28 Barramento de Menssagens Container Adaptador de Aplicação Aplicação Figura 5: Estrutura interna de um ESB Um ESB deve possuir características e funcionalidades específicas, como manipulação de requisições, roteamento, mediação entre aplicações e serviços, adaptadores para aplicações de diferentes tecnologias, mecanismos de segurança, ferramentas para gestão da infraestrutura de integração, orquestração de processos, manipulador de eventos gerados pelos sistemas envolvidos e, em alguns casos, um ambiente de desenvolvimento e testes (MENGE, 2007). Existem diversas soluções de ESB disponíveis no mercado. Algumas delas são desenvolvidas e mantidas por organizações privadas, enquanto outras são soluções de software livre. O Mule ESB é um ESB de código aberto muito utilizado para integração de aplicações de software baseadas em serviço. Ele utiliza o conceito de container de serviços, além de possuir uma grande variedade de mecanismos de comunicação suportados, como SOAP, REST, HTTP, FTP, TCP, UDP, SMTP, POP3 e JDBC, entre outros (MULESOFT, 2014). O conceito de integração baseado em containers é altamente modular no Mule ESB (MULESOFT, 2014), o que permite que implementações com a sua estrutura consistam basicamente de múltiplas instancias de componentes do barramento, as quais são distribuídas através de uma rede e interconectadas através de algum dos mecanismos de comunicação suportados pela ferramenta. O Mule ESB provê todos os serviços de integração que são essenciais a um ESB, incluindo a orquestração de serviços a partir de processos de negócio descritos em WS-BPEL
29 (Web Services Business Process Execution Language). Um exemplo de componentes envolvidos no fluxo executado pela arquitetura do Mule ESB durante o envio de uma mensagem entre duas aplicações pode ser visualizado na Figura 6. A figura apresenta a sequencia padrão de estruturas pelas quais transitam as mensagens entre duas aplicações como transportadores de mensagem, roteadores, componentes de manipulação, dentre outros. A mensagem é trafegada e roteada através do barramento e, após ser manipulada e transformada por um componente, é enviada ao roteador de saída que também pode executar operações de manipulação e transformação antes de entregar a mensagem à aplicação destino (MENGE, 2007) (MULESOFT). A transformação realizada pelo componente pode ser, por exemplo, a execução das regras de negócio sobre a mensagem recebida. Transportador Roteador de Entrada Componente Roteador de Saída Transportador Figura 6: Fluxo de integração através do ESB O Mule ESB é um ESB de código aberto e baseado em Java, que permite aos desenvolvedores conectar aplicações de diferentes tecnologias de maneira eficiente. Por essas características e por atender a todos os requisitos necessários para um ESB padrão de mercado em termos arquiteturais e práticos, o Mule ESB foi escolhido para o desenvolvimento do estudo de caso que será apresentado nesse trabalho. 2.4 Trabalhos Relacionados De acordo com O Reilly (2005), a Web 2.0 deve promover o uso da web como uma plataforma onde os serviços substituem os tradicionais pacotes de software com maior eficiência em termos de escalabilidade e custo. Já a Web 3.0 (HENDLER, 2009) deve incorporar conceitos de web semântica, principalmente com base no uso de RDF (Resource Description Framework) e de OWL (Web Ontology Language) (BERNERS-LEE et al.,
30 2001). Nesse cenário, onde existe a possibilidade de existir diversos serviços para prover a mesma funcionalidade com atributos de qualidade similares, a seleção dinâmica de serviços merece destaque e o assunto que tem sido estudado mesmo antes de surgirem as propostas concretas para a Web 2.0 e 3.0. Dentre os principais trabalhos que tratam da seleção dinâmica de serviços, merecem destaque: 1. (SHAIKHALI et al., 2003) propõe em seu trabalho uma alteração dos UDDIs atuais de maneira a incorporar neles funcionalidades que possibilitam especificar o período de tempo que a descrição de um serviço deve permanecer no repositório. Incluir no repositório áreas privadas para armazenar descrições de partes ou métodos dos serviços que por segurança ou outros motivos e necessidades não devem ser disponibilizados na mesma área onde estão publicadas as demais informações dos serviços. Adicionalmente na configuração dos UDDIs são implementadas propriedades para descrever e armazenar informações como variáveis de qualidade de serviços (QoS), dentre outras. Estes UDDIs modificados proveriam também uma interface com métodos que possibilitariam executar ações no repositório como armazenar serviços, localizar serviços, obter detalhes do serviço, definir o período em que o serviço deve ficar disponível no repositório dentre outros. A seleção de serviços é pré-processada por uma estrutura chamada pelo autor de QoS Broker fora do UDDI através de algoritmos baseados em média. 2. A ideia central do trabalho apresentado por (SOYDAN BILGIN; SINGH, 2004) é prover uma nova linguagem chamada SWSQL (Semantic Web services Query and Manipulation Language) utilizada pelos provedores e consumidores de serviços para efetuar inserções, modificações e consultas de variáveis de qualidade e descrição de serviços. A SWSQL é baseada em ontologias e no conceito de modelo de dados relacional. Neste contexto, os serviços são identificados nos repositórios através de um identificador e os valores de suas variáveis de qualidade identificados através de uma tabela relacional contendo tuplas formadas por este identificador e pelas ontologias, onde são armazenadas as informações das variáveis de serviços.
31 A Figura 7 demonstra um exemplo de consulta utilizando alguns elementos da sintaxe da linguagem SWSQL. Nela procura-se o identificador do serviço (servicekey) dentre todos os serviços deste domínio com a variável rangeofcars com valor igual a média (Averange). Conforme é possível notar na sintaxe, as variáveis utilizadas para efetuar a consulta e que consequentemente armazenam as informações dos serviços são especificadas através de elementos da linguagem DAML (DARPA Agent Markup Language), que é precursora do OWL e, portanto, também consideram que o repositório de serviços foi construído com base em ontologias e conceitos de qualidade de serviços para a construção do algoritmo. Figura 7: Exemplo de consulta utilizando linguagem SWSQL 3. (CAVERLEE et al., 2004) baseia seu trabalho em três passos: analise de tendências para possíveis origens da localização de serviços; analise e classificação do conjunto de serviços obtidos no passo anterior; aproveitamento dos resultados para obter relacionamentos relevantes. No primeiro passo, a partir de técnicas probabilísticas aplicadas sobre uma base sumarizadas de informações sobre serviços disponíveis, obtém-se uma série de prováveis serviços tidos como aptos para a utilização. Uma vez definido um conjunto de prováveis serviços, utiliza-se um mecanismo, também baseado em probabilidade e tendências, para definir uma classificação entre os elementos
32 deste conjunto. A terceira e última etapa do processo adotado neste trabalho utiliza conceitos de mineração e classificação de dados para inferir relacionamentos entre serviços similares gerando com isto, informações de similaridade e relacionamento para serem utilizados como base para futuras pesquisas. 4. (YU; REIFF-MARGANIEC, 2008) apresenta em seu trabalho uma série de propriedades presentes nos serviços, tidas como não funcionais, e discute como as abordagens atuais de descrição e seleção de serviços utilizam estas propriedades. Segundo ele, diversas abordagens apresentam propostas viáveis para efetuar a seleção de serviços baseada nestes atributos, entretanto, todas requerem premissas como extensões dos repositórios existentes ou algoritmos de seleção baseados em web semântica. Contudo, conclui em seu trabalho que todas as abordagens utilizadas baseiam-se em semânticas através de ontologias. 5. (SHIREESHA, 2013) propõe uma alteração no repositório (UDDI) para que o mesmo exerça a função de unidade central na seleção de serviços. Este repositório possui internamente as funções de processamento, coleta e armazenamento de informações sobre os serviços nele descritos. O repositório é suprido de feedbacks emitidos pelos atuais consumidores dos serviços com suas respectivas variáveis de qualidade (QoS), que por sua vez são utilizados na etapa de processamento. Nesta etapa, é aplicado o seguinte algoritmo para determinar o serviço a ser selecionado: a) Executar a pesquisa a partir da descrição do serviço; b) Organizar todos os serviços obtidos da pesquisa realizada por suas assinaturas e parâmetros; c) Obter os parâmetros de serviço desejados; d) Agrupar o resultado e ordená-lo baseado na relevância dos itens obtidos; e) Se não obtiver um resultado relevante, permitir à aplicação cliente reavaliar as restrições. Voltar ao passo b; 6. A definição de novos conjuntos de metadados para a descrição dos serviços (SCHMIDT et al., 2005), considerando as novas informações nos filtros de seleção já aplicados para a seleção de serviços;
33 7. Os algoritmos para a descoberta e seleção de serviços usando ontologias (TOMA et al., 2007; PATHAK et al., 2005) e algoritmos combinando ontologias com teoria dos grafos (LIN et al., 2004), baseados em uma solução proprietária que utiliza um repositório de serviços baseado em ontologias; 8. Os algoritmos baseados em tecnologia adaptativa (FENG et al., 2007; SANTANA et al., 2009b); 9. Os algoritmos baseados em qualidade de serviço (YANG et al., 2005), como disponibilidade e tempo de resposta; 10. Os algoritmos que consideram a análise probabilística de dados históricos (CASATI et al., 2004); 11. Os algoritmos baseados em inteligência artificial, como redes neurais e técnicas de aprendizado (MATAI; HAN, 2007). É importante notar que todas essas soluções trabalham com atributos de serviços que normalmente não estão disponíveis nos web services ou outros serviços utilizados pelas empresas de mercado. Portanto, a sua adoção depende também da aceitação dessas propostas e da adoção desses novos padrões pela comunidade, já que a interoperabilidade é fundamental para a Web 3.0.
34 3 Proposta Arquitetural para o Barramento de Serviços Neste capítulo, são apresentadas a descrição do algoritmo de seleção de serviços utilizado neste trabalho e uma proposta arquitetural para a orquestração dinâmica de serviços dentro do ESB. 3.1 Algoritmo para Seleção de Serviços Para o estudo de caso apresentado nesse trabalho, foi escolhido o algoritmo para seleção de serviços proposto em Santana et al. (2009b). Este algoritmo foi escolhido porque ele permite o uso dos atributos de QoS para a seleção dos serviços, o que é necessário para a implementação da solução proposta, apresentada na seção 3.2. O algoritmo se baseia em uma estrutura de tabela de decisão adaptativa para o ranqueamento e a seleção dos serviços. Uma possível tabela para a solução deste tipo de problema é ilustrada na Tabela 1, onde consta uma tabela com as linhas c1, c2,, cn para representar as condições, as linhas a1, a2,, am para representar as ações, e as linhas ba1, ba2,, bak para representar as funções adaptativas, que definem as ações a serem tomadas de maneira adaptativa pelo algoritmo durante a sua execução (NETO, 2001). Na implementação da tabela de decisão adaptativa para esse trabalho, as linhas de condições foram definidas como os valores para as variáveis que definem a qualidade dos serviços, como segurança, tempo de resposta e disponibilidade, entre outros. As linhas com as funções adaptativas são responsáveis por aplicar as regras de atualização nas variáveis de condição, por exemplo diminuindo ou aumentando os valores das variáveis. As linhas de ações são responsáveis por executar as regras definidas de acordo com as condições avaliadas a cada momento.
35 Condição Ação Função C1 C2... Cn A1 A2... An Ba1 Ba2... Ban Tabela de Decisão Adaptativa 0 1 2... n Tabela 1: Tabela de decisão adaptativa O algoritmo utilizado neste trabalho baseia-se na estrutura de tabela de decisão adaptativa para efetuar a seleção dinâmica de serviços. A Tabela 2 apresenta um pseudocódigo deste algoritmo, através do qual é possível melhor compreender seu funcionamento. Implementado internamente ao barramento de serviços, este algoritmo funciona aguardando por requisições que exijam sua orquestração. Uma vez recebida uma requisição, o algoritmo verifica a base de serviços disponíveis para executar a tarefa requisitada e seleciona o serviço melhor ranqueado dentre os disponíveis. Este ranqueamento é definido de acordo com variáveis de qualidade inerentes aos serviços, por exemplo, tempo de resposta, indisponibilidade, segurança, etc. Identificado o serviço a ser utilizado, o barramento efetua sua chamada e valida seu retorno. Neste ponto do algoritmo, inicia-se o conceito da tabela de decisão adaptativa discutida neste trabalho, onde, na validação do retorno é verificada a ocorrência ou não de alguma condição, definidas na tabela de decisão pelas linhas de condições. Uma vez identificada a ocorrência de uma das condições pré-estabelecidas, o algoritmo executa a ação diretamente relacionada a esta condição (definida na tabela de decisão através das linhas de ação). Seguido desta ação, o algoritmo aplica na base de serviços disponíveis uma função de adaptação (definida na tabela de decisão pelas das linhas de funções adaptativas), a fim de atualizar as variáveis relacionadas a este serviço e consequentemente reclassificar o ranqueamento de serviços existente, para que as próximas requisições possam
36 ser executadas sobre o ambiente atualizado. Algoritmo: Tabela de Decisão Adaptativa Inicio Enquanto Houver Requisição { Receber Requisição; Verificar Serviço Melhor Ranqueado; Executar Chamada do Serviço; Validar Retorno { Caso Condição 01; Executar Ação 01; Aplicar Função Adaptativa 01; Caso Condição 02; Executar Ação 02; Aplicar Função Adaptativa 02; Caso Condição N; Executar Ação N; Aplicar Função Adaptativa N; } Retornar Dados do Serviço; } Fim Tabela 2: Algoritmo de seleção dinâmica Um exemplo de funcionamento, onde é possível visualizar a fusão entre o algoritmo de seleção e a estrutura da tabela de decisão adaptativa é demonstrado a partir da Tabela 3 e Tabela 4. A Tabela 3 contém um exemplo de base com quatro serviços disponíveis para executar uma determinada tarefa. Baseado nas variáveis de qualidade tempo de resposta e indisponibilidade é definida a classificação destes serviços, no qual o serviço com ID 02 é o melhor ranqueado. Id do Serviço 01 02 03 04 Tempo de Resposta 2000 1000 8000 5000 Flag de Indisponibilidade S N N S Posição 3 1 2 4 Tabela 3: Exemplo de variáveis de qualidade de serviços
37 A Tabela 4 foi preenchida com alguns exemplos de cenários possíveis numa aplicação da tabela de decisão adaptativa. Durante uma simulação de execução do ambiente neste cenário, ao receber uma requisição para executar esta funcionalidade, o barramento consultaria a base ilustrada na Tabela 3 onde estaria definido o serviço com id 2 como melhor ranqueado. O ESB por sua vez efetua a chamada deste serviço e analisa o retorno. Caso, por exemplo, nesta validação seja identificada a condição 02 definida na tabela de decisão ilustrada na Tabela 4, o algoritmo de seleção dinâmica executaria a ação 02 que, conforme definido neste exemplo, utilizaria o retorno do serviço. Paralelamente a esta ação, o algoritmo aplicaria uma função adaptativa que atualizaria a variável tempo de resposta referente a este serviço na base ilustrada na Tabela 3 com o novo valor constatado. Uma vez atualizado o valor desta variável a classificação dos serviços automaticamente sofre uma reordenação, pois conforme mencionado, este ranqueamento é baseado no valor das variáveis de qualidade dos serviços. Após a reclassificação, o serviço com id 02 não seria mais o primeiro, posição esta que seria ocupada agora pelo serviço com id 03, ou seja, numa próxima requisição será este o serviço definido para executar a funcionalidade solicitada. Serviço 01 Serviço 02 Serviço 03 Serviço 04 Condição 01 Serviço Serviço Serviço Indisponível Serviço Indisponível Indisponível Indisponível Condição 02 Tempo de Tempo de Tempo de Resposta Tempo de Resposta Resposta >5000 Resposta >5000 >5000 >5000 Ação 01 Executar Serviço Executar Serviço Executar Serviço Executar Serviço Posição 2 Posição 2 Posição 2 Posição 2 Ação 02 Utilizar Retorno Utilizar Retorno Utilizar Retorno Utilizar Retorno Função 01 Atualizar flag Atualizar flag Atualizar flag Atualizar flag Indisponibilidade Indisponibilidade Indisponibilidade Indisponibilidade Função 02 Atualizar Tempo Atualizar Tempo Atualizar Tempo Atualizar Tempo Resposta Resposta Resposta Resposta Tabela 4: Exemplo de tabela de decisão adaptativa preenchida 3.2 Proposta Arquitetural de Alteração do ESB Este trabalho apresenta uma proposta arquitetural para alterar o barramento de serviços. Originalmente, todo ESB contém um service engine, que é o elemento arquitetural responsável pela mediação dos serviços. O service engine, por exemplo, pode acessar um
38 UDDI para obter informações sobre determinado serviço antes que ele possa ser invocado. Para viabilizar a orquestração dinâmica de serviços baseados em QoS e outros critérios de seleção dinâmica, por exemplo a partir dos diversos métodos propostos e apresentados em 3.4, deve-se permitir a incorporação de algoritmos para ranqueamento e seleção de serviços aos ESBs. Uma solução para esse problema é alterar o service engine, incorporando a ele novos elementos arquiteturais que permitam que ele passe a ser inteligente, ou seja, que ele possa executar algoritmos inteligentes. Nessa solução, o service engine passaria a ser composto por um localizador de serviços (Service Searcher), uma base de dados com informações sobre os serviços (Services Repository) e uma estrutura responsável pela seleção efetiva dos serviços (Solution Manager), onde os algoritmos poderiam ser disponibilizados. A proposta está ilustrada na Figura 8, construída a partir da proposta original apresentada em Santana (2009a). O Service Searcher deve fazer a busca pelos serviços nos diferentes repositórios: UDDIs, repositórios semânticos (Semantic Services Repository, proposta da Web 3.0) e outros possíveis repositórios que venham a surgir (Other types of repositories for services). Informações sobre os serviços devem ser armazenadas no Services Repository. O armazenamento deve ser feito usando metadados, o que exige a criação de um esquema XML (XML-Schema), de forma que o acesso ao repositório obedeça a padrões de dados específicos. Isso é importante para que o Solution Manager trabalhe adequadamente, para prover a interoperabilidade e para o eventual compartilhamento de informações entre ESBs no futuro, caso uma solução distribuída se mostre mais viável para a seleção de serviços. O Solution Manager deve implementar os algoritmos para o ranqueamento e seleção dinâmica de serviços. Idealmente, os algoritmos devem ser implementados na forma de plug-ins. Assim, o responsável pela gestão da infraestrutura pode definir o algoritmo ou a solução mais adequada, dentre as oferecidas pelo ESB, para a sua aplicação.
39 Figura 8: Proposta de solução arquitetural Vale notar que a definição de um XML-Schema para o Mule ESB não faz parte do escopo desse trabalho. Porém, alguns metadados foram definidos para viabilizar o desenvolvimento do estudo de caso apresentado no Capítulo 4. O encadeamento de serviços também não é abrangido na analise feita neste trabalho, embora seja possível aplicar os conceitos propostos aqui num cenário que utiliza composição de serviços para executar uma determinada funcionalidade.
40 4 Estudo de Caso: Implementação da Solução Proposta aplicando Algoritmo Baseado em Tabelas de Decisão Adaptativas Neste capítulo é apresentado o estudo de caso onde foram implementadas a solução arquitetural proposta alterando o Mule ESB e a aplicação cliente, que foi construída para testar a nova solução. 4.1 Implementação da Solução Proposta A implementação da solução proposta neste trabalho baseia-se no desenvolvimento de componentes e configurações no barramento de serviços Mule ESB, a fim de permitir que a aplicação obtenha autonomia para efetuar uma seleção dinâmica dos serviços em tempo de execução. Conforme descrito anteriormente, em um contexto orientado a serviços o ESB é o componente que intermedia duas ou mais aplicações e/ou serviços aguardando por requisições que exijam sua ação. Ao receber uma requisição, por exemplo, envolvendo orquestração de serviços, tem a responsabilidade de executar os seguintes processos: 1. Manipular o conteúdo recebido; 2. Selecionar dinamicamente o web service disponível; 3. Encaminhar o conteúdo para o web service selecionado; 4. Receber o resultado do processamento executado pelo web service; 5. Manipular o conteúdo recebido e devolvê-lo à aplicação.
41 A Figura 9 ilustra os três fluxos implementados no barramento e que executam a orquestração dinâmica de serviços. O código fonte desta implementação efetuada no Mule pode ser consultada no Apêndice A, ao final deste trabalho. O fluxo ConsultaArquivoXML é responsável por obter as informações dos serviços disponíveis, armazenadas em um arquivo XML. O fluxo AtualizarArquivoXML é responsável por atualizar estas informações no arquivo XML. O fluxo Principal contém os componentes responsáveis pela orquestração e seleção dos serviços, bem como as manipulações necessárias durante o roteamento dos dados através do barramento. Figura 9: Desenvolvimento do ESB
42 A seguir, são detalhados separadamente os principais componentes presentes nos fluxos desta aplicação. O primeiro ícone ilustrado no fluxo Principal da Figura 8 é um HTTP EndPoint. Trata-se do componente responsável por ficar aguardando em uma entrada específica do ESB à espera de requisições que sejam para lá direcionadas. Ao receber uma requisição, este componente tem a função de capturar o conteúdo recebido, executar as manipulações necessárias nos dados de maneira a deixá-los em um formato compreendido pelos demais componentes do barramento, e encaminhá-lo para o próximo componente. Este componente tem a função de encapsular os dados recebidos em um formato SOAP para que seja possível encaminhá-lo como entrada para ser processado pelo web service. Este componente, ilustrado nos fluxos ConsultaArquivoXML e AtualizaArquivoXML, tem a função de inserir no barramento o diretório contendo um arquivo de configuração onde são armazenadas algumas informações sobre os serviços disponíveis para a funcionalidade requerida. Neste exemplo, utilizamos um arquivo do tipo XML com a estrutura ilustrada na Figura 10. Nele, são inseridas as informações que representam as variáveis de qualidade dos web services. Para facilitar a ilustração e demonstração, neste exemplo foram utilizados os atributos de QoS tempo de resposta e disponibilidade.
43 Figura 10: Arquivo com metadados dos serviços disponíveis Este arquivo é o que constitui a base de metadados apresentada na proposta de alteração da arquitetura do barramento de serviços deste trabalho. Este componente tem a função de mapear em tempo de execução os dados do arquivo XML obtido no componente anterior para um objeto Java, onde será possível manipular os dados em memória e em tempo de execução. Presente nos fluxos ConsultaArquivoXML e AtualizaArquivoXML, este componente representa um objeto Java (POJO - Plain Old Java Object), onde são mapeados e armazenados os dados obtidos do arquivo XML com as variáveis de qualidade dos web services, tornando possível efetuar operações de ordenação e seleção sobre eles. Este componente tem a função de armazenar em uma variável de sessão, o ID do serviço, que está na primeira posição do ranking presente no arquivo XML.
44 Presente duas vezes no fluxo Principal. Sua primeira utilização no fluxo tem a função de rotear a mensagem entre os web services disponíveis. Para isto ele utiliza o ID do serviço armazenado na variável de sessão para definir qual web service utilizar. Este componente tem a função de encaminhar a entrada encapsulada no componente SOAP para o web service. Dado que pode existir mais de um web service disponível e que pode ser utilizado, existirá um componente HTTP para cada opção de web service. Neste exemplo, foram definidos três web services, logo, três componentes. Presente pela segunda vez no fluxo Principal, este componente tem a função de decidir, a partir do retorno do serviço, quais são as ações que o barramento deve tomar. Neste exemplo, existem três possíveis ações a serem tomadas, baseadas nas seguintes condições: 1. O web service retornou os dados corretamente e com tempo de resposta dentro do esperado; 2. O web service retornou os dados corretamente, mas com tempo de resposta superior ao esperado; 3. O web service não retornou os dados, ou seja, considera-se que houve indisponibilidade do serviço; Cada uma das condições acima leva o barramento de serviços a seguir um determinado fluxo e executar uma sequência de ações no tráfego da mensagem. Além das ações, cada condição dispara também no barramento a execução de funções adaptativas, de maneira a atualizar dinamicamente as próximas ações a serem tomadas no caso de uma recorrência da condição encontrada. A descrição dos próximos componentes contempla as ações e funções adaptativas aplicadas em cada uma das condições descritas acima.
45 Este componente é executado caso a decisão seja seguir o fluxo atual e devolver o retorno do serviço para que a aplicação possa apresentar o resultado ao usuário. Este componente está presente três vezes no fluxo Principal. Ele funciona apenas como um direcionador para outros fluxos do barramento. Neste exemplo, ele executa os sub fluxos ConsultaArquivoXML e AtualizaArquivoXML. 4.2 Execução e Testes da Solução Para testar a proposta de solução para a seleção dinâmica de serviços apresentada e desenvolvida neste trabalho, foram desenvolvidos uma série de web services armazenados localmente. Para o desenvolvimento destes serviços, foram utilizados os mecanismos para construção de web services presentes no ambiente de desenvolvimento da ferramenta NetBeans. Cabe salientar que esta proposta de solução aplica-se a qualquer tipo de web service existente dentro dos padrões estabelecidos pela W3C. A utilização de web services próprios neste trabalho tem unicamente o intuito de tornar mais fácil a validação e homologação dos resultados, uma vez que deste modo é possível termos uma quantidade maior de diferentes web services que executam uma mesma funcionalidade, o que não seria tão facilmente possível caso utilizássemos web services externos. Além disto, o ambiente controlado e o armazenamento local dos web services permite a simulação de casos de teste como indisponibilidade dos serviços e tempos de resposta e um maior controle sobre as variáveis envolvidas, a fim de aumentar a relação causa-efeito e a acurácia dos testes. Dado que o intuito deste estudo de caso é avaliar a implementação da proposta de solução apresentada, a funcionalidade dos web services desenvolvidos para os testes restringem-se a simplesmente receber um valor de entrada e devolvê-lo à aplicação com a uma informação que identifique o web service que processou os dados recebidos. A Figura 11 ilustra o trecho de código de um dos web services que executa este processamento e a Figura
46 12 ilustra a estrutura com os três web services desenvolvidos e utilizados para os testes. Figura 11: Web Services utilizados Figura 12: Trecho de código executado pelos Web Services Aplicação cliente é a aplicação que irá utilizar os recursos arquiteturais do barramento de serviços para executar uma determinada tarefa. Neste trabalho, foi adotada uma aplicação web hipotética que utiliza funcionalidades de um web service para executar uma determinada tarefa. Neste caso de uso, como aplicação utilizou-se uma página web, ilustrada na Figura 13, composta simplesmente por um campo onde o usuário pode digitar um texto e um botão responsável por capturar e encaminhar o conteúdo digitado pelo usuário para ser processado pelo web service. O desenvolvimento desta página consiste basicamente de código HTML (HyperText Markup Language) simples, efetuado no ambiente de desenvolvimento da ferramenta NetBeans [https://netbeans.org/] e armazenado localmente. Internamente a esta página, existe um formulário, ou seja, um form em linguagem HTML, que envia o conteúdo do campo de
47 texto para um endereço especifico, que neste exemplo é um diretório local. Figura 13: Aplicação cliente A validação da solução proposta e desenvolvida neste trabalho foi estruturada em três testes: 1) Teste de sucesso, onde o web service executa sua tarefa e retorna para a aplicação conforme esperado; 2) Um teste onde o web service executa sua tarefa e retorna para a aplicação, entretanto com tempo de resposta superior ao esperado; e 3) Um teste de falha, onde o web service não retorna para a aplicação, simulando indisponibilidade do serviço. 4.2.1. Teste de Sucesso Neste teste, o usuário insere um texto no campo de entrada e clica no botão Enviar, conforme Figura 14.
48 Figura 14: Aplicação cliente A aplicação, por sua vez, encaminha o texto digitado pelo usuário para a entrada do barramento de serviços onde um componente do Mule ESB está configurado aguardando por requisições. O Mule ESB, por sua vez, executa as manipulações necessárias nos dados de entrada recebidos conforme especificado na implementação da solução deste trabalho. Neste momento do teste existem três serviços disponíveis e cadastrados no barramento para executar esta funcionalidade. A Figura 15 apresenta o arquivo XML que representa os metadados dos serviços cadastrados no momento do teste. Por ela, é possível notar que o serviço com ID 01 é o primeiro serviço na classificação estabelecida entre os três existentes. Esta posição do serviço foi obtida com base nas suas variáveis de QoS tempo de resposta e indisponibilidade (falha), que são melhores do que as dos demais serviços.
49 Figura 15: Classificação e status dos serviços disponíveis Conforme implementado, o Mule ESB verifica este arquivo e chama o serviço correspondente ao ID 01 do arquivo, encaminhando os dados de entrada recebidos da aplicação. O serviço executa o processamento dos dados recebidos e devolve ao Mule ESB. O Mule ESB verifica a ocorrência ou não de falha e o tempo de resposta, que neste exemplo está dentro do esperado. A partir dessa condição, o Mule ESB executa as manipulações especificadas na solução e devolve o conteúdo retornado pelo serviço para a aplicação, que por sua vez apresenta o resultado ao usuário conforme Figura 16. Figura 16: Resultado na aplicação cliente
50 4.2.2. Teste de Tempo de Resposta Neste teste o usuário insere um texto no campo de entrada e clica no botão Enviar, conforme Figura 17. Figura 17: Aplicação cliente A aplicação, por sua vez, encaminha o texto digitado pelo usuário para a entrada do barramento de serviços onde um componente do Mule ESB está configurado aguardando por requisições. O Mule ESB, por sua vez, executa as manipulações necessárias nos dados de entrada recebidos conforme especificado na implementação da solução deste trabalho. Neste momento do teste, existem três serviços disponíveis e cadastrados no barramento para executar esta funcionalidade, como no teste anterior. A Figura 18 apresenta o arquivo XML que representa os metadados dos serviços cadastrados no momento do teste. O serviço com ID 01 é o primeiro serviço na classificação estabelecida entre os três existentes, considerando os atributos de QoS tempo de resposta e indisponibilidade (falha).
51 Figura 18: Classificação e status dos serviços disponíveis Conforme implementado, o Mule ESB verifica este arquivo e chama o serviço correspondente ao ID 01 do arquivo, encaminhando os dados de entrada recebidos da aplicação. O serviço executa o processamento dos dados recebidos e devolve ao ESB. Entretanto, no intuito de efetuar um teste de tempo de resposta maior do que esperado, inseriu-se no processamento deste serviço um comando Sleep para que o retorno ocorra somente após 8000 milissegundos, ou seja, um tempo maior do que os 3000 milissegundos considerados como tempo aceitável para uma boa performance da aplicação. Por sua vez, o ESB verifica a ocorrência ou não de falha e o tempo de resposta, que neste exemplo está acima do esperado. Dado esta condição, o ESB atualiza o arquivo de metadados dos serviços, alterando a variável tempo do serviço de ID 01 com o valor do tempo de resposta aferido pelo ESB. Após esta atualização, o arquivo fica conforme visualizado na Figura 19, onde podemos observar que houve uma reclassificação dos serviços disponíveis, onde o serviço com ID 01 está agora na posição dois, dado que o valor de sua variável de qualidade tempo é de 8000.
52 Figura 19: Classificação e status dos serviços disponíveis Conforme especificado na implementação da proposta, dado que o serviço retornou a solicitação, mesmo que com tempo acima do esperado, o Mule ESB executa as manipulações especificadas na solução e devolve o conteúdo retornado pelo serviço para a aplicação, que por sua vez apresenta o resultado ao usuário conforme Figura 20. Figura 20: Resultado na aplicação cliente 4.2.3. Teste de Indisponibilidade Neste teste o usuário insere um texto no campo de entrada e clica no botão Enviar conforme Figura 21.
53 Figura 21: Aplicação cliente A aplicação encaminha o texto digitado pelo usuário para a entrada do barramento de serviços onde um componente do Mule ESB está configurado aguardando por requisições. O Mule ESB executa as manipulações necessárias nos dados de entrada recebidos conforme especificado na implementação da solução deste trabalho. Neste momento do teste, existem três serviços disponíveis e cadastrados no Mule ESB para executar esta funcionalidade. A Figura 22 apresenta o arquivo XML que representa os metadados dos serviços cadastrados. Por ela, pode-se notar que o serviço com ID 02 é o primeiro serviço na classificação estabelecida entre os três existentes, conforme resultado do teste anterior. Figura 22: Classificação e status dos serviços disponíveis
54 Conforme implementado, o Mule ESB verifica este arquivo e chama o serviço correspondente ao ID 02 do arquivo, encaminhando os dados de entrada recebidos da aplicação. No intuito de efetuar um teste de indisponibilidade, inseriu-se neste serviço uma indisponibilidade intencional, ou seja, o serviço não retorna os dados processados para a aplicação, disparando com isto uma falha de disponibilidade no ESB. Dado esta condição, o ESB atualiza o arquivo de metadados dos serviços, alterando a variável falha do serviço de ID 02 com o valor S, indicando que este serviço apresentou uma indisponibilidade. Após esta atualização, o arquivo fica conforme visualizado na Figura 23, onde se pode observar que houve uma reclassificação dos serviços disponíveis, onde o serviço com ID 02 está agora na posição três, dado que o valor de sua variável de qualidade falha é S. Figura 23: Classificação e status dos serviços disponíveis Conforme especificado na implementação da proposta, dado que o serviço não retornou a solicitação, o ESB reexecuta o fluxo dentro do barramento, iniciando novamente a leitura do arquivo de metadados dos serviços disponíveis. Uma vez que o arquivo já foi atualizado depois da indisponibilidade apresentada pelo serviço anterior, o ESB seleciona o serviço melhor classificado no arquivo e chama o serviço correspondente ao ID 01 encaminhando os dados de entrada recebidos da aplicação. O serviço por sua vez executa o processamento sob os dados recebidos e devolve ao
55 ESB. O ESB verifica a ocorrência ou não de falha e o tempo de resposta, que neste exemplo está dentro do esperado. Dado esta condição o ESB executa as manipulações especificadas na solução e devolve o conteúdo retornado pelo serviço para a aplicação, que por sua vez apresenta o resultado ao usuário conforme Figura 24. Figura 24: Resultado na aplicação cliente Portanto, os três testes apresentaram os resultados esperados, mostrando a reclassificação dos serviços com bases nos atributos de QoS tempo de resposta e indisponibilidade do serviço e o resultado da implementação das alterações arquiteturais implementadas no Mule ESB.