Würden Sie derzeit JBoss oder Glassfish (oder einen anderen) als Java EE-Server für ein neues Projekt verwenden? [geschlossen]

Wenn Sie heute ein neues Java EE-Projekt starten würden, das in etwa einem Jahr abgeschlossen sein soll, welchen Anwendungsserver würden Sie wählen und warum?

Ein Teil Ihrer Antwort sollte Ihre Argumente für Ihre Entscheidung enthalten. Und wie viel Erfahrung Sie mit dem von Ihnen ausgewählten Java EE-Server und mit den anderen verfügbaren Servern auf dem Markt haben. Diese sind interessant, da wir alle ein Gefühl für die Untersuchung und den Gedanken bekommen, der in Ihre Antwort aufgenommen wurde.

Ich habe in den letzten 10 Jahren WebLogic, WebSphere, JBoss, GlassFish, Resin, Jetty, Tomcat und einige andere verwendet. Wenn ich also über ein neues Projekt nachdenken würde, würde ich mir zuerst ein paar Fragen stellen. Eine Sache, die ich nicht mehr in Frage stellen würde, ist, dass ich mich pauschal weigern würde, JSPs zu verwenden, es sei denn, ich wurde gefoltert, bis ich um meine Mutter weinte.

Muss ich aufgrund eines Mandats einer Person mit einem bestimmten Produkt kompatibel sein / bereitgestellt werden? Gibt es keine Möglichkeit, sie zu ignorieren oder anders zu überzeugen? Wenn ja, gibt es Ihre Antwort.

Muss ich EJBs verwenden? "Ja wirklich?" Vermeiden Sie sie, wenn es überhaupt möglich ist - sie werden wirklich nur für sehr große Systeme der Enterprise-Klasse benötigt. Denken Sie daran, dass es sich nur um Werkzeuge handelt, und zwar um große (kann jemand "Goldener Vorschlaghammer" sagen?). Sie sind stark überbeansprucht, also fragen Sie sich wirklich, ob Sie sie brauchen. Wenn Sie sie brauchen, werden dadurch einige Ihrer Optionen entfernt, einschließlich meines Favoriten Jetty.

Müssen Sie eine der anderen wichtigen J2EE-Technologien wie JMS, ESB usw. verwenden? Wenn dies der Fall ist und Sie wirklich nicht darauf verzichten können, sind Sie erneut auf einen vollständigen J2EE-Container beschränkt. Überlegen und recherchieren Sie sorgfältig, bevor Sie sich beispielsweise für BPM entscheiden, und vermeiden Sie AquaLogic BPM um (fast) jeden Preis - es ist extrem hässlich.

Wenn Sie wirklich einen vollständigen J2EE-Container verwenden müssen, sollten Sie zuerst Open Source in Betracht ziehen, da dieser robuster, besser unterstützt und kostengünstiger ist. Sie haben eine größere Kundenbasis und eine offenere Support-Interaktion, sodass sie in der Regel schneller bessere Lösungen erhalten. Resin ist jedoch unreif und ich würde es im Vergleich zu GlassFish oder JBoss vermeiden - ich fand es problematisch, es bereitzustellen und zu unterstützen. Ich würde JBoss wegen seiner breiteren Kundenbasis, Reife usw. bevorzugen. GlassFish ist schwieriger in einen automatisierten Build- / Bereitstellungsprozess zu integrieren, aber es könnte für einige seiner spezifischen Funktionen besser sein (wenn Sie sie benötigen).

Habe ich einen besonderen Grund, Apache zu brauchen? Dann beugen Sie sich zu Tomcat, vielleicht plus etwas.

Kann ich nur mit Servlets auskommen? Dann würde ich Jetty verwenden - es ist die leichteste, schnellste, einfachste und flexibelste Lösung. Wenn ich mich dagegen lehne, Jetty benutzen zu können, würde ich alle meine Annahmen in Frage stellen, warum. YAGNI gilt.

Am besten verwenden Sie StringTemplate / WebStringTemplate auf Jetty: eine saubere, robuste, schnelle und wartbare Lösung ohne Lizenzgebühren, soliden Ruf und Support usw. Hier beginne ich heutzutage.

Die meisten Anwendungen / Systeme wählen viele ausgefallene J2EE-Funktionen, wenn sie nur Servlets und JDBC mit einer anständigen Architektur / Design benötigen. Frage, warum du denkst, du brauchst mehr.

Von den vollständigen Containern würde ich WebLogic und WebSphere vermeiden, es sei denn, Sie unterstützen eine öffentliche MAJOR-Website (die Website meines aktuellen Arbeitgebers wird auf WebLogic bereitgestellt und erreicht mehr als elf Millionen Zugriffe pro Monat, andere waren vergleichbar). Der wahre Bekanntheitsgrad von WebLogic liegt in der relativ einfachen Clusterbildung. Vermeiden Sie jedoch (fast) um jeden Preis die proprietären Funktionen zur Lieferantenbindung. WebSphere ist einfach ein Albtraum, den ich buchstäblich um jeden Preis vermeiden würde - ich lehne es ab, Projekte mit WebSphere durchzuführen, nachdem ich in der Vergangenheit ein paar gemacht habe. Keines der beiden Produkte ist die massiven Lizenzgebühren wert, es sei denn, Sie haben wirklich einen besonderen Bedarf, der die Verwendung einer proprietären Funktion fördert. In einem Jahrzehnt als leitender Architekt / Ingenieur für viele Fortune 500-Unternehmen habe ich einen solchen Bedarf noch nicht erkannt. Andererseits,

Selbst für die wirklich großen, stark frequentierten öffentlichen Websites sind die proprietären Produkte immer noch fraglich. Ich würde diese Lizenzgebühren in Höhe von mehreren Millionen Dollar pro Jahr lieber für eine gute Hardware und eine gute Zeit von einer Handvoll wirklich guter Berater ausgeben, um eine einfache Skalierbarkeitslösung zu finden. Die zusätzlichen Millionen pro Jahr könnten dann verwendet werden, um etwas zu produzieren, das es wert ist, auf dieser schönen Website verkauft zu werden ...

EDIT: ein weiteres Stück zu berücksichtigen ...

Ich bin kürzlich auf Terrakotta gestoßen . Ich überdenke alles und versuche, es bald in einem bedeutenden System bereitzustellen. Insbesondere Terracotta macht Clustering besser als alles andere, daher würde ich WebLogic für sein Clustering NICHT MEHR empfehlen.

Der Begriff "Anwendungsserver" ist nicht eindeutig. Mit GlassFish v3 können Sie beispielsweise mit einem herkömmlichen Webcontainer klein anfangen und sich weiterentwickeln (mithilfe von OSGi und der einfachen Funktion "Container hinzufügen"), um alles hinzuzufügen, was Sie möchten: JPA, JAX-RS, EJBs, JTA, JMS, ESB , etc ... Es ist jedoch dasselbe Produkt, dieselbe Administrationsoberfläche usw. Qualifiziert sich dies für Sie als Anwendungsserver? -Alexis (Sonne)

Die erste Frage, die ich mir normalerweise stelle, lautet: "Kann ich das mit Tomcat machen?". Wenn die Antwort Nein lautet, weil ich JMS oder JTA benötige, greife ich auf einen Anwendungsserver zurück.

Ich habe WebLogic 8 vor ungefähr 3 Jahren verwendet, zufrieden mit der Benutzerfreundlichkeit von WebLogic und dem Lizenz- / Kostenmodell. Wir haben es für zwei Projekte verwendet, eines war ein Webdienst und das andere war ein Portal. In keinem dieser Projekte sind Probleme mit WebLogic oder WebLogic Portal aufgetreten.

In den letzten zwei Jahren habe ich mit WebSphere gearbeitet. Jedes Mal, wenn ich mit IBM verhandelte, kostete es doppelt so viel wie ein WebLogic-Äquivalent, aber laut Unternehmensrichtlinien musste WebSphere verwendet werden. Ich fand die Lernkurve in WebSphere erheblich steiler als in WebLogic und unser Lebenszyklus zum Erstellen / Bereitstellen / Testen war so zeitaufwändig, dass wir Tomcat in der Entwicklungsumgebung verwendeten. Das größte Problem, das ich mit WebSphere hatte, war jedoch, als wir auf einen Fehler stießen, der uns zwang, auf die nächste Patch-Version zu aktualisieren, nur um auf ein neues Problem beim Parsen von web.xml zu stoßen. Es dauerte eine 48-stündige Schicht, um all das durchzuarbeiten.

Im Moment benutze ich JBoss. Vor ungefähr 3 Monaten wollte ich mein neues Projekt mit Tomcat und Jetspeed 2 beginnen, aber ich bemerkte, dass Jetspeed 2 momentan etwas stagniert und JBoss Portal 2.7.0 gerade mit JSR 286 / Portlet 2.0-Unterstützung veröffentlicht wurde. Ich habe JBoss ausprobiert und fand es sehr einfach einzurichten und zu verwalten. Der Erstellungs- / Bereitstellungs- / Testzyklus ist sehr schnell und ich muss den Server selten neu starten, es sei denn, ich habe irgendwo eine Spring-XML-Datei geändert.

Ich benutze jBoss seit 3-4 Jahren.

Argumente für jBoss:

1. Open Source.
2. Kommerzielle Unterstützung verfügbar.
3. Große, aktive Benutzergemeinschaft.

Argumente gegen jBoss:

1. Kein allgemeiner Zugriff, unterstützte Java EE 5-Containerfreigabe.
2. Viel Dokumentation, aber ausführlich; Es kann schwierig sein, Antworten auf "Wie mache ich x?" zu finden.
3. Verwaltungstools für 4.x schlecht im Vergleich zu anderen kommerziellen Angeboten.

Kasse GlassFish 3.1! Die Version 3.1 basiert auf dem modularen, auf Java EE 6 basierenden GlassFish v3-Kernel und bietet Clustering, zentralisierte Verwaltung und hohe Verfügbarkeit.

Weitere Informationen finden Sie unter http://blogs.oracle.com/nazrul/entry/glassfish_3_1 .

Ein weiterer Punkt, der hier nicht erörtert wurde, ist die Leistung. Wenn dies aufgrund der Art des Dienstes oder der Anzahl der Benutzer ein Problem darstellt, gilt Folgendes:

• Tomcat scheint langsamer zu sein als Glassfish
• Glassfish scheint langsamer zu sein als Resin
• Harz ist viel langsamer als G-WAN + Java

Beachten Sie, dass G-WAN nur auf der JVM basiert: Es werden keine weiteren Container verwendet (sofern nicht ausdrücklich angegeben), sodass Sie sie möglicherweise für leistungskritische Teile Ihrer Webanwendungen reservieren können.

Da G-WAN andere Sprachen unterstützt (C, C ++, C #, D, Objective-C), können Sie sogar einige Teile der Anwendungen in Raw C verarbeiten, während Sie Java für andere Aufgaben behalten.

Ich könnte Ihr bevorzugtes Betriebssystem als Entscheidungskriterium angeben. Dies sollte die Unterstützung erleichtern, wenn Sie denselben Anbieter für Betriebssystem und App-Server verwenden. Wenn Sie bereits eine Beziehung zu einem oder beiden Anbietern haben, prüfen Sie, ob diese gut zu handhaben sind.

Aus technischer Sicht würde ich mich für GlassFish entscheiden, da es Unterstützung für neuere Innovationen bietet. Ich denke nicht, dass JBoss schlecht ist, es ist einfach nicht so aktuell.

Die meiste Erfahrung habe ich mit WebLogic gemacht, aber ich habe JBoss und GlassFish verwendet. Ich habe gerade eine neue Site auf einem vollständigen Sun Open Source-Stack (OpenSolaris, GlassFish, MySQL) veröffentlicht und es war eine großartige Erfahrung mit nur geringen Frustrationen.

Ich denke immer noch, dass WebLogic der beste Java EE-App-Server auf dem Markt ist. Ich denke, es lohnt sich, wenn Sie sich diese Lizenzgebühren leisten können.

Ich war überrascht zu sehen, wie weit Sie durch die Kombination von Tomcat, OpenEJB und ActiveMQ gehen können. Das scheint mir eine kostengünstige Alternative zu sein.

Ich würde auch in den Spring dm Server schauen. Es basiert auf Tomcat, aber ich denke, das OSGi-Stück, das sie hinzugefügt haben, könnte in kurzer Zeit überall sein. Wenn es mit der gleichen Qualität wie das Spring-Framework erstellt wird, ist es in der Tat sehr gut.

Eine Alternative: Verwenden Sie überhaupt keinen Appserver.

Auschecken http://www.atomikos.com/Publications/J2eeWithoutApplicationServer .

Bewahren Sie für Webprojekte bei Bedarf einen leichten Webcontainer in Kombination mit Wicket auf, um die Komplexität von JSP / JSF oder Streben zu vermeiden.

HTH Guy