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

DPKOM_2

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

1

Obsah přednášky • • • • •

Technologie Enterprise JavaBeans Distribuované zpracování – základ EJB EJB služby middleware Řízení zdrojů Primární služby

2

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

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

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

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

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

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

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

Distribuované zpracování základ EJB

Client

Distributed Object Remote interface

Remote interface

Stub

Skeleton

Network

10

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

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

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

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

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

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

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

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

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

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

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

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

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

Ří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. 2. 3. 4. 5. 6.

konkurentnost řízení transakcí perzistenci distribuci objektů pojmenování (naming) bezpečnost 24

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

25

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

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

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

28

//Vzdá //Vzdálené lené rozhraní rozhraní bezstavové bezstavového session beanu

Poznámky

@javax, javax,ejb. ejb.Remote; Remote; @Remote public interface CalculatorRemote { public int add( add(int x, int y); public int subtract( subtract(int x, int y); }

29

//Tř //Třída stateless session bean

Poznámky

import javax. javax.ejb.*; ejb.*; @Stateless public class CalculatorBean implements CalcularRemote { public int add( add(intx, intx, int y) { return x+y ; } public int subtract( subtract(int x, int y) { return x-y ; } }

30

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

Požadavky na entitní třídu • Třída musí být opatřena komentářem (anotovaná) @javax.persistence.Entity • 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

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

Poznámky

package com.titan. com.titan.domain .titan.domain; domain; import import import import

javax.persistence.Entity; javax.persistence.Entity; javax.persistence.Table; javax.persistence.Table; javax.persistence. javax.persistence.Column .persistence.Column; Column; javax.persistence.Id; javax.persistence.Id;

Entitní bean Cabin

@Entity @Table(name @Table(name="CABIN") name="CABIN") public class Cabin implements java. java.io. io.Serializable { private int id; private String name; name; private int deckLevel; deckLevel; @Id @Column( Column(name="CABIN_ID") name="CABIN_ID") public int getId() getId() { return id;

}

public void setId( setId(int pk) pk) {id = pk; pk;

}

@Column( Column(name="CABIN_NAME") name="CABIN_NAME") public String getName() { return name; name; public void setName( setName(String str) str)

}

{ name = str; str; }

@Column( Column(name="CABIN_DECK_LEVEL") name="CABIN_DECK_LEVEL") public int getDeckLevel() getDeckLevel() { return deckLevel; deckLevel; public void setDeckLevel( setDeckLevel(int level) level) { }

}

deckLevel = level; level; }

34

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

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

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

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

Ž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

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

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

Bezstavové session beany a strategie swapping (prohazování ) bean instances EJB object EJB server Client Applications stub

1

A

Instance Pool

C stub

2

B

D

42

Bezstavové session beany a strategie swapping (prohazování ) bean instances EJB object EJB server Client Applications stub

1

B

Instance Pool

C stub

2

A

B

D

43

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

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

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

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

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

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

Proces aktivace a pasivace beanu EJB server secondary storage

Client stub

EJB object

B

bean instance

EJB server secondary storage

Client

B

stub

EJB object

bean instance eviction

EJB server secondary storage

Client stub

EJB object

C

bean instance

50

Aktivační mechanismus • Aktivační proces je podporovaný metodami zpětného volání životního cyklu. • Anotační metoda @javax.ejb.PostActivate 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 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

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

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

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

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

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

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

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

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

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

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

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

62

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

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

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

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

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

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

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

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

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

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

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

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