TCP/IP nodes
IBM® Integration Bus implements access to the TCP/IP input and output streams through a series of message flow nodes.
Two sets of TCP/IP message flow nodes exist: TCPIPServer nodes and TCPIPClient nodes. Both sets have identical function in terms of accessing the data streams; however, one set uses client connections and the other set uses server connections. As a result, the nodes establish the connections in different ways but they use the streams in the same way when the connections have been established.
The main difference between the properties of the nodes is that the TCPIPServer nodes do not allow the host name to be changed (because it must always be localhost). All TCPIPServer nodes that use the same port must be in the same integration server because the port is tied to the running process. TCPIPClient nodes on the same port can be used in different integration servers, but client connections cannot be shared because the client connections are tied to a particular integration server, which maps to a process. Within the two sets of nodes (TCPIPClient and TCPIPServer), are three types of node:
- TCPIPServerInput and TCPIPClientInput
- TCPIPServerReceive and TCPIPClientReceive
- TCPIPServerOutput and TCPIPClientOutput
The input and receive nodes access the input stream to retrieve data, and the output nodes access the output stream to send data. No single node can access both streams at the same time. To access both streams simultaneously, you must connect multiple nodes in a message flow.
Configurable services for TCPIPServer nodes and for TCPIPClient nodes must be predefined by an administrator. The connection details for TCP/IP configurable services are defined by the administrator when configuring the integration node for test or production. TCP/IP configurable services must be defined before a message flow that uses them is deployed, even in a test environment. For more information, see Configuring properties for TCP/IP.
Input nodes
The input node allows access to a connection's input stream. The node is triggered by the arrival of data in the stream and starts processing the message flow. The input node controls thread and transaction management. The TCP/IP nodes are not transactional in the way that they interact with TCP/IP, but other nodes in the same flow can be transactional (for example, WebSphere® MQ nodes). The input node does not create a thread for every connection being used, but waits for two requirements to be met:
- A connection is available that still has an open input stream
- Data is available on the input stream (at least 1 byte)
For example, 1,000 TCP/IP connections can be handled by one input node that has only one additional instance. This situation is possible because the node does not poll the connections, but is triggered when the specified conditions are met.
Receive nodes
The receive node is triggered to read data from a connection when a message arrives on its In terminal. It waits for data to arrive, then sends it to the Out terminal. You can configure the receive node to use a particular connection (by specifying a connection's ID) or to use any available connection. If the node is configured to use any available connection, it receives data from the first connection that has data available.
Output nodes
The output node sends data to a connection. It is triggered by a message arriving on its In terminal, then it sends the data contained in the message to the stream. The same message that is received in the node is sent to the Out terminal.
Combining nodes
The six client and server nodes can be combined to provide more complex operations. For example, an output node followed by a receive node enables a synchronous request of data:
- A connection ID to ensure that the same connection is used by multiple nodes
- The ability to reserve connections so that they can be accessed only when the ID is specified
One connection in multiple nodes
Every connection has a unique identifier assigned to it when it is created. Whenever a node uses a connection, the ID that is used is written to the local environment. Any nodes that use it later in the flow can access the same connection by specifying the ID; the receive and output nodes find the ID by searching in a specified location in the local environment. By default, the location in which a node writes its connection details is different from the location in which the next node looks to see if there is an ID to use. The nodes can be configured to use the ID that was sent by a previous node. For example, the combination of the output and receive nodes shown in Combining nodes can be configured so that the receive node uses the WrittenDestination data from the preceding output node.
The use of the ID enables a series of nodes to access the same connection, but does not prevent two message flow threads accessing the same connection. When a connection is used for the first time, it can be reserved so that no other nodes can access it unless they know the ID. For example, the combination of the output and receive nodes shown in Combining nodes reserves the connection so that no other threads can access it before the receive node uses it. By default, the receive node then releases the connection when it has finished.
The ability to reserve connections (and access them by specifying the correct ID) enables you to build up complex interactions with TCP/IP connections that span whole flows and even multiple message flows. As a result, the TCP/IP interactions can be used with other asynchronous transport mechanisms like WebSphere MQ.
Reserved connections must be released at some time, otherwise they remain unavailable indefinitely. For more information about reserved and available connections, see Connection management.
Correlating replies across flows
You can use the TCP/IP nodes in asynchronous patterns, in which data is sent out through a TCP/IP output node and received back through a TCP/IP input node. The spanning of two message flows causes any state in the first flow to be lost and therefore inaccessible from the second flow. The TCP/IP nodes enable you to store some reply details on a connection, and these details are then available for the input node to use when a new event arrives on the same connection. By default, this data is taken from the local environment, but you can configure the nodes to take the data from any location, including the Correlid field and message IDs in WebSphere MQ headers.