摘要： 获得有关如何设置 SQL Server 以便在异类环境中进行 Web 服务访问的详细讨论，并且了解更多有关
SQL Server 中 Web 服务的主要方案的信息。
下载相关的 WebServicePerlScript.exe 代码示例。
简介在 SQL Server 中，我们向数据库引擎中添加了对本机 XML Web 服务的支持。这一功能是围绕众所周知的标准
（如 SOAP 1.2、WSDL 1.1 和 HTTP）设计的。将解决方案建立在这些标准之上，可以在大多数企业都拥有的异
类环境中支持互操作性和服务扩张。
添加到 SQL Server 中的新的基础结构大大有利于直接向服务器外部公开 Web 服务，这是因为将本机 SOAP 堆栈
内置到数据库引擎中消除了使用中间层进程（如 IIS）达到这一目标的需要。它还使 SQL Server 能够作为组件
参与面向服务的体系结构，因为服务在这些新的体系结构中提供了黏合剂。本机 XML Web 服务使您既可以将存储
过程作为 Web 服务公开，而且可以针对数据库服务器执行特殊的 T-SQL 语句。实际上，我们已经基于 SOAP 创
建了一种新的访问 SQL Server 的机制；SOAP 提供了与当前的 Tabular Data Stream (TDS) 专用二进制协议几
乎相同的功能。
我们首先详细考察如何设置 SQL Server 以便在异类环境中进行 Web 服务访问。我们将查看如何使用 Perl 脚本
进行数据库管理，并且简要考察一下其他可以使用本机 Web 服务的方案。
异类访问请考虑这样一个环境，在这里，运行在非 Microsoft 操作系统上的应用程序需要连接到 SQL Server。对于此类
应用程序，我们的建议是使用 SQL Server 授权 (SQL-Auth) 连接到 SQL Server Web 服务。让我们考察一下该
机制是如何工作的。
要公开 Web 服务，用户需要做的第一件事情是创建一个终结点。请观察如下所示的用于创建终结点的数据定义
语言 (DDL) 语句。它将一个名为“GetCustomerInfo”的存储过程公开为 Web 服务。
注 尽管术语 WEBMETHOD 在概念上与 ASP.NET 中的 [WebMethod] 相同，但它在其他方面与 ASP.NET 无关。
CREATE ENDPOINT sql_auth_endpoint STATE = STARTED AS HTTP( SITE = '*', PATH = '/sql/sql_auth', AUTHENTICATION = (BASIC), PORTS=(SSL) ) FOR SOAP( WEBMETHOD'GetCustomerInfo' ( name='AdventureWorks.dbo.GetCustomerInfo', schema=STANDARD ) , LOGIN_TYPE = MIXED, WSDL = DEFAULT, DATABASE = 'AdventureWorks', BATCHES=ENABLED, NAMESPACE = 'http://Adventure-Works/Customers/' )为了保持 SQL Server 中的“设计安全”主题，我们在任何情况下都不允许对 SQL Server 进行 ANONYMOUS
访问。这意味着所有连接都需要使用受支持的身份验证方案之一在 HTTP 传输级别进行身份验证。BASIC
是最常见和使用最广泛的身份验证模型之一，因为它受到大多数客户端的支持。但是，它也是最不安全的选择，
因为它要求以明文发送密码。为了避免该问题，我们要求每当选择 BASIC 作为身份验证类型时，都要为 SSL
启用终结点。要启用 SSL，必须执行以下命令：
httpcfg set ssl /i IP:Port /h Hash /g Guid
其中，Hash 是证书哈希，Guid 是一个标识注册该证书的实体的全局唯一标识符 (GUID) 字符串。用户可以
通过在 Certificate 中查找 Thumbprint 值来获取证书的哈希值。作为最佳实施策略，请为 SQL Server
的每个实例创建单个 GUID，并且对于该实例执行的所有证书注册，都使用同一个 GUID。您可以使用任何
工具来发现该 GUID 值。Httpcfg.exe 随附了 Windows 支持工具。
因此，在该示例中，它将成为：
httpcfg set ssl /i 1.1.1.1:443 /h 4463b7899c499a38812a7bbe7d73f4d31d026b2f /g
"{2bb50d9c-7f6a-4d6f-873d-5aee7fb43290}"
其中，1.1.1.1 会被宿主 SQL Server 的计算机的 IP 地址替换。
那么，如何在终结点上启用 SQL-Auth 呢？这是通过在终结点语法的 payload 节中指定“LOGIN_TYPE=MIXED”
完成的。通过指定“MIXED”，您可以使用集成式或 SQL 身份验证对 SQL Server 实例进行身份验证。现在，
我们使 SQL 凭据能够作为有效负载（消息）的一部分流动。在完成该工作时，我们已经小心地确保传输凭据的
SOAP 标头与 WS-Security Username 标记相匹配。遵循 WS-Security 标准自然可以提高互操作性；例如，
只需很少的几行代码，就可以使用 Web Services Enhancements 2.0 for Microsoft .NET (WSE) 生成用户
名标记 SOAP 标头。
正如您可以在上述讨论中看到的那样，存在两种级别的身份验证：
•传输级别
•消息级别
现在，让我们深入探讨这两个级别的身份验证是如何工作的。
所有请求总是在传输级别进行身份验证。因此，如果用户提交无效的 BASIC 身份验证凭据，则连接失败
，并且发生 HTTP 401 访问被拒绝错误。如果用户成功地在传输级别进行身份验证，则我们具有两个选择。
我们可以使用传输凭据或作为 SOAP 消息的一部分到来的凭据登录 SQL Server。所选的凭据是由 SOAP
消息中是否存在 SQL-Auth 凭据确定的。如果 SOAP 消息中存在凭据，则我们将试图使用 SQL-Auth
凭据登录 SQL Server 数据库。如果该方法失败，则我们向用户返回失败，并且我们不会后退到使用
BASIC 身份验证凭据。如果 SOAP 消息中不存在凭据，则我们将试图使用传输凭据登录 SQL Server。
包含 SQL 凭据的 SOAP 消息如下所示：
: : : : SOAP-ENV:Client : : There was an error in the incoming SOAPrequest packet: Client, LoginFailure, AccessDenied : http://schemas.microsoft.com/sqlserver/2004/SOAP : : : There was an error in the incoming SOAPrequest packet: Sender, LoginFailure,