还有HttpSession和EJB session如何对应、常用的编程模式是怎样的，不是很明白，可能关键还在于上面的问题没理清。
Session Bean顾名思意 就是会话bean。 既然是会话那它一定有一种状态(State)。所以它有 Stateful Session Bean，Stateless Session Bean)
对于Enterprise Bean的调用，是通过生成EJBObject来实现的。客户端是不直接访问的。 所以要通过服务器端建立一个Remote接口与client联系，实例子化EJBObject.当然是要调用Home接口的。
对于session的理解可以是和HttpSession一样的。
只是客户端，先通过jndi获取到对Home对象,并创建
就是那段Object ref = ctx.lookup("xxxx");
然后 ejbCreate()；
调用自己的方法，
调用enterprise bean 。
然后ejbRemove()
这些好多入门级的代码都这样写。
一个sessionbean创建了，一般都是调用他的。。这个好象没有默认的消失时间。就算有可能和jvm的GC有关，我对这个不太清楚
session bean 常用的模式是session Facade模式。
http://www.think.idv.tw/THINK/j2ee/EJBLifeCycle.scr
可能需要注册
俺虽然算不上个牛人，但算半个的话至少还是问心无愧的，先前提出的问题只是个引子，后面其实还有很多相关的问题的，既然这样，偶也就没兴趣再贴了
b4
stateless bean :
因为无状态，服务器根据应用需要NEW BEAN 和删除 BEAN.
stateful bean:
服务器根据IDLE 时间将bean passactive ,这时，这个bean就可以被重新设置值服务其他session,也就是说在一个会话过程中 ，真正服务的stateful bean 可以不是同一个。
恩，见过好多牛牛都是从最简单问题展开讨论的。。
希望你继续贴啊。
session.setAttribute("ejbRef",ejbObjRef）；
一旦释放:
session.setAttribute("ejbRef",null）；
则ejb容器按照规定的步骤在一段时间后把该stateful session bean自动退化收集了。
当然，如果你保持了引用，但是很长时间没有调用该stateful session bean，ejb容器也会按照策略进行序列化到硬盘的操作，等下次你调用后再行读出，但是不会收集。
SFSB为什么有人认为难用，不喜欢，就是因为要做清除，否则会严重影响性能。不象SLSB，用完就不管了，其实SLSB用完也应该注意释放一些资源，这是EJB使用中最应该注意的，也是陷阱之一吧！
1、状态管理
SFSB带状态，我必须小心进行状态管理
2、性能问题
SFSB是调用的时候才创建，不像SLSB能够预创建之后缓存在池中，速度很慢。
比如weblogic server 6+
在weblogic的实现中，remove方法里是空的，它什么也不作。
weblogic的SLSB的调用是方法级的，就是你连续调用一个
SLSB的两个方法，可能用到服务器端不同的SLSB的实例（所以最好不要在SLSB方法中使用实例变量）
我觉得随着App Server、J2EE框架的发展和成熟，这些严重影响性能的问题，应用服务器会开发商自己会慢慢解决
那只是远端EJBObject接口的一个方法申明,weblogic必定有自己的一套实施方法来继承并实现的。
slsb的定义本身就是和状态无关的，也就是说服务器会按policy自动调用pool中的某个bean为客户端服务的，客户端是透明的，无法知道此情况。
虽然ejb端的处理是重量级的操作，但是在应用服务器开发商无法更新其内部实现的情况下，通过调整参数等性能调优还是能优化整体性能的。
impl类的remove方法。