我们看了DDS协议之前,但在最近的一次扩展LinkedIn的讨论回复一个之前的协议条RTI首席执行官斯坦·施耐德在困难关注“data-centricity”作为DDS的主要特色。虽然听起来不错,我很难得到良好的感觉,实际上意味着什么。
物联网(物联网)消息传递协议运行在各种各样的“模式”或风格。在这一点上,一些使用旧的“远程过程调用(RPC)风格可能会感到舒适的一个老式的程序员。这样的消息包含的命令:“把温度设置为72。”“把风扇关掉。”“报告目前65%的湿度。“这就像调用一个函数参数。你可能会认为一个API生成命令,“SetTemp (Thermo15, 72);“或”SetPower (Fan25,);“或”报告(“湿度”,65年,CurrentTime (), MyLocation);“
相比之下,更常见的发布/订阅模型是完全以数据为中心的。消息不需要命令;他们可以直接发布的新数据,和两个订阅者数据分析师可以得到新的数据。显然“以数据为中心”是相对的:pub / sub比RPC以数据为中心的——然而DDS显然更多的以数据为中心的。所以这是什么意思?
我问RTI为一些代码片段,这样我可以看到专门non-DDS和DDS代码可能会是什么样子。他们做的是一个日历的例子中,它演示了一个相对微妙的情况。开会的场景是一个计划,然后改变会议日期。
接收的message-centric版本,说,三个邮件。一个设置会议日期;下一个提供电话细节;最后,另一个电子邮件改变了日期。由你来管理与信息会发生什么——要么通过电子邮件找到的时候参加或手动细节添加到你的日历。
DDS-style以数据为中心的等效(他们说实现不同模式,称为“客观状态”)会被别人取代你的日历的信息与观点,通过DDS添加一个会议,增加电话的细节,然后更改日期。
在抽象的意义上,是谁管理的区别。在电子邮件的情况下,你的角色(在应用程序)的消息,解释他们(相当于开箱或“反序列化”或“分解”消息的内容),然后手动更改日历的状态。在DDS的情况下,DDS管理状态。
这是相当于比较“伪代码”作为RTI写的。对于DDS,代码管理日历,然后查看会议会看起来像:
你会发现没有代码维护日历。一旦你建立了“读者”,那么所有你做的是阅读或查看如果您需要。
MQTT片段他们提交的是这样的:
这个代码来处理消息时进来——尽管他们的结果“以数据为中心”订阅发布/订阅系统中。使用标准的记忆体技术创建集合然后明确填充,从消息中提取数据与信息。那些不出现在DDS的版本,因为DDS处理这些不透明。
听起来不错,但我仍然感到模糊。特别是,我想知道关于数据所有权:DDS, DDS有拥有的所有数据吗?如果我使用Outlook或gmail日历,然后我必须放弃DDS使用其他格式吗?
与RTI在谈话中,他们阐明了DDS可以链接到其他数据源通过类似于一个符号链接。所以它不像DDS重造一个完整的新的日历系统——它可以利用的。
但它也变得更加微妙,因为主人我的日历,我需要能够批准或拒绝会议请求。所以别人不能随意改变我的日历。这是我们谈论的话题。
主题的方法中定义的数据类型是DDS。“温度”可能是一个主题;“日历”可能是另一个。可以过滤副键,这样可以区分不同的温度计或位置时订阅“温度”或不同人的日历当订阅“日历。“对于每一个数据类型,是一种结构,内部DDS消息中的数据。格式可以是不同的对于不同的出版商相似的数据,所以当一个订阅时,数据结构可以协商,以便DDS知道如何解析更新。
所以你可能会想,“主题=“日历”;关键=布来安”会给人访问我的日历的变化。但如果你给他们,然后他们可以简单地直接改变我的日历,我不干预。所以你可能会有两个主题——“日历”和“提出日历”或类似的东西。别人可以看到你实际日历;然后提出一个会议,出版“提出了日历,“你可以看到通过提出日程表视图;一旦你接受它,它被添加到你的日历,现在可见通过日历的话题。
差异可以归结为,你会发现代码的管理数据模型。DDS,中间件处理所有的协议。与许多其他协议,应用程序代码。可以改变如果你有一个大型工业设置与成千上万的节点和一个巨大的各种各样的应用程序保持同步(DDS设计的场景)。如果应用程序可以简单地达到和读或写数据而不用担心怎么和存储以及如何保持它的电流,然后少能更容易出错和应用程序设计。
