作为系列文章的开篇,以JBOSS EAP 6.1的新特性为索引介绍一下新的老容器JBOSS在7以后引入的新特性。本系列的介绍对JBOSS EAP 6.1以上、JBOSS AS 7.2以上直到wildfly8都适用。
1. 在以上描述的模块化类加载系统避免了包冲突的基础上,JEE6对EJB 项目的严格配置也为包冲突问题提供了很好的解决方案。MANIFAST中必须指明所依赖的模块。《EJB实现—贯穿始终的模块》。
2. JNDI的全面升级,使得Bean的重名问题和客户端stub的定位都得到很好的解决:EJB JNDI名字不再可以随便自定义,EJBJNDI的全名规范:
java:global[/<app-name>]/<module-name>/<bean-name>[!<fully-quali?fied-interface-name>]
其中包含了WAR包名称app-name,JAR包名称module-name,自定义Bean名称bean-name,接口的全地址名称,还有stateful的话需要声明stateful。如: CommonDAO/UTM/Common_DAO!com.hp.ngoss.utm.commondao.CommonDAOBusiness
对EJB3.1 Jboss的客户端有两个专题的详细讲解《让人又爱又恨的EJB3.1 JNDI》和《去掉jboss-ejb-client.properties》。
3. 对Singleton Session bean的支持,每个虚拟机只提供一个实例,单例模式在应用级别的实现。
4. 提供异步方法(Asynchronous methods),EJB支持Future方式获得交互结果,提高了线程的使用率。见本系列文章:《异步Bean》
5. JPA(hibernate4)的全面支持,简化持久化层的开发工作。见本系列文章《JPA/hibernate》
6. *没有接口的Session Bean。不推荐,理由:无论是CORBA还是Web Service都没有说不要Stub的概念。类似的,EJB要能够被调用,需要知道接口,不提供接口的方式必然需要在调用的时候创建接口以及对应的输入输出参数信息,这样一来增加传输的流量开销;当然不是说完全没价值,对于服务提供对象是第三方的客户时,有时会不提供编程接口,这种情况便可以采用此方式,但通常来说服务供认者与客户是友好关系,直接提供接口给客户不违背良心。基于之前说的问题,本人不推荐使用这种方式。
7. *在动态Web项目中实现Session Bean。不太推荐使用,这个使得JEE的4层架构中的Web层与Business层的界线混淆,出于解耦的目的,不推荐使用。可能的使用场景,JBOSS自己提供的EJB只给自己的web层使用,没有分布式的场景。
8. Managed domains: 管理域组织各物理机上的虚拟服务为服务组,使得所有服务器在一个地方统一配置、统一部署。配置为同一服务组内的机器可以自动扩展,也可以在一台主机上根据不同的端口绑定来设置多个实例。Managed Domain要区别与Cluster,Cluster的主要功能是负载均衡、容灾,而Managed domain的目的主要在于统一管理。本系列八《Managed Domains》详细的介绍了一个管理域的实现,并讲解了管理域的统一配置、统一部署的特性。本系列九《Cluster负载均衡集群》介绍了JBOSS EAP 6(JbossAS7)的集群配置方式。
9. Infinispan: http://www.oschina.net/p/infinispan/
看到JBOSS EAP带来的各种好处的同时,也希望JBOSS EAP能即像WebLogic等厂商经营的应用服务器一样,提供更多专业的为开发和实施带来便利的能力(如自动升级应用)。同时也能保持开源社区的包容性和技术的多样性,更开放的尝试各种新技术,新架构,新思想。