Allgemeiner Überblick

M. Klink

Abbildung 6.1: Aufbau Application Server

Der Application Server ist im Gesamtkonzept unserer Anwendung gesehen ein Auftragsabwickler, der seine genauen Nachbarn kennt und von diesen Aufträge bekommt und daraufhin Ergebnisse zurück liefert. Wie man auf dem groben Aufbauplan (Abbildung serverallgemein) erkennen kann, kann der Application Server über die Interfaces vom Client oder Workflowmanager, aufgerufen werden. Die häufigsten Aufrufe, die der Application Server erhält, sind Funktionsaufrufe, die als Parameter eine Auftrags-Datenstruktur enthalten. Diese Auftrags-Datenstruktur (siehe Abschnitt auftragsdatenstruktur) definiert entweder genau was ein bestimmter Nutzer, eine bestimmte Nutzergruppe oder was der Application Server selbst für Aufgaben ausführen muss, außerdem werden Daten in der Datenstruktur gespeichert und als Ergebnis der Aufgaben in der Datenstruktur weitergesendet. Ein Schritt in einem Workflow besteht grundsäztlich aus einem oder mehreren solcher Aufträge. Wenn also im weiteren davon die Rede ist, daß ein Auftrag gesendet wird, ist damit ein Funktionsaufruf gemeint, der eine Auftrags-Datenstruktur enthält.

Der Application-Server selber soll in der Anwendung nie Client oder Workflowmanager triggern. Nur in einem Ausnahmefall kann der Application Server selber Aufrufender sein, wobei er aber nur als Durchreiche-Akteur fungiert und einen Aufruf vom Client an den Workflowmanager weitergibt. Die Aufrufe, die er vom Client durchreicht, sind entweder die Anweisung, einen neuen Workflow zu starten, oder die Information, daß der aktuelle Schritt in einem bestimmten Workflow erfolgreich beendet wurde.

Die Kommunikation mit dem Client beschränkt sich ansonsten im wesentlichen auf 5 verschiedene Aufrufe vom Client,die nachfolgend aufgeführt sind:

1. Gib mir mögliche Workflowtemplates.
2. Starte neuen Workflow.
3. Gib mir wartende Aufträge.
4. Lies Informationen aus der Datenbank für ein Formular.
5. Speichere ausgefüllte Formulare.

Je nach Aufruf werden im Server Daten aus der Datenbank gelesen oder in dieselbe geschrieben und eventuell auch der Workflowmanager benachrichtigt. Die Kommunikation mit dem Workflowmanager ist ähnlich. Der Workflowmanager kann einen neuen Auftrag an den Application Server senden, der entweder ein Formularauftrag für den Client oder ein Auftrag an den Application Server sein kann.

Der Server kann vom Workflowmanager die vorhandenen Templates abfragen und diese dann dem Client mitteilen. Er kann Ergebnisse von einem Auftrag zurücksenden und somit auch die Abarbeitung eines Workflow-Schrittes signalisieren.

Der typische Ablauf für einen Workflow-Schritt wäre, daß der Workflowmanager dem Application-Server einen Auftrag sendet und dieser ihn mit allen wichtigen Informationen wie Workflow- und UserId speichert. Danach würde sich ein Nutzer am Client einloggen und nach Aufträgen fragen. Dies kann Tage oder auch nur 10 Minuten später sein. Der Application-Server sucht dann die passenden Aufträge aus der Datenbank und schickt diese dem Client. Wenn diese am Client fertig bearbeitet sind, sendet dieser dem Application-Server die neuen Daten.

Dadurch wird der Application-Server veranlaßt, die neuen Daten in der Datenbank zu speichern und den Workflowmanager von der Beendigung des Workflow-Schrittes zu benachrichtigen. Nachdem der Workflowmanager benachrichtigt ist, wird der zu dem Workflow-Schritt gehörige Auftrag vom Application-Server in der Datenbank als abgearbeitet gekennzeichnet. Der Workflowmanager, der die Beendigung des Workflow-Schritts signalisiert bekam, kann nun anhand des Templates erkennen, wie weit der Workflow abgearbeitet ist und ob weitere Aufträge gesendet werden müssen.

In welchem Zustand sich der Workflow befindet, weiß der Application Server technisch nicht,da er immer nur genau die Funktionen abarbeitet, die er den Kommunikationspartnern zur Verfügung stellt.