本文讲解4.6版jxTMS中通过数据总线进行配置，整个系列的文章请查看：4.6版升级内容
docker版本的使用，请查看：docker版jxTMS使用指南
4.0版jxTMS的说明，请查看：4.0版升级内容
4.2版jxTMS的说明，请查看：4.2版升级内容
4.4版jxTMS的说明，请查看：4.4版升级内容
之前版本的docker版jxTMS都是采取本地文件的方式进行配置的。对于standalone构型来说，这是没问题的。但对于分布式构型，由于可能需要同时启动多个副本来执行不同的任务，这就存在问题了。
同时启动多个副本完成不同的任务，要求做出两点适应性的改进：
加载什么样的功能模块，可以通过命令行来灵活的调整
各功能模块启动后如何配置，可通过中心化的配置服务来进行灵活的调整
前者就是上篇的命令行参数，后者就是本文的集中化配置。
数据总线的第一个应用，就是集中化配置。
注：设备数据采集后也会将采集并经过解析等处理后的数据发送到另外一条数据总线
集中化配置是建构在数据总线【dataBus】之上的：
数据服务地址：dataBus
总线广播地址：dataBus.broadcast
jxTMS主系统中默认启动了一个dataBusService类来提供基础的配置服务。目前依靠此配置服务的功能模块使用到的配置项类型包括：
allSite，site模块用来对站点及其下属设备进行配置
mqttTopics，mqtt模块用来配置订购需订阅的主题
allDingtalkGroup，dingding模块用来配置开通的钉钉组
allResource，auth模块用来配置需加载的资源
allUser，auth模块用来配置需加载的用户
allRight，auth模块用来配置需加载的权限
allVDResource，device模块用来配置配置化的设备数据获取虚拟资源
这个配置服务有一个默认的数据读写服务，上面每一种类型的配置对应一张dataTable数据表，每一个配置项对应该表的一个dataItem项。
此默认配置服务的每种类型，都需要在加载相应模块时手动设置。本示例是在cwz.main模块的initAtLoad函数中加载的：
def initAtLoad(self, db, org):
s = dataBusService.getItemType(None,None,'allResource')
dataBusService.registerDataDual_fromDT(s)
s = dataBusService.getItemType(None,None,'allRight')
dataBusService.registerDataDual_fromDT(s)
s = dataBusService.getItemType(None,None,'allSite')
dataBusService.registerDataDual_fromDT(s)
s = dataBusService.getItemType(None,None,'allUser')
dataBusService.registerDataDual_fromDT(s)
s = dataBusService.getItemType(None,None,'mqttTopics')
dataBusService.registerDataDual_fromDT(s)
s = dataBusService.getItemType(None,None,'allDingtalkGroup')
dataBusService.registerDataDual_fromDT(s)
s = dataBusService.getItemType(None,None,'allVDResource')
dataBusService.registerDataDual_fromDT(s)
getItemType是将数据总线的st、sn、type合并为点分格式，示例中由于前两者都是None，所以实际上就是所给的type，这里列出完全是为了日后便于扩展。
考虑到数据采集系统的分布式构型精细化管理的需要，集中化配置同时准备了两种配置手段来支持各子系统的配置需求：
dataBusService.registerDataDual_fromDT是把该类型下的所有配置全部发送给请求方，然后请求方可以通过设置过滤器来过滤自己感兴趣的配置项，只接收这些经过过滤的配置项。如前篇命令行一文中的mqttTopicWildcard命令行参数可以实现数据采集系统的横切
dataBusService.registerEventDual注册一个配置事件响应函数，来处理请求方的配置请求。可以更精细与灵活的来实现配置管理
参考资料：
下面的系列文章讲述了如何用jxTMS开发一个实用的业务功能：
下面的系列文章讲述了jxTMS的一些基本开发能力：