Trabalhando com Cenários de Exemplo de Serviço da Web

Esta seção descreve quatro cenários nos quais os clientes de serviços da Web interagem com . Esses cenários não compõem uma lista definitiva, mas representam alguma das opções suportadas para os aplicativos de serviços da Web.

O fluxo interage com um serviço da Web
Você cria um fluxo de mensagens 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. Os IDs de funcionários são mantidos no diretório do funcionário da empresa que pode ser acessado por meio de um serviço da Web.
Isso representa um fluxo de mensagens com nós MQInput, Compute1, HTTPRequest, Compute2 e MQOutput.  O nó HTTPRequest interage com o Servidor de Diretório Corporativo por meio de 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 mensagem 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.

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. Esse novo fluxo de mensagens permite que os clientes antigos acessem o servidor utilizando novas interfaces sem atualizar suas próprias interfaces.
Isso representa um fluxo de mensagens com nós HTTPInput, Compute1, HTTPRequest, Compute2 e HTTPReply. O nó HTTPRequest interage com o Servidor de Diretório Corporativo por meio de 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.

O fluxo de mensagens é chamado como um serviço da Web
Você modifica o design de um fluxo de mensagens existente para interagir com os clientes do serviço da Web por meio de HTTP. O fluxo de mensagens existente obtêm uma mensagem de entrada bem definida, e o cliente pode utilizar o WSDL exportado da ferramenta ao chamar o fluxo de mensagens.

A maioria dos fluxos de mensagens que atualmente utilizam para entrada ou saída pode ser adaptada para utilizar HTTP como um protocolo adicional ou de substituição.


Isso representa um fluxo de mensagens com nós HTTPInput, Compute1, DataUpdate, Compute2 e HTTPReply.

Você pode modelar a mensagem de entrada no domínio MRM e gerar WSDL a partir do modelo ou processar uma mensagem de domínio XML ou XMLNS genérica. Se você definiu a mensagem no domínio MRM, será possível configurar o nó HTTPInput para validar a mensagem de entrada. O nó gera uma exceção se a mensagem não estiver em conformidade com o modelo.

Você pode configurar o nó HTTPReply para gerar um conjunto de cabeçalhos HTTP padrão para a mensagem de resposta enviada ao cliente. Isso reduz as modificações que devem ser feitas para converter o fluxo de mensagens de um processamento de mensagens para um fluxo que processa mensagens HTTP.

O fluxo de mensagens fornece acesso ao aplicativo
Você projeta dois fluxos de mensagens que recebem pedidos de e enviam respostas para clientes do serviço da Web e interagem com um aplicativo existente que não foi adaptado para comunicações por meio de HTTP.

O primeiro fluxo de mensagens recebe pedidos de entrada de clientes do serviço da Web em um nó HTTPInput. Ele inclui um nó Compute para transformar os pedidos de algum modo e um nó MQOutput para enviar o pedido modificado ao aplicativo .

O segundo fluxo de mensagens recebe a resposta do aplicativo que está em um nó MQInput. A mensagem é transmitida ao nó Compute que a transforma e a propaga para um nó HTTPReply que envia essa mensagem como uma resposta ao cliente original do serviço da Web.

Embora as transformações concluídas pelo nó Compute possam ser triviais, o código ESQL, no primeiro, deve salvar as informações de estado de HTTP recuperadas pelo segundo para garantir que as respostas do aplicativo sejam retornadas ao cliente que enviou o pedido original.


Isso representa dois fluxos de mensagens; o primeiro tem os nós HTTPInput, Compute1 e MQOutput. O segundo tem os nós MQInput, Compute2 e HTTPReply. O nó MQOutput coloca uma mensagem em uma fila do WebSphere MQ atendida por um aplicativo existente, que coloca suas respostas em uma fila de entrada atendida pelo nó MQInput.

O primeiro fluxo de mensagens recebe a mensagem, executa as transformações necessárias e codifica o identificador de pedido HTTP na mensagem de saída. (O identificador de pedido também pode ser armazenado em um banco de dados, se você preferir). O nó HTTPInput fornece o identificador de pedido, como um campo na árvore Ambiente Local, chamado Destination.HTTP.RequestIdentifier, e Compute1 pode ler e armazenar esse valor.

O segundo fluxo de mensagens recebe a mensagem de resposta e transforma-a de volta para o formato da mensagem do cliente. Compute2 lê o identificador de pedido HTTP da mensagem e define LocalEnvironment.Destination.HTTP.RequestIdentifier utilizando esse valor. O nó HTTPReply utiliza o identificador de pedido para garantir que a mensagem seja enviada ao cliente HTTP correto.

A implementação desse cenário requer a manipulação correta de MQMD. As mensagens recebidas em uma mensagem em HTTP devem ter um MQMD incluído para serem enviadas ao nó MQOutput. Além disso, quaisquer mensagens recebidas no devem ter o MQMD removido antes de prosseguir com o nó HTTPReply ou HTTPRequest (exceto se desejar incluir um MQMD no fluxo de HTTP).

No módulo ESQL para Compute1, inclua uma instrução como esta:

SET OutputRoot.XML.A.MessageID =
			CAST(InputLocalEnvironment.Destination.HTTP.RequestIdentifier AS
CHARACTER);

No módulo ESQL para Compute2, codifique uma instrução como esta:

SET
OutputLocalEnvironment.Destination.HTTP.RequestIdentifier =
			CAST(InputRoot.XML.A.MessageID AS BLOB);

Conceitos relacionados

Gerar WSDL (Web Services Description Language)

Tarefas relacionadas
Criação de um Fluxo de Mensagens
Configurando Nós para Cenários de Serviços da Web Específicos
Implementando Aplicativos de Fluxo de Mensagens
Verificando os Resultados da Implementação

Referências relacionadas
Nó HTTPInput
Nó HTTPReply
Nó HTTPRequest