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 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:Se pueden producir retardos durante el proceso:
El cliente puede cancelar la petición en los dos puntos siguientes del proceso:
El formato físico de todos los seis mensajes se define mediante un formato de propiedad.
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 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 consta de tres subflujos:
Este subflujo implementa el reconocimiento de tres vías para recibir la petición del cliente TCP/IP.
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:
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.
Este subflujo implementa el reconocimiento con WebSphere MQ, incluida la conversión de los datos al formato XML.
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:
En lugar de utilizar un nodo MQGet, puede utilizar un nodo MQInput para habilitar el servicio WebSphere MQ de modo que se invoque de forma asíncrona. No obstante, la salida de este subflujo debe tener los valores correctos en el entorno local para que el subflujo sendReply pueda utilizar la misma conexión que el subflujo receiveRequest. Por lo tanto, debe almacenar una correlación de los ID de mensaje de WebSphere MQ que esté emparejada con el ID de conexión. El ejemplo de nodos HTTP muestra cómo almacenar la correlación como mensajes en otra cola WebSphere MQ. Otras opciones para almacenar la correlación son:
Si el servidor TCP/IP se sustituye por un servicio web, debe utilizar un subflujo invokeWebService, en lugar del subflujo invokeMQService. Puede crear un subflujo invokeWebService utilizando un nodo SOAPRequest. Consulte el ejemplo de nodos SOAP para obtener una demostración sobre cómo crear un flujo de consumidor de servicios web.
Este subflujo implementa el reconocimiento de tres vías para devolver la respuesta al cliente TCP/IP.
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: