Request - Reply vs Publish-subscribe

Naviga le tue risposte
4

Stiamo lavorando a un'integrazione tra due sistemi di grandi dimensioni. Sistema A è un database con dati dei dipendenti e Sistema B è un sistema esterno utilizzato per il contatto quotidiano con i clienti (ad esempio riunioni, posizione, ordine di lavoro, lavoro stato e così via). Ci schiereremo un ESB nel mezzo.

Esistono 3 istanze di Sistema A e 1 istanza di Sistema B. Ciò è dovuto a restrizioni legali e non possiamo avere tutti i dati del Sistema A nello stesso database.

Nel sistema B abbiamo 20-30 contatti attivi ogni giorno, in cui vengono utilizzati continuamente alcuni dati del sistema A.

Abbiamo bisogno di aggiornare riunione, posizione e stato di lavoro nel Sistema B durante il giorno. E hanno due soluzioni proposte per l'integrazione di questi sistemi.

Soluzione A: Publish-Subscribe: il sistema A invia messaggi di aggiornamento (basati sugli standard ADL HL7) e l'istanza di System B preleva i dati a loro relativi. Questo viene fatto come trasmesso e genererà 1000-10000 messaggi al giorno. Invierà informazioni dal Sistema A a tutti i dipendenti, generando così un messaggio per ogni dipendente nel Sistema A (1,2,3). Esiste solo un sottoinsieme di dipendenti del Sistema A che è "attivo" e interessante per gli aggiornamenti nel Sistema B. Ma i messaggi fluiranno su TUTTI i dipendenti poiché i dati vengono aggiornati anche da altri sistemi.

Soltion B: Il sistema B richiede informazioni aggiornate attraverso una soluzione di richiesta-risposta. Genera chiamate vuote, ma chiederà solo che i dipendenti "siano attivi" nel sistema B in un dato giorno.

Commenti sulle soluzioni? Vantaggi svantaggi? Qual è la soluzione "pesante" più infrastrutturale tra questi due?

Spero che ci sia qualcuno là fuori che potrebbe darmi qualche suggerimento:)

    
posta kincaid 05.06.2013 - 11:07
fonte

3 risposte

4

La Soluzione B funziona solo se richiedi i dati dal Sistema A ogni volta che è richiesto dal Sistema B. Altrimenti non puoi garantire che le informazioni siano aggiornate. Non è così male come sembra ed è in effetti la base di tutte le architetture SOA.

La decisione se spingere (Soluzione A) o tirare (Soluzione B) dipende dal rapporto tra gli aggiornamenti nel sistema A e il numero di query nel Sistema B.

Dove ci sono molti aggiornamenti nel sistema A rispetto ad alcune query nel sistema B, allora "pull" è la scelta più ovvia.

Dove hai relativamente pochi aggiornamenti nel sistema A e molte query nel sistema B, allora "push" è la strada da percorrere.

Se disponi di molti aggiornamenti e molte query, la scelta è ugualmente buona (o cattiva!).

    
risposta data 07.06.2013 - 04:00
fonte
2

Dato che stai usando System B in tempo reale, dovresti scegliere qualsiasi architettura tecnicamente implementabile, che ti fornisca i dati più aggiornati nel Sistema B, mentre usi meno risorse.

È necessario esaminare i dettagli di implementazione della Soluzione A e B, e vedere che cosa offre un migliore dato corrente al consumo di risorse (memoria, CPU). Idealmente avresti un servizio di pubblicazione sul sistema A per record, che informa System B quando un singolo record nel sistema A è stato modificato ... ma questa non è una delle soluzioni proposte.

    
risposta data 06.06.2013 - 16:29
fonte
1

Se gli aggiornamenti passano solo da A a B, B può semplicemente memorizzare dati da A. B dovrebbe solo leggere i dati da A quando necessario e non è necessario che A invii i dati (pubblica) senza che venga richiesto. Quindi devi gestire cosa fare con la cache stantia (A è stato aggiornato dall'ultima volta che B è stato aggiornato). Ma cosa succede se B ha bisogno di dati solo quando A è stato aggiornato? B può chiedere periodicamente A se c'è un aggiornamento dall'ultimo controllo di B, e ottenere solo le entità aggiornate.

R. Fielding ha rilasciato commenti sul motivo per cui pub / sub non è scalabile qui: link che da dove ottengo la mia risposta.

    
risposta data 07.06.2013 - 03:51
fonte

Leggi altre domande sui tag

Ho bisogno dei test JUnit per il livello controller su un MVC quando ho un livello database quando è necessario o quando un controller deve essere asincrono