Длинный текст о выходе Celesa 7

[Ivan Ponomarev]

Всем привет!

Прогресс не стоит на месте и на нашем GitHub готовится к выходу Celesta версии 7, которая является, по сути, новым отдельным проектом и полностью изменяет парадигму использования Celesta.

Основным вариантом использования Celesta 7 является разработка с использованием Java-фреймворка Spring.  Интеграция с этой технологией теперь будет наиболее простая и прямолинейная. Ради этого пришлось отказаться от многих привычных вещей: Celesta 7 утрачивает совместимость с Showcase и Flute; вместо Showcase и Flute предполагается отдельная разработка бэкенд Restful-сервисов при помощи Spring Boot
и отдельная разработка фронтенда. Такие возможности Flute, как обработка очередей и задания по расписанию уже присутствуют в виде стандартных Spring-компонент.

При этом выход Celesta 7 не повредит проектам Flute и Showcase (нужно просто не обновлять Maven-зависимости на 7-ку).

Мы продолжим поддержку Celesta 6-й версии на протяжении всего времени, что будет использоваться Celesta 6 и её Jython-скрипты.

Основные отличия

1. Фундаментальным отличием Celesta 7 от Celesta 6 является инверсия контроля: если ранее Celesta была ответственной за запуск Celesta-процедур (мы указывали имя процедуры и параметры), то теперь в уже выполняющейся процедуре мы можем использовать Celesta как сервис для создания CallContext, из которого затем рождаются курсоры и доступ к базе данных.

Нечто подобное уже делалось в прежних версиях при помощи всевозможных "костылей", т. к. потребность в таком использовании была всегда, но изначальная архитектура не предполагала, что кто-либо, кроме самой Celesta, может "грамотно" создавать CallContext. Создание CallContext было усложнено, но люди всё равно создавали его вне Celesta всевозможными хаками. Теперь всё по-другому: создать CallContext становится максимально просто. Не Celesta теперь выполняет процедуры, а из уже выполняющейся процедуры мы получаем доступ к функциональности Celesta.

2. Т. к. Celesta больше не запускает процедуры, то мы полностью убрали из проекта Celesta зависимость от Jython. Взамен этого Celesta можно использовать в качестве Maven-зависимости из любого JVM-языка, будь то Java, Kotlin, Groovy, JRuby или, при желании, тот же Jython.

3. Другое фундаментальное отличие заключается в том, что из  Celesta полностью убрано понятие сессии. Убраны методы  login/logout, класс SessionContext, логирование входов-выходов. Понятие пользовательской сессии отсутствует в RESTful-архитектуре, логин-логаут является прерогативой модуля Mellophone, поэтому в целом вся эта функциональность нарушала Single Responsibility Principle для Celesta и являлась лишним звеном уже для Celesta 6. Теперь сессии можно  либо поддерживать внешними средствами (Tomcat-ом, например), либо вовсе их не иметь, если речь идёт о REST-сервисах.

При этом мы сохраняем принцип авторизованного доступа к данным: никакой доступ к данным из базы не производится анонимно, что позволяет сохранить всю функциональность по распределению прав доступа на уровне таблиц и функциональность лога изменений таблицы.

3. Кодогенерация курсоров на Jython ликвидирована. Вместо неё производится кодогенерация курсоров на Java при помощи celesta-maven-plugin.

4. Документация Celesta 7 будет вестись не на Wiki, а в виде AsciiDoc непосредственно в проекте Celesta7. Таким образом решается проблема привязки документации непосредственно к версии системы (каждый PR в Celesta теперь будет проверяться не только на степень покрытия тестами, но и на актуализацию документации).  Отдельно мы будем решать вопрос о том, где и как будет публиковаться скомпилированная документация.

Пример использования

Общий принцип использования Celesta 7 при создании RESTful-сервисов следующий. На уровне контроллера мы, так или иначе, знаем имя пользователя, от которого работаем (это отрабатывается на уровне гейтвеев и фильтров):

@RestController
@RequestMapping(value = "/hello")
public class HelloController {
    //инжектим сервис через конструктор
    private final HelloService srv;
 
    public HelloController(HelloService srv) {
        this.srv = srv;
    }
 
    @GetMapping(value = "/{name}")
    public String hello(@PathVariable String name) {
        //Создаём CallContext, передавая в него только имя пользователя
        //Данный объект получит статус NEW
        CallContext cc = new CallContext(name);
        //Вызываем сервис
        return srv.greet(new DummyCallContext(name), name);
    }
}

На уровне сервиса всё работает так:

@Service
public class HelloService {
    //Это -- аннотация Celesta, благодаря которой при вызове
    //метода будет открыта транзакция и CallContext перейдёт
    //из статуса NEW в статус ACTIVATED
    //А при завершении вызова -- коммит транзакции и перевод
    //контекста в статус CLOSED
 
    @EntryPoint
    public String greet(CallContext cc, String name) {
        //Тут мы можем работать с курсорами,
        //например, FooCursor c = new FooCursor(cc);
 
        return String.format("<p>Hello, %s!</p>" +
                        "<p>we are in connection #%s</p>" +
                        "<p>we are in method #%s</p>", name,
                cc.getConnection().getName(),
                cc.getProcName());
    }
}

Объект CallContext теперь может находиться в трёх статусах:

•   NEW -- контекст создан, но не имеет сссылки на Celesta и не пригоден для создания курсоров.
•   ACTIVATED -- в объект переданы ссылки на Celesta, сгенерирован Connection к базе данных, открыта транзакция и мы можем создавать курсоры.
•   CLOSED -- транзакция завершена коммитом или роллбэком, подключение возвращено в пул, все курсоры закрыты.

Как видите, основную рутинную работу по подготовке курсора берёт на себя обработчик аннотации @EntryPoint.

При этом возможны варианты: если  имя пользователя нерелевантно (все работают от одного пользователя), то
можно создать экземпляр SystemCallContext(), который будет работать от "системного пользователя", имеющего доступ
ко всем данным.

Если мы не хотим пользоваться машинерией Spring и аннотацией @EntryPoint, то создать "активированный" курсор
можно, передав в конструктор дополнительными параметрами экземпляр класса Celesta и название вызываемой процедуры
(название процедуры в этом случае нужно не для вызова самой процедуры, а для нужд логирования и профилирования,
@EntryPoint прописывает нужное название процедуры автоматически.)
 

 Что дальше?

В ближайшие дни Celesta 7 появится на Maven Central. В новых проектах мы сможем прозрачно писать RESTful-сервисы на SpringBoot на Celesta 7, используя шаблон, приведённый выше. С технологией Jython мы начинаем прощаться.

Всем хорошего дня,

 

С уважением,

ИП