Managing COM Objects on NT 4.0

Downloads
15974.zip

IF YOU want to create Web applications on your Windows 2000 and Windows NT 4.0 servers today, you need to be familiar with Microsoft Windows DNA. Windows DNA was Microsoft's architecture for building Web and Win32 applications before the .NET initiative came along. The Microsoft Windows DNA home page (http://www.microsoft.com/dna) lists software and technologies that are now part of the Microsoft .NET and .NET Enterprise Servers platform. The list includes servers such as SQL Server and Exchange Server, programming tools such as Visual C++ (VC++), and services such as COM+ services in Win2K and Microsoft Transaction Services (MTS) in NT 4.0.

To create applications with these Windows DNA—or .NET—tools, you build COM components with a language such as Visual Basic (VB) or VC++ and wire them together with script or code. In NT 4.0, you can manage COM components with MTS (you use COM+ in Win2K). MTS has been around for a while, but many organizations are just beginning to use it in their applications. Let's walk through the basics of installing and managing COM components with MTS in NT 4.0. (I discuss using COM+ to manage components in Win2K in "Managing COM+ Applications," http://www.win2000mag.com, InstantDoc ID 9753.)

Storing Components
If you intend to manage a COM component with MTS, the developer must compile it as a DLL. Many administrators place DLLs in a server folder that other servers can link to so all servers can share the same copy of the DLLs. However, this practice is unwise for several reasons. First, if the server hosting the DLLs goes down or becomes unavailable for some reason, the other servers can't access the DLLs. Second, if all the servers access the same copy of the DLLs, you can't upgrade a DLL in a rolling fashion (i.e., on one server or a group of servers at a time). Instead, you must shut down every process that uses the DLL before you can replace it.

A better approach is to put DLLs on a staging server and then copy them to each production server when you're ready. With this method, you have application redundancy and can roll out a component upgrade from a staging server to one or a few servers at a time rather than to all servers at once.

I talk more later about copying DLLs and MTS packages from the staging server to the production servers. But first we need to put the components on the staging server. A good way to organize components on the staging server is to create a component directory with a subdirectory for each MTS package or each project. Figure 1 shows what the directory structure might look like. To save time, you can write a batch file to create the directories on the staging server. Listing 1 shows such a batch file.

Adding Components to MTS
After you create the directory structure and copy the component DLLs to the appropriate subdirectories, you can install the components in MTS on the staging server. When you install components in MTS, they run inside an MTS package. The MTS package, or component container, has an NT 4.0 identity and, by default, creates a process for itself and its components.

To create a new MTS package, open MTS Explorer from the NT 4.0 Option Pack folder in Programs. Figure 2 shows the MTS Explorer window. Expand the Microsoft Transaction Server folder, the Computers folder, and the My Computer folder, and select My Computer. Right-click the Packages Installed folder, select New, then select Package. Next, click the Create Empty Package icon. Enter a name (such as Components) for the package, and click Next to display the Set Package Identity window, which Figure 3 shows.

The default package identity, Interactive User, causes the package to run under the user account of the currently logged-in user. You should change the identity of the package to a specific account that has the privileges needed to work with the package. In Figure 3, I've set the identity to the user account WininNTPackageUser.

You might want to change one more package setting. By default, the Activation property is set to Server. This value causes the package to run in its own server process, which mtx.exe hosts. You can change the value to Library, which causes the package to run in the calling application's process. For instance, if an ASP application executes a method of a class in a package with the Activation value Library, the package runs in the Microsoft IIS process Inetinfo instead of in mtx.exe. The Library setting results in a fast application, but one that can crash if anything in the package goes wrong. (Server packages can also crash, but they won't cause Inetinfo to crash.) In addition, if you use the Library setting for a package, you must go through extra steps to replace a package component. In the case of an ASP application, you must shut down the entire IIS system. I usually test an application with the Server setting. Then I performance-test the application and, if necessary for performance reasons, change the setting to Library for the application's production version. To change a package's Activation setting, right-click the package name, select Properties, click the Activation tab, then select Library or Server.

After you've created the Components package, you can add one or more components to it by dragging the component files (i.e., the DLL files) from Windows Explorer and dropping them into the package in MTS Explorer. After a component is in the package, you can open the component class' property pages to set the class' properties, such as the Transaction Type property, which controls how and when the class participates in a transaction.

Distributing Packages to Other Servers
Now that your component is in a directory and in an MTS package on the staging server, how do you get it to the production servers in your application farm? A network that has different groups of Web application servers running different applications (e.g., two servers running one application, two other servers running another application, and three more servers running a different set of applications) typically has a staging server for each group of production servers. You should configure a staging server similarly to its associated production servers—matching their NT, Microsoft Data Access Components (MDAC), IIS, MTS, and other settings— so you can test new application versions on the staging server before you roll them out to the production servers.

You have several options for moving components and packages from one server to another. One option is to access each server independently and copy the components, create or modify the packages, and load the components into the packages manually. You can use MTS Explorer to access and manage remote computers. Right-click My Computer, choose New, then choose Computer to add a remote system to MTS Explorer. When MTS successfully connects to the newly added computer, the computer icon's screen turns green. You can now view and, if you have the appropriate authority, manage the remote MTS server.

This method of copying components is labor intensive and time consuming, however. It's also fraught with problems because you must carefully perform each step on each system. One small mistake, such as setting an incorrect property for a component or class or deleting the wrong component, might prevent an application from working.

A second option is to use a batch file such as the one in Listing 1 to create a component directory structure on each server. You could create another batch file to copy the components to the servers for you. But the batch files get you only part of the way to your objective; you must still create the packages, load the components into the packages, and configure package properties, security, and any other settings. (In addition, if you use the batch-file approach and a batch operation fails, discovering which process failed and recovering from the failure are almost impossible.) However, MTS exposes its methods and properties through COM, so a developer could create a utility that automates package creation and configuration.

A third option for remotely managing components and packages is to use MTS's Remote Components folder. You can use this folder on each MTS system to push and pull components from one system to another. To use Remote Components, you must install the DLLs in a network share so the remote servers can find them. Then, using MTS Explorer, you can copy a component from the network share to a remote server's Remote Components folder. MTS copies the component across the network, installs it on the remote server in a folder in the MS install directory, and gives the folder the same name as the package. Using Remote Components is a workable solution, but you still must do the work on each system, and you have limited control over the directory structure your components are installed in.

Another approach you can use is MTS Explorer's Export and Import features. I prefer this method because it exports all the DLLs and package settings in one step. Then, you can import the package to any other system in one step.

When you export a package, MTS Explorer creates a package file (with the .pak extension) that contains information about the components and roles, or security groups (if any), included in the original package. MTS Explorer also copies the component DLL files and type libraries to the same directory in which it created the package file. The exported package includes the original package's settings such as Activation and Transaction Type. To export a package, take the following steps:

1. In MTS Explorer's left pane, click the name of the package you want to export and select Export from the Action menu. Alternatively, right-click the package name and select Export from the menu.
2. Enter the name of the new package file to create. To add any existing roles to the package, select the Save Windows NT user ids associated with roles check box.
3. Click Export to start the export.

If you change a package property or refresh a DLL that has been recompiled, you must export the package again because the MTS catalog entries for the package are no longer valid. Developers should read the Books Online (BOL) section "Building an MTS Package for Export" for information about what they need to do with components meant for export. The BOL documentation includes pointers on configuring components for export.

To import the package to another system, you can use the MTS Explorer Action menu's Import option. Alternatively, start Windows Explorer, open the Packages Installed folder, and drag the target package into the Packages Installed folder on the server you want to install the package on.

Mtxrepl is another tool you can use to replicate MTS applications from one MTS server to another—within an NT 4.0 cluster (using Microsoft Cluster Server—MSCS). I haven't tried to use Mtxrepl without a cluster, but it might work. The BOL MTS documentation mentions that you must shut down packages on the target system before you use this tool, or you might get unexpected results.

Automating Automation
MTS provides an automation interface. The MTS Explorer snap-in exposes most of MTS's functions. Developers can use any OLE Automation-compatible language, such as Visual Basic (VB) or VBScript, to develop an application to automate MTS. Developers can find more information about automating tasks with MTS in the BOL section "Automating MTS Administration."

If your organization has many applications that use components, or many servers, you might want to ask your developers to crank out a utility that automates the process of exporting a package from a server, copying the package to another server, then importing the package on the second server. The utility should have a command-line version so that you can automate the process in a command file. Such a utility will save you a tremendous amount of time in the long run and reduce the work that you and your staff must perform to manage your servers.