In the Whistler release of Windows 2000, due in Q2 2001, Microsoft will include a revision of its COM+ component infrastructure. COM+ 1.0 debuted with Windows 2000 in February 2000, merging the Microsoft Transaction Server (MTS) component host environment with COM, while adding a host of significant new features for developers, such as object pooling, loosely couple events, and queued components (See myCOM+ showcase for more information).
But with Whistler, Microsoft is taking COM+ to the next level, focusing on three key areas: Scalability, availability and manageability.
Scalability enhancements
First up is process recycling, which attacks the problem of application performance degrading over time because of memory leaks and the like. Process recycling proactively destroys and recreates COM+ applications to prevent this problem, while helping to eliminate nagging bugs and other problems. It's configured with the COM+ Component Services GUI and doesn't require any programming at all. Administrators can configure process recycling to occur on any number of events, such as a number of calls limit, an activation limit, elapsed time, amount of RAM used, expiration, or similar. Process recycling fires COM+ Events, which are notifications that can be programmatically responded to.
Another scalability enhancement is configurable isolation level, which allows developers or administrators to control the extent to which changes made outside of a transaction are visible to that transaction. The visibility of external changes (that is, the isolation level) is controlled using locks. Locks control whether transactions can see uncommitted data (dirty reads), whether other transactions can modify existing data before the current transaction ends (unprepared reads), or whether other transactions can add new data before the current transaction ends (phantom reads). A high isolation environment incurs more locking, less concurrency, and a lower potential for incorrect data, while a low isolation environment incurs less locking, more concurrency, higher potential for incorrect data. Like process recycling, this feature is configured at deployment time using the Component Services GUI. <% ' Added so can inventory as Connected Home articles. kw = "CH" %>
Incidentally, COM+ 1.0 (Windows 2000) and MTS (Windows NT 4.0) use the highest possible level of isolation to ensure correct data, which may be overkill for some applications. Microsoft felt that it was better to be safe than sorry while developers got used to programming under a transactional model. However, now that developers are used to this style of programming, they are allowing them to choose the desired isolation level in their component-based applications.
Availability enhancements
Microsoft is adding a number of availability enhancements to COM+ 2.0 as well. In COM+ 2.0, COM+ applications can be configured to run as NT services, which is almost impossible under COM+ 1.0. COM+ 2.0 applications can be started at system boot or in order, can be run as LocalSystem,, and can be more easily made to be cluster aware. This feature is configured at deployment in the Component Services GUI, not programmatically.
Another new availability feature, Memory Gates, handles a big problem with COM+ 1.0 applications: Low memory scenarios. In COM+ 1.0, creating components in low-memory situations can cause some serious issues. For example, a component might need to create another component, but no memory is left for that action to complete. Low memory scenarios are not well debugged by most developers, and Microsoft hasn't created an infrastructure to handle these scenarios. In COM+ 2.0, servers will not be loaded and components will not be created in low memory situations, based on a check of available resources and the application's requirements. Memory gates, as these situations are called, are checked in SCM.
Manageability enhancements
Finally, Microsoft is adding a number of manageability enhancements to COM+ 2.0. In COM+ 1.0, there is no way to control component activations. But COM+ 2.0 applications can be paused, resumed, disabled, and enabled. Administrators can manage this feature from Component Services, while developers can programmatically control component activation, making COM+ apps more manageable. The pause feature prevents future activations, while current activations are not affected; this only works for COM+ server apps. Resume allows future activations. Disable prevents future activations, though existing activations are not affected, and state remains during a reboot. Enable allows future activations.
COM+ 2.0 process dumps overcome the difficulty of troubleshooting COM+ applications in a production environment by taking a snapshot and getting debug information without having to shut down the application. Process dumps are generated with a new tool called userdump.exe (which will be ported to NT 4 as well). This leaves the target environment virtually untouched. Note that installing COM+ 2.0 does not install userdump.exe; this tool will be installed manually be developers. And developers will need to manage their dump files as well, as Microsoft has no plans to build dump file management into COM+ 2.0.
One of the most often requested features is finally making it into the product in COM+ 2.0. Alias components are a form of implementation sharing, which occurs at the binary level, rather than at the code level, which is the only form of sharing in COM+ 1.0. Binary implementation sharing will require less code and offer developers a way to get their solutions to market more quickly. Multiple CLSIDs (class IDs, unique identifiers for components) can be created that all point to the same implementation DLL. This creates reuse at a binary component level, and any number of CLSIDs can point to the same server.
Another much-requested feature, Public and Private components, will be available in COM+ 2.0 as well. In COM+ 1.0, all COM+ components are public, so that any application that knows the name of the component can gain access to any of its properties or methods. In COM+ 2.0, both public and private components (which are similar to Public and Private methods in Visual Basic) are allowed. Public components can be activated from other applications, while Private components can only be seen and activated from other components within the same application. Private components are private to the application.
A final new COM+ 2.0 feature, application partitions, allows multiple configurations of a single application or component to exist on a single machine. In COM+ 1.0, only a single application or component configuration is allowed on a single machine. Allowing multiple versions of the same app/component is good for hosted environments that manage a few large severs rather than multiple small servers. An application partition creates a conceptual logical machine. COM+ apps are installed into one or more partitions, where the "base partition" represents the entire machine. Partitions are grouped into partition sets and users and Active Directory organizational units are assigned to a single partition set for security authentication. Users can only access components from partitions in their partition set, but anyone can access the base partition.
Conclusion
COM+ 2.0 (which is referred to as COM+ 1.x in internal Microsoft documents) is an integral part of Windows Whistler that will likely change over time. This overview is based on Whistler Server build 2236 (Build 2236.main.000516-1846), a pre-beta 1 release of the operating system that represents the state of COM+ 2.0 at the time of this writing. But like the first release of COM+, which eventually dropped features such as Component Load Balancing (CLB) and In-Memory Database (IMDB), COM+ 2.0 may change before the final release of Whistler. Stay tuned to the SuperSite for the latest information.