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 Chama um Serviço da Web Existente

Neste cenário, o broker chama uma implementação de serviço da Web existente. O WSDL para o serviço da Web já existe e é importado para criar um conjunto de mensagens.

Um fluxo de mensagens baseado nesse conjunto de mensagens envia uma solicitação de serviço da web e recebe a resposta, por exemplo, usando um nó SOAPRequest.

O diagrama mostra um serviço da Web existente e o WSDL que o descreve. O WSDL é importado para criar um conjunto de mensagens. Um fluxo de mensagens que usa o conjunto de mensagens é criado para chamar o serviço da Web e ambos são implementados em um broker.

Chave para os símbolos:

O 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.

Utilizações Possíveis

Etapas de Design

  1. Importe o WSDL para criar um conjunto de mensagens contendo definições para as mensagens SOAP descritas pelo WSDL.
  2. Crie um fluxo de mensagens para chamar o serviço da Web. Se o domínio SOAP for usado, o fluxo de mensagens usará um nó SOAPRequest, um nó SOAPAsyncRequest ou um nó SOAPAsyncResponse. Os nós são configurados usando o WSDL importado na Etapa 1. Se necessário, você pode criar um fluxo modelo a partir do início, soltando o WSDL em uma tela do editor de fluxo de mensagens em branco. Se você usar o domínio SOAP, deverá criar o fluxo de mensagens usando os nós de transporte e um domínio XML ou MIME. Por exemplo, se a ligação de WSDL especificar o transporte HTTP, e a mensagem de pedido for SOAP, você poderá usar um nó HTTPRequest com o domínio XMLNSC. É possível, então, configurar o nó manualmente com as informações do terminal para o serviço da Web.
  3. Construa um arquivo archive do intermediário para implementação. O arquivo bar contém seu fluxo de mensagens e o conjunto de mensagens que contém o WSDL importado. O domínio SOAP sempre requer que a WSDL seja implementada, porque as mensagens são verificadas com relação a ela no tempo de execução; além disso as informações de WSDL são incluídas na árvore lógica. O conjunto de mensagens inclui definições de Esquema XML que podem ser usados para validação de mensagem nos domínios SOAP, XMLNSC ou MRM.

No Tempo de Execução

Seu fluxo de mensagens cria um pedido de serviço da Web formatado corretamente, chama o serviço da Web e analisa a resposta do serviço da Web. Se você usar o domínio SOAP, seu fluxo de mensagens usará o modelo de árvore lógica SOAP. Se você não usar o domínio SOAP, seu fluxo de mensagens usará a árvore lógica para seu domínio selecionado; por exemplo, você usa o domínio MIME se suas mensagens de serviço da Web usarem SOAP com Anexos.

Exemplo 1

Intermediário do Serviço da Web
Neste exemplo, um aplicativo cliente utiliza um serviço da Web chamado Account que é disponibilizado por outra organização. O cliente é amplamente distribuído em sua empresa. O cliente utiliza uma operação chamada getBalance, mas o serviço Account está sendo modificado para alterar a definição da operação getBalance. É possível construir os fluxos de mensagens para fornecer uma interface para o serviço Account. em vez de modificar o cliente. Os fluxos de mensagens podem chamar o serviço Account para fazer o trabalho e o novo serviço da Web delega para o serviço da Web original. O cliente agora pode continuar usando o serviço Account, usando os novos fluxos de mensagens.
Nos exemplos de padrões de fluxo de mensagens típicos mostrados aqui, o nó de pedido intermediário chama o serviço Account:
  • Usando os nós SOAPInput, SOAPRequest e SOAPReply:
    O diagrama mostra um fluxo de mensagens que fornece uma interface para o serviço de Conta usando os nós SOAPInput, SOAPRequest e SOAPReply.
  • Usando os nós SOAPInput, SOAPAsyncRequest, SOAPAsyncResponse e SOAPReply:
    O diagrama mostra dois fluxos de mensagens que fornecem uma interface para o serviço de Conta usando os nós SOAPInput, SOAPAsyncRequest, SOAPAsyncResponse e SOAPReply.
  • Usando os nós HTTPInput, HTTPRequest e HTTPReply:
    O diagrama mostra um fluxo de mensagens que fornece uma interface para o serviço de Conta usando os nós HTTPInput, HTTPRequest e HTTPReply.

Nos fluxos de mensagens no exemplo, Compute1 modifica a mensagem getBalance original conforme requerido pelo serviço Account modificado, enquanto Compute2 restaura a mensagem de resposta para o formato original. Se você tiver importado ou gerado WSDL, terá um modelo de mensagem para a operação getBalance. Se você tiver um modelo de mensagem definido para a operação getBalance, poderá utilizar os nós Mapeamento em vez dos nós Compute.

Detalhes de HTTP

se você utilizar os nós de transporte HTTP, conforme mostrado no exemplo, é possível configurar o nó HTTPRequest para gerar cabeçalhos HTTP dos cabeçalhos recebidos pelo nó HTTPInput. Esta configuração permite que cookies e outros cabeçalhos específicos do aplicativo sejam transmitidos através do fluxo de mensagens. O nó HTTPReply pode ser utilizado para extrair cabeçalhos da resposta de serviço da Web, para retornar ao cliente de origem. Para criar esta configuração, selecione Gerar cabeçalhos HTTP padrão a partir de em ambos os nós, HTTPRequest e HTTPReply. Geralmente, não é necessário que a mensagem de pedido original gere a resposta ao cliente e você pode selecionar Substituir mensagem de entrada por resposta de serviço da Web no nó HTTPRequest. Se você desejar preservar dados do pedido de entrada, poderá armazenar isto no LocalEnvironment em Compute1 e recuperá-lo em Compute2 para inclusão na resposta.

Exemplo 2

Utilizando um Serviço da Web
Neste exemplo, um fluxo de mensagens do WebSphere MQ implementa um processo para o departamento de Recursos Humanos de sua empresa. Como parte desse processamento, o fluxo de mensagens chama um serviço da Web para recuperar números de IDs de funcionários. Os números de IDs de funcionários são mantidos no diretório de funcionários da empresa que é acessado através de um serviço da Web.
Nos exemplos de padrões de fluxo de mensagens típicos mostrados aqui, o nó de pedido broker recupera o ID do funcionário:
  • Usando os nós MQInput, SOAPRequest e MQOutput:
    Este diagrama mostra um fluxo de mensagens que chama um serviço da Web usando os nós MQInput, SOAPRequest e MQOutput.
  • Usando os nós MQInput, SOAPAsyncRequest, SOAPAsyncResponse e MQOutput:
    Este diagrama mostra dois fluxos de mensagens que chamam um serviço da Web usando os nós MQInput, SOAPAsyncRequest, SOAPAsyncResponse e MQOutput.
  • Usando os nós MQInput, HTTPRequest e MQOutput:
    Este diagrama mostra um fluxo de mensagens que chama um serviço da Web usando os nós MQInput, HTTPRequest e MQOutput.

Nos fluxos de mensagens do exemplo, Compute1 prepara a mensagem de pedido de serviço da Web e Compute2 processa a resposta. Por exemplo, incorporando o ID do funcionário em outra mensagem. Se você tiver um modelo de mensagem definido, poderá utilizar nós Mapeamento em vez de nós Compute nestes exemplos.

Detalhes de HTTP

Se você utilizar os nós de transporte HTTP, conforme mostrado o exemplo, você geralmente desmarca Substituir Mensagem de Entrada por Resposta de Serviço da Web nas propriedades do nó HTTPRequest. A resposta do servidor de diretório corporativo é colocada em um local temporário na árvore de mensagens. O local temporário é especificado em Local da Mensagem de Resposta na propriedade da árvore no mesmo nó. Em Compute2, é possível codificar ESQL para recuperar o resultado e atualizar a mensagem final.

Esse Diagrama Mostra que É Possível Colocar e, em seguida, Recuperar a Resposta de Serviço da Web em um Local Temporário na Árvore de Mensagens.

Utilizar o domínio SOAP para esses cenários é preferencial. Para obter informações adicionais sobre a escolha de um domínio para serviços da Web, consulte WebSphere Message Broker e Serviços da Web.

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 | ac34530_