В любом веб-приложении одним из краеугольных вопросов является поддержка клиентских сессий. Платформа JavaEE не исключение и для этих целей в ней существует специализированный HttpSession API, доступ к которому есть у любого веб-приложения, развёрнутого в некотором сервлет-контейнере. Что же из себя представляют эти самые сессии?

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

В спецификации CDI предусмотрен механизм «перехватчиков», который позволяет реализовывать в прикладном коде приёмы аспектно-ориентированного программирования. Иначе говоря, разработчику становится доступна сквозная функциональность (cross cutting concerns), то есть прежде, чем обратиться к некоторому методу CDI-бина, у программиста появляется возможность выполнить предобработку, сам бизнес-метод и постобработку.

Для этих целей и существует механизм CDI Interceptors, причём применяется он не только для спецификации CDI, но и активно используется в технологии Enterprise JavaBeans.

Ни для кого не секрет, что ни одна повседневная задача разработчика не обходится без потребности валидировать поступающие «извне» потоки данных: с пользовательских HTML-форм, внешних систем и т.д. На первый взгляд, ничего нет плохого в том, что каждый программист пытается по-своему решить эту задачу (фактически написав «очередной велосипед», используя множество проверок, состоящих из if-else блоков).

Но при таком подходе высока вероятность, что в будущем поддержка такого «спагетти»-кода станет крайне затруднительной из-за постоянной потребности в модификации атрибутов класса или в случае переиспользования проверок в различных участках системы, например, на клиенте и на сервере. Чтобы избежать подобных проблем, в стеке JavaEE предусмотрели спецификацию Bean Validation 2.0 (JSR 380).

Необходимость коммуницировать клиенту и серверу существует не только в Java EE-приложениях, но и в любых других веб-приложениях. Как известно, для этих целей используются различные подходы, например, поллинг. При поллинге клиент периодически опрашивает сервер, отправляя клиентский запрос, а тот в свою очередь формирует ответ на него.

То есть для поддержки актуального состояния данных, клиент должен постоянно опрашивать сервер для получения обновлённых данных. Такой подход не всегда удобен, так как требует дополнительных накладных расходов и действий со стороны клиента (если обновление данных на сервере не произошло, сеть нагружается впустую). Устранить некоторые недостатки поллинга помогают его разновидности, тот же Long polling.

Timer API — полезный инструмент Enterprise Java Beans, позволяющий легко создавать задачи, выполняющиеся с задержкой по времени или требующие выполнения по расписанию. Например, можно в строго определённый час запускать формирование ежедневных отчётов, собирая сводную статистику. Для работы на выбор разработчику предоставляются два типа таймеров.