Jakarta Enterprise Beans - Jakarta Enterprise Beans

Inte att förväxla med JavaBeans .

Jakarta Enterprise Beans ( EJB ; tidigare Enterprise JavaBeans) är en av flera Java API: er för modulär konstruktion av företagsprogramvara . EJB är en mjukvarukomponent på serversidan som inkapslar en applikations affärslogik . En EJB -webbcontainer ger en runtime-miljö för webbrelaterade programkomponenter, inklusive datasäkerhet , Java-servlets livscykelhantering , transaktionsbehandling och andra webbtjänster . EJB-specifikationen är en delmängd av Java EE- specifikationen.

Specifikation

EJB-specifikationen utvecklades ursprungligen 1997 av IBM och antogs senare av Sun Microsystems (EJB 1.0 och 1.1) 1999 och förbättrades under Java Community Process som JSR 19 (EJB 2.0), JSR 153 (EJB 2.1), JSR 220 (EJB 3.0), JSR 318 (EJB 3.1) och JSR 345 (EJB 3.2).

EJB-specifikationen tillhandahåller ett standardiserat sätt att implementera "business" -programvaran på serversidan (även kallad " back-end ") som vanligtvis finns i företagsapplikationer (i motsats till "front-end" -program för användargränssnitt ). Sådan programvara behandlar samma typer av problem, och lösningar på dessa problem implementeras ofta upprepade gånger av programmerare. Jakarta Enterprise Beans är avsedd att hantera sådana vanliga problem som uthållighet , transaktionsintegritet och säkerhet på ett standardiserat sätt, vilket gör det möjligt för programmerare att koncentrera sig på de specifika delarna av företagets programvara som finns.

Allmänt ansvar

EJB-specifikationen beskriver hur en applikationsserver tillhandahåller följande ansvarsområden:

Dessutom definierar Jakarta Enterprise Beans-specifikationen de roller som spelas av EJB-containern och EJB: erna samt hur man distribuerar EJB: erna i en container. Observera att EJB-specifikationen inte beskriver hur en applikationsserver tillhandahåller uthållighet (en uppgift delegerad till JPA-specifikationen), utan i stället beskriver hur affärslogik enkelt kan integreras med de uthållighetstjänster som applikationsservern erbjuder.

Historia

Företag fann att användning av EJB: er för att inkapsla affärslogik medförde en prestationsstraff. Detta beror på att den ursprungliga specifikationen endast tillåts för fjärrmetodanrop genom CORBA (och eventuellt andra protokoll), även om den stora majoriteten av affärsapplikationer faktiskt inte kräver denna distribuerade datorfunktion . EJB 2.0-specifikationen tog upp denna oro genom att lägga till konceptet för lokala gränssnitt som kunde anropas direkt utan prestationsstraff av applikationer som inte distribuerades över flera servrar.

EJB 3.0-specifikationen ( JSR 220) var en avvikelse från sina föregångare, efter ett nytt lättviktsparadigm. EJB 3.0 visar ett inflytande från Spring i dess användning av vanliga Java-objekt, och dess stöd för beroendeinjektion för att förenkla konfiguration och integration av heterogena system. Gavin King, skaparen av Hibernate, deltog i EJB 3.0-processen och är en uttalad förespråkare för tekniken. Många funktioner som ursprungligen var i viloläge införlivades i Java Persistence API , ersättning för enhetsbönor i EJB 3.0. EJB 3.0-specifikationen är starkt beroende av användningen av anteckningar (en funktion som läggs till Java-språket med dess 5.0-version) och konvention över konfiguration för att möjliggöra en mycket mindre detaljerad kodningsstil. I praktiken är EJB 3.0 därför mycket lättare och nästan ett helt nytt API, som har liten likhet med tidigare EJB-specifikationer.

Exempel

Följande visar ett grundläggande exempel på hur en EJB ser ut i kod: 

@Stateless 
public class CustomerService { 
  

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

Ovanstående definierar en tjänstklass för bestående ett kundobjekt (via O / R-mappning ). EJB tar hand om hanteringen av uthållighetskontexten och addCustomer () -metoden är transaktionell och trådsäker som standard. Som visat fokuserar EJB bara på affärslogik och uthållighet och vet ingenting om någon särskild presentation.

En sådan EJB kan användas av en klass i t.ex. webblagret enligt följande: 

@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";
   }
}

Ovanstående definierar en JavaServer Faces (JSF) backing bean där EJB injiceras med @EJB-anteckningen. Dess addCustomer-metod är vanligtvis bunden till någon UI-komponent, till exempel en knapp. I motsats till EJB innehåller stödbönan ingen affärslogik eller uthållighetskod, men delegerar sådana farhågor till EJB. Backbönan känner till en viss presentation, som EJB inte hade någon kunskap om.

Typer av Enterprise Beans

En EJB-behållare rymmer två huvudtyper av bönor:

  • Sessionsbönor som kan vara antingen "Stateful", "Stateless" eller "Singleton" och kan nås antingen via ett lokalt (samma JVM) eller Remote (olika JVM) eller direkt utan ett gränssnitt, i vilket fall lokal semantik gäller. Alla session bönor stöder asynkron körning för alla vyer (lokalt / fjärr / inget gränssnitt).
  • Message Driven Beans (MDBs, även känd som Message Beans). MDB stöder också asynkron körning, men via ett meddelandeparadigm.

Sessionsbönor

Stateful Session Beans

Se även: Konversationstillstånd (Java EE)

Stateful Session Beans är affärsobjekt med tillstånd : det vill säga de håller reda på vilken samtalsklient de har att göra med under en session och därmed är tillgången till beaninstansen strikt begränsad till endast en klient åt gången. Om samtidigt åtkomst till en enda böna försöks ändå serierar behållaren dessa förfrågningar, men via @AccessTimeout-anteckningen kan behållaren istället kasta ett undantag. Stateful session beans-tillstånd kan bestå (passiveras) automatiskt av behållaren för att frigöra minne efter att klienten inte har nått bönan på en tid. JPA: s utökade uthållighetskontext stöds uttryckligen av Stateful Session Beans.

Exempel
  • Utcheckning i en webbutik kan hanteras av en stateful session bean som skulle använda sitt tillstånd för att hålla reda på var kunden befinner sig i kassan, eventuellt hålla lås på de varor kunden köper (ur systemarkitekturens synvinkel , skulle det vara mindre idealt att låta klienten hantera dessa lås).

Stateless Session Beans

Stateless Session Beans är affärsobjekt som inte har tillstånd kopplat till dem. Åtkomst till en enda böninstans är dock fortfarande begränsad till endast en klient åt gången, samtidigt är åtkomst till bönan förbjuden. Om du försöker få åtkomst till en enda böna, dirigerar behållaren helt enkelt varje begäran till en annan instans. Detta gör en statslös sessionböna automatiskt trådsäker. Instansvariabler kan användas under en enda metod samtal från en klient till bönor, men innehållet i dessa instansvariabler är inte garanterade att bevaras mellan olika klientmetod samtal. Instanser av statslösa sessionbönor slås vanligtvis samman. Om en andra klient får åtkomst till en viss bön direkt efter att en metodanrop på den som en första klient har avslutat kan den få samma instans. Bristen på allmänna kostnader för att hålla en konversation med den anropande klienten gör dem mindre resurskrävande än stateful bönor.

Exempel
  • Skicka ett e-postmeddelande till kundsupport kan hanteras av en statslös böna, eftersom detta är en engångsoperation och inte ingår i en flerstegsprocess.
  • En användare av en webbplats som klickar på rutan "Håll mig informerad om framtida uppdateringar" kan utlösa ett samtal till en asynkron metod för sessionbönan för att lägga till användaren i en lista i företagets databas (detta samtal är asynkront eftersom användaren inte måste vänta på att få information om dess framgång eller misslyckande).
  • Att hämta flera oberoende datadelar för en webbplats, som en produktlista och den nuvarande användarens historia, kan också hanteras med asynkrona metoder för en sessionböna (dessa samtal är asynkrona eftersom de kan utföras parallellt på det sättet, vilket potentiellt ökar prestanda). I det här fallet returnerar den asynkrona metoden en framtida instans.

Singleton Session Beans

Singleton Session Beans är affärsobjekt som har ett globalt delat tillstånd inom en JVM. Samtidig åtkomst till den enda böninstansen kan styras av behållaren (Container-managed concurrency, CMC) eller av själva bean (Bean-managed concurrency, BMC). CMC kan ställas in med @Lock-anteckningen, som anger om ett läslås eller ett skrivlås ska användas för ett metodsamtal. Dessutom kan Singleton Session Beans uttryckligen begära att bli omedelbar när EJB-behållaren startar med @Startup-anteckningen.

Exempel
  • Att ladda en global daglig prislista som är densamma för varje användare kan göras med en singleton session bean, eftersom detta kommer att förhindra att applikationen behöver göra samma fråga till en databas om och om igen ...

Meddelandestyrda bönor

Message Driven Beans är affärsobjekt vars körning utlöses av meddelanden istället för med metodanrop. The Message Driven Bean används bland annat för att tillhandahålla en högnivåvänlig abstraktion för den lägre JMS-specifikationen ( Java Message Service ). Det kan prenumerera på JMS-meddelandeköer eller meddelandeämnen, vilket vanligtvis sker via attributet activityConfig i kommentaren @MessageDriven. De lades till i EJB för att möjliggöra händelsestyrd bearbetning. Till skillnad från sessionbönor har en MDB inte en klientvy (Local / Remote / No-interface), dvs. e. klienter kan inte slå upp en MDB-instans. En MDB lyssnar bara på alla inkommande meddelanden på till exempel en JMS-kö eller ett ämne och bearbetar dem automatiskt. Endast JMS-stöd krävs av Java EE-specifikationen, men Message Driven Beans kan stödja andra meddelandeprotokoll. Sådana protokoll kan vara asynkrona men kan också vara synkrona. Eftersom sessionsbönor också kan vara synkrona eller asynkrona, är den primära skillnaden mellan session- och meddelandestyrda bönor inte synkroniteten, utan skillnaden mellan (objektorienterad) metod samtal och meddelanden .

Exempel
  • Skicka en konfigurationsuppdatering till flera noder kan göras genom att skicka ett JMS-meddelande till ett "meddelandeämne" och kan hanteras av en Message Driven Bean som lyssnar på detta ämne (meddelandeparadigmet används här eftersom avsändaren inte behöver veta antal konsumenter, deras plats eller till och med deras exakta typ).
  • Skicka ett jobb till ett arbetskluster kan göras genom att skicka ett JMS-meddelande till en "meddelandekö" och kan också hanteras av en Message Driven Bean, men den här gången lyssnar du på en kö (meddelandeparadigmet och kön används, eftersom avsändaren behöver inte bry sig om vilken arbetare som utför jobbet, men den behöver försäkran om att ett jobb bara utförs en gång).
  • Bearbetning av tidshändelser från Quartz-schemaläggaren kan hanteras av en Message Driven Bean; när en kvartsutlösare utlöses , anropas MDB automatiskt. Eftersom Java EE inte känner till Quartz som standard skulle en JCA- resursadapter behövas och MDB skulle antecknas med hänvisning till detta.

Avrättning

EJB: er distribueras i en EJB-behållare, vanligtvis inom en applikationsserver . Specifikationen beskriver hur en EJB interagerar med sin behållare och hur klientkoden interagerar med behållaren / EJB-kombinationen. EJB-klasserna som används av applikationer ingår i javax.ejb paketet. ( javax.ejb.spi Paketet är ett tjänsteleverantörsgränssnitt som endast används av EJB-containerimplementeringar.)

Klienter för EJB: n instanserar inte dessa bönor direkt via Java: s nya operatör, utan måste istället få en referens via EJB-behållaren. Den här referensen är vanligtvis inte en referens till själva implementeringsbönan utan till en proxy , som antingen dynamiskt implementerar det lokala eller fjärranslutna affärsgränssnittet som klienten begärde eller dynamiskt implementerar en undertyp av den faktiska bönan. Proxy kan sedan gjutas direkt till gränssnittet eller bönan. En klient sägs ha en 'vy' på EJB, och det lokala gränssnittet, fjärrgränssnittet och böntypen motsvarar respektive lokalvy, fjärrvy och gränssnittsvy.

Denna proxy behövs för att ge EJB-behållaren möjlighet att transparent tillhandahålla tvärgående ( AOP- liknande) tjänster till en böna som transaktioner, säkerhet, avlyssningar, injektioner och remoting. Som ett exempel anropar en klient en metod på en proxy, som först startar en transaktion med hjälp av EJB-behållaren och sedan anropar den verkliga bönmetoden. När bean-metoden återvänder avslutar proxyn transaktionen (dvs. genom att begå den eller göra en återgång) och överför kontrollen tillbaka till klienten.

EJB Container är ansvarig för att klientkoden har tillräckliga åtkomsträttigheter till en EJB. Säkerhetsaspekter kan deklarativt tillämpas på en EJB via anteckningar.

Transaktioner

EJB-containrar måste stödja både containerhanterade ACID- transaktioner och beanhanterade transaktioner.

Containerhanterade transaktioner (CMT) är som standard aktiva för samtal till sessionbönor. Det vill säga ingen uttrycklig konfiguration behövs. Detta beteende kan stämmas deklarativt av bönan via anteckningar och vid behov kan sådan konfiguration senare åsidosättas i distributionsbeskrivaren. Tuning inkluderar att stänga av transaktioner för hela bönan eller specifika metoder, eller begära alternativa strategier för transaktionsförökning och start eller anslutning till en transaktion. Sådana strategier handlar främst om vad som ska hända om en transaktion pågår eller inte redan pågår när bönan anropas. Följande varianter stöds:

Deklarativa transaktionstyper
Typ Förklaring
OBLIGATORISK Om klienten inte har startat en transaktion kastas ett undantag. Annars används kundens transaktion.
NÖDVÄNDIG Om klienten har startat en transaktion används den. Annars startar en ny transaktion. (detta är standard när ingen uttrycklig typ har specificerats)
KRÄVER_NEW Om klienten har startat en transaktion avbryts den. En ny transaktion startas alltid.
STÖD Om klienten har startat en transaktion används den. Annars används ingen transaktion.
STÖDS INTE Om klienten har startat en transaktion avbryts den. Ingen ny transaktion startas.
ALDRIG Om klienten har startat en transaktion kastas ett undantag. Ingen ny transaktion startas.

Alternativt kan bönan också deklarera via en kommentar att den vill hantera transaktioner programmatiskt via JTA API. Detta driftsätt kallas Bean Managed Transactions (BMT), eftersom bönan själv hanterar transaktionen istället för behållaren.

evenemang

JMS ( Java Message Service ) används för att skicka meddelanden från bönor till klienter, så att klienter får asynkrona meddelanden från dessa bönor. MDB kan användas för att ta emot meddelanden från klienter asynkront med antingen en JMS- kö eller ett ämne.

Namngivning och katalogtjänster

Som ett alternativ till injektion kan klienter för en EJB få en referens till sessionbönans proxyobjekt (EJB-stubben) med Java Naming and Directory Interface (JNDI) . Detta alternativ kan användas i fall där injektion inte är tillgänglig, till exempel i icke-hanterad kod eller fristående fjärr Java SE-klienter, eller när det är nödvändigt att programmatiskt bestämma vilken böna som ska erhållas.

JNDI-namn för EJB-sessionbönor tilldelas av EJB-behållaren via följande schema:

JNDI-namn
Omfattning Namnmönster
Global java: global [/ <app-name>] / <module- name> / <bean-name> [! <fully-qualified-interface-name>]
Ansökan java: app / <modulnamn> / <bönamn> [! <fullständigt-kvalificerat-gränssnittsnamn>]
Modul java: module / <bean-name> [! <fully-qualified-interface-name>]

(poster inom hakparentes betecknar valfria delar)

En enda böna kan erhållas med vilket namn som helst som matchar ovanstående mönster, beroende på klientens "plats". Kunder i samma modul som den önskade bönan kan använda modulomfånget och större omfattningar, klienter i samma applikation som den önskade bönan kan använda appomfånget och högre etc.

Kod som körs i samma modul som CustomerService-bönan (som ges i exemplet som visas tidigare i den här artikeln) kan använda följande kod för att få en (lokal) referens till den: 

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

Fjärr / distribuerad körning

För kommunikation med en klient som är skriven på Java-programmeringsspråket kan en session bean exponera en fjärrvy via ett @Remote-kommenterat gränssnitt. Detta gör att dessa bönor kan anropas från klienter i andra JVM som själva kan vara placerade på andra (fjärr) system. Ur EJB-behållarens synpunkt är valfri kod i en annan JVM fjärrkontroll.

Stateless- och Singleton sessionbönor kan också exponera en "webbtjänstklientvy" för fjärrkommunikation via WSDL och SOAP eller vanlig XML. Detta följer JAX-RPC och JAX-WS specifikationerna. JAX-RPC-stöd föreslås dock för framtida borttagning. För att stödja JAX-WS antecknas sessionsbönan med @WebService-anteckningen och metoder som ska exponeras på distans med @WebMethod-anteckningen ..

Även om EJB-specifikationen inte nämner exponering som RESTful-webbtjänster på något sätt och inte har något uttryckligt stöd för denna form av kommunikation, stöder JAX-RS- specifikationen uttryckligen EJB. Efter JAX-RS-specifikationen kan stateless- och Singleton-sessionbönor vara rotresurser via @Path-kommentaren och EJB-affärsmetoder kan mappas till resursmetoder via @GET-, @PUT-, @POST- och @DELETE-anteckningar. Detta räknas dock inte som en "webbtjänstklientvy", som endast används för JAX-WS och JAX-RPC.

Kommunikation via webbtjänster är typiskt för klienter som inte är skrivna på Java-programmeringsspråket, men är också praktiskt för Java-klienter som har problem att nå EJB-servern via en brandvägg. Dessutom kan webbtjänstbaserad kommunikation användas av Java-klienter för att kringgå de svåra och illa definierade kraven för de så kallade "klientbiblioteken"; en uppsättning jar-filer som en Java-klient måste ha på sin klassväg för att kunna kommunicera med fjärr EJB-servern. Dessa klientbibliotek är potentiellt i konflikt med bibliotek som klienten redan kan ha (till exempel om klienten själv också är en fullständig Java EE-server) och en sådan konflikt anses vara mycket svår eller omöjlig att lösa.

Arv

Hemgränssnitt och nödvändigt affärsgränssnitt

"Hemgränssnitt" omdirigerar här. För andra användningsområden, se Hemgränssnitt (otydlig) .

Med EJB 2.1 och tidigare varje EJB tvungen att ge en Java-implementering klass och två Java-gränssnitt. EJB-behållaren skapade instanser av Java-implementeringsklassen för att tillhandahålla EJB-implementeringen. Java-gränssnitten användes av klientkoden för EJB.

Obligatorisk distributionsbeskrivare

Med EJB 2.1 och tidigare krävde EJB-specifikationen att en distributionsbeskrivare var närvarande. Detta behövdes för att implementera en mekanism som gjorde det möjligt för EJB att distribueras på ett konsekvent sätt oavsett vilken specifik EJB-plattform som valts. Information om hur bönan ska distribueras (t.ex. namnet på hem- eller fjärrgränssnitt, huruvida och hur man lagrar bönan i en databas etc.) måste anges i distributionsbeskrivaren.

Den driftsättningsbeskrivaren är en XML -dokument som har en post för varje EJB ska sättas in. Detta XML-dokument specificerar följande information för varje EJB:

  • Hemgränssnittets namn
  • Java-klass för Bean (affärsobjekt)
  • Java-gränssnitt för hemgränssnittet
  • Java-gränssnitt för affärsobjektet
  • Ihållande butik (endast för Entity Beans)
  • Säkerhetsroller och behörigheter
  • Stateful eller Stateless (för Session Beans)

Gamla EJB-containrar från många leverantörer krävde mer distributionsinformation än den i EJB-specifikationen. De skulle kräva ytterligare information som separata XML-filer eller något annat konfigurationsfilformat. En EJB-plattformsleverantör tillhandahöll vanligtvis sina egna verktyg som skulle läsa denna distributionsbeskrivare och möjligen generera en uppsättning klasser som skulle implementera de nu föråldrade hem- och fjärrgränssnitten.

Sedan EJB 3.0 ( JSR 220 ) ersätts XML-deskriptoren med Java-anteckningar som anges i Enterprise Bean-implementeringen (på källnivå), även om det fortfarande är möjligt att använda en XML-descriptor istället för (eller utöver) anteckningarna. Om en XML-deskriptor och anteckningar tillämpas på samma attribut inom en Enterprise Bean, åsidosätter XML-definitionen motsvarande källnivåanteckning, även om vissa XML-element också kan vara additiva (t.ex. en aktiveringskonfigurationsegenskap i XML med en ett annat namn än redan definierat via en @ActivationConfigProperty-kommentar läggs till istället för att ersätta alla befintliga egenskaper).

Behållarvariationer

Från och med EJB 3.1 definierar EJB-specifikationen två varianter av EJB-containern; en fullständig version och en begränsad version. Den begränsade versionen följer en korrekt delmängd av specifikationen som heter EJB 3.1 Lite och är en del av Java EE 6: s webbprofil (som i sig är en delmängd av hela Java EE 6-specifikationen).

EJB 3.1 Lite utesluter stöd för följande funktioner:

  • Fjärrgränssnitt
  • RMI-IIOP Interoperabilitet
  • JAX-WS Endpoints för webbtjänster
  • EJB Timer Service (@Schedule, @Timeout)
  • Asynkrona session bean invokations (@Asynchronous)
  • Meddelandestyrda bönor

EJB 3.2 Lite utesluter färre funktioner. Särskilt utesluter det inte längre @Asynchronous och @ Schedule / @ Timeout, men för @Schedule stöder det inte attributet "ihållande" som fullt EJB 3.2 stöder. Den fullständiga uteslutna listan för EJB 3.2 Lite är:

  • Fjärrgränssnitt
  • RMI-IIOP Interoperabilitet
  • JAX-WS Endpoints för webbtjänster
  • Ihållande timers ("beständigt" attribut på @Schedule)
  • Meddelandestyrda bönor

Versionshistorik

EJB 4.0, slutlig release (2020-05-22)

Jakarta Enterprise Beans 4.0 , som en del av Jakarta EE 9, var en verktygsversion som främst flyttade API-paketnamn från toppnivåpaketet javax.ejb till toppnivåpaketet jakarta.ejb .

Andra ändringar inkluderade borttagning av föråldrade API: er som var meningslösa att flytta till det nya toppnivåpaketet och borttagning av funktioner som var beroende av funktioner som togs bort från Java eller någon annanstans i Jakarta EE 9. Följande API: er togs bort:

  • metoder som är beroende av java.security.Identity vilka har tagits bort från Java 14.
  • metoder som förlitar sig på Jakarta XML RPC för att återspegla borttagningen av XML RPC från Jakarta EE 9-plattformen.
  • föråldrad EJBContext.getEnvironment() metod.
  • "Stöd för distribuerad interoperabilitet" för att återspegla borttagningen av CORBA från Java 11 och Jakarta EE 9-plattformen.

Andra mindre ändringar är att markera Enterprise Beans 2.x API-gruppen som "valfritt" och göra Schedule anteckningen repeterbar.

EJB 3.2.6, slutlig release (2019-08-23)

Jakarta Enterprise Beans 3.2 , som en del av Jakarta EE 8, och trots att den fortfarande använder "EJB" -förkortning har denna uppsättning API: er bytt namn till "Jakarta Enterprise Beans" av Eclipse Foundation för att inte trampa på Oracle "Java "varumärke.

EJB 3.2, slutlig release (28.05.2013)

JSR 345 . Enterprise JavaBeans 3.2 var en relativt liten version som huvudsakligen innehöll specifikationsförklaringar och tog bort vissa begränsningar som infördes av specifikationen men med tiden tycktes inte tjäna något verkligt syfte. Några existerande fullständiga EJB-funktioner krävdes också att de skulle vara i EJB 3 lite och funktionalitet som föreslogs att beskäras i EJB 3.1 beskärs verkligen (gjordes valfritt).

Följande funktioner har lagts till:

  • Passivering av en stateful session bean kan inaktiveras via attribut på @Stateful annotation (passivationCapable = false)
  • TimerService kan hämta alla aktiva timers i samma EJB-modul (kunde tidigare bara hämta timers för bönan där TimerService anropades)
  • Livscykelmetoder (t.ex. @ PostConstruct) kan vara transaktionella för stateful session beans med den befintliga @TransactionAttribute-kommentaren
  • Autoklockbart gränssnitt implementerat av inbäddningsbar container

EJB 3.1, slutlig release (2009-12-10)

JSR 318 . Syftet med Enterprise JavaBeans 3.1-specifikationen är att ytterligare förenkla EJB-arkitekturen genom att minska dess komplexitet ur utvecklarens synvinkel, samtidigt som man lägger till ny funktionalitet som svar på samhällets behov:

  • Lokal vy utan gränssnitt (Ingen gränssnittsvy)
  • .warförpackning av EJB-komponenter
  • EJB Lite: definition av en delmängd av EJB
  • Bärbara EJB globala JNDI- namn
  • Singletons (Singleton Session Beans)
  • Initiering av program och avstängningshändelser
  • Förbättringar av EJB-timerservice
  • Simple Asynchrony (@Asynchronous for session beans)

EJB 3.0, slutlig release (2006-05-11)

JSR 220 - Stora förändringar : Den här versionen gjorde det mycket lättare att skriva EJB: er med hjälp av "anteckningar" snarare än de komplexa "distributionsbeskrivare" som används i version 2.x. Användningen av hem- och fjärrgränssnitt och ejb-jar.xml-filen krävdes inte längre i den här versionen, efter att ha ersatts med ett affärsgränssnitt och en böna som implementerar gränssnittet.

EJB 2.1, slutlig release (2003-11-24)

JSR 153 - Stora förändringar :

  • Webbtjänstsupport (nytt): statslösa sessionbönor kan åberopas via SOAP / HTTP . Dessutom kan en EJB enkelt komma åt en webbtjänst med den nya tjänstreferensen.
  • EJB timer-tjänst (ny): Händelsebaserad mekanism för att åberopa EJB vid specifika tider.
  • Meddelandestyrda bönor accepterar meddelanden från andra källor än JMS .
  • Meddelandedestinationer (samma idé som EJB-referenser, resursreferenser etc.) har lagts till.
  • EJB-frågespråk (EJB-QL) tillägg: ORDER BY, AVG, MIN, MAX, SUM, COUNT och MOD.
  • XML-schema används för att specificera distributionsbeskrivare, ersätter DTD: er

EJB 2.0, slutlig release (2001-08-22)

JSR 19 - Stora förändringar : Övergripande mål :

  • Standardkomponentarkitekturen för att bygga distribuerade objektorienterade affärsapplikationer i Java .
  • Gör det möjligt att bygga distribuerade applikationer genom att kombinera komponenter som utvecklats med hjälp av verktyg från olika leverantörer .
  • Gör det enkelt att skriva (företags) applikationer: Applikationsutvecklare behöver inte förstå detaljerade transaktions- och tillståndshanteringsdetaljer, multi-threading, anslutningspooling och andra komplexa lågnivå-API: er.
  • Kommer att följa "Write Once, Run Anywhere" -filosofin för Java . En företagsbönor kan utvecklas en gång och sedan distribueras på flera plattformar utan rekompilering eller källkodsändring.
  • Ta itu med utvecklings-, implementerings- och runtime-aspekterna av en företagsapplikations livscykel.
  • Definiera de kontrakt som gör det möjligt för verktyg från flera leverantörer att utveckla och distribuera komponenter som kan fungera tillsammans vid körning.
  • Var kompatibel med befintliga serverplattformar. Säljare kommer att kunna utöka sina befintliga produkter för att stödja EJB.
  • Var kompatibel med andra Java API: er.
  • Tillhandahålla interoperabilitet mellan Enterprise Beans och Java EE-komponenter såväl som programmeringsspråk som inte är Java.
  • Var kompatibel med CORBA-protokollen (RMI-IIOP).

EJB 1.1, slutlig release (1999-12-17)

Stora förändringar :

  • XML-distributionsbeskrivare
  • Standard JNDI-sammanhang
  • RMI över IIOP
  • Säkerhet - rolldriven, inte metodstyrd
  • Entity Bean support - obligatoriskt, inte valfritt

Mål för släpp 1.1:

  • Ge bättre stöd för montering och distribution av applikationer.
  • Ange mer detaljerat ansvaret för de enskilda EJB-rollerna.

EJB 1.0 (1998-03-24)

Tillkännagavs på JavaOne 1998 , Sun: s tredje Java-utvecklare-konferens (24 till 27 mars) Mål för version 1.0:

  • Definierade de distinkta "EJB-roller" som antas av komponentarkitekturen.
  • Definierade klientbilden för företagsbönor.
  • Definierade företagets Bean-utvecklare.
  • Definierade ansvaret för en EJB Container-leverantör och serverleverantör; tillsammans utgör dessa ett system som stöder distribution och körning av enterprise Beans.

Referenser

externa länkar