Il modo migliore per integrare diversi sistemi?

Question

Ok, dove lavoro, abbiamo un numero abbastanza consistente di sistemi scritti negli ultimi due decenni che manteniamo.

I sistemi sono diversi in quanto più sistemi operativi (Linux, Solaris, Windows), database multipli (diverse versioni di Oracle, Sybase e MySQL) e persino più lingue (C, C ++, JSP, PHP e una serie di altri) vengono utilizzati.

Ogni sistema è abbastanza autonomo, anche a costo di inserire gli stessi dati in più sistemi.

La direzione ha recentemente deciso che dovremmo studiare cosa servirà per far dialogare felicemente tutti i sistemi e condividere i dati.

Tieni presente che mentre possiamo apportare modifiche al software a uno qualsiasi dei singoli sistemi, una riscrittura completa di uno o più sistemi non è qualcosa che la gestione è in grado di intrattenere.

Il primo pensiero di alcuni degli sviluppatori qui è stato il semplice: se il sistema A ha bisogno di dati dal sistema B, dovrebbe semplicemente connettersi al database del sistema B e ottenerlo. Allo stesso modo, se deve fornire dati B, dovrebbe semplicemente inserirlo nel database B.

A causa del caos dei database (e delle versioni) utilizzati, altri sviluppatori erano del parere che avremmo dovuto avere un nuovo database, combinando le tabelle di tutti gli altri sistemi per evitare di destreggiarsi tra più connessioni. In questo modo sperano che potremmo essere in grado di consolidare alcune tabelle e di eliminare l'immissione di dati ridondanti.

Questo è il momento in cui sono stato chiamato per la mia opinione su tutto il casino.

L'intera idea di utilizzare il database come mezzo di comunicazione del sistema ha un odore divertente per me. La logica aziendale dovrà essere collocata in più sistemi (se il Sistema A vuole aggiungere dati al Sistema B capirà meglio le regole di B relative ai dati prima di effettuare l'inserimento), molto probabilmente molti sistemi dovranno fare una qualche forma di polling del database per trovare eventuali modifiche ai loro dati, la manutenzione continua sarà un mal di testa, poiché qualsiasi modifica a uno schema di database ora propaga diversi sistemi.

Il mio primo pensiero è stato quello di dedicare tempo e scrivere API / servizi per i diversi sistemi, che una volta scritti potevano essere facilmente utilizzati per passare / recuperare i dati avanti e indietro. Molti altri sviluppatori ritengono che sia eccessivo e molto più lavoro rispetto al semplice utilizzo del database.

Quindi quale sarebbe il modo migliore per far dialogare questi sistemi?

Answer 1

L'integrazione di sistemi diversi è il mio lavoro quotidiano.

Se fossi in te, farei il possibile per evitare di accedere ai dati del sistema A direttamente dal sistema B. Aggiornamento Il database del sistema A dal sistema B è estremamente poco saggio. È esattamente l'opposto della buona pratica rendere la tua logica aziendale così diffusa. Finirai per pentirti.

L'idea del database centrale non è necessariamente negativa ... ma lo sforzo richiesto è probabilmente entro un ordine di grandezza nel riscrivere i sistemi da zero. Non è certo qualcosa che tenterei, almeno nella forma che descrivi. Può avere successo, ma è molto, molto più difficile e richiede molta più disciplina dell'approccio di integrazione punto-punto. È divertente sentirlo suggerire nello stesso respiro dell'approccio "da cowboy" di trasferire i dati direttamente in altri sistemi.

Nel complesso il tuo istinto sembra piuttosto buono. Ci sono un paio di approcci. Ne citi uno: implementare i servizi. Non è un brutto modo di procedere, soprattutto se hai bisogno di aggiornamenti in tempo reale. L'altra è un'applicazione di integrazione separata che è responsabile del riordino dei dati. Questo è l'approccio che di solito adotto, ma di solito perché non riesco a cambiare i sistemi che sto integrando per chiedere i dati di cui ha bisogno; Devo inserire i dati. Nel tuo caso l'approccio dei servizi non è male.

Una cosa che vorrei dire che potrebbe non essere ovvio per qualcuno che arriva all'integrazione di sistema per la prima volta è che ogni pezzo di dati nel tuo sistema dovrebbe avere un unico, autorevole punto di verità. Se i dati sono duplicati (e sono duplicati) e le copie non sono d'accordo tra loro, la copia nel punto di verità per quei dati deve essere considerata corretta. Non c'è altro modo per integrare i sistemi senza che la complessità urli verso il cielo a un ritmo esponenziale. L'integrazione degli spaghetti è come il codice degli spaghetti e dovrebbe essere evitata a tutti i costi.

Buona fortuna.

EDIT:

Il middleware affronta il problema del trasporto, ma questo non è il problema centrale nell'integrazione. Se i sistemi sono abbastanza vicini da consentire a un'app di trasferire i dati direttamente a un'altra, è probabile che siano abbastanza vicini da poter chiamare direttamente un servizio offerto da un'altra. Non consiglierei il middleware nel tuo caso. Potresti trarne qualche vantaggio, ma ciò sarebbe compensato dalla maggiore complessità. Devi risolvere un problema alla volta.

Answer 2

Sembra che potresti voler indagare Accodamento messaggi e middleware orientato ai messaggi .

MSMQ e Java Message Service essendo esempi.

Answer 3

Sembra che tu stia cercando opinioni, quindi fornirò le mie.

Concordo con gli altri sviluppatori che scrivere un'API per tutti i diversi sistemi sia eccessivo. Probabilmente lo faresti più velocemente e avresti molto più controllo su di esso se prendessi solo l'altro suggerimento di creare un singolo database.

Answer 4

Una delle sfide che dovrai affrontare è allineare i dati in ciascuno dei diversi sistemi in modo che possano essere integrati in primo luogo. È possibile che ciascuno dei sistemi che si desidera integrare contenga insiemi di dati completamente diversi, ma è più probabile che si tratti di dati che si sovrappongono. Prima di immergermi nella scrittura di API: s (che è il percorso che prenderei anche data la tua descrizione) ti consiglio di provare a trovare un modello logico di dati per i dati che devono essere integrati. Questo modello di dati ti aiuterà quindi a sfruttare i dati che hai nei diversi sistemi e renderli più utili agli altri database.

Consiglio vivamente anche un approccio iterativo all'integrazione. Con i sistemi legacy c'è così tanta incertezza che cercare di progettare e implementare tutto in una volta è troppo rischioso. Inizia in piccolo e raggiungi un sistema ragionevolmente integrato. " Completamente integrato " non vale quasi mai la pena puntare.

Answer 5

L'interfaccia diretta tramite database push / poking espone molti dettagli interni di un sistema all'altro. Ci sono ovvi svantaggi: l'aggiornamento di un sistema può rompere l'altro. Inoltre, ci possono essere limiti tecnici nel modo in cui un sistema può accedere al database dell'altro (considera come un'applicazione scritta in C su Unix interagirà con un database SQL Server 2005 in esecuzione su Windows 2003 Server).

La prima cosa che devi decidere è la piattaforma in cui il "database principale" risiederà, e lo stesso per il middleware che fornisce la colla tanto richiesta. Invece di andare verso l'integrazione di middleware a livello di API (come CORBA), ti suggerirei di considerare Middleware orientato ai messaggi. MS Biztalk, eGate di Sun e Fusion di Oracle possono essere alcune delle opzioni.

La tua idea di un nuovo database è un passo nella giusta direzione. Potresti leggere un po 'il modello Enterprise Entity Aggregation .

Una combinazione di "integrazione dati" con un middleware è la strada da percorrere.

Answer 6

Se stai andando verso la strategia Middleware + Single Central Database, potresti prendere in considerazione l'idea di raggiungere questo obiettivo in più fasi. Ecco un processo graduale logico che può essere considerato:

1. Implementazione di servizi / API per sistemi diversi che espongono le funzionalità per ciascun sistema
2. Implementazione del Middleware che accede a queste API e fornisce un'interfaccia a tutti i sistemi per accedere ai dati / servizi da altri sistemi (accede ai dati dalla fonte centrale se disponibile, altrimenti li ottiene da un altro sistema)
3. Implementazione del solo database centrale, senza dati
4. Implementazione dei servizi di memorizzazione nella cache / archiviazione dei dati a livello di middleware che possono archiviare / memorizzare nella cache i dati nel database centrale ogni volta che si accede a tali dati da uno qualsiasi dei sistemi, ad es. Se i record 1-5 del sistema A vengono recuperati dal sistema B tramite Middleware, i servizi di memorizzazione nella cache dei dati Middleware possono archiviare questi record nel database centralizzato e la prossima volta che questi record verranno recuperati dal database centrale
5. La pulizia dei dati può avvenire in parallelo
6. Puoi anche creare un meccanismo di importazione per trasferire quotidianamente i dati da più sistemi al database centrale (automatizzato o manuale)

In questo modo, lo sforzo viene distribuito su più pietre miliari e i dati vengono gradualmente archiviati nel database centrale in base al primo accesso al primo archiviato.