Pitäisikö sinun mennä JMS: n kanssa?

Hajautettu järjestelmäkehitys kasvaa nopeasti, kun ohjelmistokehittäjät rakentavat järjestelmiä, joiden on pysyttävä sähköisen liiketoiminnan jatkuvasti kasvavien vaatimusten mukaisina. Mutta koskaan ennen sanomankäsittelykerroksen suunnittelu ja toteutus hajautetussa järjestelmässä ei ole ollut yhtä monimutkaista kuin nykyään. Tämä johtuu lähinnä mahdollisten toimintojen dramaattisesta lisääntymisestä, jonka mahdollistavat standardit, kuten Java Message Service (JMS), jotka yhdistävät monien toimittajien tekniikat yhteen järjestelmään. Lisäksi Internetin lisääntyminen on synnyttänyt uusia, laaja-alaisia ​​käyttäjäkuntia, ja se on tarjonnut useita protokolleja viestintään hajautetussa järjestelmässä. Tällaisia ​​protokollia ovat CORBA IIOP (Internetin välinen ORB-protokolla), Microsoft DCOM (hajautettu komponenttimallimalli) ja Java RMI (etämenetelmän kutsuminen).

Näiden protokollien luonnollinen kehitys on johtanut viestisuuntautuneen väliohjelmiston (MOM) käyttöönottoon, mikä mahdollistaa löyhemmän kytkemisen hajautettuihin järjestelmiin abstraktoimalla käännös, tietoturva ja taustalla olevat yhteyskäytännöt asiakkailta ja palvelimilta. Väliohjelmistoihin kuuluvat SOAP (Simple Object Access Protocol) ja JMS. Oma, keskikerroksinen tapahtumakäsittely on ollut olemassa COBOLin (Common Business Oriented Language) alkuaikoista lähtien, mutta se ei ollut kovin monimutkaista johtuen varhaisen viestintätekniikan rajoituksista.

JMS: n kaltaisten standardien myötä kehittäjät voivat nyt yhdistää useita tekniikoita. Hajautetun järjestelmän suunnittelupäätökset ovat vaikeampia, ja niiden vaikutukset tietojen eheyteen ja jakeluun ovat kriittisiä järjestelmän onnistumisen tai epäonnistumisen kannalta.

Yleinen ja hiljainen oletus on, että tekniikan käyttöönotto on voimavara, kun taas sen vastuut jätetään usein huomiotta. Velkojen huomioon ottamatta jättäminen johtaa usein järjestelmään, joka on joko tarpeettoman monimutkainen ja / tai ylisuunniteltu. Perustiedot JMS: stä ja sen luontaisista ominaisuuksista (järjestelmästä riippumattomat ominaisuudet), jota seuraa huolellinen analyysi suhteessa tiettyihin hajautetun järjestelmän skenaarioihin, voivat osoittaa, kuinka hyvin JMS voi ratkaista järjestelmävaatimukset joko muuttamalla olemassa olevia ongelmia tai jopa tuomalla uusia.

JMS-yleiskatsaus

JMS, jonka Sun Microsystems esitteli vuonna 1999 osana Java 2 Platform, Enterprise Edition (J2EE) -määritystä, on joukko standardeja, jotka kuvaavat viestien käsittelyn väliohjelmistokerroksen perustan. JMS antaa järjestelmien kommunikoida synkronisesti tai asynkronisesti sekä pisteestä pisteeseen että julkaisu-tilaus -mallien kautta. Nykyään useat toimittajat tarjoavat JMS-toteutuksia, kuten BEA Systems, Hewlett-Packard, IBM, Macromedia ja Oracle, jolloin JMS voi olla vuorovaikutuksessa useiden toimittajien tekniikoiden kanssa.

Kuvassa 1 on esitetty yksinkertainen JMS-pohjainen järjestelmä, jossa lähtevä jono on täynnä asiakkaan käsiteltäviä viestejä, ja saapuva jono, joka kerää asiakkaan käsittelytulokset tietokantaan lisäämistä varten.

Kuten edellä mainittiin, MOM (kuten JMS) sallii löyhemmän kytkennän hajautetuissa järjestelmissä abstraktoimalla käännökset, tietoturvan ja taustalla olevat yhteyskäytännöt asiakkailta ja palvelimilta. Yksi viestinkäsittelykerroksen pääominaisuuksista on, että koska se tuo tämän abstraktikerroksen käyttöön, joko asiakkaan tai palvelimen toteutus voi muuttua, joskus radikaalisti, vaikuttamatta muihin järjestelmän komponentteihin.

Kaksi erityistä skenaariota

Tässä osassa esitän kaksi hajautettua järjestelmää, jotka ovat mahdollisia JMS-ehdokkaita, ja selitän kunkin järjestelmän tavoitteet ja miksi järjestelmät ovat JMS-ehdokkaita.

Skenaario 1

Ensimmäinen ehdokas on hajautettu koodausjärjestelmä (esitetty kuvassa 2). Tässä järjestelmässä on joukko N asiakkaat, jotka hakevat koodaustöitä keskitetystä tietokantapalvelimesta. Asiakkaat suorittavat sitten varsinaisen muunnoksen (koodauksen) digitaalisesta masterista koodatuiksi tiedostoiksi ja lopettavat ilmoittamalla jälkikäsittelyn tilansa (esim. Onnistuminen / epäonnistuminen) takaisin keskustietokantapalvelimelle.

Koodaustyypit (esim. Teksti, ääni tai video) tai muunnokset (esim. .pdf että .xml, .wav että .mp3, .avi että .qt) ei ole väliä. On tärkeää ymmärtää, että koodaus on CPU-intensiivistä ja skaalautuminen vaatii hajautettua käsittelyä useiden asiakkaiden kesken.

Yhdellä silmäyksellä tämä järjestelmä on potentiaalinen JMS-ehdokas, koska:

• Prosessointi on jaettava, koska se on erittäin prosessorinintensiivistä
• Järjestelmän suorituskyvyn kannalta voi olla ongelmallista yhdistää useita asiakkaita suoraan yhteen tietokantapalvelimeen

Skenaario 2

Toinen JMS-ehdokasjärjestelmä on Internet-portaalin maailmanlaajuinen rekisteröintijärjestelmä. Yleinen rekisteröinti käsittelee uuden käyttäjän luomista (rekisteröintiä), kirjautumista ja todennusta koskevat pyynnöt.

Erityiset rekisteröintitiedot (esim. Nimi, osoite, suosikkiväri) ja käyttäjän todennustavat (esim. Palvelinpuolen käyttäjäobjektit, HTTP-evästeet) eivät ole tärkeitä. On kuitenkin tärkeää, että tämä järjestelmämittakaava käsittelee miljoonia käyttäjiä, ja käyttötapoja on vaikea, ellei mahdotonta ennustaa. (Televisioidun ESPN World Cup -pelin aikana ilmoittaja sanoo: "Kirjaudu sisään ja äänestä online-kyselyssä. Esittelemme tulokset esityksen lopussa." Yhtäkkiä 500 000 käyttäjää kirjautuu sisään kolmen minuutin kuluessa. 3 minuuttia = 180 sekuntia; 500 000 käyttäjätunnusta / 180 sekuntia = 2778 käyttäjätunnusta / s.)

Tämä järjestelmä on potentiaalinen JMS-ehdokas seuraavista syistä:

• Järjestelmä on jaettava tapahtumamäärän skaalaamiseksi
• Tapahtumat ovat atomisia (esim. Sisäänkirjautuminen), joten ne ovat valtiottomia ja siksi ehdokkaita jakelulle

Nämä kaksi järjestelmää ovat arkkitehtonisesti samanlaisia. Useat asiakaskoneet poimivat tietoja keskitetystä tietokantapalvelimesta (mahdollisesti kopioidaan osoitteeseen M vain luku -tietokantapalvelimet), suorita jonkinlainen logiikka asiakkaassa ja raportoi sitten tila takaisin tietokannan keskuspalvelimelle. Yksi järjestelmä toimittaa koodatut tiedostot tiedostojärjestelmään UNC / FTP: n kautta; toinen toimittaa HTML-sisältöä verkkoselaimille HTTP: n kautta. Molemmat järjestelmät ovat hajautettuja.

Tämä on niin monta insinööriä, jotka suorittavat analyysinsa ennen JMS: n soveltamista. Tämän artikkelin loppuosassa selitän, että vaikka näillä järjestelmillä on monia ominaisuuksia, JMS: n tarkoituksenmukaisuus tulee selkeämmäksi ja erilaisemmaksi tutkittaessa kunkin järjestelmän vaatimuksia, mukaan lukien järjestelmän suorituskyky, tietojen jakelu ja skaalautuvuus.

Järjestelmäanalyysi: Integroida tai ei integroida

JMS: llä on luonnostaan ​​riippumattomia ominaisuuksia. Jotkut näistä ominaisuuksista (plusmerkit, joita merkitään +, miinukset merkitään -), jotka koskevat molempia järjestelmiä, ovat:

• (+) JMS on joukko standardeja, jotka ovat luoneet useat toimittajan toteutukset; siksi vältät pelättyä toimittajan lukitus ongelma.
• (+) JMS mahdollistaa abstraktion (yleisen API: n kautta) asiakkaan ja palvelimen välillä; voit muuttaa tietokantamallia tai -alustaa muuttamatta sovelluskerrosta (implisiittisiä tässä on muita potentiaalisia järjestelmämuutoksia, jotka viestikerros eristää toisistaan).
• (+)/(-) JMS voi auttaa järjestelmän mittakaavassa (ammattilainen). Haittapuolena on, että mikä tahansa JMS-järjestelmällä skaalautuva järjestelmä voi skaalata ilman sitä.
• (-) JMS on monimutkainen. Se on täysin uusi kerros, jossa on uudet palvelimet. Ohjelmiston käyttöönoton hallinta, palvelinten valvonta ja tietoturva ovat vain muutamia ei-triviaalisista ongelmista, jotka liittyvät JMS-käyttöönottoon. Myös kustannukset tulisi ottaa huomioon.
• (-) Toimittajat eivät aina tulkitse standardeja tarkalleen samalla tavalla, joten erilaisten toteutusten välillä on eroja.
• (-) JMS: n avulla tarvitset lisää järjestelmän tarkistuksia ja saldoja. Et vain esitä uutta tasoa, otat myös käyttöön asynkronisen datan jakelun ja kuittauksen, mikä lisää asynkronisen ilmoituksen monimutkaisuutta.
• (-) Ei viestejä raportointi / päivitys / seuranta jonoja ilman mukautettua ohjelmistoa.

JMS: llä on myös järjestelmästä riippuvia ominaisuuksia. JMS: n tarkoituksenmukaisuus riippuu siitä, kuinka hyvin nämä ominaisuudet yhdistyvät ongelmasarjaan, jonka yrität ratkaista. Jotkut näistä ominaisuuksista ja miten ne liittyvät kahteen kiinnostavaan järjestelmään, seuraavat:

Välimuisti

Välimuisti on ensisijainen näkökohta kapasiteetin suunnittelussa missä tahansa hajautetussa järjestelmässä. JMS: llä on monia ominaisuuksia, jotka mahdollistavat sen käytön välimuistitekniikkana (lähinnä se, että se on hajautettu, synkroninen tai asynkroninen ja tiedonsiirto objekteina viesteissä). Siksi olemassa olevaa JMS-asennusta voidaan tarvittaessa käyttää välimuistin infrastruktuurina.

Koodausjärjestelmää tarkasteltaessa välimuistiin tallentaminen ei yleensä ole hyödyllistä järjestelmän yleisen suorituskyvyn parantamiseksi, koska useimmat tiedostomuunnokset suoritetaan kerran ja siirtyvät isännöintipalveluun tai SAN-verkkoon (varastointiverkko), ja siellä on vähän sisällön päällekkäisyys asiakkaiden välillä. Yleinen rekisteröinti on ensisijainen ehdokas käyttäjätietojen välimuistiin, koska käyttäjät yleensä kirjautuvat sisään, selaavat ja kirjautuvat sitten ulos. Sisäänkirjautuminen luo käyttäjän välimuistimerkinnän, ja tämä objekti antaa myöhemmän käyttäjän todennuksen käyttäjän ollessa sivustolla.

Käsitellään tilausta

Globaalissa rekisteröintijärjestelmässä ei ole aikataulutusta ja / tai tilausta tapahtumien käsittelyyn. Pseudosatunnaiset käyttäjät tulevat järjestelmään pseudo-satunnaisin väliajoin sisäänkirjautumisen yhteydessä, selaavat sisältöä (ja siksi todennetaan, kun he pääsevät rajoitettuun sisältöön ja / tai sovelluksiin) ja kirjautuvat sitten ulos.

Koodausjärjestelmässä käsittely tilataan. Sisältö erissä ryhmiin toimitettavaksi riippuen siirrettävän tallennustilan saatavuudesta (esim. DLT Solutions tai Network Appliance -tallennustila). Sisältöä ei toimiteta ennen kuin erä on valmis, joten erät on suoritettava järjestyksessä (vaikka erän sisällä olevat muunnokset voivat olla järjestämättömiä). Prioriteettijonojen toteuttaminen JMS: ssä käsittelyjärjestyksen säilyttämiseksi on mahdollista, mutta tämän viestierien järjestyksen ylläpitäminen useiden JMS-palvelinten ja useiden jonojen välillä tulee melko monimutkaiseksi. Relaatiotietokantapalvelin, joka tukee tapahtumia, on sopivampi tekniikka tämän työnkulun hallintaan.

Turvallisuus

Suojaus ei ole osa JMS-määritystä. Suojausongelmaa ei välttämättä muuteta JMS-pohjaisen toteutuksen yhteydessä (jos sinulla on ennen JMS: tä suojausvaatimus, sinulla on samanlainen turvallisuusvaatimus JMS: n jälkeen). Tämän tietäen on tärkeää ymmärtää, miten JMS voi liittyä olemassa olevaan infrastruktuurin turvallisuuteen.

Yleensä mitä enemmän tekniikkaa käytät, sitä haavoittuvampi järjestelmäsi on hakkereille ja tietoturvaloukkauksille. Koska maailmanlaajuinen rekisteröintisovelluspalvelin on verkkopohjainen, toimittajien JMS-toteutuksessa havaitut ja Internet-uutisryhmissä julkaistut tietoturvaongelmat muuttuvat nopeasti sivustosi turvallisuusvastuiksi. Koska JMS on yleinen sovellusliittymä, se on alttiimpi tietoturvaloukkauksille kuin oma järjestelmä, joka käyttää julkaisematonta sovellusliittymää.

Vaikka voit hyödyntää olemassa olevaa palomuuria ja IP-pohjaista verkkoturvaa suojataaksesi käyttöliittymän (lue: ei Web-suunnattu - pun tarkoitettu) ja tietokantapalvelimet suojausrikkomuksilta, JMS-sovelluspalvelimien paljastaminen aiheuttaa merkittävän tietoturvariskin. suoraan Internetiin.

Koodausjärjestelmä on yleensä olemassa samassa verkossa (myös Internetistä eristetty verkko). Joten, tämän järjestelmän verkon topografiassa ei ole mitään luontaista, joka liittyy JMS: ään ja tämän topografian hyödyntämiseen turvallisuuden tarjoamiseksi (koodausjärjestelmälle on paljon vähemmän turvallisuusvaatimuksia, koska se ei ole verkkoon päin).

Skaalautuvuus

Koska maailmanlaajuinen rekisteröintijärjestelmä on suuren ja kapriisisti napsauttavan käyttäjäkannan mielihyvän alainen, järjestelmän skaalautuvuusvaatimukset oikeuttavat JMS: n. JMS ei vain auta järjestelmän mittakaavassa, vaan myös jonottaa tapahtumat, vaikka siitä ei ole paljon apua, kun käyttäjän pyynnöt tulvivat järjestelmää.

Koska hajautettu koodausjärjestelmä on säännellyt huolellisesti dataliikennettä (koska se on oletettavasti itsenäinen järjestelmä), järjestelmän skaalautuvuusvaatimukset eivät ole yhtä pelottavia. Hajautettua koodausta varten voit liittää O [100] asiakkaita suoraan tietokantaan ja kurista niiden liikennettä tasapainottamaan koodauksen läpimenoa tietokantapalvelimen suorituskyvyn kanssa.

Esitys

Yhden JMS-palvelimen käyttöönotto voi pikemminkin muuttaa suorituskykyongelmia kuin ratkaista niitä. Tästä syystä JMS-järjestelmä tulisi suunnitella useilla JMS-palvelimilla (ja siten useilla jonoilla). Kuva 4 osoittaa, miksi suorituskykyongelmia muutetaan ratkaisemisen sijaan. Se kuvaa prosessointikerrokset, joita yleinen tietopalvelin tarvitsee vastaamaan asiakasyhteyspyyntöihin:

Tiedonvaihto asiakkaan ja palvelimen välillä on kaksiosainen prosessi riippumatta siitä, onko kyseessä asiakas-tietokanta tai asiakas-JMS-palvelin:

1. Tietojen käyttö
2. Langan- ja pistorasioiden hallinta, yhdistäminen ja välimuisti

JMS ja tietokantapalvelin näyttävät täsmälleen samoilta (kuva 4). He hoitavat pistorasian yhteyksiä, ketjujen hallintaa ja pääsyä palvelimen tietoihin.

Vain yhdellä JMS-palvelimella mahdolliset suorituskykyongelmat kulkevat tietokantapalvelimelta JMS-palvelimeen. Tietokantapalvelimen kontekstinvaihtoon liittyvän mahdollisen suorituskyvyn heikkenemisen lisäksi suorituskykyongelmat ovat nyt mahdollisesti suurempia JVM-palvelimen JMM-suorituskykyongelmien vuoksi.

Yksi JMS-palvelin lisää huomattavasti monimutkaisuutta järjestelmääsi ja saattaa myös aiheuttaa suorituskykyongelmia, jotka liittyvät useiden asiakkaiden liittämiseen yhteen palvelimeen. Usean JMS-palvelimen vaikutus järjestelmän suunnitteluun ja tietovirtaan voi tarkoittaa eroa onnistuneen tai epäonnistuneen järjestelmän käyttöönoton välillä.

Yhteenvetona, ominaisuudet vs. mahdollinen JMS-vaikutus näyttävät tältä:

Ominaisuudet verrattuna JMS-vaikutuksiin