docs/4_APIs_and_Services/4.3_Application_Framework_Binder/1_Binder_daemon_vocabulary/1_Binder_daemon_vocabulary.md

   1 ---
   2 edit_link: ''
   3 title: Binder daemon vocabulary
   4 origin_url: >-
   5   https://git.automotivelinux.org/src/app-framework-binder/plain/docs/afb-daemon-vocabulary.md?h=master
   6 ---
   7
   8 <!-- WARNING: This file is generated by fetch_docs.js using /home/boron/Documents/AGL/docs-webtemplate/site/_data/tocs/apis_services/master/app-framework-binder-developer-guides-api-services-book.yml -->
   9
  10 # Vocabulary for AFB-DAEMON
  11
  12 ## Binding
  13
  14 A shared library object intended to add a functionality to an afb-daemon
  15 instance.
  16 It implements an API and may provide a service.
  17
  18 Binding made for services can have specific entry points called after
  19 initialization and before serving.
  20
  21 ## Event
  22
  23 Messages with data propagated from the services to the client and not expecting
  24 any reply.
  25
  26 The current implementation allows to widely broadcast events to all clients.
  27
  28 ## Level of assurance (LOA)
  29
  30 This level that can be from 0 to 3 represent the level of
  31 assurance that the services can expect from the session.
  32
  33 The exact definition of the meaning of these levels and how to use it remains to
  34 be achieved.
  35
  36 ## Request
  37
  38 A request is an invocation by a client to a binding method using a message
  39 transferred through some protocol:
  40
  41 - HTTP
  42 - WebSocket
  43 - ...
  44
  45 and served by ***afb-daemon***
  46
  47 ## Reply/Response
  48
  49 This is a message sent to client as the result of the request.
  50
  51 ## Service
  52
  53 Service are made of bindings running on a binder
  54 The binder is in charge of connecting services and applications.
  55 A service can serve many clients.
  56
  57 The framework establishes connection between the services and the clients.
  58 Using sockets currently but other protocols are considered.
  59
  60 The term of service is tightly bound to the notion of API.
  61
  62 ## Session
  63
  64 A session is meant to be the unique instance context of a client,
  65 which identify that instance across requests.
  66
  67 Each session has an identifier.
  68 Session identifier generated by afb-daemon are UUIDs.
  69 A client can present its own session id.
  70
  71 Internally, afb-daemon offers a mechanism to attach data to sessions.
  72 When a session is closed or disappears, data attached to that session
  73 are freed.
  74
  75 ## Token
  76
  77 The token is an identifier that the client must give to be authenticated.
  78
  79 At start, afb-daemon get an initial token.
  80 This initial token must be presented by incoming client to be authenticated.
  81
  82 A token is valid only for a period.
  83
  84 The token must be renewed periodically.
  85 When the token is renewed, afb-daemon sends the new token to the client.
  86
  87 Tokens generated by afb-daemon are UUIDs.
  88
  89 ## UUID
  90
  91 It stand for Universal Unique IDentifier.
  92
  93 It is designed to create identifier in a way that avoid has much as possible
  94 conflicts.
  95 It means that if two different instances create an UUID, the
  96 probability that they create the same UUID is very low, near to zero.
  97
  98 ## x-afb-reqid
  99
 100 Argument name that can be used with HTTP request.
 101 When this argument is given, it is automatically added to the "request" object of the answer.
 102
 103 ## x-afb-token
 104
 105 Argument name meant to give the token without ambiguity.
 106 You can also use the name **token** but it may conflicts with others arguments.
 107
 108 ## x-afb-uuid
 109
 110 Argument name for giving explicitly the session identifier without ambiguity.
 111 You can also use the name **uuid** but it may conflicts with others arguments.