IoTGateway/AllJoyn

A software framework that provides proximity-based P2P network management.

History

Alljoyn is launched on Feb. 9, 2011 by QuIC (Qualcomm Innovation Center, Inc.). Until Jun. 2015, it's over 160 members such as Qualcomm, Microsoft, LG, Sony, Sharp, Panasonic, etc. The design goal is to easily allow developers to create apps and services that leverage P2P connectivity.

Supported Features

• Transports
  • Wi-Fi, Ethernet, Serial, Power Line (PLC)

• Bindings
  • C, C++, Objective-C, Java

• Platforms
  • RTOS, Arduino, Linux, Android, iOS, Windows, Mac

• Security
  • peer-to-peer encryption (AES128) and authentication (PSK, ECDSA)

Architecture

The AllJoyn framework comprises AllJoyn Apps and AllJoyn Routers. Apps can only communicate with other Apps by going through a Router.

Alljoyn Standard Application

Alljoyn application consists of 3 parts: App Code, Service Framework Libraries & AllJoyn Core Library.

• AllJoyn App Code
  • It can be programmed to either the AllJoyn Service Frameworks Libraries or the AllJoyn Core Library.
• AllJoyn Service Framework Libraries
  • Implement a set of common services, like onboarding, notification, or control panel.
• AllJoyn Core Library
  • Provides the lowest level set of APIs to interact with the AllJoyn network, such as advertisements and discovery, session creation, etc.
• AllJoyn Router
  • Routes AllJoyn messages between AllJoyn Routers and Applications.

Alljoyn Thin Application

AllJoyn Standard Core Library (AJSCL) are designed to run on general-purpose computers which usually have significant amounts of memory and power. Othe other hand, AllJoyn Thin Core Library (AJTCL) is designed for embedded systems. A Thin Core Library is completely interoperable with AJSCL. Since the AllJoyn network wire protocol is completely implemented on both types of such a system, AJSCL can be completely unaware of the fact that they are talking to Thin Core Libraries, and vice versa.

Core Framework

Session & Port

A session can either be point-to-point or multi-point. Point-to-point sessions allow one-to-one connection, while multi-point allow a group of devices/applications to communicate on the same session. Sessions are created on a specific port. Different ports allow for a variety of point-to-point and multi-point connection topologies. In the figure below, on the left side, both A and B have a point-to-point connection to S on port 1. On the right side, A, B, C, and S are all connected on a multi-point session on S's port 2.

Bus Attachment & BusObject

AllJoyn applications communicate with one another via the BusObject abstraction. Typically, an application that is offering a service creates a BusObject. Remote applications can effectively remotely open the BusObject and call methods on it, similar to a remote procedure call. A BusObject can implement a set of interfaces. Each interface clearly defines a set of BusMethods, BusProperties, and BusSignals. BusMethods allow a remote entity to call a method. BusProperties can be get and set. BusSignals are signals emitted from the application offering the service. A BusObject is attached at a specific bus path. This allows for greater flexibility as the same object can be attached to different bus paths for different purposes. A ProxyBusObject is the object that is created by the remote application to gain access to the BusObject.

Summing up, an application offering a service implements a BusObject to expose access to its services. A remote application creates a session with this application, and connects to its BusObject on a specific object path by creating a ProxyBusObject. Then, it can call BusMethods, access BusProperties, and receive BusSignals.

An AllJoyn Application interacts with the AllJoyn framework via the Bus Attachment. The application advertises its services via the About Announcement, which lists metadata about the application, including the supportedinterfaces. The UniqueName is returned in discovery to identify the application. When a remote application discovers an AllJoyn application, it can create a session by connecting to a specific port. Both point-to-point and multi-point sessions are supported. The AllJoyn application has the option of accepting or denying remote connection requests.

Prior to session creation, the application can create any number of bus objects and place them at a specific object path. Each bus object can implement a set of interfaces, defined by a set of methods, properties, and signals. After the session is created, the remote application will typically communicate with the application by creating a local ProxyBusObject to interact with the BusObject by invoking methods, getting and setting properties, receiving signals.

D-Bus (Distributed Bus)

The AllJoyn framework utilizes an easy-to-understand object model and Remote Method Invocation (RMI) mechanism. The AllJoyn model re-implements the wire protocol set forth by the D-Bus specification and extends the D-Bus wire protocol to support distributed devices.

The following figure shows how the distributed bus may appear to a user of the bus. A component (for example, the Smartphone connection labeled :1.2) can make a procedure call to the component labeled :1.5 on the Linux host without having to worry about the location of that component. The logical distributed bus is actually split up into a number of segments, each running on a different device. The AllJoyn functionality that implements these logical bus segments is called an AllJoyn router.

The connection name (:1:1) is unique. For a component on the bus, a distributed AllJoyn system looks like a bus that is local to the device.

Demo

• ADF 2015 - Alljoyn Demo
• Alljoyn SUSI Service Demo

References

• Alljoyn Official-Site
• AllJoyn Proximal Connectivity Platform
• Peer-to-Peer Technology: Driving Innovative User Experiences in Mobile (PDF)
• The AllJoyn™ Open Source Project (PDF)
• Build an Application Using the Thin Library
• Thin Core API Guide - About
• Thin Core API Guide - Config
• Thin Core API Guide - ControlPanel
• Thin Core API Reference