3 Software Das CoBrow-System wurden an der Universität Ulm entwickelt. Es setzt sich aus serverseitigen und klientenseitigen Komponenten zusammen. Sowohl Server als auch Klienten können grundsätzlich auf verschiedene Art, bezüglich verwendeter Programmiersprachen und Funktionsmechanismen realisiert werden. Der folgende Abschnitt "Funktionsprinzip" stellt deshalb die Funktion des Systems unabhängig von der Implementierung dar. Daran schließenden sich Beschreibungen der existierenden Software, sowie der Planung für die nähere Zukunft an. 3.1 Funktionsprinzip Einfache Online Präsenz Dienste stellen den online status dar, d.h. sie zeigen an, ob andere vorher eingestellte Partner ihren Arbeitsplatzrechner eingeschaltet haben, resp. am Internet angeschlossen sind. Online Präsenz Dienste wachsen zur Zeit sehr schnell. Online Präsenz ist dabei einer der großen Internet Dienste zu werden. Inzwischen sind bei AOL/ICQ mehrere Millionen Teilnehmer registriert. Virtuelle Präsenz kombiniert die Funktionalität der Online Präsenz mit dem World Wide Web. Ein Virtueller Präsenz Dienst (VPS virtual presence service) geht weit über einfache Online Präsenz hinaus. Während bei Online Präsenz nur die Tatsache ausgewertet wird, daß ein Benutzer aktiv ist, spielt bei Virtueller Präsenz der virtuelle Aufenthaltsort eines Benutzers im World Wide Web die wesentliche Rolle. Anhand des virtuellen Aufenthaltsorts, der Verknüpfung von WWW Seiten und server- sowie klientenabhängiger Parameter erzeugt der VPS dynamisch Listen von virtuellen Nachbarn. Die bei einfachen Online Präsenzdiensten werden diese Listen dagegen statisch von den Benutzern zu Anfang eingeben. Das Ergebnis des VPS kann schließlich, wie bei Online Präsenzdiensten, z.B. als Namensliste dargestellt werden. Es sind aber auch andere Darstellungsmöglichkeiten denkbar. Beispielhaft wurde eine 3 dimensionale Darstellung der virtuellen Nachbarn vor dem Hintergrund der Seitenstruktur eines Web-Servers implementiert. Trotz Ähnlichkeiten in der Darstellung laufen bei Virtueller Präsenz wesentlich komplexere Vorgänge ab. Während sich Online Präsenzdiensten nur in einer aus Klienten und Server bestehenden "kontrollierten" Umgebung ablaufen, entsteht Virtuelle Präsenz vor dem Hintergrund des World Wide Web mit vielen, sich laufend ändernden Randbedingungen in den Bereichen: (WWW-)Klient/Server, Proxy, Firewalls, HTML/Layout, dynamische Inhalte und Sicherheit. Der Virtuelle Präsenz Dienst ist ein schwach gekoppeltes Netzwerk von Servern. Jeder Server ist dabei für einen Bereich des WWW verantwortlich. Diese Bereiche können sehr klein sein, z.B. einige verknüpfte WWW Seiten auf einem Web Hosting Service. Sie können auf der anderen Seite aber auch einen größeren Teil des World Wide Web umfassen. VP-Server verschiedener VP-Bereiche kommunizieren miteinander, um virtuelle Nachbarschaft über die Grenzen von VP-Bereichen zu realisieren. So wird es möglich, virtuelle Nachbarn über die Grenzen von WWW-Servern und VP-Servern hinweg zu sehen. Die Datenbasis von VP-Servern setzt sich aus drei Komponenten zusammen: 1. Aufenthaltsort von Benutzern (A), 2. Benutzereigenschaften (B) und 3. Linkstruktur des VP-Bereichs (L). Alle drei sind dynamischer Natur. Die Dynamik ist allerdings unterschiedlich groß. Sie nimmt von 1 nach 3 ab. Die Quelle der Informationen hängt vom Szenarium ab. Bei einem typischen Einsatz Virtueller Präsenz für E-Commerce stammt A vom WWW Server oder einer zusätzlichen Spurverfolgungskomponente, B aus einer zentralen Benutzerdatenbank und C vom WWW Server durch regelmäßige Analyse der WWW Seiten. In einem anderen Szenarium können A und B aber auch vom VP- Klienten. L wurde auch schon unabhängig vom WWW nicht aus HTML-Seiten, sondern direkt aus der Dokumentendatenbank extrahiert. Ein VP-Server muß im wesentlichen selbständig, ohne großen Wartungsaufwand laufen. Er gibt nicht Daten aus, wie typische WWW- Server, sondern kommuniziert mit anderen VP-Servern, WWW-Servern und VP- Klienten. Gleichzeitig enthält ein VP-Server Zustandsinformation in wesentlichem Umfang. Diese Datenbasis darf trotz aktiver und passiver Kommunikation mit den oben genannten (potentiell feindseligen) Partnern nicht gefährdet werden. Dazu müssen sowohl im Protokoll (VPP), als auch bei der Implementierung des Dienstes besondere Vorkehrungen getroffen werden. Das Protokoll sichert die Quelle aller Eingaben (auch angeforderter Eingaben) durch Public Key Message Authentification. Die Authentifizierung der Quelle geschieht optional durch vertrauenswürdige Dritte über Benutzer-URIs entsprechend X.509 und PKIX. Der Zweck des VP-Klienten ist die Darstellung der virtuellen Nachbarn. Daneben sind aber aus praktischen Gründen auch Kommunikationsmechanismen, wie ASCII-Chat integriert. Die verwendeten Verfahren sind veröffentlicht und bei der Universität Ulm als Erfindung angemeldet. VPP (Virtual Presence Protocol) ist als Internet-Draft verfügbar (ftp://ftp.ietf.org/internet-drafts/draft-wolf- vpp-01.txt). Bei IANA wurde der TCP/UDP Port 677 für VPS mit VPP reserviert. 3.2 Aktueller Zustand CoBrow (Collaborative Browsing) ist der Projektname des VP-Projekts der Universität Ulm. 3.2.1 Server Der CoBrow Server ist implementiert in ANSI C. Er ist sofort verfügbar für Windows NT, 95/98, SunOS und Linux. Andere Portierungen erfordern eine (geringe) Nachbearbeitung an systemabhängigen Teilen (I/O, C- Header). Der CoBrow Server (Version 1.15.3) wurde bis zu 3.000 Locations (WWW- Seiten) und 30 Benutzern gleichzeitig getestet. Die Belastungsgrenzen liegen bei etwa 10.000 Seiten und 50 gleichzeitig aktiven Benutzern. Benutzerinformationen werden für gewisse Zeit vorgehalten, um sofort wieder verfügbar zu sein, wenn ein Benutzer nach kurzer Zeit zurückkehrt. Die Belastungsgrenze liegt bei 1000 passiven Benutzern. Alle Werte gelten für ein Windows NT Pentium II/200/128MB System. Die Datenbasis wird bei Betriebsende und optional während des Betriebs in lokalen Dateien gespeichert. Der Server ist in weitem Umfang konfigurierbar durch ca. 50 Parameter, die zum Systemstart und zur Laufzeit gesetzt werden können. Der CoBrow Server wird in jeder Version einem ständigen Dauertest mit ca. 1000 Benutzern pro Tag unterzogen. Die Software ist durch den seit über einem Jahr dauernden Betrieb und ständige Verbesserungen sehr stabil und zuverlässig. Die Spurverfolgung ist implementiert als 1. remote Proxy, 2. Apache Modul, 3. ISAPI-Filter (MS IIS), 4. Java Servlet. 3.2.2 Klienten Die Aufgabe des VP-Klienten ist die dynamische Darstellung der virtuellen Nachbarn mit Zusatzinformationen über die anderen Benutzer und Konfigurationsmöglichkeiten. Daneben ist eine Methode zum ASCII-Chat integriert, sowie der Start externer Kommunikationsmittel. Es sind 3 Klienten verfügbar: 1. Java (Version 3.0) 2. HTML (Version 1.0) 3. Win32-3D (Version 2.0) Die Java Implementierung ist die am häufigsten verwendete. Der CoBrow Klient als Java Applet wurde auf geringe Codegröße geachtet, so daß der Klient auch über Modem in kurzer Zeit (10 Sek.) zum Benutzer geladen werden kann. Es existiert eine Variante des Java-Klienten für Gruppenkommunikation mit Gruppenverwaltung. Die HTML Variante wird dann verwendet, wenn der Kunde kein Java Applet einsetzen will. Gründe dafür sind die generelle Vermeidung von Java auf einer Web-Site oder die Existenz von HTTP-Proxies, die Java-Applets filtern. Die 3D-Implementierung zeigt eine dreidimensionale Darstellung einer Web-Site. Die Benutzer werden als Awatare eingeblendet und können dadurch direkt beobachtet werden, wenn sie zwischen Seiten wechseln. Die Implementierung ist in C++ Windows32 native mit Cosmo/VRML-OLE Control. 3.3 Planung Der Zeithorizont der Softwareplanung beträgt 9 MonateManpower-Zahlen beziehen sich auf diesen Zeitraum. Die Softwaredesigns sind fertiggestellt. Die Implementierung der meisten Komponenten läuft. Die Eigenschaften der Komponenten sollen hier nur kurz aufgeführt werden. 3.3.1 Server Auf Basis des Prototyps und zuverlässiger Kommunikations-Middleware wird gerade ein Server der 2. Generation entwickelt (Projektname: CyLand, aktuelle Manpower: 1; geplant: 2). - 1.000 aktive Benutzer - 1.000.000 passive Benutzer - 10.000.000 Locations - SQL-Datenbank und - mehrere VP-Bereiche, pro VP-Bereich Konfiguration - Script Konfiguration für automatischen Hosting-Service - RSA Message Authentication (ab Mitte Jahr 2000 lizenzfrei) - Unterstützung von Plug-Ins, für externe Applikationen, I/O Filter und URL-Mapping 3.3.2 Klienten Zur Zeit werden 2 neue Klienten entwickelt. Die Klienten zielen auf unterschiedliche Szenarien: 1. Java (aktuelle Manpower: 0,5; geplant: 1) 2. Win32 native (aktuelle Manpower: 0,5; geplant: 1) Beide Klienten basieren auf den Kommunikationsmodulen der jeweiligen Vorgänger. Layout und Eigenschaften werden erwarteten Anforderungen des kommerziellen Betriebs angepaßt. Die Kapazität wird auf 1000 Nachbarn erhöht. Der Win32 Klient wird mit zusätzlichen Eigenschaften ausgestattet. Wesentliche Teile liegen schon vor. - Anordnungsvarianten, - dynamische Hervorhebung, - Live-Icons, - Video-Grabber, Audio-I/O, - private Chat Kanäle, - Benutzerprofilserver, - Distributionsfunktionen, - lokales Page-Tracking, - Screen-Space für servergesteuerte Einblendungen. 3.3.3 Benutzerdatenbank Die ständige Benutzerdatenbank wird aus dem VP-Server ausgelagert. Sie übernimmt die persistente Speicherung aller Benutzerprofile und die Auflösung der (im allgemeinen) HTTP-Cookie basierten Benutzeridentifikation zu Benutzerprofilen. Die Benutzerdatenbank ist ein VP-Bereich-übergreifender, evtl. weltweit einsetzbarer Dienst mit einer Tragfähigkeit von 10.000.000 passiven und 10.000 aktiven Benutzern. Die Implementierung geschieht durch einen standard-HTTP-Server mit Datenbank (aktuelle Manpower: 0; geplant: 0,5). Die während des Betriebs des CoBrow Servers an der Universität Ulm gesammelten Profile gehen in die Benutzerdatenbank ein. 3.3.4 E-Commerce Integration Da der erste Einsatz von CoBrow im E-Commerce liegt, wird das CoBrow- System bezüglich Design/Layout und Kundendatenbank mit E-Commerce Produkten integriert. Implementierung geschieht in Form von CyLand-Modulen. Dabei werden sich Details der Implementierungen wechselseitig beeinflussen. Es wurde noch keine Produktauswahl getroffen (aktuelle Manpower: 0; geplant: 1).