Agent Communication

Most agent communication is done with JMS, but some agent activities use the web tier through HTTP as needed. For example:

Stateless server-agent communication provides significant benefits to performance, security, availability, and disaster recovery. Because each agent request is self-contained, a transaction consists of an independent message that can be synchronized to secondary storage as it occurs. Either the server or agent can be taken down and brought back up without repercussion, other than lost time. If communications fail mid-transaction, no messages are lost.

Once reconnected, 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 figure, the arrow represents the direction in which the stateless communication was established, but the flow is in both directions with JMS.

Figure 1. Stateless Communication


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, Deployment Automation 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.