IoTGateway/AllJoyn

From ESS-WIKI
Revision as of 07:45, 16 February 2016 by Daniel.hung (talk | contribs)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to: navigation, search

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 arch.png

Alljoyn Standard Application

Alljoyn app.png

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 thin.png

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.

Alljoyn session port.png

Bus Attachment & Bus Object

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. Alljoyn bus attachment.png

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.

Bus Interface & Bus Name

An interface definition collects a group of Bus Methods, Bus Signals, and Bus Properties along with their associated type signatures into a named group. In practice, interfaces are implemented by client, service, or peer processes. Interfaces specified this way are described in XML as per the D-Bus specification.


In order to complete the addressing picture of the bus, connections to the bus must have unique names. The AllJoyn system assigns a unique temporary bus name to each bus attachment. However, this UniqueName is autogenerated each time the service connects to the bus and is therefore unsuitable for use as a persistent service identifier. There must be a consistent and persistent way to refer to services attached to the bus. These persistent names are referred to as Well-Known Names.

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.


In the AllJoyn bubble diagrams, the connections to the bus are labeled as clients (C) and services (S) using the sense of clients and services in the RMI model. . The AllJoyn router that implements the core of the distributed bus is labeled (D).

Alljoyn dbus.png

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.

AllJoyn applications can advertise its services via two mechanisms: About Announcements and Well-Known Name.

About Announcements are the recommended mechanism for advertising. It provides a common way for applications to advertise a consistent set of metadata about the application to intersted parties, such as make, model, supported interfaces, a graphical icon, and much more.

Well-Known Name is a more primitive mechanism for applications to announce and discover each other. It is the mechanism that About Announcements use. It is recommended for an application to use About Announcements unless there is a speicifc need for this lower-level functionality.

In both cases, the process of discovery returns a list of AllJoyn applications identified by its UniqueName.


Here is the workflow diagram for advertisement & discovery.

Alljoyn advertisement.png

Put it all together

The following figure shows a hypothetical arrangement of how all of these pieces are related.

Alljoyn interface.png

At the center is the dark line representing the AllJoyn bus. The bus has "exits" which are the BusAttachments assigned the unique names :1.1 and :1.4. In the figure, the BusAttachment with the unique name of :1.1 has requested to be known as org.alljoyn.samples.chat.a and has been assigned the corresponding well-known bus name. The "a" has been added to ensure that the bus name is unique.

There are a number of things implied by taking on that bus name. First, there is a tree structure of bus objects that resides at different paths. In this hypothetical example, there are two bus objects. One is at the path /org/alljoyn/samples/chat/chat and which presumably implements an interface suitable for chatting. The other bus object lives at the path /org/alljoyn/samples/chat/contacts and implements an interface named org.alljoyn.samples.chat.contacts. Since the given bus object implements the interface, it must provide implementations of the corresponding bus methods, bus signals, and bus properties.

The number 42 represents a contact session port that clients must use to initiate a communication session with the service. Note that the session port is unique only within the context of a particular bus attachment, so the other bus attachment in the figure may also use 42 as its contact port as shown.

SUSI Alljoyn Service

Advantech implements an Alljoyn service sample for SUSI APIs. It uses AllJoyn Thin Core Library (AJTCL), so that you can apply it on both embedded systems and general-purpose devices. This Alljoyn application supports About Announcement, ControlPanel service & Event/Action feature.

Build Sample

1. Follow the page to get Alljoyn source code, or directly download from Alljoyn Download

Note: We use v14.12 for SUSI Alljoyn service application.

2. Set $AJ_ROOT 

$ export AJ_ROOT=`pwd`

3. Get Alljoyn SUSI Service source code and put it under $AJ_ROOT/services/base_tcl/sample_apps

4. Set environment variables (Cross-Compiler & SUSI4 lib path) 

$ export CROSS_PATH=/opt/poky/1.5.1/sysroots/x86_64-pokysdk-linux/usr/bin/arm-poky-linux-gnueabi
$ export CROSS_PREFIX=arm-poky-linux-gnueabi-
// Set your SUSI4 lib path
$ export SUSI4_PATH=/home/root/Projects/SUSI_4.0/Library/DllSusi4

5. Build Thin Core Library 

$ cd $AJ_ROOT/core/ajtcl
$ scons WS=off TARG=linux

6. Build SUSI service 

$ cd $AJ_ROOT/services/base_tcl/sample_apps/SusiService
$ scons WS=off TARG=linux AJ_TCL_ROOT=$AJ_ROOT/core/ajtcl

Run Sample

After building, you can get the application binary named SusiService in build folder. Just copy it into your device and execute it!


About verification tools, you can use these two APKs on Android system.

Or use AllJoynExplorer on Windows 10.

Customization

To customize ControlPanel properties, you need to generate source codes from XML file again.

1. Modify susi_services.xml as your expected.

2. Copy susi_services.xml into ControlPanel tools folder. 

$ cp susi_services.xml $AJ_ROOT/services/base_tcl/controlpanel/tools/CPSAppGenerator/SampleXMLs/

3. Run generateCPSApp.py to produce the Control Panel Generated code. 

$ cd $AJ_ROOT/services/base_tcl/controlpanel/tools/CPSAppGenerator
$ python generateCPSApp.py -p [output folder] ./SampleXMLs/susi_services.xml

4. Copy ControlPanelGenerated.c and ControlPanelGenerated.h from [output folder] to $AJ_ROOT/services/base_tcl/sample_apps/SusiService folder.

Demo

References

Retrieved from "https://ess-wiki.advantech.com.tw/wiki/index.php?title=IoTGateway/AllJoyn&oldid=359"