uma abordagem arquitetural para a orquestração dinâmica de
TRANSCRIPT
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. Luiz Carlos da Silva Rozante
UFABC
Suplente Interno
__________________________________
Prof. Dr. Pedro Luiz Pizzigatti Corrêa
POLI-USP
Titular Externo
__________________________________
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 Enterprise Service Bus
FTP File Transfer Protocol
HTTP Hypertext Transfer Protocol
IEEE Instituto de Engenheiros Eletricistas e Eletrônicos
JDBC Java Database Connectivity
MOM Message Oriented Middleware
OWL Web Ontology Language
POP3 Post Office Protocol
QOS Quality of service
REST Representational state transfer
SMTP Simple Mail Transfer Protocol
SOA Service Oriented Architecture
SOAP Simple Object Access Protocol
SOC Service Oriented Computing
TCP Transmission Control Protocol
TI Tecnologia da Informação
UDDI Universal Description, Discovery and Integration
UDP User Datagram Protocol
UMO 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.
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).
Monolítico Estruturado Cliente
Servidor 3 Camadas N Camadas Serviços
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.
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
Repositório de Serviços
Provedores de Serviços
Consumidores de Serviços
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
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;
Identificação do Domínio Modelo de Serviços
Componentes dos
Sistemas Legados
Análise dos Sub Sistemas
Alocação dos Serviços
Especificação dos Componentes
Mapeamento Tecnológico
Repositório de
Componentes de
Serviços
Repositório
de Serviços
1A
2 3
4
Estruturação baseada nos padrões arquiteturais
5
6
7
1B
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
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
Barramento de Menssagens
Container
Adaptador de Aplicação
Aplicação
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.
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.,
Transportador Roteador de
Entrada Componente
Roteador de Saída
Transportador
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
Tabela de Decisão Adaptativa
0 1 2 ... n
Condição
C1
C2
...
Cn
Ação
A1
A2
...
An
Função
Ba1
Ba2
...
Ban
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
Indisponível Serviço
Indisponível Serviço Indisponível Serviço Indisponível
Condição 02 Tempo de
Resposta >5000 Tempo de
Resposta >5000 Tempo de Resposta
>5000 Tempo de Resposta
>5000
Ação 01 Executar Serviço
Posição 2 Executar Serviço
Posição 2 Executar Serviço
Posição 2 Executar Serviço
Posição 2
Ação 02 Utilizar Retorno Utilizar Retorno Utilizar Retorno Utilizar Retorno
Função 01 Atualizar flag
Indisponibilidade Atualizar flag
Indisponibilidade Atualizar flag
Indisponibilidade Atualizar flag
Indisponibilidade
Função 02 Atualizar Tempo
Resposta Atualizar Tempo
Resposta Atualizar Tempo
Resposta Atualizar Tempo
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.
56
5 Conclusão
A seleção dinâmica de serviços pode ser concebida de diferentes maneiras, entretanto a
implementação deste dinamismo no barramento de serviços mostra-se como uma solução
adequada, uma vez que o conceito fundamental desta estrutura é justamente a orquestração de
serviços e a integração de aplicações.
A implementação da seleção diretamente no barramento de serviços traz também ganhos
de escalabilidade e otimização de desempenho, uma vez que ela permite adicionar de forma
incremental outras soluções para a orquestração dinâmica de serviços, com destaque para a
utilização de algoritmos inteligentes de ranqueamento e seleção de serviços como os citados
nos trabalhos relacionados a este tema.
A orquestração observada através dos resultados obtidos no estudo de caso deste
trabalho comprova a inserção de dinamismo na seleção dos serviços, ou seja, a partir da
aplicação prática da proposta em um barramento de serviços presente no ambiente
tecnológico atual, comprovou-se que a arquitetura obteve autonomia para tomada de decisão
em tempo de execução a partir de variáveis atualizadas dinamicamente e não mais se
baseando em regras inseridas estaticamente no código durante o desenvolvimento das
aplicações.
Uma vez comprovada sua eficácia através deste estudo de caso, o conceito da solução
apresentada neste trabalho pode ser estendido para outros barramentos de serviços
disponíveis atualmente no mercado, o que mostra a abrangência da proposta. O teste da
solução em outros ESBs de mercado está entre os trabalhos futuros, juntamente com o
desenvolvimento do XML-Schema para o armazenamento de informações sobre os serviços e
a incorporação de outras técnicas e algoritmos inteligentes para otimizar o processo de
seleção dos serviços.
Conclui-se, portanto, que a dinâmica na orquestração de serviços em uma arquitetura
SOA é um assunto constantemente estudado no meio científico; e soluções para este
problema muitas vezes surgem oriundas destas pesquisas e trabalhos.
57
Referências Bibliográficas
Barry W. Boehm: A Spiral Model Of Software Development And Enhancement. Ieee
Computer, 21, 5 (May 1988), Pp. 61-72.
Bass, L.; Clements, P.; Kazman, R. Software Architecture In Practice. Second Edition,
Addison-Wesley Professional. 2003.
Berners-Lee, T; Hendler, J.; Lassila, O. The Semantic Web. Scientific American, 284(5):34-
43, 2001.
Bradac, M.; D. Perry, L. Votta. Prototyping A Process Monitoring Experiment. Ieee -
Software Engineering. 1994.
Beck, K., Programação Extrema Explicada, Bookman, (1999).
Berander, P.; Damm, L.; Eriksson, J.; Gorschek, T.; Henningsson, K.; Jönsson, P. Et Al.
Software Quality Attributes And Trade-Offs. Blekinge Institute Of Technology. 2005.
Casati, F.; Castellanos, M.; Dayal, U.; Shan, M. Probabilistic, Context-Sensitive, And Goal-
Oriented Service Selection. Proceedings Of The 2nd International Conference On Service
Oriented Computing. 2004. P. 316-321.
Caverlee, J.; Liu, L.; Rocco, D. Discovering And Ranking Web Services With Basil: A
Personalized Approach With Biased Focus. Proceedings Of The 2nd International
Conference On Service Oriented Computing. 2004. P. 153-162.
Chappell, D. A. Enterprise Service Bus. O’reilly. 2004.
Dujmovic, J. J. Mixed Averaging By Levels (Mal) – A System And Computer Evaluation
Method. Proceedings Of The Informatica Conference, Bled, Yugoslavia. 1973.
Endrei, M.; Ang, J.; Arsanjani, A.; Chua, S.; Comte, P.; Krogdahl, P.; Luo, M.; Newling, T.
58
Patterns - Service-Oriented Architecture And Web Services. Ibm Redbook. 2004.
Feng, X.; Wang, H.; Wu, Q.; Zhou, B. An Adaptive Algorithm For Failure Recovery During
Dynamic Service Composition. Lecture Notes In Computer Science. 2007. V. 4825, P. 41-48.
Fox, Armando; Patterson, David; Engineering Long Lasting Software, Alpha Edition, 2012.
Griss, M. L. Software Reuse Archetecture, Process, and Organization for Business Success.
In Proc. of the Eighth Israeli Conference on Computer Systems and Software Engineering,
Herzliya, 1997, pp. 86–98.
Hendler, J. Web 3.0 Emerging. Computer, vol. 42, no. 1, 2009, pp. 111–113.
Huhns, M.; Singh, M.P. Service-Oriented Computing: Key Concepts And Principles. Ieee
Internet Computing. 2005. V.9-1, P.75-81.
Ieee. Standards Collection: Software Engineering. Ieee Standard 610.12-1990, Ieee 1993
Lin, C.; Wu, Z.; Deng, S.; Kuang, L. Automatic Service Matching And Service Discovery
Based On Ontology. Lecture Notes In Computer Science. 2004. V. 3252, P. 99-106.
Mackenzie, C. M.; Laskey, K.; Mccabe, F.; Brown, P. F.; Hamilton; Metz., R. Oasis
Reference Model For Service Oriented Architecture 1.0. 2006.
Matai, J.; Han, D. S. Learning-Based Trust Model For Optimization Of Selecting Web
Services. Lecture Notes In Computer Science. 2007. V. 4505, P. 642-649.
Menascé, D. A. Qos Issues In Webservices. 2002. Ieee Computer, Pp 72-75.
Menge, F. Enterprise Service Bus. Free And Open Source Software Conference. 2007.
Mule, Oficial Web Site. 2014. Www.Mulesoft.Org
Neto, J. J. 2001. Adaptive Rule-Driven Devices – General Formulation and Case Study.
Lecture Notes in Computer Science. Watson, B.W. and Wood, D. (Eds.): Implementation and
Application of Automata 6th International Conference, CIAA. Vol. 2494, Pretoria, South
Africa, July 23-25, Springer-Verlag, 2001, pp. 234-250.
59
O'REILLY, Tim. What Is Web 2.0 - Design Patterns and Business Models for the Next
Generation of Software. O'Reilly Publishing, 2005.
P. Naur And B. Randell, (Eds.). Software Engineering: Report Of A Conference Sponsored
By The Nato Science Committee, Garmisch, Germany, 7-11 Oct. 1968, Brussels, Scientific
Affairs Division, Nato 1969
Pathak, J.; Koul, N.; Caragea, D.; Vasant, G. A Framework For Semantic Web Services
Discovery. Proceedings Of The 7th Annual Acm International Workshop On Web
Information And Data Management. 2005. P. 45-50.
Peltz, C. Web Services Orestrestration and Choreography. Computer, vol. 36, no. 10, pp. 46-
52, Oct. 2003.
Pressman, Roger S. Engenharia De Software. 6. Ed. São Paulo: Mcgraw-Hill, 2002.
Santana, F. S. Uma Infraestrutura Orientada A Serviços Para A Modelagem De Nicho
Ecológico. Tese De Doutorado. Escola Politécnica Da Universidade De São Paulo. 2009a.
141p.
Santana, F. S., Barberato, C., Stange, R. L., Neto, J. J., Saraiva, A. M. Application Of
Adaptive Decision Tables To Enterprise Service Bus Service Selection. Proceedings – Wta,
Escola Politécnica Da Universidade De São Paulo. 2009b.
Schmidt, M.T.; Hutchison, B.; Lambros, P.; Phippen, R. The Enterprise Service Bus: Making
Service-Oriented Architecture Real. Ibm Systems Journal. 2005.
Shaikhali, A.; Rana, O. F.; Al-Ali, R.; Walker, D. W. Uddie: An Extended Registry For
Web Services. Applications And The Internet Workshops, 2003. Proceedings. 2003
Symposium On. 2003. P. 85-89.
Silva, Edna Lúcia; Menezes, Estera Muszkat; Metodologia da Pesquisa e Elaboração de
Dissertação. – 4. Ed. rev. atual. – Florianópolis: UFSC, 2005.
Soydan Bilgin, A.; Singh, M. P. A Daml-Based Repository For Qos-Aware Semantic Web
Service Selection. Ieee International Conference On Web Services, Proceedings. 2004. P.
368-375.
60
Stal, M. Web Services: Beyond Component-Based Computing. Communications Of The
Acm. 2002. V. 45-10, P. 71-76.
Toma, I.; Roman, D.; Fensel, D.; Sapkota, B.; Gomez, J. M. A Multi-Criteria Service
Ranking Approach Based On Non-Functional Properties Rules Evaluation. Lecture Notes In
Computer Science. 2007.
Yager, R. R. On Ordered Weighted Averaging Aggregation Operators In Multi-Criteria
Decision Making. Ieee Transactions On Systems, Man And Cybernetics. 1988. V. 18, P. 183-
190.
Yang, L.; Dai, Y.; Zhang, B.; Gao, Y. Dynamic Selection Of Composite Web Services Based
On A Genetic Algorithm Optimized New Structured Neural Network. International
Conference On Cyberworlds. 2005. P. 522-529
61
Apêndice A
Código fonte da alteração no barramente de serviços Mule ESB:
<mule xmlns:mulexml="http://www.mulesoft.org/schema/mule/xml"
xmlns:http="http://www.mulesoft.org/schema/mule/http"
xmlns:cxf="http://www.mulesoft.org/schema/mule/cxf"
xmlns="http://www.mulesoft.org/schema/mule/core"
xmlns:doc="http://www.mulesoft.org/schema/mule/documentation"
xmlns:spring="http://www.springframework.org/schema/beans" version="CE-
3.3.1" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="
http://www.mulesoft.org/schema/mule/http
http://www.mulesoft.org/schema/mule/http/current/mule-http.xsd
http://www.mulesoft.org/schema/mule/cxf
http://www.mulesoft.org/schema/mule/cxf/current/mule-cxf.xsd
http://www.springframework.org/schema/beans
http://www.springframework.org/schema/beans/spring-beans-current.xsd
http://www.mulesoft.org/schema/mule/core
http://www.mulesoft.org/schema/mule/core/current/mule.xsd
http://www.mulesoft.org/schema/mule/xml
http://www.mulesoft.org/schema/mule/xml/current/mule-xml.xsd ">
<byte-array-to-string-transformer name="Byte_Array_to_String"
doc:name="Byte Array to String"/>
<byte-array-to-object-transformer name="Byte_Array_to_Object"
doc:name="Byte Array to Object"/>
<byte-array-to-string-transformer name="Byte_Array_to_String1"
doc:name="Byte Array to String"/>
<sub-flow name="AtualizaXMLFalha" doc:name="AtualizaXMLFalha">
<echo-component doc:name="Echo"/>
<echo-component doc:name="Echo"/>
<echo-component doc:name="Echo"/>
</sub-flow>
<sub-flow name="AtualizaXMLTime" doc:name="AtualizaXMLTime">
<echo-component doc:name="Echo"/>
<echo-component doc:name="Echo"/>
<echo-component doc:name="Echo"/>
</sub-flow>
<sub-flow name="ConsultaArquivo" doc:name="ConsultaArquivo">
<cxf:jaxws-client operation="retornaIdServico"
serviceClass="wcf.IService1" enableMuleSoapHeaders="true" doc:name="SOAP"/>
<echo-component doc:name="Echo"/>
<http:outbound-endpoint exchange-pattern="request-response"
host="localhost" port="50865" path="Service1.svc" doc:name="HTTP"/>
<echo-component doc:name="Echo"/>
<expression-transformer
expression="#[sessionVars['variavel']=payload.toString()]"
doc:name="Expression"/>
</sub-flow>
<flow name="Principal" doc:name="Principal">
62
<http:inbound-endpoint exchange-pattern="request-response"
host="localhost" port="8088" path="entrada" transformer-
refs="Byte_Array_to_String1" doc:name="HTTP"/>
<cxf:jaxws-client operation="hello" serviceClass="padrao.NewWebService"
enableMuleSoapHeaders="true" doc:name="SOAP"/>
<echo-component doc:name="Echo"/>
<enricher target="#[sessionVars['variavel']]" doc:name="Message
Enricher">
<flow-ref name="ConsultaArquivo" doc:name="Flow Reference"/>
</enricher>
<echo-component doc:name="Echo"/>
<choice doc:name="Choice">
<when expression="#[sessionVars['variavel']==22]">
<processor-chain>
<http:outbound-endpoint exchange-pattern="request-response"
host="localhost" port="8084" path="WebApplication1/Servico01"
doc:name="HTTP"/>
</processor-chain>
</when>
<otherwise>
<processor-chain>
<http:outbound-endpoint exchange-pattern="request-response"
host="localhost" port="8084" path="WebApplication1/Servico02"
doc:name="HTTP"/>
</processor-chain>
</otherwise>
</choice>
<choice doc:name="Choice">
<when expression="#[sessionVars['variavel']==23]">
<processor-chain>
<echo-component doc:name="Echo"/>
<enricher target="#[sessionVars['falha']]" doc:name="Message
Enricher">
<flow-ref name="AtualizaXMLTime" doc:name="Flow Reference"/>
</enricher>
</processor-chain>
</when>
</choice>
<echo-component doc:name="Echo"/>
<object-to-string-transformer doc:name="Object to String"/>
<echo-component doc:name="Echo"/>
</flow>
</mule>