Wie nun muß man sich so eine MUtech
vorstellen? Im Gegensatz zu den anderen Komponenten der Living Worlds Struktur,
die eindeutig durch den Standard von VRML 2.0 (der Browser) bzw. Living
Worlds (die Knoten SharedObject und Zone) definiert sind,
ist die MUtech als eine proprietäre Komponente geplant. Das
heißt, wenn sich mehrere Benutzer in einer Szene treffen wollen,
müssen alle dieselbe MUtech benutzen.
Dies scheint nur auf den ersten Blick eine größere
Einschränkung zu sein, denn der Living Worlds Standard gibt vor, daß
die MUtech als VRML PROTO Definition erstellt wird. Diese kann dann
je nach Bedarf beim Aufbau einer Verbindung zu einer Szene von einem Server
übers Internet zugeladen werden und führt dann auf dem eigenen
Rechner ihre Kommunikationsaufgaben aus.
Die einzigen Regeln, an die sich die Entwickler
von solchen MUtechs laut Standard zu halten haben sind eine gewissen
Minimalfunktionalität (z.B. die Unterstützung einer Reihe von
Events wie "messageToPilot" oder "replyToDrone") und vor
allem die, daß die Kommunikation mit dem Browser einzig über
standard VRML 2.0 Skripte erfolgt. Letzteres stellt sicher, daß der
Browser über keine Zusatzfunktionalität neben der Unterstützung
von VRML 2.0 beherrschen muß, und es garantiert, daß jede MUtech
mit jedem VRML 2.0 Browser arbeiten kann.
Der Grund für diese eher bescheidenen festen
Anforderungen an die MUtech ist der gleiche, aus dem man sich überhaupt
erst für eine proprietäre Komponente entschieden hat: Die Technologie
für das Managen von Mulit-User-Welten ist noch recht unausgereift
und ein Bereich für viel Innovation. Hier wollten die Entwickler von
Living Worlds nicht mit festen Regeln eine suboptimale Komponente im Standard
festschreiben. Des weiteren gibt es auch für verschiedene Anwendungsbereiche
unterschiedliche Anforderungen an die MUtech, sodaß es eine
optimale für alle Fälle nicht geben kann. Stattdessen wird erwartet,
daß für verschiedene Anwendungen spezialisierte MUtechs
entstehen werden.
Nun da alle Komponenten von Living Worlds eingeführt worden sind, hier noch einmal eine grafische Übersicht (vrml.org 97 (1)):
Die neu in Living Worlds eingeführten Konzepte,
nämlich die MUtech und die verteilten Objekte, sind in dieser
Darstellung ocker eingefärbt. Des weiteren ist hier zu erkennen, daß
der VRML 2.0 Browser zwischen diesen beiden als Vermittler fungiert. Neben
der Benutzerschnittstelle ist schließlich noch eine Komponente mit
der Bezeichnung External Application in dieser Gesamtübersicht
über verteiltes VRML aufgeführt. Diese ist kein Teil von Living
Worlds, sondern gehört zu anderen, parallel laufenden Bemühungen
um eine API (das External Authoring Interface), mit der externe
Applikationen auf den VRML Browser zugreifen können sollen. Über
eine ähnliche Schnittstelle haben tatsächlich die meisten der
bisherigen proprietären Lösungen für Multi-User VRML gearbeitet.
Wichtig für Living Worlds sind insbesondere
die Kommunikationsschnittstellen, die hier mit den Ziffern 2, 3,4 und 7
versehen sind. Ziffer 2 zeigt die Kommunikation zwischen verteilten und
lokalen Objekten, Ziffer 3 den konzeptionellen Fluß von Daten aus
der Objekthaltung in den Browser, ein Weg, den wie jedes andere auch die
verteilten Objekte nutzen. In Ziffer 4 sieht man die Kommunikation zwischen
dem Browser und der MUtech, die, wie oben erwähnt, über
VRML 2.0 Skripte erfolgt. Ziffer 7 schließlich ist die Anbindung
der MUtech an das Netzwerk. Diese wird proprietär von den einzelnen
Entwicklern festgelegt.
Es scheint geradezu erstaunlich, wie wenig strukturelle
Änderungen die Living Worlds Working Group am bisherigen VRML Standard
vornehmen brauchte, um so eine radikale Erweiterung wie den Übergang
von Single-User hin zum verteilten VRML zu ermöglichen.
 |
 |