As Visual Basic developers, you and I love the fact that VB lets us create full applications in a relatively short amount of time. There is no doubt that, compared to other languages on the market, Visual Basic stands out as perhaps the leading rapid application development (RAD) language. One of the things that make Visual Basic so easy to use is that VB hides a lot of the details of the technology from us. In Visual Basic, for example, you could live a happy and fruitful life without knowing what a message loop is or learning anything about the types of messages that the OS sends to each window. (If you do not know how things are done at this level, then you are proof that the Visual Basic team has done its job correctly.)
COM+ is also an architecture that the Visual Basic team has decided to hide from you. The problem is that almost every aspect of what you can or cannot do with Visual Basic classes is governed by the rules of COM. You may ponder the fact that every “public” class you have in an ActiveX DLL or ActiveX EXE is a COM component, and you may decide that item of information is just an interesting piece of trivia. According to this view, in the real world it matters not whether you are writing COM components or Widgets—the only thing that matters is that they work correctly and that they deliver what they have promised. This is an interesting thought, because the real question then becomes: what do we gain from COM+? It seems fitting then to take some time to define the term and analyze some of the claims it has made.
COM+ is an interesting term. What makes COM+ a particularly interesting term is that it is used very frequently, yet very few people know what the term actually means. Most people think COM+ is the next version of COM. (The term COM refers to the Component Object Model—a specification Microsoft introduced in 1992.) Actually, COM has changed very little from its Windows NT 4.0 cycle to the introduction of COM+ in Windows 2000. It is fair to say that COM+ is actually more the next version of a Microsoft product named Microsoft Transaction Server (MTS), and it is even more exact to say that COM+ is actually the integration of the MTS service model with the COM APIs. To understand what all this means, let’s talk about COM first, then MTS, then see why these two models were merged in COM+.
As I mentioned earlier, COM stands for the Component Object Model. COM is one of those terms that sound old; in fact, the first specification came out around 1992. However, COM is still heavily used today; without COM there would be no COM+. In fact, without COM, VB classes and components would behave very differently.
COM is a specification, and it is also to some extent the implementation of the specification. The goals of COM are the following:
- A standard for versioning
Versioning is a big word, but it means that existing client programs should work with newer versions of the component. Actually, the versioning scheme dictates that new versions of the client should work with old versions of the component as well. They may decide to display a message telling the user to upgrade the component, but the program should not crash.
- Environment for components with different threading requirements
COM is a technology for interoperability between components that have high thread affinity and those that have low thread affinity or no thread affinity. High thread affinity means that certain components can get calls from only one thread. Visual Basic components have high thread affinity. Low thread affinity means that the component may have a group of threads making calls into its methods. No thread affinity means that the component may receive calls from any thread. COM was designed to enable communication between all these types of components.
- Location transparency
Location transparency is the idea that you should be able to write a client program in such a way that the code works when the component is on the same thread, a different thread in the same process, a different process on the same machine, or even a different process on a different machine. There should be no difference in the way you write code to use that component. There may be a difference in how you design the methods for the component. For example, if you know a component is going to be used remotely, you may design the methods to minimize the round-trips around the network, but the bottom line is that a client will use the same method calls when the component is local as when the component is deployed remotely.
One of the main aspects of the COM specification is the definition of what a COM interface is and what those interfaces look like in memory. COM is therefore a specification for compiler makers for how COM objects should behave and how their interfaces should look in memory. The specification also discusses how COM components are packaged into COM servers. In the VB world, we know those packages as ActiveX DLLs or ActiveX EXEs.
COM is more than a specification. Microsoft also ships COM libraries that have APIs for creating instances of COM objects. COM also includes a loader that uses the registry to find the ActiveX DLL or ActiveX EXE hosting the components.
The architecture of COM and its promises have not changed very much in the transition to COM+—COM+ components are really COM with a different name. What has changed to some degree is the way that the APIs work and the loader (the things Microsoft ships with the OS). The main difference in the APIs is that they have knowledge of the MTS model. To understand that statement better, let’s talk about MTS.
MTS was originally a separate product that worked with Windows NT 4.0 and was part of the NT Option Pack 4.0. It was meant to serve as an object broker -- a server product that manages instances of objects. It was also meant to be a piece of software that would interact with and drive the Distributed Transaction Coordinator (DTC). The DTC is a service that manages transactions that involve more than one database (or other resource managers) at the same time. Transactions that involve more than one resource manager are hard to manage; they involve the use of a protocol known as the two-phase commit protocol. Also, MTS introduced a way to better manage the security of the components at a method level. MTS uses a model called role-based security, in which you can define groups of users and grant them access to different parts of the component.
What makes MTS an interesting product is that in order to offer services such as an ability to drive the DTC, to support role-based security, and even to some extent to control the lifetime of objects, MTS uses a model known as interception. Interception means that, when the client creates an instance of your component, MTS intercepts the request and hands you an object that looks just like the object you requested. Internally, MTS then creates an instance of the true object the client requested. The idea is that every time you make a method call, the call actually goes through the impostor MTS-provided object first before reaching the true object. By intercepting each call, MTS can provide services that do their job before and after each method call.
The problem facing the MTS team was that they did not want to add
their code directly to the COM APIs in the first release. For
example, it is a lot easier to intercept a call to create a component
if the API calls in COM are MTS-aware to begin with. However, if you
do not want to change the way the APIs work, then you have to resort
to other techniques of interception that could be considered
"hacks.” When you specify that
you would like your component to be an MTS component (and this is
done by adding your component to an MTS package through an
administration program), MTS changes some registry keys. The changes it makes to the
registry tell the COM APIs that the ActiveX EXE containing your
component is actually MTX.EXE,
an MTS
server,
instead of your server. This little trick makes it possible for MTS
to inject its code before creating an instance of your COM component.
As a result, in Windows NT 4.0, COM and MTS work together but are not
integrated.
The problem with this lack of integration is that at times you have to code your COM component in such a way that you will not break the relationship between the impostor component and your component. It is very easy to do things that can make the client retrieve a reference to your component instead of to the MTS impostor component, and the result is that the services stop working correctly. The full integration of the COM architecture with the MTS mode is known as COM+, and it is available only in Windows 2000.
COM+ is the next version of MTS. It is the next version in the sense that it relies on the MTS model of interception and also adds a few new services. If you know how to write code that interacts with the MTS services, then you know how to interact with the COM+ services—the functions are practically identical, and all the old functions work in COM+. One big improvement is that when you specify that a COM component is part of a COM+ application (MTS packages have been renamed to COM+ applications), the system does not rely on registry hacks to provide you with services. The COM APIs have been rewritten to detect that the COM component has been marked as a COM+ component and to provide the client with the impostor object instead of a direct reference to the true object.
Therefore, be aware that the COM architecture itself has not changed much. A few concepts have been added in COM, such as a new boundary called context that you will learn about in this book. The main thing to realize is that the literature on COM+ sometimes refers to the architecture of the components (which in reality is just COM, just as it was before), and sometimes it refers to the new services (or really the new version of MTS).
Get COM+ Programming with Visual Basic 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.
