COM+ and .NET - A practical approach - Part 1

Abstract

This article is actually made up from three main parts. The first part handles all the aspect of using COM+. After reading this part you will know what the options that you have to host your assembly in COM+, impact on ASP.NET application performance of any option and what are, if any, limitations impose by selecting certain COM+ hosting option.

The second part describes all the administrative benefits that your application can gain from COM+. This part includes details about improving availability and stability using COM+ and who to monitor and use monitor data to detect quickly and easily problems sources.

The third part describes daily programming tasks that can be archive easily by using COM+ features. COM+ include many features that can reduce the number of code lines and time that you might invest in order to fulfill common programming tasks. This part outlines those programming tasks and explains demonstrates how to use COM+ to achieve them.

Introduction

COM+ is living but not much kicking on our WEB servers since windows 2000. COM+ even deserves to be upgrade to version 1.5 in XP and Windows 2003 operation system. COM+ was useful for DNA programs but seems to loose it’s glorious in the .Net age. Most of programmers use COM+ to manage transactions over database but COM+ offers many others options that can be use to create much more scalable and available application and to simplified programming tasks. This article will take practicable path to COM+ (1.0 and 1.5) by explaining and demonstrating when and how you can use COM+ with .Net.

Defining the Problem

COM+ name is one of its biggest disadvantages. Interpolation of the COM words combination misleads many programmers to think that COM+ is base on COM and to prevent using an old technology from the new brand .NET WEB application. While for some cases COM+ is really based on COM using its abilities can have huge contribute to WEB application and server. .Net creators thought about the consequences of using COM to access COM+ application and create the CLR in such a way that access to .Net component that register in the COM+ might be without any usage of COM. This architecture let us use COM+ services such as Queued Components, Loosely coupled events, Pooling, JITA (Just In Time Activation), SWC (Services Without Component) and others to simplify programming tasks.

In this article I will show how we can register .Net components in COM+ and what effect this registration got on performance, and limitations. After understanding what are the consequences of using COM+ we will see how COM+ contribute application and web server availability and stability. Continue with the practical approach we will see how COM+ features can simplify daily task that we face while creating WEB applications.

This article addresses COM+ 1.0 and 1.5. Wherever COM+ is mention I refer feature exist both in COM+ 1.0 and 1.5. Where COM+ 1.5 explicitly use the refer feature exists only in COM+ 1.5 version (windows XP or .Net servers).

Article Structure

• Com+ application types and how they effect your application performance
• Performance
• Accessing and limitations
• Make your application scalable as possible
• Maximum isolation
• Component Monitoring and quick problem solving
• Application Recycling
• Scale your objects
• Process dump
• Enable different version of COM+ application simultaneously running
• Looking for bright future o
• Applying security
• Increase server output and application income.
• Monitoring and squeezing licenses usage.
• Notify others when your application change state
• Picking COM+ fruit without need to nourish COM+ tree.
• Notify ASP.NET from COM+ server application.
• Transactions, just for the record.

(a) Com+ application types and how they effect your application performance

There are two ways that COM+ can host .Net components: Library application and Server application. Library application run the component in the caller process while Server application run component in dedicate process that COM+ create, called Dllhost.exe. COM+ application type influences every aspect of the hosted component. Server application run in separate process affecting the overall performance of application that needs to cross the process boundary to call component services. Cross process communication is the major factor in the differences regarding performance and limitations between Library and Server applications.

COM+ is based on context. Context is environment for objects with the same execution requirements. Context can intercept method call or object activation and execute one of the COM+ services as a result. In order to register .Net class in COM+ the class must inherit from ServicedComponent. ServicedComponent implementation is based on Remoting that easily can be used to intercept method calling. When CLR required to instance new derived ServicedComponent object a call to managed C++ is made. The managed C++ call CoCreateInstance that allow COM+ to bind the object to unmanaged context and supply unmanaged services that predefined to the register class in the COM+ catalog. CLR is also capable of taking advantage the attributes programmer relate to a class, in order to set class metadata in COM+, if not previously set. During the registration the InProcServer32 key that usually points to the COM DLL or COM EXE path points to mscoree.dll which is the .NET JIT engine (ironically mscoree.dll is COM DLL). Since the call back to CLR the actual object created is real managed object.

The describe process happened when COM+ library object requires and in the end of the road a pure managed class create by CLR. Objects registered as server application got another instantiation path. The cross process nature of server application requires Remoting as long as DCOM to call the registered object from managed code. Actually there are two Remoting calls during object activation one for getting the server object URI and one for the actual activation. COM interop calls are made during activation and data un-marshaling. In both cases (library, server) the object is managed object created by CLR just the server object need Remoting and DCOM to activate the object and for every call to un-marshal parameters. We will see the impact of those differences in the performance section.

(i) Performance

After understanding the steps related to activation of library and server application lets see how every one of this options influence our web application performance. As I state earlier this article is about practical approach so while we check for COM+ applications performance we will check other COM+ services that might influence web application performance in certain situations. Those services include JIT, object pooling, and synchronization support. I’m not intending to go deep into the details of those services, you can find full coverage of them at http://www.ondotnet.com/pub/a/dotnet/excerpt/com_dotnet_ch10/index.html?page=1. or on MSDN documentations.

The performance test is based on regular ASP.NET application build in the conservative layer architecture. The ASP.NET application construct from 6 pages :

1. GetDataNoCom.aspx : page that Get about 20 records from Database and display them..
2. GetDaataCom.apsx : page that call class registered in COM+ to retrieve about 20 records from Database and display them.
3. GetLargeDataNoCom.aspx : page that Get about 1000 records from Database and display part of them
4. GetLargeDataCom.aspx : page that call class registered in COM+ to retrieve about 1000 records from Database and display part of them.
5. LongInit.aspx : page that call resource with long initialization time.
6. LongInitCom : page that call class register in COM+ . The com+ class use resource with long initialization time.

Every one of the COM+ objects will be test while running as Library and Server with JIT, object Pooling and methods call time. The test made on machine with single Intel 4 1,80GHz CPU and 500 MB of RAM. Result numbers are RPS (Request per second) returned by ACT (Application Center Test). Each test runs for 5 Seconds with 10 simultaneous users.

Table 1.0 test results
	No COM+	Library				Server
		Pooling	JITA	Call Time	PRS	Pooling	JITA	Call Time	RPS
GetDataNoCom – 90 records	300	X	X	X	X	X	X	X	X
GetDaataCom – 90 records	X	-	-	-	233	-	-	-	111
	X	+	+	-	200	+	+	-	105
	X	+	+	+	200	+	+	+	105
GetLargeDataNoCom - 900 records	50	X	X	X	X	X	X	X	X
GetLargeDataCom – 900 records	X	-	-	-	49	-	-	-	36
	X	+	+	-	48	+	+	-	28
	X	+	+	+	48	+	+	+	28
LongInit	1	X	X	X	X	X	X	X	X
LongInitCom	X	-	-	-	1	-	-	-	1
	X	+	+	-	0.3	+	+	-	100
	X	+	+	+	0.3	+	+	+	100

As you can see in Table 1.0 there is difference in performance between non COM+ pages and pages that use COM+ Library. The performance differences are minimizing as the page perform more time consuming tasks. On the contrary we can see that pages using COM+ server application is 2 time slower then pages using COM+ library applications. One exception is handling a task that requires long initialization time you can see that using pooling can improve performance dramatically. We will address this issue in details later. You can also see that using Call time data to enable us to monitor application components don’t have any impact on page output. Later on we will see how we can use that data to inspect application problems in run time.

Using ACT can help you in the development process. Checking your page for RPS as you develop can help you find problems and bottlenecks as you or other programmer making them. Solving problems founds early in the development process are usually more easy then solving them when the development processes done. I strongly recommend to use ACT as much as possible to get good grasp of application status at every development phase.

(ii) Accessing and limitations

Beside the performance aspect we need to consider limitation that we need to be aware of if we choose to use COM+ applications. Limitation actually related just to COM+ server application mainly due to it’s out of process nature. Server library class can’t access the ASP.NET intrinsic object. Actually it can be done if the page multi threaded state change to single thread by using ASPCOMPAT attribute but using this attribute will harm application performance.

Hosting .Net assembly in DLLHOST.exe which is a process running in system directory result in limitation due to the fact that ASP.NET application and the called COM+ server assembly running in different location enforce the programmer to host assemblies that holds common data (interfaces, enumerations, etc) in the GAC. Putting common data assemblies in the GAC prevent deployment of those assemblies to several physical locations.

Using Remoting to call COM+ server application from ASP.NET application imposes several other limitations. If ASP.NET calls COM+ class and ask for data every thing working smooth since CLR handle the Remoting for the register COM+ class. But if COM+ class needs to create callback to the calling ASP.NET application or to return reference type (like DataReader) some action must be taken in order to make the page class Remoting server. Later on I’ll show how to achieve this behavior.

Another limitation derived from Remoting is the requirement to pass parameters that support serialization. Remoting serialize object to move them across the Remoting channel. Passing object that don’t support serialization as parameter will cause runtime error.

Due to DCOM and Remoting usage of every call to class register as COM+ server application its better to use chunky over chatty calls. Create few calls with parameters rather then using properties for classes that will be called from ASP.NET applications. To be clarify chunky over chatty is right just for "entry point" classes. Other classes that used as part of the request process should use the classic OO approach.

(b) Make your application available as possible

One of the strategic targets that .Net is just a tactic to achieve is the Enterprise software market. Microsoft wants to penetrate that market that was dominated for years by Oracle and SUN (Java and java application server suppliers). The enterprise market demands are different from those of E-commerce market. Usually enterprise software use to handle large different databases with set of intranet applications that stand from the end enterprise user as one big software. Those applications (usually tens) use to be host by the same server which is part of load balancing cluster. Building set of application by different development teams, with high volume of connectivity between them, that eventually will be treating as one application and host on the same server demands different set of requirements from building single client server application or E-commerce one. Microsoft starts to release more and more software tools and development tools that help enterprises to build their software. One of those tools is COM+ and one of the COM+ donation is strong support to availability and scalability.

Hosting many applications on the same server have many advantages for the enterprise. This configuration supply best performance due to the connectivity between applications and save money (Imagine the cost of buying and maintaining server for each application). But there is one big disadvantage. If the hour report system run into problem and consume 100% CPU all other applications that run under the same IIS will also harm. Such a situation can damage the availability of application and even data and must be prevent or at least monitor and stop.

One of the obvious conclusions from performance and limitation is that it’s better not to use COM+ server application. Even though that conclusion is based on solid evidences COM+ server application can solve the availability issue easily but with performance tax. In most cases the performance tax is irrelevant for enterprise software that need to serve in the extreme case tens thousands of users split between three servers or more.

(i) Maximum isolation

Registration of class as COM+ server application ends up with dedicated process named dllhost.exe that will run the class objects, when they will be created. This paradigm isolates those class objects from the address space of the calling application and let us terminates the class objects without terminating the calling web application.

As a matter of fact IIS5 and IIS6 supply other isolation mechanism. IIS 5.0 catch request for .Net application and by using pipe transfer the request to dedicated process for handling ASP.NET applications - aspnet_wp.exe. There is just one aspnet_wp process in the server and every web application got its own application domain inside aspnet_wp. ASP.NET takes advantage of that architecture and restart application by restarting web application’s application domain. While ASP.NET can restart application in given situations administrators can’t. What you can do as administrator is to use ASP.NET mechanism of restarting web application when any change is made to the application bin directory. That workaround will work just if your application not processing incoming request. In that case application restart will be happened just after the request is done. If one of the request processing steps enters never ending loop, the web application won’t restart.

This IIS5 behavior together with in process activation mode of assemblies used by the web application can end up with unavailability of more then one application even if just one application misbehaves. To overcome this situation administrator need to restart aspnet_wp process that as result restarts all applications running on the server. The only way to prevent this situation is to use layer separation and to host non GUI layers as COM+ applications so the administrator can use COM+ MMC to restart the dedicate process without harm the aspnet_wp process.

IIS6 introduce Application Polls that can host one or more web application. Applications pools has their own w3_wp process that can be recycled by administrator thus enable to terminate one web application without harm others. This IIS6 option let administrators terminate one application but it still missing the monitoring abilities build in COM+ that enable administrators to find quickly the misbehave assembly.

Now let’s see isolation in practice. We will build simple web application (AvailabilityCheck) with assembly containing one class register in COM+. That class contains two methods DoItRight and NeverEndingStory which contain never ending loop. The web form contain two buttons each one calls class method.

Figure 1.0

//Class code
namespace AvailabilityCheckDll
{
   public class AC : System.EnterpriseServices.ServicedComponent 
   {
      public AC()
      {
      }
      public string DoItRight()
      {
         return DateTime.Now.ToString (); 
      }
      public string NeverEndingStory()
      {
         // simulate unfinish recursive
         for(;;)
         {
      
         }
         return DateTime.Now.ToString (); 
      }
   }
}
// Page Code
public class WebForm1 : System.Web.UI.Page
{
   protected System.Web.UI.WebControls.Button btnDoItRight;
   protected System.Web.UI.WebControls.Button btnNeverEndingStory;
   private void Page_Load(object sender, System.EventArgs e)
   {
   }
   +#region Web Form Designer generated code
   private void btnDoItRight_Click(object sender, System.EventArgs e)
   {
      AvailabilityCheckDll.AC oAc = new AvailabilityCheckDll.AC();
      Response.Write ( oAc.DoItRight ());
   }
   private void btnNeverEndingStory_Click(object sender, System.EventArgs e)
   {
      AvailabilityCheckDll.AC oAc = new AvailabilityCheckDll.AC();
      Response.Write ( oAc.NeverEndingStory());
   }
}

Running the web application cause AC class to register as Library application. Clicking on DoItRight button return page with printed date and time. Clicking on NeverEndingStory cause the CPU to reach 100%. The only way to finish 100% CPU utilization is by restarting the aspnet_wp (IIS5) or recycling Application Pool (IIS6). Now change the AC metadata, on COM+ MMC, to run as server application and press NeverEndingStory button. After you notice that the CPU consumption reached 100% simply shutdown the COM+ application. Note that the CPU usage return to be normal and you get error page indicating some problem in your application. This scenario shows the strength of using COM+ server application. You saw how easily is to stop malicious code, without harming other web applications.

Another option to gain isolation is to use Remoting and host assemblies on dedicated Windows service. Administrator can shutdown the dedicated service without harm other application. There are two disadvantages to this approach. Shutdown the service influences all assemblies that hosted in that service and there are no statistics to take advantage of.

As you see register class as COM+ Server application result in more available applications and in conjunction with monitoring can reduce dramatically application unavailability period. Just don’t forget that registration class as COM+ application will harm your application performance. As I state, before decide if to register your assembly as Server application its better to check with ACT (Application Center Test) for RPS (Request per Second) and just then to make your decision.

(ii) Component Monitoring and quick problem solving

COM+ Server application supply set of data and statistic that can be used to fast allocate of malicious code. If all the assemblies that the web application uses are load into the application domain memory address the only way to know where error happened (if you get error message at all) is by bubbling exceptions and writing them to log file. Even if the programmer follows that practice the server administrator is likely won’t understand those logs. Registration of classes as COM+ server might help administrators in several ways:

• Process information. Every class that registers as server application got its own dedicates process. COM+ MMC let you know what the process ID of every application is. You can use this data to look for high CPU usage processes at the Task Manager. Comparing PID (PID column can be added from View->Select Columns menu) from task manager with status view of com+ applications can help you determine quickly which COM+ application responsible for high CPU utilization.
• Component information. First of all to use this data

  EventTrackingEnabled

  attribute must be set in the class declaration. Setting this attributes yield in statistic for every application component that can be seen in the status view of the components folder. The most important data is CallTime. This parameter shows how much time in milliseconds object is performing its task. Using this data administrator can find bottleneck components or components that cause the application to misbehave (components with huge call time). Furthermore if every component present one of the application layer administrators can easily find if the application problem roots are deep in database or logic layers.

As you see the application and components data exported by COM+ can be used by Administrator to minimize the time for problem tracking and therefore maximize the total availability time of application. As isolation, component and application data can be gather just if the application set as server (for components call time collect just if application set as server. Other statistic data collect for library and application but there aren’t useful as call time).

You can use the previous code sample to see how the describe data goes into practice and help you to find the problematic process and class. Set the COM+ application to run as server and run the web application. Press NeverEndingStory button. When CPU usage reaches 100% open task manager and switch to processes tab. Order the data by CPU usage. On the top of the list you should se DllHost.exe. Recall the DllHost.exe PID and open COM+ MMC status view of COM+ applications folder. Look for application with the same PID, you will found that AvailabilityCheckDll match the same PID. Till now you know which application causes the problem what left is to find the responsible class. Open the application components status view. This application contains only one class but you can easily see that one component call time is keep growing. This component is responsible for the high CPU usage.

(iii) Application Recycling (COM+ 1.5)

Version 1.5 of COM+ takes the availability and stability of COM+ application one step farther. COM+ application can cause expected and unexpected problems such as memory leaks or usage of unscaleable resource. COM+ let administrator set in which circumstances your application will be recycle automatically. COM+ let you set recycling by process lifetime, memory consumption, number of method calls and object activations.

(iv) Scale your objects (COM+ 1.5)

COM+ 1.5 introduce new feature that enable to scale legacy single threaded applications (such as components build by VB 6.0). That feature allow administrator to set the number of DllHost process that can be start for the given application and serve incoming requests. When application pool size is greater then one, COM+ start to rout requests between DllHost processes in round robin manner. You can see all the process including their PID in the running processes folder of COM+ MMC. Besides improving scalability Application pooling can be very useful for availability and recovery. If for some reason error happened in one DllHost new request can rout and use other DllHost from the pool.

(v) Process dump (COM+ 1.5)

Full process memory dump is very useful for monitoring, analyzing and debugging purpose. Dumps are crucial to find and fix problems that cause application exceptions. COM+ 1.5 address this issue by adding a tab that let the administrator to set automatically generation of process memory dump when exception occurred. COM+ MMC let you set the location of the dump file and the number of dump files that will be kept before recycling them on the disk. Beside auto generation of dump file you can dump application memory whenever you want by using the dump menu on application context menu of applications in running processes folder. After creating the dump file you can use WinDbg to open the dump file and analyze the data.

(vi) Enable different version of COM+ application simultaneously running (COM+ 1.5 on .NET server)

This feature can be found only on .Net servers. You have to enable com+ partitions by enabling partition option in Options tag of your computer in COM+ MMC. Partitions enabled administrator to create number of partitions that every partition hosts Server or Library application with different setting of metadata. This option enables hosting of several COM+ application versions with different COM+ catalog data on the same machine. When COM+ application Component activation required COM+ decide to activate object in partition by the user that activate the component and users that attach to given partition. You can also take advantage of this feature to separate data between different groups of developers or users by setting different connect string as COM+ constructor string

(vii) Looking for bright future

I hope that until this part you got the impression how much COM+ Server Application can help you to create much more scalable and available systems and on the contrary how COM+ Server Application harm performance mainly due to the DCOM involve in the activation and marshaling process. I hope that Microsoft get the picture and newer versions of COM+ will be .Net based and turn DCOM obsolete. Until then you need to make your own decision for performance or stability and availability. Theoretically switching from Server to Library application is just a meter of changing the activation type but practically there are Server imitations (that I mention previous) and slight code changes (that you can see in the test application) between the two activation types. My advice is to take in account the limitations and code changes when you create class that should be host as COM+ component. Doing so leave administrator and project manager to decide how your assembly will be run eventually.

Next Part

• Click here for Part 2