Ich versuche zu verstehen, wo einige meiner Anwendungslogik in meine Java EE-Anwendung gehen sollten. Ich bin neu in Java EE und versuche, viele unstrukturierte Daten aus einer Legacy-Datenbank zu laden und ein sauberes Objektmodell für die Verwendung durch meine Anwendung zu erstellen. Aus meiner Untersuchung sehe ich, dass Java EE Apps 2 Komponenten, Enterprise Bean und Web Application Components haben. Dieser Teil meiner Anwendung ist verantwortlich für das Laden der Daten, das Erstellen des Objektmodells und das Senden von Nachrichten über JMS auf der Grundlage des aktuellen Zustands der Daten an interessierte Parteien. Die Daten werden durch Synchronisation mit der Datenbank und von Nachrichten, die über JMS von entfernten Java-Anwendungen empfangen werden, aktualisiert.
Ist ein EJB der richtige Ort für diese Art von Funktionalität? Wie kann ich mit der Initialisierung meines Objektmodells beginnen (Hauptmethode Java-App-Äquivalent)? Was ist die beste Vorgehensweise zum Erstellen eines zeitgesteuerten Ereignisses zum Überprüfen des Objektmodells und zum Senden von Nachrichten über JMS?
Ich habe eine Reihe von Artikeln über Java EE, Glassfish, EJBs gelesen ... aber ich habe immer noch nicht das Gefühl, dass ich ein klares Bild davon habe, wo ich diese Funktionalität schreiben sollte. Alle Beispiele, die ich von EJB gesehen habe, sind in der Regel direkte Methodenaufrufe auf die Beans von Client-Anwendungen.
Im Moment glaube ich, dass eine Java-Anwendung den Job erledigen könnte, aber wir schauen uns in Zukunft RMI und Webclients an.
Java EE wird traditionell für den Client / Server-Architekturstil verwendet. Die Geschäftslogik wird in EJB-Session-Beans implementiert, die normalerweise entweder von einer Webanforderung, einer JMS-Nachricht oder einem RMI-IIOP-Remoteaufruf aufgerufen werden.
Ist ein EJB der richtige Ort dafür? Art von Funktionalität?
Die Logik geht in das EJB. Aber es gibt verschiedene Arten von EJB.
Wie kann ich die Initialisierung von starten? mein Objektmodell (Hauptmethode Java App gleichwertig)?
Es gibt keine main -Methode. Es gibt jedoch noch einige Möglichkeiten, um eine Verarbeitung durchzuführen, die der Anwendungsbereitstellung und / oder der Deimplementierung entspricht. Sie können sich ServletContextListener ansehen, Glassfish Lifecycle-Modul (nicht standardisiert) oder vielleicht das neu eingeführte Singleton Bohnen und @Startup Annotation.
Was ist die beste Vorgehensweise für? Erstellen eines zeitgesteuerten Ereignisses zum Überprüfen des Objektmodell und sendet Nachrichten über JMS?
Sie können einen EJB-Timer erstellen wird regelmäßig aufgerufen. Wenn Sie möchten, dass das Modell einmal im Speicher geladen wird, würde ich vorschlagen, dass Sie sich auch Singleton -Bohnen ansehen. Mit EJB 3.0 war das Problem, wie man starte den Timer automatisch , aber ich denke, sie haben das in EJB 3.1 verbessert und Timer können wurde vom Anwendungsserver automatisch gestartet , wenn die Anwendung mithilfe der Annotation @Scheduled bereitgestellt wurde. So kann es Ihnen irgendwie einen gewünschten Ausgangspunkt geben, wie Sie in Ihrer vorherigen Frage gefragt haben.
Sie können eine JMS-Nachricht von einer beliebigen Bean senden. JMS ein externes System genau wie die Datenbank. JMS-Nachrichten werden unter Verwendung einer speziellen Art von EJB empfangen, die Message-Driven Bean (MDB) genannt wird.
Ihre Anwendung wird keine traditionelle Web-EJB-Datenbank-Client-Server-Anwendung sein, aber sie sollte mit Java EE durchführbar sein, das definitiv ein sehr flexibles Modell ist.
Wie Sie sagten, neigen die Beispiele dazu, den direkten Aufruf zu involvieren. Nach meiner Erfahrung sind das nicht nur die Beispiele. Keine der Java EE * 1-Apps, die ich gesehen habe, verwendet ein langlebiges Objekt-Diagramm, wie Sie es beschreiben. Stattdessen arbeiten sie typischerweise in einem einzigen Datensatz (+ Kinder / Verwandte) als Antwort auf eine Web-Anfrage, Web-Service-Anruf oder JMS-Nachricht .
Ihre Anforderungen brechen diese Form und Java EE ist möglicherweise nicht die beste Lösung. Bei "face value" gehört die Art von Code, den Sie beschreiben, in den EJB-Container, aber diesem Container fehlt ein guter langlebiger Kontext, um den Objektgraphen zu verankern. Der Web-Container hat einen solchen Kontext, jedoch fehlen Einrichtungen für Zeitgeber und Nachrichtenbehandlung und dergleichen. Die Kosten für den Verzicht auf J2EE und die Verwendung einer einfachen Java-Anwendung bestehen darin, die Möglichkeiten des Anwendungsservers für Verwaltung, Bereitstellung und Überwachung zu verlieren.
Eine gute Wahl könnte sein, auf das zurückzugreifen, was das Spring-Framework groß gemacht hat. Ich weiß nicht, ob Sie mit der Geschichte von J2EE vertraut sind, aber die plötzliche, große Popularität von Spring Framework und Hibernate war im Wesentlichen eine Gemeinschaftsrebellion gegen den EJB-Container, Versionen 1.x / 2.x. Was der Spring WebApplicationContext Ihnen gab, war ein robustes, transaktionsorientiertes Backend für eine Webanwendung, wobei MDBs und JTA genutzt wurden, während ansonsten so viel wie möglich vom EJB-Container * 2 ignoriert wurde (und Unit-Testing im Prozess erheblich vereinfacht wurde). Sie können diesen Ansatz verwenden und Ihre Anwendung als einzelne WAR-Datei erstellen und Ihre Back-End-Dienste mit Spring booten.
Eine interessante Alternative ist, den Java EE-Anwendungsserver komplett zu entfernen und Ihre Anwendung auf dem OSGi-Framework aufzubauen. Dies ist der Ansatz der "normalen Java-Anwendung". Die OSGi-Laufzeitumgebung bietet Ihnen die Administrationskonsole und Hot-Deployment-Funktionen, über die Sie sonst noch verfügen müssten. Die fehlenden Teile der Infrastruktur sind der Timer (verwenden Sie Quartz ) und die Message-Driven Beans (verwenden Sie die JMS-API direkt). Eine OSGi-Anwendung fühlt sich ein wenig wie der Linux-Kernel und der Boot-Prozess an, wobei die Dienste entsprechend den Runlevels bereitgestellt und gestartet werden. Schnapp dir Apache Felix und sieh es dir an.
Sie haben die Skalierung nicht erwähnt. Wenn das Objektdiagramm riesig ist, sehen Sie sich Technologien wie GigaSpaces oder Coherence an.
** 1) Sun hat die "2" mit der Einführung von EJB3 * aus dem Akronym genommen.
** 2) Entity EJBs 2.x waren der schlechteste Teil. EJB 3 kann als weitgehend "wenn du nicht übertroffen wirst, schließe dich ihnen" an, um Hibernate zu standardisieren. *