111111
精灵王
精灵王
  • 注册日期2010-12-08
  • 发帖数640
  • QQ
  • 火币1103枚
  • 粉丝120
  • 关注75
  • 社区明星
阅读:3475回复:0

使用EJB3.O简化EJB研发(二)-JSP教程,J2EE/EJB/服务器

楼主#
更多 发布于:2011-01-08 21:03
简化研发者的观点 如果你使用现有版本的ejb你会懂得研发一个如helloworld的简单的ejb程式是多么困难。你至少需要两个接口,一个bean类和一个部署描述文件。大多数的研发者希望知道为什么我需要所有这些。ides(研发环境工具)象oracle的jdeveloper, eclipse和xdoclet简化了研发者的做这些普通的工作研发周期,可是在ejb在你部署到所选择的容器中之前,编译类和打包部署文件依然是研发人员的工作。 ejb3.0试图从以下方面简化复杂性: ?         不必定义接口和部署的描述文件,这些能由容器使用metadata annotations生成。 ?         使用常用的java类作为ejb的类和常用的ejb业务接口。 元数据描述(metadata annotations) ejb3.0非常倚重metadata annotations。metadata annotations已成为jsr 175标准并且将是j2se 5.0的一部分。annotations是一种对象变成的属性,非常类似和xdoclet。可是不像xdoclet那样需要预先编译,annotations由java编译器在需要编译的时候编译。(依赖于@retention的开始时间)。在研发人员的观点,annotations就如同一个公有的并能作为类,域,方法,参数,本地变量,构造,枚举和包相同使用的修改量。你能在你的java代码中附带特别的属性使用annotations来生成代码,自动编写文件代码,或提供如在运行期间增强业务层安全或特别业务逻辑的特别服务。j2ee1.5(5.0)的目标是简化研发人员使用annotations因此而可能产生一套的annotations模板。annotations使用@来标记,如下:  @author("debu panda")  @bean  public class mysessionbean ejb3.0为了简化研发因此使用metadata annotations来产生许多如接口相同的人为因素和使用annotations来替代部署描述文件。 使用 pojos 和 pojis 在规范条件中,javabeans和接口经常分别的涉及到简单java对象(pojos)和简单java接口(pojis)。这些不必要的如home接口的人为因素已被去掉。 研发人员必须在javax.ejb包中实现一个ejb接口(会话bean,实体bean或消息驱动bean)或选择在bean的实现类中使用annotation。你能使用无状态,状态,消息驱动或实体去注释一个bean类。例如,如果你定义一个无状态ejb作为helloworld,你能如下定义ejb: @remote  @stateless public class helloworldbean { public string sayhello(string s)  { system.out.println("hello: "+s; }  } ejb的接口无论远程的还是本地的都不必再实现ejbobject和ejblocalobject。你要么为ejb提供业务接口并且实现bean类中的接口,要么需要在部署的时候生成这些接口。虽然会话bean和消息驱动bean的接口是必须的,不过实体bean的接口是可选的。如果你没有为你的会话bean实现一个接口,那么他会自动为你生成一个。所生成的接口是本地的还是远程的取决于你在bean类中的annotations。如果你仔细看看上面的代码范例,@remote非常明显是用来为你的helloworld生成一个远程接口。如果需要,你能在你的ejb中同时生成远程和本地接口。 在上面的例子中,非常明显研发人员不必再做那些如定义接口和实现回滚方法等这些普通的工作。 生成接口的名字来源于bean实现类的名字。生成接口对研发人员来说非常有用。不过我并没有看到所有如oracle 的jdeveloper的这些ide即时实现这种生成接口功能。 规范中没有明确ejb查找时客户端的需求是什么,也没有明确我们怎么保持这些ejb需要调用的接口。基于以下几个情况下的原因我将不推荐使用生成接口: ?         生成接口的名字来源于bean的名字 ?         如果你不愿意在ejb中暴露出一些方法而生成接口将默认暴露出所有的方法。 ?         你需要在客户端使用接口来调用ejb. 去掉回滚方法的需求。 ejb2.1和更早版本需要实现非常多即使对于每个ejb你不必的一些生命周期的方法,如ejbpassivate, ejbactivate, ejbload, ejbstore等等。例如,在无状态会话bean中不必ejbpassivate不过你还是得实现他的方法。目前ejb3.0中类似的常用java类实现这些生命周期的方法都变成为可选择的。如果你在ejb中实现所有回滚容器都会调用这些方法。 唯一的异常是在你能使用remove的annotations时一个状态会话bean的业务方法的ejbremove方法是状态会话bean。如果你使用这个annotations他将在完成annotations方法后(无论正常或非正常)提示容器移除状态会话bean实例。例如,你能指定以下的方式去在checkout方法执行后移除一个状态会话bean实例。 @stateful public class cart { ... ... @remove public void checkout() { ... } } annotations和部署描述的比较 在前面我们讨论到ejb中不再需要部署描述而由annotations代替。每个部署描述的属性都将被选择一个默认值,而研发人员在直到他们想改动这些属性的默认值之前不必为这些属性指定值。这些也能用来为bean的类自身指定使用的annotations。ejb3.0规范为研发人员使用bean类型,接口类型,资源引用,事务属性,安全等等定义了一组metadata annotations。例如,如果我们能如下为一个特别的ejb定义使用资源引用: @resource(name="jdbc/oracleds", resourcetype="javax.sql.datasource") j2ee的提供商如oracle, bea, ibm将增加属性annotations在他们指定的部署描述中,研发人员将能使用这些annotations去避免使用部署描述。这看起来对研发人员十分具有吸引力,特别对xml描述是已感到厌恶的研发人员,他们早就恨透并想脱离老的那种描述方式,但依然有一些问题使得我们在正式使用annotations时需要谨慎对待。
  • 他违背了我们轻便应用程式的目标,因为如果一个ejb如果使用一个提供商指定的部署描述,在重新编译或打包ejb的时候他必须多次改动。
  • 部署描述对ejb模板提供了全局观点使得组装和部署的时候不必考虑独立的ejb,他们将每个部署需求拧在一起,并且在部署完成之前描述是无效或不可自动生成的。这对部署员来说是个可怕的事情。
  • 部署描述在ejb模板中被相关工具用来定义ejbs,当你试图整合一个和另一个容器的时候非常有用。ejb3.0规格同样主张在部署描述中使用重载annotations的方式。可是在规范里并没有提到重载annotations的细节。

无疑摆脱部署描述将使得新的研发者研发更加容易,不过如果使用不当这也将造成管理上的可怕问题。
更多黑客技术 黑客软件 计算机技术 编程技术 网站技术 qq技术 IT新闻 黑客基地 请访问 灯火安全联盟  灯火黑客 www.hack8888.com/bbs

喜欢0 评分0
游客

返回顶部