aboutsummaryrefslogtreecommitdiffstats
path: root/docs/afb-overview.md
blob: 67e5b0d10a3eafe2c4d3dd9bd6bac5073f92b761 (plain)
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
92
93
94
95
96
97
98
Overview of the binder
======================

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 developped 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 connexion 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][Smack] a security context,
  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 resquests 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.

<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 ***binbing*** but that in reality runs within the context
of **D**.

The framework AGL takes care of making the plumbing working.