Если вы занимаетесь разработкой софта для предприятий, то возможно уже написали собственную платформу. Которая позволяет вам быстро создавать UI и логику для работы с данными, содержит общую для ваших проектов функциональность: управление правами пользователей, генератор отчетов, BPM и тому подобное, и имеет архитектуру, позволяющую легко сопровождать и масштабировать приложение. Если еще не успели написать, предлагаем познакомиться с нашей разработкой — платформой CUBA.
Платформа существует более четырех лет, но до сих пор она использовалась в довольно узком кругу разработчиков нашей компании и партнеров. Мы успели сделать на ней два тиражируемых продукта и больше десятка заказных проектов. И вот настал момент, когда после длительной подготовки, мы решились выпустить ее в виде продукта, доступного всем желающим.
Для начала приведу краткий список основных возможностей. Подробности разумеется можно узнать на сайте.
- Декларативное создание UI: компоновка экранов в XML, инициализация и обработка событий в классах Java.
- Библиотека data-aware визуальных компонентов. Есть все стандартные, плюс специфические, например, универсальный фильтр данных, поля выбора связанных сущностей с разнообразными возможностями, таблица с группировками.
- Экраны работают в веб (AJAX) и в десктоп (Swing) клиентах. Исходники общие.
- Метаданные — расширенная информация о модели данных. Проектирование модели данных «от сущностей к таблицам».
- Мягкое удаление записей в БД.
- Управление правами доступа на уровне операций с сущностями, их атрибутов и отдельных экземпляров, экранов и компонентов UI.
- Подключаемая при необходимости функциональность: генератор отчетов, модуль бизнес-процессов с визуальным редактором, полнотекстовый поиск, работа с кредитными картами.
- «Из коробки» поддерживаются PostgreSQL, MS SQL Server, Oracle, HSQL.
- Стандартный деплоймент на любом веб-контейнере.
- Горизонтальное масштабирование на кластере серверов, можно отдельно средний слой, отдельно веб-серверы.
Ну и для того, чтобы всем этим было удобно пользоваться, мы сделали Студию. Это отдельное приложение, которым пользуется разработчик параллельно с обычной Java IDE. Студия предоставляет графический интерфейс к механизмам платформы, позволяя мышкой накликать модель данных, сгенерировать DDL-скрипты для БД, нарисовать экраны в WYSIWYG-редакторе, сделать заготовки сервисов среднего слоя. Использование Студии не обязательно, но сильно облегчает многие вещи, особенно на начальном этапе проекта.
Кому это может пригодиться?
Мы позиционируем CUBA в первую очередь как инструмент для разработчиков, занимающихся автоматизацией внутренних бизнес-процессов предприятий. Это могут быть производственные процессы, закупки и продажи, документооборот, управление персоналом, средства мониторинга и так далее. CUBA может послужить основой любой учетной или управленческой системы.
Кроме того, проверенным вариантом является использование платформы в качестве backend распределенной системы. В этом случае на платформе создается средний слой с основной бизнес-логикой и UI для сотрудников, а сайты и мобильные приложения для внешних пользователей выступают клиентами среднего слоя.
Используя платформу, можно сосредоточиться в основном на бизнес-логике, так как большинство инфраструктурных задач уже решены. Соответственно, сделать проект быстрее и меньшими усилиями.
Условия использования CUBA описаны на нашем сайте. Бесплатный вариант есть.
Документация есть.
История
Теперь хочу рассказать о зарождении и эволюции платформы. Собственно, в основном речь пойдет о технологиях, так что станет примерно понятно, как CUBA устроена.
С чего все началось. Наша компания создавалась для того, чтобы делать информационные системы для предприятий. Разные системы для разных предприятий, и чем больше, тем лучше. То, что писать мы будем на Java, не вызывало сомнений в силу предыдущего положительного опыта, независимости от ОС, наличия великолепной IDE, широкого выбора фреймворков всех уровней и тому подобного. В то же время мы понимали, что делать каждый проект с нуля, пользуясь только тем, что дают Java и доступные фреймворки, сложно и неэффективно. Значительная часть функциональности корпоративных систем пересекается, независимо от особенностей бизнеса. Да и ту часть, которая уникальна в каждом приложении, мы хотели делать проще и быстрее. К сожалению (или к счастью), мы не нашли ничего готового в мире Java, что удовлетворяло бы нашим требованиям, никакой подходящей «платформы для быстрого создания бизнес-приложений», и как водится, решили написать свою.
Начали со среднего слоя — взяли JBoss с EJB3, в качестве ORM прикрутили OpenJPA. Почему не Hibernate — это тема для отдельной статьи, постараемся со временем ее написать. Научили OpenJPA работать с мягким удалением прозрачно для разработчика, чтобы не надо было ничего дописывать в запросы и контролировать результаты.
Написали свой фреймворк метаданных, необходимый нам для реализации универсальных механизмов, таких как визуальные компоненты, настраивающие свои свойства в зависимости от типа атрибута сущности, который они отображают. На основе метаданных сделали механизм декларативного объявления графов сущностей (мы их называем “представления” — views). Такой механизм нужен для того, чтобы с любого уровня приложения можно было запросить данные и указать, какой объектный граф сейчас требуется, т.е. с какими атрибутами и связанными сущностями мы хотим в данный момент работать.
Начали работать над security: пользовательская сессия, сами пользователи, роли и права доступа. Поломали голову над тем, как реализовать контроль доступа на уровне строк (row-level security). Остановились на том, что предикаты ограничений должны группироваться в отдельную от ролей иерархическую структуру. Всё управление security, разумеется, сразу делали динамическим в смысле возможности настройки в runtime.
Сложным был выбор технологии для веб UI. Нам нужно было поверх какого-то фреймворка создать свой слой абстракции для разделения компоновки и кода экранов, а также для реализации набора визуальных компонентов, работающих с сущностями с помощью наших метаданных. Кроме того, мы планировали в будущем сделать реализацию этого же слоя на базе десктопного Swing. В общем, хотелось, чтобы прикладной код не зависел ни от каких технологий, кроме Java и наших собственных. В итоге, для веб клиента выбрали Vaadin (тогда он назывался ITMill). Альтернатив было немного, ну и в любом случае сейчас не жалеем о выборе, так как фреймворк мощный и активно развивается. Хотя набили много шишек, попытаемся о них рассказать в отдельной статье.
Таким образом у нас появился GenericUI — модуль платформы для создания экранов на XML и Java. Он состоит из загрузчиков экранов, библиотеки визуальных компонентов и источников данных (datasources), связывающих компоненты с моделью данных. Первым, что мы написали на GenericUI, были экраны управления security самой платформы. Ну а потом начали делать первое приложение — это была заказная система документооборота. Надо сказать, что GenericUI позволяет работать в обход себя, напрямую с компонентами нижележащего UI-фреймворка. Поначалу мы этим активно пользовались, так как возможностей GenericUI часто не хватало. Со временем, в результате развития платформы, необходимость в таком “низкоуровневом” кодировании почти отпала, 99% прикладного кода работает только с обобщенными интерфейсами.
Через некоторое время пришла идея отказаться от JBoss и реализовать всю инфраструктуру на Spring. Замечательная функциональность и расширяемость Spring дала нам возможность реализовать нужные механизмы более просто и надежно. Плюс мы обрели независимость от сервера, а также время старта приложения на Tomcat от 5 до 15 секунд, что в разы быстрее, чем было на JBoss.
Несмотря на приемлемое время рестарта приложения, иногда необходимо деплоить части приложения на лету, без остановки сервера. Поэтому мы реализовали возможность динамической компиляции и загрузки классов из специального каталога. Более того, cейчас Студия постоянно отслеживает изменения в проекте и подбрасывает в этот каталог исходники UI, что очень помогает при разработке экранов — можно увидеть результат изменений без рестарта, логина, поиска экрана в меню и т.д.
Настала пора наращивания функциональности — в приложениях нужны были управление бизнес-процессами и полнотекстовый поиск. Раздувать основную часть платформы мы не стали, а разбили ее на несколько проектов, которые используются приложениями при необходимости.
После Workflow и Full Text Search начали разработку собственного генератора отчетов. До этого использовали JasperReports, но он нас не устраивал, во-первых из-за слишком трудоемкого процесса создания шаблонов, а во-вторых из-за сложностей с выводом результатов в Excel. Реализовали простую идею: отдельно описывать логику извлечения данных, отдельно создавать шаблон в Excel, Word или HTML. Такой подход себя оправдал, и недавно мы даже выделили ядро генератора в отдельный open-source проект под названием YARG для использования вне платформы. Про него обязательно будет статья на Хабре.
Система сборки довольно долгое время базировалась на Ant-скриптах. Причем, если сторонние библиотеки загружались из репозитория в бинарном виде, то платформа подключалась к прикладному проекту только в виде исходников, напрямую из SVN. Такой подход имел преимущества на этапе становления платформы — любой программист при работе над своим проектом мог легко поправить что-то в платформе и просто закоммитить свои изменения. В определенный момент мы перешли на стандартный вариант, когда бинарные артефакты и исходники платформы загружаются в проект так же, как и остальные зависимости — из Maven-репозитория. Заодно заменили Ant на Gradle, который позволил нам заключить основной код сборки в плагине, а скрипты проектов сделать максимально лаконичными, но при этом произвольно расширяемыми.
Когда мы начали делать Sherlock — продукт для такси, потребовался десктопный клиент. Тогда и появилась вторая реализация GenericUI-компонентов на Swing. В результате весь UI продукта (более 300 экранов) доступен и в веб и в десктоп вариантах с одинаковой функциональностью, отличия только в отзывчивости интерфейса и нюансах работы с клавиатуры.
Также для тиражируемых продуктов мы придумали механизм расширений, который позволяет адаптироваться к требованиям заказчиков. Расширение — это, по сути, проект нового приложения, в котором продукт используется как платформа. Таким образом нам удается добиваться максимальной кастомизации под заказчика без изменения кода основного продукта. Сохраняется и возможность обновления версий продукта — для этого достаточно привести расширение в соответствие новой версии и пересобрать его.
В определенный момент времени появилась идея сделать платформу доступной разработчикам за пределами нашей компании. Два года назад CUBA была взята на вооружение еще двумя ИТ-компаниями, которые сделали на ее основе довольно крупные проекты: систему обработки электронных сообщений граждан Правительства Москвы и федеральный Электронный регистр онкобольных Республики Казахстан. Это окончательно убедило нас в том, что CUBA может быть полезной не только нам, и мы начали подготовку к публичному релизу.
C этого момента началась работа над Студией, которая позволяет снизить порог входа для начала разработки на платформе и дает возможность более удобно решать рутинные задачи. Мы сделали Студию веб приложением, что дает интересные возможности применения — от теоретической способности работы в облаке до вполне практической возможности быстро подключиться к проекту коллеги и, например, помочь ему разобраться в проблеме. Кроме Студии в помощь разработчику написали плагин к IntelliJ IDEA для навигации по специфическим для CUBA элементам проекта.
Планы на будущее
На данный момент CUBA перешла из фазы интенсивного роста и постоянных изменений в более спокойную стадию эволюции. Естественно, в первую очередь это непрерывный процесс различных локальных доработок и устранения дефектов. Кроме того, мы планируем в ближайшее время заняться доделкой модуля отображения диаграмм — там появятся компоненты для отображения карты и интерактивные диаграммы на JavaScript, которые будут управляться, как и все остальные GenericUI-компоненты, из серверного Java-кода. После этого, скорее всего, займемся вопросами деплоймента CUBA-приложений в облаке у PaaS-провайдеров.
Разумеется, мы открыты для диалога, и направления совершенствования платформы во многом будут определяться пожеланиями разработчиков, ее использующих.
В отличие от самой платформы, Студия является очень молодым продуктом. В первую очередь мы работаем над повышением удобства использования Студии и стараемся сделать ее более умной и дружелюбной.
Также много усилий в последнее время прикладываем к улучшению документации. Пока в ней есть пробелы, явно не хватает примеров и рецептов решения типовых задач. Эти недостатки и будем устранять, а в следующем году собираемся выпустить всю документацию на английском.
На Хабре мы планируем публиковать статьи о различных аспектах устройства платформы и о проблемах, которые нам приходилось решать. Надеюсь, что будет интересно.
Автор: krivopustov
