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 interfacein 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:
Figure 7.2 IDL compiler used to generate stubs
The runtime library functions, in contrast, are responsible for functions such as:
In essence, the stubs perform data-related processing and the runtime library performs communication-related services.
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 calla 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 is based on the OSF/Open Groups 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 OSFs 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.
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 capacitya middleware product that could support many types of application across the enterprise, and many of its features are geared towards enterprise level useits 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 DCEits RPC mechanismto 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:
Previous | Table of Contents | Next |