Il miglior supporto di messaggistica per applicazioni SOA in tempo reale?

Question

Sto lavorando ad un'applicazione in tempo reale implementata usando in stile SOA (leggi componenti accoppiati in modo lasco collegati tramite un protocollo di messaggistica - JMS, MQ o HTTP).

L'architetto che ha progettato questo sistema ha scelto di utilizzare JMS per connettere i componenti. Questo sistema è in tempo reale, quindi non è necessario mettere in coda i messaggi in caso di errore di un componente (la transazione semplicemente scade). Inoltre, non è necessaria la consegna o il rollback garantiti.

In questo caso, ci sono dei vantaggi nell'usare JMS su qualcosa come un servizio web HTTP (velocità, footprint delle risorse, ecc.)?

Una cosa che sto pensando è che l'approccio JMS ci richiede di impostare una dimensione del pool di thread (il numero di componenti che ascoltano un argomento / coda JMS), un servizio HTTP non sarebbe più adatto da questo non è necessaria la configurazione (viene creato un nuovo thread per ogni richiesta HTTP che rende l'applicazione scalabile a un numero "illimitato" di richieste fino a quando il server esaurisce le risorse).

Mi manca qualcosa?

Answer 1

Non sono affatto d'accordo con i punti sollevati da S.Lott, ma qui ci sono un paio di punti da considerare riguardo ai servizi web HTTP:

• I tuoi clienti devono solo sapere come comunicare via HTTP, un protocollo ben supportato da quasi tutte le lingue moderne in una forma o nell'altra. JMS, sebbene popolare, è più specializzato di HTTP e limita quindi le lingue che possono essere utilizzate dai sistemi interconnessi. Forse non è un problema per il tuo sistema al momento, ma dovrai collegare altri sistemi in seguito che potrebbero avere difficoltà a supportare la connettività JMS?

• Gli standard come WSDL e SOAP che potresti utilizzare per i tuoi servizi sono ben supportati da molti linguaggi e ci sono molti strumenti in giro che genereranno codice per implementare entrambe le estremità della pipeline (client e server) per te da un file WSDL, riducendo la quantità di sviluppo che dovrai fare. Questi standard rendono anche relativamente semplice definire e pubblicare le specifiche dei dati che passerai tra i tuoi sistemi, cosa che presumibilmente dovrai fare a mano usando una tecnologia di accodamento come JMS.

• Il rovescio della medaglia, come sottolineato da S.Lott, JMS ti offre funzionalità che butti via usando il protocollo HTTP (senza stato): ordering garantito & amp; affidabilità; monitoraggio; scalabilità; ecc. Sei sicuro di non averne bisogno e di non averne bisogno in futuro?

Ottima domanda, a proposito.

Answer 2

Penso che dipenda davvero dalla situazione. Dove lavoro, supportiamo Remoting, JMS, MQ, HTTP e sFTP. Stiamo implementando un dispositivo middleware che parla Remoting, JMS, MQ e HTTP e un componente software middleware che parla JMS, MQ e HTTP.

Come indicato sopra, gli standard ci aiutano a diventare flessibili, ma i formati proprietari consentono più funzionalità.

In poche parole, direi che usi HTTP per le chiamate senza stato (che potrebbero finire per soddisfare quasi tutte le tue esigenze) e qualsiasi formato proprietario ti serva per le chiamate con stato. Se lavori in una grande impresa, un'appliance hardware di solito si adatta perfettamente come middleware: compressione, crittografia, trasformazione e traduzione velocissime, con un costo totale di proprietà molto basso.

Answer 3

Non conosco abbastanza bene le tue esigenze, ma potresti trascurare Gestibilità, Flessibilità e Prestazioni.

JMS consente di monitorare e gestire la coda. Queste caratteristiche mancano di HTTP e dovresti creare piuttosto che acquistare da un fornitore.

Inoltre, in JMS ci sono code e argomenti che consentono a più abbonati di un singolo editore. Non possibile in HTTP.

Anche se potresti non aver bisogno di queste cose nella versione 1.0, potresti volerle in futuro.

Inoltre, JMS potrebbe essere in grado di utilizzare altri meccanismi di trasporto come i socket denominati, il che riduce le spese generali se non c'è tutta quella negoziazione dei socket in corso (quasi) con ogni richiesta.

Answer 4

Se segui il percorso HTTP e desideri supportare più di un computer o un certo tipo di affidabilità, avrai bisogno di un bilanciamento del carico in grado di rilevare i server Web disponibili e caricare le richieste su di essi, quindi eseguire il failover su un altro server Web se un particolare box / processo muore. I client che invieranno richieste HTTP dovranno anche gestire i fallimenti dei server e riprovare le operazioni in qualche ciclo.

Questa è una delle caratteristiche principali di una coda di messaggi: bilanciamento del carico affidabile con failover e accoppiamento lento tra produttori e consumatori senza che questi debbano includere la logica dei tentativi, quindi il codice client o server non deve preoccuparsi di questo un pò cosa. Questo è totalmente separato dal fatto che tu voglia o meno la persistenza del messaggio o desideri utilizzare le transazioni ACID per produrre / consumare messaggi (che può essere molto utile BTW).

Se ti concentri solo sul lato server usando Java, che sia Servlet o MessageListener / MDB, sono in qualche modo simili in entrambi i casi. La differenza è il bilanciamento del carico.

Quindi forse la domanda dovrebbe davvero essere: un broker JMS è più facile da configurare e amp; lavorare con la configurazione dell'infrastruttura di bilanciamento del carico DNS / NAT / IP / HTTP?

Answer 5

Suppongo che dipenda da cosa intendi in tempo reale ... Né JMS né HTTP a mio avviso supportano "in tempo reale"; bene le applicazioni, nel senso che non possono offrire prestazioni prevedibili / deterministiche né dare la giusta priorità ai flussi in presenza di contese.

Parte di ciò è che queste tecnologie sono costruite su TCP che serializza tutto il traffico in un singolo FIFO, il che significa che non è possibile assegnare facilmente le priorità ai diversi flussi di traffico. Inoltre, i timer TCP non sono facilmente controllabili con conseguenti blocchi e timeout imprevedibili ... Per questo motivo molte applicazioni di streaming utilizzano UDP anziché TCP come protocollo sottostante.

Un altro problema con JMS è che le implementazioni tipiche utilizzano un broker che centralizza l'invio dei messaggi. Questa non è l'architettura migliore per ottenere prestazioni deterministiche.

Se stai cercando un middleware in grado di offrirti il ??tipo di garanzie di affidabilità e semantica di pubblicazione e sottoscrizione che ottieni con JMS, ma è stato sviluppato per adattarsi al dominio dell'applicazione in tempo reale, ti consiglio di dare un'occhiata ai dati OMG -Distribution Service (DDS). Vedi dds.omg.org e questo articolo che ho scritto sostenendo perché DDS è il miglior middleware per implementare una SOA in tempo reale. http://soa.sys-con.com/node/467488