Programování

Měli byste jít s JMS?

Vývoj distribuovaného systému rychle roste, protože vývojáři softwaru vytvářejí systémy, které musí držet krok s neustále se zvyšujícími požadavky kladenými elektronickým obchodem. Ale nikdy předtím nebyl design a implementace vrstvy pro zpracování zpráv v distribuovaném systému tak složité jako dnes. To je většinou způsobeno dramatickým nárůstem potenciální funkčnosti umožněné standardy, jako je Java Message Service (JMS), které spojují technologie mnoha prodejců v jednom systému. Šíření internetu navíc vyvolalo vznik nových, rozsáhlých uživatelských základen a zpřístupnilo několik protokolů pro komunikaci v distribuovaném systému. Mezi takové protokoly patří CORBA IIOP (Internet Inter-ORB Protocol), Microsoft DCOM (Distributed Component Object Model) a Java RMI (Remote Method Invocation).

Přirozený vývoj těchto protokolů vedl k zavedení middlewaru orientovaného na zprávy (MOM), který umožňuje volnější propojení v distribuovaných systémech abstrahováním překladu, zabezpečení a základních komunikačních protokolů od klientů a serverů. Mezi middlewarová řešení patří SOAP (Simple Object Access Protocol) a JMS. Proprietární zpracování transakcí na střední vrstvě existuje již od počátků COBOL (Common Business Oriented Language), ale nebylo to příliš složité kvůli omezením technologií raných zpráv.

S příchodem standardů, jako je JMS, mohou vývojáři nyní spojovat řadu technologií. Rozhodnutí o návrhu distribuovaného systému jsou obtížnější a jejich dopad na integritu a distribuci dat je zásadní pro úspěch nebo selhání systému.

Všudypřítomný a tichý předpoklad je, že zavedení technologie je aktivem, zatímco její závazky jsou často ignorovány. Neúčtování závazků často vede k systému, který je buď zbytečně komplikovaný a / nebo přepracovaný. Základní pochopení JMS a jeho inherentních kvalit (vlastností nezávislých na systému), po nichž následuje pečlivá analýza ve vztahu ke konkrétním scénářům distribuovaného systému, může naznačovat, jak dobře může JMS vyřešit systémové požadavky oproti změně stávajících problémů nebo dokonce zavedení nových.

Přehled JMS

JMS, představený společností Sun Microsystems v roce 1999 jako součást specifikace Java 2 Platform, Enterprise Edition (J2EE), je soubor standardů, které popisují základy vrstvy middlewaru pro zpracování zpráv. JMS umožňuje systémům komunikovat synchronně nebo asynchronně prostřednictvím modelů typu point-to-point a publish-subscribe. Dnes poskytuje několik dodavatelů implementace JMS, jako jsou BEA Systems, Hewlett-Packard, IBM, Macromedia a Oracle, což umožňuje JMS komunikovat s více technologiemi dodavatelů.

Obrázek 1 ukazuje jednoduchý systém založený na JMS s odchozí frontou naplněnou zprávami pro klienty ke zpracování a příchozí frontou, která shromažďuje výsledky zpracování klienta pro vložení do databáze.

Jak již bylo zmíněno výše, MOM (jako JMS) umožňuje volnější propojení v distribuovaných systémech abstrahováním překladu, zabezpečení a základních komunikačních protokolů od klientů a serverů. Jedním z hlavních prostředků vrstvy zpracování zpráv je to, že protože zavádí tuto abstrakční vrstvu, může se implementace klienta nebo serveru změnit, někdy radikálně, aniž by to ovlivnilo ostatní součásti systému.

Dva konkrétní scénáře

V této části představuji dva distribuované systémy, které jsou potenciálními kandidáty na JMS, a vysvětluji cíle každého systému a proč jsou systémy kandidáty na JMS.

Scénář 1

Prvním kandidátem je systém distribuovaného kódování (zobrazený na obrázku 2). Tento systém má sadu N klienti, kteří načítají úlohy kódování z centrálního databázového serveru. Klienti poté provedou skutečnou transformaci (kódování) z digitálního hlavního souboru do kódovaných souborů a dokončí tím, že nahlásí svůj stav po zpracování (např. Úspěch / neúspěch) zpět na centrální databázový server.

Typy kódování (např. Text, zvuk nebo video) nebo transformace (např. .pdf na .xml, .wav na .mp3, .avi na .qt) nezaléží. Je důležité si uvědomit, že kódování je náročné na CPU a vyžaduje škálované distribuované zpracování mezi více klienty.

Na první pohled je tento systém potenciálním kandidátem JMS, protože:

  • Zpracování musí být distribuováno, protože je extrémně náročné na procesor (CPU)
  • Může být problematické z hlediska výkonu systému připojit více klientů přímo k jednomu databázovému serveru

Scénář 2

Druhým kandidátským systémem JMS je globální registrační systém pro internetový portál. Globální registrace zpracovává požadavky na vytvoření nového uživatele (registraci), přihlášení a ověření.

Specifické registrační informace (např. Jméno, adresa, oblíbená barva) a metody autentizace uživatele (např. Uživatelské objekty na straně serveru, soubory cookie HTTP) nejsou důležité. Je však důležité, aby tento systém škáloval, aby zvládl miliony uživatelů, a způsoby použití je obtížné, ne-li nemožné, předvídat. (Během televizní hry ESPN World Cup hlasatel říká: „Přihlaste se a hlasujte v naší online anketě. Výsledky představíme na konci show.“ Najednou se do tří minut přihlásí 500 000 uživatelů. interval 3 minuty = 180 sekund; 500 000 uživatelských přihlášení / 180 sekund = 2778 uživatelských přihlášení / s.)

Tento systém je potenciálním kandidátem JMS z následujících důvodů:

  • Systém musí být distribuován, aby se zvýšil objem transakce
  • Transakce jsou atomické (např. Přihlášení), takže jsou bez státní příslušnosti, a proto jsou kandidáty na distribuci

Oba systémy jsou architektonicky podobné. Několik klientských počítačů extrahuje data z centrálního databázového serveru (případně replikovaného na M pouze pro čtení databázových serverů), proveďte nějakou logiku na klientovi a poté nahlaste stav zpět na centrální databázový server. Jeden systém dodává kódované soubory do souborového systému přes UNC / FTP; druhá poskytuje obsah HTML do webových prohlížečů přes HTTP. Oba systémy jsou distribuovány.

To je tolik, kolik techniků jde se svými analýzami před aplikací JMS. Ve zbytku tohoto článku vysvětluji, že ačkoli tyto systémy sdílejí mnoho charakteristik, vhodnost JMS se stává jasnější a divergentnější, když zkoumáme požadavky každého systému, včetně výkonu systému, distribuce dat a škálovatelnosti.

Analýza systému: Integrovat nebo neintegrovat

JMS má vnitřní vlastnosti nezávislé na systému. Některé z těchto vlastností (klady označené +, zápory označené -), které platí pro oba systémy, zahrnují:

  • (+) JMS je sada standardů vytvořených implementacemi více dodavatelů; proto se vyhnete obávaným zámek dodavatele problém.
  • (+) JMS umožňuje abstrakci (prostřednictvím obecného API) mezi klientem a serverem; můžete změnit databázové schéma nebo platformu bez změny aplikační vrstvy (implicitní zde jsou další potenciální změny systému, izolované od sebe vrstvou zasílání zpráv).
  • (+)/(-) JMS může pomoci systémovému měřítku (pro). Protikladem je, že jakýkoli systém, který se škáluje pomocí JMS, může škálovat i bez něj.
  • (-) JMS je komplikovaný. Je to zcela nová vrstva s novou sadou serverů. Správa zavádění softwaru, monitorování serveru a zabezpečení jsou jen některé z netriviálních problémů spojených s zaváděním JMS. Rovněž je třeba vzít v úvahu náklady.
  • (-) Prodejci ne vždy interpretují a proto implementují standardy přesně tak stejným způsobem, takže existují rozdíly mezi různými implementacemi.
  • (-) S JMS potřebujete více systémových kontrol a vyvážení. Nejenže zavedete novou vrstvu, ale také zavedete asynchronní distribuci dat a potvrzení, které má přidanou složitost asynchronního oznámení.
  • (-) Žádné fronty hlášení / aktualizace / monitorování zpráv bez vlastního softwaru.

JMS má také vlastnosti závislé na systému. Vhodnost JMS závisí na tom, jak dobře tyto vlastnosti mapují problémovou sadu, kterou se snažíte vyřešit. Následují některé z těchto kvalit a to, jak souvisí se dvěma zájmovými systémy:

Ukládání do mezipaměti

Ukládání do mezipaměti je primární úvahou pro plánování kapacity v jakémkoli distribuovaném systému. JMS má mnoho funkcí, které umožňují jeho použití jako technologii ukládání do mezipaměti (hlavně je distribuovaná, synchronní nebo asynchronní a výměny dat jako objekty ve zprávách). Stávající instalaci JMS lze tedy v případě potřeby využít jako infrastrukturu ukládání do mezipaměti.

Při zvažování kódovacího systému není ukládání do mezipaměti obecně užitečné pro zvýšení celkového výkonu systému, protože většina transformací souborů se provede jednou a přesune se do hostitelského zařízení nebo do sítě SAN (storage area network) a je málo překrytí obsahu mezi zákazníky. Globální registrace je hlavním kandidátem na mezipaměť informací o uživateli, protože uživatelé se obvykle přihlašují, procházejí a poté se odhlašují. Přihlášení vytvoří položku mezipaměti uživatele a tento objekt poskytuje následné ověření uživatele, když je uživatel na webu.

Zpracování objednávky

V rámci globálního registračního systému neexistuje žádné plánování ani objednávka zpracování transakcí. Pseudonáhodní uživatelé vstupují do systému v pseudonáhodných intervalech po přihlášení, procházejí obsah (a jsou proto ověřeni při přístupu k omezenému obsahu nebo aplikacím) a poté se odhlásí.

V rámci kódovacího systému je nařízeno zpracování. Obsah se rozděluje do skupin k doručení v závislosti na dostupnosti vyměnitelného úložiště (např. DLT Solutions nebo Network Appliance storage). Obsah není doručen, dokud není dávka dokončena, takže dávky se musí spustit v pořadí (i když transformace v dávce mohou být potenciálně neuspořádané). Implementace prioritních front v rámci JMS pro zachování pořadí zpracování je možná, ale udržování tohoto pořadí dávkových zpráv mezi více servery JMS a více frontami se stává docela komplikovaným. Relační databázový server s podporou transakcí je vhodnější technologií pro správu tohoto pracovního toku.

Bezpečnostní

Zabezpečení není součástí specifikace JMS. Bezpečnostní problém se nutně nemění s implementací založenou na JMS (pokud máte bezpečnostní požadavek před JMS, budete mít podobný bezpečnostní požadavek po JMS). S tímto vědomím je důležité pochopit, jak může JMS souviset se stávajícím zabezpečením infrastruktury.

Obecně platí, že čím více technologií použijete, tím zranitelnější bude váš systém vůči hackerům a porušení zabezpečení. Vzhledem k tomu, že aplikační server pro globální registraci je orientován na web, bezpečnostní nedostatky objevené v implementaci JMS vašich dodavatelů a publikované v internetových zpravodajských skupinách se rychle stávají bezpečnostními závazky pro váš web. Protože JMS je obecný API, je také náchylnější k narušení zabezpečení než proprietární systém, který používá nepublikované API.

I když můžete využít stávající zabezpečení brány firewall a sítě založené na protokolu IP k ochraně vašich aplikačních a databázových serverů typu back-end (číst: není určeno webem - je to zamýšleno slovem), existuje značné bezpečnostní riziko vystavením aplikačních serverů JMS přímo na internet.

Systém kódování obecně existuje ve stejné síti (také v síti izolované od Internetu). Takže v topografii tohoto systému není nic inherentního, co se týká JMS, a využití této topografie k zajištění bezpečnosti (pro kódovací systém existuje mnohem méně bezpečnostních požadavků, protože to není orientováno na web).

Škálovatelnost

Protože globální registrační systém podléhá rozmarům velké a uvážlivě klikající uživatelské základny, požadavky na škálovatelnost systému zaručují JMS. JMS nejen pomůže škálovat systém, bude také řadit transakce, i když to moc nepomůže, když systém zaplaví požadavky uživatelů.

Vzhledem k tomu, že distribuovaný kódovací systém pečlivě reguluje přenos dat (protože je to pravděpodobně samostatný systém), požadavky na škálovatelnost systému nejsou tak impozantní. Pro distribuované kódování můžete připojit svůj O [100] klienti přímo do vaší databáze a škrťte jejich provoz, aby se vyvážila propustnost kódování s výkonem databázového serveru.

Výkon

Zavedení jediného serveru JMS může problémy s výkonem spíše změnit než je vyřešit. Z tohoto důvodu by měl být systém JMS navržen s více servery JMS (a tedy s několika frontami). Obrázek 4 ukazuje, proč se problémy s výkonem místo řešení mění. Ilustruje vrstvy zpracování požadované pro obecný datový server, aby reagoval na požadavky na připojení klienta:

Výměna dat mezi klientem a serverem je dvoudílný proces, ať už se jedná o klient-databáze nebo klient-JMS server:

  1. Přístup k datům
  2. Správa vláken a soketů, sdružování a ukládání do mezipaměti

JMS a databázový server vypadají úplně stejně (obrázek 4). Zpracovávají připojení soketů, správu podprocesů a přístup k datům serveru.

Pouze s jedním serverem JMS lze potenciální problémy s výkonem jednoduše dojíždět z databázového serveru na server JMS. Kromě možného zhoršení výkonu spojeného s přepínáním kontextu na vašem databázovém serveru jsou nyní problémy s výkonem potenciálně větší kvůli problémům s výkonem JVM na vašem serveru JMS.

Jeden server JMS dodává vašemu systému značnou složitost a může také způsobit problémy s výkonem související s připojením více klientů k jednomu serveru. Dopad více serverů JMS na design vašeho systému a tok dat může znamenat rozdíl mezi úspěšným nebo neúspěšným zavedením systému.

Stručně řečeno, funkce versus potenciální dopad JMS vypadá takto:

Funkce versus dopad JMS

$config[zx-auto] not found$config[zx-overlay] not found