AllJoyn Framework Overview
AllJoyn implementation is a "distributed software Bus"
Bus is point-to-point mode
The protocol does not depend on the network
These three points are flipped from the introductory PPT, but understand a little bit to understand that this framework is a distributed middle-tier communication framework that supports point-to-point communication and is shielded from the underlying physical network by the middle tier, providing interfaces directly to upper-level programming languages.
High-level system framework
This figure is excerpted from (Alljoyn-tech overview v3_for Brooks)
There are only two types of nodes in the system from this framework of the high-level:
Routing Nodes (RN)
Leaf Nodes (LN)
The rule is that RN can communicate with RN and LN, and LN can only communicate with RN.
Here are two pictures showing a process of communication between router, discovering and establishing a session. This is a simple example of communication in the high-level System architecture.
Ad Hoc Bus Formation:discovery
Here the client app and the device internal router establish internal links, the client side of the router will find the router of the service by looking for interface.
Ad Hoc Bus formation:session Creation
Router established a session to enable client access to service.
Software components
This part of the phase is beginning to get to the point.
High-level framework for Software components: Basic service Framework (Base services frameworks and core framework)
Software components can also be divided into the Client Library and Router
Client Library:
Interface for developing users
Publish Externally as SDK API
Divided into two types of stand client and Thin client
SC for high-level operating systems, the Thin client is intended for embedded systems or small memory systems.
Router:
Any app that contains router can be thought of as a router Node
Router must be built using the stand Client Library and must be run in Hlos.
It can be deployed as a separate service or daemon
The router feature includes bus management and AllJoyn message routing
About the SDK for AllJoyn
The AllJoyn program is provided externally in the form of an API, which is implemented by an object.
Most of the programs just keep an object on the outside. objects provide many interfaces to the outside, and these APIs can be queried by about.
The interface consists of three forms:
- Method: Interacting with an object
- Signals (signal): Notification of asynchronous events
- Property (attribute): Read or SET data
The following illustration is about the use of API interfaces.
The first is to connect to the bus
Applications to attach to the bus.
The left object is posted to the bus local attachment.
A proxy object is defined on the peer
The signal processing handler will be registered to the right end of the bus attachment to deal with the signal sent by object.
The use of method is accomplished by using the proxy object.
When invoking the interface on the right proxy, the left method handler registers the handler function, executes and returns the value to the proxy object.
The Signal (signal) is triggered by the left object and processed by the Signal handler registered on the right.
With these two graphs, a basic operation flow is strung together. This is still a bit like the idea of CORBA.
Copyright NOTICE: This article for Bo Master original article, without Bo Master permission not reproduced.
Open Source Project AllJoyn framework