Adapter overview

This section provides a brief description of the TCP/IP protocol and describes the components of the adapter for TCP/IP.

The TCP/IP protocol

TCP/IP is a set of protocols for the transmission of any sort of data over heterogeneous physical networks. It is the basis of the Internet and many other networks large and small. Data is encapsulated in packets that the stateless IP protocol carries through the network. Control of the stream of IP packets is taken care of by TCP, the Transmission Control Protocol. It is responsible for establishing a "virtual circuit" between the sending host and the receiving host and providing for reliable transmission.

Software that implements the TCP protocol comes in two varieties: TCP clients, which initiate the connection, and TCP servers, which listen on assigned ports for initiation requests and then accept them. The structure of TCP is inherently full duplex, meaning that both TCP clients and TCP servers are capable of sending and receiving data concurrently.

Connector architecture

The WebSphere Business Integration Adapter for TCP/IP provides a way of routing data sent over raw TCP/IP connections into and out of the WebSphere business integration system. Certain industry-standard protocols for the transmission of domain-specific messages, such as the HL7 protocol in the health-care industry, are designed to be sent directly over TCP/IP connections. The TCP/IP adapter provides a robust, highly scalable way to route such messages into or out of the WebSphere business integration system, regardless of the nature of the TCP application at the other end of the connection.

Figure 1 and Figure 2 show the connector components and their relationships to the WebSphere business integration system and to the TCP/IP network to which they are connected. In Figure 1, an inbound message coming from the network (represented by the cloud) over a TCP/IP socket is transformed and then delivered to the broker.

Figure 1. Architecture of the connector - Event (inbound) processing
Illustration showing how a message is sent from a server to the Protocol Listener Framework, how it is processed by the PIMO Framework and data handler, and how the resulting business object is sent to the broker.

Similarly, in Figure 2, an outbound message coming from a broker is transformed and then delivered over a TCP/IP socket to the network.

Figure 2. Architecture of the connector - Request (outbound) processing
Illustration showing how a business object is sent from the broker to the Protocol Handler Framework, how it is processed by the data handler and PIMO Framework, and how the resulting message is sent over the TCP/IP network.

Connection management

The connector, the runtime component of the adapter for TCP/IP, is capable of serving as either a TCP server (in inbound, or event processing, mode) or a TCP client (in outbound, or service request, mode). The module in the connector that implements the actual TCP protocol is called the Connection Manager.

The Connection Manager has two parts: the Protocol Listener Framework and the Protocol Handler Framework.

Protocol Listener Framework

The Protocol Listener Framework serves as a TCP server, based on properties set in the ServerConfiguration section of the connector configuration file, the CFG. See Appendix B. Connector-specific properties and required business-object properties for more information on the CFG.

The Framework listens for incoming requests and provides for parallel processing of multiple requests through a thread management component called the request pool. Every new incoming request becomes a new request object in the request pool. The size of the pool is set by the MaxRequestPoolSize configuration property.

Requests in the pool are processed by worker threads, up to the number configured by the MaxRequestProcessors property in the CFG. At any given moment, the connector can process at most (MaxRequestPoolSize + MaxRequestProcessors) requests. Thread management and load balancing are also taken care of here. The worker threads package the incoming requests into byte arrays and hand them off to the Message Processing Framework.

Protocol Handler Framework

The Protocol Handler Framework serves as the TCP client, taking service call request data and sending it to remote hosts based on properties set in the ClientConfiguration part of the CFG.

The Protocol Handler Framework uses connection pooling to improve performance by reusing client connections to the external TCP/IP socket server. To use connection pooling, set ConnectionPoolingOn to True. You can set the number of connections with the ConnectionPoolSize property.

Message processing management

The Message Processing Framework manages the transformation of incoming event data into WebSphere business integration-usable business objects and of outgoing service request business objects into various supported message structures that can be sent over TCP/IP. It is made up of three parts:

The following sections provide an overview of the PIMO framework and describe how the components are used in both inbound and outbound processing. Details of the PIMO framework, including the business objects and meta-objects used in PIMO processing, are described in Business objects and meta-objects in the TCP/IP adapter.

The PIMO framework

The PIMO framework is a highly flexible, general-purpose abstraction for effecting business logic processing at the connector level. The PIMO framework is capable of a wide range of operations, and is used, in differing forms, in other adapters.

Message structures that come in over a TCP/IP connection might require a certain amount of pre-processing before they can be sent on to a data handler to be turned into WebSphere business integration business objects. In the TCP/IP connector, the PIMO framework has been customized specifically to take care of pre- and post-processing issues.

Take, for example, the HL7 health care data standard. The details of network transmission error detection and correction are handled by the lower levels of most modern network protocols, so the main standard does not include specifications covering them. However, many mini and mainframe computer systems, which might be part of the HL7 data flow, operate in communication environments that do not provide sufficient lower-layer functionality. In these cases, HL7 offers several alternate lower-layer protocols, such as the Hybrid Low Layer Protocol and the Minimal Low Layer Protocol, to suit different environments. Messages sent using these protocols must be pre-processed to remove this protocol-related information before the main body of data can be extracted.

The PIMO framework is designed to do exactly this sort of pre-processing by invoking one or more PIMO maps. The maps for the adapter are configured in the BIA_MO_Tcpip_MapSubscriptions PIMO meta-object. Each map has a message handler associated with it. These maps are provided to the PIMO framework when a message or business object is sent to the framework.

Inbound processing flow

In event (inbound) processing, the adapter's connector acts as a TCP server, listening on the designated socket, and setting up and managing the load on the socket once the connection with a client is established.

The data goes from the Connection Management component to the Message Processing component, where some basic pre-processing is done by the PIMO.

  1. Event data coming in from the request pool is run through the PIMO framework, where certain pre-processing operations are done using functionality found in message handlers.
  2. The data is then handed over to a data handler, an independent plug-in used by many different adapters, to be built into a WebSphere business integration-usable business object. The choice of data handlers is based on the DataHandlerMimeType and related properties in the CFG.
  3. The business object is passed on to the broker. The structure of the business object is completely determined by the data handler, so the adapter for TCP/IP is capable of handling any sort of message data for which there is a related data handler.
  4. If this is a synchronous request, a response is returned from the broker.

One TCP server can be configured per connector instance.

Outbound processing flow

In request (outbound) processing, the integration broker sends the connector a business object that represents the message it wishes to send to a pre-configured target host or application.

  1. A data handler converts the object into a message, which might also, if necessary, be sent for post-processing by the PIMO subcomponent.
  2. The connector, acting as a TCP client, contacts the appropriate server, establishes the connection, and manages sending the data.
  3. If required, the connector also handles any responses that the target server might provide.

Multiple TCP clients can be configured per connector instance.

Common Event Infrastructure

This adapter is compatible with the IBM Common Event Infrastructure, a standard for event management that permits interoperability with other IBM WebSphere event-producing applications. If Common Event Infrastructure support is enabled, events produced by the adapter can be received (or used) by another Common Event Infrastructure-compatible application.

For more information, refer to Appendix D. Common Event Infrastructure.

Application Response Measurement

This adapter is compatible with the Application Response Measurement application programming interface (API), an API that allows applications to be managed for availability, service level agreements, and capacity planning. An ARM-instrumented application can participate in IBM Tivoli(R) Monitoring for Transaction Performance, allowing collection and review of data concerning transaction metrics.

For more information, refer to Appendix E. Application Response Measurement.

Copyright IBM Corporation 1997, 2005. All Rights Reserved.