EJB学习

EJB

     EJB是sun的JavaEE服务器端组件模型，设计目标与核心应用是部署分布式应用程序。简单来说就是把已经编写好的程序（即：类）打包放在服务器上执行。凭借java跨平台的优势，用EJB技术部署的分布式系统可以不限于特定的平台。EJB (Enterprise JavaBean)是J2EE(javaEE)的一部分，定义了一个用于开发基于组件的企业多重应用程序的标准。其特点包括网络服务支持和核心开发工具(SDK)。在J2EE里，Enterprise Java Beans(EJB)称为Java 企业Bean，是Java的核心代码，分别是会话Bean（Session Bean），实体Bean（Entity Bean）和消息驱动Bean（MessageDrivenBean）。在EJB3.0推出以后，实体Bean被单独分了出来，形成了新的规范JPA。

     EJB3.0中两个重要的变更分别是：使用了Java5中的程序注释工具和基于Hibernate的O/R映射模型。

1.EJB描述：

一个技术规范：EJB 从技术上而言不是一种"产品",EJB 是一种描述了构建应用组件要解决的标准：

可扩展(Scalable)

分布式(Distributed)

事务处理(Transactional)

数据存储(Persistent)

安全性 (Secure)

2.EJB 架构

为了满足架构的目标，规范中描述了:

服务器 (Server)

容器(Container)

类 (Class) 和实例(Instance)

Home 和 Remote 接口

客户端(Client)

3.三种bean   

     Entity Bean:

     实体Bean使用@Entity注释来标记，所有实体bean中的属性/字段不必使用@Transient注释来标记。实体bean的持久化字段可以通过JavaBean-style机制或者声明为public/protected字段来实现。

     EJB3.0同时支持Bean之间双向的和单向的关联，它们可以是一对一、一对多、多对一或者是多对多的关联。然而双向关联的两端还要分为自身端 (owning side)和对方端(inverse side)不同的端。自身端负责向数据库通告关联的变更。对于多对多的关联自身端必须明确的声明。实际上对方端通过isInverse=true进行注释.

     一个 enterprisebean 可以从客户端接受数据，对

它进行处理，并将其发送到企业信息系统层以作存储；同时它也可以从存储器获取数据，

处理后将其发送到客户端应用程序。

     Session Bean :

Session bean 描述了与客户端的一个短暂的会话。当客户端的执行完成后，session bean 和它的数据都将消失；

简单的理解为一个会话Bean完成一个用户功能。但是会话Bean不是持久的，当一个客户程序终止的时候，会话Bean的生命周期就结束了，与客户程序再无关联。会话Bean有根据是否为特定的客户程序保存状态分为有状态的会话Bean和无状态的会话Bean。

1): 有状态的会话Bean 是客户应用程序的扩展。代表客户程序执行任务并维护该程序的相关状态，该状态称为会话状态。在有状态会话Bean中调用的方法既可以从该会话状态中读取数据，也可以将数据写入该状态中。并且本次会话的状态由该会话Bean调用的所有方法共享

2):  无状态会话Bean不为特定的客户程序保持会话状态。

      Message Driver Bean

     Message-driven bean 结合了 session bean 和 Java信息服务（JMS）信息监听者的功能，它允许一个商业组件异步地接受 JMS消息。

      消息驱动Bean。消息驱动Bean允许J2EE应用程序异步的接收Java消息服务（JMS）的消息。消息驱动Bean包含处理接受到的消息的事务逻辑，主要作用是处理消息。它与其他Bean（实体Bean和会话Bean）的区别主要在于以下几点：

a) 消息驱动Bean没有任何接口，客户程序不是通过接口来访问消息驱动Bean的，它处理的消息可以来自任何消息客户程序。

b) 消息驱动Bean类似于无状态会话Bean，是没有状态的，它的实例不保持特定客户程序的会话状态。

c) 消息驱动Bean不需要返回任何数值给他的客户程序，也不能向客户程序返回异常，因为消息驱动Bean是异步地处理消息的。

      JMS的编程过程很简单，概括为：应用程序A发送一条消息到消息服务器的某个目地(Destination)，然后消息服务器把消息转发给应用程序B。因为应用程序A和应用程序B没有直接的代码关连，所以两者实现了解偶。

4.ejb远程调用原理-- ORMI协议

      

在Java领域中有很多可实现远程通讯的技术，例如：RMI、MINA、ESB、Burlap、Hessian、SOAP、EJB和JMS等.

http://blog.csdn.net/u012506661/article/details/55818021（远程通信必看）

 

同样的原理，于weblogic服务器作为中转站。实现服务端与客户端间的参数和返回值的传输，而唯一不同的地方：RMI技术是通过注册的方式写入到weblogic服务器上，而EJB3.0就直接咯，将一个EJB项目发布到weblogic中便可。

http://blog.csdn.net/illusion_luna/article/details/8108716

实质就是，客户端与服务端的EJB对象不在同一个JVM进程中，就是远程调用；客户端与服务端的EJB对象在同一个JVM进程中，就是本地调用。

远程调用是指运行在两个JVM中，通过通信建立的调用，本地调用是指运行在同一个JVM中，调用时传递的是一个引用，即一个内存地址。

http://www.cnblogs.com/sunsonbaby/archive/2004/09/10/41955.html

细看ejb远程调用的过程：

一个远程对象至少要包括4个class文件：远程对象；远程对象的接口；实现远程接口的对象的stub；对象的skeleton这4个class文件。

 

在EJB中则至少要包括10个class：

Bean类，特定AppServer的Bean实现类

 

Bean的remote接口，特定AppServer的remote接口实现类，特定App Server的remote接口的实现类的stub类和skeleton类。

 

Bean的home接口，特定AppServer的home接口实现类，特定App Server的home接口的实现类的stub类和skeleton类。 

 

和RMI不同的是，EJB中这10个class真正需要用户编写的只有3个，分别是Bean类和它的remote接口，home接口，至于其它的7个class到底是怎么生成，被打包在什么地方，或者是否需要更多的类文件，会根据不同的App Server表现出比较大的差异，不能一概而论。

 

拿我最熟悉的Weblogic的来说吧，Weblogic的Bean实现类，以及两个接口的Weblogic的实现类是在ejbc的时候被打包到EJB的jar包里面的，这3个class文件可以看到。而home接口和remote接口的Weblogic的实现类的stub类和skeleton类是在EJB被部署到Weblogic的时候，由Weblogic动态生成stub类和Skeleton类的字节码，因此看不到这4个类文件。

 

对于一次客户端远程调用EJB，要经过两个远程对象的多次RMI循环。首先是通过JNDI查找Home接口，获得Home接口的实现类，这个过程其实相当复杂，首先是找到Home接口的Weblogic实现类，然后创建一个Home接口的Weblogic实现类的stub类的对象实例，将它序列化传送给客户端（注意stub类的实例是在第1次RMI循环中，由服务器动态发送给客户端的，因此不需要客户端保存Home接口的Weblogic实现类的stub类），最后客户端获得该stub类的对象实例（普通的RMI需要在客户端保存stub类，而EJB不需要，因为服务器会把stub类的对象实例发送给客户端）。

 

客户端拿到服务器给它的Home接口的Weblogic实现类的stub类对象实例以后，调用stub类的create方法，(在代码上就是home.create()，但是后台要做很多事情),于是经过第2次RMI循环，在服务器端，Home接口的Weblogic实现类的skeleton类收到stub类的调用信息后，由它再去调用Home接口的Weblogic实现类的create方法。

 

在服务端，Home接口的Weblogic实现类的create方法再去调用Bean类的Weblogic实现类的ejbCreate方法，在服务端创建或者分配一个EJB实例，然后将这个EJB实例的远程接口的Weblogic实现类的stub类对象实例序列化发送给客户端。

 

客户端收到remote接口的Weblogic实现类的stub类的对象实例，对该对象实例的方法调用（在客户端代码中实际上就是对remote接口的调用），将传送给服务器端remote接口的Weblogic实现类的skeleton类对象，而skeleton类对象再调用相应的remote接口的Weblogic实现类，然后remote接口的Weblogic实现类再去调用Bean类的Weblogic实现类，如此就完成一次EJB对象的远程调用。