Scegliere la tecnologia giusta per il sistema di messaggistica

3

Sto lavorando su un sistema di messaggistica da due anni a questa parte, il sistema è stato scritto da una squadra ormai lontana e coinvolge le e-mail e l'elaborazione dei documenti. Il processo di base è:

  1. Ricevi un'email, analizzala, salva gli allegati alla condivisione samba. Notifica al processore dei messaggi. Abbiamo una robusta applicazione Java che funziona molto bene.

  2. Elabora il messaggio, questo implica ottenere i dati utente da LDAP, chiamando i servizi web di elaborazione dei file su piattaforme diverse. Il sistema ha una sorta di servizio di riconsegna che esegue il polling del database per messaggi non riusciti o scaduti in stati diversi e li reinvia.

Le parti di elaborazione dei file sono servizi web EJB che fondamentalmente eseguono utilità da riga di comando. Il problema sta nella nostra soluzione di orchestrazione che è basata su OpenESB (quasi morta ora), ha un gruppo di BPEL che si chiamano a vicenda e chiamano EJB remoti (EJB3.0 su glassfish v2).

Il problema più grande è che viene eseguita troppa logica nei BPEL (ad esempio, tutti gli aggiornamenti del database sono eseguiti in BPEL, non c'è un livello di persistenza), sembrano gli spaghetti più terrificanti che abbia mai visto. Per non parlare del fatto che i NetBeans che usiamo per modificarli vengono eseguiti molto lentamente, al punto che alcuni file sono modificabili solo in un semplice editor di testo come XML. Inoltre il sistema ha un numero di bug sgradevoli che richiederebbe un grande refactoring da correggere e temo persino di pensarci. Questi messaggi sono gestiti manualmente dal nostro supporto, quindi non c'è quasi nessun impatto sul client, ma mi piacerebbe comunque avere un vero sistema transazionale.

Ora, per la domanda stessa. Sono disposto a dedicare molto del mio tempo libero a cercare di raggiungere due obiettivi: creare un sostituto per ESB e BPEL, apprendere nuove tecnologie e preferibilmente di tendenza. Mi piacerebbe mantenere il codice negli EJB di elaborazione dei file poiché funzionano bene, anche se sto pensando di sbarazzarmi di SOAP come interfaccia remota. Pertanto, sto chiedendo informazioni su quale tecnologia (-ies) mi consenta di creare una soluzione di messaggistica affidabile che:

  1. Avere un livello di persistenza amichevole, non ci sarà nulla di veramente complesso in dbs, solo i meta-dati dei messaggi.
  2. Prenditi cura delle chiamate di bilanciamento e di polling ai servizi web di elaborazione dei file.
  3. Non è necessario occuparsi di tonnellate di XML in luoghi diversi per aggiungere un nuovo metodo di interfaccia.
  4. Sarebbe scalabile - può essere eseguito su un numero di macchine.
  5. consentirebbe il monitoraggio in tempo reale, come la visualizzazione delle code di messaggi, il carico corrente, gli stati ecc.
  6. Spero che mi permetta di imparare qualcosa di nuovo, ovvero non lo stack J2EE. Fondamentalmente sono aperto a qualsiasi cosa, tranne BPEL e OpenESB.
posta devmiles.com 21.02.2012 - 19:17
fonte

2 risposte

3

Mi sto divertendo molto con Erlang in questo momento. È un ottimo linguaggio in sé e per sé. Il vero divertimento è nel framework e nel runtime su cui si basa. Erlang Runtime è progettato per applicazioni distribuite e simultanee (è nato a Ericsson per la sua infrastruttura di rete). Per l'integrazione con altri sistemi, c'è RabbitMQ che è costruito in Erlang e ha API native per la maggior parte dei grandi linguaggi. Ha un'interfaccia di gestione integrata che ti permette di visualizzare messaggi e cose simili.

Affrontare in modo specifico i tuoi requisiti:

  1. Erlang ha un database integrato chiamato Mnesia. Per la messaggistica duratura, Rabbit fa leva su Mnesia (se un'istanza scende la coda non andrà giù con esso) e non devi preoccuparti di te stesso, funziona.

  2. Out of the box Coniglio usa il round robin pub-sub. Se hai 3 ascoltatori che chiamano coda fanout, verranno alternati per ciascun messaggio.

  3. Rabbit ha una configurazione basata su API con UI disponibile per gestirlo senza modificare i programmi.

  4. Verifica: Erlang è stato progettato pensando alla scalabilità ... originariamente era stato progettato per supportare l'infrastruttura di rete di Ericsson. Combinato con RabbitMQ e puoi distribuire l'elaborazione dei messaggi su molti nodi

  5. Verifica: Rabbit MQ ha molti plug-in per il monitoraggio

  6. Erlang sta guadagnando molta trazione in quanto una soluzione per l'elaborazione simultanea ha sicuramente un approccio diverso al di fuori del paradigma OO standard.

risposta data 21.02.2012 - 19:30
fonte
1

Per l'interfaccia remota raccomanderei di considerare RESTful invece di SOAP. Io stesso ho avuto brutte esperienze con SOAP in passato (in particolare per quanto riguarda prestazioni e interoperabilità) e ho trovato REST un ottimo sostituto: leggero e flessibile.

Per l'infrastruttura ESB le tue esigenze richiedono un framework, per supportare le funzionalità menzionate sarebbe gravoso fare altrimenti. Non ho molta esperienza in merito, ma uno dei miei clienti gestisce un ESB abbastanza complesso utilizzando Mule , con buoni risultati.

Un'alternativa a ESB sarebbe utilizzare solo un framework MQ. Ad esempio, OpenMQ

    
risposta data 21.02.2012 - 20:02
fonte