Order commercial services
Select the type of service:
By clicking the "Send a request" button, I give my consent to processing of my personal data in accordance with the Federal law of 27.07.2006 No. 152-FZ "On personal data" on the terms and for the purposes specified in the Consent to personal data processing.
This site uses cookies and similar technologies related to personal data to offer you a better browsing experience and analyse traffic. By clicking "I Accept" on this banner, or using this site, you consent to this.
I Accept
LUI Development History
Oracle Forms Implementation
Initially, LUI was developed as an interface for one of the FORS company products, i.e. Fastcom automated billing system. Since it used Oracle Forms for user interaction, it was a logical decision to create the first engine based on this product.

However in due time, it was obvious that Forms was no longer developed by Oracle, and its latest release didn't meet LUI technical requirements. That said, the next step was to create a new engine, based on a modern and more advanced platform.
JavaScript + Ajax Implementation
The development started in 2008, and in 2009 the new engine was integrated into Fastcom. However the product still used forms developed specifically for Oracle Forms, which didn't let shutting it down completely. The two engines worked in tandem, and the forms working on Oracle engine could be easily accessed through LUI and visa versa.

Still, the new engine didn't meet a number of our requirements, performance for instance.
Java Implementation
(2015 – present time)
From after 2013 we've started development of a new engine, working in browser and having scalable performance which allows it to handle tens of thousands of users simultaneously. Its integration in 2015 went smoothly and almost unnoticed by both users and developers of business logic.

Although this engine is well-adjusted and meets all the requirements of the applications working on it, it still has quite narrow application area, that is Oracle Database applications only, and we would rather expand it.
Classic three-tier architecture
(2019 – present time)
That is why a new engine having flexibly connected language modules and database access modules is available.

Here, the declarative and procedural languages are connected as plugins. Hence the dynamic structures can be defined using SQL, PL/pgSQL, JavaScript, Java, Perl, etc., as well as their combinations.

This new release allows the application to have several connections to one or multiple databases simultaneously, including different DBMS types (Oracle, Postgres, MySQL, MSSQL Server, etc.). For instance, when dealing with Master-Detail forms, the master list can receive data from one database, while the details' records can be extracted from the other one. This principle allows:

  • Integration of systems with different DBMS without using unreliable and hard to debug heterogeneous db-links
  • Smooth step-by-step migration of the application from one DBMS to another

Another essential feature of this release is working both in long-living and short-living transactions modes:

  • Short-living transaction starts and ends during a single interface event, which suits well for large-scale systems with a virtually infinite number of users
  • Long-living transaction spans across the events, providing the opportunity of handling locks management, data consistency, and rolling back transactions at the database level. This mode suits well for enterprise systems, where data consistency is crucial.
  • Combined scenario provides both modes when some connections to the DBMS work in the short-living mode, and others — in the long-living mode.