Auctionsmartinherbort.de/docs/Documentation_AuctionsDotNet.pdf · Hasso-Plattner-Institut für...

Auctions.Net

Ein Auktionssytem auf Basis von Microsoft .NET

Marc Aßmann <[email protected]>Martin Herbort <[email protected]>

Alexander Saar <[email protected]>Lars Trieloff <[email protected]>

Hasso-Plattner-Institut für SoftwaresystemtechnikLehrstuhl für Betriebssyteme und Middleware

Prof.-Dr.-Helmert-Str. 2-314482 Potsdam

Inhaltsverzeichnis1. Einführung ....................................................................................................................... 1

1.1. Motivation und Ziele ................................................................................................ 11.2. Systemanforderungen ............................................................................................... 1

2. Anwendungsentwurf und Implementierung ............................................................................. 42.1. Überblick ............................................................................................................... 42.2. Technologien .......................................................................................................... 5

2.2.1. Komponenten-Modelle .................................................................................. 52.2.2. Werkzeuge .................................................................................................. 5

2.3. Kommunikationskonzept .......................................................................................... 62.3.1. Auction-Server :: Desktop-Client ..................................................................... 62.3.2. Auction-Server :: Mobile-Server :: Mobile-Client ............................................... 8

2.4. Auction-Server ....................................................................................................... 82.4.1. Anforderungen ............................................................................................. 82.4.2. Entwurf ...................................................................................................... 92.4.3. Implementierung .........................................................................................12

2.5. Desktop-Client ......................................................................................................142.5.1. Anforderungen ............................................................................................142.5.2. Entwurf .....................................................................................................142.5.3. Implementierung .........................................................................................18

2.6. Mobile-Server .......................................................................................................202.6.1. Anforderungen ............................................................................................202.6.2. Entwurf .....................................................................................................212.6.3. Implementierung .........................................................................................24

2.7. Mobile-Client ........................................................................................................242.7.1. Anforderungen ............................................................................................252.7.2. Entwurf .....................................................................................................252.7.3. Implementierung .........................................................................................32

2.8. Deployment ..........................................................................................................393. Schlussfolgerungen ...........................................................................................................41Literaturverzeichnis ..............................................................................................................42Glossar ..............................................................................................................................43

ii

Kapitel 1. Einführung1.1. Motivation und Ziele

Das Projekt Auctions.Net umfasst die Entwicklung, Implementierung und Dokumentation einer verteiltenAnwendung. Das Projekt findet im Rahmen der Vorlesung "Middleware und Komponentenprogrammierung"am Lehrstuhl für "Betriebssysteme und Middleware" des Hasso Plattner Instituts für Softwaresystemtechnik inPotsdam statt.

Das Ziel von Auctions.Net ist der Entwurf eines interaktiven Auktionssystems als Client/Server-Anwendungmit Hilfe von Remotezugriffen auf verteilte Objekte. Weiterhin soll zusätzlich zum normalen Desktop-Clientdie Anbindung eines SmartPhone-Clients entwickelt werden, welcher die Auktionäre in die Lage versetzt, auchmobil an den Auktionen teilzunehmen.

Abbildung 1.1. Use-Case

1.2. Systemanforderungen

Auctions.Net soll als verteilte Client/Server-Architektur implementiert werden. Bei genauerer Betrachtung derAnforderungen an ein modernes Auktionssystem wie zum Beispiel eBay genügt es jedoch nicht, nur eineneinzelnen Server die Funktionalität des gesamten Systems bereitstellen zu lassen. Vielmehr muss dieFunktionalität in verschiedene Bereiche aufgeteilt und auf unterschiedliche Server verteilt werden.

Um diese Anforderungen zu erfüllen, werden für Auctions.Net drei Server mit unterschiedlichenAufgabenbereichen entwickelt sowie die entsprechenden SmartPhone- und Desktop-Clients. Die Aufgaben undAnforderungen an diese werden im Folgenden kurz beschrieben. Für genauere Informationen über den Aufbauund die Funktion der Systemkomponenten von Auctions.Net siehe Kapitel über Anwendungsentwurf undImplementierung.

Auction-Server

Der Auction-Server stellt die Funktionalität zum Speichern und Verwalten der Auktionen zur Verfügung sowieein Interface, über das die Clients und die anderen Server des Systems mit ihm kommunizieren können. Da essich bei Auctions.Net um ein Business-System für geschäftliche Transaktionen handelt, müssen natürlichaufgrund der sensiblen zu speichernden Daten (Kreditkartennummer, Adresse, etc.) Überlegungen bezüglich derZugriffssicherungen erfolgen.

1

Folgende Anforderungen wurden für den Auction-Server definiert:

• Verwaltung von Auktionen und Usern sowie Geboten bei Auktionen.• Schnittstelle, um Zugriff von SmartPhone- und Desktop-Clients sowie durch Mobile- und Agenten-Server

zu ermöglichen.• Benachrichtigung der Clients über die Änderung des Zustandes einer Auktion.• Zusätzliche Benachrichtigung des Gewinners und des Anbieters einer Auktion per E-Mail.• Verwendung einer SQL-Datenbank, um die Persistenz der Auktionsdaten zu gewährleisten und die

Implementierung dieser aus dem Aufgabenbereich des Projektes auszulagern.• Authentifikation des Zugriffs durch einfache Sicherheitsmechanismen wie z.B. Login-Name und Passwort.

Agent-Server

Der Agent-Server soll als autonomer Teil des Auctions.Net Systems agieren. Er verwaltet autonom arbeitendeAgenten, welche mit einem gewissen Grad an Logik ausgestattet sind und stellvertretend für einen UserAktionen auf dem Auction-Server durchführen kann. Jeder im System registrierte User kann auf den Agent-Server zugreifen und Agenten erzeugen oder löschen. Dieser Ansatz verlangt natürlich bei der Realisierung einegewisse Aufmerksamkeit in Fragen der Sicherheit.

Folgende Anforderungen wurden für den Agent-Server definiert:

• Erstellen von autonomen, d.h. selbstständig agierenden Agenten zum Verkaufen und Bieten bei Auktionendurch User.

• Schnittstelle zum Zugriff durch Desktop-Clients, um Agenten erstellen, zerstören und verwalten zu können.• Schnittstelle zum Zugriff auf den Auction-Server, um Angebote abgeben zu können.• Authentifikation des Zugriffs durch einfache Sicherheitsmechanismen wie z.B. Login-Name und Passwort.

Mobile-Server

Aufgrund der Unterschiede zwischen normalen Desktop-Plattformen und mobilen Plattformen soll der Mobile-Server als Schnittstelle und Protokollumsetzer zwischen dem Mobile-Client und dem Auction-Server dienen. Dader Mobile-Client keine interaktive Front-End-Funktionalität wie der Desktop-Client bieten kann, soll derMobile-Server Nachrichten für die angemeldeten Mobile-Clients zwischenspeichern, falls diese aufgrundschwacher Funknetze oder einem leeren Akku etc. nicht verfügbar sind.

Folgende Anforderungen wurden für den Mobile-Server definiert:

• Schnittstelle zum Zugriff auf den Auction-Server, um Angebote abgeben zu können.• Schnittstelle zum Zugriff durch SmartPhone-Clients, um Angebote abgeben zu können.• Zwischenspeichern von Nachrichten für SmartPhone-Clients falls diese Offline sind.

Desktop-Client

Der Desktop-Client stellt ein interaktives Front-End für den Auctions.Net Service zur Verfügung, mit welchemman die volle Funktionalität von Auctions.Net nutzen kann. Er sollte über ein möglichst komfortables und leichtzu bedienendes grafisches User Interface (GUI) verfügen.

Folgende Anforderungen wurden für den Desktop-Client definiert:

• Schnittstelle zum Zugriff auf den Auction-Server, um Auktionen zu erstellen, anzuzeigen und auf Auktionenbieten zu können.

• Schnittstelle zum Zugriff auf den Agent-Server, um Agenten erstellen, zerstören und steuern zu können.• Anzeige der Zustände der Auktionen und persönlichen Agenten in einem grafischen User Interface (GUI).

Mobile-Client

Einführung

2

Damit die User von Auctions.Net auch über Ereignisse bei Auktionen informiert werden können, wenn sie nichtvor dem PC zu Hause oder im Büro sitzen, soll im Rahmen des Projektes auch ein Client für mobile Systemewie z.B. SmartPhones entwickelt werden. Dies ist vor allem für Geschäftsleute von Vorteil, die meistens ausberuflichen Gründen viel unterwegs sind und an die die Idee von Auctions.Net addressiert ist.

Folgende Anforderungen wurden für den Mobile-Client definiert:

• Schnittstelle zum Zugriff auf den Mobile-Server, um über diesen Auktionen zu erstellen, anzuzeigen sowieGebote abgeben zu können.

• Anzeige der Zustände der Auktionen in einem grafischen User Interface (GUI).

Einführung

3

1Im folgenden wird darauf eingegangen werden, welche Middleware-Plattform gewählt wurde und welche spezielle Art der Kommunikationdamit möglich wird.

Kapitel 2. Anwendungsentwurf und Implementierung2.1. Überblick

Aus den gegebenen Anforderungen und den identifizierten Komponenten konnten wir dann eine Sicht auf dasSystem ableiten, dies es uns ermöglichte, das Zusammenspiel der aktiven und passiven Komponenten zuerkenen.

Die Darstellung des Erkannten in Form eines FMC-Aufbaubildes erleichterte es uns, ein gemeinsames Bild vomSystem zu teilen, einheitliche Namenskonventionen einzuhalten und das Verständnis des Systems zu schärfen.

Abbildung 2.1. FMC-Aufbaubild des Gesamtsystems

Wie aus Abbildung 2.1. FMC-Aufbaubild des Gesamtsystems [] deutlich wird, besteht das System imwesentlichen aus zwei großen Schichten. Die Applikationssicht (hier Auctions.Net Service genannt) läuft aufeinem oder mehreren zentralen Servern, die sich um Datenhaltung von Auktionsdaten und Benutzerinformationkümmern sowie aus der aktiven Komponente „Auction-Server“, die die Verarbeitung jeglicher Transaktionenvornimmt.

Auf der Benutzerebene agiert der Desktop-Client in Form einer graphischen Benutzeroberfläche als Schnittstellezwischen Benutzer und Aktionsserver. Er speichert Zugangs- und Konfigurationsdaten und kommuniziert mitdem Server über eine noch nicht näher spezifizierte RPC-Schnittstelle1. Eine Sonderstellung nimmt der Mobile-Client ein. Er kommuniziert nicht direkt mit dem Auction-Server sondern sendet und empfängt Nachrichtenvom sogenannten Mobile-Server. Dieser kommt im System nur einmal an einer zentralen Stelle vor, weshalb erauch in der Applikationsschicht gezeit wird, obwohl er seitens des Auction-Servers die gleichen Schnittstellennutzt wie der Desktop-Client und für den Auction-Server nicht von einem anderen Desktop-Client zuunterscheiden ist. Der Mobile-Server fungiert als Protokollumsetzer, weil er für die Kommunikation mit demMobile-Client eine andere Schnittstelle bereitstellt als der Auction-Server von Hause aus liefert. DieseSchnittstelle ist auf die Anforderung, den Datenverkehr zu minimieren, optimiert.

Die Daten die der Desktop-Client lokal speichert werden bei mobilen Client verteilt gespeichert. Ein Teil liegtbeim Mobile-Client, der Rest beim Mobile-Server.

4

2.1.1. Umsetzung des Entwurfs

Dieser sehr modulare Aufbau ermöglichte es uns, nach der Definition der Schnittstellen die Aufgabenentsprechend der funktionalen Aufteilung der Module zu verteilen. Damit konnten detailiertereImplementationsschritte in kleineren Teams vorgenommen werden, wobei insbesondere die Methoden des Pair-Programming und der gelegentlichen Code-Reviews zur Sicherung der Qualität eingesetzt wurden.

2.2. Technologien

2.2.1. Komponenten-Modelle

Zur Realisierung des Projekts standen uns einige Komponenten-Modelle zur Verfügung. Diese wurden in derVorlesung vorgestellt. Sie sollen hier nur insoweit beschrieben werden, wie sie in unsere Überlegungen zurAuswahl eines Modelles eingeflossen sind. Eine Anforderung an das Projekt war die Wahl aus folgendenAlternativen:

• Benutzung zweier Komponenten-Modelle und keine weiteren Anforderungen bzgl. der eingesetztenProgrammiersprachen.

• Benutzung zweier Programmier-Sprachen und Benutzung eines Komponenten-Modells.

Schon diese Anforderung machte also ein Review der vorgestellten Komponenten-Modelle notwendig.

2.2.1.1. CORBA - Common Object Request Broker Architecture

CORBA ist ein Komponenten-Modell, bei der Objekte über einen sogen. Object Request Broker (ORB)miteinander kommunizieren. Kernmerkmal von CORBA ist die Plattformunabhängigkeit. Da wir aberAuctions.Net im Hinblick auf die Server und die Desktop-Clients nicht plattformunabhängig gestalten wollten,konnte dies kein Argument mehr dafür sein, CORBA einzusetzen. Schließlich mussten wir bei den Mobile-Clients sowieso auf eine ganz andere Technologie zurückgreifen. Auch sind für den Einsatz von CORBAsowohl allgemeine als auch spezielle sogen. Objektdienste nötig. Insbesondere braucht man einenNamensdienst, der für eine eindeutige Identifikation der Objekte bzgl. des Software-Systems sorgt. Durchandere Projektgruppen hatten wir von einigen Schwierigkeiten erfahren, einen Namensdienst aufzusetzen.Diesen hätten wir uns natürlich auch gestellt, dennoch haben wir uns unter den Komponenten-Modellen nochweiter umgesehen.

2.2.1.2. EJB - Enterprise Java Beans

EJB ist ein Java-basiertes Komponenten-Modell. Kernmerkmal ist hier, dass EJB serverbasiert ist. Wirbrauchten aber ein Modell, das für Server- und Client-Anwendungen gleichermaßen geeignet ist. Insbesonderewurde im Vorfeld des Projekts ein kleiner Taschenrechner programmiert, der dazu diente, einen Eindruck vomUmgang mit EJB zu bekommen. Für EJB spricht die einfache Anbindungsmöglichkeit an eine Datenbank undauch die Werkzeug-Unterstützung. Schließlich entwickelt man EJB in Java, wofür es gute, frei verfügbareEntwicklungsumgebungen gibt (z.B. Eclipse).

2.2.1.3. Microsoft .NET Framework

Das .NET Framework ist für die Entwicklung von Server- und Client-Anwendungen gleichermaßen gutgeeignet. Alle Team-Mitglieder hatten schon vor Auctions.Net mit dem .NET Framework gearbeitet. SpeziellSchlüssel-Funktionalität, die wir bereits in der Analyse des Projekts identifizieren konnten, wurde schon vorAuctions.Net in Prototyp-Projekten getestet. Dazu gehörten Events und Kommunikation über Rechnergrenzenhinweg. Für letzteres steht unter dem .NET Framework Remoting zur Verfügung. Zudem stand mit demMicrosoft Developer Network (MSDN) eine riesige Support-Datenbank zur Verfügung. Nach anfänglichenSchwierigkeiten, die zum Teil auf unvollständige oder fehlerhafte Inhalte der MSDN [MSDN] zurückzuführenwaren, ließen sich aber entscheidende Aspekte umsetzen. Dies war der Punkt, an dem die Wahl auf dasMicrosoft .NET Framework fiel.

2.2.2. Werkzeuge

Microsoft Visual Studio.NET 2003

Die ausgereifte und umfangreiche aber teure Entwicklungsumgebung VisualStudio ermöglicht komfortables und intuitives Entwickeln. Die Erfahrung des

Anwendungsentwurf und Implementierung

5

Teams hat gezeigt, dass sich wenig erfahrene und weit FortgeschritteneEntwickler sofort zurechtfinden. Während der Laufzeit des Projekts haben wir vonder 2002 Version auf die 2003 Version gewechselt. Motivation hierzu war dieIntegration des aktuellen .NET Frameworks 1.1, das u.A. in Sicherheitsaspektendeutlich ausgereifter ist als Version 1.0. Für Benutzer-Oberflächen steht derWindows Forms Designer zur Verfügung, der auf die Entwicklung von GUIs imWindows Look & Feel spezialisiert ist. Dies ist im Hinblick auf die Zielgruppe einwichtiges Merkmal, denn man darf aufgrund der Marktsituation mit einem hohenBekanntheitsgrad von Standard-Windows-Oberflächen rechnen.

NUnit 2.0 (Open Source) Hierbei handelt es sich um ein Test-Werkzeug. Mit NUnit generiert man Testfällefür Modul- und Integrationstests dadurch, dass man für jede zu testende Klasseeine Tester-Klasse schreibt. Diese führt definiert Funktionsaufrufe mit definiertenParametern durch. Vor und nach jedem Test wird die Test-Umgebung initialisiertbzw. abschließende Arbeiten durchgeführt. Dadurch kann man dieUnabhängigkeit einzelner Tests voneinander erreichen. Diese und weitereEinstellungen tätigt man durch spezielle Attribute innerhalb der Tester-Klasse.Eine Besonderheit von NUnit ist die Integration in das Visual Studio. So war esmöglich nach Anlegen einer neuen Compiler-Direktive, mit dem Start des Startup-Projekts nicht die eigentliche Anwendung, sondern automatisch NUnit mitentsprechenden Tests zu starten.

NDoc 1.1 Jan 2003(Open Source)

Ein Werkzeug, mit dem sich aus den .NET Assemblies und den zugehörigenXML-Kommentaren der Quelltexte automatisiert API-Dokumentationen in CHM-oder HTML-Hilfe erstellen lassen.

DocMan 0.99a (OpenSource)

Der DocBook Toolchain-Manager DocMan gestattet das sehr komfortableUmwandeln von XML-Dateien nach dem DocBook-Standard, z.B. in PDF oderHTML. Der DocMan ist besonders einfach zu bedienen

XMLmind XML Editor2.3 (Freeware)

XMLmind ist ein umfangreicher und komfortabler Editor für XML-Dokumente.Die Erfahrung zeigte, dass auch Programmierer, die in XML unbewandert sind,sofort mit der Erstellung komplexer Dokumente mit XMLmind zurechtkommen.

Tortoise CVS 1.2.2(Open Source)

Die Verwaltung der Quellen, der Dokumentation und der sonstigen Artefaktewurde mit dem Concurrent Versioning System (CVS) organisiert. Tortoise CVSbietet zwar nur eine spärliche Oberfläche an, dies wird jedoch durch dieIntegration in den Windows Explorer ausgeglichen. Es unterstützt allewesentlichen CVS-Funktionen wie Update, Commit und Merge. Im Laufe desProjekts kam es immer wieder zu Problemen bei der Nutzung von CVS.

Microsoft VisioProfessional 2002

Visio ist ein komplexes Modellierungswerkzeug. Viele UML-Diagramme, die z.T.nur dem projektinternen Gebrauch dienten, wurden zunächst mit MS Visioverfasst.

Sparxsystems EnterpriseArchitect 3.51

Ein Werkzeug welches Reverse-Engineering unterstützt, also die Generierung vonUML-Diagrammen aus bestehenden Quellcode-Dateien.

2.3. Kommunikationskonzept

Auctions.Net ist eine verteilte Anwendung. Dieser Abschnitt geht auf Anforderungen und alternativeKommunikationskonzepte für die Realisierung der Verteilung ein. Im folgenden werden die Anforderungen andas Kommunikationskonzept beschrieben.

2.3.1. Auction-Server :: Desktop-Client

Folgende Nachrichten werden zwischen Client und Server ausgetauscht:

Tabelle 2.1. Kommunikationsprotokoll


6

Kommunikationsphase Nachrichten

Login Benutzer anmelden

Benutzer registrieren

Transaktion Auktionen suchen

Angebote eines Benutzers zurückgeben

Angebot erzeugen

Gebote abgeben

Diese Nachrichten erfordern jeweils Antworten der Gegenseite. Daher kommt hier idealerweise eine RPC-Technologie wie .NET Remoting oder das Simple Object Access Protocol (SOAP) zum Einsatz. Da dieApplikation auf Windows-Desktops genutzt werden soll, ist eine Festlegung auf .NET Remoting über denverfügbaren binären Channel in Bezug auf Performance und Effizienz sinnvoll.

Um zu vermeiden, daß die Clients ständig beim Server rückfragen müssen, ob Auktionsdaten noch auf demaktuellen Stand sind, soll der Auction-Server die Clients über Änderungen informieren. Dafür wird einRückkanal vom Auction-Server zum Client benötigt. Benachrichtigt werden sollen die Client z.B. beimEintreffen eines neuen Gebots auf eine Auktion, oder bei Ablauf einer Auktion. Hiermit wird das Observer-Pattern aus [GAMMA 96] implementiert.

Observer: "Definiere eine 1-zu-n-Abhängigkeit zwischen Objekten, so daß die Änderung desZustandes eines Objektes dazu führt, das alle abhängigen Objekte benachrichtigt undautomatisch aktualisiert werden."—Erich Gamma: Entwurfsmuster: Elemente wiederverwendbarer objektorientierter Software

Die Clients beobachten also Auktionen auf Veränderungen. Diese Nachrichten erfordern prinzipiell keineRückantwort eines Desktop-Clients. Daher könnte hier ein zu .NET Remoting alternativesKommunikationskonzept genutzt werden. Möglich wäre die Nutzung von Multicast-Nachrichten. Alsproblematisch hierbei wurden folgende Punkte angesehen:

• Das .NET Framework verfügt von Haus aus über keine Unterstützung für die Nutzung von Multicast-Kommunikationskonzepten.

• Alle Nachrichten über einen Multicast-Kanal zu verschicken, könnte die Netzwerkbelastung beim Clientleicht auf ein nicht tolerierbares Mass erhöhen.

• Die Partitionierung der Nachrichten auf unterschiedliche Kanäle zur Netzwerkverkehrreduzierung beimClient mutete dem Team als eine zu komplexe Aufgabe an.

• Auf die Übertragung von Multicast-Nachrichten im Internet ist kein Verlass. Diese Techniken scheinenderzeit noch eher für lokale Netze sinnvoll einsetzbar zu sein.

Aus diesen Gründen und ob der einfachen Nutzbarkeit wurde bei Nachrichten, die vom Server zum Clientgeschickt werden, ebenfalls auf .NET Remoting gesetzt. Beim Einsatz von .NET Remoting muss daraufgeachtet werden, die Anzahl der auszutauschenden Nachrichten für alle Szenarien möglichst gering zu halten,um ein gute Skalierbarkeit des Systems zu gewährleisten.

Die Schnittstellen von Auction-Server und Desktop-Client müssen beiden Kommunikationspartnern bekanntsein. Dafür kann man eine .NET Assembly in Form einer Dynamic Linked Library (DLL) in die Applikationenbeider Seiten einbinden. Um unabhängige Erweiterbarkeit auf beiden Seiten sicherzustellen, sollten vor allemInterfaces und abstrakte Klassen zum Einsatz kommen. Die in dieser Assembly (AuctionsManagerInterface.dll)zusammengefassten Schnittstellenbeschreibungen enthalten folgende Definitionen:

• Interfaces des Auction-Servers.• Einfache Datenstrukturen für den Datenaustausch.• Klassen zur Ausnahmebehandlung (Custom Exceptions).• Ereignisdefinitionen (Event Types).• Ereignisrückmeldeschnittstellen (Delegates).

Davon losgelöst betrachtet werden die, bei Ablauf einer Auktion nötigen Benachrichtigungen an Käufer undVerkäufer einer Auktion. Diese Nachrichten brauchen nicht unbedingt direkt beim Desktop-Client angezeigt zu


7

werden. Für diesen Zweck eignet sich E-Mail am Besten, denn dann können Kaufs-/Verkaufbestätigungen beimAnwender mit anderen E-Mails archiviert und gegebenenfalls leicht ausgedruckt werden.

2.3.2. Auction-Server :: Mobile-Server :: Mobile-Client

Beim Zugriff von Mobile-Clients ergeben sich veränderte bzw. verschärfte Anforderungen. Der Mobile-Clientsoll auch Auktionen suchen und auf sie bieten können. Desweiteren soll der Nutzer eines Mobile-Clients auchüber Änderungen an Auktionen informiert werden. Allerdings kann von einem mobilen Gerät nicht erwartetwerden, daß es ständig online ist. Somit muss die Kommunikation vom Auction-Server in Richtung Mobile-Client in ein Request-basiertes Pull-Modell umgewandelt werden. Eine wichtige Anforderung ist auch, daßAnzahl und größe von Nachrichten minimal gehalten werden. Daher wird eine Protokollumsetzerschicht(Mobile-Server) eingeführt, die diese Anforderungen sicherstellt.

Mobile Clients sollten nicht auf Microsoft-basierte Systeme beschränkt sein, denn in diesem Bereich hatMicrosoft keine so dominierende Stellung, als daß sich die Konzentration auf die Möglichkeiten des .NETCompact Frameworks lohnen würde. Um die zukünftige Anbindung von Geräten mit Palm OS oder Symbiansicherzustellen, wird für die Kommunikation zwischen Mobile-Client und Mobile-Server SOAP eingesetzt. DieSchnittstelle zwischen Mobile-Server und Auction-Server ist dieselbe, wie die Schnittstelle zwischen Desktop-Client und Auction-Server.

2.4. Auction-Server

Der Auction-Server stellt das Herzstück des Auctions.Net Service dar. Er verwaltet Benutzer und Angebotebzw. Auktionen. Daher wird die Funktionalität auf zwei Akteure verteilt. Dies ist zum einen derAuctionsUserManager, der die Benutzerverwaltung und den Login-Prozess realisiert. Zum anderen sorgt derAuctionsManager für die Abwicklung und Steuerung des Auktionsbetriebs.

2.4.1. Anforderungen

Folgende Anforderungen wurden für AuctionsUserManager und AuctionsManager definiert:

AuctionsUserManager

• Die Registrierung neuer Benutzer muss ermöglicht werden.• Folgende Kundendaten sollen verwaltet werden:

• Namen und Anschrift• Zahlungsinformationen (Bankverbindungsdaten oder Kreditkartennummern)• Weitere Kontaktinformationen(E-mail, Telefon, etc...)

• Der Zugriff auf den AuctionsManager soll durch den AuctionsUserManager durch einen Login-Mechanismus geschützt werden.

• Die Kundendaten sollen in einer SQL-Datenbank gespeichert werden.• Eine Möglichkeit zur Konfiguration des Servers über eine Konfigurationsdatei muss gegeben sein.

AuctionsManager

• Der AuctionsManager muss durch ein Login geschützt werden, welcher vom AuctionsUserManagerbereitgestellt wird.

• Es sollen neue Auktionen von Verkäufern gestartet werden können.• Folgende Daten müssen dabei für eine Auktion gespeichert werden:

• Titel• Produktbeschreibung• Mindestpreis• Verkäufer• Laufzeit der Auktion• ggf. Bieter mit dem höchsten Gebot


8

• Die Daten einer Auktion sollen in einer SQL-Datenbank gespeichert werden.• Benutzer sollen Auktionen nach folgenden Kriterien suchen können:

• Titel• Beschreibung• maximales Gebot oder Mindestpreis

• Käufer sollen Gebote auf Auktionen abgeben können.• Für die Umsetzung des Observer-Pattern müssen Benachrichtigungen verfügbar sein, die den Client über

Aktualisierungen von Auktionsdaten informieren.• Bei Ablauf einer Auktion sollen Käufer und Verkäufer per E-Mail benachrichtigt werden.• Eine Möglichkeit zur Konfiguration des Servers über eine Konfigurationsdatei muss gegeben sein.

Die Umsetzung der Anforderungen und die bei der Implementierung angewendeten Strategien und Methodenwerden im Folgenden näher erläutert.

2.4.2. Entwurf

Die Lösungskonzepte für die Implementierung der Anforderungen werden im Folgenden mit Hilfe dersemiformalen Techniken FMC und UML spezifiziert.

Struktur und Abhängigkeit der vom Auction-Server persistent zu haltenden Daten werden im folgenden Entity/Relationship-Diagramm (ERD), welches der FMC-Spezifikation entspricht, dargestellt. Es zeigt die Entitäts-Typen Kunde, Gebot und Angebot sowie deren Beziehungen zueinander. Aus dem ERD lässt sich leichterkennen, daß ein Kunde von Auctions.Net entweder die Rolle eines Käufers oder auch eines Verkäuferseinnehmen kann. Die zu speichernden Daten für einen Entitäts-Typ können den Auflistungen der Entitäten desERDs entnommen werden. Weiterhin wurde definiert, daß eine Auktion genau einem Kunden (Verkäufer)zugeordnet ist und daß einem Gebot genau ein Kunde (Käufer) und genau eine Auktion zugeordnet ist.

Abbildung 2.2. Auctions.Net Datenstruktur

Die dargestellten Entitäts-Typen wurden ohne weitere Änderung in die Datenbank übernommen. Dabei wurdejeweils ein Entitäts-Typ mit Hilfe einer Tabelle dargestellt.

2.4.2.1. Verwendete Werkzeuge und Bibliotheken

SQL-Datenbank Zur persistenten Speicherung von Benutzer- und Auktionsdaten wird Microsoft


9

SQL-Server 2000 Desktop Engine verwendet. Sie ist im Umfang des Microsoft.Net Framework SDK enthalten und wird vom Framework und Visual Studio .Netgut unterstützt.

E-Mail SmtpEmailer ist eine Open-Source Bibliothek für das Versenden von E-Mail überSMTP. SmtpEmailer wurde von Steaven Woyan geschrieben.

2.4.2.2. Architektur

Die UML Klassendiagramme zeigen die wichtigsten Bestandteile des AuctionServer nach dem derzeitigenStand der Implementierung. Es wird eine Klasse AuctionsManager definiert, die das InterfaceIAuctionsManager implementiert. Die Klasse AuctionsUserManager ist vom Interface IAuctionsUserManagerabgeleitet. Der AuctionManager ist für die Verwaltung der Auktionen zuständig und hantiert mit Auction-Objekten. Diese stellen Behälter für AuctionInfo- und AuctionTrigger-Objekte. Clients erhalten diese Objekteals Antwort auf eine Anfrage wie SearchAuctions(), GetAuction() oder GetUserAuctions() zurück. Sie kapselndie Auktions-spezifischen Daten.

Abbildung 2.3. Auction-Server Akteure

Die Struktur der Auction-Objekte beinhaltet ein kapselndes Objekt, welches eine Auktion repräsentiert und aufdem Server lebt. Es kapselt zum einen ein AuctionInfo-Objekt, welches die Daten der Auktion beinhaltet und anden Client gesendet wird, weiterhin beinhaltet es ein AuctionTrigger-Objekt, über welches die Eventbehandlungeiner Auktion realisiert wird.


10

Abbildung 2.4. Auktionen

Diese Implemetierung der Auktionsdaten ist nicht optimal. Zwischenzeitliche Schwierigkeiten im Umgang mit.Net Remoting führten zu dieser Architektur, die sich nach dem Veröffenlichen der Schnittstellen nicht mehr soohne weiteres ändern liess. Daher wurde aus zeitlichen Gründen darauf verzichtet. Besser wäre der Aufbau nachdem folgenden Klassendiagramm gewesen.


11

Abbildung 2.5. Auktionen - Alternative Architektur

Dieser Aufbau hätte die Klassen Auction und AuctionTrigger zusammengeführt, die in der aktuellenImplementierung ohnehin zyklisch untereinander referenziert sind. Dies würde die Komplexität derImplementierung vermindern. Im alternativen Konzept sind die Events für die Clients nicht direkt zugreifbar.Die Events wurden in ein Server-internes Objekt ausgelagert. Der Client bekommt bei Anfragen zwar nochimmer eine Referenz auf diese internen Objekte und speichert sie in einem ClientAuction-Objekt, jedoch kennter nur noch das Interface der abstrakten Klasse. Das verhindert, daß Clients Events auslösen und somit denServer manipulieren können.

Das folgende Sequenzdiagramm nach dem UML-Standard beschreibt das Verhalten von Client und Server beimAufbau einer Verbindung (Register/Login) sowie einige Transaktionsvorgänge. Diese beinhalten das Erzeugenund das Bieten auf eine Auktion sowie das Benachrichtigen eines Client durch den Server nachdem ein Gebotauf eine Auktion abgegeben wurde.

Abbildung 2.6. Kommunikationsablauf zwischen Client und Server

2.4.3. Implementierung

2.4.3.1. Vorgehensweise

Auction-Server und Desktop-Client wurden von einem Team bestehend aus zwei Personen (M. Aßmann, A.Saar) entwickelt, welches das Paradigma des Extreme Programming (XP) für die Implementierung angewendethaben. Extreme Programming beschreibt die Situation, das zwei Personen im Team an einem Rechner arbeiten.Vier Augen sehen ja bekanntlich mehr als zwei. Weiterhin beinhaltet das XP-Paradigma Konventionen für dasTesten von Module. Testfälle sollen vor der Implementierung der eigentlichen Funktionen definiert undimplementiert werden.

Die Modultests wurden mit Unterstützung durch das Softwarewerkzeug NUnit durchgeführt. Dieses bietet eine


12

sehr gute Integration in Visual Studio. Zur Einbettung der Tests in die Anwendung wurde in Visual Studio eineneue Build-Konfiguration erstellt (TEST). Wird das Projekt mit dieser Konfiguration compiliert, so werdenautomatisch die die Testfälle enthaltenden Klassen mit eingebunden. Ausserdem wird bei der Ausführung desProgramms automatisch die Testumgebung gestartet. Das Einbinden der Testumgebung wird im folgendenCodebeispiel gezeigt.

Beispiel 2.1. NUnit Integration

static void Main(string[] args){

#if TEST// starting NUnit GUI if "TEST" is definedSystem.Windows.Forms.Application.Run(new NUnitForm("AuctionsManager"));

#else// normal application code

#endif

}

Besonders wichtig war der Test der Schnittstelle des Servers zum Client. Diese Schnittstelle wurde ausgiebiggetestet. Für jeden Test wird eine Testumgebung mit Testdaten aufgebaut. Die Testdaten bestehen aus einigenNutzer- und Auktionsdaten, die in die Datenbank gelegt werden. Dann wird von der Testmethode eineMethodenschnittstelle des Servers getestet. Nach jedem Testfall wird die Testumgebung samt Testdaten wiedergelöscht. Somit konnte jede Testmethode von einer statischen und intakten Testumgebung ausgehen.

2.4.3.2. Implementierungsdetails

Bei der Kommunikation des Servers mit dem Client muss davon ausgegangen werden, daß sich Clients nichtordnungsgemäß abmelden und nicht mehr erreichbar sind. Der Server muss die vom Client empfangeneCallback-Methode bei Nichterreichbarkeit des Clients aus der Ereignisbehandlungsliste streichen. Dies wurdesichergestellt, indem alle Callbacks der Events auf Auktionen einzeln in einem try-Block ausgeführt werden.Sollte die Kommunikation schiefgehen, wird der Callback des Clients entfernt. Um eine gute Performance auchbei großen Nutzerzahlen zu erzielen und die Sendung von Events asynchron von den Schnittstellenmethodenauszuführen, wird der Aufruf eines Callback in einen vom Framework bereitgestellen ThreadPool eingestellt.

Beispiel 2.2. AuctionsManager.cs

public event AuctionEventHandler AuctionEvent;private Auction auction;

public void RaiseAuctionChangedEvent(){

//only raise event, if someone subscribed to itif(AuctionEvent != null){

//call each Callback one-by-oneforeach( AuctionEventHandler handler

in AuctionEvent.GetInvocationList() ){

//Let another thread do this jobThreadPool.QueueUserWorkItem(

new WaitCallback(this.RaiseChangedEvent), handler);

}}

}

private void RaiseChangedEvent(Object callback){


13

AuctionEventHandler handler = (AuctionEventHandler)callback;

try{

handler(this.auction,new AuctionEventArgs(AuctionEventType.AuctionChanged));

}catch(Exception ex){

//Client was unreacheable, remove callback from internal listthis.AuctionEvent -= handler;

Console.WriteLine("Callback removed: {0}", ex.ToString());}

}

2.5. Desktop-Client

In diesem Kapitel werden die Anforderungen, der Entwurf und die Implementierung des Auctions.Net Desktop-Clients näher erläutert. Der Desktop-Client soll den Benutzer in die Lage versetzen, den Auctions.Net Servicefür seine geschäftliche Ativitäten optimal zu nutzen. Dazu werden die Architektur und die wichtigenImplementierungsdetails vorgestellt. Dargestellt werden auch die von uns umgesetzten Strategien,Softwarewerkzeuge und externe Bibliotheken.


Der Desktop-Client soll dem Anwender die vollen Möglichkeiten des Auctions.Net Service in komfortablerWeise nutzen lassen. Da der potentielle Markterfolg von einer Auktionsplattform fundamental von derRepräsentation des Dienstes beim Anwender abhängt, liegt ein besonderes Gewicht auf diesem Teilprojekt.

Folgende funktionale Anforderungen soll der Desktop-Client erfüllen:

• Erstellen von Auktionen (Angeboten).• Suchen von Auktionen.• Anzeigen der selbst erstellten Auktionen sowie der Auktionen, welche als Suchergebnisse gefunden wurden.• Gebote auf Auktionen abgeben.• Hohe Konfigurierbarkeit durch Speichern der erforderlichen Daten (Name, Passwort, Server-URL etc.) in

einer Konfigurationsdatei.• Überwachen von für den User interessanten Auktionen, z.B. die auf die er geboten hat.• Funktional ausgereiftes Graphical User Interface (GUI) um ein angenehmes und effektives Arbeiten zu

ermöglichen.

2.5.2. Entwurf


MagicLibrary MagicLibrary ist ein Open-Source Projekt, welches funktional erweiterte Featuresfür z.B. Sidebar, Menüs und TabPages für Windows Forms Anwendungen zurVerfügung stellt. Die Bibliothek wurde von der Crownwood Consulting Ltd.entwickelt und publiziert.


Der Client enthält, wie aus dem FMC-Aufbaudiagramm ersichtlich wird, einen Controller. Der Controllerkapselt die Funktionalität des Clients, die mit der Teilnahme am Auctions.Net Service zu tun hat. Der Controllerübernimmt die Kommunikation mit dem Auction-Server, und hält vom Server erhaltene Daten für die Anzeigein unterschiedlichen Views vor. Views stellen Auktionsdaten dar und erlauben dem Benutzer unterschiedlicheAktionen auf den Auktionen. So kann z.B. ein neues Gebot auf eine Auktion abgegeben werden. Der Controller


14

führt die Anfrage über den Auction-Server aus und sorgt nach einem erfolgreichen Gebot für die Aufnahme derAuktion in eine Favoritenliste. Der Controller benachrichtigt dabei alle Views, die Favoriten darstellen, daß eineneue Auktion in die Favoritenliste eingefügt wurde, die jetzt u.U. dargestellt werden soll.

Abbildung 2.7. Model-View-Controller Pattern im Desktop-Client

Das UML Klassendiagramm zeit einen Ausschnitt aus der Klassenhierarchie des Desktop-Clients. Es ist dieUmsetzung des FMC Aufbaudiagrammms. Die Klasse AuctionClientRemoteController übernimmt die Funktiondes Controllers. Der AuctionClientRemoteController verwaltet Auktionen in Objekten der vonRemotelyDelagatableObject abgeleiteten Klasse RMCAuctionTrigger. Unterschiedlche Views erben von einerSimpleAuctionView Basisklasse. Diese Views zeigen Auktionen in AuctionViewItem-Objekten an. Die KlasseAuctionViewItem erbt von der im .Net Framework enthaltenen Klasse System.Windows.Forms.ListViewItem.Dies ermöglicht die komfortable Anzeige von Auktionen in den AuctionViews.


15

Abbildung 2.8. Desktop-Client

2.5.2.3. GUI-Entwicklung

Im folgenden sind einige Shortcuts des Desktop-Clients abgebildet, welche die verschiedenen UIs für dasSuchen nach Auktionen, das Verwalten eigener Angebote, das Erstellen eines neuen Angebots und das Ändernder Client-Optionen zeigen.


16

Abbildung 2.9. UI für das Suchen nach Auktionen

Abbildung 2.10. UI für das Überwachen eigener Angebote


17

Abbildung 2.11. Dialog für das erstellen neuer Angebote

Abbildung 2.12. Dialog für die Optionen des Desktop-Clients



Der Desktop-Client wurde parallel zum Auction-Server von demselben 2-Mann Team entwickelt. Es wurde alsoebenfalls das Paradigma des Extreme Programming (XP) angewandt (siehe dazu auch Kapitel über Auction-Server/Implementierung). Für den Test der Funktionalität wurden Blackbox-Tests mit Hilfe desÄquivalenzklassenverfahrens nach [LIGGESMEYER 02] angewendet. Es wurden also für die verschiedenenEingabeparameter die entsprechenden Eingabeklassen gebildet, welche im Anschluss getestet wurden. Dabeiwurden die entsprechende Debugger-Ausgaben wärend der Tests analysiert und bewertet.


Der Server benötigt für die Kommunikation mit dem Client, die bei der Änderung an einer Auktion notwendigwird, eine Refernz auf ein Objekt das beim Client auf der Maschine lebt. Der Client muss also dem Server fürdie Eventbehandlung eine Methode eines Objektes einer Klasse übergeben, die von MarshalByRefObjekt erbt.


18

Da vermieden werden soll, daß der Server die Klassen kennen muss, welche die Client-Eventbehandlungenenthalten, wird eine abstrakte Klasse (RemotlyDelegatebleObject) eingeführt, die die Schnittstelle der vomClient für die Eventbehandlung definierten Objekte beschreibt. Die Klasse RemotelyDelegatableObject erbt vonMarshalByRefObject und definiert zwei Methoden, von denen eine abstrakt ist. Diese Methode definiert deneigentlichen Ereignisbehandlungscode. Somit sieht der Server keinen Client-spezifischen Code, sondern nureine klar definierte Schnittstelle.

Beim Testen der Applikation ist das Problem aufgetreten, daß Verbindungen zu entfernten Objektenzusammenbrachen, wenn sie eine gewisse Zeit inaktiv waren. Um dies zu verhindern, muss inRemotelyDelegatableObject die von MarshalByRefObject geerbte Methode InitializeLifeTimeServiceüberschrieben werden. Diese verzichtet auf die Rückgabe eines sogenannten Lease-Objektes, das dieLebenszeiteinstellungen von einem Remoteobjekt steuert. Das automatische Aufräumen von Remoteobjekten istin Auctions.Net jedoch nicht erwünscht. Daher wird einfach NULL zurückgegeben.

Beispiel 2.3. Remote Callbacks

public abstract class RemotelyDelegatableObject : MarshalByRefObject{

protected abstract void internalReceiver(object sender, EventArgs e);

public void Receiver(object sender, EventArgs e){

internalReceiver(sender, e);}

public override object InitializeLifeTimeService(){

return null;}

}

public class Callback : RemotelyDelegatableObject{

public override void internalReceiver(object sender, EventArgs e){

/* callback code */}

}

Um das in den Anforderungen verlangte Speichern von Konfigurationsdaten wie z.B. Login-Name, Passwort,Server-URL, etc. zu ermöglichen, wurde eine Komponente entwickelt, die dies übernimmt. DieserConfigurationManager enthält zwei Methoden, welche das Speichern und Laden von Objekten in XML-Dateienermöglichen. Somit konnte ein Konfigurationsobjekt definiert werden, welches zur Laufzeit geändert und ohneProbleme gespeichert bzw. geladen werden kann. Diese Technologie wird in Auctions.Net sowohl für Server alsauch für Client verwendet.

Beispiel 2.4. Speichern von Objekten in XML-Dateien

public static object load(FileInfo file){try{Stream r = (Stream)File.Open(file.FullName, FileMode.Open, FileAccess.Read);SoapFormatter c = new SoapFormatter ();

object myObject = c.Deserialize(r);r.Close();return myObject;

} catch { return null; }}


19

public static bool store(object obj, FileInfo file){try{Stream s = (Stream)File.Open(file.FullName, FileMode.Create, FileAccess.Write);SoapFormatter b = new SoapFormatter ();b.Serialize(s, obj);s.Close();return true;

}catch { return false; }

}

2.6. Mobile-Server

Der Mobile-Server dient den Mobile-Clients als Proxy, der die Kommunikation mit dem Auction-Server an dieAnforderungen in einem mobilen Umfeld anpasst.

Anfragen wie "Search", "Bid", "Sell" etc. werden von den Mobile-Clients also nicht direkt an den Auction-Server geschickt, sondern mit einem "Umweg" über den Mobile-Server. Was ist die Motivation hierzu? Nun,Auctions.Net nutzt in hohem Maße Events. Zum Teil dienen die Events der Benachrichtung von Clients überVorgänge auf dem Server. Bei den Desktop-Clients kann davon ausgegangen werden, dass sie für die Dauerihrer Auctions.Net-Sitzung alle Events "mitkriegen", für die sie sich abonniert haben. Die Übertragung vonNachrichten, die vom Server an Clients geschickt werden, kann aber in einem mobilen Umfeld nichtsichergestellt werden. Die Einführung einer protokollumsetzenden Instanz kann den mobilen Clients einAnfrage-basiertes Kommunikationsmodell ermöglichen. Nachrichten vom Server an die Clients werden indieser Instanz zwischengespeichert, bis ein mobiler Client sie abfragt. Im mobilen Umfeld ist der effizienteUmgang mit knappen und teuren Resourcen (Netzwerk-Bandbreite, Rechenleistung) anzustreben. Daher sollenAnzahl und Umfang von Nachrichten möglichst klein sein.

Der Auctions.Net Mobile-Server soll die angesprochene protokollumsetzende Instanz darstellen. Er verhält sichgegenüber dem Auction-Server wie ein Desktop-Client. Allerdings muss er die Kommunikation für vieleMobile-Clients realisieren. D.h. wenn ein Mobile-Client A mit dem Mobile-Server kommuniziert, so muss derMobile-Server gegenüber dem Auction-Server als ein Stellvertreter für A auftreten. Für alle verschiedenenMobile-Clients muss folglich der Mobile-Server eine andere Stellvertreterrolle einnehmen.


Funktionale Anforderungen

1. Umsetzung der Event-basierten Kommunikation in eine Anfrage- und Session-basierte Kommunikation.2. Konvertierung von Aufrufen aus dem Mobile-Client-Format in das Desktop-Client-Format und

anschließende Weiterleitung an den Auction-Server.3. Empfang der Rückgaben des Auction-Servers und anschließende Konvertierung das Mobile-Client-Format.4. Zuordnung dieser Rückgaben zu den entsprechenden Accounts.5. Möglichkeit des Abrufs von Benachrichtigungen des Auction-Servers durch die berechtigten Mobile-

Clients.6. Einfache Identifikation der Nutzer mittels Login-Name / Passwort-Kombination.7. Ein Account darf nur für solche Clients verwaltet werden, die dem Auction-Server als Desktop-Client

bereits bekannt sind, d.h. es gibt keine Nutzer, die Auctions.Net nur mittels mobiler Geräte nutzen.

Nichtfunktionale Anforderungen

1. Optimierung des Kommunikationsprotokolls auf effiziente Netzwerk- und Rechen-Nutzung.

Datenhaltungsanforderungen


20

1. Account-basierte Verwaltung der Mobile-Clients.2. Zwischenspeicherung von Benachrichtigungen infolge von Events als einfache Textnachrichten beim

entsprechenden Client-Account.

2.6.2. Entwurf


Der Mobile-Server ist komplett in C# geschrieben. Für die Realisierung des Mobile-Servers wurdeausschließlich auf die Standard-Bibliotheken des MS .NET-Frameworks v1.1 zurückgegriffen. Zum Testenwurde eine Bibliothek des Test-Werkzeugs NUnit verwendet.


Alle Mobile-Clients sollen mit derselben Instanz der Klasse MobileServer reden. Hier wurde folglich dasSingleton-Pattern angewandt, siehe [GAMMA 96]. Diese Instanz des Mobile-Servers kommuniziert mit demAuction-Server und prüft, ob der Nutzer des Mobile-Client dort bereits als Nutzer eines Desktop-Clientsregistriert ist. Nur in diesem Fall kann ein Account für einen Mobile-Client erzeugt werden. Auf dem Mobile-Server findet die komplette Account-Verwaltung statt. Siehe hierzu die nachstehende Abbildung.

Abbildung 2.13. FMC-Aufbaubild zum Mobile-Server

Es muss sichergestellt werden, dass mit dem richtigen Account gearbeitet wird, wenn eine Anfragehereinkommt. Dazu muss nach den Kriterien "Berechtigung des Aufrufers" und "Gültigkeit seines Accounts"der richtige Account ausgewählt werden. Auf diesem werden dann die endgültigen Aktionen wie "suchen","bieten", "verkaufen" etc. durchgeführt. Siehe hierzu die nachstehende Abbildung.


21

Abbildung 2.14. Klassen-Diagramm zum Mobile-Server

Eine Instanz der Klasse ClientObj zusammen mit einer Instanz der Klasse client_rec stellt einen Account dar.Die Instanzen der Klasse client_rec werden im folgenden "Client-Datensätze" genannt. Jeder Client-Datensatzenthält insbesondere Sicherheitsinformationen (Login-Name und Passwort) sowie eine Referenz auf einClientObj. Die Client-Datensätze sind in einem Hashtable organisiert, welches nach dem Schlüssel "SessionID"indiziert ist. Wenn eine Anfrage hereinkommt, identifiziert der Mobile-Server den richtigen Account anhand derSessionID. Ist dieser Vorgang erfolgreich, wird die gewünschte Aktion auf dem ClientObj vorgenommen. Diefolgende Abbildung stellt den Ablauf für den Fall dar, dass ein Mobile-Client erstmalig über den Mobile-Serverauf eine Auktion bieten will und der Nutzer auf dem Auction-Server zwar als Nutzer eines Desktop-Clientsbekannt ist, jedoch noch nicht über einen Account auf dem Mobile-Server verfügt.


22

Abbildung 2.15. Sequenz-Diagramm zur Erstellung eines neuen Accounts

Wenn ein Mobile-Client erstmalig mit dem Mobile-Server kommuniziert, hat er natürlich noch keine SessionID.Ohne eine solche SessionID kann er nur eine einzige Funktion auf dem Mobile-Server aufrufen: login().Übergabe-Parameter sind die gleichen Angaben zu Login-Name und Passwort wie für den Desktop-Client desNutzers. Um also den Nutzer zu authentifizieren, leitet der Mobile-Server den login()-Aufruf zum Auction-Server weiter. Geschieht dies erfolgreich, so wird ein neuer Account (ClientObj + client_rec) angelegt. Dazuwird eine Zufallszahl berechnet, die als Teil eines neuen Client-Datensatzes im Hashtable der registriertenNutzer des Mobile-Servers (registeredUsersHT) abgelegt wird. Die Zufallszahl stellt die SessionID dar und istbezüglich dieses Hashtables eindeutig. Die SessionID wird als Ergebnis dieses Vorgangs an den Mobile-Clientzurückgegeben. Jede Anfrage (ausser login()) dieses Mobile-Clients muss von nun an diese SessionIDbeinhalten. Wird, wie in Abb. 2, bid() aufgerufen, so wird an Hand der übermittelten SessionID die Identitätdes Aufrufers festgestellt und der bid()-Aufruf von dem entsprechenden ClientObj ausgeführt. Dazukommuniziert das ClientObj mit dem Auction-Server.

Der Mobile-Server basiert auf einem naiven (d.h. nicht sehr effektiven) Sicherheitskonzept: Eine SessionID istfür eine definierte Zeitspanne (Default: 10 Tage) gültig. Diese Zeitspanne beginnt mit dem Aufruf von


23

login(). Danach ist die Angabe der richtigen SessionID bei jedem Aufruf ausreichend für dieAuthentifikation des Nutzers. Login-Name und Passwort werden nur beim Aufruf von login() zurAuthentifikation herangezogen. In diesem Zuge wird dann auch eine frische SessionID generiert.



Der Mobile-Server wurde komplett von Martin geschrieben. Dennoch kam es gelegentlich zu Reviews voneinzelnen, kleineren Code-Stücken, an denen insbesondere Marc beteiligt war. Gerade im Zusammenhang mitder Verfügbarkeit des Mobile-Server-Dienstes (als .NET wellknown service) wurden so einige Fehler behoben.Z.B. war es bis in eine späte Phase der Implementierung für Mobile-Clients möglich, dieInitialisierungsmethode (run()) des Mobile-Servers aufzurufen. Dies wurde durch die Verwendung statischerMethoden behoben.

Sehr hilfreich war auch der Einsatz des Testwerkzeugs NUnit. Zu Beginn der Implementierungsphase wurdenparallel zwei Versionen des Mobile-Servers entwickelt: der eigentliche Mobile-Server und ein Dummy-Mobile-Server. Da der Auction-Server (also der Master-Server) noch nicht verfügbar war, hatten wir zu diesemZeitpunkt keine Möglichkeit, in einer geeigneten Umgebung zu testen. NUnit ermöglichte es, Testfälle zuschreiben, die Teile der Gesamt-Funktionalität schon auf Grundlage des Dummy-Mobile-Servers testeten. Auchwollten Lars, der den Mobile-Client programmiert hat, und Martin möglichst früh die Kommunikation viaSOAP testen. Dazu bot der Dummy-Mobile-Server über .NET Remoting eine Reihe von Funktionen an, die fixeRückgabe-Werte hatten und gegen die Lars testen konnte. Basis hierfür waren die "echten" Funktionen, die alsDummies auf dem Dummy-Mobile-Server zum Einsatz kamen und dort nötigenfalls verbessert wurden. Diesentspricht in Teilen der Top-Down-Integrationstest-Strategie nach [LIGGESMEYER 02].


In den Anforderungen für den Mobile-Server ist von einem Mobile-Client-Format für Rückgaben des Auction-Servers die Rede. Motivation für die Umsetzung von einem Format in ein anderes waren die Fähigkeiten derJava SOAP-Implementation kSOAP. Wie man in [ENHYDRA 03] nachlesen kann, gibt esInteroperabilitätsprobleme zwischen kSOAP und Plattformen, die SOAP unterstützen (wie MS .NETRemoting). Wir haben uns daher entschieden, die Datentypen, die zur Kommunikation zwischen Mobile-Clientund Mobile-Server genutzt werden, so einfach wie möglich zu halten. Zu diesem Zweck existiert in der KlasseClientObj die Funktion convertAuction(), die aus den komplexer strukturierten Auction-Objekteneinfache IMobileAuctionObjekte macht, die lediglich Attribute mit primitiven Datentypen enthalten.

Eine wesentliche Anforderung des Mobile-Servers ist auch die Zwischenspeicherung von Nachrichten, die dannanfallen, wenn bestimmte Events auftreten. In Auctions.Net gibt es im wesentlichen AuctionEvents. Diesebenachrichtigen alle Nutzer, die sich für diesen Event-Typ registriert haben, von Änderungen am Status einerbestimmte Auktion. Die Event-Behandlungsroutine aktualisiert bei den Desktop-Clients entsprechende Fenster.Damit ist dort die Event-Behandlung abgeschlossen. Wie sollen aber Mobile-Clients mit AuctionEventsumgehen? Schließlich sind sie oft gar nicht erreichbar. Aus diesem Grund registriert sich das ClientObj desAccounts eines Mobile-Clients auf alle AuctionEvents für diejenigen Auktionen, die dem Nutzer gehören (d.h.für die er der Verkäufer ist). Solange der Mobile-Server "lebt", werden für jedes Auftreten eines AuctionEventsNachrichten mit Angabe von Auktionsnummer, zugehörigem Titel und aktuellem Gebot generiert und in einerArrayList (messageList) gespeichert. Jedes ClientObj hat genau eine solche Liste.

2.7. Mobile-Client

Eine Anforderung an das Auctions.Net System war es, Kunden den Zugriff nicht nur von Desktop-Rechnernsondern auch von mobilen Kleinstgeräten wie GSM-Telefonen zu gewähren. Mögliche Ansatzpunkte um dieszu erreichen wären

• WAP-Schnittstelle• VoiceXML-Schnittstelle• auf dem mobilen Gerät laufende Programme

Sowohl eine WAP-basierte Benutzeroberfläche als auch eine VoiceXML-basierte, also ein über einSpracherkennungsprogramm und Text-Synthesizer arbeitende Oberfläche hätten sich sehr leicht über eineASP.NET Serverkomponente realisieren lassen, doch da diese Implementationen einen Einsatz des Internet-Information-Servers sowie unter Umständen eines VoiceXML-Gateways erfordert hätten, sowie uns der


24

plattformübergreifende Einsatz von Middlewaretechnologien herausfordernder erschien, haben wir uns für diedritte Alternative in Form eines auf dem Endgerät laufenden Programms entschieden.


Zur Erhöhung der Übersichtlichkeit werden die Anforderungen wie in [Balzert 00] beschrieben in Funktionale,Nichtfunktionale und Datenhaltungsanforderungen unterteilt.

Funktionale Anforderungen

1. Der Benutzer soll sich per Benutzernamen und Passwort beim MobileServer authentifizieren können2. Der Benutzer muss die Möglichkeit haben, eine einfache Stichwortsuche abzugeben3. Der Benutzer muss die Möglichkeit haben, sich die Liste der Auktionen anzeigen zu lassen, auf denen er

selbst bietet4. Es soll möglich sein, gleichzeitig von mehreren Clients am System teilzunehmen5. Die Benutzerschnittstelle muss eine Möglichkeit bieten, die Details der Auktion zu untersuchen

Nichtfunktionale Anforderungen

1. Die Benutzerschnittstelle soll einfach zu bedienen sein2. Auf Eingaben des Benutzers soll es eine schnelle Rückmeldung geben3. Das Volumen der zwischen Client und Server übertragenen Daten soll möglichst klein sein4. Benutzername und Passwort sollen so selten wie möglich zwischen Client und Server übertragen werden

Datenhaltungsanforderungen

1. Benutzername und Passwort sollen während einer Sitzung nicht erneut abgefragt werden2. Der Client soll den letzten Suchbegriff speichern, damit es möglich ist, zwischen Ergebnisliste und

Detailansicht zu wechseln3. Alle anderen Daten sollen serverseitig gespeichert werden

2.7.1.1. Plattform

Als Entwicklungsplattform haben wir die Java 2 Micro Edition festgelegt, eine spezielle Version der Java-Plattform, die es ermöglicht, Java-Programme auf Kleinstgeräten wie Handies, Organizern aber auch Küchen-und Haushaltsgeräten auszuführen.

Für diese Plattform haben wir uns aufgrund der hohen Verbreitung und guten Standardisierung sowie aufgrundder Tatsache, dass bereits SOAP-Bibliotheken für J2ME vorliegen, entschieden.

2.7.2. Entwurf

Der ursprüngliche Entwurf sah vor, für alle beteiligen Objekte, welche die GUI des MobileClient manipulierenund betrachten können soll, Proxy-Klassen zu erzeugen, die vom Applikationsentwickler transparent genutztwerden können, ohne es nötig zu machen, Implementierungsdetails der Nutzung des SOAP-Frameworks zunutzen.


25

Abbildung 2.16. Entwurfsdiagramm des Mobile-Client

Wie aus dem obigen Klassendiagramm deutlich wird, nutzt die AuctionGUI einen Auktionscontroller,welcher mit Beginn der Sitzung ein MobileServer-Objekt erzeugt, welches über den ProxyTransport eineSOAP-Verbindung zum MobileServer herstellt. Diese MobileServer-Instanz stellt Methoden bereit, überwelche die Liste der eigenen Auktionen angezeigt werden kann, nach Auktionen gesucht werden kann, usw.

Gängige Desktop- und Server-SOAP-Frameworks bieten Assistenten, mit denen aus einer gegebenen WSDL-Datei (die vom .NET-Framework für vorbereitete Klassen automatisch erzeugt wird) Proxy-Klassen erzeugtwerden können. Diese Funktionalität bietet das kSOAP-Framework nicht an, so dass es nötig wurde, die Proxy-Klassen von Hand zu schreiben.

2.7.2.1. GUI-Entwurf

Bei dem Entwurf der GUI haben wir zuerst Mockups der jeweiligen Formulare erstellt, die zeigen, welcheInformationen die einzelnen Screens bereitstellen. Weiterhin wurde eine Art Automatengraph gezeichnet, derzeigt mit welchem Menüpunkt man von welchem Screen zu welchem Folgescreen kommt.


26

Abbildung 2.17. Login des Benutzers

Folgeaktionen für Login des Benutzers

Aktion: AboutFolgescreen: Abbildung 2.20. About-Screen []Aktion: LoginFolgescreen: Abbildung 2.19. Übersicht [] oder Abbildung 2.18. Fehlerhafter Login [] (bei Fehleingabe)

Abbildung 2.18. Fehlerhafter Login

Folgeaktionen für fehlerhaften Login

Aktion: TimeoutFolgescreen: Abbildung 2.17. Login des Benutzers []

Abbildung 2.19. Übersicht

Folgeaktionen für Übersicht


27

Aktion: AboutFolgescreen: Abbildung 2.20. About-Screen []Aktion: LogoutFolgescreen: Abbildung 2.17. Login des Benutzers []Aktion: My AuctionsFolgescreen: Abbildung 2.22. Liste eigener Auktionen []Aktion: My MessagesFolgescreen: Abbildung 2.21. Nachrichten an den Benutzer []Aktion: SearchFolgescreen: Abbildung 2.23. Suchmaske []

Abbildung 2.20. About-Screen

Folgeaktionen für About-Screen

Aktion: LoginFolgescreen: Abbildung 2.17. Login des Benutzers []

Abbildung 2.21. Nachrichten an den Benutzer

Folgeaktionen für Nachrichten an den Benutzer

Aktion: AboutFolgescreen: Abbildung 2.20. About-Screen []Aktion: LogoutFolgescreen: Abbildung 2.17. Login des Benutzers []Aktion: OverviewFolgescreen: Abbildung 2.19. Übersicht []


28

Abbildung 2.22. Liste eigener Auktionen

Folgeaktionen für Liste eigener Auktionen

Aktion: AboutFolgescreen: Abbildung 2.20. About-Screen []Aktion: LogoutFolgescreen: Abbildung 2.17. Login des Benutzers []Aktion: Auction DetailsFolgescreen: Abbildung 2.25. Detailansicht einer Auktion []Aktion: OverviewFolgescreen: Abbildung 2.19. Übersicht []

Abbildung 2.23. Suchmaske

Folgeaktionen für Suchmaske

Aktion: AboutFolgescreen: Abbildung 2.20. About-Screen []Aktion: OverviewFolgescreen: Abbildung 2.19. Übersicht []Aktion: SearchFolgescreen: Abbildung 2.24. Suchergebnisse []


29

Abbildung 2.24. Suchergebnisse

Folgeaktionen für Suchergebnisse

Aktion: AboutFolgescreen: Abbildung 2.20. About-Screen []Aktion: LogoutFolgescreen: Abbildung 2.17. Login des Benutzers []Aktion: Auction DetailsFolgescreen: Abbildung 2.25. Detailansicht einer Auktion []Aktion: OverviewFolgescreen: Abbildung 2.19. Übersicht []

Abbildung 2.25. Detailansicht einer Auktion

Folgeaktionen für Detailansicht einer Auktion

Aktion: AboutFolgescreen: Abbildung 2.20. About-Screen []Aktion: Back to resultsFolgescreen: Abbildung 2.24. Suchergebnisse [] oder Abbildung 2.22. Liste eigener Auktionen [], je nachvorhergegangenem ScreenAktion: bidFolgescreen: Abbildung 2.26. Erfolgreiches Gebot [] oder Abbildung 2.25. Detailansicht einer Auktion [](bei Misserfolg)


30

Abbildung 2.26. Erfolgreiches Gebot

Folgeaktionen für erfolgreiches Gebot

Aktion: TimeoutFolgescreen: Abbildung 2.20. About-Screen []


Die Hauptentwicklungsumgebung für den MobileClient war der Java-basierte Text-Editor jEdit[http://www.jedit.org], der durch Plugins erweitert wurde und so eine komfortable Entwicklung erlaubte.

Der Build-Prozess wurde durch Apache Ant [http://ant.apache.org/] gesteuert, ein Java-basiertes Pendant zumake, welches über XML-Dateien gesteuert wird und ebenfalls erweiterbar ist. Die Software Antenna[http://antenna.sourceforge.net/] stellt genau so eine Erweiterung zur Verfügung, um die Arbeit mitJ2ME-spezifischen Aufgaben, wie das automatische Aktualisieren der Java Applikations Deskriptoren zuerleichtern.

Um die erzeugten Java-Archive nochmals zu verkleinern, da auf den Mobilgeräten in der Regel wenigSpeicherplatz zur Verfügung steht, wurde der Obfuscator ProGuard [http://proguard.sourceforge.net/] genutzt,der nichtbenötigte Dateien aus dem Archiv entfernt und damit den Speicherbedarf reduziert. ProGuard wurdeebenfalls über die Antenna-Erweiterungen gesteuert.

Die Softwareentwicklungskits Java 2 Micro Edition Wireless Toolkit 1.0 und 2.0 stellten nicht nur diegrundlegende Klassenbibliothek bereit, sondern lieferten mit den enthaltenen Emulatoren auch eineLaufzeitumgebung.

Die freie SOAP-Bibliothek kSOAP [http://ksoap.enhydra.org/], welche den minimalen XML-Pull-Parser kXML[http://kxml.enhydra.org/] einschließt, wurde genutzt, um SOAP-Nachrichten zu kodieren zu versenden, zuempfangen und wieder in Objekte zu deserialisieren.


Die Architektur des Mobile-Client ist äußerst einfach. Die Java Virtual Machine des Hostgerätes lädt dieMobile-Client-Applikation in den Speicher und führt sie aus. Der Mobile-Client kommuniziert perTastatureingaben und Displayausgaben mit dem Endnutzer und über das Netzwerk-Interface mit dem Mobile-Server.


31

http://www.jedit.org

http://ant.apache.org/

http://antenna.sourceforge.net/

http://proguard.sourceforge.net/

http://ksoap.enhydra.org/

http://kxml.enhydra.org/

Abbildung 2.27. Aufbaubild des Mobile-Client

Das obige FMC-Aufbaubild des Mobile-Client sollte diesen Sachverhalt klären. Die Mobile Java VM erzeugt ineiner Strukturvarianz ein Exemplar des Mobile-Client, der die eigentlich gewünschte Funktionalität bereitstellt.


In der Implementierungspraxis konnte der vorgeschlagene Entwurf leider nicht umgesetzt werden, was daranlag, dass der Emulator für die Java 2 Micro Edition es nicht erlaubte, aus SoapObjects über einenKonstruktoraufruf neue Objekte vom Typ Auction oder Bid zu erzeugen, sondern mit einem nicht alsException auffangbaren BAD METHOD SIGNATURE ERROR die Ausführung des Emulators beendete.

In der daraus erforderlichen Neustrukturierung des Codes wurde die Klasse Auction eingeführt, welcheverschiedene statische Methoden zur Umwandlung von SoapObjects in leichter zu handhabende Java-Klassen oder Variablentypen zu wandeln.


32

Abbildung 2.28. Klassendiagramm des Mobile-Client

Ein weiteres Problem hat sich beim Test des Programms auf dem Endgerät, einem Siemens S55 gezeigt. Dieerste Version des Mobile-Client wurde gegen das Mobile Information Device Profile 2.0 entwickelt, diebenutzerfreundlichere GUI-Elemente wie aktive Labels (bzw. Buttons) unterstützt, aber auf dem Endgerät nichtunterstützt wurde.

Aus diesem Grunde musste der Mobile-Client auf Version 1.0 des Mobile Information Device Profilezurückportiert werden. Auf einige dieser Unterschiede wird im Abschnitt Implementierungsdetails eingegangen.Die nun lauffähige GUI kann kann auf dem nachstehenden Bild betrachtet werden.


33

Abbildung 2.29. links und mitte: Auktionsdetails, rechts: Update-Nachricht

Sucht ein Nutzer A nach Auktionen (Suchbegriff hier: "note"), kann er zu Suchtreffern Details abrufen (sieheobiges Bild, links und mitte). Automatisch ist im Eingabefeld "My Bid" das nächste gültige Gebot enthalten.Wenn Nutzer A nun auf eine Auktion bietet, so wird der Verkäufer (Nutzer B) mittels einer Update-Nachrichtüber die Zustandsänderung seiner Auktion informiert (siehe obiges Bild, rechts).


Bei der Entwicklung wurde folgende Vorgehensweise von Lars Trieloff, dem Entwickler dieses Programmteilsgewählt.

1. Klärung mit Martin Herbort über die angebotenen Schnittstellen des MobileClient

Martin hat daraufhin einen Dummy bereitgestellt, aus dem eine WSDL-Datei erzeugt werden konnte,gegen die ich die programmatischen Schnittstellen ausrichten konnte.

2. Entwicklung der Proxy-Klassen unter Java 2 Standard Edition 1.4.

Die kSOAP-Bibliothek ist unter leichten Anpassungen kompatibel zur J2SE und da es dort einfacher ist, zutesten, da der Aufruf des Emulators entfällt und das Debugging auch einfacher fällt, wurde eineProxyTransport-Klasse entwickelt, die für J2ME von einer anderen Klasse erbt als bei J2SE und damit eineeinfache Umstellung erlaubt.

Weiterhin hat das .NET-Framework für unterschiedliche Klassen unterschiedliche Namespaces in derWSDL-Datei erzeugt und diese für den Aufruf von SOAP-Diensten bekannt sein müssen, wurden dieNamespaces und der gewünschte SOAP-Endpoint in der Klasse ProxyTransport als Konstantenfestgelegt.

3. Entwicklung der GUI.

Die GUI wurde entsprechend der Automatenspezifikation, zunächst aber ohne Interaktion mit dem Server,entwickelt.

4. Portierung der Proxy-Klassen zur J2ME.


34

Dabei traten die oben beschriebenen Probleme mit nicht umgehbaren BAD METHOD SIGNATUREERROR-Fehlern auf und es musste auf eine statische Konverterklasse ausgewichen werden.

5. Wechsel vom Dummy auf den echten Server.

Dies gestaltete sich problemlos, da lediglich die statischen Variablen der ProxyTransport-Klasse geändertwerden mussten.

6. Portierung auf MIDP 1.0.

Nach dem Test auf dem Endgerät wurde klar, dass eine Rückportierung nötig ist. Dies gestaltete sichproblemlos, da nur bestimmte und direkt nachvollziehbare Codezeilen geändert werden mussten und derUmfang des Codes sich in Grenzen hielt.


Die Klasse Auction wandelt SoapObjects in einfacher zu behandelnde Java-Typen. Ein SoapObjectbesteht selbst aus anderen SoapObjects, auf die mit der Methode getProperty zugegriffen werden kann.SoapObjects, die einfache Java-Objekte wie Integer oder String enthalten lassen sich oft einfachcasten.

Beispiel 2.5. Auction.java

package net.auctions.proxy;

import org.ksoap.SoapObject;

/*** Convenience Functions for accessing a AuctionSoap Object. Cannot create* object because of "Bad Method Singature"** @author lars* @created May 22, 2003*/public class Auction {

/*** Gets the currentBid attribute of the Auction class** @param auction Description of the Parameter* @return The currentBid value*/public static String getCurrentBid(SoapObject auction) {

String val = auction.getProperty("Current_bid").toString();System.out.println("val");return val;

}

/*** Gets the description attribute of the Auction class** @param auction Description of the Parameter* @return The description value*/public static String getDescription(SoapObject auction) {

return auction.getProperty("Description").toString();}

/*** Gets the dueDate attribute of the Auction class** @param auction Description of the Parameter* @return The dueDate value*/


35

public static long getDueDate(SoapObject auction) {String date = auction.getProperty("Due_date").toString();System.out.println(date);try {

return Long.parseLong(date);} catch (Exception e) {

e.printStackTrace();return 0;

}}

/*** Gets the id attribute of the Auction class** @param auction Description of the Parameter* @return The id value*/public static int getId(SoapObject auction) {

return Integer.parseInt(auction.getProperty("Id").toString());}

/*** Gets the minBid attribute of the Auction class** @param auction Description of the Parameter* @return The minBid value*/public static String getMinBid(SoapObject auction) {

String val = auction.getProperty("Min_bid").toString();System.out.println("val");return val;

}

/*** Gets the title attribute of the Auction class** @param auction Description of the Parameter* @return The title value*/public static String getTitle(SoapObject auction) {

String title = auction.getProperty("Title").toString();System.out.println(title);return title;

}

/*** Gets the user attribute of the Auction class** @param auction Description of the Parameter* @return The user value*/public static String getUser(SoapObject auction) {

return auction.getProperty("Uid").toString();}

}

Die Unterschiede zwischen dem MIDP 1.0 und 2.0 sollten durch die Betrachtung der folgenden Code-Abschnitte verdeutlicht werden:

Beispiel 2.6. WelcomeForm.java


36

Dies ist die Version für das MIDP 1.0

package net.auctions.gui;import javax.microedition.lcdui.Command;import javax.microedition.lcdui.CommandListener;import javax.microedition.lcdui.Display;import javax.microedition.lcdui.Form;import javax.microedition.lcdui.Item;import javax.microedition.lcdui.StringItem;import javax.microedition.lcdui.TextField;

/*** Description of the Class** @author lars* @created June 18, 2003*/public class WelcomeForm extends CommandHandler {

/*** Constructor for the LoginForm object** @param c Description of the Parameter*/public WelcomeForm(CommandListener c) {

super("Welcome", c);listMyAuctions = new Command("my Auctions", Command.ITEM, 1);this.addCommand(listMyAuctions);searchAuctions = new Command("find Auction", Command.ITEM, 1);this.addCommand(searchAuctions);listMessages = new Command("list Messages", Command.ITEM, 1);this.addCommand(listMessages);this.append(new StringItem("Welcome: ", "please select the desired action from"

+ " the menu. You can search for auctions, view your own actions and view "+ "received messages."));

logout = new Command("logout", Command.CANCEL, 1);this.addCommand(logout);about = new Command("about", Command.HELP, 1);this.addCommand(about);exit = new Command("exit", Command.EXIT, 1);this.addCommand(exit);

}

/*** Description of the Method** @param c Description of the Parameter* @param disp Description of the Parameter* @return Description of the Return Value*/public int handleCommand(Command c, Display disp) {

if (c == logout) {return AuctionGui.LOGOUT_COMMAND;

} else if (c == about) {return AuctionGui.ABOUT_COMMAND;

} else if (c == exit) {return AuctionGui.EXIT_COMMAND;

} else if (c == listMyAuctions) {return AuctionGui.LIST_COMMAND;

} else if (c == searchAuctions) {return AuctionGui.SEARCH_COMMAND;

} else if (c == listMessages) {return AuctionGui.MESSAGES_COMMAND;

}return 0;

}


37

private Command about;private Command exit;private Command listMessages;private Command listMyAuctions;private Command logout;private StringItem myAuctions;private StringItem myMessages;private StringItem search;private Command searchAuctions;

}

Die Version für das MIDP 2.0

package net.auctions.gui;import javax.microedition.lcdui.Command;import javax.microedition.lcdui.CommandListener;import javax.microedition.lcdui.Display;import javax.microedition.lcdui.Form;import javax.microedition.lcdui.Item;import javax.microedition.lcdui.ItemCommandListener;import javax.microedition.lcdui.StringItem;import javax.microedition.lcdui.TextField;

/*** Description of the Class** @author lars* @created June 18, 2003*/public class WelcomeForm extends CommandHandler {

/*** Constructor for the LoginForm object** @param c Description of the Parameter*/public WelcomeForm(CommandListener c) {

super("Welcome", c);listMyAuctions = new Command("my Auctions", Command.ITEM, 1);searchAuctions = new Command("find Auction", Command.ITEM, 1);listMessages = new Command("list Messages", Command.ITEM, 1);StringItem myAuctions = new StringItem("List", "my Auctions", Item.BUTTON);StringItem searchForAuctions = new StringItem("Search", "for Auctions", Item.BUTTON);StringItem myMessages = new StringItem("show", "my Messages", Item.BUTTON);myAuctions.setDefaultCommand(listMyAuctions);myAuctions.setItemCommandListener((ItemCommandListener) c);searchForAuctions.setDefaultCommand(searchAuctions);searchForAuctions.setItemCommandListener((ItemCommandListener) c);myMessages.setDefaultCommand(listMessages);myMessages.setItemCommandListener((ItemCommandListener) c);this.append(myAuctions);this.append(searchForAuctions);this.append(myMessages);logout = new Command("logout", Command.CANCEL, 1);this.addCommand(logout);about = new Command("about", Command.HELP, 1);this.addCommand(about);exit = new Command("exit", Command.EXIT, 1);this.addCommand(exit);

}

/*** Description of the Method** @param c Description of the Parameter* @param disp Description of the Parameter


38

* @return Description of the Return Value*/public int handleCommand(Command c, Display disp) {

if (c == logout) {return AuctionGui.LOGOUT_COMMAND;

} else if (c == about) {return AuctionGui.ABOUT_COMMAND;

} else if (c == exit) {return AuctionGui.EXIT_COMMAND;

} else if (c == listMyAuctions) {return AuctionGui.LIST_COMMAND;

} else if (c == searchAuctions) {return AuctionGui.SEARCH_COMMAND;

} else if (c == listMessages) {return AuctionGui.MESSAGES_COMMAND;

}return 0;

}

private Command about;private Command exit;private Command listMessages;private Command listMyAuctions;private Command logout;private StringItem myAuctions;private StringItem myMessages;private StringItem search;private Command searchAuctions;

}

Mit dem zusätzlichen Parameter Command.ITEM wird ein Label als aktiv markiert und mit den MethodensetDefaultCommand und setItemCommandListener werden dem Button auszuführende Aktionenzugeordnet, die aktiviert werden, sobald der Benutzer bei ausgewähltem Button die Bestätigen-Taste drückt.

2.8. Deployment

Auctions.Net ist eine verteilte Applikation. Die Server können physikalisch voneinander entfernt sein. Das heißtinsbesondere, dass die Mobile-Clients auch dann noch ihre Nachrichten vom Mobile-Server abrufen können,wenn der Auction-Server z.B. zu Wartungszwecken vorübergehend offline ist. Wie im Abschnitt "MobileServer" bereits erwähnt, kommunizieren die Mobile-Clients über den Mobile-Server, d.h. indirekt, mit demAuction-Server. Siehe hierzu untenstehende Abbildung.


39

Abbildung 2.30. Deployment von Auctions.Net


40

Kapitel 3. SchlussfolgerungenDie Wahl von Microsoft.Net als Middleware-Plattform zur Umsetzung einer Auktionsplattform hat sich alsgünstig erwiesen. Die Plattform unterstützte die Umsetzung der Anforderungen optimal. Die benötigte 2-WegeKommunikation zwischen Client und Server konnte realisiert werden. Ein paar Tücken waren bei derFehlersuche zu überwinden, da aufgetretene Fehlermeldungen häufig nur mittelbar auf die Fehlerursachehinwiesen. Die Anbindung mobiler Geräte über SOAP klappte ohne weiteres. Visual Studio alsEntwicklungsumgebung hat die Arbeit in der Implementierungsphase gut unterstützt.

Die Realisierung von mobilen Anwendungen unter Java ist hinsichtlich verfügbarer Rechenleistung auf mobilenGeräten immer noch problematisch. Vor allem der Aufwand für das Ver- und Entpacken von SOAP-Nachrichten ist hier kritisch. Es ist aber zu erwarten, daß mobile Geräte in absebarer Zeit über die nötigeLeistung verfügen werden. Der plattformübergreifenden Realisierung von mobilen Anwendungen unterNutzung von SOAP steht dann nichts mehr im Wege.

Für die Absicherung der Kommunikation unter SOAP bestehen noch keine anerkannten Standards. Die .NetPlattform bringt daher von Haus aus keine Möglichkeit zur sicheren SOAP-Kommunikation mit. Es wäre leichtmöglich, die Kommunikation auf unterer Netzwerk-Ebene abzusichern. Leider verliert man dann dieKonformität zum genutzten Standard, was den Wert des SOAP-Einsatzes mindert.

Der Einsatz von Design-Patterns hat zu einer erweiterbaren und gut wartbaren Architektur geführt. DieDefinition von Interfaces ermöglichte die arbeitsteilige (Weiter-)Entwicklung einzelner Teilprojekte. Nachdemdie Schnittstellen feststanden, konnten die Teams unabhängig vom jeweiligen Fertigstellungsstand andererTeilprojekte arbeiten.

Die Einrichtung einer Testumgebung für Unit-Testing war zunächst aufwändig. Insgesamt hat sich der Aufwandallerdings gelohnt, da eine saubere Umgebung für die Entwicklung und den Test von neuen Funktionenbereitstand. Bei der Entwicklung mit der Testumgebung konnte immer sichergestellt werden, daß einmalimplementierte Funktionalität bei der Weiterentwicklung intakt blieb.

Insgesamt muss man sagen, daß die Umsetzung einer Auktionsplattform für Desktop- und mobilen Zugriff indiesem Projekt hervorragend gelungen ist.

41

Literaturverzeichnis[LIGGESMEYER 02] Software-Qualität. Testen, Analysieren und Verifizieren von Software. Prof. Dr. Peter

Liggesmeyer. Spektrum Akademischer Verlag. Heidelberg. 2002.

[GAMMA 96] Entwurfsmuster. Elemente wiederverwendbarer objektorientierter Software. Erich Gamma,Richard Helm, Ralph Johnson und John Vlissides. Addison-Wesley. 1996.

[MSDN] MSDN. Microsoft Developer Network, www.msdn.microsoft.com. Microsoft.

[ENHYDRA 03] www.enhydra.org. Website.

42

Glossar

.Net FrameworkErweiterbare Klassenbibliothek und Ausführungsplattform zur Realisierungvon Anwendungen für Windows Betriebssysteme.

.Net RemotingKommunikationstechnik zur Realisierung von verteilten Systemen auf derMicrosoft .Net Plattform. .Net Remoting ermöglicht transparent aufentfernete Objekte zuzugreifen. Für die Kommunikation könnenunterschiedliche Protokolle zum Einsatz kommen. Darunter finden sich einproprietäres und binäres Format sowie SOAP als offenes Format.Siehe auch Simple Object Access Protocol.

Agent-ServerVerwaltet autonome Agenten, die stellvertretend für Clients Aktionen aufdem Auction-Server ausführen können.

AssemblyAssemblies bilden die Basiseinheit für Weitergabe, Versionskontrolle,Wiederverwendung, Aktivierungs-Scoping und Sicherheitsberechtigungeninnerhalb des Microsoft.Net Frameworks. Eine Assembly stellt derCommon Language Runtime die für das Erkennen vonTypimplementierungen erforderlichen Informationen zur Verfügung.

Auction-ServerDie zentrale Komponente des Auctions.Net Service. Der Auction-Server hatdie Aufgabe, die Auktionen und User zu verwalten sowie dieentsprechenden Benachrichtigungen bei Änderungen an die Clients zuschicken.

CORBA Siehe Common Object Request Broker Architectur.

Common Object RequestBroker Architectur Middleware-Kommunikationsplattform zur plattform- und

sprachunabhängigen Realisierung von verteilten Anwendungen.

Desktop-ClientBietet ein Front-End für den Auctions.Net Service. Dieses unterstüzt, imGegensatz zum Mobile-Client, die volle Funktionalität von Auctions.Net.

DLL Siehe Dynamic Linked Library.

Dynamic Linked LibraryNichtausführbare Dateien, die von verschiedenen Anwendungen dynamischgebundenen ausführbaren Code enthalten.Siehe auch Assembly.

EJB Siehe Enterprise Java Beans.

Enterprise Java BeansServerseitiger Technologie-Standard auf Java-Basis zur RealisierungInternetgestützter und verteilter Geschäftsanwendungen.

Extensible Markup LanguageVom W3-Konsortium definierte Sprache zur strukturierten Darstellung vonInformationen.

Extreme ProgrammingDas Paradigma des Extreme Programming ist eine speziell für kleine Teamsentwickelt Software-Entwicklungsmethode, welche viele derherkömmlichen Grundsätze der Software-Entwicklung in Frage stellt.

43

FMC Siehe Fundamental Modeling Concepts.

Fundamental ModelingConcepts Systembeschreibungssprache welche von Prof. Dr. Siegfried Wendt

entwickelt und am Hasso Plattner Institut für Softwaresystemtechnik gelehrtwird.

Model-View-ControllerProgrammierungs-Paradigma für besser wartbare und erweiterbareBenutzerschnittstellen. Nutzt das Beobachter-Design-Pattern.Siehe auch Observer.

Mobile-ClientAnwendung für den Einsatz auf mobilen Java-fähigen Geräten zurTeilnahme am Auctions.Net Service.

Mobile-ServerServer für Mobile-Clients. Ermöglicht die Einbindung mobiler Geräte in denAuctions.Net Service durch Umsetzung des Kommunikationsprotokolls.

MVC Siehe Model-View-Controller.

ObserverLösungsansatz für das Aktualisieren von Client-Objekten, wenn sich derZustand des beobachteten Servers ändert.

Simple Object Access ProtocolSammlung von auf XML basierenden Konventionen zum Zugriff aufverteilte Objekte.

SOAP Siehe Simple Object Access Protocol.

Unified Modeling LanguageSemi-formale Modellierungstechnik für Objektorientierte Analyse undDesign. UML gilt als Industriestandard.

UML Siehe Unified Modeling Language.

XML Siehe Extensible Markup Language.

XP Siehe Extreme Programming.

Glossar

44

Auctionsmartinherbort.de/docs/Documentation_AuctionsDotNet.pdf · Hasso-Plattner-Institut für...

Documents

Transcript of Auctionsmartinherbort.de/docs/Documentation_AuctionsDotNet.pdf · Hasso-Plattner-Institut für...