简介：
微软事务处理服务(MTS)代表了一类新的产品，它使开发和布置高性能的、可变尺度的、可靠的分布式应用程序更加容易。这是通过将以组件为基础的开发和布置技术与事务处理控制器的可变尺度性、可靠性结合起来而实现的。
为什么使用微软事务处理服务？
微软事务处理服务被设计用于使的构造 高性能的、可变尺度的、可靠的internet和intranet应用程序更加容易。多年以前，我们就能构造这些应用程序了，但它所要求的才赋和投资超出了大多数公司的能力。
MTS以已被证实的事务处理方法为基础，但它的重要性超出了事务处理控制器的领域，它对分布式、以组件为基础的服务器应用程序定义了一个简单的 编程模式和执行环境。
应用程序由能够提供商业应用功能的微软ActiveX组件组合而成。这些组件似乎被开发用于单用户。通过在MTS环境下安装这些组件来执行它们，服务器应用程序能高性能的、可靠的自动改变尺度以支持同时存在的多客户。
MTS 被特别设计用于允许服务器应用程序在一个很大的用户范围内变化（从小的单用户系统到高容量的网络服务器）。它还具有通常只有高档的事务处理系统才具有的鲁棒性和完整性。
下面这部分对开发一个优秀的服务器应用程序的复杂性作一个简单的回顾。
我们从三个不同角度来讨论这个问题：
第一、它强调了一个网络服务器为提供合理水平服务所必须作的工作。
第二、它论述了当构造以组件为基础的应用程序所引起的问题。
第三、它描述了即使是在错误发生时，维持应用程序的完整的重要性。
MTS提供了一个应用程序编程模式，使得开发者避开了这些复杂之处，允许开发者将精力集中于程序的功能上，并降低了构造程序所需的费用和时间。
服务器基本结构：
服务器要有一个高级的基础。从零开始建造一个网络应用服务器不是一件容易的事。完成实际的商业功能，例如处理在线书库的订单，实际只是工作的一小部分。典型的服务器系统必须有一个高级基础来获取可接受的性能和尺度。
应用程序服务开发者必须亲自经常开发基本构件中的许多部分。举个例子，序调用提供了丰富的服务，系统开发者仍必须作下面的工作：
注册目录系统服务器；
管理服务器处理池和线程池；
最后，服务器需要为多用户请求提供的服务管理线程池，而不只是针对一个单用户。使多客户同时请求使用共享数据和资源的要求同步。这要求高级锁定协议能解释死锁、条件竞争、资源匮乏及其他性能上的问题。管理客户内容，包括数据库连接和数据结构的全视图。（目标视图）
客户缓冲状况以改善潜在慢速网络通行。
完成安全保障以确保商业功能和对象仅提供给被授权者。
完成管理和确认工具以允许服务器的远程安装和管理。
MTS提供了一个应用程序/服务器基本结构来满足上面的要求。
构造以组件为基础的应用程序：
从组件构造应用程序对开发者有极大的吸引力并且是面向对象计算的早期目标之一。由于它提供了一个自然的方法来封装商业功能，因而对开发服务器应用程序更具吸引力。
然而，组件工程程序比它原来显现出来的要困难。早期对象系统的一个根本弱点是缺乏共同的框架来允许开发者无论是在同一进程或是交叉进程，都能将不同部分创造的对象结合到一个完整的程序里。组件对象模型（COM）解决了这个问题。
然而，简单的用一个COM模型来从组件构造服务器应用程序是不够的。该组件必须使用共同的服务框架。那些自己构造服务器框架的开发者使用其他组的组件开发程序的机会就会很小。
MTS程序工程师和编程界面提供了一个共同的框架来构造以组件为基础的服务器应用程序。
保持程序的完整性：
非常重要的一点是，商业系统应能准确的维持商业状态。例如，一个在线书库必须可靠的跟踪订单。若不然，将会产生巨大的收入损失。现存的订单可能丢失或在取订单、填订单的时候有延时，不满意的用户可能会转到别处作生意。
维持商业系统的完整性从不容易，特别在发生错误以后。具有讽刺意义的是，即使计算机变的越来越可靠，系统作为一个整体变得更加不可靠。对提供internet和intranet连接到数十、数百、甚至可能数万个服务器上的无数桌式计算机来讲，错误是常事。
对分布式程序的要求使问题复杂化。商业事务，如订书，逐渐地卷入多个服务者，必须证实其信用，书必须船运，必须管理存货目录，并且客户必须有资金。这一切都使在多服务器上的多个数据库更新成为必须。分布式开发者必须预料到程序的某一部分能在其他部分发生错误后继续运行。这些防错方案是单个程序的好几倍。
商业程序经常被要求将多个工作协调为单个商业事务。一个在线书库绝对不能在没有处理恰当的订单前就去安排装运的日程，同时也不可能向用户收取费用而不通知其送货日期。协调这些工作使它们都发生或都不发生，若无特殊系统支持是非常困难的。
即使在发生错误时要确保程序最小单位的更新，是很不容易的。尤其当一个应用程序分布在多个数据库和系统上时。使用在设计上隐藏了其可完成性的多种组件造成了这个问题。
当多个用户获取同一组件时程序也必须能提供一致的行为。对同一本书同时的定单不应产生只送一本书给两个用户的情况。除非程序被正确书写，资源竞争最终将引起不一致性。这些问题很难解决并将花很多钱。并且随着程序增长和费用增多而更可能发生。这也是由于使用组件引起的。
MTS使用以组件为基础的编程完整事务使得你能开发出鲁棒，分布式的，以组件为基础的程序。
MTS工程师
这部分对MTS工程师主要元素作一简介
这些元素包括：
ActiveX组件，完成应用程序功能。
事务管理服务执行者，为程序组件运行服务。
服务处理，提供存放程序组件的代理处理环境。
资源管理者(RM)，管理程序的可耐阶段，例如包括相关数据库系统和事务性消息队列。
资源分配者，管理进程内组件非耐久性共享数据，例子包括数据库连接池，管理队列。
微软分布事务协调者，允许通过多个资源管理者，分配者和程序组件协调事务。
微软事务服务器组件：程序组件使商业行为模式化。这些组件了完整商业规则，提供视图和程序状态变化情况。考虑在线书库的例子。用在数据库系统中的记录代表商务的耐久状态，如挂起订单，方便的目录，可接受帐单。应用程序组件刷新状态以反映如新定单和目录发送的变化。
MTS程序组件是ActiveX处理中服务器（DDL）。通过使用Microsoft Visual Basic，Visual C++，Visual J++或任何与ActiveX相兼容的开发工具，你可以创造并实现这些组件。
ActiveX以COM为基础，包括：
界面概念，客户从对象请求服务的方法；
通过处理器和机器界限与透明对象的连接；
确认组件，动态装载和执行组件的机制；
对象能通过MTS工程师支持多界面，并提供给用户查询支持对象的特殊界面的方法。并允许组件提供不同水平的功能并逐渐引入新版本。
MTS扩展了COM以提供一个通用的服务器程序框架。除了上面提到的COM内在的特性外，MTS还处理服务器注册，进程,线程管理，内容管理，共享资源的管理和同步化，以及以组件为基础的安全性管理。
将事务引入到程序模板作为获得最小单元更新和在组件、数据库系统及网络边界达到一致性的机制。每个组件都有一个事务属性指出组件的事务性语义。这允许事务性内容被MTS自动管理。MTS使用户避免了复杂的服务事件，使用户可以专注于完成商业功能。由于在MTS下运行组件可充分利用事务服务程序，用户可以把程序当成各自独立的状态来编写程序。MTS处理同时事件，资源池，内容管理及其他系统水平的复杂的事件。事务系统，与数据库服务器和其他类型的资源管理协同工作，确保同时事务是强大的、一致的、有恰当的分离性，并且，一旦完成，变化是可耐久的。
应用程序作为ActiveX的组件来分配，称为包裹。包裹定义了错误分离和信任边界。
事务管理服务执行器：
事务管理服务执行器是一个动态连接库（DDL），它对事务管理服务组件提供运行时服务。这些服务包括线程管理和内容管理。这些动态连接库被加载到应用程序组件的宿主进程中，并且在后台透明的执行。
服务进程：
服务进程是应用程序组件执行的宿主系统进程，对数十、成百、上千个客户提供服务。你可以配置多个服务进程在一个计算机上执行。每个服务进程反映了一个分立的信任边界和错误绝缘域。
其他的进程环境也能让应用程序组件在其上运行。这使你可以分配应用程序以适合不同的分布、性能和错误绝缘要求。例如，你可以配置MTS组件直接加载到微软SQL服务器上或微软网络信息服务器（IIS）上。你还可以直接将它们配置到客户进程中去。
资源管理者：
资源管理者是一种系统服务，它管理耐久数据。服务器应用程序使用资源管理者维持应用程序的耐久状态，如方便的存货目录记录，到期订单以及可接受帐目。资源管理者于事务管理者协同工作，以保证应用程序的最小性和分立性。微软SQL服务器，耐久的消息队列和事务性的文件系统都是资源管理者的例子。
最小性保证了在一个特殊事务中所有的更新都能完成（并能持久）或者被放弃并回到原来的状态。一致性意味着一个事务是系统状态的正确转化，保存了状态变量。
分立使得同时事务不会得知其他事务的信息和未完成的结果，以免引起应用程序状态的不稳定。资源管理者应用以事务为基础的同步协议来分离活动事务管理程序未完成的工作。
耐久性意味着对已管理资源（如数据库记录）的更新，能不受错误的影响，包括通讯错误，进程错误和服务系统错误。事务管理的日志甚至能允许你在磁盘介质失效后恢复耐久状态。
最小性和分立性协同工作使得事务管理程序看起来是立刻发生的。事务管理程序的中间状态对外面来说是不可见的，并且产生了这样一个结果：或者所有的工作都完成了，或者没有一个完成了。这允许我们在编写应用程序组件时，可以把事务管理程序当作顺序发生而不考虑其同时性，这对应用程序开发者是一个非常大的简化。
MTS支持资源管理者来完成OLE事务管理协议或X/Open XA协议。有开发资源管理者的工具包。
一个资源分配者在一个进程内代表应用程序组件管理非耐久性的共享数据。资源分配者与资源管理者相似，但没有担保或耐久性。MTS提供两种资源分配者：
ODBC资源分配者
共享属性管理者
并提供了一个工具包来开发资源分配者
ODBC资源分配者：
ODBC资源分配者使用标准开放数据连接界面为事务服务器管理数据连接池。ODBC资源分配者维护数据库连接池，快速和有效的分配给对象连接。连接被自动列在对象的事务处理程序中。资源分配者能自动的回收和重用连接。ODBC资源分配者是一个动态连接库，它对用户透明的提供这种功能并且内构在MTS的特性里。
共享属性管理者：
共享特性管理者对定义的应用程序，进程宽度，属性（变量）进行同步管理。你可以使用它来维护一个Web页面冲浪计数器，常量数据的缓冲，或者提供高速缓冲来避免数据库的过热点。（例如产生唯一的接收成员）。
微软分布式事务管理协调者：
微软分布式事务管理协调者是一个系统服务，用于协调跨越多个资源管理者的事务。即使事务可能在分立的计算机上跨越了多个资源管理者，它也能当作最小事务来完成。
微软分布式事务管理协调者最早作为微软SQL服务器6.5版本的一部分发布，并且包含在MTS里。它完成了两阶段承诺协议来保证事务处理结果（完成的或抛弃的）在所有的资源管理者中是一致的。
微软分布式事务管理协调者确保最小性，不管是在错误（节点冲突、网络崩溃或资源管理者、应用程序的错误动作），条件竞争（事务管理程序开始工作而一个资源管理者正在放弃）还是可提供性（一个资源管理者装备了一个事务但没有返回）发生时。
微软分布式事务管理协调者支持符合OLE事务管理或X/Open XA协议的资源管理者。
结论：
微软事务管理服务器将改变人们开发商业应用程序的方法。组件基础技术、面向对象技术与针对分布式、在线事务处理的时间验证技术的结合将使得布置由被购买的通常构造的组件组成的应用程序更加容易。经济上的优点将产生商业组件的一个新市场。这种情况，反过来说，使得原来没有解决的问题得到商业上的解决。
微软事务处理服务已经分两阶段展开。初始时，分布式事务处理协调器在1996年4月作为微软SQL服务器版本3.5的一部分发布。它提供了通过相异数据存储库的分布式两阶段承诺。
在1996年11月，微软事务服务器发布。它提供了可靠的、可变尺度的、分布式的运行ActiveX组件所需的编程环境和运行时执行环境。
了解更多的信息：
查询微软事务管理服务器的最新信息，可到其Web站点（http://www.microsoft.com/transaction/）
也可以参考<<事务处理：概念和技术>> 作者：Jim Gray&Andreas Reuter ,Morgan Kaufmann出版社，1993年。
本文所包括的内容作为最新出版物代表了微软公司在所讨论问题上的最新观点。因为微软必须对市场情况作出反应，微软不承诺解释这些内容，也不保证在出版日期以后的内容的准确性。
Trackback: http://tb.blog.csdn.net/TrackBack.aspx?PostId=3209
