jxTMS是以低成本快速定制为核心诉求的、SaaS模式的二次开发平台,详见:jxTMS简介。本文是讲述jxTMS平台中如何实现能力扩展的,整个系列请访问:jxTMS设计思想
jxTMS是通用的的二次开发平台,而在前述的安全一章的讨论中,大家看到jxTMS出于安全的考虑,对一般的开发者限制了其能力【即只能按jxTMS的要求来使用jxTMS指定的功能】。但业务系统却是需要面向用户的业务需求提供针对性的定制。而这些定制难免需要全能力【即编程语言+扩展包+操作系统含安装的各种应用所提供的全部功能】。
如,笔者用jxTMS开发过的:智能转运箱,还有在线编程考试系统之类的,绝大部分功能都能用jxTMS来快速开发完成,但核心业务功能【智能转运箱中的硬件控制、在线编程考试的c++代码的编译/试算/运行、python代码的执行】却需要jxTMS开放全能力才可以完成,这对于开发jxTMS的笔者来说当然没问题。
但换成其它开发者,就对jxTMS构成了一个两难:
-
不限制能力,jxTMS就只能封闭运营以强化对开发者的管控,否则安全无法得到保证,但这就限制了jxTMS的使用模式和范围
-
限制能力,jxTMS就会因为无法实现核心业务功能而在客户处失去价值
所以,jxTMS采用了分级控制的方式来解决这个两难:
1、一般的开发者
就是按安全一章所述来限制其能力。但即便是被限制了能力,由于jxTMS已经提供了足够强大的基本能力,还是可以支持开发者完成绝大部分的业务系统功能。
同时,随着jxTMS的发展,也会不断增强其基本能力,所以即便是被限制了能力,也是足以满足大部分业务功能的开发需要的。
2、第三方开发者
这些开发者和jxTMS是一个共生的关系,所以其更值得信任,也同时会有更多的技术之外的约束手段。
所以对于这些合作伙伴所提供的模块,会解除导包的限制使得其会获得更强大的能力
3、通过扩展来提供完全能力的合作方式
第三方开发者所开发的模块,依然是利用jxTMS所提供的二次开发平台来开发的,其能力依然会受到jxTMS的制约,而有些功能可能需要突破jxTMS的限制,如智能转运箱需要实现对箱子的硬件控制。
笔者当时是通过在jxTMS中增加一个硬件控制包来解决这个问题的。但作为通用的业务系统二次开发平台,jxTMS不可能有一个超能力的需求,就向平台中增加一种稀奇古怪的能力。
所以jxTMS最终是以外挂的方式提供了能力的扩展。即jxTMS提供了两种客户端:一种是java的、一种是python的,经过审核的合作伙伴,可以基于这两种客户端来开发自己的程序,作为外挂部件通过消息系统接入到jxTMS中,来为自用模块或第三方模块提供服务。
即以自定义模块或第三方模块+全能力外挂的方式来提供全能力。
全能力外挂
说起来玄乎,其实原理非常简单,结构一文说了,jxTMS是分布式的平台,所以需要建立内部的管理协同机制。而这一机制是基于一种称之为catalogService的服务,其来自目录服务的进一步发展。
目前,catalogService已经成为jxTMS的内生机制,所有的web服务、app服务、组织都需要启动catalogService的客户端,向catalogService注册、保活、接受其下达的管控命令。
注:保活就是以指定间隔向catalogService发送心跳信号,如果三次未检测到则视为该客户端已失联,在将其从目录中删除的同时会向管控模块报告此事件
也就是说,catalogService是整个jxTMS的管控中心。依托catalogService,jxTMS可以在不同的服务器上启动组织、关闭组织;当某台服务器崩溃后,将其上的组织转移到其它服务器上启动,相当于提供了组织的冷备,可将意外故障所导致的组织服务中断时间缩小到秒级。
所以呢,全能力外挂就是运行在jxTMS所提供的catalogService客户端上并接受catalogService管理的用户程序。由于同样具有catalogService所提供的保活能力,所以全能力外挂也天然的具有冷备能力,故障停服间隔也同样缩小到了秒级。
因此,全能力外挂本质上就是一种微服务,用户或第三方利用catalogService启动一个自定义的微服务来完成核心业务所需的独特功能,然后供用户模块或第三方模块调用。
目前,考虑到安全性与全能力的平衡,全能力外挂不可以访问组织私有数据库,也就是说,用户模块或第三方模块需要从组织私有数据库读取数据后再以参数的形式来调用全能力外挂所提供的服务。
当用户组织积累了大量数据后,就可能需要以各种方式挖掘出这些数据中的价值。所以,未来不排除向全能力外挂开放数据查询的能力。
目前jxTMS已经开放个人注册试用,欢迎大家注册试用:
下面的系列文章讲述了如何用jxTMS开发一个实用的业务功能:
下面的系列文章讲述了jxTMS的一些基本功能: