CTK框架介绍

大家好，又见面了，我是你们的朋友全栈君。

转（http://blog.csdn.net/xinqidian2015/article/details/50537325）

CTK插件框架可以简单的描述为C++的动态组件系统

Design

CTK插件框架的设计有很大的灵感来自OSGi并且使得应用程序由许多不同的组件组合成一个可扩展模型。这个模型允许通过那些组件间共享对象的服务通信。

框架的分层模型被展示在图片1中包括:

Plugins–插件是开发者创建的CTK组件

Services Layer–用动态的方式连接插件通过提供为C++对象提供一个发布-查找-绑定模型。

Life Cycle Layer–install,start,stop,update和uninstall插件的API.

Security–处理安全方面(还不能使用)

更多的这些概念的细节解释可以在下面找到。

Plugins

CTK插件是他的核心,一个基于Qt Plugin系统的共享库。另外在CTK库中默认被隐藏的符号跨所有平台。第一步模块化是关于那些保持局部并且不共享。你共享的东西越少,需要做的错误假设就越少。然而,没有分享就没有合作。CTK插件通常值共享符号(类和函数)来支持CTK的服务模型。

Services

一个在C++中的协作模型通常会使用工厂模式。不同的工具包使用不同的模式和API来访问这样的工厂。通常,决定使用哪种工厂实现是重要的。更进一步来说,代码实现通常不能宣传它的实用性,也不能宣传用户列表可能的实现和挑选最合适的那个。工厂一般不是动态的,一旦一个实现的实例被注册,它不能撤回。最终地,如果很多不同的工厂在使用中,没有集中概述你代码绑定的实现。

这些问题的一种解决方案是CTK服务注册.一个插件可以创建一个对象并且使用CTK服务在一个或多个接口中注册它。另外的插件可以向registry要求所有的使用特定接口注册的服务列表。一个插件甚至可能等待一个特殊的服务出现然后回调。

因此一个插件可以注册一个服务,它可以获取一个服务并且也可以监听直到一个服务出现或者消失。任意数量的插件可以使用相同的接口注册服务并且任何数量的插件都可以获取相同名字的服务看图片2.

如果多个插件用相同的接口注册对象,它们可以用属性来区分。每一个服务注册有一组标准和自定义的属性。你可以使用一个语言表达式过滤器来筛选你感兴趣的服务。属性可以被其他角色使用在应用程序级别。

由于服务是动态的,一个插件可以决定从注册表中撤销它的服务当其他插件还在使用的时候。使用这样一个服务的插件必须确保她们不再使用服务对象并且丢弃任何指向它的指针。这可能听起来像一个很大的额外的复杂性但是使用帮助累比如ctkServiceTracker并且一个像Declarative Services的框架可以使得这个过程简单并且获取很大的优势。服务的动态特性允许安装和卸载插件而其他插件保持功能。它也可以模拟真实世界的问题这样的问题不是静态的。例如在一个分布式的环境中一个服务可能模拟一个终端的连接并且如果连接到远程机器,服务将被撤销。更进一步,动态解决了初始化问题。使用CTK插件的应用程序不需要一个指定的开始顺序在它们的插件中。

尽管service registry接受任何基于QObject的对象作为服务,实现重用的最好的办法是使用标准接口注册这些对象从客户端代码中实现解耦。因此CTK插件框架提供了许多标准接口被设计的接近在OSGi中发布的服务规范。这些标准的服务细节在规范和wiki中描述。

Deployment

CTK插件框架也可以被用来作为你应用程序逻辑的主要容器，但是它也可以嵌入到你已存在的框架中。框架的管理通过提供简单的API来标准化,允许插件install,start,stop和update其他插件,也可以枚举插件和它们服务的用法。API也可以通过所谓的management agents来控制插件框架。管理代理可以和命令行,图形桌面应用或者AJAX应用一样。

Benfits

CTK插件框架基于OSGi的原则和API。同样地它继承了一个非常成熟的和完全被设计的组件系统被用来在Java世界中创建高度复杂的应用。它也带有基于Qt的C++程序的优势。下面列表获取自使用OSGi的好处和使用CTK的上下文。

Reduced Complexity降低复杂度

用CTK插件框架开发意味着开发插件。它们从其他插件隐藏内部并且通过定义好的服务交流。隐藏内部意味着之后有更多改变的自由。这不仅减少了bug数量也使得插件开发更简单因为正确的插件实现一块功能通过定义好的接口。

Reuse

标准化的组件模型使得它更容易使用第三方的组件。

Real World

CTK插件框架是动态的。它可以更新插件并且服务来去自如。有数量惊人的真实世界场景匹配这个动态服务模型。应用程序可以复用这个强大的service registry在它们自己的领域内。这不仅节省编写代码,它也提供了全局的可见性,调试工具和更多的功能比起一个专门的解决方案。在这样一个动态化境中编写代码听起来就像噩梦但是幸运地是这有支持的类和框架可以免除即使不是全部也是大部分。

Easy Deployment

CTK插件框架不仅仅是一个标准的组件,也指定了组件如何被安装和管理。可以通过插件使用API来提供一个管理代理。这个管理代理可以像命令行,图形桌面应用,一个Amazon的EC2W云计算接口,或者一个IBM Tivoli管理系统。标准化的管理API使得在现有和未来的系统集成CTK插件框架变得很容易。

Dynamic Updates动态更新

使用的OSGi组件模型是一个动态模型。插件被安装,启动,停止,更新和卸载而不用降低整个系统。

Adaptive

使用的OSGi组件模型被设计来自底层允许混合和匹配组件。这要求组件的依赖关系需要被指定并且它需要生活在一个环境中,他们的可选组件依赖关系并不总是可用的。服务注册表是一个动态的插件注册表,获取和监听服务。这种动态服务模型允许插件发现在系统中什么功能可以被使用和适应它们提供的功能。这使得代码更灵活并且更易于改变。

Transparency

插件和服务是一等公民在CTK插件环境中。管理API提供了访问插件内部状态还有如何跟其他插件连接。部分应用程序可以被停止来调试一个特定的问题或者诊断被带来的插件。

Versioning

在CTK插件框架中所有的插件都有版本号并且只有插件,可以连接在一起合作

Simple

CTK插件API是十分简单的。核心API少于25个类。核心API是足够的对写插件,安装它们,启动,停止,更新和卸载它们并且包含了所有的监听类。

Lazy

在软件中lazy是好的并且OSGI使用的技术有很多机制只有在需要的时候才做。例如插件可以被启动但是她们也可以被配置只有当其他插件使用它们的时候再启动。服务可以被注册但是只有它们被使用的时候才创建。这些lazy场景可以节省巨大的运行成本

Humble

CTK插件框架不接管你的整个程序.乜可以选择暴露提供功能只是你程序的一部分,或者甚至运行多个框架实例在相同的进程中。

Non Intrusive

在CTK插件环境中的应用程序被留给它们自己。她们可以使用任何功能没有框架限制它们。对CTK服务没有特殊的接口要求,每一个QObject可以充当一个服务并且每个类都可以充当一个接口。