Figure 2. The transaction statistcs window offers a graphical view of cumulative server activity.
Having reduced the frequency of my column to every other month imposes extra responsibility on me. In particular, I lack the "not enough time" excuse for failing to follow through on commitments I made in previous columns. At the same time, because two months have passed, you have probably forgotten those commitments, if not the entire gist of my last column. If thatıs the case, you can look it up (see "Tiers Without Tears," DBMS, February 1998), which is exactly what I do when I want to remember what Iıve told you in the past. The column includes my attempts to develop some middle-tier components. Toward the end of that discussion I made a veiled promise to describe Microsoft Transaction Server (MTS) 2.0 in some detail this month, and I plan to fulfill that promise.
When I wrote my February column, I was having a devil of a time installing a late beta of the Windows NT Option Pack, and I determined that my best course of action would be to reinstall Windows NT entirely! Soon after, I reformatted my hard disk and reinstalled Windows NT Workstation. I was surprised by how quickly I was able to accomplish this task and by how much better my life had become in the process. It took me about three hours to back up my volatile files onto a network drive, repartition and reformat my 4GB disk, and reinstall the operating system and applications. The systemıs performance has accelerated quite noticeably, and it no longer gives me all sorts of error messages. I recommend a regular NT reinstall to anybody who uses it as a workstation and particularly to those of you who have evaluated a number of administrative or development tools and utilities that you are no longer using.
Microsoft released the Windows NT Option in December, and I downloaded and installed it without incident. The Option Pack includes Internet Information Server (IIS) 4.0, MTS 2.0, Microsoft Message Queue Server 1.0, Microsoft Certificate Server 1.0, Microsoft Management Console, and Internet Connection Services for Microsoft RAS. You probably donıt want to digest this all at one time, but it comes in one package, and itıs now included in the price you pay for Windows NT Server. The setup program allows you to pick which applications you want to install.
The Option Pack setup program added a new folder for the Personal Web Server (PWS) to the Programs group in my Start menu. It placed a subfolder for the Transaction Server inside the Start menuıs PWS folder. I started both the Transaction Server and SQL Server 6.5, which is the database of choice for the supplied sample applications. I arranged the windows in the Transaction Server Explorer so that I could see it respond to a client application. I then ran the sample application, which simulates deposits and withdrawals into a checking account. It seemed to work just fine. (See Figures 1 and 2.) Of course, running a client to a middle-tier application server on the same box as the middle tier is not very interesting, so I decided to try running the client from my Windows 95 laptop.
I had already installed the NT Option Pack for Windows 95, and if you find the experience confusing, youıre not the only one. Thatıs the version you can install if you want Personal Web Server 4.0 for Windows 95, and it installs Transaction Server on your Windows 95 box as well. This is mostly useful for reading the help files and reviewing the sample code when you are away from your office. The installation process registered my sample applications as local server applications. I vainly believed that I could change that registration by entering the DCOM-configuration utility and using it to point the previously installed components at my Windows NT remote server. For a moment this appeared to work. The first time I fired off a task from the sample application client, the server chugged and the client reported a successful transaction. After that, all I got were error messages indicating that either the application server or the database was missing.
Because I had seen it work one time, I doggedly thought I could get it to work again by changing some of the code in the sample. Silly me. I stayed in my office until 8:00 on a Sunday evening tinkering with code. The only smart thing I did was posting a request for assistance on the Microsoft newsgroup microsoft.public.microsofttransactionserver.administration-security. I returned at 9:30 Monday morning to find that a kind gentleman from Belgium had supplied my solution, which I would have found had I thoroughly read the help file.
To wit, you must use the MTS Explorer to generate an application executable, which you then distribute to your client machines. When you run the generated executable on a client machine, it configures the client to access your remote server application. To request services executing on a remote MTS server, the client computer that installs the executable must have DCOM support but does not require any MTS server files besides those that the generated executable installs. A few months back, I installed DCOM on my Windows 95 laptop in anticipation of just such a moment. I found the sample applicationıs package in the MTS Explorer and initiated the "Export" process.
The Export process creates copies of both the package DLLs for execution on another MTS server and a .exe file containing the files that the client computer needs to connect to the middle tier. Creating DLLs for installation on a remote server is useful for redundancy and load balancing in addition to moving from a development to a deployment environment. For the time being, I ignored them and concentrated on running the .exe file on my client.
After doing so, I found a new directory named "Remote Applications" inside the clientıs "Program Files" directory. Inside this directory, I found a subdirectory: the GUID of the MTS package. Opening this subdirectory, I discovered several DLLs, whose names matched the names of those installed in my Transaction Server. Fancy that. Before I could run the sample client application, I needed to make a setup disk for it and install it on the client computer. (I later learned that I could have directed the MTS packager to do this work for me.) Once I got all this straight, I went hog wild and installed it on a number of the computers in the office so I could experience the full effect of multiple client workstations using the services of a middle tier managed by MTS.
Pardon my excitement. I realize that in the preceding paragraphs I sped through my experience getting MTS to work in a test configuration, introducing a number of new concepts without much explanation. Letıs take a look at what MTS contains, what it does, and how one goes about setting up an application to run within MTS. Then weıll review how you must code your business service components in order to make them function effectively within the MTS context.
Having now spent some time with MTS, I realize that my earlier confusion about it resulted from seeing only one of the surfaces it exposes; I was having the classic "blind men meeting the elephant" problem! Because I started reviewing MTS from a programmerıs standpoint, I had been focusing on the APIs provided with MTS that allow a programmer to use the MTS resource and transaction-management facilities. I could also see how MTS provides a runtime environment offering a fairly wide range of services. It was not until I actually tried to set up components to run in and against MTS that I began to see the rich environment that it provides for administering middle-tier components.
The MTS Explorer is the administrative tool that you use to identify and maintain the components that should be under MTS control. MTS identifies a "package" as a group of components that execute within the same process. MTS Explorer provides a user interface for creating packages, setting package properties, adding components to packages, and setting component properties. A packageıs security and identity properties determine the security context under which the package will execute. Its activation property determines whether the package will execute within the process of the client that creates it or within an independent process managed by MTS. Packages that execute within the process of a creating client are referred to as "Library" packages. They are only available to clients on the computer on which the package is installed. Library packages offer no component tracking, role checking, or process isolation.
When I learned this, I had to reconsider why you would ever want to designate a package as a Library package. The answer follows as a consequence of the tight integration between IIS 4.0 and MTS 2.0. On a computer running both IIS 4.0 and MTS 2.0, it makes sense to set up packages that contain ASP Server objects (see "Keeping Active," DBMS, December 1997) as Library packages, because the caller is known and MTS manages each ASP application as a separate process. As a result, a failure in one wonıt affect another.
The MTS Explorer provides a wizard-style interface for adding components to packages. The administrator selects one or more DLLs that contain the components that should be included in a package. After you add components, property pages allow specification of their transaction and security properties. The transaction property determines how the component should participate in transactions. (See Figure 3.) There are four possible settings:
Using a transaction server to manage components that do not support transactions was another concept that took a little effort to grasp. I initially perceived benefits accruing from using the MTS Explorer to build distributable files and to define a security model. These are significant benefits that donıt require the use of any transactions. Recall my experience with the "Export" function, wherein I created an executable file for delivery to client machines. Executing that file installed the component DLLs on my client machine and made appropriate registry entries that enabled the client application to make DCOM calls to my server. Prior to MTS, you had to manage DCOM registry settings with the DCOM-configuration utility, and they had to be done consistently on each client machine. Now that you can deliver the client configuration package generated by MTS over a LAN or through a Web page, Microsoft is discouraging us from continuing to use the DCOM-configuration utility.
MTS provides a user-authentication scheme that employs roles together with the graphical tools to administer roles and users. The developer who builds a component can define roles that can perform specified operations. For instance, a salesperson role might be able to query inventory availability, but the inventory manager role would be able to adjust stock levels. When the administrator obtains a component, either commercially or from an internal developer, he or she can review the roles that are defined within the components and assign users from the local NT domain to appropriate roles. Roles apply to packages, so it makes sense to assemble components that have a common set of roles and security requirements into common packages.
MTS assigns a context object to every object running under its control. A context object is an extensible MTS object that provides context for the execution of an instance, including transaction, activity, and security properties. When an MTS object is created, MTS automatically creates a context object for it. When the MTS object is released, MTS automatically releases the context object.
MTS builds its architecture for resource sharing around resource managers that manage durable, or persistent, data and resource dispensers that allocate nondurable resources such as shared properties and database connections. The Resource Dispenser Manager is a DLL that works with specific resource dispensers to pool and recycle these nondurable resources automatically. The ODBC version 3.0 Driver Manager is just such an MTS resource dispenser; when a component accessing ODBC data sources (either directly or indirectly through an API such as ADO or DAO) runs under MTS control, MTS allocates ODBC connections via the ODBC-resource dispenser. This allocation of resources occurs whether or not the component developer implemented any of the MTS-specific API functions.
Thatıs as much as you get for free, and I think itıs quite a bit! To leverage the MTS runtime environment further, you have to call the key MTS API functions within your application. There are two functions to start with: SETCOMPLETE and setabort. These functions are overloaded; they perform additional functionality when used in conjunction with transactional components. Because their names imply transaction processing, using them within nontransactional components is another counterintuitive aspect of the MTS environment. However, using these APIs allows MTS to manage object reuse more efficiently by enabling "just-in-time activation."
When an object calls either setcomplete or SETABORT, it notifies the MTS runtime environment that it should be deactivated as soon as control returns to the client. This allows the MTS runtime environment to release and reuse the objectıs resources, including any database connection it holds prior to the objectıs release. The client continues to hold a reference to the deactivated object. When a client calls a method on a deactivated object, the clientıs reference is automatically bound to a new object. Thus the client has the illusion of a continuous reference to a single object without persistently consuming server resources. (It probably adds some latency to the already considerable overhead of a DCOM method invocation.)
The other significant resource-allocation function that MTS performs is the maintenance and provision of shared values, such as incrementing counters or transaction codes. By providing a mechanism for maintaining and dispensing unique identifiers, MTS significantly reduces the burden on developers to manage concurrency. To use the shared property manager, you must implement a class that references the shared property manager type library, and write some code that creates the objects that it provides.
The shared property manager presents a three-level object hierarchy. The top level is the shared property manager itself. The middle level is a named collection object that represents the group of shared properties that need to be available to the application package. The method call that creates this group (CREATEPROPERTYGROUP) of shared-takes parameters that allow the developer to specify the groupıs isolation level and lifetime. The bottom level consists of the specific shared properties themselves, which would typically be properties such as "next order number" or "transaction type code."
Itıs finally time for a brief discussion of transactions and for me to share a little secret: MTS itself does not provide transaction processing services. Rather, it manages transaction context and obtains transaction processing services from the Microsoft Distributed Transaction Coordinator (DTC). DTC is an NT system service that enables work to commit as an atomic transaction even if it involves multiple persistent data stores, which may reside on separate computers running different operating systems. DTC was first released as part of Microsoft SQL Server version 6.5 and is now included with MTS as well. Microsoft DTC implements a two-phase commit protocol to ensure that the transaction outcome (either commit or abort) is consistent across all resource managers involved in a transaction. DTC supports resource managers that implement OLE Transactions, X/Open XA protocols, and LU 6.2 Sync Level 2.
OLE Transactions is Microsoftıs COM-interface standard for transaction management. OLE Transactions defines the interfaces that applications, resource managers, and transaction managers use to perform transactions. Applications use OLE Transactions interfaces to initiate, commit, abort, and inquire about transactions. OLE Transactions objects provide the infrastructure for initiating transactions, propagating transactions from process to process or from system to system, connecting transactions to database resources, and indicating the successful completion of a componentıs piece of a transaction.
MTS exposes the DTC services through programming tools that allow developers to build transactional components (in addition to the administrative tools we reviewed earlier that allow assignment of transactional properties to components). The availability of MTS services simplifies client programming and causes only a modest increase in the complexity of middle-tier programming. Clients do not need to know about transaction boundaries because the components they are using can be configured to initiate transactions on their behalf. Transactions provide a simple concurrency model. Because a transactionıs isolation prevents one clientıs work from interfering with anotherıs, you can develop components as though only a single client executes at a time.
MTS manages transaction context based on each componentıs transactional settings as specified in the MTS Explorer and on each componentıs report of its success or failure in completing its task. When a client application invokes a method on an MTS object that requires transactions, MTS automatically starts a transaction and associates the transaction with an MTS context object. Once a transaction has started, the component can reference the transactionıs context object. It needs to do so in two specific instances. First, when it needs to create another object that should participate in the current transaction, the transactional component should invoke the CREATEINSTANCE method on the context object. Using this object-instantiation mechanism (in contrast to the standard CREATEOBJECT method) allows the developer to use the services of several independent components within a single transaction controlled by a "top level" component.
A component must also reference the transaction context when it has completed its work successfully or encountered a condition that precludes successful completion. In the former case, calling the SETCOMPLETE method on the transaction object notifies the MTS transaction manager that this componentıs work is done. In the latter case, calling the setabort method advises the MTS transaction manager that the component is unable to complete its work. Thus it will have to roll back the transaction once all of the active components have reported their status.
Itıs already time to wrap up and there is still more to tell. I expect that you will soon be seeing several books devoted to building applications around MTS; if I didnıt already have a full-time job, I would be tempted to write one myself! Iıll conclude with some simple assertions about how IS organizations will be deploying MTS in the coming months. First, Microsoft delivers several component packages with MTS 2.0 that provide tight integration with IIS 4.0. In particular, these components allow Web site developers using IIS to mark Active Server Pages as transactional, using the same transaction settings that system administrators assign in the MTS Explorer. IIS can run in its entirety within an MTS-managed process, or individual ASP applications can run in separate processes. Another technology with which MTS is integrated is the Microsoft Message Queue Server (see David Linthicumıs column "Get the Message," DBMS, November 1997). While Iım not yet ready to promise that Iıll follow through on a specific topic, itıs clear that the Microsoft development machine is continuing to churn out development infrastructure worth investigating and writing about.
Figure 2. The transaction statistcs window offers a graphical view of cumulative server activity.
Figure 3. Transaction tab on the component property sheet allows the administrator to specify how the component should participate in transactions.