There are two agent types. Web agents use WebSocket connections and HTTP(S) for agent-server communication. Web agents were introduced with version 7.0.0. Agents delivered before version 7.0.0 are called JMS agents. JMS agent use JMS and HTTP(S) to communicate with the server. You determine agent type when you install the agent.
Agents do the actual work of deploying components and so relieve the server from the task, making large deployments that involve thousands of targets possible. Usually, an agent runs on the same host on which the resources it handles are located. A single agent can handle all the resources on its host. If a host has several resources, an agent process is started separately for each one. Depending on the number of hosts in an environment, a deployment might require many agents. For 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. A deployment to this environment might have one agent and three separate resources.
Agents have one or more matching agent resources, which represent the agents in the resource tree.
Agents are installed with the batch files that are provided with the installation files, see Installing agents from the command line. You can install agents on UNIX systems with the web application. Agents are run with the batch files that are included with the installation package.
Agents are unobtrusive and secure. Agent communications use SSL encryption and mutual key-based authentication for server-agent communication and employ JMS, HTTP, and HTTPS protocols to communicate with the server. See Agent security and communication.
Agent configuration consists of assigning an agent to at least one environment; agents can be assigned to multiple environments. If an agent is assigned to several environments, it can do work on behalf of all of them.
To manage agents, see Agents and agent relay configuration.
If you create a resource template instead of importing a resource template from the cloud, you can specify an Agent Name Pattern for any agent prototype that you add to the resource template. The agent name pattern can include the properties ${p:application.name} and ${p:environment.name}, but no other properties or wildcards.
Along with an agent's uuid, an agent has an endpoint ID that is generated as part of an agent installation process. An agent's endpoint ID is found in conf/agent/installed.properties file of your agent install directory with the property name locked/agent.id. This endpoint ID is broadcast to the server when the agent connects and is used by the server to uniquely identify any given agent. When an agent is restarted and connects back to the IBM UrbanCode Deploy server, the IBM UrbanCode Deploy server identifies the connecting agent by its endpoint ID and matches it up with the agent uuid.
You must use the server-side generated agent uuid only while managing an agent as it is more accessible than the agent's endpoint ID which is never intended to be seen by end-users.