通道架构

整个Origin X中的核心就是任务/接口和服务层的双通道配置以及通道架构，它主要包含四部分内容：

1. 标准四通道架构。
2. ox-cmdb中的配置项三通道架构。
3. ox-plugin中的插件通道架构。
4. 任务专用的Income/Outcome独立任务通道架构。

开发人员必须理解这些通道存在的意义以及如何扩展，才能够精确选择合适的父类进行扩展开发，在真正的配置、开发、实施过程中，父类的选择是通道开发的难点，这就在于开发人员是否理解了之中的每一种数据结构的用途，核心数据结构可参考：OX-006 - 核心数据结构。

整体的通道架构图如下：

1. 标准四通道

Origin X中的标准四通道和 zero-jet 中的原生定义是绑定的，它们的支持表如下：

通道类型	Database	Mission	Integration	主动被动
Adaptor	支持	不支持	不支持	被动
Connector	支持	不支持	支持	被动
Actor	支持	支持	支持	主动
Director	支持	支持	不支持	主动

简单说明一下：

1. 被动通道的配置集中于：I_API, I_SERVICE两张表，用于开发 RESTful 接口专用。
2. 主动通道的配置集中于：I_JOB, I_SERVICE两张表，用于开发后台调度任务专用。
3. 如果仅仅是内部实现，不带集成，那么可直接选择Adaptor / Director模式。
4. 如果需要和第三方系统集成，则才会选择Connector / Director模式。

2. 扩展三通道

扩展三通道并不是Origin X中的原生通道，而是在 cmdb 项目中使用的特殊三类通道，它们的详细内容如下：

类名	备注
AbstractHub	扩展三通道的顶层抽象类。
AbstractHData	单数据处理通道。
AbstractHBatch	批量数据处理通道。
AbstractHFile	上传文件数据处理通道。

扩展三通道中有两个核心结构：

• Completer：配置项数据访问接口，可针对JsonObject/JsonArray的配置项数据实现单表/多表的添加、删除、查询、修改操作，并且在操作过程中会处理关系数据up/down节点。
• Atomy：比对结果数据结构，当两个JsonArray同时出现时，该结果中会存储
  • DELETE：比对后需要被删除的数据。
  • UPDATE：比对后需要执行更新的数据。
  • ADD：比对后新添加的数据。

除此之外，扩展三通道中直接引入了 Aspect 插件流，将通道架构和插件架构合并到一起使用，而且扩展三通道中支持变更历史的生成，会针对所有的增删改实现变更历史的记录工作。

3. 插件通道

插件通道属于开发人员定制过的通道信息，一般从前边提到的七个通道直接继承，并实现特定的功能，如：

类名	父类	备注
AbstractItsm	AbstractHBatch	ITSM生命周期专用开关通道 ，位于 infix-itsm 项目。
AbstractUcmdb	AbstractHData	带 UCMDB 单记录推送器集成通道，位于 infix-ucmdb 项目。
AbstractUcmdbBatch	AbstractHBatch	带 UCMDB 批量记录推送器集成通道，位于 infix-ucmdb 项目

其他的通道在这里就不枚举了，开发人员可以在项目中搜索这些通道的信息来定制不同的基础通道。

4. 任务通道

任务通道请参考：OX-008 - 任务通道详解

5. 总结

不论是开发RESTful的Api、还是开发任务，开发人员首先需要考虑的点是选择四通道或三通道中哪个通道作为当前通道的基类，然后就可以直接在通道内部实现业务逻辑了，选择的基本原则：

• 按照需求，减少数据结构的消费，按需选择您将使用的相关数据结构。
• 很多数据结构是需要配置的，如果不配置，容器不会开销额外资源去构造这些数据结构。