OSF DCE Application Development Guide--Introduction and Style Guide

OSF DCE Application Development Guide—Introduction and Style Guide
The dashed lines in the above figure show the progress of the client’s efforts to get access
to the desired object, which involves acquiring a binding to the junction server, making
contact with it, and passing to it the object’s name. The solid line shows the apparent
direct access to the object that the client’s user seems to enjoy. The dotted lines show
other possible paths of access to the other objects that the server manages.
Junction protocol is generally a private matter between an application’s clients and
servers. However, the acl_edit command uses a generalized protocol.
5.3.2 Junctions and the ACL Editor
The binding routines that acl_edit uses are discriminating enough to detect a junction
anywhere in an entry name that is passed to it. This allows a distributed application to
have its own namespace for objects with ACLs on them, rather than burdening the DCE
namespace by separately exporting binding information for every one of these objects.
The separate objects have to be made publicly accessible somehow because entities
should be able to access ACLs directly, regardless of whether they happen to already be
in contact with the server that manages the ACL’ed object, and indeed regardless of
whether or not they happen to be a client of the particular server to which the objects
belong.
Suppose, for example, a user enters the following in order to interactively edit the ACL
for the printer object cotta, where the namespace entry for a print server is
/.../tinseltown.org/dce/dce_print, and there is no /.../tinseltown.org/dce/dce_print/cotta
entry in the DCE namespace:
acl_edit /.../tinseltown.org/dce/dce_print/cotta
The binding routine, sec_acl_bind(), which is called internally by acl_edit, receives an
error when it tries to bind to the object cotta. However, the DCE Directory Service also
tells it how much of the name it passed is valid. The sec_acl_bind() routine then retries
the binding operation, this time through the valid entry name
/.../tinseltown.org/dce/dce_print and passes the residual part of the name (cotta)as a
parameter. Now it is up to the application ACL manager to interpret the residual name
correctly and find the requested ACL.
5.4 Name Service Terminology
DCE RPC NSI is an RPC-based interface that uses the DCE Cell Directory Service
(CDS) as its database. The NSI routines do not constitute a general interface into CDS
as such; they are a set of specialized routines whose purpose is simply to provide ways
for RPC servers to advertise themselves to RPC clients, and for clients to find and bind to
them.
In fact there is no public general application programming interface (API) to CDS.
There is a general CDS interface that is used internally by the DCE components, but
5− 6 Tandem Computers Incorporated 124246