Jakarta Enterprise Beans - Jakarta Enterprise Beans

Jakarta Enterprise Beans ( EJB ; dawniej Enterprise JavaBeans) to jeden z kilku interfejsów API języka Java służących do modułowej budowy oprogramowania dla przedsiębiorstw . EJB to składnik oprogramowania po stronie serwera , który hermetyzuje logikę biznesową aplikacji. Kontener WWW EJB zapewnia środowisko wykonawcze dla składników oprogramowania związanych z siecią WWW, w tym zabezpieczenia komputerów , zarządzanie cyklem życia serwletów Java , przetwarzanie transakcji i inne usługi sieciowe . Specyfikacja EJB jest podzbiorem specyfikacji Java EE .

Specyfikacja

Specyfikacja EJB została pierwotnie opracowana w 1997 roku przez IBM, a później przyjęta przez Sun Microsystems (EJB 1.0 i 1.1) w 1999 roku i rozszerzona w ramach procesu społecznościowego Java jako JSR 19 (EJB 2.0), JSR 153 (EJB 2.1), JSR 220 (EJB 3.0), JSR 318 (EJB 3.1) i JSR 345 (EJB 3.2).

Specyfikacja EJB zapewnia standardowy sposób implementacji oprogramowania „biznesowego” po stronie serwera (zwanego również „ zapleczem ”), które zwykle znajduje się w aplikacjach korporacyjnych (w przeciwieństwie do oprogramowania interfejsu użytkownika „front-end” ). Takie oprogramowanie rozwiązuje te same typy problemów, a rozwiązania tych problemów są często wielokrotnie wdrażane przez programistów. Jakarta Enterprise Beans ma na celu rozwiązywanie typowych problemów, takich jak trwałość , integralność transakcyjna i bezpieczeństwo w standardowy sposób, pozostawiając programistom swobodę skoncentrowania się na poszczególnych częściach oprogramowania przedsiębiorstwa.

Ogólne obowiązki

Specyfikacja EJB szczegółowo opisuje, w jaki sposób serwer aplikacji zapewnia następujące obowiązki:

• Przetwarzanie transakcji
• Integracja z usługami trwałości oferowanymi przez Jakarta Persistence (JPA)
• Nadzór konkurencji
• Programowanie sterowane zdarzeniami przy użyciu Jakarta Messaging (JMS) i Jakarta Connectors (JCA)
• Wywołanie metody asynchronicznej
• Planowanie zadań
• Nazewnictwo i usługi katalogowe za pośrednictwem Java Naming and Directory Interface (JNDI)
• Komunikacja międzyprocesowa przy użyciu RMI-IIOP i usług internetowych
• Bezpieczeństwo ( JCE i JAAS )
• Wdrożenie z komponentów oprogramowania w serwerze aplikacji

Ponadto specyfikacja Jakarta Enterprise Beans definiuje role odgrywane przez kontener EJB i EJB, a także sposób wdrażania EJB w kontenerze. Należy zauważyć, że specyfikacja EJB nie wyszczególnia, w jaki sposób serwer aplikacji zapewnia trwałość (zadanie delegowane do specyfikacji JPA), ale zamiast tego szczegółowo opisuje, w jaki sposób logika biznesowa może łatwo zintegrować się z usługami trwałości oferowanymi przez serwer aplikacji.

Historia

Firmy odkryły, że użycie EJB do hermetyzacji logiki biznesowej przyniosło spadek wydajności. Dzieje się tak, ponieważ oryginalna specyfikacja zezwalała tylko na zdalne wywoływanie metod przez CORBA (i opcjonalnie inne protokoły), mimo że znaczna większość aplikacji biznesowych w rzeczywistości nie wymaga tej funkcji przetwarzania rozproszonego . Specyfikacja EJB 2.0 rozwiązała ten problem, dodając koncepcję lokalnych interfejsów, które mogą być wywoływane bezpośrednio bez uszczerbku dla wydajności przez aplikacje, które nie były rozproszone na wielu serwerach.

Specyfikacja EJB 3.0 ( JSR 220) była odejściem od swoich poprzedników, zgodnie z nowym paradygmatem lekkości. EJB 3.0 pokazuje wpływ Springa na wykorzystanie zwykłych obiektów Java oraz obsługę wstrzykiwania zależności w celu uproszczenia konfiguracji i integracji systemów heterogenicznych. Gavin King, twórca Hibernate, brał udział w procesie EJB 3.0 i jest jawnym orędownikiem tej technologii. Wiele funkcji pierwotnie zawartych w Hibernate zostało włączonych do Java Persistence API , które zostało zastąpione przez komponenty bean encji w EJB 3.0. Specyfikacja EJB 3.0 opiera się w dużej mierze na wykorzystaniu adnotacji (funkcja dodana do języka Java w wydaniu 5.0) i konwencji zamiast konfiguracji, aby umożliwić znacznie mniej rozwlekły styl kodowania. W związku z tym w praktyce EJB 3.0 jest znacznie lżejszy i stanowi prawie całkowicie nowy interfejs API, mający niewielkie podobieństwo do poprzednich specyfikacji EJB.

Przykład

Poniżej przedstawiono podstawowy przykład tego, jak EJB wygląda w kodzie:

@Stateless 
public class CustomerService { 
  

  private EntityManager entityManager; 
   
  public void addCustomer(Customer customer) { 
    entityManager.persist(customer); 
  } 
}

Powyższe definiuje klasę usług do utrwalania obiektu klienta (poprzez mapowanie O / R ). EJB zajmuje się zarządzaniem kontekstem trwałości, a metoda addCustomer () jest domyślnie transakcyjna i bezpieczna dla wątków. Jak wykazano, EJB koncentruje się wyłącznie na logice biznesowej i trwałości i nic nie wie o żadnej konkretnej prezentacji.

Taki EJB może być używany przez klasę np. W warstwie sieciowej w następujący sposób:

@Named	
@RequestScoped
public class CustomerBacking {
   @EJB 
   private CustomerService customerService;

   public String addCustomer(Customer customer) {
      customerService.addCustomer(customer);
      context.addMessage(...); // abbreviated for brevity
      return "customer_overview";
   }
}

Powyższe definiuje komponent bean zapasowy JavaServer Faces (JSF), w którym komponent EJB jest wstrzykiwany za pomocą adnotacji @EJB. Jego metoda addCustomer jest zwykle powiązana z jakimś składnikiem interfejsu użytkownika, takim jak przycisk. W przeciwieństwie do komponentu EJB zapasowy komponent bean nie zawiera żadnej logiki biznesowej ani kodu trwałości, ale przekazuje takie obawy komponentowi EJB. Fasola szparagowa wie o konkretnej prezentacji, o której EJB nie miał żadnej wiedzy.

Rodzaje fasoli przedsiębiorstwa

Pojemnik EJB zawiera dwa główne rodzaje ziaren:

• Session Beans, które mogą być „Stateful”, „Stateless” lub „Singleton” i mogą być dostępne za pośrednictwem interfejsu lokalnego (ta sama maszyna JVM) lub zdalnego (inna JVM) lub bezpośrednio bez interfejsu. W takim przypadku zastosowanie ma semantyka lokalna. Wszystkie komponenty bean sesji obsługują wykonywanie asynchroniczne dla wszystkich widoków (lokalny / zdalny / bez interfejsu).
• Message Driven Beans (MDB, znane również jako Message Beans). Bazy MDB obsługują również wykonywanie asynchroniczne, ale poprzez paradygmat przesyłania wiadomości.

Fasola sesyjna

Stanowe fasole sesji

Stateful Session Beans to obiekty biznesowe posiadające stan : to znaczy, że śledzą, z którym wywołującym klientem mają do czynienia podczas całej sesji, dzięki czemu dostęp do instancji bean jest ściśle ograniczony tylko do jednego klienta w danym momencie. Jeśli mimo to zostanie podjęta próba równoczesnego dostępu do jednego komponentu bean, kontener serializuje te żądania, ale za pośrednictwem adnotacji @AccessTimeout kontener może zamiast tego zgłosić wyjątek. Stan komponentu bean sesji stanowej może być utrwalany (pasywowany) automatycznie przez kontener, aby zwolnić pamięć po tym, jak klient nie uzyskiwał dostępu do komponentu bean przez pewien czas. Rozszerzony kontekst trwałości JPA jest wyraźnie obsługiwany przez Stateful Session Beans.

Przykłady

• Wyewidencjonowanie w sklepie internetowym może być obsługiwane przez stanowy komponent bean sesji, który wykorzystywałby swój stan do śledzenia, gdzie klient jest w procesie realizacji transakcji, prawdopodobnie blokując pozycje kupowane przez klienta (z punktu widzenia architektury systemu , byłoby mniej idealne, gdyby klient zarządzał tymi blokadami).

Bezpaństwowe fasole sesji

Bezstanowe komponenty Beans sesji to obiekty biznesowe, które nie mają skojarzonego z nimi stanu. Jednak dostęp do jednej instancji bean jest nadal ograniczony tylko do jednego klienta na raz, jednoczesny dostęp do bean jest zabroniony. W przypadku próby równoczesnego dostępu do pojedynczego komponentu bean kontener po prostu kieruje każde żądanie do innego wystąpienia. Dzięki temu bezstanowy komponent bean sesji jest automatycznie bezpieczny dla wątków. Zmienne instancji mogą być używane podczas pojedynczego wywołania metody od klienta do komponentu bean, ale nie ma gwarancji, że zawartość tych zmiennych instancji zostanie zachowana w różnych wywołaniach metod klienta . Wystąpienia komponentów bean Sesja bezstanowa są zazwyczaj łączone. Jeśli drugi klient uzyskuje dostęp do określonego komponentu bean zaraz po zakończeniu wywołania metody przez pierwszego klienta, może uzyskać tę samą instancję. Brak kosztów utrzymania konwersacji z klientem wywołującym sprawia, że ​​są one mniej zasobochłonne niż fasola stanowa.

Przykłady

• Wysyłanie wiadomości e-mail do działu obsługi klienta może być obsługiwane przez bezstanowy komponent bean, ponieważ jest to operacja jednorazowa, a nie część wieloetapowego procesu.
• Użytkownik witryny klikając pole „informuj mnie o przyszłych aktualizacjach” może wywołać asynchroniczną metodę komponentu bean sesji w celu dodania użytkownika do listy w bazie danych firmy (wywołanie to jest asynchroniczne, ponieważ użytkownik nie trzeba zaczekać na informację o jej sukcesie lub porażce).
• Pobieranie wielu niezależnych danych dla witryny internetowej, takich jak lista produktów i historia bieżącego użytkownika, również może być obsługiwane przez metody asynchroniczne komponentu bean sesji (te wywołania są asynchroniczne, ponieważ mogą być wykonywane równolegle w ten sposób, co potencjalnie zwiększa wydajność). W takim przypadku metoda asynchroniczna zwróci wystąpienie Future .

Fasola pojedynczej sesji

Singleton Session Beans to obiekty biznesowe mające globalny stan współużytkowany w JVM. Jednoczesny dostęp do jedynej instancji bean może być kontrolowany przez kontener (współbieżność zarządzana przez kontener, CMC) lub przez sam komponent bean (współbieżność zarządzana przez Bean, BMC). CMC można dostroić za pomocą adnotacji @Lock, która określa, czy dla wywołania metody będzie używana blokada odczytu, czy blokada zapisu. Ponadto, Singleton Session Beans może jawnie zażądać utworzenia wystąpienia podczas uruchamiania kontenera EJB, używając adnotacji @Startup.

Przykłady

• Ładowanie globalnego dziennego cennika, który będzie taki sam dla każdego użytkownika, można wykonać za pomocą pojedynczego komponentu bean sesji, ponieważ zapobiegnie to konieczności wykonywania przez aplikację tego samego zapytania do bazy danych w kółko ...

Fasola sterowana wiadomościami

Elementy beans sterowane komunikatami to obiekty biznesowe, których wykonanie jest wyzwalane przez komunikaty, a nie przez wywołania metod. Komponent Bean Message Driven jest używany między innymi w celu zapewnienia łatwej w użyciu abstrakcji wysokiego poziomu dla specyfikacji niższego poziomu JMS ( Java Message Service ). Może subskrybować kolejki komunikatów lub tematy komunikatów JMS, co zwykle odbywa się za pośrednictwem atrybutu ActivationConfig adnotacji @MessageDriven. Zostały dodane w EJB, aby umożliwić przetwarzanie sterowane zdarzeniami. W przeciwieństwie do ziaren sesyjnych, MDB nie ma widoku klienta (lokalny / zdalny / brak interfejsu), i. mi. klienci nie mogą wyszukiwać instancji MDB. MDB po prostu nasłuchuje każdej przychodzącej wiadomości, na przykład kolejki JMS lub tematu i przetwarza je automatycznie. Specyfikacja Java EE wymaga tylko obsługi JMS, ale komponent Beans Message Driven Beans może obsługiwać inne protokoły przesyłania komunikatów. Takie protokoły mogą być asynchroniczne, ale mogą być również synchroniczne. Ponieważ komponenty bean sesji mogą być również synchroniczne lub asynchroniczne, podstawową różnicą między komponentami bean opartymi na sesjach i komunikatami nie jest synchroniczność, ale różnica między wywoływaniem metod (obiektowych) a przesyłaniem wiadomości .

Przykłady

• Wysyłanie aktualizacji konfiguracji do wielu węzłów może odbywać się przez wysłanie wiadomości JMS do „tematu wiadomości” i może być obsługiwane przez komponent Bean sterowany komunikatem, który nasłuchuje tego tematu (używany jest tutaj paradygmat wiadomości, ponieważ nadawca nie musi znać liczba konsumentów, ich lokalizacja, a nawet dokładny rodzaj).
• Wysłanie zadania do klastra roboczego może być wykonane przez wysłanie komunikatu JMS do `` kolejki komunikatów '' i może być również obsługiwane przez komponent Bean Message Driven, ale tym razem nasłuchiwanie kolejki (używany jest paradygmat wiadomości i kolejka, ponieważ nadawca nie musi dbać o to, który pracownik wykona zadanie, ale musi mieć pewność, że zadanie jest wykonywane tylko raz).
• Przetwarzanie zdarzeń czasowych z harmonogramu Quartz może być obsługiwane przez moduł Message Driven Bean; kiedy wyzwalacz kwarcowy zostaje uruchomiony , MDB jest wywoływany automatycznie. Ponieważ Java EE domyślnie nie wie o Quartz, potrzebny byłby adapter zasobów JCA , a baza danych MDB byłaby opatrzona adnotacją z odniesieniem do tego.

Wykonanie

Komponenty EJB są wdrażane w kontenerze EJB, zwykle na serwerze aplikacji . Specyfikacja opisuje, w jaki sposób komponent EJB współdziała ze swoim kontenerem oraz jak kod klienta współdziała z kombinacją kontener / EJB. Klasy EJB używane przez aplikacje są zawarte w javax.ejb pakiecie. ( javax.ejb.spi Pakiet jest interfejsem dostawcy usług używanym tylko przez implementacje kontenerów EJB).

Klienci EJB nie tworzą instancji tych ziaren bezpośrednio za pośrednictwem nowego operatora Java, ale zamiast tego muszą uzyskać odwołanie za pośrednictwem kontenera EJB. To odwołanie zwykle nie jest odwołaniem do samego komponentu bean implementacji, ale do serwera proxy , który albo dynamicznie implementuje lokalny lub zdalny interfejs biznesowy, którego zażądał klient, albo dynamicznie implementuje podtyp rzeczywistego komponentu bean. Serwer proxy można następnie przesłać bezpośrednio do interfejsu lub komponentu bean. Mówi się, że klient ma „widok” na EJB, a interfejs lokalny, interfejs zdalny i sam typ komponentu bean odpowiadają odpowiednio widokowi lokalnemu, widokowi zdalnemu i widokowi bez interfejsu.

To proxy jest potrzebne, aby dać kontenerowi EJB możliwość przejrzystego świadczenia usług przekrojowych ( podobnych do AOP ) dla transakcji typu bean, takich jak transakcje, zabezpieczenia, przechwytywanie, wstrzykiwanie i zdalne przesyłanie. Na przykład klient wywołuje metodę na serwerze proxy, która najpierw rozpocznie transakcję za pomocą kontenera EJB, a następnie wywoła rzeczywistą metodę fasoli. Kiedy metoda bean powraca, proxy kończy transakcję (tj. Zatwierdzając ją lub dokonując wycofania) i przekazuje kontrolę z powrotem do klienta.

Kontener EJB jest odpowiedzialny za zapewnienie, że kod klienta ma wystarczające prawa dostępu do EJB. Aspekty bezpieczeństwa mogą być deklaratywnie stosowane do EJB poprzez adnotacje.

Transakcje

Kontenery EJB muszą obsługiwać zarówno transakcje ACID zarządzane przez kontener, jak i transakcje zarządzane przez komponent bean.

Transakcje zarządzane przez kontener (CMT) są domyślnie aktywne dla wywołań komponentów bean sesji. Oznacza to, że nie jest wymagana żadna jawna konfiguracja. To zachowanie może być strojone deklaratywnie przez komponent bean za pośrednictwem adnotacji, aw razie potrzeby taką konfigurację można później zastąpić w deskryptorze wdrażania. Tuning obejmuje wyłączenie transakcji dla całego ziarna lub określonych metod lub zażądanie alternatywnych strategii propagacji transakcji i rozpoczęcia lub dołączenia do transakcji. Takie strategie dotyczą głównie tego, co powinno się stać, jeśli transakcja jest lub nie jest już w toku w momencie wywołania fasoli. Obsługiwane są następujące odmiany:

Alternatywnie, fasola może również zadeklarować za pomocą adnotacji, że chce obsługiwać transakcje programowo za pośrednictwem interfejsu API JTA . Ten tryb działania nazywa się transakcjami zarządzanymi przez ziarno (BMT), ponieważ sam komponent bean obsługuje transakcję zamiast kontenera.

Wydarzenia

JMS ( Java Message Service ) służy do wysyłania komunikatów z komponentów bean do klientów, aby umożliwić klientom odbieranie komunikatów asynchronicznych z tych komponentów. Bazy MDB mogą służyć do asynchronicznego odbierania wiadomości od klientów przy użyciu kolejki JMS lub tematu.

Nazewnictwo i usługi katalogowe

Alternatywnie do wstrzykiwania, klienci komponentu EJB mogą uzyskać odwołanie do obiektu proxy komponentu bean sesji (kod pośredniczący EJB) za pomocą interfejsu Java Naming and Directory Interface (JNDI) . Tej alternatywy można użyć w przypadkach, gdy iniekcja nie jest dostępna, na przykład w kodzie niezarządzanym lub autonomicznych zdalnych klientach Java SE lub gdy konieczne jest programowe określenie, który komponent bean ma zostać uzyskany.

Nazwy JNDI dla komponentów bean sesji EJB są przypisywane przez kontener EJB za pomocą następującego schematu:

(wpisy w nawiasach kwadratowych oznaczają części opcjonalne)

Pojedyncze ziarno można uzyskać pod dowolną nazwą pasującą do powyższych wzorców, w zależności od „lokalizacji” klienta. Klienci w tym samym module co wymagany komponent bean mogą korzystać z zakresu modułu i większych zakresów, klienci w tej samej aplikacji co wymagany komponent bean mogą korzystać z zakresu aplikacji i wyższych itd.

Np. Kod działający w tym samym module co komponent bean CustomerService (zgodnie z przykładem pokazanym wcześniej w tym artykule) może użyć następującego kodu w celu uzyskania (lokalnego) odniesienia do niego:

CustomerServiceLocal customerService =
    (CustomerServiceLocal) new InitialContext().lookup("java:module/CustomerService");

Zdalne / rozproszone wykonanie

W przypadku komunikacji z klientem napisanym w języku programowania Java, komponent bean sesji może udostępniać widok zdalny za pośrednictwem interfejsu z adnotacjami @Remote. Pozwala to na wywoływanie tych komponentów bean z klientów w innych maszynach JVM, które same mogą znajdować się w innych (zdalnych) systemach. Z punktu widzenia kontenera EJB każdy kod w innej JVM jest zdalny.

Bezstanowe i singletonowe komponenty bean sesji mogą również udostępniać „widok klienta usługi sieciowej” do zdalnej komunikacji za pośrednictwem WSDL i SOAP lub zwykłego XML. Jest to zgodne ze specyfikacjami JAX-RPC i JAX-WS . Jednak obsługa JAX-RPC jest proponowana do usunięcia w przyszłości. Aby obsługiwać JAX-WS, komponent bean sesji jest opatrzony adnotacją @WebService oraz metodami, które mają być ujawniane zdalnie, za pomocą adnotacji @WebMethod.

Chociaż specyfikacja EJB w żaden sposób nie wspomina o ekspozycji jako usługach WWW zgodnych z REST i nie ma wyraźnego wsparcia dla tej formy komunikacji, specyfikacja JAX-RS wyraźnie obsługuje EJB. Zgodnie ze specyfikacją JAX-RS, bezstanowe i singletonowe komponenty bean sesji mogą być zasobami roota poprzez adnotację @Path, a metody biznesowe EJB mogą być mapowane na metody zasobów poprzez adnotacje @GET, @PUT, @POST i @DELETE. Nie liczy się to jednak jako „widok klienta usługi sieciowej”, który jest używany wyłącznie w przypadku JAX-WS i JAX-RPC.

Komunikacja za pośrednictwem usług sieciowych jest typowa dla klientów nie napisanych w języku programowania Java, ale jest również wygodna dla klientów Java, którzy mają problem z dostępem do serwera EJB przez zaporę ogniową. Ponadto klienci Java mogą wykorzystywać komunikację opartą na usługach internetowych, aby ominąć tajemnicze i źle zdefiniowane wymagania dotyczące tak zwanych „bibliotek-klientów”; zestaw plików jar, które klient Java musi mieć w swojej ścieżce klasy, aby komunikować się ze zdalnym serwerem EJB. Te biblioteki klienta mogą potencjalnie kolidować z bibliotekami, które klient może już mieć (na przykład, jeśli sam klient jest również pełnym serwerem Java EE) i uważa się, że taki konflikt jest bardzo trudny lub niemożliwy do rozwiązania.

Dziedzictwo

Interfejsy domowe i wymagany interfejs biznesowy

W EJB 2.1 i wcześniejszych każdy EJB musiał zapewnić klasę implementacji Java i dwa interfejsy Java. Kontener EJB utworzył instancje klasy implementacyjnej Java, aby zapewnić implementację EJB. Interfejsy Java były używane przez kod klienta EJB.

Wymagany deskryptor wdrażania

W przypadku EJB 2.1 i wcześniejszych specyfikacja EJB wymagała obecności deskryptora wdrażania. Było to konieczne w celu realizacji mechanizmu, który jest dozwolony EJB być rozmieszczone w sposób spójny niezależnie od platformy specyficzne EJB został wybrany. W deskryptorze wdrażania musiały zostać określone informacje o sposobie wdrażania komponentu bean (takie jak nazwa interfejsu domowego lub zdalnych, czy i jak przechowywać komponent bean w bazie danych itp.).

Deskryptor rozmieszczenia jest XML dokument posiadający wpis dla każdego EJB, który będzie wykorzystany. Ten dokument XML określa następujące informacje dla każdego EJB:

• Nazwa interfejsu domowego
• Klasa Java dla Bean (obiekt biznesowy)
• Interfejs Java dla interfejsu domowego
• Interfejs Java dla obiektu biznesowego
• Trwały sklep (tylko dla Entity Beans)
• Role i uprawnienia bezpieczeństwa
• Stanowe lub bezstanowe (w przypadku fasoli sesji)

Stare kontenery EJB od wielu dostawców wymagały więcej informacji dotyczących wdrażania, niż podano w specyfikacji EJB. Wymagałyby dodatkowych informacji w postaci oddzielnych plików XML lub innego formatu pliku konfiguracyjnego. Dostawca platformy EJB na ogół dostarczył własne narzędzia, które odczytywałyby ten deskryptor wdrażania i prawdopodobnie wygenerował zestaw klas, które implementowałyby przestarzałe interfejsy Home i Remote.

Od wersji EJB 3.0 ( JSR 220 ) deskryptor XML jest zastępowany adnotacjami Java ustawionymi w implementacji Enterprise Bean (na poziomie źródła), chociaż nadal możliwe jest użycie deskryptora XML zamiast (lub oprócz) adnotacji. Jeśli deskryptor XML i adnotacje są zastosowane do tego samego atrybutu w komponencie Enterprise Bean, definicja XML zastępuje odpowiednią adnotację na poziomie źródła, chociaż niektóre elementy XML mogą również być addytywne (np. Właściwość Activation-config-w XML z zostanie dodana inna nazwa niż już zdefiniowana za pomocą adnotacji @ActivationConfigProperty zamiast zastępowania wszystkich istniejących właściwości).

Odmiany pojemników

Począwszy od EJB 3.1, specyfikacja EJB definiuje dwa warianty kontenera EJB; pełna wersja i ograniczona wersja. Wersja ograniczona jest zgodna z odpowiednim podzbiorem specyfikacji o nazwie EJB 3.1 Lite i jest częścią profilu internetowego Java EE 6 (który sam jest podzbiorem pełnej specyfikacji Java EE 6).

EJB 3.1 Lite nie obsługuje następujących funkcji:

• Zdalne interfejsy
• Interoperacyjność RMI-IIOP
• Punkty końcowe usługi sieci Web JAX-WS
• Usługa licznika czasu EJB (@Schedule, @Timeout)
• Asynchroniczne wywołania komponentu bean sesji (@Asynchronous)
• Fasola sterowana wiadomościami

EJB 3.2 Lite wyklucza mniej funkcji. W szczególności nie wyklucza już @Asynchronous i @ Schedule / @ Timeout, ale w przypadku @Schedule nie obsługuje atrybutu „trwałego”, który obsługuje pełny pakiet EJB 3.2. Pełna lista wykluczonych dla EJB 3.2 Lite to:

• Zdalne interfejsy
• Interoperacyjność RMI-IIOP
• Punkty końcowe usługi sieci Web JAX-WS
• Trwałe liczniki czasu (atrybut „stały” w @Schedule)
• Fasola sterowana wiadomościami

Historia wersji

EJB 4.0, ostateczne wydanie (22.05.2020)

Jakarta Enterprise Beans 4.0 , jako część Jakarta EE 9, było wydaniem narzędzi, które głównie przenosiło nazwy pakietów API z pakietu najwyższego poziomu javax.ejb do pakietu najwyższego poziomu jakarta.ejb .

Inne zmiany obejmowały usunięcie przestarzałych interfejsów API, które nie miały sensu, aby przejść do nowego pakietu najwyższego poziomu, oraz usunięcie funkcji zależnych od funkcji, które zostały usunięte z Javy lub innego miejsca w Dżakarcie EE 9. Następujące interfejsy API zostały usunięte:

• metody, na java.security.Identity których opierają się metody , zostały usunięte z Java 14.
• metody opierające się na Jakarta XML RPC w celu odzwierciedlenia usunięcia XML RPC z platformy Jakarta EE 9.
• przestarzała EJBContext.getEnvironment() metoda.
• „Wsparcie dla rozproszonej interoperacyjności”, aby odzwierciedlić usunięcie CORBA z języka Java 11 i platformy Jakarta EE 9.

Inne drobne zmiany obejmują oznaczenie grupy API Enterprise Beans 2.x jako „Opcjonalna” i zapewnienie Schedule powtarzalności adnotacji.

EJB 3.2.6, ostateczne wydanie (23.08.2019)

Jakarta Enterprise Beans 3.2 , jako część Jakarta EE 8 i mimo że nadal używa skrótu „EJB”, ten zestaw interfejsów API został oficjalnie przemianowany na „Jakarta Enterprise Beans” przez Eclipse Foundation, aby nie kroczyć po Oracle „Java " znak towarowy.

EJB 3.2, wersja ostateczna (28.05.2013)

JSR 345 . Enterprise JavaBeans 3.2 była stosunkowo niewielką wersją, która zawierała głównie wyjaśnienia specyfikacji i zniosła pewne ograniczenia narzucone przez specyfikację, ale z czasem wydawało się, że nie służą one żadnemu celowi. Wymagano również, aby kilka istniejących pełnych funkcji EJB znajdowało się w EJB 3 lite, a funkcjonalność, która była proponowana do przycinania w EJB 3.1, została faktycznie przycięta (stała się opcjonalna).

Dodano następujące funkcje:

• Pasywację pełnostanowego komponentu bean sesji można dezaktywować za pomocą atrybutu w adnotacji @Stateful (passivationCapable = false)
• TimerService może pobrać wszystkie aktywne zegary w tym samym module EJB (poprzednio mógł pobierać tylko timery dla komponentu bean, w którym wywołano TimerService)
• Metody cyklu życia (np. @PostConstruct) mogą być transakcyjne dla beanów sesji stanowych przy użyciu istniejącej adnotacji @TransactionAttribute
• Interfejs z możliwością automatycznego zamykania zaimplementowany przez kontener z możliwością osadzania

EJB 3.1, ostateczne wydanie (2009-12-10)

JSR 318 . Celem specyfikacji Enterprise JavaBeans 3.1 jest dalsze uproszczenie architektury EJB poprzez zmniejszenie jej złożoności z punktu widzenia programisty, przy jednoczesnym dodaniu nowej funkcjonalności w odpowiedzi na potrzeby społeczności:

• Widok lokalny bez interfejsu (widok bez interfejsu)
• .war opakowanie komponentów EJB
• EJB Lite: definicja podzbioru EJB
• Przenośne globalne nazwy JNDI EJB
• Singletony (Singleton Session Beans)
• Zdarzenia inicjowania i zamykania aplikacji
• Udoskonalenia usługi licznika czasu EJB
• Prosta asynchroniczna (@ asynchroniczna dla ziaren sesji)

EJB 3.0, ostateczne wydanie (2006-05-11)

JSR 220 - Główne zmiany : ta wersja znacznie ułatwiła pisanie EJB, używając „adnotacji” zamiast złożonych „deskryptorów wdrażania” używanych w wersji 2.x. Korzystanie z interfejsów domowych i zdalnych oraz pliku ejb-jar.xml również nie były już wymagane w tej wersji, ponieważ zostały zastąpione interfejsem biznesowym i komponentem bean implementującym interfejs.

EJB 2.1, wersja ostateczna (24.11.2003)

JSR 153 - Główne zmiany :

• Obsługa usług sieci Web (nowe): bezstanowe sesyjne komponenty bean mogą być wywoływane przez SOAP / HTTP . Ponadto EJB może łatwo uzyskać dostęp do usługi sieci Web, korzystając z nowego odniesienia do usługi.
• Usługa licznika czasu EJB (nowa): oparty na zdarzeniach mechanizm wywoływania komponentów EJB w określonych godzinach.
• Fasola sterowana wiadomościami akceptuje wiadomości ze źródeł innych niż JMS .
• Dodano miejsca docelowe wiadomości (ta sama idea, co w przypadku odwołań do EJB, odwołań do zasobów itp.).
• Dodatki języka zapytań EJB (EJB-QL): ORDER BY, AVG, MIN, MAX, SUM, COUNT i MOD.
• Schemat XML służy do określania deskryptorów wdrażania, zastępuje DTD

EJB 2.0, ostateczne wydanie (2001-08-22)

JSR 19 - Główne zmiany : Ogólne cele :

• Standardowa architektura komponentów do tworzenia rozproszonych, zorientowanych obiektowo aplikacji biznesowych w języku Java .
• Umożliwiaj tworzenie aplikacji rozproszonych, łącząc komponenty opracowane przy użyciu narzędzi różnych dostawców .
• Ułatw pisanie aplikacji (dla przedsiębiorstw): deweloperzy aplikacji nie będą musieli rozumieć szczegółów dotyczących transakcji i stanu niskiego poziomu, wielowątkowości, buforowania połączeń i innych złożonych niskopoziomowych interfejsów API.
• Będzie zgodny z filozofią Java „Napisz raz, uruchom gdziekolwiek” . Komponent korporacyjny Bean można stworzyć raz, a następnie wdrożyć na wielu platformach bez ponownej kompilacji lub modyfikacji kodu źródłowego.
• Zajmij się aspektami rozwoju, wdrażania i środowiska wykonawczego w cyklu życia aplikacji korporacyjnej.
• Zdefiniuj umowy, które umożliwią narzędziom wielu dostawców opracowywanie i wdrażanie komponentów, które mogą współpracować w czasie wykonywania.
• Bądź kompatybilny z istniejącymi platformami serwerowymi. Dostawcy będą mogli rozszerzyć swoje istniejące produkty o obsługę EJB.
• Bądź kompatybilny z innymi API Java .
• Zapewnia interoperacyjność między komponentami Enterprise Beans i Java EE, a także aplikacjami w języku programowania innym niż Java.
• Bądź kompatybilny z protokołami CORBA (RMI-IIOP).

EJB 1.1, ostateczne wydanie (17.12.1999)

Główne zmiany :

• Deskryptory wdrażania XML
• Domyślne konteksty JNDI
• RMI ponad IIOP
• Bezpieczeństwo - oparte na rolach, a nie na metodzie
• Obsługa Entity Bean - obowiązkowa, nie opcjonalna

Cele w wersji 1.1:

• Zapewnij lepszą obsługę montażu i wdrażania aplikacji.
• Należy bardziej szczegółowo określić obowiązki poszczególnych ról EJB.

EJB 1.0 (24.03.1998)

Ogłoszone podczas JavaOne 1998 , trzeciej konferencji Sun dla programistów Java (24-27 marca) Cele wydania 1.0:

• Zdefiniowano odrębne „Role EJB”, które są przyjmowane przez architekturę komponentów.
• Zdefiniowano widok klienta na fasolki korporacyjne.
• Zdefiniowano widok programisty Enterprise Bean.
• Zdefiniowano obowiązki dostawcy EJB Container i serwera; razem tworzą one system, który wspiera wdrażanie i wykonywanie korporacyjnych fasoli.

Bibliografia

Zewnętrzne linki

• Oficjalna strona internetowa
• Javadocs interfejsu API Java EE 8
• Dokumenty Javadocs interfejsu API EJB 3.0
• Specyfikacja EJB 3.0
• Samouczek Sun's EJB 3.0
• Glosariusz 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)
• „Working with Message-Driven Beans” z EJB3 w akcji, wydanie drugie
• Klient wywołuje EJB