熱點推薦:
您现在的位置: 電腦知識網 >> 編程 >> Java編程 >> Java核心技術 >> 正文

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

2013-11-23 18:56:42  來源: Java核心技術 

摘要

  BEA WebLogic Platform應用程序供應(provisionin)是一個這樣的過程准備提供一個有效的WebLogic Platform環境來支持已部署好的應用程序的後續應用在前一篇文章中我們介紹了經過幾個階段將WebLogic Platform 應用程序從開發升級到生產階段時我們能從中獲得什麼在本文中研究的重點是使用可用於WebLogic Platform產品的工具來自動化每個階段的應用程序供應這將允許您自動創建運行WebLogic應用程序所需的環境

簡介

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

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

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

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

  挑戰

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

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

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

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

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

基於模板的供應

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

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

基於WLST的供應

  WebLogic Server Scripting Tool(WLST)是一個命令行腳本接口(使用Jython構建)您可以使用該接口與WebLogic Server交互以及配置WebLogic ServerWLST既支持聯機操作模式也支持脫機操作模式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 paymentWSAppTarget wliCluster) unassign(Application taxWSAppTarget wliCluster ) unassign(JDBCConnectionPool portalPoolTarget wliCluster ) unassign(JDBCDataSourcepn_trackingDataSource Target wliCluster ) unassign(JDBCDataSource pnDataSourceTarget wliCluster ) unassign(JDBCTxDataSourceportalFrameworkPool Target wliCluster )

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

  def create_wlpcluster(cluster_config): clusterName clusterAddrmulticastAddrmulticastPort mss = cluster_config # create the cluster cluster = auto_createCluster(clusterNameclusterAddr
multicastAddr multicastPort) # create the managed servers for msConfig in mss: managedserver = auto_createManagedServer(msConfigcluster) # add the cluster to the target list of the following resources wlstcd(/) jcf = wlstgetTarget(JMSConnectionFactory/ + cgQueue) if jcf != None: jcfaddTarget(cluster) poolList=portalPoolcgPoolcgJMSPoolnonXA for poolName in poolList: pool = wlstgetTarget(JDBCConnectionPool/ + poolName) if pool != None: pooladdTarget(cluster) dsList=pn_trackingDataSourcepnDataSource for dsName in dsList: ds = wlstgetTarget(JDBCDataSource/ + dsName) if ds != None: dsaddTarget(cluster) txdsList=portalFrameworkPoolcgDataSourcecgDataSourcenonXA for txdsName in txdsList: txds = wlstgetTarget(JDBCTxDataSource/ + txdsName) if txds != None: txdsaddTarget(cluster) wlstcd(Application/ + JWSQueueTransport) ejb = wlstgetTarget(EJBComponent/ + QueueTransportEJB) if ejb != None: ejbaddTarget(cluster) wlstcd(/)

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

  dsList=pn_trackingDataSourcepnDataSource for dsName in dsList: ds = wlstgetTarget(JDBCDataSource/ + dsName) if ds != None: dsaddTarget(cluster)

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

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

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

用例快速生產復制

  該用例描述了一個特殊的供應場景在該場景中客戶已經有了一個在管理服務器上正確配置的正在運行的生產域並且需要將相同的配置復制到WebLogic集群域中的許多托管服務器中在多台遠程機器上運行基於GUI的工具非常單調乏味並且很容易出錯基於模板的方法似乎非常適合用來自動化這個復制過程我們將舉例說明如何使用Domain Template Builder來捕獲生產域中的東西

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


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

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

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

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


將<wliconfig>文件夾添加到<Domain Root Directory>(注意不必在<wliconfig>文件夾下包含托管服務器的子文件夾)
將<script>文件夾添加到<Domain Root Directory>
將對應於tradeHubJMSEG事件生成器的jar文件(即WLIJmsEG_tradeHubJMSEGjar)添加到<Domain Root Directory>
將DefaultAuthorizerldift文件添加到<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\platformjar) existingPoolName = cgJMSPoolnonXA cd (/) cd (JDBCConnectionPool/ + existingPoolName) cmosetDriverName(oraclejdbcdriverOracleDriver) cmosetUserName(EEDCDB) cmosetPassword(EEDCDB) cmosetURL(jdbc:oracle:thin:@:

  :) loadDB(iexistingPoolName) closeTemplate()

WebLogic安全區

  每個WebLogic Platform域都是在一個默認安全區中配置的通常存儲在嵌入式LDAP中每個安全區都由一組已配置的安全提供者用戶安全角色和安全策略組成可以定制默認安全區來支持各種安全需要比如說替換一個安全提供者和添加用戶為了支持將安全數據從一個安全區遷移到另一個安全區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允許門戶管理員有選擇性地將數據從一個階段移動到另一個階段注意該工具目前在devdev上它在WebLogic Platform的下一個版本中也將受到支持

WebLogic Integration TPM 數據

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

  bulkloader [verbose] [config <blconfigxml>] [wlibc]

  import <dataxml>

  export <dataxml> [nokeyinfo] [select <selectorxml>]

BEA Liquid Data for WebLogic服務器設置

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

  <java classname=combealdiutilCfgImpExp fork=true> <classpath> <pathelement location=<WL_HOME>/server/lib/weblogicjar/> <pathelement location=<REPOSITORY_DIR>/importexporttools/CfgImpExpjar/> <pathelement location=<WL_HOME>/liquiddata/server/lib/wlldijar/> <pathelement location=<WL_HOME>/liquiddata/server/lib/castorjar/> <pathelement location=<WL_HOME>/liquiddata/server/lib/xercesImpljar/> <pathelement location=<WL_HOME>/liquiddata/server/lib/APPINF/lib/LDSjar/> </classpath> <arg line=<ADMIN_ADDR> <ADMIN_PORT> <ADMIN_USERNAME> <ADMIN_PASSWORD> import <DOMAIN_HOME>/ldrepository/import_export/LDconfigxml/> </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/wlwjar) cd(/) cd(Security/mydomain) cd(User/weblogic) cmosetPassword(weblogic) setOption(OverwriteDomain true) writeDomain(<BEA_HOME>/user_projects/domains/wlwwli) closeTemplate() readDomain(<BEA_HOME>/user_projects/domains/wlwwli) setOption(ReplaceDuplicatesfalse) addTemplate(<WL_HOME>/common/templates/applications/wlijar) updateDomain() closeDomain()

結束語

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


From:http://tw.wingwit.com/Article/program/Java/hx/201311/26016.html
  • 上一篇文章:

  • 下一篇文章:
  • 推薦文章
    Copyright © 2005-2013 電腦知識網 Computer Knowledge   All rights reserved.