What is MicrosoftCorporation
COM+ is the name of the COM-based services and technologies first released in Windows 2000. Think of COM+ as a set of services available to developers of components, to enable better scalability or reliability. These services are implemented by a "container" and via "interception". COM+ is most often used in server-based applications, though COM+ is included in desktop (client
) versions of Windows as well as server versions of Windows. It was originally called COM+ to indicate that it complemented the existing COM, or ComponentObjectModel
COM+ 1.0 shipped in Windows 2000, and included this stuff:
- COM+ is integrated into the Windows kernel. What this means is, there is no extra download, no add-on to install.
- Version 3 of MTS and integrated into COM and the kernel. Of MTS, the Transaction Services, Security Services, and Synchronization Services have been significantly upgraded. Think of MTS as a container for hosting transactional components. The transaction capability is delivered by the DTC, or distributed transaction coordinator, which is also built-into Windows, but which is distinct from COM+ or MTS technology. (DTC is available via its own APIs, independently of COM+).
- Queued Components - A communication mechanism that allows COM clients to make calls on a COM object when the server's machine is not reachable on the network. The calls are recorded by a system utility , and played back into the server-side COM object when the server machine becomes available.
- Pools - useful for constructing a throttle on the number of instances that can be created at runtime. The pool pattern is most commonly understood to apply to database connections, but in fact pools can be used for any component that should be similarly restricted at runtime.
- Compensating Resource Managers - whereby you can build a transaction-aware wrapper (or manager) for a resource. This means you could include filesystem updates into a TwoPhaseCommit unit-of-work. Something like the old Encina Toolkit.
- Event Service - A publisher is any program in an enterprise application that provides information updates, such as a change in stock prices. A subscriber is likewise any program in an enterprise application that receives these notifications. The Event Service of COM+ provides an easy way for subscribers to sign up to receive these notifications from publishers, and for the publishers to locate and make calls to their subscribers.
In addition, there were supporting services, like JIT Activation (helpful when creating pools of objects), role-based security, and others. For a good overview see the article: http://support.microsoft.com/default.aspx?scid=kb;EN-US;q253669
COM+ 1.5 shipped in Windows XP and included, in addition to the above:
- App Pooling
- App Recycling
- app partitions
- Services without Components (SwC). So you can use COM+ services without developing a component.
- configurable isolation levels on transactional components.
- private components
- pause/resume of apps
- process initialization
- COM+ apps as Windows services (Daemons)
- process dumping, for better debugging
You can get a review of that stuff, here: http://msdn.microsoft.com/library/default.asp?url=/library/en-us/cossdk/html/e7073ba5-6b19-4d94-8cc0-b4e16bb44afd.asp
Windows Server 2003 also included COM+ 1.5.
Future versions of Windows (eg, Vista, and the Windows Server codenamed "Longhorn") will include updates to COM+.
There was a book, published by MSPress, that gave an overview of COM+. Unfortunately, it is no longer available.
At one time there was a COM+ Resource CD, with samples, papers, and docs, available free. The content for it was once available on the microsoft.com website, at http://www.microsoft.com/com/resources/compluscd/default.asp?RLD=59
. This too, is no longer available.
, in his book COM+ and the Battle for the MiddleTier?
, has compared ComPlus
to functions performed by a TransactionProcessingMonitor
, and suggested there are additional concerns addressed by EnterpriseJavaBeans
such as DistributedTransactionCoordinator?
, and services specific to components.
Stuff that Isn't in COM+
These items were initially in COM+ in the Windows 2000 beta's going way back to Summer 1999. They did not ship in COM+ in Windows 2000 or later versions of Windows:
- In-Memory Database - IMDB is a service that provides automatic memory caching of back-end tables on middle-tier machines. It can enormously speed up access to database tables that are primarily read from rather then written to, such as those for mail order catalogs.
- Load Balancing - COM+'s load-balancing service provides an automatic mechanism for distributing object creation requests among a number of services in a pool, thereby spreading the load.
Microsoft dropped the In-Memory Database (IMDB) from COM+ before the initial release of Windows 2000, saying it "didn't serve customer needs". See article by DavidChappell
-- Stu Charlton
IMDB was dropped because it
- added a new API (==complexity)
- introduced new choices to navigate, new pitfalls (eg, how to keep the cache consistent with the db, in concurrent access scenarios)
- for read ops, couldn't surpass the performance of a db client cache
- Some people have observed that the functionality offered by the IMDB is now being delivered through the AdoDotNet. In the sense that the DataSet is an in-memory, queryable cache, it it fulfills part of the goals of IMDB.
CLB was "removed" because Microsoft believed it needed additional administrative UI, additional complementary programming interfaces and documentation in order to be used properly. That was provided by a separate product, AppCenter?
. But in actual fact, CLB capability wasn't removed from Windows. It is still built-in to Windows (2000, XP, 2003, etc). You can still use it. See here: http://discuss.microsoft.com/SCRIPTS/WA-MSD.EXE?A2=ind0007E&L=DCOM&P=R1502&I=-3
. But there is no admin UI to help you.
COM+ and DotNet
COM+ infrastructure also provides services to .NET developers and applications; these services are available through the System.EnterpriseServices
is a new name, denoting a new way to access existing services.
The .NET Framework v2.0 (released November 2005) introduces a new transaction API, System.Transactions. System.Transactions does not replace COM+, nor does it replace System.EnterpriseServices
. Instead it provides an alternative API to System.EnterpriseServices
, specifically in cases where transactions are the main service to be used. And, while System.Transactions is a new API, for distributed transactions, it uses the same underlying distributed transaction coordinator built-in to Windows.
COM+ Services without Components
Services without Components was introduced in COM+1.5 (Windows XP and 2003) and allows applications to take advantage of COM+ services without actually being packaged as hosted, configured components. In the traditional model, a component would derive from System.EnterpriseServices
, and then could participate in transactions, activation, etc. In the Sw
C model, an app can simply create a transactional context, programmatically, and use it. Something like the Tran-C capability in Transarc's Encina, circa 1990, or like the OTS in CORBA.
What really impresses and excites me about ComPlus
is the idea of having a MultiCaster
embedded in COM. PublishAndSubscribe
is an extremely powerful paradigm, as fundamental as function-calling.
Indeed the COM+ Event service is very useful and fairly simple. The basis for Pub-Sub is the interface. Publishers invoke a method on an interface to publish a method. Subscribers implement the interface to receive such events. Again, the programming model remains client/object and interface-based. In between the publisher and subscriber, there is a proxy which handles things like subscription lists, and whether to deliver the events in parallel or serially.
Events can also be unbound - meaning 1 or more publishers, and 0 subscribers.
The Events service within COM+ replaces and greatly simplifies the COM Connection Points
technology that has been described in the literature. Again, no new APIs.
What is the Java equivalent of COM+ Events? Is JMS (Java Messaging Service) the 'approved' Java API for PublishAndSubscribe?
Yes. JMS is the "approved" way of doing publish-subscribe. HOWEVER, there is still an open issue as to whether or not there should be an "easier" way (aka Jini Events or the CORBA Event Service) to do the same thing. -- KyleBrown
COM+ Queued Components
This is a novel piece of the COM+ technology. The trend in many different areas is to add capability, add function, without adding new programming interfaces, new things to learn (or not learn).
With QC, the goal is to enable asynchronous invocation of components, without adding a messaging API to the application. This is in contrast to the use of a bare MessageQueueing?
middleware in an application; in the MQ case, you'd be using Put/Get verbs to exchange messages.
The way this works - when deploying a component, you mark it for "queued invocation". When the client invokes the remote interface, using the same client/object programming model as always, this request is intercepted by a "Recorder" and "freeze-dried" onto a queue. On the other side of the queue, there is a "player", which does the reverse process and invokes the component.
There are limitations. For example, with a queued (asynchronous) invocation, you cannot have in/out params. To get a response, you have to build a conversation into your app (perhaps a reflexive QC call).
But this is a nice capability, without adding any new APIs.
I always find this kind of thing funny. The hard part is not the explicit MessageQueueing? stuff, it's what you build on it. Having such a transparent queuing feature leaves in an even worse case, not easily recognizing where you will get bitten by queueing weirdness (building the conversation into your app, as you said).
Instead of being up front, clear and obvious, it slides by stealthily to come and annoy you at the worse of moments.
One of the great thing with the COM QueryInterface way of things for example is exactly this, that it is explicit: you ask for an interface, and it's either there or not. If it's not, there is nothing you can do. But if it is, everything works as designed (err, well, anyway!). Some other languages or component systems do this in a transparent way, and then you get bitten off later on. For example, systems that flatten interfaces together so that any object with the appropriate methods signatures will work, even if they do not advertise the interface explicitly (interface semantics goes down the drain).
Composition of Component Services
One final neat twist to all of this is that all of the COM+ Services compose nicely. For example, you can compose QC with COM+ Events, to allow asynchronous event subscriptions.
You can compose Transactions with COM+ Events, etc.
History of COM+
Microsoft started using the term "COM+" sometime in 1997. At that time, the vision was to integrate a component runtime with with all languages so you could create ComponentObjectModel
objects directly from C++, Java, Perl, etc without InterfaceDefinitionLanguage
The "COM+" that was actually delivered, first in Windows 2000 and then in succeeding versions of the Windows OS, is not that; it's much more limited.
The .NET stuff Microsoft announced in July 2000 is the realization of the common language runtime. See MicrosoftDotNet
See EjbVsComPlus for a different perspective
(discussions involving PeterMerel
et al, were moved to EjbVsComPlus
around 22nd March 2004)
2006 January edits and refactoring by DinoChiesa