doc/02_architecture.rst

   1 ============
   2 Architecture
   3 ============
   4
   5 OpenERP as a multitenant three-tiers architecture
   6 =================================================
   7
   8 This section presents the OpenERP architecture along with technology details
   9 of the application. The tiers composing OpenERP are presented. Communication
  10 means and protocols between the application components are also presented.
  11 Some details about used development languages and technology stack are then summarized.
  12
  13 OpenERP is a `multitenant <http://en.wikipedia.org/wiki/Multitenancy>`_, `three-tiers architecture
  14 <http://en.wikipedia.org/wiki/Multitier_architecture#Three-tier_architecture>`_:
  15 database tier for data storage, application tier for processing and functionalities
  16 and presentation tier providing user interface. Those are separate layers
  17 inside OpenERP. The application tier itself is written as a core; multiple
  18 additional modules can be installed in order to create a particular instance
  19 of OpenERP adapted to specific needs and requirements. Moreover, OpenERP
  20 follows the Model-View-Controller (MVC) architectural pattern.
  21
  22 A typical deployment of OpenERP is shown on `Figure 1`_. This deployment is
  23 called Web embedded deployment. As shown, an OpenERP system consists of
  24 three main components:
  25
  26 - a PostgreSQL database server which contains all OpenERP databases.
  27   Databases contain all application data, and also most of the OpenERP
  28   system configuration elements. Note that this server can possibly be
  29   deployed using clustered databases.
  30 - the OpenERP Server, which contains all the enterprise logic and ensures
  31   that OpenERP runs optimally. One layer of the server is dedicated to
  32   communicate and interface with the PostgreSQL database, the ORM engine.
  33   Another layer allows communications between the server and a web browser,
  34   the Web layer. Having more than one server is possible, for example in
  35   conjunction with a load balancing mechanism.
  36 - the client running in the a web browser as javascript application.
  37
  38 The database server and the OpenERP server can be installed on the same
  39 computer, or distributed onto separate computer servers, for example for
  40 performance considerations.
  41
  42 .. _`Figure 1`:
  43 .. figure:: _static/02_openerp_architecture.png
  44    :width: 50%
  45    :alt: OpenERP 6.1 architecture for embedded web deployment
  46    :align: center
  47
  48    OpenERP 6.1 architecture for embedded web deployment
  49
  50 The next subsections give details about the different tiers of the OpenERP
  51 architecture.
  52
  53 PostgreSQL database
  54 +++++++++++++++++++
  55
  56 The data tier of OpenERP is provided by a PostgreSQL relational database.
  57 While direct SQL queries can be executed from OpenERP modules, most accesses
  58 to the relational database are done through the server Object Relational
  59 Mapping layer.
  60
  61 Databases contain all application data, and also most of the OpenERP system
  62 configuration elements. Note that this server can possibly be deployed using
  63 clustered databases.
  64
  65 OpenERP server
  66 ++++++++++++++
  67
  68 OpenERP provides an application server on which specific business applications
  69 can be built. It is also a complete development framework, offering a range
  70 of features to write those applications. Among those features, the OpenERP
  71 ORM provides functionalities and an interface on top of the PostgreSQL server.
  72 The OpenERP server also features a specific layer designed to communicate
  73 with the web browser-based client. This layer connects users using standard
  74 browsers to the server.
  75
  76 From a developer perspective, the server acts both as a library which brings
  77 the above benefits while hiding the low-level details, and as a simple way
  78 to install, configure and run the written applications. The server also contains
  79 other services, such as extensible data models and view, workflow engine or
  80 reports engine. However, those are OpenERP services not specifically related
  81 to security, and are therefore not discussed in details in this document.
  82
  83 **Server - ORM**
  84
  85 The Object Relational Mapping ORM layer is one of the salient features of
  86 the OpenERP Server. It provides additional and essential functionalities
  87 on top of PostgreSQL server. Data models are described in Python and OpenERP
  88 creates the underlying database tables using this ORM. All the benefits of
  89 RDBMS such as unique constraints, relational integrity or efficient querying
  90 are used and completed by Python flexibility. For instance, arbitrary constraints
  91 written in Python can be added to any model. Different modular extensibility
  92 mechanisms are also afforded by OpenERP.
  93
  94 It is important to understand the ORM responsibility before attempting to
  95 by-pass it and to access directly the underlying database via raw SQL queries.
  96 When using the ORM, OpenERP can make sure the data remains free of any corruption.
  97 For instance, a module can react to data creation in a particular table.
  98 This behavior can occur only if queries go through the ORM.
  99
 100 The services granted by the ORM are among other :
 101
 102  - consistency validation by powerful validity checks,
 103  - providing an interface on objects (methods, references, ...) allowing
 104    to design and implement efficient modules,
 105  - row-level security per user and group; more details about users and user
 106    groups are given in the section Users and User Roles,
 107  - complex actions on a group of resources,
 108  - inheritance service allowing fine modeling of new resources
 109
 110 **Server - Web**
 111
 112 The web layer offers an interface to communicate with standard browsers.
 113 In the 6.1 version of OpenERP, the web-client has been rewritten and integrated
 114 into the OpenERP server tier. This web layer is a WSGI-compatible application
 115 based on werkzeug. It handles regular http queries to server static file or
 116 dynamic content and JSON-RPC queries for the RPC made from the browser.
 117
 118 **Modules**
 119
 120 By itself, the OpenERP server is a core. For any enterprise, the value of
 121 OpenERP lies in its different modules. The role of the modules is to implement
 122 any business requirement. The server is the only necessary component to
 123 add modules. Any official OpenERP release includes a lot of modules, and
 124 hundreds of modules are available thanks to the community. Examples of
 125 such modules are Account, CRM, HR, Marketing, MRP, Sale, etc.
 126
 127 Clients
 128 +++++++
 129
 130 As the application logic is mainly contained server-side, the client is
 131 conceptually simple. It issues a request to the server, gets data back
 132 and display the result (e.g. a list of customers) in different ways
 133 (as forms, lists, calendars, ...). Upon user actions, it sends queries
 134 to modify data to the server.
 135
 136 The default client of OpenERP is an JavaScript application running in the
 137 browser that communicates with the server using JSON-RPC.
 138
 139 MVC architecture in OpenERP
 140 ===========================
 141
 142 According to `Wikipedia <http://en.wikipedia.org/wiki/Model-view-controller>`_,
 143 "a Model-view-controller (MVC) is an architectural pattern used in software
 144 engineering". In complex computer applications presenting lots of data to
 145 the user, one often wishes to separate data (model) and user interface (view)
 146 concerns. Changes to the user interface does therefore not impact data
 147 management, and data can be reorganized without changing the user interface.
 148 The model-view-controller solves this problem by decoupling data access
 149 and business logic from data presentation and user interaction, by
 150 introducing an intermediate component: the controller.
 151
 152 .. _`Figure 3`:
 153 .. figure:: _static/02_mvc_diagram.png
 154    :width: 35%
 155    :alt: Model-View-Controller diagram
 156    :align: center
 157
 158    Model-View-Controller diagram
 159
 160 For example in the diagram above, the solid lines for the arrows starting
 161 from the controller and going to both the view and the model mean that the
 162 controller has a complete access to both the view and the model. The dashed
 163 line for the arrow going from the view to the controller means that the view
 164 has a limited access to the controller. The reasons of this design are :
 165
 166  - From **View** to **Model** : the model sends notification to the view
 167    when its data has been modified in order the view to redraw its content.
 168    The model doesn't need to know the inner workings of the view to perform
 169    this operation. However, the view needs to access the internal parts of the model.
 170  - From **View** to **Controller** : the reason why the view has limited
 171    access to the controller is because the dependencies from the view to
 172    the controller need to be minimal: the controller can be replaced at
 173    any moment.
 174
 175 OpenERP follows the MVC semantic with
 176
 177  - model : The PostgreSQL tables.
 178  - view : views are defined in XML files in OpenERP.
 179  - controller : The objects of OpenERP.
 180
 181 Network communications and WSGI
 182 ===============================
 183
 184 OpenERP is an HTTP web server and may also be deployed as an WSGI-compliant
 185 application.
 186
 187 Clients may communicate with OpenERP using sessionless XML-RPC, the recommended
 188 way to interoperate with OpenERP. Web-based clients communicates using the
 189 session aware JSON-RPC.
 190
 191 Everything in OpenERP, and objects methods in particular, are exposed via
 192 the network and a security layer. Access to the data model is in fact a ‘service’
 193 and it is possible to expose new services. For instance, a WebDAV service and
 194 a FTP service are available.
 195
 196 Services can make use of the `WSGI
 197 <http://en.wikipedia.org/wiki/Web_Server_Gateway_Interface>`_ stack. WSGI is a
 198 standard solution in the Python ecosystem to write HTTP servers, applications,
 199 and middleware which can be used in a mix-and-match fashion. By using WSGI, it
 200 is possible to run OpenERP in any WSGI compliant server. It is also possible to
 201 use OpenERP to host a WSGI application.
 202
 203 A striking example of this possibility is the OpenERP Web layer that is
 204 the server-side counter part to the web clients. It provides the requested
 205 data to the browser and manages web sessions. It is a WSGI-compliant application.
 206 As such, it can be run as a stand-alone HTTP server or embedded inside OpenERP.
 207
 208 The HTTP namespaces /openerp/ /object/ /common/ are reserved for the XML-RPC
 209 layer, every module restrict it's HTTP namespace to /<name_of_the_module>/
 210
 211 Process model
 212 =============
 213
 214 In the past, the OpenERP server was using threads to handle HTTP requests
 215 concurrently or to process cron jobs. Using threads is still the default
 216 behavior when running the ``openerp-server`` script but not the recommended
 217 one: it is in fact recommended to use the ``--workers`` option.
 218
 219 By using the ``--workers`` option, the OpenERP server will spawn a fixed number
 220 of processes instead of spawning a new thread for each incoming request.
 221
 222 This has a number of advantages:
 223
 224  - Processes do not suffer from CPython's Global Interpreter Lock.
 225  - Processes can be gracefully recycled while requests are still handled by the
 226    server.
 227  - Resources such as CPU time and memory made available to a process can be
 228    monitored on a per-process basis.
 229
 230 When using the ``--workers`` options, two types of processes may be spawned:
 231 web process, and cron process.
 232
 233 .. versionadded:: 7.1
 234
 235 .. _longpolling-worker:
 236
 237 When using the ``--workers`` options, three types of processes may be spawned:
 238 web process, and cron process, just as previsouly, but also an evented (using
 239 gevent) web process is started. It is used for long-polling as needed by the
 240 upcoming Instant Messaging feature. As for now, that process is listening on a
 241 different port than the main web processes. A reverse proxy (e.g. Nginx) to
 242 listen on a unique port, mapping all requests to the normal port, but mapping
 243 the ``/longpolling`` route to the evented process is necessary (the web
 244 interface cannot issue requests to different ports).
 245
 246 (It is possible to make the threaded server evented by passing the ``--gevent``
 247 flag.)
 248
 249 The goal is to drop support for the threaded model, and also make all web
 250 processes evented; there would be no more distinction between "normal" and
 251 "longpolling" processes. For this to happen, further testing is needed.
 252