Previous | OpenFusion Graphical Tools | Next |
The Administration Manager is used to configure the OpenFusion Services and to manage (stop and start) the Services. The Administration Manager is extensible and can be used to configure user-created Java Objects.
The Administration Manager has two panes:
The left-hand pane of the Administration Manager shows all services, Singletons, and Java Objects, and the domains that contain them, in a tree structure.
Domains are high-level organisational units. The default hierarchy shows all installed OpenFusion Services under a single domain. This hierarchy can be restructured and extended as required, as described in Extending the Object Hierarchy.
Nodes represent actual hardware devices within the domain and are given the name of the machine they represent. The default hierarchy shows the local machine as a node called localhost. This node can be deleted and replaced with a node which uses the computer name, if required. There is no difference, functionally, between using the machine name and the name localhost.
A Service is a logical group of Singletons and Java Objects that are controlled together. Groups of Services can be started together at the node or domain level.
Each of the OpenFusion Services is represented by a Service node in the Object Hierarchy. New Services can be created, which can contain different permutations of Singletons and Java Objects.
Every Service should contain a ProcessSingleton. The ProcessSingleton is the object which allows the Service to be controlled from the Administration Manager.
Every OpenFusion CORBA object is represented by a Singleton in the Object Hierarchy. Additional Singletons and Java Objects can be added to the hierarchy, either to existing OpenFusion Services or to user-created Services.
Java Objects should be co-located with CORBA Singletons in a Service. A Service which contains Java Objects and no Singletons cannot be monitored correctly for its status and cannot be controlled from the Administration Manager.
See Extending the Object Hierarchy for details of adding nodes, Services, and Singletons. See Distributed Installation Configuration for details of how multiple nodes can be managed from a central host.
Every node in the Object Hierarchy has an associated tool tip which provides information about that node. To see the tool tip, hover the mouse pointer over the node.
The tool tip gives the type of node (Domain, Service, Singleton, etc.), the name of the node, and the status of the node (see Status).
Different nodes in the Object Hierarchy are identified by different icons.
A coloured icon in the Status column of the tree view shows the current status of each service.
Parent nodes can show an indeterminate status. This is used when the node's child nodes have mixed status (for example, some are stopped and some are started).
The status is also shown in the tool tip for each Service.
Services can be started or stopped individually.
To start a service, right-click on the service name in the Object Hierarchy and select Start from the pop-up menu.
To stop a running service, right-click on the service name in the Object Hierarchy and select Stop from the pop-up menu.
Some properties cannot be modified after a service is started, so the service must be properly configured beforehand.
To start (or stop) a collection of services, right-click on the services' parent node and select Start (or Stop) from the pop-up menu. Services are started and stopped in the order they appear in the Object Hierarchy.
If an object hierarchy node cannot be started (that is, the option is disabled), then it is likely that it has an unlicenced child node or that the Node object hierarchy node is not valid for the hardware device that the Administration Manager is being invoked from, noting that localhost is always valid.
Before a service is started, the system automatically saves the service configuration. If there are mandatory properties for the service which have not been completed, the service will not start, a warning will be displayed, and the missing property will be noted in the browser log.
The Object Hierarchy can be extended with new Domains, Nodes, Services, Singletons, and Java Objects.
The default Object Hierarchy shows all installed OpenFusion Services grouped under a single node under a single domain. Extending the Object Hierarchy provides a more flexible approach to managing the OpenFusion installation.
For example it may be necessary to run a particular Service in different configurations at different times. Instead of re-setting all the properties for the Service when it is run in another configuration, copies of the Service could be created under different domains. Each could be configured with the required properties. Then, to switch between configurations, simply stop one domain and start the other.
Another use for multiple domains would be to set up different combinations of Services that should be started together.
Nodes can be used to represent different servers within the domain.
New Services can be created to manage user-created Java Objects.
Other ways of grouping domains, nodes, and services will suggest themselves based on the way OpenFusion is used in a particular installation.
Domains and Services are simply organisational groupings and can be added without restriction.
Nodes represent hardware devices running CORBA Services. A node can only be managed through the Administration Manager if it is given a valid device name (localhost is always valid).
To add a node, right-click on the parent node and select Add Domain, Add Node, or Add Service (the command depends on the level you are adding to) from the pop-up menu.
Enter a name for the node. Node names must be unique within the scope of their parent nodes. You can re-use a name if it is under a different parent. Names can only contain alphanumeric characters.
When a new Service is added, a ProcessSingleton is automatically created beneath it. This allows the service to be managed by the Administration Manager: it is not recommended that users have a service without a ProcessSingleton.
Singletons and Java Objects can only be added under Service nodes of the Object Hierarchy.
Singletons and Java Objects in the Object Hierarchy are representations of underlying objects and so only objects which already exist are available for adding to a Service.
The Resolve Name of the Naming Service Singleton must be unique within the whole Domain, not just within the scope of the parent node (localhost by default). The Resolve Name must be unique to avoid the possibility of two objects attempting to register themselves in the NameService with the same name.
To add a Singleton or Java Object, right-click on a Service node and select Add from the pop-up menu. Select either Singleton or Java Object to see a menu of available objects. Objects that cannot be added to the Service are greyed-out. Select the required object from the list.
It is not possible to have two instances of the same Singleton or Java Object under one Service.
If the same Singleton or Java Object is added under two different Services, they are two separate instances and properties changed in one instance will not affect the other instance.
To delete a node from the Object Hierarchy, right-click the node and select Delete from the pop-up menu.
When a node is deleted, all children and all properties and settings of that node are also deleted.
A deleted node cannot be recovered, but a new node with the same name as the deleted node can be added later.
The order of Services beneath nodes and Singletons/Java Objects beneath Services can be altered. The order is important as it determines the sequence in which Singletons and Java Objects will start when a node is started.
To move a Service, Singleton, or Java Object higher up the list, right-click on the node and select Start Earlier from the pop-up menu.
To move a Service, Singleton, or Java Object down the list, right-click on the node and select Start Later from the pop-up menu.
The ProcessSingleton is always the last Singleton in a Service and cannot be moved up.
Locking a property prevents that property from being updated. Single properties can be locked selectively, or an entire node in the Object Hierarchy can be locked.
This is not intended as a security measure. It is a simple matter to unlock a locked node or property. The purpose of the lock is to prevent accidental changes, and to prevent global changes from cascading through to a locked property.
Locking a property in the Administration Manager browser does not lock the property in the underlying CORBA object and does not prevent the property being changed programmatically.
The locked state of nodes and properties is saved when the browser is closed, so locks are restored when the browser is reloaded.
To lock a node in the Object Hierarchy, check the box in the Lock column for that node. To unlock the node, clear the checkbox.
Locks cascade to nodes lower in the hierarchy. If a Service is locked, the Singletons under that Service are also locked. If a domain is locked, the entire hierarchy under that domain is locked.
Nodes which have been locked by a cascade from a node higher in the hierarchy display a padlock icon in the Lock column. These nodes cannot be unlocked individually; the parent node much be unlocked first.
When a node is locked, all properties for the node are locked and cannot be individually unlocked. You can, however, selectively lock properties without locking an entire node. If a property is selectively locked and then a lock is applied to a higher node, the individual lock is retained if the higher lock is removed.
Starting a Service node can also cause some of the properties for that Service to be locked. Whether a property is locked or not when the Service starts is determined by the Type of the property (see Type).
Properties can be locked for a number of reasons. Locked properties display a padlock icon in the Lock column and are coloured grey.
When a node is locked, all properties for that node automatically become locked. The only way to unlock these properties is to unlock the node.
Some properties are locked based on Type (see Type):
Some properties are locked based on the value of another property. For example, if the Security Enabled property for a service is checked, the other properties on the Security tab are unlocked and available. If the Security Enabled property is unchecked, then the other security properties are not needed and are all locked.
Any property can be locked individually, at the user's discretion. To lock a single property, check the box in the Lock column for that property. To unlock the property, clear the checkbox.
It is possible to restore all, or selected, Services and Singletons to their default (as supplied) states.
When a Singleton is restored, the IOR for the Singleton is deleted from the domains directory structure. (See XML Configuration Files for details of how the domains directory structure maps the Object Hierarchy.)
When a Service is restored, the Service's data directory contents and log file are deleted and the IORs for each of that Service's Singletons are deleted.
The Restore command can be used at higher levels of the Object Hierarchy to restore all Services below the selected node.
Use this command with caution.
To restore a Service or a Singleton, right-click it in the Object Hierarchy.
The right-hand panel of the Administration Manager shows the properties for the node selected in the Object Hierarchy.
Each service has properties arranged on tabbed panels. Utilities for service management are in the Service Log and Memory Profiler panels.
The following sections give basic instructions for working with properties. Details of how specific properties can be used for configuring individual Services are described in the sections dealing with each Service.
Every property has a type, which defines how and when the property value can be changed.
If the value of a dynamic property is changed in the Administration Manager while the Service is running, the Set menu option must be used to update the property in the underlying CORBA object (see Set).
Some properties are defined as mandatory. A mandatory property is one which must be given a value before the Service is started and cannot be left blank. Zero (0) is a valid entry for a mandatory integer property.
A node can be saved with mandatory properties left incomplete but a warning message will be displayed.
Properties can be read only or read/write. Read-only properties display information which can never be amended in the Administration Manager. Read/write properties can be amended (unless locked).
Read-only properties are indicated by grey shading. This is the same look as a locked property, but there is no icon in the Lock column for a read-only property.
Some properties will not appear on the Administration Manager property panel because they are conditional properties. These are properties which apply only to specific system configurations. For example, some properties relate to a specific ORB and will not appear on the screen if a different ORB is in use.
A property with a boolean data type has a checkbox in the Value field. If the checkbox is ticked, the property is set to true. If the box is cleared, the property is set to false. To change the state of the checkbox, click it once.
A property with an enumerated data type has a drop-down list of valid values. To set the property, click the arrow at the right of the Value field and select a value from the list.
All other property values accept keyboard input. To set or edit the property, click in the Value field and type the required value.
Some property types are validated and will produce an error message if an invalid value is entered:
If the special characters $$are entered into a property field, the directory path of the current node is substituted. For example, if $$ is entered for a property of the NotificationSingleton, the following string is substituted:
<install_dir>/domains/OpenFusion/localhost/NotificationService/NotificationSingleton
Where <install_dir> is the OpenFusion installation directory and the directory path is entered as a continuous string (no carriage returns).
For example, enter the following to specify the location of the NotificationSingleton.ior file:
$$NotificationSingleton.ior
Note that the $$substitution includes the trailing slash of the directory path, so entering the following text would be incorrect (resulting in a double-slash):
$$/NotificationSingleton.ior
Each type of property has a set of actions which can be performed on it. Right-click the property row to access a pop-up menu of actions.
The following actions are available.
This action resets the counter to zero.
The action is only available for counter properties.
This action retrieves the current value of the property from the underlying CORBA object and updates the Value field of the property.
If the value of an object's property is changed programmatically while the Service is running, the property displayed in the Administration Manager will not be updated unless this action is performed, and therefore can show a false value for dynamic properties.
This action can only be performed while the Service is running (and therefore is only available for dynamic properties).
This action transfers the value of the property in the Administration Manager to the underlying CORBA object.
This action can only be performed while the Service is running (and therefore is only available for dynamic properties).
If the value of a dynamic property is changed in the Administration Manager while the service is running, the property in the underlying CORBA object is not automatically updated. The Set action must be used to update the CORBA object property.
This action copies the value of the selected property to all peers (all objects under the same parent node) which have a property with the same name.
If this action is performed on a Singleton property, the same property for all other Singletons and Java Objects under the same Service will be updated. If the action is performed on a Service property, the same property for all other Services under the same node will be updated.
If it is a dynamic property, the updated value is also set in the underlying CORBA object.
For example, the Storage Type property could be changed to File for the NotificationService and this command could be used to transfer that change to all other Services under the same node.
Properties which are locked (see Locking) are protected from being updated by this action.
This action copies the value of the selected property to all properties in the Object Hierarchy which have the same name. This action is similar to Assign Value to Peers but the change is made over the entire Object Hierarchy.
If it is a dynamic property, the updated value is also set in the underlying CORBA object.
Properties which are locked (see Locking) are protected from being updated by this action.
Assigns a valid UUID to the property.
This action is only available for UUID properties.
Signals are displayed as buttons in a Service's property list.
When clicked, a signal button will trigger some action in the underlying Service. The action each signal button performs will depend on how the signal has been defined and will be described in the documentation for each Service.
A signal will only trigger an action when the underlying Service is running.
To access secured services, a valid user identity must be provided.
The current user identity is displayed in the Administration Manager's status bar. To change the identity, use the Enter user identity tool bar button and enter a user name and password in the User Identity Details dialog box.
Every Service has a log file that can be viewed on the SERVICE LOG tab for the Service. Only the last (most recent) 250Kb of the log file will be displayed.
The log file for each Service can be configured to specify log file location, maximum log file size, the level of information to be logged, and other factors. See Logging Properties for details.
Use the Refresh Log button to refresh the display with the current contents of the log file (the display is not automatically updated when the file contents change).
Use the Delete Log File button to clear the Service Log. This clears the display and deletes the contents of the underlying log file. The Service Log can only be deleted if the Service is not running.
The Memory Profiler for each service shows the total available, used, and free memory in the Java Virtual Machine (JVM) that the service is running in. The total and used memory are also shown as a graph which shows changes over time.
To start the Memory Profiler, select the reporting interval from the Interval drop-down list and click Start. The service must be running or the Memory Profiler will not start. To halt the Profiler, click Stop. Stopping the Profiler freezes the display but does not clear it. Re-starting a stopped graph, however, clears the display.
The scale of the Memory axis (y-axis) changes dynamically in order to effectively display changing amounts of memory.
The Clean button forces immediate garbage collection on the current process. The results of this will be seen as a drop in the Used JVM Memory and an increase in the Free JVM Memory on the Memory Profiler. This operation can be performed even when the Memory Profiler is stopped.
The browser tool bar buttons provide access to a number of common features.
Many of these functions can be performed by using a key combination (control key plus a letter).
If a function is not available in a particular browser, the corresponding button will be greyed-out while that browser is active.
When functions specific to a particular browser are added to the tool bar, the buttons will be described in the section of this Guide which deals with the relevant browser.
Previous | OpenFusion Graphical Tools | Next |