MTS plays a key role in Microsoft's vision for distributed systems. The primary objective of MTS is to take care of many of the functions required to build robust distributed applications that can gracefully handle a large number of requests. Custom software components that are installed under MTS control can take advantage of these MTS features. Figure 43.1 shows a typical three-tiered system architecture that would be deployed using MTS. This illustration shows both standard client applications and Web-based applications sharing a common MTS-based infrastructure.
The success that Microsoft has experienced with MTS revolves around allowing developers to build these multitiered applications by providing a true component-oriented runtime environment that will all but eliminate writing traditional infrastructure code. This is not a dream. It's reality.
MTS is built entirely on COM. Developers can use many different development tools?such as Visual Basic?easily within this environment. The COM-based architecture simplifies object use and reuse, and administrators perform management tasks via drag-and-drop GUIs. MTS also includes automatic transaction support, role-based security, the ability to access most major databases, message queuing product integration, and mainframe-based application integration. As Figure 43.1 also illustrates, MTS is fully integrated with IIS and Active Server Pages (ASP) for ease of Internet/intranet application development. MTS is also positioned for high performance by tackling the hard subjects of database connection pooling, shared property management, and thread pooling.
MTS is a complex product, and the techniques for building a distributed system that includes MTS are different from standard coding techniques. However, the criteria for whether to use MTS is probably getting fuzzier. First, because MTS comes with most of the high-profile Windows operating systems (Windows NT, Windows 2000, and so on), it is rarely a barrier to just start using MTS. It is already there. Second, because MTS offers such things as connection pooling, automatic transactions, thread pooling, IIS/ASP integration, and MSMQ integration, the reasons not to leverage off of this built-in capability are few. And, third, MTS is essentially a formal system architecture (much like J2EE/EJB is), but it is already available and is production worthy. A short discussion of some of the highlights of MTS will make things more clear.
The connection pooling feature of MTS allows multiple clients or components to share a limited pool of database connections. This saves time and resources that would otherwise be used to open, close, and maintain database connections.
A close working partner of MTS is the Distributed Transaction Coordinator. This is truly the distributed transaction workhorse of MTS. MTS and DTC can coordinate transactions across multiple back-end databases (see Figure 43.1). This allows the developer to commit or roll back all changes with one MTS managed statement. For more information on MS DTC, refer to Chapter 32, "Distributed Transaction Processing."
MTS provides automatic transaction management services to components. All the developer or administrator has to do is use a simple property page interface to specify what level of transaction protection is required by a given component. Then, at runtime, MTS performs all required transaction management automatically. This greatly simplifies development and facilitates component reuse.
MTS provides a Shared Property Manager to simplify programming of components that need to save state information or share state with other components.
The thread pooling feature of MTS automatically assigns threads to components from a preallocated pool. When a component finishes executing, MTS reclaims the thread. This greatly reduces the overhead of thread creation/deletion for better overall performance and scalability.
MTS creates instances of components on the server only when requested and reclaims memory resources when the component finishes executing. This form of just-in-time (JIT) activation and as-soon-as-possible deactivation minimizes memory requirements on server machines.
Client applications and users can be validated/authenticated at the time they call an MTS component. This feature can simplify database administration in an n-tier application by moving most security functionality from the database to the middle tier in MTS. For details, see "Configuring Security" later in this chapter.
MTS comes with an automatic client setup feature. Using the client setup program, an administrator can readily configure client machines to access components that are hosted on a remote MTS machine.
Any component in MTS control must create a reference to its MTS Context Object. Creating this reference enables the component to take advantage of MTS services, such as transaction and security support. It is customary not to save the state information across transaction boundaries within components. States are best kept in databases or in the Shared Property Manager (SPM) and retrieved by components when needed.
You can also call other objects from within an MTS component call to the CreateInstance() method. When components complete execution, they must call the SetComplete method on the MTS Context Object. This tells MTS that the component wants to commit any work it has performed when all components involved in the transaction are finished executing. If a component cannot execute successfully, it must call the SetAbort method on the MTS Context Object. This will tell MTS that it should abort the current transaction and roll back all changes made by components involved in the transaction. A basic MTS component pseudocode template would look like the following:
Set ObjectContext = GetObjectContext() (some application code here) Set ObjXYZ = ctxObject.CreateInstance() (some application code here) if (everything OK) ObjectContext.SetComplete Else ObjectContext.SetAbort
The preceding is not executable code, just a functional template illustration. The exact coding technique will vary depending on the program in which you are coding. Now take a look at how to get started with MTS.
The setup of MTS is fairly straightforward. If you haven't installed software from the option pack associated with your operating system, then you probably don't have MTS yet. Keep the following issues in mind:
MTS comes bundled with the NT Option Pack. The NT Option Pack is available in the Enterprise Edition of Visual Studio, the Universal MSDN subscription, or from the Microsoft Web site at www.microsoft.com/windows/downloads/default.asp.
MTS can be installed on any of the 32-bit platforms that Microsoft has, just like SQL Server 2000. Check the documentation for restrictions on Windows 95/98 installations of MTS.
It is safe to install SQL Server 2000 after installing MTS. In previous versions of SQL Server, you had to reinstall MTS.
It is highly recommended that you install the MTS samples code during this installation. Often, it will require you to choose the Custom Installation option and then make sure you get all MTS boxes checked. Some are not installed as the default. The sample code is great for learning MTS capabilities. A couple of code samples are available, including a banking package called Sample Bank and even Tic-Tac-Toe.
If MTS is installed on a server whose role is a primary or backup domain controller, a user must be a domain administrator to manage packages in the MTS Explorer.
After MTS has been installed, you can use the MTS Explorer to view all services that relate to MTS (including MTS), such as Microsoft SQL Server and OLAP Servers. With MTS Explorer, you have the ability to trace messages, see the active transaction list (and ID), and observe the transaction statistics since the last time MS DTC was started. As you can see in Figure 43.2, the MTS Explorer is simply a snap-in for the Microsoft Management Console.
The MTS Explorer is also a good place to view the objects within MTS. These objects are organized into a hierarchy. You should be able to see this hierarchy in Figure 43.2 starting from the Microsoft Transaction Server node and working your way down through the tree to Installed Packages, Components, and Roles.
Some of the important items in the MTS hierarchy are described in Table 43.1.
|Computers folder||Several computers with MTS can be managed from one console.|
|Packages Installed folder||Each computer can have several packages installed; all of these packages are contained in the Packages Installed folder.|
|Package||One package can contain many components. Components within a package share a process, so calls between them are fast.|
|Components folder||Each package can contain several components; these components are contained in the Components folder.|
|Component||A component is the item that outside applications actually call. You can set certain security and transaction support properties at the component level.|
|Role||A role is the primary security mechanism in MTS. Each package can have its own set of roles defined.|