中间件技术概念和分类

为什么要中间件

 

计算机技术迅速发展。从硬件技术看，CPU 速度越来越高，处理能力越来越强；从 软件技术看，应用程序的规模不断扩大，特别是Internet 及WWW 的出现，使计算机的应用范围更为广阔，许多应用程序需在网络环境的异构平台上运行。这一切都对新一代的软 件开发提出了新的需求。在这种分布异构环境中，通常存在多种硬件系统平台( 如PC ，工作站，小型机等) ，在这些硬件平台上又存在各种 各样的系统软件( 如不同的操作系统、数据库、语言编译器等) ， 以及多种风格各异的用户界面，这些硬件系统平台还可能采用不同的网络协议和网络体系结构连接。如何把这些系统集成起来并开发新的应用是一个非常现实而困难 的问题。

 

二 什么是中间件

 

为解决分布异构问题，人们提出了中间件(middleware) 的概念。中间件 是位于平台( 硬件和操作系统) 和应用之间的 通用服务，如图1 所示，这些服务具有标准的程序接口和协议。针对不同的操作系统和硬件平台，它们可 以有符合接口和协议规范的多种实现。

 

 

也许很难给中间件一个严格的定义，但中间件应具有如下的一些特点：

 

满足大量应用的需要

运行于多种硬件和OS 平台

支持分布计算，提供跨网络、硬件和OS 平台的透明性的应用或服务的交互

支持标准的协议

支持标准的接口

 

由于标准接口对于可移植性和标准协议对于互操作性的重要性，中间件已成为许多标准化工作的主要部分。对于应用软件开发，中间件远比操作 系统和网络服务更为重要，中间件提供的程序接口定义了一个相对稳定的高层应用环境，不管底层的计算机硬件和系统软件怎样更新换代，只要将中间件升级更新， 并保持中间件对外的接口定义不变，应用软件几乎不需任何修改，从而保护了企业在应用软件开发和维护中的重大投资。

 

三、主要中间件的分类

 

中间件所包括的范围十分广泛，针对不同的应用需求涌现出多种各具特色的中间件产品。但至今中间件还没有一个比较精确的定义，因此，在不 同的角度或不同的层次上，对中间件的分类也会有所不同。由于中间件需要屏蔽分布环境中异构的操作系统和网络协议，它必须能够提供分布环境下的通讯服务，我 们将这种通讯服务称之为平台。基于目的和实现机制的不同，我们将平台分为以下主要几类：

 

远程过程调用（Remote Procedure Call ）

面向消息的中间件（Message-Oriented Middleware ）

对象请求代理（Object Request Brokers ）

 

它们可向上提供不同形式的通讯服务，包括同步、排队、订阅发布、广播等等，在这些基本的通讯平台之上，可构筑各种框架，为应用程序提供 不同领域内的服务，如事务处理监控器、分布数据访问、对象事务管理器OTM 等。平台为上层应用屏蔽 了异构平台的差异，而其上的框架又定义了相应领域内的应用的系统结构、标准的服务组件等，用户只需告诉框架所关心的事件，然后提供处理这些事件的代码。当 事件发生时，框架则会调用用户的代码。用户代码不用调用框架，用户程序也不必关心框架结构、执行流程、对系统级API 的 调用等，所有这些由框架负责完成。因此，基于中间件开发的应用具有良好的可扩充性、易管理性、高可用性和可移植性。

 

下面，针对几类主要的中间件分别加以简要的介绍。

 

远程过程调用

 

远程过程调用是一种广泛使用的分布式应用程序处理方法。一个应用程序使用RPC 来 “远程”执行一个位于不同地址空间里的过程，并且从效果上看和执行本地调用相同。事实上，一个RPC 应 用分为两个部分：server 和client 。server 提供一个或多个远程过程；client 向server 发出远程调用。server 和client 可以位于同一台计算机，也可以位于不同的计算机，甚至运行在不同的操作系统之上。它们通过网络进 行通讯。相应的stub 和运行支持提供数据转换和通讯服务，从而屏蔽不同的操作系统和网络协议。在 这里RPC 通讯是同步的。采用线程可以进行异步调用。

 

在RPC 模型中，client 和server 只要具备了相应的RPC 接口，并且具有RPC 运行支持，就可以完成相应的互操作，而不必限制于特定的server 。 因此，RPC 为client/server 分 布式计算提供了有力的支持。同时，远程过程调用RPC 所提供的是基于过程的服务访问，client 与server 进行直接连接，没有中间机构 来处理请求，因此也具有一定的局限性。比如，RPC 通常需要一些网络细节以定位server ；在client 发出请求的同时，要求server 必须是活动的等等。

 

面向消息的中间件

 

MOM 指的是利用高效可靠的消息传递机制进行平台无关的数据交流，并基于数据通信来进行分布式系统的集成。通过提供消息传 递和消息排队模型，它可在分布环境下扩展进程间的通信，并支持多通讯协议、语言、应用程序、硬件和软件平台。目前流行的MOM 中间件产品有IBM 的MQSeries 、 BEA 的MessageQ 等。消息传递和排队技术有以下三个主要特点：

通讯程序可在不同的时间运行: 程序不在网络上直接相互通话，而是间接地将消息放 入消息队列，因为程序间没有直接的联系。所以它们不必同时运行。消息放入适当的队列时，目标程序甚至根本不需要正在运行；即使目标程序在运行，也不意味着 要立即处理该消息。

 

对应用程序的结构没有约束: 在复杂的应用场合中，通讯程序之间不仅可以是一对一 的关系，还可以进行一对多和多对一方式，甚至是上述多种方式的组合。多种通讯方式的构造并没有增加应用程序的复杂性。

 

程序与网络复杂性相隔离: 程序将消息放入消息队列或从消息队列中取出消息来进 行通讯，与此关联的全部活动，比如维护消息队列、维护程序和队列之间的关系、处理网络的重新启动和在网络中移动消息等是MOM 的任务，程序不直接与其它程序通话，并且它们不涉及网络通讯的复杂性。

 

对象请求代理

 

随着对象技术与分布式计算技术的发展，两者相互结合形成了分布对象计算，并发展为当今软件技术的主流方向。1990 年底，对象管理集团OMG 首次推出对象管理结构OMA(Object Management Architecture) ，对象请求代理（Object Request Broker ）是这个模型的核心组件。它的作用在于提供一个通信框架，透明地在 异构的分布计算环境中传递对象请求。CORBA 规范包括了ORB 的 所有标准接口。1991 年推出的CORBA 1.1 定 义了接口描述语言OMG IDL 和支持Client/Server 对 象在具体的ORB 上进行互操作的API 。CORBA 2.0 规范描述的是不同厂商提供的ORB 之 间的互操作。

 

对象请求代理(ORB) 是对象总线，它在CORBA 规 范中处于核心地位，定义异构环境下对象透明地发送请求和接收响应的基本机制，是建立对象之间client/server 关 系的中间件。ORB 使得对象可以透明地向其他对象发出请求或接受其他对象的响应，这些对象可以位于 本地也可以位于远程机器。ORB 拦截请求调用，并负责找到可以实现请求的对象、传送参数、调用相应 的方法、返回结果等。client 对象并不知道同server 对 象通讯、激活或存储server 对象的机制，也不必知道server 对 象位于何处、它是用何种语言实现的、使用什么操作系统或其他不属于对象接口的系统成分。

 

值得指出的是client 和server 角 色只是用来协调对象之间的相互作用，根据相应的场合，ORB 上的对象可以是client ，也可以是 server ，甚至兼有两者。 当对象发出一个请求时，它是处于client 角色；当它在接收请求时，它就处于server 角色。大部分的对象都是既扮演 client 角 色又扮演server 角色。另外由于ORB 负 责对象请求的传送和server 的管理，client 和server 之间并不直接连接，因此，与RPC 所支持 的单纯的Client/Server 结构相比，ORB 可 以支持更加复杂的结构。

 

事务处理监控

 

事务处理监控（Transaction processing monitors ） 最早出现在大型机上，为其提供支持大规模事务处理的可靠运行环境。随着分布计算技术的发展，分布应用系统对大规模的事务处理提出了需求，比如商业活动中大 量的关键事务处理。事务处理监控界于client 和server 之 间，进行事务管理与协调、负载平衡、失败恢复等，以提高系统的整体性能。它可以被看作是事务处理应用程序的“操作系统”。总体上来说，事务处理监控有以下 功能：

 

进程管理，包括启动server 进程、为其分配任务、监控其执行并对负载进行平 衡。

 

事务管理，即保证在其监控下的事务处理的原子性、一致性、独立性和持久性。

 

通讯管理，为client 和server 之 间提供了多种通讯机制，包括请求响应、会话、排队、订阅发布和广播等。

 

事务处理监控能够为大量的client 提供服务，比如飞机定票系统。如果server 为每一个client 都分配其所需要的资 源的话，那 server 将不堪重负（如图2 所 示）。但实际上，在同一时刻并不是所有的client 都需要请求服务，而一旦某个client 请求了服务，它希望得到快速的响应。事务处理监控在操作系统之上提供一组服务，对client 请求进行管理并为其分配相应的服务进程，使server 在 有限的系统资源下能够高效地为大规模的客户提供服务。

 

 

四、面临的一些问题

 

中间件能够屏蔽操作系统和网络协议的差异，为应用程序提供多种通讯机制；并提供相应的平台以满足不同领域的需要。因此，中间件为应用程 序了一个相对稳定的高层应用环境。然而，中间件服务也并非“万能药”。中间件所应遵循的一些原则离实际还有很大距离。多数流行的中间件服务使用专有的API 和专有的协议，使得应用建立于单一厂家的产品，来自不同厂家的实现很难互操作。有些中间件服务只提供一 些平台的实现，从而限制了应用在异构系统之间的移植。应用开发者在这些中间件服务之上建立自己的应用还要承担相当大的风险，随着技术的发展他们往往还需重 写他们的系统。尽管中间件服务提高了分布计算的抽象化程度，但应用开发者还需面临许多艰难的设计选择，例如，开发者还需决定分布应用在client 方和server 方的功能分配。通常将表示 服务放在client 以方便使用显示设备，将数据服务放在server 以 靠近数据库，但也并非总是如此，何况其它应用功能如何分配也是不容易确定的。