OSF DCE Application Development Guide--Introduction and Style Guide

Introduction to DCE Application Programming
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
appliction 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 sugggestions: you will
certainly develop your own DCE programming style as you develop DCE applications.
1.8.3 General Policies
The Style Guide embodies a variety of basic assumptions. These form the basis for a set
of high-level policy recommendations that cross the boundaries of the specific services
discussed in later chapters. These are as follows:
• Servers are generalized providers of the services specified by their published (IDL)
interfaces. That is, servers should encapsulate the services they provide in such a
way that naive clients, with no knowledge of the specifics of server implementation,
can successfully make use of these services via the remote interfaces. In this sense,
servers are much like libraries. One should not assume that clients will be written by
someone with knowledge of server internals. Where appropriate, define wrapper
routines for the IDL operations to shield developers from binding handles and other
RPC peculiarities.
• Servers should make their resources known to clients using standard mechanisms. In
particular, they should export their bindings according to the recommended service
models, use name and endpoint services rather than fixed bindings and well-known
endpoints, and associate exported objects with UUIDs.
• Clients and servers should be portable, using DCE provided mechanisms instead of
operating system and transport-dependent mechanisms. For example, data streams
should be communicated via the RPC pipe mechanism rather than socket calls. The
AES/DC is the definitive guide to application portability using the DCE mechanisms.
• Distributed applications make greater administrative demands than nondistributed
ones. Clients and servers need to be written with an eye to minimizing and
simplifying administrative tasks. This means, for example, that
124246 Tandem Computers Incorporated 1− 37