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.
• RDK Services - RDK Services are set of services used to access device specific functionality.RDK Services are available for launching browser and native applications.It is built on WPE Framework (aka Thunder).

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 RDK Services 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 RDK Services, 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

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 containarisation, 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.