Remote application programming, using DCE, imposes some special requirements on applications that are not relevant to most local applications. A DCE application is a multicomponent system in which the various components interact dynamically as the program operates. Obviously, the application developer is concerned with creating two major types of components, servers and clients, but these application specific components also enter into relationships with other DCE components. For example, most applications will be clients of naming and security services. Server applications that provide ACL managers may act, in turn, as servers to dcecp ACL commands. Many similar client/server relationships may be created during the operation of a distributed application.
Furthermore, even components that do not communicate directly share common resources, such as directory and security services. Components use these services to exchange specific kinds of data, such as bindings, and such exchanges can succeed only when they are made according to the correct protocols. For example, a server needs to organize the way it exports bindings to a name service so that clients can succeed in finding them. Similarly, clients and servers can only succeed at authenticated communications if the correct registry and ACL data has been created and if each follows the correct incantations to make use of this data.
A particular constraint on DCE applications is that they must take into account the administrative overhead of a distributed system. Servers need to consider such issues as the location and availability of the services they need, the structure of the namespace into which they export their bindings, the DCE identity and privileges under which the server must run, and many similar issues. A successful server will be one that interacts correctly with other components while imposing a minimal load on the DCE environment and, most important, can be successfully and easily administered.
To meet these requirements, application components must interact with each other and with other DCE components in a consistent and well-behaved manner. In this context, one can think of DCE applications as having to meet application-level and administrative interoperability requirements. The Style Guide is, in part, a guide to such requirements. Given the enormous variety of programming and administrative mechanisms that DCE makes available to the programmer, the Style Guide provides a set of policy recommendations for the use of those mechanisms that will maximize the application-level and administrative interoperability of DCE applications.
In addition to being complex, DCE application programming involves elements that are likely to be unfamiliar to many programmers, such as remote parameter passing, name services, and distributed security services. Another goal of the Style Guide is to suggest wise uses for these tools, since many of the familiar local programming models are inadequate. These recommended policies are especially important in the area of security: an application that fails to follow them is likely to be insecure. Recommended policies in some other areas, such as execution semantics and locking, may also fundamentally affect the integrity of a distributed application and should not be lightly ignored. Other policies, such as those relating to parameter passing affect mainly application performance.
The simple unfamiliarity of many of the concepts can make the actual coding of an RPC application a daunting task. In traditional C programming you can usually begin with familiar models - often, with existing code - but with RPC you are unlikely to have such starting points. Therefore, this guide also provides extensive examples that illustrate the basic uses of many important elements. For example, in developing an ACL manager, you may well be able to use the sample ACL manager as a starting point.
The sample code is intended to suggest certain styles of usage that will probably prove useful in many situations. Obviously, these styles are only suggestions: you will certainly develop your own DCE programming style as you develop DCE applications.