SQL Server 本机 Web 服务的使用方案
|
摘要： 获得有关如何设置 SQL Server 以便在异类环境中进行 Web 服务访问的详细讨论，并且了解更多有关 SQL Server 中 Web 服务的主要方案的信息。 下载相关的 WebServicePerlScript.exe 代码示例。 简介 （如 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 服务的方案。 异类访问 应用程序，我们的建议是使用 SQL Server 授权 (SQL-Auth) 连接到 SQL Server Web 服务。让我们考察一下该 机制是如何工作的。 要公开 Web 服务，用户需要做的第一件事情是创建一个终结点。请观察如下所示的用于创建终结点的数据定义 语言 (DDL) 语句。它将一个名为“GetCustomerInfo”的存储过程公开为 Web 服务。 注 尽管术语 WEBMETHOD 在概念上与 ASP.NET 中的 [WebMethod] 相同，但它在其他方面与 ASP.NET 无关。 CREATE ENDPOINT sql_auth_endpoint 访问。这意味着所有连接都需要使用受支持的身份验证方案之一在 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 消息如下所示： : XMLns:SOAP- ENV="http://schemas.XMLsoap.org/soap/envelope/" XMLns:sql="http://schemas.microsoft.com/sqlserver/2004/SOAP" XMLns:sqlsoaptypes="http://schemas.microsoft.com/sqlserver/2004/SOAP/types" XMLns:sqlrowcount="http://schemas.microsoft.com/sqlserver/2004/SOAP/types/SqlRowCount" XMLns:sqlmessage="http://schemas.microsoft.com/sqlserver/2004/SOAP/types/SqlMessage" XMLns:sqlresultstream="http://schemas.microsoft.com/sqlserver/2004/SOAP/types/SqlResultStream" XMLns:sqltransaction="http://schemas.microsoft.com/sqlserver/2004/SOAP/types/SqlTransaction" XMLns:sqltypes="http://schemas.microsoft.com/sqlserver/2004/sqltypes"> : |
