Vorteile/Nachteile von Glassfish v3 Prelude vs Springsource dm Server für Web-Anwendungen?

Question

Beide dieser Appservers sind zumindest teilweise OSGI basiert. Einer (Glassfish) ist offensichtlich Java EE, der andere nicht. Jetzt bin ich gerade dabei, eine Plattform für ein neues Projekt zu wählen und die natürliche Wahl ist Glassfish v3 Prelude. Dies wirft das Problem auf, dass wir stattdessen S2AP verwenden sollten.

Die Frage ist dann: Bietet der Quelle Source-DM-Server einen zwingenden Grund, es über Glassfish zu verwenden? Und umgekehrt.

Answer 1

Java EE-App-Server verfügen über verteilte Transaktionsmanager. Wenn das überhaupt wichtig ist, dann möchtest du vielleicht sehen, ob SpringSource dm solche enthält.

Es ist möglich, XA TX mit Spring-Framework zu verwenden, nur dass Sie alleine sind, um einen geeigneten XA-Manager zu finden und zu integrieren.

Kurs XA TX sind sehr in Verruf geraten. Die meisten Leute versuchen, sie wie die Pest zu vermeiden. Amazon.com zum Beispiel verwendet sie nicht.

Momentan verwenden wir Spring-Framework und Tomcat in Kombination. Wir machen unsere eigene Integration. Viele Leute haben ähnliche Middle-Tier Stack-Wahl getroffen. Wir werden mit Spring-Framework-APIs verbunden - genau wie Java EE-Leute mit Java EE/EJB verbunden werden. Lass dich von der Frühlingsrhetorik nicht täuschen. Es bleibt jedoch weiterhin Open Source zugänglich für die Benutzergemeinschaft.

Sobald Sie Java EE gehen, werden Sie an einen bestimmten Java EE-Anbieter gebunden, da es schwierig ist, zwischen Implementierungen zu wechseln. EJB3 wird dies angeblich erleichtern, würde aber wetten, dass es immer noch eine große Herausforderung sein wird, Java EE App Server zu wechseln.

Frankly Spring-Framework bietet mehr nützliche APIs als der Java EE/EJB-Standard und es ist schneller mit Innovationen.

Answer 2

Ich habe SpringSource dm Server nicht verwendet, aber ich glaube, es ist besser, eine Weile zu warten, bevor Sie es in der Produktion versuchen. Der Grund hat damit zu tun, dass es sich um eine ziemlich neue Technologie handelt. Auch die Art, wie das Lizenzierungsschema mit SpingSource (GPL) funktioniert, hilft nicht viel, da es praktisch bedeutet, dass Sie sich nur auf SpringSource für jetzt und für die Zukunft verlassen werden. Wenn Sie Unterstützung für den Server benötigen, ist Ihre einzige Option, mit SpringSource zu gehen.

Answer 3

Ich denke, SpringSource acquisition von Covalent Technologies bringt sie in eine bessere Position, um jedem zu helfen, der den Spring/Tomcat-Stapel verwendet. Die Tomcat-Optimierungen, die mit Spring dm Server geliefert werden, können genauso viel oder mehr wert sein als die OSGi-Funktionen.

Answer 4

Die Verwendung von OSGi in Glassfish ist irreführend. Glassfish verwendet OSGi intern für den Server. OSGi steht den in Glassfish bereitgestellten Anwendungen nicht zur Verfügung.

Mit dem Spring-dm-Server können die Anwendungen für die Verwendung von OSGi geschrieben werden.

Ist OSGi eine wichtige Überlegung für Sie? Der einzige andere echte OSGi App-Server ist Paremus 'Infiniflow. Alle anderen App-Server sprechen jetzt über OSGi, aber es handelt sich um ein internes Implementierungsdetail. Es ist nicht für die bereitgestellten Anwendungen.

Answer 5

SpringSource dm Server unterstützt modulare Anwendungen - Sie können Ihre Anwendung in OSGi-Bundles aufteilen und alle Infrastrukturdienste teilen, die Sie zwischen Anwendungen bereitstellen möchten. Dies führt Sie weg von den monolithischen Strukturen wie WARs, die von Java EE definiert werden. In der Regel bedeutet dies, dass Sie während der Entwicklung einen sehr schnellen Zyklus zum Bearbeiten/Speichern/Umsetzen erhalten.OSGi ermöglicht Ihnen dann die Versionsmodule und die Pakete, die sie exportieren, sowie Module dynamisch zu aktualisieren, ohne den gesamten Server neu starten zu müssen.

SpringSource dm Server wurde von Grund auf als OSGi-Bundles erstellt. So können Sie konfigurieren, welche Subsysteme von dm Server geladen werden, wenn Sie das Standardset nicht möchten.

Answer 6

Dies ist ein alter Thread, aber ich dachte, dass es für die Menschen nützlich wäre, über diese kommen (so wie ich) die jüngsten Glassfish OSGi Verbesserungen zu teilen, vor allem im Bereich der OSGi Enterprise-RFCs: http://wiki.glassfish.java.net/Wiki.jsp?page=OsgiDashboard

Natürlich es gibt auch die @ Resource-basierte Injektion von OSGi Declarative Services, die seit v3 im Dezember '09 dort war.