摘要
以服务为导向的数据库体系结构（SODA）是一个新的用来构建高度可扩展以及可用的事务性数据库应用程序的技术。本白皮书介绍了SODA，将它放到一个和其它可扩展性技术一同的上下文中，并且描述了Microsoft® SQL Server™ 2005是如何支持SODA的。

内容列表

介绍
可扩展性概述
可扩展性方法
一般的硬件问题
向上扩展
向外扩展
透明向外扩展
非透明向外扩展
通过SODA向外扩展
以服务为导向的数据库体系结构
介绍
SODA的部件
数据库服务
服务间通信
本地XML支持
复杂的业务规则
参照数据
底层架构
SODA 和高可用性
SODA 服务代理
复制
SQL Server 2005 数据库服务
XML 支持
展示数据库服务
处理 XML
服务代理
Microsoft .NET Framework
复制
可扩展应用程序示例
结论

介绍
可扩展性对于任何一个数据库系统来说都是一个重要特征。它是指一个数据库系统在处理大量的事务，大量的数据，相当复杂的查询，以及更为复杂的应用程序需求方面的能力。Microsoft® SQL Server™ 2005在扩展性的全部四个方面都有重大的改进，并且它为处理大量的事务引入了一个新的结构化方法，即以服务为导向的数据库体系结构（SODA）。通过使用SODA，数据库变成了一组相互连接的高度可用的Web服务。

SODA十分接近的反映了在应用程序构建中的现代实践，即通过将数据库的处理过程按照服务边界进行划分来提供不受限制的可扩展性。服务可以被单独的扩展或者通过细分成新的服务来处理额外的负载，可用性，或者业务需求。每个服务都可被变成高度可用的，并且整个应用程序都可被设计成提供持续的可用性。本白皮书为以服务为导向的数据库体系结构以及SQL Server 2005支持它的方式提供了一个概况。

可扩展性概述
可扩展性是在计算机学领域里使用的一个术语，它被用来描述一个系统在处理不断增长工作量方面的能力。在事务处理的世界中，它主要被用来描述一个系统处理大量事务的能力，其次用来描述处理相当复杂应用程序的能力。在数据仓库的范畴内，这一术语通常用来描述一个系统在处理大量数据（VLDB）以及对这些数据进行的复杂查询方面的能力。本白皮书关注于系统在事务处理，主要是对大量事务处理方面的可扩展性。

在最近的五年里，对于硬件，操作系统，以及数据库管理系统方面的改进已经给单个的数据库系统能够支持的事务峰值带来了20倍的增长。而在这些方面的改进会继续驱动事务量峰值的提升。通过更改数据库和数据库应用程序构建和部署的方式，甚至可能付出更低的代价就可以得到更大的改进。而SODA就是在后面这些方面起到作用的。在深入研究SODA之前，回顾一下在扩展性方面的问题和传统的技术是很有帮助的。

可扩展性方法
软件设计者在试图找到如何利用硬件上开发出的新技术上，或者在提供超出以前在硬件上可以使用的功能的软件上花费了大量的时间。在可扩展性这个领域，已经发展出了两种基本的方法，向上扩展和向外扩展。使用向上扩展，硬件设计者要提供更强以及更快的计算机系统，软件设计者随后就要解决如何利用这些系统的问题。使用向外扩展，软件设计者通过将多个计算机系统连接在一起来创建一个更大的系统网络，它能够处理的事务量可以大大的超过单个计算机系统。向上扩展和向外扩展都有其优点和缺点，并且在每种基本方法中又都有几个变种。高端应用程序经常需要将这两种方法结合使用。

一般的硬件问题
在单个计算机处理器级别上，差不多每18个月性能会翻一番。这种现象称为摩尔定律，这个速度是由半导体生产技术的改进所导致的。在计算机系统级别，情况可能要更复杂一些。尽管可以从单个处理器的计算能力提升中得到速度的提升，但许多应用程序系统的需求远远大于单个处理器所能提供的。将多个处理器一起装到一个系统中可能是复杂，昂贵的，并且会导致得到的聚合计算能力低于预期。例如，与使用单个处理器的性能相比，连接四个处理器可能只会得到事务处理率仅三倍的提升。

事务性应用程序通常会产生极高强度的I/O操作，而我们在计算机系统设计时的大多数注意力都关注在让I/O操作的能力与处理器能力的匹配上。如果没有足够的I/O操作能力，在增加处理器的数量时甚至只能得到很小的性能改进。

由于添加大量的处理器同时又要保证有足够的I/O能力增长的成本问题，因而为提高事务处理率这样做时会导致收益递减效应。更进一步的讲，在一个现有的计算机系统中放置更快速的处理器带来的整体系统性能改进并不象处理器性能本身增长的那样大，原因在于整体系统失去了平衡。这一点在那些使用大量处理器的系统中是需要特别注意的，同时为将硬件改进同比例的转化为扩展能力增长设置了障碍。

当很多驻留数据库系统的服务器使用了多达64个的处理器时，实际上“sweet spot”是4路处理器系统。在应用程序级别，4路处理器系统对于满足绝大多数的用户的扩展能力需要已经足够了。在技术层面上，4路处理器系统通过使用一些低成本的常见技术来构建，就可让整体的性能改进跟上处理器性能改进的步伐。由于4路处理器系统可以满足应用程序的需要，并且这种需要的增长达不到摩尔定律的速度，因而使用一个4路处理器系统并且每隔几年升一下级，不失为一个最简单而且经济有效的获得扩展能力的解决方案。对于那些需求的增长比率超过了摩尔定律的速度，或者不适合使用一个4路处理器系统的应用程序而言，就需要使用向上扩展或者向外扩展技术来进一步提高扩展能力。

向上扩展
向上扩展这种方法仅仅使用一个强大的单计算机系统来处理增加的事务量。典型情况下，这个方案包括使用更多的处理器以及补充I/O处理能力等手段。它可以简单到只是将一个单处理器系统升级到使用双处理器，或者复杂到在一个计算机上安装64个处理器。向上扩展的主要好处是，系统软件可以让处理器的添加变得对于应用程序和操作者而言是完全透明的。你只需要添加处理器然后你的最大事务处理率就会上升。这就使向上扩展成为对大多数应用程序而言的最有魅力的选择。如果使用一个处理器让你的系统变得疲软，你可以升级到一个双处理器系统。如果双处理器也不行了，你可以再升级到一个4处理器系统。而且你还可以不断的升级到8, 16, 32, 甚至 64个处理器。为什么有了这么简单的一个提高可扩展性的解决方案，还需要有其它方案呢？

正如前面所提到的，使用大量的处理器并不时的还要对它们进行扩展还是有相当难度的。结果是在超过了4处理器范围后，与其产生的扩展能力增长速率相比，系统成本会增加得更快一些。在这些强大的系统中主要的成本增加存在于体系结构方面而不是每个处理器的成本。

例如，如果你现在需要4个处理器但是明年可能需要8个，并且在未来的某个时间可能会需要16个，那么你就必须购买一个可支持16个处理器的昂贵系统，以提前做好准备。这样从价格上看，使用4个处理器系统和更多处理器系统之间的差距就非常之大。另外，当可用性的考虑被加入进来后，通常有必要放置备用的计算机系统。这就更加放大了使用4处理器系统和更大系统之间的成本差距。同时也只有少数的应用程序有着超过一个64个处理器系统能力的扩展能力需要。另外一个问题是由于业务和组织的需要可能某个应用程序需要被分散化使用。
不过对于多数的需要提供比4处理器系统更大的可扩展性的用户来说，即使有着高昂的初始成本，向上扩展到一个有大量处理器的系统仍不失为一个最佳的方法。通过在增加扩展能力的同时不断努力的控制应用程序和操作上的成本，向上扩展方案仍能保持较低的整体拥有成本。

向外扩展
向外扩展采用了将不断增加的工作量分布到另外的计算机系统去处理的方式。在最近几年出现的一个典型的例子是Web服务器场。在它们简单的工作方式当中，Web服务器会响应对只读类型数据页发出的请求。由于数据是只读的，因此可以比较容易的将它们在许多Web服务器间进行复制。对于特定页的请求随后可以被路由到场中任何符合要求的可用的服务器那里。当对某些页的请求的比率增加时，其它的服务器将会添加到场中并为其Web站点提供一份页的副本。软件，或者一个networking box，将会自动的把一部份的请求重定向到新的box。其可扩展性几乎是不受限制的。在这种方法中有着五花八门的各种基本概念，但应用到数据库系统当中的只是一小部份。
数据库系统和许多其它类型的系统在维护一个共享的，可更新的，稳定的状态方面是有一些差异的。想象一下如果我们试着将Web服务器场直接应用到数据库上的情景。例如，设想一个数据库中包含了一个特定航班的登记记录并且将这些记录拷贝给了许多不同的服务器。当网络重定向程序将用户A的为其保留21A座位的请求传递给了服务器#1，而用户B对21A座位的订票请求被重定向到了服务器#7后会发生什么问题？在一个运行“场”类型的应用环境中，两台服务器都独立的满足了两个用户的请求，但21A座位实际上不适当的分配给了两个乘客。为了解决这种问题，或者将所有对21A座位的请求都交给同样的服务器处理或者多台服务器必须协调它们的更新。如此一来就使得与诸如web和应用程序服务器这样的“stateless”服务器相比，数据库服务器的向外扩展要更难一些。
由于透明度概念的出现，数据库的向外扩展变得更为复杂。对于Web访问而言，透明度是处于Web地址（URL）级别的。当你访问位于http://www.microsoft.com 的Web页时，在微软的Web服务器场中的任何一台服务器都可以为你提供该页。用户（在使用一个Web服务时也可能是应用程序）没有必要知道哪个服务器接受了他的请求。那么对于数据库应用程序而言希望或者需要的透明度级别是什么呢？如果你希望打印出一个乘客的旅行路线，哪个地方的信息可以告诉你100号航班的座位分配记录在服务器#1上而200号航班的记录存储在服务器#7上呢？再深入一步，谁负责将这所有的信息收集到一起并且通过一个应答提供给你呢？是数据库系统还是应用程序呢？

在过去，数据库的向外扩展技术从一个变成了两个类别：透明的和非透明的。SQL Server 2005为我们带来了第三个类别，那就是以服务为导向的数据库体系结构。

透明向外扩展
透明向外扩展试图将向上扩展解决方案使用的扩展方法克隆到跨越一组联网的，或者松散连接的计算机系统上。在一个理想的情况下，获得额外的处理能力只需要简单的在网络中添加新的计算机系统。而应用程序和数据库架构都不需要做任何的改变，并且在资源发生变化时工作负荷可以在系统间动态的重新均衡。应用程序可以简单的访问数据库，甚至不需要了解它的数据是如何跨多个计算系统分布的。如同向上扩展的解决方案一样，无论是应用还是工作负荷的扩展能力都得到了增强。不幸的是，即使已经经过了二十多年的发展，这个梦想还是没有实现。换一个角度看，其主要的问题就在于在对共享数据访问的协调以及将（潜在的）从多个节点返回的结果合并到一个对数据库请求的响应中的过程中需要所连接的计算机系统付出极大的通信开销，这已经超出了计算机所能提供的计算能力。

今天的透明向外扩展解决方案只能在两种环境下提供适当的扩展能力。其中最成功的数据库向外扩展发生在一个工作负荷几乎全部由读请求组成的环境下。当很少或者没有更新活动发生时，所需的跨节点通信资源是最少的，这样就有足够的计算资源来应付请求了。对于很多的应用程序来讲，在面临处理大量读请求的问题时复制可以提供一个高级的解决方案。

另外一个成功的环境就是对那些可以被细致的分区的跨节点数据库，此时应用程序的请求被定向到包含它们所需数据的分区。如果请求被路由到了正确的服务器分区并且只有很少的请求需要跨分区访问数据，也可以节省下许多计算资源来满足请求。

尽管这种技术提供了处于数据库请求（SQL）级别的透明度，为了让应用程序更好的扩展，应用程序必须了解分区架构并且避免进行跨越分区边界的请求。当负载变化时，数据库和应用程序都必须对此作出响应并进行修正。不过应用程序需求的变化可能造成细致分区变得无效从而导致严重的性能下降。这也是导致透明向外扩展技术在静态的环境下比在多数实际应用程序所工作的动态环境下使用更为成功的原因。

非透明向外扩展
非透明向外扩展技术有几个变种，不过它通常指的是使用多个独立服务器来运行不同数据库的方法。一个需要在两个或更多不同数据库中数据的应用程序会直接连接到这些数据库并且分别提交两个数据库请求。应用程序负责合并这些请求的返回的结果。很多情况下，会将数据库根据功能进行分区。例如，一个数据库可能包含了目录数据而另外一个可能包含消费者数据。另外一些情况下，数据可能根据值来进行分区，比如一个数据库包含了在东区的消费者的数据而另外一个包含了西区消费者信息。对这些系统进行扩展可能还相当不错，但数据库开发以及维护的担子是很重的。

大多数成功使用非透明向外扩展的例子是在那些一个应用程序不直接访问超过一个以上数据库的情形下出现的。相应的，应用程序的部件直接访问仅仅一个数据库并且向其它的应用程序部件发出对不直接在它们控制下的数据库的数据的请求。这些请求可能通过Web服务，以消息为导向的中间件，RPC，或者甚至是批处理来发出。复制常常被用来让只读的数据，比如参考或者目录数据，在多个节点上可用，从而避免了一个中央数据库成为这些数据的瓶颈。

通过SODA向外扩展
使用以服务为导向的数据库体系结构或者叫SODA，数据库可以根据符合应用程序需求的准确定义的服务边界进行分解。这些数据库服务随后可以驻留在一个单服务器节点上，或者多服务器节点，以获得需要的可扩展性级别。
不象透明的向外扩展，SODA避免了SQL级别的跨分区的操作，以及由它们带来的所有可扩展限制，有利于在数据库服务之间良好定义的请求。另外，与非透明向外扩展不同的是，SODA集成了对服务接口以及服务间通信，还有直接路由到数据库系统的支持，因而减轻了应用程序开发和维护的负担。本白皮书剩下的部份将会解释SODA并且提供了一个关于SQL Server 2005支持SODA的方式的概况。

以服务为导向的数据库体系结构
介绍
在过去的几年中，应用程序体系结构开始向着由某些类型的中间件连接的独立应用程序系统方向发展。例如，一个电子商务应用程序可以拥有完全独立的应用程序系统来进行基于Web的订单记录，用户跟踪，内部“heads down”订单记录，配送，运货，制造，以及信用处理。不是使用一个集中的数据库来支持所有这些应用，而代之以每个应用程序系统都有着一个或者几个它们自己的数据库。此时没有跨数据库的操作。

相应的，应用程序系统间相互通信是通过良好设计的接口来获取完成它们自身操作所需的数据　的，同时也对其它应用程序系统所拥有的数据进行修改。某些应用程序系统，比如运货的，可能是第三方所拥有的，不需要直接访问数据库。在应用程序系统之间交换XML文档的需求与日俱增。在历史上看，数据库系统只对此类的应用程序体系结构提供了很少的支持，这为应用程序开发者设置了一个重大的障碍。而以服务为导向的数据库体系结构将对此类应用程序体系结构的支持直接植入了数据库系统。

从70年代到80年代中期，数据库系统在关于应用程序体系结构这方面还几乎是一片空白。它们只是被动的存储，可以通过调用一个应用程序编程接口（API）使用数据语言（其中最流行的就是SQL）请求来读写数据。所有的业务和数据完整性规则都是由应用程序负责的。

作为专用的以及4GL应用程序开发工具得到广泛使用的结果，在八十年代中期数据库系统开始引入了创建数据完整性规则和少量业务逻辑的功能。这样就允许多个应用程序，或者甚至是最终用户，来直接访问数据库而不破坏它的内容。在八十年代后期，随着个人计算机的广泛使用，希望直接访问数据库的需要直接导致了为数据库系统开发一个完整的应用程序体系结构的结果。业务逻辑和数据完整性规则可以被组合到存储过程当中，它使用了SQL的过程化扩展，应用程序使用远程过程调用(RPC)来调用它。这成为了经典的两层结构的客户端/服务器应用模型。对于多层应用程序模型而言，它组合了通过SQL直接和使用存储过程进行应用程序数据访问，以及用来维护数据完整性和强制一些业务逻辑的触发器和约束等技术。当对基本的模型已经做了很多的精炼后，整体数据库应用程序体系结构在过去的十五年中只有些微的改变。

为了让数据库系统能够与现代的应用程序体系结构相同步，需要对传统的数据库应用程序体系结构进行大量实质上的改变：
•        现有模型中的数据直接访问以及使用数据库RPCs对存储过程的调用技术必须用对通过Web服务公布数据的本地支持来加以充实。这样就允许中间层，外部伙伴，甚至客户端应用程序与数据库系统通信，就如同应用程序之间的相互通信
•        这些Web或者数据库服务必须通过一个机制连接在一起，以允许将复杂的应用程序系统整合到数据库系统当中
•        数据库系统必须能够天生处理现代应用程序使用的通用语言，XML。
•        数据库系统必须支持将应用程序开发人员所写的任意的复杂业务逻辑组合到数据库服务当中，而这些开发者没有必要是数据库专家
•        数据库系统必须提供对可能需要跨越服务边界处理参照数据的支持
•        数据库系统必须提供让服务高度可用并允许对它们进行监视和维护的结构
将这些元素综合到一起就组成了以服务为导向的数据库体系结构(SODA)。

SODA是应用程序体系结构中用来开发高度可扩展和可用的数据库应用程序的方法。通过支持数据库沿着逻辑的应用程序服务边界来进行设计，SODA说明了在吞吐量的需要上升时应如何对整体数据库系统进行扩展。

一个应用程序可能初始时是由运行在单个物理服务器上的几个数据库服务组成的。当需求上升时，单个的数据库服务可以被移动到其它服务器上而无需改变应用程序或数据库。SODA将对何时应用向上扩展或者向外扩展的决策转化为了一个经济问题。当吞吐量需求增长时，驻留数据库服务的服务器可以向上扩展，或者可以添加新的服务器并且在它们之间重新分布数据库服务。即使在一个非常高吞吐量的应用程序中，常见的服务器（4个处理器插槽或更少一点）对大多数的单个的数据库服务而言仍然适用。如果某个特殊的数据库服务有着较高的吞吐量需要，它可以在一台比较强大的服务器上运行或者设计时将其划分成几个服务。

SODA的部件
SODA是由六个部件组合而成的，它们共同提供了一个新的数据库应用程序体系结构。这些部件既可以在某个应用程序中单独使用，也可以和传统的数据库结合到一块使用。由于可扩展性是本文的焦点，因此与其它的相比，对其中的某些部件我们给予了更大的关注。

数据库服务
数据库服务的概念是SODA及其可扩展性模型的中心内容。在一个逻辑的层面上，一个数据库服务为数据提供了一个良好组织的应用程序级别的接口。它不是一个通常意义上的用来读写数据的数据库接口，而是用来提供非常特定的应用程序功能的。例如，一个记录存货清单的数据库服务可能提供了用来检查存货级别，保留存货，从存货清单中删除产品，记录新的运货收件人，以及管理退货的方法。听上去它可能与客户端/服务器世界中的存储过程以及数据库RPC很相似，不过它们有两个重要区别。

在数据库服务和传统模型之间的第一个区别是在一个数据库服务控制下的数据访问与一个不同的数据库服务控制下的数据访问是完全隔离的。举个例子，一个订单记录数据库服务从不直接的处理与存货记录相关的表。总是通过调用存货清单数据库服务来处理存货记录的。正如随后所显示的那样，如此一来让向外扩展变得非常容易。
第二点区别是，对数据库服务的请求并不是通过一个数据库连接发出的，相对的，服务会呈现为Web 服务。通过打破传统的将一个数据库和它的存储过程由一个连接关联起来的作法，使得将服务分布到多个服务器而无须对应用程序的代码进行改变成为了现实。例如，在一个传统的模型中，可能有一套针对存货的存储过程而另一套是对应订单记录的。为了调用这些存储过程，你需要建立一个到某个指定数据库服务器的连接然后通过这条连接来调用两套存储过程。如果你随后想要将存货和订单记录功能分别放到两个数据库服务器上，你必须修改执行调用的应用程序以建立两个单独的连接并且在对应的连接上来调用存储过程。这对于数据库服务是没有必要的，因为每个服务都可被移动而不需要更改应用程序。

从一个设计者的观点上看，可能要花上很长的时间在考虑应用程序使用服务，将它们设计成拥有独立的数据，对每个服务建立独立的连接，以及通过Web服务来发布你的存储过程上。尽管如此，对于将这些服务整合到一个应用程序当中去是由应用程序的代码负责的，而不是只能提供一点帮助的数据库系统。让数据库服务真正应用于实践的方法是增加的服务间通信。

服务间通信
与传统的数据库应用程序体系结构相比，SODA的一个区别于其它的特点是其用来整合数据库服务的丰富的服务器间通信机制。SODA依靠一个异步的事务性消息系统来进行数据库服务之间的通信。这和使用以消息为导向的中间件很相似。不过，SODA的服务代理是与数据库系统紧密集成的。

服务代理使得一个数据库服务可以对其它的数据库服务发出请求而不用关心其它服务的物理位置，或者大多数情况下，对方当前的可用性。它支持异步的请求方式——可以选择立刻响应或者不响应，还有当两个服务共同工作来完成对单个请求的处理时的对话功能。它也提供了一个用来通信的事务模型，这个模型是和数据库系统的事务模型集成在一起的，但没有传统的分两个阶段提交机制的限制。

设想一下对存储在两个不同的数据库中的数据进行更新时出现的问题，其中一个数据库使用SODA，另一个使用传统的应用程序体系结构。使用SODA的那个，订单记录应用程序向一个订单记录数据库服务的接口发出了一个Web服务请求来处理订单。对于订单上的每一个货物，订单处理数据库服务都会发送一个消息给存货管理数据库服务，请求为该订单保留存货。订单记录数据库服务也会给信用管理数据库服务发送消息来检查消费者帐户的状态，给配送数据库服务发送来获取估计的运货时期，给运货服务发送……以此类推。

在某些情况下，订单记录数据库服务将会等待一个回应并且直到接收到回应（例如，“保留存货”）才会结束事务。在另外一些情况下，它可能会试图在事务结束之前收到一个回应，但不会阻止结束（比如，“信用检查”）。在某些情况下，它甚至不会试图接收一个回应并且作为对一个异步进程的中止发送消息（例如，“完成订单”）。不过，所有的通信都会和事务联系在一起并且如果事务没有结束就会失败。例如，当发出“完成订单”消息后，只有在订单记录数据库服务中的本地数据库事务已经提交后才会结束。与其对照的是使用传统数据库应用程序体系结构时，必须建立到每个数据库的连接，所有的通信都是同步的，并且必须通过一个被分两个阶段提交机制所控制的包含所有数据库的一个事务来协商完成。

SODA服务代理允许数据库服务被组合到更强大的应用程序中而不受所有数据必须存储在一个数据库中的限制，也不受笨拙的使用多个连接以及分两个阶段提交机制的限制。对于数据库服务的位置它添加了更大的透明性，并且提供了一个可被用来实现持续可用应用程序的机制。这些特点将在我们对SODA的其它部件描述之后更深刻的表现出来。

本地XML支持
XML已经快速成为业务应用程序中的通用语言，SODA很大程度上依赖于对XML的本地支持。在SODA中使用的XML或深或浅。在那些用得比较浅的情形中，XML仅被用作一个Web服务调用或者一个消息服务请求中的参数编码。而在用得较为深入的情形中，某个参数本身就是一个需要处理的复杂的XML文档。无论在哪种情形下，SODA都需要数据库系统提供对XML处理的增强的本地处理能力。这些能力包括对XML文档的编码，处理以及生成，当然还包括了在数据库中直接存储和使用XML的能力。不过，SODA的这些方面和可扩展性并无直接联系，因此不需要做更深入的讨论。

复杂的业务规则
数据库服务鼓励数据库系统比传统的管理更多的业务逻辑。为了在数据库系统内部对客户端/服务器应用程序体系结构的提供支持，通过使用SQL的过程化扩展实现业务规则的能力被添加到了数据库系统当中。从理论上说，这样就允许在数据库系统当中实现大量业务规则。不过在实践中，只有那些和数据完整性有关系的规则才使用这种方式实现。主要的原因有两个。

首先，典型的应用程序开发人员通常是使用诸如Microsoft® C#®, C++®, 以及 Visual Basic®这样的语言而不是象Transact-SQL这样的过程化SQL语言来编程的。其次，过程化SQL对于计算型的复杂业务规则的支持较为薄弱。而在SODA中，这两点限制通过支持使用通用目的的编程语言来在数据库系统中创建业务规则已经消除了。SODA的这一方面和可扩展性没有直接的关系因而不再进行更深入的讨论了。

参照数据
SODA认识到有大量的参照数据需要用相当广泛而又低开销的方式去访问。参照数据通常指的是这样的数据，它们存储在集中的位置，很少进行更新然后从多个位置以只读的方式来访问。例子包括价格表，其中的信息每个季度更新一次。产品目录信息比如订单号和产品描述可能每天或者每个小时才需要更新一次，以及一些业务规则比如给一个新用户的信用指南。参照数据也可以包括那些大多用来读取，不常更新而允许进行拷贝的数据。一个相应的例子就是一个商业系统中的消费者跟踪信息。通过使用复制技术，SODA对只读的和大多用来读取的参照数据都提供了支持。数据可以从数据库服务内部或者直接从中间层应用程序服务器来访问。

在SODA中对参照数据的支持可以成为使系统能够得以提高其扩展能力，还有可用性的关键，我们将会在后面对此进行深入的讨论。

底层架构
SODA应用程序体系结构是依靠一个丰富，支持性质的底层架构来实现的。它必须能够实现，调试，部署，监视以及维护数据库服务。它也必须能够使它们高度可用和强壮。此外，为了扩展，它必须易于重新配置它们的拓朴结构。在SODA中由于底层架构仅仅扮演一个虽然重要但仅仅是支持性的角色，因而在本文中它不会受到特殊的对待。尽管如此，这个架构的一些有关可扩展能力和可用性的特殊的部份仍将讨论。

SODA 和高可用性
使用SODA来设计应用程序可以获得的主要好处之一是它们天生就会获得极高的可用性级别。和传统的数据库服务器相比，单个的数据库服务可以通过使用诸如故障转移群集或者数据库镜像这样的技术在出现硬件或者软件失败时进行保护。而基于SODA的应用程序可以设计成在单个的服务失败时仍能继续工作。这样就让基于SODA的应用程序可以获得近乎连续的可用性。来获得持续可用性的两个关键SODA技术是服务代理和复制。

SODA 服务代理
正如前面所描述的，SODA服务代理提供了一个在数据库服务之间的异步事务性消息系统。为了提高一个应用程序的可用性，这个消息系统可以在两种方式下使用。第一种方式，在出现临时的失败时消息系统在服务之间提供完全的透明度。例如，如果一个Web订单记录服务向存货服务发出了一个请求，而此时存货服务正在从一个失败中恢复（比如通过一个故障转移群集的转换）的过程中，当辅助服务器接管之后请求就将被透明的响应。甚至在发生了灾难时，比如一个因电源短缺导致的向另外地理位置的镜像数据库进行故障转移时，Web订单记录服务的请求仍能被透明的路由到存货服务那里。

SODA服务代理可被用来获取持续可用性的第二种方式是，当与另外一个服务的通信可能在很长时间内都会失去时，使用指定的incorporate point。例如，在一个传统的订单记录系统中，订单的信息被直接输入到和处理它的订单执行系统所在的同一个数据库中。如果这个数据库不可用了，对订单信息的接受与执行都会停下来。在一个基于SODA的系统中，订单记录服务向订单执行系统发出异步的请求。如果订单执行系统不可用，这些请求将会保留在订单记录系统所在的数据库当中直到通信重新建立。即使订单执行系统几个小时或几天不可用，订单记录系统将会保持完全可操作。除了应付那些可以通过故障转移群集或者镜像技术解决的未计划的失败，此过程可以让一个应用程序在出现了计划中的问题时继续运作。

例如，订单执行系统可以为了进行关键的升级而被离线，同时不会影响一个业务接受订单的能力。同样的，在接受订单的系统被中断时也不会影响处理当前订单的执行系统。

复制
正如之前所讨论的，复制被用来让参照数据的多份拷贝在不同的服务器同时使用。这样就允许多个服务中的每一个都能提供同样的数据库服务，从而提高可扩展性和可用性。使用前面的例子，一个应用程序的订单记录部份非常适合这个解决方案。通过跨几台服务器的复制目录和消费者跟踪信息，其中的每一台服务都有能力接受来自于任何消费者的订单。任何单个服务器的失败可能会导致在这台服务器上还没有通过检查的购物车中的信息的丢失。不过，应用程序能够通过其它的服务器继续接受订单。

SQL Server 2005 数据库服务
尽管有可能，将数据库作为服务来实现只会得到来自底层数据库管理系统的很少支持或者根本没有支持，而这种做法唯一可能付诸实践是当底层系统可以提供充分的支持时。SQL Server 2005是第一个关注于提供对将数据库作为服务的充分支持的数据库管理系统。特别是SQL Server 2005中的增强的XML支持和新的服务代理为创建数据库服务提供了支柱。对Microsoft® .NET Framework的支持提供了实现复杂业务规则的必要环境，而复制的改进提供了对参照数据的增强的支持。此外，新的特性，比如peer-to-peer事务性复制，为向外扩展大多用来读取的数据提供了良好的支持。最终，这些能力可以和SQL Server 2005中其它的可扩展性，可用性，可编程性以及可管理性改进共同使用。

XML 支持
SQL Server 2000主要通过一个称为SQLXML的中间层部件为XML和XML Web服务提供了有限的支持。SQL Server 2005在数据库引擎中天生就提供了对XML的广泛的支持。这包括对本地XML Web服务访问，一个本地XML数据类型，以及XQuery的支持。

展示数据库服务
实现SODA的一个主要的需求就是将数据库作为一组Web服务显现出来的能力。SQL Server 2005通过其实现的本地SOAP访问来满足这种需求。本地HTTP SOAP访问允许对SQL Server 2005 Web服务的直接访问而无须一个作为中间层的IIS服务器，也不需要客户端数据库软件。任何应用程序都可以调用Web服务，任何开发工具集都支持生成对Web服务的调用，并且任何平台（诸如Windows, UNIX, 和 Linux）都可以访问SQL Server 2005 Web服务而无须任何特殊编程。

处理 XML
由于一个数据库服务被作为一个Web服务来展示，它通常希望处理XML文档。SQL Server 2005提供了对XML的扩展的本地支持。特别是，一个新的XML数据类型允许在数据库中对XML的本地化存储。XQuery是为使用XML数据类型存储的数据查询而提供的，并且它扩展了插入，更新以及删除XML文档或者分片的功能。对FOR XML 和 OPENXML Transact-SQL的支持是提供用来在XML和关系型格式之间进行转换的。综上所述，这些能力允许一个数据库服务用XML来面对外部世界，同时用最恰当的格式在内部来存储和处理数据。

服务代理
使用SODA进行扩展的关键是将整个的应用程序系统由一套数据库服务来组成的能力。SQL Server 2005服务代理就是设计用来为SODA提供一个全面的服务间通信机制的。服务代理为SQL Server提供了一个可靠的，持久的，事务性的以及异步的通信功能。服务代理也提供了位置透明度，这样就允许调用应用程序不需要知道一个消息将会在本地，在同一台服务器的另一个SQL Server实例或者在一个远程服务器上处理。

Microsoft .NET Framework
SODA促进了在数据库服务中复杂业务逻辑的实现。Transact-SQL是实现业务逻辑的其中一个选择。SQL Server 2005通过提供Microsoft .NET Framework 通用语言运行时 (CLR)为我们提供了第二个选择。这样就允许使用诸如C#, J#, 以及 Visual Basic .NET等传统的编程语言来实现业务逻辑。

复制
一个可以提高扩展能力的主要方法是让参照数据拥有多个副本。SQL Server 2005的复制提供了维护只读数据（比如产品目录数据）以及大多用于读取的数据（比如消费者跟踪信息）的多个副本的工具。通过允许对数据的任何副本的更新，就为大多用于读取的数据提供了出色的支持。这样就带来了一个额外的好处，即可以在任何的数据副本离线进行维护时（比如为软件打补丁时）而不中断整个系统的工作。

可扩展应用程序示例
这一部份展示了一个使用SQL Server 2005的以服务为导向的数据库体系结构来创建的N层结构的电子商务Web应用程序的一部份作为示例。此模块执行了订单接受以及订单处理任务。这个应用程序的设计目标是，它应当便于增强，扩展以及集成，从而有效的为核心业务需求服务。下面是该模块的业务需求：
•        接受订单
•        处理订单 (包括信用卡处理，存货清单，配送，以及运货)
•        读取消费者跟踪信息
•        读取产品目录
•        发送email确认订单以及订单进展报告
•        允许其它的应用程序和系统在存货级别进行查询
•        在接受订单的过程中尽可能的缩短交互的响应时间
•        通过将一部份消费者的跟踪信息以及产品目录数据进行缓存来使性能最大化
在查看基于SQL Server 2005 SODA的解决方案之前，下面的图表展示了SQL Server 2000是如何实现这些功能的。



正如图表1所展示的那样，基于浏览器的客户端通过HTTP发送请求给IIS 6.0 Web服务器，服务器上拥有一个用来接受订单的ASP.NET Web站点。ASP.NET的代码使用ADO.NET来和一个SQL Server 2000的订单记录及订单处理数据库进行通信。SQLXML 3.0 Web服务支持是用来展示存货级别的查询API的。ASP.NET代码所实现的对消费者跟踪信息以及产品目录明细的缓存使得到数据库服务器的回程时间被缩短了。SQL Mail建立在SQL Server之上并且通过发送电子邮件来确认订单以及订单进展报告。

下面列举了一些此类体系结构的限制：
•        订单记录和订单处理数据库是在单个服务器上存储的，这样就限制了应用程序的扩展能力。因而唯一的选择是进行向上扩展。另外这种方法存在单点失败的问题。如果SQL Server离线了，Web站点就无法继续接受订单
•        SQLXML通过将Web服务的方法映射到现存的存储过程来展示存货级别的查询API。SQLXML的存在就造成了对安装和维护的额外需求。ASP.NET可以用来提供这个API。不过，它需要编写和维护额外的代码
•        SQL Mail需要一个MAPI的客户端安装在SQL Server服务器上。另外，SQL Mail是无法扩展的
•        ASP.NET的代码将已经访问过的部份的产品目录和消费者跟踪信息缓存了下来。现有的技术并没有提供一个能够在数据进行了修改后自动对缓存进行刷新的解决方案。ASP.NET代码不得不针对可能出现的数据修改或者周期性地刷新缓存或者对服务器进行轮询，或者也可以实现一个自定义的解决方案可以指出被缓存的数据已经修改了

订单处理可以被分离到另外一个服务器上。不过，这样可能需要分两阶段的提交以及实现分布式事务。消费者跟踪信息和产品目录在两台服务器上必须都可以访问。一个解决方案是仍将数据放置在一台服务器上而从另外一个服务器上使用一个链接服务器和分布式查询来完成对数据的访问。一个更好的方案是在两台服务器上都放置一份数据的本地副本并且使用事务复制来复制消费者跟踪信息和产品目录。不过，事务复制对于大多用来读取的数据而言不太适合。这个方案在图表2中进行了描述。



现在设想一下SQL Server 2005是如何面对以前所描述的这些限制并且是如何允许创建一个可扩展以及松散耦合的数据库应用程序的。



正如图表3所展示的那样，订单记录和订单处理现在被分别放到了两台服务器上，由此使它成为了一个更可扩展的解决方案。另外，该设计增加了可用性，因为即使在订单处理服务器down机时，Web站点也可以继续接受订单。
当一个订单被提交时，一个记录就会生成在订单记录数据库中。几乎在同时，一个消息被放到了一个服务代理队列中。订单记录进程在此结束。该队列消息随后被路由到存储订单处理数据库的SQL Server 2005服务器那里。如果订单处理服务器离线了，消息会在订单记录数据库的队列中保持到订单处理数据库可用时。

当一个消息被订单处理数据器接收到时，不同的任务诸如存货，配送，以及运货都开始执行了。最终，一个响应消息使用服务代理被送回到订单记录服务器，服务代理随后使用SQLiMail发送订单确认邮件。这几个任务都是便于扩展的并且可以单独的更新和升级其功能。

SQLiMail使用服务代理，让它成为了一个可扩展的电子邮件解决方案。作为替换的方案，SQL Server通知服务也可被用来发送电子邮件。使用针对跨服务器的异步消息系统的服务代理清除了使用分布式事务以及分两阶段提交的需要。而且，服务代理可以辅助于向外扩展体系结构以及缩短交互的响应时间。该体系结构增加了可用性，消除了对一个外部消息解决方案或产品的需要，并且简化了对分布式数据库应用程序的实现。

订单处理服务器使用HTTP SOAP终结点来展示存货级别查询的API。HTTP SOAP终结点消除了对SQLXML和IIS的需要，同时也通过消除了额外的IIS和SQLXML层提供了更好的性能。

新的peer-to-peer事务复制配置在订单记录和订单处理数据库之间来复制消费者跟踪信息和产品目录数据。peer-to-peer事务复制与传统的事务复制相比，对于大多用来读取的数据的复制更为高级并可提供更好的性能。
ASP.NET Web站点的代理使用了新的查询通知机制来刷新缓存的产品目录和消费者跟踪数据。查询通知使用服务代理来异步的通知订阅的ASP.NET代码关于数据库更改的信息。
之前的设计是松散耦合的并且支持基于标准的Web服务从而便于集成和扩展。使用了服务代理，查询通知以及SQLiMail让它成为了一个在负载增加时可以良好扩展的解决方案。对peer-to-peer复制的使用为共享大多用于读取的产品目录和消费者跟踪数据提供了一个高级的解决方案。另外，无论在何处应用，之前的设计都可以利用XML数据类型以及XQuery功能来本地化存储和查询非结构化的数据。它也可以使用SQLCLR来扩展类型系统和聚合函数，或者来实现复杂的业务规则。

结论
以服务为导向的数据库体系结构提供了构建高可扩展能力，高可用的数据库的功能。通过将透明度边界移到服务级别，SODA避免了SQL语句级别的向外扩展解决方案的扩展限制。通过它的高度可靠的服务间通信机制，SODA支持了对可获得近乎持续可用性的数据库的设计。  
尽管本文关注于SODA作为获得可扩展性的基础的作用，SODA可以提供的远远不止这些。它是一个非常适合用来集成传统的和新一代的数据库应用程序的体系结构。而且，它是一个允许做更多的革新的体系结构，它通过将不同的服务“重新连线”以及使用新的数据库服务就可以满足新的业务需求。
这些特点让SODA成为一个构建可扩展SQL Server 2005数据库应用程序的理想的体系结构。

版权说明
该白皮书为初步文档，可能会在所述软件进行最后商业发布之前做完全修改。
该文档所含信息代表微软公司在文档出版时对所论及问题的当前看法。由于微软必须对千变万化的市场情况做出相应反应，因此本文档不应视为微软的任何承诺，且微软不保证所陈述任何信息在产品发布后的准确性。
本白皮书仅供信息参考。微软对本文件中的信息不做任何明示或默示保证。
遵守所有适用的版权法律是用户应尽的责任。下述陈述不限制任何版权，在未获得微软公司明示书面许可的情况下，不得以任何目的复制本文档任何部分或将任何部分保存或引入检索系统、亦不得以任何形式（电子、机械、影印、录制或其他方式）进行传播。
微软在文件所述主题中拥有专利权、专利应用程序、商标、版权或其他知识产权。除非在微软的任何书面许可协议中明示规定，否则对本文档的提供不得视为对任何专利权、商标、版权或其他知识产权许可的提供。
除非特别声明，本文中描述的示例公司、组织、产品、域名、e-mail地址、徽标、人物、地点以及事件均为虚构的，不应与任何实际的公司、组织、产品、域名、e-mail地址、徽标、人物、地点以及事件有任何的联系。
© 2005微软公司版权所有。
Microsoft和ActiveX是微软公司在美国和其他国家的注册商标或商标。
本文中实际公司和产品的名称可能是其相应所有者的商标。