感谢朋友【吴杰】投递本文。
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就是解决传统的层级机制的ClassLoader所带来的Jar Hell问题：
(1) JAR被加载后不使用导致资源浪费。
(2) 同名JAR包的不同版本混在导致依赖冲突。
JBoss Modules使所有的jar都打包成为模块，一个jar再也不会看到依赖中有版本冲突的类，或者加载到一个不需要加载的资源。同时，按需加载模块可以明显地提高大型应用的启动时间。
图 1 传统的ClassLoading vs. jboss-modules的ClassLoading
传统的ClassLoading vs. jboss-modules的ClassLoading
Jigsaw已经被延迟到Java SE 9。JBoss Modules会与JSR294兼容，如果Jigsaw项目能够稳定，并且成为OpenJDK的一部分，JBoss承诺将维护JBoss Modules的兼容性。
个人认为是互补的关系，通过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标准的被接受度一览
文章转自 并发编程网-ifeve.com 相关资源：敏捷开发V1.0.pptx