Foreword

I first ran into COM+ back in 1996. In those days, I was working as a Common Object Request Broker Architecture (CORBA) consultant and was fresh out of IBM, where I had been heavily involved in IBM’s original CORBA implementation.

CORBA was the first of the architectures that we might describe today as Distributed Component architectures, which set the stage for both COM/DCOM in the Microsoft space and RMI/IIOP in the Java space.

Back then, I was interested in a particularly knotty problem related to distributed component architectures. Systems built with such architectures had a characteristic performance pattern. They could handle large numbers of transactions, as long as those transactions originated from a small number of clients. So, for example, 5,000 transactions per minute divided between 5 clients worked fine. But when those same 5,000 transactions per minute were split among 1,000 clients, each processing 5 transactions per minute, the systems choked.

This was odd, I thought. Why should 5 clients, each processing 1,000 transactions per minute, be fundamentally different than 1,000 clients, each processing 5 transactions per minute? What is the difference between the first 5,000 transactions per minute and the second?

Distributed component architectures, as they existed in 1996, dictated a one-to-one relationship between clients and component instances. The business logic of such architectures is in the component instances. And it is the business logic that makes transactional requests of transactional resources, such as the database. In order to make transactional requests, the component instances require expensive resources, such as database connections. We run out of steam (i.e., transactional throughput) when one of two things happen: we overload the system with transactional requests or we run out of resources (e.g., database connections).

Clearly, going from 5 clients, each making 1,000 transactional requests per minute, to 1,000 clients, each making 5 transactional requests per minute, has no overall impact on the transactional throughput. Therefore, the reason why our distributed component systems must be dying is that we are running out of resources.

So the answer to getting lots of clients on a distributed component architecture is not going to come from increased capability of the back-end transactional resources (e.g., databases). It will have to come from something else-something that allows resource sharing. This, then, is the problem I worked on back in 1996. How do you get several clients to share resources in a distributed component architecture?

The solution to this problem came from an unexpected source. I was asked to write a book on COM and DCOM. I knew very little about COM and DCOM back then. As I looked over the COM/DCOM white papers on the Microsoft web site, I quickly recognized it as a typical distributed component architecture and predicted the same throughput problems I had seen in other distributed component systems.

As I browsed through the white papers, I noticed an obscure beta product called Microsoft Transaction Server (MTS). At first, I dismissed MTS as an API used to manage distributed transactions. But as I read more about MTS, I realized that it had little to do with transactions. Instead, it attacked a much more interesting problem: how to share resources among clients. In a nutshell, MTS addressed the very problem that had so vexed the existing distributed component systems-how to support a large number of low-transaction generating clients!

I did eventually write that book, as well as many articles on the importance of the ideas introduced by MTS. Many of these articles appeared in my ObjectWatch newsletter (available at http://www.objectwatch.com), a newsletter that has, over time, become influential in its space.

Back in 1996, I predicted that MTS would be a historically important product-one that would redefine approaches to scalability in distributed component systems. In fact, that prediction has come true. Today, every infrastructure designed to support high scalability in distributed component systems is based directly on the ideas, algorithms, and principals first introduced by MTS in 1996. Enterprise JavaBeans, for example, the Java scalability infrastructure, is almost a direct copy of MTS.

But what does this have to do with COM+, you may ask. It turns out that COM+ and MTS are one and the same. Microsoft, never known for its marketing savvy, decided to wait until customers finally got used to the name MTS (itself a misleading name), and then it pulled a fast one-it switched the name! And not just any name, but one that would be as confusing as possible! So they renamed MTS as COM+. Naturally, customers assumed that COM+ was the next release of COM. In fact, COM+ was the next release of MTS.

Now Microsoft has announced .NET. Once again, the brilliant Microsoft marketing organization has left many customers confused. Is COM+ now dead? Far from it—.NET is a series of interesting new features, none of which replace COM+. COM+ is still the scalable infrastructure that supports resource sharing and deals with the myriad of issues (such as security and transaction boundary management) that are so closely related to resource sharing and so crucial to distributed applications.

So whether you are rushing into Microsoft’s new .NET technology platform or taking a wait and see attitude, if you need to put a lot of clients around your system, you need to understand COM+. Therefore, this book is very timely. COM+ is going to be with us for a long time. Its name may change again, just to confuse the innocent; but the ideas, algorithms, and principals will not. COM+, under whatever name, is here to stay!

Roger Sessions,

CEO, ObjectWatch, Inc.

Publisher, ObjectWatch newsletter (http://www.objectwatch.com)

Author, COM+ and the Battle for the Middle Tier

Austin, Texas

Get COM & .NET Component Services now with the O’Reilly learning platform.

O’Reilly members experience books, live events, courses curated by job role, and more from O’Reilly and nearly 200 top publishers.