Agents architecture

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

Agents overview

PulseUno agents are small Java applications that PulseUno uses to run chains.

  • Each agent is associated with a primary PulseUno server.

  • Each PulseUno server can have multiple agents connected to it.

  • Agents only include the code required to run chains.

  • Agents automatically download the required plugins from the PulseUno server. No need to manually install plugins on agents.

  • By default, an agent can run one chain at a time.

For details about using chains and chain plugins, see Run chains.

Back to top

Agent architecture

Agents are an important part of PulseUno scalability. By adding more agents, the throughput and capacity of the system increases and scales to fit your needs. Depending on the number of chains defined, PulseUno might 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.

  • The monitor is a service that manages the worker process, for example, starting, stopping, and managing restarts, upgrades, and security.

  • The worker is a process that 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.

Back to top

Agent communication

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


  • 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: