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

Wenn Sie heute ein neues Java-EE-Projekt starten würden, das in etwa einem Jahr abgeschlossen sein soll, für welchen Applikationsserver würden Sie sich entscheiden und warum?

Ein Teil Ihrer Antwort sollte Ihre Argumente für Ihre Entscheidung enthalten. Und auch, wie viel Erfahrung Sie mit dem von Ihnen gewä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, die in Ihre Antwort eingeflossen sind.

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

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

Muss ich EJBs verwenden? Wirklich? Vermeiden Sie sie nach Möglichkeit – sie werden wirklich nur für sehr große Systeme der Enterprise-Klasse benötigt. Denken Sie daran, dass sie nur Werkzeuge sind, und zwar große (kann jemand “Goldener Vorschlaghammer” sagen?). Sie werden stark überbeansprucht, also fragen Sie sich wirklich, ob Sie sie brauchen. Wenn Sie sie brauchen, werden dadurch einige Ihrer Optionen entfernt, darunter mein Favorit, Jetty.

Müssen Sie eine der anderen wichtigen J2EE-Technologien wie JMS, ESB usw. verwenden? Wenn ja, und darauf können Sie wirklich nicht verzichten, dann sind Sie wieder auf einen vollwertigen J2EE-Container angewiesen. Denken Sie sorgfältig nach und untersuchen Sie, 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 vollwertigen J2EE-Container verwenden müssen, ziehen Sie zuerst Open Source in Betracht, da es robuster, besser unterstützt und kostengünstiger ist. Sie haben einen größeren Kundenstamm und eine offenere Interaktion mit dem Support, sodass sie in der Regel schneller bessere Lösungen erhalten. Resin ist jedoch unausgereift 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 (falls Sie sie brauchen).

Brauche ich Apache aus einem besonderen Grund? Dann neige dich 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 dagegen bin, Jetty verwenden zu können, würde ich alle meine Annahmen darüber in Frage stellen, warum. YAGNI gilt.

Am besten verwenden Sie StringTemplate/WebStringTemplate auf Jetty: eine saubere, robuste, schnelle, wartbare Lösung ohne Lizenzgebühren, solider Ruf und Support usw. Damit fange ich heute an.

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

Von den ausgewachsenen Containern würde ich WebLogic und WebSphere meiden, es sei denn, Sie unterstützen eine GROSSE öffentliche Website (die Website meines derzeitigen Arbeitgebers wird auf WebLogic bereitgestellt und erhält mehr als elf Millionen Zugriffe pro Monat, andere waren vergleichbar). Der eigentliche Anspruch von WebLogic auf Ruhm ist ihr relativ einfaches Clustering, aber vermeiden Sie ihre proprietären Vendor-Lock-in-Funktionen um (fast) jeden Preis. WebSphere ist einfach ein Alptraum, den ich buchstäblich um jeden Preis vermeiden würde – ich weigere mich, Projekte mit WebSphere zu machen, nachdem ich in der Vergangenheit ein paar gemacht habe. Keines der Produkte ist die enormen Lizenzgebühren wert, es sei denn, Sie haben wirklich einen besonderen Bedarf, der die Verwendung einer proprietären Funktion vorantreibt. In einem Jahrzehnt als leitender Architekt/Ingenieur für viele Fortune-500-Unternehmen habe ich noch keinen solchen Bedarf gesehen. Auf der anderen Seite habe ich VIEL Schmerz gesehen, weil ich solche proprietären Produkte ausgewählt habe.

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

EDIT: ein weiteres Stück zum Nachdenken …

bin ich kürzlich begegnet Terrakotta. Ich überdenke alles und möchte es bald in einem bedeutenden System einsetzen. Insbesondere Clustering ist Terracotta besser als alles andere, daher würde ich WebLogic NICHT MEHR für sein Clustering empfehlen.

Der Begriff “Anwendungsserver” ist mehrdeutig. Mit GlassFish v3 können Sie beispielsweise mit einem herkömmlichen Webcontainer klein anfangen und sich weiterentwickeln (unter Verwendung 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… Und doch handelt es sich um dasselbe Produkt, dieselbe Administrationsoberfläche usw. Kommt dies für Sie als Anwendungsserver infrage? -Alexis (Sonne)

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

Ich habe WebLogic 8 vor etwa 3 Jahren verwendet und war mit der Benutzerfreundlichkeit von WebLogic und dem Lizenzierungs-/Kostenmodell zufrieden. Wir haben es für zwei Projekte verwendet, eines war ein Webdienst und das andere ein Portal. Wir sind in keinem dieser Projekte auf Probleme mit WebLogic oder WebLogic Portal gestoßen.

In den letzten zwei Jahren habe ich mit WebSphere gearbeitet. Jedes Mal, wenn ich mit IBM verhandelte, kostete es am Ende immer doppelt so viel wie ein WebLogic-Äquivalent, aber die Unternehmensrichtlinie diktierte WebSphere. Ich fand, dass die Lernkurve bei WebSphere erheblich steiler war als bei WebLogic, und unser Build/Deployment/Test-Lebenszyklus war so zeitaufwändig, dass wir Tomcat in der Entwicklungsumgebung verwendeten. Aber das größte Problem, das ich mit WebSphere hatte, war, 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-Stunden-Schicht, um das alles durchzuarbeiten.

Im Moment verwende ich jedoch JBoss. Vor ungefähr 3 Monaten wollte ich mein neues Projekt mit Tomcat und Jetspeed 2 starten, aber ich bemerkte, dass Jetspeed 2 im Moment 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 Build/Deploy/Test-Zyklus 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. Kommerzieller Support verfügbar.
3. Große, aktive Benutzergemeinschaft.

Argumente gegen jBoss:

1. Keine allgemein zugängliche, unterstützte Java EE 5-Containerversion.
2. Viel Dokumentation, aber ausführlich; kann schwierig sein, die Antworten auf “Wie mache ich x?” zu finden.
3. Verwaltungstools für 4.x sind im Vergleich zu anderen kommerziellen Angeboten schlecht.

Kasse GlassFish 3.1! Aufbauend auf dem modularen, Java EE 6-basierten GlassFish v3-Kernel bietet Version 3.1 Clustering, zentralisierte Verwaltung und Hochverfügbarkeit.

Beziehen auf http://blogs.oracle.com/nazrul/entry/glassfish_3_1 für mehr Details.

Ein weiterer Punkt, der hier nicht diskutiert 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
• Resin ist viel langsamer als G-WAN + Java

Beachten Sie, dass G-WAN allein auf die JVM angewiesen ist: Es verwendet keine weiteren Container (sofern nicht ausdrücklich angegeben), sodass Sie es möglicherweise für leistungskritische Teile Ihrer Webanwendungen reservieren.

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

Ich könnte Ihr bevorzugtes Betriebssystem als Entscheidungskriterium angeben. Es sollte den Support vereinfachen, wenn Sie denselben Anbieter für das Betriebssystem und den App-Server verwenden. Wenn Sie bereits eine Beziehung zu einem oder beiden Anbietern haben, überlegen Sie, ob Sie mit ihnen gut umgehen können.

Aus technischer Sicht würde ich GlassFish wählen, weil es neuere Innovationen unterstützt. Ich finde JBoss nicht schlecht, es ist sowieso nicht mehr so ​​aktuell.

Die meisten meiner Erfahrungen 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 geringfügigen Frustrationen.