docs/afb-overview.md


1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91

.highlight .hl# Binder 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.
- 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***.

<a id="fig-binder-basis"></a>
![Figure: binder basis](pictures/basis.svg)

The shown elements are:

- The SECURITY CONTEXT

  The primary intend 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.

<!-- pagebreak -->

## 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.

<a id="fig-binder-interconnection"></a>
![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.