Come si inserisce ETL (database nel database) in SOA?

Question

Immaginiamo, che la nostra applicazione abbia bisogno dei dati ETL (estrazione, trasformazione, caricamento) dal database delle relazioni a un altro database delle relazioni. Il modo più semplice (e la maggior parte delle prestazioni, IMHO) è quello di creare un collegamento tra i database e scrivere una semplice stored procedure. In questo caso utilizziamo tecnologie e componenti minimi, tutte le funzionalità sono "pronte all'uso".

Ma è una buona pratica per SOA (architettura orientata ai servizi)? Che dire dell'accoppiamento stretto? Accoppiamo strettamente i database tra loro per sempre?

C'è un altro modo per farlo: costruiamo 2 applicazioni java su ciascun lato e comunichiamo tramite i servizi Web SOAP. Questo è più SOA friendly! Ma il degrado delle prestazioni e altri punti di errore ne valgono la pena?

Quale sarà la migliore pratica in questo caso? In che modo ETL può essere inserito all'interno di SOA?

Answer 1

Tutte queste risposte sono buone e utili.

Come ora capisco, SOA non riguarda l'implementazione dell'applicazione, ma l'architettura ("A"), principalmente Enterprise Architecture. Il metodo di gestione principale dell'azienda è la delega di responsabilità per i servizi ("S").

Quindi, se nella struttura aziendale ci sono due diverse funzioni aziendali con due diversi account responsabili, dovremmo suddividerlo in due diversi servizi con contratti ben definiti (interfacce), politica e metodi di verifica: questo è lo scopo principale della SOA.

Ma se si tratta di una funzione atomica con una persona responsabile, non c'è bisogno di SOA così tanto e dovremmo usare semplici tecnologie e implementare un'applicazione di servizio solida semplice e rapida.

Per quanto riguarda la mia domanda iniziale, è la mancanza di informazioni sul contesto dell'attività. Ora capisco che i collegamenti ai database non devono essere implementati attraverso i servizi, ed è un cattivo design perché non ha compatibilità di gestione aziendale. Ma all'interno di un servizio può essere una buona soluzione semplice.

Grazie a tutti hanno risposto.

Answer 2

In SOA, è possibile adattare il modo di elaborazione Biztalk o SAP BusinessObjects Data Integrator. Fondamentalmente, è un lavoro di scheduler/windows service, o qualcosa di simile. Fornire due punti di servizio, 1 per lo scheduler per recuperare i dati e un altro per lo scheduler per l'invio dei dati. La responsabilità dello scheduler qui è solo quella di eseguire periodicamente e trasformare i dati.

Così, i passaggi fondamentali saranno:

Fase 1: La corsa di pianificazione e ottenere i dati dal servizio A

Scheduler --get--> Service A 
Service A --data--> Scheduler 

Fase 2: I dati di pianificazione facendo trasformazione

[ Conversion --> Conversion --> Conversion --> Conversion ] 

Passaggio 3: lo scheduler invia i dati a un altro servizio

Scheduler --data--> Service B 

In Biztalk e SAP BusinessObject Data Integrator, i passaggi sono configurabili (possono essere recuperati da qualsiasi servizio e possono eseguire la trasformazione dei dati di script), quindi è più flessibile.

Tuttavia, ci sono ancora problemi usuali che possono verificarsi con l'elaborazione ETL. Ad esempio: i dati sono troppo grandi, l'impatto sulle prestazioni della rete, le RTO, i dati duplicati, ecc. Quindi le best practice ETL sono ancora un requisito qui (uso della tabella di staging, registrazione, ecc.).

Ma il degrado delle prestazioni e altri punti di guasto ne vale la pena?

L'impatto sulle prestazioni si verificherà da quando si dispone di passaggio aggiuntivo di connessione/autenticazione (al servizio web) e passaggio di trasporto (da webservice a scheduler tramite protocollo). Ma a causa di errori, penso che sia lo stesso errore che è necessario gestire con altre chiamate di servizio.

Ne vale la pena? Dipende. Se stai lavorando nello stesso ambiente (stesso database), allora è discutibile. Se si sta lavorando in un ambiente diverso (ad esempio due sistemi diversi, da Asp.Net a SAP o almeno un'istanza di database diversa), questa architettura è la soluzione migliore per gestire ETL.

Answer 3

ETL in generale si inserisce in SOA - ad es. I servizi SOA possono eseguire operazioni ETL tra loro.

Il collegamento database-database è molto utile quando si desidera replicare database o in altre situazioni simili. In generale, questo approccio non ha nulla a che fare con SOA, a meno che non esistano i casi seguenti.

Il collegamento database-database non si adatta alla SOA quando entrambi i database vengono utilizzati dai servizi SOA. In questo caso, è necessario comunicare attraverso i servizi.

Il collegamento database-database si adatta ancora alla SOA quando un solo database è la persistenza per il servizio SOA. L'altro può essere considerato come un failover o una semplice replica, non direttamente correlato alla SOA. In questo caso, il collegamento da database a database diventa semplicemente un problema relativo ai dati, che è possibile avere e risolvere.

Answer 4

Per me ci sono diversi punti mancanti nel db - a - db e il resto a base di messa a punto: eccezioni nel processo di ETL:

Quando è la trasformazione dei dati considerati validi?
Come viene gestito il risultato di una trasformazione non riuscita?
La semplice eliminazione dei dati non è un'opzione nella maggior parte dei casi.
Errore/Ripristino del sistema
Cosa succede se uno/entrambi i sistemi non funzionano per un po '? Come viene gestita la sincronizzazione? Quando è fallito l'etl e dove deve essere riavviato?
Quindi, invece di dover utilizzare database o servizi di riposo, i servizi comunicano tra loro, questo è più correlato all'utilizzo di tecnologie di migrazione come Apache Camel o ESB in grado di gestire le trasformazioni, dividere i dati, elaborarli in modo asincrono, rimetterli indietro insieme, avere un monitoraggio adeguato, recupero, bilanciamento del carico per l'ottimizzazione delle prestazioni. Ciò non accelera necessariamente la "E" in etl, né la "L" (anche se potrebbe esserlo in entrambi), ma certamente accelera la "T" e ha risultati positivi per l'integrità dei dati.
E naturalmente: gli ESB sono tecnologie correlate alla SOA. Apache Camel per me non è in realtà se è considerata un'implementazione di riferimento di Enterprise Integration Patterns.

Fondamentalmente l'idea è che etl sono basati su contenuti e non su problemi di struttura.
Allora, cosa si potrebbe fare con queste tecniche è qualcosa di simile:
DB < - DataExtractor - Validator
- ContentLengthBasedRouter - Splitter
(Ansynch) - Transformer1,
- Transformer 2 ..
- Aggregator -
- ContentBasedRouter - Transformer3 -
- DataInserter
- Monitor
e di più, ma tha t non si adatta a una descrizione testuale.