回到2003年，一群开源开发者聚在一起组成了Apache Geronimo。在这种情况下，他们发现没有一个很好的使用BSD风格许可证的消息中间件可用。因为Geronimo需要一个JMS实现J2EE兼容性，所以一些开发者开始探讨这种可能性。他们拥有大量的商业MOM经验，而且他们甚至之前已经创建了一些MOM，这些开发者打算创建下一代伟大的开源消息中间件。

　　ActiveMQ其他的一些灵感来源于市场上的大多数MOM是商业化的这个事实，封闭源码，而且购买和支持的成本高昂。商业MOM的确在业务上很流行，但是很多业务并不能负担的起不合理的成本。这也进一步增加了创建一个开源替代物的积极性。使用Apache许可证的开源MOM确实有着市场潜力。Apache ActiveMQ随着时间进步。ActiveMQ打算作为JMS的标准，以供分布式应用之间的远程通信。为了更好地理解这个意思，最佳的做法就是回顾一下分布式应用设计，尤其是通信。

　　松耦合和ActiveMQ

　　ActiveMQ为应用架构提供了松耦合的好处。松耦合通常被引入到一个架构迁移到一个古典的紧耦合的远程过程调用（RPC）中。这样一个松耦合设计被认为是异步的，调用两个应用中的任何一个应用对另一个都没有影响；不相互依赖或者有时间要求。应用可以信任ActiveMQ有能力保障消息交付。因此，通常表述为应用发送消息是发送后自寻的。也就是他们把消息发给ActiveMQ，并不关心消息如何交付和什么时候交付。同样的，消费应用也不用关心消息来自哪里何以如何发送到ActiveMQ的。这对于在非均匀环境中来说尤其有用，这种环境中允许客户端使用不同的语言编写，甚至可能是不同的网格协议。ActiveMQ充当中间人，允许以异步的方式进行非均匀集成和交互。

　　在考虑分布式应用设计的时候，应用耦合很重要。耦合引用两个或者多个应用或系统的依赖性。简单的理解耦合就是考虑从系统中任何应用改变对其他应用产生的影响，这种含义穿过架构中的其他应用作为性能被添加。改变一个应用会迫使所涉及的其他应用改变呢？如果回答是肯定的，这些应用就是紧耦合。然而，如果一个应用可以在不影响其他应用的情况下改变，这些应用就是松耦合的。对比松耦合，紧耦合应用很难维护。

　　像COM、CORBA、DCE和EJB这样的技术使用的技术称之为远程过程调用（RPC），RPC被认为是紧耦合的。使用RPC，当一个应用调用另一个应用的时候，调用者是锁定的，直到被调用者返还会控制权。图一描述了这个概念。

图一

　　通信

　　图一中的调用者是锁定的，直到被调用者返还会控制权。许多系统架构使用RPC，而且很成功。然而，是有这种紧耦合设计也有很多缺点，最显著的就是很高的维护费用需求，可谓一石激起千层浪。在另个应用见正确的时间是必要的。对于应用都必须在同时可用的这种需求从应用一到应用二，响应从应用二到应用一。这样的时间需求很难处理。对比这样设计中的紧耦合和松耦合，两个应用彼此完全不知道对方，如图二所示。

图二

　　图二中的应用一给MOM 发送了一个消息，可能过了一段时间，应用二从MOM收到一条消息。另个应用都不知道对方的存在，在两个应用之间也没有时间需求。这种单一风格的交互结果维护成本很低，因为一个应用改变对另一个没有影响。因此，松耦合应用在分布式应用设计中更具优势。

　　试想在应用必须转移到另一个地点的这种改变。这种情况可能发生在新的硬件需求或简单的机器转移的时候。紧耦合的系统设计，这样的环境很难转移，因为所有应用片段必须经历断电。松耦合设计的应用，不同的系统片段可以独立的转移。假如应用一和应用二都有多个实例，每个实例都属于不同的机器中。ActiveMQ安装在另外完全独立于这两个应用的机器上。在这种场景中，这些实例都可以移动，而不影响彼此。实际上，ActiveMQ的多个实例被认为是中间件配置网络。它允许ActiveMQ实例不影响其他实例的情况下自由转移。这意味着这个架构中的任何片段可以在任何时间被维护，而无需影响这个系统。

　　因此ActiveMQ为应用架构提供了一种不可思议的灵活性，松耦合的概念也成为现实。但是ActiveMQ应该在何时使用呢？欢迎继续关注。