Изучаем Java EE 7

В листинге 7.17 приведен пример метода, который возвращает Future. Метод sendOrderToWorkflow() использует поток операций для обработки объекта Order. Представим, что он вызывает несколько корпоративных компонентов (сообщений, веб-служб и т. д.) и на каждом этапе возвращается значение status (целочисленное). Когда клиент вызывает метод sendOrderToWorkflow() асинхронно, он ожидает получить значение status потока операций. Клиент может извлечь результат с помощью метода Future.get() или, если по какой-либо причине ему понадобится отменить вызов, у него есть возможность прибегнуть к Future.cancel(). Когда клиент вызовет Future.cancel(), контейнер попытается отменить асинхронный вызов, если выполнение этого вызова еще не началось. Обратите внимание, что метод sendOrderToWorkflow() использует метод SessionContext.wasCancelCalled() для проверки того, задал ли клиент отмену запроса. В результате метод возвращает javax.ejb.AsyncResult, который является удобной реализацией Future. Имейте в виду, что AsyncResult используется как средство передачи результирующего значения контейнеру, а не напрямую вызывающему оператору.

Листинг 7.17. Асинхронный метод, возвращающий Future

@Stateless

@Asynchronous

public class OrderEJB {

··@Resource

··SessionContext ctx;

··public Future sendOrderToWorkflow(Order order) {

····Integer status = 0;

····// обработка

····status = 1;

····if (ctx. wasCancelCalled()) {

······return new AsyncResult<>(2);

····}

····// обработка

····return new AsyncResult<>(status);

··}

}

Обратите внимание в листинге 7.17 на то, что вы также можете применить аннотацию @Asynchronous на уровне класса. Она определяет все методы как асинхронные. Когда клиент вызывает метод sendOrderToWorkflow(), ему необходимо вызвать Future.get(), чтобы извлечь результирующее значение.

Future status = orderEJB.sendOrderToWorkflow (order);

Integer statusValue = status.get();

Дескриптор развертывания

Для компонентов Java EE 7 задействуется конфигурация в порядке исключения, а это означает, что контейнер, поставщик постоянства или брокер сообщений будут применять в их отношении набор служб по умолчанию. Конфигурирование этих служб по умолчанию является исключением. Если у вас возникнет необходимость в поведении, которое не обеспечивается по умолчанию, то вам потребуется явно указать аннотацию либо ее XML-эквивалент. Вы уже видели это при работе с сущностями JPA, где набор аннотаций позволяет настраивать отображение по умолчанию. Аналогичный принцип применяется к сессионным EJB-компонентам. Одной аннотации (@Stateless, @Stateful и т. д.) достаточно для того, чтобы проинформировать контейнер о необходимости применить определенные службы (управление транзакциями, управление жизненным циклом, безопасность, перехватчики, конкурентный доступ, асинхронность и т. д.), однако если вам потребуется сменить их, используйте аннотации или XML. Аннотации присоединяют дополнительную информацию к классу, интерфейсу, методу или переменной, а XML-дескриптор развертывания делает то же самое.