感謝朋友【吳傑】投遞本文。

WildFly，前身是JBoss AS，從V8開始為區別於JBoss EAP，更名為WildFly。Wildfly 8主要具備如下特性：

• Java EE7的參考實現（2013年7月止尚未得到Java EE7相容認證）
• 啟動速度更快，佔用記憶體更少
• 模組化(JSR294)設計
• 統一配置管理
• 分散式domain管理

本文主要討論一下WildFly 8的模組化系統。

WildFly之所以啟動很快，模組化元件jboss-modules功不可沒。作為OSGi和Jigsaw(JSR 294 http://jcp.org/en/jsr/detail?id=294)“夾擊”之下的衍生物，與jboss-msc成為WildFly的全新核心。

jboss-modules解決什麼問題

JBoss Modules就是解決傳統的層級機制的ClassLoader所帶來的Jar Hell問題：

(1)     JAR被載入後不使用導致資源浪費。

(2)     同名JAR包的不同版本混在導致依賴衝突。

JBoss Modules使所有的jar都打包成為模組，一個jar再也不會看到依賴中有版本衝突的類，或者載入到一個不需要載入的資源。同時，按需載入模組可以明顯地提高大型應用的啟動時間。

圖 1 傳統的ClassLoading vs. jboss-modules的ClassLoading

傳統的ClassLoading vs. jboss-modules的ClassLoading

與Jigsaw(JSR 294)的關係

Jigsaw已經被延遲到Java SE 9。JBoss Modules會與JSR294相容，如果Jigsaw專案能夠穩定，並且成為OpenJDK的一部分，JBoss承諾將維護JBoss Modules的相容性。

與OSGi的關係

個人認為是互補的關係，通過Jboss-modules進行模組化的應用伺服器，使得OSGi的Bundle形式不再成為模組化的唯一方式，更加靈活。另外它更為小巧，沒有OSGi的Sevice層，或者其他OSGI提供的更高層次的功能，它只做一件事情，就是模組化。

圖 2 WildFly Architecture

WildFly Architecture

注：上圖中的Subsystems沒有列全，full-ha Profile的子系統如下圖：

圖 3 full-ha的子系統一覽

full-ha的子系統一覽

接下來簡單與Oracle的Java EE 7的RI，GlassFish V4.0做一個簡單的架構對比

圖 4 GlassFish V4.0與WildFly 8的系統棧圖

GlassFish V4.0與WildFly 8的系統棧圖

【筆者觀點】GlassFish與WildFly在架構實現上最大區別在於模組系統的構成。

GlassFish的做法

採用OSGi的模組化作為GlassFish的模組化系統/基盤；用HK2替代了OSGi的服務層。

WildFly的做法

鑑於Jigsaw的難產，JBoss推出自己的模組化實現並作為WildFly的模組化系統/基盤；將JBoss MSC(Module Service Container)作為其服務容器。預設情況下將OSGi排除在WildFly系統棧之外（從8.0.0.Alpha3開始OSGi子系統已經從WildFly移除，今後將提供以add-on的形式與Wildfly整合。https://issues.jboss.org/browse/WFLY-1638），該點與GlassFish不同（GlassFish與OSGi執行時是緊耦合的）。

排除廠商利益因素，筆者更喜歡JBoss的設計，原因以下：

(1)     通過JBoss Modules將WildFly與OSGi解耦，並且相容Jigsaw。設計上更為優雅，且更具遠見。

(2)     OSGi在Java EE開發領域並沒有被廣泛接受(如下圖，來自於zeroturnaround)，離真正落地尚需時日。JBoss的設計理念更貼近開發人員。

圖 5 2012年度Java標準的被接受度一覽

2012年度Java標準的被接受度一覽