The .NET Platform
Development Tools
COM & COM+
Data Access
Web Development
XML Technologies
Windows Servers
Wireless & Mobile
Security issues
Design & Process
Career Development
Analysis & Comment
Disposable Objects
We found this book useful!
You are not logged in: login here to access all areas.
Don Box on COM and COM+
Matt Nicholson talks to Don Box, founder of Developmentor, about what's important and what's not when it comes to COM, Microsoft Transaction Server and COM+.
Author: Matt Nicholson
Last updated: Jul 1999
Matt: First of all tell us about Developmentor. Who are you and what's your relationship with Microsoft? Don: Developmentor is what I started when I finished Grad School, and it's evolved over the last five or six years into a component software think-tank where we sit around and work on component technologies -largely COM. We also teach to pay the bills. Matt: What was it about COM that attracted you? Don: To be frank, COM didn't attract me. I was going through a phase in my life when I was shedding my UNIX robes and trying to learn as much about Windows programming as I could, because I didn't own a PC before 1993. Matt: And what was the point? Don: The point was very simple. There is this method in COM called Query Interface. It's fundamental to the model, but I'd never seen an explanation that worked for me. I understood the mechanics quite well but conceptually it just wasn't resonating. Matt: Do you think that message has got out now? Don: COM is like other massive shifts in programming. Everyone has their own 'dynamic_cast' that makes it make sense for them. I think I've figured out how to make it make sense to C developers as C is part of my heritage, but I'm not very good at explaining it to Visual Basic programmers. Matt: But the idea seems to make a lot of sense! Don: Yes, we want to be able to replace components in the field. The problem is that the way we used to do it with DLLs is really, really bad. The way we're doing it now with COM is better, but it's not yet right. There's still lots to be done with COM before DLL Hell becomes a thing of the past. Matt: Let's move on to COM+. I've got a problem here! When I first heard about COM+ I got the idea that it was essentially COM in combination with Microsoft Transaction Server and Message Queue Server. These technologies are around already, so is COM+ simply a marketing exercise? Don: No, it's not! OK, on the one hand, COM+ is MTS 3.0. The most significant aspect of COM+ is the unification of the COM and MTS programming models. Today, because MTS and COM were developed fairly independently, there are a lot of areas where there is an MTS way to do things and a COM way to do things. That will happen less and less, but it won't change overnight. Matt: Transaction Server is really the wrong name for the product. Don: Right, because people say, "transactions means databases; and I don't do databases." In fact you can see where COM is going by looking at MTS. Matt: What about the idea that you can write a single user application and have it magically scale in
MTS? Don: That's marketing nonsense. In the simple case it can, but the harsh reality is that MTS development is harder than pure COM development. MTS requires a higher understanding of the programming abstractions involved. Matt: Isn't this a problem? If you're writing something you want to scale, you've got two choices. You can write the code yourself, in which case you're going to know how it works because you wrote it. Or you could spend possibly the same amount of time trying to work out what MTS is actually going to do, and how you can use it to the best. Don: Totally agree! I am not advocating people go out and re-implement MTS, but I am recommending that people don't check their sensibilities at the door and think, "Wow, Windows DNA and MTS are going to make me an enterprise developer!" Matt: Can you give me an example of how that would work? Don: OK! You have objects that need to be red and you have other objects that need to be blue. It's important that the world looks red when you call into one of the objects that needs to be red. But, when the red object calls over to a method in the blue object, it's important that the world looks blue while the method runs. Then when the method returns control to the red object, the world has to turn back to red. We don't want purple!
Don Box has the reputation for being something of a guru in the
developer world. Certainly his talks are not to be missed if you can help
it. We caught up with Don at Microsoft Visual C++ European Developer
Conference held in Amsterdam earlier this year.
All the revenue at Developmentor come from training; everything else we do is gravy. Most guys at Developmentor teach one week the month and live nomadic, monk-like lives the rest of the time, trying to stay ahead of the technology curve.
COM was very similar to the work I'd done in Grad School, and I fell in love with it eventually, but not right away. I was one of the first guys outside Microsoft to figure out COM, and around that time I ran into Sarah Williams who was in developer relations at Microsoft. After trying to hire her, and being turned down, I said, "Why isn't there a column on COM in Microsoft System Journal?" She said, "I don't know - do you want to write one?"
That was the start of my relationship with Microsoft. I had never met a Microsoftie up until that point - I had figured out COM just from Craig Brockschmidt's book. I met Sarah, and that was it. I fit into the family and we have a fairly cosy relationship. Sometimes we disagree but that's OK - every family has disagreements, but I think the relationship's pretty healthy.
I fell into this thing called OLE, and it was this weird complex unapproachable thing that made no sense. I went through the standard six month fog that everyone goes through. I was able to get stuff to kind of work after a month or two, but never had an organic understanding of what I was doing right.
And then I had my epiphany. I had that moment in time when COM went from being this thing that made no sense and just seemed a real waste of time to, "My God - how could software be done any other way?" I remember the date - it's up there with my wedding date - 8 August 1994. I felt, "Yes, I can do this and it's what I want to do!" I got the point, and I haven't been able to stop doing it since.
It was the first time I'd taught a class on OLE, and it was the Monday of that class. I was explaining IUnknown and Query Interface, and I was searching for an analogy. In my search I came up with the cast system in C++. I simply said, "Query Interface is a lot like dynamic_cast in C++." And then I almost started crying: "Oh my God, that's all it is! I've been wasting six months of my life not realising how simple it is and how similar it is to these things that I already know!" It was just magic.
There are three unifying concepts that shape the programming model. COM is about interfaces, dynamic class loading and context. If you understand those three it's fine.
I look at the model and I think I do as reasonable a job explaining it as everyone else, but as an industry we still haven't figured out how to make sense of this whole component-based software model. Ask three developers on the street, "What is a component?" You will get six different answers because the technologies themselves are warping and evolving.
Hopefully the work that's been done in the 1990s on component based development will congeal to the point where, ten years from now, I'll be able to say, "here we have an interface" and everyone in the room will have the same image in their mind. Right now, most people have blank stares because we don't have a consistent vision of how it works.
The problem is that we're still at the very beginning of the curve. I don't want to say the word 'formalisation', but I'll say it. There's no canon to speak of yet. There's no equivalent of Booch's book on object orientation for component software.
Because the idea of having abstract interfaces has been with us for a very long time. There's a great paper written by David Harness in the 1970s that lays a lot of the foundations for what we do now in COM. But a lot of the early work didn't take into account things like dynamic composition.
C++ is a great example. Smalltalk actually did take that into account, but Smalltalk didn't come through in the same way as C++. In C++ the whole compilation and linkage model assumes you're building a giant executable. It doesn't take into account that you might want to use that guy's software and this guy's software, and you might want to be able to replace the parts in the field. It wasn't the problem they were solving and that's why Java is in many ways more interesting.
One of the fundamental ideas behind Java is that we dynamically build everything: we never statically link. At run time we build our world, and it may be different every time. Whereas in Windows we have DLL Hell. The basic idea of DLLs is seriously flawed.
COM lays the seeds for an approach to version and configuration management that's not perfect, nor is it complete, but it does at least allow people to control those issues. The problem is people don't take advantage of them!
Visual Basic is a great example. If you use it properly it actually does a reasonable job of version management. However, it's not the default behaviour so you have to be aware that versioning is an issue, and version management is so badly documented in VB that the average developer building COM components is totally oblivious of how to get it right! Hopefully it will get better. The idea of using the interface as a rendezvous point for version navigation, which is what COM is about, makes a lot of sense.
If you look at the evolution of the Windows platform, there's basically three phases. The first phase centred around APIs: the Windows API, TAPI, MAPI, ODBC and so on. They shared a common theme: you had an H something, which was the handle, and a bunch of functions that all took the H something as a first parameter. Hey, it was the 1980s and we were all C programmers!
Then a lot of us had kids and mortgages and we started using VB, and the problem was that to use these APIs from VB needed all of these declare statements. Now the guy writing the DLL had to write not only the H file for the C and C++ programmers, but also all these declare statements. So in the post handle based world we moved to objects, and that's what COM is about. We expose new functionality from the platform using interfaces and object models, as opposed to handles.
However, the problem with either of these approaches is that the developer has to write code, and as we know the bugs are in the code: take away the code and the bugs go away! This is where attributes come in.
APIs are inherently problematic, because you have to program against them and it's very hard for the platform to know what you want to do without analysing your code. The idea with attribute-based programming is that you specify your intent. Perhaps that you need synchronisation. So rather than you writing a critical section of code, and the platform trying to figure out what you meant to say, you let the runtime do it for you in (hopefully) a less buggy way than you would have done yourself.
That is what MTS was about. MTS was not necessarily about transactions, although they certainly influenced the programming model. The idea was for you to attribute your code to indicate what you want, and it then happens. MTS installs an interception layer between the client and your object, and this layer does what you've indicated needs to be done, such as providing a transaction or doing access checks.
To be frank, most of the other new features in Windows 2000 and COM+ are of limited use to most people. Object pooling is a God-send for the small number of people who need it, but they've probably already implemented it themselves because they couldn't wait. The eventing service is nice to have, but not especially enabling. One can argue whether or not queued components are better than explicit message queuing, but that's a debate we don't need to have today.
These services are really not that exciting. To me, the really exciting thing about COM+ is this fundamental change which means we're moving to a world where we write the component and then configure it off-line to change the way it works.
Granted, when you work in MTS you don't need to worry about thread plumbing, but you do have other considerations that strongly influence the way you structure your software, and if you're ignorant of these then your software will melt unless it's the simplest of all components. Worst still, these considerations are completely hidden in the documentation - if they're documented at all.
The problem is, it does take a lot of time to really understand MTS, and the superficial story that you get from the documentation doesn't help. The COM documentation is pretty adequate. I look up an interface definition for the platform SDK and I'm ready let's go. It speaks my language; it's direct and to the point and does not treat me like an idiot.
With MTS, I cannot believe Microsoft produced such a wonderful technology with such brain dead documentation. It's because they are catering to the lowest common denominator. The message is, "Don't worry, you have to write almost no code and it's just going to be fine." A lot of people have got the idea that MTS is just going to make their problems go away. The reality is that you have to understand how MTS works before you can use it.
But let's get back to COM+. The most important thing about COM+, which will affect every user of the technology, is the concept of context. The idea is that we put all the objects that think alike into one context, and all the objects that think differently into a different context.
Now, replace the words red and blue with transaction A and transaction B, or synchronisation boundary 1 and synchronisation boundary 2. The idea is that you configure your components to be red or blue, or whatever, and the system will segregate them accordingly. This means the red objects can talk together really efficiently, but when they need to go and talk to the blue objects the system will turn the world blue, and then turn it to red again when they come back - all as efficiently as possible. That's the miracle; that's the key message of COM+.
Click here for our Privacy Statement. Copyright © Matt Publishing. All rights reserved. No part of this site may be reproduced without the prior consent of the copyright holder.
