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);
![](https://www.cnblogs.com/Images/dot.gif)
为什么不能简单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.
高效的异常处理框架。。。