| 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