Quali scenari sono le implementazioni del servizio di distribuzione dati di Object Management Group (OMG) più adatto?

3

Sono sempre stato un grande fan delle implementazioni di messaggistica asincrona e pub / sub, ma provenendo da uno sfondo Java, ho più familiarità con l'utilizzo di sistemi di messaggistica basati su JMS, come JBoss MQ , HornetQ , ActiveMQ , OpenMQ , ecc. Ho anche seguito vagamente il discussione di AMQP . Ma recentemente mi sono reso conto della Specifica del servizio di distribuzione dei dati dal Object Management Group , e abbiamo trovato un paio di implementazioni open-source:

OpenSplice

OpenDDS

Sembra che questa roba sia focalizzata sul tipo di scenari ad alto volume che si tende ad associare a scambi di trading finanziari e cosa no. Il mio attuale interesse è più simile a quello delle notifiche relative all'elaborazione del flusso di attività (pensa a Twitter / Facebook) e mi chiedo se i server DDS valgano la pena di approfondire.

Chiunque abbia esperienza pratica con questa tecnologia e / o una profonda comprensione di esso, commenta quanto sia utile e quali scenari è più adatto? Come si accumula contro più server JMS "tradizionali" e / o AMQP (o anche STOMP o OpenWire, ecc.)

Modifica: FWIW, ho trovato alcune informazioni su questo thread StackOverflow . Non è una risposta completa, ma chiunque abbia trovato questa domanda potrebbe anche trovare utile quel thread, da cui il link aggiunto.

    
posta mindcrime 16.12.2010 - 05:45
fonte

3 risposte

1

DDS, come JMS, è solo una specifica API.

Quello che penso tu abbia bisogno di confrontare sono le implementazioni specifiche in termini di quanto bene si adattino alle tue esigenze specifiche, che non hai descritto, tranne che per dire che vuoi fare l'elaborazione del flusso di attività.

hai bisogno point-to-point o pub / sub? endpoint transitori o persistenti? semantica effimera, transazionale, garantita o esattamente una volta di consegna?

Ecco un post sul blog che ho scritto che potrebbe aiutarti: link

    
risposta data 23.03.2011 - 22:59
fonte
1

Ho usato DDS parecchio, in particolare l'implementazione RTI di DDS. Ho dedicato molto tempo e impegno a rendere la libreria RTI utilizzabile per gli sviluppatori ordinari che desiderano produrre e comporre i dati senza preoccuparsi dei problemi relativi alla qualità del servizio o di come i loro dati giungono a destinazione. Ciò comporta il wrapping dell'implementazione RTI in una libreria che fornisce un'interfaccia di richiamo per gli abbonati e un modo thread-safe di pubblicare i dati, il tutto in modo indipendente dalla piattaforma. E tutto questo viene creato utilizzando strumenti di generazione automatica del codice che supportano Windows 32/64 bit, Linux 64 bit e Java.

Cercare di usare le classi DDS non elaborate è solo questione di problemi IMHO. Il codice per impostare tutto e mantenere la QoS compatibile tra editori e iscritti non è bello. E avere un team di sviluppatori che prova ad utilizzarlo direttamente significa che avrai un lavoro a tempo pieno a supporto di loro.

Onestamente non riesco a capire perché non forniscono subito una soluzione di wrapper simile a quella che ho creato, perché è molto più facile da usare. - Probabilmente perché vogliono venderti un grosso contratto di supporto.

Il problema più grosso che avrai sarà quello di mettere a punto la QoS in un modo che soddisfi le tue esigenze. Se si guardano le statistiche pubblicate sul sito Web di RTI, sono tutte su messaggi molto piccoli, che potrebbero essere adatti a voi. Il nostro scenario di casi d'uso si riduce da piccoli messaggi infrequenti a messaggi ad alto throughput costanti ad alta velocità dell'ordine di 70 MB / s. Accordare la tua QoS per soddisfare questa domanda è difficile! Quasi sicuramente avrai bisogno di supporto quasi fino a quando non avrai qualcosa che si blocca insieme.

Ma dal lato positivo ti dà un modo indipendente dalla piattaforma di trasferire i dati e il servizio di scoperta è bello perché ti permette di spostare i servizi tra macchine molto facilmente senza letteralmente nessuna modifica alla configurazione. La sua capacità di supportare la memoria multicast e condivisa significa che può funzionare in modo efficiente quando si hanno più abbonati agli stessi dati, ma è necessario impostare le opzioni correttamente per ottenere ciò. Hai anche la possibilità di inviare i dati in modo affidabile o non rintracciabile, in base alle tue esigenze.

Uno svantaggio che può colpirti se stai usando una comunicazione affidabile è che se un abbonato ha un problema e interrompe il prelievo di dati dalla coda, può avere un effetto negativo sugli altri abbonati che girano su altri computer.

    
risposta data 09.08.2011 - 17:45
fonte
0

Nessuna esperienza con questo (e sarei sorpreso se qualcuno lo ha!).

Lo standard di messaggistica aziendale di fatto è MQSeries di IBM (o ora nascosto come Websphere in qualche modo dai doppiatori di marketing di IBM).

È stato il primo sul campo, è disponibile su quasi tutte le piattaforme, è utilizzabile dalla maggior parte delle lingue e ha un prezzo ragionevole. Oltre alla propria API supporta AMQP e JMS.

Le specifiche OMG sono morte nell'acqua.

    
risposta data 07.07.2011 - 05:56
fonte

Leggi altre domande sui tag