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

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

EJB提供了两种管理大量分布式对象的策略：实例池化和激活。下面分别对EJB组件模型中的三种模型进行一些分析。

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

stateless session bean的生命周期由三个不同的状态来组成。不存在，池化状态以及就绪状态。不存在就说明bean class的实例还没有初始化，池化状态就说明实例已经初始化了，但是还没有与EJB Obejct关联（骨架），就绪状态说明实例已经于EJB请求关联了，可以为客户提供服务了。

第二种：消息驱动bean。
MDB同样也采用池化技术来实现，只所以可以采用池化技术，是因为MDB的客户端也不于具体的MDB实例进行通信，相反是通过一种松耦合的方式来实现。首先客户发送消息给EJB容器的消息目的地，然后EJB容器再将消息发送到具体订阅此目的地的MDB实例。

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

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

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

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

综上所述，客户端与EJB组件进行通信时，它们其实都不是直接于bean class的实例进行通信，而是通过本地的代理存根于服务器端的骨架进行通信，而骨架再将具体的EJB请求委托给具体的bean class的实例来响应。