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系统集成插件说明xml结构

扩展插件定义

所以新开发的扩展插件，均放在同一的目录下进行管理，插件管理模块会自动去该目录下进行搜索查找。插件目录结构如下所示：

图 2扩展插件说明xml结构

1.2.3.    插件的注册

　　Spoon在启动的时候会对所有插件进行注册，并保存在PluginRegistry类里面。平台通过查找PluginRegistry注册表获取插件信息。Kettle安装插件需要进行重启，卸载插件也只需简单的删除plugins目录结构下对应的文件即可。

图 2plugin注册相关的UML类图

　　PluginRegistry首选注册本系统的插件类型处理类，源码中注册了7中类型，我们这里仅介绍3中，并以StepPluginType为例。注册类型处理类后，PluginRegistry按照不同的类型进行插件搜索（模板模式），基类BasePluginType提供了本地搜索、jar搜索、xml信息搜索3种钩子。根据搜索结果，按照不同的插件类型存储在PluginRegistry中。

1.2.4.    插件查找

　　PluginRegistry提供了插件查找功能，准确的来说是插件信息的查找功能。以steps在左侧功能栏里面的显示为例，进行插件查找的说明。提供了getPlugins获取指定插件类型列表、getPlugin获取指定成名插件、getCateories获取目录结构、getClass获取指定插件类等方法。

图 2spoon界面step插件显示流程

1.2.5.    插件调用

　　Kettle中调用插件时，平台通过元素管理引擎获取对应的插件信息，通过反射生成插件对象，调用对应的函数。Kettle以外观模式的方式调用插件，我们以双击某个插件图表，弹出对应配置界面为例进行说明，具体的转换时调用将在后面进一步说明。

　　Spoon界面交互相关的处理器都封装到SpoonDelegates中，根据不同的事件类型调用对应的事件处理函数。UML类图如下所示。

图 20 双击编辑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类主要属性

来源：问题不大，礼多人不怪