Introduction to IIS 4.0 with MTS and DCOM

Windows DNA lets you serve up components and transactions

At the Microsoft Professional Developers Conference '97 in California last September, Microsoft introduced the Windows Distributed interNet Application Architecture (Windows DNA), a framework for building multitier distributed computing solutions. Since then, Windows DNA has received both positive and negative press, with most of the negative press resulting from confusion surrounding the term Windows DNA and its components. To help clear up this confusion, I will introduce two major pieces of DNA, Distributed Component Object Model (DCOM) and Microsoft Transaction Server (MTS), and describe how they interact with a third major part of DNA, Internet Information Server (IIS) 4.0.

Developing DNA Applications with COM
Windows DNA lets you develop client/server applications, intranet applications, Internet applications, and a mixture of all three types. The application can use most Microsoft products with third-party components and tools. Windows NT Server and a database, such as SQL Server or Oracle, usually serve as the foundation for such an application. A Windows DNA application typically uses middle-tier business rule components and other front-end and back-end components built using the Component Object Model (COM).

COM is the most popular architecture for implementing components in a Windows environment. A COM component is simply an application or piece of code, such as an ActiveX component or control, that exposes parts of itself for other applications to use through COM's standard interface mechanisms. For example, a developer might create a customer component and expose particular attributes (known as properties) of the customer, such as name, address, and telephone number. Other applications can then use the customer component and either read or set the exposed properties. In addition to exposing properties, a COM component can also expose methods (known as actions) that other applications can use. For example, the customer component might have both Add and Delete actions, where Add creates a new customer and Delete removes an existing customer.

You can create COM components with Visual Basic (VB), C++, Delphi, Visual J++, and other languages. Because COM is a binary standard, it is language independent. Therefore, you can interchange COM components among any applications or development tools that adhere to the COM specification.

COM components are extremely powerful. Many vendors, such as Microsoft, build major business applications, such as Microsoft Office 97, using many different components that other applications can use via COM. Almost everything Microsoft ships exposes a COM interface for the application. Your organization might be creating COM components to encapsulate various layers of its business rules. Such components are usually known as business objects. For example, most companies that sell products or services have pricing rules. You can use COM to encapsulate the pricing rules into a component for other applications to use. This sharing makes changing the pricing rules easy, because all you have to do is change that one component to make all the applications use the latest pricing rules. Another example is shop floor components for the factory floor. You can easily build a set of COM components that package functions such as shop floor inventory handling, employee tool issuing, and time card entry.

DCOM even lets applications use remote procedure calls (RPCs) and a network transport (such as TCP/IP) to remotely access COM components. DCOM hides all the details from the developer, so anyone with the proper security credentials can run the DCOM Configuration tool (dcomcnfg.exe), which comes with DCOM, and configure a component to execute remotely.

Serving Up COM Components
Now that you understand a little about COM components, you can begin to understand how they relate to IIS and specifically to Active Server Pages (ASP) applications. ASP applications can execute a COM component by just adding a line or two of program code to the page. For example, you can add a few lines of code to use a Calculator component. The following line creates an instance of this component:

Set obj = Server.CreateObject("Math.Calc")

Two more lines of code set the properties of the Math.Calc component I just created:

Obj.Op1 = 2Obj.Op2 = 5

Next, I execute the Add method:

Obj.Add

Finally, I can retrieve the result and send it to the HTML stream:

Response.Write "Result is: " & Obj.Result

This code segment shows why COM components are so powerful. I simply use the component as a black box that performs some function.

Now, each time the ASP page executes, the Math.Calc component executes and carries out any instructions I program in the code. This functionality is great because components let developers reuse code and achieve large efficiencies in development projects.

The ASP files that make up an IIS application contain script code (usually either VBScript or JScript) and HTML. Each ASP file requires resources (at least CPU and memory) on your server. In addition to these resources, IIS caches the ASP files in memory to improve performance.

With IIS 3.0, all ASP pages and other in-process components run in the same memory space as the IIS Web service. ASP pages are relatively bulletproof, and the script in a page can create an instance of a COM component and use it like any other application, as my previous calculator example shows. An in-process COM component, such as an ActiveX component, will run in the same memory space as the Web service. Unfortunately, if the ActiveX component crashes, it can also crash the Web service. Despite this risk, many developers use in-process components because they are much faster and consume fewer resources than out-of-process components.

With IIS 4.0, you can create ASP applications that run in their own memory space, so that if the application crashes, it won't crash the server. This IIS 4.0 feature is a major improvement over IIS 3.0. You can set the ASP application to run in its own memory space using the IIS snap-in in the Microsoft Management Console (MMC) and checking the box Run in separate memory space (isolated process), as you see in Screen 1. Even if you have a Webmaster who handles such Web-related tasks, you need to understand the ramifications of such settings.

Distributing Components with DCOM
ActiveX components usually run on the same server as IIS, but they don't have to. You can easily distribute your components across the network to another server with DCOM. Figure 1 shows a typical scenario for DCOM and IIS in a network environment.

In Figure 1, the ActiveX components run on one server in the Application Server Farm. DCOM automatically manages the remote execution of these components from the Web server and handles the movement of data from the calling application (in this case, the IIS ASP application) and the movement of the component through a process known as marshalling.

You don't have to create a component as a DCOM component. You can use almost any out-of-process (.exe) ActiveX component and distribute it using the DCOM Configuration tool. Screen 2 shows the DCOM Configuration tool interface. This tool is in the System32 folder and does not have an icon in any of the Programs folders (I usually create a shortcut on the Desktop that points to this tool).

Screen 2 shows the Properties for an ActiveX component (VisData Database Utility). To distribute the component to another server, click the Location tab of the Properties box, remove the check mark in the Run application on this computer check box, select the Run application on the following computer check box, and enter the name of the server where you want to run the component. Once you click OK in the component's Properties box, you just need to register the component on the remote server to complete the setup. Now, any time any application executes the component on this system, the operating system (OS) uses DCOM to execute the component on the remote server.

You can also use the DCOM Configuration tool to set the security parameters for a component. Click the Security tab, as you see in Screen 3, to set the security attributes for the component. The Security attributes let you control three sets of permissions (access, launch, and configure) associated with the DCOM component. A Default Security tab on the master screen of the DCOM Configuration tool contains the same three security settings, except they work for all components on a server so you don't have to set the attributes for each component individually.

DCOM relies on NT access control lists (ACLs) to manage security for components. Using ACLs, DCOM security works transparently in an NT domain environment and uses standard NT security mechanisms such as the Security Accounts Manager (SAM) and NT services to control access to components.

In addition to the security attributes, you can specify which users can run a component, as you see in Screen 4, page 174. The default user account is always the user that launches the component. You might want to change this user account in certain cases, such as with a Web application. For example, if the launching user is anonymously accessing your Web site, access to any component will be through the anonymous account (usually IUSR_machinename), which is typically a local account to the NT system running IIS. If you are using DCOM and the component will execute on another NT system, use a domain account to launch the component. You can create specific user accounts for this purpose, or you can make the IUSR_machinename a domain account. You might need to add a separate account to provide the required privileges that a component needs for accessing a database or resources, such as files.

Adding Microsoft Transaction Server
MTS provides a powerful infrastructure for component and transaction management and removes a huge load from the development staff who otherwise have to develop these services. MTS works with in-process (.dll) ActiveX components, and you can create a transacted ASP page with IIS 4.0. Because ActiveX components will run in MTS and the ASP pages using these components will run in MTS, you need to understand what MTS is and why it's so powerful.

Developers create a transacted page by flagging the page as part of a transaction. They simply add TRANSACTION=Required in the language definition at the start of the page, as follows:

<%@ TRANSACTION=Required LANGUAGE="VBSCRIPT" %>

This statement forces the entire ASP page to run inside one transaction. Now that an ASP page can run as a transaction, your developers will be relying on MTS more and more.

Figure 2 illustrates how MTS fits in the NT 4.0 and IIS 4.0 architecture. You can see the layering of the various pieces and how they all work together regardless of whether you are accessing them with a Web browser or a traditional client such as a PC. MTS provides the framework for executing components and managing transactions. Transactions are useful any time you have two or more actions and all actions must complete, or all must fail. For example, if you have an inventory control system, your system must properly issue stock to the shop floor. If you pull a widget from stock and send it to the shop floor, you must deduct the widget from inventory, add the widget to a work-in-process inventory, and assign the employee ID of the individual retrieving the part. You can see that a simple request for a part from the stockroom can trigger several discreet actions that must occur. MTS can handle all the components and take all the actions. If one of these actions fails, MTS aborts the entire transaction.

MTS helps with component management from several aspects. For example, if you are running a component with MTS and DCOM, you have only one copy of that component to worry about on the server. Figure 2 illustrates how MTS stores the ActiveX components and how the applications talk to MTS instead of using a component directly. This redirection to MTS is transparent to the client application.

MTS also helps manage the load that components place on the server. MTS will create an instance of a component (thus using memory and processor) only as needed, and it will release those resources as soon as they are no longer required. This process is known as just-in-time (JIT) activation and as soon as possible (ASAP) deactivation.

MTS can reduce the load the database connections cause. Components that use MTS to manage database connections can significantly reduce the overall load on the server. In terms of server resource usage, database connections are expensive to create, so fewer connections are better in terms of server performance. MTS will create a database connection only as necessary, which reduces the load on the server and reduces the number of database connections required. MTS manages the database connections by pooling them and dispensing them only as necessary. Because MTS uses JIT activation and ASAP deactivation, it can more efficiently handle the database connections. Often, MTS uses one connection for multiple components, and each component behaves as if it has an exclusive connection. (I'll provide more information about the management issues associated with MTS in an upcoming article.)

Wrapping Up
You don't have to design your ActiveX components to run using DCOM. However, using DCOM can make a tremendous difference in how the components perform and the load the components place on the server and network. For example, a customer component might have 30 properties, one for each attribute of the customer (e.g., first name, last name, and street). By setting the values for each property, you cause a state transition between the components that is very expensive in terms of server resource usage. State transitions occur when a part of one process must access a part of another ActiveX component. The transition occurs when you cross the boundary, which uses a lot of system resources. You can use one state transition to redesign each component and drastically improve the component's performance by passing the data for each property to the component when you call a method. The resulting change takes only one state transition.

Likewise, you don't have to design an ActiveX component to work with MTS. Generic ActiveX components will work in MTS, but they can't take advantage of the transaction abilities and they won't perform as well as they would if they were designed to work with MTS.

As a systems manager, you can get a handle on such issues during the development and testing stage and, of course, in production—although that's not the time you want to find out about problems. You can use Performance Monitor to track IIS, ASP, and ActiveX components. The components show up as processes under the Process object on the server they execute on. You can also use Network Monitor to watch for the traffic coming across the network. The more state transitions that occur, the more packets the network will generate.