Openbravo 2.50: Data Access Layer in the overall Openbravo Architecture

This post discusses the architecture of the new Data Access Layer and its place in the rest of the current and future envisioned architecture.

The image below illustrates the different layers of the Openbravo architecture. Part of the architecture is delivered in 2.50 other parts will be delivered in future releases.


The Data Access Layer (DAL) uses the application dictionary as the basis for its operations. The application dictionary defines the tables, columns and data types in Openbravo (for example Business Partner, Sales Order, etc.). The Data Access Layer uses the application dictionary for two purposes:

• to generate Java business objects at development time
• at runtime to generate a Hibernate mapping to persist the business objects

To perform these two steps the DAL reads the application dictionary from the database and builds an in-memory representation. This is called the runtime model. Having the model in-memory makes it possible to use the model in an efficient way for different kinds of tasks (security checking, validation, etc.)

So at development time Java business objects are generated for each table in the system. The columns of the table corresponds to properties (getters/setters) in the generated Java class. The foreign key columns are present as references to other generated business objects. The business object generation is done as part of the standard Openbravo build steps. The generated classes can be found in the src-gen folder in the openbravo development project.

At runtime the DAL is responsible for generating the mapping for Hibernate and configuring Hibernate.
The DAL provides an API to store, query and remove business objects from the database. This DAL service layer takes care of validation and security checks. In a future Openbravo release this API will be used to develop the business logic layer. The business logic layer will replace the current stored procedures and triggers. The business service layer will provide an API to the outside world to run business logic within Openbravo.

Two other interesting components are also present: UI and Web Services. Integrating the DAL into the UI will be done in a future release. In 2.50 we provide a REST webservice layer which provides CRUD operations on all Openbravo business objects. I will discuss the REST Webservice support in the next post.

At runtime the DAL takes care of transaction handling and providing a context in which all DAL operations run. The transaction handling is done using the open-session-in-view pattern whereby the developer in general does not need to take care of transaction handling explicitly (but he/she can ofcourse when required). The Openbravo context object makes it easy for a developer to retrieve the current user object and other context information.

The following parts of the new architecture are delivered as part of 2.50:

• Runtime Model
• Generation of Business Object and Hibernate Mapping
• DAL API
• REST Webservices
• Transaction Handling and User Context

The other components will be delivered as part of subsequent releases.

For more information here are two wiki documents which give some more details:

• DAL Functional Spec
• DAL Developers Guide

This hopefully gives a feel for the overall current and future architecture of Openbravo. In the next blog post I will discuss the new REST Webservice functionality in Openbravo 2.50.