Unix allein bietet sicherlich nicht die Betriebsmittel zur Realisierung einer "universellen" Datenfernübertragung. Die komfortablen Vernetzungseigenschaften des Systems erlauben jedoch eine Kopplung zu fast allen gängigen Betriebssystemen mit einem zum Teil hohem Grad an Transparenz. So können die zahlreichen DFÜ-Standardanwendungen (insbesondere MS-DOS) unter Beibehaltung einer zentralen Steuerung zur "universellen" Datenfernübertragung mit vertretbarem Aufwand genutzt werden. Weiterhin ermöglicht die Verfügbarkeit von Unix auf Rechnern unterschiedlichster Leistung eine flexible Anpassung an die Performance-Anforderungen des Systems, ohne aufwendige Softwareportierungen durchführen zu müssen.

Ein Großteil der auszutauschenden Daten betreffen heute im besonderen den Zahlungsverkehr zwischen Banken und industriellen Großunternehmen. In zunehmendem Maße werden auch allgemeine Informationsdaten wie zum Beispiel Börseninformationen Gegenstand des Datenaustausches.

Zusätzlich kommen Anforderungen aus dem Bereich mittelständischer Unternehmen, die über unterschiedlichste Rechnersysteme verfügen. Auch private Personen fordern infolge der Verbreitung von preiswerten PC-Systemen Dienstleistungen, die einen Datenaustausch benötigen. Gerade für diesen weit gefächerten Bereich fällt es Betreibern größerer EDV-Systeme schwer, einen geeigneten Zugang zu schaffen. Dies betrifft insbesondere die Kreditinstitute, die als Clearing-Institutionen besonders gefordert sind, einen Datenaustausch-Service zur Verfügung zu stellen, der die oben genannten Forderungen erfüllt.

Die übergeordneten Rahmenbedingungen hierfür sind gegeben durch:

- Bedienung unterschiedlichster DFÜ-Verfahren zum Datenaustausch,

- automatisierte Abläufe,

- zentrale Administration und Systembedienung,

- Host-unabhängige Verfügbarkeit,

- Zugriffsschutz der Host-Systeme,

- Einsatzmöglichkeit von Standardanwendungen,

- Erweiterbarkeit für zukünftige Anforderungen.

In der Vergangenheit sind in den Unternehmen für einzelne Übermittlungsverfahren jeweils unabhängige Systeme geschaffen worden, die teilweise sogar problemspezifisch installiert sind. Diese Systeme stellen in der Regel Insellösungen dar, die durch eine umständliche und komplexe Bedienung die gewünschte Verfahrensvereinfachung der Datenübermittlung zumindest auf der Seite des Dienstleistenden in Frage stellen.

Im folgenden werden die Problematiken und Konsequenzen eines dedizierten, von der zentralen DV bewußt entkoppelten Systems beschrieben, das eine Zusammenfassung von Insellösungen zu einem integrierten System unter den oben genannten Rahmenbedingungen ermöglicht (siehe Abbildung 1).

Integration bestehender Kommunikationsverfahren

Einige klassische Beispiele für Kommunikationsverfahren, die heute zum Datenaustausch zwischen EDV-Systemen genutzt werden, sind in Tabelle 1 aufgeführt.

Neben den bestehenden sind auch zukünftige Datenaustauschverfahren zu berücksichtigen, soweit deren Entwicklung heute schon abzusehen ist. Hierzu zählen insbesondere die Ergebnisse von Standardisierungsvereinbarungen diverser Verbände aus Industrie und Handel (zum Beispiel ISO, CCITT sowie BDB, VDA). Insbesondere für die ISO-Norm FTAM sind schon heute Strukturen zu schaffen, die Entwicklung und Einsatz erleichtern bzw. unterstützen. Mit diesem Verfahren soll in Zukunft ein neuer systemübergreifender Standard geschaffen werden. Das FTAM-Verfahren hat das Stadium der Konzeption allerdings gerade erst überschritten, wie sich das Produkt bei Herstellern und Anwendern durchsetzt, bleibt abzuwarten.

Aus der Betrachtung der eingesetzten Verfahren lassen sich folgende Punkte an ein integriertes System als allgemeine Forderungen aufführen:

þIntegration der bestehenden Anwendungen zum Datenaustausch

Zur Zeit im Einsatz befindliche Datenaustausch-Anwendungen müssen möglichst vollständig auf dem zukünftigen System realisiert beziehungsweise abgelöst werden. Dabei sind die bestehenden Eigenentwicklungen mit möglichst geringem Aufwand zu übernehmen.

þKontrollen für Remote-Zugang

Keiner der Kommunikationspartner (Dritte) darf eine Möglichkeit haben, auf Daten des Host-Systems zuzugreifen. Der Zugriff für Dritte auf das dedizierte System muß auf die Daten beschränkt sein, die dem Dritten zugeordnet sind. Weiterhin darf es Dritten nicht möglich sein, Prozesse jeglicher Art auf dem Host-System und/oder dem dedizierten System zu initiieren.

þAlle Postdienste sind zu unterstützen

Für einen Datentransfer sind alle Möglichkeiten der heute bestehenden Postdienste verfügbar zu machen.

þAnforderungsspezifische Investitionen

Die Kosten für die Installation müssen den Anforderungen und der Auslastung des Systems anpaßbar sein.

Die Hardwarearchitektur muß folgende Forderungen erfüllen:

þhomogene Hardwarekomponenten

Es sind möglichst einheitliche Hardwarekomponenten zu wählen, da diese eine Voraussetzung für eine zentrale Bedienung darstellen; der Integrationsgrad der Hardwareeinheiten ist entsprechend hoch. Dabei muß das System bedarfsgerecht konfigurierbar sein.

þkleine Hardwareeinheiten

Ein modularer Aufbau des Systems mit kleinen Einheiten stellt neben der Möglichkeit anforderungsspezifischer Investitionen auch den flexiblen Austausch einzelner Komponenten zum Beispiel bei Ausfall offen.

þUnterstützung von Standardprotokollen

Die in der DV-Landschaft verbreiteten Protokolle für Datenübertragungen müssen implementierbar sein.

þfehlertolerante Hardware

Die Forderung nach kleinen Hardware-Einheiten ist die Voraussetzung, im Bedarfsfall, zum Beispiel nach einem Rechnerausfall, Aufgaben entweder durch andere Systeme im Verbund zu übernehmen oder kurzfristig bereitstehende Ersatzgeräte einzusetzen. Dabei sollte ein Gesamtausfall aller Systeme ausgeschlossen sein. Der Aufwand für eine Änderung der bestehenden Architektur ist so klein wie möglich zu halten. Zusätzliche technische Möglichkeiten, welche die Datensicherheit erhöhen (zum Beispiel Spiegelplatten), sollten genutzt werden.

Auch an die verwendete System-Software sind Forderungen zu stellen:

þsystemweit transparentes Dateisystem

Die Dateien des Systems sollten als ein einheitliches Filesystem erscheinen, um eine Integration zu gewährleisten.

þsystemtransparentes Prozeß-System

Für eine zentrale Steuerung aller Abläufe ist es erforderlich, daß vorhandene Kapazitäten systemweit nutzbar und zugreifbar sind.

þProgrammierung und Anwendungen systemunabhängig

Um die Erstellung von Software für das System auch für zukünftige Systeme beziehungsweise Erweiterungen offen zu halten, sollte eine Programmentwicklung unabhängig vom verwendeten System möglich sein. Hierbei sind die Programmiersprachen "C" und COBOL von entscheidender Bedeutung.

Durch geeignete Schnittstellen (unter Verwendung dieser Sprachen) sollte systemnahe Software neutral gehalten werden.

þEinsatzmöglichkeiten von Standardsoftware

Der Einsatz von Standardprogrammen ohne aufwendige Eigenentwicklungen sollte möglich sein. Hierbei sind insbesondere die zahlreichen MS-DOS-DFÜ-Anwendungen zu berücksichtigen.

þBatchorientierung der Kommunikationssoftware

Die für die Kommunikation eingesetzte Software muß möglichst von außen, das heißt, durch Steuerungsprogramme beeinflußbar sein. Manuelle Eingriffe zur Steuerung der

Übertragungen sollten grundsätzlich nicht notwendig sein.

Prinzipiell hat das System die Aufgabe, einen Datenaustausch zwischen zentralen Verarbeitungsrechnern und beliebig vielen Kommunikationspartnern mit unterschiedlichen Übertragungsverfahren und Protokollen zu realisieren.

Ein solches System läßt sich in mehrere logische Ebenen unterteilen, die es zwischen dem Verarbeitungsrechner und den Partnersystemen aufgliedern.

Bei dieser Unterteilung lassen sich die einzelnen Ebenen getrennt betrachten, die benötigten Schnittstellen zwischen den Ebenen können unabhängig voneinander definiert werden. Dazu müssen jedoch alle Ausprägungen der jeweiligen Ebenen bekannt sein.

Ebene 1:

Die Ebene 1 beinhaltet die dezentralen Systeme der Dritten.

Ebene 2:

Jedes System auf der Ebene 1 bedient sich einer Datenübermittlung über einen Postdienst. Die Anzahl der Datenübermittlungsleitungen ist wie die Anzahl der Dritten zur Zeit nicht festgelegt.

Ebene 3:

Auf der Ebene 3 werden alle Protokolle betrachtet, die für eine Datenübertragung in Frage kommen. Die verwendeten Protokolle sind abhängig von den Herstellern der Rechner und der eingesetzten Systemsoftware aller Dritten, die am Datenaustausch teilnehmen.

Ebene 4:

Neben der rein physikalischen Richtigkeit der Datenübertragung (geregelt durch Ebene 3) ist es auch wichtig, Dateninhalte zu kontrollieren. Das können zum Beispiel Berechtigungsschlüssel, aber auch Datenverschlüsselungen und Datenformate sein. Unabhängig von der Datenübertragung ist also auch eine Verarbeitung notwendig, die sich auf die Dateninhalte stützt.

Ebene 5:

Das System arbeitet autonom gegenüber den Verarbeitungs-Rechnern. Das ist notwendig, um neben einer vom Verarbeitungs-System unabhängigen Verfügbarkeit auch im Backup-Fall ausreichende Sicherheiten zu bieten. Daher werden Daten zwischen dem Zeitpunkt des Datenaustausches mit Dritten und dem Transfer vom/zum Verarbeitungs-Rechner in Pools gepuffert.

Ebene 6:

Die Aufgabe der Kopplung zum Verarbeitungsrechner ist es, einen möglichst schnellen und sicheren Datenaustausch mit dem dedizierten System zu ermöglichen, ohne den laufenden Betrieb auf der jeweiligen Anlage übermäßig zu belasten.

Ebene 7:

Diese Ebene beschreibt Pools für DFÜ-Daten auf dem Verarbeitungs-Rechner, die alle empfangenen und zu versendenden Daten der Verarbeitungsseite aufnehmen. Die einzelnen Pools werden entweder nach Anwendungen unterschieden, oder beinhalten die gesammelten Daten, die auf unterschiedliche Anwendungen verteilt werden.

Ebene 8:

Die oberste Ebene erfüllt die Aufgabe, die Verbindung zwischen den Pools auf dem Verarbeitungs-Rechner und den verarbeitenden Programmen herzustellen.

Die Abläufe der Ebenen 3 bis 6 müssen von einem zentralen Steuerungsmechanismus überwacht werden. Dieser kontrollierende Prozeß muß Zugriff auf alle laufenden Prozesse haben und Informationen über die Zustände von Datenleitungen, ein- und ausgehende Daten (Dateien) und die Berechtigungen von Dritten verwalten.

Die Abbildung 3 veranschaulicht das Systemmodell, in dem sich die einzelnen Betrachtungsebenen wiederfinden.

Im folgenden werden die Komponenten erläutert:

þDie Dritten

Den Systemen der Kommunikationspartner soll es ermöglicht werden, Daten beziehungsweise Dateien zu senden und zu empfangen.

þPostdienste

Die heute von der Post angebotenen Möglichkeiten zur Datenübertragung sind bis auf wenige Ausnahmen nicht dafür ausgelegt, große Datenmengen zwischen Rechnern auszutauschen. Die Postdienste eignen sich eher für Dialoganwendungen beziehungsweise den Austausch von Informationen (zum Beispiel Dokumenten etc.). Leider ist auch in absehbarer Zeit eine Verbesserung dieser Situation nicht abzusehen, flächendeckende digitale Netze mit hohen Übertragungsraten sind in naher Zukunft nicht verfügbar.

Für eine Übertragung kommen zum jetzigen Zeitpunkt in Frage:

- das Fernsprechnetz,

- HfD (Standleitung),

- Datex-P-Netz,

- Datex-L-Netz.

þDie DFÜ-Module

Die Realisierung der benötigten Protokollverfahren zum Datenaustausch unterscheidet sich grundsätzlich nach dem Aufwand; dieser reicht vom Einsatz eines Standardverfahrens bis zur vollständigen Neuimplementation eines Protokolls. Daher werden im folgenden fünf Typen für die Realisierung von Protokollen unterschieden:

- Typ I: Die Black-Box

Als Black-Box sind alle Standard-Software-Produkte anzusehen, die für ein oder mehrere Kommunikationsprotokolle mit Dritten außer der physikalischen Datenübertragung und dem notwendigen Protokoll auch eine eigene Überwachung der Datenleitungen und der Zugangsberechtigungen bieten.

- Typ II: Standardanwendungen

Standardanwendungen stellen eine Möglichkeit dar, Protokolle mit geringem Aufwand zu implementieren; dabei kann die Steuerung und Überwachung des Datenaustausches in der Regel über definierte Schnittstellen vorgenommen werden, womit der Integrationsgrad erheblich höher ist als bei Typ I. Die Einsatzmöglichkeiten von Standardanwendungen sind jedoch stark von der eingesetzten Hardwarearchitektur abhängig. Abgesehen von dem Industriestandard der MS-DOS-Rechner ist es nur schwer möglich, Standardprotokolle zu installieren, die herstellerfremd sind, daher ist man unter Umständen gezwungen, will man keine aufwendige Eigenentwicklung betreiben, Hardware von unterschiedlichen Herstellern zur Realisierung zu verwenden.

- Typ III: Adaption bestehender Anwendungen

Bestehende Programme können unter Beibehaltung ihrer Funktion durch Adaption auf das neue System übernommen werden.

- Typ IV: Migration bestehender Anwendungen

Die Migration der bestehenden Anwendungen beinhaltet eine volle Integration in das neue System, wobei auch die Portierung auf einen neuen Rechner notwendig sein kann.

- Typ V: Neuentwicklungen

Eine Neuentwicklung ist überall dort notwendig, wo weder über eine Standardsoftware noch über eine bestehende Anwendung eine ausreichende Integration erreicht werden kann.

Systeme weitgehend bedienerlos arbeiten lassen

In Tabelle 2 werden die oben genannten DFÜ-Module anhand einiger Kriterien, die die Einbindung in das System kennzeichnen, grob bewertet.

Hierbei werden zwei gegenläufige Interessen deutlich: Forderungen nach Flexibilität des Systems gegenüber bestehenden und zukünftigen Anforderungen und nach geringem Implementierungsaufwand stehen im Gegensatz zu einem geringen Administrationsaufwand und einer niedrigen Komplexität des Systems.

þSteuerung

Das System sollte weitgehend bedienerlos arbeiten. Um einen reibungslosen Ablauf der Kommunikationsprozesse zu gewährleisten, ist daher ein Regelsystem notwendig, das in der Lage ist, alle Aktivitäten zu überwachen.

Die Steuerungsmöglichkeiten der DFÜ-Module sind je nach verwendetem Typ (siehe oben) unterschiedlich.

Als Grundlage für Transaktionen dient dem Regelwerk eine Datenbank mit Informationen über die zu veranlassenden Aktivitäten bei definierten Ereignissen. Außerdem wird der Status der jeweiligen Übertragungen überwacht, um jederzeit einen konsistenten Zustand der Daten zu gewährleisten.

þKopplung zum Verarbeitungsrechner (Host-Systeme)

Die Verarbeitungsrechner übernehmen die zentrale Anwendungsverarbeitung der Daten. Dem Datenaustausch zwischen Host und dediziertem System kommt dabei eine besondere Bedeutung zu, da hier ein hoher Datendurchsatz bei gleichzeitiger Sicherheit der Übertragung gewährleistet sein muß.

þAdministration

Aufsetzend auf das Regelsystem stellt die Administration die einzige Benutzerschnittstelle des Systems dar. Dabei ist entsprechend den Anforderungen eine zentrale Administration von einem Arbeitsplatz aus vorzusehen.

Kriterien für die Umsetzung des Modells

þHardware

Wegen der Vielzahl der Datenleitungen, die benötigt werden, um einen Datenaustausch mit Systemen Dritter durchführen zu können, ist es wichtig, daß die Hardware Standardanwendungen für Kommunikationsprotokolle und Protokolle einsetzt, die gleichzeitig ablauffähig sind. Ein weiteres Kriterium ist die Plattenspeicherkapazität, da das dedizierte System als Zwischenspeicher für Daten fungiert. Zur Sicherstellung der Daten ist der Einsatz von Spiegelplatten oder sogar von Parallelsystemen zu überlegen, da hiermit eine maximale Verfügbarkeit des Systems gewährleistet werden kann.

Entsprechend den Anforderungen muß die Hardware variabel in der Ausbaufähigkeit sein. Dies bezieht sich insbesondere auf die Erweiterbarkeit hinsichtlich der Kommunikationsprotokolle, der Speicherkapazität und der Rechenleistung. Ziel ist, Installationen mit einem einheitlichen System für wenige bis zu beliebig viele Dritte zu ermöglichen.

þSystemsoftware

Die Systemsoftware muß gewährleisten, daß die zum Einsatz kommende Hardware ein möglichst hohes Maß an Integration bietet. Insbesondere ist eine Transparenz der Datei-/Prozeß-Systeme der beteiligten Rechner von Bedeutung.

Das für die Steuerung verwendete Betriebssystem muß multitaskingfähig sein (somit scheidet MS-DOS als Trägerbetriebssystem aus). Weiterhin muß es möglich sein, unterschiedliche Systeme mit fremden Betriebssystemen mit einem hohen Integrationsgrad anzubinden.

Notwendige Entwicklungen sollten systemunabhängig möglich sein, um einerseits unterschiedliche Systemsoftware mit einer einheitlichen Oberfläche bedienen zu können und andererseits offen gegenüber zukünftigen Entwicklungen zu sein.

Als mögliche Sysstemarchitekturen kommen dafür in Frage:

þtransparentes Verbundsystem

Unter einem solchen System ist ein Verbund zu verstehen, der wegen seiner Transparenz von Dateien und Prozessoren als ein modulares Host-System dem Anwender und Entwickler erscheint.

þnichttransparentes Verbundsystem

Ein nichttransparentes Verbundsystem ist ein Netz aus (unterschiedlichen) Rechnern mit zum Teil unterschiedlichen Betriebssystemen, welche unabhängig voneinander arbeiten und über eine gemeinsame Filetransfer-Schnittstelle untereinander Daten austauschen können.

þServer-Verbundsystem

Für die im Verbundsystem arbeitenden Rechner steht ein zentral geführtes Dateisystem zur Verfügung. Dieses erscheint den einzelnen Anwendungen transparent.

Die Eigenschaften der Systemarchitekturen in Hinblick auf die Problemstellung werden in Tabelle 3 aufgezeigt.

Ein Verbundsystem als integrierte Lösung erfüllt generell einen Großteil der Anforderungen. Für die Komponenten Regelung und Administration stellt ein transparentes Verbundsystem optimale Betriebsmittel zur Verfügung. Die flexible Ausbaufähigkeit ermöglicht eine dynamische Anpassung an wachsende Anforderungen. Eine Integration der DFÜ-Module vom Typ I und Typ II ist bereits mit einem nichttransparentem Verbundsystem möglich. Auch die Anpassung an Anforderungen hinsichtlich Leistung und OEM-Einbindung ist durch kleine Komponenten effizient gelöst. Dem steht ein hoher Administrationsaufwand gegenüber.

Server-Verbundsysteme (zum Beispiel PC-Netzwerke) sind ausgerichtet auf das Betriebssystem MS-DOS. Die leistungsstarken Tools für eine Vernetzung dieser Systeme sind ausschließlich für Dialoganwendung konzipiert und bieten nur wenige Möglichkeiten einer zentralen Steuerung von Batch-Abläufen. Das Serverprinzip eignet sich besonders zur Einbindung von MS-DOS-Standardanwendungen. Unter den Aspekten der Datensicherheit ist ein auf dem Serverprinzip basierendes Dateisystem besonders von Bedeutung, da hier eine zentrale Datenverwaltung vorliegt.

Aufgrund der bisherigen Betrachtung erscheint ein transparentes Verbundsystem geeignet als Basis für eine Realisierung. Doch sollte dieses System einerseits MS-DOS-Serverfunktionen zur Verfügung stellen, um vorhandene DFÜ-Softwarepakete nutzen zu können und andererseits die Einbindung vom OEM-Systemen als nichttransparente Komponenten erlauben (wo eine transparente Einbindung nicht möglich ist).

Zur Erfüllung der gestellten Anforderung bieten sich aus heutiger Sicht die Konzepte des Betriebssystems Unix besonders an. Für die Anbindung von unterschiedlichen Kommunikationsprotokollen stehen hier teilweise standardisierte Verfahren zur Verfügung.

Weiterhin werden von den Anbietern komfortable Betriebsmittel (DOS-Server/Emulationen, diverse Tools) zur Verfügung gestellt, die eine Einbindung unterschiedlichster Protokolle erleichtern.

Betriebssystem Unix im Rechnerverbund

Als mehrplatzfähiges Multitasking-System stellt Unix bereits auf einem Rechner ein leistungsfähiges Kommunikationssystem dar. Die besondere Bedeutung von Unix als Entwicklungssystem ist dabei mit Sicherheit unumstritten. Vor allem ab Version V werden Betriebsmittel geboten, die es erlauben, komplexe Anwendungen zu realisieren, die mit Host-Applikationen vergleichbar sind.

Im Bereich der Datenhaltung (der von Unix nur stark eingeschränkt unterstützt wird) bieten diverse Hersteller mächtige Tools und Datenbanksysteme an, die zum Teil systemübergreifend genutzt werden können.

Zur Erfüllung der zuvor genannten Forderung nach Erweiterbarkeit und Anbindung von Standardprodukten ist eine Vernetzung erforderlich. Dabei hat sich als Vernetzungsmedium für ein Unix-Verbundsystem in der Vergangenheit Ethernet (IEEE 802.3) etabliert und wird auch in Zukunft nicht an Bedeutung verlieren.

Die systemseitige Implementation der Rechnerkopplung über Ethernet erfolgt dabei mit unterschiedlichen Verfahren. Als das am stärksten unterstützte Protokoll (IBM, Siemens, DEC, Sun und viele andere) gilt TCP/IP, das betriebssystemübergreifend zur Verfügung steht. Neben der Möglichkeit der Terminalemulation bietet das Protokoll einen File-Transfer und ein Remote-Processing. Das auf den Schichten 3 und 4 des ISO/OSI-Modells anzusiedelnde Protokoll ist unabhängig vom verwendeten Medium, womit die Möglichkeit besteht, über mehrere unterschiedliche Netzwerke übergreifend ein Verbundsystem zu schaffen, ohne die Transparenz zu verlieren. Die in vielen Unix-Systemen enthaltene Socket-Schnittstelle kann darüber hinaus zur netzweiten Programm-zu-Programm-Kommunikation genutzt werden.

Die geforderte Transparenz im Rechnerverbund auf der Ebene der Daten wird durch die Möglichkeit von netzweiten Dateisystemen erreicht. Hier existiert als herstellerübergreifender Standard NFS (Network-File-System) der Firma Sun Microsystems. Es erlaubt jedem Rechner, auf Directory-Ebene Sub-Dateibäume beliebiger anderer Rechner (ebenfalls mit NFS) transparent in den lokalen Dateibaum zu integrieren. NFS basiert dabei auf der IP-Komponente des TCP/IP-Protokolls und beschränkt sich nicht ausschließlich auf Unix-Systeme. Auch für MS-DOS, VMS und andere existieren NFS-Implementationen. Die Abbildung 4 veranschaulicht die genannten Vernetzungseigenschaften.

Unix bietet weiterhin Möglichkeiten, die eine enge Anbindung von MS-DOS/OS2-Systemen an das Verbundsystem ermöglichen. Hierzu zählen vor allen MS-DOS-Emulationen und Netzeinbindungen der jeweiligen Dateisysteme (Serverdienste).

Unter Betrachtung der Zielsetzungen und der gestellten Anforderung an ein dediziertes, integriertes System als Funktionsträger für einen Datenaustausch mit unterschiedlichen DFÜ-Verfahren bietet ein auf Unix basierendes System ausreichend Möglichkeiten. Für einige Standard-DFÜ-Protokolle ist es jedoch erforderlich, auch andere Systeme zu berücksichtigen. Gleiches gilt unter Umständen auch für die Integration von bestehenden Implementationen. Auch hierfür stehen unter Unix im Verbundsystem unterschiedliche Tools zur Verfügung, um eine vom Implementations- und Administrationsaufwand vertretbare Anbindung dieser Fremdsysteme zu ermöglichen. Die Abbildung 5 soll zum Schluß eine mögliche Konfiguration für ein dediziertes, integriertes System aufzeigen.