The EAC is installed on each machine that runs the Guided Search software and is typically run in a distributed environment.
Each instance of the EAC takes one of two roles:
The EAC is accessible through three methods:
The Deployment Template communicates with the EAC programatically, and is the system of record for storing EAC configuration on disk and for defining or updating application provisioning.
Workbench communicates with the EAC Central Server through the WSDL interface. You can use the EAC Admin Console in Workbench to monitor, start, and stop application components.
The command line utility
eaccmdenables you to script the EAC using Perl, shell, or batch scripts. This utility is recommended for debugging use only.
One instance of the EAC serves as the EAC Central Server for your implementation. This instance includes a WSDL-enabled interface, through which Workbench and the Deployment Template communicate with the EAC.
The EAC Central Server also contains a repository that stores provisioning information — that is, data about the hosts, components, applications and scripts that the EAC manages.
Note
Generally, you should configure only one EAC Central Server to manage all of your Guided Search applications. Provisioning an application with more than one Central Server leads to conflicting instructions being issued across EAC Agents.
All other instances of the EAC serve as Agents. The EAC Central Server communicates with Agents through an internal Web service interface: all command, control, and monitoring functions are dispatched from the Central Server. The Agents, in turn, instruct their host machines to do the actual work of a Guided Search implementation, such as processing data with a Forge component or indexing it using Dgidx.
