OSF DCE Application Development Guide--Introduction and Style Guide

OSF DCE Application Development Guide—Introduction and Style Guide
The distinction between policy and style is itself somewhat vague. In general, policy
refers to the things you should do in an application program. You can usually identify a
policy recommendation because the words ‘‘should,’’ ‘‘must’’ or ‘‘recommended’’
appear. Style is a more general term that includes policy (hence ‘‘Style Guide’’), but that
also covers a variety of other suggestions about how you might do things. Much of the
sample code included in the Style Guide embodies not only the recommended policies,
but also provides illustrations of possible styles of usage. Such suggestions are intended
to be helpful, but unless they are couched in the language of policy, should be considered
entirely optional.
1.8.2 Policy and Style Issues
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.
1− 36 Tandem Computers Incorporated 124246