Weiterentwicklung der Web-Achitekturen

Kommentieren Drucken
Teil 39 von 71 aus der Serie "Professionelle Datenkommunikation"
Alle Artikel der Serie "Professionelle Datenkommunikation":

Abweichend von der bisher historisch orientierten Darstellung kommen wir in dieser Folge zu aktuellen Weiterentwicklungen der Web-Technologie, die sich nach der Jahrtausendwende ergeben haben. Sie ergeben sich aus der Tatsache, dass das Internet mittlerweile zu einer Massentechnologie mit gestiegenen Anforderungen an Funktionalität, Darstellungsqualität und Reaktionsfähigkeit geworden ist. Durch die in späteren Folgen noch zu diskutierende Einbindung vieler wichtiger Geschäftsprozesse reichen die Anforderungen weit in die DV von Unternehmen hinein und es wird einem Unternehmen langfristig nichts anderes übrig bleiben, als ihrer Natur nach die gleichen Technologien einzusetzen, wie dies jetzt schon die Provider tun.

In dieser Einführung muss ja immer ein Bogen zwischen dem aktuellen Stand einer Entwicklung und ihren Anfängen gespannt werden, weil sonst die aktuellen Topics unverständlich bleiben. Im Bereich der Web-Architekturen hat sich ein Wandel von statischen Inhalten zu einer Dynamisierung vollzogen. Dies hat wiederum schwerwiegende Implikationen auf die Struktur und Leistungsfähigkeit der zugrunde liegenden Server und Netze.

In verteilten (Web-)Architekturen entstehen große Mengen von Transaktionen, die von Hauptspeicher zu Hauptspeicher über das Netz ablaufen. Dadurch entsteht eine Kommunikations-Matrix zwischen den Servern im RZ. Es ist sehr wichtig, das zu verstehen. Üblicherweise haben wir in RZ-Netzen die Denkweise, dass ausgehend von einem Versorgungsbereich, der alle Endgeräte, die auf Leistungen des RZs zugreifen, ggf. auch via eines Campus-Netzes zusammenfasst, ein Netzkern durchlaufen wird, der die Kommunikation an die Server, auf denen die Anwendungen laufen, weiterleitet. Das ist letztlich nichts anderes als die Denkweise des klassischen SNA-Netzes, aus den Terminals sind alle möglichen festen und mobilen Endgeräte geworden und die alten Hosts werden durch moderne Server ersetzt. Daran wird sich auch nicht viel ändern, wichtig ist aber, zu verstehen, dass auch die Server selbst in hohem Grade untereinander kommunizieren.

Das war bisher nur im Rahmen einiger ausgewählter Anwendungen so. Moderne verteilte Architekturen und vor allem Web-Architekturen sind aber so strukturiert, dass die Arbeit mehr oder minder automatisch auf viele Leistungserbringer, sprich Virtuelle Maschinen verteilt wird. Das können wir an dieser Stelle nicht ausführlich erklären, ich will aber dennoch versuchen, zumindest den Kern dieser Entwicklung zu charakterisieren.

Die Basis-Idee einer Web-Architektur ist die Kommunikation zwischen Browser und Web-Server auf der Grundlage von http-Requests und –Responses. Funktionen wie Präsentation, Rendering, Caching sowie Authentifizierung und Cookies liegen beim Browser, der Web-Server beinhaltet in einer einfachen Struktur statische Seiten und bedient die Anforderungen des Browsers. Siehe dazu Bild 1.

Mit der Zeit wurden die Webseiten aber dynamisiert, das Ergebnis haben Sie jeden Tag vor Augen. Wenn Sie eine Webseite aufrufen, ist diese nicht statisch, sondern wird im Moment des Aufrufs erst zusammengesetzt. Das hat unterschiedliche Motivationen, eine sehr wesentliche Motivation ist aber neben der Einbindung artfremder Formate vor allem die Aktualität. Eine Webseite mit Börsenkursen würde Ihnen ohne aktuelle Kurse nichts nützen. Also besteht diese Webseite aus einem Rahmen und dynamischen Elementen, die in diesen Rahmen eingebaut werden. Eine weitere Abwandlung gegenüber einer statischen Webseite ist die Möglichkeit der Einbindung von Anwendungen, z.B. solchen, die aktuelle Daten holen, Authentifizierungen und Konversionen durchführen usw. Das ist alles an sich nichts wirklich Neues und führt zu einer dreilagigen Architektur, siehe Bild 2

In dieser Architektur werden Darstellung, Anwendungen und Daten getrennt. Bleiben wir bei der Börsenseite. Der Rahmen, den der Benutzer am Ende sieht, ist die Darstellung, die Anwendungen holen die aktuellen Daten und passen sie an die gewünschte Darstellung an und die Daten selbst liegen auf einem Transaktionsserver z.B. beim Betreiber der Börse. Es hat sich schnell gezeigt, dass ein einfacher Webserver das nicht mehr alleine schafft, sondern dass es sinnvoll ist, eine Unterteilung in einen eigentlichen Web-Server und einen Applikationsserver für die Aufarbeitung der dynamischen Inhalte und die Bereitstellung einer Schnittstelle zum Datenlieferanten vorzunehmen, siehe Bild 3.

Es gibt mit dieser Architektur eine Reihe von Problemen, die wir nur nennen, aber her nicht weiter diskutieren können:

  • Kein etablierter Standard für den Applikations-Server
  • Hoher Erstellungs- und Pflegeaufwand
  • Keine saubere Trennung zwischen Applikationen, Objekten und Daten
  • Wenig wiederverwendbarer Code
  • Fehlende Redundanzfreiheit der Daten
  • Schwierige Skalierbarkeit

Besonders letztere macht den Entwicklern erheblich zu schaffen, denn wenn ein Web-Service erfolgreich ist, hat er auch viele Benutzer mit einer teilweise dramatischen Wachstumsrate.

« Teil 38: Internet-Grundfunktionen (1)Teil 40: Erweiterungen der Grundkonzepte: Java, HTML 3 und XML »


zugeordnete Kategorien: LAN
zugeordnete Tags:

Sie fanden diesen Beitrag interessant? Sie können



Anmerkungen, Fragen, Kommentare, Lob und Kritik:

Ihre E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.

*

.