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

[Rolf V. <ro...@we...>]

> -----Ursprüngliche Nachricht-----
> Von: "Olaf Willuhn" <hbc...@wi...>
> Gesendet: 24.02.09 14:50:19
> An: hbc...@li...
> Betreff: Re: [Hbci4java-help] [Bug 84] Probleme, wenn Threads nicht selbst erzeugt werden (bei Tomcat etc .)

> 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 ;)


Ja, das ist wahr. Wobei HBCI4Java IMHO schon recht gut dokumentiert ist, daher bitte nicht als Kritik mißverstehen :)


> > 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.


Das ist wahr, wenn man das von Vorneherein ausschließen will/kann, ist die klare Trennung an der Stelle vermutlich "Overkill".

Letztlich kann es wohl nur im Ermessen der Entwickler der Anwendung liegen, wie die ihre Softwarearchitektur aufbauen. Aber falls evtl. (von Anfang an oder auch erst später) andere Möglichkeiten in Betracht gezogen werden, würde ich persönlich schon den oben skizzierten Aufbau wählen. Aber wie geschrieben, das ist wohl Sache der Entwickler der Anwendung, und hat nur noch peripher mit der Library selbst zu tun.


> > 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.


Ahso, daran hatte ich überhaupt noch nicht gedacht. Wobei ich es nicht als Nachteil ansehen würde, wenn jede Anwendung ihre eigene Version mitbringt, denn:
1.: Könnte so der Entwickler der Anwendung sicherstellen, dass die vorhandene Version von HBCI4Java zur Anwendung auch wirklich kompatibel ist, und dann diese definitiv kompatible Version einfach mitinstallieren lassen.
2.: Könnte der Entwickler der Anwendung so seine Erweiterungen einfach in seine Instanz der Library eincompilieren, und wäre beliebig flexibel (beliebige Änderungen wären möglich, sofern sinnvoll).
3.: Dürfte ein typischer Anwender vermutlich nur ein Programm auf seinem Rechner installieren, dass HBCI4Java nutzt. Falls er tatsächlich mehrere Programme installiert, dürfte der sehr geringe Mehrbedarf an Speicherplatz nicht ins Gewicht fallen.

Aber gut, das ist letztlich Ansichtssache, und lässt sich vermutlich nachträglich nicht mehr sonderlich gut umentscheiden. Ich bin schon länger der Meinung, das shared libraries in vielen Fällen mehr schaden, als nutzen, und dass es oftmals einfacher ist, wenn eine Software ihre Libraries einfach selbst mitbringt (unabhängig vom Betriebssystem) - ausgenommen natürlich Libraries, die fast jedes Programm benötigt, und die tatsächlich dutzendfach im System vorhanden wären. Das würde vieles vereinfachen (keine Versionskonflikte mehr), und der zusätzliche Speicherplatzbedarf dürfte 99% aller User nicht wirklich interessieren.

Aber gut, diese Diskussion ist wahrscheinlich für diese Mailingliste schon leicht "off topic", daher sollten wir das wohl nicht vertiefen. Es spricht ja auch nichts dagegen, den bisherigen Mechanismus mit den Factories beizubehalten, ich war nur irrtümlich davon ausgegangen, dieser wäre eigentlich unnötig und würde nicht real genutzt werden. Wenn dem so gewesen wäre, hätte man ihn in der nächsten Version einfach weglassen können.


> > 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?


Der HBCICallback ist ohne Probleme dazu in der Lage, beliebig viele Interaktionsschritte mit dem Anwender durchzuführen, das ist auf jeden Fall klar. Ich würde es nur schön finden, wenn die Library pro Session ein _eigenes_ Callbackobjekt verwaltet, damit mehrere Sessions sich nicht ein einziges derartiges Objekt teilen müssen. Dazu muss am Callbackmechanismus nicht wirklich viel geändert werden, da ja jetzt schon pro ThreadGroup ein eigenes Objekt verwaltet wird.

Ein derartiges _gemeinsames_ Callback-Objekt hat Stefan aber für die nächste Version der Library geplant, ich denke jedoch, dass das keine so gute Idee wäre. Es hätte für manche Szenarien Nachteile, im Gegenzug scheint es mir jedoch keine Vorteile zu geben.

Mein Vorschlag wäre weiterhin, den Session-Identifier von außen (also durch die Anwendung) festzulegen, und nicht mehr auf die ThreadGroup zu schauen. Im Moment findet eine Trennung von Sessions ja immer anhand der ThreadGroup statt, hier wäre es einfach besser, die Trennung anhand eines Merkmals zu haben, dass die Anwendung vorgibt. Das kann ja evtl. auch die ThreadGroup sein, aber oftmals wird das irgendeine SessionId sein.

Wäre auf jeden Fall besser, wenn die Library selbst _nicht_ auf die ThreadGroup zugreift, denn das geht halt nur, wenn das Anwendungsprogramm selbst seine Threads erzeugt. Wenn z. B. ein Application-Server wie Tomcat die Threads erzeugt, geht das nicht. Dann _muss_ das Merkmal zur Trennung der Sessions von außen an die Library übergeben werden.


Kurz zusammengefasst meine Vorschläge, nachdem ich jetzt meine falschen Vorstellungen losgeworden bin:
-> Bisheriger Mechanismus mit Factories, die von der Anwendung überschrieben werden können, sollte beibehalten werden, weil dieser (entgegen meinen Vermutungen) rege genutzt wird.

-> Aufbau der Anwendung ("HBCI4Java-Aufsatz" als klar getrenntes Modul oder mit dem restlichen Code vermischt) kann wohl nur von den Entwicklern der Anwendung sinnvoll entschieden werden.

-> Ein einziges Callback-Objekt für alle Sessions, die evtl. parallel ablaufen, erscheint mir keine gute Idee, getrennte Callback-Objekte haben diverse Vorteile und keine Nachteile.

-> Die Factories können wohl ohne weiteres global von der Library verwaltet werden, aber sonst sind meines Erachtens nach globale Variablen bzw. Datenstrukturen potentiell schlecht für Performance und Stabilität, und somit keine gute Idee. Schon alleine, weil synchronized-Methoden keine gleichzeitige Abarbeitung zulassen. Besser ist praktisch immer ein Objekt pro Session, egal ob das Objekt von der Anwendung oder von der Library instanziiert wird.

-> Der Session-Identifier sollte von der Anwendung bereitgestellt werden, weil diese vermutlich sowieso einen solchen verwaltet (sofern die Anwendung mehrere gleichzeitige Sessions benötigt -- falls nicht, kann hier ja einfach ein fixer Wert übergeben werden). ThreadGroups sind wenig geeignet, weil diese nicht verwendet werden können, wenn die Anwendung ihre Threads nicht selbst erzeugt.


> Gruss
> Olaf


Viele Grüße, Rolf