There are probably as many definitions of software architecture as there are people defining it. Most of them begin by stating that software architecture is the general structure of a system, or that it maps the requirements of a system onto specific design or implementation decisions. From the very beginning of any project, it is extremely important to maintain fluent communications among the various stakeholders in a software system. During the requirements analysis and subsequent reviews, the stakeholders are able to specify their most significant requirements. But, this can be an unstable basis for the project if each group of stakeholders is unsure whether its needs have been understood correctly. Average users, for instance, might not be able to understand use-case specifications in enough detail to offer feedback on them.
The system architecture is often the first project phase at which an overall picture of the requirements emerges. This overview can allow all stakeholders to discuss the system in the same terms. With the help of a good architecture, project owners can be more confident that the requirements they’ve defined are the right ones and in the right format.
Before implementing an open source ERP tool, it is essential to know its architecture. The architecture not only tells the business logic but also defines process work flow. It determines the robustness and flexibility of the tool.
Architectures of some open source ERP tools are discussed below:
1. Open Taps:
Opentaps have a robust and simple architecture. It basically follows a 3-Tier Web Architecture and the application server layer contains three layers namely
1. Presentation layer.
2. Business Logic Layer and
3. Data layer.
The Data layer consists of an entity engine for handling the data access and persistence via data models which is defined in XML files which can act as an interface with the database. In the Business logic layer, small reusable pieces of code which can be written in various high level scripting language or XML which acts as services. One can define a workflow in an XPDL (XML programming defined language) format. Various services are then integrated to form a service engine. This service engine can be then called directly via web services using SOAP and RMI (EJB or enterprise Java Bean is a type of RMI).
Above the business logic layer consists of presentation layer which uses Model View Controller (MVC) pattern which then allows reusing the design elements, viewing the logic and forming an action.
2. Compiere:
Compiere’s architecture is a mixture of fat client 2-tier and 3-tier architecture. It uses a fat Java Client (Java Webstart). In the client tier, web interfacing has been done. After interfacing is done, business logics and the process workflow is defined in the application server (say JBoss). The application server has been further divided into three sub parts ie; Presentation layer, Business Logic layer and a data layer. In the presentation layer, code is generated by taking JSP and swing. The purpose of taking JSP is to make a function globalise and accessible to everyone.
Swing technology is generally used for standalone function. Hence Compiere gives robustness to data security and maintaining the hierarchy. Let’s understand this by taking a small example. Assume a Sales manager is having few team members under him. So the functionality or dashboard of the sales manager would be defined using Swing so that the team members can’t access his data. While the team member’s data is defined in JSP which makes a Sales manager to have the privilege to view the performance of its team.
The accounting engine or the services that the tool provides is written JSP in order to make the integration between the modules and sub-modules easier and effective.
The Metadata which contains the callouts and Document having the workflow is written in JSP as well as Swing in order to give security and make the process efficient. Finally an entity engine (JSQL) is used to eliminate the need for entity specific persistence code in as many areas of a transactional application as possible.
