中间件的功能性特征是一种
中间件软件的基本特征。不同种类的
中间件的差异首先表现为基本功能的不同，因此我们不能总结出一套适合所有
中间件门类的、一般性的“功能性特征”。
对于某一个具体的
中间件软件，我们能够把它的功能性特征提取出来。我们假定某一
中间件定位于解决分步式环境中消息的发送者和接收者之间消息传输、管理和控制问题，该软件提供了多种消息交换方式、支持多种消息类型，提供可靠传输等服务质量控制机制，该软件支持多系统平台，支持高吞吐量的业务处理…。很显然，我们可以把“提供多种消息交换方式、支持多种消息类型，提供可靠传输等服务质量控制机制”看成是该
中间件的功能性特征，而把“支持高吞吐量的业务处理”作为非功能性的特征。
如果
中间件的选择者能够从自己的需求中归纳出对
中间件的“功能需求”，就可以把它们和面前的
中间件的功能性特征做一下对照。
功能性特征一般比较容易测试，因而也比较容易验证。
非功能性特征是跨
中间件的共性特性
软件的“非功能需求”是软件需求的重要方面。
中间件软件的“非功能性特征”也是
中间件功能的重要方面。事实上，
中间件软件的非功能性特征是跨
中间件种类的、非常重要的一般性特征，是
中间件软件功能强大的表现。
许多情况下，非功能性和功能性并非有严格的界线。比如，对于消息
中间件来说，可靠传输一定是功能性的特征；对于其它的
中间件未必如此；对于安全
中间件来说，安全不能算作非功能性特征。
非功能性特征一般比较难以测试，但仍然是一定程度可测试的。
支持标准对于
中间件必可缺少
面向消息的
中间件一直以来缺乏技术标准/规范。自从J2EE制定出基于Java的Java消息传输服务（JMS）以后，人们对消息
中间件的技术要求就有多了一项内容。相比较而言，事务处理监控程序（交易
中间件）相关的技术规范就要多一些，主要是X/OPEN（现称为OPENGROUP）的分布式事务处理系列规范，包括TPM的架构、应用与TPM的接口及事务提交管理协议等重要内容。对于J2EE
应用服务器，技术规范的影响就更大。我们甚至可以说，J2EE
应用服务器的功能体现在了对技术标准和规范的支持上。
标准/规范虽然重要，我们不可迷信，唯标准是从。因为，第一，“标准”可能仅是建议性的，并非所有的厂商都会遵守；第二，“标准”可能是妥协的结果，只是将提交的多个可选内容统统收入，各项内容甚至不能互换；第三，“标准”可能是不完整的，仅仅实现了标准要求的内容可能意味着欠缺重要的功能。
比如，X/OPEN DTP模型中定义的应用与TPM的接口就是妥协的结果。所谓“标准”就是两个厂家提交的完全不同的建议的罗列，两者完全不能互换。事实上也未见第三家厂商遵从上述的“标准”。这样的“标准”也只咎由自取参考意义。在看JMS，JMS当前规范只涉及一个消息服务器，规范只保证该服务器的客户方都使用一个一致的接口。如果厂商只是实现了JMS规范定义的内容，那么它就必不能支持服务器到服务器之间的可靠传输，其功能就会大打折扣。无论是用户还是
中间件厂商，对标准都不应该迷信。
中间件对标准的支持一般会体现在软件的功能性特征上，多数情况下是可测试和验证的。
【责任编辑：
董晶晶 TEL：（010）68479336-8024】
|
服 务 CIO 推 进 信 息 化 
