Distributed applications are all about sharing—sharing data and other resources with all the people who need them. Writing applications that work correctly in a multiuser environment is difficult. Writing applications that both work correctly and perform acceptably is even more difficult. Let's take a quick look at some of the technical issues involved.
First, code must work correctly when it is called concurrently by multiple clients. Access to internal state must be synchronized so that changes aren't lost and all clients see the results they expect. A good example of this is the reference count within a free-threaded COM object. If two concurrent calls are made to IUnknown AddRef, the reference count stored in the object must always increase by 2. Otherwise, the object might destroy itself before all the clients have finished using it, and pandemonium would ensue.
Second, access to persistent data must be coordinated so that changes aren't lost and clients don't see partially updated, inconsistent data. This requirement applies both to multiple clients accessing a single data source and to a single client accessing multiple data sources. Regardless of where the data sources are located and who is accessing them, the integrity of the data must be maintained. A classic example here is updating a bank account. Let's say that you have $500 in your checking account and that you use an ATM to make a transfer of $1,000 from a credit card to your account. At the same time, the bank is processing checks drawn on your account for $200. When you finish the credit card transfer and the bank finishes processing the checks, both you and the bank want the balance in your checking account to be $1,300. Not $300 because the record of your $1,000 deposit was lost. Nor $1,500 because the record of the checks was lost. Likewise, you don't want to see a credit card charge for $1,000 without a corresponding deposit to your checking account, and the credit card company doesn't want you to see a deposit without the corresponding charge.
Third, access to code and data must be secure. Businesses want to share information with the people who need it, but they don't want to share it with everyone in the world! Furthermore, different people might need different types of access. For example, you can view the balance of your bank account at an ATM machine, and you can make deposits and withdrawals up to a certain dollar limit. A bank teller, on the other hand, can access information and process transactions for any customer's account. Some transactions can be performed only by a bank manager. Other actions, such as changing your name and address, can be performed by bank employees who cannot access any other account information.
Fourth, distributed applications must be able to scale to meet the needs of large numbers of users. Applications must be able to share limited resources rather than dedicating individual resources to each user. Many different types of limited resources exist in a distributed system, and all must be managed. Processes, threads, memory, database connections, you name it—unless resources are shared, there won't be enough to go around if 10,000 users are accessing your application at the same time.
Finally, the cost of administering and deploying distributed applications must be kept to a minimum. Installing or updating an application should not disrupt normal business operations. Administrative tasks should be as simple as possible to reduce errors. Applications must be reliable so that employees can do their work without waiting for the computer to be "fixed."
The goal of MTS is to make it as easy as possible for component and application developers to meet these technical challenges. It does this by providing a powerful run-time environment that does as much of the difficult work as possible in a generic way that all applications can use. One part of the run time is an execution environment for COM objects. This environment addresses the code concurrency, resource management, and security issues noted earlier. A second part of the run time is a transaction manager. Transactions are the standard technique for coordinating data updates across multiple data stores and multiple users. A simple yet powerful programming model takes advantage of the run time so that developers can focus on writing custom business logic, not application server infrastructure. MTS also provides administrative tools to help simplify deployment and maintenance.