TCP Transport for TIBCO Hawk Architecture

The following are the key components of the TCP Transport for TIBCO Hawk:

Cluster Manager
Console and Hawk agent main cluster
Hawk agent and AMI subcluster
TCP Transport and TIBCO Rendezvous Bridge for Hawk Microagent (HMA)

 

Figure 4: The TCP Transport for TIBCO Hawk Architecture

Cluster Manager

The Cluster Manager is seed node for the TCP Transport Cluster. This is also the initial point of contact in the cluster. To use the TCP Transport for TIBCO Hawk, start the Cluster Manager process before starting any Hawk components. For using the fault tolerance, you can start multiple Cluster Managers.

Console and Hawk Agent Main Cluster

All the Hawk Agents, Hawk Consoles, and Hawk TCP daemons form one TCP Transport Cluster.

To form a cluster, all Hawk components and the daemon process are configured with daemon process as the seed node. The daemon process connects to itself and forms a cluster. All other Hawk components (Hawk agents and Hawk console) joins the cluster by connecting to the daemon process. It is best practice to have an odd number of daemon processes (such as 1, 3, 5, and so on). After the daemon process is started all other Hawk components can be started in any order. All agents and consoles in the cluster should have the same domain name.The configuration parameter for connecting to the daemon process is

tcp_session self_ip:port daemon_ip:port

where,

self_ip:port is the socket address of the Hawk component (Hawk agents, Hawk Console, or Cluster Manager) that is joining the cluster.

daemon_ip:port is the socket address of the Cluster Manager acting as a seed node for the TCP Transport Cluster. For the seed node daemon, self_ip:port and daemon_ip:port is same.

For fault tolerance, multiple seed nodes can be specified as comma separated list:

tcp_session self_ip:port daemon1_ip:port1,daemon2_ip:port2,...

Start the first seed node in the comma-separated list first and then other seed nodes. The cluster is not ready till the first node is started.

The Hawk Console subscribes to TCP Transport Cluster membership events. The membership ensures that the console gets notified whenever a new Hawk Agent is up or an existing one is down.

Hawk Agent and AMI Subcluster

The Hawk agent and its AMI applications form a separate cluster. For this cluster, the Hawk agent becomes the daemon process. The Hawk agent is the seed node through which all the AMI applications join the cluster. The configuration parameter for the Hawk agent’s AMI component is:

ami_tcp_session self_ip:port

where,

self_ip:port is the socket address of the Hawk agent acting as the Cluster Manager for the cluster

For the AMI application, the configuration parameter for connection to the Hawk agent in the cluster is:

tcp_session=self_ip:port agent_ip:ami_tcp_session_port

where,

self_ip:port is the socket address for the AMI application

agent_ip:ami_tcp_session_port is socket address of the Hawk agent AMI component for the TCP Transport Cluster. This is the same socket address that was used in the self_ip:port attribute of the ami_tcp_session parameter in the Hawk agent of the TCP Transport Cluster.

TCP Transport and TIBCO Rendezvous Bridge for Hawk Microagent (HMA)

The TCP Transport and TIBCO Rendezvous Bridge is required for using Hawk Microagent (HMA) with TCP Transport for TIBCO Hawk. Since the TIBCO Rendezvous transport support Hawk C/C++ AMI API, a bridge is required to use HMA in the TCP Transport Cluster. In this bridge, the TIBCO Rendezvous transport is used for HMA and the TCP Transport for TIBCO Hawk for all other AMI applications. The AMI specific transport implementation of TCP Transport for TIBCO Hawk handles both the sessions.