hat hier eigentlich schon jemand Erfahrungen mit dem Konzept der Embedded JEE Server gesammelt? Ich spiele zur Zeit mit Wildfly Swarm herum und mir gefällt hier gerade das modulare Konzept ganz gut, dass das Maven Plugin “errät”, welche Komponenten die Anwendung benötigt, das macht wirklich einen schlanken Fuß.
Natürlich hauptsächlich für Microservices im Fokus zur Zeit, auch wenn ich für so etwas keine Anwendungsfälle habe, aber auch bei weniger technikaffinen Kunden finde ich das eine gute Lösung, einfach das Jar ausführen und glücklich sein.
Deployed wird viel einfacher IME, wenn der Container embedded wird, ein Jar ausliefen, starten, fertig
Selbst Legacy Anwendungen profitieren davon, nicht nur „Microservices“.
Hatte mal ein kleines Projekt das auf Sring-Boot mit Tomcat aufgebaut war. War ne kleine Anwendung für ne Messe und man sparte sich so ne Menge Zeit den Messe-PC vorzubereiten.
War ein bisschen fricklig da JSF mit reinzubekommen, aber ging letzlich dann doch. Wenn auch leider nicht gänzlich ohne xml-Config-Dateien.
Dateigrösse: WAR vs Standalone-JAR. Gerade wenn man irgendwo remote deployt, dann kann es einen Unterschied machen ob man ein kleines WAR über die dünne Leitung schiebt oder ob jedes mal noch ein AS dranhängt.
Start Zeiten: Hier käme jedes mal noch das Booten des AS hinzu, was während der Entwicklung mMn. etwas stärker ins Gewicht fällt im Gegensatz zu einem einfachen redeployment.
Möglichkeit mehrere Anwendungen in einer JVM laufen zu lassen. Möchte man manchmal haben, braucht man aber nicht unbedingt und kann andere Probleme nach sich ziehen. Manchmal möchte man das ganze Zeug auch getrennt haben.
Version des AS ist mit der Anwendung verzahnt. Einerseits gut wegen Versionierung, andererseits muss man die Anwendung neu bauen, wenn man aus Sicherheitsgründen updaten möchte, sollte.
Bei einem War habe ich eher, dass Gefühl, dieses auf jedem beliebigen AS zum laufen zu bekommen während man sich beim embedden doch schon stark festlegt. Was auch wieder seine Vorteile haben kann, wie bereits genannt.
Embedded Tomcat bzw. Jetty brauchten gefuehlt nur einen Bruchteil was die normalen Container zum starten/redeployen brauchten, ist auch nicht verwunderlich wenn man bedenkt dass die embedded Varianten einiges von dem ganzen „Standard Krempel“ und „Management Anwendungen“ erstmal weglassen.
Das ganze ist so 1-2 Jahre her, hab deshalb keine genauen Zeiten.
Getrennt ist einfach einfacher
Wenn man mehrere Anwendungen in einem Container laufen laesst, dann oft nicht weil man moechte, sondern weil man muss.
Das ist richtig.
Auf der anderen Seite weiss man dafuer aber immer, dass die Tests mit der gleichen Container Version laufen wie in der Produktion, ein Grund weniger um in eine „but it works on my machine“ Situation zu kommen.
Wildfly Swarm hat bei mir 90mb Overhead draufgepackt. Payara Micro liegt glaube ich bei 70. Ist schon eine Hausnummer und ein berechtigter Einwand.
Nach meinen bisherigen Erkenntnissen: Wildfly Swarm wird von Maven nur in der Packaging Phase berücksichtigt, es wird auch das „normale“ war erzeugt. Es sollte also möglich sein, auf einem gebooteten Wildfly zu entwickeln und es am Ende per Swarm zu paketieren.
Müsste man mit EAR Packaging so können, aber ist vielleicht für Swarm oder Micro oder Boot nicht der richtige Anwendungsfall.
[QUOTE=ionutbaiu;140697]
Version des AS ist mit der Anwendung verzahnt. Einerseits gut wegen Versionierung, andererseits muss man die Anwendung neu bauen, wenn man aus Sicherheitsgründen updaten möchte, sollte.[/QUOTE]
Korrekt.
[QUOTE=ionutbaiu;140697]
Bei einem War habe ich eher, dass Gefühl, dieses auf jedem beliebigen AS zum laufen zu bekommen während man sich beim embedden doch schon stark festlegt. Was auch wieder seine Vorteile haben kann, wie bereits genannt.[/QUOTE]
Da kann ich dir leider nicht so ohne weiteres zustimmen. Bestes Beispiel: Payara benutzt MoXy, Wildfly Jackson, Payara Eclipselink, Wildfly Hibernate. Das ergibt schon so viele natürliche Grenzen und imkompatibilitäten, dass es tatsächlich (meiner Meinung nach) schon mit ordentlichem Aufwand verbunden sein kann einen simplen REST Service mit Persistenz übergreifend zum Laufen zu kriegen.
Sowohl SpringBoot als auch Wildfly-Swarm binden nur die Dependencies ein, die auch wirklich gebraucht werden. Damit ist das jar dann natürlich immer noch größer als ein normales war aber in der Regel kleiner als ein AppServer gebundled mit einem war.
[QUOTE=ionutbaiu;140697]
Start Zeiten: Hier käme jedes mal noch das Booten des AS hinzu, was während der Entwicklung mMn. etwas stärker ins Gewicht fällt im Gegensatz zu einem einfachen redeployment.[/QUOTE]
Ich habe den Swarm bis CR1 aktiv verfolgt. Hier gibt es z.B. maven-Plugins, die das Starten auf einfache Art und Weise ermöglichen. Auch bei SpringBoot gibt es so etwas. Geschwindigkeitsverluste sind marginal, allerdings kommt es wohl auf die Anwendung an. Ich hatte bisher jedoch keine Probleme.
[QUOTE=ionutbaiu;140697]
Möglichkeit mehrere Anwendungen in einer JVM laufen zu lassen. Möchte man manchmal haben, braucht man aber nicht unbedingt und kann andere Probleme nach sich ziehen. Manchmal möchte man das ganze Zeug auch getrennt haben.[/QUOTE]
Mehrere war in einer JVM war ja ein Hauptgrund für AppServer. Ich halte von dieser Sicht nicht mehr viel. Gerade weil die meisten Server leichtgewichtig (und auch kostenlos) sind, kann man davon ohne Probleme mehrere Instanzen starten. Nachteile sehe ich da nicht. Vorteile sind jedoch, dass die Artefakte unabhängig voneinander laufen.
[QUOTE=ionutbaiu;140697]
Version des AS ist mit der Anwendung verzahnt. Einerseits gut wegen Versionierung, andererseits muss man die Anwendung neu bauen, wenn man aus Sicherheitsgründen updaten möchte, sollte.[/QUOTE]
Das ist ganz häufig der Fall. Gerade im JEE-Fall sind nicht immer alle APIs kompatibel. Häufig baut man für ein oder 2 Versionen des AS eine Anwendung. Wenn man dann ein Update vom AS durchführt, muss man ja häufig ebenfalls die Anwendung anpassen. Aus Betriebssicht würde ich auch sagen. dass App und AS eine Einheit bilden sollten.
[QUOTE=ionutbaiu;140697]
Bei einem War habe ich eher, dass Gefühl, dieses auf jedem beliebigen AS zum laufen zu bekommen während man sich beim embedden doch schon stark festlegt. Was auch wieder seine Vorteile haben kann, wie bereits genannt.[/QUOTE]
Die Wirklichkeit ist allerdings anders. Die einzelnen JPA-Implementierungen sind nicht immer kompatibel (je nachdem, was man an Funktionalität verwendet). Das betrifft auch andere Bereiche von JEE. Ich empfinde das Bundling eher als Vorteil. Und seien wir mal ehrlich: wie oft wechselt man einen AS?
Nachdem ich gerade wieder an einer kleinen Swarm Anwendung bin: Das Tooling gefällt mir gut. Gestartet werden kann das Ganze auch aus der IDE mit mvn wildfly-swarm:run, Änderungen an JSF Pages werden sofort per Hotswap angezeigt. Funktioniert ähnlich gut wie Spring Boot, wobei hier das Tooling beim Aufsetzen des Projekts mir noch besser gefällt. Startzeit des WAR files nach dem Kompilieren übrigens unter 2 Sekunden.
