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_sessionself_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_sessionself_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.