1-treinamento_WMB6

WebSphere Message Broker V6.0

; ; ; ;

Apresenta os conceitos de SOA e ESB Introduz o WebSphere Message Broker V6.0 Apresenta o WebSphere MQ V6.0 Demonstra exemplos práticos através de laboratórios

Treinamento Básico

Índice Capítulo 1: Introdução ............................................................................................................ 1 1.1 O escopo do treinamento.................................................................................................... 2 1.2 O público-alvo .....................................................................................................................3 1.3 Visão geral dos capítulos ....................................................................................................3 1.4 O que este treinamento não contempla ..............................................................................4 Capítulo 2: Introdução a SOA e ESB..................................................................................... 5 2.1 Visão geral da arquitetura orientada a serviços.................................................................. 6 2.1.1 Definição....................................................................................................................6 2.1.2 Ciclo de desenvolvimento SOA .................................................................................7 2.2 Enterprise Integration..........................................................................................................8 2.3 Enterprise Service Bus (ESB) .............................................................................................9 Capítulo 3: XML .....................................................................................................................13 3.1 XML................................................................................................................................... 14 3.1.1 Declaração XML ......................................................................................................15 3.1.2 Instrução de processamento ................................................................................... 15 3.1.3 Comentários ............................................................................................................16 3.1.4 Elementos................................................................................................................ 16 3.1.5 Atributos ..................................................................................................................16 3.1.6 Exemplo de composição .........................................................................................17 3.2 XML Namespace...............................................................................................................18 3.2.1 Definindo um Namespace Default ...........................................................................19 3.3 Tecnologias relacionadas ................................................................................................. 19 3.4 Document Type Definition (DTD) ......................................................................................20 3.5 XML Schema Definition (XSD).......................................................................................... 20 3.5.1 Simple Type............................................................................................................. 20 3.5.2 Complex Type .........................................................................................................22 3.6 XPath ................................................................................................................................ 22 3.6.1 Notação ...................................................................................................................22 3.6.2 Funções ...................................................................................................................23 3.7 XQuery .............................................................................................................................. 24 3.8 XML Transformations (XSLT) ...........................................................................................24 Capítulo 4: Visão geral da família WebSphere para SOA..................................................27 4.1 IBM WebSphere................................................................................................................ 28 4.1.1 Application Servers..................................................................................................28 4.1.2 Business Integration ................................................................................................ 29 4.1.3 Organizational Productivity, Portals and Collaboration............................................39 Capítulo 5: WebSphere MQ ..................................................................................................41 5.1 Conceitos de mensageria ................................................................................................. 42 5.1.1 Middleware .............................................................................................................. 42 5.1.2 Mensagens .............................................................................................................. 42 5.1.3 Filas .........................................................................................................................42 5.2 Objetos do WebSphere MQ ..............................................................................................44 5.2.1 Queue Manager....................................................................................................... 44 5.2.2 Fila ........................................................................................................................... 44 5.2.3 Canais .....................................................................................................................49

i

5.2.4 Mensagem ...............................................................................................................53 5.3 A interface de comandos WebSphere MQ Script (MQSC) ...............................................54 Capítulo 6: Trabalhando com WebSphere MQ ................................................................... 57 6.1 Ferramentas de administração .........................................................................................58 6.2 Privilégios de acesso ........................................................................................................58 6.3 Cenário do Laboratório .....................................................................................................58 6.4 Criação de objetos ............................................................................................................59 6.4.1 Preparação da Queue Manager QMGR1 ................................................................ 59 6.4.2 Preparação da Queue Manager QMGR2 ................................................................ 63 6.4.3 Comunicação entre Queue Managers.....................................................................64 Capítulo 7: WebSphere Message Broker ............................................................................71 7.1 Websphere Message Broker na integração de sistemas..................................................72 7.2 Websphere Message Broker............................................................................................. 72 7.2.1 Edições de Websphere Message Broker ................................................................ 73 7.2.2 Funcionalidades do Websphere Message Broker ................................................... 73 7.2.3 Componentes do Websphere Message Broker....................................................... 74 7.3 WebSphere Message Broker como ESB .......................................................................... 77 7.3.1 Virtualização de serviço...........................................................................................77 7.3.2 Suporte e conversão de protocolo de transporte ....................................................78 7.3.3 Modelagem de mensagem e transformação ...........................................................82 7.3.4 Roteamento dinâmico..............................................................................................89 7.3.5 Estendendo as funcionalidades...............................................................................90 7.3.6 Padrões de interação ..............................................................................................91 7.3.7 Integração com outros Enterprise Information Systems (EIS).................................92 7.3.8 Suporte a Quality of service (QoS) .......................................................................... 93 7.3.9 Acesso ao registro de serviços................................................................................ 93 7.3.10 Facilidade de administração ..................................................................................93 7.4 Suporte a Web Services ................................................................................................... 95 7.4.1 Escolhendo o message domain para SOAP ...........................................................95 Capítulo 8: Instalação ...........................................................................................................99 8.1 Planejamento para a instalação......................................................................................100 8.1.1 Softwares obrigatórios ........................................................................................... 100 8.1.2 Softwares opcionais .............................................................................................. 101 8.1.3 Requisitos de software ..........................................................................................101 8.2 Questões de segurança .................................................................................................. 103 8.2.1 User ID .................................................................................................................. 103 8.2.2 Outras questões de segurança .............................................................................103 8.3 Instalando os softwares obrigatórios............................................................................... 105 8.3.1 O Launchpad .........................................................................................................105 8.3.2 Instalando o produto via Express Installation ........................................................ 105 8.4 Tarefas pós-instalação....................................................................................................107 8.4.1 Serviço WebSphere MQ ........................................................................................ 107 8.4.2 DB2 Universal Database .......................................................................................107 8.5 Verificando a instalação .................................................................................................. 108 8.5.1 Criando uma configuração default.........................................................................108 8.5.2 Executando os exemplos ......................................................................................109 8.6 Message Brokers Toolkit................................................................................................. 110 8.6.1 Navegando no Message Brokers Toolkit...............................................................110 8.7 Instalando fix packs.........................................................................................................112 8.7.1 Antes de instalar ....................................................................................................112 8.7.2 Atualizações para componentes runtime .............................................................. 112

ii

8.7.3 Atualizações para o Message Brokers Toolkit....................................................... 112 Capítulo 9: Message Flows ................................................................................................115 9.1 Visão geral do message flow ..........................................................................................116 9.1.1 O fluido .................................................................................................................. 116 9.1.2 Construindo um message flow .............................................................................. 119 9.2 Cenário do laboratório..................................................................................................... 121 9.3 Verificação e preparação do ambiente ........................................................................... 122 9.3.1 Verificação do serviço de frete .............................................................................. 122 9.3.2 Verificação do serviço Serasa ............................................................................... 123 9.3.3 Verificação do serviço de cadastro........................................................................ 124 9.4 Preparação do ambiente de desenvolvimento................................................................126 9.4.1 Criação de um Workspace ....................................................................................126 9.4.2 Conexão à Configuration Manager de um Broker Domain.................................... 127 9.4.3 Criando um Execution Group ................................................................................128 9.4.4 Criando um Message Flow Project........................................................................ 129 9.4.5 Criando um Message Set Project ..........................................................................130 9.4.6 Importação do projeto auxiliar ............................................................................... 131 Capítulo 10: Controle de transações................................................................................. 133 10.1 Transações ...................................................................................................................134 10.1.1 Transação em message flows .............................................................................134 10.1.2 Princípios de tratamento de erros .......................................................................135 Capítulo 11: Web Services ................................................................................................. 137 11.1 Implementação.............................................................................................................. 138 11.1.1 Modelagem da mensagem de entrada ................................................................138 11.1.2 Importando a definição do SOAP Envelope ........................................................ 141 11.1.3 Criação do Broker Schema ................................................................................. 142 11.1.4 Configurando o message flow .............................................................................144 11.1.5 Adição de mais uma interface de entrada ........................................................... 149 11.2 Deploy ........................................................................................................................... 151 11.3 Teste .............................................................................................................................154 11.3.1 Teste da interface HTTP ..................................................................................... 154 11.3.2 Teste da interface WebSphere MQ ..................................................................... 154 Capítulo 12: Troubleshooting ............................................................................................157 12.1 Logs .............................................................................................................................. 158 12.1.1 Troubleshooting administrativos e de runtime ..................................................... 158 12.1.2 Troubleshooting de desenvolvimento .................................................................. 159 12.1.3 Troubleshooting de deploy .................................................................................. 161 12.2 Trace Node ...................................................................................................................161 12.3 Flow Debugger.............................................................................................................. 162 12.3.1 Debugando um JavaComputeNode .................................................................... 164

iii

Figuras 2-1 Termologia SOA .................................................................................................................6 2-2 Ciclo SOA ...........................................................................................................................7 2-3 Cenário de uma empresa real ............................................................................................ 8 2-4 Integração com conexões ponto-a-ponto ...........................................................................9 2-5 Integração utilizando um ESB.............................................................................................9 2-6 Enterprise Service Bus .....................................................................................................10 3-1 Exemplo de um XML simples com declaração XML......................................................... 15 3-2 Exemplo de um XML simples com instrução de processamento .....................................15 3-3 Exemplo de um XML simples com comentários ...............................................................16 3-4 Exemplo de um XML simples com elementos ..................................................................16 3-5 Exemplo de um XML simples com atributos.....................................................................16 3-6 Trecho de um XML que representa uma imagem vetorial................................................ 17 3-7 XML de exemplo de chamada de um WebService...........................................................18 3-8 XML com Namespace Default .......................................................................................... 19 3-9 XML e tecnologias relacionadas ....................................................................................... 19 3-10 Hierarquia de simple types pré-definidos no XML Schema ............................................21 3-11 Simple Type que define um tipo para um nome de fila MQ............................................21 3-12 XML exemplo ..................................................................................................................22 3-13 Exemplo de XQuery........................................................................................................24 3-14 Utilização do XML Transformations (XSLT).................................................................... 25 4-1 Componentes do WebSphere Process Server .................................................................34 5-1 Resolução de filas............................................................................................................. 45 5-2 Configuração típica de message channel.........................................................................50 5-3 O que ocorre quando uma mensagem não pode ser entregue ........................................52 6-1 Cenário de implementação do laboratório WebSphere MQ ............................................. 59 6-2 Criação de Queue Manager pelo MQ Explorer.................................................................59 6-3 Passo 2 de criação da Queue Manager ...........................................................................60 6-4 Passo 3 da criação da Queue Manager ...........................................................................60 6-5 Passo 4 da criação da Queue Manager ...........................................................................61 6-6 Passo 5 da criação da Queue Manager ...........................................................................61 6-7 Criando uma fila local pelo MQ Explorer .......................................................................... 62 6-8 Testando a fila com o MQ Explorer ..................................................................................62 6-9 Indicação dos atributos das filas no MQ Explorer............................................................. 62 6-10 Verificação dos status das Queue Managers .................................................................63 6-11 Acesso à interface MQSC...............................................................................................63 6-12 Criação de uma fila de transmissão pelo MQ Explorer................................................... 64 6-13 Configurando a fila para ser uma fila de transmissão.....................................................65 6-14 Criando um listener pelo MQ Explorer............................................................................66 6-15 Configuração do novo listener ........................................................................................66 6-16 Criação de canais no MQ Explorer ................................................................................. 67 6-17 Configurações de Sender Channel para QMGR1 .......................................................... 67 6-18 Configurações de Receiver Channel para QMGR1........................................................68 6-19 Inicialização do canal Sender na Queue Manager ......................................................... 68 7-1 Arquitetura dos componentes runtime ..............................................................................76 7-2 Paletas com Nodes MQ no WebSphere Message Broker Toolkit 6.0.2 ...........................78 7-3 Paletas com Nodes MQe no WebSphere Message Broker Toolkit 6.0.2 ......................... 78 7-4 Paletas com Nodes Multicast no WebSphere Message Broker Toolkit 6.0.2................... 79 7-5 Paletas com Nodes Real-time no WebSphere Message Broker Toolkit 6.0.2..................79 7-6 Paletas com Nodes de telemetria no WebSphere Message Broker Toolkit 6.0.2 ............ 79 7-7 Paletas com Nodes HTTP no WebSphere Message Broker Toolkit 6.0.2........................80

iv

7-8 Paletas com Nodes JMS no WebSphere Message Broker Toolkit 6.0.2.......................... 80 7-9 Representação da árvore lógica de mensagem JMS ....................................................... 81 7-10 Mapeamento entre mensagem JMS e mensagem MQ ..................................................81 7-11 Modelagem de mensagem e transformaçao ..................................................................82 7-12 Modelagem de mensageem no WebSphere Message Broker ....................................... 83 7-13 Representação do Validate Node no Toolkit ..................................................................84 7-14 Representação do Compute Node no Toolkit.................................................................85 7-15 Código ESQL default criado para um determinado Compute Node ...............................86 7-16 Representação do Java Compute Node no Toolkit ........................................................86 7-17 Exemplo de código de um Java Compute Node............................................................. 87 7-18 Representação do Mapping Node no Toolkit..................................................................87 7-19 Editor de mapeamentos do Mapping Node .................................................................... 88 7-20 Representação do XML Transformation Node no Toolkit...............................................88 7-21 Funcionamento do XML Transformation Node ...............................................................88 7-22 Trecho de código: usando uma variável compartilhada .................................................89 7-23 Representação do Filter Node no Toolkit ....................................................................... 89 7-24 Representação do Flow Order Node no Toolkit..............................................................89 7-25 Representação do Label Node no Toolkit....................................................................... 90 7-26 Representação do Route To Label Node no Toolkit....................................................... 90 7-27 Nodes relacionados com QSAM datasets ...................................................................... 90 7-28 Nodes relacionados com VSAM datasets....................................................................... 90 7-29 Nodes de agregação....................................................................................................... 92 7-30 Message Broker Toolkit ..................................................................................................94 7-31 Exemplo de mensagem MIME........................................................................................96 7-32 Árvore lógica criada pelo MIME parser...........................................................................97 8-1 O Launchpad durante o Express Installation .................................................................. 106 8-2 ícone que mostra o estado de execução do WebSphere MQ ........................................ 107 8-3 Ícone que mostra o estado de execução do DB2 Universal Database........................... 107 8-4 Ícone “Getting started” da tela de Welcome ...................................................................108 8-5 Ícone do Default Configuration wizard ............................................................................109 8-6 Ícone “Run Pager Samples“............................................................................................109 8-7 Perspectiva de desenvolvimento ....................................................................................110 8-8 Ícone “Open Perspective“ (ícone esquerdo) ...................................................................111 8-9 Criação automática do link para a perspectiva ...............................................................111 8-10 Instalando atualizações para o Message Brokers Toolkit.............................................113 9-1 Exemplo de message flow .............................................................................................. 116 9-2 Local Environment: estrutura da árvore lógica ...............................................................116 9-3 Environment: exemplo de utilização ............................................................................... 117 9-4 Exception List: Estrutura da árvore lógica ......................................................................117 9-5 Root: exemplo de estrutura de uma mensagem MQ ......................................................119 9-6 Sistemas envolvidos em uma fábrica de automóveis imaginária ...................................121 9-7 Barra “Quick Launch” com XMLSpy ............................................................................... 122 9-8 XML de requisição à operação calcularFrete do WebService ........................................ 122 9-9 Resposta do WebService à operação calcularFrete....................................................... 123 9-10 Barra “Quick Launch” com XMLSpy .............................................................................123 9-11 XML de requisição à operação consultarEmpresa do WebService.............................. 123 9-12 Resposta do WebService à operação consultarEmpresa ............................................124 9-13 Barra “Quick Launch” com RFHUtil .............................................................................. 124 9-14 Configuração do RFHUtil para teste do serviço de cadastro de cliente ....................... 124 9-15 Verificando a leitura do arquivo no RFHUtil.................................................................. 125 9-16 Lendo a resposta do simulador através do RFHUtil ..................................................... 126 9-17 Iniciando o Message Brokers Toolkit c/ a workspace criada ........................................ 127 9-18 Conexão à Configuration Manager ............................................................................... 127 9-19 Conexão com a Configuration Manager .......................................................................128

v

9-20 Criação de um novo execution group ........................................................................... 129 9-21 Criação de um novo Message Flow Project ................................................................. 129 9-22 Criação de um novo Message Set Project.................................................................... 130 9-23 Criação de um novo message set (continuação)..........................................................131 11-1 Mensagem XML de entrada a ser modelada................................................................138 11-2 Criando um novo message definition file ......................................................................138 11-3 Criando um novo message definition file (continuação) ...............................................139 11-4 Adição de mensagem no message definition file..........................................................139 11-5 Renomeando um complexType ....................................................................................140 11-6 Adicionando um elemento numa mensagem................................................................140 11-7 Configurando o tipo do elemento idProduto ................................................................. 141 11-8 Mensagem consultarEstoque envelopada no SOAP Envelope.................................... 141 11-9 Importação da modelagem da mensagem SOAP ........................................................ 142 11-10 Criação de um Broker Schema...................................................................................143 11-11 Criação de um message flow em um determinado Broker Schema........................... 143 11-12 Configuração final do message flow EstoqueWS ....................................................... 144 11-13 Adição e configuração do HTTPInput Node ...............................................................145 11-14 Verificação do messageSet Id ....................................................................................146 11-15 Código default criado para o Compute Node.............................................................. 148 11-16 Configuração com os nodes adicionados ...................................................................149 11-17 Verificando as conexões entre Nodes ........................................................................ 149 11-18 Adição da interface WebSphere MQ ..........................................................................150 11-19 Conexão à Configuration Manager .............................................................................151 11-20 Criação de um Broker Archive (BAR) .........................................................................151 11-21 Adicionando artefatos ao Broker Archive (BAR).........................................................152 11-22 Artefatos adicionados ao Broker Archive (BAR) .........................................................152 11-23 Event Log da Configuration Manager .........................................................................153 11-24 Testando o message flow EstoqueWS no NetTool .................................................... 154 11-25 Testando a interface MQ do message flow EstoqueWS ............................................155 11-26 Verificação da mensagem de resposta.......................................................................155 12-1 View “Problem“ na perspectiva de desenvolvimento .................................................... 159 12-2 View “Tasks“ na perspectiva de desenvolvimento........................................................ 160 12-3 View “Alerts“ na perspectiva de administração.............................................................160 12-4 Event Log da Configuration Manager ........................................................................... 161 12-5 Exemplo de saída de um Trace Node ..........................................................................162 12-6 Debug de um message flow .........................................................................................162 12-7 Análise do conteúdo da mensagem através do Flow Debugger ..................................163 12-8 Comunicação com o RAC (Rational Agent Controller) ................................................. 164 12-9 Configuração do debug para Java................................................................................165 12-10 Adição do projeto Java para debug ............................................................................165

vi

Considerações Legais Este treinamento foi totalmente desenvolvido pela Intvision Solutions Ltda. Todo o material gerado não é oficial e tampouco endossado pela IBM. Para a sua elaboração a Intvision Solutions Ltda baseou-se em manuais e artigos oficiais dos produtos envolvidos e na experiência técnica de seus colaboradores. Esta apostila pode conter informações técnicas imprecisas e/ou erros de tipografia. Devido a isto, a Intvision poderá lançar versões futuras com correções a qualquer tempo e sem nenhum aviso prévio. Caso seja de seu interesse receber estas atualizações por favor consulte a Intvision. O ambiente de treinamento é fornecido na forma de máquina virtual VMWare e deverá ser utilizado apenas durante o treinamento, para fins educativos. É vedado a utilização e cópia, parcial ou integral, deste ambiente para fins comerciais. Os softwares não-IBM utilizados durante o treinamento são apresentados apenas por conveniência. A Intvision Solutions Ltda. não fornece qualquer tipo de licença de software para utilização destes. A Intvision Solutions Ltda. não se responsabilizará por qualquer dano causado pelo uso indevido de seu material. A cópia e/ou distribuição dos materiais deste treinamento sem autorização da Intvision Solutions Ltda. é expressamente proibida.

vii

1

Chapter 1.

Introdução Este capítulo provê uma visão geral do escopo deste treinamento. Este capítulo descreve: 򐂰 O escopo deste treinamento 򐂰 O público-alvo 򐂰 Visão geral dos capítulos 򐂰 O que este treinamento não comtempla

© Copyright Intvision Solutions 2007. All rights reserved.

1

1.1 O escopo do treinamento O objetivo deste treinamento é apresentar os conceitos e funcionalidades básicas do Websphere Message Broker para novos usuários. Os seguintes produtos serão apresentados: 򐂰 Websphere Message Broker 򐂰 Websphere Event Broker 6.0 O Websphere Event Broker 6.0 contém um subconjunto das funcionalidades disponíveis no Websphere Message Broker. Este treinamento terá foco no Websphere Message Broker. Este treinamento provê informações básicas para possibilitar a instalação e configuração do produto, desenvolvimento e deploy de soluções simples. Além disso habilita o usuário a completar tarefas administrativas comuns. O treinamento demonstra como criar passo-a-passo os componentes e desenvolver fluxos e message sets simples que demontram as capacidades do produto . Também serão apresentados os métodos de obtenção de dados diagnósticos para resolução de problemas. O ambiente utilizado no treinamento é baseado no Microsoft Windows. No entanto as informações tratadas aqui podem ser utilizadas em outras configurações como por exemplo em ambiente Linux.

2

WebSphere Message Broker 6.0 - Treinamento Básico

1.2 O público-alvo Este treinamento é direcionado aos novos usuários do Websphere Message Broker fazendo com que estes comecem a utilizá-lo o mais rápido possível. Este treinamento também é indicado para usuários de versões anteriores que não estão familiarizados com o novo Message Broker Toolkit.

1.3 Visão geral dos capítulos Capítulo 2, “Introdução a SOA e ESB” na página 5 Apresentamos o conceito SOA, suas características e o papel do ESB neste cenário. Capítulo 3, “XML” na página 13 Este capítulo apresenta os conceitos do eXtensible Markup Language (XML) e as tecnologias relacionadas. É um capítulo essencial para o entendimento do produto. Capítulo 4, “Visão geral da família WebSphere para SOA” na página 27 Este capítulo aborda os principais produtos da família WebSphere utilizados para implantação da arquitetura SOA. Capítulo 5, “WebSphere MQ” na página 41 Este capítulo apresenta conceitos de mensageria e o produto WebSphere MQ. Capítulo 6, “Trabalhando com WebSphere MQ” na página 57 Teremos um primeiro contato com o WebSphere MQ neste capítulo. Capítulo 7, “WebSphere Message Broker” na página 71 Este capítulo mostra como o WebSphere Message Broker atua no cenário SOA e como ele implementa as funções de um ESB. Capítulo 8, “Instalação” na página 99 Este capítulo comtempla a instalação e configuração do produto para obter um ambiente pronto para uso. Capítulo 9, “Message Flows” na página 115 Neste capítulo apresentamos o componente principal do WebSphere Message Broker: o message flow. Veremos como iniciar seu projeto dentro da ferramenta de desenvolvimento. Capítulo 10, “Controle de transações” na página 133 Este capítulo explica quais são os procedimentos necessários para o controle de transações. Capítulo 11, “Web Services” na página 137 Este capítulo demonstra o uso do Web Services em um message flow. Capítulo 12, “Troubleshooting” na página 157 Este capítulo analisa os métodos de troubleshooting para busca de informações de status. Chapter 1. Introdução

3

1.4 O que este treinamento não contempla Este treinamento não contempla etapas de migração de versões anteriores (2.1,5.0 e 5.1). Devido ao seu caráter introdutório os códigos e exemplos apresentados não deverão servir de base nas soluções de Produção. Não são apresentadas as best-practices de desenvolvimento, nem tampouco padrões ou métodos de obtenção de performance. Este treinamento será realizado em ambiente Windows e as características particulares de outros sistemas operacionais não serão apresentadas.

4

WebSphere Message Broker 6.0 - Treinamento Básico

2

Chapter 2.

Introdução a SOA e ESB Este capítulo visa apresentar as características fundamentais da arquitetura orientada a serviços (SOA).

© Copyright Intvision Solutions 2007. All rights reserved.

2.1 Visão geral da arquitetura orientada a serviços 2.1.1 Definição SOA (Service-Oriented Architecture ou Arquitetura Orientada a Serviços) é uma arquitetura de software, baseada em serviços, com foco nos processos de negócios. Suas principais características são: padrões abertos, desacoplamento e o re-uso. SOA não é uma tecnologia e sim um conceito. O grande benefício de SOA é o reuso e flexibilidade dos processos de negócios de uma empresa. Podemos resumir SOA da seguinte maneira: Dividir um processo de negócios em serviços reutilizáveis, mesmo se estes se estenderem aos aplicativos. Surgirão novos componentes (da empresa ou de parceiros de negócios) e depois juntar os novos e os antigos serviços para criar um novo processo de negócios. A Arquitetura Orientada a Serviços é uma abordagem que pode orientar melhor o serviço da sua empresa, tornando o seu atendimento mais ágil e responsivo. Dentro de uma arquitetura orientada a serviços, aplicativos, informações e outros recursos de TI são vistos como serviços ou "blocos de construção". Cada um desses serviços podem ser misturados e combinados para criar novos e flexíveis processos de negócios. Esta arquitetura é criada para fornecer flexibilidade para tratar elementos de processos de negócios e a infra-estrutura fundamental de TI como serviços que podem ser reutilizados e combinados para atender às prioridades de mudanças de negócios. Fornecendo uma ligação entre TI e processos de negócios, uma arquitetura orientada a serviços pode ajudar a aumentar a flexibilidade de negócios e a capacidade da empresa em cumprir as metas de negócios com mais rapidez, facilidade e economia.

Figure 2-1 Termologia SOA

򐂰 Serviço é a representação de uma tarefa de negócio repetitiva. Serviços são usados para encapsular as funções de uma aplicação provendo uma interface independente. Os serviços podem ser invocados por outros serviços ou aplicações. 򐂰 Orientação a serviços é a definição de métodos de integrações de aplicações e processos de negócios, conectados como serviços. 򐂰 Arquitetura Orientada a Serviços (SOA) pode ter diferentes contextos para as pessoas dentro de uma organização, dependendo das suas funções (negócio, arquitetura, implementação, operação, etc.).

6

WebSphere Message Broker 6.0 - Treinamento Básico

– Da perspectiva de negócios, SOA define um conjunto de serviços de negócios compostos para capturar o as regras de negócios e diretrizes que a empresa quer expor internamente e também para seus parceiros, clientes e fornecedores. – Da perspectiva de arquitetura, SOA é um estilo de arquitetura de aplicações, baseada em serviços. – Da perspectiva de implementação, SOA é uma infra-estrutura baseada em modelos, padrões abertos e tecnologias, como Web Services. – Da perspectiva operacional, SOA inclui um conjunto de ligações entre consumidores e provedores, além de prover a qualidade de serviço e métricas de negócios. 򐂰 Aplicativos Compostos são conjuntos de serviços relacionados e integrados para suportar um processo de negócio dentro de SOA. Aplicativos e arquiteturas baseados em SOA, além de mudar a ligação entre TI e negócios também mudam a maneira de como construir aplicações, conforme o quadro a seguir: Table 2-1 DE

PARA

Orientado a função

Orientado a processos

Construído para durar

Construído para mudar

Longos ciclos de desenvolvimento

Desenvolvido e implementado de forma incremental

Silos de aplicação

Soluções orquestradas

Aplicações estruturadas utilizando componentes

Aplicações estruturadas utilizando serviços

Implementação conhecida

Abstração da implementação

2.1.2 Ciclo de desenvolvimento SOA Para a adoção de SOA e BPM, é importante construir os processos de negócios de maneira interativa e incremental. A figura abaixo demonstra as fases e interações.

Figure 2-2 Ciclo SOA

򐂰 Modelagem (model): O início de um projeto começa pela modelagem de negócios, recolhendo e analisando as exigências deste para simular e otimizar os processos. Esta

Chapter 2. Introdução a SOA e ESB

7

informação pode estabelecer uma compreensão comum dos processos de negócios entre TI e o negócio, assegurando que o resultado da aplicação definida pelo negócio alcance os seus objetivos e resultados. 򐂰 Construção (assemble): Nesta fase, os serviços são criados ou utilizados. Com os serviços prontos, é possível iniciar a orquestração e execução destes para executar os processos de negócios já modelados. 򐂰 Implantação (deploy): Na fase de implantação, o ambiente “run-time” é configurado e escalado, para encontrar os melhores índices para os serviços. Assim, é possível implementar os serviços e processos em um ambiente robusto, escalável e altamente seguro para que este funcione com confiabilidade para os processos que ele é requisitado, fornecendo a flexibilidade de alterar os processos dinamicamente em resposta as mudanças do negócio. 򐂰 Gerenciamento (manage): Na fase de gerenciamento é estabelecida e mantida a disponibilidade e a resposta dos serviços e processos de negócio. Para monitorar, pode-se utiliza KPIs para ter um monitoramento “on-line”, isolando e diagnosticando cada etapa de um processo. Nesta fase, permite-se fazer decisões de negócio para verificar e melhorar os processos.

2.2 Enterprise Integration Em geral, as tecnologias acumuladas dentro de uma empresa trazem diversos cenários, com diferentes sistemas operacionais, protocolos de comunicação, plataformas de aplicativos, formatos de dados, etc.

Figure 2-3 Cenário de uma empresa real

Para fazer a integração entre os diversos cenários, quando não se tem um centralizador para as integrações, as empresas são obrigadas a fazer as integrações de maneira ponto a ponto entre as aplicações. Este tipo de arquitetura traz muitas dificuldades de manutenção de código, conexões diversas, gerenciamento complexo, regras de integração dentro das aplicações entre outras características.

8

WebSphere Message Broker 6.0 - Treinamento Básico

Para solucionar este problema, no passado foi criado o conceito de EAI (Enterprise Application Integration). Este conceito tornava as integrações entre os aplicativos, antes ponto a ponto, de uma maneira centralizada, facilitando a transformação de protocolos e formatos, substituição de sistemas, entre outras características.

Figure 2-4 Integração com conexões ponto-a-ponto

Porem novos requisitos foram estabelecidos para as integrações dentro de uma empresa. Na época do EAI, pensava-se somente em integração de aplicações. Hoje os requisitos de integração são maiores: Pessoas, Processos e Aplicações. Com a adição de Pessoas e Processos no escopo, o conceito de serviços tornou-se muito forte para o reuso e o desacoplamento. Os aplicativos com função de EAI tornaram-se obsoletos para tal tarefa e uma reengenharia deste padrão foi necessária. Nesta nova fase, foi criado o conceito de ESB (Enterprise Service Bus), ou seja, aproveitando o conceito do EAI onde há um centralizador de integrações de aplicativos, porem com funções estendidas, como Web Services.

Figure 2-5 Integração utilizando um ESB

2.3 Enterprise Service Bus (ESB) Para implementar uma arquitetura que suporte o SOA e outros paradigmas de integração, é necessário um ambiente sofisticado, com uma infra-estrutura gerenciável e que suporte várias interações. Este ambiente deve suportar vários estilos de integrações existentes. O conceito de Enterprise Service Bus é descrito como a nova arquitetura para explorar Web Services, Messaging Middleware, Roteamento e Transformação de dados. Para fazer uma implementação de um serviço com SOA, ambas as aplicações e infra-estruturas devem suportar os seus princípios básicos. O ESB simplifica a infra-estrutura para rotear e transportar as requisições para o serviço correto. Chapter 2. Introdução a SOA e ESB

9

O grande valor do ESB é habilitar a infra-estrutura para o SOA prover uma suíte de níveis de serviços e gerenciamento possibilitando a operação e integração em ambientes heterogêneos. O ESB também habilita a substituição da implementação de um serviço por outro sem afetar os sistemas que se conectam a ele. O ESB suporta os três principais paradigmas de integração: 򐂰 Service-oriented architectures: Onde as aplicações se comunicam através de serviços reutilizáveis; 򐂰 Message driven architectures: Onde as aplicações enviam e recebem mensagens através do ESB; 򐂰 Event driven architectures: Onde as aplicações geram e consomem mensagens independentemente.

Figure 2-6 Enterprise Service Bus

O ESB deve ser capaz de disponibilizar as seguintes capacidades: Table 2-2 Capacidades de um ESB Capacidade

Detalhe

Comunicação

򐂰 Roteamento 򐂰 Endereçamento 򐂰 Protocolo e Padrões (HTTP, HTTPS, etc.) 򐂰 Publish / Subscribe 򐂰 Response / Request 򐂰 Eventos, Fire & Forget 򐂰 Mensagens Síncronas e Assíncronas

10

WebSphere Message Broker 6.0 - Treinamento Básico

Capacidade

Detalhe

Interação de Serviços

򐂰 Interface de definição de serviços (WSDL) 򐂰 Substituição da implementação do serviço 򐂰 Modelos de serviços de mensagens requeridos para comunicação e integração (SOAP, XML, modelos proprietários, etc.) 򐂰 Serviço de diretório e procura

Integração

򐂰 Banco de Dados 򐂰 Legados e Adapters de Aplicação 򐂰 Conectividade com EAI 򐂰 Serviço de mapeamento 򐂰 Protocolo de transformação 򐂰 Enriquecimento/Agregação de dados 򐂰 Ambientes com Servidos de Aplicação (Application Server) 򐂰 Interface com linguagens de programação (Java, C, C++, etc.)

Qualidade de Serviço

򐂰 Transações (Two Fase Commit, Compensation, WS-Transaction) 򐂰 Vários paradigmas de garantia de entrega dos dados (Message Queuing, WS-ReliableMessaging, etc.)

Segurança

򐂰 Autenticação 򐂰 Autorização 򐂰 Não repudiação 򐂰 Confidenciabilidade 򐂰 Standards de segurança (Kerberos, WS-Security)

Nível de Serviço

򐂰 Performance 򐂰 Multi-Processamento 򐂰 Escalabilidade 򐂰 Alta disponibilidade 򐂰 Outras medidas e meios de continuidade e melhoria dos serviços

Chapter 2. Introdução a SOA e ESB

11

Capacidade

Detalhe

Processamento de Mensagens

򐂰 Encoded lógico 򐂰 Lógica baseada no conteúdo 򐂰 Transformação de dados 򐂰 Agregação e correlação 򐂰 Validação 򐂰 Intermediação 򐂰 Identificação de mapeamento dinâmica 򐂰 Armazenamento e encaminhamento

Infra Estrutura inteligente

򐂰 Regras de negócios 򐂰 Política de vários níveis de serviços, segurança, qualidade e capacidades (WS-Policy) 򐂰 Reconhecimento de parceiros; 򐂰 Gerenciamento e Automação 򐂰 Capacidade de Administração 򐂰 Serviço de provisionamento e registro 򐂰 Log com vários níveis 򐂰 Métricas 򐂰 Monitoração 򐂰 Integração com sistemas de gerenciamento e ferramentas de administração 򐂰 Auto monitoração e autogerenciamento

Modelagem

򐂰 Modelagem de objetos 򐂰 Modelos de objetos de negócios comuns 򐂰 Bibliotecas de formatos de dados 򐂰 Modelos públicos X privados para integração B2B 򐂰 Ferramentas de desenvolvimento e implantação

12

WebSphere Message Broker 6.0 - Treinamento Básico

3

Chapter 3.

XML Este capítulo provê uma visão geral sobre o XML e tecnologias relacionadas.

© Copyright Intvision Solutions 2007. All rights reserved.

3.1 XML O XML (eXtensible Markup Language) é uma recomendação da W3C para gerar linguagens de marcação para necessidades especiais. Na prática é uma linguagem para representação de dados para diversas necessidades. Explicando-se pelo significado da sigla, o XML é: 򐂰 Extensível: devido à natureza da sua estrutura, fica fácil estendê-lo e adaptá-lo para novas finalidades. 򐂰 Markup: os dados são envoltos em marcadores(markup), também chamados de tags. Não existe um conjunto fixo de tags, portanto você está livre para criar as suas próprias tags. 򐂰 Language: uma linguagem é definida por uma gramática. No caso do XML é estabelecido uma gramática rígida para entendimento preciso do conteúdo dos dados. O XML oferece uma tentadora possibilidade de formato de dados duradouro e cross-platform. Já é de praxe o caso de documentos escritos em uma plataforma não serem necessariamente legíveis num outra plataforma, ou por uma aplicação diferente na mesma plataforma. Quando o documento era lido, não havia a garantia de que todas as informações chegariam. Por exemplo, muitos dados do pouso lunar da década de 60 e 70 foram perdidos para sempre. Isto porque mesmo que alguém consiga ler os dados das fitas da época, ninguém saberia dizer em qual formato os dados foram armazenados nestas fitas! No XML todos os dados são texto e codificados em UTF-8 por default. Isto significa que o XML pode ser lido e editado em qualquer editor texto de qualquer plataforma. Desta forma não há a necessidade de saber como deve se interpretar um número. Além disso como as tags são abertas e fechadas, o começo e final dos dados são bem definidos, além de não existir mais o problema de se encontrar uma quebra de linha inesperada dentro da sua aplicação. Você não precisará fazer engenharia reversa para descobrir a formatação dos dados ou confiar em documentos imprecisos ou indisponíveis do formato de dados. O XML por si só faz uma auto-descrição de seu conteúdo através da nomenclatura de suas tags. O XML é utilizado cada vez mais nos mais diversos campos como: web sites, EDI (eletronic data interchange), representação de gráficos vetoriais, genealogia, serialização de objetos, RPC (remote procedure call), sistemas de voice mail,etc. Poucos fornecedores ainda insistem em forçar seus usuários com dados de formatos binários, proprietários e não documentados. No entanto, no longo prazo seria se utilizasse formatos em texto, bem documentado, fácil de entender, fácil de parsear que o XML fornece. O XML faz com que documentos e dados sejam trafegados entre sistemas com razoável esperança de que os destinos entendam-nas. Além do mais, a validação através de DTD ou XSD faz com que o receptor verifique se os dados estão no formato esperado. Assim como o Java prometeu programação portável, o XML fornece dados portáveis. Apesar de simples e poderoso, o XML: 򐂰 Não é uma linguagem de programação. Apesar de atualmente existirem diversas ferramentas de XML Scripting, tais como o Apache Ant, devemos prestar atenção ao fato de que é a aplicação quem toma a ação ao ler um Script XML. O resultado disto é semelhante à uma aplicação que lê um arquivo texto de configuração para tomar suas decisões.

14

WebSphere Message Broker 6.0 - Treinamento Básico

򐂰 Não é um protocolo de transporte. O XML necessita de um meio de transporte para ser enviado pela rede. Existem protocolos codificados em XML, porém novamente podemos observar que existe uma aplicação que envia os dados. 򐂰 Não é um banco de dados. Dados podem ser armazenados facilmente em XML, porém nada supera as características de manipulação de dados básicos (CRUD - create, read, update, delete) de um banco de dados. O XML pode ser armazenado em banco de dados em campos BLOB ou VARCHAR. O XML possui uma série de componentes que descrevem os dados contidos, que serão apresentados em seguida.

3.1.1 Declaração XML É um trecho opcional. Caso exista deve ser o primeiro a aparecer dentro do documento. Abaixo segue um exemplo de declaração XML (em negrito):

Isto é uma mensagem Figure 3-1 Exemplo de um XML simples com declaração XML

Traz as seguintes informações: 1. versão do XML: Informação utilizada pelo XML Parser 2. encoding: Informa como o XML foi codificado, já que este é texto. O seu valor default é UTF-8. 3. standalone: Indica se o XML necessita de um DTD externo para ser lido. O seu valor default é “no“.

3.1.2 Instrução de processamento É um meio de passar informações de processamento para uma determinada aplicação. Esta instrução deve começar com Vide abaixo exemplos de instrução de processamento (em negrito):

Isto é uma mensagem Figure 3-2 Exemplo de um XML simples com instrução de processamento

A declaração XML é um tipo especial de intrução de processamento.

Chapter 3. XML

15

3.1.3 Comentários Utilizados para comentar trechos de XML ou dar informações adicionais para o XML. Os comentários devem ser iniciados por . Vide abaixo exemplos de comentários (em negrito):

Isto é uma mensagem Figure 3-3 Exemplo de um XML simples com comentários

3.1.4 Elementos Vejamos o exemplo abaixo com elementos (em negrito).

-1 Objeto não encontrado Figure 3-4 Exemplo de um XML simples com elementos

Elementos consistem de tag iniciadora(eg: ), seu conteúdo (eg: -1) e tag finalizadora (eg: 0

MAXDEPTH

Local

Tamanho máximo de mensagem para a fila

Inteiro > 0

MAXMSGL

Local

Indicador de uso da fila

NORMAL XMITQ

USAGE

Local

Prioridade default

Inteiro de 0 a 9

DEFPRTY

Todos

Persistência default

YES NO

DEFPSIST

Todos

Habilidade de PUT simultâneo

EXCL SHARED

DEFPSOPT

Local

Classe de mensagens não-persistentes

NORMAL HIGH

NPMCLASS

Local

Sequencia de entrega

PRIORITY FIFO

MSGDLVSQ

Local

Habilidade de GET simultâneo

SHARE NOSHARE

SHARE NOSHARE

Local

Processo relacionado à trigger

String

PROCESS

Local

Trigger habilitado

TRIGGER NOTRIGGER

TRIGGER NOTRIGGER

Local

WebSphere Message Broker 6.0 - Treinamento Básico

Atributo

Valores

Atributo MQSC

Tipos de fila

Tipo de trigger

FIRST EVERY DEPTH NONE

TRIGTYPE

Local

Dados para o trigger

string

TRIGDATA

Local

Profundidade de ativação da trigger

inteiro > 0

TRIGDEPTH

Local

Para conhecer os demais atributos veja o seguinte site: http://publib.boulder.ibm.com/infocenter/wmqv6/v6r0/topic/com.ibm.mq.csqzaj.doc/sc 11240_.htm

5.2.3 Canais Todas as comunicações de rede no WebSphere MQ são feitas através de um canal. Quando um canal cria uma conexão entre duas Queue Managers é chamada de message channel e quando é uma conexão entre uma aplicação cliente com uma Queue Manager é chamada de client channel.

Message Channel Agents (MCA) Todos os canais possuem dois Message Channel Agents (MCA) que são complementares e são dos seguintes tipos: 򐂰 Caller MCA: é o MCA que abre uma fila de transmissão particular e transmite suas mensagens exclusivamente, ou seja, não é possível que dois canais sejam configurados para transmitir mensagens de uma mesma fila de transmissão. Nota: Isto não é válido para canais Cluster, já que estes utilizam uma mesma fila de transmissão. Os canais Cluster não serão apresentados neste treinamento. 򐂰 Responder MCA: é o MCA que recebe as mensagens de um Caller MCA. Para cada mensagem, este MCA remove o cabeçalho de transmissão, faz a resolução de fila e envia para a fila correta.

Channel Object São objetos da Queue Manager que configuram um MCA. Além disso possui atributos que definem como a comunicação será realizada, por exemplo, pode ser especificado o uso da autenticação Secure Sockets Layer (SSL)

Message Channels Para que duas Queue Managers possam se comunicar por Message Channels, as seguintes medidas devem ser tomadas: 1. Os channels objects complementares devem possuir o mesmo nome, ou seja, se o channel object da Queue Manager QMGR1 se chama QMGR1.TO.QMGR2, o channel object da Queue Manager QMGR2 também deverá se chamar QMGR1.TO.QMGR2. 2. Os channel objects complementares devem possuir o mesmo protocolo, por exemplo TCP/IP

Chapter 5. WebSphere MQ

49

3. Os channel objects complementares devem possuir o mesmo número de sequência de mensagem esperada A figura a seguir ilustra uma configuração típica com duas message channels:

Figure 5-2 Configuração típica de message channel

Os tipos de message channels possíveis serão apresentados a seguir.

Canal Sender/Receiver Este canal só pode ser iniciado pelo lado Sender. Múltiplos channel object “Sender“ podem ser definidos em diferentes Queue Managers utilizando o mesmo channel object “Receiver“ de uma Queue Manager. Suponhamos que um channel object “Sender “ é criado numa Queue Manager A e um channel object “Receiver” é criado numa Queue Manager B. Os passos de comunicação são: 1. O channel object Sender inicia o canal solicitando que o canal Receiver inicie 2. O MCA do “Sender” envia as mensagens da filas de transmissão da Queue Manager A 3. O MCA do “Receiver” faz a resolução de fila e envia a mensagem para a fila correspondente.

Canal Requester/Server Este canal pode ser iniciado pelo lado Requester, mas opcionalmente pode ser iniciado pelo lado Server se este tiver o endereço do lado Requester. Esta forma de canal não garante que o Requester está num determinado endereço. Da mesma forma que no canal Sender/Receiver, múltiplos channel object “Requester“ de diferentes Queue Managers podem conectar-se a um channel object “Server“. Contudo apenas um canal Requester/Server deve estar ativo por vez.

50

WebSphere Message Broker 6.0 - Treinamento Básico

Suponhamos que um channel object “Server” é criado numa Queue Manager A e um channel object “Requester” é criado numa Queue Manager B. Os passos de comunicação são: 1. O channel object “Requester” inicia o canal solicitando que o channel object “Server” inicie. 2. O MCA do “Server“ envia as mensagens da filas de transmissão da Queue Manager A 3. O MCA do canal “Requester“ faz a resolução de fila e envia a mensagem para a fila correspondente.

Canal Requester/Sender Esta forma de canal é similar ao canal requester/sender com o “Server“ configurado com o endereço do “Requester“. Suponhamos que um channel object “Sender” é criado numa Queue Manager A e um channel object “Requester” é criado numa Queue Manager B. Os passos de comunicação são: 1. O channel object “Requester” inicia o canal solicitando que o channel object “Server” inicie. 2. O canal é desconectado e reiniciado pelo Sender. 3. O MCA do “Sender“ envia as mensagens da filas de transmissão da Queue Manager A 4. O MCA do canal “Requester“ faz a resolução de fila e envia a mensagem para a fila correspondente.

Canal Server/Receiver Este tipo de canal é funcionalmente equivalente ao canal Sender/Receiver.

Tratamento de falhas de entrega A Figura 5-3 na página 52 abaixo mostra o que ocorre quando o Responder MCA não consegue entregar a mensagem para a fila destino:

Chapter 5. WebSphere MQ

51

Figure 5-3 O que ocorre quando uma mensagem não pode ser entregue

Se um Responder MCA não consegue entregar a mensagem para a fila destino os seguintes passos podem ser tomados: 1. Como algumas falhas podem ser transitórias por natureza, como uma fila que atingiu se número máximo de mensagens, a ação de postagem pode ser tentada novamente. O número de vezes de tentativas e o delay entre elas são configuradas no channel object desta MCA. 2. Caso atinja-se o número máximo de tentativas ou ocorra algum outro tipo de erro, o MCA pode retornar a mensagem para o remetente. Neste caso é necessário configurar algumas opções de postagem assim como setar as propriedadesReplyToQ e ReplyToQmgr. 3. Caso não seja possível entregar nem devolver a mensagem, ela é enviada para a fila DLQ. 4. Se a fila DLQ não estiver disponível, então a mensagem não é retirada da fila de transmissão e o canal pára.

Client Channel Os Client Channels permitem que as aplicações remotas possam se conectar à queue manager. Quando uma aplicação conecta numa queue manager através de uma API, ela invoca um MCA provido pela API cliente. Este MCA cria a comunicação com a queue manager por um Client Channel através do Listener provido pela queue manager. Do lado da queue manager, um channel object “Server Connection” é iniciado pela queue manager.

52

WebSphere Message Broker 6.0 - Treinamento Básico

Outra forma de se realizar um Client Connection é através de um channel object “Client Connection“ em que pode-se incluir atributos avançados como a configuração de um SSL.

5.2.4 Mensagem As mensagens enviadas pela infra-estrutura WebSphere MQ podem conter dados de qualquer forma. No intuito de ser possível o processamento de cada mensagem são necessárias informações a respeito da mensagem, como por exemplo se a mensagem necessita de uma resposta. Estas informações estão descritas no cabeçalho MQMD (MQ Message Descriptor). Neste cabeçalho encontram-se entre outras informações: 򐂰 O ID da mensagem, que é única. 򐂰 O tipo da mensagem, para determinar se uma resposta é necessária. 򐂰 Detalhes de onde enviar qualquer resposta para a mensagem. 򐂰 O tempo de expiração. 򐂰 Informações de como a mensagem foi construída, quando e por quem. 򐂰 Informações sobre a representação dos dados no corpo da mensagem.

Persistência de mensagens A mensagem persistente é aquela que pode ser recuperada mesmo após uma parada abrupta da queue manager. Isto é possível pois ela é persistida localmente e um registro de log (apresentado na seção seguinte) é criado na queue manager. Normalmente a mensagem persistente é usada nos negócios críticos, porém devido à própria persistência ela é menos performática. Em contraste a este tipo de mensagem, a mensagem não-persistente não é gravada localmente nem “logada“ e portanto mais rápida. Uma fila pode conter ambos os tipos de mensagens, porém na ocasião de uma parada abrupta da queue manager, apenas as mensagens persistentes sobreviverão. Nota: Para que as mensagens persistentes sobrevivam à uma parada normal é necessário que o atributo NPMCLASS seja configurado como HIGH. Caso contrário, todas as mensagens não-persistentes serão apagadas no reinício da queue manager.

Logging O logging é uma função fundamental realizada por uma queue manager. Este log é um registro das ações sucessivas feitas na queue manager. Todas as ações feitas com mensagens persistentes são “logadas”, assim como as mudanças nas configurações de objetos da queue manager e outras ações internas. O método que a queue manager utiliza para escrever o log assegura que as ações não ocorram enquanto os logs não forem garantidamente escritos. Os dados de log são mantidos separados dos dados da queue manager. Nos dados da queue manager são mantidos os status atuais de todos os objetos e mensagens guardadas nas filas.

Chapter 5. WebSphere MQ

53

Quando a queue manager termina abruptamente, por exemplo, numa falha de máquina, os dados da queue manager estarão num estado inconsistente. Nestas circunstâncias, a queue manager utiliza o log para reconstruir o estado atual correto dos objetos durante o reinício da queue manager. Regularmente a queue manger faz com que os dados de log sejam consistentes com os dados da queue manager. Este processo é chamado de check point e ocorre automaticamente enquanto a queue manager está em execução e quando ela termina. Assim, quando uma queue manager termina normalmente significa que existirão um mínimo número de logs a serem lidos.

Syncpoint O syncpoint é o ponto de início de uma transação no WebSphere MQ. A transação só pode ser iniciada no momento de um PUT ou GET de mensagens. As mensagens que foram postadas ou lidas de determinadas filas desde o syncpoint ficam invisíveis para outras aplicações até que seja dado um commit ou backout da transação. Nota: No WebSphere MQ é utilizado a termologia “unit of work” para denotar uma transação, ou seja, um agrupamento de ações que podem ser consolidados ou desfeitos. Pode-se habilitar ou desabilitar a transação através de uma opção SYNCPOINT ou NO-SYNCPOINT no momento do PUT ou GET. Mensagens com syncpoint são mais lentas pois são gravadas em disco.

Expiração Se uma aplicação implementa o timeout, este deve especificar o tempo de expiração no cabeçalho MQMD. Este intervalo é dado em décimos de segundos e é reduzido enquanto a mensagem trafega dentro da infra-estrutura MQ até ser lido pela aplicação. A aplicação pode receber uma notificação de expiração indicando que a mensagem foi descartada. Nota: O WebSphere MQ não discarta a mensagem imediatamente após o tempo de expiração. Ao invés disto, a mensagem continua na fila até que a aplicação tente lê-la. A notificação de expiração ocorrerá somente neste momento. No WebSphere MQ V6.0, uma verificação periódica é feita em todas as filas da queue manager para que as mensagens expiradas sejam removidas automaticamente. Isto está habilitado por default.

5.3 A interface de comandos WebSphere MQ Script (MQSC) A interface de comandos MQSC é utilizada para administrar objetos WebSphere MQ. Uma linha de comando possui a seguinte sintaxe: COMANDO TIPO_OBJETO(‘nome_objeto’) +

54

WebSphere Message Broker 6.0 - Treinamento Básico

ATRIBUTO_1(valor) + ... ATRIBUTO_n(valor) A linha de comando pode ficar numa única linha separado por espaços, porém quando o comando for separado por ENTER, será necessário acrescer o símbolo “+“ no final da linha. Atributos: 򐂰 Quando um atributo for string, o seu valor deve estar entre aspas simples 򐂰 Quando um atributo tiver um domínio(eg.: ENABLED/DISABLED, YES/NO), o seu valor não deverá possuir aspas. 򐂰 Quando um atributo for numérico, o seu valor não deverá possuir aspas.

Seguem alguns exemplos abaixo: 򐂰 Definindo uma fila local: DEFINE QLOCAL(‘INTVISION.FILA1’) DESCR(‘Primeira fila da Intvision’) 򐂰 Sobrescrevendo uma fila existente com a palavra-chave REPLACE: DEFINE QLOCAL(‘INTVISION.FILA1’) DESCR(‘Nova fila da Intvision’) REPLACE 򐂰 Mostrando todos os atributos das filas locais que têm o nome iniciado por “INTVISION”: DISPLAY QLOCAL(‘INTVISION*’) ALL 򐂰 Mostrando apenas os atributos: quantidade de mensagens na fila (CURRDEPTH) e a descrição da fila (DESCR) para todas as filas locais: DISPLAY QLOCAL(*) CURRDEPTH DESCR 򐂰 Idem ao ítem anterior, porém mostrando somente as filas que começam com “INTVISION“ e com mais de 10 mensagens: DISPLAY QLOCAL(‘INTVISION*’) CURRDEPTH DESCR WHERE(CURRDEPTH GT 10)

Chapter 5. WebSphere MQ

55

56

WebSphere Message Broker 6.0 - Treinamento Básico

6

Chapter 6.

Trabalhando com WebSphere MQ Neste capítulo vamos lidar com a criação, iniciação e administração de Queue Managers. Aprenderemos a utilizar tanto o WebSphere MQ Explorer quanto os controles de linha de comando e o WebSphere MQ Script (MQSC).

© Copyright Intvision Solutions 2007. All rights reserved.

6.1 Ferramentas de administração O WebSphere MQ possui 3 tipos de ferramentas de administração: 1. Linha de comando: são comandos que não mudam de nomenclatura entre as plataformas e possuem as seguintes finalidades: a. Comandos de Queue Manager (strmqm.exe, endmqm.exe, crtmqm.exe e dltmqm.exe): start, end, create e delete respectivamente. b. Comandos run (runXXX.exe): iniciam canais, listeners, trigger monitors, etc. c. Comandos display (dspXXX.exe): mostram informações como versão do MQ, status de inicialização de queue managers, etc. Nota: Estes comandos se encontram na pasta /bin dentro do diretório de instalação do WebSphere MQ. Após a instalação do WebSphere MQ a variável de ambiente $PATH é atualizada com este diretório. 2. MQ Script Command (MQSC): São comandos utilizados para administrar os objetos de uma Queue Manager. Para utilizá-lo digite na linha de comando: runmqsc.exe 3. MQ Explorer: É uma ferramenta gráfica baseado-se na plataforma Eclipse, onde é possível realizar a maioria das tarefas realizadas por linha de comando ou pelo MQSC.

6.2 Privilégios de acesso Para que seja possível manipular os objetos pelas ferramentas de administração é necessário que seu usuário possua os seguintes privilégios: 򐂰 No Windows: deve ser membro dos grupos Administradores e mqm. 򐂰 No UNIX e Linux: deve ser membro do grupo mqm.

6.3 Cenário do Laboratório Neste laboratório faremos a criação dos objetos MQ básicos e faremos a comunicação entre duas Queue Managers criando e configurando os objetos adicionais necessários. O cenário de implementação é apresentado na Figura 6-1 na página 59.

58

WebSphere Message Broker 6.0 - Treinamento Básico

Figure 6-1 Cenário de implementação do laboratório WebSphere MQ

6.4 Criação de objetos 6.4.1 Preparação da Queue Manager QMGR1 Para o preparo desta Queue Manager utilizaremos os recursos do MQ Explorer.

Criação da Queue Manager 1. Clique com o botão direito sobre a pasta “Queue Managers“ e New →Queue Manager 2. Digite QMGR1 como nome da Queue Manager

Figure 6-2 Criação de Queue Manager pelo MQ Explorer

3. Clique em Next Chapter 6. Trabalhando com WebSphere MQ

59

4. Em seguida serão apresentados as configurações de Logging do MQ. Vamos deixar com as configurações default. Clique em Next

Figure 6-3 Passo 2 de criação da Queue Manager

5. Agora será apresentado como a Queue Manager será iniciado. Selecione também a opção “Create server-connection channel“, que habilitará um canal para que uma aplicação cliente remota consiga conectar na Queue Manager. Clique em Next

Figure 6-4 Passo 3 da criação da Queue Manager

60

WebSphere Message Broker 6.0 - Treinamento Básico

6. No passo seguinte remova a seleção para a opção “Create listener configured for TCP/IP“, pois criaremos um Listener na seção seguinte.

Figure 6-5 Passo 4 da criação da Queue Manager

7. O último passo configura o MQ Explorer para a Queue Manager criada. Clique em Finish

Figure 6-6 Passo 5 da criação da Queue Manager

Criação de Filas locais A Queue Manager QMGR1 aparecerá como um ítem no MQ Explorer. A partir de então será possível criar as filas. 1. Na Queue Manager criada, dê um clique direito sobre Queues e faça New →Local Queue

Chapter 6. Trabalhando com WebSphere MQ

61

Figure 6-7 Criando uma fila local pelo MQ Explorer

2. Preencha com o nome “EXERCICIO1.IN“ e Finish 3. Crie mais uma fila local com o nome “EXERCICIO1.OUT“

Testanto as filas criadas 1. Clique sobre a fila criada com o botão direito e selecione “Put Test Message“.

Figure 6-8 Testando a fila com o MQ Explorer

2. Digite uma mensagem qualquer. 3. Faça um refresh da página a partir do ícone superior direito indicado naFigura 6-9. Verifique que a profundidade da fila aumentou.

Figure 6-9 Indicação dos atributos das filas no MQ Explorer

62

WebSphere Message Broker 6.0 - Treinamento Básico

6.4.2 Preparação da Queue Manager QMGR2 Criação da Queue Manager Para o preparo desta Queue Manager utilizaremos a linha de comando e a interface MQSC. 1. Na linha de comando digite “crtmqm QMGR2” O resultado deste comando será: WebSphere MQ queue manager created. Creating or replacing default objects for QMGR2. Default objects statistics : 43 created. 0 replaced. 0 failed. Completing setup. Setup completed.

2. Digite “strmqm QMGR2” para iniciá-lo.

Criação de Filas locais A queue manager QMGR2 aparecerá com o seu status de inicialização através do comando “dspmq”.

Figure 6-10 Verificação dos status das Queue Managers

A partir de então será possível criar as filas. Isto é possível através da interface MQSC pelo comando: runmqsc QMGR2 A seguinte tela será apresentada:

Figure 6-11 Acesso à interface MQSC

1. Copie os comandos abaixo: ********************************* * DEFINIÇÃO DE FILAS ********************************* DEFINE QLOCAL('EXERCICIO2.IN') DEFINE QLOCAL('EXERCICIO2.OUT') END

Testanto as filas criadas 1. Na linha de comando digite: amqsput EXERCICIO2.IN QMGR2 Chapter 6. Trabalhando com WebSphere MQ

63

2. Digite quantas mensagens quiser separados por ENTER. Para sair deixe uma linha em branco e pressione ENTER. 3. Para verificar o número de mensagens na fila, volte para a interface MQSC e digite o seguinte comando: DISPLAY QLOCAL(EXERCICIO2.IN) CURDEPTH

6.4.3 Comunicação entre Queue Managers A troca de mensagens entre Queue Managers é feita através de canais. No entanto, os canais necessitam de pontos de conexão nas respectivas Queue Managers, pois estes são inicialmente isolados. Estes pontos de conexões são as portas TCP, NetBIOS, SPX, etc. Os pontos de conexão são chamados de Listener na Queue Manager. Neste treinamento criaremos um listener TCP em cada queue manager utilizando as duas formas de criação: pela linha de comando e pelo MQ Explorer.

Criação da Fila de Transmissão na QMGR1 Vamos criar uma fila de transmissão das mensagens que irão para a Queue Manager QMGR2: 1. Siga os passos da criação de uma fila local pelo MQ Explorer e digite o nome da fila conforme abaixo:

Figure 6-12 Criação de uma fila de transmissão pelo MQ Explorer

2. Em seguida altere a propriedade Usage para Transmission

64

WebSphere Message Broker 6.0 - Treinamento Básico

Figure 6-13 Configurando a fila para ser uma fila de transmissão

3. Clique em Finish

Criação da Fila de Transmissão na QMGR2 1. Entre na interface MQSC (“runmqsc QMGR2“) 2. Digite o comando abaixo: ********************************* * CRIAÇÃO DA FILA DE TRANSMISSÃO ********************************* DEFINE QLOCAL(QMGR1) USAGE(XMITQ) END

Criação de Listener na QMGR1 Vamos criar o listener TCP com a porta 1414 através do MQ Explorer. 1. Na Queue Manager criada, vá em Advanced →Listeners →New →TCP Listener

Chapter 6. Trabalhando com WebSphere MQ

65

Figure 6-14 Criando um listener pelo MQ Explorer

2. Configure a propriedade Control como Queue Manager e digite a porta 1414 e clique em Finish.

Figure 6-15 Configuração do novo listener

3. Clique com o botão direito sobre o listener criado e clique em Start

Criação de Listener na QMGR2 Vamos criar o listener TCP com a porta1415 através do MQSC. 1. Entre na interface MQSC (“runmqsc QMGR2“) 2. Copie os comandos abaixo. ********************************* * DEFINIÇÃO DO LISTENER ********************************* DEFINE LISTENER('QMGR2_LISTENER') + TRPTYPE(TCP) + PORT(1415) + CONTROL(QMGR) *********************************

66

WebSphere Message Broker 6.0 - Treinamento Básico

* INICIALIZAÇÃO DO LISTENER ********************************* START LISTENER('QMGR2_LISTENER') END

Criação dos canais na QMGR1 1. Na QMGR1, vá em Advanced →Channels →New →Sender Channel

Figure 6-16 Criação de canais no MQ Explorer

2. Digite as informações abaixo:

Figure 6-17 Configurações de Sender Channel para QMGR1

3. Em seguida crie um Receiver Channel:

Chapter 6. Trabalhando com WebSphere MQ

67

Figure 6-18 Configurações de Receiver Channel para QMGR1

Criação dos canais na QMGR2 1. Entre na interface MQSC (“runmqsc QMGR2“) 2. Digite os seguintes comandos: ********************************* * CRIAÇÃO DO CANAL SENDER ********************************* DEFINE CHANNEL(QMGR2.QMGR1) + CHLTYPE(SDR) + CONNAME('localhost(1414)') + XMITQ('QMGR1') ********************************* * CRIAÇÃO DO CANAL RECEIVER ********************************* DEFINE CHANNEL(QMGR1.QMGR2) + CHLTYPE(RCVR)

Inicialização do canal na QMGR1 1. Dê um clique direito sobre o canal Sender criado e selecione Start

Figure 6-19 Inicialização do canal Sender na Queue Manager

68

WebSphere Message Broker 6.0 - Treinamento Básico

Inicialização do canal na QMGR2 1. Entre na interface MQSC (“runmqsc QMGR2“) 2. Digite o comando abaixo: ********************************* * INICIALIZAÇÃO DO CANAL SENDER ********************************* START CHANNEL(QMGR2.QMGR1) END

Chapter 6. Trabalhando com WebSphere MQ

69

70

WebSphere Message Broker 6.0 - Treinamento Básico

7

Chapter 7.

WebSphere Message Broker Este capítulo provê uma visão macro do Websphere Message Broker e seu papel na integração de sistemas. As suas funcionalidades principais e os seus componentes serão descritos.

© Copyright Intvision Solutions2007. All rights reserved.

7.1 Websphere Message Broker na integração de sistemas A integração de sistemas é um grande desafio nas grandes empresas. A IBM provê inúmeras soluções e oferecimentos para auxiliar as empresas a integrar seus sistemas. O Websphere Message Broker é uma importante parte dos oferecimentos da IBM. Numa visão de alto nível a integração de sistemas refere-se à soluções de integração de sistemas de dentro ou fora da empresa. Historicamente, a integração de sistema tem se preocupado com a integração de sistemas legado como os de diferentes departamentos e divisões da compania, ou de novas aquisições. Dentro da organização, estes sistemas variam consideravelmente pelos departamentos, existem em diferentes plataformas, são escritas em diferentes linguagens de programação e usam diferentes estruturas de dados. Assim sendo, integrar sistemas é uma solução mais prática e barata do que re-escrever as aplicações existentes. O Websphere Message Broker é usado na implementação da integração de sistemas pois este provê mecanismos de conexão, roteamento e transformação de dados de negócio ,originários de uma variedade de protocolos de transporte, sem necessitar nenhuma alteração na aplicações geradoras ou consumidoras dos dados. O Websphere Message Broker também possui as seguintes funcionalidades-chave que o torna uma valiosa solução de integração: 򐂰 Distribui qualquer tipo de informação entre diversos sistemas e aplicações, provendo a informação correta no formato correto e no momento correto. 򐂰 Reduz o número de conexões ponto-a-ponto e simplifica a programação removendo a lógica de integração das aplicações. 򐂰 Roteia a informação em tempo real baseado em tópico e conteúdo para qualquer destino utilizando um poderoso engine publish/subscribe 򐂰 Valida e transforma mensagens em diferentes formatos de mensagens, incluindo Web Services e outros formatos XML e não-XML. 򐂰 Roteia mensagens baseado em conteúdo 򐂰 Aumenta a agilidade nos negócios reconfigurando dinamicamente os padrões de distribuição de informações sem a reprogramação das aplicações-destino. 򐂰 Controle de acesso para entrega segura de informações para o local correto no momento correto.

7.2 Websphere Message Broker Em termos práticos o WebSphere Message Broker é um mediador que realiza transformação de mensagem e roteia para diferentes participantes de diferentes destinos baseado em regras definidas pelo usuário. Assim, diversas aplicações podem trocar informações de diferentes formas com o broker lidando com o processamento da informação que deve chegar ao lugar certo e no formato certo. Diferentemente de um servidor de processos, o WebSphere Message Broker não é um bom lugar para armazenar estados de processos long-running ou coreografar diversos processos de negócio. Na verdade o WebSphere Message Broker provê uma camada de conectividade para os executores do processos que coreografam o fluxo de atividades entre serviços. É de responsabilidade do WebSphere Message Broker entregar as requisições de serviço, re-rotear ou transformá-lo se necessário.

72

WebSphere Message Broker V6.0 - Treinamento Básico

De forma semelhante, o WebSphere Message Broker também não é um lugar indicado para implementar lógicas de negócio. Não é uma boa idéia encapsular uma lógica de negócio dentro de message flows. Enquanto o WebSphere Message Broker possui a habilidade de rotear e transformar a mensagem baseada em regras de negócio e valores, a lógica de negócio complexa deve ser colocada num servidor de aplicações como o WebSphere Application Server. Uma das forças do WebSphere Message Broker é sua poderosa capacidade de parsear diferentes formatos de mensagens vindos de diferentes canais e protocolos, manipulando a mensagem, e serializando a mensagem em diversos tipos de mensagem física e protocolos. O WebSphere Message Broker é flexível suficiente para: 򐂰 Suportar diversos paradigmas de mensageria como o comportamento síncrono ou assíncrono Suportar diferentes padrões de interações como fire-and-forget, request-reply, publish-subscribe e capacidade de agregação.

7.2.1 Edições de Websphere Message Broker Existem três edições do produto Websphere Message Broker que são descritas abaixo:

Websphere Event Broker O Websphere Event Broker é usado para distribuição e roteamento de mensagens de diferentes aplicações. Ele pode distribuir informações e dados, que são geradas por eventos de negócio em real-time para pessoas, aplicações e dispositivos pela empresa. O Websphere Event Broker tem suporte para múltiplos protocolos de transporte e estende a informação além do ponto-a-ponto, utilizando mecanismos de distribuição flexíveis como o publish/subscribe e multicast.

Websphere Message Broker O Websphere Message Broker contém todas as funcionalidades do Websphere Event Broker e estende-o para incluir funcionalidades adicionais que habilitam armazenamento, transformação e complementação de dados que trafegam pelo broker.

Rules and Formatter Extension Websphere Message Broker with Rules and Formatter Extension provê Rules and Formatter nodes e elementos runtime associados. Isso suporta as funcionalidades das versões antigas do Websphere MQ Integrator. Esta funcionalidade não será tratada no treinamento.

7.2.2 Funcionalidades do Websphere Message Broker Roteamento de mensagem Provê a conectividade para aplicações e serviços tanto standard-based como non-standard-based. O roteamento pode ser ponto-a-ponto ou baseado no filtragem do conteúdo da mensagem. O Websphere Message Broker contém uma gama de transportes que fazem com que os negócios sejam seguros e conduzidos à qualquer hora e lugar, provendo integração usando tecnologias móvel, de telemetria e de Internet. O Websphere Message Broker é construído sobre o WebSphere MQ e desta maneira suporta os mesmos transportes. No entanto, ele também estende as funcionalidades do WebSphere MQ adicionando o suporte a outros protocolos, incluindo Internet e Intranet em tempo-real e destinos multicast. Chapter 7. WebSphere Message Broker

73

Neste âmbito o Websphere Message Broker suporta os seguintes transportes: 򐂰 WebSphere MQ Enterprise Transport 򐂰 WebSphere MQ Web Services Transport 򐂰 WebSphere MQ Real-time Transport 򐂰 WebSphere MQ Multicast Transport 򐂰 WebSphere MQ Mobile Transport 򐂰 WebSphere MQ Telemetry Transport 򐂰 WebSphere Broker JMS Transport Além destes transportes fornecidos, os usuários podem definir e criar seus próprios input nodes que aceitem mensagens de outros transportes e formatos.

Transformação e enriquecimento de mensagem A transformação e enriquecimento é uma importante capacidade do Websphere Message Broker e possibilita a integração de negócios sem a necessidade de lógica adicional nas aplicações a serem integradas. As mensagens podem ser transformadas entre aplicação para usar diferentes formatos. Por exemplo, transformando um formato personalizado de uma sistema legado para um XML que pode ser utilizado com um Web Service. Este mecanismo é poderoso na unificação da empresa na medida em que a informação pode ser distribuída para sistemas que esperam formatos de dados completamente diferentes sem que haja a necessidade de reprogramação nos sistemas de origem ou destino. As mensagens podem ser enriquecidas pela integração com múltiplas fontes de dados como banco de dados, aplicações e arquivos. Isto permite qualquer manipulação de dados como logging ou merging. Manipulações complexas dos dados da mensagem podem ser realizadas utilizando ESQL ou Java. No Websphere Message Broker, a transformação e alteração da mensagem depende do entendimento da estrutura e conteúdo da mensagem de entrada. Mensagens auto-definidas como XML contém informações sobre sua estrutura e formato. Entretanto para uso de outros tipos de mensagem personalizada é necessário que a definição de mensagem esteja presente. O Message Broker Toolkit auxilia na definição destas mensagens para o message broker.

Publish/Subscribe A maneira mais simples de rotear um mensagem é utilizando a mensageria ponto-a-ponto para enviar mensagens diretamente de uma aplicação à outra. A arquitetura publish/subscribe provê uma outra forma de mensageria na qual a mensagem é enviada para todas as aplicações que assinam um tópico particular. O broker lida com a distribuição das mensagens entre as aplicações publicadoras e aplicações assinantes. Quanto mais aplicações publicam ou assinam em muitos tópicos, mas mecanismos sofisticados de filtragem podem ser aplicados.

7.2.3 Componentes do Websphere Message Broker O Websphere Message Broker consiste em duas partes principais: um ambiente de desenvolvimento para a criação de message flows, message sets, e outros artefatos; um

74

WebSphere Message Broker V6.0 - Treinamento Básico

ambiente runtime que contém componentes para execução desses message flows criados no ambiente de desenvolvimento.

Ambiente de desenvolvimento O ambiente de desenvolvimento é onde são criados os message flows que contém a fluxo com a lógica à ser executada. O Broker utiliza esta lógica para processar as mensagens em runtime. Message Flows Os message flows são fluxos onde os nodes são conectados, cada um deles provendo alguma lógica básica. A combinação de vários nodes é utilizada para conseguir manipulações complexas da mensagem. Uma sorte de métodos estão disponíveis para definir a lógica do fluxo de mensagem. Dependendo do tipo de dados ou dos skills do desenvolvedor, existem as seguintes opções: – Extended Structured Query Language (ESQL) – Java – eXtensible Style Sheet Language for Transformations (XSLT) – Mapeamento Drag-and-drop Os nodes definem o protocolo de transporte para as aplicações de origem e de destino. Message Sets Um message set é a definição da estrutura da mensagem que será processada por um message flow no broker. Como mencionado anteriormente, para que um message flow seja capaz de transformar a mensagem, o broker precisa conhecer a estrutura da mensagem. A definição da mensagem pode ser usada para verificar a estrutura da mensagem em runtime e/ou ajudar na construção dos message flows e mapeamentos no Message Broker Toolkit. Os message sets são compilados são chamados de message dictionary.

Ambiente Runtime O ambiente runtime é um conjunto de componentes requeridos para deploy e execução de message flows. Broker O Broker é onde se armazena e se executa um message flow. O Broker usa o WebSphere MQ como transporte para comunicar-se com outros Brokers e também com o Configuration Manager, de onde este recebe as informações de configuração. Cada Broker possui um banco de dados onde é armazenado todas as configurações deste, incluindo os message flows e message sets. Execution groups É parte componente de um Broker (descrito acima) para possibilitar que message flows sejam agrupados por interesse. Um Broker pode possui n execution groups. Os execution groups são processos de sistema operacional separados (possuem pid program ids - distintos) e, portanto o conteúdo do execution group permanecem separados dentro de um mesmo Broker. Isto é útil para isolar message flows. O deploy de um message flow é feito num execution group específica. Configuration Manager

Chapter 7. WebSphere Message Broker

75

O Configuration Manager faz a interface entre o Message Broker Toolkit e os Brokers. O Configuration Manager armazena as configurações dos Brokers num repositório interno, provendo assim um controle central das configurações dos Brokers associados. O Configuration Manager é responsável por fazer o deploy dos message flows nos Brokers. Ele também reporta o andamento do deploy e os status do ambiente dos Brokers como por exemplo se um determinado message flow está parado ou não. Broker Domain Os Brokers são agrupados em Broker Domains. Os Brokers de um determinado Broker Domain compartilham uma configuração em comum que é definido no Configuration Manager. Um Broker Domain pode conter também um User Name Server. Os componentes de um Broker Domain podem existir em múltiplas máquinas e sistemas operacionais, e são conectadas via WebSphere MQ. Um Broker pertence a apenas um Broker Domain. User Name Server O User Name Server é um componente opcional que é requerido apenas quando message flows com publish/subscribe estão em execução, ou quando uma segurança extra é requerida para que aplicações consigam publicar ou assinar tópicos. O User Name Server provê autenticação por tópicos para usuários e grupos que fazem operações publish/subscribe.

Figure 7-1 Arquitetura dos componentes runtime

76

WebSphere Message Broker V6.0 - Treinamento Básico

7.3 WebSphere Message Broker como ESB A arquitetura SOA define um approach para reutilização e extensão de recursos de maneira flexível. Isto é feito separando-se a interface do serviço da sua implementação. Cada aplicação que contém uma lógica de negócio é exporta como serviço. Por exemplo, o serviço de criação de conta de cliente poderia ser uma transação CICS, enquanto que uma chamada de saldo de cliente é servida por uma aplicação J2EE rodando num WebSphere Application server. Criando-se uma interface padrão para estas aplicações, suas lógicas de negócio ficam disponíveis para reutilização para muito processos de negócio. Possibilitar que aplicações conversem numa mesma linguagem não é fácil. Aplicações antigas podem utilizar tecnologias que são completamente diferentes das atuais. Um ESB permite virtualização e gerenciamento de interações de serviços entre os participantes da comunicação. Ele não só ajuda na camada de conectividade entre provedor e consumidor de serviço, mas também auxilia na tradução de tipos de mensagem. Um ESB pode localizar os provedores de serviço e rotear a requisição para o serviço mais adequado, eliminando a necessidade do consumidor saber onde o provedor está. O WebSphere Message Broker provê as capacidades de um Exposed ESB Gateway, incluindo: 򐂰 Virtualização de serviço 򐂰 Suporte e conversão de protocolos de transporte 򐂰 Modelagem e transformação de mensagem 򐂰 Roteamento dinâmico de mensagem 򐂰 Suporte à mediação personalizada 򐂰 Suporte à padrões de interação como: request-reply, publish-subscribe, aggregation. 򐂰 Integração com outros enterprise information systems (EIS) 򐂰 Suporte a Quality of Service (QoS). 򐂰 Acesso ao registro de serviços. 򐂰 Facilidade de administração

7.3.1 Virtualização de serviço A virtualização de serviço é um atributo core de um ESB. O requisitante do serviço não necessita se preocupar com qual linguagem de programação o serviço foi criado, sua plataforma de execução, seu endereço de rede, seu protocolo de comunicação ou mesmo quando o provedor de serviço está disponível. O requisitante só tem a responsabilidade de conectar ao bus e colocar a requisição. O WebSphere Message Broker utiliza message flow que aceitam requisições de diferentes formatos, protocolos e canais de comunicação. Ele pode determinar qual o destino para a requisição, converter a requisição se necessário e enviá-lo para o provedor do serviço. O provedor de serviço aceita a requisição do WebSphere Message Broker na sua forma nativa e reponde de volta ao bus, que por sua vez resposta à requisição inicial. O provedor de serviço portanto não necessita saber qual é o formato da mensagem do requisitante.

Chapter 7. WebSphere Message Broker

77

7.3.2 Suporte e conversão de protocolo de transporte O uso de um ESB elimina a necessidade do provedor e consumidor de serviços usarem o mesmo protocolo. O WebSphere Message Broker suporte uma gama de protocolos tantos de entrada como de saída para estender o alcance e escopo até dispositivos móveis e dispositivos de telemetria como sensores e atuadores. Os transportes suportados pelo WebSphere Message Broker incluem: 򐂰 WebSphere MQ Enterprise Transport Utilizado para conectar aplicações WebSphere MQ que conectam no WebSphere Message Broker. Os Nodes deste protocolo são: – MQInput Node – MQOutput Node – MQReply Node – MQGet Node – Publication Node

Figure 7-2 Paletas com Nodes MQ no WebSphere Message Broker Toolkit 6.0.2

򐂰 WebSphere MQ Mobile Transport Utilizado exclusivamente pelos clientes do WebSphere MQ Everyplace. Desta forma os dispositivos móveis como handhelds podem enviar mensagens para o bus. Os nodes deste protocolo são: – MQeInput Node – MQeOutput Node

Figure 7-3 Paletas com Nodes MQe no WebSphere Message Broker Toolkit 6.0.2

򐂰 WebSphere MQ Multicast Transport É utilizado predominantemente no modelo publish/subscribe. Os nodes que dão suporte a este protocolo são: – Real-timeInput Node – Real-timeOptimizedFlow Node

78

WebSphere Message Broker V6.0 - Treinamento Básico

– Publication Node

Figure 7-4 Paletas com Nodes Multicast no WebSphere Message Broker Toolkit 6.0.2

򐂰 WebSphere MQ Real-time Transport Este é um protocolo leve otimizado para uso com mensagens não persistentes. Ele é usado exclusivamente por clientes JMS e são obtidos grandes níveis de escalabilidade e throughput de mensagem. Os nodes que suportam este protocolo são: – Real-timeInput Node – Real-timeOptimizedFlow Node – Publication Node

Figure 7-5 Paletas com Nodes Real-time no WebSphere Message Broker Toolkit 6.0.2

򐂰 WebSphere MQ Telemetry Transport Este é utilizado em aplicações especiais em dispositivos que utilizam poucos recursos e requerem pouca banda de rede, tipicamente para aquisição de dados e controle de processos de produção. Os nodes que suportam este protocolo são: – SCADAInput Node – SCADAOutput Node – Publication Node

Figure 7-6 Paletas com Nodes de telemetria no WebSphere Message Broker Toolkit 6.0.2

򐂰 WebSphere MQ Web services Transport Este protocolo utiliza o protocolo HTTP sobre TCP/IP. O protocolo HTTP é o mais comum na Internet e Intranet já que seus pacotes normalmente não são bloqueados por muitos firewalls. Os nodes que suportam este protocolo são: – HTTPInput Node – HTTPReply Node Chapter 7. WebSphere Message Broker

79

– HTTPRequest Node

Figure 7-7 Paletas com Nodes HTTP no WebSphere Message Broker Toolkit 6.0.2

Nota: Caso haja um message flow com HTTPInput Node em execução num Broker runtime, será iniciado o processo biphttplistener que receberá as requisições HTTP de entrada. A porta default deste listener é o 7080 para HTTP e 7083 para HTTPS. 򐂰 WebSphere Broker JMS Transport É utilizado para enviar/receber mensagens JMS que seguem a especificação 1.1 do JMS. Provendo interoperabilidade com as implementações JMS de diversos fornecedores, o WebSphere Message Broker pode atuar como ponte entre as combinações de JMS Providers. Os nodes que suportam este protocolo são: – JMSInput Node – JMSOutput Node

Figure 7-8 Paletas com Nodes JMS no WebSphere Message Broker Toolkit 6.0.2

O JMSInput Node permite que uma mensagem JMS seja recebida de um ponto JMS e as mensagens JMS são enviadas para outro ponto JMS por um JMSOutput Node. Estes pontos são acessíveis através de uma conexão com um JMS Provider. Quando uma

80

WebSphere Message Broker V6.0 - Treinamento Básico

mensagem JMS chega, o JMSInput Node criará a estrutura de mensagem mostrada na Figura 7-9. .

Figure 7-9 Representação da árvore lógica de mensagem JMS

Os nodes JMSMQTransform e MQJMSTransform são nodes que fazem a ponte de transformação entre os protocolos JMS e WebSphere MQ. Na prática estes nodes fazem um mapeamento de cabeçalhos necessários para cada tipo de transporte.

Figure 7-10 Mapeamento entre mensagem JMS e mensagem MQ

O WebSphere Message Broker pode também suportar como entrada/saída: 򐂰 Arquivos do filesystem 򐂰 Arquivos VSAM 򐂰 Arquivos QSAM Chapter 7. WebSphere Message Broker

81

򐂰 CICS EXCl 򐂰 TCP/IP Socket 򐂰 FTP 򐂰 Protocolos de telemetria baseados no SCADA. O WebSphere Message Broker também suportam WBI Adapters que fornecem outros tipos de protocolos de transporte.

7.3.3 Modelagem de mensagem e transformação A maioria dos negócios globais recaem sobre a troca de informações entre aplicações. A informação fica contida em mensagem que possuem uma estrutura definida que é conhecida e estabelecida entre remetente e destinatário. As aplicações tipicamente usam uma combinação de mensagems, incluindo algumas definidas com as seguintes estruturas ou padrões: 򐂰 Estruturas de dados C e COBOL 򐂰 Padrões industriais como SWIFT e EDIFACT 򐂰 DTD ou Schema XML Você pode modelar uma grande variedade de formatos de mensagem que são entendidas pelos message flows do WebSphere Message Broker. Quando a modelagem da mensagem é conhecida, o broker runtime pode parsear uma mensagem entrante (mensagem física) e convertê-la para uma árvore de mensagem lógica. Assim, esta mensagem lógica é manipulada e no final do seu processamento pelo message flow, o broker runtime a converte novamente para o formato físico. Abaixo segue uma visão geral de como uma mensagem física é parseada quando chega à um Input Node:

Figure 7-11 Modelagem de mensagem e transformaçao

O WebSphere Message Broker fornece uma gama de parsers para ler e escrever formatos de dados. Alguns formatos de dados como XML são auto-definidas e podem ser parseados para uma mensagem lógica sem uma referência a um modelo de mensagem. No entanto a maioria dos formatos de mensagem não são auto-definidas. Por exemplo, a mensagem binária COBOL ou uma mensagem formatada em SWIFT não contém definições suficientes para que o parser entenda a mensagem. Desta forma, o parser necessita de um modelo que descreva como a mensagem deve ser parseada. 82

WebSphere Message Broker V6.0 - Treinamento Básico

Para aumentar a produtividade de criação de modelos de mensagem, os importadores são fornecidos para transformar em modelos de mensagem as definições encontradas em: 򐂰 Arquivos de cabeçalho C (C Header) 򐂰 Arquivos copybook de COBOL 򐂰 XML Schema 򐂰 DTD 򐂰 Arquivos WSDL Além disso, a IBM fornece modelo pré-construídos dos padrões industriais como SWIFT, EDIFACT, X12, FIX, HL7, TLOG e outros.

Figure 7-12 Modelagem de mensageem no WebSphere Message Broker

A tabela seguinte mostra os parsers suportados pel WebSphere Message Broker: Table 7-1 Tabela com parsers Parser

Uso

MRM

Para modelar um grande alcance de mensagens incluindo XML, formatos binários fixos, mensagens sequenciais. O MRM pode também ser utilizado para lidar com JMS byteMessage e textMessage que entram por um JMSInput Node.

XML

Para mensagens em conformidade com o padrão XML do W3C, porém sem suporte a namespaces.

Chapter 7. WebSphere Message Broker

83

Parser

Uso

XMLNSC, XMLNS

Para mensagens em conformidade com o padrão XML do W3C, com suporte a namespaces

JMSMap ou JMSStream

Para mensagens produzidas pelo provider JMS do WebSphere MQ. O JMSInput Node formata o JMS MapMessage e StreamMessage para XML.

IDOC

Para mensagens no formato SAP iDoc.

MIME

Para lidar com mensagens MIME como o SOAP com anexos ou RosettaNet

BLOB (Binary Large Object)

Na realidade não é um parser, já que mantém a mensagem na sua forma física (bit stream).

Nota 1: O BLOB será o parser default, caso não seja associado nenhum ao Input Node.

Nota 2: Não se esqueça que cada parser tem a resposabilidade final de transformar a mensagem física em mensagem lógica (árvore lógica) e vice-versa. A mensagem lógica criada fica no domínio do seu parser até que isto seja alterado dentro do message flow. Por isso, muitas vezes dentro do contexto do WebSphere Message Broker, você ouvirá dizer em Message Domain, que é a referência para o parser da mensagem lógica. Uma vez que a mensagem de entrada é construída como mensagem lógica, o WebSphere Message Broker possui diferentes formas de processá-la:

Validate Node

Figure 7-13 Representação do Validate Node no Toolkit

É utilizado para fazer a validação da mensagem entrante. Também é utilizado quando mensagens de diversos formatos chegam a um message flow. O Validate Node verifica as propriedades: message domain, message set e message type da mensagem que chega ao seu terminal In. Ele pode ser configurado para verificar se o conteúdo da mensagem bate com estas propriedades. Table 7-2 Propriedades do Validate Node

84

Propriedade

Domínio

Check message domain

Todos

Check message set

Somente MRM e IDOC

Check message type

Somente MRM

Validate message body

Somente MRM e IDOC

WebSphere Message Broker V6.0 - Treinamento Básico

Compute Node

Figure 7-14 Representação do Compute Node no Toolkit

Utilizado para construi uma ou mais mensagens de saída. Ele é utilizado criar uma mensagem totalmente nova com ou sem acesso a banco de dados, ou modificar a mensagem que passa por ele. As instruções de processamento da mensagem são feitas através da linguagem ESQL. O Extended Structured Query Language(ESQL) é uma linguagem de programação que estende o Structured Query Language (SQL) que tem uso comum em banco de dados relacionais. Com o ESQL você pode criar ou modificar tanto a mensagem de entrada quanto banco de dados externos através de expressões. As expressões podem conter operadores aritméticos, operadores de texto (eg.: concatenação), operadores lógicos e outras funções pré-definidas. Entre as utilizações comuns do Compute Node estão: 򐂰 Construir uma nova mensagem usando alguns comandos de atribuição. 򐂰 Transformar uma mensagem de um formato para outro. 򐂰 Converter o codepage de uma mensagem texto para outra. Por exemplo, alterar um texto codificado em ASCII para EBCDIC. 򐂰 Criação de rotas dinâmicas. Por exemplo, o Compute Node pode propagar a mensagem para um Label Node. 򐂰 Aggregação de informação com acesso a banco de dados. Abaixo segue um trecho de código ESQL gerado para um Compute Node:

Chapter 7. WebSphere Message Broker

85

CREATE COMPUTE MODULE MessageFlowTeste_Compute CREATE FUNCTION Main() RETURNS BOOLEAN BEGIN -- CALL CopyMessageHeaders(); -- CALL CopyEntireMessage(); RETURN TRUE; END; CREATE PROCEDURE CopyMessageHeaders() BEGIN DECLARE I INTEGER 1; DECLARE J INTEGER; SET J = CARDINALITY(InputRoot.*[]); WHILE I < J DO SET OutputRoot.*[I] = InputRoot.*[I]; SET I = I + 1; END WHILE; END; CREATE PROCEDURE CopyEntireMessage() BEGIN SET OutputRoot = InputRoot; END; END MODULE; Figure 7-15 Código ESQL default criado para um determinado Compute Node

Nota: O acesso a banco de dados deste node é realizado através de conexão ODBC. A propriedade Data Source do Compute Node indica qual é a conexão ODBC a ser utilizada.

Java Compute Node

Figure 7-16 Representação do Java Compute Node no Toolkit

O Java Compute Node é um novo node muti-uso para programação. Ele é baseado no Java 1.4.2 e suporta XPath 1.0 para navegar pelas mensagens. Nota: O suporte para o Java versão 5 está disponível apenas a partir do fixpack 3 do Broker Runtime. Até o lançamento deste treinamento, a versão 6.0.2 do Message Broker Toolkit possuia suporte apenas até a versão 1.4.2 do Java. O deploy de códigos Java 1.5 é possível, porém utilizando-se a plataforma Eclipse a partir da versão 3.1 para o desenvolvimento. O deploy do arquivo .jar pode ser feito normalmente através do Message Broker Toolkit ou Configuration Manager Proxy. Porém, a não ser que haja grande necessidade, este suporte deve ser evitado. O Java Compute Node pode transformar a mensagem e rotear a mensagem para um dos seus terminais de saída. O suporte à banco de dados é fornecido de duas formas: 򐂰 Via JDBC type 4 (sem suporte a XA)

86

WebSphere Message Broker V6.0 - Treinamento Básico

򐂰 Via classe MbSQLStatement que utiliza a conexão ODBC com suporte transacional total. O código Java associado a um Java Compute Node é armazenado num Java Project no workspace do Message Broker Toolkit e pode ser aproveitado todas as funcionalidades do Java Development Toolkit (JDT) do Eclipse para o seu desenvolvimento. O suporte ao debug deste código é fornecido utilizando-se o Java debugger do Eclipse, que se conecta a JVM do execution group do Broker runtime. Abaixo segue um exemplo de código Java associado à um Java Compute Node:

import com.ibm.broker.javacompute.MbJavaComputeNode; import com.ibm.broker.plugin.*; public class SamplelNode extends MbJavaComputeNode { public void evaluate(MbMessageAssembly assembly) throws MbException { MbOutputTerminal out = getOutputTerminal("out"); MbOutputTerminal alt = getOutputTerminal("alternate"); MbMessage message = assembly.getMessage(); // ---------------------------------------------------------// Add user code below // End of user code // ---------------------------------------------------------// The following should only be changed // if not propagating message to the 'out' terminal out.propagate(assembly); } } Figure 7-17 Exemplo de código de um Java Compute Node

Mapping Node

Figure 7-18 Representação do Mapping Node no Toolkit

A grande vantagem do Mapping Node em relação aos outros Nodes de transformação é o mapeamento drag-and-drop que permite uma visualização gráfica da transformação da mensagem. O seu uso comum é a realização de mapeamentos de estruturas lógicas semelhantes. Para mapeamento de estruturas complexas utilize um Compute Node ou um Java Compute Node. Dentro de um Mapping Node é possível construir um ou mais mensagens e agregá-los com informações de banco de dados ou da mensagem de entrada. Os mapeamentos são transformados em código ESQL no momento do deploy. A atribuições feitas através do mapeamento drag-and-drop podem ser alteradas aplicando-se funções ESQL pré-definidas ou personalizadas e/ou funções do XPath 1.0. Por exemplo, você pode converter o dado origem para caixa alta.

Chapter 7. WebSphere Message Broker

87

Figure 7-19 Editor de mapeamentos do Mapping Node

Na WebSphere Message Broker V6.0 é possível realizar o debug gráfico passo-a-passo pelo Mapping Node através do Flow Debugger. Nota: O Mapping Node suporta apenas mensagens definidas em Message Sets e tabelas de banco de dados definidas em Database Schemas.

XML Transformation Node

Figure 7-20 Representação do XML Transformation Node no Toolkit

O XML Transformation Node utiliza o eXtensible Stylesheet Language for Transformations (XSLT) para transformar uma mensagem XML para outro formato (que pode ser ou não um XML) de acordo com as regras escritas num arquivo XSL.

Figure 7-21 Funcionamento do XML Transformation Node

O XML Transformation Node será gerados como Java no momento do deploy. O WebSphere Message Broker V6 suporte stylesheets compilados, que aumentam a performance da transformação.

88

WebSphere Message Broker V6.0 - Treinamento Básico

7.3.4 Roteamento dinâmico Numa arquitetura SOA um ESB deve ter a capacidade de decidir o destino de uma mensagem dinamicamente provendo assim uma transparência na localização dos serviços. Com o WebSphere Message Broker o roteamento pode ser baseado no cabeçalho da mensagem (como MQMD ou MQRFH2) ou no seu conteúdo. Vale a pena mencionar que no WebSphere Message Broker V6 foram adicionados dois tipos de dados novos: ROW e SHARED. Eles são úteis para a tomada de decisões de roteamento a partir de tabelas de decisão. Normalmente a solução indicada era salvar a tabela de decisão num banco de dados para que todos os message flows tivessem acesso. No entanto, uma melhor alternativa é a variável SHARED ROW. Com ele você pode atribuir uma tabela de lookup em memória, que é compartilhada para todas as instâncias de message flows.

-- Uma variável compartilhada que pode ser usada por todas as instâncias do message flow declare CacheQueueTable SHARED ROW; -- Código para atribuir ou excluir regras da variável CacheQueueTable ...... -- Pega a informação de roteamento diretamente da memória SET OutputLocalEnvironment.Destination.MQDestinationList.DestinationData[] = ( SELECT S.QUEUE_MANAGER as queueManagerName, S.QUEUE_NAME as queueName FROM CacheQueueTable.DestinationData[] as S WHERE S.VARIABLE2 = Variable2 and S.VARIABLE3 = Variable3 ); Figure 7-22 Trecho de código: usando uma variável compartilhada

Filter Node

Figure 7-23 Representação do Filter Node no Toolkit

O Filter Node roteia a mensagem de acordo com expressões booleanas ESQL. Você pode utilizar qualquer elemento da mensagem de entrada e acessar o banco de dados para montar a expressão e como resultado terá TRUE, FALSE ou UNKNOWN (no caso de a expressão não retornar nada).

Flow Order Node

Figure 7-24 Representação do Flow Order Node no Toolkit

O Flow Order Node controla a ordem de processamento de uma mensagem dentro do message flow. A mensagem de entrada é propagada para fluxo ligado ao terminal First. Quando este fluxo termina o controle é retornado para o Flow Order Node, que em seguida envia a mesma mensagem de entrada para o terminal Second.

Chapter 7. WebSphere Message Broker

89

Label Node e Route To Label Node

Figure 7-25 Representação do Label Node no Toolkit

Figure 7-26 Representação do Route To Label Node no Toolkit

Utilize um Route To Label Node para rotear a mensagem para um dos Label Nodes localizados dentro do message flow.

7.3.5 Estendendo as funcionalidades O WebSphere Message Broker pode ser estendida de acordo com suas necessidades. Os support packs fornecidos pela IBM ou por terceiros podem auxiliá-lo na implementação dos message flows.

QSAM dataset adapter Os nodes QSAM dataset adapter do SupportPac IA11 são utilizados para operar num QSAM( eg.: dataset sequencial de um mainframe).

Figure 7-27 Nodes relacionados com QSAM datasets

VSAM dataset adapter Os nodes VSAM dataset adapter do SupportPac IA13 são utilizados para operar datasets VSAM de um mainframe.

Figure 7-28 Nodes relacionados com VSAM datasets

WebSphere Message Broker File Extender Este provê um conjunto de nodes para o WebSphere Message Broker V6 para adicionar capacidades no domínio de arquivos físico. Nota: Para mais informações sobre o WebSphere Message Broker file Extender veja a página do produto: http://www-306.ibm.com/software/integration/wbimessagebroker/fileextender/v5/in dex.html

90

WebSphere Message Broker V6.0 - Treinamento Básico

LDAP Plug-in O SupportPac IA08 contém um node para acesso ao LDAP usando certos parâmetros da mensagem.

Sendmail Plug-in O SupportPac IA07 contém um node para construir um e-mail e enviá-lo.

Customização de Plug-in O WebSphere Message Broker fornece APIs para permitir que o desenvolvimento de plug-ins para extensão de capacidades de mediação: 򐂰 API Java para criação de plug-in 򐂰 API C para criação de plug-in e parsers Nota: Para mais informações sobre o desenvolvimento de plug-ins customizados procure o capítulo “Developing user-defined extensions“ no information center do WebSphere Message Broker.

7.3.6 Padrões de interação Quando dois ou mais sistemas interagem entre si, estes sempre recaem sobre os seguintes padrões de interação: 򐂰 Interação de mão única 򐂰 Requisição/Resposta 򐂰 Agregação 򐂰 Publish/Subscribe (pub/sub)

Interação de mão única O cenário fire-and-forget é o mais comum para o modo assíncrono: o remetente envia a mensagem para o destinatário e só. O remetente não precisa de uma resposta do destinatário para continuar seu trabalho. Algumas vezes quando necessário, o destinatário envia uma resposta para o remetente. Nesta situação o requisitante deve implementar um event handler para capturar a resposta que chega assincronamente fazendo uma correlação entre requisição/resposta. O WebSphere Message Broker suporta interações assíncronas usando o transporte MQ ou JMS. Ele também suporta o modo one-way de Web Service usando SOAP over HTTP 1.1. Neste caso o requisitante não espera por uma resposta SOAP, mas sim por um simples status HTTP 200 ou 202.

Requisição/Resposta É o cenário mais amplamente utilizado nos modos síncrono e assíncrono. Quando é síncrono o requisitante envia a mensagem, aguarda pela resposta, e continua suas tarefas. O requisitante deve esperar por um determinado período de tempo, mas caso a resposta não chegue uma exceção de time-out terá de ser tratada. Um exemplo típico deste cenário é uma solicitação de saldo bancário num ATM, na qual a aplicação aguarda pela resposta do sistema CICS.

Chapter 7. WebSphere Message Broker

91

Agregação A agregação é um processo que se constitui de duas etapas: 1. Requisição de pelo menos 2 serviços a partir da mensagem de entrada. 2. Processamento das respostas dos serviços e agregação destas numa única mensagem de saída. Um exemplo típico deste cenário é quando um cliente faz um pedido pela Internet. O Broker constrói diversas requisições independentes que são disparadas para os fornecedores envolvidos no pedido e então consolida os resultados numa única resposta para o cliente. Os nodes utilizados para a implementação deste cenário são: 򐂰 AggregateControl node 򐂰 AggregateRequest node 򐂰 AggregateReply node

Figure 7-29 Nodes de agregação

Publish/Subscribe (pub/sub) O publish/subscribe envolve o envio de dados de uma aplicação para qualquer número de receptores. Isto introduz uma camada de abstração entre remetente e receptor, já que um não precisa se preocupar com o outro. Esta camada de abstração é provida pelo Broker, que gerencia os dados de entrada (publication) das aplicações remetentes (publishers) e encontra os receptores interessados (subscribers). O broker então envia os dados para os subscribers registrados. A correlação entre publishers e subscribers é definida através de tópicos, que ficam contidos em uma estrutura hierárquica definida pela aplicação. Os subscribers registram o interesse em um tópico (ou tópicos) com o Broker. O Broker então distribui uma publicação para este tópico para todos estes interessados. Por exemplo, o Broker publica o preço de uma ação de diferentes companias usando diferentes tópicos, um por compania. Os usuários assinarão apenas os tópicos das companias que lhe interessem. Dentro de um message flow, a publicação em tópico é possível através do Publication Node.

7.3.7 Integração com outros Enterprise Information Systems (EIS) Um ESB deve ter a capacidade de interagir com os EIS existentes dentro da empresa. Existem diversos adapters para interação com outros componentes do ambiente como: 򐂰 Siebel 򐂰 PeopleSoft 򐂰 SAP R/3 򐂰 CICS Transaction Server 򐂰 IMS 92

WebSphere Message Broker V6.0 - Treinamento Básico

7.3.8 Suporte a Quality of service (QoS) Pelo ponto de vista de arquitetura um ESB deve apenas prover a capacidade de virtualização de serviço, mas sempre existem uma série de questões de QoS que afetam um ESB. Alguns dos importantes aspectos de QoS que afetam um ESB são: 򐂰 Autenticação e autorização 򐂰 Garantia de entrega para o local correto e confidencialidade 򐂰 Transações 򐂰 Performance e throughput 򐂰 Alta disponibilidade 򐂰 Logging, métricas e monitoração

7.3.9 Acesso ao registro de serviços A medida que a infra-estrutura SOA cresce, fica mais importante que o sistema de serviços possa: 򐂰 Encontrar e publicar serviços 򐂰 Gerenciar o ciclo de vida do serviço 򐂰 Suportar interações policy-driven. 򐂰 Alterar notificações. 򐂰 Ter um repositórios de metadados de serviços Um registro de serviços gerencia os metadados do serviço habilitando a seleção, invocação, gerenciamento, governança e reuso dos serviços levando-se assim para uma arquitetura SOA bem-sucedida. Como espinha dorsal da arquittetura SOA, o ESB deve ter habilidade total de acessar um registro de serviços. O SupportPac IA9L habilita o WebSphere Message Broker acessar o WebSphere Service Registry and Repository de dentro do message flow.

7.3.10 Facilidade de administração Um ESB deve ser fácil de gerenciar. O WebSphere Message Broker inclui o WebSphere Message Broker Toolkit, que é uma ferramenta de desenvolvimento e administração dos componentes runtime.

Chapter 7. WebSphere Message Broker

93

Figure 7-30 Message Broker Toolkit

Além da interface do Message Broker Toolkit, você pode escolher as seguintes opções: 򐂰 SupportPac IS02: WebSphere Message Broker Administrator Explorer Plug-in for MQ Explorer Este SupportPac permite que tarefas administrativas do Message Broker sejam realizadas através do WebSphere MQ Explorer. Veja mais informações em: http://www-1.ibm.com/support/docview.wss?rs=171&uid=swg24012457&loc=en_US&cs=ut f-8?=en 򐂰 Configuration Manager Proxy API Através desta API uma aplicação pode ser conectar a um Configuration Manager e gerenciar os objetos do Broker Domain. Mais informações podem ser encontradas no WebSphere Message Broker Information Center: http://publib.boulder.ibm.com/infocenter/wmbhelp/v6r0m0/topic/com.ibm.etools.mf t.doc/ae20620_.htm

94

WebSphere Message Broker V6.0 - Treinamento Básico

7.4 Suporte a Web Services Com o WebSphere Message Broker você pode desenvolver seus message flows para trabalhar com mensagens SOAP sobre qualquer um dos transportes suportados, incluindo o HTTP/HTTPS, JMS ou MQ.

7.4.1 Escolhendo o message domain para SOAP Como o SOAP é uma mensagem XML, seu message flow terá que usar um dos seguintes parsers: XMLNS, XMLNSC ou MRM. Caso seu WebService usa SOAP com anexos, então você precisará utilizar o parser MIME. O SOAP versão 1.1 e 1.2 são suportadas pelo WebSphere Message Broker V6.

MRM domain O MRM domain é criado por um parser que utiliza as definições de mensagem de um Message Set. O parser MRM pode ser utilizado para interpretar três tipos de mensagens: 򐂰 Custom Wire Format (CWF): Modelagem de mensagens binárias C, COBOL, PL/I e de outras linguagens. 򐂰 XML Wire Format (XML): Modelagem de mensagens XML, com ou sem utilização de namespace. Com esta modelagem é possível associar tipagem e constraints aos elementos XML, além de controlar a sua cardinalidade e composição na mensagem. 򐂰 Tagged Delimited String Format (TDS): Modelagem de mensagens posicionais ou separados por delimitadores e tags. Por exemplo: HL7, SWIFT, EDIFACT e X12. Os message sets compilados são chamados de dicionários no ambiente do Broker runtime. O MRM parser pode efetuar uma validação da mensagem com o dicionário implementado no ambiente runtime.

XML domains Três tipos de parsers são disponibilizados para interpretar um XML em conformidade com o padrão W3C: 򐂰 XMLNSC domain Este domain pode ser utilizado para qualquer mensagem XML, incluindo aqueles que utilizam namespaces. O parser usa a implementação XML4C e reduz a quantidade de memória ocupada na montagem da árvore lógica. É importante notar que o comportamento default do parser XMLNSC é discartar whitespaces não significativos (tab, enter, espaços) , mixed content (elementos misturados com texto), comentários, processing instruction e DTDs embutidos. 򐂰 XMLNS domain Caso o XMLNSC parser não cumpra seus requisitos, utilize este. O uso de namespace é permitido. 򐂰 XML domain Este parser não permite a utilização de namespace. É fornecido por razões de compatibilidade com versão anteriores do WebSphere Message Broker.

MIME domain - SOAP com anexos O SOAP com anexos é um padrão W3C para Web services que precisem incorporar anexos como imagens em suas mensagens. Ele é baseado no multipart MIME, que consiste numa mensagem particionada, cada um com um tipo definido e delimitado com um string limitador.

Chapter 7. WebSphere Message Broker

95

A primeira parte da mensagem é normalmente uma mensagem SOAP normal que refere às outras partes (os anexos).

MIME-Version: 1.0 Content-Type: Multipart/Related; boundary=MIME_boundary; type=text/xml Content-Description: Optional description of message. Optional preamble text --MIME_boundary Content-Type: text/xml; charset=UTF-8 Content-Transfer-Encoding: 8bit Content-ID: abc-123 myClaimDetails cid:[email protected] --MIME_boundary Content-Type: application/octet-stream Content-Transfer-Encoding: binary Content-ID: myBinaryData --MIME_boundary-Optional epilogue text Figure 7-31 Exemplo de mensagem MIME

O MIME parser interpreta a mensagem MIME e gera a árvore lógica correspondente como abaixo:

96

WebSphere Message Broker V6.0 - Treinamento Básico

Figure 7-32 Árvore lógica criada pelo MIME parser

Observe que cada corpo das partes da mensagem MIME é guardado como BLOB. Normalmente a mensagem é parseada com o MIME parser na entrada do message flow e a primeira parte (onde está a mensagem SOAP) da mensagem é parseada com o MRM parser ou pelo ResetContentDescriptor Node. O parser MIME implementado no WebSphere Message Broker não suporta completamente o padrão MIME, mas suporta todos os formatos MIME usados em aplicações baseadas em mensagem, incluindo SOAP com anexos e RosettaNet.

Qual domain escolher? Se a sua mensagem é XML, então utilize um dos seguintes parsers: 򐂰 MRM parser com message set modelado com XML Wire Format. 򐂰 XMLNS parser 򐂰 XMLNSC parser No entanto o MRM parser oferecerá maior flexibilidade pelos seguintes motivos: 򐂰 O dicionário gerado pela modelagem do message set pode ser aproveitado no message flow para: – Fornecer tipagem dos elementos do XML. – Validar o XML com as constraints e composição dos elementos. – Decodificar automaticamente os dados binários codificados em Base64. – Extração automática de data e hora através de uma máscara (eg.: yyyy-mm-dd hh:mm:ss) 򐂰 Existem opções avançadas de renderização do formato físico XML. Por exemplo você pode ter um elemento que é renderizado como atributo numa mensagem e como elemento numa outra mensagem.

Chapter 7. WebSphere Message Broker

97

򐂰 Você pode compartilhar a estrutura lógica com outras representações físicas. Por exemplo, uma mensagem criada em COBOL na representação física Custom Wire Format (CWF) pode ter a mesma representação lógica para o formato físico XML Wire Format (XML) Caso nenhuma das razões acima lhe interessem veja as próximas dicas: 򐂰 Se você necessita de uma melhor performance ou menor consumo de memória, utilize o XMLNSC parser. 򐂰 Nunca utilize o XML domain para novos message flows. Este domain é fornecido apenas por razões de compatibilidade. 򐂰 Caso sua mensagem chegue de uma aplicação escrita em COBOL, C ou PL/I ou mesmo consista em dados binários fixos utilize o MRM domain com o formato físico CWF. 򐂰 Caso a sua mensagem consiste de texto formatado, separados por tags ou delimitadores ou ambos, utilize o MRM domain com o formato físico TDS. 򐂰 Se você utiliza mensagens JMS use o XML domain ou um dos JMS domains. 򐂰 Se sua mensagem possui várias partes ou utiliza anexos SOAP, utilize o MIME parser. Adicionalmente você pode customizar um domain desenvolvendo o seu próprio parser.

98

WebSphere Message Broker V6.0 - Treinamento Básico

8

Chapter 8.

Instalação Este capítulo detalha considerações de software e de sistema para instalar o Websphere Message Broker. Serão discutidas as seguintes tarefas: 򐂰 Planejamento para a instalação 򐂰 Questões de segurança 򐂰 Instalando os softwares obrigatórios 򐂰 Tarefas pós-instalação 򐂰 Verificando a instalação 򐂰 Instalando fix-packs

© Copyright Intvision Solutions 2007. All rights reserved.

8.1 Planejamento para a instalação Esta seção apresenta informações a respeito dos softwares obrigatórios e opcionais para instalar o Websphere Message Broker v6.0 no Windows. Os requisitos para estes produtos, como espaço em disco e memória também serão discutidos

8.1.1 Softwares obrigatórios Para realizar uma instalação full do Websphere Message Broker você deverá instalar todos os softwares obrigatórios listados a seguir. É possível instalar partes específicas do produto numa máquina. Poderíamos por exemplo querer instalar apenas o Broker runtime. Neste caso nem todos os softwares mencionados serão necessários. WebSphere MQ O WebSphere MQ provê um mecanismo de comunicação entre Configuration Manager, os Brokers, o Message Broker Toolkit . O WebSphere MQ pode ser utilizado também para a comunicação com os sistemas a serem integrados. Este deve ser instalado no ambiente runtime do Websphere Message Broker. Um WebSphere MQ Queue Manager deve ser criado para: – Cada Broker runtime criado – Configuration Manager – User Name Server O Message Broker Toolkit comunica-se através de um cliente do WebSphere MQ e portanto não necessita da instalação do WebSphere MQ. WebSphere MQ Explorer O WebSphere MQ Explorer é uma ferramenta de administração gráfica que permite criar, modificar e apagar recursos do WebSphere MQ e monitorar uma rede WebSphere MQ. Apesar de ser um componente opcional, na instalação típica este é instalado. O WebSphere MQ Explorer está disponível em Windows e Linux (x86) apenas. WebSphere Eclipse Platform O WebSphere Eclipse Platform V3.0.1 é um pré-requisito para o WebSphere MQ Explorer ODBC Drivers for Cloudscape O Configuration Manager utiliza um banco de dados Apache Derby embutido. No Windows, o “ODBC Drivers for Cloudscape” pode possibilitar que a mesma base seja utilizada como base de dados do Broker runtime. Esta configuração é suportado em ambiente de teste apenas. Para ambientes de produção, uma outra alternativa de banco de dados deve ser usada. WebSphere Message Broker runtime O WebSphere Message Broker runtime é a parte do produto que possibilita a criação de recursos runtime, incluindo o Configuration Manager, Brokers runtime, User Name Server. Message Brokers Toolkit O Message Brokers Toolkit é uma interface gráfica construída sobre a plataforma Rationall® Application Developer. O Message Brokers Toolkit é usado tanto para desenvolvimento como para administração.

100

WebSphere Message Broker V6.0 - Treinamento Básico

Os desenvolvedores o utilizam para criar message flows e artefatos necessários por ele e o deploy disso é feito também através do Message Brokers Toolkit . O Message Brokers Toolkit pode ser instalado sem o componente runtime por exemplo para desenvolver e/ou administrar componentes de Broker Domains remotos. O Message Brokers Toolkit está disponível para Windows e Linux (x86). Não há nenhum pré-requisito para a sua instalação. Caso algum outro produto que utilize a plataforma Rational Application Developer é encontrada, a instalação do Message Brokers Toolkit utilizará a instalação antiga contanto que a plataforma esteja na mesma versão.

8.1.2 Softwares opcionais Adicionalmente ao softwares obrigatórios, muitos produtos opcionais podem ser instalados. Estes produtos são descritos nesta seção. Rational Agent Controller O Rational Agent Controller (RAC) versão 6.0.0.1 é usado pelo Message Brokers Toolkit durante o debug de um message flow. Caso você deseje usar o Flow Debugger do Message Brokers Toolkit , então será necessário instalar o Rational Agent Controller em cada máquina onde esteja instalado o Broker runtime. Quando o Rational Agent Controller é instalado onde se encontra o Broker runtime, você instala um servidor que se comunica com um cliente Rational Agent Controller embutido no Message Brokers Toolkit . Como a versão de Rational Application Developer se altera durante seu próprio ciclo de vida, a versão funcional do Rational Agent Controller necessária para funcionar com o Broker runtime pode mudar. DB2 Universal Database Enterprise Server O DB2 Universal Database é suportado como um repositório das configurações do Broker runtime. O DB2 Universal Database Enterprise Serer Versão 8.2 é fornecido no pacote do Websphere Message Broker V6.0. Existem três tipos de instalação do DB2: instação compacta, instalação típica e instalação personalizada. A instalação compacta é adequada para todas as funcionalidades requeridas pelo Websphere Message Broker V6.0. No entanto instalaremos a versão típica do DB2 visto que esta inclui ferramentas de administração gráficas como o DB2 Control Center. Outros bancos de dados suportados Os outros bancos de dados suportados em ambiente de produção são o Oracle, Sybase Adaptive Server Enterprise (ASE) e Microsoft SQL Server. Estes não são fornecidos juntamente com o pacote Websphere Message Broker e portanto você terá que obter sua cópia caso queira usar estes bancos de dados.

8.1.3 Requisitos de software Esta seção descreve os requisitos de softwares para o Websphere Message Broker V6.0 Espaço em disco Antes de instalar o Websphere Message Broker verifique a quantidade de espaço em disco necessário. Isto inclui não somente o espaço pós-instalação, mas também o espaço para

Chapter 8. Instalação

101

arquivos temporários durante a instalação, espaço para os softwares requeridos e o espaço para as configurações e desenvolvimentos pós-instalação. Espaço em disco para o Websphere Message Broker A quantidade de espaço em disco requerida depende dos componentes a serem instalados e da working space requerida por estes componentes. O total de espaço requerido para um produto instalado geralmente incrementa numa ordem de dezenas a centenas de megabytes na medida em que os artefatos são desenvolvidos, logs são criados e fixpacks são aplicados. Este aumento dos requisitos de espaço ao longo do tempo devem ser levados em conta. Uma das maiores fontes de uso de espaço em disco é a aplicação de fixpacks. A razão para isto é que as novas versões de plug-ins para o Message Brokers Toolkit não apagam as versões anteriores para não afetar a compatibilidade com outros produtos que dependem da plataforma Rational Application Developer. Um espaço adicional é necessário para arquivos temporários gerados pelo instalador. Ao término da instalação todos os arquivos temporários são apagados. Importante: Caso falte espaço em disco durante a instalação do Message Brokers Toolkit alguns problemas podem ocorrer. Um sintoma disto é a ausência de partes do Message Brokers Toolkit responsáveis por message sets e/ou ausência de nodes. Caso este sintoma ocorra, desinstale o Message Brokers Toolkit e libere um espaço extra antes de reinstalá-lo. Durante a instalação, o wizard mostrará os requisitos dos componentes que serão instalados. A tabela a seguir descreve o cenário típico para componentes instalados no Windows e Linux. Table 8-1 Espaço em disco necessário para componentes instalados em Windows e Linux Componente

Espaço requerido no Windows

Espaço requerido no Linux

Broker, Configuration Manager e User Name Server

315MB (+ 300MB de espaço temporário)

280MB (+ 300MB de espaço temporário)

Transformation services (extensão opcional do Broker)

25MB

20MB

Message Brokers Toolkit

4.2GB (+1.5GB de espaço temporário)

4.2GB (+1.5GB de espaço temporário)

Espaço em disco para o WebSphere MQ A instalação do WebSphere MQ, excluindo o WebSphere MQ Explorer, pode tomar até 25.2MB de espaço em disco. Esta quantidade pode aumentar dependendo dos componentes WebSphere MQ criados. O WebSphere MQ Explorer requer até 40.5MB de espaço em disco. Espaço em disco para o WebSphere Eclipse Platform A instalação do WebSphere Eclipse Platform necessita aproximadamente 1.5GB. Espaço em disco para banco de dados Os bancos de dados fornecidos com o Websphere Message Broker V6.0 requerem os seguinte espaços adicionais:

102

WebSphere Message Broker V6.0 - Treinamento Básico

– O DB2 Universal Database Enterprise Server requer aproximadamente 300MB na instalação compacta. A instalação típica requer aproximadamente 350-560MB e a personalizada 260-600MB. – O Cloudscape embutido necessita aproximadamente 105MB no Windows. Em adição as espaço necessário para a instalação dos bancos de dados, um espaço é necessário para armazenagem das configurações do Configuration Manager e/ou Broker runtime. No caso do Broker runtime, o mínimo de espaço adicional é de 10MB. Memória O mínimo de memória necessária para o Websphere Message Broker V6.0 runtime é de 512MB de RAM. Para executar o Message Brokers Toolkit é necessário um mínimos de 512MB em Windows ou Linux. Para melhor performance é recomendado um mínimo de 1GB de RAM. A memória para os softwares de pré-requisto devem ser considerados.

8.2 Questões de segurança Os requisitos de segurança devem ser considerados antes da instalação do Websphere Message Broker. Existem diferentes formas de controle de segurança para cobrir vários aspectos do uso do produto. Esta seção discute alguns destes aspectos para Windows.

8.2.1 User ID Há um inúmero de aspectos a serem considerados para escolher o user ID utilizado pelo Websphere Message Broker V6.0: 1. O número de caracteres permitido para o user ID varia de acordo com o sistema operacional – No Windows, o tamanho máximo é de 12 caracteres. – No Linux e UNIX®, o tamanho máximo é de 8 caracteres Os bancos de dados também podem ter estas restrições. 2. Utilize todas as letras em minúsculo ou maiúsculo. 3. No Windows, o user ID de administrador não deve ser utilizado. Qualquer tentativa de usar o user ID de administrador com o Websphere Message Broker runtime produz erros de autorização. 4. No Windows, o user ID criado deve ser membro do grupo de Administradores. É recomendado que o user ID e combinações de senha sejam válidas em todos os sistemas operacionais envolvidos na configuração do Websphere Message Broker.

8.2.2 Outras questões de segurança A segurança deve ser considerada nas máquinas onde o Websphere Message Broker está instalado. Esta seção discute algumas outras questões de segurança para o Websphere Message Broker. Segurança de banco de dados

Chapter 8. Instalação

103

No ambiente de testes, o mesmo user ID e senha podem ser utilizados para acessar banco de dados e criar componentes do Websphere Message Broker. Isto traz simplicidade no ambiente de teste e em ocasiões na qual apenas um usuário administra o banco de dados. Como exemplo, o Default Configuration Wizard, que faz o setup de um Broker Domain para testes, usa o user ID e senha do Websphere Message Broker runtime para criar e acessar os bancos de dados. Num ambiente mais complexo ou num ambiente de Produção, o acesso seguro ao banco de dados é importante, principalmente no acesso à bases armazenadoras de dados de negócio. Nestes ambiente é típico que um administrador de banco de dados determine as permissões para os objetos. Desta forma, diferentes user IDs são necessários para diferentes tarefas. Para segurança de banco de dados seja melhorada, garanta que qualquer senha seja alterada se o default user ID para o banco de dados é usado. Por exemplo, ao usar o DB2, deixar o user db2admin usar a senha db2admin é um risco em potencial. Segurança no WebSphere MQ O usuário do Websphere Message Broker deve ser membro do grupo mqm (grupo de segurança do WebSphere MQ). Este grupo habilita o usuário a criar componentes e acessar filas e outros recursos do WebSphere MQ necessários para a comunicaçao entre componentes do Websphere Message Broker. O SSL pode ser usado na segurança das conexões entre Message Brokers Toolkit e Configuration Manager, assim como nos canais que conectam os Brokers runtime.

104

WebSphere Message Broker V6.0 - Treinamento Básico

8.3 Instalando os softwares obrigatórios Neste treinamento instalaremos o produto através do Launchpad no Windows. Para informações sobre outras alternativas de instalação do Websphere Message Broker V6.0, procure informações relevantes no “Installation Guide”.

8.3.1 O Launchpad Quando você insere a mídia do produto (DVD ou CD), o Lauchpad é executado automaticamente. Caso este não se execute, dê um duplo clique no arquivo mqsilaunchpad.exe que se encontra na pasta raíz. O Launchpad oferece dois tipos de instalação: o Express Installation e o Advanced Installation. Neste treinamento utilizaremos a primeira opção. Express Installation Utilize o Express Installation se você deseja uma instalação full do Websphere Message Broker V6 incluindo os softwares obrigatórios. O Express Installation necessita de pouca interação com o usuário e durante a instalação os valores default são assumidos para que a instalação seja o mais simples e rápido possível. O Express Installation instala todos os softwares requeridos para uma instalação mínima do Websphere Message Broker: 򐂰 WebSphere Eclipse Platform V3.0.1 򐂰 WebSphere MQ 6.0 򐂰 ODBC Drivers for Cloudscape 򐂰 Websphere Message Broker V6.0 򐂰 Websphere Message Broker Toolkit V6.0 O Launchpad detecta quando qualquer software obrigatório já foi instalado no seu sistema. Caso nenhum dos softwares obrigatórios existam, o estado do software estará como pendente (“Pending”) e todos os check boxes serão selecionados. É possível que alguns softwares já existam, mas que o status seja de versão incorreta (“Incorrect Level“).

8.3.2 Instalando o produto via Express Installation Para iniciar o Express Installation: 1. No Launchpad, navegue até a página do Express Installation. Abra a página do Express Installation clicando o botão do canto superior esquerdo. 2. Assegure-se de que todos os check boxes estão selecionados. Todos os softwares deverão estar com status pendente (“pending”). 3. Clique em Launch Express Installation for Websphere Message Broker. Isto iniciará a instalação dos softwares obrigatórios. Enquanto os softwares obrigatórios estão sendo instalados, poucos painéis são mostrados para inserção de dados pelo usuário. Aceite todos os valores default e clique em Next quando solicitado.

Chapter 8. Instalação

105

Verificando o progresso da instalação O progresso do Express Installation pode ser visto através dos estados conforme a figura abaixo:

Figure 8-1 O Launchpad durante o Express Installation

106

WebSphere Message Broker V6.0 - Treinamento Básico

8.4 Tarefas pós-instalação Após a instalação full do Websphere Message Broker V6.0, garanta que os seguintes produtos estejam em execução usando ass instruções desta seção: 򐂰 WebSphere MQ 򐂰 DB2 Universal Database

8.4.1 Serviço WebSphere MQ Para verificar se o serviço do WebSphere MQ está no ar, escolha uma das alternativas: 򐂰 Verifique o rodapé direito do monitor como o ícone do WebSphere MQ. Vide Figura 8-2 na página 107 򐂰 Verifique o status “Started” do serviço “IBM MQSeries” na lista de serviços do Windows: Start →Control Panel →Administrative Tools →Services

Figure 8-2 ícone que mostra o estado de execução do WebSphere MQ

8.4.2 DB2 Universal Database Para verificar se o DB2 Universal Database está em execução, escolha uma das seguintes alternativas: 򐂰 Verifique o rodapé direito do monitor como o ícone do DB2. Vide Figura 8-3 na página 107. Caso o banco esteja parado, clique com o botão direito sobre o ícone e clique em Start(DB2). 򐂰 Na linha de comando digite db2start. Se o DB2 Universal Database estiver em execução, a mensagem “The database manager is already active“ é mostrada. 򐂰 Verifique a o status “Started“ do serviço “DB2 - DB2-0“ na lista de serviços do Windows: Start →Control Panel →Administrative Tools →Services.

Figure 8-3 Ícone que mostra o estado de execução do DB2 Universal Database

Chapter 8. Instalação

107

8.5 Verificando a instalação Esta seção descreve como verificar se a sua instalação do Websphere Message Broker foi bem sucedida. Para auxiliá-lo em verificar a instalação rapidamente existem 2 wizards: 򐂰 Default configuration wizard, para criação de um Broker domain simples. 򐂰 Prepare the Samples wizard, para configurar e fazer deploy de exemplos.

8.5.1 Criando uma configuração default No Message Brokers Toolkit, os message sets e message flows podem ser desenvolvidos sem a criação de componentes runtime. Contudo, você não poderá testar ou executar estes message flows, ou executar qualquer exemplo fornecido até ter configurado os componentes runtime e criado um Broker Domain. O Default Configuration wizard cria os seguintes componentes e recursos no sistema a fim de prover um Broker Domain simples que possa ser utilizado para fins de teste: 򐂰 Um Configuration Manager chamado WBRK6_DEFAULT_CONFIGURATION_MANAGER 򐂰 Um Broker runtime chamado WBRK6_DEFAULT_BROKER 򐂰 Uma Queue Manager chamada WBRK6_DEFAULT_QUEUE_MANAGER compartilhada entre Configuration Manager e o Broker runtime. 򐂰 Um Listener na Queue Manager na porta 2414. 򐂰 Um banco de dados para as configurações do WBRK6_DEFAULT_BROKER chamado DEFBKDB6. Nota: Caso o DB2 esteja instalado e em execução, o Default Configuration wizard o utilizará para a criação da base DEFBKDB6, caso contrário utilizará o banco de dados Apache Derby embutido. Executando o Default Configuration wizard Siga as seguintes instruções para a criação de uma configuração default: 1. Abra o Message Brokers Toolkit: Start →IBM WebSphere Message Brokers 6.0 →WebSphere Message Brokers Toolkit 2. Caso a tela de Welcome não seja aberta, então clique em Help →Welcome 3. Clique no ícone “Getting started“ mostrado na Figura 8-4 na página 108 4. Clique no ícone “Create the Default Configuration“ mostrado na Figura 8-5 na página 109. Este abrirá uma tela com a documentação do produto. 5. Clique em “Start the Default Configuration wizard“. 6. Preencha com a senha do usuário.

Figure 8-4 Ícone “Getting started” da tela de Welcome

108

WebSphere Message Broker V6.0 - Treinamento Básico

Figure 8-5 Ícone do Default Configuration wizard

Quando o Default Configuration wizard termina com sucesso, um Broker Domain simples é configurado no sistema.

Dica: O Default Configuration wizard faz com que os serviços do Broker runtime e Configuration Manager sejam executados automaticaticamente. Problemas podem ocorrer caso os softwares de dependência não sejam iniciados automaticamente. Para resolver este problema configure os serviços do WebSphere MQ e o DB2 para inicializarem automaticamente: Start →Control Panel →Administrative Tools →Services →IBM MQ Series →Properties Start →Control Panel →Administrative Tools →Services →DB2 - DB2-0 →Properties Altere o startup type para automatic

8.5.2 Executando os exemplos Dentro do Message Brokers Toolkit existe uma seleção de exemplos para demonstrar as diferentes áreas de funcionalidades do produto e como usá-los. Os Getting Started Samples são os seguintes: 򐂰 Pager samples 򐂰 Scribble sample 򐂰 Soccer sample O Pager samples são fornecidos para você para verificar a sua instalação do Websphere Message Broker. Para acessar os exemplos, siga os passos 1,2 e 3 da seção anterior e clique no ícone “Run Pager Samples” da Figura 8-6 na página 109

Figure 8-6 Ícone “Run Pager Samples“

Clique em “Set up pager samples“ e isto iniciará o Prepare the samples wizard. Este wizard criará todos os recursos necessários para a execução do exemplos, tais como: filas MQ, deploy na execution group,etc.

Chapter 8. Instalação

109

Importante: Os exemplos funcionam apenas no ambiente default criado por Default Configuration wizard. Os exemplos não serão executados em ambientes montados manualmente, ainda que tenham os mesmos nomes.

8.6 Message Brokers Toolkit O Message Brokers Toolkit é a interface gráfica para o Websphere Message Broker que roda em Windows e Linux. O Message Brokers Toolkit é o ambiente de desenvolvimento de message flows e recursos associados como o ESQL, Java, mapeamentos, definições de mensagem, etc. O Message Brokers Toolkit também é usado para tarefas administrativas como configurar propriedades e componentes de um Broker Domain e publish/subscribe. Algumas tarefas administrativas como início/parada de message flows podem ser realizados tanto no Message Brokers Toolkit quanto pela linha de comando.

8.6.1 Navegando no Message Brokers Toolkit Perspectivas O Message Brokers Toolkit está construído sobre a plataforma Rational Application Developer, que por sua vez baseia-se na plataforma Eclipse. As perspectivas são conceitos herdados do Eclipse, em que uma coleção de views é apresentada de acordo com o objetivo da perspectiva. A Figura 8-7 na página 110 mostra a perspectiva “Broker Application Development perspective”, que é a perspectiva default apresentada quando se abre o Message Brokers Toolkit..

Figure 8-7 Perspectiva de desenvolvimento

110

WebSphere Message Broker V6.0 - Treinamento Básico

Mudando de perspectivas Existem duas formas de se alterar a perspectiva: A primeira forma: 1. Clique em Window →Open Perspective →Other... 2. Selecione a perspectiva desejada e clique OK A segunda forma: 1. No canto superior direito clique no ícone “Open Perspective“. Vide Figura 8-8 na página 111 2. Selecione a perspectiva desejada e caso não encontre, escolha “Others“ para a listagem completa.

Figure 8-8 Ícone “Open Perspective“ (ícone esquerdo)

Quando uma perspectiva é selecionada, o Eclipse criará um botão com o link direto para a perspectiva selecionada. Caso selecionemos a perspectiva “Broker Administration Perspective“ teremos o resultado da Figura 8-9 na página 111

Figure 8-9 Criação automática do link para a perspectiva

Dica: Para tornar os botões menores e mais fáceis de enxergar: 1. Clique com o botão direito perto do botão de perspectivas. 2. Clique em Show Text Qual perspectiva escolher? A seguir apresentamos as perspectivas mais adequadas para determinadas tarefas: Table 8-2 Perspectivas para tarefas básicas Tarefa

Perspectiva

Desenvolver message flows

Broker Application Development Perspective

Desenvolver message sets

Broker Application Development Perspective

Deploy e teste de message flows

Broker Administration Perspective

Debugar message flows

Debug Perspective

Chapter 8. Instalação

111

Tarefa

Perspectiva

Gerenciar Broker Domains

Broker Administration Perspective

Configurar Publish/Subscribe

Broker Administration Perspective

Conectar e buscar definições de banco de dados

Data Perspective

Desenvolver Classes Java para uso em JavaCompute nodes

Java Perspective

8.7 Instalando fix packs As instruções desta seção descrevem como instalar um fix pack (pacotes de correção) para versões instaladas do Websphere Message Broker V6.0. Estes pacotes são baixados via Web e contém recursos adicionais à ferramenta ou correções de problemas.

8.7.1 Antes de instalar 򐂰 Verifique se você está logado com o mesmo user ID que foi utilizado para instalar o Websphere Message Broker V6.0 򐂰 Certifique-se de que todos os componentes runtime, tais como: Configuration Manager, User Name Server e todos os Brokers runtime estejam parados. 򐂰 Assegure-se de que todos os arquivos do Websphere Message Broker estejam fechados, inclusive os arquivos readme. 򐂰 Feche o Message Brokers Toolkit

8.7.2 Atualizações para componentes runtime Para instalar um fix pack siga as instruções fornecidas com o fix pack e leia o arquivo memo.ptf e os arquivos readme. O processo de atualização terá as mesmas sequências do processo de instalação inicial.

8.7.3 Atualizações para o Message Brokers Toolkit As atualizações são feitas através da ferramenta IBM Rational Product Updater que se encontra em: Start →IBM WebSphere Message Brokers 6.0 →Rational Product Updater Siga as etapas seguintes: 1. Baixe o pacote de correção para o Message Brokers Toolkit. 2. Descompacte o pacote numa pasta temporária 3. Abra o Rational Product Updater 4. Clique em Preferences →Update Sites 5. Aponte para o arquivo policy.xml que se encontra na pasta temporária criada no ítem 2. 6. Clique OK 7. Em seguida clique em Find Updates na tela principal 8. Os ítens a serem atualizados estarão selecionados como na Figura 8-10 na página 113. Então clique em Install Updates

112

WebSphere Message Broker V6.0 - Treinamento Básico

Figure 8-10 Instalando atualizações para o Message Brokers Toolkit

Chapter 8. Instalação

113

114

WebSphere Message Broker V6.0 - Treinamento Básico

9

Chapter 9.

Message Flows Neste capítulo apresentaremos o principal componente de execução do WebSphere Message Broker: o message flow. Vamos apresentar a forma de iniciar seu projeto criando um ambiente de desenvolvimento no Message Broker Toolkit.

© Copyright Intvision Solutions 2007. All rights reserved.

9.1 Visão geral do message flow A definição mais simples de message flow é: “uma sequência de passos de processamento a ser executado pelo Broker runtime quando uma mensagem de entrada é recebida”. Entretanto outras definições podem ser dadas: 򐂰 Do ponto de vista de negócio, o message flow é uma ponte de comunicação entre consumidor e provedor de serviço, pois ele faz roteamento, conversão de protocolos de transporte, transformação de formatos de mensagem e distribuição de eventos. 򐂰 Do ponto de vista de desenvolvimento, o message flow é o elemento principal de desenvolvimento, pois todos os outros artefatos desenvolvidos (message sets, database schemas) são auxiliares ao seu desenvolvimento. 򐂰 Do ponto de vista de implementação, o message flow é o elemento de deploy que pode ser iniciado, parado e apagado no Broker runtime.

Figure 9-1 Exemplo de message flow

9.1.1 O fluido A mensagem que trafega entre os nodes é chamada de assembly. Este é o “fluido” que é manipulado e transformado pelos nodes durante a execução do message flow. O assembly constitui-se de 4 árvores lógicas, a saber: 򐂰 Local Environment: esta árvore lógica é utilizada para guardar informações que podem ser utilizadas pelos nodes seguintes.

Figure 9-2 Local Environment: estrutura da árvore lógica

򐂰 Environment (também chamada de Global Environment): nesta árvore você pode gravar/ler variáveis globais, ou seja, que podem ser utilizados por qualquer node seguinte durante a execução do message flow. Apesar de não existir uma estruturação fixa para esta árvore, é recomendado que você crie suas variáveis na sub-árvore Variables conforme Figura 9-3 na página 117.

116

WebSphere Message Broker 6.0 - Treinamento Básico

Figure 9-3 Environment: exemplo de utilização

򐂰 ExceptionList: é uma árvore de exceções que é populada no momento de uma exceção no message flow.

Figure 9-4 Exception List: Estrutura da árvore lógica

A hierarquia de exceções mostram um detalhamento da exceção em diferentes níveis. Os elementos da Figura 9-4 são descritos a seguir: Table 9-1 Exception List: detalhamento dos elementos Nome

Tipo

Descrição

File

String

arquivo fonte C++

Line

Integer

Linha no arquivo fonte C++

Function

String

Nome da função C++

Type

String

Tipo do objeto fonte

Name

String

Nome do objeto fonte

Label

String

Label do objeto fonte

Chapter 9. Message Flows

117

Nome

Tipo

Descrição

Text

String

Texto adicional

Catalog

String

Nome do catálogo de erros

Severity

Integer

Severidade do erro:

1. informação 2. aviso 3. erro Number

Integer

Número da mensagem no catálogo

Insert/Type

Integer

Tipo do parâmetro da função C++

1. Boolean 2. Integer 3. Float 4. Decimal 5. Character 6. Time 7. GMT Time 8. Date 9. Timestamp 10.GMT Timestamp 11. Interval 12.BLOB 13.Bit array 14.Pointer Insert/Text

String

Valor do parâmetro da função C++

򐂰 Root: esta é a árvore lógica principal, que é populada pelo parser de um node de entrada. Um MQInput Node que processa uma mensagem MQ construirá a seguinte mensagem:

118

WebSphere Message Broker 6.0 - Treinamento Básico

Figure 9-5 Root: exemplo de estrutura de uma mensagem MQ

O elemento Properties sempre será o primeiro elemento na árvore Root e guarda informações sobre as características da mensagem, tais como: informações de como a mensagem é parseada (MessageSet, MessageType, MessageFormat), codificação (CodedCharSetId, Encoding), identificação da resposta (ReplyIdentifier), etc. Em seguida a árvore Root pode conter cabeçalhos do protocolo de transporte associado ao node de entrada. No caso da Figura 9-5 temos o cabeçalho MQMD, que é o cabeçalho de uma mensagem MQ. O corpo da mensagem será sempre o último filho da árvore Root.

9.1.2 Construindo um message flow Ao desenvolver um message flow você deverá considerar os seguintes aspectos: 򐂰 Quais nodes devo utilizar? Verifique os protocolos de transporte de entrada e saída e escolha os nodes de entrada e de saída correspondentes. Em seguida escolha os diversos nodes disponíveis para obter a função esperada do message flow. 򐂰 Quando é melhor criar mais de uma entrada para o message flow? – Quando o message flow deve fornecer as mesmas funções para diversos tipos de transportes. – Quando um message flow recebe diversos tipos de formatos de dados por filas MQ. Dessa forma pode-se incluir n MQInput Nodes, cada um com propriedades de parse de entrada diferente. – Cada node de entrada num message flow faz com que o Broker runtime execute uma thread de execução. Incluir mais de um node de entrada pode aumentar a performance do message flow. Contudo, isto não é recomendado. Ao invés disto configure instâncias adicionais do message flow nas propriedades de seu deploy. 򐂰 Quando é melhor criar um subflow? Subflows são trechos de message flows encapsulados com Input Nodes e Output Nodes. Por exemplo, quando muitos message flows necessitam do mesmo tratamento de erros, um subflow pode ser construído e adicionado em cada um deles. Chapter 9. Message Flows

119

Com a definição de subflows você ganha: – Reuso e redução de tempo de desenvolvimento – Uma forma consistente de alcançar uma função particular e aumento da manutenibilidade de seus message flows. – Flexibilidade: você pode parametrizar o subflow através de Promoted Properties. 򐂰 Onde é necessário visualizar ou gravar as informações do assembly? Em ambiente de Produção, onde o recurso de Debug não é aconselhável, você pode considerar o uso de Trace Nodes que gravem a árvore lógica Exception List na saída Catch ou Failure de um node de entrada. 򐂰 Quando você precisa validar a mensagem de entrada? Você pode utilizar uma grande variedade de parsers de entrada como XMLNS, XMLNSC, MIME, MRM, etc. No entanto, caso haja necessidade de validação da mensagem com constraints de tipagem, valores ou sequência de elementos, você deverá utilizar o parser MRM no node de entrada. 򐂰 Quando seu message flow acessa um banco de dados? Verifique a propriedade Data Source nos nodes que acessam o banco de dados. Eles apontam para o nome do ODBC configurado em seu sistema operacional. Verifique também se o usuário/senha foi configurado através do comando mqsisetdbparms 򐂰 Quando fazer a conversão de codepage? Em alguns casos você precisará transformar uma mensagem codificada em UTF-8 para uma mensagem ISO8859-1. Neste caso altere o elemento Root.Properties.CodedCharSetId e Root.Properties.Encoding para que a mensagem de saída esteja na codificação esperada.

120

WebSphere Message Broker 6.0 - Treinamento Básico

9.2 Cenário do laboratório O cenário consiste na implementação da integrações dos sistemas de uma fábrica de automóveis imaginária. Os sistemas apresentados são os seguintes: 򐂰 Sistema de estoque: Guarda as informações de estoque de carros e peças produzidas. 򐂰 Sistema de frete: Calcula o custo de frete de carros e peças. 򐂰 Cadastro de clientes: Manipula o cadastro de clientes desta fábrica. 򐂰 Serasa: Faz análise de risco de determinado cliente. 򐂰 Email Adapter/SMTP Server: Fica responsável pelo envio de e-mails. 򐂰 Usuário: Apesar de não ser um sistema, está representado aqui para simular uma aplicação que utiliza os serviços dos sistemas.

Figure 9-6 Sistemas envolvidos em uma fábrica de automóveis imaginária

O objetivo deste laboratório é disponibilizar um serviço que simplifica todos os acessos necessários aos sistemas envolvidos durante um processo de venda imaginário. É importante observar que este cenário tem efeito apenas elucidativo das capacidades do WebSphere Message Broker. O cenário foi construído como forma de utilizar o máximo possível as funcionalidade do produto. Os ítens já estarão construídos para simular serviços disponíveis: 1. Simulador de serviço de consulta de frete 2. Simulador de serviço de consulta de cliente no Serasa 3. Simulador do sistema legado que processa o cadastro de clientes. Através deste cenário implementaremos os seguintes serviços: Chapter 9. Message Flows

121

1. Serviço de consulta de estoque disponível 2. Encapsulamento do cadastro de clientes em WebService 3. Serviço de verificação de uma venda de veículo utilizando os serviços disponíveis (via simuladores) e serviços a serem implementados. 4. Serviço de realização de uma venda de veículo utilizando os serviços 2 e 3.

9.3 Verificação e preparação do ambiente Inicialmente vamos verificar o funcionamento dos simuladores que já estão disponíveis no ambiente.

9.3.1 Verificação do serviço de frete Este serviço é um WebService e possui portanto um arquivo WSDL (Web Service Description Language). Através deste WSDL iremos gerar uma requisição para o WebService de frete, conforme a seguir: 1. Abra o XMLSpy, através do botão localizado no “Quick Launch“:

Figure 9-7 Barra “Quick Launch” com XMLSpy

2. Com o XMLSpy aberto, clique em SOAP →Create new SOAP Request 3. Clique em Browse e selecione WSDL do serviço de frete que se encontra em: C:\Student\Workspace\IVS_Lab_Materiais\WSDL\fretews.wsdl 4. Clique em OK para carregar o WSDL. 5. Selecione a operação WSDL. Como existe apenas uma operação (calcularFrete), clique em OK 6. Preencha o XML de requisição como no exemplo abaixo:

1 04523-000 12345-000 1 Figure 9-8 XML de requisição à operação calcularFrete do WebService

7. Clique em SOAP →Send request to Server 8. A resposta à solicitação virá num XML como abaixo: 122

WebSphere Message Broker 6.0 - Treinamento Básico

78.22 Figure 9-9 Resposta do WebService à operação calcularFrete

9.3.2 Verificação do serviço Serasa Este serviço verifica o risco que um dado cliente tem de não arcar com seus compromissos. Sua interface também é WebService. Para verificar o seu funcionamento faremos o mesmo procedimento do ítem Verificação do serviço de frete. 1. Abra o XMLSpy, através do botão localizado no “Quick Launch“:

Figure 9-10 Barra “Quick Launch” com XMLSpy

2. Com o XMLSpy aberto, clique em SOAP →Create new SOAP Request 3. Clique em Browse e selecione WSDL do serviço serasa que se encontra em: C:\Student\Workspace\IVS_Lab_Materiais\WSDL\serasaws.wsdl 4. Clique em OK para carregar o WSDL. 5. Selecione a operação WSDL. Como existe apenas uma operação (consultarEmpresa), clique em OK 6. Preencha o XML de requisição como no exemplo abaixo:

12345 Figure 9-11 XML de requisição à operação consultarEmpresa do WebService

7. Clique em SOAP →Send request to Server 8. A resposta à solicitação virá num XML como abaixo:

Chapter 9. Message Flows

123

345 alto risco Figure 9-12 Resposta do WebService à operação consultarEmpresa

9.3.3 Verificação do serviço de cadastro O serviço de cadastro de clientes simula um sistema legado que possui interface C. Este simulador lê uma requisição escrita em C, através de uma fila MQ chamada CADASTROLEGADO.IN e grava a resposta também numa fila MQ, porém chamada de CADASTROLEGADO.OUT. 1. Abra o RFHUtil, através do botão localizado no “Quick Launch:

Figure 9-13 Barra “Quick Launch” com RFHUtil

2. Selecione a Queue Manager WBRK6_DEFAULT_QUEUE_MANAGER 3. Selecione a fila CADASTROLEGADO.IN 4. Clique no botão Read File

Figure 9-14 Configuração do RFHUtil para teste do serviço de cadastro de cliente

124

WebSphere Message Broker 6.0 - Treinamento Básico

5. Procure pelo arquivo C:\Student\Workspace\IVS_Lab_Materiais\Arquivos teste\msg1_CADASTROLEGADO.IN 6. Verifique o conteúdo do arquivo lido clicando na aba Data. Veja informações como o nome do arquivo lido e do lado direito, as configurações de apresentação dos dados desta mensagem. Como o arquivo é binário, não é possível lê-lo claramente pelas configurações indicadas abaixo.

Figure 9-15 Verificando a leitura do arquivo no RFHUtil

7. Volte para a tela inicial clicando na aba Main. 8. Clique no botão Write Queue para enviar a mensagem para a fila indicada. 9. Verifique a resposta do simulador clicando em Read Queue na fila CADASTROLEGADO.OUT conforme abaixo:

Chapter 9. Message Flows

125

Figure 9-16 Lendo a resposta do simulador através do RFHUtil

10.Veja a resposta na aba Data

9.4 Preparação do ambiente de desenvolvimento No ambiente deste laboratório já temos pronta a instalação dos componentes necessários para o desenvolvimento de message flows, são eles: 򐂰 WebSphere MQ V6.0.2 򐂰 Broker runtime versão 6.0.0.3 򐂰 Configuration Manager 6.0.0.3 򐂰 Banco de dados DB/2 8.2 + FP11 򐂰 Message Brokers Toolkit versão 6.0.2 c/ iFix 008 (Jul/2007) Nesta seção criaremos os elementos iniciais para o desenvolvimento de message flows.

9.4.1 Criação de um Workspace A workspace é a área de trabalho onde serão reunidos os diversos projetos que serão desenvolvidos durantes este laboratório. 1. Crie a pasta C:\workspace 2. Inicie o Message Brokers Toolkit através do atalho no Desktop. Digite o nome da Workspace criada no ítem 1 e em seguida clique em OK.

126

WebSphere Message Broker 6.0 - Treinamento Básico

Figure 9-17 Iniciando o Message Brokers Toolkit c/ a workspace criada

3. Feche a tela “Welcome“

9.4.2 Conexão à Configuration Manager de um Broker Domain Vamos criar uma conexão para a Configuration Manager de um Broker Domain na qual faremos o deploy dos message flows criados. 1. Selecione a perspectiva “Broker Administration” 2. Na view Domains (posição inferior esquerdo) clique com o botão direito e selecione New →Domain 3. Digite as informações necessárias conforme abaixo:

Figure 9-18 Conexão à Configuration Manager

Chapter 9. Message Flows

127

4. Clique em Next 5. Digite o nome da conexão: Desenvolvimento e clique em Finish 6. Perguntado se quer criar um projeto de Server, clique em Yes

9.4.3 Criando um Execution Group O execution group é o local onde serão implantados os message flows e os recursos necessários (dicionários, bibliotecas jar, xsl,etc). Verifique que já existe um Broker runtime chamado WBRK6_DEFAULT_BROKER neste Broker Domain e dentro dele um execution group de nome default que possuem message flows implantados. Neste execution group estão os message flows simuladores de serviços.

Figure 9-19 Conexão com a Configuration Manager

Vamos criar um segundo execution group, onde implantaremos os message flows a serem desenvolvidos. 1. Com o botão direito clique no Broker WBRK6_DEFAULT_BROKER e selecione New → Execution Group 2. Digite “desenv“ no nome do execution group a ser criado e clique em Finish

128

WebSphere Message Broker 6.0 - Treinamento Básico

Figure 9-20 Criação de um novo execution group

9.4.4 Criando um Message Flow Project O Message Flow Project é o projeto onde criaremos os message flows. Para criar um projeto deste tipo: 1. Selecione a perspectiva Broker Application Development 1. Clique em File →New →Message Flow Project 2. Digite o nome ACME_MessageFlowsProject e clique em Finish.

Figure 9-21 Criação de um novo Message Flow Project Chapter 9. Message Flows

129

9.4.5 Criando um Message Set Project O message set project é o projeto para a definição de um, e apenas um, message set. Dentro de um message set definimos o formato físico de uma mensagem e sua respectiva representação lógica. Dentro do nosso cenário, faremos trocas de mensagens XML inicialmente , e portanto o formato físico escolhido será o XML. Para criar um message set project: 1. Selecione a perspectiva Broker Application Development 2. Clique em File →New →Message Set 3. Digite as informações abaixo e clique em Next.

Figure 9-22 Criação de um novo Message Set Project

4. A seguir escolha o tipo físico das mensagens deste message set. Escolha XML documents e clique em Finish.

130

WebSphere Message Broker 6.0 - Treinamento Básico

Figure 9-23 Criação de um novo message set (continuação)

9.4.6 Importação do projeto auxiliar Vamos importar um projeto auxiliar que contém materiais necessários ao longo do laboratório. 򐂰 Escolha a perspectiva “Broker Application Development” 򐂰 Selecione File →Import 򐂰 Selecione “Existing Project into Workspace“ 򐂰 Importe o projeto C:\Student\Workspace\IVS_Lab_Materiais

Chapter 9. Message Flows

131

132

WebSphere Message Broker 6.0 - Treinamento Básico

10

Chapter 10.

Controle de transações Este capítulo provê uma visão geral sobre transações no WebSphere Message Broker.

© Copyright Intvision Solutions 2007. All rights reserved.

10.1 Transações Transação é um conceito fundamental na construção de aplicações distribuídas confiáveis. As características de uma transação, coletivamente chamadas de ACID, são: 򐂰 Atomicidade: Se bem sucedido, todas as operações acontecem; caso contrário, nenhuma operação acontece. 򐂰 Consistência: A aplicação realiza transições de estado válidas no seu término. 򐂰 Isolação: Os efeitos das operações não são “visíveis” externamente até que a transação termine sucedidamente. 򐂰 Durabilidade: Uma vez que a transação é completada, as alterações sobrevivem à falhas. Um message flow consiste em diversos nodes que realizam determinada função, por exemplo: 򐂰 Lêem de uma fila 򐂰 Atualizam uma tabela de banco de dados 򐂰 Escrevem um uma ou mais filas A característica transacional de um message flow é muito requisitada, principalmente em aplicações críticas. Isto é, o message flow deve trabalhar em coordenação. Por exemplo, se uma atualização de banco de dados falha no último passo, o message flow deve ter a capacidade de desfazer todas as alterações realizadas. Isto seria uma transação global que envolve diversos resource managers. O WebSphere Message Broker suporta transações globais.

10.1.1 Transação em message flows Um message flow suporta dois tipos de transações: 򐂰 Message flows coordenados: garante que todas as alterações nos sistemas sejam consolidados ou desfeitos juntos dentro de uma única transação. 򐂰 Message flows não-coordenados: Permite que as atualizações nos sistemas ocorram independentemente. As atualizações não são afetadas pelo sucesso ou falha geral do fluxo.

Message flows coordenados Message flows que interagem com banco de dados ou outro recurso recuperável podem ser configurados para suportar uma única transação global. A transação é consolidada quando a mensagem de entrada é processada normalmente pelo message flow. Ao contrário, a transação é desfeita caso as duas condições abaixo sejam satisfeitas: 1. A exceção é jogada durante o message flow e é tratada diretamente pelo node de entrada. 2. A saída Catch do node de entrada não está conectada. Este tipo de transação não será tratatada neste treinamento.

Message flows não-coordenados As atualizações nos recursos neste caso são gerenciados individualmente pelos respectivos Resource Managers envolvidos. Alguns Resource Managers como o WebSphere MQ

134

WebSphere Message Broker 6.0 - Treinamento Básico

permitem que haja uma transação específica dele. As transações específicas de cada Resource Manager possuem escopo limitado aos recursos pertencentes a ele. As transações específicas de Resource Managers são normalmente utilizadas quando existem um único tipo de recurso recuperável utilizado no fluxo. Por exemplo podemos citar um fluxo que contém apenas MQInput Nodes e MQOutput Nodes, que não acessem nenhum banco de dados. Estes tipos de transação não devem ser utilizadas quando existem mais de um tipo de recurso e a integridade dos dados precise ser mantida.

10.1.2 Princípios de tratamento de erros Utilize os seguintes princípios para desenvolver tratamentos de erro com controle transacional: 򐂰 Crie uma fila de backup e configure a propriedade “backout threshold“ da fila. 򐂰 Coloque a maior parte do tratamento de erro no terminal “Catch“ do MQInput Node de forma a generalizar a notificação e registro do erro. 򐂰 Coloque um Throw Node no final do fluxo “Catch“. 򐂰 Notifique alguém sobre o erro.

Chapter 10. Controle de transações

135

136

WebSphere Message Broker 6.0 - Treinamento Básico

11

Chapter 11.

Web Services Neste capítulo vamos conhecer o método de construção de um Web Service.

© Copyright Intvision Solutions 2007. All rights reserved.

11.1 Implementação Faremos o desenvolvimento de um message flow que acessa uma base de dados e retorna os dados para o requisitante do serviço. A interface deste serviço será em WebService.

11.1.1 Modelagem da mensagem de entrada Nesta seção vamos modelar a mensagem entrante do message flow. Vamos criar uma definição de mensagem XML com a seguinte estrutura:

100 Figure 11-1 Mensagem XML de entrada a ser modelada

Para criar este definição: 1. Selecione a perspectiva Broker Application Development 2. Sobre o message set project clique com o botão direito e selecione New →Message Definition File 3. Nomeie o arquivo como EstoqueMessages conforme abaixo:

Figure 11-2 Criando um novo message definition file

4. Clique em Next

138

WebSphere Message Broker 6.0 - Treinamento Básico

5. Como a interface será de WebService, vamos associar um Namespace para a mensagem de entrada selecionando o checkbox “Use target namespace“. Logo após digite a seguinte namespace: http://www.intvision.com.br/consultaEstoque

Figure 11-3 Criando um novo message definition file (continuação)

6. A seguir vamos criar a mensagem de entrada que se chamará consultarEstoque. Para fazer isso selecione Messages →Add Message

Figure 11-4 Adição de mensagem no message definition file

7. A mensagem criada será um elemento do tipo complexType1. Renomeie o complexType1 para consultarEstoqueType:

Chapter 11. Web Services

139

Figure 11-5 Renomeando um complexType

8. Agora vamos adicionar o único elemento desta mensagem que é o idProduto. Clique com o botão direito sobre consultarEstoque ou consultarEstoqueType e selecione Add Local Element.

Figure 11-6 Adicionando um elemento numa mensagem

140

WebSphere Message Broker 6.0 - Treinamento Básico

9. Altere o tipo do elemento idProduto para o simpleType xs:int.

Figure 11-7 Configurando o tipo do elemento idProduto

Nota: Observe que a coluna minOccurs e maxOccurs estão configurados como 1, ou seja, este elemento será obrigatório e deve aparecer no máximo 1 vez. 10.Crie uma segunda mensagem chamada consultarEstoqueResp e adicione o elemento quantidadeEstoque como int (xsd:int) 11. Salve o message definition file com CTRL-S

11.1.2 Importando a definição do SOAP Envelope Como este serviço possui interface WebService, a mensagem consultarEstoque criada no ítem anterior deverá ser “envelopada” num SOAP Envelope. Assim, uma chamada ao serviço deverá ter a seguinte configuração:

100 Figure 11-8 Mensagem consultarEstoque envelopada no SOAP Envelope

Chapter 11. Web Services

141

1. Clique com o botão direito sobre o ACME_MessageSet e selecione New →Message Definition File From →IBM Supplied Message 2. Selecione a mensagem soapenv11.xsd que é relativo ao SOAP Envelope V1.1 e clique em Next

Figure 11-9 Importação da modelagem da mensagem SOAP

3. Na próxima tela clique em Finish.

11.1.3 Criação do Broker Schema Nesta seção vamos criar o message flow que receberá a solicitação SOAP e fará o acesso ao banco de dados de estoque. Inicialmente, vamos criar um Broker Schema, que é um agrupamento de message flows. Na prática o Broker Schema funciona como um package Java. 1. Clique com o botão direito sobre Flows em ACME_MessageFlowsProject e selecione New →Broker Schema

142

WebSphere Message Broker 6.0 - Treinamento Básico

Figure 11-10 Criação de um Broker Schema

2. Digite br.com.acme.estoque e clique em Finish 3. Mesmo após o Broker Schema ser criado, ele aparecerá apenas quando algum message flow for adicionado a ele. Vamos criar um message flow que será adicionado a este Broker Schema. Clique com o direito sobre Flows e selecione New →Message Flow. 4. Digite o nome do flow EstoqueWS, deselecione o checkbox “Use default broker schema” e selecione o broker schema criado anteriormente.

Figure 11-11 Criação de um message flow em um determinado Broker Schema

Chapter 11. Web Services

143

5. Clique em Finish

11.1.4 Configurando o message flow Nota: Este message flow contém os nodes do Support Pac IA90: SOAP Extract Node e SOAP Envelope Node que você encontrará na paleta “Web Services“. Para mais informações sobre este Support Pac acesse: http://www-1.ibm.com/support/docview.wss?rs=849&context=SSKM8N&dc=D400&uid=swg2 4014070&loc=en_US&cs=UTF-8%E2%8C%A9=en&rss=ct849websphere O message flow EstoqueWS conterá os seguintes nodes:

Figure 11-12 Configuração final do message flow EstoqueWS

Este message flow será um WebService via HTTP e portanto, precisamos inicialmente adicionar um HTTPInput Node, localizado na paleta “HTTP“ ao lado esquerdo do editor de message flow. Vide Figure 11-13 on page 145 Na propriedade “Path suffix for URL“ digite /estoquews conforme Figure 11-13 on page 145 Nota: Quando um Broker runtime é inicializado e possui pelo menos 1 message flow com HTTPInput Node, ele iniciará um processo chamado biphttplistener.exe A porta HTTP default aberta pelo biphttplistener é a 7080. Caso haja mais de 1 Broker runtime rodando na mesma máquina será necessário alterar esta porta para evitar conflitos. No nosso laboratório o message flow será acessível pela URL absoluta: http://localhost:7080/estoquews

144

WebSphere Message Broker 6.0 - Treinamento Básico

Figure 11-13 Adição e configuração do HTTPInput Node

Para que este flow entenda como a mensagem de entrada deve ser lida é necessário que associemos um parser ao HTTPInput Node. Lembra-se da definição de mensagem de entrada construída na seção Modelagem da mensagem de entrada? Vamos utilizá-lo agora. Primeiramente verifique qual é o identificador do nosso messageSet (message set id). Para isto veja o arquivo messageSet.mset no projeto ACME_MessageSetProject conforme Figure 11-14 on page 146 Atenção: O message set id pode não ser igual ao apresentado na figura.

Chapter 11. Web Services

145

Figure 11-14 Verificação do messageSet Id

Em seguida clique sobre o HTTPInput Node e verifique a tab “Input Message Parsing“ nas propriedades deste node. Selecione as seguintes propriedades: Table 11-1 Configuração do parser de entrada Propriedade

Valor

Message Domain

MRM

Message set

Digite o messageSet Id encontrado acima

Message type

Envelope

Message format

XML1

Dica: Para facilitar a localização dos parâmetros de “Input Message Parsing“, referencie os Message Set Projects utilizados. Desta forma não será necessário fazer as etapas manuais apresentadas acima. No nosso caso, dê um clique direito sobre o projeto ACME_MessageFlowsProject e selecione “Properties“. Em “Project References“, selecione o checkbox do projeto ACME_MessageSetProject. O próximo passo é adicionar um SOAPExtract Node, que irá remover o envelope SOAP. Adicione-o a partir da paleta “Web Services“. Configure o SOAPExtract Node da seguinte forma: Table 11-2 Configuração do SOAP Extract Node

146

Propriedade

Valor

Remove envelope (remove o envelope SOAP?)

true

Envelope destination (onde o envelope SOAP extraído ficará guardado?)

$LocalEnvironment/SOAP/Envelope

WebSphere Message Broker 6.0 - Treinamento Básico

Propriedade

Valor

Destination path mode (o destino do envelope existe ou deverá ser criado?)

Create path

Route to ‘operation‘ label (Roteia conforme o WSDL operation?)

true

Adicione um Label Node a partir da paleta “Routing“ e configure-o: Table 11-3 Configuração do Label Node Propriedade

Valor

Label name

consultarEstoque

Agora vamos colocar um Compute Node (paleta “Transformation”) que extrairá as informações de estoque do banco de dados. Configure o Node: Table 11-4 Propriedade

Valor

Data source

DEFBKDB6

Transaction

Automatic

ESQL module

br.com.acme.estoque.EstoqueWS_Compute

Compute mode

Message

Treat warnings as errors

false

Throw exception on database error

true

Feito isto, dê um clique direito sobre o Compute Node e selecione “Open ESQL“. Outra alternativa é dar um duplo clique sobre o Node. O ESQL deste Compute Node terá o seguinte código default:

Chapter 11. Web Services

147

BROKER SCHEMA br.com.acme.estoque

CREATE COMPUTE MODULE EstoqueWS_Compute CREATE FUNCTION Main() RETURNS BOOLEAN BEGIN -- CALL CopyMessageHeaders(); -- CALL CopyEntireMessage(); RETURN TRUE; END; CREATE PROCEDURE CopyMessageHeaders() BEGIN DECLARE I INTEGER 1; DECLARE J INTEGER; SET J = CARDINALITY(InputRoot.*[]); WHILE I < J DO SET OutputRoot.*[I] = InputRoot.*[I]; SET I = I + 1; END WHILE; END; CREATE PROCEDURE CopyEntireMessage() BEGIN SET OutputRoot = InputRoot; END; END MODULE; Figure 11-15 Código default criado para o Compute Node

Adicione o conteúdo do arquivo EstoqueWS/EstoqueWS.esql do projeto IVS_Lab_Materiais entre a diretiva BEGIN e END; da função Main(). Salve o ESQL com CTRL-S. A saída do Compute Node criará uma mensagem do tipo calcularEstoqueResp. Porém falta envelopá-lo com o SOAP Envelope. Adicione então um SOAPEnvelope Node. Deixe-o com as propriedades default. Por último adicione um HTTPReply Node da paleta “HTTP“ para que o message flow responda à requisição HTTP. O resultado final destes procedimentos será:

148

WebSphere Message Broker 6.0 - Treinamento Básico

Figure 11-16 Configuração com os nodes adicionados

A última etapa é ligar os nodes e obter a configuração desejada. Clique sobre o terminal de saída de um node e dê um segundo clique sobre o terminal de entrada do próximo node. Para verificar o DE-PARA de ligação passe o mouse sobre ele:

Figure 11-17 Verificando as conexões entre Nodes

11.1.5 Adição de mais uma interface de entrada O WebSphere Message Broker possui grande flexibilidade para uso de protocolos de transporte diferentes. Nesta seção vamos adicionar o suporte ao WebSphere MQ, fazendo com que este serviço seja acessível também via filas, aproveitando-se então de um transporte assíncrono, seguro e confiável. O message flow modificado é apresentado abaixo:

Chapter 11. Web Services

149

Figure 11-18 Adição da interface WebSphere MQ

1. Adicione um MQInput Node com as seguintes propriedades: Table 11-5 Configurações do MQInput Node Propriedades

Valor

Basic

ESTOQUEWS.IN

Input Message Parsing/Message domain

MRM

Input Message Parsing/Message set

ACME_MessageSet

Input Message Parsing/Message type

Envelope

Input Message Parsing/Message format

XML1

2. Insira um Filter Node no final do message flow, pois agora é necessário escolher o Node de resposta 3. Clique duas vezes sobre o Filter Node e adicione o conteúdo do arquivo EstoqueWS/Filtro.esql do projeto IVS_Lab_Materiais entre as diretivas BEGIN e END; 4. Adicione um MQReply Node. 5. Reestruture o message flow do modo apresentado na Figure 11-18 on page 150

150

WebSphere Message Broker 6.0 - Treinamento Básico

11.2 Deploy 1. Alterne para a perpectiva “Broker Administration“. 2. Conecte à Configuration Manager WBRK6_DEFAULT_CONFIGURATION_MANAGER

Figure 11-19 Conexão à Configuration Manager

3. Crie um Broker Archive (BAR) que é o pacote de deploy. Nomeie-o como desenv

Figure 11-20 Criação de um Broker Archive (BAR)

4. Selecione o ícone “Add” deste desenv.bar:

Chapter 11. Web Services

151

Figure 11-21 Adicionando artefatos ao Broker Archive (BAR)

5. Selecione o message flow EstoqueWS e o message set ACME_MessageSet e salve com CTRL-S. O resultado será:

Figure 11-22 Artefatos adicionados ao Broker Archive (BAR)

152

WebSphere Message Broker 6.0 - Treinamento Básico

6. Agora clique e arraste o arquivo desenv.bar para a execution group desenv. 7. Abra o Event Log da Configuration Manager e verifique o status do deploy.

Figure 11-23 Event Log da Configuration Manager

Chapter 11. Web Services

153

11.3 Teste 11.3.1 Teste da interface HTTP Vamos validar o funcionamento do WebService que criamos na seção anterior. 1. Abra o utilitário NetTool a partir de C:\Tools\nettool\start-nettool.bat 2. Digite a URL: http://localhost:7080/estoquews 3. Digite o conteúdo da requisição tal como mostrado na Figure 11-8 on page 141 na porção esquerda do NetTool. Por conveniência, o XML também se encontra no arquivo C:\Student\Workspace\IVS_Lab_Materiais\Arquivos teste\estoquews.xml 4. Clique em Send 5. Verifique a resposta do WebService na porção direita da tela.

Figure 11-24 Testando o message flow EstoqueWS no NetTool

11.3.2 Teste da interface WebSphere MQ 1. Abra o utilitário RFHUtil 2. Selecione a fila ESTOQUEWS.IN. 3. Clique no botão Read File e escolha o arquivo C:\Student\Workspace\IVS_Lab_Materiais\Arquivos teste\estoquews.xml 4. Na tab MQMD, digite a fila ESTOQUEWS.RESP no campo Reply To Queue.

154

WebSphere Message Broker 6.0 - Treinamento Básico

Figure 11-25 Testando a interface MQ do message flow EstoqueWS

5. Volte à tab Main e clique em Write Q 6. Selecione a fila ESTOQUEWS.RESP e clique em Read Q 7. Verifique a mensagem lida na tab Data. Selecione a formatação XML em Data Format.

Figure 11-26 Verificação da mensagem de resposta

Chapter 11. Web Services

155

156

WebSphere Message Broker 6.0 - Treinamento Básico

12

Chapter 12.

Troubleshooting Este capítulo orienta e dá dicas de busca de informações para resolução de problemas.

© Copyright Intvision Solutions 2007. All rights reserved.

12.1 Logs Tanto o Message Brokers Toolkit quanto os componentes Runtime do WebSphere Message Broker criam logs para registros de ocorrências, principalmente quando algo não está indo bem. Dependendo do sistema operacional e do ponto de falha analisado, você deve selecionar o log adequado para análise.

12.1.1 Troubleshooting administrativos e de runtime Caso ocorra algum problema na inicialização/parada de algum componente runtime como Brokers runtime, Configuration Manager ou User Name Server deve-se procurar informações nos seguintes locais: 򐂰 No Windows: Abra o Event Viewer através de Control Panel →Administrative Tools → Event Viewer e verifique as ocorrências na tag Application 򐂰 No UNIX: Abra o arquivo criado pelo syslog (não configurado por default) Nota: Para configurar o syslog, coloque a seguinte linha no arquivo de configuração (/etc/syslog.conf): user.info /var/adm/user.log

Em seguida digite “touch /var/adm/user.log“ e reinicie o syslog. 򐂰 No z/OS: Verifique o log de console ou o joblog pelo address space. Além disso, alguns erros de processamento nos message flows são logados nestes mesmos locais. Veja algumas delas: 1. Fila de entrada não encontrada: Quando um message flow é executado e possui um MQInput de uma fila inexistente, o flow fica parado até a criação desta. 2. Bibliotecas obrigatórias não encontradas: Quando um message flow que possui um plugin node ou JavaComputeNode é iniciado, o Broker runtime carrega as bibliotecas de dependência. Caso o Broker runtime não as encontre, então o message flow não é iniciado. 3. ABEND (Abnormal End): Uma execution group pode terminar de forma anormal, por exemplo, na falta de recursos da máquina. Um registro disto é gerado e as informações detalhadas sobre o ABEND é registrado em outro arquivo indicado no log. Este arquivo é enviado para o diretório MQSI_WORKPATH/errors. Limpe periodicamente este diretório para relacionar rapidamente o ABEND ao problema detectado. Por último vale lembrar que os Trace Nodes que estão configurados como “Local Error Log“ também farão seus registros no mesmo local.

158

WebSphere Message Broker 6.0 - Treinamento Básico

12.1.2 Troubleshooting de desenvolvimento Quando ocorrer algum problema durante o desenvolvimento de message flows ou outros componentes necessários, verifique: 򐂰 A view “Problems“ na perspectiva “Broker Application Development“

Figure 12-1 View “Problem“ na perspectiva de desenvolvimento

򐂰 A view “Tasks“ na perspectiva “Broker Application Development“. Caso não esteja visível, clique em Window →Show View →Tasks

Chapter 12. Troubleshooting

159

Figure 12-2 View “Tasks“ na perspectiva de desenvolvimento

򐂰 A view “Alerts“ na perspectiva “Broker Administration“

Figure 12-3 View “Alerts“ na perspectiva de administração

160

WebSphere Message Broker 6.0 - Treinamento Básico

򐂰 Erros lógicos na aplicação: o message flow pode conter loops infinitos. Não deixe-se guiar pelas descrições dos nodes. Confira as configurações reais dos nodes.

12.1.3 Troubleshooting de deploy Quando é realizado o deploy, o resultado é apresentado no Event Log do Configuration Manager:

Figure 12-4 Event Log da Configuration Manager

Para obter informações adicionais utilize a variável de ambiente MQSI_SHOW_DEPLOY. Siga os seguintes passos para que sejam registradas as etapas de deploy passo-a-passo: 1. Na linha de comando digite “export MQSI_SHOW_DEPLOY=1“ 2. Reinicie o Broker runtime 3. Analise o Event Viewer/syslog

12.2 Trace Node O trace node é bastante flexível na medida em que pode ser posicionado em qualquer local dentro do message flow. Ele é utilizado para verificar o conteúdo da mensagem trafegada, das variáveis e da exceção caso ocorra. Veja um exemplo de saída de um Trace Node:

Chapter 12. Troubleshooting

161

(0x01000000):Properties = (0x03000000):MessageSet (0x03000000):MessageType (0x03000000):MessageFormat . . (0x01000000):MQMD = (0x03000000):SourceQueue (0x03000000):Transactional (0x03000000):Encoding (0x03000000):CodedCharSetId (0x03000000):Format . . (0x01000010):XML = (

( = ‘P258VC4002001' = ‘INVOICE' = 'XML'.

( = = = = =

'TESTIN' TRUE 546 1208 'MQSTR ‘

(0x01000000):MESSAGE = ( (0x02000000): = ‘ELEMENT1' ) Figure 12-5 Exemplo de saída de um Trace Node

12.3 Flow Debugger O flow debugger é a forma mais usual de analisar o funcionamento de um message flow e sua interação com outros sistemas. Além de ser possível verificar o fluxo da mensagem e seu conteúdo através dos nodes, é possível analisar o funcionamento de cada node. Veja o flow debugger em execução abaixo:

Figure 12-6 Debug de um message flow

162

WebSphere Message Broker 6.0 - Treinamento Básico

Figure 12-7 Análise do conteúdo da mensagem através do Flow Debugger

O Flow Debugger funciona através de uma conexão com o RAC (Rational Agent Controller) que por default se encontra instalado na máquina do Broker runtime. As configurações do RAC ficam no arquivo /config/serviceconfig.xml. Verifique neste arquivo quais os clientes RAC que possuem permissão para conexão. Caso não seja possível conectar ao RAC, verifique se a porta TCP default (10002) está liberada no firewall. Nota: É possível driblar um firewall entre a comunicação do Flow Debugger com o RAC. Para tanto, edite o arquivo de configuração /config/serviceconfig.xml, procure o elemento AgentControllerConfiguration e altere o valor do atributo isDataMultiplexed de false para true e o atributo filePort de 10005 para 0. Reinicie o RAC. Para que seja possível fazer uma sessão de Debug é necessário que o Broker runtime e o RAC estejam ativos. Abaixo segue uma ilustração da comunicação do Flow Debugger com o Rational Agent Controller:

Chapter 12. Troubleshooting

163

Figure 12-8 Comunicação com o RAC (Rational Agent Controller)

12.3.1 Debugando um JavaComputeNode O suporte ao debug de um JavaComputeNode não é ativo por default. Para debugar o código de um JavaComputeNode é necessário configurar o Flow Debugger e o Broker Runtime da seguinte forma: 1. Abra uma porta de debug na JVM (Java Virtual Machine) da execution group do Broker runtime. Para isso execute o comando: mqsichangeproperties -e -o ComIbmJVMManager -n jvmDebugPort -v onde é o nome do Broker runtime, é a execution group e é a porta a ser aberta para debug da JVM. 2. Na configuração de debug, configure a porta de debug criado no ítem 1).

164

WebSphere Message Broker 6.0 - Treinamento Básico

Figure 12-9 Configuração do debug para Java

3. Adicione os códigos-fonte do projeto Java (que contém a implementação do JavaComputeNode) na tab “Source“. Desta forma, o Flow Debugger saberá onde procurar o código.

Figure 12-10 Adição do projeto Java para debug

Chapter 12. Troubleshooting

165

166

WebSphere Message Broker 6.0 - Treinamento Básico

Glossário BAR. Abreviação para “message broker archive”. É um arquivo usado para armazenar message flows compilados, message sets e outros códigos para fazer deploy num execution group. BIP message. Uma mensagem de evento gerado pelo WebSphere Message Broker. É identificado por seu número,por exemplo: BIP1003. Breakpoint. Usado como um ponto de suspensão de execução de um message flow quando um Flow Debugger está ativo. Broker. Um Broker é um conjunto de processos de execução que rodam message flows Broker Administration perspective. Esta é uma perspectiva do Message Brokers Toolkit. É utilizada para administrar objetos de um broker domain. Ela também é utilizada para realizar deploy e alterar a topologia do Broker Domain. Broker Application Development perspective. É a perspectiva no Message Brokers Toolkit para criação de message flows e message sets. Broker database. É o banco de dados onde armazena-se a configuração de 1 (um) Broker. Múltiplos Brokers podem compartilhar o mesmo banco de dados. Broker domain. Um grupo de brokers que compartilham uma mesma configuração e gerenciada por um único Configuration Manager Command console. É uma interface de comandos que configura o ambiente para executar os comandos do WebSphere Message Broker. Compute node. Um node de um message flow que utiliza ESQL. Normalmente utilizado para transformação de mensagem Configuration Manager. Armazena a configuração de um Broker Domain gerenciado por ele e realiza ações de deploy entre o Toolkit e os Brokers. Configuration Manager Proxy API.

Uma API para acessar um Configuration Manager e realizar operações administrativas. Database node. Um node de message flow para realizar ações em banco de dados utilizando ESQL. Não altera a mensagem. DB2 Enterprise Server. Um banco de dados que é suportado para uso do Broker Database e é fornecido com o WebSphere Message Broker. Dead letter queue. Uma fila do WebSphere MQ queue que guarda mensagens que foram repostadas pelo message flow. Debug perspective. É a perspectiva utilizada no Message Brokers Toolkit para debugar message flows e Java, ESQL or mapeamentos associados a ele. Default Configuration Wizard. Um wizard que cria um Broker Domain simples para verificar a instalação do WebSphere Message Broker installation. A configuração criada por ele pode ser usada para fins de teste e utilização dos exemplos fornecidos. ESQL. ESQL significa “Extended Structured Query Language” e é usado na transformação de mensagens em message flows. É também utilizado para realizar operações em banco de dados. Execution groups. Um execution group representa uma coleção de message flows dentro de um Broker. Java. Uma linguagem de programação orientada a objetos e utilizada para programação de um JavaCompute node ou user defined nodes no Message Brokers Toolkit. JavaCompute node. Um node de um message flow para transformar e rotear mensagens usando Java. Também é usado para manipular banco de dados utilizando Java. Mapping. Um método de transformação de mensagem utilizando drag-and-drop de

167

referências para message definitions e database definitions. Mapping node. Um node de um message flow que utiliza mappings para construir uma mensagem de saída usando outras mensagens ou banco de dados. Message Brokers Toolkit. Uma interface gráfica para realizar o desenvolvimento, teste, deploy e debug de message flows. Message Definition. Define a estrutura lógica e física das mensagens. Message Domain. É a propriedade que pode ser configurada no Node de entrada para indicar o tipo de mensagens que o message flow espera processar e seleciona o parser apropriado. Exemplos de Message Domain são XMLNS e MRM. Message Flow Debugger. Uma ferramenta para visualizar o caminho das mensagens dentro de um message flow, podendo ver e alterar o conteúdo das mensagens enquanto são processadas.

ODBC drivers for Cloudscape. Driver ODBC para conectar ao banco de dados embutido no Configuration Manager. São utilizados para aproveitar essa base como Broker Database. Queue manager. Um queue manager é um sistema que fornece serviços de enfileiramento para aplicações. É utilizado para a comunicação entre os componentes runtime do WebSphere Message Broker. Rational Agent Controller. É usado para debug de message flow no Message Brokers Toolkit. Deve ser instalado na mesma máquina do Broker que será debugado. System Log. Um log visível no Windows Event Viewer que mostra informações sobre softwares rodando como Windows Services incluindo os componentes runtime do WebSphere Message Broker components. Terminal. Cada node de um message flow contém diversos terminais. Mensagens são enviadas para diferentes terminais dependendo dos resultados de processamento do node.

Message sets. Message sets contém definições das mensagens que serão processados pelo Broker. As message definitions associadas a um message set contém informações de como é a estrutura lógica e física das mensagens.

User Name Server. Usado para fornecer autenticação e segurança para publish/subscribe num broker domain.

MQInput node. Um node de message flow para ler uma mensagem de uma fila WebSphere MQ.

WebSphere Event Broker. Usado para distribuição e roteamento de mensagem de diferentes aplicações. É frequentemente usado na mensageria publish/subscribe

MQOutput node. Um node de message flow para postar uma mensagem numa fila WebSphere MQ mqsideploy. Um comando do Command Console para realizar deploy de arquivos BAR. mqsilist. Um comando executado no Commando Console para listar todos os componentes runtime do WebSphere Message Broker de uma máquina. mqsistart. Um comando executado no Command Console para iniciar um componente como um Broker ou Configuration Manager. mqsistop. Um comando executado no Command Console para parar um componente runtime como Broker ou Configuration Manager.

WebSphere Message Broker. Fornece storage, transformação e enriquecimento de dados em adição às funcionalidades do WebSphere Event Broker. WebSphere MQ. Uma aplicação de mensageria que é a base para todo o produto. Todas as comunicações entre os componentes do WebSphere Message Broker são realizadas via WebSphere MQ. WebSphere MQ Explorer. Uma interface gráfica para administração de componentes WebSphere MQ como filas e canais. Windows Event Viewer. Uma ferramenta do Windows para visualizar conteúdo de logs de aplicação e sistema.

168

Índice Remissivo A acesso a banco de dados 86 ACID 134 agregação 73, 92 Arquivo messageSet.mset 145 assembly 116 B backout threshold 135 balanceamento de carga 29 batch 43 BPEL 32 Broker Domain 76 C cabeçalho DLQ 47 fila de transmissão 45 MQMD 53 CICS 77 client channel 49 comunicação assíncrona 43 Conexão à Configuration Manager 127 Configuration Manager 75 Configuration Manager Proxy 94 controlar a ordem de processamento 89 conversão de codepage 42, 120 Criação da Fila de Transmissão 64 Criação da Queue Manager 59 Criação de Filas locais 61 Criação de um Workspace 126 Criação do Broker Schema 142 Criando um Execution Group 128 Criando um Message Flow Project 129 Criando um Message Set Project 130 Custom Wire Format 95 Customização de Plug-in 91 D Database Schemas 88

DB2 101 debug gráfico 88 E EAI 9 Edge 29 EDI 29 EIS 29, 92 Environment 116 ESQL 85 Event Log do Configuration Manager 161 ExceptionList 117 Execution groups 75 F fire-and-forget 73, 91 fix pack 112 G grupo mqm 104 I importadores 83 Importando a definição do SOAP Envelope 141 Input Message Parsing 146 integração de sistemas 72 J J2EE 28, 77 Java debugger 87 JCA 29 JMS 79 JMS Providers 80 JVM 164 L LDAP 91 Linha de comando 58 Listener 64 listener 80 Local Environment 116 Local Error Log 158

169

lógica de negócio 73 lookup em memória 89 M mapeamento drag-and-drop 87 maxOccurs 141 mensageria 73 Message Brokers Toolkit 100 message channel 49 message dictionary 75 Message Domain 84 message set id 145 middleware 42 MIME domain 95 minOccurs 141 MQ Explorer 58, 94 Multicast 78 P PCF 47 Perspectivas 110 perspectivas 111 ponto-a-ponto 72 Properties 119 publish/subscribe 73, 76, 92 publish-subscribe 73

syslog 158 T Tagged Delimited String Format 95 Testanto as filas criadas 62 transação global 134 Tratamento de falhas 51 U User Name Server 76 V validação da mensagem 84 view “Alerts“ 160 view “Problems“ 159 view “Tasks“ 159 W WebSphere MQ Everyplace 78 X XML domain 95 XML Wire Format 95 XMLNS domain 95 XMLNSC domain 95 XSLT 88

Q QoS 29, 93 R Rational Agent Controller 101, 163 Real-time Transport 79 request-reply 73 Root 118 S SCADA 79 Sendmail 91 Server Connection 52 sistemas legado 72 SOAP Envelope 141, 142 standard-based 73

170