Jakarta Enterprise Beans - Jakarta Enterprise Beans

Jakarta Enterprise Beans (EJB; ранее Enterprise JavaBeans) является одним из нескольких API Java для модульного строительства корпоративное программное обеспечение. EJB - это на стороне сервера программный компонент который инкапсулирует бизнес-логика приложения. EJB веб-контейнер обеспечивает среда выполнения для веб-компонентов программного обеспечения, включая компьютерная безопасность, Управление жизненным циклом сервлетов Java, обработка транзакции, и другие веб-сервисы. Спецификация EJB - это подмножество Java EE Технические характеристики.^[1]

Технические характеристики

Спецификация EJB была первоначально разработана в 1997 г. IBM и позже принят Sun Microsystems (EJB 1.0 и 1.1) в 1999 г.^[2] и улучшен под Процесс сообщества Java в качестве JSR 19 (EJB 2.0), JSR 153 (EJB 2.1), JSR 220 (EJB 3.0), JSR 318 (EJB 3.1) и JSR 345 (EJB 3.2).

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

Общие обязанности

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

• Обработка транзакции
• Интеграция с упорство услуги, предлагаемые Джакарта Стойкость (JPA)
• Контроль параллелизма
• Событийное программирование с помощью Jakarta Messaging (JMS) и Соединители Джакарта (JCA)
• Вызов асинхронного метода
• Планирование работы
• Именование и справочные службы через Интерфейс именования и каталогов Java (JNDI)
• Межпроцессного взаимодействия с помощью RMI-IIOP и Веб-сервисы
• Безопасность (JCE и JAAS )
• Развертывание из программные компоненты на сервере приложений

Кроме того, спецификация Jakarta Enterprise Beans определяет роли, выполняемые контейнером EJB и EJB, а также способ развертывания EJB в контейнере. Обратите внимание, что спецификация EJB не детализирует, как сервер приложений обеспечивает постоянство (задача, делегированная спецификации JPA), но вместо этого подробно описывает, как бизнес-логика может легко интегрироваться со службами сохранения, предлагаемыми сервером приложений.

История

Компании обнаружили, что использование EJB-компонентов для инкапсуляции бизнес-логики снижает производительность. Это связано с тем, что исходная спецификация разрешала только удаленный вызов метода через CORBA (и, возможно, другие протоколы), хотя подавляющее большинство бизнес-приложений фактически не требует этого распределенных вычислений функциональность. Спецификация EJB 2.0 решила эту проблему, добавив концепцию локальных интерфейсов, которые могут быть вызваны напрямую без потери производительности приложениями, которые не были распределены по нескольким серверам.^[3]

Спецификация EJB 3.0 (JSR 220) был отходом от своих предшественников, следуя новой парадигме облегчения. EJB 3.0 показывает влияние Весна в использовании простых объектов Java и поддержке внедрение зависимости для упрощения настройки и интеграции разнородных систем. Гэвин Кинг, создатель Hibernate, участвовал в процессе EJB 3.0 и является ярым сторонником этой технологии. Многие функции, изначально включенные в Hibernate, были включены в Java Persistence API, замена сущность beans в EJB 3.0. Спецификация EJB 3.0 в значительной степени полагается на использование аннотации (функция, добавленная в язык Java с выпуском 5.0) и соглашение важнее конфигурации чтобы включить гораздо менее подробный стиль кодирования. Соответственно, с практической точки зрения EJB 3.0 намного легче и почти полностью новый API, мало напоминающий предыдущие спецификации EJB.^{[нужна цитата ]}

Пример

Ниже показан базовый пример того, как EJB выглядит в коде:

@Stateless общественный учебный класс Обслуживание клиентов {     частный EntityManager entityManager;      общественный пустота addCustomer(Покупатель покупатель) {     entityManager.сопротивляться(покупатель);   } }

Вышеуказанное определяет класс обслуживания для сохранения объекта Customer (через Отображение O / R ). EJB заботится об управлении контекстом постоянства, а метод addCustomer () по умолчанию является транзакционным и потокобезопасным. Как было показано, EJB фокусируется только на бизнес-логике и устойчивости и ничего не знает о каком-либо конкретном представлении.

Такой EJB может использоваться классом, например, в веб-слой следующим образом:

@Named	@RequestScopedобщественный учебный класс Клиент {   @EJB    частный Обслуживание клиентов обслуживание клиентов;   общественный Нить addCustomer(Покупатель покупатель) {      обслуживание клиентов.addCustomer(покупатель);      контекст.добавить сообщение(...); // для краткости сокращено      возвращаться "customer_overview";   }}

Вышеуказанное определяет JavaServer Faces (JSF) компонент поддержки, в который EJB внедряется с помощью аннотации @EJB. Его метод addCustomer обычно привязан к некоторому компоненту пользовательского интерфейса, например к кнопке. В отличие от EJB, компонент поддержки не содержит никакой бизнес-логики или кода сохранения, но делегирует такие проблемы EJB. Поддерживающий компонент знает о конкретной презентации, о которой EJB ничего не знал.

Типы корпоративных бинов

Контейнер EJB содержит два основных типа bean-компонентов:

• Сессионные бобы^[4] которые могут иметь статус "Stateful", "Stateless" или "Singleton", и к ним можно получить доступ через любой Местный (та же JVM) или Удаленный (другой JVM) интерфейс или напрямую без интерфейса,^[5] в этом случае применяется локальная семантика. Все сессионные компоненты поддерживают асинхронное выполнение^[6] для всех представлений (локальный / удаленный / без интерфейса).
• Компоненты, управляемые сообщениями (MDB, также известные как компоненты сообщений). MDB также поддерживают асинхронное выполнение, но через парадигму обмена сообщениями.

Сессионные бобы

Сессионные компоненты с отслеживанием состояния

Сессионные компоненты с отслеживанием состояния^[7] бизнес-объекты, имеющие государственный: то есть они отслеживают, с каким вызывающим клиентом имеют дело в течение всего сеанса, и, таким образом, доступ к экземпляру компонента строго ограничен только одним клиентом за раз.^[8] Если в любом случае предпринимается попытка одновременного доступа к одному bean-компоненту, контейнер сериализует эти запросы, но с помощью аннотации @AccessTimeout контейнер может вместо этого вызвать исключение.^[9] Состояние сессионных компонентов с отслеживанием состояния может автоматически сохраняться (пассивироваться) контейнером для освобождения памяти после того, как клиент не обращался к компоненту в течение некоторого времени. Контекст расширенного сохранения JPA явно поддерживается сеансовыми компонентами с отслеживанием состояния.^[10]

Примеры

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

Сессионные компоненты без сохранения состояния

Сессионные компоненты без сохранения состояния^[11] - это бизнес-объекты, с которыми не связано состояние. Однако доступ к одному экземпляру компонента по-прежнему ограничен одновременно только одним клиентом, одновременный доступ к bean-компоненту запрещен.^[8] При попытке одновременного доступа к одному bean-компоненту контейнер просто направляет каждый запрос в другой экземпляр.^[12] Это делает сессионный компонент без сохранения состояния автоматически потокобезопасным. Переменные экземпляра могут использоваться во время одного вызова метода от клиента к компоненту, но не гарантируется, что содержимое этих переменных экземпляра будет сохранено на разных клиентах. метод звонки. Экземпляры сессионных компонентов без сохранения состояния обычно объединяются в пул. Если второй клиент обращается к конкретному bean-компоненту сразу после завершения вызова метода, сделанного первым клиентом, он может получить тот же экземпляр. Отсутствие накладных расходов на поддержание диалога с вызывающим клиентом делает их менее ресурсоемкими, чем компоненты с отслеживанием состояния.

Примеры

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

Одиночные сессионные компоненты

Одиночные сессионные компоненты^[13][14] бизнес-объекты, имеющие глобальное общее состояние в JVM. Параллельный доступ к одному-единственному экземпляру компонента может контролироваться контейнером (параллелизм, управляемый контейнером, CMC) или самим компонентом (параллелизм, управляемый компонентом, BMC). CMC можно настроить с помощью аннотации @Lock, которая указывает, будет ли для вызова метода использоваться блокировка чтения или блокировка записи. Кроме того, сеансовые компоненты Singleton могут явно запрашивать создание экземпляра при запуске контейнера EJB с помощью аннотации @Startup.

Примеры

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

Бины, управляемые сообщениями

Бины, управляемые сообщениями^[15] - это бизнес-объекты, выполнение которых запускается сообщениями, а не вызовами методов. Бин, управляемый сообщениями, используется, среди прочего, для обеспечения упрощенной абстракции высокого уровня для JMS нижнего уровня (Служба сообщений Java ) Технические характеристики. Он может подписаться на очереди сообщений JMS или темы сообщений, что обычно происходит через атрибут ActivationConfig аннотации @MessageDriven. Они были добавлены в EJB для обеспечения обработки, управляемой событиями. В отличие от сессионных компонентов, MDB не имеет клиентского представления (локальный / удаленный / без интерфейса), т.е. е. клиенты не могут найти экземпляр MDB. MDB просто прослушивает любое входящее сообщение, например, в очереди или теме JMS, и обрабатывает их автоматически. Спецификация Java EE требует только поддержки JMS,^[16] но компоненты, управляемые сообщениями, могут поддерживать другие протоколы обмена сообщениями.^[17][18] Такие протоколы могут быть асинхронными, но также могут быть синхронными. Поскольку сессионные компоненты также могут быть синхронными или асинхронными, основное различие между компонентами, управляемыми сеансом и сообщениями, заключается не в синхронности, а в различии между (объектно-ориентированными) метод вызов и обмен сообщениями.

Примеры

• Отправка обновления конфигурации на несколько узлов может быть выполнена путем отправки сообщения JMS в «тему сообщения» и может быть обработана компонентом, управляемым сообщениями, который прослушивает эту тему (здесь используется парадигма сообщения, поскольку отправителю не нужно знать количество потребителей, их местонахождение или даже их точный тип).
• Отправка задания в рабочий кластер может быть выполнена путем отправки сообщения JMS в `` очередь сообщений '', а также может быть обработана компонентом, управляемым сообщениями, но на этот раз при прослушивании очереди (используется парадигма сообщения и очередь, поскольку отправителю не нужно заботиться о том, какой работник выполняет задание, но ему нужна гарантия, что задание выполняется только один раз).
• Обработка событий времени из Кварцевый планировщик может обрабатываться компонентом, управляемым сообщениями; когда кварц спусковой крючок срабатывает, MDB вызывается автоматически. Поскольку Java EE по умолчанию не знает о Quartz, JCA потребуется адаптер ресурсов, и MDB будет аннотирован со ссылкой на него.^[19]

Исполнение

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

Клиенты EJB не создают экземпляры этих bean-компонентов напрямую с помощью оператора new Java, а вместо этого должны получать ссылку через контейнер EJB. Эта ссылка обычно является ссылкой не на сам компонент реализации, а на доверенное лицо, который либо динамически реализует локальный, либо удаленный бизнес-интерфейс, запрошенный клиентом, или динамически реализует подтип фактического компонента. Затем прокси-сервер может быть напрямую преобразован в интерфейс или компонент. Говорят, что клиент имеет «представление» на EJB, и локальный интерфейс, удаленный интерфейс и сам тип компонента соответственно соответствуют локальному представлению, удаленному представлению и представлению без интерфейса.

Этот прокси-сервер необходим для того, чтобы дать контейнеру EJB возможность прозрачно обеспечивать сквозное (АОП -like) сервисы для bean-компонента, такие как транзакции, безопасность, перехват, инъекции и удаленное взаимодействие. Например, клиент вызывает метод на прокси-сервере, который сначала запускает транзакцию с помощью контейнера EJB, а затем вызывает фактический метод компонента. Когда метод компонента возвращается, прокси завершает транзакцию (т. Е. Совершает ее или выполняет откат) и передает управление обратно клиенту.

Контейнер EJB отвечает за обеспечение достаточных прав доступа кода клиента к EJB.^[20] Аспекты безопасности могут быть декларативно применены к EJB через аннотации.^[21]

Сделки

Контейнеры EJB должны поддерживать как управляемый контейнером КИСЛОТА транзакции и транзакции, управляемые компонентом.^[22]

Транзакции, управляемые контейнером (CMT), по умолчанию активны для вызовов сессионных компонентов. То есть явной конфигурации не требуется. Это поведение может быть декларативно настроено компонентом через аннотации, и, если необходимо, такая конфигурация может быть позже переопределена в дескрипторе развертывания. Настройка включает отключение транзакций для всего компонента или определенных методов или запрос альтернативных стратегий для распространения транзакции и запуска или присоединения к транзакции. Такие стратегии в основном касаются того, что должно произойти, если транзакция уже выполняется или не выполняется на момент вызова компонента. Поддерживаются следующие варианты:^[23][24]

В качестве альтернативы, компонент также может объявить через аннотацию, что он хочет обрабатывать транзакции программно через JTA API. Этот режим работы называется транзакциями, управляемыми компонентом (BMT), поскольку компонент обрабатывает транзакцию, а не контейнер.^[25]

События

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

Именование и службы каталогов

В качестве альтернативы внедрению клиенты EJB могут получить ссылку на прокси-объект сессионного компонента (заглушку EJB), используя Интерфейс именования и каталогов Java (JNDI). Эту альтернативу можно использовать в случаях, когда внедрение недоступно, например, в неуправляемом коде или автономных удаленных клиентах Java SE, или когда необходимо программно определить, какой bean-компонент получить.

Имена JNDI для сессионных компонентов EJB назначаются контейнером EJB по следующей схеме:^[26][27][28]

(записи в квадратных скобках обозначают необязательные части)

Один bean-компонент может быть получен с любым именем, совпадающим с указанными выше шаблонами, в зависимости от «местоположения» клиента. Клиенты в том же модуле, что и требуемый компонент, могут использовать область действия модуля и более крупные области, клиенты в том же приложении, что и требуемый компонент, могут использовать область действия приложения и выше и т. Д.

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

CustomerServiceLocal обслуживание клиентов =    (CustomerServiceLocal) новый InitialContext().искать("java: module / CustomerService");

Удаленное / распределенное выполнение

Для связи с клиентом, написанным на языке программирования Java, сессионный компонент может предоставлять удаленное представление через аннотированный интерфейс @Remote.^[29] Это позволяет вызывать эти bean-компоненты из клиентов в других JVM которые сами могут находиться в других (удаленных) системах. С точки зрения контейнера EJB любой код в другой JVM является удаленным.

Сеансовые компоненты без сохранения состояния и Singleton могут также предоставлять "клиентское представление веб-службы" для удаленной связи через WSDL и МЫЛО или простой XML.^[30][31][32] Это следует за JAX-RPC и JAX-WS технические характеристики. Однако поддержка JAX-RPC предлагается удалить в будущем.^[33] Для поддержки JAX-WS компонент сеанса аннотируется аннотацией @WebService, а методы, которые должны отображаться удаленно, с помощью аннотации @WebMethod.

Несмотря на то, что спецификация EJB никоим образом не упоминает доступ к веб-службам RESTful и не имеет явной поддержки этой формы связи, JAX-RS спецификация явно поддерживает EJB.^[34] В соответствии со спецификацией JAX-RS сессионные компоненты без сохранения состояния и Singleton могут быть корневыми ресурсами с помощью аннотации @Path, а бизнес-методы EJB могут быть сопоставлены с методами ресурсов с помощью аннотаций @GET, @PUT, @POST и @DELETE. Однако это не считается «представлением клиента веб-службы», которое используется исключительно для JAX-WS и JAX-RPC.

Связь через веб-службы типична для клиентов, написанных не на языке программирования Java, но также удобна для клиентов Java, у которых возникают проблемы с доступом к серверу EJB через брандмауэр. Кроме того, связь на основе веб-служб может использоваться клиентами Java для обхода запутанных и плохо определенных требований к так называемым «клиентским библиотекам»; набор jar-файлов, которые Java-клиент должен иметь на пути к классу, чтобы взаимодействовать с удаленным сервером EJB. Эти клиентские библиотеки потенциально конфликтуют с библиотеками, которые клиент может уже иметь (например, если сам клиент также является полноценным сервером Java EE), и такой конфликт считается очень трудным или невозможным для разрешения.^[35]

Наследие

Домашние интерфейсы и необходимый бизнес-интерфейс

В EJB 2.1 и ранее каждый EJB должен был предоставлять реализацию Java. учебный класс и два интерфейса Java. Контейнер EJB создал экземпляры класса реализации Java, чтобы обеспечить реализацию EJB. Интерфейсы Java использовались клиентским кодом EJB.

Требуемый дескриптор развертывания

В EJB 2.1 и ранее спецификация EJB требовала наличия дескриптора развертывания. Это было необходимо для реализации механизма, который позволял EJB быть развернутый согласованным образом независимо от выбранной конкретной платформы EJB. Информация о том, как должен быть развернут компонент (например, имя домашнего или удаленного интерфейса, следует ли и как хранить компонент в базе данных, и т. Д.) Должна быть указана в дескрипторе развертывания.

В дескриптор развертывания является XML документ, содержащий запись для каждого развертываемого EJB. Этот XML-документ определяет следующую информацию для каждого EJB:

• Имя домашнего интерфейса
• Java-класс для Bean (бизнес-объект)
• Интерфейс Java для домашнего интерфейса
• Java-интерфейс для бизнес-объекта
• Постоянное хранилище (только для Entity Beans)
• Роли безопасности и разрешения
• Stateful или Stateless (для сессионных компонентов)

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

Начиная с EJB 3.0 (JSR 220 ) дескриптор XML заменяется на Аннотации Java установлен в реализации Enterprise Bean (на уровне исходного кода), хотя по-прежнему можно использовать дескриптор XML вместо (или в дополнение к) аннотаций. Если дескриптор XML и аннотации применяются к одному и тому же атрибуту в корпоративном компоненте, определение XML переопределяет соответствующую аннотацию на уровне источника, хотя некоторые элементы XML также могут быть добавочными (например, свойство-config-активации в XML с имя, отличное от уже определенного в аннотации @ActivationConfigProperty, будет добавлено вместо замены всех существующих свойств).

Варианты контейнера

Начиная с EJB 3.1, спецификация EJB определяет два варианта контейнера EJB; полная версия и ограниченная версия. Ограниченная версия придерживается правильное подмножество спецификации под названием EJB 3.1 Lite ^[36][37] и является частью Веб-профиль Java EE 6 (который сам по себе является подмножеством полной спецификации Java EE 6).

EJB 3.1 Lite исключает поддержку следующих функций:^[38]

• Удаленные интерфейсы
• Совместимость RMI-IIOP
• Конечные точки веб-службы JAX-WS
• Служба таймера EJB (@Schedule, @Timeout)
• Вызов асинхронного сеансового компонента (@Asynchronous)
• Бины, управляемые сообщениями

EJB 3.2 Lite исключает меньше возможностей. В частности, он больше не исключает @Asynchronous и @ Schedule / @ Timeout, но для @Schedule он не поддерживает атрибут "persistent", который поддерживает полный EJB 3.2. Полный список исключенных для EJB 3.2 Lite:

• Удаленные интерфейсы
• Совместимость RMI-IIOP
• Конечные точки веб-службы JAX-WS
• Постоянные таймеры («постоянный» атрибут в @Schedule)
• Бины, управляемые сообщениями

История версий

EJB 4.0, финальная версия (2020-22-05)

Jakarta Enterprise Beans 4.0 как часть Jakarta EE 9, был выпуск инструментария, который в основном перемещал имена пакетов API с верхнего уровня javax.ejb пакет на верхний уровень jakarta.ejb упаковка.^[39]

Другие изменения включали удаление устаревших API, которые было бессмысленно переносить в новый пакет верхнего уровня, и удаление функций, которые зависели от функций, которые были удалены из Java или где-либо еще в Jakarta EE 9. Следующие API были удалены:

• методы, опирающиеся на java.security.Identity который был удален из Java 14.
• методы, опирающиеся на Jakarta XML RPC чтобы отразить удаление XML RPC из платформы Jakarta EE 9.
• устарел EJBContext.getEnvironment () метод.
• «Поддержка распределенного взаимодействия», чтобы отразить удаление CORBA из Java 11 и платформы Jakarta EE 9.

Другие незначительные изменения включают в себя пометку группы API Enterprise Beans 2.x как «Необязательную» и создание График аннотация повторяемая.

EJB 3.2.6, финальная версия (23.08.2019)

Jakarta Enterprise Beans 3.2, как часть Jakarta EE 8, и несмотря на то, что до сих пор используется аббревиатура «EJB», этот набор API был официально переименован в «Jakarta Enterprise Beans» Фонд Затмения чтобы не наступать на торговую марку Oracle "Java".

EJB 3.2, финальный выпуск (28 мая 2013 г.)

JSR 345. Enterprise JavaBeans 3.2 был относительно второстепенным выпуском, который в основном содержал уточнения спецификации и снял некоторые ограничения, наложенные спецификацией, но со временем, похоже, не служили реальной цели. Также требовалось, чтобы некоторые существующие полные функции EJB были в EJB 3 lite, а функции, которые предлагалось сократить в EJB 3.1, действительно были сокращены (сделаны необязательными).^[40][41]

Были добавлены следующие функции:

• Пассивирование сессионного компонента с отслеживанием состояния можно отключить с помощью атрибута в аннотации @Stateful (passivationCapable = false)
• TimerService может получать все активные таймеры в том же модуле EJB (ранее мог извлекать только таймеры для bean-компонента, в котором был вызван TimerService)
• Методы жизненного цикла (например, @PostConstruct) могут быть транзакционными для сессионных компонентов с отслеживанием состояния, используя существующую аннотацию @TransactionAttribute.
• Интерфейс с возможностью автоматического закрытия, реализованный с помощью встраиваемого контейнера

EJB 3.1, финальная версия (10.12.2009)

JSR 318. Целью спецификации Enterprise JavaBeans 3.1 является дальнейшее упрощение архитектуры EJB за счет уменьшения ее сложности с точки зрения разработчика, а также добавления новых функций в ответ на потребности сообщества:

• Локальное представление без интерфейса (представление без интерфейса)
• .война упаковка компонентов EJB
• EJB Lite: определение подмножества EJB
• Портативный EJB Global JNDI Имена
• Синглтоны (Одиночные сеансовые компоненты)
• События инициализации и завершения работы приложения
• Улучшения службы таймера EJB
• Простой Асинхронность (@ Асинхронный для сессионных компонентов)

EJB 3.0, последний выпуск (11 мая 2006 г.)

JSR 220 - Серьезные изменения: Этот выпуск значительно упростил написание EJB-компонентов с использованием «аннотаций», а не сложных «дескрипторов развертывания», используемых в версии 2.x. Использование домашнего и удаленного интерфейсов и файла ejb-jar.xml также больше не требовалось в этом выпуске, поскольку он был заменен бизнес-интерфейсом и компонентом, реализующим интерфейс.

EJB 2.1, финальный выпуск (24 ноября 2003 г.)

JSR 153 - Серьезные изменения:

• веб-сервис поддержка (новое): сессионные компоненты без сохранения состояния могут быть вызваны через МЫЛО /HTTP. Кроме того, EJB может легко получить доступ к Web-сервису, используя новую ссылку на сервис.
• Служба таймера EJB (новинка): механизм на основе событий для вызова EJB в определенное время.
• Компоненты, управляемые сообщениями, принимают сообщения от источников, отличных от JMS.
• Добавлены места назначения сообщений (такая же, как ссылки на EJB, ссылки на ресурсы и т. Д.).
• Добавления языка запросов EJB (EJB-QL): ORDER BY, AVG, MIN, MAX, SUM, COUNT и MOD.
• Схема XML используется для указания дескрипторов развертывания, заменяет DTD

EJB 2.0, последний выпуск (22.08.2001)

JSR 19 - Серьезные изменения:Общие цели:

• Стандартная компонентная архитектура для строительства распределен объектно-ориентированные бизнес-приложения в Ява.
• Сделать возможным создание распределенных приложений путем объединения компонентов, разработанных с использованием инструментов из разные поставщики.
• Упростите написание (корпоративных) приложений: разработчикам приложений не придется разбираться в деталях низкоуровневого управления транзакциями и состоянием, многопоточности, пула соединений и других сложных низкоуровневых API.
• Будет следовать философии «Напиши один раз, беги где угодно» Ява. Корпоративный компонент можно разработать один раз, а затем развернуть на нескольких платформах без перекомпиляции или модификации исходного кода.
• Рассмотрите аспекты разработки, развертывания и выполнения в жизненном цикле корпоративного приложения.
• Определите контракты, которые позволяют инструментам от нескольких поставщиков разрабатывать и развертывать компоненты, которые могут взаимодействовать во время выполнения.
• Будьте совместимы с существующими серверными платформами. Поставщики смогут расширять свои существующие продукты для поддержки EJB.
• Будьте совместимы с другими Ява API.
• Обеспечение взаимодействия между корпоративными компонентами и компонентами Java EE, а также приложениями на языке программирования, отличном от Java.
• Будьте совместимы с протоколами CORBA (RMI-IIOP).

EJB 1.1, последняя версия (1999-12-17)

Серьезные изменения:

• Дескрипторы развертывания XML
• Контексты JNDI по умолчанию
• RMI через IIOP
• Безопасность - зависит от ролей, а не методов
• Поддержка Entity Bean - обязательна, но не обязательна

Цели для версии 1.1:

• Обеспечьте лучшую поддержку сборки и развертывания приложений.
• Более подробно укажите обязанности отдельных ролей EJB.

EJB 1.0 (24 марта 1998 г.)

Объявлено на JavaOne 1998,^[42] Третья конференция Sun Java-разработчиков (24–27 марта)Цели для версии 1.0:

• Определены отдельные «роли EJB», которые предполагает компонентная архитектура.
• Определяет клиентское представление корпоративных компонентов.
• Определяет точку зрения разработчика корпоративных компонентов.
• Определены обязанности поставщика контейнера EJB и поставщика сервера; вместе они составляют систему, которая поддерживает развертывание и выполнение корпоративных компонентов.

Рекомендации

внешняя ссылка

• Официальный веб-сайт
• Документация Java EE 8 API Javadocs
• Документация Javadoc по API EJB 3.0
• Спецификация EJB 3.0
• Руководство Sun EJB 3.0
• EJB (3.0) Глоссарий
• EJB FAQ
• JSR 345 (EJB 3.2)
• JSR 318 (EJB 3.1)
• JSR 220 (EJB 3.0)
• JSR 153 (EJB 2.1)
• JSR 19 (EJB 2.0)
• «Работа с объектами, управляемыми сообщениями» из EJB3 в действии, второе издание
• Клиент вызывает EJB