Beschreibung der Start-Prozedur

Startvorgang einer SR-JRC Anwendung

Der Start einer Anwendung mit Datenbank-Anbindung erfordert eine Menge an Konfiguration, Initialisierung, Vorbereitung und ein erstes Einlesen an Daten. Dies ist bei fast jeder Anwendung jedesmal das Gleiche, sodass es sich lohnt, dies zusammen zu fassen und für den Anwender einfacher zu gestalten.

Wie bereits unter Konfiguration beschrieben, ist der ApplicationContext in mehrere Dateien aufgeteilt, wovon 2 Teil des SR-JRC Frameworks sind. Die dritte Datei ist Teil der Anwendung.

SR-JRC Anwendungen können in 3 Kategorien eingeteilt werden:


modulare Desktop Anwendungen
hierbei gibt es eine Startanwendung, die den Anwendungsrahmen erzeugt und anschließend die Anwendungsmodule lädt.

Systemdienste
sind Hintergrunddienste oder Automaten, die autark ohne GUI laufen

einfache GUI-Anwendungen
sind einfache Anwendungen, wie z.B. eine Installations-Anwendung, die keinen Desktop oder ladbare Module benötigt.

Seitenanfang

Desktop-Anwendung

Der Start einer Anwendung mit Datenbank-Anbindung erfordert eine Menge an Konfiguration, Initialisierung, Vorbereitung und ein erstes Einlesen an Daten. Dies ist bei fast jeder Anwendung jedesmal das Gleiche, sodass es sich lohnt, dies zusammen zu fassen und für den Anwender einfacher zu gestalten. Für eine Anwendungsklasse SampleApp könnte die main Funktion so aussehen: 

public static void main(String[] args) {
    List sArgs = new ArrayList(Arrays.asList(args));

    new DesktopApplicationLauncher(new SampleApp()
                                , new String[] {
                                  "de/schwarzrot/app/base/ctx/security-context.xml"
                                , "de/schwarzrot/app/base/ctx/data-access-context.xml"
                                , "de/schwarzrot/main/sampleapp/ctx/application-context.xml"
                                  }
                                , sArgs).start();
}
Application Startup

Wie bereits unter Konfiguration beschrieben, ist der ApplicationContext in mehrere Dateien aufgeteilt, wovon 2 Teil des SR-JRC Frameworks sind. Damit eine Anwendung vom Framework als solche erkannt wird, gibt es das Interface MainEntry, welches die Anwendungsklasse implementieren muss. MainEntry erwartet einen Generics-Parameter, mit dem die Konfigurationsklasse angegeben wird.

Die Konfigurationklasse ist eine Javabean, über die der Zustand der Anwendung gespeichert und die für jeden Benutzer separat abgelegt werden kann. Vorgabe des Frameworks ist die Speicherung als Java-Preferences.

Als letztes muss das Framework der Anwendung die Möglichkeit einräumen, mögliche Anwendungsparameter vorzubelegen. Dazu wird das statische Array, welches jede main-Funktion unter Java erhält in eine Liste gepackt und dem Starthelfer übergeben.

Der Anwendungsrahmen, der Teil von SR-JRC ist, gibt in der run()-Methode der Anwendungsklasse die Kontrolle an den konfigurierten Desktop weiter. Je nach Implementierung der Desktopklasse führt es früher oder später zu einem JFrame.setVisible(true);

In nebenstehender Grafik kann der Ablauf detailliert betrachtet und nachvollzogen werden.

Seitenanfang

einfache GUI-Anwendung

Wird anstatt des DesktopApplicationLaunchers der SimpleApplicationLauncher verwendet, können einfache GUI-Anwendungen gestartet werden. Es wird kein Desktop geladen und dort, wo die Desktopanwendung die Kontrolle an die Desktop-Instanz übergibt, wird beim SimpleApplicationLauncher schlicht die Kontrolle an die Anwendungsklasse übergeben.

Diese Art, eine Anwendung zu starten wird z.B. beim Java-Installer von VdrAssistant verwendet.

Seitenanfang

Systemdienst

Der größte Teil der Initialisierung ist identisch zu der Desktop-Anwendung. Deshalb haben beide Starthelfer auch einen gemeinsamen Vorfahren, den AbstractApplicationLauncher. Die Unterschiede sind in der ServerLauncher Klasse ausformuliert. Für eine Anwendungsklasse SampleService könnte die main Funktion so aussehen: 

public static void main(String[] args) {
    List sArgs = new ArrayList(Arrays.asList(args));

    new ServiceLauncher(new SampleService()
                      , new String[] {
                        "de/schwarzrot/app/base/ctx/security-context.xml"
                      , "de/schwarzrot/app/base/ctx/data-access-context.xml"
                      , "de/schwarzrot/main/sampleservice/ctx/application-context.xml"
                        }
                      , sArgs).start();
}
Service Startup

Systemdienste funktionieren etwas anders, als Desktop-Anwendungen, deshalb gibt es eine Erweiterung des MainEntry Interface, genannt Service. Der ServiceLauncher erwartet eine Service-Instanz als ersten Parameter.

Die Konfigurationklasse ist wieder eine Javabean. Statt der GUI-Parameter wird hier die verwendete Log-Konfiguration, sowie die IP-Adresse des Dienstes abgelegt.

Als letztes muss das Framework der Anwendung die Möglichkeit einräumen, mögliche Anwendungsparameter vorzubelegen. Dazu wird das statische Array, welches jede main-Funktion unter Java erhält in eine Liste gepackt und dem Starthelfer übergeben.

Während bei der Desktop-Anwendung der Aufruf von Desktop.start() nicht zurück kommt, geht der Service-Starter davon aus, dass der Dienst seine Aufgabe (run()-Methode) als Einzelaufgabe formuliert hat, welche zyklisch aufzurufen ist. Dafür hat die Service-Schnittstelle die Methode isIdle(). Gibt nun der Dienst bei der Frage, ob ihm langweilig ist "Ja" zurück, fällt der Dienst in den Dornröschenschlaf. Wie lange das ist, kann in der Dienstregistrierung in der Datenbank geändert werden (z.B. mit der Dienste-Verwaltung der Desktop-Anwendung, die zu jeder Desktopanwendung gehört).

In nebenstehender Grafik kann der Ablauf detailliert betrachtet und nachvollzogen werden.

Seitenanfang