本文提供了在把WebLogic Platform应用程序从开发升级为产品时应该注意的问题概述，并描述了应用程序和目标环境需要具体改动的地方。本文的读者主要是升级过程中所涉及的开发人员和管理人员。
在开发团队已经完成了WebLogic Platform应用程序的开发后，接下来，就要把它移植到一个与开发环境非常不同的准产品环境中，比如，分段环境或QA环境。本文简要论述了在把WebLogic Platform应用程序升级为产品时应该注意的问题，并提供了有助于升级过程的几点提示。此外，还描述了开发环境和目标环境之间所存在的典型差异、应用程序需要改动的地方以及准备用于产品部署的环境。
我们着重于一个单独的WebLogic Platform应用程序，因为我们认为一个应用程序可能是一个将被部署的更大系统的一部分。我们还考虑到当升级为产品时，正在开发的应用程序之间的通信所造成的影响。这里提到的“ WebLogic Platform应用程序”，是指结合了WebLogic 8.1 Platform（例如，WebLogic Integration、WebLogic Portal）一个或多个组件或WebLogic Liquid Data的应用程序。这里讨论的应用程序使用WebLogic Integration Processes 和（一个简单的门户）以及WebLogic Liquid Data。而WebLogic Workshop则用做开发应用程序的IDE。
当涉及到多个应用程序时，我们就假设它们已经被适当地设计成松散耦合的，并能被部署在单独的域/集群上[1]，并且它们能满足其他应用程序与架构有关的需求，比如，安全性和高可用性（HA）。
您的应用程序升级过程可以包括从开发环境转移到系统集成环境，再到QA环境，最后到产品环境。或许，步骤会有多有少，但是最终结果是一样的：应用程序很可能需要改变，才能在新的环境中运行；而目标环境也可能需要更新，这样才能容纳应用程序。本文试图阐明转移产品过程中的突出问题，而不论步骤多少。
虽然我们讨论了对目标域的潜在更新，但是我们并没有谈到目标域自身的创建（初始）。(我们推荐使用配置向导工具来创建)。
开发环境与产品环境
在开发时，WebLogic Workshop是创建应用程序以及为应用程序间通信使用服务控件的理想工具。它与一个单独的WebLogic服务器实例一起工作。开发人员的环境可以包括使用与WebLogic Platform捆绑在一起的Pointbase数据库，也可以使用一个企业数据库，但不能是产品数据库。
另一方面，产品环境是一个严格控制的环境，通常由具有多台集群服务器的多个域所组成。应用程序将部署在这些域之上，并需要域间交互。在这种环境中，安全性和高可用性十分关键。而在开发环境中，它们则完全没有必要。另外，WebLogic Workshop IDE不能用在目标环境中。
图1显示了这些差异。 
图 1
具体来说，我们能发现两种环境在以下方面存在差异：
WebLogic资源 应用程序所需的以及在开发环境中创建的WebLogic资源很不可能不存在于目标环境中。此外，这些资源可能在产品域中有不同配置。例如，因为满足HA需求而不同。
数据库 数据库配置一般定位到连接池，但是在需要对应用程序模块更新时则例外(比如，当使用WebLogic Application Integration Application Views时，以下会提到)。当更换数据库时，任何已经编写的定制的JDBC代码显然必须要改变。应用程序所需的以及在开发环境中创建的数据库资源(表、模式、帐号)可能在目标数据库中不存在，并且可能要更新应用程序才能适应目标数据库环境。
集群 开发使用“单个的实例”，非集群环境，而产品环境则通常是集群环境。
代理/负载均衡器 集群包括要使用代理/负载均衡器。将通过域的代理配置来访问应用程序。当多个应用程序被部署到多个域时，应用程序到应用程序的通信（例如，使用服务控件）将通过类似配置代理的方式进行。
节点管理器 使用集群还有可能引入WebLogic节点管理器，尤其是为到达高可用性而需要保证服务器被迅速重启时。
安全性 在开发期间，会使用WebLogic的嵌入式LDAP，并使用“demo”证书来认证。应用程序是不安全的，允许匿名访问。而在产品环境中，会使用一个外部认证提供器，这样会限制只有通过认证的用户才能访问。另外，还有可能需要使用商业证书的SSL。
启动节点 WebLogic定义了“development”和“production”服务器启动节点，它们有若干不同点[2]。
参与者 不要忘了该过程中的个人。当移植到产品环境时，开发团队通常需要与一位应用程序管理员（负责应用程序生命周期的维护）、一位系统管理员、一位数据库管理员以及一位安全性管理员一起工作。
可能需要改动的地方
处理开发环境和产品环境之间的差异需要改动应用程序以及前面提到的目标环境。以下是准备应用程序和产品部署环境时必须要解决的几个或所有方面。
前端访问 前端是指客户端访问应用程序的方式。不论是否在开发环境中用直接访问（例如，“localhost:7001”）去访问应用程序，在产品环境中都是通过一个代理/负载均衡器来访问应用程序（见图1）。Workshop提供了一个清晰的方法来指定下面提到的前端设置。
后台访问 后台是指应用程序调用远程服务的方式。后台服务的URL必须改变，因为那些服务现在处于一个代理/负载均衡器之后（见图1）。
Workshop IDE能在开发域中方便地创建它需要的资源，但是这些资源必须被显式地添加到产品域中（通常是一个运行的集群）。这些资源包括为会话web服务而被Workshop运行时使用的会话状态表，以及用来处理异步请求的队列[3]。
与之类似，其他的应用程序资源，例如JDBC、JMS资源，必须在目标环境中被识别和配置。
应用程序所需的数据库表必须在产品数据库中创建。应用程序可能还需要一个具体的数据库帐号和/或帐号优先权。
假如使用Application Views访问数据库，例如，在使用WebLogic Integration中的样例DBMS适配器时，要使用数据库就必须在产品环境中重新配置Application Views。WebLogic Application Integration （WLI AI）为此提供了配置工具——aiConfigurator。另外，当使用了应用程序视图事件时，aiConfigurator则被用来配置内部消息目标。
安全性 目标环境需要配置才能使用外部认证提供器。因此必须要部署商业数字化证书并启用SSL。而且，还要对应用程序做一些相应的改变。
规划和准备产品部署
产品和开发团队必须在一个新应用程序的部署策略下合作：开发团队指定目标环境中应用程序的需求（也提供应用程序本身），而产品团队则用已经存在的或在目标环境中被添加或重新配置的资源来满足那些需求。这样合作的结果是一份全面的规范说明——升级计划书，它全面描述了应用程序必须要更新的地方，以及各种部署需求，比如目标环境中需要的资源。
下面列出的项目详细说明了在产品构建之前应用程序所需的潜在改动，以及在部署应用程序之前产品环境所需的潜在更新。而您的升级计划中包括哪几项则取决于应用程序的性质和目标环境的配置。
为产品构建准备应用程序
配置前端访问
指定应用程序的前端信息有两种可用的方法。
第一种方法是在wlw-config.xml文件中配置每个项目的前端信息。在为产品部署而构建应用程序时（使用wlwBuild)），可以使用这种配置方法。
第二种方法是在产品域中的wlw-runtime-config.xml文件中配置。这时，您需要为应用程序中的每个项目配置一个入口。下面是一个wlw-runtime-config.xml样例，配置了含有三个项目的两个应用程序（platApp1和platApp2）。
|
<?xml version="1.0" encoding="UTF-8"?>
<wlw-runtime-config xmlns="http://www.bea.com/2003/03/wlw/config/">
<wlw-config application-name="platApp1" context-path="/project1">
<hostname>proxysvr1</hostname>
<protocol>http</protocol>
<http-port>9101</http-port>
</wlw-config>
<wlw-config application-name="platApp1" context-path="/project2">
<hostname>proxysvr1</hostname>
<protocol>http</protocol>
<http-port>9101</http-port>
</wlw-config>
<wlw-config application-name="platApp2" context-path="/project3">
<hostname>proxysvr1</hostname>
<protocol>http</protocol>
<http-port>9101</http-port>
</wlw-config>
</wlw-runtime-config>
|
使用wlw-runtime-config有一个优点，即它不需要再编译应用程序。然而，也有其他因素会导致再编译。下面我们会提到。
假如要限制应用程序只访问SSL，则需要在每个项目的<protocol>元素中指定“https”并使用<https-port>标记来指定端口。
配置后台访问
企业系统涉及到多个以松散耦合方式通信的应用程序，例如，一个Portal应用程序通过服务控件与一个Process应用程序通信。在目标环境中将通过一个代理/负载均衡器访问集群服务器，而不像开发环境中那样，只访问本地服务。
当应用程序使用一个服务控件调用另一个应用程序时，Workshop会在生成的服务控件文件（.jcx）中以部分注释（“@jc:location http-url”）的方式包含被调用程序的主机名和端口号。例如，部署结果可能如下：
|
/**
* @jc:location http?url="http://localhost:7001/processes/CSR.jpd"
* @jc:wsdl file="#CSR_ProcessWsdl"
*/
|
在您为产品部署构建EAR之前，每个这样的URL都必须用目标服务的主机名和端口号固定下来，也就是部署目标服务的域的代理/负载均衡器的主机名和端口号。下面是更新后的含有代理地址和端口号的URL：
|
/**
* @jc:location http?url="http://proxysvr2:9201/processes/CSR.jpd"
* @jc:wsdl file="#CSR_ProcessWsdl"
*/
|
开发团队需要提供一个供应用程序使用的远程服务列表，而产品管理员则需要在为产品部署构建应用程序之前更新相应的服务控件文件。
安装应用程序文件
在开发过程中，为了启用团队开发会使用到资源控制工具。作为Workshop Team Development最佳实践的一部分[4]， 某些的文件不应该放入资源树中，这些文件需要在为产品部署构建应用程序之前安装。它们包括Portal库、NetUI标记库、Liquid Data控件文件以及下面列出的Workshop生成文件。
|
/.workshop directory
/META-INF except the application-config.xml file.
/APP-INF/lib
web-project/WEB-INF/*.tld
web-project/WEB-INF/*.tldx
web-project/WEB-INF/jpf-struts-config*.xml
web-project/WEB-INF/classes
web-project/WEB-INF/lib
schema-project/system/*.*
/*.jar
/*.war
|
重新配置Application Views
假如应用程序部署了Application Views，那必须更新Application Views才能反映产品环境中的配置。例如，假如一个Application View与一个DBMS适配器一起使用，那么产品中的数据库设置会不同。
BEA提供了aiConfigurator工具[5]，使重新配置Application Views变得简单。例如，可以使用以下命令来更新Application View。
|
aiConfigurator.cmd
-appName  {app.name}
-appFile {app.work.dir}
-domainRootDir {domain.dir}
-updateDesignTime -configAdapter
-appViewName {app_view.name}
-adapterName {adapter.name}
-prop EventCatalog={database.catalog}
-prop EventSchema={database.user}
-prop UserName={database.user}
-prop Password={database.password}
aiConfigurator.cmd
-appName {app.name}
-appFile {app.work.dir}
-domainRootDir {domain.dir}
-updateDesignTime -configFactory
-appViewName {app_view.name}
-adapterName {adapter.name}
-factoryName {factory.name}
-prop UseDataSource=false
-prop JdbcDriverClassName={database.xa_driver}
-prop JdbcUrl={database.url}
-prop JdbcProperties={database.props}
-prop UserName={database.user}
-prop Password={database.password}
|
目标事件生成器
当使用支持多生成器实例的WLI AI适配器时，例如样例DBMS适配器，事件生成器可以分布在集群中的每个节点上。我们可以使用aiConfigurator的“inboundMessagingTargets”选项来指定Event Generation Targets从而完成这项工作，例如：
|
aiConfigurator.cmd
…
-configAdapter
-inboundMessagingTargets Server1,Server2
|
目标规格取决于适配器是否实现了“event generator instance support”。[6]
这与我们的讨论有关，是因为它需要目标集群配置的知识。具体的说，集群中的WLI服务器名字会用在目标规格中。
更新服务器路径
在用wlwBuild工具为产品部署而重新构建应用程序前，必须用目标域的位置更新.work文件中的服务器路径属性。例如：
|
<option name="server.path" value="/usr/domains/platDomain"/>
|
配置应用程序安全性
为了满足产品环境中的安全性需求，有必要改变应用程序的配置和资源。
要启用SSL，则需要改变应用程序的服务控件并部署描述符。下面的代码片段显示了服务控件文件中所需的改动。
|
/**
* @jc:location http-url="https://proxysvr1:7002/webservice/Report.jws"
* @jc:wsdl file="#ReportWsdl"
*/
public interface ReportControl extends com.bea.control.ControlExtension, com.bea.control.ServiceControl
|
以下代码显示了为配置 “transport-guarantee”而对部署描述符进行的必要改动。
|
<security-constraint>
<!-some other configs -->
<user-data-constraint>
<transport-guarantee>CONFIDENTIAL</transport-guarantee>
</user-data-constraint>
</security-constraint>
|
要启用客户端证书的使用，则需要对调用应用程序进行相应的改动[7]。
假如要保证产品环境中的应用程序安全，则要确保login-config被适当地设置为FORM或CLIENT-CERT。这为每个项目的web应用程序部署描述符（web.xml）而设置，例如：
|
<login-config>
<auth-method>CLIENT-CERT</auth-method>
</login-config>
|
参见上面前端部分中的启用SSL的节点。
为高可用性进行配置
要支持集群产品环境的高可用性（HA），需要更新应用程序的配置。例如，在weblogic.xml中配置<session-param>描述符元素以在集群间启用会话复制是很重要的[8]。
|
<session-descriptor>
<session-param>
<param-name>PersistentStoreType</param-name>
<param-value>replicated_if_clustered</param-value>
</session-param>
</session-descriptor>
|
为产品部署更新目标环境
配置应用程序资源
应用程序所需的在开发域中被创建的资源也必须在目标域中进行配置。这些资源包括WebLogic资源，例如JMS资源（JMS服务器、队列、主题等）和JDBC资源（连接池、数据源等）。至少存在两种把应用程序资源添加到目标域中的方法。
假如已经创建了域并且域正在运行，那么就可以使用dev2dev WebLogic脚本工具（WLST Online） [9]。
假如域的创建是升级过程的一部分，那么应用程序资源能够在使用dev2dev WLST离线工具[10]时被添加。应用程序配置和它需要的资源能够在开发环境中用Configuration Template Builder巧妙地打包成一个Extension Template，然后用WLST offline（或使用Configuration Wizard GUI）将其应用到目标域中以扩展它。
配置AsyncDispatcher队列
假如应用程序/项目支持对web服务或处理的异步请求，Workshop则能在开发域中创建队列来处理这些请求。（它为每个这样的项目创建一个“AsyncDispatcher”队列和一个相应的错误队列 )。这些队列必须在部署应用程序前在目标域中配置。
一个最近置入到dev2dev代码库的“PO Sample” [11]提供了一个很好的自动向域中添加这些队列的例子。该例子检查应用程序的wlw-manifest文件，然后用WLST把这些队列添加到一台正在运行的WebLogic服务器中。
假如目标域是集群的，这些队列必须被配置为JMSDistributedQueues。
配置域安全性
除了以上列出的应用程序为安全性配置而做的改动外，产品环境也需要做相应的更新。
l 可能需要部署商业数字证书（比如VeriSign证书）。
l 还可能需要配置外部认证提供器。
l 在确定服务器已经启用了SSL后，可以在产品域中配置SSL。
配置Liquid Data存储库
如果应用程序部署了Liquid Data 查询，那么产品域目录下的Liquid Data存储库目录（“ldrepository”）需要用合适的Liquid Data配置来更新（比如Stored Queries、Custom Functions等），然后需要把LD数据源导入到产品域中。
wlw-runtime-config
如果产品中使用了wlw-runtime-config.xml，那必须将其复制到集群中每台被管理服务器的根目录下。参见上面的前端配置部分。
在产品数据库中创建表
创建会话状态表 会话状态表中保存着一个web服务或业务流程的会话状态。这些在开发过程中被Workshop运行时自动创建，但它们必须在应用程序部署前在产品数据库中显式地创建。前面在dev2dev提到的“PO Sample”[11]也提供了编写这一步骤的脚本的例子：它检查应用程序的wlw-manifest文件，然后生成可用于创建所需表的SQL文件。
创建应用程序特定的表 应用程序所需的数据库表（例如，顾客、帐单、定单）必须在产品部署前在目标环境中创建。
创建CMP Entity Bean表 假如应用程序部署了CMP Entity bean，那么底层的表模式会在开发中被容器自动创建。然而，在产品中该功能被禁用了，所以，这些表必须在目标数据库中创建。这就需要用到更为精确的表模式定义。
升级计划将包括以上与您的应用程序和前面提到的部署环境有关的内容，并且能在开发与产品之间提供一个契约。这些结构性信息能够用简单的XML语言——一种应用程序的“超级描述语言”——在一份XML文件中轻松地捕获到。您可以想像用下游工具来处理XML文档，以在适当的地方使升级过程自动化并且简洁。
一些依赖条件
以上步骤中使用哪些工具依赖于现存的域或正在构建的应用程序，如下所述。
l WlwBuild的使用依赖于域的存在。在用wlwBuild为产品部署而构建应用程序之前，它的.work文件必须用域的位置更新。
l Application View的重新配置依赖于域的存在。域的位置作为一个参数来传递到aiConfigurator。
l AiConfigurator只应该在还没有启动的域之上运行。
l 基于“PO Sample”工具的使用将依赖于构建的应用程序（EAR）。它利用了wlwBuild生成的应用程序的wlw-manifest文件。
这些依赖条件会影响您所采用的升级过程。例如，能使用wlwBuild构建一个应用程序EAR，然后用一个与PO Sample类似的工具更新现存的域。然而，却不可能用wlwBuild创建一个应用程序EAR，再在域的创建过程中使用PO Sample，因为存在一个循环依赖。
升级过程
总的来说，一个升级过程包含了上面概述的这些步骤：协作制定一份升级计划、准备并构建应用程序、准备目标域并将应用程序部署为产品。下面的图2描述了这些步骤。此外，确切的步骤将取决于您的应用程序的特点、目标环境的配置以及产品管理员所设置的策略。
图 2
在这个过程中，准备并构建应用程序，然后作为输入来更新（已存在的）目标域。因此，这些步骤是按顺序进行的。如果需要的话，也可以用一个不同的过程和不同的工具组合，把准备并构建应用程序与准备和创建或更新域这两个步骤并行进行。
结束语
把一个WebLogic Platform应用程序从一个开发环境升级到一个产品环境，需要开发人员与管理人员的合作，以及对应用程序和目标环境的必要更新。这样做所产生的结果是一份升级计划，它指出了应用程序为适应目标环境所需的改动以及目标环境为接纳应用程序所需的改动。应用程序的改动包括配置上的以及源代码级的改动。而域则必须用应用程序所需的资源来配置，并满足安全性和高可用性需求。一些工具可用来协助部署过程的自动化/脚本部分，其中包括创建和更新域、构建应用程序以及配置WLI AI Application Views。 |
