SQL Server XML 和 Web 应用体系结构
摘要: 本文概要介绍在一组基于 SQL Server XML 的解决方案中使用 Duwamish Books, Phase 4 应用和更可靠的 Duwamish Online 应用后所得到的体系结构。
有关 Microsoft® SQL Server™ 2000 中介绍的 SQL Server XML 技术套件的详细信息，请参阅相关文档 Duwamish Online SQL Server XML 分类浏览（英文）。
您可以在 MSDN Online 代码中心（英文）查看 d5sqlxml.exe 示例代码。
简介
Microsoft SQL Server 2000 以其众多的新功能闪亮登场，其中包括我们称之为 SQL Server XML 的系列 XML 新技术。此技术套件包含诸多改进、增强和特性，使 SQL Server 成为更具 Web 特点的应用程序，向 Microsoft .NET 版本迈进了一步。
SQL Server XML 可用于扩展、增强或替换 Web 应用的体系结构。新特性可分为两个主要组件：
数据库组件，允许数据库对 XML 进行读、处理和写操作
SQL Server XML Internet Server API (ISAPI) 应用，允许通过 HTTP 访问数据库
无论是使用这两个组件还是使用其中的一个，都可以获得多个理想的体系结构。为了测试新工具的功能和灵活性，我们检验了 Duwamish Online 的逻辑体系结构，并将其应用到一组基于 SQL Server XML 的解决方案中。为了使研究更全面，我们在测试中同时使用了比较简单的 Duwamish Books, Phase 4 应用和更可靠的 Duwamish Online 应用。下面是所得出的体系结构的概述。
逻辑体系结构
我们必须认识到不管应用是什么形式，下面两种体系结构始终存在：逻辑体系结构，是用于分析应用的组织概念，而物理体系结构则表示实施应用的途径。区分这两个概念是非常必要的，因为这两个体系结构很少完全对应（即使有过这种情况）。下面您将看到，与给定的逻辑设计相对应的物理体系结构会根据不同的情况而改变。
创建 Duwamish Online 及其以前版本时，我们根据 Microsoft n-层准则确定逻辑体系结构。该体系结构包括由 Web 应用执行的公共操作，并不是专门针对 Duwamish Online 的。
逻辑体系结构：
应用分为五个逻辑层。距离客户端最远的是数据层，其中存储了应用所需的信息。它的上一层为数据访问层，它从数据库中数据的表示形式中提取数据，并且包含所有数据库操作公用的例程。数据访问层直接由业务逻辑层使用。业务逻辑层通过隐藏来自更高层的事务逻辑和实施细节来提取业务事务。体系结构的下一个逻辑层是工作流层，也称为业务接口，它提供了一个到表示层的简单界面（也称为接口）。工作流层管理内部状态，并使用业务逻辑层提供的自动操作来完成复杂的工作流。最后是表示层，它为用户转换工作流层返回的结果。有一些转换比较简单，例如通过 XSL 样式表将结果转换为 HTML；有些则比较复杂，例如通过电话线阅读结果的语音算法。
下面是从这个逻辑体系结构得出的几个物理体系结构。
物理体系结构
分发负载
SQL Server XML 使数据库具备除读写数据之外的很多其他功能。XML 功能允许存储过程处理大量高度结构化的数据。相关信息可以作为 XML 传递到存储过程，从而允许业务逻辑或工作流以存储过程（而不是 COM+ 或脚本）的形式实施。这意味着，现在您可以将更多应用处理移到数据库一级。如果决定采用这种方式，请切记数据库是应用中可伸缩性最小的部分。
决定应用在数据库和 Web 服务器之间分发处理的方式是非常关键的。这将影响应用所需的软件和硬件，开发应用所需的专业技能，以及部署、更新和维护的过程。为遵循简单性原则，我们将参考一个服务器配置，其中 Web 服务器执行大部分工作，属于“头重”类型。而那种由数据库服务器执行大部分工作的配置则属于“脚重”类型。
对于大多数应用，有两方面的因素决定其选择“头重”服务器：
成本：数据库服务器所用的软件和硬件比 Web 服务器所用的软件和硬件成本高。
可伸缩性：在 SQL Server 2000 中，数据库的可伸缩性在 SQL Server 7.0 的基础上得到改善，但是为了充分发挥新硬件的功能，还需要仔细规划和有效维护。
基于以上原因，基于“脚重”类型的服务器配置体系结构留待以后讨论。
Microsoft n-层物理体系结构
作为比较，我们先看一个没有使用 SQL Server XML 的 Duwamish Online (http://www.duwamishonline.com/) 的物理体系结构。它的设计目的是尽可能实现上面介绍的逻辑体系结构。尽管每一层都设计为执行一类逻辑操作，但是，仍然出现功能分布超出范围的情况。例如，某些业务逻辑由数据库中的存储过程执行以提高性能。那些熟悉 Duwamish Books, Phase 4 的用户很快就会发现结构的改变很小。
Microsoft n-层体系结构：
此体系结构允许每个组件专用于一个特定任务，并使用最适合该任务的技术。缓存用 C++ 编写以最大程度提高性能；使用 Active Server Pages (ASP) 和 XSL 来控制表示逻辑；由 Microsoft Visual Basic® 执行工作流、业务逻辑和数据访问；用 Transact SQL (T-SQL) 控制组件和数据库操作。未划定技术界限的各层将按照将其作为单独的 COM+ 组件实施来划分。所有这些灵活性的代价是各层必须协同工作。跨环境调试是一项艰难的工作，必须非常细心，以确保适合一种环境的数据必须重新设置格式以适合其目标环境。（例如，字符串“a < b”存储在数据库中不会出现问题，但是如果没有经过转义就放入 XML 文件中，将导致括号不匹配，从而损坏分析程序。）
读取方物理体系结构
Duwamish Online 在整个应用中使用单一的物理结构。与此相反，基于 SQL Server XML 的版本使用两个互补的物理体系结构：一个用于读取，另一个用于写入。在我们的例子中，第二种比较合适，因为两种使用情况需要不同类型的处理。
注意： 请参阅 http://msdn.microsoft.com/voices/news/sqlxml.asp（英文）中的完整体系结构图。
读取方体系结构：
SQL Server XML 技术用于所有层（从数据库到表示）以最大限度地提高性能。SQL Server XML ISAPI 应用代替 Web 层上的 ASP。ISAPI 应用和 SQLOLEDB 提供程序自动执行数据访问，从而减小代码量，缩短开发时间。获得此性能的代价是失去了可靠的 ASP 对象模型和灵活性。下面一节写入方物理体系结构中将说明失去的功能，以及如何在必要时将应用代码集成到体系结构中，从而重新获得这种灵活性。
现在，让我们看一些更细致的体系结构特性。表示方法由 XSL 样式表单独控制。因为数据库返回的数据为 XML，所以这一特性很有用。但是，使用 XSL 的好处是不依赖于技术。换句话说，模板、ASP 页和 COM+ 组件可以使用同一个样式表。模板包含工作流层。（模板是 XML 说明文件，它生成数据驱动的动态 Web 页，允许通过 HTTP 快速访问数据库，同时提供一定级别的数据提取和数据安全性。）模板通常使用存储过程进行数据访问，尽管它们也可以使用 XML Data Reduced (XDR) 架构，这种架构提供了一种直观的语法将数据库对象映射到 XML 元素，还提供了使用 XPath（XML 路径语言）进行数据库查询的能力。有关模板、XDR 架构和实施细节的详细说明，请参阅我以前的文章 Duwamish Online SQL Server XML 分类浏览。
这种体系结构没有单独的业务逻辑层。这是因为我们的应用中的只读操作只有很少的业务逻辑量，可以轻松地集成到数据访问例程中。在其他情况下，业务逻辑层可作为数据库中的一组存储过程高效实施。有关这方面的设想和方法，请参阅本文后面的以数据库为中心的体系结构一节。
经过验证，最大的变化发生在数据库层。新增的一组功能允许存储过程直接读写 XML。事实上，所有数据检索都通过 XML 来完成。
写入方物理体系结构
SQL Server XML 模板经过高度流程化，能尽可能高效地通过 HTTP 访问数据库。为此付出的代价是功能集受到限制。在模板中找不到所需功能的情况下，SQL Server 的专用 ISAPI 应用被替换为 ASP、ASP 和 COM+ 的组合或自定义的 ISAPI 应用。
本节中说明的体系结构适用于您的页面要执行下列操作的情况：
访问多个服务器上的数据库
处理在设计时未知其格式的 HTTP 请求
调用 COM/COM+ 对象
使用 COM+ 事务
连接至 Internet 上的任何应用或 Web 服务，例如付款提供程序
写入方体系结构：
Web 层上的代码表示应用功能的四个层——数据访问、业务逻辑、工作流和表示。在开发应用时，请确保此代码与体系结构保持一致。这可使代码的可读性更高，也更易于维护。如果决定单独使用 ASP，脚本类的效率会更高。如果在业务逻辑层或工作流层有大量复杂的处理，对这些层使用 COM+ 组件可能速度更快。相反，对于处理量相对较小的情况，使用脚本可能速度更快。
这种新体系结构更出色的原因是，所有层（从数据到表示）都使用 XML 来传输和存储信息。数据库中的存储过程使用这些新功能来读写 XML。数据访问层利用 ADO 2.6 流与数据库进行高效、基于 XML 的通讯。
更新颖的方法是将某些中间层下移到数据库中。
以数据库为中心的体系结构
Duwamish Online 体系结构基于这样一种设想：因为数据库的可伸缩性最低，它应该设计成执行尽可能少的任务。分布式分区视图等新功能允许在多个服务器之间分担工作量，从而提高了数据库的可伸缩性，使开发人员可以选择将大部分工作放在何处。
如果选择将“脚重”服务器群集（数据库方面功能更强）与 SQL Server XML 体系结构一起使用，则另一种方法是使用与 n-层组件的分层方式相似的方式来对数据库中的存储过程进行分层。要实现这一点，必须有好的编程方法，例如选择适当的数据结构和尽可能避免重复代码。
以数据库为中心的体系结构：
这种体系结构中的表示层还包含用于访问数据库中的存储过程的代码。此代码可能与传统数据访问层中的代码相同。但是，调用此代码时数据访问层可能会出错，因为这些例程调用工作流层提供的接口。
在使用存储过程进行开发工作时应该小心避免出现缺陷。让我们先来看一个设计，这个设计使用了几个智能存储过程，它们先执行该层的公共任务，然后再执行在下一个层上继续执行其代码路径的逻辑切换。在工作流层中调用“智能过程”将对应于若干个不同的操作之一。此过程如下所示：
CREATE PROCEDURE
/* 这是一个智能过程，执行工作流操作 */
DoWorkflow
/* Action 用于选择该调用的多个操作之一 */
@Action nvarchar(255),
/* SomeOtherParameters 是一个占位符，用于工作流所需的其他输入 */
@SomeOtherParameters ntext
AS
/* 执行工作流的公共操作 */
Execute SomeCommonWorkflowOperations
If @Action = N'Action1'
BEGIN
/* 执行 Action 1 */
Execute BusinessLogicAction1
END
Else If @Action = N'Action2'
BEGIN
/* 执行 Action 2 */
Execute BusinessLogicAction2
END
GO
第一次调用此过程时，SQL Server 优化执行恰好第一次运行的任何代码路径。这使其余代码路径的运行效率降低，尽管它们的成本可能更高或者使用的频率更高。
为确保优化执行所有代码路径，可为每个操作创建一个单独的过程，尽可能避免切换逻辑。为防止代码重复，所有层中多个操作共享的函数应该放在单独的过程中。当该设计产生大量过程时，优化可以大大提高应用的效率。
集成
Web 开发中最值得称道的一点是用户看不到实施过程。因此，本文中介绍的体系结构可以轻松地合并到单个应用中，而无需用户参与。下面是一些准则，可以帮助您更轻松地集成应用的不同部分：
在整个应用中使用 XML。XML 可以用于任何技术中，可以使用 XSL 样式表轻松地进行转换，还可以毫无困难地存储在任何地方。SQL Server XML 使得在您的应用中使用 XML 比以前更容易。
尽可能分解代码。
使用 XSL 样式表来转换 XML。可以在模板、COM+ 组件和一段脚本之间方便地共享同一个 XSL 样式表。
当脚本执行多个函数时，使用脚本类分解代码。
在数据库方面，始终使用存储过程进行数据访问。它们不仅易于维护，而且比未编译的 SQL 查询执行速度快得多。
影响
本节说明使用新的体系结构对于您的应用在“功能”和性能方面有何影响。
可编程性
可编程性是指容易编写应用代码。通常反映在开发应用的时间而不是功能方面。以 Duwamish Online 应用为例。该应用的五个层是通过一组完全不同的技术来实现的。表示层使用了 C++（用于缓存组件）和 Web 技术（例如 XML、XSL 和 ASP)。工作流层、业务逻辑层和数据访问层是 Visual Basic COM+ 组件，而数据库中的存储过程是用 T-SQL 编写的。使用这么多技术的优点是，开发人员可以针对每种类型的操作选择最佳技术。但是，要使所有组件高效地紧密协作无疑是一个难点。当使用多种不同的工具和不同的编程语言开发组件时，跨组件跟踪和调试始终非常困难。
在整个应用中使用 SQL Server XML 将有助于最大程度地降低不同技术的工作量。（XSL 是一个例外：它不属于 SQL Server XML，但却紧密集成在 SQL Server XML 模板中）。各层之间一起工作，但产生的冲突最少。在各层之间进行调试非常简便，因为所有的中间数据都是 XML，无需任何额外操作。但是，可编程性的最大优点可能是大大减少了代码量：基于 SQL Server XML 版本的 Duwamish Books, Phase 4 可完成基于 COM+ 的同类产品相同的工作，但前者的代码量只有后者的十分之一。通过 SQL Server XML 的内置功能使数据访问、XML 转换、XSL 转换和数据缓存变得更加简便。
遗憾的是，不能再使用 XSL 的高效调试工具，而用于其他新技术的调试工具相对来讲还不成熟（尤其是与 Microsoft Visual Studio® 提供的跨语言调试能力相比）。
可管理性
SQL Server XML 应用易于部署。对于运行在 Web 层的代码，只需简单地将文件复制到它们的目标目录，然后运行一次配置工具以建立相应的虚拟目录。更新过程只是简单地替换过期的文件。可以使用 SQL Server Enterprise Manager 轻松地管理数据库对象。
性能
有关详细信息，请参阅 Duwamish Online SQL Server XML 分类浏览文章中有关性能的一节。
使用建议
有关新技术最重要的问题可能是使用的时机。尽管 SQL Server XML 不是所有 Internet 问题的最终解决方案，但是在某些情况下，其优势是显而易见的，这包括代码量大大减少、开发周期明显缩短、性能更高和维护更方便。新技术的两个主要组件（数据库和 ISAPI 应用）的使用情况不同，如下所述。
SQL Server XML 的数据库服务器组件几乎用于所有应用。即使要将现有的应用从使用数据库转换为使用 XML 也是值得的。一些显著的优点如下：
易于本地化（使用 XSL）
不依赖于平台和技术
易于缓存 XML 数据
能够使用脱机/断开连接的应用
易于合并或创建 Web 服务
能够与其他应用协同工作
新技术的 Web 界面组件是专用的。它们可提供对数据库的快速、高效访问，并提供使用 XSL 样式表轻松创建数据驱动页的能力。这些优点非常有用。在我们的测试中，Duwamish Online SQL Server XML 分类浏览（无缓存）比 Duwamish Online（有缓存）的性能高 15%。使用 SQL Server 2000 技术预览版进行的早期测试显示 SQL Server XML ISAPI 缓存可使性能有数量级的提高。但是，如果应用包含下列任何一种情况，则可以考虑使用基于 ASP 的中间层：
与数据提取无关的扩展业务逻辑例程。有两个选项决定这些例程的位置：数据库的存储过程或 XSL 中的脚本。脚本的效率不够高，而结构化查询语言 (SQL) 可能不是最佳语言。
扩展字符串，尤其是结果集合的处理。此规则的例外情况是存储在 XML 或 HTML 数据库中的转义字符串。SQL Server 2000 的一个新功能将自动完成这项工作。有关详细信息，请参阅 SQL Server Books Online 文档（XML 和 Internet 支持 检索和编写 XML 数据 使用 FOR XML 检索 XML 文档 使用 EXPLICIT 模式 F. 指定 cdata 指令）。
大量 HTML 输入。模板的局限性使其无法通过在设计时已知其格式的 HTTP 请求检索所有信息，此工作可以使用 ASP 页完成。
注意！SQL Server 2000 还允许通过 URL 直接访问数据库。在其他情况下，允许使用动态模板来帮助解决体系结构方面的很多问题。但是，如果启用此功能，将允许尝试删除数据库的查询，因此，如果选择使用此功能，请确保数据库的安全性无懈可击。
总结
SQL Server XML 提供了一种新的观念，通过允许从数据库直接检索 XML，使您的应用可以端对端使用 XML。新的 ISAPI 应用提供了令人满意的性能，但不一定适用于应用中的所有使用情况。
文章来源：未知 | 
