中间件简介

中间件 & 可适应中间件

1. 中间件概述

随着网络和软件技术的飞速发展，软件面临更多的问题，例如：不同的操作系统、不同的网络环境等。在每个软件中解决这些问题加大了软件开发人员的负担，因此倾向于将这些具有广泛应用的共性功能提取出来，从而避免了重复开发，并可以使这些功能模块更专业、更稳定、更高效可靠。这些被提取出来的模块的功能主要是一类业务，不像操作系统那样具有普遍的应用能力，因此将其称为 中间件 。

中间件是处于操作系统之上，应用程序之下的软件。它隐藏了计算机体系结构、操
作系统、编程语言和网络技术等方面的异构性，为上层的应用程序提供运行与开发的环境，帮助用户灵活、高效地开发和集成复杂的应用系统。

上图是中间件在分布式系统中的位置。目前，中间件己经成为网络环境下大型复杂应用系统构建和运行的核心基础支撑软件，很多大型的商业信息系统、任务关键系统都是在中间件平台上运行。

2. 可适应中间件

传统的中间件为上层应用程序隐藏了底层的异构性。但是，一些新的应用如果能够知道底层环境的细节并随之做出相应的调整，会得到更好的效果。因此，要求中间件能够根据外界环境的改变而变化，并使得应用程序能够控制和改变中间件，这样的中间件称为可适应中间件。

根据可适应中间件提供调整的时间将可适应中间件划分为 静态可适应中间件 和 动态可适应中间件。

• 静态可适应中间件在应用程序编译或者启动时刻进行调整，静态可适应中间件可以进一步划分为
  • 可定制中间件，在应用程序编译时刻进行调整。
  • 可配置中间件，在启动时刻进行调整。
• 动态可适应中间件在应用程序 运行过程 中进行调整。动态可适应中间件可以进一步划分为
  • 可协调中间件，在应用程序的被使用前进行调整。
  • 可变中间件，在应用程序的被使用后进行调整。

目前己经有很多种动态可适应中间件，其中，最主要的两类是反射式中间件和面向方面中间件，分别在中间件中使用了 反射技术 和 面向方面编程技术。

2.1 反射式中间件

反射式中间件在传统中间件的技术上引入了反射技术使得中间件能够动态地进行变化。

2.1.1 反射计算的概念

计算系统用来感知世界的一部分并基于此进行一些动作，计算系统与此部分因果连接（causal connection），即一方的改变将直接影响另一方。元系统（meta-system）是指将另一个计算系统当成领域的计算系统，作为领域的计算系统称为目标系统。反射是指计算系统能感知并操控自身的能力，而反射系统是指以自身为目标系统的元系统，反射系统对自身进行的感知和操控称为反射计算。

由此观点可以看出，一个反射系统由两个部分组成：

• 对系统的问题域进行建模并对其进行推理和操纵的部分；
• 对系统自身建模并对其进行推理和操纵，使系统能够适应某些变化。

从实现角度看，这两部分采用同样的实现机制，第一部分称为“基础层”，第二部分称为“元层”。基础层和元层之间具有因果联系。

2.1.2 DynamicTAO

DynamicTAO 是一个能够动态配置并符合 CORBA 规范的反射式中间件，也是最早的反射式中间件。它复用现有的 TAO，TAO 是一个基于面向对象设计模式的可迁移的、灵活的、可扩展的、可配置的对象请求代理（ORB）。DynamicTAO 注重于在 TAO 上增加反射特性，通过增加配置器和挂钩来获取中间件自身结构信息并提供对中间件的运行时动态配置。使用 策略设计模式 将 ORB 内部引擎分成多个不同的方面。配置文件用于指明 ORB 中用来实现并发、请求分发等方面的策略。在 ORB 启动时刻，配置文件呗解析，相应的策略呗加载。

DynamicTAO 通过 构建配置器 的集合来实现具体化。一个构件配置器保持了一个特定的构件与系统中其他构件的依赖关系。每个运行 DynamicTAO 的进程都包含一个域配置器（DomainConfigurator），负责维护在进程中对象请求代理之间、对象请求代理和对象的实现（Servants）之间的依赖关系。每个对象请求代理包含了一个定制的构建配置器交错 TAOConfigurator，负责管理一组策略实现的构件，这些策略包括：并发策略、调度策略、安全策略和监控策略。如果客户程序使用了一种策略，TAOConfigurator 将该程序信息记载道相应的策略实现的构件中，同时该配置器的指针也加到客户程序的依赖列表中。这样 DynamicTAO 可以通过构建配置器中存储的信息获得整个中间件平台的运行信息，同时也可以修改运行时的状态。DynamicTAO 还引入了动态配置代理，它能够根据给定的动态配置拓扑图和配置策略，自动完成对网络中各个节点的重新配置。

上图为 DynamicTAO 的具体化结构。 DynamicTAO 使用 TAOConfigurator 解决对象请求代理的一致性。通过对构件配置器中存储的依赖关系进行分析，判断是否能够进行动态配置。使用策略新实现构件替换旧实现构件时，需要保证旧实现构件己经不再被任何客户程序使用，并且以后不会被需要使用，同时需要将旧实现中的一些信息迁移到新实现中。采用的版本控制机制是：允许同一时间同一个策略在内存中有两个不同的实现。每次构件加载进来时，赋一个版本号给该构件，引用该构件的实现通过版本号和构件名称。版本号也用来标识哪个实现是最新的，当没有引用指向旧版本时，旧版本被回收。

2.1.3 OpenORB

OpenORB 符合 CORBA 的规范，但是它不像 DynamicTAO，它是从头开始设计的一种新颖的中间件体系结构。OpenORB 体系结构在运行时刻将构件作为可标识的实体保存。将元层和基础层明确区分，通过反射实现动态重配置。基础层包含实现通常中间件服务的构件；元层包含暴露这些实现给程序员的反射机制，实现检查和自适应。元层的结构使用与基础层相同的构件模型，所以反射也可以用作元层的检查和自适应。元层的构件包含了一个平台的因果关联的自表示（self-representation），并且和一个基本层的构件相关。在 OpenORB 中每个构件都有自己的元空间，每个元空间由四个相互独立的元空间模型构成：接口元模型、体系结构元模型、栏截器元模型和资源元模型，其中接口元模型和体系结构元模型属于结构反射，栏截器元模型和资源元模型属于行为反射。

其中接口元模型、体系结构元模型和栏截器元模型针属于构件相关，资源元模型属于平台相关。每个构件拥有独立的接口元模型和体系结构元模型，每个接口拥有独立的栏截器元模型，而每个地址空间拥有独立的资源元模型。

2.1.3.1 接口元模型

提供对构件的外在表示的访问。构件的外在表示指的是构件提供和要求的接口。通过接口元模型可以动态检查构件提供的服务。

2.1.3.2 体系结构元模型

将构件看作一个软件体系结构，关注构件的内部实现。包括两个方面：表示一个构件中构件之间关系的构件图和一组体系结构限制，体系结构限制定义了使构建集有效的规则。检查和自适应软件的体系结构，即添加和替换构件以及修改体系结构限制。

构件图可以是递归的，例如构件图中的构件含有 architecture 元空间模型。递归在原始构件中终止，即原始构件没有可见的底层结构，程序员不能访问其内部实现细节。

2.1.3.3 拦截器元模型

以拦截器的形式增加方法的预处理和后期处理。

2.1.3.4 资源元模型

提供对底层资源和资源管理器的访问。通过增加删除资源和修改管理资源的算法的参数。资源元模型提供对表示资源管理的构件的访问，检查和自适应域资源有关的行为。

2.2 面向方面的中间件

面向方面编程（ Aspect Oriented Programming ）是面向对象编程（ Object Oriented Programming ）的补充和完善。面向方面编程是一种关注分离的技术，系统不同的关注能够分离并单独设计，可以解决面向对象变成难以解决的复杂问题。面向方面编程允许用不同的维度来分解软件系统，软件开发者可以使用垂直分解过程建立中间件的基本分解模型。然后，在不改变现有结构的基础上，使用面向方面技术，将需要的实现正交添加到基本模型上。

2.2.1 AspectIX

AspectIX 是一个 CORBA 兼容的中间件体系结构，它通过使用碎片对象模型（ Fragmented Object Model ）使 QoS 代码从系统的功能代码中分离出来。

碎片对象模型如上图所示。片段对象模型允许一个分布式对象被分成若干哥碎片（ fragment ），碎片分布在多个节点或者地址空间中。分布式对象的语义由所有的碎片实现，因此碎片之间需要相互通信。一个碎片由碎片接口和碎片实现组成，碎片接口隐藏了碎片的实现细节，客户端通过碎片接口与分布式对象进行交互。与分布式对象交互的客户端，在它的地址空间里由一个本地碎片。

AspectIX 将非功能性的需求，例如实时性、可靠性、一致性等，设计成方面。每个碎片实现包含了一组方面配置。通过方面配置可以启用活停用某个方面。对于方面，可以使用特定的配置对象进行配置。

当客户绑定到一个分布式对象时，它将获得对象在本地地址空间的碎片。客户端通过碎片接口检查该对象支持哪一种服务质量配置，还可以创建一些描述它自己需求的方面配置对象，然后将这个配置发送给对象。对象收到请求后，进行如下操作：

1. 检查当前的碎片实现是否能够满足需求，如果可以，返回接受请求；
2. 否则，检査碎片实现仓库，寻找可以满足需求的碎片实现，如果能够找到这样的碎片实现，返回接受请求；
3. 否则，拒绝客户端的配置请求。

2.3 JBoss

Sun 为了推动 Java 服务器端 应用的开发，在年底推出了技术及相关的规范。在 J2EE 应用服务器领域，JBoss 是应用最广泛的应用服务器。由于 JBoss 遵循 LGPL 授权分发，并且是一个开源项目，这使得 JBoss 广为流行。JBoss 为基于 Java 的软件开发提供了高质量、高性能和高扩展性的中间件平台。

2.3.1 JBoss 结构

JBoss 作为 Java 程序，首先需要运行在 Java 虚拟机上，同时，作为 Java 中间件，它又为上层的应用提供了开发平台。 JBoss 作为中间件，不再像传统的中间件那样，作为一个整体运行，而是由多个构件组成，除了必须部署的微内核外，其他的服务根据需要像构件一样部署到内核上。因此，JBoss 是高度模块化和松耦合的。JBoss 作为 web 应用服务器时，在 JBoss 的微内核上部署 JBoss web 服务及相关服务，就可以运行 web 应用。

JBoss 微内核提供了一个配置和管理 POJO 的环境，可以更好地支持扩展性在服务器环境下需要的主要方面。

• JBoss 微内核主要由 Container 、 Dependency 、 Kernel 、 AOP-MC-int 和 Spring-int 模块构成，其中 Kernel 模块定义了内核的核心操作，包括内核的启动、配置、部署 POJO 等；
• Container 模块主要定义了连接点，用于在运行时刻对类进行操作；
• Dependency 模块用于确保依赖关系被满足；
• AOP-MC-int 模块用于集成 JBossAOP 和 MC ；
• Spring-Int 模块使得 Spring 模型能够用在微内核上。 其中 Kernel 是微内核的核心。