Enterprise JavaBeans (EJB) vyvolala veľké vzrušenie od oznámenia agentúry EMI z marca 1998 Enterprise JavaBeans Specification verzia 1.0. Spoločnosti ako Oracle, Borland, Tandem, Symantec, Sybase a Visigenic okrem iného ohlásili alebo dodali produkty, ktoré zodpovedajú špecifikácii EJB. Tento mesiac sa na vysokej úrovni pozrieme na to, čo presne Enterprise JavaBeans je. Prejdeme si, ako sa EJB líši od pôvodného modelu súčasti JavaBeans, a prediskutujeme, prečo EJB vyvolala taký obrovský záujem.
Najprv však treba poradiť: tento mesiac sa nebudeme zaoberať zdrojovým kódom ani témami s postupmi. Tento článok nie je návodom; je to skôr architektonický prehľad. EJB pokrýva veľké množstvo území a bez toho, aby ste najskôr pochopili základné príslušné pojmy, sú útržky kódu a triky programovania nezmyselné. Ak je záujem zo strany JavaWorldČitatelia, budúce články môžu pokrývať špecifiká používania rozhrania Enterprise JavaBeans API na vytvorenie vlastných Enterprise JavaBeans.
Aby sme pochopili, prečo je EJB tak atraktívny pre vývojárov, potrebujeme určité historické pozadie. Najprv sa pozrieme na históriu systémov klient / server a na súčasný stav vecí. Potom si povieme niečo o rôznych častiach systému EJB: Komponenty EJB - ktoré žijú na Kontajner EJB beh vo vnútri Server EJB - a Objekty EJB, ktoré klient používa ako akési „diaľkové ovládanie“ komponentov EJB. Prejdeme si dva typy EJB: zasadanie a subjekt predmety. Tiež sa dočítate o Domov a diaľkový rozhrania, ktoré vytvárajú inštancie EJB a poskytujú prístup k obchodným metódam EJB. Na konci článku získate predstavu o tom, ako je možné zostaviť rozšíriteľné servery pomocou Enterprise JavaBeans. Najskôr sa však pozrieme späť v čase.
História klient / server
Dávna história
Na začiatku bol sálový počítač. A bolo to dobré. (Alebo rovnako dobré, ako to bolo.) Stav techniky v oblasti spracovania informácií v 60. rokoch pozostával predovšetkým z veľkých a drahých strojov, ktoré veľké organizácie používali na podporu svojich každodenných obchodných operácií. Minipočítače a zdieľanie času v 70. rokoch zvýšili dostupnosť výpočtového výkonu, ale informácie a spracovanie boli stále centralizované na jednotlivých strojoch. Prvé osobné počítače v 80. rokoch rýchlo preplnili podnikovú scénu tisíckami malých ostrovov informácií. Všetci neúnavne chrlili správy s premenlivou kvalitou, pri havárii stratili dôležité údaje a rýchlo si navzájom odporovali.
Klient / server na záchranu
Architektúra klient / server je jedným z najbežnejších riešení hádanky o tom, ako zvládnuť potrebu centralizovanej kontroly údajov a širokej dostupnosti údajov. V systémoch klient / server sú informácie udržiavané relatívne centralizované (alebo sú rozdelené a / alebo replikované medzi distribuovanými servermi), čo uľahčuje kontrolu a konzistenciu údajov a stále poskytuje prístup k údajom, ktoré používatelia potrebujú.
Systémy klient-server sa dnes bežne skladajú z rôznych počtov úrovne. Štandardný starý systém mainframe alebo timesharing, kde je používateľské rozhranie spustené na rovnakom počítači ako databáza a obchodné aplikácie, je známy ako single tier. Takéto systémy sa dajú relatívne ľahko spravovať a konzistencia údajov je jednoduchá, pretože údaje sa ukladajú iba na jednom mieste. Jednoúrovňové systémy majú, bohužiaľ, obmedzenú škálovateľnosť a sú náchylné na riziká dostupnosti (ak dôjde k výpadku jedného počítača, dôjde k zlyhaniu celého vášho podnikania), najmä ak sa jedná o komunikáciu.
Prvé systémy klient / server boli dvojúrovňový, pričom užívateľské rozhranie bežalo na klientovi a databáza žila na serveri. Takéto systémy sú stále bežné. Jeden dvojúrovňový server s rôznymi typmi záhrad vykonáva väčšinu obchodnej logiky na klientovi a aktualizuje zdieľané údaje zasielaním prúdov SQL na server. Jedná sa o flexibilné riešenie, pretože konverzácia typu klient / server sa deje na úrovni databázového jazyka servera. V takomto systéme je možné správne navrhnutého klienta upraviť tak, aby odrážal nové obchodné pravidlá a podmienky bez úpravy servera, pokiaľ má server prístup k schéme databázy (tabuľky, zobrazenia atď.) Potrebnej na vykonávanie transakcií. Server v takomto dvojvrstvovom systéme sa nazýva a databázový server, ako je uvedené nižšie.
Databázové servery však majú určité záväzky. Často je SQL pre konkrétnu obchodnú funkciu (napríklad pridanie položky do objednávky) identické, s výnimkou údajov, ktoré sa aktualizujú alebo vkladajú z hovoru na hovor. Databázový server nakoniec vykoná analýzu a opravu takmer identického kódu SQL pre každú obchodnú funkciu. Napríklad všetky príkazy SQL na pridanie položky k objednávke budú pravdepodobne veľmi podobné, rovnako ako príkazy SQL na vyhľadanie zákazníka v databáze. Čas, ktorý táto analýza trvá, by bolo lepšie stráviť skutočným spracovaním údajov. (Tento problém možno napraviť, vrátane vyrovnávacích pamätí SQL a uložených procedúr.) Ďalším problémom, ktorý sa vyskytne, je vytváranie verzií verzií klientov a databázy súčasne: pri aktualizácii sa musia všetky počítače vypnúť a klienti alebo servery, ktoré vo svojich službách zaostávajú. softvérová verzia zvyčajne nebude použiteľná, kým nebude inovovaná.
Aplikačné servery
An aplikačný server architektúra (pozri nasledujúci obrázok) je populárnou alternatívou k architektúre databázového servera, pretože rieši niektoré problémy, ktoré majú databázové servery.
Prostredie databázového servera zvyčajne vykonáva obchodné metódy na klientovi a server používa hlavne na vytrvalosť a presadzovanie integrity údajov. V aplikačnom serveri sa obchodné metódy spúšťajú na serveri a klient požaduje, aby server tieto metódy vykonal. V tomto scenári klient a server zvyčajne použijú protokol, ktorý predstavuje konverzáciu na úrovni obchodných transakcií, a nie na úrovni tabuliek a riadkov. Takéto aplikačné servery často fungujú lepšie ako ich databázové náprotivky, stále však trpia problémami s verziou.
Databázový aj aplikačný systém je možné vylepšiť pridaním ďalších úrovní do architektúry. Tzv trojstupňový systémy umiestňujú prostredný komponent medzi klienta a server. Na riešenie záväzkov dvojvrstvových systémov sa objavilo celé odvetvie - middleware. A monitor spracovania transakcií, jeden typ middlewaru, prijíma streamy požiadaviek od mnohých klientov a môže vyvážiť zaťaženie medzi viacerými servermi, poskytnúť zlyhanie pri zlyhaní servera a spravovať transakcie v mene klienta. Ostatné typy middlewaru poskytujú preklad komunikačných protokolov, konsolidujú požiadavky a odpovede medzi klientmi a viacerými heterogénnymi servermi (toto je obzvlášť populárne pri riešení starších systémov pri reinžinieringu obchodných procesov) a / alebo poskytujú meranie služieb a informácie o sieťovej prevádzke.
Viaceré úrovne poskytujú flexibilitu a interoperabilitu, ktorá vyústila do systémov s viac ako týmito tromi vrstvami služieb. Napríklad, n-vrstva systémy sú zovšeobecnením trojvrstvových systémov, pričom každá vrstva softvéru poskytuje inú úroveň služieb vrstvám nad a pod ňou. Perspektíva n-úrovne považuje sieť za skupinu distribuovaných služieb, a nie za prostý prostriedok prístupu klienta na jeden server.
Ako sa dostali do módy objektovo orientované jazyky a techniky, začali sa systémy klient / server čoraz viac posúvať k objektovej orientácii. CORBA (Common Object Request Broker Architecture) je architektúra, ktorá umožňuje spustenie objektov v aplikáciách - dokonca aj objektov napísaných v rôznych jazykoch - na samostatných počítačoch v závislosti od potrieb danej aplikácie. Aplikácie napísané pred rokmi je možné zbaliť ako služby CORBA a spolupracovať s novými systémami. Enterprise JavaBeans, ktorá je navrhnutá tak, aby bola kompatibilná s CORBA, je ďalším vstupom do objektovo orientovaného okruhu aplikačno-serverových.
Účelom tohto článku nie je poskytnúť výukový program o systémoch klient / server, ale bolo potrebné poskytnúť určité pozadie s cieľom definovať kontext. Teraz sa pozrime na to, čo EJB ponúka.
Enterprise JavaBeans a rozšíriteľné aplikačné servery
Teraz, keď sme sa pozreli na trochu histórie a pochopili sme, čo sú aplikačné servery, pozrime sa na Enterprise JavaBeans a pozrime sa, čo v tomto kontexte ponúka.
Základnou myšlienkou Enterprise JavaBeans je poskytnúť rámec pre komponenty, ktoré môžu byť „pripojené“ k serveru, čím sa rozširuje funkčnosť tohto servera. Enterprise JavaBeans je podobný pôvodným JavaBeans iba v tom, že používa niektoré podobné koncepty. Technológia EJB sa neriadi Špecifikácia komponentu JavaBeans, ale tým úplne iným (a masívnym) Špecifikácia Enterprise JavaBeans. (Podrobnosti o tejto špecifikácii nájdete v zdrojoch.) EJB Spec volá rôznych hráčov v systéme klient / server EJB, popisuje, ako EJB spolupracuje s klientom a s existujúcimi systémami, objasňuje kompatibilitu EJB s CORBA a definuje zodpovednosti za rôzne komponenty v systéme.
Ciele Enterprise JavaBeans
The EJB Spec sa snaží splniť niekoľko cieľov naraz:
EJB je navrhnutý tak, aby vývojárom uľahčil vytváranie aplikácií, a tak ich oslobodí od podrobností systému na nízkej úrovni týkajúcich sa správy transakcií, vlákien, vyvažovania záťaže atď. Vývojári aplikácií sa môžu sústrediť na obchodnú logiku a podrobnosti riadenia spracovania údajov prenechať rámcu. V prípade špecializovaných aplikácií je však vždy možné dostať sa pod „kapotu“ a prispôsobiť tieto služby na nižšej úrovni.
The EJB Spec definuje hlavné štruktúry rámca EJB a potom osobitne definuje zmluvy medzi nimi. Zodpovednosti klienta, servera a jednotlivých komponentov sú jasne definované. (O chvíľu si prejdeme, aké sú tieto štruktúry.) Vývojár, ktorý vytvára komponent Enterprise JavaBean, má veľmi odlišnú rolu od niekoho, kto vytvára server kompatibilný s EJB, a špecifikácia popisuje zodpovednosti každého z nich.
Cieľom EJB je byť štandardným spôsobom budovania aplikácií klient / server v jazyku Java. Rovnako ako je možné kombinovať pôvodné komponenty JavaBeans (alebo komponenty Delphi alebo čokoľvek iné) od rôznych dodávateľov a vytvoriť tak vlastného klienta, je možné kombinovať komponenty servera EJB od rôznych dodávateľov a vytvoriť tak vlastný server. Komponenty EJB, ktoré sú triedami Java, budú samozrejme bežať na akomkoľvek serveri kompatibilnom s EJB bez rekompilácie. Je to výhoda, ktorú snáď nemôžu dúfať ponúknuť riešenia špecifické pre platformu.
- Nakoniec je EJB kompatibilný s inými Java API, používa ich, môže spolupracovať s aplikáciami, ktoré nie sú Java, a je kompatibilný s CORBA.
Ako funguje systém klient / server EJB
Aby sme pochopili, ako funguje systém klient / server EJB, musíme porozumieť základným častiam systému EJB: komponent EJB, kontajner EJB a objekt EJB.
Komponent Enterprise JavaBeans
Enterprise JavaBean je komponent, rovnako ako tradičný JavaBean. Enterprise JavaBeans sa vykonávajú v rámci domény Kontajner EJB, ktorá sa následne vykoná v rámci Server EJB. Serverom EJB môže byť akýkoľvek server, ktorý môže hostiť kontajner EJB a poskytovať mu potrebné služby. (To znamená, že mnoho existujúcich serverov môže byť rozšírených na servery EJB a v skutočnosti to dosiahli mnohí predajcovia alebo oznámili zámer tak urobiť.)
Komponent EJB je typom triedy EJB, ktorá sa s najväčšou pravdepodobnosťou bude považovať za „Enterprise JavaBean“. Je to trieda Java, ktorú napísal vývojár EJB a ktorá implementuje obchodnú logiku. Všetky ostatné triedy v systéme EJB buď podporujú prístup klientov k triedam komponentov EJB, alebo poskytujú služby (napríklad perzistencia atď.).
Kontajner Enterprise JavaBeans
V kontajneri EJB „žije“ komponent EJB. Kontajner EJB poskytuje služby ako správa transakcií a zdrojov, spravovanie verzií, škálovateľnosť, mobilita, vytrvalosť a bezpečnosť komponentom EJB, ktoré obsahuje. Pretože kontajner EJB spracováva všetky tieto funkcie, vývojár komponentov EJB sa môže sústrediť na obchodné pravidlá a nechať manipuláciu s databázou a ďalšie také jemné podrobnosti na kontajner. Napríklad, ak sa jediný komponent EJB rozhodne, že aktuálna transakcia by sa mala prerušiť, jednoducho oznámi svojmu kontajneru (spôsobom definovaným Špecifikácia EJB, a kontajner je zodpovedný za vykonanie všetkých vrátení zmien alebo za vykonanie všetkého, čo je potrebné na zrušenie prebiehajúcej transakcie. V jednom kontajneri EJB zvyčajne existuje viac inštancií komponentov EJB.
Objekt EJB a vzdialené rozhranie
Klientsky program vykonáva metódy na vzdialených EJB prostredníctvom Objekt EJB. Objekt EJB implementuje „vzdialené rozhranie“ komponentu EJB na serveri. Diaľkové rozhranie predstavuje „obchodné“ metódy komponentu EJB. Diaľkové rozhranie vykonáva skutočnú a užitočnú prácu s objektom EJB, ako napríklad vytvorenie objednávkového formulára alebo odloženie pacienta k špecialistovi. Ďalej budeme diskutovať o vzdialenom rozhraní.
