標籤:
AllJoyn SDK Concepts[AllJoyn應用通過APIs在objects間暴露自己的功能,大多數應用只暴露一個object,有時會自動產生父object(當應用的object不是root時);object能繼承一個或多個介面]
Exposing Functionality
AllJoyn applications expose their functionality via APIs implemented in objects
– Most applications will expose only a single object
– Object hierarchies are supported if required by application model
? AllJoyn will create parent objects automatically if application object is not the root
Objects implement one or more interfaces
– These are the APIs that can be discovered using About
Interfaces are composed of members, which fall into three categories
– Methods – classic OO object interaction
– Signals – asynchronous event notification
? Can be broadcast, multicast, or point-to-point
? Can also send a Sessionless Signal: a broadcast signal that doesn’t require an application session to be delivered
– Properties – data members
? These are accessed by built-in get/set methods
All of this information can be introspected remotely
AllJoyn SDK Concepts
Bus Attachment is required to interact with/over the bus
– They are the application’s presence on the AllJoyn Bus
– They provide the root (/) of the object hierarchy
Objects are published to local Bus Attachment
– Object path names look like file paths
? e.g. /Games/chess
Proxy Objects
– Local representation of a remote object
Signal handlers are registered with the Bus Attachment
– Registered by applications to take action when a signal is
received
Sessions
– Flow controlled connections between applications
– Can be point-to-point or multipoint
AllJoyn SDK Concepts
Method Calls and Signals
Method Calls are made by using Proxy Objects
– This results in a method call message being sent to the object the proxy object represents
– Method handler is invoked to execute method and generate the reply
– The method reply is sent by the object back to the proxy object
Signals are emitted by Objects and consumed by Signal Handlers
– Sessionless signals work the same way, but do not require the application to create a session
? They are broadcast and are delivered to any app interested in receiving sessionless signals
? Only a single instance of a signal will be sent, i.e. if the same signal is emitted multiple times, only the last will be delivered
– Useful for sending isochronous data, such as state updates
AllJoyn SDK Concepts
Object Model
As stated earlier, the Object model is similar for all language bindings
– Create a BusAttachment to connect to the bus
– Create BusInterface(s) that will be implemented by BusObjects
– Create and register BusObject(s) with the BusAttachment
– BusObjects handle remote method calls and emit Signals
– Applications call methods on remote objects using ProxyBusObjects
– Applications register Signal handlers with BusAttachment
Security Concepts
Design of Security Framework
Authentication and encryption is designed to be app-to-app
– Trust relationship established between the applications*
? There is no trust relationship established at the device level
– The Router is not involved other than to route the messages
– Device pairing not required unless the transport requires it
Security is enabled per interface
– Authentication and key exchange initiated on demand
– Applications can have a mixture of secured interfaces and open interfaces
Security-enabled interface
– Authentication is required to make method calls
– Authentication required to receive signals
– All messages are encrypted
? Regardless of authentication mechanism, encryption always uses same AES-128 CCM algorithm
* Applications could be firmware of embedded device
Security Model – Authentication and Encryption
Built-In Authentication Mechanisms
Four mechanisms supported
– Mechanism negotiated using SASL protocol
– Mechanism chosen by application developer
– Most mechanisms adapted from TLS protocols per RFC 5256
Simple Pin-code pairing
– Specifically for Thin Client applications that lack resources to support big-number arithmetic
Pin-code SRP
– Pairing with a single-use password using Secure Remote Password protocol
Logon SRP
– User name and password using Secure Remote Password protocol
– Password required every time peers connect
Certificate-based
– RSA public key authentication and X.509 certificate-based
– Trust relationship lasts while certificate valid
Base Services
AllJoyn Base Services for fundamental use cases
• Standard AllJoyn building blocks for generically useful services
– Onboarding
– Notifications
– Control Panel
– Config
• Accelerate application and device development
Onboarding Service
Onboarding
Provides a standard way to get devices onto a WiFi Network
– Onboarder is an application running on a smart device
– Onboardee is the device to be added to the WiFi network
Basic flow
– Onboarder discovers device that needs to be onboarded
– Connects to it, and provides configuration information
– Onboardee verifies it can connect
? Informs onboarder that it has been successful or not
Onboarding Service
Notification Service Framework
AllJoyn Notifications Service Framework
Simple, standardized interface for sending and receiving human-readable messages
– Contents are text
? Possible to reference image, audio, video: application can fetch media using reference
– Works across devices, operating systems and connection types
? WiFi, Ethernet, PLC, etc…
– Producer (sender) can assign priority to notification
– Consumer (receiver) can configure preferences on types of notifications it receives
Examples
– Refrigerator could send a notification that freezer door has been left open for more than 2 minutes
? This could be rendered on any producer: mobile device, TV, set top box, etc…
– Washing machine can send a notification when wash cycle is complete
Notification Service
Control Panel Service Framework
Control Panel Service Framework
Infrastructure for exposing user interfaces for devices remotely
– Model is there is a controller and a controllee
– Controlee exposes it’s UI using the framework,
– Controller renders the UI and sends control commands back to controllee base on UI input
– Defined such that any control application using the framework can render a controllee exposed UI
? That is a generic app can control any type of devices that exposes controls using this framework
Examples
– After receiving a notification that the oven has been on Broil for 5 minutes a user could bring up the ovens
control panel and change the setting to “bake at 250” to keep the food warm
– A user could check the current values of a refrigerator (including current temperature) and modify the
settings to make things hotter or colder as needed.
Control Panel Service Framework Example
Control Panel Service High Level Architecture
[正版請搜尋:beautifulzzzz(看樓主部落格園官方部落格,享高品質生活)]
[如果您也喜歡智能硬體的東西,可以交個朋友~]
[如果您胸懷大志,能團結各路豪傑的亂世英雄,也可以留下一下資訊~]
AllJoyn持續更新中。。。\(^o^)/~
[Alljoyn] 2、物聯網開源軟體架構alljoyn研究(二)——初步瞭解