1. 插件体系结构
1.1. 插件技术原理
1.1.1. 插件概念说明
插件是一种遵循统一的预定义接口规范编写出来的程序，应用程序在运行时通过接口规范对插件进行调用，以扩展应用程序的功能。在英文中插件通常称为plug-in、plugin或者plug in。插件最典型的例子是Eclipse开发平台，Microsoft的ActiveX控件和COM（Component Object Model，部件对象模型）实际上ActiveX控件不过是一个更高继承层次的COM而已。此外还有Photoshop的滤镜（Filter）也是一种比较常见的插件，还有就是Mozilla Firefox，Foobar等等也遵循着插件机制。
插件最吸引人的地方当然就是其所实现“运行时(Run-time)”功能扩展。这意味着软件开发者可以通过公布插件的预定义接口规范，从而允许第三方的软件开发者通过开发插件对软件的功能进行扩展，而无需对整个程序代码进行重新编译。运行时是相对于编译时(Assembly-time)而言的。一般来说，软件开发者对软件功能更新时，是在源代码级别进行更新，然后对整个程序进行重新编译，进而发布应用程序的新版本，这就是编译时的软件更新。
插件的本质在于不修改程序主体（或者程序运行平台）的情况下对软件功能进行扩展与加强，当插件的接口公开后，任何公司或个人都可以制作自己的插件来解决一些操作上的不便或增加新的功能，也就是实现真正意义上的“即插即用”软件开发。“平台+插件软件结构”是将一个待开发的目标软件分为两部分，一部分为程序的主体或主框架，可定义为平台，另一部分为功能扩展或补充模块，可定义为插件。
在进行软件开发之前，是否采用“平台+插件软件结构”进行软件开发，还要依据具体的软件需求情况进行确定，但一般来讲，使用“平台+插件软件结构”进行软件设计会给所开发软件增加新的生命力。当确定“平台+插件的软件结构”之后，就要分析哪些部分功能由主体完成（即平台的基本功能），哪些部分功能由插件完成（即需要扩展的插件功能）。平台所完成的功能应为一个软件系统的核心和基础，这些基本功能即可为用户使用，也可为插件使用，就是又可以把平台基本功能分为两个部分，内核功能和插件处理功能。平台的内核功能是整个软件的重要功能，一个软件的大部分功能因由内核功能完成。平台的插件处理功能用于扩展平台和管理插件，为插件操纵平台和与插件通信提供标准平台扩展接口。插件所完成的功能是对平台功能的扩展与补充，一般插件完成系列化功能。
为了实现平台+插件结构的软件设计需要定义两个标准接口，一个为由平台所实现的平台扩展接口，一个为插件所实现的插件接口。这里需要说明的是：平台扩展接口完全由平台实现，插件只是调用和使用，插件接口完全由插件实现，平台也只是调用和使用。平台扩展接口实现插件向平台方向的单向通信，插件通过平台扩展接口可获取主框架的各种资源和数据，可包括各种系统句柄，程序内部数据以及内存分配等。插件接口为平台向插件方向的单向通信，平台通过插件接口调用插件所实现的功能，读取插件处理数据等。
平台插件处理功能包括插件注册、管理和调用，以及平台扩展接口的功能实现。插件注册为按照某种机制首先在系统中搜索已安装插件，之后将搜索到的插件注册到平台上，并在平台上生成相应的调用机制，这包括菜单选项、工具栏、内部调用等。插件管理完成插件与平台的协调，为各插件在平台上生成管理信息以及进行插件的状态跟踪。插件调用为调用各插件所实现的功能。平台插件处理功能实现的另一部分功能为平台扩展接口的具体实现。
1.1.2. 插件接口的认识
开发支持插件功能的应用程序必须解决一个问题：如何在主程序与插件间正确地互相通信。为了在主程序与插件之间能正确地互相通信，应该先制定一套通信标准，这套通信标准就是接口，主程序与插件只能通过制订好的接口进行通信。软件开发中，接口只是定义功能并规定调用功能的形式，而不包含功能的实现。接口实质上是软件模块的调用规范。在后续章节中我们将会介绍kettle开发的插件中，常用的几种通讯方式。
就开发支持插件功能的应用程序而言，一般来说由主程序的开发者来制订接口，如果希望其他的开发人员能开发相关的插件，只要公开相关接口即可。接口功能一般由插件方实现。因为插件的实现也要调用主程序的功能，所以接口功能也可能由主程序来实现。也就是说，主程序与插件的信息流可能是双向的。
接口的调用规范与功能实现互相分离有一个很大的优点：尽管不同的插件开发者对同一个接口的具体实现不同，但是在主程序中对这些插件的调用方式是一样的。如果有主程序实现的接口，在不同的插件中也可以用相同的使用方式调用主程序的功能。这极大的提高了应用程序的灵活性。
1.1.3. 程序结构及其运行机制
主程序中，插件管理部分用于管理插件的安装和删除，并将所有安装插件的信息保存到适合的地方，例如保存到注册表或配置文件中。主程序启动时，根据插件的配置信息加载插件模块，然后获得插件的输出函数或输出类的指针并加以保存，如果需要的话，可以向主程序增加界面接口元素，如菜单、工具条按钮等。在主程序中当点击与插件相关联的接口元素时，就会触发插件调用函数，在插件调用函数中使用主函数中所保存的插件信息调用插件中实现的功能。在调用插件输出函数时也可以把主程序中实现的接口传递给插件方。
1.2. Kettle体系结构
图 2‑1 Kettle插件架构
Kettle分为kettle平台、各类插件。其中kettle平台是整个系统的基础，包括UI、插件管理、元数据管理和数据集成引擎。UI显示Spoon这个核心组件的界面，通过xul实现菜单栏、工具栏的定制化，显示插件界面接口元素。元数据管理引擎管理ktr、kjb或者元数据库，插件通过该引擎获取基本信息。插件管理引擎主要负责插件的注册。数据集成引擎负责调用插件，并返回相应信息。
1.2.1. 插件扩展机制
Kettle是众多“可供插入的地方”（扩展点）和“可以插入的东西”（扩展）共同组成的集合体。在我们的生活中，电源接线板就是一种“扩展点”，很多“扩展”（也就是电线插头）可以插在它上面。
在Kettle中不管是以后的扩展还是系统集成的功能，本质上来讲都是插件，管理方式和运行机制是一致的。系统集成的功能点也均实现了对应的扩展接口，只是在插接的说明上略有不同。
Kettle的扩展点包括step插件、job entry插件、Database插件、Partioner插件、debugging插件，这里我们重点介绍step、job entry、database插件。暴露的扩展点如下表所示：
表 1 Step扩展接口
|
Java接口 |
基类 |
主要功能 |
|
StepMetaInterface |
BaseStepMeta |
存储step设置信息 验证step设置信息 序列化step设置信息 提供获取step类的方法 |
|
StepDialogInterface |
BaseStepDialog |
step属性信息配置窗口 |
|
StepInterface |
BaseStep |
处理rows |
|
StepDataInterface |
BaseStepData |
为数据处理提高数据存储 |
表 2 job entry扩展接口
|
Java接口 |
基类 |
主要功能 |
|
JobEntryInterface |
JobEntryBase |
存储job entry设置信息 序列化job entry设置信息 提供获取job entry类的方法 执行job entry任务 |
|
JobEntryDialogInterface |
JobEntryDialog |
job entry属性信息配置窗口 |
表 3 Database 扩展接口
|
Java接口 |
基类 |
主要功能 |
|
DatabaseInterface |
BaseDatabaseMeta |
访问各类数据库 |
1.2.2. 插件的建立
Kettle中的插件包含两部分，一是系统本身就已经实现的功能点，在源码目录src中说明，如kettle-steps.xml；二是系统之外开发的插件，在plugins目录对应插件目录下的plugins.xml说明，plugins/steps/S3CsvInput/plugins.xml。
系统集成插件定义（step为例）
表 4 系统自带插件定义
|
内容 |
位置 |
|
插件说明信息 |
src/kettle-steps.xml，所有插件集中说明 |
|
插件源码 |
src与src-ui下，org.pentaho.di.steps.插件名 |
|
插件图片 |
插件说明xml中说明 |
|
插件界面文字说明 |
org.pentaho.di.steps.插件名.messages |
插件说明信息中包括描述信息、类名（包括package，反射用）、父级目录（Spoon左侧栏目录）、提示信息和图片信息。Kettle使用国家化方式编程，所以软件中的所有文字描述均由messages_**.properties提供。
图 2‑2 系统集成插件说明xml结构
扩展插件定义
所以新开发的扩展插件，均放在同一的目录下进行管理，插件管理模块会自动去该目录下进行搜索查找。插件目录结构如下所示：
图 2‑3 扩展插件目录结构
表 5 扩展插件定义
|
内容 |
位置 |
|
插件说明信息 |
plugins/插件类型/插件名称/plugin.xml |
|
插件源码 |
*.jar |
|
插件图片 |
plugins/插件类型/插件名称/ |
|
插件依赖包 |
plugins/插件类型/插件名称/ |
扩展插件与系统集成插件的说明内容相似，扩展插件增加ID属性和依赖属性，同时他的目录结构、描述信息和提示信息均能进行国际化配置。
图 2‑4 扩展插件说明xml结构
1.2.3. 插件的注册
Spoon在启动的时候会对所有插件进行注册，并保存在PluginRegistry类里面。平台通过查找PluginRegistry注册表获取插件信息。Kettle安装插件需要进行重启，卸载插件也只需简单的删除plugins目录结构下对应的文件即可。
图 2‑5 插件注册时序图
图 2‑6 plugin注册相关的UML类图
PluginRegistry首选注册本系统的插件类型处理类，源码中注册了7中类型，我们这里仅介绍3中，并以StepPluginType为例。注册类型处理类后，PluginRegistry按照不同的类型进行插件搜索（模板模式），基类BasePluginType提供了本地搜索、jar搜索、xml信息搜索3种钩子。根据搜索结果，按照不同的插件类型存储在PluginRegistry中。
1.2.4. 插件查找
PluginRegistry提供了插件查找功能，准确的来说是插件信息的查找功能。以steps在左侧功能栏里面的显示为例，进行插件查找的说明。提供了getPlugins获取指定插件类型列表、getPlugin获取指定成名插件、getCateories获取目录结构、getClass获取指定插件类等方法。
图 2‑7 Spoon中step列表
左侧显示由Spoon.refreshCoreObjects（）函数实现，如果选择时trans相关的内容，将显示所有的step插件。流程图如下所示：
图 2‑8 spoon界面step插件显示流程
1.2.5. 插件调用
Kettle中调用插件时，平台通过元素管理引擎获取对应的插件信息，通过反射生成插件对象，调用对应的函数。Kettle以外观模式的方式调用插件，我们以双击某个插件图表，弹出对应配置界面为例进行说明，具体的转换时调用将在后面进一步说明。
Spoon界面交互相关的处理器都封装到SpoonDelegates中，根据不同的事件类型调用对应的事件处理函数。UML类图如下所示。
图 2‑9 事件代理类
SpoonStepsDelegate提供了与UI交互相关的处理事件，如复制、删除、粘贴、编辑等。双击某个step时会调用编辑功能，编辑功能是对插件StepDialogInterface的封装。时序图如下：
图 2‑10 双击编辑step时序图
双击是TransGraph对象注册的时间，双击是根据页面上的坐标信息获取双击的stepmeta对象（来自于*.ktr）。然后，将这个对象传给事件代理类处理，根据stepmeta对象，获取对应的插件类名，通过反射生成StepDialogInterface的实例并调用open（）方法。
1.2.6. 插件间通信
Kettle插件之间天生就具有通信共享数据的特点，kettle中最主要通信方式是通过插件时间共同关联一个数据类对象的方式进行通信；使用单例模式实现插件间信息共享。
第一种方式还设计多线程同步的问题，在后面的章节中将会进行重点介绍。
1.2.7. 插件生命周期
Kettle并不能做到热插拔，每次添加或者删除插件的时候都需要重启。安装或删除插件，只需要在plugins文件夹下添加或删除对应的文件即可。
2. 平台体系结构
2.1. 元数据管理引擎
元数据主要包括转换元数据（.ktr）和Job元数据(.kjb)，元数据也可以存储在数据库中，这里我们主要介绍文件存储形式的。
元数据管理类包括TransMeta，该类定义了一个转换（对应一个.ktr文件），提供了保存和加载该文件的方法；JobMeta类，同样对应于一个工作(.kjb文件)，提供保存和加载方法。StepMeta类保存的是Step的一些公共信息的类，每个类的具体的元数据将保存在显示了StepMetaInterface的类里面。
两个类中主要保存的信息如下：
代码 1 TransMeta类主要属性
1 private List<StepMeta> steps; 2 3 private List<TransHopMeta> hops; 4 5 private String name; 6 7 private Result previousResult;//上一个jobentry的执行结果。 8 9 private List<RowMetaAndData> ;//resultRows;这次trans执行后的数据结果。 10 11 private List<ResultFile> resultFiles;
steps字段对应于.ktr中的<step>节点，hops字段对应于<hop>节点。resultRows、previousResult实际上是插件见的通信类。
代码 2 JobMeta类主要属性
1 protected String name; 2 3 protected String filename; 4 5 public List<JobEntryInterface> jobentries;//保存jobentry列表 6 7 public List<JobHopMeta> jobhops;//保存jobentries之间的链接关系。 8 9 public List<DatabaseMeta> databases;
2.2. UI显示
2.2.1. TransGraph类
图 3‑1 TransGraph类与显示
选中转换标签后，红框内的编辑区对象对应org.pentaho.di.ui.spoon.trans包中的TransGraph类。
2.2.2. JobGraph类
图 3‑2 JobGraph与显示
选中Job标签后，红框内的编辑区对象对应org.pentaho.di.ui.spoon.job包中的JobGraph类。
2.3. 转换执行引擎
2.3.1. Trans类
Trans类负责转换执行相关的所有任务，包括转换加载、相关插件的实例化、初始化、运行、监视转换执行，并把内容放置到TransInfo类中。
2.3.2. StepInitThread类
Step初始化线程包装类，使用多线程，调用所有StepInterface实现类的Init函数。
2.3.3. StepMetaDataCombi类
把插件的主要实现类全部存储在这个类中，方便集中调用。
1 public class StepMetaDataCombi 2 3 { 4 5 public StepMeta stepMeta; 6 7 public String stepname; 8 9 public int copy; 10 11 public StepInterface step; 12 13 public StepMetaInterface meta; 14 15 public StepDataInterface data; 16 17 }
2.3.4. RunThread类
步骤处理线程包装类，这个类能够处理异常并将其记录到日志中。同时，也能够在异常发生或者执行结束后，记录相关内容、关闭相关资源。
2.4. Job执行引擎
2.4.1. Job类
Job的执行类，本身实现了Thread是一个单独的线程。Job entry可以是单独的线程，也可以是顺序执行，大多数情况都是顺序执行下一步以上一步的执行结果为基础。Job类也包括转换加载、相关插件的实例化、初始化、运行、监视Job执行。