by Don Benage and Larry Millett
This chapter explores the subject of distributed transaction processing. Microsoft is creating a growing number of tools and technologies to help manage applications that execute on multiple computers. This distributes the processing load and provides a collection of other benefits. For example, distributed systems can cost less than the monolithic systems they replace. They also can be easier to maintain and update in response to changing business conditions, if properly designed. Not every application requires distributed transaction services. This area of computing technology is rapidly growing, however, and many businesses and organizations can benefit from these tools, even if they aren't yet aware of the benefits.
Some of these techniques have existed for a while, but were available only on large, expensive platforms costing hundreds of thousands or even millions of dollars. Part of the attraction of these tools is that they're now available on low-cost, commodity-priced computing platforms, putting the technology within the reach of much smaller organizations. This chapter provides an overview of two key components Microsoft offers for distributed transaction processing: the Distributed Transaction Coordinator (DTC) and Transaction Server. The DTC, introduced with SQL Server 6.5, greatly simplifies the process of developing and deploying distributed applications. Transaction Server 1.0 built on the functionality offered by DTC. Transaction Server 2.0, now available as part of the Windows NT Option Pack, is a standard part of Windows NT Server 4.0 Enterprise Edition. It provides a COM-based programming model and forms the basis of an entirely new computing architecture that you can use to build state-of-the-art distributed systems. n
In May 1997, Microsoft announced that a distributed transaction processing system based on a Microsoft platform (Windows NT Server, SQL Server, and Microsoft Transaction Server) had achieved a billion transactions per day. The day before, IBM announced a similar result, using Windows NT Server, DB2, and Transarc Encina. Each company touted the event as a major milestone in the development of high-volume, highly scalable distributed systems based on relatively inexpensive off-the-shelf hardware and software. In both cases, a transaction processing (TP) monitor was a critical piece.
A TP monitor is a software system designed to foster the creation, management, and execution of transactional applications. This is done, in general, by providing tools that make it easier to build scalable applications. The tools provided, which vary from one implementation to another, can include language extensions, a runtime environment, management consoles, and other useful elements.
The salient feature of applications created in TP monitor environments is that they can grow to meet the needs of an organization without experiencing disproportionate increases in costs. In other words, if the processing capacity of the system must double, the costs for the system should be of the same order of magnitude.
Microsoft introduced its TP monitor, Microsoft Transaction Server (MTS), in January 1997. As its name implies, MTS provides support for distributed applications to preserve transactional integrity. The distributed transaction services build on the Distributed Transaction Coordinator service shipped with Microsoft SQL Server 6.5. However, MTS also provides many other services typically provided by an object request broker (ORB), including security, concurrency, multithreading, shared state, and resource pooling. Both types of services are essential for scalable component-based software development.
Microsoft claims that for many distributed applications, MTS can dramatically reduce complexity and development time. In theory, a component can be developed as a single-user standalone; MTS provides the necessary infrastructure for integrated multiuser deployment. At first glance, it's a remarkable claim, and on closer examination, the difficulties seem truly overwhelming. Still, MTS version 1.0 substantially fulfills Microsoft's claims.
Microsoft has two goals for MTS: provide a robust, scalable infrastructure for component-based applications and simplify development of such applications. The component architecture of choice is, of course, ActiveX. Because MTS manages security, transaction processing, concurrency, and resource pooling, developers can concentrate on correctly implementing business logic.
Microsoft very explicitly designed MTS to support mid-tier components for a distributed three-tier application. MTS documents use special terms to identify various components:
FIG. 24.1
Base Client 1 interacts with a single application component. Base Client 2 invokes
one application component, which in turn invokes two others. The secondary components
implement a distributed transaction spanning two resource managers. Base Client 3
uses two mid-tier components: one updates a database, and both share data via a resource
dispenser.
Figure 24.1 shows various interactions among base clients, MTS components, resource dispensers, and resource managers. Base clients invoke MTS components, which can invoke resource dispensers, which can invoke resource managers.
In addition to Visual Studio, MTS is included with Windows NT Server Enterprise Edition. According to Microsoft, MTS will be standard part of Windows NT Server after release of Internet Information Server (IIS) 4.0.
ON THE WEB:Microsoft maintains a list of answers to frequently asked questions about MTS at http://www.microsoft.com/support/transaction/content/faq/.
A transaction is a permanent series of updates to persistent data, which guarantees that all updates occur or none. If the data is consistent before the update, it will be consistent after the series of updates. For example, a program might implement a transfer of funds between two bank accounts. The program must ensure that the proper amount is transferred out of one account and transferred into the other account. Before the transfer, each account is internally consistent (all transactions sum to the current balance), and all accounts are collectively consistent (account balances for a depositor sum to his total balance with the bank). The transfer must preserve both consistencies. This means either that both parts of the transfer succeed, or that if any part fails, no change is made to either account. The ability to guarantee this sort of consistency is sometimes called transactional integrity. In 1983, Andreas Reuter identified four criteria for transactional integrity:
Collectively, these criteria for transactional integrity are known as the ACID test.
The atomicity and isolation criteria have important implications for application developers. Because the intermediate states of a transaction aren't visible outside the transaction and because each transaction is "all or nothing," transactions appear to execute separately and sequentially. This means that an application using transactions can ignore concurrency issues, which can be a substantial simplification.
Every major database management system (DBMS) includes transaction-management functions. For the DBMS application, each table is a separate data set, and updates to multiple tables frequently require transactional integrity. The Transact-SQL language in Microsoft SQL Server includes many transaction-management commands. These three are fundamental:
NOTE: In theory, any persistent data storage mechanism can implement transactions. The best known implementations today are the major database servers such as Microsoft SQL Server, Oracle, Sybase, and Informix. For simplicity, the rest of this chapter discusses transactions as implemented in Microsoft SQL Server.
The BEGIN TRANSACTION command marks the beginning of a sequence of operations that must satisfy the ACID test; COMMIT TRANSACTION marks the end. The ABORT TRANSACTION command indicates that the transaction has failed, and all operations back to the BEGIN TRANSACTION command should be undone (rolled back). The COMMIT TRANSACTION command indicates that the transaction has succeeded, and all operations should be made permanent (committed). Sometimes, it's appropriate to nest transactions.
Assume two tables for a bank example: an AccountActivity table, listing each deposit, withdrawal, or transfer for each account; and a BankAccount table listing each account (including a current balance). Then the Transact-SQL commands to transfer $1,000 from account 11111 to account 22222 might look like Listing 24.1.
BEGIN TRANSACTION
BEGIN TRANSACTION
INSERT AccountActivity (AccountNumber, ActivityType, ActivityDate, Amount)
VALUES (`11111', `Transfer', getdate(), -1000.00)
IF @@error != 0 ABORT TRANSACTION
UPDATE BankAccount
SET CurrentBalance = CurrentBalance - 1000.00
WHERE AccountNumber = `11111'
IF @@error != 0 ABORT TRANSACTION
COMMIT TRANSACTION
BEGIN TRANSACTION
INSERT AccountActivity (AccountNumber, ActivityType, ActivityDate, Amount)
VALUES (`22222', `Transfer', getdate(), 1000.00)
IF @@error != 0 ABORT TRANSACTION
UPDATE BankAccount
SET CurrentBalance = CurrentBalance + 1000.00
WHERE AccountNumber = `22222'
IF @@error != 0 ABORT TRANSACTION
COMMIT TRANSACTION
COMMIT TRANSACTION
Although it's admittedly oversimplified, this scenario does show basic transaction management. The BEGIN TRANSACTION and COMMIT TRANSACTION commands mark the beginning and end of a group of operations (inserts, updates, or nested transactions) that must collectively satisfy the ACID test. If any one operation fails due to an error condition, the entire transaction rolls back to the state at the BEGIN TRANSACTION command. This is implemented by the conditional ABORT TRANSACTION command after each operation.
NOTE: Database servers implement transactions through logs. Every physical write to the data is accompanied by a log entry. Because a series of physical writes is generally required to take a database from one consistent state to another, the log also records consistent checkpoints. If the system should crash in the middle of a sequence of physical writes, the server (on restart) reverses the updates recorded in the log back to the last recorded consistent checkpoint. The BEGIN TRANSACTION and COMMIT TRANSACTION instructions force the database server to establish a new consistent checkpoint in the log; the ABORT TRANSACTION instruction forces the server to roll back to a specific checkpoint. After a server determines that it won't need to roll back beyond a given checkpoint, it discards all entries before that checkpoint.
If a single program can execute the funds transfer, and if all tables involved reside on a single server, the DBMS can provide all necessary transaction management services. In fact, creating a stored procedure makes sense to improve performance and encapsulate the function. When a transaction spans multiple database servers or multiple applications participate in a transaction, however, some middleware is required to coordinate the transactions. MTS fulfills that role.
Sometimes an application must update two or more distinct data sets, and the updates must satisfy the ACID test. Suppose that a bank customer wants to transfer funds between accounts at two different branches and that each branch maintains separate account databases. In this case, the standard transaction management provided by SQL Server won't suffice.
Suppose that account 11111 resides at Branch A and account 22222 resides at Branch B. The funds-transfer application can issue the BEGIN TRANSACTION, INSERT AccountActivity, and UPDATE BankAccount commands separately at Branch A and Branch B. The application can send a commit instruction to Branch A, wait for confirmation, and then send a commit to Branch B. On a good day, everything works just fine. But if the network connection to Branch B fails after Branch A is committed and before Branch B gets the commit message, Branch A is updated and committed, whereas Branch B is in an inconsistent state. The application won't meet the atomicity (all or nothing) criteria of the ACID test.
The solution is a protocol known as two-phase commit (2PC). This protocol adds an extra state: ready to commit. A database in this state can durably commit or roll back a sequence of operations. Before issuing a commit transaction, the application issues a prepare-to-commit instruction to each database. When all databases involved achieve the ready-to-commit state, the application issues a final commit instruction. Figure 24.2 shows a successful 2PC transaction.
FIG. 24.2
A two-phase commit for a successful transaction involving two database servers, a
commit coordinator, and a client application. The commit coordinator doesn't issue
the Commit 2PC Tran instruction until it receives a Commit Prepared
message from each database server.
Normally, everything succeeds. However, if one database server experiences a hardware failure or network connection failure before the final commit instruction, data can be restored to the ready-to-commit state, still ready to commit or roll back.
By using the prepare-to-commit instruction, the bank transfer application acts as its own commit coordinator. In the uncomplicated example where everything succeeds, it's not a major task. However, a transaction involving multiple operations on multiple databases and using multiple 2PC protocols can fail in a bewildering variety of ways:
Coping with all the various ways in which a 2PC transaction might fail requires sophisticated design and programming. Because distributed applications must often support transactional integrity, it makes sense to encapsulate the commit coordinator functions in a server--a TP monitor such as MTS.
NOTE: Theoretically, no protocol can guarantee that every transaction commits or rolls back without intervention. 2PC is probably the best possible protocol, but occasionally an administrator will have to manually force transactions to abort or commit.
Although you need a basic understanding of 2PC to take advantage of MTS, a full analysis of Microsoft's implementation is beyond the scope of this book. Suffice it to say that the 2PC mechanisms described reliably provide transactional integrity with automatic problem resolution in most failure situations. However, a few conditions still require human intervention. This means that an application that uses the 2PC features in MTS will require knowledgeable administrators.
NOTE: The MTS component that acts as a 2PC commit coordinator, the Distributed Transaction Coordinator, originally shipped as a component of Microsoft SQL Server 6.5. Microsoft DTC can interact with other TP monitors by using OLE transactions (the native 2PC protocol for MTS) or X/Open XA (natively supported by many UNIX databases, including Informix, Oracle, and DB2). For details of Microsoft's implementation of 2PC, see the Microsoft SQL Server Programmer's Toolkit, Guide to Microsoft Distributed Transaction Coordinator.
An MTS component accessing a database uses ODBC. Microsoft provides a number of class hierarchies encapsulating the ODBC API, including Remote Data Objects (RDO), ActiveX Data Objects (ADO), OLE DB, and Remote Data Service (RDS; formerly known as the Advanced Data Connector). Different tools suit different purposes. Still, as shown in Figure 24.3, all database access methods lead to ODBC.
NOTE: With its Universal Data Access initiative, Microsoft is trying to correct the assumption that every persistent data store is a relational database. ADO, OLE DB, and RDS are all designed for Universal Data Access, although, of course, they work quite well with relational databases.
MTS provides two important functions beyond basic database access: distributed transaction support and database connection pooling. The ODBC 3.0 Driver Manager plays an important role in both functions. ODBC has always used a driver manager; with MTS it takes on new responsibilities. Figure 24.4 shows how the ODBC Driver Manager fits between an application and an ODBC driver.
FIG. 24.3
All data access methods from MTS lead to ODBC, including Remote Data Service (RDS),
ActiveX Data Objects (ADO), Remote Data Objects (RDO), or OLE DB.
FIG. 24.4
The ODBC Driver Manager loads ODBC drivers on behalf of an application (such as an
MTS component). In MTS, it also supports connection pooling and transaction enlistment.
NOTE: The ODBC 3.0 Driver Manager DLL is installed with Transaction Server.
To support distributed transactions from MTS, an ODBC driver must meet three requirements:
CAUTION: Thread safety is uncommon and thread affinity is common among popular ODBC drivers. These problems can manifest as a memory-access violation in the mtx.exe process from within the driver when the ODBC Driver Manager begins to close inactive connections.
For database access from an MTS component, choose ADO or RDO. Direct ODBC seems to offer efficiency (by eliminating an intermediate layer), but in most cases developers end up implementing their own class hierarchy. A lot of focused effort went into the development of ADO and RDO; it makes sense to use what's there. OLE DB is another low-level interface for access to any tabular (rows and columns) data source; ADO encapsulates access to OLE DB and is usually a better choice.
Microsoft introduced RDO with Visual Basic 4.0. RDO is a lightweight encapsulation of the ODBC API, designed specifically for access to a remote DBMS. With Visual Studio 97, Microsoft released RDO 2.0, a substantial revision. RDO 2.0 includes several features not available in ADO 1.0:
ADO encapsulates the OLE DB interface. Although not specifically designed for DBMS access, ADO can access relational databases, ISAM, text, hierarchical, or any tabular data source, as long as a data access provider exists. ODBC turns out to be an excellent data access provider. ADO is an Automation-based component, so any Automation-capable application or language can use it.
TIP: Microsoft is clearly encouraging developers to move from RDO to ADO. The company claims that future versions of ADO will provide a superset of RDO 2.0, a more sophisticated interface, and an easier programming model. ADO also supports web page data access via RDS.
Successful pooling of database connections in MTS requires attention to two details: connection state and security. Server-side connection state can cause side effects that are difficult to reproduce and eliminate. Connection pooling requires a trade-off between database security and application scalability.
Many database servers maintain a substantial amount of state for each connection. For example, an application might create a connection local temporary table (CREATE TABLE #MyTemporaryTable ...). If an MTS component creates a temporary table and doesn't drop it before releasing the connection, a subsequent component using the connection and trying to create or use the same temporary table might fail. Another pitfall is changing the current database (USE ThatDatabase); MTS can't detect this context change and will reuse the connection as though the original database were still current. Many servers also maintain connection local system variables (such as @@rowcount).
Shared database connections require a trade-off between security and scalability. The user account is an inherent attribute of a connection and can't be changed. Using multiple accounts for ODBC connections will effectively prevent reuse. One approach might be to have users enter a valid account and log in from the base client, but use a common account within MTS. This approach provides user authentication but doesn't enforce access polices. This limitation can be overcome by defining user roles for an MTS component.
SQL Server has included support for the 2PC protocol in the past. Application programmers using the C/C++ programming languages could access 2PC functionality by using the DB-Library interface provided by Microsoft for developing SQL Server applications. Procedures were provided on servers that allowed them to take on the role of commit coordinator.
The inclusion of DTC in MTS adds important new components to help implement distributed transactions and make the management of 2PC a more practical undertaking. Each server has a full DTC service that coordinates transactions with other servers. By using the DTC, a server can take on the role of commit coordinator for certain transactions. Also, the DTC can help resolve problem (or in-doubt) transactions by communicating with other DTC services that run on other servers involved in a transaction.
A client-side interface to DTC is available for Windows NT and Windows 95 computers. This interface allows developers to create applications using distributed transactions and leverage the facilities provided by the full DTC service running on SQL Servers. The client components of DTC don't include a full DTC service, even on Windows NT clients. Also, the DTC client is available only for 32-bit versions of Windows (Windows 95 and Windows NT).
TIP: A stored procedure running on a SQL Server can possibly launch a distributed transaction on behalf of a 16-bit client. Therefore, older Windows clients can still benefit from DTC functionality.
Also, a set of management utilities has been added to the Microsoft Transaction Server Explorer (MTX) and the SQL Enterprise Manager (a pair of administrative utilities). The utilities include graphical tools that allow you to dynamically monitor the state of transactions on servers running the DTC service. You can open multiple windows to monitor transactions occurring on multiple servers from a single workstation. An administrator also can manually resolve problem transactions arising from equipment or application failure.
Most developers prefer the use of MTX, although database-centric developers find the SQL Enterprise Manager to be very useful as well. There's overlapping functionality between these two tools.
Many application developers haven't seen much need for administrative utilities in the past. The MTX is an exception--it's designed specifically to configure the MTS application environment, as well as make specific settings for your application components. It's used far more often by a lead developer than by a network administrator in typical enterprise network environments, although there are clear benefits if these two groups coordinate with one another.
NOTE: Although SQL Enterprise Manager can be run on Windows 95, the DTC utilities are available only when using SQL Enterprise Manager on a Windows NT computer.
The DTC server components are installed automatically when you set up SQL Server 6.5 or upgrade SQL Server 6.0 to version 6.5. They're also installed when you set up Microsoft Transaction Server. You can start the DTC service just like any other service: by using the Control Panel on the local computer or by using the Services dialog box in the Server Manager utility provided with Windows NT Server. You also can start the service by using SQL Service Manager, SQL Enterprise Manager, or MTX.
The rest of this section focuses on the DTC capabilities added to SQL Enterprise Manager. This administrative tool has been enhanced with functionality to completely monitor and manage DTC capabilities.
The DTC Configuration dialog box allows you to control the behavior of the DTC service. You can configure parameters that affect viewing transactions in the Transactions window, the tracing information sent to the Trace window, and the location and size of the DTC log file. To configure the DTC service, follow these steps:
FIG. 24.5
Use this dialog box to configure the displays that monitor the Distributed Transaction
Coordinator service and its behavior.
To view the status of active transactions, follow these steps:
TIP: You can select another server and open a transactions window for it as well. You can monitor transactions on a number of servers simultaneously by using tiled or cascaded windows.
CAUTION: You shouldn't manually force transactions until you thoroughly understand the interaction of all members of a DTC system. Review the Guide to Microsoft Distributed Transaction Coordinator carefully before using this utility to resolve transactions.
FIG. 24.6
A DTC Transactions window for the server HQSRV1 that has three active transactions
and one preparing to commit.
FIG. 24.7
In the Transactions window, you can monitor transaction states and manually resolve
in-doubt transactions.
To view the traces being sent (at the level you configured DTC to provide), follow these steps:
TIP: You can select another server and open a Traces window for it also. You can monitor traces from a number of servers simultaneously by using tiled or cascaded windows.
A DTC service maintains statistical information about its performance. To view the statistics that have accumulated for a DTC service, follow these steps:
FIG. 24.8
A DTC Statistics window for the server HQSRV2.
NOTE: The statistics for a DTC service are cleared and restarted whenever the DTC service is stopped and restarted.
Microsoft Transaction Server 1.0, released in January 1997, builds on the functionality offered by DTC. MTS 2.0 is now available as part of the Windows NT Option Pack and is included as a standard part of Windows NT Server 4.0 Enterprise Edition.
MTS 2.0 provides a COM-based programming model with a relatively simple Application Programming Interface (API) that makes it easy for developers to create powerful, distributed applications. Applications are created largely as though they were designed for a single user to execute on a desktop computer. With minor additions, these applications can be invoked in a Transaction Server environment. Transaction Server provides all the needed additional capabilities to make the application multiuser and leverages DTC to provide distributed transaction processing. Transaction Server therefore forms the basis for a powerful three-tiered distributed computing architecture.
Figure 24.9 shows a simple example of the way an MTS environment might be set up. Desktop PC clients might be so-called "fat" Win32 systems (running Windows 95 or Windows NT) or "thin" clients running a web browser.
Although the example in Figure 24.9 describes three tiers, nothing inherent in the design of MTS limits it to this structure. You can break a computing system into more than three logical tiers, and MTS's design makes implementing various system architectures, including multi-tiered designs, straightforward. The three-tiered model is natural in some respects and is starting to be widely used, but need not be the only deployment alternative with MTS.
FIG. 24.9
This sample MTS environment shows various elements of a three-tiered architecture.
NOTE: The operating systems and applications installed on PCs have become much larger as they've grown in sophistication. With the advent of the HTTP-based web browser, application developers started exploring the capability of using this relatively "thin" tool as the basis for server-based applications. The traditional application architecture with its executable files and dynamic link libraries (DLLs) has been characterized as "fat" because of the amount of information (programs, configuration files, and data) that must be stored on the client.Browsers (from Netscape, Microsoft, and others) continue to get "fatter" as more features are added, however. Also, browser-based applications haven't yet reached the level of performance and sophistication offered by the more traditional Win32 client. It remains to be seen how fat the thin client will need to become to match the functionality offered by Win32 clients.
The next few sections provide an introduction to Transaction Server. You get a quick tour of MTS in action and review the product's features.
Transaction Server is used to deploy mid-tier logic implemented in the form of ActiveX components. These objects receive requests from clients, apply some sort of logic (for example, business rules) to the requests, and then call on appropriate resource managers to resolve the requests. The ActiveX components can be written with a variety of languages, including those listed in Table 24.1 later in the section "Packages of Components." These components can be developed in-house or purchased from third-party software vendors.
After these components are written or acquired, they're combined to form packages that you can deploy as a unit sharing resources (for example, memory) and security settings. MTS also manages a shared pool of ODBC data connections to various data providers, which can be traditional database servers or files on a mainframe. The packages are then deployed, usually on Windows NT servers, to act as intermediaries for clients wanting to access shared resources.
Because of MTS's capability to manage links among many clients accessing many resource managers (for example, databases) while applying application logic, the application architecture you can create with these building blocks has some very desirable characteristics:
Much of the distributed nature of the MTS product comes as a direct result of the use of the Component Object Model (COM) and Distributed Component Object Model (DCOM) as the basis for MTS component building. Chapter 4, "Using Microsoft's Object Technologies," provides a thorough introduction to these technologies.
After you purchase off-the-shelf components, write your own, or both, you can create collections of components called packages. The programming techniques required for creating these components are described in the Chapter 25, "Using Microsoft Transaction Server to Enable Distributed Applications."
You can manage a package of components as a unit. The components in the package can share security settings and can access other shared resources through the use of MTS's Shared Property Manager (SPM). They also can share a pool of ODBC connections to database resources. Allocating memory and processing on a one-to-one basis with clients becomes inefficient when handling large numbers of clients. A shared pool is more efficient and scales better as the number of clients grows.
When access to distributed database resources is required, the services of Microsoft's DTC (described earlier in this chapter) are used to efficiently provide a message-based architecture that can maintain the atomic nature of transactions across machine boundaries. Communications with database resource dispensers are handled by using various protocols:
The MTS development environment provides a very flexible programming environment. As already noted, the focus of most developers is on creating components designed for single-user environments without regard for distributed applications issues. They can work in various languages, including those listed in Table 24.1.
| Language | Manufacturer |
| Delphi | Borland |
| C++Builder | Borland |
| Visual Basic | Microsoft |
| Visual C++ | Microsoft |
| Visual J++ | Microsoft |
| PowerBuilder | PowerSoft |
After components are created, they're packaged to facilitate setting security and deploying on a particular machine. Packages can be managed effectively by using the Transaction Server Explorer. You can even split a package for deployment across server boundaries by partitioning the package for multiple-machine installation. The following section describes the use of Transaction Server Explorer.
Microsoft Transaction Server Explorer (MTX) is the tool used to package components and then deploy the packages. This administrative console is a graphics utility that lets you manipulate and control the components that build a multitiered MTS architecture. In addition to these component-based activities, you also can use Transaction Server Explorer to start and stop the DTC, change the service account settings, or perform other administrative tasks.
The MTX included with MTS 2.0 is one of the first tools delivered by Microsoft that makes use of Microsoft's new administrative tool known as the Microsoft Management Console (MMC). Specific tools are created as snap-ins, which are actually just ActiveX controls written according to specific guidelines.
ON THE WEB:You can download a paper describing the MMC and its extensibility from Microsoft's web site at http://www.microsoft.com/msdn/sdk/techinfo/default.htm.
To use MTX, follow these steps:
FIG. 24.10
The Transaction Server Explorer with My Computer selected in the left pane and the
contents of My Computer in the right pane.
TIP: Right-clicking an object generally opens a context-sensitive menu with choices pertinent to the object selected.
FIG. 24.11
ActiveX components created with a variety of languages can be integrated into a single
package for deployment on this computer, or to be exported to other machines.
After you create a package that includes the appropriate components, you need to set various properties to control the package's behavior. There are properties for the package as a whole, and properties that pertain only to a particular component within the package. To set package and component properties, follow these steps:
FIG. 24.12
The Security tab allows you to set more stringent authorization requirements for
components in this package.
The four choices for transaction support bear further discussion. After you break up your application into component parts, you need to control their participation in transactions. To achieve the highest level of reusability and flexibility, these decisions aren't made when the code is being written, but when the components are deployed with MTX.
FIG. 24.13
Use the Properties dialog box for an individual component to control transactional
behavior.
If a component is flagged as Requires a Transaction, it will automatically be executed within a transaction at runtime. If it's called by another component that has already begun a transaction, it will participate in that same transaction. If it's executed on its own outside the scope of any other transactions, a new transaction is created to ensure that the work done by this component is completed or rolled back.
A component that Requires a New Transaction always spawns its own transactional boundaries. A situation that might call for such behavior can be a component that writes audit information to a log. In such a case, you might want the work of this component to be durable, even if the work of a calling component must be rolled back.
A component that Supports Transactions can go either way with respect to transactional behavior. If it's called within a transaction, it participates. If the calling process isn't using a transaction, no transaction is started by this component. This varies from the previous two choices in that it's possible for this component to execute outside transactional boundaries--something that never happens with the first two choices.
The final choice, Does Not Support Transactions, is used primarily in cases where the underlying work being done is simply not transactional in nature. Some actions can't be rolled back, and some resources might be required that were never designed to support transactional behavior. These can still be used in a component, but without the benefit of transactional integrity.
Another important operation you perform with MTX is to configure role-based security. The need for this type of security is easy to understand when you reflect on an environment where many clients are sharing mid-tier business logic. If you want to control access to these components or the behavior of the components depending on the calling process, role-based security becomes an obvious choice.
To establish roles for a package, follow these steps:
FIG. 24.14
Role-based security is a powerful feature of MTS that has been used in large mainframe-based
systems for years.
A common practice--recommended by Microsoft for most situations--is to create a few standard roles and then assign groups from a Windows NT domain to those roles. For example, if you have a Consultant Billing application, you might create a group called Consultant Billing Admins and another called Consultant Billing Users. This could be done by a network administrator with User Manager for Domains rights or another equivalent method. Then, by using MTX, a lead developer for the application could create roles for the application called Admin and User following the preceding steps.
After you assign the Consultant Billing Admins group to the Admin role and the Consultant Billing Users group to the Users role, it becomes very easy to control access to particular functionality within the application. Users assigned administrative responsibility for the application are simply added to the Windows NT group Consultant Billing Admins. Any code within the component restricted to the Admin role is available only to this group of people.
Microsoft plans to continue evolving MTS into the future, where it will become a key component of multimachine architectures. Microsoft has publicly announced plans to add data- dependent message routing (useful in partitioning large applications) and durable queues, which would maintain the queue of messages even in the event of catastrophic failure. These and other features will likely be delivered by, or derived from, the Microsoft Message Queue (MSMQ) Server (code-named Falcon). It will be interesting to see how these technologies are combined to extend and improve the powerful features already included in the current release of MTS.
In this chapter, you learned about distributed database applications. You also learned about a component included in MTS and SQL Server, the Distributed Transaction Coordinator, which simplifies the process of managing distributed transactions. The various tools for monitoring the status of distributed transactions and resolving problem transactions were described. You also were introduced to Microsoft Transaction Server, a powerful tool for implementing multiuser, distributed applications.
See the following chapters for related information:
© Copyright, Macmillan Computer Publishing. All rights reserved.