The TCPIP Handshake sample uses the TCPIPServerInput,
TCPIPServerOutput, and TCPIPServerReceive nodes.
For an overview of how these nodes work and are configured,
see TCP/IP overview
in the WebSphere Message broker documentation.
You might use this sample flow if you have replaced an existing TCP/IP service with a WebSphere MQ service and some of the clients have not migrated to the new service.
The existing service is a TCP/IP server that implements a request/reply service. A three-way handshake exists at both the request and reply sides of the data exchange. The three-way handshake provides a mechanism for the client to cancel a request that is taking too long to process. Because the handshake is implemented in the application layer, the cancellation can be performed without breaking the TCP/IP connection.
The following steps demonstrate the handshake:
Request:Time delays might occur during the process:
The client can cancel the request at the following two points in the process:
The physical format of all of the six messages is defined by a proprietary format.
The new service is a WebSphere MQ request/reply service that uses the standard WebSphere MQ convention of using the Correlation ID field of the MQMD to correlate each reply to its corresponding request. The request and reply messages are both in XML format.
The message flow is a veneer that makes the new WebSphere MQ service look like the original TCP/IP service, in terms of the sequence and physical format of the data exchanged.
The TCPIPMQVeneer message flow consists of three subflows:
This subflow implements the three-way handshake to receive the request from the TCP/IP client.
This subflow takes the request from the TCP/IP connection, sends an acknowledgment back on the same connection, and waits for a confirmation.
The request is used to populate the message tree in the TCPIPServerInput node. The acknowledgment and confirmation are both constructed in the local environment tree. The request message is unchanged by the subflow.
Look at the MakeRequestAck and CheckRequestConf classes, which are used by the MakeAcknowledgement and CheckConfirmation nodes, to find out how the local environment is used to construct the acknowledgment and to use the confirmation. These classes do not create any new MbMessages. All the modifications are made to the input local environment, which is then propagated onwards. The input message is not changed, which is important because:
The ID location property of the TCPIPServerOutput and TCPIPServerReceive nodes is set to $LocalEnvironment/TCPIP/Input/ConnectionDetails/Id, to ensure that the acknowledgment is sent back, and that the confirmation is waited for, on the same connection upon which the request was received.
The TCPIPServerReceive node has the Timeout waiting for data record (seconds) property set to 60 seconds, and the Timeout terminal of the node is not wired. Therefore, if the client sends a request but then fails to send a confirmation within 60 seconds of the acknowledgment being sent, an exception is produced by the TCPIPServerReceive node. In the Java class CheckRequestConf in the CheckConfirmation node, if the confirmation message does not contain the expected value, a negative confirmation is assumed, and the request is propagated to the Alternate terminal that is wired to a Throw node. Therefore, the client sending a negative confirmation has the same result as when the client fails to send a confirmation within 60 seconds. That is, an exception is produced that cancels the request.
This subflow implements the handshake with WebSphere MQ, including converting the data to XML format.
This subflow:
It is essential that the local environment is preserved or copied, to ensure that the TCPIP nodes in the sendReply subflow are able to use the same connection as the receiveRequest subflow.
The invokeMQService subflow can be replaced in order to call another type of service, without requiring the other two subflows to be changed.
Examples of how the invokeMQService subflow can be modified or replaced:
Instead of using an MQGet node, you can use an MQInput node to enable the WebSphere MQ service to be called asynchronously. However, the output of this subflow must have the correct values in the local environment to allow the sendReply subflow to use the same connection as the receiveRequest subflow. You must, therefore, store a map of the WebSphere MQ Message ID that is paired with the connection ID. The HTTP nodes sample shows you how to store the map as messages on another WebSphere MQ queue. Other options for storing the map are to:
If the TCP/IP server is replaced by a Web service, you must use an invokeWebService subflow instead of the invokeMQService subflow. You can construct an invokeWebService subflow by using a SOAPRequest node. See the SOAP nodes sample for a demonstration of how to construct a Web service consumer flow.
This subflow implements the three-way handshake to send the reply back to the TCP/IP client.
This subflow sends the reply and the handshake is completed by waiting for an acknowledgment from the client, and then sending a confirmation back to the client.
This subflow is similar to the receiveRequest subflow in the following ways: