Using OODCE

Distributed computing has been possible as long as computers have been on networks, but only recently have sophisticated tools become available to facilitate writing distributed apps in heterogeneous environments. The Open Software Foundation's Distributed Computing Environment (OSF/DCE) is one such environment, providing multithreading, remote procedure call (RPC), time synchronization, security, and uniform naming (for more information, see "Distributed Computing and the OSF/DCE," by John Bloomer, DDJ, February 1995).

DCE applications are typically complex. The DCE libraries contain over 500 functions and data types. Even seemingly trivial applications require nontrivial amounts of code just to cover the basics. In fact, the difficulty of writing real-world DCE applications by hand has long been seen as an obstacle to DCE's widespread acceptance. OODCE, a C++ library originally developed by Hewlett-Packard, greatly simplifies the development of distributed applications.

By encapsulating DCE functionality in C++ objects, OODCE accomplishes several things at once. First, it allows programmers to write DCE applications in C++ style. Secondly, it makes obvious the underlying DCE object model. In the DCE model, a server is responsible for exporting objects to the RPC run time, making them accessible to clients. Each exported object can be seen as an instance of a class defined by an IDL interface specification. For example, a server may export several Coke-machine objects, each of which acts independently. Although these two machines are exported by the same server, one machine may report being empty while another has plenty of Cokes to sell. This aspect of the interface is obscured in the standard DCE interface by the myriad of C APIs required to get anything done. OODCE clarifies this aspect of the DCE object model by expressing it in a set of C++ class hierarchies.

Finally, OODCE simplifies developing DCE applications by hiding details of key components with default behavior, allowing you to specialize the behavior when necessary. For instance, registering a DCE server with the RPC run time occupies two full pages in the OSF/DCE Application Development Guide. Using OODCE, we can get away with only two member-function calls to theServer because the DCEServer class provides reasonable default behavior regarding network protocols, authentication services, and the like. If we don't like that default behavior, we can override it in a subclass of DCEServer. Thus, we can put together a server in record time with the option of fine tuning it later. This aspect captures the spirit of OODCE.

Rather than explain in full detail every part of OODCE, we'll walk through the development of a simple application. This should demonstrate how little effort is required to get a prototype distributed system off the ground. We'll also discuss what else you can (and can't) do with OODCE 1.0.

One key feature of sophisticated distributed computing is interoperability. Sharing data on a homogenous network has been relatively simple for many architectures and operating systems for about 15 years on microcomputers and about 25 years on larger systems. Trying these machines together in a way that transcends both computer architecture and operating system is one of DCE's strengths.

The same principle holds true for DCE development systems. An OODCE server that could talk only to OODCE clients would be of limited utility. Similarly, an OODCE client that could not work with existing C-based servers would be shut out of many applications where legacy servers are in place (and working too well to be rewritten), but where new clients are needed.

For this reason, an OODCE application starts out with exactly the same sort of interface specification as a C-based DCE application, written in the DCE Interface Description Language (IDL). An IDL file describes a specific interface to a server class, including all its potential RPCs and all its data types.

In the C world, an IDL compiler ("idl") translates this file into three output files: two files of C code implementing a set of "stubs" for marshaling and unmarshaling parameters and return codes on both the client and server files, and a header file specifying the function signatures for which the server programmer must provide function implementations.

OODCE takes this a step further with its own IDL compiler, "idl++," which produces the three files of the standard idl compiler, plus four more files to implement the C++ interface. We will describe these files by way of example.

Implementing the client side is even easier. There are no classes to define; we simply make member function calls on a CokeMachine_1_0 object. The default implementation of the client-side classes (here, CokeMachine_1_0) handles binding to existing server-side objects upon construction. It also handles all the RPCs implicitly, so that calls to the member function CokeMachine_1_0 on the client side transparently result in calls to the object CokeMachine_1_0_Mgr on the server side.

OODCE has many virtues beyond rapid prototyping. Not only is naming a server easy, but with a single constructor, cleaning up the CDS namespace can be made automatic upon server shutdown. The default method for locating objects exported by named servers is very simple: Just pass the name to your client object's constructor. A DCETracer class has a trace level that is very useful for tracking the activities of a server. The trace level, of course, can be changed as the server runs. We recommend that no server be passed off to testing or production without DCETracer.

Lastly, security has been made simple. This is one of OODCE's most-significant contributions, but the security classes deserve an article unto themselves.

While OODCE is clearly a step toward creating a reasonable distributed programming environment, there is still room for improvement. For instance, there

is no default behavior for pipes (a convenient way to move large amounts of data between clients and servers in DCE), which would help speed prototyping with them. The distribution of objects is asymmetric, unlike OSF's Request For Comments (RFC) 48.2. In this RFC, references to client-side objects can be passed to servers via RPC, making the client a client/server without requiring extra code. Do not allow RPC exceptions (which are C exceptions) to propagate beyond the scope of any automatic C++ variables, because the C exception mechanism will not destroy these objects, producing memory leaks. Using exceptions with multiple RPC threads is also problematic. This is significant because a server with only one RPC thread isn't much of a server. The OODCE notes indicate that this problem will be remedied in a future release.

So why use C++ at all for DCE applications? C++ has always been a sort of compromise between the high-level expressiveness of languages like Common Lisp and Smalltalk, and the efficiency of languages close to the iron, like C and assembly. It's clearly easier to use a language with automatic garbage collection (like Common Lisp and Smalltalk) than to code the memory management by hand (as in C and C++). But programmers are willing to manage their own memory to facilitate run-time efficiency.

In distributed computing, local run-time efficiency gains are often dwarfed by network communications, which typically consume far more time than memory management. Furthermore, in a DCE-based system, the RPC run time itself has considerable overhead, including a garbage-collection system. Given all this, why stick with C++?

In his book The C++ Programming Language, Bjarne Stroustrup gives four reasons why C++ remained close to the original C model, even when rejecting this heritage might have improved the language. The reasons are essentially cultural: the millions of lines of C code and C-based libraries (he counts this as two reasons), the hundreds of thousands of C programmers, and the need for C and C++ to be used side-by-side.

All four reasons apply to DCE applications at times, but other times it may make sense to break free of the C/C++ model entirely and use a more abstract and more expressive language. OODCE provides an excellent set of tools for making distributed computing about as easy as it could be in C++.

The next major DCE release is billed as having built-in C++ support. It should be available in 1996 (although it took some vendors quite a while to move from DCE 1.0.2 to 1.1, so don't hold your breath). Although 1.2's C++ support shares the goal of facilitating DCE application development in C++, it is not compatible with OODCE.

The C++ component of DCE 1.2 is described in the Open Software Foundation's DCE RFC 48.2, prepared by DEC. Instead of providing a complete C++ class library for DCE programming, RFC 48.2 describes a set of extensions to idl itself for providing distributable objects. (Remember that OODCE goes out of its way not to change the input language of idl.) In doing so, it establishes the "hooks" that a class library (like OODCE) uses to provide complete C++ support for DCE. One very interesting feature of RFC 48.2, which is missing from OODCE, is object-location transparency, which allows use of objects without knowing whether they are local or only proxies representing nonlocal objects. While OODCE may be rewritten at some point to take advantage of this and other features, we know of no plans to do so.

As of this writing, OODCE is only available on HP-UX series machines (HP 9000) running HP's DCE/9000. There appears to be some interest in supporting OODCE on other platforms, but no specific ports have been announced. The Open Software Foundation is currently discussing with HP the possibility of making OODCE part of the OSF DCE source offering, which would help spread it throughout the DCE community.

(a)
void Function()


{


  TheMutex.Lock();


  DoSomething();


  TheMutex.UnLock();


}




(b)
void Function


{


  DCEPthreadLock TheLock


     ( TheMutex );


  DoSomething();


}

void Function
{
  DoSomeInitialWork();
  {
    DCEMutexLock TheLock
           ( TheMutex );
    DoSomething();
  }
  DoSomethingElse();
}

#define LOCK( m ) for(DCEMutexLock
                  __TheLock( m );;)
void Function()
{  
  DoSomeInitialWork();
  LOCK( TheMutex ) {
    DoSomething();
  }
  DoSomethingElse();
}

(defun function()
  (initial-task)
  (with-locks (mutex-one mutex-two)
    (protected-task-one)
    (with-locks (mutex-three)
      (protected-task-two))
  (unprotected-task))