WebSphere Message Broker, Versão 8.0.0.5 Sistemas operacionais: AIX, HP-Itanium, Linux, Solaris, Windows, z/OS

Consulte as informações sobre a versão mais recente do produto em IBM Integration Bus, Versão 9.0

O Broker Implementa uma Nova Interface de Serviço da Web

Neste cenário, o broker implementa uma nova interface de serviço da Web. O WSDL para o serviço da Web é gerado a partir de um conjunto de mensagens e disponibilizado aos clientes. Um fluxo de mensagens baseado neste WSDL e no conjunto de mensagens recebe um pedido e, em seguida, constrói uma mensagem de resposta usando os dados obtidos de um aplicativo não de serviço da Web existente.

O diagrama a seguir mostra um fluxo de mensagens sendo criado a partir de uma definição de interface (por exemplo, um arquivo de cabeçalho) de um aplicativo existente que não está acessível atualmente como um serviço da Web. Um arquivo WSDL é gerado a partir de um conjunto de mensagens e exportado para utilização por um cliente de serviço da Web. Um fluxo de mensagens que usa o conjunto de mensagens e o WSDL é criado para chamar o aplicativo. O fluxo de mensagens e o conjunto de mensagens são implementados em um broker, fornecendo uma interface de serviço da Web para o aplicativo original.

O diagrama é descrito no texto circundante.

Chave para os símbolos:

Este diagrama descreve os símbolos que são usados nos outros diagramas, que não são descritos aqui porque os diagramas possuem suas próprias descrições.

Esse cenário às vezes é referido como uma fachada de serviço da Web. O design da interface de serviços da Web tipicamente envolve algum reagrupamento, restrição ou aprimoramento da interface existente e não é limitado por uma definição WSDL existente.

Utilizações Possíveis

Etapas de Design

  1. Crie um conjunto de mensagens para as mensagens de negócios, possivelmente importando uma definição de interface como um arquivo de cabeçalho C ou arquivo de cabeçalho.
  2. Gere uma definição WSDL a partir do conjunto de mensagens.
  3. Utilize um toolkit SOAP como o Rational Application Developer para criar um cliente de serviços da Web apropriado com base no WSDL.
  4. Desenvolva um fluxo de mensagens para implementar o serviço da Web.

No Tempo de Execução

Seu fluxo de mensagens recebe um pedido de serviço da Web, converte-o em um formato esperado pelo aplicativo existente e chama o aplicativo existente. A resposta do aplicativo existente é convertida em uma resposta de serviço da Web válida.

Exemplo 1

Neste exemplo, um fluxo de mensagens existente é modificado para fornecer um serviço da Web. Se o fluxo de mensagens existente modelar dados em um conjunto de mensagens, uma definição de WSDL poderá ser gerada a partir desse conjunto de mensagens e disponibilizada aos clientes.

A maioria dos fluxos de mensagens que atualmente utilizam o WebSphere MQ para entrada ou saída pode ser adaptada para suportar serviços da Web como um protocolo adicional ou substituição.

Seguem padrões típicos de fluxos de mensagens. Em cada caso, os nós de entrada e resposta substituem ou complementam os nós MQInput e MQOutput originais. Entende-se que a parte principal do fluxo faz algum processamento útil.
  • Usando os nós SOAPInput e SOAPReply:
    O Diagrama Mostra um Fluxo de Mensagens que Fornece um Serviço da Web Usando os Nós SOAPInput e SOAPReply.
  • Usando os nós HTTPInput e HTTPReply:
    O diagrama mostra um fluxo de mensagens que fornece um serviço da Web usando os nós HTTPInput e HTTPReply.

Se usar o domínio SOAP, a forma da árvore lógica será diferente do domínio original e você precisará levar isso em conta no fluxo de mensagens. Se usar os nós HTTP com o domínio original, a forma da árvore lógica não será alterada. Para obter informações sobre como escolher o domínio, consulte WebSphere Message Broker e Serviços da Web.

Detalhes de HTTP
Se você utilizar os nós HTTP, é possível configurar o nó HTTPReply para gerar um conjunto de cabeçalhos HTTP padrão para a mensagem de resposta enviada ao cliente. A geração de um conjunto de cabeçalhos HTTP padrão reduz as modificações que você deve fazer para converter o fluxo de mensagens, de um que processa mensagens do WebSphere MQ para um fluxo que processa mensagens HTTP.

Exemplo 2

Nesse exemplo, um fluxo de mensagens é criado para fornecer acesso assíncrono a um aplicativo WebSphere MQ.

Seguem padrões típicos de fluxos de mensagens. Em cada caso, o fluxo recebe o pedido de serviço da Web e constrói a resposta usando dados retornados do aplicativo no WebSphere MQ.
  • Usando dois fluxos de mensagens com os nós SOAPInput e SOAPReply:
    O diagrama mostra dois fluxos de mensagens que fornecem acesso assíncrono a um aplicativo WebSphere MQ usando os nós SOAPInput e SOAPReply.
  • Usando dois fluxos de mensagens com os nós HTTPInput e HTTPReply:
    O diagrama mostra dois fluxos de mensagens que fornecem acesso assíncrono a um aplicativo WebSphere MQ usando os nós HTTPInput e HTTPReply.

Em cada caso, o primeiro fluxo de mensagens recebe pedidos de entrada de um cliente de serviço da Web. O nó Compute1 transforma o pedido e um nó MQOutput envia o pedido modificado ao aplicativo existente.

No segundo fluxo de mensagens, um nó MQInput recebe a resposta do aplicativo. O nó Compute2 então transforma a mensagem e propaga a mesma para um nó de resposta que responde ao cliente de serviço da Web original.

O nó Compute1 também deve salvar algumas informações de correlação a serem recuperadas pelo nó Compute2, assegurando que as respostas do aplicativo WebSphere MQ sejam retornadas ao cliente que enviou o pedido original.

Detalhes de HTTP

Usando os nós HTTPInput e MQOutput como a mensagem de saída e os nós MQInput e HTTPReply como a mensagem de resposta:

O diagrama mostra como é possível usar os nós HTTPInput e MQOutput como a mensagem de saída e os nós MQInput e HTTPReply como a mensagem de resposta.

Uma maneira de preservar as informações de correlação é para o nó Compute1 codificar o ID de correlação na mensagem de saída. (Como alternativa, o identificador pode ser armazenado em um banco de dados). Os nós SOAPInput e HTTPInput colocam o identificador como um campo na árvore ambiente local e o nó Compute1 pode ler e armazenar este valor. O local do identificador se difere entre os nós SOAPInput e HTTPInput, conforme descrito nas seções seguintes.

Nós SOAP

O nó Compute2 lê o identificador de resposta SOAP da mensagem e configura LocalEnvironment.Destination.SOAP.Reply.ReplyIdentifier usando este valor. O nó SOAPReply usa o identificador de resposta para assegurar que a mensagem atinja o cliente HTTP correto. No módulo ESQL para o nó Compute1, inclua uma instrução de código como a seguinte:
SET OutputRoot.XMLNS.A.MessageID = 
CAST(InputLocalEnvironment.Destination.SOAP.Reply.ReplyIdentifier AS CHARACTER);
No módulo ESQL para o nó Compute2, inclua uma instrução de código como a seguinte:
SET OutputLocalEnvironment.Destination.SOAP.Reply.ReplyIdentifier = 
CAST(InputRoot.XMLNS.A.MessageID AS BLOB);

Nós HTTP

O nó Compute2 lê o identificador de pedido de HTTP da mensagem e configura LocalEnvironment.Destination.HTTP.RequestIdentifier usando este valor. O nó HTTPReply utiliza o identificador de pedido para assegurar que a mensagem atinja o cliente HTTP correto. No módulo ESQL para o nó Compute1, inclua uma instrução de código como a seguinte:
SET OutputRoot.XMLNS.A.MessageID = 
CAST(InputLocalEnvironment.Destination.HTTP.RequestIdentifier AS
CHARACTER);
No módulo ESQL para o nó Compute2, inclua uma instrução de código como a seguinte:
SET
OutputLocalEnvironment.Destination.HTTP.RequestIdentifier = 
CAST(InputRoot.XMLNS.A.MessageID AS BLOB);
Avisos | Marcas Registradas | Downloads | Biblioteca | Suporte | Feedback

Copyright IBM Corporation 1999, 2014Copyright IBM Corporation 1999, 2014.

        
        Última atualização:
        
        Última atualização: 2015-02-28 18:28:35


Tópico de ConceitoTópico de Conceito | Versão 8.0.0.5 | ac34540_