Lobster Experten Fragen

Dateisystem

Das Dateisystem ist natürlich immer am leichtesten zu erreichen, erst recht das lokale. Hier kann man wunderbar Daten zur Verarbeitung bereitstellen und auch hinterher wieder die Ergebnisse ablegen. Vorausgesetzt natürlich, die verschiedenen Systeme, die miteinander kommunizieren, haben auch alle Zugriff auf das selbe Dateisystem.
Nun werden aber weder im EDI- noch im EAI-Umfeld alle relevanten Programme auf dem selben Rechner laufen. Die nehmen sich doch nur gegenseitig die Leistung weg, mal ganz zu schweigen von dem Risiko, dass mit einem einzigen Rechner auf einen Schlag alle geschäftskritischen Prozesse ausfallen könnten.
Eine Lösung hierfür ist sicher ein SAN, ein Storage Area Network, auf dem alle wichtigen Prozesse ihre Daten speichern. Da hat man meist gleich noch Hochverfügbarkeit usw. mit drin. Aber es geht auch eine Nummer kleiner, mit dem NAS, dem Network Attached Storage. Das ist letztlich nichts anderes als der gute, alte Fileserver, auf den mittels entsprechender Protokolle wie NFS oder SMB zugegriffen wird. Na gut, nicht nur der Fileserver, die Zugriffe erfolgen oft kreuz und quer durch’s ganze Firmennetz.

Das lokale Dateisystem ist wohl kaum einer näheren Betrachtung wert, und wenn Sie tatsächlich ein SAN aufbauen wollen, ist das ein zu großes Unterfangen, als dass man es hier nennenswert anschneiden könnte.
Interessant ist für uns eigentlich vor allem, welche Ansprüche an eine EDI-/EAI-Software zu stellen sind, die auf die Platten entfernter Rechner zugreifen muss.

NFS

NFS ist das alte Network File System aus der Unix-Welt. Es ist inzwischen ziemlich in die Jahre gekommen und weist (aus historischen Gründen) auch nicht gerade hohe Sicherheitsstandards auf. Allerdings ist die aktuelle Version 4 gegenüber dem der verbreiteten Version 3 stark verbessert und hat hier wieder gewaltig aufgeholt.
Wenn Sie in einer Unix/Linux-Umgebung unterwegs sind, können Sie sich das Leben mit NFS aber recht einfach machen. Sie mounten einfach die entsprechenden Netzlaufwerke (am besten automatisch schon beim Booten)  und greifen in Ihrer Software dann auf diese genau so leicht zu wie auf lokale Partitionen und Verzeichnisse. Und eigentlich beherrschen auch Windows-Server NFS, es wird nur kaum genutzt. Wenn der entfernte Rechner mit Windows läuft, können Sie stattdessen über Samba dessen Freigaben ebenso mounten, da gibt es erst mal kaum Unterschiede (von einigen Feinheiten im Betrieb dann mal abgesehen, das ist dann aber SMB).
Ihr EDI-/EAI-System muss also, wenn es unter Unix/Linux läuft, weiter nichts beachten, es sieht genau genommen nicht mal, dass ein Verzeichnis lokal und das andere eigentlich auf einem Server im Keller liegt. Ob da nun /user/local/data/Datei.txt steht oder /mount/fileserver/commondata/Datei.txt, der Zugriff erfolgt für die Anwendung selbst identisch.

SMB

Mittels SMB realisiert in erster Linie Windows sein Netzwerk-Dateisystem. Hier ist die Sache etwas komplizierter als bei NFS-Mounts. Sie kennen das berühmte, verbundene Netzlaufwerk. Meist werden dafür Buchstaben weit hinten im Alphabet genutzt (besonders gerne das T), und dann zeigt eben Laufwerk T: auf ein freigegebenes Verzeichnis irgend eines entfernten Rechners. Das ist eine nette Lösung für einen Bürocomputer, an dem man sich erst mal einloggt, dann (meist automatisch) die Netzlaufwerke verbunden werden, und wenn man dann damit arbeiten will, ist alles da.
Für Serverprozesse, die meist als Windows-Dienst auch ganz ohne User-Login laufen müssen, ist das unbrauchbar. Solche Laufwerksbuchstaben wie T: sind immer auf den eingeloggten Benutzer bezogen und existieren für einen Prozess, der beim Rechnerstart ganz automatisch mit anläuft, gar nicht. Hier ist eine andere Technik gefragt, aber auch die kennen Sie schon aus Ihrem Dateimanager (aka Windows Explorer). Man gibt den Server und den Freigabenamen des gesuchten Verzeichnisses direkt an, etwa so:

\\servername\freigabename\pfad\Datei.txt

Mit dieser sogenannten UNC-Notation kann man jeden im Netz bekannten Rechner erreichen und alle dort freigegebenen Verzeichnisse ansprechen (unter Unix geht das übrigens auch, da werden dann normale Slashes / verwendet).
Nun braucht man aber für SMB auch eine Benutzer-Authentifikation. Während man NFS-(oder Samba-)Mounts beim Bootvorgang erledigt und sich dabei entsprechend zu erkennen gibt (was bei NFSv3 kaum der Rede wert ist), erwartet ein Windows-Rechner die Authentifikation des Users, wenn er auf die Freigabe zugreifen will.
Eine Möglichkeit dieses Problem zu lösen besteht darin, die entsprechende Software mit dem Benutzerkonto eines Domänen-Administrators laufen zu lassen. Greift sie dann auf den UNC-Pfad zu, gibt sie dabei die Identität ihres Benutzers an. Ist dieser auch auf dem entfernten Rechner bekannt, gewährt dieser den Zugriff. Allerdings ist nicht jeder System- und Netzwerk-Admin damit einverstanden, irgend welche Programme im Kontext eines so mächtigen Users laufen zu lassen.
Die Alternative ist, dass sich die Software bei jedem Zugriff mit einem vorgegebenen Benutzer anmeldet. Das kann dann zum Beispiel so aussehen:

SMB-Angaben
Angaben für eine SMB-Authentifikation in Lobster data

Natürlich muss die Software dazu in der Lage sein…

Der kleine Unterschied

Im Prinzip kann eine Software also auf freigegebene Verzeichnisse entfernter Rechner genau so leicht zugreifen wie auf die lokalen Platten. Ein paar kleine Einschränkungen gibt es dann aber doch.
Die einfachste davon ist, dass der Server, auf dem das gewünschte Verzeichnis liegt, gerade nicht läuft oder durch eine Netzwerkstörung nicht erreichbar ist. Das kann einem allerdings beim Zugriff z.B. via FTP genau so passieren.
Eine andere Einschränkung ist die, dass man sich nicht zu sehr der Illusion hingeben sollte, dass man es mit einem lokalen Verzeichnis zu tun hat. Nicht nur ist die Zugriffszeit schlechter, da ja alles über’s Netz geht, man kann sich auch nicht auf die selben Mechanismen verlassen, die bei lokalen Laufwerken das Leben einfacher machen.
Als einfaches Beispiel seien File Events genannt. Sie kennen das vielleicht: Sie haben den Windows-Explorer offen, irgend ein Prozess legt eine neue Datei ab oder löscht eine weg, und Sie sehen die Veränderung sofort, auch ohne erst zu aktualisieren. Hier wurde das Ereignis (Datei hinzugekommen/gelöscht) als Nachricht ins System geschickt, und der Explorer konnte sofort darauf reagieren und die Anzeige aktualisieren. Über das Netz funktioniert so etwas nur sehr unzuverlässig. Der Grund mag durchaus sein, dass man die Netzwerklast nicht mit solchen Kleinigkeiten hochtreiben will. Der Nachteil ist, dass sich eine Software plötzlich, nur, weil es sich um eine Netzwerkressource handelt, auf diesen Mechanismus nicht mehr verlassen kann.

Nutzen für EDI/EAI

Beim Datenaustausch von EDI-/EAI-Systemen mit anderen Prozessen sind lokale oder Netzwerk-Dateisysteme erst mal eine einfache Lösung. Allerdings sollte man dabei nicht vergessen, dass man dem betreffenden System zwar eine Datei zur Verarbeitung bereitstellen kann, es aber selbst nachsehen muss, ob es neue Arbeit gibt (File events sind, wie erwähnt, nicht verlässlich). Das bedeutet, die diversen Empfänger müssen regelmäßig „ihre“ Verzeichnisse nach neuen Dateien durchsuchen, ganz ähnlich wie beim Datenaustausch mittels FTP. Im eigenen Firmennetz muss man sich aber normalerweise wenigstens keine Sorgen um abgehörte oder gar manipulierte Übertragungen machen.
Manche etwas einfachere Software bietet schlicht nur eine solche Dateischnittstelle – oder man kann sie zumindest irgendwie dazuprogrammieren. Da bleibt einem dann also gar nichts anderes übrig. Gibt es aber andere Möglichkeiten, die gewährleisten, dass angelieferte Daten sofort in die Verarbeitung gehen, sollte man doch lieber darauf zurückgreifen.