1. 为什么要Narrow
我们都知道在调用EJB的时候需要Narrow，比如
为什么不能简单Cast，是有原因di，J2EE规范规定J2EE的AS必须实现以IIOP为底层传输协议的远程对象传输机制（但是不限制使用自己的传输协议，例如t3等），所以如果是标准的IIOP实现，对象的类型在远程传输过程当中已经不是Java类型，而是OMG的Object类型，所以需要调用narrow方法在客户端重新构建这样的一个桩，如果是t3协议，则返回的对象已经是重建好了的实现了Java类型的桩，这个时候的narrow就会对改对象不加修改，直接返回。采用IIOP可以使CORBA用户很容易直接调用EJB方法，但是IIOP传输的是二进制的数据，必须有防火墙支持。Java 从1.2引入对CORBA的支持，1.3增强了对RMI-IIOP（用IIOP作为底层传输协议的RMI实现）的支持。
2.
有时候web service并不是那么的有用，比如速度、效率、JDK版本限制等等，所以对于Java 2 Java的远程调用的方式基本上就只能考虑需要防火墙支持的IIOP（RMI实现存在严重的开发商不兼容，尤其是桩类的大小问题也会成为影响性能的主要原因），对于更老的版本的JDK，可能连IIOP都不支持，如果写applet，对带宽的要求就更高了（我们的系统简直就是一个大杂烩^_^），这个时候可以采用一个Servlet桥的方式来解决这个需求（Servlet本身的多线程模式可以省掉我们很多功夫，本来想Socket的，不过Scoket的代价比较高，Socket的Server端和Client端的JDK版本要求应该基本一致：这句需要考证），客户端去invoke servlet，servlet桥把方法调用委托给Stateless SessionBean, 这个是我迄今为止研究出来的最简单直接的办法，不知道其他产品里面还有没有更好的解决办法
3.
考虑问题ing：
现有环境下，如果实现“对系统的主动监控”以及“核心业务逻辑的不间断运行”？貌似里面相关方比较多。
4.
如何实现对Bea的有效监控？回头查查它的Management Bean再回来补充。
5.
高效的异常处理框架。。。
我们都知道在调用EJB的时候需要Narrow，比如
1 MyHome Home = (MyHome )PortableRemoteObject.narrow (context.lookup(
), MyHome.class);
), MyHome.class);为什么不能简单Cast，是有原因di，J2EE规范规定J2EE的AS必须实现以IIOP为底层传输协议的远程对象传输机制（但是不限制使用自己的传输协议，例如t3等），所以如果是标准的IIOP实现，对象的类型在远程传输过程当中已经不是Java类型，而是OMG的Object类型，所以需要调用narrow方法在客户端重新构建这样的一个桩，如果是t3协议，则返回的对象已经是重建好了的实现了Java类型的桩，这个时候的narrow就会对改对象不加修改，直接返回。采用IIOP可以使CORBA用户很容易直接调用EJB方法，但是IIOP传输的是二进制的数据，必须有防火墙支持。Java 从1.2引入对CORBA的支持，1.3增强了对RMI-IIOP（用IIOP作为底层传输协议的RMI实现）的支持。
2.
有时候web service并不是那么的有用，比如速度、效率、JDK版本限制等等，所以对于Java 2 Java的远程调用的方式基本上就只能考虑需要防火墙支持的IIOP（RMI实现存在严重的开发商不兼容，尤其是桩类的大小问题也会成为影响性能的主要原因），对于更老的版本的JDK，可能连IIOP都不支持，如果写applet，对带宽的要求就更高了（我们的系统简直就是一个大杂烩^_^），这个时候可以采用一个Servlet桥的方式来解决这个需求（Servlet本身的多线程模式可以省掉我们很多功夫，本来想Socket的，不过Scoket的代价比较高，Socket的Server端和Client端的JDK版本要求应该基本一致：这句需要考证），客户端去invoke servlet，servlet桥把方法调用委托给Stateless SessionBean, 这个是我迄今为止研究出来的最简单直接的办法，不知道其他产品里面还有没有更好的解决办法
3.
考虑问题ing：
现有环境下，如果实现“对系统的主动监控”以及“核心业务逻辑的不间断运行”？貌似里面相关方比较多。
4.
如何实现对Bea的有效监控？回头查查它的Management Bean再回来补充。
5.
高效的异常处理框架。。。
