Vodič za početnike za Enterprise JavaBeans

Enterprise JavaBeans (EJB) stvorio je veliko uzbuđenje od najave Enterprise JavaBeans Specification Verzije 1.0 u ožujku 1998. godine . Tvrtke kao što su Oracle, Borland, Tandem, Symantec, Sybase i Visigenic, između mnogih drugih, najavile su i / ili isporučile proizvode koji se pridržavaju EJB specifikacija. Ovog ćemo mjeseca na visokoj razini pogledati što je zapravo Enterprise JavaBeans. Razmotrit ćemo kako se EJB razlikuje od izvornog modela komponenata JavaBeans i raspravit ćemo zašto je EJB generirao tako veliku količinu interesa.

Ali prvo, savjet: ovaj mjesec nećemo gledati izvorni kod ili teme s uputama. Ovaj članak nije udžbenik; nego je to arhitektonski pregled. EJB pokriva puno teritorija, a bez prethodnog razumijevanja osnovnih pojmova, isječci koda i programski trikovi su besmisleni. Ako postoji interes čitatelja JavaWorlda , budući članci mogu pokrivati ​​specifičnosti korištenja Enterprise JavaBeans API-ja za stvaranje vlastitih Enterprise JavaBeans-a.

Da bismo razumjeli zašto je EJB toliko privlačan programerima, treba nam neka povijesna pozadina. Prvo ćemo pogledati povijest sustava klijent / poslužitelj i trenutno stanje. Zatim ćemo razgovarati o različitim dijelovima EJB sustava: EJB komponente - koje žive na EJB spremniku pokrenutom unutar EJB poslužitelja - i EJB objekti, koje klijent koristi kao neku vrstu "daljinskog upravljanja" EJB komponenata . Preći ćemo na dvije vrste EJB-ova: sesijski i entitetni objekti. Pročitat ćete i o kući i daljinskom upravljačusučelja koja stvaraju instance EJB-a i pružaju pristup poslovnim metodama EJB-a. Na kraju članka imat ćete ideju kako se proširivi poslužitelji mogu graditi pomoću Enterprise JavaBeans-a. Ali prvo, pogled u prošlost.

Povijest klijenta / poslužitelja

Drevna povijest

U početku je bilo glavno računalo. I bilo je dobro. (Ili ionako onoliko dobro koliko je dobilo.) Stanje tehnike obrade informacija tijekom šezdesetih godina sastojalo se prvenstveno od velikih, skupih strojeva koje su velike organizacije koristile za potporu svakodnevnom poslovanju. Miniračunala i dijeljenje vremena 1970-ih povećali su dostupnost računalne snage, ali informacije i obrada i dalje su bili centralizirani na pojedinačnim strojevima. Prva osobna računala u 1980-ima brzo su zatrpala korporativni krajolik tisućama malenih otočića informacija, a svi su neumorno izbacivali izvješća promjenjive kvalitete, gubili kritične podatke kad su se srušili i brzo postajali međusobno neskladni.

Klijent / poslužitelj u pomoć

Klijent / poslužiteljska arhitektura jedno je od najčešćih rješenja zagonetke kako riješiti potrebu za centraliziranom kontrolom podataka i širokom dostupnošću podataka. U sustavima klijent / poslužitelj informacije se održavaju relativno centraliziranim (ili se dijele i / ili repliciraju među distribuiranim poslužiteljima), što olakšava kontrolu i dosljednost podataka, a istovremeno pruža pristup podacima koji su potrebni korisnicima.

Klijentsko-poslužiteljski sustavi sada se obično sastoje od različitog broja slojeva. Standardni stari glavni računalo ili sustav dijeljenja vremena, gdje se korisničko sučelje izvodi na istom računalu kao baza podataka i poslovne aplikacije, poznat je kao jednoslojni. Takvim je sustavima relativno lako upravljati, a dosljednost podataka je jednostavna jer se podaci pohranjuju na samo jednom mjestu. Nažalost, jednoslojni sustavi imaju ograničenu skalabilnost i skloni su opasnostima od dostupnosti (ako je jedno računalo u kvaru, cijelo vaše poslovanje propada), posebno ako je u pitanju komunikacija.

Prvi sustavi klijent / poslužitelj bili su dvoslojni, pri čemu se korisničko sučelje izvodilo na klijentu, a baza podataka živjela je na poslužitelju. Takvi su sustavi još uvijek česti. Dvoslojni poslužitelj vrste vrtne sorte izvodi većinu poslovne logike na klijentu, ažurirajući zajedničke podatke slanjem tokova SQL-a na poslužitelj. Ovo je fleksibilno rješenje, jer se razgovor klijent / poslužitelj odvija na razini jezika baze podataka poslužitelja. U takvom sustavu, pravilno dizajnirani klijent može se modificirati tako da odražava nova poslovna pravila i uvjete bez mijenjanja poslužitelja, sve dok poslužitelj ima pristup shemi baze podataka (tablicama, prikazima i tako dalje) potrebnoj za obavljanje transakcija. Poslužitelj u takvom dvorazinskom sustavu naziva se poslužitelj baze podataka, kao što je prikazano u nastavku.

Ipak, poslužitelji baze podataka imaju neke obveze. Često je SQL za određenu poslovnu funkciju (na primjer, dodavanje stavke u narudžbu) identičan, osim podataka koji se ažuriraju ili ubacuju, od poziva do poziva. Poslužitelj baze podataka završava raščlanjivanjem i ponovnim analizama gotovo identičnog SQL-a za svaku poslovnu funkciju. Na primjer, svi SQL izrazi za dodavanje stavke u narudžbu vjerojatno će biti vrlo slični, kao i SQL izrazi za pronalaženje kupca u bazi podataka. Vrijeme koje treba ovom raščlanjivanju bolje bi se potrošilo na obradu podataka. (Postoje lijekovi za ovaj problem, uključujući SQL raščlanjivanje predmemorije i pohranjene procedure.) Drugi problem koji se pojavljuje je istodobno izdavanje verzija klijentima i bazi podataka: svi se strojevi moraju isključiti radi nadogradnje,a klijenti ili poslužitelji koji zaostaju u svojoj verziji softvera obično se ne mogu koristiti dok ih ne nadograde.

Aplikacijski poslužitelji

Aplikacija poslužitelj arhitektura (vidi sljedeću sliku) je popularna alternativa arhitekture poslužitelja baze podataka, jer to rješava neke probleme baza podataka poslužitelja imati.

Okolina poslužitelja baze podataka obično izvršava poslovne metode na klijentu i koristi poslužitelj uglavnom za trajnost i provođenje integriteta podataka. Na poslužitelju aplikacija, poslovne metode se izvode na poslužitelju, a klijent zahtijeva da poslužitelj izvrši te metode. U ovom scenariju klijent i poslužitelj obično će koristiti protokol koji predstavlja razgovor na razini poslovnih transakcija, umjesto na razini tablica i redaka. Takvi poslužitelji aplikacija često imaju bolji učinak od svojih kolega baze podataka, ali i dalje pate od problema s verzijama.

I baze podataka i aplikacijski sustavi mogu se poboljšati dodavanjem dodatnih razina u arhitekturu. Takozvani troslojni sustavi postavljaju posrednu komponentu između klijenta i poslužitelja. Čitava industrija - međuproizvodi - pojavila se kako bi riješila obveze dvorazinskih sustava. Monitor transakcija za obradu,jedna vrsta posredničkog softvera, prima tijekove zahtjeva od mnogih klijenata i može uravnotežiti opterećenje između više poslužitelja, osigurati preusmjeravanje kada poslužitelj zakaže i upravlja transakcijama u ime klijenta. Ostale vrste posredničkog softvera nude prijevod komunikacijskog protokola, objedinjuju zahtjeve i odgovore između klijenata i više heterogenih poslužitelja (ovo je posebno popularno u radu sa naslijeđenim sustavima u ponovnom inženjeringu poslovnih procesa) i / ili pružaju mjerenje usluga i informacije o mrežnom prometu.

Više nivoa pruža fleksibilnost i interoperabilnost što je rezultiralo sustavima s više od ova tri sloja usluge. Na primjer, n-tier sustavi su generalizacija troslojnih sustava, a svaki sloj softvera pruža različitu razinu usluge slojevima iznad i ispod njega. N-tier perspektiva mrežu smatra skupom distribuiranih usluga, a ne samo sredstvom za pristup klijenta jednom poslužitelju.

Kako su objektno orijentirani jezici i tehnike ušli u modu, tako su se i klijent / poslužiteljski sustavi sve više kretali prema objektnoj orijentaciji. CORBA (Common Object Request Broker Architecture) arhitektura je koja omogućuje objektima unutar aplikacija - čak i objektima napisanim na različitim jezicima - da se izvode na odvojenim strojevima, ovisno o potrebama određene aplikacije. Aplikacije napisane prije godina mogu se pakirati kao CORBA usluge i međusobno surađivati ​​s novim sustavima. Enterprise JavaBeans, koji je dizajniran da bude kompatibilan s CORBA-om, još je jedan ulazak u objektno orijentirani prsten aplikacijskog poslužitelja.

Svrha ovog članka nije pružiti tutorial o sustavima klijent / poslužitelj, ali bilo je potrebno pružiti neke pozadine kako bi se definirao kontekst. Sada pogledajmo što EJB nudi.

Enterprise JavaBeans i proširivi poslužitelji aplikacija

Sad kad smo pogledali malo povijesti i razumjeli što su poslužitelji aplikacija, pogledajmo Enterprise JavaBeans i vidjet ćemo što on nudi u tom kontekstu.

Osnovna ideja koja stoji iza Enterprise JavaBeans-a je pružanje okvira za komponente koje mogu biti "priključene" na poslužitelj, čime se proširuje njegova funkcionalnost. Enterprise JavaBeans sličan je izvornom JavaBeansu samo po tome što koristi neke slične koncepte. EJB tehnologijom ne upravlja JavaBeans komponentna specifikacija, već potpuno drugačija (i masivna) Enterprise JavaBeans specifikacija. (Pogledajte Resurse za detalje o ovoj specifikaciji.) EJB Spec poziva različite igrače u EJB sustavu klijent / poslužitelj, opisuje kako EJB surađuje s klijentom i sa postojećim sustavima, opisuje EJB-ovu kompatibilnost s CORBA-om i definira odgovornosti za razne komponente u sustavu.

Poduzetnički JavaBeans ciljevi

EJB Spec pokušava ostvariti nekoliko ciljeva odjednom:

  • EJB je dizajniran kako bi programerima olakšao stvaranje aplikacija, oslobađajući ih detalja o sustavu niske razine upravljanja transakcijama, nitima, uravnoteženjem opterećenja itd. Programeri aplikacija mogu se usredotočiti na poslovnu logiku i detalje upravljanja obradom podataka prepustiti okviru. Međutim, za specijalizirane programe uvijek je moguće ući "ispod haube" i prilagoditi ove usluge niže razine.

  • EJB Spec definira glavne strukture EJB okvira, a zatim posebno definira ugovore između njih. Odgovornosti klijenta, poslužitelja i pojedinačnih komponenata jasno su napisane. (Za trenutak ćemo razmotriti kakve su ove strukture.) Programer koji stvara Enterprise JavaBean komponentu ima vrlo različitu ulogu od nekoga tko stvara EJB-kompatibilan poslužitelj, a specifikacija opisuje odgovornosti svakog od njih.

  • EJB želi biti standardni način za izradu klijentskih / poslužiteljskih aplikacija na jeziku Java. Baš kao što se izvorni JavaBeans (ili Delphi komponente ili bilo što drugo) različitih dobavljača mogu kombinirati za izradu prilagođenog klijenta, tako se i EJB poslužiteljske komponente različitih dobavljača mogu kombinirati za izradu prilagođenog poslužitelja. EJB komponente, kao Java klase, naravno, izvodit će se na bilo kojem EJB poslužitelju bez ponovne kompilacije. To je prednost koju se rješenja za platformu ne mogu nadati.

  • Konačno, EJB je kompatibilan i koristi druge Java API-je, može surađivati ​​s aplikacijama koje nisu Java i kompatibilan je s CORBA-om.

Kako funkcionira sustav EJB klijent / poslužitelj

Da bismo razumjeli kako funkcionira sustav EJB klijent / poslužitelj, moramo razumjeti osnovne dijelove EJB sustava: komponentu EJB, spremnik EJB i objekt EJB.

Komponenta Enterprise JavaBeans

Poduzetnički JavaBean komponenta je, baš kao i tradicionalni JavaBean. Poduzeće JavaBeans izvršava se unutar EJB spremnika, koji se pak izvršava unutar EJB poslužitelja. Svaki poslužitelj koji može ugostiti EJB spremnik i pružiti mu potrebne usluge može biti EJB poslužitelj. (To znači da se mnogi postojeći poslužitelji mogu proširiti na EJB poslužitelje, a zapravo su mnogi dobavljači to postigli ili su najavili da to namjeravaju učiniti.)

EJB komponenta je vrsta klase EJB koja se najvjerojatnije smatra "Enterprise JavaBean". To je Java klasa koju je napisao programer EJB, a koja implementira poslovnu logiku. Sve ostale klase u EJB sustavu ili podržavaju pristup klijenta ili pružaju usluge (poput postojanosti i tako dalje) razredima komponenata EJB.

Spremnik Enterprise JavaBeans

EJB spremnik je mjesto gdje EJB komponenta "živi". Spremnik EJB pruža usluge kao što su upravljanje transakcijama i resursima, izrada verzija, skalabilnost, mobilnost, postojanost i sigurnost komponenata EJB koje sadrži. Budući da EJB spremnik obrađuje sve ove funkcije, programer EJB komponente može se koncentrirati na poslovna pravila, a manipulaciju bazom podataka i druge takve fine detalje prepustiti spremniku. Na primjer, ako pojedinačna EJB komponenta odluči da trenutnu transakciju treba prekinuti, ona jednostavno kaže svoj spremnik (na način definiran EJB-ovom specifikacijom, a spremnik je odgovoran za izvršavanje svih vraćanja ili poduzimanje bilo čega što je potrebno za otkazivanje transakcija je u tijeku. Više instanci EJB komponenata obično postoji unutar jednog EJB spremnika.

EJB objekt i udaljeno sučelje

Klijentski programi izvršavaju metode na udaljenim EJB-ovima putem EJB objekta. EJB objekt implementira "udaljeno sučelje" EJB komponente na poslužitelju. Daljinsko sučelje predstavlja "poslovne" metode EJB komponente. Udaljeno sučelje obavlja stvarni, korisni posao EJB objekta, poput izrade obrasca za narudžbu ili odgađanja pacijenta stručnjaku. U nastavku ćemo detaljnije razgovarati o udaljenom sučelju.