*Rainer Janssen ist Mitarbeiter in der Zentralabteilung Informatik und Kommunikation bei der Hoechst AG, Frankfurt am Main. Bei dem Beitrag handelt es sich um eine überarbeitete und gekürzte Fassung eines Referats zum Count-Symposium "OSI-Implementierung, Nutzungsaspekte offener Kommunikation" (Anfang Dezember 1987 in Leinfelden).
FRANKFURT - Die Frankfurter Hoechst AG, die sich ganz der offenen Kommunikation verschrieben hat, möchte bei Büroanwendungen nicht nur auf einem Bein stehen. Darum hat sich der Chemiekonzern dazu entschlossen, verschiedene Systeme einzusetzen und diese auf der Basis von X.400 zu verbinden, Selbsthilfe ist bei Hoechst dabei in den Bereichen angesagt, wo es um die Einbettung von OSI in die vorhandene Umgebung geht. So baut das Unternehmen laut Rainer Janssen* bei der Adressierung auf eine selbstgestrickte Interimslösung, da die Standardisierung für Directory-Dienste noch aussteht.
Die Einführung von Systemen zur Realisierung elektronischer Post im Konzern stellt eine große Unterstützung in vielen Bereichen dar (unter anderem Terminabsprachen, gemeinsame Erstellung von Texten, Kommunikation mit Auslandsgesellschaften). Heute werden abhängig von der jeweiligen Rechnerumgebung unterschiedliche Büroorganisations- beziehungsweise elektronische Postsysteme benutzt, so zum Beispiel Memo, Disoss und Profs von IBM, All-in-1 von Digital Equipment, Deskmanager von Hewlett-Packard und Quik-Comm von General Electric.
Hoechst verfolgt das Ziel, weltweit im Konzern die Möglichkeit des elektronischen Nachrichtenaustausches einzurichten. Da keinem Benutzer eines der beschriebenen Systeme zugemutet werden kann, jeden Tag in mehrere Briefkästen hineinzuschauen und mit jeweils unterschiedlichen Benutzeroberflächen zu arbeiten, gelten folgende Prinzipien bei der Realisierung eines Verbundes zum elektronischen Nachrichtenaustausch:
- nur ein Bildschirm pro Benutzer,
- möglichst keine Veränderung der gewohnten Benutzeroberfläche (die Bedienung sollte zum Beispiel nicht vom Zielsystem einer Nachricht abhängen),
- Integration der vorhandenen Hardware,
- Nachricht einmal erstellen und an beliebige Teilnehmer in unterschiedlichen Systemen verteilen.
Vor dem Hintergrund der gegebenen Rahmenbedingungen (Heterogenität, internationale Kommunikationsanforderungen) hat sich Hoechst entschlossen, sein Vorgehen im Bereich Electronic Mail nicht auf ein einziges Büroorganisationssystem abzustellen, da auf diese Art und Weise nur ein Teil der Anforderungen abgedeckt werden könnte. Darüber hinaus bedeutet die Entscheidung für ein bestimmtes System aus unserer Sicht eine zu große Herstellerabhängigkeit.
Hoechst hat es sich daher zum Ziel gesetzt, die vorhandenen oder künftigen Bürokommunikations- und Postsysteme mit Schnittstellen gemäß der Empfehlung X.400 auszurüsten und unter Nutzung von X.25-Netzen zu verbinden. In Ländern, in denen kein X.25-Netz verfügbar ist, werden wir uns des Netzes eines speziellen Anbieters bedienen. Der Schwerpunkt des bisher verfügbaren Standards liegt auf dem Nachrichtentransport. Andere Leistungen, wie beispielsweise Directory-Dienste, werden derzeit noch entwickelt. Die Verabschiedung des entsprechenden Standards X.500 steht im Laufe dieses Jahres ins Haus.
Im Zuge der E-Mail-Planungen und -Realisierungen wurde zunächst in Gesprächen mit mehreren Herstellern versucht, den jeweiligen Stand der Dinge zu klären, um zukünftige Entwicklungen im Bereich Message Handling transparenter machen zu können. Außerdem erprobte das Unternehmen im Rahmen eines Feldversuches einige X.400-Pakete, so zum Beispiel den Message-Router von DEC und Targon-Mail von Nixdorf. Das Anfang 1987 installierte DEC-Produkt dient zur Anbindung von All-in-1 auf VAX-Systemen. Zu diesem Zeitpunkt wurden darüber hinaus die Verbindung von Memo und Quik-Comm über eine spezielle Brücke als Zwischenlösung und die Einrichtung von Briefkästen auf Systemen bei Hoechst für Teilnehmer weltweit, die über kein eigenes Electronic-Mail-System verfügen (Zugang über öffentliche Netze), "in die Tat umgesetzt". Ende 1987 kam es zur Anbindung von Quik-Comm/ X.400 und zur Kommunikation mit der amerikanischen Hoechst-Tochtergesellschaft auf X.400-Basis. Die Hoechst Celanese benutzt hierfür ein DEC-System auf der Basis des OSI-Protokolls, welches über eine spezielle Brücke mit dem System Profs von IBM verbunden ist.
In diesem Jahr steht die Nutzung von Profs (mit DFN-Lizenz), Telebox, Deskmanager und Memo nach X.400 an.
Im Sinne unserer Strategie bilden die X.400 fähigen Systeme das Rückgrat dieses Verbundes, das heißt nicht-X.400 fähige Systeme werden nach Möglichkeit nicht über spezielle Gateways direkt miteinander verbunden, sondern unter Nutzung eines X.400-Systems in den Verbund einbezogen. Bei diesem Verbund sind Directory-Probleme zu lösen. Die Verabschiedung der CCITT-Empfehlung X.500 für Directory-Dienste wird im Herbst '88 erwartet, mit ihrer praktischen Verfügbarkeit ist jedoch erst in mehreren Jahren zu rechnen. Bei der Realisierung von Übergangslösungen muß geprüft werden, ob durch einen hohen zusätzlichen Programmieraufwand die fehlende Funktionalität der heute verfügbaren Systeme ausgeglichen und dabei einige Programme realisiert werden, die man in einigen Jahren nicht mehr benötigt. In Erwägung zu ziehen ist auch, für eine Übergangszeit gewisse Einschränkungen zu akzeptieren und einen Kompromiß zu realisieren, der es ermöglicht, die Funktionen heutiger Systeme zu nutzen und mit einem geringen Anteil an Eigenprogrammierung auszukommen.
Wir haben uns für den zweiten Weg entschieden, um möglichst schnell einen breiten Verbund unter Einbeziehung unterschiedlicher Systeme aufbauen zu können. Der im folgenden beschriebene Ansatz gilt jedoch nur für die Kommunikation innerhalb des Unternehmens, da er mit gewissen technischen und organisatorischen Konsequenzen verbunden ist. Ein entscheidender Gesichtspunkt bei der Betrachtung der heutigen Situation (X.400 fähige und nicht-X.400 fähige Systeme in einem gemeinsamen Verbund) besteht in der Frage der Adressierung der Teilnehmer. Im X.400-Bereich benutzen wir die sogenannte "O/R Name Form 1.1 (Organisator/Rezipient), die aus mehreren Komponenten besteht: personal name, organisation name, unit name, private domain name, administration domain name und country code. Bei der Nutzung von Bürosystemen mit X.400-Schnittstelle tritt kein Adressierungsproblem auf, da das System eine solche Adresse erzeugen kann. Zu lösen ist in diesem Fall nur die Einbettung in die Benutzeroberfläche des Bürosystems (unter anderem Kurznamen). Einige der heute benutzten Systeme haben jedoch keine Möglichkeit, eine X.400-Adresse in obengenannten Sinne auf dem Umschlag einer Nachricht zu generieren. Es ergibt sich daher bei der Kommunikation zwischen X.400- und Nicht-X.400-Systemen ein Adreßumsetzungsproblem. Eine Möglichkeit der Adreßumsetzung besteht sicherlich darin, die X.400-Adresse des Empfängers in den Textteil einer Nachricht zu stellen und durch ein entsprechendes Programm auf dem sendenden X.400-fähigen System, über das die Nachricht geleitet wird, interpretieren zu lassen. Eine andere Möglichkeit besteht in der Installation von Umsetztabellen auf den X.400-Systemen. In solchen Tabellen müßte aber für jeden möglichen Empfänger ein Eintrag vorhanden sein, der damit verbundene Aufwand zur Realisierung und Pflege wäre also sehr hoch.
Zwei Attribute für die Identifikation
Hoechst hat sich für eine Übergangslösung entschieden, bei der die Teilnehmer an der elektronischen Post durch die Angabe der beiden Attribute Benützeridentifikation und Systemidentifikation charakterisiert werden können. Die Benutzeridentifikation entspricht dem Namen des Benutzers, die Systemidentifikation kennzeichnet das elektronische Postsystem, an das der Benutzer angeschlossen ist. Im X.400- System, das der sendende Teilnehmer benutzt, erfolgt eine Umsetzung auf die X.400-Adresse des Empfängers, indem die Systemidentifikation auf, "unit", "prmd", "admd" und "country" abgebildet wird und die Benutzeridentifikation als Name erhalten bleibt. Das empfangene X.400-System prüft die X.400-Adresse, mit der der Empfänger in seinem System erreicht wird.
Keine Umsetztabelle der externen Empfänger
Der Vorteil dieser Übergangslösung für die heutige gemischte Welt besteht darin, daß jedes X.400-System nur ein Verzeichnis seiner eigenen Teilnehmer, der erreichbaren Domains, nicht aber eine Umsetztabelle bezüglich der externen Empfänger führen muß. Realisiert werden muß in jedem X.400-System eine Tabelle zur Umsetzung der Systemidentifikation in Teile der X.400-Adresse. Diese enthält aber nur einen Eintrag pro erreichbarem System und ist daher mit vertretbarem Aufwand zu pflegen. Wie bereits oben erwähnt, ist diese Übergangslösung nur innerhalb eines Unternehmens realisierbar, da sie mit den oben angeführten Konsequenzen bezüglich der Art der Teilnehmereinträge (kein Vorname und keine Organisation) verbunden ist.
Erschwerter Einstieg durch hohe Preise
In Ermangelung eines verteilten Directory-Dienstes werden zur Unterstützung der Benutzer Dateien zwischen den X.400-Systemen ausgetauscht, die für jeden Teilnehmer die Adreßattribute und weitere beschreibende Informationen wie Name, Vorname, Organisation, Stadt und Gebäude enthalten. Die X.400-Systeme leiten diese Dateien an die einzelnen an sie angeschlossenen Systeme (nicht X.400) weiter. Die Art der Interpretation dieser Informationen in die einzelnen Systeme hängt von den Möglichkeiten jedes Bürosystems ab und muß lokal organisiert werden. Die Notwendigkeit der oben beschriebenen Übergangslösung ergibt sich nicht aus Eigenschaften der X.400-Systeme, sondern aus der mangelnden Fähigkeit anderer Systeme, die benötigten Adressen zu generieren. Unser langfristiges Ziel ist, direkte X.400-Schnittstellen für alle Postsysteme zu nutzen.
Ganz allgemein läßt sich sagen, daß die Realisierung einer offenen Kommunikation wie Electronic Mail via X.400 in Industrieunternehmen nur möglich sein wird, wenn es gelingt, die Entwicklungen auf diesem Gebiet zu beschleunigen und Zwischenlösungen zu schaffen, die zum einen unseren heutigen Anforderungen genügen, zum anderen aber auch einen Schritt in Richtung der eigenen Zielsetzung darstellen. Ein Problem liegt hier sicherlich auch in der Preispolitik verschiedener Hersteller. Ein Produkt, welches die Ebene 4 des Referenzmodells realisiert, kann langfristig für viele Anwendungen genutzt werden, wird aber heute schon benötigt, wenn man "nur" elektronischen Nachrichtenaustausch gemäß X.400 betreiben möchte. Ein relativ hoher Preis für ein solches Produkt erschwert den Einstieg in die Welt der offenen Kommunikation für viele Anwender. Da in Zukunft diese Basisprodukte sicher noch sehr häufig vertrieben werden, sollten die Hersteller prüfen, ob der heutige hohe Preis und der damit verbundene erschwerte Einstieg für viele Anwender in ihrem Sinne ist.