Podjetje JavaBeans (EJB) je od razglasitve marca 1998 razburjalo veliko navdušenja Specifikacija Enterprise JavaBeans različice 1.0. Podjetja, kot so Oracle, Borland, Tandem, Symantec, Sybase in Visigenic, so med številnimi drugimi napovedala in / ali dostavila izdelke, ki ustrezajo specifikaciji EJB. Ta mesec si bomo na visoki ravni ogledali, kaj pravzaprav je Enterprise JavaBeans. Preučili bomo, kako se EJB razlikuje od prvotnega komponentnega modela JavaBeans, in razpravljali, zakaj je EJB ustvaril tako veliko zanimanje.
Najprej pa nasvet: v tem mesecu ne bomo več gledali izvorne kode ali tem s smernicami. Ta članek ni vadnica; prej gre za arhitekturni pregled. EJB pokriva veliko ozemlje in brez predhodnega razumevanja osnovnih pojmov so delčki kode in programski triki nesmiselni. Če obstaja zanimanje s strani JavaWorldBralci, bodoči članki lahko zajemajo posebnosti uporabe API-ja Enterprise JavaBeans za ustvarjanje lastnega Enterprise JavaBeans-a.
Da bi razumeli, zakaj je EJB tako privlačen za razvijalce, potrebujemo nekaj zgodovinskega ozadja. Najprej si bomo ogledali zgodovino sistemov odjemalec / strežnik in trenutno stanje. Nato bomo razpravljali o različnih delih sistema EJB: EJB komponente - ki živijo na Posoda EJB teče znotraj EJB strežnik - in Predmeti EJB, ki ga odjemalec uporablja kot nekakšen "daljinski upravljalnik" komponent EJB. Preučili bomo dve vrsti EJB: sejo in entiteta predmetov. Prebrali boste tudi o tem domov in na daljavo vmesniki, ki ustvarjajo primerke EJB in omogočajo dostop do poslovnih metod EJB. Na koncu članka boste imeli idejo, kako je mogoče razviti razširljive strežnike z uporabo Enterprise JavaBeans. Najprej pa pogled nazaj v čas.
Zgodovina odjemalca / strežnika
Starodavna zgodovina
Na začetku je bil glavni računalnik. In bilo je dobro. (Ali tako ali tako dober, kot je dobil.) Najsodobnejše področje obdelave informacij do šestdesetih let je bilo sestavljeno predvsem iz velikih, dragih strojev, ki so jih velike organizacije uporabljale za vsakodnevno poslovanje. Miniračunalniki in časovna skupnost v sedemdesetih letih so povečali dostopnost računalniške moči, vendar so bile informacije in obdelava še vedno centralizirani na posameznih strojih. Prvi osebni računalniki v osemdesetih letih prejšnjega stoletja so poslovno pokrajino hitro zasuli s tisoči drobnih otočkov informacij, vsi pa so neutrudno bruhali poročila spremenljive kakovosti, izgubljali kritične podatke, ko so se sesuli, in hitro postali neskladni med seboj.
Naročnik / strežnik na pomoč
Arhitektura odjemalec / strežnik je ena najpogostejših rešitev za uganko, kako se spoprijeti s potrebo po centraliziranem nadzoru podatkov in razširjeni dostopnosti podatkov. V sistemih odjemalec / strežnik se informacije hranijo relativno centralizirano (ali so razdeljene in / ali razmnožene med porazdeljenimi strežniki), kar olajša nadzor in doslednost podatkov, hkrati pa še vedno zagotavlja dostop do podatkov, ki jih uporabniki potrebujejo.
Odjemalsko-strežniški sistemi so zdaj pogosto sestavljeni iz različnih številk stopnje. Standardni stari glavni računalnik ali sistem skupne rabe časa, kjer uporabniški vmesnik deluje v istem računalniku kot baza podatkov in poslovne aplikacije, je znan kot enostopenjski. Takšne sisteme je razmeroma enostavno upravljati, doslednost podatkov pa je preprosta, ker so podatki shranjeni le na enem mestu. Na žalost imajo enotirni sistemi omejeno razširljivost in so nagnjeni k nevarnosti razpoložljivosti (če en računalnik ne deluje, celotno vaše podjetje propade), zlasti če gre za komunikacijo.
Prvi sistemi odjemalec / strežnik so bili dvotirni, pri čemer je uporabniški vmesnik deloval na odjemalcu, baza podatkov pa na strežniku. Takšni sistemi so še vedno pogosti. Dvotirni strežnik z vrsto vrtnih sort izvaja večino poslovne logike na odjemalcu in posodablja podatke v skupni rabi s pošiljanjem tokov SQL strežniku. To je prilagodljiva rešitev, saj pogovor odjemalec / strežnik poteka na ravni strežnikovega jezika baze podatkov. V takem sistemu je mogoče pravilno oblikovanega odjemalca spremeniti tako, da odraža nova poslovna pravila in pogoje brez spreminjanja strežnika, če ima strežnik dostop do sheme baze podatkov (tabele, pogledi itd.), Ki je potrebna za izvajanje transakcij. Strežnik v takem dvotirnem sistemu se imenuje a strežnik baz podatkov, kot je prikazano spodaj.
Strežniki baz podatkov pa imajo nekaj obveznosti. Pogosto je SQL za določeno poslovno funkcijo (na primer dodajanje elementa naročilu) enak, razen podatkov, ki se posodabljajo ali vstavljajo, od klica do klica. Strežnik baz podatkov na koncu razčleni in ponovi skoraj enak SQL za vsako poslovno funkcijo. Na primer, vsi stavki SQL za dodajanje elementa v naročilo so verjetno zelo podobni, prav tako kot stavki SQL za iskanje stranke v zbirki podatkov. Čas, ki ga potrebuje to razčlenitev, bi bil bolje porabljen za dejansko obdelavo podatkov. (Za to težavo obstajajo rešitve, vključno z razčlenjevanjem predpomnilnikov SQL in shranjenimi postopki.) Druga težava, ki se pojavi, je istočasno različevanje odjemalcev in baze podatkov: vsi stroji se morajo za nadgradnje izklopiti, odjemalci ali strežniki pa zaostajajo Različica programske opreme običajno ni uporabna, dokler je ne nadgradite.
Aplikacijski strežniki
An aplikacijski strežnik arhitektura (glej naslednjo sliko) je priljubljena alternativa arhitekturi strežnika baz podatkov, saj rešuje nekatere težave, ki jih imajo strežniki baz podatkov.
Okolje strežnika baz podatkov običajno izvaja poslovne metode na odjemalcu in strežnik večinoma uporablja za vztrajanje in uveljavljanje celovitosti podatkov. V aplikacijskem strežniku se poslovne metode izvajajo na strežniku in odjemalec zahteva, da strežnik te metode izvede. V tem primeru odjemalec in strežnik običajno uporabljata protokol, ki predstavlja pogovor na ravni poslovnih transakcij, namesto na ravni tabel in vrstic. Takšni strežniki aplikacij so pogosto boljši od svojih kolegov zbirke podatkov, vendar še vedno trpijo zaradi težav z različicami.
Tako baze podatkov kot tudi aplikacijske sisteme je mogoče izboljšati z dodajanjem dodatnih ravni arhitekturi. Tako imenovani tristopenjski sistemi postavljajo vmesno komponento med odjemalcem in strežnikom. Celotna industrija - vmesna programska oprema - se je pojavila, da bi rešila obveznosti dvotirnih sistemov. A monitor za obdelavo transakcij, ena vrsta vmesne programske opreme, sprejema tokove zahtev od številnih odjemalcev in lahko uravnoteži obremenitev med več strežniki, omogoči preklop, ko strežnik odpove, in upravlja transakcije v imenu stranke. Druge vrste vmesne programske opreme zagotavljajo prevajanje komunikacijskih protokolov, združujejo zahteve in odzive med odjemalci in več heterogenimi strežniki (to je še posebej priljubljeno pri obravnavi starejših sistemov pri prenovi poslovnih procesov) in / ali zagotavljajo merjenje storitev in informacije o omrežnem prometu.
Več stopenj zagotavlja prilagodljivost in interoperabilnost, kar je povzročilo sisteme z več kot tremi plastmi storitev. Na primer, n-raven sistemi so posplošitve tristopenjskih sistemov, pri čemer vsaka plast programske opreme zagotavlja različno raven storitve za plasti nad in pod njo. N-tier perspektiva omrežje obravnava kot skupino porazdeljenih storitev in ne zgolj kot sredstvo za dostop odjemalca do enega strežnika.
Ker so objektno usmerjeni jeziki in tehnike prišli v modo, so se tudi odjemalsko-strežniški sistemi vse bolj premikali k objektni orientaciji. CORBA (Common Object Request Broker Architecture) je arhitektura, ki omogoča, da se predmeti v aplikacijah - tudi predmeti, napisani v različnih jezikih - izvajajo na ločenih strojih, odvisno od potreb dane aplikacije. Programi, napisani pred leti, so lahko pakirani kot storitve CORBA in povezani z novimi sistemi. Enterprise JavaBeans, ki je zasnovan tako, da je združljiv s CORBA, je še en vstop v objektno usmerjen obroč aplikacijski strežnik.
Namen tega članka ni zagotoviti vadnico o sistemih odjemalec / strežnik, vendar je bilo treba določiti nekaj ozadja, da bi lahko opredelili kontekst. Zdaj pa poglejmo, kaj ponuja EJB.
Enterprise JavaBeans in razširljivi strežniki aplikacij
Zdaj, ko smo si ogledali nekaj zgodovine in razumeli, kaj so aplikacijski strežniki, si oglejmo Enterprise JavaBeans in poglejmo, kaj ponuja v tem kontekstu.
Osnovna ideja Enterprise JavaBeans je zagotoviti okvir za komponente, ki jih je mogoče "priključiti" na strežnik, in s tem razširiti njegovo funkcionalnost. Enterprise JavaBeans je podoben prvotnemu JavaBeans le v tem, da uporablja nekaj podobnih konceptov. Tehnologije EJB ne ureja Specifikacija komponente JavaBeans, ampak s povsem drugačnimi (in množičnimi) Specifikacija podjetja JavaBeans. (Za podrobnosti o tej specifikaciji glejte vire.) EJB Spec pokliče različne akterje v sistemu odjemalec / strežnik EJB, opiše, kako EJB sodeluje z odjemalcem in obstoječimi sistemi, opiše združljivost EJB s sistemom CORBA in opredeli odgovornosti za različne komponente v sistemu.
Enterprise JavaBeans cilji
The EJB Spec poskuša doseči več ciljev hkrati:
EJB je zasnovan tako, da razvijalcem olajša ustvarjanje aplikacij in jih osvobodi sistemskih podrobnosti o upravljanju transakcij, niti, uravnoteženja obremenitve itd. Razvijalci aplikacij se lahko osredotočijo na poslovno logiko in podrobnosti upravljanja obdelave podatkov prepustijo okolju. Za specializirane aplikacije pa je vedno mogoče priti "pod pokrovom" in prilagoditi te storitve nižje ravni.
The EJB Spec opredeljuje glavne strukture okvira EJB in nato natančno opredeljuje pogodbe med njimi. Odgovornosti odjemalca, strežnika in posameznih komponent so jasno opredeljene. (V trenutku bomo preučili, katere so te strukture.) Razvijalec, ki ustvarja komponento Enterprise JavaBean, ima zelo drugačno vlogo kot nekdo, ki ustvarja strežnik, združljiv z EJB, in specifikacija opisuje odgovornosti vsakega.
EJB želi biti standardni način za odjemalsko / strežniške aplikacije, ki se gradijo v jeziku Java. Tako kot je mogoče originalne JavaBeans (ali komponente Delphi ali kar koli drugega) različnih ponudnikov kombinirati za izdelavo odjemalca po meri, lahko tudi strežniške komponente EJB različnih ponudnikov ustvarijo strežnik po meri. Komponente EJB, ki so razredi Java, se bodo seveda izvajale v katerem koli strežniku, skladnem z EJB, brez ponovne prevajanja. To je prednost, ki jo rešitve, specifične za platformo, ne morejo ponuditi.
- Končno je EJB združljiv in uporablja druge Java API-je, lahko deluje z aplikacijami, ki niso Java, in je združljiv s CORBA.
Kako deluje sistem odjemalec / strežnik EJB
Da bi razumeli, kako deluje sistem odjemalec / strežnik EJB, moramo razumeti osnovne dele sistema EJB: komponento EJB, vsebnik EJB in objekt EJB.
Komponenta Enterprise JavaBeans
Enterprise JavaBean je komponenta, tako kot tradicionalni JavaBean. Enterprise JavaBeans se izvrši v Posoda EJB, ki se nato izvede v EJB strežnik. Vsak strežnik, ki lahko gosti vsebnik EJB in mu nudi potrebne storitve, je lahko strežnik EJB. (To pomeni, da se lahko številni obstoječi strežniki razširijo na strežnike EJB, v resnici pa so številni prodajalci to dosegli ali pa so napovedali svojo namero.)
Komponenta EJB je vrsta razreda EJB, ki se najverjetneje šteje za "Enterprise JavaBean". Gre za razred Java, ki ga je napisal razvijalec EJB in izvaja poslovno logiko. Vsi drugi razredi v sistemu EJB bodisi podpirajo dostop odjemalca do razredov komponent EJB bodisi zagotavljajo storitve (kot je obstojnost itd.).
Posoda Enterprise JavaBeans
Vsebnik EJB je tam, kjer komponenta EJB "živi". Vsebnik EJB ponuja storitve, kot so upravljanje transakcij in virov, različice, razširljivost, mobilnost, obstojnost in varnost komponent EJB, ki jih vsebuje. Ker vsebnik EJB obravnava vse te funkcije, se lahko razvijalec komponente EJB osredotoči na poslovna pravila in vsebniku prepusti manipulacijo z bazo podatkov in druge take podrobne podrobnosti. Če se na primer posamezna komponenta EJB odloči, da je treba trenutno transakcijo prekiniti, preprosto pove svoj vsebnik (na način, ki ga določa EJB Spec, kontejner pa je odgovoren za izvedbo vseh povratnih sprememb ali za vse, kar je potrebno za preklic transakcije, ki je v teku. V enem vsebniku EJB običajno obstaja več primerkov komponent EJB.
Objekt EJB in oddaljeni vmesnik
Odjemalski programi izvajajo metode na oddaljenih EJB s pomočjo EJB objekt. Objekt EJB izvaja "oddaljeni vmesnik" komponente EJB na strežniku. Oddaljeni vmesnik predstavlja "poslovne" metode komponente EJB. Oddaljeni vmesnik opravi dejansko, koristno delo predmeta EJB, na primer ustvari obrazec za naročilo ali odpošlje pacienta k specialistu. V nadaljevanju bomo podrobneje obravnavali oddaljeni vmesnik.
