四、还需要考虑的

　　1，如果其中一个Service崩溃，我们需要停止相应的Listener，这一点可以在Listener中做到，例如当Listener访问Service时出错，它可以等待一段时间以后再去监听Queue，同时把已经取得的消息重新发回到Queue中去，以便让其他的Listener处理。当然也可以将Listener放置到Service端，这样Service崩溃，Listener也就跟着不可用了。

　　2，如果某一时刻，所有的Service都不可用，Proxy也不应该无限等待下去，而应该设置一个等待回复消息的超时期限，如果这个期限内没有收到回复消息，则表明Service都不可用，同时通知客户端。

　　3，过期消息的处理，如同上一点，当Service不可用时，Proxy通知客户端出错，但是此时Proxy已经向Queue中发送了一条消息，当Service恢复时，这条消息会被重新处理。我们应该避免这种情况发生，因为这条消息已经过期了。可以设置消息的过期期限小于Proxy等待回复消息的期限，以确保它不会被重新处理。

　　4，最糟糕的情况就是，Proxy或者Queue崩溃，这样就算Service正常，客户端也会调用失败。

　　5，效率，既然我们选择了WebService和负载均衡，那就表示我们应该接受它效率相对低下的弱点，在这里需要说明的是JMS并不是效率的瓶颈，因为Listener只负责拿到消息并发送给Service，这时Service还是运行在多线程下的。