【IT168 技术文档】

　　简介

　　微软事务处理服务(MTS)代表了一类新的产品，它使开发和布置高性能的、可变尺度的、可靠的分布式应用程序更加容易。这是通过将以组件为基础的开发和布置技术与事务处理控制器的可变尺度性、可靠性结合起来而实现的。

　　为什么使用微软事务处理服务

　　微软事务处理服务被设计用于使的构造 高性能的、可变尺度的、可靠的internet和intranet应用程序更加容易。多年以前，我们就能构造这些应用程序了，但它所要求的才赋和投资超出了大多数公司的能力。

　　MTS以已被证实的事务处理方法为基础，但它的重要性超出了事务处理控制器的领域，它对分布式、以组件为基础的服务器应用程序定义了一个简单的 编程模式和执行环境。

　　应用程序由能够提供商业应用功能的微软ActiveX组件组合而成。这些组件似乎被开发用于单用户。通过在MTS环境下安装这些组件来执行它们，服务器应用程序能高性能的、可靠的自动改变尺度以支持同时存在的多客户。

　　MTS 被特别设计用于允许服务器应用程序在一个很大的用户范围内变化（从小的单用户系统到高容量的网络服务器）。它还具有通常只有高档的事务处理系统才具有的鲁棒性和完整性。

　　下面这部分对开发一个优秀的服务器应用程序的复杂性作一个简单的回顾。

　　我们从三个不同角度来讨论这个问题：

　　第一、它强调了一个网络服务器为提供合理水平服务所必须作的工作。

　　第二、它论述了当构造以组件为基础的应用程序所引起的问题。

　　第三、它描述了即使是在错误发生时，维持应用程序的完整的重要性。

　　MTS提供了一个应用程序编程模式，使得开发者避开了这些复杂之处，允许开发者将精力集中于程序的功能上，并降低了构造程序所需的费用和时间。

　　服务器基本结构

　　服务器要有一个高级的基础。从零开始建造一个网络应用服务器不是一件容易的事。完成实际的商业功能，例如处理在线书库的订单，实际只是工作的一小部分。典型的服务器系统必须有一个高级基础来获取可接受的性能和尺度。

　　应用程序服务开发者必须亲自经常开发基本构件中的许多部分。举个例子，序调用提供了丰富的服务，系统开发者仍必须作下面的工作：

　　注册目录系统服务器

　　管理服务器处理池和线程池；

　　最后，服务器需要为多用户请求提供的服务管理线程池，而不只是针对一个单用户。使多客户同时请求使用共享数据和资源的要求同步。这要求高级锁定协议能解释死锁、条件竞争、资源匮乏及其他性能上的问题。管理客户内容，包括数据库连接和数据结构的全视图。（目标视图）

　　客户缓冲状况以改善潜在慢速网络通行。

　　完成安全保障以确保商业功能和对象仅提供给被授权者。

　　完成管理和确认工具以允许服务器的远程安装和管理。

　　MTS提供了一个应用程序/服务器基本结构来满足上面的要求。

　　构造以组件为基础的应用程序

　　从组件构造应用程序对开发者有极大的吸引力并且是面向对象计算的早期目标之一。由于它提供了一个自然的方法来封装商业功能，因而对开发服务器应用程序更具吸引力。

　　然而，组件工程程序比它原来显现出来的要困难。早期对象系统的一个根本弱点是缺乏共同的框架来允许开发者无论是在同一进程或是交叉进程，都能将不同部分创造的对象结合到一个完整的程序里。组件对象模型（COM）解决了这个问题。

　　然而，简单的用一个COM模型来从组件构造服务器应用程序是不够的。该组件必须使用共同的服务框架。那些自己构造服务器框架的开发者使用其他组的组件开发程序的机会就会很小。

　　MTS程序工程师和编程界面提供了一个共同的框架来构造以组件为基础的服务器应用程序。

　　保持程序的完整性

　　非常重要的一点是，商业系统应能准确的维持商业状态。例如，一个在线书库必须可靠的跟踪订单。若不然，将会产生巨大的收入损失。现存的订单可能丢失或在取订单、填订单的时候有延时，不满意的用户可能会转到别处作生意。

　　维持商业系统的完整性从不容易，特别在发生错误以后。具有讽刺意义的是，即使计算机变的越来越可靠，系统作为一个整体变得更加不可靠。对提供internet和intranet连接到数十、数百、甚至可能数万个服务器上的无数桌式计算机来讲，错误是常事。

　　对分布式程序的要求使问题复杂化。商业事务，如订书，逐渐地卷入多个服务者，必须证实其信用，书必须船运，必须管理存货目录，并且客户必须有资金。这一切都使在多服务器上的多个数据库更新成为必须。分布式开发者必须预料到程序的某一部分能在其他部分发生错误后继续运行。这些防错方案是单个程序的好几倍。

　　商业程序经常被要求将多个工作协调为单个商业事务。一个在线书库绝对不能在没有处理恰当的订单前就去安排装运的日程，同时也不可能向用户收取费用而不通知其送货日期。协调这些工作使它们都发生或都不发生，若无特殊系统支持是非常困难的。

　　即使在发生错误时要确保程序最小单位的更新，是很不容易的。尤其当一个应用程序分布在多个数据库和系统上时。使用在设计上隐藏了其可完成性的多种组件造成了这个问题。

　　当多个用户获取同一组件时程序也必须能提供一致的行为。对同一本书同时的定单不应产生只送一本书给两个用户的情况。除非程序被正确书写，资源竞争最终将引起不一致性。这些问题很难解决并将花很多钱。并且随着程序增长和费用增多而更可能发生。这也是由于使用组件引起的。