Guidelines: COM+ Application Deployment

These guidelines describe configuration and deployment options for Microsoft Component Services (COM+) and Microsoft Internet Information Services® (IIS)-based applications. This set of guidelines can be used to develop strategies for configuring and deploying COM+ and IIS-based applications during the Construction phase and Transition phase of a project. These guidelines are mostly applicable to the initial deployment of applications from project testing or pre-production environments, to the actual production environment at the start of the Transition phase.

First, the structure of a COM+ application is described to provide a frame of reference for subsequent configuration and deployment options. Then a variety of COM+ application configuration and deployment options and utilities are discussed. Next, IIS configuration and deployment options are outlined. Finally, several deployment scenarios are discussed along with techniques and tool usage.

These guidelines do not include any references to Microsoft’s Application Center® 2000 product, because the product is in beta at the time these guidelines were created. Application Center 2000 will provide enhanced configuration and deployment capabilities for applications developed using the Microsoft Windows DNA® platform.

Component Architecture Overview

In the Microsoft Windows® 2000 operating system, COM+ provides a set of application services that encompass the transaction, process control, resource allocation and JIT activation services of Microsoft Transaction Server® (MTS). It also encompasses the component runtime and invocation services of the Component Object Model (COM). Both MTS and COM were available on earlier Microsoft Windows® operating systems. COM+ builds upon these technologies and includes new services that provide improved threading and security, transaction management, object pooling, queued components, application administration and packaging. The following list summarizes some of the COM/COM+ framework characteristics that impact distribution and deployment:

The primary architectural model that these guidelines will address is a multi-tier COM+ application that is registered within the Component Services framework. The term COM+ application, as used in these guidelines, refers to one or more COM components that have been configured as a unit that uses one or more of the Component Services, provided by the Windows 2000 operating system. These guidelines will not address deployment scenarios for single-tier COM-based applications.

COM+ Applications

The Component Services snap-in, which is part of the base Windows 2000 operating system installation, is the primary tool for configuring and managing COM+ applications. A COM+ application consists of the following pieces: server applications, library applications and application proxies. A server application is a COM+ application that runs in its own process, dllhost.exe, which is the Microsoft-system provided surrogate to host COM+ Dynamic Link Libraries (DLLs). A library application is a COM+ application that runs in the process of the client that creates it. The “client”, in this case, can be either a base COM+ applications, or it can be a COM+ server application. The figure below depicts this architecture. Application proxies are a set of files containing registration information that allows a client to remotely access a COM+ server application.

The following sections describe the physical deployment and registration requirements for each of the COM+ application types, server applications (formerly MTS server packages), library applications (formerly MTS library packages), and application proxies.

Server Applications

Server applications are comprised of one or more components, which consist of one or more DLLs. These DLLs are hosted by the surrogate that is provided with the Microsoft Windows operating system-- dllhost.exe. Server applications are registered in the COM+ catalog, which is described below.

Library Applications

Like server applications, library applications are also comprised of one or more components, which consist of one or more DLLs. However, these DLLs are hosted in a base COM+ client executable. The base COM+ client executable can either be a ‘standard’ Win32 application, an IIS/Active Server Pages (ASP)-based automation host, or a COM+ server application. Library applications are registered the same way server applications are registered, however, library applications cannot be remotely accessed and they cannot use the new COM+ message queuing service. The impact of these restrictions is that ‘no information’ related to remote access or queuing is stored in the COM+ Catalog for COM+ library applications.

Application Proxies

An application proxy consists of one or more files that contain registration information that allows a COM+ client application to remotely access a COM+ server application. Typically, all of the registration information and runtime type information necessary to access a remote COM+ server application will be packaged in a single DLL. The registration information includes information such as: class identifiers (CLSIDs) of the classes contained in the component for which the proxy is being installed, and program identifiers (ProgIDs), which are automation-friendly versions of the CLSIDs, and the Remote Server Name (RSN) of the server on which the COM+ server application is running. This information will be stored in the Windows Registry of the client computer. In addition, type library information can be optionally packaged with the DLL, to provide a binary description of the interfaces exposed by a component and to define the methods along with their parameters and return types.

COM+ Catalog

The COM+ catalog is a generic term for the set of information that is maintained in the COM+ Registration Database (RegDB) and the Windows Registry. Access to the information maintained in the COM+ catalog is gained by using the COM+ Administration Library, which exposes a scriptable automation interface.

The type of information that is stored in the COM+ catalog includes the following:

COM+ Registration Database

The COM+ registration database is a transactional information store that houses information about COM+ applications. Legacy COM components that use COM+ services have these new services attributes stored in the COM+ Registration Database. New COM components are registered completely in the COM+ Registration Database, however, there is some duplication of information in the Windows Registry so that legacy tools can use them.

Windows Registry

The Windows registry houses COM information under the HKEY_CLASSES_ROOT registry key. This information is maintained to support all the registration information needs of legacy COM applications as well as type library and interface proxy/stub registration information for COM+ applications.

Component Application Configuration and Deployment

The goal of component application deployment is to efficiently distribute COM+ application proxies, library applications and server applications to one or more computers. There are a variety of tools and techniques to support this distribution. They include the following approaches:

Depending upon the type and magnitude of the Windows DNA-based application being deployed, the Implementer can use different combinations of these tools during the Deployment discipline Activity: Create Deployment Unit, to develop the Installation Artifacts. Installation artifacts include install scripts and setup files.

Component Services Snap-in

The Component Services Snap-in is the primary management tool used for configuring and deploying COM+ applications. It can be used for configuring system level parameters, installing and configuring applications, and configuring and monitoring services used by COM+ applications.

This tool provides a wizard-based interface to export COM+ server applications and application proxies. Two files are created for each type of export. One file has an .MSI extension and the other has a .CAB extension. The file with the .MSI extension is a Microsoft Software Installer application package that contains all the information necessary to be deployed using the Microsoft Installer Service. The Microsoft Installer Service is part of the base Windows 2000 operating system.

The file with the .CAB extension is a Cabinet file that contains the MSI file and a cabinet information file. This file can be used with the component download features of Microsoft Internet Explorer®, by embedding an Object tag with a Codebase reference in an HTML page. This approach is applicable when the Internet Explorer browser is used to host application proxies and those proxies, in turn, are communicating with a remote COM+ server application. The following code sample demonstrates how an object tag is inserted into an HTML page.

The Component Services Snap-in can be used to assemble all of the configuration information for a COM+ application. This includes all of the parameters mentioned under the COM+ Catalog section above. The Component Services Snap-in is a good tool for configuring applications on one or two servers. When an application needs to be deployed to numerous servers, or there are a large number of applications that need to be deployed to a small number of servers, one of the other deployment options discussed in the following sections should be explored.

Custom Scripts

All of the functionality that is exposed via a graphical user interface from the Component Services Snap-in, is also available through an application programming interface (API) to the COM+ Catalog. The following objects are part of the COM+ Administration Library.

COMAdminCatalog	Object that represents the entire catalog
COMAdminCatalogCollection	Object that represents any collection within the catalog
COMAdminCatalogObject	Object that represents any item within a COMAdminCatalogCollection collection

These objects can be used in scripts written in VBScript, JScript or any other language/environment that supports either COM+ automation or native COM+ interface-based invocations. This approach is well suited to situations where complex COM+ server and library application environments must be duplicated across numerous machines and where application deployment customization is required. Custom deployment scripts can be created to not only deploy the COM+ application, but to perform a variety of other activities related to configuring and to deploying a complete application as well. Examples of this include:

COMRepl

COM+ provides a tool, COMRepl, to assist in the automatic distribution of COM+ applications from one source computer to one or more target computers. The COMRepl tool provides the ability to replicate the components and their associated configuration information. The following requirements must be met to use COMRepl:

COMRepl is well suited for replicating COM+ server and library applications across multiple servers.

Custom MSI Packages

The MSI output files that are created when exporting COM+ server applications or application proxies from the Component Services Snap-in, can be combined into other MSI packages to build monolithic MSI packages. This is a particularly useful approach when deploying COM+ application proxies that are part of a larger application. One of the features of COM+ application proxies, is that the RSN of the proxy can be specified when the MSI script is run. This provides flexibility of location in where the application proxy MSI file is created and where it is installed. Custom MSI packages can then be configured using Microsoft’s Active Directory Group Policies and IntelliMirror technologies to construct seamless deployment scenarios to large numbers of Windows 2000 machines. Refer to the Microsoft Windows 2000 Web site at http://www.microsoft.com/windows2000/default.asp for more information on Active Directory and IntelliMirror.

IIS Configuration and Deployment

The process of configuring and deploying a Microsoft IIS (Internet Information Services) application to one or more machines involves the following steps:

The following sections describe how the IIS Metabase is structured and the tools and techniques that are available for modifying the Metabase. Additionally, various tools and techniques for replicating the Metabase, site content and COM+ applications across machines are addressed. Techniques for replicating application data, and application data access information (such as ODBC DSN information) across machines are not addressed in these guidelines.

IIS Metabase

The metabase is a hierarchical database that is used to store configuration values for IIS. Properties can be set at the computer, Web site, virtual directory, directory, and file level within the metabase. The default name for the IIS metabase is metabase.bin. The default location for the file is in the Inetsrv folder.

There are a variety of ways to update the metabase. However, all access to the metabase is ultimately gained by using the IIS Admin Objects or the IIS Admin Base Objects. The IIS Admin Objects expose an automation interface that takes advantage of Microsoft’s Active Directory Services Interface (ADSI). This allows languages such as VBScript, Jscript and Visual Basic to manipulate the metabase. The IIS Admin Base Object is a COM object that implements the IMSAdminBase interface. IMSAdminBase provides a low-level interface with methods that enable COM-compliant languages such as Visual C++ to manipulate the metabase.

IIS Metabase Configuration and Replication

Configuring and replicating the IIS Metabase is the first step in deploying an IIS-based application. Several tools and techniques can be used to accomplish this.

GUI Tools

The primary GUI tool for manipulating the IIS Metabase is the Internet Services Manager Snap-in. This tool supports manual configuration of all metabase information by presenting a hierarchical view of all Internet Services and their associated content trees. FTP, Web and SMTP services can all be managed and configured using the Internet Services Manager Snap-in.

Another Microsoft supplied tool is MetaEdit. This is a GUI tool that allows direct manipulation of all metabase keys and values. It provides a hierarchical tree-view of the metabase that reflects the internal structure of the metabase and the associated IIS Admin Object model.

Both of these tools are well suited for configuring a single machine. However when multiple machines need to be configured identically, another approach should be used.

Custom Scripts and Programs

IIS provides pre-built scripts that leverage the IIS Admin Objects and provide simplified access to those objects. Located in the AdminScripts subdirectory of the Inetpub directory are numerous VBScript files that can be used to query and update the metabase. One of these scripts, adsutil.vbs provides commands to get, set, enumerate, delete, create, and copy metabase keys and values. It also supports a variety of options for creating, deleting and modifying IIS applications as well as starting and stopping IIS services. These scripts can be combined into other custom scripts or the IIS Admin Objects can be directly accessed from custom scripts to manipulate the metabase and/or to recreate an entire metabase structure. This is a very flexible approach for replicating metabase information across multiple machines.

An alternative to using the IIS Admin Objects is to use the IMSAdminBase interface of the IIS Admin Base Objects from a Visual C++ program. This approach may be chosen if extremely robust deployment utilities need to be developed, or if Visual C++ is a preferred development environment.

Similar to using automation scripts for configuring and deploying COM+ applications, custom scripts have the advantage over other deployment approaches and utilities by being extensible. They can be enhanced to distribute and to configure all aspects of an application, not just IIS metabase information.

Content and Application Replication

After the IIS Metabase is replicated, site content and possibly COM+ application components and configuration information must be replicated across machines. The techniques described in the Component Application Configuration and Deployment section can be used to deploy COM+ applications. The following sections provide alternatives for replicating site content.

Microsoft Site Server®

Microsoft Site Server provides a comprehensive Web site management solution. Site Server includes a content deployment feature with the capabilities of keeping the content of multiple Web sites in sync. The deployment features of the product are robust in that they can be automated, and are recoverable in the event of a replication failure. This is a good solution for content replication, particularly if Site Server is already being used.

Microsoft Visual InterDev®

Another Microsoft tool that can be used to deploy IIS-based applications is Visual InterDev. Visual InterDev provides functions that allow the implementer to copy content from one Web site to another using the Microsoft FrontPage® server extensions that are part of IIS. The limitation of this approach is that a copy can only be made to one Web site at a time, and the copy cannot be scheduled for automatic updates. This approach is only recommended for sites that are spread across a small number of servers.

IISSync

IISSync is a tool that is provided with IIS to replicate IIS metabase information, IIS site content, and COM+ application information across multiple machines. To replicate COM+ applications, IISSync internally calls COMRepl, the component replication tool described previously in the Component Application Configuration and Deployment section of this guideline. The primary limiting factor in using IISSync, is that it is designed to be used in a clustered environment. This means that it can only be used with Windows NT Server Enterprise, or with Windows 2000 Advanced Server Edition.

Custom Scripts

As with COM+ application deployment and IIS metabase deployment, custom scripts can be developed to deploy the content of an IIS-based application. This approach provides the maximum amount of flexibility of all the content deployment alternatives, but is also the most labor-intensive approach.

Deployment Scenarios

This section discusses two deployment scenarios and lists the appropriate configuration and deployment tools and techniques that should be used for each.

COM+ N-Tier System Deployment

This deployment scenario describes the tools and techniques that should be applied to a COM+-based application where a presentation tier, rich native client (Win32-based) is accessing COM+ server applications on one or more middle-tier servers. This scenario has the following considerations:

The best technology for deploying the rich native client application and the COM+ application proxies to the Windows 2000 Professional machines would be to use the Component Services Snap-in to export the COM+ application proxy .MSI file. Then include that .MSI file in a comprehensive MSI package that installed the entire rich native client application. Finally, the comprehensive MSI package could be configured within the Active Directory Group Policy/IntelliMirror framework and be deployed using its distribution features.

The deployment techniques for the COM+ server application, library application and associated application data depend upon the complexity of the application’s configuration and to the number of machines that the application is being deployed. If the application will only be running on one or two machines, or the application is very simple, and the application will only be deployed to a single site, the Component Services Snap-in can be used to manually install and configure the COM+ server and library applications. The exported .MSI files can be manually copied to each server to be installed. The associated data file and data access configuration setup can also be performed manually on each machine.

If the COM+ application is complex or if it is going to be deployed across multiple servers or sites, then COMRepl and/or COMRepl, in conjunction with custom scripts, should be used to deploy the application and associated application data. This technique will guarantee that mistakes are not made by manually deploying the application and that the machine configurations are consistent across all servers.

IIS/COM+ System Deployment

This deployment scenario describes the tools and techniques that should be applied to an IIS-based application. The application may also include COM+-based application components that are accessed from ASP pages. The guidelines for deploying this type of system are similar to the guidelines for deploying a pure COM+-based system. For guidelines on deploying the COM+ portion of an IIS/COM+ System, see the previous COM+ N-Tier System Deployment section that describes techniques for COM+ server application deployment.

If the system is relatively simple and static, or if it is only being deployed to a small number of machines, and the application will only be deployed to a single site, then manual distribution can be used. The Internet Services Manager Snap-in and/or the MetaEdit utility can be used to configure the IIS Metabase on all deployment machines. Then a tool such as Visual Interdev can be used to replicate site content to each of the Web servers, one at a time.

If the system is complex and/or dynamic, or if it will be deployed across multiple machines or sites, one or more automated deployment techniques should be used. If the environment being deployed to is a Microsoft Windows Cluster-based platform, then IISSync should be used to replicate the IIS Metabase information, IIS site content and any associated COM+ applications across machines. If IISSync cannot be used, scripts should be developed to update the IIS Metabase. This will ensure metabase consistency across all IIS machines. Next, a content replication tool such as Site Server should be used. The automated content replication features of Site Server are critically important when site content changes frequently and large numbers of servers must be kept in sync. Additionally, custom scripts will most likely need to be developed to distribute associated site data files or data access configuration information. These custom scripts must be run on all machines, but the execution of the scripts can be automated by using Telnet or some other remote console utility to initiate the execution of the scripts from a single remote machine.

Guidelines: Configuration and Deployment of COM+ and IIS-Based Applications

Topics

Summary

Component Architecture Overview

COM+ Applications

Server Applications

Library Applications

Application Proxies

COM+ Catalog

COM+ Registration Database

Windows Registry

Component Application Configuration and Deployment

Component Services Snap-in

Custom Scripts

COMRepl

Custom MSI Packages

IIS Configuration and Deployment

IIS Metabase

IIS Metabase Configuration and Replication

GUI Tools

Custom Scripts and Programs

Content and Application Replication

Microsoft Site Server®

Microsoft Visual InterDev®

IISSync

Custom Scripts

Deployment Scenarios

COM+ N-Tier System Deployment

IIS/COM+ System Deployment