原文来自www.onjava.com
http://www.onjava.com/pub/a/onjava/2003/06/11/j2ee_deployment.html?page=1
接上一篇
通常认为remote calls比local calls需要花费更多的时间，在远程过程呼叫中，本地代理对象必须copy所有的参数并且把他们通过电缆传送过来，通过RMI，在远程控制对象时，会造成网络交通堵塞和长时间的响应等待
考虑到用户在web page上发出一个命令的细节，而这特殊的请求轮流的调用servlet，随后就是处理在session beans和entity beans中的business method。至少4个网络操作都有同时的运行，其中的2个操作都是remote EJB calls。
图
当session beanscall 别的 session beans或者多个entity beans时，就需要创建额外的remote calls。如果执行的效果时首先要考虑到的，就需要在构架和设计时作出调整。来减少remote calss 的数量，而且要减少remote calls产生的消耗。
这里我们有许多方法来解决perforamce的问题
我们可以通过使用EJB的coarse-grained设计模式来减少网络上的trips
我们可以通过使用本地而不是远程接口或者是实体beans来消除一些不必要的远程呼叫
我们可以通过改变打包结构来使更多的beans部署在一个EAR文件里从而使一些远程呼叫变成本地呼叫
2.1.2 本地接口 VS 远程接口
J2EE1.3中引入本地enterprise beans的概念，它可以允许一个entity beans显示本地接口，这样可以允许以引用reference来传递参数而不是传值value。然而为了使session beans能够访问本地enterprise beans必须将本地enterprise beans打包到和session bean一样相同的EAR文件里。通常有2种方法来实现。
a.在数据层中可以在entiy beans之前创建一个session Facade，这样可以同样可以使entity beans在内部application中起到同样的作用，然而，如果仅仅依赖这种session Facade技术的话，程序运行的效果可嫩并不是很好。
b.把entity beans放到business层中，并且允许business层的session beans可以直接连接本地enterprise beans。这样可以减少entity beans重复使用的程度。
自从本地的entity beans只能在位于相同的EAR文件里起作用，在application外部的模块中的其他的business beans就无法来与entity beans连接。而且这将加倍在不同applicatipn 模块中的相同entity beans的实例（instances）
2.1.3打包结构
一些J2EE application server例如BEA的weblogic会优化beasns之间的远程呼叫和本地呼叫.如果beans都在相同的enterprise application中,这很有利于一个session beans呼叫多个session beans或者entity beans.但是这样也有一些不利之处:
降低可维护性:所有的打包在同一个EAR的beans必须在同一时间被部署或者是重新部署,这样会阻止在运行时间改变beans的可能性.
平台依赖性: 不是所有的app server都提供这种方式的优化,而且如果你转变app server vendors的话是没有任何作用的.
可能破坏到设计思路: 许多开发人员设计beans都假设所有的参数通过传值而不是传递引用.如果改变呼叫的约定将会破坏以前的假设,特别是如果传递对象的模式被同时用在entity beans中
2.2 资源定位的考虑:另一个区域我们必须考虑通用资源和库的位置,一条戒律是资源一定要随着用到的J2EE模块在一起.然而,如果在某种情况下比如一些同用资源被几个模块同时用到时,你可以把他放到一个这些模块都可以获取到这些资源的地方.除此之外,把资源路径放入你的系统的CLASSPATH里将会引起与其他J2EE模块部署到相同的容器的冲突.这样会同样的限制你来部署J2EE应用程序
