Electronic Mall: Banking und Shopping in globalen Netzen

5 Realisierungsvarianten

Nachfolgend werden verschiedene Realisierungsvarianten von Client-Server-Applikationen beschrieben. Die Variante 1 beschreibt eine Realisierung, in welcher der Server die Hauptarbeitslast trägt, wogegen der Client sich lediglich mit der Visualisierung beschäftigt. Bei Variante 2 und Variante 3 werden Realisierungen vorgestellt, in welchen die Clients und die Servers viel schwächer miteinander gekoppelt sind. Der Grad der Koppelung zwischen Client und Server nimmt deshalb von den Varianten 1 bis 3 ab: Zuerst auf der Ebene des funktionalen Gerüstes und danach auf der Ebene der Benutzerinteraktion.

5.1 Variante 1: Anbieterbasierte Applikationen

Als anbieterbasierte Applikationen werden solche bezeichnet, die auf Systemen entwickelt wurden, welche eine Host-Terminal Architektur aufweisen. Diese Applikationsarchitektur ist in der Praxis immer noch vorherrschend. Anbieterbasierend wird sie deshalb genannt, weil die wesentliche Informationsverarbeitung beim Anbieter geschieht.

Bezeichnend für die Host-Terminal Architektur ist, dass die ganzen applikationscharakteristischen Softwarekomponenten, die sog. Intelligenz, auf einem Host liegen. Das Terminal ist lediglich ein Ein-/Ausgabegerät für den Benutzer, d.h. es dient nur der Datenerfassung und Entgegennahme. Bei den klassischen Terminals wird auf der Ebene der Applikation keine Vorverarbeitung der vom Benutzer generierten Daten geleistet. Das Terminal bietet lediglich Unterstützung auf der Ebene der Datenflusskontrolle (OSI-Schicht 2) und unterstützt gegebenenfalls gewisse abstrakte Eingabe-Elemente wie Masken etc. Typische Repräsentanten dieser Klasse von Diensten sind die Videotex-Applikationen oder Host-Systeme von IBM mit den 3270 Terminals oder der wohl am weitesten verbreitete Terminal-Standard von DEC, das VT100 und die entsprechenden Derivate (VT200, VT320, etc.). Nachfolgend werden zwei Unterklassen von anbieterbasierten Applikationen unterschieden. Die hostbasierte Steuerung, bei welcher der Benutzer alles vom System vorgelegt bekommt und die clientbasierte Steuerung, bei welcher der Benutzer etwas mehr Freiraum erhält.

5.1.1 Hostbasierte Steuerung

Die hostbasierte Steuerung stellt die Erfassung der für die Applikation benötigten Daten in den Vordergrund. Dem Benutzer wird von der Applikation eine Maske geliefert, die er ausfüllt und nach Beendigung des Ausfüllvorganges dem Host zuschickt. Solche Systeme weisen, aufgrund der technischen Gegebenheiten, eine recht starre Benutzerführung auf, d.h. der Freiraum an Arbeitsablaufgestaltung ist äusserst bescheiden. Der Vergleich mit dem Barcode-Leser ist hier angebracht. Dieser dient auch zur Erfassung der für die Applikation relevanten Daten, die bereits in einem Barcode vorliegen. Somit wird die Datenerfassung rationalisiert und die Fehlerhäufigkeit bei der Dateneingabe, wie zum Beispiel Tippfehler, minimiert.

Aus dieser Optik resultieren diese negativen Vorbehalte gegenüber solchen Systemen in einem interaktiven telematischen System, insbesondere im Zahlungsverkehr. Es wird vom "Kunden als billigste Bankangestellte" gesprochen, da ja der Kunde diejenige Arbeit leistet, die vorher Bankmitarbeiter erledigten, nämlich die EDV-mässige Erfassung der Zahlungsaufträge, ohne den für ihn zusätzlichen Mehrwert zu erkennen.

Je nach Mächtigkeit des Terminals können dem Benutzer gewisse ergonomische Erleichterungen angeboten werden. Beispielsweise geschieht die Cursorsteuerung innerhalb einer Bildschirm-Maske bei den 3270 Terminals durch lokale Intelligenz im Terminal. Andere Terminals bieten zum Teil grafische Unterstützung an, um die Ergonomie zu erhöhen, so zum Beispiel die Terminals basierend auf dem CEPT-Standard (vgl. Videotex, Kap. VII, Abs. 2).

Unter dem Aspekt des Mehrwertes stellt die strenge hierarchische Beziehung Host-Terminal eine hohes Risiko dar: Da die Daten nur auf dem Host zur Verfügung stehen und der durch das Terminal an den Benutzer gelieferte Output viel Information enthält, welche für die Informationsdarstellung wichtig ist (Farbe, Layout, etc.), ist sie ungeeignet für eine weitere elektronische Verarbeitung durch den Kunden. In diesem Sinne wird das "love-it-or-leave-it" Dilemma beim Kunden verschärft: Schon kleine Produktemängel können ihn dazu bewegen, das Produkt des Anbieters als Ganzes zu verwerfen.

Neben den geschilderten ergonomischen und marketingspezifischen Nachteilen, gibt es, vor allem auf technologischer Seite, auch Vorteile bei solchen Systemen. Ein ganz zentraler Punkt betrifft die Wartung der Software. Da die Applikation vollständig auf dem Host läuft, kann sie auf beliebige Weise geändert oder um Funktionalität ergänzt werden. Diese Modifikationen können zu beliebigen Zeitpunkten durchgeführt werden, ohne dass man sich um die Endgeräte (Terminals) kümmern muss. Die dadurch erreichte engere Bindung des Kunden an den Anbieter ist, aus der Perspektive des Anbieters betrachtet, ein weiterer, grosser Vorteil.

Auf der anderen Seite kann der Anbieter nicht gezielt auf individuelle Kundenbedürfnisse eingehen, da alle Kunden auf exakt dasselbe Programm zugreifen.

Ein weiterer Vorteil dieser Architektur liegt bei der Einführung von Angeboten in einer Electronic Mall. Mit relativ geringem Aufwand kann der Anbieter Kunden erreichen, indem er sich bei einem Mittlerdienst anschliesst und sich über den Gateway-Dienst vermitteln lässt. Dies ist besonders einfach zu realisieren bei Hostsystemen, welche die Konzeption von Remote-Terminals anbieten, wie das bei UNIX-basierten oder verwandten Systemen der Fall ist. Der Kunde braucht dazu lediglich eine Terminal-Emulation, die kostengünstig oder sogar via Public-Domain angeboten wird. Die organisatorischen Anpassungen seitens der IT-Verantwortlichen betrifft vor allem das Sicherheitsmanagement und die Führung von zusätzlichen Benutzerkonti, die nicht Angestellte, sondern Kunden der Firma sind. Wie in Kap. II dargestellt, nutzen vor allem in den USA diverse Anbieter diese Möglichkeit über den Mittlerdienst CompuServe.

5.1.2 Clientbasierte Steuerung

Im Unterschied zur hostbasierten Steuerung lässt die clientbasierte Steuerung wesentlich mehr Freiheitsgrade zu. Konzeptuell gesehen liegt die Intelligenz der Applikation beim Anbieter. Der Kunde besitzt dadurch erheblich mehr Einflussnahme auf den Arbeitsablauf bei der Datenerfassung und auf die Visualisierung.

Durch die Leistungsfähigkeit der PCs im Bereich Rechnerleistung und Grafikfähigkeit erlauben die Applikationen (siehe Abschnitt 3) die Benutzersteuerung durch ein GUI - Grafikprotokoll, wie z.B. X-Windows, Display-Postscript oder RIPTerm aus dem Mailbox-Bereich. Diese sind in der Lage, solche GUI-spezifischen Informationen zwischen Kunden- und Anbieter-Rechner zu vermitteln.

Der Vorteil einer solchen clientbasierten Steuerung liegt vor allem in der Verbesserung der Benutzerergonomie. Des weiteren können sich auch die Anbieter viel besser durch eine gute, grafische Visualisierung ihres Angebotes präsentieren.

Als Nachteil ist die wesentlich höhere Menge an Daten zu nennen, die zwischen Kunden- und Anbieter-Rechner transferiert werden muss. Die existierenden, grafischen Protokolle wurden in bezug auf diesen Aspekt erheblich verbessert. Trotzdem sind die heute existierenden Protokolle unter 14'400 bps kaum zu betreiben, mit der Ausnahme von RIPTerm, welches sich auch ab 2'400 bps zufriedenstellend betreiben lässt.

Das Konzept von Client-Server kann natürlich wesentlich erweitert werden. Die Daten, welche zwischen Client und Server transferiert werden, können ohne Darstellungsinformation übertragen werden. Die Darstellung ist dann Sache der Software beim Kunden, resp. der Client-Komponente der Applikation. Weitere Vorteile wurden bereits in Abschnitt 2.3.3 erwähnt. Hierbei ist besonders darauf zu achten, dass die Anbieter eine standardisierte Schnittstelle zur Verfügung stellen, damit Drittanbieter oder den Kunden selbst die Clientkomponente entwickeln können.

5.2 Variante 2: Mittlerbasierte Applikationen

Unter mittlerbasierten Applikationen werden solche verstanden, bei welchen das Erscheinungsbild der Applikation vom Mittler geprägt ist. Beispiele sind Prodigy, der schweizerische Videotex-Dienst sowie die meisten Angebote von Bildschirmtext und CompuServe.

Der Vorteil von solchen Systemen besteht darin, dass der Mittler wesentlich zur Verbreitung eines solchen Systems beiträgt. Insbesondere dann, wenn es sich um einen (privaten) kommerziellen Mittler handelt. Er übernimmt das Marketing und bestimmt einen geeigneten Marketing-Mix an Angeboten. Die Integration und Interoperabilität der Applikationen ist auch Sache des Mittlers. Wie bei einem Einkaufszentrum stellt der Mittler die Infrastruktur sowohl für die Anbieter als auch für die Kunden bereit (Wasser, Strom, Parkplätze, etc.). Er verkauft den verschiedenen Anbietern Ladenfläche und stellt diese in einer für den Kunden sinnvollen Kombination zusammen (Banken, Post, Cafeteria, etc.).

In diesem Sinne sind die Mittler für eine harmonische Integration der Anbieter verantwortlich. Dies wird durch ein vom Mittler zur Verfügung gestelltes GUI übernommen, welches für die Präsentation der Anbieter verwendet wird. Ein Ziel dieses GUI sollte es sein, dass der Benutzer für alle über den Mittler zu beziehenden Dienste das gleiche "Look and Feel" haben soll. Dies steht aber im Gegensatz zu den Zielen der Anbieter, die in einer Vereinheitlichung eine potentielle Gefahr der Kundenentfremdung sehen, indem ein Mittler das jeweilige Layout diktiert. Beispiele eines enorm vom Mittler vorgegebenen Layouts sind Prodigy oder CompuServe mit den Diensten, welche über die WinCim Schnittstelle angeboten werden. Eine grundsätzlich andere Politik betreibt das schweizerische Videotex oder Btx in Deutschland. Dort bietet der Mittler lediglich eine Kommunikationssprache für die Übertragung darstellungsspezifischer Information. Die effektive Präsentation der Dienstleistung ist Sache des Anbieters. Dies weist den Nachteil auf, dass die Anbieter recht unterschiedliche Darstellungen für den gleichen Sachverhalt haben. Diese Unkonformitäten in der Benutzerführung haben, insbesondere im schweizerischen Videotex-Telebanking, zu einer erheblichen Unzufriedenheit der Kunden beigetragen (siehe Kap. VII).

Bei der technologischen Realisation von mittlerbasierten Applikationen gibt der Mittler Standards vor, wie die Anbieter ihre Produkte bei ihm anzuliefern haben. Hier ist es von äusserster Wichtigkeit, dass der Mittler standardisierte Protokolle verwendet, damit der Anbieter die Daten nicht in einem speziellen Format anliefern muss. Eine alternative Strategie würde bedeuten, dass der Mittler mehrere Schnittstellenformate auf verschiedenen Abstraktionsstufen anbietet, um somit eine möglichst grosse Anzahl von Anbietern ansprechen zu können. Beispielsweise kann er Clearing-Center Funktionalitäten (siehe Kap. II oder Kap. IV) zur Verfügung stellen.

Gegenüber dem Nachfrager gelten die gleichen Überlegungen, wie sie bereits unter Abs. 5.1 erwähnt wurden. Auch hier sollte der Mittler möglichst eine Client-Server Lösung anstreben, damit der Prozess der Mehrwerterzeugung (siehe Kap. III) in der Informationsaufbereitung offen bleibt. Sobald zwischen zwei Teilnehmern in einem telematischen System die transferierten Daten nicht mehr maschinell weiterverarbeitet werden können, wird das Potential, aus den Daten noch weiteren Mehrwert zu erzeugen, erheblich eingeschränkt. Dies ist der Fall, falls die Daten mit Darstellungsinformation angereichert sind. Im Extremfall wäre dies ein Bitmap im Gegensatz zu einer Vektorgrafik.

Mittler müssen auch Schnittstellen zu weiteren Mittlerdiensten aufbauen können. Dies ist besonders interessant für kleine Mittler, die dann ihr Angebot gegenüber den Kunden um ein vielfaches erweitern können. Hier muss jedoch darauf geachtet werden, wie sich die Übergänge zwischen den verschiedenen Mittlerdiensten dem Kunden gegenüber präsentieren. Da der Mittler jeweils Einfluss auf das GUI nimmt, wird der Kunde beim Wechsel des Mittlers einen Stilbruch feststellen. Die Netzdienste garantieren keine transparenten Übergänge in bezug auf das GUI. Beispielsweise ist es technologisch gesehen mit sehr viel Aufwand verbunden, einen für den Benutzer transparenten Übergang zwischen den heute existierenden Mittlerdiensten wie Prodigy zu CompuServe oder Prodigy zu Videotex zu schaffen, im Gegensatz zu Mittlerdiensten auf dem Internet, wie dem WWW oder Gopher (siehe Kap. III).

5.3 Variante 3: Kundenbasierte Applikationen

Diese Variante nennt sich kundenbasiert, da die Integration und Interoperabilität der Applikationen, resp. Anbieter, beim Kunden vorgenommen werden. Dieser Schritt gibt dem Kunden mehr Gestaltungsfreiraum in der Informationsdarstellung und erlaubt ihm mehr Freiheit in der Wahl des Mittlers.

Der Mittler übernimmt in dieser Variante Clearingfunktionen und Vermittlerdienste zwischen den Anbietern und den Kunden, kümmert sich jedoch nicht mehr direkt um den Angebotsmix.

Technisch wird dies ermöglicht, indem die Clientkomponenten der Applikationen die Interoperabilitätseigenschaften des Betriebssystemes und des GUIs beim Kunden ausnutzen. In Microsoft-Windows wird dies ermöglicht, indem die Applikationen sich an die von Microsoft vorgeschlagenen CUA-Vorgaben halten und Dienste wie Clipboard, OLE und DDE, sowie Schnittstellen zum Program-Manager ausnutzen. Dadurch wird die Integration für Drittanbieter erleichtert und der Kunde kann mit Hilfe seiner Office-Applikationen (Word, Excel, etc.) sogar selber einen Mehrwert aus den vom Anbieter gelieferten Daten erzielen.

Voraussetzung dafür ist, dass die Anbieter ihre Produkte in standardisierten Formaten anbieten und dass die Mittler kundenseitig ebenfalls standardisierte Schnittstellen anbieten. Die Anbieter müssen sich daher stärker auf den InformationsInhalt (Qualität) der Kerndienste spezialisieren, damit der Kunde motiviert wird, auf diese Informationen und Dienstleistungen zuzugreifen. Durch die Standardisierung bei den Anbietern und Mittlern wird das Angebot wesentlich erhöht: Anbieter können über diverse Mittler erreichbar sein, und Kunden können zwischen unterschiedlichen Mittlern wählen. Der Kunde kann sich selber sein Angebot zusammenstellen und durch die Client-Server Architektur, sowie durch die Trennung von Darstellungsinformation und Inhalt bei der Datenübermittlung, mit geringem Aufwand einen Mehrwert erzielen. Drittanbieter erleichtern die technologische Erschliessung und Verbreitung, indem sie die Clientkomponenten zur Verfügung stellen.

Die Integration des Produktemixes kann selbstverständlich auch durch einen Anbieter selber geschehen, der seine Dienstleistung mit Dienstleistungen Dritter sinnvoll kombiniert und als Softwarepaket den Kunden anbietet. Als Beispiel sei der Prototyp im Anhang A angeführt. In diesem Sinne sind Mittlerfunktionalitäten implizit in der Clientkomponente der Software enthalten (virtueller Mittler).