| DCOM Explained by Rosemary Rock-Evans Digital Press ISBN: 1555582168 Pub Date: 09/01/98

Previous | Table of Contents | Next

The generated stub code performs functions associated with the manipulation of the data structures. The reasons why should be obvious. The stub code is generated from information you give it about the interface—in effect the structure of the data going across the network. It is obvious that the code is thus going to deal primarily with data structures. Hence, for example, it does things like:

  • Pack and unpack the data structures
  • Convert individual data items into a format which can be both passed across the network and converted from one machine format to another (if an intermediate common protocol such as the ASN (Abstract Syntax Notation) Basic Encoding Rules has been used, both conversion to the common format and conversion from the common format may be performed)

Figure 7.2 IDL compiler used to generate stubs

The runtime library functions, in contrast, are responsible for functions such as:

  • Handling network communication errors—and recovering from the errors
  • Coordinating the request/reply messages between client and server managing all network synchronization of clients and servers, establishing connections, and coordinating transmission
  • Managing sessions between multiple clients and server processes

In essence, the stubs perform data-related processing and the runtime library performs communication-related services.

### MS RPC and DCOM

So how does all of this relate to DCOM? What happens to turn a method call into an RPC? When a programmer uses DCOM, he or she invokes a method on an interface using certain arguments. The method call is translated within DCOM into a call to a remote procedure call. The procedure in this case is equivalent to a method found within a component.

Similarly, when a DCOM service is invoked using a method call on a DCOM interface, this, too, is translated internally into a remote procedure call—a call on a method within a DCOM service component. This translation is easy because the paradigms used for component invocation and that used for remote procedure calls are so similar. When the programmer uses components he or she is actually looking at a group of methods described by an interface.

Figure 7.3 Interface on a class or component

When the programmer uses a remote procedure call he or she is looking at only one of those methods. As Procedures are also defined by Interfaces, the similarities between RPCs and Component invocations are obvious.

Figure 7.4 Interface for an RPC

In fact, the only difference is that the interfaces used for component invocation group methods together around the concept of the class. Whereas, with RPC Interfaces, no grouping takes place, each method has one interface.

### MS RPC and DCE RPC

MS RPC is based on the OSF/Open Group’s DCE RPC. Why is this important? It is of exceptional importance because it is via the DCE RPC mechanism that communication with non-Windows platforms is being achieved.

In effect, on Windows platforms, Microsoft uses their own MS RPC mechanism to support distributed processing across machines and across the network, but where communication is between a Windows machine and a non-Windows platform such as Solaris or Digital Unix, the DCE RPC mechanism is used.

DCE RPC and MS RPC can communicate with one another because Microsoft based MS RPC on DCE RPC. Microsoft did not use the OSF’s code to produce their implementation but used the API and developed their own code. The implementation is thus DCE compliant but is not OSF sourced. Some differences in approach between MS RPC and DCE RPC did creep in during the development of MS RPC, but these are being sorted out by the DCOM vendors themselves, so the developer does not need to worry too much about this.

### So What Is DCE?

DCE stands for Distributed Computing Environment. It is a standard developed by the OSF (Open Software Foundation), now the Open Group. DCE is not a specification, however. It is provided to potential vendors as source code, which they then adapt to ensure the code works successfully on their platforms.

Altogether DCE is now ported successfully to about 30 hardware environments including not only numerous flavors of Unix, but many “proprietary” operating systems such as GCOS and VMS. DCE is middleware in its own right, and many people are using it to develop distributed applications. It was designed for use in an enterprise-wide capacity—a middleware product that could support many types of application across the enterprise, and many of its features are geared towards enterprise level use—its Directory services, its thread support, its security support, and so on.

The architecture of DCE is shown below, together with its relationship to other software such as the application. Software outside the scope of DCE is shown using dark shading; software within the scope of DCE, but which is still being developed, is shown using light shading.

Figure 7.5 Architecture of DCE

As can be seen from the picture, DCE is far from just the RPC mechanism which Microsoft uses DCE actually includes a Threads service, security service, Directory service, time services, as well as Distributed File support. Microsoft has, in effect, used only a small part of DCE—its RPC mechanism—to develop their own MS RPC.

Although this book is not about DCE, I will, in the next few paragraphs, provide you with a brief description of DCE so that you can see what it does and how it works. This may seem irrelevant to you if you want to use DCOM, but you need to bear in mind:

  • First, that your company may be using DCE anyway and you may have to interface to it when you are developing your DCOM applications.
  • Second, that companies providing DCOM implementations on other platforms are going to be using some of the DCE services in their ports to provide equivalent services for security or thread support, for example.
  • And, third, that Microsoft is actively thinking of using some of these DCE services themselves anyway—particularly the security services—so in the future you will need to know how they work.

Previous | Table of Contents | Next