Com Plus
Com PlusWhat is MicrosoftCorporation's "COM+"?
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+ 1.5 shipped in Windows XP and included, in addition to the above:
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+.
Feb2004 note: 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.
RogerSessions, 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 and ComPlus 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:
IMDB was dropped because it
COM+ and DotNet
COM+ infrastructure also provides services to .NET developers and applications; these services are available through the System.EnterpriseServices namespace. 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.ServicedComponent?, and then could participate in transactions, activation, etc. In the SwC 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.
COM+ Events
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). -- PierrePhaneuf
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 (IDL).
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, StephanSchmidt, HankRoark et al, were moved to EjbVsComPlus around 22nd March 2004)
2006 January edits and refactoring by DinoChiesa
EditText of this page
(last edited November 2, 2007)
or FindPage with title or text search