Added Application Framework Binder in Developer Guides

Revised and added Application Framework Binder as a part of Developer Guides.

v2 : Corrected typo : MACRO -> MACROS

Bug-AGL: [SPEC-3633]

Signed-off-by: Shankho Boron Ghosh <shankhoghosh123@gmail.com>
Change-Id: I7a6d6206f69ed44a18011c81f475ce5eac306a33
Reviewed-on: https://gerrit.automotivelinux.org/gerrit/c/AGL/documentation/+/25663
Reviewed-by: Jan-Simon Moeller <jsmoeller@linuxfoundation.org>
Tested-by: Jan-Simon Moeller <jsmoeller@linuxfoundation.org>

1 files changed, 91 insertions, 0 deletions

diff --git a/docs/3_Developer_Guides/2_Application_Framework_Binder/0_Overview.md b/docs/3_Developer_Guides/2_Application_Framework_Binder/0_Overview.md
new file mode 100644
index 0000000..1b2163c
--- /dev/null
+++ b/docs/3_Developer_Guides/2_Application_Framework_Binder/0_Overview.md
@@ -0,0 +1,91 @@
+---
+title: Overview
+---
+
+The ***binder*** provides the way to connect applications to
+the services that it needs.
+
+It provides a fast way to securely offer APIs to applications
+written in any language and running almost anywhere.
+
+- The ***binder*** is developed for AGL (Automotive Grade Linux) but it is not bound to AGL.
+- The ***binder*** is the usual name.
+- The binary is named **afb-daemon**.
+- The name **afb-daemon** stands for ***Application Framework Binder Daemon***.
+
+The word *daemon*, here, denote the fact that the ***binder*** makes witchcraft to
+connect applications to their expected services. (note: that usually the term of
+daemon denotes background process but not here).
+
+Each ***binder*** **afb-daemon** is in charge to bind one instance of
+an application or service to the rest of the system, applications and services.
+Within AGL, the connection between services and/or applications
+is tuned by the AGL framework and the AGL system.
+
+## The basis of the binder
+
+The following figure shows main concepts linked to the ***binder***.
+
+![Figure: binder basis](pictures/basis.svg)
+
+The shown elements are:
+
+- The SECURITY CONTEXT
+
+    The primary intention of any ***binder*** is to provide
+    a secured environment for any application.
+    On AGL, the   **security context** is ensured by [Smack]
+    , the security context of the application or service.
+
+- The BINDER
+
+    This is the central element.
+    It makes possible to run HTML5 applications and provides
+    the unified access to APIs provided by the ***bindings***.
+
+    Running a pure HTML5 application doesn't require any ***binding***.
+    In that case , the ***binder*** acts as a simple HTTP server for
+    the web runtime.
+
+- The BINDINGs
+
+    A ***binding*** adds one **API** to the ***binder***.
+
+    An **API** is a set of **verbs** that can be called
+    using either REST over HTTP or a kind of JSON RPC.
+
+    ***bindings*** are either:
+
+    - dynamically loaded libraries in the ***binder*** process
+    - remote service running on the same host
+    - remote service running on other hosts
+
+    When acting as an HTTP server, the binder treats the language
+    settings of the HTTP requests to provide internationalized
+    content as specified by
+    [widget
+    specifications](https://www.w3.org/TR/widgets/#internationalization-and-localization).
+
+- The APPLICATION
+
+    An ***application*** connects to the binder to get access to
+    the **API** that it provides or to get its HTTP services to access
+    resources.
+
+## Interconnection of binders
+
+The AGL framework interprets the **widget/application** manifests
+to setup the ***bindings*** configuration of the ***binders***.
+
+The figure below shows that ***binders*** are interconnected.
+
+![Figure: binder interconnection](pictures/interconnection.svg)
+
+The figure shows 4 several **application/service**: **A**, **B**,
+**C** and **D**.
+
+The application **A** might use an **API** that is shown as a
+local ***binding*** but that in reality runs within the context
+of **D**.
+
+The framework AGL takes care of making the plumbing working.
\ No newline at end of file