DPKOM_2. Technologie Enterprise JavaBeans Řízení zdrojů a primární služby

Transkript

1 DPKOM_2 Technologie Enterprise JavaBeans Řízení zdrojů a primární služby 1

2 Obsah přednášky Technologie Enterprise JavaBeans Distribuované zpracování základ EJB EJB služby middleware Řízení zdrojů Primární služby 2

3 Technologie Enterprise JavaBeans EJB je standard pro vývoj a rozmístění distribuovaných aplikací na straně serveru v Javě. Definuje smlouvu mezi komponentami a aplikačními servery, která umožňuje libovolné komponentě běžet na libovolném aplikačním serveru, splňujícím kontrakt. Výhody EJB: 1. Široce rozšířený průmyslový standard. Množství nejlepších implementačních zkušeností. 3

4 Technologie Enterprise JavaBeans 2. Je možná přenositelnost z jedné platformy na jinou. EJB je publikovaná a volně přístupná každému. 3. Rychlý vývoj díky infrastruktuře EJB middleware na aplikačním serveru. 4

5 Technologie Enterprise JavaBeans 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. 5

6 Proč Java EJB podporuje pouze Javu (rozdíl od.net) Výhody Javy: Oddělení rozhraní a implementace přímo na syntaktické úrovni. Bezpečnost a zabezpečení vyšší než u standardních jazyků. Neexistují pointery, bohaté knihovny. Vlákno ve stavu dead nezpůsobí ukončení aplikace. Nezávislost na platformě. Architektura vrstev a bytekód. 6

7 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. 7

8 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. 8

9 Distribuované zpracování základ EJB 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. 9

10 Distribuované zpracování základ EJB Client Distributed Object Remote interface Remote interface Stub Skeleton Network 10

11 Distribuované zpracování základ EJB 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). 11

12 Distribuované zpracování základ EJB 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 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. 13

14 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 14

15 Explicitní přístup ke službám middleware 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: 15

16 Explicitní přístup ke službám middleware nevýhody 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. 16

17 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. 17

18 Implicitní přístup k 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 } 18

19 Implicitní přístup k middleware 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ě. 19

20 Implicitní přístup k middleware 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. 20

21 Implicitní přístup k middleware 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. 21

22 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. 22

23 Implicitní &explicitní využívání služeb middleware 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. 23

24 Ří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: 1. konkurentnost 2. řízení transakcí 3. perzistenci 4. distribuci objektů 5. pojmenování (naming) 6. bezpečnost 24

25 Řízení zdrojů Služby představují jistý druh infrastruktury potřebný pro fungování třívrstvé architektury 25

26 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 26

27 Komponenty na straně serveru 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. 27

28 Komponenty na straně serveru Uvedené soubory se spakují do EJB JAR modulu, ve kterém je uložen enterprise bean. 28

29 //Vzdálen lené rozhraní bezstavového session beanu javax,ejb ejb.remote public interface CalculatorRemote { public int add(int x, int y); public int subtract(int x, int y); } 29

30 //Třída stateless session bean Poznámky import javax.ejb public class CalculatorBean implements CalcularRemote { public int add(intx intx, int y) { return x+y ; } public int subtract(int x, int y) { return x-y ; } } 30

31 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 31

32 Požadavky na entitní třídu 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. 32

33 Požadavky na entitní třídu 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). 33

34 package com.titan..titan.domain domain; import javax.persistence.entity; import javax.persistence.table; import javax.persistence..persistence.column Column; import javax.persistence.id; Poznámky Entitní name="cabin") public class Cabin implements java.io io.serializable { private int id; private String name; private Column(name name="cabin_id") public int getid() { return id; } public void setid(int pk) {id = pk; Column(name name="cabin_name") public String getname() { return name; } public void setname(string str) { name = str; Column(name name="cabin_deck_level") public int getdecklevel() { return decklevel; } public void setdecklevel(int level) { decklevel = level; } } 34

35 Ří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. 35

36 Řízení zdrojů 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) 36

37 Instance pooling 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. 37

38 Sdílení instancí 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. 38

39 Ž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 39

40 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ů. 40

41 Sdílení instancí 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ů. 41

42 Bezstavové session beany a strategie swapping (prohazování ) EJB object bean instances Client Applications EJB server stub 1 A Instance Pool C stub 2 B D 42

43 Bezstavové session beany a strategie swapping (prohazování ) EJB object bean instances Client Applications EJB server stub 1 B Instance Pool C stub 2 A B D 43

44 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). 44

45 EJBContext 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. 45

46 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. 46

47 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. 47

48 Aktivační meachanismus 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. 48

49 Mechanismus aktivace 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. 49

50 Proces aktivace a pasivace beanu EJB server secondary Client storage stub EJB object B bean instance EJB server Client secondary storage stub EJB object B bean instance eviction EJB server secondary Client storage stub EJB object C bean instance 50

51 Aktivační mechanismus 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í 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. 51

52 Aktivační mechanismus 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. 52

53 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ů. 53

54 Souběžnost 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?? 54

55 Souběžnost pro session a entitní beany Ř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. 55

56 Souběžnost u beanůřízených zprávami Beany řízné zprávami jsou sdílitelné (poolable) a použitelné pro zpracování příchozích zpráv souběžně. 56

57 Řízení transakcí Transakce jsou pracovní jednotky, které se skládají z úloh, které musí být vykonány společně. Transakce jsou atomické: všechny úlohy transakce musí být vykonány, aby bylo možné považovat transakci za úspěšnou. Transakce jsou proto řízeny automaticky. Jednoduše deklarováním transakčních atributů v čase nasazení instalace (deployment time), řekne EJB serveru, jak řídit beany v době běhu. 57

58 Perzistence Entitní beany jsou perzistentní, což v tomto případě znamená, že jejich stavy jsou uloženy v databázi. To zabezpečuje to, že perzistentní entity mají trvanlivost a znamená to také to, že jak chování, tak i data mohou být přístupny i po chybě (havárii) systému. 58

59 Perzistence Model JavaPersistence, který je použit od verze 3.0, je obyčejný model založený na Javě POJO objektech. Entity tedy mohou být vytvářeny mimo rozsah EJB kontejneru. Jsou alokovány jako jiné Java objekty s použitím operátoru new(). Entity mohou být připojeny (attach) nebo odpojeny (detached) od řízení kontejneru (container management). Instance beanů jsou připojeny k perzistentní paměti prostřednictvím služby EntityManager. 59

60 Perzistence Služba EntityManager poskytuje metody k vytvoření, nalezení, dotazu, odstranění a aktualizaci entity beanu (create, find, query, remove, update). Když je instance entitního beanu připojena, kontejner řídí perzistentní stav beanu a automaticky synchronizuje bean s jeho zdrojovými daty (data v databázi). 60

61 Perzistence Instance beanu jsou obyčejně odpojeny od EJB kontejneru, když je transakce dokončena. Tyto odpojené instance mohou být poslány sítí ke vzdáleným klientům, nebo dokonce uloženy na disku. Jejich stav může být modifikován, a po té může být instance beanu opět připojena k EJB kontejneru s využitím metody EntityManager.merge(). 61

62 Perzistence Když je instance znova připojena, všechny změny (stavů) na ní provedené jsou synchronizovány s perzistentní pamětí. 62

63 Distribuované objekty Doposud byl pro vzdáleného klienta definovaný bean svým vzdáleným rozhraním. Všechno ostatní zůstává neviditelné, včetně mechanismu distribuovaných objektů. EJB 3.0 vyžaduje, aby kontejner EJB podporoval protokoly RMI-IIOOP (Java RMI API používající CORBA IIOP protokol), SOAP 1.2 prostřednictvím JAX-RPC API. Bez ohledu na protokoly, server musí podporovat klienty Javy používající Java EJB API klienta, což znamená, že protokol se musí mapovat na Java RMI-IIOP nebo JAX-RPC programový model. 63

64 Asynchronních posílání zpráv Podpora řízení asynchronních zpráv znamená, že EJB kontejner spolehlivě nasměruje zprávy z JMS klientů na JMS-MDB. Chyba při doručení způsobí požadavek na opětovné doručení. Doručované zprávy mohou být navíc perzistentní, což znamená, že jsou buď uloženy na disku, nebo v databázi, až do doby, kdy mohou být spolehlivě doručeny. 64

65 Time service Služba Timer se používá k plánování oznámení (notification), která jsou zaslaná beanům ve specifikovaném čase. Služba se využívá v bankovních systémech ke kontrole splácení hypoték, finanční limity na nákup, atd. Timery mohou být nastaveny na entitní, bezstavové beany a beany řízené zprávami. 65

66 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. 66

67 Služba pojmenování 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. 67

68 Služba pojmenování 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. Javovské klientské aplikace mohou užívat JNDI k inicializaci spojení se serverem EJB a k lokalizaci EJB specifik. 68

69 Služba pojmenování 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. 69

70 Bezpečnost Servery EJB mohou podporovat tři druhy zabezpečení: 1. Autentikaci prověřuje identitu uživatele, nejpoužívanější je login se username a heslem 2. Autorizaci (kontrola přístupu) uplatňuje politiky, co daný uživatel může a co ne. Uživatel se dostane jen k tomu, na co má povolení. 3. Zabezpečná komunikace (secure communication) zaměřena na komunikační kanály mezi serverem a klienty. Bezpečný kanál pomocí kryptování. 70

71 Bezpečnost EJB specifikuje, že každý klient aplikace přistupující do EJB systému musí být asociovaný s identitou bezpečnosti (security identity). Identita bezpečnosti reprezentuje klienta buď jako uživatele, nebo roli. Normálně bývá uživatel osoba, jejíž identita je přiřazena při logování. Role specifikuje skupinovou identitu např. manažeři. 71

72 Přístup řízený rolí Role-driven access control Identita bezpečnosti je reprezentovaná objektem java.security.principal který působí jako reprezentant uživatelů, skupin, organizací v EJB architektuře řízeného přístupu. Popisovač nasazení obsahuje tagy, které deklarují kterým logickým rolím je umožněno přistoupit ke kterým metodám beanu za běhu Bezpečnostní role představují logické role, protože nereflektují přímo uživatele, nebo skupiny Bezpečnostní role jsou mapovány uživatelským skupinám reálného světa, když je bean rozmísťován. 72

73 Přístup řízený rolí Toto mapování umožňuje přenositelnost (portabilitu) beanu. Při každém nasazení beanu nastává mapování. 73

74 Přístup řízený rolí Role Administrátora je asociována se všemi metodami Cabin EJB (označení *) Role ReadOnly je omezena pouze na tři metody getname(), getdecklevel(), findbyprimarykey() jakýkoli pokus role ReadOnly používat jiné metody skončí výjimkou. Protože jeden popisovač umístění (deployment descriptor) může popsát více než jeden enterprise bean, tagy používané k deklaraci method povolení a rolí jsou definované ve speciální sekci popisovače rozmístění. To umožňuje několika beanům sdílet stejné bezpečnostní role. 74