HBCI4Java-Server Dokumentation

Allgemeines HBCI4Java-Server ermöglicht das Implementieren eines eigenen HBCI-Servers.

See:
          Description

Packages
org.kapott.hbci.server Paket mit den Basis-Klassen für die Realisierung eines HBCI-Servers.
org.kapott.hbci.server.datastore Dieses Package enthält die Schnittstellenbeschreibung für ein Objekt, welches jede HBCI-Server-Anwendung bereitstellen muss und welches für die Bereitstellung von Laufzeitdaten dient.

 

Allgemeines

HBCI4Java-Server ermöglicht das Implementieren eines eigenen HBCI-Servers. Außerdem ist in diesem Paket eine Referenz-Implementation eines HBCI-Servers enthalten, die (fast) sofort gestartet werden kann und somit als Test-HBCI-Server für eigene HBCI-Client-Anwendungen zur Verfügung steht.

Zum einen wird also eine Java-Klassenbibliothek angeboten, die das Framework für einen HBCI-Server realisiert. Der Grundgedanke dabei ist folgender: Um (z.B. bei einem Kreditinstitut) einen eigenen HBCI-Server zu entwickeln, wird eine Java-Anwendung geschrieben, welche eine Instanz der Klasse org.kapott.hbci.server.HBCIServer erzeugt und initialisiert. Hinter diesem Objekt verbirgt sich der komplette HBCI-Server, der mit .start() gestartet wird.
Ein HBCI-Server muss natürlich an die jeweilige Umgebung angepasst werden. Dazu werden beim Initialisieren der HBCIServer-Instanz Java-Objekte übergeben, welche bestimmte Interfaces implementieren müssen. Diese Schnittstellen werden aus dem HBCI4Java-Server-Code heraus benutzt, um mit dem Backend-System des jeweiligen Kreditinstitutes zu kommunizieren.

Zum einen handelt es sich dabei um ein Interface, welches benutzt wird, um die Laufzeitdaten des Servers in Erfahrung zu bringen. Dazu gehören Daten wie die Bankleitzahl des Kreditinstitutes, die IP-Adresse, auf der Server eingehende Verbindungen entgegennehmen soll, die zu unterstützenden HBCI-Versionen und Sprachen, die jeweils zu unterstützenden Geschäftsvorfälle samt der dazugehörigen Geschäftsvorfallparameter etc. Außerdem werden von HBCI4Java-Server über diese Schnittstelle die Menge der gültigen Benutzerkennungen abgefragt, die Kontoverbindungen, die pro Nutzer gültig sind usw. usf. Des weiteren wird diese Schnittstelle benutzt, um geänderte Daten (z.B. geänderte Schlüssel oder Signatur-IDs) in das Bank-Backendsystem zurückschreiben zu können.

Eine weitere Schnittstelle, die von der HBCI-Server-Anwendung implementiert und bereitgestellt werden muss, ist eine Callback-Schnittstelle. Diese wird immer dann aus dem HBCI4Java-Server-Code heraus aufgerufen, wenn ein bestimmtes Ereignis - z.B. das Eintreffen eines Auftragssegmentes - stattgefunden hat. Die "Randdaten" des jeweiligen Auftrages (z.B. die Nutzerkennung/Kunden-ID des Kunden) werden dabei in einem Context-Objekt bereitgestellt. Die HBCI-Server-Anwendung muss auf solche Ereignisse reagieren (i.d.R. also die Auftragsdaten überprüfen und evtl. eine entsprechende Aktion im eigentlichen Banksystem auslösen) und eventuell Rückgabedaten (Ergebnisse, Fehler-/Erfolgsmeldungen) bereitstellen.

Der "interne" Teil von HBCI4Java-Server übernimmt dabei sämtliche Details der Protokoll-Abwicklung: das Entgegennehmen von Nachrichten, Entschlüsseln, Überprüfen der Signatur, Auswerten und Überprüfen des Nachrichteninhaltes bis hin zum Erzeugen und Versenden der Antwortnachricht. Außerdem werden sämtliche Nachrichten, die die Schlüssel- und Dialogverwaltung betreffen, völlig transparent von HBCI4Java-Server behandelt -- das heißt, die HBCI-Server-Anwendung "sieht" nur die für ein Banksystem tatsächlich relevanten Daten, nämlich die schon aufbereiteten Daten aus den Auftragsnachrichten eines HBCI-Clients. Die von der HBCI-Anwendung generierten Antwortdaten werden ebenfalls in einer sehr einfachen Form an den HBCI4Java-Server-Code zurückgegeben, welcher dann die Erzeugung der jeweiligen Antwortnachricht (inklusive Signierung/Verschlüsselung usw.) übernimmt.

Zusammenfassend kann man also sagen, dass für die Realisierung einer eigenen HBCI-Server-Anwendung und die Anbindung an ein bestehendes Backend-System "nur" zwei Schnittstellen tatsächlich zu implementieren sind: zum einen eine Schnittstelle zum Zugriff auf die Laufzeitdaten des Backend-Systems (Nutzerkennungen/Schlüssel usw.), zum anderen die Reaktion auf eingehende Auftragsnachrichten.

Der zweite Teil des HBCI4Java-Server-Paketes stellt eine Referenz-Implementation eines HBCI-Servers dar. Hier sind also die beiden relevanten Schnittstellen bereits exemplarisch implementiert. Die Implementation ist dabei sehr einfach gehalten und entspricht natürlich nicht den Bedürfnissen einer "echten" Bank. Es ist aber immerhin möglich, eine im Prinzip beliebige Anzahl von Benutzern damit zu verwalten (der Server unterstützt natürlich auch die Behandlung von mehreren Dialogen gleichzeitig) und somit einen echten Bankbetrieb zu simulieren.


HBCI4Java-Server -- Copyright (c) 2003 Stefan Palme

hbci4java@kapott.org