用于应用配置的智能目录的方法和设备 优先权要求
本申请要求于2001年9月21日提交的名为“用于应用配置的智能目录的方法和设备”的美国专利申请第09/960529号的优先权，该申请作为参考引用。
【技术领域】
本发明涉及经由分布式计算环境自动配置(deploy)、去配置(undeploy)和重新配置(redeploy)应用和应用成分。
背景技术
分布式计算环境包括一组协调工作以提供各种计算业务的连网计算机。在这种类型的计算环境中，软件应用被分成许多应用成分。这些成分被分布在位于一个或多个连网计算机的服务器应用上，使不同成分被分布式环境内的不同服务器应用运行。应用成分被设计成有效工作于分布式环境中。设计用于分布式计算环境的应用的优点包括：增加适应大量用户的可伸缩性，增加可靠性以及有效使用计算资源。
分布式计算环境的一个实例是由Sun Microsystems开发的Java
TM平台企业版(J2EE)基础结构。J2EE应用主要由企业Java
TM Beans(EJB)组成，它是按Java
TM编程语言编写的可重用的应用成分。Java
TM2平台企业版规范v1.3中记载了J2EE基础结构的规范，所述规范可通过网址
http：//java.sun.com/i2ee/j2ee-1 3-pfd4-spec.pdf得到，在此引用该规范以资参考。
在J2EE基础结构中，应用成分是在安装于分布式计算环境中的每个计算机上的一个应用服务器程序内运行的。应用的应用成分可以被分散到分布式计算环境内的许多应用服务器上，也可以集中到单一应用服务器内。
J2EE应用服务器程序提供在分布式编程环境中应用成分所需的低级功能。J2EE应用服务器程序提供的功能包括：启动分布式应用成分之间的通信，以及启动位于分布式计算机环境内或者该环境外的不同应用之间的通信。应用服务器处理系统资源、线程、存储器、数据库连接、安全性、客户机连接以及事务管理。应用服务器还管理J2EE应用的安装和删除。这包括把多个应用成分分布到分布式计算环境中的多个应用服务器上。通过把这些功能集成到应用服务器上，J2EE平台允许应用开发商集中实施应用的商业逻辑，而不是分布式应用所需的低级功能。
尽管设计J2EE应用平台是为了消除许多与开发分布式应用关联的复杂性，但是借助该程序设计范例的软件开发仍然是复杂和困难的。与J2EE应用的开发关联的困难之一是配置问题。配置是安装各种应用成分的处理，该应用成分包括分布式计算环境内应用服务器上的应用。J2EE应用结构的一个实例有助于理解与配置J2EE应用关联的复杂性。
图1显示了全打包的J2EE应用的典型结构。这种形式的J2EE应用准备安装在分布式计算环境中。打包的J2EE应用被并入企业应用文档文件(EAR)100中。.EAR文件包含J2EE应用107和J2EE应用配置说明符(DD)105。J2EE应用107包括一个或多个应用成分。这些应用成分可以是企业Java
TMBean111、110和112；J2EE客户机应用120、121和122；或者Web成分130、131和132。配置说明符105是说明J2EE应用的属性(比如事务属性或者安全认证)的文件。再一个实施例中，用可扩充标记语言，即广泛用于描述信息的语言对配置说明符编码。附加配置说明符可以用来描述J2EE应用的各个成分。
企业Java
TM Beans(EJB)被容置在Java
TM文档(.JAR)文件中，如标记110的具体显示。.JAR文件把多个文件一起捆绑在单一文档文件中。通常，.JAR文件包含Java
TM.class文件和与应用成分关联的辅助资源。对于EJB，.JAR文件包含EJB配置说明符113、一个或多个EJB.class文件115以及EJB应用成分115所需的辅助资源。.class文件包含实施EJB操作所需的软件码。EJB配置说明符113描述了EJB.class文件和关联的资源115的属性。类似于J2EE应用配置描述符，EJB配置说明符也可以被编码为.XML文件。J2EE应用可以包含任何数量的EJB.JAR文件，如图1所示的三个EJB.jar文件110、111和112仅仅用于图示说明，它既不打算成为上限也不打算成为下限。
J2EE应用107还可以包含J2EE客户应用120、121和122。J2EE客户应用在用户计算机上执行功能，并向J2EE应用提供接口。J2EE应用可以包含任何数量的J2EE客户应用文件，或者作为选择，不包含该J2EE客户应用文件。类似企业Java
TM Beans，这些应用成分还可以包含于.JAR文件中。如图1的.JAR文件120所示，J2EE客户应用包括J2EE客户应用125和J2EE客户应用配置说明符123。J2EE客户应用由一个或多个J2EE.class文件组成，J2EE.class文件包含实施J2EE客户应用功能的Java
TM码。Java
TM客户应用还可以包含J2EE客户应用所需的辅助资源。J2EE客户应用配置说明符123详细描述了J2EE客户应用125的属性。
J2EE应用107还包括一个或多个web成分。web成分是J2EE应用用来与web客户通信的服务器方对象。这些对象处理web用户请求，并响应该请求产生用户的静态和动态内容。例如，web成分允许J2EE应用显示用于每个用户的专用web页。
web成分被容置在.WAR文件130、131和132中。如文件130中的详细描述，.WAR文件包含web成分135和web成分配置说明符133。web成分说明符133是描述web成分的..XML文件。web成分的实例包括Java
TM服务器页(.JSP)文件、Java
TM sevlet.class文件、超文本标记语言文件(HTML)文件或者图形交换格式(GIF)文件。
配置J2EE应用需要若干步骤。首先用户必需把大量应用成分之每个(比如图1中公开的应用成分)打包成JAR文件或者.WAR文件。把每个应用成分打包成一个独立文件之后，用户必需把应用成分文件装配成单一的J2EE应用(.EAR)文件。一旦完全打包的J2EE应用文件被建立时，用户就可以把整个.EAR文件安装到使用软件应用的J2EE应用服务器上。该应用需要用户人工地选择待配置的J2EE应用以及应用服务器或者配置该应用的服务器。
把应用成分打包成.JAR或者.WAR文件，任何再打包成.EAR文件的处理可能非常耗费时间。大J2EE应用可能具有500种以上不同应用成分，在配置应用之间，需要把这些成分装配到一个.EAR文件中。如果软件开发商即使修改这些应用成分的一个，就必需重复打包.EAR文件的整个处理。另外打包处理对于小应用可能是浪费地。如果J2EE应用仅包含单一应用成分，则首先在把该单一应用成分打包到.JAR文件中。然后再把所得到的.JAR文件再打包到.EAR文件中。单一应用成分的这一双重打包浪费了软件开发商的时间并且不能提供配置J2EE应用的优势。
由于在分布式计算环境中配置J2EE应用包含一系列复杂的打包和分配步骤，因此配置新应用是软件管理员的一项困难任务。软件管理员必需使用独立软件应用人工地指定将要配置应用的应用服务器，然后再人工地启动配置处理。只要软件管理员希望配置应用的修订或者更新的版本，就必需重复该处理。此外，软件管理员必需人工地去配置来自应用服务器的旧应用。
对于软件开发商，复杂的应用配置处理妨碍了软件开发。在软件开发中，开发商也许必需经常改变应用资源码，在每次改变之后，开发商必需重复相同的费力的配置处理，以便在开发中测试该应用。这明显增加了在开发J2EE应用中的时间和困难。
因此，希望有一个具有以下条件的分布式计算环境：1)向分布式计算环境中的一个或多个计算机自动地配置新的或已更新的应用，2)自动地去配置来自分布式计算环境中的一个或多个计算机的不需要或者过时的应用；3)向分布式计算环境中的一个或多个计算机自动地配置应用成分，而又不需要多余的打包步骤。
【发明内容】
根据本发明，通常采用一个分布式计算环境执行自动配置分布式计算环境中的应用的方法。该分布式计算环境可以包括单个计算机或者多个计算机。每个计算机可以包含一个或多个用于执行应用或者应用成分的应用服务器。该方法的实施例自动地扫描应用目录以查找去配置应用的位置。该方法在应用目录中识别一个去配置应用，并把该应用配置给分布式计算环境中的至少一个应用服务器。
再一个实施例中，该方法扫描应用目录以获得存储在应用目录中的所有应用的列表。然后该实施例将应用的列表与在前配置的应用列表进行比较，以便选择待配置的应用。
在另一个实施例中，该方法通过检查与应用关联的配置指示符来识别已修改的应用。配置指示符可以是包含应用的文件的属性，或者作为选择，是一个与包含应用的文件分离的一个文件的属性。已修改的应用被重新配置给分布式计算环境中的至少一个计算机。
在一个实施例中，该方法扫描应用目录以获得存储在应用目录中的所有应用的列表。该实施例然后将该应用列表与先前配置的应用进行比较。从分布式计算环境中去配置不存在于应用目录中的在前配置应用。
从下面的附图、详细说明以及权利要求可以理解本发明的其它实施例和优点。
【附图说明】
下面将参照附图说明本发明。
图1示出了全打包的J2EE应用的结构；
图2示出了利用本发明实施例的分布式计算环境；
图3示出了本发明的方法的一个实施例。
参考附图和下面的详细说明将会更好地理解本发明。在附图中，相同的参考标记指示相同的部件。
【具体实施方式】
本发明通过按需配置和去配置应用和应用成分，解决现有分布式计算环境的缺点。本发明的实施例通过使用应用通晓文件目录(application savvy filedirectory)或者目录集实现这些目的。这些应用通晓目录被称之为智能目录，是一个分布式计算环境中目前配置的应用和应用成分的拷贝储存库。类似于普通文件目录，智能目录被利用来组织数据存储器上的信息文件，比如与应用或者应用成分关联的文件。此外，智能目录可以被堆放在其它智能目录之内。尽管可以使用多个智能目录，但是本发明的实施例只需要分布式计算机环境下的单一智能目录。
在一个实施例中，智能目录与分布式计算环境内的至少一个计算机通信。这能够启动分布式计算环境中的服务器程序以监视智能目录的新应用文件。一旦检测到智能目录中的新应用文件，分布式计算环境就自动地配置与该新文件关联的应用或应用成分。智能目录还自动检测现存文件的删除，并且去配置与删除的文件关联的应用或应用成分。最后，智能目录检测具有文件较新版本的现存文件的替换，并自动地重新配置与该文件的新版本关联的应用或应用成分。这能够使用户通过简单地增加、删除或更新智能目录中的应用文件来改变分布式应用的配置，而不执行一系列显式配置步骤。
本发明的一个实例实施例被用来在J2EE基础结构定义的分布式计算环境内进行操作。在该实施例中，智能目录与J2EE分布式计算环境中的至少一个应用服务器进行通信。该智能目录包含与配置在J2EE分布式计算环境中任何一个应用服务器上的所有J2EE应用相关联的文件。当增加、消除或者更新智能目录中相应应用文件时，该实施例自动地配置、去配置和重新配置J2EE应用。
在本发明的该实施例的再一个变化中，智能目录能够把J2EE应用和应用成分配置给应用服务器，而不需要显式打包步骤。智能目录可以配置被分离成它的组成文件的J2EE应用，而不是配置被打包为J2EE..EAR文件的J2EE应用。这些文件可以包括J2EE客户应用。.JAR文件、EJB..JAR文件和web成分.WAR文件。配置未打包文件的这一能力还扩展到J2EE应用成分文件。.JAR和.WAR由捆绑在一起的许多文件组成，智能目录可以配置多个应用成分，它们被分离成诸多组成文件，比如.class文件、.GIF文件、.XML文件、.HTML文件或者与应用成分关联的其它类型的文件。
智能目录允许用户通过与它们的被打包对应物类似的方式配置未打包的J2EE应用和应用成分。用户仅增加、删除或修改智能目录中的未打包文件。然后智能目录配置、去配置或重新配置应用成分响应。在一个实施例中，每个应用或应用成分的所有组成文件包含于分离目录或子目录内。这可以使用户更容易地识别与每个应用或者应用成分相关联的文件组。用户还能够容易地管理与应用或应用成分关联的文件，而不需要分布其它应用或应用成分。分离的目录或子目录也是智能目录。在一个实施例中，在智能目录内建立的任何子目录也被自动地当作一个智能目录。
图2显示了组成本发明一个实施例的分布式计算环境。分布式计算环境200包括多个计算机210、220、230和240。所示的4个计算机用于说明的目的。分布式计算环境可以包括单个计算机至任何数量的计算机。每个计算机包括工作于分布式计算环境中所需的基础硬件和软件，包括一个或多个处理装置、存储装置、数据存储装置、通信装置和任何有关的软件。分布式计算环境中的这些硬件和软件成分的使用是本领域公知技术。尽管未在图2显示，但是分布式计算环境200可以包括与诸多外部系统交换信息的通信连接，这些外部系统例如是客户计算机、数据库和其它企业系统、监视系统以及数据存储系统。
分布式计算环境中的所有计算机彼此经由通信链路250通信。通信链路250可以是计算机网络，比如局域网或者广域网，通信链路250可以利用能够承载信息的任何类型的通信技术。图1所示的包括通信链路250的通信连接的数量和安排仅用于说明目的，通信链路250可以按照本领域中连接计算机的已知技术的任何合适方式进行配置。
计算机210包含服务器程序212和214。这些服务器程序之每个能够独立地运行一个或多个分布式应用或应用成分。图2所示的服务器程序212和214用于说明目的，计算机210可以包含单个服务器程序至任何数量的服务器程序。同样，计算机230和240分别包含服务器程序232、234、242和244。在一个实施例中，每个服务器程序是能够运行一个或多个J2EE应用或应用成分的J2EE应用服务器。
计算机220包含管理(Admin)服务器程序225。管理服务器225监控分布式应用或者应用成分的配置、去配置和重新配置。在一个实施例中，单个管理服务器225执行用于整个分布式计算环境200的功能。计算机220还可以包含图2中未示出的其它程序。在一个实施例中，计算机220包含一个管理服务器225以及一个或多个服务器程序如以上讨论的程序。
计算机220还与应用存储器223通信。应用存储器223是能够存储和检索与应用和应用成分关联的存储装置。管理服务器225能够存取应用存储器223的内容，以便配置、去配置或者重新配置应用或应用成分。应用存储器223还可以经由计算机220或者经由分布式计算环境中的其它计算机访问用户。在一个实施例中，应用存储器223是与计算机220通信的通用存储装置的一部分。
在一个实施例中，与应用和应用成分关联的文件被存储到位于应用存储器223上的一个或多个智能目录中。智能目录被实施为一个或多个标准文件目录，类似于连接通用存储装置所利用的那些目录。智能目录包含与在分布式计算环境中配置的应用和应用成分相关联的每个文件的拷贝。管理服务器225监视智能目录的内容，以便处理应用和应用成分的配置、去配置和重新配置。
图3显示了管理服务器225使用的监视处理300的实施例。在该实施例中，管理服务器225以周期间隔检查智能目录的内容。该检查开始于步骤305，首先检索所有智能目录的列表。在一个实施例中，该列表从用户供应的指定为智能目录的文件目录生成。作为选择，可以通过管理服务器225的初始配置预先确定一个或多个智能目录。另一个实施例可以把智能目录内的子目录自动指定为智能目录本身。在该实施例中，管理服务器225递归地扫描每个智能目录以查找所有子目录的位置，所以，步骤305中的目录列表将包括智能目录和所有它们的子目录。
在步骤310，管理服务器225从目录列表中选择下一个目录。步骤310是管理服务器225为目录列表的每个目录重复的处理环路中的第一步。如果这是管理服务器225经由该环路的首次重复，则管理服务器225将从目录列表中选择第一目录。反之，管理服务器225将从该列表选择下一个目录。目录列表上的目录可以按照管理服务器225处理和最终选择目录列表上的所有目录而提供的任何顺序来安排。在一个实施例中，目录列表的目录可以被安排成最佳化操作速度、存储器使用、对应用存储器223的存取。
管理服务器225在步骤315检索被定位在所选择目录内的所有文件的列表。文件列表可以包括与完整的应用或应用成分关联的文件。在一个实施例中，文件可以包含完整的J2EE应用，或者作为打包.EAR文件，或者被分离成用于J2EE应用的每个应用成分的各个文件。应用文件可以被打包为.JAR或者.WAR文件，或者可以被进一步分离成各个文件，比如Java
TM.class文件、.xml配置说明符、.HTMI文件、.GIF图像文件、.JSP Java
TM服务器页文件或者其它类型的与分布式计算环境中的应用成分的配置关联的文件。在未打包的应用或应用成分文件的情况下，管理服务器225的实施例将假设子目录中的所有未打包文件都与公共应用或者应用成分相关联。
在步骤320，管理服务器225从文件列表选择下一个文件。步骤320是管理服务器225为文件列表上的每个文件重复的处理环路中的第一步。如果这是管理服务器225经由该环路的首次重复，则管理服务器225将从文件列表中选择第一文件。反之，管理服务器225将从文件列表选择下一个文件。文件列表上的目录可以按照管理服务器225处理和最终选择文件列表上的所有文件而提供的任何顺序来安排。在一个实施例中，文件列表的文件可以被安排成最佳化操作速度、存储器或对应用存储器223的存取。
在步骤330，管理服务器225将所选择的文件与内部维护的管理器列表进行比较。管理列表是与在分布式计算环境200中当前配置的应用和应用成分关联的所有文件的列表。在一个实施例中，在应用和应用成分的配置期间，按照管理服务器225的在前迭代构成管理列表。下面将对此进行更详细的讨论。如果管理列表上没有文件，则没有当前配置在分布式计算环境200中的应用和应用成分。
管理服务器225检查管理列表，以确定所选择的文件是否已经在管理文件上。管理列表缺少所选择的文件，则表示去配置与所选择文件关联的应用或者应用成分。然后，由步骤333完成与所选择的文件关联的应用和应用成分关联的配置。配置处理将在下文中进行详述。此外，在配置成功完成之后，步骤333将所选择的文件添加到管理列表上。按此方式，创建和更新管理列表。
如果如果所选择的文件已经被定位于管理列表上(步骤330)，则在步骤335，管理服务器确定所选择的文件是否包含依据在前配置的版本修改的应用或应用成分。该确定可以通过任何通常使用的识别软件或者软件成分的版本的方法，比如版本号的使用、文件检验和或者其它识别方法来完成。该识别所需的信息可以被存储到管理列表上。如果已经依据管理列表上的副本修改了所选择的文件，则可以在步骤338重新配置与选择的文件相关联的应用或应用成分(下文进行更详细讨论)。如果来自管理列表的信息用来识别已修改的文件，则在成功完成重新配置之后更新概信息。这样，用已配置的应用和应用成分的最新版本更新管理列表。
在一个实施例中，管理列表不仅包含与在前配置的应用和应用成分相关联的文件的名称，而且还包含每个文件的日期。在许多公共文件系统中，每个文件具有相应的只要文件被更新就修改的日期。在此实施例中，管理服务器225将所选择文件上的日期与管理列表上存储的相应文件的日期进行比较。比管理列表上日期副本新的所选择文件的日期指示与所选择文件关联的应用或应用成分已经被更新，因为需要配置和重新配置应用或者应用成分。在步骤338中执行重新配置。
如果需要，在配置和重新配置与所选择文件关联的应用或者应用成分之后(在步骤340)，则管理服务器225检验是否存在保存在还没有选择的文件列表上的任何文件。重复步骤320至340，用于从文件列表中得到每个未选择的文件。如果已经从文件列表中选择了所有文件，则管理服务器225在步骤345检查管理列表。管理服务器225确定其副本正从所选择目录的文件列表中失掉的管理列表的文件。这表明与应用或应用成分关联的文件已经从智能目录中删除。所以，将从分布式计算环境200中去配置对应的应用或应用成分。在步骤348上完成与管理列表的文件关联并且不在文件列表上的所有应用或应用成分的去配置(下文将进行更详细讨论)。在应用或应用成分的成功去配置之后，从管理列表中删除所选择的文件。
在任选去配置应用或应用成分之后，管理服务器225检验目录列表上是否存在任何在前未选择的目录(步骤350)。重复步骤310至350，以用于目录列表上的每个未选择的目录。如果没有剩余更多的选择的目录，则管理服务器225在开始再进行监视处理之前，等候一个时间周期(步骤355)。在一个实施例中，该时间周期为3秒钟。
配置333和重新配置338的步骤能够使应用或者应用成分操作分布式计算环境200中的一个或多个服务器程序。尽管这些处理的具体细节将根据分布式计算环境的基础结构而改变，但是一般来说，对服务器程序的配置和重新配置需要，待存储到关联于服务器程序的存储器中以及待配置来在分布式计算环境中操作的应用或应用成分。去配置步骤348通常是配置处理的逆过程。由于本发明实施例是针对配置或去配置应用和应用成分的自动选择，而不是配置处理本身，该实施例的操作基本上不改变处理的细节，无论分布式计算环境是何种类型。
在适合于J2EE分布式计算环境的本发明实施例中，配置可以包括企业Java
TM Beans或者Java
TM服务器页的附加编译、安全配置、事务处理、操作环境、应用成分所谓注册以及具有JNDI命名业务的资源。Java
TM命名和目录接口(JNDI)是定位Java
TM对象的标准Java
TM语言扩展。在J2EE分布式环境的一个实施例中，应用服务器通过HTTP请求，请求待配置的应用或应用成分。Java
TM servlet接收该请求，并用特定的应用或应用成分进行响应。
在适合于J2EE分布式计算环境的本发明再一个实施例中，与管理服务器225通信的配置文件存储关于整个分布式计算环境200的信息，包括关于分布式计算环境200中的每个计算机、应用服务器、应用、应用成分以及其它可管理实体的信息。该配置文件还包括把应用和应用成分分布到分布式计算环境200内不同应用服务器的信息。分布式计算环境200内的应用和应用成分的分布可以通过每个应用服务器的资源和能力来确定。根据配置信息把应用和应用成分配置给不同的应用服务器。
配置文件的一个实施例是XML数据文件。该文件存储分布式计算环境的配置信息，以作为一系列XML数据标记。在一个实施例中，用户可以人工地创建该配置信息。配置文件包括用于分布式计算环境中每个应用的XML数据标记。每个应用XML数据标记包含一系列XML标记，该XML标记对应于与应用关联的每个应用成分。这些应用XML标记指明将要被配置的相应应用成分。每个应用成分XML标记可以指定分布式计算环境中的特定应用服务器、一组应用服务器或者每个应用服务器。
作为XML配置文件使用的一个实例，将详细讨论以下样本应用XML标记。
<Application Name＝“Foo”URL＝“somepath”>
<EJBComponent Name＝“bar”URI＝“BAR.JAR”
Targets＝“MyServer”/>
<WebAppComponent Name＝“baz”URI＝“baz.jar”
Targets＝“MyDomain”/>
</Application>
样本应用的应用XML标记称作“Foo”。应用XML数据开始于标记<Application>并结束于标记</Application>。<Application>标记还包括被设置成“Foo”的“名称”属性。该标记中可以包含其它属性，比如指定“Foo”应用的位置的“URI”。在两个<Application>标记之间是应用成分XML标记。第一应用成分是<EJBComponent>。该XML标记指明与名为“bar”的“Foo”关联的EJB应用成分。根据它的应用成分XML标记属性，“bar”应用成分包含于“bar.jar”文件，并且将被配置在应用服务器“MyServer”上。同样，第二应用成分XML标记指明包含在文件“baz.jar”中的web成分“baz”。对于该应用，把“Target”属性设置到“MyDomian”指明将成为整个分布式计算环境的该成分的配置目标。
一旦管理服务器225开始激活，管理服务器225把配置文件中描述的每个实体转换成一个MBean。一个MBean是一个服从Java
TM管理扩展(JMX)标准的企业Java
TM Bran。Java
TM管理扩展标准的规范位于
http：//java.sun.com/aboutJava/communityprocess/final/final/jsr003/index.htma，在此作为参考引用。在该实施例中，通过MBean的使用处理应用和应用成分的配置、重新配置以及去配置。在应用和应用成分的配置期间，管理服务器225搜索代表当前已选择文件的MBean。在一个实施例中，通过JNDI兼容命名服务进行该搜索。如果管理服务器225发现一个与应用或应用成分关联的文件的MBean，则把应用或应用成分配置到由MBean指定的应用服务器上。如果没有发现MBean，则创建新MBean并将应用或应用成分配置在由配置文件指定的应用服务器上。
打包文件比如.JAR文件、.EAR文件或.WAR文件，或者未打包文件比如类别、.XML、.HTML或.JSP文件，可以利用图3所示的实施例。在配置或重新配置未打包文件中，管理服务器225必须有意地配置不完全的应用或应程序成分。在创建或修改应用或应用成分中，软件开发商可能经常修改一些不同的源文件，以便实现必需的变化。当完成文件之一的所需变化时，将立即变更该文件的日期，将发信号通知管理服务器225与该文件关联的应用或者应用成分已准备好配置。然而，可以不完成对其它的关联于应用或应用成分的所需改变。配置此时与这些文件关联的应用或应用成分将导致不完全的配置。该不完全配置至少浪费系统资源。不完全配置还可能造成更严重的后果，比如系统故障和数据恶化。
为了避免不完全应用或应用成分的非故意配置，本发明的再一个实施例处理与打包文件不同的未打包文件的配置。不完全配置对于打包文件是不可能的，因为打包步骤出现在所有源文件的创建或者修改完成之后。因此，在该实施例中，根据结合图3讨论的处理，配置与打包文件关联的应用成分。
至于未打包文件，延迟配置和重新配置处理直至用户设置配置对象。配置对象发信号告知管理服务器225，与新的或修改的文件相关联的所有应用和应用成分已经准备去配置或重新配置。在一个实施例中，配置对象可以是一个分离的文件。在一个实施例中，文件具有管理服务器225已知的预定名称。管理服务器225监视配置对象的属性。该属性可以是文件的特性或者其内容。通过修改配置对象的属性，用户向管理服务器225指示与应用或应用成分关联的文件的创建或修改已经完成，并且准备配置应用或应用成分。
在一个实施例中，配置对象是一个空文件和零文件，所监视的属性是与该零文件关联的日期。用户通过更新该零文件上的日期，指示应用或应用成分已经准备配置。在许多操作系统中，这可以用“touch”命令完成。一旦更新了配置对象，管理服务器225就将配置与新的或新近修改的未打包文件关联的应用和应用成分。
对于未打包文件，按以下方式修改结合图3讨论的处理。如果管理服务器225确定应当在步骤330配置所选择的文件，则在步骤333，管理服务器225首先确定所选择的文件是一个打包文件还是一个未打包文件。一个实施例检查进行该确定的所选择文件的扩展。在J2EE应用的采用的实施例中，打包文件具有文件扩展，比如.EAR、.JAR和.WAR。其它文件扩展也可用于打包文件。
如果所选择的文件不是打包文件，则管理服务器225检查配置对象。如果用户未更新配置对象，则绕过配置处理并且去配置与所选择文件关联的应用或应用成分。相反，如果配置对象已经被更新，则由管理服务器225配置与所选择文件关联的应用或应用成分。
未打包应用和应用成分的配置、去配置和重新配置按照与它们的打包副本的相同方式进行。在一个实施例中，一旦管理服务器225已经确定一个未打包应用或应用成分已经准备去配置，则管理服务器225可以自动地把与应用或应用成分相关联的所有文件打包成打包文件，然后将其分布到服务器程序上。用户不需参与该自动打包处理，从而方便了对服务器程序的分配。
本发明优选实施例的上述说明用于解释和说明的目的，而不是用于穷举或者把本发明限制到所公开的精确形式。显然，本领域熟练技术人员将会明白许多修改和变化。选择和说明实施例是为了最好地解释本发明的原理以及其实际应用，从而使本领域熟练技术人员能够理解适合于预期使用的各种实施例以及具有各种修改的本发明。本发明的范围由以下权利要求和它们的等同物定义。