Im Rahmen dieser Projektarbeit soll eine verteilte Anwendung entwickelt werden, welche in der Lage ist, über ein Netzwerk Mehrpersonen-Spiele anzubieten und dynamisch zu verwalten. Hierbei soll weniger der Fokus auf die Spiele an sich, sondern auf die Kommunikation und den Datentransport der einzelnen Clients gesetzt werden. Die Hauptaufgabe besteht darin, einen Client auf Basis von Jini und JavaSpaces zu erstellen, welcher Verbindungen zu anderen Spielern aufbaut und die verschiedensten Spiele anbietet. Diese Spiele können durch ‚einfache Integration’ eingebunden werden. Unter ‚einfacher Integration’ versteht man, dass der Anwender seinen Client nicht updaten muss, wenn der Entwickler ein neues Spiel implementiert und integriert! Die Integration eines neuen Spiels soll durch ‚dynamisches Klassenladen’ über einen Webserver stattfinden. Die Abbildung 1.1-1 zeigt den verteilten Aufbau.

(Abbildung 1.1-1)

Der Client muss folgende funktionalen Kriterien nach Abschluss dieser Projektarbeit erfüllen können:

- Ein beliebig ausgewählte Spielpartie erstellen

- Einer erstellten Spielpartie beitreten

- Eine Spielpartie verlassen

- TicTacToe spielen

- Das 100er Spiel spielen

- Verbindung zu den Jini- Diensten aufbauen

- Mehrbenutzerfähigkeit

- Einfache Integration weiterer Spieltypen

- Datentransport ausschließlich über JavaSpaces

- Dynamische Objektverwaltung des JavaSpace-Servers

1.1.3 Kriterien, die der Client erfüllen kann

Weitere Ziele, die das Projekt zwar erfüllen könnte, aber auf die hier verzichtet werden kann, da sie die eigentliche Kernfunktionalität nicht beeinflussen:

- Eine laufende Spielpartie beobachten

- Authentifizierung mit einem Spielernamen

1.1.4 Abgrenzungskriterien zu anderen Produkten In diesem Punkt möchte ich kurz auf die Abgrenzung der Funktionalität zu anderen Systemen eingehen, welche aber hier bewusst nicht zur Zielsetzung beitragen sollen. Als Gegenüberstellung habe ich den ‚Gamespy’ der Firma Arcarde (http://www.gamespy.com) getestet, welcher von der Grundidee ähnlich ist, sich aber dennoch in folgenden Punkten abgrenzt:

- Wurde in anderer Programmiersprache implementiert (C++)

- Installation nur über das Internet

- Datentransport ist in den Spielen selbst ‚hart programmiert’

- Client-Update bei neuer Spielintegration erforderlich

- GameSpy beinhaltet User Chat und Spielerliste als Feature

Im Allgemeinen kann man sagen, dass die Anwendung von zwei Gruppen genutzt wird.

- Der ‚Endanwender’ ? nutzt den Client zum Spielen!

- Der ‚Spielprogrammierer’ ? Zum einfachen Integrieren neuer Spiele

1.2.2 Einsatzgebiet und Betriebsbedingungen

Der Client soll seinen Einsatz bei jedem Anwender finden, der gerne mit anderen Leuten über ein Netzwerk spielen möchte. Die physikalische Umgebung des Systems wird in den meisten Fällen der Home-PC, eventuell auf einer LAN-Party sein. Weiterhin soll die Anwendung bei Spielprogrammierern zum Einsatz kommen, die mit einfachen Mitteln Mehrpersonen-Spiele anbieten und implementieren möchten. Die Betriebszeit hängt von dem Anwender ab und kann hier nicht definiert werden.

Auf den ersten Blick erinnert das Wort Jini an den ‚guten Lampengeist’ aus

Prinzipiell kann man bei Jini, wie in Abbildung 2.1-1 zu sehen ist, drei Hauptkomponenten ausmachen:

Ein zentraler LookupService-Server stellt den Dreh- und Angelpunkt des gesamten Konzeptes dar. Er muss allen anderen Komponenten zugänglich sein und enthält eine Art Datenbank diverser zuvor registrierter Services, die bei Bedarf ausgeliefert werden können.

Der Service-Server ist der ‚Anbieter’ von Services. Er registriert selbige beim Lookup-Server und führt sie meistens auch aus.

Ein Client bzw. das entsprechende Programm implementiert die Schnittstelle zum Endnutzer und richtet dementsprechend formatierte Service-Wünsche an einen Lookup-Server. Er macht die Services also letztendlich nutzbar.

Alle Komponenten können auf beliebigen Rechnern laufen, die durch ein ‚beliebiges TCP/IP Netzwerk’ verbunden sind.

(Abbildung 2.1-1)

Sowohl Client als auch Service müssen zunächst Kontakt zu einem Lookup-Service aufnehmen. Hier unterscheidet man zwei Wege :

? Unicast-Lookup ? Multicast- Lookup

Unicast-Lookup wird verwendet, wenn die IP-Adresse des Lookup-Servers bereits bekannt ist. Hier wird also gezielt eine Verbindung hergestellt.

Beim Multicast-Lookup wird per ‚Broadcast’ im so erreichbaren Netzwerk versucht, einen Lookup-Service zu finden. Dieser wird standardmäßig auf Port 4160 ‚lauschen’. Das heißt, eigentlich ‚lauscht’ dort der RMI-Daemon (s.h. Anhang), welcher dann den Lookup-Service aufweckt. Bei der Suche können Gruppen angegeben werden, die einen solchen Service unterstützen sollen. In jedem Fall liefert nach erfolgreicher Verbindungsaufnahme der Lookup-Service ein so genanntes ‚Registrar-Objekt (Proxy) ’ an den Client bzw. Service P

(s.h. Abb. 2.1-2). Dies kann dann zur weiteren Kommunikation genutzt werden.

Lookup-Service wird gesucht:

(Abbildung 2.1-2)

Service mit diversen Eigenschaften registrieren. Dabei werden u.a eine Kopie SP des Services bzw. eines Service-Proxies , der später Kontakt zum

eigentlichen Service aufnehmen kann, zum Lookup-Server gesendet (s.h. Abb. 2.1-3). Der Lookup-Server vergibt bei der erstmaligen Registrierung eine eindeutige ID, welche bei erneuter Anmeldung vom Service-Server oder auch vom Client genutzt werden kann. Je nach Lookup-Service muss die Registrierung regelmäßig erneuert werden. Dies dient z.B. dem Vermeiden von ‚Service-Leichen’. Wenn ein Service registriert ist, kann mit Sicherheit davon ausgegangen werden, dass der Anbieter noch existiert.

Dienst meldet sich an:

(Abbildung 2.1-3)

anzufordern. Dazu muss entweder eine eindeutige ‚Service-ID’, diverse Eigenschaften oder ein konkretes Interface angegeben werden, welches dem gewünschten Service entspreche n. (s.h. Abb. 2.1-4)

Client nutzt Service:

(Abbildung 2.1-4)

Leasing basiert auf dem Prinzip, dass Zugriff auf eine Ressource nur für begrenzte Zeit gewährt wird. Die Ressource wird für eine bestimmte Zeitspanne ‚geliehen’. Jini- Leases stellt an Nutzer von Ressourcen bei langfristiger Nutzung die Anforderung regelmäßiger Bestätigung des Bedarfs. Jini- Leases können vom Anbieter des Leases abgelehnt und vom Abnehmer verlängert werden. Leases bieten eine konsistente Möglichkeit für das Entfernen ungenutzter oder nicht mehr benötigter Informationen, um mit den vorhandenen Ressourcen schonend umzugehen.

2.2.2 Vorteile von Leasing

Ein großer Vorteil liegt darin, dass die Wahrscheinlichkeit des Absturzes des gesamten Systems auf ein Minimum reduziert wird.

? Das System verhält sich ‚vorsichtig’

Jini vereinheitlicht die Handhabung bestimmter Programmfehler, die Leases werden bei Netzwerkfehlern und Abstürzen von einzelnen Rechnern nicht mehr verlängert.

Ablegen von Objekten

Lease write(Entry entry, Transaction txm, long lease)

Lesen von Objekten

Entry read(Entry Template, Transaction txm, long timeout) Entry readIfExsits(Entry Template, Transaction txm, long Timeout)

Entfernen von Objekten

Entry take(Entry Template, Transaction txm, long Timeout) Entry takeIfExsits(Entry Template, Transaction txm, long Timeout)

2.3.2 Das Entry

Ein Objekt, welches in einem Space gespeichert werden soll, bezeichnet man als ‚Entry’. Um ein Entry zu sein, muss das Objekt das Interface Entry implementieren.

Ein Beispiel: import net.jini.core.entry.Entry;

public class Nachricht implements Entry { public String einString; // Ein Konstruktor ohne Argumente public Nachricht() { } }

Diese Klasse besitzt ein String- Attribut, welches eine Nachricht aufnehmen kann. Entry ist ein ‚marker Interface’. Es besitzt somit keine Konstanten oder Methoden und ist daher recht einfach zu implementieren. Jedes Feld eines Entry muss ‚public’ sein. Man kann keine Basistypen in einem Entry abspeichern. Ein Entry kann eine beliebige Anzahl von Konstruktoren haben.

2.3.3 Idee der Synchronisation

JavaSpaces könne n sehr gut zur Kommunikation und Koordination in verteilten Java-Anwendungen eingesetzt werden.

Zum Beispiel kann man JavaSpaces zur Koordination schnell veränderlicher JINI-Umgebungen, Umgebungen in denen Entities verfügbar und nicht verfügbar sind, einsetzen. JavaSpaces garantiert Synchronisation auf Entry Ebene. Durch den geschickten Einsatz dieser Entries können also Zugriffe und Aktivitäten synchronisiert werden.

Es ergibt sich folgendes Grundmuster der Synchronisation:

- Lesen eines vorhandenen Entry ist jederzeit möglich (auch von mehreren Prozessen)

- Ändern eines Entry ist jeweils nur durch einen Prozess möglich. Dabei wird das Entry erst aus dem Space entfernt, dann verändert. Damit ist es exklusiv verfügbar. Danach wird es wieder in den Space zurück geschrieben.

‚Read(), write()’ und ‚take()’ Operationen erzwingen einen koordinierten Zugriff auf Entries. Dieser Mechanismus muss verstanden worden sein, da er als Grundlage in der zu implementierenden Anwendung dient.

Wie bereits aus der Zielsetzung hervorgeht, ist eine verteilte Anwendung zu entwickeln, welche auf Basis von Jini und JavaSpaces einen Client repräsentieren soll, mit dem man die verschiedensten Spiele über eine TCP/IP Verbindung nutzen kann. Dazu soll eine übersichtliche Oberfläche erstellt werden, die dem Nutzer bei Programmstart die Möglichkeit gibt, eine Spielpartie zu erstellen, einer erstellten Partie beizutreten, eine laufende Partie als Beobachter zu verfolgen und den Client wieder beenden zu können. Möchte der Anwender eine neue Spielpartie erstellen, soll er sich aus einer Auswahlliste ein Spieltyp selektieren und die Spielerzahl mit angeben. Um zu sehen, welche Partien bereits erstellt wurden, wird eine Liste benötigt, über die man eine Spielpartie selektieren kann um dieser beizutreten, oder sie zu beobachten. Aus der Liste muss ersichtlich sein, um welchen Spieltyp es sich handelt, wie viele Spieler der Spieltyp erfassen kann, wie viele bereits zu dieser Spielpartie beigetreten sind und wie der momentane Spiels tatus ist. Der Status soll Information über den momentanen Zustand der Spielpartien in Form von ‚offen’, ‚läuft’ oder ‚beendet’ liefern. Diese Liste muss immer aktuell gehalten werden. Dies kann automatisch vom Programm nach interner Zeitvorgabe, oder vo m Benutzer manuell erledigt werden. Hat man eine Partie erstellt oder ist zu einer erstellten Spielpartie beigetreten, soll man in eine Art ‚Warteraum’ geführt werden, in dem man die Partie auch wieder verlassen kann. Auch im Spiel selber muss die Möglichkeit bestehen, das laufende Spiel wieder verlassen oder den Client komplett beenden zu können. Hierbei ist eine ständige Aktualisierung der erforderlichen Spieldaten und die Reinigung des JavaSpace-Servers notwendig. Die wichtigste Anforderung liegt jedoch in der dynamischen Integration bzw. Objekt-Instanzierung eines neuen oder ausgewählten Spiels (Instanzierung bedeutet die Erzeugung von realen Instanzen (Objekten)). Hierbei ist zu beachten, dass die Datenhaltung so einfach wie möglich gehalten wird, um eine spätere problemlose Integration eines neuen Spiels zu gewährleisten. Der Nutzer des Clients soll die Integration nicht bemerken. Er muss seinen Client keinem Update unterziehen, um das neue Spiel nutzen zu können. Genau an dieser Stelle liegt der Kernpunkt dieses Projekts. Es soll gezeigt werden, wie mit Hilfe der Eigenschaften von Jini und JavaSpaces eine solch komplexe Anwendung einfach erstellt werden kann. Am Ende der Arbeit soll eine Anleitung verfasst werden, die die Integration eines neuen Spiels so einfach wie möglich beschreibt.

Im Laufe der Projektarbeit mussten einige Abgrenzungen und Festlegungen getroffen werden, um den Umfang der Anwendung zu reduzieren bzw. die Funktionalität eindeutig beschreiben zu können.

Der Initiator einer neu erzeugten Spielpartie erhält immer die Spielernummer eins. Dieser Spieler soll das Spiel eröffnen und den ersten Zug tätigen. Wird ein laufendes Spiel verlassen oder freiwillig beendet, sollen alle beteiligten Mitspieler eine Nachricht bekommen und die Verbindung wird getrennt. Hier geht keiner als Gewinner oder Verlierer aus der Partie. Handelt es sich um Spiele wie z.B. TicTacToe oder Schach, bei denen eine feste Spielerzahl von zwei vorgegeben wird, soll die Spielerzahl als ‚fixed’ gesetzt werden. Hier darf der Anwender die Spieleranzahl nicht verändern können. Hat das ausgewählte Spiel seine Höchstspielerzahl erreicht, soll es automatisch gestartet werden. Die Speicherung und Kommunikation der benötigten Spieldaten soll ausschließlich mit Jini und einem JavaSpace-Server geschehen. Um die einzelnen Spiele untereinander zu unterscheiden, muss dem jeweiligen Spieltyp eine eindeutige Spielnummer (ID) mitgegeben werden. Die Initialisierung dieser ID soll genau einmal erfolgen. Die ID sollte daher in einem separaten-Entry (s.h. Punkt 2.3.2) abgespeichert werden. Auch bei späterer Spielintegration muss die Information des Spieltyps wegen der Aktualisierung des Clients in einem separaten-Entry festgehalten werden. Ist der JSS nicht verfügbar bzw. ‚abgestürzt’, muss dies geschickt abgefangen werden und der Client soll eine Nachricht an den Anwender senden.

Das zu entwickelnde System soll auf allen gängigen Betriebssystemen laufen. Aus diesem Grund soll die Anwendung in Java programmiert werden. Die Benutzerschnittstelle soll mit einer Auflösung von 800 x 600 Bildpunkten noch voll darstellbar sein. Auf dem Client-Rechner müssen Java und Jini fertig konfiguriert vorhanden sein. Auf der Serverseite müssen folgende Dienste zur Datenübertragung und Kommunikation laufen:

Eine genaue Anleitung zur Inbetriebnahme der einzelnen Dienste ist auf ^{http://wwwmath.uni-muenster.de/u/versys/courses/SoSe2001/VS/EXAMPLES/Installation.pdf} zu finden.

Das System muss innerhalb der angegebenen Projektfrist von einem Semester einsatzbereit sein. Die Entwicklungsumgebung ist vom Programmierer der Anwendung bereit zu stellen und zu konfigurieren. Die Entwicklung des Systems soll von Zuhause aus erledigt werden. Die Testläufe können im Projektraum an der Fachhochschule Trier ausgeführt werden. Parallel sind ständige Absprachen mit dem Auftraggeber notwendig, welche wöchentlich stattfinden können. Hierbei ist dem Auftraggeber eine Ausarbeitung der letzten Woche schriftlich oder am Rechner vorzuführen. Parallel zur Entwicklung des Systems, muss ein Pflichtenheft/Dokumentation geführt werden, welches bei Fertigstellung des Projekts dem Auftraggeber ausgehändigt werden muss.

3.2.3 Qualitative Anforderungen

Die Anwendung soll eine übersichtliche Benutzerschnittstelle haben. Weiterhin soll die Software leicht änderbar und erweiterbar sein. Das System soll Vertraulichkeit und Sicherheit gewährleisten. Weitere Spiele sollen ohne Schwierigkeiten integrierbar sein. Da es sich hierbei um eine verteilte Anwendung handelt, müssen Rechnerabstürze oder Serverausfälle berücksichtigt werden. Die Performance soll im Hinblick auf eine eventuell große Benutzeranzahl ausreichend sein.

Hier soll darauf geachtet werden, dass keine unnötigen Attribute verwendet werden und dass die Namensgebung aussagekräftig ist. Die Anwendung soll die Eigenschaft besitzen, ohne großen Aufwand erweitert werden zu können. Dies stellt eine große Herausforderung dar, weil die Daten sowohl für Schach als auch für Skat oder andere Spiele geeignet sein müssen. Man muss spielerspezifische Daten, wie zum Beispiel die Spielernummer, ablegen können. Jeder Spieler, der dem Spiel beitritt, muss eine eindeutige Spielernummer zugeteilt bekommen.

Die maximale Anzahl der Mitspieler muss für den ausgewählten Spieltyp bei der Erstellung des Spiels abgespeichert werden. Außerdem muss eine Grenze vorhanden sein, die Auskunft darüber gibt, wann der letzte der Maximal zulässigen Mitspieler eines Spieltyps eingetroffen ist. Wird nun die ‚Beitrittsgrenze’ erreicht, muss das Spiel als ‚Voll’ deklariert werden. Dazu reicht ein Wahrheitswert aus. Auch um das Spielende festzuhalten reicht ein Wahrheitswert, der sagt, ob das Spiel zu Ende ist oder nicht. Um auf ein bestimmtes Spieldatenobjekt zugreifen zu können, muss dies durch eine eindeutige ID gekennzeichnet sein. Man soll ein bestimmtes Spiel aus einer Liste selektieren können, um es zu spielen. Hier muss der Spielname als String angegeben werden, über den man auch später die Klasse identifizieren muss. Daher hat der Spielname ebenso wie die ID eine wichtige Rolle und kann nicht vernachlässigt werden. Eine der wichtigsten Attribute ist der Spielstatus. Der Spielstatus gibt den aktuellen Zustand des laufenden Spiels an. An dieser Stelle muss abstrahiert werden, da es verschiedene Spiele geben kann, die man vorher nicht kennt. Dieser Sachverhalt ist unter Punkt 4.9.2 nachzuschlagen. An dieser Stelle nehmen wir an, dass wir ein Objekt des Typs ‚SpielStatus’ abspeichern müssen. Zur Spielkoordination muss eine Variable bereitgestellt werden, die sagt, welcher Spieler gerade am Zug ist.

Zusammenfassend werden folgende Anforderungen an die Daten gestellt:

? Eine eindeutige Spiel-ID ? Dynamisch zugeteilte Spielernummer ? Der Spielname des Spiels ? Der Spielstatus des jeweiligen Spiels ? Anzahl der maximalen Mitspieler ? Spieler, der am Zug ist

? Maximale Mitspieleranzahl einer Spielpartie ist erreicht ? Eine Spielpartie ist beendet oder nicht