我对中间件的理解 Angels

面了一个实习，说道 我研究方向是大规模数据处理，分布式计算，hadoop 中间件，对方似乎对我说出中间件这个词很感兴趣直接问我我对中间件的理解，我还很少仔细思考这个问题，只好凭自己的理解说：中间件就是硬件操作系统和应用之间一个平台，可以屏蔽操作系统的异构性。

       一个完整的系统平台通常是由一组中间件集成在一起，包括开发平台和运行平台。这组中间件中一般都会至少一个通信中间件。中间件更多的是用在分布式系统中的一个概念。

中间件屏蔽了底层操作系统的复杂性，使得应用程序开发变得简单而统一。减少程序设计的复杂性（hadoop就是一个范例），将注意力集中在自己的业务上，不必再为程序在不同系统软件上移植而重复工作，大大减少了技术上的负担。中间件带给应用系统的，不只是开发的简单，开发周期的缩短，也减少了系统的维护，运行和管理的工作量，（这个在hadoop中没感觉到，直接写mpi的程序，运行也不需要什么额外的维护吧，可能hadoop的容错机制更健全可以认为符合这一点）。还减少了计算机总体费用的投入。

中间件为了解决分布异构的问题，这也是分布式计算系统比较困扰又不得不面对的一个问题。中间件提供标准的程序接口和协议，应用程序直接调用，或者更确切的说是中间件的服务进程调用应用程序接口完成一项任务。

一：中间件的特点

可以概括如下：

1.    满足大量应用的需求
2.   运行于多种硬件和OS平台
3.    支持分布计算，提供跨网络，硬件和OS平台的透明性的应用或服务
4.    支持标准的协议 互操作性
5.   支持标准接口 可移植性

      中间件成为许多标准化工作的主要部分。对于应用软件开发，中间件比操作系统和网络服务更为重要，中间件提供的程序接口定义了一个相对稳定的高层应用环境，不管底层的计算机硬件和系统软件怎样更新换代，只要将中间件升级更新，并保持中间件对外接口定义不变，应用软件几乎不需要任何修改，从而保护了企业在应用软件开发和维护中的重大投资。

二：中间件的分类

中间件必须要提供分布式环境下的通讯服务，我们将这种服务称之为平台，基于目的和实现机制不同，可以分为以下主要几类：

1. 远程过程调用（Remote Procedure Call） 　　
2. 面向消息的中间件（Message-Oriented Middleware） 　
3. 对象请求代理（Object Request Brokers）

他们的功能：

第一：向上提供不同形式的通讯服务，包括同步，排队，订阅发布，广播，在这些基本的通讯平台上，可以构筑各种框架，为应用程序提供不同领域内的服务，事务处理监控器，分布式事务访问，对象事务管理器OTM。

第二：中间件本身定义了相应领域内的应用的系统结构，标准的服务组件等，用户只需告诉框架所关心的事件，然后提供处理这些事件的代码。当事件发生时，框架则会调用用户的代码。用户不必调用框架，用户程序不关心框架的结构，执行流程，对系统api的调用，这些都有框架负责完成，因此基于中间件开发的应用具有良好的可扩充性，易管理性，高可用性和可移植性。

2.1 分类具体介绍：

        2.1.1 远程过程调用

远程过程调用是一种广泛使用的分布式应用程序处理方法。一个应用程序使用RPC来“远程”执行一个位于不同地址空间里的过程，并且从效果上看和执行本地调用相同。

     2.1.2 面向消息的中间件

      MOM指的是利用高效可靠的消息传递机制进行平台无关的数据交流，并基于数据通信来进行分布式系统的集成。通过提供消息传递和消息排队模型，它可在分布环 境下扩展进程间的通信，并支持多通讯协议、语言、应用程序、硬件和软件平台。目前流行的MOM中间件产品有IBM的MQSeries、BEA的 MessageQ等。

消息传递和排队技术有以下三个主要特点： 　　

1. 通讯程序可在不同的时间运行:程序不在网络上直接相互通话，而是间接地将消息放入消息队列，因为程序间没有直接的联系。所以它们不必同时运行。消息放入适当的队列时，目标程序甚至根本不需要正在运行；即使目标程序在运行，也不意味着要立即处理该消息。 　　
2. 对应用程序的结构没有约束:在复杂的应用场合中，通讯程序之间不仅可以是一对一的关系，还可以进行一对多和多对一方式，甚至是上述多种方式的组合。多种通讯方式的构造并没有增加应用程序的复杂性。 　　
3. 程序与网络复杂性相隔离: 程序将消息放入消息队列或从消息队列中取出消息来进行通讯，与此关联的全部活动，比如维护消息队列、维护程序和队列之间的关系、处理网络的重新启动和在网 络中移动消息等是MOM的任务，程序不直接与其它程序通话，并且它们不涉及网络通讯的复杂性。

     2.1.3 对象请求代理

     随着对象技术与分布式计算技术的发展，两者相互结合形成了分布对象计算，并发展为当今软件技术的主流方向。1990年底，对象管理集团OMG首次推出对 象管理结构OMA(Object Management Architecture)，对象请求代理（Object Request Broker）是这个模型的核心组件。它的作用在于提供一个通信框架，透明地在异构的分布计算环境中传递对象请求。CORBA规范包括了ORB的所有标准 接口。1991年推出的CORBA 1.1 定义了接口描述语言OMG IDL和支持Client/Server对象在具体的ORB上进行互操作的API。CORBA 2.0 规范描述的是不同厂商提供的ORB之间的互操作。 　　

     对象请求代理(ORB)是对象总线，它在CORBA规范中处于核心地位，定义异构环境下对象透 明地发送请求和接收响应的基本机制，是建立对象之间client/server关系的中间件。ORB使得对象可以透明地向其他对象发出请求或接受其他对象 的响应，这些对象可以位于本地也可以位于远程机器。ORB拦截请求调用，并负责找到可以实现请求的对象、传送参数、调用相应的方法、返回结果等。 client对象并不知道同server对象通讯、激活或存储server对象的机制，也不必知道server对象位于何处、它是用何种语言实现的、使用 什么操作系统或其他不属于对象接口的系统成分。 　　

    值得指出的是client和server角色只是用来协调对象之间的相互作用，根据相应的场 合，ORB上的对象可以是client，也可以是server，甚至兼有两者。当对象发出一个请求时，它是处于client角色；当它在接收请求时，它就 处于server角色。大部分的对象都是既扮演client角色又扮演server角色。另外由于ORB负责对象请求的传送和server的管 理，client和server之间并不直接连接，因此，与RPC所支持的单纯的Client/Server结构相比，ORB可以支持更加复杂的结构。

2.1.4 事务处理监控

    事务处理监控（Transaction processing monitors）最早出现在大型机上，为其提供支持大规模事务处理的可靠运行环境。随着分布计算技术的发展，分布应用系统对大规模的事务处理提出了需 求，比如商业活动中大量的关键事务处理。事务处理监控界于client和server之间，进行事务管理与协调、负载平衡、失败恢复等，以提高系统的整体 性能。它可以被看作是事务处理应用程序的“操作系统”。总体上来说，事务处理监控有以下功能： 　　

1. 进程管理，包括启动server进程、为其分配任务、监控其执行并对负载进行平衡。 　　
2. 事务管理，即保证在其监控下的事务处理的原子性、一致性、独立性和持久性。 　　
3. 通讯管理，为client和server之间提供了多种通讯机制，包括请求响应、会话、排队、订阅发布和广播等。 　　

     事务处理监控能够为大量的client提供服务，比如飞机定票系统。如果server为每一个 client都分配其所需要的资源的话，那server将不堪重负（如图2所示）。但实际上，在同一时刻并不是所有的client都需要请求服务，而一旦 某个client请求了服务，它希望得到快速的响应。事务处理监控在操作系统之上提供一组服务，对client请求进行管理并为其分配相应的服务进程，使 server在有限的系统资源下能够高效地为大规模的客户提供服务。

三：中间件的不足之处

      多数流行的中间件服务使用专有的API和专有的协议，使得应用建立于单一厂家的产品，来自不同厂家的实现很难互操作。有些中间件服务只提供一些平台的实 现，从而限制了应用在异构系统之间的移植。应用开发者在这些中间件服务之上建立自己的应用还要承担相当大的风险，随着技术的发展他们往往还需重写他们的系 统。尽管中间件服务提高了分布计算的抽象化程度，但应用开发者还需面临许多艰难的设计选择，例如，开发者还需决定分布应用在client方和server 方的功能分配。通常将表示服务放在client以方便使用显示设备，将数据服务放在server以靠近数据库，但也并非总是如此，何况其它应用功能如何分 配也是不容易确定的。