ejb3开发实践心得(排版重整版)

EJB3.0实践心得体会
缺点：开发和设计过程中，如果不注意的话，效率会很差；开发成本相对有点高，但比起EJB2已经好了很多了！
特点：分布式
适用环境：
对于大型的系统，如果想使用分布式来均衡和提高负载;
有各种各样的客户端类型:local端,remote端和其他异构的信息系统(这其中决定了客户端的访问方式，每种类型的客户端都有一种最佳的访问方式，这样能避免不必要的消耗，提高性能)
整合系统
所要注意的是：尽管它有很多优点，但有些小系统能用其他方案解决的，就没必要硬往上套!
本人设计和开发ejb3.0的心得体会：
 Ejb采用分布式来分担负载，所以在设计开发前，尽量把实施的环境考虑周到和清楚，尽量发挥分布式的最大功效
Ejb实则是牺牲单次的访问效率来提高整体的访问效率，上一个心得已经讲了怎样发挥分布式的最大效率；下面主要说下怎样控制单个访问效率，不能牺牲过大：
在说怎么控制单个访问效率之前：先来看看ejb的客户端的访问类型，访问方式和实现细节
   Remote客户端（该客户端不在运行ejb的进程内就是remote客户端），他的访问方式就是远程访问方式;实现细节如下(个人观点，本人不是专家，学者，仅仅一个开发者而已)：
⑴客户端先从ejb容器中lookup一个ejb实例，ejb容器为ejb实例生成两个代理对象：一个是服务器端代理，一个是客户端代理，ejb服务器将客户端代理返回给客户端，这样客户端就拥有了ejb对象的代理存根了，该存根实现了相应的业务接口，自然通过该存根调用服务器端的方法，完成相应的工作
在(1)步骤中，效率主要消耗在lookup和回传客户端代理中，每个应用肯定要往应用服务器查找命名服务，这点消耗是应该的，但不能在一个应用中频繁地去lookup;开发人员应该在客户端的一个应用中缓存这个代理类存根,当然这种实现的手段很多，设置一个变量保存，可以模仿spring，当然也可以结合正宗的spring就更加wonderful了；
（2）客户端准备好相应的参数，利用上面的代理存根，调用远在服务器的服务；这个过程的具体实现如下(再次说明这个只是我的个人观点，本人没有研究过相关项目的源代码<那是学者干的活，I am a developer>，只是觉得要实现上述过程的话，就得这样，如是而已，所以用于理解可以，学术不行)：客户端代理和服务器端代理两者肯定先要建立socket通信，然后把参数进行序列化（要想在网上传输，这是必须的），两者之间肯定会确定某种协议进行传输，服务端接到相应的调用后，就去调用ejb实例完成相应的工作，然后服务端代理把相应的结果按同样的方式返还给客户端，至此完成一次调用！
在(2)步骤中，效率主要消耗在3点：1，socket的建立与通信；2，参数的序列化；3，协议的解析；当然如果一个客户端的访问方式必须是远程的访问方式，这个消耗同样是必须的！问题是何谓访问方式必须是远程的访问方式！所以根据客户端类型选择合适的访问方式是解决该问题的一个方法；当然还有其他的方法：正如前面所说，远程的访问方式这样的消耗是必须的，但我们在设计的时候却可以使这种消耗出现的频率变少！我认为一个很重要的原则就是一个应用中尽量使这样的通信变少，能一次性的传递过去和返回回来是最好的结果，所以在进行设计时，应该是粗粒度设计理念，可以参照下门面模式的设计思想！
Local客户端（客户端和ejb实例在同一个进程内）,它的访问方式就是local访问方式，其实现细节如下：
Local客户端先lookup一个ejb实例，由于客户端和ejb实例在同一个进程中，数据间是可以共享的，所以就不用像remote访问方式那样了，直接在内存中交互，当然local客户端也可以用远程的访问方式访问ejb，但正如我前面所说，这种消耗是我们可以而且也应该避免的。
异构系统客户端(不同系统平台<windows,linuc等>，不同开发语言<c++，delphi,c#等>的客户端)，这种客户端的访问方式就是webservice的访问方式；这种访问方式同样要进行socket连接，虽然不用把参数进行序列化，但是它实则是用xml来描述各种信息，翻译和解析这些xml也是消耗性能的！异构的能用webservice的访问方式访问ejb，同构的当然也能，不过这就有点做作，傻b干的事情，效率暂且不说，还增加开发成本！
控制单次访问效率的问题上，还可以从ejb实例的类型来看看效率的问题（这其中要牵扯些应用服务器如何管理这些ejb实例的问题）。Ejb实例的类型从ejb规范中我们就可以看到，它包含有3种的ejb类型：1，session bean(这其中包含两种stateful session bean和stateless session bean);2,entity bean；3，Message Drivered bean.
说实话，在我看来，用户访问的只是session bean（间接来说，其实它也可以调用message drivered bean,不过它是通过消息间接来调用的，在后面，我会通过几张图来说明这个问题）；用户访问相应的session bean来完成相应的业务逻辑，如果需要操作其他的资源，包括数据库和其他的一些服务，可以通过注入的方式来使用这些服务，比如要操作某个数据库表可以使用@PersistenceContext注解注入进EntityManager，然后使用其中方法操作entity bean来达到操作数据库的目的，有关jpa的知识可以看相关的规范（应该有相应的规范吧，我以前学的时候这个规范可没弄过，如果您用的应用服务器是jboss并且对hibernate很熟悉<hibernate我虽然熟悉但很少用，个人对ibatis比较感兴趣>，就没有什么难度了）。好像有点偏题了，我所要讲的就是ejb应用服务器端的代理实际上代理的是session ejb实例，那么我们来猜想下，应用服务器是怎么来管理session ejb实例的：session ejb实例分为两种：stateless的和stateful的；应用服务器管理stateless采用的是类似于数据库连接池的技术，通过这种方式来提高负载，而管理stateful session bean 时必须为每个会话创建一个单独的实例，这样就会增加服务器的负担，所以效率和性能方面stateless的要比stateful的要好很多（当然应用服务器为了减轻这方面的负担，在管理 stateful session bean 时采用了一种网上大哥们都说的钝化激活技术，来减轻内存的消耗）。
鉴于对两种session bean 的了解，在设计时尽可能的采用stateless session bean，这话看起来有点像是废话，确实！最关键的我们怎么做到这一点了：下面我们来打个比方，有两套以上的系统要用到同一个业务方法，比如这些系统都要用到类似购物车的功能，大家肯定会想到，stateful session bean会是一个很好的选择，其实不然，ejb在整合各种系统时，我们要达到的目的是，整合业务方法所要达到的功能，而不是要把相应的负载（如果那个负载不是必须的）也整合进去，那样就会照成单个服务器的负载过重，我们可以把这种负载通过一种变相的方式，把这些负载均衡到各个子系统自有的服务器上，比如上面的购物车，我们可以缓存在web容器的session中，这样就能在ejb容器中通过stateless session bean 来代替stateful session bean ，同样能识别不同的会话（这里的会话跟上面说的ejb会话是不同的，希望能注意下）。
Message drivered bean 实则是基于jms的一个应用，在jms这个体系中，它实际上充当的是一个消费者，而且是个异步的消费者，所以性能挺好的，所以当某个方法需要一个业务时，但并不在意这个业务的返回时，可以把这个业务(例如邮件的发送，短信的发送什么的)设计成一个message drivered bean.
好了，关于效率的问题谈的有点烦了，觉得有用就行，没有的话，你可以把它当作废话看待，无所谓（本人最不喜欢看别人的脸色，一切随心就好，有相同性格的，大可以交个朋友，本人非常乐意）！再谈谈ejb项目管理的心得吧。
说到项目管理的心得，感觉有点扯淡，说成项目开发的心得也行，要说成管理也是自己管自己，不过一个人开发，管管也好!从几方面来谈把：
命名规则：ejb3.0的命名规则，我记得在什么地方看到过，忘了，不过大概意思还是有个谱：无非是local和remote接口都建立出来，ejb class命名时已Bean结尾这些，我感觉这些有点扯淡之嫌，但建议还是好的，我们也就照着做吧。下面我来说说我的源代码组织习惯（包的命名规则实际上就是为了组织源代码）和ejb name的命名习惯（大家可以看看这段话： The name annotation element defaults to the unqualified name of the bean class. The name—whether explicitly specified or defaulted—must be unique within the ejb-jar；这段话是ejb3.0规范里介绍好几种annotation 的name属性的一段话，大概意思是这样的，这个annotation名字默认是非限定的bean class的名字，这个名字无论是自己定义的，还是默认的，都必须在ejb-jar中是唯一的，足见ejb name的命名也是很重要的）：
引文发现长了点（其实规则几句话就能完事了）：1，我们可以把接口，实现类，公共类和测试类建立在不同的源代码文件夹下，各个源文件夹下的包名和平常一样，相互对应起来，比如接口所在的包名是com.oyang.ejb,那么实现类所在的包名是com.oyang.ejb.impl;建立在不同的文件夹下，方便查看和利用ant进行打包发布，至于包名怎么设定，可以按照大家的习惯，我的习惯是按项目，如果有子项目，再加上子项目，在加上所属层，到底是action, valuebean,还是common,再加上功能模块！当然比较大型的项目是这样，方便团队，各个项目，各个功能模块同时开发！小的项目按实际情况定吧！
2．Ejb name的命名规范：我的习惯是项目名缩写+功能模块缩写+Bean class name,之间的间隔按驼峰命名法的习惯（有一点要考虑的是你的包的命名规范）！
3，在开发时，整个版本控制器（svn,vss都行），这个我认为是必须的，个人目前用着svn,公司用着vss!

好了，先告一段落！有时间有心情再玩玩了！目前还有个小小的遗憾，还没有想到一个很好的方案在jboss上开发ejb引入ibatis（个人比较喜欢，所以心中有点疙得慌，但jboss的jpa是通过hibernate实现的，估计难<有点不大可能>，只是随口提下）！
差点忘了，还有几个图片没有附上去：
1，Ejb进行系统整合图：
 

2，ejb在传统web开发中的位置：