Ist Glassfish auch ein Webserver?

[Semox]

Hallo Forum

Ich experimentiere mit Glassfish. Dabei würde ich gern lernen, wie ich Applikationen, die ich in Netbeans erzeugt habe (Servlets, JSPs, klassische Beans) in meinem "Heimnetznetzwerk" so portiere, als wäre es das Internet himself.

Die Idee ist, daß ich ein Mini-Ausleihsystem (z.B. wie in einer Bücherei mit Bildchen, Kurzbeschr., Ausleihstatus und für den Admin wer's Medium hat) zum tauschen von Movies und Musik bastele. Dazu habe ich einen alten Rechner mit J2EE ausgestattet und ne MySQL Datenbank eingerichtet.

Auf meinem Schlepptop habe ich schon eine *.war file in so einem Beispiel erzeugt und würde nun gern wissen, ob Glassfish nun neben einem Applikationsserver auch einen Webserver enthält, mit dem man Inhalte online (im Heimnetz) stellen kann, wobei es dann eben auch SFTP Zugriff, Rollen, Benutzerkontensteuerung etc. geben können sollte. Kann mich da jemand beraten? Vielen Dank.

Meine Kenntnisse sind was Netzwerkommunikation und Java Programmierung angeht noch nicht sooo unendlich weit, weil ich mitten im Studium bin.

EDIT:
Gruß,
SemoX

 

[FArt]

Ich hoffe, dass man im Studium heutzutage nicht verlernt bei Wikipedia vorbei zu schauen, die Webseite des Anbieters bzw. die 'Doku zu lesen oder zu googeln.

GlassFish ? Wikipedia
https://glassfish.dev.java.net/
https://glassfish.dev.java.net/javaee5/webtier/webtierhome.html

 

[Semox]

Hallo FArt

Danke für die Links. Denen bin ich schon gefolgt. Ist denn Glassfish nun ein vollwertiger Webserver mit den gleichen Fähigkeiten wie z.B. der IIS 7? Das steht da nicht in den Docs, die ich bisher gelesen habe. Hauptsächlich bin ich dabei mich durch das JavaEE Tutorial von Sun durchzuarbeiten... Leider stand da nicht dabei was Glassfish alles kann, obwohl dort eine große Menge an Themen angeschnitten werden.

Was das Studium angeht - das hoffe ich doch auch...

Einige der Profs an meiner Uni und der FH meiner Frau meinen, daß sich Wikipedia viel zu sehr auf journalistischem Niveau (da zu knapp und selten gut belegt), statt wissenschaftlich fundierter Erkenntnisse bewegt - harter Tobac die Aussage... Aber das wäre ein Thema für Trolls und Flamer á la Apple vs. MS, NB vs. Eclipse und Java vs. .NET in der Plauderecke des Forums...

Viele Grüße
Semox

 

[maki]

Ist denn Glassfish nun ein vollwertiger Webserver mit den gleichen Fähigkeiten wie z.B. der IIS 7?

Wenn es um Webserver geht, ist Apache der Standard, nicht der IIS
Nebenbei bemerkt, Benutzerkonntensteuerung, SFTP Zugriff etc. gehören nicht zum Funktionsumfang eines Webservers.

Einige der Profs an meiner Uni und der FH meiner Frau meinen, daß sich Wikipedia viel zu sehr auf journalistischem Niveau (da zu knapp und selten gut belegt), statt wissenschaftlich fundierter Erkenntnisse bewegt - harter Tobac die Aussage... Aber das wäre ein Thema für Trolls und Flamer á la Apple vs. MS, NB vs. Eclipse und Java vs. .NET in der Plauderecke des Forums...

Das WikiPedia keine Akademische Quelle ist ist klar & unumstritten, denke aber das FArts Aussage darauf abzielte, dass du Fragen zu Grundlagen hattest (Ist Glassfish auch ein WebServer?), diese erschlägt man nunmal mit FAQs, WikiPedia & Google.

 

[FArt]

Definiere "vollständig" und welche Funktionalität von IIS7 erwartest du?

Welche Antwort erhoffst du dir über diese hinaus?
https://glassfish.dev.java.net/javaee5/webtier/webtechnologies.html
GlassFish Community Downloads
Sun Java System Web Server - Overview

 

[Semox]

Danke Euch beiden!

Manchmal ist es eben doch sehr verlockend, Fragen eben doch in ein Forum zu fragen statt durch 100-200 Webseiten zu scrollen... Tut mir Leid! =) Nichts für ungut...

Dann beeil ich mich mal - mein Sohn schläft endlich und ich habe ganze 50 min Zeit meine Antworten zu ergooglen oder erfragen, bis ich meine Tochter von KiGa abholen darf... *g

Beste Grüße,
Semox

 

[JanHH]

Mann mann, so ein Hickhack.

Glassfish ist ein Application Server mit integriertem Servlet-Container. Selbiger "spricht" auch HTTP und kann neben Servlets auch weiteren Webinhalt ausliefern, ist damit aber quasi "zweckentfremdet". So ist es zumindest beim JBoss, und beim Glassfish meines Wissens nach auch. Man sollte also nicht die volle Funktionalität und Leistungsfähigkeit eines richtigen HTTP-Servers erwarten.

Sofern die angepeilte Applikation nicht explizit die Funktionalität eines Application Servers (konkret, EJBs) benötigt, würde ich allerdings dringend davon abraten, mir sowas an die Backe zu binden, und einen ganz normalen Tomcat benutzen.. ist für alles andere ausreichend und deutlich einfacher zu konfigurieren. EJB-Application-Server sind eine Wissenschaft für sich.

Man kann problemlos eine nette effiziente Webanwendung mit JSF und JPA (Hibernate) programmieren, die im Tomcat läuft. Für "kleinere" HTTP-Aufgaben ist der auch ausreichend (kommt halt drauf an, wieviele Leute auf das System zugreifen wollen). Sonst halt noch Apache installieren, ist alles nicht so schwierig. Selbst wenn es ein Application Server sein muss, ist allerdings wohl der JBoss der Standard, den die meisten Leute vorziehen.

Gruß
Jan

 

[FArt]

Mann mann, so ein Hickhack.

Was meinst du?

Glassfish ist ein Application Server mit integriertem Servlet-Container. Selbiger "spricht" auch HTTP und kann neben Servlets auch weiteren Webinhalt ausliefern, ist damit aber quasi "zweckentfremdet". So ist es zumindest beim JBoss, und beim Glassfish meines Wissens nach auch. Man sollte also nicht die volle Funktionalität und Leistungsfähigkeit eines richtigen HTTP-Servers erwarten.

Sofern die angepeilte Applikation nicht explizit die Funktionalität eines Application Servers (konkret, EJBs) benötigt, würde ich allerdings dringend davon abraten, mir sowas an die Backe zu binden, und einen ganz normalen Tomcat benutzen.. ist für alles andere ausreichend und deutlich einfacher zu konfigurieren. EJB-Application-Server sind eine Wissenschaft für sich.

Man kann problemlos eine nette effiziente Webanwendung mit JSF und JPA (Hibernate) programmieren, die im Tomcat läuft. Für "kleinere" HTTP-Aufgaben ist der auch ausreichend (kommt halt drauf an, wieviele Leute auf das System zugreifen wollen). Sonst halt noch Apache installieren, ist alles nicht so schwierig. Selbst wenn es ein Application Server sein muss, ist allerdings wohl der JBoss der Standard, den die meisten Leute vorziehen.

Gruß
Jan

Auch wenn du dir viel Mühe gegeben hast und selber hier viel geschrieben hast, die Antwort ist nicht richtig.

Was ist ein "richtiger Webserver" und was heißt hier "zweckendfremdet"? Die JEE Spec deckt auch Webanwendungen ab und somit ist ein Webserver in Applikationsservern enthalten. JBoss hat per Default einen kompletten Tomcat im Bauch.
Die Anforderungen bestimmen die Laufzeitumgbung, also z.B. welchen Webserver ich benötige oder ob es vielleicht doch ein Applikationsserver sein sollte. In dieser Hinsicht teile ich also deine Meinung.

Jetzt frage ich mich: war deine aufwendige Anworte besser und hilfreicher als die Links?

Nichts für ungut...

 

[maki]

Selbst wenn es ein Application Server sein muss, ist allerdings wohl der JBoss der Standard, den die meisten Leute vorziehen.

Die Zeiten sind doch längst vorbei, JBoss 4 war noch sehr populär, aber JBoss 5 bei weitem nicht mehr so wie der vorgänger, liegt wohl daran dass es so lange gedauert hatte die aktuelle JEE Spek umzusetzen.

 

[FArt]

Die Zeiten sind doch längst vorbei, JBoss 4 war noch sehr populär, aber JBoss 5 bei weitem nicht mehr so wie der vorgänger, liegt wohl daran dass es so lange gedauert hatte die aktuelle JEE Spek umzusetzen.

Ich denke, es liegt daran, dass die Community langsam einbrincht. Dafür gibt es zwei Gründe:

* die Core-Entwickler ziehen sich aus der Community zurück; schließlich gibt es den JBoss-Support und dafür zahlen die Kunden
* auch im JBoss-Forum werden immer wieder Fragen gestellt, die leicht durch Doku oder Forensuche beantwortet werden können. Zu selbst gelösten Problemen gibt es kaum noch Rückmeldungen und echte Diskussionen kommen sowieso nicht auf. Die Community besteht vorwiegend noch aus Leechern, die zwar Fragen stellen aber selber der Community nichts zurückgeben. Adrian Brock hat da desöfteren mal sehr extrem reagiert, aber der hat mittlerweile auch lieber seinen eigenen Blutdruck im Blick und zählt lieber mal bis 10... oder bis 1000

Dadurch verliert der JBoss an Attraktivität. Die Technik darunter kann es jedenfalls nicht sein.

 

[bygones]

ui - neue sachen gelernt... was loest JBoss dann grad ab ?

 

[JanHH]

Mit "Webserver" meinte ich: HTTP-Server. Ein "nativer" solcher wie Apache ist ja doch effizienter, wenn es ums Ausliefern von grossen Dateien (Bildern, Filmen) usw geht, sowas würde ich nicht einem eingebetten Servlet Container, der halt "auch" HTTP spricht, aufbürden. Zumindest nicht dann wenn nenneswerte Mengen an Zugriff auf die Seite stattfinden.

Die HTTP-Fähigkeiten der Servlet-Container dienen ja, denke ich mal und habe ich auch schon öfters gehört, vorwiegend einer einfachen Konfigurationsmöglichkeit zu Entwicklungszwecken, aber nicht dem Produktivbetrieb.

Würde die Kernfrage des Threads allerdings eher darin sehen, herauszufinden, ob für den Threadstarter nicht ein Tomcat die beste Lösung wäre. Eine Diskussion über den angesagtesten Appliaction Server scheint mir hier fehl am Platze.

 

[JanHH]

Eigentlich ist es auch eine Frage der Begriffsdefinition.. Was ist ein "Webserver" eigentlich genau? Eigentlich teilt man ja auf in Servlet Container, Application Server und HTTP-Server.

 

[maki]

Mit "Webserver" meinte ich: HTTP-Server. Ein "nativer" solcher wie Apache ist ja doch effizienter, wenn es ums Ausliefern von grossen Dateien (Bildern, Filmen) usw geht, sowas würde ich nicht einem eingebetten Servlet Container, der halt "auch" HTTP spricht, aufbürden. Zumindest nicht dann wenn nenneswerte Mengen an Zugriff auf die Seite stattfinden.

Die HTTP-Fähigkeiten der Servlet-Container dienen ja, denke ich mal und habe ich auch schon öfters gehört, vorwiegend einer einfachen Konfigurationsmöglichkeit zu Entwicklungszwecken, aber nicht dem Produktivbetrieb.

Würde die Kernfrage des Threads allerdings eher darin sehen, herauszufinden, ob für den Threadstarter nicht ein Tomcat die beste Lösung wäre. Eine Diskussion über den angesagtesten Appliaction Server scheint mir hier fehl am Platze.

Die Zeiten in denen man einen Apache Server mit mod_jk vor den Tomcat geschaltet hat nur der Performance wegen sind imho vorbei, zumindest seit 4.0.

 

[FArt]

Die Zeiten in denen man einen Apache Server mit mod_jk vor den Tomcat geschaltet hat nur der Performance wegen sind imho vorbei, zumindest seit 4.0.

Na ja, statische Inhalte liefert der Apache (besonders unter Last) immer noch schneller aus als der Tomcat. Und ein Loadbalancing lässt sich mit mod_jk auch noch wesentlich einfacher und flexibler realisieren.

 

[maki]

Ja, ist aber imho nicht mehr die Regel, so wie es früher mal war, seit TC 4.0 ist der TC nicht mehr ganz so langsam, da lohnt sich ein vorgeschalteter Apache imho erst wenn wirklich große Last auf dem WebServer .

 

[JanHH]

Ich finde es auch sinnvoller, den Tomcat vom HTTP-Bedienen zu entlasten. Die Frage ist doch auch, wie komplex das ist, was innerhalb des Servlets abläuft. Der Tomcat sollte seine volle Power schon dafür nutzen können. Ausserdem ist der Apache ja ein "richtiges" Programm (nativer Maschinenecode), während Tomcat ja auch "nur" java ist. Es kommt natürlich wirklich auf den Einzelfall an. Für eine kleine intranet-Anwendung, bei der nicht viel los ist, reicht der Tomcat natürlich locker aus. Aber der Threadstarter schweigt dazu ja .

 

[maki]

Ich finde es auch sinnvoller, den Tomcat vom HTTP-Bedienen zu entlasten. Die Frage ist doch auch, wie komplex das ist, was innerhalb des Servlets abläuft. Der Tomcat sollte seine volle Power schon dafür nutzen können. Ausserdem ist der Apache ja ein "richtiges" Programm (nativer Maschinenecode), während Tomcat ja auch "nur" java ist. Es kommt natürlich wirklich auf den Einzelfall an. Für eine kleine intranet-Anwendung, bei der nicht viel los ist, reicht der Tomcat natürlich locker aus. Aber der Threadstarter schweigt dazu ja .

Wie gesagt, für normale Anwendungen lohnt sich meist kein Apache, denn die Komplexität steigt dadurch.

Alles in allem muss man Messen ob es etwas bringt, denn alles andere ist geraten

 

[JanHH]

Naja im Endeffekt muss ja ein und dieselbe CPU die Arbeit verrichten, egal ob sie ihre Taktzyklen dem Tomcat oder dem Apache schenkt. Insofern hast Du wohl Recht. Man neigt aber dazu, davon auszugehen, dass nativer Code deutlich effizienter läuft als java-Bytecode, aber das ist wohl auch schon seit einiger Zeit nicht mehr der Fall..

 

[Noctarius]

.. aber das ist definitiv auch schon seit einiger Zeit nicht mehr der Fall..

zu mindestens nicht in jedem Fall

 

[JanHH]

Aber wenn man jetzt ein Multiprozessorsystem hat, macht der Apache dann nicht wieder richtig Sinn? Weil sich das hervorragend auf die verschiedenen CPUs aufteilen lässt?

Aber der Herr Threadstarter sollte endlich mal darlegen, wieviel Auslastung seiner Applikation eigentlich zu erwarten ist. Und/oder wieviel Erfolg er mit Glassfish hatte.

 

[Noctarius]

Tomcat ist eine Java Anwendung, die teilt ihre Threads sowieso auf möglichst viele Cores auf

 

[maki]

Die Frage ist auhc, ob mod_jk richtig konfigueriert ist, ist auch nicht ohne.

Einen Apache davorzuschalten hat natürlich auch andere Gründe als Performance, aber wie gesagt, "normal" bzw. häufig ist dieses Setup heutzutage nicht mehr.

 

[Noctarius]

Wir nutzen AJP um die Webanwendungen an die verschiedenen Domains zu binden. Brauchen würde man es nicht aber die VHOST Config von Apache ist fein

 

[Sergeant_Pepper]

Die Frage ist auhc, ob mod_jk richtig konfigueriert ist, ist auch nicht ohne.
Einen Apache davorzuschalten hat natürlich auch andere Gründe als Performance, aber wie gesagt, "normal" bzw. häufig ist dieses Setup heutzutage nicht mehr.

Was würde man denn heute machen, um ein Load Balancing zu realisieren?

 

[maki]

Was würde man denn heute machen, um ein Load Balancing zu realisieren?

Klar, dazu schaltet man einen Apache vor.

 

[9xklug]

Macht man üblicherweise mit einem Hardware Loadbalancer...