作为微软新一代企业级应用平台旗舰产品之一的SQL Server 2005，有太多的精彩值得我们关注。而SOA(面向服务的架构)，对于新一代面向同步和异步应用的、基于以因特网平台为主的请求/响应模式的分布式计算来说，无疑是一场革命。数据库，作为基于面向服务的数据库架构(SODA)构建分布式架构的一个战略组成部分之一，举足轻重。本系列文章中，我们将试图剖析SODA背后的相关概念，并进而观察微软如何以其力图“撼动未来”的SQL Server 2005适应这种新型架构。
一、SOA架构的出现
当我们把上世纪九十年代占主流的客户机-服务器和N层应用程序架构用于开发今天大规模的因特网电子商务站点时，这些方案遇到了严重的问题—可伸缩性和可用性。其中一个主要的问题就是，数据越来越倾向于存储在一个大规模、高度集中的数据库中，而且所有客户端组件都可以对之实现直接访问。此时，几乎所有与这些数据库相关的通信都是以SQL语句(或存在于一个存储过程中的批语句)形式执行的;于是，客户端将接收到一个特定于要解决的任务的数据集合。
而今，当我们试图把“遗留”系统加入到较新的应用程序中时，又遇到了其它的问题。在经过多年来使用各种专利性技术和平台发布大范围的系统后，整个世界可谓“遍布”这种能够较好地实现“自身”工作的系统;但是，这些系统却往往缺乏清晰的思路来实现与其它应用程序的交互—悉知，如今的连接环境正变得越来越方便。因此，实现今天的应用程序所要求的灵活性已经变得相当困难。B2B(业务到业务)应用甚至于使得事情进一步复杂化，因为这要求必须满足特定的标准并使用可靠的方法来实现业务传输的电子化。非常明显，满足今天全球业务环境需要的不断演变的系统都要求实现某种新架构，这种架构必须能够高效地使用“遗留”系统并能提供一个灵活的商业基础框架。
为了满足这些需要，最近三到五年间已经出现了一种“新的”大规模、松耦合、分布式的系统架构，特别是作为因特网电子商务站点已经成长为其主要的商业运作模式。面向服务的架构(SOA)已经开始作为主流的松耦合、以服务为中心的架构出现。事实证明，基于SOA的应用程序更能经得起失败，并且更为容易地按比例调整规模—通过使用多种方法添加必要的资源来满足不断发展的要求;而且，它们也允许把“遗留”系统轻松地集成到现有B2B及其它系统中。
二、 面向服务架构对数据的要求
在一个SOA应用程序中，SOA服务提供者、服务消费者及其它组件都会将数据处理作为其自身角色的一个“自然”的特征。典型情况下，一个SOA应用程序仍然使用中央数据库来存储和保护数据;但是，也有可能使用许多这种大型的数据库来存储各类数据—例如单独存储的销售、生产和操作数据以及每一部分中的特定数据子集等。每个服务提供者和消费者都可能需要对数据或其自己特定的数据存储进行本地缓冲。此外，跨越应用程序的远距离部分传输的消息本身常常就是一些值得加以存档而备以后使用的数据。
根据数据在系统中的特征，我们可以按下列四种方式对之进行划分：
•①引用数据—用于创建服务请求(例如一个产品目录)。它必须是以一种为所有部分可用的格式存在，而且以一种恒定不变的方式(例如一个目录日期)加以标识。
•②活动数据—是短暂的数据，用于执行一个特定的活动，例如一个产品列表(用于从库存中检索购买项)。既然它是私有于服务的，所以该格式不需要被其它模块所理解。
•③资源数据—是一种长期存在的数据。这种数据为一个服务(例如顾客数据和帐户数据)内部使用。
•④服务交互数据—用于服务间的通讯。这必须是以一种为所有部分都能理解的格式进行，并且必须长期保持不变。例如，在服务之间以一个订单表单形式进行通讯。假如该订单被丢失，那么它必须能够被以与以前相同的形式重新生成并且被再次转换。
下图1展示了一些可能构成一个松耦合的应用程序(基于SOA原则进行构建)的端点。其中的服务消费者可能代表一个客户端应用程序;而一个服务器应用程序(例如一个Web服务器)，或者是任何其它类型的应用程序，将把消息发送给一个服务提供者。在复杂的系统中，可能通过一个消息路由器最初接收消息，然后应用特定的逻辑把该请求路由到适当的服务提供者。然后，该服务提供者接收此消息并加以处理—解包并重新格式化它，执行任何要求实现的工作，最后可能把一个响应发送回服务消费者。
|
|
| 图1：一个面向服务构架应用程序局部示意图 |
上图中向我们提供了一个重要的细节—事务中的每一个结点都在以各种形式接收、存储和传输数据。有时这些数据是“短暂”的，而有时每个结点可能会把数据存储到一个缓存或其自己的本地数据库中。
基于在一个应用程序中的这些新的数据处理方式，如今，处于SOA应用程序核心位置的数据库面临着一些与以往N层应用程序不同的挑战。但是，数据一致性仍然同以往一样重要;不过，现在又出现了其它的要求：
1.数据库操作处于一种新的环境—数据请求经由基于XML的消息而不是通过专用连接方式进行;
2.缓冲数据仓库部分需要了解何时刷新数据更为有效，而不是根据某个固定时间表实现刷新;
3.数据库不得不参与以一种固定顺序发生的“对话”;
4. 存在复杂的逻辑必须宿主在数据库中(或宿主在这些数据库附近)。
今天，XML成为一种应用于新一代分布式系统的良好的消息格式。这种格式能够为几乎任何系统容易地分析并通过某种模式建模语言来定义这些数据的适当结构。于是，交换消息的系统可以把信息依附到一条XML消息中;结果，当这些消息“流经”系统时，数据将“汇集”于消息中。系统只需分析和处理它们能够理解的部分而忽略掉其它内容。简言之，设计XML的目的是为了作为一种灵活的格式来支持分布式系统。
微软的架构师们正是看到了这种结构化趋势，及时地推出了新一代SQL Server 2005以满足这种新的挑战;而同时，SQL Server 2005仍能继续支持许多现有的非SOA应用程序。本文中，我们将全面探讨如何在一个使用SQL Server 2005的SOA应用程序中应用本地Web服务存取，数据库改变通知，Service Broker以及SQLXML等技术。
三、 SQL SERVER 2005适应SOA数据要求
随着我们对SOA概念的不断深入，有一个问题越来越明晰：组成整个系统的每一个组件都会把接收、处理与传送数据作为自身的主要功能之一。即使一个服务提供者对于一条发送自某个服务消费者的消息的响应只是简单地进行“位”设置(置为“on”或“off”)而根本不必与一个数据库交互，此提供者也必须处理该消息中的数据以便确定相应的任务。事实上，现代商业应用程序通常会广泛地与数据打交道;所以，对于一个SOA组件来说，常常会存取一个本地的或集中的数据库，或经常二者兼有。
SQL Server 2005提供了一组新的特征来进一步方便集成化结构化设计—支持把数据库作为一个SOA服务提供者使用。微软SQL Server 开发小组称这组新的特征为“面向服务的数据库架构”(或简称为“SODA”)。
直接在数据库引擎中实现SOA特征存在如下重要理由：
调整系统规模。即使在最大的企业SOA应用程序中，单个服务也可能按几乎任何规模被实例化;一个使用不太频繁的服务有可能具有比一个典型的小型部门数据库更少的活动。与SQL SERVER集成到一起意味着，一个服务程序可以利用所有的本地支持来适应从嵌入式设备到最为丰富的企业数据库服务器，而不必改进管理复杂性。服务逻辑代码可以在任何规模下执行，而任何实现都可以在发布时刻被调整到一个单独的中间层中。借助于SQL SERVER 2005，服务逻辑可以在数据层上运行或者被发布到中间层中。假如你仔细地设计一个应用程序，那么你会注意到，如何调整的问题将会是一种发布决策而不是一项设计或开发时刻决策。
作为微软新一代企业级应用平台旗舰产品之一的SQL Server 2005，有太多的精彩值得我们关注。而SOA(面向服务的架构)，对于新一代面向同步和异步应用的、基于以因特网平台为主的请求/响应模式的分布式计算来说，无疑是一场革命。数据库，作为基于面向服务的数据库架构(SODA)构建分布式架构的一个战略组成部分之一，举足轻重。本系列文章中，我们将试图剖析SODA背后的相关概念，并进而观察微软如何以其力图“撼动未来”的SQL Server 2005适应这种新型架构。
一、SOA架构的出现
当我们把上世纪九十年代占主流的客户机-服务器和N层应用程序架构用于开发今天大规模的因特网电子商务站点时，这些方案遇到了严重的问题—可伸缩性和可用性。其中一个主要的问题就是，数据越来越倾向于存储在一个大规模、高度集中的数据库中，而且所有客户端组件都可以对之实现直接访问。此时，几乎所有与这些数据库相关的通信都是以SQL语句(或存在于一个存储过程中的批语句)形式执行的;于是，客户端将接收到一个特定于要解决的任务的数据集合。
而今，当我们试图把“遗留”系统加入到较新的应用程序中时，又遇到了其它的问题。在经过多年来使用各种专利性技术和平台发布大范围的系统后，整个世界可谓“遍布”这种能够较好地实现“自身”工作的系统;但是，这些系统却往往缺乏清晰的思路来实现与其它应用程序的交互—悉知，如今的连接环境正变得越来越方便。因此，实现今天的应用程序所要求的灵活性已经变得相当困难。B2B(业务到业务)应用甚至于使得事情进一步复杂化，因为这要求必须满足特定的标准并使用可靠的方法来实现业务传输的电子化。非常明显，满足今天全球业务环境需要的不断演变的系统都要求实现某种新架构，这种架构必须能够高效地使用“遗留”系统并能提供一个灵活的商业基础框架。
为了满足这些需要，最近三到五年间已经出现了一种“新的”大规模、松耦合、分布式的系统架构，特别是作为因特网电子商务站点已经成长为其主要的商业运作模式。面向服务的架构(SOA)已经开始作为主流的松耦合、以服务为中心的架构出现。事实证明，基于SOA的应用程序更能经得起失败，并且更为容易地按比例调整规模—通过使用多种方法添加必要的资源来满足不断发展的要求;而且，它们也允许把“遗留”系统轻松地集成到现有B2B及其它系统中。
二、 面向服务架构对数据的要求
在一个SOA应用程序中，SOA服务提供者、服务消费者及其它组件都会将数据处理作为其自身角色的一个“自然”的特征。典型情况下，一个SOA应用程序仍然使用中央数据库来存储和保护数据;但是，也有可能使用许多这种大型的数据库来存储各类数据—例如单独存储的销售、生产和操作数据以及每一部分中的特定数据子集等。每个服务提供者和消费者都可能需要对数据或其自己特定的数据存储进行本地缓冲。此外，跨越应用程序的远距离部分传输的消息本身常常就是一些值得加以存档而备以后使用的数据。
根据数据在系统中的特征，我们可以按下列四种方式对之进行划分：
•①引用数据—用于创建服务请求(例如一个产品目录)。它必须是以一种为所有部分可用的格式存在，而且以一种恒定不变的方式(例如一个目录日期)加以标识。
•②活动数据—是短暂的数据，用于执行一个特定的活动，例如一个产品列表(用于从库存中检索购买项)。既然它是私有于服务的，所以该格式不需要被其它模块所理解。
•③资源数据—是一种长期存在的数据。这种数据为一个服务(例如顾客数据和帐户数据)内部使用。
•④服务交互数据—用于服务间的通讯。这必须是以一种为所有部分都能理解的格式进行，并且必须长期保持不变。例如，在服务之间以一个订单表单形式进行通讯。假如该订单被丢失，那么它必须能够被以与以前相同的形式重新生成并且被再次转换。
下图1展示了一些可能构成一个松耦合的应用程序(基于SOA原则进行构建)的端点。其中的服务消费者可能代表一个客户端应用程序;而一个服务器应用程序(例如一个Web服务器)，或者是任何其它类型的应用程序，将把消息发送给一个服务提供者。在复杂的系统中，可能通过一个消息路由器最初接收消息，然后应用特定的逻辑把该请求路由到适当的服务提供者。然后，该服务提供者接收此消息并加以处理—解包并重新格式化它，执行任何要求实现的工作，最后可能把一个响应发送回服务消费者。
|
|
| 图1：一个面向服务构架应用程序局部示意图 |
上图中向我们提供了一个重要的细节—事务中的每一个结点都在以各种形式接收、存储和传输数据。有时这些数据是“短暂”的，而有时每个结点可能会把数据存储到一个缓存或其自己的本地数据库中。
基于在一个应用程序中的这些新的数据处理方式，如今，处于SOA应用程序核心位置的数据库面临着一些与以往N层应用程序不同的挑战。但是，数据一致性仍然同以往一样重要;不过，现在又出现了其它的要求：
1.数据库操作处于一种新的环境—数据请求经由基于XML的消息而不是通过专用连接方式进行;
2.缓冲数据仓库部分需要了解何时刷新数据更为有效，而不是根据某个固定时间表实现刷新;
3.数据库不得不参与以一种固定顺序发生的“对话”;
4. 存在复杂的逻辑必须宿主在数据库中(或宿主在这些数据库附近)。
今天，XML成为一种应用于新一代分布式系统的良好的消息格式。这种格式能够为几乎任何系统容易地分析并通过某种模式建模语言来定义这些数据的适当结构。于是，交换消息的系统可以把信息依附到一条XML消息中;结果，当这些消息“流经”系统时，数据将“汇集”于消息中。系统只需分析和处理它们能够理解的部分而忽略掉其它内容。简言之，设计XML的目的是为了作为一种灵活的格式来支持分布式系统。
微软的架构师们正是看到了这种结构化趋势，及时地推出了新一代SQL Server 2005以满足这种新的挑战;而同时，SQL Server 2005仍能继续支持许多现有的非SOA应用程序。本文中，我们将全面探讨如何在一个使用SQL Server 2005的SOA应用程序中应用本地Web服务存取，数据库改变通知，Service Broker以及SQLXML等技术。
三、 SQL SERVER 2005适应SOA数据要求
随着我们对SOA概念的不断深入，有一个问题越来越明晰：组成整个系统的每一个组件都会把接收、处理与传送数据作为自身的主要功能之一。即使一个服务提供者对于一条发送自某个服务消费者的消息的响应只是简单地进行“位”设置(置为“on”或“off”)而根本不必与一个数据库交互，此提供者也必须处理该消息中的数据以便确定相应的任务。事实上，现代商业应用程序通常会广泛地与数据打交道;所以，对于一个SOA组件来说，常常会存取一个本地的或集中的数据库，或经常二者兼有。
SQL Server 2005提供了一组新的特征来进一步方便集成化结构化设计—支持把数据库作为一个SOA服务提供者使用。微软SQL Server 开发小组称这组新的特征为“面向服务的数据库架构”(或简称为“SODA”)。
直接在数据库引擎中实现SOA特征存在如下重要理由：
调整系统规模。即使在最大的企业SOA应用程序中，单个服务也可能按几乎任何规模被实例化;一个使用不太频繁的服务有可能具有比一个典型的小型部门数据库更少的活动。与SQL SERVER集成到一起意味着，一个服务程序可以利用所有的本地支持来适应从嵌入式设备到最为丰富的企业数据库服务器，而不必改进管理复杂性。服务逻辑代码可以在任何规模下执行，而任何实现都可以在发布时刻被调整到一个单独的中间层中。借助于SQL SERVER 2005，服务逻辑可以在数据层上运行或者被发布到中间层中。假如你仔细地设计一个应用程序，那么你会注意到，如何调整的问题将会是一种发布决策而不是一项设计或开发时刻决策。
按比例调整。你可以通过许多方式来按比例调整以数据中心的计算，通常以按比例调整数据库或通过使用面向服务的架构的方式来分布这些处理。按比例调整数据库将会导致一个数据库簇—而它是紧耦合的;而相比之下，面向服务的方案导致更为松弛的耦合度。直接通过数据库支持SOA的构建有助于减少在一个真正的网格方案中的组件处理问题。
消息作为数据。各种请求和响应消息都成为一些“有趣”的数据—把它们存档到一个数据库中可能有重大价值。保持这些消息长时间可用则为我们提供了一种历史数据，从而便利了以后的审计和事务分析。因为消息存储在表格中并且有系统目录视图可用，所以你可以很容易地使用Transact-SQL来观察任何系统部分的状态。
在SQL SERVER中实现SOA特征存在大量的优点。也只有这样，它才有理由充当一个SOA应用程序中的一个独立的服务提供者。为此，它必须能够实现类似一个服务提供者的行为。
对于SQL Server 2005(或任何数据库引擎)来说，要承担起作为一个独立的SOA服务程序的角色，它必须实现若干超出其本地数据处理能力的特征：
端点(End Point)支持。SODA提供者必须提供通信支持以接收和传输消息。典型情况下，这可以通过一个TCP套接字，HTTP GET或PUT，SOAP端点，或其它类型的端点实现。
过程服务请求。大多数SOA消息要使用XML方式加以格式化;因此，服务提供者必须能够处理并且可能要把打包的数据转换成其它形式以满足组成服务的组件的需要。它还必须能够参与复杂的对话和会话—而它们将作为相互依赖的消息由其它组件接收或发送到这些组件。
服务逻辑宿主。提供者必须能够执行要求的任何复杂程度的逻辑来处理消息并提供必要的响应，而且还可以协调若干其它服务的输入;而这可能要求普通的应用程序服务器任务，例如对资源进行“池”存储，激活，以及按规模调整处理逻辑。
SQL SERVER 2005中的各种新特征为这些功能提供了支持;此外，还提供了其它基础性结构来支持数据管理。例如，一个服务提供者必须安全地加入到一个SOA系统中，并且能够对客户端实现认证，而且提供凭证来实现对其它实体的认证，提供持久性，参与会话和事务及其它应用程序级特征。
SQL Server 2005建立在SQL Server 2000关系数据库引擎特征之上，以及自从它的最初发行版本以来所开发的新技术(例如SQLXML 3.0，通知服务以及其它工具)，从而全面实现了面向服务的数据库架构。
四、小结
该文中，我们仅粗略地分析了SOA出现的缘由及其对数据存储的新要求，并进而简要概括了SQL Server 2005对这种新式数据要求所提供的支持。在下篇中，我们将展开SQL Server 2005对SOA架构支持的全面探讨。