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

Previous Table of Contents Next


This approach is excellent from Microsoft’s point of view—they can optimize the performance of DCOM, but it becomes extremely difficult to provide an exact functional match of all the middleware services on other platforms. If Software AG, for example, was to provide an exact copy functionally on the other platforms, it would have to port all DCOM and many embedded Windows NT services to Unix and the mainframe—an almost impossible task. The alternative route, and the one they are taking, is to port some services, but provide access to Windows NT and some other middleware services from the other platforms. What this means is that many services we might find useful are confined to Windows NT, and this situation is not likely to change.

Table 19.1 Platform support
Operating system DCOM Who
UNIX AIX Planned Software AG
HP-UX Planned HP, Software AG
Solaris YES Software AG
SINIX Planned Software AG
Linux Planned Software AG
SCO UnixWare Planned Software AG
Digital Unix Planned Digital, Software AG
IRIX YES Silicon Graphics
PC Windows 95 YES Microsoft
Windows NT WS YES Microsoft
Windows NT Svr YES Microsoft
Macintosh YES Microsoft
Propty
Open MVS YES Software AG
OS/400 Planned Software AG
OpenVMS Planned Digital, Software AG

I do find this one of the more limiting—perhaps the most limiting—aspect of DCOM.

Middleware should provide an infrastructure on which to build applications spanning a whole host of platforms. In fact, its very purpose is to ensure that a company’s investment in the machines and the applications and databases that run on those machines is not wasted. By using middleware, the company can reuse all the legacy data, access legacy applications, and link together what were previously islands of data and function.

Microsoft almost seem to have provided a middleware product that can only be used for building new applications. What is the point of this?

In the following tables, I have provided a summary of the services provided by DCOM and whether they are provided on other platforms or not. The tables have been divided up into“Communication-level services,” “Management-Level services,” “Translation-Level services,” and “Other services” in line with the diagram I have been using throughout this book.

Table 19.2 Communication-level services
Service Other platforms? Windows NT
Pack/Unpack YES YES
Translate Data formats Generally yes YES
Buffer packing YES YES
Compression/Decompression NO NO
Long message handling NO NO
Session management YES YES
Network calling YES YES
Transmission coordination YES YES
Fault handling YES YES
Client retries YES YES
Client time-out YES YES
Server retries YES YES
Alternative server search NO NO
Automatic server restart NO NO
Failover NO NO
Triggering YES YES
Automated? NO NO
Context bridging NO YES (TCP/IP, UDP, IPX/SPX, NetBIOS, LU6.2)
Communication options
Request/reply YES YES
One way NO NO
Broadcast/Multicast (Outgoing Interface) Not clear at the time of writing YES
Memory Management Basic YES YES
Automatic? NO NO
Distributed Shared memory NO NO
Shared memory single host NO YES
Internet version? NO NO

Table 19.3 Management layer services
Service Other platforms? Windows NT
Thread support YES (but different from Windows
NT)
YES
Automatic creation? NO With MTS only
Automatic lock handling? NO NO
Security YES (but not same as Windows NT)
Authentication
  User/password YES YES
  Digital certificates Internet only YES
  Smart cards NO YES
Authorization NO (or alternative approach) YES
Confidentiality
  Public key YES (Internet) YES
  Secret key via third parties only via third parties
Integrity checking YES Some
Nonrepudiation YES (Internet) YES
Audit Some on some platforms YES
Load balancing NO NO
Distributed Transaction support NO YES
Transaction Buffer Pool NO YES
MSMQ (Message queuing) NO (some client gateways) YES
Polling/pulling/
notification
YES
Prioritization? YES
Broadcast/multicast YES
Guaranteed delivery Mostly yes
Deferred delivery YES
Message routing YES
  Static or Dynamic? Static
Distributed File service NO YES
Distributed Time service NO NO
Single host time service NO YES

Table 19.4 Translation services
Service Other platforms? Windows NT
OLE DB NO YES
OLEMSGing NO YES
Structure storage YES YES

Table 19.5 Other services
Service Other Platforms? Windows NT
Administration NO
Installation Part
Configuration YES
Event monitoring YES (not central)
Problem resolution Minor
Performance monitoring YES
Directory
Single file NO NO
File per machine Registry Registry
Replicated file Planned Active Directory (planned)
Publish/subscribe NO NO

So Overall?

On the whole, DCOM and all the services it supports is an attractive proposition for any user contemplating using Windows NT as their strategic platform and are happy with the component-based interface. Long term, DCOM will probably emerge to be a major player in the middleware area, but not the only player.

I do feel DCOM is a less attractive proposition for heavy users of Unix and the mainframe or other non-Windows platforms simply because there may not be the same level of support provided on these platforms—look at the DTPM products or DCE; they provide an attractive alternative.


Previous Table of Contents Next