Java中的EJB的介绍（java ejb是啥）-编程开发-知优网

本文先向您介绍Java中的EJB，接着详细描述了HelloWorldbean的一些代码。

EJB是sun的服务器端组件模型，***的用途是布置分布式应用程序，相似微软的.net技能。凭仗Java跨渠道的优势，用EJB技能布置的分布式体系能够不限于特定的渠道。

EJB (Enterprise JavaBean)是J2EE的一部分，界说了一个用于开发依据组件的企业多重应用程序的标准。其特色包括网络服务支撑和中心开发东西(SDK)。

在J2EE里，Enterprise Java Beans(EJB)称为Java 企业Bean，是Java的中心代码，分别是会话Bean（Session Bean），实体Bean（Entity Bean）和音讯驱动Bean（MessageDriven Bean）。

1.Session Bean用于完结事务逻辑，它能够是有状况的，也能够是无状况的。每逢客户端恳求时，容器就会挑选一个Session Bean来为客户端服务。Session Bean能够直接拜访数据库，但更多时分，它会经过Entity Bean完结数据拜访。

2.Entity Bean是域模型方针，用于完结O/R映射，担任将数据库中的表记载映射为内存中的Entity方针，事实上，创立一个Entity Bean方针相当于新建一条记载，删去一个Entity Bean会一起从数据库中删去对应记载，修正一个Entity Bean时，容器会主动将Entity Bean的状况和数据库同步。

3.MessageDriven Bean是EJB2.0中引进的新的企业Bean，它依据JMS音讯，只能接纳客户端发送的JMS音讯然后处理。MDB实践上是一个异步的无状况Session Bean，客户端调用MDB后无需等候，马上回来，MDB将异步处理客户恳求。这适合于需求异步处理恳求的场合，比方订单处理，这样就能防止客户端长期的等候一个办法调用直到回来成果。

EJB实践上是SUN的J2EE中的一套标准,而且规矩了一系列的API用来完结把 EJB概念转换成EJB产品.EJB是BEANS,BEANS是什么概念,那便是得有一个包容她,让她可劲造腾的当地,便是得有容器.EJB有必要生存在 EJB容器中.这个容器可是功能强大之极!她首要要包装你BEAN,EJB的客户程序实践上历来就不和你编写的EJB直接打交道,他们之间是经过 HOME/REMOTE接口来发生联系的.它担任你的BEAN的全部的吃喝拉萨睡,比方BEAN的继续化,安全性,事务管理...

因为EJB2.0的杂乱性，在Spring和Hibernate等轻量级结构呈现后，许多的用户转向了，在咱们的呼声中，EJB3.0标准总算发布了。

期待已久的EJB3.0标准在总算发布了。在本文中将对新的标准进行一个概要性的介绍，包括新增的元数据支撑，EJBQL的修正，实体Bean模型拜访 bean上下文的新办法和运行时环境等等。作者还评论了EJB在未来要作出的调整以及EJB3.0与其他开发标准之间的联系。

　　开端

无论怎么因为EJB的杂乱性使之在J2EE架构中的体现一向不是很好。EJB大概是 J2EE架构中仅有一个没有完结其能够简略开发并进步生产力的组成。EJB3.0标准正测验在这方面作出尽力以减轻其开发的杂乱性。EJB3.0减轻了开发人员进行底层开发的工作量，它撤销或最小化了许多(曾经这些是有必要完结)回调办法的完结，而且下降了实体Bean及O/R映射模型的杂乱性。

在本文中，我首要会介绍EJB3.0中几个首要的改动。它对进一步深化了解EJB3.0 是十分重要的。随后，我会从更高的层面来描绘现已被提交到EJB3.0标准中的细节，并一个个的解说新的标准中的改动:实体Bean,O/R映射模型，实体联系模型和EJB QL(EJB查询言语)等等。

　　布景

EJB3.0中两个重要的改动分别是:运用了Java5中的程序注释东西和依据Hibernate的O/R映射模型。

Java5(曾经叫J2SE1.5或Tiger) 中加入了一种新的程序注释东西。经过这个东西你能够自界说注释符号，经过这些自界说符号来注释字段、办法、类等等。这些注释并不会影响程序的语义，可是能够经过东西(编译时或运行时)来解说这些符号并发生附加的内容(比方布置描绘文件)，或许强制某些有必要的运行时行为(比方EJB组件的状况特性)。注释的解析能够经过源文件的解析(比方编译器或这IDE东西)或许运用Java5中的APIs反射机制。注释只能被界说在源代码层。因为全部被提交到 EJB3.0草案中的注释符号都有一个运行时的RetentionPolicy，因而会添加类文件占用的存储空间，但这却给容器制造商和东西制造商带来了便利。

现在Hibernate十分受欢迎，它是开发源代码的Java O/R映射结构，意图是把开发人员从繁琐的数据耐久化编程中摆脱出来。它也有一个标准的HQL(Hibernate 查询言语)言语，你能够在新的EJB QL中看到它的影子。Hibernate在处理如数据查询、更新、连接池、事务处理、实体联系处理等方面十分简略。

　　概览

在现已提交的EJB3.0标准中首要触及两个方面的改动:

1. 一套以注释为根底的EJB编程模型，再加上EJB2.1中界说的经过布置描绘符和几个接口界说的应用程序行为。

2. 新的实体Bean耐久化模型，EJBQL也有许多重要的改动。

还有一些有关上述的提议，比方:一个新的客户端编程模型，事务接口的运用以及实体Bean的生命周期。请留意EJB2.1编程模型(包括布置描绘符和home/remote接口)依然是有用的。新的简化模型并没有彻底替代EJB2.1模型。

　　EJB注释

EJB标准安排一个重要的方针是减轻原始代码的数量，而且他们为此给出了一个***而简介的办法。在EJB3.0的里，任何类型的企业级 Bean仅仅一个加了恰当注释的简略Java方针(POJO)。注释能够用于界说bean的事务接口、O/R映射信息、资源引证信息，效果与在 EJB2.1中界说布置描绘符和接口是相同的。在EJB3.0中布置描绘符不再是有必要的了;home接口也没有了，你也不用完结事务接口(容器能够为你完结这些工作)。

比方，你能够运用@Stateless注释符号类把Java类声明为一个无状况会话bean。关于有状况会话bean来说，@Remove注释能够用来符号一个特定的办法，经过这个注释来阐明在调用这个办法之后bean的实例将被清除去。

为了削减描绘组件的阐明信息，标准安排还选用了由反常进行装备(configuration-by-exception)的手法，意思是你能够为全部的注释供给一个清晰的缺省值，这样大都常规信息就能够据此揣度得出。

　　新的耐久化模型

新的实体bean也是一个加了注释的简略Java方针(POJO)。一旦它被 EntityManager拜访它就成为了一个耐久化方针，而且成为了耐久化上下文(context)的一部分。一个耐久化上下文与一个事务上下文是松耦合的;严厉的讲，它隐含的与一个事务会话共存。

实体联系也是经过注释来界说的，O/R映射也是，并供给几种不同的数据库标准操作，在EJB2.1中这些要经过开发人员自己的规划形式或许其它技能来完结的(比方，自增加主键战略)。

　　深化研究

现在是时分具体了解EJB3.0草案了。让咱们开端讨论全部EJB中四种企业级bean，并看看他们在新的标准中是什么姿态。

　　无状况会话bean

在EJB3.0标准中，写一个无状况会话bean(SLSB)只需求一个简略的Java文件并在类层加上@Stateless注释就能够了。这个bean能够扩展javax.EJB.SessionBean接口，但这些不是有必要的。

一个SLSB不再需求home接口，没有哪类EJB再需求它了。Bean类能够完结事务接口也能够不完结它。假如没有完结任何事务接口，事务接口会由恣意public的办法发生。假如只要几个事务办法会被暴露在事务接口中，这些办法能够运用 @BusinessMethod注释。缺省情况下全部发生的接口都是local(本地)接口，你也能够运用@Remote注释来声明这个接口为remote(长途)接口。#p#

下面的几行代码就能够界说一个HelloWorldbean了。而在EJB2.1中相同的bean至少需求两个接口，一个完结类和几个空的完结办法，再加上布置描绘符。


... 
　　;@NamedQuery( 
　　name="findAllCustomersWithName", 
　　queryString="SELECTcFROMCustomercWHEREc.nameLIKE:custName"
　　) 
　　.... 
　　;@InjectpublicEntityManagerem; 
　　customers=em.createNamedQuery("findAllCustomersWithName") 
　　.setParameter("custName","Smith") 
　　.listResults();

在提交的EJB3.0草案中，EJB QL与标准SQL十分的挨近。实践上标准中乃至直接支撑本地的SQL(就像咱们上面提到的那样)。这一点对某些程序员来说或许有些不是很清楚，咱们将鄙人面进行更具体的解说。

　　多样性

办法答应(Method permissions)能够经过@MethodPermissions和@Unchecked注释来声明;相同的，事务特点也能够经过 @TransactionAttribute注释来声明。标准中依然保存资源引证和资源环境引证。这些相同能够经过注释来声明，可是有一些纤细的不同。比方，上下文(context)环境要经过注入东西操控。容器依据bean对外部环境引证主动初始化一个恰当的现已声明的实例变量。比方，你能够象下面这样取得一个数据源(DataSource):


;@Resource(name="myDataSource")//Typeisinferredfromvariable 
publicDataSourcecustomerDB;

在上面的比方中假如你不指定引证资源的称号(name)那么其间的customerDB会被以为是默认值。当全部的引证特点都可得到时分@Injec注释就能够这样写:

;@InjectpublicDataSourcecustomerDB;
;@InjectpublicDataSourcecustomerDB;

容器担任在运行时初始化customerDB数据源实例。布置人员有必要在此之前在容器中界说好这些资源特点。

更好的音讯是:那些曾经有必要检测的反常将一去不复返。你能够声明恣意的应用程序反常，而不用在再抛出或捕获其他相似 CreateException和FinderException这样的反常。容器会抛出封装在javax.ejb.EJBException中的体系级反常或许只在必要时分抛出IllegalArgumentException或IllegalStateException反常。

　　EJB文件处理形式

在咱们完毕本节之前，让我的快速的阅读一下容器供给商在EJB处理形式方面或许的改动。标准中对此并没有清晰的表态，但我能够想到至少两种形式。

一种办法是首要运用EJB文件生成相似于EJB2.1布置形式的文件(包括必要的接口和布置描绘符)然后再用相似于EJB2.1的办法来布置这个EJB组件。当然，这样发生的布置描绘符或许并不标准可是它能够处理同一个容器对EJB2.1和 EJB3.0兼容的问题。下面这幅图描绘了这一进程。

另一种办法是一种相似于JSP托放的布置形式。你能够把一个EJB文件放到一个预先界说的目录下，然后容器会辨认这个EJB并处理它，然后布置并使之能够运用。这种办法能够建立于上面那种办法之上，在支撑重复布置时有很大的协助。考虑到布置的简略性也是EJB3.0标准的意图之一，我真挚的期望鄙人一个草案出来时能够确认一个形式(至少能有一个非正式的)。

　　你有什么主见?

EJB3.0标准的拟定正在有序的进行，为了使EJB的开发变得愈加简略，EJB标准安排作出的尽力是众所周知的。就像他们说的那样，全部对会变得简略，但做到这一点并不简略。现在现已界说了50个注释符号(还有几个将鄙人一个草案中发布)，每一个都有自己的缺省规矩和其他的操作。当然，我真的不期望EJB3.0变成EJB2.1的一个翻版"EJB 3.0 = EJB 2.1 for dummies"(期望这个等式不要建立)。***，我仍是不由得要提一些我自己的观念:

首要，标准的确使重复布置变得简略了，而且有一个简略的形式来拜访运行时环境。我仍是觉得home接口应该抛弃。

在前期的EJB标准中，实体bean用于映射一个耐久化存储。理论上(或许仅仅理论上) 或许需求把实体bean映射到一个留传的EIS (enterprise information system)体系中。出于将来扩展的考虑这样作是有优点的，而且能够使更多的事务数据模型选用实体bean。也因而其随同的杂乱性使得实体bean不被看好。在本次提交的草案中，一个实体bean仅仅一个数据库的映射。而且是依据非笼统耐久化形式和简略的数据拜访形式的愈加简略开发。

我对模型改动持保存情绪，我以为在EJB中包括SQL脚本片断并不是个好留意。一些开发人员彻底对立包括某些“SQL片段 (SQLness)”(比方@Table 和 @Column注释)。我的观念是这些SQLness是好的，据此咱们能够清楚的知道咱们究竟要数据库作些什么。可是某些SQL段我看来并不是很好，比方 columnDefinition="BLOB NOT NULL"，这使得EJB代码和SQL之间的耦合过火严密了。

虽然关于本地SQL的支撑看似很诱人，其实在EJB代码中嵌入SQL是一个十分糟糕的主见。当然，有些办法能够防止在EJB中硬编码SQL，可是这应该在标准中阐明，而不能是某些开发人员自己界说的形式。

假定@Table注释只用于类。在运行时经过@Table注释的name特点界说的表称号将有必要对应一个实践的数据库表。标准对此应该给予清楚的阐明和共同的形式。

标准还需求更清楚的阐明客户端编程模型，尤其是一般java客户端。标准中全部的参阅都假定或许隐含的运用EJB客户端。而且标准中对客户端的向后兼容方面也没有给出清晰的说法。

Transient注释应该重新命名以防止和已有的transient关键字发生抵触。事实上，在这一点上咱们更乐于略微的违背一下 configuration-by-exception准则而且界说一个@Persistent注释来清晰的界说耐久化字段 @Persistent注释能够仅仅是一个符号注释或许它能够有几个特点来相关O/R映射注释。

　　与其他标准的相关

现在或许影响到EJB3.0的JSR有JSR175(java言语元数据东西)和JSR181(Java Web服务元数据)

JSR175现已开始完结而且不会和EJB3.0有太大的抵触;可是JSR181与EJB3.0有两个相关的当地:

Web service接口:EJB标准将选用一种机制习惯JSR181以便能够把一个bean完结为一个Web service并告知Web service怎么被客户端调用。

JSR 181方案选用不同的机制来处理安全问题。在前期的标准中EJB主张运用一个共同的机制(MethodPermissions)，可是JSR 181方案运用一个略微不同的办法(SecurityRoles和SecurityIdentity注释)。相同的RunAs注释的界说也存在这少许不同。这一问题还在处理中最终会在J2EE层的标准中保持其共同性。

在J2EE 1.5中的一些开发标准或许与EJB3.0有相关。除了上面提到的几个相关之外现在没有其他的开发标准与EJB3.0有抵触。

　　完毕语

在使EJB的开发变得简略高效之前，咱们还有很长一段路要走。标准安排在下降EJB的开发难度方面起了个好头。O/R映射模型的提议还处在前期阶段，标准安排正在完善它。我期望它不要太杂乱也不要与SQL过火的耦合。

【修改引荐】