中间件的基本概念

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

tomcat服务器的工作原理可以概括为以下几点：

1、Tomcat是运行在JVM中的一个进程。它定义为“中间件”，顾名思义是一个在Java项目与JVM之间的中间容器。

2、Web项目的本质，是一大堆的资源文件和方法。Web项目没有入口方法（即main方法），这意味着Web项目中的方法不会自动运行起来。

Web项目部署进Tomcat的webapp中的目的是很明确的，那就是希望Tomcat去调用写好的方法去为客户端返回需要的资源和数据。

3、Tomcat可以运行起来，并调用写好的方法。那么，Tomcat一定有一个main方法。对于Tomcat而言，它并不知道用户会有什么样的方法，这些都只是在项目被部署进webapp下后才确定的。

由此，可知Tomcat用到了Java的反射来实现类的动态加载、实例化、获取方法、调用方法。但是部署到Tomcat的中的Web项目必须是按照规定好的接口来进行编写，以便进行调用。

扩展资料：

tomcat服务器的特点：

Tomcat运行时占用的系统资源小，扩展性好，支持负载均衡与邮件服务等开发应用系统常用的功能。Tomcat是一个开源的web服务器，且是一个小型的轻量级应用服务器，在中小型系统和并发访问用户不是很多的场合下被普遍使用，是开发和调试JSP程序的首选。

对于一个初学者来说，可以这样认为，当在一台机器上配置好Apache服务器，可利用它响应对HTML页面的访问请求。实际上Tomcat部分是Apache服务器的扩展，所以当你运行tomcat时，它实际上作为一个Apache独立的进程单独运行的。

当配置正确时，Apache为HTML页面服务，而Tomcat实际上运行JSP页面和Servlet。另外，Tomcat和IIS、Apache等Web服务器一样，具有处理HTML页面的功能，另外它还是一个Servlet和JSP容器，独立的Servlet容器是Tomcat的默认模式。

参考资料来源：百度百科-tomcat

这其实是一个比较虚的概念。广义的中间件范围很广。起沟通作用的都可以认为是中间件。甚至ODBC这样的东西你也可以认为是中间件。
现在用的比较多的中间件应该是BEA公司的tuxedo和IBM公司的weblogic（好象是这个东西），我接触过一点tuxedo。oracle、sun和ms好象也有类似产品，不过用的人很少。tuxedo是这个领域的领导者，不过IBM正在追赶并有可能超过，毕竟，IBM就是IBM。
tuxedo这东西我们用来做数据库和前台应用之间的中间件。
使用了中间件之后，以前直接连接的前台应用程序和数据库之前就多了个tuxedo，现在前台程序把请求发给tuxedo，tuxedo再把请求发给数据库，数据库处理结束之后把结果返回tuxedo，tuxedo再把结果送回给前台。这样一搞，表面看复杂了很多。不过带来一些好处，比如：
安全。tuxedo的服务是定制的，这就有点象是存贮过程，因为应用程序无法直接接到数据库而只能通过tuxedo，所以应用程序无法做tuxedo服务之外的事情。你把你的应用逻辑写在tuxedo中，你就可以保证你的数据是安全的。
性能。有些数据库性能不好，比如oracle一个连接就是好多M，连接数一多，机器内存就没了，有了tuxedo之后，tuxedo负责连接数据库，连接数比较少，tuxedo可以用排队的方式来处理这些数据库请求，这样提高了性能。中间件的高级应用好象还可以把数据库分布在不同的机器上，由tuxedo动态分配前、后台的请求和处理，把它们搞在不同的机器上，所以你用了中间件之后如果后台数据库处理来不及，可以加一台机器，前台请求太多（比如网站）可以加多前台机器。你可以灵活的调整性能。
方便移植。业务逻辑做到了中间件里之后，你更换后台数据库、改变前台的开发工具什么的移植工作较小，因为中间件的工作改动不大。

应用服务器做的人好象就更多了。而且应用服务器这东西和中间件类似（逻辑上）我觉得它应用也是中间件的一种，不过大家一般说中间件都是指的狭义的中间件，就是tuxedo这些。

中间件应用领域很广的。简直大一点的应用都可以用到中间件。国内也有一些开发商自己写中间件，不过好象是自己用，没形成市场。

满足大量应用的需要 ；
运行于多种硬件和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等，但从分类上不知道怎么归类，向上不能够划归应用，往下又不能归入 *** 作系统，于是就把它归入了中间件，如此中间件的概念更加扩大了。市场上对于中间件，各家的说法不一，客观上也导致了理解上的复杂性。

---