O Intermediário Chama um Serviço da Web Existente

Neste cenário, o intermediário chama uma implementação de serviço da Web existente.

O diagrama mostra um arquivo WSDL associado de serviço da Web importado para um conjunto de mensagens. O conjunto de mensagens é implementado para um fluxo em um intermediário.

Chave para Símbolos:

O diagrama descreve os símbolos utilizados em outros diagramas e não é descrito aqui porque cada um desses diagramas possui 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 transporte do serviço da Web for HTTP, será utilizado um nó HTTPrequest. Se o transporte do serviço da Web for JMS, serão utilizados nós JMS ou do WebSphere MQ apropriados.

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.

Exemplo 1

Neste exemplo, o intermediário age como um mediador para o serviço da Web.

  1. Crie um fluxo de mensagens com os nós: HTTPInput, HTTPRequest e HTTPReply.
  2. O cliente de serviços da Web gera um pedido de serviço da Web. Ele é direcionado para o nó HTTPInput pelo intermediário.
  3. O fluxo de mensagens processa a mensagem de alguma maneira.
  4. O nó HTTPRequest envia um pedido para o serviço da Web original e recebe a resposta.
  5. O fluxo gera uma resposta do serviço da Web e coloca-a no nó HTTPReply. A resposta pode ser baseada na resposta completa ou parcial recebida pelo nó HTTPRequest.
  6. O intermediário envia a resposta para o cliente de serviço da Web.

Se outro aplicativo ativado para o WebSphere MQ exigir as informações em um formato diferente, o fluxo de mensagens poderá organizar a mensagem para ser propagada primeiro para um nó MQOutput para transmissão para este aplicativo antes de prosseguir para o final do fluxo e do nó HTTPReply que envia a resposta do serviço da Web esperada. Os nós Compute apropriados seriam requeridos para transformar a mensagem (se necessário) e para manipular os cabeçalhos da mensagem (ex. incluindo um cabeçalho MQMD).

Exemplo 2

Neste exemplo, o intermediário fornece auditoria para um serviço da Web.

  1. Você projeta um fluxo de mensagens que inclui um nó HTTPInput conectado a um nó Warehouse.
  2. A mensagem de entrada recebida do cliente de serviço da Web é armazenada no banco de dados pelo nó Warehouse.
  3. O nó Warehouse transmite a mensagem para um nó HTTPRequest, que interage com o serviço da Web.
  4. Quando a resposta for recebida, o nó HTTPRequest propagará a resposta para o nó HTTPReply.
  5. O nó HTTPReply gera a resposta para o cliente de serviço da Web.

Exemplo 3

O fluxo WebSphere MQ interage com um serviço da Web
Você cria um fluxo de mensagens WebSphere MQ que acessa um serviço da Web em uma conexão HTTP. Por exemplo, você pode criar um fluxo de mensagens que suporte um processo para o departamento de Recursos Humanos da empresa. O processo deve recuperar os números de ID do funcionário e aprimorar a mensagem com essas informações. IDs de funcionários são mantidos no diretório de funcionários da empresa, que é acessado por meio de uma serviço da Web.
Isso representa um fluxo de mensagens com os nós MQInput, Compute1, HTTPRequest, Compute2, MQOutput. O nó HTTPRequest interage com o Corporate Directory Server em uma conexão HTTP.

Nesse cenário, você normalmente limpa a caixa de opções Substituir Mensagem de Entrada pela Resposta do Serviço da Web nas propriedades do nó HTTPRequest e coloca a resposta do servidor de diretório corporativo em um local temporário na árvore da mensagens especificada na propriedade Local da Mensagem de Resposta na Árvore no mesmo nó. No Compute2, você codifica ESQL para descompactar o resultado e aumenta a mensagem final conforme apropriado.

Exemplo 4

O fluxo de mensagens funciona como um serviço da Web intermediário
Você projeta um fluxo de mensagens que interage com um serviço da Web que atualizou sua interface em nome dos clientes do serviço da Web que não estão cientes da nova interface. O novo fluxo de mensagens permite que clientes mais antigos acessem o servidor utilizando as novas interfaces, sem atualizarem suas interfaces.
Isso representa um fluxo de mensagens com os nós HTTPInput, Compute1, HTTPRequest, Compute2, HTTPReply. O nó HTTPRequest interage com o Corporate Directory Server em uma conexão HTTP.

O ESQL de codificação em Compute1 para mapear o pedido do cliente para um pedido do servidor e em Compute2 para mapear a resposta do servidor para a resposta do cliente. Você pode definir essas mensagens de pedido e de resposta no domínio MRM para simplificar a transformação de um formato para outro.

Você pode configurar o nó HTTPRequest para gerar os cabeçalhos HTTP recebidos pelo nó HTTPInput, permitindo que os cabeçalhos de cookies e de outros aplicativos específicos sejam transmitidos. O nó HTTPReply pode fornecer uma tarefa equivalente para extrair os cabeçalhos da resposta do serviço da Web para que sejam retornados ao cliente de origem. Se desejar que isso seja feito, selecione a caixa de opções apropriada Gerar Cabeçalhos HTTP Padrão de..... nos nós HTTPRequest e HTTPReply.

Na maioria dos cenários, o pedido original não tem valor, e você só precisa da resposta do serviço para poder gerar a mensagem de resposta do cliente. Sendo assim, selecione a propriedade Substituir Mensagem de Entrada pela Resposta do Serviço da Web no nó HTTPRequest. Se desejar preservar quaisquer dados da resposta de entrada, você poderá armazená-los no Ambiente Local no Compute1 e recuperá-los no Compute2 para inclusão na resposta.

Conceitos relacionados
Serviços da Web, WSDL e Fluxos de Mensagens
O Intermediário Implementa uma Nova Interface de Serviço da Web
O Intermediário Implementa uma Interface de Serviço da Web Existente
O Intermediário Implementa Interface Não do Serviço da Web para Novo Serviço da Web
Avisos | Marcas Registradas | Downloads | Biblioteca | Suporte | Feedback
Direitos Autorais IBM Corporation 1999, 2006 Última Atualização: 1 Sep 2006
ac34530_