实战activeMQ

现在在互联网中构建的并发量比较大的网站，很少是用java写的，好像潜在，人们在构建基于互联网络的应用中已经因为处理并发能力这个因素将java淘汰出局了，但是，很多事实证明，优秀的实践能弥补语言的先天不足，仿佛很多人在用jetty、jms、apache、memcache、mysql(derby\hsqdb)等这些技术的巧妙组合也能实现百万级并发能力，当然，主流的框架是使用不了了。
其中我对jms的理解一直是“提升系统响应能力”的工具，而非“为了实现某些功能而不得不引入”，因为可以这样说“凡是jms能实现的，rpc一样能实现”，接下来的几个话题我比较感兴趣，也是很像听听大家意见的：

1、在一个使用mq的系统中，消息的生产者和消息的消费者是不是一定在不同的主机和不同的进程里面？是不是说消息的生产者和消费者在同一台主机的同一个进程里面，这种设计压根就不应该用jms，这样设计就是荒谬的？

2、从你拿到需求那天开始，如果你有全权决定技术框架的权利，那么如果你最终选定了jms实现其中的某部分，是什么驱动着你做出这个决定？是需求中某部分不用jms就实现不了？是非功能需求中出于对性能的考虑？还是因为出于对遗留系统的集成？

这两个问题对于我来说很重要，因为我不想发生这种事情：虽然对jms相关开发了若指掌，但是现有系统使用jms除了增加复杂性以外没起到什么作用，就算去掉jms效果也差不多。

1.JMS实际上是一种规范，定义了程序接口，数据结构，服务器和客户端行为，但是并没有定义具体的传输手段。如果jms server和client都在一个jvm里面，用jms通信也是可以的，比如一个jboss里的多个war或ear通过jboss mq通信。如果在同一个ear或war里，再用jms自然就觉得有些多余了。

2.为什么选用jms？java服务端的系统间集成，除了jms，还有更好的选择吗？不论是效率，功能，易用以及第三方工具支持等，jms都比其他的方案要好，至少不差。

看了楼主的activeMQ介绍,有几点疑问

1.在实际项目中,发送消息后,是否需要关闭连接
2.在接收消息的时候,是采取什么方式来循环读取queue中的消息