Microsoft Corporation
Microsoft Transaction Server Overview
Microsoft Transaction Server Benefits
Microsoft Transaction Server Features at a Glance
A Quick Tour through Microsoft Transaction Server
Easier Application-Server Development
Mainframe-Class Reliability
More Development Choices
Easier Management
Microsoft Transaction Server Product Comparison
Suggested Reading
The growth of the Internet and distributed computing will increase the demand for businesses to deploy solutions on servers. The Internet has grown into a widely used environment for publishing and sharing information online. Businesses can achieve an even greater return on their online systems by moving beyond document sharing to running actual business functions online. Instead of simply publishing sales reports and product catalogs, businesses can operate accounting systems and order-entry systems on servers, with users accessing the shared business functions from browsers and desktop systems. This new environment of online solutions will require shared business applications running on servers.
Historically, there has been a problem with this vision. Building and deploying shared applications running on servers is much harder than on desktop systems. Server applications require a sophisticated infrastructure that is costly to develop and difficult to maintain. Server applications need to be more reliable than desktop applications, because the impact of system failure or data corruption on a server can effect an entire business, not just a single user. Server applications need to be as easy to deploy and maintain as desktop applications, without requiring special training or a costly infrastructure.
To solve these problems, Microsoft has developed the Microsoft® Transaction Server (MTS); a product that combines the flexibility and low cost of desktop applications with the mission-critical transaction-processing features normally found in high-end mainframe systems. Microsoft Transaction Server is a component-based transaction processing system for developing, deploying, and managing high performance, scalable, and robust enterprise, Internet, and intranet server applications. MTS defines an application-programming model for developing distributed, component-based applications. It also provides a run-time infrastructure for deploying and managing these applications.
Microsoft Transaction Server provides the easiest way to run scalable, robust applications on the Microsoft Windows NT® Server operating system:
By integrating component software with a transaction-processing infrastructure, Microsoft Transaction Server eliminates the problems inherent in building and deploying server solutions.
Building and deploying a networked server solution is no easy task. Implementing the actual business function (or example, handling orders for an online bookstore) is actually a small fraction of the work involved. A scalable solution also requires plumbing, the sophisticated application infrastructure that enables the business function to be shared by a large number of users. Server plumbing includes:
Building server plumbing into an application is expensive. Independent software vendors (ISVs) estimate that server plumbing consumes 30 to 40 percent of their development costs. This applies across a broad spectrum of applications, from large warehouse management applications to small systems used for managing a doctor's office.
The importance of data integrity and system reliability increases as more users access a shared system. Businesses simply cannot afford to lose information or corrupt business processes in the event of a system or software failure. Since these problems become harder to solve in a distributed environment, businesses have been willing to pay a premium, using proprietary, high-end technologies to make sure that their solutions are designed to operate under mission-critical situations.
Microsoft Transaction Server solves these problems, and this Reviewer's Guide is designed to efficiently help the reader understand how. The Reviewer's Guide is divided into the following sections:
This section of the Reviewer's Guide contains a quick overview of MTS benefits and the features that deliver them. Each of these features is explored in more depth later in the Guide.
Microsoft Transaction Server delivers a series of plumbing features to drive down the complexity and cost of building applications on the server. These features enable developers to focus on building business logic without having to build an application infrastructure. The result is shorter development time, less complex programming, and easier deployment and integration.
Easier development only solves part of the problem that businesses will face with online server applications. Applications need to run reliably and recover from failures accurately. Otherwise, records can be corrupted and business disrupted. The type of reliability and transaction processing features that have been running on mainframe applications for twenty-five years are essential for the new generation of online application servers. Transactions are to application servers what brakes are to cars.
Easier development and mainframe-class reliability have limited benefits if businesses are forced to deploy the applications in rigid, static configurations. MTS is designed for flexibility, providing businesses with many deployment choices based on their current systems and continuously changing requirements.
Businesses have learned that the costs of deploying and managing a distributed application can far exceed the costs of developing and acquiring it. MTS has been designed from the ground up to lower the costs and complexity of distributed applications by providing easier management.
Table 1 provides a brief list of features in Microsoft Transaction Server.
Table 1. Microsoft Transaction Server—Features At A Glance
| Feature | Description |
| Easier Application Server Development | |
| Accessible three-tier application model |
|
| ActiveX support |
|
| Two new APIs and two new interfaces |
|
| Automatic thread and process management |
|
| Object instance management |
|
| Component packaging |
|
| Database connection pool |
|
| Shared Property Manager |
|
| Sample applications as learning tools |
|
| Mainframe-Class Reliability | |
| Automatic transactions through DTC |
|
| Process isolation |
|
| Distributed security service |
|
| More Deployment Choices | |
| Integration with DCOM |
|
| Integration with Microsoft Internet Information Server |
|
| Support for multiple databases and resource managers |
|
| Integration with Microsoft SQL Server |
|
| "Fat" and "thin" client support |
|
| No client footprint |
|
| Dynamic configuration |
|
| Easier Management | |
| Transaction Server Explorer |
|
In this section of the Reviewer's Guide, the reviewer will install Microsoft Transaction Server and run two sample applications. This will provide a first-hand example of the easy configuration and management features of MTS.
Before you install Microsoft Transaction Server, make sure that your computer meets the minimum requirements. For the latest information on supported platforms and hardware and software requirements, see the readme.hlp file in the root directory of the Setup disc.
To run Microsoft Transaction Server, you must meet certain hardware requirements, which include:
Before you install Microsoft Transaction Server, you must install Microsoft Windows NT version 4.0 on your computer. See the readme.hlp file for the latest information on other platforms.
To set up from disc:
Important To install the sample applications that you will use for validating your Microsoft Transaction Server installation, you must choose to install the files for Microsoft Transaction Server Development during setup.
When you run the Setup program, it creates a folder for Transaction Server, \MTx.
MTS includes a sample bank application that demonstrates many of the product features, including:
Sample Bank is a three-tiered application, where a form built with Visual Basic invokes middle-tier components that perform bank credits and debits against a SQL Server database. The middle-tier components are run in MTS. MTS manages the server plumbing, including threads, object instances, transactions, and database connections. Sample Bank has a very simple design, and installs in minutes, but displays many features normally associated with high-end business applications.
Figure 1. Bank
The reviewer can use the following steps to install and operate the sample bank:
To install the Sample Bank package:
This Sample Bank package includes several components.
To monitor the Sample Bank package components and transactions:
To configure the ODBC data source:
The Bank application consists of four components:
Figure 2. Bank Architecture
The client initiates a bank transaction by invoking MoveMoney. MoveMoney invokes an Account component for each database that it needs to modify. MoveMoney also invokes the Receipt component for each bank transaction. MTS makes sure that the work of all these components executes as a single unit (or transaction), even though these are different components that could be written in different languages. Each one of these components is built as a simple, single-user ActiveX component yet executes as "multiuser" through MTS thread and process management services. Finally, the Account Components are accessing the SQL Server database via MTS ODBC resource dispensers, a mechanism for high-performance database access.
This is an example of a simple application getting all of the benefits of a sophisticated, high-end server infrastructure—including transactions, location transparency, thread and process management, and database connection pooling—through integration with MTS.
Hockey is a distributed, multiuser game that uses MTS features without requiring transactions. The application includes a component that uses MTS for thread management and to manage a shared game state across multiple users.
Figure 3. Hockey
Steps for installing hockey include:
To create the package:
To import the Hockey server component:
After you start playing the game, go back to the Transaction Server Explorer. Notice that the Hockey server component icon is now "spinning" indicating that it is activated and that your Microsoft Transaction Server installation is correct. If you stop the game, the icon stops spinning because the Hockey client is no longer using the Hockey server component.
If you click the Status command on the View menu, you can see usage information about the Hockey component.
Figure 4. Viewing Hockey Component in Explorer
Hockey is a simple application consisting of three components:
Figure 5. Hockey Architecture
Each player invokes a HockeyServer component. Each HockeyServer component stores game state, including puck and player location, in the Shared Property Manager.
There can be up to four players playing together in a single game, and there is no limit on the number of games being played on MTS.
This is a simple example of a server application relying upon MTS to manage low-level system resources across multiple users. It demonstrates the location transparency of MTS, thread and process management, high performance across a network, and the Explorer administration tool.
Two transitions are taking place that will drive demand for server-solution technology:
Table 2. Examples of Internet Publishing Applications Migrating to Online Applications
| Internet Publishing Application | Online Application |
| Human Resources Handbook | Human Resources Benefits Management |
| Real Estate advertising | Appointment scheduling |
| Events calendar | Online ticketing |
| Hard Goods catalog | Order capture and fulfillment |
| Advertising-sponsored content | Fee-based content (micropayments) |
| Flight schedules | Reservations and ticketing |
| Mutual Fund advertising, Prospectus | Portfolio management |
Businesses that want to transition their use of the Web from publishing information to running online applications encounter barriers that make it difficult to do so on a wide-scale basis. These barriers include:
Active Server describes Microsoft's 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 will lower the skill set and cost requirements for solutions in the distributed world of Internet and intranet servers.
Microsoft Transaction Server is a key Active Server technology, lowering the cost and complexity for deploying component solutions on the server. Throughout the Reviewer's Guide, we will illustrate how MTS addresses the barriers that prevent the wide-scale deployment of solutions on the server.
To better evaluate the plumbing services provided by MTS, it is helpful to first understand the anatomy of a server application. The diagram below shows the basic components of a server application:
Figure 6. Anatomy of a generic server solution
A server application must include:
The mission of Microsoft Transaction Server is to provide solution developers with all of the following application infrastructure services: receiver, queue, connections, context, security, thread pool, synchronization, management, and configuration, so that developers only have to concentrate on client logic, server logic, and setting up the database. This significantly lowers the cost and complexity of deploying server applications.
Businesses and software companies are turning to a three-tiered application model for distributed solutions. In a three-tiered application, business-process logic is separated from presentation services and data services.
The appeal behind three-tiered solutions lies in the belief that businesses can achieve faster development, lower deployment costs, and increased flexibility when applications are neatly partitioned, as opposed to monolithic and client/server designs, where presentation, logic, and data services are tightly dependent on each other.
Figure 7. Evolution of distributed application models from monolithic to three-tiered
To date, three-tiered applications have been the domain of high-end tools and deployment environments. These products are expensive and have failed to achieve mass-market support.
The Microsoft Transaction Server provides an accessible, built-in architecture for three-tiered applications on Windows NT Server. MTS is a middle-tier platform for running multiuser business logic.
Figure 8. MTS architecture
As a middle-tier platform, MTS provides an architecture for solutions on the server that connect users to databases. The basic architecture of MTS consists of:
MTS provides the plumbing, while developers build the business logic. This is the first step in making application server development easier.
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.
Figure. 9 Products for ActiveX support
Developers can use Microsoft Visual Basic, Microsoft Visual C++, and Microsoft Visual J++.
Since ActiveX is a language-neutral technology supported by most major development tool vendors, developers can use popular third-party products to build MTS 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 of the MTS 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 ORBs and TP monitor applications. All MTS plumbing features are available for developers building in Java. In a sense, MTS is the industry's first transaction processing monitor for Java.
ActiveX on the desktop today represents the software industry's best example of component reuse and rapid development through standards. There is a $240 million market for prebuilt ActiveX software components that developers use in their solutions. MTS's support for ActiveX will extend this type of developer leverage onto the server.
Most existing application server products and development environments require mastery of a complicated set of programming interfaces. This represents both a significant up-front training investment and a significant ramp-up time before developers become productive. Programming complexity is one of the reasons that ORBs and TP monitors have been slow to achieve mass-market acceptance.
Microsoft Transaction Server leverages existing ActiveX programming interfaces, familiar to desktop developers, in order to lower training costs and shorten ramp-up time.
MTS has only two new APIs, GetObjectContext and SafeRef. Most MTS applications can be built using just one new API and one new interface.
Reviewers can refer to the Microsoft Transaction Server Programmers Guide for more information in this area.
Solutions running on servers require a sophisticated application infrastructure to support increasing numbers of concurrent clients. An example of this mechanism is threading, a low-level Windows NT service that enables multiple concurrent users to share a single operating system process.
To date, developers have had to hand-code the creation and termination of threads into their application in order to enable a large number of concurrent users to share a server application. Allocating a 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 problem requiring sophisticated programming to address issues like deadlocks, starvation, and race conditions. These low-level, complex problems 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 "server plumbing" that can consume 30 to 40 percent of a development project. It diverts development resources from building additional functionality into a solution and it increases the support complexity of the solution after it has been deployed.
Microsoft Transaction Server provides an automatic thread pool to components. 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.
ActiveX uses an object-oriented infrastructure called 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. MTS 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, an MTS 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 MTS 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.
This ability for an object to be deactivated and reactivated while clients hold references to it is referred to as just-in-time activation. 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.
Object instance management and just-in-time activation enables MTS applications to scale better than most component applications built with traditional object-oriented infrastructure approaches, including ORBs.
Assembling different software components into a single solution can present configuration and deployment problems, including:
Microsoft Transaction Server introduces the concept of component packages to enable the easy integration of different software components into a single application. Components in a package:
Figure 10. Packages enable components to be grouped and distributed as a single unit.
Packages increase application flexibility. An entire application can be deployed in a single package, and then partitioned into multiple packages in order to achieve a higher degree of:
Integrating a relational database with a multiuser application presents development challenges:
As mentioned earlier, MTS includes resource dispensers, which make it easier for a developer to share system resources across multiple, concurrent application components.
Figure 11. Resource dispensers provide a pool of database connections for high performance and easier programming.
Microsoft Transaction Server includes a resource dispenser that provides 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 main memory. Scenarios for this type of function can 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.
In order for developers to quickly learn how to build server solutions, Microsoft Transaction Server includes two sample applications: Bank and Hockey.
Sample Bank is a simple transactional database application that demonstrates how to use Microsoft Transaction Server APIs.
Figure 12. Bank
Hockey is a simple multiuser game that shows nontransactional components managing a shared state.
Figure 13. Hockey
Over the last ten years, businesses have grown accustomed to application development backlogs that can range from a 12 to 18 months to deploy mission-critical client/server applications.
The typical project begins with an end-user department in an organization needing a new solution. For example, a sales department needs a new order entry system.
Unless the department has the funding or wherewithal to deploy the application themselves, they rely upon the central Information Technology (IT) organization to build/buy and deliver the solution. The IT department, which is responsible for information as a corporate asset, needs to deploy the solution carefully so that it meets user requirements and protects the integrity of business processes. Lengthy deployment cycles can be costly, but recovering from system failures can be even more costly. This takes time. The end-user department—the Information Technology department's customer—is a "captive" audience, patiently waiting for the new solution.
The growth of the Internet will change this cycle. Most businesses that operate an Internet or intranet site today use it for information publishing. They have learned that deploying a Web site requires more than a one-time cost. The constant pull for new material on the Internet forces businesses to update the information content of their Web sites on a weekly, daily, or even hourly basis. The need to frequently update Web systems will remain constant, even as businesses migrate their use of the Web from publishing information to running online solutions. As online systems migrate to the Web, IT customers will begin to transition beyond internal audiences—end-user departments—to a broader set of external customers. These external customers will not be captive in the same manner as internal audiences. There will be many alternative solutions on the Web. IT competition is literally a mouse-click away, as different companies compete for customers in a given market by using online business applications projected onto the Internet. This will force IT to change the way it builds online solutions.
Online applications will require a combination of Rapid Application Development (RAD) and Reliability, Availability, and Serviceability (RAS). To date, IT managers had only two choices:
—or—
Microsoft Transaction Server is the first technology to integrate RAD with mission critical integrity.
Microsoft Transaction Server is integrated with the MS DTC, a general purpose distributed transaction manager. MS DTC was first released as part of Microsoft SQL Server 6.5 and 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 with the following properties:
These properties are sometimes known by their acronym, ACID.
To users, a transaction is a single event that either happens or doesn't happen. To developers, a transaction allows them to write components that can participate in distributed environments.
Transactions are an essential tool for building online server applications from component software.
Building solutions from components—a requirement for rapid development and lower development costs—presents challenges in enforcing reliability and solution integrity.
To date, most business solutions are developed as a monolithic application by a team. The team members all work in the same department or for the same ISV. It is relatively easy for them to integrate the ACID properties into an application because they have a common design and can test through all of the different failure scenarios together.
But as companies turn to component development, it will become increasingly costly to test and link various failure scenarios together. Solutions will be assembled from prebuilt components developed by different companies.
Figure 14. Example of an error in a component application
For example, consider a simple bank-funds transfer application assembled from three components—Transfer, Credit, and Debit—that are each built by a different developer:
Transfer begins work. Debit succeeds and subtracts $100 from a database. Credit fails because its computer crashed in the middle of work. Unless the developer of Transfer has programmed what to do if one of the components has failed, the application has just withdrawn $100 from a bank without putting it anyplace. The application is effectively destroying money, which is an example of achieving an incorrect business result!
Although this scenario may be easy to correct in a three-component application, a more typical online business application involving hundreds of components running across multiple servers will spawn an exponentially increasing number of potential error conditions for the developer to anticipate. A distributed transaction infrastructure is the only way to address these issues in a cost-effective manner.
Figure 15. Transactions tie the work of distributed components together.
MTS makes transaction management transparent to the component developer. Developers do not have to write begin or end transaction into their application code. They simply declare components to be transactional using the Transaction Server Explorer. 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. Since MTS is adding support for industry-standard transaction protocols, components that update databases on UNIX and mainframe systems can also participate in distributed component applications.
This is a major breakthrough in flexibility and ease of use when compared to previous generations of transaction processing systems.
Integrating software components purchased from third parties into an existing solution is an important requirement for fast time-to-market, but presents integrity challenges to the server developer.
Bugs in the new component may corrupt the existing solution. Testing is important, but it cannot always find all problems.
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 provides developers with a safe mechanism for rapidly integrating new software into existing solutions without compromising mission-critical integrity.
Figure 16. The same solution, with two deployment options
Microsoft Transaction Server provides a distributed security service for component-based solutions. This security service relies upon Windows NT security to authenticate users, and it maps on top of the Windows NT domain topology.
MTS provides two complimentary security models—declarative and programmatic.
Declarative security is automatic and is specified when components are added into a package, without forcing developers to program security code into their applications. Administrators declare which users and groups have access to different parts of a solution by using the Transaction Server Explorer. These users and groups can be mapped to existing Windows NT users and groups without having to code the 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:
MTS lets you declare that only employees in the human resources department can access view_payroll_table, and only managers can access change_payroll_table.
Programmatic security enables developers to code custom access control directly into their components.
Microsoft Transaction Server supports predefined security roles, which enables end users to rapidly integrate components from different ISVs into a solution with good security, without forcing programmers to hand-configure the security attributes of each component. Using security roles, ISVs define generic security groups at development time—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.
Business managers want to deploy solutions across a wide variety of environments without the cost of maintaining special implementations for each deployment configuration. For example, a business may want to deploy a customer management solution across:
This sort of deployment flexibility has been a problem for server applications because stand-alone and work-group solutions have lacked the server plumbing required to "scale up" to support enterprise workloads, and enterprise-class solutions—usually based on TP monitors—have lacked the small footprint required to "scale down" to support work-group and stand-alone configurations.
Microsoft Transaction Server enables flexible deployment of solutions across different types of business environments and different system configurations from a common code base.
Microsoft Transaction Server is integrated with 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 Windows operating 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 the Microsoft Internet Information Server (IIS), enabling businesses to easily project server solutions over the Internet and intranets.
IIS is the only Web server that:
IIS 3.0 introduces Active Server Pages, a technology that makes it easier to integrate server business solutions with HTML Web content. ASP enables Web content creators to:
Figure 17. IIS and Microsoft Transaction Server integration
HTML content deployed as Active Server Pages can invoke business components running in MTS. This extends MTS scalability and component flexibility to Internet applications, combining RAD and RAS for the Internet.
Microsoft Transaction Server has an open, flexible design that supports multiple types of resource managers for information storage and retrieval, including:
Figure 18. MTS integration with IIS
Any resource manager that supports a DTC transactional protocol will work as a MTS resource manager. MTS currently supports the OLE Transactions protocol. Additional planned support includes:
By providing open interfaces for multiple types of resource managers, MTS provides businesses with deployment flexibility and more options.
Although Microsoft Transaction Server supports an open design that can integrate with any type of information store, it works best with Microsoft SQL Server.
Microsoft SQL Server:
Microsoft SQL Server and Microsoft Transaction Server are integrated through common support for the OLE Transactions protocol, the fast native MTS transaction protocol, and common use of the Microsoft Distributed Transaction Coordinator.
Microsoft Transaction Server enables businesses to deploy solutions that support both "fat" Win32 clients and "thin" HTML clients at the same time, from the same server solution.
The "fat" versus "thin" client debate is an example of the type of technology issue that increases deployment risk for IT managers moving to distributed systems. There are strong arguments on both sides of this issue.
Microsoft Transaction Server provides the best server-solution development and deployment environment, working equally well with "fat" and "thin" clients.
A sample application that Microsoft uses to demonstrate Microsoft Transaction Server, the Adventure Works business solution, shows this capability, with both a Visual Basic client and an HTML client accessing the same functionality on a single server.
Figure 19. HTML and Win32 clients to the same MTS solution
Microsoft Transaction Server does not require any special software code running on the client system for either "fat" or "thin" client support.
This "footprintless" approach to client integration contrasts sharply with existing middleware products, which require client libraries or client nodes in order to provide integration with the desktop.
Microsoft Transaction Server enables businesses to partition solutions across servers, providing enhanced performance and scalability.
Figure 20. Solution running on a single server, and partitioned across two servers
For example, a customer management application might consist of components:
These components can be deployed in:
Businesses have discovered that potential cost savings in building solutions from components are often lost during deployment. MTS is designed to lower the cost and complexity of deploying and managing distributed applications built from components.
Microsoft Transaction Server includes the Transaction Server Explorer, a graphical management tool that makes it easier to deploy and manage solutions across a network.
Transaction Server Explorer provides developers and administrators with a complete view of all the components deployed within a solution.
Figure 21. Transaction Server Explorer
The Transaction Server Explorer includes point and click wizards for assembling and configuring a solution from prebuilt packages and components.
Microsoft Transaction Server includes a wizard to create packages.
Figure 22. Microsoft Transaction Server Package Wizard
MTS includes a wizard to add components to a package. The wizard either lists all components already registered in the system, or enables the administrator to register new components.
Figure 23. Component Wizard
Transaction Server Explorer includes a wizard that enables administrators to export a package to a remote server, dynamically adding servers to a distributed solution.
Administrators can remotely add client systems to a distributed solution.
Administrators and developers can set the transactional properties of components deployed within a package.
Figure 24. Transaction dialog box
Administrators can configure the security attributes of components and packages.
The Transaction Server Explorer includes a GUI utility for monitoring transaction status. Administrators can intervene and resolve transaction outcomes.
The Transaction Server Explorer includes a GUI utility for tracking transaction performance.
Figure 25. Transaction Statistics window
The Transaction Server Explorer includes a GUI utility for viewing trace messages.
It is difficult to conduct a comparison of MTS with other server application environments, because no other product combines MTS's integration of component software with transaction processing features.
Table 3 compares Microsoft Transaction Server with other technologies for deploying server solutions on Internet and Intranets, including Visigenics VisiOrb, Oracle's WebServer middleware product, and BEA System's Tuxedo Transaction Processing Monitor. This comparison is based on information published by the respective vendors on the current implementations of their products. An "X" indicates that the feature is supported by the product.
Table 3. Product Comparison
| Microsoft Transaction Server | Visigenics VisiOrb |
Oracle Web Server |
BEA Tuxedo |
|
| Easier Application Server Development | ||||
| Accessible three-tiered application model | X | X | X | X |
| Support for ActiveX on the server: | X | |||
|
X | X | X | X |
|
X | |||
|
X | X | X | X |
|
X | |||
|
X | |||
|
X | |||
| Simple programming interfaces with two APIs | X | |||
| Automatic thread and process management | X | |||
| Object instance management | X | |||
| Component packaging | X | |||
| Database connection pool | X | X | X | |
| Shared Property Manager | X | X | ||
| Sample applications as learning tools | X | |||
| Mainframe-Class Reliability | ||||
| Automatic transactions through DTC | X | program-matic | program-matic | |
| Process isolation | X | X | X | X |
| Distributed security service | X | X | ||
| More Deployment Choices | ||||
| Integration with DCOM | X | X | promised 1997 | |
| Integration with Microsoft Internet Information Server | X | X | ||
| Support for multiple databases and resource managers | X | X | ||
| Integration with Microsoft SQL Server | X | |||
| "Fat" and "thin" client support | X | X | X | X |
| No client footprint | X | |||
| Dynamic configuration | X | X | ||
| Easier Management | ||||
| Transaction Server Explorer, GUI tool to: | X | |||
|
X | |||
|
X | |||
|
X | |||
|
X | |||
|
X | |||
|
X | |||
|
X | X | ||
|
X | X | ||
|
X | X | ||
|
X |
In addition to the documentation included with Microsoft Transaction Server, you can also consult the following third-party books for more information about related technologies.
Transaction Processing: Concepts and Techniques
Jim Gray and Andreas Reuter
ISBN 1-55860-190-2
Morgan Kaufmann Publishers
340 Pine Street, Sixth Floor
San Francisco, CA 94104-3205 USA
(800) 745-7323 or (415) 392-2665
(415) 982-2665 fax
Shows how large, distributed heterogeneous computer systems can be made to work reliably. It explains how to apply transaction concepts to distributed systems and how to use them to build high-performance, high-availability applications with finite budgets and risk.
Principles of Transaction Processing for the Systems Professional
Philip A. Bernstein and Eric Newcomer
ISBN 1-55860-415-7
Morgan Kaufmann Publishers
340 Pine Street, Sixth Floor
San Francisco, CA 94104-3205 USA
(800) 745-7323 or (415) 392-2665
(415) 982-2665 fax
E-mail: orders@mkp.com
Web: http://www.mkp.com
Provides an understanding of the internals of transaction processing systems, how they work, and how best to use them. Includes the architecture of transaction processing monitors, transactional communications paradigms, and mechanisms for recovering from transaction and system failures.
For the latest information on Microsoft Transaction Server, check out the Microsoft Transaction Server Web site at http://www.microsoft.com/transaction/.
The information contained in this document represents the current view of Microsoft Corporation on the issues discussed as of the date of publication. Because Microsoft must respond to changing market conditions, it should not be interpreted to be a commitment on the part of Microsoft, and Microsoft cannot guarantee the accuracy of any information presented after the date of publication.
This article is for informational purposes only. MICROSOFT MAKES NO WARRANTIES, EXPRESS OR IMPLIED IN THIS DOCUMENT.