2009-07-10 18 views
9

Sono nel mercato per una buona libreria open source basata su Pub/Sub (modello di osservatore). Non ho trovato alcun mi piace:Best Publish/Subscribe "Middleware"

  • JMS - legato a Java, tratta i contenuti dei messaggi come muti blob binari

  • NDDS - $$, uso di IDL

  • CORBA/ICE - Pub/sub è costruito sulla cima della RPC, CORBA API non è intuitivo

  • JBOSS/ESB - non troppo familiarità con

.210

Sarebbe bello se tale pacchetto potrebbe al seguente:

  • Network basato

  • Consapevole di carico utile di dati, gli utenti non dovrebbero preoccuparsi di Endian/serializzazione emette

  • Supporto per più lingue (C++, ruby, Java, python sarebbe bello)

  • Nessun codice generato automaticamente (nessun IDL!)

  • intuitiva di sottoscrizione/argomento gestione

Per divertimento, ho created my own. Pensieri?

risposta

3

Utilizziamo l'implementazione RTI DDS. Costa $, ma supporta molti parametri di qualità del servizio.

Esiste un'implementazione DDS gratuita denominata OpenDDS, ma non l'ho utilizzata.

Non vedo come sia possibile aggirare la necessità di predefinire i tipi di dati se la lingua di destinazione è tipizzata staticamente.

+2

Ho sempre pensato che i dati dovrebbero essere XML, in questo modo è semi-predefinito (tramite uno schema), ma non è legato a una lingua. – David

2

Guardare un po 'più a fondo nelle varie implementazioni JMS.

Molti di questi non sono solo Java, ma forniscono anche librerie client per altre lingue.

Suns OpenMQ ha almeno un'interfaccia C++, Apache ActiveMQ fornisce librerie lato client per molte lingue comuni.

Quando si tratta di formati di messaggi, di solito sono disaccoppiati dal middleware del messaggio stesso. È possibile definire il proprio formato di messaggio. È possibile definire il proprio schema XML e inviare messaggi XML. È possibile inviare BER codificato ASN.1 utilizzando una libreria di terze parti se lo si desidera. Oppure formattare e analizzare i dati con una libreria JSON.

0

Si potrebbe dare un'occhiata a PubSubHubbub. È un'estensione di Atom/RSS per lasciare pubub tramite webhooks. L'interfaccia è HTTP e XML, quindi è indipendente dalla lingua. Sta aumentando l'adozione ora che Google Reader, FriendFeed e FeedBurner lo stanno utilizzando.Il caso d'uso principale sono i blog e roba del genere, ma ovviamente puoi avere qualsiasi tipo di payload.

L'unica implementazione open source che conosco finora è this one per Google AppEngine. Dicono che il supporto per l'auto-hosting stia arrivando.

1

Potresti essere interessato alla libreria MUSCLE (disclaimer: l'ho scritto, quindi potrei essere di parte). Penso che soddisfi tutti i criteri che hai specificato.

https://public.msli.com/lcs/muscle/

0

C'è anche OpenSplice DDS. Questo è simile al DDS di RTI, tranne che è L GPL!

check it out:

+1

Link a OpenSplice http://www.opensplice.org/cgi-bin/twiki/view/Community/WebHome – tuergeist

+0

Ha detto "Nessun codice generato automaticamente (nessun IDL!)" – tobsen

4

Come sottolineato-out da un precedente post in questo thread, una delle opzioni è OpenSplice DDS che è un'implementazione Open Source delle OMG DDS standard (lo stesso standard implementato da NDDS) .

I principali vantaggi di OpenSplice DDS sopra l'altro middleware che si stanno prendendo in considerazione possono essere riassunti come:

  • prestazioni
  • supporto Rich per QoS (persistenza, di tolleranza agli errori, Tempestività, ecc)
  • Data Centricity (ad es. Possibilità di interrogare e filtrare flussi di dati)

Qualcosa che vorrei capire è quali sono i tuoi problemi con IDL. DDS utilizza IDL come modalità indipendente dalla lingua per specificare i tipi di dati utente. Comunque DDS non è limitato a IDL, potresti usare XML, se preferisci. Il vantaggio di specificare i tipi di dati, e disaccoppiamento loro rappresentazione da un linguaggio di programmazione specifico, è che il middleware in grado di:

(1) prendere lontano da voi l'onere di dati di serializzazione,

(2) generare molto tempo/spazio efficiente serializzazione,

(3) assicurare end-to-end di sicurezza tipo,

(4) consentire il filtro contenuto nel complesso tipo di dati (non solo l'header come in JMS), e

(5) enabl l'interoperabilità on the wire tra i vari linguaggi di programmazione (ad es. Java, C/C++, C#, ecc.)

A seconda del sistema o dell'applicazione che si sta progettando, alcune delle proprietà sopra riportate potrebbero non essere utili/pertinenti. In tal caso, puoi semplicemente generare uno, pochi "tipi DDS" che sono i titolari dei dati serializzati.

Se si pensa a JMS, fornisce 5 diversi tipi di argomenti che è possibile utilizzare per inviare i propri dati. Con DDS puoi fare lo stesso, ma hai la flessibilità di definire esattamente i tipi di argomento.

Infine, si potrebbe voler dare un'occhiata a this blog entry su Scala e DDS per una discussione più lunga sul perché i tipi e la tipizzazione statica sono buoni specialmente nei sistemi distribuiti.

-AC

1

tre che ho usato:

  • IBM MQ Series - troppo costoso, difficile da lavorare.

  • Tico Rendezvous - (rinominato ora in EMS?) È stato UDP molto veloce e utilizzato, potrebbe anche essere utilizzato senza server centrale. Il mio preferito ma costoso e richiede una tariffa di manutenzione.

  • ActiveMQ: lo sto usando al momento ma trovo che si arresta spesso in modo anomalo. Inoltre richiede alcuni progetti portati da Java come spring.net. Funziona ma non posso raccomandarlo a causa di problemi di stabilità.

utilizzato anche MSMQ, nel tentativo di costruire il mio Pub/Sub, ma dal momento che non gestisce fuori dalla scatola il vostro bloccato a scrivere una notevole quantità di codice.

+0

TIBCO Rendezvous e TIBCO EMS sono due prodotti diversi . EMS è un fornitore JMS che comprende uno o più server di messaggi centrali. Rendezvous è un pub/sub middleware senza connessione che non ha un server centrale. I due prodotti sono gratuiti in base alle tue esigenze. – scaganoff

0

IBM Webpshere MQ e la licenza non è eccessivamente ampia se si lavora a livello aziendale.

+1

L'OP ha richiesto una soluzione * Open Source *! –

Problemi correlati