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

Previous | Table of Contents | Next

Legacy system integration difficult-It is clear that Microsoft is having as much difficulty as the other ORB vendors in integrating “legacy” technology (for legacy read not object/component based)—RDBMSs, existing procedural language-based applications, network DBMSs, other operating systems (such as MVS), simple flat files (like VSAM or ISAM), application packages, and so on.

Integration in DCOM has been achieved via a quite complex set of drivers, translators, proxy objects, and gateways. The more “legacy” technology needs to be accessed, the more complex is the overall environment.

In general, it should be clear that the more intermediate software layers are used, the more processing power is needed and the greater becomes the risk of slowing processing, increasing the likelihood of error and increasing the difficulty of finding where errors came from.

Oddly, it is the use of component based technology that is the problem here. The rest of most companies’ systems and databases are procedurally based. In fact all development up to now has been procedurally based. Object/component technology turns this approach on its head, but by doing this the object technology inventors create a world that is difficult to marry successfully with all that has gone before.

Component-based technology may be (may being the operative word) a good idea in theory, but it doesn’t look so attractive if you then cannot access or use everything you have already developed.

New and possibly unstable-Microsoft’s middleware products have taken some time to come to final fruition and are only now beginning to take shape. The potential purchaser needs to be aware that the pieces in this vast puzzle are still not all in place—MSMQ had only just been released at the time of writing this, the Active Directory will not be available until 1998 (or later) and is likely to affect the design of MSMQ, the Zero Administration Initiative with Management Console is also not due until 1998, and so on.

Some of the pieces are also very new and as such will need some time to settle down (like most release 1 software)—particularly Transaction Server. Thus even though the picture does look impressive, it is still some way from being fully complete and it is all in a state of flux.

Don’t let this totally put you off, however; this particular weakness will obviously disappear in time. But it should affect when you decide to use DCOM—perhaps waiting until things have settled down a bit.

Not yet enterprise level—DCOM cannot be described as “enterprise-level” middleware. What do I mean by enterprise level? Enterprise middleware can be used by a company across the entire company on all its machines to support applications of many types (transaction processing, query processing, heavy duty, light duty, high volume, or low volume). It is also geared towards high availability, high reliability, and excellent performance. So what does make an enterprise-level product? The services I believe make a middleware product into an enterprise-level product are:

  • fully automated end-to-end security (all platforms including non-Microsoft)
  • fully automated multitasking (or multithreading)
  • fully automatic load balancing
  • advanced fault handling services such as failover, automatic restart, and recovery
  • totally automated triggering or no triggering in the case of transaction processing
  • automated memory management (or none being required)
  • multiplatform remote administration services and setup
  • a replicated publish/subscribe directory service
  • full context bridging (all platforms)
  • a distributed shared memory service
  • a distributed time service
  • fully distributed transaction processing support (on multiple platforms)
  • full message queuing support (on multiple platforms)

Microsoft still has some way to go to catch up with the really heavy-duty DTPMs or DCE, which are the only products on the market currently that can be deemed enterprise level.

Other platform support is weak-I explained in the chapter on other platforms that DCOM was being ported to other platforms by Digital, HP, Silicon Graphics, Software AG, and with some input from Level 8 for MSMQ.

A reminder of the other platforms being supported is shown in Table 19.1.

But Microsoft’s entire middleware strategy and services are, not surprisingly, entirely dependent on the user having Windows NT as their strategic platform, and this should not be forgotten.

This is fine if the user wants to go this route, but if the developer has a mix of platforms at the moment—Unix, mainframe, and Windows, with no one platform being strategic—it will limit the architecture of the systems being built and may make design more difficult. The developer loses a great deal of flexibility by having to use the Windows NT platform as the main location of services and focus of development. The emphasis upon Windows NT as the prime platform is inevitable given the tight integration between Windows NT and the middleware services.

Previous | Table of Contents | Next