InformationWeek

Another component of COM+ is the In-Memory Database. This OLE DB data source acts as a cache for frequently used database tables, particularly those used primarily for reads. This speeds up database performance by several orders of magnitude because no disk requests are required to retrieve cached data. You can store as much as 2 Gbytes of data in RAM. The application reads it like any other database-only faster. It's possible that entire static database tables could be loaded into memory and never accessed from disk by client applications. This could prove useful for electronic-commerce applications, such as catalogs, that change information infrequently.

Declarative Sentences
Developers can set COM+'s attributes at compilation time through use of declarative statements within their code. A preview of COM+ technology recently provided to Visual C++ 6.0 developers demonstrated how to use these block declarative statements to generate the metadata required by the COM+ environment, as well as the interface definition language files and interface files used by other applications, to implement methods within the code. This capability is available in Visual Basic 6.0 and is expected in the next release of Visual Studio, which should be available within 60 days of the release of Windows 2000. The capability significantly improves the productivity of developers building components for COM+ and insures that the default attribute settings for those components will be properly configured at install time.

To manage legacy COM components within Windows 2000 Component Services, a new registration database called RegDB stores the metadata that describes them. This database is optimized for the type of information that COM+ needs to activate components, and is used instead of the system registry. In addition, COM+ has a transactional, scriptable interface called Catalog that accesses information in the RegDB. As applications move closer to COM+ versions, the system registry-the bane of Windows NT administrators and support technicians-will slowly become irrelevant.

If COM+ lives up to the promise of its design, its automation of software and operating-system integration will provide a compelling reason for building enterprise applications on the Windows platform. It will also make it easier for cross-platform developers to build effective gateways between the Windows environment and the rest of the operating-system universe. For example, integration of Kerberos support-if Microsoft sticks closely to other companies' implementation of the security model-could let Unix and Windows 2000 applications interact securely and transparently. COM+-to-Corba bridging could be handled by objects developed within COM+'s component model, exposing the services of Windows 2000 to applications running elsewhere on the network.

Windows 2000 is probably only the first platform for COM+. If Microsoft follows form from previous versions of COM, COM+ will likely be ported to Unix operating systems by Microsoft and its business partners. There are also clones of the COM environment coming: The Netscape camp has a COM clone in the works as part of its Mozilla open-source Communicator Internet client project, and the Gnome project for an open-source interface for Linux and other Unix-derived operating sys- tems will eventually include COM compatibility alongside its Corba support. COM+ could eventually emerge as a cross-platform alternative to Corba.

The question, of course, is whether Microsoft can successfully pull off COM+ even on the Windows 2000 platform. The answer, so far at least, seems to be yes. Developers at the recent Visual C++ Developers' Conference in Boston were enthusiastic about what they saw demonstrated in conference presentations on COM development. But that enthusiasm was tempered by the fact that it could be well into the next year before those developers get a set of tools that can take full advantage of the advances they liked.