Table Of ContentCOM and .NET Component Services
Dedication
Foreword
Preface
Scope of This Book
Some Assumptions About the Reader
Definitions and Text Conventions
Other COM+ Books and References
How to Contact Us
Acknowledgments
1. COM+ Component Services
1.1 COM+ Component Services
1.2 The Component Services Explorer
1.3 Hello COM+
1.4 COM+ Configured Components
1.5 Applications, DLLs, and Components
1.6 Configuring COM+ Applications
1.7 Debugging COM+ Applications
1.8 Deploying COM+ Applications
1.9 Summary
2. COM+ Context
2.1 Encapsulation via Marshaling in COM
2.2 Encapsulation via Interception in COM+
2.3 The Context Object
2.4 The Call Object
2.5 Cross-Context Manual Marshaling
2.6 Summary
3. COM+ Instance Management
3.1 Client Types
3.2 Instance Management and Scaling
3.3 Object Pooling
3.4 Just-in-Time Activation
3.5 Combining JITA with Object Pooling
3.6 Object Constructor String
3.7 COM+ Instance Management Pitfalls
4. COM+ Transactions
4.1 Transaction Basics
4.2 Transaction Properties
4.3 Transaction Scenarios
4.4 COM+ Transactions Architecture
4.5 Configuring Transactions
4.6 Voting on a Transaction
4.7 Transactional Object Life Cycle
4.8 Designing Transactional Components
4.9 Nontransactional Clients
4.10 Transactions and Object Pooling
4.11 Compensating Transactions
4.12 Transaction Execution Time
2
4.13 Tracing Transactions
4.14 In-Doubt Transactions
4.15 Transaction Statistics
4.16 COM+ Transactions Pitfalls
5. COM+ Concurrency Model
5.1 Object-Oriented Programming and Multiple Threads
5.2 Apartments: The Classic COM Solution
5.3 Activities: The COM+ Innovation
5.4 COM+ Configuration Settings
5.5 Activities and JITA
5.6 Activities and Transactions
5.7 Tracing Activities
5.8 The Neutral Threaded Apartment
5.9 Summary
6. Programming the COM+ Catalog
6.1 Why Program the Catalog?
6.2 The Catalog Programming Model
6.3 Catalog Structure
6.4 Interacting with the Catalog
6.5 Features of COMAdminCatalog
6.6 The COM+ Catalog and Transactions
6.7 Summary
7. COM+ Security
7.1 The Need for Security
7.2 Basic Security Terms
7.3 Role-Based Security
7.4 Securing a Server Application
7.5 Securing a Library Application
7.6 Programmatic Role-Based Security
7.7 Security Boundaries
7.8 Advanced COM+ Security
7.9 COM+ Security Pitfalls
7.10 Summary
8. COM+ Queued Components
8.1 Major Benefits of Queued Components
8.2 Queued Components Architecture
8.3 Component Services Explorer Configuration
8.4 Invoking Queued Components on the Client Side
8.5 Designing Queued Component Interfaces
8.6 Receiving Output from a Queued Component
8.7 Queued Component Error Handling
8.8 Queued Components and Transactions
8.9 Synchronous Versus Asynchronous Components
8.10 Queued Components Security
8.11 Queued Components Pitfalls
8.12 Summary
9. COM+ Event Service
9.1 Classic COM Events
9.2 COM+ Event Model
9.3 The Event Class
9.4 Subscription Types
9.5 Delivering Events
3
9.6 Event Filtering
9.7 Distributed COM+ Events
9.8 Asynchronous Events
9.9 COM+ Events and Transactions
9.10 COM+ Events and Security
9.11 COM+ Events Limitation
9.12 Summary
10. .NET Serviced Components
10.1 Developing Serviced Components
10.2 .NET Assemblies and COM+ Applications
10.3 Registering Assemblies
10.4 Configuring Serviced Components
10.5 Application Activation Type
10.6 The Description Attribute
10.7 Accessing the COM+ Context
10.8 COM+ Context Attributes
10.9 COM+ Object Pooling
10.10 COM+ Just-in-Time Activation
10.11 COM+ Constructor String
10.12 COM+ Transactions
10.13 COM+ Synchronization
10.14 Programming the COM+ Catalog
10.15 COM+ Security
10.16 COM+ Queued Components
10.17 COM+ Loosely Coupled Events
10.18 Summary
A. The COM+ Logbook
A.1 Logbook Requirements
A.2 Log File Example
A.3 Using the Logbook
A.4 Configuring the Logbook
A.5 How Does the Logbook Work?
A.6 Summary
B. COM+ 1.5
B.1 Improved User Interface Usability
B.2 Legacy Applications and Components
B.3 Disabling Applications and Components
B.4 Pausing Applications
B.5 Service Activation Type
B.6 Improved Queuing Support
B.7 Application Pooling and Recycling
B.8 Application Dump
B.9 Application Partitioning
B.10 Aliasing Components
B.11 Configurable Transaction Isolation Level
B.12 Improved Context Activation Setting
B.13 Private Components
B.14 Web Services in COM+ 1.5
B.15 Summary
C. Introduction to .NET
C.1 .NET Programming Languages
C.2 Packaging .NET Components: Assemblies
C.3 Developing .NET Components
4
C.4 Writing .NET Client-Side Code
C.5 .NET as a Component Technology
C.6 Composing Assemblies
Colophon
5
Dedication
To my wife, Dana
6
Forew ord
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
7
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
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
8
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 (www.objectwatch.com)
Author, COM+ and the Battle for the Middle Tier
Austin, Texas
9
Preface
This book discusses COM+ component services. Each service is
covered in its own chapter, and each chapter discusses a similar
range of issues: the problem the service addresses, possible
solutions to that problem, an in-depth description of the COM+
solution, tradeoffs, design, and implementation guidelines, tips, and
known pitfalls. I have tried to provide useful design information and
lessons I learned while applying COM+. I also describe COM+ helper
classes and utilities I developed that will enhance your productivity
significantly. (The COM+ Events helper objects and the COM+
Logbook are prime examples.) This book focuses on the "how to"—
that is, it provides practical information. You should read the
chapters in order, since most chapters rely on information discussed
in the preceding chapters. The book also aims to explain COM+ step
by step. A software engineer already familiar with COM who wants
to know what COM+ is and how to use it can read this book and
start developing COM+ applications immediately.
Scope of This Book
Here is a brief summary of the chapters and appendixes in this
book:
• Chapter 1 introduces the Component Services Explorer and
basic COM+ terminology. This chapter deliberately holds your
hand as you develop your first "Hello World" COM+
component. Subsequent chapters do much less handholding
and assume you are familiar with the COM+ environment. If
you already have experience with basic COM+ development,
feel free to skip this chapter.
• Chapter 2 demystifies the COM+ context by presenting it as
the key mechanism for providing component services using
call interception. Generally, you need not be concerned with
contexts at all. However, the COM+ context underlies the way
COM+ services are implemented.
• Chapter 3 describes two scalability-enabling mechanisms that
COM+ provides for a modern enterprise application: object
pooling and Just-in-Time Activation (JITA). The discussion of
instance management, and especially JITA, is independent of
transactions. Early COM+ documentation and books tended to
couple instance management and transactions. However, I
found that not only can you use instance management
independently of transactions, but it is easier to explain it that
10
