7. 开发 Web 应用程式
本章包括：
Web应用程式概论
开放式的Internet标准已经永久地改变了分散式计算的结构；Web的基本语言HTML也已经成了展现使用者介面元素的常用语言。透过跨平台支援的指令档语言和Java程式，以及支援嵌入式COM元件，这样就可以将动态元素与静态文字相结合，让使用者获得更强的互动式体验。不过，Web技术并不仅仅用於 Internet上，它也可以应用到下列商业行为中：
本节将描述建立Web应用程式时的一般性概念。
建立在用户端／伺服器基础架构上
在研究建立基於Web之应用程式以前，先回顾一下Web的结构模式和在模式中的浏览器与伺服器之间的角色关系，是非常有帮助的。
一般而言，合作的应用程式可以归类为用户端程式或者伺服器端程式二种。用户端应用程式要求伺服器的服务和资料，而伺服器端应用程式则回应用户端的请求。早期开发的两层式（用户端／伺服器）应用程式是为了存取大型资料库，并且将用於操作资料的规则和使用者介面整合到用户端应用程式中。伺服器的任务只是尽可能满足大量存取资料的请求。
双层（Two-tier）应用程式执行许多独立系统的功能：它们提供使用者介面、收集并处理使用者输入、执行请求的程序，以及报告请求的状态。指令序列可以根据需要而重覆执行许多次。因为伺服器只提供对资料的存取，所以用户端是使用它的本机资源来执行大多数的处理任务。用户端应用程式必须含有资料储存位置及它们在资料库中如何组织的资讯。一旦取得资料以後，用户端负责将资料格式化，并且把它们显示给使用者。
用户端／伺服器模式的主要优点是透过让多个使用者同时存取相同的应用程式资料，在一台电脑上进行的更新可以在所有存取伺服器的电脑上立即生效。但是，随着用户端数量的增加，伺服器很快就无法应付用户端的请求了。而且，因为许多处理逻辑被限制於一个整体的应用程式套件中，所以要改变商业规则将导致必须修改来源程式码。尽管双层模式的简单和灵活性催生了许多小规模的商业应用程式，但是更快的资料存取和更迅速的开发时间（timelines）的需求，已迫使系统开发者去寻求建立分散式应用程式的新方法。
新的系统设计
今天的用户端／伺服器应用程式与先前几乎完全不同，於是它们有了一个新的名称：多层应用程式（multitier application），也称为n层（n-tier）基础结构。在这种模式中，处理程序被分散在用户端和伺服器之间，而在中间层取得商业逻辑。大多数系统将执行下面的叁个主要任务，它们对应於n层模型的叁个等级或者叁层：
| 工作 | 说明 |
|---|---|
| 使用者介面和导览 | 在下图中被标示为Tier 1的层级。本层包含了使用者全部可体验到的经验，其中不仅提供图形的介面，也让使用者可以跟应用程式进行互动、输入资料并且检视请求的结果，而且一旦用户端接收到资料，它也会管理资料的操作和格式化。在Web应用程式中，浏览器担任此一层级的工作。 |
| 商业逻辑 | Tier2层是在使用者介面和资料服务层之间，它属於分散式应用程式开发者的领域。商业逻辑取得主掌应用程式处理的规则，一端与使用者相连，另一端与资料相连。由规则主掌的功能近似於日常的商业任务，这些功能可以是独立的工作或者是一系列的工作。 |
| 资料服务 | 在下图中被标示为Tier 3的层级。资料服务是由结构化（SQL、Oracle资料库）或者非结构化（Microsoft Exchange、Message Queuing）资料存放区来提供的，负责管理并且提供对应用程式资料的存取能力。独立应用程式可以取得一个或者数个资料储存服务。 |
叁层结构区隔了每个主要的功能。这样，功能的存在独立於处理规则和商业逻辑之外，因而与资料分离。这个模式虽然需要进行更多的分析和设计，但却大大地降低了维护成本，并且提高了在长期执行时，功能上的灵活性。下图描述了在新系统设计中，在不同层中提供服务的Microsoft技术。
| 图7-1 叁层架构 |
Microsoft Windows Distributed interNet
Application基础架构
Microsoft开发了Windows Distributed interNet Application基础架构（Windows DNA）以作为整合开发Web与n层模式的方法。Windows DNA为能满足公司电脑化、Internet、intranet以及全球性电子商务要求的解决方案定义了架构，同时降低了总体的开发和部署成本。
Windows DNA结构采用了标准、基於Windows的服务来满足在多层解决方案中，使用者介面、导览，以及商业逻辑和资料储存各层的需求。在Windows DNA中使用的服务是透过Component Object Model（COM）进行整合的，包括：
Microsoft使用公开的通讯协定和公共介面来建立Windows DNA架构，这使得公司可以更容易地整合协力厂商产品。另外，透过支援Internet电脑计算需求的工业标准，Windows DNA使开发者可以更容易地对技术更新最初回应。一些近来新增到Windows DNA中的技术将在本章後面的
〈开发技术〉 中加以介绍，下图则列出了这些技术。
| 图7-2 Windows DNA架构 |
Internet资讯服务架构
IIS 5.0是构成整个Windows DNA结构的重要组成部分。IIS 5.0所扮演的重要角色是利用Hypertext Transfer Protocol（HTTP）将存取系统的用户端连线到其他的Windows DNA服务，例如DHTML、ASP等。另外，IIS 5.0还包含能让系统开发者可以延伸来定义自订应用程式结构的基本功能集合。
本章节的主旨就是描述这些基本功能，并且定义了IIS 5.0结构与其他 Windows DNA结构之间的关系，同时也提供关於IIS 5.0如何处理HTTP请求的一般简介。
IIS核心功能
IIS 5.0定义了您可以用来建立Web应用程式的基本功能。Active Server Pages（ASP）和其他Microsoft技术已经延伸了这个基本功能，能为应用程式的开发建立更丰富的环境。其中基本的伺服器功能是透过Internet Server Application Programming Interface（ISAPI）展现的。
IIS 5.0所提供的核心功能包括：
ASP藉由提供到COM基础架构以及与其他在Windows DNA中之相关人员的连线来延伸了这些功能。类似地，您可以使用ISAPI来定义自订的功能集以便来延伸IIS 5.0基础架构。IIS 5.0的核心功能、ASP与延伸基础架构之间的关系如下图所示：
| 图7-3 IIS架构 |
IIS 5.0与元件服务
您可将IIS 5.0和元件服务一起使用，以建立Web应用程式的基本结构。 IIS 5.0使用元件服务提供的功能来：
说明
在IIS 4.0版中，Microsoft Transaction Server（MTS）提供了异动处理的支援。在IIS 5.0和Windows 2000中，元件服务不但支援所有 MTS的异动处理，还包含额外的元件开发和布署功能。
IIS 5.0将Web应用程式定义为资源档案的集合，这些资源档案被分组到逻辑名称空间中。透过将资源分组成应用程式，可以获得在整个名称空间共用资料和在个别程序中执行应用程式的能力。
从内部来说，IIS 5.0是利用一个称为Web Application Manager的物件来协调独立的应用程式，它包括一个您可用来建立管理Web应用程式所需程式的公开介面（IWAMAdmin）。当在独立的程序中执行Web应用程式时，IIS 5.0使用元件服务来协调对资源的同时存取，并且在COM元件之间传递环境资讯。
IIS 5.0使用元件服务的 ObjectContext 物件将对ASP内建物件的存取权授予被ASP呼叫的COM元件。例如，如果您想使用Visual Basic来建立需要存取由HTML档案中之表单所提交资讯的COM元件，那麽可以使用如下程式码：
Dim objObjectContext As ObjectContext
Dim vntIn As Variant
Set objObjectContext = GetObjectContext()
vnt In = objObjectContext.Item("Request").Form("Field1")
元件服务使用 ObjectContext 来维持关於特定COM元件例项的资讯。当IIS 5.0在ASP网页中编译指令档时，将呼叫元件服务来建立 ObjectContext 物件，以便追踪ASP网页中指令档的资讯。 ObjectContext 包括一个能唯一识别ASP网页中指令档例项的识别属性。例如，如果ASP网页中的指令档建立了已经登录在元件服务中的COM元件例项，那麽每个物件都将与ASP网页中指令档的ObjectContext联系。类似地，当使用 @Transaction指令在ASP网页中建立异动处理指令档时，元件服务便能得知并启动新的异动处理。从这时开始，元件服务协调它所控制之所有资源的更新。元件服务透过对留存资源所作变更的追踪来保证异动处理的完整性。
关於和管理应用程式的详细资讯，请参阅本章後面的〈定义应用程式的界限〉。
关於异动处理的更多资讯，请参阅本章後面的 〈异动处理〉 、第6章〈Active Server Pages〉中的 〈了解异动〉 和在Platform SDK中的〈Component Services〉。
IIS对请求的处理
当IIS 5.0接收到一个HTTP请求时，它会对此URL进行评估，以判定该请求要求的是静态内容（HTML）还是动态内容（ASP或者ISAPI）。
请求处理动作
| 请求 | 动作 |
|---|---|
| HTML网页 | IIS 5.0立即以HTML格式传回网页。 |
| ISAPI副档名 | IIS 5.0载入ISAPI DLL（如果还没有执行过的话），而请求将透过Extension_ Control_ Block资料结构发送到延伸中。 |
| 对应到特定ISAPI副档名的档案副档名 | IIS 5.0载入适当的DLL档案，并且透过 Extension_ Control_ Block 资料结构来提出请求。例如 .asp副档名将被对应到Asp. dll，以使所有带 .asp副档名的档案所作的请求都重新导向到Asp.dll上。 |
| CGI应用程式 | IIS 5.0将建立新程序。然後，提供被包括在整个环境请求和程序中之标准输入（STDIN）里的查询字串和其他参数。 |
设计决策
虽然对於开发Web应用程式有一个丰富的且不断扩充的工具集合，但是基本的开发周期与开发一般应用程式（Desktop）在很多方面都是类似的。本部分将集中介绍开发Web应用程式时，独特的设计决策。
定义应用程式的界限
基於ASP的应用程式是ASP网页和COM元件的集合。在定义应用程式时，您将使用Internet服务管理员嵌入式管理单元来委派应用程式在您网站上的起始目录。在您网站中之起始目录下的每个档案和资料夹都被认为是应用程式的一部分。因此，您可以用这个目录结构来构成用来定义应用程式作用领域的 应用程式界限 （application boundaries）。在每个Web网站中可以有多个应用程式，而且每个应用程式可以用不同的方式来设定。
开发Web应用程式所面临的最重要的工作是判定如何将许多的ASP网页组合成单一Web应用程式。IIS 5.0使用 名称空间 （namespace）的概念来识别应用程式。名称空间是将记忆体中的一块区域与容易识别的名称产生相关，它将一组档案识别为互相属於对方。IIS 5.0使用虚拟目录来定义应用程式的名称空间。下图解释了这个概念：
| 图7-4 应用程式的名称空间 |
应用程式界限内的指令档和ISAPI的副档名DLL形成了一个独立的单元，并且都是在单独的伺服器程序中执行。IIS 5.0管理员可以在与IIS 5.0相同的伺服器程序中，即程序集区（预设程序）中执行应用程式，也可以在独立的程序中执行应用程式以独自执行该应用程式，这在开发和测试时非常有用。
要学习更多关於独立应用程式和元件的知识，请参阅本章後面的〈将程序独立以简化开发〉部分。
除了在单独的程序中执行应用程式以外，无论是执行在独立程序或者在程式集区中，您都可以把元件从呼叫它们的 .asp档案中分离出来。在对您的元件进行除错时，将程序独立出来是非常好的配置方式。程序集区为伺服器提供了进阶保护，而无需花费维护大量独立程序的费用。为了在您元件本身的程序中执行这些元件，您必须建立新的应用程式，并且使用元件服务嵌入式管理单元将元件新增到应用程式中。
应用程式的五种可能设定为：
因为程序界限代表不同的记忆体区域，所以它们之间的呼叫需要由IIS 5.0 执行一些额外工作。跨越程序界限进行呼叫的机制被称为 封送处理 （marshaling）。封送处理的呼叫比在独立程序内的呼叫要慢一点。因此，在集区中以及独立应用程式的执行效率并不像执行在IIS程序集区的应用程式那样好。
将程序独立以简化开发
在IIS的早期版本中，所有的ISAPI应用程式（包括ASP）都会共用伺服器程序的资源与记忆体。尽管这样提供了快速的效能，但是不稳定的元件可能会导致伺服器当机，这对於像IIS这样执行重要任务的应用程式是一个不能接受的行为。更糟的是，除非重新启动伺服器，否则处於程序中的元件不能被卸除，这意味着修改现有的元件，将会影响共用相同伺服器的所有网站，不论是否是直接影响。
由於IIS 4.0版或更高版本的应用程式与元件服务间更紧密整合，因此可以在独立的程序中启动。这样做有两个原因：
说明
如果您决定了要在独立的程序中执行应用程式，或者与其他应用程式一起执行在某个程序集区中，那麽您必须从内容视窗中的 主目录 或者 虚拟目录 标签页上的 应用程式保护 下拉功能表中选择 高（独立的） 或 中（集区的）。 首先您应该为您的应用程式起始目录建立应用程式（如果还没有这样做的话）。要在新程序中执行的元件也必须安装到合适的COM应用程式中。若需详细资讯，请参阅元件服务的文件。
跨处理序应用程式的安全性考虑
预设情况下，跨处理序（Out-of-Process）应用程式和元件，包括ISAPI 延伸，都不能存取metabase中的属性。这个限制主要是出於安全性的考量，以阻止对Metabase进行未经授权的变更。如果想要让跨处理序应用程式存取 metabase，您必须进行下列操作：
控制应用程式流程
应用程式设计方式的主要选择之一就是执行模式。在设计较佳的应用程式中，使用模组处理单元将输入转换到输出的逻辑是很清楚的。COM结构和Active Server Pages（ASP）便能够满足模组设计的需要，以控制Windows DNA结构中的执行流程。本部分将简介一些在设计时控制Web应用程式流程中较为重要的且需要记住的内容。
应用程式控制技术
ASP提供了六种不同的方法来影响一般的执行流程。下图显示了这六种方法。图表中的箭头代表执行流程的方向。
重新导向
| 图7-5 |
重新导向是将请求转移到其他位置的程序。重新导向要求将向伺服器发送一个新的请求。但是，在一般情形下，应该将应用程式设计成只在用户端与伺服器之间产生最小的流量。许多过去由重新导向解决的设计问题现在都可以透过移转来实施，而且并不需要产生新的请求。关於应用程式设计的资讯，请参阅本章後面的〈协调用户端／伺服器的处理程序〉。
您可以使用 Response.Redirect 方法来实施重新导向。
移转
| 图7-6 |
将请求从一个ASP网页转移到另一个ASP网页的功能是在IIS 5.0中导入的。移转与重新导向相似，但是它不要求发送新的请求，因此能更加有效地控制应用程式流程。如果要将请求移转到应用程式界限外的ASP网页，边界将会暂时地延伸到含有外部ASP网页的范围。外部ASP网页将会表现得就像是包含在呼叫此ASP网页的应用程式所在界限内一样。因此，任何已经指派了套用范围的物件或者变数，在向其移转请求的ASP网页中仍然是存在的。移转除了比重新导向更加快速以外，还保留了所有来自於最初请求之ASP的内建物件，包括来自於HTTP表单张贴的数值。
您可以使用 Server.Transfer 方法来完成移转。
执行
| 图7-7 |
在ASP网页中，执行特定指令档，并且传回结果的功能是在IIS 5.0中导入的。执行这个功能类似於在大多数程式语言中使用的程序呼叫。如果您已开发了一个可以建置您想要合并之某个功能的ASP应用程式，但还没有在某个元件中建立此一功能，那麽使用这种应用程式流程的控制方法将非常合适。
您可以使用 Server. Execute 方法来完成执行的功能。
元件引入
| 图7-8 |
这可能是控制应用程式流程最常用的一种方法。COM程式模型已和 Windows DNA整合在一起的，并用来解决大多数的设计问题。Windows Script Components是IIS 5.0中支援的技术，它可让您更容易地将现有指令档转换为元件。
您可以使用 Server. CreateObject 方法来应用元件引入。关於指令档元件的详细资讯，请参阅本章後面的
〈Windows指令档元件〉 和第6章〈Active Server Pages〉中的 〈使用元件与物件〉 一节。
跳离
| 图7-9 |
在通常情况之下，您会希望ASP应用程式将网页中指令档中的每一行都执行完毕。但是有些情况下，您可能希望只要简单地终止回应就可以了。例如，如果侦测到（利用 Response.IsClient Connected 方法）用户端不再等待回应，那麽您可能会想终止ASP应用程式的执行。
您可以使用 Response.End 方法来实现跳离现有ASP应用程式的执行程序。
程序处理
| 图7-10 |
如果您想要在 .asp档案中定义副程式或者函数，可以利用适合於您所使用之指令档语言的程序语法来实施。例如VBScript定义了具有Sub ... End Sub 语法的副程式和具有Function ... End Function语法的函数。另一方面，Jscript则支援透过函数的程序处理。关於副程式处理的资讯，参阅第6章〈Active Server Pages〉中的 〈撰写程序〉 。
协调用户端／伺服器的处理程序
Web应用程式从本质上来说是分散式的。随着用户端处理能力的增加，也增加了您可以在用户端和伺服器之间指派处理工作的程度。透过将一些处理工作指派到用户端上，可以增强应用程式的回应能力，但是同时也会增加应用程式设计的复杂性。
在用户端与伺服器之间指派处理工作时，请记住两个设计目标。首先，需要让透过HTTP连线传送的流量最小。不管您所建立的连线有多快，在本机上处理总是最快的。您应该只在绝对必须的时候才在用户端和伺服器之间传递资讯。
第二个设计目标是只将伺服器资源提供给必须用此资源来完成处理工作的用户端。用户端的每个请求都应该经过完全的验证，以便伺服器不必回应用户端要求更多资讯的请求，避免增加透过HTTP连线进行传送的递回路径。例如，如果用户端进行请求时能向伺服器完全描述其功能，那麽伺服器可以立即发送符合该功能的回应，而不是向用户端要求进一步的资讯。这个设计概念也适用於支援资料库存取的Web应用程式设计。例如，如果用户端正检测指令的状态，那麽应该向用户端提供只描述特定指令的记录集合，而不是指令表格中的所有记录。
将资料快取
当用户端存取ASP网页时，主要有两种方法可以提供所需资讯：
从应用程式的外部资源中取得资料将要求更多的处理步骤，因此会比从应用程式内取得资料要求更多的时间进行处理。
如果欲发送到浏览器上的资料已经应前面的请求而事先准备好了，也已经把它们储存到了快取中，那麽应用程式便可以更快地检索资料。这种快取形式被称为是 汇出快取 （output cache）。当希望以相同的格式来为许多不同的请求传回相同格式的资料时，使用输出快取将特别合适。例如，一般发展输入表单的工作是收集现存的资料，好作为在下拉式清单方块中的选项。更好的方法是直接把项目写入HTML网页，因为对现存资料的更新将会自动反映到表单中。下面的指令档是输出快取的一个范例。在这个范例中，利用 get SportsListBox 函式以使用现存资料来建立清单方块，此清单方块被新增到应用程式之内，以便用户端可以更快地进行存取。此范例假定在伺服器上已经有定义好被称为「Sport」（Data Source Name, DSN）的资源。
<%@ LANGUAGE=JavaScript %><HTML><BODY>
<FORM METHOD=post>
What is your favorite sport? <%= getSportsListBox() %>
<P>
<INPUT TYPE=submit>
</FORM>
</BODY>
</HTML>
<%
function getSportsListBox()
{
SportsListBox = Application("SportsListBox")
If (SportsListBox != null) return SportsListBox;
crlf = String.fromCharCode(13, 10)
SportsListBox = "<select name=Sports>" crlf;
SQL = "SELECT SportName FROM Sports ORDER BY SportName";
cnnSports = Server.CreateObject("ADODB.Connection");
cnnSports.Open("Sports", " Web User", " Web Password");
rstSports = cnnSports.Execute(SQL);
fldSportName = rstSports("SportName");
While (!rstSports.EOF)
{ SportsListBox = SportsListBox " <option>" fldSportName "</
option>"
crlf; rstSports.MoveNext(); }
SportsListBox = SportsListBox "</select>"
Application("SportsListBox") = SportsListBox
return SportsListBox;
}
%>
在有些环境中，应用程式会接收到许多对相同资料的请求，但是需要为每个请求改变资料的表达形式。在这种情况下，可以使用 输入快取 （input cache），来储存资料而非表达资料。这可以利用VBScript所提供的 Dictionary 物件，或者是ADO记录集合进行资料快取来建置。
下面的范例利用新增不连线（connectionless）的记录集合到应用程式中来示范资料快取。然後，在应用程式空间中之ASP网页里的指令档就可以存取记录集合，而不是从资料库来取得资料。下面的两个ASP网页中的指令档，示范了这个技巧。
摘录於Global.asa档案：
<OBJECT ID=rsCustomers PROGID="ADODB.Recordset" RUNAT="Server"
SCOPE="Application">
</OBJECT><!N中继资料（METADATA） TYPE="TypeLib" FILE = "C:\Program
Files\Common Files\system\ado\msado15.dll"
-->
<% SQL = "SELECT CompanyName, City FROM Customers" Cnn = "DSN=AdvWorks"
rsCustomers.CursorLocation = adUseClient rsCustomers.Open SQL, Cnn,
adOpenStatic, AdLockReadOnly rsCustomers.ActiveConnection = Nothing
Set myCustomers = Application("rsCustomers").Clone Set CompanyName
=myCustomers("CompanyName") Set City = myCustomers("City")
Do Until myCustomers.EOF%><B><%= CompanyName %></B> is located in <B><%=
City %></B>.<P>
<%
myCustomers.MoveNext
Loop
%>
此应用程式的Global. asa档案建立了记录集合，并且把它新增到应用程式空间中。ASP网页中的指令档将移植此记录集合，并且利用将 ActiveConnection 属性设定为Nothing来使它设定为不连线。然後， ASP网页中的指令档将复制该记录集合，并且重覆利用这些数值，这样将比存取资料库本身要快得多。只有在知道将被用於移植之记录集合中的资料是相对稳定时，才适用这个技巧。
用户端的能力
应用程式将如何来掌握不同的用户端能力是您需要作出的最重要设计决策之一。例如，对於使用者来说，最重要的问题之一是连线的速度。如果应用程式可以判断这个速度，那麽它就可以调整回应来符合其能力。应用程式能察觉当前连线速度的唯一方法，是用户端是否将这个资讯封包包装成为请求的一部分，而一起传送。
您可以在用户端或者伺服器端解决用户端的能力问题。用户端的解决方案将依赖於使用Dynamic HTML（DHTML）把用户端目前设定的描述包装为请求的一部分，如下图所示。
| 图7-11 |
采用这种方法将有下列优点：
有些情况不能使用用户端指令档。例如，Internet上的应用程式不能保证用户端将会支援指令档，这就意味着对於有些用户端上之应用程式将无法使用。另外，从用户端可能无法存取伺服器端资源，因为用户端可能位於出於安全性的考量而不允许指令档执行的网路上。
伺服器端的方法依赖於Browser Capabilities元件。这个元件会读取User Agent HTTP标头，其中包括判断用户端能力的请求。附在IIS 3.0和4.0中的 Browser Capabilities元件则是透过查询静态清单来判断用户端效能。在下图中将显示事件的顺序：
| 图7-12 |
使用这种方法会使应用程式设计者在清单逾期时，遇到许多困难。更重要的是，这个技巧并不涵盖用户端能力中之可配置的状态面，而且没有提供在请求产生时，实际启用的方法。
在IIS 5.0中，Browser Capabilities元件已改进来克服这些早期设计的局限。现在它可以为单个的用户端请求进行修改，传回描述用户端效能的cookie。另外，如果对 .asp档案的最初请求不包括cookie，那麽将可以呼叫指令档，并在用户端上执行，从而建立cookie。在下图中显示了事件的顺序：
| 图7-13 |
对Browser Capabilities元件的改进为伺服器端解决方案提供了另一个方法。当收到不含cookie的请求时，此技术使用特殊的状态程式码回头来呼叫用户端。利用在.asp档案的第一行写入特殊的标签，您就可以产生状态程式码。例如：
<!-- 中继资料（METADATA） TYPE=Cookie"NAME= BrowsCap" SRC="Sendcook.htm"-->
您也可以指示IIS 5.0发送特殊的状态程式码，即HTTP 449状态程式码到 Internet Explorer 5中，然後告诉Internet Explorer 5执行Sendcook.Htm中的指令档，以产生描述用户端效能的cookie。当伺服器接收到cookie时，它将同时使用cookie和Browser Capabilities元件来决定如何将回应发送回用户端。
说明
如果中继资料（metadata）标签是存在於某个被用户端使用Server.Transfer或者Server.Execute方法进行移转所得结果的档案中（被移转或引入的档案），那麽IIS 5.0将忽略此标签。但是，实际上含有重新导向档案中的中继资料标签是会被正常处理的。
关於使用这个功能的详细资讯，请参阅《Microsoft Internet Information Services 5.0超级管理手册－网页开发篇》一书。
关於DHTML用户端能力的详细资讯，请参阅MSDN Online上的DHTML 参考资料，网址为
http://msdn.microsoft.com 。关於新一代Client Capabilities元件功能的范例，请参阅《Microsoft Internet Information Services 5.0超级管理手册－网页开发篇》一书。
对国际性用户端的支援
在Internet或者某个intranet上发布资讯的一个好处是可以建立国际性Web 站台，使用者便可以从不同的国家来进行存取。使用者可以要求使用自己的语言来进行区域化的网页，这样他们就能在地区性的浏览器版本中，阅读这些网页。
当建立包含不同语言网页的Web站台时，您可能需要转换在浏览器和Web 伺服器之间，或者在ASP网页中之指令档与COM元件之间传递的字串。如果 Web站台上的所有网页都是以Web伺服器使用的预设字元集编写的，那麽ASP 将自动进行转换。但是，如果要使用不同的字元集编写网页，就需要使用ASP 指令来指定如何转换字串。例如，如果网站的某些网页以某个日语字元集编写，而其他网页是以某个中文字元集来编写的，那麽就需要指定ASP指令档，在哪个特定网页中使用哪个字元集来处理字串。
ASP也提供了支援不同地方文化传统的指令，例如货币、时间和日期的格式。使用字串转换指令时，除非不能在Web伺服器中的预设地域使用指令档，才需要使用地域性指令档。若需详细资讯，请参阅本章後面的主题：
设定字串转换的字码页
字码页（Code Page）是作业系统用来将符号（字母、数位和标点符号）对应成字元编号的内部表格。不同的字码页提供了对不同国家使用的字元集的支援。字码页是以号码来参照的，例如，字码页932代表日语字元集，而字码页 950代表某个中国字元集。
Active Server Pages和它所支援的指令档引擎在内部使用的是Unicode字元集，这是一个16位元固定宽度的字元编码标准。如果您使用Web伺服器的预设字码页来完成所有的网页，那麽ASP将自动转换字串。但是，如果指令档并不是以Web伺服器预设字码页来建立时，您就必须指定字码页，以便字串在下列元件间进行传送时，可以正确被转换：
要在ASP网页中指定字码页，请使用 @ CODEPAGE指令。例如，为了将字码页设定为日文，请使用下面的指令：
<%@ CODEPAGE = 932 % >
当ASP处理到该网页上的内容和指令档时，它将使用您所设定的字码页将指令档字元集的字元转换到Unicode字元。例如，在ANSI中表示「a」字元的值，将被转换成不同的数值，而这个数值在Unicode中是用来表示「a」字元。
Active Server Pages假设在Web伺服器和浏览器之间，或者指令档和COM 元件之间传递的字串与指令档位於相同的字码页。如果需要指定不同的字码页，可以设定 Session.CodePage 属性来覆盖CODEPAGE设定。例如，您可能使用JIS字元集来制作了指令档，但是需要回应使用UTF-8（这是在标准日语字元集的两种不同字元编码方式）的用户端。
Session.CodePage 预设值为 @ CODEPAGE指令的值，设定此指令可以覆写当前的CODEPAGE设定。例如，要将字码页改变为某个中文字元集，您可使用下面的指令：
<% Session.CodePage = 950 % >
如果您要为指令档的某部分暂时改变字码页，那麽请确定将网页中的 Session.CodePage 设回为原始值。在下面的指令档中显示了如何暂时改变字码页：
<!-- Welcome to my home page in Japanese, code page 932 -->
<%
@CodePage = 932
Session("OriginalCodePage") = Session.CodePage
<!-- Look up name in Chinese, code page 950 --!>
Session.CodePage = 950
Sender = ReadMailHeader("Sender")
Found = FindFriend("Sender")
<!-- Restore the original code page --!>
Session.CodePage = Session("OriginalCodePage")
If Found == TRUE
ReplyWithPersonalizedForm()
Else
ReplyWithBusinessForm()
%>
设定地区识别码
地区 （Locate）是一个与使用者语言有关的使用者喜好资讯的集合，它将决定日期和时间是以何种格式来显示、项目如何按照字母顺序进行排序，以及如何进行字串的比较。 地区识别码 （LCID）是一个32 位元的值，定义了地区唯一项目。除非您为特定的指令档指定不同的地区识别码，否则ASP会使用Web伺服器中预设的地区识别码。
要为ASP网页设定地区识别码，您可使用 @ LCID指令。例如，为了将地区识别码设定为日文，您可以使用下面的地区识别码：
<%@ LCID = 1041 % >
@ LCID指令可告诉ASP，此指令档是在哪个地区授权的。如果需要改变指令档输入或输出的地区识别码，可使用Session.LCID属性。下面的范例显示了将地区识别码设定为British English，并且使用VBScript的FormatCurrency方法，将字元集中数值125所代表的符号作为货币符号。
<% Session.LCID = 2057 Dim curNumb cur Numb = FormatCurrency（125） Response.Write（cur Numb） %>
Session. LCID属性预设为 @ LCID指令中的设定。设定指令档中 Session.LCID的值可覆盖此预设设定。
关於LCID的详细资讯，请参阅Platform SDK的〈Windows Base Services〉里的〈International Features〉。
使用ASP存取资料
ASP提供Web开发者一个灵活易用，且可延伸的方法来与Internet或者是 Intranet应用程式的OLE DB资料库提供者（Provider）进行互动。使用ASP和 Microsoft Data Access Components（MDAC）不仅意味着您在开始时可以用 Microsoft Access来开发解决方案，然後再延伸到Microsoft SQL Server，而且还可以存取任何其他具有OLE DB提供者的资料库。使用元件服务的附加功能，您还可以建立支援基於Web的异动处理的多层次应用程式。
ADO概述
ActiveX Data Objects（ADO）为所有OLE DB资料来源提供了一个通用的程式模型；就本质而言，它是一个具有可用来与资料来源通讯之属性和方法物件的集合。ADO使用一般性的OLE DB提供者来存取特定资料来源的特定功能，包含原始的OLE DB提供者在内，也包括使用来对Open Database Connectivity （ODBC）驱动程式进行存取的特定OLE DB提供者。ADO是为了取代所有其他进阶资料存取方法的需要而设计的，它可以存取相关的、Indexed Sequential Access Method（ISAM）或者层次性的资料库，或者您只要具备有与ODBC相容的驱动程式，就可以存取任意资料来源类型。
ADO的简单易用、快速和较低的记忆体需求使它成为在伺服器端的理想指令档。实际上，ADO是广受建议的ASP应用程式资料存取技术。您可以直接从伺服器端指令档呼叫ADO或者从商业元件中进行呼叫。
与早期的资料存取方法不同，ADO不要求依照阶层层级来建立物件；要在不同环境中重新使用物件时，您可以独立建立大多数ADO物件，这提供了更大的灵活性并且降低了记忆体消耗。ADO也使用ODBC资料来源的ODBC 3.0 连线集区和OLE DB提供者的工作阶段集区，这消除了不断为每个使用者建立新 Connection物件的需求，而这些需求是非常消耗资源的。
但是，OLE DB却不能向用户端提供远端资料。一旦取得了资料，并且发送到浏览器後，使用者就不能在用户端应用程式中轻易的进行操作，或者对它进行改变。包括筛选和修改记录的资料操作都必须在伺服器上进行，因为实际对资料进行操作的物件寄存在那里。如果应用程式设计需要包含资料的用户端操作，那麽请参阅本章後面的〈使用远端资料服务连结远端资料〉。
OLE DB是Microsoft之Universal Data Access的基础，它提供了当程式存取资料时，使用标准方法之COM介面的集合。应用程式是否能使用ADO特性，有部分是取决於是否具有资料来源的OLE DB提供者。ADO被设计成与OLE DB 共同运作，而且在大多数场合中，ADO元件将透过OLE DB与资料库进行通讯；如果没有OLE DB提供者，您也可以使用ADO直接与ODBC驱动程式进行通讯。使用ADO透过OLE DB提供者进行通讯将会对下面描述的几个章节有影响：
关於ADO的详细资讯，请参阅Platform SDK中的ADO SDK文件。关於效能的资讯，请参阅本章後面的
〈资料存取效能〉 。
使用ADO的预存程序
预存程序 （stored procedure）是储存在相同名称下，并且作为一个单元来处理的预先编译集合，其中包括SQL叙述和选项流程控制叙述。用启用的连线集区建立储存过程可以显示出某些特殊的考虑。例如，为准备好的 SQL叙述建立临时储存过程是一个可由ODBC Data Source Administrator进行设定的选项。这个设定的预设值在SQL Server 2.65及3.5驱动程式中是启用的（On），这意味着当某个SQL叙述指令准备好时，就会建立并编译一个临时的预存程序。当某种ADO方法呼叫到准备好的指令时，就会执行临时储存程序，从而节省了解析和编译SQL叙述的花费。如果正确使用，这个功能可以改善应用程式的效能。如果某个SQL叙述要执行两次以上，或者它将执行一次以上而且含有参数，那麽就应该先准备好SQL叙述。您必须将第一次要执行并进行编译的SQL叙述准备好，而且，一旦中断到资料库的连线，这项准备就会遗失。
当启用连线集区时，您必须判断要在什麽时候删除暂时预存程序。当使用 SQL Server 2.65驱动程式时，储存程序将在连线中断时被释放。而使用SQL Server 3.5驱动程式时，您可以选择在中断时释放，或者在连线中的适当时间加以删除。
使用临时的预存程序和连线集区时，可能会出现储存问题。例如，如果使用的是预设设定，那麽就有可能会用完建立和储存临时预存程序的TempDB空间。当连线集区被启用时，将产生一个到资料库的连线，但是当用户端使用完毕并且中断此连线时，连线将返回到集区中。尽管它们不再与用户端联络，也不会再被呼叫，但是连线并没有被释放，也没有从TempDB中删除预存程序。
因此，当执行SQL Server 2.65驱动程式时，建议在连线集区被启用时，不要在准备时建立预存程序。而若使用SQL Server 3.5驱动程式，当启用连线集区时，应该停用建立临时预存程序的选项，或者把这个选项设定为「disconnect and as appropriate」。把选项设定成「disconnect and as appropriate」意味着当建立临时预存程序的OLE DB ICommand物件被释放时，ODBC SQL Server驱动程式将会中断连线。如果在用户端的程式码中使用了ADO，那麽预存程序将在 ADODB.Recordset和ICommand物件被关闭时，同时被释放。
为ADO选择用户端网路函式库
ADO是透过网路函式库来建置与资料库间的通讯。网路函式库的选择是由资料提供者和系统设定来决定的，而且对资料库存取速度具有显着的影响。例如，如果从Microsoft SQL Server存取资料，那麽存取速度通常比使用TCP/IP网路函式库要来得快。但是，如果SQL Server与IIS 5.0都在同一电脑上执行，那麽使用具名管道（Named Pipes）网路函式库就可能会改善效能。
您可以使用控制台中的Data Sources（ODBC）选项来为DSN设定网路函式库。一旦为某个连线设定了函式库，那麽将成为所有以後建立之连线以及应用程式可能使用到的DNS-less连线的预设函式库。
说明
如果要把网路函式库由Named Pipes改变为TCP/IP，那麽请确保没有把Named Pipes当作一个选项而加以删除，因为SQL Server Enterprise Manager依赖这个函式库。
使用远端资料服务连结远端资料
如果Web应用程式提供了用户端存取资料的能力，那麽您可以在具有远端资料服务（Remote Data Service，RDS）的用户端和伺服器之间指派资料处理的程序。用户端RDS元件将向Web伺服器发送查询，而伺服器端的RDS元件会处理这些请求，并且使用异动处理物件来把它们发送给资料库管理系统（Database Management System，DBMS）。DBMS会回应请求，把资料发送回 Web伺服器。接着Web伺服器上的RDS元件会把资料转换为ADO之 Recordset 物件。然後资料将被解析，以便传送给用户端。最後，在用户端上，资料显示在能察觉资料（data-aware）的控制项中，例如出现在文字方块或者组合方块里。
用来完成远端资料连结的两个主要物件是 RDS.DataControl 和 RDS.DataFactory 。首先，藉由在HTML网页中放入物件标签，以在用户端上建立 RDS.DataControl 物件的副本。例如：
<OBJECT
CLASSID="clsid:BD96C556-65A3-11D0-983A-00C04FC29E33"
ID="RDSDC1">
<PARAM NAME="SQL" VALUE="SELECT Author, ID FROM Authors">
<PARAM NAME="CONNECT" VALUE="DSN=Pubs;">
<PARAM NAME="SERVER" VALUE=http://Bookweb/>
</OBJECT>
前面的物件标签建立了 RDS.DataControl 物件的例项，并且为它设定了SQL、Connect和Server参数。如果将这个标签新增到HTML网页中，那麽就可以将资料控制项物件连结到HTML网页上的多个可察觉资料的控制项。例如，在下面的HTML网页中的标签显示了一个被连结到 RDS.DataControl 物件的HTML表格：
<TABLE id=Tasks DataSrc=#RDSDC1 WIDTH=100% BORDER=1 style="display:
none">
<THEAD ALIGN=left>
<TR>
<TH><em>ID</TH>
<TH><em>Author</TH>
</TR>
</THEAD>
<TR>
<TD><DIV DATAFLD=ID></DIV></TD>
<TD><DIV DATAFLD=Author></DIV></TD>
</TR>
</TABLE>
与 RDS.DataControl 物件进行通讯的伺服器端物件是 RDS.DataFactory 或者是商业元件。您可以先在用户端上建立 RDS.DataSpace 物件，然後使用 CreateObject 方法在伺服器上建立 DataFactory 物件的例项，从而起始 RDS.DataFactory 物件。下面的范例指令档解释了这个过程。
如果 RDS.DataFactory 物件不能满足您对资料存取的需求，那麽您可以建立自订的商业元件来与用户端通讯，或者可以直接使用在ASP网页之指令档的ADO来取得资料。在下面的范例中，自订的商业元件（Inventory）展示了称为 getQuantityonHand 的方法。 RDS.DataControl 物件在伺服器上建立了 Inventory 的例项，然後呼叫 getQuantityonHand 方法来取得记录。
<HTML>
<HEAD>
</HEAD>
<BODY>
<!-- RDS.DataControl -->
<OBJECT classid="clsid:BD96C556-65A3-11D0-983A-00C04FC29E33"
ID=ADC1><
OBJECT>
<!-- RDS.DataSpace -->
<OBJECT ID="ADS1" WIDTH=1 HEIGHT=1 CLASSID="CLSID:BD96C556-65A3-
11D0-983A
00C04FC29E36">
</OBJECT>
<SCRIPT LANGUAGE="VBScript">
Option Explicit
Sub GetRecords()
Dim objInventory, myRS
Set objInventory =
ADS1.CreateObject("Company.Inventory", _
"http://<%=Request.ServerVariables("SERVER_NAME")%>")
'Inventory exposes a method called
' getQuantityonHand that takes connection string and SQL parameters.
Set myRS = objInventory.getQuantityonHand _
("DSN=pubs;UID=sa;PWD=permission;","Select Quantity From Inventory")
' Assign the returned recordset to SourceRecordset.
ADC1.SourceRecordset = myRS
End Sub
</SCRIPT>
</BODY>
</HTML>
在Platform SDK中的IIS 5.0文件之〈Component Design Guidelines〉内所描述的相同问题将可套用到所有与 RDS.DataControl 通讯而建立之自订资料商业元件中。例如，您应该确保元件有支援Apartment或Both执行绪模式。
说明
Remote Data Service （RDS） 取代了Advanced Data Connector（ADC），而现在ADC已被视为过时的产品。至於ADC的远端功能（在用户端上操作和修改记录集合的能力）已经被整合到ADO中而当作是RDS的一部份了。
若需详细资讯，可参阅Platform SDK中的〈Remote Data Service〉。
异动处理
异动处理是一种应用程式开发的方法，这种方法把所有程序都分割成独立的工作单元，也就是异动（transaction）。 IIS 5.0和元件服务的整合使得建立支援异动处理的Web应用程式更加简单。如果要设计Web应用程式，那麽将会面对几个基本的设计决策。本部分简介了一些基本的设计问题和异动处理ASP的基础技术。
设计异动处理的Web应用程式
异动处理Web应用程式的一个最重要的概念，是区分商业程序和实际上的异动。商业程序是大多数公司的日常处理业务，例如处理销售订单。实际上的异动则与用於记录商业程序之资料来源的实际更新是相关的。一个商业程序通常由不止一个实际异动所组成。
例如，当处理销售订单时，您至少需要完成叁个不同的步骤：
根据不同的系统设计，每个步骤可代表一或多个实际异动。
Internet的非连线特性使得每个步骤被分成不同的实际异动。当实际异动开始後，所有其他使用者都不能更新参与异动的资源，直到异动结束後才可以进行变更。请想像一下，如果上面描述的全部销售订单程序都被分配到单独的实际异动中，将会发生什麽情况？使用者藉由指出对哪个产品有兴趣，便可以开始某个异动程序，这样将会锁定使用者的帐户并将此产品标记成为已不在存货资料库中。然後使用者可以让浏览器继续执行，同时参与其他商业行为，但是这都是在交付销售以前进行的。因为整个订单被当作一个实际异动来处理，所有的资源都被锁定，直到使用者交付或放弃订单。不过这样的设计对於出现在Web上的异动处理系统是不可行的。
对Web上的异动应用程式的设计要求，可能总是以商业程序的方式来表现。因此，建立一些将商业程序变成实际异动的设计技术是非常重要的。例如将实际异动限制到单独的 .asp档案中。
说明
商业程序可以横跨多个 .asp档案，但是实际异动却不能。
另一个设计技巧是用异动资源内的状态码来指明异动为未提交还是已经提交。藉由将状态码含在其中，就可以保留资源而不必实际将它提交。当商业程序完成时，藉由改变状态码，就可以开始其他的实际异动来提交所有悬而未决的资源。Crawford & Sons Custom Bicycle Company的案例研究，显示了这两个原则如何影响Web异动处理应用程式的建置。
Crawford & Sons公司之Web应用程式案例研究
Crawford & Sons Custom Bicycle Company是一家遍布北美的手工自行车制造商。员工们现在决定要透过Web应用程式来取得自行车的订单。他们使用Microsoft SQL Server来维护使用者和存货清单记录，并且也开发了用元件服务登录的资料和商业逻辑元件。现在，他们需要开发 .asp档案，以便让他们的使用者能存取独立商业程序范围内的这些元件。下图说明了组成Web应用程式的不同实际异动和 .asp档案。
| 图7-14 |
销售订单应用程式是由Login.asp、Credit.asp、Inventory.asp和Commit.Asp 这四个 .asp档案所组成的。注意每个实际异动都是由一个独立的 .asp档案来表示（每个 .asp档案都包含 @ Transaction = Required指令）。Login、Credit和 Inventory都与称为Sales Order的COM元件互动，它显示了完成取得订单的方法。
当用户端准备提交销售时（也就是当商业程序完成时），Commit.asp把全部逻辑异动组织到实际异动中，而此实际异动将把资料来源中的所有状态码由「搁置」变更为「完成」。这种设计满足了Web不连线的本质（connectionless nature）也满足了使用者对商业程序一致性的需求。
关於元件服务异动处理的详细资讯，请参阅第6章〈Active Server Pages〉中的
〈了解异动〉 和Platform SDK中的〈Component Service〉和〈Message Queuing〉。
异动处理技术
让Active Server Pages（ASP）参与异动处理的主要技术是元件服务，它向 IIS 5.0提供了异动服务以及寄存元件例项的环境。这个环境的优点是能为独立元件例项建立属性的能力。当IIS 5.0在编译ASP网页中的指令档时，就会建立一个新的IIS 5.0 Web Application Manager（IIS WAM）例项。
IIS WAM是一个Component Object Model（COM）元件，IIS 5.0用它来管理应用程式。如果指令档包含 @ TRANSACTION指令，那麽IIS WAM的例项将在具有适当异动属性的异动处理环境中声明。例如，如果在指令档中包括了 @ TRANSACTION = Required，那麽会告诉元件服务，它建立的IIS WAM例项应该在某个异动中执行。如果ASP网页中的指令档要建立已经使用元件服务登录之所有其他元件的例项，那麽元件服务将把它们使为是相同异动处理的一部分来看待。下图显示了ASP和IIS WAM之间的关系：
| 图7-15 |
元件服务透过两个不同的层级向IIS 5.0提供了异动处理服务。在最低阶，元件服务与Microsoft Distributed Transaction Coordinator（MS DTC）进行互动，以保证异动可满足可靠的异动处理系统的ACID属性（Atomic（原子，无法再被分割），Consistent（前後一致），Isolated（独立），Durable（耐用））。元件服务透过两种机制将元件例项连线到MS DTC：资源管理员（resource managers）和资源指派员（resource dispensers）。
资源管理员是管理持久性资料的系统服务。元件服务支援实作OLE Transactions协定，例如Microsoft SQL Server 6.5，或者X/ Open DTP XA标准的资源管理员。资源指派员和资源管理员类似，它们使用元件来共用状态资讯。但是，这个资讯并不是持久的。例如，资源指派员可以为使用标准开放资料库连线（ODBC）介面的元件来管理资料库的连线集区。ODBC 3.0 Driver Manager是 ODBC连线的资源指派员。有关元件服务异动处理的详细资讯，请参阅第6章〈Active Server Pages〉中的 〈了解异动〉 和Platform SDK中的〈Component Service〉和〈Message Queuing〉。
IIS应用程式的安全性议题
Web网站的安全对Web开发者来说是一个重要的问题。一个安全的系统必须要有仔细的计划，Web网站管理员和程式设计师也必须对能保证网站安全的选项非常了解。另外，他们也需要了解所有不同的安全性子系统是如何进行互动的。
本部份将提供关於ASP、元件和ISAPI开发者面临的安全性问题的概论。关於Web网站安全性的基本原则则已在第4章
〈安全管理〉 中有详细的讨论。
使用ASP来存取用户端凭证
您可以使用ASP来建立伺服器端的指令档，它能提取使用者其用户端凭证之内容并把此资讯储存在文字档中。透过将该指令档新增到SSL-secured的 Web网页中，就可以有效地编写目录和用於管理存取伺服器之使用者的用户端凭证。
若需详细资讯，请参阅《Microsoft Internet Information Services 5.0超级管理手册－网页开发篇》。
传递安全性内容
Windows为每个登入的使用者都建立了安全性内容（security context）。当 IIS 5.0接收到用户端的请求时，它将验证请求，然後扮演用户端。在扮演用户端时，IIS 5.0在被验证之用户端之安全性内容的范围内执行。在请求处理的不同阶段，依据用户端请求的本质，您可以改变安全性内容。下图显示了组成请求处理各部分的不同安全性内容。
| 图7-16 |
IIS 5.0程序的安全性内容称为是本机系统（LocalSystem）。但是，当IIS 5.0 处理用户端请求时，它将模仿产生该请求之用户端的内容。如果用户端是使用 Anonymous验证模式进行身份验证的，那麽对於程序内的应用程式，安全性内容将是IUSR_ machinename，对於执行在独立程序中的应用程式，安全性内容将是IWAM_ machinename。如果用户端是使用其他身份验证模式进行身份验证的，那麽安全性内容将对应到用户端的个人帐户中。
如果您使用ASP建立了COM元件的例项，COM元件将继承建立它之 .asp 档案的安全性内容。当IIS 5.0摧毁元件例项时，也会在大多数例项中使用 .asp 档案的安全性内容。但是，至少在下面这种情况下不会发生这样的情况。如果 COM元件已被授予工作阶段作用领域（也就是 Session ("mysesscomp"）= Server. CreateObject （"MyComps.comp1"），而且在元件摧毁以前工作阶段就逾时了，那麽IIS 5.0将会试图使用它自己的安全性内容（LocalSystem）来摧毁元件，而不是使用存取 .asp档案之用户端的环境。如果元件存取了它还没有发布的安全性资源，那麽会对整个系统产生某些副作用。
额外的安全性考虑
登录
许多IIS 5.0应用程式都需要使用其他软体元件所提供的资源。例如，ISAPI 延伸DLL可能必须由协力厂商呼叫自动化伺服器，或者CGI应用程式可能要启动由Microsoft Visual Basic建立的程式。这些元件把永久资讯储存在登录中，以便它们可以正确地执行。对於这些元件的标准桌面使用者而言，登录资讯是从使用者目前使用Windows登入之电脑上的设定档（profile）中读取的。当由IIS 5.0 启动时，这些应用程式经常会出现问题，因为IIS应用程式可使用的设定档是预设使用者的设定档。预设使用者的设定档中都是所有使用者的共同资讯，并没有特定属於某一个使用者，因此，当User 1在他的桌面上执行时，元件可能会按照预期执行，因为它是从登录中之User 1的设定档中来读取资讯的。而同一应用程式可能无法从IIS 5.0执行，因为它没有权限可存取User 1的设定档。甚至当IIS 5.0使用基本或者Windows整合身份验证来模拟User 1的帐户时，也是这种情况。
桌面
Windows NT 4.0和Windows 2000使用了在同一台电脑上能存有多个桌面的概念。桌面可以被视为是登入到电脑时所看到的画面，它会接收电脑使用者发出的所有滑鼠和键盘资讯，并且允许应用程式在一定的范围内与其他应用程式进行互动。例如，桌面上的一个应用程式可以发送资讯给桌面上的其他应用程式。 支援多个桌面意味着还可以执行其他的桌面，只是看不到它们，而且也不能向它们发送键盘资讯或者滑鼠资讯。这看起来仿佛是没有作用，但是实际上，许多作为Windows服务执行的应用程式都需要桌面提供的能力，除非不想与互动式使用者桌面进行互动。因此，每一个服务都具有自己的桌面，而不会被当前登入的使用者所干扰。
如果IIS应用程式以某种方法与桌面进行互动（例如如果它要显示讯息方块），那麽它将在桌面上显示讯息方块，但该桌面在电脑的显示器上是看不到的。类似地，IIS应用程式不能将资讯发送或者张贴到互动式桌面上的应用程式中。如果IIS应用程式需要与互动式桌面进行互动，就应该使用其他形式的程序间通讯，例如Named Pipes。如需更详细资讯，请参阅Platform SDK中之〈Windows Base Services〉里的〈Interprocess Communication〉。
ISAPI筛选器DLL
请不要将ISAPI筛选器DLL与ISAPI延伸DLL弄混。ISAPI筛选器DLL 执行在IIS 5.0服务的原始环境中。预设所有服务都执行在它们所安装电脑上的 Local System帐户下。Local System帐户拥有对本机电脑上几乎所有资源的存取权，除非被指定拒绝存取，但是它不能存取网路上其他电脑的资源。
开发技术
Microsoft Windows Distributed interNet Application（Windows DNA）结构是一个可用来建立Web应用程式的动态技术集合。Microsoft利用Windows 2000 在这个结构中新增了数个重要的特性。
元件服务
元件服务是在Windows 2000中新出现的，它提供了许多能让元件和Web 应用程式的开发变得更加容易的服务。这些服务将在後面章节中介绍。
伫列式元件
如果用户端与伺服器是在连线状态时，那麽伫列式元件（Queued Components）可让您建立能立即执行的元件。伫列式元件提供了一个进行非同步呼叫并且执行元件的简单方法。当用户端与伺服器没有在连线状态时，元件将保持在执行状态直到连线建立为止。透过使用类似於在元件开发中进行呼叫的方法，伫列式元件可提供给开发人员适当的帮助，而无须具备编排（marshaling）方面的知识。如需更加详细的资讯，请参阅Platform SDK中的〈Component Service〉和〈Queued Components〉。
元件服务事件
元件服务事件可以让出版商和订户松散地（lossely）连线到资料来源，这样您就可以分别来开发、设定和执行这些资源。出版商不需知道订户的数量和地区识别码，而订户藉由中介经纪人来寻找出版商并管理订单。藉由允许保留出版商和订户双方的身份识别，事件系统将可简化元件和Web应用程式的开发程序：您可以在不需要知道彼此存在的情形下，操作出版商和订户的身份识别。如需更详细的资讯，请参阅Platform SDK〈Component Service〉里的〈COM+ Events〉。
动态HTML
动态HTML（DHTML）是和Internet Explorer 4.0一起，由Microsoft同时导入的技术，它能让您在回应用户端事件时，提供更丰富的HTML。将HTML 网页升级成DHTML，这样不仅可以增强使用者在浏览时的感受，而且也建立了能更有效地使用伺服器资源的Web应用程式。藉由在文件物件模式（Docummnet Object Model，DOM）中设定属性，您可以使用DHTML来控制HTML网页的外观，其中DOM是Microsoft向World Wide Web Consortium（W3C）提议的一个模式。DHTML展示了一个能够动态地改变DOM属性的事件模式。下面的范例简单说明了如何使用 <DIV> 标签将HTML网页分割成不同区域，以及如何设定显示类型属性以便在使用者按一下输入按钮时，就显示各个区域。
说明
当您按下某个选择性按键时将会呼叫此副程式，并将 This is some hidden text. 这段隐藏的文字显示在Mydiv这个隐藏的区域中。
< SCRIPT LANGUAGE = "VBScript"> Sub showit（） 'This subroutine is called when the user clicks a select button. 'It displays text in the hidden DIV. document.all. MyDiv.style.display = "" End Sub </ SCRIPT > < DIV ID= "My Div" style= "display： 'none'" > This is some hidden text. </ DIV > < Select id= "Showit" onclick=showit>
关於DHTML的详细资讯，请参阅MSDN Online，网址为
http://msdn.microsoft.com 。
Windows指令档元件
Windows指令档元件（Windows Script Components）提供了一个建立 Component Object Model（COM）元件的简单方法，那就是使用如Microsoft Visual Basic Scripting Edition（VBScript）和其他与ECMA 262语言规范相容的语言（例如Microsoft JScript 2.0和JavaScript 1.1）等指令档语言。您可以在如IIS 、 Microsoft Windows Scripting Host（WSH）和其他支援COM元件的应用程式中使用指令档，当作是应用程式中的COM元件。指令档元件技术由以下内容组成：
指令档元件对於开发COM元件的原型而言，是非常好的技术。指令档元件与其他COM元件相似，如果希望让它们参与异动处理，或者想从元件服务执行时期的环境中获得好处，那麽您可以在元件服务中登录它们。因为它们是COM 元件，所以指令档元件可以存取ASP的内建物件。
关於指令档元件的详细资讯，请参阅MSDN Online，网址为
http://msdn.microsoft.com 。关於建立指令档元件的更多资讯，请参阅Platform SDK。关於指令档元件的特别范例，请参阅第6章〈Active Server Pages〉中的 〈使用元件与物件〉 和Platform SDK。
XML
Extensible Markup Language（XML）与HTML类似，能够以标签的形式将标记套用到文件上。但是，与HTML不同的是，XML被设计为成为通用的标记语言。换句话说，套用到XML文件中的标记不仅能像HTML那样可以传递、显示和格式资讯，还可以用来传递文件的语义或者组织结构。这种弹性使得XML 的功能非常强大，也有非常大的可用范围。
要了解Microsoft在XML方面的详细资讯，请参阅XML SDK，您可以从 MSDN Online中取得，网址为 http://msdn.microsoft.com/xml 。关於XML和相关标准的详细资讯，可参阅 World Wide Web Consortium，网址为 http://www.w3.org 。
Active Directory服务介面
Microsoft Active Directory服务介面（Active Directory Service Interfaces， ADSI）是一个基於COM的目录服务模式，它允许与ADSI相容的用户端应用程式存取包括Windows目录服务、Lightweight Directory Access Protocol（LDAP）和NDS等各种不同的目录协定，同时还使用了一个标准介面组。ADSI将用户端应用程式放置在基本的资料存放区或协定的应用和操作细节之外。
ADSI用户端应用程式可以使用一个称为ADSI提供者的应用程式。由提供者显示的资料被组织在由提供者定义的自订名称空间中。除了套用ADSI所定义的介面以外，提供者也可以套用ADSI架构，这个架构用来提供关於名称空间架构和ADSI提供者所提供之物件的中继资料（metadata）。
关於ADSI的详细资讯，请参阅Platform SDK中的〈Active Directory Service Interfaces Version 2.0 SDK〉和〈Active Directory Schema SDK〉。
ADSI和IIS
目前IIS 5.0将大多数Internet网站设定资讯储存在一个称为IIS metabase 的自订资料存放区（data store）单元中。IIS 5.0提供了一个允许应用程式对 metabase存取和操作的低阶DCOM介面。为了能让您轻易地存取metabase，IIS 5.0中也有ADSI提供者，在其中包含了DCOM介面所提供的大多数功能，因此任何与ADSI相容的用户端应用程式都可以使用此ADSI提供者。关於在IIS 5.0 中使用ADSI的详细资讯，请参阅第8章〈利用程式来管理IIS 〉中的 〈使用IIS Admin物件〉 。
可延伸的Web应用程式开发
开发Web应用程式时的两个主要目标是效能和可延伸性。
效能
在单一使用者桌面软体开发的领域中，效能需求已经被明确定义。在这个前提之下，当执行一般工作时，让使用者不会遭遇到明显延迟的状况是非常重要的。
在早期的World Wide Web，缓慢的Web网页是非常普遍的，因为对於许多使用者来说，长时间的等待是可以容忍的。但是，随着越来越多的企业Web 应用程式的建立，对Web应用程式效能的要求和对单一使用者桌面的效能也一样随之增加。今天，由於通讯技术的日益进展，使用者对网站效能的要求也大幅的提高。
可延伸性
设计Web应用程式的实际问题，是当应用程式被视为是传统的桌面应用程式那样出现在单一使用者面前时，它实际上是可以同时服务成千上百个使用者的分散式应用程式。
Web应用程式要求各种环境条件下的效能都能具备，换句话说，它们必须 是可延伸的。当然，Web应用程式必须执行得非常好，但是在单一使用者上的较佳效能并不一定能转换为可延伸的效能。
判断应用程式的可延伸性为何有许多不同的规则。理想情况下，真正可延伸的Web应用程式应该可以：
当然，这些可延伸性要求只是「理想」的情况。但是，您的应用程式越接近理想的要求，在有负载的情形下，应用程式就更能成功。
效能和可延伸性的设计考量
在开始进行Web应用程式开发专案时，必须记住的最重要的事情就是Web 应用程式在很大程度上是伺服器上的应用程式。过去，伺服器软体在复杂性和程式难度上仅次於作业系统核心。IIS 5.0和Windows提供了许多新工具，使得Web 应用程式的开发变得更加快速和简单，但是伺服器软体程式的开发问题和挑战仍然存在。
使应用程式具有可延伸性的一些重要考量包括：
分析这些主题已超过了本章的范围。但是，在本章节中有一个针对IIS的说明和程序的汇整，它会帮助您建立可延伸的Web应用程式。
关於设计Web应用程式的详细资讯，请参阅本章前面的 〈设计决策〉 。
开发可延伸的ASP应用程式
利用ASP，您可以轻易且快速地建立Web应用程式，然後花费一小部分时间来使用例如C或者C++ 等较为传统的伺服器端语言。
但是，建立基於ASP的应用程式所需的伺服器处理和用户端与伺服器之间的互动是很复杂的，并且用大量的ASP指令档建立的Web应用程式也有可能没有良好的可延伸性。
适当的使用ASP
为避免可延伸性问题，在开发ASP时要记住下面两点：
第一点强调了ASP应与HTML、使用DHTML的用户端指令档，以及XML 相吻合，以便建立一个功能强大且与使用者互动的平台。ASP指令档被设计为用来将使用者介面与Web应用程式的商业逻辑相连结，并且为完成这些工作，本身也已经最佳化了。
第二点应该作为一个重要的提示：如果您发现大多数商业逻辑都嵌入到了 ASP中，那麽您的应用程式也许不能正确地进行延伸。ASP内的ActiveX指令档语言能建置大量的商业逻辑处理，这一点是确定的。然而，如果您的Web应用程式所需的商业逻辑比较重要，那麽此商业逻辑应放入到COM元件中，而不是将其嵌入到ASP网页的指令档中。
将IIS上的ASP最佳化
一旦您确定在应用程式中使用ASP的设计是适当的，并且已经把大量商业逻辑封装到COM元件中，那麽就有两种办法可以来进一步提高此Web应用程式的效能和可延伸性：
关於设计Web应用程式的详情，请参阅本章前面的 〈设计决策〉 。
将ASP指令档最佳化
您应该小心地进行程式码的最佳化。在ASP指令档中，与在任何其他的程式语言中一样，请先确定应用程式的哪个部分消耗最多的时间和资源。之後，再利用此资讯来解决在最佳化工作中出现的重要问题。
以下几个技巧，也许会对您ASP网页中指令档的效能问题有所帮助：
IIS设定的最佳化
IIS 5.0提供了多种配置设定，调节这些设定可以微调Web应用程式的效能和可延伸性。这些设定包括 ：
在《Microsoft Internet Information Services 5.0超级管理手册－网页开发篇》中将提供各属性的参考资料，包含可以增进效能的技巧。
开发可延伸的元件
因为大多数的商业逻辑都包装到COM元件中，所以元件除了必须易於延伸之外，还应该设计为具有高效能。
以下是建立可延伸元件的一些建议：
设计高效能的ISAPI应用程式
ISAPI是Web应用程式效能最高的介面。如果您建立了某个ISAPI延伸或者筛选器，那麽很有可能它的效能会超越在ASP网页中的指令档或者执行相似工作的元件。
然而，ISAPI的速度表现并不意味着可以忽视效能和可延伸性方面的考量。实际上，ISAPI不能使用ASP和COM所提供的大多数应用程式支援服务。例如，如果想要ISAPI应用程式保持工作阶段状态，那麽必须由您亲自实作大多数工作阶段功能。
以下是有关改进ISAPI延伸的可延伸性和执行状况的一些建议：
关於ISAPI延伸和筛选器的详细资讯，请参阅Platform SDK中的ISAPI 文件。
资料存取效能
对Web应用程式开发者而言，存取资料和资料取得，通常是最富挑战性的领域。
许多关於资料存取的可延伸性和效能方面的问题并不在Web应用程式开发者的控制范围内。但是，您可以使用某些技术来获得最好的效能：
关於资料存取的详细资讯，请参阅第6章〈Active Server Pages〉中的 〈存取资料来源〉 及本章前面的 〈使用ASP存取资料〉 。
测试效能和可延伸性
对於任何Web应用程式开发专案而言，都必须仔细的进行规划和开发。但是，为了开发真正可延伸的Web应用程式，您应该针对可延伸性的问题来严格而定期地测试应用程式。您应该记住，几乎所有Web应用程式在开发期间都会遇到一些不可预知的可延伸性问题。发现并解决这些问题的唯一方法，就是认真的、全面的进行测试。总之，最有用的可延伸性和效能测试就是采用与真实环境所会面临的压力相似的方法来进行。
Web Application Stress Tool 是一个Web工具，它被设计来模仿多个浏览器向一个Web应用程式请求网页的情形。它可以使用在不同的 Internet服务中，并可自订负载，且能提供丰富的功能集合，这对於为特定Web 网站收集效能资料的人来说是非常理想的。
在Windows 2000 Resource Kit所附的光碟上便可以取得 Web Application Stress Tool 。