整合安全角色的系统和方法

摘要

本发明给出整合安全角色的系统和方法。上游应用程序包括与上游安全角色和下游安全角色对应的一个或多个角色映射要求。通过将上游安全角色标识符加入下游应用程序的角色映射表中或通过将上游用户到角色映射加入下游应用程序的角色映射表中扩展上游安全角色。当上游安全角色得到扩展时，指定给上游安全角色的用户自动访问经角色映射的下游应用程序。

说明书

技术领域

本发明一般涉及跨越应用程序边界整合安全角色的系统和方法。更具体地说，本发明涉及通过将上游安全角色映射到下游安全角色，来扩展安全角色的系统和方法。

背景技术

计算机系统将各种技术用于用户验证。当计算机系统接收到来自用户的请求时，计算机系统通常验证和核准用户。例如，用户可以访问他的银行帐户信息和银行管理应用程序履行一系列步骤(譬如，向用户请求用户标识符和密码)以验证和核准用户。计算机系统还可以请求核准访问下游应用程序。利用如上所述的例子，银行管理应用程序(即，上游应用程序)可以调用下游应用程序来检索与用户请求相对应的帐户信息，从而，下游应用程序需要用户标识信息以同意访问。

Java 2 Enterprise Edition(J2EE)包括用于用户请求核准的基于安全角色访问控制机制。安全角色可以被看作是一组Enterprise Java Bean(EJB)方法许可，以及对URL(统一资源定位符)网页的读/写访问许可。EJB豆(bean)和URL网页被包装在一起变成J2EE应用程序，以便构建解决商业问题的功能集。系统管理者可以将个别的用户标识符以及组标识符映射到每个安全角色，以便将访问商业功能的所需许可提供给每个用户和组。

但是，将用户映射到应用程序遇到的难题是，不同的开发商或销售商创建整合到较大商业应用程序中的分立J2EE应用程序。安全角色通常定义在应用程序的边界内，应用程序的边界又使商业应用程序以模块方式开发。例如，商业操作可以被划分成一组组件和不同组可以独立开发这些组件。开发特定模块的组可能意识不到需要从其它模块申请访问的用户。

此外，在用于下游应用程序的模块化系统中，人工管理用户到角色映射遇到的难题是变得既非微不足道又复杂。例如，工作流用户请求可能由大量J2EE应用程序来管理。当发现这种情况时，用户的身份被映射到与每个应用程序相对应的安全角色，以便向用户提供访问。

因此，所需的是使上游应用程序的安全角色自动映射到下游应用程序的所需安全角色，和相反，使下游应用程序安全角色自动映射到上游应用程序安全角色的系统和方法。此外，所需的是更有效地向用户提供跨越应用程序边界的访问的系统和方法。

发明内容

因此，根据第一方面，本发明提供了在第一下游应用程序上核准客户请求的方法，所述方法包括：在第一下游应用程序上接收来自上游应用程序的第一应用程序请求，其中，第一应用程序请求是从客户请求中导出的，并且包括由上游应用程序确定的上游安全角色标识符；读取存储在可从下游应用程序访问的下游核准表中的核准表项；将包括在请求中的上游安全角色标识符与包括在下游核准表中的核准表项的至少一个匹配；并响应匹配以核准客户请求。

根据第二方面，本发明提供了包括如下组件的信息管理系统：一个或多个处理器；可由处理器访问的存储器；可由处理器访问的一个或多个非易失性存储设备；和在第一下游应用程序上核准客户请求的客户核准工具，该客户核准工具包括：在第一下游应用程序上接收来自上游应用程序的第一应用程序请求的装置，其中，第一应用程序请求是从客户请求中导出的，并且包括由上游应用程序确定的上游安全角色标识符；读取存储在可从下游应用程序访问的下游核准表中的核准表项的装置，下游核准表位于非易失性存储设备之一中；将包括在请求中的上游安全角色标识符与包括在下游核准表中的核准表项的至少一个匹配的装置；并响应匹配以核准客户请求的装置。

根据第三方面，本发明提供了用于在第一下游应用程序上核准客户请求的存储在计算机可操作媒体上的计算机程序产品，所述计算机程序产品包括实现根据第一方面的方法的装置。

最好，标识一个或多个所需下游安全角色，其中，每个核准表项对应所需下游安全角色的至少一个。可选地，选择与匹配核准表项对应的所需下游安全角色和使它包括在发送到第二下游应用程序的第二应用程序请求中。

可替代地，在接收第一应用程序请求之前，生成匹配核准表项。为了生成匹配核准表，接收包括上游安全角色和下游安全角色的角色映射要求，上游安全角色对应于上游安全角色标识符，然后，使上游安全角色标识符包括在匹配核准表项中，匹配核准表项对应于下游安全角色。

可选地，确定上游安全角色和下游安全角色是否等效，并且，配置上游安全角色和下游安全角色，以便使它们等效。

最好，在计算机网络上接收第一应用程序请求。

根据第四方面，本发明提供了扩展上游安全角色以包括下游应用程序的方法，所述方法包括：接收与上游应用程序和上游安全角色对应的安全角色映射请求；选择与安全角色映射请求和下游应用程序对应的下游安全角色；和将一个或多个下游核准表项加入下游安全角色中，其中，核准表项对应于上游安全角色。

最好，从由用户标识符、组标识符和上游安全角色标识符组成的组中选择至少一个核准表项。

最好，确定上游安全角色和下游安全角色是否等效，并且，配置下游核准表项和一个或多个上游核准表项，以便使它们等效，上游核准表项对应于上游安全角色。

可选地，从上游应用程序接收包括用户标识符的应用程序请求。在这种情况下，将用户标识符与下游核准表项的一个或多个匹配，和响应匹配以核准应用程序请求。

附图说明

现在参照像例示在附图中那样的本发明优选实施例，仅以举例的方式对本发明加以描述，在附图中：

图1是示出上游应用程序将包括上游安全角色的应用程序请求发送到下游应用程序的图形；

图2是示出上游应用程序将请求发送到下游应用程序的图形，其中，下游应用程序的相应核准表包括一个或多个上游主题；

图3A是示出在角色到角色映射过程中使上游安全角色标识符包括在下游核准表项中的图形；

图3B是示出在角色到角色映射过程中通过将上游安全角色用户到角色映射加入下游安全角色中使上游安全角色映射到下游安全角色的图形；

图4是示出在应用程序生命周期内的各个阶段准备代码和更新安全角色所采取的步骤的高级流程图；

图5是示出分析上游应用程序和将上游安全角色角色映射到下游安全角色所采取的步骤的流程图；

图6是示出将上游安全角色角色映射到下游安全角色所采取的步骤的流程图；

图7是示出下游应用程序具有上游安全角色指定的用户时所采取的步骤的流程图；和

图8是能够实现本发明的信息管理系统的方块图。

用在不同附图中的相同标号表示相似或相同的项。

具体实施方式

下文旨在提供本发明的例子的详细描述，不应该被认为是对本发明本身的限制。而且，各种改变都将落在所附权利要求书限定的本发明的范围之内。

图1是示出上游应用程序120将包括上游安全角色137的应用程序请求130发送到下游应用程序140的图形。与上游安全角色相对应的上游安全角色标识符已经角色映射(role-map)了下游应用程序的相应下游核准表170。图1中的例子示出了下游核准表170包括下游核准表项190中的上游安全角色标识符(对于有关角色映射加入的进一步细节，请参见图3A、4、5、6和相应文本)。

客户100通过诸如因特网之类的计算机网络110将请求115发送到服务器115。例如，客户100可能想检查利用服务器115访问的银行帐户结余。请求105包括服务器115用于验证和核准客户100的用户数据107。例如，用户数据107可以包括用户标识符、密码、数字证书、或用于验证和核准客户100的其它信息。

服务器115包括与客户请求对接的上游应用程序120。利用如上所述的例子，上游应用程序120可以是允许用户检查银行帐户结余、存款金额和取款金额的联机银行管理应用程序。上游应用程序120包括万维网模块122和EJB(Enterprise Java Bean)模块125。万维网模块122将用户界面提供给客户100(例如，网页)，并且还利用包括在请求105中的客户100的验证数据(例如，数字证书)验证客户100。一旦万维网模块122验证了客户100，万维网模块122就调用EJB模块125，以便进一步处理请求105。

Enterprise Java Bean(EJB)模块根据用户所指定的安全角色核准用户的请求。利用如上所述的例子，如果将“CheckBalance”角色指定给客户100，EJB模块125核准客户100检查银行帐户结余。在如图1所示的例子中，如果将存储在数据存储体150中的适当上游安全角色160指定给客户100，EJB模块125就同意用户核准。EJB模块125在用户核准步骤中访问位于核准表存储体(store)150中的上游核准表155。上游核准表155包括上游安全角色160和相应上游核准表项162、165和167。上游核准表项162和165包括作为用户标识符的项，而上游核准表项167包括作为组标识符的项。核准表存储体150可以存储在诸如计算机硬盘之类的非易失性存储区上。

EJB模块125通过将包括在用户数据107中的客户100的用户标识符与上游核准表项162、165和167比较，确定是否同意访问客户100。

一旦EJB模块125同意访问客户100，EJB模块125就确定应该调用下游应用程序140来管理请求。利用如上所述的例子，联机银行管理应用程序确定应该调用命名空间管理应用程序，以便从命名空间中查找用户帐户信息。EJB模块125将请求130发送到下游应用程序140。请求130包括用户标识符135和角色137。用户标识符135标识客户100，而角色137包括与诸如上游安全角色160之类的客户100的上游安全角色相对应的标识符。

在一个实施例中，下游应用程序140可以位于单独服务器上，而角色137包括在在诸如LAN(局域网)或因特网之类的计算机网络上发送到寄存下游应用程序的服务器的安全上下文(security context)中。

下游应用程序140包括接收和分析请求130的EJB模块145。EJB模块145确定客户100要求特定安全角色指定，以便使EJB模块145同意访问。利用如上所述的例子，如果将下游安全角色175指定给请求者，EJB模块145同意访问，以从命名空间中查找用户的银行帐户信息。EJB模块145访问包括下游安全角色175的下游核准表170。EJB模块145将用户标识符135和角色137与下游核准表项180、185和190相比较。下游核准表项180和185包括作为用户标识符的下游主题，而下游核准表项190包括与上游安全角色160相对应的上游安全角色标识符。EJB模块145确定包括在角色137中的上游安全角色与包括在下游核准表项190中的上游安全角色标识符匹配，并同意访问客户100。

在一个实施例中，代替将上游安全角色标识符加入下游核准表中，计算机系统可以将与特定上游安全角色相联系的上游主题映射到下游核准表(对于有关到下游安全角色的上游用户到角色映射的进一步细节，请参见图2、3B和相应文本)。

图2是示出上游应用程序将请求发送到下游应用程序的图形，其中，下游应用程序的相应核准表包括与上游应用程序对应的一个或多个核准表项。除了图2的下游核准表270被用户到角色映射到上游安全角色(260)，而图1的下游核准表170是利用上游安全角色标识符角色映射的之外，图2与图1相同。具体地说，下游核准表270包括在用户到角色映射过程中加入下游核准表270中的核准表项290、295和299(对于有关用户到角色映射的进一步细节，请参见图3B和相应文本)。

由于下游核准表270被用户到角色映射到上游安全角色260，请求230不包括客户200的所指定的上游安全角色，而图1的请求130包括客户200的所指定的上游安全角色(例如，角色137)。

图3A是示出在角色到角色映射过程中使上游安全角色标识符包括在下游核准表项中的图形。上游核准表300包括要求角色映射到下游安全角色330的上游安全角色305。翻译角色到角色映射的一种途径是，通过将上游安全角色角色映射到下游安全角色，使下游安全角色的许可包括在上游安全角色中。例如，如果用户被指定了上游安全角色，那么就自动同意用户访问已经角色映射到上游安全角色的下游安全角色。

服务器在角色到角色映射过程中访问包括安全角色305和安全角色315的上游核准表300。核准表项310包括与安全角色305相对应的项，而核准表项320包括与安全角色315相对应的项。

服务器在角色到角色映射过程中访问下游核准表325和选择要映射到下游安全角色330的上游安全角色305。下游安全角色330包括核准表项335和340。服务器将核准表项345加入下游安全角色330中，以便将上游安全角色305“角色映射”到下游安全角色330。下游核准表项345包括与上游安全角色305相对应的上游安全角色标识符。下游安全角色330现在被配置成下游应用程序同意访问指定了下游安全角色305的用户(对于有关下游应用程序访问同意步骤的进一步细节，请参见图1、7和相应文本)。

图3B是示出在角色到角色映射过程中通过将上游安全角色用户到角色映射(即，用户标识符和组标识符)加入下游安全角色中使上游安全角色355映射到下游安全角色375的图形。

服务器在角色到角色映射过程中访问包括安全角色355和安全角色365的上游核准表350。核准表项360包括与安全角色355相对应的一组用户到角色映射。用户到角色映射表中的每个项包括已经指定给上游安全角色355的用户、组、或安全角色标识符。服务器访问下游核准表370和选择上游安全角色375，以便角色映射上游安全角色355。

下游安全角色375包括核准表项385和390。核准表项395包括来源于上游安全角色355到下游安全角色375的用户到角色映射的新项。下游安全角色375现在被配置成相应下游应用程序同意核准指定了上游安全角色355的用户(对于有关下游应用程序核准的进一步细节，请参见图2、7和相应文本)。

图4是示出在应用程序生命周期内的各个阶段准备代码和更新安全角色所采取的步骤的高级流程图。应用程序的生命周期包括应用程序开发阶段(例如，设计和编码)、汇编阶段(例如，包化和定义策略和引用)、部署阶段(例如，安装和填入绑定信息)和运行期阶段(即，执行)。如上所述的阶段是J2EE术语，正如本领域的普通技术人员所知，其它软件开发系统也可以用于实现本发明。

应用程序开发者明白，他的应用程序(即，上游应用程序)要求从来自其它应用程序(即，下游应用程序)的访问服务。因此，应用程序开发者定义对他的上游应用程序要求访问的下游应用程序的安全角色引用(步骤400)。应用程序开发者将security-role-reference扩展名加入他定义符号角色名的代码中，符号角色名可以用于引用下游应用程序中的安全角色。

由于在上游应用程序汇编期间，实际安全角色名可能未知，security-role-reference元素提供了上游安全角色应该被映射到下游安全角色的指示。实际下游安全角色名可以在上游应用程序的部署阶段解决(对于进一步的细节，请参见下文)。“security-role-reference”可以被定义成J2EE部署描述符中的扩展名。可以将“security-role-reference”加入EJB模块和万维网模块中，并且，定义如下：

<！ELEMENT security-role-ref(description？，security-role-ref-name)>

该元素可以包括描述下游应用程序的可选项“description”，以便在绑定过程中向应用程序开发者提供角色到角色映射指导(对于有关绑定过程的进一步细节，请参见下文)。

应用程序开发者可以将另一个扩展名加入J2EE部署描述符中以允许下游安全角色和security-role-reference之间的绑定。例如，应用程序通过小区名和它的应用程序名唯一地标识。小区包括许多应用程序服务器，它是制定安全策略的基本单元。安全角色通过像如下那样的三元组唯一地标识：

(cell name，application name，security role name)

当安装新应用程序时，部署者通过像如下那样，将元素加入J2EE部署描述符的绑定扩展名中，解决security-role-reference问题：

<！ELEMENT security-role-binding(security-role-ref-name，unique-role-name)>

上面的语句将唯一角色名(unique-role-name)(三元组)与汇编器定义的security-role-reference名绑定在一起(步骤450)。将用户和用户组指定给安全角色的访问控制安全策略可以通过如下元素来定义：

<！ELEMENT authorization(security-role-name，subject^*)>

security-role-name代表为下游应用程序定义的安全角色。subject可以是唯一用户标识符、组标识符、特殊主题或security-role-reference名。当被指定时，security-role-reference名意味着下游应用程序的安全角色被指定给应用程序。

核准表附在应用程序边界上，并且包括一个或多个核准元素，每个安全角色一个核准元素。依赖于管理者的偏好，服务器在运行时实现两种途径之一(步骤490，对于有关角色到角色映射的进一步细节，请参见图5和相应文本)。第一种途径是保持security-role-reference名指定并要求用户安全上下文包括安全角色属性(对于有关包括在安全上下文中的安全角色属性的进一步细节，请参见图1、3A和相应文本)。第二种途径是根据下游服务器的核准策略，将security-role-reference名扩展到用户、组和特殊主题(对于有关主题加入的进一步细节，请参见图2、3B和相应文本)。

在第一种途径中，当核准指定用户时，服务器通过预定应用程序查找赋予那个用户的安全角色。当将下游调用发送给下游应用程序时，将安全角色属性加入用户的安全证件中，传送给下游应用程序或服务器。下游应用程序赋予用户的新安全角色也被加入用户的安全证件中。

在第二种途径中，在运行时用上游应用程序的核准策略(即，用户、组、特殊主题指定)取代处在下游应用程序核准表中的下游应用程序角色名。上游应用程序中的security-role-binding表示，每当修改上游应用程序的用户到角色绑定时，安全运行期应该更新下游应用程序的核准表。

为了避免循环相关性，实现安全角色的等效性。如果将安全角色指定给另一个安全角色，或反过来，那么，两个安全角色被标识为等效的。一旦两个安全角色被标识为等效角色，处理保证两个相应核准表是相同的。角色等效性也可以应用于以循环方式相互指定的三个或更多个安全角色。例如，将角色1指定给角色2，将角色2指定给角色3，并将角色3指定给角色1。在本例中，所有三个角色被标识为等效角色。

图5是示出分析上游应用程序和将上游安全角色角色映射到下游安全角色所采取的步骤的流程图。处理从步骤500开始，在那里，处理分析位于上游应用程序存储体515中的下游应用程序，以识别下游应用程序和一个或多个下游应用程序之间的角色映射要求(步骤510)。例如，联机银行管理应用程序使用户可以检查银行帐户结余、存款金额和取款金额。在本例中，在联机银行管理应用程序中定义了三种安全角色，它们是CheckBalance角色、DepositFund角色和WithdrawFund角色。在本例中，联机银行管理应用程序(即，上游应用程序)在执行用户请求的同时，调用命名空间管理应用程序(即，下游应用程序)。在本例中，命名空间管理应用程序包括四种安全角色，它们是CosNamingRead、CosNamingWrite、CosNamingCreate和Cos-Naming-Delete，为了使用户执行要求联机银行管理应用程序中的Check-Balance角色的结余检查操作，还要求用户已经读取访问了要求命名空间管理应用程序中的CosNamingRole角色的命名空间。上游应用程序存储体515可以存储在诸如计算机硬盘之类的非易失性存储区上。

对上游应用程序是否包括角色映射要求作出确定(判决520)。处理通过分析包括在上游应用程序中的扩展名识别角色映射要求(对于有关安全角色扩展名的进一步细节，请参见图4和相应文本)。

如果上游应用程序不包括角色映射要求，判决520转移到“否”分支522，在那里，服务器在步骤530中装载上游应用程序，并且处理在步骤535中结束。另一方面，如果上游应用程序包括角色映射要求，判决520转移到“是”分支528，在那里，处理选择包括在上游应用程序中的第一角色映射要求(步骤540)。角色映射要求标识要映射到下游安全角色的上游安全角色。

上游安全角色包括存储在上游核准表存储体555之类的上游核准表中的上游主题(即用户标识符、组标识符等)。下游安全角色包括存储在下游核准表存储体560之类的下游核准表中的下游主题。上游核准表存储体555和下游核准表存储体560可以存储在诸如计算机硬盘之类的非易失性存储区上。

处理以两种方式之一将上游安全角色角色映射到下游安全角色。第一种途径是保持security-role-reference名指定，并要求用户安全上下文(即，请求)包括上游安全角色标识符(对于有关安全角色标识符传送的进一步细节，请参见图1、3A和相应文本)。第二种途径是根据下游服务器的核准策略，将security-role-reference名扩展到用户、组和特殊主题(预定处理方块550，对于有关角色映射加入的进一步细节，请参见图6和相应文本)。

对上游应用程序是否包括多个角色映射要求作出确定(判决570)。上游应用程序可以包括与单个下游应用程序相对应的多个角色映射要求或上游应用程序可以包括与多个下游应用程序相对应的多个角色映射要求。如果上游应用程序包括多个角色映射要求，判决570转移到“是”分支572，分支572循环回到选择(步骤580)并处理下一个角色映射要求。这个循环继续下去，直到上游应用程序再也没有角色映射要求要处理为止，此刻，判决570转移到“否”分支578，在那里，处理在步骤590中结束。

图6是示出将上游安全角色角色映射到下游安全角色所采取的步骤的流程图。处理从步骤600开始，在那里，处理选择上游核准表和识别位于上游核准表存储体615中的上游安全角色(步骤610)。所选下游安全角色对应于包括在上游应用程序中的角色映射要求。上游核准表存储体615可以存储在诸如计算机硬盘之类的非易失性存储区上。处理选择位于下游核准表存储体625中的下游核准表(步骤620)，下游核准表存储体625包括与角色映射要求相对应的下游安全角色。下游核准表存储体625可以存储在诸如计算机硬盘之类的非易失性存储区上。

对处理被配置成通过使上游安全角色标识符包括在下游核准表中还是使下游安全角色用户到角色映射包括在下游核准表中将上游安全角色角色映射到下游安全角色作出确定(判决630)(对于有关角色映射选项的进一步细节，请参见图3A、3B、4和相应文本)。如果处理被配置成使上游安全角色标识符包括在下游核准表中，则判决630转移到“是”分支638，在那里处理在步骤670中使上游安全角色标识符包括在下游核准表中，并且处理在步骤680中返回(对于有关上游安全角色标识符的进一步细节，请参见图3A和相应文本)。

另一方面，如果处理被配置成使上游安全角色指定(即，用户标识符、组标识符等)包括在下游核准表中，则判决630转移到“否”分支632，在那里，处理识别与上游安全角色相对应的角色指定(步骤635)。处理在步骤640中将识别的上游角色指定加入下游安全角色中，并且，处理在步骤680中返回。

图7是示出下游应用程序核准具有上游安全角色指定的用户时所采取的步骤的流程图。处理从步骤700开始，在那里，下游应用程序接收来自上游应用程序710的请求715(步骤730)。请求715包括用户标识符720并可以包括角色725。用户标识符270标识正在请求的用户，而角色725包括与正在请求的用户的下游安全角色指定相对应的上游安全角色标识符。

对上游安全角色(例如，角色725)是否包括在请求715中作出确定(判决740)。如果上游安全角色不包括在请求715中，判决740转移到“否”分支742，绕过上游角色提取步骤。另一方面，如果请求715包括上游安全角色，判决740转移到“是”分支748，在那里，下游应用程序从请求715中提取上游安全角色，并使上游安全角色与用户标识符720结合在一起用于确定核准访问(对于进一步的细节，请参见下文)。

处理分析请求715和识别位于数据存储体765中的用于访问核准的所需下游安全角色(步骤760)。数据存储体765可以存储在诸如计算机硬盘之类的非易失性存储区上。处理查找与所需下游安全角色相对应的角色指定，并将它们与用户标识符720和角色725相比较(步骤770)。对处理是否将用户标识符720或角色725(如果可应用)与所需下游安全角色指定之一匹配作出确定(判决780)。如果处理没有识别出匹配，判决780转移到“否”分支782，在那里，在步骤785中返回错误。另一方面，如果处理识别出匹配，判决780转移到“是”分支788，在那里，处理在步骤790中核准用户，并且处理在步骤795中结束。

在一个实施例中，处理可能需要来自第二下游应用程序的信息，以便处理上游应用程序的请求。在这个实施例中，处理使匹配的下游安全角色包括在第二请求中，并且将第二请求发送到第二下游应用程序。

图8例示了作为能够实现这里所述的发明的计算机系统的信息管理系统801。计算机系统801包括与主机总线805耦合的处理器800。二级(L2)高速缓冲存储器810也与主机总线805耦合。主机-PCI桥接器815与主存储器820耦合，包括高速缓冲存储器和主存储器控制功能，并提供总线控制以管理PCI总线825、处理器800、L2高速缓冲存储器810、主存储器820和主机总线805之间的传送。PCI总线825为包括例如LAN卡830在内的各种设备提供接口。PCI-ISA桥接器835提供总线控制以管理PCI总线825与ISA总线840、通用串行总线(USB)功能845、IDE设备功能850、功率控制功能855之间的传送，并可以包括未示出的其它功能元件，譬如，实时时钟(RTC)、DMA控制、中断支持和系统管理总线支持。外围设备和输入/输出(I/O)设备可以附在与ISA总线840耦合的各种接口860(例如，并行接口862、串行接口864、红外(IR)接口866、键盘接口868、鼠标接口870和固定硬盘(HDD)872)上。可替代地，附在ISA总线840上的超级I/O控制器(未示出)可以容纳许多I/O设备。

BIOS880与ISA总线840耦合，它合并了各种低级系统功能和系统引导功能所需的处理器可执行代码。BIOS880可以存储在任何计算机可读媒体中，包括磁存储媒体、光存储媒体、闪速存储器、随机访问存储器、只读存储器和传送编码指令的信号(例如，来自网络的信号)的通信媒体。为了将计算机系统801附连在另一个计算机系统上以便在网络上复制文件，使LAN卡830与PCI总线825和PCI-ISA桥接器835耦合。类似地，为了将计算机系统与ISP连接以便利用电话线连接与因特网连接，使调制解调器875与串行端口864和PCI-ISA桥接器835连接。

虽然在图8中所述的计算机系统能够实现这里所述的发明，但是，这种计算机系统只不过是计算机系统的一个例子。本领域的普通技术人员应该知道，许多其它计算机系统设计也能够实现这里所述的发明。

本发明的优选实现之一是应用程序，即，可以驻留在例如计算机的随机访问存储器的代码模块中的一组指令(程序代码)。在计算机需要之前，该组指令可以存储在另一个计算机存储器中，例如，在硬盘驱动器上，或者，在诸如光盘(最终用在CD-ROM中)或软盘(最终用在软盘驱动器中)之类的可换式存储器中，或者，通过因特网或其它计算机网络下载。因此，本发明可以作为用在计算机中的计算机程序产品来实现。另外，尽管所述的各种方法可以方便地在通过软件有选择地启动或重新配置的通用计算机中实现，但本领域的普通技术人员应该认识到，这样的方法也可以在硬件中、在固件中，或在构造成执行所需方法步骤的更专门设备中实现。