IoT平台接口定制观察
2018-03-26 本文已影响47人
小鱼儿他老汉
设备端接口
一直以来,IoT的设备端接口的标准化程度较低,其多样化一直是一件让人挠头的事情。要么需要码农提供深度定制的服务,耗时耗力,要么会导致项目中断。
标准化接口
就我自己来说,在EPIC架构的Connector端一直推荐采用标准化的方法:
- 传输层:TLS
- 应用层:MQTT
- 表达层:JSON
然后数据就可以一路沿着队列传送到其他服务如数据库和API接口。但是由于资源原因,设备接口端一直存在定制需要。虽然大多数设计都比较落伍,尤其在安全性和语义性上缺乏合理的设计。
接口定制服务化
我们来观察其他供应商的做法:
- 机智云提供的Agent,其实是将接口工作统一到设备领域中,这样开发中直接访问设备的Agent,接口工作可以减少。
- 中移动OneNet,提供了Lua透传和JSON Schema两种方式,一种是让用户自己写代码,另外一种是利用JSON来定义编码解码对接工作。
- 华为OceanConnect,提供了编解码插件,本质上也是类似与OneNet的第二种方式。
以上三种方式都有可取之处,目的只有一个:加速设备对接和应用集成速度。
利用标记语言如JSON/XML,甚至Markdown/CSV格式语言都可以实现从编解码定义到编解码代码转换,但是没有标准化。而直接使用编程语言有一定风险,这也是为何OneNet采用嵌入式脚本Lua的原因吧。
此外需要设计者提供工具来实现:规划、验证、设备端代码生成。
类似设计
Yahoo pipes曾经是接合网络爬虫和非结构化数据解析的一种实验性工具。Twisted上也曾经有人提供过开源的替代品。如果将pipes作为通用编解码器来考虑,那么这个设计可以作为一个参考。
Google ProtocolBuf 也是一个相对完整的设计,包括.proto定义和代码生成器。除了JSON,还有msgpack和BSON等二进制序列化标准。替代品还有:Thrift,Hessian,Kiro......
在这些开源设计基础上,通过增加callback等其他定义,也可以构成一个相对完整的设计。