COM+ |
The COM+ Model
A typical COM+ model is shown in the Figure below and is made up of:
1. The COM+ Surrogate Process (DLLHOST.EXE)
2. The COM+ Class Loading and Remoting Framework (OLE32.DLL)
2. The Context Object and Wrapper Proxies for each component
3. The COM+ Server Component
4. COM+ clients
5. Auxiliary systems like COM+ runtime services, the Service Control Manager (SCM), the Microsoft Distributed Transaction Coordinator (MS-DTC), the Microsoft Message Queue (MSMQ), the COM-Transaction Integrator (COM-TI), etc.
Components that run under the control of the COM+ Surrogate are called COM+ components. These components are deployed and run in the COM+ Surrogate (DLLHOST.EXE), and are managed by the COM+ Class Loading and Remoting Framework (OLE32.DLL). As is usual with COM+ components, the object implementing the IClassFactory serves as a Factory Object to create new instances of these components. COM+ inserts an Interceptor (which consists of a Factory Wrapper Object and an Object Wrapper) between the actual COM+ component that the Framework manages, and it's Client. Therefore, whenever the client makes a call to the COM+ component, the Wrappers (Factory and Object) intercept the call and inject their own instance management algorithm called the Just In Time Activation (JITA) into the call. The wrapper then makes this call on the actual COM+ component. In addition to this, based on the information from the component's deployment properties, transaction logic and security checks are also done in these wrapper objects. For every COM+ component, there also exists a Context Object that implements the IObjectContextInfo interface. The Context Object maintains specific information about that component such as its transactional information, security information and deployment information. The COM+ component calls into the Context Object through its IObjectContextInfo interface.
COM+ - Just In Time Activation (JITA)
In COM+, the actual middle-tier COM+ component is not created until the call from a client reaches the container. Since the component is not running all the time, it does not use up a lot of system resources (even though a context wrapper and stub for the component are still hanging around for the component). As soon as the call comes in from the client, the interceptor activates its Instance Management algorithm called JITA. The actual COM+ component is created "Just In Time" to service the request from the wrapper. And when the request is serviced and the reply is sent back to the client, and the component either calls SetComplete()/SetAbort(), or the transaction that it's part of ends, or the client calls Release() on the component, the actual COM+ component is deactivated. In short, COM+ is a stateless component model. Generally, this is what happens on the Server when a client requests services from a typical COM+ component:
1. Acquire a database connection.
2. Read the component's state from either the Shared Property Manager or from an already existing object or from the client.
3. Perform the business logic.
4. Write the component's changed state, if any, back to the database.
5. Close and release the database connection.
It is thus possible to implement high latency resources as asynchronous resource pools, which should take advantage of the stateless JIT activation afforded by the middleware server.
Transactional Model in COM+
In the COM+ model, each COM+ component declaratively declares its transactional primitives. The COM+ runtime environment automatically initiates transactions. For every component, COM+ creates a corresponding Context Object that contains information like the transaction identity, the current activity identifier, the security ID of the caller, etc. The Context Object is loaded as part of the COM+ Surrogate Process (OLE32.DLL). In addition to holding the Context Object, the COM+ Surrogate Process takes part in transaction processing on behalf of the component. The components and the COM+ Surrogate Process typically execute in a separate host process provided by the COM+ runtime (DLLHOST.EXE). COM+ uses OLE Transaction technology to carry out two-phase commit transactions. This model defines three entities in transaction processing:
1. Transaction Client,
2. Transaction Manager - the Microsoft Distributed Transaction Coordinator (MS DTC for short), and
3. Resource Manager - anything that manages persistent, durable resources such as a database or a file and allows transactional access to the underlying data (e.g., SQL Server).
The Figure below illustrates the transaction model in COM+.
The COM+ Surrogate does a good job of isolating COM+ components from the details of how transactions are carried out. The COM+ Surrogate, the Dispenser Manager, and the MS DTC do most of the work required to perform two-phase commit, distributed transactions behind the scenes. To achive this, COM+ takes on all the major responsibilities of a Transaction Client and performs such steps as:
1. Creating transactions and maintaining the transaction context,
2. Instructing MS DTC to commit or abort the current transaction,
3. Propagating the transaction context to all participating objects and enlisting the appropriate resources.
COM+ is an umbrella name for a number of new features in Microsoft's Component Object Model (COM).
COM+ is, in large part, a merging of Transaction Server (MTS) and Message Queue (MSMQ) into the base framework of COM. It is basically the unification of COM, MTS and MSMQ,
in addition to:
Extensions to COM
Extensions to MTS
and the addition of other services.These services include self-describing components, queued components, events, security, transactions, and load balancing.
Self Describing Components
Self-describing components are standard COM components that have attributes associated with them. The attributes --not to be confused with properties that can be programmatically set and queried-- are runtime characteristic that can be applied to the component. Administrators can define attribute values at runtime or developers can define the values at design time. For example, a designer might stipulate that a component requires transaction.Administrators can override other attributes. It is possible to pass an attribute to a component as it is created. The attribute can be a database connection string as an example. This would allow a component to redirect opens to a database replica in case the master cannot be immediately recovered.
Queueing
Probably the most prominent new feature of COM is support for Queued components (QC). An ordinary component that accepts only in parameters can be marked at design time (through self-description) or runtime as a QC. In normal mode, all interactions with the component occur in real-time using DCOM. But when a component is used in QC mode, the client-side stub silently records interactions between the application and the component. When the component is destroyed, the interactions are batched into an MSMQ message and sent across the network. QC interactions can leverage common MSMQ messaging properties like recovery and transactions --again through self-description or by administrative control. At the target queue, a player reads the interactions and replays them. Another feature of QCs is automatic processing of poison messages --transactions that are never going to succeed and stay at the head of a queue.Events (Loosely Coupled Events)
COM+ provides a multi-publisher, multi-subscriber event channel mechanism. Unlike many other publisher-subscriber mechanisms, COM+ events can have a semantically rich interface. That is, a publisher might callTeller.credit(Athul, 1000001);
rather than
SendEvent(channel=Teller, name=Athul, credit=1000001);
Publication and Subscription is at the method level. In other words, it's highly granular -- you can have different publishers emitting events to each method and different subscribers receiving events through each method. Anyone or any program can register another program to publish or subscribe to events. Event filters can be defined at the publisher or at the subscriber ends of an event channel. Events, publications, filters and other event machinery can be secured using standard NT 5 security. Redirection allows events to be republished as invocations to ordinary COM objects. Finally, events can be sent using DCOM or as Queued Components (when broader fan-out and maximum scaleability are needed).
Transactions
The transaction features of COM+ are a repackaging of MTS. COM+ will provide a new interface with individual get/set methods for each bit - SetComplete, EnableCommit, SetAbort, DisableCommit.Security
The security features of COM+ are much like those in MTS, but they also leverage the new security infrastructure of NT 5. Access controls can be placed on the application (package), component, and (this is new) method level. You have the ability to map NT user accounts and groups to Roles. This allows you to build a logical security model on top of the grungier model often found in the real world. The core of NT security is provided by Active Directory. Kerberos (with transitive trust) is the primary security service used by AD, but PKI and NTLM are also supported. AD implements the PKI extensions to Kerberos that allow users to authenticate themselves with X.509 certificates and then obtain the standard Kerberos TGT and session keys.Load Balancing
The COM+ load balancing architecture allows you to define a router on a server that forwards object creations to a machine that has low utilization. Once the object is created, method calls go to the same object even when it is stateless. Of course, there are Wizards for everything and a single Application Explorer window for management.
More to come soon...
.gif){kind=small}
