Kettle 体系架构

Kettle 体系架构

 

1 .  插件体系结构

1.1  插件接口的认识

开发支持插件功能的应用程序必须解决一个问题:如何在主程序与插件间正确地互相通信。为了在主程序与插件之间能正确地互相通信,应该先制定一套通信标准,这套通信标准就是接口,主程序与插件只能通过制订好的接口进行通信。软件开发中,接口只是定义功能并规定调用功能的形式,而不包含功能的实现。接口实质上是软件模块的调用规范。在后续章节中我们将会介绍kettle开发的插件中,常用的几种通讯方式。

 就开发支持插件功能的应用程序而言,一般来说由主程序的开发者来制订接口,如果希望其他的开发人员能开发相关的插件,只要公开相关接口即可。接口功能一般由插件方实现。因为插件的实现也要调用主程序的功能,所以接口功能也可能由主程序来实现。也就是说,主程序与插件的信息流可能是双向的。

 接口的调用规范与功能实现互相分离有一个很大的优点:尽管不同的插件开发者对同一个接口的具体实现不同,但是在主程序中对这些插件的调用方式是一样的。如果有主程序实现的接口,在不同的插件中也可以用相同的使用方式调用主程序的功能。这极大的提高了应用程序的灵活性。

1.2  程序结构及其运行机制

主程序中,插件管理部分用于管理插件的安装和删除,并将所有安装插件的信息保存到适合的地方,例如保存到注册表或配置文件中。主程序启动时,根据插件的配置信息加载插件模块,然后获得插件的输出函数或输出类的指针并加以保存,如果需要的话,可以向主程序增加界面接口元素,如菜单、工具条按钮等。在主程序中当点击与插件相关联的接口元素时,就会触发插件调用函数,在插件调用函数中使用主函数中所保存的插件信息调用插件中实现的功能。在调用插件输出函数时也可以把主程序中实现的接口传递给插件方。

 

2 Kettle体系结构

Kettle 体系架构_第1张图片

 Kettle分为kettle平台、各类插件。其中kettle平台是整个系统的基础,包括UI、插件管理、元数据管理和数据集成引擎。UI显示 Spoon这个核心组件的界面,通过xul实现菜单栏、工具栏的定制化,显示插件界面接口元素。元数据管理引擎管理ktr、kjb或者元数据库,插件通过该引擎获取基本信息。插件管理引擎主要负责插件的注册。数据集成引擎负责调用插件,并返回相应信息。

2.1 插件扩展机制

Kettle是众多“可供插入的地方”(扩展点)和“可以插入的东西”(扩展)共同组成的集合体。在我们的生活中,电源接线板就是一种“扩展点”,很多“扩展”(也就是电线插头)可以插在它上面。

在Kettle中不管是以后的扩展还是系统集成的功能,本质上来讲都是插件,管理方式和运行机制是一致的。系统集成的功能点也均实现了对应的扩展接口,只是在插接的说明上略有不同。

Kettle的扩展点包括step插件、job entry插件、Database插件、Partioner插件、debugging插件,这里我们重点介绍step、job entry、database插件。暴露的扩展点如下表所示:

Kettle 体系架构_第2张图片

Kettle 体系架构_第3张图片


2.2 插件的建立

Kettle中的插件包含两部分,一是系统本身就已经实现的功能点,在源码目录src中说明,如kettle-steps.xml;二是系统之外开发的插件,在plugins目录对应插件目录下的plugins.xml说明,plugins/steps/S3CsvInput/plugins.xml。

 Kettle 体系架构_第4张图片

 

插件说明信息中包括描述信息、类名(包括package,反射用)、父级目录(Spoon左侧栏目录)、提示信息和图片信息。Kettle使用国家化方式编程,所以软件中的所有文字描述均由messages_**.properties提供。

1) 系统集成插件说明xml结构:

Kettle 体系架构_第5张图片

2)扩展插件定义

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

Kettle 体系架构_第6张图片

Kettle 体系架构_第7张图片

扩展插件与系统集成插件的说明内容相似,扩展插件增加ID属性和依赖属性,同时他的目录结构、描述信息和提示信息均能进行国际化配置。

Kettle 体系架构_第8张图片

2.3 插件的注册

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

插件注册时序图:

Kettle 体系架构_第9张图片

plugin注册相关的UML类图:

Kettle 体系架构_第10张图片

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

2.4 插件查找

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

Spoon中step列表:

Kettle 体系架构_第11张图片

左侧显示由Spoon.refreshCoreObjects()函数实现,如果选择时trans相关的内容,将显示所有的step插件。流程图如下所示:

spoon界面step插件显示流程:

Kettle 体系架构_第12张图片

2.5 插件调用

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

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

事件代理类:

Kettle 体系架构_第13张图片

 

SpoonStepsDelegate提供了与UI交互相关的处理事件,如复制、删除、粘贴、编辑等。双击某个step时会调用编辑功能,编辑功能是对插件StepDialogInterface的封装。时序图如下:

双击编辑step时序图:

Kettle 体系架构_第14张图片

双击是TransGraph对象注册的时间,双击是根据页面上的坐标信息获取双击的stepmeta对象(来自于*.ktr)。然后,将这个对象传给事件代理类处理,根据stepmeta对象,获取对应的插件类名,通过反射生成StepDialogInterface的实例并调用open()方法。

2.6 插件间通信

Kettle插件之间天生就具有通信共享数据的特点,kettle中最主要通信方式是通过插件时间共同关联一个数据类对象的方式进行通信;使用单例模式实现插件间信息共享。

2.7 插件生命周期

Kettle并不能做到热插拔,每次添加或者删除插件的时候都需要重启。安装或删除插件,只需要在plugins文件夹下添加或删除对应的文件即可。

 

你可能感兴趣的:(Kettle)