Из Википедии, свободной энциклопедии
Перейти к навигацииПерейти к поиску

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

Спецификация

Спецификация EJB была первоначально разработана IBM в 1997 году, а затем принята 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 предоставляет стандартный способ реализации серверного (также называемого « back-end ») «бизнес» программного обеспечения, которое обычно используется в корпоративных приложениях (в отличие от программного обеспечения « внешнего интерфейса » с пользовательским интерфейсом ). Такое программное обеспечение решает одни и те же типы проблем, и решения этих проблем часто повторно реализуются программистами. Jakarta Enterprise Beans предназначен для решения таких общих задач, как постоянство , целостность транзакций и безопасность стандартным способом, оставляя программистам возможность сосредоточиться на отдельных частях имеющегося корпоративного программного обеспечения.

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

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

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

История

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

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

Пример

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

@Stateless  общедоступный  класс  CustomerService  { частный  EntityManager  entityManager ; public  void  addCustomer ( Клиент-  клиент )  {  entityManager . настаивать ( заказчик );  }  }

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

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

@Named @RequestScoped общедоступный  класс  CustomerBacking  {  @EJB  private  CustomerService  customerService ; общедоступная  строка  addCustomer ( Клиент-  клиент )  {  customerService . addCustomer ( заказчик );  контекст . addMessage (...);  // сокращенно  return  "customer_overview" ;  } }

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

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

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

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

Сессионные компоненты

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

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

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

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

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

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

Singleton Session Beans

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

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

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

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

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

Казнь

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

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

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

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

Транзакции

Контейнеры EJB должны поддерживать как транзакции ACID, управляемые контейнером, так и транзакции, управляемые компонентами. [22]

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

Типы декларативного управления транзакциями
ТипОбъяснение
ОБЯЗАТЕЛЬНЫЙЕсли клиент не начал транзакцию, выдается исключение. В противном случае используется транзакция клиента.
ОБЯЗАТЕЛЬНЫЙЕсли клиент начал транзакцию, она используется. В противном случае запускается новая транзакция. (это значение по умолчанию, если не указан явный тип)
REQUIRES_NEWЕсли клиент начал транзакцию, она приостанавливается. Всегда начинается новая транзакция.
ПОДДЕРЖКАЕсли клиент начал транзакцию, она используется. В противном случае транзакция не используется.
НЕ ПОДДЕРЖИВАЕТСЯЕсли клиент начал транзакцию, она приостанавливается. Никакая новая транзакция не начинается.
НИКОГДАЕсли клиент начал транзакцию, выдается исключение. Никакая новая транзакция не начинается.

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

События

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

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

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

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

Имена JNDI
ОбъемШаблон имени
Глобальныйjava: global [/ <имя-приложения>] / <имя-модуля> / <имя-боба> [! <полностью-квалифицированное-имя-интерфейса>]
Приложениеjava: app / <имя-модуля> / <имя-боба> [! <полностью квалифицированное-имя-интерфейса>]
Модульjava: module / <имя-боба> [! <имя-полностью-квалифицированного-интерфейса>]

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

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

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

CustomerServiceLocal  customerService  =  ( CustomerServiceLocal )  новый  InitialContext (). поиск ( "java: модуль / CustomerService" );

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

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

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

Хотя спецификация EJB никоим образом не упоминает представление в виде веб-сервисов RESTful и не имеет явной поддержки для этой формы связи, спецификация JAX-RS явно поддерживает EJB. [34] В соответствии со спецификацией JAX-RS сессионные компоненты Singleton и Stateless могут быть корневыми ресурсами с помощью аннотации @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-дескриптор и аннотации применяются к одному и тому же атрибуту внутри Enterprise Bean, определение 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 он не поддерживает "постоянный" атрибут, который поддерживает полный EJB 3.2. Полный список исключенных для EJB 3.2 Lite:

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

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

EJB 4.0, финальная версия (22 мая 2020 г.)

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 как «Необязательную» и Scheduleповторение аннотации.

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

Jakarta Enterprise Beans 3.2 , как часть Jakarta EE 8, и, несмотря на то, что до сих пор используется аббревиатура EJB, этот набор API был официально переименован Eclipse Foundation в 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 декабря 2009 г.)

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

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

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

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

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

JSR 153 - Основные изменения :

  • Поддержка веб-сервисов (новинка): сессионные компоненты без сохранения состояния могут быть вызваны через SOAP / 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 - Основные изменения : Общие цели :

  • Стандартная компонентная архитектура для построения распределенных объектно-ориентированных бизнес-приложений на Java .
  • Сделайте возможным создание распределенных приложений, комбинируя компоненты, разработанные с использованием инструментов от разных поставщиков .
  • Упростите написание (корпоративных) приложений: разработчикам приложений не придется разбираться в деталях низкоуровневого управления транзакциями и состоянием, многопоточности, пула соединений и других сложных низкоуровневых API.
  • Буду следовать философии Java «Напиши один раз, запусти где угодно» . Корпоративный компонент можно разработать один раз, а затем развернуть на нескольких платформах без перекомпиляции или модификации исходного кода.
  • Рассмотрение аспектов жизненного цикла корпоративного приложения, связанных с разработкой, развертыванием и выполнением.
  • Определите контракты, которые позволяют инструментам от нескольких поставщиков разрабатывать и развертывать компоненты, которые могут взаимодействовать во время выполнения.
  • Будьте совместимы с существующими серверными платформами. Поставщики смогут расширять свои существующие продукты для поддержки EJB.
  • Будьте совместимы с другими API Java .
  • Обеспечение взаимодействия между корпоративными компонентами и компонентами 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] третьей конференции Java-разработчиков Sun (24–27 марта). Цели выпуска 1.0:

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

Ссылки

  1. ^ «Технология Enterprise JavaBeans» . www.oracle.com . Проверено 15 декабря 2016 .
  2. ^ Дизайн и разработка J2EE , © 2002 Wrox Press Ltd., стр. 5.
  3. ↑ J2EE Design and Development , 2002, Wrox Press Ltd., стр. 19.
  4. ^ JSR 318, 4.1, http://jcp.org/en/jsr/detail?id=318
  5. ^ «Дополнительные местные бизнес-интерфейсы (блог Кена Сакса)» . Архивировано из оригинального 19 ноября 2015 года . Проверено 1 июня +2016 .
  6. ^ JSR 318, 4.5, http://jcp.org/en/jsr/detail?id=318
  7. ^ JSR 318, 4.6, http://jcp.org/en/jsr/detail?id=318
  8. ^ а б JSR 318, 4.10.3, http://jcp.org/en/jsr/detail?id=318
  9. ^ JSR 318, 4.3.14, 21.4.2, http://jcp.org/en/jsr/detail?id=318
  10. ^ «Постоянство контекста в Stateful» . Архивировано из оригинального 16 марта 2008 года . Проверено 1 июня +2016 .
  11. ^ JSR 318, 4.7, http://jcp.org/en/jsr/detail?id=318
  12. ^ JSR 318, 4.3.14, http://jcp.org/en/jsr/detail?id=318
  13. ^ JSR 318, 4.8, http://jcp.org/en/jsr/detail?id=318
  14. ^ "Синглтон EJB" . Openejb.apache.org . Проверено 17 июня 2012 .
  15. ^ JSR 318, 5.1, http://jcp.org/en/jsr/detail?id=318
  16. ^ JSR 318, 5.7.2, http://jcp.org/en/jsr/detail?id=318
  17. ^ JSR 318, 5.4.2, http://jcp.org/en/jsr/detail?id=318
  18. ^ JSR 318, 5.6.2, http://jcp.org/en/jsr/detail?id=318
  19. ^ Разработка Quartz MDB. «Разработка Кварцевого МДБ» . Mastertheboss.com . Проверено 17 июня 2012 .
  20. ^ JSR 318, Глава 17, http://jcp.org/en/jsr/detail?id=318
  21. ^ «Аннотации по безопасности» . Openejb.apache.org . Проверено 17 июня 2012 .
  22. ^ JSR 318, Глава 13, http://jcp.org/en/jsr/detail?id=318
  23. ^ JSR 318, 13.6.2, http://jcp.org/en/jsr/detail?id=318
  24. ^ «Аннотации транзакций» . Openejb.apache.org . Проверено 17 июня 2012 .
  25. ^ JSR 318, 13.3.6, http://jcp.org/en/jsr/detail?id=318
  26. ^ JSR 318, 4.4, http://jcp.org/en/jsr/detail?id=318
  27. ^ «Переносимые глобальные имена JNDI (MaheshKannan)» . Blogs.oracle.com. Архивировано из оригинала на 2011-06-20 . Проверено 17 июня 2012 .
  28. ^ «Переносимые глобальные имена JNDI (блог Кена Сакса)» . Blogs.oracle.com. Архивировано из оригинала на 2011-12-29 . Проверено 17 июня 2012 .
  29. ^ JSR 318, Глава 15, http://jcp.org/en/jsr/detail?id=318
  30. ^ JSR 318, 2.6, http://jcp.org/en/jsr/detail?id=318
  31. ^ JSR 318, 3.2.4, http://jcp.org/en/jsr/detail?id=318
  32. ^ JSR 318, 4.3.6, http://jcp.org/en/jsr/detail?id=318
  33. ^ JSR 318, 2.7, http://jcp.org/en/jsr/detail?id=318
  34. ^ JSR 311, глава 6.2, http://jcp.org/en/jsr/detail?id=311
  35. ^ «Связь между JBoss AS 5 и JBoss AS 6 | JBoss AS | Сообщество JBoss» . Community.jboss.org . Проверено 17 июня 2012 .
  36. ^ "Веб-профиль Resin Java EE 6 - Resin 3.0" . Wiki.caucho.com. 12 февраля 2010 г. Архивировано из оригинала на 2012-03-23 . Проверено 17 июня 2012 .
  37. ^ JSR 318, 21.1 EJB 3.1 Lite, http://jcp.org/en/jsr/detail?id=318
  38. ^ JSR 318, Таблица 27 - Необходимое содержимое EJB 3.1 Lite и Full EJB 3.1 API, http://jcp.org/en/jsr/detail?id=318
  39. ^ «Что нового в этой версии» . Jakarta Enterprise Beans, основные функции . Jakarta Enterprise Beans 4.0. Jakarta EE . 5 ноября 2020 . Проверено 5 декабря 2020 .
  40. ^ «Что нового в EJB 3.2? - Java EE 7 набирает обороты! (Арун Гупта, осталось много миль ...)» . Проверено 1 июня +2016 .
  41. ^ «Если вы не знали, что будет в EJB 3.2 ... (блог Марины Ваткиной)» . Архивировано из оригинала 4 марта 2016 года . Проверено 1 июня +2016 .
  42. ^ «Отчет о поездке на конференции JavaOne: Технология Enterprise JavaBeans: Разработка и развертывание бизнес-приложений в качестве компонентов» . Alephnaught.com . Проверено 17 июня 2012 .

Внешние ссылки

  • Официальный веб-сайт
  • Документация 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