Integrazione tra servizi in una SOA

Question

Integrazione tra servizi in una SOA

#1 da (1 voti)

3

Supponiamo di avere un Contesto Limitato per Inventario (InventoryBC) e un altro per Spedizioni (SpedizioniBC). Questi 2 BC devono comunicare insieme. Sono ospitati su 2 diversi servizi su server diversi con database diversi.

Quando viene effettuata una spedizione, potrei aver bisogno di recuperare alcuni dati dall'inventario BC, quindi penso che una richiesta REST GET dovrebbe risolverla. Tuttavia, quando viene effettuata una spedizione ho bisogno di diminuire l'inventario in modo che un evento "ShipmentCompleted" faccia il trucco.

Tuttavia, cosa succede se uno dei servizi non funziona? Le scritture non vengono perse in quanto verranno conservate in coda fino al loro consumo, ma per quanto riguarda le letture? No reads = niente funziona

Questo stile di integrazione funziona nella pratica o esiste un approccio migliore per un sistema più scalabile e liberamente accoppiato?

design domain-driven-design architecture web-services soa

posta Songo 16.01.2015 - 12:40

fonte

1 risposta

Leggi altre domande sui tag design domain-driven-design architecture web-services soa

Un modo per usare VoltDB nell'app per rails? Qual è il modo "corretto" per memorizzare le funzioni in un database?

score 1 · Answer 1

Se posso riformulare la tua domanda, stai chiedendo "cosa succede al mio sistema se qualcosa si rompe?" Bene, la risposta breve è che il tuo sistema non funziona più correttamente. Questo succede sempre in sistemi complessi. Il grado in cui si sperimentano funzionalità degradate dipenderà da cosa si è rotto e quanto sia importante. Ad esempio, quando la navetta spaziale volava, c'erano alcuni punti nella traiettoria di volo in cui si poteva perdere un motore e ancora arrivare in orbita. Altri luoghi nella traiettoria hanno significato un ritorno all'abbandono del sito di lancio, mentre altri ancora hanno significato lo sbarco attraverso l'Atlantico (molto probabilmente Saragozza, Spagna).

Nel tuo caso specifico, il sistema non sembra essere così complesso. Nondimeno, in qualsiasi sistema, ci saranno parti che sono più critiche di altre. I database nei sistemi di computer sono spesso progettati in punti in cui possono essere un singolo punto di errore. Può essere estremamente costoso e non necessario progettare questi SPF fuori dal sistema, quindi è necessario vivere con la probabilità che il sistema si guasti di tanto in tanto. Buone pratiche di progettazione, incluso l'utilizzo di database federati e più aree geografiche, possono ridurre questo rischio.

Penso che tu abbia il giusto approccio: avere molti piccoli pezzi autonomi con limiti di interfaccia molto limitati è il modo migliore per garantire l'affidabilità complessiva del sistema.