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

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.

O diagrama mostra um conjunto de mensagens que está 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á atualmente acessível 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. É criado um fluxo de mensagens utilizando o conjunto de mensagens e WSDL é criado para chamar o aplicativo. O fluxo de mensagens e o conjunto de mensagens são implementados para um intermediário, fornecendo uma interface de serviço da Web para o aplicativo original.

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.

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.

Utilizações Possíveis

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 copybook COBOL.

  1. Importe o copybook COBOL para criar um modelo de mensagem.
  2. Crie um fluxo de mensagens com nós: HTTPInput, HTTPReply e CICS.
  3. Utilize os nós HTTPInput e HTTPReply para fornecer a fachada do serviço da Web.
  4. Utilize o nó CICS para invocar a implementação 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 WSDL exportado das ferramentas do WebSphere Message Broker na chamada do 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.

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

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

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

Representa dois fluxos de mensagens; o primeiro possui os nós HTTPInput, Compute1 e MQOutput. O segundo possui 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 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);
Conceitos relacionados
Fluxos de Mensagens do Domínio XML
O Intermediário Chama um Serviço da Web Existente
O Intermediário Implementa uma Interface de Serviço da Web Existente
Intermediário Implementa Interface Não do Serviço da Web para Novo Serviço da Web
Avisos | Marcas Registradas | Downloads | Biblioteca | Suporte | Feedback

Copyright IBM Corporation 1999, 2009Copyright IBM Corporation 1999, 2009.
Última atualização : 2009-02-13 16:11:57

ac34540_