Chuanjiang Apache OFBiz Technology Architecture

From the decision to read Apacheofbiz source to now unknowingly a year passed. This year, for various reasons, the source code read intermittently. In fact, the biggest problem is the inability to understand some of the things inside, leading to a sudden loss of enthusiasm. Until recently, the company in the development of an "application of rapid development platform" triggered some of my thinking, so decided to take out the source code to re-read. To the recent fascination with its architectural design.

Personally, the analysis of apacheofbiz can be divided into three chunks: technology, business, database design. Each of these three pieces is a very top-notch level, and you can learn a lot in every direction. Previously, it was just a separate parsing of the various parts of ofbiz, and it is time to write an article to chuanjiang its various parts. Of course, this article is mainly related to ofbiz technology this piece.

Introduction to the Framework

This picture is the overall frame of the ofbiz. You can see that all ofbiz apps are built on their framework. The core of its framework is serviceengine (service engine) and Entityengine (Entity engine). In fact, the body engine support for the type of database and topology is very sound. It supports the coexistence of local databases and remote databases and supports up to 8 mainstream databases.

OFBiz Technology Chuanjiang

The following is the process of a client request to see how the OFBiz components interact and converge.

(1) The client browser makes a request to the Web server (HTTP/HTTPS), and the request is received by the Web container and processed accordingly (such as encapsulation of parameters).
(2) The request is routed to a proxy servlet, which analyzes which app the request is destined for, Then go to the Controller.xml configuration file under the project to match the Request-map configuration item, which is used to just ofbiz how to handle the request. The usual process is to conduct security checks and permission confirmations, then trigger an "event" or service call, and finally respond with a view. In response to a view, OFBiz will go to View-map to match the view, and each view has its corresponding handler.
(3) OFBiz will use the configured handler to process the view. Handler's role is primarily to render page elements and to merge the data that needs to be presented with the page elements.
(4) Data preparation. The front-end request is ultimately a request for operations on the back-end data. The way to get data in ofbiz is very rich. Considering that this is a very large amount of code in terms of business logic, OFBiz attempts to write this part of the code using dynamic languages. The main is to take advantage of the concise dynamic language, less code, the advantages of rapid development. With the development of the Java language, OFBiz has chosen and replaced a variety of different JVM scripting languages, such as: Beanshell,groovy. Using scripting languages to write business logic code that is related to manipulating entities can be both pros and cons:

Disadvantage: The lack of intrinsic type security of dynamic language (weakly typed language) and the performance of pure interpretation are not comparable to Java's interpretation + compiled language.

Advantages: A large number of traditional industries, do not need such high performance requirements, even if the need to improve the hardware, the scripting language in programming efficiency, logic simplicity is Java verbose code, the scripting language is closer to the expression of human language, more suitable for the implementation of DSL, To express business logic (and OFBiz's next goal will also enhance support for groovy's implementation of DSLs).

(5) OFBiz Viewhandler after binding the page elements and data through the template engine, renders the final output stream and responds to the client browser via HTTP.

Page rendering

Apache OFBiz uses the Xml+widget layout to split pages into widgets to enhance the flexibility and reusability of individual widgets.

These widgets can be nested into each other to form a decorator-widget generating template, where widgets can write HTML tags directly, or reference template files (such as Freemaker) supported by various server-side template engines.

The content of the front-end is usually html+ data. The widget does not ignore the data section. It's just a layout technique that eventually translates from Webcontainer to HTML, except that data processing (CRUD) is usually on the server side. These actions are abstracted into the "action" in the widget. A screen typically contains references to a variety of other component widgets, which can be: Form,screen,menu, and so on.

Permission check

The authorization model for the role + security group is used in OFBiz.

You can see several commonly used permissions are: _admin (Administrator rights), _view (browse permissions, for the minimum permissions), _create (Create Permissions), _update (edit permissions), _delete (delete permissions). Therefore, if the authorization check is configured in Controller.xml, the permission check process is performed. Before a request is processed, it checks whether it needs to log on first. If the login verification is passed, the member's security group will be obtained. The security group is also a collection of security permission. In turn, you can determine whether a user has permission to an operation.

Request Event

Because OFBiz uses a public proxy servlet, its processing logic has no exclusive servlet for each request. Here OFBiz introduces the mechanism of event to handle the specific operational logic that each request needs to execute.

Each request is received, and if there is a special processing, an event is triggered. Is the trigger mechanism for the event. It is configured within the REQUEST-MAP configuration item under the Controller.xml file.

Service engine

The OFBiz execution service is based on its own implementation of the service engine framework. The service engine draws on the "businessdelegate" pattern in corej2ee pattern.

After the calling program invokes the service through the Service engine framework, the service engine first extracts the parameters of the calling service and constructs the context of the service invocation. Then choose the right dispatcher, it is actually businessdelegate. He chooses the right engine to perform the service. OFBiz will first determine if the service is "special", such as whether it is asynchronous? Whether it is executed recursively. If it is, then it will choose its built-in Jobscheduler to execute. and is it with Seca (Serviceevent Control Action)? If it is seca, then the Seca is executed and then the specific engine configured to perform the actual target service is executed, and in this process there is a map that acts as the context for execution, storing intermediate results, error messages, and final results. When execution is complete, the context object is rolled back at the middle layer of the call stack and the final execution results are returned to the caller.

Service event Control Responder the so-called Seca is the abbreviated form of the first letter of the service event controls action. It can be simply understood as "service orchestration" (multiple services may be executed, but some services need to meet specific execution conditions).

For example, above a service X with Seca, before the service engine executes, it will process its ECA (here call an action first, it needs to execute service B). When the ECA process is complete, control is returned to the execution engine. The execution engine will determine if the real service X will be invoked based on the execution result of service B. Seca is used to replace its original rule engine and workflow engine in OFBiz, which shows that its flexibility is sufficient to meet the complex business support.
To write more technical analysis at the end, please see the previous series of articles as well as the subsequent continuous updates.

Chuanjiang Apache OFBiz Technology Architecture