EJB 2.x – úvod do J2EE technológie

Architektúra EJB 2.x, ktorá je súčasťou Java 2 Enterprise Edition (J2EE), sa stala akceptovaným štandardom pre budovanie distribuovaných, mission-critical aplikácií. Špecifikácia EJB robí z J2EE aplikačného servera solídny základ pre budovanie aplikácií, od ktorých sa očakáva, že budú bezpečné, škálovateľné a portabilné. A práve o tejto technológii budú nasledujúce články.

Čo vlastne EJB znamená? Špecifikácia definuje EJB ako architektúru pre distribuované systémy založené na komponentoch. V žiadnom prípade nesmie byť zamieňaná za klasické JavaBeans, pretože EJB sú enterprise level komponenty zapuzdrujúce viac či menej komplikovanú biznis logiku. Táto logika môže byť a väčšinou je prepojená na externé zdroje, čo môžu byť relačné databázy, LDAP, iné EJB komponenty a podobne. Ako častá výhoda EJB sa uvádza to, že vývojár sa môže viac zamerať na vývoj samotnej biznis logiky a nemusí si robiť veľké starosti s detailmi životného cyklu aplikácie, transakcií, bezpečnosti a perzistencie. K tomu musím podotknúť, že uvedené platí len čiastočne. Veľmi záleží od skúseností vývojára a tiež od konkrétnej implementácie špecifikácie EJB. Po zvládnutí technológie to však platí určite.

Úvod do architektúry Enterprise JavaBeans 2.x

V predchádzajúcom odstavci je definovaný pojem EJB. Vraví, že EJB je vlastne architektúra (môžeme povedať tiež model), ktorej poslaním je budovanie distribuovaných komponentových enterprise systémov. Táto definícia síce môže byť užitočná, ale iba pre toho, kto dobre pozná význam spojenia „distribuovaný komponentový systém“. Asi vám veľmi nepomôže, ak ste v oblasti vývoja enterprise systémov alebo samotných EJB úplní nováčikovia. Možno by pre vás bolo dôležitejšie najprv pomenovať, čo vlastne predstavuje pojem enterprise aplikácia. Dostaneme sa aj k tomu, ale najprv mi dovoľte, aby som vám predostrel schematický náhľad ilustrujúci EJB architektúru.

Schéma EJB architektúry vnímaná z najvyššej úrovne

Vývoj enterprise aplikácií rozhodne nezačal s príchodom EJB alebo Javy všeobecne. V skutočnosti sa tento termín používal už za čias masívneho využívania mainframe systémov. A hoci organizácie používali Common Object Request Broker Architecture (CORBA®) už od 90-tych rokov, vďaka boomu internetu a decentralizácii správy informačných systémov stále viac a viac vyvíjaných aplikácií prekračuje hranice organizácií a podporuje stále viac podnikových procesov. Pod pojem enterprise aplikácia môžeme zahrnúť všetok softvér, ktorý podnik zakúpil, vyvinul alebo prevzal a ktorý poskytuje služby na úrovni podpory podnikových procesov. Služby sa môžu týkať napríklad správy majetku, materiálovo-technického zabezpečenia, fakturácie a účtovníctva, skrátka čohokoľvek čo si musí organizácia manažovať. Skutočné enterprise aplikácie už dávno nie sú uzavreté medzi štyri steny dátového centra, ale ich jednotlivé komponenty a služby, ktoré poskytujú, sú často decentralizované cez celú organizáciu vrátane jej pobočiek.

Z toho, čo sme si zatiaľ povedali, začína byť vidieť, že vývojár enterprise systémov sa musí vyrovnať s množstvom komplexných technologických problémov, ktoré sa nevyskytujú pri tvorbe „malých“ aplikácií. Vzdialená správa, geografické rozloženie, rôzne úrovne prístupov pre zákazníkov, dodávateľov, zamestnancov, mnohonásobné súčasné prístupy k rôznym zdrojom, podpora rôznych jazykov a podobne, to sú len niektoré z množstva rôznych úloh, pred ktorými vývojári stoja. Môžeme ešte spomenúť nutnosť prevádzky aplikácií v heterogénnych prostrediach a častú podmienku integrácie na existujúce systémy.

Ak sa vrátime späť k definícii EJB a zohľadníme, čo sme si povedali o vývoji enterprise systémov, môžeme sa pokúsiť znova definovať architektúru EJB takto:

Enterprise JavaBeans sú softvérové komponenty, nasadené na aplikačnom serveri, vytvárajúcom bezpečné a spoľahlivé prostredie pre beh týchto komponentov. Inštalované komponenty sú dostupné cez sieť a ich úlohou je poskytovať služby pre podporu podnikových procesov.

Distribuované komponentové systémy

V predošlej časti sme už spomínali tento pojem. Nepovedali sme si však, prečo je pre nás tak dôležitý. Najprv by sme si však mali objasniť, čo je softvérový komponent a aký má význam pre vývojárov enterprise aplikácií. Keď hovoríme o komponente všeobecne, môžeme povedať, že každá Javovská trieda je komponent. Avšak v enterprise prostredí musíme zájsť ďalej. V roku 1996 European Workshop on Component-Oriented Programming (ECOOP) prišiel s touto definíciou:

Softvérový komponent musí mať jasne definované rozhranie a explicitne vyjadrené závislosti. Musí byť možné ho nasadiť nezávisle ako produkt tretej strany.

Komponent, všeobecne povedané, ponúka biznis služby svojím klientom. Klient môže byť GUI interfejs alebo iný komponent. Ponúkané služby môžu byť úplne jednoduché, napríklad vrátenie e-mailu na definovaného zákazníka, až po veľmi komplikované, ako je výpočet ceny za objednávku, ktorá má byť doručená napríklad do Mongolska. Nezáleží na tom, aké služby komponent ponúka, poskytuje ich prostredníctvom svojho verejne dostupného rozhrania. Z pohľadu klienta nie je známe, akým spôsobom komponent pracuje, dôležitý je výsledok. Tento princíp sa označuje ako zapuzdrenie. Komponent obvykle „pozná“ niekoľko operácií (metódy), má určité vlastnosti (uchovávajú stav) a vie generovať udalosti (najčastejšie ako asynchrónna notifikácia).

Ďalšia skutočnosť vyplývajúca z definície komponentu je to, že môže mať logické prepojenie na iný komponent. Táto závislosť musí byť explicitne zdokumentovaná. Málokedy sa nájde úplne nezávislý komponent. A nie je to nič nekorektného, mať takéto závislosti, avšak je nutné, aby boli pochopiteľné a zrozumiteľné. Vo svete enterprise aplikácií je úplne normálne, že jeden komponent závisí od iných. Správnym pochopením týchto závislostí sme schopný rýchlo rozhodnúť, ktoré ďalšie komponenty budú ovplyvnené v prípade, že je nutné zmeniť alebo odobrať niektoré časti verejného rozhrania komponentu.

Posledný koncept vyplývajúci z definície je, že komponent musí byť možné nasadiť (deploy). Táto požiadavka môže byť trochu nejasná, pretože definícia deploymentu nebola pevne stanovená a pre rôznych ľudí môže znamenať rôznu vec. Napríklad Java triedy musia byť tiež nasadené (ak ich chceme používať). Musia byť v správnom balíčku a musia byť umiestnené v classpath. CORBA triedy musia byť tiež správne nasadené, ale úplne iným spôsobom. Napriek tomu všetkému, komponent musí byť tiež svojím spôsobom nasadený skôr, ako bude môcť začať poskytovať svoje služby klientom. Nasledovný obrázok ilustruje komponent (EJB), ktorý má všetky tri spomínané vlastnosti:

Komponent má verejné rozhranie, závislosti a je možné ho nasadiť

V súvislosti s komponentmi treba ešte spomenúť, že sa združujú do väčších celkov, čo sa označuje ako komponentná architektúra. Takáto architektúra pozostáva zo samotných komponentov a série služieb pre budovanie aplikácií. Môže byť využívaná ako framework, čo je sada znovupoužiteľných komponentov, využiteľná súčasne z rôznych aplikácií a šetriaca čas pri vývoji. Framework teda poskytuje stabilné a otestované prostredie so sadou komponentov a služieb.

Viacvrstvové systémy a EJB

Ku koncu 80-tych a začiatkom 90-tych rokov minulého storočia začali mnohé organizácie nahrádzať dvojvrstvové (klient/server) aplikácie trojvrstvovými. Išlo v podstate o to, že medzi klienta a server bola umiestnená ďalšia vrstva, ďalšie softvérové komponenty a služby. Táto medzivrstva, vo väčšine prípadov zodpovedná za implementáciu biznis logiky, bola nasadená niekde na lokálnej sieti a zdieľaná medzi klientmi. Je jasné, že sa tým odľahčila prvá vrstva, čo bolo jednoznačne pozitívum. Na druhej strane táto zmena priniesla nové nečakané výzvy, ktoré súviseli s distribuovanou povahou trojvrstvovej aplikácie. Môžeme spomenúť napríklad otázku bezpečnosti, súčasného prístupu, viacvláknové aspekty a podobne. Snáď najzaujímavejšom zmenou v porovnaní s predchádzajúcim systémom bola nutnosť vysporiadať sa s intenzívnou sieťovou komunikáciou medzi prvou a druhou vrstvou. Nasledujúci obrázok znázorňuje typickú viacvrstvovú architektúru a v rámci nej umiestnenie EJB:

Umiestnenie EJB v typickej viacvrstvovej architektúre

Možno vás pri pohľade na obrázok napadlo (tak ako mňa pred určitým časom), či je distribuovaná komponentová architektúra naozaj tak skvelá, ako sa snažím prezentovať. Či sa naozaj oplatí investovať do jej učenia sa, jej nasadenia a využívania. Myslím, že môžem jednoznačne povedať áno. Treba si totiž uvedomiť, že rozdrobenie architektúry do väčšieho množstva malých technologických celkov (EJB je len jedna časť J2EE), má svoje nesporné výhody. Ide o to, že každý kúsok skladačky je zodpovedný len za svoj podiel na celku a môže sa maximálne sústrediť na prácu, na ktorú bol navrhnutý. Ďalšími výhodami je už spomínané odľahčenie klienta a možnosť zmeny UI (user interface) bez nutnosti zásahu do biznis logiky. Na záver už len spomeniem, že izolovaním jednotlivých vrstiev je umožnené organizáciám nakúpiť a inštalovať komponenty tretích strán, čím sa môžu viac sústrediť na svoj biznis.

Prečo práve EJB?

Dúfam, že teraz vám už je viac jasný význam komponentnej architektúry a jej použitie. Doteraz sme však príliš neuvažovali nad významom EJB ako takých. Samozrejme, že by som sa nepúšťal do písania takejto série článkov, keby som nebol presvedčený o ich nevyhnutnosti a dôležitosti pri tvorbe enterprise systémov na platforme J2EE. Nie je však od veci spomenúť si pár dôvodov, prečo práve EJB. Tieto dôvody sú veľmi podobné ako dôvody, prečo som si vybral práve jazyk Java:

• Filozofia „napíš raz a rozbehni kdekoľvek“.
• Špecifikácia oddelená od implementácie.
• Interoperabilita.
• Možnosť zamerať sa na biznis logiku.
• Kompatibilita s CORBA/IIOP.

Keďže EJB sú písané v Jave a tá je platformovo neutrálna, aj enterprise bean stačí napísať iba raz a vďaka Java Virtual Machine ho môžeme prevádzkovať na akomkoľvek aplikačnom serveri, ktorý spĺňa špecifikáciu EJB. Ďalšou kladnou črtou týkajúcou sa aj jazyka ako takého, je snaha o oddelenie rozhraní (špecifikácie) od implementácie. Táto idea nie je úplne nová, existuje aj v CORBA svete, kde špecifikujete rozhranie pomocou Interface Definition Language (IDL), ktorý je jazykovo a platformovo neutrálny.

Môžeme si to predstaviť na príklade Java Database Conectivity (JDBC). Možno ste si to niektorí ani neuvedomili, ale JDBC je len špecifikácia, obsahujúca sadu rozhraní a veľmi malé množstvo implementačných tried. Nachádzajú sa v balíčkoch java.sql a javax.sql. Aby ste však JDBC mohli začať využívať, musíte si najprv stiahnuť JDBC driver od konkrétneho výrobcu databázového servera. A samotný driver nie je nič iné, ako konkrétna implementácia JDBC. Mala by presne odpovedať špecifikácii, ale niektorí poskytovatelia pridávajú aj funkcie navyše. Výhodou takéhoto riešenia je, že vývojár systému si môže vybrať podľa neho najvhodnejšiu implementáciu. V praxi sme však vždy limitovaní databázovým serverom, pretože nie každý výrobca poskytuje viac ako jednu implementáciu JDBC. S EJB je to veľmi podobné.

Čo sa týka interoperability, teda možnosti spolupráce a komunikácie medzi rôznymi platformami, EJB ponúka niekoľko ciest, ako ju zabezpečiť. Je to veľmi komplexná téma a chcem jej venovať niekoľko článkov. Spomeniem len, že podobne ako CORBA, ktorá využíva Internet Interoperability Protocol (IIOP) na zabezpečenie komunikácie medzi rôznymi komponentami v rámci distribuovaného systému, aj EJB využívajú v tejto oblasti zavedené štandardy a odporúčania.

Možnosť zamerať sa primárne na riešenie biznis logiky vyplýva z bohatosti a komplexnosti celej J2EE. Táto platforma definuje špecifikácie rôznych technológií zabezpečujúcich napríklad komunikáciu distribuovaných komponentov, bezpečnosť, perzistenciu objektov, messaging, logging, mailing a veľa iných. Zdôrazňujem, že SUN a ostaní členovia zoskupenia okolo J2EE, definujú iba Application Programming Interfaces (APIs). Konkrétny poskytovateľ a výrobca aplikačného servera zabezpečuje implementáciu. Pokiaľ je implementácia profesionálne zvládnutá, vývojár sa môže viac sústrediť na spomínanú biznis logiku, namiesto riešenia infraštruktúry.

CORBA umožňuje vyvíjať aplikácie v rôznych jazykoch vrátane C++, Visual Basic, Cobol a tiež v Jave. Táto kompatibilita je výhodná, pretože existuje a stále funguje veľké množstvo CORBA/IIOP aplikácií. EJB bola od počiatku navrhnutá tak, aby umožňovala nadviazať spoluprácu s CORBA komponentmi.

Koniec začiatku

Dostali sme sa až na koniec tohto úvodu do problematiky EJB. Išlo o výsostne teoretické pojednanie s cieľom oboznámiť vás s určitým pozadím, na ktorom vznikala technológia EJB 2.x. Pri tvorbe koncepcie týchto článkov som prišiel jednoznačne k záveru, že v záujme lepšieho pochopenia vysvetľovanej problematiky by bolo vhodné opierať sa o komplexný príklad. Stanovil som si teda cieľ, vytvorenie jednoduchej enterprise aplikácie budovanej počas celej série o EJB. Mám tým na mysli aplikáciu, ktorá bude spĺňať kritériá vhodnosti použitia EJB a zároveň bude dostatočne jednoduchá na pochopenie. O akú aplikáciu pôjde, vám zatiaľ neprezradím, ale už v budúcom článku začneme s analýzou problematiky a zbieraním požiadaviek. Odporúčam vám zopakovať si základy UML.

Odkazy a zdroje

• J2EE 1.4 Tutorial (EJB 2.1) – základný tutoriál od SUNu (v kapitolách 23. až 29. sa podrobne rozoberá technológia EJB)
• Mastering Enterprise Java Beans Second Edition (EJB 2.0) – je veľmi dobre napísaná kniha, ktorú si môžete voľne stiahnuť vo formáte PDF (non-printable)
• Stránka organizácie OMG venovaná UML – táto stránka obsahuje veľa odkazov na ďalšie informácie a tutoriály venované UML 1.x a UML 2.0
• Špecifikácia technológie EJB 2.x – na tejto stránke si môžete stiahnuť, alebo dať zobraziť špecifikáciu EJB 2.x

Starší komentáře ke článku

Pokud máte zájem o starší komentáře k tomuto článku, naleznete je zde.