Ejb java что это

Enterprise JavaBeans

Что такое EJB (Enterprise JavaBeans) и для чего она нужна? Можно ли обойтись без EJB при разработке WEB-приложений? Что даёт EJB программистам?

В java WEB-приложении можно использовать JSP (JavaServer Pages), JavaServer Faces (JSF), Struts, GWT. Для работы с базой данных можно использовать JDBC (Java Database Connectivity) или JPA (JBoss Hibernate). Применение в WEB-приложении servlet’a позволяет перехватить обращение к серверу и выполнить определенные действия, т.е. выполнить фильтрацию сообщений. Где и как в WEB-приложении можно использовать EJB?

Опыт показывает, что типовые задачи имеют типовые решения. Это и обеспечивает EJB, который представляет набор «фиксированных» решений типовых проблем, возникающих при разработке серверных приложений, а также проверенная временем схема реализации серверных компонентов. Эти фиксированные решения, или службы, предоставляются «контейнером EJB». Для доступа к этим службам необходимо создать специализированные компоненты, используя декларативные и программные EJB API, и развернуть их на сервере приложений.

Сервер приложений Java EE (Enterprise Edition) включает два основных компонента : WEB-container (для использования JSP, JSF, Struts и т.д.) и EJB-container. Первый компонент используется для создания пользовательского интерфейса и слабо подходит для описания бизнес-логики WEB-приложения. Для этого используется EJB-container.

Enterprise JavaBeans имеет спецификацию написания и поддержки серверных компонентов, содержащих бизнес-логику. Данная технология применяется, как правило, в том случае, если бизнес-логика требует один или несколько следующих сервисов :

Основные типы компонентов EJB

В языке EJB под компонентом подразумевается зерно (Bean), а под Enterprise подразумевают «корпоративный». EJB делит компоненты (зерна) на несколько типов, исходя из их предназначения :

Сессионный компонент Session Beans, иначе называемый сеансовый, вызывается клиентом (браузером) для выполнения вполне определенных операций, таких как, к примеру, проверка кредитной истории клиента. Слово «сессионный» предполагает, что экземпляр компонента доступен только на время выполнения определенной задачи сервером, и безвозвратно уничтожается в случае аварии или остановки сервера. Для доступа к серверной части приложения, клиент вызывает методы сессионного компонента, выполняющего определенные бизнес-задачи внутри сервера.

Сеансовый компонент с сохранением состояния EJB stateful автоматически сохраняет свое состояние между обращениями к нему от одного и того же клиента, и завершает свое существование либо по таймауту, либо по явному запросу клиента. Типичным примером компонента с сохранением состояния является корзина с покупками в интернет-магазине.

Сеансовые компоненты без сохранения состояния EJB stateless не хранят никакой информации о своем состоянии и являются прикладными службами, которые выполняют все необходимые действия в рамках запроса. EJB stateless можно использовать для реализации таких операций, как перевод средств на кредитную карту или проверку кредитной истории клиента. На основе stateless-бинов проектируются WEB-сервисы.

Компоненты-одиночки EJB singleton используются совместно всеми клиентами, имеющими к ним доступ, и продолжают свое существование на протяжении всего времени работы приложения. Информацию о своем состоянии EJB singleton сохраняет. Компонент-одиночку можно использовать, к примеру, в интернет-магазине для реализации скидки, поскольку правила предоставления скидки фиксированы и распространяются на всех клиентов.

Сеансовые компоненты могут вызываться локально или удаленно, посредством Java RMI. Компоненты-одиночки и компоненты без сохранения состояния могут также экспортироваться в виде веб-служб SOAP (Simple Object Access Protocol) или REST (Representational State Transfer).

Компоненты управляемые сообщениями MDB (Message-Driven Bean) подобно сеансовым компонентам реализуют некоторую прикладную логику и имеют одно важное отличие: клиенты никогда не вызывают методы MDB напрямую. Вместо этого компоненты MDB вызываются для обработки отправленных на сервер сообщений, что позволяет организовать асинхронный обмен сообщениями между частями системы. Типичными примерами подобных серверов сообщений могут служить IBM WebSphere MQ, Oracle Advanced Queueing и TIBCO. Компоненты MDB, как правило, применяются для повышения надежности интеграции систем и асинхронной обработки данных. Примером MDB сообщения может быть запрос на доставку товарных запасов от автоматизированной системы розничной торговли к системе управления поставками.

Entity Bean и Java Persistence API

EJB тесно связан с двумя спецификациями : с JPA, которая является стандартом хранения данных для Java EE и с CDI (Contexts and Dependency Injection) которая обеспечивает возможность внедрения зависимостей и предоставляет службы управления контекстом для всех компонентов Java EE, включая EJB.

Контейнеры EJB-container

Java-приложениям для работы нужна виртуальная машина JVM (Java Virtual Machine). Сеансовым компонентам и компонентам MDB для работы точно также необходим контейнер EJB. Можно считать EJB-container развитием базовой идеи JVM. Так же, как JVM прозрачно управляет памятью, EJB-container обеспечивает компоненты EJB такими службами, как обработка транзакций, поддержка безопасности, удаленные взаимодействия и веб-службы.

Согласно спецификации EJB3 контейнер предоставляет службы, применимые только к сеансовым компонентам и MDB. Операция добавления компонента EJB3 в контейнер называется развертыванием (deployment). После того, как EJB-компонент благополучно развернут в контейнере, он готов к использованию приложениями.

В Java технологиях контейнеры не ограничены только EJB3. Контейнер Java EE – это сервер приложений с поддержкой EJB3, веб-контейнеров (сервлеты, JSP, JSF, Struts, GWT) и других Java EE API и служб. Примерами реализаций контейнеров Java EE могут служить следующие серверы приложений : Oracle WebLogic, GlassFish, IBM WebSphere, JBoss и Caucho Resin.

Определение наименования компонентов EJB

Формат именования компонентов EJB имеет следующий вид :

В представленном формате именования компонентов EJB ряд элементов (workspace, module-name, ejb-name) присутствуют в имени всегда и являются обязательными. А элементы [app-name] и [!object-name] могут отсутствовать и считаются необязательными.

workspace

Сервер Java EE может включать четыре пространства имен workspace, каждое из которых представляет свою область видимости.

app-name

module-name

ejb-name

Значение наименования компонента ejb-name является обязательным и всегда присутствует в наименовании ресурса. Для компонентов EJB, помеченных аннотациями @Stateless, @Stateful или @Singleton, в качестве значения ejb-name по умолчанию выбирается имя класса компонента. Это значение можно переопределить с помощью атрибута name() аннотации. Для компонентов EJB, объявленных в файле ejb-jar.xml, значение ejb-name определяется с помощью элемента bean-name.

object-name

Значение полного наименования объекта [!object-name] является обязательным, и переносимые имена компонентов EJB с этим элементом всегда будут присутствовать в JNDI. Но сервер EE также требует, чтобы в JNDI присутствовало имя без этого значения. Такое «усеченное» наименование может пригодиться, когда доступ к компоненту осуществляется через единственный интерфейс (или если компонент вообще не имеет интерфейса).

Источник

Введение в основы EJB3

Так как я уже затрагивал тему EJB3 в уроках, то решил рассмотреть его более детальней.

Немного о EJB

EJB (Enterprise Java Beans) – это фреймворк для построение бизнес-логики приложения.

Сервер приложений J2EE состоит из двух основных элементов:

WEB-Container – (JSP, JSF и т.д.) все что дает конечный вид пользователю, а точней пользовательский интерфейс.

EJB-Container – используется для написания бизнес-логики.

С точки зрения EJB – это технология, предоставляющая множество готовых решений (управление транзакциями, безопасность, хранение информации и т.п.) для вашего приложения.

EJB делится на три типа компонентов

1. Session beans – используется для построения бизнес-логики, которая может быть вызвана программным клиентом через локальный, удаленный или веб-интерфейс обслуживания клиентов.

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

Существует 2 типа session-beans: stateless и stateful.

Stateful – автоматически сохраняют свое состояние между разными клиентскими вызовами.

Stateless – используются для реализации бизнесс-процессов, которые могут быть завершены за одну операцию.

2. Message-Driven beans – компонент является корпоративным компонентом, который позволяет Java EE приложениям обрабатывать сообщения асинхронно.

Этот тип бинов обычно действует в качестве слушателя JMS-сообщения, который похож на слушателя событий, но получает JMS-сообщений вместо событий. Сообщения могут быть отправлены на любой компонент Java EE (клиентское приложение, другой компонент, или веб-компонент) или JMS приложение или систему, которая не использует Java EE технологий.

Message-Driven beans может обрабатывать не только JMS сообщения но и других видов сообщений.

На схеме выше можно наблюдать общение между приложением и сервером с помощью очереди куда поступают сообщения.

3. Entities – это сущности каких то объектов и в EJB оно является хранилищем данных на период жизненного цикла Entity.

Entities является свое-родным отображением таблиц в БД.

Одним из главным достоинством EJB3 стал новый механизм работы с persistence, он дает возможность автоматически сохранять объекты в реляционной БД используя технологию ORM.

Для работы с entity был создан JPA (Java Persistence API).

JPA определяет стандарт для:

1) конфигурации маппинга сущностей приложения и их отображения в таблицах БД;

2) EntityManager API – позволяет выполнять CRUD (create, read, update, delete) операции над сущностями;

3) Java Persistence Query Language (JPQL) – для поиска и получения данных приложения;

Основные аннотации EJB3

@EJB – помечается bean, который мы собираемся использовать.

@Stateless – говорит контейнеру, что класс будет stateless session bean. Для него контейнер обеспечит безопасность потоков и менеджмент транзакций.

@Local – относится к интерфейсу и говорит, что bean реализующий интерфейс доступен локально.

@Remote – относится к интерфейсу и говорит, что bean доступен через RMI (Remote Method Invocation).

@Stateful – говорит контейнеру, что класс будет stateful session bean.

@Remove – метод, помеченный как Remove говорит контейнеру, что после его исполнения нет больше смысла хранить bean, т.е. его состояние сбрасывается. Это бывает критично для производительности.

@Entity – говорит контейнеру, что класс будет сущностью БД.

@Table(name=” ”) – указывает таблицу для маппинга БД.

@Id – указывает уникальный идентификатор сущности который будет ключом в БД.

@Column – указывает параметры колонки в БД включая имя колонки в БД.

@WebService – говорит, что интерфейс или класс будет представлять web-сервис.

Правила создания session bean

В качестве session bean может выступать обычный класс Java, но он должен удовлетворять следующим условиям:

1. Он должен иметь как минимум один метод;

2. Он не должен быть абстрактным;

3. Он должен иметь конструктор по-умолчанию;

4. Методы не должны начинаться с “ejb” (например ejbBean, ejbGoAtHome)

5. Свойства класса должны быть объявлены примитивами или реализовывать интерфейс Serializable.

Жизненный цикл EJB3

У stateless и MDB бинов существует 2 события жизненного цикла, которые мы можем перехватить. Это создание и удаление бина.

Метод, который будет вызываться сразу после создании бина помечается аннотацией @PostConstruct, а перед его удалением – @PreDestroy.

Stateful бины обладают помимо рассмотреных выше еще 2 событиями:

1) При активации @PostActivate;

2) При деактивации @PrePassivate.

Источник

Ejb java что это

Это серверные компоненты, работающие под управлением контейнера в распределенной среде и предназначенные для реализации бизнес-логики в корпаративных распределенных приложениях на языке java.

Все технологии, рассмотренные до этого не позволяли распределять бизнес-логику (кроме вебсервисов). EJB предназначено для Java и делает распределение бизнес-логики легче.

EJB предоставляет фреймворк, упрощающий разработку распределенных приложений.

Спецификация EJB определяет три типа распределенных компонентов

Содержание

sessions beans

sessions beans могут быть 3 видов:

stateless

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

Важно, еще раз, все компоненты stateless должны быть идентичны и обращение клиента может быть направлено к любому из этих компонент.

Вообще, контейнер управляет всеми видами компонентов EJB.

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

Stateless компоненты требуют меньше ресурсов и позволяют более гибко управлять нагрузкой. Поэтому, когда возможно, лучше использовать именно их. Но есть и другая сторона: если компонент не хранит данные в себе, значит их хранит клиент и код клиента усложняется.

Компоненты stateless не должны реализовывать javax.ejb.SessionSynchronization. Также на основе stateless компоненты можно реализовать веб-сервис.

stateful

Перевод из рабочего процесса называют passication (instance passivation), а обратный перевод называется активацией (activation).

Чтобы дать компоненту освободить ресурсы, перед переводом в пассивное состояние, контейнер вызывает метод, помеченный аннотацией @PrePassivate и реализовать этот функционал должен программист.

При переводе из пассивного состояния в активное, конейтенр вызовет метод @PostActivate, который должен восстановить компонент.

На перевод компонентов в пассивное состояние накладываются ограничения, например:

В этих случаях контейнер просто не может перевести в пассивное состояние. Сеансовые компоненты без сохранения состояния не переводятся, а просто уничтожаются.

singleton

Компонент Singleton создается в единственном экземпляре на каждой виртуальной машине. Компонент живет на протяжении всей жизни контейнера. Он, по аналогии с компонентом без сохранения состояния в своих полях может иметь некоторую информацию, но, в отличии от компонента сущности, при завершении работы контейнера, эта информация нигде не сохраняется.

Экземпляр singleton разделяется между всеми клиентами, в отличии от двух предыдущих типов сеансовых компонентов.

Компоненты управляемыми сообщениями были введенеы в спецификацию EJB2. Они позволяют получать и обрабатывать jms-сообщения (Java Messaging Services). JMS, в отличие от сокетов, обеспечивает надежную передачу сообщения. Например, если клиент, для которого предназначено сообщение, не работает, то сообщение будет сохранено на сервере и будет передано клиенту когда он заработает. JMS поддерживает два типа сообщений:

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

Также компоненты могут поддерживать транзакцию и не предоставляют напрямую работу с БД (работа с БД осуществляется с помощью entity-компонент).

Контейнер может поддерживать пул MDB-компонентов.

Любой MJB-компонент может быть удаленным или локальным. Удаленный расположен за пределами текущего EJB-контейнера (на другой машине). Локальный расположен в том-же контейнере, где и обращающийся к нему компонент. Такое разделение сделано, чтобы можно было экономить ресурсы при обращении к локальным компонентам.

Для того, чтобы объявить удаленный компонент, можно поступить 2 способами.

Способ 1: объявить Java-интерфейс и пометить его аннотацией @Remote из javax.ejb.Remote

Класс, реализующий этот интерфейс будет удаленным компонентом.

Способ 2: пометить сам класс аннотацией @Remote и в качестве параметра передать название интерфейса

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

Объявление локального интерфейса осуществляется аналогично, только используется аннотация @Local, а не @Remote.

Надо иметь в виду, что хотя компонент будет локальным, обращение к его методом все равно будет осуществляться через контейнер. Его локальность позволят только избежать передачи данных по сети.

Один и тот же компонент может быть и удаленным и локальным, для этого надо будет реализовывать два интерфейса, т.к. один и тот же интерфейс не может быть и удаленным и локальным. (как правило так не делают).

В принципе, ejb-компонент без сохранения состояния может являться веб-сервисом, и обращаться к нему можно как к обычному веб-сервису, но для этого он должен быть помечен javax.jws.WebService.

Сеансовые компоненты могут быть трех разным типов и помечаются аннотациями из javax.ejb.Stateless javax.ejb.Statefull, javax.ejb.Singleton

В случае с компонентами управляемыми сообщениями, новый интерфейс реализовывать не обязательно. Сам класс должен быть помечен аннотацией javax.ejb.MessageDriven, но он должен реализовать существующий интерфейс javax.jms.MessageListener (это интерфейс должен реализовывать события, чаще всего это onMessage).

Требования, предъявляемые к компонентам

Класс, описывающий сеансовый компонент:

При этом надо иметь в виду, что поддержка аннотаций появилась только с EJB 3 версии. В более ранних версиях требовалось, чтобы компонент наследовался от EJBObject или EJBLocalObject.

Клиенты

Клиенты, работающие с EJB-компонентами, никогда не работают с этими компонентами напрямую. Они работают с заглушкой. Заглушка уже преобразует обращения в соответствии с протоколом передачи распределенных объектов по сети, там запросы демаршализируются и контейнером производится обращение к нужным EJB-компонентам.

Клиент не знает конкретную реализацию EJB компонента и можно даже поменять тип компонента с stateless на stateful без изменения кода переменных.

Как клиенты могут работать с объектами? (в качестве клиента могут быть и сервлеты, и jsp-страницы и javaSE и другой EJB-компонент).

В случае с stateless компонентом: он может быть представлен как веб-сервис и, тогда, работа с ним будет аналогично вебсервисам:

Со всеми остальными типами компонентов используется два способа для работы клиентов с этими компонентами (нужно получить ссылку на компонент).

Впрыскивание ресурсов (DI):

При этом можно передавать имя компонента, но, если имя не передано, то конейнет выполнит поиск EJB-компонента соответствующему типа, перед которым стоит аннтация (у нас Cart) и ссылка будет присвоена переменной.

После того, как получена ссылка, с ней можно обращаться как с POJO-объектом.

Возможно еще получать ссылку не на интерфейс EJB-объекта, а на класс EJB-объекта. (В предыдущем примере Cart определяло интерфейс, который реализован пусть будет CartBean).

Это можно сделать так:

Это называют безинтерфейсным представлением объекта.

К бизнес-методам есть тоже ограничения

Получение ссылки на EJB-объекты

Не рекомендуется в одном архиве компоновать и клиентскую часть и разворачивание ее на сервере. Т.е не должно быть клиентской части и класса main от JavaSE.

В случае использования JNDI тоже не все так просто. Если приложение работает в конейнере, то никаких проблем.

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

Об именовании EJB-объектов:

К каджому EJB-объекту можно получить ссылку по нескольким именам. (через интерфейс и через название класса, реализующего интерфейс). Но есть еще способы:

1) Через глобальный контекст

поиск при этом проводится в контексте текущего приложения

Источник

Ejb java что это

Отличие от JavaBeans

Цели, лежащие в основе технологии EJB

Основы технологии EJB

Для того чтобы понять, как работает и как устроена EJB-система, сначала необходимо рассмотреть ее основные части: EJB-компоненту (component), EJB-контейнер (container) и EJB-объект (object).

EJB-компонента (The Enterprise JavaBeans component)

Отдельная EJB-компонента представляет цобой компоненту в том же смысле что и традиоционный JavaBeans «bean» («зерно»). Компоненты EJB выполняются внутри EJB-контейнера, который, в свою очередь, выполняется внутри EJB-сервера. Любой сервер, который в состоянии поддерживать EJB-контейнеры и предоставлять им необходимые сервисы, может быть EJB-сервером (то есть многие из существующих серверов могут быть просто расширены до поддержки Enterprise JavaBeans).

EJB-компонента представляет из себя Java-класс, который реализует некоторую бизнес-логику. Все остальные классы в EJB-системе либо реализуют поддержку клиент/сервер взаимодйествий между компонентами, либо реализуют некоторые сервисы для компонент.

EJB-контейнер (The Enterprise JavaBeans container)

EJB-объект (EJB-object) и удаленный интерфейс (remote interface)

Клиентские приложения вызывают методы на удаленных EJB-компонентах через EJB-объект (EJB-object). EJB-объект реализует «удаленный интерфейс» EJB-компоненты на сервере. Суть в том, что находящаяся на сервере EJB-компонента, помимо бизнес-функций, ради которых она была разработана, должна реализовывать также некоторые функции, определяемые спецификацией, которые служат для «управления» EJB-компонентой со стороны контейнера. EJB-объект реализует лишь бизнес-интерфейс для EJB-компоненты, являясь, в некотором смысле, «промежуточным» звеном между клиентом и EJB-компонентой.

EJB-объекты и EJB-компоненты представляют собой разные классы, хотя «снаружи» (при взгляде на их интерфейсы), они выглядят одинаково. Это происходит потому, что они реализуют один и тот же интерфейс (а именно, интерфейс, описанный для EJB-компоненты). Однако при этом они выполняют совершенно разные функции. EJB-компонента выполняется на сервере, внутри EJB-контейнера и реализует бизнес-логику, в то время как EJB-объект выполняется у клиента и удаленно вызывает методы у EJB-компоненты.

В качестве поясняющего примера рассмотрим видеомагнитофон. Предположим, что он является EJB-компонентой. EJB-объект, в таком случае, является аналогом пульта управления (remote control) этого магнитофона. У пульта управления есть все те же кнопки, что и на передней панели видеомагнитофона. Нажатие кнопки на пульте управления приведет к такому же эффекту, что и нажатие кнопки, расположенной на самом магнитофоне, но в результате только магнитофон, а не пульт управления, начнет выполнять функции.

Как работает система

Разработчику, однако, не нужно самому реализовывать EJB-объект. Этот класс создается специальным кодогенератором, поставляемым вместе в EJB-контейнером. Как уже было сказано, EJB-объект (созданный с помощью сервисов контейнера) и EJB-компонента (созданная разработчиком), реализуют один и тот же интерфейс. В результате, когда приложение-клиент хочет вызвать метод у EJB-компоненты, то сначала вызывается аналогичный (по имени) метод у EJB-объекта, что находится на стороне клиента, а тот, в свою очередь, связывается с удаленной EJB-компонентой и вызывает у нее этот метод (с теми же аргументами).

Session и Entity beans

Существует два различных типа «бинов»: session и entity. Рассмотрим их более подробно.

Session bean представляет собой EJB-компоненту, связанную с одним клиентом. «Бины» этого типа, как правило, имеют ограниченный срок жизни (хотя это и не обязательно), и редко участвуют в транзакциях. В частности, они обычно не восстанавливаются после сбоя сервера. В качестве примера session bean можно взять «бин», который живет в веб-сервере и динамически создает HTML-страницы клиенту, при этом следя за тем, какая именно страница загружена у клиента. Когда же пользователь покидает вэб-узел, или по истечении некоторого времени, session bean уничтожается. Несмотря на то, что в процессе своей работы, session bean мог сохранять некоторую информацию в базе данных, его предназачение заключается все-таки не в отображении состояния или в работе с «вечными объектами», а просто в выполнении некоторых функций на стороне сервера от имени одного клиента.

Entity bean, наоборот, представляет собой компоненту, работающую с постоянной (persistent) информацией, хранящейся, например, в базе данных. Entity beans ассоциируются с элементами баз данных и могут быть доступны одновременно нескольким пользователям. Так как информация в базе данных является постоянной, то и entity beans живут постоянно, «выживая», тем самым, после сбоев сервера (когда сервер восстанавливается после сбоя, он может восстановить «бин» из базы данных).

Например, entity bean может представлять собой строку какой-нибудь таблицы из базы данных, или даже результат операции SELECT. В объектно-ориентированных базах данных, entity bean может представлять собой отдельный объект, со всеми его атрибутами и связями.

Создание серверных объектов

Итак, приложение-клиент соединяется с EJB-сервером и посылает ему запрос на создание «бина» (Enterprise JavaBean) для обработки своих запросов. Сервер отвечает на такой запрос созданием объекта на стороне сервера (экземпляр EJB-компоненты) и возвращает клиенту прокси-объект (EJB-объект), чей итерфейс совпадает с интерфейсом созданной EJB-компоненты и чьи методы перенаправляют вызовы собственно экземпляру компоненты. После этого приложение-клиент работает с EJB-объектом как с локальным объектом, даже и не подозревая, что всю работу выполняет не EJB-объект, а удаленная компонента на сервере. Необходимо заметить, что созданием и удалением EJB-компонент на сервере занимается EJB-контейнер.

«Родной интерфейс» для EJB-компоненты наследуется от интерфейса javax.ejb.EJBHome, который представляет базовую функциональность для взаимодйествия между контейнером и компонентой. Все методы этого интерфейса должны быть RMI-совместимы. Интерфейс также описывает один или более create() методов, которые все называются ключевым словом create, но тело которых различно. Все create методы возвращают объект с «внешним» (remote) для данной компоненты интерфейсом.

Entity «бины», помимо упоминавшихся, имеют дополнительный интерфейс finder, который используется для поиска по уникальному ключу экземпляра «бина».

И, как уже говорилось, «родной интерфейс» включает в себя методы, сообщающие контейнеру о необходимости удалить экземпляр компонента. В этом случае сервер производит удаление экземпляра, и любая следующая попытка вызвать метод у удаленной компоненты приведет к возникновению исключительной ситуации.

Источник