Architecture of Component Services


In this section, you'll learn about the basic components of the COM+ architecture. You'll learn how a COM+ application is organized, how COM+ provides the component services, and how the .NET Framework interacts with COM+.


Non-Default Constructors COM can only instantiate a .NET class with its public default constructor via the CoCreateInstance() method. COM can't create an object and pass parameters for object creation at the same time. If you want to create a .NET object in different ways from a COM client, you need to use the factory pattern (that is, create a separate .NET object with a default constructor and having different methods to create objects in different ways. Refer to Chapter 3, ".NET Remoting," for an example of using the factory pattern).

Serviced Components

One of the most important classes in the System.EnterpriseServices namespace is the ServicedComponent class. Any class that uses enterprise services must derive from the System.EnterpriseServices.ServicedComponent class. Such a class is also called a serviced component . Classes that derive from ServicedComponent must be public and concrete and must provide a public default constructor. A basic serviced component declaration is shown here:

 Imports System.EnterpriseServices Namespace Exam70310     Public Class MySampleSC         Inherits ServicedComponent         Public Sub New()             ...         End Sub     ...     End Class End Namespace 


Configured Components You can apply declarative attributes on the serviced components that are configurable at runtime. For this reason, serviced components are sometimes called configured components.

The ServicedComponent class has methods but no properties or events. I have listed some important methods of this class in Table 7.2. All these methods are protected except the DisposeObject() method, which is a public static method. You can override the protected methods in a class inherited from the ServicedComponent class.

Table 7.2. Important Methods of the ServicedComponent Class




Can be used to perform startup operations. It is called when an object is created or allocated from a pool.


Indicates whether the object should be pooled. It is called when an object is to be moved to the pool.


Provides access to the construction string of the serviced component. It is called after the serviced component object is created; that is after the constructor is executed.


Can be used to perform cleanup operations. It is called when an object is about to be deactivated; that is destroyed or moved to a pool.


Finalizes the resources used by the serviced component and removes the associated COM+ reference.


Component Versus Class You'll often find the term component and class used interchangeably in this chapter. They refer to the same thing, but there is a slight distinction. A class is a unit of development, whereas a component is a unit of deployment. A component can provide features such as versioning and security, which are not of interest to a class.

Declarative Programming Model

Unlike the conventional procedural model, the programming model for enterprise services is declarative in large part. In the procedural model, you write code to accomplish a task, whereas in the declarative model you use declarative tags that instruct the underlying platform to accomplish a task. In the case of a serviced component, the declarative tags specify the services that the component receives such as transactions, just-in-time activation, object pooling, and so on.

In Visual Basic .NET, the declarative tags are specified using attributes. You can place attributes on certain program elements such as assemblies, classes, and methods to specify runtime information. At runtime, these attribute values can be manipulated through a mechanism called reflection. After the application is deployed, administrators can use tools such as the Component Services tool to manipulate the attribute values and change the behavior of the application without any need to recompile the application.

For example, consider an application that needs to support transactions. In the procedural model, a programmer has to write code to commit or abort a transaction. As opposed to this, in the declarative programming model, a programmer can just mark the code with attributes that tell the runtime environment that the code must support a transaction. A simple serviced component that supports a transaction can be defined as follows :

 <Transaction(TransactionOption.Required)> _ Public Class MySampleSC     Inherits ServicedComponent    ... End Class 

When the preceding code executes, all the necessary details to enable transactions and to perform commit and rollback operations is done behind the scenes by the runtime environment.

What are the advantages of declarative programming over procedural programming? There are many. The three most important advantages are

  • Reduced Development Cost Development cost is reduced because there is now less code to write and maintain.

  • Increased Reliability Application reliability is increased because it is very likely that the underlying platform has gone through more testing than an average piece of application code.

  • Increased Flexibility Declarative code using .NET attributes can be read and modified at runtime without any need to recompile the application. Therefore, it is easy to write programs that allow administrators to reconfigure the way an application behaves after it has been deployed.


Attribute Naming Formally, attributes are represented by classes whose names end in the word "Attribute." So, for example, the ApplicationActivation attribute is implemented by the ApplicationActivationAttribute class. In coding, you are allowed to leave off the "Attribute" suffix, and I recommend that you do so to increase your code's readability.

As you progress through this chapter, you'll use several attributes that specify the runtime requirements for serviced components. I have listed these attributes and their description in Table 7.3.

Table 7.3. Attributes of the System.EnterpriseServices Namespace






Allows you to configure the security of an application hosting the serviced component.



Specifies whether the serviced components are activated in the creator's process ( ActivationOption.Library , the default value) or in the system's process ( ActivationOption.Server ).



Specifies the GUID of the COM+ application.



Specifies the name of the COM+ application.



Enables queuing support for the COM+ application.



Indicates whether the method should automatically notify the COM+ context about its success or failure when it completes.



Enables security checking when the serviced component is accessed.



Allows passing of the context properties from the COM transaction integrator (COMTI) to the COM+ context.



Allows the component to pass a construction string to enable object construction.


Assembly, Class, Method, Interface

Specifies the description of the assembly, class, method, or interface.



Indicates that a class can participate in loosely coupled events.



Enables event tracking on the component.



Specifies the queuing exception class.



Allows you to use ASP intrinsic objects such as Request and Response.


Class, Interface

Enables queuing support on the specified interface or class.



Indicates whether the serviced component supports just-in-time activation.



Indicates whether the serviced component supports load balancing.



Indicates whether the serviced component must be created in the creator's context.



Indicates whether the serviced component will be created in an object pool and configures the size of the pool.



Specifies that a serviced component should not be visible and should not be activated outside its containing COM+ application.


Assembly, Class, Method

Indicates that the methods of the serviced component should be called through an interface so that the security is applied.


Assembly, Class, Interface

Indicates the security role that will have access to the serviced component.



Specifies the synchronization support offered to the serviced component. It controls how multiple threads can execute the methods of the serviced component simultaneously .



Specifies the transaction support required by the serviced component.

COM+ Applications

A COM+ application is a group of serviced components that perform related functions. Each of these components further consists of interfaces and methods. A COM+ application is the primary unit of administration and deployment for a serviced component.

A COM+ application is always stored in a DLL file. A DLL file cannot run on its own. Therefore, a COM+ application is always configured to run in one of the following two ways:

  • Server Application In a server application, a COM+ application runs in its own process. To enable this, COM+ provides a surrogate process ( dllhost.exe ) that hosts the DLL file for the COM+ application.

  • Library Application In a library application, the COM+ application runs in the process of the client that creates it. To enable this, the components in a library application are always loaded into the process of the creator.

Now that you have two types of applications, you'll have to choose between them. Table 7.4 helps you make this decision based on various parameters.

Table 7.4. Choosing Between Server and Library Applications


Server Application

Library Application


Low, because communication between the objects involves marshalling across processes or computers.

High, because the objects are locally available to the client programs and no marshalling is required.


High, because any unhandled exception in the application only affects the dllhost.exe process that is hosting the application.

For this reason, a server application is especially useful when you have any components that use unmanaged or unsafe code.

Low, because any unhandled exception in the application affects the client program that hosts the serviced component.


High. Server applications can also be more tightly secured because you can explicitly configure the process-wide security settings.

Low, because the components rely on security settings of the client process that hosts the serviced component.

Support for component services

High, because all COM+ component services are supported when a COM+ application runs as a server application.

Low, because serviceslike object pooling and queued componentsare not supported.


Server Application Versus Library Application You should know the merits and demerits of configuring a COM+ application to run as a server application or as a library application. Use the information in Table 7.4 to make the decision.

COM+ Catalog

The COM+ catalog stores information about COM+ applications. Each COM+ application and serviced component is uniquely identified in the COM+ catalog using a globally unique identifier (GUID).

The other important information stored in the COM+ catalog for a serviced component is its runtime requirements. For example, if a component requires a transaction, this information is stored in the COM+ catalog. Later when the component is activated, COM+ services use the catalog to determine the runtime requirements of components.

The COM+ catalog itself is physically split between the following locations:

  • COM+ Registration Database ( RegDB ), which is stored in the Registration directory of the Windows installation (such as c:\windows\registration ).

  • Windows Registry within a key named HKEY_CLASSES_ROOT .

However, you can access and update the catalog in an integrated way by using the Component Services administrative tool. This tool is available in the Administrative Tools section of the Windows Control Panel. This tool allows administrators to make changes to the installed COM+ application via a user interface, as shown in Figure 7.3. Any changes made through the Component Services administrative tool are stored in the COM+ catalog. You can also read or update the catalog through programs as shown in the section "Registering the Serviced Component into the COM+ Catalog."

Figure 7.3. The Component Services administrative tool allows you to manage and configure COM+ applications.

Serviced Component Activation

At this point, you should have a reasonably clear idea about how a serviced component is configured for development and deployment. What remains to be seen is how the .NET Framework and COM+ work together to activate a serviced component and enforce the configured semantics at runtime.

Activation of a serviced component can be summarized in the following steps:

  1. When a client program creates a new instance of a serviced component, .NET enterprise services use the COM-based CoCreateInstance() API to request COM+ component services to instantiate the serviced component. .NET enterprise services pass the GUID of the serviced component to the CoCreateInstance() API.

  2. COM+ component services use the GUID to retrieve the runtime information of the serviced component from the COM+ catalog. The COM+ component services then check to see if the client program is running in the same context (that is, an environment that is compatible with the runtime requirements of the serviced component).

  3. If the runtime requirements of the serviced component matches with that of the client program, the new object is created in the same context as the client program, as shown in Figure 7.4. A reference to the newly created object is returned to the client program so that the client program can make direct calls on the newly created object.

    Figure 7.4. Components with similar runtime requirements might exist in similar context.

  4. If the runtime requirements of the serviced component are not compatible with that of the client program, COM+ component services create a new context that matches the runtime requirements of the client and create the serviced component object in that environment, as shown in Figure 7.5. The COM+ component services then create a proxy and returns the proxy to the client program.

    Figure 7.5. Components with different runtime requirements exist in different contexts and communicate through a proxy.

  5. The client program uses the proxy to communicate with the serviced component object. The proxy uses a mechanism known as interception that enables the proxy to do some pre-processing and post-processing for each object and method invocation to ensure that the correct runtime policies are applied when a method call proceeds from one context to another.

The concepts of context and interception are the keys to understanding the preceding activation process.


A context is a set of properties that define a runtime environment for the serviced component. A context is created during the activation process for a serviced component that is configured to require certain automatic services.

Because different serviced components objects can be configured with different attributes and have different requirements at runtime, COM+ component services use contexts to group together the like-minded objects while separating incompatible objects. Objects having the same runtime requirements share a context, whereas those having incompatible runtime requirements must reside in different contexts, as shown in Figure 7.5.

An object can access its context-specific properties using the ContextUtil class of the System.EnterpriseService namespace. The ContextUtil class provides static methods and properties as listed in Table 7.5. I'll use some of these members in this chapter to interact with the context of an object.

Table 7.5. Important Members of the ContextUtil Class






Indicates whether the object should be deactivated when the object's method returns.



Tells the COM+ context to vote for aborting the current transaction. This method does not deactivate the object when the object's method returns.



Tells the COM+ context to vote for committing the current transaction. This method does not deactivate the object when the object's method returns.



Determines whether the caller is in a specified role.



Indicates whether the current COM+ context is transactional.



Indicates whether the current COM+ context has role-based security enabled.



Specifies the COM+ context transaction voteabort or commit.



Represents the current COM+ transaction object.



Indicates the COM+ context to vote for aborting the current transaction. This method also deactivates the object when the object's method returns.



Indicates the COM+ context to vote for committing the current transaction. This method also deactivates the object when the object's method returns.


Interception is a mechanism that enables COM+ to capture calls to any object and execute its own code before passing the call to the object. For example, a component in the COM+ catalog might specify that only the users authenticated with the supervisors security role are allowed to call a method named ApproveOrder() . In this case, COM+ intercepts the call to the ApproveOrder() method and forwards or rejects the call to the component based on the identity of the user.

When two objects are in the same context, no interception is required because the objects have the same runtime requirements. However, when the objects are resident in different contexts, it is important to ensure that appropriate runtime requirements for individual contexts are satisfied. Therefore, the objects in a different context use a proxy to communicate instead of directly making calls to each other. The proxy uses interception to ensure that the runtime requirements are met. Interception is available at two levels:

  • Object-level This level of interception enables the proxy to perform pre-processing and post-processing operations when a object is created and destroyed. This level of interception is helpful in providing object-level services such as object construction and object pooling.

  • Method-level This level of interception enables the proxy to perform pre-processing and post-processing operations when a method is invoked on an object. This level of interception is useful in providing method-level services such as just-in-time activation and transactions.


  • Classes that want to use COM+ component services must derive from the System.EnterpriseServices.ServicedComponent class.

  • To use COM+ services in your program, you need not write a lot of code. Instead, you use declarative attributes to specify whether a class should receive particular services.

  • The declarative attributes applied to a class are stored in the COM+ catalog as part of the assembly registration process. At runtime, COM+ reads the COM+ catalog to determine what services a component should receive and provides those services.

  • COM+ uses interception to provide various runtime services. Interception is a mechanism that enables COM+ to capture calls to any object and execute its own code before passing the call to the object.

  • COM+ creates different contexts for objects that have different runtime requirements. A proxy is used to provide interception services between the objects in different contexts.


MCAD. MCSD Training Guide (Exam 70-310. Developing XML Web Services and Server Components with Visual Basic. NET and the. NET Framework)
MCAD/MCSD Training Guide (70-310): Developing XML Web Services and Server Components with Visual Basic(R) .NET and the .NET Framework
ISBN: 0789728206
EAN: 2147483647
Year: 2002
Pages: 166 © 2008-2017.
If you may any questions please contact us: