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
Projeto de Pesquisa
Grupo de Pesquisa Participante
Patrocnio
ii
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 padres 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.
iii
Sumrio
1 2
Introduo 1.1 Estrutura do relatrio Enterprise Service Bus 2.1 Responsabilidades do ESB 2.2 Benefcios do ESB 2.3 JBI 2.4 ESBs comerciais e de cdigo aberto Arquitetura do Oracle Service Bus 3.1 Sute de produtos do OSB 3.2 Componentes da arquitetura do OSB 3.3 Fluxo de mensagens via servios de proxy 3.4 WSDL efetivos e WSDL gerado 3.5 Web services com atributo style igual a SOAP document RPC 3.6 Padres de troca de mensagens 3.7 Broker de mensagens 3.8 Transformao e processamento de mensagens 3.9 Disponibilizao de EJB como servio 3.10 Console de teste 3.11 Gesto de recursos 3.12 OSB e UDDI 3.13 Tratamento de erros 3.14 Versionamento 3.15 Monitoramento 3.16 Disponibilizao do OSB em servidores 3.17 Outros conceitos importantes Anlise prtica do Oracle Service Bus 4.1 Publicao do servio no OSB 4.2 Alterao dos parmetros do servio sem alterar o cliente 4.3 Definio de fluxos em servios de Proxy 4.4 Validao de tipos de dados utilizando servio de proxy 4.5 Versionamento de servios utilizando o OSB 4.6 Monitoramento de servios 4.7 Concluso Concluso Referncias
5 6 6 8 11 12 13 15 15 17 20 25 26 29 29 30 30 31 31 32 32 32 32 32 34 34 34 40 45 63 78 85 114 114 115 116 117
5 6
Apndice 1 - Diferenas entre OSB e ALSB Apndice 2 - Elementos de um WSDL
iv
1 Introduo
ESB a infra-estrutura que permite alta interoperabilidade entre sistemas distribudos via servios. Processos disponibilizados via servios distribudos em mltiplos sistemas usando diferentes plataformas e tecnologias podem ser executados de uma maneira mais simples utilizando o ESB. O ESB um barramento de mensagens, projetado para possibilitar a implementao, 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 protocolos (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 organizaes implementem as especificaes ou recomendaes de forma que muitas partes das tecnologias que seguem estes padres sejam portveis atravs de diferentes im-
_______________________________________________________________________________________________ RelaTe-DIA: Estudos de Enterprise Service Bus e Oracle Service Bus 5
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 concordarem 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, podese 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 orquestrao. 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 iniciativas 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 padres bsicos de roteamento como os propostos por Hohpe e Woolf [2004]. Os padres de barramento de mensagens, roteamento baseado em contedo, filtros e pipes, conexo ponto a ponto, normalizador, modelo de dados cannicos formam a base para os ESB modernos que, alm disso, implementam padres chave de EAI (Enterprise Application Integration). Estes padres no so simples de implementar, como os padres 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 cliente. 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 sistemas 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 linguagem de programao. O barramento permite conectar aplicaes Java, aplicaes .Net, brokers que requisitam objetos, alm de sistemas legados. A Figura 2, apresentada 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 aplicaes 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 como servios, por exemplo, vendas, funcionalidades departamentais, recursos humanos, 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 utilizando diferentes tecnologias, tais como motor de regras (externo ou embutido), mo1
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 conexo 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 barramento abstrai e realiza mediao entre os ns conectados, alguma flexibilidade alcanada; se for observada a necessidade de substituir uma aplicao por outra, podese 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 3 4
http://www.w3.org/TR/wsdl http://www.w3.org/TR/soap/ 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 clientes, 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. GlassfishESB 5 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 integrao 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 segurana, 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 resposta. Request-response: A operao recebe uma mensagem e ir retornar uma resposta. Solicit-response: A operao envia uma requisio e ir esperar uma resposta. Notification: A operao envia uma mensagem, mas no ir esperar uma resposta.
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 ca5 6
https://open-esb.dev.java.net/Downloads.html# 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 resposta 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 utilizados durante o caminho de uma mensagem, incluindo no apenas HTTP e JMS, mas tambm HTTPS, SMTP, XMPP, FTP dentre outros. Muitos barramentos tm a capacidade de conectar diferentes formatos de dados, por exemplo, Eletronic Data Interchange (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 consultados 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 motores 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 SAML 8 (Security Assertion Markup Language). 2.1.9 Gerncia de servios
Servios executando no ESB podem ser monitorados, auditados, mantidos e reconfigurados. No ltimo caso, mudanas no processo podem ser feitas sem necessidade de reescrever servios ou aplicaes subjacentes, dependendo das modificaes necessrias 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, como o ponto de integrao central, o barramento pode realizar as transformaes necessrias 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 dados 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 barramento 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 barramento, 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;
http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=security
A gesto centralizada permite coletar mtricas sobre servios, permitindo monitorar 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 fornecedor. 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, conectores 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 componentes conectados executem juntos e que sejam disponibilizados componentes escritos por desenvolvedores dentro deste ambiente. Para realizar este objetivo, JBI define quatro elementos principais (Figura 5): engine de servios (ou Service Engines SE), componentes de ligao (ou Biding Component BC), roteador de mensagens normalizadas (Normalized Message Router NMR) e ambiente de execuo (runtime evironment).
Figura 5 Arquitetura JBI em alto nvel, como demonstrado pela especificao 1.0 [Hewitt, 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 protocolos 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 para 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 entrega (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 permitindo 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 sugeriria que JBI o principal conceito para a implementao de um Enterprise Service Bus. No entanto, poucos fornecedores suportam JBI, devido a vrias razes: muitos fornecedores perceberam que poderiam ter suas ferramentas SOA construdas pelo empacotamento de solues EAI previamente desenvolvidas; eles tinham suas prprias definies 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 especificar 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 implementaes 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 Oracle/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 Service Bus WorkSpace Studio; Tratamento de falhas na chamada de servios (tanto roteamento como pooling de mensagens); Otimizao de transporte de mensagens: permite que o container trate EJBs remotos que esto posicionados na mesma JVM com os consumidores invocando os servios como se fossem EJBs locais. Esta otimizao de desempenho 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 negcio. 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 barramento. Isto feito atravs de regras de alerta que indicam quando o barramento 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 permitindo 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 criar processos de negcio que envolva automao de servios bem como tarefas humanas, 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 podem 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 infraestrutura de servios, incluindo portais e aplicaes compostas. Oracle Business Process Management: inclui automatizao, execuo e monitoramento 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 Arquitetura Orientada a Servios. Dentre estes produtos destacam-se os produtos para desen_______________________________________________________________________________________________ RelaTe-DIA: Estudos de Enterprise Service Bus e Oracle Service Bus 15
volvimento de portais (Oracle WebLogic Portal e Oracle WebCenter Interaction), para a camada de processos (Oracle WebLogic Integrator e Oracle Business Process Management), 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 provedores; 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], apresentado na Figura 8, podemos notar a aderncia das atividades propostas de serem realizadas 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 consumidor-provedor menos dependente; Definies de roteamento de servios; Realizao de testes de servios e orquestraes atravs do console de teste.
Projeto Mapeamento de mercado Provedor de servio Modelagem de negcio Desenvolvimento de servio Teste de servio Publicao de servio
Execuo
Mudana
Engenharia de requisitos
Projeto de servio
Proviso de servio
Monitorao de servio
Gerenciamento de servio
Broker de servio
Seleo de registro
Atualizao de registro
Manuteno de registro
(Consumidor de servios)
Descoberta de servio
Negociao de servio Invocao de servio Monitorao de servio
Orquestrao /composio de servio Provedor de aplicao Engenharia de requisitos Projeto da aplicao Implementao da aplicao Teste de modulo
Teste da aplicao
Manuteno da aplicao
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 mediao 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 mensagem, transformao de mensagens, configurao, validao e registro de servios. Gesto de servios: monitoramento e gesto das atividades e disponibilidade 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 utilizados no OSB so: o o o HTTP/SOAP WS-I, WS-Security, WS-Policy, WS-Addressing 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 SOAP v1.2. EJB/RMI no WebSphere Permite a criao e a customizao de protocolos especficos da organizao, bem como usar protocolos nativos do Oracle, por exemplo, Oracle Data Service Integrator.
o o
Camada de segurana (Figura 9): permite os seguintes nveis de segurana:
o o
Segurana no transporte da mensagem: SSL/Basic Auth Segurana na mensagem: WS-Policy/WS-Security, SAML, UserID/Password, X509, Signing & Encryption, e Custom security credentials Segurana de console: suporta Web Single-Sign-On e acesso baseado em perfis Polticas: WS-Security e WS-Policy
o o
Figura 9 Camada de segurana
Camada para composio de servios (Figura 10): esta camada inclui a modelagem do fluxo de servios, alm de atividades de descoberta de servios em UDDI, validao, transformao, testes da orquestrao, alm da especificao 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 governana sobre as mensagens que trafegam pelo barramento disponibilizando: dashboard, monitoramento, definio de alertas, relatrios, verificao 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 servios, determina a lgica de roteamento, e transforma estas mensagens para compatibilidade com outros consumidores de servios. Ele recebe mensagens atravs de protocolos 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 direcionado 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 correspondem 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 o o o Recebe o stream de dados da requisio do cliente (ou consumidor); Envia o stream de dados da requisio para o provedor; Recebe o stream de dados da resposta do provedor; Envia o stream de dados da resposta para o cliente (ou consumidor). Desserializa e serializa mensagens, quando necessrio; Trata questes de segurana da mensagem; Manipula mensagens para iniciar fluxo de mensagens (requisio e resposta) Servios de proxy so definies de web services intermedirios que o OSB implementa localmente O OSB permite a definio de servios de proxy pela definio de sua interface via WSDL (Web Services Description Language) e o tipo de transporte que ele utiliza.
Camada de ligao (binding layer): o o o
Servio de proxy (proxy service) o o
o o
A lgica de processamento da mensagem especificada na definio do fluxo da mensagem quando um servio de proxy definido. 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 atualizao As variveis principais do context so: $header (SOAP), $body (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 paradigma. Como um servio de proxy pode rotear mensagens para mltiplos servios de negcio, um servio de proxy pode ser configurado 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 caminho de processamento em uma nica direo sem ramificaes. Um estgio um passo de processamento configurado pelo usurio. Mensagens de entrada para pipelines so acompanhadas de um conjunto de variveis de contexto da mensagem que contm 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 mensagem; 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 entram no fluxo de mensagem atravs do n incial, e todas as mensagens de respostas 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 requisio, 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 podem conter estgios, onde podem ser configuradas aes para manipular mensagens 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 requisio/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 considerado completo. Quando o n recebe uma mensagem de resposta, o processamento da resposta comea. O n de roteamento suporta roteamento condicional bem como transformaes de requisio e resposta. Dado que o n de roteamento representa o limite entre o processamento da requisio e resposta, ele no pode ter nenhum descendente no fluxo da mensagem. Logo, ele usado 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. 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 processam o fluxo das mensagens, tais como: assign, delete, insert, Java callout, transformao MLF, rename, replace, validate. Em particular, a ao validate 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 validao de elementos locais. 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 operacionais (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 o o O processamento da requisio comea no n inicial. Em seguida, o par pipeline executa apenas o processamento da requisio. O n de deciso (n branch), avalia a tabela de deciso para o fluxo que foi avaliado como verdadeiro. 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 processamento 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 processamento da respostas iniciado no sentido inverso sem esperar por qualquer resposta.
Processamento da resposta: o o o o O n de roteamento executa qualquer transformao da resposta que tenha sido definida; O n de diviso pula qualquer n de diviso e continua com o n que precede a diviso; O par pipeline executa o pipeline da resposta; 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 endpoint selecionado ou aps a resposta ser recebida [OSB, 2009c]. Processamento para tratar questes de segurana (WS-Security) e autorizao podem 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 propriedades 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 criados 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 gerado. 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 WSPolicies. 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 gerados 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 baseados 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 service orientado a documento pode ter apenas um parmetro ou tipo de mensagem, tipicamente um documento XML. Isto significa que os mtodos que implementam as operaes devem ter apenas um nico parmetro. Entretanto, operaes de web services 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, respectivamente. Na Figura 16, soap-env namespace SOAP 1.1 prfinido e req o namespace do elemento PurchaseOrg (http://example.com/lookup/docs).
<definitions name="Lookup" targetNamespace="http://example.com/lookup/service/defs" xmlns:tns="http://example.com/lookup/service/defs" xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:docs="http://example.com/lookup/docs" xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/" xmlns="http://schemas.xmlsoap.org/wsdl/"> <types> <xs:schema targetNamespace="http://example.com/lookup/docs" elementFormDefault="qualified"> <xs:element name="PurchaseOrg" type="xs:string"/> <xs:element name="LegacyBoolean" type="xs:boolean"/> </xs:schema> </types> <message name="lookupReq"> <part name="request" element="docs:purchaseorg"/> </message> <message name="lookupResp"> <part name="result" element="docs:legacyboolean"/> </message> <portType name="LookupPortType"> <operation name="lookup"> <input message="tns:lookupReq"/> <output message="tns:lookupResp"/> </operation> </portType> <binding name="LookupBinding" type="tns:lookupPortType"> <soap:binding style="document" transport="http://schemas.xmlsoap.org/soap/http"/> <operation name="lookup"> <soap:operation/> <input> <soap:body use="literal" /> </input> <output> <soap:body use="literal"/> </output> </operation> </binding> </definitions> Figura 15 Exemplo de WSDL de servio orientado a documento <soap-env:body> <req:purchaseorg>Oracle</req:purchaseorg> </soap-env:body> Figura 16 Exemplo de mensagem SOAP de requisio do servio orientado a documento <soap-env:body> <req:legacyboolean>true</req:legacyboolean> </soap-env:body> Figura 17 Exemplo de mensagem SOAP de resposta do servio orientado a documento
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 Figura 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 respostas 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).
<definitions name="Lookup" targetNamespace="http://example.com/lookup/service/defs" xmlns:tns="http://example.com/lookup/service/defs" xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:docs="http://example.com/lookup/docs" xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/" xmlns="http://schemas.xmlsoap.org/wsdl/"> <types> </xs:sequence> </xs:complexType> </xs:schema> </types> <message name="lookupReq"> <part name="request" type="docs: RequestDoc"/> </message> <message name="lookupResp"> <part name="result" type="docs: ResponseDoc"/> </message> <portType name="LookupPortType"> <operation name="lookup"> <input message="tns:lookupReq"/> <output message="tns:lookupResp"/> </operation> </portType> <binding name="LookupBinding" type="tns:lookupPortType"> <soap:binding style="rpc" transport="http://schemas.xmlsoap.org/soap/http"/> <operation name="lookup"> <soap:operation/> <input> <soap:body use="literal" namespace="http://example.com/lookup/service"/> </input> <output> <soap:body use="literal" namespace="http://example.com/lookup/service"/> </output> </operation> </binding> </definitions> Figura 18 Exemplo de WSDL de servio com estilo RPC <soap-env:body> <ns:lookup> <request> <req:purchaseorg>Oracle</req:purchaseorg> </request> </ns:lookup> <soap-env:body>
Figura 19 Exemplo de mensagem SOAP de requisio do servio com estilo RPC <soap-env:body> <ns:lookupResponse> <result> <req:legacyboolean>true</req:legacyboolean> </result> </ns:lookupResponse> <soap-env:body> 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 clientes publicados aps a execuo da operao para o qual os consumidores foram publicados. Requisio/resposta assncrona (ponte de sncrono para assncrono). o o Cliente sncrono envia requisies para provedor assncrono, e cliente fica aguardando a resposta OSB prov uma fila JMS para a mensagem de requisio e configura outra fila para a mensagem de resposta, com um valor de timeout para a resposta. As filas so utilizadas para simular troca de mensagens sncrona. 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 roteamento de mensagens. o A ao de callout de servio usada dentro de um estgio de roteamento 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 substituio de URL e extensvel pelo uso de Java Callouts e POJOs. Maiores detalhes sobre Service Callout podem ser encontrados em [OSB, 2009b].
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 grupo 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 processamento 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 binrios 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 transformao (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 execuo 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 componente separado como Oracle Data Service Integrator. O Database Lookup deve ser utilizado 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 propagao 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 plataformas 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 disponibilizado. 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 iniciar 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 tomar 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 disponibiliza uma stack JAX-RPC para realizar ligao XML para Java; Retries inteligentes: o transporte EJB toma decises de retries baseado na natureza 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 podem ser: servio de proxy, servio de negcio, Xquery, XSLT e recurso MFL. A funcionalidade 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., ambiente 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 consumidores 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 servios, por exemplo: mdia de tempo de processamento de um servio; volume processado; 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 (cluster de servidores) (Figura 21).
Figura 21 Formas de implantao do OSB
Quando disponibilizado em um cluster, os outros servidores so gerenciados a partir 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 customizada para importar apenas o que se deseja. Tarefas de implantao podem ser customizadas utilizando a ferramenta WebLogic Server Scripting Tool9.
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/usergui de/modelingmessageflow.html Segurana (Oracle Service Bus Security Guide): http://downloadllnw.oracle.com/docs/cd/E13159_01/osb/docs10gr3/security/index.html Console de teste: http://download.oracle.com/docs/cd/E13159_01/osb/docs10gr3/usergui de/testing.html MFL (Message Format Language): http://download.oracle.com/docs/cd/E13159_01/osb/docs10gr3/console help/mfls.html Implementaes especficas atravs de uso de APIs: http://download.oracle.com/docs/cd/E13159_01/osb/docs10gr3/usergui de/appendixAPIs.html Definio de papis para tratamento de monitoramento no OSB: http://download.oracle.com/docs/cd/E13159_01/osb/docs10gr3/operatio ns/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 passo 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 lugar, 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 necessrio, 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 barramento, 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 apresentado 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 aparentemente 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 (mtodo 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 intervalo 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). possvel 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 (UnidadeOperativaBS), 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 negcio
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 provedor (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 realizados 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 retornado pelo servio e a classe POJO que encapsula os parmetros para invocao do servio 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 apresenta 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 servidor com a alterao e realizar a chamada do servio no cliente, sem alter-lo, utilizando 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 erro, mesmo invocando um servio em uma verso mais nova do que a que o cliente est 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 parmetros 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, e nviado 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 parmetro extra na classe POJO que encapsula os parmetros do servio, no afeta a sua execuo. 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 parmetros 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 resposta recebida pelo cliente. Neste caso, o servio do provedor no recebeu o valor esperado do atributo que foi adicionado, j que o cliente no est configurado para enviar 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 conexo ponto-a-ponto [Souza et al., 2009] entre cliente e servidor (consumidor e consumidor) 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 servio 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 servios, determina a lgica de roteamento, e transforma estas mensagens para compatibilidade com outros consumidores de servios. No Oracle Service Bus, um fluxo de mensagem corresponde implementao de um servio de proxy. Voc pode configurar a lgica de manipulao de mensagens usando definies de fluxo de mensagem de servio de Proxy. A lgica inclui atividades como transformao, publicao e gerao de relatrio, as quais so implementadas como aes individuais dentro de estgios 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 caminho de processamento em uma nica direo sem ramificaes. Um estgio um passo de processamento configurado pelo usurio. Mensagens de entrada para pipelines so acompanhadas de um conjunto de variveis de contexto da mensagem que contm 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 definio de fluxo de mensagens no OSB. Para a definio de fluxos entre consumidores e provedores, necessrio que o servio 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-apasso para publicao de servio de negcio no barramento, o que envolve a importao 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 incluem: 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 apropriados 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 mensagem 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 mensagens. Neste trabalho, foi utilizado o ALSB (Aqualogic Service Bus), cuja verso foi evoluda 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 ManagerLoanReaview e NormalLoan foram registrados e que o servio de proxy LoanGateway 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 fluxo, 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 estgio.
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 roteamento (Communication > Routing Table), como apresentado na Figura 46. Nesta tela, deve-se definir uma expresso (Expression), por exemplo, expresso XQuery para recuperar a taxa de juros no corpo da mensagem (varivel de contexto $body), como apresentado 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 ManagerLoanReview, 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 taxa menor do que 5%, e a Figura 53 apresenta o trace de invocao do servio. J a Figura 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 especficas. 4.3.2.1 Cenrio O exemplo utilizado nesta seo para apresentar a transformao de mensagens semelhante 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 financeiros 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_______________________________________________________________________________________________ RelaTe-DIA: Estudos de Enterprise Service Bus e Oracle Service Bus 51
cessor. Se a quantia menor ou igual a 25 milhes, a solicitao roteada para o servio 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 servio 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 emprstimo secundria, o corpo da mensagem ($body) transformado pela adio dos detalhes da taxa de crdito. Em seguida, feito o roteamento da mensagem transformada 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 (WebLogic Server), logo necessrio apenas registr-lo a partir do WSDL creditRating, escolhendo a porta helloPort e endpoint URI igual a http://<host:port>/ crejws_basic_ejb/CreditSimpleBean.
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.
LoanSaleProcessor: servio de negcio da empresa financeira secundria para tratar solicitaes maiores do que 25 milhes. Este servio j instalado no servidor de aplicao (WebLogic Server), logo necessrio apenas registr-lo a partir do WSDL loanSale, escolhendo a porta helloPort e endpoint URI igual a http://<host:port>/ljws_basic_ejb/LargeSimpleBean.
O passo-a-passo para realizar importao de WSDL e registro de servios apresentado 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 mensagens
As mensagens de entrada e sada dos servios apresentam diferenas as quais fazem necessria a transformao de mensagens para invoc-los: A operao invocada do servio NormalLoan a processLoanApp que recebe como entrada uma mensagem processLoanApp que tem uma parte (loanRequest) que do tipo LoanStruct (Figura 58). Este tipo de dados est definido no targetNamespace denominado "java:normal.client". O servio CreditRatingService recebe como entrada um objeto LoanStruct do namespace "java:credit.client" (semelhante ao da Figura 58 diferindo apenas o namespace) e retorna um objeto LoanStruct (semelhante ao da Figura 58 diferindo apenas no namespace). J o servio LoanSaleProcessor recebe como entrada um objeto do tipo LoanStruct, mas com um atributo a mais (CreditRating) (Figura 59). O targetNamespace da estrutura, neste caso, java:large.client.
<xs:complexType name="LoanStruct">
<xs:sequence> <xs:element minOccurs="0" name="Name" nillable="true" type="xs:string"/> <xs:element minOccurs="0" name="SSN" nillable="true" type="xs:string"/> <xs:element minOccurs="0" name="Rate" nillable="false" type="xs:double"/> <xs:element minOccurs="0" name="Amount" nillable="false" type="xs:long"/> <xs:element minOccurs="0" name="NumOfYear" nillable="false" type="xs:int"/> <xs:element minOccurs="0" name="Notes" nillable="true" type="xs:string"/> </xs:sequence> </xs:complexType>
Figura 58 Tipo complexo LoanStruct do namespace java:normal.client

<xs:complexType name="LoanStruct"> <xs:sequence> <xs:element minOccurs="0" name="Name" nillable="true" type="xs:string"/> <xs:element minOccurs="0" name="SSN" nillable="true" type="xs:string"/> <xs:element minOccurs="0" name="Rate" nillable="false" type="xs:double"/> <xs:element minOccurs="0" name="Amount" nillable="false" type="xs:long"/> <xs:element minOccurs="0" name="NumOfYear" nillable="false" type="xs:int"/> <xs:element minOccurs="0" name="Notes" nillable="true" type="xs:string"/> <xs:element minOccurs="0" name="CreditRating" nillable="true" type="xs:string"/> </xs:sequence> </xs:complexType>
Figura 59 Tipo complexo LoanStruct do namespace java:large.client
Como o servio de proxy foi criado a partir do WSDL de NormalLoan, ento no h necessidade de realizar transformao de mensagem para rotear a mensagem para NormalLoan. 4.3.2.3 Configurao da transformao da mensagem e roteamento para servio Caso o valor do emprstimo seja maior do que 25 milhes, o fluxo de LoanGateway2 ir invocar o servio que calcula a taxa de crdito (realizando callout) e, em seguida, realizar o roteamento da mensagem para o servio de emprstimo da empresa secundria. Logo, seguindo os mesmos passos da Figura 43, Figura 44, Figura 45 e Figura 46 criaremos a tabela de roteamento para o servio LoanGateway2. Aps escolher a expresso XQuery, no Namespace Definitions ir para Variable Structures e escolher o elemento body. No elemento $body processLoanApp (request) ir para o elemento loanRequest e escolher a varivel Amount. A expresso XQuery ser montada: $body/exam:processLoanApp/loanRequest/java:Amount. Esta expresso ser utilizada pelo servio de proxy para recuperar a quantia solicitada para emprstimo.
Figura 60 Definio da varivel Amount para a expresso XQuery
Em seguida, defina o operador >, o valor de 25000000, o servio LoanSaleProcessos e o mtodo processLoanApp. Dessa forma, o roteamento para o caso do valor da solicitao ser maior do que 25 milhes foi definido. A Figura 61 apresenta o resultado final desta configurao. Crie um roteamento default para NormalLoan da mesma forma que apresentadado na Figura 49.
Figura 61 Definio do roteamento para o servio que trata solicitaes de emprstimo maiores do que 25 milhes
Para obter a taxa de juros, o servio de negcio CreditRating ser invocado atravs da realizao de um service callout. Para criar a ao de callout, necessrio criar o parmetro de entrada para o servio realizando as seguintes tarefas: Apagar o atributo xsi:type da mensagem de entrada do servio. Quando se tem uma hierarquia de elementos, o atributo xsi:type utilizado para ident ificar exatamento o tipo derivado de um elemento10. A Figura 62 apresenta o envelop SOA de invocao do servio de proxy e o atributo xsi:type destac ado. Este atributo deve ser removido para a invocao do servio CreditRating. Atribuir em uma varivel o parmetro de entrada para a ao de callout do servio Renomear o namespace para o parmetro de entrada para o callout do servio
Para apagar o atributo xsi:type da mensagem necessrio adicionar uma ao de remoo desta tag na tabela de roteamento (Figura 63). No campo XPath preencher com a expresso ./exam:processLoanApp/loanRequest/@xsi:type e preencher body no cam-
10
Explicao sobre o 0/#UseDerivInInstDocs
uso
do
atributo
xsi:type
http://www.w3.org/TR/xmlschema-
po referente varivel. Validar e salvar, para atualizar as configuraes do servio (Figura 64).
<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"> <soap:Header xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/"> </soap:Header> <soapenv:Body> <exam:processLoanApp xmlns:exam="http://example.org"> <loanRequest xsi:type="java:LoanStruct" xmlns:java="java:normal.client" xmlns:xsi="http://www.w3.org/2001/XMLSchemainstance">  <java:Name>string</java:Name>  <java:SSN>string</java:SSN>  <java:Rate>1.051732E7</java:Rate>  <java:Amount>90000000</java:Amount>  <java:NumOfYear>3</java:NumOfYear>  <java:Notes>string</java:Notes> </loanRequest> </exam:processLoanApp> </soapenv:Body> </soapenv:Envelope>
Figura 62 Envelope SOAP com a mensagem para invocao do servio de proxy
Figura 63 Adio de ao para remoo
Figura 64 Definio da expresso e varivel a ser realizada a remoo
O prximo passo consiste em atribuir um parmetro de entrada para o callout do servio. Para isto, a partir do cone Delete adicionar uma ao do tipo assign (Add an Action > Message Processing > Assign) e definir a expresso XQuery $body/exam:processLoanApp/loanRequest para a estrutura de varivel body. O resultado da expresso deve ser atribudo varivel loanRequestVariable, resultando na tela apresentada na Figura 65.
Figura 65 Definio da ao assign
O prximo passo consiste em renomear o namespace java:normal.client do parmetro de entrada para compatibilizar com o servio. A partir do ncone da atividade assign, criar uma atividade rename (Add an Action > Message Processing > Rename). Na expresso XPath, preencher .//java:* e definir a varivel loanRequestVariable. Dessa forma foi definida uma condio para pesquisar por todos os namespaces com prefixo Java na varivel de contexto loanRequestVariable. O prximo passo, define o namespace a ser alterado identificado pela expresso XPath. Neste caso escolher namespace e preencher no campo java:credit.client. O resultado apresentado na Figura 66.
Figura 66 Criao da atividade de rename
O prximo passo consiste em criar a ao de Callout para o servio (Action > Communication > Service Callout). Aps escolher esta ao a partir da ao de rename, escolher o servio e o mtodo do servio. Ser exibida a tela apresentada na Figura 67 com campos para configurar a mensagem de requisio e resposta do servio. Preencher o campo referente mensagem de requisio com loanRequestVariable e o campo de resposta (return) com o valor creditRating, como apresentado na Figura 68. Dessa forma, aps a execuo do servio, o resultado ser armazenado na varivel de contexto $creditRating.
Figura 67 Campos para configurao da requisio e resposta do servio de callout
Figura 68 Preenchimento dos campos de requisio e resposta do servio de callout
Em seguida, deve-se transformar a mensagem resultante da invocao do servio CreditRating para invocar o servio LoanSaleProcessor. Neste caso, necessrio: Renomear o namespace da mensagem; Inserir um novo elemento na mensagem passada para o servio LoanSaleProcessor.
Para renomear o namespace java:credit.client para java:large.client. A partir do ncone da atividade Service Callout, criar uma atividade rename (Add an Action > Message Processing > Rename). Na expresso XPath, preencher .//java:* e definir a varivel body, a qual contm o corpo da mensagem . Dessa forma foi definida uma condio para pesquisar por todos os namespaces com prefixo Java na varivel de contexto body. O prximo passo, define o namespace a ser alterado identificado pela expresso XPath. Neste caso escolher namespace e preencher no campo java:large.client. O resultado apresentado na Figura 69.
Figura 69 Renomeao do namespace java:credit.client para java:large.client
O prximo passo incluir o novo elemento na mensagem. Isto feito atravs da ao Insert. Crie uma ao Insert. Clicando em expression, segue-se para o editor de expresso XQuery. Nesta tela, deve adicionar um novo namespace: na paleta Namespace Definitions, adicione o namespace (add namespace) com prefixo lg e URI java:large.client. Na textbox de especificao de expresso XQuery, preencher <lg:CreditRating>{data($creditRating)}</lg:CreditRating>. Os colchetes {} indicam ao motor XQuery que o contedo entre {} deve ser considerado como no sendo XML e deve ser interpretado. Dessa forma, ser retornado o valor da taxa de crdito atribuda pelo servio CreditRating, montando assim o valor do atributo CreditRating no namespace lg que se refere URI java:large.client. Salve o resultado e, na tela de configurao da ao, escolha a opo after para indicar a partir de qual elemento ser inserido o novo elemento. Clique no link <XPath> e, navegando na paleta Variable Structures v at o atributo Notes de loanRequest. A expresso construda ser ./exam:processLoanApp/loanRequest/java:Notes. Substitua o namespace java por lg, resul_______________________________________________________________________________________________ RelaTe-DIA: Estudos de Enterprise Service Bus e Oracle Service Bus 59
tando em ./exam:processLoanApp/loanRequest/lg:Notes. No textbox ao lado, preencha body. A configurao resultante apresentada na Figura 70. Clique em salvar para concluir a configurao da transformao para a mensagem de entrada do servio.
Figura 70 Resultado da insero de elemento na mensagem
Em seguida, necessrio configurar a mensagem de retorno do servio ( Response actions) a fim de que a mensagem retornada pelo servio de proxy para o cliente esteja de acordo com o contrato do servio (WSDL). Logo, necessrio remover o elemento <CreditRating> e reverter o namespace para o namespace original java:normal.client. Logo, na tela de edio da tabela de roteamento adiciona uma ao de delete e, atravs do link <Xpath>, no editor de expresso XQuery preencha ./exam:processLoanAppResponse/return/lg:CreditRating para indicar que deve ser removido o elemento CreditRating da parte com o nome return da mensagem com o nome processLoanAppResponse. No textbox da varivel, preencha body, para indicar que o elemento deve ser removido do corpo da mensagem (Figura 71).
Figura 71 Remoo do atributo CreditRating da mensagem de resposta
Em seguida adicione uma ao para renomear o namespace da mensagem de resposta de java:large.client para java:normal.client. Na expresso XPath preencha lg:*, No textbox para a varivel preencha body e no namespace preencha java:normal.client. Com isso o servio est configurado (Figura 72).
Figura 72 Renomeao do namespace
4.3.2.4 Testes do servio de proxy Os testes do servio de proxy podem ser realizados da mesma forma que foi apresentado na seo 4.3.1.3 . Aps abrir o console de teste, preencher como parmetro de en_______________________________________________________________________________________________ RelaTe-DIA: Estudos de Enterprise Service Bus e Oracle Service Bus 60
trada para o servio, o valor de amount maior do que 25 milhes, como apresentado na Figura 73.
Figura 73 Invocao de servio de proxy para realizar roteamento para empresa de financeira secundria
A Figura 74 apresenta o resultado da invocao do servio de proxy com roteamento para a empresa financeira secundria. Observe que a mensagem de resposta foi CREDIT RATING: AA: LOAN PURCHASED BY THE <i><b>LARGE</b></i> LOANS SERVICE e no trace de invocao de servio que, na execuo de RouteNode1, o servio CreditRatingService foi invocado e, em seguida, o servio LoanSaleProcessor. A Figura 75 apresenta a invocao do servio de proxy realizando roteamento para NormalLoan.
Figura 74 Resultado de invocao do servio de proxy com roteamento para empresa financeira secundria
Figura 75 - Resultado de invocao do servio de proxy sem roteamento para empresa financeira secundria
4.3.2.5 Concluso Neste teste, foi apresentada a transformao de mensagem para rote-la para um nico servio. As aes foram definidas para a mensagem de requisio e de resposta da tabela de roteamento. No entanto, se a mensagem transformada fosse enviada para dois ou mais servios, utilizando esta abordagem seria necessrio replicar as aes para cada roteamento. Neste caso, a melhor alternativa usar um pipeline pair para realizar as transformaes e, aps ter a mensagem transformada, esta ser roteada para os servios.
4.4
Validao de tipos de dados utilizando servio de proxy
O objetivo desta seo demonstrar o uso da funcionalidade correspondente ao validate, oferecida pelo OSB para configurao de estgios em fluxos de servios de proxy. Essa funcionalidade consiste em configurar um estgio que valida alguma estrutura contida na mensagem (por exemplo, um objeto) com uma definio preestabelecida desta estrutura, fornecida atravs de um arquivo WSDL ou XSD. Caso o contedo da mensagem avaliado no esteja de acordo com a definio esperada, o barramento levantar uma exceo e retornar a mensagem de erro para o cliente. Alm disso, outras aes podem ser configuradas para serem executadas ao identificar este tipo de problema. Esta seo tambm descreve como emitir uma mensagem personalizada ao cliente do servio quando levantado esse tipo de exceo no barramento. 4.4.1 Validao de estruturas em mensagens
Esta seo apresenta a configurao para validao de estruturas em mensagens. 4.4.1.1 Configurao da validao Aps criar o servio de Proxy, possvel definir o fluxo de atividades de manipulao das mensagens de requisio e resposta do servio. Para configurar a validao necessrio ter adicionado o pipeline pair, um stage e o prprio servio, dentro do mapa de fluxo de mensagens (map of message flow) conforme mostra a Figura 76.
Figura 76 Mapa de fluxo de mensagens

Ao editar o estgio inserido para realizar a atividade de validao, adicione uma ao de validao indo em Add an Action/Message Processing/Validate conforme ilustrado na Figura 77.
Figura 77 Inserindo a ao Validate
Edite a expresso de validao entrando no link <XPath> (Figura 78).
Figura 78 Editando a expresso Xpath de validao
Na prxima tela dever ser selecionada a estrutura a qual deseja ser validada. Clique no link Variable Structures (Figura 79).
Figura 79 Link Variable Structures
Selecione a varivel de estrutura Body, na combobox (Figura 80).
Figura 80 Selecionando a varivel de estrutura body
Ento, selecione, dentro das operaes disponveis, a estrutura a qual ser validada. Ao selecionar a estrutura, no quadro Property Inspector aparecer o comando XPath correspondente a estrutura (Figura 81).
Figura 81 Selecionando o comando Xpath
Esse comando dever ser copiado para do XPath Expression Editor. Para fazer isso, caso esteja utilizando o Browser do Internet Explorer, basta arrastar o objeto selecionado para o quadro. Se estiver usando outro Browser, copie e cole o comando. Logo aps, clique em Validade e depois em Save (Figura 82).
Figura 82 Validando e salvando o comando Xpath
Ao retornar para a janela de configurao do estgio, insira body como a varivel da expresso e marque Raise Error on validation failure, caso no esteja marcado (Figura 83).
Figura 83 Configurao da ao de validao
Agora deve-se inserir a configurao da estrutura correta, a qual ser comparada com o contedo da mensagem. Ela pode ser obtida atravs de um arquivo WSDL ou XSD. Para isso, clique no link <Resource> e escolha o tipo do arquivo (neste exemplo, ser um WSDL) conforme ilustra a Figura 84.
Figura 84 Escolha do tipo de arquivo para seleo da estrutura a ser comparada na

validao
O arquivo, para ser selecionado, j deve ter sido adicionado ao projeto. Caso ainda no tenha adicionado o arquivo WSDL ou XSD como recurso do projeto, faa-o antes de continuar. A prxima janela mostra uma lista de todos os arquivos do tipo que foi selecionado e que esto disponveis no barramento. Selecione o arquivo correspondente que possui a estrutura a ser configurada (Figura 85).
Figura 85 Arquivos do tipo WSDL disponveis no barramento para seleo de estruturas
Aps selecionar o respectivo arquivo, o OSB apresentar as estruturas disponveis. Selecione a estrutura desejada e clique em Submit (Figura 86).
Figura 86 Estruturas disponveis dentro do arquivo WSDL selecionado
Ao retornar para a janela anterior, clique em Validade e depois em Save (Figura 87).
Figura 87 Validando e salvando as configuraes de validao de estrutura no OSB
De volta a janela de edio do fluxo de mensagem, clique em Save e ative as novas configuraes no OSB (Figura 88).
Figura 88 Finalizando a configurao da validao de estrutura no OSB
4.4.1.2 Testando a validao da mensagem Ao executar o servio onde est configurado o fluxo com a validao foi obtido o resultado esperado, conforme apresentado na Figura 89.
******************************************************* Codigo: 1 Nome: AS Sigla: BRA Indicador: PT CdigoAGP: 1 ******************************************************* Figura 89 Resultado da chamada do servio aps configurao da validao no OSB
Em seguida, a fim de testar a validao, o objeto alvo da validao foi modificado. Neste caso, o objeto da classe ConsultaUnidadeOperativa, que funciona como parmetro para chamada do servio. O atributo Nome foi excludo. Ao executar o servio foi levantada a exceo pelo barramento, uma vez que a estrutura do objeto da mensagem de chamada do servio no confere com a definio que foi configurada no OSB. A mensagem retornada apresentada na Figura 90.
<WS data binding error>could not find getter for property 'Nome' on br.com.petrobras.beans.ConsultaUnidadeOperativa ******************************************************* java.rmi.RemoteException: SOAPFaultException - FaultCode [{http://schemas.xmlsoap.org/soap/envelope/}Server] FaultString [BEA382505: OSB Validate action failed validation] FaultActor [null] Detail [<detail><con:fault xmlns:con="http://www.bea.com/wli/sb/context"><con:errorCode>BEA382505</con:errorCode><con:reason>OSB Validate action failed validation</con:reason><con:details><con1:ValidationFailureDetail xmlns:con1="http://www.bea.com/wli/sb/stages/transform/config"><con1:m essage>Expected element 'Nome@java:br.com.petrobras.beans' instead of 'Numero@java:br.com.petrobras.beans' here</con1:message><con1:xmlLocation><java:Numero xmlns:java="java:br.com.petrobras.beans">0</java:Numero></con1:xmlLoca tion><con1:message>Expected element 'Nome@java:br.com.petrobras.beans' instead of 'Sigla@java:br.com.petrobras.beans' here</con1:message><con1:xmlLocation><java:Sigla xmlns:java="java:br.com.petrobras.beans">BRA</java:Sigla></con1:xmlLoc ation><con1:message>Expected element 'Nome@java:br.com.petrobras.beans' before the end of the content</con1:message><con1:xmlLocation></con1:xmlLocation></con1:Validat ionFailureDetail></con:details><con:location><con:node>PipelinePairNode1</con:node ><con:pipeline>PipelinePairNode1_request</con:pipeline><con:stage>stag e1</con:stage><con:path>requestpipeline</con:path></con:location></con:fault></detail>]; nested exception is: javax.xml.rpc.soap.SOAPFaultException: BEA-382505: OSB Validate action failed validation at br.com.petrobras.sistema.wsclient.UnidadeOperativaService_Stub.getUnid adeOperativa(UnidadeOperativaService_Stub.java:37) at Main.WSCliente.main(WSCliente.java:29) Caused by: javax.xml.rpc.soap.SOAPFaultException: BEA-382505: OSB Validate action failed validation at weblogic.wsee.codec.soap11.SoapCodec.decodeFault(SoapCodec.java:265) at webloglogic.wsee.ws.dispatch.client.CodecHandler.decodeFault(CodecHandler.java: 106) at webloglogic.wsee.ws.dispatch.client.CodecHandler.decode(CodecHandler.java:91) at webloglogic.wsee.ws.dispatch.client.CodecHandler.handleFault(CodecHandler.java: 79) at webloglogic.wsee.handler.HandlerIterator.handleFault(HandlerIterator.java:254) at webloglogic.wsee.handler.HandlerIterator.handleResponse(HandlerIterator.java:22 4)
at webloglogic.wsee.ws.dispatch.client.ClientDispatcher.handleResponse(ClientDispa tcher.java:161) at webloglogic.wsee.ws.dispatch.client.ClientDispatcher.dispatch(ClientDispatcher. java:116) at weblogic.wsee.ws.WsStub.invoke(WsStub.java:89) at weblogic.wsee.jaxrpc.StubImpl._invoke(StubImpl.java:335) at br.com.petrobras.sistema.wsclient.UnidadeOperativaService_Stub.getUnid adeOperativa(UnidadeOperativaService_Stub.java:32) ... 1 more Figura 90 Exceo levantada pelo OSB
A primeira parte da mensagem <WS data binding error> a indicao da ausncia do atributo que foi excludo, e emitida pelo Workshop. O resto da mensagem a exceo gerada pelo OSB. Observe que existe um cdigo que identifica o tipo de erro (BEA-382505) e, logo aps, a mensagem OSB Validate action failed validation. 4.4.2 Configurao para personalizao de mensagem de erro
possvel personalizar a mensagem de erro emitida pelo OSB quando levantada a exceo aps a identificao de desvio da estrutura que est sendo validada no barramento. Para isso, necessrio configurar um estgio para manipulao de erros. Esse estgio anexado ao estgio de validao, no fluxo de mensagens, para ser executado sempre que ocorrer algum erro. Logo, podem ser configuradas diversas aes ao identificar um erro em um dado estgio. Neste exemplo, ser configurada apenas uma ao para enviar uma mensagem personalizada ao cliente aps detectar um erro de validao, configurado na seo anterior. 4.4.2.1 Configurando um estgio para manipulao de erros Na janela de edio do fluxo de mensagem, adicione um estgio para manipulao de erros (Add Stage Error Handler) a partir do estgio onde foi configurada a validao, conforme mostra a Figura 91.
Figura 91 Adicionando um estgio para manipulao de erro
Clique no cone Error Handler e adicione um estgio (Add Stage) para configurar uma ao ao gerar a exceo pela validao (Figura 92).
Figura 92 Adicionando um estgio dentro da edio do manipulador de erro
Edite o estgio e adicione a ao de controle de fluxo If...Then... conforme ilustra a figura Figura 93.
Figura 93 Adicionando um controle de fluxo
Edite a expresso, clicando no link <Condition> (Figura 94).

Figura 94 Link para edio da expresso
Na prxima janela, clique em Builder, ilustrado na Figura 95.
Figura 95 Link Builder
Na janela que apresentada (Figura 96), configure o operando (Operand) com o texto $fault/ctx:errorCode, sem as aspas. No campo valor (value), insira o contedo "BEA-382505", inclusive com as aspas. O operador (operator) deve ser =. Por fim, clique em Add.
Figura 96 Configurao da expresso
Nesta configurao criada a expresso $fault/ctx:errorCode = "BEA-382505" que torna-se verdadeira quando ocorre um erro de validao, que identificado pelo cdigo interno BEA-382505". Aps adicionar a expresso, clique em Validate e ento em Save. Caso a expresso no seja validada, redigite manualmente o contedo. Ao retornar a janela anterior, adicione a ao de controle de fluxo Raise Error, conforme ilustra a Figura 97.
Figura 97 Adicionando a ao de controle de fluxo Raise Error
Na prxima tela, insira a mensagem que gostaria que o cliente recebesse ao levantar a exceo de erro de validao da estrutura de mensagens (Figura 98).
Figura 98 Configurao da mensagem enviada ao cliente ao detectar erro de validao
Aps inserir a mensagem, clique em Validade e depois em Save. Salve todas as alteraes e ative-as no OSB. 4.4.2.2 Teste da configurao da manipulao do erro Ao executar o cliente novamente com o objeto passado como parmetro de chamada do servio faltando o atributo Nome, retornada a mensagem de erro apresentada na Figura 99. Observe que todo o detalhamento da mensagem permanece inalterado exceto a descrio configurada no OSB (destacada na Figura 100).
<WS data binding error>could not find getter for property 'Nome' on br.com.petrobras.beans.ConsultaUnidadeOperativa ******************************************************* java.rmi.RemoteException: SOAPFaultException - FaultCode [{http://schemas.xmlsoap.org/soap/envelope/}Server] FaultString [Estrutura incompatvel: Sua solicitao no pode ser resolvida porque algum componente no passou na validao. Por favor, verifique as classes e parmetros de sua mensagem.] FaultActor [null] Detail [<detail><con:fault xmlns:con="http://www.bea.com/wli/sb/context"><con:errorCode>Estrutura incompatvel</con:errorCode><con:reason>Sua solicitao no pode ser resolvida porque algum componente no passou na validao. Por favor, verifique as classes e parmetros de sua mensagem.</con:reason><con:location><con:node>PipelinePairNode1</con:node ><con:pipeline>PipelinePairNode1_request</con:pipeline><con:stage>Vali dao da requisio</con:stage><con:path>requestpipeline</con:path><con:error-handler>true</con:errorhandler></con:location></con:fault></detail>]; nested exception is: javax.xml.rpc.soap.SOAPFaultException: Estrutura incompatvel: Sua solicitao no pode ser resolvida porque algum componente no passou na validao. Por favor, verifique as classes e parmetros de sua mensagem. at br.com.petrobras.sistema.wsclient.UnidadeOperativaService_Stub.getUnid adeOperativa(UnidadeOperativaService_Stub.java:37) at Main.WSCliente.main(WSCliente.java:29) Caused by: javax.xml.rpc.soap.SOAPFaultException: Estrutura incompatvel: Sua solicitao no pode ser resolvida porque algum componente no passou na validao. Por favor, verifique as classes e parmetros de sua mensagem. at weblogic.wsee.codec.soap11.SoapCodec.decodeFault(SoapCodec.java:265) at weblogic.wsee.ws.dispatch.client.CodecHandler.decodeFault(CodecHandler.java :106) at weblogic.wsee.ws.dispatch.client.CodecHandler.decode(CodecHandler.java:91) at webloglogic.wsee.ws.dispatch.client.CodecHandler.handleFault(CodecHandler.java: 79) at webloglogic.wsee.handler.HandlerIterator.handleFault(HandlerIterator.java:254) at webloglogic.wsee.handler.HandlerIterator.handleResponse(HandlerIterator.java:22 4) at webloglogic.wsee.ws.dispatch.client.ClientDispatcher.handleResponse(ClientDispa tcher.java:161)
at webloglogic.wsee.ws.dispatch.client.ClientDispatcher.dispatch(ClientDispatcher. java:116) at weblogic.wsee.ws.WsStub.invoke(WsStub.java:89) at weblogic.wsee.jaxrpc.StubImpl._invoke(StubImpl.java:335) at br.com.petrobras.sistema.wsclient.UnidadeOperativaService_Stub.getUnid adeOperativa(UnidadeOperativaService_Stub.java:32) ... 1 more Figura 99 Mensagem de erro personalizada java.rmi.RemoteException: SOAPFaultException - FaultCode [{http://schemas.xmlsoap.org/soap/envelope/}Server] FaultString [Estrutura incompatvel: Sua solicitao no pode ser resolvida porque algum componente no passou na validao. Por favor, verifique as classes e parmetros de sua mensagem.] FaultActor [null] Detail [<detail><con:fault xmlns:con="http://www.bea.com/wli/sb/context"><con:errorCode>Estrutura incompatvel</con:errorCode><con:reason>Sua solicitao no pode ser resolvida porque algum componente no passou na validao. Por favor, verifique as classes e parmetros de sua mensagem.</con:reason><con:location><con:node>PipelinePairNode1</con:node ><con:pipeline>PipelinePairNode1_request</con:pipeline><con:stage>Vali dao da requisio</con:stage><con:path>requestpipeline</con:path><con:error-handler>true</con:errorhandler></con:location></con:fault></detail>]; nested exception is: javax.xml.rpc.soap.SOAPFaultException: Estrutura incompatvel: Sua solicitao no pode ser resolvida porque algum componente no passou na validao. Por favor, verifique as classes e parmetros de sua mensagem. Figura 100 Detalhe da mensagem de erro retornada pelo barramento
4.4.3
Concluso
O ESB pode ser configurado para realizar validaes crticas nas estruturas das mensagens e identificar alteraes em seus objetos e parmetros que podem, por exemplo, representar equvocos por parte do cdigo do cliente ou servidor. Como uma exceo permite a execuo de outras aes. No OSB, possvel configurar compensaes para os erros identificados. Por exemplo, um erro de validao de estrutura poderia iniciar outra ao inserida em um manipulador de erro para rotear essa mensagem para outras verses do mesmo servio, a fim de verificar se a diferena encontrada na estrutura do servio um problema de versionamento ou se realmente trata-se de um erro que deve ser registrado e comunicado ao cliente, seja atravs de mensagens personalizadas ou at atravs de outros servios que poderiam ser invocados a partir do erro de validao. Portanto, a ferramenta permite a configurao de vrias aes a partir de um erro em algum estgio. Sua estrutura anloga a um processo que possui subprocessos de compensao para possveis eventos que possam surgir durante a execuo do processo principal, por exemplo, um erro levantado por alguma exceo.
4.5
Versionamento de servios utilizando o OSB
Esta seo apresenta solues para versionamento de servios utilizando o OSB, de acordo com exemplos prticos de necessidades de versionamento identificados juntos GDIEP. 4.5.1 Alterao do parmetro de entrada de servio
Nesta seo apresentada a soluo para o problema de versionamento de parmetro de entrada de servio utilizando o barramento. 4.5.1.1 Descrio do problema e projeto de soluo A necessidade de versionamento de servio correspondente ao seguinte cenrio: O servio est sendo utilizado por n consumidores e um dos consumidores solicita que um parmetro p1 de entrada do servio seja alterado para um novo parmetro p2. Neste caso, existe uma correspondncia direta entre os valores de p1 e p2. O servio que realiza a consulta s informaes de plataforma, na verso v1, tinha um mtodo que recebia a sigla da Unidade Operativa como parmetro, e, na verso v2, foi solicitado que fosse passado o cdigo da Unidade Operativa como parmetro, ao invs da sigla. Uma observao importante que o cdigo da unidade operativa pode ser obtido a partir da sigla.
Este caso corresponde ao seguinte exemplo real:
Portanto, dado esta modificao no servio, todos os consumidores da verso v1 do servio que passavam a sigla como parmetro deveriam agora passar o cdigo da unidade operativa como parmetro, invocando a verso v2 do servio. Ou seja, se os consumidores utilizarem a mesma chamada do servio para invocar a nova verso, ocorrer erro. Com intuito de realizar a alterao para atender ao consumidor que solicitou a modificao do servio sem impactar os demais consumidores, o barramento de servios foi utilizado para resolver este problema. A Figura 101 apresenta um esquema de invocao da verso v1 do servio PlataformaService a qual estava publicada no barramento. Neste caso, a verso v1 do servio foi publicada no barramento e um servio de Proxy (Proxy1) responsvel por fazer o roteamento das solicitaes dos consumidores para o servio.
OSB
Consumidor 1
Consumidor 2
Proxy1
Plataforma service v1
Consumidor 3 Figura 101 Esquema de invocao da verso v1 do servio PlataformaService publicado no barramento
Para solucionar o problema do versionamento do servio e dado que existe um mapeamento entre o cdigo da unidade operativa a partir da sigla, decidiu-se ento manter uma nica verso do servio (a verso v2). A Figura 102 apresenta um esquema da soluo adotada. Desta forma a verso v2 do servio foi publicada no barramento e a verso v1 foi removida. Um servio de proxy (Proxy 2) foi criado para fazer o roteamento para a verso v2. O consumidor que solicitou a nova verso (Consumidor 3) passou a invocar o servio de proxy2. A fim de que os outros consumidores no fossem impactados com a modificao, ou seja, continuassem invocando o mesmo servio, o servio de proxy1 foi alterado para passar a invocar a verso v2 do servio PlataformaService. Ou seja, os parmetros de entrado do sevio de proxy 1 foram mantidos (recebe a sigla da unidade operativa), no entanto, ao invs do servio de proxy 1 fazer o roteamento para a verso v1 do servio PlataformaService ele passou a fazer o roteamento para a verso v2. Para poder realizar esta invocao, o servio de proxy 1 faz uma transformao da mensagem recebida que contm a sigla para passar a ter o elemento cdigo. Os seguintes passos so realizados no fluxo do servio de proxy 1: Recebe a mensagem de entrada; Realiza um DatabaseLookUp para recuperar o cdigo correspondente sigla da Unidade Operativa que veio na mensagem; Substitui no corpo da mensagem a sigla da Unidade Operativa para ser o cdigo da Unidade Operativa e o nome da funo que est sendo chamada no servio verso v1 para o nome da funo que ser invocada no servio verso v2; Faz o roteamento para a verso v2 do servio.
No foi necessrio fazer nenhuma transformao na mensagem de resposta, pois esta no sofreu alterao da verso v1 para v2.
OSB
Consumidor 1
Proxy1
Consumidor 2
Plataforma service v2 Proxy2
Consumidor 3
Figura 102 - Esquema de invocao da verso v2 do servio PlataformaService publicado no barramento
4.5.1.2 Implementao da soluo O OSB oferece uma funcionalidade em seu fluxo de mensagem que permite a modificao do contedo de uma mensagem XML. Para realizar a chamada do servio verso v2 necessrio o parmetro codigo que obtido a partir do parmetro sigla atravs da execuo de uma consulta SQL. Utilizando a funo Replace para alterar o contedo da mensagem em conjunto com a funo fn -bea:execute-sql para executar o comando SQL, possvel configurar um Stage no fluxo de mensagem que realiza as alteraes necessrias na mensagem de chamada do servio verso v1 para a correta invocao do servio verso v2. Para atender necessidade dos clientes que invocam o servio passando o parmetro sigla ou codigo foram implementados os servios de proxy UnOpCodig oProxy (Proxy1 da Figura 102) e UnOpSiglaProxy (Proxy 2 da Figura 102). O servio UnOpCodigoProxy utilizado pelos clientes que invocam o servio utilizando o parmetro codigoe ele somente realiza o roteamento da mensagem para o servio verso v2, conforme sua configurao de fluxo de mensagem, ilustrada na Figura 103.
Figura 103 Configurao do UnOpCodigoProxy
Os clientes configurados para invocar o servio passando como parmetro a sigla da Unidade Operativa, permanecem invocando o antigo servio de proxy UnOpSiglaProxy, porm, ele sofrer modificaes em seu fluxo de mensagem para rotear suas mensagens para o novo servio verso v2. Como pode ser visto na Figura 104, o servio UnOpSiglaProxy est configurado para repassar as mensagens ao servio verso v2. Entretanto foi inserido um novo estgio (stage 1) no caminho de requisio do servio (Request Pipeline) que ser configurado
para alterar a mensagem original, adaptando-a para invocar corretamente o servio de destino do proxy (Figura 104).
Figura 104 Configurao do Stage 1, no proxy UnOpSiglaProxy
O passo a passo da configurao do estgio descrito a seguir: Ao editar o Stage 1, adicione a ao de processamento da mensagem Replace, conforme ilustra a Figura 105:
Figura 105 Adicionando a ao Repleace no proxy UnOpSiglaProxy
A configurao do Replaceconsiste em selecionar alguma parte da estrutura da mensagem utilizando o Xpath e alter-la com um valor definido em Expression. possvel alterar um n inteiro na mensagem com o valor definido, caso selecione a opo Replace entire node, ou substituir somente o valor de variveis, caso selecione a opo Replace node contents. Clique no link <Xpath> para selecionar a estrutura que ser alterada (Figura 106):
Figura 106 Link <Xpath>
Selecione a estrutura a ser alterada e copie seu respectivo comando Xpath para o quadro no centro da janela. Clique em Save. No exemplo, todo o n ser modificado para permitir a chamada de outro servio (Figura 107).
Figura 107 Seleo da estrutura a ser alterada
Preencha o campo com o nome da Variable Structure que bodye clique no link <Expression> (Figura 108):
Figura 108 Configurao da funo Repleace
Na prxima janela, dever ser configurada a expresso que substituir o n selecionado anteriormente. O objetivo reescrever o cdigo da mensagem para invocar corretamente o servio verso v2. Para facilitar o entendimento, o cdigo ser apresentado gradativamente. No primeiro momento, construda a estrutura textual com as tags
da mensagem XML (Figura 109) contendo o nome da funo que ser chamada no servio e o parmetro codigo. Observe que no h contedo definido para a tag que representa o cdigo (<ser:codigo>), j que ele ser definido pela funo fn bea:execute-sql. <ser:getUnOpCodigo xmlns:ser="http://br/com/petrobras/services"> <ser:codigo> </ser:codigo> </ser:getUnOpCodigo>
Figura 109 Cdigo XML que define a estrutura da mensagem para invocar o novo servio
Para definir o valor do cdigo, ser executada uma consulta SQL para obter o valor do banco a partir da sigla. Para isso ser utilizada a funo fn-bea:execute-sql, que possui a seguinte sintaxe: fn-bea:execute-sql($datasource-string, $rowElemName, $sql-string, $params...) onde: $datasource o nome do JNDI do datasource. $rowElemName o nome do elemento que define a estrutura de retorno. $sql-string o comando SQL. $params ... a enumerao de parmetros de 1 at k. Para o exemplo proposto, a linha de comando da funo ser como a ilustrada na Figura 110: fn-bea:execute-sql( 'UnOperativaDataSource', xs:QName('getUnOpCodigo'), 'SELECT unop_cd_unid_oper as codigo FROM unid_operativa WHERE unop_sg_unid_oper =?', xs:string($body/ser:getUnOpSigla/ser:sigla)))
Figura 110 Linha de comando da funo fn-bea:execute-sql()
O retorno desta funo uma estrutura conforme ilustra a Figura 111: < getUnOpCodigo>
< CODIGO>99999</CODIGO> </getUnOpCodigo>

Figura 111 Retorno da funo fn-bea:execute-sql()
Para extrair somente o valor do cdigo, que o valor de interesse, deve-se utilizar a funo fn:string($arg-atomic). O cdigo pode ser visto na Figura 112: <ser:getUnOpCodigo xmlns:ser="http://br/com/petrobras/services"> <ser:codigo> { fn:string( fn-bea:execute-sql( 'UnOperativaDataSource', xs:QName('getUnOpCodigo'),
'SELECT unop_cd_unid_oper as codigo FROM unid_operativa WHERE unop_sg_unid_oper =?', xs:string($body/ser:getUnOpSigla/ser:sigla))) } </ser:codigo> </ser:getUnOpCodigo>
Figura 112 Cdigo que retorna o contedo que substituir a estrutura anterior
Observe que o comando foi inserido entre chaves ({}). Isso necessrio para o OSB interpretar o contedo como um comando e no somente um texto. Aps finalizar a configurao, clique em Validate e depois em Save. A configurao final da funo Replace ilustrada na Figura 113. A opo Replace entire node deve permanecer marcada. Clique em Validate e depois em Save.
Figura 113 Configurao final da funo Repleace
O fluxo de mensagem final pode ser visualizado na Figura 114:
Figura 114 Fluxo de mensagem do Proxy UnOpSiglaProxy
Ao executar o cliente para o proxy UnOpSiglaProxy, foi obtido o resultado esperado, conforme ilustra a Figura 115:
<env:Envelope xmlns:env="http://schemas.xmlsoap.org/soap/envelope/"> <env:Header /> <env:Body> <m:getUnOpSiglaResponse xmlns:m="http://br/com/petrobras/services"> <unid:UnidadesOperativasList xmlns:unid="http://controls.beans/unidadeoperativa"> <unid:UnidadeOperativa> <unid:codigoUnidadeOperativa>1</unid:codigoUnidadeOperativa> <unid:indicadorAtiva>PT </unid:indicadorAtiva> <unid:siglaUnidadeOperativa>BRA</unid:siglaUnidadeOperativa> <unid:nomeUnidadeOperativa>AS</unid:nomeUnidadeOperativa> <unid:codigoUnidadeOperativaAGP>1</unid:codigoUnidadeOperativaAGP> </unid:UnidadeOperativa> </unid:UnidadesOperativasList> </m:getUnOpSiglaResponse> </env:Body> </env:Envelope> Figura 115 Resposta da chamada do servio de proxy UnOpSiglaProxy
4.5.1.3 Concluso O OSB permite alterao do texto da mensagem XML com flexibilidade, permitindo alterar tanto estrutura ou como tambm somente os valores das variveis. No problema real citado nesta seo, houve a necessidade de adaptar uma mensagem endereada a um servio para que fosse executado por outro. A funo Replacepermitiu a edio da mensagem original e a funo fn-bea:execute-sql permitiu consultar o banco de dados em tempo de execuo para obter o parmetro correto que satisfaz o servio para o qual a mensagem modificada seria roteada pelo barramento. O resultado foi satisfatrio j que todo esse processo se mostrou transparente ao cliente do servio.
4.6
Monitoramento de servios
O OSB gerencia as transformaes e roteamento de mensagens no barramento e oferece opes administrativas e de monitoramento. Por exemplo, o OSB permite coletar informaes em tempo real sobre o fluxo de mensagens que percorrem o barramento em um determinado perodo. O painel de informaes do OSB (dashboard) permite monitorar o estado do sistema e visualizar as notificaes emitidas pelo OSB quando ocorrem alertas emitidos pelos servios. Com estas informaes o responsvel pela gerncia do ambiente de servios pode rapidamente isolar e diagnosticar os problemas que ocorrem. O framework de monitoramento do OSB prov vrias funes de acesso a informaes do que est ocorrendo no barramento. Por exemplo, informaes sobre o nmero de mensagens que foram processadas com sucesso ou falha, o projeto que o servio pertence, a mdia de tempo de execuo do processamento de mensagens e o nmero de alertas associados a um servio.
4.6.1
Configurao do tempo de coleta de dados
O OSB realiza a coleta de dados em um intervalo fixo de tempo, chamado de intervalo de agregao (aggregation interval). Este intervalo pode ser configurado pelo usurio do OSB atravs de uma lista com valores pr-definidos oferecida pela ferramenta. Para um dado intervalo de agregao, automaticamente configurado um subintervalo chamado de intervalo de amostra (sample interval), onde sero computadas as estatsticas em tempo real. No intervalo de amostra so coletadas, a cada perodo, as informaes relativas funo configurada no OSB. Essas informaes so armazenadas a cada ciclo do intervalo de amostra at o momento em que o intervalo de agregao tambm finaliza seu ciclo, e ento todas as amostras coletadas so publicadas no console do OSB. A relao entre o intervalo de agregao e o intervalo de amostra pode ser vista na Tabela 1. Por exemplo, no primeiro caso, de 1 em 1 minuto sero gravadas as amostras (vide coluna intervalo de amostra) e, de acordo com o intervalo de agregao escolhido (1 ou 2 ou 3 ou 4 ou 5 minutos), as informaes sero publicadas no barramento.
Tabela 1 Relao entre intervalo de agregao e intervalo de amostra Intervalo de agregao
1, 2, 3, 4 e 5 minutos 10, 15, 20, 25 e 30 minutos 40, 50 e 60 minutos 90 e 120 minutos 3, 4, 5 e 6 horas 8, 10 e 12 horas 16, 20 e 24 horas 2, 3, 4, 5, 6 e 7 dias
Intervalo de amostra
1 minuto 5 minutos 10 minutos 30 minutos 1 hora 2 horas 4 horas 1 dia
O intervalo de agregao no OSB possui as seguintes propriedades:

S possvel configurar e obter estatsticas de um servio em relao a somente um intervalo de agregao. No possvel configurar valores arbitrrios para o intervalo de agregao. Somente os valores oferecidos pela ferramenta podem ser selecionados. O intervalo de agregao somente pode ser configurado para servios de proxy ou de negcio (business service). Uma regra de alerta (alert rule) deve ser configurada atravs da definio de uma condio e do respectivo valor do intervalo de agregao.
importante observar que, se um servio for renomeado, todas as estatsticas que foram coletadas sobre ele sero perdidas, todas as configuraes sero reiniciadas e o monitoramento do servio iniciar do comeo. Caso seja modificado somente o intervalo de agregao de um servio, as estatsticas desse servio sero reiniciadas, porm as mtricas de contagem configuradas e registradas no sero modificadas. Para configurar o intervalo de agregao no OSB, siga os passos apresentados a seguir.
1. Clique no servio (business service ou Proxy service) para o qual deseja configurar o intervalo de agregao (Figura 116). importante observar que, para realizar esta configurao, necessrio criar uma seo.
Figura 116 Seleo do servio para configurao do intervalo de agregao
2. Clique no link Operational Settings, conforme mostra a Figura 117:
Figura 117 Link Operational Settings
Nesta tela esto as opes que habilitam os diferentes tipos de mensagens que podem ser registradas pelo monitoramento do OSB. Em Aggregation Interval possvel configurar o intervalo de agregao utilizando os valores que esto pr-definidos entre 0 minutos e 7 dias. Outros alertas podem ser habilitados devendo ainda configurar o nvel de gravidade mnima da mensagem que dever ser considerada pelo monitor. Ao selecionar um nvel de gravidade, somente as mensagens deste nvel e de nveis mais crticos sero alertadas pelo OSB. A Tabela 2 detalha as opes desta tela, as quais so descritas em mais detalhes nas prximas sees.
Tabela 2 Opes do Oracle Service Bus Console
Funcionalidade
State Monitoring
Descrio
Esta opo habilita ou desabilita o servio Esta opo habilita o servio de monitoramento a partir de um nvel especfico ou superior. Ainda possvel desabilitar o monitoramento do servio para um servio de Proxy. Esta opo configura o intervalo de agregao do servio. Esta opo habilita o alerta de SLA para os servios com um nvel de gravidade especfico ou maior. Ainda possvel desabilitar o alerta de SLA para o servio. Esta opo habilita o alerta de pipeline para servios de Proxy com um nvel de gravidade especfico ou maior. Ainda possvel desabilitar o alerta de pipelining para o servio de Proxy. Esta opo habilita ou desabilita a mensagem de relatrio para o servio de Proxy. Esta opo habilita o Log para mensagens com um nvel de gravidade especfico ou maior. Ainda possvel desabilitar o Log para servios de Proxy. Esta opo habilita ou desabilita o Execution Tracing para servios de Proxy. Esta opo habilita ou desabilita o Message tracing para um servio de Proxy com um nvel de detalhe especfico ou maior. Ainda possvel configurar o limite da carga (em KB) e o codificador padro. Esta opo habilita ou desabilita endpoints de servios de negcio que no respondem. Ainda possvel especificar um intervalo de tempo para espera, antes de tentar novamente uma chamada ao endpoint que se encontra offline. Somente possvel habilitar e desabilitar endpoints offline pra servios de negcio. Esta opo habilita ou desabilita throttling para um servio de negcio. Esta opo restringe o nmero de mensagens que podem ser processadas concorrentemente por um servio de negcio.
Padro
Habilitado Desabilitado
Aggregation Interval SLA Alerts
10 minutos Habilitado
Pipeline Alerts
Habilitado no nvel Normal ou maior
Reports
Habilitado nvel Normal ou maior
Logs
Habilitado no nvel de Debug ou maior
Execution Tracing Message Tracing
Desabilitado Desabilitado
Offline Endpoint URIs
Desabilitado
Throttling State Maximum Concurrency
Desabilitado 0
Throttling Queue Message Expiration
Esta opo restringe o nmero mximo de mensagens na fila do throttling. O intervalo mximo de tempo (em milissegundos) no qual uma mensagem pode ser instalada em uma fila de throttling.
0 0
4.6.2
Mensagens de monitoramento no OSB
Esta seo apresenta as funcionalidades apresentada na Tabela 2, explicando a configurao prtica destas funes. 4.6.2.1 Alert-Destination Os destinos de alerta (Alert-Destination) so recursos inseridos no OSB que permitem configurar o destino para a emisso das mensagens dos alertas levantados pelo barramento. Por padro, o Oracle Service Bus Console um destino para as notificaes de qualquer alerta, independente da configurao de outros destinos de alerta. No OSB possvel configurar um e-mail, SNMP Traps, relatrio e JMS como destinos de alerta. O SNMP (Simple Network Management Protocol) traps oferece uma interface a outros softwares para monitorarem os nveis de acordo de servio configurados no OSB. Habilitando notificaes de alerta do SNMP Trap, as ferramentas Web Services Management (WSM) e o Enterprise Service Management (ESM) podem monitorar violaes de SLA e alertas de pipeline atravs de suas notificaes de alerta. Para maiores informaes sobre a configurao de destinos de alerta no OSB, consulte o guia de operaes (Operations Guide) do Oracle Service Bus [OSB, 2008b]. 4.6.2.2 Configurao de alertas de SLA (SLA Alerts) Os alertas de SLA11 so mensagens emitidas automaticamente quando identificada a violao de algum contrato de nvel de servio ou condio pr-definida configurada no OSB. Os alertas de SLA podem ser utilizados para: Monitoramento e gerao de notificao por e-mail de erros de segurana (WSSecurity). Monitoramento do nmero de mensagens que trafegam em um dado pipeline. Deteco da violao do contrato de nvel de servio (SLA) com produtos de terceiros (SNMP Trap). Deteco de enpoints que no respondem. 1. Clique no servio (Proxy service ou Business service) o qual deseja configurar o alerta de SLA, conforme mostra a Figura 118.
Para configurar um alerta de SLA no OSB, execute os seguintes passos:
11 http://pt.wikipedia.org/wiki/Acordo_de_N%C3%ADvel_de_Servi%C3%A7o
Figura 118 Selecionando o servio para a configurao do alerta SLA
2. Na prxima janela, clique em SLA Alert Rules, conforme ilustra a Figura 119:
Figura 119 Janela de configurao do servio de negcio (Business service)
3. Na prxima janela, clique em Add new (Figura 120).
Figura 120 Adicionando uma regra para o alerta SLA
4. Na janela de configurao do alerta insira os parmetros necessrios e clique em Next(Figura 121).
Figura 121 Configurao de nova regra de alerta
5. Na janela de configurao de condies de regra de alerta, configure o intervalo de agregao (Aggregation Interval) para esta regra e a expresso condicional para disparar a mensagem. Caso seja necessrio utilizar expresses compostas utilizando os operadores And e/ou Or, insira primeiro todas as expresses condicionais, depois selecione as expresses que faro parte da composio e clique no boto And ou Or(Figura 122).
Figura 122 Configurao de expresso composta para alerta de SLA
6. possvel realizar composies com mais de duas expresses e/ou com expresses que j foram compostas. Para isso, selecione as expresses desejadas e clique no respectivo operador lgico (Figura 123).
Figura 123 Composio de expresso utilizando expresses j compostas
7. Ao finalizar a configurao da expresso, clique em Last (Figura 124).
Figura 124 Janela de configurao da condio de alerta configurada
8. Na prxima janela, que mostra o resumo das configuraes realizadas, clique em Save.
Figura 125 Resumo da configurao do alerta SLA
Ao executar o servio que obedece a condio para emisso da mensagem de alerta SLA, o Oracle Service Bus Console registra a ocorrncia do alerta conforme mostra a (Figura 126), respeitando o tempo de agregao configurado para o aparecimento do registro.
Figura 126 Registro do alerta de SLA no Oracle Service Console
Observe o grfico em pizza demonstrando a estatstica de 100% de mensagens do tipo Major, considerando que s existe 1 mensagem registrada. Para obter mais informaes sobre o registro, clique no link respectivo ao Alert Name. A Figura 127 mostra um exemplo de detalhamento do alerta.
Figura 127 Detalhamento da mensagem de alerta SLA
4.6.2.3 Configurao de alertas de Pipeline (Pipeline Alerts) O alerta de pipeline pode ser gerado ao configurar uma ao de alerta no fluxo de mensagens de um servio de Proxy. A mensagem de alerta pode ser usada para detectar erros no fluxo de mensagem e/ou indicar ocorrncias do negcio, sendo emitida caso a sua condio de disparo seja satisfeita. Para programar a condio no fluxo, poder ser usada a linguagem XQuery para acessar valores nas mensagens e os construtores do fluxo de mensagem if-then-else para programar as condies. Ainda possvel configurar destinos adicionais (o destino padro o OSB) para a emisso de mensagens de alerta de pipeline. O texto de mensagem do alerta editvel, podendo incluir texto e valores de variveis de contexto. Os alertas gerados pelo servio e registados pelo OSB podem ser visualizados na pgina do painel principal no Oracle Service Bus Console.
Para configurar um alerta de pipeline dentro do fluxo de mensagem do OSB, siga os passos a seguir: 1. Ao editar o fluxo de mensagem no servio de Proxy alvo no OSB, selecione o estgio onde deseja realizar a configurao de um alerta, e ento clique em Edit Stage (Figura 128).
Figura 128 Editando um estgio no fluxo de mensagem
2. Neste exemplo ser mostrada a utilizao do alerta utilizando uma condio (se o cdigo da Unidade Operativa for igual a 1). Portanto, na janela de edio do estgio, insira a condio de IF e adicione a ao de alerta clicando no dado estgio ou em Add an Action e indo em Add an Action/Reporting/Alert conforme mostra a Figura 129. Caso no deseje utilizar uma condio, mas apenas configurar a ao de alerta, simplesmente adicione a ao correspondente no local mais adequado dentro do fluxo de mensagem.
Figura 129 Adicionando uma ao de Alert
3. Insira um parmetro para o Alert clicando em Expression e inserindo o respectivo Xquery. Preencha o campo Alert-Summary com um texto que descreva os motivos do alerta e selecione o nvel de gravidade do alerta na caixa de rolagem (Figura 130). possvel configurar mltiplos destinos para a mensagem de alerta. Para isso, necessrio configurar recursos de destino (Destination). As informaes de como realizar esses procedimentos podem ser encontradas no guia de operaes (Operations Guide) do Oracle Service Bus [OSB, 2008b].
Figura 130 Configurando uma mensagem de Alerta
Ao executar o servio que obedece a condio para emisso da mensagem de Alerta (cdigo = 1), o Oracle Service Bus Console registra a ocorrncia do alerta conforme mostra a (Figura 131), respeitando o tempo de agregao configurado para o aparecimento do registro.
Figura 131 Registro do alerta de pipeline no Oracle Service Bus Console
Observe o grfico em pizza apresenta a estatstica de 100% de mensagens do tipo Warning. Isto ocorreu porque s existe 1 mensagem registrada. Para obter mais informaes sobre o registro, clique no link respectivo ao Alert Summary. A Figura 132 mostra o detalhamento do alerta.
Figura 132 Detalhamento da mensagem de alerta de pipeline
4.6.2.4 Configurao do Report A ao de Report no OSB permite emitir uma mensagem de relatrio contendo dados extrados da mensagem XML que est sendo tratada no fluxo de mensagem. Para poder utilizar a ao de Report dever ser configurado um provedor de relatrio (reporting provider) para receber as mensagens de relatrio. O OSB entrega os dados da mensagem e dos alertas para um ou mais provedores de relatrio. Os dados da mensagem podem ser capturados do body da mensagem e de outras variveis associadas com a mensagem, como o header ou inbound variables.
O OSB oferece o JMS reporting provider como provedor de relatrio padro. O mdulo de relatrio (reporting module), no OSB console, exibe as informaes capturadas pelo provedor de relatrio. Caso no se deseje utilizar este provedor, possvel criar um provedor especfico utilizando o Reporting Service Provider Interface (SPI). Caso seja configurado um provedor prprio, as informaes enviadas a ele no sero exibidas no console do OSB, sendo necessrio desenvolver uma interface para o usurio. Para obter maiores informaes sobre o uso do SPI, consulte o guia de operaes (Operations Guide) do Oracle Service Bus [OSB, 2008b]. O provedor padro JMS Reporting Provider automaticamente configurado quando criado um domnio no OSB. Todas as mensagens so reunidas e guardadas em um banco de dados do JMS (JMS Reporting Provider Data Store) em um formato especfico. Para receber mensagens de relatrio do JMS Reporting Provider, necessrio criar uma ao de Report no fluxo de mensagens de um servio de Proxy. A ao de Report permite extrair informaes de cada mensagem e registrar no OSB Reporting provider. Para isso, necessrio especificar a informao que se deseja extrair da mensagem e adicionar no OSB Reporting Data Stream. Para realizar a configurao de um relatrio dentro do fluxo de mensagem do OSB, siga os passos a seguir: 1. Ao editar o fluxo de mensagem no servio de Proxy alvo no OSB, selecione o estgio onde deseja realizar a configurao de um alerta, e ento clique em Edit Stage (Figura 128). 2. Adicione a ao no local mais adequado dentro do fluxo de mensagem indo em Add an Action/Reporting/Report (Figura 133).
Figura 133 Adicionando uma ao de Report
3. Para configurar a ao de Report, clique em <Expression> (Figura 134) para selecionar, utilizando o Xpath, as informaes que se deseja incluir na mensagem do relatrio. As informaes podem ser includas no somente a partir da varivel Body da mensagem, mas de qualquer parte da mensagem como, por exemplo, os dados do campo header. Para este exemplo, foi selecionado todo o contedo da varivel body (Figura 135).
Figura 134 Link para seleo de partes da mensagem que sero incluidas no Report
Figura 135 Contedo da varivel body selecionado para constar no relatrio
4. O prximo passo inserir uma chave (Key Name) junto com o valor de uma varivel da mensagem (Key Value) para identificar o relatrio. possvel inserir mais de uma chave e seus respectivos valores. Para inserir a chave clique em Add key (Figura 136).
Figura 136 Adicionando uma chave para o relatrio
5. No novo quadro que surgir, insira no campo Key Name o nome da chave, e no campo Key Value, o valor da chave a partir do contedo da mensagem que est sendo manipulada dentro do estgio, identificando tambm a varivel de onde o valor est sendo extrado (Figura 137).
Figura 137 Configurao do Report
6. Para adicionar outra chave, clique no cone da chave e depois em Add Key, conforme ilustra a Figura 138:
Figura 138 Adicionando mais uma chave
Se estiver usando o provedor padro JMS Reporting Provider, as chaves e seus valores associados so mostrados na coluna de ndice dos relatrios, na tabela de resumos
das mensagens. Para acessar essa tabela, a partir da tela principal v em Operations/Message Reports, conforme ilustra a Figura 139.
Figura 139 Tela de resumo das mensagens de relatrio
Ao executar o servio que emite uma mensagem de relatrio, a mensagem registrada pelo JMS exibida na janela de resumo de mensagens de relatrio (Figura 140).
Figura 140 Registro da mensagem de relatrio
No campo Report Index encontra-se a chave e o valor da chave configurado na ao de Report. O campo DB TimeStamp mostra a data e o horrio da ocorrncia da mensagem. O campo Inbound Service mostra o caminho do servio de Proxy que originou a mensagem e o campo Error Code somente preenchido quando a mensagem de relatrio for configurada a partir de um estgio do tipo Error Handller, onde o cdigo do erro associado mensagem de relatrio.
Para acessar os detalhes da mensagem de report, clique na respectiva chave da mensagem dentro da lista de mensagens de relatrio, na coluna Report Index (Figura 141 ).
Figura 141 Link para o detalhamento da mensagem de relatrio
A Figura 142 ilustra o contedo da mensagem de relatrio. Clicando em Detail, o OSB exibir o contedo programado na ao de Report. Neste exemplo foi configurada a ao para extrair o contedo do body da mensagem (Figura 143).
Figura 142 Detalhamento da mensagem de relatrio
Figura 143 Contedo extrado da mensagem para compor o relatrio
4.6.2.5 Resumo de Logs O OSB possui uma seo de resumo de log (Log Summary) que mostra o resumo das mensagens de log dos servidores associados ao domnio. O arquivo de log do domnio oferece uma localizao central dos logs dos servidores associados ao domnio, no qual possvel verificar o estado geral do domnio. Cada instncia de servidor envia um subconjunto de suas mensagens para um arquivo de log do domnio. Por padro, os servidores emitem somente algumas mensagens de nvel de gravidade maior ou igual a Notice e no possvel modificar esse conjunto de mensagens que so enviadas. Se for configurada uma ao de log no pipeline, a mensagem enviada para o servidor que administra os logs (Admin server log). possvel visualizar a mensagem de log na sesso Server Health do OSB (Figura 144). Para acessar as mensagens de log no seo Log Summary, v em Operations/Dashboard/Server Health.
Figura 144 Seo de resumo de log
Somente os usurios que possurem o privilgio de administrador podero visualizar o resumo de log. A Tabela 3 descreve os nveis de gravidade que agrupam as mensagens no resumo de log.
Tabela 3 Descrio dos nveis de gravidade no resumo de log Nvel de gravidade
Alert
Descrio
Este nvel indica que um servio particular est em um estado instvel enquanto outras partes do sistema continuam funcionando normalmente. A recuperao automtica no possvel, logo a ateno imediata do administrador necessria para resolver o problema. Este nvel indica que o sistema ou erros de servios ocorreram. O sistema pode recuperar-se, mas podem existir perda momentnea ou permanente degradao do servio.
Critical
Emergency Error
Este nvel indica que o servidor est em um estado em que ele no pode ser usado. Isso indica que ocorreu uma falha severa no sistema. Este nvel indica que um erro de usurio ocorreu. O sistema ou aplicao pode manipular este tipo de erro sem interrupo. Degradaes limitadas no servio podem ocorrer. Este nvel reporta operaes normais com uma mensagem informativa. Esta uma mensagem informativa com um alto nvel de importncia em relao ao nvel info. Este nvel indica que uma operao suspeita ou configurao foi realizada. No entanto, as operaes normais no so afetadas.
Info Notice Warning
4.6.2.5.1 Configurao do Log Para configurar uma ao de log que ser registrada no Log summary, siga os pa ssos abaixo: 1. Ao editar um estgio (stage) em um fluxo de mensagens, adicione a ao indo em Reporting/Log (Figura 145).
Figura 145 Inserindo uma ao de log
2. Clique no link <Expression> para selecionar o contedo (utilizando o XPath) da mensagem o qual deseja anexar ao registro do log (Figura 146).
Figura 146 Anexando o contedo da mensagem no registro de log
3. Insira uma anotao no campo de texto para constar no log e escolha um nvel de gravidade para o este registro de log (Figura 147). Salve as alteraes e ative a sesso.
Figura 147 Registrando anotao e nvel de gravidade no registro de log
Ao executar o respectivo servio onde foi configurado o log, o registro inserido no resumo de log (Log Summary), respeitando o tempo de agregao. Para visualizar o registro do log, entre na seo de resumo de log e clique no respectivo nvel de gravidade para o qual o log foi configurado (Figura 148). As mensagens esto agrupadas pelo nvel de gravidade e cada linha da tabela mostra o nmero de logs registrados.
Figura 148 Mensagens no resumo de Log
A prxima janela mostra a lista de logs que esto registrados detalhando alguns campos como data, subsistema de origem, nvel de gravidade, identificao da mensagem e a prpria mensagem (Figura 149).
Figura 149 Lista de registros de log
Para acessar detalhes do log, selecione o registro e clique em View (Figura 150).
Figura 150 Selecionando o registro de log para acessar seu detalhamento
A janela seguinte mostra o contedo do detalhamento da mensagem (Figura 151).
Figura 151 Detalhamento do registro de log
4.6.2.5.2 Visualizao de detalhes do servidor possvel acessar a pgina de detalhes do servidor clicando no nome do servidor abaixo do resumo do servidor (Server Summary) (Figura 152).
Figura 152 Acesso a visualizao de detalhes do servidor
As informaes da prxima pgina (Figura 153) so mostradas em um subconjunto de abas de monitoramento do OSB. A Tabela 4 descreve as informaes disponveis.
Figura 153 Janelas de informaes sobre o servidor Tabela 4 Detalhamento das informaes sobre o servidor Aba
General Channels Performance Threads
Descrio
Esta aba oferece informaes gerais em tempo de execuo sobre o servidor. Esta aba oferece informaes de monitoramento sobre os canais. Esta aba oferece informaes sobre o desempenho do servidor. Esta aba oferece caractersticas em tempo de execuo e estatsticas das filas que esto sendo executadas no servidor no momento.
Timers Workload Security JMS JTA
Esta aba oferece informaes sobre o temporizador utilizado pelo servidor. Esta aba oferece estatsticas de Work managers, restries e polticas configuradas no servidor. Esta aba permite o monitoramento de estatsticas dos bloqueios de acesso no autorizado a usurios, realizados no servidor. Esta aba permite o monitoramento das informaes sobre JMS no servidor. Esta aba permite um resumo de toda informao de transao para todos os tipos de recursos no servidor.
4.6.2.6 Configurao Tracing O OSB permite rastrear mensagens sem ter que desligar o servidor. Essa funcionalidade permite descobrir problemas e diagnosticar fluxos de mensagens em um ou mais servios de proxy. Por exemplo, se um servio de proxy estiver falhando e o usurio desejar descobrir em qual estgio (stage) o problema se localiza, possvel habilitar o rastreamento para um servio de Proxy. Aps habilitar esta opo, o sistema registra vrios detalhes extrados do fluxo de mensagem como nome do estgio, nome do pipeline e nome do n da rota. Todo o contexto das mensagens tambm registrado, incluindo o contedo dos Headers e Message body. Quando algum problema ocorre no fluxo de mensagens, detalhes adicionais como o erro do cdigo e a razo do problema tambm so registrados. O rastreamento ocorre no incio e fim de cada componente no fluxo de mensagem, incluindo estgios, pipelines e ns. As aes (Action) no so rastreadas individualmente. Para habilitar a funo de rastreamento (Tracing) siga os passos abaixo: 1. Identifique o servio de negcio e clique nele, conforme mostra a Figura 154, para acessar suas opes.
Figura 154 Servios de proxy para configurao do Tracing
2. V na guia Operational Settings. Nesta guia se encontram as opes Execution Tracing e Message Tracing. Habilitando a opo Execution Tracing, o OSB registrar no log diversos detalhes selecionados a partir do contexto do fluxo de mensagem (message flow context) e do contexto da mensagem (message context). Estes detalhes incluem: nome do estgio (stage), nome do pipeline ou n da rota e contexto da mensagem corrente. Habilitando a opo Message Tracing, o OSB registrar no log as trocas de mensagens entre o fluxo de pipeline e o servio de proxy (requisies de entrada e resposta requisio de entrada, bem como requisies de sada e resposta da requisio de sada), ou seja, no momento em que a mensagem entra no pipeline para ser processada (requisio de entrada), quando ela sai do fluxo para ser enviada para o servio de ne_______________________________________________________________________________________________ RelaTe-DIA: Estudos de Enterprise Service Bus e Oracle Service Bus 106
gcio (requisio de sada), quando ela retorna do servio de negcio para o servio de proxy (resposta de sada) e quando a resposta enviada para o cliente (resposta da entrada). Quando aplicvel, os registros de log de mensagens de sada podem incluir o nmero de tentativas, cdigo de erro e mensagem de erro. Ao habilitar a opo Message Tracing, dever ser configurado o parmetro Detail Level, que pode ser definido como Tarse, Headers e Full. Essa opo especifica o nvel de detalhe do registro no log. Selecionando a opo Tarse, ser registrado a data, hora, tipo do servio, nome do servio e o URI. Selecionando a opo Headers, sero registradas as informaes da opo Tarse juntamente com a representao em XML dos metadados mensagem. Selecionando a opo Full, sero registradas as informaes da opo Tarse juntamente com contedo da mensagem e os anexos, se houver. Ao escolher esta opo, dever ser especificado o valor mximo do tamanho (em Kilobytes) da mensagem que ser registrada no log, preenchendo o campo Payload Tracing Limit. O campo Default Enconding opicional. Deixando-o em branco, o OSB usar o codificador padro da estao (host). Se o valor especificado no puder ser usado (por exemplo, o valor no uma opo de configurao vlida), ento o OSB utilizar o codificador Base64 no contedo que ser registrado. 3. Habilite as opes desejadas nos campo Execution tracinge Message tracing. Neste teste ambas as opes foram habilitadas, conforme mostra a Figura 155.
Figura 155 Habilitando o Trancing de servios no OSB
4. Configure o campo Detail Level como Full e defina um valor mximo em kilobytes para o tamanho do contedo gerado pelo rastreamento. O campo Default Encoding no obrigatrio. Aps a configurao, clique em Update e ative a seo (Figura 156).
Figura 156 Definindo a configurao do Tracing no OSB
O contedo gerado pelo Tracing armazenado no diretrio de log do servidor. Por exemplo, no domnio criado como exemplo, que pode ser instalado juntamente com o OSB, o caminho para o contedo gerado no arquivo de log : <OSB_HOME>\samples\domains\servicebus\servers\xbusServer\logs\servicebus.l og. OSB_HOME o diretrio no qual foi instalado o OSB. A Figura 157 mostra, como exemplo, o contedo do arquivo de log gerado pelo Tracing.
Figura 157 Exemplo do contedo do arquivo de log
4.6.2.7 Configurao do Throttling O Oracle Service Bus oferece opes de configurao de concorrncia de mensagens. As restries impostas ao fluxo de mensagens para um servio de negcio so conhecidas como Throttling. Para configurar o Throttling para um servio de negcio, necessrio habilitar a funo nas configuraes operacionais do servio de negcio (Operational Settings). Para isso, marque a opo Throttling State como Enabled (Figura 158). Observe que necessrio possuir uma seo ativa.
Figura 158 Habilitando a opo de Throttling
Aps habilitar o Throttling para um servio de negcio, necessrio especificar um valor para o campo Maximum Concurrency. Tambm podem ser definidos valores para os campos Throttling Queue e Message Expiration. Abaixo se encontra o detalhamento de cada um dos parmetros de configurao do Throttling: Maximum Concurrency: Restringe o nmero de mensagens que podem ser processadas concorrentemente por um servio de negcio. O valor deve ser um inteiro positivo. Quando o valor for alcanado por um servio de negcio, todas as mensagens de chegada para o servio de negcio sero colocadas em uma fila (Throttling queue) at o servio de negcio poder aceitar mais mensagens. Qualquer mudana neste parmetro afetar tanto as novas mensagens quanto aquelas que estiverem na fila (throttling queue). Quando o valor aumentado, o OSB permite que mais mensagens sejam enviadas para o servio de negcio aps processar aquelas que estavam na fila antes. Quando o valor reduzido, o OSB pe qualquer mensagem nova em uma fila at o valor definido para que a concorrncia fique abaixo do configurado, se estiver definido um valor para a fila (throttling queue). Caso no tenha definido um valor para a fila (throttling queue), a mensagem ser descartada. Em um ambiente de cluster, o nmero de mensagens que podem ser processadas concorrentemente pelos servios de negcio dividido igualmente entre os servidores gerenciados. Throttling queue: uma fila de prioridades na qual as mensagens so enquadradas quando um servio de negcio alcana seu nmero mximo de concorrncia. Mensagens com prioridade maior so processadas primeiro. Mensagens so processadas baseadas na regra First in First out. Somente uma fila pode ser configurada para um servio de negcio. Um throttling queue uma fila gravada na memria. Mensagens que so colocadas na fila no so recuperveis se o servidor falhar ou for reiniciado. Quando se apaga ou renomeia um servio de negcio, todas as mensagens no throttling queue so descartadas. O parmetro throttling queue restringe o nmero de mensagens na fila (throttling queue). O tamanho da fila deve ser um inteiro positivo. Todas as mensagens de chegada acima do mximo do limite de concorrncia para os servios de negcio so colocadas na fila (throttling queue). Quando a fila est cheia, a mensagem integrante da fila com o mais baixo valor de prioridade ser removida da fila e a nova mensagen que possui um nvel de prioridade maior ser inserida.
Se seu tamanho estiver configurado como zero, nenhuma fila ser criada para o servio de negcio. Qualquer mudana neste parmetro automaticamente aplicada. Quando se reduz o valor deste parmetro, todas as mensagens acima do novo valor so descartadas. Em um ambiente de Cluster, as mensagens so divididas igualmente entre os servidores gerenciados. Message Expiration: Restringe o tempo mximo (em milisegundos) em que uma mensagem pode permanecer na fila (throttling queue) de um servio de negcio. O valor para este parmetro deve ser um inteiro positivo. Quando o tempo configurado terminar, a mensagem removida da fila. Estas mensagens so referenciadas como mensagens expiradas. Se o parmetro configurado por zero, as mensagens na fila no iro expirar. Caso aumente o valor do parmetro configurado, o tempo de expirao para novas mensagens e para as mensagens que j esto presentes na fila sero aumentados. Caso reduza o valor do parmetro configurado, todas as mensagens que excedem o novo valor sero imediatamente descartadas. Aps configurar o Throttling, clique em Update e depois ative a seo (Figura 159).
Figura 159 Salvando a configurao do Throttling
4.6.2.7.1 Mtricas disponveis para Throttling Algumas mtricas so disponibilizadas ao habilitar a funo de Throttling. Elas p odem ser visualizadas na janela de detalhamento do monitoramento do servio que acessada indo em operations/dashboard/service health, e ento clicando no servio de negcio desejado (Figura 160 e Figura 161).
Figura 160 Acessando mtricas para Throttling
Figura 161 Mtricas do servio de negcio
4.6.2.8 Gerenciamento de Endpoint URI Um Endpoint URI uma URL de um servio externo que acessado pelo servio de negcio. No OSB, necessrio definir no mnimo um Endpoint URI para um servio de negcio. Quando se define mltiplos endpoints URI para um servio de negcio, necessrio configurar um algoritmo de balanceamento de carga entre as seguintes opes: Round robin", Random, Random-weighted ou none.
Os algoritmos de balanceamento controlam a forma na qual os servios de negcio acessaro os Endpoints URI. Um Endpoint URI pode permanecer online ou offline. O OSB permite configurar o nmero de tentativas de acesso a um Endpoint URI que se encontra offline. Para realizar essa configurao, siga os passos abaixo:
1.
Na janela de configurao do servio de negcio, clique em Edit (Figura 162).
Figura 162 Janela de configurao do servio de negcio 2.
Clique em Next na prxima janela (Figura 163).
Figura 163 Janela de configurao geral do Servio de negcio
3. Na opo Retry Count (Figura 164) deve-se especificar o nmero mximo de tentativas que o servio de negcio dever executar para acessar o Endpoint URI aps alguma falha inicial. Na opo Retry Iteration Interval, configure o intervalo, em segundos, entre as tentativas de acesso ao Endpoints URI. Nesta janela ainda possvel escolher um algoritmo de balanceamento de carga, selecionando uma opo em Load Balancing Algorithm. Caso deseje desabilitar as tentativas de chamada ao Endpoint URI em ca_______________________________________________________________________________________________ RelaTe-DIA: Estudos de Enterprise Service Bus e Oracle Service Bus 112
so de erro na aplicao, marque no na opo Retry Applications Errors. Ao finalizar a configurao, clique em Last e, na prxima janela, em Save. Ative a sesso para aplicar as configuraes.
Figura 164 Janela de edio da configurao do servio de negcio
Tambm possvel configurar Endpoints URI com o estado de offline permanentemente ou temporariamente em um servio de negcio. Um erro de comunicao ocorre cada vez que um servio de negcio tenta acessar um Endpoint URI que no responde. Configurando um Endpoint URI como offline, possvel prevenir que um servio de negcio continue tentando acess-lo caso ele no responda alguma vez e, por conseguinte, no emitir erros de comunicao. Para configurar um Endpoint URI como offline permanentemente ou termporariamente em um servio de negcio, siga os passos abaixo:
1.
Na janela de configuraes operacionais do servio de negcio (Figura 165), marque a opo Enable With Retry Intervale insira o intervalo de tempo. Quando esta opo selecionada, o servio de negcio remove os Endpoints URI que no respondem, colocando-os offline, em tempo de execuo, durante o intervalo tempo configurado. Para tornar os Endpoints permanentemente offline, configure o intervalo de tempo como 0 hora, 0 minuto e 0 segundo. Logo, somente as URIs que respondem so usadas para novas tentativas de acesso e para processamento das requisies subseqentes. Neste caso, para habilitar novamente as URIs marcadas como offline, necessrio fazer isso manualmente. Esta opo til quando se deseja verificar o motivo do Endpoint ficar offline por um tempo.
Figura 165 Janela de configuraes operacionais
4.7
Concluso
O monitoramento de servio do OSB oferece um conjunto de funcionalidades que permitem ao administrador configurar aes que emitem avisos sobre diversas variveis relativas s mensagens dos servios e a sade do servidor. Essas mensagens so programadas para serem emitidas caso ocorra algum evento que seja relevante no contexto dos fluxos de mensagens e no Acordo de Nvel de Servio (SLA). Isso permite ao administrador um acompanhamento detalhado do que ocorre no servidor, facilitando a tomada de deciso em tempo hbil. Ainda possvel configurar funcionalidades que executaro procedimentos automticos que iro corrigir problemas ou minimizar possveis impactos no sistema. O OSB fornece um conjunto de parmetros e estatsticas que demonstram detalhadamente o que ocorre no barramento. Cada chamada de servio pode ser rastreada e seus dados registrados em log para futuras anlises. Durante os testes a ferramenta realizou suas funcionalidades sem apresentar problemas, mostrando-se plenamente estvel e confivel.
Concluso
O Enterprise Service Bus (ESB) a principal infra-estrutura de uma Arquitetura Orientada a Servios. Hewit [2009] aponta que no existe um padro para ESB. No entanto, consenso entre os fornecedores de ferramentas quais so as responsabilidades de um
ESB, as quais incluem: prover conectividade; transformao de dados; roteamento de mensagens baseado em contedo; tratar segurana; tratar confiabilidade; gerncia de servios; monitoramente e log de servios; balanceamento de carga etc. Este relatrio apresentou os principais conceitos de ESB e analisou de forma prtica a implementao de ESB da Oracle, o Oracle Service Bus (OSB). As principais caractersticas da ferramenta foram apresentadas, sendo detalhada a arquitetura da ferramenta. A anlise prtica abordou as principais funcionalidades para implantao de um ESB em uma organizao focando na: Publicao de servios no barramento; Efeitos da evoluo de servios sobre o barramento e como este pode ser utilizado para tratar versionamento de servios; Uso do barramento para definio de fluxos (em servios de proxy) para tratar processos de negcio simples; Validao de tipos de dados definidos nas mensagens utilizando o barramento; Funcionalidades para monitoramento de servios no barramento.
Os resultados obtidos com nossos experimentos demonstraram que o OSB uma ferramenta que atende s caractersticas principais de um ESB no que concerne implantao de SOA em uma organizao.
6 Referncias
GAMMA, E., HELM, R., JOHNSON, R., VLISSIDES, J., Design Patterns: Elements of Reusable Object-Oriented Software, Addison-Wesley, 1994. GU, Q., LAGO, P., A stakeholder-driven Service Life Cycle Model for SOA, ACM, IW-SOSWE07, Dubrovnik, Crocia, 3 de setembro, 2007. Dsponvel em http://portal.acm.org/ft_gateway.cfm?id=1294930&type=pdf&coll=GUIDE&dl=GUI DE&CFID=80367577&CFTOKEN=59281546. Acesso em 10 Jul. 2008. HOHPE, G., WOOLF, B., Enterprise Integration Patterns: Designing, Building, and Deploying Messaging Solutions, Addison-Wesley, 2004. HEWITT, E., Java SOA Cookbook, OReilly, 2009. JOSUTTIS, N. M., SOA in practice: The Art of Distributed System Design. OReilly, 2007. OSB, Concepts and Architecture 10g Release 3 (10.3), 2008a. Disponvel em http://downloadllnw.oracle.com/docs/cd/E13159_01/osb/docs10gr3/concepts/index.html. Acesso em 14 Out. 2009. OSB, Operations Guide 10g Release 3 (10.3), 2008b. Disponvel em http://download.oracle.com/docs/cd/E13159_01/osb/docs10gr3/pdf/operations.pd f. Acesso em 18 Dez. 2009. OSB, Oracle Service Bus. 2009a. Disponvel em http://www.oracle.com/technology/products/integration/service-bus/index.html. Acesso em 12 Set. 2009.
OSB, Modelling message flow. 2009b. Disponvel em http://download.oracle.com/docs/cd/E13159_01/osb/docs10gr3/userguide/modeli ngmessageflow.html. Acesso em 12 Set. 2009b. OSB, XQuery mapper. 2009c. Disponvel em http://download.oracle.com/docs/cd/E13160_01/wli/docs10gr3/dtguide/index.ht ml. Acesso em 12 Set. 2009c OSB, Security. 2009d. Disponvel em http://downloadllnw.oracle.com/docs/cd/E13159_01/osb/docs10gr3/security/index.html. Acesso em 12 Set. 2009. OSB, User Guide. 2009e. Disponvel em http://download.oracle.com/docs/cd/E13159_01/osb/docs10gr3/userguide/index. html. Acesso em 30 Out. 2009. PAPAZOGLOU, MIKE P., HEUVEL, WILLEM-JAN, Service oriented architectures: approaches, technologies and research issues, VLDB Journal, Springer-Verlag, 2007 SOUZA, J., AZEVEDO, L., BAIAO, F., SANTORO, F. Estudo de ferramentas da BEA para SOA. Relatrios Tcnicos do DIA/UNIRIO (RelaTe-DIA), RT-0015/2009, 2009. Disponvel (tambm) em: http://seer.unirio.br/index.php/monografiasppgi.
Apndice 1 - Diferenas entre OSB e ALSB

Esta seo apresenta as diferenas observadas entre o ALSB e OSB de acordo com as funcionalidades avaliadas por Souza et al. [2009]. A publicao de servios no barramento compreende duas etapas. Em primeiro lugar, necessrio realizar o deploy das aplicaes no servidor de aplicao WLS (agora renomeado para Oracle WebLogic Server) e, em seguida, publicar as interfaces de servios (WSDL) no OSB. O primeiro passo necessrio, uma vez que o servio ser executado no mesmo OWLS em que est a sua interface. Observe que, no caso de uma aplicao distribuda, o deploy do servio (seu cdigo executvel) ser realizado em qualquer outro servidor de aplicao (JBoss, WebSphere, etc), e o WSDL do servio ser publicado no OSB. Neste trabalho estamos utilizando o OWLS e o OSB disponveis http://<IP ou local host>:7001/console e http://localhost:7021/sbconsole/, respectivamente, ou a partir dos links do menu Iniciar. WLS OWLS o Boto Lock & Edit Para realizar o deployment, necessrio entrar no console de administrao do OWLS (http://<IP do computador ou localhost>:7001/console/console.portal). Diferentemente do WLS no OWLS no existe mais o boto Lock & Edit. No entanto, aps iniciar o OWLS a partir do OSB, aparecem botes para ativar as mudanas (Activate e Undo changes). o Instalao de aplicao no OWLS O passo a passo para instalao de aplicao no OWLS o mesmo realizado no WLS exceto pelo fato de que aps o registro da aplicao, esta iniciada diretamente. Anteriormente, no WLS aps a publicao da apli_______________________________________________________________________________________________ RelaTe-DIA: Estudos de Enterprise Service Bus e Oracle Service Bus 116
cao esta ficava no estado Preparada para inicializao e era necess rio executar alguns passos para inicializ-la. ALSB OSB o o Assim como no ALSB, no OSB necessrio criar uma sesso para gerenciar o OSB, bem como ativ-la no final da realizao das alteraes. Em ambos os ambientes, os recursos (WSDL, XSD, etc) so agrupados por projetos, que podem ser visualizados no Project Explorer.
Apndice 2 - Elementos de um WSDL

Esta seo descreve os elementos de um WSDL [OSB, 2009e]. Um WSDL possui os elementos apresentados na Tabela 5.
Tabela 5 Elementos de um WSDL
Elemento <types> <message> <portType> <operation> <binding> <port> <service>
Descrio Definies de tipos para o contedo das mensagens. Definio abstrata do tipo de dados sendo transferido. Uma mensagem consiste de partes, as quais descrevem o contedo lgico e abstrato de uma mensagem. Coleo abstrata de operaes suportadas pelo servio. Descrio abstrata de uma ao suportada pelo servio Define o protocolo concreto e especificao do formato de dados para um <portType> Um endpoint simples, consistindo de endereo de rede e um binding. Coleo de portas ou endpoints.
Um exemplo de seo <types> do WSDL de um servio que prov cotas de aes, com os termos TradePriceRequest e TradePrice apresentado na Figura 166.
<types> <schema targetNamespace="http://example.com/stockquote.xsd" xmlns="http://www.w3.org/2001/XMLSchema"> <element name="TradePriceRequest"> <complexType> <all> <element name="tickerSymbol" type="string"/> </all> </complexType> </element> <element name="TradePrice"> <complexType> <all> <element name="price" type="float"/> </all> </complexType> </element> </schema> </types> Figura 166 Exemplo de seo types de um WSDL
Um exemplo de seo <message> apresentado na Figura 167, onde existem quatro tipos de mensagens (sellerInfoMessage, buyerInfoMessage, response, e negotiationMessage), cada uma tem uma ou mais partes.
<message name="sellerInfoMessage"> <part name="inventoryItem" type="xsd:string"/> <part name="askingPrice" type="xsd:integer"/> </message> <message name="buyerInfoMessage"> <part name="item" type="xsd:string"/> <part name="offer" type="xsd:integer"/> </message> <message name="response"> <part name="result" type="xsd:string"/> </message> <message name="negotiationMessage"> <part name="item" type="xsd:string"/> <part name="price" type="xsd:integer"/> <part name="outcome" type="xsd:string"/> </message> Figura 167 Exemplo de seo message de um WSDL
O elemento <portType> define um conjunto de operaes suportadas por um ou mais endpoints (os quais so definidos pelo elemento <port>). No padro WSDL 2.0, o nome do elemento (<portType>) foi alterado para <interface>. O tipo de porta prov a interface pblica para as operaes providas pelo servio. Cada operao definida em um elemento <operation>, onde cada uma uma descrio abstrata de uma ao suportada pelo servio. A Figura 168 apresenta um exemplo que define um tipo de porta com uma operao, GetLastTradePrice, a qual tem como entrada a mensagem GetLastTradePriceInput e como sada a mensagem GetLastTradePriceOuput. As descries concretas destas mensagens so definidas no binding WSDL, como demonstrado no subelemento <soap:operation> da Figura 169.
<portType name="StockQuotePortType"> <operation name="GetLastTradePrice"> <input message="tns:GetLastTradePriceInput"/> <output message="tns:GetLastTradePriceOutput"/> </operation> </portType> Figura 168 Exemplo de portType e operao do WSDL
A seo Binding (Figura 169) [Josuttis, 2007] onde a definio do servio passa da descrio abstrata para a concreta. Esta seo especifica detalhes de implementao de um servio definido de forma abstrata no portType, e composta da seguinte forma: 1) Transport: Protocolo de comunicao (HTTP ou SMTP Simple Mail Transport Protocol): protocolo para transportar as mensagens SOAP 2) Style: pode assumir os valores rpc ou document 3) Formato de dados: literal ou encoded. Encoded (segue regras de codificao segundo SOAP 1.1), e no est de acordo com o padro para web services. O atributo SoapAction usado para informar o propsito da requisio HTTP SOAP, seu valor uma URI, identificando a inteno. Ele pode ser usado por firewalls, para filtrar as requisies SOAP feitas usando HTTP. A Figura 169 apresenta um
exemplo de Binding para o tipo de porta StockQuotePortType, o qual provido pelo valor do atributo type. O subelemento <soap:binding> atrelado ao formato de protocolo SOAP. Neste subelemento, o atributo style especifica que o formato dados do estilo SOAP document, e o atributo transport especifica que o protocolo de transporte HTTP.
<binding name="StockQuoteSoapBinding" type="tns:StockQuotePortType"> <soap:binding style="document" transport="http://schemas.xmlsoap.org/soap/http"/> <operation name="GetLastTradePrice"> <soap:operation soapAction="http://example.com/GetLastTradePrice"/> <input> <soap:body use="literal"/> </input> <output> <soap:body use="literal"/> </output> </operation> </binding> Figura 169 Exemplo de elemento Binding do WSDL
A seo <service> especifica um ou mais endpoints na qual a funcionalidade do servio est disponvel. Tecnicamente seo <service> lista um ou mais ports. Cada port consiste de um portType (interface) e um binding (implementao), incluindo endereo fsico para acesso ao servio. A Figura 170 define duas portas, StockQuotePort e StockQuotePortUK. Ambos usam o mesmo binding, tns:StockQuoteSoapBinding, o que definido de forma concreta no atributo <binding>, mas tem endereos diferentes http://example.com/stockquote e http://example.uk/stockquote. Estas so portas alternativas para o servio.
<service name="StockQuoteService"> <port name="StockQuotePort" binding="tns:StockQuoteSoapBinding"> <soap:address location="http://example.com:9999/stockquote"/> </port> <port name="StockQuotePortUK" binding="tns:StockQuoteSoapBinding"> <soap:address location="http://example.uk:9999/stockquote"/> </port> </service> Figura 170 Exemplo de seo service do WSDL

965-7286-1-Pb - Estudo Oracle Service Bus Petrobras

Hochgeladen von

Dokumentinformationen

Originaltitel

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

965-7286-1-Pb - Estudo Oracle Service Bus Petrobras

Hochgeladen von

Copyright:

Verfügbare Formate

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

Departamento de Informtica Aplicada

Relatrios Tcnicos do DIA/UNIRIO, No. 0020/2010

Estudos de Enterprise Service Bus e Oracle Service Bus*

5 6 6 8 11 12 13 15 15 17 20 25 26 29 29 30 30 31 31 32 32 32 32 32 34 34 34 40 45 63 78 85 114 114 115 116 117

Apndice 1 - Diferenas entre OSB e ALSB Apndice 2 - Elementos de um WSDL

Figura 1 Enterprise Service Bus [OSB, 2008a]

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

2 Enterprise Service Bus

_______________________________________________________________________________________________ RelaTe-DIA: Estudos de Enterprise Service Bus e Oracle Service Bus 6

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

_______________________________________________________________________________________________ RelaTe-DIA: Estudos de Enterprise Service Bus e Oracle Service Bus 7

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

http://www.w3.org/TR/wsdl http://www.w3.org/TR/soap/ http://msdn.microsoft.com/en-us/library/aa395208.aspx

_______________________________________________________________________________________________ RelaTe-DIA: Estudos de Enterprise Service Bus e Oracle Service Bus 8

_______________________________________________________________________________________________ RelaTe-DIA: Estudos de Enterprise Service Bus e Oracle Service Bus 9

Figura 4 Exemplo de MEP Request-Response intermediado pelo ESB

Mediao e independncia de protocolo

_______________________________________________________________________________________________ RelaTe-DIA: Estudos de Enterprise Service Bus e Oracle Service Bus 10

_______________________________________________________________________________________________ RelaTe-DIA: Estudos de Enterprise Service Bus e Oracle Service Bus 11

_______________________________________________________________________________________________ RelaTe-DIA: Estudos de Enterprise Service Bus e Oracle Service Bus 12

ESBs comerciais e de cdigo aberto

3 Arquitetura do Oracle Service Bus

Sute de produtos do OSB

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

Figura 7 Produtos da Oracle separados em camadas

_______________________________________________________________________________________________ RelaTe-DIA: Estudos de Enterprise Service Bus e Oracle Service Bus 16

Negociao de servio Invocao de servio Monitorao de servio

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

Componentes da arquitetura do OSB

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

_______________________________________________________________________________________________ RelaTe-DIA: Estudos de Enterprise Service Bus e Oracle Service Bus 17

Figura 9 Camada de segurana

_______________________________________________________________________________________________ RelaTe-DIA: Estudos de Enterprise Service Bus e Oracle Service Bus 18

Figura 10 Camada de composio

_______________________________________________________________________________________________ RelaTe-DIA: Estudos de Enterprise Service Bus e Oracle Service Bus 19

Figura 11 Camada de gesto

Fluxo de mensagens via servios de proxy

_______________________________________________________________________________________________ RelaTe-DIA: Estudos de Enterprise Service Bus e Oracle Service Bus 20

Figura 12 Processamento de mensagens

Camada de ligao (binding layer): o o o

Servio de proxy (proxy service) o o

_______________________________________________________________________________________________ RelaTe-DIA: Estudos de Enterprise Service Bus e Oracle Service Bus 21

Figura 13 Camadas do fluxo de mensagens

_______________________________________________________________________________________________ RelaTe-DIA: Estudos de Enterprise Service Bus e Oracle Service Bus 23

_______________________________________________________________________________________________ RelaTe-DIA: Estudos de Enterprise Service Bus e Oracle Service Bus 24

Figura 14 Exemplo de fluxo de mensagem

WSDL efetivos e WSDL gerado

_______________________________________________________________________________________________ RelaTe-DIA: Estudos de Enterprise Service Bus e Oracle Service Bus 25

Web services com atributo style igual a SOAP document RPC

_______________________________________________________________________________________________ RelaTe-DIA: Estudos de Enterprise Service Bus e Oracle Service Bus 26

_______________________________________________________________________________________________ RelaTe-DIA: Estudos de Enterprise Service Bus e Oracle Service Bus 27

_______________________________________________________________________________________________ RelaTe-DIA: Estudos de Enterprise Service Bus e Oracle Service Bus 28

Padres de troca de mensagens

_______________________________________________________________________________________________ RelaTe-DIA: Estudos de Enterprise Service Bus e Oracle Service Bus 29

Transformao e processamento de mensagens

Disponibilizao de EJB como servio

_______________________________________________________________________________________________ RelaTe-DIA: Estudos de Enterprise Service Bus e Oracle Service Bus 30

3.10 Console de teste

3.11 Gesto de recursos

_______________________________________________________________________________________________ RelaTe-DIA: Estudos de Enterprise Service Bus e Oracle Service Bus 31