Что такое EJB? Эволюция Enterprise JavaBeans

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

EJB архитектура

Архитектура EJB состоит из трех основных компонентов: корпоративных компонентов (EJB), контейнера EJB и сервера приложений Java. EJB запускаются внутри контейнера EJB, а контейнер EJB запускается внутри сервера приложений Java.

Существует два типа EJB - сессионные компоненты и компоненты, управляемые сообщениями:

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

Когда-то используемые для обеспечения устойчивости в системе EJB, объектные компоненты были вытеснены Java Persistence API. Продолжайте читать, чтобы узнать больше о сессионных компонентах и ​​компонентах, управляемых сообщениями.

EJB против JavaBeans

Enterprise JavaBeans была первой компонентной моделью разработки для Java EE. EJB похож на JavaBeans в том, что он основан на компонентах, но на этом сходство заканчивается:

  • JavaBean является классом Java , который инкапсулирует несколько объектов и соответствует определенным правилам. JavaBeans используются в основном для разработки на стороне клиента.
  • Корпоративный компонент (EJB) - это класс Java, наделенный определенными возможностями на стороне сервера. Корпоративные компоненты используются в крупномасштабных бизнес-приложениях и системах.

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

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

Контейнер EJB управляет жизненным циклом сессионного компонента, который определяется его состоянием:

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

Безопасность потоков с сессионными компонентами

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

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

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

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

Простейшая архитектура будет состоять из приложения EJB, его контейнера и сервера, которые координируются со службой сообщений, обрабатывающей MDB. В производственной среде ваша архитектура, скорее всего, будет включать третий компонент, предназначенный для использования bean-компонентов. В процессе разработки все эти компоненты могут работать на одной локальной машине.

На рисунке 1 показана типичная управляемая событиями архитектура с компонентами, управляемыми сообщениями.

Мэтью Тайсон

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

Хотя сессионные компоненты проще и поэтому чаще используются в EJB, архитектуры, управляемые событиями, стали популярными, особенно с появлением микросервисов. 

Аннотации EJB

Определение и использование корпоративных компонентов было камнем преткновения для многих разработчиков до EJB 3.0, в котором были введены аннотации к спецификации EJB. Аннотации упрощают настройку корпоративных компонентов для работы с широким спектром функций Java EE. Продолжайте читать, чтобы начать работу с аннотациями EJB.

@Stateless: определить сессионный компонент без состояния

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

Листинг 1. Пример аннотации @Stateless

 import javax.ejb.Stateless; @Stateless public class MyStatelessBean { public String getGreeting() { return "Hello JavaWorld."; } } 

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

@EJB: использовать сессионный компонент без сохранения состояния

После того, как вы определили сессионный компонент, пользоваться им очень просто:

Листинг 2. Пример аннотации @EJB

 public class MyServlet extends HttpServlet { @EJB MyStatelessBean myEjb; public void doGet(HttpServletRequest request, HttpServletResponse response) { response.getWriter().write("EJB Says " + testStatelessEjb.getGreeting()); } } 

Here, we inject the stateless bean into a servlet, and then it's available for use. Notice how the bean is identified under the @EJB annotation. The "stateless" designation tells us this bean will not track the client. Because it's stateless, we also know this bean is subject to threading if it does any work outside the invoked method.

@Remote: Define a remote EJB interface

In the above examples, I assumed the EJB and EJB client were running in the same JVM. If the enterprise bean and its client are running in separate JVMs, then the EJB must define a @Remote interface. In this case, it's up to you to define and implement the interface, as shown in Listing 3.

Listing 3. @Remote annotation example

 @Remote public interface MyStatelessEjbRemote { String sayHello(String name); } 

The remote interface is sent to the client to invoke. Calls to it will then be fulfilled by the EJB's server-side implementation. The MyStatelessBean example in Listing 4 implements the remote interface.

Listing 4. Implementing a remote interface

 public class MyStatelessBean implements MyStatelessEjbRemote{ ... } 

A remote interface is implemented just like a normal class implementing an interface. As the consumer of a remote EJB, the client application must be able to access the class definition for the remote interface. You can package the class definition for the remote interface as a dependency JAR.

Local vs remote interface

While it's important to know how to implement a remote interface, in practice it's more common to use a local interface. The local interface is used by default and works whenever the EJB is invoked within the same JVM context. Using the remote interface comes into play when the application is distributed across multiple JVMs.

Stateful sessions beans and singleton beans

The process for defining and consuming stateful @Session beans and @Singleton beans is the same as what you've seen for @Stateless beans. Remember the semantics:

  • Multiple session beans can be instantiated and used for the same client.
  • A singleton bean will exist only once for the entire application.

Thread safety and scheduling with singletons

Thread safety is built in when you're working with session beans, but both stateless and singleton beans can be accessed concurrently by multiple clients. Developers are responsible for thread safety when implementing these types of beans.

Singleton beans offer some support for thread safety via the @Lock annotation. You can use the @Lock annotation on singleton bean methods to set read/write privileges for each method. The two options are @Lock(LockType.READ) or @Lock(LockType.WRITE), which is the default.

Another useful feature of singleton beans is the ability to schedule tasks in a simple way, using the @Schedule annotation. Listing 5 shows how to schedule a task daily at noon.

Listing 5. @Schedule annotation example

 @Singleton public class MySchedulerBean { @Schedule(hour = "12") void doIt() { System.out.println("Hello at Noon!"); } } 

CDI vs EJB

CDI, or Context and Dependency Injection is a newer enterprise specification that some developers have proposed could replace EJB.

At a high level, CDI offers a general-purpose component framework, while EJB stands out for its richly featured, individual components. Whereas CDI uses dependency injection to define and reference any software component, EJB components are more formally defined, with each offering a specific set of capabilities out of the box. Both specs are planned for future development as part of Jakarta EE, where the question of whether CDI should replace EJB will eventually be resolved.

Conclusion

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

Этот рассказ «Что такое EJB? Эволюция Enterprise JavaBeans» был первоначально опубликован JavaWorld.