Využití EJB 3.0 při tvorbě podnikových aplikací

Univerzita Hradec Králové Fakulta informatiky a managementu Katedra informatiky a kvantitativních metod Využití EJB 3.0 při tvorbě podnikových aplikací Diplomová práce Autor: Studijní obor: Bc. Tomáš Olívka Aplikovaná informatika Vedoucí práce: Prof. PhDr. RNDr. Antonín Slabý, CSc. Hradec Králové listopad 2009

Prohlášení: Prohlašuji, že jsem diplomovou práci zpracoval samostatně a s použitím uvedené literatury. V Hradci Králové dne 15.11. 2009 Tomáš Olívka

Poděkování: Děkuji vedoucímu diplomové práce Prof. PhDr. RNDr. Antonínu Slabému, CSc. za veškerou pomoc a podnětné připomínky při zpracování diplomové práce. Dále děkuji majitelům firmy Datex spol. s.r.o., Ing. Aloisi Nevrtalovi a Ing. Václavu Vyniklářovi za možnost vyvíjet prototyp aplikace SOB v rámci této diplomové práce.

Anotace: Diplomová práce se zabývá možnostmi uplatnění frameworku EJB 3.0 při tvorbě podnikových aplikací a na základě získaných teoretických poznatků vytvoření prototypu reálné podnikové aplikace. Annotation: Title: Making use of EJB 3.0 in development enterprise applications. The thesis focuses on the usage framework EJB 3.0 in development enterprise applications. The thesis aims to set up real world application prototype that would be built on theoretical knowledge of EJB 3.0.

Obsah 1 2 3 4 5 Úvod...3 1.1 Terminologie...3 1.2 Odkazy...4 1.3 Schémata a zdrojové kódy...4 Java Enterprise Edition 5, základní pojmy...5 2.1 Java EE specifikace...5 2.2 Java EE platforma...6 2.2.1 Java EE kontejner...6 2.2.2 JEE aplikační server...6 2.2.3 JEE webový kontejner...8 2.2.4 EJB kontejner...8 2.3 Java EE BluePrints...10 2.3.1 JEE BluePrints Katalog...11 2.3.2 JEE Patterns...11 2.3.3 Návrhové vzory...12 2.4 Architektura JEE aplikací...14 2.4.1 Vícevrstevná architektura...14 2.4.2 Komponentová architektura...20 EJB 3.0...24 3.1 Enterprise java beany...24 3.2 Metadata - anotace nebo XML?...25 3.3 Session beany...26 3.3.1 Specifikace obchodního rozhraní session beanů...26 3.3.2 Specifikace třídy session beanů...28 3.3.3 Bezstavové session beany...29 3.3.4 Stavové session beany...31 3.4 Message-driven beany...35 3.4.1 Kdy použít MDB?...36 3.4.2 Specifikace MDB...37 3.5 Dependency inejction...37 3.5.1 Field nebo setter injection?...38 3.5.2 Kdy lze použít dependency injection?...39 3.6 Light-weight AOP koncept Intereceptory...41 3.6.1 Kde a jak lze použít interceptory?...42 3.6.2 Rozdíl mezi interceptory a AOP...43 JPA...44 4.1 Nezávislost JPA na EJB kontejneru...44 4.2 Entity...45 4.2.1 Entitní třída...45 4.2.2 Objektově relační mapování...46 4.2.3 Vazby mezi entitami...47 4.3 Práce s třídou EntityManager...48 4.4 Nastavení JPA persistence.xml...49 Prototyp aplikace SOB...51 5.1 Popis prototypu SOB...51 5.2 Motivace tvorby prototypu...51 5.3 Architektura prototypu SOB...52 1

6 7 8 9 5.3.1 Prezentační vrstva...52 5.3.2 Střední vrstva...53 5.3.3 EIS vrstva...53 5.3.4 Pohled nasazení...53 5.4 Řešené problémy...54 5.4.1 Vývojový nástroj a JEE platforma...54 5.4.2 ORM reverse engineering...54 5.4.3 Integrace EJB a Stripes...55 5.4.4 Nasazení protypu do různých prostředí...59 5.4.5 Efektivní vývoj a testování...61 5.5 Zhodnocení prototypu SOB...63 5.6 Poučení o manipulaci s prototypem SOB...64 Závěr...65 Slovník pojmů...66 Seznam použité literatury...69 Přílohy...72 2

1 Úvod V dnešním světě dynamicky se rozvíjejících informačních systémů a tvrdém konkurenčním boji na trhu výrobců aplikací lze jen těžko obstát bez dobře propracované metodiky, podle které lze efektivně a úspěšně vyvíjet a nasazovat systémy do produkčního prostředí. Požadavky na kvalitu, funkčnost a bezpečnost softwaru se stále zvyšují, a proto je nezbytné dodržovat určité standardy při vývoji aplikace. Pro úspěšné splnění všech požadavků je zcela nezbytné zvolit společně s metodiku nějaký rámec (framework), který nám pomůže zpřehlednit a zefektivnit používání těchto standardů v rámci vývojářských týmu podílejících se na produkci aplikací. Jedním z takovýchto frameworků pro podporu tvorby distribuovaných vícevrstevných aplikací v programovacím jazyce Java je EJB 3.0. Tento framework je součástí specifikace Java Enteprise Edition 5 od společnosti Sun Microsystems a poskytuje standardní prostředky pro budování obchodní logiky vícevrstevných škálovatelných aplikací pomocí tzv. EJB komponent, které jsou nasazovány na aplikační server. Aplikační sever poskytuje EJB komponentám bezpečné prostředí pro jejich provoz. Cílem této diplomové práce je seznámit čtenáře s možnostmi frameworku EJB 3.0. Za tímto účelem byly vytvořeny jednoduché ukázky zdrojových kódů a schémata, které by měly sloužit k lepší orientaci v dané problematice. Ukázky zdrojových kódů v dokumentaci, v tutoriálech nebo v odborné literatuře obvykle ne zcela korespondují s požadavky z praxe, proto bude vytvořen prototyp aplikace na základě reálných požadavků zákazníka. Smyslem tvorby prototypu je snaha ověřit, zdali pomocí popsaných technologií a postupů lze úspěšně vytvořit a nasadit celý systém. Text práce by měl být srozumitelný čtenáři se základními znalostmi objektově orientovaného programování a syntaxe jazyka Java a měl by mu poskytnout nejen přehled o frameworku EJB 3.0, ale především pomoci získat dostatek informací o vhodnosti frameworku pro využití při implementaci konkrétních požadavků na část či celou aplikační logiku. 1.1 Terminologie S přihlédnutím k tomu, že naprostá většina termínů týkajících se oblasti zájmu této práce pochází z angličtiny a je v ustálené podobě používána mezi vývojáři a analytiky na celém světě, není vhodné tyto termíny vždy překládat. Jednak by 3

překlad působil kostrbatě, a také by mohl zcela srozumitelný anglický termín překladem ztratit svoji jednoznačnost. Příkladem může být hned klíčové slovo této práce bean, které by překladem do českého ekvivalentu (fazole, bob, zrno,...) zcela znepřehlednilo text práce a především zmátlo čtenáře, kterému již prošla pod rukama některá odborná publikace o tomto tématu. Ovšem některá slova překladem do češtiny neztrácejí svůj původní význam a působí přirozeněji (např. web container webový kontejner). Z těchto důvodů se snažíme o nalezení jednoznačného termínu v češtině a při jeho prvním výskytu v textu se uvádí s anglickým ekvivalentem v kulatých závorkách. Český termín pak bude důsledně používán v celé práci, ovšem pokud by se jevil jako zavádějící, bude zvolen anglický originál, který bude skloňován (např. za pomocí beanů). 1.2 Odkazy Veškeré zdroje, ze kterých tato práce čerpá, jsou uvedeny v kapitole 8 (Seznam použité literatury). Pokud je někde v textu uvedena přímá citace, pak je označena hranatými závorkami, v nichž je uvedeno číslo odkazu se zkratkou cit. a za ní číslo stránky1. Například citace z odkazu 6 stránka 17 bude vypadat takto: [16 cit. 17]. Většina odkazů použitých v této práci je v anglickém jazyce, a proto se citace uvádějí v českém jazyce a jsou autorským překladem. Uvedení hranatých závorek s číslem odkazu za nějakým pojmem nebo větou neznamená citaci, ale pouze uvádí zdroj, kde je pojem vysvětlen, nebo kde se můžeme zevrubněji s danou problematikou seznámit. Příkladem může být:... Hibernate [18]..., kde odkaz 18 za názvem Hibernate odkazuje na oficiální stránky s dokumentací a referenčním manuálem k produktu Hibernate. 1.3 Schémata a zdrojové kódy V této práci se vyskytuje celá řada schémat a kusů zdrojových kódů, které by měly čtenáři usnadnit pochopení dané problematiky. Ke správné interpretaci některých schémat (především diagramů tříd) se předpokládá alespoň základní znalost UML notace 2.0. Jak v diagramech tříd, tak ve zdrojových kódech se pro zpřehlednění názvu definuje každé rozhraní počátečním písmenem I a až za ním následuje logický název. Například rozhraní Operace se bude definováno jako IOperace. Podobně je tomu i u abstraktních tříd, které jsou uvozeny písmenem A. Veškeré názvy tříd, rozhraní, atributů či metod uvedené v běžném textu budou označeny kurzívou stejně tak jako výše zmíněné rozhraní IOperace. 1 V případě odkazu na internetové stránky se číslo stránky neuvádí. 4

2 Java Enterprise Edition 5, základní pojmy Tato kapitola přináší obecný vhled do Java Enterprise Edition 5 společnosti Sun Microsystems (dále jen Java EE, nebo JEE) a vysvětluje základní pojmy, které jsou nezbytné pro další studium EJB 3.0 technologie. V literatuře se také můžeme setkat s pojmem Java 2 Enterprise Edition (J2EE), označuje starší zápis platformy, kde číslo verze bylo určeno třemi znaky (např. J2EE 1.4). Tvůrci specifikace se rozhodli vynechat z názvu specifikace číslo 2 stejně jako číslo 1 z čísla verze (revision numer) [7]. Proto dostal nástupce verze 1.4 označení Java EE 5 (JEE 5), což je podle staršího zápisu ekvivalentní s označením Java 2 EE 1.5 (J2EE 1.5). Zdůrazněme, že v textu celé práce budeme obecné označení Java EE (JEE) vztahovat pouze k verzi Java EE 5. 2.1 Java EE specifikace Java EE je specifikace, nikoli konkrétní produkt. Definuje vstupy a výstupy JEE kontejneru bez ohledu na konkrétního výrobce. Je to standard, díky kterému je zajištěna snadná přenositelnost aplikací mezi jednotlivými platformami. Specifikace je tvořena rozsáhlou sadou API. Obrázek 2-1 zakresluje dostupnost API v jednotlivých JEE kontejnerech. Pro stručné seznámení s funkcionalitou jednotlivých API postačí JEE tutorial [1]. Některými API, např. Java persistence (JPA), Java transaction (JTA), Web Services, se budeme podrobněji zabývat v následujících kapitolách této práce. Schéma 2-1 JEE API, převzato z [1] 5

2.2 Java EE platforma Java EE platforma je široce rozšířená provozní (runtime) platforma pro vývoj, nasazení a běh enterprise aplikací v jazyce Java. Cílem JEE platformy je poskytnout vývojářům rozsáhlou sadu specifikací (APIs), pomocí níž je možné snižovat časovou náročnost vývoje, redukovat složitost a zvyšovat výkon enterprise aplikací [1 cit.1]. Java EE platforma je určena Java EE specifikací a poskytuje vícevrstevný distribuovaný aplikační model. To znamená, že jednotlivé části aplikace mohou běžet na různých zařízeních [10 cit. 6]. Jinými slovy řečeno: JEE platforma implementuje JEE specifikaci. JEE platforem existuje celá řada a jsou uzpůsobeny konkrétním hardwarovým prostředím, či aplikačním nárokům. Příkladem mohou být platformy pro různé operační systémy (Windows, Unix), platformy pro provoz aplikací v clusterech, či platformy pro efektivní vývoj aplikací s nižšími hardwarovými nároky. 2.2.1 Java EE kontejner Pokud tvoříme jednoduché Java třídy v Java SE, potřebujeme na jejich spuštění JVM, což je fakticky kontejner pro běh Java SE aplikací. Pro běh enterprise aplikace také potřebujeme kontejner, který je obecně nazýván Java EE kontejner. V rámci Java EE kontejneru existují 4 kontejnery: EJB, Web, aplikační klient a aplet. 2.2.2 JEE aplikační server JEE aplikační server, nebo také jen JEE server, je konkrétní JEE kontejner, který implementuje JEE specifikaci a je poskytovatelem JEE platformy. To, že je JEE platforma definována JEE specifikací znamená, že může existovat více implementací konkrétní verze JEE specifikace. Pokud má být nějaký aplikační server nazván JEE aplikačním serverem, tak musí bezpodmínečně implementovat celou JEE specifikaci. Díky komponentové architektuře JEE specifikace si může každý výrobce serveru (vendor) implementovat jednotlivá API JEE specifikace buď sám, nebo využít některých existujících řešení. Pokud se budeme striktně držet vývoje aplikace dle JEE specifikace, bude nám prakticky jedno, na jakém JEE aplikačním serveru naši aplikaci nasadíme. Mělo by bez výjimky platit Write Once, Run anywhere 2 [7]. 2 Write Once, Run anywhere (WORA) jedná se o dlouhodobý strategický záměr firmy Sun Microsystems, jehož cílem je bezproblémová přenositelnost aplikací, popř. aplikačních modulů, mezi jednotlivými poskytovateli JEE platformy[7] 6

Pozorný čtenář by si mohl položit otázku, proč tedy existuje celá řada jak komerčních tak i open-source řešení aplikačních serverů, když, jak bylo psáno v předchozím odstavci, by mělo být možné nasadit naší aplikaci na jakémkoli JEE serveru. Je třeba zdůraznit, že právě díky jednotné specifikaci, jednoznačnému určení co vše má aplikační server poskytovat, musí logicky existovat i určitá omezení. Omezení v tom smyslu, že JEE specifikace nedefinuje ani nemůže definovat veškerou funkcionalitu, která by se mohla hodit při vývoji konkrétní aplikace. Jednotliví výrobci se často liší: 1. Jakým způsobem implementují jednotlivá API JEE specifikace. Například JEE aplikační server JBoss [19] implementuje JPA API (viz. kapitola 4) pomocí ORM frameworku Hibernate [18], narozdíl od JEE aplikačního serveru GlassFish, který implementuje JPA API pomocí TopLink Essentials [17]. Rozdíly v implementaci obvykle mívají za následek různé požadavky serveru na hardware a v konečném důsledku přímo ovlivňují rychlost nasazování a provozu aplikací. 2. Jaké nestandardní služby mimo JEE specifikaci poskytují. Např. aplikační server JBoss využívá pro logování knihovnu Log4j, kterou můžeme využít i při logování v naší aplikaci. Při využívání nadstandardních služeb fakticky snižujeme možnost přenositelnosti aplikace mezi aplikačními servery3 a především zvyšujeme závislost na konkrétní platformě. Pro zvolení vhodného aplikačního serveru musíme zvážit, zdali si při tvorbě aplikace vystačíme s JEE specifikací, nebo bychom rádi využili některých speciálních služeb, které konkrétní server může poskytovat. Dále bychom si měli promyslet, zda některý z open-source produktů vyhovuje našim požadavkům, nebo budeme preferovat komerční řešení. Některé servery jsou vhodnější pro vývoj aplikací na localhostu, jiné jsou uzpůsobeny pro provoz aplikací v rozsáhlém produkčním prostředí (řeší např. clustering a mirroring). Není zde prostor pro popisování a porovnávání jednotlivých aplikačních serverů. Pro veškeré ukázky zdrojových kódů v této diplomové práci platí, že jsou platformě nezávislé a mohou být nasazeny a spuštěny na jakémkoli aplikačním serveru implementujícím specifikaci JEE 5. 3 Příklad s knihovnou Log4j je pouze ilustrativní a ve většině případů není problém ji distribuovat s aplikací i do ostatních aplikačních serverů. 7

2.2.3 JEE webový kontejner Nejprve si připomeňme, že JEE webový kontejner (někdy též servlet kontejner) je součástí JEE kontejneru a je tedy dostupný v kterémkoli JEE serveru. Webový kontejner implementuje část JEE specifikace (JSP API a Servlet API), která poskytuje běh webových komponent a úložiště html stránek. Webový kontejner může existovat samostatně, ne jen v rámci JEE kontejneru, a může zajišťovat běh statických, či dynamických webových aplikací. JEE servery jsou velice robustní, poskytují řadu služeb a jsou navrženy pro efektivní běh aplikací, což klade nemalé požadavky na výkon stanice, na které jsou provozovány. Při vývoji a testování GUI webových aplikací dochází k častým úpravám kódu a následně k jejich opětovnému nasazování a spouštění. Neustálé opakování takovéhoto postupu je velice neproduktivní. To bývá jedním z důvodů, proč vývojáři nezřídka volí hardwarově méně náročný samostatný webový kontejner. Jedním z nejrozšířenějších samostatných webových kontejnerů je Apache Tomcat od společnosti The Apache Software Foundation. Apache Tomcat poskytuje i některé služby nad rámec JEE webového kontejneru (např. definice datasource ve verzi 5 a 6) [9] a je třeba zdůraznit, že samostatné webové kontejnery nemusí sloužit pouze k vývoji aplikací. Ve webovém kontejneru lze s dalšími knihovnami (komponentami) aplikace nasadit tzv. light-weight kontejner (např. Spring 2.5), který fakticky existuje jako alternativa (nadstavba) ke službám JEE, včetně IOC kontejneru, což může být dalším důvodem upřednostnění samostatného webového kontejneru před aplikačním serverem. Na samostatném webovém kontejneru ovšem nelze nasadit a spustit EJB komponenty4, a proto pro potřeby vývoje a nasazování EJB komponent budeme muset zvolit nějaký JEE server. 2.2.4 EJB kontejner EJB kontejner slouží k běhu EJB beanů. Nejdůležitější zodpovědností kontejneru je zajistit bezpečné transakční distribuované prostředí pro provoz beanů [5 cit. 59]. Kontejner implementuje vlastní verzi IOC, díky němuž je možné volat naše beany z klientů, nebo jiných beanů bez přímého použití kontejnerového API prostřednictvím anotací nebo xml descriptoru. Takto můžeme kontejneru definovat, jaké EJB beany chceme v kódu použít a kontejner nám za běhu zajistí 4 Existují i určité možnosti, jak nasadit EJB komponenty mimo JEE server (např. na webovém kontejneru). Může se jednat např. o plug-in OpenEJB pro Tomcat, nebo prostřednictvím Springu. 8

jejich instance. Kontejner se v podstatě chová jako neviditelný prostředník mezi klientem a beanem a zajišťuje životní cyklus beanů. V následujícím výčtu je definováno několik základních služeb, které jsou díky kontejneru k dispozici. Řízení transakcí: Transakcí rozumíme jednotku práce (např. sled volaných metod), která musí být vykonána v kuse bez přerušení a ve zvoleném pořadí. EJB framework poskytuje dva typy transakcí: Kontejnerem řízené transakce, kdy kontejner zajistí start a commit (popř. rollback, když se vyskytne chyba) transakce. Beanem řízené transakce umožňující vykonávat persistentní operace definované pomocí atributů (anotací) spjatých s našimi EJB beany, kdy má vývojář stoprocentní kontrolu nad průběhem transakce. Této kontroly může být dosaženo z klienta nebo přímo z EJB beanu. Bezpečnost: je jedna z nejdůležitějších výhod EJB frameworku a hlavním důvodem pro využití vícevrstevného aplikačního modelu. Správa rolí a oprávnění pro volání metod je možné řešit již v Java SE programováním oproti Java security API. EJB framework značně zjednodušuje definici oprávnění pro metody EJB beanů prostřednictvím nastavení atributů (anotace nebo xml). Životní cyklus a zdroje: EJB kontejner řídí zdroje (např. vlákna či databázová spojení), které využívají EJB beany a řídí životní cyklus beanů. Vytváří a likviduje instance beanů, pasivuje je prostřednictvím serializace do sekundární paměti a aktivuje je zpět. Kontejner má schopnost znovu použít instance beanů tak, jak uzná za vhodné, a dokáže automaticky zvyšovat či snižovat počet dostupných instancí beanů, díky čemuž se značně zefektivňuje práce s pamětí a snižují hardwarové nároky na PC, na kterém běží JEE server. Vzdálený přístup: EJB framework poskytuje vývojářům velice snadné definování EJB beanů, jejichž metody se mají volat z klientů běžících ve vzdálených JVM. Kontejner zajistí transformaci lokálních EJB beanů do tzv. distribuovaných síťových objektů sloužících pro přenos dat mezi JEE serverem a vzdáleným klientem. Metody EJB beanů je možné volat i z jiných programovacích jazyků. Podpora pro souběžné požadavky (requesty): Kontejner se postará o obsluhu souběžně volaných EJB beanů z klienta, aniž bychom museli psát více vláknový obslužný kód a zajišťuje podporu řízení vláken. 9

Pokud více klientů volá metody instance beanu, kontejner zeserializuje requesty a díky tomu dovoluje pouze jednomu klientovi zavolat instaci beanu v jednom okamžiku. Pokud k souběhu volání dojde, ostatní klienti jsou nejprve přesměrováni na jiné instance beanu, nebo jsou přinuceni počkat, dokud se původní instance stane opět dostupnou. Vývojáři tak ušetří spoustu času, který by museli věnovat psaní vláknově bezpečného kódu. Clustering a vyrovnávání zátěže (load-balancing): Clusterem máme na mysli paralelní práci více výpočetních jednotek pracujících společně za určitým cílem. V JEE je clustering obecně práce nad clusterem a poskytuje dvě zásadní služby: škálovatelnost (scalability) - možnost pružně přidávat resp. odebírat výpočetní stanice do resp. z clusteru a tak zásadním způsobem ovlivňovat celkovou výkonnost clusteru a vysokou dostupnost (high availability), zachovat dostupnost clusteru při výpadku některé ze stanic clusteru a stávající požadavky rovnoměrné rozdělit mezi zbylé funkční stanice. Z definice specifikace není EJB kontejner povinen podporovat clustering a vyrovnávání zátěže, ovšem téměř všichni výrobci kontejnerů více méně tyto služby podporují 5. Je potřeba vzít v úvahu, že se jedná o tzv. nestandardní (viz. 2.2.2) služby a jejich konfigurace může být kontejner od kontejneru odlišná. Na druhé straně je třeba si uvědomit, že výhody, které přinášejí tyto služby při řešení obsluhy mnoha souběžných requestů či při provádění náročných algoritmů, jsou dosti vysoké a změna EJB kontejneru resp. aplikačního serveru nebývá tak častá. 2.3 Java EE BluePrints Společně se JEE specifikací jsou vyvíjeny a dokumentovány tzv. BluePrints, které vývojářům poskytují pravidla, vzory a zdrojové kódy pro vývoj, ladění a nasazování JEE aplikací [8]. Motivací vzniku BluePrints byly především neustále se opakující otázky vývojářů a analytiků, jakým způsobem řešit řadu problémů při vývoji aplikací. Ukázalo se, že samotný tutoriál[1] s jednoduchými ukázkami kódu je jako teoretický základ pro produkci složitějších aplikací nedostačující. BluePrints obsahují BluePrints Solution Katalog[11], J2EE Patterns Catalog[12] i řadu dalších kompletů. Jedním z nich je Enterprise definující 5 některé JEE servery podporují clustering pouze nad celou JEE aplikací (ear), nikoli nad samostatným EJB modulem 10

modelové řešení, které je postaveno nad Java SE a Java EE platformou. Seskupuje souhrn pravidel (pokynů), návrhových vzorů a příkladů řešení reálných problémů ve zdrojových kódech, které umožňují tvorbu robustních škálovatelných přenosných aplikací. Dalším kompletem BluePrints je Performance zabývající se problematikou výkonnosti a škálovatelnosti aplikací. Nabízí celou řadu strategií, jak upravit a vylepšit výkonnost buď nově vznikající či již existující aplikace. [8] Kromě výše zmíněných kompletů existuje mnoho dalších sestav, avšak cílem této práce není kompletně vyjmenovat všechny kategorie BluePrints. Měli bychom mít na paměti, že při analytické fázi je vhodné pokusit se vyhledat již existující řešení. Nemělo by být cílem analytika vymyslet vždy originální řešení daného problému. Není nutné objevovat již objevené. Literatura [8] je právě tím místem, kde by mělo začínat hledání, jak řešit konkrétní problémy JEE. 2.3.1 JEE BluePrints Katalog BluePrints katalog se dělí do čtyř logických kategorií6. Každá kategorie katalogu je rozdělena do klíčových otázek (problémů) a nabízí různé strategie, vzory a pokyny pro jejich řešení. V následujícím výčtu jsou stručně komentovány jednotlivé kategorie. [11] AJAX podporuje způsob návrhu a tvorby JEE aplikací využívajících technologii AJAX. Web tear prezentuje řadu řešení pro vývoj webové vrstvy JEE aplikací s použitím JEE technologií JSF, Servlets, JSPa JSTL. Business logic soustřeďuje se na vrstvu JEE aplikace, která obsahuje obchodní a integrační logiku. Technologie použité v této vrstvě jsou především EJB, JSM, XML, JDBC, JEE Conectors. Web services řeší problematiku webových služeb a servisně orientované architektury (SOA) aplikací. 2.3.2 JEE Patterns Součástí BluePrints je katalog návrhových vzorů [12] a nově Core JEE paterns [13] řešící řadu typických programátorských problémů. Je potřeba zmínit, že návrhové vzory existují v obecné podobě [14] a je možné je implementovat prakticky do všech objektově orientovaných jazyků. 6 V době sepisování této práce existuje kompletní katalog pouze pro starší verzi J2EE 1.4 a pro verzi JEE 5 zatím není kompletní. 11

2.3.3 Návrhové vzory Návrhové vzory obsažené v Java EE Bluepritns jsou už konkrétní ukázkou implementace některých návrhových vzorů za pomocí Java 5 a JEE 5, využívajících nových vlastností jazyka Java verze 5 jakou jsou například generika a anotace. V následujícím výčtu si vyjmenujeme a stručně popíšeme několik obecných návrhových vzorů, jejichž konkrétní aplikace se vyskytuje v prototypu aplikace SOB (kap. 5) a které by měl bezpodmínečně znát každý vývojář či softwarový architekt pracující s objektově orientovaným programovacím jazykem. Všechny níže uvedené vzory můžeme nalézt v [14]. 2.3.3.1 Singleton (jedináček) Jedná se o konstrukci, která zajistí, aby v celé aplikaci existovala pouze jediná instance dané třídy. K této instanci se přistupuje pomocí statické metody a samotný konstruktor jedináčka je privátní (tzn. nelze vytvořit instanci jedináčka voláním konstruktoru z jiných tříd). Schéma 2-2 Model View Controler 2.3.3.2 Model View Controler MVC Dnes už standardní přístup (princip) oddělení datové vrstvy a aplikační logiky (model) od vrstvy, která zpracovává požadavky klienta na aplikaci (controler) a od vrstvy starající se o prezentaci (zobrazení) dat na klientovi (view). V Javě existuje celá řada MVC frameworků, které podporují a usnadňují vývoj JEE aplikací podle principů vzoru MVC. Součástí JEE je komponentově orientovaný MVC framework JSF. Z ostatních můžeme uvést např. Struts, Struts2, Webwork, Spring MVC, Stripes, Tapestry.... Na schématu 2-2 je naznačen způsob komunikace mezi jednotlivými vrstvami a ostatními systémy. U větších systémů může být více než 12

jenom tyto tři vrstvy popsané vzorem MVC (viz. kapitola 2.4 Architektura JEE aplikací). 2.3.3.3 Data Access Object DAO Smyslem tohoto vzoru je oddělení vrstvy přístupu k datům od vrstvy aplikační logiky. DAO se programuje striktně proti rozhraní a implementace DAO rozhraní zajišťuje přístup k datům konkrétním způsobem (schéma. 2-3). V aplikaci můžeme využít více implementací konkrétního DAO rozhraní podle toho, jaký přístup nám bude pro konkrétní získávání více vyhovovat. Např. JPA implementace se bude hodit pro snadné získání a manipulaci s namapovaným objektem. Oproti tomu může být v některých případech efektivnější využít implementaci např. pomocí JDBC (složité dotazy přes více tabulek nutnost optimalizace a efektivnosti dotazů). Snadné přepínání jednotlivých implementací tohoto vzoru můžeme zajistit pomocí AbstractFactory. Schéma 2-3 implementace DAO tříd, jejichž účelem je perzistence třídy faktura 2.3.3.4 Facade Pokud se některá část systému či komponenta stává příliš složitou a komunikace s ostatními subsystémy či komponentami se s přibývající složitostí čím dál více znepřehledňuje, pak přichází prostor pro využití návrhového vzoru Facade, který doporučuje nahrazení početné sady veřejných metod rozmístěných v mnoha třídách subsystému jedním rozhraním, které bude vystaveno jako fasáda pro komunikaci s ostatními subsystémy. Celá problematika je velice dobře zřetelná ze schématu 2-4. 13

Schéma 2-4 Naznačení způsobu komunikace Subsystému 1 s ostatními subsystémy prostřednictvím návrhového vzoru Facade 2.4 Architektura JEE aplikací V této podkapitole se budeme věnovat dvou základním konceptům JEE aplikační architektury. Nejprve si popíšeme vícevrstevnou architekturu a její nejčastěji definované vrstvy a v druhé časti nastíníme problematiku komponentové architektury. Je třeba zdůraznit, že oba koncepty architektur nejdou proti sobě, ale vzájemně se doplňují. Uplatňování obou konceptů patří k tzv. best practice při vývoji JEE aplikací. 2.4.1 Vícevrstevná architektura JEE platforma zajišťuje podporu vývoje serverové (server-side) a klientské (client-side) části distribuovaných vícevrstevných aplikací. Takovéto aplikace bývají zpravidla sestaveny ze tří základních vrstev (tier7) definovaných JEE (schéma 2-5): 1. klientská vrstva (client-tier): poskytuje uživatelské rozhraní a podporuje mnoho typů klientů (mobilní zařízení, síťová zařízení, PC...) 2. střední vrstva (middle-tier): střední vrstva je tvořena jedním nebo více moduly (může obsahovat více pod-vrstev sub-tier) a zajišťuje klientské služby (client services) prostřednictvím webového kontejneru (prezentační vrstva) a služby obchodní logiky aplikace díky EJB kontejneru (vrstva obchodní logiky). 7 v literatuře se můžeme setkat i s pojmem layer 14

3. EIS vrstva (EIS tear popř. back-end tear): bývá tvořena zpravidla databázovým systémem a je přístupná standardními JEE API. Schéma 2-5 tří základní vrstvy v JEE aplikacích - převzato z [10] JEE vrstvy aplikace zobrazené na schématu 2-5 se většinou ještě dělí na pod-vrstvy, které mohou prostupovat napříč třemi základními vrstvami. Smyslem rozdělení aplikace do vrstev je především při high-level pohledu logické oddělení jednotlivých funkcionalit od sebe a udržení si představy o tom, co má jaká vrstva resp. pod-vrstva v aplikaci na starosti. Počet vrstev aplikace vždy záleží na její velikosti a členitosti - jaké služby poskytuje a pomocí jakých prostředků dosahuje požadovanou funkcionalitu. Schéma 2-6 znázorňuje nejčastěji používané vrstvy u středně velkých JEE systémů. Nižší vrstva (na schématu zprava) by měla být vždy nezávislá na vyšší vrstvě, která se nalézá vlevo od nižší vrstvy. Například vrstva obchodní logiky, v tomto případě nižší vrstva, by nikdy neměla být závislá na vyšší prezentační vrstvě. To znamená, že jakákoliv změna prezentační logiky neovlivní funkčnost vrstvy obchodní logiky. Opačně tento princip samozřejmě neplatí ani platit nemůže, protože vyšší vrstvy jsou závislé na vrstvách nižších. Pokud nastane v nižší vrstvě chyba, pak se tato chyba promítne do všech vyšších vrstev. Nižší vrstva by nikdy neměla volat metody vyšší vrstvy, jinak by došlo k porušení závislosti mezi nižší a vyšší vrstvou. Na schématu 2-6 je naznačeno volání jednotlivých vrstev resp. závislost. Šipka vychází vždy ze závislé vrstvy (pozn. přerušovaná šipka značí pouze odpověď, nikoli závislost). 15

Schéma 2-6 naznačuje závislost jednotlivých vrstev. Zprava plně nezávislá EIS vrstva. 2.4.1.1 Prezentační vrstva (view tear) Prezentační vrstva se stará o zpřehlednění a usnadnění komunikace klienta se systémem prostřednictvím graficky uživatelského rozhraní (GUI). Presentační vrstva se obvykle skládá z webové a klientské vrstvy. To odpovídá fyzickému rozdělení do dvou částí. Serverový front-end controler (dále jen kontroler), který je umístěn na serveru a aplikační klient (internetový prohlížeč, dále jen klient), který je umístěn u uživatele systému. Prezentační vrstva prostupuje klientskou a střední JEE vrstvou. Kontroler přijímá a validuje požadavky od klienta. Na základě těchto požadavků získává data z vrstvy obchodní logiky, generuje je do formátu (x)html nebo xml a posílá je prostřednictvím http protokolu klientovi. Kontroler bývá zpravidla řešen nějakým MVC frameworkem (viz. kap. 2.3.3 MVC) Klient posílá požadavky na server prostřednictvím http nebo https protokolu metodou get, nebo post. Klient je z principu tzv. tenký klient, protože na něm neběží žádná obchodní logika, stará se pouze o zobrazení (x)html nebo xml dat a může validovat požadavky prostřednictvím skriptu (Java script, VB scrtipt). 2.4.1.2 Vrstva Obchodní logiky (business tear) Vrstva obchodní logiky může být tvořena za pomoci různých frameworků či knihoven, nebo jen s Java SE, ale my se v této práci budeme zabývat výhradně 16

tvorbou obchodních služeb pomocí EJB frameworku a JPA API. Takto definovaná vrstva obchodní logiky se v JEE aplikacích dělí do dvou částí: doménový model (domain model) a služby obchodní logiky (services). Doménový model je reprezentován entitami8, které nesou data o svém stavu. Jinými slovy doménový model reprezentuje stav systému, který je ukládán resp. načítán vrstvou přístupu k datům do EIS vrstvy. Entity odpovídají specifikaci POJO a jsou definovány JPA API obsahují anotace nad atributy resp. metodami definující jejich názvy ve zdroji dat a jejich omezení (podrobně popsáno v kapitole 4 JPA). Služby obchodní logiky jsou JavaBean komponenty (EJB beany9) zajišťující požadovanou funkcionalitu. Vývojáři se mohou při využití EJB beanů skutečně soustředit na implementaci obchodní logiky, zatímco EJB kontejner se postará o veškerou podporu (viz. kap. 2.4.4) nutnou pro běh kódu. EJB beany musí z definice obsahovat rozhraní a implementaci (viz kapitola 3 EJB 3.0). Striktním přístupem programování proti rozhraní jsou nejprve vydefinovány funkce, které má jednotlivá služba poskytovat, a až následně vytvořena implementace dané služby (implementací může být více). Výhodou takového postupu je snadná změna implementace obchodní logiky, aniž by se muselo zasahovat do jiných tříd náležících do různých vrstev. Při návrhu vrstvy obchodní logiky je možno držet se objektového paradigmatu rich domain model velice dobře popsaného v [16], nebo využít tzv. anti-vzor (antipatern) anemic domain model. Každý z přístupů nese určité výhody a nechá se použít při tvorbě vrstvy obchodní logiky s využitím frameworku EJB [4]. S přihlédnutím k tomu, že hlavním cílem EJB frameworku je podpora produkce rozsáhlých podnikových aplikací vyvíjených desítkami programátorů, pokusíme se v následujícím textu nastínit některé možné komplikace při využití domain modelu a proč je stále, nejen v JEE ale obecně, při tvorbě rozsáhlých systémů v OOP je jednou z best practice využívání anemic domain modelu. Anemic domain model je nazýván anti-vzorem [15], protože jde proti standardnímu objektově orientovanému pohledu (domain model), kdy každá doménová třída nese nejen data ale i zodpovědnost za určité činnosti aplikace poskytuje služby (obchodní logiku v metodách). V rozsáhlých aplikacích se domain model problematicky uplatňuje především z těchto důvodů: 8 Ve starší verzi EJB existovaly entity beany, které lze sice v EJB 3.0 použít, ale již nejsou dál vyvíjeny. Místo toho existují samostatné entity definované JPA, které lze využít i bez použití EJB frameworku. 9 Podrobněji o různých typech EJB beanů v kapitole 3. 17

Pokud je v doménové třídě příliš mnoho metod zajišťujících obchodní logiku, nebo jsou tyto metody rozsáhlé, stává se doménová třída nepřehlednou a obtížně udržovanou. Při použití anemic domain modelu se tato problematika řeší tvorbou více služeb. V některých případech bývá velice obtížné určit, která z doménových tříd má zajišťovat konkrétní obchodní službu. Jedná se zejména o případy, kde existuje požadavek na zpracování vícedoménových objektů. Tento problém se týká obecně delegování zodpovědnosti za transakce, které probíhají napříč doménovým modelem.10 Jednotlivé služby doménové třídy mohou obsahovat celou řadu metod, které k dané doméně logicky patří, ale každá metoda může využívat zcela jiných prostředků (knihoven). Z tohoto důvodu je u rozsáhlejších systémů za jejich tvorbu zodpovědný právě vývojář specializující se na konkrétní typ prostředků. Sestavování a udržování třídy, jejíž metody programuje více vývojářů, se může značně komplikovat. Jako příklad takového problému můžeme uvést skupinu metod využívajících složitějšího matematického aparátu a jednoduché validace. Obě skupiny metod do doménové třídy logicky patří, ale není efektivní zatěžovat zkušeného vývojáře (senior developer) tvorbou jednoduchých validací. Při využívání EJB entitních tříd pro datové objekty nelze bezezbytku uplatnit koncepci domain modelu, a to především z důvodu, že entitní třídy musejí splňovat specifikaci POJO. V některých třídách rich domain modelu nemusí být žádoucí uveřejňovat např. nějakou set metodu, či doménová třída s veřejným prázdným konstruktorem nemusí splňovat existenční podmínky instance objektu. V takových případech je o poznání těžší namapovat entity na databázovou strukturu. Tvorba testů jednotlivých metod obchodní logiky pro složitější domain model oproti testování jednotlivých metod služeb může být komplikovanější. Nutno podotknout, že i anemic domain model nese určité nevýhody, a to především skutečnost, že i když služby obchodní logiky pracují s poměrně složitým objektovým datovým modelem, jejich tvorba se značně přibližuje procedurálnímu 10 Domain model samozřejmě může obsahovat i služby obchodní logiky definující jednotlivé transakce, rozdíl oproti anemic domain modelu je v tom, že služby domain modelu by měly poskytovat pouze fasádu (návrhový vzor Facade viz. kap. 2.3.3) tj. volat pouze metody doménových tříd, tedy nezpracovávat žádná data. 18

programování a může tak docházet k částečné duplicitě kódu jednotlivých služeb. Je vždy na analytikovi, jakou strategii zvolí, a je třeba zdůraznit, že finální rozhodnutí by mělo vždy přinášet více výhod. Výhodou anemic domain modelu je především snadnější udržovatelnost projektu při práci ve větším počtu vývojářů a snadná změna implementace služeb. Oproti tomu výhoda domain modelu je ve stoprocentním využití OOP, a tím minimalizace duplicitního kódu. 2.4.1.3 Vrstva přístupu k datům (data acess tear11) Vrstva přístupu k datům se stará o persistenci datového modelu vrstvy obchodní logiky. Je tvořena DAO objekty (kap 2.3.3) a měla by být jediným místem v aplikaci, odkud je možný přístup do EIS vrstvy. Při použití EJB frameworku jsou DAO objekty EJB beany stejně jako služby obchodní logiky. Každý DAO objekt má na starosti persistenci jedné konkrétní doménové třídy. Většinou zajišťuje základní CRUD operace, a pokud je třeba, tak mohou být vyspecifikovány další metody zohledňující speciální potřeby aplikace na persistenci dané entity. Tato vrstva bývá implementována s využitím některého z ORM frameworků odstiňujícího DAO objekty od implementace konkrétního datového zdroje. ORM frameworky mají vestavěný dotazovací jazyk (obecně OQL), který umožňuje pracovat s datovým zdrojem tak, jako by se jednalo o objektovou databázi a způsob dotazování je ovlivněn pouze doménovým modelem, nikoli datovým zdrojem. OQL dotazy jsou ORM frameworkem převedeny na dotazy odpovídající způsobu dotazování dle využitého datového zdroje. Například pokud budeme využívat jako datový zdroj relační databázi Oracle, tak námi psané objektové dotazy v OQL budou transformovány do podoby SQL s příslušným dialektem databázové verze. V dnešní době existuje celá řada ORM frameworků, které se od sebe liší jak způsobem dotazování, tak způsobem mapování doménových tříd. V JEE existuje pro ORM standard JPA API, což je specifikace funkcí, které každý JEE ORM framework poskytuje. JPA taktéž definuje dotazovací jazyk JPQL a způsob mapování EJB entit na datový zdroj. JPA nás tedy odstiňuje nejen od konkrétního datového zdroje, ale také od ORM frameworku, a z toho důvodu nám bude při tvorbě datové vrstvy prostřednictvím JPA API jedno, na jakém JEE serveru bude naše aplikace nasazena a jaký typ datového zdroje bude pro produkční verzi vyvíjené aplikace zvolen. 11 nebo také persistence tear viz. [4] 19

2.4.1.4 EIS vrstva EIS vrstva slouží jako zdroj dat pro enterprise aplikace. EIS vrstva obsahuje jeden nebo více systémů jako jsou například relační databáze, mainframe systémy, objektové databáze, FTP file systémy aj. pro trvalé ukládání dat. Vrstva obchodní logiky zpravidla pracuje v jednom okamžiku jenom se zlomkem dat a jejich stav se průběžně načítá resp. ukládá do EIS vrstvy. JEE platforma poskytuje přístupy do různých typů EIS technologií: JEE Konektorová architektura (Connector architecture) je normou pro integraci JEE aplikací s existujícími EIS systémy využívající adaptéry (resource adapters12), které mohou být umístěny do JEE serverů. Zprávové služby (JMS API) definují způsob asynchronního zasílání zpráv mezi JEE zprávovými systémy. JDBC API slouží pro spojení JEE aplikací s relačními databázemi. Umožňuje otevírání a uzavírání nových spojení s databází, volání SQL dotazů, spouštění databázových funkcí, startování transakcí, zapsání (commit) popř. vyrolování (rollback) transakcí. JEE platforma umožňuje jak synchronní tak asynchronní integraci pro přístup JEE aplikace k EIS vrstvě. Asynchronní systémy jsou vhodnější pro kvalitní a spolehlivé vyměňování zpráv mezi systémy a zpravidla jsou i velice výkonným řešením. Oproti tomu synchronní systémy jsou jen těžko nahraditelné všude tam, kde je nutný přístup aplikace do více datových zdrojů a požadované zpracování musí proběhnout v přesném pořadí v rámci jedné transakce. 2.4.2 Komponentová architektura EJB framework je výhradně komponentovým frameworkem, což znamená, že jeho základními stavebními prvky jsou komponenty. Návrh a implementace systému za pomocí komponent je v pořadí třetí best practice dle metodiky RUP [21]. Zásadním přínosem komponentového systému je možnost snadnějšího a tedy i levnějšího rozšíření stávajícího systému, či nahrazení implementace stávajících komponent. Komponentová architektura se dělí do tzv. zásuvných modulů (plugin), které sdružují komponenty vykonávající určitou specifickou činnost. Klíčovými pojmy komponentové architektury jsou komponenta a rozhraní (API), jejichž význam a funkce si popíšeme v následujících podkapitolách. 12 Jedná se o technologii zásuvných modulů umožňující JEE serveru připojit se na různé druhy EIS systémů. 20

2.4.2.1 Rozhraní Rozhraní odděluje specifikaci od implementace. V jazyce Java se definuje klíčovými slovy public interface a jeho tělo je tvořeno pouze veřejnými (public) hlavičkami metod13. Hlavičky metod specifikují název metody a popřípadě její vstupní parametry a návratovou hodnou. Rozhraní nemůže obsahovat výkonná těla metod a ani žádné atributy. Veškerá logika (prostředky, jimiž se dosáhne požadovaného úkolu) je ponechána třídě, která implementuje dané rozhraní. Rozhraní naopak může obsahovat libovolný počet konstant a může dědit (vazba extend) z jiného rozhraní. Při tvorbě rozhraní se snažíme v systému nalézt metody, které se vyskytují nebo by se mohli vyskytovat napříč různými třídami a následně tyto metody rozdělit podle funkce k příslušným rozhraním. Jednotlivá rozhraní pak můžou obsahovat i sémantiku metod, neboli popis funkcí, vstupních parametrů, návratových hodnot a vyhazovaných (throws) výjimek prostřednictvím komentované dokumentace. V dokumentaci se taktéž můžou nalézat jistá omezení metod, popřípadě příklady jejich volání. Jedno rozhraní pak může být implementováno více třídami a jedna třída může implementovat více rozhraní narozdíl od abstraktní třídy, kdy každá třída může mít pouze jednoho předka. Pokud někde v kódu voláme metody specifikované rozhraním, pak je nikdy nevoláme přímo na proměnné třídy implementující toto rozhraní, ale vždy na proměnné popř. atributu typu rozhraní. Důsledným používáním atributů typu rozhraní místo samotných tříd získáváme značnou flexibilitu kódu. Kdykoli můžeme nahradit třídu implementující rozhraní, nebo přidat další typy tříd implementujících dané rozhraní, aniž bychom museli upravovat klientský kód14. Pro snadnou inicializaci rozhraní se využívají návrhové vzory např. Factory method, Factory, Facade, nebo můžeme využít služeb EJB kontejneru15, který realizuje inicializaci atributů prostřednictvím dependency injection (viz. kapitola 3.5), nebo jiného IOC kontejneru. Na schématu (2-7) je naznačena část bankovní aplikace, kde jsou definovány tři typy bankovních účtů pomocí tříd (BeznyUcet, Silver, Gold) implementujících rozhraní IBankovniOperace. Klienti jsou v tomto příkladu komponenty, které nevolají přímo jednotlivé instance tříd bankovních účtů, ale veškeré operace 13 V literatuře se můžeme setkat s pojmem signatura metody. Klientský kód v tomto kontextu znamená jakýkoliv kus kódu užitý v aplikaci, který používá proměnnou nebo atribut typu rozhraní 15 V Javě můžeme použít jakýkoliv IOC kontejner (např. Spring) 14 21

provádějí prostřednictvím rozhraní IBankovniOperace. Klient v tomto případě provede požadovanou bankovní operaci např. pošle peníze na jiný účet (odeslipenize) a nemusí vědět s jakým typem účtu pracuje. Každá třída účtu pak obsahuje vlastní implementaci operace. Třída BeznyUcet nejprve provede kontrolu, zdali je na účtu dostatečný zůstatek a pouze pokud ano, pak odešle peníze. Oproti tomu třída Silver může odesílat peníze do debetu -250000 a třída Gold do -1000000. Schéma 2-7 Ukázka nahrazení přímé vazby mezi jednotlivými implementacemi bankovního účtu a klientskými komponentami prostřednictvím rozhraní IBankovniOperace Výhodou takového návrhu je, že jednotliví klienti nejsou závislí na konkrétní třídě. Tím jsou eliminovány přímé vazby a je umožněna vysoká flexibilita a modularita celého modelu. Jednotlivé implementace mohou být snadno zaměňovány, rušeny a přidávány. Pokud bychom se například rozhodli ve výše zmíněném příkladu rozšířit systém o další typ účtu Platium, kde by neexistoval žádný limit při posílání peněz, pak jednoduše přidáme novou třídu, které bude implementovat rozhraní IBankovniOperace. 2.4.2.2 Komponenta Smyslem vytváření komponent je především lokalizovat znovupoužitelné části systému tak, aby každá komponenta systému poskytovala svému okolí určité funkce (služby). Tento princip zcela koresponduje s OOP. Jak komponenta, tak objekt zapouzdřují své chování a poskytují svému okolí komunikační rozhraní. Komponenta je fyzickou nenahraditelnou částí systému, která obsahuje implementaci a poskytuje realizaci množiny specifikovaných rozhraní [22 cit. 350]. 22

Jinými slovy každá komponenta obsahuje specifikaci (rozhraní) a zapouzdřuje implementaci specifikace. Na úrovni jazyka Java je komponentou každý kus zdrojového kódu zkompilovaného do souboru s příponou class. Takto vytvořené soubory nazýváme elementárními komponentami, které se zpravidla seskupují do archívů jar a přidávají se k aplikaci jako knihovny (library). Elementární komponenta může být třída (Class), rozhraní (Interface) nebo seznam (Enum). Je třeba zdůraznit, že rozhraní elementární komponenty není reprezentováno klasickým rozhraním, které jsme si popsali v kapitole 2.4.2.1, nýbrž ho specifikují všechny deklarace16 komponenty označené klíčovým slovem public. Při návrhu aplikace se ovšem nespokojíme pouze s elementárními komponentami na úrovni jazyka, nýbrž máme potřebu vytvářet vyšší celky, které si pro přehlednost pojmenujeme jako logické komponenty. Každá logická komponenta je tvořena několika elementárními komponentami, z nichž je definováno klasické Java rozhraní (interface) určené pro komunikaci s ostatními komponentami17 a jedna či více implementačních tříd. Další prvky jako např. abstraktní třídy, seznamy, soubory obsahující metadata atp. jsou volitelné. Příkladem takovýchto komponent z JEE prostředí jsou například servlet, JSP stránka, nebo EJB session beany (kap. 3.3). Z vyššího návrhového pohledu může být komponenta složena z více logických komponent. Logické komponenty pak můžeme seskupovat do tzv. zásuvných modulů, které lze snadno přidávat do aplikace. V případě EJB to jsou ejb-moduly komprimované do archivu *.jar, které kromě vlastních zkompilovaných zdrojových kódů obsahují deployment descriptor popisující způsob nasazení do JEE serveru. Jednotlivé komponenty EJB modulů mohou být přístupné ostatním aplikacím (jak vzdáleným tak lokálním detailněji popsané v kapitlole 3). 16 Deklaracemi elementární komponenty máme namysli, hlavičky metod, atributy, konstanty, názvy vnořených tříd(inner class) nebo samotnou deklaraci komponenty (název třídy, rozhraní nebo seznamu). 17 Rozhrání komponenty může být více, nebo mohou být nahrazeny návrhovým vzorem Facade 23

3 EJB 3.0 V této kapitole se detailněji seznámíme s EJB 3.0 frameworkem od společnosti Sun Microsystems. Popíšeme si jeho základní rysy, seznámíme se specifikací jednotlivých EJB 3.0 komponent a uvedeme si možnosti jejich využití při tvorbě střední vrstvy serverově orientované aplikace. V následujícím textu budeme mít zkratkou EJB vždy na mysli EJB verzi 3.0, pokud nebude výslovně uvedeno jinak. Jak již bylo naznačeno (kap. 2.4), EJB framework je navržen pro usnadnění vývoje střední vrstvy rozsáhlých škálovatelných podnikových aplikací (vrstva obchodní logiky a vrstva přístupu k datům viz. kap. 2.4.2 a 2.4.3). Využívá k tomu služby EJB kontejneru (kap. 2.2.4) starajícího se o řadu procesů, které běží na pozadí. Programátor se tak může soustředit na vývoj obchodní logiky a nemusí se zabývat psaním neustále se opakujícího servisního kódu18, který do značné míry činí nepřehledným zdrojový kód aplikace. 3.1 Enterprise java beany Enterprise Java beany (EJB) jsou serverové komponenty běžící v EJB kontejneru a slouží k zapouzdření obchodní logiky aplikace. Obchodní logikou máme na mysli zdrojový kód vykonávající funkční požadavky, které má vyvíjený systém splňovat. Například v systému elektronického bankovnictví budou EJB implementovat obchodní logiku v metodách provedprikazkuhrade a odeslivypisuctunaemail. Vyvoláním těchto metod provede klient příkaz k úhradě a obdrží zprávu o stavu účtu na jeho emailovou adresu. Klient v tomto případě může být buď lokální nebo vzdálený. Lokálním klientem je např. komponenta webové vrstvy (JSP nebo Servlet) nebo jiná EJB komponenta v rámci jedné JVM. Vzdáleným klientem může být obecně Java komponenta běžící v jiné JVM, nebo vzdálená webová služba. EJB beany dělíme podle způsobu komunikace s klientem na session beany a na message-driven beany. Session beany slouží k implementaci synchronní komunikace s klientem a Message-driven beany komunikují s klientem asynchronně. Podrobněji si celou problematiku implementace obou skupin EJB beanů popíšeme v kapitolách 3.2 a 3.3. Mezi EJB beany můžeme taktéž zařadit 18 V tomto případě myslíme obslužný kód, který nemá nic společného s obchodní problematikou (business service). Příkladem může být otevření databázového spojení před spuštěním transakce. 24

Entity19, kterým se budeme věnovat v kapitole 4 (JPA) a to z toho důvodu, že je lze nasadit i mimo EJB kontejner20. 3.2 Metadata - anotace nebo XML? Ještě než se pustíme do popisování jednotlivých EJB komponent, vysvětlíme si jakým způsobem je možné vytvářet metadata k EJB komponentám. Metadata, nebo-li popisná data EJB komponent, slouží k nastavení specifických vlastností. Určují jakým způsobem bude kontejner nakládat s EJB komponenty, popř. s jejich metodami či atributy. Metadata můžou ovlivňovat např. životní cyklus EJB komponent, ověřovat práva klienta pro přístup k obchodní metodě, nastavovat JNDI názvy EJB komponent, zajišťovat dependency injection komponentovým atributům nebo určovat typ EJB komponent21. Metadata můžeme vytvářet dvěma způsoby: buď pomocí anotací přímo v kódu EJB komponent, nebo pomocí XML souboru (deployment descriptor). Při interpretaci metadat platí princip konfigurace výjimkou (configuration by exception), kdy kontejner nastavuje základní provozní hodnoty (default), pokud nebyly zadány žádná nebo minimum metadat. Díky tomuto principu nemusíme ztrácet čas s detailním popisováním veškerých EJB komponent jen proto, že si je chceme spustit. Dalším pravidlem při čtení metadat je skutečnost, že EJB kontejner čte současně jak anotace tak XML a pouze pokud je pomocí XML i anotace nastavena stejná vlastnost, pak platí ta hodnota, která je nastavena v XML. O tom, zda-li použít anotace nebo XML nebo jejich kombinaci záleží vždy na preferenci vývojáře popř. na firemní metodice jakým způsobem tvořit a dokumentovat metadata. Podívejme se nyní na výhody jednotlivých konceptů. Anotace nám nepochybně přinášejí přehlednější kód. Je z nich jasně patrné chování třídy, popř. kusu kódu, a mohou tak částečně posloužit i jako zdroj dokumentace. Oproti tomu díky XML můžeme ponechat zdrojový kód EJB komponent bez závislostí na anotacích z balíčku javax.ejb.*. Navíc při jakékoli změně nastavení EJB komponenty nemusíme zasahovat do zdrojového kódu a provádět následnou kompilaci. Kombinování obou přístupů dohromady může přinést snadnější vývoj, kdy programátor používá výhradně anotace pro zpřehlednění kódu a při ladění a nasazování aplikace se může využít XML, které automaticky přepíše všechny anotace nastavující vlastnosti pro vývojové prostředí. 19 Pozor, neplést s Entity beany z EJB 2.1. Podrobněji o této problematice v kapitole 4. 21 Výčet možností není úplný a s jednotlivými typy metadat se budeme seznamovat v následujícím textu této práce. 20 25