Columns

COM+ Redux
David Chappell - July 1998

Sometimes I feel sorry for Microsoft (okay, not very often, since it's hard to feel a lot of sympathy for what Fortune Magazine calls "the scariest company in the world"). But here's a case in point: everyone pressures Microsoft to release information about new technologies as soon as possible and, being enthusiastic about their work, they often do. But releasing information early means that things may change. When this happens, people criticize you for misleading them.

Today's example of this phenomenon is COM+. In my last column, I said that COM+ is the most important thing to happen in the COM world since COM's inception, and that's still true. What's changed is exactly what COM+ is, at least for now. In their first public pronouncements about the technology, Microsoft emphasized the benefits of a new COM+ runtime library. Once this library was available, we were told, writing code that used COM would get much easier—the runtime would do most of the work. Well, Microsoft still promises to ship the COM+ runtime, but it's now been pushed off into the second release of COM+. No dates have yet been announced, but it looks like for the next year or two, COM+ will consist of something quite different than we were originally told. Rather than the sea change originally described, the COM+ we'll see first is a collection of new services built on COM as we know it today.

Is this a good thing? You can decide for yourself, but to me, some of the services in the forthcoming first release of COM+ are very attractive. In fact, they're services that users been requesting for quite a while, including the ability to invoke a COM object's methods asynchronously over a message queue, support for load balancing, publish and subscribe services, and more.

DCOM Meets MSMQ

Microsoft Message Queue (MSMQ) allows an application to send a message to a queue, then have that message be read from that queue by some other application. Unlike DCOM today, which relies on synchronous RPC, it allows applications to communicate asynchronously. MSMQ-style communication is very useful when the sender need not wait for a response from the receiver, or if the sender and receiver might not be running at the same time, or in many other situations.

With the queued components service in COM+, COM-based applications can take advantage of asynchronous communications. Rather than using RPC for communication, a DCOM application can invoke methods in a remote object via MSMQ. The benefits of asynchronous communication can be used from the familiar interfaces and programming model of COM.

Well, almost. As you might expect, mapping COM's fundamentally RPC-oriented paradigm onto message queuing entails some compromise. For example, all methods in the COM interfaces being invoked using this service can have only [in] parameters, and they can't return any results. And the remote object the client is communicating with doesn't have its lifetime controlled in the usual COM way. Instead, the client creates an object on its own local system that records, then sends its method calls (i.e., its messages) across to a server object. When the client calls Release, only this local object is destroyed. For applications that can live within these limits, however, the marriage of COM and MSMQ is bound to be useful.

Load Balancing

One of the most requested additions to DCOM and MTS has been support for load balancing. If several machines are available that can provide the same services, it makes sense to use them intelligently, assigning client requests to the most lightly loaded system. COM+ allows this by grouping server machines into application clusters. To a client, an application cluster looks like a single machine, and the client directs all requests to create remote COM objects to one place. This service then silently routes each create request to the most available machine in the cluster, making the decision based on real-time information it maintains about the cluster's machines.

To allow this, a specific COM class must be configured to be load balanced. Once this is done, requests to create DCOM and remote MTS objects of that class will be spread among the machines in the cluster. Don't confuse COM+ application clusters with Wolfpack-style clustering. Wolfpack (officially called Microsoft Cluster Server) today only allows automatic failover. Even when it reaches its full potential, it will provide a complement to, not a replacement for, COM+ application clusters.

Events

It's often necessary for an object to send events to one or more other objects. In COM today, the typical way to send an event is by invoking a method in each object that should receive it. But what if the event's sender doesn't know exactly which objects are interested in this event? And what if those interested objects aren't even running right now? In this case, the problem is no longer just how to send simple events. Instead, we need a way both for the receiving objects to register their interest in specific events and for the sender to discover those objects. In other words, we need what's come to be known as a publish-and-subscribe mechanism.

While COM has long supported simple events, COM+ adds support for publish and subscribe. A COM object can create a subscription for an event, specifying the class of event it's interested in. These subscriptions can contain filters, allowing an object to receive only events of that class that meet certain criteria. For example, an object may create a subscription for stock price change events, then use a filter to specify exactly which stocks it's interested in. When the event occurs, the COM+ events service can pass the event on to this object, creating the object if necessary. Administrators can also create subscriptions, which means that the object itself need not be started just to register its interest in the event. This generic publish-and-subscribe mechanism can be used for all kinds of things, so watch for it to be widely applied in future software from Microsoft and others.

Caching Data

Memory is cheap these days, and databases are larger than ever. Given this, it makes sense to cache as much data as possible in memory rather than paying the price of disk access each time an application needs something. But building and managing your own in-memory cache is a nuisance. It would be nice to have a standard way to populate, access, and save data using a cache.

Doing these things is exactly the purpose of COM+'s in-memory database (IMDB). The IMDB is an OLE Database provider, which means that applications can also access it using Microsoft's current favorite database interface, ActiveX Data Objects (ADO). To an application using it, such as the middle tier of a three-tier app, IMDB provides a convenient place to store data that's not often changed. If this in-memory data is changed, the IMDB can write it to disk as required. The IMDB can also be used to store transient state for objects, subsuming the role of MTS's Shared Property Manager (SPM), and it supports locking and the ability to act as a resource manager for transactional applications, just like a "real" database.

MTS and COM+

MTS provides today's COM objects with support for transactions, declarative security, and more. But why should these features be bound together into a monolithic product? Why not factor them into distinct services and let COM-based applications use them as needed? This way, an application would be able to use each service independently.

This is exactly what happens in COM+. With the first COM+ release, MTS as a distinct technology goes away. Instead, the features of today's MTS will be provided as separate COM+ services using something called interception. Interception allows automatically placing one object in the access path to another. A client calling a method on some COM object, for example, might implicitly access one or more interceptor objects first, objects that provide other services. This is in fact how MTS provides support for transactions today, although it's not directly visible to clients, so COM+ really just generalizes the idea. Despite the changes, however, Microsoft is promising us that current MTS applications will run unchanged in the new world of COM+.

Conclusions

Microsoft's initial COM+ descriptions left me a little worried—too much change too fast isn't good, even if those changes ultimately make things easier. By backing off on the delivery of the more radical COM+ services and instead focusing on useful evolutionary enhancements to today's COM, I think Microsoft is doing the right thing. And the additions in this first COM+ round match what many of their customers have said is needed. Even though the more innovative features of COM+ that I described in my last column won't appear for a while, what we'll see in its first incarnation still looks promising.