Dovresti andare con JMS?

Lo sviluppo di sistemi distribuiti sta crescendo rapidamente poiché gli sviluppatori di software creano sistemi che devono stare al passo con i requisiti sempre crescenti imposti dall'e-business. Ma mai prima d'ora la progettazione e l'implementazione di un livello di elaborazione dei messaggi all'interno di un sistema distribuito sono state così complesse come lo sono oggi. Ciò è dovuto principalmente al notevole aumento delle potenziali funzionalità abilitate da standard come Java Message Service (JMS) che connettono le tecnologie di molti fornitori in un unico sistema. Inoltre, la proliferazione di Internet ha dato vita a nuove, estese basi di utenti e ha reso disponibili diversi protocolli per la comunicazione all'interno di un sistema distribuito. Tali protocolli includono CORBA IIOP (Internet Inter-ORB Protocol), Microsoft DCOM (Distributed Component Object Model) e Java RMI (Remote Method Invocation).

La naturale evoluzione di questi protocolli ha portato all'introduzione del middleware orientato ai messaggi (MOM), che consente un accoppiamento più flessibile all'interno dei sistemi distribuiti astringendo traduzione, sicurezza e protocolli di comunicazione sottostanti da client e server. Le soluzioni middleware includono SOAP (Simple Object Access Protocol) e JMS. L'elaborazione delle transazioni proprietaria di livello intermedio è esistita sin dai primi giorni di COBOL (Common Business Oriented Language), ma non era molto complessa a causa dei limiti delle prime tecnologie di messaggistica.

Con l'avvento di standard come JMS, gli sviluppatori possono ora connettere numerose tecnologie. Le decisioni di progettazione del sistema distribuito sono più difficili e le loro implicazioni sull'integrità e la distribuzione dei dati sono fondamentali per il successo o il fallimento del sistema.

Un presupposto pervasivo e tacito è che l'introduzione della tecnologia sia una risorsa mentre le sue responsabilità sono spesso ignorate. Non tenere conto delle passività spesso si traduce in un sistema che è inutilmente complicato e / o troppo ingegnerizzato. Una comprensione di base di JMS e delle sue qualità intrinseche (qualità indipendenti dal sistema), seguita da un'attenta analisi in relazione a specifici scenari di sistemi distribuiti, può indicare quanto bene JMS potrebbe risolvere i requisiti di sistema rispetto all'alterazione dei problemi esistenti o persino all'introduzione di nuovi.

Panoramica di JMS

JMS, introdotto da Sun Microsystems nel 1999 come parte della specifica Java 2 Platform, Enterprise Edition (J2EE), è un insieme di standard che descrivono le basi per un livello middleware di elaborazione dei messaggi. JMS consente ai sistemi di comunicare in modo sincrono o asincrono tramite entrambi i modelli point-to-point e di pubblicazione-sottoscrizione. Oggi, diversi fornitori forniscono implementazioni JMS come BEA Systems, Hewlett-Packard, IBM, Macromedia e Oracle, consentendo così a JMS di interagire con più tecnologie di fornitori.

La Figura 1 mostra un semplice sistema basato su JMS con una coda in uscita popolata con messaggi da elaborare per i client e una coda in entrata, che raccoglie i risultati dell'elaborazione del client per l'inserimento in un database.

Come accennato in precedenza, MOM (come JMS) consente un accoppiamento più lasco all'interno di sistemi distribuiti astraendo la traduzione, la sicurezza ei protocolli di comunicazione sottostanti dai client e dai server. Una delle risorse principali del livello di elaborazione dei messaggi è che, poiché introduce questo livello di astrazione, l'implementazione del client o del server può cambiare, a volte radicalmente, senza influire sugli altri componenti del sistema.

Due scenari specifici

In questa sezione, presento due sistemi distribuiti che sono potenziali candidati per JMS e spiego gli obiettivi di ciascun sistema e perché i sistemi sono candidati JMS.

scenario 1

Il primo candidato è un sistema di codifica distribuito (mostrato nella Figura 2). Questo sistema ha una serie di N client che recuperano i lavori di codifica da un server database centrale. I client quindi eseguono la trasformazione effettiva (codifica) dal master digitale ai file codificati e terminano riportando il loro stato di post-elaborazione (ad esempio, riuscita / non riuscita) al server del database centrale.

I tipi di codifica (ad esempio, testo, audio o video) o trasformazioni (ad esempio, .pdfin .xml, .wavin .mp3, .aviin .qt) non hanno importanza. È importante comprendere che la codifica richiede un uso intensivo della CPU e richiede un'elaborazione distribuita su più client per essere scalata.

A prima vista, questo sistema è un potenziale candidato JMS perché:

  • L'elaborazione deve essere distribuita in quanto è estremamente intensiva per il processore (CPU)
  • Può essere problematico, dal punto di vista delle prestazioni del sistema, connettere più client direttamente a un singolo server di database

Scenario 2

Il secondo sistema candidato JMS è un sistema di registrazione globale per un portale Internet. La registrazione globale gestisce le richieste di creazione (registrazione), accesso e autenticazione di nuovi utenti.

Le informazioni di registrazione specifiche (ad esempio, nome, indirizzo, colore preferito) e metodi di autenticazione dell'utente (ad esempio, oggetti utente lato server, cookie HTTP) non sono importanti. Tuttavia, è importante che questo sistema sia scalabile per gestire milioni di utenti e che i modelli di utilizzo siano difficili, se non impossibili, da prevedere. (Durante una partita televisiva della Coppa del Mondo ESPN, l'annunciatore dice: "Accedi e vota nel nostro sondaggio online. Presenteremo i risultati alla fine dello spettacolo". All'improvviso, 500.000 utenti accedono entro tre minuti intervallo.3 minuti = 180 secondi; 500.000 accessi utente / 180 secondi = 2.778 accessi utente / sec.)

Questo sistema è un potenziale candidato JMS per i seguenti motivi:

  • Il sistema deve essere distribuito per ridimensionare il volume delle transazioni
  • Le transazioni sono atomiche (ad es. Login), quindi sono apolidi e quindi candidati per la distribuzione

I due sistemi sono architettonicamente simili. Diverse macchine client estraggono i dati da un server database centrale (possibilmente replicati su server database M di sola lettura), eseguono una logica sul client e quindi segnalano lo stato al server database centrale. Un sistema fornisce file codificati a un filesystem su UNC / FTP; l'altro fornisce contenuto HTML ai browser Web su HTTP. Entrambi i sistemi sono distribuiti.

Questo è quanto molti ingegneri fanno con le loro analisi prima di applicare JMS. Nel resto di questo articolo, spiego che, sebbene questi sistemi condividano molte caratteristiche, l'appropriatezza di JMS diventa più chiara e divergente man mano che esaminiamo i requisiti di ciascun sistema, comprese le prestazioni del sistema, la distribuzione dei dati e la scalabilità.

Analisi del sistema: integrare o non integrare

JMS ha qualità intrinseche e indipendenti dal sistema. Alcune di queste qualità (pro denotati da +, svantaggi denotati da -) che si applicano a entrambi i sistemi includono:

  • (+) JMS è un insieme di standard creati da più implementazioni di fornitori; pertanto, si evita il temuto problema del blocco del fornitore .
  • (+) JMS consente l'astrazione (tramite un'API generica) tra client e server; è possibile modificare uno schema o una piattaforma di database senza cambiare il livello dell'applicazione (qui sono implicite altre potenziali modifiche al sistema, isolate l'una dall'altra dal livello di messaggistica).
  • (+) / (-) JMS può aiutare un sistema a scalare (un professionista). Lo svantaggio è che qualsiasi sistema scalabile con JMS può scalare senza di esso.
  • (-) JMS è complicato. È un livello completamente nuovo con un nuovo set di server. La gestione dell'implementazione del software, il monitoraggio del server e la sicurezza sono solo alcuni dei problemi non banali associati all'implementazione di JMS. Anche i costi dovrebbero essere considerati.
  • (-) I fornitori non interpretano e quindi implementano sempre gli standard esattamente allo stesso modo, quindi esistono differenze tra le varie implementazioni.
  • (-) Con JMS, sono necessari più controlli e bilanciamenti del sistema. Non solo si introduce un nuovo livello, ma si introduce anche la distribuzione e il riconoscimento asincrono dei dati, che ha la complessità aggiuntiva della notifica asincrona.
  • (-) Nessun messaggio di segnalazione / aggiornamento / monitoraggio delle code senza software personalizzato.

JMS ha anche qualità dipendenti dal sistema. L'adeguatezza di JMS dipende da quanto queste qualità sono mappate al set di problemi che stai cercando di risolvere. Di seguito sono riportate alcune di queste qualità e il modo in cui si relazionano ai due sistemi di interesse:

Caching

La memorizzazione nella cache è una considerazione primaria per la pianificazione della capacità all'interno di qualsiasi sistema distribuito. JMS ha molte caratteristiche che ne consentono l'uso come tecnologia di caching (principalmente che è distribuito, sincrono o asincrono e gli scambi di dati come oggetti nei messaggi). Pertanto, un'installazione JMS esistente può essere utilizzata come infrastruttura di memorizzazione nella cache, se necessario.

Quando si considera il sistema di codifica, la memorizzazione nella cache in genere non è utile per aumentare le prestazioni complessive del sistema, poiché la maggior parte delle trasformazioni di file viene eseguita una volta e viene spostata in una struttura di hosting o SAN (rete di archiviazione) e c'è poca sovrapposizione di contenuti tra i clienti. La registrazione globale è un ottimo candidato per una cache delle informazioni dell'utente, poiché gli utenti di solito accedono, navigano e quindi si disconnettono. Il login crea una voce della cache dell'utente e questo oggetto fornisce la successiva autenticazione dell'utente mentre l'utente si trova sul sito.

Ordine di elaborazione

All'interno del sistema di registrazione globale, non vi è alcuna pianificazione e / o ordine per l'elaborazione delle transazioni. Gli utenti pseudo-casuali accedono al sistema a intervalli pseudo-casuali al momento dell'accesso, sfogliano il contenuto (e vengono quindi autenticati quando accedono a contenuti e / o applicazioni limitati), quindi si disconnettono.

All'interno del sistema di codifica, l'elaborazione è ordinata. Il contenuto viene suddiviso in gruppi per la consegna a seconda della disponibilità di archiviazione rimovibile (ad esempio, soluzioni DLT o archiviazione di Network Appliance). Il contenuto non viene consegnato fino al completamento del batch, quindi i batch devono essere eseguiti in ordine (sebbene le trasformazioni all'interno di un batch possano potenzialmente essere non ordinate). L'implementazione di code di priorità all'interno di JMS per preservare l'ordine di elaborazione è possibile, ma il mantenimento di questo ordine di batch di messaggi tra più server JMS e più code diventa piuttosto complicato. Un server di database relazionale con supporto per le transazioni è una tecnologia più adatta per la gestione di questo flusso di lavoro.

Sicurezza

La sicurezza non fa parte della specifica JMS. Il problema di sicurezza non viene necessariamente modificato con un'implementazione basata su JMS (se si dispone di un requisito di sicurezza pre-JMS, si avrà un requisito di sicurezza simile dopo JMS). Sapendo questo, è importante capire come JMS potrebbe essere correlato alla sicurezza dell'infrastruttura esistente.

In generale, più tecnologia usi, più il tuo sistema diventa vulnerabile agli hacker e alle violazioni della sicurezza. Poiché il server delle applicazioni di registrazione globale è rivolto al Web, le falle di sicurezza scoperte nell'implementazione JMS dei fornitori e pubblicate nei news group di Internet diventano rapidamente responsabilità della sicurezza per il tuo sito. Inoltre, poiché JMS è un'API generica, è più soggetta a violazioni della sicurezza rispetto a un sistema proprietario che utilizza un'API non pubblicata.

Sebbene sia possibile sfruttare il firewall esistente e la sicurezza di rete basata su IP per proteggere le applicazioni back-end (leggi: non rivolte al Web, gioco di parole) dalle violazioni della sicurezza, esiste un rischio significativo per la sicurezza creato dall'esposizione dei server delle applicazioni JMS direttamente a Internet.

Il sistema di codifica generalmente esiste sulla stessa rete (anche una rete isolata da Internet). Quindi, non c'è nulla di intrinseco nella topografia di rete di questo sistema che si riferisce a JMS e che sfrutta questa topografia per fornire sicurezza (ci sono molti meno requisiti di sicurezza per il sistema di codifica, poiché non è rivolto al Web).

Scalabilità

Poiché il sistema di registrazione globale è soggetto ai capricci di una base di utenti ampia e capricciosa, i requisiti di scalabilità del sistema garantiscono JMS. JMS non solo aiuterà a scalare il sistema, ma metterà in coda le transazioni, anche se non sarà di grande aiuto quando le richieste degli utenti inondano il sistema.

Poiché il sistema di codifica distribuito ha regolato attentamente il traffico dati (poiché è presumibilmente un sistema autonomo), i requisiti di scalabilità del sistema non sono così formidabili. Per la codifica distribuita, è possibile connettere i O[100]client direttamente al database e limitare il loro traffico per bilanciare il throughput di codifica con le prestazioni del server di database.

Prestazione

L'introduzione di un singolo server JMS può modificare i problemi di prestazioni piuttosto che risolverli. Per questo motivo, un sistema JMS dovrebbe essere progettato con più server JMS (e quindi più code). La figura 4 mostra il motivo per cui i problemi di prestazioni vengono modificati anziché risolti. Illustra i livelli di elaborazione necessari affinché un server di dati generico risponda alle richieste di connessione client:

Lo scambio di dati tra client e server è un processo in due parti, sia che si tratti di un server da client a database o da client a JMS:

  1. Accesso ai dati
  2. Gestione di thread e socket, pool e memorizzazione nella cache

Un JMS e un server di database hanno lo stesso aspetto (Figura 4). Gestiscono le connessioni socket, la gestione dei thread e l'accesso ai dati del server.

Con un solo server JMS, i potenziali problemi di prestazioni si spostano semplicemente dal server database al server JMS. Oltre al possibile degrado delle prestazioni associato al cambio di contesto all'interno del server database, i problemi di prestazioni ora sono potenzialmente maggiori a causa di problemi di prestazioni JVM all'interno del server JMS.

Un singolo server JMS aggiunge una notevole complessità al sistema e potrebbe anche introdurre problemi di prestazioni relativi alla connessione di più client a un singolo server. L'impatto di più server JMS sulla progettazione del sistema e sul flusso di dati può fare la differenza tra un'implementazione del sistema riuscita o non riuscita.

In sintesi, le caratteristiche rispetto al potenziale impatto JMS sono così:

Funzionalità rispetto all'impatto JMS