Agent architecture

This topic describes PulseUno agents and how they communicate with the PulseUno server and with each other.

Agent overview

Agents are small Java applications that PulseUno uses to run chains. Each agent is associated with a primary PulseUno server.

Agents are an important part of PulseUno scalability. A PulseUno server can have multiple agents connected to it. By adding more agents, the throughput and capacity of the system increases and scales to fit your needs.

By default, an agent can run one chain at a time. Depending on the number of chains, PulseUno may require a large number of agents to prevent the queue of chains growing too large.

Agents are unobtrusive and secure. After an installed agent is started, the agent opens a socket connection to the PulseUno server. Communication between server and agents uses a JMS-based (Java Message Service) protocol and can be secured using SSL, with optional mutual key-based authentication for each end-point. The communication protocol is stateless and will recover after many types of network outages.

Agent services and processes:

  • The monitor service manages the worker process. It is responsible for starting and stopping the agent, managing restarts, upgrading, and security.

  • The worker process runs the chains after receiving commands from the server.

  • Chains are run in their own process using plugins to perform the steps and integrate with third-party tools.

Agents include only the code required to run chains and automatically download the required plugins from the PulseUno server.

For details on how to work with agents, see Manage agents.

Back to top

Agent communication

Agents are triggered using JMS and generally use HTTP/S to get more details about what they are expected to do, or to report detailed results.

Example:  

  • The server uses JMS to send agent commands.

  • The agent monitor service uses JMS for all server communications and for sending commands, such as run step to the worker process.

  • The worker process uses JMS for system communications and HTTP REST services when performing plugin steps or retrieving information from the server.

  • Agent activities such as posting logs, transmitting chain results, and posting files to PulseUno use the web tier through HTTP or HTTPS.

Most clients use browsers to communicate with the web server through HTTP or HTTPS.

Stateless server-agent communication provides significant benefits to performance, security, availability, and recovery after downtime. Because each agent request is self-contained, a transaction consists of an independent message that can be synchronized to secondary storage as it occurs. The server or agent can be taken down and brought back up with minimal impact, other than lost time.

If communications fail mid-transaction, no messages are lost. After reconnecting, the server and agent automatically determine which messages got through and what work was successfully completed.

After an outage, the system synchronizes the endpoints and recovers affected processes. The results of any work performed by an agent during the outage are communicated to the server.

In the following diagram, the arrow represents the direction in which the stateless communication was established, but the flow is in both directions with JMS.

For added security, agents do not listen on ports. Agents send requests when they are ready to make the transition to a new state. Because JMS connections are persistent and not based on a request-response protocol, PulseUno does not have to continually open and close ports, which enables the server to communicate with agents at any time while remaining secure and scalable.

REST-style services achieve statelessness by ensuring that requests include all the data needed by the server to make a coherent response.

Back to top

See also: