Zusammenhang Präsentation und Browser

??? heißt: Noch zu klären.

X-Window System

Es gibt das X-Window System, welches Betriebsystemübergreifend eine graphische Präsentationsschicht darstellt. Das Protokoll ist auf elementarer Ebene (Linien, Pixmaps usw.). Das Abstraktionsniveau ist also sehr niedrig.
Es ist hervorragend dazu geeignet, Visualisierungen von Graphiken, die auf schnellen Hochleistungsrechnern erzeugt werden, auf Workstations darzustellen.

SGML/XML und Browser

Die Struktur von Dokumenten (Objekten) kann man sehr gut mit SGML/XML darstellen. Daher ist das Abstraktionsnivau sehr hoch. Ansehen kann man sie mit sog. Browser-Programmen, die dann zusammen mit Darstellungsvorschriften dann ein sichtbares Dokument ergeben, also eine konkrete Ausprägung herstellen.
Transportiert man diese Dokumente über das Internet, ergibt das zusammen mit dem Verweismechanismus das WWW. Dank der hohen Abstraktion braucht man weniger Daten zu transferieren.

Die Darstellungsaufgabe haben also sowohl der Browser als auch das Betriebssystem.
Gebräuchliche Muster wie die GUI-Elemente (Label,Button,Scrollbar, Fensterelemente) sind wegen der besteren Leistung sehr gut auf der Präsentationsebene (Browser/X-Server) aufgehoben. Die Idee ist also naheliegend, das HTTP und das X-Window-Protokoll zu integrieren.
Das hatte das Broadway-Projekt des X-Konsortiums vor.

Frage: Was ist daraus geworden ???

Browser und was daraus geworden ist

Durch das WWW wurde das Internet populär und auf allen gebräuchlichen Arbeitsstationen und Persönlichen Computern (PC) wurden HTML-Browser implementiert.
Um den Nutzern und Bedienern ein integriertes und einheitliches Instrument zur Hand (bzw. zur Maus) zu geben, wurden z.B. im populären Netscape-Communikator mehrere Clients für Dienste integriert.
Um auch lokal Dokumente ansehen zu können, sind auch hierzu Möglichkeiten eingebaut. Dann liegt nahe, auch eine file://-URL zu definieren.
Noch weiter gedacht und die Parole "Das Netz ist der Computer" hinzugenommen, soll dem Nutzer/Bediener eine einheitliche Sichtweise gegeben werden, und so kam (u.a) Microsoft auf die Idee, daß der Browser mit dem Dateimanager/Explorer zusammen fallen kann (und zudem kann man auch andere aus dem Markt drängen).
Ähnlich ist auch der Dateimanager in KDE auch ein Browser.

In HTML gibt es auch Formulare.

In Prinzip entsprechen die Browser etwas fähigeren Terminals aus der Großrechner zeit, die ein paar Editierfunktionen im Terminal selbst ausführen und wenn das Formular/Maske fertig ausgefüllt ist, an den Server abgesandt werden.
Somit liegt die Idee nahe, viele Clients, z.B. Betriebswirtschaftlicher Anwendungen (z.B. die Erfassung von Auftrags- und sonstigen Transaktionsdaten) über das WWW/HTTP abzuwickeln, somit wird der Browser zum universellen Client.

Browser,Applets und die CORBA-Technologie

Bei den leistungsfähigen PCs und Arbeitsstationen können auch Berechnungen sowie Animationen auf den Client in der Browser-Umgebung verlagert werden, um Netzwerkbandbreite und Serverleistung zu sparen. Dazu werden auf virtuellen Maschinen, die von der Architektur abstrahieren (und somit auf allen ausgeführt werden können) aus dem Internet geladende Programme ausgeführt. (Wegen der Möglichkeit von Schadensprogrammen wie Viren usw. muß diese Maschine gefährliche Elementarfunktionen abfangen bzw. durch einen Sicherheitsmanager genehmigen lassen.)

Graphische Animationen lassen sich sehr gut mit solchen Applets realisieren.

Sobald ein Zustandskontext im verwaltet werden muß, ist das HTTP nicht mehr gegeignet, und CORBA, bzw. das IIOP ist besser, da nun Objekte ins spiel kommen.

Wegen der oben angesprochenen Universalität des Browsers ist ein ORB im Browser zweckmäßig.

Netzwerkcomputer

Obige Ausführungen legen nahe, daß für viele Fälle ein Monster-Browser mit einem ORB für sehr viele Anwendungsfälle ausreichend sein kann, wenn entsprechende Server und Netzwerkverbindungen vorliegen. (Historisches Vorbild sind die Terminals).

Grundsätzlich brauchen diese eigentlich keine Festplatte.
Es ist aber durchaus wünschenswert, daß nicht bei jedem Auschaltungen aufgrund Arbeitspausen oder gar Ausfällen (Strom, Heisenbugs in der Software) jedesmal die ganze Software aus dem Netz geholt werden muß. (Szenario: Großraumbüro schaltet um 8 Uhr alle Arbeitsstationen an ...).
Wenn die PCs sowieso handelsüblich eine Festplatte hat, liegt es nahe, die Software auf dieser zu cachen. (zudem ist Swapen über das Netz sowieso nicht gut für die Bandbreite und die zufriedenheit des Nutzers und daher sehen wir Swapspace auf den Rechner vor.)

Die Binaries der Software sowie Scripte und Dokumentationen haben die positive eigenschaft, daß sie sich nie ändern,es kann nur neue Versionen geben. Also liegt die READ ONLY-Semantik vor.

Die persistenen Daten der Anwendungen und die Transaktionen darauf werden auf den Servern gehalten und behandelt.

Die Implementationen der CORBA-Objekte befindet sich im Implementationrepository.
Im Prinzip ist es egal ob es nun CORBA-Komponenten oder andere Binaries und Schared Libraries sind, sie können uniform verwaltet werden.

Die Netzwerkcomputer sollten möglichst keine Administration erfordern. Die Softwareupdates (und eventl. Lizenzen, wobei Client Software ohne Server macht wenig sinn, deswegen kann einfach die Nutzung über Audit-Dienste berechnet werden) sollten zentral verwaltet werden.

Das Hinterlegen von Software könnte nun nach dem push oder pull-Verfahren erfolgen:

Push: Von einem Server aus werden neue Versionen in den Software-Cache geschoben
Pull: Der Client fordert die Software von einem Server an