CUBA - a platform for rapid development of business applications in Java
If you are developing software for enterprises, you may have already written your own platform. Which allows you to quickly create UI and logic for working with data, contains common functionality for your projects: user rights management, report generator, BPM, and the like, and has an architecture that makes it easy to maintain and scale the application. If you have not had time to write, we suggest to get acquainted with our development - the CUBA platform .
The platform has existed for more than four years, but until now it has been used in a rather narrow circle of our company's developers and partners. We managed to make two replicable products on it and more than a dozen custom-made projects. And then came the moment when, after a long preparation, we decided to release it in the form of a product available to everyone.
To begin with, I will give a short list of basic features. Details of course can be found on the site.
Well, in order to make it all convenient to use, we made a Studio. This is a separate application that the developer uses in parallel with the usual Java IDE. The studio provides a graphical interface to the mechanisms of the platform, allowing the mouse to click on the data model, generate DDL scripts for the database, draw screens in a WYSIWYG editor, and make blanks for middle-level services. Using the Studio is not necessary, but it greatly facilitates many things, especially at the initial stage of the project.
')
We position CUBA primarily as a tool for developers involved in automating internal business processes of enterprises. These can be production processes, purchases and sales, document flow, personnel management, monitoring tools, and so on. CUBA can be the basis of any accounting or management system.
In addition, a proven option is to use the platform as a backend of a distributed system. In this case, a middle layer with the main business logic and UI for employees is created on the platform, while websites and mobile applications for external users act as clients of the middle layer.
Using the platform, one can focus mainly on business logic, since most infrastructure tasks have already been solved. Accordingly, make the project faster and with less effort.
Terms of use CUBA described on our website . There is a free option.
Documentation is.
Now I want to talk about the origin and evolution of the platform. Actually, basically it will be about technologies, so it will become approximately clear how CUBA works.
How it all began Our company was created to make information systems for enterprises. Different systems for different enterprises, and the more, the better. The fact that we will write in Java is not in doubt due to the previous positive experience, independence from the OS, the presence of a great IDE, a wide range of frameworks of all levels and the like. At the same time, we understood that it is difficult and inefficient to do each project from scratch, using only what Java and frameworks provide. Much of the functionality of corporate systems overlaps, regardless of the nature of the business. And the part that is unique in each application, we wanted to make it easier and faster. Unfortunately (or fortunately), we did not find anything ready in the Java world that would satisfy our requirements, no suitable “platform for quickly creating business applications”, and as usual, we decided to write our own.
We started from the middle layer - we took JBoss from EJB3, and screwed OpenJPA as ORM. Why not Hibernate is a topic for a separate article, we will try to write it over time. We taught OpenJPA to work with soft deletion transparently for the developer, so that there was no need to add anything to the queries and control the results.
We wrote our metadata framework, which we need to implement universal mechanisms, such as visual components, which customize their properties depending on the type of entity attribute that they display. On the basis of metadata, a mechanism for declarative declaration of entity graphs was made (we call them “views” - views). Such a mechanism is needed in order to be able to request data from any level of the application and indicate which object graph is currently required, i.e. what attributes and related entities we want to work with at the moment.
Started working on security: user session, users themselves, roles and access rights. We broke our head on how to implement row-level security. We stopped at the fact that constraint predicates should be grouped into a hierarchical structure separate from roles. All security controls, of course, were immediately made dynamic in the sense of being configurable at runtime.
Difficult was the choice of technology for the web UI. We needed to create our own layer of abstraction on top of some framework to separate the layout and the code of the screens, as well as to implement a set of visual components that work with entities using our metadata. In addition, we planned in the future to make the implementation of the same layer on the basis of desktop Swing. In general, I wanted the application code not to depend on any technology other than Java and our own. As a result, Vaadin was chosen for the web client (then it was called ITMill). There were few alternatives, well, in any case, now we don’t regret the choice, since the framework is powerful and actively developing. Although many cones were filled, we will try to tell about them in a separate article.
Thus, we have GenericUI - a platform module for creating screens in XML and Java. It consists of screen loaders, a library of visual components and data sources (datasources), connecting components with the data model. The first thing we wrote on GenericUI was the security management screens of the platform itself. Well, then we started to make the first application - it was a custom workflow system. It must be said that GenericUI allows you to work around itself, directly with the components of the underlying UI framework. At first, we actively used this, as GenericUI often lacked opportunities. Over time, as a result of the development of the platform, the need for such a “low-level” coding almost disappeared, 99% of the application code works only with generic interfaces.
After some time, the idea came to abandon JBoss and implement the entire infrastructure in Spring. Spring's remarkable functionality and extensibility enabled us to implement the necessary mechanisms more simply and reliably. Plus, we gained independence from the server, as well as the start time of the application on Tomcat from 5 to 15 seconds, which is several times faster than it was on JBoss.
Despite the acceptable application restart time, it is sometimes necessary to deploy parts of the application on the fly, without stopping the server. Therefore, we have implemented the ability to dynamically compile and load classes from a special directory. Moreover, now the Studio constantly monitors changes in the project and throws UI sources into this directory, which is very helpful when designing screens - you can see the result of changes without restarting, login, searching the screen in the menu, etc.
The time has come to increase functionality - applications needed business process management and full-text search. We did not inflate the main part of the platform, but divided it into several projects that are used by applications if necessary.
After Workflow and Full Text Search, we started developing our own report generator. Before that, they used JasperReports, but it did not suit us, firstly because of the too laborious process of creating templates, and secondly because of the difficulties with displaying the results in Excel. They implemented a simple idea: separately describe the logic of data extraction, separately create a template in Excel, Word or HTML. Such an approach was justified, and recently we even singled out the generator core into a separate open-source project called YARG for use outside the platform. About him there will definitely be an article on Habré.
The build system for a long time was based on Ant-scripts. Moreover, if third-party libraries were loaded from the repository in binary form, the platform was connected to the application project only in the form of sources, directly from SVN. Such an approach had advantages at the stage of the formation of the platform - any programmer, while working on his project, could easily fix something in the platform and simply commit his changes. At a certain point, we switched to the standard version, when binary artifacts and platform sources are loaded into the project in the same way as other dependencies - from the Maven repository. At the same time, Ant was replaced by Gradle, which allowed us to conclude the main assembly code in the plugin, and make the project scripts as concise as possible, but at the same time arbitrarily extensible.
When we started making Sherlock, a product for a taxi, we needed a desktop client. Then came the second implementation of GenericUI-components on Swing. As a result, the entire product UI (more than 300 screens) is available both on the web and in desktop versions with the same functionality, the differences are only in the responsiveness of the interface and the nuances of working with the keyboard.
Also for replicated products, we have invented an extension mechanism that allows us to adapt to customer requirements. An extension is essentially a new application project in which the product is used as a platform. Thus, we manage to achieve maximum customization for the customer without changing the code of the main product. The possibility of updating product versions is also preserved - it is enough to align the extension with the new version and rebuild it.
At a certain point in time, the idea to make the platform available to developers outside our company. Two years ago, CUBA was put into service by two more IT companies that made quite large projects on its basis: a system for processing electronic messages of citizens of the Government of Moscow and the federal Electronic Register of Cancer Patients of the Republic of Kazakhstan. This finally convinced us that CUBA could be useful not only for us, and we began preparations for a public release.
From now on, work has begun on the Studio, which reduces the entry threshold for starting development on the platform and makes it possible to more conveniently perform routine tasks. We made Studio a web application that provides interesting application possibilities - from the theoretical ability of working in the cloud to the very practical possibility to quickly connect to a colleague's project and, for example, help him to understand the problem. In addition to the Studio, a plugin for IntelliJ IDEA to navigate CUBA-specific elements of the project was written to help the developer.
At the moment, CUBA has moved from a phase of intensive growth and constant changes to a more relaxed stage of evolution. Naturally, first of all, this is a continuous process of various local modifications and elimination of defects. In addition, we plan in the near future to do the finishing of the chart display module - there will appear components for displaying the map and interactive diagrams in JavaScript, which will be managed, like all other GenericUI components, from the server-side Java code. After that, most likely, we will deal with deployment of CUBA applications in the cloud with PaaS providers.
Of course, we are open to dialogue, and the directions for improving the platform will largely be determined by the wishes of the developers who use it.
Unlike the platform itself, Studio is a very young product. First of all, we are working to improve the usability of the Studio and we are trying to make it more intelligent and friendly.
Also, a lot of effort recently applied to the improvement of documentation. While there are gaps in it, there are clearly not enough examples and recipes for solving typical problems. We will eliminate these shortcomings, and next year we are going to release all the documentation in English.
On Habré we plan to publish articles about various aspects of the platform device and the problems that we had to solve. Hope it will be interesting.
The platform has existed for more than four years, but until now it has been used in a rather narrow circle of our company's developers and partners. We managed to make two replicable products on it and more than a dozen custom-made projects. And then came the moment when, after a long preparation, we decided to release it in the form of a product available to everyone.
To begin with, I will give a short list of basic features. Details of course can be found on the site.
- Declarative UI creation: screen layout in XML, initialization and event handling in Java classes.
- A library of data-aware visual components. There are all standard, plus specific, for example, universal data filter, selection fields of related entities with various possibilities, a table with groupings.
- The screens work in the web (AJAX) and in the desktop (Swing) clients. Sources are common.
- Metadata - extended information about the data model. Designing a data model “from entities to tables”.
- Soft deletion of records in the database.
- Management of access rights at the level of operations with entities, their attributes and individual instances, screens and UI components.
- If necessary, connected functionality: report generator, business process module with a visual editor, full-text search, work with credit cards.
- Out of the Box are supported by PostgreSQL, MS SQL Server, Oracle, HSQL.
- Standard deployment on any web container.
- Horizontal scaling on a cluster of servers, you can separately the middle layer, separately web servers.
Well, in order to make it all convenient to use, we made a Studio. This is a separate application that the developer uses in parallel with the usual Java IDE. The studio provides a graphical interface to the mechanisms of the platform, allowing the mouse to click on the data model, generate DDL scripts for the database, draw screens in a WYSIWYG editor, and make blanks for middle-level services. Using the Studio is not necessary, but it greatly facilitates many things, especially at the initial stage of the project.
')
Who can it be useful?
We position CUBA primarily as a tool for developers involved in automating internal business processes of enterprises. These can be production processes, purchases and sales, document flow, personnel management, monitoring tools, and so on. CUBA can be the basis of any accounting or management system.
In addition, a proven option is to use the platform as a backend of a distributed system. In this case, a middle layer with the main business logic and UI for employees is created on the platform, while websites and mobile applications for external users act as clients of the middle layer.
Using the platform, one can focus mainly on business logic, since most infrastructure tasks have already been solved. Accordingly, make the project faster and with less effort.
Terms of use CUBA described on our website . There is a free option.
Documentation is.
Story
Now I want to talk about the origin and evolution of the platform. Actually, basically it will be about technologies, so it will become approximately clear how CUBA works.
How it all began Our company was created to make information systems for enterprises. Different systems for different enterprises, and the more, the better. The fact that we will write in Java is not in doubt due to the previous positive experience, independence from the OS, the presence of a great IDE, a wide range of frameworks of all levels and the like. At the same time, we understood that it is difficult and inefficient to do each project from scratch, using only what Java and frameworks provide. Much of the functionality of corporate systems overlaps, regardless of the nature of the business. And the part that is unique in each application, we wanted to make it easier and faster. Unfortunately (or fortunately), we did not find anything ready in the Java world that would satisfy our requirements, no suitable “platform for quickly creating business applications”, and as usual, we decided to write our own.
We started from the middle layer - we took JBoss from EJB3, and screwed OpenJPA as ORM. Why not Hibernate is a topic for a separate article, we will try to write it over time. We taught OpenJPA to work with soft deletion transparently for the developer, so that there was no need to add anything to the queries and control the results.
We wrote our metadata framework, which we need to implement universal mechanisms, such as visual components, which customize their properties depending on the type of entity attribute that they display. On the basis of metadata, a mechanism for declarative declaration of entity graphs was made (we call them “views” - views). Such a mechanism is needed in order to be able to request data from any level of the application and indicate which object graph is currently required, i.e. what attributes and related entities we want to work with at the moment.
Started working on security: user session, users themselves, roles and access rights. We broke our head on how to implement row-level security. We stopped at the fact that constraint predicates should be grouped into a hierarchical structure separate from roles. All security controls, of course, were immediately made dynamic in the sense of being configurable at runtime.
Difficult was the choice of technology for the web UI. We needed to create our own layer of abstraction on top of some framework to separate the layout and the code of the screens, as well as to implement a set of visual components that work with entities using our metadata. In addition, we planned in the future to make the implementation of the same layer on the basis of desktop Swing. In general, I wanted the application code not to depend on any technology other than Java and our own. As a result, Vaadin was chosen for the web client (then it was called ITMill). There were few alternatives, well, in any case, now we don’t regret the choice, since the framework is powerful and actively developing. Although many cones were filled, we will try to tell about them in a separate article.
Thus, we have GenericUI - a platform module for creating screens in XML and Java. It consists of screen loaders, a library of visual components and data sources (datasources), connecting components with the data model. The first thing we wrote on GenericUI was the security management screens of the platform itself. Well, then we started to make the first application - it was a custom workflow system. It must be said that GenericUI allows you to work around itself, directly with the components of the underlying UI framework. At first, we actively used this, as GenericUI often lacked opportunities. Over time, as a result of the development of the platform, the need for such a “low-level” coding almost disappeared, 99% of the application code works only with generic interfaces.
After some time, the idea came to abandon JBoss and implement the entire infrastructure in Spring. Spring's remarkable functionality and extensibility enabled us to implement the necessary mechanisms more simply and reliably. Plus, we gained independence from the server, as well as the start time of the application on Tomcat from 5 to 15 seconds, which is several times faster than it was on JBoss.
Despite the acceptable application restart time, it is sometimes necessary to deploy parts of the application on the fly, without stopping the server. Therefore, we have implemented the ability to dynamically compile and load classes from a special directory. Moreover, now the Studio constantly monitors changes in the project and throws UI sources into this directory, which is very helpful when designing screens - you can see the result of changes without restarting, login, searching the screen in the menu, etc.
The time has come to increase functionality - applications needed business process management and full-text search. We did not inflate the main part of the platform, but divided it into several projects that are used by applications if necessary.
After Workflow and Full Text Search, we started developing our own report generator. Before that, they used JasperReports, but it did not suit us, firstly because of the too laborious process of creating templates, and secondly because of the difficulties with displaying the results in Excel. They implemented a simple idea: separately describe the logic of data extraction, separately create a template in Excel, Word or HTML. Such an approach was justified, and recently we even singled out the generator core into a separate open-source project called YARG for use outside the platform. About him there will definitely be an article on Habré.
The build system for a long time was based on Ant-scripts. Moreover, if third-party libraries were loaded from the repository in binary form, the platform was connected to the application project only in the form of sources, directly from SVN. Such an approach had advantages at the stage of the formation of the platform - any programmer, while working on his project, could easily fix something in the platform and simply commit his changes. At a certain point, we switched to the standard version, when binary artifacts and platform sources are loaded into the project in the same way as other dependencies - from the Maven repository. At the same time, Ant was replaced by Gradle, which allowed us to conclude the main assembly code in the plugin, and make the project scripts as concise as possible, but at the same time arbitrarily extensible.
When we started making Sherlock, a product for a taxi, we needed a desktop client. Then came the second implementation of GenericUI-components on Swing. As a result, the entire product UI (more than 300 screens) is available both on the web and in desktop versions with the same functionality, the differences are only in the responsiveness of the interface and the nuances of working with the keyboard.
Also for replicated products, we have invented an extension mechanism that allows us to adapt to customer requirements. An extension is essentially a new application project in which the product is used as a platform. Thus, we manage to achieve maximum customization for the customer without changing the code of the main product. The possibility of updating product versions is also preserved - it is enough to align the extension with the new version and rebuild it.
At a certain point in time, the idea to make the platform available to developers outside our company. Two years ago, CUBA was put into service by two more IT companies that made quite large projects on its basis: a system for processing electronic messages of citizens of the Government of Moscow and the federal Electronic Register of Cancer Patients of the Republic of Kazakhstan. This finally convinced us that CUBA could be useful not only for us, and we began preparations for a public release.
From now on, work has begun on the Studio, which reduces the entry threshold for starting development on the platform and makes it possible to more conveniently perform routine tasks. We made Studio a web application that provides interesting application possibilities - from the theoretical ability of working in the cloud to the very practical possibility to quickly connect to a colleague's project and, for example, help him to understand the problem. In addition to the Studio, a plugin for IntelliJ IDEA to navigate CUBA-specific elements of the project was written to help the developer.
Future plans
At the moment, CUBA has moved from a phase of intensive growth and constant changes to a more relaxed stage of evolution. Naturally, first of all, this is a continuous process of various local modifications and elimination of defects. In addition, we plan in the near future to do the finishing of the chart display module - there will appear components for displaying the map and interactive diagrams in JavaScript, which will be managed, like all other GenericUI components, from the server-side Java code. After that, most likely, we will deal with deployment of CUBA applications in the cloud with PaaS providers.
Of course, we are open to dialogue, and the directions for improving the platform will largely be determined by the wishes of the developers who use it.
Unlike the platform itself, Studio is a very young product. First of all, we are working to improve the usability of the Studio and we are trying to make it more intelligent and friendly.
Also, a lot of effort recently applied to the improvement of documentation. While there are gaps in it, there are clearly not enough examples and recipes for solving typical problems. We will eliminate these shortcomings, and next year we are going to release all the documentation in English.
On Habré we plan to publish articles about various aspects of the platform device and the problems that we had to solve. Hope it will be interesting.
Source: https://habr.com/ru/post/204834/
All Articles