中间件的基本概念

评估中间件掌握方法是关键要选择一个技术上符合要求的中间件既要了解自己的需求，还得能对一个中间件软件作出技术上的评估

我们这里不谈如何了解您的需求，只谈如何对中间件做技术上的评估

随着中间件的广泛应用，最终用户和应用开发商时常面临这个问题

中间件的种类越来越多，单一产品的功能特性又越来越丰富，如果不得要领，就会陷入到无尽的细节之中

因此，掌握方法就非常重要

选择中间件当然不能只关注技术，必须考虑厂商实力、提供的服务、价格等相关因素，但技术上是否满足需要无疑是位居第一位的

以同类中间件的“标准功能”作为参考你完全可以从你的具体需求出发，看看这个软件是否适用，或者好不好

如果你知道你要评估的这一类中间件软件通常具有的功能——我们称它是“标准功能”——你就有了一个可作为参考的依据

你可以看一看你面前的中间件有没有这些“标准功能”，如果没有，是否对你有重要的影响

把握功能需求、非功能需求与技术标准三个方面我们在设计一个软件时，可以把对软件的需求划分成功能需求和非功能需求

功能需求指明软件必须执行的功能，定义系统的行为——即软件在某种输入条件下要给出确定的输出必须做的处理或转换

功能需求通常是软件功能的“硬指标”——如“支持分布式环境中消息的可靠传输”;非功能需求不描述软件做什么，描述软件如何做

非功能需求通常作为软件设计的“软指标”——如“系统具有可伸缩性”

为此，我们可以把功能需求对应的功能称为“功能性特征”，把非功能需求对应的功能称为“非功能性特征”

评估一个中间件软件，最主要的是看这个软件的功能，包括功能性特征和非功能性特征，是否符合我们的要求，或者符合大多数人的通常要求

如果你知道某一种中间件软件的“标准功能”，你可以进一步把它分成“功能性的特征”和“非功能性特征”

如果你不知道，你只需从你的需求出发，研究一下你面前中间件的“功能性特征”和“非功能性特征”是否满足你的功能需求和非功能需求

中间件是处于支撑地位的通用软件，其技术的标准化具有重要意义

中间件对技术标准的支持表现为使用标准的API、使用标准化的技术和实现标准化的功能等几个方面

中间件支持标准通常意味着用户和应用对厂商的依赖更小、应用开发人员学习使用一种新产品更容易，中间件软件可以和更多的系统互 *** 作，技术更开放

因此，评估一个中间件不仅要看它是否具有某项功能，还要看这个功能是否使用了标准的技术

功能性特征是中间件的基本特征中间件的功能性特征是一种中间件软件的基本特征

不同种类的中间件的差异首先表现为基本功能的不同，因此我们不能总结出一套适合所有中间件门类的、一般性的“功能性特征”

对于某一个具体的中间件软件，我们能够把它的功能性特征提取出来

我们假定某一中间件定位于解决分步式环境中消息的发送者和接收者之间消息传输、管理和控制问题，该软件提供了多种消息交换方式、支持多种消息类型，提供可靠传输等服务质量控制机制，该软件支持多系统平台，支持高吞吐量的业务处理很显然，我们可以把“提供多种消息交换方式、支持多种消息类型，提供可靠传输等服务质量控制机制”看成是该中间件的功能性特征，而把“支持高吞吐量的业务处理”作为非功能性的特征

如果中间件的选择者能够从自己的需求中归纳出对中间件的“功能需求”，就可以把它们和面前的中间件的功能性特征做一下对照

功能性特征一般比较容易测试，因而也比较容易验证

非功能性特征是跨中间件的共性特性软件的“非功能需求”是软件需求的重要方面

中间件软件的“非功能性特征”也是中间件功能的重要方面

事实上，中间件软件的非功能性特征是跨中间件种类的、非常重要的一般性特征，是中间件软件功能强大的表现

我们这里采用了在2000年的《中间件——达成灵便的电子商务的技术基础》一文中对成功的中间件的共性特征的归纳(做了一点裁减)：许多情况下，非功能性和功能性并非有严格的界线

比如，对于消息中间件来说，可靠传输一定是功能性的特征;对于其它的中间件未必如此;对于安全中间件来说，安全不能算作非功能性特征

非功能性特征一般比较难以测试，但仍然是一定程度可测试的

支持标准对于中间件必可缺少面向消息的中间件一直以来缺乏技术标准/规范

自从J2EE制定出基于Java的Java消息传输服务(JMS)以后，人们对消息中间件的技术要求就有多了一项内容

相比较而言，事务处理监控程序(交易中间件)相关的技术规范就要多一些，主要是X/OPEN(现称为OPENGROUP)的分布式事务处理系列规范，包括TPM的架构、应用与TPM的接口及事务提交管理协议等重要内容

对于J2EE应用服务器，技术规范的影响就更大

我们甚至可以说，J2EE应用服务器的功能体现在了对技术标准和规范的支持上

标准/规范虽然重要，我们不可迷信，唯标准是从

因为，第一，“标准”可能仅是建议性的，并非所有的厂商都会遵守;第二，“标准”可能是妥协的结果，只是将提交的多个可选内容统统收入，各项内容甚至不能互换;第三，“标准”可能是不完整的，仅仅实现了标准要求的内容可能意味着欠缺重要的功能

比如，X/OPENDTP模型中定义的应用与TPM的接口就是妥协的结果

所谓“标准”就是两个厂家提交的完全不同的建议的罗列，两者完全不能互换

事实上也未见第三家厂商遵从上述的“标准”

这样的“标准”也只咎由自取参考意义

在看JMS，JMS当前规范只涉及一个消息服务器，规范只保证该服务器的客户方都使用一个一致的接口

如果厂商只是实现了JMS规范定义的内容，那么它就必不能支持服务器到服务器之间的可靠传输，其功能就会大打折扣

无论是用户还是中间件厂商，对标准都不应该迷信

中间件对标准的支持一般会体现在软件的功能性特征上，多数情况下是可测试和验证的

由于应用范围和产品历史不同，这些通信子系统也就千差万别。关于几种常用的中间件产品，比如IBM MQSeries，CICS/TXSeries和BEA Tuxedo的通信机制，是经常被软件工程师们讨论的话题，因为许多产品特性都是与此息息相关的。我这里仅仅粗浅地介绍一下最表层的一些架构，希望能够抛砖引玉。首先，我想对比一下数据传输类中间件MQSeries与TPM类交易中间件CICS/TXSeries和BEA Tuxedo。MQSeries与CICS/TXSeries或BEA Tuxedo有很大的不同，因为MQSeries被设计为一个以异步数据通信为基础的中间件。MQSeries这类中间件的特点是“存储/转发”(对持久消息，直接保存到硬盘；对非持久消息，开始时先保存到共享内存)，而TPM中间件(包括TXSeries和Tuxedo)没有这个“存储”的功能，而侧重分布式的实时交易处理。数据传输类中间件MQSeries适于以下的应用场合：数据跨异种系统的可靠传输。 高速地传送数据或请求，接收方一般不会因为工作量大而导致溢出或丢弃。
这是因为数据传输中间件系统的接收器快速存储收到的数据而不急于进行处理和响应。 消耗时间长的交易，或消耗时间长短不定的交易，或者是批处理作业。
服务程序(MQ守护程序)可以高效率的执行批量交易和长时间交易，而完全不用考虑通信等待的问题，通信由相关的队列、通道和收听器来维护。 工作量按时间分布不均匀的服务器系统。
服务程序可以充分利用系统空闲的时间(比如夜间)工作。 分布式的复杂系统
分布式的复杂系统存在各种各样的意外事件和复杂情况，如果全部采用同步系统，一个工作点的失败可以导致整个系统的瘫痪。异步和“存储/转发”是解决相互等待的最佳途径。 相对数据传输中间件MQSeries，TPM类交易中间件(CICS/TXSeries和BEA Tuxedo)有以下的优势：针对高速且有返回信息的交易，有极快的响应速度。 强大的分布式事务处理的能力。
MQSeries也支持两阶段提交，但异步的性质决定了它不能支持分布式应用的统一交易处理。 完全屏蔽了通信层的工作，使开发更加简便，专注于业务系统。 MQSeries的通信机制的核心是通道和收听器。通道设置决定了通信的协议、参数和相关方法。MQSeries的收听器有两种机制：基于inetd的守护进程机制(amqcrsta)，和基于线程响应的机制(runmqlsr)。这两种机制各有优缺点。runmqlsr的性能更出色，但老版本的MQSeries在接收过多的连接时有一些问题。amqcrsta能支持更多的通道和客户访问，但可能造成系统资源更多的损耗。MQSeries v53以后，runmqlsr已经得增强，我个人认为这种方式更好。当然，无论如何，要接受更多客户机或通道的访问，必须调整qmini或Windows注册表的一些参数(MaxChannels, MaxActiveChannels, ListenerBacklog)，以及一些相关的 *** 作系统的内核参数。以客户机访问方式为例，MQSeries的每个客户机都与收听器(amqcrsta或runmqlsr)建立Socket连接，而MQSeries收听器通过IPC机制通知Queue Manager Agent (amqzlaa0)读写消息和队列。客户机访问方式采用的是短连接，而通道连接方式采用的是长连接。关于短连接和长连接的比较，后面还要加以讨论。CICS/TXSeries的通信处理与MQSeries的通道连接方式类似，使用长连接的方式。CICS/TXSeries的TCP/IP收听器进程叫做cicsip，在v51以后，其功能大大增强。CICS/TXSeries使用一个LD:TCPProcessCount参数，其内部是用了Socket的SO_REUSEADDR选项，支持多个收听器进程是用相同的IP和端口。这个特性大大简化了多并发情况的客户机设置，可以采用相同的服务器收听器设置。当然这种特性会增加服务器收听器的设计难度。cicsip进程将请求写入请求队列，实际上是写入Region Pool中的共享内存。而每个应用服务器进程(cicsas)通过IPC机制读取请求，经过计算，返回信息到共享内存中的应答队列，再通过收听器返回客户机。可以看出，CICS/TXSeries在内部使用了一个异步处理的方式，其目的是充分利用系统资源，达到最高的吞吐效率。但对外仍然是一个同步通信的系统。但是与MQSeries不同，CICS/TXSeries没有任何存储数据或请求的 *** 作，队列的容量和数据的生存期也远远小于MQSeries。在这些方面，CICS/TXSeries与Tuxedo没有什么不同。但Tuxedo的通信机制还是有很多不同于CICS/TXSeries的方面：CICS/TXSeries的通信设置很简单，只须设置一个收听器IP和端口就可以了。Tuxedo的通信设置可就多了，本地语言(C, COBOL等)客户访问(WSL)，Java Jolt访问(JSL)，域连接(T/DOMAIN)，集群等等都需要独立的网络设置，使用独立的收听器。而且还有很多看不见的端口被作为客户连接使用(WSH)，网络管理员在配置防火墙时要颇费一番脑筋。 Tuxedo使用短连接的方式，与MQSeries的客户机访问方式相似，但通信方式要复杂一些。以本地语言客户访问的收听器WSL为例：WSL在接收到客户请求后，立即释放连接，而客户机接着使用新建的连接与一个WSH进程继续通信。这种方式可以降低WSL的工作量。 Tuxedo的客户机程序直接与收听器建立Socket连接。CICS/TXSeries的客户机程序通过IPC与一个客户机守护程序(cclclnt)通信，该守护程序(cclclnt)与CICS/TXSeries的服务器建立一个Socket连接。 目前MQSeries和Tuxedo的收听器还不支持复用IP地址和端口，所以如果有太多的客户访问或通道连接，需要增加新的收听器端口。从上面的讨论可以看出：MQSeries的通道连接方式以及CICS/TXSeries采用长连接的通信方式，MQSeries的客户机访问方式以及Tuxedo采用短连接的通信方式。所谓长连接，就是一旦建立连接，一般的应用API不会中断该连接；所谓短连接，就是在一个完整的应用中先建立连接，最后结束该连接，而且程序退出时必然切断连接。这两种通信方式对应用系统有着深刻的影响。短连接灵活方便，避免了下述很多长连接面临的棘手的问题：客户机异常中断，网络中断，包括Windows 9x之类的 *** 作系统正常关闭，都不会通知服务器，造成服务器保持闲置无用的连接，长连接通常要等待“tcp_keepidle”之类的时间，这个时间默认时一般是两个小时。这样会明显加重服务器的负载，无故占用相应的资源。MQSeries采用DISCINT和HBINT等通道参数来避免这个问题。 如果仅仅是少量访问，建立长连接浪费过多的资源。MQSeries也是通过DISCINT和HBINT等通道参数来避免这个问题。 网络相关的故障仅仅影响本次连接。短连接可以隔离故障的影响。

满足大量应用的需要 ；
运行于多种硬件和OS平台 ；
支持分布式计算，提供跨网络、硬件和OS平台的透明性的应用或服务的交互功能 ；
支持标准的协议 ；
支持标准的接口。 最早具有中间件技术思想及功能的软件是IBM的CICS，但由于CICS不是分布式环境的产物，因此人们一般把Tuxedo作为第一个严格意义上的中间件产品。Tuxedo是1984年在当时属于AT&T的贝尔实验室开发完成的，但由于分布式处理当时并没有在商业应用上获得像今天一样的成功，Tuxedo在很长一段时期里只是实验室产品，后来被Novell收购，在经过Novell并不成功的商业推广之后，1995年被BEA公司收购。尽管中间件的概念很早就已经产生，但中间件技术的广泛运用却是在10年之中。BEA公司1995年成立后收购Tuxedo才成为一个真正的中间件厂商，IBM的中间件MQSeries也是90年代的产品，其它许多中间件产品也都是最近几年才成熟起来。
1998年IDC公司对于中间件有一个定义，并根据用途将其划分为6个类别。如今所保留下来的只有消息中间件和交易中间件，其他的已经被逐步融合到其他产品中了，被包裹进去了，在市场上已经没有单独的产品形态出现了。例如，当时有一个叫屏幕数据转换的中间件，其主要是针对IBM大机终端而设计产品，用于将IBM大机终端的字符界面转化为用户所喜欢的图形界面，类似的东西当时都称为中间件。但随着IBM大机环境越来越少，当时盛行一时的此类中间件如今已经很少再被单独提及。 2000年前后，互联网盛行起来，随之产生了一个新的东西，就是应用服务器。实际上，交易中间件也属于是应用服务器，为了区分，人们把传统的交易中间件称为分布交易中间件，因它主要应用在分布式环境下，而将新的应用服务器，称为J2EE中间件，到目前为止，这都是市场上非常热门的产品。
EAI概念出来之后，市场上又推出了一些新的软件产品，例如工作流、Portal等，但从分类上不知道怎么归类，向上不能够划归应用，往下又不能归入 *** 作系统，于是就把它归入了中间件，如此中间件的概念更加扩大了。市场上对于中间件，各家的说法不一，客观上也导致了理解上的复杂性。

技术现状

中间件技术是在克服复杂网络应用的共性问题中不断发展和壮大起来的，这些问题可以归纳为四个方面：

1、从计算环境来看：中间件面对的是一个复杂、不断变化的计算环境，要求中间件技术具有足够的灵活性和可成长性；

2、从资源管理的角度来看： *** 作系统和数据库管理系统管理的是有限资源，资源种类有限，资源量也有限，而中间件需要管理的资源类型（数据、服务、应用）更丰富，且资源扩展的边界是发散的；

3、从应用支撑角度来看：中间件需要提供分布应用开发、集成、部署和运行管理的整个生命周期的总体运行模型；

4、从应用的角度来看：利用中间件完成的往往是复杂、大范围的企业级应用，其关系错综复杂，流程交织。例如客户关系管理系统需要集成多个企业内部应用，而供应链管理则涉及企业之间的应用集成。

因此，由于网络应用的复杂性，特别是分布、异构和自治等特点，决定了中间件技术和产品的形态多样性。中间件技术已经形成一个丰富的谱系（图1），并正在向上（应用框架和普适服务）和向下（融合 *** 作系统、数据库管理系统的功能）两个方向不断延伸，并在向更宽广的应用领域拓展。

图1中间件技术谱系

在国内，国防科技大学、北京大学、北航、中科院软件所、东南大学等大学和院所很早就投入到中间件技术的研究中，并形成了一系列的成果。在国家发改委、信息产业部电子发展基金和国家科技部863计划和政府其他基金资助下，通过各项目研究单位和国内骨干软件企业多年的不懈努力，国内在基础中间件领域已经形成丰富的技术积累，并在CORBA技术（国防科技大学与中创软件）、消息中间件技术（中科院软件所）、J2EE应用服务器（北京大学）、WebService（北航）等方面在技术上基本与国外保持同步发展的水平。

以CORBA技术为例，国防科技大学与中创软件以对象管理组织发布的CORBA及MDA标准体系为依据，并结合J2EE、XML、WebService等标准，对ORB、CORBA构件模型及其运行支撑技术、企业协同框架（CCA）、EAIProfile等进行了深入的研究，近3年在国内一级刊物和国际会议上发表50多篇文章，向对象管理组织（OMG）提交9项标准提案，已经从标准跟从阶段进入参与阶段，研究论文和成果在国际上得到广泛引用，国防科技大学CORBA研究成果StarBus并获得国家科技进步二等奖。

产品与市场现状

中间件作为基础软件的重要组成，已与 *** 作系统、数据库齐头并进，在世界范围内呈现出迅猛发展的势头，已经形成一个巨大的产业。中间件在国内整个软件行业中应该是发展速度最快的市场之一。中国软件产业经过20年的发展，很多部门的信息化建设都走过了关键业务应用和部门级应用的阶段，现在开始向企业级应用转变。所谓企业级应用，最为人们所重视的就是各类信息资源之间如何关联、整合、协同、互动和按需服务，这些都是中间件能够发挥巨大作用的空间所在。当然，中国软件产业整体上还比较弱，整个社会信息化的程度无论在广度、深度方面都还不够，这些自然也限制了国内软件产业及中间件的市场规模。随着国家信息化建设的不断深入，社会对应用软件，特别是对网络应用起支撑作用的中间件产品的巨大需求是不争的事实，国内中间件的市场才刚刚开始启动，存在巨大的发展机会和空间。

网络应用中间件逐渐在基础中间件、应用中间件、应用框架等三个层面形成激烈的产品竞争和市场竞争格局。从三个方面的产品来分析，国外厂商仍然占主导地位，主流厂商包括IBM，BEA，ORACLE，HP，Iona等，而一些新型的中间件公司，如Tibco，webMethod，Vitria也开始携其应用集成中间件或业务流程管理中间件进入中国市场。而国内一些规模较大的软件公司也开始进入此领域，形成了包括中创软件商用中间件、金蝶Apusic、东方通科技、中关村科技、北京汇金科技、中和威等在内的一批中间件专业厂商，东软、用友、信雅达等应用集成商也大量投入中间件产品的研发，国产中间件已经形成了比较完整产品体系，例如，中创软件、中和威推出了基于CORBA标准的通信中间件产品；中创软件、金蝶软件、东方通技、北京汇金科技等公司分别推出了遵循J2EE规范的应用服务器产品；中创软件、中科院软件所、东方通科技、北京汇金科技推出了消息中间件产品；中创软件推出了符合OMG标准的企业应用集成套件InforEAI；此外，还有大量的公司投入到中间件开发平台和构件库的建设中。国产中间件已经广泛成功应用于我国政府、交通、金融、证券、保险、税务、电信、移动、教育、军事等行业或领域的信息化建设，并成为大型应用系统建设不可缺少的一环。

同国外厂商比较，国内中间件厂商的整体实力还存在很大的差距。如果仅仅从产品的功能上看，我们似乎并不比别人缺什么，但围绕中间件产品从研发到成功应用的全周期来看，我们还缺很多东西，暂时也很难对国外产品形成真正的竞争威胁。应该说国内中间件产品的成熟度应该是没有问题的，但要市场普遍接受国产中间件产品，却还有一个相当长的过程。以中创软件Infor系列中间件为例，我们提供的产品可在各类主流 *** 作系统平台和主流数据库上稳定可靠地运行，并可与通行的各种开发工具紧密融合，产品都具备丰富的系统管理功能，并已经在大量行业中获得了成功应用经验，即使如此，要真正形成具有号召力的中间件品牌，还有艰巨的路需要一步步去走。同国外优秀中间件产品相比，我们还有大量需要借鉴和学习的地方，例如在产品的发展方向把握、持续开发能力、产品化工作、市场运作等方面，我们都还要继续加强，不断完善。当然，国内中间件厂商及其产品也具有非常明显的优势，我们贴近国家信息化的现实需求，已经积累了丰富的领域问题和中间件应用经验，我们的中间件产品可以在实用性和易用性方面更加贴近本地化市场需求，在技术支持和服务方面也具有相当的优势。

中间件是一种独立的系统软件或服务程序，是连接两个独立应用程序或独立系统的软件，即使它们具有不同的接口，但通过中间件相互之间仍能交换信息。

中间件在 *** 作系统、网络和数据库之上，应用软件的下层，总的作用是为处于自己上层的应用软件提供运行与开发的环境，帮助用户灵活、高效地开发和集成复杂的应用软件。

随着计算机技术的快速发展，更多的应用软件被要求在许多不同的网络协议、不同的硬件生产厂商以及不一样的网络平台和环境上运营。这导致了软件开发者需要需要开发多种应用程序来达到运营的目的。所以，中间件技术的产生，在极大程度上减轻了开发者的负担，使得网络的运行更有效率。

扩展资料

中间件技术

1、远程过程调用

一个应用程序使用RPC来“远程”执行一个位于不同地址空间里的过程，并且从效果上看和执行本地调用相同。事实上，一个RPC应用分为两个部分：server和client。server提供一个或多个远程过程；client向server发出远程调用。

在RPC模型中，client和server只要具备了相应的RPC接口，并且具有RPC运行支持，就可以完成相应的互 *** 作，而不必限制于特定的server。

2、面向消息的中间件

MOM指的是利用高效可靠的消息传递机制进行平台无关的数据交流，并基于数据通信来进行分布式系统的集成。消息放入适当的队列时，目标程序甚至根本不需要正在运行；即使目标程序在运行，也不意味着要立即处理该消息。

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

3、对象请求代理

可向上提供不同形式的通讯服务，包括同步、排队、订阅发布、广播等等，在这些基本的通讯平台之上，可构筑各种框架，为应用程序提供不同领域内的服务，如事务处理监控器、分布数据访问、对象事务管理器OTM等。

4、事务处理监控

事务处理监控最早出现在大型机上，为其提供支持大规模事务处理的可靠运行环境。随着分布计算技术的发展，分布应用系统对大规模的事务处理提出了需求，比如商业活动中大量的关键事务处理。

参考资料来源：百度百科—中间件

参考资料来源：百度百科—中间件技术

---