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

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

• @Remote — обозначает удаленный бизнес-интерфейс. Параметры методов передаются по значению и нуждаются в том, чтобы быть сериализуемыми как часть протокола RMI;

Рис. 7.3. Сессионные EJB-компоненты, вызываемые клиентами нескольких типов

• @Local — обозначает локальный бизнес-интерфейс. Параметры методов передаются по ссылке от клиента к EJB-компоненту.

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

В листинге 7.2 показаны локальный (ItemLocal) и удаленный интерфейс (ItemRemote), реализуемые сессионным EJB-компонентом без сохранения состояния ItemEJB. Благодаря этому коду клиенты смогут вызывать метод findCDs() локально или удаленно, поскольку он определен в обоих интерфейсах. Метод createCd() будет доступен только удаленно с помощью RMI.

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

@Local
public interface ItemLocal {
··List findBooks();
··List findCDs();
}
@Remote
··public interface ItemRemote {
··List findBooks();
··List findCDs();
··Book createBook(Book book);
··CD createCD(CD cd);
}
@Stateless
public class ItemEJB implements ItemLocal, ItemRemote {
··//…
}

В качестве альтернативы коду из листинга 7.2 вы могли бы указать интерфейс в классе EJB-компонента. При этом вам пришлось бы включить имя интерфейса в аннотации @Local и @Remote, как показано в листинге 7.3. Это удобно, когда у вас имеются унаследованные интерфейсы, для которых вы не можете добавить аннотации, поэтому вынуждены использовать их в своем сессионном EJB-компоненте.

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

public interface ItemLocal {
··List findBooks();
··List findCDs();
}
public interface ItemRemote {
··List findBooks();
··List findCDs();
··Book createBook(Book book);
··CD createCD(CD cd);
}
@Stateless
@Remote(ItemRemote.class)
@Local(ItemLocal.class)
@LocalBean
public class ItemEJB implements ItemLocal, ItemRemote {
··//…
}

Если EJB-компонент обеспечивает хотя бы один интерфейс (локальный или удаленный), то он автоматически теряет представление без интерфейса. Тогда потребуется явным образом указать, что он обеспечивает представление без интерфейса, с помощью аннотации @LocalBean в отношении класса EJB-компонента. Как вы можете видеть в листинге 7.3, ItemEJB сейчас обладает локальным и удаленным интерфейсами, а также представлением без интерфейса.

Интерфейсы веб-служб

В дополнение к удаленному вызову посредством 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-имена с использованием следующего синтаксиса: