O Intermediário Implementa uma Nova Interface de Serviço da Web

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.

O diagrama mostra um aplicativo existente cujo arquivo de definição é importado para um conjunto de mensagens. É gerado um arquivo WSDL a partir do conjunto de mensagens. O conjunto de mensagens é implementado para um fluxo em um intermediário. O fluxo interage no tempo de execução com o aplicativo original existente e o cliente de serviço da Web.

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.

À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.

Utilizações Possíveis

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.

Etapas de Design

  1. Crie um conjunto de mensagens para as mensagens de negócios, possivelmente importando uma definição de interface como um arquivo de cabeçalho C ou arquivo de cabeçalho.
  2. Gere uma definição WSDL a partir do conjunto de mensagens.
  3. Utilize um toolkit SOAP como o Rational Application Developer para criar um cliente de serviços da Web apropriado com base no WSDL.
  4. Desenvolva um fluxo de mensagens para implementar o serviço da Web.

Tempo de Execução

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.

Exemplo 1

Um aplicativo CICS existente possui uma interface de copybook COBOL.

  1. Importe o copybook COBOL para criar um modelo de mensagem.
  2. Crie um fluxo de mensagens com o nós: HTTPInput, HTTPReply e CICS.
  3. Utilize os nós HTTPInput e HTTPReply para fornecer a fachada de serviço da Web.
  4. Utilize o nó CICS para chamar a implementação do CICS original.

Exemplo 2

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 WebSphere Message Broker ao chamar o fluxo de mensagens.

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.


Isto representa um fluxo de mensagens com os nós HTTPInput, Compute1, DataUpdate, Compute2, 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 WebSphere MQ para um fluxo que processa mensagens HTTP.

Exemplo 3

O fluxo de mensagens fornece acesso ao aplicativo WebSphere MQ
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 WebSphere MQ 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 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.


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 que encerra o primeiro fluxo coloca uma mensagem em uma fila do WebSphere MQ atendida por um aplicativo existente, que coloca suas respostas na fila de entrada atendida pelo nó MQInput que inicia o segundo fluxo

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);
Conceitos relacionados
Serviços da Web, WSDL e Fluxos de Mensagens
O Intermediário Chama um Serviço da Web Existente
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
ac34540_