Migration der CORBA-Anwendung auf moderne Java-Technologien (Rest/SOAP/EJB)

Question

Ich habe die Anforderung, ein CORBA-Legacy-System auf die neueste Java-Technologie zu migrieren. Das Hauptproblem, dem ich gegenüberstehe, ist die Bereitstellung langlebiger Transaktionen (db) im vorgeschlagenen System. Momentan behält der Client (Swing App) das CORBA-Dienstobjekt und führt mehrere db txn aus, bevor er tatsächlich alle txn festlegt/zurückrollt. Service-Schicht hält den Zustand des Verbindungsobjekts durch, um die Transaktion abzuschließen.

Ich wollte diesen Mechanismus in meinem neuen System (REST/WS) reproduzieren, so dass entweder Swing Client/Web (Future) in der gleichen Weise funktionieren kann.

zB:

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(); 
} 

Nun wollte ich CORBA zu jeder modernen Technolgie wandern, aber immer noch ich bin im Allgemeinen eine Lösung dafür zu finden. (Das Problem ist, dass der Client keine Änderungen an der Dienstschicht oder der Db-Schicht vornehmen möchte), sie wollten nur CORBA entfernen.

paar Optionen für mich verfügbar sind

1. Migrate CORBA RMI -> damit den aktuellen System erforderlichen Änderungen sind minimal, aber das Transaktionsmanagement, Connection Pooling, müssen Haltezustand mich selbst zu tun.

2. CORBA zu Stateful EJB migrieren -> RMI vergleichen mehr Änderungen erforderlich, aber besser, da ich Container-Managed-Verbindungspooling verwenden kann, Zustand besser zu erhalten.

3. Migrate CORBA Stateful Webservice (SOAP) -> Mehr futuristisch, aber viele Änderungen erforderlich - Wie immer kann ich IDL zu WSDL konvertieren und übertragen den Anruf bis zur Umsetzung Schicht

4. Migrate CORBA REST -> Am meisten gewünscht, wenn möglich - aber die Zeit, die für die Migration benötigt wird, ist enorm, Codeänderungen würden von der UI-Schicht zur Service-Schicht erfordern.

Vielen Dank im Voraus

Answer 1

Die Reihenfolge, in der ich die Optionen wählen würde, vom besten zum schlechtesten, wäre 4, 3, 2 und 1, jedoch würde ich Stateful Bohnen vermeiden oder Dienstleistungen, wenn dies menschlich möglich ist.

Ich werde über die Details der Implementierung gehen, was Sie im Detail tun müssen.

Für jede dieser Lösungen müssen Sie XA-compliant data sources and transactions verwenden, damit Sie die Einhaltung der ACID, preferably from an application server so you don't have to generate the transaction yourself, garantieren können. Dies sollte eine Verbesserung gegenüber Ihrer bestehenden Anwendung sein, da dies mit ziemlicher Sicherheit nicht garantiert werden kann, aber darauf hingewiesen, dass nach meiner Erfahrung viele Hacks eingesetzt werden, um JTA im Wesentlichen neu zu erfinden, also passen Sie darauf auf.

Für 4 möchten Sie container-managed transactions with XA verwenden. Sie könnten dies tun, indem Sie injecting a @PersistenceContext backed by a JTA connection. Ja, das kostet eine Menge Zeit, Tests und Aufwand, aber es hat zwei Boni: Erstens wird es viel einfacher sein, ins Web zu gehen, und es klingt, als ob die Zeit kommen würde. Zweitens, diejenigen, die nach Ihnen kommen, sind eher in neueren Web-Service-Technologien vertraut als nackte CORBA und RMI.

Für 3 möchten Sie auch container-managed transactions with XA verwenden. SOAP wäre nicht meine erste Wahl, da es sehr ausführliche Nachrichten verwendet und REST populärer ist, aber es könnte getan werden.Wenn es jedoch Stateful ist, müssen Sie bean-managed transactions instead und dann hang on to resources across web service calls verwenden. Dies ist gefährlich, da es möglicherweise das gesamte System blockieren könnte.

Für 2 können Sie zwei Wege gehen, entweder container-managed transactions with XA mit einem stateless session facade for a stateful EJB. Sie können use a client JAR for your EJB und Paket mit der Swing-App. Es empfiehlt sich, die statusfreie Fassade zu verwenden, da dies die Belastung Ihres Anwendungsservers verringert. Denken Sie daran, dass Sie auch web services from stateless EJB beans generieren können, was im Wesentlichen zu # 3 wird.

Für 1 ... nun, viel Glück. Es ist möglich, use RMI to interface with EJB's, und generieren Sie Ihre eigenen Stub und Krawatte, obwohl dies nicht empfohlen wird, und das aus gutem Grund. Dies ist seit Jahren keine gängige Praxis. Möglicherweise müssen die Stubs und Bindungen in regelmäßigen Abständen neu generiert werden, und es kann ein Verständnis der Low-Level-Funktionen des Anwendungsservers erforderlich sein. Auch hier werden Sie XA-Transaktionen wünschen. Sie möchten das Transaktionsmanagement nach Möglichkeit nicht selbst durchführen.

Schließlich bin ich mir sicher, dass jeder zustimmen wird, die Wahl liegt bei Ihnen, was zu tun ist, und es gibt keinen "richtigen" oder "falschen" Weg, trotz der oben genannten Meinungen. Wenn es nach mir ginge (und es ist nicht), würde ich zwei wichtige Fragen an mich stellen und meinen Kunden:

1. Ist das für einen Vertrag oder zeitweiligen Eingriff, und wenn ja, was ist der Begriff? Bekomme ich später bei einem anderen Vertrag für dasselbe System die erste Wahl, wenn sie zusätzliche Updates wünschen? (Mit anderen Worten, wie viel Geld werde ich aus diesem vs. wie viel Zeit werde ich ausgeben? Wenn es eine langfristige, werde ich mit 4 oder 3 gehen, sonst 3 oder 2 wäre besser .)

2. Warum CORBA loswerden? "Weil es alt ist" ist eine ehrliche Antwort, aber was ist der Anstoß, die "alte Schärfe" loszuwerden? Planen sie, die Nutzung dieses Systems in Zukunft zu erweitern? Gibt es eine Lizenz, die kurz vor dem Ablauf steht und sie wollen nur das Licht an? Liegt es daran, dass sie das nicht an einen jüngeren Programmierer weitergeben wollen, der vielleicht nicht weiß, wie man mit Low-Level-Kram umgehen soll? Was soll das System in zwei Jahren, fünf Jahren oder länger?

(OK, so dass mehr als zwei Fragen ist: D) ​​