Consigli su Come migrare una gigantesca applicazione java monolitica verso qualcosa orientata al servizio

4

Mi trovo di fronte al problema della migrazione di un'enorme applicazione web java monolitica verso un approccio più orientato ai servizi. L'applicazione è cresciuta per anni da ciò per cui era originariamente progettata e continua a crescere. Ciò significa un sacco di modifiche ai clienti in cui lo sviluppo è sotto pressione, con poche preoccupazioni sulla qualità del codice. Ciò ha portato a una struttura di codice molto molto complessa (nessun packaging modulare, molti elementi ereditari complessi, un mix di funzionalità nelle classi e buono come nessuna documentazione).

Ora la funzionalità passo passo deve essere estratta ed eseguita come servizio.

Sostituzione / Riqualificazione è al momento senza domande. Quindi il codice dovrebbe essere estratto e spostato in modo che possa essere sostituito in seguito con una nuova versione più pulita.

Il problema che ora devo affrontare è che è davvero difficile identificare il codice che rappresenta una funzionalità ed estraendolo senza rompere altre funzionalità o persino l'intera applicazione.

Qualche idea su come posso affrontare questo problema? Sono aperto a tutto.

    
posta Tarken 22.08.2012 - 11:40
fonte

3 risposte

6

Costruisci e definisci accuratamente un'API, o un insieme di API diverse, se necessario, quindi implementale semplicemente avvolgendo le richieste in questa webapp (e / o pacchetti che sono usati da questa webapp).

Questo ti aiuterà a "multithread" dopo lo sviluppo. Potrai sia creare nuovi strumenti, che utilizzeranno la tua nuova API, sia, allo stesso tempo, iniziare a cambiare gradualmente l'implementazione dell'API, eliminando così la vecchia webapp.

Dividi e conquista, nulla è cambiato dai tempi dei romani:)

    
risposta data 22.08.2012 - 12:01
fonte
3

Il modo principale per raggiungere questo obiettivo è innanzitutto identificare i livelli di cesoiatura - quelle parti che sembrano leggermente meno saldamente incorporate nel resto dell'app. Ad esempio, l'accesso ai database, che richiama un sistema esterno, è quindi il luogo ideale in cui cercare la sostituzione con le chiamate SOA.

Successivamente puoi guardare le aree più grandi che sono più modulari e sostituirle con una chiamata SOA esterna. Stai praticamente suddividendo il codice monolitico nel modo migliore possibile in blocchi a cui si accede tramite una SOA piuttosto che una normale chiamata di metodo. Potrebbe essere necessario assicurarsi che alcuni dei moduli sostituiti siano racchiusi in classi che assomigliano al vecchio in modo che il resto della vecchia app non sappia che qualcosa è cambiato, solo che gli interni ora chiamano un sistema esterno piuttosto che un codice interno.

Una volta completato tutto ciò, avrai una base di codice più piccola, ma sarà comunque disordinata e monolitica. A quel punto, devi davvero sporcarti e cambiare il modo in cui funziona il codice, dovrai iniziare a cambiare la GUI o la maggior parte di esso in modi più intrusivi, prendere una parte che si trova ai margini del programma principale e inizia da lì, una volta che ne hai fatto alcuni, diventerà più facile.

    
risposta data 22.08.2012 - 11:56
fonte
0

Devi creare un'API che esponga i metodi di quanti ne possano fare nei servizi SOAP.

Altre app possono utilizzare le tue funzionalità.

La tua app attuale può continuare a esistere anche se consiglierei di rifattarla per chiamare le funzioni API (non è necessario SOA qui).

SOA serve per condividere utili logiche di business tra le applicazioni. Ma ciò non significa che l'app che ha originato la logica di bussiness debba utilizzare SOA per utilizzare la propria logica di business. Quell'app potrebbe utilizzare SOA per consumare la logica di bussiness degli altri.

    
risposta data 22.08.2012 - 17:46
fonte

Leggi altre domande sui tag