Enterprise JavaBeans (EJB) vyvolala velké nadšení od oznámení zprávy z března 1998 Enterprise JavaBeans Specification verze 1.0. Společnosti jako Oracle, Borland, Tandem, Symantec, Sybase a Visigenic mimo jiné oznámily a / nebo dodaly produkty, které splňují specifikaci EJB. Tento měsíc se podrobně podíváme na to, co přesně Enterprise JavaBeans je. Projdeme si, jak se EJB liší od původního modelu komponenty JavaBeans, a probereme, proč EJB vyvolala tak velký zájem.
Nejprve však poradce: tento měsíc se nebudeme zabývat zdrojovým kódem ani tématy s návody. Tento článek není návodem; je to spíše architektonický přehled. EJB pokrývá hodně území a aniž by nejprve porozuměli základním pojmům, fragmenty kódu a triky programování nemají smysl. Pokud je zájem ze strany JavaWorldČtenáři, budoucí články mohou pokrývat specifika používání rozhraní Enterprise JavaBeans API k vytváření vlastních Enterprise JavaBeans.
Abychom pochopili, proč je EJB tak atraktivní pro vývojáře, potřebujeme nějaké historické pozadí. Nejprve se podíváme na historii systémů klient / server a na aktuální stav věcí. Poté probereme různé části systému EJB: Komponenty EJB - které žijí na Kontejner EJB běží uvnitř EJB server -- a Objekty EJB, kterou klient používá jako jakési „dálkové ovládání“ komponent EJB. Projdeme si dva typy EJB: zasedání a subjekt předměty. Také si přečtete o Domov a dálkový rozhraní, která vytvářejí instance EJB a poskytují přístup k obchodním metodám EJB. Na konci článku budete mít představu o tom, jak lze pomocí Enterprise JavaBeans postavit rozšiřitelné servery. Ale nejdříve, ohlédnutí se v čase.
Historie klient / server
Dávná historie
Na začátku byl sálový počítač. A bylo to dobré. (Nebo stejně dobrý, jak to jen bylo.) Stav techniky ve zpracování informací v šedesátých letech sestával primárně z velkých a drahých strojů používaných velkými organizacemi k podpoře jejich každodenních obchodních operací. Minipočítače a sdílení času v sedmdesátých letech zvýšily dostupnost výpočetního výkonu, ale informace a zpracování byly stále centralizovány na jednotlivých strojích. První osobní počítače v 80. letech rychle zaplnily podnikové prostředí tisíci malých ostrůvků informací, všechny neúnavně chrlily zprávy o proměnlivé kvalitě, při havárii ztratily důležitá data a rychle se staly nekonzistentními.
Klient / server na záchranu
Architektura klient / server je jedním z nejběžnějších řešení hlavolamu, jak zvládnout potřebu centralizovaného řízení dat a široké dostupnosti dat. V systémech klient / server jsou informace udržovány relativně centralizované (nebo jsou rozděleny a / nebo replikovány mezi distribuovanými servery), což usnadňuje kontrolu a konzistenci dat a přitom poskytuje přístup k datům, která uživatelé potřebují.
Systémy klient-server se nyní běžně skládají z různých počtů úrovně. Standardní starý systém mainframe nebo timesharing, kde uživatelské rozhraní běží na stejném počítači jako databáze a obchodní aplikace, je známý jako single tier. Takové systémy se relativně snadno spravují a konzistence dat je jednoduchá, protože data jsou uložena pouze na jednom místě. Jednoúrovňové systémy mají bohužel omezenou škálovatelnost a jsou náchylné k rizikům dostupnosti (pokud selže jeden počítač, dojde k výpadku celého vašeho podnikání), zejména pokud jde o komunikaci.
První systémy klient / server byly dvoustupňový, přičemž uživatelské rozhraní běželo na klientovi a databáze žila na serveru. Takové systémy jsou stále běžné. Jeden typ dvoustupňového serveru s řadou zahrad provádí většinu obchodní logiky na klientovi a aktualizuje sdílená data zasíláním streamů SQL na server. Jedná se o flexibilní řešení, protože konverzace klient / server probíhá na úrovni databázového jazyka serveru. V takovém systému lze správně navrženého klienta upravit tak, aby odrážel nová obchodní pravidla a podmínky bez úpravy serveru, pokud má server přístup k databázovému schématu (tabulkám, pohledům atd.) Potřebným k provedení transakcí. Server v takovém dvoustupňovém systému se nazývá a databázový server, Jak je ukázáno níže.
Databázové servery však mají určité závazky. Často je SQL pro konkrétní obchodní funkci (například přidání položky do objednávky) identický, s výjimkou aktualizovaných nebo vložených dat, od volání k volání. Databázový server nakonec analyzuje a opravuje téměř identický SQL pro každou obchodní funkci. Například všechny příkazy SQL pro přidání položky do objednávky budou pravděpodobně velmi podobné, stejně jako příkazy SQL pro vyhledání zákazníka v databázi. Čas, který tato analýza zabere, by bylo lépe strávit skutečným zpracováním dat. (Existují řešení tohoto problému, včetně mezipamětí SQL parse a uložených procedur.) Dalším problémem, který se objeví, je správa verzí klientů a databáze současně: všechny počítače musí být kvůli upgradu vypnuty a klienti nebo servery, které ve svých verze softwaru jsou obvykle nepoužitelné, dokud nebudou upgradovány.
Aplikační servery
An aplikační server architektura (viz další obrázek) je populární alternativou k architektuře databázového serveru, protože řeší některé problémy databázových serverů.
Prostředí databázového serveru obvykle provádí obchodní metody na klientovi a používá server většinou k vytrvalosti a vynucování integrity dat. Na aplikačním serveru běží obchodní metody na serveru a klient požaduje, aby server tyto metody provedl. V tomto scénáři klient a server obvykle použijí protokol, který představuje konverzaci na úrovni obchodních transakcí, namísto na úrovni tabulek a řádků. Takové aplikační servery často fungují lépe než jejich databázové protějšky, ale stále trpí problémy s verzí.
Databázový i aplikační systém lze vylepšit přidáním dalších úrovní do architektury. Tzv třívrstvá systémy umisťují mezi klientem a serverem mezilehlou komponentu. Celé odvětví - middleware - se objevilo, aby řešilo závazky dvoustupňových systémů. A monitor zpracování transakcí, jeden typ middlewaru, přijímá proudy požadavků od mnoha klientů a může vyvažovat zátěž mezi více servery, poskytovat převzetí služeb při selhání při selhání serveru a spravovat transakce jménem klienta. Jiné typy middlewaru poskytují překlad komunikačních protokolů, konsolidují požadavky a odpovědi mezi klienty a více heterogenními servery (to je obzvláště populární při řešení starších systémů v reengineeringu obchodních procesů) a / nebo poskytují měření služeb a informace o síťovém provozu.
Více úrovní poskytuje flexibilitu a interoperabilitu, která vyústila v systémy s více než těmito třemi vrstvami služeb. Například, n-úroveň systémy jsou zobecněním třívrstvých systémů, přičemž každá vrstva softwaru poskytuje jinou úroveň služeb vrstvám nad a pod ní. Perspektiva n-tier považuje síť za fond distribuovaných služeb, nikoli pouze za prostředek pro přístup klienta k jednomu serveru.
Vzhledem k tomu, že do módy vstoupily objektově orientované jazyky a techniky, tak se systémy klient / server stále více posunuly k objektové orientaci. CORBA (Common Object Request Broker Architecture) je architektura, která umožňuje provozovat objekty v aplikacích - dokonce i objekty napsané v různých jazycích - na samostatných počítačích v závislosti na potřebách dané aplikace. Aplikace napsané před lety lze zabalit jako služby CORBA a spolupracovat s novými systémy. Enterprise JavaBeans, který je navržen tak, aby byl kompatibilní s CORBA, je dalším vstupem do objektově orientovaného kruhu aplikačních serverů.
Účelem tohoto článku není poskytnout výukový program o systémech klient / server, ale bylo nutné poskytnout určité pozadí, aby bylo možné definovat kontext. Nyní se podívejme na to, co EJB nabízí.
Enterprise JavaBeans a rozšiřitelné aplikační servery
Nyní, když jsme se podívali na trochu historie a porozuměli jsme tomu, co jsou aplikační servery, podívejme se na Enterprise JavaBeans a podívejme se, co v tomto kontextu nabízí.
Základní myšlenkou Enterprise JavaBeans je poskytnout rámec pro komponenty, které mohou být „připojeny“ k serveru, čímž se rozšíří funkčnost tohoto serveru. Enterprise JavaBeans je podobný původním JavaBeans pouze v tom, že používá některé podobné koncepty. Technologie EJB se neřídí Specifikace komponenty JavaBeans, ale úplně jiným (a masivním) Specifikace Enterprise JavaBeans. (Podrobnosti o této specifikaci najdete v Zdrojích.) Specifikace EJB vyvolává různé hráče v systému klient / server EJB, popisuje, jak EJB spolupracuje s klientem a se stávajícími systémy, vysvětluje kompatibilitu EJB s CORBA a definuje odpovědnosti za různé komponenty v systému.
Cíle Enterprise JavaBeans
The Specifikace EJB se snaží splnit několik cílů najednou:
EJB je navržen tak, aby vývojářům usnadnil vytváření aplikací a osvobodil je od nízkoúrovňových systémových podrobností o správě transakcí, vláken, vyvažování zátěže atd. Vývojáři aplikací se mohou soustředit na obchodní logiku a podrobnosti správy zpracování dat nechají na rámec. U specializovaných aplikací je však vždy možné dostat se pod kapotu a přizpůsobit tyto služby nižší úrovně.
The Specifikace EJB definuje hlavní struktury rámce EJB a poté konkrétně definuje smlouvy mezi nimi. Odpovědnosti klienta, serveru a jednotlivých komponent jsou jasně vysvětleny. (O tom, jaké jsou tyto struktury, se ve chvíli podíváme.) Vývojář, který vytváří komponentu Enterprise JavaBean, má velmi odlišnou roli od někoho, kdo vytváří server kompatibilní s EJB, a specifikace popisuje odpovědnost každého z nich.
EJB si klade za cíl být standardním způsobem pro budování aplikací klient / server v jazyce Java. Stejně jako lze zkombinovat původní JavaBeans (nebo komponenty Delphi nebo cokoli jiného) od různých dodavatelů a vytvořit tak vlastního klienta, lze také zkombinovat komponenty serveru EJB od různých dodavatelů a vytvořit tak vlastní server. Komponenty EJB, které jsou třídami Java, budou samozřejmě běžet na libovolném serveru kompatibilním s EJB bez rekompilace. To je výhoda, kterou nemohou doufat nabídnout řešení pro konkrétní platformu.
- A konečně, EJB je kompatibilní s jinými Java API a používá je, může spolupracovat s aplikacemi, které nejsou Java, a je kompatibilní s CORBA.
Jak funguje systém klient / server EJB
Abychom pochopili, jak systém klient / server EJB funguje, musíme porozumět základním částem systému EJB: komponentě EJB, kontejneru EJB a objektu EJB.
Součást Enterprise JavaBeans
Enterprise JavaBean je komponenta, stejně jako tradiční JavaBean. Enterprise JavaBeans se spouštějí v rámci Kontejner EJB, který zase vykonává v rámci EJB server. Serverem EJB může být jakýkoli server, který může hostovat kontejner EJB a poskytovat mu potřebné služby. (To znamená, že mnoho stávajících serverů může být rozšířeno na servery EJB a ve skutečnosti to mnoho prodejců dosáhlo nebo oznámilo záměr tak učinit.)
Komponenta EJB je typ třídy EJB, který bude s největší pravděpodobností považován za „Enterprise JavaBean“. Je to třída Java napsaná vývojářem EJB, která implementuje obchodní logiku. Všechny ostatní třídy v systému EJB buď podporují přístup klientů k třídám komponent EJB, nebo jim poskytují služby (jako je vytrvalost atd.).
Kontejner Enterprise JavaBeans
V kontejneru EJB „žije“ komponenta EJB. Kontejner EJB poskytuje služby, jako je správa transakcí a zdrojů, správa verzí, škálovatelnost, mobilita, vytrvalost a zabezpečení komponent EJB, které obsahuje. Vzhledem k tomu, že kontejner EJB zpracovává všechny tyto funkce, může se vývojář komponent EJB soustředit na obchodní pravidla a ponechat manipulaci s databází a další takové jemné podrobnosti kontejneru. Například pokud se jedna komponenta EJB rozhodne, že aktuální transakce by měla být zrušena, jednoduše řekne svému kontejneru (způsobem definovaným Specifikace EJB, a kontejner je zodpovědný za provedení všech odvolání nebo za provedení všeho, co je nezbytné pro zrušení probíhající transakce. V jednom kontejneru EJB obvykle existuje více instancí komponent EJB.
Objekt EJB a vzdálené rozhraní
Klientské programy provádějí metody na vzdálených EJB prostřednictvím Objekt EJB. Objekt EJB implementuje „vzdálené rozhraní“ komponenty EJB na serveru. Vzdálené rozhraní představuje „obchodní“ metody komponenty EJB. Vzdálené rozhraní provádí skutečnou užitečnou práci s objektem EJB, jako je vytvoření objednávkového formuláře nebo odložení pacienta na specialistu. O vzdáleném rozhraní budeme hovořit podrobněji níže.
