Vývoj distribuovaných systémov rýchlo rastie, pretože vývojári softvéru vytvárajú systémy, ktoré musia držať krok s neustále sa zvyšujúcimi požiadavkami kladenými na elektronické obchodovanie. Ale nikdy predtým nebol návrh a implementácia vrstvy na spracovanie správ v distribuovanom systéme také zložité ako dnes. Je to väčšinou z dôvodu dramatického nárastu potenciálnej funkčnosti, ktorý umožňujú štandardy ako Java Message Service (JMS), ktoré spájajú technológie mnohých dodávateľov do jedného systému. Šírenie internetu navyše vyvolalo vznik nových, rozsiahlych užívateľských základní a sprístupnilo niekoľko protokolov pre komunikáciu v distribuovanom systéme. Takéto protokoly zahŕňajú CORBA IIOP (internetový protokol Inter-ORB), Microsoft DCOM (distribuovaný objektový model komponentov) a Java RMI (vzdialená metóda vyvolávania).
Prirodzený vývoj týchto protokolov viedol k zavedeniu middlewaru orientovaného na správy (MOM), ktorý umožňuje voľnejšie spojenie v distribuovaných systémoch abstrahovaním od prekladov, zabezpečenia a základných komunikačných protokolov od klientov a serverov. Medzi middlewarové riešenia patria SOAP (Simple Object Access Protocol) a JMS. Proprietárne spracovanie transakcií na strednej vrstve existuje už od počiatku COBOLu (Common Business Oriented Language), ale nebolo to príliš zložité z dôvodu obmedzení technológií skorých správ.
S príchodom štandardov, ako je JMS, môžu vývojári teraz spájať množstvo technológií. Rozhodnutia o návrhu distribuovaného systému sú ťažšie a ich dopad na integritu a distribúciu údajov je zásadný pre úspech alebo zlyhanie systému.
Všadeprítomný a tichý predpoklad je, že zavedenie technológie je aktívom, zatiaľ čo jej záväzky sú často ignorované. Neúčtovanie záväzkov často vedie k systému, ktorý je buď zbytočne komplikovaný a / alebo nadmerne prepracovaný. Základné pochopenie JMS a jeho inherentných kvalít (vlastnosti nezávislé na systéme), po ktorých nasleduje starostlivá analýza vo vzťahu k konkrétnym scenárom distribuovaného systému, môže naznačiť, ako dobre môže JMS vyriešiť systémové požiadavky oproti zmene existujúcich problémov alebo dokonca zavedeniu nových.
Prehľad JMS
JMS, predstavený spoločnosťou Sun Microsystems v roku 1999 ako súčasť špecifikácie Java 2 Platform, Enterprise Edition (J2EE), je súbor štandardov, ktoré popisujú základy vrstvy middlewaru na spracovanie správ. JMS umožňuje systémom komunikovať synchrónne alebo asynchrónne prostredníctvom modelov typu point-to-point aj publish-subscribe. Dnes niekoľko dodávateľov poskytuje implementácie JMS, ako sú BEA Systems, Hewlett-Packard, IBM, Macromedia a Oracle, čo umožňuje spoločnosti JMS komunikovať s rôznymi technológiami dodávateľov.
Obrázok 1 zobrazuje jednoduchý systém založený na JMS s odchádzajúcou frontou naplnenou správami pre klientov na spracovanie a prichádzajúcou frontou, ktorá zhromažďuje výsledky spracovania klienta na vloženie do databázy.
Ako už bolo spomenuté vyššie, MOM (ako JMS) umožňuje voľnejšie spojenie v distribuovaných systémoch abstrahovaním od prekladov, bezpečnosti a základných komunikačných protokolov od klientov a serverov. Jedným z hlavných prostriedkov vrstvy na spracovanie správ je to, že pretože zavádza túto abstrakčnú vrstvu, implementácia buď klienta, alebo servera sa môže niekedy radikálne zmeniť bez toho, aby to ovplyvnilo ďalšie súčasti systému.
Dva konkrétne scenáre
V tejto časti uvádzam dva distribuované systémy, ktoré sú potenciálnymi kandidátmi na JMS, a vysvetľujem ciele každého systému a prečo sú tieto systémy kandidátmi na JMS.
Scenár 1
Prvým kandidátom je systém distribuovaného kódovania (zobrazený na obrázku 2). Tento systém má súbor N klienti, ktorí načítajú úlohy kódovania z centrálneho databázového servera. Klienti potom vykonajú skutočnú transformáciu (kódovanie) z digitálneho predlohy na kódované súbory a skončia hlásením svojho stavu po spracovaní (napr. Úspech / neúspech) späť na centrálny databázový server.
Typy kódovania (napr. Text, zvuk alebo video) alebo transformácie (napr. .pdf do .xml, .wav do .mp3, .avi do .qt) nezáleží. Je dôležité si uvedomiť, že kódovanie je náročné na CPU a vyžaduje si distribuované spracovanie medzi viacerých klientov.
Na prvý pohľad je tento systém potenciálnym kandidátom na JMS, pretože:
- Spracovanie musí byť distribuované, pretože je mimoriadne náročné na procesor (CPU)
- Môže byť problematické z hľadiska výkonu systému pripojiť viac klientov priamo k jednému databázovému serveru
Scenár 2
Druhým kandidátskym systémom JMS je globálny registračný systém pre internetový portál. Globálna registrácia vybavuje žiadosti o vytvorenie nového používateľa (registráciu), prihlásenie a autentizáciu.
Konkrétne registračné informácie (napr. Meno, adresa, obľúbená farba) a metódy autentifikácie používateľa (napr. Objekty používateľa na strane servera, súbory cookie HTTP) nie sú dôležité. Je však dôležité, aby tento systém umožňoval zvládnuť milióny používateľov, a je ťažké, ak nie nemožné, predvídať vzorce používania. (Počas televízneho zápasu na majstrovstvách sveta ESPN vyhlasovateľ hovorí: „Prihláste sa a hlasujte v našej online ankete. Výsledky predstavíme na konci predstavenia.“ Zrazu sa do troch minút prihlási 500 000 používateľov. interval 3 minúty = 180 sekúnd; 500 000 prihlásení používateľov / 180 sekúnd = 2 778 prihlásení používateľov / s.)
Tento systém je potenciálnym kandidátom na JMS z nasledujúcich dôvodov:
- Systém musí byť distribuovaný kvôli zmenšeniu objemu transakcie
- Transakcie sú atómové (napr. Prihlasovacie údaje), takže sú bez štátnej príslušnosti, a preto sú kandidátmi na distribúciu
Tieto dva systémy sú si navzájom architektonicky podobné. Niekoľko klientskych počítačov extrahuje údaje z centrálneho databázového servera (možno replikované na server) M iba na čítanie databázových serverov), vykonajte na klientovi určitú logiku a potom nahlasuj stav späť na centrálny databázový server. Jeden systém dodáva kódované súbory do súborového systému cez UNC / FTP; druhá dodáva obsah HTML do webových prehľadávačov cez HTTP. Oba systémy sú distribuované.
To je toľko, koľko inžinierov ide so svojimi analýzami pred aplikáciou JMS. Vo zvyšku tohto článku vysvetľujem, že hoci tieto systémy zdieľajú mnoho charakteristík, vhodnosť JMS sa stáva zreteľnejšou a rozdielnejšou, keď preskúmame požiadavky každého systému vrátane výkonu systému, distribúcie údajov a škálovateľnosti.
Analýza systému: Integrovať alebo neintegrovať
JMS má prirodzené vlastnosti nezávislé od systému. Niektoré z týchto kvalít (klady označené +, zápory označené -), ktoré sa vzťahujú na oba systémy, zahŕňajú:
- (+) JMS je sada štandardov vytvorených implementáciami viacerých dodávateľov; preto sa obávate zámok dodávateľa problém.
- (+) JMS umožňuje abstrakciu (cez všeobecné API) medzi klientom a serverom; databázovú schému alebo platformu môžete zmeniť bez zmeny aplikačnej vrstvy (implicitné sú tu ďalšie potenciálne zmeny systému, ktoré sú od seba izolované vrstvou správ).
- (+)/(-) JMS môže pomôcť systémovej škále (pro). Protikladom je, že každý systém, ktorý sa škáľuje pomocou JMS, môže škálovať aj bez neho.
- (-) JMS je komplikovaný. Je to úplne nová vrstva s novou sadou serverov. Správa zavedenia softvéru, monitorovanie servera a zabezpečenie sú len niektoré z netriviálnych problémov spojených s zavedením JMS. Mali by sa zvážiť aj náklady.
- (-) Predajcovia nie vždy tlmočia, a preto implementujú normy presne rovnakým spôsobom, takže existujú rozdiely medzi rôznymi implementáciami.
- (-) S JMS potrebujete viac systémových kontrol a vyvážení. Zavediete nielen novú vrstvu, ale aj asynchrónnu distribúciu údajov a potvrdenie, ktoré má asynchrónnu notifikáciu ešte zložitejšiu.
- (-) Žiadne fronty na hlásenie, aktualizáciu a monitorovanie správ bez vlastného softvéru.
JMS má tiež vlastnosti závislé od systému. Vhodnosť JMS závisí od toho, ako dobre tieto vlastnosti mapujú problémovú skupinu, ktorú sa snažíte vyriešiť. Nasledujú niektoré z týchto vlastností a ich vzťah k dvom záujmovým systémom:
Ukladanie do vyrovnávacej pamäte
Ukladanie do pamäte cache je primárnym hľadiskom pri plánovaní kapacity v akomkoľvek distribuovanom systéme. JMS má mnoho funkcií, ktoré umožňujú jeho použitie ako technológie ukladania do pamäte cache (hlavne to, že je distribuovaný, synchrónny alebo asynchrónny a výmeny dát ako objekty v správach). Preto je možné v prípade potreby využiť existujúcu inštaláciu JMS ako infraštruktúru ukladania do vyrovnávacej pamäte.
Pri uvažovaní o kódovacom systéme nie je ukladanie do pamäte cache všeobecne užitočné na zvýšenie celkového výkonu systému, pretože väčšina transformácií súborov sa vykoná raz a presunie sa do hostiteľského zariadenia alebo do siete SAN (storage area network). obsah sa prekrýva medzi zákazníkmi. Globálna registrácia je hlavným kandidátom na medzipamäť informácií o používateľoch, pretože používatelia sa zvyčajne prihlasujú, prehľadávajú a potom sa odhlásia. Prihlásenie vytvorí položku cache používateľa a tento objekt poskytuje následnú autentifikáciu užívateľa, keď je užívateľ na webe.
Objednávka na spracovanie
V rámci globálneho registračného systému neexistuje žiadne plánovanie a / alebo objednávka na spracovanie transakcie. Pseudonáhodní používatelia vstupujú do systému v pseudonáhodných intervaloch po prihlásení, prezerajú obsah (a preto sú autentifikovaní, keď pristupujú k obmedzenému obsahu alebo k aplikáciám) a potom sa odhlásia.
V rámci kódovacieho systému je objednané spracovanie. Obsah sa doručí do skupín na doručenie v závislosti od dostupnosti vymeniteľného úložiska (napr. DLT Solutions alebo úložisko Network Appliance). Obsah sa doručí až po dokončení dávky, takže dávky sa musia spúšťať v uvedenom poradí (aj keď transformácie v dávke môžu byť potenciálne nezoradené). Implementácia prioritných frontov v rámci JMS na zachovanie poradia spracovania je možná, ale udržanie tohto poradia dávkových správ medzi viacerými servermi JMS a viacerými frontami sa stáva dosť komplikovaným. Pre správu tohto pracovného toku je vhodnejšou technológiou server s relačnou databázou s podporou transakcií.
Bezpečnosť
Zabezpečenie nie je súčasťou špecifikácie JMS. Bezpečnostný problém sa nemusí nevyhnutne meniť pri implementácii založenej na JMS (ak máte požiadavku na bezpečnosť pred JMS, budete mať podobnú požiadavku na bezpečnosť po JMS). S týmto vedomím je dôležité pochopiť, ako môže mať JMS vzťah k súčasnej bezpečnosti infraštruktúry.
Všeobecne platí, že čím viac technológií použijete, tým zraniteľnejší bude váš systém voči hackerom a porušeniam bezpečnosti. Pretože globálny registračný aplikačný server je orientovaný na web, bezpečnostné chyby zistené v implementácii JMS vašich dodávateľov a zverejnené v internetových diskusných skupinách sa rýchlo stávajú bezpečnostnými záväzkami pre vaše stránky. Pretože JMS je všeobecné API, je tiež náchylnejšie na narušenie bezpečnosti ako proprietárny systém, ktorý používa nepublikované API.
Aj keď môžete svoju existujúcu bránu firewall a sieťové zabezpečenie založené na protokole IP využiť na ochranu svojich aplikačných a databázových serverov typu back-end (čítať: nie je to určené pre web - určené pre slovné hračky), existuje značné bezpečnostné riziko vystavením aplikačných serverov JMS. priamo na internet.
Systém kódovania všeobecne existuje v tej istej sieti (tiež v sieti izolovanej od Internetu). Takže v topografii tohto systému nie je nič, čo by sa týkalo JMS, a využitie tejto topografie na zabezpečenie bezpečnosti (pre kódovací systém existuje oveľa menej bezpečnostných požiadaviek, pretože to nie je orientované na web).
Škálovateľnosť
Pretože globálny registračný systém podlieha rozmarom veľkej a neuveriteľne klikajúcej užívateľskej základne, požiadavky na škálovateľnosť systému sú zárukou JMS. JMS pomôže nielen zväčšiť systém, ale aj zaradiť transakcie do frontu, aj keď to nebude príliš užitočné, keď systém zaplaví požiadavky používateľov.
Pretože distribuovaný systém kódovania starostlivo reguluje prenos údajov (pretože sa jedná o pravdepodobne samostatný systém), požiadavky na škálovateľnosť systému nie sú také hrozné. Pre distribuované kódovanie môžete pripojiť svoje O [100] klientov priamo do vašej databázy a obmedziť ich prenos, aby vyvážili priepustnosť kódovania s výkonom databázového servera.
Výkon
Zavedenie jediného servera JMS môže skôr zmeniť problémy s výkonom, ako ich vyriešiť. Z tohto dôvodu by mal byť systém JMS navrhnutý s viacerými servermi JMS (a teda s viacerými radmi). Obrázok 4 ukazuje, prečo sa problémy s výkonom namiesto riešenia menia. Ilustruje vrstvy spracovania potrebné na to, aby generický dátový server odpovedal na požiadavky na pripojenie klienta:
Výmena údajov medzi klientom a serverom je dvojdielny proces, či už ide o server typu klient-databáza alebo server typu klient-JMS:
- Prístup k údajom
- Správa vlákien a soketov, združovanie a ukladanie do pamäte cache
JMS a databázový server vyzerajú úplne rovnako (obrázok 4). Riešia pripojenia soketov, správu vlákien a prístup k údajom na serveri.
Iba s jedným serverom JMS môžu potenciálne problémy s výkonom jednoducho dochádzať z databázového servera na server JMS. Okrem možného zníženia výkonu spojeného s prepínaním kontextu vo vašom databázovom serveri sú teraz problémy s výkonom potenciálne väčšie kvôli problémom s výkonom JVM vo vašom serveri JMS.
Jeden server JMS dodáva vášmu systému značnú zložitosť a môže tiež spôsobiť problémy s výkonom spojené s pripojením viacerých klientov k jedinému serveru. Dopad viacerých serverov JMS na dizajn vášho systému a tok údajov môže znamenať rozdiel medzi úspešným alebo neúspešným zavedením systému.
Stručne povedané, funkcie verzus potenciálny vplyv JMS vyzerajú takto:
Funkcie verzus vplyv JMS
