Acerca del ejemplo de Reconocimiento TCPIP

El ejemplo Reconocimiento TCPIP utiliza los nodos TCPIPServerInput, TCPIPServerOutput y TCPIPServerReceive. Para obtener una visión general de cómo funcionan y cómo están configuran los nodos, consulte Visión general de TCP/IP en la documentación de WebSphere Message Broker.

Puede utilizar este flujo de ejemplo si ha sustituido un servicio TCP/IP existente con un servicio WebSphere MQ y algunos de los clientes no se han migrado al nuevo servicio.

El servicio existente

El servicio existente es un servidor TCP/IP que implementa un servicio de petición/respuesta. Existe un reconocimiento de tres vías en los extremos de petición y respuesta del intercambio de datos. El reconocimiento de tres vías proporciona un mecanismo para que el cliente cancele una petición que está tardando mucho en procesarse. Dado que el reconocimiento se implementa en la capa de aplicación, se puede llevar a cabo la cancelación sin interrumpir la conexión TCP/IP.

Los pasos siguientes muestran el reconocimiento:

Petición: Respuesta:

Se pueden producir retardos durante el proceso:

El cliente puede cancelar la petición en los dos puntos siguientes del proceso:

  1. Después de enviar la petición pero antes de que el servidor inicie el proceso. El cliente puede cancelar la petición enviando un mensaje de Petición-Confirmación negativo o no enviando un mensaje de Petición-Confirmación.
  2. Después de que el servidor haya iniciado el proceso de la petición, pero antes de que el servidor haya completado el proceso. El cliente puede cancelar la petición enviando un mensaje de Respuesta-Reconocimiento o no enviando un mensaje de Respuesta-Reconocimiento.

El formato físico de todos los seis mensajes se define mediante un formato de propiedad.

El nuevo servicio

El nuevo servicio es un servicio de petición/respuesta de WebSphere MQ que utiliza el convenio estándar de WebSphere MQ mediante el campo ID de correlación de MQMD para correlacionar cada respuesta con su petición correspondiente. Los mensajes de petición y respuestas tienen el formato XML.

El flujo de mensajes TCPIPMQVeneer

El flujo de mensajes es una fachada que hace que el servicio WebSphere MQ se parezca al servicio TCP/IP original, en lo relacionado con la secuencia y el formato físico de los datos intercambiados.

El flujo de mensajes TCPIPMQVeneer

El flujo de mensajes TCPIPMQVeneer consta de tres subflujos:

receiveRequest

Este subflujo implementa el reconocimiento de tres vías para recibir la petición del cliente TCP/IP.

Subflujo receiveRequest

Este subflujo toma la petición de la conexión TCP/IP, vuelve a enviar un reconocimiento a través de la misma conexión y espera una confirmación.

La petición se utiliza para rellenar el árbol de mensajes en el nodo TCPIPServerInput. El reconocimiento y la confirmación se construyen en el árbol del entorno local. El subflujo no modifica el mensaje de petición.

Busque las clases MakeRequestAck y CheckRequestConf, que utilizan los nodos MakeAcknowledgement y CheckConfirmation, para saber cómo se utiliza el entorno local para crear el reconocimiento y para utilizar la confirmación. Estas clases no crean ningún MbMessage nuevo. Todas las modificaciones se realizan en el entorno local de entrada que, a continuación, se propaga. El mensaje de entrada no se modifica, lo que es importante debido a que:

En consecuencia, el nodo TCPIPServerOutput tiene su propiedad Ubicación de datos establecida en $LocalEnvironment/Variables/ReplyAcknowledgement/BLOB y el nodo TCPIPServerReceive tiene su propiedad Ubicación de datos de salida establecida en $OutputLocalEnvironment/Variables/ReplyConfirmation.

La propiedad Ubicación de ID de los nodos TCPIPServerOutput y TCPIPServerReceive establecida en $LocalEnvironment/TCPIP/Input/ConnectionDetails/Id, para asegurarse de que se vuelve a enviar el reconocimiento y que se espera la confirmación, en la misma conexión en que se ha recibido la petición.

El nodo TCPIPServerReceive tiene la propiedad Se ha excedido el tiempo de espera de registro de datos (segundos) establecida en 60 segundos y el terminal Timeout del nodo no está cableado. Por lo tanto, si el cliente envía una petición pero no envía una confirmación en el plazo de 60 segundos desde que se ha enviado el reconocimiento, el nodo TCPIPServerReceive genera una excepción. En la clase Java CheckRequestConf del nodo CheckConfirmation, si el mensaje de confirmación no contiene el valor previsto, se presupone una confirmación negativa, y la petición se propaga al terminal alternativo que está cableado a un nodo Throw. Por lo tanto, el cliente que envía una confirmación negativa tiene el mismo resultado que el cliente que no envía una confirmación en el plazo de 60 segundos. Esto es, se genera una excepción que cancela la petición.

invokeMQService

Este subflujo implementa el reconocimiento con WebSphere MQ, incluida la conversión de los datos al formato XML.

Subflujo invokeMQService

Este subflujo:

Resulta esencial que se conserve o copie el entorno local, para asegurarse de que los nodos TCPIP del subflujo sendReply puedan utilizar la misma conexión con el subflujo receiveRequest.

El subflujo invokeMQService se puede sustituir para poder llamar a otro tipo de servicio, sin que sea necesario modificar los otros dos subflujos.

Ejemplos de cómo se puede modificar o sustituir el subflujo invokeMQService:

sendReply

Este subflujo implementa el reconocimiento de tres vías para devolver la respuesta al cliente TCP/IP.

Subflujo sendReply

Este subflujo envía la respuesta y el reconocimiento se completa esperando un reconocimiento del cliente y luego devuelve la confirmación al cliente.

Este subflujo es similar al subflujo receiveRequest en los aspectos siguientes:

Volver a la página inicial del ejemplo