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

中间件是软件技术发展的一种潮流，被誉为发展最快的软件品种，近年来势头强劲，当然，这也是源于市场在全球范围内对中间件的支持。毫无疑问，中间件正在成为软件行业新的技术与经济增长点。

1999年，Nasdaq股市上投资回报率最高的并非某些名声显赫的网站，而是全球最大的独立中间件厂商BEA公司，其股票升幅高达884.6%。时至今日，BEA的营业收入已连续18个季度保持高速增长。

国际数据集团（IDC）在日前发表的一份报告中预计今后五年中间件市场将快速成长。IDC预计全球中间件和商业软件收入将从1999年的27亿美元增长到2004年的近97亿美元，增长255%。据GlobalSight公司预计，全球电子商务市场到2001年将达到1.2万亿美元。 ForresterResearch则估计，仅仅是BtoB电子商务，到2003年的年收入就将达到1.3万亿美元。而业内人士认为，未来基于 Internet的电子商务业务将有79%建筑在中间件的基础之上。无疑，这将带来一个潜力巨大的市场。

在中国，有关数字同样让人兴奋，1998年中间件市场总值达12.34亿美元;1999年为17亿美元；预测到2004年将达到90.3亿美元，年增长率为39.7%，远远高于软件业的平均增长水平。

为什么要使用中间件

具体地说，中间件屏蔽了底层操作系统的复杂性，使程序开发人员面对一个简单而统一的开发环境，减少程序设计的复杂性，将注意力集中在自己的业务上，不必再为程序在不同系统软件上的移植而重复工作，从而大大减少了技术上的负担。中间件带给应用系统的，不只是开发的简便、开发周期的缩短，也减少了系统的维护、运行和管理的工作量，还减少了计算机总体费用的投入。

中间件定义及分类

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

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

满足大量应用的需要

运行于多种硬件和OS平台

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

支持标准的协议

支持标准的接口

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

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

远程过程调用（Remote Procedure Call）

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

对象请求代理（Object Request Brokers）

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

1、远程过程调用 远程过程调用是一种广泛使用的分布式应用程序处理方法。一个应用程序使用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必须是活动的等等。

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

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

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

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

3、对象请求代理 随着对象技术与分布式计算技术的发展，两者相互结合形成了分布对象计算，并发展为当今软件技术的主流方向。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可以支持更加复杂的结构。

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

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

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

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

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

地为大规模的客户提供服务。

IBM MQSeries是IBM的消息处理中间件。MQSeries提供一个具有工业标准、安全、可靠的消息传输系统。

它的功能是控制和管理一个集成的系统，使得组成这个系统的多个分支应用(模块)之间通过传递消息完成整个工作流程。MQSeries基本由一个信息传输系统和一个应用程序接口组成，其资源是消息和队列。

MQSeries的关键功能之一是确保信息可靠传输，即使在网络通信不可靠或出现异常时也能保证信息的传输。MQSeries的异步消息处理技术能够保证当网络或者通信应用程序本身处于“忙 "状态或发生故障时，系统之间的信息不会丢失，也不会阻塞。

TongLINK/Q是面向消息的中间件。TongLINK/Q的主要功能是在不同的网络协议、不同的操作系统和不同的应用程序之间提供可靠的消息传送。

* 高效、可靠、灵活的传输功能

通过预建连接、多路复用、流量控制、压缩传输、断点重传、传输优先级管理、服务（类）驱动等机制来保证实现。

* 事件代理机制

事件代理机制提供了一种异步应用开发模型，用户只需要定义一个事件及怎么处理，TongLINK/Q自动完成操作。利用事件代理机制，可以实现事件订阅与发布，实现策略管理。

* 会话管理

TongLINK/Q通过一个简单的会话标识来描述一种复杂的通信关系，实现了更高层次、更抽象的通信服务。

* 良好的易用性和可管理性

TongLINK/Q实现了实时监控和管理，提供了日志机制、动态配置、远程管理功能。并提供多层次安全管理，支持多种开发工具。

BEA TUXEDO是目前最成功的中间件产品，它有以下特点：

* 高速数据甬道机制，减少客户机与主机和数据库的联接，降低整个系统的负担

* 提供名字服务和数据依赖路由机制，提高系统设计的灵活性

* 提供7种客户机/服务器通讯方式，使应用开发灵活方便

* 提供多个层面的系统负载均衡机制，能最有效地运用系统资源

* 提供服务优先级机制，区分服务的不同级别，使重要服务得到最快的响应

* 提供网络通讯压缩和加密机制，使通讯性能和安全性大大提高

* 提供动态伸缩机制，方便应用系统的扩充和维护

* 提供故障恢复等机制，保证应用的高可用性

* 提供多个层面的安全机制，保证应用的安全性

* 支持XA协议，保证涉及多场地、异构数据源交易和数据的一致性

* 提供多个层面的应用管理机制，使应用管理方便容易

* 提供网络调度功能，实现网络资源的充分利用并支持通讯失败的自动恢复

* 与其他多种系统互联，保护用户投资

* 支持异构系统数据格式的透明转换，方便系统扩展

* 支持包括声音、图象在内的多种数据类型，不同编程语言数据格式的区别由TUXEDO自动转换(如C和COBOL)，其中FML类型更支持网上只传输有效数据和可改变的多种数据类型组合等功能

* 提供域的划分与管理功能，使超大规模应用成为可能

* 提供DES(Data Entry System)功能，支持字符界面的开发

* 支持国际化，可用中文显示诊断和系统消息

RFID中间件具有下列的特色:

独立于架构(Insulation Infrastructure)RFID中间件独立并介于RFID读写器与后端应用程序之间，并且能够与多个RFID读写器以及多个后端应用程序连接，以减轻架构与维护的复杂性。

数据流(Data Flow)RFID的主要目的在于将实体对象转换为信息环境下的虚拟对象，因此数据处理是RFID最重要的功能。RFID中间件具有数据的搜集、过滤、整合与传递等特性，以便将正确的对象信息传到企业后端的应用系统。

处理流(Process Flow)RFID中间件采用程序逻辑及存储再转送(Store-and-Forward)的功能来提供顺序的消息流，具有数据流设计与管理的能力。

标准(Standard)RFID为自动数据采样技术与辨识实体对象的应用。EPCglobal目前正在研究为各种产品的全球惟一识别号码提出通用标准，即EPC(产品电子编码)。EPC是在供应链系统中，以一串数字来识别一项特定的商品，通过无线射频辨识标签由RFID读写器读入后，传送到计算机或是应用系统中的过程称为对象命名服务(Object Name Service)。对象命名服务系统会锁定计算机网络中的固定点抓取有关商品的消息。EPC存放在RFID标签中，被RFID读写器读出后，即可提供追踪EPC所代表的物品名称及相关信息，并立即识别及分享供应链中的物品数据，有效率地提供信息透明度。

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

满足大量应用的需要

运行于多种硬件和OS平台

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

支持标准的协议

支持标准的接口

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

RFID中间件是一种面向消息的中间件(Message-Oriented Middleware，MOM)，信息(Information)是以消息(Message)的形式，从一个程序传送到另一个或多个程序。信息可以以异步(Asynchronous)的方式传送，所以传送者不必等待回应。面向消息的 中间 件包含的功能不仅是传递(Passing)信息，还必须包括解译数据、安全性、数据广播、错误恢复、定位网络资源、找出符合成本的路径、消息与要求的优先次序以及延伸的除错工具等服务。

RFID中间件可以从架构上分为两种:

以应用程序为中心(Application Centric) 的设计概念是通过RFID Reader厂商提供的API，以Hot Code方式直接编写特定Reader读取数据的Adapter，并传送至后端系统的应用程序或数据库，从而达成与后端系统或服务串接的目的。

以架构为中心(Infrastructure Centric) 随着企业应用系统的复杂度增高，企业无法负荷以Hot Code方式为每个应用程式编写Adapter，同时面对对象标准化等问题，企业可以考虑采用厂商所提供标准规格的RFID中间件。这样一来，即使存储RFID标签情报的数据库软件改由其他软件代替，或读写RFID标签的RFID Reader种类增加等情况发生时，应用端不做修改也能应付。

RFID 中间件的特征 一般来说，RFID 中间 件具有下列的特色:

独立于架构(Insulation Infrastructure) RFID 中间 件独立并介于RFID读写器与后端应用程序之间，并且能够与多个RFID读写器以及多个后端应用程序连接，以减轻架构与维护的复杂性。

数据流(Data Flow) RFID的主要目的在于将实体对象转换为信息环境下的虚拟对象，因此数据处理是RFID最重要的功能。RFID 中间 件具有数据的搜集、过滤、整合与传递等特性，以便将正确的对象信息传到企业后端的应用系统。

处理流(Process Flow)RFID 中间 件采用程序逻辑及存储再转送(Store-and-Forward)的功能来提供顺序的消息流，具有数据流设计与管理的能力。

标准(Standard) RFID为自动数据采样技术与辨识实体对象的应用。EPCglobal目前正在研究为各种产品的全球惟一识别号码提出通用标准，即EPC(产品电子编码)。EPC是在供应链系统中，以一串数字来识别一项特定的商品，通过无线射频辨识标签由RFID读写器读入后，传送到计算机或是应用系统中的过程称为对象命名服务(Object Name Service，ONS)。对象命名服务系统会锁定计算机网络中的固定点抓取有关商品的消息。EPC存放在RFID标签中，被RFID读写器读出后，即可提供追踪EPC所代表的物品名称及相关信息，并立即识别及分享供应链中的物品数据，有效率地提供信息透明度。

面对各种RFID的应用，用户的首要问题是:"如何将现有的系统与新的RFID Reader连接?"

事实上，这个问题的本质是用户应用系统与硬件接口的问题。在RFID应用中，通透性是整个应用的关键，正确抓取数据、确保数据读取的可靠性、以及有效地将数据传送到后端系统都是必须考虑的问题。传统应用程序之间的数据通透是通过中间件架构来解决的，并由此发展出各种Application Server应用软件。