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 doesnt look so attractive if you then cannot access or use everything you have already developed.
New and possibly unstable-Microsofts 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 placeMSMQ 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.
Dont let this totally put you off, however; this particular weakness will obviously disappear in time. But it should affect when you decide to use DCOMperhaps waiting until things have settled down a bit.
Not yet enterprise levelDCOM 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:
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 Microsofts 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 momentUnix, mainframe, and Windows, with no one platform being strategicit 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 |