Aufgabe 1

Mit der Einführung von JDK 1.2 wird ein 100% pure Java Object Request Broker Java IDL mitgeliefert, der mit jedem CORBA konformen ORB interoperieren kann. Java IDL ist ein freies Produkt von Sun, das einen light-weight ORB, einen Naming-Service und einen IDL-Compiler für Java beinhaltet. In Java IDL sind nur wenige Funktionalitäten implementiert. Für die Entwicklung einer kleinen verteilten Client/Server-Anwendung, wie wir sie in diesem Praktikum durchführen, reicht Java IDL aus (Hier ein Hello World Beispiel für Java IDL). Für größere Anwendungen stehen freie Implementierungen (z.B. Mico (C++, TCL) oder auch JacORB (Java); Mico ist im Labor installiert, dazu hier ein kleines Tutorium, und hier ein Beispiel im WWW für die Verknüpfung beider ORB's) und kommerzielle Produkte von verschiedenen Herstellern zur Verfügung. Als Untesrtützung für den Umgang mit C++ kann z.B. dieses Dokument genutzt werden: Von Java nach C++ von Thomas Willhalm. Bei der compilierung von Mico kann es bei den aktuellen gnu-Compilern zu Problemen kommen, u.a. kann man hier für Ubuntu Hilfe erhalten.

Lesen Sie sich die Aufgabenstellung sorgfaltig durch, damit nicht evtl. aufrgund einer Nachlässigkeit die erfolgreiche Bearbeitung gefährdet ist!

Teil 1: Vorbereitung

In Mico gibt es ein Beispiel, um die Interoperabilität zwischen Java IDL und Mico zu testen (zu finden bei Mico im Ordner demo). Leider werden die Beispiele von den Anbietern nicht gewartet, so dass sie unter Umständen nicht mehr ausführbar sind. Verwenden Sie daher die komprimierte Datei demo.zip, da diese im Labor funktioniert. Ihr PC ist zunächst unter Linux zu starten, da Sie den C++-Compiler von Mico (mico-c++) benötigen. Arbeiten Sie zur Vorbereitung auf das Praktikum die Beispiele in den Ordnern interop/jdk und interop/jdk_naming durch (unbedingt README Dateien lesen). Ggf. sollten Sie die Beispiele zum vertiefenden Verständnis im Labor zum Laufen bringen, wenn möglich, auch auf mehrere Rechner verteilt; z.B. ein Rechner für den Namensdienst, einen für den Client und ein Dritter für den Server.
 
Die Beispiele sind sehr wichtig, da sie den Rahmen für die erste und zweite Praktikumsaufgabe stellen!

Wenn Sie das erste Beispiel ausführen wird in der Datei account.ref eine IOR direkt zur Verfügung gestellt. Diese können Sie sich mittels des Tools iordump (in mico/tools/iordump) in "lesbarer Form" anzeigen lassen. In meinem pub (oder im WWW) finden Sie auch eine Version für Windows.

Teil 2: Message of the Day

Implementieren Sie eine kleine eigene Client/Server-Anwendung; ein Server verwaltet Nachrichten (Textzeilen): die Nachrichten des Tages, die von unterschiedlichen Clients (den Redakteuren) ihm zugesendet werden. Diese Nachrichten sind eindeutig nummeriert. Clients fragen in bestimmten Abständen als Leser die aktuellen Nachrichten ab. Damit ein Client nicht immer alle Nachrichten erhält, erinnert sich der Server an einen Client und welche Nachricht er ihm zuletzt zugestellt hat. Meldet sich dieser jedoch eine gewisse Zeit lang nicht, so vergisst der Server diesen Client. Im Nachfolgenden die detaillierte Beschreibung. 

Funktionalität

Server

  1. Ein Client bekommt auf Anfrage gemäß Nachrichtennummerierung eine noch nicht an ihn ausgelieferte und beim Server bekannte Textzeile geliefert. In einem Flag wird ihm mitgeteilt, ob es noch weitere, für ihn unbekante Nachrichten gibt.
  2. Ein Client, der seit ** Sekunden keine Abfrage mehr gemacht hat, wird beim Server vergessen (unabhängig davon, wann er die letzte Textzeile als Redakteur übertragen hat!), also dort gelöscht. Bei einer erneuten Abfrage (nach dem Vergessen) wird er wie ein unbekannter Client behandelt.
    Der timeout von ** Sekunden ist für alle Clients gleich und wird über die GUI des Servers gesetzt.
  3. Der Server hält nur die letzten *** Textzeilen vor. Alle anderen werden gelöscht. Die Anzahl der Textzeilen *** wird dem Server beim Start oder per GUI übergeben. 
  4. Die Textzeilen werden vom Server durchnummeriert (beginnend bei 0) und stellen eine eindeutige ID für jede Textzeile dar. Ein Client hat sich beim Server vor dem Versenden einer Textzeile diese Nummer zu besorgen!
    In der Zustellung einer Nachricht an den Server ist diese Nummer jeder Textzeile voranzustellen (rechtsbündig ohne führenden Nullen, sondern mit führenden blank), d.h. die Nummer wird der Textzeile einfach vorne (als vier Zeichen langer Text) an gestellt resultierend in einer neuen Textzeile. Als Vereinbarung werden vier Zeichen dafür reserviert (ggf. wird bei Null wieder angefangen zu zählen). Der Server merkt sich nicht, von wem eine Textzeile gesendet wurde, insbesondere schaut er nicht in die Textzeile hinein!
    Der Server fügt einer empfangenen Nachricht die Empfangszeit vorne an.
  5. Da die Textzeilen bzgl. der Nummerierung in zusammenhängender Reihenfolge erscheinen sollen und Nachrichten mit Textzeilen verloren gehen können bzw. in nicht sortierter Reihenfolge eintreffen können, arbeitet der Server intern mit einer Deliveryqueue und einer Holdbackqueue. In der Deliveryqueue stehen die Nachrichten, die an Clients ausgeliefert werden können, maximal *** viele Textzeilen. In der Holdbackqueue stehen alle Textzeilen, die nicht ausgeliefert werden dürfen, d.h. zwischen der größten Nummer in der Deliveryqueue und der kleinsten Nummer in der Holdbackqueue fehlt mindestens eine Nummer. Der Server fügt nach einem timeout (3 Sekunden) oder einem zugrossen Abstand der Nummern (letzte gelieferte Textzeilennummer - letzte auslieferbare Textzeilennummer > 10) eine Fehlertextzeile in die Deliveryqueue ein, etwa: >>>>>>Fehler: >>>>Nachricht 4 vermisst (8): 20:32:53,750, damit die Holdbackqueue eingetroffene Textzeilen an die Deliveryqueue übertragen kann. Sollte die vermisste Nachricht jedoch noch rechtzeitig vor dem Löschen eintreffen, ersetzt der Server (sofern vorhanden) die Fehlertextzeile in der Deliveryqueue durch die neue Nachricht.
  6. Der Server terminiert sich, wenn die Differenz von aktueller Systemzeit und Zeit der letzten Abfrage eines Clients länger als seine Wartezeit beträgt, d.h. seine Wartezeit wird durch Abfragen der Clients erneut gestartet bzw. bestimmt die maximale Zeit, die der Server "ungenutzt" läuft. Der Server meldet sich beim Namensdienst vor der Terminierung ab!
  7. Dieser Dienst wird unter dem Namen Messages bei dem Namensdienst registriert.
  8. Der Server ist in Java zu implementieren und muss auf jedem Rechner im Labor startbar sein! Erzeugen Sie dazu eine ausführbare Datei! (Ein Ordner mit den zugehörigen *.class Dateien reicht aus, es muss keine *.jar erzeugt werden, siehe hierzu z.B. ein Tutorial von Sun: jar-Tutorial. bzw. jar cvfm <jar-dateiname> Manifest.txt *.class broadcast/*.class).

Client

  1. Ein Client sendet in bestimmten Abständen, d.h. alle **** Sekunden, eine Textzeile an den Server, die seinen Namen (sein Rechnernamen (zB lab18), die Praktikumsgruppe (zB 1) und die Teamnummer (zB 03), also "lab18103" beinhalten) und seine aktuelle Systemzeit (die der Sendezeit enstprechen soll) beinhaltet und ggf. anderen Text, zum Beipiel "lab18103 Client 10:33:40 Nachrichteninhalt". Der Abstand von **** Sekunden wird bei der Initialisierung des Clients (z.B. beim Aufruf) gesetzt und nach dem Senden von 5 Textzeilen jeweils um ca. 50% (mindestens 1 Sekunde) per Zufall vergrößert oder verkleinert. Die Zeit **** darf nicht unter 1 Sekunde "rutschen". 
  2. Der Client fragt nach dem Senden von 7 Textzeilen solange aktuelle Textzeilen beim Server ab, bis er alle erhalten hat,d.h. alle bisher noch nicht erhaltene und beim Server noch vorhandene Textzeilen, und stellt sie in seiner GUI dar. Dabei gelten die vom Client gesendeten Textzeilen als bei diesem Client unbekannte Textzeilen! Alle unbekannten Textzeilen werden ihm also einzeln übermittelt bzw. pro Anfrage erhält er nur eine unbekannte Textzeile.
  3. Bei der Initialisierung des Clients (z.B. beim Aufruf) wird seine Lebenszeit gesetzt. Ist diese Zeit erreicht, terminiert sich der Client selbst. 
  4. Der Client ist in C++ zu implementieren und muss auf jedem Rechner im Labor startbar sein! Erzeugen Sie dazu eine ausführbare Datei!

GUI

  1. Server-GUI:
    1. Der Server hat eine GUI über die die benötigten steuernden Werte gesetzt werden; diese sind zumindest der timeout für das löschen von Clients und die Warteszeit des Servers, nachdem der letzte Client Textzeilen abgefragt hat. 
    2. In der Server-GUI sind zumindest die letzten 15 erhaltenen Textzeilen und alle aktuell bekannten Clients darzustellen. 
    3. Bei den Textzeilen (die deren ID bzw. Nummer beinhaltet) ist deren Ankunftszeit beim Server mit auszugeben. (z.B. mittels java.text.SimpleDateFormat) 
    4. Bei den Clients ist deren letzte Zugriffszeit (im Sinne der Abfrage der Textzeilen!) mit auszugeben.
    5. Diese Ausgaben sind ebenfalls alle in eine Datei Server.log zu schreiben.
  2. Client-GUI
    1. Der Client hat eine GUI (Standardausgabe reicht).
    2. Die GUI zeigt die Textezeilen an, die vom Server gesendet werden inklusive seiner Abfragezeit (Sendezeitpunkt der Serveranfrage).
    3. In der GUI ist anzuzeigen, wenn der Client eine Textzeile an den Server überträgt. 
    4. Alle Ausgaben sind ebenfalls in eine Datei client<Clientname>.log , wobei <Clientname> der Name des Clients ist (z.B. clientATlab22103.log), zu schreiben. 

Fehlerbehandlung

  1. Wann immer die Besorgung einer IOR schief geht, ist eine Fehlermeldung auszugeben und auch in der zugehörigen Protokolldatei zu vermerken. Handelt es sich um den Namensdienst, beenden sich die Prozesse. Handelt es sich um den Server, wartet der Client eine bestimmte Zeit und vertsucht es dann nochmal. Tritt  wieder ein Fehler auf, beendet er sich (mit Fehlermeldung!).
  2. Tritt während dem Lauf ein Fehler in der Kommunikation mit dem Server auf, erzeugt der Client eine entsprechende Fehlermeldung, die auch in der zugehörigen Protokolldatei zu vermerken ist. Er besorgt sich dann beim Namensdienst eine neue IOR. Tritt dieser Fehler insgesamt während der Lebenszeit des Clients öfters als 10-mal auf, terminiert sich der Client mit einer entsprechenden Fehlermeldung.

IDL

Die folgende IDL beschreibt die Schnittstelle des Servers für die Clients.

module broadcast{
        interface messages {
                /* Abfragen aller Nachrichten */
                string getmessages(in string rechnerid, out long msgID, out boolean getall);
                /* Senden einer Nachricht */
                long dropmessage(in string message, in long msgID);
                /* Abfragen der eindeutigen Nachrichtennummer */
                long getmsgid(in string rechnerid);
        };
};

getmessages: Fragt beim Server eine aktuelle Textzeile ab. rechnerid stellt den eindeutigen Namen des rufenden Clients dar. Dieser besteht aus der Zeichenkette des Rechneres, z.B. "lab18", der Praktikumsgruppe (1, 2 oder 3) und der Teamnummer (zu erfragen, z.B. 03), z.B. "lab18203". Als Rückgabewert erhält er eine für ihn aktuelle Textzeile zugestellt. In der Variabln msgID steht die Nachrichtennummer und in der Variablen getall signailiert der Server ihm, ob noch für ihn aktuelle Nachrichten vorhanden sind.getall.value = false bedeutet, es gibt noch weitere aktuelle Nachrichten, getall.value = true bedeutet, dass es keine aktuellen Nachrichten mehr gibt, d.h. weiter Aufrufe von getmessages sind nicht notwendig.

dropmessage: Sendet dem Server eine Textzeile, die den  Namen des aufrufenden Clients und seine aktuelle Systemzeit, die durch eine 6-stellige Zahl repräsentiert wird (hh:mm:ss), und ggf. irgendeinem Text beinhaltet, sowie die zugeordnete (globale) Nummer der Textzeile (long msgID). In message sind also der Name, die Systemzeit und irgendein Text (als Nachricht des Clients) als eine Zeichenkette zusammengefasst, z.B. "lab18203 10:33:40 Zummsel". Es gibt keine definierten Trennungssysmbole. Als Rückgabewert erhält er einen Fehlercode, mit 1 = OK und 0 = error.

Tipp

Verwenden Sie die Dateien aus Teil 1 und passen Sie diese an, insbesondere die Dateien von C++. Damit Sie die Betreuung z.B. zur Klärung von Fragen nutzen können und damit Sie die Befragung am Anfang des Praktikums erfolgreich absolvieren können, ist die Aufgabe gut vorzubereiten! (Siehe hierzu die PVL-Bedingung). Zum Testen können Sie eine beispielhafte Lösung verwenden, die fast überall lauffähig ist: exeFile.zip. Zum Austesten gibt es hier ein Paket von Dummies, d.h. von Server und Client, die ohne Funktionalität sind: Dummies.zip. Lesen Sie zum Starten die README Dateien. Beachten Sie bitte: damit Sie mit dem Programm arbeiten können, bevor Sie das Labor kennen lernen, ist der Client hier in Java gehalten! Sie müssen ihn jedoch in C++ implementieren!

Ein Hinweis zu dem IDL-Datentyp string: Dieser wird als char* in C++ übersetzt und stets mit NUL beendet. Hinweise zur Programmierung finden Sie hier (*.pdf, OMG Quelle, Abschnitt 1.7 Mapping for String Types). Dies zeigt, dass Zeichenketten stets ein kleines Problem mit sich bringen und daher mit Vorsicht behandelt werden sollten.

Halten Sie das System einfach und strukturiert! Wenn die Kernfunktionalität erstellt wurde, kann das System immer noch beliebig erweitert/verbessert werden.

Das Praktikum wird von Kollegen Hartmut Schulz mitbetreut, der auf seinen WWW-Seiten weitere Informationen zu den Aufgaben hat!

Abnahme

Da die Aufgaben des VSP sehr frühzeitig im WWW zur Verfügung stehen, wird die Abnahme stark auf eine vorbereitende Arbeit aufgebaut. Erfahrungen aus den letzten Praktika haben gezeigt, dass sonst erhebliche Nacharbeiten stattfinden und dadurch eine wesentliche zeitliche Verzögerung bewirkt wird, die zu einem erhöhten Arbeitsaufkommen gerade vor den Prüfungswochen führt.
 
Bis Montag Abend vor Ihrem Praktikumstermin ist ein erster Entwurf für Teil 2 der Aufgabe als *.pdf Dokument mir per E-Mail über den Verteiler abgabe_aivsp@ zuzusenden. Ggf. können offene Fragen mit gesendet werden. Geben Sie bitte auch an, wer zu Ihrem Team dazu gehört (inklusive E-Mail Adresse!). Der Entwurf darf keinen Code beinhalten, da er nicht in dieser Detailebene "angesiedelt ist". Folgende Fragen sind dort als Minimum zu benatworten: mit welchen ADT's sollen die Holdbackqueue, die Deliveryqueue und die Liste der Clients beim Server realisiert werden und warum erfüllen sie ihre Aufgabe? Wie werden timeouts geprüft (lazy oder eager) ? Wie wird festgestellt, dass Fehlertextzeilen zu erstellen sind ? Zudem muss der Entwurf bzgl. des aktuellen Standes der Entwicklung die Klassendiagramme beinhalten. Der Entwurf ist für die PVL wichtig: sollten die Abgabefrist und/oder die erforderlichen Inhalte nicht eingehalten bzw. erbracht worden sein, gilt die Aufgabe als nicht erfolgreich bearbeitet!
 
Zwischen 08:15 und 09:00 findet am Tag des Praktikums eine Befragung von Teams statt. Die Befragung muss erfolgreich absolviert werden, um weiter am Praktikum teilnehmen zu können. Ist die Befragung nicht erfolgreich, gilt die Aufgabe als nicht erfolgreich bearbeitet. Als erfolgreich wird die Befragung bewertet, wenn Ihre Kenntnisse eine erfolgreiche Teilnahme an dem Praktikumstermin in Aussicht stellen.

Zwischen 10:45 und 10:55 haben Sie selbst einen Eingangstest durchzuführen, der darüber entscheidet, ob Sie an einer Vorführung teilnehmen können. Achtung: ein Nachholtermin für das gesamte Praktikum bzw. die Vorführung ist nicht vorgesehen!
Zwischen 10:55 und 11:25 findet eine gemeinsame Vorführung statt. Bei der Vorführung wird per Zufall ausgewählt, welcher Server eines Teams zum Einsatz kommt. Alle Teams (auch dasTeam, das den Server gestartet hat) haben ihre Clients zu starten.

Zwischen 11:25 und 11:30 findet ggf. eine Befragung von Teams zu ihrem Code statt. Diese muss erfolgreich absolviert werden, um weiter am Praktikum teilnehmen zu können. Ist die Befragung nicht erfolgreich, gilt die Aufgabe als nicht erfolgreich bearbeitet.

Abgabe: Unmittelbar am Ende des Praktikums ist von allen Teams der Code abzugeben. Zu dem Code gehören die Sourcedateien und die *.log Dateien, die während der Vorführung erzeugt wurden sowie die *.log Dateien, die beim Eingangstest erzeugt wurden! Bitte beachten Sie: es muss klar sein, welche *.log Dateien zu welcher Vorführung bzw. zu welchem Test gehören!

Im Code ist zu kommentieren, wo die oben aufgeführten Punkte umgesetzt wurden! Zudem ist zu beschreiben, wie das Programm gestartet wird. Die Abgabe gehört zu den PVL-Bedingungen und ist einzuhalten, terminlich wie auch inhaltlich!

Wird eine Aufgabe nicht erfolgreich bearbeitet gilt die PVL als nicht bestanden. Damit eine Aufgabe als erfolgreich gewertet wird, müssen beide Befragungen, der Eingangstest sowie die Vorführung als erfolgreich gewertet werden. Zudem muss der Entwurf wie auch die Abgabe korrekt durchgeführt worden sein. Alle gesetzten Termine sind einzuhalten. Dies ist notwendig, da aufgrund der Größe der Praktikumsgruppen sonst erhebliche zeitliche Verzögerungen entstehen würden. 



gratis Counter by GOWEB
Gratis Counter by GOWEB