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 é 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:Podem ocorrer atrasos durante o processo:
O cliente pode cancelar o pedido em dois momentos no processo a seguir:
O formato físico de todas as seis mensagens é definido por um formato proprietário.
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 é 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 consiste em três subfluxos:
Esse subfluxo implementa o handshake em três vias para receber o pedido do cliente TCP/IP.
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:
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.
Este subfluxo implementa o handshake com o WebSphere MQ, incluindo a conversão dos dados para o formato XML.
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:
Ao invés de utilizar um nó MQGet, você pode utilizar o nó MQInput para permitir que o serviço WebSphere MQ seja chamado de maneira assíncrona. Entretanto, a saída deste subfluxo deve ter os valores corretos no ambiente local para permitir que o subfluxo sendReply utilize a mesma conexão que a do subfluxo receiveRequest. Você deve, portanto, armazenar um mapa do ID de Mensagem do WebSphere MQ que se une ao ID de conexão. A amostra dos nós HTTP mostra como armazenar o mapa como mensagens em outra fila do WebSphere MQ. Outras opções para armazenamento do mapa são:
Se o servidor TCP/IP é substituído por um serviço da Web, você deve utilizar um subfluxo invokeWebService ao invés do subfluxo invokeMQService. Você pode construir um subfluxo invokeWebService utilizando um nó SOAPRequest. Consulte a amostra Nós SOAP para obter uma demonstração de como construir um fluxo do consumidor do serviço da Web.
Esse subfluxo implementa o handshake em três vias para enviar a resposta de volta ao cliente TCP/IP.
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: