论文的题目是：Towards Dynamic Component Isolation in a Service Oriented Platform。

文章提供一种容错性较高的方法来动态的加载程序的组件，论文提供了一个初步的构想，并对未来的工作进行了展望。

为何要引入新的组件隔离机制：

随着构件式软件开发的发展，以往的构件开发方式存在了诸多缺点，比如：大多数的组件都是由第三方来开发的，这给组件带来了一定程度的不可控性，软件的主体是否对组件完全的信任是一个很重要的问题，因为组件可能对软件主体造成一定程度的影响，最为直接的就是组件的bug影响到整个程序的运行，造成程序的崩溃，这是我们很不愿意看到的。

此外，传统的组件隔离大多是基于Namespace的，这种方法只能逻辑上进行代码的分离，起不到内存和错误的隔离作用。而且如今的组件开发也面临了各种各样的软件环境，这给组件的测试带来了很大的困难，从而进一步增加了系统的不稳定性。

什么是OSGi：

OSGi技术是面向Java的动态模型系统。它提供允许应用程序使用精炼、可重用和可协作的组件构建的标准化原语。这些组件能够组装进一个应用和部署中。

简单的说，OSGi提供了一种实时的组件机制，组件可以被动态的添加、运行、停止和更新而不影响主程序的运行。

如今围绕OSGi的COTS市场正在逐步扩大，而COTS质量模型的不实用性也逐渐的体现出来。因为COTS质量模型需要组件的众多属性（成熟度、可恢复度和容错性），这些属性大多很难测量。

本篇文章为当今主流的组件隔离做出了总结，在此基础上提出了一种基于OSGi平台上的隔离机制。

Java标准隔离机制：

1、 Namespace-Based Isolation

基于命名空间的隔离是编写代码的常用的手段，在程序查找类或者函数时把命名空间也当做一个基本的标识属性，从而形成从函数到命名空间的一个向上的遍历来做到区分不同空间下的同名函数的问题。

但是这种隔离方法只起到了代码的隔离作用，对于组件中的错误并不能进行控制，也起不到隔离效果。

2、 OS-Based Isolation

OS-Based隔离机制是一种类似与多进程的隔离，它把程序分解到多个虚拟机上，从而提供了内存的隔离，不同虚拟机上的程序也互不影响。虽然单个进程的崩溃不会引起整个程序的问题，但是会带来程序的停滞，而组件的重新启动也会加重系统的资源消耗。

不同的进程间的通信使用Sockets或者RMI来实现。

3、 Domain Isolation

域隔离是一种细粒度的隔离方式，类似于多线程。它使用一个隔离容器和API来控制整个程序的生命周期。其中每个隔离的部分都是JVM的一个单独的实例。同样，被隔离的组件崩溃之后也不影响系统的运行，优势是域隔离的通信消耗低，可以有一套自己的资源访问机制、容错机制和一套clean application termination的机制。

Java组件隔离的应用：

Java组件隔离的应用有很多，不同类型的程序都会有使用，具体如下图：

论文中列出了7个例子，可以看出OS based和Domain based都提供了一定的容错性，并且他们大多使用Socket或者RMI方式来通信组合。

OSGi下的新隔离机制：

结合OSGi下无需重启加载组件的特性，使用一个组件管理中心对组件进行管理，各个组件以低耦合的方式结合，在代码上使用加强型的Namespace-Isolation，使类和方法可以交叉引用。Bundle（OSGi下的基本组件）的注销机制不会造成任何反作用。

新隔离机制的另外一个特点就是动态隔离，这里引入了一个sandbox来实现其功能。

程序被分为两个部分，主区域和隔离区，在主区域中只运行信任的组件，不信任的组件并不运行，不信任的组件和其依赖的组件运行在sandbox中，在sandbox中依赖组件并不运行，但却作为一份拷贝复制在sandbox里。不信任组件的崩溃只会造成sandbox的重新启动，对程序主体并没有影响。并且系统提供了一套组件由sandbox向主程序过度的机制。

组件间通信通过一个特殊的ServiceReference对象来完成，它的本质是通过代理来完成通讯，这无疑加重了系统的负担。

总结：

论文结合当今主流的组件隔离方式提出了一种基于sandbox的组件隔离方法，从而增强了系统的稳定性和健壮性，第三方组件对系统的影响只波及到sandbox。但是sandbox的引入也带来了一定的负面影响，加重了系统的通信负担。

对于使用sandbox的隔离方法，论文只是提出了构想，还有一些细节问题没有涉及，比如sandbox中的组件如何平稳过渡到主程序，而且在JVM中对于多个组件引入的sandbox的数量也是问题，还有sandbox组件的通信都是需要进一步研究的问题。