All processes, packaging, configuration, deployments, and so on, requested by the Deployment Automation server, run on hardware assigned to agents.
Typically, an agent runs on the host where the resources it handles are located. A single agent can handle all resources on its host. If a host has several resources, an agent process is invoked separately for each resource.
Example: A test environment might contain a single web server, a single middleware server, and a single database server, all running on the same host machine. A deployment to this environment might have one agent and three separate resources.
Agents are an important part of Deployment Automation scalability. By adding more agents, the throughput and capacity of the system increases almost exponentially and can scale to fit even the largest enterprise.
Depending on the number of hosts in an environment, a deployment may require a large number of agents. Agents are unobtrusive and secure. When an installed agent is started, it opens a socket connection to the Deployment Automation server. Communication between server and agents is based on a JMS (Java Message Service) protocol and can be secured using SSL, with optional mutual key-based authentication for each end-point. This communication protocol is stateless and resilient to network outages. For details about the benefits of statelessness, seeAgent communication.
While an agent is characterized as a single process, technically an agent consists of a monitor process and a worker process, as displayed in the following figure.
- The monitor is a service that manages the worker process, for example, starting and stopping and handling restarts, upgrades, and security.
- The worker is a multi-threaded process that performs the actual deployment work after receiving commands from the server.
- Work commands come from plugin steps, which provide seamless integration with many third-party tools.