JBoss7配置指南
1. jboss各主要版本特性... 3
1.1. jboss4特性... 3
1.2. jboss5特性... 5
1.3. jboss6特性... 6
1.4. jboss7特性... 7
2. 為什麼JBoss AS7 這麼快... 8
3. JBoss AS7中的新概念－域... 10
3.1. 域(Domain)的概念及其與群集(Cluster)的區別... 10
3.2. 實驗... 11
1.1.1. 準備工作... 11
1.1.2. 配置... 12
3.2.1.1. Master上面的配置... 14
3.2.1.1.1. domain.xml 14
3.2.1.1.2. host.xml 15
3.2.1.2. Slave上面的配置... 16
3.2.1.2.1. domain.xml. 16
3.2.1.2.2. host.xml 16
3.3. AS 7.1的安全補充說明... 17
3.4. 部署... 20
3.5. 小結... 25
4. JBoss7配置... 26
4.1. 目標聽眾... 26
4.1.1. 開始之前... 26
4.1.2. 手冊中的示例... 26
4.2. 客戶端... 26
4.2.1. web介面... 26
4.2.1.1. HTTP管理接入點... 26
4.2.1.2. 訪問管理控制檯... 27
4.2.1.3. 對管理控制檯進行加密... 27
4.2.2. 命令列介面... 27
4.2.2.1. Native管理接入點... 28
4.2.2.2. 執行命令列管理工具... 28
4.2.2.3. 管理請求... 29
4.2.2.3.1. 管理資源的地址... 30
4.2.2.3.2. 操作型別和操作描述列表... 30
4.2.2.4. 命令列歷史資訊... 32
4.2.2.5. 批處理... 32
4.2.3. 配置檔案... 33
4.3. 核心管理概念... 34
4.3.1. 執行模式... 34
4.3.1.1. 單伺服器模式... 34
4.3.1.2. 管理域... 34
4.3.1.2.1. Host(主機) 35
4.3.1.2.2. 主機控制器(HostController) 35
4.3.1.2.3. Domain Controller(域控制器）... 36
4.3.1.2.4. Server Group (伺服器組) 37
4.3.1.2.5. Server (伺服器）... 38
4.3.1.3. 決定執行在單獨伺服器或者管理域上... 38
4.3.2. 通用的配置概念... 39
4.3.2.1. Extensions (擴充套件) 39
4.3.2.2. Profile和subsystem(子系統 ) 40
4.3.2.3. Paths( 路徑) 40
4.3.2.4. nterfaces (介面) 42
4.3.2.5. socket binding(socket繫結)和socket binding group(socket繫結組) 43
4.3.2.6. System Properties( 系統屬性) 43
4.3.3. Management resources( 管理資源) 44
4.3.3.1. Address (地址) 44
4.3.3.2. operations( 操作) 45
4.3.3.3. Attributes( 屬性) 47
4.3.3.4. Children（子節點) 49
4.3.3.5. Descriptions(描述) 51
4.3.3.6. 和JMX Beans相比... 53
4.3.3.7. 管理資源樹的基本結構(management resource trees) 53
4.3.3.7.1. 單伺服器模式(Standalone server) 53
4.3.3.7.2. 管理域模式 (managed domain) 54
4.4. 管理任務... 56
4.4.1. 網路介面和埠... 56
4.4.1.1. 網路介面宣告... 56
4.4.1.2. Socket Binding Groups 58
4.4.2. 管理介面的安全性... 59
4.4.2.1. 初始化設定... 60
4.4.2.2. 快速配置... 61
4.4.2.3. 詳細配置... 63
4.4.2.3.1. 管理介面... 63
4.4.2.3.2. 安全域... 64
4.4.2.3.3. Outbound connections(外部連線) 68
4.4.2.4. 問題... 68
4.4.3. JVM設定... 68
4.4.3.1. 管理域... 69
4.4.3.2. 單獨執行伺服器... 70
4.4.4. 命令列引數... 70
4.4.4.1. 系統屬性... 71
4.4.4.2. 單獨執行模式（ Standalone) 71
4.4.4.3. 管理域模式 (Managed Domain) 72
4.4.4.4. 其他命令列引數... 72
4.4.4.4.1. 單伺服器模式（ Standalone）... 73
4.4.4.4.2. 管理域模式 (Managed Domain) 73
4.4.4.4.3. 通用引數 (Common parameters) 73
4.4.5. 子系統配置... 74
4.4.5.1. 資料來源 (Data sources) 74
4.4.5.1.1. JDBC驅動安裝... 74
4.4.5.1.2. 資料來源定義 (Datasource Definitions) 75
4.4.5.1.3. 參考... 78
4.4.5.2. 訊息 (Messaging) 78
4.4.5.2.1. Connection Factories 78
4.4.5.2.2. Queues and Topics 79
4.4.5.2.3. Dead Letter和Redelivery. 80
4.4.5.2.4. 安全性... 81
4.4.5.2.5. 參考... 82
4.4.5.3. Web. 82
4.4.5.3.1. 容器設定 (Container configuration) 82
4.4.5.3.2. Connector設定 (Connector configuration) 84
4.4.5.3.3. Virtual-server配置（Virtual-Server configuration）... 88
4.4.5.3.4. 參考... 89
4.4.5.4. Web services 89
4.4.5.4.1. 參考... 90
- jboss各主要版本特性
1.1. jboss4特性
JBoss4包括web伺服器(servlet/JSP容器，HTML伺服器)、EJB2.0容器。完整的純Java的資料庫引擎，(Java訊息服務)JMS，JavaMail,和Java事務處理API/Java事務處理服務（JTA/JTS）支援。早期的JBoss使用了Apache Tomcat Web伺服器，但在JBoss4.0中已經吧Apache Tomcat內嵌到JBoss中了。後續又整合Java資料物件(JDO)，對於JMS多點傳送機制支援的修補，對J2EE1.4的完全實現和分散式事務機制。
JBoss的應用伺服器控制和配置－JMX機制，執行一次可以部署所有的元件和服務。資源屬性和可配置引數可以通過MBeans（可控制beans）對映和更改，這些控制可以在 JBoss的控制檯進行設定。一旦我們的servlet-based的應用程式被部署，JBoss就自動安裝一個部署MBeans,這個MBeans會被新增到JMX控制檯的導航選單中。通過這個MBean就可以部署或解除安裝WAR應用程式，或檢視應用程式相關的屬性。
JBoss 4基於JBoss 3.2,在J2EE標準特性方面，主要的改進包括：
l JBoss 4是業界第一家取得正式J2EE 1.4認證的應用伺服器，完全符合規範的J2EE標準。
l 完全支援J2EE web services（JAX-RPC方式和WS4EE架構方式）和SOA。
l 支援AOP模型,JBoss Aop極大的提高了生產力。
l 與Hibernate緊密整合。
l 通過一個內建的Caching構架提升叢集功能和分散式Caching（TreeCache）。
JBoss4完全遵循J2EE1.4標準，所以允許開發者在不同的應用伺服器上重用J2EE元件（如EJB等），比如可以輕易的將部署在Weblogic或Websphere上的EJB遷移到JBoss上賴，JBoss4比JBoss3.2實現了下面幾個新的J2EE標準：
l JBoss4支援J2EE Web Services，包括JAX-RPC和J2EE架構的Web Services，使用EJB提供安全的Web Service環境，它是基於J2EE的SOA實現。JBoss3.2中舊的JBoss.NET Web Services API不再支援，新的Web Service實現是WS BasicProfile-1.0 compliant。
l JBoss4實現JMS1.1替代了JBoss3.2中的JMS1.0
l JBoss4實現了JCA (Java Connector Architecture) 1.5替代了JBoss3.2中的JCA1.0
l JBoss4實現了新的Java Authorization Contract for Containers (JACC),JACC是JAVA2一個基本的許可權機制，為訪問EJB方法和web資源賦予授權描述，即J2EE應用伺服器和特定的授權認證伺服器之間定義了一個連線的協約，新的實現在語法上基於JBoss3.2，使用認證過的Subject宣告Roles，認證與JAAS的authentication保持一致。並且security配置，JBoss4和JBoss3.2相容。
l JBoss4實現了EJB2.1規範.替代了JBoss3.2中的EJB2.0規範。
JBoss4特性：
l JBoss4.2必須需要安裝jdk5
l JBoss Ejb3預設被安裝
l JBoss的web容器使用JBoss Web v2.x (整合tomcat6)
l deploy/jboss-web.deployer 目錄替換了原先的deploy/jbossweb-tomcat55.sar
l JBoss Transactions v4.2為預設的事務管理器
l JBoss WS提供web service功能
l JGroups/JBossCache支援 channel multiplexing
l JBoss Remoting更新到stable 2.2.x，JBossMQ(JBoss4.0使用)為預設JMS實現，但是可以使用JBoss Messaging替換。
l EJB呼叫方式 由 rmi-invoker替換為JBoss Remoting 的 unified-invoker
l log4j 和 commons-logging 升級到新版本。
1.2. jboss5特性
JBoss AS5中，大部分顯著的新特性新增都源自於要將所有主要的JBoss子系統帶到下一個階段去：
JBoss Messaging 1.4現在取代了JBossMQ，成為預設的JMS提供者。除了透明的故障恢復和智慧的訊息重分發外，JBM還支援即開即用的叢集佇列和主題。可以跨節點把訊息複製到記憶體中，從而避免磁碟I/O，或者能使用支援大訊息的分頁技術將訊息持久化到任何流行的關聯式資料庫中。JBM證明，利用已完全出現的新的只擴充套件日誌儲存，原本就很卓越的效能和東西會變得更加優秀。
JBoss WebServices 3.0，完全支援JAX-WS/JAX-RPC、XOP和SwA的附件、還有一系列WS-*標準。JBWS轉向了一個可插拔的架構，該架構允許更換底層的WebServices棧，所以你可以將JBossWS-native換成Sun Metro或Apache CXF。這樣的話，你就可以因地制宜，使用最合適WebServices棧。
為了改進可伸縮性和叢集Web會話的鈍化，AS5中的叢集支援SFSB的Buddy複製，以控制記憶體的使用。EJB3 Entity和Hibernate快取有了很大的改進，因為可以針對實體和查詢使用不同的快取，它們分別是失效快取和複製快取。在底層的JGroups協議棧中，還有一些其它的效能優化。
JBoss Transactions是JBoss 5預設的事務管理器。JBoss TS已經與JBoss 5的Servlet容器——JBoss Web——一起在AS 4.2系列中進行了測試，JBoss Web是基於Apache Tomcat的一個實現，支援原有的APR-based聯結器，它在可伸縮性和效能上不但要達到，而且要超越Apache Http伺服器的水平。
就API來說，AS5是Java EE 5的實現，所有相關的API都會包含在內。對大部分Java EE 5“新的”API來說，比如EJB3、JAX-WS、JPA等，在JBoss AS 4.2系列中已經實現了，但由於JBoss AS5增加了TCK測試的覆蓋範圍，所以肯定會更為嚴格遵循規範。
JBoss5應用伺服器提供了大量的新功能：除了支援最新的EJB 3.0規範外，新版的JBoss AOP也正式釋出。Web Services 方面，JBoss 現在支援全部的J2EE Web Services，同時相容Microsoft.NET；Messaging 專案採用了完整的JMS 1.1 實現，同時充分的改進了分散式目的單元格等功能的高可用性；JBoss Seam 中包括了一系列統一的革命性的組建設計模型和框架。同時JBoss 5中也整合了Hibernate 3.2
JBoss AS 4.2和企業應用平臺的第一個版本（EAP 4.2）確實對AS 5造成了很大的影響。從零開始建立一個全新的核心、從MBeans轉換到POJO、在最底層整合AOP、統一跨子系統的後設資料處理、更改類載入系統、使部署器Aspect化，換句話說，就是改變內部架構、替換應用伺服器的核心，同時還要保持與大部分已有服務的向後相容性，為各種內部子系統引入合適的SPI。長遠看來這是好事，因為它允許最大的可插拔性，以及在不同的執行時環境中（比如獨立的EJB3或嵌入到不同的應用伺服器中）按需要選取使用各種JBoss專案。
JBoss AS5不只是一個Java EE 5應用伺服器。對下一代JBoss專案來說，它還寄託了成為最先進的伺服器執行時環境的願景。
1.3. jboss6特性
JBoss AS6 最大亮點是對Java EE 6 Web Profile規範的支援，一份關於最流行的Java EE標準的報告中，排名前5（JPA、JSP、EJB3、JSF及CDI）的都是Java EE Web Profile的必備元件。除了Java EE 6 Web Profile所需的這些元件外，AS 6還提供了可選的經過認證的元件：RESTEasy 2.1.0——JAX-RS 1.1規範的實現；HornetQ 2.1.2——JMS 1.1規範的實現以及JBoss Web Services CXF棧——JAX-WS 2.2規範的實現。
主要特性就是對JBoss Injection框架的完整實現。這對於滿足Java EE 6平臺規範所要求的Resources、Naming以及Injection是至關重要的。Infinispan v4.2.0是個開源的資料網格平臺，從CR1里程碑釋出時就加入了，現在它也整合到了JBoss AS 6中，並且是預設的分散式快取提供者。Infinispan公開了一個相容於JSR-107的Cache介面，你可以將物件儲存其中。JBoss AS 6伺服器可以動態探測並註冊到前端的apache httpd伺服器。
對於效能來說，JBoss AS 5與6之間有明顯的變化。JBoss AS 6對啟動效能的提升很明顯，現在的平均啟動時間是15秒。使用者能夠感覺到這種改進，一定程度上是因為延遲了隨AS一同釋出的管理控制檯應用的部署，轉而以“按需”方式提供，同時還實現了Timer Service的延遲部署。Microcontainer（v2.2）的增強（包括新的註解掃描庫的實現）極大降低了應用部署的時間。
1.4. jboss7特性
JBoss AS7可實現為雲做好準備的架構，並可使啟動時間縮短十倍，提供更快的部署速度並降低內在的佔用。JBoss Enterprise Application Platform 6的核心是JBoss Application Server 7的最新版本，該版本代表著Java應用伺服器在從複雜和單一的形式轉向更加輕便、模組化和敏捷的變革過程中的一個意義重大的里程碑。 該版本將使開發人員有重新思考如何開發和部署企業Java應用。
JBoss Application Server 7構建於先前版本的良好基礎之上，並提供更出色的效能、更低的記憶體佔用率、分散式管理和Java EE6 Web Profile認證。它的新能力包括：
l Java Enterprise Edition（EE）6 Web Profile認證，一種輕型的標準可移植Java EE，專為開發和部署豐富的交換式Web應用而進行了優化。
l Java上下文和依存關係插入（Java Context and Dependency Injection – CDI），這種標準化的統一框架支援型別安全的依存關係插入和定義完善的上下文生命週期，通過簡化和優化程式碼的方式實現了程式碼的輕鬆編寫、測試和維護。
l Arquillian測試，改善了對測試驅動式開發的支援，提供了遠端和嵌入式元件測試，且不會生產完整企業Java容器所帶來的不必要複雜性。
l 構建於輕型的高度優化的模組化服務容器和新型域模型基礎上，使JBoss Application Server 7能夠從最小的裝置擴充套件至更大的關鍵任務叢集。
l 通過基於Eclipse的JBoss工具來提供開發人員工具支援，改善了對Java CDI、休眠、代表性狀態傳輸和Web服務的支援。
l 全新的複雜域模型和豐富的管理API，可實現強大的伺服器和叢集自動化。
- 為什麼JBoss AS7 這麼快
JBoss7專案lead Jason Green,最近在他的blog 上，回答了這個問題. 以下是這篇blog的譯文：
用Ahmdahl法則(高效並行)而不是Moore定律(等待硬體能有更高的時脈頻率)來設計JBoss7. 目前幾乎每臺桌上型電腦，筆記本和伺服器都至少有兩個CPU核心，而且多核的趨勢還在繼續。 CPU 時脈頻率競爭的時代其實已經終結。所以軟體也必須要適應這一趨勢，充分利用硬體的計算能力。
JBoss AS進行了一次重大的改變來獲得這一關鍵的演進(evolution).我們重寫了AS7,使得它的整個架構是一個全新的，高效能的和可管理的。在令人驚談的工程師的努力下，我們從在github上一個很小的原型，在一年多的時間裡實現了今天看到的具有巨大工作量的遵循Java EE Web Profile標準的J2EE伺服器(更不用說我們在這期間釋出了AS6,使得JBoss的使用者可以早點得到關於EE6的新特性，新技術)。
在開始詳細的解釋以前，請允許我給出一些背景知識。應用伺服器的核心問題是管理服務(service).在現代的應用伺服器中幾乎所有的部件都有生命週期，那就意味著在特定的時間點上，這個部件必須被啟動，在以後的時間點，它必須被停止。 我們將所有具有生命週期的物件都看作是一個service.另外一個service重要的屬性是，service和service的之間的依賴關係會影響到相應service的生命週期。舉個例子，servlet的service依賴於web server.另外，如果這個sevlet使用到其他的資源，比如資料庫連線或者是EJB,那麼它也依賴於這些資源，這些依賴的資源可用以後自己才能啟動。 但一個應用伺服器啟動或者部署時，它必須保證它能夠按照正確的順序將各種service啟動。進一步，如果任何服務由於某種原因停止了，它必須能停止所有依賴於這個service的其他sevice(以相對於啟動相反的順尋停止).這在單執行緒的環境下是一個簡單的問題。
但JBoss AS7實在並行的啟動和部署這些服務。這個複雜的問題通過我們全新的服務容器解決: JBoss Modula Service Container. MSC是一個高階的並行狀態機。它在執行中分析服務之間的依賴關係，並且在同一時間儘可能多的啟動服務，但同時又遵循服務間的依賴關係。這就意味著不僅能夠快速啟動，而且能夠並行的進行部署。
除了並行的service,JBoss AS7還有類模組化和並行的類載入技術。通過將類劃分到恰當的類模組中，應用伺服器可以自然地優化訪問模式，僅僅查詢一個點，就可以獲得所需要的類。另外，由於限制了類模組之間的可見性，查詢就沒有沒有那麼大的開銷。對於JBoss Modules, 類模組解析和查詢的時間複雜度是O(1).所有的這些操作都有很高的並行性，甚至大部分的類定義也是並行的。
AS7對部署的處理也是高效的。一個主要的優化是我們通過快速掃描部分class來對annotation資訊進行索引。為了取得更好的效率，我們允許模組預先生成空間效率指數(space efficient index)來更快的載入。另外一個部署時的優化，是我們謹慎的緩衝和再使用relection data，因為JVM在這方面不是很有效率。
最後，另一個重要的原因我想強調的是我們已經並且會繼續會守護CPU和記憶體在啟動和部署方面的使用情況(儘可能的少佔用記憶體和CPU，做到儘可能的高效）。這就是在設計階段就作出的好決定。一個有趣的例子是我們不再使用JAXB(或者其他內省機制驅動的繫結器)來解析只讀一次的配置檔案。JAXB或者其他採用內省機制的繫結器帶來的是幾乎用和真正做實際解析工作一樣或者更到時間來處理如何解析。所有的這些意味著: 在AS5和AS6裡處理XML的時間都比AS7的啟動時間要長。
希望這些內容能夠更好的從大的方面理解AS7如何獲得高效性得以快速啟動，為什麼JBoss7與過去有很大的不同。這篇部落格只是一個開始，繼續關注我的下一個blog,我將討論Jboss7的roadmap
- JBoss AS7中的新概念－域
JBoss AS7新加入了域（domain）的概念並實現了相關功能。域的提出及實現，其目的是使得多臺JBoss AS伺服器的配置可以集中於一點，統一配置、統一部署，從而在管理多臺JBoss AS伺服器時，實現集中管理。本文詳細介紹如何使用AS7的這一新特性。
3.1. 域(Domain)的概念及其與群集(Cluster)的區別
對於使用過JBoss AS過往版本的使用者，可能對AS所提供的群集功能已經很熟悉了，在理解域的時候可能會遇到困難。那麼域和群集有什麼區別，用處上有什麼不同呢？
總的來講，JBoss的群集的目的是提供：
l 負載平衡（Load Balance）
l 高可用（High Availablity）
而域的目的則是將多臺伺服器組成一個伺服器組（Server Group），併為一個伺服器組內的多臺主機（Host）提供：
l 單點集中配置（通過一個域控制器，即Domain Controller，實現組內主機的統一配置）
l 單點統一部署，通過域控制器將專案一次部署至組內全部主機。
簡單來講，群集的目標是讓多臺伺服器分攤壓力，當一臺或多臺伺服器當機時，服務可以繼續保持運轉；而域的目標則是提供集中配置和管理多臺伺服器的能力。
在沒有域的概念時，要想讓群集內的多臺伺服器或幾組伺服器保持統一的配置，一個一個分別的去手工維護，是非常麻煩的事情，而域的引入解決了這一問題。
我們可以理解域和群集的相互關係是"正交（orthogonal）"的：通過一橫一豎這兩條軸，JBoss AS為我們在運維方面提供了強大的可擴充套件能力。
3.2. 實驗
熟悉了AS7中Domain的設計理念，接下來動手實際做個實驗，看看Domain是如何在AS7中工作的。
1.1.1. 準備工作
使用兩臺電腦做為實驗器材，兩臺電腦的IP分別為10.0.1.3及10.0.1.18，分別執行JBoss AS7，並組成一個伺服器組（Server Group）。其中，使用10.0.1.3這臺機器做為域控制器（Domain Controller）：
如上圖所示，兩臺主機分別被命名為”master“及”slave“。通過配置，將master與slave組成一個伺服器組，名為'main-server-group'，其中master將做為這個伺服器組的域控制器。
需要說明一點的是，伺服器組(Server Group)可以由多臺伺服器(Host)組成，並不一定只有兩臺，所以不要被master及slave這樣的名字給迷惑了，以為一個伺服器組僅支援一主一從兩臺hosts。
本文中因為只使用兩臺伺服器做為實驗器材，因此出於方便角度將它們分別命名為master及slave。
此外，在一個伺服器組中，只有一臺域控制器，在本實驗中我們將使用master這臺機器做為domain controller。
1.1.2. 配置
AS7由於經過了重新設計，因此在目錄結構與配置檔案上面與前一版本有了很大不同，對於熟悉了對AS6的配置和的人來講，使用AS7會接觸不少新概念和新思路。為了清楚表達，我會將一些與AS6及以前版本不同的地方做出必要的說明。
首先是bin目錄中的內容：
在AS7以前版本中，用來啟動JBoss服務的run.sh不見了，取而代之的是standalone.sh（獨立執行模式）及domain.sh（域執行模式）。我們稍後將使用domain.sh來執行JBoss AS7，但首先要將兩臺hosts配置好，接下來講解兩臺伺服器的配置：
AS7的目錄結構和前一版本有很大不同，因為配置檔案及其所在位置也有很大變動，下面是AS7的目錄結構：
可以看到有一個名為"domain"的目錄，看一下這個domain目錄裡面的內容：
這個目錄中包含了AS7執行在domain模式下所需的配置及內容，其中名為“configuration”的目錄裡面含有我們所需要的配置檔案：
其中domain.xml和host.xml是我們需要關注的內容。我們需要對master及slave上面的配置檔案分別進行配置：
從上圖中可以看到，master的JBoss
AS中需要配置domain.xml及host.xml兩個檔案，其中domain.xml是做為域控制器必須配置的內容，host.xml則是master及slave各自的JBoss
AS都需要配置的檔案。我們先從master上面的配置看起：
3.2.1.1. Master上面的配置
3.2.1.1.1. domain.xml
這個檔案裡面有幾個部分是值得我們關注一下的：
# extensions - 這一部分定義了域中伺服器在啟動時需要載入的模組。AS7使用了全新設計的JBoss Modules來載入模組，大幅提高了伺服器的啟動。這一內容不是本文講解重點，後續我會專門寫一篇文章來介紹。目前瞭解到這一程度即可。
# profiles - profiles是domain中定義的一個核心概念，也是domain的核心組成部分。基於profiles，AS7便實現了域中各伺服器的統一集中配置：使用者可通過profile對各子系統（subsystem）進行配置，完成後將profile配置給某個或多個伺服器組，各伺服器組內的主機共用一份配置。
# server groups - 伺服器組的概念已經在前面的介紹中一再提及，也是AS7的域的設計中一個核心組成部分。在這裡，AS7預設定義了兩個伺服器組：main-server-group及other-server-group，它們分別使用'default' profile及'ha' profile。在本實驗中，我們將使用main-server-group。
3.2.1.1.2. host.xml
上面是一些host.xml中需要配置的關鍵內容，已經針對要做的測試做了一些配置上面的修改，以下是詳細說明：
# host name按照我們的需要改成了"master"。
# management - management定義了伺服器的管理埠，其中：9999埠是所謂"native"二進位制埠，後面的jboss-admin.sh管理命令會使用這個埠；9990則提供基於WEB頁面的管理端。我們等一下兩種管理埠都會用到。
# domain controller - 定義本伺服器所需連線的domain控制器所在地址，因為master本身就是domain controller，所以連線至本機localhost即可。
# interfaces - management及public介面服務所在的地址，我們要將其設為slave可以訪問到的IP地址，保證slave可以連線至host
# servers - 一個物理主機實際上可以同時執行多臺JBoss AS7的Server，而每一臺Server都可以配置到不同的伺服器組去。在本實驗中，我們使用最簡的情況，master上面只跑一個server-one，屬於main-server-group，把其它AS7預設設定的server可以都刪掉，只留server-one。
3.2.1.2. Slave上面的配置
3.2.1.2.1. domain.xml
Slave這臺機器不作為域控制器而存在，因此不需要管它，也可以將domain.xml刪掉或改名。
3.2.1.2.2. host.xml
上面的配置有幾點需要說明：
* slave裡面，host name指定為"slave"。
* domain-controller：指定為master的IP：10.0.1.3，通過9999管理埠進行通訊。
* slave上面，屬於main-server-group的server也命名為"server-one"，這會和master上面的server衝突嗎？實際上不會，因為兩臺同樣名字的server執行在不同的host當中。
3.3. AS 7.1的安全補充說明
從JBoss AS 7.1 開始，對控制埠（9999及HTTP端的9990）的安全配置成為必須。因此需要補充下述安全配置方面的步驟：
首先要在master上面建立管理員的賬號，在bin目錄下有add-user工具可以幫我們建立賬號密碼並進行配置，我們建立一個管理員賬號admin，密碼為123123：
可以看到系統為我們分別在domain和standalone建立了mgmt-users.properties，我們是用域模式執行，因此檢視domain/configuration/mgmt-users.properties這個檔案的最後一行：
可以看到相關賬號密碼已經被建立。此時檢視host.xml：
可以發現host.xml已經把安全配置應用起來了，使用ManagementRealm這個安全域進行認證。
同樣地，我們需要在slave主機上進行一模一樣的工作。
接下來，我們需要做一下slave對master的認證連線工作。slave要想和master建立域控關係，需要知道master的管理端賬號密碼。在域控這一塊，AS7對認證有要求：需要在域控制器上以過來連線的主機host名為使用者名稱新增賬號。
我們在slave的host.xml檔案中指定了slave的host名為slave：
因此，master做為域控制器，需要在上面新增名為slave的管理員賬號，密碼仍為123123：
master:~/projs/as7/710/bin$ ./add-user.sh
Enter details of new user to add.
Realm (ManagementRealm) :
Username : slave
Password :
Re-enter Password :
About to add user 'admin' for realm 'ManagementRealm'
Is this correct yes/no? yes
Added user 'slave' to file 'master/as7/710/standalone/configuration/mgmt-users.properties'
Added user 'slave' to file 'master/as7/710/domain/configuration/mgmt-users.properties'
這時再檢視mgmt-users.properties，可以看到多了slave賬號：
接下來，我們要在slave主機的的host.xml做下認證配置，使用這個賬號與master進行認證通訊：
上面的配置中有這些值得注意：
我們在認證域ManagementRealm中配置了server-identities，這個認證域用在與域控制器master的連線方面。其中secret value是domain上對應slave主機名的那個賬號的密碼，用base64加密。我們在master上面配置的slave賬號的密碼為123123，MTIzMTIz=則是123123的base64加密後的文字。這個配置用在連線domain-controller時進行認證：
有關更多的AS7的安全配置的資訊，可檢視官方文件：
關於host.xml的詳細配置方法，也可參考as7目錄下自帶的xsd文件：
3.4. 部署
配置完成後，接下來便到了實際部署的階段，我們將master和slave上面的AS7分別用domain.sh啟動起來。
啟動成功的話，應該可以在master上面看到上面的日誌，slave被成功的註冊進來。
完成啟動後，我們需要將待使用的virtual-host啟動起來，當AS7以domain的方式啟動時，預設是不啟動任何virtual server的（在我目前使用的7.0.0 CR1 White
Rabbit版本中是這樣），我們可以在domain.xml中配置預設載入virtual-host，也可以在伺服器執行起來後，使用管理端命令動態的載入，在這裡我準備使用後一種方式，從而講解AS7管理端的使用方法。
在AS7的bin目錄下面有一個jboss-admin.sh， 這是AS7提供的全新的管理工具，我們使用這個工具，連線至master：
可以看到，我們已經連線到了master的9999管理埠。接下來可以檢視"default"這個profile當中的web模組的執行情況：
可見http伺服器已經啟動，由於我們的"main-server-group"使用的是default這個profile，因此，伺服器組中的兩臺host的web模組接受profile的統一配置，都是已啟動的。繼續看一下web模組中的細節：
注意到virtual-server的狀態是未定義（undefined），我們要想將一個web專案部署進伺服器組中的各個host，就必須載入一個待部署的virtual-server，因此我們使用命令來新增：
可以看到，我們之前在domain.xml中配置的 "other.com" 這個 virtual host被成功新增了。
接下來是部署WEB應用的環節，我們首先用maven製作一個最簡單的web專案，僅包含一個歡迎頁面：
生成的專案如下：
使用如下命令將專案打成WAR包：
得到war：
接下來是部署這個war包，對於本次實驗來講，關鍵的部分在於能否通過domain提供的server group管理功能，一次將一個專案部署進server group中的多臺伺服器。我們接下來就驗證這點，順便看下AS7提供的WEB管理功能，開啟WEB瀏覽器，訪問master的HTTP埠的管理地址： 可以看到，管理頁識別出AS7正執行在domain模式之下，並且目前共有兩臺主機執行（左上角的列表分別列有master及slave）。我們要關注的是server-group：點選右上角的"Server Groups"，進入伺服器組的管理頁面，然後點選左邊的"Manage Deployments"頁面，進入部署功能頁面：
可以看到，目前還沒有任何資源被加至伺服器組，此時點選右邊的"Add Content"功能，將my-webpp.war新增進Content Repository（域控制器用於儲存待部署資源的目錄）。
新增完成後如下圖所示：
然後點選"Add To
Group"將my-webapp.war新增至
"main-server-group"，並將其enable，一切順利的話結果如下所示：
此時我們預期的結果應該是my-webapp.war被同時部署至master及slave了，分別試著訪問master及slave的http資源，看看是否都部署上my-webapp這個應用了：
結果如我們所預期的那樣，兩臺伺服器都可以訪問到這個部署的資源。通過對一個點（Domain Controller）的配置與部署，我們實現了多AS7伺服器的集中管理。
3.5. 小結
通過域這個概念，實現了多伺服器統一管理，統一配置，資源統一部署的目標。通過集中管理，我們可以在此基礎上再進行群集的劃分與部署，實現群集內多臺伺服器的單點配置與管理。可以說AS7的Domain概念的引入，與群集的概念組合在一起，通過一橫一從兩條軸，形成了完整的座標系。
4. JBoss7配置
4.1. 目標聽眾
這篇文件是為需要安裝配置JBoss Application Server(AS7)的人員編寫。
4.1.1. 開始之前
你需要知道如何下載，安裝和執行JBoss Application Server7. 如果你還不瞭解這些資訊， 請參考“入門指導"。
4.1.2. 手冊中的示例
手冊種大部分的例子會使用部分XML配置檔案或者是de-typed的管理模型進行表示 。
4.2. 客戶端
JBoss AS7提供三種不同的方式對伺服器進行配置和管理: web，命令列和xml 配置檔案形式。無論你選擇什麼樣的配置方式，配置資訊都會被同步到各個方式的管理介面上，並且被儲存到xml配置檔案中。
4.2.1. web介面
web管理客戶端是一個GWT的應用，它通過HTPP管理介面來管理域(domain)或者是單獨執行(standalone)的伺服器。
4.2.1.1. HTTP管理接入點
基於HTTP協議的管理接入點負責接入 使用http協議與管理層進行互動 客戶端。它負責接收使用JSON編解碼的協議和de-typed RPC形式的的api來對可管理的域伺服器或者單獨執行伺服器進行管理操作。web控制檯就是通過它來實現的，但基於HTTP協議的管理接入點也可以與其他的管理終端進行整合，互動。
基於HTTP協議的管理點會執行在域控制器(domain controller)或者是單獨執行伺服器上，預設執行在9990埠上。
基於HTTP協議的管理接入點執行在兩個不同的context下。一個用於執行管理的操作 另外一個提供對web管理介面的訪問。
l 域API: http://<host>:9990/management
l Web控制檯: http://<host>:9990/console
4.2.1.2. 訪問管理控制檯
管理控制檯和基於HTTP協議管理的API在統埠上執行，可以通過以下URL進行訪問：
l http://<host>:9990/console
4.2.1.3. 對管理控制檯進行加密
web管理控制檯通過HTTP管理介面來對伺服器進行通訊。對於如何機密HTTP管理介面以及如何啟用預設的安全域，請參考一下本文中關於“加密管理介面"章節。
4.2.2. 命令列介面
命令列方式的管理工具（CLI）提供了對域和單獨執行伺服器的管理。使用者可以使用命令列來連線域伺服器或者單獨執行伺服器,通過傳輸de-typede的管理模型來執行管理操作。
4.2.2.1. Native管理接入點
Native的管理接入點負責接入使用AS內部協議與管理層進行互動的客戶端.它使用基於java物件來描述的管理操作、二進位制協議和RPC形式的API來對域和單獨執行伺服器進行管理操作。命令列方式的管理工具使用它來實現對伺服器的管理，單Native管理接入點也提供了極強的整合能力，可以和其他的客戶端進行整合。
Nativeg管理接入點執行在host控制器上或者是一個單獨執行伺服器上。如果使用命令列管理工具，Native管理接入點必須被啟用.預設Native管理接入點執行在9999埠上：
4.2.2.2. 執行命令列管理工具
根據作業系統，使用JBossAS7 bin目錄下的jboss-admin.sh或者jboss-admin.bat來啟動命令列管理工具.關於AS7目錄的詳細資訊，請參考"入門指南"。
命令列工具啟動以後的第一件事情就是連線被管理的Jboss AS7例項。我們通過命令connect進行：
localhost:9999 是JBossAS7域控制器客戶端連線的預設主機和埠名.主機名和埠都是可選的引數，可以被單獨或者一起指定。想要退出對話，可以鍵入quit命令來結束。
help命令用來顯示參考幫助文件：
檢視特定命令的詳細幫助文件，需要在命令後加"--help"引數來獲得。
4.2.2.3. 管理請求
管理請求允許與管理模型進行低階別的互動。它不同於高階別的命令(比如建立一個jms的queue命令:create-jms-queue),使用管理請求可以對伺服器的配置像對直接對xml配置檔案進行編輯而進行讀和修改操作。整個配置用一個有地址的資源樹進行表示，這個樹上的每個節點提供一系列的操作供執行。
一個管理請求包含三個部分：地址，操作名和可選的操作引數
這是一個管理請求的規約：
舉個例子：
管理請求字串之間的空格是不敏感的。
4.2.2.3.1. 管理資源的地址
管理請求可以不含有地址資訊和引數,比如::read-resource, 可以列出當前Node下的所有節點型別。
在管理命令中，為了消除歧義需要以下幾個字首：
l " : " --- 在當前節點上執行操作，比如：
[subsystem=web] :read-resource(recursive="true")
l " ./" ---- 在當前節點的子節點上執行操作,如：
[subsystem=web] ./connector=http:read-resource
這個操作的全路徑地址是: subsystem=web,connector=http.
l " /" --- 在根節點上執行操作,如：
[subsystem=web] /:read-resource 或子節點: [subsystem=web] /subsystem=logging:read-resource
4.2.2.3.2. 操作型別和操作描述列表
操作的型別可以分為在任何節點上的通用操作和在特殊節點上的特殊操作(如:subsystem).通用的操作包括：
對於特殊操作列表（比如在logging子系統上可以進行的特殊操作),可以通過管理的節點進行查詢。比如，查詢一個單獨執行伺服器上logging子系統上所支援的操作：
可以看出，logging支援三個額外特殊的操作:change-root-log-level , set-root-logger and remove-root-logger
進一步關於被管理節點描述或者被管理節點上操作的描述，可以通過一下命令查詢：
4.2.2.4. 命令列歷史資訊
命令列(和操作請求)歷史資訊預設是開啟的。歷史資訊在記憶體中和硬碟檔案中都有儲存,並且命令列歷史資訊在命令列對話之間儲存。
命令列歷史資訊檔案資訊儲存在名為.jboss-cli-history的檔案中，這個檔案會在使用者的home目錄下自動建立。當啟動命令列模式時，這個檔案會被讀入記憶體中來對初始化命令列歷史資訊。
在命令列對話中，你可以使用上下鍵來向前和向後查閱命令列歷史資訊。
命令列歷史可以通過history命令進行操作。如果history命令執行時不帶引數，它會將記憶體中所有的歷史命令和操作列印出來(取決於歷史資訊的最大個數，預設500). history 命令支援3個可選的引數：
4.2.2.5. 批處理
批處理模式允許使用者以將一組命令和操作按照原子的方式執行。如果一個命令或者操作失敗，那麼在批處理中成功執行的子命令將會被回滾。
不是所有的命令都可以批處理種執行。比如: cd, ls, help等不能被轉換成操作請求的就不可以在批處理種執行。 只有可以轉換成為操作請求的命令才可以在批處理種執行。批處理的命令實際上是以組合操作請求的方式執行的。
執行batch命令進入批處理模式：
run-batch執行一個批處理：
退出批處理編輯模式並且不丟失更改：
稍後重新啟用批處理：
還有一些比較重要的批處理命令(使用tab補全來檢視以下列表)：
4.2.3. 配置檔案
域管理和單伺服器的xml配置可以在configuration子目錄下找到：
一個被管理的域有兩種型別的配置:一種是對整個域的配置(domain.xml)另外一種是對每個加入到域裡主機(host)的配置(host.xml).關於如何配置域拓詳細資訊請參考"域配置"章節。xml配置是核心可靠的配置源。任何通過web介面或者命令列方式對配置的更改都持久化到XML配置檔案中.如果一個域或者單獨伺服器離線,xml配置檔案也可以進行手動更改，任何更改都在下一次啟動時生效。
但是，我們鼓勵使用者使用web介面或者命令列方式更改配置檔案，而不是採用離線編輯的方式對配置檔案進行更改。對正在處理的配置檔案進行的外部更改將不會被探測到，從而有可能會被覆蓋。
4.3. 核心管理概念
4.3.1. 執行模式
JBoss Application Server 7可以被啟動到兩個不同的模式.域模式可以用來執行和管理多個jboss伺服器的拓撲， 或者是單伺服器模式，僅執行一個伺服器的例項
4.3.1.1. 單伺服器模式
對於大多數的使用來說，通過管理域實現的中心管理能力是不需要的。對於這些使用場景，一個jboss7的例項可以被執行成單伺服器模式。一個單伺服器的例項是一個獨立的程式，像JBoss3 ,4,5 或6的例項，可以通過standalone.sh或者standalone.bat進行啟動。
如果需要多個伺服器的例項或者多伺服器的管理，那麼就需要使用者來協調管理多個伺服器。比如:在所有的單伺服器上部署一個相同的應用，使用者需要在每臺伺服器上進行操作。更為可能，使用者會啟動多個單獨執行的伺服器來組成高可用的叢集，就像是使用JBoss 3, 4 5和6那樣。
4.3.1.2. 管理域
JBoss7一個最重要的新特性就是可以通過一個管理點來管理多個JBoss7伺服器例項.一個域包含一個DomainController程式（域的中心管理點），這些被管的伺服器是這個域的成員。
在這個域裡所有的伺服器例項共享統一的管理策略，域控制器來保證每個伺服器都使用這一管理策略來配置。域可以橫跨幾個物理（或者虛擬)機器，所有的JBoss7服務例項執行在一個受HostController程式控制的給定主機（host)上。一個HostController的例項會被配置成為中心的DomainController.在每個主機上的HostController可以與DomainController進行互動來控制執行在自己主機(host)上伺服器例項的生命週期，並且幫助DomainController來管理。
當你通過domain.sh或者domian.bat來在一個主機上執行JBoss7管理域時，那麼你的意圖是去執行一個HostController，並且一般是至少執行一個JBoss7的伺服器例項,而且在主機上的HostController應該被配置來充當DomainController.
下圖是一個管理域的拓撲：
4.3.1.2.1. Host(主機)
上圖中的每個Host方框代表一個物理或者虛擬的主機。一個物理的主機可以包含零個，一個或者多個伺服器例項(server instance)。
4.3.1.2.2. 主機控制器(HostController)
當domain.sh或者domain.bat在主機上執行時，一個叫HostController的程式也會被啟動。HostContoller只負責管理伺服器例項；它不會處理伺服器例項的日常工作。HostController負責在自己的主機上啟動停止單個伺服器例項的程式，並且與DomainController進行互動來管理這些伺服器例項。
HostController預設在主機檔案系統中JBoss7安裝目錄下讀取domain/configuration/host.xml檔案。host.xml檔案主要包含特定主機的資訊：
主要是：
l 在安裝要執行的JBoss7伺服器的例項名。
l 關於HostContraller如何與DomainController聯絡，並且註冊到DomainController種來獲取配置的資訊。這個配置資訊可以是如何查詢聯絡一個遠端的DomainController,或者是告訴HostController本身就可以充當DomainController
l 特定於本地安裝的各種配置資訊，如在domain.xml裡(見以下內容)中interface的配置資訊可以被對映成host.xml中的IP地址資訊。在domain.xml中的抽象路徑資訊可以被對映成host.xml的真實檔案系統資訊。
4.3.1.2.3. Domain Controller(域控制器）
一個HostController的例項被配置成整個域的中心管理點，就成為了DomainController.DomainController的主要負責維護域的管理策略，保證所有的HostController能夠獲取目前的配置資訊，以及協同HostController來保證執行的伺服器例項都根據當前的策略來配置。中心管理策略預設儲存DomainController安裝主機的domain/configuration/domain.xml中。
domain.xml必須位於執行Domain Controller Jboss7安裝目錄下的domain/configuration. 如果不作為Domain Controller執行的AS7則不需要這個檔案;比如執行連線到遠端DomainController的HostController的伺服器。但不作為DomainController執行HostController的AS7安裝中存在這個檔案，也不會有影響。
domain.xml檔案包括各種配置，在Domain下的JBoss7的例項可以配置各種profile去執行。一個profile的配置包含各種組成profile的subsystem的詳細配置資訊(比如，一個整合的jboss web例項就是一個subsystem,一個JBoss TS的事務管理器也是一個subsystem）.Domain的配置資訊也包括在subsystem需要用到的socket組的定義。Domain配置資訊也包含Server group的定義。
4.3.1.2.4. Server Group (伺服器組)
Server group是一組被統一管理和配置的伺服器例項。在一個管理域裡，每個伺服器例項都是伺服器組的一個成員(即使是一個組裡只有一個伺服器，這個伺服器仍然是一個組的成員)。Domain Controller和Host Controller會保證在一個server group裡所有的server具有一致的配置。這些伺服器被配置成同樣的profile,並且部署相同的內容。
一個domain可以有多個server group.上面的圖示種給出了兩個server group： "ServerGroupA"和“ServerGroupB"。不同的Server group可以被配置成不同的profile和部署不同的內容:比如在一個domain在不同層的伺服器來提供不同的服務。不同的Server group也可以執行同樣的profile，部署相同的內容；比如對應用進行升級時候，為了避免整個服務不可用，可以首先對一個server group中應用進行升級,然後再對另外一個sever group升級。
sever group定義的例子如下：
<server-group name="main-server-group" profile="default">
<socket-binding-group ref="standard-sockets"/>
<deployments>
<deployment name="foo.war_v1" runtime-name="foo.war" />
<deployment name="bar.ear" runtime-name="bar.ear" />
</deployments>
</server-group>
一個server-group的配置包含以下不可預設的屬性：
l name -- server group名
l profile -- server執行在的profile名
另外，還有以下可選配置：
l socket-binding-group -- 定義在server group中用到的預設的socket binding group名， 可以在host.xml裡覆蓋。如果在server-group裡沒有定義，那麼必須在每個server的host.xml裡定義。
l deployments -- 在組伺服器要部署的內容。
l system-properties -- 組伺服器種要設定的所有的system properties
l jvm -- 在組伺服器種預設的jvm設定。Host Controller將會合並在host.xml裡提供的屬性，並且用這些屬性來啟動伺服器的JVM.詳細配置資訊選項請參考JVM配置。
4.3.1.2.5. Server (伺服器）
在上述圖表中的server表示一個實際的應用伺服器例項。Server執行於獨立域HostController的JVM程式中。Host Controller負責啟動這一JVM程式。(在管理域裡，終端使用者不能直接從命令列裡啟動一個server程式)。
HostController合併整理domain.xml裡的域配置資訊和從host.xml上獲得的主機配置資訊。
4.3.1.3. 決定執行在單獨伺服器或者管理域上
什麼用例適合管理域，什麼適合單獨伺服器(standalone server)？管理域協調多個伺服器的管理--通過JBoss7提供的中心節點，使用者可以管理多個伺服器,通過域管理的豐富功能來統一伺服器的配置，通過協調方式將伺服器配置變更(包括部署內容）在各個伺服器上生效。
重要的是要理解選擇管理域和單獨伺服器要根據你的伺服器是如何管理的,而不是根據為終端使用者請求提供什麼樣服務的能力。管理域和單獨伺服器的差別對於高可用叢集也是十分重要的。理解高可用性對於執行的單獨伺服器和管理域是正交的。也就是說,一組單獨伺服器可以被配置成為高可用性叢集。管理域和單伺服器模式決定伺服器是如何管理的，而不是他們所提供的功能：
所以,考慮到以上原因：
l 如果只有一個伺服器，執行在域模式下不會有更多的好處,執行在單伺服器模式下是更好的選擇。
l 對於多伺服器生產環境，執行在域模式和單伺服器模式下取決於使用者是否想使用管理域提供的中心管理。某些企業已經開發出自有成熟的多伺服器管理方式，並且能夠輕鬆協調管理多個單獨伺服器。讀於這些企業，由多個單獨執行伺服器組成的多伺服器架構是一個好的選擇。
l 單伺服器更適合與大多數的開發環境。任何在管理域下執行的伺服器的配置都可以在單伺服器模式執行的伺服器獲得,因此即使應用是將來要執行在域管理模式的生產環境中，很多(幾乎是全部)開發都可以在單伺服器模式下進行。
l 執行管理域對於一些高階的開發是有幫助的。比如:需要多JBoss7伺服器例項之間進行互動的開發。開發人員會發現配置多個伺服器作為域成員是進行多服器叢集的有效方式。
4.3.2. 通用的配置概念
以下通用的配置概念對於管理域模式和單服器模式都適用：
4.3.2.1. Extensions (擴充套件)
一個擴充套件(是一個能擴充套件伺服器功能的模組）. JBoss 7的核心是簡單清量級的。所有使用者需要用到應用伺服器的功能都是通過擴充套件提供的。一個擴充套件被打包成為在modules目錄下的一個模組。使用者如果需要一個特別的擴充套件，則需要在domain.xml或者standalone.xml里加入<extension/> xml元素來指明這個模組名。
<extensions>
[...]
<extension
module="org.jboss.as.transactions"/>
<extension module="org.jboss.as.web" />
<extension module="org.jboss.as.webservices"
/>
<extension module="org.jboss.as.weld" />
</extensions>
4.3.2.2. Profile和subsystem(子系統 )
在domain.xml和standalone.xml配置中最重要的部分是一個(在standalone.xml)或者多個(在domain.xml裡)profile的配置。一個profile是一個命名的子系統集合。一個子系統是使用一個擴充套件新增到和伺服器核心的一組功能(參考以上的擴充套件)。一個子系統可以提供處理servlet的功能;一個子系統可以提供EJB容器，一個子系統可以提供JTA，等等。一個profile是命名的子系統的列表,並且包含各個子系統詳細的配置資訊。 一個伺服器擁有大量子系統的profile會提供豐富的功能.一個擁有數量少並且功能專注的子系統提供的功能相應減少，但是具有更少的記憶體消耗。
domain.xml和standalone.xml裡關於profile的配置看上去大致相同，唯一的不同是standalone.xml只允許有一個profile的xml元素(伺服器執行的proifle）,但domain.xml可以有多個profile,每一個profile可以對映到一個或者多個伺服器組。
domain.xml和standalone.xml裡關於子系統的配置是相同的。
4.3.2.3. Paths( 路徑)
路徑是一個檔案系統路徑的邏輯名。在doamin.xml,host.xml和standalone.xml配置種都包含用來來宣告路徑的部分。其他的配置可以通過邏輯名來引用這些路徑，而不需要包含路徑的所有全部資訊(在不同的機器都不相同).比如:
logging子系統的配置包含對jboss.server.log.dir路徑的引用來指向server的log目錄:
<file relative-to="jboss.server.log.dir"
path="server.log"/>
JBoss7自動提供一系列的標準路徑，而不需要使用者在配置檔案中配置.
jboss.home - JBossAS安裝的跟目錄
user.home - 使用者的home目錄
user.dir - 使用者當前的工作路徑
java.home - java安裝路徑
jboss.server.base.dir - 一個伺服器例項的跟目錄
jboss.server.data.dir - 伺服器儲存資料的目錄
jboss.server.log.dir - 伺服器日誌檔案目錄
jboss.server.tmp.dir - 伺服器儲存臨時檔案目錄
jboss.domain.servers.dir -host Controller在此目錄為伺服器例項建立的工作區(僅在管理域模式下)
使用者可以通過在配置檔案中使用<path>xml元素來增加自己的路徑或者覆蓋除了上面前五個路徑的配置。
<path name="example" path="example"
relative-to="jboss.server.data.dir"/>
Path的屬性：
name -- 路徑名
path -- 實際的物理檔案系統名,如果沒有relative-to的定義，將會被處理成為絕對路徑.
relative-to -- (可選)前面定義的路徑名，或者系統提供的標準路徑。
domain裡<path>配置不可以包含path和relative-to屬性,只需要name屬性。
<path name="x"/>
上面這個配置的示例簡單的說明:有意個叫"x"的路徑，在domain.xml配置的其他部分可以引用。指向x的實際檔案系統的路徑是主機相關的，需要在每個機器的host.xml裡定義。如果這種在domain.xml裡定義path的方式被使用，那麼在每個機器上host.xml裡都需要path來有定義實際的檔案系統路徑:
<path name="x" path="/var/x" />
在standalone.xml裡<path/>都必須包含實際檔案系統的路徑資訊。
4.3.2.4. nterfaces (介面)
介面就是對socket可以繫結到的一個物理介面,IP地址或者主機名的邏輯命名。domain.xml,host.xml和standalone.xml的配置資訊種都包行有介面宣告的部分。其他部分的配置可以根據這些邏輯名來引用這些介面,而不需要包含這些介面全部詳細的資訊(這些介面資訊在不同的機器上不盡相同)。一個介面的配置包含介面的邏輯名，也包含解析這個介面名成為真實實體地址的資訊。詳細資訊請參考介面和埠部分。
在domain.xml裡<interface/>元素只需要name屬性,不需要包含任何真實IP地址的資訊:
<interface name="internal"/>
這樣一個配置簡單的表明:"有一個叫internal的介面在domain.xml的其他部分可以引用。指向internal的IP地址是和主機相關的，地址資訊將會在每臺機器的host.xml裡指定。"如果使用這一方法，那麼在每臺機器上的host.xml裡必須有interface元素來指定IP地址:
<interface name="internal">
<nic name="eth1"/>
</interface>
在standalone.xml裡的<interface/>元素必須包含IP地址資訊。
4.3.2.5. socket binding(socket繫結)和socket binding group(socket繫結組)
socket繫結是對一個socket命名的配置。
在doamin.xml,和standalone.xml配置種都包含用來來宣告socket命名的部分。其他的配置可以通過邏輯名來引用這些socket，而不需要包含socket的所有全部資訊(在不同的機器都不相同).請參考interfaces和ports部分。
4.3.2.6. System Properties( 系統屬性)
系統屬性值可以在domain.xml, host.xml和standalone.xml裡的多個地方設定.standalone.xml裡設定的值會成為server啟動程式的一部分。在domain.xml和host.xml設定的值將在serer啟動時生效。
當在domain.xml或者host.xml裡設定的一個系統屬性，它是否能夠最終被應用生效取決於它在什麼地方被配置。如果系統屬性作為在domain.xml里根節點下的一個子孫節點被設定，那麼它將在所有的server上生效。如果在domain.xml中<server-group/>裡的<system-property/>設定，那麼它將在這個組裡所有的server生效。在host.xml里根節點下作為一個子節點設定系統屬性，那麼它將在這個主機的host
controller控制的所有server上生效。最後,在host.xml中<server/>裡的<system-property>設定，那麼它將在只在那個sever上生效。同樣的屬性可以被配置在多個地方:<server/> 中的值要優先於在host.xml根節點中直接定義的值，host.xml裡定義的值要優先於任何domain.xml裡的值，<server-group/>裡定義的值要優先於通過domain.xml里根節點裡定義的值。
4.3.3. Management resources( 管理資源)
當JBOss7在啟動的時候解析配置檔案，或者當使用AS7的管理介面的時候，都是在增加，刪除或者修改AS7內部管理模型的管理資源。AS7的管理資源具有以下特徵:
4.3.3.1. Address (地址)
所有JBossAS的管理資源都以樹的結構進行組織。指向一個管理資源樹節點的路徑就是管理資源的地址。每個資源地址的片段都是鍵值對:
鍵是在雙親上下文中資源的型別.因此，單伺服器模式執行的伺服器根資源就有以下型別的子孫:子系統，介面，socket繫結等等。提供AS7web伺服器能力的子系統就有型別是connector和virtual-server的子孫。提供AS7 訊息伺服器的子系統就有jms-queue和jms-topic型別的子孫節點。
值給定型別特定資源的名字。比如:子系統裡的web或者messaging, 子系統connector裡的http或者https.
管理資源的全路徑是一個排好序的鍵值對的列表,這個地址可以指從資源數的根指向這個資源。地址中使用"/"來分割地址元素，使用"="來分割鍵和值:
/subsystem=web/connector=http
/subsystem=messaging/jms-queue=testQueue
/interface=public
如果使用HTTP API,那麼"/:來分割鍵和值而不是"=":
http://localhost:9990/management/subsystem/web/connector/http
http://localhost:9990/management/subsystem/messaging/jms-queue/testQueue
http://localhost:9990/management/interface/public
4.3.3.2. operations( 操作)
查詢更改一個管理資源的狀態要通過一個操作。一個操作具有一下特徵:
- 字串名:
- 零個或者多個命名的引數.每個引數都有一個字串名和一個型別是org.jboss.drm.ModelNode值(或者當通過 CLI呼叫時，ModelNode用文字內容表示，通過HTTP APi呼叫時候，model node用JSON物件表示)。引數是可選的:
- 返回值也是一個型別是org.jboss.dmr.ModelNode的值(或者當通過 CLI呼叫時，ModelNode用文字內容表示，通過HTTP APi呼叫時候，model node用JSON物件表示)。
- 除了根節點的資源，每個資源應該有一個remove操作("這裡應該是因為在AS7.0時很多資源都沒有)。 add操作的引數會根據資源而不同。remove操作沒有引數:
全域性的操作都適用於所有的資源.詳細內容請參考全域性操作部分。
一個資源所支援的操作可以通過呼叫這個資源本身的一個操作獲得:read-operation-names.一旦知道了操作的名，關於操作的引數和返回的詳細資訊就可以通過呼叫read-operation-description來獲得。比如，在單獨執行伺服器上獲取根節點資源所支援的操作名,然後得到一個操作全部的詳細資訊，在CLI中可以通過以下來獲得:
[standalone@localhost:9999 /]
:read-operation-names
{
"outcome" => "success",
"result" => [
"add-namespace",
"add-schema-location",
"delete-snapshot",
"full-replace-deployment",
"list-snapshots",
"read-attribute",
"read-children-names",
"read-children-resources",
"read-children-types",
"read-config-as-xml",
"read-operation-description",
"read-operation-names",
"read-resource",
"read-resource-description",
"reload",
"remove-namespace",
"remove-schema-location",
"replace-deployment",
"shutdown",
"take-snapshot",
"upload-deployment-bytes",
"upload-deployment-stream",
"upload-deployment-url",
"validate-address",
"write-attribute"
]
}
[standalone@localhost:9999 /] :read-operation-description(name=upload-deployment-url)
{
"outcome" => "success",
"result" => {
"operation-name" =>
"upload-deployment-url",
"description" =>
"Indicates that the deployment content available at the included URL
should be added to the deployment content repository. Note that this operation
does not indicate the content should be deployed into the runtime.",
"request-properties" =>
{"url" => {
"type" => STRING,
"description" => "The URL at which the deployment content is
available for upload to the domain's or standalone server's deployment content
repository.. Note that the URL must be accessible from the target of the
operation (i.e. the Domain Controller or standalone server).",
"required" => true,
"min-length"
=> 1,
"nillable" => false
}},
"reply-properties" => {
"type" => BYTES,
"description" => "The hash of managed deployment content that
has been uploaded to the domain's or standalone server's deployment content
repository.",
"min-length" => 20,
"max-length"
=> 20,
"nillable" => false
}
}
}
如何獲取一個資源所支援的操作請參考以下Description部分。
4.3.3.3. Attributes( 屬性)
管理資源將它們的狀態暴露成為屬性。屬性有string型別名，和一個型別是org.jboss.drm.ModelNode值(或者當通過 CLI呼叫時，ModelNode用文字內容表示，通過HTTP APi呼叫時候，model node用JSON物件表示)。
屬性可以是隻讀或者是可讀寫的。讀寫屬性值可以通過全域性的read-attribute和write-attribute操作來進行。
read-attribute操作僅有一個"name"引數，它的值是這個atrribute的名。比如在sorkcet-binding資源裡通過CLI來讀port屬性:
[standalone@localhost:9999 /]
/socket-binding-group=standard-sockets/socket-binding=https:read-attribute(name=port)
{
"outcome" => "success",
"result" => 8443
}
如果一個屬性是可寫的，資源的狀態可以通過write-attribute操作來改變。這個操作接受兩個引數:
name – 屬性名
value – 屬性值
比如在sorkcet-binding資源裡通過CLI來設定port屬性:
[standalone@localhost:9999 /] /socket-binding-group=standard-sockets/socket-binding=https:write-attribute(name=port,value=8444)
{"outcome" => "success"}
屬性可以有兩種儲存型別:
CONFIGURATION – 表示屬性值儲存在持久化的配置中，比如管理資源配置要從這些檔案讀取的:domain.xml,host.xml或者standalone.xml.
RUNTIME – 表示屬性之日僅僅儲存在執行的伺服器中而不是持久化的配置中。 比如一個metric(如已經處理的請求數)十一個RUNTIME屬性一個典型的例子。
管理資源暴露出的所有屬性值可以通過"read-resource"操作再加上“include-runtime=true"的引數來獲得，比如通過CLI:
[standalone@localhost:9999 /]
/subsystem=web/connector=http:read-resource(include-runtime=true)
{
"outcome" => "success",
"result" => {
"bytesReceived" =>
"0",
"bytesSent" =>
"0",
"errorCount" =>
"0",
"maxTime" =>
"0",
"processingTime" =>
"0",
"protocol" =>
"HTTP/1.1",
"requestCount" =>
"0",
"scheme" =>
"http",
"socket-binding" =>
"http",
"ssl" => undefined,
"virtual-server" =>
undefined
}
}
省略include-runtime（或者設定成false)來限制僅僅儲存在持久化配置上的值才被輸出。
[standalone@localhost:9999 /]
/subsystem=web/connector=http:read-resource
{
"outcome" => "success",
"result" => {
"protocol" =>
"HTTP/1.1",
"scheme" =>
"http",
"socket-binding" =>
"http",
"ssl" => undefined,
"virtual-server" =>
undefined
}
}
參考一下Description相關部分來獲取更多關於一個特定資源暴露出屬性的資訊。
4.3.3.4. Children（子節點)
管理資源可以支援子資源。一個資源孩子節點的型別(比如web子系統資源的connector子節點)可以通過查詢資源的description來獲得(參考以下Description部分)或者通過呼叫"read-children-types"操作。當你知道了子節點的型別，你就可以通過全域性"read-children-types"操作和已知節點型別來獲得全部子節點名。這個操作僅接受一個引數型別:child-type,它的值即使已知的子節點型別。比如，一個表示socketbinding
組的資源有孩子節點。使用CLI來獲得這些子節點的型別和給定型別所有的資源:
[standalone@localhost:9999 /]
/socket-binding-group=standard-sockets:read-children-types
{
"outcome" => "success",
"result" => ["socket-binding"]
}
[standalone@localhost:9999 /]
/socket-binding-group=standard-sockets:read-children-names(child-type=socket-binding)
{
"outcome" => "success",
"result" => [
"http",
"https",
"jmx-connector-registry",
"jmx-connector-server",
"jndi",
"osgi-http",
"remoting",
"txn-recovery-environment",
"txn-status-manager"
]
}
4.3.3.5. Descriptions(描述)
所有的管理資源都暴露用於描述管理資源屬性，操作和子節點型別的後設資料(metadata).通過呼叫一個或者多個被管理資源所支援的全域性操作來獲取.以上我們給出了 read-operation-names,
read-operation-description, read-children-types 和
read-children-names操作的例子。
read-resource-description 操作用來獲得一個資源屬性，子節點的詳細資訊。比如,通過CLI:
[standalone@localhost:9999 /]
/socket-binding-group=standard-sockets:read-resource-description
{
"outcome" => "success",
"result" => {
"description" =>
"Contains a list of socket configurations.",
"head-comment-allowed"
=> true,
"tail-comment-allowed"
=> false,
"attributes" => {
"name" => {
"type" => STRING,
"description" => "The name of the socket binding
group.",
"required" => true,
"head-comment-allowed" => false,
"tail-comment-allowed" => false,
"access-type" => "read-only",
"storage" => "configuration"
},
"default-interface" => {
"type" => STRING,
"description" => "Name of an interface that should be used as
the interface for any sockets that do not explicitly declare one.",
"required" => true,
"head-comment-allowed" => false,
"tail-comment-allowed" => false,
"access-type" => "read-write",
"storage" => "configuration"
},
"port-offset" => {
"type" => INT,
"description" => "Increment to apply to the base port values
defined in the socket bindings to derive the runtime values to use on this
server.",
"required" => false,
"head-comment-allowed" => true,
"tail-comment-allowed" => false,
"access-type" => "read-write",
"storage" => "configuration"
}
},
"operations" => {},
"children" =>
{"socket-binding" => {
"description" => "The individual socket configurtions.",
"min-occurs" => 0,
"model-description" => undefined
}}
}
}
注意在上述例子中的輸入:"operations" => {}"。如果命令列已經包含引數operation=true,(比如
/socket-binding-group=standard-sockets:read-resource-description(operations=true))，那麼操作的結果會包含這個資源所支援的每個操作的描述。
關於被管理資源上執行read-resource-description和其他全域性操作所支援的其他引數的詳細資訊，請參考全域性操作部分。
4.3.3.6. 和JMX Beans相比
JBossAS管理的資源在概念上和Open MBeans極為相似。他們有一下主要的幾點不同:
- JBossAS的管理資源通過樹形結構進行組織。資源地址的鍵值順序是不同的，因為它定義了被管理資源在數形結構上的位置,而JMX ObjectName的key屬性順序不是很重要。
- Open MBean屬性的值，操作引數的值和操作的返回值，必須是JDK規定的簡單型別(String,Boolen,Integer等等) 或者實現了javax.management.openmbean.CompositeData 或者 javax.management.openmbean.TabularData的物件。JBossAS管理資源的 屬性值，操作引數值和操作的返回值都是org.jboss.dmr.ModelNode型別。
4.3.3.7. 管理資源樹的基本結構(management resource trees)
如同以上提到的，被管理資源以樹形結構組織。數的結構決定於你執行在單伺服器模式還是管理域模式。
4.3.3.7.1. 單伺服器模式(Standalone server)
單伺服器模式下管理樹的樹形結構和standalone.xml配置檔案的十分相似：
根節點資源:
extension – 在伺服器上安裝的擴充套件。
path – 伺服器上可用的路徑。
system-property – 配置檔案中設定的系統屬性 (如不在命令列種設定的屬性)
core-service=management – 伺服器中核心的管理服務。
core-service=service-container – JBoss7的最核心資源JBoss MSC ServiceContainer
ubsystem – server上安裝的子系統.大部分的管理模型都是子系統型別的子節點。
interface – 介面配置
socket-binding-group – server上socket繫結組的中心資源
socket-binding – 單個socket繫結的配置
deployment – server上已經部署的內容
4.3.3.7.2. 管理域模式 (managed domain)
在管理域模式下，管理資源樹會跨越整個域，包含域範圍的配置(如在domain.xml上定義的配置),和主機相關的配置(如在host.xml配置的內容)以及每個執行應用伺服器暴露出的管理資源。在管理域中Host Controller程式提供對整個資源樹的訪問.如果Host Controller是主Domain Controller，那麼資源樹中對於每個主機相關資訊都是可得到的,如果Host Controller是遠端Domain Controller的從屬(slave)，那麼僅與Host Controller所在的host相關部分的資源樹的是可以訪問的。
整個域的根資源如下。這些資源包括它的子孫，除了host型別都會被持久化到domain.xml中。
extension – 域模式上執行的擴充套件。
path – 在域中可用的路徑。
system-property – 配置檔案中設定的系統屬性 (如不在命令列種設定的屬性),可以在整個域裡使用
profile – 一組子系統的設定，可以分配給server group
subsystem – 子系統的設定,可以組成profile.
interface – 介面配置
socket-binding-group –socket繫結組設定，可以被sever
group使用。
socket-binding – 單個socket繫結的配置
deployment – 可用的部署內容，可以分配給sever
group. deployments available for assignment to server groups
server-group – server group配置
host – 單獨的Host Controller.每個host型別的節點都代表是特定主機的根資源。host和host的子孫節點的配置會被持久化儲存到主機的host.xml檔案中。
path – 主機伺服器上可用的路徑
system-property – 主機伺服器配置檔案中設定的系統屬性
core-service=management – Host Controller的核心管理服務。
interface – 可以被Host Controller和主機上伺服器使用的介面配置。
jvm – 用來啟動伺服器的JVM設定
server-config – 配置HostController如何啟動sever;配置使用什麼server group，和覆蓋在其他資源上定義的和伺服器相關的配置項。
server – server的根資源.sever和一下資源不會直接被持久化；
在域範圍和主機級別的持久化的yuan ,組成了server的配置。
extension – 在伺服器上安裝的擴充套件。
path – 伺服器上可用的路徑。
system-property – 配置檔案中設定的系統屬性 (如不在命令列種設定的屬性)
core-service=management – 伺服器中核心的管理服務。
core-service=service-container – JBoss7的最核心資源JBoss MSC ServiceContainer
subsystem – server上安裝的子系統.大部分的管理模型都是子系統型別的子節點。
interface – 介面配置
socket-binding-group – server上socket繫結組的中心資源
socket-binding – 單個socket繫結的配置
deployment – server上已經部署的內容
4.4. 管理任務
4.4.1. 網路介面和埠
4.4.1.1. 網路介面宣告
JBoss AS 7 在整個配置檔案中都引用命名的介面。一個網路介面通過指定一個邏輯名和選擇一個物理介面來宣告。
[standalone@localhost:9999 /]
:read-children-names(child-type=interface)
{
"outcome" => "success",
"result" => [
"management",
"public"
]
}
以上操作意味著server宣告瞭兩個介面:一個可以使用”management”進行引用，另外一個可以用”public”引用。管理層（比如HTTP管理點)需要用到的所有元件和服務都可以使用”management”介面。與網路通訊有關的應用(如Web, Message等等)都可以使用”public”介面.介面的名字沒有任何特別的要求；可以用任何名字宣告介面。配置的其他部分可以用邏輯名來引用這些介面，而不用包含介面的所有詳細資訊（在管理域裡伺服器上的這些資訊隨著機器不同而不同).
domain.xml, host.xml 和standalone.xml 都包含宣告介面的部分。但我們看這些在xml檔案中介面宣告時，就會發現介面的選擇條件(selection criteria)。介面選擇的條件有兩種型別:一種是單獨的xml元素，介面繫結到萬用字元地址；另外一種是介面或者地址有一個或者多個特徵值需要滿足。下面是一個介面條件選擇的例子，每個介面都有特定的IP地址:
<interfaces>
<interface name="management">
<inet-address value="127.0.0.1"/>
</interface>
<interface name="public">
<inet-address value="127.0.0.1"/>
</interface>
</interfaces>
另外一些使用萬用字元的例子:
<interface name="global">
<!-- 使用任何地址 -->
<any-address/>
</interface>
<interface name="ipv4-global">
<!--使用任何IPV4的例子-->
<any-ipv4-address/>
</interface>
<interface name="ipv6-global">
<!-- 使用任何IPV6的例子 -->
<any-ipv6-address/>
</interface>
<interface name="external">
<nic name="eth0"/>
</interface>
<interface name="default">
<!-- 匹配下面子網地址，而且支援multicats不是點對點的地址-->
<subnet-match value="192.168.0.0/16"/>
<up/>
<multicast/>
<not>
<point-to-point/>
</not>
</interface>
4.4.1.2. Socket Binding Groups
AS7中socket的配置類似於interface的宣告,Sockets用一個邏輯名來宣告，可以在整個配置中引用。 多個Sockets宣告可以用一個特定的名字宣告成為一個組。這樣在配置一個在管理域裡的server group時可以方便的引用一個特定的socket binding
group. Socket binding group通過interface邏輯名來引用interface:
<socket-binding-group name="standard-sockets"
default-interface="public">
<socket-binding name="jndi"
port="1099"/>
<socket-binding name="jmx-connector-registry"
port="1090"/>
<socket-binding name="jmx-connector-server"
port="1091"/>
<socket-binding name="http"
port="8080"/>
<socket-binding name="https"
port="8443"/>
<socket-binding name="jacorb"
port="3528"/>
<socket-binding name="jacorb-ssl"
port="3529"/>
<socket-binding name="osgi-http"
port="8090"/>
<socket-binding name="remoting"
port="4447"/>
<socket-binding name="txn-recovery-environment"
port="4712"/>
<socket-binding name="txn-status-manager"
port="4713"/>
<socket-binding name="messaging"
port="5445"/>
<socket-binding name="messaging-throughput"
port="5455"/>
</socket-binding-group>
一個socket binding 包含一下資訊:
- name – socket配置的邏輯名，可以在配置的其他任何地方引用。
- port – 這個配置中socket要繫結到的基礎埠 (注意server可以通過配置增減所有埠值來覆蓋這一配置)
- interface （可選) – 配置中socket要繫結介面的邏輯名 (參考 上面的介面宣告 ) .如果沒有指定， socket binding group 配置元素中的default-interface屬性值將會被使用。
- multicast-address (可選) --如果socket用於多播，將會使用這個多播地址。
- multicast-port (可選) – 如果socket用於多播，將會使用這個多播埠
- fixed-port (可選, 預設是false) – 如果是true, 埠值將一直使用這個值，這個值不會被使用增減埠值而覆蓋。
4.4.2. 管理介面的安全性
除了在執行伺服器或者伺服器組上的各種服務，JBoss7還提供了兩個管理介面允許遠端的客戶端可以管理JBoss AS7.這個章節中介紹如何使用這些介面，以及如何對這些介面進行加密。
這兩個管理介面被暴露成一個HTTP介面和一個Native介面。HTTP介面既用來提供基於GWT的管理控制檯(admin console)使用，也提供給使用JSON編碼協議和de-typed RPC API各種管理操作使用。當執行在單獨執行伺服器(standalone)時候，Native介面允許管理操作通過私有的二進位制協議訪問。這種使用二進位制協議型別的操作可以通過AS7提供的命令列工具，也可以通過使用AS7jar檔案的遠端客戶端進行互動。
在管理域下使用這些介面稍有些負責。在每一個主機上都有一個host controller的程式。在主機上的host controller會配置成為domain controller.在管理域中可以用同樣的方式來使用HTTP介面; HTTP介面允許基於GWT的管理控制檯(admin console)執行在主domain controller，也允許任何基於HTTP和JSON的管理控制客戶端在任何host controller上執行管理操作。然而其他的一些客戶端則使用Natvie介面：一旦host controller啟動真正的應用伺服器例項，這些應用伺服器則通過native介面與host controoler後臺建立連線；從host controller則使用native 介面與主domain controller在後臺建立連線來獲取domain 模型的拷貝，並隨後接收主domain cotroller的操作請求。
4.4.2.1. 初始化設定
單獨執行伺服器的介面配置在standalone.xml裡定義，在管理域裡執行伺服器的介面配置在host.xml 中。在兩個檔案中，介面配置都有相同的結構:
<management>
...
<management-interfaces>
<native-interface
interface="management" port="9999"
/>
<http-interface interface="management"
port="9990"/>
</management-interfaces>
</management>
...
<interfaces>
<interface name="management">
<inet-address
value="127.0.0.1"/>
</interface>
<interface name="public">
<inet-address
value="127.0.0.1"/>
</interface>
</interfaces>
navtive介面預設監聽9999埠，http介面監聽9990.管理介面同時與一個命名為 “management”的網路介面(network inteface)相關聯。雖然management網路介面(network interface)的配置和public 網路介面的預設配置相同，但我們推薦不要合併這兩個配置。managment和public的網路介面分開配置可以保證任何將應用伺服器中服務更為公開的配置更改，不會無意識的公開本不需要公開的管理介面。
4.4.2.2. 快速配置
在本章節剩下的部分我們講更為詳細的講述安全域的配置-但是如果你想快速的啟用安全域並且完善安全配置來滿足需求，預設的配置包含一個預先定義的安全域，它基於一個property檔案和一個可以通過命令列來啟用的指令碼。
安全域定義在standalone.xml或者host.xml檔案中<management>元素. 預設的安全域:
<management>
<security-realms>
<security-realm
name="PropertiesMgmtSecurityRealm">
<authentication>
<properties path="mgmt-users.properties"
relative-to="jboss.server.config.dir" />
</authentication>
</security-realm>
</security-realms>
...
</management>
預設安全域通過呼叫在configuratiion目錄下的mgmt-user.properties來校驗連線的使用者。property檔案預設沒有任何使用者，因此新的使用者要用username=password格式新增到檔案中:
手動啟用兩個介面配置好的管理域:
<management>
...
<management-interfaces>
<native-interface
interface="management" port="9999"
security-realm="PropertiesMgmtSecurityRealm" />
<http-interface
interface="management" port="9990"
security-realm="PropertiesMgmtSecurityRealm"/>
</management-interfaces>
</management>
這將為Http interface啟用Http Digest
authentication,並且在Native interface啟用Digest SASL-這也意味著對於原始密碼不會在客戶端和伺服器端進行傳輸驗證。
使用指令碼來啟用安全域，首先要編輯“mgmt-users.properties”,因為配置會馬上生效。你需要至少定義一個使用者，並且執行以下命令:
對於單獨執行的伺服器:
./jboss-admin.sh --connect --file=scripts/secure-standalone-mgmt.cli
對於在管理域的伺服器:
./jboss-admin.sh --connect --file=scripts/secure-host-controller-mgmt.cli
注意這個指令碼只能執行在預設配置為master的host上。如果建立了其他具有不同名稱的host，那麼需要更新這個指令碼或者手動對這個新的配置實施安全性。並且還要注意，這個指令碼僅僅改變它要執行的名為master的host,如果有多個host
controller,這個指令碼需要使用他們所有正確的host名字執行去更改。同時，請閱讀這個章節的其他部分關於如何配置從host controller連線主host controller的校驗。
禁用JMX遠端訪問
除了以上的JBoss管理協議，還有允許JDK和應用管理操作的遠端JMX 連線。為了安全性，可以通過刪除遠端連線配置來禁止這一服務，或者刪除整個subsystem.
<subsystem xmlns="urn:jboss:domain:jmx:1.0">
<!-- Delete the following line to disable remote
access -->
<jmx-connector
registry-binding="jmx-connector-registry"
server-binding="jmx-connector-server" />
</subsystem>
4.4.2.3. 詳細配置
管理介面的配置在<management>下的三個節點中:
<management>
<security-realms />
<outbound-connections />
<management-interfaces />
</management>
<security-realms /> - 配置一個或者多個安全域來定義遠端使用者如何連線到伺服器進行驗證，並且定義伺服器上的身份(identity)。
<outbound-connections /> -有時候安全域的配置需要連線到一個外部的資源；這些連線在這裡配置。
<management-interfaces /> - 這裡定義Http interface和Native interface，正如我們在簡介裡描述的那樣。
4.4.2.3.1. 管理介面
對於單個管理介面的配置是最簡單的。僅僅需要配置管理介面的”security-realm”屬性，來指定使用安全域的名字。因為管理介面啟動安全域時，要查詢安全域所提供的功能，並且啟動安全相依的傳輸:比如使用者的密碼如果可以從安全域中獲得，Http interface會嘗試使用Digest驗證，如果使用者密碼不能從安全域中獲取，http interface會轉而支援Basic驗證。
<management> ...
<management-interfaces>
<native-interface ...
security-realm="PropertiesMgmtSecurityRealm" />
<http-interface ...
security-realm="PropertiesMgmtSecurityRealm"/>
</management-interfaces>
</management>
管理介面可以使用同樣的安全域，但這不是必須的。如果需要，不同的管理介面可以使用不同的安全域。
4.4.2.3.2. 安全域
<security-realms /> 元素用來配置一個或者多個安全域。安全域的配置具有以下結構:
<management>
<security-realms>
<security-realm
name="SampleRealm">
<server-identities />
<authentication />
</security-realm>
</security-realms>
...
</management>
<server-identities />元素定義server的身份資訊。目前可以配置一個SSL身份(identity)來定義伺服器如何從一個keystore 取得身份資訊。也可以配置一個加密的身份-伺服器使用什麼樣的命令或密碼和其他的伺服器進行通訊。
<authentication /> 定義如何驗證連線到伺服器的使用者
4.4.2.3.2.1 Authentication(驗證)
最初，AS7支援三種機制來驗證連線到伺服器的使用者:
LDAP – 使用LDAP 伺服器來驗證使用者的額身份資訊。
Users – 定義在domain model裡的使用者名稱和密碼資訊，這僅作為簡單測試使用。
Properties – 使用者名稱和密碼定義在一個伺服器安裝檔案目錄的 property檔案中。
下表概括了管理介面支援的驗證機制，用來對終端使用者在傳輸級別上進行驗證:
|
Authentication |
HTTP |
Native |
|
LDAP |
HTTP BASIC |
Not Supported1 |
|
Users |
HTTP DIGEST |
SASL DIGEST |
|
Properties |
HTTP DIGEST |
SASL DIGEST |
1 – 將被增加到AS7-1167
HTTP Basic和SASL Plain(實現以後)在一個表單裡傳輸使用者密碼，很容易被破解。
下面的章節闡述如何配置這些驗證機制:
4.4.2.3.2.1.1 LDAP
LDAP驗證操作首先要建立一個和遠端目錄伺服器的連線。然後使用使用者提通的使用者名稱去執行查詢區別使用者的識別名(distinguished name)。最後驗證器和目錄伺服器建立一個新的連線，使用查詢到的識別名和使用者提供的密碼來驗證是否是合法使用者。
這是一個使用LDAP驗證的安全域配置:
<security-realm name="TestRealm">
<authentication>
<ldap connection="ldap_connection"
base-dn="CN=Users,DC=mydomain,DC=aslab" username-attribute="sAMAccountName"
/>
</authentication>
</security-realm>
ldap元素可以配置以下屬性:
connection - 定義在 <outbound-connections>的連線來連線到LDAP目錄伺服器。
base-dn - 開始搜尋使用者的上下文中的識別名(基準識別名).
Username-attribute – 目錄中的使用者名稱的屬性，用來匹配提供的使用者名稱
recursive (default - false) - 是否需要迭代查詢
user-dn (default - dn) - 使用者中存放識別名的屬性， 用來校驗使用者資訊
4.4.2.3.2.1.2 User
User校驗器是一個對儲存在domain model裡使用者名稱和密碼進行驗證的簡單校驗器。校驗器僅用作簡單的測試使用:
這是一個使用User驗證器的例子:
<security-realm name="TestRealm">
<authentication>
<users>
<user
username="TestUser">
<password>TestUserPassword</password>
</user>
</users>
</authentication>
</security-realm>
在這個配置中，每個使用者都用<user>進行定義，使用者名稱使用”username” 屬性定義，password定義在user下的<password>中。
4.4.2.3.2.1.3 Properties
Properties校驗器和User校驗器類似，除了使用者名稱和密碼定義在一個properties檔案中。比起 User校驗的優點是password不必在domain model中暴露。
這是一個使用properties驗證器配置安全域的一個例子:
<security-realm name="TestRealm">
<authentication>
<properties path="users.properties"
relative-to="jboss.server.config.dir" />
</authentication>
</security-realm>
Properties檔案通過簡單定義”path”屬性來指定檔案的路徑和 ”relative-to”屬性來引用定義好的路徑和path屬性相對的路徑。在這個例子中，user.properties在存放stadnalone.xml檔案相同的目錄下。
如果”relateive-to”屬性沒有指定，那麼path屬性的之必須是一個絕對路徑。
4.4.2.3.2..2 Server Identities（伺服器身份)
<server-identities>用於配置在多種場景中伺服器辨別自己身份的資訊。 目前在HTTP interface中可以定義一個SSL indentiy並且使用這一indentity來啟用SSL，另外一個Secret identity可以存放一個密碼，當host controller和遠端的domain controller 建立連線時，使用這一個定義好的Secret indentity.
- SLL
SSL identity的配置目前需要從本地檔案系統中載入一個靜態的keystore.以後會增強這一個功能來允許多種型別的keystore:
一個SSL indentity的配置示例如下:
<security-realm name="TestRealm">
<server-identities>
<ssl>
<keystore
path="server.keystore"
relative-to="jboss.server.config.dir"
password="keystore_password" />
</ssl>
</server-identities>
</security-realm>
keystore的路徑資訊和properites驗證器中properties檔案資訊相同，使用一個路徑指定keystore和一個可選的relative-to 屬性來指定path屬性相對於一個已知的路徑。
- Secret
從domain
controller連線到一個加密的主domain controller時，需要配置Secret identity.
為了實現連線加密的主domain controoler,下面是在從domain controller中增加的配置：
<host xmlns="urn:jboss:domain:1.0"
name="slave">
<management>
<security-realms>
<security-realm
name="TestRealm">
<server-identities>
<secret value="c2xhdmVfcGFzc3dvcmQ=" />
</server-identities>
</security-realm>
</security-realms>
...
</management>
<domain-controller>
<remote host="127.0.0.1"
port="9999" security-realm="TestRealm" />
</domain-controller>
...
</host>
這裡<remote>定義了domain
controller引用了一個定義好的安全域。，這個引用意味著這個安全域會被用來載入客戶端的配置（以後這將會擴充套件使得域也同樣可以為客戶端的連線定義SSL)
secret是密碼採用Base64編碼，連線會使用host名（在這個示例中是'slave')和從secret中得到的密碼進行驗證。
AS7-1102列出了密碼的處理將會被增強，來更好的保護密碼的配置。如採用密碼混淆，加密方式以及使用外部的security
provider, smart card或者使用 PKCS#11的硬體加密模組。
4.4.2.3.3. Outbound connections(外部連線)
如前面所述，外部連線用來連線一個遠端的伺服器，目前僅支援LDAP連線，以後會增加資料庫連線來支援對儲存在資料庫中的資訊進行驗證。
- LDAP
下面是一個連線LDAP伺服器的例子:
<outbound-connections>
<ldap name="ldap_connection"
url="ldap://127.0.0.1" search-dn="CN=AS7 Test
Server,CN=Users,DC=mydomain,DC=aslab"
search-credential="AS_Password" />
</outboundconnections>
<ladp>可以配置以下屬性:
name - 連線名，ladp驗證其會使用這個名字來引用這個連線。
url – 連線目錄伺服器的URL.
search-dn - 使用者初始化搜尋的識別名
search-credential – 連線進行搜尋的密碼
initial-context-factory (default - com.sun.jndi.ldap.LdapCtxFactory) -用來建立連線的 initial context factory
4.4.2.4. 問題
Application
server如何連線到host controller的native
interface上-是如何進行驗證的?
當JBossAS7程式啟動時會建立一個隨機的key並且將這個key傳輸到啟動的伺服器例項，applicaiotn server使用這個key來驗證native interface的連線。
4.4.3. JVM設定
管理域和單獨執行伺服器的 JVM設定是不相同的。在管理域中， domain controller元件會負責停止和啟動伺服器程式，因此由它來決定 JVM的設定。在單獨執行伺服器中，由啟動伺服器的程式 (比如通過命令列引數 )負責 JVM的設定。
4.4.3.1. 管理域
在管理域裡， JVM設定可以在不同的作用域上宣告 :比如在特定的伺服器組，一個主機或者一個特別的伺服器。如果沒有顯式宣告， JVM設定從父作用域繼承。這樣可以在不同的層次上允許定製或者繼承 JVM設定。
我們來看一下對一個伺服器組 JVM的宣告 :
<server-groups>
<server-group name="main-server-group" profile="default">
<jvm name="default">
<heap size="64m" max-size="512m"/>
</jvm>
<socket-binding-group ref="standard-sockets"/>
</server-group>
<server-group name="other-server-group" profile="default">
<jvm name="default">
<heap size="64m" max-size="512m"/>
</jvm>
<socket-binding-group ref="standard-sockets"/>
</server-group>
</server-groups>
(參見 domain/configuration/domain.xml)
在這個例子裡，伺服器組 "main-server-group" 的 jvm設定成 64m的 heap size和 最大是 512m的 heap size.任何屬於這個組的伺服器都會整合這些 JVM設定。你可以改變整個組，或者一個特定伺服器，主機的 JVM設定 :
<servers>
<server name="server-one" group="main-server-group" auto-start="true">
<jvm name="default"/>
</server>
<server name="server-two" group="main-server-group" auto-start="true">
<jvm name="default">
<heap size="64m" max-size="256m"/>
</jvm>
<socket-binding-group ref="standard-sockets" port-offset="150"/>
</server>
<server name="server-three" group="other-server-group" auto-start="false">
<socket-binding-group ref="standard-sockets" port-offset="250"/>
</server>
</servers>
(參考 domain/configuration/host.xml)
在這個例子中， server-two 屬於 main-server-group， 因此會繼承名字為 default的 JVM設定，但是它在 server-two伺服器上宣告瞭一個較低的 maxium heap size。
[domain@localhost:9999 /] /host=local/server-config=server-two/jvm=default:read-resource
{
"outcome" => "success",
"result" => {
"heap-size" => "64m",
"max-heap-size" => "256m",
}
}
4.4.3.2. 單獨執行伺服器
對於單獨執行的伺服器，則需要在執行 $JBOSS_HOME/bin/standalone.sh 指令碼時使用命令列引數來設定 JVM，或者在 $JBOSS_HOME/bin/standalone.conf 宣告。 (對於 windows使用者，需要執行 %JBOSS_HOME%/bin/standalone.bat 和設定
%JBOSS_HOME%/bin/standalone.conf.bat.)
4.4.4. 命令列引數
啟動 JBoss AS7的管理域，需要執行 : $JBOSS_HOME/bin/domain.sh 指令碼，啟動單獨執行的伺服器需要執行 $JBOSS_HOME/bin/standalone.sh . 使用這兩個指令碼啟動時，將會使用預設的設定。以下內容，我們講介紹如何通過額外的命令列引數來覆蓋這些預設的設定。
4.4.4.1. 系統屬性
單伺服器和管理域模式都使用用來設定標準位置 (如 jboss.home.dir,jboss.server.config.dir)的預設設定， B這小節中介紹這些系統屬性的預設值。每個系統屬性，都可以通過標準的 JVM設定方式 -Dkey=value覆蓋：
$JBOSS_HOME/bin/standalone.sh -Djboss.home.dir=some/location/AS7/jboss-as \
-Djboss.server.config.dir=some/location/AS7/jboss-as/custom-standalone
以上的命令列啟動一個不是標準的 AS home目錄，並且使用一個特定的配置檔案路徑 . 具體系統屬性的含義將在以下內容中介紹。
同時，你也可以使用一個 properties檔案通過下面任何一種方式來覆蓋配置預設的系統屬性 :
$JBOSS_HOME/bin/domain.sh --properties=/some/location/jboss.properties
$JBOSS_HOME/bin/domain.sh -P=/some/location/jboss.properties
這個 properties檔案是一個標準的包含 key=value對的標準 Java property檔案 :
jboss.home.dir=/some/location/AS7/jboss-as
jboss.domain.config.dir=/some/location/AS7/custom-domain
4.4.4.2. 單獨執行模式（ Standalone)
|
屬性名 |
說明 |
預設值 |
|
java.ext.dirs |
指定 JDK extension路徑 |
null |
|
jboss.home.dir |
JBoss AS 7 安裝的根目錄 |
standalone.sh 設定為 $JBOSS_HOME |
|
jboss.server.base.dir |
server的 base目錄 |
jboss.home.dir /standalone |
|
jboss.server.config.dir |
base configuration目錄 |
jboss.server.base.dir /configuration |
|
jboss.server.data.dir |
用於存放持久化資料的目錄 |
jboss.server.base.dir /data |
|
jboss.server.log.dir |
存放 server.log 的目錄 |
jboss.server.base.dir /log |
|
jboss.server.temp.dir |
臨時檔案目錄 |
jboss.server.base.dir /tmp |
|
jboss.server.deploy.dir |
部署目錄 |
jboss.server.data.dir /content |
4.4.4.3. 管理域模式 (Managed Domain)
|
屬性名 |
說明 |
預設值 |
|
jboss.home.dir |
The root directory of the JBoss AS 7 installation. |
domain.sh 設定為 $JBOSS_HOME |
|
jboss.domain.base.dir |
domain的 base目錄 |
jboss.home.dir /domain |
|
jboss.domain.config.dir |
base configuration目錄 |
jboss.domain.base.dir /configuration |
|
jboss.domain.data.dir |
用於存放持久化資料的目錄 . |
jboss.domain.base.dir /data |
|
jboss.domain.log.dir |
存放 host-controller.log 和 process-controller.log 檔案的目錄 |
jboss.domain.base.dir /log |
|
jboss.domain.temp.dir |
臨時檔案目錄 |
jboss.domain.base.dir /tmp |
|
jboss.domain.deployment.dir |
部署目錄 |
jboss.domain.base.dir /content |
|
jboss.domain.servers.dir |
被管伺服器輸出存放的目錄 |
jboss.domain.base.dir /log |
4.4.4.4. 其他命令列引數
第一種接收引數的格式是 :
--name=value
比如 :
$JBOSS_HOME/bin/standalone.sh --server-config=standalone-ha.xml
如果引數名是一個單詞，那麼使用一個” -”字首，而不是兩個” --”:
-x=value
比如 :
$JBOSS_HOME/bin/standalone.sh -P=/some/location/jboss.properties
下面說明在單伺服器和管理域模式下可用的的命令列引數 :
4.4.4.4.1. 單伺服器模式（ Standalone）
|
引數名 |
預設的預設值 |
值 |
|
--server-config |
jboss.server.config.dir /standalone.xml |
一個相對於 jboss.server.config.dir 的路徑或者是一個絕對路徑 |
4.4.4.4.2. 管理域模式 (Managed Domain)
|
引數名 |
預設的預設值 |
值 |
|
--domain-config |
jboss.domain.config.dir/domain.xml |
一個相對於 jboss.domain.config.dir 的路徑或者是一個絕對路徑 |
|
--host-config |
jboss.domain.config.dir/host.xml |
一個相對於 jboss.domain.config.dir 的路徑或者是一個絕對路徑 |
下面的引數不需要指定值，並且只能被用於 host controller.(比如被配置連線到遠端 domain controller的主機 )
|
引數 |
功能 |
|
--backup |
使從 host controller建立和維護一個域配置的本地拷貝 |
|
--cached-dc |
如果從 (slave)host controller在啟動時不能連線主 domain controller取得配置資訊，那麼通過 -bakcup建立的本地拷貝將會被使用。同時 slave host controller不會改變任何 domain的配置，僅啟動伺服器。 |
4.4.4.4.3. 通用引數 (Common parameters)
這些沒有值的引數既適用於單伺服器模式也適用於管理域模式。下表介紹這些引數的使用 :
|
引數 |
功能 |
|
--version |
列印 JBossAS的版本資訊，並且退出 JVM。 |
|
--help |
列印各引數的幫助資訊，並且退出 JVM |
4.4.5. 子系統配置
以下章節中將集中介紹通過 CLI和 web介面進行操作的高階管理用例 .對於每個子系統詳細的配置屬性，請參考每個子系統的參考文件。
配置的 schema 檔案都在目錄 $JBOSS_HOME/docs/schema
4.4.5.1. 資料來源 (Data sources)
Datasources 在通過子系統進行配置。宣告一個新的資料來源，需要兩個步驟 : 提供一個 JDBC 驅動，然後定義一個使用這個 JDBC驅動的資料來源。
4.4.5.1.1. JDBC驅動安裝
在應用伺服器中安裝 JDBC驅動推薦使用一個常規的 jar進行部署。因為當在域模式下執行應用伺服器時，部署的內容會自動傳送到要部署的所有伺服器上，因此使用 jar檔案將利用這一特性而不需要關心額外的事情。
任何符合 JDBC4的啟動將會被自動識別並且按照名字和版本安裝到系統中。 JDBC jar使用 Java server provider機制進行識別。 Jar檔案中需要包含一個檔名是 META-INF/services/java.sql.Driver 的文字檔案 ,這個檔案中包含在這個 jar裡的驅動類的名稱。如果你的 JDBC驅動 jar不符合 JDBC規範，我們通過其他方式也可以部署這樣的驅動。
修改 Jar 檔案
最直接的方式是簡單的修改 Jar檔案新增缺失的檔案。你可以通過一下命令新增 :
The most straightforward solution is to simply modify the JAR and add the missing file. You can do
- 改變路徑到或者建立一個空的臨時資料夾 .
- 建立一個 META-INF 子目錄
- 建立一個 META-INF/services 子目錄
- 建立 一個只包含一行內容 :JDBC驅動類的全名的檔案 META-INF/services/java.sql.Driver .
- 使用 jar命令來跟新這個 jar檔案 :
jar \-uf jdbc-driver.jar META-INF/services/java.sql.Driver
如何部署
JDBC4驅動
jar檔案，請參考”應用部署 “章節。
4.4.5.1.2. 資料來源定義 (Datasource Definitions)
subsystem xmlns="urn:jboss:domain:datasources:1.0">
<datasources>
<datasource jndi-name="java:jboss/datasources/ExampleDS" pool-name="ExampleDS">
<connection-url>jdbc:h2:mem:test;DB_CLOSE_DELAY=-1</connection-url>
<driver>h2</driver>
<pool>
<min-pool-size>10</min-pool-size>
<max-pool-size>20</max-pool-size>
<prefill>true</prefill>
</pool>
<security>
<user-name>sa</user-name>
<password>sa</password>
</security>
</datasource>
<xa-datasource jndi-name="java:jboss/datasources/ExampleXADS" pool-name="ExampleXADS">
<driver>h2</driver>
<xa-datasource-property name="URL">jdbc:h2:mem:test</xa-datasource-property>
<xa-pool>
<min-pool-size>10</min-pool-size>
<max-pool-size>20</max-pool-size>
<prefill>true</prefill>
</xa-pool>
<security>
<user-name>sa</user-name>
<password>sa</password>
</security>
</xa-datasource>
<drivers>
<driver name="h2" module="com.h2database.h2">
<xa-datasource-class>org.h2.jdbcx.JdbcDataSource</xa-datasource-class>
</driver>
</drivers>
</datasources>
</subsystem>
(參見 standalone/configuration/standalone.xml)
如以上示例所示，資料來源通過邏輯名來引用 JDBC驅動 .通過命令列 (CLI)可以很方便的查詢同樣的資訊 :
[standalone@localhost:9999 /] /subsystem=datasources:read-resource(recursive=true)
{
"outcome" => "success",
"result" => {
"data-source" => {"java:/H2DS" => {
"connection-url" => "jdbc:h2:mem:test;DB_CLOSE_DELAY=-1",
"jndi-name" => "java:/H2DS",
"driver-name" => "h2",
"pool-name" => "H2DS",
"use-java-context" => true,
"enabled" => true,
"jta" => true,
"pool-prefill" => true,
"pool-use-strict-min" => false,
"user-name" => "sa",
"password" => "sa",
"flush-strategy" => "FailingConnectionOnly",
"background-validation" => false,
"use-fast-fail" => false,
"validate-on-match" => false,
"use-ccm" => true
}},
"xa-data-source" => undefined,
"jdbc-driver" => {"h2" => {
"driver-name" => "h2",
"driver-module-name" => "com.h2database.h2",
"driver-xa-datasource-class-name" => "org.h2.jdbcx.JdbcDataSource"
}}
}
}
[standalone@localhost:9999 /] /subsystem=datasources:installed-drivers-list
{
"outcome" => "success",
"result" => [{
"driver-name" => "h2",
"deployment-name" => undefined,
"driver-module-name" => "com.h2database.h2",
"module-slot" => "main",
"driver-xa-datasource-class-name" => "org.h2.jdbcx.JdbcDataSource",
"driver-class-name" => "org.h2.Driver",
"driver-major-version" => 1,
"driver-minor-version" => 2,
"jdbc-compliant" => true
}]
}
使用 web控制檯和命令列可以極大的簡化 JDBC驅動的部署和資料來源的建立。
命令列方式提供了一些列的命令來建立和更改資料來源 :
[standalone@localhost:9999 /] help
Supported commands:
[...]
data-source - allows to add new, modify and remove existing data sources
xa-data-source - allows add new, modify and remove existing XA data sources
特定命令的詳細描述請使用”
-b”引數查詢。
4.4.5.1.3. 參考
datasource子系統由 IronJacamar 專案提供。更多關於配置屬性和屬性的詳細介紹請參考專案文件 :
- IronJacamar 主頁 : http://www.jboss.org/ironjacamar
- 專案文件 : http://www.jboss.org/ironjacamar/docs
- Schema描述 : http://docs.jboss.org/ironjacamar/userguide/1.0/en-US/html/deployment.html#deployingds_descriptor
4.4.5.2. 訊息 (Messaging)
JMS伺服器需要通過 messaging子系統進行配置。在本章節中，我們將概括介紹常用的配置項。其他詳細的介紹，請參考 HornetQ使用者指南 (參見 "參考 ").
4.4.5.2.1. Connection Factories
JMS connection factories 可以分為兩類 : In-VM connection factory和被遠端客戶端使用的 connections factories. 每個 connecton factory都引用一個 connector ，每個
connector都關聯到一個 socket binding. Connection Factory的 entry定義 factory被暴露的 JNDI name.
<subsystem xmlns="urn:jboss:domain:messaging:1.0">
[...]
<connectors>
<in-vm-connector name="in-vm" server-id="0"/>
<netty-connector name="netty" socket-binding="messaging"/>
<netty-connector name="netty-throughput" socket-binding="messaging-throughput">
<param key="batch-delay" value="50"/>
</netty-connector>
</connectors>
[...]
<jms-connection-factories>
<connection-factory name="InVmConnectionFactory">
<connectors>
<connector-ref connector-name="in-vm"/>
</connectors>
<entries>
<entry name="java:/ConnectionFactory"/>
</entries>
</connection-factory>
<connection-factory name="RemoteConnectionFactory">
<connectors>
<connector-ref connector-name="netty"/>
</connectors>
<entries>
<entry name="RemoteConnectionFactory"/>
</entries>
</connection-factory>
<pooled-connection-factory name="hornetq-ra">
<connectors>
<connector-ref connector-name="in-vm"/>
</connectors>
<entries>
<entry name="java:/JmsXA"/>
</entries>
</pooled-connection-factory>
</jms-connection-factories>
[...]
</subsystem>
( 參見 standalone/configuration/standalone.xml)
4.4.5.2.2. Queues and Topics
Queues 和 topics 是 messaging 子系統的子資源 .每個 Entry指定一個 queue或者 topic的 JNDI名 :
<subsystem xmlns="urn:jboss:domain:messaging:1.0">
[...]
<jms-destinations>
<jms-queue name="testQueue">
<entry name="queue/test"/>
</jms-queue>
<jms-topic name="testTopic">
<entry name="topic/test"/>
</jms-topic>
</jms-destinations>
</subsystem>
(參見 standalone/configuration/standalone.xml)
JMS endpoints 通過命令列方式可以很容易的建立 :
[standalone@localhost:9999 /] add-jms-queue --name=myQueue --entries=queues/myQueue
[standalone@localhost:9999 /] /subsystem=messaging/jms-queue=myQueue:read-resource
{
"outcome" => "success",
"result" => {"entries" => ["queues/myQueue"]},
"compensating-operation" => undefined
}
JbossAS同時也提供了其他很多的維護
JMS子系統的命令
:
[standalone@localhost:9999 /] help
Supported commands:
[...]
add-jms-queue - creates a new JMS queue
remove-jms-queue - removes an existing JMS queue
add-jms-topic - creates a new JMS topic
remove-jms-topic - removes an existing JMS topic
add-jms-cf - creates a new JMS connection factory
remove-jms-cf - removes an existing JMS connection factory
獲取更多命令列的詳細資訊，請使用”
--help”引數獲取。
4.4.5.2.3. Dead Letter和Redelivery
有些設定可以在萬用字元地址上生效，而不是一個特別的 messaging destination.Dead letter queue和 redelivery設定就可以使用萬用字元地址 :
<subsystem xmlns="urn:jboss:domain:messaging:1.0">
[...]
<address-settings>
<address-setting match="#">
<dead-letter-address>
jms.queue.DLQ
</dead-letter-address>
<expiry-address>
jms.queue.ExpiryQueue
</expiry-address>
<redelivery-delay>
0
</redelivery-delay>
[...]
</address-setting>
</address-settings>
[...]
</subsystem>
(參見 standalone/configuration/standalone.xml)
4.4.5.2.4. 安全性
安全性的設定也可以使用萬用字元地址生效，如同 DLQ和 redelivery設定一樣 :
<subsystem xmlns="urn:jboss:domain:messaging:1.0">
[...]
<security-settings>
<security-setting match="#">
<permission type="send" roles="guest"/>
<permission type="consume" roles="guest"/>
<permission type="createNonDurableQueue" roles="guest"/>
<permission type="deleteNonDurableQueue" roles="guest"/>
</security-setting>
</security-settings>
[...]
</subsystem>
(參見 standalone/configuration/standalone.xml)
4.4.5.2.5. 參考
Messaging 子系統由 Hornetq專案提供。詳細的關於可用的配置項資訊，請查詢 hornetq專案文件。
- HornetQ主頁 : http://www.jboss.org/hornetq
- 專案文件 : http://www.jboss.org/hornetq/docs
4.4.5.3. Web
Web子系統的配置由三個部分組成 :JSP, connectors和 virtural servers。高階特性如 :負載均衡， failover等將在高”可用性指南”中介紹。預設配置對於大多數的用例都可以提供合理的效能。
需要的擴充套件 :
<extension module="org.jboss.as.web" />
基本子系統配置的例子 :
<subsystem xmlns="urn:jboss:domain:web:1.0" default-virtual-server="default-host">
<connector name="http" scheme="http" protocol="HTTP/1.1" socket-binding="http"/>
<virtual-server name="default-host" enable-welcome-root="true">
<alias name="localhost" />
<alias name="example.com" />
</virtual-server>
</subsystem>
依賴於其他子系統 : 無 .
4.4.5.3.1. 容器設定 (Container configuration)
JSP設定 (JSP Configuration)
這裡的”配置“包含了所有關於 servlet engine自身的設定。詳細的關於配置屬性的介紹，請參考 JBossWeb有關文件.
[standalone@localhost:9999 /] /subsystem=web:read-resource
{
"outcome" => "success",
"result" => {
"configuration" => {
"static-resources" => {
"sendfile" => 49152,
"max-depth" => 3,
"read-only" => true,
"webdav" => false,
"listings" => false,
"disabled" => false
},
"jsp-configuration" => {
"development" => false,
"keep-generated" => true,
"recompile-on-fail" => false,
"check-interval" => 0,
"modification-test-interval" => 4,
"display-source-fragment" => true,
"error-on-use-bean-invalid-class-attribute" => false,
"java-encoding" => "UTF8",
"tag-pooling" => true,
"generate-strings-as-char-arrays" => false,
"target-vm" => "1.5",
"dump-smap" => false,
"mapped-file" => true,
"disabled" => false,
"source-vm" => "1.5",
"trim-spaces" => false,
"smap" => true
}
},
"connector" => {"http" => undefined},
"virtual-server" => {"localhost" => undefined}
}
}
(參見 standalone/configuration/standalone.xml)
4.4.5.3.2. Connector設定 (Connector configuration)
Connecotrs是 web子系統的子資源。每個 connector都引用一個特定的 socket binding:
[standalone@localhost:9999 /] /subsystem=web:read-children-names(child-type=connector)
{
"outcome" => "success",
"result" => ["http"]
}
[standalone@localhost:9999 /] /subsystem=web/connector=http:read-resource(recursive=true)
{
"outcome" => "success",
"result" => {
"protocol" => "HTTP/1.1",
"scheme" => "http",
"socket-binding" => "http",
"ssl" => undefined,
"virtual-server" => undefined
}
}
建立一個 connector需要先宣告一個 socket binding：
[standalone@localhost:9999 /] /socket-binding-group=standard-sockets/socket-binding=custom:add(port=8181)
新建立的沒有被使用的
socket binding可以用來建立一個新的
connector配置
:
[standalone@localhost:9999 /] /subsystem=web/connector=test-connector:add(
socket-binding=custom, scheme=http, protocol="HTTP/1.1", enabled=true
)
web子系統可以配置三種型別的 connecotr:
HTTP Connectors
預設的 connector,通常執行在 8080埠。配置請參考以上內容
HTTPS Connectors
HTTPS connectors是 web子系統的子資源。預設使用 JSSE.每個 connector引用一個特定的 socket binding：
[standalone@localhost:9999 /] /subsystem=web:read-children-names(child-type=connector)
{
"outcome" => "success",
"result" => [
"ajp",
"http",
"https"
]
}
[standalone@localhost:9999 /] /subsystem=web/connector=https:read-resource(recursive=true)
{
"outcome" => "success",
"result" => {
"protocol" => "HTTP/1.1",
"scheme" => "https",
"secure" => true,
"socket-binding" => "https",
"ssl" => {},
"virtual-server" => undefined
}
}
建立一個新的 connector首先需要宣告一個新的 socket binding:
[standalone@localhost:9999 /] /socket-binding-group=standard-sockets/socket-binding=https:add(port=8443)
新建立的，沒有使用的
socket binding可被用來設定新建立的
connecotr：
[standalone@localhost:9999 /] /subsystem=web/connector=test-connector:add(socket-binding=https, scheme=https, protocol="HTTP/1.1", enabled=true, ssl = {})
預設 SSL使用” tomcat”別名和” changit”密碼。可以使用 keytool來建立相應的 keystore:
keytool -genkey -alias tomcat -keyalg RSA
當然需要指定值是” changeit”的密碼。
AJP Connectors
AJP Connectors是 web子系統的子資源。它和前段 apache httpd的 mod_jdk,mode_proxy和 mod_cluster一起使用。
每個 connecotor都引用一個特定的 socket binding:
[standalone@localhost:9999 /] /subsystem=web:read-children-names(child-type=connector)
{
"outcome" => "success",
"result" => [
"ajp",
"http"
]
}
[standalone@localhost:9999 /] /subsystem=web/connector=ajp:read-resource(recursive=true)
{
"outcome" => "success",
"result" => {
"protocol" => "AJP/1.3",
"scheme" => "http",
"socket-binding" => "ajp",
"ssl" => undefined,
"virtual-server" => undefined
}
}
建立一個新的 connector首先需要宣告一個新的 socket binding:
[standalone@localhost:9999 /] /socket-binding-group=standard-sockets/socket-binding=ajp:add(port=8009)
新建立的，沒有使用的
socket binding可被用來設定新建立的
connecotr：
[standalone@localhost:9999 /] /subsystem=web/connector=ajp:add(
socket-binding=ajpm, protocol="AJP/1.3", enabled=true
)
Native Connectors
Native connectors是基於 Tomcat native的高效能的 connectors.如果 nativie模組安裝的話，就可以使用 native connectors 。
目前很多釋出已經包含 jboss web native(如果你還沒有試用過 JBoss web native)。
在配置層面，由於使用 OpenSSL,只有 SSL部分需要被不同的配置。
[standalone@localhost:9999 /] /subsystem=web/connector=https:read-resource(recursive=true)
{
"outcome" => "success",
"result" => {
"protocol" => "HTTP/1.1",
"scheme" => "https",
"secure" => true,
"socket-binding" => "https",
"ssl" => {
"certificate-file" => "/home/jfclere/CERTS/SERVER/newcert.pem",
"certificate-key-file" => "/home/jfclere/CERTS/SERVER/newkey.pem",
"password" => "xxxxxxx"
},
"virtual-server" => undefined
}
}
4.4.5.3.3. Virtual-server配置（Virtual-Server configuration）
和 connector類似， virtual server 宣告 web 子系統的子資源。可以通過使用別名來引用 virtual server,
同時 virtual server 也可以指定預設的 web 應用來充當 root web context 。
[standalone@localhost:9999 /] /subsystem=web:read-children-names(child-type=virtual-server)
{
"outcome" => "success",
"result" => ["localhost"]
}
[standalone@localhost:9999 /] /subsystem=web/virtual-server=default-host:read-resource
{
"outcome" => "success",
"result" => {
"access-log" => undefined,
"alias" => ["example.com"],
"default-web-module" => undefined,
"enable-welcome-root" => true,
"rewrite" => undefined
}
}
增加一個 virtual server的宣告可以通過預設的 add操作 :
[standalone@localhost:9999 /] /subsystem=web/virtual-server=example.com:add
[standalone@localhost:9999 /] /subsystem=web/virtual-server=example.com:remove
在 configuration tree上任意一個節點上都可以執行增加和刪除操作
4.4.5.3.4. 參考
Web子系統部件由 jboss web專案提供。關於 web子系統可配置的屬性的詳細介紹，請參考 JBoss Web文件 :
- JBoss Web 配置和參考 : http://docs.jboss.org/jbossweb/7.0.x/config/index.html
- JBossWeb 主頁 : http://www.jboss.org/jbossweb
- 專案文件 : http://docs.jboss.org/jbossweb/7.0.x/
4.4.5.4. Web services
Web service endpoint 通過包含有 webservice endpoint 實現的部署來提供因此他們可以通過部署資源進行查詢。
進一步的資訊，請參考”應用部署”章節。每個 webservice endpoint 都需要指定一個 web context 和一個 wsdl的 URL :
[standalone@localhost:9999 /] /deployment="*"/subsystem=webservices/endpoint="*":read-resource
{
"outcome" => "success",
"result" => [{
"address" => [
("deployment" => "jaxws-samples-handlerchain.war"),
("subsystem" => "webservices"),
("endpoint" => "jaxws-samples-handlerchain:TestService")
],
"outcome" => "success",
"result" => {
"class" => "org.jboss.test.ws.jaxws.samples.handlerchain.EndpointImpl",
"context" => "jaxws-samples-handlerchain",
"name" => "TestService",
"type" => "JAXWS_JSE",
"wsdl-url" => "http://localhost:8080/jaxws-samples-handlerchain?wsdl"
}
}]
}
4.4.5.4.1. 參考
Webservice 子系統由 JBossWS專案提供。關於 websevice子系統可配置的屬性的詳細介紹，請參考 JBoss WS文件 :
- JBossWS 主頁 : http://www.jboss.org/jbossws
- 專案文件 : https://docs.jboss.org/author/display/JBWS