Die Grundfunktionen: technische Zusammenfassung |
Die virtuelle Messe und das Spiel für mehrere Teilnehmer sind schon Realität. Der Abend bei Anna ist nur insofern Phantasie, als einige Aspekte davon noch nicht zur Marktreife gediehen sind. (So ist z.B. die Technologie der digitalen Authentifizierung zwar bereits seit einigen Jahren verfügbar; uns ist allerdings noch nicht bekannt, daß sie für die Gewährleistung der Ehrlichkeit von digitalen Spielwürfeln eingesetzt wird.)
VRML97 ermöglicht die Interaktion zwischen einem einzelnen Besucher und den Objekten in einer virtuellen Szene. Die Interaktion zwischen mehreren Anwendern sowie die automatische Aktualisierung von Szenenänderungen auf beliebig verteilten Clienten ist das Thema der Living-Worlds-WG.
Standardschnittstellen zu solchen Basisdiensten sind deshalb unerläßlich, weil die meisten GevU-basierten Anwendungen viel zu komplex werden, daß einzelne Autoren sie entwickeln könnten. Sie werden die Funktionalität mehrerer verschiedener Sprachen ausnützen und, wie wir bei Anna gelernt haben, auch die Dienste mehrerer Betreiber in Anspruch nehmen. Die Steuerung mancher Objekte wird durch menschliche Willkür bestimmt. Andere werden von verschiedenen, mehr oder weniger opportunistisch interagierenden Applets gesteuert (vgl. Annas Whiteboard, Bernds Würfel, Claras Sprachpaket und Spaßvogel). Charakteristisch für diese neue Applikationsgattung ist vielmehr ein ständiges Aushandeln: zwischen Objekten, die unabhängig voneinander geschaffen werden und sich oft zum ersten Mal zur Laufzeit begegnen, sowie zwischen VRML-Autoren, die eben durch ihre Code-Beiträge zu mehrfach besuchten VRML-Welten allmählich Teilhaber eines stets wachsenden, stets wandelnden geistigen Schatzes werden.
Ganz klar: Von den einzelnen Autoren lokaler Wohnzimmer kann man nicht erwarten, daß sie sich mit dieser Komplexität unmittelbar auseinandersetzen. Cyberspace ist insofern wie jeder andere moderne Lebensraum; seine Entwicklung setzt eine verläßliche Infrastruktur voraus: Einrichtungen, die allgemein zugängliche Lösungen für die grundlegenden Bedürfnisse wie Transport und Kommunikation, Verkehrsregelung, Geldtransaktionen und Eigentumsschutz bieten.
Kämmen wir also unsere diversen Szenarien gezielt nach Anforderungen an die Infrastruktur durch, können wir zwei Funktionsgruppen bilden, die von den Entwicklern zukünftiger virtueller Welten verlangt bzw. vorausgesetzt werden. Die erste enthält die Grundfunktionen, womit eine Gemeinsamkeit in virtuellen Räumen überhaupt ermöglicht wird; die zweite besteht aus Mechanismen, womit eine adäquate Sicherheit in gemeinsam erlebten virtuellen Umgebungen gewährleistet wird.
Gemeinsamkeit: lokale Ereignisse übers Netz verteilen |
Die Basis einer GevU bildet diejenige Funktionalität, wodurch mehrere Clients sich gegenseitig wissen lassen, wann immer einer angekommen oder weggefahren ist, eine Nachricht gesendet oder etwas in der Szene verändert hat. Es handelt sich um Mechanismen, die:
1) Objekte in verteilten Szenen in Echtzeit
einfügen bzw. löschen. Avatare an-
und abtreten lassen - oder einen RoboCop, der einen ins Gefängnis
steckt... Auf jedem Client muß der Szenen-Graph dynamisch von jedem
anderen Client aus verändert werden können.
2) Objektzustände und -verhalten in
Echtzeit verfolgen und verteilen. Client A muß alles erfahren, was beim Clienten B
passiert und für A relevant ist (z.B., wie die Würfel am Tisch
oder die Bilder von der Wand fallen). Geht es auch um die Clients C, D
usw., dann wird die Frage ,,Wer muß was wie oft erfahren?"
zunehmend kritisch für das Zeitverhalten des Systems - entweder die
Bandbreite im Netz oder die Prozessorleistung am Client wird schnell zum
Flaschenhals. Da verschiedene Clienten immer verschiedene Halsbreiten
haben werden, ist es ein subtiles Problem der dynamischen
Datenverteilung, jeden so weit auf dem Laufenden zu halten, wie es ihm
seine Ressourcen erlauben.
3) Objekte von Extern in Echtzeit steuern
lassen. Sämtliche
persönliche Interaktion, von der Avatarbewegung bis zum
Spielzug am digitalen Schachbrett, baut auf diesen Basismechanismus auf.
Die mitgebrachten Würfel, womit man die Wette gewinnt, und das
allgemeingültige elektronische Geld, womit die Wette ausgezahlt
wird, werden sowohl Benutzerschnittstellen als auch
Programmschnittstellen (APIs) brauchen.
4) Informationen zwischen Objekten
austauschen, von
einfachen Nachrichten-Strings und Multimedia-Daten (z.B. Visitenkarten
mit einem Bild) bis hin zu beliebigen Datenströmen und
-behältern (z.B. einer Datei mit einem Lebenslauf, oder dem
kompletten Satz der 1997er Wartungshandbücher einer
Produktlinie).
5) Importierte Objekte zu permanenten
Szenenbestandteilen machen. Sonst kann Bernd sein mitgebrachtes Brettspiel nicht bei Anna
stehen lassen, wenn er seine Maschine ausschaltet. Dieser simpel
anmutende Anforderung hat ganz und gar nichttriviale Auswirkungen. Wenn
ich jede Szene, die ich betrete, potentiell umgestalten kann, werde ich
de facto einer ihrer Autoren. Was passiert, wenn ich mich
entsprechend verhalte?
Diese Grundfunktionen bildeten das Hauptziel der Living-Worlds-Spezifikation. Das zweite Ziel war, die unzertrennlich damit verbundenen Sicherheitsfragen in den Griff zu bekommen.
Sicherheit: für gegenseitige Verträglichkeit sorgen |
Vertrauen, z.B. auf die Harmlosigkeit so netter Haustiere, wie sie Freunde mitbringen können, ist eine feine Sache; Kontrolle ist aber bekanntlich besser. Die grundlegenden Sicherheitsanforderungen an einer GevU können wir in drei Bereiche unterteilen:
1)
Zugriffskontrolle für
Daten und Funktionen.
Die Basis jedes Mehrbenutzersystems ist der geschütze Zugang zu
Daten und Funktionen. Bevor ein Objekt auf eine Nachricht reagiert,
muß eine Sicherheitsüberprüfung erfolgen. Und nachdem die
Nachricht abgearbeitet ist, soll eine zweite Prüfroutine
kontrollieren, daß nichts zerstört wurde.
Unglücklicherweise bietet VRML97 keine Möglichkeit an, den
Absender einer Nachricht zu bestimmen - wie soll man dann entscheiden, ob
der Inhalt gefährlich sein könnte? Und da Event-Kaskaden laut Spezifikation keine Zeit nehmen, sind
,,vor" und ,,nach" nicht immer ohne weiteres zu ermitteln ...
2) Differenzierter
Transaktionsschütz.
Bei kollaborativen
Anwendungen kommen Konflikte vor, die nicht eindeutig zu lösen sind.
Was passiert, wenn einer die Tür zu schließen versucht, die
ein anderer gerade öffnen will? Oder wenn zwei Benutzer gleichzeitig
dasselbe Buch vom Tisch hochnehmen? Im zweiten Fall könnten beide
Leseratten ein virtuelles Buchexemplar bekommen - aber wie entscheidet
man, wer beim Türgerangel gewinnt?
3) Identitätskontrolle für
Benutzer und ihre Agenten.
Zugriffskontrollen
stellen sicher, daß Objekte nur auf geprüfte Nachrichten
reagieren. Die Identitätskontrolle verlangt Input von einer
unabhängigen Instanz (vgl. die authentifizierten Visitenkarten von
VeriSign, Inc.) sowie verläßliche Pfade innerhalb des Clients,
damit extern beglaubigte Zertifikate nicht lokal gehackt werden
können.
Auch diese Basisfunktionenen - oder genauer, die Schnittstellen, über die dieser Funktionssatz anzubieten wäre - gehören zum Themenbereich der Living-Worlds-WG. Ein erster Lösungsansatz für diese Problematik liegt sogar seit Febuar 1997 vor - die Spezifikation kann auf der CD nachgelesen werden.
Die zweigleisige Akzeptanz von Living Worlds |
Als die Living-Worlds-WG im Oktober 1996 erstmalig an die Öffentlichkeit ging, haben über 40 Firmen und Organisationen im VRML-Umfeld ihr Vorhaben begrüßt und ihre Unterstützung für eine zügige Weiterentwicklung dieses Themas bekundet. Interessant ist deshalb die zweifache Resonanz, die dann der eigentliche technische Vorschlag bisher erfahren hat: (1) die Spezifikation wird vielerorts respektvoll erwähnt; (2) sie ist von niemanden implementiert worden.
Die respektvolle Erwähnungen gelten vor allem der Grundzätzlichkeit, mit der die LW-Gruppe die konzeptionelle und technische Problematik einer GevU erörtert haben. Wenn alle Probleme noch lange nicht gelöst sind, so sind sie wenigstens klar identifiziert und ihre interne Zusammenhänge erläutert.
n Die fehlenden Implementierungen werden vordergründig damit erklärt, daß die unvollständige Java-Unterstützung für Script-Knoten in den maßgeblichen VRML-Browsern eine LW-Implementierung zuerst nicht zuließe. Dieses Argument wird wohl bis Ende 1997 hinfällig werden - und dabei zwei tiefer liegende Gründe enthüllen:
1) VRML97 ist für
die Beschreibung einer GevU grundsätzlich nicht geeignet. Es fehlen
ganz elementare Sprachmittel, womit die Nützung der
GevU-Basisfunktionalität nachvollziehbar programmiert werden
könnte.
2) Das GevU-Thema hat bei
den zwei wichtigsten Browserhersteller nicht die Priorität, die auf
eine schnelle Durchsetzung der notwendigen Spracherweiterungen hoffen
ließe.
Die inneren und äußeren Probleme des Living-Worlds-Ansatzes und die weiteren Implikationen dieser Probleme sind unser letztes Thema. Dabei handelt es sich um zwei ganz verschiedene Problemklassen. Auf der einen Seite liegt die inhärente Komplexität des Funktionsgebietes. Hier war die Aufgabe, Konzepte zu finden, um die natürliche Komplexität in einem nachvollziehbarem Rahmen zu bändigen. Auf der anderen Seite liegt die VRML-bedingte Schwierigkeit der Implementierung. Hier war die Aufgabe, für eine Funktionalität, die völlig außerhalb der VRML97-Semantik liegt, mit welchen Verrenkungen auch immer eine VRML97-konforme Syntax zu basteln.
Die erste Aufgabe wurde von der LW-WG überzeugend gelöst; die zweite wurde - was wohl in der Natur der Aufgabe lag - nur unbefriedigend abgeschlossen.