Application Server Vorteile? [Archiv]

Exxtreme

2010-11-28, 23:08:43

So, habe mich ins Thema Application Server ein wenig eingelesen. Nur frage ich mich wozu man sowas eigentlich braucht. Ein stinknormaler Client, der alles enthält reicht doch auch oder nicht?

RattuS

2010-11-28, 23:28:39

Vielleicht verstehe ich nicht, was du meinst, aber die Vorteile eines App Servers liegen doch auf der Hand, sofern sie denn benötigt werden:

Dezentralisierung von Anwendungen (Clients benötigen keine zusätzliche Installation)
bessere Skalierbarkeit bei Anwendungen (z.B. bei Lizenzen, Anzahl von Zugriffen etc.)
u.s.w.

Ganon

2010-11-29, 00:08:05

Kommt drauf an was du machen willst. Rich-Client Anwendungen haben meist einen ganz anderen Einsatzbereich, als serverseitge Anwendungen.

Wenn du es dir "erlauben" kannst auf jeden Client eine Java-VM zu installieren und diese auch genug Leistung für diese Aufgaben hat, dann widerspricht nichts dem Rich-Client Konzept. Soll deine Anwendung aber von einem Telefon oder von einem Bibliotheks-PC (aka Gastzugang) auch funktionieren, kommst du mit Rich-Clients nicht weiter.

Auch wenn deine Anwendung auf einem Terminal-Server laufen soll, macht es sicherlich keinen Spaß bei 200 Nutzern 200 mal die Java-VM zu starten. Das wären 3GB RAM nur für die ganzen VMs ohne deine Anwendung selbst.

Ich persönlich würde im Business-Bereich von Rich-Clients Abstand nehmen. Die haben imo dort keine Zukunft mehr.

Monger

2010-11-29, 00:16:05

Ein Application Server den nunmal jeder kennt, ist der Web Application Server, wie z.B. die ganzen Google Produkte (Google Maps, Mail etc.). Das ist Code der Serverseitig läuft, nur ein relativ rudimentäres Frontend läuft auf dem Client.

Der größte Vorteil davon ist wohl die breite Verfügbarkeit: jeder Rechner der einen halbwegs aktuellen Browser hat, kann ohne Installation und zusätzliche Plugins beliebige Programme ausführen. Da auch praktisch die gesamte Rechenlast nur beim Server liegt, ist auch die Hardwareausstattung des Clients ziemlich irrelevant.
Der PC dient dann nur noch als Thin Client: er übernimmt nur die Darstellung, alles andere liegt zentralisiert auf einem Server.

Diese Idee ist übrigens weit älter als der PC. Terminaldienste gab es lange vor dem Siegeszug des Home PC! ;)

Ectoplasma

2010-11-29, 00:22:52

Die meisten Anwendungen in mittleren und großen Betrieben sind heute WEB-Anwendungen, deren Natur es ist dezentral zu laufen. Die Vorteile liegen klar auf der Hand. Das einzige, was auf einem Arbeitsplatz installiert sein muss, ist ein Browser. Jedes OS besitzt so einen Browser.

Und ganz nebenbei. In vielen Betrieben ist immer noch IE6 einer der meist benutzten Browser. So allmählich geht es zu höheren Browser-Versionen.

darph

2010-11-29, 00:46:24

Und ganz nebenbei. In vielen Betrieben ist immer noch IE6 einer der meist benutzten Browser. Gibt's dazu eigentlich neuere Zahlen?

Exxtreme

2010-11-29, 08:28:12

Dezentralisierung von Anwendungen (Clients benötigen keine zusätzliche Installation)
Aber ein Frontend braucht so eine Anwendung. Und ob ich das Frontend oder gleich die ganze Applikation installiere ist gehüpft wie gesprungen.

Btw. gibt es irgendwo eine gute Beschreibung wie ein Application Server funktioniert?

Gast

2010-11-29, 10:37:21

Shink

2010-11-29, 10:54:38

Gibt's dazu eigentlich neuere Zahlen?
Ist mir nicht bekannt. Dass IE6 von z.B. Google nicht mehr unterstützt wird bedeutet aber auch bei manchen Betrieben ein Umdenken.
Wenn dann tatsächlich umgestellt wird dann meist auch gleich auf IE8.

Exxtreme

2010-11-29, 11:14:02

Genau. Bestes Beispiel z.B. SAP: Es ist total sinnlos, das auf dicken Servern im RZ zu installieren, und den Nutzern dann nur das SAP-Gui auf den PC zu geben, damit sie im System arbeiten können, genausogut könnte man das SAP-System ja auch auf jedem User-PC installieren.

Ok, zugegeben extremes Beispiel, aber merkst worauf ich hinauswill?
Hmmm, ich sehe da den Vorteil nicht. Ob ich ein GUI oder ein GUI + Programmlogik installiere ist gehüpft wie gesprungen. Application Server bedeuten eigentlich viel mehr Aufwand. Man muss zusätzlich eben diesen Application Server zur Verfügung stellen etc.

Shink

2010-11-29, 11:30:14

Exxtreme

2010-11-29, 11:48:05

Naja, am Server liegt nunmal z.B. die ganze Programmlogik, Business-Prozesse und -Regeln etc.
Wenn es da eine Änderung gibt muss man die nur auf den Server ausrollen und nicht auf alle Clients (bei denen z.B. vielleicht gerade der PC ausgeschalten ist oder das Programm Tag und Nacht läuft).
Sobald du zusätzliche Schaltflächen einbaust dann wird u.U. auch ein neuer Client fällig. Den einzigen Vorteil den ich bisher sehe, ist dass man die Leistung der Anwendung erhöhen kann ohne die Clients austauschen zu müssen. Einfach einen fetteren Application Server hinstellen und fertig.

darph

2010-11-29, 11:53:45

Sobald du zusätzliche Schaltflächen einbaust dann wird u.U. auch ein neuer Client fällig. Den einzigen Vorteil den ich bisher sehe, ist dass man die Leistung der Anwendung erhöhen kann ohne die Clients austauschen zu müssen. Einfach einen fetteren Application Server hinstellen und fertig.
Grundsätzlich bietet sich das doch bei jeder Applikation an, bei der Daten von verschiedenen Benutzern miteinander in Relation stehen.

Und wenn ich jetzt sowieso eine zentrale Datenbank habe, warum dann nicht gleich einen Großteil des Models auch auf diesen Server legen? Dann kann ich hier, was die Aufbereitung der Rohdaten angeht doch wesentlich schneller und flexibler agieren, als wenn ich das alles immer wieder in einem monolithischen Block "deployen" muß.

Außerdem kann ich dann den Nutzern auch nur die View geben, die sie für ihre Aufgabe auch brauchen. Das geht sogar noch schöner und einfacher, wenn auch die View vom Server geladen wird (also zum Haifisch jede Web-App).

Das MVC-Pattern ist dir ja ein Begriff. Das Ganze nur noch weiter gedacht.

user77

2010-11-29, 11:58:09

Ich kann jetzt für unser system sprechen und was es erleichtert hat:

was passiert wenn ein user-pc kaputt geht?

ohne App server -> du musst nen neuen PC wieder für den user einrichten, kann je nach anzahl der Programme und anderen einstellungen mehrere Stunden dauern.

mit App Server -> du gibts ihm einem Thinclient, und er meldet sich wieder mit seinen Benutzerdaten an und hat alles wie es war.

was ist wenn ein User in einem anderen Standort ein Programm braucht?

ohne Appserver: du schickst ihm einen CD, er legt sie ein und du installieren per Remote.

mit Appserver: du fügst den User du der Gruppe des Programms am Server hinzu und sofort hat er das Programm am desktop

das sind sachen, die mir als admin das leben erleichtern.

Shink

2010-11-29, 12:58:12

Sobald du zusätzliche Schaltflächen einbaust dann wird u.U. auch ein neuer Client fällig.
Naja; man wird niemanden finden der einen zwingt den Client so bescheuert zu machen dass er bei jeder zusätzlichen Schaltfläche neu installiert werden muss.

Matrix316

2010-11-29, 14:22:32

Sobald du zusätzliche Schaltflächen einbaust dann wird u.U. auch ein neuer Client fällig. [...]
Nicht bei einer Web Anwendung. ;)

Es ist halt ein ganz anderer Aufwand wenn ich nur den Server aktualisieren muss, und vielleicht sogar die Clients vom Server aus (Avira Server z.B.) als wenn ich von PC zu PC rennen muss und einen ganzen Tag oder mehr nur am installieren bin.

Exxtreme

2010-11-29, 15:50:37

Nicht bei einer Web Anwendung. ;)
Dazu braucht's schon eine gute Portion Masochismus um sich Webanwendungen anzutun.
Es ist halt ein ganz anderer Aufwand wenn ich nur den Server aktualisieren muss, und vielleicht sogar die Clients vom Server aus (Avira Server z.B.) als wenn ich von PC zu PC rennen muss und einen ganzen Tag oder mehr nur am installieren bin.
Bei der Webanwendung mag das ja der Fall sein. Andererseits gibt es Frontends, die keine Installation brauchen. Die schiebt man bei Bedarf auf den Client und fertig.

Frucht-Tiger

2010-11-29, 16:31:53

Der Thread Titel ist unglücklich gewählt, was du eigentlich meinst ist eine Thin- vs. Rich-Client Gegenüberstellung. Application Server sind ja nur eine mögliche Basis für Client/Server Anwendungen.

xxxgamerxxx

2010-11-29, 16:33:08

Also prinzipiell sind das ja Begriffe aus dem Bereich Distributed Computing. Und den gibt's IMO seit den 70er. Die Ideen sind da ja eher, wie man seine Anwendung in Komponenten aufteilt und somit vorhandene Ressourcen am besten ausnutzt.

Der Begriff selbst ist natürlich sehr weitläufig. Im einfachsten Fall ist es ein Server, von dem man eine Anwendung verteilt. Das kann auch ein Fat Client sein. Sehr beliebt wird der Application Server auch in Form von Webanwendungen realisiert. Genau so gut kann da auch ein Dienst (z.B. Windows Dienst) laufen. Oder eben eine komplexe SOA Infrastruktur mit Webdiensten/Remotingdiensten, DTC, ESB usw.

Im Bereich Thin Client hat ein Application Server den Vorteil, dass man eine zentrale Logik hat und hier etwas flexibler ist. Ein Application Server kann natürlich auch cachen, um bei vielen Nutzern den Zugriff etwas zu beschleunigen.

Coda

2010-11-29, 16:46:11

Ein Application Server den nunmal jeder kennt, ist der Web Application Server, wie z.B. die ganzen Google Produkte (Google Maps, Mail etc.). Das ist Code der Serverseitig läuft, nur ein relativ rudimentäres Frontend läuft auf dem Client.
Also eigentlich läuft nur das "Model" auf dem Server. Bei Google Maps dürfte weitaus mehr Code auf dem Client laufen, der Server stellt ja im wesentlichen nur die statischen Map-Tiles zur Verfügung. Oder verstehe ich dich gerade falsch?

Monger

2010-11-29, 16:59:38

Also eigentlich läuft nur das "Model" auf dem Server. Bei Google Maps dürfte weitaus mehr Code auf dem Client laufen, der Server stellt ja im wesentlichen nur die statischen Map-Tiles zur Verfügung. Oder verstehe ich dich gerade falsch?
Ich weiß es nicht. Die ganze Datenbank die hintendran die Map Tiles verwaltet, aktualisiert, komprimiert... die auch erstmal die Suche auf die Koordinate X,Y macht und die dafür relevanten Tiles zusammen sucht...

Von der Datenmenge her ist es natürlich sowieso deutlich mehr, aber ich hätte jetzt vermutet, dass der Server bei Google Maps schon deutlich mehr zu tun hat als der Client.
Ist eventuell auch ein schlechtes Beispiel. Google Mail ist da sicherlich eindeutiger: der Client macht da fast gar nix. Die ganze Such- /Sortier Logik z.B. von den Mails wird nunmal serverseitig abgefahren.

Shink

2010-11-29, 17:01:40

Der Server stellt ja im wesentlichen nur die statischen Map-Tiles zur Verfügung. Oder verstehe ich dich gerade falsch?
Naja; das und den Code den der Client dann ausführt.

xxxgamerxxx

2010-11-29, 17:17:41

Bei einer heutigen Webanwendung kann man auch nicht so klar die Linie zwischen Client und Application Server ziehen, da ja der Application Server i.d.R. bei heutigen Webframeworks erst mal die GUI rendern muss, bevor sie überhaupt auf dem Client angezeigt werden kann. Mit Ajax verschiebt sich das vielleicht ein wenig, ändert aber nichts am Grundprinzip.

robobimbo

2010-11-29, 17:23:28

Wenn zentrale Datenhaltung, dann Application Server, denn der übernimmt:
==> Replikation zwischen verschiedenen Datenstores
==> Transaktionen damit es zu so wenig Dateninkosistenzen wie möglich kommt
==> Ausfallssicherheit

Mit welcher Technologie du drauf zugreifst oder in was dahinter die Daten gespeichert werden ist eigentich völlig irrelevant.

Demirug

2010-11-29, 19:24:34

xxxgamerxxx

2010-11-29, 19:36:05

Ein wenig ist gut. Eine richtige RIA ist hat mehr von einem Fat-Client als von einer Webanwendung.

Bei richtigen RIA Anwendungen ist das bestimmt so, dass der Client zu 99% die GUI ausführt. Aber selbst dann sind die von Fatclients noch weit entfernt und ähneln eher Thin/Smart Clients, denn die Kommunikation geht ja eigentlich nur über REST. Und der Client kann ja bei jedem Aufruf ganz einfach vom App Server eine andere Version bekommen.

Gast

2010-12-01, 18:48:43

Vielleicht sollte beim Client mehr differenzieren.

- HTML mit evtl. ein wenig JavaScript und Ajax

Bei dieser Variante wird eigentlich alles, bis auf die kleinen JavaScript - "Schnippsel", vom Server gerendert (das ist nach wie vor die bevorzugte Methode).

- nur JavaScript mit Ajax

Bei dieser Methode liefert der Server zwar noch den Content aus, gerendert wird aber auf dem Client. Diese Methode hat sehr viele Nachteile. Das Debugging von JavaScript ist eher schlecht und Syntaxfehler treten erst zur Laufzeit auf.

- Java Swing Client

Bei dieser Methode verkommt der App Server eher zum "Datendurchreicher". Ein App Server könnte aber auch hier noch Vorteile bringen, falls die Business Logik doch komplex sein sollte.

Von Vorteil bei allen drei Methoden ist, dass sowohl die Datenquelle, als auch die Businesslogik zentral verwaltet werden können. Man sollte insgesamt im Auge behalten, dass ein App Server eher in Unternehmen angesiedelt sind. Im Privaten bereich lohnt sich ein App Server wohl kaum.