About the TCPIP Handshake sample

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

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: Reply:

Time delays might occur during the process:

The client can cancel the request at the following two points in the process:

  1. After sending the request, but before the server starts to process it. The client can cancel the request by sending a negative Request-Confirmation message, or by failing to send a Request-Confirmation message.
  2. After the server has started to process the request, but before the server has completed the processing. The client can cancel the request by sending a negative Reply-Acknowledgment message, or by failing to send a Reply-Acknowledgment message.

The physical format of all of the six messages is defined by a proprietary format.

The new service

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 TCPIPMQVeneer message flow

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

The TCPIPMQVeneer message flow consists of three subflows:

receiveRequest

This subflow implements the three-way handshake to receive the request from the TCP/IP client.

recieveRequest subflow

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:

Correspondingly, the TCPIPServerOutput node has its Data location property set to $LocalEnvironment/Variables/ReplyAcknowledgement/BLOB and the TCPIPServerReceive node has its Output data location property set to $OutputLocalEnvironment/Variables/ReplyConfirmation.

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.

invokeMQService

This subflow implements the handshake with WebSphere MQ, including converting the data to XML format.

invokeMQService subflow

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:

sendReply

This subflow implements the three-way handshake to send the reply back to the TCP/IP client.

sendReply subflow

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:

Back to sample home