Openbravo 3.0 Architecture

In Openbravo 3.0 the Openbravo ERP system moves away from a classic servlet architecture to a Rich Internet Application (RIA) architecture. This is a radical paradigm shift resulting in a much more dynamic and versatile user interface. In a RIA architecture the requests for data and for the page/user interface are separated. The page/user interfaces is loaded on the client once and then re-used while the user works in the application. This in contrast for requests for data and actions, these are executed continuously.


The Openbravo 3.0 architecture is implemented using Openbravo Core and several related modules:
The JSON module provides the JSON REST web service, it is used for the client-server data communication
The Weld module provides dependency injection and component management
The Kernel module takes care of infrastructure tasks as request processing, event handling, compression and caching
The DataSource module uses the JSON module and provides higher level data request functionality for querying and data related actions
The Smartclient module provides the Smartclient user interface library
The application module contains the implementation of the navigation bar, grids and forms and other application oriented client and server side code.


This guide explains the concepts implemented by these modules.

Presentation on Openbravo 3.0 architecture

The following link provides an online presentation on the Openbravo 3.0 architecture concepts:

Main Concepts: Component and Component Provider

This section introduces central concepts of the Openbravo 3.0 user interface. The Openbravo 3.0 user interface is implemented by so-called components. A component is a specific part of the user interface. It can be a selector, a field on a form, but also a complete layout, or a form or grid.

Components are implemented in modules. A module has complete freedom on how to implement components (if there is a window table, a grid table or a generic view table etc.). The components within a module are managed by a Component Provider, it is responsible for creating a component and providing it to the Openbravo kernel. A component provider is also responsible for registering the static content with Openbravo, this is explained in more detail below.
A component can be retrieved using a URL (a component request). For example this URL will retrieve the javascript for the sales invoice window:
To explain the structure of this url, the OBUIAPP_MainLayout identifies the client application module. The ComponentProvider of that module knows how to handle the last part of the url: View?viewId=_167. It will create a StandardWindowComponent which gets the viewId (the ADWindow id) to generate the javascript. The generated javascript is postprocessed (compressed, syntax checking) before it is send to the client.
The following image illustrates the request flow processing in more detail:


The overall request and generate flow operates as follows:
a component request (with a component type and id) is received by the Client Kernel module (in the KernelServlet).
based on the component type the kernel module finds the module responsible for handling the requested component, that module is then called to create the component using the component id.
the module reads the component definition from tables or other sources and instantiates the Component instance.

the component is called to generate its client-side representation.
if it is a templated component (i.e. it has a specific template) then the component calls a template processor for the template.
the view is generated using the template or by executing javacode which generates a String (javascript).

the result (often a javascript string) is returned to the Client Kernel module.
the Client Kernel module processes the result: 1) checks the syntax of the result (using jslint, 2) compresses it using jsmin.
Note the Client Kernel module also takes care of caching components and component requests. This is covered in a later section in this documentation in more detail.

Introducing Weld: dependency injection and more

Weld implements the JSR-299: Java Contexts and Dependency Injection for the Java EE platform (CDI). CDI is the Java standard for dependency injection and contextual lifecycle management. For general information on dependency injection concepts visit this page.
Weld documentation is available here.

An internal technical session on Weld is available on youtube here.
Core parts of the Openbravo architecture use Weld for dependency injection, component definition and business entity events. The starting point is defining components and the scope in which they live. The next step is using these components by injecting them in other components. Note, to make use of Weld dependency injection it is not possible to create objects using the classic java new keyword. See a later section below on this topic.

Print Friendly

Leave a Reply