Вы знаете, что EJB - это управляемые компоненты, и теперь пришло время более пристально взглянуть на то, как контейнер управляет вашими EJB объектами. Это позволит нам лучше понимать службы, которые предоставляет Контейнер, примеры кода и процесс разработки.
Основная идея достаточно проста. Когда бы клиентское приложение ни запросило ссылку на EJB объект, Контейнер реально возвращает ссылку на сгенерированный Контейнером прокси, который принимает все клиентские запросы, выполняет некоторые вспомогательные действия и, в конечном итоге, делегирует их объекту, реализованному BeanProvider'ом. Мы вызываем формирователь EJB Объекта, а затем EJB Экземпляра. Пожалуйста, не путайте их: EJB Объект генерируется Контейнером, в то время как EJB экземпляр реализуется Bean Provider'ом.
Вы также должны заметить, что наличие и роли EJB Объекта являются стандартом EJB спецификации. Также обратите внимание на то, что стратегия реализации и способ взаимодействия с экземпляром EJB специфичны для контейнера.
И наконец, сгенерированный контейнером прокси (EJB Объект) не нужно путать с RMI прокси, который также представлен. Приведенная ниже диаграмма разъясняет эту архитектуру.
Диаграмма показывает архитектурное позиционирование EJB объекта относительно других главных составных частей. На диаграмме я показал случай удаленного клиентского приложения, но вы должны держать в уме, что всегда существует перехватывающий EJB объект, даже когда вызов метода приходит из кода в этом же контейнере (например, другого EJB).
RMI прокси и заглушка (stub), с одной стороны, присутствуют только когда клиент обращается к удаленному представлению EJB компонента. Пожалуйста, обратите внимание, что RMI прокси и заглушка автоматически герерируются Контейнером, хотя различные Контейнеры выполняют это действие, применяя разные стратегии.
Пунктирная стрелка представляет зависимости, и она означает, что если, например, реализация Экземпляра EJB изменится, EJB Объект также должен быть изменен, поскольку он полагается на специфическую реализацию метода для этого Экземпляра EJB.
Тот факт, что Экземпляр EJB никогда не доступен напрямую, является основным механизмом, которым Контейнер управляет экземплярами вашего компонента. На языке EJB мы говорим, что Контейнер вставляет код между клиентом (если он присутствует) и EJB Экземпляром, а мы вызываем EJB Объект - артефакт Контейнера. Вставленный Контейнером код представляет EJB экземпляр с промежуточными службами, такими как объединение экземпляров, управление распараллеливанием, управления транзакциями и постоянством объектов.
Таким образом, с ваших плеч снимается огромная ноша - представьте себе сколько кода вам было бы необходимо написать для реализации некоторых или всех этих служб самостоятельно. Но так как у вас есть EJB Контейнер, вы можете просто сказать ему, что ему нужно делать для вашей пользы - например, запустить новую транзакцию, когда вызывается определенный метод.
В EJB мы называем декларативное управление транзакциями и логику безопасности метапрограммированием. Идея состоит в том, что вы, фактически, программируете свой компонент или приложение, но часть поведения вы не кодируете самостоятельно - вы просто сообщаете Контейнеру что нужно делать.
Теперь вы знаете весь архитектурный фон, который вам нужен для начала рассмотрения того, как мы реализуем и используем Enterprise JavaBean. Я дам вам более подробную информацию об EJB Объектах и внутренних способах работы Контейнера тогда, когда мы будем рассматривать примеры кода.
| ← | Основное API EJB | Программное обеспечение | → |