• 完全自动化的过程：过程应该以完全自动化的方式运行。该过程启动之后，应该不需要人工干预。如果域已建立，所有托管服务器均已启动，而且所有应用程序均已成功部署，这个过程就会成功终止。
• 单个配置文件：应该有单个配置文件用于控制目标域的属性。因为过程被分为一些单独的步骤，而且每个步骤都使用各种脚本和配置文件，该要求保证了过程的灵活性，使该过程适用于不同的机器和不同的域配置。
• 平台独立性：这种方法应该尽可能做到与平台无关。第一个版本是在HP-UX上的客户项目中开发的，然而，客户可能想在所需平台的列表中加入Windows和Linux。
• 独立的域：解决方案必须为WebLogic Server域提供独立性。不同的开发和测试团队可以共享一组机器。每个团队都需要独立地控制其WebLogic Server域。结果，域之间不能共享任何WebLogic Server资源。因此，每个域必须有一个单独的节点管理器；否则，节点管理器配置中的修改将会影响到其他域。

　　稍后，我们将在本文中讲述所提出的解决方案是如何满足这些要求的。让我们看一看过程本身。

过程概述
　　自动化过程由6个步骤组成。在第一步中，我们需要形式最简单的WebLogic Server域（即一个仅包含一台管理服务器的非集群化服务器域），而且我们需要启动这个域的Adimin Server。在第二步中，我们将这个域扩展到一个由我们的Admin Server所管理的WebLogic Server集群。我们还需要配置机器和节点管理器。第三步将配置所有必需的WebLogic Server服务，比如JMS和JDBC资源，以及其他的域配置设置。在第四步中，我们将把应用程序的发布文件复制到其目标目录中。在第五步中，我们将启动集群的节点管理器和托管服务器。最后，我们将部署并激活应用程序。图1示例了该方法的6个独立步骤。

图1：组成用于构建和启动一个集群化WebLogic Server域的完全自动化过程的6个步骤

　　BEA WebLogic产品包含对开发和管理提供支持的许多工具，比如WebLogic Workshop、WebLogic Builder和Domain Configuration Wizard。然而，对于把应用程序构建为具有完全功能的并可运行WebLogic Server域，这些工具都不支持进行基于脚本的自动化转换。
　　因此，我们联合使用了几种工具。底层的工具集包括Apache Ant构建工具、BEA WebLogic Domain Configuration Wizard、WebLogic节点管理器和WLShell（一个用于WebLogic Server 的JMX 管理工具，由Paco Gomez开发）。此外，我们还使用了Unix shell脚本和SSH（Secure Shell）。
　　我们将使用Ant作为用于自动化过程的基本框架。尽管我们不准备在软件开发过程中执行构建过程，但是很多地方具有相似性，所以Ant似乎是最佳选择。我们想要做到与平台无关，把整个过程分为几个单独的步骤，这些步骤将成为Ant目标，而且这些目标之间存在相关性。Ant提供在一个步骤中运行整个过程或者分别执行单个目标的灵活性。此外，我们将利用Ant和Java之间的良好集成，为Domain Configuration Wizard 和WLShell启动Java过程。Ant还提供执行shell命令和等待HTTP服务正确启动的功能，当我们需要检查Admin Server是否启动时，使用上述功能十分方便。

图2 显示了完整的自动化过程。

图2：基于框架Ant构建文件的自动化过程

　　基本框架是执行整个过程的Ant目标。因此，我们满足了一步过程的要求。我们将主要目标命名为rebuildAll ，以突出一个事实，即我们想在构建域之前整理好一切内容。这个目标由一些子目标组成，这些子目标又可以包含嵌套的目标。这种方法使我们能够单独执行自动化过程的单个步骤，这对错误分析和管理已安装的域很有用处。我们使用三种基本的Ant目标类型。第一类使用Ant在文件系统上工作。我们将使用这个目标类型来整理域，复制发布文件，以及构建域的目录结构。第二类执行shell脚本。在Unix中，这是自动化过程的一种便捷途径。shell脚本的不足之处在于它的平台相关性。如果我们想转移到Windows平台上，我们不得不提供等价于每个脚本的Windows命令文件。此外，较大的脚本会变得十分复杂，难于读取和维护。第三类Ant目标调用Java程序，而Java程序与Ant集成良好。我们在不同的情况中使用它（比如，执行WLShell时）。WLShell本身可以在嵌套的WLShell脚本中读取。

模板方法
　　我们想有一个用于修改指域值的配置文件，但是我们会使用许多需要访问这些值的不同脚本和配置文件。所提出的解决方案是基于Ant的替换任务的。我们惟一需要的环境设置是到正确Ant可执行文件的路径。
我们把具有全局相关性的变量定义为domain.properties文件中的属性，该文件将被包含在build.xml文件中。如果我们想在任何其他的脚本或配置文件中使用这种全局变量，我们需要创建一个模板文件，然后使用一个置换标记来表示这个变量。置换标记可以是封闭在两个“@”符号中的任意字符串。

图3：使用Ant置换目标的模板方法

　　模板文件位于template.home目录中。我们创建一个Ant目标trimFiles，以从模板生成目标文件，并把它们放入project.home目录中。
　　步骤1：简单的WebLogic Server域
　　作为自动化域建立过程的一部分，我们需要一个基于脚本的方法来建立初始域。从SP1开始的WebLogic Server 7.0具有WebLogic Server的静默（silent）安装特点，在静默安装中，WebLogic Server域的建立是一个子活动。
　　我们使用Ant目标buildDomain自动化域的创建过程。这项任务需要文件silent.xml作为输入，该文件包含初始的WebLogic Server域的配置信息。我们只需要一个由一台Admin Server组成的、非常简单的域配置。然而，它必须包含如下项目的正确值：域名、监听地址和端口、系统用户和密码，以及通向BEA Home和WebLogic Home的正确路径。因为这些值是特定于域的，所以我们在domain.properties文件中定义它们，然后使用模板方法生成silent.xml文件。Ant目标buildDomain调用WebLogic发布的dmwiz.sh shell脚本，该脚本以静默模式从头开始创建了一个新的WebLogic Server域。在这之前，它会检查所有的基本目录是否存在，并删除这些位置上的任何旧域。因为在Unix系统上，删除打开的文件将招致许多麻烦，我们需要验证没有该域的进程正在运行（比如，我们关掉节点管理器和所有的WebLogic Server实例）。这个Ant目标的成功执行将为我们提供一个新创建的、准备启动的WebLogic Server域。
　　从现在开始，每个配置行为均基于JMX。因此，我们需要启动新域的Admin Server。我们将使用Ant目标startAdmin来调用shell脚本startAdmin.sh。这是文件startWebLogic.sh的简洁版，包含一些特定于域的信息，比如域名、监听地址和端口。接着，我们要使用模板方法生成这个脚本。此外，我们还要生成文件boot.properties，该文件包含用户和密码，可以使Admin Server不用提示该信息。Admin Server将使用“nohup”选项启动，因此，即使我们终止它的父shell，它也会继续运行。但是现在，我们需要检测何时继续自动化部署的下一步骤。我们必须等到Admin Server运行并接受JMX命令为止。我们要实现Ant目标waitForAdmin，它基于Ant任务等待和HTTP实现了一个非常简单的忙等待循环。只要Admin Server响应HTTP请求，此循环就会终止，而我们就可以继续进行基于JMX的配置。
　　步骤2：集群配置
　　作为进行集群配置的先决条件，我们需要有一个带有正在运行的Admin Server的WebLogic Server域。域配置包含在config.xml文件中。我们可以通过编辑这个文件来配置域，但是这可能需要域完全重新启动，因为Admin Server会定期保存对域配置所做的修改，但只在启动时加载它们。
　　在这里，我们更愿意使用基于JMX的方法，使用WLShell通过JMX命令定义服务器和集群。我们的WLShell工作目录是项目主目录。我们将配置集群的脚本命名为cluster.wlsh。我们希望该脚本包含由模板方法插入的、特定于域的信息。相反，我们在这里只使用变量，然后再读入一个WLShell脚本，我们把它命名为connect.wlsh。connect.wlsh用于设置所有特定于域的变量，并连接到Admin Server。它将重用于所有的WLShell任务中。因此，cluster.wlsh不是一个模板脚本（即遵从模板方法），而connect.wlsh是模板脚本。connect.wlsh定义了集群、托管服务器，并向集群添加托管服务器。
　　为了能够通过节点管理器启动域，我们需要给机器指派托管服务器。脚本cluster.wlsh是完成此项工作的绝佳之地，因为它定义了托管服务器及其属性。然而，使用WLShell版本的一个bug可以防止这一点。作为一种规避方法，我们使用了由脚本admin.sh 所调用的WebLogic Admin Utility。相应的Ant目标是assignMachine。因为所有JMX命令还可以由WebLogic Admin Utility发出，所以这种方法为所有潜在的WLShell bug给出了一种通用的规避方法。但是，因为BEA WebLogic Server 7.0中的Admin Utility没有批处理模式，而且每次JMX调用必须单独发出，所以使用该解决方案所付出的代价是处理时间延长。
　　步骤3：JMS和JDBC配置
　　J2EE资源（比如JMS和JDBC）的配置十分直观。在这里，我们使用了Ant目标buildJMS和buildDB。这两个Ant目标都调用了WLShell脚本，而该脚本又读入了connect.wlsh。connect.wlsh建立到Admin Server的连接，并为JMS和JDBC配置定义了所有相关的变量。因为connect.wlsh是一个模板文件，我们可以在domain.properties中定义所有必需的变量，然后在执行Ant目标trimFiles期间把它们加入connect. wlsh中。
　　步骤4：复制发布文件
　　在该步骤中，我们把所有应用程序的发布文件都复制到域主目录的应用程序目录，从而使它们对BEA WebLogic Server可用。上述发布文件包括业务应用程序的所有EAR和WAR存档文件，以及其他的库。
　　如果我们在多机器环境中进行操作，我们要使用FTP脚本或批处理模式中的SCP（Secure Copy）来把整个域（即域的根目录和所有子目录）复制到参与的机器上。我们引入一个良好的冗余性级别，因为没有运行Admin Server的节点上只需要文件的一个子集。然而，如果Admin Server节点由于某些原因失效，我们可以在其他任意机器上快速启动Admin Server。
　　步骤5：启动节点管理器和托管服务器
　　在这个步骤中，我们想启动域的托管服务器。作为先决条件，我们需要在涉及的所有机器上启动节点管理器。我们使用Ant目标startNodeManager，它调用了一个shell脚本startNodeManager.sh。这个脚本必须包含特定于域的设置（即监听端口和节点管理器主目录），所以我们使用模板方法来生成它。对这个BEA WebLogic Server域的所有远程机器，我们使用SSH命令启动远程节点管理器。
　　现在，我们可以使用Ant目标startManaged启动托管服务器。因为我们想启动一个具有多台托管服务器的域，我们使用了Ant任务并行，它提供大量功能，并极大地缩短了整个域的启动时间。
　　在一个客户项目中，我们必须从并行服务器启动中排除一些托管服务器，因为它们是一项所有其他托管服务器都需要的JMS服务的宿主。因此，我们首先排除这些托管服务器。我们使用脚本startManaged.wlsh通过JMX命令来启动托管服务器。
　　步骤6：部署应用程序
　　这是自动建立域的最后一步。我们通过JMX命令在所有节点上部署并激活业务应用程序。我们使用Ant目标deployApps，它调用了WLShell 脚本deploy.wlsh。我们不必等到托管服务器切换到运行模式，因为我们已经连接上了已经正在运行的Admin Server。Admin Server启动一项部署任务，然后负责部署和激活应用程序。

结束语
　　这个已归档的过程已经证明了它在各种客户项目中的可用性。
　　回顾前面的要求，我们可以肯定地说，所提出的解决方案完全满足“完全自动化”、“只在一处进行配置”和“域独立”的条件。平台独立性没有完全得到满足，因为仍然存在各种shell脚本，而Windows平台并不直接支持它们。然而，通过对Windows使用Unix shell实现（比如cygwin），项目可以解决这个问题。
　　所给出的解决方案是在BEA WebLogic Server 7.0上开发和测试的。WebLogic Server 8.1引入了一些有趣的功能，我们可以利用这些功能来简化这个过程。这些功能包括与Ant更加紧密的集成、Configuration Template Builder，以及Admin Utility的批处理模式。
　　可以很容易地扩展所提出用于建立BEA WebLogic Server的方法，以自动化域管理的某些方面。在一些客户项目中，我们可以使用Ant目标来提高单独服务器或整个域的性能。在负载测试期间，我们实现了Ant目标以在单个步骤中修改与性能相关的设置，比如JDBC连接池大小、工作线程的数量，或者整个集群的JVM配置。