Arbeitsgruppe Diskrete Mathematik Computerorientierte Mathematik II
Sommersemester 2000
 Joswig / Jahn / Liebchen / Schwartz

eCommerce-Programmieraufgabe
TU Berlin, Math. Dep.
Fachbereich
Mathematik

Inhaltsverzeichnis

Motivation

Stellt euch vor, ihr seid ein Software-Unternehmen, das von einem Comic-Verlag den Auftrag erhalten hat, den Vertrieb seiner Produkte über das Internet abzuwickeln. Ihr stellt somit eine Schnittstelle zwischen dem Endverbraucher und dem Verlag dar, indem ihr die Kundenanfragen mit den euch vom Verlag bereit gestellten Informationen abgleicht.

Dabei soll sich der Endverbraucher bei euch darüber informieren können,

Darüber hinaus soll der Endverbraucher natürlich auch eine Bestellung über ein bestimmtes Comic aufgeben können.

Die erforderliche Software muss dann die nachfolgenden drei Gebiete abdecken:

Da wir uns aber nun einmal nicht im richtigen Leben, sondern nur in der Coma befinden, ist noch ein Wort zu der Rollenverteilung zu verlieren: Das Coma-Team ist der Verlag und ihr übernehmt sowohl die Rolle des Software-Unternehmens als auch die des Endverbrauchers.

Schema
Eure Aufgabe beschränkt sich nun aber darauf, lediglich ein Java-Applet zu entwickeln, das der Endverbraucher laden kann und mit dem er über eine Internetverbindung Produktinformationen beziehen und Bestellungen aufgeben kann. Die Abwicklung der Kommunikation zwischen eurem Unternehmen und dem Verlag, sowie die Modellierung des Verlagsdepots werden von uns gestellt.

Aufgabenstellung

Zuerst beschreiben wir, was euer Programm am Ende der letzten Woche alles leisten soll. Im Anschluss daran geben wir euch Meilensteine vor, die ihr in den folgenden Wochen erreichen sollt.

Gesamtumfang

Schreibt ein Java-Applet, das dem Benutzer die Möglichkeit eröffnet, sich über sämtliche im Verlagsdepot aktuell verfügbaren Comics zu informieren und Bestellungen für Produkte an das von uns modellierte und über das weiter unten beschriebene Kommunikationsprotokoll für euch erreichbare Verlagsdepot zu richten.

Der Programmablauf soll darin bestehen, dass zu Beginn einmal der vollständige Bestand des Verlagsdepots in das Applet eingelesen wird. Auf Wunsch des Benutzers soll der im Applet verwaltete Bestand auch zu einem späteren Zeitpunkt neu vom Verlag eingelesen werden können. Der Bestand wird von uns groß genug gewählt werden, um Unübersichtlichkeit herzustellen. Daher soll der Benutzer die Ansicht der verfügbaren Artikel einschränken (SELECT) und sortieren (ORDER BY) können. Diese Operationen sollen schnell ausgeführt werden können, sprich geeignete Datenstrukturen verwenden. Ferner soll der Benutzer einen Artikel als aktuell markieren können. Wenn zu dem aktuellen Artikel ein Bild existiert, dann soll es angezeigt werden.

Der Benutzer soll nun auf Basis der dem Applet zur Verfügung stehenden Informationen eine Bestellung über den aktuellen Artikel aufgeben können. Wenn das Ergebnis einer Bestellung darin besteht, dass die im Applet verwalteten Informationen zu dem angeforderten Artikel nicht mehr aktuell sind, dann sollen diese aktualisiert werden. Ebenso soll die im Applet mitgeführte Stückzahl nach einer erfolgreich ausgeführten Bestellung angepasst werden. Schließlich soll der Benutzer in einer separaten Ansicht angezeigt bekommen können, welche Artikel er in welcher Stückzahl zu welchem Preis geordert hat.

Erste Woche (bis 23.06.2000): Grundlagen der Datenkommunikation

Entwickelt euer Programm während der ersten Woche zunächst (mindestens) so weit, dass eine Datenverbindung (Socket) zu dem von uns implementierten und durch euch dezentral zu startenden Server aufgebaut wird. Durch diese Verbindung sendet ihr dann beide Arten von Informationsanfragen, deren Antworten euch entweder Informationen zu allen im Depot verfügbaren Produkten oder aber nur zu einem ausgewählten Artikel liefern. Überprüft die Antwort bereits darauf, ob es sich in der Tat um Produktinformationen, oder aber um eine Fehlermeldung handelt. Wenn es sich um Produktinformationen handelt, dann nehmt die erhaltenen Objekte in einen AVL-Baum auf. Der Suchschlüssel eines Artikels soll dabei sein Titel sein. Ihr könnt davon ausgehen, dass es keine zwei verschiedenen Artikel gibt, die denselben Titel besitzen.
Protokolliert in der ersten Woche zu eurer eigenen Kontrolle eure Anfragen, die Antworten des Servers sowie eventuell auftretende Exceptions in einer TextArea!

Zweite Woche (bis 30.06.2000): Erste Elemente für eine Benutzeroberfläche

Am Ende der zweiten Woche sollt ihr euer Applet so weit ausgebaut haben, dass dem Benutzer folgende Funktionalitäten zur Verfügung gestellt werden: Beachtet beim Zeichnen insbesondere, dass die Bildgröße angemessen an die Größe der zur Verfügung stehenden Zeichenfläche angepasst wird und dass paint recht selten aufgerufen wird. Letzteres will sagen, dass ihr einen Button vorsehen sollt, mit dem der Benutzer die Zeichnung des Bildes explizit anstoßen kann.

Dritte Woche (bis 07.07.2000): Weitere Elemente für eine Benutzeroberfläche

Die in dem vorigen Schritt implementierte Ansicht aller verfügbaren Artikel soll spätestens bis zum Ende der dritten Woche handhabbar gemacht werden: Dem Benutzer soll die Möglichkeit gegeben werden, die Artikel nach ihren Titeln zu sortieren (ORDER BY), falls ihr sie nicht ohnehin immer nur sortiert anzeigt... Außerdem soll er sich nur noch solche Artikel anzeigen lassen können, deren Titel ein angegebenes Suchwort enthalten (SELECT). Wenn in einer bereits durch ein voriges SELECT eingeschränkten Anzeige erneut ein SELECT verlangt wird, dann soll nur aus den momentan angezeigten Artikeln weiter ausgewählt werden. Dem Benutzer muss aber natürlich auch die Möglichkeit gegeben werden, wieder alle Artikel angezeigt zu bekommen.
Bei der Suche nach nur einem Wort des Titels hilft euch nun euer AVL-Baum recht wenig, da gemäß der lexikographischen Sortierung das erste Wort entscheidend ist. Ihr benötigt also eine weitere Datenstruktur, in der sich schnell nach einzelnen Wörtern des Titels suchen lässt. Dazu sollt ihr zusätzlich zu eurem AVL-Baum eine Hashtable implementieren, in der sich für jedes Wort eines jeden Titels ein Verweis auf das Objekt des Artikels befindet, dessen Titel das Wort enthält. Die Hashtable soll dabei keine eigenen Objekte für die Artikel erzeugen, sondern auf dieselben Objekte verweisen, wie bereits der AVL-Baum. Da es voraussichtlich mehrere Artikel geben wird, deren Titel das Wort Garfield enthält, besteht das Ergebnis einer Suchanfrage im allgemeinen auch aus mehreren Objekten.
Denkt insbesondere bei der Implementierung der Hashtable daran, diese erst autonom zu testen (module testing), bevor ihr sie in euer Applet einbaut (system testing)!

Vierte Woche (bis 14.07.2000): Bestellwesen

Spätestens am Ende der vierten und letzten Woche sollt ihr den beim eCommerce obligatorischen Einkaufswagen vollständig implementiert haben:
Der Benutzer soll für den durch ihn in der Listenansicht markierten Artikel entscheiden können, dass er eine bestimmte Stückzahl erwerben möchte. Wenn die Bestellung nicht ausgeführt werden konnte, weil die im Applet vorliegenden Informationen veraltet waren, dann sollen diese aktualisiert werden. Ebenso sollen die im Applet geführten Informationen nach einer erfolgreich durchgeführten Bestellung aktualisiert werden.
Der Benutzer soll sich schließlich in einer separaten Ansicht ansehen können, von welchen Artikeln er welche Stückzahl zu welchem Preis bestellt hat.

Das war's dann auch schon - viel Spaß bei der Bearbeitung! Und für den Fall, dass unerwartete Probleme insbesondere mit den von uns zur Verfügung gestellten Klassen oder mit dem Verbindungsaufbau auftreten, seid ihr aufgefordert jederzeit eine mail an Christian oder die anderen Mitglieder des Coma-Teams zu schicken!

Arbeiten mit Sockets

Allgemeines

Unter einer Socket versteht man einen Endpunkt einer Datenverbindung zwischen zwei Prozessen. Dabei können die Prozesse auf verschiedenen Rechnern laufen, was eine weltweite Kommunikation ermöglicht.
Die Identifikation einer Socket erfolgt über die IP-Adresse des Rechners (z.B. 130.149.11.18 für fb3-c22.math.tu-berlin.de) zusammen mit der Protokollidentifizierung (z.B. 6 für TCP, siehe auch /etc/protocols) und einer zusätzlichen so genannten Portnummer. Da auf jedem Rechner jeder Portnummer höchstens ein Prozess zugeordnet ist, kann der Empfängerprozess eines Datenpakets ausgemacht werden: Zuerst wird das Datenpaket an den durch die IP-Adresse gekennzeichneten Rechner gesendet und dieser verteilt es dann über die Portnummer an eine auf ihm laufende Applikation.
Networking

Da die weit verbreiteten Dienste ftp, telnet oder http Internet-Dienste sind, fügen auch sie sich in die oben skizzierte Hierarchie ein und besitzen insbesondere eine Portnummer. Für diese und einige weitere Dienste sind Standardportnummern vereinbart, z.B. 23 für telnet. Eine vollständige Liste befindet sich auf UNIX-Systemen in der Regel unter /etc/services. Die Portnummern bis 1023 sind für derartige Dienste reserviert, so dass wir uns bei der Wahl der für uns relevanten 16-Bit langen Portnummern auf den Bereich oberhalb von 1024 beschränken müssen. Eine gründlichere Beschreibung der allgemeinen Sachverhalte zu TCP/IP könnt ihr euch gerne im Java-Tutorial zu Gemüte führen. Dort gibt es auch noch einmal eine gründliche und Java-spezifische Beschreibung zu Sockets.

Java-Spezifisches

Die gesendeten Daten sind im übrigen zunächst von keiner Programmiersprache abhängig, sondern reine Byte-Ströme. Somit hätten wir unseren Server theoretisch auch in einer anderen Programmiersprache wie beispielsweise C schreiben können. Aber da wir euch so viel Komfort wie irgend möglich bieten wollen, ist unser Server genau wie eure Applets in Java implementiert, so dass wir nicht mit nackten Byte-Strömen operieren müssen, sondern Java-Objekte durch unsere Sockets schicken können.
Damit ein Java-Objekt direkt in eine Socket geschrieben und auch direkt aus ihr gelesen werden kann, muss es das Serializable-Interface implementieren. Da wir euch die zu versendenden Klassen beide zur Verfügung stellen, habt ihr damit für diese Programmieraufgabe nichts zu tun. Da nun aber Wissen selten geschadet hat, möchten wir euch trotzdem auf die ausführliche Beschreibung von Serialisierung im Java-Tutorial hinweisen...

Aufgabenspezifisches

Bei unserem Vorhaben müssen wir schließlich noch die Sicherheitsbestimmungen für Applets berücksichtigen. Der Teil, der uns betrifft, ist dabei der folgende Fakt:
Applets dürfen nur zu dem Host, von dem ihr class-File geladen wurde, eine Socket aufbauen!
Eine ungewollte Ausnahme hierzu stellt Ben Mesander beim Microsoft Internet Explorer auf dem Macintosh fest - Ausnahmen bestätigen halt auch hier nur die Regel!
Es trifft sich also gut, dass der Endverbraucher in unserem Konzept keinen direkten Zugriff auf das Verlagsdepot besitzen soll, sondern dass ihr als Software-Unternehmen, welches das Applet zur Verfügung stellt, als Puffer dazwischen sitzt. Das Applet wird also durch den Endverbraucher von eurem Host geladen und baut seine Verbindung nicht etwa zu dem auf einem anderen Rechner residierenden zentralen Verlagsdepot, sondern nur zu eurem dezentralen Host auf, von dem es gerade geladen wurde. Dort läuft permanent der von uns bereit gestellte und von euch zu Beginn eurer Sitzung zu startende Server, der bereit ist, Anfragen entgegen zu nehmen.
Dass dieser dezentral laufende Server dann wiederum eine Verbindung zu dem von uns zur Verfügung gestellten zentralen Verlagsdepot aufbaut, spielt für euch keine Rolle, da wir es bereits implementiert haben. Dabei handelt es sich um zwei Java-Applications, die ihrerseits im Gegensatz zu Applets Sockets zu beliebigen Hosts unterhalten können.
In eurem Applet muss also die Möglichkeit vorgesehen sein, dass dem Endverbraucher (client) eine Socket zu eurem Software-Unternehmen (server) aufgebaut wird. Der client sendet dann über diese Socket Java-Objekte zum server und erhält von dort ebenfalls Java-Objekte zurück, die der client wiederum als Antworten seiner Anfragen interpretiert. Um dies technisch zu realisieren, werdet ihr voraussichtlich die nachfolgenden Methoden verwenden müssen: Diese Liste erhebt natürlich keinerlei Anspruch auf Vollständigkeit.

Aus den Beschreibungen der aufgeführten Methoden und Klassen geht hervor, dass sie zum Teil den Programmablauf unterbrechen, um beispielsweise auf zunächst noch fehlende Ressourcen zu warten. Wir hoffen, dass die Darstellung in einem Ablaufdiagramm dazu beiträgt, euer Verständnis dafür zu schärfen, wann welche Methode auf welches Ereignis wartet.

Verfügbare Klassen

Wir unterscheiden zwei Arten von Klassen: Solche, die ihr in dem Code eures Applets verwenden müsst, und andere, die euch zur Verfügung stehen, damit ihr in eurem Software-Unternehmen die Anfragen der von euch geladenen Applets entgegen nehmen könnt.

Zur letzteren Gruppe gehört nur ComaEcomServer. Diese stellt die Möglichkeit zur Verfügung, Anfragen von Applets entgegen zu nehmen und sie an das zentrale Verlagsdepot weiterzuleiten. Das einzige, was ihr mit ihr tun sollt, ist zu Beginn eurer Sitzung einmal
fb3-c22:~ % java ComaEcomServer &
zu tippen, und zum Ende eurer Sitzung einmal
fb3-c22:~ % ps
zu starten und in Abhängigkeit des Outputs
11111 pts 0 0:00 ps
13579 pts 0 0:00 java ComaEcomServer
schließlich euren Server wieder zu beenden:
fb3-c22:~ % kill 13579
Auf diese Weise stellt ihr sicher, dass euer Applet stets eine Verbindung zu seiner Codebasis herstellen können sollte. Der auf diese Weise gestartete Server kann dann nämlich an dem Rechner fb3-c22.math.tu-berlin.de (jedoch in eurem Applet besser über einen Aufruf von getCodeBase() zu referenzieren) unter der Portnummer 1235 Anfragen eurer Applets entgegen nehmen.

Die vier Klassen

müsst ihr nun aber offensiv in eurem Code nutzen. Unter dem Punkt ComaEcom-Kommunikationsprotokoll beschreiben wir, in welchem Format euer Applet mit Hilfe dieser Klassen Anfragen an den von uns implementierten und bei euch laufenden Server stellen muss, um sinnvolle Antworten zu erhalten. Beim download der class-Files könnt ihr euch aussuchen, ob ihr sie einzeln ladet, oder als ein zip-file. Wir raten euch, eine eigene Artikelklasse zu definieren, die ihr aus einer Instanz von ComaEcomInfoRequest konstruieren könnt, und die ihrerseits vorsieht, für den repräsentierten Artikel eine neue Instanz von ComaEcomOrderRequest als auch von ComaEcomInfoRequest konstruieren zu können.

ComaEcom-Kommunikationsprotokoll

Grundsätzlich gilt natürlich, dass ihr nahezu beliebige Objekte in unsere Socket schicken könnt, genauso wie wir euch beliebige Objekte als Antwort vorsetzen können. Aber da wir eine gewisse Struktur aufbauen wollen, ziehen bestimmte Anfragen wohldefinierte Antworten nach sich, bis auf Verbindungsfehler versteht sich.

Arten von Anfragen

Coma-Article-Number (CAN)

Eine Coma-Article-Number ist ein Java-long-Wert, der einen im Verlagsdepot verfügbaren Artikel identifiziert. Eine gültige Coma-Article-Number, zu der auch ein Produkt existiert, so dass ihr auf ihr eure ersten Tests zum Verbindungsaufbau vornehmen könnt, ist beispielsweise die 256.

Christian Liebchen
Last modified: Thu Jun 15 15:00:42 MET DST 2000
$Id: index.html,v 1.3 2000/06/15 14:05:06 schwartz Exp schwartz $ 		Valid HTML 4.0!