Microsoft Transaction Server (MTS) is a component-based model and run-time environment that simplifies the task of developing application components by allowing you to perform work by using transactions. These application components implement business rules and run from the middle tier in a three-tier application. For example, in the case of a bank, records in one or more database systems represent the durable state of the business, such as the amount of money in an account. The application components update that state to reflect changes, such as debits (increases) and credits (decreases).
Microsoft Transaction Server protects applications from anomalies caused by concurrent updates or system failures and maintains the ACID properties:
Transaction Server makes transaction management transparent to the component developer. Developers do not have to write begin or end transaction into their application code.
The intermediate states of a transaction aren't visible outside the transaction, and either all the work happens or none of it does. This allows you to develop application components as if each transaction executes sequentially and without regard to concurrency. This is a tremendous simplification for application developers.
You can declare that a component is transactional, in which case Transaction Server associates transactions with the component's objects. A component can participate in the transaction of the component calling it, enabling developers to coordinate the work of many components written in different languages and running on different systems as a single, atomic unit. When an object method is executed, the services that resource managers and resource dispensers (such as the ODBC resource dispenser to manage pools of database connections) perform on its behalf execute under a transaction. This can also include work that it performs for other Transaction Server objects. Work from multiple objects can be composed into a single atomic transaction.
Without transactions, error recovery is extremely difficult, especially when multiple objects update multiple databases. The possible combinations of failure modes are too great even to consider. Using transactions simplifies error recovery. Resource managers automatically undo the work of the transaction, and the application retries the entire business transaction.
Transactions also provide a simple concurrency model. You can rely on a transaction's isolation to prevent one client's work from interfering with another client's work. Microsoft Transaction Server allows you to write components as if there were only one client executing at a time.
Microsoft Transaction Server performs all of this essential management automatically. Writing applications as if they run in isolation reduces development time dramatically and allows programmers to concentrate on business functions. Transaction Server handles concurrency, resource pooling, security, context management, and other system-level complexities, insulating the programmer from these issues.
The basic architecture of Microsoft Transaction Server consists of:
Microsoft Transaction Server is a key Active Server technology. Active Server technology is a broad strategy to enable businesses to easily develop and deploy server solutions for the Internet and intranets. Just as the combination of Windows, Microsoft Office, and OLE development tools reduced the skill set and cost requirements for deploying solutions on the desktop, Active Server lowers the skill set and cost requirements for solutions in the distributed world of Internet and intranet servers. More than 80 vendors are supporting Microsoft Transaction Server including IBM, Sybase, and Informix. Microsoft Transaction Server can also handle cross-platform commits, such as commits between DB2 on OS/390 (MVS) and Microsoft SQL Server on Windows NT.
Microsoft Transaction Server application components—the business logic that runs on the server—can be written with any language that produces ActiveX DLLs. Developers and businesses that use these languages for desktop solutions can now use them for server solutions. Since ActiveX is a language-neutral technology supported by most major development tool vendors, developers can use popular third-party products to build Transaction Server applications. Major tools vendors planning support for Microsoft Transaction Server in 1997 include:
Microsoft Transaction Server support for Java is of particular interest to Internet programmers because all Transaction Server middle-tier services are provided to ActiveX components written in Java. This contrasts with other middleware approaches, where Java is used as a simple front end to back-end Object Request Brokers (ORBs) and TP monitor applications. All Transaction Server server functionality is available for developers building in Java. In a sense, Transaction Server is the industry's first transaction-processing monitor for Java.
A server application must include these basic components:
Solutions running on servers require a sophisticated application infrastructure to support increasing numbers of concurrent clients. Microsoft Transaction Server provides all necessary, automated services for easy management and development of transactions on Windows NT.
Automatic thread pool to components ensures that developers do not have to program thread management—the creation, allocation, and termination of system threads—into their solution. This enables easier scalability in a multiuser environment, while lowering the skill set required to build server solutions.
To date, developers have had to include the creation and termination of threads in an application to enable a large number of concurrent users to share a server application. Allocating one system thread per user can result in poor performance in a multiuser environment. Building a thread pool that shares system threads across users is a complex solution requiring sophisticated programming to address issues like deadlocks, starvation, and race conditions. These issues need to be addressed regardless of the developer's programming language, even if the developer is using Java.
This is a good example of the basic server functionality that can consume 30 to 40 percent of a development project. It diverts development resources from building advanced functionality into a solution, and it increases the support complexity of the solution after it has been deployed.
Object instance management and just-in-time activation—deactivating and reactivating an object while a client holds a reference to it—enable Transaction Server applications to scale more efficiently than most component applications built with traditional object-oriented infrastructure approaches, including ORBs. From the client's perspective, only a single instance of the object exists from the time the client creates it to the time it is finally released. In actuality, the object may be deactivated and reactivated many times. ActiveX uses an object-oriented infrastructure called Component Object Model (COM).
Applications consist of components that invoke services from other components. With basic COM objects, clients have control over object lifetimes—client references are bound to the same object instance for as long as the reference is held. Transaction Server extends the COM model with just-in-time activation, which gives component developers additional control over object lifetimes and allows server resources to be used more efficiently.
During method execution, a Transaction Server object can use either the SetComplete or SetAbort methods to indicate that the object does not need to maintain state after returning from the call. As a result, the Transaction Server Executive can deactivate the object after the method call returns. The object remains deactivated until the client makes another call to it. As long as the object is deactivated, only limited server resources need be allocated to it, namely those required to maintain the object context and its association with the client references. Other server resources, such as memory for the object's private data and database connections, do not need to remain allocated to the object and can be used for other purposes. Only when the object is subsequently called is it reactivated, at which time it can reacquire any resources that it needs to service the call.
Transaction Server includes several resource dispensers that make it easier for a developer to share system resources across multiple, concurrent application components, including one for a reusable pool of ODBC database connections. Application components make standard ODBC database calls. The ODBC resource dispenser transparently provides fast allocation of new connections from a shared pool, providing a significant performance improvement in a multiuser environment. The ODBC resource dispenser also simplifies the development of robust server applications by automatically including the work of components in transactions.
Many multiuser applications require common access to shared information stored in memory. Scenarios for this type of function include:
Programming applications that share information in memory across multiple concurrent users can create difficulties, including:
Microsoft Transaction Server includes a prebuilt resource dispenser called the Shared Property Manager. The Shared Property Manager enables multiple users to easily access shared global data without complex programming.
Microsoft Transaction Server is integrated with the Microsoft Distributed Transaction Coordinator (MS DTC), a general purpose, distributed transaction manager. MS DTC is included with Microsoft Transaction Server.
Most high-end mainframe systems use transactions as the basis for their application processing. Transactions provide a way to bundle a set of operations or events into a single unit of execution. A transaction is a collection of events that follow ACID properties—Atomicity, Consistency, Isolation, and Durability. To users, a transaction is a single event that either happens or doesn't happen. To developers, a transaction allows components to participate in distributed environments.
Microsoft Transaction Server enables multiple components to work together across different packages, with each package operating in its own protected address space in memory. This is critical when, for example, you are integrating a software component purchased from a third party into an existing solution. Bugs in the new component can corrupt the existing solution. Testing is important, but it cannot always find all problems.
Microsoft Transaction Server provides developers with a safe mechanism for rapidly integrating new software into existing solutions without compromising mission-critical integrity:
Microsoft Transaction Server provides a distributed security service for component-based solutions. This security service relies on Windows NT security to authenticate users, and it maps on top of the Windows NT domain topology.
Transaction Server provides two complimentary security models—declarative and programmatic.
Declarative security is automatic and is specified when components are added to a package. Administrators declare which users and groups have access to parts of a solution by using Transaction Server Explorer. These users and groups can be mapped to existing Windows NT users and groups without having to code security into each of the individual components. This enables solution-specific security, even for prebuilt components purchased from third parties.
For example, a human resources application has two methods:
Transaction Server lets you declare that only employees in the human resources department can access view_payroll_table, and only managers can access change_payroll_table.
To ensure security without impacting performance, Microsoft Transaction Server introduces the concept of a role and sets security only at the "front gate." The role is very similar to a group except that it only applies to that MTS server. Much like a group, you add users to the role. Components and even interfaces then use the roles to grant access. Roles are added to interfaces and/or components. Users in a role have access to the component or interface and those outside of the role do not.
MTS components always run as the same user. By default, this is the interactive user of the machine, but this can be set to any Windows NT account (user or group). When a client tries to access the component, MTS impersonates the client and performs an access-control list (ACL) check. An ACL is a compilation of access control elements (ACE) that specify a user and groups and their access permissions on that object; every user or group can be identified by a unique security identifier (SID). The ACL check either allows or denies access. MTS also gathers information about the client, such as the SID, so additional programmatic security can be made available. After this is accomplished, MTS stops impersonating the client. The component is instantiated and runs as the user specified in the package properties.
Programmatic security enables developers to code custom access control directly into their components.
Microsoft Transaction Server supports predefined security roles that enable end users to rapidly integrate components from different ISVs into a solution with good security, without having to configure the security attributes of each component. At development time, ISVs use security roles to define generic security groups, such as managers and administrators, that restrict access to the appropriate component methods and interfaces. Businesses then rapidly integrate components from different vendors into a solution, mapping predefined security roles to existing Windows NT groups.
Microsoft Transaction Server is integrated with the Distributed Component Object Model (DCOM) for component-to-component communications across a network.
DCOM is simply "COM with a longer wire," an evolution of the Component Object Model used in millions of Windows systems today. COM is the core object technology for ActiveX. DCOM is:
In addition to the Open Group initiative, both Software AG and Digital Equipment Corporation are in the process of licensing DCOM to non-Microsoft platforms, including most major implementations of UNIX. UNIX systems supporting DCOM can be clients to Microsoft Transaction Server applications.
Microsoft Transaction Server is tightly integrated with Microsoft Internet Information Server (IIS), enabling businesses to easily project server solutions over the Internet and intranets.
IIS is the only World Wide Web server that:
IIS version 3.0 introduces Active Server Pages, a technology that makes it easy to integrate server business solutions with HTML Web content. ActiveX server pages enable Web content creators to:
HTML content deployed as Active Server Pages can invoke business components running in Transaction Server. This extends Transaction Server scalability and component flexibility to Internet applications, combining "RAD" and "RAS" for the Internet.
Microsoft Transaction Server does not require additional software running on the client system for either "fat" or "thin" client support.
This approach to client integration contrasts sharply with existing middleware products that require client libraries or client nodes to provide integration with the desktop.
Microsoft Transaction Server enables businesses to partition solutions across servers, providing enhanced performance and scalability:
For example, a customer-management application might consist of the following components:
These components can be deployed in: