Доступ к Enterprise-бинам

Примечание:

Материал в этом разделе применим только к сессионным компонентам, но не к компонентам, управляемым сообщениями. Поскольку компоненты, управляемые сообщениями, используют другую программную модель, они не имеют интерфейсов или представлений без интерфейса, которые допускали бы доступ клиента.

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

Клиент может получить доступ к сессионному компоненту только через методы, определённые в бизнес-интерфейсе компонента, или через общедоступные методы Enterprise-бина, который не имеет представления интерфейса. Бизнес-интерфейс или представление без интерфейса определяет представление клиента Enterprise-бина. Все остальные аспекты Enterprise-бина (реализации методов и параметры развёртывания) скрыты от клиента.

Хорошо продуманные интерфейсы и представления без интерфейса упрощают разработку и обслуживание приложений Java EE. Интерфейсы и представления без интерфейса не только защищают клиентов от сложностей слоя EJB, но также позволяют вносить изменения в Enterprise-бины, не затрагивая клиентов. Например, если вы измените реализацию бизнес-метода сессионного компонента, вам не придётся изменять клиентский код. Но если бы вы изменили сигнатуры методов в интерфейсах, вам, возможно, придётся внести изменения и в клиентский код. Поэтому важно тщательно проектировать интерфейсы и представления без интерфейса, чтобы изолировать клиентов от возможных изменений в Enterprise-бинах.

Сессионные компоненты могут иметь более одного бизнес-интерфейса. Сессионные компоненты могут (но не обязаны) реализовать свой бизнес-интерфейс или интерфейсы.

Использование Enterprise-бинов в клиентах

Клиент Enterprise-бина получает ссылку на объект Enterprise-бина посредством инъецирования зависимости с аннотацией Java или поиска JNDI с использованием синтаксиса Java Naming and Directory Interface для поиска Enterprise-бина.

Инъецирование зависимостей — это самый простой способ получения ссылки на Enterprise-бин. Клиенты, которые работают в среде, управляемой сервером Java EE, веб-приложениями JavaServer Faces, веб-сервисами JAX-RS, другими Enterprise-бинами или клиентскими приложениями Java EE, поддерживают инъецирование зависимостей с помощью аннотации javax.ejb.EJB.

Приложения, работающие вне среды, управляемой сервером Java EE, такие как приложения Java SE, должны выполнять явный поиск. JNDI поддерживает глобальный синтаксис для идентификации компонентов Java EE, чтобы упростить этот явный поиск.

Переносимый синтаксис JNDI

Переносимый поиск JNDI использует три пространства имён JNDI: java:global, java:module и java:app.

Пространство имён JNDI java:global — это переносимый способ поиска удалённых Enterprise-бинов с помощью механизма JNDI. Адреса JNDI имеют следующую форму:
```
java:global[/application name]/module name/enterprise bean name[/interface name]
```
Имя приложения и имя модуля по умолчанию соответствуют именам приложения и модуля без расширения файла. Имена приложений требуются, только если приложение упаковано в EAR. Имя интерфейса требуется только в том случае, если Enterprise-бин реализует более одного бизнес-интерфейса.
Пространство имён java:module используется для поиска локальных Enterprise-бинов внутри одного и того же модуля. Адреса JNDI, использующие пространство имён java:module, имеют следующую форму:
```
java:module/enterprise bean name/[interface name]
```
Имя интерфейса требуется только в том случае, если Enterprise-бин реализует более одного бизнес-интерфейса.
Пространство имён java:app используется для поиска локальных Enterprise-бинов, упакованных в одном приложении. То есть Enterprise-бин упакован в файл EAR, содержащий несколько модулей Java EE. Адреса JNDI, использующие пространство имён java:app, имеют следующую форму:
```
java:app[/module name]/enterprise bean name[/interface name]
```
Имя модуля необязательно. Имя интерфейса требуется только в том случае, если Enterprise-бин реализует более одного бизнес-интерфейса.

Например, если Enterprise-бин MyBean упакован в архив веб-приложения myApp.war, имя модуля будет myApp. Имя переносимого JNDI: java:module/MyBean. Эквивалентное имя JNDI, использующее пространство имён java:global: java:global/myApp/MyBean.

Выбор удалённого или локального доступа

При разработке приложения Java EE одним из первых решений, которое вы принимаете, является тип клиентского доступа, разрешённого Enterprise-бинами: удалённый, локальный или веб-сервис.

Разрешить ли локальный или удалённый доступ зависит от следующих факторов.

Сильная или слабая связность бинов: сильносвязные бины зависят друг от друга. Например, если сессионный компонент, обрабатывающий заказы на продажу, вызывает сессионный компонент, который отправляет клиенту сообщение с подтверждением, эти компоненты сильно связаны. Сильносвязные бины — хорошие кандидаты для локального доступа. Поскольку они подходят друг к другу как логическая единица, они, как правило, часто вызывают друг друга и выигрывают от повышения производительности, которое возможно при локальном доступе.
Тип клиента: если к Enterprise-бину обращаются клиентские приложения, он должен разрешить удалённый доступ. В производственной среде эти клиенты почти всегда работают на компьютерах, отличных от GlassFish Server. Если клиентами Enterprise-бина являются веб-компоненты или другие Enterprise-бины, тип доступа зависит от того, как вы хотите распространять свои компоненты.
Распределение компонентов: приложения Java EE являются масштабируемыми, поскольку их серверные компоненты могут быть распределены по нескольким компьютерам. Например, в распределённом приложении сервер, на котором работают веб-компоненты, может быть не тем, на котором развёрнуты Enterprise-бины, к которым они получают доступ. В этом распределённом сценарии Enterprise-бины должны разрешать удалённый доступ.
Производительность: из-за таких факторов, как задержка в сети, удалённые вызовы могут быть медленнее, чем локальные. С другой стороны, при распределении компонентов между различными серверами можно повысить общую производительность приложения. Оба эти утверждения являются обобщениями. Производительность может варьироваться в разных операционных средах. Тем не менее, нужно помнить, как дизайн приложения может повлиять на производительность.

Если нет уверенности, какой тип доступа должен иметь Enterprise-бин, выбирайте удалённый доступ. Это решение даёт больше гибкости. Остаётся возможность на будущее распространять компоненты в соответствии с растущими требованиями к приложению.

Хотя это редко встречается, Enterprise-бин может разрешить как удалённый, так и локальный доступ. В этом случае либо бизнес-интерфейс компонента должен быть помечен аннотациями @Remote или @Local, либо класс компонента должен явно обозначать бизнес-интерфейсы с помощью аннотаций @Remote и @Local. Один и тот же бизнес-интерфейс не может быть как локальным, так и удалённым бизнес-интерфейсом.

Локальные клиенты

Локальный клиент имеет следующие характеристики.

Он должен работать в том же приложении, что и Enterprise-бин, к которому он обращается.
Это может быть веб-компонент или другой Enterprise-бин.
Для локального клиента местоположение Enterprise-бина, к которому он обращается, не является прозрачным.

Представление Enterprise-бина без интерфейса является локальным представлением. Публичные методы класса реализации Enterprise-бина доступны локальным клиентам, которые обращаются к представлению Enterprise-бина без интерфейса. Enterprise-бины, которые используют представление без интерфейса, не реализуют бизнес-интерфейс.

Локальный бизнес-интерфейс определяет бизнес-методы и методы жизненного цикла компонента. Если бизнес-интерфейс бина не аннотирован @Local или @Remote, и если класс бина не указывает интерфейс аннотациями @Local или @Remote, бизнес-интерфейс по умолчанию является локальным интерфейсом.

Чтобы создать Enterprise-бин, разрешающий только локальный доступ, вы можете, но не обязаны, выполнить одно из следующих действий.

Создайте класс реализации Enterprise-бина, который не реализует бизнес-интерфейс, указывая, что компонент предоставляет представление без интерфейса клиентам. Например:
```
@Session
public class MyBean { ... }
```
Аннотируйте бизнес-интерфейс Enterprise-бина как интерфейс @Local. Например:
```
@Local
public interface InterfaceName { ... }
```
Укажите интерфейс класса компонента в аннотации @Local и укажите имя интерфейса. Например:
```
@Local(InterfaceName.class)
public class BeanName implements InterfaceName  { ... }
```

Доступ к локальным Enterprise-бинам с использованием представления без интерфейса

Клиентский доступ к Enterprise-бину, который предоставляет локальное представление без интерфейса, осуществляется посредством инъецирования зависимостей или поиска JNDI.

Чтобы получить ссылку на представление без интерфейса Enterprise-бина через инъецирование зависимостей, используйте аннотацию javax.ejb.EJB и укажите класс реализации Enterprise-бина:
```
@EJB
ExampleBean exampleBean;
```
Чтобы получить ссылку на представление без интерфейса для Enterprise-бина через поиск JNDI, используйте метод lookup интерфейса javax.naming.InitialContext:
```
ExampleBean exampleBean = (ExampleBean)
        InitialContext.lookup("java:module/ExampleBean");
```

Клиенты не используют оператор new для получения нового объекта Enterprise-бина, который использует представление без интерфейса.

Доступ к локальным Enterprise-бинам, реализующим бизнес-интерфейсы

Клиентский доступ к Enterprise-бинам, которые реализуют локальные бизнес-интерфейсы, осуществляется посредством инъецирования зависимостей или поиска JNDI.

Чтобы получить ссылку на локальный бизнес-интерфейс Enterprise-бина через инъецирование зависимостей, используйте аннотацию javax.ejb.EJB и укажите имя локального бизнес-интерфейса Enterprise-бина:
```
@EJB
Example example;
```
Чтобы получить ссылку на локальный бизнес-интерфейс Enterprise-бина с помощью поиска JNDI, используйте метод lookup интерфейса javax.naming.InitialContext:
```
ExampleLocal example = (ExampleLocal)
         InitialContext.lookup("java:module/ExampleLocal");
```

Удалённые клиенты

Удалённый клиент Enterprise-бина имеет следующие особенности.

Он может работать на другой машине и на другой JVM, чем Enterprise-бин, к которому он обращается. (Не обязательно работать на другой JVM.)
Это может быть веб-компонент, клиентское приложение или другой Enterprise-бин.
Для удалённого клиента местоположение Enterprise-бина прозрачно.
Enterprise-бин должен реализовывать бизнес-интерфейс. То есть удалённые клиенты не могут получить доступ к Enterprise-бину через представление без интерфейса.

Чтобы создать Enterprise-бин, который разрешает удалённый доступ, вы должны сделать одно из двух:

Аннотировать бизнес-интерфейс Enterprise-бина аннотацией @Remote:
```
@Remote
public interface InterfaceName { ... }
```
Аннотировать класс компонента аннотацией @Remote, указав бизнес-интерфейс или интерфейсы:
```
@Remote(InterfaceName.class)
public class BeanName implements InterfaceName { ... }
```

Удалённый интерфейс определяет бизнес- методы и методы жизненного цикла, специфичные для компонента. Например, удалённый интерфейс компонента BankAccountBean может иметь бизнес-методы deposit и credit. На рисунке 35-1 показано, как интерфейс управляет клиентским представлением Enterprise-бина.

Рис. 35-1. Интерфейсы для Enterprise-бина с удалённым доступом

Диаграмма, показывающая удалённый клиент, обращающийся к методам Enterprise-бина через его удалённый интерфейс.

Клиентский доступ к Enterprise-бину, который реализует удалённый бизнес-интерфейс, осуществляется посредством инъецирования зависимостей или поиска JNDI.

Чтобы получить ссылку на удалённый бизнес-интерфейс Enterprise-бина через инъецирование зависимостей, используйте аннотацию javax.ejb.EJB и укажите имя удалённого бизнес-интерфейса Enterprise-бина:
```
@EJB
Example example;
```
Чтобы получить ссылку на удалённый бизнес-интерфейс Enterprise-бина через поиск JNDI, используйте метод lookup интерфейса javax.naming.InitialContext:
```
ExampleRemote example = (ExampleRemote)
        InitialContext.lookup("java:global/myApp/ExampleRemote");
```

Клиенты веб-сервисов

Клиент веб-сервиса может получить доступ к приложению Java EE двумя способами. Во-первых, клиент может получить доступ к веб-сервису, созданному с помощью JAX-WS. (Для получения дополнительной информации о JAX-WS см. главу 31 «Создание веб-сервисов с помощью JAX-WS».) Во-вторых, клиент веб-сервиса может вызывать бизнес-методы сессионного компонента без сохранения состояния. Бины сообщения не могут быть доступны клиентам веб-сервиса.

При условии, что он использует корректные протоколы (SOAP, HTTP, WSDL), любой клиент веб-сервиса может получить доступ к сессионному компоненту без сохранения состояния независимо от того, написан ли этот клиент на Java. Клиент даже не «знает», какая технология реализует сервис: сессионный компонент без сохранения состояния, JAX-WS или какая-либо другая технология. Кроме того, Enterprise-бины и веб-компоненты могут быть клиентами веб-сервисов. Эта гибкость позволяет вам интегрировать приложения Java EE с веб-сервисами.

Клиент веб-сервиса обращается к сессионному компоненту без сохранения состояния через класс реализации конечной точки веб-сервиса. По умолчанию все публичные методы в классе бина доступны для клиентов веб-сервисов. Аннотация @WebMethod может использоваться для настройки поведения методов веб-сервиса. Если для аннотирования методов класса компонента используется аннотация @WebMethod, клиентам веб-сервиса доступны только те методы, которые аннотированы @WebMethod.

Пример кода см. в разделе Пример веб-сервиса: helloservice.

Параметры метода и доступ

Тип доступа влияет на параметры методов бина, которые вызываются клиентами. Следующие разделы относятся не только к параметрам метода, но и к возвращаемым значениям.

Изоляция

Параметры удалённых вызовов более изолированы, чем параметры локальных вызовов. При удалённых вызовах клиент и компонент работают с разными копиями объекта параметра. Если клиент изменяет значение объекта, значение копии в компоненте не изменяется. Этот уровень изоляции может помочь защитить компонент, если клиент случайно изменил данные.

При локальном вызове и клиент, и компонент могут изменять один и тот же объект параметра. Вообще говоря, вы не должны полагаться на этот побочный эффект локальных вызовов. Возможно, когда-нибудь вы захотите распределить свои компоненты, заменив локальные вызовы удалёнными.

Как и в случае с удалёнными клиентами, клиенты веб-сервисов работают с копиями параметров, отличными от компонентов, реализующих веб-сервис.

Детальность доступа к данным

Поскольку удалённые вызовы, скорее всего, будут медленнее, чем локальные, параметры в удалённых методах должны быть относительно крупными. Крупный объект содержит больше данных, чем мелкий, поэтому требуется меньше вызовов для доступа. По той же причине параметры методов, вызываемых клиентами веб-сервисов, также должны быть крупными.