Изучаем Java EE 7 - [123]

В листинге 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-дескриптор развертывания делает то же самое.

XML-дескриптор развертывания — альтернатива аннотациям, а это означает, что у любой аннотации имеется эквивалентный XML-тег. При одновременном использовании аннотаций и дескрипторов развертывания настройки в дескрипторе развертывания возьмут верх над аннотациями во время процесса развертывания. Я не стану вдаваться в подробности, описывая структуру XML-дескриптора развертывания (с именем ejb-jar.xml), поскольку он является необязательным и может оказаться очень многословным. В качестве примера в листинге 7.18 показано, как мог бы выглядеть файл ejb-jar.xml, связанный с ItemEJB (который был показан ранее в листинге 7.2). Он определяет класс EJB-компонента, удаленный и локальный интерфейсы, его тип (Stateless). Кроме того, здесь имеет место транзакция, управляемая контейнером (CMT) (Container).

Листинг 7.18. Файл ejb-jar.xml

·········xmlns: xsi="http://www.w3.org/2001/XMLSchema-instance"
·········xsi: schemaLocation="http://xmlns.jcp.org/xml/ns/javaee

·········http://xmlns.jcp.org/xml/ns/javaee/ejb-jar_3_2.xsd"
·········version="3.2">
··
····
······ItemEJB
······org.agoncal.book.javaee7.chapter07.ItemRemote
······org.agoncal.book.javaee7.chapter07.ItemLocal
······
······org.agoncal.book.javaee7.chapter07.ItemEJB
······Stateless
······Container
····
··

Если вы решите произвести развертывание сессионного EJB-компонента в файле с расширением. jar, то вам потребуется сохранить дескриптор развертывания в файле META-INF/ejb-jar.xml. А при развертывании сессионного EJB-компонента в файле с расширением. war вам придется сохранить дескриптор развертывания в файле WEB-INF/ejb-jar.xml. XML-конфигурация описывает детали, специфичные для среды, и не должна указываться в коде с помощью аннотаций (например, если EJB-компонент необходимо задействовать одним путем в среде разработки и другим путем — в средах тестирования/производства).