Standard EJB 3.0 w znaczący sposób różni się od standardu EJB 2.1. Należy być świadomym tych różnic podczas tworzenia aplikacji z powiązaniami EJB opartymi na wersji 3.0 lub późniejszej.
Standard EJB 3.0 jest ponownie przemyślaną wersją komponentów EJB (Enterprise JavaBeans), opartą na analizie coraz większych problemów, jakie programiści napotkali podczas tworzenia aplikacji przy użyciu standardu EJB. W niniejszej sekcji omawiane są wyzwania, które rozwiązuje standard EJB 3.0, różnice między standardem EJB 3.0 i jego poprzednikiem - EJB 2.1 oraz zmiany w interfejsie lokalnym komponentów EJB 3.0.
Architektura EJB została zaprojektowana z myślą o aplikacjach zawierających rozproszone komponenty. Zanim wprowadzono standard EJB, najbardziej znanym standardem obsługującym obiekty rozproszone była architektura CORBA (Common Object Request Broker Architecture). Architektura ta jednak stała się zbyt złożona i jest postrzegana jako trudna do stosowania. Podczas rozwoju standardu EJB był on rozszerzany o wiele opcji i uzyskał reputację zbyt złożonego do używania przez programistów. Przed wprowadzeniem standardu EJB 3.0 programiści zgłosili następujące uwagi na temat komponentów EJB:
Przez ponad dekadę komponenty EJB były podstawowym elementem używanym podczas tworzenia rozbudowanych aplikacji pisanych w języku Java. W tym czasie standard EJB rozwijał się i stał się standardową platformą do programowania, wdrażania i wykonywania rozproszonych komponentów używanych w środowiskach wielu użytkowników. Platforma zawierała usługi do monitorowania cyklu życia, realizacji współbieżności, zarządzania zasobami, obsługi transakcji, zabezpieczeń i trwałości.
W czasie, kiedy dostępna stała się wersja 2.1 architektury EJB, następujące standardowe opcje były dostępne dla programistów pracujących z komponentami EJB: komponenty bean sesji dla danych nietrwałych i komponenty bean obiektów dla danych trwałych, deskryptor wdrażania XML, lokalny lub główny interfejs (mimo że dostęp do niego mogły mieć tylko klienty wewnątrz kontenera Java 2 Platform Enterprise Edition), komponenty bean sterowane komunikatami dla komunikatów asynchronicznych oraz obsługa usług WWW, które ujawniały punkt końcowy tak, aby w razie potrzeby możliwe było wywołanie komponentu EJB. Wynikiem wprowadzenia tych opcji był jednak fakt, że programiści musieli napisać dużą ilość kodu, aby utworzyć komponent EJB. Musieli na przykład zakodować interfejs główny, interfejs komponentu, klasę komponentu bean oraz deskryptor wdrażania, który mógł być złożony dla komponentu bean obiektu. Musieli również kodować metody na potrzeby zarządzania cyklem życia, nawet jeśli nie były one wywoływane.
Standard EJB 3.0 wprowadził następujące główne zmiany, które doprowadziły do uproszczenia modelu programowania:
Standard EJB 3.0 jest formalnie zdefiniowany w dokumencie JSR 220: Enterprise JavaBeans 3.0. Ta specyfikacja JSR ma ponad 800 stron i jest podzielona na trzy sekcje: sekcja dotycząca interfejsu API trwałości języka Java definiuje strukturę trwałości i omawia obiekty, sekcja dotycząca podstawowych kontraktów i wymagań komponentów EJB opisuje komponenty bean sterowane komunikatami i komponenty bean sesji, a sekcja dotycząca uproszczonego interfejsu API komponentów EJB zawiera przegląd modelu programistycznego EJB.
W związku z kwestiami poruszonymi we wcześniejszych sekcjach standard EJB 3.0 doprowadził do znacznego uproszczenia specyfikacji EJB. Dotyczy to w szczególności komponentów EJB z interfejsem lokalnym (czyli komponentów EJB, które będą uruchamiane w tej samej maszynie JVM co klient). Poniżej przedstawiono dowód na uproszczenie. Następujące wiersze kodu generują interfejs EJB.
package ejbeasy;
public interface EasyEJBClaim {
public void stateClaim(String myName);
}Poniższe wiersze tworzą implementację bezstanowego komponentu bean sesji.
package ejbeasy;
import javax.ejb.Stateless;
@Stateless
public class EasyEJBClaimBean implements EasyEJBClaim {
public void stateClaim(String myName){
System.out.println(myName + "mówi: Czy można jeszcze prościej?");
}
}Interfejs jest interfejsem POJO, a klasa komponentu bean jest klasą POJO. Adnotacja @Stateless przekształca klasę POJO w bezstanowy komponent EJB.