The service controller is the first process that runs on top of the EGO kernel. It functions as a bootstrap mechanism for starting the other processes in the cluster. It also monitors and recovers the other services. It is somewhat analogous to init on UNIX systems or Service Control Manager on Windows systems. After the kernel boots, it reads a configuration file to retrieve the list of services to be started.
The service controller acts as a client to the EGO kernel, requesting resource allocations for running services and instantiating activities to host those services. It ensures that all the defined services are running by detecting failures and restarting service instances based on the parameter settings in the Control Policy portion of the service profile.
The service controller also provides APIs to allow other tools to instantiate, control, and query services at runtime.
The service controller reads configuration files for services that must be instantiated. The configuration files are XML documents (service profile) that contain the service definition (that is, parameters that define the type of resources the service instances need to run along with how to start and monitor the service instances). These files can be created either by the service controller administrator or by the API during runtime. There is one service definition file dedicated to each service.
Service controller start-up sequence:
One of the hosts within the cluster is elected as the master. The master host, in turn, starts the EGO kernel, which then starts the service controller on the same host.
The service controller opens a connection to EGO and registers as a recoverable client.
The service controller loads the service definition database containing the list of services that need to be instantiated.
The service controller recovers the latest state info from EGO and starts and stops services following the service definitions from the database. The service controller is ready for service.