DCOM Explained
by Rosemary Rock-Evans Digital Press ISBN: 1555582168 Pub Date: 09/01/98 |
Previous | Table of Contents | Next |
|
If you want to build a distributed application, the last thing you need is to be told is that the middleware you have available, to act as the infrastructure, only runs on Windows with links to the IBM mainframe. Given the number of other perfectly good (even excellent) middleware products there are around, no one would blame you for deciding to use TOP END, Tuxedo, or DCE instead, for example, which run on numerous platforms, so would provide no limit on your design or how you connected up your existing systems and databases. DCOM may be free with Windows, but if it doesnt work with the other platforms you need to incorporate in your design, it isnt a lot of use.
You shouldnt have to migrate your systemsyour heritage systems, your working systems, your working databasesto new platforms. Really good middleware enables you to link them all up. Your companys investment in those systems can be preserved, and you can be saved the tedium of pointless migration (a thankless task at the best of times as most end users consider it a waste of money and time).
So this chapter is particularly important for those of us that believe the D in DCOM should stand for more than distributed over a Windows network. We will be seeing that DCOM is being ported to other platforms, but the number of platforms is still limited and the functionality is not as rich as on the Windows platform itself.
Figure 11.1 DCOM on other platforms
Let us start this chapter by first looking at what platforms DCOM already exists on or is being ported to. DCOM was released with Windows NT version 4 (Workstation and Server) in 1996. DCOM for Windows 95 was put into beta in mid-1996 and released towards the end of 1996. A beta version of DCOM for the Apple Macintosh was made available in 1997 (running under Windows).
The draft version of the COM specification was released for third parties in October 1995. DCOM was by this time already in development, but the specification was for use by external third parties. The specification was a joint development by Digital and Microsoft.
There are four companies involved in the porting at the momentDigital, Hewlett Packard, Software AG, and Silicon Graphics.
Digital-is porting DCOM to Digital Unix and OpenVMS. Note that it will only be OpenVMS on the Alpha, not VAX/VMS, and there are no plans to support the VAX. The ports are actually being based on Software AGs port. Source code is also being supplied by Microsoft. Work started on the port in August 1996, and when I wrote this the ports were due mid-1998.
As part of the port, Digital plans to also provide compiler support for Microsofts C and C++ as well as providing a Java Virtual Machine on Open-VMS. They intend to support the Win32 API using (probably) Bristol technologys software.
The ports will be limited to the TCP/IP network protocol because DCE is being used as the underlying infrastructural software to support the ports. Digital is having to do some work to get Microsofts MS RPC to talk to the DCE RPC, particularly adding NTLM authorization to OpenVMS to provide the equivalent authenticated RPC mechanism which Microsoft uses. But you dont need to worry about this too much.
You also wont need to worry about installing DCE when you use DCOM on the other platforms; it will come as part of the port. If you want to find out more about Digitals ports, they have a Web sitehttp://www.openvms.digital.com/openvms.
Software AG-was the first company to get involved with ports of DCOM and it terms these additional ports DCOM FTE (For the Enterprise).
It is concentrating on developing ports of DCOM for midrange Unix and mainframe systems. The ports it is planning to release or has already released are for Solaris, Digital Unix, OpenMVS, Linux, AIX, Sinix, OS/400, and SCO UnixWare. Further ports to HP-UX and OpenVMS are also planned though this may change with Digital and HPs involvement. On MVS, the developer must have the POSIX-compliant version of MVS.
Microsoft entered into the partnership agreement with Software AG at the time Windows NT version 4 was being developed. The partnership wasnt announced until October/November of 1996, by which time Software AG was well underway developing the ports of DCOM to other platforms.
Software AG in the United States worked with Microsofts Windows NT team to develop the ports, and a test version for Sun Solaris 2.5 was made available in October 1996, where it could be freely downloaded. At the time, the versions for Digital Unix and OpenMVS were under development.
IBM OpenMVS, Linux (on Intel), and Digital Unix beta kits were released in the first half of 1997. Platforms scheduled to begin beta testing in 1998 were the OS/400, OpenVMS, and SINIX.
Software AG and MainSoft have formed a partnership to trade technologies based on DCOM. Under the agreement, announced in December 1996, Mainsoft was responsible for putting the Win32 APIs onto Unix. Software AG also used MainSofts DCOM automation technology and structured storage system. Both companies are Microsoft source code licensees.
As we saw earlier, DCOM on the Windows NT platform is highly integrated with basic operating system services such as thread management, memory management, and I/O functionality. On Windows NT these services are provided by the kernel system and typically present a callable interface in the Win32 set of functions.
DCOM FTE contains an implementation of a subset of the Microsoft Windows NT Kernel services (Win32 service routines). This implementation provides the basic services required for the DCOM FTE runtime environment on Unix. Rather amusingly it has been dubbed the Mutant, so if you hear anyone asking if you have a mutant on your Unix machine, theyre not talking about Turtle games, theyre talking about DCOM!
The Mutant provides the system services required by DCOM FTE plus additional APIs, which Software AG feels are needed for DCOM applications. When I write this, support for Win32 GUI-related APIs (Windows, Windows Messages, Drawing, primitives, and so on) werent supported, but no doubt they will be in the course of time.
Previous | Table of Contents | Next |