如何从技术上选择中间件

1、如何从技术上选择中间件评估中间件把握方法是关键要选择一个技术上符合要求的中间件既要了解自己的需求，还得能对一个中间件软件作由技术上的评估。我们这里不谈如何了解您的需求，只谈如何对中间件做技术上的评估。随着中间件的广泛应用，最终用户和应用开发商时常面临这个问题。中间件的种类越来越多，单一产品的功能特性又越来越丰富，假如不得要领，就会陷入到无尽的细节之中。 因此，把握方法就特别重要。选择中间件当然不能只关注技术，必需考虑厂商实力、 供应的服务、价格等相关因素，但技术上是否满意需要无疑是位居第 一位的。以同类中间件的“标准功能”作为参考你完全可以从你的详细需求动身，看看这个软件是否适用， 或者好不好

2、。假如你知道你要评估的这一类中间件软件通常具有 的功能一一我们称它是“标准功能”一一你就有了一个可作为 参考的依据。你可以看一看你面前的中间件有没有这些“标准功能”，假如没有，是否对你有重要的影响。各种中间件软件的“标准功能”是什么？对于这个问题没有 标准和肯定的答案，但可以有多数人或多数厂家可以接受的答案， 你不妨以之作为参考。 假如找不到现成的， 你也可以自己试着去 归纳。向各个厂家要一下产品的介绍材料，做一下比较。“标准功能”通常包含在产品的共性功能中。把握功能需求、非功能需求与技术标准三个方面我们在设计一个软件时，可以把对软件的需求划分成功能需 求和非功能需求。功能需求指明软件必需执行

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

4、" 。假如你不知 道，你只需从你的需求动身， 研究一下你面前中间件的 “功能性 特征”和“非功能性特征”是否满意你的功能需求和非功能需求。中间件是处于支撑地位的通用软件，其技术的标准化具有重要意义。中间件对技术标准的支持表现为使用标准的API、使用标准化的技术和实现标准化的功能等几个方面。中间件支持标准通常意味着用户和应用对厂商的依靠更小、应用开发人员学习使用一种新产品更简单， 中间件软件可以和更多的系统互操作，技术更开放。因此，评估一个中间件不仅要看它是否具有莫项功能， 还要看这个功能是否使用了标准的技术。功能性特征是中间件的基本特征中间件的功能性特征是一种中间件软件的基本特征。

5、不同种 类的中间件的差异首先表现为基本功能的不同， 因此我们不能总 结由一套适合全部中间件门类的、一般性的“功能性特征”。对于莫一个详细的中间件软件，我们能够把它的功能性特征提取由来。我们假定莫一中间件定位于解决分步式环境中消息的 发送者和接收者之间消息传输、管理和掌握问题，该软件供应了 多种消息交换方式、支持多种消息类型，供应牢靠传输等服务质 量掌握机制，该软件支持多系统平台，支持高吞吐量的业务处 理很明显，我们可以把“供应多种消息交换方式、支持多种 消息类型，供应牢靠传输等服务质量掌握机制”看成是该中间件的功能性特征，而把“支持高吞吐量的业务处理”作为非功能性的特征。假如中间件的选择者能够

6、从自己的需求中归纳由对中间件 的“功能需求”，就可以把它们和面前的中间件的功能性特征做 一下对照。功能性特征一般比较简单测试，因而也比较简单验证。非功能性特征是跨中间件的共性特性软件的“非功能需求”是软件需求的重要方面。中间件软件 的“非功能性特征”也是中间件功能的重要方面。事实上，中间 件软件的非功能性特征是跨中间件种类的、特别重要的一般性特征，是中间件软件功能强大的表现。NextPage我们这里采用了 AberdeenGroup 在2000年的中间件一 一达成灵活的电子商务的技术基础一文中对成功的中间件的共性特征的归纳（做了一点裁减）：很多状况下，非功能性和功能性并非有严格的界线。比如，

7、对于消息中间件来说， 牢靠传输一定是功能性的特征； 对于其它 的中间件未必如此；对于安全中间件来说， 安全不能算作非功能 性特征。非功能性特征一般比较难以测试，但仍旧是一定程度可测试支持标准对于中间件必可缺少面向消息的中间件一直以来缺乏技术标准/规范。自从J2EE制定由基于Java的Java消息传输服务（JMS）以后，人们对消 息中间件的技术要求就有多了一项内容。相比较而言，事务处理监控程序（交易中间件）相关的技术规范就要多一些，主要是 X/OPEN （现称为 OPENGROUP ）的分布式事务处理系列规范， 包括TPM的架构、应用与 TPM的接口及事务提交管理协议等 重要内容。对于J2EE应

8、用服务器，技术规范的影响就更大。我 们甚至可以说，J2EE应用服务器的功能体现在了对技术标准和 规范的支持上。标准/规范虽然重要，我们不可迷信，唯标准是从。因为， 第一，“标准”可能仅是建议性的，并非全部的厂商都会遵守； 第二，“标准”可能是妥协的结果，只是将提交的多个可选内容 统统收入，各项内容甚至不能互换；第三，“标准”可能是不完整的，仅仅实现了标准要求的内容可能意味着欠缺重要的功能。比如，X/OPEN DTP 模型中定义的应用与 TPM 的接口就是 妥协的结果。所谓“标准” 就是两个厂家提交的完全不同的建议 的排列，两者完全不能互换。事实上也未见第三家厂商遵从上述 的“标准”。这样的“标准”也只咎由自取参考意义。 在看JMS ,JMS当前规范只涉及一个消息服务器，规范只保证该服务器的客户方都