New platform - White Paper

This document is a work in progress. It will be available for review and feedback until 01-08-2007. Feel free to comment on it at Openbravo Green Sourceforge forum . Consider it as an index, more content will be gradually added. Once the design principles are frozen, we plan to continue with the detailed architecture design documents, which will also be subject of discussion for a period of time.

Contents 1 General architecture 1.1 Spring 1.1.1 What is Spring? 1.1.2 Key features 1.1.3 Benefits for Openbravo 1.2 DAO layer: Hibernate 1.2.1 What is Hibernate? 1.2.2 Key features 1.2.3 Benefits for Openbravo 1.3 Service Layer 1.3.1 Exposing the service layer 1.3.2 Implementing the service layer 1.4 Presentation layer 1.5 Client side 1.6 Web browser user interface 2 Enterprise capabilities 2.1 Security: Authentication and authorization 2.2 Auditing, logging, monitoring 2.3 Integration 2.4 Job scheduling. Quartz 2.5 Portlets. JSR 168 2.6 Software as a service (SaaS) 2.7 Modularity 2.8 Internationalization 3 Service Oriented Architecture (SOA) 3.1 BPEL 3.2 ESB 4 Application functionalities 4.1 Windows 4.2 Reporting 4.3 Workflow 4.4 Help system 4.5 Search tool 4.6 Query tool 4.7 Import/Export data 5 Development 5.1 Style guidelines 5.2 Source code documentation 5.3 Version control system 5.4 Change log 5.5 Unit testing 5.6 Source code metrics 5.7 Environment 5.8 Nightly builds 6 Release management 6.1 Certification documents 6.2 Execution environments 6.3 Install tool 6.4 Bug tracking tool 6.5 Testing tool

General architecture

Spring

What is Spring?

Spring is a lightweight framework for building Java applications. It can be used to build any application in Java and it is not just limited to web applications. The lightweight part of the description doesn’t refer to the number of classes or size of the distribution, but rather, it defines the principle of the Spring philosophy as a whole: minimal impact. You have to make few changes to your application code to gain the benefits of the Spring core. And if you choose to discontinue using it at any point, it is simple.

Key features

The Spring framework can be considered as a collection of smaller frameworks. It is a layered architecture consisting of seven modules. Its main features are the following.

• Core container.

It provides the essential functionality: defines how beans are created, configured, and managed. The other modules are built on top of this one.

• Dependency injection.

The core of the spring framework is based in the principle of Inversion of Control (IoC). The basic concept of the this pattern is that you do not create your objects but describe how they should be created. You don't directly connect your components and services together in code but describe which services are needed by which components in a configuration file. The IoC container is then responsible for hooking it all up.

In a typical IoC scenario, the container creates all the objects, wires them together by setting the necessary properties, and determines when methods will be invoked.

• Aspect-oriented programming (AOP) framework.

AOP provides the ability to implement crosscutting logic (logic that applies to many parts of your application) in a single place and to have that logic applied across your application automatically. There are many applications for AOP. As well as providing logging, it is used for many purposes, particularly in transaction management.

• DAO.

The Spring JDBC DAO layer offers a meaningful exception hierarchy for managing the exception handling and error messages thrown by different database vendors.

• Object Relational Mapping (ORM).

Supports several ORM frameworks to provide its Object Relational tool, including Hibernate, JDO and iBatis. These 3 options comply to Spring's generic transaction and DAO exception hierarchies.

• Security.

Full integration with Acegi Security, featuring comprehensive authentication, authorization, instance-based access control and channel security.

• Web framework.

It is built on top of the application context module, providing contexts for Web-based applications.

• MVC framework.

The Model-View-Controller (MVC) framework is a full-featured MVC implementation for building Web applications. It is highly configurable via strategy interfaces and accommodates numerous view technologies including JSP, Velocity or XmlEngine.

• Remote access framework.

Spring provides support for a variety of remote access mechanisms, including Java RMI and more. In addition, it has its own HTTP-based protocol that is based in the standard Java serialization.

This makes possible to export a service without needing to have implementation-specific code in the application.

• Unit testing.

Provides first class testing support. Support classes for writing unit tests and integration tests.

Benefits for Openbravo

• Better and more automated transaction management.
• Advanced security by Acegi.
• Pluggable architecture.
• Wide-known and proven standards.
• Faster development.
• Integration: web services.

DAO layer: Hibernate

What is Hibernate?

Hibernate is a free, open source Java package that makes it easy to work with relational databases. It makes it seem as if the database contains plain Java objects, without having to worry about how to get them out of database tables. It liberates the developer to focus on the objects and features of the application, without having to worry about how to store them or find them later. So to sum up, it’s an easy and efficient way to work with information from a relational database in the form of natural Java objects.

Key features

• Database independence.

One of the advantages of using the ORM (Object relational mapping) tools is to be transparent to the database. therefore the developed application should be independent of any changes made to the database. Changing from one database to another only means changing one hibernate.cfg.xml configuration file. It supports a wide range of databases, including Oracle, MySQL, PostgreSQL, DB2, SAP DB, Informix, MS SQL Server and more.

• Object-oriented query language (HQL).

It has its own query language, called HQL (Hibernate Query Language). It’s similar to SQL, but instead of treating with tables, objects are queried. However, if requires, queries may be expressed standard SQL, or even in the native SQL dialect of the chosen database.

• Transparent persistence without byte code processing.

• Flexible Object / Relational mappings.

It supports polymorphic associations, such as many-to-one, one-to-many, many-to-many, one-to-one, and ternary. Or even bidirectional associations.

• High performance.

It has a highly scalable architecture. And the overhead is minimum, compared to JDBC. SQL is generated at system initialization time, rather than at runtime.

Benefits for Openbravo

• Ability to support a wide range of databases, such as MySQL.
• Fully integrated with Spring.
• Wide-known and fast growing technology.

Service Layer

The Service Layer is under the presentation/remoting layer. It is a gateway to the internals of the ERP system and this makes it the adequate place to coordinate concerns like transactions and security. This means that layers on top of the Service Layer should not call methods that change the state of the Domain Objects directly, but should call methods in the Service Layer instead.

Moreover, it decouples the layers above the Service Layer from the Domain Layer, because it also acts like a Facade: it hides the complexity of retrieval and delegates to the domain objects.

Exposing the service layer

• DWR

DWR makes it simple to call Java code directly from Javascript. It allows the user-side JavaScript to interact with the server-side Java, so this helps manipulating web pages' results.

This method of remoting functions from Java to Javascript gives users feel much like conventional RPC mechanisms like RMI or SOAP, but with the benefit of running it over the web, without requiring additional web-browser plugins.

• Remoting: Web services

A Web service is a software system designed to support interoperable Machine to Machine interaction over a network. Therefore, Web services are Web APIs that can be accessed over a network, and executed on the remote system hosting the requested services.

Spring allows integrating classes for remoting support using various technologies. In Openbravo's case, this opens the gates for integrating it with many external applications such as a CRM or a DMS, for instance.

Implementing the service layer

One if the consequences of using an ORM tool like Hibernate is that, preferably, all the PL/SQL code should be moved into Java. That is, the stored procedures have to be translated or adapted into Java. As said, Hibernate takes care of dealing with the database. As one of our goals is the database independence, having no stored PL/SQL code makes sense.

Presentation layer

Spring offers a MVC framework for building web applications. This MVC offers, among others, the following technologies for the view: JSP, JasperReports, etc. JasperReports makes it possible to create reports graphically in a easy way. In our case, there is no problem in using our self-made implementation: XmlEngine

Client side

The client side is independent from the server side. This allows using different user interfaces to interact with the server. This approach provides user interface independence, allowing to develop different interfaces with the same technology.

Web browser user interface

As with previous Openbravo versions, the new Openbravo platform offers a completely web-based client. This user interface will be rich, independent of the presentation and the data, saving bandwidth and offering a better user-experience.

For the presentation layer, we will use DHTML and rich AJAX control widgets from DOJO. DWR will be used to process the client-side Javascript, retrieve data and invoke the service layer.

Enterprise capabilities

Security: Authentication and authorization

Spring gives us the opportunity to have advanced security features, even without touching the Openbravo codebase. The Acegi security consists on pluggable web filters.

In order to implement the new security into Openbravo, these are the steps to follow:

1. Remove the current security implementation, that is, HttpSecureBaseServlet.

1. Build the authorization and authentication module of Acegi, using the Openbravo tables.

1. Build the login HTML pages of Acegi, reusing the current HTML login pages of Openbravo.

1. Use Spring to manage the security (through Acegi), and inject it where necessary.

Security features:

• Authentication

  Login to the application and request of session parameters: Language, Warehouse, role,

• Authorization

  Menu options. Window actions: new, save, delete, update, read. Process and reports execution.

• Data security

  Security filters for data to allow view data based on session parameters: For example, "View my department's employee's wages" is a security filter. But "View my clients with credit less than 10000" is business logic.

Auditing, logging, monitoring

Logging has a lot of characteristics that make it a prime candidate for implementation as an aspect. Spring offers the AOP framework to get it done.

1. The first step is to know what we want to monitor and audit.
2. Secondly, we implement the auditing as beans, with as many business methods as DAO methods.

Integration

Spring offers several technologies to expose Java beans as web services. These web services will expose the desired functionality to other applications and integration tools.

1. Build existing web services for integration with external POS systems.
2. Build new web services for the integration with many enterprise applications like CRMs.
3. Make these web services compatible with integration tools like Jitterbit, Mule, ServiceMix, etc.

Job scheduling. Quartz

• Background processes like reports generation
• Driving workflows
• Maintenance tasks
• BPM

Portlets. JSR 168

Software as a service (SaaS)

Modularity

The applications developed in our platform should be modular. A module is a package that includes database objects, data, windows, reports, processes, tasks, workflows and every functional object defined within the Openbravo platform. Modules may have dependencies on other modules. And every Openbravo module should be managed the same way with independence of their type. An example of module types are:

• Verticals.
• New versions, patches and service packs.
• Localizations.
• Community functional developments.
• Other customizations

Openbravo modules should be developed independently of other developments, focused to easily allow the integration of contributions and to allow distributed developments. There should not be conflicts when integrating modules. For example, there should not be database object name conflicts, or other functional object name conflicts, record identificators collisions, etc.

To achieve this object names independence, every functional object will get a naming styles. Database tables will be mapped to entity Java objects through Hibernate, and record identifiers will be generated independently and business-logic free.

To allow the installation and uninstallation of modules, they should be packaged with all the functional objects and information related to this module, like the name, version, dependencies, etc. We need a module management tool, required for their installation and uninstallation and capable of resolving module dependencies.

A modularity model similar to OSGi, JSR 277 or JSR 232 or JSR 291 is preferred.

Internationalization

Openbravo Green aims to be designed to be easily localizable with support other nations and cultures. The requirements are:

• Technical requirements
  • Unicode support for all the information displayed to the user.

  Using UTF-8 as default codification for all the information: HTML pages, text messages, database this requirement is required.

  • Ability to add support for a new locale without the need to compile the application.

  Just adding the files corresponding to a new localization should be sufficient to install support for a new locale.

  • Locale and format information should be per user not per machine.

  All the information needed to define a locale: (date formats, numbering formats, language, ...) should be defined by user

• Functional requirements
  • Support for RTL (right-to-left) languages like Hebrew and Arabic.
  • Support for multiple calendars systems.

  Gregorian calendar, Hijri calendar, Chinese calendar...

  • Support for multiple currencies and currency formats.
  • Support for multiple weights and measures.

Service Oriented Architecture (SOA)

It is a fundamental design principle for an enterprise information system to be service oriented. In a network environment resources need to be available as independent services that can be accessed without knowledge of their underlying platform implementation.

Openbravo Green is structured in layers and the service layer provides the functionality to the client side. The service layer will be exposed in several ways depending the client technology and also Openbravo Green aims to expose this layer as web services to be easy for other applications to collaborate very tighly and leverage the functionality of Openbravo Green with third party applications, components and industry standards.

The areas where Openbravo Green wants to focus are:

• Integration between applications.
• Workflow.
• Bussines process Management.
• Import/Export data.
• Business Intelligence Tools.

BPEL

BPEL is a high level language that extend the service concept by providing a method of defining and supporting orchestration of fine grained services into more coarse-grained business services, which in turn can be incorporated into workflows and business processes implemented in composite applications or portals.

BPEL allows business analyst to develop processes without the need of a programmer. BPEL process can be designed and tested managing only business related concepts. There are several BPEL process designers that allow create, test and deploy a BPEL processes graphically.

Openbravo Green will develop the necessary services to create a workflow system around BPEL . BPEL does not stand for workflow but it can be used to orchestrate workflows if the necessary services are available to BPEL processes. These services will be invoked by BPEL process that represent the workflow concepts: Services to initiate a task, to assign task to a user or a group or users, to claim a task, to complete a task, or change the state of a task. Services to manage the list of pending tasks for a user or a group. Services to audit, manage or administer tasks.

ESB

An Enterprise Service Bus (ESB) refers to a software architecture implemented by middleware infrastruture technologies. ESB products are usually based on standards, that provides foundational services for more complex architectures via an event-driven and standards-based messaging engine. An ESB generally provides an abstraction layer on top of an implementation of an enterprise messaging system which allows integration architects to exploit the value of messaging without writing code.

Application functionalities

Windows

Windows are the main functional objects in an ERP. Users spend most of their time working with them. These windows allow the user to edit and query the requested information, navigate through the information and invoke processes. The users that work with ERP windows must be productive and feel comfortable with the user interface. They also must have the tools and the proper information accessible to perform their job. The usability and look and feel is a key factor.

• Single table edition

  These are the productivity functionalities required to perform the edition of table records needed by users.

  • Update, insert and delete records

  Save in a direct manner. No need to do several clicks to save a record and ability to revert changes easily.

  • Browse table records and fields
  • Sort, filter and search records

  Filters may be invoked inside the window pressing a button or may appear at the beginning of the edition for large windows. Filters have to be easy and powerful for users with expressions based on the window fields and predefined named filters.

  • Attach documents to records
  • Swap between edit view and relation view
  • Report / Print current record or current table.

  Predefined reports for tables using Jasperreports and printable version of edition windows.

• Master-detail edition

  In an ERP system there are have relationships between the tables that store the information and the easiest way is to navigate, edit and show the information is through these relations.

  • Tabs

  Tabs are the general system to show related information hierarchically organized where the tab on the left show the information of the parent table and the tabs on the right, that are smaller, show the information of the son tables.

  • One window for header an lines

  Windows like Ordersand Invoices are organized in two tables, one for the header and other for the lines. Tabs are not a good solution to edit this kind of information and one window to show both tables is preferred. The header as a common record and the lines in an editable grid below the header.

• Fields

  Fields are the minimum piece of information editable, usually shown as an editable text box, but fields can be very different and the application must be able to offer the proper tools to edit all kind of fields.

  • Different field types

  Fields may have different types: Literal, number, date, currency, description, boolean, images, check constrained, ... And also have different meanings: zip numbers, telephone numbers, email addresses, ... Windows must handle all this field types properly, and show the values in the format selected by the user.

  • Field edition tools

  The windows must offer tools to help the edition and maintenance of these fields, like a calendar to edit dates, a calculator to edit numbers, a change currency window...

  • Field validations

  Windows must validate in the client side the data entered the data by the user individually, for example mandatory fields, check constrained values, telephone numbers, email addresses, min/max interval...

  • Combo fields, List fields,

  Check constrained fields may be shown in a combo box field that shows all the available values for that field. The values of a combo box may be a fixed list or a data filtered list.

  • Group of fields

  Group of fields that show related information may be shown in groups with a label that identifies the group.

  • Fields Visible / Invisible dependent on other field value
  • Calculated fields

  Fields that show information that is not stored directly in the current table and show more information like totals.

• Selector lists
  • Selector lists with filters

  Filter expressions based on fields, predefined named filters.

• Process execution
  • Processes with parameters

  Parameters requested to the user, of the current window, and of the current session.

• User messages
  • Complex validations (client side and server side).
  • Error management, User messages,
  • Process execution.
• Window navigation
  • Menus.
  • Links to related windows

Reporting

Use the reporting technology of JasperReports and/or Pentaho suites for graphical and printed reports. OLAP dynamic analysis, balanced score cards, business intelligence, etc.

The main features of JasperReports are:

• Complex Reports
  • Sub-reports easily handle highly complex layouts
  • Pixel-perfect page-oriented output for web or print
  • Report output in PDF, XML, HTML, CSV, XLS, RTF, TXT
  • Crosstabs
• Integrated Charting
  • Comprehensive set of chart types
• Internationalized and Localizable
• Scalable
• Extensible
• Easy to Use
  • iReport visual report designer
  • Other Eclipse- and Swing-based designers available

The reporting capabilities required for Openbravo Green are:

• Reports executed from windows and menu options.
• Reports with parameters requested to the user, of the current window, and of the current session.

Workflow

The requirements for a human workflow system we want create in Openbravo Green are:

• Task assignment to users, roles, groups.
• Task routing various flow patterns and assignment rules.
• Escalation and delegation rules.
• Notification to users/groups via e-mail, Voice, Pager, SMS ...
• Customizable Worklist, task forms, attachments.
• Task History, audit, productivity reports.

Help system

The help system should be integrated and easily editable. A wiki-alike system is preferred, allowing with contributions all the ERP users.

Search tool

Tool to easily search entities. Not only based in field filters but also in predefined and complex user-defined criteria. For example: partners with pending invoices between X and Y, with more than X employees, etc.

Query tool

Tool to make database queries, according to a user-defined criteria or filters, sort orders, etc. The result of this queries can be saved in many formats: HTML, PDF, XLS, ODS, TXT, etc.

Import/Export data

Import data to the application from a plain-text, Excel or OpenOffice Calc file. In the same way, export the desired data into these formats, plus PDF.

Development

To create quality of Openbravo Green, quality must be present in all the stages of the construction of the product. In an open source project quality must be present also in the source code.

Style guidelines

Source code must be easy to read, and every body involved in the same project should write code with the same style, same indentation, naming variables, methods... The coding convention Openbravo Green will follow is the Java Coding Conventions. The coding conventions published by Sun for java and widely adopted.

Source code documentation

Following the previous paragraph source code must be also well documented. Open bravo Green will document the source code using Javadoc. Javadoc is a tool for generating API documentation in HTML format from doc comments in source code. It is also widely adopted for java

Version control system

A development team that works in the same code base needs a version control system as a collaboration tool. Openbravo Green use Subversion. Subversion is a version control system with great features and very capable to support all the requirements of a development team. The Subversion repository is hosted by Sourceforge located in the Openbravo Green Subversion repository. The address of the Subversion repository is https://openbravo.svn.sourceforge.net/svnroot/openbravo/branchs/green.

Change log

A change log is a text document that has all the changes committed in the version control system by date and user. Change logs are useful to keep track of the source code changesm this way you can read in a single document what changes are included between two releases. The format of a change log document Openbravo Green will follow is the GNU Change log style. There are useful tools to create change logs based on the version control system commits like SVN2Log, SVN2CL.

Unit testing

To assure that changes in the source code does not affect the previous correct behaviour, and to test the correct behaviour of new classes, developers must write unit test. To help the developer to write unit tests, Openbravo green will use Junit. JUnit is a regression testing framework written and is intended for developers who implements unit tests in Java. To help to create these tests of classes isolated form other layers, Openbravo Green will also use Mock object libraries.

A good article with JUnit best practices can be located at [1]

Source code metrics

To help to measure the quality of source code there are automatic tools that provide metrics, scans Java source code and looks for potential problems. The Openbravo Green team will use the tools PDM and XRadar.

Environment

A development team needs an Integrated Development Environment with all the tools they need to create the applications. Openbravo Green developers will use Eclipse or Netbeans.

• Debugging

  A developer should be able to reproduce, isolate and debug a bug report in an easy way, with the help of external applications such as debuggers and IDEs. We will make it easy to develop and debug the application with IDEs such as Eclipse or Netbeans.

• Profiling

  Tools to monitor the application, analyze its performance, analyze the performance of an specific code portion, memory usage, etc. They will be used to assure that we offer the best quality in terms of memory usage and performance.

Nightly builds

There will be Openbravo Green builds every day to assure that builds created for the Sofware Quality team are not created with code which may be in the middle of mayor modifications. These builds will be very important for testing and for reviewing bug fixes.

The nightly build process will be automatized and integrated with the Version Control System. The results of the build will be inspected by the programmers and will place a priority on ensuring the nightly does not break.

Release management

Openbravo will prepare a full set of migration tools, methodologies and tests to minimize the effort and to ensure the reliability of the upgraded system.

Certification documents

We will document which versions we certify with which operating systems and also the supported software versions. Our community edition product will have frequent updates, with support in our forums and IRC channel. Also, we will have a long term support professional product.

Execution environments

The Openbravo Green development team will have three execution environments each one with the different configurations supported by Openbravo Green: O.S. Windows and Linux. Database. Oracle, PostgreSQL...

• Development environment. Common environment and personal working environments.
• QA environment.
• Acceptance tests environment.

Install tool

The installation tool will be Bitrock based. The future build process with be properly documented.

Bug tracking tool

We need a bug tracking tool, capable of allowing detailed bug reports and easy to use. A bug report should contain attributes like an Identifier, name, submitter, assignee, problem description, problem solution, how to reproduce, priority, state, category, version where found, version where fixed, where is fixed, possible workaround, etc.

A bug report must have a well defined workflow based in the state of this bug with responsible of the bug report in each state and with predefined requisites to change from one state to another: Reported, accepted, open, rejected, pending, fixed, closed...

We have bug reporting guidelines, and we will also write more documentation about this.

Testing tool

Tests should be managed though an automated tool that runs the test and verifies the execution of the test suites of one defined build in one defined environment.

A testing inventory tool should have the ability to categorize test suites in regression tests, acceptance tests, by product layer, etc. This tool should have a relationship with the bug tracking system: most fixed bugs, if necessary, should have their own test. This testing inventory tool must also store the results of the execution of the test suites categorized by build version and environment to allow the creation of reports and charts.

• Acceptance tests

Minimum suite of test that any version should pass before being released to the community. This tests are created with the purpose of assuring that every Openbravo product have the same quality.

Category: Architecture