[AllJoyn] 1, IoT open source software Framework AllJoyn Research (a)--preliminary understanding

What is AllJoyn? [is a collaborative open source software framework designed to connect everything]

An Open Source API Framework for the Internet of everything
A-Devices and applications publish APIs over A network in a standard-of-the-type
why APIs?
–because The software developers understand and work with every day
These APIs are the functional ity that the ' things ' on the network expose to other ' things '
–e.g. Temperature, time of day, etc ....
–services and/or devices can compose these APIs to provide whatever set of functionality they require
, haven APIs A Re critical to interoperability between devices and services
How does applications know what APIs is available?< /strong>
–alljoyn provides application discovery and fine-grained discovery of the APIs supported by Applications
– This is accomplished in a platform and Radio-link agnostic A-type

overview[It is a distributed software bus that provides "media" that enables AllJoyn applications to communicate with each other, and applications can be cured in microprocessors, Mobile apps or traditional PC applications or services; An application can be either a server or a client; The bus is set up as ad hoc]

AllJoyn implements a "distributed software Bus"
, Haven Bus provides the "medium" that enables Alljoy n applications to communicate via published APIs
? Applications may is firmware on microcontrollers, mobile device "apps" or traditional applications on Pcs/servers
–app Lications Publishing APIs is services, while those consuming the APIs is clients
? An application can both a service and a client:this are makes AllJoyn a peer-to-peer system
–communication is via M Essages that map directly to APIs in high-level programming languages
Bus Formation is ad hoc
–bas Ed on discovery of Applications/services
–abstracts link-specific discovery Mechanisms
Protocol are Network-independent
–wire protocol is based on the D-bus wire-protocol with extensions
–can run over Wi-f I, Wi-Fi Direct, Ethernet, PLC and Bluetooth
? Could likely run over others

The high-level system architecture[hierarchy includes routing nodes and page nodes where routing nodes can connect to routing nodes or leaf nodes, and leaf nodes can only connect to leaf nodes]

AllJoyn Bus is composed of types of nodes:
–routing Nodes (RN)
–leaf Nodes (LN)
? LN can only connect to RN
? RN can connect to other RN
–alljoyn can thought of as a mesh of stars

The discovery mechanism of Ad Hoc bus formation:discovery[ad hoc bus: The interface description is contained in the about message, the real discovery mechanism is dependent on the transport layer, the different transport layer adopts the same protocol.

Interface descriptions contained in about message
? Services advertise, and clients find, about messages
? Connect to advertisers supporting desired interfaces
Actual discovery mechanism is transport dependent:
? On Wi-Fi, PLC, ethernet:lightweight IP Multicast Protocol
? On Wi-Fi direct:would use pre-association discovery

Ad Hoc Bus Formation:session creation[Session establishment will cause Bus connection extension]

Session creation'll cause Routing Nodes to connect and extend the bus
? Once connected, buses merge and has a single shared namespace
? Peers can discover when other peers join or leave the bus
? Peers can interact via their APIs
? Session reference counting keeps device-to-device connections alive
? Multicast events can sent to all peers in the session

AllJoyn software framework:high-level architecture[software framework high-level architecture]

A Comprehensive Software Communication framework

Software Components[alljoyn is composed of the client library and router. The client library includes standard Client (SC) and thin Client (TC), SC runs on Hlos, supports multi-threading, different development platforms and languages. TC Limit is more, only C language]

AllJoyn has both main architectural components:the Client Library and the Router
Client Library
–this is referred to as a Client Library because all AllJoyn applications be clients of the router
? This was true regardless of if, in their application context, they was exposing services, or is clients of the other services
? Applications is peers if they implement both client and service functionality
, Haven Client Library is what software developers interact with:the API set of the AllJoyn SDK
–there is implementations of the Client library:theStandard Client(SC) and theThin Client(TC)
, Haven SC is targeted @ applications running in Hlos environments
? The SDK APIs for the SC provide a high level of abstraction, and allow complex multi-threaded applications
? Native implementation is in C + + and there is a number of language bindings for various platforms available
, Haven TC is targeted at applications this would reside on deeply embedded devices (i.e. device firmware)
? Targets a very minimal memory (RAM and ROM) footprint,
? Implemented in C, with no other language bindings
? TC depends on a Routing Node running elsewhere, likely off device

Software components:router[Any node that contains a router is a routing node, and the router uses SC (thus running on Hlos)

Router
–any node containing the router is a Routing node
, haven router is built using the standard Client library, and so must run in an Hlos
–this can deployed as a standalone daemon/service or integrated with the SC in an application
? The only platforms on which standalone functionality was currently supported are linux-based, such as OpenWRT
, Haven Router functionality consists of bus management and routing AllJoyn messages
? Bus Management includes
–managing the Namespace:application addressing over the bus
–cross-device communication:discovering Services and connecting to the routing node supporting this service on behalf Le AF nodes
? Message routing consists of delivering messages between applications, or to the router itself
–alljoyn control signaling also uses AllJoyn messages
–routing Nodes do the ' heavy lifting ' in the AllJoyn system
–leaf Nodes depend on Routing Nodes to interact with other Nodes

Software Components:language Bindings

Standard Client Library supports multiple language bindings
? Java binding available, compatible with Dalvik
? Objective C binding is available for use on IOS and MacOS
? Managed C + +, C #, WinJS, and Visual Basic is available for use in Windows 8 style applications
? Unity + C Binding available for use on Android
? NPAPI binding for JavaScript is available
–all of the bindings is currently wrappers around the native C + + implementation
–same object model for all bindings
–seamless interoperability between applications written in different languages
Thin Client Library only supports C
–most appropriate language for embedded RTOS development
–other language wrappers around the C implementation being investigated

[Genuine Please search: beautifulzzzz (see the Landlord Blog Park Official blog, enjoy a high quality of life)]

[If you also like the smart hardware things, can make a friend ~]

[If you are ambitious, can unite each hero's heroes, can also leave a message ~]

AllJoyn Continuous Update ... \ (^o^)/~

[AllJoyn] 1, IoT open source software Framework AllJoyn Research (a)--preliminary understanding