安装SQLServer 2008 R2 提示 Microsoft .NET 应用程序安全性

启用NET Framework 3.5功能即可，具体 *** 作如下：

1、打开系统控制面板，点击程序，进入程序功能。

2、找到程序与功能，下面有启动或关闭windows功能，点击打开。

3、打开windows功能选项卡，找到NET Framework 3.5，不要打开直接点击前面的方框选中，内部所有功能都会被选中。

4、然后等待十分钟左右，系统自动安装，下图显示已通过为SQLServer 2008 R2安装完成。

一些活动，如读写文件，显示对话框，读写环境变量，可以通过包含在框架安全构架中的.NET Framework方法实现。这就使.NET Framework能根据安全策略允许或不允许一个 *** 作，而不需要程序员做额外的工作。尽管暴露了保护资源的管理类的创建者在他们的库中做了明确的安全需求，使用.NET Framework类库访问受保护资源的开发人员可以自由地利用代码访问安全系统；他们不必作出明确的安全调用。

管理员可以通过决定给予哪些许可来优化安全策略，然后，依靠.NET Framework处理所有的安全 *** 作。代码访问安全能阻止大部分的恶意攻击，对代码的验证减少了缓存溢出和其它会导致安全攻击的不期望的行为。因此，应用程序和组件生来就受到了保护，它们免于大多数安全问题的冲击，而这些安全问题一直困绕着本地代码的实现。 有时根据已认证的身份或根据与代码执行上下文相关的角色作出认证决定是合适的。例如，金融和企业软件可以通过评估角色信息的企业逻辑加强策略。根据作出请求的用户角色可以对金融交易的数据进行限制。出纳被允许可以处理一定金额的请求，而多于该金额的所有工作需要监督人的角色来处理。

身份可以映射到登录系统的用户，或由应用程序定义。相应的原则封装了身份和其它相关的角色信息（例如，但并不限于此，用户的组由 *** 作系统定义）。

认证和授权

认证是一个过程，它接收来自用户的证书，并对证书的授权进行确认。如果证书是有效的，那么用户就可以说他拥有已认证的身份。而授权的过程是：确定认证用户是否能够访问给定的资源。认证可通过系统或企业逻辑来完成，通过某个API它是或获得的。认证API是完全可扩展的，因此开发人员根据需要使用自己的企业逻辑。开发人员可以对他们的认证需求进行编码，也可以修改底层的认证方法而无需对他们的代码作太大变化。除了微软Windows? *** 作系统身份认证外，还有的认证方法包括基本HTTP，摘要和 Kerberos，以及微软Passport和基于窗体的认证。这些认证方法已经完全集成到中了。

在窗体认证中，用户提供证书，并提交窗体。如果应用程序簦别请求，系统发送一个cookie ，该cookie以某种形式包含包含了证书或包含重新获得身份的关键字。接下来发送的请求在头中包含了cookie，处理程序通过应用程序所期望的任何有效方法对这些请求认证和授权。如果请求没有经过认证，HTTP客户端将用于把请求发送到认证窗体，在那里用户可能提供信任证书。窗体认证有时用于个性化--为已知用户的内容进行定置。在一些情况下，身份是问题所在而不是认证，因此用户的个性化信息可以简单地通过访问用户或获得。

授权的目的是确定作出请求的身份是否被给予了对给定资源的访问权。提供了两种类型的授权服务：文件授权和URL授权。文件授权根据正在作用的方法和作出请求的身份决定用户使用于哪个访问控制列表。URL授权是URI名称空间和不同用户或角色间的逻辑映射。 .NET Framework提供了一个特殊的功能，隔离存储，用于存储数据，甚至是当不允许对文件进行访问时--例如，当从Internet下载了一个管理控件，并运行它，为它提供了有限的许可权但没有权力读写文件。

隔离存储是一组新的用于.NET支持的用于本地存储的类型和方法。在本质上，每个组合可以访问磁盘上一断被隔离的存储空间。它不允许访问其它数据，隔离存储只对为它创建的组合有效。

隔离存储也可被应用程序用于保存活动记录，保存设置，或者将状态数据保存到磁盘上以备将来之用。因为隔离存储的位置是预先决定好的，所以隔离存储为指定唯一存储空间提供了一种方便的方式，而不需要决定文件路径。

从本地企业局域网获得的代码具有相似的限制，但更少，它可以访问大限额的隔离存储。最后，从受限站点区域（不信任站点）来的代码没有对隔离存储的访问权。

加密

.NET Framework提供了一组加密对象，它们支持加密算法、数字签名、散列、生成随机数，是通过众所周知的运算法则实现的，如RSA, DSA, Rijndael/AES, Triple DES, DES, 和 RC2, 以及MD5, SHA1, SHA-256, SHA-384 和 SHA-512散列算法。同时还支持在IETF和W3C开发的XML数字签名规范。.NET Framework使用加密对象支持内部服务。这些对象还作为管理代码提供给需要加密支持的开发人员。

如何指定安全性？

如果要对组合运行时的行为进行修改，根据程序员的需要，可以作出声明式安全或强迫式安全的修改。 声明式安全使程序员可以直接在组合代码的元数据中为组合指定安全需求。许可请求和所有其它形式的声明式安全是在代码中是作为定置属性指定的。类，属性和方法的注释用于优化许可。例如，声明式安全可用于类的调用者在调用方法前检查调用者是否被已知地行商签名过，或有一个特定的强名。

由于声明属性是组合元数据的一部分，所以组合的安全需求易于辨别。可以使用工具对组合进行扫描，以发现哪些方法需要某些许可，哪些方法断言了某些许可。

当被请求的活动和许可在编译时是知道时，声明式检查可作为选择的解决方案之一。例如，如果方法总是检查对C:temp的写访问许可，那么许可检查就会从声明中得到好处。另一方面，如果被请求的具有访问权的位置发生了变化，那么强迫式安全也许是一个比较好的解决方案。 强迫式安全直接在代码中实现。程序员通过程序采取安全活动，并且根据安全堆栈的状态决定是给予还是拒绝许可。例如，当一个方法请求访问一个特定的文件时，如果调用者（或方法的任何一个调用者）没有被给予必需的许可权限，那么请求失败。因为强迫式安全是通过程序实现的，所以满足了动态需求。如果你需要对一个特定文件的访问许可，但该许可还要根据其它信息发生变化，那么，强迫式安全就是可选的解决方案。

.NET Framework安全迎合了这种事实：软件向多样化的移动组件发展，并根据这种事实提供保护。在一个细化的、可扩展的策略和许可系统下，用户能够运行功能强大的代码，而同时减少相关的风险。在没有运行时对用户作出信任决定时，管理员可以在各个级别创建强壮的安全策略。策略是完全可定置的。开发人员能够集中解决应用程序逻辑，而不用关心核心的安全问题（它由CLR透明地处理）。然而，开发人员可以在任何时候扩展安全模型。

有许多程序设计师和使用者，非常渴望有一个完善而且透明清楚的基础架构，来建立WebServices（因特网服务）。.NET Framework 就是为了这个需求，而提供的基础架构。.NETFramework 提供了应用程序模型及关键技术，让开发人员容易以原有的技术来产生、部署，并可以继续发展具有高安全、高稳定，并具高延展的Web Services。对于.NET Framework 而言，所有的组件都可以成为Web Services，Web Services 只不过是另一种型态的组件罢了。微软将COM 的优点整合进来，它可以不用像COM 那么严谨的来栓锁两个对象，.NET Framework 以松散的方式来栓锁Web Services 这种型态的组件。这样的结果让开发人员非常容易的发展出强而有力的Web 服务组件，提高了整体的安全及可靠性，并且大大的增加系统的延展性。

.

Analysis services 2000的简介

适用于：Microsoft® SQL Server™ 2000 Analysis Services

摘要：学习如何使用 Microsoft XML for Analysis Provider 附带的连接池对象来开发

适用于 Microsoft SQL Server 2000 Analysis Services 的可伸缩客户端和 Web 应用程序

目录

简介

读者

连接池对象

使用连接池对象

请求和返回连接

平衡和收缩连接池

ADOConPool 对象

OLEDBConPool 对象

小结

其他信息

简介

资源管理是开发可伸缩客户端和基于 Web 的应用程序时需要考虑的一个重要问题。在构

造可为许多并发用户提供服务的客户端应用程序时，资源管理的指导原则是尽可能迟地分配资

源，并尽可能早地解除资源分配。资源（例如内存、进程线程以及网络或数据库连接）的可用

性与客户端应用程序的性能和用户的满意程度直接相关。因此，随着客户端应用程序的不断扩

通过对资源管理进行进一步的控制，连接池可以降低可伸缩性的影响。连接池使客户端应

用程序能够在连接池与给定资源之间建立连接，而不需要在每次使用时都重新建立连接。在连

接池中建立连接之后，客户端应用程序可以重复使用该连接，而不必执行完整的连接过程。

因为客户端应用程序不需要重复地建立和关闭连接，使用池缓冲的连接会显著提高连接性

能。此过程所需的时间对使用滞后时间较长的资源（例如 Internet 或网络连接）的客户端应

用程序来说尤其重要。当客户端应用程序不再需要连接时，该连接就返回到连接池。

除了可以提高性能以外，使用连接池还可以更有效地管理资源，同时又不会给客户端应用

程序增加额外的资源管理费用。连接池管理器可以根据需要分配和解除分配连接以维护连接池

为了支持使用 Microsoft SQL Server 2000 Analysis Services 的 Web 客户端应用程序

的可伸缩性需要，Microsoft XML for Analysis Provider 中已经实现了连接池功能。XML

for Analysis Provider 会自动使用连接池，另外也可以对其他不需要使用由提供程序本身提

供的 XML 连接的客户端应用程序使用此功能。本文旨在介绍一些对象，通过它们可以充分利

用 Analysis Services 客户端应用程序中的连接池。

读者

本文假定读者具备 SQL Server 2000 Analysis Services 以及 Microsoft

ActiveX® 数据对象 (ADO) 和 OLE DB 数据访问技术的基础知识。有关示例可在

Microsoft Visual Basic® 和 Microsoft Visual C++® 中找到。

连接池对象

XML for Analysis Provider 中提供了两个对象：ADOConPool 和 OLEDBConPool。

ADOConPool 对象用于管理 ADO 连接对象；OLEDBConPool 对象用于管理 OLE DB 会话对象。

虽然两种对象提供的连接池类型不同，但是它们均使用了相同的基础机制来管理连接池。在本

文中讨论这种共享的机制时，用术语“连接”来描述 ADO 连接对象和 OLE DB 会话对象。

连接池机制仅适用于 Microsoft SQL Server 2000 Service Pack 1 (SP1) 中包含的、已

经过更新的 Microsoft OLE DB Provider for OLAP Services 8.0 (MSOLAP.2) OLE DB 提供

使用连接池对象

在支持 ADO 或 OLE DB 数据访问技术的编程语言中，可以使用 ADOConPool 和

OLEDBConPool 对象。但是，要在 Visual C++ 程序中使用这些对象，必须在程序中添加以下

编译器指令以包含正确的头文件和属性：

"tagPROPVARIANT") rename("_LARGE_INTEGER","")

rename("_ULARGE_INTEGER","")

using namespace MSXmlAnalysisSCLib

请求和返回连接

从连接池请求连接所用的机制不同于 OLE DB 资源池对基于 Web 的应用程序进行快速访

问所用的机制。连接池对象将活动连接池分成两组：“可用连接”和“已用连接”。可用连接

由当前未分配给客户端应用程序的连接组成；已用连接是指当前已分配给客户端应用程序并被

连接请求需要采用特殊的身份验证和模拟机制。当通过应用程序请求连接时（

ADOConPool 对象使用 GetConnection 方法，而 OLEDBConPool 对象使用 GetSession 方法）

，连接池试图检索可用连接，检索条件是该连接使用的域名和用户名与客户端应用程序所用的

安全标识符 (SID) 相同。如果找到匹配的可用连接，则将其返回到客户端应用程序。

如果未找到与客户端 SID 信息匹配的连接，连接池对象就会对客户端请求中传递的连接

信息进行分析，以确定连接池中是否已经存在同一个请求数据库的可用连接。如果找到匹配的

数据库，连接池对象就会尝试将客户端请求的角色安全性与现有可用连接的角色安全性进行匹

配。如果发现角色安全性是匹配的，连接池对象会接着比较可用连接的用户名和客户端请求的

用户名。如果用户名也匹配，则将可用连接返回到客户端应用程序。如果用户名不匹配，则根

据 Analysis 服务器上的角色安全性，使用客户端请求的域和用户名重新验证可用连接，然后

如果未找到匹配的角色安全性和数据库，则在连接池中创建一个新的连接并将其分配给发

与资源共享通常采用的方法相比，此方法还具备一个优点，即发出请求的客户端应用程序

可以重复使用具有同一角色安全性权限的现有活动连接，即使该连接最初是由其他用户请求的

。与可用连接相关联的新用户名仍然通过了验证，因此能够维护其安全性，并且可以将该连接

提供给客户端。这就缩短了为大量并发用户提供服务的客户端应用程序的连接时间并降低了费

对于那些执行大量 *** 作并需要重复请求和返回连接的客户端应用程序来说，该机制的效率

更高。可以将同一个活动且经过验证的连接返回到发出请求的客户端应用程序。

对于客户端应用程序来说，将连接返回到连接池是一个非常简单的过程。客户端应用程序

将连接引用传递回连接池对象（ADOConPool 对象使用 ReturnConnection 方法，而

OLEDBConPool 对象使用 ReturnSession 方法）。连接池对象验证传递回的连接对象是否确实

注意事项

如果用户请求了某个连接，将其释放，然后又从连接池对象中请求另一个连接，则根据连

接池内的活动连接重新验证用户所使用的模拟机制将返回同一连接，而不需要重复访问

Analysis 服务器。如果用户释放第一个连接请求后其角色权限发生了变化，则第二个请求将

例如，某个用户在 Analysis 服务器上的角色为 Role A。Role A 使用户可以对两个多维

数据集 Cube A 和 Cube B 运行查询。当此用户所使用的客户端应用程序首次请求连接时，返

回的连接有权访问 Cube A 和 Cube B。客户端应用程序运行查询，然后释放连接。

Analysis 服务器的管理员现在将 Role A 的访问权限更改为只能访问 Cube A。如果此用户

的客户端应用程序请求另一个连接，首次请求时创建的连接将再次返回到该客户端应用程序，

但是，它仍然有权访问 Cube A 和 Cube B。虽然 Role A 对应的用户当前只能访问 Cube A

，但仍会对 Cube B 继续执行查询，就好象此用户对该多维数据集仍具有访问权限一样。

只有重新分配活动连接，才会出现这种问题；新创建的连接始终会跟 Analysis 服务器进

行验证。如果上面的示例中客户端应用程序首次请求的活动连接已超时，系统就会为该客户端

应用程序分配一个新创建的连接，这时该连接就具有正确的角色权限。

对于 Web 应用程序，解决此问题的最简单的方法是每当 Analysis 服务器上的角色发生

改变时都重新启动 Microsoft Internet Information Services (IIS)，强制应用程序在请求

鉴于 IIS 线程管理的特性，当您创建基于 Web 的应用程序时，在 Active Server

Pages (ASP) Web 应用程序中使用 ADOConPool 和 OLEDBConPool 连接池对象时应该特别小心

。IIS 检查每个 COM 组件以确定其灵活性（COM 组件的线程处理和封送处理能力）。XML

for Analysis Provider 支持自由线程模块，但并不提供自由线程封送拆收器 (FTM)。正是由

于这个原因，IIS 5.0 或更高版本认为 XML for Analysis Provider 并不灵活。

这意味着如果使用 IIS 5.0 或更高版本的默认设置，ADOConPool 和 OLEDBConPool 对

象在缓存于 ASP 应用程序的应用程序或会话作用域中（换句话说，缓存于 ASP

Application 或 Session 对象变量中）时将使用系统安全性上下文。请求和返回连接中介绍

的模拟机制将无法正常工作。连接池对象在试图验证所有活动连接时将使用默认的 IIS 用户

为了纠正这一错误，请将 IIS 5.0 或更高版本的配置数据库中的

ASPTrackThreadingModel 设置更改为 True。更改此设置是为了防止 IIS 检查 COM 组件的灵

活性，但是，由于要进行封送处理和序列化，这会导致性能的降低，因此应该只在包含 Web

应用程序的虚拟目录或 Web 目录中更改此设置。

平衡和收缩连接池

连接池中包含的连接数目没有严格的限制，因为已将基础管理机制设计为无阻碍机制，即

客户端应用程序在请求连接时应该都能获得连接。正是由于无阻碍的特点，两个对象才能使用

不过，也可以使用两种不同的技术来管理连接池：“平衡”和“收缩”。

平衡连接池

每当将连接返回到连接池（ADOConPool 对象使用 ReturnConnection 方法，而

OLEDBConPool 对象使用 ReturnSession 方法）时，都会用到平衡技术。连接池对象将把活动

连接（已用连接和可用连接）的总数与 MaxSessions 属性值进行比较，以确定是否有必要平

衡连接池。如果活动连接的总数大于 MaxSessions 属性值，则需要进行平衡。

为了平衡连接池，连接池对象将根据自上次访问每个可用连接以来经过的秒数对可用连接

组进行排序。然后，该对象逐一删除那些经过时间最长的可用连接，直到已用连接和可用连接

的总数小于 MaxSessions 属性值或者没有任何活动的可用连接为止。

注意：平衡时不使用 Timeout 属性。

收缩连接池

每当客户端应用程序调用 ADOConPool 或 OLEDBConPool 对象的 Shrink 方法时，都会用

到收缩技术。此技术是针对过期的可用连接而言的。连接池对象将把每个可用连接的上次访问

时间与当前系统时间进行比较，如果相差的秒数大于 Timeout 属性值，就会删除该可用连接

但是，这两种技术都不适用于管理已用连接。在完成一项 *** 作之后，客户端应用程序负责

将连接返回到连接池，这样就可以把已用连接作为可用连接进行重新分配。连接池对象并不试

图管理已用连接，而是仅对可用连接进行平衡和收缩。使用此方法可以在性能和资源管理之间

ADOConPool 对象

ADOConPool 对象为使用 ADO 数据访问技术的客户端应用程序提供连接池，从而维护

ADOConPool 对象具有以下属性和方法：

MaxSessions 属性

MaxSessions 属性用于限制连接池中 ADO 连接对象（包括可用连接和已用连接）的数目

数据类型

长整型

权限

读/写

备注

由于连接池机制被设计为无阻碍机制，因而并不使用 MaxSessions 属性直接限制连接池

的增长。而是由 ReturnConnection 和 Shrink 方法使用此值来平衡和收缩连接池。有关平衡

和收缩的详细信息，请参阅本文前面介绍的平衡和收缩连接池。

Sessions 属性

Sessions 属性返回连接池中活动 ADO 连接对象的数目。

数据类型

长整型

权限

只读

备注

Sessions 属性报告由 ADOConPool 对象管理的连接（包括已用连接和可用连接）的总数

Timeout 属性

Timeout 属性设置或返回可用 ADO Connection 对象保持活动状态的秒数。

数据类型

长整型

权限

读/写

备注

与 MaxSessions 属性类似，Timeout 属性由 Shrink 方法用来识别要从连接池中删除的

活动可用连接。有关收缩的详细信息，请参阅平衡和收缩连接池。

GetConnection 方法

如果给定连接字符串，GetConnection 方法将返回 ADO Connection 对象。

语法

C++

HRESULT GetConnection([in] BSTR in_bstrCn, [out,retval] IDispatch**

Visual Basic

Set io_ppADOConnection = object.GetConnection(in_bstrCn As String)

object

对 ADOConPool 对象的有效引用。

in_bstrCn

适用于 ADO Connection 对象的连接字符串。

io_ppADOConnection

返回的 ADO Connection 对象引用。

备注

此方法试图在创建新连接之前通过匹配连接和安全性信息，从连接池中请求现有的可用连

接。有关请求连接的详细信息，请参阅请求和返回连接。

ReturnConnection 方法

ReturnConnection 方法将 ADO Connection 对象返回到连接池。

语法

C++

HRESULT ReturnConnection([in,out] IDispatch** io_ppADOConnection)

Visual Basic

object.ReturnConnection io_ppADOConnection

object

对 ADOConPool 对象的有效引用。

io_ppADOConnection

要返回到连接池的 ADO Connection 对象。

备注

使用此方法返回连接之后，连接池对象会自动平衡可用连接。有关平衡连接的详细信息，

Shrink 方法

当 Shrink 方法被调用时，它将终止过期的可用 ADO 连接对象并从连接池中将其删除。

语法

C++

HRESULT Shrink()

Visual Basic

object.Shrink

object

对 ADOConPool 对象的有效引用。

备注

客户端应用程序应该定期调用此方法，以终止并删除已经超时的可用连接。有关收缩连接

池的详细信息，请参阅平衡和收缩连接池。

OLEDBConPool 对象

OLEDBConPool 对象为使用 OLE DB 数据访问技术的客户端应用程序提供连接池，从而维

护 OLE DB 会话对象的集合。OLEDBConPool 对象适用于那些直接使用 OLE DB 对客户端数据

进行访问的应用程序，而大多数启用 Web 的应用程序应该使用 ADOConPool 连接池对象。

MaxSessions 属性

MaxSessions 属性用于限制连接池中 OLE DB 会话对象（包括可用会话和已用会话）的数

数据类型

长整型

权限

读/写

备注

由于连接池机制被设计为无阻碍机制，因而并不使用 MaxSessions 属性直接限制连接池

的增长。而是由 ReturnSession 和 Shrink 方法使用此值来平衡和收缩连接池。有关平衡和

收缩的详细信息，请参阅平衡和收缩连接池。

Sessions 属性

Sessions 属性返回连接池中活动 OLE DB 会话对象的数目。

数据类型

长整型

权限

只读

备注

Sessions 属性报告由 OLEDBConPool 对象管理的连接（包括已用连接和可用连接）的总

Timeout 属性

Timeout 属性设置或返回可用 OLE DB 会话对象保持活动状态的秒数。

数据类型

长整型

权限

读/写

备注

与 MaxSessions 属性类似，Timeout 属性由 Shrink 方法用来识别要从连接池中删除的

活动可用连接。有关收缩的详细信息，请参阅平衡和收缩连接池。

GetSession 方法

如果给定一组 OLE DB 属性，GetSession 方法将返回 OLE DB 会话对象。

语法

C++

HRESULT GetSession([in] int in_cPropSets, [in] DBPROPSET* in_pPropSets,

[out,retval] IDBCreateCommand** io_ppSession )

in_cPropSets

in_pPropSets 参数中引用的 tagDBPROPSET 类型结构的长度（以字节为单位）。

in_pPropSets

用来标识和（如果必要）创建 OLE DB 会话对象的 tagDBPROPSET 类型结构的指针。有关

tagDBPROPSET 类型结构的详细信息，请参阅 OLE DB 文档（英文）中的 DBPROPSET

io_ppSession

返回的 OLE DB 会话对象引用。对象引用被转换为 IDBCreateCommand OLE DB 接口。有

关 IDBCreateCommand 接口的详细信息，请参阅 OLE DB 文档（英文）中的

备注

此方法试图在创建新连接之前通过匹配连接和安全性信息，从连接池中请求现有的可用连

接。有关请求连接的详细信息，请参阅请求和返回连接。

ReturnSession 方法

ReturnSession 方法将 OLE DB 会话对象返回到连接池。

语法

C++

HRESULT ReturnSession([in,out] IDBCreateCommand** io_ppSession)

io_ppSession

返回到连接池的 OLE DB 会话对象。

备注

使用此方法返回连接之后，连接池对象会自动平衡可用连接。有关平衡连接的详细信息，

Shrink 方法

当 Shrink 方法被调用时，它将终止过期的可用 OLE DB 会话对象并从连接池中将其删除

语法

C++

HRESULT Shrink()

备注

客户端应用程序应该定期调用此方法，以终止并删除已经超时的可用连接。有关收缩连接

小结

连接池是一种有效的资源管理方法。使用作为 Microsoft XML for Analysis Provider

的一部分提供的连接池对象，可以将这种资源管理方法扩展到使用 Microsoft SQL Server

2000 Analysis Services 的客户端应用程序，从而减少开发和实施过程中的开支，以低成本

实现高性能。

另外,站长团上有产品团购,便宜有保证

---