Article,
Wie rich darf's denn sein?
Java Magazin, (2008)
Abstract
Absolut super Artikel zur Architektur zwischen Server und Client. Das erste Mal werden sinnvolle Definitionen zu den Begrifflichkeiten gebracht und nicht dieser historische Kauderwelch. Wichtigste Definition: Fat bedeutet alles was Teile der Businesslogik auf dem Client hält. Das fängt schon mit einfachen Validierungen die Programmspezifisch sind an - also alles was sich nicht generisch z.B. über reguläre Ausdrücke formulieren lässt. Die Berechnung des Preises im Warenkorb auf dem Client ist ein sicheres Zeichen für Fat Client, da hier diverse Daten zum Client geladen und dort verarbeitet werden müssen. Sprich Logik auf dem Client ist Fat mit ganz wenigen Ausnahmen - die in der Regel keine Rolle spielen. Typische Beispiele: Die Client-Server Anwendungen der 80er ala Powerbuilder. Die Logik war auf dem Client nur die Daten waren auf dem Server. Es werden 2 Architekturtypen dargestellt und verglichen: 1) Generischer Rich Client der Thin Ansatz 2) Der implementierte Rich Client der Fat Ansatz zu 1) Es ist ein Client gemeint, der wirklich nur das Rendering der Dialoge übernimmt. Bei den Mainframes in den 70er war es das Terminal welches Character vom Server bekam und wieder welche zurück schickte. In den 90er war es der Browser der HTML (auch Character) bekam und zurück schickte. Wichtige Merkmale: Der Zustand liegt auf dem Server. Verarbeitung erfolgt auf dem Server. Entscheidungen erfolgen durch Roundtrip über den Server. (Client ist dumm kann nichts entscheiden, weiss nicht mal was er darstellt). Vorteile: Client ist für viele Anwendungen einsetzbar (egal welche er rendern muss - hauptsache alle kommunizieren im unterstützten Format). Super Trennung zwischen Client und Server. Zur Entwicklung des Clients und der Anwendung können komplett unterschiedliche Entwicklerteams genutzt werden die nicht von einander wissen. Den Client entwickeln ein paar Experten (z.B. Mozilla, oder Microsoft). Die Serveranwendung entwickeln ganz andere Experten. Keine großen Sicherheitskonzepte benötigt, da die Businessschnittstellen nur vom Server angesprochen werden. Nach meiner Meinung wichtig ist allein, das man immer sicher ist mit dem richtigen Client zu kommunizieren. Nachteile: Vorhaltung des Zustandes auf der Datenbank bringt die altbekannten Probleme beim Passivieren und Aktivieren von Sessions oder der Verteilung des Zustandes im Cluster oder ähnliches. Es kommt schnell zu Resourcenengpässen auf dem Server - hier muss von vornherein eine Skalierbare Architektur bedacht werden. zu 2) Teile der Logik werden auf dem Client implementiert. Damit können die Roundtripps zum Server verringert werden weil der Client eine Weile autark arbeitet. In der Praxis geht die Rechnung nicht immer auf, da wenn Du einen Teil der Logik auf den Client ziehst evtl. viel andere Logik mit rüber muss oder doppelt implementiert wird. Die Schnittstellen auf dem Server müssen zusätzlich gesichert werden, da viele Clients über viele Tore an den Server rangehen und dort direkt Businessmethoden aufrufen. Die Last verteilt sich allerdings besser, da schon viel Last auf den Clients liegt und der Server nur noch mittlere Last abbekommt (Zustandssync an definierten Punkten). Entschungsempfehlung des Autors: - abhängig vom konkreten Szenario 1) bei + umfangreiche Anwendungen mit komplexer, datenabhängiger Logik (also fast alle Webanwendungen) 2) bei + Anwendungen bei denen ein komplexes Datenobjekt an den Client gesendet wird, dort bearbeitet wird und wieder zurück gesendet wird. (typisch Tabellenbearbeitung) Aus meiner Sicht auch für Anwendungen der Aussendienstmitarbeiter sinnvoll allerdings muss man dort ein geeignetes Datenobjekt finden was nicht geshared ist.
