Re: [Hbci4java-help] [Bug 84] Probleme, wenn Threads nicht selbst erzeugt werden (bei Tomcat etc .)

[Olaf W. <hbc...@wi...>]

Hi,

> Es gibt zwar schon viel und auch gut verständliche Doku, aber die
> beschreibt eigentlich nie, warum die Architektur der Library so ist, wie
> sie ist, und wie es dazu gekommen ist.

Wie das immer so ist mit Doku: Irgendwo wuerde man sich immer
noch mehr wuenschen ;)

> Achso. Das heißt dann also, dass man eine Kapselung hat, die man so
> beschreiben könnte:
>
> User <-> Anwendungsprogramm <-> HBCI4Java-Aufsatz <-> HBCI4Java <->
> Banksysteme
>
> Warum auch nicht, ich würde nur behaupten, dass es immer eine Trennung
> zwischen dem Anwendungsprogramm und dem HBCI4Java-Aufsatz geben sollte.
> Dann wären die Verantwortlichkeiten weiterhin klar definiert.

Ich sehe von "HBCI4Java-Aufsatz" jetzt nicht so ganz den Sinn.
Es sei denn, man betrachtet "HBCI4Java" als _ein_ moegliches
Payment-Backend, falls man neben HBCI noch andere Protokolle
unterstuetzen moechte.

> Nun, man müsste dann halt die HBCI4Java-Bibliothek selbst kompilieren,
> damit diese zur Compilezeit alle zusätzlichen Klassen kennen. 

Das wuerde aber implizieren, dass jede Anwendung ihre eigene
Version von HBCI4Java mitbringt. Fuer OpenSuSE aber gibt es
HBCI4Java z.Bsp. als RPM (http://packman.links2linux.de/package/hbci4java),
welches als Abhaengigkeit von mehr als einem Paket verwendet wird.

> Hmm, man kann das noch weiterspinnen, indem der User sogar zunächst danach
> gefragt wird, welchen TAN-Typ er verwenden möchte (es kann ja mehrere
> geben), danach würde dann z. B. bei iTANs der TAN-Index abgerufen werden,
> etc. Oder der User kann sogar interaktiv arbeiten, mit weiteren
> Zwischenschritten. Halt je nachdem, was im spezifischen Fall genau
> gewünscht ist.

Das ist doch mittels HBCICallback bereits so. Oder meinst du
etwas anderes?


Gruss
Olaf