acsdaemon::ServiceDefinitionBuilder Interface Reference

import "acsdaemon.idl";

Inheritance diagram for acsdaemon::ServiceDefinitionBuilder:

[legend]Collaboration diagram for acsdaemon::ServiceDefinitionBuilder:

[legend]List of all members.

Public Member Functions
void	add_naming_service (in string host) raises (ACSErrTypeCommon::BadParameterEx)
void	add_notification_service (in string name, in string host) raises (ACSErrTypeCommon::BadParameterEx)
void	add_xml_cdb (in string host, in boolean recovery, in string xml_cdb_dir) raises (ACSErrTypeCommon::BadParameterEx)
void	add_manager (in string host, in string domain, in boolean recovery) raises (ACSErrTypeCommon::BadParameterEx)
void	add_acs_log (in string host) raises (ACSErrTypeCommon::BadParameterEx)
void	add_logging_service (in string host, in string name) raises (ACSErrTypeCommon::BadParameterEx)
void	add_interface_repository (in string host, in boolean load, in boolean wait_load) raises (ACSErrTypeCommon::BadParameterEx)
void	add_services_definition (in services_definition_xml definition) raises (ACSErrTypeCommon::BadParameterEx)
boolean	is_valid (out string error_description)
services_definition_xml	get_services_definition ()
void	close ()
Public Attributes
readonly attribute short	acs_instance_number

---

Detailed Description

Allows a client of a services daemon to first define the setup of ACS services and later to start all these services. The various add_ methods can be invoked in arbitrary order because the correct parallel/serial startup of the selected services is the responsibility of ServicesDaemon#start_services. For the different options to start ACS services, see the description of ServicesDaemon.

Note that clients must call close when done with an object of this type.

---

Member Function Documentation

void acsdaemon::ServiceDefinitionBuilder::add_acs_log (  in string  host  )  raises (ACSErrTypeCommon::BadParameterEx)

Starts an ACSLog service (used by Python components and any corba-aware scripts to contribute log records to central logging). Parameters: host  Hostname Returns: void

void acsdaemon::ServiceDefinitionBuilder::add_interface_repository (  in string  host, in boolean  load, in boolean  wait_load )  raises (ACSErrTypeCommon::BadParameterEx)

Starts an interface repository. Parameters: host  Hostname load  If true, the IFR is not only started, but also the loading with all IDL files is triggered. Otherwise the IFR stays empty and should be loaded by an explicit execution of "acsstartupLoadIFR". This parameter has the opposite meaning of the flag "-noloadifr" in the acsStart script. wait_load  If true and load==true, then ServicesDaemon#start_services will wait for the IFR loading to finish. This is the opposite of the flag "-nowaitifr" in the acsStart script. Returns: void

void acsdaemon::ServiceDefinitionBuilder::add_logging_service (  in string  host, in string  name )  raises (ACSErrTypeCommon::BadParameterEx)

Starts a logging service. Parameters: host  Hostname name  name of the log service. If name is null, then "Log" will be used. Returns: void

void acsdaemon::ServiceDefinitionBuilder::add_manager (  in string  host, in string  domain, in boolean  recovery )  raises (ACSErrTypeCommon::BadParameterEx)

Starts a manager. Parameters: host  Hostname domain  The manager's domain. Should be empty or null if manager federation is not enabled. recovery  if true then use recovery information from previous run. Returns: void

void acsdaemon::ServiceDefinitionBuilder::add_naming_service (  in string  host  )  raises (ACSErrTypeCommon::BadParameterEx)

Starts a naming service. Parameters: host  Hostname Returns: void

void acsdaemon::ServiceDefinitionBuilder::add_notification_service (  in string  name, in string  host )  raises (ACSErrTypeCommon::BadParameterEx)

Starts a notification service. Parameters: name  Notification service name, either one of the systemNotificationServiceXyz string constants or the name of an optional notification service. host  Hostname Returns: void

void acsdaemon::ServiceDefinitionBuilder::add_services_definition (  in services_definition_xml  definition  )  raises (ACSErrTypeCommon::BadParameterEx)

Allows adding existing definitions, which should be obtained from a previous call to get_services_definition. These definitions will be merged with those from the other add_ method calls. The ACS instance number of the given definition will be ignored, i.e., acs_instance_number remains unchanged. Note that this method can be used to convert a preconfigured services description to a different ACS instance: just create a new ServiceDefinitionBuilder instance with the desired ACS instance, and feed the existing service description. Todo: Should we specify that illegal duplicate services will be stripped off automatically? If not, then this method would be useless for merging real configurations with one naming service each, but still could be useful to add a setup snippet about optional notification services etc. Perhaps the typical usage will be for system integrators to dynamically construct a services description from a few disjoint building blocks, in order to reuse commonalities among operational and testing environments while having some services run differently.

void acsdaemon::ServiceDefinitionBuilder::add_xml_cdb (  in string  host, in boolean  recovery, in string  xml_cdb_dir )  raises (ACSErrTypeCommon::BadParameterEx)

Starts a CDB service. About the TMCDB, see ServicesDaemon::start_xml_cdb Parameters: host  Hostname recovery  if true then use recovery information from previous run. xml_cdb_dir  the directory which contains the CDB directory, see env var ACS_CDB. Returns: void

void acsdaemon::ServiceDefinitionBuilder::close (   )

This method must be called when the ServiceDefinitionBuilder instance is no longer used (typically after calling get_services_definition). It allows the factory (services daemon) to release allocated resources. The instance must not be used afterwards. Note that the services daemon imposes a limit of 10 active ServiceDefinitionBuilder instances to protect itself from misbehaving clients, which means that failures to call "close()" will eventually lead to failures in subsequent calls to ServicesDaemon#create_service_definition_builder.

services_definition_xml acsdaemon::ServiceDefinitionBuilder::get_services_definition (   )

Serializes the current service description to XML, to be used as parameters of ServicesDaemon#start_services and ServicesDaemon#stop_services. To allow the serialization of a partially complete services definition, this method does not check/enforce the validity of the services. See is_valid. The format of this XML is subject to changes between ACS releases, but for any given ACS release, a client can also store this service description and use it directly with the ServicesDaemon, without going through this ServiceDefinitionBuilder again.

boolean acsdaemon::ServiceDefinitionBuilder::is_valid (  out string  error_description  )

Validates the services definition that has been built up. This method can be used for error display by interactive clients, or to log errors when using preconfigured service definitions. Note that get_services_definition() will not enforce a valid service description! Parameters: error_description  Empty if the current definition is valid. Otherwise a description about the problems, e.g. "Missing services: CDB, manager. Illegal multiple definition of: naming" Returns: true if the services definition is valid.

---

Member Data Documentation

readonly attribute short acsdaemon::ServiceDefinitionBuilder::acs_instance_number

The ACS instance number as specified in the factory method.

---

The documentation for this interface was generated from the following file:

• acsdaemon.idl

---