Enterprise JavaBeans (EJB) on herättänyt paljon jännitystä sen jälkeen, kun maaliskuussa 1998 ilmoitettiin Enterprise JavaBeans -määritysversio 1.0. Esimerkiksi Oracle, Borland, Tandem, Symantec, Sybase ja Visigenic ovat ilmoittaneet ja / tai toimittaneet tuotteita, jotka noudattavat EJB-määrityksiä. Tässä kuussa tarkastelemme korkeatasoisesti, mitä Enterprise JavaBeans on. Käymme läpi, kuinka EJB eroaa alkuperäisestä JavaBeans-komponenttimallista, ja keskustelemme siitä, miksi EJB on herättänyt niin valtavaa kiinnostusta.
Mutta ensin neuvonta: emme tarkastele lähdekoodia tai ohjeita aiheita tässä kuussa. Tämä artikkeli ei ole opetusohjelma; pikemminkin se on arkkitehtoninen yleiskatsaus. EJB kattaa paljon alueita, ja ymmärtämättä ensin asiaan liittyviä käsitteitä, koodinpätkät ja ohjelmointitrikit ovat merkityksettömiä. Jos on kiinnostusta JavaWorldLukijoiden tulevissa artikkeleissa saatetaan käsitellä Enterprise JavaBeans -sovellusliittymän käytön yksityiskohtia oman Enterprise JavaBeanin luomiseen.
Tarvitsemme historiallista taustaa ymmärtääksemme, miksi EJB on niin houkutteleva kehittäjille. Ensin tarkastellaan asiakas / palvelinjärjestelmien historiaa ja nykytilannetta. Sitten keskustelemme EJB-järjestelmän eri osista: EJB-komponentit - jotka elävät EJB-säiliö juoksu sisällä EJB-palvelin - ja EJB-objektit, jota asiakas käyttää eräänlaisena "EJB-komponenttien" kauko-ohjauksena ". Käymme läpi kahden tyyppiset EJB: t: istunto ja kokonaisuus esineitä. Voit myös lukea Koti ja etä rajapinnat, jotka luovat EJB-esiintymiä ja tarjoavat pääsyn EJB: n liiketoimintamenetelmiin. Artikkelin loppuun mennessä sinulla on käsitys siitä, kuinka laajennettavat palvelimet voidaan rakentaa Enterprise JavaBeansin avulla. Mutta ensin katsaus ajassa taaksepäin.
Asiakas- / palvelinhistoria
Muinaishistoria
Alussa oli keskuskone. Ja se oli hyvä. (Tai niin hyvä kuin se onkin.) Tietojenkäsittelyn taso 1960-luvulle asti koostui pääasiassa suurista, kalliista koneista, joita suuret organisaatiot käyttivät päivittäisen liiketoimintansa tukemiseen. Pientietokoneet ja aikaosuudet 1970-luvulla lisäsivät laskentatehon saatavuutta, mutta tieto ja käsittely keskitettiin edelleen yksittäisiin koneisiin. Ensimmäiset 1980-luvun henkilökohtaiset tietokoneet sekoittivat nopeasti yritystoiminnan tuhansilla pienillä tietosaarilla, jotka kaikki väsyttämättä keräsivät vaihtelevan laadukkaita raportteja, menettivät kriittisiä tietoja kaatuessaan ja muuttuivat nopeasti epäjohdonmukaisiksi keskenään.
Asiakas / palvelin pelastukseen
Asiakas / palvelin -arkkitehtuuri on yksi yleisimmistä ratkaisuista, miten käsitellä sekä keskitetyn tiedonhallinnan että laajamittaisen tiedon saatavuuden tarvetta. Asiakas- / palvelinjärjestelmissä tieto pidetään suhteellisen keskitettynä (tai jaetaan ja / tai kopioidaan hajautettujen palvelimien kesken), mikä helpottaa tietojen hallintaa ja yhdenmukaisuutta, samalla kun tarjoaa pääsyn käyttäjien tarvitsemiin tietoihin.
Asiakas-palvelin-järjestelmät koostuvat nyt useista eri numeroista tasot. Normaali vanha keskusyksikkö tai aikajakojärjestelmä, jossa käyttöliittymä toimii samalla tietokoneella kuin tietokanta ja yrityssovellukset, tunnetaan nimellä yksitasoinen. Tällaisia järjestelmiä on suhteellisen helppo hallita, ja tietojen yhdenmukaisuus on yksinkertaista, koska tietoja tallennetaan vain yhteen paikkaan. Valitettavasti yksitasoisilla järjestelmillä on rajoitettu skaalautuvuus ja ne ovat alttiita käytettävyysvaaroille (jos yksi tietokone on alas, koko yrityksesi menee alas), varsinkin jos kyseessä on viestintä.
Ensimmäiset asiakas / palvelinjärjestelmät olivat kaksitasoinen, jossa käyttöliittymä juoksi asiakkaalla ja tietokanta asui palvelimella. Tällaiset järjestelmät ovat edelleen yleisiä. Yksi puutarhatyyppinen kaksitasoinen palvelin suorittaa suurimman osan asiakkaan liiketoimintalogiikasta päivittämällä jaetut tiedot lähettämällä SQL-virtoja palvelimelle. Tämä on joustava ratkaisu, koska asiakas / palvelin-keskustelu tapahtuu palvelimen tietokannan kielen tasolla. Tällaisessa järjestelmässä oikein suunniteltu asiakasta voidaan muokata vastaamaan uusia liiketoimintasääntöjä ja ehtoja palvelinta muuttamatta, kunhan palvelimella on pääsy liiketoimien suorittamiseen tarvittavaan tietokantakaavioon (taulukot, näkymät jne.). Palvelinta tällaisessa kaksitasoisessa järjestelmässä kutsutaan a tietokantapalvelin, kuten alla.
Tietokantapalvelimilla on kuitenkin joitain vastuita. Usein tietyn liiketoimintatoiminnon SQL (esimerkiksi kohteen lisääminen tilaukseen) on identtinen puhelusta toiseen, lukuun ottamatta päivitettäviä tai lisättäviä tietoja. Tietokantapalvelin jäsentää ja korjaa lähes identtisen SQL: n jokaiselle liiketoiminnalle. Esimerkiksi kaikki SQL-käskyt kohteen lisäämiseen tilaukseen ovat todennäköisesti hyvin samankaltaisia, samoin kuin SQL-käskyt asiakkaan löytämiseksi tietokannasta. Aika, jonka tämä jäsennys vie, olisi parempi käyttää tosiasiallisesti tietojen käsittelyyn. (Tähän ongelmaan on olemassa korjaustoimenpiteitä, mukaan lukien SQL-jäsennysvälimuistit ja tallennetut menettelyt.) Toinen esiin tuleva ongelma on asiakkaiden ja tietokannan versiointi samanaikaisesti: kaikkien koneiden on pysäytettävä päivityksiä varten, ja asiakkaiden tai palvelimien, jotka ovat myöhässä ohjelmistoversiota ei yleensä voi käyttää ennen päivitystä.
Sovelluspalvelimet
An sovelluspalvelin arkkitehtuuri (katso seuraava kuva) on suosittu vaihtoehto tietokantapalvelinarkkitehtuurille, koska se ratkaisee joitain ongelmia, joita tietokantapalvelimilla on.
Tietokantapalvelinympäristö suorittaa yleensä liiketoimintamenetelmät asiakkaalla ja käyttää palvelinta lähinnä pysyvyyteen ja tietojen eheyden varmistamiseen. Sovelluspalvelimessa liiketoimintamenetelmät suoritetaan palvelimella, ja asiakas pyytää palvelinta suorittamaan nämä menetelmät. Tässä tilanteessa asiakas ja palvelin käyttävät yleensä protokollaa, joka edustaa keskustelua liiketapahtumien tasolla taulukkojen ja rivien sijaan. Tällaiset sovelluspalvelimet toimivat usein paremmin kuin tietokanta-kumppaninsa, mutta ne kärsivät silti versiointiongelmista.
Sekä tietokanta- että sovellusjärjestelmiä voidaan parantaa lisäämällä arkkitehtuuriin lisää tasoja. Niin sanottu kolmitasoinen järjestelmät asettavat välikomponentin asiakkaan ja palvelimen välille. Koko teollisuus - väliohjelmisto - on kasvanut vastaamaan kaksitasoisten järjestelmien vastuita. A tapahtumien käsittely -monitori, yhden tyyppinen väliohjelmisto, vastaanottaa pyyntövirtoja monilta asiakkailta ja voi tasapainottaa kuormituksen useiden palvelimien välillä, tarjota vianmäärityksen palvelimen epäonnistumisen yhteydessä ja hallita tapahtumia asiakkaan puolesta. Muunlaiset väliohjelmistot tarjoavat kommunikaatioprotokollien käännöksen, yhdistävät pyynnöt ja vastaukset asiakkaiden ja useiden heterogeenisten palvelinten välillä (tämä on erityisen suosittua vanhojen järjestelmien käsittelyssä liiketoimintaprosessien uudelleensuunnittelussa) ja / tai tarjoavat palvelumittausta ja verkkoliikennetietoja.
Useat tasot tarjoavat joustavuuden ja yhteentoimivuuden, joka on johtanut järjestelmiin, joissa on enemmän kuin nämä kolme palvelutasoa. Esimerkiksi, n-taso järjestelmät ovat kolmitasoisten järjestelmien yleistyksiä, joista kukin ohjelmistokerros tarjoaa eri palvelutasoa sen ylä- ja alapuolella oleville tasoille. N-tason näkökulmasta verkko on hajautettujen palvelujen pooli, eikä pelkästään keino, jolla asiakas voi käyttää yhtä palvelinta.
Kun olio-kielet ja tekniikat ovat tulleet muotiin, niin asiakas / palvelin-järjestelmät ovat yhä enemmän siirtyneet kohti kohdesuuntaa. CORBA (Common Object Request Broker Architecture) on arkkitehtuuri, jonka avulla sovelluksissa olevat kohteet - jopa eri kielillä kirjoitetut - voivat toimia erillisillä koneilla tietyn sovelluksen tarpeiden mukaan. Vuosia sitten kirjoitetut sovellukset voidaan pakata CORBA-palveluiksi ja toimia yhdessä uusien järjestelmien kanssa. Enterprise JavaBeans, joka on suunniteltu yhteensopivaksi CORBA: n kanssa, on toinen merkintä olio-sovellus-palvelinrenkaaseen.
Tämän artikkelin tarkoituksena ei ole tarjota opas asiakkaan / palvelimen järjestelmistä, mutta se oli tarpeen antaa jonkinlainen tausta kontekstin määrittelemiseksi. Katsotaan nyt, mitä EJB: llä on tarjottavanaan.
Enterprise JavaBeans ja laajennettavat sovelluspalvelimet
Nyt kun olemme tarkastelleet vähän historiaa ja ymmärtäneet, mitä sovelluspalvelimet ovat, katsotaanpa Enterprise JavaBeansia ja katsotaan, mitä se tarjoaa tässä yhteydessä.
Enterprise JavaBeansin perusajatuksena on tarjota kehys komponenteille, jotka voidaan "liittää" palvelimeen, ja siten laajentaa palvelimen toimintoja. Enterprise JavaBeans on samanlainen kuin alkuperäinen JavaBeans vain siinä mielessä, että siinä käytetään samankaltaisia käsitteitä. EJB-tekniikkaa ei säännellä JavaBeans-komponenttitiedot, mutta täysin erilaisella (ja massiivisella) Enterprise JavaBeans -määritys. (Katso lisätietoja tästä spesifikaatiosta Resursseista.) EJB Spec kutsuu EJB: n asiakas- / palvelinjärjestelmän eri pelaajat, kuvaa kuinka EJB toimii yhteistyössä asiakkaan ja olemassa olevien järjestelmien kanssa, kertoo EJB: n yhteensopivuuden CORBA: n kanssa ja määrittelee järjestelmän eri komponenttien vastuut.
Enterprise JavaBeans -tavoitteet
EJB Spec yrittää saavuttaa useita tavoitteita kerralla:
EJB on suunniteltu helpottamaan kehittäjien sovellusten luomista vapauttamalla heidät järjestelmän matalista yksityiskohdista tapahtumien, ketjujen, kuormituksen tasapainottamisen ja niin edelleen. Sovelluskehittäjät voivat keskittyä liiketoimintalogiikkaan ja jättää tietojenkäsittelyn hallinnan yksityiskohdat kehykselle. Erikoissovelluksissa on kuitenkin aina mahdollista päästä "konepellin alle" ja mukauttaa näitä alemman tason palveluita.
EJB Spec määrittelee EJB-kehyksen päärakenteet ja sitten niiden väliset sopimukset. Asiakkaan, palvelimen ja yksittäisten komponenttien vastuut on määritelty selkeästi. (Käymme hetkessä läpi, mitä nämä rakenteet ovat.) Enterprise JavaBean -komponentin luomisella kehittäjällä on hyvin erilainen rooli kuin EJB-yhteensopivan palvelimen luojalla, ja määrittely kuvaa kunkin vastuun.
EJB pyrkii olemaan tavanomainen tapa asiakas- / palvelinsovellusten rakentamiseen Java-kielellä. Aivan kuten eri toimittajien alkuperäiset JavaBeans (tai Delphi-komponentit tai mitä tahansa) voidaan yhdistää mukautetun asiakkaan tuottamiseksi, eri toimittajien EJB-palvelimen komponentit voidaan yhdistää mukautetun palvelimen tuottamiseksi. EJB-komponentit, jotka ovat Java-luokkia, suoritetaan tietysti missä tahansa EJB-yhteensopivassa palvelimessa ilman uudelleenkääntämistä. Tämä on etu, jota alustakohtaiset ratkaisut eivät voi toivoa tarjoavansa.
- Lopuksi EJB on yhteensopiva muiden Java-sovellusliittymien kanssa ja käyttää niitä, voi toimia yhdessä muiden kuin Java-sovellusten kanssa ja yhteensopiva CORBA: n kanssa.
Kuinka EJB-asiakas- / palvelinjärjestelmä toimii
Ymmärtääksemme, kuinka EJB-asiakas- / palvelinjärjestelmä toimii, meidän on ymmärrettävä EJB-järjestelmän perusosat: EJB-komponentti, EJB-säilö ja EJB-objekti.
Enterprise JavaBeans -komponentti
Enterprise JavaBean on komponentti, aivan kuten perinteinen JavaBean. Enterprise JavaBeans suorittaa EJB-kontti, joka puolestaan suorittaa EJB-palvelin. Mikä tahansa palvelin, joka voi isännöidä EJB-säilöä ja tarjota sille tarvittavat palvelut, voi olla EJB-palvelin. (Tämä tarkoittaa, että monet olemassa olevat palvelimet voidaan laajentaa EJB-palvelimiksi, ja itse asiassa monet toimittajat ovat saavuttaneet tämän tai ilmoittaneet aikomuksestaan tehdä niin.)
EJB-komponentti on EJB-luokan tyyppi, jota todennäköisesti pidetään "Enterprise JavaBean -laitteena". Se on Java-luokka, jonka on kirjoittanut EJB-kehittäjä ja joka toteuttaa liiketoimintalogiikkaa. Kaikki muut EJB-järjestelmän luokat joko tukevat asiakkaan pääsyä EJB-komponenttiluokkiin tai tarjoavat palveluja (kuten pysyvyys jne.).
Enterprise JavaBeans -säilö
EJB-komponentti "asuu" EJB-säiliössä. EJB-säilö tarjoaa palveluja, kuten tapahtumien ja resurssien hallintaa, versiointia, skaalautuvuutta, liikkuvuutta, pysyvyyttä ja suojausta sen sisältämille EJB-komponenteille. Koska EJB-kontti hoitaa kaikki nämä toiminnot, EJB-komponenttien kehittäjä voi keskittyä liiketoimintasääntöihin ja jättää tietokannan käsittelyn ja muut vastaavat yksityiskohdat kontille. Esimerkiksi, jos yksi EJB-komponentti päättää, että nykyinen tapahtuma on keskeytettävä, se yksinkertaisesti kertoo sen säilölle (tavalla, jonka EJB Spec, ja kontti on vastuussa kaikkien palautusten suorittamisesta tai tekemästä tarvittavat toimet keskeneräisen tapahtuman peruuttamiseksi. Useita EJB-komponenttimerkkejä esiintyy tyypillisesti yhden EJB-säiliön sisällä.
EJB-objekti ja etärajapinta
Asiakasohjelmat suorittavat etäisen EJB: n menetelmät EJB-objekti. EJB-objekti toteuttaa EJB-komponentin "etärajapinnan" palvelimella. Etärajapinta edustaa EJB-komponentin "liiketoimintamenetelmiä". Etäkäyttöliittymä tekee EJB-objektin todellisen, hyödyllisen työn, kuten tilauslomakkeen luomisen tai potilaan siirtämisen asiantuntijalle. Keskustelemme etäkäyttöliittymästä tarkemmin alla.
