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+.

NOTE

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 

NOTE

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

Method	Description
Activate()	Can be used to perform startup operations. It is called when an object is created or allocated from a pool.
CanBePooled()	Indicates whether the object should be pooled. It is called when an object is to be moved to the pool.
Construct()	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.
Deactivate()	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.
DisposeObject()	Finalizes the resources used by the serviced component and removes the associated COM+ reference.

NOTE

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.

NOTE

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

Attribute	Scope	Description
ApplicationAccessControl	Assembly	Allows you to configure the security of an application hosting the serviced component.
ApplicationActivation	Assembly	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 ).
ApplicationID	Assembly	Specifies the GUID of the COM+ application.
ApplicationName	Assembly	Specifies the name of the COM+ application.
ApplicationQueuing	Assembly	Enables queuing support for the COM+ application.
AutoComplete	Method	Indicates whether the method should automatically notify the COM+ context about its success or failure when it completes.
ComponentAccessControl	Class	Enables security checking when the serviced component is accessed.
COMTIIntrinsics	Class	Allows passing of the context properties from the COM transaction integrator (COMTI) to the COM+ context.
ConstructionEnabled	Class	Allows the component to pass a construction string to enable object construction.
Description	Assembly, Class, Method, Interface	Specifies the description of the assembly, class, method, or interface.
EventClass	Class	Indicates that a class can participate in loosely coupled events.
EventTrackingEnabled	Class	Enables event tracking on the component.
ExceptionClass	Class	Specifies the queuing exception class.
IISIntrinsics	Class	Allows you to use ASP intrinsic objects such as Request and Response.
InterfaceQueuing	Class, Interface	Enables queuing support on the specified interface or class.
JustInTimeActivation	Class	Indicates whether the serviced component supports just-in-time activation.
LoadBalancingSupported	Class	Indicates whether the serviced component supports load balancing.
MustRunInClientContext	Class	Indicates whether the serviced component must be created in the creator's context.
ObjectPooling	Class	Indicates whether the serviced component will be created in an object pool and configures the size of the pool.
PrivateComponent	Class	Specifies that a serviced component should not be visible and should not be activated outside its containing COM+ application.
SecureMethod	Assembly, Class, Method	Indicates that the methods of the serviced component should be called through an interface so that the security is applied.
SecurityRole	Assembly, Class, Interface	Indicates the security role that will have access to the serviced component.
Synchronization	Class	Specifies the synchronization support offered to the serviced component. It controls how multiple threads can execute the methods of the serviced component simultaneously .
Transaction	Class	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

Parameter	Server Application	Library Application
Performance	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.
Fault-tolerance	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.
Security	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.

EXAM TIP

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.

Context

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

Member	Type	Description
DeactivateOnReturn	Property	Indicates whether the object should be deactivated when the object's method returns.
DisableCommit()	Method	Tells the COM+ context to vote for aborting the current transaction. This method does not deactivate the object when the object's method returns.
EnableCommit()	Method	Tells the COM+ context to vote for committing the current transaction. This method does not deactivate the object when the object's method returns.
IsCallerInRole()	Method	Determines whether the caller is in a specified role.
IsInTransaction	Property	Indicates whether the current COM+ context is transactional.
IsSecurityEnabled	Property	Indicates whether the current COM+ context has role-based security enabled.
MyTransactionVote	Property	Specifies the COM+ context transaction voteabort or commit.
Transaction	Property	Represents the current COM+ transaction object.
SetAbort()	Method	Indicates the COM+ context to vote for aborting the current transaction. This method also deactivates the object when the object's method returns.
SetComplete()	Method	Indicates the COM+ context to vote for committing the current transaction. This method also deactivates the object when the object's method returns.

Interception

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.

REVIEW BREAK

• 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.

---

Top