Client/Server Netzwerk Programmierung mit Esprit

Transkript

1 Client/Server Netzwerk Programmierung mit Esprit Übersicht über die Möglichkeiten der Agenten-basierten Client/Server Programmierung mit dem Esprit-Server November 2015 Rainer Buesch

2 Inhaltsverzeichnis 1 Einführung Esprit Software Funktionsprinzip Zeiw-Kanal-Verbindung Client-Sessions Asynchrone Requests Agenten Laufzeitumgebungen Einfacher Agent Fehlerbehandlung Asynchrone Agenten Abbruch asynchroner Agenten Worker und Sleeper Agenten Timeouts asynchroner Agenten Hintergrund-Agenten Parallelprozessing auf Client und Server Sequenzierte Agenten Agenten mit Teilergebnissen Gezippte Argumente Zugriff mit Sperren Prozessing-Methoden von Agenten GUI Aktionen mit Agenten Standard Agenten Agenten für Datenbank-Zugriffe File Agenten File-Transfer Agent Stream Download Agent Message Agenten Model-View-Controller Prinzip über Netz Server-Modelle PositionServerModel Clientseitiger Controller Clientseitiger View Große Server-Modelle Alive Business Objects Client-Zugriff auf Alive Business Objekte Komplexe Modelle im Server Server Kaskadierung Zusammenschalten von Servern Weiterreichen von Agenten Architektur des Esprit-Servers Skalierbarkeit Erweiterbarkeit

3 6.3 Logfile Management Log-Dateien Log-Kanäle Automatische Log Bereinigung Zeitgesteuerte Server-Prozesse Datenbank-Verbindungen Server Aktivität Server-Statistik Resource-Sperren Agenten-Verwaltung Laufende File-Transfers Benachrichtigung Session-Liste Co-Server Verbindungen Benutzer-Verwaltung Passwort Vergabe Benutzer Login Kundenspezifische Benutzerverwaltung Architektur des EsprIT Clients Verbindung zum Server Software Update Login Reconnect Message Empfänger Schnittstelle zu Betriebssystemprozessen Steuerung von Clients (mit Down-Requests) Synchrone Down-Requests Down-Requests an viele Clients Asynchrone Down-Requests Client Aktivitäts-Monitor Workflows Ablauf von Workflows Parallel laufende Workflows Serverseitige Workflows Fazit Client/Server Lastverteilung Komplexe prozedurale Abläufe Agenten als Programmierschnittstelle Echtes MVC über Netz Lebende Business-Objekte Rich-Client oder Web-Client? Weitere Informationen

4 1 Einführung Dieses Dokument beschreibt die Funktionsweise des Esprit-Servers, sowie die neue Art der Agenten-basierenden Client/Server Programmierung wie sie mit dem Esprit-Server möglich ist. Die folgenden Ausführungen erheben keinen Anspruch auf Vollständigkeit. Vielmehr geht es darum, dem Leser ein Grundverständnis für die Esprit-Technologie zu vermitteln und ihm eine Übersicht über deren Möglichkeiten zu geben. 1.1 Esprit Software Durch seine besondere Architektur bietet der Esprit-Server Möglichkeiten, die mit herkömmlichen Middleware-Servern nicht oder nur sehr schwer realisierbar sind. Durch den integrierten Message-Service ist er in der Lage, Clients dynamisch über Änderungen aller Art (z.b. in der Datenbank) zu benachrichtigen. Alle Clients werden so ohne eigenes Zutun stets auf dem aktuellsten Stand gehalten. Jegliches sonst übliche Server-Polling entfällt. Die Kommunikation zwischen Client und Server geschieht über sog. Agenten. Dies sind intelligente Austauschobjekte, die Daten übertragen und Funktionen ausführen können. Mit der Agenten-basierenden Programmierschnittstelle können Client/Server Systeme extrem schnell, einfach und robust entwickelt werden, bei bestmöglicher Performance. Ein spezieller Transfer-Kanal erlaubt den Austausch großer Datenmengen zwischen Client und Server, ohne die sonstigen Funktionen zu stören. Über einen zusätzlichen Web-Kanal können auch HTML-Dokumente oder Bilddaten abgerufen werden. Nicht zuletzt dient er der zur dynamischen Aktualisierung der Client-Software. Besondere serverseitige ABO-Objekte (Alive Business Objects) erlauben allen Clients eine einheitliche Sicht der Welt. Änderungen an solchen Objekten werden automatisch an alle Clients kommuniziert, die so - ohne selbst aktiv werden zu müssen - stets auf dem aktuellsten Stand sind. Wegen dieser besonderen Merkmale ist der Esprit-Server ideal zur Unterstützung von Rich-Clients (z.b. mit Swing oder JavaFX GUI) geeignet. Die Esprit Software beinhaltet den EsprIT Middleware-Server, sowie ein umfangreiches Framework zur Entwicklung von Client/ServerLösungen. Als pure Java Software ist sie auf allen Plattformen lauffähig. 1.2 Funktionsprinzip Zeiw-Kanal-Verbindung Eine wesentliche Besonderheit des Esprit-Servers besteht darin, dass Clients eine Doppelverbindung über einen TCP Netzwerk-Port aufbauen: Request/Response-Verbindung Über diese Verbindung kann der Client Anfragen (Requests) absetzen und erhält eine entsprechende Antwort (Response). Die Abarbeitung des Requests geschieht synchron, d.h. der Client blockiert solange, bis er die Antwort erhalten hat. Message-Verbindung Über diese Verbindung empfängt der Client vom Server asynchrone Nachrichten (Messages). Damit ist der Server in der Lage, alle verbundenen Clients über Veränderungen (z.b. in der Datenbank) zu benachrichtigen. Inkonsistenzen werden so von vornherein vermieden. -4-

5 1.2.2 Client-Sessions Beide Netzwerkkanäle werden vom Server gemeinsam als jeweils eine Client-Session verwaltet. Da es sich um eine stehende TCP-Verbindung handelt, gibt es keine Verzögerungen durch vielfachen Verbindungs-Auf/Abbau. Ausgehende Client-Anfragen und eingehende Server-Nachrichten können problemlos zeitlich überlappen. Requests/Responses sowie Messages können jeweils ein beliebiges Objekt als Argument (siehe: Agenten) transportieren. So geschieht der Datenaustausch zwischen Client und Server sehr einfach und performant. Bild 1) Die Verbindung des Clients zum Esprit-Server besteht aus einem Request/Response-Kanal, sowie einem Message-Kanal für asynchrone Server-Nachrichten. Ein Kanal für den Massendaten-Transfer sowie ein Webserver-Kanal werden bei Bedarf hinzugeschaltet Asynchrone Requests In einem Request kann der Client dem Server mitteilen, dass er die Antwort gerne per Nachricht zugeschickt bekommen möchte. Auf diese Weise funktionieren asynchrone Requests. Der Client muss dann nicht blockierend auf die Antwort warten, sondern wird informiert, wenn sie eintrifft. 2 Agenten Agenten sind Objekte (von AbstractAgent abgeleitet), die als Argument eines Request/Response- oder eines Message-Objekts versendet werden. Als Austauschobjekt bilden sie die Schnittstelle zwischen Client und Server. Dabei können sie sowohl Daten übertragen, als auch Funktionen ausführen. 2.1 Laufzeitumgebungen Die clientseitige Laufzeitumgebung wird repräsentiert durch ein ClientContext Objekt, welches die Verbindung zu einem oder mehreren Esprit-Servern kapselt. Es ist das zentrale Objekt, über das der Programmierer Zugriff auf alle anderen Objekte der Clientseite hat. Die Instantiierung eines ClientContext Objekts entspricht dem Verbindungsaufbau zum Esprit-Server. Es können viele ClientContext Objekte in derselben VM (Virtual Machine) existieren. Die serverseitige Laufzeitumgebung wird repräsentiert durch ein ServerContext Objekt, welches den Zugriff auf alle Serverkomponenten gestattet. Die Instantiierung des ServerContext Objekts entspricht dem Starten des Esprit-Servers. Ein Agent kann in beiden Welten existieren. Befindet er sich auf der Clientseite, so hat er Zugriff auf den ClientContext und kann alles tun, was die Client-Software an Möglichkeiten bietet. Befindet er sich auf Serverseite, so hat er Zugriff auf den ServerContext und damit auf alle Serverkomponenten. -5-

6 Der Agent wird auf Clientseite erzeugt und initialisiert. Alsdann wird er zum Server geschickt (Request), wo er ausgeführt wird, indem bestimmte Methoden in ihm aufgerufen werden. Schließlich wird er zum Client zurückgeschickt (Response), wo er nochmals bestimmte Funktionen ausführt (Agenten-Postprocessing). Durch Überscheiben der betreffenden Methoden wird er mit Logik versehen. 2.2 Einfacher Agent Ein einfacher Agent soll die grundsätzliche Funktionsweise demonstrieren. Betrachten wir einen Agenten, der sämtliche auf dem Server konfigurierten Benutzer auf der Client-Konsole ausgibt: public class UserListAgent extends AbstractAgent { private User[] users; public UserListAgent(ClientContext ctx) { super(ctx); // Instantiation on client side public void executeonserver() throws Exception { // executes on server side users = getservercontext().getusermanager().getusers(); public void doonresponsereceived() throws Exception { // executes when received on client side getclientcontext().loginfo(this, users); Der UserListAgent wird auf Clientseite mit dem ClientContext instantiiert und hat deshalb Zugriff auf alle Client-Objekte. Er weiß insbesondere, wie er sich selbst zum Server senden kann. Die Methode executeonserver() wird automatisch auf Serverseite aufgerufen, wenn der Agent dort eintrifft. Die Methode doonresponsereceived() wird automatisch auf Clientseite aufgerufen, wenn der Agent zurückgesendet wurde. Damit ist die gesamte Funktion vollständig im Agenten formuliert. Zum Erzeugen und Ausführen reicht eine einzige Codezeile: new UserListAgent(ctx).sendForExecution(); Der Agent beinhaltet also Code, der zum Teil auf Server- und zum Teil auf Clientseite ausgeführt wird. Damit ist eine Client/Server-Funktion vollständig im Agenten gekapselt, was die Programmierung sehr übersichtlich und den Code leicht wartbar macht. Die Netzwerkschicht bleibt dem Programmierer vollständig verborgen. Was im Kleinen geht, funktioniert auch im Großen - Agenten können beliebige Komplexität beinhalten. Mit der Methode hasrun() kann erfragt werden, ob der Agent schon auf dem Server gelaufen ist. Mit getprocessingduration() erfahren Sie, wie lange die Ausführung gedauert hat. Mit isreceivedinresponse() bzw. isreceivedinmessage() kann erfragt werden, ob der Agent in einer Response oder Message (nur bei asynchronen Agenten) empfangen wurde. Ein einmal benutzter Agent ist sozusagen verbraucht und kann nicht wiederverwendet werden. 2.3 Fehlerbehandlung Sollte bei der Ausführung auf dem Server ein Fehler aufgetreten sein, so kann dieser im Agenten abgefragt werden. Darum braucht sich der Programmierer aber nicht zu kümmern, da dies automatisch von einem im ClientContext konfigurierten ClientErrorHandler erledigt wird. Letzterer -6-

7 erzeugt defaultmäßig einen Fehler-Dialog um dem Benutzer das Problem anzuzeigen. Sollte eine andere Fehlerbehandlung gewünscht sein, dann kann ein kundenspezifischer ClientErrorHandler im ClientContext hinterlegt werden. Alternativ dazu ist die automatische Fehlerbehandlung des Agenten individuell abschaltbar (setignoremessageerror(true)), liegt dann aber in der Zuständigkeit des Programmierers. 2.4 Asynchrone Agenten Normalerweise läuft die Ausführung eines Agenten auf dem Server synchron, d.h. die ClientBenutzeroberfläche (GUI) blockiert, bis der Agent in der Response empfangen wurde. Dies ist in Ordnung, solange die Ausführung nur kurze Zeit dauert. Bei zu erwartenden längeren Ausführungszeiten sollte der Agent mit setasync(true) auf asynchrone Ausführung umgeschaltet werden. Er wird dann dem Client nach seiner Ausführung in einer Nachricht zugeschickt. Während dieser Zeit blockiert nicht der gesamte Client, sondern lediglich die Action, die den Agenten abgeschickt hat. Die betroffene GUI-Komponente (Menü oder Schaltfläche) graut solange aus. Würden wir den vorhin formulierten UserListAgent als asynchronen Agenten laufen lassen, dann müssten wir statt doonresponsereceived() die Methode doonmessagereceived() überschreiben, die automatisch aufgerufen wird, wenn der Agent in einer Nachricht empfangen wird. public void doonmessagereceived() throws Exception { getclientcontext().loginfo(this, users); Abbruch asynchroner Agenten Durch das Konzept der asynchronen Ausführung ist es natürlich möglich, dass ein Client viele asynchrone Agenten zum Server schickt, die dort ggf. stundenlang parallel laufen können. Der Client selbst merkt sich, welche Agenten er am laufen hat und kann sie deshalb jederzeit, falls erforderlich, abbrechen. Sollte der Client gänzlich terminiert werden, dann werden automatisch alle seine auf dem Server laufenden Agenten abgebrochen Worker und Sleeper Agenten Würde der Server jeden Agenten akzeptieren, dann liefe er Gefahr, schnell überlastet zu werden. Der Server unterscheidet deshalb nach Worker- und Sleeper Agenten: Worker-Agenten sind typischerweise CPU-intensiv und setzen den Server unter Last. Der Server akzeptiert deshalb nicht beliebig viele solche Agenten, sondern lässt nur eine maximale (dynamisch konfigurierbare) Anzahl wirklich parallel laufen. Weitere Agenten werden abgelehnt. Sleeper-Agenten sind solche, die den Server kaum belasten, da sie die meiste Zeit nur warten und deshalb wenig aktiv sind (z. B: Agenten mit Überwachungsaufgaben). Solche Agenten akzeptiert der Server in beliebiger Anzahl. Ein asynchroner Agent wird defaultmäßig als Worker-Agent angesehen und ist damit grundsätzlich ablehnbar, falls der Server stark belastet ist. Mit setrejectable(false) wird er als Sleeper markiert und deshalb auf jeden Fall akzeptiert. Ob ein Agent ein Worker oder ein Sleeper ist, entscheidet der Programmierer. -7-

8 2.4.3 Timeouts asynchroner Agenten Asynchrone Agenten sollten normalerweise eine bestimmte erwartete Laufzeit nicht überschreiten. Mit setasynctimeout(seconds) kann ein Timeout-Wert vorgegeben werden, nach dem der Server den Agenten automatisch abbricht. Wird der Timeout-Wert nicht gesetzt, gilt ein auf dem Server konfigurierter Defaultwert. Der Wert 0 sagt explizit, dass der Agent ewig laufen darf Hintergrund-Agenten Mit setnoreturn(true) wird ein asynchroner Agent markiert als einer, der nicht mehr an den Client zurückgeschickt werden muss. Der Client vergisst diesen Agenten und kann ihn deshalb auch nicht mehr abbrechen. Ein solcher Agent wird sogar dann weiterlaufen, wenn der Client offline geht, solange also, bis er zu Ende gelaufen ist oder wegen einem definierten Timeout abgebrochen wird. Auf diese Weise kann der Client quasi Hintergrundprozesse auf dem Server laufen lassen Parallelprozessing auf Client und Server Auch einen asynchronen Agenten erhält der Client in Wirklichkeit sofort in der Response wieder zurück, wobei serverseitig in ihm bereits die Methode executeforresponse() synchron aufgerufen wurde. Erst danach beginnt die asynchrone Abarbeitung und schließlich wird er (ggf. viel später) in einer Nachricht von Client empfangen. Der in der Response, sowie der in der Message empfangene Agent können sich ergänzende Ergebnisse beinhalten. Während der Client die Agenten-Nachricht erwartet, kann er die Ergebnisse des Response-Agenten bereits interpretieren und verarbeiten. So wird also auf einfache Weise ein echtes Parallelprozessing auf Client- und Serverseite erreicht Sequenzierte Agenten Asynchrone Agenten können als Ergebnis ihrer Ausführung große Datenmengen beinhalten - man denke nur an eine Datenbankanfrage, bei der sehr viele Datensätze gefunden wurden. Würde man diese alle im Agenten aufsammeln und an den Client schicken, dann bekäme man sowohl auf Server-, wie auf Clientseite ggf. ein ernstes Memory-Problem. Mit einem sequenzierten Agenten (abgeleitet von AbstractSequencedAgent) können die Daten in wohldefinierten Quanten, auf mehrere Agenten-Nachrichten verteilt, übertragen werden. Nach diesem Prinzip arbeitet auch der in der Software enthaltene DBLoadAgent, der asynchron eine beliebige Anzahl Datensätze aus der Datenbank liest Agenten mit Teilergebnissen Normalerweise wird ein Agent, der nach seiner Ausführung auf dem Server einen Fehler beinhaltet, auf Clientseite nicht mehr ausgewertet, stattdessen findet lediglich die automatische Fehlerbehandlung statt. Es gibt aber Fälle, in denen es wünschenswert ist, auch Teilergebnisse auszuwerten, selbst wenn der Agent auf einen Fehler lief. Mit der Einstellung setpartialresultsenabled(true) erreicht man, dass trotz Fehler das normale Agenten-Postprocessing auf Clientseite stattfindet. Angenommen, unser Agent soll eine Reihe von Datensätzen in eine Datenbanktabelle einfügen. Der 25. Datensatz wird aber von der Datenbank wegen einer Constraintverletzung abgelehnt. Der zurückgeschickte Agent beinhaltet nun sowohl die erfolgreich eingefügten Datensätze (inklusive der Primärschlüsselwerte und Defaultwerte, die von der Datenbank vergeben wurden), als auch den betreffenden Fehler. Beides wird auf Clientseite ausgewertet. -8-

9 2.5 Gezippte Argumente Wir möchten einen FileReadAgent schreiben, der den Inhalt einer Server-Textdatei ausliest. Dazu könnte der Agent den Text in einer String-Variablen namens text speichern. Ein Agent bietet per se die Möglichkeit ein beliebiges Argument zu speichern und zwar wahlweise sogar in gezippter Form. Mit setargument(text, true) wird der Inhalt der Variable komprimiert und damit deutlich schneller übertragen. Mit getargument() wird er wieder abgerufen und dabei automatisch dekomprimiert. Dies funktioniert gleichermaßen mit beliebigen Objekt-Argumenten. 2.6 Zugriff mit Sperren Wir möchten die Serverdatei, die wir mit unserem FileReadAgent gelesen haben, auf Clientseite editieren, um sie dann auf dem Server zurückzuspeichern. Dabei bekommen wir einen potentiellen Konflikt mit anderen Benutzern, die vielleicht gerade das gleiche tun wollen. Um dem vorzubeugen können wir die Datei mit einer exklusiven Sperre versehen, die den verändernden Zugriff von anderen Benutzern abblockt. Angenommen file ist die Datei, die wir lesen wollen, so erreichen wir dies folgendermaßen: public void executeonserver() throws Exception { lockexclusive(file); // acquire a resource-lock String text = readfilecontent(file); setargument(text, true); // store as zipped argument Ebenso hätten wir mit lockshared(file) eine shared Sperre belegen können, die verhindert, dass jemand anders die Datei löscht, während wir sie im Zugriff haben. 2.7 Prozessing-Methoden von Agenten Bisher haben Sie die folgenden Methoden kennengelernt, die automatisch in einem Agenten aufgerufen werden: executeforresponse() (nur bei asynchronem Agent) wird in einem asynchronen Agenten auf Serverseite aufgerufen bevor er in der Response an den Client zurückgeschickt wird. Danach erst beginnt die asynchrone Abarbeitung. executeonserver() ist die Haupt-Methode, die den Code beinhaltet, den der Agent auf dem Server ausführt. doonresponsereceived() wird auf dem Client aufgerufen, wenn der Agent in einer Response empfangen wurde. doonresponseconfirmed() wird unmittelbar nach doonresponsereceived() aufgerufen, nachem der Empfang dem Server quittiert wurde. Zu diesem Zeitpunkt kann man sicher sein, dass der Server weiss, dass der Client die Antwort erhalten und gelesen hat. Dieser feine Unterschied spielt bei bestimmten Sychronisierungsanforderungen eine Rolle. doonmessagereceived() (nur bei asynchronem Agent) wird auf dem Client aufgerufen, wenn der Agent in einer Message empfangen wird. Es gibt aber noch einige andere interessante Methoden: doinitiallyonclient() wird auf dem Client aufgerufen, bevor der Agent zum Server abgeschickt wird. -9-

10 dofinallyonclient() wird auf dem Client aufgerufen, nachdem der Agent empfangen wurde. doinitiallyonserver() wird auf dem Server aufgerufen, wenn der Agent vom Server empfangen wird. dofinallyonserver() wird auf dem Server aufgerufen, bevor der Agent zum Client geschickt wird. doonresponseerror() wird auf dem Client aufgerufen, wenn der in der Response empfangene Agent einen Fehler enthält. doonmessageerror() (nur bei asynchronem Agent) wird auf dem Client aufgerufen, wenn der in der Message empfangene Agent einen Fehler enthält. doonserversidecancellation() (nur bei asynchronem Agent) wird auf dem Server aufgerufen, wenn der Agent abgebrochen wurde. doonclientsidecancellation() (nur bei asynchronem Agent) wird auf dem Client aufgerufen, wenn der Agent abgebrochen wurde. Alle diese Methoden sind als Callback-Methoden zum Überschreiben gedacht, um Funktionalität an bestimmten Stellen einzuklinken. Eine Beschreibung der sich daraus ergebenden Möglichkeiten würde den Rahmen dieser Abhandlung sprengen. 2.8 GUI Aktionen mit Agenten Typischerweise werden Agenten durch eine GUI-Aktion (Klick auf eine Schaltfäche oder einen Menü-Eintrag) aktiviert. Um Agenten bequem in ein Swing-GUI einzubinden gibt es die AgentAction Klasse, die im folgenden Beispiel gezeigt wird: public class UserListAction extends AgentAction<ClientContext,UserListAgent> { public UserListAction(ClientContext ctx) { super(ctx, new RawActionKey( Get user list )); public UserListAgent createinputagent() { return new UserListAgent(getClientContext()); Die AgentAction stellt selbst fest, ob es sich um einen synchronen oder asynchronen Agenten handelt und verhält sich entsprechend. Bei asynchronen Agenten blockiert sie solange, bis die Agenten-Nachricht empfangen wurde. Ist die Timeout-Zeit zu zwei Dritteln abgelaufen, wird der Benutzer automatisch gefragt, ob er den Agenten weiterlaufen lassen oder abbrechen möchte. 3 Standard Agenten Hier werden einige der wichtigsten Agenten aus einer umfangreichen Bibliothek bereits existierender Standard-Agenten vorgestellt. Selbstverständlich können diese Agenten als Basis für kundenspezifische Erweiterungen (Ableitungen) herangezogen und entsprechend erweitert werden. 3.1 Agenten für Datenbank-Zugriffe Für den Zugriff auf Datenbanken steht ein Satz spezieller Datenbank-Agenten zur Verfügung. Sie

11 alle nutzen DBObjects als Datenbank-Persistenzschicht. Eine wesentliche Besonderheit dieser Agenten ist, dass sämtliche Datenbank-Änderungen per Nachricht an alle eingeloggten Clients kommuniziert werden, sofern diese ein Interesse dafür angemeldet haben (d.h. sich für RecordChangeEvents registriert haben). Damit ist sichergestellt, dass alle Clients dieselbe Sicht der Daten haben und keine Inkonsistenzen entstehen können. Die Datenbank-Agenten können jeweils einzelne oder mehrere Datensätze bearbeiten. Falls gewünscht, erledigen sie ihre Arbeit in einer Datenbank-Transaktion, nach dem Motto alles oder nichts. Außerdem können sie wie die meisten Agenten wahlweise synchron oder asynchron laufen. DBInsertAgent Dieser Agent fügt Datensätze in eine Tabelle ein. Als Ergebnis beinhaltet der Agent die eingefügten Datensätze und zwar mit den Primärschlüssel- und Defaultwerten, die die Datenbank vergeben hat. DBUpdateAgent/DBDeleteAgent Schreibt Datensätze in die Datenbank zurück bzw. löscht sie, auf Wunsch in einer Transaktion. DBSelectAgent Dieser Agent liest Datensätze aus einer Tabelle gemäß einem vorgegebenen Selektionsfilter und einer definierten Sortierung. Dabei werden alle gefundenen Datensätze in einem einzigen Antwort-Agenten übertragen. DBLoadAgent Dieser Agent arbeitet ähnlich wie der DBSelectAgent, läuft aber in jedem Falle asynchron und ist sequenziert, d.h. er liest die Datensätze in vorgebbaren Blockgrößen und überträgt sie entsprechend aufgeteilt in mehreren Antwort-Agenten an den Client. 3.2 File Agenten Der Server hat ein festgelegtes Basisverzeichnis (Root-Directory), unterhalb dessen er eine Verzeichnisstruktur aufbauen und Dateien ablegen kann. File-Agenten ermöglichen dem Client den kontrollierten Zugriff auf solche Server-Dateien. Ein Zugriff außerhalb des Root-Verzeichnisses ist den Clients nicht möglich. FileReadAgent Dieser Agent liest eine Server-Textdatei und überträgt den Inhalt in gezippter Form an den Client. FileEditAgent Dieser Agent arbeitet ähnlich wie der FileReadAgent. Zusätzlich aber belegt er eine serverseitige Editier-Sperre (siehe: Resource-Sperren), um die gelesene Datei vor Veränderungen von anderen Benutzern zu schützen. FileStoreAgent Dieser Agent schreibt den vom Client veränderten Inhalt einer Datei zurück auf den Server. Für das Zurückschreiben wird eine kurzzeitige exklusive Editier-Sperre vom Server angefordert. Sollte diese bereits an einen anderen Benutzer vergeben sein, kann keine Speicherung erfolgen. 3.3 File-Transfer Agent Dieser Agent überträgt Dateien (binär oder ASCII) vom Client zum Server oder umgekehrt. Die Dateiübertragung wird nicht vom Agenten selbst ausgeführt, sondern geschieht über den speziellen Transfer-Kanal des Servers, sozusagen im Hintergrund, um die sonstige Funktion des Servers möglichst wenig zu beeinträchtigen. Der Agent kontrolliert diesen Vorgang und macht ihn

12 transaktional; dies bedeutet, dass z.b. eine existierende Serverdatei erst dann überschrieben wird, wenn auch wirklich das letzte Byte vom Client empfangen wurde. Der FileTransferAgent kann in einer einzigen Transaktion auch mehrere Dateien zwischen Client und Server übertragen, wobei auch eine Mischung von Uploads und Downloads, also ein transaktionaler Datei-Austausch, möglich ist. Desweiteren können die Dateinamen auf Server- und Clientseite unterschiedlich sein. Dateinamen und Zielverzeichnisse sind frei vorgebbar. File-Transfers lassen sich darüberhinaus verketten mit weiteren Funktionen. Da der Client erfährt, wann die Dateiübertragung fertig ist, kann er darauf reagieren und weitere, davon abhängende Aktionen ausführen. Natürlich hat der Benutzer auch die Wahl, ob der Transfer synchron oder asynchron ausgeführt werden soll. In letzterem Falle steht es ihm frei, den Vorgang jederzeit abzubrechen. Nach einem Abbruch werden bereits übertragene Daten wieder gelöscht, gemäß den Vorgaben einer Transaktion. Nicht zuletzt können auch mehrere File-Transfers parallel laufen. Damit existiert ein allgemeiner Mechanismus für einen flexiblen, transaktionalen Austausch von FileSets, eine Funktionalität, die andere Client/Server Systeme nur mit umständlichen Konstrukten nachbilden können. 3.4 Stream Download Agent Ähnlich wie der FileTransferAgent dient der StreamDownloadAgent dazu, Daten vom Server herunterzuladen. Allerdings werden die Daten nicht auf dem Client gespeichert, sondern direkt beim Auslesen des Datenstroms verarbeitet. Intelligente Parser werten die Daten aus und produzieren direkt die gewünschten Ergebnisse. Im Vergleich zum File-Transfer ist diese Art der Datenverarbeitung deutlich performanter, da die Zwischenspeicherung auf Clientseite entfällt. 3.5 Message Agenten Message-Agenten kommunizieren mit anderen Clients, indem sie die Fähigkeit des Servers nutzen, Nachrichten zu versenden. Eine Nachricht kann gezielt an eine Session, einen Benutzer (der mehrmals eingeloggt sein kann), eine Benutzergruppe oder an alle verbundenen Clients geschickt werden. Der Inhalt einer Nachricht ist ein beliebiges Objekt, das der Empfänger jeweils entsprechend auswertet. Der TextMessageAgent beispielsweise schickt eine Textmeldung an einen oder mehrere Adressaten. Der Empfänger reagiert damit, dass er eine Dialogbox öffnet, in der die Nachricht angezeigt wird. Die EsprIT-Software beinhaltet bereits standardmäßig ein Chat-Tool, mit dem Clients komfortabel direkt untereinander kommunizieren können. Bild 2) Chat-Tool des EsprIT Clients

13 4 Model-View-Controller Prinzip über Netz Das Model-View-Controller Prinzip (MVC) wird üblicherweise in GUIs angewendet, um z.b. die Zustände von GUI-Komponenten zu kontrollieren. Weil es äußerst robust funktioniert, wird es sehr gerne verwendet, war bisher aber auf lokale Anwendungen beschränkt. Da der Esprit-Server einen integrierten Message-Kanal besitzt, ist es mit ihm erstmals möglich, dieses Prinzip auch über Netz zu realisieren. Die sich daraus ergebenden Möglichkeiten sind enorm. Bild 3) Das Model-View-Controller-Prinzip kann nun über Netz realisiert werden 4.1 Server-Modelle ServerModel Instanzen sind zentrale Objekte, die auf Serverseite (typischerweise als Singleton Objekte) existieren. Sie bilden einen Zustand ab, der von Clients life beobachtbar ist. Im folgenden wird ein einfaches Beispiel betrachtet, aber der Komplexität sind hier kaum Grenzen gesetzt. Lassen Sie uns das MVC-Prinzip anhand des Position-Tools, welches im Esprit-Server als Beispiel enthalten ist, gedanklich durchspielen PositionServerModel Grundlage des Prinzips ist das PositionServerModel, abgeleitet von AbstractServerModel, welches in unserem Beispiel eine Position als veränderlichen x/y Wert, speichert. Mit der Methode setposition(x,y) kann dieser Wert verändert und mit getposition() erfragt werden. Der Esprit-Server hält eine Instanz des PositionServerModels im ServerContext vor, die dort beim Start des Servers abgelegt wurde und mit serverctx.getpositionmodel() abrufbar ist. Der Java Code des PositionServerModels sieht folgendermaßen aus: public class PositionServerModel extends AbstractServerModel { private Point currentpos = new Point(0, 0); private PositionServerModel(ServerContext serverctx) { super(serverctx); public synchronized Point getposition() { return currentpos;

14 public synchronized void setposition(sessionid accessorid, Point point) { this.currentpos = point; sendchangeevent(new PositionEvent(accessorId, point)); Wie aus dem Quellcode ersichtlich wird bei jeder Veränderung der Position ein PositionEvent gesendet. Dieses beinhaltet die neue Position, sowie die SessionId des Clients, der die Aktion ausgeführt hat. Man beachte, dass die beiden Methoden getposition() und setposition(x,y) als synchronized deklariert sind. Dies ist wichtig, da im Allgemeinen viele Clients gleichzeitig versuchen könnten, die Position zu verändern. Da jede Client-Aktion im Server in einem anderen Thread läuft, muss der Zugriff synchonisiert erfolgen. Der Quellcode des Events sieht folgendermaßen aus: public class PositionEvent extends AbstractSessionEvent { private final Point point; public PositionEvent(SessionId sessid, Point point) { super(sessid); this.point = point; public Point getposition() { return point; public interface Listener extends GenericEvent.Listener { public void positionchanged(positionevent e); Durch das innere Listener-Interface ist vorgeschrieben, mit welcher Methode ein Client (die ViewKlasse) auf dieses Event zu reagieren hat Clientseitiger Controller Damit ein Client als Controller die Position im PositionServerModel verändern kann, schreiben wir den PositionSetAgent, der folgendermaßen aussieht: public class PositionSetAgent extends AbstractAgent { private final Point newposition; public PositionSetAgent(ClientContext clientctx, Point newposition) { super(clientctx); this.newposition = public void executeonserver() throws Exception { PositionModel model = getservercontext().getpositionmodel(); model.setposition(getsessionid(), newposition); Dieser Agent holt sich die Referenz auf das PositionServerModel aus dem ServerContext, ruft in ihm die setposition(x,y) Methode auf und übergibt dabei die vom Client übertragene neue Position als Argument. Die ebenfalls übergebene SessionId des Clients wird im Modell gespeichert, damit stets nachvollziehbar ist, wer der letzte Zugreifende war. Dieser Aufruf löst, wie oben beschrieben,

15 ein PositionEvent als Nachricht an alle Clients aus, die dann ihrerseits ihre jeweilige Darstellung (View) aktualisieren. Auch der verursachende Controller-Client selbst erhält auf diese Weise die Rückmeldung über die Positionsänderung und aktualisiert sich entsprechend. Der PositionSetAgent wird im Client folgendermaßen erzeugt und abgeschickt: new PositionSetAgent(getClientContext(), newpoint).sendforexecution(); Clientseitiger View Jedem GUI-Programmierer ist vertraut, wie man z.b. eine Schaltfläche mit einer auszuführenden Callback-Funktion koppelt. Dies funktioniert ganz ähnlich mit den über Netz empfangenen Events des Esprit-Servers. Um die jeweils aktuelle Position im Client-GUI anzuzeigen konstruieren wir das PositionLabel, eine einfache JLabel-Komponente, die auf PositionEvents reagiert und die aktuelle Position als Text anzeigt: public class PositionLabel extends JLabel { public PositionLabel(ClientContext ctx) { ctx.getmessagechannel().addneteventlistener(new MyPositionListener()); private void setvalue(point p) { settext(p.getx()+","+p.gety()); private class MyPositionListener implements PositionEvent.Listener public void positionchanged(positionevent e) { setvalue(e.getposition()); Wie Sie sehen, registriert sich die Komponente beim MessageChannel des ClientContexts, um auf Events zu horchen. Dort werden alle erdenklichen Event-Typen empfangen, da wir aber explizit PositionEvent.Listener implementieren, horchen wir gezielt auf PositionEvents. Beim Empfang eines solchen Events wird die dafür vorgeschriebene Methode positionchanged(e) aufgerufen, in der formuliert ist, wie die Reaktion zu erfolgen hat: hier das einfache Setzen des Textes. Es ist guter Programmierstil, den Listener als private innere Klasse zu implementieren (wie z.b. MyPositionListener). Man vermeidet damit, dass in der API öffentliche Methoden sichtbar sind (positionchanged(e)), die eigentlich niemand aufrufen darf. Das Reagieren auf PositionEvents ist sozusagen innere Angelegenheit der PositionLabel Klasse und sollte deshalb nach außen nicht sichtbar sein. Unser PositionLabel hat noch einen kleinen Fehler: der richtige Werte wird erst dann angezeigt, wenn das erste PositionEvent empfangen wurde. Es fehlt noch die anfängliche Initialisierung auf den aktuellen Wert. Dazu ist ein PositionGetAgent erforderlich, der die aktuelle Position des PositionServerModels abfragt. Seine Implementierung ist trivial. Die Initialisierung geschieht typischerweise im Konstruktor und könnte dann so aussehen: public PositionLabel(ClientContext ctx) throws Exception { ctx.getmessagechannel().addneteventlistener(new MyPositionListener()); PositionGetAgent agent = new PositionGetAgent(ctx).sendForExecution(); setvalue(agent.getposition()); // get position from the received agent

16 4.1.4 Große Server-Modelle Im obigen Beispiel wurde ein sehr einfaches ServerModel mit einem einzigen Parameter gezeigt. In der Praxis kann ein solches Modell beliebig komplex werden. So könnte man beispielsweise eine komplette Fabrik mit allen ihren Fertigungsarbeitsplätzen in einem FactoryServerModel beschreiben. Dieses Modell hätte viele Parameter und würde entsprechend viele verschiedene Event-Typen senden. Clients könnten das Modell teilweise oder ganz visualisieren, je nachdem für welche Events sie sich interessieren. Entscheidend ist, dass alle Clients stets den jeweils aktuellen Zustand darstellen und dies mit bester Performance, da sie vom Server immer nur die notwendigste Delta-Information empfangen. 4.2 Alive Business Objects Eine besonders interessante Anwendung des MVC-Prinzips sind die lebenden Business-Objekte (Alive Business Objects = ABOs). Im Unterschied zu Server-Modellen kann es davon mehrere Instanzen desselben Typs geben, die sich dann aber eindeutig durch einen Primary-Key unterscheiden. Ein einmal erzeugtes ABO wird in einem speziellen Server-Cache gespeichert und bleibt dort existent solange ein Client-Zugriff darauf hat. Nehmen wir als Beispiel ein Tank-Objekt an, welches aus der Datenbank gelesen wurde, also persistent ist (abgleitet von AbstractPersistentABO). Nehmen wir ferner an, dass ein Client (Controller) den Füllstand des Tanks ändert, indem er per Request in diesem Objekt die setlevel(value) Methode aufruft. Ähnlich wie ein ServerModel reagiert das Tank-Objekt, indem es den neuen Wert in der Datenbank speichert und dann eine Nachricht an alle Clients verschickt, in der die Änderung kommuniziert wird. Alle Clients erhalten die Änderung sofort, ohne selbst eine neuerliche Datenbankabfrage machen zu müssen! Man beachte ferner, dass ein anderer Client, der z.b. die Art der Flüssigkeit verändern möchte, das Tank-Objekt nicht nochmals aus der Datenbank lesen muss, sondern es bereits im serverseitigen Cache vorfindet. Er kann auch mehrere Eigenschaften des Objekts gleichzeitig ändern, bevor er es wieder in die Datenbank zurückschreibt. In der Summe ergeben sich durch diesen Mechanismus enorme Performance-Vorteile gegenüber herkömmlichen Techniken Client-Zugriff auf Alive Business Objekte Der Zugriff auf solche ABOs gestaltet sich für den Programmierer sehr einfach. Folgendes Beispiel zeigt, wie das Tank Objekt ausgehend von einer Master-Instanz des betreffenden ABOs vom Server geholt und verändert wird: TankABO master = TankABO.getMaster(clientCtx); TankABO t = master.fetch(false, 100); // fetch instance from server by primary key t.setlevel(1500); t.setfluid( Water ); t.update(); // update on server t.drop(); // switch offline update messages are not received any more Zunächst wird eine Master-Instanz vom Typ Tank erzeugt, die in der Lage ist, das echte BusinessObjekt vom Server zu holen. Dazu wird als Argument von fetch(false, pk) der Primary-Key 1 Dies funktioniert völlig anders bei handelsüblichen Applikations-Servern, die auf RMI (Remote Method Invocation) basieren. Dort muß vor jedem Zugriff das Objekt aus der Datenbank gelesen und nach dem Zugriff wieder in die Datenbank zurückgeschrieben werden, und dies für die Änderung jeder einzelnen Objekt-Eigenschaft ein altbekanntes, aber konzeptionsbedingtes Performanceproblem

17 angegeben (hier die Tanknummer 100), der auch aus mehreren Werten bestehen kann. Anhand dieses Schlüssels wird die Instanz im ABO-Cache des Servers gesucht. Falls sie bereits existiert, erhält der Client sie sofort. Ansonsten wird sie frisch aus der Datenbank gelesen und instantiiert. Würde fetch(...) mit dem Argument true aufgerufen, dann würde das ABO gleich mit einer Resource-Sperre belegt, um zu verhindern, dass andere Benutzer es gleichzeitig verändern können (siehe: Resource-Sperren). Andere Clients haben dann nur lesenden Zugriff. Das Beispiel zeigt auch die Änderung von gleich mehreren Eigenschaften, die dann mit update() auf den Server zurückgeschrieben werden. Daraufhin und das ist das Neue an dieser Technik werden alle Clients, per Nachricht informiert und erhalten so umgehend die geänderten Werte, ohne eigenes Zutun. Der abschließende drop() Aufruf führt dazu, dass der Client das Business-Objekt offline schaltet. Es wird dann nicht mehr vom Server aktualisiert. Auf ähnlich einfache Weise geschieht auch das Erzeugen neuer, bzw. das Löschen vorhandener Tank-Objekte. Man beachte, dass zum Umgang mit ABOs keinerlei Agenten im Spiel sind zumindest nicht sichtbar. Die Alive Business Objects können verstanden werden als eine Programmier-Schicht, die sich über den Agenten aufbaut Komplexe Modelle im Server Mit Alive Business Objects ist es realisiert, dass der Server ein einziges Modell der Welt im Speicher hält, auf das alle Clients zugreifen können. Dabei ist garantiert, dass alle stets die gleiche Sicht der Welt haben, da sie über Änderungen dynamisch informiert werden. Alive Business Objects sind darüber hinaus einfach zu entwickeln und sehr robust in der Anwendung2. 5 Server Kaskadierung 5.1 Zusammenschalten von Servern Ein Server kann sich mit einem oder mehreren anderen Servern, seinen sog. Co-Servern, verbinden und ist dann deren Co-Client. Auf diese Weise sind Server kaskadierbar und können zu komplexen Verbundnetzen zusammengeschaltet werden, wobei jeder Einzelne typischerweise auf einem anderen Rechner läuft und auch andere Aufgaben haben mag. Bild 4) Mehrere Server lassen sich zu einem Verbundnetz kaskadieren. Client-Anfragen können entweder direkt an einen bestimmten Ziel-Server geroutet oder von Server zu Server durchgereicht werden. 2 Alive Business Objects entsprechen in etwa den Session-Beans bei J2EE konformen Applikations-Servern. Dort erzeugt jedoch jeder Client seine persönliche Kopie der Instanz im Server und es fehlt jegliche Benachrichtigung

18 Per Konfiguration ist jedem Server bekannt, wer seine Co-Server und Co-Clients sind, so dass er sich nach zeitweiligem Netzwerkausfall oder nach einem Restart automatisch wieder korrekt in das Netzwerk einklinkt. Die Verbindung zwischen Co-Client und Co-Server ist in sofern eine Besondere, als sie ohne eine Benutzerauthentifizierung besteht und ihr damit keine PermissionSchranken auferlegt sind. 5.2 Weiterreichen von Agenten In einem Server-Verbund können Agenten vom Client entweder direkt an einen Zielserver geschickt, oder aber von Server zu Server herumgereicht werden, wobei jeder Server im Agenten seinen speziellen Teil erledigt. Beispielsweise kann der Zentralserver die Datenbankabfrage erledigen (denn er hat die Datenbankverbindung) und dann das mit Zwischenergebnissen gefüllte Agenten-Objekt weitersenden an einen Compute-Server, der in der Lage ist, spezielle geometrische Berechnungen durchzuführen. Wenn der Client seinen Agenten schließlich zurückerhält, haben mehrere Server für ihn daran gearbeitet. Einer der Vorteile des Agenten-Konzeptes liegt darin, dass Aufgaben auf verschiedene Server verteilt werden können. Dabei brauchen die involvierten Server keine spezielle Intelligenz zu besitzen. Der Code, den sie ausführen sollen, müssen sie selbst nicht kennen - sie erhalten ihn ja quasi im Agenten zugeschickt. Für die Praxis bedeutet dies, dass alle Server bis auf Unterschiede in ihrer Konfiguration identisch sind. Eine weitere interessante Möglichkeit besteht darin, dass Dateien quer über den ServerNetzverbund quasi geschoben werden können (siehe: FileTransferAgent). Sollte beispielsweise ein Compute-Server ein Berechnungsergebnis fertiggestellt haben, deponiert er es auf dem ZentralServer, der seinerseits die Clients veranlasst, die Ergebnisse dort abzuholen. Ein solcher Server-Verbund kann auch eingesetzt werden, um z.b. diverse Prozesse auf den jeweiligen Plattformen zu überwachen und deren Zustände an interessierte Clients durch zu melden. Die Anwendungsmöglichkeiten sind sehr vielfältig. 6 Architektur des Esprit-Servers Dieses Kapitel bietet einen Überblick über die wichtigsten Funktionen des Esprit-Servers. Das in der Software enthaltene Admin-Tool, ein spezieller Administrations-Client, spiegelt diese wider und ermöglicht dem Administrator die visuelle Kontrolle über die meisten Vorgänge im Server. 6.1 Skalierbarkeit Ein Server muss viele Clients gleichzeitig bedienen. Er tut dies, indem er die einzelnen Requests bzw. Agenten in Threads gleichzeitig laufen lässt. Sollten dabei Serverobjekte manipuliert werden, sorgt er für eine saubere Synchronisierung der Zugriffe. Der Esprit-Server ist hochgradig multithreaded, d.h. in ihm laufen viele Threads gleichzeitig. Zur Synchronisierung verwendet er die modernen Concurrency-Klassen (seit Java-6), mit deren Hilfe dies sehr robust und performant möglich ist. Threads sind teure Ressourcen. Der Server achtet darauf, möglichst keine neuen Threads zu erzeugen, sondern stattdessen bereits vorhandene wiederzuverwenden. Dazu verwaltet er sie in sogenannten Thread-Pools und kann so sehr genau steuern, wie viele Threads wirklich gleichzeitig laufen, um sich letztendlich vor Überlastung zu schützen

19 Kurz gesagt: Der Esprit-Server ist skalierbar, d.h. der Administrator kann über die Konfiguration der Thread-Pools den Server optimal an die Hardware, auf der er läuft, anpassen. Einem PC kann man natürlich nicht soviel Last zumuten, wie einer Multi-CPU-Maschine, aber und das ist entscheidend der PC ist jederzeit austauschbar gegen einen Hochleistungsrechner, die Software aber bleibt exakt die gleiche. Eine optimale Einstellung der Thread-Pools zu finden erfordert Experimentierfreude und etwas Erfahrung. Je nach Anforderung der laufenden Applikationen kann sich das Optimum aber auch zeitlich verschieben. Deshalb sind die entscheidenden Parameter zur Laufzeit dynamisch veränderbar. 6.2 Erweiterbarkeit Sämtliche Server-Funktionalität ist gekapselt in der eingangs erwähnten ServerContext Klasse. Sie bietet Zugriff auf alle enthaltenen Server-Komponenten. Die Instantiierung dieser Klasse entspricht dem Hochfahren des Servers. Ggf. ist es notwendig den Esprit-Server um kundenspezifische Funktionalitäten zu erweitern, um beispielsweise ein spezielles Permission-System einzubauen. Dies kann sehr einfach geschehen durch das Erstellen einer spezialisierten MyServerContext Klasse, die sich von ServerContext ableitet. Zudem können sie bestimmte Server-Komponenten durch ihre Eigenen ersetzen, der Esprit-Server bietet dafür eine ganze Reihe von Schnittstellen. Statt des standardmäßigen UserManagers verwenden Sie z.b. ihren MyUserManger, abgeleitet von UserManager, der die Benutzer in Ihrer Datenbank verwaltet. 6.3 Logfile Management Log-Dateien Der Esprit-Server verwaltet eine Reihe von Logdateien in denen sämtliche Serveraktivitäten vollständig nachvollziehbar sind. Ein Client kann den Inhalt einer Logdatei zur Ansicht anfragen. Damit dies mit guter Performance geschieht, ist die Größe einer Logdatei begrenzt. Beim Erreichen der maximalen Größe schließt der Server die aktuelle Logdatei und legt automatisch eine Neue an. Auch der Detaillierungsgrad der Logmeldungen ist einstellbar. Für den Testbetrieb wählt man den gesprächigen verbose-mode, im Produktionsbetrieb genügt es, wenn nur eventuelle Fehlermeldungen protokolliert werden. Bild 5) Der Log-Konfigurationsdialog ermöglicht direkte Einsicht in die Logdateien sowie das dynamische Verändern der Logging-Parameter

20 6.3.2 Log-Kanäle Würden alle Log-Einträge in die gleiche Datei erfolgen, dann wäre sehr schwer nachvollziehbar, welcher Client welche Serveraktivität verursacht hat. Deshalb unterscheidet der Server die Clinets nach deren Application-Name und öffent jeweils einen Client-spezifischen Log-Kanal, in dem nur die Aktivitäten eines bestimmten Client-Typs protokolliert werden Automatische Log Bereinigung Damit das Log-Filesystem nicht vollläuft, ist die Anzahl der Logdateien begrenzt. Ein Hintergrundprozess löscht automatisch in regelmäßigen Zeitabständen die jeweils ältesten Logdateien, und zwar in allen geöffneten Log-Kanälen. Sämtliche Veränderungen an Log-Dateien oder Kanälen sind von dafür registrierten Clients beobachtbar, da sie per Nachricht mitgeteilt werden. Auf Wunsch werden sogar die einzelnen Logmeldungen versendet und sind dann in einer Server-Logkonsole auf Clientseite unmittelbar zu verfolgen. 6.4 Zeitgesteuerte Server-Prozesse Der Esprit-Server bietet die Möglichkeit, Kundenspezifische Klassen (abgeleitet von AbstractServerBatchTask) in einer Prozess-Liste des Servers zu registrieren, jeweils mit einer zusätzlichen Angabe, wann und mit welcher Wiederholungsrate sie aufgerufen werden sollen. Ein spezieller Thread des Servers führt sie dann zum gegebenen Zeitpunkt aus. Es kann jeweils nur ein zeitgesteuerter ServerBatchTask gleichzeitig laufen. Weitere Prozesse, die auch laufen möchten, blockieren in einer Warteschlange bis der Ausführungs-Thread wieder frei ist. Ein laufender ServerBatchTask sendet dem Client regelmäßige Fortschrittsmeldungen, so dass dieser den Ablauf in einem Laufbalken visualisieren kann. Auch von den Logmeldungen, die der Server-Prozess in die Logdatei schreibt, erhält der Client eine Kopie per Nachricht, und kann sie deshalb in einer Konsole anzeigen. Es steht dem Client jederzeit frei, einen laufenden ServerBatchTask abzubrechen, manuell neu zu starten oder ihn dynamisch umzukonfigurieren. In einer speziellen Logdatei wird mitgeschrieben, wann welcher ServerBatchTask, gelaufen ist, und mit welchem Ergebnis er abgeschlossen hat. Bild 6) Mit diesem Dialog kann ein ServerBatchTask konfiguriert und manuell ausgeführt werden. Eine typische Anwendung besteht z.b. darin, dass regelmäßig bestimmte Datenübertragungen (z.b. Datenabgleich von einer Datenbank mit einer anderen) ausgeführt werden. 6.5 Datenbank-Verbindungen Per Konfiguration kann dem Esprit-Se-rver mitgeteilt werden, dass er sich mit einer oder mehreren relationalen Datenbanken verbinden soll. Diese können sogar von verschiedenen Herstellern stammen, denn die zugrunde liegende Persistenzschicht (DBObjects) basiert auf JDBC und ist damit weitestgehend datenbankunabhängig

21 Die Verbindung zu einer Datenbank erfolgt über einen konfigurierbaren Connection-Pool, der die gleichzeitige Ausführung mehrerer Transaktionen von verschiedenen Benutzern gestattet. Da Verbindungen zu mehreren Datenbanken gleichzeitig bestehen können (also mehrere ConnectionPools!), ist es möglich, Datensätze aus einer Datenbank zu lesen, um sie unmittelbar in eine andere einzufügen. Damit hat man praktisch eine on-the-fly Datenübertragung zwischen zwei ggf. sehr unterschiedlichen Datenbanksystemen realisiert, die zudem außerordentlich performant ist. Der Esprit-Server selbst ist nicht auf eine Datenbank angewiesen. 6.6 Server Aktivität Server-Statistik Der Esprit-Server führt interne Statistiken über aller erdenklichen Ereignisse. Ein spezielles ServerStatisticABO liefert dem Client in regelmäßigen Zeitabständen Schnappschüsse des Momentanzustands und macht so die Servertätigkeit für den Client beobachtbar. Auf diese Weise findet man leicht Engpässe, die ggf. eine Umkonfiguration ratsam erscheinen lassen. Wenn beispielsweise entdeckt wird, dass die Ausführung von Agenten öfter abgelehnt wurde, dann könnte man die maximale Anzahl parallellaufender Agenten erhöhen oder die Warteschlange vergrößern. Um gezielte Messungen durchzuführen, lassen sich alle Zählerwerte der Statistik zurücksetzen. Bild 7) Das Statistik-Panel gibt eine Übersicht über die wichtigsten Zustandsparameter des Servers Resource-Sperren Der Esprit-Server bietet dem Client die Möglichkeit sog. Resource-Sperren anzufordern. Möchte der Client z.b. eine Serverdatei lesen, dann kann er eine shared Sperre dafür belegen, die sicherstellt, dass die Datei nicht gelöscht werden kann, solange sie im Zugriff ist. Andere Clients können dieselbe Datei gleichzeitig ebenfalls mit shared Sperren belegen