В дополнение к удаленному вызову посредством RMI EJB-компоненты без сохранения состояния также могут вызываться удаленно как веб-службы SOAP или RESTful. Главы 14 и 15 посвящены веб-службам, поэтому я не стану описывать их здесь. Я лишь хочу показать вам, как может осуществляться доступ к сессионному EJB-компоненту без сохранения состояния в различных формах благодаря простой реализации разных аннотированных интерфейсов. В листинге 7.4 приведен EJB-компонент без сохранения состояния с локальным интерфейсом, а также конечные точки веб-служб SOAP (@WebService) и RESTful (@Path). Следует отметить, что эти аннотации происходят из JAX-WS (см. главу 14) и JAX-RS (см. главу 15) соответственно и не являются частью EJB.
@Local
public interface ItemLocal {
··List
··List
}
@WebService
public interface ItemSOAP {
··List
··List
··Book createBook(Book book);
··CD createCD(CD cd);
}
@Path(/items)
public interface ItemRest {
····List
}
@Stateless
public class ItemEJB implements ItemLocal, ItemSOAP, ItemRest {
··//…
}
Переносимое JNDI-имя
JNDI существует уже долгое время. Соответствующий API-интерфейс определяется для серверов приложений и является переносимым между ними. Однако этого нельзя было сказать о JNDI-имени, которое зависело от реализации. При развертывании EJB-компонента в GlassFish или JBoss его имя в службе каталогов оказывалось другим и, таким образом, было непереносимым. Клиенту пришлось бы искать EJB-компонент, используя одно имя для GlassFish и другое имя — для JBoss. Начиная с EJB 3.1, JNDI-имена уже были определены, благодаря чему код мог быть переносимым. Таким образом, теперь каждый раз при развертывании сессионного EJB-компонента с его интерфейсами в контейнере каждый EJB-компонент/интерфейс автоматически привязывается к переносимому JNDI-имени. Спецификация Java EE определяет переносимые JNDI-имена с использованием следующего синтаксиса:
java:<область видимости>[/<имя приложения>]/<имя модуля>/<имя EJB-компонента>[!<полностью уточненное имя интерфейса>]
У каждого фрагмента JNDI-имени есть следующее значение:
• <область видимости> — определяет последовательность пространств имен, которые отображаются в разные области видимости приложения Java EE;
• global — префикс java: global позволяет компоненту, выполняющемуся вне приложения Java EE, получить доступ к глобальному пространству имен;
• app — префикс java: app позволяет компоненту, выполняющемуся в рамках приложения Java EE, получить доступ к пространству имен, специфичному для приложения;
• module — префикс java: module позволяет компоненту, выполняющемуся в рамках приложения Java EE, получить доступ к пространству имен, специфичному для модуля;
• comp — префикс java: comp — это закрытое пространство имен, специфичное для компонента и недоступное для других компонентов;
• <имя приложения> — требуется, только если сессионный EJB-компонент упакован в файл с расширением EAR или WAR. Если дело обстоит именно так, то в <имя приложения> автоматически будет указано имя файла EAR или WAR (без указания расширения);
• <имя модуля> — это имя модуля, в который упакован сессионный EJB-компонент. Это может быть EJB-модуль в отдельном файле с расширением JAR или веб-модуль в файле с расширением WAR. В <имя модуля> по умолчанию указывается базовое имя архива без расширения файла;
• <имя EJB-компонента> — имя сессионного EJB-компонента;
• <полностью уточненное имя интерфейса> — это полностью уточненное имя каждого определенного бизнес-интерфейса. В случае с представлением без интерфейса именем может быть полностью уточненное имя класса EJB-компонента.
Чтобы проиллюстрировать это соглашение об именовании, обратимся к примеру ItemEJB (определенному в листинге 7.5), который располагает удаленным интерфейсом, локальным интерфейсом и представлением без интерфейса (с помощью аннотации @LocalBean). Все эти классы и интерфейсы относятся к пакету org.agoncal.book.javaee7. ItemEJB — это <имя EJB-компонента>, а соответствующий EJB-компонент упакован в cdbookstore.jar (<имя модуля>).
package org.agoncal.book.javaee7;
@Stateless
@Remote(ItemRemote.class)