基于消息的中间件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 供应商之间通常不能相互直接通信。
/*****************************************************************/