Dot NET Enterprise Services

Technology Excellence

General Industry Practice

Healthcare IT Solutions

.NET Enterprise Services and COM+1.5

This article discusses about Microsoft .NET Enterprise Services and its use of COM middle tier services. It introduces new COM 1.5 features as well as design guidelines to take full advantage of these new capabilities in .NET applications.

Please fill up the form below and we will submit a proposal for your project. Alternatively, you can send email to contact@optionm.net with the project requirements.

Contents

	Overview
	NET Enterprise Services and COM+
	Process Initialization
	Application Recycling
	Web Services

Overview

COM+ 1.5 can be viewed as the chrome on COM+ 1.0. While COM+ 1.0 brought with it internal improvements like contexts, a new thread-pool architecture, and object pooling, COM+ 1.5 carries more visible and functional features for use in a distributed application. If used correctly, these improvements can result in increased performance, better reliability, increased scalability, and simpler manageability of your application. Some of these now standard features were previously implemented under COM+ 1.0 only by tricky code or administration techniques. For instance, a component can be designated as "private" to your application to prevent it from being created by callers outside that process. Previously this was smartly done by enabling security for a component but not assigning roles to it. Another example is component aliasing, allowing you to have the same binary image in multiple applications on the same machine. Before COM+ 1.5, it took source-level magic with additional ProgIDs and CLSIDs to make this possible.
Enter COM+ 1.0. Our single-system folks have transitioned from the client-server mindset to obtaining resources late and releasing them early with MTS. Through experience they now understand the importance of resource pooling and of not tying up server resources, making short running (transactional) method calls, and of using one object per client. Microsoft, too, has learned a lot from its customers and understands more of what they need to be successful. With COM+ 1.0, we provided our customers the ability to drive to the end of the driveway, as they were ready for
COM+ 1.5 gives you all the features of COM+ 1.0 along with numerous enhancements to improve the management, availability, and scalability of your application. To get the maximum miles per gallon and safe driving for your application, your responsibility is to understand and implement these technologies in a correct fashion. This document helps you do just that, and to uphold that responsibility to your customers by creating a better, faster, and more reliable application. Let's take a look at these exciting new features
A majority of these concepts are truly innovative and allow you to take new liberties within your application architecture-like being able to create pools of applications, exposing your COM+ application as a Web service or as a Microsoft® Windows® NT service, and even using COM+ services without your application being configured in COM+. While COM+ is powerful and feature-rich, it's critical to understand the correct application of these features, as it can make or break your application with just the check of a box. This article gives you the knowledge to make the correct decisions in your application design.

Click here to submit your project requirements to Option Matrix, India.

NET Enterprise Services and COM+

When Microsoft® Transaction Server (MTS) was initially released. Unlike its predecessor MTS, COM+ ships with the operating system-the 1.0 version with Windows 2000, and the 1.5 version with Windows XP and Windows Server 2003. (Throughout this article I will use the term "Windows XP/Windows Server 2003" to uniformly discuss the COM+ 1.5 platform.) For those who did not previously use MTS as part of their architecture, this bundling has occasionally led to confusion:
With the release of the Microsoft® .NET Framework and its auto-everything, attribute-based programming model, this confusion has been further fueled. Developers and architects are asking questions similar to those asked when Microsoft® ActiveX® suddenly appeared a few years back and clashed with OLE and COM. There is an initial common misunderstanding among the relationship between COM+ and Microsoft .NET: How does .NET fit into COM+? Does it replace COM+? Do I even need COM+ anymore?
All the features and services that COM+ provides are available in the .NET Framework. The .NET Framework does not replace COM+, for it is dependent upon COM+ for all its middle-tier component services. The .NET Framework provides an environment for managed code to make use of COM+-as well as other enterprise service technologies like Microsoft® Internet Information Services (IIS) and Microsoft® Message Queue server (MSMQ)-more easily than could be done in the past.
To add to the confusion, the .NET Framework provides a managed class into COM+ called Enterprise Services (ES) within the System.EnterpriseServices namespace. This class offers ways to programmatically make use of these services in a more simplified fashion than in the past. Which version of COM+ it maps to is completely dependent upon whether the .NET Framework is running on Windows 2000 or Windows XP/Windows Server 2003. Figure 1 below shows the relationship of the technologies.

Figure 1. .NET Framework uses COM+/IIS/MSMQ for its middle tier services.

Attributes within managed code map directly to settings in the COM+ catalog and correspondingly in the Component Services Explorer (CSE). Attributes are used to properly configure a component in COM+ once it's installed. Attribute-based programming is encouraged, as it takes the burden of proper configuration off the administrator. Attributes are compiled into an assembly's meta-data, allowing a component to carry around its behavior wherever its assembly is deployed. This results in a consistent configuration across multiple servers.
Override some of these attribute values administratively through the CSE and the COM+ catalog. However, there are four attributes that always read from the metadata when a component is loaded and will supersede any settings in the CSE. These are JIT (Just-In-Time) activation, object pooling (although it uses the pool size attribute set in the CSE), AutoDone ("Automatically deactivate this object when this method returns"), and using security at the method level. Use caution when overriding any attribute at the application or component level. The developer of the component defines a particular set of attributes to ensure his component will have the correct context and services available when instantiated so that it functions correctly.
The functionality of COM+ 1.5 is not solely limited to a managed .NET application. Unmanaged Microsoft® Visual Studio® 6.0 code can use both versions of COM+, depending upon the platform it runs on. The bad news is that since developers are not using the .NET Framework classes with Visual Studio 6.0, most likely will have to do more manual programming to take advantage of the new COM+ 1.5 features, .Just as important, developer will not be able to use attributes within code that map to COM+ catalog and CSE configuration settings. The good news is that most of the COM+1.5 features are made available to components through CSE configuration settings and not programmatically.

Click here to submit your project requirements to Option Matrix, India.

Process Initialization

A common need among those designing COM+ components is more control over resource management during the initialization and shutdown of its hosting process. Specifically, this relates to process-wide resources that the first instance of a class in that process creates, all subsequent instances use, and the last instance releases.
Language-specific lifetime management features (such as a C++, C#, or Microsoft® Visual Basic® .NET constructor/destructor or Visual Basic Class_Initialize/Class_Terminate methods) simply don't cover all scenarios. These mechanisms typically fall short at the component level, but more so at the process level, for a configured object. Primarily this is due to the fact that during these initialization functions of a configured object instance, the MTS/COM+ context associated with that object has not yet been created. When these initialization functions are invoked, the code cannot access any MTS/COM+ services through the object context. Note that Class_Initialize now has access to an object context as of Windows 2000.. To counter the need to access the object context during initialization, MTS introduced the optional IObjectControl interface with its Activate and DeActivate methods, which have access to context. Activate is invoked each time an instance is activated, while Deactivate is invoked correspondingly when a component is deactivated. If used for allocation and cleanup of that instance's resources only, they typically serve the purpose.
Unfortunately, IObjectControl does not offer direct, process-wide resource management support. In an attempt to get around this limitation, creative programmers have despondently discovered that using IObjectControl for management of process-wide resources in the enterprise space is not straightforward or reliable. This limited means of supervising the lifetime of process-wide resources typically leads to resource leaks, unexpected process termination due to thrown exceptions, or a hung system. What is needed is a standard way to manage process-level resource management operations.
COM+ 1.5 introduces the IProcessInitializer interface for enhanced lifetime management of process-wide resources that do not have direct ties to COM+, such as network connections, shared memory, and so on. This is an optional interface that should be implemented only by those components within server-activated applications that want to participate in process-wide resource management. This interface will not be called for library-activated applications.

IProcessInitializer::Startup. Takes one parameter and is invoked when a component is starting up. (In Windows XP and Windows Server 2003, this parameter can be used to extend the default 90-second window. Under Windows 2000 Sp2+ it is always NULL). It is important not to take too much time initializing resources, as the operating system will kill a DLLHOST process if its initialization is not finished within the default ninety (90) seconds. When this is called, no COM+ components have yet been instantiated and there are no contexts from COM+ with which to work. Hence initialization through IProcessInitializer should be limited to resources that don't necessitate a COM+ context.

IProcessInitializer::Shutdown. Takes no parameters and is called when a component is shutting down. In the case of COM+ failfast, or abnormal program termination, the Shutdown method will not be invoked.

When the very first instantiation request comes in for any component in a server-activated application, the COM+ infrastructure creates the DLLHOST process and loads the DLL file that houses the requested object. At the same time, the COM+ runtime queries the COM+ catalog for all configured components in that application that implement the InitializesServiceProcess attribute. (When a component that implements IProcessInitializer is registered, this property is set automatically.) Every component in that application that has this attribute set will be instantiated, its constructors called, and its IProcessInitializer::Startup method called. Once Startup completes, the normal COM+ activation process continues with IObjectConstruct::Construct and IObjectControl::Activate being called respectively, if implemented. Each object's IProcessInitializer interface pointer is saved for when the process is shutting down (discussed shortly). COM+ creates the instance and is the only client to call methods on that object. It thus manages its lifetime so the object will always be around when the process goes to properly shut down.
When the process is being shut down, COM+ accesses the IProcessInitializer pointer it obtained when the process was starting up. Using this pointer, the IProcessInitializer::Shutdown method is invoked for the last instance of any class that implements IProcessInitializer.
When a component with IProcessInitializer is started or terminated, its exported DllMain function is never called for PROCESS_ATTACH or PROCESS_DETACH events. If you had previous code that did initialization or cleanup here, you should move it to the Shutdown and Startup methods. "If resource allocation is done in multiple components, all loaded at the same time, isn't it a formula for problems?" Absolutely. can't pre-determine the order in which each component's IProcessInitializer::Startup methods will be invoked. It is permissible to have more than one component in a server application that implements IProcessInitializer.

Unfortunately, this increases the logic required within its methods to coordinate management of shared process-wide resources with other components in that same application that also implement this interface. Therefore, creating one component per application whose sole purpose in life is to allocate/initialize and de-allocate a specific resource is the best way to go with IProcessInitializer. If multiple orthogonal resources are used, you probably will want one component implementing IProcessInitializer for each resource.
This feature is available on Windows 2000 under COM+ 1.0 with COM+ hotfix rollup 14 or higher. If running Windows 2000 and COM+ 1.0, simply implementing IProcessInitializer and registering the component will not enable the initialization feature for a component. A COM+ rollup does not automatically register the COMSVCS.DLL, and thus IProcessInitializer interface is not a recognized interface on that particular system. You will have to manually register COMSVCS.DLL through REGSVR32.EXE in order for the IProcessInitializer interface to be known. for more information on how to accomplish this. This registration issue is fixed on Windows 2000 SP3.

Click here to submit your project requirements to Option Matrix, India.

Application Recycling

Just like our old, creaky human bodies, the performance of most applications will degrade for various reasons over time. Memory leaks, poor coding practices, bugs, and improper resource management can cause a process to perform poorly, hang, or even crash as time progresses. A common site maintenance action is to regularly recycle (stop and restart) the Web server or a DLLHOST process as a quick fix for known issues and to prevent unknown ones from occurring.
From within the CSE, you can manually recycle an application process on-demand, or use triggers to automate this process. These standard, non-extensible triggers from the UI include time, memory, calls, and activations as shown in Figure 2.

Figure 2. Recycling options

Lifetime Limit. Maximum minutes the process can live. This will trigger if none of the other triggers fire beforehand.

Memory Limit. If virtual memory exceeds this amount for greater than 1 minute, the trigger fires.

Expiration Timeout. Grace period once any trigger fires before shutdown occurs.

Call Limit. Maximum number of method calls received before trigger fires.

Activation Limit. Maximum number of activations before trigger fires.

Once a trigger event is raised, the Expiration Timeout grace period commences. This is the number of minutes COM+ will wait for clients to complete existing work before recycling occurs. When either the expiration timeout expires or the last client reference is released the process will be recycled. COM+ will always recycle the process when this time period expires, regardless of whether any outstanding references still exist. This covers the situation where a client has stopped using an object reference but has never (properly) released it. A lack of this fall-through timeout would prevent proper application recycling if releasing all outstanding references was the only criteria used.
To avoid complications with existing references during this recycling process, COM+ transparently creates a duplicate of the DLLHOST process associated with an application to service all future object activation requests. The original DLLHOST exists to finish servicing any outstanding reference requirements on the older instances. Once all of the external references to instances in that old process space are released, or the grace timeout period expires, the original DLLHOST is shut down. Through this behavior, application recycling ensures that a client application does not experience a service interruption.
Immediately after a recycling trigger criteria is met, yet before the process is actually shut down, the IComApp2Events::OnAppRecycle2 event is fired. It is raised by the COM+ runtime through the system events publisher (CLSID_ComServiceEvents). Using the standard COM+ event mechanism, you can implement the IComApp2Events interface to subscribe to this and various other system events relating to process termination and loading. In the event-handler routine, a monitoring or logging application can use the data passed in to log or make dynamic lifetime management decisions. For instance, a subscriber client or a monitoring application can release any existing object references it holds in the process about to be shut down. It immediately can then create a new reference to that same class of object in a valid process by calling the appropriate object instantiation API (CoCreateInstance, CreateObject, New, and so on). This prevents the client from calling a proxy that no longer points to a valid instance after the process is recycled.
When using application recycling in conjunction with application pooling, proper lifetime management of synchronization objects and shared resources is paramount. Suppose component instance X (XA) in process A is holding a Win32 mutex synchronization object to a resource (or a file handle) that another instance of X (XB) is waiting on in process B. If process A is recycled and XA does not release that object properly, the instance of XB in process B is hung if waiting in an infinite timeout. However, if XA subscribes to ::OnAppRecycle2, it can ensure that its cleanup code releases any shared resources it holds when shutting down to minimize the chance of this happening.
Recycling occurrences will be spread over a period of time when combining application recycling and application pooling to minimize the effect on clients. Suppose we have X pooled application processes, and the Lifetime Limit is set to ET minutes. The lifetimes of each pooled application process will be (Z* (ET/X) + ET), where Z is the zero-based order of creation. Assuming no other triggers are fired, if we have four processes and ET is 60 minutes, their respective lifetimes would be X0=60 minutes, X1=75 minutes, X2=90 minutes, and X3=105 minutes. COM+ 1.5 will space out the recycling process so that if a process is shut down for any reason, another process will not be shut down until at least ET/# processes minutes have expired. Once this time has passed, the normal shutdown period will be used again.

Here are some issues to be aware of when using application recycling:

An application configured to run as a service cannot be recycled. This makes perfect sense, as services typically run throughout the lifetime of a system boot.

If used in conjunction with application pooling, application recycling will occur on a per-process basis. Only the particular process whose recycling trigger has been activated will be recycled. This preserves availability by always having an application to service new clients while one is being recycled.

Applications that activate as "Library" will inherit the application recycling properties of their server-activated activator application. Just like other characteristics of library packages, such as identity, this is a natural expectation as it shares the process of its activator.

Application pooling can sometimes yield unexpected results for library-activated components, as the Call Limit is the total of all calls into all components in that process. Suppose server-activated component S instantiates library-activated component L, and the application for component S has its call limit set to 1000. If component L gets 999 calls, and S gets only 1 call, the process will recycle. Even if almost all of the calls go to component L, the Call Limit setting will be triggered for that process. L may or may not be written to handle recycling and this could cause problems.

Even if you have selected the Leave running when idle check box in the Activation tab, application recycling will ignore this setting and shut down once the recycling trigger is met.

Once application recycling is configured and an application is started, recycling cannot be disabled for any running instances of the application. Additionally, an application cannot refuse to be recycled once a recycle event has been triggered.

You cannot prevent an administrator from recycling the application manually or changing the criteria to do so in the CSE. As with any configuration settings, locking down access to the CSE through setting proper permissions on the roles for the system application can assist in making this more secure.

Disabling or Pausing an Application

There are times when an application may need to be temporarily inaccessible to its users. For instance, a database server may need to be updated or rebooted and data components should not make calls to it during that time. Another CPU or additional memory may be added to the application server, which could affect configuration properties in the COM+ catalog. A new version of a DLL or an updated runtime file that a configured component uses may need to be installed. Perhaps an open logging file related to a specific configured application needs to be closed and archived. Or a constructor string used to connect with a database server at activation time needs to be changed, due to a sudden relocation of the database server. Maybe a bank does not want its application run during off-hours so it can disable it nightly and resume it in the morning. In any case, when a problem is occurring, you may want to debug that process. The motivations to pause or disable an application are numerous. But while closely related, these two options serve two different functions. For simplicity's sake, let's discuss each separately.

Application Pause

Pausing an application comes in handy when trying to attach a debugger to a process, or to halt it to examine the application's state. To best analyze the process, it is sometimes best to stabilize the process by preventing any new activation requests, or method calls, into that process. Pausing holds the process state relatively stable, potentially allowing you to more easily isolate the error. You can dump it (through AutoDump+, Userdump, Dr. Watson, or the CSE), analyze PerfMon counters, or attach a process-level debugger during that paused state.
If pooling an application, you can independently pause one or more of its DLLHOST processes independently of each other. Pausing is process-specific and is paused from the Running Processes folder context menu. A paused process counts towards the maximum processes allowed based upon the application pooling configuration entry. New requests continue flowing into other non-paused processes in the pool to service existing clients, while the paused process is left alone to be analyzed and debugged. This isolation can be very useful when users say that the problem happens only on the production machine, as it allows both debugging and the application's execution itself to occur in parallel.
If the maximum processes in a pooled application are all paused, and an activation request comes in, that request will fail. Clients that hold existing references to objects in a paused process will not be processed and will return the hResult E_APP_PAUSED.
A paused process will no longer be in a paused state following a server reboot. If a paused process is marked for recycling (one of its recycling criteria has been triggered), it will not be shut down until its active lifetime is resumed again from the context menu.

Application Disable

Disabling an application is particularly useful when installing new software to avoid application errors or service interruption during the update process. By disabling an application instead of doing a shutdown during an update, new users cannot instantiate any of its components nor run them until the complete installation process finishes and the application is manually enabled again. Without this option, the administrator has to manually shut down the application but still cannot prevent the process from being restarted on the next activation request (like COM+ failfast does). Disabling is also very handy when, for whatever compelling reason, you want to prevent any further component activations for that application or a particular component.
Disabling is handled through the context menu both at the application level and the individual component level. It is not done through the Running Processes folder as is pausing. When done at the application level, it affects both non-running and running processes. If an application using application pooling is disabled, all its existing processes are disabled. Of course, if an application using application pooling is not running and is disabled, no future instances of its processes will be created until it is enabled again.
If disabling is done at the component level, any existing, non-paused processes with outstanding references to instances of the just-disabled component will continue to service requests for that class of object. This differs from pausing where an existing client cannot make calls into that process with an outstanding reference. However, no new instantiations of the component will occur. New activation requests will not be sent to a specific paused process, or to a disabled application or component. A library-activated application cannot be paused-only a server-activated application can. Both server and library applications, as well as individual components, can be disabled.
Once disabled, this status persists across reboots of the server in the COM+ catalog. This is useful if we do not want clients to start using an object right after a reboot, for instance, were we to need to make some configuration change for it to work correctly after reboot.

Click here to submit your project requirements to Option Matrix, India.

Web Services

One of the primary goals of the .NET Framework is exposing pre-packaged functionality to consumers as a Web service. For example, medical companies could expose diagnostic feedback services to companies whose applications solely gather and assemble the data but don't contain the complex and specialized code to produce the diagnosis. Surprisingly, Web services technology is not one developed by Microsoft. Rather, it is implemented using industry-wide standards of HTTP, XML, and SOAP. This translates into non-Windows (non-DCOM) clients accessing Web services on Microsoft platforms.
Under COM+ 1.0, non-Windows clients had no way to access the functionality of COM components. Even those on remote Windows machines had to open a specified port range to allow DCOM through a firewall, which meant additional configuration changes. Another drawback of DCOM is that by opening a range, you can cause conflicts with other applications. This may also relax your firewall security policy by opening up a lot of ports. (Alternatively, you can explicitly map an application to a specific DCOM port. But don't dismiss DCOM just yet. It has many positive features that are not available in any other protocol and is still the most powerful way to accomplish RPC to COM components. It is still the preferred way to access configured components from Windows clients. This leads to confusion among developers about the use of Microsoft® .NET Remoting, ServicedComponent classes, COM+ Web services, .NET Web services, and DCOM.
We'll discuss each of these and how they compare to DCOM so you can make your decision. .NET Remoting is evolving to provide new features, just as DCOM did its early days. As yet it lacks security when self-hosting, but keep in mind that if hosting the remoting session in IIS, you can take advantage of IIS inherent authentication, authorization, roles, and so on.
Suppose you can't use DCOM for whatever reason. What other options are there? For unmanaged code, you could use the SOAP toolkit and port 80. A better option may be to use COM+ (1.5) Web services. When compared to DCOM, it gives up a bit of performance, but gets a huge increase in functionality and flexibility-the main purpose behind SOAP anyway. COM+ Web services is primarily focused on cross platform and non-Windows operating systems on the client accessing configured COM+ components. But even on Windows clients, COM+ 1.5 Web services can be used as an alternative remote calls mechanism to DCOM/RPC. It adds a Microsoft-specific layer to ease the migration from COM to .NET for Web service providers and consumers. This layer allows RPC, text-based remote calls to a COM+ component through .NET Remoting and the SOAP protocol.

Some reasons to use Web services:
1. Provides cross-platform capability.
2. Takes advantage of Web service infrastructure.
3. Loose-coupling creates a service oriented architecture that is more conducive to enterprise development.
On the server side, COM+ 1.5 Web services simplifies configuration and access of remote endpoints. It trivially exposes a component's methods as an XML Web service, without having to change a byte of source code. From the client side, it offers better integration for accessing Web services. Depending upon the activation mechanism, code to invoke methods upon a target Web service component on another machine can look just as if the target lived within the consumer's own assembly.

.NET Remoting and COM+ Web Services

Figure 3. Flow and processing of a SOAP message

While closely related, .NET Remoting and COM+ Web services serve different functions. COM+ Web services uses .NET Remoting, which is specifically optimized for configurations with .NET running on both the client and server. In a type of environment where you can ensure that both the client and server are running managed consumer and target code, it provides a rich, persistent, and stateful connection similar to DCOM. Even with managed code on both the client and the server, you can use COM+ Web services to communicate cross-machine over SOAP. .NET Remoting can also be used less optimally (through the SOAP formatter) in environments where the .NET Framework is not on the client. .NET Remoting does not use DCOM and is a less-restrictive alternative for remote method calls between managed clients and servers. .NET Remoting and SOAP combine to allow a more flexible option than DCOM, which would be the only other option if managed or unmanaged COM+ components were called remotely.
Even if you have the .NET Framework on the client and server, remote calls to ServicedComponent components (and unmanaged components) will occur over DCOM by default. To override DCOM, a client configuration file must be loaded from the client machine to allow activation through .NET Remoting. This client file makes client COM+ catalog changes that tell COM+ Web services this is a .NET Remoting SOAP-based activation. If the catalog says to use DCOM, the remoting configuration file will be ignored. Conversely, if the catalog says to use .NET Remoting over SOAP and the configuration file is missing, the activation will fail. This is done transparently for unmanaged components using COM+ Web services. (Again, realize that DCOM is the only protocol that will allow a transaction or security to flow from an activator component to the component it uses on another machine).
A message formatter encodes and decodes calls as they are sent across the channel. .NET Remoting uses either the SOAP or binary message formatter. COM+ Web services uses .NET Remoting through the SOAP formatter. This is slower and less efficient than the binary formatter, but in exchange you get the flexibility needed for unmanaged (and managed) clients or servers. The binary formatter uses a more efficient binary protocol but is not used by COM+ Web services. If the need arose, you could use other formatters with your COM+ or ServicedComponent-managed class. Developers have to write the logic to do this, or just change the generated configuration file in the vroot.

Click here to submit your project requirements to Option Matrix, India.

Option Matrix Featured Case Studies

Option Matrix Whitepapers

External Links

Portal for Multi-location Hospital

The client was a healthcare provider (multi-location hospital) for the local resident patients having sleeping disorders. Option Matrix's scope of consulting was for their Seattle,