SOA e database condivisi

Non capisco SOA (Service-oriented Architecture) e database. Mentre sono attratto dal concetto SOA (incapsulando la logica aziendale riutilizzabile in servizi) non riesco a capire come dovrebbe funzionare se le tabelle dati incapsulate in un servizio sono richieste da altri servizi/sistemi --- oppure è adatto per SOA del tutto in questo scenario?SOA e database condivisi

Per essere più concreto, supponiamo di avere due servizi:

CustomerService: contiene la mia tabella Customers di database e la logica di business associati.
OrderService: contiene la tabella e la logica Orders.

Ora che cosa se ho bisogno di JOIN le tabelle Customers e Orders con un'istruzione SQL? Se le tabelle contengono milioni di voci, le prestazioni inaccettabili risulterebbero se dovessi inviare i dati sulla rete utilizzando SOAP/XML. E come eseguire lo JOIN?

Facendo una piccola ricerca, ho trovato alcune soluzioni proposte:

Use replication per fare una copia locale dei dati richiesti dove necessario. Ma poi non c'è incapsulamento e allora qual è il punto di usare SOA? Questo è discusso on StackOverflow ma non c'è un chiaro consenso.
Impostare un Master Data Service che incapsula tutti i dati del database. Immagino che otterrebbe dimensioni di mostro (con essenzialmente una chiamata API per ogni stored procedure) e richiedono aggiornamenti per tutto il tempo. Per me questo sembra legato al concetto enterprise data bus.

Se avete qualche input su questo, per favore fatemelo sapere.

Edit: È passato un anno, e il mio interesse per la SOA è diminuita, come è la popolarità del concetto in generale. Al giorno d'oggi, le persone sembrano voler concentrarsi sui servizi RESTful.

fonte

2011-11-16 Gruber

La modifica rende assolutamente zero senso. I servizi RESTful sono una questione di progettazione dell'API e la presenza di singoli servizi spinge in realtà le cose verso SOA. Quindi il tuo commento sul passaggio da SOA a REST è come dire di passare dal mangiare banane all'utilizzo di sveglie. – Max

Grazie per l'input, ma non sono sicuro di essere d'accordo con te. Sin dagli albori dell'evoluzione dell'architettura orientata ai servizi (SOA), la SOA è stata confrontata e contrapposta al modello dell'interfaccia RESTful. [SearchSOA] (http://searchsoa.techtarget.com/tip/SOA-and-RESTful-interfaces-When-why-the-should-be-combined) - Gruber 24 minuti fa – Gruber

Controlla anche questo: http: // martinfowler.com/articles/enterpriseREST.html#bounded-contexts –

Uno dei principali che definiscono un "servizio" in questo contesto è che possiede, assolutamente, che i dati nell'area in cui è responsabile, nonché le operazioni su quei dati.

La copia dei dati, tramite la replica o qualsiasi altro meccanismo, elimina tale responsabilità. O replichi anche le regole aziendali o finirai per finire in una situazione in cui ti ritroverai a dover aggiornare l'altro servizio per modificare le regole interne.

L'utilizzo di un singolo servizio dati è solo "non fare SOA"; se disponi di un unico luogo che gestisce tutti i dati, non disponi di servizi indipendenti, hai solo un servizio.

Suggerirei, invece, la terza opzione: utilizzare la composizione per mettere insieme i dati, evitando completamente l'operazione JOIN del livello di database.

Invece di pensare a dover unire questi due valori insieme nel database, pensate a come comporre insieme ai bordi:

Quando si esegue il rendering di una pagina HTML per un cliente, è possibile fornire HTML da più servizi e li compongono visivamente l'un l'altro: i dettagli del cliente provengono dal servizio clienti e i dettagli dell'ordine dal servizio ordini.

Allo stesso modo un indirizzo email di fatturazione: comporre i dati forniti da più servizi visivamente, senza richiedere l'unione nel database.

Questo ha due vantaggi: uno, si elimina la necessità di unirsi al database e anche la necessità di avere i dati memorizzati nello stesso tipo di database. Ora ogni servizio può utilizzare qualunque archivio dati sia più appropriato per le loro necessità.

Due, è possibile modificare più facilmente l'esterno dell'applicazione. Se si dispone di parti piccole e componibili, è possibile aggiungere facilmente le parti in nuovi modi.

fonte

2011-11-17 03:30:57

Cercando gli indizi non ho trovato la tua idea --- è un approccio interessante. Se potessi eliminare la necessità di "UNIRE", il problema originale non si presenterebbe. Tuttavia, nel mio caso il 'JOIN' sembra difficile da aggirare perché il risultato di esso non è inteso per scopi di presentazione. Ma ci penserò. Qualcosa di cruciale che si sottolinea è che ** un servizio deve possedere i propri dati ** e le operazioni associate. C'è stato disaccordo su ciò in [altri thread] (http://stackoverflow.com/questions/4019902/soa-joining-data-across-multiple-services). Grazie per la risposta! – Gruber

Udi Dahan ha un blog qui: http://www.udidahan.com/ - il suo lavoro è stato di valore inestimabile nel plasmare le mie opinioni sull'argomento, e qui troverai molte più informazioni preziose. –

Stai suggerendo che il servizio clienti può accedere solo ai dati del cliente e il servizio ordini può accedere solo ai dati dell'ordine? Non ho visto alcuna menzione di questo nei libri di Thomas Erl? Per favore, potresti fornire un riferimento? –

Il principio guida è che è possibile memorizzare dati immutabili nella cache Ciò significa che nel servizio ordini possono esistere dati immutabili semplici dall'entità cliente e non è necessario rivolgersi al servizio clienti ogni volta che si richiedono le informazioni. Rompendo tutto su servizi isolati e poi effettuando sempre queste chiamate a procedure remote ignora il fallacies of distributed computing. Se si dispone di ampie esigenze di reporting è necessario creare un servizio aggiuntivo. Io chiamo il servizio di aggregazione dei rapporti, che, di nuovo, ottiene i dati di sola lettura a scopo di segnalazione. È possibile vedere un articolo

fonte

2011-11-18 10:30:47

Ho letto il tuo articolo. Ottima lettura. Immagino che il caching dei dati di altri servizi combinato con il meccanismo basato sugli eventi che descriveresti funzionerebbe. Per i servizi i cui dati non cambiano spesso penso che potrei farla franca lasciando che i servizi aggiornino le loro cache una volta ogni notte, il che porterebbe via la complessità della gestione degli eventi. – Gruber

Si potrebbe voler controllare modelli complementari come CQRS http://martinfowler.com/bliki/CQRS.html –

Nella domanda SO citata, varie persone dichiarano che è OK per un servizio accedere ad altri dati di servizi, quindi il servizio Ordine potrebbe avere una funzionalità GetAllWithCustomer, che restituirebbe tutti gli ordini insieme ai dettagli del cliente per quell'ordine.

Inoltre, questa mia domanda può essere utile:

https://softwareengineering.stackexchange.com/questions/115958/is-it-bad-practice-for-services-to-share-a-database-in-soa

fonte

2011-12-01 13:29:58

Grazie. Sembra che le persone abbiano opinioni diverse su questo. Se io, per esempio, replica la tabella di dati 'CustomerService'' Clienti' (per motivi di prestazioni) a 'OrderService', mi ritrovo con un problema" spaghetti "se il design di' Customers' deve cambiare --- I quindi devi aggiornare il codice di 'OrderService'. E con SOA è ciò di cui voglio allontanarmi. – Gruber

@ user1035411 Non penso che dovresti replicare i dati. Penso solo che al servizio Ordine dovrebbe essere consentito l'accesso ai dati dei Servizi clienti. Un'altra cosa da considerare è che si potrebbe desiderare una tabella clienti per il servizio Ordine che contenga dati dei clienti rilevanti solo per il servizio ordini. Il nome cliente verrebbe utilizzato da molti servizi, in modo tale da rimanere nel cliente. ma il limite di credito potrebbe essere un candidato per il servizio di ordine? Ciò impedirebbe al design dei clienti di cambiare troppo spesso. –

Voglio onorare il principio SOA secondo cui i servizi parlano solo attraverso le loro interfacce, quindi non devo mai aggiornare altri servizi se ne viene modificato uno internamente. Sono d'accordo con te che i servizi potrebbero aver bisogno di memorizzare i dati di altri servizi. Il problema sono le prestazioni e come aggiornare i dati memorizzati nella cache. Il recupero di grandi quantità di dati tramite SOAP/XML produce un pesante carico di rete, mentre la replica di solito è abbastanza liscia. Dal momento che la replica rompe il principio SOA, penso che proverò dall'altra parte e, come suggerisci, memorizzerò solo una quantità minima di dati. – Gruber

risposta

Problemi correlati