April 19, 1999
Print this story |
| Related links: |
|
|
| And from our sister publication: |
|
|
here's only one real reason to consider buying into Microsoft's upcoming Windows 2000 operating
system as a strategic enterprise platform: the COM+ component architecture. COM+ is a key to
Microsoft's Digital interNet Architecture (DNA) strategy, and the first of three DNA components
(see story, p. 72). Sure, Microsoft may be pushing its Active Directory Service. But Novell Directory Services could just as easily fit the bill for most enterprise customers-and it's already shipping (see InformationWeek Labs, p. 77). But Microsoft and many of its customers hope COM+ is the technology that will make Windows NT applications truly scalable, both in capacity and across the corporate network and Internet, and bring software built for previous versions of Microsoft's component technology along with it.
That's a tall order for a single revision of the Windows operating system. Microsoft seems to have laid out the blueprint-but you can't run an application on a blueprint. How well Microsoft implements the COM+ architecture will become more apparent when the third beta version of Windows 2000 becomes available later this month.
COM+ is the latest iteration of Microsoft's Component Object Model, originally known as Object Linking and Embedding. COM was first implemented in Windows 95. In Windows NT 4.0, Microsoft introduced the Distributed Component Object Model, which took COM beyond the boundaries of a single computer and into the realm of distributed computing. DCOM and the development tools that take advantage of it-such as Microsoft's Visual Studio-gave Windows developers the ability to build multitier client-server applications that spanned the corporate network and the Internet.
Microsoft refined the DCOM environment with database connectivity through its OLE DB database interface, and the abstraction of remote database connections through ActiveX Data Objects. These enhancements were delivered as part of the Visual Studio 6.0 development suite and the Windows NT Option Pack. Also included in Visual Studio 6.0 and the Option Pack was the first step toward Windows scalability-the Microsoft Transaction Server and Microsoft Message Queue. MTS and MSMQ brought transaction handling and asynchronous communications to Windows NT 4.0 Server.
With Windows 2000, all the technologies grafted onto the Windows NT 4.0 environment over the last two years will become integral parts of a single architecture by being blended into the operating system. COM+ is the sum of DCOM, OLE DB, MTS, and MSMQ, transformed into integrated Windows services.
The Plus In COM+
Microsoft has enhanced the transaction-handling and message-queuing services of MTS and
MSMQ, adding load balancing and publish-and-subscribe capabilities to the architecture. As a
result, COM+ isn't just a component development model, it's an object request broker and
message-oriented middleware as well, offering services that rival even the most complete
Corba implementation-at least on paper.
Helping to push COM+ even further ahead of other distributed application environments is its built-in management instrumentation. COM+ provides two points of control for system administrators: the COM+ Explorer, a Microsoft Management Console "snap-in" interface; and a full set of scriptable administration objects that can automate component service tasks.
COM+ takes a lot of the work out of the development and deployment of applications. With COM+, many of the services that developers configure manually are part of the operating system. COM+ Explorer lets administrators and developers control most of the properties of objects running on a Windows 2000 server or workstation through a graphical interface, turning features on and off with a click. This makes it easy to configure advanced feature support even for older COM apps.
This level of control over the configuration of COM software within the Microsoft Management
Console is both a blessing and a potential security nightmare. Through the COM+ Explorer
interface, users with either a local-machine or domain-administrator password could easily
disable or damage running applications by inadvertently changing declared attributes. For
example, untrained administrators might accidentally cause a transaction to fail while adding
users to a component's access control list. Also, if software components are deployed to users
with administrative access to their workstations, those users could disturb software
installations. Windows 2000's group and security policies should be used extensively to prevent
these problems.
continued...page 2, 3