Although these new interfaces add functionality, the likely reason that you’re exploring COM+ is for the new set of services that it provides. Chief among these services are Events and Queued Components. Although space prohibits a complete discussion of these services, I’ll give you a brief overview and some resources that will be helpful for delving deeper into the subject.
Basically, COM+ Events is a system that allows components to implement published interfaces (known as EventClasses) while other components subscribe to these interfaces. A publisher component can then simply call methods on this interface (fire events), and subscribers will be notified of the event by the COM+ infrastructure in conjunction with a new operating system service. In this way, publishers and subscribers can be loosely coupled and modified without affecting one another, and new components can be developed without the knowledge of the publisher.
Including this layer of abstraction as part of the COM+ infrastructure creates two primary benefits. First, components can be created that are not dependent upon one another, therefore simplifying the development and creating a flexible system whereby subscribers can be brought online at a later time. Secondly, the layer of abstraction provides an opportunity to extend the architecture and add features, such as filtering, at either end of the system. Publishers can then determine not only which subscribers should receive events, but also in what order they should receive them, and subscribers can respond to only those events in which they are interested based on the data passed as arguments. To get more in-depth information on events, see my article in the July issue of the Visual Basic Programmer’s Journal: (http://www.devx.com/upload/free/features/vbpj/2000/07jul00/df0007/df0007.asp).
A second new service, Queued Components, provides developers with a simple method of invoking components asynchronously. As you’re probably aware, the Microsoft Message Queue Server (MSMQ) allows you to create applications that are asynchronous by providing a queuing mechanism that you can incorporate into your application through the MSMQ object model. Unfortunately, this requires you to rewrite your code for explicit use with MSMQ. COM+ now provides a layer of abstraction on top of MSMQ so that you can administratively configure components to receive their invocations in a queued fashion through MSMQ, rather than synchronously through DCOM, as is typically the case. This allows you to create applications that are not required to be aware of component lifetimes, and that can be more scalable because the actual processing of the method calls can be deferred.
Although this system puts some small constraints on how you can design your components, and although it requires you to instantiate components using the GetObject function and a moniker, it does have its benefits. For example, you can create a much more flexible solution with the same code base. For more information on using queued components, see the technical article on MSDN at http://msdn.Microsoft.com/library/techart/complusqc.htm.