At the Embedded linux Conference in April, Open Connectivity Foundation (OCF) Executive Director Mike Richmondconcludedhis keynote on the potential for interoperability between the OCF’s IoTivity IoT framework and the AllSeen Alliance’s AllJoyn spec by inviting to the stage Greg Burns, the chief architect of AllJoyn. Burns briefly shared his opinion that not only was there no major technical obstacle to combining these two major open source IoT specs, but that by taking the best of both standards, a hybrid could emerge that improves upon both.
Later in the day, Burns gave a technical overview of how such a hybrid could be crafted in “Evolving a Best-of-Breed IoT Framework.” (See video below.) Burns stated in both talks that his opinions in no way reflect the official position of OCF or the AllSeen Alliance. At the time of the ELC talk in April, Burns had recently left his job as VP of Engineering at Qualcomm and Chair of the Technical Steering Committee at the AllSeen Alliance to take on the position of Chief IoT Software Technologist in the Open Source Technology Center at Intel Corp.
Several of Burns’ proposed mergers of AllJoyn features are already being actively evaluated at IoTivity. Later this year, IoTivity 2.0 will introduce the first layer of compatibility with AllJoyn, and subsequent releases will likely include more AllJoyn-inspired changes. Also at ELC, Intel’s Vijay Kesavan, who is Chair of the Iotivity Security Task Group, gave an overview of IoTivity 2.0 .
Shared strengths and interesting differencesIn his presentation, Burns explained how IoTivity and AllJoyn have a lot in common. Similarities include standardized wire protocols, schema definitions, and data models, as well as an IP multicast based proximal discovery scheme that lets devices find and communicate each other without requiring a cloud service. Both frameworks also support transport and OS independence, as well as collaborative, open source development, he added.
Burns acknowledged that many of the terms and concepts used by the two frameworks are different. Yet, many of these concepts map directly, he added. For example, a URI in IoTivity translates into a “bus name plus object path” in AllJoyn. Similarly, an IoTivity resource is essentially an AllJoyn object, a collection is a child object, a link is a local object path, and an observe is an add-match. “I don’t really see the challenge in making these concepts look more similar,” said Burns.
There are also a few unique concepts on each side. Burns proposes using at least two of them: IoTivity’s “interface” and AllJoyn’s “resource introspection.”
In his presentation, Burns analyzed each major component, noting the pros and cons of each. Later he revisited the topics to propose how each might be merged, or in some cases, one approach might be used in place of the other. Here, we combine these observations, giving a birds-eye summary of the major points. The quotes indicate selected, edited comments approved by Burns.
Programming Model IoTivity’s RESTful with Notify vs. AllJoyn’s D-Bus, RMI (remote message indication), and PubSub
“It honestly doesn’t really matter. Anything you can express in one, you can express in the other. So stick with RESTful. It works, and is broadly adopted. We’ve had trouble trying to get people to accept AllJoyn’s approach because it was unfamiliar. Engagement with groups like W3C are really valuable for any IoT standard, and a D-Bus architecture is a tough sell. It’s a battle that isn’t worth fighting.”
Schema IoTivity’s JSON payload with CBOR binary serialization and RAML (RESTful API Modeling Language) vs. AllJoyn’s binary payload with XML and D-Bus serialization
“AllJoyn’s XML solution is based on D-Bus, but over time has become richer and more evolved than JSON. Because AllJoyn uses D-Bus type signatures, it’s more precise. JSON needs to be extended to specify exactly how data gets serialized by adding data types, which are extended notations to the schema specifically for code generation. Being able to automatically generate code from a data model is extraordinarily powerful.
“We need unambiguous serialization both ways. Right now, IoTivity can serialize as a floating point number, integer, and other ways, so receiving devices have to handle multiple serialization types. It’s not a big deal to fix it. It would also be beneficial to add ‘events and actions’ from AllJoyn: support for multiple generic types, supplemental metadata, enumeration values, and human readable strings.
“CBOR is a little more compact than D-Bus, but it’s pretty much equivalent. With AllJoyn you have to know how big the data is before you can serialize it, but CBOR has a nice mechanism for streaming that lets you identify consecutive blocks.
“One of the most powerful things in AllJoyn is that devices know their own data model. Since IoT endpoints may last longer than the servers talking to them, this ‘resource introspection’ is pretty powerful. Some endpoints will have differentiating features that aren’t standardized, so you need to be able to get the data model from it. AllJoyn also uses resource introspection to do code generation, runtime data validation, and access rights checking, so it’s very powerful for the developer.”
Transport IoTivity’s UDP (IPv4 and 6) and UDP multicast vs. AllJoyn’s UDP and TCP (IPv4 with 6 coming)
“I don’t think IoTivity is there quite yet. Right now it’s a COaP-only implementation.”
Service Discovery IoTivity’s CoAP vs. AllJoyn’s MDNS
“These are basically the same: IP multicast with unicast responses and different unicast addresses.”
Network Topology IoTivity’s point-to-point and point-to-multipoint vs. AllJoyn’s “mesh of stars” with leaf and routing nodes
“Overall, IoTivity’s approach is preferable, but AllJoyn’s mesh of stars has its advantages. In AllJoyn, leaf nodes [endpoints] rely on routing nodes to do message passing and service advertisement and discovery. It started out looking a lot like D-Bus, but became more distributed. AllJoyn’s approach enables lightweight, simpler devices on the leaf nodes, but they need to be connected to a routing node running Linux or windows. You can’t have two leaf nodes talking to each other. So unless the routing node is running on an access point, you’ve doubled your network bandwidth.“AllJoyn’s advantage is that the routing nodes support store and forward so leaf nodes can advertise or discover and then go to sleep. For example, a leaf node can post the current temperature on the routing node and then sleep. To do that now on IoTivity you need a caching server. It would be extraordinarily difficult for AllJoyn to eliminate routing nodes and have leaf nodes talk to one another. However, you could fairly easily add a node type to IoTivity with additional functionality such as resource discovery and store and forward. You could end up with something that is better than either solution.”
Security and Permissions IoTivity’s DTLS link layer with ACL permissions and resource, interface, wildcard and CRUDN vs. AllJoyn’s application layer and ACL plus “capability” with interface, object, property, and method etc.
“The underlying security technologies are similar, with both using ECC, AES, and X509, but AllJoyn’s approach is better. With AllJoyn, packets are encrypted at the application level, so it doesn’t matter how they get to their destination. With IoTivity’s link layer encryption, you hit boundaries a
