docs/afb-overview.md

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