EJB3.0中的session bean以及MDB解析

版权声明：本文为博主原创文章，未经博主同意不得转载。

https://blog.csdn.net/aboy123/article/details/24587133

大型业务系统面临的主要问题就是高并发性和事务訪问，client的数量与server端的分布式对象数量存在一定程度的正比关系，client数量越多。server端分布式对象也就越多。怎样解决这样的高并发的问题也就成了企业级架构首先要解决的问题。EJB作为一种server端分布式组件，为我们提供了应对策略。

EJB提供了两种管理大量分布式对象的策略：实例池化和激活。

以下分别对EJB组件模型中的三种模型进行一些分析。

第一种：无状态的会话Bean（Stateless session bean)
Stateless session bean採用池化技术来实现，stateless session bean的client不直接于bean class的实例进行通信。而是通过bean class所暴漏的远程或者本地接口来通信。再进一步的讲就是通过bean class的代理存根来与EJB容器通信。这样以来就能够为每个bean class维护一个的实例池。然后用这些实例来为大量的客户进行服务。

stateless session bean的生命周期由三个不同的状态来组成。

不存在，池化状态以及就绪状态。

不存在就说明bean class的实例还没有初始化，池化状态就说明实例已经初始化了，可是还没有与EJB Obejct关联（骨架），就绪状态说明实例已经于EJB请求关联了。能够为客户提供服务了。

另外一种：消息驱动bean。
MDB相同也採用池化技术来实现。仅仅所以能够採用池化技术，是由于MDB的client也不于详细的MDB实例进行通信，相反是通过一种松耦合的方式来实现。首先客户发送消息给EJB容器的消息目的地，然后EJB容器再将消息发送到详细订阅此目的地的MDB实例。

相同的道理，EJB容器也为每个MDB class维护一个实例池，当有消息发送到此MDB订阅的目的地时，EJB容器就会挑选一个MDB class的实例来接受和处理消息。

第三种：有状态的会话bean (Statefull session bean)

与stateless bean 和MDB不同，Statefull session bean採用激活机制来实现，为什么採用激活机制来实现，是由于有状态的会话bean要维护于client的会话状态，每个实例仅仅能服务于同一个client。

MDB採用激活机制来减少server资源的消耗，当EJB容器资源不够的时候。它就会选择一些能被钝化的实例。将其序列化到磁盘上，当须要的时候，再将其从磁盘恢复到内存中。

综上所述。client与EJB组件进行通信时，它们事实上都不是直接于bean class的实例进行通信，而是通过本地的代理存根于server端的骨架进行通信，而骨架再将详细的EJB请求托付给详细的bean class的实例来响应。