仓酷云
标题:
JAVA编程：EJB3.0新标准概览及其将来开展
[打印本页]
作者:
不帅
时间:
2015-1-18 11:13
标题:
JAVA编程：EJB3.0新标准概览及其将来开展
ruby里有这些工具吗？又要简单多少？我没有用过这两门语言，我估计在这些语言力没有很统一的这种标准，或者根本就没有提供。标准
弁言
等候已久的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映照模子，实体干系模子和EJBQL(EJB查询言语)等等。
背景
EJB3.0中两个主要的变动分离是：利用了Java5中的程序正文工具和基于Hibernate的O/R映照模子。
Java5中的元数据工具。
Java5（之前叫J2SE1.5或Tiger）中到场了一种新的程序正文工具。经由过程这个工具你能够自界说正文标志，经由过程这些自界说标志来正文字段、办法、类等等。这些正文其实不会影响程序的语义，可是能够经由过程工具（编译时或运转时）来注释这些标志并发生附加的内容（好比部署形貌文件），大概强迫某些必需的运转时举动（好比EJB组件的形态特征）。正文的剖析能够经由过程源文件的剖析（好比编译器或这IDE工具）大概利用Java5中的APIs反射机制。正文只能被界说在源代码层。因为一切被提交到EJB3.0草案中的正文标志都有一个运转时的RetentionPolicy，因而会增添类文件占用的存储空间，但这却给容器打造商和工具打造商带来了便利。
Hibernate
今朝Hibernate十分受接待，它是开辟源代码的JavaO/R映照框架，目标是把开辟职员从烦琐的数据耐久化编程中摆脱出来。它也有一个尺度的HQL（Hibernate查询言语）言语，你能够在新的EJBQL中看到它的影子。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（远程）接口。
上面的几行代码就能够界说一个HelloWorldbean了。而在EJB2.1中一样的bean最少必要两个接口，一个完成类和几个空的完成办法，再加上部署形貌符。
importjavax.ejb.*;
/**
*Astatelesssessionbeanrequestingthataremotebusiness
*interfacebegeneratedforit.
*/
@Stateless
@Remote
publicclassHelloWorldBean{
publicStringsayHello(){
return"HelloWorld!!!";
}
}
有形态回话bean
除几个SFSB的出格申明以外，有形态回话bean(SFSB)和SLSB一样精简：
・一个SFSB应当有一个办法来初始化本人（在EJB2.1中是经由过程ejbCreate()来完成的）。在EJB3.0的标准中倡议这些初始化操纵能够经由过程自界说办法完成，并把他们表露在营业接口中。在利用这个bean之前由客户端来挪用响应的初始化办法。今朝标准构造就是不是供应一个正文来标志某个办法用于初始化还存在争议。
・Bean的供应者能够用@Remove正文来标志任何SFSB的办法，以申明这个办法被挪用以后bean的实例将被移除。一样，标准构造仍旧在会商是不是要有一种机制来处置这类特别的情形，即当这个办法呈现非常的情形下bean的实例是不是被移除。
上面是对以上成绩我团体的概念：
・是不是应当有一个正文来标明一个办法举行初始化呢？我的概念是――应当有，如许容器就能够在挪用其他办法之前最少挪用一个办法来举行初始化。这不但能够制止不用要的毛病(因为没有挪用初始化办法)并且可使容器更明白的判别是不是能够重用SFSB实例。我临时把这个成绩放一放，标准构造只思索为一个办法供应一个正文来声明它是一个初始化办法。
・关于第二个成绩我的概念也是一定的。这有益于Bean的供应者合客户端程序对其举行把持。只要一个遗留的成绩：那就是一旦挪用这个办法失利，是不是能移除这个bean的实例？谜底是不克不及，可是它将会在回话停止的时分被移除。
<P> 动静驱动Bean
动静驱动Bean是独一一种必需完成一个营业接口的Bean。这个接口指出bean撑持的是哪种动静体系。关于以JMS为基本的MDB来讲，这个接口是javax.jms.MessageListener。注重MDB营业接口不是一个真正意义上的营业接口，它只是一个动静接口。
实体Bean
・实体Bean利用@Entity正文来标志，一切实体bean中的属性/字段不用利用@Transient正文来标志。实体bean的耐久化字段能够经由过程JavaBean-style机制大概声明为public/protected字段来完成。
・实体bean可使用助手类来形貌其形态，可是这些类的实例并没有耐久化独一性（persistentidentity）的特征(即，独一标识这个bean的字段等)，实践上这些助手类与他们的实体bean实例是严密分离的；而且这些对象仍是以非共享体例来会见实体对象的。
实体联系关系
EJB3.0同时撑持Bean之间双向的合单向的联系关系，它们能够是一对1、一对多、多对一大概是多对多的联系关系。但是双向联系关系的两头还要分为本身端（owningside）和对方端（inverseside）分歧的端。本身端卖力向数据库公告联系关系的变动。关于多对多的联系关系本身端必需明白的声明。实践上对方端经由过程isInverse=true举行正文（由此本身端就不用申明了而是由另外一段揣度出）。看来下面的形貌，标准构造还能说让EJB变的复杂了吗？
O/R映照
EJB3.0中的O/R映照模子也有了主要的改动，它从本来的abstract-persistence-schema-based酿成了如今的Hibernate-inspired形式。只管今朝标准构造还在就此举行会商可是一个明白的模子将会呈现鄙人一个版本的草案中。
举例来讲，O/R映照模子将经由过程bean类中的正文来声明。并且此办法还会指出对应的详细表和字段。O/R映照模子供应了一套自有的SQL；并且除供应一些基础的SQL外还撑持某些高层开辟的功效。好比，有一个经由过程@Column正文声明的字段columnDefinition，那末能够写如许的SQL：columnDefinition="BLOBNOTNULL"
客户端程序模子
一个EJB客户端能够经由过程@Inject正文以一种“注进”的体例取得一个bean的营业接口援用。你也能够利用另外一个正文@javax.ejb.EJBContext.lookup()来完成下面的操纵，可是标准中没有告知我们一个一般的Java客户端如何取得一个Bean的实例，由于这个一般的Java客户端是运转在一个客户端容器中，它没法会见@javax.ejb.EJBContex对象。如今另有别的一种机制来完成下面的事情那就是利用一个超等高低文情况对象：@javax.ejb.Context()。可是标准中没有指出该怎样在客户端中利用这个对象。
EJBQL
EJBQL能够经由过程@NamedQuery来正文。这个正文有两个成员属性分离是name和queryString.一旦界说了这些属性，就能够经由过程EntityManager.createNamedQuery(name)来指向这个查询。你也能够创立一个尺度的JDBC作风的查询并利用EntityManager.createQuery(ejbqlString)或EntityManager.createNativeQuery(nativeSqlString)(这个办法用于实行一个当地查询)来实行查询。
EJBQL有两个中央能够界说其参数。javax.ejb.Query接口供应了界说参数、指向查询、更新数据等等办法。上面是一个EJBQL指向查询的例子：
....
@NamedQuery(
name="findAllCustomersWithName",
queryString="SELECTcFROMCustomercWHEREc.nameLIKE:custName"
)
....
@InjectpublicEntityManagerem;
customers=em.createNamedQuery("findAllCustomersWithName")
.setParameter("custName","Smith")
.listResults();
上面列出了一些EJBQL的加强特征：
・撑持批量更新和删除。
・间接撑持内毗连和外毗连。FETCHJOIN运转你指出联系关系的实体，Order能够指定只查询某个字段。
・查询语句能够前往一个以上的了局值。实践上，你能够前往一个依附的类好比上面如许：
SELECTnewCustomerDetails(c.id,c.status,o.count)
FROMCustomercJOINc.orderso
WHEREo.count>100
・撑持groupby和having。
・撑持where子句的嵌套子查询。
在提交的EJB3.0草案中，EJBQL与尺度SQL十分的靠近。实践上标准中乃至间接撑持当地的SQL(就像我们下面提到的那样)。这一点对某些程序员来讲大概有些不是很分明，我们将鄙人面举行更具体的解说。
多样性
办法允许(Methodpermissions)能够经由过程@MethodPermissions或@Unchecked正文来声明；一样的，事件属性也能够经由过程@TransactionAttribute正文来声明。标准中仍旧保存资本援用和资本情况援用。这些一样能够经由过程正文来声明，可是有一些渺小的不同。好比，高低文(context)情况要经由过程注进工具把持。容器依据bean对内部情况援用主动初始化一个得当的已声明的实例变量。好比，你能够象上面如许取得一个数据源（DataSource）：
@Resource(name="myDataSource")//Typeisinferredfromvariable
publicDataSourcecustomerDB;
在下面的例子中假如你不指定援用资本的称号(name)那末个中的customerDB会被以为是默许值。当一切的援用属性都可失掉时，@Injec正文就能够如许写：
@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的一个翻版"EJB3.0=EJB2.1fordummies"（但愿这个等式不要建立）。最初，我仍是不由得要提一些我本人的概念：
・起首，标准的确使重复部署变得简单了，而且有一个复杂的形式来会见运转时情况。我仍是以为home接口应当保持。
・在初期的EJB标准中，实体bean用于映照一个耐久化存储。实际上(大概只是实际上)大概必要把实体bean映照到一个遗留的EIS(enterpriseinformationsystem)体系中。出于未来扩大的思索如许作是有优点的，而且可使更多的营业数据模子接纳实体bean。也因而其陪伴的庞大性使得实体bean不被看好。在本次提交的草案中，一个实体bean只是一个数据库的映照。而且是基于非笼统耐久化形式和复杂的数据会见形式的加倍复杂开辟。
・我对模子变动持保存立场，我以为在EJB中包括SQL剧本片段并非个好注重。一些开辟职员完整否决包括某些“SQL片断（SQLness）”（好比@Table和@Column正文）。我的概念是这些SQLness是好的，据此我们能够分明的晓得我们究竟要数据库作些甚么。可是某些SQL段我看来并非很好，好比columnDefinition="BLOBNOTNULL"，这使得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（JavaWeb服务元数据）
JSR175已开端完成而且不会和EJB3.0有太年夜的抵触；可是JSR181与EJB3.0有两个联系关系的中央：
・Webservice接口：EJB标准将接纳一种机制顺应JSR181以即可以把一个bean完成为一个Webservice并告知Webservice怎样被客户端挪用。
・JSR181企图接纳分歧的机制来处置平安成绩。在初期的标准中EJB倡议利用一个分歧的机制（MethodPermissions），可是JSR181企图利用一个略微分歧的体例（SecurityRoles和SecurityIdentity正文）。一样的RunAs正文的界说也存在这些许不同。这一成绩还在办理中终极会在J2EE层的标准中保持其分歧性。
在J2EE1.5中的一些开辟标准大概与EJB3.0有联系关系。除下面说到的几个联系关系以外如今没有其他的开辟标准与EJB3.0有抵触。
停止语
在使EJB的开辟变得复杂高效之前，我们另有很长一段路要走。标准构造在下降EJB的开辟难度方面起了个好头。O/R映照模子的发起还处在初期阶段，标准构造正在完美它。我但愿它不要太庞大也不要与SQL太过的耦合。让我们不要只是停止在希冀、但愿、思索和哀求中：提出你的设法并把你的倡议发送给标准构造ejb3-feedback@sun.com。JCP并非很平易近主的构造，可是你的倡议必定是有代价的。
而学习JAVA我觉得最应该避免的就是：只学习，不思考，只记忆，不实践！
作者:
爱飞
时间:
2015-1-18 22:57
不过，每次的执行编译后的字节码需要消耗一定的时间，这同时也在一定程度上降低了 Java 程序的运行效率。
作者:
小魔女
时间:
2015-1-20 07:48
一般学编程语言都是从C语开始学的，我也不例外，但还是可能不学过程语言而直接学面向对象语言的，你是刚接触语言，还是从C开始学比较好，基础会很深点，如果你直接学习JAVA也能上手，一般大家在学语言的时候都记一些语言的关键词，常有的包和接口等。再去做逻辑代码的编写，以后的学习过程都是从逻辑代码编写中提升的，所以这方面都是经验积累的。你要开始学习就从
作者:
透明
时间:
2015-1-24 06:10
Pet Store.（宠物店）是SUN公司为了演示其J2EE编程规范而推出的开放源码的程序，应该很具有权威性，想学J2EE和EJB的朋友不要 错过了。
作者:
因胸联盟
时间:
2015-1-31 21:25
学Java必读的两个开源程序就是Jive和Pet Store.。 Jive是国外一个非常著名的BBS程序，完全开放源码。论坛的设计采用了很多先进的技术，如Cache、用户认证、Filter、XML等，而且论坛完全屏蔽了对数据库的访问，可以很轻易的在不同数据库中移植。论坛还有方便的安装和管理程序，这是我们平时编程时容易忽略的一部份（中国程序员一般只注重编程的技术含量，却完全不考虑用户的感受，这就是我们与国外软件的差距所在）。
作者:
若相依
时间:
2015-2-6 16:59
Java是一种计算机编程语言，拥有跨平台、面向对java
作者:
金色的骷髅
时间:
2015-2-13 01:00
多重继承（以接口取代）等特性，增加了垃圾回收器功能用于回收不再被引用的对象所占据的内存空间，使得程序员不用再为内存管理而担忧。在 Java 1.5 版本中，Java 又引入了泛型编程（Generic Programming）、类型安全的枚举、不定长参数和自动装/拆箱等语言特性。
作者:
蒙在股里
时间:
2015-2-13 22:49
多重继承（以接口取代）等特性，增加了垃圾回收器功能用于回收不再被引用的对象所占据的内存空间，使得程序员不用再为内存管理而担忧。在 Java 1.5 版本中，Java 又引入了泛型编程（Generic Programming）、类型安全的枚举、不定长参数和自动装/拆箱等语言特性。
作者:
飘灵儿
时间:
2015-3-4 02:16
多重继承（以接口取代）等特性，增加了垃圾回收器功能用于回收不再被引用的对象所占据的内存空间，使得程序员不用再为内存管理而担忧。在 Java 1.5 版本中，Java 又引入了泛型编程（Generic Programming）、类型安全的枚举、不定长参数和自动装/拆箱等语言特性。
作者:
老尸
时间:
2015-3-7 03:41
是一种突破用户端机器环境和CPU
作者:
深爱那片海
时间:
2015-3-8 03:56
在全球云计算和移动互联网的产业环境下，Java更具备了显著优势和广阔前景。
作者:
不帅
时间:
2015-3-15 20:30
让你能够真正掌握接口或抽象类的应用，从而在原来的Java语言基础上跃进一步，更重要的是，设计模式反复向你强调一个宗旨：要让你的程序尽可能的可重用。
作者:
若天明
时间:
2015-3-22 04:08
是一种突破用户端机器环境和CPU
欢迎光临 仓酷云 (http://ckuyun.com/)
Powered by Discuz! X3.2