Foreword
A guy walks into a bar and sees two well-dressed women in their mid-fifties talking to one another just within earshot. He hears one of the women saying, "What's your IQ? Mine is 155!" The other woman replies, "Really, mine is 149! How did you interpret the impact of Nelson's micro-economic theory on the development of post-Soviet Union Eastern Europe?" At this point, two men in athletic wear enter the bar in midconversation, catching the ear of our observer. The first man says, "I just had my IQ tested. I am a solid 115!" to which the second replies, "Excellent! My IQ was 108 last time I was tested. Say, who do you like for this Sunday's Giants/Dodgers game?" Not being a sports fanatic, the attention of our eavesdropper turns to two men in their late twenties sitting in a corner booth. He overhears the first man confess, "My IQ test results just came in. I only scored 63." Trying to console his friend, the second man replies, "Don't feel bad, my IQ is only 59. By the way, which is better: C++ or Visual Basic?"
VB is dead. Finally.
OK, so VB the tool is still alive. But VB as a derogatory label, a culture, an all-encompassing worldview, is dead as a doornail.
For me, the beginning of the end was the first edition of the book you are now reading. Prior to that point, VB was considered an absolute toy amongst most of my colleagues. Worse, VB users were considered to be the people not competent enough to get jobs in documentation, testing, or marketing. VB was often viewed as society's "safety net" that provided "workfare" for those who could not make it on their own as software developers.
And then came Ted's first book.
When developers asked me about good MTS programming books, I constantly found myself recommending Ted's book. At first, I apologized for the VB-related content in the book. "Just pencil in the semicolons if you need them," I would exclaim. However, I eventually grew tired of playing the role of "VB apologist" and decided to rethink my views. At that point, I came to the following realization:
We all are VB programmers in one way or another.
VB programmers are (correctly) portrayed as being blind to a set of issues many consider to be critical. If this is the litmus test for being a VB programmer, then Dim me As VBProgrammer. I care deeply about component integration, yet I am blind to T-SQL optimizations in SQL Server 7.0. My office mate just wrote a 400-page treatise on NT security, yet he couldn't tell you the difference between an unparsed general entity and an internal parameter entity if his life depended on it. In the information-overload world we live in as software developers, selective ignorance is the only way to survive.
Ted (unlike many writers, including myself) has embraced the selective ignorance chromosome that is present in all developers, not just those who have embraced the development tool that dares not speak its name. The first edition of this book demonstrated Ted's mastery of focusing the attention of the reader on the concepts that are important. Unlike the 800-page behemoths so common in this field, Ted's book was a digestible morsel of information that made the able developer more able to solve the problems at hand. This second edition brings Ted's story up to date with the current state of the practice in COM development and will be a valuable addition to the component software canon.
Don Box
Redondo Beach, California
Acknowledgments
First and foremost, I must acknowledge DevelopMentor. For any of you who are unfamiliar with this company, DevelopMentor focuses on training and education for developers building distributed systems. DevelopMentor is made up of the brightest and most enthusiastic group of computer scientists I have ever encountered—a peer group of the highest level of technical integrity. I consider myself extremely fortunate to have been part of this community for the last six years of my life. Many of the ideas, analogies, and recommendations in this book derive from a shared viewpoint and common base of knowledge that have grown out of the DevelopMentor community.
Many thanks to Mike Abercrombie, Lorrie Trussell, and everyone else who works at DevelopMentor. I am grateful for all your hard work building this rich and nourishing environment, which has given me so many opportunities. DevelopMentor has allowed me to exchange ideas with some of the industry's top researchers and to pursue my passion for cutting-edge technology.
I'd like to give a very special thanks to Don Box. I am especially indebted to Don for his guidance and advice on so many aspects of my career. His vision has been incredibly valuable in structuring the story this book tells. If it weren't for the questionable choices Don makes time after time when buying a laptop computer, I would consider him the smartest man in the software industry today.
I'd like to thank those subject experts who reviewed chapters and provided valuable feedback and constructive criticism. You have made this book considerably better and more accurate. I had lots of support from the different product groups within Microsoft. Thanks to Robert Green from the Visual Studio team for reviewing the first five chapters. Thanks to George Reilly from the IIS teams for reviewing the chapter on IIS and ASP. Thanks to Dick Dievendorff from the MSMQ team for reviewing my messaging chapter. A special thanks to Joe Long from the COM+ team for taking the time to answer countless questions I had when writing the chapters on the internals of COM+.
There were also many people at DevelopMentor who conducted valuable chapter reviews. Thanks to Bob Beauchemin and Jason Masterman for contributing their expertise in the areas of transaction processing and COM+ distributed services. Thanks to Tim Ewald for making excellent recommendations about architectural design issues and explaining how things work way down under. Thanks to Doug Tenure for giving me feedback on some of the earlier chapters on COM. Thanks to Keith Brown, Steve Rodgers, and Dan Sinclair for thoroughly reviewing my security chapter. Thanks to Aaron Skonnard for reviewing several chapters and making excellent suggestions about how to motivate and explain software development based on IIS, ASP, and XML. Thanks to my buddy Brian Randell for his research and his passionate views on the subject of component versioning. Chapter 5 is an adapted version of an article I coauthored with Brian for Microsoft Systems Journal. Don't tell anyone (especially Brian), but I think a few of the paragraphs in this chapter might even have been written by him.
DevelopMentor is a great place to work because it's full of legendary characters. Mike Woodring has rewritten the Island Hopper samples using nothing but assembly language. Calvin Caldwell once paused between steps in the ATL COM AppWizard to go out back (on his ranch) and deliver a baby calf. During an intensive week-long course, Dr. Joe Hummel led a cab ride of eager students into Hollywood in the early morning hours to provide a realistic simulation of what it's like to transmit packets across the Internet. And then there's this guy, Fred Wesley, who thinks so hard and so deep that none of us really understands a word he says. The joke about Fred is that he spends so much time contemplating and debating the theory of thought that he never gets around to the practice of thinking.
I also need to thank all my other peers at DevelopMentor including Niels Berglund, Henk de Koning, Jon Flanders, Martin Gudgin, Stuart Halloway, Justin Hoagland, Simon Horrell, Kevin Jones, Paul Kirby, John Lam, Brian Meso, Jose Mojica, Gus Molina, Brad E. Needham, Fritz Onion, Simon Perkins, Brent Rector, Dave Schmitt, George Shepherd, David Smallberg, Dan Weston, and Jason Whittington. All of you have contributed in one way or another to my overall understanding of computer science and software development.
Last but surely not least, I must give recognition to Chris Sells, the evil genius of DevelopMentor. Chris, more than any other individual, is responsible for my career direction. He's the one who ultimately led me down the path to writing about Visual Basic and COM. It was Chris's overly adequate explanations of casting away const, template specialization, and functor objects that convinced me that I would never find happiness as a C ++ programmer.
I'd like to thank everyone I have worked with at Fawcette Technical Publications. Thanks to all the hardworking people who put the VBITs conferences together, including Tena Carter, Janet Nickels, Robert Scoble, Maryam Ghaemmaghami, Jennifer Brucker, and Diamond Jim Fawcette.
Thanks to Joshua Trupin and Joseph Flanigen for publishing my articles in MSDN Magazine, Microsoft Systems Journal, and MIND. I'd also like to thank the other people at these publications who helped me get my words into print, including Joanne Steinhart, Terry Dorsey, Etna Novik, Joan Levinson, and Michael Longacre.
I would like to thank Claudette Moore and Debbie McKenna at the Moore Literary Agency for their support and assistance. Thanks especially to Claire Horne for helping me create and shop the proposal for the first edition of this book.
I am especially appreciative of all the people at Microsoft Press for helping me put this book together. This includes my acquisitions editor, Ben Ryan, and a very talented editing and production team. Many thanks to Kathleen Atkins for doing an excellent job as lead editor and project manager. Thanks, too, to Sally Stickney for her contributions editing the manuscript. I was also very lucky to have Ina Chang as the manuscript editor and Steve Perry as the technical editor. I hope to work with all of them again in the future.
Finally, I would like to thank the attorneys who work for Microsoft. In retrospect, I am very grateful that you made me spell out "Visual Basic" at every possible occasion instead of allowing me to use the friendly two-letter abbreviation that we all use when referring to our beloved development tool. You have undoubtedly added at least 10 pages to this text and you have, therefore, increased the perceived value of my book to the casual observer looking through the shelves at her local bookstore.
Who Is This Book For?
I believe that a thorough knowledge of COM and COM+ is a prerequisite to building multitier applications with Windows 2000. From my perspective, there's no way you can build scalable applications without a solid understanding of the infrastructure that supports the applications. To that end, the purpose of this book is to explain the critical parts of COM+ and Windows 2000 that affect the way you design and write components for a distributed application.
This book is for intermediate and advanced Visual Basic programmers who want to develop for COM+ and Windows 2000. The book focuses on the architecture of the Windows platform. To this extent, it can also serve as a resource for ASP and C++ developers. Some readers might be new to COM. Other readers might already have experience with COM and Microsoft Transaction Server (MTS). My goal in this edition is to accommodate both kinds of readers.
Over the past five years, I've thought long and hard about how to craft a story that includes just the right amount of detail. Some technical details are critical. Other technical details are esoteric, and absorbing them would waste your mental bandwidth. I've tried to cover what's important and omit what's not. I wanted to cover a lot of territory while keeping the text as concise as possible. While I make a point of avoiding unnecessary complexity, I also reserve the right to dive into low-level details in places where I think it's appropriate.
Many Visual Basic programmers don't have the motivation or aptitude to learn about COM and COM+ at this level. Visual Basic can extend a modest amount of the platform's functionality to these programmers without their needing any knowledge of the underlying technology, but they won't be able to create large information systems with COM+, IIS, ASP, and MSMQ. This book is most definitely not for them.
For Readers Already Familiar with the First Edition
I've always hated buying the second edition of a technical book just to find out that it had a new cover and the same old text. One of my main goals with the second edition has been to create something that adds value for those who have read the first edition. Over 75 percent of the text for this book is newly written for the second edition.
I have restructured my coverage of the fundamentals of classic COM and placed them as early in the book as possible. Chapter 2, which covers interface-based programming, is the one chapter that's basically the same in both editions. I've condensed the fundamentals of COM that were spread across several chapters in the first edition into Chapter 3 of this edition. Chapter 4 and Chapter 5 describe using Visual Basic to create and version components. The material in these chapters has been enhanced from the first edition with new coverage of building custom type libraries with IDL and designing components for scripting clients. For programmers who are already comfortable with COM and MTS, Chapters 2 through 5 can serve as a quick review or as a reference.
Chapter 6 and Chapter 7 cover the architecture of the COM+ runtime environment. The aim is to teach you how to write configured components that take advantage of the runtime services and thread pooling offered by COM+. Chapter 8 on transactions introduces new material that compares local transactions to distributed transactions. Chapter 9 includes new and essential coverage of IIS and ASP. Chapter 10 on messaging has coverage of MSMQ similar to the first edition, but it also adds new material about the Queued Components Service and COM+ Events. Chapter 11 is a security chapter recently written from the ground up. (I hope it isn't as painful for you to read as it was for me to write.) Chapter 12 covers application design issues that affect scalability and performance.
What Experience Do You Need?
I assume that you have a background that includes object-oriented programming and creating applications that use classes. It doesn't matter whether you learned about classes using Visual Basic, C++, or Java. It's just important that you understand why you would design a class using encapsulation and that you understand the relationship between a class and an object.
It's helpful but not essential that you have some experience in computer science or a low-level language such as C. It would be impossible for me to tell you about COM without talking about things such as pointers, memory addresses, stack frames, and threads. If you don't have this background, please take the time to contemplate what's going on at a lower level. Occasionally your temples might begin to throb. But the time and effort you invest will be more than worthwhile.
Most readers of this book will have done some work in database programming. It's hard to imagine that an intermediate Visual Basic programmer could have gotten by without having worked on at least one database-oriented application. When I describe writing transactions for COM+ objects, I assume that you have a moderate comfort level with ActiveX Data Objects (ADO) and Structured Query Language (SQL). If you don't have this background, you should acquire it on your own. The ADO and SQL code presented in this book isn't overly complicated.
In the chapter on IIS and ASP, I assume you know the basics of using HTML and creating simple ASP pages. Given the background of most readers and the availability of quality reference material on ASP, I didn't see much point in covering those details.
What's Not in This Book
This book doesn't contain many step-by-step instructions. Therefore, this book won't appeal to those who just want to know what to do but don't care why. Throughout the book, I refer you to MSDN to get the details concerning such practices as using the administrative tools for COM+ or IIS. I don't think these are areas in which most programmers need assistance. My goal is to build your understanding of the theory behind the software.
I don't tell you much about how to automate COM+ or IIS administration through scripting or custom administrative applications. While both COM+ and IIS provide rich object models for automating administrative chores, I don't spend much time on it. I cover a little bit of these topics here and there, but I expect you to learn the details through the documentation in MSDN and the Platform SDK.
If you're looking for a book with a great big sample application that you can use as a starting point, this isn't the right book for you. Most of my code listings are short, between 5 and 10 lines. When I present a code listing, I always try to do it in as few lines as possible to focus your attention on a particular point. I omit extraneous things such as error handling. For this reason, my style doesn't lend itself to those who are looking to blindly copy-and-paste my samples into production code. When it comes to presenting code, my goal is to teach you to fish as opposed to simply giving you fish.
