Enterprise JavaBeans (EJB) je specifikace pro vývoj rozsáhlých distribuovaných podnikových aplikací na platformě Java. EJB 1.0 byl vydán v roce 1998. Nejnovější verze, EJB 3.2.3, byla přijata pro zařazení do Jakarty EE, kde bude přejmenována na Jakarta Enterprise Beans.
EJB architektura
Architektura EJB se skládá ze tří hlavních komponent: Enterprise Beans (EJB), kontejner EJB a aplikační server Java. EJB běží uvnitř kontejneru EJB a kontejner EJB běží uvnitř aplikačního serveru Java.
Existují dva typy EJB - fazole relace a fazole založené na zprávách:
- Fazole relace jsou vyvolány klientem a programově zpřístupňují klientovi podnikové funkce, jako jsou transakce a správa prostředků.
- Fazole založené na zprávách také zapouzdřují a poskytují podnikové funkce, ale jsou asynchronní a řízené událostmi. Fazole založené na zprávách naslouchají událostem a reagují na ně a klient je nemůže vyvolat.
Jakmile byly fazole entit použity k zajištění perzistence v systému EJB, byly nahrazeny rozhraním API Java Persistence. Pokračujte v čtení a dozvíte se více o fazole relace a fazole založené na zprávách.
EJB vs JavaBeans
Enterprise JavaBeans byl prvním vývojovým modelem založeným na komponentách pro Java EE. EJB je podobný JavaBeans v tom, že je založen na komponentách, ale tím podobnost končí:
- A JavaBean je třída Java, která zapouzdřuje více objektů a odpovídá určitým konvencím. JavaBeans se používají hlavně pro vývoj na straně klienta.
- An podniková fazole (EJB) je třída Java naplněná specifickými schopnostmi na straně serveru. Enterprise bean se používají ve velkých podnikových aplikacích a systémech.
Fazole relace
A fazole relace je nejobecnější typ podnikové fazole, představující kus obchodní funkce, kterou může klient volat. Klientem v tomto případě může být jiná třída v místním JVM nebo vzdálené volání.
Kontejner EJB spravuje životní cyklus fazole relace, který je určen stavem fazole:
- Fazole bez státní příslušnosti jsou podobné rozsahu požadavku v rozhraní Java Servlet API. Fazole bezstavové relace obsahují část volatelných funkcí, ale jinak jsou bez státní příslušnosti.
- Stavové fazole relace jsou spojeny pouze s jedním klientem a připojují se k probíhající relaci daného klienta. Stavové fazole relace fungují podobně jako obor relace v rozhraní Servlet API.
- Singleton fazole jsou podobné rozsahu aplikace v Servlet API. Fazole typu singleton session existuje pro každého klienta pouze jednou.
Bezpečnost nití s fazolemi relace
Stavový objekt bean relace je přístupný pouze jednomu klientovi najednou, takže při práci s tímto typem objektu bean je zaručena bezpečnost vlákna. Fazole bezstavové relace a fazole singleton jsou flexibilnější a umožňují souběžná připojení, která musí být spravována vývojářem. Při práci s těmito druhy fazolí jste zodpovědní za bezpečnost nití.
Fazole založené na zprávách
Fazole řízené zprávami (MDB) jsou vyvolávány prostřednictvím zpráv JMS (Java Message Service). JMS funguje jako distribuovaný vzor příkazu, kde objekt typu message-driven bean funguje jako posluchač příkazu. Když zpráva dorazí na téma nebo do fronty, je vyvolána fazole řízená zprávou naslouchající tomuto tématu.
Fazole založené na zprávách se nepoužívají tak běžně jako fazole relace, ale jsou výkonné. Jelikož jsou asynchronní a řízené událostmi, jsou obzvláště užitečné pro dlouhodobé úlohy, kde je důležité šetřit prostředky.
Nejjednodušší architektura by sestávala z aplikace EJB a jejího kontejneru a serveru, které se koordinují se zprávovou službou zpracovávající MDB. Ve výrobě by vaše architektura pravděpodobně obsahovala třetí komponentu věnovanou konzumaci fazolí. Při vývoji by všechny tyto komponenty mohly běžet na stejném místním počítači.
Obrázek 1 ukazuje typickou architekturu řízenou událostmi s fazolemi založenými na zprávách.
Matthew Tyson Práce s fazolemi založenými na zprávách je více zapojena než použití fazolí relace. V prostředí řízeném událostmi budete obvykle potřebovat zprostředkovatele zpráv, jako je ActiveMQ.
Zatímco fazole relace jsou jednodušší, a proto se běžněji používají v EJB, architektury založené na událostech se staly populární, zejména s explozí mikroslužeb.
Anotace EJB
Definování a konzumace podnikových fazolí bylo pro mnoho vývojářů problémem až do EJB 3.0, které zavedlo anotace ke specifikaci EJB. Díky anotacím je velmi snadné konfigurovat podnikové fazole pro širokou škálu funkcí v prostředí Java EE. Pokračujte v čtení, abyste mohli začít s anotacemi EJB.
@Stateless: Definujte fazole relace bez státní příslušnosti
Chcete-li určit třídu jako fazole relace bez státní příslušnosti, použijete javax.ejb. bez státní příslušnosti anotace, jak je uvedeno v Seznamu 1.
Výpis 1. Příklad anotace @Stateless
import javax.ejb.Stateless; @ Stateless public class MyStatelessBean {public String getGreeting () {return "Hello JavaWorld."; }} Tato fazole bez státní příslušnosti obsahuje jednoduchý podpis, který nepřijímá žádné argumenty a vrací řetězec. Nenechte se zmást jednoduchostí: tato fazole dokáže vše, co potřebujete, včetně interakce s jinými fazolemi, službami nebo datovou vrstvou vaší aplikace.
@EJB: Konzumujte fazole relace bez státní příslušnosti
Jakmile definujete fazole relace, její použití je tak jednoduché:
Výpis 2. Příklad anotace @EJB
veřejná třída MyServlet rozšiřuje HttpServlet {@EJB MyStatelessBean myEjb; public void doGet (požadavek HttpServletRequest, odpověď HttpServletResponse) {response.getWriter (). write ("EJB Says" + testStatelessEjb.getGreeting ()); }} Zde injikujeme fazole bez státní příslušnosti do servletu a poté je k dispozici pro použití. Všimněte si, jak je fazole identifikována pod @EJB anotace. Označení „bez státní příslušnosti“ nám říká, že tato fazole nebude klienta sledovat. Protože je bez státní příslušnosti, víme také, že tato fazole podléhá vláknování, pokud funguje mimo vyvolanou metodu.
@Remote: Definujte vzdálené rozhraní EJB
Ve výše uvedených příkladech jsem předpokládal, že klient EJB a EJB běží ve stejném JVM. Pokud podniková fazole a její klient běží v samostatných JVM, musí EJB definovat a @Dálkový rozhraní. V tomto případě je na vás, abyste definovali a implementovali rozhraní, jak je uvedeno v seznamu 3.
Výpis 3. Příklad poznámky @Remote
@ Vzdálené veřejné rozhraní MyStatelessEjbRemote {Řetězec sayHello (Název řetězce); } Vzdálené rozhraní je odesláno klientovi k vyvolání. Volání na něj bude poté splněno implementací na straně serveru EJB. The MyStatelessBean příklad v seznamu 4 implementuje vzdálené rozhraní.
Výpis 4. Implementace vzdáleného rozhraní
veřejná třída MyStatelessBean implementuje MyStatelessEjbRemote {...} Vzdálené rozhraní je implementováno stejně jako normální třída implementující rozhraní. Jako spotřebitel vzdáleného EJB musí mít klientská aplikace přístup k definici třídy pro vzdálené rozhraní. Definici třídy pro vzdálené rozhraní můžete zabalit jako soubor JAR závislostí.
Místní vs vzdálené rozhraní
I když je důležité vědět, jak implementovat vzdálené rozhraní, v praxi je běžnější používat místní rozhraní. Ve výchozím nastavení se používá místní rozhraní a funguje vždy, když je EJB vyvolán ve stejném kontextu JVM. Použití vzdáleného rozhraní vstupuje do hry, když je aplikace distribuována na více JVM.
Stavové sezení fazole a jednozrnné fazole
Proces definování a konzumace stavového @Zasedání fazole a @Jedináček fazole je stejné jako to, co jste viděli @ Bez státní příslušnosti fazole. Pamatujte na sémantiku:
- Lze vytvořit instanci více fazolí relace a použít je pro stejného klienta.
- Jednoletá fazole bude existovat pouze jednou pro celou aplikaci.
Bezpečnost závitů a plánování pomocí singletonů
Zabezpečení vláken je integrováno, když pracujete s fazolemi relace, ale k bezstavovým i singletonovým fazolím lze přistupovat současně více klienty. Vývojáři jsou zodpovědní za bezpečnost vláken při implementaci těchto typů fazolí.
Fazole Singleton nabízejí určitou podporu pro bezpečnost nití prostřednictvím @Zámek anotace. Poznámky anotace @Lock na metodách singleton bean můžete nastavit pro každou metodu oprávnění pro čtení a zápis. Tyto dvě možnosti jsou @Lock (LockType.READ) nebo @Lock (LockType.WRITE), což je výchozí nastavení.
Další užitečnou funkcí singletonových fazolí je schopnost jednoduchým způsobem naplánovat úkoly pomocí @Plán anotace. Výpis 5 ukazuje, jak naplánovat úkol každý den v poledne.
Výpis 5. Příklad anotace @Schedule
@Singleton veřejná třída MySchedulerBean {@Schedule (hour = "12") void doIt () {System.out.println ("Hello at Noon!"); }} CDI vs EJB
CDI neboli Context and Dependency Injection je novější podniková specifikace, kterou někteří vývojáři navrhli, by mohla nahradit EJB.
Na vysoké úrovni nabízí CDI univerzální rámec komponent, zatímco EJB vyniká svými bohatě vybavenými jednotlivými komponentami. Zatímco CDI používá vkládání závislostí k definování a odkazování na jakoukoli softwarovou komponentu, komponenty EJB jsou definovány formálněji, přičemž každá z nich nabízí specifickou sadu funkcí. Obě specifikace jsou plánovány pro budoucí vývoj v rámci Jakarty EE, kde bude nakonec vyřešena otázka, zda by CDI měla nahradit EJB.
Závěr
Enterprise JavaBeans byla první specifikací, která nabízí snadný způsob zapouzdření a opětovné použití obchodní logiky v podnikových aplikacích Java. EJB, daleko od těžkého monstra starých lidí, je dnes štíhlý rámec založený na anotacích, který vám umožní přístup k široké škále podnikových funkcí hned po vybalení z krabice. Zvažte EJB, až budete příště požádáni o rychlé rozšíření distribuované škálovatelné obchodní aplikace. Možná budete příjemně překvapeni.
Tento příběh „Co je EJB? Vývoj Enterprise JavaBeans“ původně publikoval JavaWorld.
