透明计算组件调研报告.docx
《透明计算组件调研报告.docx》由会员分享，可在线阅读，更多相关《透明计算组件调研报告.docx（78页珍藏版）》请在冰豆网上搜索。
透明计算组件调研报告
透明计算组件调研报告
清华大学
第1章背景资料
1.1背景
信息技术的发展在当前阶段有以下几个趋势：
一是计算模式多种多样，它从集中式的单一节点的巨型机运算，发展到个人的台式计算机，再到internet上分布式个人机与台式机的混合运算，目前P2P，GRID技术正在蓬勃的发展之中；伴随着计算模式发展的数字媒体技术，通讯技术等等将计算机应用带入一个新的领域，理所当然的应用程序也包含了多种多样的计算模式。
第二，计算设备的体积不断减小。
从摩尔定律诞生以来，计算速度一直按照这个规律增长，另外一个特征就是计算设备的体积越来越小。
它带来的一个好处就是计算为中心的计算逐渐转变为以人为中心的计算；当今一个手持设备的计算能力就与30年前的大型机相当。
在以上两个背景下，透明计算这一新兴研究领域得到了蓬勃发展。
它强调的是计算无处不在，以人为中心，重视任何时间任何地点的按需服务。
它将计算从人坐在屏幕前的模式带到一个更广阔更激动人心的空间。
透明计算环境以手机、PDA、智能家电、智能数码产品以及其他嵌入式设备为代表，其主要特征是：
v硬件设备异构，硬件配置各不相同；
v运算能力小，系统资源有限；
v外部环境和内部资源变化剧烈；
v大都具有联网能力，网络协议各不相同；
v安全性要求高，强调稳定性。
为了适应以上环境的需求，新的应用软件平台应该具有以下特征：
1软件需要实现自描述，以达到即插即用，减少人机交互的复杂度，这包括硬件驱动的即插即用；
2具有动态可配置性，因为应用程序所处环境变化剧烈，需要支持在不同网络环境，不同用电量支持，不同硬件支持的情景下提供不同质量的服务。
3需要实现环境感知和策略驱动，以提供自适应服务，使用户能够透明的享受到计算的乐趣。
本报告调研面向透明计算[1][2]环境下构件和中间件技术。
以灵活构件加载技术、元数据实现构件自描述、反射式中间件技术为重要特征，设计一个中间件系统原型，实现动态可配置，自适应服务，环境感知，策略驱动等特性，从而适应透明计算环境的特殊需求。
通过对该中间件研究和评价，为进一步深入研究适合于透明计算的操作系统打下基础。
本报告主要从应用需求出发，对系统的架构进行了较为广泛的研究，并针对研究的结果，设计出一个了原型系统，进行实际评测，作为下一步工作的基础。
1.2该领域研究状况和进展
透明计算是在各种新型的非传统PC计算设备将越来越多地互联在迅猛发展的计算机网络上、并全面渗透到社会生活中去的背景下提出的全新计算模式。
当前透明计算研究主要侧重在一个网络环境内多模态交互技术和面向透明计算的操作系统体系结构和支持多设备互联的软硬件体系结构等方面。
面向透明计算环境的软件平台研究目前主要分为三大方面，一方面侧重在面向透明计算环境的中间件基础构架和总体结构的研究与实现，包括MIT的Oxygen、Stanford大学的InteractiveWokspaces、CMU的Aura和RoSES、UCBerkeley的Ninja；另一方面侧重在面向透明计算环境的底层操作系统方面的研究与实现，主要包括UIUC的2K[14]，UniversityofCalifornia的AgentOS、贝尔实验室的Pebble、Cornell大学的MagnetOS；还有一方面是侧重面向透明计算环境的具体应用的研究，如清华大学计算机系提出的智能教室，UIUC的ActiveSpace等。
这三方面紧密结合，相互影响，共同促进透明计算的研究。
传统的面向嵌入式系统的操作系统和中间件平台，并不把动态灵活地适应透明计算环境作为主要的实现目标，不能主动地根据环境的具体情况调整自身情况，在保证完成环境需求的情况下，同时达到消耗设备的资源（内存资源、CPU资源、电源、持久存储资源等）最小[44][45]。
在透明计算环境中，并不把操作系统性能最强和功能最多作为唯一目标，而对操作系统的要求是及时满足变化的环境需求，在保证性能的情况下，消耗的总体资源最小。
而这方面正是构件件化软件平台的优势，基于构件思想的操作系统体系和中间件平台结构具有功能构件的主动查找，灵活加载等优点，使得它成为最适合透明计算环境的操作系统体系结构之一，并成为国内外系统软件领域研究的热点。
反射式中间件是一种实现了系统反射机制的中间件系统。
通过实现反射机制，反射中间件可以克服传统中间件系统的单一性和不灵活性，从而可以更好的支持新的应用领域。
反射式中间件具有良好的自省的能力；具有在运行期间对构件进行自我调整的能力；并且有在运行期间对构件进行自我重新配置的能力，可以修改系统的执行状态，或根据环境重新解释自己的行为。
这些优点意味着对于系统环境和应用模式具有非常灵活的适应能力。
另一方面，基于反射式中间件技术的体系结构能够很自然地分开考虑功能部分和非功能部分，以充分体现中间件介于系统和应用之间的桥梁作用。
基于此，基于构件平台的反射式中间件技术从90年代开始逐渐被人们所重视，并应用于普氏计算领域。
初期人们比较关心的的工作是如何在系统级实现计算反射，如何构建反射模型，设计元数据与元协议以达到自省和建立系统表象与元数据的关联，这方面比较突出的工作有UIUC的DynamicTao，Lancaster的OpenORB等等。
90年代中后期，反射失中间件得主要应用场景是透明计算与移动计算领域，后来发展到P2P，GRID，可编程网络等目前研究的热点领域，其主要提供的方案也集中在需要动态配置，提供自适应服务的方面。
所以如何利用反射的特点在运行时提供动态调整的能力，以及提供策略驱动服务使得对中间件的动态配置不需要人为的干预根据系统运行时的情况自动地进行等成为研究重点，相关的研究项目有：
LegORB、UIC、Chisel、CARISMA、ReMMoC、GRIDKIT、NETKIT等。
目前主要的中间件技术几乎都具有不同程度的“自描述”能力，但现有的技术还没有一个系统的完整的解决方案来实现分层和可变分辨率的自描述体系；为了更好地支持中间件的自适应性，需要从下层的构件平台开始扩展和改进，特别是对元数据增加“自描述”语义和反射性描述，使中间件达到开放性、可配置性和可重配置性要求的体系结构，而这方面的工作也很不足。
同时如何在中间件管理层具体实现调整或修改构件应用所描述行为的状态和相关的语义，也是一个要解决的技术难点。
第2章反射概念以及反射式中间件平台的综述
2.1反射的由来
在逻辑学中，反射是一种扩展理论的方法；在基于逻辑的推理系统中，反射被用来描述理论和元理论之间的关系。
上世纪70年代末，反射的概念被研究程序设计语言的学者引入到计算机领域中来。
在一些早期的程序设计语言，包括：
基于过程的程序设计语言，如3-LISP和BROWN，基于规则的程序设计语言，如TEIRISIAS和SOAR以及基于逻辑的程序设计语言，如FOL和META-PROLOG的设计中，反射的概念都得到了体现。
1982年，MIT的B.C.Smith在他的博士报告[36]中最早介绍了程序反射（proceduralreflection）的概念并提出了反射假说：
“既然我们可以构造一个包含了负责管理有关某个外部世界的表示的内部过程的计算过程，并通过这个计算过程来对那个外部世界进行推理；那么同样的，我们也可以构造一个能对自身进行推理的计算过程，它含有一个负责管理有关它自身的操作和结构的表示的内部过程。
”也就是说，借助反射，一个计算过程就能够访问、推理并改变有关其自身的表示。
Smith在他的报告中还介绍了他设计的反射式语言3-LISP。
1987年，PattieMaes在前人工作的基础上系统地阐述了计算反射和反射系统的概念，并介绍了她设计的面向对象的反射式语言3-KRS[29]。
Maes给出的计算反射的定义如下：
计算反射简称反射，是反射系统在运行过程中所做的有关系统自身的计算和控制。
“计算系统”，是指负责解决某个领域中的问题并能对这个领域进行作用的基于计算机的系统；每一个计算系统都是“针对”某个特定的领域的，系统中包括了用来描述这个领域中的实体和实体间的关系的数据结构以及处理这些数据结构的规则。
计算反射就是反射系统的一种行为。
这里所说的“反射系统”是一个特殊的计算系统。
反射系统的特别之处在于，它所“针对”的那个领域就是这个系统本身，而且系统中用于描述系统的数据结构和系统本身之间存在着“因果联系”。
也就是说，如果有关系统的描述发生了某种改变，那么系统本身必定发生了与这种改变相符的改变；反之，如果系统本生发生了某种改变，那么有关系统的描述也必定会发生与这种改变相符的改变。
在反射系统中，用于描述系统本身的数据结构被称为系统的自描述信息，它是实现反射的基础。
反射系统就是通过维护正确的系统自描述信息来达到在运行时对系统的行为进行监视以及根据环境和应用程序的需要对系统进行重新配置的目的的。
2.2基本概念介绍
一般来说，反射系统在逻辑上采用的两层结构：
基础层（base-level）和元层（meta–level）；基础层和元层通过具体化（Reification）和吸收（Absorption）这两个过程相关联。
基础层：
完成的是有关外部领域的计算，或者说它实现系统对外提供的计算功能，这是任何计算系统都需要完成的计算,简称基层；
元层：
完成关于系统自身的计算，也就是只有反射系统才需要完成的计算。
具体化过程（Reification）[6,26,37]是指对基础层的一些特性进行抽象，并用元层中的实体来对其进行描述的过程。
元层应该向用户提供接口，使得用户能够访问和修改元层中实体的状态，这些接口称为元接口（Meta-interface）。
吸收过程（Absorption）[6,26,36]是具体化的反过程，它根据用户对于元层中实体的状态所作的修改来调整基础层中相应的特性，从而使基础层的特性能够和元层中实体的状态保持一致，即通过对元层数据的修改影响到基层的状态。
具体化和吸收实现了系统和有关系统的表示之间的因果联系。
2.3计算反射的应用
计算反射的最初应用也是目前一个比较广泛的应用是在编程语言中。
1991年MIT的GregorKiczales第一次比较详细的在《TheArtoftheMetaobjectProtocol》一书中阐述了元对象协议（MetaobjectProtocol）[23]，这是是反射技术和面向对象的方法相结合的产物。
“元对象协议”中的“对象”是指使用面向对象的方法来描述元层中的实体，即将元层中的实体表示为面向对象的系统中的对象，也就是元对象（Metaobject）。
而对于基础层是否使用面向对象的方法来描述，元对象协议则不做要求。
元对象所对应的类称为元类（Metaclass）。
元对象协议是一个系统中的元对象向系统的用户所提供的接口的总和。
通常，一个元对象协议中至少应该包括两类接口：
访问（Introspection）接口和调整（Intercession）接口。
通过访问接口，系统的用户可以获取系统的状态信息；通过调整接口，系统的用户能够按照实际的需求调整系统中的一些策略，从而改变系统的行为。
程序设计语言通过提供反射机制，可以有效的提高用这种语言开发的软件系统的灵活性和可扩展性。
在Java中，系统提供的java.lang.reflect包实现了反射机制，其中包含了可以用来在运行时检查类的结构并分析数据字段的实际内容的类[39]，函数如下所示：
反射功能函数
作用
Field[]getFields（）;
Field[]getDeclaredFields（）
通过获得字段（filed）信息，可以获得一个类的运行时内部变量信息，根据这些信息做出一些不同的相应或采取不同策略，同时，我们也可以运行时的修改一个类的变量信息；
Method[]getMethods（）;
Method[]getDeclaredMethods（）
通过获得方法信息，我们可以动态的调用一个我们原来不知道参数类型甚至方法名的方法，实现函数指针。
Constructor[]getConstructors（）;
ConstructorgetConstructor（Class[]argumentTypes）
通过获得构造器的信息，我们可以动态生成一个类。
C#也提供了对反射的支持，它提供了完善的metadata来描述软件模块自身的信息，metadata包含以下几张表
Table名称
包含内容
CommonDefinitionMetadataTable
包含Module中定义的最基本的信息：
包含Module的入口，类的入口，每个类中函数的入口等等
CommonReferenceMetadataTable
包含该Module对其他Module，类以及函数及域的依赖关系
ManifestMetadataTables
描述Assembly包含的文件和资源信息，实现自描述
它通过定义在System.Reflection名字空间中的一组类来在运行时对元数据的访问；通过反射可以动态获取一个模块的内容，实现动态调用，实时序列化并保存程序运行时状态，实时数据安全性监测，例如对函数输入的参数类型的检测，以及实现垃圾回收机制等等。
除了程序设计语言以外，反射在计算机科学的其他领域中也得到了越来越多的关注，如：
操作系统[40]、分布式系统[1,38]、文件系统[28]、软件工程[8]和数据库[18]等。
2.4反射式中间件中的基本概念
反射式中间件的定义：
反射式中间件是一种特殊的计算系统，它包含自描述信息，并且提供了对自描述信息的访问机制，而且这种自描述信息和中间件的实例之间存在着因果联系（CausalConnection）[26,29],即中间件的运行时状态和它的自描述信息应该始终是一致的。
因此，外界就可以通过访问中间件的自描述信息来获取中间件的信息，也可以通过修改中间件的自描述信息来对中间件进行定制和调整。
这样，反射式中间件和传统的中间件相比就更加灵活，而且能够适应动态变化的环境。
自描述的信息一般被称为元数据（metadata），在反射式中间件的领域，元数据与语言级的反射相比有其自身的特点：
动态性（Dynamical）：
一般来说，语言级的反射描述的主要是编译时得到的静态信息，如类的结构，函数的参数等等，这些信息一经确定不会改变；中间件的元信息一般强调实时性和动态性，它一般是一种运行时的状态的描述或表象，需要运行时获取数据。
自适应性（Adaptive）：
对于程序设计语言级的反射一般需要的功能是“introspection”，即内省，察看内部信息而不需要改变其内容；反射式中间件需要的更多是Adaptation，即根据环境和用户的需要自适应动作，更强调元数据与系统内部状态的动态关联，即通过元协议完成对系统内部信息状态的探察和更改，以使系统实现更优服务。
依据反射的对象，也就是元层中的实体所对应的基础层的特性，可以将反射分为结构反射（StructuralReflection）和行为反射（BehavioralReflection）。
结构反射[26]的对象是基础层中的结构信息。
对于语言级别的内容来说，它包含基础层中包含的数据结构、使用的数据类型、对象之间的继承关系和接口的内容等；对于系统级别的结构反射，会提供更多的体系结构的信息，例如构成系统的基础构件，构件间的连结体等等。
通过结构反射，平台使用者可以直接获取系统的内部结构和功能信息，通过改变系统结构和其组成构件的功能来改变系统得对外行为。
行为反射的对象是基础层中语义方面的信息，它向外提供有关系统内部运行时状态的运行环境的信息。
语言级的比较常见的例子是对到达的调用信息的察看与改变，例如CORBA的Interceptor（拦截函数）和Java的动态proxy，通过这种机制，实现对程序功能的运行时监测和调整，加入一些非功能性（non-functional）行为，例如安全性检查和并发控制；系统级别的行为反射通过定制、获取和修改系统的运行时策略来实现，它可以影响系统资源管理进而影响系统对外的表现行为。
结构反射和行为反射有些时候是相关联的，例如一些系统的行为改变是通过结构改变引起的，所以并不能完全区分这两种反射机制；对于一个具体的反射系统来说，可以只实现结构反射或者行为反射，也可以同时实现这两种反射[22]。
2.5反射式中间件的研究和对比
有关反射式中间件的研究始于上世纪九十年代后期，初期的研究主要关注的问题放在如何构造反射式中间件的模型，如何实现结构反射和行为反射，如何定制元协议以建立元数据和系统的状态之间的逻辑关系等，其研究成果多为模型系统。
但随着近年来透明计算和移动计算等新兴研究领域的繁荣，反射式中间件逐渐找到了其应用场景并发展完善；到今天，反射式中间件的研究已经渗透到各个领域，例如PeertoPeer系统，网格计算，可编程网络等等。
下面几节的内容主要按照时间顺序介绍反射式中间件的几个里程碑式的成果，几种重要的设计理念。
2.5.1DynamicTao和LegORB
UIUC的dynamicTAO[25]是一个支持动态配置的符合CORBA规范的反射式中间件，也是最早的反射式中间件平台。
它基于TAO，通过增加配置器（Configurators）和挂钩（Hooks）来获取中间件自身结构信息并提供对中间件的运行时动态配置。
具体来说，每个运行dynamicTAO的进程中都包括一个域配置器（DomainConfigurator）的实例，它负责维护本进程中对象请求代理之间、对象请求代理和对象的实现（Servants）之间的依赖关系，依赖信息用类DependencySpecification来刻画。
DependencySpecification包含两个重要的域，分别为hookname和configurator的引用，可以通过hookname得到相应的configurator。
每个对象请求代理中保存了一个TAO配置器（TAOConfigurator）的实例，如图所示，它负责管理一组策略实现的构件，这些策略包括：
并发策略，安全策略，调度策略和监视策略等。
如果一个客户程序使用了一种策略，该TAO配置器负责把该客户程序信息记载到相应策略实现的构件中，即加上钩子；同时该配置器的指针也被加入到客户程序依赖列表中。
这样中间件平台就可以通过配置器中存储的信息获取整个中间件平台的运行时信息，同时也可以修改运行时状态：
在运行时替换某一策略的具体实现来实现对中间件的动态配置，如将线程池策略换成每来一个请求单独起一个线程来服务的策略。
dynamicTAO还引入了动态配置代理，它能够根据给定的动态配置拓扑图和配置策略自动完成对网络中的一组节点的重新配置，从而大大减轻了系统管理员的负担。
图21DynamicTao的配置器模型
LegORB[33]是UIUC在dynamicTAO的基础之上开发的面向透明计算环境的反射式中间件，遵循所需即所得和简单的设计原则。
为了适应透明计算环境中资源有限的计算设备，LegORB一方面尽可能的简化了dynamicTAO中各个构件的接口和实现，另一方面采用了一种类似微内核的体系结构，内核中只包括一些必需的功能，如确保CORBA的互操作性和允许用户对中间件定制等。
LegORB的内核有三部分组成：
LegORB配置器、客户端配置器和服务器端配置器。
其中，客户端配置器和服务器端配置器可以根据实际需要分别或者同时挂接到LegORB配置器上，而且，它们又可以分别挂接六类不同的构件。
这样，实际得到的LegORB的体积就由挂接构件的多少，即所需功能的多少来决定。
2.5.2OPENORB、ReMMoC和CARISMA
图22OPENORB的元空间模型
1998年，英国Lancaster大学分布式媒体研究组的G.S.Blair等人在以往研究的基础上提出了一个与具体语言无关的反射式中间件的模型[2]，由于这个中间件模型符合CORBA规范，而且具有可配置和开放的特点，所以后来被命名为OpenORB。
在OpenORB中，每个对象都拥有独立的元空间；每元空间由三个互相独立的元空间模型构成。
这三个独立的原空间模型分别是Encapsulation模型，Composition模型和Environment模型。
Composition元模型包含了与该
对象相关联的其他对象的信息，即构成了一张对象图（objectgraph）;Environment模型包括每个接口的运行时环境信息，例如在一个分布式系统中，一个接口的运行时环境信息包括消息的到来，排队，筛选，分发，列集散集等等，由一些系统函数来提供访问这些信息的接口；Encapsulation（Behaviour）模型提供了获取接口内部信息的手段，内部信息包括函数信息，参数信息，内部结构和域信息。
这三个元模型互相可以嵌套使用，例如Composition（Environment（object）），刻画了构成object运行时环境的对象视图，使用这种方式可以动态插入一些对象提供非功能性服务，例如插入Monitor查看某一层元空间的对象视图。
OpenORB提供了一个比较理想的中间件反射模型，但是由于它过于理想化，带来的效率开销和实现上的困难使他很难进入应用领域。
Blair等人进而提出了基于构件框架来构造元空间的思想，OpenORB的原型是用Python语言实现的。
在这个原型的基础上，Blair等人对原来的设计进行了修改，提出了一个更为完善的反射式中间件的模型OpenORB2[2]，并用C＋＋实现了这个新的模型。
OpenORB2的实现基于OpenCOM[10]，后者是一个借鉴了COM的核心思想，同时提供了对反射的支持的轻量级的构件模型。
OpenORB2沿用了OpenORB的多模型元空间的设计，但是对元空间的内容和结构进行了调整。
新的元空间包括四类元模型：
体系结构元模型、接口元模型、拦截元模型和资源元模型。
其中，每个构件拥有独立的体系结构元模型和接口元模型，每个接口拥有独立的拦截元模型，而每个地址空间拥有独立的资源元模型。
OpenORB2采用了分层结构，中间件从总体上来说分为三层，由下至上依次为：
资源层、通信层和绑定层。
其中，每一层都包括若干个构件框架，每个构件框架负责提供某种特定的服务。
例如：
资源层包括缓冲区管理、传输和线程管理三个构件框架，它们负责提供相应的服务。
图2-3REMMOC的构件框架模型
ReMMoC[17]是一个面向移动计算环境的反射式中间件，它着眼于解决运行在移动设备的客户端应用程序如何发现用不同服务发现协议来发布的应用服务，以及如何与基于不同的中间件平台开发的应用服务进行互操作的问题。
和OpenORB相似，ReMMoC也是基于OpenCOM的构件模型；但是和OpenORB相比，ReMMoC更突出了构件框架（ComponentFramework，简称CF）的概念，因为它本身就是由一组构件和构件框架组成的。
构件框架是指用于规定一组构件之间的交互方式的规则和约定，在ReMMoC中就是一个由一组构件组成的用于提供某种服务的复合构件。
既然CF也是一个OpenCOM构件,则它也实现OpenCOM的所有基本接口：
IMetaInterface（获取其他接口内部信息），ILifeCycle（生命周期管理）和IConnections（主要负责接收其他构件的服务）；并且它的内部包含了一张用于表示这组构件之间的依赖关系的图，每个构件框架对外提供ICFMetaArchitecture接口，外界元素可以通过这个接口来查看和调整构件框架的具体配置。
为了在调整构件框架的配置时确保其完整性，每个构件框架都提供了IAccept插槽，用于挂接提供完整性验证的构件。
此外，为了协调可能同时产生的多个查看构件框架
升级会员 