WildFly的模塊化系統

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不再會看到依賴中有版本衝突的類，或者加載到一個不須要加載的資源。同時，按需加載模塊能夠明顯地提升大型應用的啓動時間。

與Jigsaw(JSR 294)的關係

Jigsaw已經被延遲到Java SE 9。JBoss Modules會與JSR294兼容，若是Jigsaw項目可以穩定，而且成爲OpenJDK的一部分，JBoss承諾將維護JBoss Modules的兼容性。

與OSGi的關係

我的認爲是互補的關係，經過Jboss-modules進行模塊化的應用服務器，使得OSGi的Bundle形式再也不成爲模塊化的惟一方式，更加靈活。另外它更爲小巧，沒有OSGi的Sevice層，或者其餘OSGI提供的更高層次的功能，它只作一件事情，就是模塊化。

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

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

【筆者觀點】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的設計理念更貼近開發人員。

by 吳傑 via ifeve