Uzņēmums JavaBeans (EJB) ir izraisījis lielu satraukumu kopš 1998. Gada marta paziņojuma par Enterprise JavaBeans specifikācijas versija 1.0. Tādi uzņēmumi kā Oracle, Borland, Tandem, Symantec, Sybase un Visigenic, cita starpā, ir paziņojuši un / vai piegādājuši produktus, kas atbilst EJB specifikācijai. Šomēnes augstā līmenī apskatīsim, kas tieši ir Enterprise JavaBeans. Mēs izskatīsim, kā EJB atšķiras no sākotnējā JavaBeans komponentu modeļa, un apspriedīsim, kāpēc EJB ir radījis tik milzīgu interesi.
Bet vispirms padomdevējs: mēs šomēnes nemeklēsim avota kodu vai norādījumus. Šis raksts nav apmācība; drīzāk tas ir arhitektūras pārskats. EJB aptver daudz teritoriju, un, vispirms neizprotot iesaistītos pamatjēdzienus, koda fragmenti un programmēšanas triki ir bezjēdzīgi. Ja ir interese no JavaWorldLasītāju lasījumā nākamajos rakstos var aplūkot Enterprise JavaBeans API izmantošanas specifiku, lai izveidotu savus Enterprise JavaBeans.
Lai saprastu, kāpēc EJB ir tik pievilcīgs izstrādātājiem, mums ir nepieciešams zināms vēsturiskais pamatojums. Pirmkārt, mēs aplūkosim klienta / servera sistēmu vēsturi un pašreizējo situāciju. Tad mēs apspriedīsim dažādas EJB sistēmas daļas: EJB komponenti - kas dzīvo uz EJB konteiners skrien iekšā EJB serveris -- un EJB objekti, kuru klients izmanto kā sava veida EJB komponentu "tālvadības pulti". Mēs aplūkosim divu veidu EJB: sesija un vienība objektiem. Jūs arī lasīsit par mājas un tālvadības pults saskarnes, kas rada EJB instances un nodrošina piekļuvi attiecīgi EJB uzņēmējdarbības metodēm. Raksta beigās jums būs ideja par paplašināmu serveru izveidi, izmantojot Enterprise JavaBeans. Bet vispirms atskats uz laiku.
Klienta / servera vēsture
Senā vēsture
Sākumā bija lieldatoru dators. Un tas bija labi. (Vai arī tik labi, cik tas ir sanācis.) Informācijas apstrādes sasniegumi pagājušā gadsimta sešdesmitajos gados galvenokārt sastāvēja no lielām, dārgām mašīnām, kuras lielās organizācijas izmantoja, lai atbalstītu viņu ikdienas uzņēmējdarbību. Minidatori un laika koplietošana 1970. gados palielināja skaitļošanas jaudas pieejamību, taču informācija un apstrāde joprojām tika centralizēta atsevišķās mašīnās. Pirmie personālie datori astoņdesmitajos gados ātri pārblīvēja korporatīvo ainavu ar tūkstošiem sīku informācijas saliņu, kas visi nenogurstoši sagrozīja mainīgas kvalitātes pārskatus, avarējot zaudēja kritiskos datus un ātri kļuva savstarpēji pretrunīgi.
Klients / serveris glābšanai
Klienta / servera arhitektūra ir viens no visbiežāk sastopamajiem risinājumiem, kā risināt gan centralizētas datu vadības, gan plašas datu pieejamības nepieciešamību. Klienta / servera sistēmās informācija tiek turēta samērā centralizēti (vai tiek sadalīta un / vai atkārtota starp izplatītajiem serveriem), kas atvieglo datu kontroli un konsekvenci, vienlaikus nodrošinot piekļuvi lietotājiem nepieciešamajiem datiem.
Klienta-servera sistēmas tagad parasti sastāv no dažādiem numuriem līmeņi. Standarta vecā lieldatora vai laika koplietošanas sistēma, kurā lietotāja saskarne darbojas tajā pašā datorā, kurā darbojas datu bāze un biznesa lietojumprogrammas, ir pazīstama kā viena līmeņa. Šādas sistēmas ir salīdzinoši viegli pārvaldāmas, un datu konsekvence ir vienkārša, jo dati tiek glabāti tikai vienā vietā. Diemžēl vienlīmeņu sistēmām ir ierobežota mērogojamība un tās ir pakļautas pieejamības riskiem (ja viens dators nedarbojas, viss jūsu bizness samazinās), it īpaši, ja ir iesaistīta komunikācija.
Pirmās klienta / servera sistēmas bija divpakāpju, kur lietotāja interfeiss darbojās klientā un datu bāze dzīvoja serverī. Šādas sistēmas joprojām ir izplatītas. Viena veida dārza šķirnes divpakāpju serveris klienta lielāko daļu biznesa loģikas veic, atjauninot koplietotos datus, nosūtot serverim SQL straumes. Tas ir elastīgs risinājums, jo klienta / servera saruna notiek servera datu bāzes valodas līmenī. Šādā sistēmā pareizi izstrādātu klientu var modificēt, lai atspoguļotu jaunos biznesa noteikumus un nosacījumus, nemodificējot serveri, ja vien serverim ir piekļuve datu bāzes shēmai (tabulām, skatiem un tā tālāk), kas nepieciešama darījumu veikšanai. Serveri šādā divpakāpju sistēmā sauc par a datu bāzes serveris, kā parādīts zemāk.
Datu bāzes serveriem tomēr ir dažas saistības. Bieži vien SQL noteiktai uzņēmējdarbības funkcijai (piemēram, vienuma pievienošana pasūtījumam) ir identiska, izņemot datus, kas tiek atjaunināti vai ievietoti, sākot no zvana līdz zvanam. Datu bāzes serveris beidz parsēt un atjaunot gandrīz identisku SQL katrai biznesa funkcijai. Piemēram, visi SQL priekšraksti vienuma pievienošanai pasūtījumam, visticamāk, būs ļoti līdzīgi, tāpat kā SQL priekšraksti klienta atrašanai datu bāzē. Laiks, kas nepieciešams šai parsēšanai, būtu labāk pavadīts, reāli apstrādājot datus. (Šai problēmai ir risinājumi, tostarp SQL parsēšanas kešatmiņas un saglabātās procedūras.) Vēl viena problēma, kas rodas, ir vienlaicīga klientu un datu bāzes versiju izstrāde: visām mašīnām ir jāizslēdz jauninājumi, un klientiem vai serveriem, kas atpaliek no savām programmām programmatūras versija parasti nav izmantojama, kamēr nav jaunināta.
Lietojumprogrammu serveri
An lietojumprogrammu serveris arhitektūra (skat. nākamo attēlu) ir populāra alternatīva datu bāzes servera arhitektūrai, jo tā atrisina dažas no datu bāzes serveru problēmām.
Datu bāzes servera vide parasti izpilda biznesa metodes klientā un serveri galvenokārt izmanto noturībai un datu integritātes nodrošināšanai. Lietojumprogrammu serverī uzņēmējdarbības metodes darbojas serverī, un klients pieprasa, lai serveris izpildītu šīs metodes. Šajā scenārijā klients un serveris parasti izmanto protokolu, kas attēlo sarunu biznesa darījumu līmenī, nevis tabulu un rindu līmenī. Šādi lietojumprogrammu serveri bieži darbojas labāk nekā viņu datu bāzes kolēģi, taču tie joprojām cieš no versiju radīšanas problēmām.
Gan datu bāzes, gan lietojumprogrammu sistēmas var uzlabot, arhitektūrai pievienojot papildu līmeņus. Tā saucamais trīspakāpju sistēmas ievieto starpkomponentu starp klientu un serveri. Lai novērstu divpakāpju sistēmu saistības, ir izveidojusies visa nozare - starpprogrammatūra. A darījumu apstrādes monitors, viena veida starpprogrammatūra, saņem pieprasījumu plūsmas no daudziem klientiem un var līdzsvarot slodzi starp vairākiem serveriem, nodrošināt kļūmi, kad serveris neizdodas, un pārvaldīt darījumus klienta vārdā. Cita veida starpprogrammatūra nodrošina sakaru protokolu tulkošanu, apvieno pieprasījumus un atbildes starp klientiem un vairākiem neviendabīgiem serveriem (tas ir īpaši populāri, strādājot ar mantotajām sistēmām biznesa procesu pārstrādē) un / vai sniedz pakalpojumu uzskaiti un tīkla trafika informāciju.
Vairāki līmeņi nodrošina elastību un savietojamību, kā rezultātā ir izveidotas sistēmas ar vairāk nekā šiem trim pakalpojumu slāņiem. Piemēram, n līmeņa sistēmas ir trīs līmeņu sistēmu vispārinājumi, kur katrs programmatūras slānis nodrošina atšķirīgu apkalpošanas līmeni slāņiem virs un zem tā. N-līmeņa perspektīvā tīkls tiek uzskatīts par izplatīto pakalpojumu kopumu, nevis vienkārši līdzekļiem, kā klients var piekļūt vienam serverim.
Tā kā uz objektu orientētās valodas un paņēmieni ir kļuvuši modē, klienta / servera sistēmas arvien vairāk ir virzījušās uz objektorientāciju. CORBA (Common Object Request Broker Architecture) ir arhitektūra, kas ļauj lietojumprogrammās esošajiem objektiem - pat objektiem, kas rakstīti dažādās valodās - darboties atsevišķās mašīnās atkarībā no konkrētās lietojumprogrammas vajadzībām. Pirms gadiem rakstītās lietojumprogrammas var iepakot kā CORBA pakalpojumus un sadarboties ar jaunām sistēmām. Uzņēmuma JavaBeans, kas paredzēts savietojamībai ar CORBA, ir vēl viens ieraksts objektorientētajā lietojumprogrammu-serveru gredzenā.
Šī raksta mērķis nav sniegt apmācību par klienta / servera sistēmām, taču konteksta definēšanai bija nepieciešams sniegt zināmu fonu. Tagad apskatīsim, ko piedāvā EJB.
Uzņēmuma JavaBeans un paplašināmo lietojumprogrammu serveri
Tagad, kad mēs esam apskatījuši mazliet vēstures un esam sapratuši, kas ir lietojumprogrammu serveri, apskatīsim Enterprise JavaBeans un redzēsim, ko tas piedāvā šajā kontekstā.
Enterprise JavaBeans pamatideja ir nodrošināt sistēmu komponentiem, kurus var "pieslēgt" serverim, tādējādi paplašinot šī servera funkcionalitāti. Enterprise JavaBeans ir līdzīgs sākotnējiem JavaBeans tikai ar to, ka tajā tiek izmantoti daži līdzīgi jēdzieni. EJB tehnoloģiju nepārvalda JavaBeans komponentu specifikācija, bet pilnīgi atšķirīgs (un masīvs) Enterprise JavaBeans specifikācija. (Sīkāku informāciju par šo specifikāciju skatiet resursos.) EJB Spec izsauc dažādus spēlētājus EJB klienta / servera sistēmā, apraksta, kā EJB mijiedarbojas ar klientu un esošajām sistēmām, izklāsta EJB saderību ar CORBA un nosaka atbildību par dažādiem sistēmas komponentiem.
Enterprise JavaBeans mērķi
The EJB Spec mēģina sasniegt vairākus mērķus vienlaikus:
EJB ir izstrādāta tā, lai izstrādātājiem būtu viegli izveidot lietojumprogrammas, atbrīvojot tos no zema līmeņa sistēmas detaļām par darījumu pārvaldīšanu, pavedieniem, slodzes līdzsvarošanu utt. Lietojumprogrammu izstrādātāji var koncentrēties uz biznesa loģiku un atstāt datu apstrādes pārvaldības detaļas satvarā. Tomēr specializētām lietojumprogrammām vienmēr ir iespējams nokļūt "zem pārsega" un pielāgot šos zemākā līmeņa pakalpojumus.
The EJB Spec nosaka galvenās EJB struktūras struktūras un pēc tam konkrēti nosaka līgumus starp tām. Klienta, servera un atsevišķo komponentu pienākumi ir skaidri norādīti. (Pēc brīža mēs iepazīsimies ar šīm struktūrām.) Izstrādātājam, kas izveido Enterprise JavaBean komponentu, ir ļoti atšķirīga loma no tā, kurš izveido ar EJB saderīgu serveri, un specifikācijā ir aprakstīti katra pienākumi.
EJB mērķis ir būt parastam klienta / servera lietojumprogrammu veidošanas veidam Java valodā. Tāpat kā dažādu piegādātāju oriģinālos JavaBeans (vai Delphi komponentus vai ko citu) var apvienot, lai izveidotu pielāgotu klientu, dažādu EJB serveru komponentus var apvienot, lai izveidotu pielāgotu serveri. EJB komponenti, kas ir Java klases, protams, darbosies jebkurā ar EJB saderīgā serverī bez atkārtotas kompilēšanas. Tas ir ieguvums, ko nevar cerēt piedāvāt platformas specifiski risinājumi.
- Visbeidzot, EJB ir saderīgs ar citiem Java API un izmanto tos, var sadarboties ar citām lietotnēm, kas nav Java, un ir saderīgs ar CORBA.
Kā darbojas EJB klienta / servera sistēma
Lai saprastu, kā darbojas EJB klienta / servera sistēma, mums ir jāsaprot EJB sistēmas pamatdaļas: EJB komponents, EJB konteiners un EJB objekts.
Enterprise JavaBeans komponents
Enterprise JavaBean ir sastāvdaļa, tāpat kā tradicionālā JavaBean. Enterprise JavaBeans izpilda EJB konteiners, kas savukārt tiek izpildīts EJB serveris. Jebkurš serveris, kas var uzņemt EJB konteineru un nodrošināt tam nepieciešamos pakalpojumus, var būt EJB serveris. (Tas nozīmē, ka daudzus esošos serverus var paplašināt par EJB serveriem, un faktiski daudzi pārdevēji to ir sasnieguši vai ir paziņojuši par nodomu to darīt.)
EJB komponents ir EJB klases tips, kuru, visticamāk, uzskatīs par "Enterprise JavaBean". Tā ir Java klase, kuru uzrakstījis EJB izstrādātājs un kas īsteno biznesa loģiku. Visas pārējās EJB sistēmas klases vai nu atbalsta klienta piekļuvi EJB komponentu klasēm, vai arī nodrošina pakalpojumus (piemēram, noturība utt.).
Enterprise JavaBeans konteiners
EJB konteiners ir tas, kur "dzīvo" EJB komponents. EJB konteiners sniedz tādus pakalpojumus kā transakciju un resursu pārvaldība, versiju veidošana, mērogojamība, mobilitāte, noturība un drošība tajā esošajiem EJB komponentiem. Tā kā EJB konteiners apstrādā visas šīs funkcijas, EJB komponentu izstrādātājs var koncentrēties uz uzņēmējdarbības noteikumiem un manipulācijas ar datu bāzēm un citas tik sīkas detaļas atstāt konteinerā. Piemēram, ja viens EJB komponents nolemj, ka pašreizējais darījums ir jāpārtrauc, tas vienkārši paziņo savam konteineram (veidā, ko nosaka EJB Spec, un konteiners ir atbildīgs par visu atcelšanu vai visu nepieciešamo, lai atceltu notiekošo darījumu. Vairāki EJB komponentu gadījumi parasti pastāv vienā EJB konteinerā.
EJB objekts un attālā saskarne
Klientu programmas attālās EJB izpilda metodes, izmantojot EJB objekts. EJB objekts serverī ievieš EJB komponenta "attālo saskarni". Attālā saskarne atspoguļo EJB komponenta "biznesa" metodes. Attālā saskarne veic EJB objekta faktisko, noderīgo darbu, piemēram, pasūtījuma veidlapas izveidi vai pacienta atlikšanu speciālistam. Tālāk mēs sīkāk apspriedīsim attālo saskarni.
