Tabelle 6.1 Internet-Dienste (Auswahl)

Neben den oben genannten Diensten gibt es noch eine Reihe weiterer mul-timedialer Dienste. Wir kommen deshalb später auf die Themen Audio und Video zurück.

Das World Wide Web (oder kurz das Web) ist der multimediale Dienst des Internet und bietet die besten Verknüpfungsmöglichkeiten. Diese Eigen-schaften machen das Web zu dem Informationsdienst im Internet, der am schnellsten wächst. Im Web kann ein Dokument hervorgehobene Worte oder Bilder enthalten, die mit anderen Medien verknüpft sind. Ein solcher Querverweis (auch Hyper-Link genannt) kann sich z. B. auf Dokumente, Sätze, Videoclips oder Sound-Dateien beziehen. Im Web kann ein Verweis von jeder Stelle eines Dokuments auf eine beliebige Stelle eines anderen Dokuments zeigen. Mehr noch: Die Verweisziele müssen nicht im gleichen Dokument, nicht einmal im eigenen Computer liegen! Das Verweisziel kann auf einem beliebigen Internet-Computer irgendwo auf der Welt lie-gen. Durch das Anklicken von Hyperlinks kann man so durch das Internet „surfen“, ohne sich explizit um Netzadressen kümmern zu müssen!
Im Gegensatz zu anderen Internetdiensten war WWW rasch durchgehend kommerzialisiert. Hier trifft man große Firmen, Zeitschriften-Verlage, Institute und Hochschulen. Waren- und Bücherbestellungen gehören be-reits zum Internet-Alltag. Veröffentlichungen zu lesen, bevor sie auf Papier erscheinen, ist ebenfalls möglich: Ein Vorreiter ist hier Der Spiegel, der einen Teil seiner Artikel im Netz bereits veröffentlicht, bevor das Magazin selbst erhältlich ist. Auch manche Buchverlage praktizieren diese Vorgehensweise.

Das Web wurde ursprünglich am Europäischen Zentrum für Hochenergie-physik CERN in Genf entwickelt. Die Entwicklung begann 1989 unter der Leitung von Tim Berners-Lee. Ein Schwerpunkt der ersten Arbeiten waren die Definition des Client/Server-Protokolls HTTP (Hypertext Transfer Procotol). Neben CERN war lange Zeit das National Center for Super-computer Applications (NCSA) an der University of Illinois in Urbana-Champaign die wichtigste Organisation zur Entwicklung von Web-Software. CERN hat im Frühjar 1995 die Weiterentwicklungs- und Promo-tionsaufgabe für das WWW an das französiche Institut INRIA (Insitut Na-tional de Recherche en Informatique et en Automatique) übergeben. INRIA hatte beim Aufbau des französischen Internet maßgeblich mitgearbeitet und war von Anfang an bei Forschungsprojekten über das Web beteiligt. Die Web-Adresse von INRIA lautet http://www.inria.fr.

Abbildung 6.1 Eine Web-Seite im Navigator von Netscape

Sollen für das Surfen explizite URLs genutzt werden, so sind diese im Eingabefeld „Adresse“ oder „Gehe zu“ einzugeben. Nach Betätigung der RETURN-Taste wird Kontakt mit dem gewünschten Internet-Computer aufgenommen und nach dem Transfer des Inhalts dieser vom Browser angezeigt.

Einer der wichtigsten Knöpfe für den Novizen ist der Hilfe-Knopf (Hilfe-Button). Über ihn gelangt man zum Online-Handbuch, aus dem die fol-gende Beschreibung der Hauptmenü-Leiste des Netscape Navigators ent-nommen ist.

Die Symbolleiste
Mit den Symbolen für „Seite vor“ und „Seite zurück“ kann man sich in der History-Liste bewegen. Die History-Liste ist linear geordnet: Vor längerer Zeit besuchte Seiten liegen in der History-Liste weiter zurück. Hat man mit dem Symbol „Seite zurück“ ältere Seiten aufgeblättert, so kommt man mit dem Symbol „Seite vor“ wieder zu den jüngeren Seiten. Am Ende einer Browser-Sitzung wird die History-Liste gelöscht.

Was während einer Browsersitzung als Homepage gilt, wird unter Bear-beiten | Einstellung | Navigator eingestellt. In der Regel ist hier die Ho-mepage des Browser-Herstellers eingetragen.

Wird das Symbol „Seite neu laden“ betätigt, so überprüft der Browser mit Hilfe des Servers, ob an der momentan angezeigten Seite Änderungen seit der letzten Zustellung durch den Server vorgenommen wurden. Falls das der Fall ist, wird die aktualisierte Seite vom Server geholt. Liegt dort die Seite jedoch unverändert vor, so lädt der Browser die Seite aus dem Cache.

Weitere, direkt aus der Symbolleiste heraus ausführbare Operationen sind das Drucken der aktuellen Web-Seite bzw. des aktuellen Bereichs (Frame), das Suchen im Internet und das Beenden einer laufenden Übertragung einer Web-Seite.

Für die Verwaltung interessanter Web-Seiten steht eine Lesezeichenver-waltung zur Verfügung. Wird eine Web-Seite mit einem Lesezeichen be-legt, so wird die URL der Seite in das Leseverzeichnismenü aufgenom-men. Soll die so registrierte Seite später wieder besucht werden, so muss nicht eine eventuell lange URL eingegeben werden, sondern die Seite wird aus dem Leseverzeichnismenü ausgewählt. Vorteilhaft ist, dass die Lese-zeichen nach Kategorien gebündelt werden können. Neben dem Eintragen von Lesezeichen unterstützt die Lesezeichenverwaltung auch das Löschen, Umorganisieren und noch andere Operationen mit Lesezeichen.

Abbildung 6.2 Die Netscape-Symbolleiste

Sicherheitsindikatoren
Um auf eventuelle Sicherheitsgefahren hinzuweisen, nutzt der Netscape-Browser mehrere Sicherheitsindikatoren, um die drei Sicherheitszustände eines Dokuments zu signalisieren. Aus der Sicht des Browsers gibt es die Sicherheitszustände „sicher“, „unsicher“ und „gemischt“. Ein unsicheres Dokument kann auf dem Weg zu einem Empfänger von Dritten eingesehen und gelesen werden. Für ein sicheres Dokument trifft dies nicht zu: Das Dokument ist verschlüsselt und kann nur von seinem legitimen Empfänger dechiffriert werden. Gemischte Dokumente sind sichere Dokumente mit teilweise unsicheren Inhalten. Neben den Dokumenten können auch Über-tragungsvorgänge gefährdet sein. Bei einem unsicheren Übertragungsvor-gang kann die gesendete Information durch böswillige Dritte gefährdet werden.

Der auffälligste Sicherheitsindikator befindet sich in der linken unteren Ecke des Bildschirms in Form eines Vorhängeschlosses. Ist das Schloss in der Anzeige geöffnet, so ist die dargestellte Seite nicht verschlüsselt. Ein geschlossenes Schloss signalisiert eine verschlüsselte Seite. Detaillierte Informationen über den Sicherheitszustand einer Web-Seite erfährt der Benutzer über die Browser-Menüpunkte Ansicht | Seiteninformation (sie-he: http://home.de.netscape.com/de/info/security doc.html .

Auch die URL gibt über den Sicherheitszustand Auskunft. Server, die das SSL-Protokoll nutzen (Secure Socket Layer), haben im Protokollfeld der URL statt des üblichen „http://“-Eintrages den Eintrag „https://“.

Abbildung 6.3 Zusammenspiel HTML-Browser (Web-Client) und HTTP-Server (Web-Server)

Der Browser registriert das Plug-In und gibt bei Bedarf Auskunft über installierte Plug-Ins. Zu diesem Zweck ruft man beim Netscape Navigator unter „Hilfe“ die Option „Über Plug-Ins“ auf und erhält die Liste der be-reits installierten Tools. Trifft man nach der Installation beim Surfen im Internet auf eine Web-Seite, die ein für das Plug-In erstelltes multimediales Element enthält, so bedient sich der Browser automatisch dieses Plug-Ins zum Abspielen der Animation, des Video- oder Musik-Clips.

Stößt man mit seinem Browser auf eine Seite, die Daten für ein spezielles Plug-In enthält, das man noch nicht integriert hat, so bleibt das spezielle Feature unbenutzbar und es erscheint in vielen Fällen, jedoch nicht immer, ein entsprechender Hinweis. Anbieter solcher Seiten sollten stets auch einen direkten Link auf die Download-Pages anbieten, von denen das be-nötigte Plug-In dann geholt werden kann.
Netscape stellt im Internet spezielle Seiten zur Verfügung, von denen aus direkt auf einen Großteil der verfügbaren Plug-Ins zugegriffen werden kann. Da das

Angebot ständig zunimmt, lohnt es sich, diese Seite häufiger zu besuchen:
http://www.netscape.com/comprod/mirror/navcomponents_downlod.html

Auch Microsoft bietet eine solche Seite an. Die Seite findet man unter:
www.microsoft.com/ie/download/ieadd.htm

Tabelle 6.2 Plug-Ins für den Netscape Navigator

Tabelle 6.3 Plug-Ins für den Microsoft Internet Explorer

Tabelle 6.4 Auswahl einiger Web-Server-Hersteller

Insgesamt gibt es ein Angebot von über 50 Server-Produkten für nahezu alle Betriebssysteme von Amiga über AS/400, DOS, Mac, Netware, Linux, MVS, VM, VMS, Windows 3.x, Windows 95, Windows NT, OS/2 bis hin zu Unix. Einige Server sind kostenfrei, andere kosten mehrere zehntausend D-Mark. Die Ursache für die Preisspanne liegt allerdings nicht nur in techni-schen Unterschieden begründet. Gleichwohl unterscheiden sich die Server

• in ihrer Funktionalität (hochperformant – weniger performant),
• in der Art und Weise wie sie zu verwalten sind (mit oder ohne grafische Benutzerschnittstelle)
• welche Management-Tools es gibt (Performance-Überwachung),
• welche Log-Dateien produziert werden können (Common Log Format oder proprietär),
• welche Sicherheitsprotokolle und welcher Zugriffsschutz implementiert ist (SSL, SHTTP, Password, URL-, IP-, DNS-basiert),
• welche zusätzlichen Server integriert sind (Gopher, Mail, News, FTP usw.),
• ob Datenbank-Schnittstellen vorhanden sind und letztlich auch darin,
• ob es (meist) proprietäre Erweiterungen (z. B. Work-flow Anwendungen) gibt.

Die meisten Server-Hersteller bieten von ihren Servern Demo-Versionen an.

XML ist eine herstellerunabhängige, erweiterbare und benutzerdefinierbare Beschreibungssprache, die im Dezember 1997 verabschiedet wurde. XML bedeutet eine Erweiterung der Möglichkeiten von HTML. Während HTML hauptsächlich aus Text besteht und aus Informationen darüber, wie der Text und die entsprechende Seite formatiert sein sollen, ist XML eine Sprache, die Daten und Datenstrukturen beschreibt. Anwendungen wie z. B. elektronische Produktkataloge benutzen heute noch vielfach HTML zur Präsentation von Daten, die aus einer Datenbankschnittstelle ausgele-sen werden.
Das Ergebnis einer Datenbankabfrage wird hierbei als HTML-Seite aufge-arbeitet und verliert so die Zuordnung zwischen Variablennamen und den zugehörigen Datenfeldern. Eine semantische Bearbeitung der Daten ist somit nicht mehr möglich.

XML erweitert HTML insofern, dass nun Informationen über die Syntax und Semantik der Daten verschickt werden können. Mit Dokumenten, die statt in HTML in XML verfasst oder aus Datenbeständen generiert sind, lässt sich daher viel mehr machen, denn in den Elementnamen und selbst-definierten Attributen beziehungsweise deren Werten sind die Informatio-nen über die eigentlichen Daten enthalten. Auf diese sogenannten Metada-ten kann man ebenfalls zugreifen [vgl. Behme, 11ff].

Darüber hinaus wurde mittlerweile eine wesentliche Schwachstelle von HTML erkannt: Es ist zwar sehr gut zur Formatierung von Dokumenten geeignet, eine Strukturierung der einzelnen Elemente ist allerdings kaum möglich. Zwar können mittels des Elements <h> verschiedene Hierarchie-ebenen definiert werden, doch beschränkt sich diese Hierarchisierung auf Überschriften. Komplexere Strukturen, wie sie in Abbildungsverzeichnis-sen, Adressfeldern oder Index-Verzeichnissen bestehen, lassen sich nicht definieren.
In HTML gibt es Elemente wie <H1> oder <BLOCKQUOTE>. In XML dagegen kann sich jeder beliebig viele eigene Elemente definieren: von REZEPT bis hin zu STRAßE, etwa in einem privaten Koch- oder Adress-buch.
So enthielte eine Beschreibung der Struktur für ein Adressbuch wahrscheinlich außer einem Element wie ADRESSBUCH (welches das gesamte Dokument einschließt) weitere Elemente wie VORWAHL, TELNR. Und PLZ, die innerhalb einer ADRESSE hierarchisch geschachtelt sein müssen.

Der Inhalt und die Struktur zukünftiger Dokumente werden folglich mittels XML definiert, während das Darstellungsverhalten solcher Dokumente im Web-Browser mit Hilfe von XSL (eXtensible Style Language) beschrieben wird. Für die Verknüpfung verteilter Dokumente untereinander kommen die Standards XPointer und XLink zum Einsatz.

Ein beträchtlicher Anteil der künftig im Web abzurufenden Katalogdaten (sofern sie in XML vorliegen) wird aus Datenbanken generiert sein. Das hat verschiedene Gründe. Zum einen ist die sequentielle Generierung gro-ßer Datenbestände aus einer Datenbank am sinnvollsten (z. B. Konsistenz); zum anderen gilt: Kann man aus einem Datensatz korrektes XML generie-ren, dann funktioniert das auch mit Hunderttausenden von Datensätzen.

Wichtig ist auch, dass die resultierenden Dokumente nicht unbedingt XML-Instanzen sein müssen. Es kann sich z. B. um in HTML gewandelte Ausschnitte handeln. Einfachstes Beispiel ist das Inhaltsverzeichnis eines Buches, das im Quelltext so gar nicht bestand, sondern automatisch erstellt wurde und auch als eigenständiges Dokument gespeichert werden kann. Aus einem einzigen XML-Dokument können im Prinzip fast beliebig viele Web- (HTML-) Dokumente entstehen, wie etwa eine konkrete Adresse aus einem Adressbuch heraus. Und natürlich ist es möglich, aus XML-Quellen HTML-Dateien zu erzeugen, die jeder Browser anzeigen kann. Dabei ge-hen zwar Informationen verloren, aber immerhin bewirkt eine solche Kon-vertierung generelle Verfügbarkeit für den Einkäufer.

Mobile Geräte unterscheiden sich erheblich von den Geräten, mit denen man bisher Internet-Dienste in Anspruch genommen hat. Verglichen mit einem Desktop Computer und selbst mit einem Laptop unterscheiden sich mobile Geräte wesentlich in folgenden Punkten:

• kleinere Displays
• schwierigere Eingabemöglichkeiten
• leistungsschwächere CPUs
• geringere Speicherkapazität
• eingeschränkte Stromversorgung.

Durch diese Begrenzungen müssen sich Benutzerschnittstellen von mobi-len Internet-Anwendungen und von traditionellen Internet-Anwendungen fundamental unterscheiden. Vor allem das kleine Display und die fehlende Maus erfordern eine unterschiedliche Darstellung und eine veränderte Me-nüführung.

Diese Einschränkungen werden sich in absehbarer Zeit nicht wesentlich ändern. Natürlich werden stetige Verbesserungen an den Geräten vorge-nommen, doch der Gegensatz zwischen den Zielen bleibt erhalten. Zum einen sollen mobile Geräte möglichst klein, leicht und benutzerfreundlich sein, auf der anderen Seite soll durch ein größeres Display sowie durch mehr Speicherkapazität und bessere Eingabemöglichkeiten der Bedie-nungskomfort gesteigert werden.

Die Mobilfunknetze unterscheiden sich erheblich von den herkömmlichen Netzwerken. Sie sind gekennzeichnet durch:

• geringere Bandbreite
• längere Übertragungszeiten
• geringere Verbindungsstabilität
• geringere Verlässlichkeit.

Bestehende Internet-Anwendungen können deshalb nur in den seltensten Fällen 1:1 auf WAP-Applikationen abgebildet werden.

Bezüglich der Netzwerkqualität wird es mittelfristig große Verbesserungen durch schnellere und verlässlichere Netzwerke geben. Jedoch wird die eingeschränkte Stromversorgung der mobilen Geräte diese Verbesserungen wieder relativieren. D. h., selbst bei theoretisch sehr hohen Bandbreiten der Netzwerke, werden diese durch die begrenzte Energieversorgung der Endgeräte in der Praxis nicht vollständig genutzt werden können.

Abbildung 6.4 Das WAP-Programming-Model

Zunächst baut der Client mit dem Wireless Application Protokoll (genauer: WSP und WTP, siehe unten) eine Sitzung zu einem WAP-Gateway auf. Dieses übersetzt die Anfragen vom WAP-Protokoll-Stack in den WWW-Protokoll-Stack (also in HTTP und TCP/IP) und schickt diese Anfrage an den bestimmten Web-Server weiter. Der Web-Server behandelt den Aufruf wie jeden anderen HTTP-Aufruf. D. h., es werden dynamische Seiten er-stellt oder einfache statische Seiten zurückgegeben. Der einzige Unter-schied liegt darin, dass keine HTML-Seiten, sondern Seiten im Wireless Markup Language-Format zurückgegeben werden. Viele WAP-Gateways verfügen über einen HTML/WML-Konverter, d. h., es wäre in einigen Fällen möglich, HTML-Seiten zu liefern. Von dieser Möglichkeit muss allerdings abgeraten werden, da die Ergebnisse der Konvertierung meist nicht brauchbar sind. Das WAP-Gateway verschlüsselt die Web-Inhalte in kompakten Binärcode. Dadurch reduziert sich die Größe und die Anzahl von Paketen, die im Mobilfunknetz hin und her gesendet werden. Die ver-schlüsselten Web-Inhalte werden schließlich über WAP (WSP/WTP) zu-rück zum WAP-Client geschickt.
Es wird also die bekannte Internet-Proxy-Technologie verwendet. Durch die Verwendung der Resourcen der WAP-Gateways können die mobilen Geräte sehr einfach und kostengünstig sein.

Durch diese Architektur ist sichergestellt, dass Benutzer von mobilen Ter-minals WAP-Inhalte und Applikationen unabhängig vom benutzten Netz-werk anschauen können. Entwickler können Applikationen schreiben, die unabhängig von Geräten und Netzwerken sind und die so das größtmögli-che Publikum erreichen. Inhalte und Anwendungen befinden sich auf her-kömmlichen Web-Servern, wodurch Web-Technologien wie CGI, Java Servlets, Java Server Pages (JSP) oder Active Server Pages (ASP) verwen-det werden können. Über das WAP-Gateway kann unter Umständen auf Benutzerdatenbanken und auf Informationen aus dem Mobilfunknetz (z. B. Standort des Benutzers) zugegriffen werden.
Es gibt vier verschiedene Möglichkeiten, wie die einzelnen Komponenten nach Standort und Aufgaben verteilt werden können.

Abbildung 6.5 Einsatzszenarien

Wenn sich sowohl der Dial-in-Server, als auch der WAP-Server (WAP-Gateway) und der Origin-Server (Web-Server) innerhalb eines Unternehmens befinden, spricht man von einer „Total Corporate Solution“. Die Sicherheit und die Unabhängigkeit sind in diesem Falle am höchsten bzw. größten. Eine solche Lösung ist jedoch allenfalls für sehr große Unternehmen interessant, da der Dial-in-Server in der Regel immer beim Netzwerkbetreiber steht.

Wenn dies der Fall ist, alle anderen Komponenten jedoch innerhalb des Unternehmens angesiedelt sind, bezeichnet man dies als „Corporate Solu-tion“. Eine solche Verteilung empfiehlt sich vor allem bei Anwendungen (z. B. Banking-Anwendungen), bei denen hohe Sicherheit vonnöten ist und dafür das WAP-Gateway durch die firmeneigene Firewall abgeschirmt sein muss. Auch für Intranet-Lösungen wie Firmen-E-Mail o. ä., bietet sich diese Lösung an. Wird der WAP-Server eines Netzwerkbetreibers und der eigene Origin-Server verwendet, spricht man von einem „Content Provi-der“. Dies ist die heute am häufigsten verwendete Verteilung. Als letzte Möglichkeit kann zusätzlich noch der Origin-Server oder Web-Server ei-nes Netzwerkbetreibers oder eines Internet-Service-Providers verwendet werden. Hier begibt man sich einerseits in sehr starke Abhängigkeit der Provider, andererseits muss man nicht über Hardware oder bestimmtes Know-how verfügen.

Abbildung 6.6 Der WAP-Protokoll-Stack

Der WAP-Protokoll-Stack minimiert die Anforderungen an die Bandbrei-ten, wodurch garantiert wird, dass WAP-Anwendungen in einer Vielzahl von verschiedenen Mobilfunknetzen erreicht werden können. Die einzel-nen Schichten werden im Folgenden kurz vorgestellt.

Die Sicherheitsschicht wird von der Wireless Transport Layer Security (WTLS) gebildet. Sie ist für die Bereitstellung von sicheren Verbindungen und den dazu notwendigen Sicherheitstechniken zuständig. Dazu gehören unter anderem Authentifizierung, Privacy und Datenintegrität. Zusätzlich gibt es noch speziell für die Belange der mobilen Kommunikation ange-passte Sicherheitstechniken. Die WTLS ist optional und arbeitet über der Transportschicht.

Der im WAP definierte Protokoll-Stack optimiert das Standard-Web-Protokoll (HTTP) für die besonderen Anforderungen in Mobilfunknetzen, die durch geringe Bandbreite, hohe Wartezeiten und ähnliche Einschrän-kungen gekennzeichnet sind. Es wurden Verbesserungen in den Session, Transaction, Security und Transport Layers vorgenommen.
Der Vergleich der Kombination HTTP, TCP und IP gegenüber WSP, WTP und UDP lässt den drastisch geringeren Overhead des WAP erkennen:

Abbildung 6.7 Unterschiedlicher Bandbreitenverbrauch der Protokolle

Auch das nachfolgende Schaubild macht den Performance-Gewinn des WAP im Gegensatz zu HTTP/HTML deutlich. So ist der Sprachumfang des WAP-Standards deutlich kompakter als HTML. Dazu kommt, dass die WAP-Inhalte immer in komprimierter Form übertragen werden, was bei HTTP nicht der Fall ist. Dies wird als sogenanntes „big pipe – small pipe“ Syndrom bezeichnet.

Abbildung 6.8 Das „big pipe – small pipe“ Syndrom

Nach Einschätzung von Motorola wird im Jahr 2005 eine Milliarde Men-schen das Internet regelmäßig nutzen, wobei der Zugang zu 50 Prozent über Mobilfunkgeräte erfolgen wird. Über drei Evolutionsschritte wird das Mobiltelefon zu einem Informations , Transaktions-, Zahlungs-, Si-cherheits- und Unterhaltungs-Tool: WAP, GPRS (General Packet Radio Service) und UMTS (Universal Mobile Telecommunication System) sind die drei Schritte.

Abbildung 6.9 Zukunft des Handy-Banking (Bild: Postbank)

EDI bezeichnet den elektronischen Austausch von Daten zwischen zwei Anwendungssystemen in einer standardisierten und automatisierten Form (sogenannte interventionslose Transaktionen). Ziel von EDI ist es, die Kos-ten und den Zeitbedarf für die Dokumentenverarbeitung zu senken.
EDI hat sich – trotz des unbestrittenen Einsparpotenzials - bis heute nur zögerlich durchgesetzt, was auf eine Vielzahl von Faktoren zurückzufüh-ren ist:

• Zahlreiche Standards: Es existieren verschiedene proprietäre Stan-dards. Während in Deutschland EDIFACT ca. 40% Marktanteil hat, verfügt ANSI X12 in den USA über einen Anteil von knapp 50%. Geschäftspartner müssen sich immer zuerst auf einen Stan-dard einigen oder gar mehrere Standards einführen, um den An-sprüchen des Gegenübers gerecht zu werden.

• Hohe Implementierungskosten: Es müssen spezielle Netzwerke zwischen den kommunizierenden Partnern aufgebaut werden, ent-weder private Punkt-zu-Punkt-Netzwerke oder sogenannte Value Added Networks (VANs). Neben den hohen Hardware- und Da-tenfernübertragungskosten fallen zudem Kosten für die Installation der Software an.

• Beschränkte Möglichkeiten: Per EDI lassen sich nur beschränkte Mengen von Daten und diese nur in bestimmten Formaten über-tragen. Die Übermittlung von technischen Zeichnungen, Grafiken oder dynamischen Daten wird nicht unterstützt.

• EDI unterstützt nicht den Sinn des B2B, nämlich sich mit mehre-ren Unternehmen auszutauschen, z. B. über einen Marktplatz oder einen Broker. Per EDI können sich über eine feste Verbindung immer nur zwei Unternehmen austauschen.

Viele Unternehmen stellen zunehmend ihre EDI-gestützten Prozesse auf Internet um. Das wird den Vorteil mit sich bringen, dass nur noch ein Stan-dard auf dem Markt existieren wird. Zudem wird es für kleine und mittlere Unternehmen einfacher werden, Geschäftsbeziehungen mit mächtigeren Abnehmern einzugehen. Oft wurden diese kleinen und mittleren Unter-nehmen von diesen fallengelassen, wenn sie nicht bereit waren, EDI einzu-führen; durch kostengünstige Internet-Lösungen können sie nun problem-los solche Geschäftsbeziehungen aufrecht erhalten bzw. neu eingehen.

Bis ins Jahr 2003 werden internet-gestützte Prozesse laut Boston Consul-ting Group einen Anteil von 72% und EDI-gestützte Prozesse nur noch einen Anteil von 28% der Unternehmen einnehmen (siehe Abbildung 6.12 Castanet der Transmitter sendet, der Repeater verteilt und der Tuner emp-fängt). Die Firma 3Com rechnet damit, dass bis ins Jahr 2005 85-100% ihres EDI über Internet laufen wird.

Abbildung 6.11 Beschaffung über Internet vs. EDI 2003

Da EDI von vielen Unternehmen nie richtig akzeptiert wurde und proprie-täre Systeme allgemein mit höheren Kosten und zahlreichen Einschrän-kungen verbunden sind, zeigt sich nun mehr und mehr, dass das Internet durchaus über die Möglichkeiten verfügt, Beschaffungsprozesse auf eine effiziente Weise zu unterstützen und zu optimieren.
Gerade bei C-Gütern, die dezentral durch den einzelnen Bedarfsträger beschafft werden, werden gravierende Nachteile von EDI-Systemen deutlich:

Neben der Auswahl von Lieferanten muss der Benutzer die C-Güter aus einem Katalog auswählen. Verfügbarkeitsnachfragen und Berechtigungs-konzepte müssen realisiert sein. Mit EDI-Systemen allein lassen sich diese Prozesse wegen der hohen technischen Komplexität und der dadurch ent-stehenden geringen Benutzerfreundlichkeit nicht dezentral durchführen.
Aufgrund der bisher fehlenden multimedialen Unterstützung und der Ein-schränkungen der EDI-Systeme wird die automatisierte Beschaffung von C-Gütern erst auf Internet-Basis realisierbar.

Tabelle 6.6 RealAudio-Sites im WWW (live)

Ebenfalls live im Intenet ist das Radioprogramm der Deutschen Welle zu hören (http://www.dw-world.de). Der Sender informiert über das Weltge-schehen und versteht sich auch als Botschafter Deutschlands im Ausland. Das achtstündige Kernprogramm wird dreimal am Tag ausgestrahlt, wobei überwiegend Informationen aus Wirtschaft und Politik gesendet werden, daneben aber auch Sport und Musik. Das Programm wird von einem ame-rikanischen RealAudio-Server ins Internet transportiert. Die Programm-übersicht befindet sich auf der Web-Site http://www.dw-world.de.

Tabelle 6.8 Video- und Audio-Player (Plug-Ins ) für die Steaming-Live-Technik

Abbildung 6.12 Castanet der Transmitter sendet, der Repeater verteilt und der Tuner empfängt

Technisch gesehen besteht ein Push-Channel aus miteinander verwobenen Web-Seiten und Java-Applikationen, die sich der Aktualität wegen in mehr oder weniger regelmäßigen Abständen ändern. Die Betreiber der Push-Channels frischen im Rhythmus der Änderungen ihre Datenbestände auf und spielen dann den Abonnenten nur die Neuigkeiten zu. Der Rhythmus der Änderung spielt nur eine untergeordnete Rolle. Ein Push-Channel mit vergleichsweise hoher Änderungsfrequenz könnte beispielsweise einem Filmbetrachter die Bilder zustellen. Ein Kanal zum Zustellen von Börsen-kursen hätte eine im Vergleich dazu langsame Änderungsfrequenz. Eine noch geringere Änderungsfrequenz würde den Push-Channel kennzeich-nen, der abonnierte Software-Updates distributiert.

Heute fließen in erster Linie Nachrichten und News über die Push-Channels. So wundert es nicht, dass zu den Anbietern von Inhalten Fern-sehsender wie ABC und CNN sowie Zeitungen, etwa die New York Times, die Chicago Tribune und USA Today gehören. In Deutschland wollen Springer und Bertelsmann einen gemeinsamen Sportkanal betreiben.

Technologieanbieter für Push-Channels gibt es heute mehrere. Gemein-samkeiten bestehen darin, dass sich die meisten Anbieter auf das HTTP-Protokoll konzentrieren und der Channel-Inhalt im Hintergrund auf die lokale Festplatte geladen wird. Clients funktionieren wie Off-Line-Reader. Dass die einzelnen Produktbestandteile der Programm-Suites verschiede-ner Hersteller nicht kompatibel miteinander sind, ist in dieser frühen Phase der Technologieentwicklung fast selbstverständlich.

Tabelle 6.9 Push-Technologien für das Internet

Oben haben wir schon erwähnt, dass Push Channels neben Informationen prinzipiell auch digitale Güter distributieren können. Um die optimale Verteilung des digitalen Guts Software kümmert sich vorrangig Castanet von Marimba Software in Palo Alto. Ziel dabei ist die internetbasierte Software-Pflege. Bislang verhinderten lange Übertragungszeiten beim Download, Java-Programme auch für komplexere Aufgaben über das Netz zu ziehen. Castanet bietet hier einen Ausweg: Das sogenannte Application Distribution Protocol, kurz ADP, sorgt dafür, dass der komplette Code nur einmal, und zwar unmittelbar nach dem Abonnieren des Channels, über das Netz auf die lokale Festplatte gezogen wird. Danach erfolgen nur noch differenzielle Updates. Software-Freischaltung, Lizenzvergabe und auch Software-Leasing lässt sich mit Castanet realisieren. Diese Beispiele ver-deutlichen, dass in der Push-Technologie entsprechende Potenziale für elektronische Märkte ruhen.

Die Programm-Suite von Castanet umfasst im Wesentlichen drei Kompo-nenten (siehe Abbildung 6.12 Castanet der Transmitter sendet, der Repea-ter verteilt und der Tuner empfängt) Bedient wird der Push-Channel vom sogenannten Transmitter, der als Server arbeitet. Der Client wird Tuner genannt und verwaltet die Channel-Abonnements. Als Java-Applikation läuft der Tuner auf allen Plattformen, die Java unterstützen. Mit dem oben erwähnten ADP-Protokoll für die Abwicklung von Software-Updates, wird auch der Castanet-Tuner gepflegt. Für die Entwicklung von Channels bie-tet Castanet das Tool Bongo.