This is an archive page !!!


Electronic Mall: Banking und Shopping in globalen Netzen

3 Die Applikationsentwicklung

In diesem Abschnitt geht es darum, verschiedene Ansätze der Applikationsentwicklungen einer Electronic Mall zu vergleichen. Dabei werden mögliche Varianten vorgestellt, wie ein Anbieter Applikationen unter Nutzung der Netzdienste realisieren kann.

3.1 Die angebotene Dienstleistung

Als erstes muss sich der Anbieter überlegen, welche Dienstleistung er in der Electronic Mall anbieten will. Zwei Dienstleistungen werden im Folgenden unterschieden:

Die Applikation dient zur Unterstützung einer Markttransaktion. Die Dienstleistung selber wird aber ausserhalb der Electronic Mall erstellt (z.B. Reservationssysteme). In diesem Falle dient die Applikation der Erfassung von Kundendaten, wie dem Ausfüllen eines Bestellformulares. Der Nachfrager wird diese Daten i. d. R. nur zu Archivzwecken wiederverwenden.

Die Dienstleistung läuft innerhalb der Electronic Mall ab. Das Produkt ist dem Nachfrager in elektronischer Form zustellbar (z.B. Datenbankabfrage, Zahlungsverkehr). In diesem Falle sollte der Anbieter darauf achten, dass der Nachfrager die Möglichkeit hat, die an ihn gesandte Information weiterverarbeiten zu können, damit dieser den entsprechenden Nutzen davon ziehen kann.

3.2 Die Gestaltung der Clientkomponente

Die meisten Anbieter setzen bereits Informationssysteme in ihrer Firma ein. Diese sind jedoch meist nicht mit der Aussenwelt verbunden. Ziel ist es, die Clientkomponente derart zu gestalten, dass die bestehenden unternehmensinternen Informationssysteme nur wenig geändert werden müssen.

3.2.1 Die Analyse der Informationsobjekte

Zuerst muss abgeklärt werden, welche Informationsobjekte zwischen Anbieter und Nachfrager ausgetauscht werden. Aus den Informationsobjekten sind diejenigen Attribute zu analysieren, die der Nachfrager ohne Mithilfe von unmittelbarer Zusatzinformation des Anbieters bearbeiten kann. Beispielsweise kann der Nachfrager dem Anbieter eine Adressänderung mitteilen, ohne vorgehend Information beim Anbieter bezogen zu haben. Umgekehrt ist es bei der Reservation eines Sitzplatzes in einem Theater: Dort muss der Nachfrager wissen, welche Plätze noch frei sind.

Sämtliche Information, welche der Nachfrager dem System ohne unmittelbare Zuhilfenahme des Anbieters liefern kann, sollte in der Clientkomponente vorhanden sein bzw. durch diese verarbeitet werden können. Das Vorhandensein bedeutet nicht, dass diese Information in Form von Programmcode vorliegen muss. Sie kann auch in einer Datenbank beim Nachfrager vorrätig sein.

3.2.2 Die Einbindung der Netzdienste

In einem nächsten Schritt muss untersucht werden, mit welcher Geschwindigkeit die Informationsobjekte zwischen Anbieter und Nachfrager ausgetauscht werden müssen. Bei einem Reservationssystem sollte der Nachfrager unmittelbar über den Buchungsstatus benachrichtigt werden. Beim Zahlungsverkehr im Retail-Bereich genügt es, den Nachfrager im Stunden- oder sogar im Tagebereich über die Kontoinformationen zu benachrichtigen. Für die Übertragung der Informationsobjekte im Stundenbereich genügen die MHS-Dienste. Werden jedoch kürzere Interaktionsintervalle benötigt, so muss auf den Gateway-Dienst zurückgegriffen werden. Dieser ist jedoch sowohl für den Anbieter, als auch für den Nachfrager teuer, da verbindungsorientiert (reliable point to point communication) kommuniziert werden muss.

Die Kommunikation im Store-and-Forward Modus fördert eine batchmässige Verarbeitung der Information. Dies verringert die Kommunikationskosten, da der Nachfrager die Informationsobjekte Offline bei sich lokal vorverarbeiten kann. Des weiteren lässt ein Batchbetrieb eine flexiblere Auslastung der Rechner zu. Spitzenlasten können durch die zusätzliche Pufferung der Objekte in den Stapeldateien einfacher geglättet werden.

3.2.3 Der Entwurf des Übertragungsprotokolls

Zur Übertragung der Informationsobjekte muss ein geeignetes Protokoll festgelegt werden. Zuallererst gilt es abzuklären, ob bereits Standards existieren, wie z.B. UN/Edifact im Zahlungsverkehr (siehe Kap. IV). Sind diese nicht vorhanden, so muss ein proprietäres Protokoll entwickelt werden. Es sollte jedoch beim Entwickeln eines solchen Protokolls darauf geachtet werden, dass tatsächlich Objekte übertragen werden und nicht nur Darstellungsinformation, wie z.B. Bitmaps. Das Übertragen von Objekten erlaubt eine Weiterverarbeitung der Information beim Nachfrager, während dies bei Protokollen, welche mehrheitlich Darstellungsinformation (z.B. VT100 oder X-Windows) übermitteln, schwieriger ist. Wird Darstellungsinformation übertragen, so ist es ohnehin schwierig, auf eine OnlineVerbindung zwischen Nachfrager und Anbieter zu verzichten, da das durch den Nachfrager zu bearbeitende Objekt (z.B. Text oder Bestellformular) sich auf dem Server des Anbieters befindet.

3.2.4 Die Gestaltung der Benutzeroberfläche

Schliesslich muss die Benutzeroberfläche bei der Clientkomponente gestaltet werden. Es ist darauf zu achten, dass eine klare Trennung zwischen der Funktionalität der Objekte und der Schnittstellenelemente herrscht. Damit können die Schnittstellenelemente ausgetauscht werden, ohne die Funktionalität zu beeinflussen.

(a) mit Darstellungsinformation: Koordinaten des Textes am Bildschirm, Farbe, Schriftart
(b) ohne Darstellungsinformation: nur der Textinhalt

Bild V - 8: Verschiedene Protokolle zwischen Client- und Serverkomponenten

Bei der Gestaltung der Benutzerschnittstelle kommen die Vorteile der ClientServer Architektur besonders zum Tragen: Da die bearbeiteten Objekte auf dem ClientRechner liegen, existiert kein Kommunikationsaufwand. Wird die Benutzerschnittstelle durch die Serverkomponente gesteuert, so bedeutet dies einerseits Rechenaufwand beim Server und andererseits eine Online-Verbindung. Zusätzlich wird sich das System in der Interaktion mit dem Benutzer langsamer verhalten, als bei einer lokalen Bearbeitung, da die Nachrichten zwischen Client- und Serverkomponente über das Kommunikationsnetz gehen müssen.

3.3 Die Gestaltung der Serverkomponente

Die Serverkomponente sollte sich nur mit der Verarbeitung der vom Client erhaltenen Informationsobjekte befassen müssen. Wird die Kommunikation zwischen Client und Server mittels eines MHS geregelt, so sind Client- und Serverkomponenten der Applikation völlig autonom. Die Serverkomponente muss lediglich Kenntnisse über die Informationsobjekte selber haben, nicht aber wie diese vom Client erstellt werden. Bei einer Gateway-Verbindung muss der Server jedoch in der Lage sein, innert nützlicher Frist dem Client eine Antwort zu liefern, damit die Benutzerergonomie gewährleistet werden kann.


Einführung Inhalt Externe Links Forum Bestellformular Sponsoren

© Copyright 1995, B. G. Teubner Stuttgart.
© Copyright 1996 Online Edition by OBS. Alle Rechte vorbehalten.
Diese Seiten können Sie am besten mit Netscape lesen!
Aktualisiert am 16. Februar 1996; Kommentare an emall@obs-us.com.