Neste cenário, o broker implementa uma nova interface de serviço da Web. O WSDL para o serviço da Web é gerado a partir de um conjunto de mensagens e disponibilizado aos clientes. Um fluxo de mensagens baseado neste WSDL e no conjunto de mensagens recebe um pedido e, em seguida, constrói uma mensagem de resposta usando os dados obtidos de um aplicativo não de serviço da Web existente.
O diagrama a seguir mostra um fluxo de mensagens sendo criado a partir de uma definição de interface (por exemplo, um arquivo de cabeçalho) de um aplicativo existente que não está acessível atualmente como um serviço da Web. Um arquivo WSDL é gerado a partir de um conjunto de mensagens e exportado para utilização por um cliente de serviço da Web. Um fluxo de mensagens que usa o conjunto de mensagens e o WSDL é criado para chamar o aplicativo. O fluxo de mensagens e o conjunto de mensagens são implementados em um broker, fornecendo uma interface de serviço da Web para o aplicativo original.
Chave para os 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.
Neste exemplo, um fluxo de mensagens existente é modificado para fornecer um serviço da Web. Se o fluxo de mensagens existente modelar dados em um conjunto de mensagens, uma definição de WSDL poderá ser gerada a partir desse conjunto de mensagens e disponibilizada aos clientes.
A maioria dos fluxos de mensagens que atualmente utilizam o WebSphere MQ para entrada ou saída pode ser adaptada para suportar serviços da Web como um protocolo adicional ou substituição.
Se usar o domínio SOAP, a forma da árvore lógica será diferente do domínio original e você precisará levar isso em conta no fluxo de mensagens. Se usar os nós HTTP com o domínio original, a forma da árvore lógica não será alterada. Para obter informações sobre como escolher o domínio, consulte WebSphere Message Broker e Serviços da Web.
Nesse exemplo, um fluxo de mensagens é criado para fornecer acesso assíncrono a um aplicativo WebSphere MQ.
Em cada caso, o primeiro fluxo de mensagens recebe pedidos de entrada de um cliente de serviço da Web. O nó Compute1 transforma o pedido e um nó MQOutput envia o pedido modificado ao aplicativo existente.
No segundo fluxo de mensagens, um nó MQInput recebe a resposta do aplicativo. O nó Compute2 então transforma a mensagem e propaga a mesma para um nó de resposta que responde ao cliente de serviço da Web original.
O nó Compute1 também deve salvar algumas informações de correlação a serem recuperadas pelo nó Compute2, assegurando que as respostas do aplicativo WebSphere MQ sejam retornadas ao cliente que enviou o pedido original.
Usando os nós HTTPInput e MQOutput como a mensagem de saída e os nós MQInput e HTTPReply como a mensagem de resposta:
Uma maneira de preservar as informações de correlação é para o nó Compute1 codificar o ID de correlação na mensagem de saída. (Como alternativa, o identificador pode ser armazenado em um banco de dados). Os nós SOAPInput e HTTPInput colocam o identificador como um campo na árvore ambiente local e o nó Compute1 pode ler e armazenar este valor. O local do identificador se difere entre os nós SOAPInput e HTTPInput, conforme descrito nas seções seguintes.
Nós SOAP
SET OutputRoot.XMLNS.A.MessageID =
CAST(InputLocalEnvironment.Destination.SOAP.Reply.ReplyIdentifier AS CHARACTER);
No módulo ESQL para o nó Compute2, inclua uma instrução de código como a seguinte: SET OutputLocalEnvironment.Destination.SOAP.Reply.ReplyIdentifier =
CAST(InputRoot.XMLNS.A.MessageID AS BLOB);
Nós HTTP
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 como a seguinte: SET
OutputLocalEnvironment.Destination.HTTP.RequestIdentifier =
CAST(InputRoot.XMLNS.A.MessageID AS BLOB);