评估中间件掌握方法是关键

　　要选择一个技术上符合要求的中间件既要了解自己的需求，还得能对一个中间件软件作出技术上的评估。我们这里不谈如何了解您的需求，只谈如何对中间件做技术上的评估。随着中间件的广泛应用，最终用户和应用开发商时常面临这个问题。中间件的种类越来越多，单一产品的功能特性又越来越丰富，如果不得要领，就会陷入到无尽的细节之中。因此，掌握方法就非常重要。

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

　　以同类中间件的“标准功能”作为参考

　　你完全可以从你的具体需求出发，看看这个软件是否适用，或者好不好。如果你知道你要评估的这一类中间件软件通常具有的功能——我们称它是“标准功能”——你就有了一个可作为参考的依据。你可以看一看你面前的中间件有没有这些“标准功能”，如果没有，是否对你有重要的影响。

　　各种中间件软件的“标准功能”是什么？对于这个问题没有标准和绝对的答案，但可以有多数人或多数厂家可以接受的答案，你不妨以之作为参考。如果找不到现成的，你也可以自己试着去归纳。向各个厂家要一下产品的介绍材料，做一下比较。“标准功能”通常包含在产品的共性功能中。

　　把握功能需求、非功能需求与技术标准三个方面

　　我们在设计一个软件时，可以把对软件的需求划分成功能需求和非功能需求。功能需求指明软件必须执行的功能，定义系统的行为——即软件在某种输入条件下要给出确定的输出必须做的处理或转换。功能需求通常是软件功能的“硬指标”——如“支持分布式环境中消息的可靠传输”；非功能需求不描述软件做什么，描述软件如何做。非功能需求通常作为软件设计的“软指标”——如“系统具有可伸缩性”。为此，我们可以把功能需求对应的功能称为“功能性特征”，把非功能需求对应的功能称为“非功能性特征”。评估一个中间件软件，最主要的是看这个软件的功能，包括功能性特征和非功能性特征，是否符合我们的要求，或者符合大多数人的通常要求。

　　如果你知道某一种中间件软件的“标准功能”，你可以进一步把它分成“功能性的特征”和“非功能性特征”。如果你不知道，你只需从你的需求出发，研究一下你面前中间件的“功能性特征”和“非功能性特征”是否满足你的功能需求和非功能需求。

　　中间件是处于支撑地位的通用软件，其技术的标准化具有重要意义。中间件对技术标准的支持表现为使用标准的API、使用标准化的技术和实现标准化的功能等几个方面。中间件支持标准通常意味着用户和应用对厂商的依赖更小、应用开发人员学习使用一种新产品更容易，中间件软件可以和更多的系统互操作，技术更开放。因此，评估一个中间件不仅要看它是否具有某项功能，还要看这个功能是否使用了标准的技术。

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

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

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

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

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

　　非功能性特征是跨中间件的共性特性

　　软件的“非功能需求”是软件需求的重要方面。中间件软件的“非功能性特征”也是中间件功能的重要方面。事实上，中间件软件的非功能性特征是跨中间件种类的、非常重要的一般性特征，是中间件软件功能强大的表现。

　　我们这里采用了AberdeenGroup在2000年的《中间件——达成灵便的电子商务的技术基础》一文中对成功的中间件的共性特征的归纳（做了一点裁减）：

　　许多情况下，非功能性和功能性并非有严格的界线。比如，对于消息中间件来说，可靠传输一定是功能性的特征；对于其它的中间件未必如此；对于安全中间件来说，安全不能算作非功能性特征。

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

　　支持标准对于中间件必可缺少

　　面向消息的中间件一直以来缺乏技术标准/规范。自从J2EE制定出基于Java的Java消息传输服务（JMS）以后，人们对消息中间件的技术要求就有多了一项内容。相比较而言，事务处理监控程序（交易中间件）相关的技术规范就要多一些，主要是X/OPEN（现称为OPENGROUP）的分布式事务处理系列规范，包括TPM的架构、应用与TPM的接口及事务提交管理协议等重要内容。对于J2EE应用服务器，技术规范的影响就更大。我们甚至可以说，J2EE应用服务器的功能体现在了对技术标准和规范的支持上。

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

　　比如，X/OPEN DTP模型中定义的应用与TPM的接口就是妥协的结果。所谓“标准”就是两个厂家提交的完全不同的建议的罗列，两者完全不能互换。事实上也未见第三家厂商遵从上述的“标准”。这样的“标准”也只咎由自取参考意义。在看JMS，JMS当前规范只涉及一个消息服务器，规范只保证该服务器的客户方都使用一个一致的接口。如果厂商只是实现了JMS规范定义的内容，那么它就必不能支持服务器到服务器之间的可靠传输，其功能就会大打折扣。无论是用户还是中间件厂商，对标准都不应该迷信。

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