基于消息的中间件MOM
中间件所包括的范围十分广泛，针对不同的应用需求涌现出多种各具特色的中间件产品。但至今中间件还没有一个比较精确的定义，因此，在不同的角度或不同的层次
上，对中间件的分类也会有所不同。由于中间件需要屏蔽分布环境中异构的操作系统和网络协议，它必须能够提供分布环境下的通讯服务，我们将这种通讯服务称之
为平台。基于目的和实现机制的不同，我们将平台分为以下主要几类：
远程过程调用（Remote Procedure Call）
面向消息的中间件（Message-Oriented Middleware）
对象请求代理（Object Request Brokers）
它们可向上提供不同形式的通讯服务，包括同步、排队、订阅发布、广播等等，在这些基本的通讯平台之上，可构筑各种框架，为应用程序提供不同领域内的服务，如
事务处理监控器、分布数据访问、对象事务管理器OTM等。平台为上层应用屏蔽了异构平台的差异，而其上的框架又定义了相应领域内的应用的系统结构、标准的
服务组件等，用户只需告诉框架所关心的事件，然后提供处理这些事件的代码。当事件发生时，框架则会调用用户的代码。用户代码不用调用框架，用户程序也不必
关心框架结构、执行流程、对系统级API的调用等，所有这些由框架负责完成。因此，基于中间件开发的应用具有良好的可扩充性、易管理性、高可用性和可移植
性。
MOM面向消息的中间件
MOM指的是利用高效可靠的消息传递机制进行平台无关的数据交流，并基于数据通信来进行分布式系统的集成。通过提供消息传递和消息排队模型，它可在分布环境下扩展进程间的通信，并支持多通讯协议、语言、应用程序、硬件和软件平台。目前流行的MOM中间件产品有IBM的MQSeries、BEA的MessageQ等。消息传递和排队技术有以下三个主要特点：
通讯程序可在不同的时间运行程序不在网络上直接相互通话，而是间接地将消息放入消息队列，因为程序间没有直接的联系。所以它们不必同时运行。消息放入适当的队列时，目标程序甚至根本不需要正在运行；即使目标程序在运行，也不意味着要立即处理该消息。
对应用程序的结构没有约束。在复杂的应用场合中，通讯程序之间不仅可以是一对一的关系，还可以进行一对多和多对一方式，甚至是上述多种方式的组合。多种通讯方式的构造并没有增加应用程序的复杂性。
程序与网络复杂性相隔离
程序将消息放入消息队列或从消息队列中取出消息来进行通讯，与此关联的全部活动，比如维护消息队列、维护程序和队列之间的关系、处理网络的重新启动和在网络中移动消息等是MOM的任务，程序不直接与其它程序通话，并且它们不涉及网络通讯的复杂性。
/*****************************************************************/
作为 MOM（Message Oriented Middleware） 标准的 JMS
Java 消息传送服务规范最初的开发目的是为了使 Java 应用程序能够访问现有 MOM 系统。引入该规范之后，它已被许多现有的 MOM 供应商采用并且已经凭借自身的功能实现为异步消息传送系统。
在创建 JMS 规范时，设计者希望融合现有消息传送系统的精髓。这包括：
路由和传送消息的消息传送提供者的概念
不同的消息传送模式或域，例如点对点消息传送和发布/订阅消息传送
用于接收同步和异步消息的工具
对可靠消息传送的支持
常见消息格式，例如流、文本和字节
供应商通过提供一个 JMS 提供者来实现 JMS 规范，该提供者由实现 JMS 接口的库、消息的路由和传送功能以及用来管理、监视和调整消息传送服务的管理工具组成。路由和传送功能可以由集中式消息服务器或代理来执行，也可以通过每个客户端运行时环境的功能来实现。
同样，JMS
提供者可以扮演多种角色：可以创建为独立产品或大型分布式运行时环境系统中的嵌入式组件。作为独立产品时，它可以用于定义企业应用程序集成系统的主干；在
嵌入到应用服务器中时，它可以支持组件间消息传送。例如，J2EE 使用 JMS 提供者实现消息驱动 Bean 并允许 EJB 组件发送和接收消息。
如果创建了包含现有系统所有功能的标准，则用户很难了解并实现通过此标准建立的系统。而 JMS
定义了消息传送概念和功能所具有的共同特点。从而使这种标准更易于掌握，并最大限度地提高了 JMS 应用程序在 JMS
提供者之间的可移植性。需要强调的一点是，JMS 是 API 标准，而不是协议标准。将 JMS
客户端从一个供应商移动到另一个供应商是很容易的。但是不同的 JMS 供应商之间通常不能相互直接通信。
/*****************************************************************/