Transactional COM+ Building Scalable Applications

by Ewald, Tim

• ISBN13: 9780201615944
• ISBN10: 0201615940
• Edition: 1st
• Format: Paperback
• Copyright: 2001-03-06
• Publisher: Addison-Wesley Professional

Summary

Tim Ewald, COM columnist for DOC Magazine, explains how COM+ works, and then sets out specific rules intended as concrete guidelines to help developers build COM+ systems.

Author Biography

Tim Ewald is a Director of Content at DevelopMentor, a premier developer services company. His research and development work focuses on the design and implementation of scalable systems using component technologies such as COM and Java. Tim has authored or co-authored several DevelopMentor courses, including the MTS and COM+ curriculum. He is also a co-author of Effective COM (Addison-Wesley), a former columnist for DOC and Application Strategies, and a frequent conference speaker. Before joining DevelopMentor, Tim worked as an independent consultant specializing in COM and related technologies.

0201615940AB04062001

Table of Contents

Foreword	xiii
Preface	xv
Scalability	1	(50)
Scalability Basics	1	(3)
Identity	4	(2)
Identity in COM	6	(1)
Sharing Identities	7	(4)
Implementing Named Objects	8	(2)
The Problem with Sharing COM Objects	10	(1)
Identity Revisited	11	(10)
Implementing Named Objects with Key-Based Logical Identity	12	(3)
Implementing Named Objects on Top of a Database	15	(4)
What Has Been Gained?	19	(2)
The Object-per-Client Model	21	(3)
Transactions	24	(7)
Enter Transactions	25	(1)
Clients and TMs and RMs, Oh My!	26	(1)
Local Transactions and Distributed Transactions	27	(2)
The Transactions and Scalability Paradox	29	(2)
Integrating Objects and Transactions	31	(7)
Using Transactions Explicitly	31	(1)
Using Transactions Implicitly	32	(1)
Applying Transactions	32	(4)
Thinking about Roundtrips	36	(2)
A Complex Problem	38	(11)
A Possible Solution	40	(1)
A Much Better Solution	41	(3)
Thinking about Roundtrips Again	44	(2)
Processor Objects	46	(3)
Summary	49	(2)
Atoms	51	(32)
The Linker Switch Story	51	(3)
An Experiment	52	(1)
The Windows Process Loader	53	(1)
How COM+ Works	54	(1)
From Consoles to Contexts	54	(3)
Cross-Context Calls	56	(1)
Contexts as Objects	57	(4)
Object Context Interfaces	59	(1)
Using Object Context	60	(1)
Where Do Contexts Come From?	61	(12)
The Catalog	62	(1)
Applications	63	(2)
Libraries and Servers	65	(2)
Why Library Applications?	67	(1)
Configured Classes	68	(1)
Custom Attributes	68	(3)
Changing the Contents of the Catalog	71	(2)
Context Flow	73	(2)
Causality	75	(3)
How Causality Works	76	(2)
Causalities as Objects	78	(4)
Call Context Interfaces	79	(2)
Using Call Context	81	(1)
Summary	82	(1)
Mechanics	83	(34)
Context Relativity	83	(11)
The Problem	84	(5)
Marshaling Interface Pointers	89	(1)
The Global Interface Table	90	(4)
Context Relativity in Day-to-Day Life	94	(1)
The Cost of Contexts	94	(8)
A Context for Every Object	95	(1)
The Cost of Contexts in Time	96	(2)
The Cost of Contexts in Space	98	(3)
Are Contexts Worth the Price?	101	(1)
Limiting Context	102	(11)
Nonconfigured Classes	102	(1)
Raw-Configured Classes	103	(2)
Context-Aware Code Revisited	105	(3)
A Different Way of Looking at the World	108	(2)
Subtle Complexities	110	(2)
Custom Marshaling	112	(1)
Some Other Observations	113	(2)
Summary	115	(2)
Threads	117	(40)
Apartments	117	(11)
Apartment Types	119	(1)
Where Do Apartments Come From?	120	(2)
Threading Models	122	(2)
Default Contexts	124	(3)
Remote Object Creation	127	(1)
Cross-Apartment Calls	128	(5)
STA Complexities	129	(4)
Cross-Apartment Call Overhead	133	(1)
Apartment Guidelines	133	(5)
Raw-Configured Classes Revisited	138	(1)
Activities	138	(6)
Enter Activities	139	(1)
Where Do Activities Come From?	140	(3)
Detecting the Presence of an Activity	143	(1)
Allocating STA Objects to Apartments	144	(4)
Serializing Calls	148	(6)
Activity Reentrancy	151	(1)
Activity Deadlock	152	(2)
Activity Guidelines	154	(1)
Summary	155	(2)
Objects	157	(36)
Object Pooling	158	(8)
Enabling Object Pooling	158	(2)
Reusing Objects	160	(3)
Controlling the Size of a Class's Pool	163	(3)
Implementing Pooled Classes	166	(7)
Accessing Context	166	(1)
Managing Resources	167	(2)
The GIT Trick (and Why It Doesn't Work)	169	(3)
An Exception to the Rules	172	(1)
Object Pooling Guidelines	173	(1)
Just-in-Time Activation	174	(8)
Enabling JITA	174	(1)
How JITA Works	175	(1)
Flipping the Done Bit	176	(3)
The AutoComplete Attribute	179	(1)
JITA Notifications	179	(3)
JITA Guidelines	182	(6)
Lies, Damn Lies, and Statistics	188	(2)
Summary	190	(3)
Transactions	193	(56)
Local Transactions	194	(6)
OLE DB	195	(3)
Higher Level APls	198	(2)
Distributed Transactions	200	(10)
Enter the Distributed Transaction Coordinator	200	(3)
Starting a Distributed Transaction	203	(2)
Enlisting a Connection	205	(2)
The Two-Phase Commit Protocol	207	(3)
Distributed Transaction Complexities	210	(8)
Distributed Transaction Propagation	210	(6)
Connection Management	216	(1)
A Race Condition	217	(1)
Declarative Transactions	218	(27)
Transactional Objects	219	(1)
Enter Transaction Streams	220	(1)
Where Do Transaction Streams Come From?	221	(5)
Detecting the Presence of a Transaction Stream	226	(1)
Creating and Propagating a Distributed Transaction	227	(2)
Autoenlisting Connections	229	(5)
Controlling a Declarative Transaction's Outcome	234	(3)
Flipping the Happy Bit	237	(2)
The Four Possible States of a Transactional Object	239	(4)
Root Objects and HRESULTs	243	(1)
Transaction Stream Caveats	243	(2)
Transaction Guidelines	245	(1)
Summary	246	(3)
Isolation	249	(40)
Correctness versus Performance	250	(15)
Five Degrees of Isolation	252	(1)
Implementing Isolation Using Locks	253	(3)
Implementing Isolation Using Versions	256	(4)
Choosing an Isolation Level	260	(4)
Isolation-Level Guidelines	264	(1)
Specifying Isolation Levels	265	(8)
Isolation Levels and OLE DB	266	(1)
Isolation Levels and the DTC	267	(2)
Isolation Levels and COM+	269	(1)
Bring Your Own Transaction	269	(4)
ISOFLAGs	273	(1)
Deadlocks	273	(6)
Avoiding Deadlocks	273	(1)
Detecting Deadlocks	274	(1)
Timeouts and the DTC	275	(2)
Timeouts and COM+	277	(1)
Timeouts and OLE DB	278	(1)
Application-Level Isolation	279	(7)
Optimistic Application-Level Locking	280	(1)
Pessimistic Application-Level Locking	281	(5)
Summary	286	(3)
Protocols	289	(62)
HTTP	289	(5)
HTTP Messages	290	(3)
HTTP Connection Management	293	(1)
Internet Information Server	294	(14)
Mapping Requests to Files	294	(5)
Mapping Requests to Processes	299	(5)
Mapping Requests to Contexts and Apartments	304	(3)
Processing Requests in Parallel	307	(1)
Active Server Pages	308	(20)
Processing ASP Requests	309	(2)
Transactional Pages	311	(5)
Transaction Outcome Notifications	316	(6)
Server.Execute and Server.Transfer	322	(2)
ASP Pages and Raw-Configured Classes	324	(1)
ASP Pages and Object Context	325	(3)
HTTP + XML = RPC	328	(10)
SOAP Messages	329	(2)
SOAP and HTTP	331	(6)
Applying SOAP	337	(1)
Message Queuing	338	(10)
Transactional Messaging	340	(6)
Applying Message Queuing	346	(2)
Summary	348	(3)
Design	351	(24)
Machines, Processes, and Protocols	351	(5)
Machine Architecture	351	(1)
Process Architecture	352	(2)
Protocols	354	(2)
Processors and Helpers	356	(9)
A Simple Logical Model	356	(2)
A Simple Physical Model	358	(5)
Accessing Processors via HTTP	363	(2)
Transactions and Data Access	365	(3)
Accessing Data Efficiently	367	(1)
Middle-Tier State	368	(5)
Some Final Advice	373	(2)
Appendix A: Toward .NET	375	(4)
Appendix B: Building a Better Connection Pool	379	(12)
An Example	380	(11)
IObjectConstruct	382	(2)
IObjectControl	384	(2)
IConn	386	(2)
Using a Pooled Connection	388	(1)
Source Code	389	(2)
Appendix C: Debugging	391	(2)
Appendix D: Catalog Attributes and Component Services Explorer Property Pages	393	(18)
Application Property Pages	394	(6)
Class Property Pages	400	(6)
Interface Property Pages	406	(3)
Method Property Pages	409	(2)
Rules Summary	411	(4)
Index	415

Excerpts

I am (metaphorically speaking) the man on the cover of this book. Or at least I was four years ago. That's when I first encountered the Microsoft Transaction Server (MTS), the precursor to COM+, and knew that my life as a COM developer had changed forever. I very rapidly discovered that the traditional COM object models I was used to did not work in the MTS environment. That annoyed and fascinated me, so I set out to understand why. At first I was blind in my belief that the MTS team had things all wrong--that its creators did not understand distributed objects at all. Over time, however, I came to see why MTS worked the way it did. The answer, quite simply, was scalability.MTS was designed to simplify the development of scalable distributed applications, and everything it did was in service of that goal. Viewed in that light, the things MTS did with objects (e.g., not sharing them between clients and deactivating them when their transactions ended) finally made sense to me. While all of this was happening, I was spending a lot of time writing and teaching classes about MTS. I met a number of developers who were struggling the same way I had and who needed help. Like me, they wanted to know how MTS worked, why it worked that way, and, most important, how to design systems that used it. It became clear to me that I had a story to tell and that I had to write this book.It took a long time. In fact, the writing process took so long that this book isn't about MTS at all, but its descendant, COM+. What Is COM+?COM+ is a runtime environment that provides services to instances of classes that declare their desire to use the services. For example, if a class declares that it needs causality-based call synchronization, the COM+ runtime makes sure that only one logical thread of action invokes an instance's methods at a time. Or, if a class declares that it needs a distributed transaction, the COM+ runtime makes sure that one is available. COM+-based systems can be written in C++, Visual Basic 6, or any other COM-friendly language today; and the systems in C#, Visual Basic 7, or any other Common Language Runtime-friendly language tomorrow. The COM+ runtime serves as the foundation for many higher-level technologies, including Internet Information Server (IIS), Active Server Pages (ASP), Site Server, Application Center 2000, and Biztalk Server 2000.COM+ is the cornerstone of a framework of technologies designed to support the development of large-scale distributed applications on the Windows platform. The current, shipping version of the framework is called Windows DNA. The next version is called .NET. Both versions have similar overall architectures that are based on three assumptions about the needs of scalable systems: They must be accessible by multiple users on internal networks' machines and the Internet, running both browser-based and custom client applications. They must use multiple server machines to handle a high volume of client requests concurrently. They must be robust in the face of failure.From these assumptions, both frameworks derive three basic principles: System logic is consolidated on servers, not on clients or in backend databases.Servers can share resources (e.g., database connections), encapsulate database schemas and data access technologies, and offer a tightly controlled security environment. Transactions are at the center of the programming model.They provide a standard model for protecting distributed system state in the face of both concurrent access and system failure. The majority of system state must be kept under transactional control (e.g., in a database). The components in a system communicate using a variety of protocols.Clients typically communicate with servers using HTTP and, increasingly, Simple Object Access Protocol (SOAP); DCOM and Microsoft Message Queue