Migrazione dell'applicazione CORBA alle moderne tecnologie Java (Rest/SOAP/EJB)

Question

È necessario migrare un sistema CORBA legacy a qualsiasi tecnologia java più recente. Il problema principale che sto affrontando è quello di fornire una transazione longeva (db) nel sistema proposto. Attualmente il client (Swing App) conserva l'oggetto di servizio CORBA ed esegue più db txn prima di eseguire effettivamente il commit/rollback di tutto il txn. Il livello di servizio mantiene lo stato dell'oggetto di connessione per completare la transazione.

Volevo riprodurre questo meccanismo nel mio nuovo sistema (REST/WS) in modo che il client/Web di Swing (futuro) possa funzionare nello stesso modo.

esempio:

try { 
    service1.updateXXData(); // --> insert in to table XX 
    service2.updateUUData() //--> insert in to table UU 
    service1.updateZZData(); // --> insert in to table ZZ 
    service2.updateAAData(); // --> insert in to table AA 

    service1.commit(); // con.commmit(); 
    service2.commit(); // con.commmit(); 

} 
exception(){ 
    service1.rollback(); // con.rollback(); 
    service2.rollback(); // con.rollback(); 
} 

Ora ho voluto migrare CORBA a qualsiasi technolgy moderna, ma ancora sono in generale di trovare una soluzione per questo. (la preoccupazione è che il cliente non voglia apportare alcuna modifica al livello di servizio o al livello db), volevano solo rimuovere CORBA.

paio di opzioni disponibili per me sono

1. Migrate CORBA per RMI -> in modo che le modifiche necessarie per sistema attuale sono minimi, ma la gestione delle transazioni, il pool di connessioni, mantenendo lo stato bisogno di fare la mia auto.

2. Migrare CORBA a EJB stateful -> Confrontare RMI più modifiche richieste, ma meglio poiché posso utilizzare il pool di connessioni gestite dal contenitore, mantenere lo stato in un modo migliore.

3. Migrate CORBA per Stateful Webservice (SOAP) -> più futuristico, ma molti cambiamenti richiesti - Come mai posso convertire IDL per WSDL e delegare la chiamata a livello di attuazione

4. Migrate CORBA per REST -> I più desiderati se possibile - ma la quantità di tempo necessaria per la migrazione è enorme, le modifiche al codice richiederebbero dal livello dell'interfaccia utente al livello di servizio.

Grazie mille in anticipo

Answer 1

L'ordine in cui vorrei scegliere le opzioni, dal migliore al peggiore, sarebbe 4, 3, 2 e 1, ma eviterei fagioli stateful o servizi se umanamente possibile farlo.

Vedrò i dettagli di implementazione di ciò che dovrete fare in dettaglio.

Per ognuna di queste soluzioni, è necessario utilizzare XA-compliant data sources and transactions in modo da poter garantire la conformità ACID, preferably from an application server so you don't have to generate the transaction yourself. Questo dovrebbe essere un miglioramento rispetto alla tua applicazione esistente in quanto quasi certamente non può garantirlo, ma tieni presente che, secondo la mia esperienza, la gente mette un sacco di hack per reinventare essenzialmente JTA, quindi fai attenzione.

Per 4, si desidera utilizzare container-managed transactions with XA. Potresti farlo da injecting a @PersistenceContext backed by a JTA connection. Sì, questo costa un sacco di tempo, test e sforzi, ma ha due bonus: in primo luogo, il passaggio al web sarà molto più semplice, e sembra che stia arrivando il momento. In secondo luogo, quelli che vengono dopo di voi hanno maggiori probabilità di essere ben versati nelle nuove tecnologie dei servizi Web rispetto a CORBA e RMI.

Per 3, è anche possibile utilizzare container-managed transactions with XA. SOAP non sarebbe la mia prima scelta in quanto utilizza messaggi molto prolissi e REST è più popolare, ma potrebbe essere fatto.Se è di stato, però, sarà necessario utilizzare bean-managed transactions instead e quindi hang on to resources across web service calls. Questo è pericoloso, in quanto potrebbe potenzialmente bloccare l'intero sistema.

Per 2, è possibile procedere in due modi, utilizzando container-managed transactions with XA utilizzando uno stateless session facade for a stateful EJB. Puoi use a client JAR for your EJB e comprimerlo con l'app Swing. È preferibile utilizzare la facciata senza stato, poiché ridurrà il carico sul server delle applicazioni. Tieni presente che puoi generare anche web services from stateless EJB beans, trasformandolo sostanzialmente in # 3.

Per 1 ... bene, buona fortuna. È possibile use RMI to interface with EJB's e generare il proprio stub e pareggio, anche se questo non è raccomandato e per una buona ragione. Questa pratica non è stata una pratica popolare per anni, potrebbe richiedere la rigenerazione periodica degli stub e dei legami e potrebbe richiedere una comprensione delle funzioni di basso livello del server delle app. Anche qui, vorrai transazioni XA. Se non vuoi gestire la gestione delle transazioni da solo, non sei tu.

Alla fine, come sono sicuro che tutti saranno d'accordo, la scelta è tua su cosa fare, e non c'è "giusto" o "sbagliato" modo, nonostante le opinioni di cui sopra. Se mi fosse stato (e non è), mi piacerebbe chiedere due questioni importanti di me stesso e il mio cliente:

1. E 'questo per un contratto o di impegno temporaneo, e in caso affermativo qual è il termine? Ricevo prima un altro contratto per questo stesso sistema più tardi quando vogliono aggiornamenti aggiuntivi? (In altre parole, quanti soldi ho intenzione di ottenere da questo contro quanto tempo sto spendendo? Se sarà un lungo periodo, allora andrei con 4 o 3, altrimenti 3 o 2 sarebbe meglio .)

2. Perché sbarazzarsi di CORBA? "Perché è vecchio" è una risposta onesta, ma qual è l'impulso di liberarsi della "vecchia piccantezza"? Hanno in programma di espandere l'utilizzo di questo sistema in futuro? C'è qualche licenza che sta per scadere e vogliono solo tenere le luci accese? E 'perché non vogliono scaricarlo su qualche programmatore più giovane che potrebbe non sapere come affrontare cose di basso livello come questo? Cosa vuoi che il sistema faccia in due anni, cinque anni o più?

(OK, in modo che è più di due domande: D)