docs/3_Developer_Guides/2_Application_Framework_Binder/0_Overview.md

   1 ---
   2 title: Overview
   3 ---
   4
   5 The ***binder*** provides the way to connect applications to
   6 the services that it needs.
   7
   8 It provides a fast way to securely offer APIs to applications
   9 written in any language and running almost anywhere.
  10
  11 - The ***binder*** is developed for AGL (Automotive Grade Linux) but it is not bound to AGL.
  12 - The ***binder*** is the usual name.
  13 - The binary is named **afb-daemon**.
  14 - The name **afb-daemon** stands for ***Application Framework Binder Daemon***.
  15
  16 The word *daemon*, here, denote the fact that the ***binder*** makes witchcraft to
  17 connect applications to their expected services. (note: that usually the term of
  18 daemon denotes background process but not here).
  19
  20 Each ***binder*** **afb-daemon** is in charge to bind one instance of
  21 an application or service to the rest of the system, applications and services.
  22 Within AGL, the connection between services and/or applications
  23 is tuned by the AGL framework and the AGL system.
  24
  25 ## The basis of the binder
  26
  27 The following figure shows main concepts linked to the ***binder***.
  28
  29 ![Figure: binder basis](images/basis.svg)
  30
  31 The shown elements are:
  32
  33 - The SECURITY CONTEXT
  34
  35     The primary intention of any ***binder*** is to provide
  36     a secured environment for any application.
  37     On AGL, the   **security context** is ensured by [Smack]
  38     , the security context of the application or service.
  39
  40 - The BINDER
  41
  42     This is the central element.
  43     It makes possible to run HTML5 applications and provides
  44     the unified access to APIs provided by the ***bindings***.
  45
  46     Running a pure HTML5 application doesn't require any ***binding***.
  47     In that case , the ***binder*** acts as a simple HTTP server for
  48     the web runtime.
  49
  50 - The BINDINGs
  51
  52     A ***binding*** adds one **API** to the ***binder***.
  53
  54     An **API** is a set of **verbs** that can be called
  55     using either REST over HTTP or a kind of JSON RPC.
  56
  57     ***bindings*** are either:
  58
  59     - dynamically loaded libraries in the ***binder*** process
  60     - remote service running on the same host
  61     - remote service running on other hosts
  62
  63     When acting as an HTTP server, the binder treats the language
  64     settings of the HTTP requests to provide internationalized
  65     content as specified by
  66     [widget
  67     specifications](https://www.w3.org/TR/widgets/#internationalization-and-localization).
  68
  69 - The APPLICATION
  70
  71     An ***application*** connects to the binder to get access to
  72     the **API** that it provides or to get its HTTP services to access
  73     resources.
  74
  75 ## Interconnection of binders
  76
  77 The AGL framework interprets the **widget/application** manifests
  78 to setup the ***bindings*** configuration of the ***binders***.
  79
  80 The figure below shows that ***binders*** are interconnected.
  81
  82 ![Figure: binder interconnection](images/interconnection.svg)
  83
  84 The figure shows 4 several **application/service**: **A**, **B**,
  85 **C** and **D**.
  86
  87 The application **A** might use an **API** that is shown as a
  88 local ***binding*** but that in reality runs within the context
  89 of **D**.
  90
  91 The framework AGL takes care of making the plumbing working.