Neste cenário de serviço da Web, o intermediário fornece uma interface de serviço da Web para um aplicativo existente que não é um serviço da Web.
Chave para Símbolos:
Às vezes, isso é referido como uma fachada de serviço da Web. O design da interface de serviço da Web geralmente envolverá algum reagrupamento, restrição ou aprimoramento da interface existente e não é restrito por uma definição WSDL existente.
O intermediário fornece uma interface de serviços da Web para um aplicativo existente, fornecendo, opcionalmente, outros recursos mistos como auditoria dos pedidos feitos.
Com o tempo, a implementação pode ser alterada sem afetar a interface apresentada no cliente de serviços da Web.
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 de 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.
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 WebSphere MQ para um fluxo que processa mensagens 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 o pedido de algum modo e um nó MQOutput para enviar o pedido modificado ao aplicativo WebSphere MQ.
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 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 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 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 no WebSphere MQ devem ter o MQMD removido antes de serem enviadas para um 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);