Every DCE server requires some management. At a minimum, servers need to be started and stopped. In addition, servers usually provide generic server information such as the server principal name and an indication that the server is listening for remote calls. Servers may also permit other kinds of management operations while they are running; it is perfectly feasible to have a server reinitialize or even unregister and reregister endpoints while it is running.
From the management perspective, servers are thought of as either on-demand or persistent. In the on-demand model, a server only starts (thus occupying system resources) when it is needed. When an on-demand server is installed, a startup configuration is also installed with dced. Such a server would then use the configuration (obtained by a call to the dce_server_inq_server( ) routine) when it is auto-started by dced on receipt of an RPC request for an interface, operation, or object registered for that server.
A persistent server is one that runs continuously. Starting, stopping and otherwise managing such a server are typically considered privileged operations. In general, a robust persistent server should provide a separate application control program that calls the DCE management interfaces (APIs for dced, RPC, and the like) and the application's own management interface (if one is provided). Of course, a server cannot start itself, but an application control client program can start the server via the dced. The model looks something like that shown in the following figure:
Managing a Server with a Control Client
In addition to starting and stopping the server, the dced management routines provide other control operations. For example, the control program can use dced_server_disable_if( ) and dced_server_enable_if( ) to disable and reenable specific interfaces offered by the server. Application-specific management operations can be used to exert even finer control than is possible with the DCE-provided services.