Distribuované programování s prvky komponent XDPKO. Doc. Ing. František Huňka, CSc.

Transkript

1 Distribuované programování s prvky komponent XDPKO Doc. Ing. František Huňka, CSc. 1

2 Obsah 1 Distribuované systémy základní architektura Distribuované systémy Java EE, Enterprise JavaBeans přehled Anotace - metadata v Javě a možnosti jejich využití Technologie Enterprise JavaBeans Distribuované zpracování základ EJB EJB služby middleware Řízení zdrojů Primární služby Perzistence v Javě (Java Persistence) EntityManager Perzistentní kontext Životní cyklus entitních beanů Pakování perzistentní jednotky Získání EntityManager Mapování perzistentních objektů Primární klíč třídy a kompozitní klíče Mapování položek Entitní relace Jednosměrná relace one-to-one Obousměrná relace one-to-one Jednosměrná relace one-to-many Jednosměrná relace many-to-one Obousměrná relace one-to-many Obousměrná relace many-to-many Jednosměrná relace many-to-many Kaskádování Dědičnost entit a zpětná volání posluchači Jedna tabulka pro hierarchii tříd Tabulka pro konkrétní třídu Tabulka pro podtřídu Zpětná volání entity a posluchači Dotazy a EJB QL Quary API Stránkování výsledků EJB QL Session beany Bezstavové session beany Zpřístupnění vlastností prostředí EJBContext Životní cyklus bezstavových session beanů Beany řízené zprávami Transakce Transakce řízené kontejnerem, beanem a klientem Transakční atributy

3 1 Distribuované systémy, základní architektura V této kapitole se dozvíte: co jsou to distribuované systémy, jaké jsou základní platformy pro tvorbu distribuovaných systémů jaké je využití anotací (metadat v Javě. Komponentová technologie Cíl vytvořit softwarové součástky a ty používat jako např. hardwarové součástky. Základní pojmy: Rozhraní: každá komponenta musí mít rozhraní, kterým komunikuje se svým okolím Sada rozhraní: množina rozhraní, které komponenta zveřejňuje a poskytuje k použití aplikacím Identita komponenty: umožňuje od sebe odlišit různé komponenty, je dána zpravidla jednoznačným identifikátorem Anonymita klienta: o svém prostředí (aplikaci, kde je použita) má komponenta vědět co nejméně; tím je její použití univerzálnější Skládání součástek: schopnost komponenty fungovat jako uživatel jiné komponenty Znovupoužití: znovupoužití komponenty je třeba pečlivě plánovat Sdílení a napojení několika klientů: sdílení komponent klientskými aplikacemi je velmi častým jevem 1.1 Distribuované systémy Distribuovaný systém bude mít intuitivně komponenty, které jsou distribuované na různých počítačích (jiných JVM). Na počítač, který hostí některé komponenty distribuovaného systému se odkazujeme jako na hostitelský (host). Koncept hostitelského počítače pak bude označovat všechny operační komponenty počítače, včetně hardware, síťového operačního systému a software. Distribuovaný systém má více než jednu komponentu na více než jednom hostitelském počítači. Tyto komponenty se vzájemně ovlivňují, jsou ve vzájemné interakci. Komponenty potřebují poskytovat vzájemný přístup ke službám a potřebují být schopny si požádat o služby navzájem. Teoreticky by komponenty mohly být propojeny navzájem pomocí primitivních operací síťového operačního systému. Prakticky by to bylo příliš složité pro mnoho aplikací. Middleware mezivrstva, která pomáhá s heterogenitou a distribucí. 3

4 Komponenta 1... Síťový operační systém Komponenta N Hardware Hostitelský počítač Obr. 1.1 Hostitelský počítač a distribuovaný systém Komponenta 1... Middleware Komponenta N Síťový operační systém Hardware Hostitelský počítač Obr 1.2 Middleware v distribuovaném systému Úkoly middleware Middleware přemosťuje mezeru mezi síťovým operačním systémem a komponentami. Poskytuje navrhovateli vyšší úrovně abstrakce. Implementuje vyšší úrovně abstrakce založené na základních operacích (primitives), které poskytuje síťový operační systém. Zapouzdřuje složitost před návrhářem. Typy middleware Vzdálené volání procedur (Remote Procedure Calls) 4

5 Vyvinuto počátkem 80. let firmou Sun Microsystem jako část platformy Open Network Computing. RPCs jsou operace, které mohou být vyvolány vzdáleně nad různými platformami hardware a operačních systémů. Systémy remote procedure call jsou základem objektově orientovaného middleware. Objektově orientované middleware Toto middleware se vyvinulo více méně z myšlenky RPC. Prvním z těchto systémů byl OMG produkt Common Object Request Broker Architecture CORBA. Microsoft přidal distribuované schopnosti svému Component Object Model (COM) a vytvořil.net. Sun poskytl mechanismus pro Remote Method Invocation (RMI) v Javě. Vývoj objektově orientovaného middleware kopíroval vývoj objektově orientovaných jazyků, které se vyvinuly z procedurálních. Standardizace frameworku komponent První aplikační servery poskytovaly komponentní služby nestandardním, proprietálním (vlastnickým) způsobem. Nebyla dohoda, co je komponenta a jak bude komponenta poskytovat služby prostřednictvím aplikačního serveru. Výsledkem byla závislost na dodavateli aplikačního serveru. Standardizace frameworku komponent spočívá v: Dohodě (kontraktu) na množině standardních rozhraní mezi aplikačními servery a komponentami. Tato dohoda umožní libovolné komponentě běžet na libovolném aplikačním serveru. To dovolí, aby komponenty byly přepínány mezi aplikačními servery bez nutnosti měnit kód, nebo potenciálně dokonce rekompilovat samotné komponenty. Dodavatelé (vendors) aplikačních serverů, kteří implementují takový standardizovaný framework komponent, zabezpečí svoji práci vyšší kvalitou implementace standardu, než pouze omezením (uzamčením) jejich zákazníků. Standardní framework komponent. Tři různé architektury pro distribuované systémy CORBA OMG Platforma.NET - Microsoft Enterprise JavaBeans Sun Microsystems CORBA Common Object Request Broker Architecture, OMG Object Managing Group, ORB Object Request Broker klíčová komponenta poskytuje infrastrukturu umožňující objektům vzájemnou komunikaci nezávisle na platformě či technice implementace objektů, IDL interface definition language. Platforma.NET Technologie úzce svázána s platformou Microsoft Původ v Microsoft Transaction Server (MTS), později přejmenován na COM+ (Component Object Model) COM navržen na používání na desktopu, později upraven do služeb na straně serveru Pro distribuovaný přístup se používá DCOM distribuovaný objektový model komponent jádro dnešní technologie.net 5

6 1.2 Enterprise JavaBeans Je standardní komponentní architektura, sloužící k realizaci aplikační vrstvy informačního systému. EJB komponenty jsou objekty implementované vývojářem, které zajišťují vlastní aplikační (business) logiku systému. Komponenty EJB mají své uplatnění zejména ve tří-(a více) vrstvých distribuovaných aplikacích, kde se jedná o součásti platformy JavaEE. Client Presentation Tier Client Presentation Tier Client Presentation Tier Business Logic Middleware Tier Business Logic Middleware Tier Database Obr. 1.3 Typické vícevrstvé rozmístění Základní vlastnosti EJB Poskytnout robustní infrastrukturu pro vývoj rozsáhlých škálovatelných informačních systémů; Umožnit vývojáři se soustředit výhradně na problémovou doménu; Umožnit tvorbu znovupoužitelných komponent s využitím různých nástrojů od různých dodavatelů a budování aplikací kombinováním takto vytvořených komponent; Usnadnit distribuci a nasazování aplikací. Většina standardních služeb (autentizace, autorizace, distribuovanost, transakce, perzistence, řízení přístupu ke zdrojům, apod.) jsou zajišťovány kontejnerem a jejich konfigurace probíhá deklarativním způsobem. Klíčovou vlastností je interoperabilita, a to mezi jednotlivými kontejnery a aplikačními servery, tak i s jinými aplikacemi. Portabilita aplikace jsou vyvíjeny nezávisle na konkrétní platformě. Interoperabilita běh aplikací je nezávislý na koncové platformě. Java EE Java EE (Enterprise Edition) je standardním deštníkem pro prostředky počítání Java enterprise. V podstatě spolu sdružuje technologie pro kompletní vývoj enterprise-class na straně serveru platformy rozmístění v Javě. Java EE je významná, protože vytváří jednotnou platformu pro vývoj v Javě na straně serveru. 6

7 K lepšímu porozumění skutečné hodnoty Java EE bude uveden část výčtu důležitých technologií a API, které Java EE implementace podporují. EJB (Enterprise JavaBeans) definuje jak psát komponenty na straně serveru a poskytuje standardní smlouvu mezi komponentami a aplikačními servery, které je řídí. EJB je uhelným kamenem Java EE. Java API for Web Services (JAX-WS). Webové služby metadat pro platformu Java. Specifikuje různé anotace pro vývoj webových služeb a rozmístění. Je nově zavedený až od Javy EE 5.0. Javovské vzdálené volání metod (RMI) a RMI-IIOP. RMI je javovská nativní cesta ke komunikaci mezi distribuovanými objekty, kdy oba objekty běží v různých JVM. RMI-IIOP je rozšíření RMI, které může být použito na integraci platformy CORBA. Je to oficiální API, které je možné použít přímo v Javě EE. Java Naming and Directory Interfaces (JNDI) se používá k zpřístupnění jmen a adresářových systémů. Je to možné využít při propojování EJB komponent nebo jiných zdrojů přes počítačovou síť. Java Database Connectivity (JDBC) je API pro zpřístupnění relačních databází. Java Transaction API (JTA) a Java Transaction Services (JTS) tyto prostředky dovolují komponentám využít spolehlivou transakční podporu EJB 3.0 Tato specifikace přináší výrazné zjednodušení vývoje (oproti EJB 2.1). Toho je dosaženo: přechodem od komponent typu Entity EJB k POJO entitám (plain old java object), nahrazením většiny deployment deskriptorů (popisovačů rozmístění) pomocí anotací (komentáře s využitím metadat) uplatnění techniky dependency injection Kontejner základní činnost řídí životní cyklus EJB komponent zajišťuje autentizaci a autorizaci (JAAS) umožňuje distribuci komponent (RMI-IIOP) řídí transakce (JTA) může zajišťovat perzistenci (JTA) poskytuje přístup ke zdrojům (JDBC, JCX) poskytuje další služby (JMS, JavaMail) Nastavení atributů různých služeb (transakce, bezpečnost, přístup ke zdrojům ) je důsledně odděleno od kódu komponent a řeší se deklarativním způsobem (u verze 3.0 pomocí anotací). To zjednodušuje kód komponent a zároveň umožňuje jejich chování snadno přizpůsobit požadavkům při konkrétním nasazení, aniž by bylo nutné měnit jejich kód. EJB komponenty Entity EJB (přítomny kvůli zpětné kompatibilitě, nahrazuje je technologie Java Persistence API, která je oddělena od specifikace EJB); Stateless Session EJB Stateful Session EJB Message-Driven EJB Role při vývoji EJB aplikací Vývojář komponenty Sestavitel aplikace 7

8 Odborník na nasazení Dodavatel EJB kontejneru Dodavatel EJB serveru Administrátor Distribuce a nasazení EJB komponent Komponenty spolu s popisovači nasazení (popis instalace) se zabalí do tzv. modulů, které je možné nasadit v prostředí libovolného kontejneru, splňujícího požadavky specifikace EJB. Při nasazení je ovšem nutné aplikaci nakonfigurovat, což se děje prostřednictvím úprav popisovačů nasazení. JAR File Generator Obr. 1.5 Spakování a rozmístění beanu Kdy použít EJB Když musí být aplikace škálovatelná. Když musí být podporován souběžný přístup a transakce. Když bude existovat více různých typů klientů Kdy nepoužít EJB Když to bude kanón na vrabce. Když nejsou potřeba služby a vlastnosti poskytované touto technologií. Vždy je však důležité logicky oddělit aplikační vrstvu od prezentace. Nevýhody EJB Komponenty jsou závislé na kontejneru a jeho API. Složitost a náročnost na osvojení (i když zredukováno). Kontejner má vždy jistou režii. 1.3 Anotace komentáře (metadata) Zásadní rozšíření jazyka Java 5.0. Anotace jsou značky vkládané do zdrojového kódu a určené většinou pro různé nástroje např. dokumentace programu, metadata pro EJB aplikace 8

9 deployment descriptor (popis instalace). Umožní zapsání zdrojového kódu a poznámek (anotací) do jednoho souboru: JavaBeans vyžadují třídu BeanInfo paralelně s beanem EJB vyžadují popisovač instalace (deployment descriptor) dosud další soubor.xml Zpracování značek Značky mohou být zpracovány v následujících etapách (v jedné i ve všech třech): 1. mohou být určeny pouze pro nástroje pracující se zdrojovým kódem čteny ze zdrojového kódu 2. mohou být začleněny do přeloženého.class souboru a určeny pro nástroje pracující s těmito soubory nástroje připravující instalaci (rozmístění deployment) na aplikačním severu před vlastním spuštěním nástroje pro práci s knihovnami 3. mohou být začleněny do.class souboru a určeny pro zpracování za běhu programu (runtime reflection). Anotace patří mezi modifikátory. Vkládá se před anotované položky (deklarace a definice) bez středníku. Podle konvence se anotace vkládá před ostatní modifikátory. Zápis anotace Anotace doplňuje javadoc značky (tags). Od jiných syntaktických prvků odlišuje anotace Je to předpona. používají i značky v dokumentačních komentářích. Anotace se nevyskytuje uvnitř komentářových závorek. Identifikátor, který za znakem následuje je identifikátor anotace. Např. - označuje datový atribut, který bude ignorován indikuje nepoužívat metodu Anotace nesmí deklarovat žádného předka potomci rozhraní java.lang.anotation.annotation nesmí se explicitně deklarovat podobně jako enum Anotace bez parametrů, nedefinuje žádné parametry značkovací anotace (marker annotations). Anotace s parametry. // Deklarace anotace Testovat { // Pouziti anotace public class MojeTrida { // bezparametrická anotace, nemá závorky public void chytrametoda() { //... 9

10 // indikace docasne specifikace - deklarace Preliminary { // public class TimeTeravel {... NazevAnotace { Typ NazevPrvku( ); // deklarace prvku anotacniho typu // nebo Typ NazevPrvku( ) default [implicitni hodnota] ; // deklarace ReguestForEnhancement { int id( ); String synopsis( ); String engineer( ) default [unassigned] ; String date( ) default [unimplemented] ; // ( id = , synopsis = Enable time-travel, engineer = Mr. Peabody, date = 12/4/2008 ) public static void travelthroughtime(date destination) {... Možnosti anotace anotování: tříd rozhraní atributů metod parametrů metod balíčků musí být definován soubor package-info.java definice pouze v tom souboru, vlastní anotace před klíčovým slovem package Anotace ve standardní knihovně označená deklarace je považována za zavrženou a příslušný objekt/metoda by se neměly používat označuje metody, které mají zastínit (překrýt) stejnojmenné metody rodičovské třídy jako parametr má definován vektor textových řetězců specifikujících varování, která má překladač při překladu anotované entity potlačit. označená anotace musí být uvedena v dokumentaci. Program generující anotaci ji pak bude uvádět jako součást popisu deklarace dané entity. 10

11 specifikuje, které druhy entit je možné jí označít. Má jeden parametr výčtového typu: java.lang.anotation.elementtype ANNOTATION_TYPE Definice jiné anotace CONSTRUCTOR Definice konstruktoru FIELD Deklarace atributu LOCAL_VARIABLE Deklarace lokální proměnné METHOD Deklarace metody PACKAGE Deklarace balíčku PAREMETER Deklarace parametru TYPE Deklarace třídy, rozhraní, výčtového typu. Neoznačená definice znamená, možnost deklarace libovolného z uvedených typů. definice s ní označená se stane součástí dědictví dceřinných tříd. Při dotazu na pak v případě záporné odpovědi bude automaticky dotazována její rodičovská třída a eventuálně její rodičovská třída atd. definuje dobu uchování informací předaných anotací. Jednoparametrická anotace s parametrem výčtového typu java.lang.anotation.retentionpolicy Anotace ve standardní knihovně Retention SOURCE anotace určená pouze pro programy pracující se zdrojovým kódem soubory.java CLASS anotace určená pro programy pracující s.class soubory např. programy pro instalaci (deployment) aplikací a knihoven. Class loader tento typ anotace nezpracuje a do classobjektu dané třídy ji nezačlení. RUNTIME informace daného typu anotace se dostanou až do class-objektu dané třídy, které anotace označuje. Prostřednictvím mechanismu reflexe proto bude možné za běhu programu příslušné informace uvedené v anotaci zjistit a podle nich reagovat. Reflexe Reflexe je proces, kterým počítačový program může pozorovat a modifikovat svoji vlastní strukturu a chování. Reflexe v Javě dovoluje javovskému kódu vyhledávat informace o datových atributech, metodách a konstruktorech třídy nahrané do operační paměti počítače. Úvodní kapitola popisuje a vysvětluje základní pojmy nutné k dalšímu studiu. Jsou zde popsány základní distribuované platformy. Především se ale úvodní kapitola věnuje technologii EJB a její verzi 3. Dále kapitola obsahuje popis a vysvětlení anotací (metadat), které se objevily v Javě od verze 5. Na praktických příkladech je vysvětleno jejich použití. 11

12 2 Technologie Enterprise JavaBeans V této kapitole se dozvíte: co tvoří základ EJB, jaké základní služby EJB poskytuje, co je to řízení zdrojů, jaké jsou základní primární služby. Fyzicky představuje EJB dvě věci v jedné: Specifikace (může být členěna do dokumentů) navrhuje pravidle úmluvy mezi aplikačním serverem a komponentami. Množina javovských rozhraní. Komponenty a aplikační servery musí vyhovovat těmto rozhraním. Protože jsou všechny komponenty psány podle stejných rozhraní, pro aplikační server vypadají všechny stejně. Z toho důvodu může aplikační server řídit libovolnou komponentu. EJB jako aplikační vrstva komponent Skutečný rozdíl mezi prezentační vrstvou komponent a enterprise beany je v doméně, ve které pracují. Prezentační vrstva zpracovává operace na straně klienta. Enterprise beany zpracovávají komponenty na straně serveru. 2.1 Distribuované zpracování - základ EJB EJB umožňuje vývoj a instalaci (deployment) distribuovaných komponent distribuovaných objektů (vzdálených objektů). Vzdálené volání metody distribuovaného objektu sleduje běžný postup, který je podobný téměř u všech distribuovaných technologií. Hlavní kroky postupu: 1. Klient volá stub proxy objekt na straně klienta. Stub utajuje síťovou komunikaci před klientem. Stub prostřednictvím soketů komunikuje s počítačovou sítí, ví jak zaslat parametry javovských reprezentací reprezentacím v síti. 2. Stub volá počítačovou sítí skeleton, což je proxy objekt na straně aplikačního serveru. Skeleton utajuje síťovou komunikaci od distribuovaných objektů. Skeleton umí přijmout volání prostřednictvím soketů, stejně tak převést parametry z jejich síťové reprezentace do javovské reprezentace. 3. Skeleton deleguje volání na vhodnou implementaci distribuovaného objektu. Tento objekt obslouží volání (klienta), provede svoji práci a vrátí řízení skeletonu. Ten následně vrací řízení stubu, který konečně vrací řízení vzdálenému klientovi. Klíčovým bodem je, že jak stub, tak i implementace objektu na straně serveru implementují stejné rozhraní remote interface. To znamená, že stub klonuje hlavičky (signatures) metod distribuovaného objektu. Klient, který volá metodu stubu si myslí, že volá distribuovaný objekt přímo; ve skutečnosti klient volá prázdný stub, který ví, jak se dostat přes počítačovou síť ke skutečné implementaci (distribuovanému objektu). Tomu se říká distribuovaná transparentnost. Ve skutečnosti je distribuovaný objekt abstrakce, která je vytvořena spoluprací mezi stubem a skeletonem a objekty implementace. Žádná samostatná entita není v tomto scénáři distribuovaný objekt. 12

13 Obr. 2.1 Distribuované zpracování 2.2 EJB služby middleware Služby middleware může EJB poskytovat explicitně a implicitně. Explicitní přístup vyžaduje explicitně volat API služby middleware. Implicitní přístup je bez nutnosti psaní API služeb middleware. Explicitní přístup ke službám middleware Kód je používá middleware API, aby požádal framework k provedení požadovaných služeb. Následující příklad ukazuje pseudokód metody transfer distribuované komponenty Bank, která provádí (přesun) částek mezi účty: transfer(account account1, Account account2, long amount) { // 1: Volá API middleware k provedení bezpečnostní kontroly // 2: Volá API middleware pro spuštění transakce // 3: Volá API middleware k naplnění řádků z databáze // 4: Odečte částku od jednoho účtu a přidá ji k druhému účtu // 5: Volá API middleware pro uložení řádků do databáze // 6: Volá API middleware k ukončení transakce Ačkoli jsme obslouženi s předepsaným middleware prostřednictvím frameworku, naše aplikační logika je protkána s logikou volání toto API middleware. Tento postup má jisté stinné stránky: Snížená produktivita vývojáře. I přes to, že framework poskytuje služby middleware, stále se předpokládá, že vývojář bude psát kód který je bude využívat. Psaní a testování kódu vždy zabírá čas a takto snižuje produktivitu. Obtížnost psaní. Kód je nadutý. Jednoduše chceme provádět transfer, ale to vyžaduje velké množství kódu z důvodu smísení kódu interakcí služeb s kódem aplikační logiky. Obtížná údržba. V případě, že chcete změnit způsob jakým využíváte služby middleware, musíte přepsat váš kód. 13

14 Implicitní přístup k middleware S tímto přístupem framework nejen poskytuje služby middleware, ale také jednodušší způsob jejich použití. Implicitní framework middleware dovolí deklarovat služby middleware, které potřebujete pro vaši aplikaci v odděleném popisovači souboru, nebo dokonce prostřednictvím jednoduchých anotací, uvnitř vlastního kódu. Takto váš kód již neobsahuje žádné těžkopádné volání API pro použití služeb middleware. Kód je jasný se zaměřením na aplikační (business) logiku. Následuje předchozí příklad přepsaný za použití implicitního přístupu k middleware: transfer(account account1, Account account2, long amount) { // 1: Odečte částku z jednoho účtu a přičte ji k jinému účtu V době kompilace předchozího kódu, si framework prohlédne (prozkoumá) popisovač (deskriptor) a / nebo anotaci uvnitř kódu a provede požadované služby middleware. Takto je mechanismus použitý na poskytování služeb middleware implicitně je implementačním detailem serveru EJB a je ponecháno na prodejcích (dodavatelích), aby se rozhodli individuálně. Výhody tohoto řešení jsou následující: Zvýšení produktivity vývojáře. Vývojáři nemusí psát kód pro vyvolání služeb middleware. Vše co musí udělat je, deklarovat služby, které vyžadují v popisujícím souboru s využitím XML nebo anotací v samotném kódu. Snadný zápis. Protože není třeba psát žádný kód k vyvolání služeb middleware, váš kód komponenty může být zaměřen na aplikační logiku. Snadná údržba. Oddělení business (aplikační) logiky od logiky middleware je snadno udržovatelé. Změna služeb middleware nevyžaduje změnu kódu aplikace. Implicitní &explicitní využívání služeb middleware EJB používá implicitní přístup k middleware, avšak poskytuje také jednoduché API ke konkrétním interakcím se službami middleware. Ačkoli přístup přes API je složitější, nechává větší řízení v rukách vývojáře. Např. v případě kdy vývojář nechce označit celou metodu v EJB jako transakční. V tom případě musí použít javovské transakční API k interakci s transakčním řízením služeb EJB. Použitím API služeb middleware může vývojář označit začátek a konec transakce v konkrétních bodech uvnitř kódu metody a tímto vykonávat lepší řízení. EJB poskytuje obě možnosti využívání služeb middleware. 2.3 Řízení zdrojů Servery EJB také řídí zdroje, které používají beany a mohou dále řídit mnoho distribuovaných objektů. Musí řídit a rozhodovat, jak budou distribuobané objekty používat paměť, vlákna, databázová připojení atd. Servery EJB podporují tyto služby: konkurentnost řízení transakcí perzistenci distribuci objektů pojmenování (naming) 14

15 bezpečnost Služby představují jistý druh infrastruktury potřebný pro fungování třívrstvé architektury. Komponenty na straně serveru Enterprise beany v Javě, zapouzdřují business (aplikační) logiku = kód který požaduje aplikace session beany vykonávají úlohy klienta beany řízené zprávami fungují jako posluchači pro konkrétní typ asynchronní zprávy Obsah enterprise beanu pro jeho vytvoření jsou potřebné následující soubory: Třída enterprise bean implementuje metody definované v aplikačním rozhraní a jakékoli metody životního cyklu zpětného volání (callback). Business rozhraní lokální, vzdálené rozhraní, definuje metody implementované třídou enterprise bean. Helper classes třídy výjimek, pomocné třídy pro třídu enterprise bean. Uvedené soubory se spakují do EJB JAR modulu, ve kterém je uložen enterprise bean. //Vzdálené rozhraní bezstavového public interface CalculatorRemote { public int add(int x, int y); public int subtract(int x, int y); //Třída stateless session bean import public class CalculatorBean implements CalcularRemote { public int add(intx, int y) { return x+y ; public int subtract(int x, int y) { return x-y ; Entitní beany Entitní bean je lehký (lightweight) perzistentní doménový objekt tzv. POJO. Typická entita reprezentuje tabulku v relační databázi. Instance entitního beanu koresponduje se řádkem této tabulky. Ke každé entitě musí existovat entitní třída Požadavky na entitní třídu 15

16 Třída musí být opatřena komentářem Modifikátor třídy musí být public nebo protected, musí obsahovat neparametrický konstruktor, může obsahovat další konstruktory Třída nesmí mít modifikátor final. Žádná metoda, stejně jako perzistentní instanční proměnné (datové atributy) nesmí být deklarovány final. Pokud je instance entity předávaná hodnotou jako odpojený (detached) objekt prostřednictvím rozhraní session beanu, třída musí implementovat rozhraní Serializable. Entitní třídy mohou být podtřídami jiných entitních, nebo neentitních tříd, neentitní třídy mohou mít pod sebou entitní třídy. Perzistentní instanční proměnné (datové atributy) entitní třídy mohou být deklarované jako private nebo protected a zpřístupňovány pomocí přístupových a modifikačních metod (get/set). package com.titan.domain; import javax.persistence.entity; import javax.persistence.table; import javax.persistence.column; public class Cabin implements java.io.serializable { private int id; private String name; private public int getid() { return id; public void setid(int pk) {id = public String getname() { return name; public void setname(string str) { name = public int getdecklevel() { return decklevel; public void setdecklevel(int level) { decklevel = level; 2.3 Řízení zdrojů Velký aplikační systém s mnoha uživateli vyžaduje tisíce až miliony objektů, které se využívají současně. Protože počet interakcí mezi objekty roste, roste i časová odezva systému a frustrace uživatelů. Servery EJB zvyšují výkonnost synchronizací interakcí mezi objekty a sdílením zdrojů. Mezi počtem klientů a počtem distribuovaných objektů, které jsou třeba k obsloužená klientů je přímá úměra. 16

17 EJB explicitně podporuje dva mechanismy zvyšující výkonnost: 1. instance pooling (sdílení instancí) pro bezstavové session beany (stateless) 2. aktivační mechanismus pro stavové session beany (stateful) Instance looping (sdílení instancí) Koncept sdílení zdrojů se využíval již dříve např. pool databáze connection business objekty v systému mohou sdílet přístup do databáze. Tento nápad snižuje počet databázových připojení a zvyšuje propustnost systému. Mnoho EJB kontejnerů používá také sdílení zdrojů k serverové straně komponent; tato technika se nazývá instance pooling. Klienti session beanů jsou v interakci s těmito beany prostřednictvím vzdáleného nebo lokálního rozhraní, které je implementované EJB objekty. Klientské aplikace nikdy nemají přímý přístup k instanci třídy session beanu. Instance pooling (sdílení instancí) je možné, protože klienti nemají k beanům přímý přístup. Proto neexistuje žádný pádný důvod, udržovat oddělené kopie každého beanu pro každého klienta. Server proto může udržovat mnohem menší množství beanů a znovu využít každou instanci beanu k obsluze jiného požadavku. Životní cyklus entitních beanů Žádný stav (no state) bean ještě nevytvořil instanci; stav pouze pro popis začátku životního cyklu beanu Sdílený stav (pooled state) kontejner již vytvořil instanci, ale ta ještě nebyla asociována s objektem EJB Připravený stav (ready state) instance byla asociována s objektem EJB a je připravena reagovat na zavolání její metody Sdílení instancí Protože bezstavové session beany neudržují žádný stav mezi vyvoláváním metod, každé volání metody pracuje nezávisle tak, že vykonává operaci bez využití instančních proměnných (datových atributů třídy). To znamená, že libovolná instance bezstavového session beanu může obsloužit požadavek libovolného EJB objektu vhodného typu. Kontejner proto může přepínat instance beanu mezi voláním metod klientů. Každý dodavatel EJB implementuje sdílení instancí odlišně, ale všechny strategie sdílení instancí se snaží, aby byly instance rychle dosažitelné za běhu. Když klienti vytvoří požadavky na business metody, instance beanů ze sdílené oblasti jsou přidělovány EJB požadavkům a asociovány s klienty. Po vykonání požadavku, EJB objekt již dále nepotřebuje instanci beanu a ta je vrácena do společné oblasti. EJB server udržuje sdílenou oblast pro všechny typy rozmístěných bezstavových session beanů. 17

18 EJB object bean instances Client Applications EJB server stub 1 A Instance Pool C stub 2 B D Obr. 2.2 Bezstavové session beany a strategie swapping (prohazování ) bean instances EJB object Client Applications EJB server stub 1 B Instance Pool C stub 2 A B D Obr. 2.3 Bezstavové session beany a strategie swapping (prohazování ) EJBContext Brzy poté, co je instance umístěna do společné oblasti, je odkaz na ni dán do javax.ejb.context. Tento context objekt je injektovaný v případě požadavku na instanci session beanu. EJBContext poskytuje rozhraní, kterým bean může komunikovat s EJB prostředím. EJBContext je velmi užitečný, když se instance beanu se přemisťuje do stavu ready (připravený stav). Když instance beanu obsluhuje požadavek, EJBContext získává nový význam. Poskytuje informace o klientovi, který používá danou instanci beanu. Instanci dále poskytuje přístup k její vlastní EJB stub proxy, což je užitečné, když bean potřebuje předat odkaz na sebe, nebo na jiný enterprise bean. EJBContext tedy není statická třída, ale je to rozhraní ke kontejneru. 18

19 Beany řízené zprávami a instance pooling Beany řízené zprávami rovněž neudržují žádné stavové veličiny a proto jsou rovněž vhodné pro sdílení instancí. Ve většině EJB kontejnerů, má každý typ beanů řízených zprávami svoji vlastní oblast sdílených instancí, které obsluhují příchozí zprávy. Aktivační mechanismus Stavový session bean udržuje stav mezi voláními metod. Konverzační stav reprezentuje pokračující konverzaci mezi stavovým session beanem a klientem. Stavové session beany na rozdíl od bezestavových, entitních a beanů řízených zprávami nemají mechanismus instance pooling. Místo toho používají aktivační mechanismus, který zachovává (konzervuje) zdroje. Když EJB server potřebuje zachovat (konzervovat) zdroje, přesune stavový session bean z operační paměti (bean je serializovaný a přemístěný do druhotné paměti). Když klient vyvolá metodu EJB objektu, je vytvořena nová instance stavového beanu se stavem odpovídajícímu inicializovanému beanu. Pasivace (passivation) je činnost deasociace instance stavového beanu od EJB objektu a uložení jeho stavu. Aktivace stavového session beanu je znovu obnovení instance stavového beanu relativně k jeho EJB objektu. Když přijde požadavek na metodu pasivovaného beanu, kontejner automaticky vytvoří novou instanci a nastaví atributy na hodnoty uložené během pasivace. EJB server Client secondary storage stub EJB object B bean instance EJB server Client stub EJB object secondary storage B bean instance eviction EJB server Client secondary storage stub EJB object C bean instance Obr. 2.4 Proces aktivace a pasivace beanu Aktivační proces je podporovaný metodami zpětného volání životního cyklu. Anotační je vyvolaná ihned následně po úspěšné aktivaci instance beanu, je-li samozřejmě deklarovaná ve třídě beanu. Anotační metoda javax.ejb.prepassivate 19

20 je vyvolaná bezprostředně před pasivací instance beanu opět, je-li vývojářem definovaná ve třídě beanu. Tyto dvě metody jsou zvláště užitečné při aktivaci a pasivaci stavového beanu. Protože instance stavového beanu je vypovězena z paměti, otevřená spojení se zdroji nejsou udržována. Výjimky jsou vzdálené odkazy na jiné beany a SessionContext, který musí být udržovaný se serializovaným stavem beanu a rekonstruovaný, když je opět bean aktivovaný. EJB také vyžaduje, aby během pasivace byly udržovány odkazy na prostředí JINI kontextu, rozhraní komponent a služba EntityManager a objekt UserTransaction. 2.4 Primární služby Konkurentnost (souběžnost), řízení transakcí, perzistence, distribuované objekty, asynchronní posílání zpráv, timer, naming (služba jmen), bezpečnost Souběžnost (concurrency) je důležitá pro všechny typy beanů, ale liší se podle typu beanů. Konkurentnost pro session a entitní beany Stavové a bezstavové session beany nepodporují souběžnost. Vždy slouží pouze klientu, který je vytvořil a nesdílí žádní data. Entitní beany reprezentují data, která mohou být sdílena a zpřístupněna souběžně. V distribuovaném systému objektů vzniká problém, když je snaha sdílet distribuované objekty mezi klienty. Dva klienti používají současně jeden EJB objekt?? jeden čte a druhý dělá změny?? Řešení: Několik klientů může být napojeno na jeden EJB objekt, ale pouze jeden klient (vlákno) může mít přistup k instanci beanu v daném čase. Ostatní klienti čekají, až se dokončí vyvolaná metoda, resp. celá transakce. Kompletní souběžnost řídí EJB kontejner. Proto také beany nesmí vytvářet své vlastní vlákna. Beany řízné zprávami jsou sdílitelné (poolable) a použitelné pro zpracování příchozích zpráv souběžně. Služba pojmenování Poskytují klientům mechanismus pro nalezení distribuovaných objektů a služeb. Služba pojmenování: vazbu s objektem (object binding) vyhledání API (lookup API) Object binding je asociace distribuovaného objektu se jménem, nebo identifikátorem přirozeného jazyka. Např. objekt TravelAgentRemove může být svázán se jménem TravelAgentRemote nebo se jménem agent. Vazba je jednoduše ukazatel, nebo index na distribuovaný objekt. Vyhledání API umožňuje klientovi připojit se na distribuovanou službu a požádat o vzdálený odkaz ke specifikovanému objektu. Enterprise JaveBeans výhradně používá JNDI jako API pro vyhledávání pro javovské klienty. JNDI podporuje libovolný druh jmenné a adresářové služby. 20

21 Javovské klientské aplikace mohou užívat JNDI k inicializaci spojení se serverem EJB a k lokalizaci EJB specifik. javax.naming.context jndicontext = new javax.naming.initialcontext(); Object ref = jndicontext.lookup( TravelAgentRemote ); TravelAgentRemote agent = (TravelAgentRemote) PortableRemoteObject.narrow(ref, TravelAgentRemote.class); Reservation res = agent.bookpassage(...); Objekt jndicontext má informace o EJB serveru a o tom, jaký JNDI driver je třeba nahrát. Metoda Context.lookup() říká poskytovateli JNDI služby jméno objektu, které se má vrátit z EJB serveru. Jakmile je vzdálené rozhraní k dispozici TravelAgent EJB, je možné začít volat metody k provádění požadovaných služeb. Tato kapitola se již detailněji zabývá technologií Enterprise JavaBean. Popisuje základní služby middleware EJB a jejich použití. Dále se věnuje řízením zdrojů a primárním službám. 21

22 3 Perzistence v Javě (Java Persistence) V této kapitole se dozvíte: jaká je základní filosofie využití perzistence v technologii EJB jaké jsou základní funkce Entitního manažera (EntityManager) k čemu se využívají perzistentní jednotky. Java Persistence je oddělený dokument specifikací od jádra specifikace EJB. Je to nejdůležitější inovace verze EJB 3.0. Specifikace Java Persistence: poskytuje standardní objektově relační mapování (integruje mnoho konceptů z Hibernate a JDO) není pouze svázaná s kontejnerem Java EE a může být testována a použita také v prostředích J2SE definuje rozhraní service provider, takže různí persistence providers mohou být použiti bez vlivu na kód entity Perzistence je klíčová část platformy Java EE. EntityManager je ústřední služba pro všechny perzistentní akce přenos entitních informací do/z relační databáze. Entity jsou obyčejné javovské objekty, které jsou stejně alokovány. Nejsou perzistentní, dokud tak neučiní EntityManager. 3.1 EntityManager EntitníManager řídí objektově relační mapování. API EntityManager poskytuje metody pro tři odlišné druhy operací: metody řízení životního cyklu entit metody synchronizace databázových operací metody pro vyhledání a dotazy na entity Dále poskytuje cachovací a transakční služby. Entity & session beany Entity mají klientem viditelnou perzistentní identitu (primární klíč), který se liší od jejich objektové reference. Entity mají perzistentní, klientem viditelné stavy. Entity nejsou vzdáleně přístupné (remotely accessible). Život entity může být kompletně nezávislý na životě aplikace (lifetime). Příkladem je entita Customer. Customer cust = new Customer(); cust.setname( Bill ); Entita zůstane obyčejným objektem, dokud nepožádáme entitního mamažéra o její uložení do databáze. import javax.persistence.*; 22

23 public class Customer implements java.io.serializable { private int id; private String lastname; private String firstname; private CustomerType customertype; private Date timecreated = new Date(); private @Column(name="CUST_ID") public int getid() { return id; public void setid(int pk) { id = pk; public String getlastname() { return lastname; public void setlastname(string lastname) { this.lastname = lastname; public String getfirstname() { return firstname; public void setfirstname(string firstname) { this.firstname = public CustomerType getcustomertype() { return customertype; public void setcustomertype(customertype type) { customertype = public Date gettimecreated() { return timecreated; public void settimecreated(date time) { timecreated public JPEG getpicture() { return picture; public void setpicture(jpeg jpeg) { picture = jpeg; 3.2 Perzistentní kontext Protože entity nemohou být zpřístupněny vzdáleně, je proto možné je rozmístit pouze lokálně a použít je buď z J2SE kódu mimo kontejner EJB, nebo z session beanů nebo zprávami řízených beanů z kontejneru EJB. Perzistentní kontext je spojení mezi vaší instancí v paměti a databází. Perzistentní kontext je manipulovatelný prostřednictvím API EntityManageru. Perzistentní kontext je množina řízených (managed) entitních instancí. EntityManager sleduje všechny entitní objekty uvnitř perzistentního kontextu kvůli změnám, aktualizacím v databázi s využitím pravidel flush modu. Poté co je perzistentní kontext uzavřený, všechny připojené entity (řízené) se stanou odpojenými a nejsou tedy dále řízeny EntityManagerem. Stav odpojených entitních objektů není synchronizován s databází. Existují dva typy perzistentních kontextů: 23

24 1. perzistentní kontext ohraničený transakcí Transaction-scoped persistence context 2. rozšířený perzistentní kontext Extended persistence context Perzistentní kontext ohraničený transakcí Tento kontext žije stejně dlouho jako transakce a končí s jejím dokončením. Na konci je tento kontext zrušen a instance entit se stanou odpojenými. Pouze perzistentní kontexty řízené aplikačním serverem mohou být transakčně ohraničené. Jinými slovy pouze instance EntityManageru injektované prostřednictvím nebo jejího XML ekvivalentu, mohou být transakčně ohraničené titan ) EntityManager public Customer somemethod() { Customer cust = entitymanager.find(customer.class, 1); cust.setname( new name ); return cust; Když má být prováděná metoda somemethod(), kontejner EJB ji vyvolá právě z kontextu JTA transakce (Java Transaction API). Odkaz na instanci entitního beanu Customer je získán z EntityManagera a metoda setname() změní jméno entity Customer. Instance beanu Customer bude řízena po celou dobu transakce. To znamená, že např. změny jména budou synchronizovány s databází. Na konci metody je vrácen odkaz na instanci Customer. Po ukončení transakce je transakčně ohraničený kontext zničen a instance entity Customer již není dále řízena. Vyvolání metody setname() po ukončení transakce jinak neovlivní obsah databáze. Používá se u bezstavových session beanů. Např. metody openaccount(), deposit(), withdraw(), getbalance() vždy vytváří nový perzistentní kontext. Rozšířený perzistentní kontext má delší životnost než transakce, využívá se u stavových session beanů. Instance entit, které jsou připojeny k rozšířenému perzistentnímu kontextu, jsou stále řízeny i po skončení transakce. Toto je zvláště užitečné v případech, kdy je třeba konverzovat delší dobu s databází, ale není žádoucí mít transakce běžící dlouhou dobu, protože transakce představují hodnotné zdroje jako třeba JDBC spojení a zámky databáze. Viz následující příklad: Customer cust = null; transaction.begin(); // začátek transakce 1 cust = extendedentitymanager.find(customer.class, 1); transaction.commit(); // konec transakce 1 transaction.begin(); // začátek transakce 2 cust.setname( Bill ); extendedentitymanager.flush(); // uložení změn do databáze transaction.commit(); // instance cust zůstává připojena, změny jsou // uloženy do DB V příkladu je lokální proměnná cust inicializována voláním metody find() a je stále řízena i po skončení transakce 1. 24

25 3.3 Životní cyklus entitních beanů new. Entitní instance byla vytvořena v paměti, atributy jsou naplňovány daty, ale není ještě asociovaná s perzistentní identitou v databázi nebo s perzistentním kontextem. (Změny stavů atributů entitní instance nejsou synchronizovány s databází). managed. Entita má perzistentní identitu v databázi a je aktuálně asociovaná s perzistentním kontextem. Je to stav po vyvolání metody persist(). detached (odpojena). Entita má perzistentní identitu, ale není nebo již dále není asociovaná s perzistentním kontextem. removed. Entita je aktuálně asociovaná s perzistentním kontextem, ale je naplánovaná pro odstranění z databáze. Obr. 3.1 Životní cyklus entitních beanů Odpojené entity (Detached Entity) Zajímavá stránka odpojených entit je v tom, že mohou být serializované a poslané sítí vzdálenému klientu. Klient může nyní provést změny v instanci entity, a poslat instanci entity zpět serveru, aby mohla být opět synchronizována s databází (změny datových atributů jsou uloženy do databáze). 3.4 Pakování a instalace (rozmístění) entitních tříd Entitní třídy jsou pakovány a instalovány v perzistentních jednotkách (persistence unit). Perzistentní jednotka je logické seskupení entitních tříd, metadat mapování a konfiguračních dat pro databázi. Perzistentní jednotka je definovaná v souboru persistence.xml. Je to deployment deskriptor vyžadovaný specifikací Java Persistence. Soubor persistence.xml definuje jednu nebo více perzistentních jednotek a je uložen v adresáři META-INF. Existují následující typy: obyčejný soubor JAR uvnitř classpath regulárního programu Java SE, 25

26 soubor EJB-JAR. Perzistentní jednotka může být včleněna do rozmístění EJB. soubor JAR v adresáři WEB-INF/lib ve tvaru.war (web archive) soubor JAR v kořenu enterprise archive (.ear) soubor JAR v adresáři EAR lib. Popisovač rozmístění persistence.xml definuje identitu a konfigurační vlastnosti pro každou perzistentní jednotku. Každá perzistentní jednotka musí mít identitu, i prázdný řetězec je platné jméno. Nejjednodušší příklad: <?xml version= 1.0 encoding= UTF-8?> <persistence xmlns= <persistence-unit name= intro /> </persistence> Každá persistentní jednotka je svázána pouze s jedním datovým zdrojem. V prostředí Java EE je tato asociace definovaná specifickým elementem XML. Kořen schéma XML persistence.xml je element <persistence>, který obsahuje jeden, nebo více elementů <persistence-unit>. Viz následující příklad. <persistence> <persistence-unit name="titan"> <jta-data-source>java:/oracleds</jta-data-source> <properties> <property name="org.hibernate.hbm2ddl">update</property> </properties> </persistence-unit> </persistence> Atribut name definuje jméno, podle kterého se na jednotku odkazujeme. Tento atribut je nutný a je používán injektovanými anotacemi a XML popisovači rozmístění. Atribut transaction-type, je volitelným atributem elementu <persistence-unit> a definuje, zda chceme, aby perzistentní jednotka byla řízena a integrována Java EE transakcemi (JTA), nebo používala lokální zdroj (RESOURCE_LOCAL) API javax.persistenceentitytransaction k řízení integrity vašich instancí EntityManagerem Element <persistence-unit> má následující pod-elementy: <description> volitelný komentář popisující danou perzistentní jednotku <provider> volitelný element je plně kvalifikované jméno třídy nebo implementací rozhraní javax.persistence.persistenceprovider. Většinou nedefinujeme. <JTA-data-source> volitelný definujete, pokud používáte: JTA nebo RESOURCE_LOCAL perzistentní jednotky. Tyto elementy určují specifickou identitu dodavatele konkrétního datového zdroje. Obyčejně je tento řetězec globálním jménem JNDI pro odkaz na datový zdroj. <maping-file> volitelný <jar-file> volitelný <class> volitelný <properties> volitelný element definuje množinu atributů specifikovaných dodavatelem, předaných správci persistence. <exclude-unlisted-classes> volitelný 26

27 Perzistentní jednotka Pokud nejsou specifikována žádná jiná metadata uvnitř souboru persistence.xml, soubor JAR, který obsahuje persistence.xml, bude skenován od kořene po libovolnou třídu anotovanou Takto anotované třídy jsou přidány k množině tříd perzistentní jednotky. Je možné ještě přidat další soubory JAR, které chcete, aby byly také skenovány. Takové soubory se přidají do elementu <jar-file> <persistence> <persistence-unit name="titan"> <jta-data-source>java:/oracleds</jta-data-source> <jar-file>../lib/customer.jar</jat-file> <properties> <property name="org.hibernate.hbm2ddl">update</property> </properties> </persistence-unit> </persistence> Skenování souborů JAR je garantováno v prostředí Java EE a nemělo by být problémem v prostředí Java SE. V každém případě je možné třídy deklarovat explicitně s použitím elementu <class>: <persistence> <persistence-unit name="titan"> <jta-data-source>java:/oracleds</jta-data-source> <class>com.titan.domain.cabin</class> <class>com.titan.domain.customer</class> <properties> <property name="org.hibernate.hbm2ddl">update</property> </properties> </persistence-unit> </persistence> Třídy Cabin a Customer jsou přidány do množiny perzistentní jednotky spolu s ostatními třídy získanými z archivní jednotky. Pokud nechceme, aby byl skenován soubor JAR persistence.xml, pak se použije element <excluded-unlisted-classes> <persistence> <persistence-unit name="titan"> <jta-data-source>java:/oracleds</jta-data-source> <class>com.titan.domain.cabin</class> <class>com.titan.domain.customer</class> <excluded-unlisted-classes/> <properties> <property name="org.hibernate.hbm2ddl">update</property> </properties> </persistence-unit> </persistence> 3.5 Získání EntityManager V Javě SE jsou instance Entitních Managerů vytvářeny V Java EE je možné také použít rozhraní factory, ale Java EE poskytuje některé další možnosti k získání instancí je snadnější. EntityManager-Factory package javax.persistence; 27

28 public interface EntityManagerFactory { EntityManager createentitymanager(); EntityManager createentitymanager(java.util.map map); // pro další rozšíření specifikací persistence.xml void close(); boolean isopen(); EntityManager-Factory v Javě SE public class Persistence { public static EntityManagerFactory createentitymanagerfactory( String unitname ); public static EntityManagerFactory createentitymanagerfactory( String unitname, java.util.map properties; ); Třída javax.persistence.persistence vyhledá popisovač rozmístění persistence.xml podle unitname. To umožní lokalizovat EntityManagerFactory, která odpovídá danému jménu. EntityManagerFactory Javě EE V Javě EE získání instancí může být přímo injektováno do položky nebo metody set() pomocí package FIELD, TYPE)@Retention(RUNTIME) PersistenceUnit { String name() default ; String unitname() default ; EntityManagerFactory Při použití PersistenceUnit ta nejen injektuje EntityManagerFactory, ale také registruje odkaz na ni uvnitř JNDI ENC v EJB. Kontejner EJB je zodpovědný označení a injektování odpovídající factory viz následující kód: import javax.persistence.*; import javax.ejb.* public MyBean implements MyBusinessInterface CRM ) private EntityManagerFactory factory; private EntityManagerFactory CUSTDB ) public void setfactory2(entitymanagerfactory f) { this.factory2 = f; 28

29 Když je vytvořena instance bezstavového beanu, kontejner EJB nastaví datový atribut factory na CRM, definované v persistence unit. Také volá setfactory2() s persistence unit CUSTDB. V prostředí Java EE není třeba volat metodu close(). Získání perzistentního kontextu Perzistentní kontext může být vytvořen voláním EntityManagerFactory.createEntityManager(). Vrácená instance reprezentuje rozšířený perzistentní kontext. Je-li v EntityManagerFactory nastaveno JTA-enable, pak je možné explicitně získat instanci EntityManager uvnitř transakce voláním metody EntityManager.joinTransaction(). Pokud nezískáte EntityManager uvnitř transakce, potom změny provedené v entitách nejsou synchronizovány s obsahem databáze. Použití API EntityManagerFactory je trochu upovídané a může být těžkopádné při vnořené EJB volání. Naštěstí EJB a specifikace Java Persistence jsou výborně integrované. EntityManager může být přímo injektovaný do EJB použitím (jako ekvivalent XML). package javax.persistence; public enum PersistenceContextType { TRANSACTION, EXTENDED PersistenceProperty { String name(); String TYPE, PersistenceContext { String name() default ; String unitname() default ; PersistenceContextType type() default TRANSACTION; PersistenceProperty[] properties() default {; funguje víceméně stejným způsobem kromě toho, že místo instance EntityManagerFactory je injektovaná instance entitního public class MySessionBean implements MySessioinRemote titan ) private EntityManager entitymanager;... Dependency injection Je to výkonný mechanismus pro získání referencí na zdroje a pro injektování referencí objektům v relaci s EJB. Injection je technika spolehnutí se na kontejner, který poskytne 29