A Guide to Reviewing
Microsoft Transaction Server
Release 2.0—The Best Technology
for Developing and Deploying
Applications on Windows NT
Microsoft® Transaction Server Release version 2.0 (MTS) is an important feature of the Microsoft® Windows NT® operating system that simplifies the development and deployment of server-centric applications built using Microsoft Component Object Model (COM) technologies. MTS is ideal for developing line-of-business and electronic commerce applications with Web-based interfaces, leveraging powerful development tools such as the Microsoft® Visual Basic® programming system for scalable, three-tiered development, and building production-quality applications with distributed object technologies.
MTS 1.0 revolutionized the way that developers build server-centric applications by providing a true component-oriented run-time environment that eliminates writing infrastructure code. MTS 2.0 extends the environment by providing powerful integration with Microsoft Internet Information Server 4.0 (IIS), transactional connectivity to Oracle and DB2 databases, integration with Microsoft® Message Queue Server 1.0 (MSMQ), transactional mainframe connectivity via Microsoft® SNA Server 4.0 and the COM Transaction Integrator, and improved performance and manageability.
For the latest information on Microsoft Transaction Server, visit http://www.microsoft.com/com/tech/mts.asp .
The argument for three-tiered systems is deceptively simple: by partitioning applications cleanly into presentation, application logic, and data sections, the result will be enhanced scalability, reusability, security, and manageability. And, three-tiered approaches map well to a number of important application development challenges. Internet and intranet application developers need easy ways to use browsers as the presentation interfaces to line-of-business and electronic commerce applications.
Developers that use powerful programming tools such as Visual Basic and the Microsoft® Visual J++® Web development system to build two-tiered systems now want to build more scalable and flexible applications without having to completely change the way they write code. Designers of distributed component-based applications need ways to deploy and reuse objects anywhere in a network, from desktop machines to servers, without sacrificing security, scalability, or manageability. Yet, despite this nearly universal desire, most companies have made very little progress in harnessing the power of three-tiered, server-centric architectures.
Three-tiered architectures are often called server-centric, because they enable application logic to run on servers instead of on clients as in two-tiered applications. In fact, to deliver maximum benefit, three-tiered systems must run with presentation logic on desktop clients or browsers, application logic on middle-tiered servers, and data on dedicated database servers. This presents a number of challenges:
Complicating matters, companies frequently need to buy expensive and complex add-in software from third-party vendors to address these issues. This creates dependencies on third parties and makes developers integrate products from different vendors—increasing the development and maintenance costs of distributed applications. While these issues affect all software developers, add-in costs and dependencies are particularly relevant to independent software vendors (ISVs) who must minimize external costs and maintain control over product quality.
To meet the challenges, any solution must satisfy three technical requirements:
In addition to technology requirements, solutions must be cost-effective, reduce vendor dependency, and minimize the need for systems integration.
A Three-Tiered Application
Microsoft Transaction Server (MTS) Release 2.0 is an important feature of Windows NT that simplifies the development and deployment of server-centric applications built using Microsoft Component Object Model (COM) technologies. MTS is ideal for developing line-of-business and electronic commerce applications with Web-based interfaces, leveraging powerful development tools such as Visual Basic for scalable, three-tiered development, and building production-quality applications with distributed object technologies. MTS 2.0 is the best technology for building server-centric applications on Windows NT because:
MTS 1.0 revolutionized the way that developers build server-centric applications by providing a true component-oriented run-time environment that eliminates the need to write infrastructure code. MTS 2.0 now extends the environment by providing powerful integration with Microsoft Internet Information Server 4.0 (IIS), transactional connectivity to Oracle and DB2 databases, integration with Microsoft Message Queue Server 1.0 (MSMQ), transactional mainframe connectivity via Microsoft SNA Server 4.0 and the COM Transaction Integrator (COMTI), and improved performance and manageability.
Most important, MTS 2.0, IIS 4.0, MSMQ 1.0, and SNA Server 4.0 are available and integrated today, in contrast to the mixture of specifications, plans, and poorly integrated products available from other vendors.
Microsoft Transaction Server—Release 2.0 Features at a Glance
Feature | Description and Benefits |
Easy
Ease-of-Use | |
MTS Explorer Enhancements | The MTS 2.0 Explorer includes enhanced support for managing packages and ease-of-use enhancements such as support for multiple item selection. The MTS explorer can also manage IIS applications and components generated by SNA Server 4.0 as MTS packages. |
Microsoft Management Console Support | MTS 2.0 provides support for running the MTS Explorer management interface as a snap-in to the Microsoft Management Console (MMC). MMC integration provides users with a consolidated management environment with a consistent look and feel. |
Comprehensive
Automatic Client Installation Utility | MTS 2.0 provides a utility that simplifies and automates the process of configuring client machines that need to access MTS-based components running on a server. |
Comprehensive Functionality | |
Transactional ODBC Driver for Oracle and DB2 Databases | MTS 2.0 includes ODBC 3.0-compliant drivers for Oracle version 7.3 and later and IBM's DB2. ODBC 3.0 compliance enables developers to build MTS applications that access these databases (on any platform), along with access to other resources such as SQL Server and Microsoft® Message Queue Server, in transactional units of work for full data integrity protection. ODBC 3.0 compliance also lets MTS perform connection pooling of Oracle and DB2 database sessions for improved performance. |
Performance Enhancements | MTS 2.0 provides a multi-threaded class factory that reduces the time it takes for MTS to create and execute instances of server-based objects when requested by clients. MTS 2.0 also improves performance by reducing the number of steps that many internal operations require for execution. |
Windows NT Workstation and Windows 95 Support | MTS 2.0 supports operation on Windows NT Workstation and the Microsoft® Windows® 95 operating system to let companies deploy stand-alone versions of their MTS applications. |
Integrated
Integration with Windows NT Features and Microsoft Products | |
IIS Integration | Microsoft Internet Information Server (IIS) version 4.0 is integrated with MTS 2.0 and uses MTS for many run-time services such as transaction management. Transaction support lets IIS Active Server Pages access databases, mainframe applications, and message queues with full data integrity protection. MTS integration also provides IIS with process isolation to prevent individual failures from affecting other parts of a Web site, enhanced run-time services such as thread and connection pooling for better performance, and easier component management. |
MSMQ Integration | MTS 2.0 provides integration with Microsoft Message Queue Server (MSMQ). MSMQ integration lets MTS-based applications communicate in a reliable, loosely coupled fashion. MSMQ operations (such as send and receive) enlist in MTS transactions automatically for data integrity protection. |
Microsoft Transaction Server—Release 2.0 Features at a Glance | |
Feature | Description and Benefits |
Integration with Windows NT Features and Microsoft Products | |
SNA Server 4.0 Integration | MTS 2.0 can use Microsoft SNA Server 4.0 and the COM Transaction Integrator to include mainframe applications (for example, running under CICS) and their data in transactions managed by MTS. MTS-based applications can update one or more databases, send or receive messages with MSMQ, and invoke a mainframe application that updates data (for example, in VSAM), and all updates, including those on the mainframe, will commit or abort as a whole. Microsoft SNA Server 4.0 also makes it easy to generate COM-based interfaces to mainframe applications for simplified MTS programming. |
Support for Windows NT Clustering Services | MTS 2.0 supports operation on clustered Windows NT Servers. Clustering lets administrators configure MTS for automatic failover and fault-tolerant, high-availability operation. |
Microsoft Transaction Server—Complete Features at a Glance | |
Feature | Description and Benefits |
Ease-of-Use | |
Simplified Three-Tiered Application Development |
MTS completely separates three-tiered infrastructure from presentation and application logic. This lets MTS developers build their applications as a collection of single-user COM components and then deploy components in the appropriate tier. Components that run on middle-tiered servers automatically support multi-user operation. |
COM Component Support | MTS supports any tool that can produce COM DLLs, including Microsoft Visual Basic, Microsoft® Visual C++® development system, and Microsoft Visual J++. |
Simple Application Programming Interfaces | MTS developers have to learn only a simple set of APIs to deploy their components in the MTS run-time environment. Extensive knowledge of COM APIs and Microsoft® Win32® APIs is not required. |
Support for Component Packages |
MTS lets developers combine related components into packages. Packages provide an easy way to secure, manage, and deploy components as a group. |
MTS Explorer | The MTS Explorer is a GUI-based systems management console that makes it easy for administrators to create and manage packages, configure component properties such as security and transaction behavior, and monitor/manage operating servers. The MTS Explorer supports advanced ease-of-use features such as drag-and-drop editing and multiple item selection. |
Microsoft Management Console Support | The MTS Explorer management interface can run as a snap-in to the Microsoft Management Console (MMC). MMC integration provides users with a consolidated management environment with a consistent look and feel. |
Automatic Client Installation Utility | MTS provides a utility that simplifies and automates the process of configuring client machines that need to access MTS-based components running on a server. |
Comprehensive Functionality | |
Automatic Transaction Management |
MTS provides automatic transaction management services to components. Developers or administrators use simple property page interfaces to specify what level of transaction protection is required by a given component. At run time, MTS performs all required transaction management automatically. This dramatically simplifies development and facilitates component reuse. |
Database Connection Pooling |
MTS allocates connections to database resources from a pool. Components only require connections when they are active. This lowers the total number of database connections required to support clients, increasing database performance. |
Feature | Description and Benefits |
Comprehensive Functionality (Cont.) | |
Transactional ODBC Driver for Oracle and DB2 Databases | MTS includes an ODBC 3.0-compliant driver for Oracle version 7.3 and later and DB2. ODBC 3.0 compliance lets developers build MTS applications that access these databases (on any platform), along with access to other resources such as SQL Server and Microsoft Message Queue Server, in transactional units of work for full data integrity protection. ODBC 3.0 compliance also lets MTS perform connection pooling of Oracle and DB2 database sessions for improved performance. |
Support for Multiple Databases and Resource Managers |
Components running under MTS can access multiple databases and other resources such as message queuing systems and mainframe applications, simultaneously and with full data integrity protections. MTS automatically manages transactions so that all databases and other resources included in a request commit or abort as a unit. |
No MTS Client Footprint | MTS applications require no libraries or run-time environment on client machines beyond that provided by COM and Distributed COM (DCOM). |
Windows NT Workstation and Windows 95 and Windows 98 Support | MTS supports operation on Windows NT Workstation and Windows 95 and Windows 98 so that companies can deploy stand-alone versions of their MTS applications. |
Process Isolation | MTS Administrators can configure packages to run in their own process to ensure that failures do not spread to other packages. |
Automatic Thread Pooling | As requests come from clients, MTS automatically assigns threads to components from a pre-allocated pool. When a component finishes executing, MTS reclaims the thread. This reduces the overhead of thread creation/deletion for better performance. |
Automatic Object Instance Management | MTS creates instances of components on the server only when requested and reclaims memory resources when the component finishes executing. This form of just-in-time (JIT) activation and as-soon-as-possible deactivation minimizes memory requirements on server machines. |
Shared Property Manager | MTS provides the Shared Property Manager to simplify programming of components that need to save state information or share state with other components. |
Integration with Windows NT Features and Microsoft Products | |
Integration with Microsoft SQL Server 6.5 |
Microsoft SQL Server 6.5 provides an OBDC 3.0 driver that provides extremely fast and efficient transactional integration, based on Microsoft Distributed Transaction Coordinator (DTC) to MTS applications. Because MTS also uses DTC for transaction management, administrators can use the same utilities to manage transactions between MTS and SQL Server, simplifying systems administration |
Feature | Description and Benefits |
Integration with Windows NT Features and Microsoft Products (Cont.) | |
IIS Integration | Microsoft Internet Information Server version. 4.0 is integrated with MTS and uses MTS for many run-time services such as transaction management. MTS integration makes it easy for IIS Active Server Pages to call MTS components that access databases, mainframe applications, and message queues with full data integrity protection. MTS integration also provides IIS with process isolation to prevent individual failures from affecting other parts of a Web site, enhanced run-time services such as thread and connection pooling for better performance, and easier component management. |
MSMQ Integration | MTS provides integration with Microsoft Message Queue Server (MSMQ). MSMQ integration lets MTS-based applications communicate in a reliable, loosely coupled fashion. MSMQ operations (such as send and receive) enlist in MTS transactions automatically for data integrity protection |
SNA Server 4.0 Integration | MTS can use Microsoft® SNA Server 4.0 and the COM Transaction Integrator to include mainframe applications (for example, running under CICS and IMS) and their data in transactions managed by MTS. MTS-based applications can update one or more databases, send or receive messages with MSMQ, and invoke a mainframe application that updates data (for example, in VSAM), and all updates, including those on the mainframe, will commit or abort as a whole. Microsoft SNA Server 4.0 also makes it easy to generate COM-based interfaces to mainframe applications for simplified MTS programming. |
Support for Windows NT Clustering Services | MTS supports operation on clustered Windows NT Servers. Clustering enables administrators to configure MTS packages for automatic failover and fault-tolerant, high-availability operation. |
Windows NT Security Integration |
MTS provides a role-based security mechanism that is integrated with the Windows NT security environment. Roles let developers design security protections into their components without knowing how the components will be ultimately deployed. Administrators map roles to users when they install components into MTS. |
MTS 2.0 is included as a feature of Microsoft Windows NT Server, Enterprise Edition 4.0, Microsoft Windows NT Server, Standard Edition 4.0, Windows NT Workstation 4.0, and Windows 95. In addition, existing licensees of these operating system platforms can obtain MTS 2.0 via the Windows NT 4.0 Option Pack. The Option Pack is available in CD-ROM form for an estimated retail price of US $99 or via a Web-based download for no charge.
Machines that invoke MTS-based components running on Windows NT Server require a Microsoft Windows NT Server Client Access License (CAL). Machines that already have an existing CAL for access to services such as print services and file sharing do not need to purchase an additional CAL in order to use MTS Clients. Visit http://www.microsoft.com/ntserver for more information on Microsoft Windows NT Server licensing.
Every application, from spreadsheets on personal computers to accounts payable systems on mainframes, has three components: presentation, application logic, and data. Presentation components focus on interacting with the user. Application logic components perform calculations and determine the flow of the application. Data components manage information that must persist across sessions, planned shutdowns, and systems failures. While every application has these components, application developers have many configuration and deployment options that balance issues such as development costs with scalability and component reusability.
A Two-Tiered Application
Two-tiered applications group presentation and application logic components together on the client machine and access data remotely via network connections. Using tools such as the industry-standard Structured Query Language (SQL), application components on the client read data from the database, perform application logic, and send data back to the database when updates need to occur. Two-tiered applications usually work very well in departmental-scale applications with modest numbers of users (under 100), a single database, and secure, fast networking. And, because most client/server development tools automatically generate them, two-tiered applications are the most common form of network-based application in use today.
With a large number of users, multi-database environments, and non-secure network environments, two-tiered applications can experience a number of limitations.
Developers also need to be aware that because of lock contention, two-tiered applications scale well to a point and then can degrade quickly. And because lock resolution is not dependent on the speed of the server, even installing more powerful database machines does not provide significantly greater performance.
A Two-and-a-Half–Tiered Application
with Data Gateways
When companies experience the limitations of two-tiered models, most turn to data gateways and database stored procedures. Data gateways enable data that resides in other databases (for example, VSAM data on a mainframe) to look and behave as though it resides in the database to which the client is connected. This increases the number of sources of data that a two-tiered application can access and offers an appealing way to integrate different applications via extending access to their data.
A Two-and-a-Half–Tiered Application
with Stored Procedures
Stored procedures provide a way for clients to execute groups of SQL statements remotely on the database server. Client applications invoke stored procedures by name, and can pass parameters in to, and retrieve results out of, the procedures. Stored procedures reduce network traffic by minimizing the data that must be exchanged back and forth with the client, improve security by limiting use to authorized clients, and improve application reuse by enabling multiple presentation components to call the same stored procedure centrally. Stored procedures also improve scalability. As a rule of thumb, applications that use stored procedures can support about twice as many users as similar two-tiered applications.
Where two-tiered architectures group presentation and application components together on the client, stored procedures group the application logic components with the data components on the database server. This is often called a two-and-a-half–tiered architecture, because stored procedures offer greater scalability, security, and reuse than two-tiered approaches, but are not as powerful as true three-tiered architectures.
Despite the advantages of data gateways and stored procedures, a number of significant limitations exist. Regarding stored procedures:
Regarding data gateways, integration with other applications must occur at the data-to-data level via gateways. Implications of data-to-data integration include:
Based on these limitations, stored procedures work best within single applications that need enhanced scalability and security, but do not require broad reuse. Data gateways work best for read-only and very low volume applications. Applications that require component reuse and the ability to access multiple databases and mainframe applications clearly need something more.
A Three-Tiered Application
In three-tiered architectures, presentation, application logic, and data components are separated into distinct units. Presentation components manage user interaction and make requests for application services by calling middle-tiered components. Application components perform business logic and make requests to databases and other resources using their native interfaces such as SQL to a database or LU6.2 to mainframe applications. Clients can call as many server-based components as they need to complete a request, and components can call other components to improve reuse.
Three-tiered architectures are often called server-centric, because they uniquely enable application components to run on middle-tiered servers independent of both the presentation interface and database implementation. While there is no requirement that each unit runs on a different physical machine, to deliver maximum benefit, three-tiered systems must run with presentation components on desktop clients or browsers, application logic on middle-tiered servers, and data on dedicated database servers. The independence of application logic from presentation and data offers many benefits:
While the arguments for three-tiered architectures are compelling, most companies have little experience beyond two-tiered and two-and-a-half–tiered approaches. The most likely explanation is that development tool support for database-centric approaches is strong and few tools have existed to assist with server-centric development. With the availability of Microsoft Transaction Server, supported by a wide range of popular development tools, three-tiered development is finally accessible to a wide range of companies.
MTS Application Architecture
MTS provides a server-centric environment for developing and deploying three-tiered applications based on Microsoft’s Component Object Model (COM) technologies. In MTS applications, application logic components run under the control of MTS on servers and are invoked by presentation-centric components running on clients via Microsoft’s Distributed COM (DCOM) technologies. Clients can be a mixture of conventional applications and Active Server Page (ASP) scripts running within Microsoft Internet Information Server (IIS).
Application logic components can access a number of different databases, Microsoft Message Queue Server (MSMQ), and, via Microsoft SNA Server 4.0, CICS and IMS applications. Access to databases and resources is done through MTS Resource Dispensers that perform services such as connection pooling automatically. MTS also supports automatic transactions so that access to data and resources is done with all-or-nothing protection.
Developers can build presentation and application logic components with any tool or programming language that can generate COM-compliant dynamic-link libraries (DLLs). For components to work efficiently within the MTS environment, developers must observe several simple rules:
A Sample MTS Component Code Template
When components follow these rules, applications can take advantage of MTS benefits such as enhanced scalability, performance, and management with no additional development. Installation of components into the MTS environment is as simple as dragging and dropping the component’s DLL into an MTS Explorer window.
MTS represents a powerful technology for developing and deploying three-tiered applications based on Microsoft Component Object Model (COM) technologies. As detailed in the Introduction to Three-Tiered Computing section, three-tiered architectures offer broad benefits, such as enhanced scalability, security, and application logic reuse. Because these benefits are applicable to a variety of applications in all industries, a good way to understand when to use MTS is to describe several common scenarios and show how MTS adds value.
Among its many roles, the Web has emerged as an ideal vehicle for delivering line-of-business and electronic commerce applications to users. Browsers represent an easy way to present powerful and dynamic user interfaces with near-zero desktop footprint and maintenance costs. And Internet/intranet networking now reaches almost every part of the world, making it possible to turn virtually any desktop into a high-powered presentation and user input device instantly.
As noted earlier, presentation and user input are just part of the total application. There needs to be something else that takes the user’s HTML-based input and invokes an application that processes the request against the appropriate databases and other resources. In the case of the Web, that something is usually a Web server. While early Web servers simply provided access to static HTML pages, most Web servers now have mechanisms for accepting input from users, invoking an application or script, and returning a response.
The process of handling application requests from Web servers is more difficult than it sounds:
Conventional solutions to these issues rely on mechanisms such as Common Gateway Interface (CGI) scripts, which work well enough for basic applications, but are not scalable or robust enough for line-of-business or electronic commerce applications.
MTS, combined with Microsoft Internet Information Server 4.0 (IIS), is ideal for building production-quality three-tiered applications with Web-based front ends. IIS provides state-of-the-art facilities for delivering visual and interactive pages to browsers and a powerful application mechanism called Active Server Pages (ASPs). ASPs are text files that contain a combination of standard HTML commands and scripts based on Visual Basic and JavaScript.
Web page designers use ASPs by building standard Web pages containing references to URLs with .ASP extensions. For example, it is common to send input forms to users and designate in the return URL an ASP that processes the response. When users fill in the form and send their response, IIS sees that the URL contains a .ASP extension and executes the appropriate ASP script. The script in the ASP file can do basic calculations, access databases via ODBC interfaces, and build an HTML stream to send back to the browser. Most important, ASPs can also call components running under MTS.
When an ASP calls an MTS component, the request comes in to MTS as though it came from any other client. The component can:
Because MTS provides automatic transaction support, if any error condition occurs within an MTS component or the ASP script, MTS will roll back all changes made to databases (including those on the mainframe, if applicable) and message queues. MTS transactions provide important data integrity protection required by production-quality systems. For example, without transaction protection, orders could be sent without collecting payments, and accounts could get out of balance. MTS also provides a sophisticated component run-time environment that can handle a large number of users and deliver consistently good response times.
By combining IIS Active Server Pages with MTS, companies can build powerful line-of-business and electronic commerce applications—out of reusable components—with interactive and dynamic Web-based interfaces. In fact, while ASPs alone can implement significant amounts of calculations and database access, Microsoft recommends using ASPs for presentation management and MTS for application logic. This approach yields Web-based applications, built from reusable components, that can support a large number of users, perform complex calculations, and access multiple databases and other resources such as mainframe applications.
Development tools such as Visual Basic and Visual J++ owe a lot of their popularity to how easy they make building two-tiered applications. Features such as data-bound controls isolate developers from the complexities of database access while providing powerful user interface capabilities. Their support for COM also makes it easy to develop applications using a modular, component-based architecture.
At the same time, two-tiered applications built with Visual Basic and Visual J++ will experience the same limitations as other two-tiered applications. For example, data-bound controls place demands on databases and can create contention issues when used by many users concurrently. It also was difficult (prior to MTS 1.0) to use COM components built using Visual Basic (and other COM-enabled tools) outside of the client environment.
With MTS, developers can use their existing skills with tools such as Visual Basic to build sophisticated three-tiered applications. By following a few simple rules, developers can generate the application logic components of their programs as COM-enabled dynamic-link libraries (DLLs) that run on middle-tiered servers under the control of MTS. Then, when client-based presentation components call server-based application components, the Distributed Component Object Model (DCOM) run time will route the requests to MTS automatically. Benefits of using MTS in this environment include:
With MTS, companies can realize the benefits of powerful development tools on an entirely different scale.
Companies have been aware of the benefits of object-oriented programming tools and development methodologies for some time. Initially, objects delivered most of their value in client-centric uses, such as user interface development, because companies lacked any standard and easy way to use objects in server-centric roles. MTS changes this.
By providing support for server-side objects, MTS lets companies take advantage of distributed objects in line-of-business applications. Developers build their applications as a collection of COM components and deploy them using MTS. Using a combined COM and MTS approach, developers of distributed object applications will see a number of benefits:
Most important, MTS 2.0 and supporting products such as MSMQ 1.0, IIS 4.0, and SNA Server 4.0, are available and integrated today, in contrast to the mixture of specifications, plans, and poorly integrated products available from other vendors.
MTS Benefits: |
Enables scalable, reusable applications without complex programming Works well with popular Adds only a simple set of new API calls Simplifies configuration and management |
MTS completely separates three-tiered infrastructure from presentation and application logic. This lets MTS developers build their applications as a collection of single-user COM components and then deploy components in the appropriate tier. Components that run on middle-tiered servers automatically support multi-user operation as long as they follow a few simple rules.
MTS supports any tool that can produce COM DLLs, including Microsoft Visual Basic, Microsoft Visual C++, and Microsoft Visual J++. Developers and businesses that use these languages for desktop solutions can now use them for server solutions. A number of other tools vendors provide COM support within their products, including:
Most existing three-tiered development environments, such as distributed TP monitors, require developers to master 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. In fact, programming complexity is one of the reasons that Object Request Brokers (ORB) and TP Monitors have been slow to achieve mass market acceptance.
MTS takes advantage of existing COM programming interfaces, familiar to desktop developers, in order to lower training costs and shorten ramp-up time. For example:
MTS developers have to learn only a simple set of new APIs to deploy their components in the MTS run-time environment. Extensive knowledge of COM APIs and Microsoft® Win32® APIs is not required.
Assembling different software components into a single solution can present configuration and deployment issues. To address these issues, MTS provides the concept of packages to make it easy for developers to combine different COM components into a single manageable unit. Components in a package execute in the same process space, share common security, and can be deployed as a single unit. Packages also increase application deployment flexibility. An entire application can be distributed as a single package and then partitioned into multiple packages to optimize performance, load balancing, and fault isolation.
The MTS Explorer is a GUI-based systems management interface that makes it easy for administrators to create and manage packages, configure component properties such as security and transaction behavior, and monitor/manage operating servers. Other MTS Explorer features include:
The MTS Explorer also includes a Software Development Kit (SDK) for developing applications that install and configure MTS applications automatically.
The MTS Explorer management interface can run as a snap-in to the Microsoft Management Console (MMC). MMC integration provides users with a consolidated management environment with a consistent look. Other software with MMC interfaces includes Windows NT, IIS, and the Microsoft® BackOffice® family.
While MTS applications require no special libraries or services to run on client machines, some configuration of registry entries must be performed to tell DCOM where to find instances of objects. MTS provides a utility that performs all required configuration actions automatically on clients to let them make calls to MTS-based components transparently.
MTS Benefits: |
Provides automatic data integrity protection Improves database and Supports common databases Simplifies client management Limits scope of failures Simplifies data sharing |
MTS provides automatic transaction management services to components. Developers or administrators can use simple property page interfaces to specify what level of transaction protection is required by a given component. At run time, MTS performs all required transaction management automatically. This dramatically simplifies development and facilitates component reuse. For more information on MTS transactions, refer to the section titled The Role of MTS Transactions in Components.
Integrating relational databases within a three-tiered application environment presents a number of challenges:
To address these issues, Microsoft Transaction Server provides an ODBC resource dispenser that creates and manages a reusable pool of ODBC database connections automatically. When application components make standard ODBC calls, MTS locates an available connection, uses it, and returns the connection to the pool when the component completes. The result is greater scalability, much simpler programming for component developers, and significantly faster operation in multi-user environments.
MTS includes an ODBC 3.0-compliant driver for Oracle Version 7.3 and later as well as IBM's DB2. ODBC 3.0 compliance enables developers to build MTS applications that access these databases (on any platform), along with access to other resources such as SQL Server and Microsoft Message Queue Server, in transactional units of work for full data integrity protection. ODBC 3.0 compliance also enables MTS to perform connection pooling of Oracle and DB2 database sessions for improved performance.
Components running under MTS can access multiple databases and other resources such as message queuing systems and mainframe applications from within a single MTS transaction. Access to resources can be from a single component or from multiple components that are called together to form a single business operation. After all the work in a transaction completes, MTS initiates a two-phase commit protocol transparently with each resource to ensure that all databases and other resources included in a request commit or abort as a unit.
Microsoft Transaction Server does not require any special software or libraries on client platforms. Browser-based clients can access MTS components via IIS, and clients running Windows 95, Windows 98 or Windows NT 4.0 Workstation invoke components transparently through DCOM.
Performance and Scalability Features
MTS supports operation on Microsoft® Windows NT® Workstation, Microsoft® Windows 95, and Microsoft® Windows® 98 to enable companies to deploy stand-alone versions of their MTS applications for development and testing purposes. The same applications can be deployed on Windows NT Server without any modification.
In many run-time environments, failures within one thread or process can cause failures of entire applications and affect many users. In contrast, MTS Administrators can configure packages to run in their own Windows NT process to ensure that failures in any given package do not spread to other packages.
One way that developers can gain more scalability from their applications is to use Windows NT threads instead of processes for application execution. To make it easy for developers to use threads, MTS provides an automatic thread pooling mechanism. When a request for component execution comes in to MTS from a client, MTS automatically locates an available thread from a pool, executes the component on the thread, and returns the thread to the pool. This simplifies programming and reduces the overhead of thread creation and deletion to improve performance.
In most distributed object environments, instances of server-based objects remain active, and consume server resources, as long as a reference to the object is held by one or more clients. In multi-user environments, this can result in tremendous server resource requirements. To address this issue, MTS extends the COM object model with just-in-time (JIT) activation where components only consume server resources while they are actually executing.
After an MTS-based component indicates that it has completed its work, MTS deactivates the component and recycles its resources. As long as the component is deactivated, only limited server resources remain allocated to it. When the component is called again, MTS reactivates it by reacquiring any resources that the component needs. Most important, from the client’s perspective, only a single instance of the component exists from the time the client creates it to the time it is finally released. No special programming is required.
Many applications require the ability to share data between instances of components. In multi-user scenarios, sharing data safely requires developers to implement locking schemes to prevent concurrent access by multiple components. To make data sharing easier, MTS includes a special-purpose resource dispenser called the Shared Property Manager. The Shared Property Manager enables multiple components to access the same data concurrently—and safely—without complex programming.
MTS Benefits: |
Enables components to access SQL Server 6.5 quickly and efficiently.
Makes it easy to develop powerful Web-based applications. Simplifies asynchronous communication between Simplifies access to mainframe applications and data. Supports fault-tolerant Simplifies security policy |
Microsoft SQL Server 6.5 provides an OBDC 3.0 driver that provides extremely fast and efficient transactional integration, based on the OLE Transactions protocol and the Microsoft Distributed Transaction Coordinator (DTC), to MTS applications. OLE Transactions provides fast, efficient transaction coordination interfaces. Because MTS uses DTC for transaction management, administrators can use the same utilities to manage transactions between MTS and SQL Server, simplifying systems administration.
Microsoft Internet Information Server version. 4.0 is integrated with MTS and uses MTS for many run-time services such as transaction management. MTS integration makes it easy for IIS Active Server Pages to call MTS components that access databases, mainframe applications, and message queues with full data integrity protection. MTS integration also provides IIS with process isolation to prevent individual failures from affecting other parts of a Web site, with enhanced run-time services such as thread and connection pooling for better performance, and with easier component management.
MTS Application developers can include MSMQ operations (that is, send and receive) within transactional units of work that contain other activities such as database updates. MSMQ operations commit or abort along with other resources in the transaction to preserve data integrity. For example, if an application updates a database and sends a message to another application within a transaction, any abort condition will cause the database updates to roll back. MSMQ will also roll back by canceling the send operation. When used within a transaction, MSMQ never completes send operations until transactions commit. This prevents receivers from getting messages from transactions that aborted.
MSMQ takes similar actions when receive operations occur within a transaction. If the transaction aborts, MSMQ rolls back the receive operation by putting the received message back in its queue. This message becomes available for receipt by subsequent transactions. The transactional features of MSMQ are important, because many types of problems will occur if abort logic does not include queue operations. For example, if a receive operation does not roll back when associated database operations are rolled back, the message effectively becomes lost, because no database processing occurs.
Microsoft SNA Server 4.0 makes it easy to generate COM-based interfaces to mainframe applications for simplified MTS programming. Developers use the graphical tools provided by SNA Server’s Transaction Integrator to designate the COBOL-based communication area definitions in mainframe applications. Then, Transaction Integrator creates COM objects containing the appropriate methods and input/output parameters automatically.
When MTS applications call the components, SNA Server automatically calls the appropriate mainframe applications (for example, running under CICS), which join the current transaction managed by MTS. MTS-based applications can update one or more databases, send or receive messages with MSMQ, and invoke a mainframe application that updates data (for example, in VSAM), and all updates, including those on the mainframe, will commit or abort as a whole.
MTS supports operation on clustered Windows NT Servers. Clustering lets administrators configure MTS for automatic failover and fault-tolerant, high-availability operation. For example, MTS packages can be installed on both machines in a Windows NT cluster environment. When a failure occurs in the online machine, requests for components will be directed to the standby machine once the Microsoft Cluster Service automatically transfers control.
MTS provides a distributed security implementation for component-based applications. MTS uses Windows NT security to authenticate users, but provides its own options for authorization. Transaction Server provides two complementary models called declarative and programmatic security. Declarative security is automatic and is specified when components are added into a package and doesn’t require developers to do any programming. Administrators declare which users and groups of users have access to the package using the MTS Explorer. This enables deployment-specific security, even for when used with prebuilt components purchased from third parties.
In contrast, programmatic security lets developers build custom access controls directly into their component by explicitly using roles. For example, roles in a banking application could be called teller and manager, and components could check to make sure that the current user has been given manager privileges before performing certain operations. Administrators associate users with roles using the MTS Explorer. Most important, components themselves have no embedded knowledge of specific users and don’t have to make explicit calls to the Windows NT Security environment. This dramatically improves the ability of a component to be both secure and reusable in a broad sense.
|
Transactions are an essential tool for building server-centric applications from component software. To date, most applications are developed as a monolithic application by a single team of developers where it is relatively easy to design transactions properly. But, as companies turn to component-based development, and use prebuilt components developed by other companies, transaction protection becomes much harder to ensure.
Consider a simple bank funds transfer application assembled from three components —Transfer, Credit, and Debit—each built by a different developer.
Assume that Transfer begins work by calling Debit and Credit. Debit succeeds and subtracts $100 from a database. Credit fails because its database was unable to commit successfully. Unless the developer of Transfer has programmed what to do if one of the components has failed, the application will withdraw $100 from the savings account without putting it in a corresponding checking account.
Although this scenario may be easy to correct in a three-component application, typical business applications involving hundreds of components running across multiple servers are unmanageable without transactions. With component-based development, an automatic distributed transaction infrastructure is the only way to address these issues in a cost-effective manner.
Components without Transactions
Components with MTS Transactions
MTS makes transaction management transparent to the component developer. Developers do not have to write begin or end transaction statements into their application code. Developers can even use different tools and languages to build their components. They simply declare components to be transactional using the Transaction Server Explorer. Then, when a component begins execution, MTS starts a transaction automatically if one is required.
When the component accesses a resource such as a database, message queue, or mainframe application, MTS automatically enlists the resource in the transaction. If the component calls another component, the called component also joins the transaction automatically. When all components in a transaction complete their work, MTS initiates a full two-phase commit to either commit or abort the work.
In many ways, MTS defines an entirely new category of product. MTS uniquely provides a combination of:
That said, the two closest competitors to MTS are CORBA-compliant Object Request Brokers (ORBs) that support the Object Transaction Service and Sun’s Enterprise JavaBeans strategy.
While the vision of the Object Management Group (OMG) remains exciting to most corporations, the CORBA approach suffers from a number of weaknesses:
The bottom line is that CORBA-compliant ORBs provide a simple way to build basic distributed object applications, but do not provide the infrastructure required for deployment in a production-quality capacity.
More recently, Sun Microsystems announced an initiative called Enterprise JavaBeans. Like CORBA, Enterprise JavaBeans promises developers that they can build reusable components and run them anywhere on a network. Like CORBA, the Enterprise JavaBeans strategy has significant weaknesses:
In fact, until the Enterprise JavaBeans specification becomes more complete, it will be difficult for vendors to build compliant products and for customers to assess the viability of Enterprise JavaBeans in their environment.
The growth of Internet computing is creating explosive demand for businesses to deploy solutions on servers. While the Internet achieved its initial growth by providing an easy way to publish and share information online, businesses now realize that they can achieve even more by Web-enabling their line-of-business applications for Internet and intranet use. Instead of simply publishing sales brochures and product catalogs, businesses can operate accounting systems and order-entry systems on servers with users accessing the shared business functions from now-ubiquitous browsers.
Companies are also realizing that they are wasting huge amounts of programming effort by developing single-use two-tiered and two-and-a-half–tiered applications instead of three-tiered applications with reusable components that run on servers. By developing applications logic once in component form and running components on a server, a variety of different presentation interfaces can be supported. And, since components can call other components easily, duplicating programming efforts is minimized.
Historically, there has been a problem with this server-centric vision. Lacking tool and infrastructure support, building and deploying server-based components is much harder than building single-use applications. Server-based applications need to be more reliable than desktop applications, because the impact of system failure or data corruption can affect an entire business, not just a single user. This mandates a sophisticated infrastructure that is costly to develop and difficult to maintain. By many estimates, infrastructure development represents 30%–40% of the average server-centric development project. To be viable, server-based applications need to be as easy to deploy and maintain as desktop applications, without requiring developers to have special skills or to build costly, complex infrastructure code.
It was with these goals in mind that Microsoft developed Microsoft Transaction Server and included it with Microsoft Windows NT and Microsoft Windows 95. MTS combines the flexibility and low cost of desktop applications with the mission-critical transaction processing features normally found in high-end mainframe systems. And, because Microsoft Transaction Server is based on Microsoft’s Component Object Model, MTS is accessible to a wide range of developers without expensive retraining.
For the latest information on Windows NT Server, visit the Microsoft Windows NT server Web site, http://www.microsoft.com/ntserver as well as the Windows NT Server Forum on the Microsoft Network (GO WORD: MSNTS). For more information on Microsoft Transaction Server, visit the MTS area of the Microsoft COM Web site, http://www.microsoft.com/com/mts-f.htm.