Technische Universität Ilmenau

Transcrição

Technische Universität Ilmenau
Fakultät für Informatik und Automatisierung
Institut für Theoretische und Technische Informatik
Fachgebiet Rechnerarchitekturen
Diplomarbeit
Konzeption und Realisierung der Server-Komponente für ein
P2P-File-Sharing-System, bei dem die User am
Umsatz beteiligt sind
Autor:
Holger Krauß
geb. am 04.04.1975
Studiennummer 24691
Verantwortlicher Hochschullehrer:
Prof. Dr. Ing. habil. Wolfgang Fengler
Betreuer:
Dr. Ing. Jürgen Nützel
Datum:
19. September 2002
Inventarisierungsnummer:
2002-09-04/040/IN95/2231
Erklärung
Hiermit erkläre ich an Eides statt, die vorliegende Diplomarbeit persönlich
angefertigt zu haben. Ich habe im Rahmen der Arbeit nur die im
Literaturverzeichnis aufgeführte Literatur verwendet. Auszüge und Zitate aus
der Literatur sind mittels Quellenangabe als solche gekennzeichnet.
Ilmenau, 19. September 2002
Inv-Nr. 2002-09-04/040/IN95/2231
Holger Krauß
Danksagung
Ich möchte mich bei all denen bedanken, die mich bei der Bearbeitung meines
Diplomthemas unterstützt haben und somit einen großen Beitrag zum Gelingen der
Arbeit leisteten. Mein besonderer Dank gilt meinem Betreuer Dr. Ing. Jürgen Nützel
für die konstruktive Unterstützung bei der Ausarbeitung der Diplomarbeit durch viele
wertvolle Hinweise, Anregungen und fachlichen Diskussionen.
Des Weiteren möchte ich mich bei meiner Familie bedanken, deren vorbehaltlose
Unterstützung mir dieses Studium ermöglicht hat.
Inv-Nr. 2002-09-04/040/IN95/2231
Holger Krauß
Thesen zur Diplomarbeit
1.
Für das Problem des profitablen Vertriebes von virtuellen Waren über das
Internet existiert derzeit keine hinreichende Lösung.
2.
Digital Rights Management (DRM) Systeme widersprechen dem Prinzip offener
Sicherheitsanforderungen, da sie die Rechteverwaltung in Hände derer gibt, die
kein Interesse daran haben.
3.
P2P-Netzwerke
befriedigen
das
Bedürfnis
der
Internet-Nutzer,
direkt
untereinander Daten auszutauschen und miteinander zu kommunizieren.
4.
Beim Strukturvertrieb, auch Multi-Level-Marketing (MLM) genannt, werden
Kunden Teil des Vertriebsnetzes, indem sie Waren nicht nur konsumieren
sondern an andere weiterverkaufen.
5.
P2P-Netzwerke eignen sich zur Realisierung einer MLM-Struktur für den
Vertrieb von virtuellen Waren über das Internet.
6.
Provisionen in finanzieller Form motivieren die Nutzer des Potato-Systems für
eine Vertriebstätigkeit und zum Bezahlen von virtuellen Waren.
7.
Die Zentralisierung der Nutzer- und Transaktionsverwaltung des PotatoSystems im Accounting-Server führt zur Struktur eines hybriden P2PNetzwerkes und ermöglicht einen effizienteren Ablauf als ein reines P2PNetzwerk ohne zentrale Instanz.
8.
Die
Transaktionsnummer
dient
zur
eindeutigen
Identifizierung
eines
elektronischen Belegs oder einer Quittung und ist somit die Basis für das
funktionale Prinzip des Potato-Systems.
9.
Das Potato-System macht das Interesse der Provider von virtuellen Waren zu
dem der Konsumenten und wirkt somit deren Verfeindung entgegen.
Inv-Nr. 2002-09-04/040/IN95/2231
Holger Krauß
Inhaltsverzeichnis
1.
EINLEITUNG UND MOTIVATION....................................................................... 1
2.
PEER-TO-PEER NETZWERKE.......................................................................... 3
2.1.
P2P-Architekturen ......................................................................................................8
2.1.1.
Reines P2P ........................................................................................................................ 8
2.1.2.
Hybrides P2P (koordiniertes)........................................................................................... 14
2.1.3.
Cycle Sharing................................................................................................................... 16
2.2.
P2P-Geschäftsmodelle.............................................................................................16
2.2.1.
Bannerwerbung................................................................................................................ 17
2.2.2.
Affiliate Marketing ............................................................................................................ 18
2.2.3.
Struktur-Marketing ........................................................................................................... 20
2.2.4.
Punkte- und Rabattsystme .............................................................................................. 22
3.
LÖSUNGSANSÄTZE FÜR DAS POTATO-SYSTEM ....................................... 23
3.1.
Dezentraler Lösungsansatz mit reinem P2P..........................................................24
3.2.
Praktikabler Lösungsansatz mit koordiniertem P2P.............................................28
3.2.1.
Einführung der beteiligten Personen ............................................................................... 29
3.2.2.
Beschreibung des prinzipiellen Ablaufes......................................................................... 31
3.2.3.
Erweiterung um eine Virtuelle Community ...................................................................... 34
4.
KONZEPTION................................................................................................... 36
4.1.
Anwendungsfallanalyse...........................................................................................37
4.1.1.
Akteure............................................................................................................................. 37
4.1.2.
Anwendungsfall: Als Provider registrieren....................................................................... 38
4.1.3.
Anwendungsfall: Datei anmelden .................................................................................... 39
4.1.4.
Anwendungsfall: Als Käufer registrieren.......................................................................... 41
4.1.5.
Anwendungsfall: Datei kaufen ......................................................................................... 42
4.2.
Anwendungsarchitektur ..........................................................................................43
4.3.
Businessklassen identifizieren ...............................................................................45
Inv-Nr. 2002-09-04/040/IN95/2231
4.4.
Fachklassenmodellierung .......................................................................................46
4.5.
Komponentenabgrenzung .......................................................................................48
4.6.
Aktivitäten modellieren ............................................................................................50
4.7.
Dialoge identifizieren ...............................................................................................52
4.8.
Transaktionsnummern.............................................................................................53
5.
IMPLEMENTIERUNG EINES PROTOTYPS..................................................... 56
5.1.
Überblick über verwendete Technologien .............................................................57
5.1.1.
MySQL Datenbank Server............................................................................................... 57
5.1.2.
JavaBeans ....................................................................................................................... 57
5.1.3.
Java Servlets ................................................................................................................... 58
5.1.4.
JavaServer Pages (JSP) ................................................................................................. 58
5.1.5.
Java Applets .................................................................................................................... 59
5.2.
Umsetzung der Anwendungsarchitektur ...............................................................59
5.3.
Kommunikation zwischen Applets und dem Server .............................................61
6.
ZUSAMMENFASSUNG UND AUSBLICK ........................................................ 63
LITERATUR- UND QUELLENVERZEICHNIS ......................................................... 65
ABBILDUNGSVERZEICHNIS.................................................................................. 67
TABELLENVERZEICHNIS ...................................................................................... 68
ANHANG A – DATENBANKSCHEMA DES POTATO-SYSTEMS.......................... 69
Inv-Nr. 2002-09-04/040/IN95/2231
1. Einleitung und Motivation
Seite 1
Die Produktion und der Vertrieb von multimedialen Produkten sind sehr teuer. Firmen
wie BMG, Sony und Vivendi, aber auch Hersteller von Software wie Microsoft oder
Oracle, tragen die gesamten Kosten und das Risiko. Sie sind somit auf den Erlös aus
dem Verkauf ihrer Produkte angewiesen. Die Verbreitung von illegalen oder
unlizensierten Kopien von Musik, Film, Software, etc. untergräbt dieses Modell.
Insbesondere
im
Musikgeschäft
könnte
dies
dazu
führen,
dass
Autoren,
Komponisten und Sänger nicht mehr ausreichend bezahlt und gefördert werden
können und somit keine hochwertigen Produktionen mehr entstehen. Mit der rasch
zunehmenden
Bandbreite
des
Internets
und
ständig
verbesserten
Komprimierungsverfahren betrifft diese Problematik auch immer stärker Kino- und
Videoproduktionen.
Eine wesentliche Rolle bei der Verbreitung von illegalen Kopien spielen sogenannte
Internet-Tauschbörsen. Auch wenn Napster bereits nicht mehr existiert, dürfte es
immer noch das bekannteste Beispiel dafür sein. Diese Tauschbörsen, die auch als
File-Sharing-Netze bezeichnet werden, basieren auf Peer-To-Peer-Netzwerken, wie
Gnutella oder Freenet. Sie erlauben ihren Nutzern auf einfache und schnelle Weise
in ihrem Besitz befindlichen Content mit anderen zu teilen, sowie gesuchte Inhalte
von anderen zu kopieren. So verbreiten sich gerade illegale Kopien von populären
Inhalten wie Musiktitel der Top-Ten rasend schnell im Internet.
Besonders im Bereich der Musik- und Filmindustrie ist man um Lösungen bemüht,
um den Schaden in der Zukunft einzudämmen. Zunächst zogen die großen
Produktionsfirmen in einen Krieg gegen die Internet-Tauschbörsen und erzwangen
auf gerichtlichem Weg die Abschaltung von Napster. Allerdings fanden die
ehemaligen Napster-Nutzer schnell Ersatz in neuen Tauschbörsen, die zu dem noch
weniger angreifbar waren als das Original.
Weitere Bemühungen beschäftigen sich mit den Inhalten selbst. Sogenannte Digital
Rights Management (DRM) Systeme sollen die Nutzung der Produkte so
einschränken, dass die Erstellung und Verbreitung von illegalen Kopien unmöglich
wird. Bei diesen Systemen wird jedoch die Verwendung der Produkte über ein
Werkzeug gesteuert bzw. eingeschränkt, dass auf dem Endgerät des Nutzers
installiert ist. Damit wird dieser gezwungen, die Bedürfnisse des Providers und nicht
Inv-Nr. 2002-09-04/040/IN95/2231
Seite 2
seine eigenen zu befriedigen. Es ist zu bezweifeln, dass diese Bemühungen den
gewünschten Erfolg bringen. Mit dem Verkauf geben die Hersteller ihre Produkte
unter die Kontrolle der Kunden, was einem fundamentalen Prinzip offener
Sicherheitsanforderungen widerspricht: Die Mittel zur Durchsetzung von Interessen
müssen sich in der Hand derer befinden, die die Interessen verfolgen. Denn wie die
Erfahrung zeigt, gelingt es immer wieder, die unter hohem Aufwand hergestellten
Mechanismen zur Nutzungskontrolle auf Endgeräten auszuschalten oder zu
umgehen.
Des
Weiteren
versucht
die
Musikindustrie
derzeit,
das
Internet
als
Vertriebsmöglichkeit für sich zu erschließen. Bei den Ergebnissen handelt es sich
zumeist um Angebote, bei denen die Nutzer einzelne Titel gegen Bezahlung
herunterladen können. Es ist jedoch fraglich, ob solche Angebote auf große
Nutzerakzeptanz stoßen werden. Keine der derzeitigen Bemühungen der Anbieter
von virtuellen Waren liefert den Internet-Nutzern Grund genug, vom kostenlosen
Angebot der Tauschbörsen zu gebührenpflichtigen Angeboten zu wechseln. Für das
Problem des profitablen Vertriebs von virtuellen Waren über das Internet scheint es
also derzeit keine ansprechendeLösung zu geben.
Ziel dieser Arbeit soll es nun sein, einen neuen Lösungsansatz für dieses Problem zu
betrachten. In Kapitel 2 wird zunächst der aktuelle Stand als Basis dargelegt. Darauf
aufbauend soll im Kapitel 3 zunächst herausgefunden werden, ob dieser Ansatz
prinzipiell in der Lage ist, eine sinnvolle Alternative zu bestehenden Lösungen für
den Internetvertrieb von virtuellen Waren anzubieten. Die Idee bei diesem Ansatz ist
es, ein Peer-To-Peer-Netzwerk zum Vertrieb von virtuellen Waren im Internet
aufzubauen, bei dem die Nutzer selbst Teil der Vertriebsstruktur sind. Zur Motivation
für diese Vertriebstätigkeit werden die Nutzer in Form von Provisionen am Umsatz
beteiligt. Aus dieser Idee soll ein prinzipiell sowie technisch realisierbarer
Lösungsansatz entwickelt werden. Für die Umsetzung dieses Ansatzes wird in
Kapitel 4 ein Konzept erstellt. Um die Funktion des konzipierten Systems testen zu
können, soll noch ein Prototyp implementiert werden, womit sich Kapitel 5
beschäftigt.
Inv-Nr. 2002-09-04/040/IN95/2231
2. Peer-To-Peer Netzwerke
Seite 3
Das Internet, wie es in den späten 60iger Jahren ursprünglich konzipiert wurde, war
ein Peer-To-Peer-System. Angedachter Sinn des ARPANET war die gemeinsame
Nutzung
von
Computerressourcen
in
einem
USA-weitem
Netzwerk.
Die
Herausforderung dabei war es, unterschiedliche existierende Netzwerke, sowie
künftige Technologien in einer gemeinsamen Netzarchitektur zu integrieren, die
jedem Host erlaubt, ein gleichwertiger Netzteilnehmer zu sein. ARPANET verband
damals Hosts nicht in einer Master/Slave oder Client/Server Beziehung, sondern als
Peers (Ebenbürtige) im Netzwerk. Generell waren zwei beliebige Rechner im Netz in
der Lage, Datenpakete auszutauschen, und das Netz diente vor allem Forschern zu
Kommunikation und Datenaustausch. Zwar waren FTP oder Telnet selbst
Client/Server Anwendungen, jedoch war das Nutzungsmuster als ganzes gesehen
symmetrisch, denn jeder Host im Netz konnte zu jedem anderen Host FTP- oder
Telnetverbindungen herstellen. Aus dieser grundlegenden Symmetrie entstanden
komplexere Systeme wie Usenet oder das Domain Name System (DNS), die auf
Peer-To-Peer-Kommunikation basieren. Mit der zunehmenden Verbreitung des
Internets kippte dieses Gleichgewicht dahingehend, dass immer mehr Nutzer
hinzukamen, die nur die bereitgestellten Ressourcen, anfänglich meist Informationen,
konsumierten. Die Zahl der Netzteilnehmer, die Ressourcen bereitstellten, blieb im
Verhältnis gesehen sehr gering. Dieses Ungleichgewicht zwischen Konsum und
Publikation führte dazu, dass sich das Internet immer mehr zu einer Client/Server
Landschaft entwickelte, in der die gesamten Ressourcen auf wenigen Servern
zentralisiert wurden und die Mehrheit der Netzteilnehmer nur als Clients auf diese
Ressourcen zugriff (siehe Abbildung 1). Dies ist vor allem auf die mehrheitlich
„dünne“ Anbindung dieser neuen Netzteilnehmer zurückzuführen, die es unmöglich
machte, dass diese über Modems angebundenen Hosts auch Inhalte anboten. Die
Client/Server Architektur beherrscht bis heute das Internet. Peer-To-Peer wurde
somit zunächst in den Hintergrund gedrängt [1].
Inv-Nr. 2002-09-04/040/IN95/2231
Seite 4
Client
Client
Client
Server
Client
Client
Abbildung 1:
Client/Server-Modell
Mitte der neunziger Jahre rückte der Wunsch der Clients, Daten direkt untereinander
auszutauschen, wieder mehr in den Vordergrund. Auch wenn der Inhalt dieses
Austausches nun nicht mehr wissenschaftlichen Zwecken wie zu den Anfängen des
Internets dient, ist das Prinzip jedoch dasselbe. Zunächst beschränkte sich der
Datenaustausch auf Kurznachrichten, dem Instant Messaging, einer Form der
Kommunikation unter Netzteilnehmern, hervorgebracht durch das Programm ICQ („I
seek you“). Mit immer weiter zunehmender Leistungsfähigkeit der Clients und
Geschwindigkeit der Netzwerke, die sie verbanden, wurden auch andere Inhalte wie
Musik und Bilder zu beliebten Tauschobjekten im Internet. Der Erfolg von Napster
zeigt, wie groß der Bedarf der Internetnutzer ist, populäre Inhalte untereinander,
eben „Peer“ zu „Peer“, auszutauschen.
Da nun für all diese neueren Ansätze zum Austausch von Daten zwischen allen
möglichen Netzteilnehmern der Begriff „Peer-To-Peer“ (P2P) verwendet wird, ist es
sinnvoll, diesen einmal etwas näher zu betrachten.
Ursprünglich gilt für P2P-Netzwerke, dass die “Peers” gleiche Fähigkeiten und
gleiche
Verantwortung
haben
und
dass
zwischen
ihnen
symmetrische
Kommunikation besteht. Für heutige Verhältnisse vereinfacht dies das Verständnis
für diese neuen Ideen jedoch etwas zu stark oder besser gesagt ist er zu
einschränkend. Somit gilt es, die Veränderungen des Verständnisses des Begriffes
Inv-Nr. 2002-09-04/040/IN95/2231
Seite 5
P2P zu erklären und zu verstehen. Der grundlegende Unterschied heutiger P2PNetzwerke und der aus den Anfängen der Netzwerktechnologie besteht in den
Netzknoten (nodes). Heutige Netzwerke sind im Gegensatz zu Früheren von einer
Heterogenität aus verschiedensten Geräten geprägt. Heute verbinden sich neben
PCs auch Mobiltelefone, PDAs und andere Smart-Devices mit Servern und
untereinander. Diese Heterogenität hat die Äquivalenz der früheren P2P-NetzwerkArchitekturen ersetzt. Die Ebenbürtigkeit der Teilnehmer in heutigen P2P-Netzen
bezieht sich nur noch auf eine Fähigkeit, direkt miteinander zu kommunizieren. Im
traditionellen Client/Server-Umfeld des Internets nimmt die Mehrheit dieser sich im
Netzwerk befindlichen Geräte die Rolle von reinen Clients ein, heißt sie greifen nur
auf Netzwerkressourcen zu (Informationen, Dokumente, Applikationen, Medien etc.),
ohne dabei selbst einen Beitrag oder Wert zum Netz hinzuzufügen. Gute Beispiele
dafür wären das Browsen im Internet oder das Streamen eines Videos. Somit läuft
die gesamte Kommunikation nur zwischen Client und Server ab und weist eine
starke Asymmetrie auf, so dass weit mehr Daten vom Server zum Client gesendet
werden als umgekehrt. Als Konsequenz daraus findet sich diese Asymmetrie z.B. in
Kabel- oder DSL-Angeboten verschiedener ISPs wieder: Die DownstreamGeschwindigkeit ist oft um ein vielfaches höher als die Upstream-Geschwindigkeit.
Ein großes, sich daraus ergebendes Problem ist die schlechte Skalierbarkeit dieser
Client/Server-Netze. Um immer mehr neuen Clients den Zugriff auf einen Server zu
ermöglichen, reicht nicht einfach der Anschluss des Clients an das Internet aus. Die
zusätzliche Belastung des Servers erfordert sowohl eine Erhöhung der Bandbreite
des Netzzuganges als auch die Erhöhung der Rechenleistung des Servers.
Aus Sicht der „P2P-Bewegung“ sind diese ursprünglich als reine Clients gesehenen
Knoten der Kern der veränderten Betrachtungsweise. Client/Server Modelle
berücksichtigen heute zu wenig, dass sich ein Großteil der Ressourcen vom Zentrum
weg zu den Clients verschoben hat. Diese Clients vereinen nämlich gewisse
interessante Eigenschaften.
Inv-Nr. 2002-09-04/040/IN95/2231
Seite 6
Abbildung 2:
Ausschnitt aus Gnutella-Netzwerk
Sie befinden sich alle am „Rande“ des Netzwerks bzw. des Internets, d.h. sie sind
letztes Element in der Kette der Vernetzung und sind in der Regel vom DNS System
ausgeschlossen, da sie meist keine fixen IP-Adressen haben. Weiterhin besitzen sie,
durch
neue,
erschwinglichere
Technologien
(z.B.
Prozessor,
Harddisk,
Breitbandnetzzugänge) begünstigt, wertvolle meist brachliegende Ressourcen
(digitale Dokumente, digitale Medien, Präsenz des Benutzer/Besitzer, Speicherplatz,
Rechenleistung, Bandbreite). P2P-Netzwerke machen sich genau diese freien
Ressourcen zu nutze, um das Bedürfnis der Nutzer, direkt untereinander zu
kommunizieren und Daten auszutauschen, zu befriedigen. Zur Realisierung solcher
Netze sind nun spezielle Applikationen nötig.
Diese Applikationen müssen dezentralisierte Ressourcen finden und verwalten
können, sowie sich in einem Umfeld temporärer Verbindungen und wechselnder IPAdressen zurechtfinden. Weiter müssen die Knoten außerhalb des DNS-Systems
operieren und sind teilweise oder total unabhängig von zentralen Servern/Hosts.
P2P-Systeme müssen also zwei Dinge gewährleisten:
•
Variable Konnektivität und Temporäre Netzwerkadressen
•
Unabhängigkeit der einzelnen Knoten
Inv-Nr. 2002-09-04/040/IN95/2231
Seite 7
Napster und ICQ sind gute Bespiele für P2P-Applikationen. Beide lassen in ihrer
Verwaltung das DNS-System außer Acht, die Kontrolle der Verbindung liegt beim
Knoten und die „Peers“ können autonom in Bezug auf ihre Ressourcen handeln.
Es gibt aber noch weitere Merkmale, die für P2P-Netwerke von Bedeutung sind. Da
wäre zunächst der so genannte Netzwerkeffekt. Er tritt in allen Arten von Netzwerken
auf und besagt, dass durch das Hinzukommen neuer Netzteilnehmer im System
zusätzliche Ressourcen, Fähigkeiten, etc. allen Beteiligten des Netzwerks zugute
kommen. Für die Beschreibung eines P2P-Netzwerks ist also die Anzahl der
beteiligten Knoten oder „Peers“ ein wichtiger Punkt. Eine hohe Anzahl von Knoten
bewirkt somit eine bessere Verfügbarkeit von Ressourcen (digitale Inhalte,
Speicherplatz, Rechenleistung, etc.), und steigert somit den Wert des Netzwerks. Vor
allem populäre Inhalte verbreiten sich durch die hohe Nachfrage schnell über das
Netz und sind dadurch redundant auf vielen Hosts zu finden und damit gut verfügbar.
Ein weiteres Merkmal heutiger P2P-Strukturen ist die Möglichkeit der Separierung
von Authoring und Publishing. Dies bedeutet, dass jeder Netzteilnehmer auch Inhalte
publizieren, sprich weitergeben kann, die er nicht selbst verfasst hat. Diese Tatsache
ist, wie der Fall Napster zeigt, höchst problematisch. Obwohl das Internet die
Selbstpublikation stark verbreitet hat, verbringen die meisten User heute noch immer
bedeutend mehr Zeit, Informationen zu verarbeiten (Downloaden) als selbst
herzustellen. Systeme wie Napster und Gnutella ermöglichen bzw. ermöglichten
somit neben dem Publizieren eigenen Schaffens auch das Verbreiten von Daten und
Inhalten, welche man selbst nicht verfasst hat. Dass dies zu Problemen mit
Urheberrechten führt illustriert der Fall Napster sehr gut. Auch wenn das File Sharing
von Napster abgeschaltet ist, wird dieses Merkmal weiterhin kennzeichnend für noch
existierende und neue P2P-Netze sein (Gnutella, Freenet, etc.) [1].
Zusammenfassend kann gesagt werden, dass P2P-Netzwerke eine Möglichkeit
bieten, das Verlangen der Internetnutzer, miteinander direkt zu kommunizieren und
Daten auszutauschen, befriedigen. Dieser Trend führt zu einer Verlagerung von
Ressourcen, vor allem in der Form von digitalen Inhalten, heraus aus dem Zentrum,
in Form der Server, an den Rand des Internets, zu den ursprünglich als Clients
fungierenden Hosts. Hierfür sind Applikationen nötig, die diese Ressourcen
verwalten und in Netzwerke integrieren. Dies müssen sie in einem heterogenen und
Inv-Nr. 2002-09-04/040/IN95/2231
Seite 8
dynamischen Umfeld von autonomen Netzwerkknoten realisieren, ohne dabei mehr
als nötig zu standardisieren, um die Vorteile der Vernetzung optimal zu nutzen.
2.1. P2P-Architekturen
Grundsätzlich gibt es zwei verschiedene Formen von P2P-Architekturen. Die Erste
ist die reine Form eines P2P-Netzwerks, die Zweite eine P2P-Architektur, welche
durch Elemente einer Client/Server-Architektur erweitert wurde. Von dieser zweiten
Form gibt es zudem noch eine Variante, in welcher der Akzent mehr auf RessourcenNutzung als der Vernetzung zwischen den einzelnen „Peers“ liegt.
2.1.1. Reines P2P
In einem reinen P2P-Netzwerk gibt es keine zentrale Stelle, alle Netzteilnehmer sind
gleichgestellt (siehe Abbildung 3). Jeder Knoten verwaltet sich selbst, und alle
Knoten zusammengefasst bilden das Netzwerk und dessen Administration. Jeder
Knoten ist Server und Client zugleich („Servent“). Die Anwendungen, die diese
Servents realisieren, werden im Allgemeinen als Clients bezeichnet, auch wenn
diese Bezeichnung unzureichend ist. Da der Begriff „Servent“ in der Praxis eher
ungebräuchlich ist, werde ich im Weiteren nur noch die Bezeichnung „Client“
verwenden. Ein Client solch eines P2P-Netzwerks loggt sich in das Netz
folgendermaßen ein: er verbindet sich zu anderen Clients im Netzwerk und teilt ihnen
mit, dass er im Netz ist. Die anderen Hosts kommunizieren dem Knoten, mit welchen
anderen Clients („user“) sie verbunden sind und übermitteln gleichzeitig diesen den
aktiven Status des neu teilnehmenden Nutzers. Es wird also immer eine Antwort
zurück- und eine Nachricht weitergesendet. Dieser Prozess geht bei den anderen
Clients („user“) so weiter, so dass sich in kürzester Zeit Tausende von Hosts
miteinander verbinden können. Es scheint nun, dass die Reichweite solch eines
Netzwerks unendlich sein kann. Wie viele Schichten eine Mitteilung erreichen kann,
wird jedoch durch den „time-to-live“- Wert (TTL) begrenzt. Somit gibt es für jeden
Client eine Begrenzung der „Reichweite“ im Netz, Horizont genannt. Diese
Limitierung verhindert die Entstehung von infiniten Schleifen und ist damit besonders
wichtig für den problemlosen Betrieb des Netzwerkes. Trotz dieser Beschränkung
kann die Ausdehnung des Netzwerks von Teilnehmern, mit denen ein einzelner
Inv-Nr. 2002-09-04/040/IN95/2231
Seite 9
Benutzer verbunden ist, enorme Ausmaße annehmen, und Daten verbreiten sich in
der Praxis dennoch über das gesamte Internet. Schließlich genossen Europäer im
Mittelalter ebenfalls chinesische Gewürze, obwohl sie außer Mythen und Legenden
nichts über China wussten. Alles was nötig war, war das Wissen um einige Plätze im
Nahen Osten, an denen mit China Handel betrieben wurde [2].
Die bekanntesten Beispiele für reines P2P im Internet sind Gnutella und Freenet.
Gnutella wurde ursprünglich von Nullsoft, einer Tochtergesellschaft von AOL,
programmiert. Das Programm war, entgegen der viel verbreiteten Meinung, nicht
Open-Source.
Das
Kommunikationsprotokoll
wurde
nicht
veröffentlicht.
Das
Programm wurde „reverse engineered“, d.h. Entwickler bauten nachträglich ein
Protokoll auf, welches die Eigenschaften von Gnutella erfasste.
Client
Client
Client
Client
Abbildung 3:
Client
Modell eines reinen P2P-Netzes
Gnutella ist ein Protokoll, nicht eine Software. Sie legt fest, wie GnutellaApplikationen miteinander über das Internet via HTTP kommunizieren.
Das Protokoll wurde öffentlich zugänglich gemacht. Es gibt heute über 30
verschiedene entsprechende Applikationen, die gemeinhin als „Clients“ bezeichnet
werden. (z.B. Bearshare, Limewire, Toadnode). Teilweise sind diese Anwendungen
selbst Open-Source-Projekte. Gnutella ist somit das erste große reine P2P-Netzwerk
nach den Anfängen des Internet selbst (Arpanet). Um ein Verständnis für die
Funktionsweise von Gnutella zu schaffen, soll nun kurz das Gnutella-Protokoll erklärt
Inv-Nr. 2002-09-04/040/IN95/2231
Seite 10
werden. Es definiert die Kommunikation zwischen den Clients und erlaubt so einen
Suchmechanismus (distributed search) für das ganze Netzwerk. Die Kommunikation
findet über Mitteilungen (packets), welche durch eine spezielle Beschreibung
(Descriptor) gekennzeichnet (tagged) sind. Die Version 0.4 des Gnutella-Protokolls
definiert 5 Beschreibungen: PING, PONG, QUERY, QUERYHit und PUSH.
Mitteilungen enthalten außerdem den GUID (Global Unique Identifier), um so jeden
Host und jede Mitteilung eindeutig im Netzwerk zu identifizieren. Die Descriptors
geben den kommunizierenden Computern genaue Anweisungen, wie sie auf eine
Mitteilung zu reagieren haben. PING und PONG ermöglichen, wie schon oben
erwähnt, das Anmelden im Netzwerk. Nachfolgend soll der Prozess des Suchens
(QUERY), des Findens (QUERYHit) und des Herunterladens (PUSH) erläutert
werden.
Erster Schritt: Suche
Der eingegebene Suchbegriff wird
nun durch die Mitteilung QUERY an
alle
Netzteilnehmer
versandt.
QUERY durchsucht die von den
Clients
angebotenen
(shared)
Ressourcen. Die Reichweite dieser
Mitteilung
ist
durch
die
TTL
beschränkt.
Zweiter Schritt: Gefunden
Besitzt
nun
ein
durch
angesprochener
QUERY
Computer
den
gesuchten Inhalt, wird er sie mit
einer
QUERYHit
Netzwerk
an
Mitteilung
den
via
Suchenden
beantworten. Sie beinhaltet die IPAdresse
Namen
des
der
Senders
und
die
entsprechenden
Dateien.
Inv-Nr. 2002-09-04/040/IN95/2231
Seite 11
Dritter Schritt: Download
Der
Computer,
welcher
die
gewünschte Datei hat, wird nun, im
Gegensatz zu vorher, über HTTP
direkt angesprochen. Der Download
wird nun vom Suchenden initiiert.
Firewalls
können
aber
eine
Verbindung zwischen den Clients
verhindern.
Evtl. vierter Schritt: Firewall
Falls der suchende Nutzer den
Download aufgrund eines Firewalls
nicht initiieren kann, sendet er eine
PUSH-Mitteilung
an
seine
Gegenpartei, welche nun von sich
aus den Transfer startet.
Die total dezentrale Struktur und der Open-Source-Code des Protokolls verursachen
aber auch gewisse Schwierigkeiten. Da inzwischen weit über 30 verschiedene auf
Gnutella basierende Programme im Umlauf sind, gibt es Kompatibilitätsprobleme.
Der einfache Aufbau des Protokolls ließ es zu, dass eine Menge an verschiedenen
Clients mit unterschiedlichen Zusatzfunktionalitäten entstanden, deren Kompatibilität
untereinander mehrheitlich nicht gegeben ist. Das Gnutella Protokoll selbst ist noch
nicht genügend ausgereift und bedarf einer Weiterentwicklung innerhalb der OpenSource-Community. Des Weiteren ist die Konnektivität ein Problem. Wie jeder
Browser braucht jeder Gnutella Client eine „Startseite“ resp. einen „Starthost“. Die
Tatsache, dass diese Hostadressen nur eine beschränkte Lebensdauer haben und
nicht ständig verfügbar sind erschwert den Verbindungsaufbau zum Netz. Ein
Lösungsansatz hierfür ist das „auto-connect“ Feature, welches in einigen Clients
(z.B. Bearshare oder Limewire) enthalten ist. Bei diesem „auto-connect“ greift der
Client auf Adresslisten zu, die auf zentralen Webservern, wie dss.Clip2.com oder
www.Gnutellahosts.com, gepflegt werden. Diese Zusatzfunktion bricht jedoch mit
Inv-Nr. 2002-09-04/040/IN95/2231
Seite 12
dem Konzept des reinen P2P, da hierbei eine Art zentraler Koordination auf ClientServer- Basis genutzt wird.
Ein weiteres Problem von Gnutella ist die schlechte Skalierbarkeit. Durch die
parallele Weitergabe von eingehenden Requests in allen Knoten verbreiten sich
Anforderungen expotentiell im Netz. Diese Überflutung des Netzes mit Requests
erzeugt eine solch hohe Last auf dem Netzwerk, welches dadurch zum
Zusammenbruch gebracht werden kann. Für dieses Problem haben die GnutellaEntwickler derzeit noch keine Lösung parat [2]. Umgekehrt führt die zu geringe
Bandbreite der Netzzugänge vieler Clients ebenfalls zu Problemen. Über langsame
Modemverbindungen eingebundene Clients bremsen das Netzwerk aus oder
partitionieren es sogar. Dies erschwert die Kommunikation und schmälert erheblich
den Erfolg von Suchanfragen. Ein Lösungsansatz für dieses Problem ordnet die
Clients so um, dass schnelle Sevents mehr in die Mitte des Netzwerks und
langsamere mehr am Rand positionieren werden.
Ein weiteres bekanntes reines P2P-Netzwerk ist Freenet. Es entstand aus einem
Forschungsprojekt, das 1997 von Ian Clarke an der Universität von Edinburgh
begonnen wurde. Es wurde in Java entwickelt und benutzt im Gegensatz zu Gnutella
nicht HTTP als unterliegendes Schichtprotokoll. Hauptsächlich unterscheidet sich
Freenet von Gnutella jedoch durch die Ziele, die bei der Entwicklung im Mittelpunkt
standen und einen sehr sozialpolitischen Charakter haben. So wurde das FreenetProjekt mit folgenden Absichten ins Leben gerufen [2]:
•
anonyme Distribution von Inhalten zu ermöglichen
•
anonymes Abrufen von Inhalten zu ermöglichen
•
die Entfernung von Inhalten nahezu unmöglich zu machen, heißt Zensur
zu verhindern
•
ohne zentrale Kontrolle zu funktionieren
In vieler Hinsicht gleichen die Architektur und Protokoll von Freenet denen von
Gnutella.
Jeder
Teilnehmer
Anforderungen an ein paar
benutzt
eine
Client-Anwendung
und
schickt
benachbarte Clients. Diese werden eindeutig
gekennzeichnet, zu weiteren Clients weitergegeben und gespeichert, um den
Anforderungen entsprechende Daten an den Requester zurückgeben zu können. Der
wesentliche Unterschied zwischen beiden Systemen ist, dass ein Freenet-Client, der
eine Anfrage erfüllt, die Daten zum Requester schicken muss. Dies ist bei Gnutella
Inv-Nr. 2002-09-04/040/IN95/2231
Seite 13
nur eine Option, jedoch nicht zwingend gefordert. Viel wichtiger als das eigentliche
Schicken der Daten ist die Tatsache, dass jeder Client in der Kette, durch die die
Daten gesendet werden, eine Kopie der Daten bei sich ablegt. Diese behält der
Client dann solange, wie andere Netzteilnehmer danach fragen, und löscht sie, wenn
eine gewisse Zeit lang sich niemand mehr dafür interessiert. Obwohl diese
Vorgehensweise auf den ersten Blick sehr ineffizient erscheint, so erfüllt es doch
einige Dinge, die bei der Umsetzung der Ziele von Freenet sehr hilfreich sind.
Mit diesem Vorgehen ermöglicht es Freenet kleinen Anbietern, große, populäre
Inhalte effizient, ohne Probleme mit zu geringer Bandweite oder zu schwachem
Server, zu verbreiten. Es fördert und verbreitet populäre Inhalte, während es
unpopuläre Angebote aus dem Netz verschwinden lässt. Durch diese weite
Distribution populärer Daten scheint es, als bringe Freenet die Daten „näher“ zu
denen, die sie haben wollen. Unter Nähe ist hier die Entfernung der Hosts in InternetHops von einander zu verstehen. Dies ist ein interessanter Punkt bezüglich der
Architektur von Freenet, denn die Popularität der Inhalte von Netzteilnehmern wirkt
sich tatsächlich auf die Topologie des Freenet-Netzes aus. Im Gegensatz zu
Gnutella werden bei Freenet nicht zu befriedigende Requests nicht parallel an alle
benachbarten Hosts, sondern nacheinander an die Nachbar-Hosts weitergegeben,
solange keine positive Antwort folgt. Dieses Vorgehen nennt man „Depth-first“
(Tiefensuche), während die Gnutella-Methode als „Breadth-first“ (Breitensuche)
bezeichnet wird. Nun angenommen, ein Client entdeckt, dass er ständig und schnell
Daten von einem bestimmten Nachbarn bekommt, so wird er diesen für künftige
Requests favorisieren. Die Bandbreite des Netzes verbessert sich somit dort, wo es
dem Endbenutzer zu Gute kommt. Zurückkommend auf das Bild des Handels
zwischen Europa und China im Mittelalter würde dies bedeuten, dass Freenet China
umso näher an Europa heranbringt, desto mehr Europäer mit China handeln wollen
[2].
Ein
weiters
Ergebnis
der
Freenet-Architektur
ist
die
gute
Skalierbarkeit.
Netzüberlastungen durch Request-Überflutung, wie bei Gnutella, sind durch die
verwendete Tiefensuche ausgeschlossen. Auch Versuche, das Netzwerk mit großen
Datenmengen zu überfluten haben nur geringe Auswirkungen. Solange niemand
nach diesen Daten fragt, werden sie sich nicht durch das Netz bewegen.
Inv-Nr. 2002-09-04/040/IN95/2231
Seite 14
Des Weiteren macht es ein System von Schlüsseln und Prüfsummen (Hashes)
unmöglich,
im
Netzwerk
existierende
Inhalte
unter
gleichem
Namen
zu
überschreiben. Jedes Element hat eine eindeutige Kennung. Doch genau diese
einmalige Kennung birgt auch das größte Problem von Freenet in sich. Obwohl für
jedes Element, welches man ins Netzwerk stellt, ein beliebiger String als
Bezeichnung gewählt werden kann, erstellt Freenet aus Sicherheitsgründen sowohl
von diesen Bezeichnungen als auch von Such-Strings Prüfsummen. Wenn also
Bezeichnung und Suchstring sich auch nur in einem Zeichen unterscheiden, bleibt
bei der Suche das Datenelement außen vor. Zum Beispiel würde die Suche nach
Inhalten mit dem Titel „MySong.mp3“ eine Datei mit dem Namen „My-Song.mp3“
ignorieren. Freitext-Suchanfragen bleiben somit erfolglos. Die Lösung dieses
Suchproblems stellt laut Ian Clarke derzeit die wichtigste Aufgabe für die
Entwicklergemeinde von Freenet dar.
2.1.2. Hybrides P2P (koordiniertes)
Napster und ICQ sind wohl die bekanntesten Beispiele für hybride P2P-Netze. Nach
seiner Erfindung löste ICQ eine Welle des Instant Messaging aus, welches heute von
über 120 Millionen Menschen in über 245 Ländern genutzt wird [3]. Mitte 1999 ging
Napster online und hatte vor seiner, durch die Domestizierung durch Bertelsmann
bedingten, Abschaltung über 60 Millionen Nutzer.
Koordinierte P2P-Netzwerke haben im Gegensatz zur reinen P2P-Architektur einen
oder mehrere zentrale Server (siehe Abbildung 4). Dies soll dazu dienen, die Vorteile
von P2P mit denen des Client/Server Modells zu verbinden.
Um Teil eines solchen hybriden P2P-Netzes zu werden, benötigt der User in der
Regel eine Client Applikation. Diese meldet dann den Benutzer bei einem zentralen
Server an, sofern dieser registriert ist. Der zentrale Server administriert alle aktiven
User und deren angebotenen Ressourcen, welche der Server in einem zentralen
Verzeichnis einträgt. Die Suche nach Ressourcen verläuft nun eben über dieses
Verzeichnis der Koordinationsstelle und ermöglicht einen schnelleren Ablauf des
Such- und Vermittlungsprozesses. Bis hierhin entspricht dies im wesentlichen einer
Client/Server Architektur, bei der ein sehr geringes Datenaufkommen vorliegt. Um
hingegen nach der Vermittlung auf gefundene Ressourcen zuzugreifen, verbindet
sich der User dann über reines P2P direkt mit dem vermittelten „peer“. Große
Inv-Nr. 2002-09-04/040/IN95/2231
Seite 15
Datenmengen werden somit nur direkt unter den „peers“ ausgetauscht. Das hohe
Datenaufkommen, mit dem herkömmliche File Server zu kämpfen haben, entfällt
somit bei den zentralen Servern einer hybriden P2P-Architektur.
Client
Client
Client
Server
Client
Client
Client
Abbildung 4:
Hyprides P2P
Damit bringt Koordiniertes Peer-2-Peer dem User höhere Benutzerfreundlichkeit und
verspricht insgesamt eine bessere Vernetzung der Hosts. Was bei der reinen P2PArchitektur zur fast uferlosen Vernetzung tausender Clients führt, wird hier durch
zentrale Server gelöst. Um große Massen von Nutzern effizient zu verwalten, bedarf
es eines Netzwerks von Zentral-Servern, was in einer Partitionierung des Netzwerks
resultiert. Einerseits wird dadurch eine bessere Connectivität erreicht. Andererseits
ist es dem User nicht immer möglich, das gesamte Netzwerk zu durchsuchen, da die
zentralen Server nicht zwingend miteinander kommunizieren und ihre Verzeichnisse
austauschen. Eine Lösung für dieses Problem sind erweiterte Clients, die es dem
Benutzer erlauben, den Server manuell auszuwählen. Dies ermöglicht außerdem die
Bildung von themenspezifischen Servern.
Die Abhängigkeit von zentralen Servern macht Hybride P2P-Netze allerdings leicht
angreifbar. Der Verlust der Server führt zum Verlust des ganzen Netzes, was die
Abschaltung von Napster technisch gesehen sehr einfach machte.
Inv-Nr. 2002-09-04/040/IN95/2231
Seite 16
2.1.3. Cycle Sharing
Dieser Ansatz von Peer-2-Peer Netzwerken wurde von SETI@Home bekannt
gemacht und ist in diesem Bereich bislang das größte und erfolgreichste Projekt.
SETI (Search for Extraterrestrial Intelligence) begann das Projekt im Mai 1999, um
freie Rechenleistung von unzähligen PCs zur Analyse von Radiowellen zu nutzen.
Seither haben über 2.6 Millionen Freiwillige über 500 000 Jahre Rechenleistung
beigetragen.
Da diese Form des P2P jedoch für diese Arbeit nicht relevant ist, möchte ich nicht
näher darauf eingehen.
2.2. P2P-Geschäftsmodelle
Einfach gesagt, beschreibt ein Geschäftsmodell die Art und Weise, wie eine Firma
Geschäfte und damit möglichst Gewinne macht. Einige Modelle sind recht einfach:
eine Firma produziert Waren oder bietet Dienstleistungen an, und verkauft diese dem
Kunden.
Andere
Geschäftsmodelle,
wie
zum
Beispiel
Fernseh-
oder
Radioübertragung, sind etwas komplexer.
Das Internet ermöglicht viele neue Geschäftsmodelle, sowie viele Wiedererfindungen
von bestehenden Modellen. Ein bekanntes Beispiel hierfür sind Auktionen. Eines der
ältesten Geschäftmodelle der Welt wurde durch Firmen wie eBay aufgegriffen und
entwickelte sich zu einem der erfolgreichsten Modelle im Internet.
Gemein ist all diesen Business-Modellen im Internet, dass sie versuchen, die
besonderen Gegebenheiten des Mediums Internet zu ihrem Vorteil zu nutzen. Die
Vernetzung von Millionen von Benutzern auf der ganzen Welt brachte bereits eine
Fülle von Ideen, um damit Geld zu verdienen, hervor. Mit jeder Innovation, die diese
globale Vernetzung vorantreibt, werden sich neue Ideen und Geschäftsmodelle
ergeben.
Für P2P-Netze sind vor allem Geschäftsmodelle interessant, bei denen die direkte
Kommunikation der Benutzer von Bedeutung ist, und vom Betreiber motiviert wird.
Diese Motivation passiert meist durch einen materiellen Anreiz für den Benutzer, zum
Beispiel durch Provisionen oder Rabatte. Im folgenden werden einige Modelle
erläutert, die entsprechende Ansätze enthalten.
Inv-Nr. 2002-09-04/040/IN95/2231
Seite 17
2.2.1. Bannerwerbung
Bannerwerbung ist eine der am meisten verbreiteten Varianten, Besucher auf die
Webseiten des Werbenden zu bringen. Werbebanner werden meist auf anderen
Websites geschaltet (siehe Abbildung 5). Neuere Entwicklungen bieten auch
Programme zum Download an, die Werbebanner direkt auf den Bildschirm des
Benutzers bringen. Dies dient dazu, nicht nur Betreibern von Webseiten, sondern
auch dem Endbenutzer und eigentlichen Werbekonsumenten zu ermöglichen, an der
geschalteten Werbung zu verdienen. Viele Anbieter von kostenlosen Diensten im
Internet finanzieren sich über die Einblendung von Werbebannern.
Abbildung 5:
Webseite mit Bannerwerbung
Die Schaltung von Werbebannern wird in der Regel entweder nach sogenannten AdImpressions, der Anzahl der vom Server ausgelieferten Banner, oder nach Ad-Clicks,
der Anzahl der tatsächlich erfolgten Klicks auf das Banner, abgerechnet. Bei der
Verrechnung nach Ad-Impressions wird meistens der Begriff des TKP, des
Tausender-Kontakt-Preises, des Preises für 1000 Ad-Impressions verwendet. Bietet
eine
Seite
die
Verrechnung
nach
Ad-Clicks
an,
wird
meist
von
einer
durchschnittlichen Click-Rate zwischen 0,5 und 3 Prozent der Ad-Impressions
ausgegangen und der Preis für einen Click dementsprechend hoch angesetzt. Die
Inv-Nr. 2002-09-04/040/IN95/2231
Seite 18
Entscheidung, das Risiko einer geringen Click-Rate durch Buchung nach TKP selbst
zu tragen, oder dieses durch Wahl der vielleicht überteuerten Ad-Click Verrechnung
auf den Anbieter abzuwälzen, bleibt dem Werbenden überlassen.
2.2.2. Affiliate Marketing
Die Idee des Affiliate Marketings entstand während eines Gesprächs zwischen einer
jungen Frau und Amazon Gründer Jeff Bezos. Die junge Frau hatte eine Website
zum Thema Scheidung erstellt und fragte Bezos, ob sie nicht gegen eine
Verkaufsprovision Bücher zu diesem Thema auf ihrer Website anbieten könne. Die
Idee des Affiliate Programms war geboren und ist heute eine der entscheidenden
Säulen für Amazons Bekanntheit und Erfolg. Heute verkauft Amazon seine Bücher
und CDs auf über 500.000 Partner-Websites weltweit.
Jedoch ist das Affiliate Marketing im Grunde keine revolutionäre Idee, sondern
vielmehr die Rückbesinnung auf die bewährten Vertriebskanäle des Offline-Business.
Produkte und Dienstleistungen werden näher zum Kunden gebracht, sind für den
Kunden besser und schneller erreichbar und können unmittelbar an die spezifischen
Interessen und Bedürfnisse bestimmter Zielgruppen angepasst werden [4].
Affiliateprogramme beruhen auf der Basis der erfolgreichen Empfehlung. Die
Werbepartner empfehlen ein bestimmtes Produkt oder einen Anbieter und erhalten
dafür eine Provision.
Im Internet hat sich das Affiliate Marketing zum Online-Geschäftsmodell schlechthin
etabliert. Mit niedrigen Kundenakquisitionskosten für die Betreiber hat es sich in allen
Bereichen des B2C und B2B im E-Commerce durchgesetzt. Mehr als 20% des
Online-Umsatzes werden über Partner-Websites generiert. Affiliate-Programme
bieten für E-Business Unternehmen die Möglichkeit, virtuelle Filialnetze aufzubauen
[5].
Inv-Nr. 2002-09-04/040/IN95/2231
Seite 19
Partner-Sites
Kunden
Kunden
Anbieter
Kunden
Abbildung 6:
Affiliate-Netzwerk
Wesentlich für den Erfolg der Affiliate-Programme ist die Tatsache, dass
Empfehlungen
durch
andere
weit
glaubwürdiger
auf
Kunden
wirken
als
Eigenwerbung, zum Beispiel durch Bannerwerbung. Doch welche Möglichkeiten
bieten Affiliate-Programme für die Werbepartner? Wie bereits erwähnt erhält der
Partner für seine Funktion als Werbender eine Provision. Hierfür gibt es mehrere
Möglichkeiten der Berechnung, die häufigsten sind folgende:
•
Erfolgreiche Empfehlung: Das heißt der Kunde hat den Link angeklickt
und das beworbene Angebot besucht. Dann bekommt der Werbepartner
für jeden Click auf den entsprechenden Werbelink einen Betrag
gutgeschrieben.
•
Abschluss eines Kaufs: Dies bedeutet, dass der Kunde das Angebot
besucht und etwas daraus gekauft hat. In diesem Abrechnungsmodell
erhält der Partner dann eine Provision in Höhe eines bestimmten
Prozentsatzes vom Betrag des Kaufes.
Ein Reiseportal im Internet wäre zum Beispiel ein idealer Werbepartner für einen
Hersteller von Reisegepäck. Der Reiseanbieter könnte bei jeder abgeschlossenen
Reisebuchung ein Werbebanner für ein Kofferset des Gepäck-Herstellers in die
Buchungsbestätigung einbinden. Der Betreiber des Reiseportals erhielte nun
entweder eine Provision für jeden Kunden, der sich das Angebot des Gepäck-
Inv-Nr. 2002-09-04/040/IN95/2231
Seite 20
Herstellers angesehen hat oder für jeden Koffer, der von einem geworbenen Kunden
gekauft wurde.
Provisionen werden oft nur oberhalb eines Minimums oder nicht in Form von Geld
ausgezahlt. So vergeben viele Firmen ihre Provisionen nur in Form von Gutschriften
oder anderen virtuellen Währungen.
2.2.3. Struktur-Marketing
Das Struktur-Marketing, auch bekannt als Multi-Level-Marketing (MLM), Network
Marketing oder Strukturvertrieb, ist eine Form des Direktvertriebs, die sich unter
anderem aus dem Versandhandel entwickelt hat. Beim klassischen Direktvertrieb ist
das Ziel, Waren oder Dienstleistungen ohne Zwischenhändler, eben direkt, an
Endkunden zu verkaufen. MLM führt dieses Prinzip weiter, und versucht die
Endkunden als Wiederverkäufer zu gewinnen. Damit konsumiert der Kunde die
gekauften Produkte nicht nur, sondern verkauft sie weiter (siehe Abbildung 7). Somit
wird der Kunde selbst ein Teil der Vertriebsstruktur. Um die Teilnahme an dieser
Vertriebsstruktur für den Kunden attraktiv zu machen, erhält ein Kunde für jeden
verkauften Artikel eine Provision, und zwar nicht nur für selbst erzielte Verkäufe,
sondern auch für die Verkäufe derer, die er zunächst wiederum geworben hat.
Daraus ergibt sich eine pyramidenförmige Vertriebsstruktur.
Inv-Nr. 2002-09-04/040/IN95/2231
Seite 21
Partner
Kunden
Kunden
Anbieter
Kunden
Kunden
Kunden
Abbildung 7:
Strukturvertrieb
Strukturvertrieb gibt es seit den 40er Jahren. California Vitamins, ein Direktverkaufsunternehmen, ermöglichte erstmals seinen Mitarbeitern, andere Menschen als
Vertriebspartner anzuwerben und somit auch an deren Provisionen teilzuhaben. Neu
an diesem Geschäft war die Art und Weise der Vergütung der Mitarbeiter. Heute
bekannte Beispiele aus der Wirtschaft sind „AVON“, „Tupper Ware“ oder „Amway“.
Im Internet existieren MLM-Geschäftsmodelle bislang vor allem als Weiterführung
von Banner- oder Affiliate-Programmen. Bei diesen werden dann die Werbepartner
nicht nur für die selbst vermittelten Umsätze entlohnt, sondern auch an denen
beteiligt, die von weiteren geworbenen Partnern vermittelt wurden.
Inv-Nr. 2002-09-04/040/IN95/2231
Seite 22
2.2.4. Punkte- und Rabattsystme
Viele Unternehmen versuchen, ihre Kunden durch die Vergabe von Rabattpunkten
für
zukünftige
Einkäufe
zu
binden.
Durch
Drittanbieter
werden
unternehmensübergreifende Netze gebildet, die Kunden an die angeschlossenen
Shops binden sollen. Bei diesem Modell sind dann die erworbenen Rabattpunkte in
allen Shops gültig, die Teil des Netzes sind. Bei jedem weiteren Einkauf werden
weitere Rabattpunkte gesammelt. Ein Beispiel hierfür ist Webmiles, zu dessen ShopNetz Firmen wie Quelle, bol.de oder Vobis gehören.
Einen anderen Weg beschreitet letsbuyit.com. Bei diesem Anbieter ergibt sich ein
Rabatt für Warenkäufe durch die Anzahl der Verbraucher, die den selben Artikel
kaufen wollen. Je größer die Anzahl der Käufer, desto höher ist der gewährte Rabatt.
Inv-Nr. 2002-09-04/040/IN95/2231
3. Lösungsansätze für das Potato-System
Seite 23
Das unter dem Namen „Potato-System“ (PS) zu entwickelnde System soll es
ermöglichen, die Struktur eines P2P-Netzes zum Vertrieb von digitalen Inhalten zu
nutzen.
Im
Gegensatz
zu
bisherigen
P2P-Ansätzen
zum
Austausch
von
multimedialen Daten soll das PS nicht dazu dienen, die illegale Verbreitung von
Raubkopien im Internet zu fördern. Vielmehr ist es das Ziel, eine Lösung zu finden,
die es Autoren, Komponisten etc. ermöglicht, ihre Waren effizient und vor allem
profitabel mittels eines P2P-Netzwerkes zu vertreiben.
Ich gehe davon aus, dass der PC als offenes System bestehen bleibt. Unter offenen
Systemen
versteht
man
in
diesem
Zusammenhang
Systeme,
die
aus
herstellerunabhängigen, allgemein verfügbaren Hard- und Softwarekomponenten
bestehen. Dabei dienen Standardisierung und offene Spezifikation den Zielen
Interoperabilität und Portabilität [11]. Der PC kann also nach Belieben des Nutzers
durch Hard- und Softwarekomponenten in seiner Funktionalität erweitert und
verändert werden.
Unter dieser Vorraussetzung werden Digital Rights Management (DRM) Systeme
auch in Zukunft keinen zureichenden Schutz vor unlegitimer Verwendung und
Weiterverbreitung von Software oder Multimedia bieten. Wenn man den Nutzer nun
nicht zwingen kann, Urheberrechte einzuhalten und für konsumierte Ware zu zahlen,
muss man Möglichkeiten finden, den Nutzer zu motivieren, dies aus eigenem
Interesse zu tun. Beim Potato-System steht die Idee im Mittelpunkt, die Nutzer zu
Vertriebspartnern zu machen. Damit verlieren diese die Rolle des Feindes der
Content Provider und werden Verbündete im Vertrieb der digitalen Inhalte. Um den
Nutzer für diese „Vertriebstätigkeit“ zu motivieren, erhält er eine Provision. Genauer:
Ein Nutzer, der für ein Multimediaprodukt oder eine Software bezahlt hat, erhält jedes
Mal eine Vermittlungsprovision, wenn das von ihm weiterverbreitete Produkt von
einem der Empfänger bezahlt wird. Zahlt dieser keinen Kaufpreis, erhält der Sender
keine Provision. Allerdings kann dann der Empfänger seinerseits auch niemals eine
Vermittlungsgebühr erhalten, denn jeder Bezahlvorgang wird quittiert.
Diese Art des Vertriebes entspricht dem Prinzip des oben beschriebenen Multi-LevelMarketing: Der Content Provider sendet sein Produkt an eine Reihe von Nutzern, die
dies dann kaufen und gegen eine Provision an weitere Nutzer weiterverkaufen.
Inv-Nr. 2002-09-04/040/IN95/2231
Seite 24
3.1. Dezentraler Lösungsansatz mit reinem P2P
Der erste Ansatz zur Umsetzung dieses Vertriebssystems zielt auf eine vollkommen
dezentralisierte Lösung ab. Betrachtet man die baumartige Struktur des MLM, so
erscheint ein reines P2P-Netzwerk (2.1.1) als gut geeignetes Netz, um ein MLM-Netz
darin einzubetten. So stellt sich ein reines P2P-Netz vom Blickpunkt eines einzelnen
Benutzers aus ebenfalls als Baum dar, bei dem der Betrachtende die Wurzel ist.
(siehe Abbildung 2). Der Vertrieb der virtuellen Waren würde somit von der Wurzel
aus, sprich dem Content Provider, über seine benachbarten Knoten weiter durch das
ganze Netz erfolgen (siehe Abbildung 8).
Client
Client
Client
Client
Client
Client
Client
Client
Client
Client
Client
Client
Client
Client
Client
Client
Client
Client
Client
Client
Client
Abbildung 8:
Client
Einbettung eines Baumes in ein P2P-Netzwerk
Des Weiteren hat die Betrachtung von Freenet ergeben, dass sich reine P2P-Netze
bestens zur Superdistribution eignen. Superdistribution ist eine Art des Vertriebes,
bei der digitale Inhalte ohne Einschränkungen frei verfügbar, jedoch vor
Modifikationen und vom Besitzer unerwünschten Verwendungen geschützt sind [6].
Superdistribution ermöglicht somit die uneingeschränkte Verbreitung von digitalen
Inhalten im Netzwerk und fördert damit den bereits beschriebenen Effekt, dass sich
Inhalte umso schneller im Netz verbreiten, je populärer sie sind. Dies ist ein
wesentliches Ziel des zu entwerfenden Systems.
Inv-Nr. 2002-09-04/040/IN95/2231
Seite 25
Neben diesen wesentlichen Eigenschaften bringt die Struktur eines reinen P2PNetzwerkes andere Vor- und Nachteile mit sich, die es in diesem speziellen
Anwendungsfall genau zu prüfen und zu bewerten gilt.
Ruft man sich den Fall Napster in Erinnerung und betrachtet dagegen Gnutella oder
Freenet, so bietet die dezentrale Struktur vor allem den Vorteil, dass es schwer
angreifbar ist. Es existieren keine zentralen Knoten, bei deren Sabotage oder
erzwungener Abschaltung das Netzwerk zerstört würde. Da das zu entwerfende
System jedoch das Ziel hat, die Benutzer zum Einhalten der Urheberrechte zu
motivieren und damit aller Voraussicht nach nicht mit dem Gesetz in Konflikt geraten
wird, beschränkt sich dieser Vorteil auf Sabotage und sollte nicht überbewertet
werden. Der Großteil des heutigen Internet beruht auf der zentralisierten
Client/Server-Struktur, deren Server mit diesem Problem zu kämpfen haben.
Ein tatsächlich großer Vorteil des dezentralisierten Lösungsansatzes ist die gute
Skalierbarkeit. Eine schnell wachsende Teilnehmerzahl hätte keine negativen Folgen
für die Verfügbarkeit von Daten, wie dies bei zentralisierten Client/Server-Systemen
der Fall ist. Im Gegenteil; je mehr Teilnehmer ein entsprechendes Netz hat, desto
schneller erfolgt die Verbreitung gefragter Inhalte und damit deren Verfügbarkeit im
Netz.
Neben diesen Vorteilen birgt ein ausschließlich dezentraler Ansatz einen großen
Nachteil für das hier zu entwerfende System. Das bei Gnutella als ineffizient
erscheinende Durchreichen der gewünschten Daten vom Responder zum Requester
durch alle Zwischenknoten beschränkt sich in diesem Fall nicht nur auf Daten. Die
zentrale Idee, dem Nutzer für seine Distribution Provisionen zu zahlen, würde bei
jedem getätigten Kauf erfordern, dass die bezahlte Summe entlang der gesamten
Distributionskette bis zum Content Provider durchgereicht wird. Dabei behält sich
jedes Glied in dieser Kette eine Provision ein und reicht nur den Restbetrag weiter
zurück, wie Abbildung 9 zeigt.
Inv-Nr. 2002-09-04/040/IN95/2231
Abbildung 9:
Seite 26
Waren- und Geldfluss bei dezentralem Lösungsansatz
Dieses Vorgehen setzt voraus, dass die gesamte Vertriebsgeschichte des Produktes
in irgendeiner Form an das Produkt selbst angehängt werden muss, um den Weg für
die Bezahlung zu beschreiben. Auch das eigentliche Weiterreichen der Bezahlung
dürfte sich in dieser Form nur sehr schwer realisieren lassen. Da ein Content
Provider für seine Ware natürlich eine reelle Währung verlangen wird, um seine
Produktionskosten zu decken, müsste somit auch Geld durch das Netz fließen. Es ist
wohl kaum praktikabel, wenn das Geld entlang der Vertriebskette von Nutzer zu
Nutzer bis zum Content Provider beispielsweise durch Überweisungen gelangt.
Abgesehen von einem sehr hohen Aufwand, den Geldfluss zu realisieren, würde
dieses Verfahren eine Reihe von Angriffspunkten beinhalten. So bedürfte es eines
aufwendigen Protokolls, um dem Provider zu ermöglichen, nachzuvollziehen, wie oft
sein Produkt von einem Vertriebspartner an weitere Nutzer verkauft wurde. Diese
Kontrolle ist aber zwingend erforderlich, um den Missbrauch zum Betrug
auszuschließen. Sonst könnten Vertriebspartner nicht nur ihre Provisionen, sondern
auch den eigentlichen Preis der Ware für sich einstreichen, ohne dass der Provider
oder die übergeordneten Vertriebspartner jemals etwas davon merken würden. Die
P2P-Clientsoftware müsste entsprechend eines solchen Protokolls realisiert werden.
Eine Information an die Vertriebspartner oder Provider, sprich deren Clientsoftware,
über jede getätigte Transaktion wäre nötig. Provider und Vertriebspartner könnten
daraufhin ihre Zahlungseingänge anhand dieser Informationen überprüfen. Da eine
Überprüfung jedoch noch nicht das Geld bringt, wäre es weiterhin erforderlich, dass
sich jeder Vertriebspartner gegenüber dem Provider oder dem über ihm liegenden
Inv-Nr. 2002-09-04/040/IN95/2231
Seite 27
Vertriebspartner eindeutig identifiziert. Dies wäre prinzipiell durch digitale Signaturen
möglich, was jedoch einen höheren Aufwand für die Nutzer darstellt und somit nicht
in ihrem Interesse sein kann. Des Weiteren käme auf Provider und Vertriebspartner
ein hoher Verwaltungsaufwand zu, um den Geldfluss abzuwickeln. Der größte
Schwachpunkt dieser Idee ist jedoch die Clientsoftware. Mit dem Mechanismus der
Benachrichtigung des Providers über getätigte Transaktionen übergibt man wie bei
herkömmlichen Kopierschutzsystemen die Kontrollinstanz auf das Endgerät des
Nutzers und lädt diesen geradezu zum Missbrauch ein. Da das Protokoll offen gelegt
werden soll, wäre zu erwarten, dass sehr bald Clients entstehen würden, die die
Rückmeldung von Transaktionen „vergessen“ und somit den Nutzer zu größerem
Gewinn verhelfen. Dies hätte den Zusammenbruch des gewünschten Geldflusses
und damit des ganzen Systems zur Folge.
Eine praktikable Lösung wäre, wenn ein Käufer den Preis für das Produkt direkt an
den Hersteller bezahlt, und dieser dann anhand der Vertriebsgeschichte des
Produkts Provisionen an die Nutzer in der Vertriebskette auszahlt.
Abbildung 10: Waren- und Geldfluss bei dezentralem Lösungsansatz mit zentraler
Provisionsauszahlung
Bei diesem Vorgehen übernimmt der Content Provider jedoch eine zentrale Rolle.
Somit ist der Ansatz nicht mehr dezentral.
Inv-Nr. 2002-09-04/040/IN95/2231
Seite 28
3.2. Praktikabler Lösungsansatz mit koordiniertem P2P
Bei näherer Betrachtung dieser zentralen Funktion eines Providers stellt man fest,
dass darin ein nicht zu unterschätzender Verwaltungsaufwand liegt. So ist es
durchaus wahrscheinlich, dass ein Provider nicht jede Provision einzeln auszahlt,
sondern diese wegen ihrer teilweise sehr niedrigen Beträge bis zu einem
Mindestauszahlungsbetrag anspart. Dies bedeutet aber, dass jeder Anbieter von
Inhalten Daten seiner Kunden und Vertriebspartner, sowie deren Kontoinformationen
speichern müsste. Es ist weiterhin anzunehmen, dass ein Nutzer von mehr als einem
Anbieter virtuelle Ware konsumiert und weiterverkauft. Als Folge müsste sich ein
Nutzer bei unzähligen Anbietern anmelden, seine Daten hinterlassen und hätte
ebenso viele Konten.
Spätestens hier drängt sich der Gedanke an eine zentrale Instanz auf, die sowohl
Anbieter als auch Vertriebspartner sowie deren Transaktionen an zentraler Stelle
verwaltet (siehe Abbildung 11). Diese zentrale Instanz soll im Folgenden als
Accounting Server (AS) bezeichnet werden.
Abbildung 11: Waren- und Geldfluss mit zentraler Instanz
Die Eigenschaften des dezentralen Ansatzes unter Verwendung eines reinen P2PNetzwerkes werden mit einer zentralen, koordinierenden Instanz verknüpft. Man
erhält also ein koordiniertes oder hybrides P2P-Netzwerk, wie unter 2.1.2
beschrieben.
Inv-Nr. 2002-09-04/040/IN95/2231
Seite 29
3.2.1. Einführung der beteiligten Personen
Um die prinzipielle Funktionsweise des Potato-Systems besser beschreiben zu
können, stelle ich nun einige Personen vor, die mit dem System interagieren. Zur
Darstellung dieser Personen dienen gemischte Stereotype. Diese bestehen aus
einem Namen und einem zugehörigen Bild. Ein Stereotyp kann beliebige
Eigenschaften eines Objektes repräsentieren [7]. So werden die Personen, die mit
dem System interagieren greifbarer und die Beschreibung des Systems gelingt
anschaulicher.
3.2.1.1 Provider (Fred)
Da das System der Distribution von multimedialen Produkten und Software dienen
soll, stellt der Produzent solcher Ware die erste beteiligte Person dar. Diese soll im
Folgenden als Provider oder Anbieter bezeichnet werden. Ein Provider kann eine
reale Person, also zum Beispiel ein Autor eines Textes oder ein Komponist eines
Musikfiles, sein. Ebenfalls möglich wäre, dass ein Provider für eine Rechtsperson,
also zum Beispiel eine Firma, steht. So wäre denkbar, dass eine Managementfirma
mehrere Künstler betreut und deren Arbeiten über das Potato-System vertreibt.
Wesentlich für den Provider ist, dass er tatsächlich die Rechte an den von ihm
vertriebenen
Waren
zurückzuverfolgen
besitzt.
können
Um
sollte
eventuellen
ein
Provider
Missbrauch
als
reale
feststellen
Person
und
eindeutig
identifizierbar sein. Für den Provider wird im Weiteren der Stereotyp „Fred“
verwendet.
Inv-Nr. 2002-09-04/040/IN95/2231
Seite 30
3.2.1.2 Konsument (Draco)
Neben den Anbietern von virtuellen Waren, den Providern, sind natürlich die Nutzer
für das System von Bedeutung, die die angebotene Ware konsumieren. Eine weitere
Person ist also der Konsument. Konsumenten bleiben dem System unbekannt und
zeichnen sich ausschließlich durch den Konsum, zum Beispiel das Hören von MP3s,
von multimedialen Produkten oder Software aus. Der Stereotyp Draco dient der
Veranschaulichung des Konsumenten.
3.2.1.3 Käufer (Harry)
Entschließt sich ein Konsument dazu, für die konsumierte Ware zu zahlen, so wird er
zum Käufer. Ein Käufer muss dem System bekannt sein, um einen Kauf
abzuwickeln. Der Käufer wird im Weiteren durch den Stereotyp Harry dargestellt.
Inv-Nr. 2002-09-04/040/IN95/2231
Seite 31
3.2.1.4 Wiederverkäufer (Ginny)
Sowohl reine Konsumenten als auch solche, die durch den Kauf einer virtuellen
Ware zu Käufern geworden sind, haben die Möglichkeit erhaltene Waren
weiterzugeben. Ein Wiederverkäufer oder Vertriebspartner zeichnet sich jedoch
dadurch aus, dass er gekaufte Produkte an andere weiterverkauft. Also kann nur ein
Käufer zum Wiederverkäufer werden. Der Wiederverkäufer wird mit dem Stereotyp
Ginny dargestellt.
3.2.1.5 Betreiber des Accounting Servers (Bill)
Der zentrale Akteur des Systems ist der Betreiber des AS, er verwaltet alle Daten die
für das PS relevant sind. Des Weiteren führt er die „Potato-Konten“ der
angemeldeten Provider und Wiederverkäufer. Als Stereotyp dient Bill.
3.2.2. Beschreibung des prinzipiellen Ablaufes
Nehmen wir an, Fred hat eine virtuelle Ware, ein Musikstück, produziert. Dieses
Musikstück liegt als Datei mit dem Namen MYSONG.MP3 vor und Fred möchte diese
Datei kommerziell über das PS vertreiben. Voraussetzung dafür ist zunächst, dass
Fred tatsächlich die Urheberrechte an der Datei besitzt. Um das Risiko des
Missbrauches an dieser Stelle zu minimieren muss sich Fred zunächst bei Bill
registrieren. Dabei muss Fred gegenüber Bill einige Angaben machen, die es
erlauben, dass Fred von Bill eindeutig als Person identifiziert werden kann. Für
diesen Zweck wäre unter anderem eine Digitale Signatur von Fred sinnvoll. Fall sich
später herausstellt, dass durch den Vertrieb der Datei MYSONG.MP3 Urheberrechte
Inv-Nr. 2002-09-04/040/IN95/2231
Seite 32
verletzt wurden, kann Bill aufgrund seiner Daten eindeutig feststellen, das Fred
diesen Missbrauch zu verantworten hat.
Der Ablauf des Vertriebs einer virtuellen Ware über das System soll durch Abbildung
12 veranschaulicht werden. Die Pfeile symbolisieren den Fluss von Ware,
Informationen und Geld. Die Nummerierung dieser Pfeile zeigen die zeitliche Abfolge
der im Folgenden beschriebenen Vorgänge.
Ist Fred nun bei Bill registriert, so kann er seine Datei bei Bill zum Vertrieb anmelden.
(1) Dabei ist wichtig, dass die Datei eindeutig als Freds Datei zu identifizieren ist.
Außerdem kann Fred noch weitere Angaben zur Datei beim AS von Bill hinterlassen.
Solche Angaben wären zum Beispiel eine Beschreibung, ein Preismodell für den
Vertrieb und natürlich die Information, wo die Datei zu finden ist. Denn es ist nicht
zwingend vorgesehen, dass eine Kopie der Datei bei Bill hinterlegt wird. Das
Preismodell enthält den Preis selbst und Daten die zur Berechnung der Provisionen
benötigt werden. Für die Anmeldung der Datei erhält Fred natürlich einen Beleg in
elektronischer Form (2). Dieser Beleg, bzw. ein Verweis darauf muss mit der Datei
verknüpft werden.
Fred kann die mit dem elektronischen Beleg versehene Datei nun auf beliebige
Weise, zum Beispiel per Email, über P2P-Tauschbörsen oder zum Download auf
einer Webseite verteilen (3). Sollte Fred nicht über die technischen Möglichkeiten
verfügen seine Waren selbst zu verteilen, wäre es durchaus sinnvoll weitere Dienste
anzubieten. So könnte man die Dateien auf einem separaten Server zum Download
anbieten, oder Fred auf dem Server Speicher zu Verfügung stellen, über den er frei
verfügen kann. Dort kann Fred dann sein Angebot selbst verwalten.
Erhält nun Ginny die Datei, so kann sie zunächst den Song anhören und die von
Fred bei Bill hinterlassenen Informationen über die Datei einsehen. Sie kann den
Song jedoch auch kaufen. Dazu muss sich Ginny sich zunächst ebenfalls bei Bill
registrieren. Jedoch sind dabei nicht so viele Angaben nötig wie bei Fred. Sie muss
sich auch nicht mit einer Digitalen Signatur identifizieren. Ihre Email Adresse reicht
aus. Im nächsten Schritt kann Ginny von Bills AS weitere Informationen, wie Preis,
Preismodell und eventuell die Vertriebsstufe, erfragen. Bei Gefallen kann er die Datei
mit einem Online-Payment-System bezahlen (4). Den bezahlten Betrag erhält Fred,
abzüglich der Gebühren, die Bill erhebt, auf seinem Account gutgeschrieben (5).
Ginny wiederum erhält für den getätigten Kauf ebenfalls einen elektronischen Beleg,
Inv-Nr. 2002-09-04/040/IN95/2231
Seite 33
der nun mit der Datei verknüpft wird (6). Sie kann nun die Datei mit ihrem Beleg
weiterverbreiten.
Konten
Fred
Ginny
Harry
10
9
5
A
Dateiinformationen
Bill
S
2
6
11
1
Beleg
4
3
Quittung
Content
7
Quittung
Content
Quittung
Beleg
Fred
8
Ginny
Harry
Abbildung 12: Prinzipieller Ablauf beim Potato-System
Harry erhält nun die mit Ginny’s Beleg versehene Datei (7) und entschließt sich, es
Ginny gleich zu tun und den Song zu kaufen (8). Von dem von Harry bezahlten
Betrag erhält nun Ginny einen Teil auf ihrem Account bei Bill gutgeschrieben (9), den
Rest bekommt Fred (10). Harry erhält wiederum einen elektronischen Beleg für
seinen Kauf, der mit der Datei verknüpft wird (11).
Inv-Nr. 2002-09-04/040/IN95/2231
Seite 34
3.2.3. Erweiterung um eine Virtuelle Community
Wie bereits beschrieben, erfolgt die Verteilung der Dateien primär unabhängig vom
Potato-System. Dies bedeutet, dass das PS über kein eigenes technisches P2PNetzwerk verfügt. Vielmehr ergibt sich aus der Struktur des Vertriebes mit dem AS
als zentrale Instanz ein „logisches“ P2P Netzwerk aus den Nutzern des PS. Bei
diesem Netzwerk sind die Nutzer die Knoten. Die Verbindungen zwischen den
Knoten entstehen durch ihre Kauf-/Verkaufsbeziehungen. Im Allgemeinen können
Verbindungen durch alle möglichen Beziehungen zwischen Personen repräsentiert
werden. Mit solchen logischen P2P Netzwerken beschäftigen sich aktuelle
Forschungen. So versuchen Soziologen derzeit die gesamte Menschheit als Modell
für den Nachrichtenfluss in einem P2P Netzwerk zu benutzen [13]. Dieses Projekt
basiert teilweise auf Forschungsergebnissen aus den sechziger Jahren [14]. Damals
wurde ermittelt, dass Botschaften an wildfremde Empfänger über durchschnittlich
sechs Stationen des „menschlichen Netzwerkes“ ihr Ziel erreichen. Während das
Experiment in den sechziger Jahren auf das Gebiet der USA begrenzt war, wird das
aktuelle Projekt global durchgeführt. Die Forscher erhoffen sich unter Anderem die
gewonnenen Erkenntnisse auch auf technische Netzwerke übertragen zu können.
Mögliche Anwendungen wären die Vorhersage von Netzauslastungen oder die
Verbesserung von Suchstrategien in Netzen.
Eine Form von logischen Netzen sind somit auch virtuelle Communities. Unter
Community, oder auf deutsch Gemeinschaft, versteht man eine Gruppe von
Personen mit gemeinsamen Interessen und Bedürfnissen [12]. Gemeinschaften
bilden sich vielfach in der realen Welt; zum Beispiel gibt es unzählige Vereine oder
denke man einfach an eine Stammtischrunde. Auch in realen Multi-Level-MarktingNetzen bilden sich solche Interessengemeinschaften. Deren Mitglieder treffen sich
bei Informations- und Verkaufsveranstaltungen um zum Beispiel Erfahrungen mit
Produkten auszutauschen oder diese auszuprobieren.
Bei einer virtuellen Community wird das reale Treffen durch die Interaktion und
Kommunikation über Onlinedienste (in der Regel dem Internet) ersetzt. Zur
technischen
Realisierung
der
Kommunikation
werden
Hilfsmittel
wie
Diskussionsforen, Chaträume, Newsletter, Mailinglisten und Email benutzt.
Wie in der realen dreht sich auch in der virtuellen Welt viel um die Anerkennung
innerhalb einer Gruppe. Dies ist zum Beispiel in Diskussionsforen zu beobachten.
Inv-Nr. 2002-09-04/040/IN95/2231
Seite 35
Nutzer, die einen besonders hohen Kenntnisstand durch entsprechende Beiträge
nachgewiesen haben, genießen innerhalb des Forums weitaus mehr dieser
Anerkennung als so genannte Newbies (Neulinge). Diese wiederum versuchen ihren
Kenntnisstand auszubauen, um ihn dann im Forum präsentieren zu können. Durch
diesen stetigen Zuwachs an Know How gewinnt das Forum an „Wert“, wird
interessanter und gewinnt an Popularität. In anderen Communities dreht sich alles
um erreichte Punktzahlen bei Computerspielen oder um seltene Sammlerstücke.
Dieser Vorgang wird oft als Community Effekt bezeichnet. Betrachtet man die
Gemeinschaft wiederum als Netz, so stellt er eine Form des oben bereits
beschriebenen Netzwerkeffektes dar.
Ein wesentlicher Beitrag zum Wachstum solcher Communities stellt die persönliche
Weiterempfehlung dar. Egal worin das gemeinsame Interesse der Mitglieder solcher
Gemeinschaften besteht, ob Wissensgebiet, Kultur oder gar eine Diät, es wird von
ihnen
an
Freunde,
Verwandte
und
Bekannte
weiterempfohlen.
Diese
Weiterempfehlungen sind weitaus glaubwürdiger als anderweitige Werbung, da sie
meist an Personen erfolgen, zu denen bereits eine Beziehung besteht. Diese
Beziehung kann wiederum die Zugehörigkeit zu einer anderen Gemeinschaft sein.
Für den Aufbau einer virtuellen Community zur Potato-Thematik wäre ein
Diskussionsforum gut geeignet. Anbieter sowie Konsumenten könnten sich dort
treffen und sich über die angebotenen virtuellen Waren austauschen. So könnte
beispielsweise ein Softwareentwickler auf sein neuestes Programm aufmerksam
machen. Nutzer die dieses dann verwenden können dann sehr einfach ihre Meinung
dazu abgeben sowie Vorschläge zu Änderungen am Programm machen. Der
Entwickler wiederum erhält somit ein gutes Feedback und kann gegebenenfalls
Anpassungen vornehmen. Dank eines Forums könnten sich gute, neue aber noch
unbekannte Waren schnell verbreiten und so an Popularität gewinnen, dass sie auch
außerhalb der Gemeinschaft gefragt sind.
Zur Förderung von Kontakten zwischen den Nutzern könnte noch ein weiterer
Service zur Verfügung gestellt werden. Nachdem ein Nutzer eine Datei gekauft hat
könnte er vom System eine Liste von Nutzern erhalten, die ebenfalls diese Datei
gekauft, also ein ähnliches Interessengebiet haben. In einem weiteren Schritt wäre
dann noch denkbar ihm Dateien anzubieten, die von diesen Nutzern ebenfalls
gekauft wurden und somit für ihn interessant sein könnten.
Inv-Nr. 2002-09-04/040/IN95/2231
4. Konzeption
Seite 36
4. Konzeption
Um die in ihrer prinzipiellen Funktion beschriebene Serverkomponente des PotatoSystems, den Accounting-Server, zu realisieren muss zunächst ein Konzept erstellt
werden. Ziel ist ein objektorientiertes Konzept, welches die gesetzten Anforderungen
erfüllt und weitestgehend unabhängig von einer nachfolgenden Implementierung ist.
Objektorientiert heißt, dass versucht wird die Dinge der realen Welt auf SoftwareObjekte abzubilden. Dabei wird so abstrahiert, dass nur die im Kontext relevanten
Eigenschaften und Funktionen berücksichtigt werden. Um zu einem solchen Konzept
zu gelangen, wird eine objektorientierte Analyse der Anforderungen durchgeführt.
Aus den Ergebnissen kann man dann ein entsprechendes Design durchführen. Als
Instrument dienen Elemente der Unified Modeling Language (UML), einer Sprache
bzw. Notation zur Spezifikation, Konstruktion, Visualisierung und Dokumentation von
Modellen für Softwaresysteme.
Analyse und Design erfolgen in Anlehnung an Bernd Oestereichs Buch
„Objektorientierte Softwareentwicklung – Analyse und Design mit der Unified
Modeling Language“ (Quelle [7]). Alle Vorgänge und Begriffe, die ich in diesem
Zusammenhang verwende, werden in dieser Quelle ausführlich erläutert.
Inv-Nr. 2002-09-04/040/IN95/2231
4. Konzeption
Seite 37
4.1. Anwendungsfallanalyse
Analyse und Design werden anwendungsfallgetrieben durchgeführt.. Das heißt, dass
zur Erschließung der Anforderungen Anwendungsfälle eingesetzt werden. Sie
beschreiben die grundsätzlichen Abläufe in einem System aus Sicht der Akteure.
Akteure und deren Anwendungsfälle müssen systematisch erarbeitet werden und
bilden die Grundlage für das weitere Vorgehen [7].
4.1.1. Akteure
Akteure sind Klassen, die außerhalb des Systems liegen und an der in einem
Anwendungsfall beschriebenen Interaktion mit dem System beteiligt sind. Akteure
nehmen dabei in der Interaktion gewöhnlich eine definierte Rolle ein.
Akteure sind beispielsweise Anwender eines Systems. Dabei werden jedoch nicht
die beteiligten Personen unterschieden, sondern ihre Rollen die sie einnehmen. Eine
Person kann somit in mehreren Rollen auftreten. Entsprechend werden dann
mehrere Akteure eingeführt. Akteure sind stereotypisierte Klasse und werden als
textueller, visueller oder gemischter Stereotyp dargestellt [7].
Die Akteure, die mit dem System interagieren, ergeben sich aus den oben
eingeführten Personen. Die entsprechenden Stereotype werden beibehalten. Für die
Betrachtung der Anwendungsfälle sind die Folgenden von Interesse:
•
Provider (Fred)
•
Konsument (Draco)
•
Käufer (Harry)
•
Wiederverkäufer (Ginny)
•
AS Betreiber (Bill)
Inv-Nr. 2002-09-04/040/IN95/2231
4. Konzeption
Seite 38
4.1.2. Anwendungsfall: Als Provider registrieren
Tabelle 1: Anwendungsfall: Als Provider registrieren
Als Provider registrieren
Die Registrierung eines Anbieters von virtuellen Waren
wird vorgenommen.
Fred, Bill
Zweck
Akteure
Ereignis
Vorbedingung
Relevante Eingabedaten
Ausnahmen
Ergebnis
Szenario
Fred will sich als Anbieter von virtuellen Waren beim PS
registrieren, um über das System seine Waren
vermarkten zu können.
Login/Passwort, Benutzerdaten, Signatur
Login bereits vergeben, unzureichende Benutzerdaten
Fred ist als gültiger Anbieter von virtuellem Content im
System registriert und besitzt einen Account bei Bill..
1. Fred möchte seine virtuellen Waren über das PS
vertreiben.
2. Fred gibt seine Benutzerdaten an und erhält nach
Überprüfung der Daten sein erwünschtes Login von
Bill.
3. Für Fred wird im System von Bill ein Datensatz und
ein Account eingerichtet.
Dieser Anwendungsfall stellt weitestgehend eine gewöhnliche Nutzerregistrierung
dar. Es gibt jedoch zwei Besonderheiten, die hierbei zu beachten sind. Zum einen
muss Fred bei Bill Daten hinterlassen, die ihn eindeutig als Person Fred identifizieren
können. Dies könnte notwendig sein, wenn Fred beispielsweise Urheberrechte
verletzt hat und Bill rechtliche Schritte dagegen einleiten will. Eine Möglichkeit wäre
die Feststellung der Identität über eine Prüfung der Adressdaten. Bei diesem
Vorgehen würde Bill an die von Fred angegebene Adresse auf dem Postweg einen
Code senden, den Fred wiederum benötigt, um seinen Nutzeraccount bei Bill zu
aktivieren. In diesem Fall liegt der Aufwand auf Bills Seite, was natürlich im Interesse
von Fred wäre.
Eine
weitere
Möglichkeit
zur
eindeutigen
Identifizierung
wären
zertifizierte
Signaturen. Diese werden von unabhängigen Instanzen, Zertifizierungsstellen
genannt, vergeben. Wenn der Nutzer von einer solchen Instanz ein Zertifikat für
seine digitale Signatur haben möchte, muss er sich der Zertifizierungsstelle
gegenüber beispielsweise durch einen Personalausweis identifizieren. Dabei ist
Inv-Nr. 2002-09-04/040/IN95/2231
4. Konzeption
Seite 39
jedoch zu beachten, dass es in vielen Ländern noch keine Gesetzgebung zum
Thema digitale Signaturen gibt. Dies bedeutet, dass in verschiedenen Ländern
Zertifikate unter verschiedenen Richtlinien vergeben werden. Was ist ein Zertifikat im
Fall der Anwendung beim PS wert, wenn es unter Angabe der Email Adresse
vergeben wurde? Des Weiteren ist zu bedenken, dass für den Fall, dass Fred noch
kein Zertifikat hat, auf ihn ein zusätzlicher Aufwand zukommt. Dies liegt jedoch nicht
in seinem Interesse und ist damit schlecht für die Nutzerakzeptanz des PotatoSystems.
Ein weiterer Punkt, der bei der Registrierung von Providern zu behandeln ist, betrifft
die Vergabe von Nutzernummern. Die Betrachtung dieses Problems betrifft jedoch
auch die Registrierung von Käufern und soll in einem späteren Abschnitt behandelt
werden.
4.1.3. Anwendungsfall: Datei anmelden
Tabelle 2: Anwendungsfall: Datei anmelden
Datei anmelden
Zweck
Akteure
Ereignis
Vorbedingung
Ausnahmen
Ergebnis
Szenario
Eine Datei, die eine virtuelle Ware beinhaltet, wird im
System zu Vermarktung angemeldet.
Fred, Bill
Fred will eine virtuelle Ware über das PS vertreiben.
Fred muss beim PS als solcher registriert sein.
Fred muss tatsächlich im Besitz der Rechte an der
angebotenen Ware sein.
Informationen zum Inhalt der Datei, Größe der Datei,
erwünschtes Preismodell für den Vertrieb der Datei,
Hash, semantischer Fingerprint
Im System existiert ein Datensatz zu einer Datei, dessen
Zugehörigkeit zu dieser eindeutig ist. Die Datei selbst
wird mit Informationen zum Eigentümer versehen.
1. Fred übermittelt die Informationen über die
einzustellende Datei an Bill.
1. Bill legt einen entsprechenden Datensatz zur Datei
auf dem AS an.
2. Bill schickt einen elektronischen Registrierungsbeleg
zurück an Fred.
3. Fred fügt diese elektronische Quittung an die
registrierte Datei an.
Inv-Nr. 2002-09-04/040/IN95/2231
4. Konzeption
Seite 40
Um eine virtuelle Ware bei Bill anmelden zu können, muss Fred bereits bei ihm als
Provider angemeldet sein. Die wichtigste Vorraussetzung für das Anmelden einer
Datei ist jedoch, dass Fred tatsächlich in Besitz der Rechte an der virtuellen Ware,
welche die Datei beinhaltet, ist. Wenn dies der Fall ist, kann die Registrierung der
Datei bei Bill vorgenommen werden. Da die eigentliche Verbreitung der Datei
unabhängig vom PS erfolgen kann, muss gewährleistet werden, dass sie anhand der
bei Bill gespeicherten Daten eindeutig identifizierbar ist. Die Notwendigkeit dafür soll
im folgenden Szenario veranschaulicht werden: nehmen wir an, Fred registriert die
Datei
MySong.mp3
bei
Bill,
verknüpft
sie
mit
dem
von
ihm
erhaltenen
Registrierungsbeleg und bietet sie auf seiner Homepage zum Download an. Weiter
angenommen geht bei der Verbreitung der Datei im Internet die Zuordnung des
Belegs zur Datei verloren, und der Beleg wird auf nicht näher betrachtete Weise mit
einer anderen Datei, die vielleicht den gleichen Namen hat, verknüpft. Wenn nun
Ginny die Datei und den Beleg erhält und es kaufen will, so erhält Fred den Kaufpreis
für eine Datei, an welcher er keine Rechte besitzt. Um dies zu verhindern, sollte von
Bill stets geprüft werden, ob die Datei, welche gekauft werden soll, auch die richtige
ist.
Da Merkmale wie Dateigröße, Medientyp u.ä. nur unzureichende Sicherheit bei der
Identifikation von Multimedia in digitaler Form bieten, sollten von Dateien
semantische Fingerprints erzeugt und bei Bill hinterlegt werden, anhand derer man
die Dateien eindeutig identifizieren kann. Für Musik entwickelt die Fraunhofer
Arbeitsgruppe für Elektronische Medientechnologie (AEMT) in Ilmenau ein Verfahren
zur Ermittlung einer „AudioID“. Dieses ermöglicht das Erkennen eines Musikstückes
anhand weniger Sekunden des Signals [9].
Des Weiteren ist auch bei der Registrierung von Dateien die Vergabe von
Transaktionsnummern zu betrachten. Dies erfolgt in einem der folgenden Kapitel.
Inv-Nr. 2002-09-04/040/IN95/2231
4. Konzeption
Seite 41
4.1.4. Anwendungsfall: Als Käufer registrieren
Tabelle 3: Anwendungsfall: Als Käufer registrieren
Als Käufer registrieren
Die Registrierung eines Käufers von virtuellen Waren
wird vorgenommen.
Harry, Bill
Zweck
Akteure
Ereignis
Harry will sich als Käufer beim PS registrieren, um
virtuelle Waren erwerben zu können.
Vorbedingung
Ausnahmen
Ergebnis
Szenario
Auch
dieser
Login/Passwort, Benutzerdaten
Login bereits vergeben, unzureichende Benutzerdaten
Harry ist als gültiger Käufer virtueller Waren beim
System registriert und besitzt einen Account bei Bill.
1. Harry möchte virtuelle Waren über das PS
weiterverteilen.
2. Harry gibt seine Benutzerdaten an und erhält dafür
sein erwünschtes Login von Bill.
3. Für Harry wird im System von Bill ein Datensatz und
einen Account eingerichtet.
Anwendungsfall
stellt
weitestgehend
eine
gewöhnliche
Nutzerregistrierung dar. Im Gegensatz zur Providerregistrierung muss Harry weniger
umfangreiche Angaben machen. Es genügen der Benutzername sowie die Email
Adresse. Eine eindeutige Identifizierung von Harry ist nicht nötig, da er keinen neuen
Content
zur
Verfügung
stellt,
sondern
nur
bereits
registrierten
Content
weiterverbreitet. Durch die oben bereits angesprochene eindeutige Identifikation der
eingestellten Dateien sollte es Harry somit nicht möglich sein, absichtlich oder
unabsichtlich Urheberrechte zu verletzen.
Inv-Nr. 2002-09-04/040/IN95/2231
4. Konzeption
Seite 42
4.1.5. Anwendungsfall: Datei kaufen
Tabelle 4: Anwendungsfall: Datei kaufen
Datei kaufen
Zweck
Akteure
Ereignis
Vorbedingung
Ausnahmen
Ergebnis
Szenario
Erwerb der Provisionsberechtigung bei der
Weiterverteilung der Datei
Ginny, Fred, Bill, Harry
Harry kauft eine virtuelle Ware, die von Fred als Datei bei
Bill registriert ist.
Harry muss als Käufer bei Bill registriert sein.
Harry muss einen zur Datei gehörigen Beleg vorlegen.
Beleg, Quittung, Hash
Datei ist keine gültige „Potato-Datei“
Harry ist im Besitz einer elektronischen Quittung für den
Kauf des Produktes.
1. Harry sendet die Transaktionsnummer für die Datei
zu Bill.
2. Harry erhält von Bill alle relevanten Daten über das
zu kaufende Produkt.
3. Harry sendet eine Kaufanfrage an Bill und bezahlt die
Ware.
4. Bill legt für die Transaktion einen eindeutig
zuweisbaren Datensatz auf dem AS an und schickt
eine entsprechende Quittung an Harry zurück.
5. Harry hängt die Quittung an die Datei an.
6. Bill schreibt die Provision als Umsatz auf Ginnys
Konto gut.
7. Bill schreibt den Kaufbetrag abzüglich der Provision
und seiner Gebühren als Umsatz auf Freds Konto
gut.
Beim Kaufen einer Datei müssen aus Sicht der beteiligten Akteure verschiedene
Vorgänge berücksichtigt werden. Aus Sicht des Käufers (Harry) wäre da zunächst
die Prüfung der Daten über die zu kaufende Datei. Wie oben bereits beschrieben
sollte durch Bill hier eine Identifizierung der Datei erfolgen und Harry mit allen
notwendigen Informationen versorgt werden. Dazu könnten unter anderem der Preis,
der Name des Anbieters sowie die umsatzstatistische Informationen der Datei
zählen. Zentraler Punkt von Harrys Interesse ist natürlich der Erhalt des Kaufbelegs,
der ihn unter anderem die Berechtigung auf Provisionen für den weiteren Vertrieb
sichert.
Aus Sicht von Bill ist vor allem der korrekte Ablauf des Kaufes von Bedeutung, wozu
natürlich auch der Bezahlvorgang gehört. Die Bezahlung der Datei ermöglicht Bill
Inv-Nr. 2002-09-04/040/IN95/2231
4. Konzeption
Seite 43
dazu den entsprechenden Betrag auf Freds Konto, sowie die Provisionen auf die
Konten der provisionsberechtigten Wiederverkäufer (Ginny) gutzuschreiben. Ginny
und Fred haben bei diesem Anwendungsfall eine passive Rolle.
4.2. Anwendungsarchitektur
Unter Anwendungsarchitektur ist hier die innere Strukturierung der AnwendungsKomponenten und Subsysteme zu verstehen. Dabei ist eine der wichtigsten
Anforderungen heutiger Architekturen die Entkopplung der Präsentationsschicht vom
eigentlichen Geschäftsmodell, sowie von der Workflowsteuerung. Aus diesem Grund
hat sich als Standard Architekturprinzip das Model-View-Controller Entwurfsmuster
(MVC) etabliert. Der Grundgedanke von MVC ist die Trennung fachlicher Semantik
von ihrer Präsentation. MVC gliedert Anwendungen in drei Teile:
•
Model (Modell)
Unter Model versteht man die Komponente, die den fachlich-funktionalen
Kern der Anwendung sowie die Daten enthält. Model-Klassen werden
daher auch Fachklassen genannt.
•
View (Ansicht)
Die View ist die Komponente, die die Daten des Models zur Darstellung
bringt.
•
Controller (Kontrollkomponente)
Der Controller steuert die Interaktion des Benutzers mit der Anwendung.
Die drei Teile Model, View und Controller sind nicht separat funktionsfähig, sondern
müssen sich gegenseitig unterstützen (siehe Abbildung 13). Dabei muss jedoch
darauf geachtet werden, dass das Model weitgehend unabhängig von den anderen
Komponenten bleibt [10].
Inv-Nr. 2002-09-04/040/IN95/2231
4. Konzeption
Seite 44
View
Controller
Model
Abbildung 13: Entwurfsmuster Model-View-Controller
In Anlehnung an MVC bilden die im Folgenden beschriebenen Bestandteile die
Architektur des PS (siehe Abbildung 14). Diese sind als Schichten der Architektur zu
verstehen und finden sich in allen Komponenten der Anwendung wieder.
Dialoge
Die Dialoge bilden die Schnittstelle der Anwendung zu ihren Benutzern. Sie sind für
die Präsentation von Daten und Informationen zuständig und nehmen Eingaben
entgegen. Dialoge sorgen für eine angemessene Darstellung und Formatierung von
Informationen aber bearbeiten oder verändern jedoch die Daten inhaltlich nicht.
Ebenso werden Benutzereingaben nur formal, nicht aber inhaltlich verarbeitet. Nach
MVC-Muster entsprechen die Dialoge der View.
Interaktionssteuerung
Die Klassen dieser Schicht empfangen die Ereignisse, die von den Dialogen
kommen.
Die
verarbeitet
die
eingegebenen
oder
darzustellenden Informationen inhaltlich nur in möglichst geringem Maße. Eventuelle
Bearbeitungen
sollten
nur
dazu
dienen,
Zustände
zu
erkennen,
um
die
Bearbeitungssituation zu steuern. Die Hauptaufgabe der Interaktionssteuerung ist die
Kommunikation zwischen den Dialogen und dem funktionalen Kern. Sie ist somit für
den technischen und formalen Ablauf zuständig und entspricht somit dem Controller
des MVC-Musters.
Vorgangssteuerung
Die Vorgangssteuerung gehört nach dem MVC Muster zum Model. Sie initiiert,
überwacht und steuert die Abarbeitung eines fachlichen Ablaufes. Dies könnte zum
Inv-Nr. 2002-09-04/040/IN95/2231
4. Konzeption
Seite 45
Beispiel die Aufgabe „Neue Transaktion erstellen“ sein. Die Vorgangssteuerung
würde in diesem Fall ein neues Transaktionsobjekt erzeugen und mit eventuell
eingegebenen Daten füllen. Vorgangssteuerungen innerhalb von Komponenten
werden auch als Mikrovorgangssteuerung bezeichnet.
Business- und Fachklassen
Diese Klassen repräsentieren die fachliche Sicht auf die Anwendung und gehören
nach MVC ebenfalls dem Model an. Sie beinhalten und kapseln die Attribute und
Operationen der fachlichen Anwendungswelt. Die Fachobjekte spiegeln die
fachlichen Zusammenhänge wieder und sorgen für ihre eigene innere Konsistenz
und ihren Beziehungen untereinander. Fachobjekte wissen jedoch nichts über die
Darstellung ihrer Daten, bzw. darüber, in welchem Verarbeitungskontext sie sich
befinden.
Eine
Businessklasse
ist
eine
Zusammenfassung
von
mehreren
Fachklassen, um diesen eine gemeinsame Schnittstelle zu geben.
Dialoge
Vorgangssteuerung
Businessklassen
Modell
Abbildung 14: Anwendungsarchitektur des Potato-Systems
4.3. Businessklassen identifizieren
Stark abstrahiert beschäftigt sich das PS mit Transaktionen, die von den Nutzern des
Systems ausgeführt werden. Diese Transaktionen drehen sich um virtuelle Waren,
Inv-Nr. 2002-09-04/040/IN95/2231
4. Konzeption
Seite 46
die in Form von Dateien vorliegen. Wobei für das PS nicht die Datei selbst, sondern
nur
bestimmte
Informationen
über
die
Datei
interessant
sind.
Die
drei
Geschäftsklassen des Systems sind:
•
Transaction
•
User
•
File
Diese drei Geschäftsklassen bilden zusammen mit der jeweils zugehörigen
Mikrovorgangssteuerung die drei grundlegenden Komponenten des Systems.
Abbildung 15 zeigt die drei Geschäftsklassen und ihre Beziehungen zueinander.
führt aus
User
1
für
Transaction
*
*
File
1
Abbildung 15: Die Geschäftsklassen repräsentieren das System mit sehr geringem
Detailierungsgrad
4.4. Fachklassenmodellierung
User
Aus den Anwendungsfällen (siehe 4.1) geht hervor, dass ein Nutzer des PS in
mehreren Rollen auftreten kann. Diese Rollen wurden durch die Akteure mit den
Stereotypen Fred, Harry und Ginny verdeutlicht. Aktive Rollen, sprich Akteure, die in
Interaktion mit dem System treten, sind davon Fred und Harry, also Provider und
Käufer von virtuellen Waren.
Um die Fachklassen der Geschäftsklasse User zu modellieren, werden diese
zunächst identifiziert. Dazu werden alle in den Anwendungsfällen verwendeten
Begriffe als Klassen angenommen und aufgelistet:
•
Nutzer (User)
•
Anbieter virtueller Ware (Provider)
•
Käufer (Buyer)
•
Benutzerdaten (Profile)
•
Konto (Account)
•
Umsatz (Turnover)
Inv-Nr. 2002-09-04/040/IN95/2231
4. Konzeption
Seite 47
Nun steht als nächster Schritt die Identifizierung der Beziehungen unter den
gefundenen Klassen an. Abbildung 16 soll diese zeigen.
1
1
User
Account
Provider
1
1
Buyer
*
1
Turnover
Profile
Abbildung 16: Klassenbeziehungen im Bereich User
In dieser Struktur ist die Klasse User als Generalisierung [7] der Klassen Buyer und
Provider modelliert. Bei näherer Betrachtung fällt jedoch auf, dass ein Nutzer nicht
nur eine der beiden Rollen einnehmen kann, sondern durchaus ein Provider auch
Dateien kaufen kann und damit die Rolle eines Käufers einnimmt. In der gezeigten
Struktur ist dieser Fall jedoch nicht realisierbar. Abbildung 17 zeigt eine erweiterte
Struktur, die das Rollenprinzip besser umsetzt.
1
1
nimmt ein
User
Account
Role
1
1
1
*
1
Turnover
Profile
1..*
Buyer
Provider
Abbildung 17: Verbesserte Klassenstruktur mit Rollen
Diese Struktur ermöglicht einem Nutzer mehrere Rollen, mindestens aber eine,
gleichzeitig einzunehmen. Dies wird durch die 1-zu-1..* Komposition ausgedrückt.
Die Klasse Role ist eine Generalisierung der Klassen Buyer und Provider. Diese
Struktur ermöglicht im Bedarfsfall auch eine einfachere Erweiterung des Systems für
Inv-Nr. 2002-09-04/040/IN95/2231
4. Konzeption
Seite 48
weitere Rollen. Weiterhin drückt dieses Klassendiagramm aus, dass jeder Nutzer ein
Nutzerprofil hat und mit einem Konto zu assoziieren ist. Jedes Konto kann wiederum
mehrere Umsätze haben.
Transaction
Für die Modellierung der Fachklassen der Transaction Businessklasse sind die
Anwendungsfälle Datei anmelden (siehe: 4.1.3) und Datei kaufen (siehe 4.1.5) von
Interesse. Es ergeben sich folgende Begriffe und entsprechende Klassen:
•
Transaktion (Transaction)
•
Transaktionstyp (TransactionType)
•
Kauf (Buying)
•
Dateiregistrierung (FileRegistration)
•
Bewertung (Review)
Die Beziehungen stellen sich folgendermaßen dar: Jede Transaktion hat einen
Transaktionstyp. Dabei handelt es sich um eine Dateiregistrierung oder den Kauf
einer Datei. Des Weiteren ist mit jeder Transaktion eine Bewertung zu assoziieren.
File
Für die Businessklasse File ergeben sich lediglich zwei Fachklassen:
•
Datei (File)
•
Preismodell (PriceModel)
Jede Datei hat ein zugehöriges Preismodell, welches Informationen über den Preis
selbst und zur Berechnung der Provisionen enthält.
4.5. Komponentenabgrenzung
Komponenten dienen der Gruppierung und Gliederung einzelner Elemente. Sie
definieren also Grenzen und können über Schnittstellen verfügen [7].
Solche Elemente sind in diesem Fall Klassen. Komponenten dienen hier zur
Gruppierung fachlich zusammenhängender Klassen.
Bei der Integration der drei Teilstrukturen, die sich aus der Fachklassenmodellierung
ergeben haben, ergibt sich die Gesamtstruktur aller Fachklassen des Systems.
Abbildung 18 zeigt die vollständige Struktur mit Abgrenzung der Komponenten.
Inv-Nr. 2002-09-04/040/IN95/2231
4. Konzeption
Seite 49
File
PriceModel
1
1
1
0..1
1
Buying
*
Transaction
1
FileRegistration
Review
*
1
nimmt ein
Turnover
*
1
User
*
Role
1
1
1..*
1
1
Account
1
Profile
Provider
Buyer
Abbildung 18: Klassendiagramm für das Potato-System
Die drei Komponenten ergeben sich aus den Businessklassen. Während diese
jedoch eine abstrahierte Sicht auf das System bieten, dienen die Komponenten der
physischen Gruppierung von zu implementierenden Klassen. Die drei Komponenten
sind:
•
Nutzerkomponente
•
Transaktionskomponente
•
Dateikomponente
Die Schnittstellen zwischen den Komponenten stellen sich recht einfach dar. Jeder
Benutzer kann mehrere Transaktionen haben. Und auch jeder Datei können
mehrere, mindestens aber eine, Transaktionen zugewiesen sein. Des Weiteren ist
jeder Kontoumsatz (Turnover) mit einer Transaktion zu assoziieren.
Inv-Nr. 2002-09-04/040/IN95/2231
4. Konzeption
Seite 50
Die Klassenstruktur ist die Basis für das Design der Datenbank, in der die
persistenten Objekte gespeichert werden. Das aus der statischen Struktur
resultierende Datenbankschema ist in Anhang A zu sehen.
4.6. Aktivitäten modellieren
Die Aktivitäten, die innerhalb der gefundenen Anwendungsfälle ausgeführt werden,
beschreiben
die
Funktionalitäten
der
Vorgangssteuerung
und
der
Mikrovorgangssteuerungen innerhalb der Komponenten. Um diese zu entwerfen,
müssen die ablaufenden Aktivitäten identifiziert und modelliert werden. Die
abgeleiteten
Aktivitätsdiagramme
stellen
eine
weitere
Konkretisierung
der
Anwendungsfälle dar. Außerdem werden in diesem Schritt die Möglichkeiten
gestaltet, wie das System die Anforderungen erfüllen soll. Als Beispiel für das
Vorgehen werden im Folgenden die Aktivitäten für den Anwendungsfall Datei kaufen
(siehe: 4.1.5) modelliert. Aus der Beschreibung der Vorgänge resultiert das
Aktivitätsdiagramm in Abbildung 19.
[Fehler]
[File nicht gefunden]
TransaktionsNr aufnehmen
Fileinfo suchen und prüfen
[OK]
Neue Transaktion anlegen
Zahlung annehmen
Kaufbetrag gutschreiben
Quittung senden
[OK]
Nutzer identifizieren
Nutzerdaten prüfen
Provisionen gutschreiben
[Nutzer unbekannt]
Als Käufer Registrieren
Abbildung 19: Aktivitätsdiagramm für den Vorgang Datei kaufen
Von einem Startpunkt aus werden zunächst zwei Vorgänge parallel durchgeführt.
Einerseits werden zu der eingegebenen Nummer die entsprechenden Informationen
gesucht. Wird kein passender Eintrag gefunden, führt dies zu einem Endpunkt. Die
Aktivität wird ohne Erfolg abgebrochen. Zum Anderen wird geprüft, ob es sich um
Inv-Nr. 2002-09-04/040/IN95/2231
4. Konzeption
Seite 51
einen registrierten Nutzer handelt, der berechtigt ist, eine Datei zu kaufen. Ist dies
nicht der Fall, so kann sich der Nutzer in einem weiteren Schritt als solcher
registrieren.
Sind beide Bedingungen erfüllt, kann der Nutzer die Bezahlung durchführen. Ist die
Bezahlung erfolgreich durchgeführt, werden parallel eine neue Transaktion für den
Kauf angelegt und die Provisionen sowie der Kaufbetrag gutgeschrieben. Als letztes
wird nun noch die Quittung an den Käufer gesendet.
Aus dem Aktivitätsdiagramm kann man nun für die Vorgangssteuerungen der
beteiligten
Komponenten
die
benötigten
Methoden
ableiten
[7].
Für
die
Nutzerkomponente sind dies die Folgenden:
•
getUserByLogin
Diese Methode sucht nach einem Nutzer mit dem eingegebenen Login
und Passwort. Weiterhin überprüft sie die Daten des Nutzers
dahingehend, ob dieser die Berechtigung hat, den gewünschten Kauf zu
tätigen.
•
createNewUser
Ist ein Benutzer noch nicht registriert, kann er durch diese Funktionalität
im System als solcher registriert werden.
Entsprechend ergibt sich für die Dateikomponente folgende Methode:
•
getFileInfoByNumber
Die Methode sucht Informationen über ein File anhand der vom Benutzer
eingegebenen Nummer.
Für die Transaktionskomponente ergeben sich weitere vier Methoden:
•
checkPayment
Diese Methode dient zur Überprüfung des Zahlungsvorganges.
•
createNewTransaction
Sie legt ein neues Transaction-Objekt an und speichert es in der
Datenbank.
•
doAccountingForTransaction
Diese Methode dient zur Buchung der Kontoumsätze die durch den Kauf
anfallen.
Inv-Nr. 2002-09-04/040/IN95/2231
4. Konzeption
Seite 52
4.7. Dialoge identifizieren
Aus den Anwendungsfällen und den modellierten Aktivitäten ergeben sich die
benötigten Dialoge, über die der Nutzer mit dem System interagiert. Tabelle 5 zeigt
die Dialoge, die für jeden Anwendungsfall benötigt werden.
Tabelle 5: Für das System benötigte Dialoge
Anwendungsfall
Dialog
Zweck
Als Provider
newProv
• Eingabedialog für die Daten, die
der Provider zur Registrierung
registrieren
angeben muss
• enthält formelle Überprüfung der
Eingabewerte
newProvConfirm
• bestätigt dem Nutzer die
Registrierung
Als Käufer registrieren
newBuyer
• Eingabedialog für die Daten, die
der Käufer zur Registrierung
angeben muss
• enthält formelle Überprüfung der
Eingabewerte
newBuyerConfirm
• bestätigt dem Nutzer die
Registrierung
Datei anmelden
login
• Dialog zur Authentifizierung des
Nutzers
registerFile
• Eingabedialog zum Auswählen und
Beschreiben der anzumeldenden
Datei(en)
transactionConfirm
• Dialog zur Bestätigung der
Anmeldung
• enthält Verweis auf Beleg ()
Inv-Nr. 2002-09-04/040/IN95/2231
4. Konzeption
Seite 53
Anwendungsfall
Dialog
Zweck
Datei kaufen
login
• Dialog zur Authentifizierung des
Nutzers
buyFile
• Dialog zur Eingabe/auswahl der zu
kaufenden Datei(en)
showBasket
• zeigt die Dateien, die gekauft
werden sollen, in einer Liste
• zeigt den Gesamtpreis
• von diesem Dialog aus gelangt der
Käufer zur Bezahlung
transactionConfirm
• Dialog zur Bestätigung der
Transaktionen
• enthält Verweis auf Quittungen für
die gekauften Dateien
(Transaktionsnummern)
4.8. Transaktionsnummern
Ein wesentlicher Bestandteil des Potato-Konzeptes sind die Transaktionsnummern.
Eine Transaktionsnummer ist der Verweis auf den elektronischen Beleg für den Kauf
oder die Registrierung einer Datei beim PS. Der eigentliche Beleg ist als Datensatz
auf dem AS gespeichert. Er ist durch die Transaktionsnummer eindeutig
identifizierbar und enthält alle Details der Transaktion. Das gesamte funktionale
Prinzip des Potato-Systems basiert auf diesen Nummern.
Eine Transaktionsnummer besteht aus drei Teilen: Der erste Teil ist ein Präfix, der
die Nummer als Potato-Nummer identifiziert. Der zweite Teil ist die Benutzernummer
des Nutzers, der die Transaktion ausgeführt hat. Der letzte Teil ist eine Nummer, die
die Transaktion in Abhängigkeit vom Nutzer eindeutig identifiziert. Die Eindeutigkeit
der gesamten Transaktionsnummer ergibt sich somit aus der Kombination der
Nutzernummer und der nutzerspezifischen Transaktionsnummer. Diese beiden Teile
enthalten ausschließlich numerische Zeichen. Hier drei Beispiele von Nummern:
Inv-Nr. 2002-09-04/040/IN95/2231
4. Konzeption
Seite 54
Tabelle 6: Beispiele für Transaktionsnummern mit ihren Bestandteilen
Transaktionsnummer
Präfix
Nutzernummer
nutzerspezifische
Transaktionsnummer
4fo512344523
4fo
51234
4523
4fo512343224
4fo
51234
3224
4fo568683224
4fo
56868
3224
Bei
den
ersten
beiden
Nummern
ist
die
Nutzernummer
identisch,
die
nutzerspezifischen Transaktionsnummern müssen damit unterschiedlich sein. Wenn
wie bei den letzten beiden Nummern der nutzerspezifische Teil gleich ist, so muss
die Transaktion von unterschiedlichen Nutzern ausgeführt worden sein, sprich die
Nutzerkennungen sind verschieden.
Eine Transaktionsnummer kann ohne Präfix maximal 16 Stellen haben. Dabei sind
die beiden Bestandteile in ihrer Länge variabel. Die Länge der Benutzernummer
kann zwischen zwei und zehn Stellen variieren, wobei die erste Stelle immer die
Anzahl der restlichen Stellen angibt:
TN =
( [x] [k ..k ] ),
1
x
x ∈ {1..9}, k ∈ {0..9}
Daraus ergeben sich neun Nummernklassen für Benutzernummern. Hier drei davon
mit entsprechenden Beispielen:
Tabelle 7: Nummernklassen für Benutzernummern
Nummernklasse
Schema
Beispiel
1
[1][k1]
17
5
[5][k1k2k3k4k5]
587634
9
[9][k1k2k3k4k5k6k7k8k9]
9873542918
Aus der maximalen Gesamtlänge von 16 Stellen abzüglich der Länge der
Nutzernummer ergibt sich eine mögliche Restlänge für die nutzerspezifische
Transaktionsnummer. Diese ist eine für jeden Nutzer fortlaufende Nummer ohne
Inv-Nr. 2002-09-04/040/IN95/2231
4. Konzeption
Seite 55
führende Nullen. Für die 27. Transaktion des Nutzers mit der Nutzernummer 587634
ergäbe sich somit zum Beispiel die Transaktionsnummer 4fo58763427. Aus der
maximalen Anzahl der Stellen der fortlaufenden Nummer ergibt sich die Zahl der
Transaktionen, die der Nutzer beim PS durchführen kann. Sie berechnet sich wie
folgt:
n = 10 15− x − 1
x ∈ {1..9}
Die Unterteilung der Nutzernummern durch variable Längen erlaubt eine
Klassifizierung der Nutzer. So ist es möglich, Nutzern, die sehr viele Transaktionen
durchführen, eine kurze Benutzernummer anzubieten. Dies wäre zum Beispiel bei
Produktionsgesellschaften sinnvoll, die den Vertrieb für viele Musiker abwickeln.
Nutzer, die nur wenige Transaktionen abwickeln können hingegen eine lange
Nutzernummer erhalten. Die Klassifizierung der Nutzer ergibt sich aus der Annahme,
dass es weitaus mehr Nutzer geben wird, die eher wenige, als solche, die sehr viele
Transaktionen tätigen. Somit steht für durchschnittliche Nutzer eine ausreichende
Menge an Benutzernummern zur Verfügung. Solche mit überdurchschnittlich vielen
Transaktionen
haben
den
Vorteil
einer
anwenderfreundlichen,
kurzen
Benutzernummer und einen großen Vorrat an Transaktionsnummern. Jeder Nutzer
der Klasse 3 könnte so jeweils 1012-1 Transaktionen durchführen.
Die Assoziation zwischen einer Datei und der zugehörigen Transaktion wird
hergestellt, indem die vom PS erstellte Transaktionsnummer in den Dateinamen
eingefügt wird. Dies erfolgt auf dem lokalen Dateisystem des Clients. Die
Transaktionsnummer wird zwischen dem eigentlichen Namen und dem Punkt
eingefügt, auf dem die Dateinamenserweiterung folgt. Sollte ein Dateiname mehrere
Punkte enthalten, so wird die Transaktionsnummer vor dem ersten Punkt eingefügt.
Dies hat den Vorteil, dass die Dateinamenserweiterung erhalten bleiben und die
Dateien so kein neues Dateiformat erhalten. Die Datei MySong.mp3 würde nach dem
Einfügen
der
Nummer
4fo6349234002035
folgendermaßen
heißen:
MySong4fo6349234002035.mp3. Das Einfügen der Nummer in den Dateinamen hat
unter anderem den Vorteil, dass Nutzer in Suchmaschinen oder in Tauschbörsen
nach „Potato-Dateien“ suchen können, indem sie den String 4fo in ihre Suche
einbeziehen. Wird noch eine Nutzernummer der Anfrage hinzugefügt, so kann zum
Beispiel nach Dateien eines bestimmten Nutzers gesucht werden.
Inv-Nr. 2002-09-04/040/IN95/2231
5. Implementierung eines Prototyps
Seite 56
Ein Prototyp ist ein vorläufiges oder temporäres Produkt, mit dem künftige Anwender
ausgewählte Eigenschaften und Funktionen des zu entwickelnden endgültigen
Systems erproben können. Dabei muss der Prototyp nicht alle Funktionen des
endgültigen Produktes anbieten, sollte aber einfach erweiterbar und zu verändern
sein. Prototypen können explorativ sein, d.h. zur Erforschung eines Sachverhaltes
dienen. Sie können experimentell, d.h. zur Überprüfung der Machbarkeit oder
Funktionsfähigkeit dienen, oder evolutionär sein, d.h. vorab ein Teilprodukt
bereitstellen [15].
Für das Potato-System wird ein evolutionärer Prototyp erstellt. Er soll die
konzipierten Funktionen und Eigenschaften zum Test anbieten. Diese könnnen dann
in weiteren Evolutionsschritten nach Bedarf geändert und erweitert werden.
Inv-Nr. 2002-09-04/040/IN95/2231
Seite 57
5.1. Überblick über verwendete Technologien
Die Realisierung des Prototyps erfolgt mit Komponenten der Java 2 Platform,
Enterprise Edition (J2EE) Version 1.4 [17]. Als Implementierung der benötigten
J2EE-Komponenten Java Servlets und JavaServer Pages wird Apache Tomcat
Version 4.0 der Jakarta Projektgruppe [19] verwendet. Zur Speicherung der
persistenten Daten dient ein MySQL Datenbank Server [18]. Der AS residiert auf
einem Linux-Server mit Apache Webserver. Im Folgenden wird ein Überblick über die
verwendeten Technologien geboten. Weiterführende Informationen sind unter [17],
[18] und [19] zu finden.
5.1.1. MySQL Datenbank Server
MySQL ist ein RDBMS (relational database management system) der Firma MySQL
AB. Eine relationale Datenbank (RD) speichert Daten in mehreren Tabellen, anstatt
alles in einem großen Speicherraum zu packen, was zu größerer Geschwindigkeit
und Flexibilität führt. Die Tabellen einer RD sind durch definierte Beziehungen
miteinander verbunden, die Anfragen auf kombinierte Daten unterschiedlicher
Tabellen ermöglichen. MySQL ist ein sehr schneller Open Source Datenbankserver,
der Schnittstellen zu vielen Programmiersprachen besitzt und für verschiedenste
Plattformen existiert.
5.1.2. JavaBeans
JavaBeans ist ein von der Firma Sun Microsystems entwickeltes, auf Java
basierendes Komponentenmodell zur Softwareentwicklung, d.h. eine Architektur für
die Definition und Wiederverwendung von Softwarekomponenten. Einzelne Beans
dienen als Basisbausteine, aus denen man durch Zusammensetzen größere
Softwareteile erstellen kann. Die Verwendung von Komponenten dient der
Modularität und Kapselung von Klassen und trägt außerdem zur besseren
Wiederverwendbarkeit und Überschaubarkeit bei größeren Softwareprojekten bei.
Inv-Nr. 2002-09-04/040/IN95/2231
Seite 58
5.1.3. Java Servlets
Java Servlets sind plattform- und protokollunabhängige, serverseitige Komponenten,
geschrieben in Java, welche auf einem javafähigen Server (z.B. Tomcat) ausgeführt
werden. Sie bilden den Rahmen für nahezu alle Anfrage/Antwort-basierten Dienste.
Ihre ursprüngliche Aufgabe besteht in dem sicheren, webbasierten Zugriff auf Daten,
welche in HTML Form dem Benutzer dargestellt werden. Diese Daten sollten
dynamisch veränderbar sein. Java Servlets sind Java Anwendungen mit einer
speziellen Schnittstelle, dem Java Servlet API. Java Servlets steht somit nahezu das
gesamte JDK zur Verfügung, was sie zu einem sehr mächtigen Werkzeug werden
lässt. Da Servlets ausschließlich Daten transportieren, diese jedoch nie selbst
darstellen, haben sie keine grafische Benutzerschnittstelle [20].
Die Laufzeitumgebung für Servlets wird von einem sogenannten Servlet-Container
zur Verfügung gestellt. Er ist dafür verantwortlich, dass Anfragen an den Server dem
entsprechenden Servlet zugeordnet werden und dieses geladen und ausgeführt wird.
Nach Bearbeitung der Anfrage durch das Servlet wandelt der Container das AntwortObjekt in eine Antwortnachricht für den Client um. Als Servlet Container dient beim
AS Apache Tomcat 4.0 [19]. Tomcat 4.0 implementiert die Version 2.3 der Servlet
Spezifikation.
5.1.4. JavaServer Pages (JSP)
Java Server Pages sind HTML-Seiten, welche spezielle Tags enthalten. Sie
bestehen i.d.R. aus folgenden Komponenten:
•
Statische HTML / XML Komponenten
•
Spezielle JSP Tags
•
Kleine Java Codefragmente, genannt „Scriptlets“
Java Server Pages können mit konventionellen HTML/XML-Tools bearbeitet werden.
Sie werden dann von einem JSP-fähigen Webserver (z.B. durch Tomcat)
interpretiert. Dieser empfängt Anfragen an eine JSP-Seite und generiert eine Antwort
von der JSP-Seite an den Client. Wenn eine JSP-Seite zum ersten Mal aufgerufen
wird, wird sie von der Engine in ein Java Servlet kompiliert und in den Speicher des
Webservers geladen. Dies erhöht die Effizienz bei weiteren Zugriffen auf die Seite.
Die Umgebung für JSP wird ebenfalls durch Tomcat zur Verfügung gestellt.
Inv-Nr. 2002-09-04/040/IN95/2231
Seite 59
http://www.
Webserver
html
JSP Engine
jsp
Browser
Abbildung 20: Funktionsweise eines Webservers mit JSP
5.1.5. Java Applets
Unter einem Java-Applet versteht man eine Java-Anwendung, die aus dem Internet
auf dem eigenen Rechner geladen und im Browser ausgeführt wird. Um dies zu
ermöglichen, werden Referenzen von Applets in HTML-Seiten eingebettet. In einem
Applet stehen fast alle Möglichkeiten von Java zur Verfügung, so dass sich beliebig
komplexe Anwendungen entwickeln lassen. Da Applets aber auf dem Rechner der
Nutzer laufen, sind sie prinzipiell an Sicherheitseinschränkungen gebunden, um dort
keinen Schaden anrichten zu können. Solche Einschränkungen können durch
signierte Applets aufgehoben werden. Mehr zu Applets ist unter [22] zu erfahren.
5.2. Umsetzung der Anwendungsarchitektur
Für die Umsetzung der an MVC orientierten Architektur kommt eine Kombination aus
JSP, Java Servlets und JavaBeans zum Einsatz (siehe Abbildung 21). Der Kern der
Anwendung, das Modell, besteht aus JavaBeans, welche die Fachklassen sowie die
Vorgangssteuerungen innerhalb der Komponenten realisieren. Die Darstellung der
Modelldaten
in
den
Dialogen
erfolgt
mit
JSP
und
Java
Applets.
Die
Interaktionssteuerung (Controller) wird durch ein Java Servlet realisiert. Persistente
Daten werden im MySQL Datenbank Server abgelegt. Der Zugriff auf die Daten
durch die Beans erfolgt über JDBC (Java Database Connectivity). Das ist eine
Schnittstellendefinition
für
die
Kommunikation
von
Java-Anwendungen
mit
Datenbanken. Alle namhaften Datenbankfirmen arbeiten mit an diesem Standard.
Die Programmierschnittstelle definiert Java-Klassen für Datenbankverbindungen,
Inv-Nr. 2002-09-04/040/IN95/2231
Seite 60
SQL-Befehle, et cetera. Der Programmierer kann über JDBC herstellerunabhängige
Datenbankbefehle absetzen und die Ergebnisse bearbeiten.
Tomcat
(Servlet Container)
6
Browser
MySQL
JSP
(RDBMS)
(View)
Response
4
5
1
Java
Applet
Request
Java Servlets
(Controller)
a
2
3
JavaBeans
(Model)
JDBC
Abbildung 21: Anwendungsarchitektur mit Ablauf einer Anfragebearbeitung
Wird von einem Browser eine Anfrage (Request) an die Anwendung gerichtet, wird
diese vom Servlet entgegengenommen und ausgewertet (1). Entsprechend der
Anfrage wird mit Hilfe der Java Beans eine Antwort erzeugt (2). Die Beans ihrerseits
können dabei auf das RDBMS zugreifen (3). Das Servlet ruft eine JSP-Seite auf (4),
welche die vom Servlet erzeugte Antwort sowie die Modelldaten der Beans darstellt
und gegebenenfalls formatiert (5). Die daraus erzeugte Antwortnachricht wird vom
Servlet Container an den Browser zurückgesendet (6).
Die Kombination aus JSP, Servlet und Beans ist ein leistungsfähiges Werkzeug zur
Entwicklung gut strukturierter Anwendungen. Da ein Servlet eine reguläre JavaKlasse ist, kann in Verbindung mit Beans die ganze Macht der Sprache zur
Bearbeitung der Anfragen eingesetzt werden. Eine Anwendung mit einem Servlet als
zentralen Eingangspunkt bietet eine weitaus höhere Übersichtlichkeit als eine reine
JSP-Lösung.
Die in Tabelle 5 aufgeführten Dialoge sind somit zwar als JSP-Seiten umgesetzt,
werden aber stets über das Servlet aufgerufen. Dazu wird die Bezeichnung des
Inv-Nr. 2002-09-04/040/IN95/2231
Seite 61
aufzurufenden Dialoges als Parameter an das Servlet übergeben. Für die URL ergibt
sich dann folgendes Muster:
http://[SERVER]/[SERVLETNAME]?do=[DIALOGNAME]
Zur Anzeige des Warenkorbes ergäbe sich zum Beispiel diese URL:
http://www.potatosystem.com/action?do=showBasket
Ein wesentlicher Vorteil dieser Vorgehensweise ist die Möglichkeit, vor dem
Anzeigen des Dialogs die Berechtigung des Nutzers dafür überprüfen zu können.
Die JSP können dann für das benutzt werden, wofür sie am besten geeignet sind:
zur Darstellung der von Servlet und Beans generierten Antworten. Ein weiterer
Vorteil ist, dass standardmäßige Java-Entwicklungs- und Debugging-Umgebungen
eingesetzt werden können.
5.3. Kommunikation zwischen Applets und dem Server
Neben der bloßen Darstellung von Transaktionsergebnissen soll die in Kapitel 4.8
beschriebene Umbenennung der Dateien auf den Client-Systemen automatisiert
werden. Dazu ist es notwendig, eine Technologie anzuwenden, die auf dem ClientSystem Operationen ausführen kann. Da die PS-Anwendung im Browser ausgeführt
und serverseitig schon Java-Technologie verwendet wird, fiel die Entscheidung auf
den Einsatz von Java Applets. Für den Schreibzugriff auf das lokale Dateisystem des
Client-Systems werden jedoch signierte Applets benötigt. Diese haben mit
Zustimmung des Nutzers die entsprechenden Berechtigungen.
Die Kommunikation zwischen den Applets und dem Servlet findet in erster Linie mit
Hilfe von Objekt-Serialisierung statt (siehe Abbildung 21 (a)). Darunter versteht man
die Umwandlung eines Objektes in einen Byte-Streams und zurück. ObjektSerialisierung ermöglicht die Übertragung auf byteorientierten Übertragungsstrecken
oder die Speicherung von Objekten in einem Dateisystem. Ein weiteres Mittel zur
Kommunikation ist der parametrisierte Aufruf der Applets. Dabei werden dem Applet
von der JSP-Seite Werte übergeben, die es benötigt um die gewünschten Aktionen
auszuführen.
Inv-Nr. 2002-09-04/040/IN95/2231
Seite 62
So läuft der Anwendungsfall Datei anmelden wie folgt ab: Der Nutzer kann im Applet
Creator die Dateien von seinem lokalen System auswählen, die er beim PS
anmelden möchte. Für jede dieser Dateien kann er dann die Attribute festlegen. Das
Creator-Applet erzeugt aus den Angaben eine Beschreibung der Dateien im XMLFormat [21], welche auch die Hashes über die Dateien enthält. Weiterhin erstellt es
für jede Datei eine Vorschau und einen Fingerprint in Form von Dateien. Diese
werden dann zusammen mit der XML-Beschreibung in ein ZIP-Archiv gepackt,
welches als Java-File-Objekt an das Servlet geschickt wird. Das Servlet extrahiert die
Daten aus der ZIP-Datei und ruft die entsprechenden JavaBeans auf, welche die
Anmeldung durchführen. Für die Anmeldung der Dateien legen die Beans die
Dateibeschreibungen in der Datenbank und die zugehörigen Vorschau- und
Fingerprint-Dateien im Dateisystem des Servers ab. Nach erfolgreicher Anmeldung
schickt das Servlet ein String-Objekt an das Creator-Applet zurück. Der String enthält
die URL für den Aufruf des Applets Renamer, welches die Umbenennung der
Dateien auf dem System des Nutzers vornimmt. Das Creator-Applet ruft die
erhaltene URL im Browser auf. Die alten und neuen Namen der Dateien werden dem
Renamer-Applet als Parameter von der JSP-Seite übergeben. Nach der Bestätigung
des Nutzers erfolgt die Umbenennung. Der Ablauf von Datei kaufen läuft
technologisch im Wesentlichen gleich ab. Jedoch kommt ein weiterer Schritt hinzu,
der Bezahlvorgang. Näheres zu den verwendeten Applets ist in [22] zu finden.
Inv-Nr. 2002-09-04/040/IN95/2231
6. Zusammenfassung und Ausblick
Seite 63
Ob das Potato-System die gestellten Anforderungen und auch Hoffnungen zu
erfüllen vermag wird sicherlich erst nach einer ausführlichen Testphase mit realen
Nutzern und realem Content absehbar sein. Jedoch wurden im Laufe dieser Arbeit
Erkenntnisse gewonnen, die schon jetzt einige Aussagen über das PS zulassen.
Durch die Verwendung einer P2P-Netzwerkstruktur bietet das PS optimale
Vorraussetzungen für die schnelle und effiziente Verbreitung von virtuellen Waren.
Dies belegen die unzähligen Tauschbörsen im Internet, die auf P2P-Netzwerken
basieren. Auch beim Multilevel Marketing hat sich der Vertrieb der Waren über ein
logisches P2P-Netzwerk in vielen Fällen bewährt, wo wie beim PS ebenfalls
Provisionen der wichtigste Antrieb für das Funktionieren dieses Prinzips ist.
Das Potato-System verfügt also über die prinzipiellen Vorraussetzungen, eine
sinnvolle Alternative für den Vertrieb von virtuellen Waren über das Netz zu werden.
Es versucht nicht den Konsumenten zum Wahren der Interessen der Provider zu
zwingen. Vielmehr bringt es ihn in eine Position, in der er die Bedürfnisse des
Providers teilt: Beide wollen möglichst viele Käufer für die Ware finden, um einen
Profit zu erwirtschaften. Das Potato-System könnte durch die Schaffung dieses
gemeinsamen Interesses die derzeitige Verfeindung von Providern und Nutzern
abbauen.
Ein Erfolg kann jedoch keineswegs garantiert werden, da dieser von vielen Faktoren
abhängig ist. Der wahrscheinlich wichtigste ist nach meiner Ansicht die Qualität der
Waren, die über das System vertrieben werden sollen. Nur bei gefragtem Content
Inv-Nr. 2002-09-04/040/IN95/2231
Seite 64
werden sich die Nutzer Chancen auf Provisionen ausrechnen und eventuell dafür
bezahlen. Des Weiteren gibt es in jedem Vertriebsnetz Randknoten, die keine
Provisionen erwirtschaften können oder wollen. Während diese beispielsweise bei
realen MLM-Systemen die Waren kaufen müssen um sie zu konsumieren, ist dies
beim PS nicht zwingend nötig. Kauft jedoch der Letzte in einer Kette nicht, so erhält
der vor ihm keine Provision und verliert somit ebenfalls seine Motivation zum Kauf.
Es sollte daher vielleicht weiterführend betrachtet werden, ob neben den finanziellen
auch noch andere Anreize für den Kauf der Waren geschaffen werden können.
Solche wären zum Beispiel limitierte Fanartikel oder Konzertkarten, die für den
Nutzer einen hohen ideellen Wert haben. Weiterhin sollte untersucht werden, wie die
im Accoounting-Server gesammelten Informationen über die Nutzer und deren
Beziehungen zueinander für weitere Dienste des Potato-Systems verwertbar sind.
Inv-Nr. 2002-09-04/040/IN95/2231
Literatur- und Quellenverzeichnis
Seite 65
[1]
Peer-To-Peer Harnessing the Benefits of a Disruptive Technology; Andy Oram;
O’Reilly & Associates 2001
[2]
Gnutella and Freenet; Represent True Technological Inovation; Andy Oram;
http://www.oreillynet.com/lpt/a//network/2000/05/12/magazine/gnutella.html
[3]
What is ICQ?; About the Web’s Largest Community;
http://www.icq.com/products/whatisicq.html
[4]
Einführung ins Affiliate Marketing;
http://www.contentmanager.de/magazin/artikel_127.html
[5]
Forrester Research
http://www.forrester.com/
[6]
The Superdistribution Resource Page
http://sda.k.tsukuba-tech.ac.jp/SdA/
[7]
Objektorientierte Softwareentwicklung; Analyse und Design mit der Unified
Modeling Language; Bernd Oestereich; R.Oldenbourg Verlag München Wien
1998
[8]
UML; Objektorientierte Modellierung für die Praxis, 2. Auflage; Rainer
Burkhardt; Addison-Wesley 2000
[9]
AudioID; Fraunhofer Institut Integrierte Schaltungen;
http://www.emt.iis.fhg.de/produkte/audioid/
[10] Pattern-orientierte Software-Architektur; F.Buschmann, Regine Meunier, Hans
Rohnert, Peter Sommerlad, Michael Stal; Addison-Wesley 1998
[11] Der Einsatz Offener Systeme in der Praxis - Technologien, Standards,
Probleme; Hugo Stempfle;
http://www.fh-augsburg.de/informatik/diplomarbeiten/langfassungen/stempflestork-1996/OpenSystems/open_sys.htm
Inv-Nr. 2002-09-04/040/IN95/2231
Seite 66
[12] Virtuelle Communities und Markenmanagement; Caspar Clemens Mierau;
http://www.medienkultur.org/sm1/tdm/ha/index.html
[13] Small World Research Project; Department of Sociology, Columbia University
http://smallworld.sociology.columbia.edu/
[14] An Experimental Study of the Small World Problem; J. Travers and S. Milgram,
1969
http://citeseer.nj.nec.com/context/493214/0
[15] Erfolgreich mit Objektorientierung; Vorgehensmodell und Managementpraktiken
für die objektorientierte Softwareentwicklung, 2. Auflage; Bernd Oestereich;
R.Oldenbourg Verlag München Wien 2001
[16] Was ist Open Source?; Informatik Support Gruppe; ETH Zürich;
http://www.ch-open.ch/html/events/Event_19.11.1999/opensource.html
[17] JavaTM 2 Platform, Enterprise Edition (J2EETM); J2EE Technologies;
http://java.sun.com/j2ee/
[18] MySQL Reference Manual; Michael Widenius, David Axmark; O’Reilly &
Associates 2002
[19] The Jakarta Project - Apache Tomcat
http://jakarta.apache.org/tomcat/
[20] Java Servlet Programming; Jason Hunter, William Crawford; O’Reilly &
Associates 1998
[21] XML kompakt; Eine praktische Einführung; Thomas Michel; Hanser Verlag
München Wien 1999
[22] Konzeption und Realisierung der Client-Komponenten für ein P2P-File-SharingSystem mit Umsatzbeteiligung für die Benutzer; Jens Hasselbach; Diplomarbeit,
Technische Universität Ilmenau 2002
Inv-Nr. 2002-09-04/040/IN95/2231
Abbildungsverzeichnis
Seite 67
Abbildungsverzeichnis
Abbildung 1:
Client/Server-Modell.......................................................................... 4
Abbildung 2:
Ausschnitt aus Gnutella-Netzwerk..................................................... 6
Abbildung 3:
Modell eines reinen P2P-Netzes ....................................................... 9
Abbildung 4:
Hyprides P2P .................................................................................. 15
Abbildung 5:
Webseite mit Bannerwerbung ......................................................... 17
Abbildung 6:
Affiliate-Netzwerk ............................................................................ 19
Abbildung 7:
Strukturvertrieb................................................................................ 21
Abbildung 8:
Einbettung eines Baumes in ein P2P-Netzwerk .............................. 24
Abbildung 9:
Waren- und Geldfluss bei dezentralem Lösungsansatz .................. 26
Abbildung 10: Waren- und Geldfluss bei dezentralem Lösungsansatz mit zentraler
Provisionsauszahlung ..................................................................... 27
Abbildung 11: Waren- und Geldfluss mit zentraler Instanz .................................... 28
Abbildung 12: Prinzipieller Ablauf beim Potato-System ......................................... 33
Abbildung 13: Entwurfsmuster Model-View-Controller ........................................... 44
Abbildung 14: Anwendungsarchitektur des Potato-Systems.................................. 45
Abbildung 15: Die Geschäftsklassen repräsentieren das System mit sehr geringem
Detailierungsgrad ............................................................................ 46
Abbildung 16: Klassenbeziehungen im Bereich User............................................. 47
Abbildung 17: Verbesserte Klassenstruktur mit Rollen .......................................... 47
Abbildung 18: Klassendiagramm für das Potato-System ....................................... 49
Abbildung 19: Aktivitätsdiagramm für den Vorgang Datei kaufen .......................... 50
Abbildung 20: Funktionsweise eines Webservers mit JSP..................................... 59
Abbildung 21: Anwendungsarchitektur mit Ablauf einer Anfragebearbeitung......... 60
Inv-Nr. 2002-09-04/040/IN95/2231
Tabellenverzeichnis
Seite 68
Tabellenverzeichnis
Tabelle 1: Anwendungsfall: Als Provider registrieren ............................................... 38
Tabelle 2: Anwendungsfall: Datei anmelden............................................................. 39
Tabelle 3: Anwendungsfall: Als Käufer registrieren .................................................. 41
Tabelle 4: Anwendungsfall: Datei kaufen.................................................................. 42
Tabelle 5: Für das System benötigte Dialoge ........................................................... 52
Tabelle 6: Beispiele für Transaktionsnummern mit ihren Bestandteilen ................... 54
Tabelle 7: Nummernklassen für Benutzernummern ................................................. 54
Inv-Nr. 2002-09-04/040/IN95/2231
Anhang A
Seite 69
Anhang A – Datenbankschema des Potato-Systems
File
PK
Review
PriceModel
ID
PK
ID
Name
Size
ContentType
FileType
Hash
Description
FK1
FileID
Price
PriceReduction
Commission
CommissionReduction
PayPercentage
Comments
Transaction
PK
ID
PK
ID
FK1
TransactionID
Rating
Text
FK1
FileID
TransactionNo
Type
SellerID
BuyerID
Date
Generation
FK2
FK3
Turnover
PK
ID
FK2
FK1
AccountID
TransactionID
Date
Amount
Roles
PK
Name
Description
User
Account
PK
ID
FK1
UserID
Amount
PK
ID
FK1
Login
Password
Email
UserNo
RolesID
Inv-Nr. 2002-09-04/040/IN95/2231
ID
Profile
PK
ID
FK1
UserID
Lastname
FirstName
Address
Address2
ZipCode
City
State
Country
URL
PhoneNumber
CellPhone

Technische Universität Ilmenau

Transcrição

Documentos relacionados

Flexlight der bel. Bilderrahmen.cdr

Titel der Aufgabe - Software

visionapp Platform Management Suite Most Recently Used List

Anleitung zum Bearbeiten der Programmliste bzw. Importieren der

Versuch 2: Addierer

Untitled

Time Machine Adventure: Anni and Fred at the

Z-Club-Germany e.V. April 2009 Langenburg Historic

Programmverhalten analysieren - VB

Installationsanleitung

Ich habe eine Freundin. Meine Freundin ist die Christina. Das ist

Allgemeine Geschäftsbedingungen - Webspace