介于应用系统和系统软件之间的一类软件,它使用系统软件所提供的基础服务(功能),衔接网络上应用系统的各个部分或不同的应用,能够达到资源共享、功能共享的目的。
中间件为一种独立的系统软件服务程序,分布式应用软件借助这种软件在不同的技术之间共享资源,中间件位于客户机服务器的 *** 作系统之上,管理计算资源和网络通信。从这个意义上可以用一个等式来表示中间件:中间件=平台+通信,这也就限定了只有用于分布式系统中才能叫中间件,同时也把它与支撑软件和实用软件区分开来。
扩展资料
中间件技术创建在对应用软件部分常用功能的抽象上,将常用且重要的过程调用、分布式组件、消息队列、事务、安全、链接器、商业流程、网络并发、>
在商业中间件及信息化市场主要存在微软阵营、Java阵营、开源阵营。阵营的区分主要体现在对下层 *** 作系统的选择以及对上层组件标准的制订。主流商业 *** 作系统主要来自Unix、苹果公司和Linux的系统以及微软视窗系列。
参考资料来源:百度百科-wipi
参考资料来源:百度百科-中间件
中间件的主要作用和功能:它使用系统软件所提供的基础服务(功能),衔接网络上应用系统的各个部分或不同的应用,能够达到资源共享、功能共享的目的。
中间件在 *** 作系统、网络和数据库之上,应用软件的下层,总的作用是为处于自己上层的应用软件提供运行与开发的环境,帮助用户灵活、高效地开发和集成复杂的应用软件。
中间件独立的系统软件或服务程序,分布式应用软件借助这种软件在不同的技术之间共享资源,中间件位于客户机服务器的 *** 作系统之上,管理计算资源和网络通信。
中间件应用
1、中间件与电子商务的整合。
Intemet是电子商务发展的基础,让商户可以通过它,把商业扩展到能到达的任意地点。这其中离不开大量的信息传输,而电子商务则使用了浏览器/服务器B/S()的技术来达到大量数据处理的目的。
2、中间件在B/S模式中的架构。
中间件在B/S模式下起到了功能层的作用。当用户从WEB界面向服务器提交了数据请求或者应用请求时,功能层负责将这些请求分类为数据或应用请求,再向数据库发出数据交换申请。
数据库对请求进行筛选处理之后,再将所需的数据通过功能层传递回到用户端。通过如此处理,单一用户可以进行点对面的 *** 作,无需通过其他软件进行数据转换。
评估中间件掌握方法是关键要选择一个技术上符合要求的中间件既要了解自己的需求,还得能对一个中间件软件作出技术上的评估
我们这里不谈如何了解您的需求,只谈如何对中间件做技术上的评估
随着中间件的广泛应用,最终用户和应用开发商时常面临这个问题
中间件的种类越来越多,单一产品的功能特性又越来越丰富,如果不得要领,就会陷入到无尽的细节之中
因此,掌握方法就非常重要
选择中间件当然不能只关注技术,必须考虑厂商实力、提供的服务、价格等相关因素,但技术上是否满足需要无疑是位居第一位的
以同类中间件的“标准功能”作为参考你完全可以从你的具体需求出发,看看这个软件是否适用,或者好不好
如果你知道你要评估的这一类中间件软件通常具有的功能——我们称它是“标准功能”——你就有了一个可作为参考的依据
你可以看一看你面前的中间件有没有这些“标准功能”,如果没有,是否对你有重要的影响
把握功能需求、非功能需求与技术标准三个方面我们在设计一个软件时,可以把对软件的需求划分成功能需求和非功能需求
功能需求指明软件必须执行的功能,定义系统的行为——即软件在某种输入条件下要给出确定的输出必须做的处理或转换
功能需求通常是软件功能的“硬指标”——如“支持分布式环境中消息的可靠传输”;非功能需求不描述软件做什么,描述软件如何做
非功能需求通常作为软件设计的“软指标”——如“系统具有可伸缩性”
为此,我们可以把功能需求对应的功能称为“功能性特征”,把非功能需求对应的功能称为“非功能性特征”
评估一个中间件软件,最主要的是看这个软件的功能,包括功能性特征和非功能性特征,是否符合我们的要求,或者符合大多数人的通常要求
如果你知道某一种中间件软件的“标准功能”,你可以进一步把它分成“功能性的特征”和“非功能性特征”
如果你不知道,你只需从你的需求出发,研究一下你面前中间件的“功能性特征”和“非功能性特征”是否满足你的功能需求和非功能需求
中间件是处于支撑地位的通用软件,其技术的标准化具有重要意义
中间件对技术标准的支持表现为使用标准的API、使用标准化的技术和实现标准化的功能等几个方面
中间件支持标准通常意味着用户和应用对厂商的依赖更小、应用开发人员学习使用一种新产品更容易,中间件软件可以和更多的系统互 *** 作,技术更开放
因此,评估一个中间件不仅要看它是否具有某项功能,还要看这个功能是否使用了标准的技术
功能性特征是中间件的基本特征中间件的功能性特征是一种中间件软件的基本特征
不同种类的中间件的差异首先表现为基本功能的不同,因此我们不能总结出一套适合所有中间件门类的、一般性的“功能性特征”
对于某一个具体的中间件软件,我们能够把它的功能性特征提取出来
我们假定某一中间件定位于解决分步式环境中消息的发送者和接收者之间消息传输、管理和控制问题,该软件提供了多种消息交换方式、支持多种消息类型,提供可靠传输等服务质量控制机制,该软件支持多系统平台,支持高吞吐量的业务处理很显然,我们可以把“提供多种消息交换方式、支持多种消息类型,提供可靠传输等服务质量控制机制”看成是该中间件的功能性特征,而把“支持高吞吐量的业务处理”作为非功能性的特征
如果中间件的选择者能够从自己的需求中归纳出对中间件的“功能需求”,就可以把它们和面前的中间件的功能性特征做一下对照
功能性特征一般比较容易测试,因而也比较容易验证
非功能性特征是跨中间件的共性特性软件的“非功能需求”是软件需求的重要方面
中间件软件的“非功能性特征”也是中间件功能的重要方面
事实上,中间件软件的非功能性特征是跨中间件种类的、非常重要的一般性特征,是中间件软件功能强大的表现
我们这里采用了在2000年的《中间件——达成灵便的电子商务的技术基础》一文中对成功的中间件的共性特征的归纳(做了一点裁减):许多情况下,非功能性和功能性并非有严格的界线
比如,对于消息中间件来说,可靠传输一定是功能性的特征;对于其它的中间件未必如此;对于安全中间件来说,安全不能算作非功能性特征
非功能性特征一般比较难以测试,但仍然是一定程度可测试的
支持标准对于中间件必可缺少面向消息的中间件一直以来缺乏技术标准/规范
自从J2EE制定出基于Java的Java消息传输服务(JMS)以后,人们对消息中间件的技术要求就有多了一项内容
相比较而言,事务处理监控程序(交易中间件)相关的技术规范就要多一些,主要是X/OPEN(现称为OPENGROUP)的分布式事务处理系列规范,包括TPM的架构、应用与TPM的接口及事务提交管理协议等重要内容
对于J2EE应用服务器,技术规范的影响就更大
我们甚至可以说,J2EE应用服务器的功能体现在了对技术标准和规范的支持上
标准/规范虽然重要,我们不可迷信,唯标准是从
因为,第一,“标准”可能仅是建议性的,并非所有的厂商都会遵守;第二,“标准”可能是妥协的结果,只是将提交的多个可选内容统统收入,各项内容甚至不能互换;第三,“标准”可能是不完整的,仅仅实现了标准要求的内容可能意味着欠缺重要的功能
比如,X/OPENDTP模型中定义的应用与TPM的接口就是妥协的结果
所谓“标准”就是两个厂家提交的完全不同的建议的罗列,两者完全不能互换
事实上也未见第三家厂商遵从上述的“标准”
这样的“标准”也只咎由自取参考意义
在看JMS,JMS当前规范只涉及一个消息服务器,规范只保证该服务器的客户方都使用一个一致的接口
如果厂商只是实现了JMS规范定义的内容,那么它就必不能支持服务器到服务器之间的可靠传输,其功能就会大打折扣
无论是用户还是中间件厂商,对标准都不应该迷信
中间件对标准的支持一般会体现在软件的功能性特征上,多数情况下是可测试和验证的
欢迎分享,转载请注明来源:内存溢出
评论列表(0条)