可编程世界的发展之路

主要结论

• 物联网技术的涌现，意味着我们身边的普通物件，例如灯泡、门把手、牙刷等都将可以动态地连接互联网并进行编程。
• 当今主流的开发方法、语言和工具无法很好地胜任对我们周围数百万个可编程物件开发软件这一重任。
• 尽管物联网市场呈现出多样化局面，但也逐渐涌现出一种包含数个共同元素（如设备、网关、云）的通用端到端架构。
• 物联网解决方案的革新呈现出两个重要趋势：从数据收集到操作现实世界，以及边缘计算范式（数据在本地处理完毕之后再发送到云中）的兴起。
• 面对可编程世界，开发者面临的主要挑战在于分布式计算固有的难题，以及诸如 JavaScript 等本就无法胜任的语言和工具正在逐渐成为物联网开发的核心，此外还有安全问题。

本文首发于 IEEE Software 杂志。 IEEE Software 针对当今世界的主要战略性技术问题提供了坚实的同行审阅信息。为了应对企业在可靠性、灵活性等方面提出的挑战，IT 经理和技术主管必须依赖 IT 专业人员才能获得最先进的解决方案。

我们周围陆续涌现出数以百万计可远程操作、可编程的设备，这对软件开发者造成了巨大的挑战。当今以云为中心，以数据为中心的物联网系统向着可编程世界的发展需要明确的路线图，同时一些尚未引起足够重视的挑战也需要我们做好准备。

物联网 (IoT) 代表着当今互联网技术的下一次巨大飞跃。二十世纪七八十年代，互联网的主要目的（似乎）在于将计算机连接在一起。二十世纪九十年代到二十一世纪初，互联网的目的是将人连接在一起。现在，大家开始调转注意力，打算将一切（真正意义上的一切）都连接到互联网。

目前有关物联网的大部分研究都围绕着数据获取、实时和脱机分析、机器学习、数据可视化，以及其他与大数据有关的话题 [1] 。这其实没什么好吃惊的，毕竟从数百万有感知能力的设备收集数据，随后汇总并处理这些数据，借此针对人们的行为和现实世界中的其他现象提供洞见，这样的能力有着极大的市场潜力。

然而一个同样重要但更微妙，也更低调的变化正在悄然发生着。硬件的进步和更强大、成本更低的集成式芯片的逐渐普及，使得我们已经可以将网络连接以及完整、成熟的虚拟机和动态语言运行时嵌入到任何地点。我们日常生活中的很多东西，包括灯泡、门把手、空调系统、喷灌浇水器、吸尘器、牙刷，甚至厨房水槽，都可以动态地连接到互联网，可以编程。

从当今以云为中心，以数据为中心的物联网系统，到未来一切物体皆可联网，网络的边缘完全可编程，到底该如何发展？本文提供了一个路线图。可编程世界（“可编程”取字面含义）会对软件开发者造成新的挑战。当今的开发方法、语言和工具（或者至少那些广泛使用的）并不足以应对我们周围新出现的数百万种可编程物件。抛开目前广受关注的物联网话题不谈，本文将介绍一些值得更深入研究的问题和技术挑战。

本文的着眼点是未来发展，因此我们的路线图在某种程度上来说较为主观。我们的观点主要源自以往参与过的物联网项目和协作 [2] [3] [4] [5] ，以及基于移动和 Web 计算领域过去 20 年来的发展，根据切身经验进行的预测和分享。例如，二十世纪九十年代末在手机上出现的虚拟机，从本质来看并不算非常重大的技术成果，然而这种技术使得手机为海量开发者打开了一扇新的大门，造就了今天规模数十亿美元计的应用产业。虽然历史本身很少重演，但类似的境况时有发生。具体到物联网领域，这种与过去相似的情况似乎尤其明显，因为我们刚刚到达一个拐点，能够将动态编程能力嵌入到几乎任何地点。

新兴的通用端到端物联网架构

“物联网”这个概念并不是新事物。二十多年前，麻省理工的教授们曾用这个词描述不同物件（设备或传感器）可以互联并共享数据的技术 [6] 。最开始，物联网概念的出现主要围绕其他辅助性技术，例如 RFID 和无线传感器网络 [7] ，然而最近这一概念的应用开始快速扩散到各种领域，包括医疗健康、交通运输、能源、零售、建筑物管理，甚至流程自动化。围绕这一领域已经成立了数百家初创公司，而大部分大型企业也已发布了物联网平台和相关组件产品。最近的一次研究总结了 115 个物联网云平台 [8] 。我们正见证着一次经典的“跨越鸿沟”时期，然而最终的赢家到底是谁还不清楚 [9] 。等到 2025 年，很有可能只会留下少量处于支配地位的物联网平台和平台供应商。

这些物联网产品中，最有趣的地方在于它们的概念相似性。尽管整个物联网市场看起来极具多样化，有大量针对不同领域的供应商，但物联网解决方案已经开始涌现出一种通用的端到端架构，所有系统中的很多组件看起来是极为相似的 1 [10] [11] 。图 1 介绍了其中的一些基本概念，下文还将进一步进行分析。

图 1：新出现的通用端到端物联网架构。尽管整个物联网市场看起来极具多样化，但所有系统中的很多组件看起来是极为相似的。

设备

设备（或外设）是负责收集传感器数据或执行操作的硬件组件，包含了内建的通信能力，可将收集到的数据发送至更广泛的物联网生态中。从功能上来说，设备可以是传感器或致动器 (Actuator)。

传感器可提供有关所监视物理实体的信息。这些信息的类型从物理实体的身份到诸如温度、湿度、压力、亮度、音量、液体流动、震动、磨损等可度量的量化指标，不一而同。传感器唯一的用途在于实现一种名为“标记 (Tag)”的识别、鉴定过程。

致动器需要消耗能量，能量通常来自风能、电能、水能等，致动器会将其转换为状态的改变，借此可更改一个或多个物理实体的状态。

网关

网关（或总线）负责收集、预处理、传输来自物联网设备及其传感器的数据，并会使用不同（通常为无线的）通信协议，例如 Wi-Fi 或 Bluetooth Smart。网关在设备和云之间提供了安全的传输协议，并可能用于支持其他任务，例如作为传感器所生成数据的中介存储，执行预处理操作，发现服务，实现地域分布，进行验证，或进行计费。网关还可用于传递云发送给设备的致动请求。

在某些系统中，设备本身可将感知的数据直接上传到云，并直接从云中接收致动请求，例如可通过 Wi-Fi、3G、4G，或（很快即将支持的）NB-IoT (NarrowBand IoT) 和 5G 网络进行。此类解决方案不需要专门的网关。此外设备本身通常也可以充当其他设备的网关，例如通过本地链路实现点对点或网状 (Mesh) 拓扑。

云

云计算和基于云的存储与分析解决方案是大部分物联网平台的核心。在常规的端到端物联网架构中，云扮演了三个主要角色。

首先是数据的获取、存储和访问。传感器数据的收集和存储是很多物联网系统的基本功能，具备感知能力的物联网设备通常会收集大量数据，而这些数据必须汇总存储到云中，以便进一步处理和分析。这方面的解决方案范围各异，从简单的本地数据库到大规模、可复制、可容错、可伸缩的存储集群不一而足。此外云还需要提供用于访问所收集数据的查询和通知发送 API。

其次是数据分析。这是指检查、交叉连接、转换所获取的可感知数据，从中发现并获得有用的信息，例如借此实现远程信息共享和决策工作。实时分析是指会在收到数据之后立刻运行的分析功能。脱机分析则是指以批处理的方式操作，会在累计到一定量的数据之后进行的分析。机器学习和数据挖掘技术以及相关算法在这一领域极为关键。

第三个角色是为致动提供支持。物联网系统的数据流并不是单向的。除了将设备收集到的传感器数据传输到云，还需要以安全的方式从云向设备传输致动信息。致动能力是远程设备可编程能力的一个重要促进因素。

此外，为物联网提供支持的云解决方案通常还需要包含管理功能，例如设备管理、用户账户管理、使用情况日志、服务器状态监视，以及报表功能。

路线图

我们认为，物联网的未来重在编排，以及通过编程方式为物联网设备远程创建大规模复杂拓扑的能力。正如 Bill Wasik 所争论的，一旦设备连接到公有或私有云，传感器数据开始流入，致动能力变得更广泛可用，人们关注的重心将从传感器数据的收集和分析转向具体应用：也就是用于操作现实世界中复杂系统的编程能力 [12] 。物联网设备提供的致动能力是所有这一切的基础。这些能力使得我们可以对周围（甚至整个地球上任何）物体下达命令并进行控制，而这一切均只需要一个舒适的编程环境，或者一个应用就够了。

正如上文所述，硬件的发展可以推动可编程世界继续向前。物联网硬件的能力和价格正在飞速接近拐点，届时我们将可以在几乎任何类型的设备上运行完整功能的操作系统，例如 Linux 或虚拟化软件栈，以及动态语言运行时。目前市面上出现的低成本芯片已经达到或超越了二十世纪九十年代末诞生 Java 2 Platform，Micro Edition [13] ，进而引爆移动应用革命前，手机的内存和处理能力。我们猜测类似的跨制造商编程能力很快将通过某些方法融入到我们日常生活的物件中。

边缘计算，这个重要的趋势也在推动着整个行业迈向可编程世界。传统的云计算系统是高度中心化的，虽然中心化的计算模式有着巨大的收益，但在通信和能耗方面成本同样很高。假设有一个包含大量彼此极为接近设备的物联网环境，如果依然将来自这些设备的数据传输到远程数据中心来处理，随后将致动请求从数据中心回传到设备，这样的做法无疑是低效的。对于延迟要求高的物联网部署，仅延迟本身的开销就会让这种解决方案变得不够实用。

“边缘计算”这个词大致出现于 2002 年，最初是指通过内容交付网络 (CDN) 部署应用程序的方法。这种方式的主要目标在于通过距离最近的 CDN 边缘服务器改善可伸缩性并降低延迟。边缘计算物联网解决方案可以在网络边缘（通常是网关设备，例如路由器或基站）进行计算，例如预处理传感器数据，在本地根据预设条件触发警报或致动请求。此类系统可以利用本地连接技术（例如 Bluetooth Smart 或 Wi-Fi Direct）在传感器设备间实现去中心化、更高效的直接通信。在促进计算能力在不同实体间移动方面，虚拟化技术也扮演了重要角色。

表 1 分别从数据和编程的角度介绍了我们的路线图中预测的物联网系统在未来 10 年里的进化方向，这个表格的内容基于：

• 在行业和学术界观察到的趋势，反映了最新研究论文、学术期刊、以及图书中的观点 1571011 [14] [15] ；
• 基于行业和学术界实践产品和原型开发体验所了解的专家观点 23；
• 个人体验，以及手机从封闭的，以语音通信为中心的设备发展为包含各类应用程序的智能手机过程中，针对移动应用发展状况的观察 13；以及
• 个人体验，以及 Web 从简单的文本分发环境发展为可立即部署至全球的富应用程序平台环境过程中，针对 Web 演化过程的观察 [16] 。

由于我们主要关注在编程这方面，因此下文我们将深入介绍与编程有关的挑战。

总的来说，我们认为物联网编程能力将从简单的致动功能，不同供应商各不通用的应用和设备 API，以及以云为中心的数据获取和处理机制，演变为能全面运用边缘计算、虚拟化，以及容器技术的系统。此类系统将能进行移植，可跨越不同制造商，并跨越不同行业应用程序。此外还可针对计算和数据，在云和异构边缘设备之间实现按需灵活迁移的能力。我们将物联网系统革新后的这种阶段称之为边缘物联网时代，以及物联网大统一时代。

是否应该用一套 API 解决物联网设备在不同领域和不同垂直行业所面临的问题，这一点目前还存在争议。然而我们可以放心地预测，未来 5 年 -10 年，物联网设备及其 API 将大幅聚合。原因很简单，让人们使用大量由不同供应商提供的应用来控制自己周围的不同设备，这样的做法本身就不现实。此外很有可能必要的基础架构将围绕目前的 IP 网络和 Web 基础架构继续成长，并通过本地连接拓扑进行增强，为边缘计算提供更好的支持。

物联网开发因何而不同

物联网开发与主流的移动应用和客户端 Web 应用程序开发在七个方面有较大差异。这些差异也是造成了下文将要介绍的，在影响力和技术方面所面临挑战的主要原因。

首先，物联网设备通常始终是一个更大规模设备系统中的必要组件，例如家庭、办公室、工厂、购物中心，或飞机上安装的互操作设备。此外物联网设备仅仅是上文介绍的端到端架构中很小的一部分。因为计算机和智能手机也非常依赖云服务。然而从应用程序开发者的角度来看，从根本上来说它们依然是独立设备，开发者依然可以选择计算机或智能手机作为目标。

其次，物联网系统从来不会休息。电脑、智能手机，以及其他独立计算设备可以视作一种“可重启”的系统，如果（并且一旦）运行出错则可以重启动。然而物联网系统通常不应，或者不能彻底关闭。虽然个别设备可能会被关闭，但整个系统必须能够应对设备和网络的中断。

第三，物联网系统更像是实用的工具而不是宠物。物联网系统中计算单位（设备或 CPU）的数量通常远远多于传统计算环境，有可能达到数百、数千，甚至上百万数量级。与电脑和智能手机不同，用户更多地会将它们视作“宠物”，而大规模系统中的物联网设备更像是实用的工具，必须能够以整体的方式加以管理，而无须针对或关注其中的个体。

第四，物联网设备通常会融入到我们周围的世界，因此可能在物理上不可见，不可碰触。设备可能永久性安装在地下，或在物理上置入到其他设备中（例如采矿设备中安装的震动传感器）。因此我们可能无法使用物理线缆连接到这样的设备，或在遇到问题后更换硬件或嵌入的软件。

第五，物联网系统是高度异构的。其中的计算单位可能具备截然不同的运算能力、存储容量、网络带宽，甚至能耗需求。I/O 机制、传感器能力，以及可支持的输入方式也可能各不相同。一些设备有物理按钮或显示屏，而很多设备可能根本不具备任何用户可见的界面。

第六，物联网系统通常趋向于只具备有限的连接能力，可能只具备间歇可用，甚至通常不可靠的网络连接。从软件开发者的角度来看，这样的环境使得他们必须经常面对各种失败做好充分准备。如果不具备完善的错误应对机制，应用程序很可能由于设备或网络中断而停用，无限期地等待回应数据包，或彻底耗尽了内存、电源，或其他资源。

最后，物联网系统拓扑可能是高度动态且短暂的。例如，工厂环境中可能有大量位置经常需要变化，具备感知能力的设备，或者它们所生产的产品（或设备组件）只会在工厂范围内短暂停留。对于这种情况，再考虑到设备数量等因素，这就要求编程和部署技术必须能适应设备数量的大范围变动。

除了上述这些基本差异，相对不成熟的物联网领域还会遇到很多其他问题。例如：

首先，目前的物联网系统还不够兼容，开发所用的 API 也不够成熟，缺乏整个业界通用的 API。与移动应用和 Web 应用程序开发不同，这些领域已经实现了大幅度的收敛，物联网 API 依然对具体供应商和硬件规格有一定的要求。这严重妨碍到我们开发可以跨越不同制造商和供应商所提供的物联网设备和系统开发软件的能力。目前这方面正在围绕标准化进行着大量努力，例如 Industrial Internet Consortium、IPSO Alliance、Open Connectivity Foundation（原名 Open Interconnect Consortium），以及 Open Mobile Alliance。然而标准化工作可能依然要等待多年才能实现一致并变得成熟。

最后，当今的物联网系统是以云为中心的，几乎所有数据都会收集到云中。并且通常来说，针对所收集数据进行的大部分运算或操作也是在云端进行的。然而随着物联网设备和网关的功能日趋完善，计算工作可能会在不同位置进行：设备上、网关上，或者云端。理想情况下的物联网，应该能在最适合的时间将计算工作和数据在不同设备之间灵活地迁移。

对软件开发工作造成的影响和挑战

总结来说，面对这些差异，物联网开发者必须从不同于大部分移动应用和客户端 Web 应用程序的多个维度加以考虑，包括：

• 多设备编程；
• 物联网系统反应式、始终在线的本质；
• 异构和多样性；
• 软件方面分布式、高度动态，可能需要迁移的本质；以及
• 以足够容错并且有一定防御能力的方式编写软件的常规需求。

典型的物联网应用程序是连续的，是反应式的。根据所采集的传感器数据为基础，触发（或反复触发）计算操作，最终获得各种可行的事件。整个过程从本质上来看是异步的、并行的，并且也是分布式的。

严格来说，这些特征在软件开发领域并不是新事物。任何针对分布式或关键任务系统构建过软件的开发者至少在某种程度上已经熟悉这些特征可能造成的挑战。为云后端服务器集群开发软件的开发者往往也会遇到类似的挑战。

有关分布式计算的谬误

然而根据自己的经验，我们认为普通的移动应用或客户端 Web 应用程序开发者并不足以胜任物联网系统开发所面临的挑战。正如 L. Peter Deutsch 和 James Gosling 在他们的著作：Fallacies of Distributed Computing 中总结的，在首次为分布式系统和应用开发软件时，程序员总是会做出下列七个错误的假设 [17] ：

• 网络是可靠的。
• 延迟为零。
• 带宽是无穷无尽的。
• 网络是安全的。
• 拓扑永远不会变化。
• 随时都有一名管理员。
• 传输成本为零。

未能充分考虑这些错误的假设将会遇到各种类型的错误，例如打开 Socket 监听已经不存在的设备，假设会立刻收到响应或需要无尽地等待回应数据包，或不必要地消耗内存和电池。Leslie Lamport 曾有一个众所周知的结论，在分布式系统中，“另外一台你根本不知道的计算机中出现的故障最终会导致你自己的计算机无法使用” [18] 。

尽管如此，开发者为了应对可能出现的错误或异常所额外开发的代码也蕴含着风险。这样的做法会导致实际的程序逻辑被隐藏在数千行为了实现差错处理而编写的样板代码 (Boilerplate code) 中，导致程序更难以理解和维护。因此物联网开发领域最大的一个挑战恰恰在于在应用程序逻辑和错误处理机制之间进行恰当的权衡。理想情况下，所用开发语言和工具应该能促进这一目的，让错误处理代码不至于和程序逻辑混杂在一起。

一般来说，为分布式系统构建和维护软件的隐性成本几乎永远会被低估。根据研究，认证和验证活动和各种检查可能会占用高达 75% 的开发成本 [19] 。

无法胜任的语言和工具

人们在物联网开发工作中使用的编程语言和工具，大部分也被用于主流的移动应用和客户端 Web 应用开发工作。例如目前主流的物联网软件开发工具包品牌 Arduino、Espruino、Intel 的 Edison 和 Galileo，以及 Tessel，均可让用户选择 C、C#、Java、JavaScript、Python 等开发语言。

最奇怪的是，JavaScript 和 Node.js（服务器端版本的 JavaScript）正由于在 Web 开发中的流行度而逐渐成为物联网开发的主要工具。这种现象让人感觉遗憾，因为 JavaScript 在设计上并非针对异步分布式应用程序或大规模编程工作的。最近 JavaScript 领域开始流行“回调嵌套 (Callback hell)”这个概念，这个概念描述了由于异步函数调用，以及在编写成功和失败处理例程时使用了独立的事件处理函数，导致应用程序逻辑难以跟踪的情况（例如可参阅 Callback Hell ）。ECMAScript 6 标准中增加的 Promise 机制有助于缓解这种问题。然而公平地说，JavaScript 并不适合用来开发任何分布式软件系统。

目前流行的物联网开发语言也没能真正解决大规模编程相关的问题。也就是说，这些语言既不能缓解对数千个设备组成的系统进行编排的难题，也不能让代码灵活地在云、网关，以及设备之间进行迁移。

物联网系统的动态本质

过去 10 年 -15 年来，软件开发变得更加敏捷和动态。大部分应用程序已经开始连接至后端服务。诸如 JavaScript 和 Python 等动态编程语言逐渐开始流行。万维网的出现让我们可以立即将软件部署到全球。开发者能够用比 10 年前更快的频率将应用程序的更新推送给客户，甚至可以在一小时内多次推送。DevOps 开发和部署模式 [20] 大幅取代了以往在自动化软件交付和基础架构等方面的实践。

虽然这些进步让软件行业从中获益，但物联网系统极为动态的本质也造成了额外的挑战。例如，物联网系统的调试和测试可能非常困难，因为设备数量太多，拓扑是动态的，网络连接不稳定，或者设备是异构甚至（有时是）不可见的。

虽然单个物联网设备可能只具备有限的数据收集功能，因此很容易测试，但要对复杂的现实环境（工厂、商场、温室、舰船等）中部署的，包含成百上千个设备的完整系统进行测试，这一过程可能充满了挑战。如果系统本身可自行对计算速度、网络延迟、设备电池消耗等因素进行调整和平衡（权衡），进而在云、网关，以及设备之间动态地迁移计算处理任务，调试和测试还将变得更加困难。此时的测试和调试过程中，甚至可能无法复现系统行为。

需要再次提醒，对于分布式或关键业务软件，或流程自动化系统的开发者来说，应该对这些挑战不陌生了。然而大部分移动应用和客户端 Web 应用程序开发者并未经历过这样的挑战，因此很可能会低估调试和测试过程中需要付出的代价和可能遇到的问题。

以史为鉴，展望未来

以往的经验和挑战证明，可编程世界的出现不仅仅需要新的硬件开发，新的通信协议和技术，或新的海量数据集摄取和分析技术。为了驾驭可编程世界的全部威力，我们需要新的软件工程和开发技术、流程、方法论、抽象，以及工具。过去在开发分布式系统和关键业务软件过程中积累的技术经验可以帮助我们避免重复工作，不需要重新发明车轮。更重要的是，为了应对这些挑战，我们需要教育软件开发者，让他们意识到物联网开发与移动应用和客户端 Web 应用程序的开发有着本质上的不同。

安全性

实现可编程世界的过程中，安全性是一个巨大的挑战。对于工厂、发电厂，或油井等复杂环境中安装的物联网设备进行远程管理，明显更需要关注安全问题。远程致动和编程能力也会造成巨大的安全隐患。传输层安全所用的加密协议、安全证书、物理隔离，以及业界围绕这些问题建立的其他实践在这一领域扮演了重要的角色，但依然有很多有趣的技术挑战等着我们克服。然而最严重的安全隐患可能在于，数千种物联网设备依然使用着自己的标准化安全设置，例如可能使用了默认的管理员密码。在芬兰已经出现了这样的问题，由于将控制系统暴露在互联网攻击中，导致整个公寓的暖气系统被远程关闭。

探讨

目前，物联网系统的编程主要以自定义应用的形式由不同生产商进行，这些应用只能控制每个生产商自己生态内的设备。例如飞利浦的灯泡只能使用 Philips Hue 应用控制，而 GE 和 Cree 也为自己的照明系统提供了专用的应用。类似地，不同制造商生产的空调系统、安全系统、家庭影院控制系统、汽车遥控系统通常也需要安装专用的应用。这种“为每个物件提供专用应用”的做法并不能很好地扩展，只能充当行业标准真正诞生前的临时解决方案。

我们认为，在未来几年里，物联网开发领域会产生巨大变化。目前还没有通用、可互操作的软件开发环境，可以让开发者针对所有类型的设备，轻松地开发一个物联网应用，更不用提大规模复杂拓扑和异构设备环境的编排和管理。此类工具的缺位也映证了物联网市场的不成熟和碎片化，以及设备本身的技术局限，例如有限的 CPU 能力，或无法在不使用线缆连接到物理设备的情况下进行软件更新。虚拟机、动态语言运行时，以及“液态”软件技术将在其中扮演重要角色，促进计算任务和数据更灵活地流动（液态软件可无缝运行于一个或多个用户所拥有的多种设备上）。如果必须通过多种类型的设备执行（或通过适配执行）相同代码，此时传统的二进制软件和针对特定硬件的物联网开发工具将遭受重创。

可编程世界催生了激动人心的机遇和挑战。我们希望本文以及我们的路线图可以启发并鼓励人们在这个领域取得更辉煌的成果。

致谢

感谢芬兰学院（295913 项目）、Mozilla，以及 Nokia Technologies 为本次研究提供的支持。

关于本文作者

Antero Taivalsaari是诺基亚的研究人员，他的研究主要涉及物联网软件开发、数字医疗、液态多设备软件等领域。Taivalsaari 在芬兰 Jyv?skyl? 大学以信息技术博士学位毕业。联系方式：antero.taivalsaari@nokia.com。

Tommi Mikkonen是芬兰赫尔辛基大学软件工程学院教授，同时也是 Mozilla Connected Devices 的技术专家。他的研究主要围绕软件架构、敏捷方法论、Web 技术，以及互联设备等领域。Mikkonen 在芬兰 Tampere 技术大学以信息技术博士学位毕业。联系方式：tommi@mozilla.com。

作者： Antero Taivalsaari 、 Tommi Mikkonen ，阅读英文原文： A Roadmap to the Programmable World

[1] R. Stackowiak et al., Big Data and the Internet of Things: Enterprise Information Architecture for a New Age, Apress, 2015.

[2] P. Selonen and A. Taivalsaari, “Kiuas: IoT Cloud Environment for Enabling the Programmable World”, Proc. 42nd Euromicro Conf. Software Eng. and Advanced Applications (SEAA 16), 2016, pp. 250–257.

[3] F. Ahmadighohandizi and K. Syst?, “Application Development and Deployment for IoT Devices”, to be published in Proc. 4th Int’l Workshop Cloud for IoT (CLIoT 16), 2016.

[4] A. Gallidabino et al., “ On the Architecture of Liquid Software: Technology Alternatives and Design Space ”, Proc. 13th Working IEEE/IFIP Conf. Software Architecture (WICSA 16), 2016;

[5] J. Miranda et al., “From the Internet of Things to the Internet of People”, IEEE Internet Computing, vol. 19, no. 2, 2015, pp. 40–47.

[6] “ Internet of Things History ”, Postscapes, 2014;

[7] A. Al-Fuqaha et al., “Internet of Things: A Survey on Enabling Technologies, Protocols, and Applications”, IEEE Communications Surveys & Tutorials, vol. 17, no. 4, 2015, pp. 2347–2376.

[8] “ IoT Cloud Platform Landscape ”, Postscapes, 2016;

[9] G. Moore, Crossing the Chasm: Marketing and Selling Disruptive Products to Mainstream Customers, 3rd ed., HarperBusiness, 2014.

[10] O. Said and M. Masud, “Towards Internet of Things: Survey and Future Vision”, Int’l J. Computer Networks, vol. 5, no. 1, 2013, pp. 1–17.

[11] J. Gubbi et al., “Internet of Things (IoT): A Vision, Architectural Elements, and Future Directions”, Future Generation Computer Systems, vol. 29, no. 7, 2013, pp. 1645–1660. [12] B. Wasik, “ In the Programmable World, All Our Objects Will Act as One ”, Wired, 14 May 2013;

[13] R. Riggs, A. Taivalsaari, and M. VandenBrink, Programming Wireless Devices with the Java 2 Platform, Micro Edition, Addison-Wesley, 2001.

[14] S. Greengard, The Internet of Things, MIT Press, 2015.

[15] N. Balani, Enterprise IoT: A Definitive Handbook, CreateSpace, 2015.

[16] D. Ingalls et al., “The Lively Kernel: A Self-Supporting System on a Web Page”, Self-Sustaining Systems, LNCS 5146, Springer, 2008, pp. 31-50.

[17] A. Rotem-Gal-Oz, “ Fallacies of Distributed Computing Explained ”;

[18] L. Lamport, Distribution, 28 May, 1987 ;

[19] J.-C. Laprie, “Dependable Computing: Concepts, Limits, Challenges”, Proc. 25th IEEE Int’l Symp. Fault-Tolerant Computing, 1995, pp. 42–54.

[20] P. Debois, “ DevOps: A Software Revolution in the Making? ”, Cutter Business Technology J., 30 Aug. 2011;