Sobre a Amostra de Reconhecimento TCPIP

A amostra Handshake TCPIP utiliza os nós TCPIPServerInput, TCPIPServerOutput e TCPIPServerReceive. Para obter uma visão geral de como esses nós funcionam e são configurados, consulte Visão Geral do TCP/IP na documentação do WebSphere Message broker.

Você pode utilizar este fluxo de amostra se tiver substituído um serviço TCP/IP existente por um serviço WebSphere MQ e alguns clientes não tiverem sido migrados para o novo serviço.

O Serviço Existente

O serviço existente é um servidor TCP/IP que implementa um serviço de pedido/resposta. Um handshake em três vias existe do lado do pedido e da resposta da troca de dados. O handshake em três vias fornece um mecanismo para o cliente cancelar um pedido que está levando muito tempo para processar. Como o handshake é implementado na camada do aplicativo, o cancelamento pode ser executado sem interromper a conexão TCP/IP.

As etapas a seguir demonstram o handshake:

Pedido: Resposta:

Podem ocorrer atrasos durante o processo:

O cliente pode cancelar o pedido em dois momentos no processo a seguir:

  1. Depois de enviar o pedido, mas antes que o servidor comece a processá-lo. O cliente pode cancelar o pedido enviando uma mensagem de Confirmação de Pedido negativa ou não enviando uma mensagem de Confirmação do Pedido.
  2. Depois que o servidor tiver começado a processar o pedido mas antes que servidor tenha concluído o processamento. O cliente pode cancelar a solicitação enviando uma mensagem de Reconhecimento de Resposta negativa ou deixando de enviar uma mensagem Reconhecimento de Resposta.

O formato físico de todas as seis mensagens é definido por um formato proprietário.

O Novo Serviço

O novo serviço é um serviço de pedido/resposta do WebSphere MQ que usa a convenção padrão do WebSphere MQ de usar o campo ID da Correlação do MQMD para correlacionar cada resposta a seu pedido correspondente. As mensagens de pedido e resposta estão no formato XML.

O Fluxo de Mensagens TCPIPMQVeneer

O fluxo de mensagens é uma camada superficial que faz com que o serviço do WebSphere MQ se pareça com o serviço TCP/IP original, em termos de seqüência e formato físico dos dados trocados.

O fluxo de mensagens TCPIPMQVeneer

O fluxo de mensagens TCPIPMQVeneer consiste em três subfluxos:

receiveRequest

Esse subfluxo implementa o handshake em três vias para receber o pedido do cliente TCP/IP.

Subfluxo recieveRequest

Esse subfluxo toma a solicitação da conexão TCP/IP, envia um reconhecimento de volta à mesma conexão e espera uma confirmação.

O pedido é utilizado para preencher a árvore de Mensagem no nó TCPIPServerInput. O reconhecimento e a confirmação são construídos na árvore de ambiente local. A mensagem de pedido não é alterada pelo subfluxo.

Examine as classes MakeRequestAck e CheckRequestConf, que são usadas pelos nós MakeAcknowledgement e CheckConfirmation, para descobrir como o ambiente local é usado para construir o reconhecimento e para usar a confirmação. Estas classes não criam nenhuma nova MbMessages. Todas as modificações são feitas no ambiente local de entrada, que é então propagado adiante. A mensagem de entrada não é alterada, o que é importante já que:

De maneira correspondente, o nó TCPIPServerOutput possui sua propriedade Local dos Dados configurada para $LocalEnvironment/Variables/ReplyAcknowledgement/BLOB e o nó TCPIPServerReceive possui sua propriedade Local dos Dados de Saída configurada para $OutputLocalEnvironment/Variables/ReplyConfirmation.

A propriedade ID location dos nós TCPIPServerOutput e TCPIPServerReceive é configurada para $LocalEnvironment/TCPIP/Input/ConnectionDetails/Id, para assegurar que o reconhecimento seja enviado de volta, e que a confirmação seja aguardada, na mesma conexão que a solicitação foi recebida.

O nó TCPIPServerReceive tem a propriedade Tempo limite esperando pelo registro de dados (segundos) configurada para 60 segundos e o terminal Timeout do nó não está ligado. Portanto, se o cliente enviar uma solicitação, mas falhar ao enviar uma confirmação dentro de 60 segundos do reconhecimento que está sendo enviado, uma exceção será produzida pelo nó TCPIPServerReceive. Na classe Java CheckRequestConf no nó CheckConfirmation, se a mensagem de confirmação não contiver o valor esperado, uma confirmação negativa é assumida e o pedido é propagado ao terminal Alternate que está ligado a um nó Throw. Portanto, o cliente que envia uma confirmação negativa obtém o mesmo resultado de quando o cliente falha ao enviar uma confirmação dentro de 60 segundos. Ou seja, uma exceção é produzida cancelando o pedido.

invokeMQService

Este subfluxo implementa o handshake com o WebSphere MQ, incluindo a conversão dos dados para o formato XML.

Subfluxo invokeMQService

Este subfluxo:

É essencial que o ambiente local seja preservado ou copiado, para garantir que os nós TCPIP no subfluxo sendReply estejam aptos para utilizar a mesma conexão que a do subfluxo receiveRequest.

O subfluxo invokeMQService pode ser substituído para chamar outro tipo de serviço, sem exigir que os outros dois subfluxos sejam alterados.

Exemplos de como o subfluxo invokeMQService pode ser modificado ou substituído:

sendReply

Esse subfluxo implementa o handshake em três vias para enviar a resposta de volta ao cliente TCP/IP.

Subfluxo sendReply

Este subfluxo envia a resposta e o handshake é executado aguardando por um reconhecimento do cliente, e enviando uma confirmação de volta ao cliente.

Este subfluxo é semelhante ao subfluxo receiveRequest das seguintes maneiras:

Voltar para o Início da Amostra