[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Banken, Dienstleistungen und Telnet.
- To: debate@fitug.de
- Subject: Re: Banken, Dienstleistungen und Telnet.
- From: Rudolf Schreiner <ras@muc.de>
- Date: Sat, 27 Mar 1999 17:17:47 +0100 (MET)
- Comment: This message comes from the debate mailing list.
- In-Reply-To: <199903261932.UAA21240@miles.io-software.com>
- Sender: owner-debate@fitug.de
On Fri, 26 Mar 1999, Arne Haeckel wrote:
> Ich sehe den prinzipiellen Gewinn von CORBA gegenüber HBCI nicht.
Es ist eine allgemein anwendbare Middleware, nicht nur eine
Spezialloesung.
> Du wirst Dir Gedanken machen müssen über technischen Interfaces für
> ca. 5000 (fachliche) Geschäftsvorfälle.
'gibt ein ziemlich langes IDL-File... :-)#
Natuerlich ist es nicht trivial, eine komplexe Anwendung zu programmieren.
> OK, ich bin nicht gerade Fan von EDIFACT (und HBCI ist von den
> EDIFACT-Definitionen abgeleitet), daher stehe ich HBCI skeptisch
> gegenüber.
Mein letzter Kontakt mit EDI war vor einigen Jahren. Ich habe mir
erlaubt, in so einem EDI-System einige riesige Sicherheitsloecher zu
finden. Das wollte keiner hoeren... :-(#
> Aber CORBA als das Allheilmittel zu preisen...
CORBA ist sicherlich nicht das Allheilmittel. Ich aergere mich dauernd
darueber. Aber weisst Du was besseres, um Verteilte Systeme
zusammenzukleben? DCE konnte sich nie breit durchsetzen. RMI ist Java
only. Und DCOM ist einfach krank.
Ich mag einfach keine Inselloesungen. Fuer mich ist z.B. Unix so genial,
weil alle Programme ein einheitliches Interface haben (Streams) und man sie
dadurch sehr einfach zusammenhaengen kann. CORBA ist aehnlich. Gib einer
Applikation ein CORBA Interface und schon koennen andere Programme die
Funktionen dieser Applikation benutzen, ueber die Grenzen von Sprachen
und Betriebssystemen hinweg. Natuerlich, in der Praxis hat das durchaus
seine Tuecken...
> Und wie
> sieht es denn bei der Sicherheit von CORBA aus:
Ausreichend. Daran hatte ich schon gedacht. 'ist zufaellig mein Job. ;-)#
> Einige ORB-Hersteller
> bieten kein IIOP over SSL an, andere IIOP over SSL (40Bit)
IONA z.B. hat SSL mit langen Keys. Amerikanische Firmen haben da
natuerlich Probleme...
> und andere
> dann die OMG-Security Services als Implementierung von
> Drittherstellern.
Das taugt hier nicht. SSL ist fuer solche Anwendungen weit besser
geeignet.
> Wie sieht es inder Freeware-/ Open Source Scene aus?
> (Ich weiß es leider nicht)
MICO verwendet SSLeay. Einige Iren bauen an CORBASEC basierend auf
SESAME, ich habe hier einen primitiven quick'n dirty Security Service mit
der schwedischen Kerberos-Implementierung. MICO ist der "GNU-ORB."
ORBacus ist frei fuer nicht kommerzielle Anwendungen. Der C++-ORBacus
verwendet ebenfalls SSLeay, die Java-Version eine oestereichische
SSL-Implementierung. Polar hat dafuer eine CORBASEC-Implementierung und
verwendet MIT-Kerberos. 'sollte aber auch mit Heimdal laufen.
Firewalls ist auch kein Problem fuer so eine einfache Anwendung (aus der
Firewall-Sicht...) Auch fuer sehr komplexe Anwendungen wird es in Baelde
eine Firewall auf der Basis von MICO geben, die Funktionalitaet habe ich
bereits (inbound, outbound, Factory, Callback, proxified,
transparent,...), jetzt arbeite ich an "Firewall-Policies."
Ich denke, das ist schon mehr als ausreichend. Ganz allgemein gibt es im
Open Source Bereich eine Menge CORBA-Software von hoher Qualitaet, z.B.
auch ILU oder TAO, einen Real-Time ORB.
> Was steht eigentlich einer batchfähigen Implementierung eines HBCI-
> Clients entgegen? Dann könnte man scriptgesteuert nachts seine
> Kontostände abholen. Oder statt Daueraufträgen könnte man dann
> Scripte für die monatliche Überweisung der Miete einrichten. Was wäre
> daran besser oder schlechter als eine Maillösung?
IMHO das Problem waere die Anbindung an andere Systeme. Du must Daten
erst exportieren und importieren. Sympatischer als Mail waere es mir
aber allemal.
Gibt es eigentlich eine im Source erhaeltliche Referenzimplementierung
von HBCI?
Rudi