我们考虑存在一个EJBClient,几个EJB 克隆和一个管理服务器的情况。

在管理服务器中保存着可用的克隆节点的列表,同时这个列表用一个epoch数字来 标记。管理服务器是克隆节点的父进程，当其管理的克隆中有一个当掉时，在管理服务器里会标明。同时 管理服务器会周期性的pings其管理的每个clone节点，如果在一定的时间内克隆节点没有响应（可以自己配置） 那么管理服务器会认为该节点已经当机。每次当节点生效或者是失效时，管理服务器都会更新它的克隆列表 同时为这个列表生成一个新的epoch数值。这个列表会被发送到每个克隆接点以及其他的远端管理服务器上。

当EJBClient为所需要的EJB做JNDI查找时，管理服务器将返回这个EJB的home接口。home接口中包括可用的EJB 克隆的列表以及列表的epoch数值。当客户端调用ejbcreate, a finder method等方法时,ORB将从 列表中选择其中的一个EJB克隆，同时将请求信息和列表的epoch数值一块传送到选择的克隆上。

如果一个克隆失效了，那么下一个ejbcreate, finder, 等的请求将可能出现下面两种情况之一:

• 请求将路由到某一个可用的克隆接点。这个克隆节点上会有从管理服务器那里获得的新的克隆列表，同时会检测到从EJB客户端请求所带过来的 epoch 数值与当前正在使用的数值不匹配。这种情况下，克隆节点将接受处理这个请求，同时将从管理服务器那里获得的新的克隆列表以及其epoch值传送到 EJBClient‘s ORB上。
  
  
• 请求将会被路由到已经失效的克隆节点。如果机器还正常，只是其上面的克隆节点失效，呢么连接将被拒绝， 那么ORB会根据返回的信息把请求发送到其克隆列表中的下一个克隆节点上。如果整个机器已经当机，那么ORB 将会等待一段时间也就是ORB的请求超时（可以自己来配置），如果超时，那么ORB将会假定这个克隆节点已经 失效同时将请求路由到其克隆列表中的下一个克隆节点上。如果这个克隆是可用的，那么这个请求路由将按照 第一种方式来处理。如果这个克隆也失效，那么ORB将会把请求发送给其克隆列表中的再下一个克隆节点上。如果列表中的所有节点都不可用，那么EJB客户端的ORB将会从管理服务器中请求一个新的可用克隆列表。注意：这是在 EJB的JNDI查找完成后，客户端唯一会向管理服务器反馈信息的情况。