那位大虾给小弟细细讲一下JNDI

bigbat 2003-08-19 09:04:10
那位大虾给小弟细细讲一下JNDI
InitialContext ic = new InitialContext();
Object objRef = ic.lookup("java:comp/env/ejb/TheConverter");
ConverterHome home = (ConverterHome)PortableRemoteObject.narrow(objRef, ConverterHome.class);
converter = home.create();
这些的意思
...全文
28 4 打赏 收藏 转发到动态 举报
写回复
用AI写文章
4 条回复
切换为时间正序
请发表友善的回复…
发表回复
stonewang 2003-08-19
  • 打赏
  • 举报
回复
请参考:
1、http://java.sun.com/products/jndi/serviceproviders.html
2、http://www-3.ibm.com/software/webservers/appserv/doc/v40/aes/infocenter-zh/infocenter/wass_content/040602.html
Sundery 2003-08-19
  • 打赏
  • 举报
回复
InitialContext ic = new InitialContext();
//初始化环境参数

Object objRef = ic.lookup("java:comp/env/ejb/TheConverter");
//在JNDI中找到相应的JNDI名字

ConverterHome home = (ConverterHome)PortableRemoteObject.narrow(objRef, onverterHome.class);
//通过narrow方法找到Home端口

converter = home.create();
//对已经建立的home端口生成对象
//这一举好像应该这样写:Converter converter = home.create();
chyihill 2003-08-19
  • 打赏
  • 举报
回复
JNDI就是java naming and directory interface,就是把一个对象指定一个名字,然后通过这个名字拿这个对象,而且需要在配置的时候指定对象的名字就可以了。在client端,你根本不需要知道你要的对象在什么地方,它的目的就是为了透明。
jouny0 2003-08-19
  • 打赏
  • 举报
回复
J2EE应用服务器在他们的JNDI(java命名和目录接口)实现周围实现了群集.虽然JNDI是J2EE应用依赖的核心服务,但是它很难在集群里实现,因为它不能把多个对象绑定在单个名字上.关于每个应用服务器的JNDI实现有三个普遍的群集方法.

·独立的

·中央集中的

·全局共享的

独立JNDI树

HP Bluestone Total-e-Server 和SilverStream Application Server利用了一个适合于每个应用服务器的独立JNDI树.在一个独立JNDI树的集群里成员服务器不知道或不关心集群里其他服务的存在.因此,不支持失败转移或者通过重定向HTTP或EJB请求的媒介服务提供支持.配置媒介服务,使他们知道集群里每个组件都驻留在哪里和万一失败发生如何得到一个替代的组件.

独立JNDI树的集群它的一个优点:更短的集群收敛时间和灵活的伸缩.集群收敛衡量了集群完全知道集群里所有的机器和相关对象的时间.然而, 在一个独立JNDI树的集群里收敛(Convergence)并不是一个要关心的问题,因为集群在两台机器一启动就完成了收敛(Convergence).独立的JNDI树的其他优点:伸缩仅仅需要需要增加额外的服务器.

然而,也存在几个弱点.首先,失败转移通常是开发者的责任. 也就是说,因为每个应用服务器的JNDI树都是独立的,所以通过JNDI重新找到的远程代理被固定到已出现的lookup服务器上.在这种情况下,如果调用EJB的一个方法失败了,开发者必须写额外的代码连接到分发器来获得另外一个活动服务器的地址,做另外一次JNDI查找,再一次调用已失败的方法. Bluestone实现了一个更复杂的独立JNDI树的形式,就是每个请求都经过EJB代理服务或者代理LBB (Load Balance Broker).EJB代理服务保证每个EJB请求都进入一个活动的UBS实例.这种方案对每个请求都添加了额外的反应时间,但是在方法调用之间允许自动的失败转移.

中央集中JNDI树

Sybase企业应用服务器实现了一个中央集中JNDI树的集群.根据这种设置,中央集中的JNDI树利用了CORBA的CosNaming服务.命名服务器收容了集群的中央集中的JDNI树,清楚哪个服务器出事了.刚一启动,集群里的每个服务器就绑定它的对象到它的JNDI树和所有的命名服务器.

在一个中央集中JNDI树的集群里获得一个EJB的引用需要两个步骤.首先,客户端从命名服务器查找一个home对象,返回一个互操作对象引用(IOR).一个IOR指向集群里活动的具有home对象的几台机器.第二,客户端挑选出定位在IOR里的第一个服务器,得到home和remote.如果在EJB方法调用之间出现失败,CORBA stub实现了重新获得另外一个home或者remote的逻辑.这个home或者remote来自从命名服务器返回的IOR里列出的一个替代服务器.

命名服务器本身就证实了中央集中JNDI树集群的一个弱点.如果你有特定的50台机器的集群,之中有5台是命名服务器,如果5台命名服务器都down掉了,那么这个集群就变的没什么用了.当然,另外45台机器能运行,但是当命名服务器down了,这个集群将不能为一个EJB客户端服务.

如果集群原先的命名服务器全部发生了失败, 在线引进一个额外的命名服务器就会出现另一个问题. 假如这样做的话,一个新的中央集中命名服务器就需要集群里每个活动机器绑定它的对象到新的命名服务器的JNDI树.虽然当绑定过程发生时开始收到请求是可能的,但不推荐这样做,因为绑定过程延长了集群的恢复时间.此外,来自一个application或者applet的JNDI lookup,事实上出现了两次网络调用.第一个调用从命名服务器重新获得一个对象的IOR,第二的调用从IOR里指定的一个服务器那重新获得客户端想要的对象.

最后,当集群数量增长时中央集中JNDI树的集群承担收敛(Convergence)所带来的增加时间.就是说当你伸缩你的集群时,你必须增加更多的命名服务器. 紧记命名服务器所在的机器和全部的集群机器通常公认的比率是1:10,两个命名服务器是最小数目.因此,如果你有一个10台机器的集群和两台命名服务器,在服务器和命名服务器之间绑定的总数能达到20,在一个40台机器的集群和四台命名服务器里,会有160个绑定关系.每个绑定都表示其中一个成员服务器绑定所有的对象到一个命名服务器的JNDI树的过程.记住,中央集中JDNI树的集群在所有的JNDI集群实现之间具有更糟糕的收敛时间(Convergence time).

全局共享JNDI树

最后,BEA Weblogic实现了一个全局共享的JNDI树.用这种方式,当集群里的一个服务器启动时,通过IP广播宣布它的存在并且把JNDI树通知给集群里的其它服务器.群集里的每个机器既绑定它的对象到全局共享JNDI树,又绑定到它自己的本地JNDI树.

在每个成员服务器里都拥有一个全局的和本地的JNDI树,允许生成的home和remote stubs失败转移,并且提供很快的进程里的JNDI lookups. 全局共享JNDI树在集群里的所有机器之间都是共享的,允许任何成员机器知道集群里所有对象的精确位置.如果在集群里的多个机器上对象是可用的,一个特殊的home对象被绑定到全局共享JNDI树.这个特殊的home知道所有EJB对象和与它相关联对象的位置, 也生成知道所有EJB对象和与它相关联对象的位置的remote对象.

全局共享方式的主要不利方面:当服务器启动时所产生的大量网络初始化传输和集群的过分收敛时间(Convergence time).相反,在一个独立JNDI树的集群里, 由于没有JNDI共享信息出现,所以收敛并不被看做是个问题.然而,对集群里所有机器来说, 一个全局共享或者中央集中的集群,建立全局共享或者中央集中JNDI树都需要花费时间. 实际上,因为全局共享集群使用广播传输JNDI信息,建立全局共享JNDI树所需的时间与以后增加的服务器数相比是线性相关的.

全局共享与中央集中JNDI树的集群相比主要的好处集中在自由伸缩和高可用性.使用全局共享,你就不必在专门的命名服务器上乱动CPU和RAM,不必在集群里调整命名服务器的数目.当然,为了伸缩应用程序,仅仅增加更多的机器就可以.此外,如果集群里的一些机器down掉了,集群将完全继续起作用.最后,和在中央集中JNDI树的集群里每个remote lookup都需要两个网络调用相比, 每个remote lookup都只需要一个单一的网络调用.

所有这些都应该打个折扣,不可全信.因为运行在应用服务器上的JSPs,servlets,EJBs,和JavaBeans可以共处在EJB服务器里.他们总是使用一个进程里的JNDI lookup.紧记,如果你只运行服务器端(server-side)应用,那么在独立的,中央集中的,或者全局共享的集群实现几乎没有什么差别. 实际上,每个HTTP请求在应用服务器上都将结束,因为应用服务器将使用进程里的JNDI lookup返回你server-side服务器里使用的一些对象.

67,512

社区成员

发帖
与我相关
我的任务
社区描述
J2EE只是Java企业应用。我们需要一个跨J2SE/WEB/EJB的微容器,保护我们的业务核心组件(中间件),以延续它的生命力,而不是依赖J2SE/J2EE版本。
社区管理员
  • Java EE
加入社区
  • 近7日
  • 近30日
  • 至今
社区公告
暂无公告

试试用AI创作助手写篇文章吧