在EJB开发过程中，根据JNDI找到Home接口再生成远程接口对象是一个耗费资源的事。因为在很多遗留的EJB系统中有很多Cache的方案。一部分是Cache Home接口，一部分Cache 远程接口对象。怎么理解这两种方案的区别呢？ 答案是SFSB时Cache Home; SLSB时Cache 远程接口对象。因为SFSB只能跟Client的一次Session关联，多个Client不能重用（也即一次性的）。相反SLSB可以从Pool中直接重用。 此方案一般用在ServiceLocator中，ServiceLocator用来隔离web层和业务层，避免web层直接接触Ejb home等接口。 经典方案是在web层中多出一层Business Interface+ Business Delegate，Business Delegate实现类中通过ServiceLocator找到远程对象。
今天在看EJB的相关知识时回忆起以前SLSB中业务接口的设计。 声明一个业务接口继承自java.rmi.Remote接口（BTW,这是一个Marker interface). 该接口中声明所有业务需要的远程方法。EJB实现类实现这个业务接口即可，不需要直接实现java.rmi.Remote 该方案目的有二： 抽象出一个公共的业务接口并强迫EJB实现（编译时检查） 解耦EJB中多余的接口声明。当然注意的是业务接口中的方法还是需要抛出java.rmi.RemoteException的，要不EJB实现类没法实现.(参考实现时接口变窄的思想）
异常是方法执行完后才抛出的，跟返回结果相似，从这个角度来说不应该是方法签名的一部分。我们知道，如果根据不同的返回类型来区别签名从而达到重载的目的是不允许的，因为方法在没有返回前系统是不知道该选择哪个方法来执行的。Java中也不允许仅仅异常声明不一样的方法进行重载。 异常在接口实现，方法继承中只能变的越来越少（变窄）。也即父类异常声明必须包括(或者说是子类异常的父类）子类异常声明。这个可以这么理解，因为我们都是面向接口或者超类编程，客户端代码一定捕获的是接口或者超类中声明的异常。这样不管具体实现类中抛出什么样的异常，对客户端代码中的try，catch结构不会有任何影响。相反如果具体类中抛出一个接口中没有的异常，客户端的代码（catch语句）就要必须做出改变，这也就破坏了我们面向接口编程的初衷了。而Core Java中异常的处理正是按照继承或接口实现时异常变窄来实现的。 针对实现接口时方法声明中异常变窄的性质。RMI和EJB中有一个设计的模式可以参考。 我们知道，RMI中需要声明一个远程接口，每个暴露出来的方法需要抛出java.rmi.RemoteException,远程接口需要继承java.rmi.Remote接口。对于客户端调用来说对于这么RemoteException基本上是无能为力的，相反写起代码起来比较麻烦。 一种思路是对应远程接口声明一个业务接口，该业务接口中不包括Remote,RemoteException声明。服务端RMI实现时一个改变是需要同时实现远程接口和业务接口。对于客户端来说跟以前一样，只是根据Naming找到对象以后转化为业务接口操作即可。当然如果需要处理RemoteException的话那么把取出来的对象转化为远程接口接口即可。
针对session EJB的应用，原因有二： Remote Session EJB的分布式功能（包括分布式事务传播） 即使只用Home EJB，也可以利用它的声明式事务功能
javascript中== 和 ===都表示逻辑等，不同的是: ==在做逻辑等时，先进行类型转换。 ===则不会。 如下例： <script language="javascript"> var valueA = "1"; var valueB = 1; if ( valueA == valueB) { alert("Equal"); } else { alert("Not equal") } //output: "Equal" if ( valueA === valueB) { alert("Equal"); } else { alert("Not equal") } //output: "Not equal" </script>
As simple as possible and no simpler -Einstein Life is like a snowball. The important thing is finding wet snow and a really long hill. -Warren Buffett Work expands so as to fill the time available for its completion -Parkinson's Law
The process areas of Human Resource Management are: Develop Human Resource Plan; Acquire Project Team, Develop Project Team and Manage Project Team. Develop Human Resource Plan Roles & Responsibilities matrix(Responsible, Accountable, Supports, Informed, Consulted), Organization Chart, Staffing Management Plan Acquire Team Four kinds of "Relationship Styles": Socializer, Relater, Thinker, Director Develop Team Situational Leadship Styles: Telling, Selling, Participative, Delegating Manage Team Virtual Teams The Death Spiral Globe Cultural Expectations
checked 和 unchecked exception 的区别，资深一点的Java程序员都知道。这里我感兴趣的是该怎么用checked 和 unchecked exception. 最早的exception处理机制来自C++，在C中为了避免错误，我们会根据返回结果或者判断状态（文件操作）来保证程序的正确性。这样在代码中就会有大量的if/else判断最后甚至让读代码的人忘了程序片段的真正意图。因此C++中引入了exception的处理机制。不过C++为了兼容C,异常处理是选择性的。 Java是真正严格实现异常机制的语言。 从架构的角度什么时候用checked exception，什么时候用unchecked exception, 如何封装，处理，仁者见仁，智者见智。 有种选择是不用checked exception. Think In Java作者Bruce Eckel在Does Java need Checked Exceptions 提到这种设计选择。我的理解是原因有三点： 业务逻辑不愿意恢复的错误，比如Rod Johnson在J2EE Deveopment Without EJB中举了一个Service Locator 中JNDI Lookup failure时直接抛出Un-Checked exception。这样不会逼着系统处理这种异常，比如尝试恢复或者提示用户。 checked exception是编译时异常，强制要求处理，确实降低了程序出错的可能。但有时程序中还是大量充斥这种异常处理的代码。 程序员经常有意无意中丢掉了异常（简单的打印出异常信息，没有思考如何进一步处理），这是程序中引入bug的一种主要来源，并且比较难找。 据说Spring中DAO的封装中都是Runtime Exception. 不知是不是也是基于此考虑。