Introducing CUBA

Introducing CUBA
A Haulmont Technology White Paper
03/2013
1
INTRODUCTION ........................................................................................................................... 2
KEY CHALLENGES TO ENTERPRISE SOFTWARE DEVELOPMENT ................................ 3
CUBA PLATFORM ......................................................................................................................... 4
Basic Features .................................................................................................................................. 4
CUBA Application Structure ............................................................................................................ 5
Middleware Architecture .................................................................................................................. 6
Client Architecture ............................................................................................................................ 7
Database Usage ................................................................................................................................ 8
Security subsystem .......................................................................................................................... 8
Report generation subsystem ......................................................................................................... 9
Workflow Subsystem ...................................................................................................................... 10
Full-text Search Subsystem ........................................................................................................... 11
Key Benefits of CUBA .................................................................................................................... 11
Future Development ....................................................................................................................... 12
Introduction
This white paper provides a summary of the common challenges to enterprise software
development and an overview of how Haulmont’s CUBA development platform can provide
developers with the tools to successfully meet these challenges to deliver scalable and
flexible solutions.
For the purposes of this document, enterprise software is defined as a wide range of
information systems designed to support enterprise operations, management and decisionmaking.
2
Key challenges to enterprise software development
Most enterprise software development projects share a common set of basic requirements,
including:
 Rich user interface
 Low-cost system deployments and upgrades, which in turn create the need for web
technologies
 Tabular representation and filtering for large data sets
 User access control
 A mechanism for report building and generation
In many cases, the requirements are even more sophisticated, for example:
 Support for additional types of user interfaces, such as desktop or mobile, to provide a
richer user experience, customized for different categories of users
 Table data filtering on complex conditions, undetermined at the time of design
 User access control on the domain objects level, as well as at the attribute level and
specific instances. Additional requirements include the ability to set permissions at runtime
without changing the application code
 The ability to create and edit report forms at runtime and to generate tabular reports in
XLS format
 The ability to organize business logic into processes with graphical representations that
are easily understood and edited by the end users
 Fault tolerance and no single point of failure
 Integration with third-party applications
In meeting these requirements, enterprise software developers typically face a range of
challenges, such as:
 The difficulty of creating rich user interfaces using diverse technologies (Java, HTML,
CSS, JavaScript).
 The need to plan system architecture with the expectation of possible future changes to
requirements for functionality and deployment
 Off-the-shelf products typically face challenges in adapting the product to the requirements
of individual customers and then trying to upgrade these clients to new version - so main
product code must be isolated from the customized code
 Short project terms and low budgets often prevent the aforementioned requirements to be
fulfilled
 There is a need to attract many highly skilled and experienced developers to the project to
meet the complexity of these challenges
3
CUBA Platform
The CUBA development platform stemmed from Haulmont’s experiences in enterprise
software development for large clients. Initiated by Haulmont in 2008, CUBA forms the basis
of all the software delivered by the company; both off-the-shelf products and bespoke
solutions. The platform effectively solves all of the challenges outlined above and offers a
huge range of other features to assist in the creation of complex enterprise IT solutions.
CUBA solutions are already being used by companies in the UK, France and Russia, with
impressive results.
Basic Features
 Based upon Java, CUBA has the ability to run on almost any operating system on servers
and workstations
 Fully open source code
 Independence from the functionality of a specific DBMS
 Platform-based applications that can be easily deployed in fail-over configuration
 Availability of effective user interface development tools based solely on Java and XML
 Powerful tools for user access rights allocation with the ability to change the configuration
at runtime
 A built-in mechanism to create and generate reports in PDF and Office formats.
 A mechanism to create and execute business processes with an integrated WYSIWYG
process editor
 Full-text search through entity attributes and the contents of the uploaded files.
 The ability to display charts, including Gantt charts
 Built-in REST API which enables data transfer in XML or JSON for rapid integration with
third-party software
 A mechanism to create functionality extensions which allows the customisation of off-theshelf products for specific customer needs without affecting the ability to receive future
upgrades
 Functionally, the platform is a set of modules, including:
o CUBA – the basic module and the mandatory part of any application
o Reports – an optional module for report generation
o Workflow – an optional module for working with business processes
o FTS (Full Text Search) – an optional module for full text search
o Charts – an optional module to display charts in the web client
o CCPayments – an optional module to accept credit card payments
4
CUBA Application Structure
The diagram below shows an example structure of a full-scale application built on the
platform.
This diagram illustrates a no-single-point-of-failure application with load balancing and the
ability to connect different types of clients. Of course, in the basic deployment configuration
the application is located on a single server, which also runs the database.
Physically, a CUBA application always contains at least two parts:
 A middleware web application (referred to as “core” or “middleware”).
 A client web application.
Both web applications are standard JavaEE Web Profile applications and can be deployed on
any Java web server - Apache Tomcat is used by default.
Web and desktop clients communicate with the middleware in a similar way through HTTP,
which allows arbitrary middleware placement, including the location behind the network
firewall. It should be noted that the basic case of single-server deployment assumes that the
local interaction between the middleware and the web client bypasses the network stack to
reduce overhead costs.
5
Middleware Architecture
The following diagram illustrates the basic components of CUBA application middleware:
The application components are displayed on the left:
 Services – container-managed components which form the ‘application boundary’ and
provide an interface for middleware clients.
 Managed Beans – container-managed components which contain the business logic of the
application. They are called by services, other beans, or through an optional JMX
interface.
 Entities – classes which model the object domain of the application.
 The application components make use of the infrastructure and the metadata provided by
the platform (in the middle of the diagram), which is, in turn, based on the following opensource frameworks (on the right):
 Spring – a well-known Dependency Injection container which is also used to implement
client interaction over the network.
 OpenJPA – an implementation of Object-Relational Mapping according to JPA standard.
6
Client Architecture
The following diagram illustrates the basic components of web and desktop clients.
The central part of the diagram shows the application components of the system client:
 XML Descriptors – XML files which contain information on the screen layout and the data
sources.
 Java Controllers – Java classes which contain screen initialization logic and handle user
interface events.
The application code of the client interacts with the interface of the visual components (VCL
Interfaces), implemented in different ways for web and desktop clients. The web
implementation is based on the open-source AJAX framework, Vaadin. The desktop client
uses Java Swing.
The Visual Components Library, (VCL) contains a large collection of ready-made
components for data visualisation:





tables (including hierarchical and grouped);
tree;
different types of input fields;
fields to display and select the related entities;
a filter component that allows the users to generate filter conditions on the basis of any
attributes from the extracted graph of entities.
The data sources mechanism (Datasources) provides a unified interface which enables the
operation of data-aware visual components.
7
Database Usage
At the time of this writing, the platform supports the following databases out of the box:
 PostgreSQL 8.3+
 Microsoft SQL Server 2005+
 Oracle 10g+
Because CUBA does not use any specific database server features, other relational
databases can be easily supported and quickly implemented if required.
On the application level, the platform also allows the use of native SQL and offers optional
fine-tuning of database interactions with the help of a built-in data-loading framework MyBatis.
Security subsystem
The basic components of CUBA security subsystem are shown in the following diagram:
The ‘User Session’ is the key security element; this object is associated with the
authenticated user and contains the information on the user’s rights to access the data.
Platform and application code calls a User Session for authorization. In the case of a faulttolerant configuration, User Sessions of the active users are replicated between the servers
in a middleware cluster.
User permissions are managed through security subsystem management screens by
defining the user’s access group and assigning a set of roles. The user’s set of roles
determines the effective set of permissions of the following types:
 The ability to open a screen
 The ability to perform operations on a given entity (read, write, create, modify, delete)
 Access to any attributes of an entity (modification, read only, no access)
8
 The permission to use certain functionality
Access groups define a set of constraints which control the access on the level of individual
items (rows) of an entity. For example, the user may be able to see only the documents
created in his department.
The security subsystem can also be integrated to use Active Directory for authentication
rather than store pass words in the database. Additionally, the Single Sign-On principle is
applied on Windows domain users, i.e. the system does not request a username and
password, but automatically uses the registration data of a given domain user.
Report generation subsystem
The basic components of the report generation subsystem are represented in the following
diagram:
A report is built by creating two related system artifacts: the visual presentation template and
the description of the extracted report data. The template in XLS, DOC, or HTML is created
externally, and the data is described in the report designer screen.
The report is generated in PDF, DOC, HTML, or XLS format according to the parameters set
in the description and the original template.
9
Workflow Subsystem
The basic components of the workflow subsystem are represented in the following diagram:
A workflow is created through the sequential change of states of an entity (Card) in
accordance with a specified process (Process), which involves users and automatic
mechanisms. A typical example is the endorsement of a document between the employees of
a given organization.
The process sets a number of state nodes and transitions between them, as well as the
following associated objects:
 Activities – the program code that runs during a transition to a state.
 Forms – the screens which allow interaction with the user during his decision-making
process before or after the transition to or from a state.
 Timers – the program code which is automatically triggered at a specified time after
entering a state.
While the process is running, Assignments can also be created to inform the user that he has
to take some action on the process.
A new process can be created with a WYSIWYG editor integrated in the platform, and then
deployed directly into the running application. The user can create their workflow from a
palette of possible states, actions, timers and forms that are defined during application
development.
10
Full-text Search Subsystem
A Full Text Search subsystem (FTS) enables unstructured search through entity attributes
and the contents of uploaded files.
FTS contains two related mechanisms: indexing and search.
Indexing is performed asynchronously with each change of a registered entity.
The search is performed in such a way that the results include not only the entities which
contain the search string in one of their attributes, but also the related entities which use this
attribute for display. For example, if a Document contains a reference to a Buyer, and the
search string contains the name of the Buyer, the first search result to be displayed will be
the Buyer, and then the Document which refers to him will also be displayed. This search
mechanic makes the search more effective for the user, who can see the Buyer’s name in the
Edit screen of the Document.
Key Benefits of CUBA
All systems based upon CUBA benefit from an effective architecture that has been heavily
tested and is business-proven across a range of applications created by Haulmont and third
party developers. In practice, the functionality offered by CUBA has enabled a significant
reduction the development time and the project costs.
CUBA features a declarative approach to user interface development that offers the following
advantages:



Abstracts the developer from the complexities of diverse technologies
(HTML/JavaScript, Swing, etc.)
Clearly separates the visual layout from the initialization and event handling logic, which
makes it easier to understand and change the code
Screens operate across web client and desktop clients, to help developers to build
systems that take advantage of the web interface or desktop application features with
little effort
The platform provides ready-made functionality at the following levels:

System level
o Infrastructure for organizing business logic on the middleware
o Visual component library and client infrastructure
o Tools for working with configuration settings and localized messages
o Tools for performing background UI tasks
o Mechanisms to run scheduled tasks on the middleware
o Tools for data caches implementation
o The ability to use dynamic attributes to define new entity attributes during the
setup and operation of the system
 Application level
o Security subsystem
11
o Report generation subsystem
o Business process management subsystem
o Full-text search
o A mechanism for reliable asynchronous email sending
o Means of entity changes logging and version storage
 Deployment level
o The ability to work in a fail-over configuration
o Ready-made tools for third-party software integration
o The ability to create independent extensions to adapt the basic product for
particular customers
To create a Web client based on CUBA, one does not necessarily have good knowledge of
classical web technologies (HTML, CSS, JavaScript).
Future Development
Based upon feedback from CUBA developers from both Haulmont and third party developers,
the CUBA team constantly adds new features and improvements to the platform.
Currently, the main focus for future development is the creation of CUBA Studio for rapid
application development. Designed to offer the core functionality of the development
environment via a web application which interacts with classic Java IDEs (e.g. Intellij IDEA),
the Studio includes a visual screen editor, project creation tools, data model definitions and
other features.
CUBA Studio will offer developers the chance to get a feel for working with CUBA and provide
a lightweight introduction to the full range of enterprise software development tools within the
full platform. Eventually CUBA Studio will be offered as a fully cloud-based development
platform enabling developers to utilise CUBA via the web.
For more information on becoming a CUBA developer or to contact Haulmont Technology
please email info@haulmont.com or call +44(0) 203 214 5110.
12