965-7286-1-pb_estudo oracle service bus petrobras

UNIVERSIDADE FEDERAL DO ESTADO DO RIO DE JANEIRO

CENTRO DE CINCIAS EXATAS E TECNOLOGIA

Relatrios Tcnicos do Departamento de Informtica Aplicada

da UNIRIO

n 0020/2010

Estudos de Enterprise Service Bus e Oracle

Service Bus

Henrique Prado Sousa

Leonardo Guerreiro Azevedo

Flvia Santoro

Fernanda Baio

Departamento de Informtica Aplicada

UNIVERSIDADE FEDERAL DO ESTADO DO RIO DE JANEIRO

Av. Pasteur, 458, Urca - CEP 22290-240

RIO DE JANEIRO BRASIL

ii

Projeto de Pesquisa

Grupo de Pesquisa Participante

Patrocnio

iii

Relatrios Tcnicos do DIA/UNIRIO, No. 0020/2010 Editor: Prof. Sean W. M. Siqueira Dezembro, 2010

Estudos de Enterprise Service Bus e Oracle Service

Bus*

Henrique Prado Sousa, Leonardo Guerreiro Azevedo, Flvia Santoro, Fernanda Baio

Ncleo de Pesquisa e Prtica em Tecnologia (NP2Tec) Departamento de Informtica Aplicada (DIA) Universidade Federal do Estado do Rio de

Janeiro (UNIRIO)

{henrique.sousa, azevedo, flavia.santoro, fernanda.baiao}@uniriotec.br

Abstract. Enterprise Service Bus (ESB) is the main infra-structure in SOA. It is responsible to make available, in a standard way, services from different platforms, implemented in different programming languages, and available from providers in a distributed environment. Despite of several patterns for SOA, there is no pattern for ESB. Vendors agree what are the responsibilities of ESB. However, each vendor has its own implementation of ESB. This work presents the main characteristics of ESB, and analises in practice the ESB implementation of Oracle, called as Oracle Service Bus.

Keywords: SOA, ESB, OSB.

Resumo. Enterprise Service Bus (ESB) corresponde a principal infra-estrutura de SOA. Ela utilizada para disponibilizar de uma forma padronizada servios de diferentes plataformas, implementados em diferentes linguagens de programao e disponveis a partir de provedores em um ambiente distribudo. Apesar de existirem vrios pa-dres para SOA, este no a regra para ESB. Existe um concenso entre fornecedores quais so as funcionalidades que um ESB deve prover. No entanto, cada fornecedor possui sua implementao de ESB. Este trabalho apresenta as principais caractersticas de um ESB, e analisa de forma prtica a implementao de ESB da Oracle, chamada de Oracle Service Bus.

Palavras-chave: SOA, ESB, OSB. ___________________

* Trabalho patrocinado pela Petrobras.

iv

Sumrio

1 Introduo 5

1.1 Estrutura do relatrio 6

2 Enterprise Service Bus 6

2.1 Responsabilidades do ESB 8

2.2 Benefcios do ESB 11

2.3 JBI 12

2.4 ESBs comerciais e de cdigo aberto 13

3 Arquitetura do Oracle Service Bus 15

3.1 Sute de produtos do OSB 15

3.2 Componentes da arquitetura do OSB 17

3.3 Fluxo de mensagens via servios de proxy 20

3.4 WSDL efetivos e WSDL gerado 25

3.5 Web services com atributo style igual a SOAP document RPC 26

3.6 Padres de troca de mensagens 29

3.7 Broker de mensagens 29

3.8 Transformao e processamento de mensagens 30

3.9 Disponibilizao de EJB como servio 30

3.10 Console de teste 31

3.11 Gesto de recursos 31

3.12 OSB e UDDI 32

3.13 Tratamento de erros 32

3.14 Versionamento 32

3.15 Monitoramento 32

3.16 Disponibilizao do OSB em servidores 32

3.17 Outros conceitos importantes 34

4 Anlise prtica do Oracle Service Bus 34

4.1 Publicao do servio no OSB 34

4.2 Alterao dos parmetros do servio sem alterar o cliente 40

4.3 Definio de fluxos em servios de Proxy 45

4.4 Validao de tipos de dados utilizando servio de proxy 63

4.5 Versionamento de servios utilizando o OSB 78

4.6 Monitoramento de servios 85

4.7 Concluso 114

5 Concluso 114

6 Referncias 115

Apndice 1 - Diferenas entre OSB e ALSB 116

Apndice 2 - Elementos de um WSDL 117

_______________________________________________________________________________________________

RelaTe-DIA: Estudos de Enterprise Service Bus e Oracle Service Bus 5

1 Introduo

ESB a infra-estrutura que permite alta interoperabilidade entre sistemas distribudos via servios. Processos disponibilizados via servios distribudos em mltiplos siste-mas usando diferentes plataformas e tecnologias podem ser executados de uma ma-neira mais simples utilizando o ESB.

O ESB um barramento de mensagens, projetado para possibilitar a implementa-o, desenvolvimento e gerenciamento de solues baseadas em SOA com o foco no empacotamento, desenvolvimento e gesto de servios distribudos [Papazoglou et al., 2007]. responsabilidade do ESB permitir que consumidores (clientes) invoquem os servios oferecidos por provedores de servios, o que envolve vrias tarefas, tais como: prover conectividade; transformao de dados; roteamento de mensagens baseado em contedo; tratar segurana; tratar confiabilidade; gerncia de servios; monitoramento e log de servios; balanceamento de carga etc. Estas tarefas devem ser consideradas para diferentes plataformas de software e hardware para diferentes middleware e pro-tocolos (Figura 1).

Figura 1 Enterprise Service Bus [OSB, 2008a]

Uma sute robusta de um ESB em SOA deve oferecer [OSB, 2008a]:

Adaptadores: os quais possibilitam conectividade em aplicaes empacotadas e sistemas legados;

Motor de consulta distribuda: que permite a criao de servios de dados para fontes de dados heterogneas;

Motor de orquestrao de servios para tratar tanto processos de longa durao (stateful) como processos de curta durao (stateless);

Ferramenta de desenvolvimento de aplicaes que permitem a rpida criao de aplicaes para o usurio;

Servios de apresentao: permitem a criao de portais personalizados que agregam servios de mltiplas fontes.

Hewitt [2009] apresenta que os padres (API Java, tecnologias XML, BPEL, WS*) publicados em conjunto por OASIS-Open, W3C, OAGI, Sun permite que as organiza-es implementem as especificaes ou recomendaes de forma que muitas partes das tecnologias que seguem estes padres sejam portveis atravs de diferentes im-

_______________________________________________________________________________________________


plementaes. Por exemplo, um web service JAX-WS funcionar praticamente da mesma forma em qualquer container que implementa JAX-WS.

Por outro lado, no existe uma especificao para ESB. No existe nenhum padro que suporta ESB e nenhuma definio precisa para ESB. Apesar dos fornecedores con-cordarem em quais caractersticas um ESB deve ter, os produtos variam muito entre si. As funcionalidades existentes em um produto podem no existir em outro ou serem realizadas de maneira completamente diferente. Existem suites, como as propostas pela Oracle, Software AG, IBM e TIBCO, que incluem uma coleo de produtos tais como ESB, motor de orquestrao, registro/repositrio de servios, motor de execuo e de desenho BPEL, Business Activity Monitoring e outras ferramentas relacionadas. As caractersticas presentes nestes produtos no so consistentes. Por exemplo, pode-se ter um ESB de um fornecedor que trata transformaes de mensagens, enquanto que o ESB de outro fornecedor delega as transformaes para o motor de orquestra-o.

O objetivo deste relatrio apresentar as principais caractersticas que devem estar presentes em um ESB (Enterprise Service Bus) e realizar uma anlise do OSB (Oracle Service Bus) no atendimento a estas caractersticas.

Este relatrio foi produzido pelo Projeto de Pesquisa em SOA como parte das inici-ativas dentro do contexto do Projeto de Pesquisa do Termo de Cooperao entre NP2Tec/UNIRIO e a Petrobras/TIC-E&P/GDIEP.

1.1 Estrutura do relatrio

Esse relatrio est organizado em 5 captulos, sendo o captulo 1 a presente introduo.

No captulo 2, so apresentadas as principais caractersticas do Enterprise Service Bus, principal infra-estrutura que apia uma abordagem SOA.

No captulo 3, apresentada, em detalhes, a arquitetura do Oracle Service Bus (OSB), que o ESB da Oracle.

No captulo 4, apresentados estudos prticos do OSB.

Nos captulos 5 e 6, so apresentadas as concluses do trabalho e referncias bibliogrficas, respectivamente.

2 Enterprise Service Bus

Enterprise Service Bus (ESB) a principal infra-estrutura que apia uma arquitetura orientada a servios (SOA). Hewitt [2009] aponta que muitos arquitetos vem o ESB como um conjunto de padres, e no como um produto. Outros argumentam que no necessrio adquirir um ESB, o qual pode ser substitudo pela implementao de pa-dres bsicos de roteamento como os propostos por Hohpe e Woolf [2004]. Os padres de barramento de mensagens, roteamento baseado em contedo, filtros e pipes, cone-xo ponto a ponto, normalizador, modelo de dados cannicos formam a base para os ESB modernos que, alm disso, implementam padres chave de EAI (Enterprise Ap-plication Integration). Estes padres no so simples de implementar, como os pa-dres de projeto propostos em [Gamma et al., 1994]. Logo, os problemas que existem nesta abordagem so o custo de desenvolvimento e que o resultado poder ser a repli-

_______________________________________________________________________________________________


cao de muitas caractersticas j disponveis no mercado, as quais j foram testadas e automatizadas, e podem ser colocadas em execuo rapidamente.

Um ESB capaz de conectar diferentes sistemas que se comunicam via mensagens sem forar a criao de conexes ponto-a-ponto que so visveis para aplicaes clien-te. Clientes se conectam ao barramento que serve como uma camada de mediao que protege os clientes de diferentes formatos e protocolo de mensagens usados em siste-mas backend1.

Um ESB tipicamente independente de plataforma no sentido de que executa em diferentes sistemas operacionais e neutro em relao a servidor de aplicao e lin-guagem de programao. O barramento permite conectar aplicaes Java, aplicaes .Net, brokers que requisitam objetos, alm de sistemas legados. A Figura 2, apresenta-da em [Papazoglou et al., 2007], descreve uma arquitetura simplificada de um ESB que integra uma aplicao J2EE usando JMS (Java Message Services), uma aplicao .NET em um cliente C#, uma aplicao MQ (Message Queue) que tem interface com aplica-es legadas, aplicaes externas e fontes de dados sendo acessadas via Servios Web em um mdulo de consultas distribudas. O ESB prov uma integrao mais eficiente entre diferentes componentes de aplicaes. Isso possvel, pois o ESB posiciona os componentes atravs de uma fachada orientada a servio, utilizando, por exemplo, web services. Na Figura 2, o mdulo de consultas distribudas usado para abstrair a complexidade de fontes de dados heterogneas. Todos os pontos finais apresentados na figura provem abstrao de destino fsico e informaes de conexo. Um portal um ponto de interface com o usurio que agrega variados recursos representados co-mo servios, por exemplo, vendas, funcionalidades departamentais, recursos huma-nos, alm de portais de parceiros do negcio.

Figura 2 Exemplo de Enterprise Service Bus [Papazoglou et al., 2007]

Assim como Papazoglou [2007], Hewitt [2009] apresenta o papel do ESB, ilustrado na Figura 3, caracterizando que o barramento coreografa interaes via mensagens uti-lizando diferentes tecnologias, tais como motor de regras (externo ou embutido), mo-

1 Backend qualquer sistema responsvel por um grupo especfico de dados e funcionalidades, por

exemplo: um banco de dados em um SGBD, mainframe, SAP, grupo de servidores JEEE, uma co-nexo com outra empresa. Do ponto de vista do negcio, um backend um sistema que tem um papel especfico e mantido por um grupo especfico. [Josuttis, 2007]

_______________________________________________________________________________________________


tor de orquestrao (utilizando BPEL ou XPDL), adaptadores para sistemas legados ou aplicaes empacotadas, e mecanismos de roteamento e transformao internos. Isto permite que todos os ns do barramento interajam sem ter que criar rotas especficas para cada aplicao, dessa forma reduzindo o custo de manuteno. Dado que o bar-ramento abstrai e realiza mediao entre os ns conectados, alguma flexibilidade al-canada; se for observada a necessidade de substituir uma aplicao por outra, pode-se fazer esta substituio com o mnimo de comprometimento com os clientes desta aplicao [Hewitt, 2009]. Basta manter as interfaces das conexes disponibilizadas no ESB.

Figura 3 O papel do ESB em SOA [Hewitt, 2009]

O ESB suporta a invocao de web services e outros ns de aplicaes preparadas para se comunicar atravs da rede. O ESB disponibiliza adaptadores para conectar com aplicaes empacotadas ou aplicaes legadas, oferecem roteamento robusto de mensagens, permitem orquestrao e transformao do contedo da mensagem, dentre outras funcionalidades.

2.1 Responsabilidades do ESB

As principais responsabilidades de um ESB apresentadas por Hewitt [2009] so descritas a seguir.

2.1.1 Suporte a web services

O ESB tem a capacidade de invocar web services baseados em WSDL2 e SOAP3, bem como servios POX4 (Plain Old XML) utilizando o protocolo http. POX correspondem a mensagens empacotadas apenas em XML, sem utilizar o protocolo SOAP.

2 http://www.w3.org/TR/wsdl

3 http://www.w3.org/TR/soap/

4 http://msdn.microsoft.com/en-us/library/aa395208.aspx

_______________________________________________________________________________________________


Em geral, criado um proxy WSDL para o servio que se quer expor no ESB. Os cli-entes, ao invs de se conectarem diretamente ao WSDL do servio, eles se conectam a um WSDL (proxy) exposto no barramento. Esta forma de conexo permite tratar lgica de roteamento e transformao dentro do barramento.

Ferramentas tratam este mecanismo de conexo de forma diferente. GlassfishESB5 trata este mecanismo diretamente no BPEL, enquanto que Aqualogic Service Bus6 permite a criao de um servio de proxy.

2.1.2 Adaptadores

Adaptadores so utilizados para conectar aplicaes que no suportam a interface SOAP ou XML, tais como, aplicaes empacotadas (SAP, PeopleSoft, SAP R/3, Siebel), banco de dados, ferramentas ERP, interfaces via arquivo.

Adaptadores podem ser utilizados tanto no caso da aplicao no fornecer integra-o via XML ou SOAP, como tambm nos casos em que se deseja um maior ganho de desempenho evitando o custo em tempo de execuo de traduzir para/de XML, se o sistema suporta diretamente serializao de objetos.

Em muitos casos adaptadores so fornecidos como uma funcionalidade que deve ser paga a parte, alm do ESB.

2.1.3 Invocao de servios

Como uma caracterstica padro, ESB suporta chamadas sncronas e assncronas de servios, e algumas vezes callback. Um servio pode ser mapeado em outro servio. Alguns ESBs permitem negociao atravs de WS-MetadataExchange7, tratando segu-rana, por exemplo.

A forma que servios se comunicam chamada de padres de troca de mensagens (ou MEP Message Exchange Pattern). Um MEP define a sequncia de mensagens em uma chamada de servio ou operao do servio, especificando a ordem, a direo e a cardinalidade das mensagens [Josuttis, 2007]. Existem diferentes tipos de MEP:

One-way: A operao recebe uma mensagem, mas no ir retornar uma res-posta.

Request-response: A operao recebe uma mensagem e ir retornar uma res-posta.

Solicit-response: A operao envia uma requisio e ir esperar uma resposta.

Notification: A operao envia uma mensagem, mas no ir esperar uma res-posta.

O ESB deve apoiar estes padres de troca de mensagens. Por exemplo, no padro Request-Response, apresentado na Figura 4, o consumidor envia mensagem para o ESB que faz o roteamento para o provedor do servio. Aps o processar a requisio, o provedor envia a resposta para o ESB que repassa a resposta para o consumidor do servio. O consumidor fica parado esperando a resposta, da mesma forma que seria na invocao de um mtodo de um componente de forma sncrona. O ESB deve ter a ca-

5 https://open-esb.dev.java.net/Downloads.html#

6 http://download.oracle.com/docs/cd/E13171_01/alsb/docs20/index.html

7http://specs.xmlsoap.org/ws/2004/09/mex/WS-MetadataExchange.pdf

_______________________________________________________________________________________________


pacidade de encontrar o provedor do servio, bem como fazer o roteamento da respos-ta para o consumidor que invocou o servio. Exemplos de MEPs e responsabilidades do ESB so apresentados em [Josuttis, 2007].

Figura 4 Exemplo de MEP Request-Response intermediado pelo ESB

2.1.4 Mediao e independncia de protocolo

Muitos barramentos permitem que diferentes protocolos de comunicao sejam utili-zados durante o caminho de uma mensagem, incluindo no apenas HTTP e JMS, mas tambm HTTPS, SMTP, XMPP, FTP dentre outros. Muitos barramentos tm a capaci-dade de conectar diferentes formatos de dados, por exemplo, Eletronic Data Inter-change (EDI), JDBC, COBOL copy books, e arquivos flat.

2.1.5 Roteamento

Barramentos disponibilizam diferentes formas de realizar roteamento de mensagens, por exemplo, a partir do contedo da mensagem (usando XPath para navegar na mensagem), roteamento baseado em um servio de regras e roteamento baseado em polticas.

Alguns barramentos permitem o controle de fila de mensagens a fim de que uma mensagem, quando enviada, seja persistida e no seja perdida. Este o princpio dos mediadores orientados a mensagens (ou MOM Message Oriented Middleware), tais como MQ e JMS [Josuttis, 2007].

2.1.6 Transformao

Dados representados em XML podem ser transformados utilizando XSLT e consulta-dos utilizando XQuery e XPath. Estas tecnologias permitem preparar o dado para ser trafegado entre sistemas/servios. Se um modelo cannico est sendo utilizado, esta uma caracterstica importante de existir no ESB.

_______________________________________________________________________________________________


2.1.7 Orquestrao

Muitos ESB realizam orquestrao atravs de um servio de proxy, o qual coordena a execuo de mltiplos servios. Alguns barramentos delegam a orquestrao para mo-tores BPEL ou XPDL.

2.1.8 Segurana

O barramento de servios prov funcionalidades para garantir o uso de polticas de segurana em conjunto com pontos de garantia de polticas, SSL e SAML8 (Security Assertion Markup Language).

2.1.9 Gerncia de servios

Servios executando no ESB podem ser monitorados, auditados, mantidos e reconfigu-rados. No ltimo caso, mudanas no processo podem ser feitas sem necessidade de reescrever servios ou aplicaes subjacentes, dependendo das modificaes necess-rias e dos servios existentes [Josuttis, 2007].

2.1.10 Modelo cannico

Dado que o ESB prov uma camada de abstrao, clientes podem se comunicar com o barramento, e no saberem a localizao do endpoint do servio com o qual realmente desejam se comunicar. Uma vez que a mensagem XML recebida no barramento, co-mo o ponto de integrao central, o barramento pode realizar as transformaes neces-srias para garantir, por exemplo, que um sistema legado de CRM integre facilmente com um novo sistema de uma empresa que foi adquirida. Esta transformao de da-dos deve ser feita a partir de um modelo que represente os dados de forma cannica, ou seja, como os dados devem ser estruturados conceitualmente de forma nica em relao s diferentes representaes existentes na organizao. Dessa forma, o barra-mento pode ser configurado para que sejam feitas transformaes das mensagens de solicitao (provenientes dos consumidores) para o modelo cannico, bem como a transformao da mensagem de resposta recebida proveniente dos provedores para o modelo cannico. Portanto, no barramento trafegam apenas informaes segundo o modelo cannico. Caso novos consumidores queiram se conectar ao provedor via bar-ramento, basta que seja implementada a transformao da mensagem do consumidor para o modelo cannico que ele conseguir se comunicar com o provedor. Este um exemplo de onde um modelo de dados cannico ganha real importncia, dado que o sistema cliente pode continuar se comunicando na forma que deseja, e o barramento serve para traduzir a mensagem para o formato esperado.

2.2 Benefcios do ESB

Hewitt [2009] aponta os seguintes benefcios em utilizar um ESB:

Reduo do tempo de integrao de aplicaes novas e aplicaes existentes;

Aumento de flexibilidade porque a dependncia entre servios reduzida;

Gesto simultnea e centralizada do catlogo de servios, enquanto que os prprios servios executam de forma distribuda;

8 http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=security

_______________________________________________________________________________________________


A gesto centralizada permite coletar mtricas sobre servios, permitindo mo-nitorar SLA (Service Level Agreements), gerar relatrios para TI e negcio;

Encoraja o uso de interfaces padro da indstria;

Maior agilidade e tempo de resposta para mudanas;

Obteno de informao atualizada e precisa sobre recursos da organizao via centralizao lgica da gesto de dados.

2.3 JBI

Hewitt [2009] apresenta que a especificao JBI (Java Business Integration), lanada pela SUN em 2005, foi uma proposta em direo a um ESB independente de fornece-dor. A arquitetura JBI suporta muito baixo acoplamento entre componentes. JBI define um metacontainer. Este metacontainer no executa nada por ele mesmo. Ele serve como um ponto de gesto de ciclo de vida para uma coleo de engines que so capazes de executar um tipo especfico de integrao, por exemplo, BPEL para orquestrao, co-nectores JDBC, conectores para arquivos etc. A idia que algum implementa uma especificao JBI e ento eles (ou outros fornecedores) podem implementar engines que so plugveis dentro do container.

2.3.1 Arquitetura JBI

JBI define o framework, as interfaces e o ciclo de vida abstrato que permite que compo-nentes conectados executem juntos e que sejam disponibilizados componentes escritos por desenvolvedores dentro deste ambiente. Para realizar este objetivo, JBI define qua-tro elementos principais (Figura 5): engine de servios (ou Service Engines SE), com-ponentes de ligao (ou Biding Component BC), roteador de mensagens normaliza-das (Normalized Message Router NMR) e ambiente de execuo (runtime eviron-ment).

Figura 5 Arquitetura JBI em alto nvel, como demonstrado pela especificao 1.0 [He-witt, 2009]

Engine de servios permitem conectar lgica, transformaes e processamento do negcio, por exemplo, SE para BPEL, SE para XLT. SE para SQL, agendamento etc.

_______________________________________________________________________________________________


Componentes de ligao oferecem independncia de protocolo. Eles provem pro-tocolos de transporte (e outro protocolos baseado em comunicao tais como protocolo para se comunicar com arquivos) para serem utilizados por servios externos. SE e BC criam um canal para o NMR. Eles agem como um proxy para servios publicados no componente de execuo JBI que precisam de um protocolo especfico. Existem BC pa-ra arquivo, LDAP, JMS, HTTP, JDBC, CICS, DCOM, CORBA, XMPP e outros.

O roteador de mensagens normalizadas media a troca de mensagens entre SEs e BCs dentro de um ambiente. O roteamento da mensagem determinado pelo NMR, e a mensagem normalizada traduzida no formato para o BC especfico que est sendo invocado. SEs e BCs se comunicam com o NMR via um pipe chamado de canal de en-trega (delivery channel). Uma mensagem normalizada composta de duas partes: a mensagem XML abstrata e os metadados da mensagem, tambm chamado de dados de contexto da mensagem.

O ambiente de execuo JBI engloba SE, BC e NMR, alm de um framework permi-tindo disponibilizao, gesto, monitoramento e instalao.

2.3.2 Como JBI tratado na indstria

Vrios fornecedores participaram da especificao JBI, tais como, membros da Apache Software Foundation, Borland, Fujitsu, JBoss, IONA, Oracle, SAP AG etc. Isto sugeri-ria que JBI o principal conceito para a implementao de um Enterprise Service Bus. No entanto, poucos fornecedores suportam JBI, devido a vrias razes: muitos forne-cedores perceberam que poderiam ter suas ferramentas SOA construdas pelo empa-cotamento de solues EAI previamente desenvolvidas; eles tinham suas prprias de-finies de um ESB; alm disso, a idia de suportar um SE ou um BC como um objeto capaz de conectar de um JBI para outro no estava completamente clara. Alm disso, existe uma limitao em JBI de que todos os contratos dos servios sejam especificados em WSDL. Isto no funciona para contratos WADL, que podem se tornar populares para POX/HTTP, ou Java puro. Outro problema levantado o container JBI especifi-car que a mensagem deve ser no formato XML, o que traz carga desnecessria para mensagens que no so baseadas em XML.

Dessa forma, fornecedores trabalharam no desenvolvimento de suas prprias SEs e BCs para HTTP, FPT, JMS, arquivo, BPEL etc. Apesar disto, existem boas implementa-es de JBI. No entanto, estas implementaes no so os ESBs mais populares.

JBI algo importante de conhecer. Ele pode ser uma boa estratgia para iniciar a construo de um SOA com ferramentas de cdigo fonte aberto durante o perodo de investigao e ento se formar para obter um ESB mais robusto, estvel e com maior desempenho.

2.4 ESBs comerciais e de cdigo aberto

Hewitt [2009] apresenta um estudo dos principais ESB dos fornecedores de mercado e aponta como lderes de mercado os seguintes ESB: IBM WebSphere ESB e DataPower; Sonic ESB; TIBCO BusinessWorks e ActiveMatrix Grid; Cape Clear. J como ESBs de cdigo aberto, ele destaca o OpenESB da Sun, Mule ESB da MuleSource, e Apache ServiceMix. Devido ao interesse do projeto na avaliao das ferramentas da Ora-cle/BEA, algumas das caractersticas do Oracle Service Bus so resumidas a seguir.

No final de 2007, BEA lanou o AquaLogic Service Bus(ALSB). Aps a compra da BEA pela Oracle, nos meados de 2008, o barramento foi rebatizado como OSB (Oracle

_______________________________________________________________________________________________


Service Bus) 10.3. O produto anterior da Oracle, chamado de Oracle Enterprise Service Bus, ser mantido, mas no ser mais promovido. Dentre as caractersticas do OSB, destacam-se:

Ferramenta para desenvolvimento baseada no Eclipse, chamada Oracle Ser-vice Bus WorkSpace Studio;

Tratamento de falhas na chamada de servios (tanto roteamento como poo-ling de mensagens);

Otimizao de transporte de mensagens: permite que o container trate EJBs remotos que esto posicionados na mesma JVM com os consumidores invo-cando os servios como se fossem EJBs locais. Esta otimizao de desempe-nho evita chamadas RMI, as quais so mais custosas.

Suporte a WS-ReliableMessaging: permite tanto o reenvio de mensagens das quais no se sabe se a resposta foi enviada, devido a falhas no meio de transporte, como tambm reenvio de mensagens aps falha do cliente ou do servidor.

Os servios so divididos em dois tipos: servios de proxy e servios de ne-gcio. Um servio de proxy exposto ao cliente e serve como um wrapper para a implementao do servio, a qual prov transparncia de localizao e um oportunidade para injetar vrias funcionalidades como segurana, transformao etc. Um servio de negcio um conjunto de metadados para um servio que est externo ao barramento.

SOAP usado como formato de mensagem cannica interno ao barramento, logo, mesmo que uma mensagem no SOAP enviada ao barramento, ela transformada em uma mensagem SOAP a fim de que seja possvel utilizar XQuery e XPath de forma padronizada atravs da interface.

OSB permite definir SLA (Service Level Agreement) e aplic-los/monitor-los em tempo de execuo nos fluxos de mensagens que atravessam o barra-mento. Isto feito atravs de regras de alerta que indicam quando o barra-mento deve sinalizar por uma violao de uma SLA. O barramento j vem com um conjunto de alertas previamente cadastrados. Os alertas podem ser configurados no s para indicar falhas como tambm para indicar quando o sistema est comeando a alcanar limites de desempenho.

Criao de relatrios a partir da situao das SLAs do barramento permitin-do realizar pesquisas sobre o mesmo.

Permite segurana ao nvel de mensagem e de transporte. O barramento disponibilizado com um conjunto arquivos XML WS-Policy que facilita a aplicao de polticas de segurana nos servios

Suporta as especificaes: WS-Policy, WS-RealiableMessaging, XACML, WS-Addressing, SCA, XPDL, SAML, PKI.

O OSB no implementa JBI, BPEL4People ou WS-HumanTask. Se o objetivo for cri-ar processos de negcio que envolva automao de servios bem como tarefas huma-nas, ento melhor olhar a sute BPM.

Um estudo das funcionalidades do ALSB apresentada em [Souza et al., 2009].

Alm do Oracle Service Bus, Hewitt [2009] apresenta as principais caractersticas do Software AG/webMethods ESB, TIBCO ActiveMatrix e BusinessWorks.

_______________________________________________________________________________________________


3 Arquitetura do Oracle Service Bus

O Oracle Service Bus (OSB) [OSB, 2009a] corresponde nova verso desenvolvida pela Oracle da ferramenta ALSB (AquaLogic Service Bus) que pertencia BEA e que foi descontinuada aps a compra da BEA pela Oracle. Maiores detalhes sobre o ALSB po-dem ser encontrados em [Souza et al., 2009].

A instalao do OSB pode ser baixada a partir do link http://download.oracle.com/docs/cd/E13196_01/platform/suppconfigs/config_alsb.html, onde se encontram tambm os links para download das verses anteriores do ALSB.

3.1 Sute de produtos do OSB

A Oracle possui uma sute de produtos que pode ser compartilhada via Oracle Service Bus [OSB, 2008a] (Figura 6):

Oracle User Interaction: permite a criao de solues contemplando infraes-trutura de servios, incluindo portais e aplicaes compostas.

Oracle Business Process Management: inclui automatizao, execuo e mo-nitoramento do ciclo de vida de processos de negcio como um todo.

Oracle Data Service Integrator: permite a criao de servios de dados que disponibilizam vises unificadas e em tempo real dos dados em diferentes fontes de dados espalhadas pela organizao

Figura 6 Arquitetura de produtos compartilhados via OSB [OSB, 2008a]

A Figura 7 apresenta os produtos da Oracle que tm relevncia em uma Arquitetu-ra Orientada a Servios. Dentre estes produtos destacam-se os produtos para desen-

_______________________________________________________________________________________________


volvimento de portais (Oracle WebLogic Portal e Oracle WebCenter Interaction), para a camada de processos (Oracle WebLogic Integrator e Oracle Business Process Mana-gement), servios de segurana (Oracle Enterprise Security), servios de dados (Oracle Data Services Platform) e registro de servios (Oracle Service Registry).

Figura 7 Produtos da Oracle separados em camadas

Segundo [OSB, 2008a], o Oracle Service Bus atende ao estgio de execuo, em um ciclo de vida de desenvolvimento de servios, tratando as seguintes atividades:

Publicao e proviso do servio;

Gesto e monitoramento do fluxo de mensagens entre consumidores e prove-dores;

Separao de usurios e processos das mudanas dos servios;

Abstrao de servios e remoo de lgica de integrao;

Transformaes, validao e roteamento;

Visibilidade e gesto operacional do servio.

Analisando a proposta de ciclo de vida de servios de Gu e Lago [2007], apresenta-do na Figura 8, podemos notar a aderncia das atividades propostas de serem realiza-das no OSB em relao a este ciclo de vida. Alm disso, o barramento tambm pode ser utilizado na fase de projeto em relao aos seguintes aspectos:

Pesquisa por servios, utilizando o console do ESB;

Implementao de servios de proxy;

Implementaes de orquestraes de servios utilizando os fluxos definidos nos servios de proxy;

Implementaes de transformaes para tornar a comunicao entre consumi-dor-provedor menos dependente;

Definies de roteamento de servios;

Realizao de testes de servios e orquestraes atravs do console de teste.

_______________________________________________________________________________________________


Provedorde servio

Broker deservio

Provedorde aplicao

(Consumidorde servios)

Mapeamentode mercado

Engenhariade requisitos

Modelagemde negcio

Projeto deservio

Desenvolvimentode servio

Teste deservio

Engenhariade requisitos

Projeto daaplicao

Implementaoda aplicao

Teste demodulo

Publicaode servio

Provisode servio

Monitoraode servio

Gerenciamentode servio

Descobertade servio

Orquestrao/composio

de servio

Negociaode servio

Invocaode servio

Teste daaplicao

Monitoraode servio

Manutenoda aplicao

Seleode registro

Atualizaode registro

Manutenode registro

Projeto Execuo Mudana

Figura 8 Ciclo de vida para servios [Gu e Lago, 2007]

As principais caractersticas do OSB so:

Integrao de servios: integrao de endpoints, broker de mensagens e medi-ao e exposio de servios para reuso.

Segurana de servios: autenticao e autorizao, validao da identidade do usurio.

Composio de servios: configurao da lgica de roteamento da mensa-gem, transformao de mensagens, configurao, validao e registro de servios.

Gesto de servios: monitoramento e gesto das atividades e disponibilida-de dos servios.

3.2 Componentes da arquitetura do OSB

A arquitetura do OSB pode ser dividida em 4 camadas:

Camada de transporte: permite integrar servios desenvolvidos utilizando diferentes protocolos. Os protocolos de comunicao que podem ser utiliza-dos no OSB so:

o HTTP/SOAP

o WS-I, WS-Security, WS-Policy, WS-Addressing

o SOAP v1.1 e v1.2: o OSB aceita mensagens de entrada em SOAP v1.1 e ele transforma a mensagem para SOAP v1.2 se for necessrio, por exemplo, para se conectar com um servio que se comunica via SO-AP v1.2.

o EJB/RMI no WebSphere

o Permite a criao e a customizao de protocolos especficos da or-ganizao, bem como usar protocolos nativos do Oracle, por exem-plo, Oracle Data Service Integrator.

Camada de segurana (Figura 9): permite os seguintes nveis de segurana:

_______________________________________________________________________________________________


o Segurana no transporte da mensagem: SSL/Basic Auth

o Segurana na mensagem: WS-Policy/WS-Security, SAML, UserID/Password, X509, Signing & Encryption, e Custom security credentials

o Segurana de console: suporta Web Single-Sign-On e acesso baseado em perfis

o Polticas: WS-Security e WS-Policy

Figura 9 Camada de segurana

Camada para composio de servios (Figura 10): esta camada inclui a mo-delagem do fluxo de servios, alm de atividades de descoberta de servios em UDDI, validao, transformao, testes da orquestrao, alm da especi-ficao de service callout. Service callout corresponde a uma ao que invoca um determinado servio de acordo com o contedo da mensagem.

_______________________________________________________________________________________________


Figura 10 Camada de composio

Camada para monitoramento de servios (Figura 11): permite realizar go-vernana sobre as mensagens que trafegam pelo barramento disponibili-zando: dashboard, monitoramento, definio de alertas, relatrios, verifica-o de SLA etc.

_______________________________________________________________________________________________


Figura 11 Camada de gesto

3.3 Fluxo de mensagens via servios de proxy

O OSB um intermedirio que processa mensagens de entrada para requisio de ser-vios, determina a lgica de roteamento, e transforma estas mensagens para compati-bilidade com outros consumidores de servios. Ele recebe mensagens atravs de pro-tocolos de transporte, tais como HTTP(S), JMS, Arquivos e FTP, e envia mensagens atravs do mesmo protocolo ou de protocolos diferentes. A mensagem de resposta do servio segue um caminho inverso. O processamento de mensagens pelo OSB direci-onado a metadados, especificados na definio do fluxo de mensagens de um servio de proxy. Servio de proxy o conceito fundamental na arquitetura do OSB. Eles cor-respondem interface que consumidores utilizam para se comunicar com servios de back-end gerenciados.

A Figura 12 ilustra em alto nvel o fluxo de mensagens atravs do OSB, a partir de um endpoint de entrada (para um servio de proxy) para um endpoint de sada (URL de outro servio um servio de negcio ou um servio de proxy).

_______________________________________________________________________________________________


Figura 12 Processamento de mensagens

Trs camadas esto envolvidas no fluxo de mensagens (Figura 13):

Camada de transporte (transport layer):

o Recebe o stream de dados da requisio do cliente (ou consumidor);

o Envia o stream de dados da requisio para o provedor;

o Recebe o stream de dados da resposta do provedor;

o Envia o stream de dados da resposta para o cliente (ou consumidor).

Camada de ligao (binding layer):

o Desserializa e serializa mensagens, quando necessrio;

o Trata questes de segurana da mensagem;

o Manipula mensagens para iniciar fluxo de mensagens (requisio e resposta)

Servio de proxy (proxy service)

o Servios de proxy so definies de web services intermedirios que o OSB implementa localmente

o O OSB permite a definio de servios de proxy pela definio de sua interface via WSDL (Web Services Description Language) e o ti-po de transporte que ele utiliza.

_______________________________________________________________________________________________


o A lgica de processamento da mensagem especificada na definio do fluxo da mensagem quando um servio de proxy definido.

o O contexto de um servio de proxy um conjunto de variveis XML que so compartilhadas ao longo do fluxo do servio.

Variveis podem conter informaes a respeito de:

Mensagem

Cabealhos de transporte

Princpios de segurana

Metadados para o servio de proxy

Metadados para roteamento primrio

Servios invocados pelo servio de proxy

O contexto pode ser lido ou modificado por expresses XQuery e atualizado por transformaes e aes de atualiza-o

As variveis principais do context so: $header (SOAP), $bo-dy (SOAP) e $attachments (MIME - Multipurpose Internet Mail Extensions)

O contexto d a impresso de que todas as mensagens so SOAP. Mensagens no-SOAP so traduzidas para este para-digma.

Como um servio de proxy pode rotear mensagens para ml-tiplos servios de negcio, um servio de proxy pode ser con-figurado com uma interface que independente do servio de negcio ao qual ele se comunica.

Figura 13 Camadas do fluxo de mensagens

A maior parte da lgica de processamento em um fluxo de mensagem tratada em pipelines. Um pipeline uma sequncia nomeada de estgios representando um cami-nho de processamento em uma nica direo sem ramificaes. Um estgio um pas-so de processamento configurado pelo usurio. Mensagens de entrada para pipelines so acompanhadas de um conjunto de variveis de contexto da mensagem que con-tm contedos da mensagem. Elas podem ser acessadas ou modificadas por aes dentro do estgio do pipeline.

_______________________________________________________________________________________________


Pipelines pertencem a uma das seguintes categorias:

Pipeline de requisio processa o caminho de requisio do fluxo da mensa-gem;

Pipeline de resposta processa o caminho de resposta do fluxo de mensagem;

Pipeline de erro trata erros para estgios e ns em um fluxo de mensagem to bem como erros no nvel do fluxo da mensagem (servio).

Os seguintes elementos so utilizados para construir um fluxo de mensagens:

N inicial: Toda mensagem comea com um n inicial. Todas as mensagens en-tram no fluxo de mensagem atravs do n incial, e todas as mensagens de res-postas so retornada para o cliente atravs do n inicial. No existe nada para ser configurado no n inicial.

Par pipeline: um n par pipeline combina um pipeline de requisio e um pipeline de resposa em elemento de alto nvel. Um n par pipeline pode ter apenas um descendente direto no fluxo da mensagem. Durante processamento de requisi-o, apenas o pipeline de requisio executado quando o OSB procesa o n par pipeline. O caminho de execuo o inverso quando o OSB processa o pipeline de resposta. Consistem de sequncia de estgios que especificam aes a serem realizadas durante o processamento de request e response.

Estgios: pipelines de requisio, pipelines de resposta, e tratadores de erros po-dem conter estgios, onde podem ser configuradas aes para manipular men-sagens passando atravs do pipeline.

Tratamento de erro: Um tratamento de erro pode ser includo em qualquer n ou estgio para tratar erros potenciais naquele local.

N de diviso: permite a diviso do fluxo de acordo com partes da mensagem, contexto da mensagem, ou baseado na operao invocada. Um nico caminho escolhido dentre diferentes caminhos.

N de roteamento: um n de roteamento realiza comunicao de requisi-o/resposta com outro servio. Ele representa o limite entre o processamento da requisio e resposta para o servio de proxy. Quando o n de roteamento dispara uma mensagem de requisio, o processamento de requisio consi-derado completo. Quando o n recebe uma mensagem de resposta, o proces-samento da resposta comea. O n de roteamento suporta roteamento condici-onal bem como transformaes de requisio e resposta. Dado que o n de ro-teamento representa o limite entre o processamento da requisio e resposta, ele no pode ter nenhum descendente no fluxo da mensagem. Logo, ele usa-do para definir o destino da mensagem.

Aes: Aes proveem instrues para tratamento de mensagens em estgios de pipelines, estgios de tratamento de erros e ns de roteamento. Aes podem ser dos seguintes tipos. Maiores detalhes so apresentados em [OSB, 2009e].

o Aes de comunicao: controlam o fluxo de mensagens e podem ser caracterizadas como de publicao dinmica, de publicao, tabela de publicao, opes de roteamento, callout para servios, cabealhos de transporte.

o Aes de controle de fluxo: implementam roteamento condicional, looping condicional e tratamento de erro. Podem ser utilizadas para no-

_______________________________________________________________________________________________


tificar o requisitante de sucesso ou para pular (skip) o resto das aes em um estgio. Aes de controle de fluxo podem ser do tipo for each, if... then..., levantamento de erro, resposta, resume, skip.

o Aes de processamento de mensagens: aes nesta categoria proces-sam o fluxo das mensagens, tais como: assign, delete, insert, Java callout, transformao MLF, rename, replace, validate. Em particular, a ao vali-date valida elementos selecionados por uma expresso XPath em relao a um elemento de um XML Schema ou um recurso WSDL. Podem ser validados apenas elementos de variveis globais; OSB no suporta vali-dao de elementos locais.

o Aes de relatrio: so usadas para registrar ou reportar (log ou report) erros e alertas gerados, se necessrio em um fluxo de mensagem dentro de um estgio. Elas podem ser dos tipos: alert, log e report. Diferente de alertas de SLA, notificaes geradas por aes de alerta so ligadas mais ao negcio, ou erros de report, e no para monitoramento do sistema. Destinos de alertas devem ser configurados tendo isto em mente.

A Figura 14 apresenta um exemplo de fluxo de mensagem. Nesta figura tm-se um pipeline de requisio em um nvel de servio nico que ramifica em pipelines operacio-nais (pode-se configurar um pipeline padro para uma operao, mas no mximo um pipeline). A determinao da operao feita via critrios do usurio.

Processamento da requisio:

o O processamento da requisio comea no n inicial.

o Em seguida, o par pipeline executa apenas o processamento da requisi-o.

o O n de deciso (n branch), avalia a tabela de deciso para o fluxo que foi avaliado como verdadeiro.

o O n de roteamento realiza o roteamento juntamente com qualquer transformao da mensagem de requisio que tenha sido definida.

No fluxo de mensagem, independente se o roteamento exista ou no, o n de roteamento representa a transio do processamen-to de uma requisio para o processamento da resposta. No n de roteamento, a direo do fluxo de mensagem invertida. Se um caminho de requisio no tem n de roteamento, o proces-samento da respostas iniciado no sentido inverso sem esperar por qualquer resposta.

Processamento da resposta:

o O n de roteamento executa qualquer transformao da resposta que tenha sido definida;

o O n de diviso pula qualquer n de diviso e continua com o n que precede a diviso;

o O par pipeline executa o pipeline da resposta;

o O n inicial envia a resposta de volta para o cliente.

_______________________________________________________________________________________________


Figura 14 Exemplo de fluxo de mensagem

Transformaes podem ser definidas antes de a mensagem ser enviada para o end-point selecionado ou aps a resposta ser recebida [OSB, 2009c].

Processamento para tratar questes de segurana (WS-Security) e autorizao po-dem ser utilizados ao invocar servio com WS-Policy [OSB, 2009d].

3.4 WSDL efetivos e WSDL gerado

Um documento WSDL descreve um servio, sua localizao, suas operaes, e o modo no qual clientes podem se comunicar com ele.

No OSB, novos servios de proxy e novos servios de negcio podem ser baseados em WSDL (chamados recursos WSDL) e ento sobrescrever ou adicionar proprieda-des de configurao.

Para servios baseados em WSDL, OSB usa WSDL efetivos ao invs dos arquivos .wsdl originais. Um WSDL efetivo representa propriedades de um WSDL de servio considerando as configuraes do OSB.

Ao criar um servio baseado em um WSDL, o OSB cria um WSDL efetivo. WSDL efetivos podem ser criados a partir dos seguintes tipos de servios de negcio ou de

_______________________________________________________________________________________________


proxy: servios SOAP criados a partir de WSDL e servios XML criados a partir de WSDL.

Outro tipo de WSDL importante a ser considerado o WSDL gerado, o qual um WSDL efetivo que o OSB gera para servios de tipo de transporte que no foram cria-dos a partir de um recurso WSDL, mas que podem ser descritos usando WSDL. Por exemplo, um WSDL gerado a partir de um servio baseado em EJB um WSDL gera-do.

O OSB permite exportar o WSDL efetivo. A exportao gera um arquivo .zip que contm o WSDL efetivo juntamente com suas dependncias, incluindo esquemas e WS-Policies. OSB avalia as dependncias, e a localizao apropriada adicionada no atributo location do elemento import do WSDL. No existe elemento import para WS-Policies. Neste caso, as referncias para as polticas so retidas e o recurso da poltica includo na exportao. WSDL gerado no pode ser exportado.

Maiores detalhes a respeito das caractersticas que se aplicam a WSDL efetivos ge-rados para servios de proxy, WSDL efetivos gerados para servios de negcio sem tipo de transporte, WSDL efetivos gerados para servios de negcio com tipo de transporte e WSDL efetivos gerados em domnios de cluster, alm de servios basea-dos em uma porta, servios baseados em binding so apresentados em [OSB, 2009e].

3.5 Web services com atributo style igual a SOAP document RPC

Um web service empacotado como documento descrito em um arquivo WSDL como um servio com estilo (Style) Document. Como padro, uma operao de um web ser-vice orientado a documento pode ter apenas um parmetro ou tipo de mensagem, ti-picamente um documento XML. Isto significa que os mtodos que implementam as operaes devem ter apenas um nico parmetro. Entretanto, operaes de web servi-ces empacotados em documento podem ter qualquer nmero de parmetros, embora os valores dos parmetros sejam empacotados em um nico tipo de dados complexo na mensagem SOAP. Este tipo de dados complexo empacotado ser descrito no WSDL como um nico documento para a operao. A Figura 15 apresenta um exemplo de WSDL de servio orientado a documento, enquanto que a Figura 16 e a Figura 17 apresentam o corpo ($Body) das mensagens de requisio e respostas do servio, res-pectivamente. Na Figura 16, soap-env namespace SOAP 1.1 prfinido e req o na-mespace do elemento PurchaseOrg (http://example.com/lookup/docs).

_______________________________________________________________________________________________


Figura 15 Exemplo de WSDL de servio orientado a documento

Figura 16 Exemplo de mensagem SOAP de requisio do servio orientado a docu-mento

Figura 17 Exemplo de mensagem SOAP de resposta do servio orientado a documen-to

true

Oracle

_______________________________________________________________________________________________


No caso do estilo de binding ser RPC, a operao do servio recebe um conjunto de parmetros na requisio e retorna como resposta um conjunto de parmetros. A Fi-gura 18 apresenta um exemplo de WSDL de servio com estilo RPC, enquanto que a Figura 19 e Figura 20 apresentam o corpo ($Body) das mensagens de requisio e res-postas do servio, respectivamente. O elemento soap-env corresponde ao namespace predefinido em SOAP 1.1, ns o namespace da operao (http://example.com/lookup/service) e req o namespace do elemento PurchaseOrg (http://example.com/lookup/docs).

Figura 18 Exemplo de WSDL de servio com estilo RPC

Oracle

_______________________________________________________________________________________________


Figura 19 Exemplo de mensagem SOAP de requisio do servio com estilo RPC

Figura 20 Exemplo de mensagem SOAP de resposta do servio com estilo RPC

3.6 Padres de troca de mensagens

O OSB permite os seguintes tipos de comunicao de mensagens:

Requisio/resposta sncrona: cliente envia a requisio e fica esperando a resposta do provedor.

Publicao um-para-um assncrona: um cliente se publica como consumidor de um servio, e o servio envia a sua resposta para o cliente publicado aps a execuo da operao para a qual o cliente foi publicado.

Publicao um-para-muitos assncrona: vrios clientes se publicam como consumidores de um servio, e o servio envia a sua resposta para os clien-tes publicados aps a execuo da operao para o qual os consumidores fo-ram publicados.

Requisio/resposta assncrona (ponte de sncrono para assncrono).

o Cliente sncrono envia requisies para provedor assncrono, e clien-te fica aguardando a resposta

o OSB prov uma fila JMS para a mensagem de requisio e configura outra fila para a mensagem de resposta, com um valor de timeout pa-ra a resposta. As filas so utilizadas para simular troca de mensagens sncrona.

o Para o cliente a invocao do servio sncrona

3.7 Broker de mensagens

O OSB tem como um dos seus componentes principais o broker de mensagem. Ele permite o roteamento de mensagens baseado em contedo e transformaes de dados, incluindo as seguintes caractersticas operacionais:

Polticas baseadas em XQueries ou callouts para servios externos para rote-amento de mensagens.

o A ao de callout de servio usada dentro de um estgio de rotea-mento de fluxo de servio para chamar um servio de destino para realizar alguma ao na mensagem. A funcionalidade de Service Callout do OSB suporta, por exemplo, a codificao RPC e substitui-o de URL e extensvel pelo uso de Java Callouts e POJOs. Maio-res detalhes sobre Service Callout podem ser encontrados em [OSB, 2009b].

true

_______________________________________________________________________________________________


Tabela de roteamento fora do servio de proxy, a qual permite a modificao das rotas sem ter que re-configurar definies de servio de proxy;

Roteamento baseado em identidade: permite classificar clientes em um gru-po de usurios definido e aplicar polticas de roteamento para estes grupos.

3.8 Transformao e processamento de mensagens

O Oracle Service Bus suporta as seguintes funcionalidades para transformao ou pro-cessamento de mensagens:

Validao de mensagens de entrada de acordo com schemas;

Seleo de um ou mais servios, baseado no contedo ou no cabealho da mensagem;

Transformao de mensagens baseado no servio de destino;

Transformao de mensagens baseado em XQuery ou XSLT;

Suporta transformaes em mensagens nos formatos XML e MFL. MFL (Message Format Language) um formato de mensagem proprietrio da Oracle/BEA. Linguagem usada para descrever como transformar dados bi-nrios em XML. A ferramenta Oracle Format Builder a ferramenta para criar mensagens no formato MFL.

Suporta chamadas de Web services para obter dados adicionais para trans-formao (por exemplo, cdigo do pas, registros de cliente etc.)

O OSB possui um a funcionalidade chamada de Database Lookup atravs de uma funcionalidade do motor de XQuery do OSB. O Database Lookup corresponde execu-o de leitura em base de dados a partir de servios de proxy atravs do uso da funo execute-sql para realizar uma chamada JDBC a um banco de dados para realizar uma leitura simples do banco de dados. Dessa forma, no h necessidade de escrever um EJB customizado ou cdigo Java customizado e sem a necessidade do uso de um com-ponente separado como Oracle Data Service Integrator. O Database Lookup deve ser uti-lizado para inserir dados na mensagem, para ler dados para decises de roteamento e para customizar comportamento do servio de proxy.

OSB prov transporte otimizado para comunicao invocando servios no Oracle Data Service Integrator. Isto permite uma abordagem mais eficiente e flexvel para acessar servios de dados do que exp-los como web services via WebLogic Workshop ou Java Web Services (JWS). Alm disso, esta ferramenta suporta segurana e propa-gao de identidade.

Duas ferramentas para transformao de dados so instaladas com o OSB e Workshop for WebLogic, o Oracle XQuery Mapper como plug-in para o Eclipse 3.1 e Format Builder. O Eclipse 3.1 e o Format Builder so suportados apenas nas platafor-mas Windows.

3.9 Disponibilizao de EJB como servio

Um EJB pode ser exposto como um web service, sem a necessidade de ferramentas ou modificaes de cdigo legado no servidor de aplicao onde o EJB est disponibiliza-do. O mecanismo de transporte EJB tem as seguintes capacidades:

_______________________________________________________________________________________________


Integridade transacional: O transporte EJB pode invocar servios de negcio no contexto de uma transao global e podem tambm ser suspensos ou ini-ciar uma transao global antes de invocar um EJB.

Propagao de segurana: Uma requisio SOAP sobre HTTP para o OSB autenticada pelo OSB e o assunto autenticado pode ser propagado para o servidor EJB.

Provedor JNDI: o transporte EJB disponibiliza um provedor JNDI, o qual pode ser reutilizado por mltiplos servios de negcio EJB. Isto prov um mecanismo centralizado para administradores gerenciarem configuraes do servidor EJB remotamente.

Caching de alto desempenho: o transporte EJB construdo com um cache de alto desempenho e permite o reuso de conexes estabelecidas e minimiza lookups de stubs EJB.

Tratamento de falhas e balanceamento de carga: o transporte EJB pode to-mar vantagem de cenrios onde o mesmo EJB est instalado em mltiplos domnios ou em um cluster para balanceamento de carga e/ou tratamento de falhas.

XML avanado para capacidade de ligao Java: o transporte EJB disponibi-liza uma stack JAX-RPC para realizar ligao XML para Java;

Retries inteligentes: o transporte EJB toma decises de retries baseado na na-tureza da falha que pode ocorrer durante a invocao de um EJB.

3.10 Console de teste

O OSB disponibiliza um console de teste que pode ser utilizado para validar recursos e expresses XQuery usadas em fluxos de mensagens. Os objetos a serem testados po-dem ser: servio de proxy, servio de negcio, Xquery, XSLT e recurso MFL. A funcio-nalidade permite rastrear o fluxo da mensagem quando da execuo do teste de um servio e examinar o estado da mensagem em pontos especficos do teste.

Podem ser testadas partes especficas de um sistema de forma isolada ou pode ser testado o sistema como uma unidade. A forma de invocar o teste pode ser utilizando: Project Explorer, Resource Browser ou XQuery Editor.

3.11 Gesto de recursos

As seguintes funcionalidades so disponibilizadas pelo OSB para gesto de recursos:

Armazenamento de informaes sobre servios, esquemas, transformaes, WSDL e WS-Policies;

Permite navergar por servios registrados no OSB;

Permite propagao de configurao de dados entre ambientes (p.e., ambi-ente de teste para ambiente de produo).

O OSB prov APIs para customizao de: definies de servio; WSDL; Schemas; XQueries; etc.

Recursos podem ser visualizados atravs dos seguintes formatos de URL:

http://host:port/sbresource?WSDL/project/...wsdlname

_______________________________________________________________________________________________


http://host:port/sbresource?POLICY/project/...policyname

http://host:port/sbresource?MFL/project/...mflname

http://host:port/sbresource?SCHEMA/project/...schemaname

http://host:port/sbresource?PROXY/project/...proxyname

http://host:port/sbresource?BIZ/project/...business_service_name

3.12 OSB e UDDI

Servios de proxy podem ser publicados em qualquer UDDI 3.0 (incluindo Oracle Service Registry). Servios publicados no OSB podem ser automaticamente publicados no UDDI. Alternativamente, pode-se definir a necessidade de aprovao quando um servio for alterado no UDDI. Definies de servios podem ser importadas do UDDI.

3.13 Tratamento de erros

Mensagens de erros podem ser customizadas para serem retornadas para consumido-res dos servios. Tratamentos de erros podem ser configurados para: estgios de pipeline; pipeline inteiro; servios de proxy. Alertas podem ser enviados de acordo com o contedo da mensagem.

3.14 Versionamento

O OSB permite disponibilizar novas verses de servios. Mltiplas verses de recursos de mensagens (p.e., WSDL, esquemas, parmetros de segurana) podem coexistir no OSB.

3.15 Monitoramento

O barramento permite configurar alertas para as regras de SLA definidas sobre os ser-vios, por exemplo: mdia de tempo de processamento de um servio; volume proces-sado; nmero de erros; violaes de segurana e erros de validao de esquema.

3.16 Disponibilizao do OSB em servidores

OSB pode ser disponibilizado em um servidor nico ou em mltiplos servidores (clu-ster de servidores) (Figura 21).

_______________________________________________________________________________________________


Figura 21 Formas de implantao do OSB

Quando disponibilizado em um cluster, os outros servidores so gerenciados a par-tir do servidor central (Figura 22).

Figura 22 Gerenciamento do OSB disponibilizado em um cluster de servidores

OSB permite gesto controlada para publicao de servios em diferentes ambientes (teste, preparao para promoo, produo). O processo pode ser automatizado pela implementao de programas Java ou scripts. As configuraes podem ser exportadas em arquivos JAR de um OSB para outro OSB, sendo que a importao pode ser cus-tomizada para importar apenas o que se deseja. Tarefas de implantao podem ser customizadas utilizando a ferramenta WebLogic Server Scripting Tool9.

9 http://download.oracle.com/docs/cd/E12840_01/wls/docs103/config_scripting/reference.html

_______________________________________________________________________________________________


3.17 Outros conceitos importantes

Alm dos conceitos abordados, outros conceitos importantes em relao ao OSB so listados a seguir, incluindo links para documentao onde maiores detalhes podem ser encontrados.

Transformao de dados utilizando o XQuery Mapper: http://download.oracle.com/docs/cd/E13159_01/osb/docs10gr3/userguide/modelingmessageflow.html

Segurana (Oracle Service Bus Security Guide): http://download-llnw.oracle.com/docs/cd/E13159_01/osb/docs10gr3/security/index.html

Console de teste: http://download.oracle.com/docs/cd/E13159_01/osb/docs10gr3/userguide/testing.html

MFL (Message Format Language): http://download.oracle.com/docs/cd/E13159_01/osb/docs10gr3/consolehelp/mfls.html

Implementaes especficas atravs de uso de APIs: http://download.oracle.com/docs/cd/E13159_01/osb/docs10gr3/userguide/appendixAPIs.html

Definio de papis para tratamento de monitoramento no OSB: http://download.oracle.com/docs/cd/E13159_01/osb/docs10gr3/operations/index.html

Guia e melhores prticas sobre implantao de servios utilizando o OSB: http://download.oracle.com/docs/cd/E13159_01/osb/docs10gr3/deploy/index.html

4 Anlise prtica do Oracle Service Bus

Esta seo apresenta anlises prticas do Oracle Service Bus (OSB).

4.1 Publicao do servio no OSB

Esta seo descreve os testes de publicao do servio no OSB e uso do mesmo pelo cliente implementado utilizando o Workshop for WebLogic Platform. Um passo a pas-so detalhado para publicao de servios no OSB apresentado em [Souza et al., 2008, 2009].

A publicao de servios no barramento compreende duas etapas. Em primeiro lu-gar, necessrio realizar o deploy das aplicaes no servidor de aplicao WLS e, em seguida, publicar as interfaces de servios (WSDL) no OSB. O primeiro passo neces-srio, uma vez que o servio ser executado no mesmo WLS que est a sua interface. Para realizar esta etapa, o arquivo .Jar do servio foi gerado e instalado no WLS. A Figura 23 apresenta o resultado da instalao do servio no WLS.

_______________________________________________________________________________________________


Figura 23 Arquivo JAR do servio publicado no WLS

Em seguida, no OSB (Oracle Service Bus), foi criado o projeto UnidadeOperativaPrj e o arquivo WSDL do servio foi publicado como um recurso deste projeto. A Figura 24 apresenta o resultado da publicao do WSDL do servio no OSB.

Figura 24 Publicao do WSDL do servio no OSB

Aps a publicao do arquivo WSDL do servio, o barramento est parcialmente preparado, pois uma particularidade do OSB que, ao publicar os WSDL, o servio no disponibilizado. Para que o servio seja disponibilizado realmente no barramen-to, necessrio criar um recurso chamado Business Service e associar esse recurso ao WSDL que foi adicionado ao projeto. O Business Service corresponde configurao, no barramento, de um servio cuja execuo ocorre fora do barramento. O Business Service foi criado a partir do WSDL publicado anteriormente, como apresentado na Figura 25. O endpoint do servio http://localhost:7001/UnidadeOperativa/UnidadeOperativaService , como apresen-tado na Figura 26.

_______________________________________________________________________________________________


Figura 25 Criao do Business Service

Figura 26 Endpoint do servio UnidadeOperativa

Vale ressaltar que o requisito de se criar um Business Service para o WSDL aparen-temente torna a tarefa de publicao de servios um tanto redundante. Porm, isso necessrio, pois o barramento permite definir configuraes especficas que no so esto no WSDL, tais como: configuraes de transporte de mensagens do servio (m-todo de requisio, se usa autenticao etc.); algoritmo de balanceamento de carga que ser usado para esse servio (none, round-robin, random ou random-weighted); nmero de tentativas a ser executado para re-executar o servio caso seja necessrio, alm do in-tervalo de tempo para as tentativas e se para tentar novamente se ocorrer erros da aplicao.

A Figura 27 (destacado em verde) apresenta o Business Service e o WSDL do servio criados. Observe que possvel testar a execuo do servio utilizando o ESB. Basta clicar no boto destacado em vermelho na Figura 27. A tela apresentada na Figura 28 exibida para realizar o teste do servio.

_______________________________________________________________________________________________


Figura 27 Business service e WSDL do servio UnidadeOperativa

Figura 28 Interface para teste do servio

Aps a publicao do servio no barramento, possvel, por exemplo, monitorar o uso do servio. Para ativar o monitoramento, basta selecionarmos um servio qualquer

_______________________________________________________________________________________________


disponvel no barramento e clicarmos em Monitoring Enabled (Figura 29). poss-vel alterarmos o intervalo de agregao. Esse intervalo corresponde ao intervalo em que as estatsticas do servio sero agregadas no barramento.

Figura 29 Habilitao do monitoramento do servio

Atravs de alertas, possvel monitorar a execuo do servio. Para este servio, criamos um alerta para informar quando o servio for executado em um tempo maior do que 100 milissegundos.

Figura 30 Configurao do alerta para o servio

Para que o cliente invoque o servio utilizando o barramento, ou seja, o barramento servindo como mediador da invocao do servio real, necessrio criar um servio de proxy. Maiores detalhes para criao de servio de proxy so apresentados por Souza et al. [2008, 2009]. Neste exemplo, com o objetivo de ilustrar a invocao do servio de negcio via servio de proxy, foi criado o servio UnidadeOperativaPX (Figura 31), a partir do WSDL do servio (UnidadeOperativa.wsdl). Para este servio foi adicionada

_______________________________________________________________________________________________


uma rota (Figura 32) com o objetivo de invocar o mtodo do servio de negcio (Uni-dadeOperativaBS), como ilustrado na Figura 33.

Figura 31 Servio de proxy UnidadeOperativaPX do projeto UnidadeOperativaPrj

Figura 32 Rota (RouteNode1) criada para o servio de proxy invocar o servio de ne-gcio

_______________________________________________________________________________________________


Figura 33 Descrio da rota: invocao do mtodo getUnidadeOperativa do servio UnidadeOperativaBS

Para o cliente passar a invocar o servio de proxy ao invs do servio de negcio, basta substituir a URL de invocao do servio pela URL do servio de proxy, como apresentado na Figura 34.

Figura 34 Invocao do servio de proxy pelo cliente

4.2 Alterao dos parmetros do servio sem alterar o cliente

Esta seo descreve os resultados obtidos com alteraes no servio do provedor sem alterar a configurao do servio no cliente. importante observar que, utilizando o barramento, o consumidor invoca o servio de proxy e este invoca o servio do prove-dor (servio de negcio). Os testes apresentados nesta seo tratam da alterao do servio do provedor sem alterar o servio de proxy e o consumidor. Os testes realiza-dos seguem os mesmos detalhes de implementao apresentados em [Sousa, 2009], porm o servio disponibilizado pelo provedor foi implementado no Workshop 10.3, ao invs do Workshop 9.2.

_______________________________________________________________________________________________


4.2.1 Implementao do servio antes de realizar o teste

O cdigo referente implementao do servio publicado no servidor e configurado no barramento pode ser visto na Figura 35. A classe POJO referente ao objeto retorna-do pelo servio e a classe POJO que encapsula os parmetros para invocao do servi-o so apresentadas nas Figura 36 e Figura 37 respectivamente.

Figura 35 Implementao do servio

_______________________________________________________________________________________________


Figura 36 Classe POJO

_______________________________________________________________________________________________


Figura 37 Classe que encapsula os parmetros da chamada do servio

4.2.2 Teste de remoo de atributo do objeto retornado pelo servio

Este teste consiste em remover o atributo codigoAGP da classe POJO retornada pelo servio, publicar o servio no servidor com a alterao e realizar a chamada do servio no cliente, sem alter-lo, utilizando o barramento como mediador. A Figura 38 apre-senta a resposta recebida pelo cliente. Logo, para o atributo removido no servio, foi atribudo o valor nulo, e no ocorreu erro na invocao do servio.

*******************************************************

Codigo: 1

Nome: AS

Sigla: BRA

Indicador: PT

CdigoAGP: null

*******************************************************

Figura 38 Resultado da invocao do servio aps remoo de atributo retornado pelo servio

4.2.3 Teste de adio de atributo no objeto retornado pelo servio

Este teste consiste em adicionar um atributo na classe POJO, publicar o servio no ser-vidor com a alterao e realizar a chamada do servio no cliente, sem alter-lo, utili-zando o barramento como mediador. A Figura 39 apresenta a resposta recebida pelo cliente. Observe que todos os atributos do objeto do cliente so preenchidos, dado que nenhum dos mesmos foi removido. Alm disso, o cliente no recebe mensagem de er-ro, mesmo invocando um servio em uma verso mais nova do que a que o cliente es-t referenciando.

*******************************************************

Codigo: 1

Nome: AS

_______________________________________________________________________________________________


Sigla: BRA

Indicador: PT

CdigoAGP: 1

*******************************************************

Figura 39 - Resultado da invocao do servio aps adio de atributo retornado pelo

servio

4.2.4 Teste de remoo de atributo no POJO que en capsula os parmetros do

servio

Este teste consiste em remover um atributo da classe POJO que encapsula os parme-tros do servio, publicar o servio no servidor com a alterao e realizar a chamada do servio no cliente, sem alter-lo, utilizando o barramento como mediador. O atributo excludo foi Nome sendo que no seria possvel apagar o atributo Codigo" porque ele essencial para a execuo do servio, j que leva o dado que ser utilizado na funo que obtm e retorna a Unidade Operativa. A Figura 40 apresenta a resposta recebida pelo cliente. Neste caso, o provedor recebeu o valor do atributo Nome, en-viado pelo cliente, mas que foi apagado no servidor. O POJO de retorno do servio no sofreu alteraes, e no ocorreram erros na execuo do servio. Logo, o parme-tro extra na classe POJO que encapsula os parmetros do servio, no afeta a sua exe-cuo. Alm disso, o barramento foi transparente nessa transao.

*******************************************************

Codigo: 1

Nome: AS

Sigla: BRA

Indicador: PT

CdigoAGP: 1

*******************************************************

Figura 40 Resultado da invocao do servio aps remoo de atributo da classe que encapsula os parmetros do servio

4.2.5 Teste de incluso de atributo no POJO que encapsula os parmetros do

servio

Este teste consiste em adicionar um atributo na classe POJO que encapsula os parme-tros do servio, publicar o servio no servidor com a alterao e realizar a chamada do servio no cliente, sem alter-lo, utilizando o barramento como mediador. O atributo includo foi chamado de novoAtributo, do tipo String. A Figura 41 apresenta a res-posta recebida pelo cliente. Neste caso, o servio do provedor no recebeu o valor es-perado do atributo que foi adicionado, j que o cliente no est configurado para envi-ar esse atributo. Esta atualizao no provocou erro na execuo do servio, logo, o parmetro ausente na classe POJO, que encapsula os parmetros do servio, no afeta sua execuo. Alm disso, o barramento foi transparente nessa transao.

*******************************************************

Codigo: 1

Nome: AS

Sigla: BRA

Indicador: PT

CdigoAGP: 1

_______________________________________________________________________________________________


*******************************************************

Figura 41 Resultado da invocao do servio aps remoo de atributo da classe que encapsula os parmetros do servio

4.2.6 Concluso dos testes

Os mesmos resultados obtidos nos testes realizados para avaliar as abordagens de co-nexo ponto-a-ponto [Souza et al., 2009] entre cliente e servidor (consumidor e consu-midor) foram obtidos nos testes realizados com a utilizao do barramento. Portanto, o uso do barramento como simples mediador da chamada do servio atravs de um ser-vio de proxy no interfere na arquitetura em relao conexo ponto-a-ponto.

4.3 Definio de fluxos em servios de Proxy

O OSB um intermedirio que processa mensagens de entrada para requisio de ser-vios, determina a lgica de roteamento, e transforma estas mensagens para compati-bilidade com outros consumidores de servios. No Oracle Service Bus, um fluxo de mensagem corresponde implementao de um servio de proxy. Voc pode configu-rar a lgica de manipulao de mensagens usando definies de fluxo de mensagem de servio de Proxy. A lgica inclui atividades como transformao, publicao e gera-o de relatrio, as quais so implementadas como aes individuais dentro de est-gios de pipeline.

A maior parte da lgica de processamento em um fluxo de mensagem tratada em pipelines. Um pipeline uma sequncia nomeada de estgios representando um cami-nho de processamento em uma nica direo sem ramificaes. Um estgio um pas-so de processamento configurado pelo usurio. Mensagens de entrada para pipelines so acompanhadas de um conjunto de variveis de contexto da mensagem que con-tm contedos da mensagem. Elas podem ser acessadas ou modificadas por aes dentro do estgio do pipeline.

Na seo 3.3 foram apresentados os principais conceitos para definio de fluxo de mensagens em um barramento. Nesta seo, so apresentados testes prticos da defi-nio de fluxo de mensagens no OSB.

Para a definio de fluxos entre consumidores e provedores, necessrio que o ser-vio provido esteja registrado no barramento e que exista um servio de proxy para fazer o roteamento das mensagens no barramento. A seo 4.1 apresenta o passo-a-passo para publicao de servio de negcio no barramento, o que envolve a importa-o do WSDL do servio e o registro do servio, alm da criao de um servio de proxy que rotear as mensagens para o servio de negcio registrado. Estes passos foram seguidos para a execuo dos testes prticos apresentados a seguir, os quais in-cluem:

Roteamento de mensagens no OSB;

Transformaes de mensagens; e

Um estudo prtico do uso de transformaes de mensagens e roteamento das mesmas para auxiliar no versionamento de servios.

4.3.1 Roteamento de mensagens

Esta seo descreve um exemplo de roteamento de mensagens no OSB.

_______________________________________________________________________________________________


4.3.1.1 Cenrio

Considere o cenrio de uma companhia de financiamento apresentado na Figura 42 que realiza roteamento de pedidos de emprstimo para servios de negcio apropria-dos baseado na taxa de juros requisitada. Se a solicitao de uma taxa menor do que 5%, ento a solicitao roteada para um servio especfico. Caso contrrio, a mensa-gem roteada para um servio normal.

Figura 42 Cenrio de anlise de pedidos de emprstimo

Em [Souza et al., 2009] foi apresentado o passo-a-passo de publicao dos servios de negcio e servio de proxy para a definio do fluxo para roteamento de mensa-gens. Neste trabalho, foi utilizado o ALSB (Aqualogic Service Bus), cuja verso foi evo-luda pela Oracle aps a compra da BEA para o OSB (Oracle Service Bus). No existem diferenas em relao ao passo-a-passo utilizando o ALSB e o OSB, e maiores detalhes para a realizao deste passo-a-passo no OSB so encontrados em [OSB, 2009b]. Nesta seo foi dado foco na apresentao da forma de realizar roteamento de mensagens.

Para os exemplos apresentados a seguir, estamos considerando que os WSDL dos servios normalLoan e managerApproval foram importados, os servios de negcio Ma-nagerLoanReaview e NormalLoan foram registrados e que o servio de proxy LoanGate-way foi criado. O passo-a-passo para realizar estas atividades apresentado em [Souza et al., 2009] e [OSB, 2009b].

4.3.1.2 Passos para criao do fluxo para roteamento de mensagem

A criao de um fluxo para um servio de proxy realizada a partir da edio do flu-xo, como apresentado na Figura 43, sendo apresentado o fluxo inicial do servio de proxy (Figura 44). A partir deste fluxo deve ser adicionada uma rota (add route) que inicia a criao de um estgio. Em seguida, devem ser definidas as aes para este es-tgio.

_______________________________________________________________________________________________


Figura 43 Criao de fluxo para servio de proxy

Figura 44 Fluxo inicial para o servio de proxy

Figura 45 Adio de ao a um estgio

Para criar ao de roteamento da mensagem, deve-se criar uma tabela de roteamen-to (Communication > Routing Table), como apresentado na Figura 46. Nesta tela, de-ve-se definir uma expresso (Expression), por exemplo, expresso XQuery para recupe-rar a taxa de juros no corpo da mensagem (varivel de contexto $body), como apresen-tado na Figura 47.

_______________________________________________________________________________________________


Figura 46 Criao de tabela de roteamento

Figura 47 Definio de expresso para recuperar a taxa de juros solicitada

Aps a definio da expresso de roteamento, define-se a regra de roteamento. No exemplo apresentado na Figura 48, a mensagem roteada para o servio ManagerLo-anReview, caso o valor da taxa seja menor do 5. Neste caso, o mtodo processLoanApp invocado. Para o caso da taxa ser maior ou igual a 5%, o servio NormalLoan deve ser invocado (Figura 49). Isto configurado criando um roteamento default (clicando no boto destacado na Figura 49) e configurando que o mtodo processLoanApp do servio NormalLoan deve ser invocado.

_______________________________________________________________________________________________


Figura 48 Roteamento para o servio que trata solicitao de taxa de juros menor do que 5%

Figura 49 Definio do roteamento default para invocar o mtodo processLoanApp do servio NormalLoan quando a taxa de juros solicitada for maior ou igual a 5%

4.3.1.3 Testes do servio de Proxy

Para realizar o teste do servio de proxy, basta clicar no boto de depurao, como apresentado na Figura 50. Ser exibida a tela apresentada na Figura 51. Para realizar o teste, preencher, no textbox correspondente a loanRequest, o valor da taxa de juros. Se for preenchido um valor menor do que 5%, o servio de proxy roteia a mensagem para o servio ManagerLoanReaview. Caso contrrio, a mensagem ser roteada para o servio NormalLoan. A Figura 52 apresenta o resultado da invocao do servio solicitando ta-xa menor do que 5%, e a Figura 53 apresenta o trace de invocao do servio. J a Figu-ra 54 apresenta o resultado da invocao do servio solicitando taxa maior do que 5%.

_______________________________________________________________________________________________


Figura 50 Iniciar depurao do servio

Figura 51 Tela de depurao de servio

Figura 52 Resultado da invocao do servio solicitando taxa igual a 4,1%

_______________________________________________________________________________________________


Figura 53 Trace de invocao do servio

Figura 54 - Resultado da invocao do servio solicitando taxa igual a 5,3%

4.3.2 Transformao de mensagens

Transformao de dados corresponde a mapeamentos de dados de um formato para outro, por exemplo, com o objetivo de tornar a informao compatvel para ambientes de sistemas heterogneos. O OSB pode ser configurado para rotear e transformar mensagens quando necessrio, baseado em configuraes de servio de proxy espec-ficas.

4.3.2.1 Cenrio

O exemplo utilizado nesta seo para apresentar a transformao de mensagens se-melhante ao cenrio de empresa financeira apresentada na seo anterior. Neste caso, a empresa utiliza o OSB para rotear solicitaes de emprstimos que podem ser pagos por uma empresa secundria caso o valor solicitado seja maior do que 25 milhes, ou seja, caso contrrio a solicitao repassada para um servio de negcio da prpria empresa.

A Figura 55 apresenta a arquitetura da aplicao para tratar emprstimos financei-ros no OSB. Inicialmente, a empresa financeira principal recebe uma solicitao de emprstimo, pela invocao do mtodo do servio de proxy (LoanGateway2), o qual determina o servio de negcio que tratar a solicitao. Se a quantia solicitada maior do que 25 milhes, ento a solicitao roteada para o servio de negcio LoanSalePro-

_______________________________________________________________________________________________


cessor. Se a quantia menor ou igual a 25 milhes, a solicitao roteada para o servi-o de negcio NormalLoan.

Quando a quantia maior do que 25 milhes, antes de realizar o roteamento para o servio da empresa secundria, o pipeline de requisio realiza um callout para o servi-o de negcio CreditRating e recebe a taxa de crdito da solicitao usando a varivel $creditRating. Para preencher os requisitos da interface do servio da empresa de em-prstimo secundria, o corpo da mensagem ($body) transformado pela adio dos detalhes da taxa de crdito. Em seguida, feito o roteamento da mensagem transfor-mada para o servio de negcio da empresa secundria. Quando este servio retorna a resposta para o servio de proxy, a mensagem transformada novamente para estar de acordo com o formato da mensagem de retorno do servio de proxy.

Figura 55 Exposio da aplicao para tratar emprstimos financeiros no OSB

4.3.2.2 Configurao necessria

Para o exemplo apresentado a seguir, as seguintes configuraes so necessrias:

Os WSDL dos servios normalLoan, managerApproval, loanSale e creditRating serem importados. O resultado da importao destes WSDLs apresentado na Figura 56.

O servio de proxy LoanGateway2 ser criado a partir do WSDL normalLoan e com URI do endpoint igual a /loan/gateway2.

Os seguintes servios de negcio estarem registrados:

o CreditRatingService: retorna a taxa de crdito quando a solicitao de emprstimo est de acordo com determinado critrio.

Este servio j instalado no servidor de aplicao (WebLo-gic Server), logo necessrio apenas registr-lo a partir do WSDL creditRating, escolhendo a porta helloPort e endpoint URI igual a http:/// cre-jws_basic_ejb/CreditSimpleBean.

o NormalLoan: servio de negcio da empresa financeira secundria para tratar solicitaes menores ou iguais a 25 milhes.

Este servio foi registrado para a execuo do exemplo da seo anterior.

_______________________________________________________________________________________________


o LoanSaleProcessor: servio de negcio da empresa financeira secun-dria para tratar solicitaes maiores do que 25 milhes.

Este servio j instalado no servidor de aplicao (WebLo-gic Server), logo necessrio apenas registr-lo a partir do WSDL loanSale, escolhendo a porta helloPort e endpoint URI igual a http:///ljws_basic_ejb/LargeSimpleBean.

O passo-a-passo para realizar importao de WSDL e registro de servios apre-sentado em [Souza et al., 2009] e [OSB, 2009b].

Figura 56 WSDL necessrios para exemplo de transformao de mensagens

Figura 57 Servios de negcio registrados para o exemplo de transformao de men-sagens

As mensagens de entrada e sada dos servios apresentam diferenas as quais fa-zem necessria a transformao de mensagens para invoc-los:

965-7286-1-pb_estudo oracle service bus petrobras

Documents