自動化WebLogic平臺應用程序供應

　　 

摘要

　　BEA WebLogic Platform應用程序供應（provisionin）是一個這樣的過程：準備提供一個有效的WebLogic Platform環境來支持已部署好的應用程序的后續應用。

在前一篇文章中，我們介紹了經過幾個階段將WebLogic Platform 8.1應用程序從開發升級到生產階段時，我們能從中獲得什么。在本文中，研究的重點是使用可用于WebLogic Platform產品的工具來自動化每個階段的應用程序供應。這將允許您自動創建運行WebLogic應用程序所需的環境。

簡介

　　BEA WebLogic Platform應用程序供應是一個這樣的過程：準備提供一個有效的WebLogic Platform環境來支持已部署好的應用程序的后續應用。WebLogic Platform環境通常由三種資源組成：域級別的資源（如JDBC Connection Pool和DataSources）、客戶應用程序和生產數據（如安全角色、緩存策略、門戶元數據和貿易合作伙伴管理數據等）。在經過幾個階段將WebLogic應用程序從開發階段升級到生產階段時，需要在每個階段適當地供應這些資源?？紤]到配置域級別和應用程序級資源的復雜性，應用程序供應不是一個普通的過程，它常常需要大量的手工勞動并且很容易出錯。所以，人們非常期待通過自動化供應過程來提高生產效率和可靠性，同時降低IT成本。

　　本文首先將討論自動化應用程序供應過程中面臨的挑戰。然后對可以在WebLogic Platform中使用的供應工具進行概括。通過對一些常見場景的案例分析，比如從開發階段升級到生產階段、快速生產復制、生產數據配置和差量供應，本文將演示如何有效使用這些供應工具來自動化供應過程。

　　本文提供的示例均摘自一些實際的客戶供應場景。文中引用的WebLogic Scripting Tool（WLST）示例腳本和域模板都已經在WebLogic Platform 8.1 Service Pack 4上開發并通過測試。在即將推出的WebLogic Platform版本中，還將支持JSR-88。因此，目前已經配置好的域級別的一些資源將作為應用程序級資源打包。隨著應用程序供應的自動化，我們的生活會更輕松一些。

　　注意，本文并不打算成為一篇關于如何使用供應工具（如Domain Template Builder，或DTB）的教程。通過“參考資料”部分中提供的鏈接，您可以找到關于這些工具的更多信息。

　　 挑戰

　　要運行WebLogic Platform應用程序，就必須創建一個包括適當WebLogic Platform組件和應用程序級資源的域。圖1提供了一個升級過程的例子，在這個過程中，應用程序要經歷4個階段：開發、集成、QA/分級測試和生產。在生產階段，WebLogic Platform應用程序供應還包括為每個應用程序供應需求設置一個集群子網和代理。

圖 1. 從開發階段升級到生產階段的應用程序升級過程

　　在典型的開發階段，幾個開發人員將同時為一個項目工作，每個開發人員從事不同的模塊研究。這些開發人員可能擁有作為沙箱的自己的工作域（開發模式、帶有本地數據庫的單服務器），并且可以使用源代碼控制工具來促進團隊開發。在開發模式域中，BEA WebLogic Server和BEA WebLogic Workshop將自動供應一些應用程序資源，比如 Entity Bean表、AsyncDispatcher隊列和會話狀態表。在生產模式域中，必須顯式供應這些資源。QA/分級測試環境通常會模擬真實的生產環境，該環境一般由一個或多個集群域以及一些專用的數據庫服務器、負載平衡器和商業證書組成。安全性和高可用性在生產階段很重要，因為它們可能是開發環境中完全缺乏的東西。此外，如果在生產階段對托管服務器使用不同的IP地址或端口，那么還需要更新應用程序模塊，為定制部署重新生成EAR文件。

　　當經過幾個階段將WebLogic Platform應用程序從開發階段升級到生產階段時，自動化這個過程對確保成功實現生產部署很關鍵。配置自動化所面臨的一個主要挑戰是識別和捕獲正確的配置需要，支持正確的應用程序部署，并將這一點貫徹到每個階段，然后進行目標環境所需的任何配置定制。

　　WebLogic Platform提供了大量系統工具來促進供應自動化，這些工具包括Configuration Wizard、Domain Template Builder和WebLogic Scripting Tool（WLST）等。關于這些工具的完整列表，請參閱WebLogic Platform Deployment Guide。WebLogic Platform還提供了許多幫助客戶完成初始的域配置的預定義域模板、一組用來添加定義良好的應用程序的模板，以及維護現有域的一些服務。根據各種供應場景的特點，可以將供應方法分成基于模板的方法和基于WLST的方法。注意，可以有效組合這些方法來應對復雜的供應場景。

基于模板的供應

　　預定義域和擴展模板包含構建或擴展特殊WebLogic域所需的主要屬性和文件。在向域中添加了新的資源和應用程序之后，就可以使用Domain Template Builder來創建定制域模板，稍后可以使用該模板，通過Configuration Wizard創建一個目標域。

　　基于模板的方法利用Domain Template Builder功能來捕獲當前域的各種配置細節和工件。為了使用基于模板的方法，將從一個運行中的域開始。這個域可以是一個服務器開發域，也可以是一個集群的生產域。此外，應該完全了解現有域，這樣才不會在創建模板時錯過關鍵配置信息。在創建模板時，有一個定制域資源設置的機會，但也可以在以后某個階段實現定制，即在使用已創建的模板實際配置該域的時候。

基于WLST的供應

　　WebLogic Server Scripting Tool（WLST）是一個命令行腳本接口（使用Jython構建），您可以使用該接口與WebLogic Server交互以及配置WebLogic Server。WLST既支持聯機操作模式，也支持脫機操作模式。WLST Online在連接到某臺運行中的服務器時才開始運作，而WLST Offline通過添加命令來支持Configuration Wizard功能，它允許在不連接到運行中的服務器的情況下創建和擴展WebLogic域。WLST Offline支持WebLogic Platform中提供的預定義域模板以及使用Template Builder工具創建的定制域模板。

　　 基于WLST的配置方法利用WLST Offline和WLST Online功能來記錄一組域腳本中的各種域配置細節，并將這些腳本與一些預定義或定制的域模板一起使用，以創建目標域。使用基于WLST的方法，可以很容易地通過腳本更改域配置，還可以通過源代碼控制有效追蹤配置變化。關于使用WLST的更多信息，請參閱CodeShare項目wlst，可以從中獲得一些示例腳本和最佳實踐。

　　 在以下幾個小節中，將深入研究一些常見的供應用例，演示并比較基于模板的方法與基于WLST的方法的運用。

用例：從開發階段轉移到分級測試/生產階段

　　該用例展示了一個在自動供應方面有較高要求的常見配置場景。通常，開發環境與生產環境存在極大差異，這使得基于WLST的方法比基于模板的方法更加適用。通過一個假設的場景，我們將闡述如何組合使用WLST Offline和WLST Online腳本來配置所需的生產域。

　　 該例中，開發團隊已經實現了兩個應用程序：BEA WebLogic Integration應用程序和BEA WebLogic Portal應用程序。這兩個應用程序都是使用單獨的服務器實例在單獨的平臺域中部署的。在從分級測試階段移動到生產階段時，該團隊想在一個平臺域中配置兩個單獨的集群（wliCluster和wlpCluster），一個用于部署WebLogic Integration應用程序，另一個用于部署WebLogic Portal應用程序。Configuration Wizard和WLST Offline只支持單集群域的自動配置。當通過Configuration Wizard在一個平臺域中配置多個集群（例如，有一個wliCluster和一個wlpCluster）時，域級別的資源會自動將目標設定為第一個集群（在這里，是wliCluster）。所以，需要重新指定一些資源（比如與門戶相關的應用程序和資源）的目標。組合使用WLST Offline和Online腳本可以有效滿足配置多集群域的特殊需求。

　　 通常，可以使用WLST Offline腳本來配置用于任何單集群域的資源。例如，WLST Offline腳本可以添加用戶、添加托管的服務器、添加額外的JMS隊列、定制JDBCConnectionPool，等等。因為WLST Offline是基于Config Wizard框架的，所以它支持一些良好的自動配置特性，但它在配置多個集群方面存在同樣的限制。在創建第一個集群（wliCluster）之后，需要從wliCluster中取消對門戶相關的應用程序和資源的目標設定。

cd('/')
unassign('Application', 'paymentWSApp','Target', 'wliCluster')
unassign('Application', 'taxWSApp','Target', ' wliCluster ')
unassign('JDBCConnectionPool', 'portalPool','Target', ' wliCluster ')
unassign('JDBCDataSource','p13n_trackingDataSource', 'Target', ' wliCluster ')
unassign('JDBCDataSource', 'p13nDataSource','Target', ' wliCluster ')
unassign('JDBCTxDataSource','portalFrameworkPool', 'Target', ' wliCluster ')

　　以下WLST Online腳本舉例說明了第二個集群（wlpCluster）的配置，并適當地重新設置與門戶相關的那些資源的目標，將它們的目標設定為wlpCluster。

def create_wlpcluster(cluster_config):

 clusterName, clusterAddr,multicastAddr,multicastPort, mss = cluster_config

 # create the cluster
 cluster = auto_createCluster(clusterName,clusterAddr, 
multicastAddr, multicastPort)

 # create the managed servers
 for msConfig in mss:
   managedserver = auto_createManagedServer(msConfig,cluster)

 # add the cluster to the target list of the following resources
 wlst.cd('/')

 jcf = wlst.getTarget('JMSConnectionFactory/' + 'cgQueue')
 if jcf != None:
   jcf.addTarget(cluster)

 poolList='portalPool','cgPool','cgJMSPool-nonXA'
 for poolName in poolList:
   pool = wlst.getTarget('JDBCConnectionPool/' + poolName)
   if pool != None:
     pool.addTarget(cluster)
  
 dsList='p13n_trackingDataSource','p13nDataSource'
 for dsName in dsList:
   ds = wlst.getTarget('JDBCDataSource/' + dsName)
   if ds != None:
     ds.addTarget(cluster)

 txdsList='portalFrameworkPool','cgDataSource','cgDataSource-nonXA'
 for txdsName in txdsList:
   txds = wlst.getTarget('JDBCTxDataSource/' + txdsName)
   if txds != None:
    txds.addTarget(cluster)

 wlst.cd('Application/' + 'JWSQueueTransport')

 ejb = wlst.getTarget('EJBComponent/' + 'QueueTransportEJB')
 if ejb != None:
   ejb.addTarget(cluster)
 wlst.cd('/')

　　讓我們仔細看看該腳本的其中一部分：

dsList='p13n_trackingDataSource','p13nDataSource'
for dsName in dsList:
  ds = wlst.getTarget('JDBCDataSource/' + dsName)
  if ds != None:
  ds.addTarget(cluster)

　　該腳本要做的就是循環遍歷DataSource的名稱，我們應該將這些DataSource的目標設定為新的wlpCluster。對于每個DataSource，首先應該調用getTarget()方法來獲得DataSource對象，然后將wlpCluster添加到其目標列表中。

　　 可以從wlst CodeShare項目中下載完整的示例腳本。

　　 除了配置域級別的資源，還需要支持關鍵生產數據的自動供應（或在有時被調用時執行的遷移），這類數據包括WebLogic安全區（security realm）、WebLogic Portal元數據和WebLogic Integration元數據。有關的更多信息，請參閱“生產數據配置”一節。

用例：快速生產復制

　　該用例描述了一個特殊的供應場景，在該場景中，客戶已經有了一個在管理服務器上正確配置的正在運行的生產域，并且需要將相同的配置復制到WebLogic集群域中的許多托管服務器中。在多臺遠程機器上運行基于GUI的工具非常單調乏味，并且很容易出錯?；谀０宓姆椒ㄋ坪醴浅＿m合用來自動化這個復制過程。我們將舉例說明如何使用Domain Template Builder來捕獲生產域中的東西。

　　 假設這個假定的域是一個WebLogic Integration集群域，叫做wlicluster，客戶最初使用Configuration Wizard在WLI域模板中創建了這個域。隨后，又部署并配置了以下資源來支持應用程序的需要：

• 一個稱為tradeHubApp.ear的應用程序，該應用程序使用了消息代理通道和事件生成器，并調用了一個第三方適配器。
• 一個稱為egDistQueue的分布式隊列，以及它對應的隊列成員。
• 一個稱為tradeHubJMSEG的JMS Event Generator，它與egDistQueue和一個現有通道文件有關。
• 一個稱為kodo的第三方適配器，它的目標是集群。

　　現在，我們需要創建一個定制域模板來捕獲完整的配置。默認情況下，Template Builder會包括這個域直接引用的文件?？梢酝ㄟ^Add File窗口（參見圖2），將已部署好的應用程序所需的其他文件（如JMS Event Generator的jar文件和第三方適配器文件）添加到模板中。

圖2. 在創建定制域模板時添加文件

　　 對于前面提到的生產域，我們需要添加以下文件：

• 將<wliconfig>文件夾添加到<Domain Root Directory>（注意，不必在<wliconfig>文件夾下包含托管服務器的子文件夾）。
• 將<script>文件夾添加到<Domain Root Directory>。
• 將對應于tradeHubJMSEG事件生成器的jar文件（即WLIJmsEG_tradeHubJMSEG.jar）添加到<Domain Root Directory>。
• 將DefaultAuthorizer.ldift文件添加到<Domain Root Directory>，因為它定義了默認授權角色以及用來訪問消息代理通道的策略。
• 將適配器工具所在的文件夾添加到<Application Root Directory>/wlicluster。

　　上面展示了域和應用程序資源的一個列表，該列表已經捕獲在域模板中。如果還有其他資源（比如安全角色和策略），那么還需要單獨使用WebLogic Platform提供的其他工具來捕獲這些資源。下一個用例舉例說明了如何使用這些工具來供應生產數據。

用例：生產數據供應

　　通常，WebLogic Platform生產環境中的數據由安全角色、緩沖策略、門戶元數據、貿易合作伙伴管理（TPM）數據和其他通常存儲在各種持久性存儲器（如嵌入式LDAP、外部數據庫和儲存庫文件）中的數據組成。該用例的重點在于自動化生產數據的供應過程。

WebLogic域級別的表

　　每個WebLogic域模板（除了WebLogic Server域模板）都有一組預定義的SQL文件，在啟動服務器之前，需要將這些文件加載到目標數據庫中。例如，WebLogic Portal域模板定義了Content Management Database Object和WSRP Object表，在啟動WebLogic Portal域之前，需要加載這兩個表。這些域級別的表將被加載到生產數據庫中，并被域中的所有服務器共享?？梢酝ㄟ^Configuration Wizard，在創建域期間加載這些表，或者通過WLST Offline中的loadDB()函數加載這些表，以下腳本對此進行了描述：

readTemplate('D:\\common\templates\domains\platform.jar')
existingPoolName = 'cgJMSPool-nonXA'
cd ('/')
cd ('JDBCConnectionPool/' + existingPoolName)
cmo.setDriverName('oracle.jdbc.driver.OracleDriver')
cmo.setUserName('E2EDCDB')
cmo.setPassword('E2EDCDB')
cmo.setURL('jdbc:oracle:thin:@::')
loadDB('9i',existingPoolName)
closeTemplate()

WebLogic安全區

　　每個WebLogic Platform域都是在一個默認安全區中配置的，通常存儲在嵌入式LDAP中。每個安全區都由一組已配置的安全提供者、用戶、組、安全角色和安全策略組成?？梢远ㄖ颇J安全區來支持各種安全需要，比如說，替換一個安全提供者和添加用戶。為了支持將安全數據從一個安全區遷移到另一個安全區，WebLogic Platform通過WebLogic Console和MBean接口提供了一些特殊的導出/導入工具。

BEA WebLogic Enterprise Security 策略數據

　　BEA WebLogic Enterprise Security（WLES）(現稱為AuqaLogic Enterprise Security)服務使用一些不同種類的策略來保護應用程序和資源。為了使客戶輕松地將策略數據轉移到生產環境中，WLES提供了Policy Export/Import工具。策略導出工具允許您將數據從策略數據庫輸出到叫作“策略文件”的文本文件中。也可以使用Policy Import工具將這些策略文件導回同一策略數據庫或另一個策略數據庫。這些工具有一些命令行接口，可以很輕松地集成這些接口來支持自動供應。

WebLogic Portal元數據

　　在配置和定制WebLogic Portal應用程序時，有各種門戶對象（比如權利和委托管理），這些對象存儲在嵌入式LDAP和門戶數據庫中。通過篩選不應傳播的元數據和遺棄不應更新的不受影響的目標數據的能力，WebLogic Portal Propagation Utility允許門戶管理員有選擇性地將數據從一個階段移動到另一個階段。注意，該工具目前在dev2dev上，它在WebLogic Platform的下一個版本中也將受到支持。

WebLogic Integration TPM 數據

　　貿易合作伙伴管理（Trading Partner Management ，TPM）數據包括貿易合作伙伴配置文件、來自keystore的證書、服務定義和服務配置文件。Bulk Loader是一個命令行工具，可以用它來導入、導出和刪除TPM數據。Bulk Loader導入的是XML表達形式的TPM數據，導出的是XML文件。

bulkloader [-verbose] [-config <blconfig.xml>] [-wlibc]

 -import <data.xml>

 -export <data.xml> [-nokeyinfo] [-select <selector.xml>]

BEA Liquid Data for WebLogic服務器設置

　　BEA Liquid Data for WebLogic(現稱為AquaLogic Data Service Platform)服務器設置包括Data Sources、Custom Functions和Stored Queries。這些設置存儲在<ldrepository>文件夾下的儲存庫文件中。以下Ant腳本描述了如何調用Liquid Data工具從Ldconfig.xml文件導入服務器設置。相同的類也支持服務器設置的導出。

<java classname="com.bea.ldi.util.CfgImpExp" fork="true">
 <classpath>
  <pathelement location="<WL_HOME>/server/lib/weblogic.jar"/>
  <pathelement location="<REPOSITORY_DIR>/import-export-tools/CfgImpExp.jar"/>
  <pathelement location="<WL_HOME>/liquiddata/server/lib/wlldi.jar"/>
 <pathelement location="<WL_HOME>/liquiddata/server/lib/castor-0.9.3.9.jar"/>
 <pathelement location="<WL_HOME>/liquiddata/server/lib/xercesImpl.jar"/>
 <pathelement location="<WL_HOME>/liquiddata/server/lib/APP-INF/lib/LDS.jar"/>
 </classpath>
 <arg line="<ADMIN_ADDR> <ADMIN_PORT> <ADMIN_USERNAME> <ADMIN_PASSWORD> 
 import <DOMAIN_HOME>/ldrepository/import_export/LDconfig.xml"/>
</java>

特定于應用程序的表

　　在生產模式域中，WebLogic Server不會在部署應用程序時嘗試自動供應所依賴的資源。例如，如果應用程序包含會話式Web service或Entity Bean，那么在部署應用程序之前，需要加載會話狀態表和Entity Bean表。因為知道需要供應的內容，所以很容易通過腳本自動供應這些內容。關于加載會話狀態表和Entity Bean表的更多信息，請參閱前一篇文章。

　　 自動化生產數據配置的需求已經通過典型平臺環境中的各種生產數據得以證實。其中一些數據可以通過WLST Online/Offline腳本進行供應，而其他一些數據則可以通過WebLogic Platform提供的特殊工具（例如，Portal Propagation工具和WLES Import/Export）來導出或導入。在極少數情況下，可能需要使用數據庫級別的工具來導出或導入存儲在外部數據庫實例中的關鍵信息。

差量供應

　　隨著生產環境的發展，可能需要對現有環境進行更進一步的定制。例如，管理員可能需要更改安全區中的一些安全提供者，或者更新現有緩存策略。這有時也稱為差量供應。大多數差量供應操作都是通過WebLogic Console和MBean調用來完成的。也可以使用基于模板的方法或基于WLST的方法來支持各種差量供應需要。

　　 例如，可以使用WLST Online將一個額外的JMS隊列作為分布式隊列進行配置，并跨集群設置相應的物理隊列成員。wlst CodeShare項目中的一個代碼示例演示了如何將Application AsyncRequest Queues作為Distributed Queues添加到Cluster中。另一個代碼示例闡述了如何通過WLST Online配置嵌入式LDAP或外部LDAP。

　　 WebLogic Console和WLST Online腳本支持活動服務器的差量供應，而WLST Offline和擴展模板可以用來供應附加的應用程序和服務，比如JDBC或JMS組件，以及啟動/關閉類。要應用擴展模板，則需要關閉服務器。以下WLST Offline腳本演示了一個差量供應場景，在該場景中，首先創建的是WebLogic Workshop域，而WebLogic Integration域模板被應用于使用addTemplate()和updateDomain()操作的WebLogic Workshop域。結果，就有了一個既支持WebLogic Workshop功能又支持WebLogic Integration功能的域。

readTemplate('<WL_HOME>/common/templates/domains/wlw.jar')
cd('/')
cd('Security/mydomain')
cd('User/weblogic')
cmo.setPassword('weblogic')
setOption('OverwriteDomain', 'true')
writeDomain('<BEA_HOME>/user_projects/domains/wlw-wli')
closeTemplate()
readDomain('<BEA_HOME>/user_projects/domains/wlw-wli')
setOption('ReplaceDuplicates','false')
addTemplate('<WL_HOME>/common/templates/applications/wli.jar')
updateDomain()
closeDomain()

結束語

　　通過幾個階段來自動化WebLogic Platform應用程序供應，需要完全了解每個階段的特定需求，并采用正確的工具來實現這個自動化過程。在本文中，我們重點研究了基于模板的方法和基于WLST的方法，并舉例說明了如何有效使用這些方法來自動化一些常見的供應場景。

原文轉自：http://www.anti-gravitydesign.com