By now you are aware that DCE consists of a number of major components, each of which addresses some necessary aspect of distributed computing: DCE Threads make programs more efficient by allowing parallel execution of portions of code, remote procedure calls (RPCs) hide network details from applications, the DCE Time Service gives consistent time to widely scattered cells and hosts, the DCE Security Service gives programs assurances that users and other programs are who they say they are and that they are authorized to do what they are supposed to do, and the DCE Directory Service helps clients find servers and other resources. For most applications, a DCE component is not used by itself, but the components all work together to create a very useful and powerful environment.
The more you understand DCE and its components, the more you will realize that a strict division by component is not always clear. The document set for DCE is organized by component mostly for the convenience of people trying to explain and understand DCE, but applications often contain a blend of aspects of all the components. This is why it often seems like the information you need to do your work is scattered across many topics or volumes, and why advanced or unusual features seem to be described along-side basic or typical tasks. DCE also has some special facilities that just do not fit neatly into any one discussion of a DCE component, and these are the facilities we describe in this first part of the OSF DCE Application Development Guide - Core Components.
You should read the OSF DCE Application Development Guide - Introduction and Style Guide prior to using the DCE facilities described here, and you may want to skip to other parts of this guide before learning details about the DCE facilities.
Most DCE facilities are already used by one or more major components of DCE to accomplish some feature they require; others are standalone facilities intended to make developing distributed applications easier. These facilities are described separately here so that you can use them for your own applications too. The DCE facilities include the following:
· Host Services
Host services give remote access to several kinds of data and functionality with respect to each DCE host and its servers. Each host runs a DCE host daemon (dced) as the interface to the host services. In many cases, dced automatically maintains the data and performs the functions. Some of the data that you can access (and maintain) remotely includes the host name, the host's cell name, configuration and execution data for all servers on the host, and a database of endpoints (server addresses) through which running servers can be contacted. Some of the functions that you can remotely perform include starting and stopping servers.
· Application Message Service
This service provides a convenient way to manage readable character strings of information that are usually displayed to application users. The service uses message catalogs to maintain message text and explanations separate from the program so that language, cultural, or other site-specific issues are easily managed for applications. The message text can also be in memory during program execution for more efficient programs.
· Serviceability
Serviceability is another kind of message text service with functionality beyond just the display of general-purpose text. Serviceability is typically used for message text about a server's activity. Messages can be displayed through standard output or standard error, or they can be routed to log files. The serviceability facility maintains message text in catalogs (or memory) just as the application message service does; but, in addition to the text and its explanation, additional attributes specify subcomponents (program modules), message severity, the action users or programs should take, and the debug level.
· Backing Store Database Service
You use a backing store to maintain typed data between invocations of applications. For example, you could store application-specific configuration data in a backing store, and then, when the application restarts, it could read the previous configuration from the backing store. Data is stored and retrieved by a Universal Unique Identifier (UUID) or character string key, and each record (or data item) may have a standard header if you wish.
As DCE has developed and improved, useful facilities such as serviceability have been added to make DCE easier and more useful. For example, serviceability makes a distributed application much easier to develop. With it, you can log and distinguish debug messages from complex applications involving multiple clients, servers, and threads. Although the major components are required to make DCE work, this kind of facility is not required.
Some solutions developed to implement a major component's feature can also prove useful to your applications. For example, the security component must have a way to maintain access control lists (ACLs). While the backing store was developed to handle this kind of task, you can use this facility to store your own application-specific data across invocations.
This first part of the OSF DCE Application Development Guide - Core Components describes how you might put these useful facilities to work in your applications.