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

Previous | Table of Contents | Next

Thread support-This is undoubtedly the biggest hurdle to overcome.

Let us see why.

DCOM supports multithreading rather than multitasking. In fact, as an architecture it is based on the premise that developers will balance the load on server components using threads. DCOM on the Windows NT platform uses the Windows NT threading service—a service we will be examining in our discussion of Windows NT itself. A vendor porting DCOM to other platforms has three main options open to him in order to provide a threads service. It can:

  • Port the Windows NT thread service to the other platforms it is aiming to support
  • Use the underlying thread service of the operating system and provide a “veneer” to hide this service—translating the Windows API to the operating system API
  • Use a portable threads service—one that has been used in other middle-ware, for example, and again use a veneer to hide the difference in APIs.

All three approaches may be used in the long term. Software AG is actually porting the Windows NT thread service for use in their Unix implementations. Digital is considering the use of the DCE threads service—a service based on POSIX threads and one which gives portability across Unix and other platforms supporting DCE—for their OpenVMS platform.

Clearly, if the Windows NT threads service is ported, the ActiveX component will be portable. But, if the underlying operating system thread service or the DCE thread service is used, we do not believe the threading service can be made completely “transparent” to the developer.

In basic DCOM the programmer has to directly use the thread service, understanding how the threads are created, the different models of thread support given, and the differences in the locking strategies used. Other threads services behave differently, so even though the same API is used, the developer may still have to understand the implications of that API on that thread service—the effects of the locking, the effects of the threads.

So, if the programmer creates ActiveX components for Windows NT which use threads, he or she may have to rewrite this bit of code if he or she wants to use this component on other platforms besides Windows NT. Massive rewrites are not required and rewriting code for every change of platform is not required, but he or she may still have to do some adjustment to get it to perform well on that platform. It would have been so much easier if Microsoft had used the DCE threads service as well as the RPC Because they would then have had a portable cross operating system threads service and none of these problems would have occurred.

Memory management - Memory management is also a service of the operating system in Windows NT, and as memory management is a fundamental function of most programs, the lack of a portable service does pose problems. Again, memory management in DCOM is exposed to the developer, it is not automatic, nor are the commands the programmer must use hidden from him. The rules used are also quite complex, which means the programmer must understand the implications of what he is doing.

The same three options which could be used for threads are not open to vendors who port DCOM, and the vendors are having to port the memory management services within Windows NT (Win32 APIs) in order to provide equivalent services. This is clearly a problem for the vendors but should solve the portability problems for the developer.

### Languages of Development

ActiveX components can theoretically be written in a number of programming languages—C++, Java, Visual Basic, OOCOBOL, or C (though as we saw more work is needed with C because it is not object oriented). ActiveX components written in one language can communicate with ActiveX components written in other languages, as long as MIDL and DCOM are used.

I say theoretically for two reasons. First, components have to be written in a language supporting the notion of function pointers. The language used must also support “structures” containing “double indirected access to a table of function pointers” (because of the Vtable). Since the binary Vtable can be generated easily by most C++ compilers, Microsoft states that the most convenient language to use for components is C++ and is better than, for example, C. Remember, however, that interpreted languages can be supported using the Type Library concept.

Second, we need to remember that when components communicate with one another, they will be passing data from one component in one language to another. The data structures and data types used by one component have to be recognizable by the program language of the other component, so you may have to do some juggling around in your program to enable the data structure sent by a C++ program, for example, to be recognizable by a Java program. Alternatively, the easier approach is simply to only send data of a type recognizable in both languages.

Microsoft’s attitude to Java deserves a special mention. Microsoft sees Java as a potential language of development for all sorts of applications—client, server, and so on, but not the only language. In fact, Java to them is simply another OOPL. Their third-party component builders have used C++, Java, and Visual Basic to build components, and these will coexist with new components built in other languages.

### ActiveX and Standardization

The ActiveX interface is clearly key to the successful widespread use of DCOM, and as such, Microsoft has placed control of ActiveX technology in the hands of the Open Group. The decision to place ActiveX with the Open Group was taken at a meeting of 84 companies in late 1996. The decision was overwhelmingly in favor of the Open Group (63 voted for, 19 preferred a new group, and 2 abstained, of which Netscape was one).

The new group set up within the Open Group to control ActiveX and license ActiveX technologies is called the “Active Group.” This group is controlled by a Steering Committee appointed by and including Microsoft itself. The list of technologies which the Active Group has within their control actually covers more than ActiveX—COM, DCOM, MS-RPC, the Security Provider Interface, OLE Structured Storage Format, the Registry, and Monikers.

Microsoft is equally interested in the Open Group’s Pre-Structured Technology Process, which is a framework for collaboration rather than standardization. One of the first PST initiatives, which was approved by the Open Group members, was geared to integrating ActiveX with DCE services—in reality ensuring DCE services could be invoked from the ActiveX interface, as well as or instead of the DCOM services. This may be especially important in the areas of security. Five or six companies are due to fund this first initiative.

Previous | Table of Contents | Next