Introduction

Thunder is a Modular architecture with plug and play design where it has a flexibility to enable or disable any feature just as a plugin.

Key Components available in the THUNDER Framework -

• WPE WebKit - powerful low-resource embedded WebKit engine with Wayland support
• WPE Backend - Abstraction layer for WPE WebKit with support for MESA based gfx or Wayland/EGL gfx
• Thunder - plugin based framework for embedding C/C++ components and bridging the "web" world.
• ThunderNanoServices - Various plugins from a DHCP Server, Wi-Fi Control, Bluetooth, Compositor to premium app based plugins (NF, Amazon, etc)

Thunder is a small framework built for embedded devices. It consists out of the following main components -

• Framework Core
• Framework Plugins
• Framework UI

Thunder and ThunderNanoservices are key components for micro services to bring into any Box. Thunder offers an event driven interface framework for subsystem availability signaling to the plugins. This framework is utilized to realize concurrent startup scenario using a conditional evaluation only in case a condition changes. This allows for startup without requiring sleeps, or resource consuming polling mechanisms.

For each micro service, we need to implement one plugin as part of ThunderNanoservices, and Nano or microservices should configured as part of any of these subsystems.

Designed for Apps:

• Pre-integrated premium apps
• Pre-integrated app store
• Voice enabled
• Lightning^tm App Dev Language

Architecture

RDK4 Building Blocks

• The modularity of RDK4 reduces the app development life cycle.

• Core - Components Every RDK Build will need regardless of operator
• Localization - Optional Components that can be added depending on operator requirements

RDK Firebolt ® Video App Platform

RDK Firebolt ® SDK  is a development environment for applications targeted to run on RDK. Firebolt ® SDK can be used by application developers to develop HTML5, Spark & Native applications for RDK. The SDK comes with an RDK image which can be loaded on the target platform on which applications can be developed and executed.

• Firebolt ® is RDK4's Video Application Platform, leveraged by both RDK & non-RDK systems.

• Firebolt ® can empower non-RDK Systems

Thunder Framework

Application framework is built on Hardware abstraction Layer, on top of abstraction layer there is a WPE Framework. WPE framework itself dispatched internally that actually starts micro and nano services. Micro and Nano services are exposed to certain interfaces so at the end the system can locked down and executing.

From Apps, there are external input interface that can send in JSONRPC messages, JSONRPC messages through dispatcher will be routed to proper micro/nano services.

Modular architecture

• The system is build up from several  layers. The functionality is contained in  modules.

Separation of concern

• A nano/micro service has its own  dedicated task/function and fulfils this.  No managers!

Interface based

• Interconnection between plugins is  based on interfaces.

Architectural focus

Agnostic to process boundaries (JSONRPC/COMRPC)

• For security and stability functionality is realized in contained processes.To communicate to process boundaries we need JSONRPC/COMRPC.

Integral implementation of security features 

• LXC containerisation, including users and groups per processes.

Small footprint, low resource usage

• Building it, only requires ZLIB.

Uniformity

• All configuration is stored as JSON and read from 1 location,RESTFull API alignment  JSON field names always lowercase, path names Pascal case.

Features

WebControl

• WPEFramework can be controlled from a webbrowser client on your PC.

Scoped Traceability (controlled from Web)

• Fine granularity, trace what you need, Web Browser UI to control it all..

Execution architecture (resource constrained)

• One thread to communicate all.Thread pools.

Ease of use when building a plugin

• Object oriented approach for communication (JSON, HTTP, WebSocket, COM/JSON RPC).

No hard-linked dependencies.

• There is NO dependency between the plugins. Use subsystems !!!!

JSONRPC/COMRPC Process transparency

 Most important part of framework is to make sure we can run processes & separate process,we can run nano/micro services out of process.So,we need to communicate to nano/micro services throughout API's.

These API's are actually incremented in 2 ways.

1. JSONRPC : Mainly targeted towards Javascript.Javascript talks to JSONRPC , Communication Layer goes into framework then it transit to C and C++ world,then from C and C++ world we can far communicate back to Javascript using JSONRPC .
2. COMRPC : Internally when we want to communicate with different nano/micro services running in different process we can use COMRPC Process.

COMRPC

COMRPC is a binary RPC migration

• Marshalling code,Proxy/Stubs are generated from the C header file!!

Interfaces

C header files with a struct definition and pure abstract methods

• It is based on interfaces and its regular struct in header file that is to contract to actually closed down between two plugins or two instances of C&C++.
• This struct and interface is to find how we communicate with other plugin or other nano/micro services.
• If we define structs there is an application that actually creates marshalling code.

COMRPC

QueryInterface/AddRef/Release

• Under struct,there is a layer coming from WPEframework that is called "COMRPC"
• COMRPC will make sure Pluming URT isn't there so the queryInterface/AddRef/Release will make sure we can do navigation over the interfaces that  our lifetime on the interfaces.

Communication Layers

• Domain Sockets
• TCP Socket

COMRPC migration is part of WPEFramework.If we have COMRPC 'C' migration,the communication layer below are main sockets for TCP Server.It means we could communicate with any interface to other host.

JSONRPC

JSONRPC is to communicate JSON object  messages.

 JSON data objects,boiler plated handlers and documentation are generated from a JSON specification file!!

JSON

Actual exchange data in JSON format : RFC4627

• RFC4627,this is the data message and contract between to separate nano/micro services.
• This is typically used from web world(from spark or from webkit itself).
• The relying of the message and pluming is done using JSONRPC.

JSONRPC

For deeper and detailed information of JSONRPC ,Please refer https://www.jsonrpc.org/specification 

Communication Layers

• RESTFUL (Web World)
• WebSocket (Web World)

Execution Architecture

• If a command comes in on settop box ,it will actually be turn into message for eg in above figure ,the Webkit browser will send this message through pipeline to framework.
  Three pipelines coming out of the settop box,different pipelines for different kind of messages.
• Received message will be deserialized that is getting back to original message and do get cpu usage.After which,we will look at the message where it has to sent to,that message will be packed with where it will send to and it is forward on to threadpool.
• The threadpool are actually multiple threads maintained by multiple persons.Person pickups the job and secure it ,As in diagram the person is evaluating CPU Usage using machine,CPU Usage value is noted down on the message(eg:CPU usage is 50% in above figure) and send back to from where we initially got the message.
• Here messages are handled by thread switch.One is communication thread and the other is thread that handled our request.This way the amount of threads used in the system will not increase when multiple connections are created,the more connections you create it will not lead to multiple threadings .

Resources opened up through JSONRPC

This gives us information regarding once system is ready ,what kind of micro/nano services are all available.
Difference between micro and nano is that micro service actually requires graphics -graphical resources or player resources

Compositor client

Compositor client compile time will be fine whether the real implementation behind it is wayland,Nexus or RPI.
Micro services themselves will use the interface of the compositor client.Micro services will not know which compositor they are using.
The implementation of compositor client actually does the communication with compositor, depending on the implementation it could be Waylanda,Nexus or RPI communication.