blob: d0615ed5224a57729962f82d375b20b8f6d039ce (
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
99
|
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][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 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.
|