Nuo 1998 m. Kovo mėn. Paskelbus „Enterprise JavaBeans“ (EJB), kilo didelis jaudulys „Enterprise JavaBeans“ specifikacijos versija 1.0. Tokios kompanijos kaip „Oracle“, „Borland“, „Tandem“, „Symantec“, „Sybase“ ir „Visigenic“, be kita ko, paskelbė ir (arba) pristatė produktus, kurie atitinka EJB specifikacijas. Šį mėnesį mes apžvelgsime, kas tiksliai yra „Enterprise JavaBeans“. Išsiaiškinsime, kuo EJB skiriasi nuo originalaus „JavaBeans“ komponento modelio, ir aptarsime, kodėl EJB sukėlė tokį didžiulį susidomėjimą.
Bet pirmiausia, patarimas: šį mėnesį mes nežiūrėsime šaltinio kodo ar patarimų temų. Šis straipsnis nėra pamoka; greičiau tai architektūrinė apžvalga. EJB apima daugybę teritorijų, o prieš tai neišmanant pagrindinių susijusių sąvokų, kodo fragmentai ir programavimo gudrybės yra beprasmiški. Jei yra susidomėjimo „JavaWorld“Skaitytojai būsimuose straipsniuose gali aptarti „Enterprise JavaBeans“ API naudojimo specifiką kuriant savo „Enterprise JavaBeans“.
Norint suprasti, kodėl EJB yra tokia patraukli kūrėjams, mums reikia tam tikro istorinio pagrindo. Pirmiausia apžvelgsime kliento / serverio sistemų istoriją ir dabartinę situaciją. Tada aptarsime įvairias EJB sistemos dalis: EJB komponentai - kurie gyvena EJB konteineris bėga į vidų EJB serveris - ir EJB objektai, kurį klientas naudoja kaip tam tikrą „nuotolinį valdymą“ EJB komponentams. Mes apžvelgsime dviejų tipų EJB: sesija ir subjektas objektai. Jūs taip pat perskaitysite apie namai ir Nuotolinis sąsajų, kurios sukuria EJB egzempliorius ir suteikia prieigą prie EJB verslo metodų. Straipsnio pabaigoje turėsite idėją, kaip išplėstinius serverius galima sukurti naudojant „Enterprise JavaBeans“. Bet pirmiausia - žvilgsnis į praeitį.
Kliento / serverio istorija
Senovės istorija
Pradžioje buvo pagrindinis kompiuteris. Ir tai buvo gerai. (Šiaip ar taip gerai, kaip buvo.) Informacijos apdorojimo pažanga praėjusio amžiaus šeštajame dešimtmetyje pirmiausia susidarė iš didelių, brangių mašinų, kurias didžiosios organizacijos naudojo savo kasdienei verslo veiklai palaikyti. Aštuntajame dešimtmetyje minikompiuteriai ir laiko pasidalijimas padidino skaičiavimo galios prieinamumą, tačiau informacija ir apdorojimas vis tiek buvo centralizuoti atskirose mašinose. Pirmieji devintojo dešimtmečio asmeniniai kompiuteriai greitai užgriovė įmonių aplinką tūkstančiais mažų informacijos salelių, kurios visos nenuilstamai išmaišydavo įvairios kokybės ataskaitas, praradusios kritinius duomenis, kai jos sudužo, ir greitai tapo nesuderinamos viena su kita.
Klientas / serveris gelbsti
Kliento / serverio architektūra yra vienas iš dažniausiai pasitaikančių sprendimų, kaip išspręsti tiek centralizuoto duomenų valdymo, tiek plačiai prieinamų duomenų prieigą. Kliento / serverio sistemose informacija laikoma santykinai centralizuota (arba yra padalijama ir (arba) atkartojama tarp paskirstytų serverių), o tai palengvina duomenų kontrolę ir nuoseklumą, tačiau vis tiek suteikia prieigą prie duomenų, kurių reikia vartotojams.
Kliento-serverio sistemos dabar paprastai susideda iš įvairių skaičių pakopas. Standartinė senoji pagrindinio kompiuterio arba laiko pasidalijimo sistema, kai vartotojo sąsaja veikia tame pačiame kompiuteryje kaip ir duomenų bazė bei verslo programos, yra žinoma kaip vienos pakopos. Tokias sistemas palyginti lengva valdyti, o duomenų nuoseklumas yra paprastas, nes duomenys saugomi tik vienoje vietoje. Deja, vienos pakopos sistemos yra riboto mastelio ir yra linkusios į prieinamumo pavojus (jei neveikia vienas kompiuteris, sumažėja visas jūsų verslas), ypač jei tai susiję su bendravimu.
Pirmosios kliento / serverio sistemos buvo dviejų pakopų, kur vartotojo sąsaja vyko kliente, o duomenų bazė buvo serveryje. Tokios sistemos vis dar paplitusios. Vienas sodo tipo dviejų pakopų serveris atlieka didžiąją verslo logikos dalį kliente, atnaujindamas bendrus duomenis siunčiant SQL srautus į serverį. Tai lankstus sprendimas, nes kliento / serverio pokalbis vyksta serverio duomenų bazės kalbos lygiu. Tokioje sistemoje tinkamai sukurtą klientą galima modifikuoti taip, kad jis atspindėtų naujas verslo taisykles ir sąlygas, nekeisdamas serverio, jei tik serveris turi prieigą prie duomenų bazės schemos (lentelių, rodinių ir pan.), Reikalingos operacijoms atlikti. Serveris tokioje dviejų pakopų sistemoje vadinamas a duomenų bazės serveris, kaip parodyta žemiau.
Duomenų bazių serveriai vis dėlto turi tam tikrų įsipareigojimų. Dažnai konkrečios verslo funkcijos (pavyzdžiui, elemento pridėjimas prie užsakymo) SQL yra identiškas, išskyrus atnaujinamus ar įterptus duomenis nuo skambučio iki skambučio. Duomenų bazės serveris baigia analizuoti ir taisyti beveik identišką SQL kiekvienai verslo funkcijai. Pvz., Visi SQL teiginiai, skirti elementui pridėti prie užsakymo, greičiausiai bus labai panašūs, kaip ir SQL sakiniai, skirti rasti klientą duomenų bazėje. Laikas, kurį užtrunka šis analizavimas, būtų geriau praleistas iš tikrųjų apdorojant duomenis. (Yra šios problemos sprendimo būdai, įskaitant SQL išanalizavimo talpyklas ir saugomas procedūras.) Kita iškilusi problema yra tuo pačiu metu versijuoti klientus ir duomenų bazę: visos mašinos turi būti išjungtos atnaujinti, o klientai ar serveriai atsilieka nuo jų. programinės įrangos versija paprastai nėra naudojama, kol jos nėra atnaujinta.
Programų serveriai
An programų serveris architektūra (žr. kitą vaizdą) yra populiari alternatyva duomenų bazės serverio architektūrai, nes ji išsprendžia kai kurias duomenų bazės serverių problemas.
Duomenų bazės serverio aplinka paprastai vykdo verslo metodus kliente ir dažniausiai naudoja serverį atkaklumui ir duomenų vientisumui užtikrinti. Programų serveryje verslo metodai vykdomi serveryje, o klientas prašo, kad serveris vykdytų šiuos metodus. Tokiu atveju klientas ir serveris paprastai naudos protokolą, kuris vaizduoja pokalbį verslo operacijų lygiu, o ne lentelių ir eilučių lygiu. Tokie programų serveriai dažnai veikia geriau nei jų duomenų bazės partneriai, tačiau jie vis tiek kenčia nuo versijų problemų.
Tiek duomenų bazių, tiek programų sistemas galima patobulinti, į architektūrą pridedant papildomų pakopų. Vadinamoji trijų pakopų sistemos įdeda tarpinį komponentą tarp kliento ir serverio. Visa pramonė - tarpinė programinė įranga - išaugo, kad galėtų išspręsti dviejų pakopų sistemų įsipareigojimus. A operacijų apdorojimo monitorius, vienos rūšies tarpinė programinė įranga, gauna užklausų srautus iš daugelio klientų ir gali subalansuoti kelių serverių apkrovą, pateikti gedimą serveriui sugedus ir valdyti operacijas kliento vardu. Kiti tarpinės programinės įrangos tipai teikia ryšių protokolų vertimą, konsoliduoja užklausas ir atsakymus tarp klientų ir kelių heterogeninių serverių (tai ypač populiaru sprendžiant senas sistemas verslo procesų perprojektavimo srityje) ir (arba) teikia paslaugų apskaitą ir informaciją apie tinklo srautą.
Keli lygiai suteikia lankstumo ir sąveikumo, dėl kurio atsirado sistemos, turinčios daugiau nei šiuos tris paslaugų sluoksnius. Pavyzdžiui, n pakopa sistemos yra trijų pakopų sistemų apibendrinimai, kurių kiekvienas programinės įrangos sluoksnis teikia skirtingą aptarnavimo lygį virš jo ir po juo esančiuose sluoksniuose. „N“ pakopos požiūriu tinklas laikomas paskirstytų paslaugų baseinu, o ne paprasčiausia priemone klientui pasiekti vieną serverį.
Kai į objektą orientuotos kalbos ir metodai atėjo į madą, kliento / serverio sistemos vis labiau ėjo link orientacijos į objektą. CORBA („Common Object Request Broker Architecture“) yra architektūra, leidžianti programose esantiems objektams - net ir skirtingomis kalbomis parašytiems objektams - veikti atskiromis mašinomis, atsižvelgiant į tam tikros programos poreikius. Prieš daugelį metų parašytas programas galima supakuoti kaip CORBA paslaugas ir sąveikauti su naujomis sistemomis. „Enterprise JavaBeans“, sukurtas suderinti su CORBA, yra dar vienas įrašas į objektu orientuotą programų ir serverių žiedą.
Šio straipsnio tikslas nėra pateikti kliento / serverio sistemų pamokų, tačiau norint apibrėžti kontekstą, reikėjo pateikti tam tikrą pagrindą. Dabar pažvelkime į tai, ką siūlo EJB.
Įmonės „JavaBeans“ ir išplėstinių programų serveriai
Dabar, kai peržiūrėjome šiek tiek istorijos ir supratome, kas yra programų serveriai, pažvelkime į „Enterprise JavaBeans“ ir pažiūrėkime, ką ji siūlo šiame kontekste.
Pagrindinė „Enterprise JavaBeans“ idėja yra sudedamųjų dalių, kurios gali būti „prijungtos“ prie serverio, sistema ir taip išplėsti to serverio funkcionalumą. „Enterprise JavaBeans“ yra panašus į originalius „JavaBeans“ tik tuo, kad naudoja keletą panašių sąvokų. EJB technologija nėra reglamentuojama „JavaBeans“ komponentų specifikacija, bet visiškai kitokiu (ir masiniu) Įmonės „JavaBeans“ specifikacija. (Žr. Šaltinius, jei norite gauti daugiau informacijos apie šią specifikaciją.) EJB Spec kviečia įvairius EJB kliento / serverio sistemos žaidėjus, apibūdina, kaip EJB sąveikauja su klientu ir esamomis sistemomis, paaiškina EJB suderinamumą su CORBA ir apibrėžia atsakomybę už įvairius sistemos komponentus.
Įmonės „JavaBeans“ tikslai
EJB Spec bando pasiekti kelis tikslus vienu metu:
EJB sukurtas tam, kad kūrėjams būtų lengva kurti programas, atleidžiant juos nuo žemo lygio operacijų, gijų, apkrovos balansavimo ir pan. Valdymo informacijos. Programų kūrėjai gali sutelkti dėmesį į verslo logiką ir palikti duomenų tvarkymo valdymo detales. Tačiau specializuotoms programoms visada galima „pakliūti po dangčiu“ ir pritaikyti šias žemesnio lygio paslaugas.
EJB Spec apibrėžia pagrindines EJB sistemos struktūras, o tada konkrečiai apibrėžia jų tarpusavio sutartis. Kliento, serverio ir atskirų komponentų atsakomybė yra aiškiai apibrėžta. (Per akimirką apžvelgsime, kokios yra šios struktūros.) „Enterprise JavaBean“ komponentą kuriantis kūrėjas vaidina labai skirtingą vaidmenį nei tas, kuris kuria EJB suderinamą serverį, o specifikacijoje aprašomos kiekvieno atsakomybės.
EJB siekia būti standartiniu būdu kliento / serverio programoms kurti Java kalba. Kaip skirtingų gamintojų originalius „JavaBeans“ (arba „Delphi“ komponentus ar bet kokius kitus dalykus) galima sujungti, kad būtų sukurtas pasirinktinis klientas, taip pat skirtingų gamintojų EJB serverio komponentai gali būti sujungti, kad būtų sukurtas pasirinktinis serveris. EJB komponentai, kaip „Java“ klasės, be abejo, bus paleisti bet kuriame su EJB suderinamame serveryje be kompiliavimo. Tai yra nauda, kurios negali tikėtis pasiūlyti konkrečios platformos sprendimai.
- Galiausiai, EJB yra suderinamas su kitomis „Java“ API ir naudoja jas, gali sąveikauti su ne „Java“ programomis ir yra suderinamas su CORBA.
Kaip veikia EJB kliento / serverio sistema
Norėdami suprasti, kaip veikia EJB kliento / serverio sistema, turime suprasti pagrindines EJB sistemos dalis: EJB komponentą, EJB konteinerį ir EJB objektą.
„Enterprise JavaBeans“ komponentas
„Enterprise JavaBean“ yra komponentas, kaip ir tradicinis „JavaBean“. „Enterprise JavaBeans“ vykdo EJB konteineris, kuris savo ruožtu vykdo per EJB serveris. Bet kuris serveris, galintis talpinti EJB konteinerį ir suteikti jam reikalingas paslaugas, gali būti EJB serveris. (Tai reiškia, kad daugelis esamų serverių gali būti išplėsti į EJB serverius, ir iš tikrųjų daugelis pardavėjų tai pasiekė arba paskelbė ketinantys tai padaryti.)
EJB komponentas yra EJB klasės tipas, kuris greičiausiai bus laikomas „Enterprise JavaBean“. Tai „Java“ klasė, parašyta EJB kūrėjo, įgyvendinanti verslo logiką. Visos kitos EJB sistemos klasės palaiko kliento prieigą prie EJB komponentų klasių arba teikia paslaugas (pvz., Patvarumas ir pan.).
„Enterprise JavaBeans“ konteineris
EJB konteineris yra tas, kuriame „gyvena“ EJB komponentas. „EJB“ konteineris teikia tokias paslaugas kaip operacijų ir išteklių valdymas, versijų kūrimas, mastelio keitimas, mobilumas, patvarumas ir saugumas. Kadangi EJB konteineris vykdo visas šias funkcijas, EJB komponentų kūrėjas gali sutelkti dėmesį į verslo taisykles ir palikti konteineriui manipuliavimą duomenų baze ir kitą tokią išsamią informaciją. Pvz., Jei vienas EJB komponentas nusprendžia, kad dabartinis sandoris turėtų būti nutrauktas, jis paprasčiausiai nurodo savo konteinerį (tokiu būdu, kurį nustato EJB Spec, o konteineris yra atsakingas už visų grąžinimų atlikimą arba viską, kas būtina norint atšaukti vykdomą operaciją. Keli EJB komponentų egzemplioriai paprastai yra vieno EJB konteinerio viduje.
EJB objektas ir nuotolinė sąsaja
Kliento programos vykdo nuotolinių EJB metodus EJB objektas. EJB objektas serveryje įdiegia EJB komponento „nuotolinę sąsają“. Nuotolinė sąsaja rodo EJB komponento „verslo“ metodus. Nuotolinė sąsaja atlieka tikrąjį, naudingą EJB objekto darbą, pavyzdžiui, sukuria užsakymo formą arba atideda pacientą specialistui. Toliau išsamiau aptarsime nuotolinę sąsają.
