本文是根据 Microsoft SQL Server（代号“Yukon”）的 Beta 1 撰写的，其中包含的所有信息均可能更改
注：本文是在产品投放生产之前编写的，因此，我们无法保证此处包含的任何细节都与在交付使用的产品中发现的细节完全一致。文中信息描述的是本文发布之时的产品，仅供规划之用。这些信息可在任何时候更改，恕不预先通知。
Transact-SQL 的增强功能 SQL Server Yukon .NET 编程 利用 CLR 在 T-SQL 和托管代码之间选择 用户定义的类型、函数和聚合 托管存储过程 XML 和 SQL Server Yukon XML 数据类型 XSD 和XML 数据类型 XML 查询 了解 Microsoft XQuery Designer 了解 SQL Server 服务代理 数据库集成 SQL Server Yukon 的可编程场景 小结
在 Microsoft SQL Server™ 下一版本（代号为“Yukon”）的规划阶段，考虑更多的是数据库的未来发展以及 SQL Server 的编程能力。Microsoft 内部的开发人员很早就意识到，未来必须引入更加对称的编程模型，还要为不同的数据模型提供更多的灵活性。编程模型对称的目的意味着，普通的数据访问和操作任务可以通过多种途径进行 — 使用 XML、Microsoft .NET 框架或 Transact-SQL (T-SQL) 代码。
这种规划带来的结果就是一个新的数据库编程平台，它在许多方面都进行了扩展。首先，寄主 .NET 框架公共语言运行库 (CLR) 的功能将数据库扩展到过程化编程和托管代码的领域。其次，.NET 框架宿主集成提供了来自 SQL Server 内部强大的对象数据库功能。对 XML 的深入支持是通过功能完善的 XML 数据类型实现的，它拥有关系数据类型的所有功能。此外，还添加了对 XML 查询 (XQuery) 和 XML 架构定义语言 (XSD) 标准的服务器端支持。最后，SQL Server Yukon 包含了 T-SQL 语言的重要增强功能。
这些新的编程模型和增强的语言共同创造了一系列的可编程性，它们补充并扩展了目前的关系型数据库模型。这种体系结构带来的最终结果是能够创建更可伸缩、更可靠、更健壮的应用程序，并提高了开发人员的工作效率。这些模型的另一个结果就是一种称为 SQL 服务代理的新应用程序框架 — 用于异步消息传递的分布式应用程序框架。稍后，我将在文中对 Yukon SQL 服务代理做进一步讨论。现在，请先看看编程模型中的主要更改和增强功能，让我们从 T-SQL 开始。
Transact-SQL 的增强功能Yukon 为 T-SQL 语言提供了更多新的语言构造和基元，这里无法一一列举。所有这些内容，您均可以在 SQL Server Yukon Books Online 中找到。对 T-SQL 语言的增强功能反映出对 ANSI-99 SQL 规范更有力地遵守，并且这些增强也是对用户请求的响应。T-SQL 中的许多改进主要集中在查询表达方式的改善方面。有几个新的查询类型允许用 T-SQL 代码处理常见情况。例如，递归查询提供了生成材料帐单或层次结构结果集的功能。
Yukon 中的 T-SQL 提供了新的 PIVOT 和 UNPIVOT 运算符。这些运算符对输入表值表达式执行操作，并生成一个输出表作为结果集。PIVOT 运算符可将行旋转为列，根据该思路可以选择性地执行聚合或其他数学计算。这就拓宽了基于给定旋转列的输入表表达式，并生成了一个输出表，其中的一列为旋转列中的每个唯一值。UNPIVOT 运算符执行的操作与 PIVOT 相反；它将列旋转为行。UNPIVOT 运算符收缩了基于旋转列的输入表表达式。
Yukon 引入了一种新的、简单的但更强大的异常处理机制，该机制采用 TRY/CATCH T-SQL 构造的形式。现在，便可以捕获和处理那些使批处理终止的事务中止错误了。此外，还有一些新的语言构造，用于安全、复制、通知服务、XML 以及 .NET 框架提供的所有功能。服务器端的 .NET 框架实现是 SQL Server 产品周期中的重要进展。
返回页首 SQL Server Yukon .NET 编程现在，开发人员可以利用任意 Microsoft .NET 兼容的语言（包括 Visual Basic .NET 和 C#）编写存储过程、触发器和用户定义的函数 (UDF)。此外，三种新对象（用户定义的类型 (UDT)、聚合和函数）还可以用托管代码来创建。CLR 是 .NET 框架的核心，它为所有基于 .NET 框架的代码提供了执行环境。CLR 提供了程序执行所需的各种函数和服务，包括实时编译、内存管理和分配、类型安全强制、异常处理、线程管理以及安全。SQL Server Yukon 作为这一功能的宿主，就象操作系统寄主应用程序一样。
作为 CLR 集成的结果，Yukon 还提供了自动内存管理、资源分配和垃圾收集等功能。通过进入 SQL Server 执行空间，SQL Server 可提供 .NET 程序集对数据库对象的直接访问。数据访问通过一种特殊形式的 ADO.NET 实现。本文不讨论数据库中 ADO.NET 功能这一部分。但是，由于访问方法与那些开发人员熟悉的方法非常类似，因此使用 CLR 的功能很容易。
Yukon 将 .NET 框架与 SQL Server 集成的方式为数据库开发人员提供了几个主要优势，包括：
增强的编程模型 CLR 兼容的语言在许多方面都远胜于 T-SQL，它为 SQL 开发人员提供了之前无法使用的构造函数和功能。此外，还提供了一组类库（框架 API），它比 SQL 本身提供的内置函数更丰富。
增强的安全性 托管代码在 CLR 中运行，寄主于数据库引擎。这使 .NET 数据库对象比以前版本的 SQL Server 中扩展的存储过程更可靠、更安全。
用户定义的类型和聚合 通过寄主 CLR，可以使用两个新的数据库对象，它们扩展了 SQL Server 的存储和查询功能。
公共开发环境 数据库开发集成是 Visual Studio .NET 开发环境的未来版本中已经纳入计划的功能。开发人员在开发和调试数据库对象和脚本时，使用与编写中间层或客户层 .NET 框架组件和服务相同的工具。
性能和可伸缩性 在某些情况下，.NET 语言的编译和执行模型提供了比 T-SQL 更佳的性能。
返回页首 利用 CLR在以前版本的 SQL Server 中，数据库程序员在编写服务器端代码时只能使用 T-SQL。借助 CLR 集成，数据库开发人员现在可以执行仅使用 T-SQL 时不可能完成或很难完成的任务了。Visual Basic .NET 和 C# 都是现代的编程语言，它们提供对数组、结构化异常处理和集合的全面支持。与 T-SQL 所能支持的代码相比，开发人员能够利用 CLR 集成编写具有更复杂的逻辑、更适于计算任务的代码。
此外，Visual Basic .NET 和 C# 还提供面向对象的功能，如封装、继承和多态。现在，相关代码可以很容易地组织成类和命名空间。在编写服务器上使用的大量代码时，这使您能够更轻松地组织和维护代码成本。这种在逻辑和物理上将代码组织成程序集和命名空间的能力是一项突出的优势，它使您能够在大型数据库实现中更快地找到和关联不同的代码片段。
设计 UDT 时，您将需要考虑如是否可为空值和检查约束这样的问题。您甚至可以使用私有函数扩展数据类型的功能；例如，您可以在本机添加 XML 序列化功能。
此外，在注册后，程序集可以引用服务器上的其他程序集。这意味着，您可以加载一个包含常用功能（该功能可由服务器上的一个或多个其他程序集使用）的程序集。这可以增加通用代码的重用。数据库开发人员肯定会欣赏这种模块化的方式，因为他们应用程序的对象模型将变得越来越大，越来越复杂。
SQL Server Yukon 实现了三种级别的安全性，可限制数据库中已注册程序集的功能。此安全模型是两种安全模型的集成：SQL Server 安全模型，它以用户身份验证和授权为基础；CLR 安全模型，它在代码层使用了代码访问安全。
最高的安全级别 SAFE 只允许对数据进行计算和访问。第二级别 EXTERNAL_ACCESS 还允许访问外部系统资源。最低的安全级别 UNSAFE 除了会危及服务器稳定性的操作之外，没有任何限制。
返回页首 在 T-SQL 和托管代码之间选择数据层中的托管代码允许您对数据库对象执行数值计算和复杂的执行逻辑。.NET 框架为字符串处理、正则表达式、错误捕获等提供了广泛支持。此外，借助 .NET 框架基类库中的功能，数据库开发人员现在可以完全访问成千上万个预建的类和例程，这些类和例程可以从任何存储过程、触发器或 UDF 轻松地访问。对于需要字符串处理、数学函数、日期操作、系统资源访问、高级加密算法、文件访问、图像处理或 XML 数据操作等情况，托管存储过程、函数、触发器和聚合提供了比 T-SQL 简单得多的编程模型。
托管代码的另一个优势是类型安全。在执行托管代码之前，CLR 将执行服务器检查，以验证代码确实安全，可以运行。例如，检查代码的内存访问，以确保如果未写入到内存就不读取内存。
在编写存储过程、触发器和 UDF 时，程序员现在必须做出的一个决定就是，使用传统的 T-SQL 还是使用 CLR 兼容的语言（如，Visual Basic .NET 或 C#）。答案取决于具体项目的需要。T-SQL 最适用于代码主要是执行数据访问，很少或没有过程化逻辑的情况。CLR 兼容的语言则最适用于数学计算密集的函数和具有复杂逻辑的过程，或是需要在 .NET 框架基类库的基础上构建解决方案的情况。
代码替换是 CLR 集成的另一个重要功能。T-SQL 和 CLR 寄主的代码都运行在服务器上的数据库引擎中。将 .NET 框架的功能和数据库紧密结合在一起，可让您充分利用服务器的处理能力。我建议您使用 SQL Server 事件探查器来审查应用程序的性能，然后根据测试的实际结果做出自己的选择。SQL Server 事件探查器已进行了改进，可提供对 SQL Server 中 CLR 性能的深入探查，包括可用于比较的新的图形输出格式。
现在让我们看一看 .NET 框架的某些功能，以及它们是如何与 Yukon 相辅相成的。
返回页首 用户定义的类型、函数和聚合Yukon 支持可扩展的 CLR 类型系统。这些类型在服务器端可用作表定义的一部分，在客户端可作为对象来操作。UDT 使您能够通过创建在托管代码中实现的新类型，来扩展现有的类型系统。某些 UDT 示例为地理空间类型、自定义金融类型和特定日期／时间类型。可以将 UDT 看成是服务器引擎和代码之间的协定。
在 .NET 术语中，UDT 是一个结构或引用类型，而不是类或枚举。这就是说内存的使用可以优化。但是，UDT 并不支持继承和多态。它即可以包含公共函数，也可以包含私有函数。事实上，像约束检查这样的任务应该作为私有类来完成。如果您的 UDT 由多个信息（例如，地理空间类型会包含经度、纬度可能还有海拔）构成，您就需要提供包含这些元素的私有字段。创建 UDT 之后，您可以使用 T-SQL 在 SQL Server 中注册类型。完成后，DLL 的内容就实际存储到数据库中了。
UDF 有两个变体：标量值函数和表值函数。标量值函数返回单一值，如字符串、整数或比特。表值函数返回的是可以由一个或多个列构成的结果集。
能够创建系统中现有函数以外的其他聚合函数的能力，是使用旧版 SQL Server 的开发人员无法做到的。借助 Yukon，开发人员可以在托管代码中创建自定义聚合函数，并使这些函数能够被 T-SQL 或其他托管代码访问。用户定义的聚合也是一个要引用数据库中已有程序集的 .NET 类。
您可以使用 UDAgg 将存储在数据库中的数据转换为数学值。例如，一个统计函数。您可以存储包含来自一个关系表中量化调查结果的数据。为了计算出这些结果的加权平均值或标准偏差，您可以调用 UDAgg 来计算和返回这些信息。
返回页首 托管存储过程作为存储过程工作的托管代码例程，最适用的情况是：将简单的结果集稍加修改后返回给调用方，或要简单地执行一个数据操作语言 (DML) 或数据定义语言 (DDL) 语句的场合。在服务器上注册后，使用代码就和编写一个存储过程一样简单。
要使用存储过程包装一个托管代码方法，请使用 CREATE PROCEDURE 语句。CREATE PROCEDURE 使用以下原型中的语法：
CREATE PROCEDURE mysproc (@username NVARCHAR(4000)) AS EXTERNAL NAME YukonCLR:[MyNamespace.CLRCode]:: myfunction 返回页首 XML 和 SQL Server Yukon
XML 在 SQL Server Yukon 中的历史实际上始于 SQL Server 2000。该版本的 SQL Server 引入了以 XML 的格式返回关系型数据、大量加载和切分 XML 文档，以及将数据库对象公开为基于 XML 的 Web 服务等功能。Web 服务工具包，也称为 SQLXML 3.0，为存储过程、XML 模板和 SQL Server UDF 提供了 Web 服务功能。该 XML 技术缺少了两个重要的部分：原生 XML 存储机制（XML 数据类型）和支持对半结构化数据进行查询的高级查询语言。Yukon 提供了这两个元素，以及更多的 Web 服务增强功能和对 T-SQL FOR XML 语句的扩展。让我们从原生 SQL Server 数据类型（XML 数据类型）的主要增强功能开始。
返回页首 XML 数据类型XML 从一种表示技术发展为一种线路格式，现在又被看作是一种存储格式。XML 中的持久存储已经引起了广泛关注，并出现了许多 XML 数据类型的可能应用。首先，XML 在不知道对象架构的情况下很有用。其次，XML 数据类型对于信息要不断重新组织情况中的动态架构很有用。第三，XML 持久性是 XML 文档应用的中心。没有什么单一的应用场景能够最好地体现 XML 数据类型的正确使用。稍后，我将在本文给出的编程示例中，将 XML 用作一种动态架构（以发送给服务器的消息形式表示用户定单）的存储格式。
XML 数据类型是功能完善的数据类型。它具有 SQL Server 中其他类型的所有能力和功能。这一点的重要性怎么强调都不过分。作为一种功能完善的类型，XML 列可以进行索引，可以通过 XSD 架构（虽然不需要 XSD 架构）添加行和列的约束，还可以使用 T-SQL 中嵌入的 XQuery 表达式进行查询。这些功能都已追加到 XQuery W3C 规范中。此外，使用 xmldt::modify 方法，用户还可以添加子树、删除子树和更新标量值。
XML 数据类型很灵活。您可以选择是否要将 XML 架构定义 (XSD) 架构与一列相关联。当一个列具有 XSD 架构关联时，它就称为类型化 XML。如果没有 XSD 关联，它就是非类型化 XML。XSD 架构可用于在将 XML 列导入数据库后，对其类型化。然后，它可以用来为系统目录创建索引和其他元数据。在查询时，类型化 XML 列比非类型化 XML 列更快，也更灵活。使用场景将决定 XML 列的类型，虽然大多数应用程序都偏向于 XSD 架构引用。
另请注意，您可以在同一列中存储 XML 文档和 XML 片段。此外，您还必须针对 XML 列创建特殊的“XML”索引。这将为标签、值和 XML 值中的路径创建索引。
返回页首 XSD 和XML 数据类型创建 XML 列时，您应该添加一个 XSD 文档并将其与该列关联。XSD 架构关联是从 SQL Server Workbench 内部执行的。XSD 关联还可以使用 DDL：
CREATE TABLE T (pk INT, xCol('mySchema'))
将一个架构导入数据库时，它被分析为各种类型的组件，包括 ELEMENT、ATTRIBUTE、TYPE（对于简单类型或复杂类型）、ATTRIBUTEGROUP 和 MODELGROUP。然后，这些组件以及所有关联的命名空间都将存储到各种系统表中。您可以使用专用的系统视图来查看这些组件。换句话说，架构不是原封不动地存储起来的。这至少包含两层意思。首先，架构标签及其关联的属性并未存储。而 XML 标签属性（targetNamespace、attributeFormDefault、elementFormDefault 等）都被重新分配给架构的组件。其次，SQL Server 不提供在导入后恢复和查看原始架构文档的功能。建议您保留一份所有架构的副本，或将它们的内容存储到专用的数据库表中。为此，使用一个 XML 列就足够了。此外，您还可以使用内置函数 XML_SCHEMA_NAMESPACE ('uri') 来检索 XML 架构。这将返回命名空间 'uri' 的内容。
当 XML 列和 XSD 架构组合在一起时，XML 数据的查询功能将是常规关系型数据和查询的补充。虽然我不建议您以 XML 的格式存储所有数据，但是能够在数据库中使用 XML，还是使 XML 文档的管理和其他应用场景大大简化了。
现在数据已经存储好了，我将转到 XQuery 上来，因为不提它，我的讨论将是不完整的。
返回页首 XML 查询XML 查询语言，通常称为 XQuery，是一种为查询所有类型的 XML 数据而进行优化的智能、健壮的语言。借助 XQuery，您可以使用类型关联的方法，对 XML 数据类型的变量和列运行查询。通过调用查询方法，您可以在同一批中跨关系型数据和 XML 数据进行查询。
与许多 XML 标准一样，XQuery 的开发（目前还是一个工作草案）是在 W3C 的指导下进行的。Yukon 支持 2001 年 12 月 20 日到 2002 年 11 月 15 日之间的 XQuery 1.0 工作草案的一个静态类型化子集。要了解所有草案，请参阅 http://www.w3c.org。
XQuery 是从一种称为 Quilt 的查询语言演变而来的，该查询语言以多种其他语言（如 XPath 1.0、XQL 和 SQL）为基础。它还包含一个 XPath 2.0 的子集。您可以在 XPath 中使用现有的技巧，而无需学习一门全新的语言。然而，SQL Server Yukon 中包含了一些超越 Xpath 的重要增强功能，如特殊的函数和对更好的迭代、结果排序和构造的支持。
XQuery 语句由一个前导和语句体组成。前导包含一个或多个命名空间声明，和／或为查询处理创建上下文的架构导入。语句体包含一个指定查询条件的表达式序列。然后，这些语句将用在前面提到的 XML 数据类型的一个方法（query、value、exist 或 modify）中。
XQuery 能够查询类型化 XML（与 XML 架构关联的数据）以及 XML 文档。
返回页首 了解 Microsoft XQuery DesignerXQuery Designer 是一个新工具，它集成在新的 SQL Server Workbench 中，可以简化 XML 数据的使用。XQuery Designer 有助于编写查询，从 XML 列和 XML 文档中操作和检索数据。XQuery Designer 的中心开发主题就是使用户无需学习 XML Query 语言的细节就可以进行 XQuery 开发。有关运行中的 XQuery Designer，请参见sqlserver/art/XmlTsqlCLRfig01.gif" target="_blank">图 1 所示。
到现在为止，我已谈论了 Yukon 的新增 .NET 功能和 XML 功能。结合使用这些技术，可以创造新的机会来解决流行领域（如电子商务）中的应用场景。SQL Server 开发最近的关注点在分布式应用程序上，其中业务工作流和逻辑都要在数据库应用程序中表示。使用 Yukon 中构建的对基于 Web 的应用程序的强大支持，让我们深入探究一下此处讲述的新功能。
返回页首 了解 SQL Server 服务代理在过去 10 年中，电子商务应用程序的迅速发展，产生了对提高跨数据库应用程序流程管理水平的需求。如果您构建过定单输入系统或在网上进行过购物，就会对工作流模型非常熟悉。当一个用户为一本书下定单时，系统必须向库存、发货和信用卡系统提交一个事务，然后必须通过另一个 Web 应用程序发送定单确认信息。等待这些流程中每一个过程的同步不是很能好地伸缩。过去，开发人员必须编写复杂的存储过程，并使用远程过程调用代码将消息排入队列。Yukon 为构建异步消息路由提供了一种新的、可伸缩的体系结构。
SQL Server 服务代理是一项 Yukon 技术，它允许内部或外部流程使用常规 T-SQL DML 的扩展来发送和接收有保证的异步消息。消息可以发送到与发送者共享的数据库中的一个队列内、同一个 SQL Server 实例中的另一个数据库内，或同一台服务器上或远程服务器上的另一个 SQL Server 实例内。
在传统的消息处理系统中，应用程序负责消息的排序和协调。消息复制、同步化和排序都是企业级数据系统必须处理的困难问题。
SQL Server 服务代理可通过自动处理消息序列、唯一传递和会话标识，来解决这些问题。当会话在两个服务代理终结点之间建立后，应用程序会按照消息发送的顺序，对每个消息只接收一次。应用程序可以按顺序处理一次消息，而无需附加代码。服务代理会自动在每个消息中添加标识符。应用程序始终可以分辨出特定消息所属的会话。
服务代理将消息排入队列以进行传递。如果目标服务不能立即获得，消息将重复发送服务和传递尝试，直到消息发送成功。这可允许一个会话在两个服务之间可靠地继续传递下去，即使一个服务在会话期间的某个时刻暂时不可用。
SQL Server 服务代理提供了启动方服务和目标服务之间的松耦合。服务可以将消息排入队列，然后继续它的应用程序处理任务，依赖 SQL Server 服务代理保证消息到达其目的地。这种松耦合带来了调度上的灵活性。启动方可以发出多个消息，并且多个目标服务可以并行地处理它们。每个目标服务都可以按自己的速度处理消息，这取决于系统目前的工作负荷。
排队还允许系统将处理更加均衡地分布，以降低服务器所需的峰值能力。这可以整体提高数据库应用程序的吞吐量和性能。例如，定单输入应用程序可能会在每天中午遇到请求增加的情况，这会导致资源的大量消耗和缓慢的响应速度。通过服务代理，定单输入应用程序在接收定单时不需要执行所有的定单处理。相反，应用程序可以输入定单，然后提交请求以进行后台处理，如付帐、发货和库存管理。后台应用程序可靠地执行一段时间的处理，同时定单输入应用程序继续接收新的定单。
在消息处理应用程序中最难实现的一件事情就是，允许多个程序并行地从同一个队列中读取。这样的情况将导致消息不按顺序处理，即使它们是按顺序接收的。
下面看一个传统的定单处理应用程序。消息 A 包含创建定单标头的相关指令，消息 B 包含创建定单行项目的相关指令，它们都是在队列中接收的。如果这些消息都被单独的服务程序实例取出队列，并同时进行处理，定单行项目事务可能会首先尝试提交，然后会因为定单还不存在而失败。失败会导致事务回滚，使消息又重新进入队列并再次处理，从而浪费了资源。传统情况下，这个问题是通过将消息 A 和消息 B 中的信息结合到一个消息中解决的。虽然这个方法对于这两个消息很直接，但是在系统涉及要协调几十个或几百个消息时，它很难伸缩。
服务代理通过自动锁定与同一任务有关的所有消息解决了这个问题，因此这些消息只能由一个服务程序实例接收和处理。同时，其他服务程序实例可以继续将与其他任务相关的消息取出队列并进行处理。这使多个并行服务程序能够可靠且高效地工作。
服务代理最有用的功能之一是激活。激活可以在消息到达时，自动启动一个服务程序，从队列读取消息。如果消息到达的速度比处理它们的速度快，系统就会启动服务程序的其他实例，直至达到配置的最大值。如果消息到达的速度减慢了，活动的服务程序将检查队列，如果发现没有消息需要处理，服务程序就会自己关闭。这使服务程序实例的数量能够随着服务负荷的更改进行动态地增加和减少。如果系统发生故障或重启，当系统恢复时，将自动启动服务程序来读取队列中的消息。传统的消息处理系统缺乏这种行为，经常在给定时刻使专用于某个特定队列的资源不是太多就是太少。
返回页首 数据库集成服务代理的集成设计为应用程序的性能和管理提供了许多优势。与 SQL Server 集成能够使用事务性消息处理；也就是说，一个服务程序的每个循环（接收消息、处理消息和发送回复消息）可以封装在一个数据库事务中。如果事务失败，所有工作都会回滚，已经接收的消息会重新排入队列，以便进行另一次尝试对其进行的处理。在应用程序提交事务之前，所有操作都不会生效。应用程序会保持一致状态，而无需增加资源开销和分布式事务协调器的复杂性。
当数据、消息和应用程序逻辑都在数据库中时，管理就更简单了。只有一项（而不是三个或四个单独的组件）需要为灾难恢复、群集、安全、备份等进行维护。例如，在传统的消息处理系统中，消息存储区和数据库可能是不同步的。例如，当一个组件从备份中恢复时，另一个组件也必须同时从备份中恢复，否则消息存储区和数据库就可能不一致。让消息和数据使用一个数据库，这就不再是问题了。
使用公共开发环境也是一个优势。应用程序的消息处理和数据部分可以使用服务代理应用程序中的同一种语言和工具。这使开发人员对数据库编程技术的熟悉扩展到了基于消息的编程。实现服务代理服务的存储过程可以用 T-SQL 或任一种以 CLR 为目标的语言编写。
此外，数据库集成使自动资源管理成为可能。服务代理在 SQL Server 实例的上下文中运行，因此代理可以维护所有准备从实例的所有数据库中传输的消息的聚合视图。这允许每个数据库维护自己的队列，同时还能在跨整个 SQL Server 实例的资源使用上保持平衡。
返回页首 SQL Server Yukon 的可编程场景让我们看看这些概念在定单输入应用程序中是怎样结合的，其中用户在一个 Web 站点下定单。在服务之间传送的消息存储在一个 XML 列中。为了说明问题，我将使用一个基于 ASP.NET 的 Web 服务，该服务已在 SQL Server 中由一个 CLR 的实例注册并寄存。该服务与一个合作伙伴通信，以发送和接收购买定单信息。使用消息的 XML 列可允许架构的封装和简化。
用户在 Web 站点上下定单。当定单事务提交后，包含定单信息的消息会放入定单输入服务队列中。定单将以 XML 列的形式发送给定单输入服务。这可将所有的定单信息合并到一列中。有关此流程的完整视图，请参见图 2。
定单输入服务启动事务，接收消息，然后处理它。然后，定单输入服务向信用限制服务发送一个请求，以验证信用状态。如果没问题，定单输入服务将执行下一步。
定单输入服务检查定单中每一项的库存。XQuery 会处理库存检查。此时，如果商品项可以发货，将向发货服务队列发送一个消息。
发货服务（一个 T-SQL 存储过程）使用 XQuery 分析 XML 消息。用户信息用于生成定单发货。当发货完成后，将向付帐服务队列发送一个消息。当付帐服务队列接收到“发货完成”的消息后，将更新数据库中的定单状态，以表示定单已经发货。所有来自和发送到定单输入服务的消息都会写到一个审计表中，供以后分析和解决问题使用。
从这个简单的示例中，您可以看到如何使用新的 Yukon 可编程功能（XML、CLR、服务代理和 T-SQL 增强功能），来构建可靠、可伸缩和完整的数据库应用程序。
返回页首 小结我只是触及了 Yukon 中几个新的、激动人心的体系结构功能。数据库开发人员从来都没有在数据访问和存储上获得这么多的选择。此 SQL Server 服务代理示例仅在结合 SQL Server 的新功能时着重说明了几项功能。开始使用 SQL Server Yukon Beta 版并继续关注 MSDN Magazine 未来的内容。只要有所了解，您就会使用 Yukon，而且再也不会走老路了。
Eric Brown 大约在 3 年前加盟 Microsoft 公司的 SQL Server 小组。此前，他供职于 greatfood.com 和其他小公司，从事数据库开发工作。