CN1577322A

CN1577322A - 管理数据处理系统中的应用文件的方法和装置

Info

Publication number: CN1577322A
Application number: CNA2004100713151A
Authority: CN
Inventors: 戴维·Y·张; 威廉·M·爱德华兹; 阿杰伊·A·阿普特; 利·A·威廉森
Original assignee: International Business Machines Corp
Current assignee: International Business Machines Corp
Priority date: 2003-07-17
Filing date: 2004-07-19
Publication date: 2005-02-09
Anticipated expiration: 2024-07-19
Also published as: US7210125B2; CN100388265C; US20050015761A1

Abstract

提供一种用于使用基于应用的名称来管理应用的方法。一个命名服务登记一个别名，所述别名表示第一复合名，第一复合名包括与一个应用相关联的应用名称和与一个配置属性相关联的配置名称，所述配置名称刻画所述应用的一个实例的配置。所述命名服务也能够产生与一个应用相关联的基于应用的名称，所述基于应用的名称表示在一个命名系统内的上下文，基于应用的名称是包括所述别名的第二复合名。使用所述基于应用的名称来管理在数据处理系统内的一个应用。第一复合名可以与第一基于布局的名称相关联，所述第一基于布局的名称表示第一上下文，用于组织与所述应用的实例相关联的文件。

Description

管理数据处理系统中的应用文件的方法和装置

相关申请的交叉引用

本申请涉及具有相同受让方的以下申请，在此通过引用将其并入：

美国专利申请序号US10/621902、提交于2003年7月17日、题目为“用于实现基于应用的命名系统的方法和系统”。

技术领域

本发明涉及一种改进的数据处理系统，具体地说，涉及一种管理数据处理系统中的资源的方法和装置。更具体地说，本发明提供了这样一种方法和装置，它用于实现在数据处理系统中的命名系统，特别用于支持软件执行、软件管理、软件安装和/或软件配置(deploy)。

背景技术

在软件程序执行期间，需要访问许多不同种类的资源，诸如对象、文档、网页、文件，并且需要访问对于执行软件程序来说为外部的许多不同形式的可执行代码或某些其他类型的计算或通信功能或数据。在某些情况下，这些资源通过软件模块的支持操作系统可以被软件模块直接利用。在其他情况下，必须在分布式数据处理系统中识别恰当的资源。

为了正确地识别已经通过数据处理系统分布的资源，已经公布了各种类型的命名系统。虽然这些命名系统处理对于识别分布资源的公共方法的需要，但它们的方法带来各种问题，对于在分布式数据处理系统内安装的应用而言尤其如此。

作为第一个示例的特定的现有技术的命名系统实现了关于跨越一组服务器的所有应用的单个共享的平面名称空间，但是这种命名系统阻止在不改变所述应用的单一标识符的情况下，在多个服务器上安装同一应用。例如，经常通过单一标识符或名称来知道一个应用，并且如果不提供用于不同实例的不同名称，则在这种现有技术的命名系统中的多个服务器上不能安装所述应用的多个实例。

作为第二示例的特定的现有技术命名系统允许每个服务器具有它自己的名称空间区域，并且同一应用的多个实例可以被安装在多个服务器上。在这种情况下，通过向服务器指定完全符合标准的路径名称来寻址给定的资源。但是，将分布式数据处理系统的布局用来作为命名系统的一部分会引起某些可周性问题。例如，当需要从一个服务器向另一个服务器移动一个应用时，对于所述应用的任何引用(即在分布式数据处理系统内对所述应用的路径名称的使用的任何实例)都需要更新以反映出所述应用的新服务器位置。

因此，有益的是提供一种方法，它使得在不依赖于基于布局的命名系统的情况下可以识别应用文件。

发明内容

提供一种方法，它用于使用基于应用的名称来管理应用。一个命名服务登记别名；所述别名表示第一复合名，它包括与一个应用相关联的应用名称和与一个配置属性相关联的配置名称，所述配置属性将所述应用的一个实例的配置刻画。所述命名服务也能够产生与一个应用相关联的基于应用的名称；所述基于应用的名称表示在命名系统内的上下文(context)，并且所述基于应用的名称是包括所述别名的第二复合名。使用基于应用的名称来在数据处理系统内管理应用。第一复合名可以与第一基于布局的名称相关联，所述第一基于布局的名称表示第一上下文，用于组织与所述应用的所述示例相关联的文件。

附图说明

在所附的权利要求中给出了被认为具有本发明的特性的新颖特征。通过结合附图阅读下面的详细说明，可以最佳地明白本发明本身、另外的目的及其优点，其中：

图1A描述了可以实现本发明的典型分布式数据处理系统；

图1B描述了在可以实现本发明的数据处理系统内可以使用的典型计算机架构；

图2描述了示出典型的基于布局的命名系统的表示的方框图；

图3描述了一个流程图，其中示出了一个典型操作，用于在支持基于布局的命名系统的分布式数据处理系统内安装一个应用；

图4描述了一个流程图，它示出了用于在基于布局的命名系统内解析一个应用名称的典型操作；

图5描述了一个方框图，它示出了在典型的Java环境中使用来支持多个命名服务的一些逻辑部件；

图6和7描述了用于按照本发明的基于应用的命名系统的两种不同表示；

图8描述了一个流程图，它示出了用于在支持基于应用的命名系统的分布式数据处理系统内配置应用的操作；

图9描述了一个流程图，它示出了一个操作，用于将在基于应用的命名系统内的基于应用的名称解析为基于布局的名称，以在分布式数据处理系统内的后续使用；

图10描述了一个方框图，它示出了用于包括别名的基于应用的命名系统的一种表示；

图11A描述了一个方框图，它示出了用于被安装的Java应用的典型J2EE环境；

图11B描述了支持基于应用的命名服务的被修改的J2EE环境的方框图；

图11C描述了一个方框图，它示出了修改的J2EE环境，所述J2EE环境包括具有对具有别名的基于应用的名称(biased application-based name)的额外支持的、基于应用的命名服务；

图12描述了一个流程图，它示出了用于将具有别名的基于应用的名称变换为无别名的基于应用的名称的处理；以及

图13A和13B描述一对方框图，它们示出了一种方式，以此方式可以通过在按照本发明的一个实施例实现的一个数据处理系统中使用别名来管理一个应用的多个版本。

具体实施方式

一般，可以包括本发明或与本发明相关联的所述器件包括多种数据处理技术。因此，作为背景信息，在更详细地说明本发明之前，说明在分布式数据处理系统内的硬件和软件组成的典型构造。

现在参见附图，图1A描述了多个数据处理系统的典型网络，每个数据处理系统可以实现本发明的一部分。分布式数据处理系统100包括网络101，它是一种介质，可以用于提供在分布式数据处理系统100内连接到在一起的、各种器件和计算机之间的通信链路。网络101可以包括：永久连接，诸如有线或光缆；或通过电话或无线通信建立的暂时连接。在所描述的示例中，服务器102和服务器103连接到网络101以及存储单元104。另外，客户端105-107也连接到网络101。客户端105-107和服务器102-103可以由多种计算器件表示，所述多种计算器件诸如主机、个人计算机、个人数字助理(PDA)等。分布式数据处理系统100可以包括未示出的其他服务器、客户端、路由器、其他器件和对等结构。

在所描述的示例中，分布式数据处理系统100可以包括网络101的因特网，用于表示使用各种协议彼此通信的网络和网关的世界范围的集合，所述协议诸如为轻型目录访问协议(LDAP)、传输控制协议/网际协议(TCP/IP)、超文本传送协议(HTTP)、无线应用协议(WAP)等。当然，分布式数据处理系统100也可以包括多个不同类型的网络，诸如内联网、局域网(LAN)或广域网(WAN)。例如，服务器102直接支持客户端109和并入无线通信链路的网络110。网络启动(enable)电话111通过无线链路112连接到网络110，PDA 113通过无线链路114连接到网络110。电话111和PDA 113也可以使用诸如蓝牙技术之类的适当技术，通过无线链路115在它们之间传送数据，以便建立所谓的个人区域网络(PAN)或个人特别网络。以类似的方式，PDA 113可以经由无线通信链路16向PDA 107传送数据。

本发明可以被实现在多种硬件平台上。图1A意欲作为异构计算环境的一个示例，而不是作为对于本发明的架构限定。

现在参见图1B，这个附图描述了诸如图1A所示的数据处理系统的一种典型计算机架构，在其中可以实现本发明。数据处理系统120包括一个或多个连接到内部系统总线123的中央处理单元(CPU)122，所述内部系统总线123互连随机存取存储器(RAM)124、只读存储器126和输入/输出适配器128，所述输入/输出适配器128支持各种输入/输出器件，诸如打印机130、盘单元132或其他未示出的器件，所述其他未示出的器件诸如为音频输出系统等。系统总线123还连接通信适配器134，它提供对通信链路136的访问。用户接口适配器148连接到各种用户器件，诸如键盘140和鼠标142或其他未示出的器件——诸如触摸屏、指示笔、麦克风等。显示适配器144将系统总线123连接到显示器146。

本领域内的普通技术人员可以明白，图1B的硬件可以根据系统实现方式来改变。例如，所述系统可以具有一个或多个处理器——诸如基于Intel^Pentium^的处理器和数字信号处理器(DSP)——和一种或多种类型的易失性和非易失性存储器。其他的外围器件可以用于补充或替代图1B中所述的硬件。所描述的示例不意味着包含对本发明的架构限定。

除了能够被实现在多种硬件平台上之外，本发明还可以被实现在多种软件环境中。一种典型的操作系统可以用于控制在每个数据处理系统内的程序执行，例如，一种器件可以运行Unix^操作系统，而另一种器件包括简单的Java^行时间环境。一种代表性的计算机平台可以包括浏览器，它是用于访问多种格式的超文本文件的公知软件应用程序，所述多种格式的超文本文件诸如为图形文件、文字处理文件、可扩展标记语言(XML)、超文本标记语言(HTML)、手持器件标记语言(HDML)、无线标记语言(WML)和各种其他格式和类型的文件。

本发明可以被实现在多种硬件和软件平台上，如以上参照图1A和图1B所述。更具体地说，虽然本发明针对改进的命名系统，特别是用于支持应用安装或配置的改进的命名系统和用于那些应用的执行环境中的后续支持的命名服务。

在更详细地描述本发明的改进的命名系统之前，描述一种典型的命名系统，具体上是按照X/Open联合命名(XFN)模型的命名系统，许多命名系统基于X/Open联合命名(XFN)模型的命名系统。X/Open是由许多其他组织和公司支持、并且专用于通过开放系统的实际实现来增强计算的独立开放系统结构。X/Open限定了在一组规范中的一种公共应用环境(CAE)，该组规范包括提供在应用程序中的可移植性的一组应用程序接口(API)，还包括用于增强应用的互用性的协议的定义。XFN规范满足了对于标准命名系统的需要。

本发明与所述XFN命名模型和类似的命名系统兼容，因此使用与在XFFN规范中所述的类似的定义。“命名惯例”是用于产生一个名称的一组语法规则。“原子名称”是由所述命名惯例定义的名称的不可分的成分。“复合名”表示按照本发明所述命名惯例构成的一个或多个原子名称的序列。例如，路径名称“/cell/nodes/nodename”是包括下列原子名称序列的复合名：“cell(单元)”、“nodes(节点)”和“node-name(节点名称)”。原子名称路径名称被从左向右排序，并且被特殊的字符定界，所述特殊的字符在这种情况下是斜杠字符。命名惯例使得能够定义用于语法分析任何复合名的功能，并且命名惯例也确定名称之间的等效性。

一个对象的“引用”包括一个或多个通信端点或地址。“绑定”是原子名称与对象引用的联系。在一些情况下，可交换地使用对象引用和它引用的对象。“上下文”是一个对象，其状态是一组具有不同原子名称的绑定。每个上下文具有相关联的命名惯例。上下文提供了查找功能，即解析操作，它返回绑定到一个对象的引用。在一个上下文对象中的原子名称可以被绑定到对于同一类型的另一个上下文对象的引用上，因此产生复合名。例如，在路径名称“/cell/nodes/node-name”中，原子名称“nodes”在“cell”的上下文中被绑定到“contextsubcontext”，而其绑定了“node-name”。复合名的解析的进行是通过解析在每个连续上下文中的每个连续原子分量。

“命名系统”是相互连接的一组同一类型的上下文，所述同一类型即具有相同的命名惯例，并且向同一组操作提供相同的语义。“命名服务”是被提供来支持命名系统的一个实例的服务，例如，命名服务可以是一组API，它们提供实现语法规则所需要的操作，所述语法规则用于产生和管理在命名系统内的名称。“名称空间”是命名系统中所有名称的集合，即名称空间是命名系统的一个实例。“复合名”是跨越多个命名系统的名称。

“联合命名系统”是多个自主命名系统的集合体，所述多个自主命名系统合作来支持通过标准接口的复合名的名称解析。“联合命名服务”是被提供来支持联合命名系统的一个示例的服务。“联合名称空间”是按照用于支配在成员命名系统和它们相应的名称空间中的关系的策略而产生的所有可能名称的集合。“命名系统边界”是这样的一个点，在此在联合体的一个成员的控制下的名称空间结束，而在联合体的下一个成员的控制下的名称空间开始。当一个命名系统与另一个命名系统联合时，在复合名解析期间首先涉及的命名系统是“上级”命名系统。在通过上级命名系统的解析后，下一个命名系统是“下级”命名系统。

在上面给出对命名系统命名法的介绍后，在更详细地说明本发明的命名系统——包括支持本发明的改进的命名系统的命名服务——之前，在图2-5中提供了一些附加的背景信息。参照图2来说明典型命名系统的一个示例。图3和图4的说明涉及典型的操作，分别用于在基于布局的名称空间中安装应用和用于在基于布局的名称空间内解析名称。图3和图4中描述的操作仅仅意欲作为在命名服务和一些其他类型的应用之间的交互的示例。另外，所描述的操作提供用于在典型的基于布局的命名系统和按照本发明实现的命名系统之间的随后比较的基础。图5提供了用于讨论在Java运行时间环境内的命名系统的基础。

虽然典型的命名服务支持许多操作，例如用于绑定名称、解析名称、去绑定(debind)、重新命名上下文等，但是本发明的说明着重于绑定操作和解析操作，这是由于它们在命名服务内的重要特性。但是，应当注意，按照本发明的实现的命名服务除了绑定操作和解析操作之外还可以提供大量的、与命名系统相关联的操作。

现在参见图2，这个方框图描述了典型的、基于布局的命名系统的表示。在图2所示的基于布局的命名系统中，串“/cell/nodes/node_name/servers/server_name/apps/app_name”表示一个完全符合标准的基于布局的名称，它表示在用于名称为“app_name”的应用的本地文件系统内的位置，即所述串表示在基于布局的命名系统内的上下文。如图2所示，上下文像在命名系统内的任何其他对象一样，上下文也可以被绑定到在上下文内的一个名称上。在其他上下文中绑定上下文就建立了一个复合名。例如，app_name是一组已经在上下文“apps”内被绑定的多个名称之一；“apps”和“databases”是已经在“sever_name”内被绑定的两个名称；“server_name”是一组已经在上下文“servers”内被绑定的多个名称之一；“servers”和“desktops”是已经在“node_name”内被绑定的两个名称；“node_name”是一组已经在上下文“节点”内被绑定的多个名称之一；“nodes”和“clusters”是已经在上下文内被绑定的两个名称。在图2所示的示例中，每个服务器(server)支持一组数据库文件和/或一组应用文件；每个节点(node)支持一组桌上型电脑(desktop)和/或一组服务器；每个单元(cell)支持一组簇(cluster)和/或一组节点。

另外，图2所示的示例可以描述具有两个命名系统边界的联合命名系统。首先，作为域类型的单元可以是在更宽的基于布局的命名系统内的上下文，诸如由有较大分布式数据处理系统的命名服务所支持的命名系统。第二，根据可以获得的操作系统支持，可以允许应用支持它们自己的上下文，即子上下文，例如提供对于由独立应用控制的被命名资源的访问。

现在参见图3，一个流程图描述了一种典型的操作，用于在支持基于布局的命名系统的分布式数据处理系统内安装一个应用。图3所述的操作可以由应用安装实用程序、应用管理器或由一些其他形式的系统管理器或系统配置实用程序来执行。

以启动对于应用的安装操作来开始操作(步骤302)。在确定在用于存储与要安装的应用相关联的一个或多个应用文件的预期布局内的适当位置后(步骤304)，获得要安装的应用的名称(步骤306)，并且进行查看以保证在要安装的应用和先前安装的应用的名称之间不产生命名冲突(步骤308)。如果存在冲突，则可以报告所述冲突，以便警告负责启动安装流程的适当系统管理员或用户。假定不存在命名冲突，则将应用存储在分布式数据处理系统内的所选择位置(步骤310)，例如在本地文件系统内的所选择位置。

在存储应用后，所述应用进行对于命名服务的一种登记操作。获得在基于布局的命名系统内的所选择的安装位置的上下文(步骤312)，例如在本地文件系统内的路径名称，并且请求恰当的命名服务将新安装的应用名称绑定一个基于布局的名称(步骤314)。名称绑定被存储在恰当的命名服务数据库内(步骤316)，并且成功安装的指示被返回安装实用程序或系统管理应用(步骤318)，由此结束安装流程。

现在参见图4，这个流程图描述了一种典型操作，用于解析在基于布局的命名系统内的应用名称。可以通过需要执行对于与所述应用名称相关联的应用的、某种类型的后续操作的任何应用来执行在图4中所述的解析操作，所述任何应用例如为需要请求访问由所述应用控制的资源的系统管理应用或对等应用。

解析操作以命名服务接收基于布局的应用名称来开始(步骤402)。所述命名服务然后使用所接收的基于布局的名称来执行查找操作，以获得用于目标应用的适当数据实体(步骤404)，诸如对象引用或上下文，由此将所述应用名称映射到它的相关联的对象。然后将诸如串之类的适当数据实体返回请求者(步骤406)，由此结束解析操作。

参见图5，这个方框图描述了在典型的Java环境中使用来支持多个命名服务的一些逻辑成分。Java命名和目录接口(JNDI)——在图5中被示出为JNDI 502——是用于向诸如应用504的、以Java编程语言所写的应用提供命名和目录功能的标准接口。

JNDI的概念模型是基于XFN命名模型的。按照JNDI规范，命名和目录服务通过提供资源的网络共享，在内联网和因特网中扮演重要的角色，并且通过使用JNDI，Java应用可以存储和检索任何类型的被命名的Java对象。另外，JNDI提供了多种方法，用于执行标准目录操作，例如将属性与对象相关联，并且使用它们的属性来搜索对象。

JNDI是独立于任何具体的命名或目录服务实现方式而被定义的。它使得Java应用能够使用公共的API来访问不同的、可能多个命名和目录服务。不同的命名和目录服务提供者可以无缝地被插在这个公共API后面。这使得Java应用可以利用在诸如LDAP和DNS之类的多种现有命名和目录服务中的信息，并且使得Java应用可以与传统的应用和系统共存。使用JNDI作为工具，Java应用开发者可以建立新的强大和可以移植的应用，它们不仅使用Java的对象模型，而且也与它们被配置的环境良好地集成。

再次参见图5，JNDI 502包括JNDI 502包括：JNDI API 506，它使得Java应用可以访问多种命名和目录服务；JNDI SPI(服务提供者接口)508，它使得多种命名和目录服务——诸如DNS(域名系统)服务提供者510、LDAP(轻型目录访问协议)服务提供者512和CORBA(公用对象请求代理程序体系结构)服务提供者514——被集成到Java运行时间环境中。如上所述，本发明针对一种改进的命名系统，具体上是这样的一种改进的命名系统，它用于支持应用的安装或配置，并且用于在那些应用的执行环境中随后支持的命名服务。参见图5，按照本发明实现的命名服务可以以类似于图5所示的其他命名服务的方式来被插入Java运行时间环境中。下面进一步更详细地说明相对于Java运行时间的本发明的描述。

如上所述，使用分布式数据处理系统的布局来作为命名系统的一部分可能引起某些可用性问题。换句话说，使用基于布局的名称(或更一般而言，基于布局的命名系统)具有固有的局限。最明显的问题是：在已经配置了一个应用后的后续时间点，可以使用所述应用的基于布局的名称——诸如应用的路径名称——来对所述应用进行对应用的各种引用。这些引用可以被存储在数据库或应用/系统管理文件内，并且根据在后续时间点在分布式数据处理系统内发生的情况，这些引用可能需要被更新，这可能需要对许多文件进行大修改以及大量的管理操作努力，以保证进行所有恰当的更新。

更具体地说，特定应用的基于布局的名称经常被存储在调用在那些特定应用内的功能的其他应用的资源文件中。例如，许多运行时间环境提供用于一个应用的各种类型的资源文件。这些资源文件打算使一个应用的资源需要具体化，以便资源名称或资源引用不必被存储在一个应用内、即在一个应用内被硬编码。资源文件在其运行时间资源要求被存储在资源文件中后变为一个应用的运行时间要求的一种元数据说明。如果一个应用需要调用在另一个应用的模块内的功能，则这个事实被存储在调用应用的资源文件中。通常，被调用的应用或被调用的模块的基于布局的名称被存储在资源文件内。以这种方式，调用应用的运行时间代码很可能使用资源引用的简单逻辑名称来进行对其资源文件的简单引用，并且运行时间环境然后提供用于确定更明确的基于布局的名称的查找操作，其后对象引用或其他数据项目用于运行时间操作。

这种方法降低了应用的源代码对其运行时间环境的依赖性，由此降低了需要根据在其运行时间环境中改变来修改一个应用的源代码的可能。但是，如果资源——特别是应用或应用模块——在本地布局内被移动，则对于基于布局的名称的依赖性使得需要在分布式数据处理系统上的大改变。例如，当一个应用需要从一个服务器被移到另一个服务器时，则对于所述应用的任何引用、即在分布式数据处理系统内的所述应用的基于布局的名称的使用的任何实例，需要被更新以反应所述应用的新服务器的位置。

基于应用的命名系统

鉴于上面对于典型的命名系统和各种运行时间分量已经提供的背景信息以及对于实现典型的命名系统的考虑。现在提供本发明的详细说明。本发明针对一种改进的命名系统，并且针对用于帮助实现所述改进的命名系统的任何运行时间分量。更具体地说，本发明针对新颖的基于应用的命名系统，而不是基于布局的命名系统。

在本发明的基于应用的命名系统中，基于应用的名称是复合名，它或者包括一个应用名称和至少一个配置名称，或者包括表示一个应用名称的原子名称和至少一个配置名称。应用名称是与一个应用的一个或多个实例相关联的原子名称。配置名称是与配置属性相关联的原子名称。配置属性可以包括将在分布式数据处理系统内配置一个应用的特定实例的方式刻画的任何元数据。例如，配置属性可以刻画一个应用的一系列版本，每个版本彼此类似，不同在一个时间段上的某些元素或特征。配置特征可以包括：配置标识符(ID)、它可以是与配置操作相关联的唯一标识符，其中所述标识符可以是例如在分布式数据处理系统内的所有配置操作上或在对于特定应用版本或实例的所有配置操作上唯一的；与应用的版本相关联的版本号/标识符，例如随着时间增加的版本号，用于识别对于应用的一系列修改中的改进的每次重复；或一些其他的标识符，用于与配置相关联的特性或量度，诸如执行配置的日期。下面参照剩余的附图更详细地说明本发明的基于应用的命名系统。

现在参见附图6和7，这些方框图描述了按照本发明的基于应用的命名系统的两种不同的表示。在图6中所示的基于应用的命名系统中，串“/cell/application/application_name/deployments/deployment_ID/versions/version_ID/modules/module_name/”表示完全符合标准的、基于应用的名称，用于具有模块名称“module_name”的应用模块，即，所述串表示在用于特定的应用模块的基于应用的命名系统内的上下文。在基于应用的命名系统中的上下文类似于参照XFN模型上述的上下文，在其他上下文中的绑定上下文建立复合名。

在图6所示的示例中，“applications(应用)”、“deployments(配置)”、“versions(版本)”和“modules(模块)”是恒定或不变的名称，但是它们可以被扩展来包括在给定上下文内的变量名称，例如用于提供在基于应用的命名系统中的命名图形内的附加分支。另外，application_name是一组已经在上下文“applications”内被绑定的多个名称之一，“deployment_ID”是一组已经在上下文“deployments”内被绑定的多个名称之一；“version_ID”是一组已经在上下文“versions”内被绑定的多个名称之一；“module_name”是一组已经在上下文“modules”内被绑定的多个名称之一。

图6中所示的示例可以描述具有两个命名系统边界的联合命名系统。首先，一个单元(cell)可以是在上级命名系统内的上下文，所述上级命名系统例如由用于较大分布式数据处理系统的命名服务支持的命名系统。第二，依赖于可以获得的操作系统支持，可以允许应用支持例如它们自己的上下文，即子上下文，以便提供对由独立应用控制的被命名资源的访问。以这种方式，本发明的基于应用的命名系统能够与上级和下级命名系统联合。

在图6所示的示例中，假定一个应用包括多个模块。但是，在其中一个应用包括单个模块的不同的实施例中，可能不需要对应于应用模块的一个上下文。换句话说，在不同的实施例中，基于应用的命名系统可以在“deployment_ID”后结束命名图形。

现在参见图7，它描述了一种替代的基于应用的命名系统，其中与图6相比较，去除了恒定或不变的上下文“applications(应用)”、“deployments(配置)”、“versions(版本)”和“modules(模块)”。在图7的示例中，串“/cell/application_name/deployment_ID/module_name/”表示用于具有模块名称“module_name”的应用模块的完全符合标准的基于应用的名称，即，所述串表示在用于特定应用模块的基于应用的命名系统内的上下文。如上所述，按照本发明实现的基于应用的命名系统支持多个复合名，其中包括一个应用名称和至少一个配置属性，并且在图7的示例中，“deployment_ID”表示在基于应用的名称中的最小单个配置属性。与图6相比较，已经在图7的表示中去除了作为基于应用的名称的一部分的“version_ID”。在本发明的其他实施例中，可以在基于应用的名称中包括附加的配置属性。同样，在图7中，假定一个应用包括多个模块。但是，在一个应用包括单个模块的不同实施例中，基于应用的命名系统可以在“deployment_ID”后结束命名图形。

下面的串是包括多种配置信息的基于应用的名称的一些示例。与任何计算机相关联的名称一样，在这些示例中的名称具有仅仅在给定的计算环境中的含义；换句话说，在这些示例中的名称仅仅在给定的数据处理系统中是有效的。换句话说，在这些实例中的名称可以仅仅在给定的数据处理系统内被解析或映射为特定的上下文或资源。因此，注意在这些实例中的名称的解释必定并入了关于支持这些名称的假设数据处理系统的信息。

示例7-1：“austin_TestBed/WebServ/Vers0-9-a/Lookup/”。在示例7-1中，“ustin_TestBed”的是作为在基于应用的命名系统内的根的上下文。这个特定的上下文通过一个特定企业的基于Austin的办公室来组织在应用的开发测试阶段中的所述应用的所有应用文件。“WebServ”指的是这样的上下文，它组织与“WebServ”有关的所有文件，“WebServ”是用于正在被所述企业开发的一个应用的特定应用名称。“Vers0-9-a”是一个配置属性，它已经被用作组织与“WebServ”应用的特定的配置版本(版本0.9alpha)相关的所有文件的上下文。“Lookup”指的是这样的上下文，它组织与在“WebServ”应用内的查找模块相关的所有文件，例如一组动态链接库(DLL)文件或其他类型的可执行文件。

示例7-2：“austin_TestBed/WebServ/Vers0-9-b/Lookup/”。除了与示例7-1中的“Vers0-9-a”的配置属性相比较，在示例7-2中的配置属性被设置为“Vers0-9-b”外，示例7-2类似于示例7-1。在示例7-2中，“Vers0-9-b”是已经被用作下述上下文的配置属性，所述上下文组织与“WebServ”应用的特定配置版本(版本0.9beta)相关联的所有文件。

示例7-3：“server/serverX/DB2/2003Jan01/”。在示例7-3中，“server”指的是作为在基于应用的命名系统内的一个根的上下文。这个特定的上下文组织特定企业的所有服务器。“serverX”指的是特定服务器的上下文。“DB2”指的是组织与“DB2”相关联的所有文件的上下文，所述“DB2”是特定的应用名称。“2003Jan01”是一个配置属性，它已经被用作一个上下文，所述上下文组织与“DB2”应用的特定配置相关联的所有文件，例如在特定日期发生的应用的配置。

示例7-4：“server/serverX/DB2/2003July01”。除了与示例7-2中的配置属性2003Jan01相比较，在示例7-4中的配置属性被设置为2003July01外，示例7-4类似于示例7-3。在示例7-4中，2003Jan01是一个配置属性，它已经被用作一个上下文，所述上下文组织与DB2应用的特定配置相关的所有文件。

这些配置属性——诸如“Vers0-9-a”或“2003July01”——可以产生自多种来源：来自系统管理员、来自控制应用的配置的系统管理应用或来自一些其他来源。

现在参见图8，这个流程图描述了一个操作，用于在支持基于应用的命名系统的分布式数据处理系统内配置一个应用。除了图8示出了基于应用的名称的使用外，图8所示的处理实质上类似于图3所示的处理。图8所示的操作的执行可以通过应用安装实用程序、应用管理器或通过一些其他形式的系统管理器或系统配置实用程序来执行。所描述的操作打算仅仅说明一个示范操作，在其中基于应用的名称被用在分布式数据处理系统内。

所述操作以启动一个配置或一个应用的安装操作来开始(步骤802)。在确定用于存储与要配置的应用相关联的一个或多个应用文件的、在预期的布局内的适当位置后(步骤804)，要配置的应用的名称和与所述应用相关联的各种配置属性一起被获得(步骤806)。可以从已经与所述应用或应用模块相关联的一个应用配置文件检索应用名称、配置属性等。

如果恰当的话，可以进行查看以保证在要配置的应用和任何先前配置的应用的名称之间不产生命名冲突。如果存在冲突，则可以报告所述冲突，以便警告负责启动配置流程的适当系统管理员或用户。假定不存在命名冲突，则将应用存储在分布式数据处理系统内的所选择位置(步骤808)，例如在本地文件系统内的所选择位置。

在存储应用后，所述应用进行对于基于应用的命名服务的一种登记操作。对于被配置的应用，根据其应用名称和一个或多个配置属性来产生一个基于应用的名称(步骤810)。获得在分布式数据处理系统内的所选择配置位置的基于布局的上下文(步骤812)，例如在本地文件系统内的路径名称，并且请求所述基于应用的命名服务将新配置的应用的基于应用的名称绑定其被配置的上下文的基于布局的名称(步骤814)。名称绑定被存储在恰当的命名服务数据库内(步骤816)，并且成功配置的指示被返回配置实用程序或系统管理应用(步骤818)，由此结束配置流程。应当注意，图8所示的配置操作描述了正在被配置的单个应用文件/模块，但是如果一个应用包括多个模块，则对于要配置的每个应用模块重复图8所示的处理，并且在产生恰当的基于应用的名称期间也使用每个模块名称。

现在参见图9，这个流程图描述了一种操作，用于将在基于应用的命名系统内的一个基于应用的名称解析为基于布局的名称以供在分布式数据处理系统内的后续使用。可以通过需要执行对于与所述基于应用的名称相关联的应用的某种类型的后续操作的任何应用来执行在图9中所述的解析操作，所述任何应用例如为需要请求访问由所述应用控制的资源的系统管理应用或对等应用。

解析操作以命名服务接收基于应用的名称来开始(步骤902)。所述命名服务然后使用所接收的基于应用的名称来执行查找操作(步骤904)，由此将所述基于应用的名称映射到它的基于布局的名称。所述基于布局的名称然后用于可能通过另一个服务来获得用于目标应用的适当数据实体(步骤906)，诸如对象引用或上下文。所述恰当的数据实体然后被返回请求者(步骤908)，由此结束解析操作。

在这个示例中，一个基于应用的名称在基于布局的名称上提供提取(abstraction)或间接层，它随后被用于运行时间环境中以获得对象引用或其他数据。但是，依赖于操作系统及其对命名服务的依赖性，基于应用的名称可能由于名称解析操作的结果而能够被直接映射到对象引用、上下文或其他恰当的数据对象。在解析一个应用或一个应用模块的基于应用的名称的情况下，考虑解析操作的结果将是配置或安装所述应用或所述应用模块的服务器根的一个上下文对象。以这种方式，所述应用或应用模块的被命名的资源与服务器根上下文相关，同时仍然可以通过JNDI被访问。如果一个应用包括多个模块，则每个模块可以映射到不同的服务器根上下文。

本发明的基于应用的命名系统提供了在相对于基于布局的命名系统的、用于应用和资源管理的多个优点。使用本发明，基于应用的名称独立于在分布式数据处理系统内的服务器布局。基于应用的名称保持接近一个应用的应用开发者的视图或用户的视图，即一个应用的实例可能仅仅是在分布式数据处理系统内的一个应用的许多配置实例的一个实例，或可能据介绍一个应用的许多版本的一个实例。

包括别名的基于应用的命名系统

现在参见图10，这个方框图描述了用于按照本发明的一个实施例的基于应用的命名系统的一种表示。虽然图10所示的基于应用的命名系统类似于图6，但是图10图解了增加对别名的支持，其中在基于应用的名称内的多个分层上下文被替换为一个别名，如下更详细所述。

如图6所示，按照本发明实现的基于应用的命名系统支持复合名，而复合名包括一个应用名称和至少一个表示配置属性的名称。如图10所示，基于应用的命名系统还可以包括对于别名的支持。别名被定义为用于表示应用名称和表示配置属性的名称的原子名称。包括别名的基于应用的名称也可以被描述为带有别名的基于应用的名称，不包括别名的基于应用的名称也可以被描述为不带有别名的基于应用的名称。

一个别名可以被实现为一个串，这个串可以或不可以包括用于应用名称的子串或用于一个或多个配置属性的子串。例如，用于别名的串可以是对于具有诸如2003-01的特定配置属性的值的串预先附加的、具有诸如WebServ的特定应用名称的值的串，其中所述应用名称和配置属性的子串被附加，但是仍然被诸如“WebServ 2003-01r”的特殊的字符定界。

但是，如下进一步所述，别名表示在应用名称和相关联的配置属性中的信息，因此别名通常是简单的串，诸如“myWebServ”。在一个优选实施例中，为了翻译别名，向基于应用的命名服务登记所述别名，所述基于应用的命名服务存储与一个复合名相关联的别名；这个相关联的复合名包括一组原子名称，它们是所述应用名称和至少一个表示配置属性的名称。在本发明的不同实施例中，在带有别名的基于应用的名称中的配置属性的数量可能不同，因此由别名表示的配置属性的数量可能不同。

同样，在图10中，像前面的图中一样，假定一个应用包括多个模块。但是，在一个应用包括单个模块的一个不同实施例中，基于应用的命名系统可以在“alias_name”后结束命名图。

与图6相比较，图10描述了一种替代的基于应用的命名系统。像在图6中一样，在图10中的基于应用的命名系统中的上下文类似于参照XFN模型上述的上下文。在其他上下文中绑定上下文建立了一个复合名。

应当注意，图10图解了可以与不带有别名的基于应用的名称——即不包括别名的基于应用的名称——并行地、在基于应用的命名服务的一个具体实现方式内实现带有别名的基于应用的名称。但是，带有别名的基于应用的名称相对于不带有别名的基于应用的名称提供某个数量的优点。如上所述，基于应用的名称提供被安装的应用的、以应用为中心的视图，这可以与现有技术的解决方案相比较，现有技术的解决方案提供基于布局的名称，基于布局的名称提供被安装的应用的、以布局为中心的视图。同样，本发明的另一个实施例提供了带有别名的基于应用的名称，它们提供按照数据处理系统的用户的需要而可变的应用的逻辑视图。带有别名的基于应用的名称可能没有布局信息，但是被配置相关联的信息拖累。

在图10所示的基于应用的命名系统中，串“/cell/applications/lias_name/modules/module_name/s”表示完全符合标准的、用于具有模块名称“module_name”的应用模块的基于应用的名称，即，这个串表示在用于特定应用模块的基于应用的命名系统内的上下文。在图10所示的示例中的作为“alias_name”的别名是以类似于下述方式的方式与一个上下文相关联的原子名称：在所述方式中，在基于应用的名称内的其他原子名称与在基于应用的命名系统中的上下文相关联。但是，所述别名与在基于应用的名称内的其他名称不同，因为它表示一个复合名，所述复合名包括一个应用名称和至少一个表示配置属性的名称。

应当注意，在图6和图10中，名称“应用”仅仅用于说明的目的，它表示在给定的基于应用的命名系统内的特定的上下文，并且不应当与用于本发明的说明性术语“基于应用的”相混淆。例如，在其上已经实现本发明的给定的数据处理系统中，可以假定由于对于给定的数据处理系统的用户在管理或维护系统中在智力上有益，特定的名称“应用”已经被选择，例如所有的应用在特定的上下文下以分层的方式被组织，这可能与在不同的上下文下以分层的方式组织的所有数据库成为比较。

别名的使用提供了一种机制，用于在使用多个配置属性的基于应用的命名系统中有效地紧凑容放完全符合标准的名称。例如，指定5个配置属性以及用于组织5个配置属性的恒定或不变上下文名称的、基于应用的命名系统将产生很长的名称，而在同一基于应用的命名系统中的别名短得多、容易记忆、容易人为或编程使用。

在图10中，别名是原子名称，它表示复合名，复合名包括一个应用名称和四个配置相关的名称。换句话说，别名是具有一个值的串。在图10所示的示例中，别名的串值被示出为“alias_name”。这个别名与复合名相关联，并且这个复合名包括一个应用名称和至少一个表示配置属性的名称。在所述别名和所述复合名之间的关联被登记在支持基于应用的命名系统的命名服务中、即基于应用的命名服务内。因此，可以从基于应用的命名服务检索这个关联以供以后使用。

这个相关联的复合名可以被描述为基于应用的名称，因为如上所定义的基于应用的名称可以包括一个应用名称和至少一个表示配置属性的名称。与别名相关联的复合名不能包括另一个别名。因此，别名表示可以被描述为不带有别名的基于应用的名称、即不包括别名的基于应用的名称的复合名。

在图10所示的示例中，在与别名相关联的复合名中的原子名称的组、即由别名表示的复合名包括下列：用于与在数据处理系统内被管理的一个应用相关联的、特定应用的原子名称，例如“application_name”；原子名称“配置”，它表示恒定或不变的上下文，用于组织在上级上下文、即“application_name”中被识别的应用的配置；具有用于诸如“deployment_ID”的配置标识符的个值的原子名称；原子名称“版本”，它表示恒定或不变的上下文，用于组织被配置的应用的版本；具有用于诸如“v”的版本标识符的一个值的原子名称。

支持基于应用的命名系统的命名服务以类似于不带有别名的基于应用的名称的方式解析带有别名的基于应用的名称。因此，带有别名的基于应用的名称必须在使用别名上下文的上级上下文内是唯一的。在图10所示的示例中，带有别名的基于应用的名称必须在一个单元中是唯一的，但是，多个唯一带有别名的基于应用的名称可以解析同一对象，例如与一个应用相关联的应用模块或数据文件。换句话说，可能存在别名到对象的多对一映射，如下面进一步所示。

在支持带有别名的基于应用的名称的数据处理系统中的应用的安装和管理

如上参照图10所述，带有别名的基于应用的名称提供相对于不带有别名的基于应用的名称的某些优点。使用带有别名的基于应用的名称的优点之一使应用的安装和管理变得更有效，例如移动一个应用的物理位置和安装一个应用的多个实例。下面描述本发明的一个实施例可以提供这些效率的方式。

如上所述，由正在执行的应用所需要的文件的名称经常被存储在所述应用的资源文件中，由此降低一个用于2的源代码对其运行时间环境的依赖性，并且降低需要根据其运行时间环境——诸如其配置位置——中的改变来修改一个应用的源代码的可能。那些文件可以被集成或以某种方式与所述应用相关联。但是，由一个应用所需要的文件可以被集成或与一些其他的应用——例如输出用于其他应用使用的功能的应用——相关联；这些文件的名称可以被保存在与所述应用相关联的一个资源文件中。在现有技术中，这些文件的名称依赖于它们被存储在其中的数据处理系统的布局。换句话说，在现有技术中，这些文件的名称是基于布局的。

在资源文件中使用基于布局的名称和在数据处理系统内的其他点引起某些问题或低效率。例如，当在一个系统内例如从一个服务器相另一个服务器移动一个应用时，在数据处理系统的布局内的应用文件的位置被改变，并且那些文件的基于布局的名称也必须改变。对于应用文件的基于布局的名称的任何引用——例如在资源文件内的任何引用——必须被更新以反映应用文件的新位置。作为另一个示例，当一个应用的特定版本的一个实例被安装在一个服务器上时，它通常被应用名称和版本号识别。当通常在单个服务器上存储一个应用的几个版本时，在单个服务器上安装一个应用的特定版本的多个实例通常很麻烦。这些类型的问题在支持基于应用的命名系统的数据处理系统内被减轻。

可以使用Java运行时间环境的一个示例来说明使用基于应用的名称的优点。在用于分布式数据处理系统的现有技术运行时间环境中，支持一种联合的命名系统，其中每个J2EE(Java 2平台，企业版)应用服务器具有其本身的上下文；J2EE应用的多个实例可以被配置在不同的J2EE应用服务器上的运行时间环境内。通过将分布式数据处理环境的命名系统与J2EE运行时间环境的命名系统联合而产生完全复合标准的基于布局的名称；JNDI提供对于结果产生的用于J2EE应用的联合名称空间的访问。在给定的运行时间环境中，一个J2EE应用可以通过调用由JNDI API提供的适当方法来引用在给定的运行时间环境的联合名称空间内的另一个J2EE应用的上下文。例如，诸如“/cell/nodes/node-name/servers/server-name EJBHome/”的完全符合标准的基于布局的名称可以被J2EE用来引用另一个远程J2EE应用的上下文。

J2EE应用包括小服务程序和其他EJB(企业JavaBeans)。每个EJB具有在EJB的配置描述符中声明的相关联信息，所述EJB的配置描述符包括用于一个EJB的各种属性的元数据。因为其环境信息对于EJB的源代码是外部的，因此可以不改变EJB的源代码而在一定程度上定制EJB。使用EJB配置描述符可以保持EJB的平台透明度，同时对于每个目标平台仅仅需要改变配置信息。

以这种方式，EJB配置描述符是如上所述的一类资源文件，因此，EJB配置描述符具有上述的问题之一。用于数据处理系统的基于布局的名称经常被存储在EJB配置描述符和其他类型的配置描述符文件内，由此当J2EE应用被从一个服务器相另一个服务器移动时或当需要安装一个应用的多个实例时引发可用性问题。例如，一个J2EE应用可以在其配置描述符中具有一个和多个E<ejb-ref>定义，并且这些EJB引用的每个可以包括用于与另一个J2EE应用相关联的模块、EJB或文件的基于布局的名称；当从一个服务器向另一个服务器移动其他J2EE应用时，J2EE客户端应用的配置描述符需要被修改以使用用于新位置的基于布局的名称。

利用本发明，可以在基于应用的命名系统内管理J2EE应用，并且基于应用的命名系统的使用可以简化应用安装和管理。J2EE客户端应用可以使用J2EE应用的安装信息来引用在J2EE应用的名称空间或上下文中的被命名资源，所述安装信息诸如J2EE应用的二进制名称、配置ID和模块名称。应用开发器或应用汇编器不需要知道J2EE应用服务器的布局信息，诸如在企业域内的节点名称和服务器名称。即使静态地定义J2EE应用安装信息，即应用安装信息在安装一个应用后不动态改变，J2EE客户端应用的配置描述符也不是必需要改变的，即使从一个服务器向另一个服务器移动J2EE应用以用于例如负荷平衡目的或某些其他目的，也是如此。

在一个系统内的一个应用的配置期间，一种应用管理实用程序将使用所述应用的配置信息来向基于应用的命名服务登记基于应用的名称。可以从与应用模块相关联的应用配置文件检索所述配置信息。基于应用的命名服务可以存储与用于应用文件的文件系统信息相关联的基于应用的名称，例如用于那些应用文件的位置的基于布局的名称；这个关联被存储在一个数据库、登记文件或某些其他类型的数据存储器中，并且可以通过查找操作来检索所述关联。以这种方式，可以在用于应用模块的基于应用的名称和应用模块的服务器的、例如路径名称的基于布局的名称之间建立绑定。一旦对于应用模块产生基于应用的名称，则可以使用恰当的基于应用的名称通过基于应用的命名服务来引用应用子上下文和对象。

现在参见图11A，这个方框图图解了用于被安装的Java应用的典型J2EE环境。Java应用模块1102需要使用作为另一个应用的一部分的应用功能或EJB。Java应用模块1102包括使用用于远程模块的本地引用名称针对查找功能的功能调用1104。当执行功能调用1104时，在Java运行时间环境1108内调用JNDI查找功能1106。对于各种配置描述符文件1110，诸如EJB配置描述符文件、应用配置描述符文件或某些其他类型的类似资源文件，查找功能1106能够将所提供的本地引用名称映射为基于布局的名称。Java应用模块1102通过恰当的API来使用基于布局的名称，以便获得对所需要的远程功能的访问。

图11B类似于图11A，除了图11B描述在数据处理系统内的本发明的一个实施例。在图11A和图11B中的类似的附图标号指的是类似的元件，由此图解：当典型的数据处理系统被修改以包括本发明的功能时，数据处理系统的某些方面保持不变。

J2EE规范定义了在应用开发和配置寿命周期中的几个不同的角色，例如应用开发器、企业bean提供器、应用汇编器和系统管理器。一般，所述角色被定义来帮助识别在J2EE应用的开发、配置和运行期间由不同方执行的任务。这些角色的一些执行对于非J2EE平台共同的任务，而其他角色具有对于J2EE平台特定的含义。可以通过无论什么人匹配一个组织的实际应用配置和配置工作流来实现所述角色。因此，每个J2EE角色可以被不同的人执行，或者单个人可以执行几个角色。例如，给定的编程者可以执行应用开发器和应用汇编器的角色。

因为可以在J2EE环境内实现本发明，因此上述的角色保持基本上不变。在图11B所示的示例中，不论应用是否将被配置在支持本发明的数据处理系统内，应用开发器以相同的方式来建立应用模块。例如，应用开发器可以建立EJB和各种应用模块，包括在配置描述符中的“ejb-ref”的规范；所述“ejb-ref”指定一个名称，例如，应用在其程序逻辑中使用来指示特定的EJB的“myHellop”。

同样，应用汇编器将各种模块捆扎到一个应用中；在这个过程期间，应用汇编器选择用于EJB的JNDI名称，例如“ejb/myHelloc”。应用汇编器指定所定义的“ejb-ref”被解析成的名称，这个名称表示在运行时间执行期间EJB需要使用的客户端模块。在现有技术中，所述被指定的名称将是基于布局的名称，诸如“cell/node/server/ejb/hellot”。相反，本发明允许诸如“cell/appl_name/vers_id/deploy_i/module/ejb/hello”的基于应用的名称的、如图11B所示的规范。

现在参见图11B，这个方框图图解了支持按照本发明的一个实施例的基于应用的命名服务的修改的J2EE环境。已经修改了在JNDI API 1108中的查找功能；已经扩展查找功能1120以包括对于基于应用的命名服务(ABNS)模块1122的支持。配置描述符文件1110包括对基于应用的名称的引用。另外，ABNS模块1122访问ABNS登记处1124，ABNS登记处1124包括在基于应用的名称和基于布局的名称之间的关联。当执行功能调用1104时，在Java运行时间环境1108内调用JNDI查找功能1120。对于各种配置描述符文件1110，诸如EJB配置描述符文件、应用配置描述符文件或某些其他类型的类似资源文件，查找功能1120能够向更全局的识别名称映射所提供的本地引用名称。

在本发明的一个实施例中，包括本发明的一种数据处理系统在资源文件中仅仅使用基于应用的名称。因此，当检索全局名称时，可以假定它是基于应用的名称，而不是基于布局的名称。在本发明的另一个实施例中，可以在资源文件中使用基于应用的名称和基于布局的名称。并且查找功能应该能够支持两种类型的名称。因此，当从文件检索名称时，也可以检索刻画所述名称的信息，诸如指示是否所检索的名称是基于应用的名称或基于布局的名称的相关联的数据类型标识符。

在任何情况下，查找功能1120依赖于ABNS模块1122，以便对基于应用的名称执行附加的处理，并且ABNS模块1122按照在ABNS登记处1124中的信息将基于应用的名称映射为基于布局的名称。Java应用模块1102通过恰当的API来使用返回的基于布局的名称，以便获得对于已经被识别的实体的访问，以例如用于调用远程对象。

参见图11C，这个方框图图解了一个修改的J2EE环境，它包括基于应用的命名服务，所述基于应用的命名服务具有对于按照本发明的实施例的带有别名的基于应用的名称的附加支持。在图11B和图11C中的类似的附图标号指的是类似的元件。图11C类似于图11B，只是图11C描述了本发明的一个实施例，用于支持带有别名的基于应用的名称，而在图11B中，被描述的系统不并入用于支持别名的概念的任何功能。

参见图11C，ABNS模块1130已经被扩展来包括用于将带有别名的基于应用的名称转换为不带有别名的基于应用的名称的功能，它被示出为带有别名的名称转换功能1132。ABNS登记处1134包括附加的信息，它们是在别名和不带有别名的基于应用的名称之间的关联。虽然ABNS登记处1134仍然包括在基于应用的名称和基于布局的名称之间的关联，但是在这些关联中的基于应用的名称被指定为不带别名的基于应用的名称。

当在图11C所示的系统中安装一个应用时，应用开发器和应用汇编器的角色再次保持基本上不变。但是，应用汇编器可以使用在配置描述符文件内的带有别名的基于应用的名称，诸如“cell/alias1/module/ejb/helloe”。在查找功能中解析使用带有别名的基于应用的名称、即使用别名作为基于应用的名称的一部分的含义，如参照图12更详细地所述。

现在参见图12，这个流程图描述了用于将带有别名的基于应用的名称转换为不带有别名的基于应用的名称的处理。图12所示的处理可以被假定为综合查找功能的一部分。

当一个程序实体——诸如图11C中的转换功能1132——获得基于应用的名称时，处理开始(步骤1202)。这个初始获得的基于应用的名称可以或可以不是带有别名的基于应用的名称，但是可以假定初始获得的基于应用的名称是具有用于多个上下文的多个名称的复合名。所述初始获得的基于应用的名称被处理以通过将作为复合名的其形式语法分析为它的组成原子名称来确定是否在其中包括任何别名(步骤1204)。换句话说，所述初始获得的基于应用的名称是包括用于多个上下文的多个子串的串，并且这些子串被标识。

然后确定这些组成原子名称之一是否已经事先被登记为别名(步骤1206)。在一个优选实施例中，仅仅在复合名内具有特定位置的某些原子名称具有成为别名的可能。如果如此的话，则检索事先与别名相关联的复合名(步骤1208)。如上所述，别名被定义为复合名，并且一个别名不能包括另一个别名。因此，当登记一个别名时，它与必须为不带有别名的基于应用的名称的复合名相关联。这个相关联的不带有别名的基于应用的名称替换在初始获得的基于应用的名称内的别名(步骤1210)，由此产生表示与初始获得的基于应用的名称相同的实体的扩展的不带有别名的基于应用的名称。所述扩展的不带有别名的基于应用的名称然后被返回调用实体(步骤1212)，并且结束处理。

如果没有在初始获得的基于应用的名称内的原子名称被登记为别名，则初始获得的基于应用的名称是不带有别名的基于应用的名称，并且控制逻辑从步骤1206向步骤1212转移以向初始获得的不带有别名的基于应用的名称返回所述调用实体，并且结束处理。

如上所述，J2EE规范限定了在应用开发和配置寿命周期中的几个不同角色。为了支持本发明的实现，由管理器角色执行的任务需要被增强以支持别名的登记，虽然这样的任务有可能被管理实用程序协助。图13图解了系统管理器可以通过使用带有别名的基于应用的名称来更容易地管理应用的方式。

现在参照图13A和13B，一对方框图图解了这样一种方式，它可以通过使用按照本发明的一个实施例实现的一种数据处理系统内的别名来管理一个应用的多个版本。图13A和13B提供了以类似于参照图11C所述的方式来使用别名的示例。

参见图13A，EJB客户端1302和1304通过JNDI来执行查找操作，所述JNDI已经通过增加用于具有带有别名的基于应用的名称支持1306的命名服务的功能来增强。一个数据存储库包括在别名和不带有别名的基于应用的名称之间的关联。图13A示出了将“aliasX”映射为“WebServ/vers”的应用1308和将“aliasZ”映射为“WebServ/vers2”的应用1302。与EJB客户端1302相关联的资源/描述符文件包括对于包括别名“aliasXv”的基于应用的名称的引用，与EJB客户端1302相关联的资源/描述符文件包括对包括别名“aliasZ”的基于应用的名称的引用。

在某个时间点，EJB客户端1302执行对于具有在应周内的本地引用名称的特定EJB的查找操作，所述特定EJB例如“myHelloe”，它在按照在各种类型的资源和描述符文件中的信息的查找操作期间部分地解析为带有别名的基于应用的名称“cell/aliases/alias/modules/hello.jar/ejb/helloo”。但是，暂时解析的名称是基于应用的名称，并且命名服务支持1306被调用来处理基于应用的名称，它发现所述基于应用的名称是带有别名的基于应用的名称。命名服务支持1306处理参照图12所述的这个基于应用的名称，并且在基于应用的名称内的别名“aliasX”被扩展以包括通过关联1308、即“WebServ/vers1j”而在数据存储库中提供的、用于“aliasX”的不带有别名的基于应用的名称。按照在数据存储库中的其他信息，被扩展的不带有别名的基于应用的名称然后被映射为基于布局的名称，例如其下存储所有应用相关联的文件的上下文，并且基于布局的名称被返回EJB客户端1302。

以类似的方式，在某个时间点，EJB客户端1304执行对于具有在应用内的本地引用名称的特定EJB的查找操作，所述特定EJB例如“myHellot”，它在按照在各种类型的资源和描述符文件中的信息的查找操作期间部分地解析为带有别名的基于应用的名称“cell/aliases/aliasZ/modules/hello.jar/ejb/hellon”。命名服务支持1306处理参照图12所述的这个基于应用的名称，并且在基于应用的名称内的别名“aliasZ”被扩展以包括通过关联1310即“WebServ/ver1”而在数据存储库中提供的、用于“aliasZ”的不带有别名的基于应用的名称。按照在数据存储库中的其他信息，被扩展的不带有别名的基于应用的名称然后被映射为基于布局的名称，例如其下存储所有应用相关联的文件的上下文，并且基于布局的名称被返回EJB客户端1304。因此，在图13A中，EJB客户端1302和1304将使用“WebServ”应用的同一版本。

现在参见图13B，与图13A相比较，由基于应用的命名服务支持所使用的数据存储库包括在别名和不带有别名的基于应用的名称之间的至少一个不同的关联；图13B示出了将“aliaZ”映射为“WebServ/ver2”的关联1312，而关联1308继续将“aliasX”映射为“WebServ/ver1”。因此在这个示例中，EJB客户端1302和1304使用“WebServ”应用的不同版本，即使资源/描述符文件保持不变也如此。仅仅支持基于应用的命名服务支持的数据存储库需要改变。图13B所示的示例可以表示“WebServ”应用的新版本的安装结果。作为安装程序的一部分，系统管理器改变在基于应用的命名服务的数据存储库内的信息，以便将一些实体转而使用更新的版本，这是对应用的源文件和资源/描述符文件透明地进行的。

当安装“WebServ”应用的多个实例时可以实现类似的效率。假定如在图13B所示的示例中那样、配置属性指的是一个应用的实例而不是一个应用的版本，则可以动态地修改别名以将各种客户端应用转为“WebServ”应用的不同实例。例如，别名“aliasX”和“aliasZ”可以初始地解析为应用的第一实例，但是在安装应用的第二实例后，可以数据存储库中修改与“aliasZ”相关联的不带有别名的基于应用的名称，以便映射到应用的第二实例，则也是对于应用的源文件和资源/描述符文件透明地进行的。

与安装应用的多个版本和应用的多个实例相比较，应用文件的移动更为简单。例如，当从一个服务器向另一个服务器移动一个应用的一个实例时，用于应用文件的位置的基于布局的名称也改变。使用按照本发明的一个实施例的基于应用的名称，需要最小数量的重新配置，对于在基于应用的命名服务的数据存储库内的那些应用文件的基于布局的名称的引用被改变。虽然当从一个服务器向另一个服务器移动应用时在支持应用文件的存储的文件系统中的基于布局的名称改变，但是基于应用的名称可以保持不变，由此使得可以在一组服务器中更有效地移动应用，以用于例如负荷平衡的目的或其他目的。在分布式数据处理系统内移动一个应用而不需要对与被移动的应用相关联的基于应用的名称的更新的能力导致极大增强的效率。

重要的是，当已经在全功能数据处理系统的上下文中描述了本发明的同时，本领域内的普通技术人员将明白本发明的处理能够以指令的形式被发布在计算机可读介质中和以多种其他形式来发布，与实际用于执行发布的信号承载媒体的具体类型无关。计算机可读媒体的示例包括诸如EPROM、ROM、带、纸、软盘、硬盘驱动器、RAM和CD-ROM的媒体、诸如数字和模拟通信链路的传送型媒体。

一种方法一般被设想为导致期望结果的、前后一致的一系列步骤。这些步骤需要物理量的物理控制。通常——但不是必定，这些量采取能够被存储、传送、组合、比较和控制的电或磁信号的形式。有时方便的是，主要因为共同使用的原因，将这些信号表示为比特、值、参数、项目、元素、对象、符号、字符、术语、数等。但是，应当明白，所有这些术语和类似的术语与恰当的物理量相关联，并且仅仅是被应用到这些量的方便标签。

本发明的说明已经为了说明的目的被给出，但是不打算穷尽或限制所公开的实施例。对于本领域内的普通技术人员，许多修改和改变是显然的。所述实施例被选择来用于说明本发明的原理及其实际应用，并且用于使得本领域内的其他技术人员能够明白本发明，以便实现可能适合于其他所考虑的用途的、具有各种修改的各种实施例。

Claims

1.一种用于管理在数据处理系统内的应用文件的方法，所述方法包括：

登记一个别名，其中所述别名表示第一复合名，该第一复合名包括与一个应用相关联的应用名称和与一个配置属性相关联的配置名称，所述配置名称刻画所述应用的一个实例的配置；

产生与一个应用相关联的基于应用的名称，其中所述基于应用的名称表示在一个命名系统内的上下文，其中基于应用的名称是包括所述别名的第二复合名；并且

使用所述基于应用的名称来管理在数据处理系统内的一个应用。

2.按照权利要求1的方法，其中，配置属性是元数据值，它刻画在分布式数据处理系统内配置应用的实例的方式。

3.按照权利要求1的方法，其中，所述别名表示应用名称和与多个配置属性相关联的多个配置名称。

4.按照权利要求1的方法，其中，登记别名的步骤还包括：

将所述别名与包括应用名称和配置名称的第一复合名相关联；并且

在一个数据存储库中存储所述别名与第一复合名的关联。

5.按照权利要求4的方法，还包括：

将第一复合名与第一基于布局的名称相关联，其中第一基于布局的名称表示第一上下文，用于组织与所述应用的实例相关联的文件。

6.按照权利要求4的方法，还包括：

移动与应用的实例相关联的文件；并且

将第一复合名与第二基于布局的名称相关联，其中第二基于布局的名称表示第二上下文，用于组织与应用的实例相关联的文件。

7.按照权利要求1的方法，还包括：

在数据处理系统内安装应用的多个版本；并且

登记所述应用的每个版本的别名。

8.按照权利要求1的方法，还包括：

在数据处理系统内安装应用的多个实例；并且

登记用于应用的每个实例的别名。

9.一种在计算机可读介质中的计算机程序产品，用于管理在数据处理系统内的应用文件，所述计算机程序产品包括：

用于登记一个别名的部件，其中所述别名表示第一复合名，第一复合名包括与一个应用相关联的应用名称和与一个配置属性相关联的配置名称，所述配置名称刻画所述应用的一个实例的配置；

用于产生与一个应用相关联的基于应用的名称的部件，其中所述基于应用的名称表示在一个命名系统内的上下文，其中基于应用的名称是包括所述别名的第二复合名；和

用于使用所述基于应用的名称来管理在数据处理系统内的一个应用的部件。

10.按照权利要求9的计算机程序产品，其中，配置属性是元数据值，它刻画在分布式数据处理系统内配置应用的实例的方式。

11.按照权利要求9的计算机程序产品，其中，所述别名表示应用名称和与多个配置属性相关联的多个配置名称。

12.按照权利要求9的计算机程序产品，其中，用于登记别名的部件还包括：

用于将所述别名与包括应用名称和配置名称的第一复合名相关联的部件；和

用于在一个数据存储库中存储所述别名与第一复合名的关联的部件。

13.按照权利要求12的计算机程序产品，还包括：

用于将第一复合名与第一基于布局的名称相关联的部件，其中第一基于布局的名称表示第一上下文，用于组织与所述应用的实例相关联的文件。

14.按照权利要求12的计算机程序产品，还包括：

用于移动与应用的实例相关联的文件的部件；和

用于将第一复合名与第二基于布局的名称相关联的部件，其中第二基于布局的名称表示第二上下文，用于组织与应用的实例相关联的文件。

15.按照权利要求9的计算机程序产品，还包括：

用于在数据处理系统内安装应用的多个版本的部件；和

用于登记所述应用的每个版本的别名的部件。

16.按照权利要求9的计算机程序产品，还包括：

用于在数据处理系统内安装应用的多个实例的部件；和

用于登记用于应用的每个实例的别名的部件。

17.一种用于管理在数据处理系统内的应用文件的装置，所述装置包括：

18.按照权利要求17的装置，其中，配置属性是元数据值，它刻画在分布式数据处理系统内配置应用的实例的方式。

19.按照权利要求17的装置，其中，所述别名表示应用名称和与多个配置属性相关联的多个配置名称。

20.按照权利要求17的装置，其中，用于登记别名的部件还包括：

21.按照权利要求20的装置，还包括：

22.按照权利要求20的装置，还包括：

用于移动与应用的实例相关联的文件的部件；和

23.按照权利要求17的装置，还包括：

用于在数据处理系统内安装应用的多个版本的部件；和

用于登记所述应用的每个版本的别名的部件。

24.按照权利要求17的装置，还包括：

用于在数据处理系统内安装应用的多个实例的部件；和

用于登记用于应用的每个实例的别名的部件。