ENRU
Продолжение использования сайта пользователем интерпретируется как согласие на обработку фрагментов персональных данных (таких, как cookies) для целей корректной работы сайта.
Этапы развития LUI
1
Реализация на Oracle Forms
(использовалась с 2002 по 2016 гг.)
Изначально LUI развивался, как интерфейс продукта компании «ФОРС» — Тиражируемой Автоматизированной Системе Расчётов (Биллинг) для предприятий связи — АСР «Fastcom». Поскольку Fastcom использовал Oracle Forms для взаимодействия с пользователем, логично, что первый «движок» LUI был реализован именно на этом продукте.

Со временем стало понятно, что Forms перестал развиваться корпорацией Oracle как продукт. Последняя версия Oracle Forms в техническом плане не удовлетворяет потребностям LUI. Было принято решение создавать новый «движок», на более современной и продвинутой платформе.
2
Реализация на JavaScript + Ajax
(использовалась с 2009 по 2014 гг.)
Начиная с 2008 года новый движок начал разрабатываться, а с 2009 года — использоваться в АСР Fastcom. Два «движка» функционировали одновременно. Совсем отказаться от реализации «движка» под Oracle Forms не позволяло то обстоятельство, что в АСР Fastcom всё ещё имелись формы, разработанные непосредственно на Oracle Forms, которые легко вызывались из «движка» LUI на Oracle Forms и наоборот.

Однако и этот «движок» не устроил по ряду параметров. В частности, по быстродействию.
3
Реализация на Java
(используется с 2015 по настоящее время)
Начиная с 2013 года начал разрабатываться ещё один браузерный «движок», легко масштабируемый по производительности и, таким образом, выдерживающий нагрузку в десятки тысяч пользователей, работающих одновременно. Новый вариант заменил предыдущую реализацию в 2015 году, и этот переход был практически незаметен как для конечных пользователей, так и для разработчиков бизнес-логики Приложения.

Это очень хорошо отлаженный «движок», удовлетворяющий всем требованиям обслуживаемых им Приложений. Но область его применения — приложения, написанные на СУБД Oracle. Хотелось бы расширить эту область применения.
4
Классическая трёхзвенная архитектура (используется с 2019 года)
Поэтому в настоящий момент доступен ещё один «движок» — с гибко подключаемыми языковыми модулями и модулями доступа к БД

Здесь декларативные и процедурные языки подключаются как внешние модули. Таким образом, динамические структуры могут описываться языками SQL, PL/pgSQL, JavaScript, Java, Perl и т.п., а также их комбинациями!

Новая реализация обеспечивает приложению возможность поддерживать одновременно несколько соединений к одной или разным Базам данных, в том числе, СУБД различных типов! (Oracle, Postgres, MySQL, MSSQL Server и др.) К примеру, в формах типа «Мастер-Деталь» мастер список будет извлекать данные из одной БД, а детальные записи будут извлекаться из другой. Этот принцип позволит:

  • Интегрировать между собой системы с различными СУБД, не используя трудно отлаживаемые и ненадёжные гетерогенные db-link'и;
  • Плавно, частями, безболезненно мигрировать прикладную систему из одной СУБД в другую.
Другая фундаментальная возможность этой реализации: работа как в режиме «длинных транзакций», так и в режиме «коротких транзакций»:

  • «Короткая транзакция» начинается и заканчивается в процессе обработки одного интерфейсного события, что очень хорошо подходит для систем массового назначения — для условно бесконечного числа пользователей;
  • «Длинная транзакция» поддерживается в промежутке между событиями, что даёт управление блокировками на уровне БД, целостность чтения данных и откатов к началу транзакции. Этот режим очень подходит для внутрикорпоративных систем с критической ответственностью за целостность и корректность данных;
  • Комбинированный вариант, когда одни соединения с СУБД работают в режиме «коротких транзакций», а другие — в режиме «длинных транзакций».
← На главную страницу