Читаем Изучаем Java EE 7 полностью

В дополнение к удаленному вызову посредством RMI EJB-компоненты без сохранения состояния также могут вызываться удаленно как веб-службы SOAP или RESTful. Главы 14 и 15 посвящены веб-службам, поэтому я не стану описывать их здесь. Я лишь хочу показать вам, как может осуществляться доступ к сессионному EJB-компоненту без сохранения состояния в различных формах благодаря простой реализации разных аннотированных интерфейсов. В листинге 7.4 приведен EJB-компонент без сохранения состояния с локальным интерфейсом, а также конечные точки веб-служб SOAP (@WebService) и RESTful (@Path). Следует отметить, что эти аннотации происходят из JAX-WS (см. главу 14) и JAX-RS (см. главу 15) соответственно и не являются частью EJB.


Листинг 7.4. EJB-компонент без сохранения состояния, реализующий несколько интерфейсов

@Local

public interface ItemLocal {

··List findBooks();

··List findCDs();

}

@WebService

public interface ItemSOAP {

··List findBooks();

··List findCDs();

··Book createBook(Book book);

··CD createCD(CD cd);

}

@Path(/items)

public interface ItemRest {

····List findBooks();

}

@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 (<имя модуля>).


Листинг 7.5. Сессионный EJB-компонент без сохранения состояния, реализующий несколько интерфейсов

package org.agoncal.book.javaee7;

@Stateless

@Remote(ItemRemote.class)

Перейти на страницу:

Похожие книги

C# 4.0: полное руководство
C# 4.0: полное руководство

В этом полном руководстве по C# 4.0 - языку программирования, разработанному специально для среды .NET, - детально рассмотрены все основные средства языка: типы данных, операторы, управляющие операторы, классы, интерфейсы, методы, делегаты, индексаторы, события, указатели, обобщения, коллекции, основные библиотеки классов, средства многопоточного программирования и директивы препроцессора. Подробно описаны новые возможности C#, в том числе PLINQ, библиотека TPL, динамический тип данных, а также именованные и необязательные аргументы. Это справочное пособие снабжено массой полезных советов авторитетного автора и сотнями примеров программ с комментариями, благодаря которым они становятся понятными любому читателю независимо от уровня его подготовки. Книга рассчитана на широкий круг читателей, интересующихся программированием на C#.Введите сюда краткую аннотацию

Герберт Шилдт

Программирование, программы, базы данных
97 этюдов для архитекторов программных систем
97 этюдов для архитекторов программных систем

Успешная карьера архитектора программного обеспечения требует хорошего владения как технической, так и деловой сторонами вопросов, связанных с проектированием архитектуры. В этой необычной книге ведущие архитекторы ПО со всего света обсуждают важные принципы разработки, выходящие далеко за пределы чисто технических вопросов.?Архитектор ПО выполняет роль посредника между командой разработчиков и бизнес-руководством компании, поэтому чтобы добиться успеха в этой профессии, необходимо не только овладеть различными технологиями, но и обеспечить работу над проектом в соответствии с бизнес-целями. В книге более 50 архитекторов рассказывают о том, что считают самым важным в своей работе, дают советы, как организовать общение с другими участниками проекта, как снизить сложность архитектуры, как оказывать поддержку разработчикам. Они щедро делятся множеством полезных идей и приемов, которые вынесли из своего многолетнего опыта. Авторы надеются, что книга станет источником вдохновения и руководством к действию для многих профессиональных программистов.

Нил Форд , Билл де Ора , Майкл Хайгард

Программирование, программы, базы данных / Базы данных / Программирование / Книги по IT