Java EE gegen Standalone

Andere haben auf einige der Vorteile hingewiesen, daher hier einige Nachteile, wenn Sie den Hintergrundprozess in dasselbe jvm wie Ihre Web-App implementieren.

• Das Starten und Stoppen des Servers, auf dem das Webmodul ausgeführt wird, bedeutet, dass Sie die Hintergrundprozesse starten und stoppen. Dies kann für Sie ein Problem sein oder auch nicht.
• Sie teilen den Heap mit allen drei Anwendungen, wenn die Hintergrundprozesse viel Speicher oder CPU verbrauchen und sich dann auf Ihre Webanwendung auswirken. Wenn die Webanwendung viele Ressourcen verbraucht, kann dies Auswirkungen auf die Hintergrundprozesse haben.
• Die Web-App muss möglicherweise auf eine Weise bereitgestellt werden, die über das Internet zugänglich ist, aber die Hintergrundprozesse laufen möglicherweise ohne Zugriff auf das Internet. Warum sollten Sie die Hintergrundprozesse dem Internet aussetzen, wenn Sie das nicht müssen?
• Wenn Sie den App-Server, die Frameworks oder die Konfiguration aktualisieren, bedeutet dies drei Dinge zu testen. Wenn die Hintergrundprozesse eigenständig ausgeführt werden, können Sie sie in einem separaten Veröffentlichungszyklus über die Web-App aktualisieren.
• Es ist einfacher, Code außerhalb des Containers zu entwickeln und zu testen. Das Ausführen Ihrer Hintergrundprozesse innerhalb des Containers bedeutet eine komplexere Entwicklungsumgebung für die Hintergrundprozesse, Sie müssen warten, bis der Server startet, Sie beginnen abhängig von den Containerressourcen, die Sie dann Unit Tests testen müssen ... usw. / li>

JPA ist innerhalb und außerhalb des Containers gleich. Der einzige Unterschied besteht darin, wie Sie einen EntityManager erhalten, der mit Spring so konfiguriert werden kann, dass er innerhalb und außerhalb des Containers gleich ist. CDI sollte außerhalb des Containers ausgeführt werden können.

Die wichtigsten Unterschiede bestehen darin, wie Sie Transaktionen mit der Datenbank durchführen, zum Beispiel mit Spring-Transaktionen im Vergleich zu ejb-Transaktionen.

Aktualisierung: Um Ihre Frage zu beantworten, geben Sie den Kommentar ein: In JPA ist der EntityManager nicht threadsicher, so dass in einem Java EE Server ein Entity Manager pro Persistenzeinheit pro Thread existiert. Die Erstellung und Schließung des Entity-Managers wird vom App-Server für Sie verwaltet. Jeder Entity Manager hat einen Cache darin. Es ist möglich, einen Second-Level-Cache zu konfigurieren, der mehrere Entity-Manager umfasst. Wenn Sie außerhalb des Containers arbeiten, müssen Sie die Anzahl der JPA-Entity Manager selbst verwalten. Dies hängt von der Anzahl der Threads in Ihrem Hintergrundprozess und den Transaktionsgrenzen ab, die Sie haben möchten. Wenn Sie sich ein Buch mit dem Titel "Pro JPA2" ansehen, gibt es einen Abschnitt, der über die Details des Laufens innerhalb oder außerhalb des Containers spricht.

In meiner Anwendung habe ich keinen Hintergrundprozess, aber jede Klasse, die einen Entity Manager benötigt, wird nur mit @PersistenceContext EntityManager em; injiziert und spring sorgt dafür, dass alles innerhalb und außerhalb des Containers funktioniert. Spring 3.1 hat ein Feature namens profiles, das es trivial macht, den gleichen Code innerhalb unseres Containers zu verwenden, ohne eine einzelne Codezeile zu ändern. Ich bin kein CDI-Benutzer, daher weiß ich nicht, ob CDI ein Äquivalent der Feder 3.1-Profile-Funktion hat.

Wenn sich alle Module (Batch + Echtzeit) auf ein Produkt beziehen, dann ist es ein guter Ansatz, sie zusammen zu bündeln. Also hier ist mein Vorschlag

1. Bündeln Sie alle Ihre Module zu einem einzigen Ohr.
2. Verwenden Sie Java EE 6 und entfernen Sie den Frühling. CDI soll in Java EE verwendet werden. Versuchen Sie für Batching-Arten von Operationen, asynchrone EJBs oder MDBs zu nutzen .

Antworten auf Ihre spezifischen Fragen

• Können / sollten wir noch CDI mit Feder verwenden? Oder sollten wir zu EJB3 wechseln?

CDI kann auch ohne EJB verwendet werden. Jedenfalls werde ich den Frühling los, da ich keinen Mehrwert für dein einfaches Projekt sehe.

• Was sind die Konsequenzen für JPA, wenn wir es aus einem Container statt aus eigenständigen Modulen verwenden? Gibt es einen Unterschied?

Es gibt keinen Unterschied außer der Tatsache, dass Sie die DataSource von JNDI beziehen können.

• Da die meisten unserer Module nicht web-bezogen sind, macht es dennoch Sinn, sie in einem Java-EE-Container auszuführen?

Ja, es ist sinnvoll, Batch- und Echtzeitaspekte eines einzelnen Produkts zu bündeln, solange keine Leistungsprobleme auftreten.

Es ist sinnvoll, in einem Anwendungsserver statt in einem eigenständigen Java-Programm für die üblichen Gründe wie

1) Sie können CDI mit Feder verwenden, da EJB3 ebenfalls auf einem ähnlichen Konzept basiert. 2) Es gibt keinen Unterschied in Bezug auf JPA, außer dass, wenn Sie später mehr Volumen zu der Anwendung hinzufügen müssen, das Laden durch Hinzufügen weiterer Maschinen hinzugefügt werden kann, die dieselbe Anwendung ausführen. Beachten Sie jedoch, dass dies eine nicht-kommerzielle Anwendung ist. triviale Menge an Arbeit und daher hängt es von der geschäftlichen Anforderung ab, die Wahl zu treffen 3) Anwendungsserver gewinnen eigenständige Anwendungen aus Gründen der integrierten Sicherheit, Zuverlässigkeit, Verwaltung und Skalierbarkeit über eigenständige Java-Apps.