Data Access Layer con servizi asincroni come MQ

3

Ho il compito di creare una guida allo sviluppo, alla progettazione e all'architettura per un grande progetto pluriennale. Devo dettare le migliori pratiche di progettazione per un certo numero di prospettive architettoniche. Vedi il seguente diagramma per dimostrare come vedo questo aspetto.

Pertanto,sullabasedialtrirequisitiarchitetturali,iserviziasincronibasatisuMQsonopreferitiacausadellaconsegnagarantitadeimessaggieperchénontuttiicomponentibusiness-criticalgarantisconoladisponibilitàelevata.LamiaesperienzanellosvilupporispettoalleinterfacceMQerapiuttostobassaenoninun COA transazionale. design. Generalmente svilupperei più thread che verificherebbero regolarmente la presenza di nuovi messaggi da elaborare, entrambi i messaggi da inserire in una coda per le richieste, mantenendo temporaneamente lo stato, quindi un altro thread che consumerà le risposte da un'altra coda.

Quando si considera un'architettura in stile COA con un livello di accesso ai dati chiaramente definito e un livello Business Logic, in che modo le origini dati asincrone vengono rappresentate o implementate qui in genere? In genere, è logico che un livello di accesso ai dati fornisca un'interfaccia a Business Logic in cui l'origine dati è un servizio Web basato su REST o SOAP. Questi servizi sono sincroni, ricevono una richiesta e la elaborano immediatamente, quindi restituiscono una risposta mentre il client attende un tempo prestabilito per riceverlo.

Le richieste asincrone potrebbero non essere elaborate immediatamente, inoltre potrebbero non restituire una risposta soddisfacente. MQ garantisce solo che il componente target alla fine riceverà il messaggio di richiesta, non garantisce che restituirà una risposta.

Mi sembra che il modo migliore per gestire questo è avere due interfacce separate richieste dal livello di accesso ai dati, interfaccia di richiesta e interfaccia di risposta. Un lavoro batch pianificato che utilizza quindi il componente Business Logic potrebbe essere in grado di gestirlo efficacemente utilizzando più thread, tuttavia potrebbe esserci un altro componente che richiede un'interfaccia sincrona in tempo reale del nostro componente Business Logic in cui ci viene richiesto di interfacciare tramite MQ non è in tempo reale.

Sono confuso su come conciliare i due. È questo il modello di design giusto qui? Come posso fornire efficacemente un'interfaccia a un componente che richiede tempo reale quando il mio componente richiede un'interfaccia asincrona?

Note:

Alcuni articoli pertinenti che ho letto:

Sembra che questa situazione sia già definita come un Anti-Motivo architettonico chiamato Sincronizzazione su Asincrona . Per me è chiaro che leggere questa gente sta dicendo che è un'idea straordinariamente cattiva. Poi altri notano che a volte non abbiamo scelta e dobbiamo fare ciò in cui mi sto trovando. Non sono in grado di chiedere un'interfaccia sincrona per cercare e cercare i servizi per questo unico sistema, e non ho voce in capitolo con gli altri componenti richiesti per un servizio di ricerca e ricerca sincrona.

    
posta maple_shaft 29.10.2014 - 15:22
fonte

2 risposte

1

Forse puoi progettare la tua interfaccia tra business e livello dati in modo asincrono? Un componente del livello dati avrebbe accesso alla 'asincronia' sottostante di MQ, l'altro componente sarebbe stato sincronizzato asincrono-in-sincronizzazione al Database attraverso JDBC

    
risposta data 30.10.2014 - 08:19
fonte
0

Suppongo che il tuo livello di sicurezza sia racchiuso all'interno del componente Generic Data Access . Il primo pensiero che mi è venuto in mente quando ho visto il tuo progetto è stato "perché i sistemi affidabili accedono al livello dati nello stesso modo in cui sono sistemi non attendibili?"

Il design che stai progettando sembra qualcosa che un ambiente assicurativo, finanziario o persino commerciale vorrebbe usare.

Il tuo livello attendibile, che è il batch e i componenti sincroni in tempo reale, viene generalmente utilizzato per le operazioni di creazione, aggiornamento ed eliminazione che possono influire sui dati sottostanti.

Il tuo livello non affidabile, che comprende i widget, è generalmente limitato alle operazioni di tipo di rapporto.

Come si chiama, la complessità nella progettazione è che le richieste arrivano attraverso metodi sincroni e asincroni. Uno dei vantaggi dell'utilizzo di Websphere MQ come intermediario per le chiamate asincrone è che i client WMQ possono ascoltare messaggi specifici su una coda di ritorno tramite un ID di correlazione. Altri server MQ più leggeri generalmente non forniscono questa funzionalità.

Un altro aspetto interessante di WMQ è che ha un sistema di gestione delle code inanimate davvero robusto. Inevitabilmente, riceverai risposte consegnate in ritardo. Il sistema DLQ ti aiuterà a tracciare quelli e capire perché stanno accadendo.

Penso che tu abbia ragione a essere preoccupato di come i widget si interfacciano con il componente Generic Data Access . La sfida principale è che ti stai impostando per interfacce personalizzate per ogni widget. Ora può essere gestibile, ma l'esperienza e il senno di poi dicono che ce ne saranno sempre di più.

Per semplificare le cose a livello di accesso ai dati, ti consiglio di fare in modo che tutte le richieste di widget vengano eseguite attraverso un livello basato su WMQ. Tutte le richieste in entrata vengono messe in coda e le risposte vengono inserite in una coda di risposta con un ID di correlazione.

Il vantaggio qui è che il tuo componente Generic Data Access ha solo 2 mezzi di accesso. I sistemi affidabili ottengono l'accesso diretto al livello. Tutti gli altri passano attraverso le code basate su WMQ. Un vantaggio di questo è che è banale continuare ad aggiungere client WMQ in grado di inviare richieste a nome di futuri widget.

Ma aspetta! potresti dire. Ci sono widget che si aspettano risposte sincrone e che eseguirli attraverso una coda influiranno su questo. È vero, ma a un certo punto del tuo progetto dovresti affrontare quel mismatch del protocollo di comunicazione da qualche parte.

Raccomando di inserire quella mancata corrispondenza tra i tuoi client MQ in quanto mantiene la logica all'interno del componente Generic Data Access semplificato. Detto in altro modo, lo strato di accesso ai dati non è responsabile della gestione del disadattamento di impedenza. È responsabilità del cliente eseguire l'accesso.

Sebbene questo possa sembrare complicare l'API per i client sincroni, in realtà espone qualcosa che potrebbe essere altrimenti nascosto. _Somewhere _ nel tuo percorso di accesso ai dati, qualcosa potrebbe essere disconnesso e i client upstream devono essere in grado di gestire un timeout / nessuna risposta. Utilizzando un client MQ e dichiarando esplicitamente all'interno dell'API "questo timeout in 1 minuto", il client upstream deve riconoscere tale situazione e gestirla di conseguenza.

Per inciso, usare un client WMQ per le mancate corrispondenze del protocollo è un buon modo per andare. Tutto il codice di rettifica è incapsulato all'interno di un particolare livello e la tua capacità di riutilizzare quel livello aumenta a causa dell'astrazione che ti fornisce. E anche se non riesci a riutilizzare completamente il codice WMQ a causa delle diverse chiamate API, puoi comunque riutilizzare il codice di rettifica del protocollo di comunicazione.

E come ultima considerazione, l'uso di un livello WMQ per l'accesso a tutti i widget rende più semplice scalare il tempo di risposta del livello di accesso ai dati. Man mano che aumenta il volume delle richieste, puoi sempre aggiungere altri thread del gestore code all'interno del livello di accesso ai dati.

Per riepilogare ...

Fai in modo che tutti i widget passino attraverso un livello di accesso basato su coda Websphere MQ per richiedere dati dal tuo negozio centrale. In questo modo si estrae l'interfaccia esterna al livello di accesso ai dati e il disaccoppiamento che fornisce renderà più semplice l'adattamento alle modifiche future.

    
risposta data 30.10.2014 - 15:58
fonte

Leggi altre domande sui tag