Co to jest EJB? Ewolucja Enterprise JavaBeans

Enterprise JavaBeans (EJB) to specyfikacja do tworzenia dużych, rozproszonych aplikacji biznesowych na platformie Java. EJB 1.0 został wydany w 1998 roku. Najnowsza wersja, EJB 3.2.3, została przyjęta do włączenia do Dżakarty EE, gdzie zostanie przemianowana na Jakarta Enterprise Beans.

Architektura EJB

Architektura EJB składa się z trzech głównych komponentów: korporacyjnych komponentów bean (EJB), kontenera EJB i serwera aplikacji Java. Komponenty EJB działają w kontenerze EJB, a kontener EJB w serwerze aplikacji Java.

Istnieją dwa rodzaje EJB - fasola sesji i fasola oparta na komunikatach:

  • Fasole sesji są wywoływane przez klienta i programowo udostępniają klientowi funkcje przedsiębiorstwa, takie jak transakcje i zarządzanie zasobami.
  • Komponenty bean sterowane wiadomościami również hermetyzują i dostarczają funkcje korporacyjne, ale są asynchroniczne i sterowane zdarzeniami. Fasola sterowana wiadomościami nasłuchuje zdarzeń i reaguje na nie, a klient nie może ich wywoływać.

Fasolki encji, które były używane do zapewniania trwałości w systemie EJB, zostały zastąpione przez interfejs API Java Persistence. Czytaj dalej, aby dowiedzieć się więcej o ziarnach sesyjnych i ziarnach sesyjnych.

EJB vs JavaBeans

Enterprise JavaBeans był pierwszym opartym na komponentach modelem programistycznym dla Java EE. EJB jest podobny do JavaBeans, ponieważ jest oparty na komponentach, ale na tym podobieństwo się kończy:

  • JavaBeans to klasa Java, która obudowuje wiele obiektów i spełnia pewnych konwencji. JavaBeans są używane głównie do programowania po stronie klienta.
  • Fasola przedsiębiorstw (EJB) jest klasą Java przepojona konkretnych możliwości po stronie serwera. Fasola korporacyjna jest używana w aplikacjach i systemach biznesowych na dużą skalę.

Fasola sesyjna

Sesja fasoli jest najbardziej ogólny typ fasoli przedsiębiorstw, reprezentujących klocek funkcjonalności biznesowych, które mogą być wywoływane przez klienta. Klientem w tym przypadku może być inna klasa w lokalnej JVM lub zdalne wywołanie.

Kontener EJB zarządza cyklem życia komponentu bean sesji, który jest określany przez stan komponentu bean:

  • Bezstanowe komponenty bean sesji są podobne do zakresu żądania w Java Servlet API. Bezstanowe ziarna sesji zawierają fragment funkcji wywoływalnych, ale poza tym są bezstanowe.
  • Stanowe komponenty bean sesji są powiązane tylko z jednym klientem i dołączane do trwającej sesji tego klienta. Stanowe komponenty bean sesji działają podobnie do zakresu sesji w Servlet API.
  • Pojedyncze ziarna bean są podobne do zakresu aplikacji w Servlet API. Jeden komponent bean sesji istnieje tylko raz dla każdego klienta.

Bezpieczeństwo nici dzięki fasolom sesyjnym

Stanowy komponent bean sesji może być dostępny tylko dla jednego klienta na raz, więc podczas pracy z tym typem ziarna gwarantowane jest bezpieczeństwo wątków. Bezstanowe ziarna sesji i pojedyncze ziarna są bardziej elastyczne, umożliwiając jednoczesne połączenia, którymi musi zarządzać programista. Jesteś odpowiedzialny za bezpieczeństwo nici podczas pracy z tego typu fasolami.

Fasola sterowana wiadomościami

Elementy bean sterowane wiadomościami (MDB) są wywoływane za pośrednictwem komunikatów JMS (Java Message Service). JMS działa jak rozproszony wzorzec polecenia, w którym komponent bean sterowany komunikatami działa jako nasłuchiwanie polecenia. Gdy wiadomość dotrze do tematu lub kolejki, wywoływany jest komponent bean sterowany komunikatem, który nasłuchuje w tym temacie.

Fasola sterowana komunikatami nie jest tak powszechnie używana, jak fasola sesji, ale ma duże możliwości. Będąc asynchronicznymi i sterowanymi zdarzeniami, są szczególnie przydatne w przypadku długotrwałych zadań, w których ważne jest oszczędzanie zasobów.

Najprostsza architektura składałaby się z aplikacji EJB oraz jej kontenera i serwera, które są koordynowane z usługą komunikatów przetwarzającą MDB. W środowisku produkcyjnym Twoja architektura prawdopodobnie zawierałaby trzeci komponent przeznaczony do wykorzystania ziarna. W fazie rozwoju wszystkie te komponenty mogą działać na tym samym komputerze lokalnym.

Rysunek 1 przedstawia typową architekturę sterowaną zdarzeniami z komponentami typu beanie sterowanymi komunikatami.

Matthew Tyson

Praca z fasolami sterowanymi wiadomościami jest bardziej skomplikowana niż korzystanie z komponentów bean sesyjnych. W środowisku sterowanym zdarzeniami zazwyczaj potrzebujesz brokera komunikatów, takiego jak ActiveMQ.

Podczas gdy komponenty bean sesji są prostsze, a przez to częściej używane w EJB, architektury sterowane zdarzeniami stały się popularne, zwłaszcza wraz z eksplozją mikrousług. 

Adnotacje EJB

Definiowanie i używanie komponentów bean korporacyjnych było punktem spornym dla wielu programistów do czasu wprowadzenia EJB 3.0, który wprowadził adnotacje do specyfikacji EJB. Adnotacje bardzo ułatwiają konfigurację komponentów bean korporacyjnych dla szerokiego zakresu funkcji dostępnych w Java EE. Czytaj dalej, aby zacząć korzystać z adnotacji EJB.

@Stateless: Zdefiniuj bezstanowy komponent bean sesji

Aby wyznaczyć klasę jako bezstanowy komponent bean sesji, użyj javax.ejb.Statelessadnotacji, jak pokazano na listingu 1.

Listing 1. Przykład adnotacji @Stateless

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

Ten bezstanowy komponent bean zawiera prosty podpis, który nie przyjmuje argumentów i zwraca ciąg. Nie daj się jednak zwieść prostocie: ta fasola może zrobić wszystko, czego potrzebujesz, w tym interakcję z innymi ziarnami, usługami lub warstwą danych aplikacji.

@EJB: Konsumuj bezstanowy komponent bean sesji

Po zdefiniowaniu komponentu bean sesji używanie go jest bardzo proste:

Listing 2. Przykład adnotacji @EJB

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

Tutaj wstrzykujemy bezstanowy komponent bean do serwletu, a następnie jest on dostępny do użycia. Zwróć uwagę, jak fasola jest identyfikowana pod @EJBadnotacją. Oznaczenie „bezstanowe” oznacza, że ​​ten komponent bean nie będzie śledził klienta. Ponieważ jest bezstanowy, wiemy również, że ten komponent bean podlega wątkowaniu, jeśli wykonuje jakąkolwiek pracę poza wywołaną metodą.

@Remote: Zdefiniuj zdalny interfejs EJB

W powyższych przykładach założyłem, że klient EJB i EJB działają w tej samej JVM. Jeśli komponent bean przedsiębiorstwa i jego klient działają w oddzielnych maszynach JVM, komponent EJB musi zdefiniować @Remoteinterfejs. W takim przypadku to do Ciebie należy zdefiniowanie i zaimplementowanie interfejsu, jak pokazano na Listingu 3.

Listing 3. Przykład adnotacji @Remote

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

Zdalny interfejs jest wysyłany do klienta w celu wywołania. Wywołania do niego będą następnie realizowane przez implementację serwera EJB po stronie serwera. MyStatelessBeanPrzykład listingu 4 narzędzi zdalnego interfejsu.

Listing 4. Implementacja zdalnego interfejsu

 public class MyStatelessBean implements MyStatelessEjbRemote{ ... } 

Zdalny interfejs jest implementowany tak jak normalna klasa implementująca interfejs. Jako konsument zdalnego komponentu EJB aplikacja kliencka musi mieć dostęp do definicji klasy dla zdalnego interfejsu. Definicję klasy dla interfejsu zdalnego można spakować jako plik JAR zależności.

Interfejs lokalny a zdalny

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 to pierwsza specyfikacja oferująca łatwy sposób enkapsulacji i ponownego wykorzystania logiki biznesowej w korporacyjnych aplikacjach Java. Daleki od starego potwora wagi ciężkiej, EJB jest dziś szczupłą strukturą opartą na adnotacjach, która umożliwia dostęp do szerokiej gamy funkcji korporacyjnych od razu po wyjęciu z pudełka. Zastanów się nad rozwiązaniem EJB następnym razem, gdy zostaniesz poproszony o szybkie uruchomienie rozproszonej, skalowalnej aplikacji biznesowej. Możesz być mile zaskoczony.

Ta historia „Co to jest EJB? Ewolucja Enterprise JavaBeans” została pierwotnie opublikowana przez JavaWorld.