Neste cenário de serviços da Web, o intermediário fornece uma interface de serviços da Web para um aplicativo não do serviço da Web existente.
Chave para Símbolos:
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.
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.
Um aplicativo CICS existente possui uma interface copybook COBOL.
A maioria dos fluxos de mensagens que atualmente utilizam WebSphere MQ para entrada ou saída pode ser adaptada para utilizar HTTP como um protocolo adicional ou de substituição.
É possível modelar a mensagem de entrada no domínio MRM e gerar WSDL a partir do modelo ou processar uma mensagem de domínio XMLNS genérica. Se você tiver definido a mensagem no domínio MRM, é 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.
É possível configurar o nó HTTPReply para gerar um conjunto de cabeçalhos HTTP padrão para a mensagem de resposta enviada ao cliente. Gerar um conjunto de cabeçalhos HTTP padrão reduz as modificações que devem ser feitas para converter o fluxo de mensagens de um que processa as mensagens do WebSphere MQ para um fluxo que processa mensagens HTTP.
O primeiro fluxo de mensagens recebe pedidos e entrada de clientes de serviços da Web em um nó HTTPInput. Incluir um nó Compute para transformar o pedido de alguma forma e um nó MQOutput para enviar o pedido modificado ao aplicativo do WebSphere MQ.
O segundo fluxo de mensagens recebe a resposta desse aplicativo em um nó MQInput. A mensagem é transmitida para um nó Compute que transforma a mensagem e propaga a mesma para um nó HTTPReply que a envia como resposta ao cliente de serviço da Web original.
Apesar das transformações concluídas por cada nó Compute poderem ser triviais, o código ESQL do primeiro nó Compute deve salvar as informações de estado HTTP que são recuperadas pelo segundo nó Compute para assegurar que as respostas do aplicativo do WebSphere MQ sejam retornadas ao cliente que enviou o pedido original.
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 LocalEnvironment chamada Destination.HTTP.RequestIdentifier e o nó 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. O nó Compute2 lê o identificador do pedido HTTP da mensagem e configura LocalEnvironment.Destination.HTTP.RequestIdentifier utilizando esse valor. O nó HTTPReply utiliza o identificador de pedido para assegurar que a mensagem atinja o cliente HTTP correto.
A implementação desse cenário requer a manipulação correta de MQMD. As mensagens recebidas em um fluxo de mensagens por HTTP devem ter um MQMD incluído para serem enviadas a um nó MQOutput. Além disso, quaisquer mensagens recebidas pelo WebSphere MQ devem ter o MQMD removido antes de serem enviadas para um nó HTTPReply ou HTTPRequest (a menos que a inclusão de um MQMD no fluxo HTTP seja desejado).
No módulo ESQL para o nó Compute1, inclua uma instrução de código similar à seguinte instrução:
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 similar à seguinte instrução:
SET OutputLocalEnvironment.Destination.HTTP.RequestIdentifier = CAST(InputRoot.XMLNS.A.MessageID AS BLOB);