Windows Server 2003 and Enterprise Services

  • Article

 

Ron Jacobs
Enterprise Services

Updated January 2003

Applies To:
   Microsoft Windows Server 2003
   Microsoft Windows Enterprise Services

Summary: This article discusses the improvements to COM+ on Microsoft Windows Server 2003 and how .NET developers using Microsoft Windows Enterprise Services can take advantage of these enhancements to build highly scalable and reliable web applications. (9 printed pages)

Contents

Introduction
Scalability Enhancements
Availability Enhancements
Manageability Enhancements
Programming Model Enhancements
Summary

Introduction

Microsoft® Windows® Enterprise Services provides .NET developers with a powerful set of services for developing robust and scalable server applications. When used from the Microsoft .NET Framework, COM+ services are referred to as Enterprise Services.

Microsoft Windows 2000 includes COM+ version 1.0 with services such as transactions, role-based security, queued components, and loosely coupled events. Microsoft Windows XP and Microsoft Windows Server 2003 includes Enterprise Services (COM+ version 1.5) with many new services to increase the overall scalability, availability, and manageability of your server applications.

These new enhancements with Enterprise Services fall into these categories:

  • Scalability Enhancements
  • Availability Enhancements
  • Manageability Enhancements
  • Programming Model Enhancements

Scalability Enhancements

Scalable systems can expand to meet future needs. COM+ Services have proven to be the most highly scalable transaction processing middleware in the world today with 6 of the top 10 TPC benchmarks (as of April 2002, see www.tpc.org/ for up to date benchmarks). Now with Windows Server 2003 and Enterprise Services based on COM+, you can build applications with even greater scalability.

The scalability enhancements include:

  • Configurable Isolation Levels
  • Application Pooling

Configurable Isolation Levels

One important Enterprise Services feature deals with transactions. Application developers can simply ask for a transaction without worrying about how many resource managers will be involved, or how the components involved in the transaction interact. Transactions ensure the integrity of the applications data by locking particular data records for a certain amount of time.

How much locking you do and for how long is based on the isolation level. A higher isolation level means more locking, and consequently, a lower potential for incorrect data. Additionally, higher isolation levels also mean less concurrency and lower performance. A lower isolation level means less locking and more concurrency. Lower isolation levels also present a higher potential for incorrect data. Choosing a lower isolation level can result in improved performance but you must be aware of the types of concurrency problems you can encounter based on your choice of isolation level.

When running on Windows 2000, COM+ services defaults to the highest isolation level (SERIALIZABLE) that guarantees all work is completely isolated during a transaction. However, this isolation level comes at a price of reduced concurrency and throughput. On Windows 2000 you can change the isolation level after the transaction begins with the SQL command SET TRANSACTION ISOLATION LEVEL. SET TRANSACTION ISOLATION LEVEL changes the effective isolation level for the remainder of the transaction. Alternatively, locking hints can set the level for a single query.

For more information on locking hints, see Locking Hints.

Enterprise Services, when running on Windows Server 2003, allows you to specify the isolation level you want to use with your transaction by specifying the Isolation property when you declare the transaction attribute. Specifying the Isolation property when you declare the transaction attribute gives you the option of choosing the isolation level that works best for your application. Additionally, the transaction attribute documents the developer's intended isolation level. For example:

[Transaction(Isolation=TransactionIsolationLevel.ReadCommitted)]
public class Account
{
   //...
}

Application Pooling

Enterprise Services server applications, running on Windows 2000, always run in a single process. There are certain types of legacy COM objects that are thread unaware and therefore must always run in the main thread of this process. The resulting effect is that the application does not scale very well because all requests must be queued to execute on the main thread. When running this type of application on Windows Server 2003, you can specify that a pool of processes will be used. This approach increases throughput in the same way that a thread pool can increase throughput in a single process. Additionally, having a pool of processes helps protect against process failures since each client request will be dispatched to the next process in the list.

Availability Enhancements

Highly available systems are critical in the world we live in and Enterprise Services offers enhancements designed to keep servers running trouble free 24 hours a day, 7 days a week. These enhancements include:

  • Application Recycling
  • Applications as NT Services
  • Low-Memory Activation Gates
  • Web Services

Application Recycling

The performance of most applications degrades over time. This can be a result of memory leaks, reliance on third-party code, and non-scalable resource usage. Enterprise Services running on Windows Server 2003 provides process recycling as a simple solution to gracefully shut down a process and restart it. Process recycling significantly increases the overall stability of your applications, offering a quick fix for known problems and a safeguard against unexpected ones.

You can configure process recycling administratively through the component services UI, or programmatically through the COM+ administrative SDK. You can shut down and recycle processes based on several criteria, including elapsed time, memory usage, the number of calls, and the number of activations.

For more information, see Application Recycling.

Applications as NT Services

Developers using Enterprise Services and Windows Server 2003 now have the ability to configure an Enterprise Services server application as a Microsoft Windows NT service. Previously, only base COM applications could run as a Windows NT service.

This feature gives you more control over when your Enterprise Services application starts. Marking it to run as a Windows NT service means that the application can be loaded into memory when the system boots. This is especially useful if you want to make your Enterprise Services application highly available by installing it on a clustered server. For improved security, you can also run your service under special built-in accounts designed for services such as NetworkService or LocalService. These accounts include the minimum privileges required to run as a service and do not require you to change passwords when they expire.

For more information, see Service User Accounts.

Low-Memory Activation Gates

System administrators know it can be difficult to configure a server so that its resources are adequate for peak loads. When a server does not have enough physical resources to make peak demand, the server can exhaust virtual memory.

Exhausting virtual memory becomes a problem if the user code or system code does not properly handle memory allocation failures. The server begins to slow down, and as memory is exhausted, memory allocations fail. The server then executes error paths to handle the allocation failures. Finally, if an error path contains a bug in the system or user code running on the server, it is extremely difficult to trap and handle safely.

Enterprise Services, running on Windows Server 2003, prevents situations in which these error paths might be run on a server. Rather than wait for memory allocations to fail in a piece of code, Windows Server 2003 checks memory before it creates a new process or object. If the percentage of virtual memory available to the application falls below a fixed threshold, the activation fails before the object is created. By failing these activations that would normally run, the low-memory activation gates feature greatly enhances system reliability.

Web Services

Web services increases availability by making your service available to all kinds of clients. Enterprise Services uses .NET remoting to bring Web services to the world of COM by making it possible for any COM object to be accessed as a Web service, or to call a Web service as though it were any other COM object. You can also use .NET remoting as a simple way to make your .NET class library accessible to Web-service clients by simply selecting a box, or adding an assembly attribute to your application. When registered, this approach will cause your Enterprise Services application to create a Web site on Microsoft Internet Information Server (IIS), and to connect the Web site to your components automatically.

The following example shows how to use the ApplicationActivation attribute with the SoapVRoot attribute to automatically publish your components as a Web service.

using System;
using System.EnterpriseServices;
[assembly: ApplicationActivation(ActivationOption.Server, SoapVRoot="AccountWebService")]

For more information, see COM+ Web Services: The Check Box Route to XML Web Services and Microsoft .NET and Windows XP COM+ Integration with SOAP.

Manageability Enhancements

Windows Server 2003 makes managing Enterprise Services applications easier than ever before, and includes the following features:

  • Pause or Disable Applications
  • Process Dump
  • Application Partitions

Pause or Disable Applications

When running on Windows 2000, it is not possible to prevent server applications from being activated. If you stop the application and a request to activate a component from that application is received, the application will immediately start again. Administrators need to be able to pause or disable applications so they can make changes to the application configuration, or assemblies and component dlls, without removing the server from the network.

When running Enterprise Services on Windows Server 2003, you can pause any running process. While the process is paused, it will not accept requests for further activations. If requests are received, a new process will start. This enables administrators to troubleshoot applications by attaching a debugger or doing a process dump while the process is paused. Other clients will have their work routed to a new process so they can continue with their work.

You can also disable an application or component so that activations will not be processed. If an application or component is disabled it will remain disabled until you enable it even if you reboot the server. This allows administrators to disable an application in order to deploy a new version of the assemblies, or to make other changes to the application configuration.

Process Dump

It is not easy to troubleshoot applications in a production environment. How do you gather information on a problem without disturbing the running processes? Enterprise Services running on Windows Server 2003 provides a solution through its new process dump feature. This feature allows the system administrator to dump the entire state of a process without terminating it.

For example, the application service provider (ASP) hosting your application finds a problem, but cannot provide much more information other than the fact that something is not working. With the process dump feature, the ASP can take a non-invasive snapshot of the running processes. The details are saved in a log file, which the ASP can send to you or Microsoft Product Support Services, making it much easier to troubleshoot the Enterprise Services application. Using advanced debuggers like WinDBG, you can quickly identify which thread is causing the problem and then diagnose the problem.

Application Partitions

On Windows 2000, COM+ allows you to configure an implementation of a component only one time on a computer. When using Enterprise Services with Windows Server 2003, you can use a feature called application partitions that allows multiple versions of COM and .NET components to be installed and configured on the same machine. This feature can save you the cost and time-consuming effort of using multiple servers to manage different versions of an application.

To see the benefits, consider a hosted application. For example, you have 1000 different customers accessing your application through an ASP. All 1000 customers require different back-end database and different security settings. To do this with Windows 2000, you would have to install 1000 versions of the application on 1000 physically separate servers.

With the application partitions feature in Enterprise Services, you can create 1000 partitions, one for each version of the application, on a single computer. Each partition acts, in effect, as a virtual server. After installing the application into each partition, you create partition sets that map users to the logical servers. This mapping determines the application version that your customer will access. Users can only access components from partitions in their partition sets. The benefit of partitions is clear. It is much easier and more cost-effective to manage one large server, or even a few larger servers, rather than many small servers.

For more information, see Creating and Configuring COM+ Partitions.

Programming Model Enhancements

From its inception, Microsoft Transaction Server (MTS), followed by COM+, introduced a new style of component-based development for server applications. Enterprise Services continues this trend, and when you use Enterprise Services on Windows Server 2003, the following features are available to assist you in building server applications:

  • Component Aliasing
  • Public and Private components
  • Process Initialization
  • Services Without Components

Component Aliasing

With COM+ on Windows 2000, you could only configure a particular implementation of a component one time on a computer. The component's CLSID referred to a combination of the component's code and its configuration requirements. Windows Server 2003 provides component aliasing, which allows you to configure one physical implementation of a component many different times.

To illustrate the benefits of component aliasing, consider the example of a component that only takes calls to store procedures in a database. You tested and debugged this component, and now want to use it in 10 different applications. Each of those 10 applications connects to a different back-end database. You can use object construction strings to pass in the DSN information for each database. The problem is that you can only register and configure the component once, so you can only specify one object constructor string.

Previously, you would have cut and pasted the code to create 10 different components, one for each application. This would mean 10 times the amount of code to test, debug, and maintain. Component aliasing enables you to configure the same physical implementation of the component 10 different ways. You get component re-use at a binary level, rather than at the source-code level. This means less code, lower development costs, and faster time to market.

Public and Private Components

With COM+ on Windows 2000, all components in your application are public. A public component can be activated from other applications. However, you might have several helper components within an application which are meant to be called only from other components within that application. Windows Server 2003 enables you to mark these components as private. A private component can only be seen and activated by other components in the same application.

The public and private components feature provides the developer with more control over what functionality to expose. You need only document and maintain the public components. You also have the option of creating private components that cannot be accessed from outside the application, but may still take advantage of all the features of Enterprise Services.

Process Initialization

Many server applications need to do specific initialization and cleanup when they are started and shut down. When running on Windows 2000 (prior to SP3) there is no way to execute code when the hosting process starts and, while you could take care of the initialization on the first activation, dealing with cleanup is even more difficult because cleanup has to be done when the last component is released.

When running on Windows Server 2003 (and Windows 2000 SP3), you can create a class that implements the IProcessInitializer interface. When the process starts up it will call IProcessInitializer.Startup, and when shutting down it will call IProcessInitializer.Shutdown. This gives your component the opportunity to take any necessary action such as initializing connections, files, caches, and so on.

For example, a component that wants to open a log file could implement IProcessInitializer, open the log file at process start, and close it at process shutdown:

   public class ServerLog : ServicedComponent, IProcessInitializer
   {
      // ...
      public void Startup(object punkProcessControl)
      {
         OpenLogFile();
         // Record startup in the log file
         Write("Server application started");
      }

      public void Shutdown()
      {
         // Record shutdown in the log file
         Write("Server application shut down");
         CloseLog();
      }
   }

Services Without Components

On Windows 2000, if you want to take advantage of COM+, you have to package your managed code into a class derived from ServicedComponent that is registered with component services. This forces developers who want services such as transactions to factor their class designs into transactional and non-transactional classes.

Windows Server 2003 allows you to programmatically enter and leave a Service Domain by making a pair of API calls. When your code executes within the service domain, it behaves as though it is in a serviced component. Services such as transactions will be applied to your component automatically. This scenario makes it possible to build a component that uses transactions for some methods, and does not have to inherit from ServicedComponent.

Summary

The .NET platform is a great way to write new applications with rich tools and languages making developers more productive than ever. Enterprise Services helps to make these applications enterprise ready with a number of features including:

  • Configurable Isolation Level
  • Application Pooling and Recycling
  • Services Without Components

You can use the .NET Framework on Windows 2000 and create a great application. Building and deploying your application on Windows Server 2003 will give you more options for the design and architecture of your system and your application will run faster and more reliably than ever before.