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