Razvoj porazdeljenega sistema hitro narašča, saj razvijalci programske opreme gradijo sisteme, ki morajo slediti vedno večjim zahtevam, ki jih nalaga e-poslovanje. Toda načrtovanje in izvedba sloja za obdelavo sporočil znotraj porazdeljenega sistema še nikoli ni bila tako zapletena kot danes. To je predvsem posledica dramatičnega povečanja potencialne funkcionalnosti, ki jo omogočajo standardi, kot je Java Message Service (JMS), ki povezujejo številne tehnologije ponudnikov v enem samem sistemu. Poleg tega je širjenje interneta povzročilo nove, obsežne uporabniške baze in na voljo več protokolov za komunikacijo znotraj porazdeljenega sistema. Takšni protokoli vključujejo CORBA IIOP (Internet Inter-ORB Protocol), Microsoft DCOM (Distributed Component Object Model) in Java RMI (Remote Method Invocation).
Naravni razvoj teh protokolov je privedel do uvedbe v sporočilo usmerjene vmesne programske opreme (MOM), ki omogoča bolj ohlapno povezovanje znotraj porazdeljenih sistemov z abstrahiranjem prevodov, varnosti in osnovnih komunikacijskih protokolov od odjemalcev in strežnikov. Med vmesne rešitve spadata SOAP (Simple Object Access Protocol) in JMS. Lastniška obdelava transakcij v srednjem sloju obstaja že v zgodnjih dneh COBOL (Common Business Oriented Language), vendar ni bila zelo zapletena zaradi omejitev tehnologij zgodnjega sporočanja.
S prihodom standardov, kot je JMS, lahko razvijalci zdaj povežejo številne tehnologije. Odločitve o načrtovanju distribuiranega sistema so težje in njihove posledice na celovitost in distribucijo podatkov so ključne za uspeh ali neuspeh sistema.
Vsesplošna in tiha predpostavka je, da je uvedba tehnologije sredstvo, medtem ko se njene obveznosti pogosto prezrejo. Neupoštevanje obveznosti pogosto povzroči sistem, ki je bodisi po nepotrebnem zapleten in / ali preveč zasnovan. Osnovno razumevanje sistema JMS in njegovih lastnih lastnosti (od sistema neodvisne lastnosti), ki mu sledi natančna analiza v zvezi s posebnimi scenariji porazdeljenega sistema, lahko pokaže, kako dobro lahko sistem upravljanja vsebin rešuje sistemske zahteve, ne glede na to, ali spreminja obstoječe težave ali celo uvaja nove.
Pregled JMS
JMS, ki ga je Sun Microsystems predstavil leta 1999 kot del specifikacije platforme Java 2, Enterprise Edition (J2EE), je niz standardov, ki opisujejo temelje za vmesno plast za obdelavo sporočil. JMS sistemom omogoča sinhrono ali asinhrono komunikacijo prek modelov od točke do točke in od objave do naročnine. Danes več ponudnikov ponuja izvedbe JMS, kot so BEA Systems, Hewlett-Packard, IBM, Macromedia in Oracle, s čimer JMS omogoča interakcijo z več dobaviteljskimi tehnologijami.
Na sliki 1 je prikazan preprost sistem, ki temelji na sistemu JMS, z odhodno čakalno vrsto, napolnjeno s sporočili, ki jih morajo stranke obdelati, in dohodno čakalno vrsto, ki zbira rezultate obdelave odjemalca za vstavljanje v bazo podatkov.
Kot smo že omenili, MOM (tako kot JMS) omogoča ohlapnejše povezovanje znotraj porazdeljenih sistemov tako, da odjemalce in strežnike odvzame prevod, varnost in osnovne komunikacijske protokole. Eno glavnih sredstev sloja za obdelavo sporočil je, da se lahko izvajanje odjemalca ali strežnika, ki uvede to plast abstrakcije, včasih korenito spremeni, ne da bi to vplivalo na druge sistemske komponente.
Dva posebna scenarija
V tem poglavju predstavljam dva porazdeljena sistema, ki sta potencialna kandidata za JMS, in pojasnjujem cilje vsakega sistema ter zakaj so sistemi kandidati za JMS.
Scenarij 1
Prvi kandidat je porazdeljeni sistem kodiranja (prikazan na sliki 2). Ta sistem ima nabor N odjemalci, ki pridobijo opravila kodiranja iz osrednjega strežnika baz podatkov. Nato odjemalci izvedejo dejansko preoblikovanje (kodiranje) iz digitalnega glavnega v kodirane datoteke in končajo s poročanjem o svojem stanju naknadne obdelave (npr. Uspeh / neuspeh) na osrednji strežnik baz podatkov.
Vrste kodiranja (npr. Besedilo, zvok ali video) ali transformacije (npr. .pdf do .xml, .wav do .mp3, .avi do .qt) ni pomembno. Pomembno je razumeti, da kodiranje zahteva CPU in zahteva porazdeljeno obdelavo med več odjemalci.
Na prvi pogled je ta sistem potencialni kandidat za JMS, ker:
- Obdelava mora biti porazdeljena, saj je zelo intenzivna (CPU)
- S stališča zmogljivosti sistema je lahko težavno povezati več odjemalcev neposredno z enim strežnikom baz podatkov
2. scenarij
Drugi sistem kandidatov za JMS je globalni sistem za registracijo internetnega portala. Globalna registracija obravnava zahteve za ustvarjanje novega uporabnika (registracijo), prijavo in preverjanje pristnosti.
Določeni podatki o registraciji (npr. Ime, naslov, najljubša barva) in načini preverjanja pristnosti uporabnika (npr. Uporabniški predmeti na strani strežnika, piškotki HTTP) niso pomembni. Vendar je pomembno, da ta sistem obsega milijone uporabnikov, vzorce uporabe pa je težko, če ne celo nemogoče napovedati. (Med televizijsko tekmo svetovnega pokala ESPN napovedovalec reče: "Prijavite se in glasujte v naši spletni anketi. Rezultate bomo predstavili na koncu oddaje." Kar naenkrat se 500.000 uporabnikov prijavi v treh minutah interval. 3 minute = 180 sekund; 500.000 prijav uporabnikov / 180 sekund = 2.778 prijav uporabnikov / sek.)
Ta sistem je potencialna kandidatka za JMS iz naslednjih razlogov:
- Sistem mora biti razdeljen za obseg transakcije
- Transakcije so atomske (npr. Prijava), zato so brez državljanstva in zato kandidati za distribucijo
Oba sistema sta si arhitekturno podobna. Več odjemalskih strojev izvleče podatke iz osrednjega strežnika baz podatkov (po možnosti razmnoži v M strežniki baz podatkov samo za branje), izvede nekaj logike na odjemalcu in nato stanje sporoči nazaj centralnemu strežniku baz podatkov. En sistem dostavi kodirane datoteke v datotečni sistem prek UNC / FTP; drugi dostavlja vsebino HTML spletnim brskalnikom prek HTTP. Oba sistema sta porazdeljena.
To je tisto, kar gre veliko inženirjev s svojimi analizami pred uporabo JMS. V nadaljevanju tega članka pojasnjujem, da kljub temu, da imajo ti sistemi številne značilnosti, ustreznost sistema JMS postane jasnejša in bolj raznolika, ko preučujemo zahteve vsakega sistema, vključno z zmogljivostjo sistema, distribucijo podatkov in razširljivostjo.
Analiza sistema: vključiti ali ne vključiti
JMS ima notranje lastnosti, neodvisne od sistema. Nekatere od teh lastnosti (prednosti, označene z +, kontra, označene z -), ki veljajo za oba sistema, vključujejo:
- (+) JMS je niz standardov, ki jih ustvarjajo izvedbe več ponudnikov; zato se izogibate strahu zaklepanje prodajalca problem.
- (+) JMS omogoča abstrakcijo (prek splošnega API-ja) med odjemalcem in strežnikom; shemo baze podatkov ali platformo lahko spremenite, ne da bi spremenili aplikacijski sloj (tu so implicitne druge možne sistemske spremembe, ki jih plast sporočil ločuje med seboj).
- (+)/(-) JMS lahko pomaga sistemski lestvici (pro). Pomanjkljivost je, da lahko kateri koli sistem, ki meri s sistemom JMS, meri brez njega.
- (-) JMS je zapleten. Gre za povsem novo plast z novim naborom strežnikov. Upravljanje uvajanja programske opreme, nadzor strežnika in varnost so le nekateri od nezanimivih težav, povezanih z uvajanjem JMS. Upoštevati je treba tudi stroške.
- (-) Dobavitelji ne razlagajo vedno in zato izvajajo standardov natančno na enak način, torej obstajajo razlike med različnimi izvedbami.
- (-) Z JMS potrebujete več sistemskih preverjanj in ravnotežij. Ne samo, da uvedete novo plast, temveč tudi asinhrono distribucijo in potrditev podatkov, ki ima še večjo zapletenost asinhronega obveščanja.
- (-) Brez programske opreme po meri ni poročil / posodobitev / spremljanja čakalnih vrst sporočil.
JMS ima tudi sistemsko odvisne lastnosti. Primernost sistema JMS je odvisna od tega, kako dobro se te lastnosti ujemajo z naborom težav, ki ga želite rešiti. Sledijo nekatere od teh lastnosti in njihov odnos do dveh sistemov zanimanja:
Predpomnjenje
Predpomnjenje je glavni vidik načrtovanja zmogljivosti v katerem koli distribuiranem sistemu. JMS ima številne funkcije, ki omogočajo njegovo uporabo kot tehnologijo predpomnjenja (predvsem ta, da je razdeljena, sinhrona ali asinhrona in izmenjava podatkov kot predmeti v sporočilih). Zato je mogoče obstoječo namestitev JMS uporabiti kot predpomnilniško infrastrukturo, če je to potrebno.
Pri razmisleku o sistemu kodiranja predpomnjenje na splošno ni koristno za povečanje splošne zmogljivosti sistema, saj se večina pretvorb datotek izvede enkrat in premakne v gostiteljski objekt ali SAN (omrežje za shranjevanje podatkov), malo pa je prekrivanje vsebine med kupci. Globalna registracija je glavni kandidat za predpomnilnik z informacijami o uporabniku, saj se uporabniki običajno prijavijo, brskajo in nato odjavijo. Prijava ustvari vnos uporabnikovega predpomnilnika, ta objekt pa zagotavlja nadaljnje preverjanje pristnosti uporabnika, medtem ko je uporabnik na spletnem mestu.
Naročilo za obdelavo
Znotraj globalnega registracijskega sistema ni načrtovanja in / ali naročila za obdelavo transakcij. Psevdonaključni uporabniki ob prijavi v sistem vstopijo v psevdonaključnih intervalih, brskajo po vsebini (in so zato preverjeni, ko dostopajo do omejene vsebine in / ali aplikacij) in se nato odjavijo.
V sistemu kodiranja je naročena obdelava. Vsebina se razdeli v skupine za dostavo, odvisno od razpoložljivosti odstranljivega pomnilnika (npr. DLT Solutions ali Network Appliance storage). Vsebina se ne dostavi, dokler paket ni končan, zato se morajo paketi izvajati po vrstnem redu (čeprav preoblikovanja znotraj paketa morda niso urejena). Izvajanje prioritetnih čakalnih vrst v sistemu JMS za ohranitev vrstnega reda obdelave je možno, vendar ohranjanje tega vrstnega reda paketov sporočil med več strežniki JMS in več čakalnimi vrstami postane precej zapleteno. Strežnik relacijske baze podatkov s podporo za transakcije je primernejša tehnologija za upravljanje tega poteka dela.
Varnost
Varnost ni del specifikacije JMS. Varnostne težave ni nujno spremeniti z implementacijo na osnovi JMS (če imate varnostno zahtevo pred JMS, boste imeli podobno varnostno zahtevo tudi po JMS). Če vemo to, je pomembno razumeti, kako se JMS lahko nanaša na obstoječo varnost infrastrukture.
Na splošno je več tehnologij, ki jih uporabljate, bolj ranljiv je vaš sistem za hekerje in varnostne kršitve. Ker je strežnik aplikacij za globalno registracijo usmerjen na splet, varnostne pomanjkljivosti, odkrite pri izvajanju JMS vašega ponudnika in objavljene v internetnih skupinah novic, hitro postanejo varnostne obveznosti za vaše spletno mesto. Ker je JMS generični API, je bolj nagnjen k kršitvam varnosti kot lastniški sistem, ki uporablja neobjavljeni API.
Medtem ko lahko obstoječi požarni zid in omrežno varnost, ki temelji na IP-ju, izkoristite za zaščito svojih varnostnih strežnikov aplikacij in strežnikov baz podatkov (ne brskajte do spleta) - obstaja veliko varnostno tveganje, ki ga povzroči izpostavljenost strežnikov aplikacij JMS neposredno na internet.
Šifrirni sistem običajno obstaja v istem omrežju (tudi omrežje, ločeno od interneta). Torej omrežna topografija tega sistema ni povezana z JMS in izkoriščanjem te topografije za zagotavljanje varnosti (za kodiranje sistema je veliko manj varnostnih zahtev, saj ni obrnjen proti spletu).
Razširljivost
Ker je sistem globalne registracije podvržen muham velike in muhasto uporabniške baze, zahteve sistema za razširljivost upravičujejo sistem JMS. JMS ne bo le pomagal prilagoditi sistema, temveč bo čakal transakcije v čakalni vrsti, čeprav ne bo veliko pomagal, ko bodo zahteve uporabnikov preplavile sistem.
Ker ima sistem porazdeljenega kodiranja natančno urejen podatkovni promet (saj gre verjetno za samostojni sistem), zahteve sistema glede razširljivosti niso tako strašne. Za porazdeljeno kodiranje lahko povežete svoj O [100] odjemalci neposredno v vašo bazo podatkov in omejite njihov promet, da uravnotežite pretok kodiranja z zmogljivostjo strežnika baz podatkov.
Izvedba
Uvedba enega samega strežnika JMS lahko težave z zmogljivostjo spremeni, namesto da bi jih rešila. Zaradi tega bi moral biti sistem JMS zasnovan z več strežniki JMS (in s tem več vrstic). Slika 4 prikazuje, zakaj se težave z zmogljivostjo spreminjajo, namesto da bi jih rešili. Ilustrira obdelavne plasti, potrebne za generični podatkovni strežnik, da se odzove na zahteve za povezavo odjemalca:
Izmenjava podatkov med odjemalcem in strežnikom je dvodelni postopek, ne glede na to, ali gre za strežnik odjemalca do baze podatkov ali odjemalca do JMS:
- Dostop do podatkov
- Upravljanje navojev in vtičnic, združevanje in predpomnjenje
JMS in strežnik baz podatkov izgledata popolnoma enako (slika 4). Omogočajo povezave vtičnic, upravljanje niti in dostop do podatkov strežnika.
Samo z enim strežnikom JMS potencialne težave z zmogljivostjo preprosto preusmerijo s strežnika baze podatkov na strežnik JMS. Poleg morebitne poslabšanja zmogljivosti, povezane s preklapljanjem konteksta znotraj strežnika baze podatkov, so težave z zmogljivostjo zdaj potencialno večje zaradi težav z zmogljivostjo JVM v strežniku JMS.
En strežnik JMS doda vašemu sistemu veliko zapletenost in lahko povzroči tudi težave z zmogljivostjo, povezane s povezavo več odjemalcev z enim strežnikom. Vpliv več strežnikov JMS na zasnovo vašega sistema in pretok podatkov lahko pomeni razliko med uspešnim ali neuspelim uvajanjem sistema.
Če povzamemo, funkcije glede na potencialni vpliv JMS izgledajo takole:
Funkcije v primerjavi z vplivom JMS
