Войти
Jakarta Enterprise Beans (EJB ; ранее Enterprise JavaBeans) является одним из нескольких Java API для модульного построения корпоративного программного обеспечения. EJB - это на стороне сервера программный компонент, который инкапсулирует бизнес-логику приложения. Веб-контейнер EJB предоставляет среду выполнения для компонентов программного обеспечения, связанных с веб, включая компьютерную безопасность, управление жизненным циклом сервлетов Java, обработка транзакций и другие веб-сервисы. Спецификация EJB - это подмножество спецификации Java EE.
Спецификация EJB была первоначально разработана в 1997 г. компанией IBM, а затем принята от Sun Microsystems (EJB 1.0 и 1.1) в 1999 году и усовершенствован в рамках Java Community Process как 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 предоставляет стандартный способ реализации серверного (также называемого «back-end ») «бизнес» программного обеспечения, которое обычно встречается в корпоративных приложениях (в отличие от «front- конец 'пользовательский интерфейс программное обеспечение). Такое программное обеспечение решает одни и те же типы проблем, и решения этих проблем часто повторно реализуются программистами. Jakarta Enterprise Beans предназначен для решения таких распространенных проблем, как постоянство, целостность транзакций и безопасность стандартным способом, позволяя программистам сосредоточиться на конкретных частях программное обеспечение предприятия под рукой.
В спецификации EJB подробно описано, как сервер приложений обеспечивает следующие обязанности:
Кроме того, спецификация Enterprise JavaBean определяет роли, выполняемые контейнером EJB и EJB, а также способы развертывания EJB в контейнере. Обратите внимание, что текущая спецификация EJB 3.2 не детализирует, как сервер приложений обеспечивает постоянство (задача удаления gated в соответствии со спецификацией JPA), но вместо этого подробно описывает, как бизнес-логика может легко интегрироваться с сервисами сохранения, предлагаемыми сервером приложений.
Компании обнаружили, что использование EJB-компонентов для инкапсуляции бизнес-логики приводит к снижению производительности. Это связано с тем, что исходная спецификация допускала только удаленный вызов метода через CORBA (и, возможно, другие протоколы), даже несмотря на то, что подавляющее большинство бизнес-приложений фактически не требует этой функции распределенных вычислений. Спецификация EJB 2.0 решила эту проблему, добавив концепцию локальных интерфейсов, которые могут быть вызваны напрямую без снижения производительности приложениями, которые не были распределены по нескольким серверам.
Спецификация EJB 3.0 (JSR 220) был отходом от своих предшественников, следуя новой парадигме облегчения. EJB 3.0 демонстрирует влияние Spring в использовании простых объектов Java и поддержку внедрения зависимостей для упрощения настройки и интеграции гетерогенных систем. Гэвин Кинг, создатель Hibernate, участвовал в процессе EJB 3.0 и является ярым сторонником этой технологии. Многие функции, изначально включенные в Hibernate, были включены в Java Persistence API, заменяющий entity beans в EJB 3.0. Спецификация EJB 3.0 в значительной степени полагается на использование аннотаций (функция, добавленная в язык Java с его версией 5.0) и соглашения по сравнению с конфигурацией, чтобы обеспечить гораздо менее подробный стиль кодирования. Соответственно, с практической точки зрения EJB 3.0 является гораздо более легким и почти полностью новым API, мало похожим на предыдущие спецификации EJB.
Ниже показан базовый пример того, что такое EJB выглядит так:
@Stateless открытый класс CustomerService {private EntityManager entityManager; public void addCustomer (Клиент-клиент) {entityManager.persist (клиент); }}Вышеуказанное определяет класс обслуживания для сохранения объекта Customer (через отображение O / R ). EJB заботится об управлении контекстом постоянства, а метод addCustomer () по умолчанию является транзакционным и потокобезопасным. Как было показано, EJB фокусируется только на бизнес-логике и устойчивости и ничего не знает о каком-либо конкретном представлении.
Такой EJB может использоваться классом, например, веб-уровень следующим образом:
@Named @RequestScoped открытый класс CustomerBacking {@EJB private CustomerService customerService; общедоступная строка addCustomer (клиент-клиент) {customerService.addCustomer (клиент); context.addMessage (...); // для краткости сокращено return "customer_overview"; }}Вышеупомянутое определяет вспомогательный компонент JavaServer Faces (JSF), в который EJB внедряется посредством аннотации @EJB. Его метод addCustomer обычно привязан к некоторому компоненту пользовательского интерфейса, например к кнопке. В отличие от EJB, компонент поддержки не содержит никакой бизнес-логики или кода сохранения, но делегирует такие проблемы EJB. Поддерживающий компонент знает о конкретной презентации, о которой EJB ничего не знал.
Контейнер EJB содержит два основных типа компонентов:
Сессионные компоненты с отслеживанием состояния - это бизнес-объекты, имеющие состояние : то есть, они отслеживают, с каким вызывающим клиентом имеют дело в течение всего сеанса, и, таким образом, доступ к экземпляру компонента строго ограничен только одним клиентом за раз. Если в любом случае предпринимается попытка одновременного доступа к одному bean-компоненту, контейнер сериализует эти запросы, но с помощью аннотации @AccessTimeout контейнер может вместо этого вызвать исключение. Состояние сессионных компонентов с отслеживанием состояния может автоматически сохраняться (пассивироваться) контейнером для освобождения памяти после того, как клиент не обращался к компоненту в течение некоторого времени. Расширенный контекст персистентности JPA явно поддерживается сеансовыми компонентами с отслеживанием состояния.
Сессионные компоненты без сохранения состояния - это бизнес-объекты, с которыми не связано состояние. Однако доступ к одному экземпляру bean-компонента по-прежнему ограничен только одним клиентом одновременно, одновременный доступ к bean-компоненту запрещен. При попытке одновременного доступа к одному bean-компоненту контейнер просто направляет каждый запрос в другой экземпляр. Это делает сессионный компонент без сохранения состояния автоматически потокобезопасным. Переменные экземпляра могут использоваться во время одного вызова метода от клиента к компоненту, но не гарантируется сохранение содержимого этих переменных экземпляра при различных вызовах метода client . Экземпляры сессионных компонентов без сохранения состояния обычно объединяются в пул. Если второй клиент обращается к конкретному bean-компоненту сразу после завершения вызова метода, сделанного первым клиентом, он может получить тот же экземпляр. Отсутствие накладных расходов на поддержание диалога с вызывающим клиентом делает их менее ресурсоемкими, чем компоненты с отслеживанием состояния.
Singleton Session Beans - это бизнес-объекты, имеющие глобальное общее состояние в JVM. Параллельный доступ к одному-единственному экземпляру компонента может управляться контейнером (параллелизм, управляемый контейнером, CMC) или самим компонентом (параллелизм, управляемый компонентом, BMC). CMC можно настроить с помощью аннотации @Lock, которая указывает, будет ли для вызова метода использоваться блокировка чтения или блокировка записи. Кроме того, сеансовые компоненты Singleton могут явно запрашивать создание экземпляра при запуске контейнера EJB с помощью аннотации @Startup.
Компоненты, управляемые сообщениями - это бизнес-объекты, выполнение которых запускается сообщениями, а не вызовами методов. Бин, управляемый сообщениями, используется, среди прочего, для обеспечения упрощенной абстракции высокого уровня для спецификации JMS нижнего уровня (Java Message Service ). Он может подписаться на очереди сообщений JMS или темы сообщений, что обычно происходит через атрибут ActivationConfig аннотации @MessageDriven. Они были добавлены в EJB для обеспечения обработки, управляемой событиями. В отличие от сессионных компонентов, MDB не имеет клиентского представления (локальный / удаленный / без интерфейса), т.е. е. клиенты не могут найти экземпляр MDB. MDB просто прослушивает любое входящее сообщение, например, в очереди или теме JMS, и обрабатывает их автоматически. Спецификация Java EE требует только поддержки JMS, но компоненты, управляемые сообщениями, могут поддерживать другие протоколы обмена сообщениями. Такие протоколы могут быть асинхронными, но также могут быть синхронными. Поскольку сессионные компоненты могут быть синхронными или асинхронными, основное различие между сессионными компонентами и компонентами, управляемыми сообщениями, заключается не в синхронности, а в различии между (объектно-ориентированным) методом вызовом и обмен сообщениями.
EJBs развернуты в контейнере EJB, обычно на сервере приложений . В спецификации описывается, как EJB взаимодействует со своим контейнером и как клиентский код взаимодействует с комбинацией контейнер / EJB. Классы EJB, используемые приложениями, включены в пакет javax.ejb . (Пакет javax.ejb.spi - это интерфейс поставщика услуг, используемый только реализациями контейнера EJB.)
Клиенты EJB не поддерживают создавать экземпляры этих bean-компонентов напрямую с помощью оператора new Java, но вместо этого необходимо получить ссылку через контейнер EJB. Эта ссылка обычно является ссылкой не на сам компонент реализации, а на прокси , который либо динамически реализует локальный или удаленный бизнес-интерфейс, запрошенный клиентом, либо динамически реализует подтип фактического компонента. Затем прокси-сервер может быть напрямую приведен к интерфейсу или компоненту. Говорят, что клиент имеет «представление» на EJB, и локальный интерфейс, удаленный интерфейс и сам тип компонента соответственно соответствуют локальному представлению, удаленному представлению и представлению без интерфейса.
Этот прокси-сервер необходим для того, чтобы дать контейнеру EJB возможность прозрачно предоставлять сквозные (AOP -подобные) сервисы для bean-компонента, такие как транзакции, безопасность, перехват, внедрение и удаленное взаимодействие. Например, клиент вызывает метод на прокси-сервере, который сначала запускает транзакцию с помощью контейнера EJB, а затем вызывает фактический метод компонента. Когда метод компонента возвращается, прокси завершает транзакцию (т. Е. Совершает ее или выполняет откат) и передает управление обратно клиенту.
Контейнер EJB отвечает за обеспечение достаточных прав доступа кода клиента к EJB. Аспекты безопасности могут быть декларативно применены к EJB с помощью аннотаций.
Контейнеры EJB должны поддерживать как транзакции, управляемые контейнером ACID, так и транзакции, управляемые компонентами.
Транзакции, управляемые контейнером (CMT), по умолчанию активны для вызовов сессионных компонентов. То есть явной конфигурации не требуется. Это поведение может быть декларативно настроено компонентом через аннотации, и при необходимости такая конфигурация может быть позже переопределена в дескрипторе развертывания. Настройка включает отключение транзакций для всего bean-компонента или определенных методов или запрос альтернативных стратегий для распространения транзакции и запуска или присоединения к транзакции. Такие стратегии в основном касаются того, что должно произойти, если транзакция уже выполняется или не выполняется на момент вызова компонента. Поддерживаются следующие варианты:
| Тип | Пояснение |
|---|---|
| ОБЯЗАТЕЛЬНО | Если клиент не начал транзакцию, генерируется исключение. В противном случае используется транзакция клиента. |
| ТРЕБУЕТСЯ | Если клиент начал транзакцию, она используется. В противном случае запускается новая транзакция. (это значение по умолчанию, если явный тип не указан) |
| REQUIRES_NEW | Если клиент начал транзакцию, она приостанавливается. Всегда начинается новая транзакция. |
| ПОДДЕРЖИВАЕТ | Если клиент начал транзакцию, она используется. В противном случае транзакция не используется. |
| NOT_SUPPORTED | Если клиент начал транзакцию, она приостанавливается. Никакая новая транзакция не начинается. |
| НИКОГДА | Если клиент начал транзакцию, генерируется исключение. Никакая новая транзакция не начинается. |
В качестве альтернативы, компонент может также объявить через аннотацию, что он хочет обрабатывать транзакции программно через JTA API. Этот режим работы называется Bean Managed Transactions (BMT), поскольку сам компонент обрабатывает транзакцию, а не контейнер.
JMS (Java Message Service ) используется для отправки сообщений от bean-компонентов клиентам, чтобы клиенты могли получать асинхронные сообщения от этих bean-компонентов. MDB могут использоваться для асинхронного приема сообщений от клиентов с использованием либо очереди JMS, либо темы.
В качестве альтернативы внедрению клиенты EJB могут получить ссылку на прокси-объект сессионного компонента (заглушку EJB) с помощью Java Naming and Directory Interface (JNDI). Эту альтернативу можно использовать в случаях, когда внедрение недоступно, например, в неуправляемом коде или автономных удаленных клиентах Java SE, или когда необходимо программно определить, какой bean-компонент получить.
Имена JNDI для сеансовых компонентов EJB назначаются контейнером EJB по следующей схеме:
| Область | Шаблон имени |
|---|---|
| Глобальный | java: global [/ |
| Приложение | java: app / |
| Модуль | java: module / |
(записи в квадратных скобках обозначают необязательные части)
Отдельный bean-компонент может быть получен с любым именем, соответствующим указанным выше шаблонам, в зависимости от «местоположения» клиента. Клиенты в том же модуле, что и требуемый компонент, могут использовать область действия модуля и более крупные области, клиенты в том же приложении, что и требуемый компонент, могут использовать область действия приложения и выше и т. Д.
Например. код, работающий в том же модуле, что и bean-компонент CustomerService (как указано в примере, показанном ранее в этой статье), может использовать следующий код для получения (локальной) ссылки на него:
CustomerServiceLocal customerService = (CustomerServiceLocal) new InitialContext ().lookup ("java: модуль / CustomerService");Для связи с клиентом, написанным на языке программирования Java, сессионный компонент может предоставлять удаленное представление через аннотированный интерфейс @Remote. Это позволяет вызывать эти bean-компоненты из клиентов в других JVM, которые сами могут быть расположены в других (удаленных) системах. С точки зрения контейнера EJB любой код в другой JVM является удаленным.
Сеансовые компоненты без сохранения состояния и Singleton могут также предоставлять "клиентское представление веб-службы" для удаленной связи через WSDL и SOAP или простой XML. Это соответствует спецификациям JAX-RPC и JAX-WS. Однако поддержка JAX-RPC предлагается удалить в будущем. Для поддержки JAX-WS сессионный компонент аннотируется аннотацией @WebService, а методы, которые должны быть доступны удаленно с помощью аннотации @WebMethod.
Хотя в спецификации EJB не упоминается доступ как веб-службы RESTful каким-либо образом и не имеет явной поддержки этой формы связи, спецификация JAX-RS явно поддерживает EJB. В соответствии со спецификацией JAX-RS сессионные компоненты без сохранения состояния и Singleton могут быть корневыми ресурсами с помощью аннотации @Path, а бизнес-методы EJB могут быть сопоставлены с методами ресурсов с помощью аннотаций @GET, @PUT, @POST и @DELETE. Однако это не считается «представлением клиента веб-службы», которое используется исключительно для JAX-WS и JAX-RPC.
Связь через веб-службы типична для клиентов, написанных не на языке программирования Java, но также удобна для клиентов Java, у которых возникают проблемы с доступом к серверу EJB через брандмауэр. Кроме того, связь на основе веб-служб может использоваться клиентами Java для обхода запутанных и плохо определенных требований к так называемым «клиентским библиотекам»; набор jar-файлов, которые Java-клиент должен иметь на пути к классу, чтобы взаимодействовать с удаленным сервером EJB. Эти клиентские библиотеки потенциально конфликтуют с библиотеками, которые клиент может уже иметь (например, если сам клиент также является полноценным сервером Java EE), и такой конфликт считается очень трудным или невозможным для разрешения.
В EJB 2.1 и ранее каждый EJB должен был предоставлять реализацию Java класс и два интерфейса Java. Контейнер EJB создал экземпляры класса реализации Java, чтобы обеспечить реализацию EJB. Интерфейсы Java использовались клиентским кодом EJB.
В EJB 2.1 и ранее спецификация EJB требовала наличия дескриптора развертывания. Это было необходимо для реализации механизма, который позволял бы развернуть EJB согласованным образом, независимо от конкретной выбранной платформы EJB. Информация о том, как должен быть развернут компонент (например, имя домашнего или удаленного интерфейса, следует ли и как хранить компонент в базе данных, и т. Д.) Должна быть указана в дескрипторе развертывания.
дескриптор развертывания - это документ XML, имеющий запись для каждого развертываемого EJB. Этот XML-документ определяет следующую информацию для каждого EJB:
Старый Для контейнеров 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 и является частью веб-профиля Java EE 6 (который сам является подмножеством полной спецификации Java EE 6).
EJB 3.1 Lite исключает поддержку следующих функций:
EJB 3.2 Lite исключает меньше возможностей. В частности, он больше не исключает @Asynchronous и @ Schedule / @ Timeout, но для @Schedule он не поддерживает атрибут "persistent", который поддерживает полный EJB 3.2. Полный список исключенных для EJB 3.2 Lite:
EJB 3.2.6, финальный выпуск (23.08.2019)
Несмотря на то, что EJB все еще используется, Eclipse Foundation официально переименовал их в Jakarta Enterprise Beans, чтобы не наступать на торговую марку "Java".
EJB 3.2, финальная версия (28.05.2013)
JSR 345. Enterprise JavaBeans 3.2 был относительно второстепенным выпуском, который в основном содержал уточнения спецификации и снял некоторые ограничения, которые были наложены спецификацией, но со временем, похоже, не служили реальной цели. Также требовалось, чтобы некоторые существующие полные функции EJB были в EJB 3 lite, и функциональность, которую предлагалось сократить в EJB 3.1, действительно была сокращена (сделана необязательной).
Были добавлены следующие функции:
EJB 3.1, финальная версия (2009 г.) -12-10)
JSR 318. Целью спецификации Enterprise JavaBeans 3.1 является дальнейшее упрощение архитектуры EJB за счет уменьшения ее сложности с точки зрения разработчика, а также добавления новых функций в ответ на потребности сообщества:
EJB 3.0, финальный выпуск (2006-05-11)
JSR 220 - Основные изменения: в этом выпуске стало намного проще писать EJB-компоненты, используя «аннотации», а не сложные «дескрипторы развертывания» используется в версии 2.x. Использование домашнего и удаленного интерфейсов и файла ejb-jar.xml также больше не требовалось в этом выпуске, поскольку он был заменен бизнес-интерфейсом и компонентом, реализующим интерфейс.
EJB 2.1, финальная версия (2003-11-24)
JSR 153 - Основные изменения:
EJB 2.0, окончательный выпуск (22.08.2001)
JSR 19 - Основные изменения: Общие цели:
EJB 1.1, финальная версия (1999-12-17)
Основные изменения:
Цели для выпуска 1.1:
EJB 1.0 (1998-03-24)
Объявлено на JavaOne 1998, третьей конференции Java-разработчиков Sun (24–27 марта). Цели выпуска 1.0:
