Melden Sie sich hier an, um auf Kommentare und die Whitepaper-Datenbank zugreifen zu können.

Kein Log-In? Dann jetzt kostenlos registrieren.

Falls Sie Ihr Passwort vergessen haben, können Sie es hier per E-Mail anfordern.

Der Zugang zur Reseller Only!-Community ist registrierten Fachhändlern, Systemhäusern und Dienstleistern vorbehalten.

Registrieren Sie sich hier, um Zugang zu diesem Bereich zu beantragen. Die Freigabe Ihres Zugangs erfolgt nach Prüfung Ihrer Anmeldung durch die Redaktion.

25.02.1994

Ein Telematikdienst im Umbruch X.400 als Grenzgaenger zwischen Buero- und Multimedia-Diensten

X.400 als Standard fuer eine unternehmensuebergreifende elektronische Post hat noch lange nicht ausgedient. So jedenfalls lautet die These von Dirk Nouvortne* und Michael Schmidt*. Beide Autoren schildern den aus ihrer Sicht notwendigen Massnahmenkatalog bei der Einfuehrung eines integrierenden Mail-Systems und machen dabei deutlich, dass X.400 auch im Hinblick auf spaetere Multimedia- Szenarien ein sinnvolles Uebertragungsinstrument sein kann.

Gegenwaertig wird die Buerokommunikation von einer Diskussion um die beiden Konzepte "Workflow" und "Groupware" bewegt. Waehrend der Workflow-Ansatz darauf abzielt, operative Ablaeufe weitgehend elektronisch festzulegen, betont der Groupware-Ansatz die elektronische Unterstuetzung einzelfallbezogener Aufgaben in einer arbeitsteiligen Organisation. E-Mail ist dabei durchaus ein wesentliches Element beider Ansaetze.

Waehrend jedoch die elektronische Post im Kontext von Groupware als Tool dient, mit dem man Ansprechpartner ad hoc zur Problembewaeltigung kontaktieren kann, kommt sie im Zusammenhang mit Workflow-Konzepten eher als Vehikel im Rahmen eines festgesetzten Arbeitsprozesses zum Tragen. Groupware zielt also letztlich auf die Verbesserung der arbeitsteiligen Produktivitaet. Elementar notwendig dafuer sind Teamarbeit, Kommunikation und die - jedenfalls teilweise - Einbeziehung aller Medien.

Telematikdienste fuer asynchrone Kommunikation

Diese technische Unterstuetzung der "Computer Supported Cooperative Work" (CSCW) greift jedoch nur dann, wenn beide Kommunikationspartner synchron kommunizieren. Anders sieht es bei asynchronen Kommunikationsbeziehungen aus, wo Telematikdienste und dabei insbesondere E-Mail an Bedeutung gewinnen. Diese haben jedoch als Werkzeug nur dann signifikante Bedeutung, wenn nicht nur eine geschlossene Benutzergruppe - meist innerhalb einer homogenen Rechnerarchitektur - kommuniziert, sondern auch die Grenzen der jeweiligen Gruppe ueberschritten werden koennen.

Eine Moeglichkeit, Kompatibilitaetsprobleme beziehungsweise Medienbrueche dieser Art zu ueberwinden, bieten Loesungen auf Basis von X.400 - einem Standard, der bisher fast ausschliesslich im wissenschaftlichen Bereich diskutiert und etabliert wurde, mittlerweile aber so gefestigt ist, dass einem kommerziellen Einsatz nichts mehr im Wege stehen duerfte. Der Hauptvorteil von X.400 liegt vor allem in seiner Ausdehnung auf externe Teilnehmer, wobei die Informationszustellung schneller und kostenguenstiger erfolgt als bei anderen Telematikdiensten. Darueber hinaus ist es bei X.400 moeglich, innerhalb heterogener Rechnerwelten einzelne Kommunikationsinseln zu integrieren.

Die Funktionsweise von X.400 ist dem des herkoemmlichen Postwesens entnommen, dass heisst, ein "Anwender" im X.400-Dienst ist entweder (vereinfacht ausgedrueckt) eine spezifische DV-Applikation oder aber eine natuerliche Person. Diese funktionalen Einheiten koennen physikalisch unterschiedlich konfiguriert werden. So ist es beispielsweise moeglich, dass der User-Agent im gleichen oder aber in einem physikalisch separaten System implementiert ist.

Im Falle der Trennung von Dialogfuehrung, Nachrichtenspeicherung sowie -uebermittlung vollzieht sich die Kommunikation ueber standardisierte Protokolle.

Diese Unterscheidung zwischen Dialog und Anwendungsprozess ist zugleich die Grundlage fuer hohe Variabilitaet und Austauschbarkeit von Mailing-Komponenten. Dabei koennen durch die Gewaehrleistung standardisierter Kommunikationsprotokolle unterschiedliche Mail- Pakete das gleiche Nachrichtenuebermittlungssystem nutzen. Den Dialog zum Erzeugen und Versenden solcher Briefe uebernimmt der User-Agent. Die X.400-Komponente, die die Briefe sortiert und zum elektronischen Briefkasten des Empfaengers weiterleitet, ist hingegen der sogenannte Message Transfer Agent (MTA), dessen Aufgabe in der Nachrichtenuebermittlung liegt, die wiederum nicht Bestandteil der Dialogfuehrung ist.

Innerhalb einer Client-Server-Architektur ist eine Fuelle individueller Konfigurationen auf X.400-Basis moeglich. Dies gilt vor allem fuer Funktionen in verschiedenen, beispielsweise ueber ein Corporate Network verbundenen Unternehmen, wo zudem auch diverse Serviceleistungen durch Betreibergesellschaften vorstellbar sind, die sonst jedes Unternehmen selbst erbringen muesste. Gerade bei der grossen Anzahl privater Message-Handling-Systeme waere es jedoch fuer einzelne Betreiber ein immenser Aufwand, jede nationale und internationale Verkehrsverbindung einzeln in die Wege zu leiten beziehungsweise Absprachen ueber die Aufteilung der Uebertragungskosten zu treffen. Hier liegt auch der Unterschied zwischen den sogenannten privaten und oeffentlichen Versorgungsbereichen.

Letzterer bestimmt die Konventionen der Interaktion zwischen beiden. Darueber hinaus stellt er zur Gewaehrleistung eines reibungslosen Nachrichtentransfers sicher, dass Accounting, Logging, Service und Durchgaengigkeit der Adressierung fehlerlos sind. Zusammenfassend laesst sich festhalten, dass die Benutzer ueber eine bestimmte Klasse von kooperierenden User-Agents auf das Nachrichtenuebermittlungssystem zugreifen, wobei spezielle Schnittstellen den Telex- und Teletex-Anwendern erlauben, mit dem User-Agent zu kommunizieren und umgekehrt.

Begriffe wie "Open Server" oder "Mailbox-Server" stehen dabei fuer einen MTA, dessen Aufgabe vor allem in der Vermittlung unterschiedlicher Mail-Clients liegt. Ueber diesen Switch werden unterschiedliche Inhouse-Electronic-Mail-Applikationen miteinander verbunden, aber auch die Verbindung nach aussen vollzogen. Auf ihm befindet sich eine Reihe von Komponenten, die sich anhand des ISO- 7-Schichtenmodells erlaeutern lassen.

Dabei ist zunaechst die reine Netzebene zu spezifizieren, also im WAN-Bereich in der Regel X.25 oder ISDN; im Inhouse-Bereich gilt es, neben unterschiedlichen LANs auch Grossrechnerformate wie 3270 oder 9750 zu bedienen. Ferner sind (gegebe- nenfalls verschiedene) Netzwerk-Betriebssysteme, die im Inhouse-Bereich existieren, abzufragen. Hier kommt es vor allem darauf an, die physikalische beziehungsweise netznahe Anbindung der Mail-Systeme zu gewaehrleisten. Darauf aufbauend, werden "Native-User-Agents" und/oder eine Reihe von Gateways installiert.

Neben dem Sicherheitsaspekt und einem erweiterten Administrationsaufwand haben Gateways den Nachteil, dass sie proprietaere Produkte lediglich auf dem kleinsten gemeinsamen Nenner verbinden. Darueber hinaus koennen nicht alle "Body Types" ueber die Gateways transportiert werden. So wurden beispielsweise beim 1984er X.400-Standard eine Reihe von Body Types vorgegeben, etwa die Zeichensaetze "IA5" oder "T.61", letzterer besser bekannt unter dem Begriff "Teletex". Bedienen nicht alle vorhandenen Gateways diese "Body Types", kann es zu funktionalen Einschraenkungen kommen.

Eine Alternative zum Gateway ist der "Native-User-Agent", der eine direkte Anbindung an ein X.400-Netz ermoeglicht. Dies vor allem auch deshalb, weil die Hersteller von Mail-Systemen oft die Strategie verfolgen, ihr jeweiliges Produkt mit dem Ziel abzuschotten, geschlossene Benutzergruppen zu bilden, waehrend das System beim Native-User-Agent von sich aus bereits offen ist. Anders formuliert: Es bedarf keinerlei Konvertierung mit den Nachteilen Laufzeitverzoegerung sowie Umsetzungsroutinen.

Neben diesen stark Mail-bezogenen Funktionen koennen MTA-Server den Betrieb eines X.400-Netzes auch noch auf andere Art unterstuetzen. Dazu gehoeren Logging-Aufgaben, Accounting-Funktionen, Routing- Aufgaben (beispielsweise eine Verteilung von Nachrichten je nach Kosten oder Dringlichkeit), Access-Control (Wer darf wem etwas schicken?) sowie eine Directory-Vereinheitlichung bezueglich unterschiedlicher Adressdatenformate.

Dabei ist es nicht zwingend, dass es nur einen MTA-Server pro Unternehmen gibt. Aus Gruenden der Performance kann es durchaus Sinn machen, mehrere Mail-Server zu installieren, die sich zu einem logischen X.400-Backbone-Netz zusammenfassen lassen (siehe Abbildung). Der Netzaufbau ist letztlich immer abhaengig von den Kosten und der Performance. Die entscheidende Funktion des MTA liegt in der Identifikation von Meldungen beziehungsweise der Pruefung, wo eventuell auf welchem anderen MTA der Empfaenger sitzt.

Bei der Implementierung eines Grossrechner-Mail-Systems ist eine Reihe von Faktoren zu beruecksichtigen, die man in der PC-Welt in dieser Komplexitaet bis dato nicht kannte. Zumindest ist es in jedem Fall leichter, PCs an eine Client-Server-Architektur heranzufuehren als an eine "Grossrechner-Mailbox". Probleme existieren darueber hinaus auch mit der Verfuegbarkeit eines entsprechenden Grossrechners, denn in der Regel wird die Nachtzeit fuer Batch-Verarbeitungen genutzt. Konsequenz: Mailings aus Uebersee werden moeglicherweise mit dem Hinweis abgewiesen: Teilnehmer nicht verfuegbar.

Um sich dieser "Client-Server-Problematik" zu stellen, werden haeufig Software-Server auf dem Grossrechner installiert. Damit ist es zugleich moeglich, den X.400-Service nicht nur aus einem E-Mail- System heraus, sondern auch auf Basis anderer Applikationen zu bedienen. Der Software-Server fungiert dann als API-Schnittstelle, ueber die auch andere Applikationen auf X.400 zurueckgreifen koennen.

Bei einer Grossrechner-Mailbox handelt es sich haeufig nicht um eine reine E-Mail-Applika- tion, sondern um eine fuer Grossrechnerverhaeltnisse komfortable Bueroanwendung, in der auch Funktionen wie "Wiedervorlage" oder "Aktenschrankverwaltung" beziehungsweise eine simple Archivierungskomponente enthalten sind. Bei der Auswahl eines User-Agents fuer PC-Mail-Netzwerke ist dies nicht so trivial. Hier ist im Vorfeld zu pruefen, ob man sich ausschliesslich auf die reine User-Agent-Thematik beschraenken will. In diesem Fall reicht die Installation eines MTA-Servers. Die organisatorische Taetigkeit beschraenkt sich dann auf die Veroeffentlichung verbindlicher Regeln fuer die Anbindung von diversen Editoren an das X.400-Netz.

Eine tiefergreifende organisatorische Betrachtung kann sich dann auch mit der Einbindung von Archiv- beziehungsweise Image- Processing-Systemen beschaeftigen. Zumindest sind aber Fragen im Hinblick auf Integration und Organisation der restlichen Telematikdienste zu klaeren. Das System sollte dabei so intelligent beziehungsweise komfortabel sein, dass es in der Lage ist, dem jeweiligen Anwender lediglich ein Directory vorzulegen, aus dem er die benoetigte Adresse entnimmt und durch Aktivieren der Versandfunktion den Kommunikationsvorgang ausloest.

Wichtiger Aspekt bei der Einrichtung einer hausinternen Mailbox ist auch die organisatorische Aufteilung und Anbindung an sogenannte "Private-Management-Domains" (PRMD) und "Administrative-Management-Domains" (ADMD). Die Betreiber von ADMDs sind vor allem oeffentliche Postgesellschaften und Carrier, so etwa der Telebox-Dienst der Deutschen Bundespost Telekom. Daneben gibt es aber auch, bedingt durch die Liberalisierung, eine Reihe von Betreibergesellschaften, die ebenfalls ADMD-Leistungen anbieten und die von den PRMDs ausgehenden Mailings verteilen.

Generell ist es ratsam, die Anzahl von PRMDs in einem Unternehmen moeglichst niedrig zu halten. So laesst sich auch der Administrationsaufwand innerhalb einer PRMD minimieren. Hinsichtlich der Directory-Services sind ferner, solange noch nicht auf X.500-Systeme zurueckgegriffen werden kann, einheitliche Namenskonventionen zu erlassen. Darueber hinaus sollten alle MTAs miteinander vernetzt sein, um noetigenfalls Rechnerausfaelle zu kompensieren.

Solange man unternehmensweit nur ueber eine Mail-Applikation, zum Beispiel auf einem Grossrechner, verfuegt, die ein internes (proprietaeres) Adressierungsschema hat, haelt sich der Administrationsaufwand in Grenzen. In einer X.400-Welt - auch wenn sie sich zunaechst ausschliesslich auf die unternehmensinterne Informationsverarbeitung bezieht - stellt sich das Problem schon wesentlich komplexer dar. So muss etwa bei verteilten Applikationen gewaehrleistet sein, dass die Adressbestaende, die zum Teil aus Performance-Gruenden redundant vorgehalten werden muessen, moeglichst zeitnah dem aktuellen Stand entsprechen. Dies gilt im uebrigen fuer alle User-Agents auf den unterschiedlichen Hardwareplattformen.

Darueber hinaus ist es aber erforderlich, nicht nur die logischen, sondern auch die physikalischen Adressen zu verwalten. Dabei muss das gesamte X.400-Netz staendig aktualisiert werden. Bei Aenderungen ist sofort eine Information an alle angebundenen Rechner zu uebermitteln, die ihrerseits sofort darauf reagieren muessen. Bei eventuellen Stoerungen eines MTAs sollte daher die Moeglichkeit bestehen, entweder automatisiert oder aber zumindest durch einen manuellen Online-Eingriff entsprechende Routing-Massnahmen einzuleiten.

Modularer Aufbau beguenstigt Outsourcing

Der modulare Aufbau des X.400-Modells beziehungsweise seine Client-Server-orientierte Basis eroeffnet also dem Anwender eine Reihe von Moeglichkeiten, Funktionen an einen Carrier auszulagern. Dies ist nicht nur unter wirtschaftlichen Gesichtspunkten interessant, sondern kann letztlich auch die Performance erheblich verbessern. Allerdings wird es auch Unternehmen geben, die als Inhouse-Anwendung bereits (unterschiedliche) E-Mail-Systeme installiert haben. Hier duerfte kaum eine Bereitschaft vorhanden sein, einen solchen Schritt in Richtung Outsourcing zu vollziehen. Fuer diese Anwendergruppe bietet sich durch die Trennung von User- Agent und Nachrichtenuebermittlung ein idealer Service an.

Generell ist davon auszugehen, dass mittelfristig alle massgeblichen E-Mail-Pakete mit einer X.400-Schnittstelle oder zumindest einem Gateway ausgestattet werden. Damit besteht eine erste Entkoppelungsmoeglichkeit zwischen User-Agent und Nachrichtenuebermittlungseinheit. Dies bedeutet, dass innerhalb eines Unternehmens E-Mail-Anwender nicht auf ihre gewohnte Oberflaeche verzichten muessen, die Uebertragung aber dem jeweiligen Betreiber ueberlassen - konkret: Die Nachrichtenuebermittlung wird durch den beauftragten Carrier wahrgenommen.

Der Anwender muss also nicht die gesamte X.400-Funktionalitaet in seiner Domaene installieren, sondern ausschliesslich den User-Agent, ueber den er auf die Uebermittlungseinheit (Server) beim Carrier zugreift. Dadurch erlangt er ein Maximum an Flexibilitaet. Umgekehrt kann ein Carrier durch die Bereitstellung eines oder mehrerer Nachrichtenspeicher Zwischen-Speicherdienstleistungen anbieten, ohne dass der Anwender entsprechende Ressourcen vorhalten muss.

Mit dem Einsatz solcher Systeme duerfte aus organisatorisch- betriebswirtschaftlichen Gruenden der Versand von Telex, Teletex und Fax aus der Mailbox kein Thema mehr sein. Schrittweise koennten also alle Telex-Nebenstellen und Faxprozessoren abgeloest werden. Mit der Einrichtung von X.400-Zugriffs- beziehungsweise Uebergabepunkten laesst sich zudem eine Schnittstelle zu anderen Telematikdiensten schaffen, die der Carrier im Rahmen eines zentralen Kommunikationsservice anbieten kann. Darueber hinaus ist es moeglich, durch Installation und Nutzung einer Nachrichtenuebermittlungseinheit beim Carrier die Anbindung an die oeffentlichen Versorgungsbereiche viel wirtschaftlicher durchzufuehren, als wenn jedes einzelne Unternehmen eigene Verbindungsbruecken schafft.

Die Dimension eines solchen Vorhabens verdeutlicht ein vergleichbares Projekt beim Gerling-Konzern. Dabei muss man allerdings vorausschicken, dass die dortige Grossrechner-Mailbox hinsichtlich des Transaktionsaufkommens die groesste Applikation im Hause ist. Bis zu 1,9 Millionen Transaktionen pro Monat sowie rund 7000 Teilnehmer mit weit ueber 200000 Mailings im Bestand verdeutlichen das Volumen, auf das die Mail-Organisation Ruecksicht nehmen musste.

Allein zu Beginn galt es, mindestens 500 Teilnehmer mit der X.400- Funktion auszuruesten.

Die so formulierte Einfuehrungsstrategie konzentrierte sich in der ersten Stufe zuerst auf die Anbindung des Host-Mail-Systems an den MTA-Server. Dabei kam es darauf an, nicht nur Mailings zu versenden, sondern darueber hinaus auch Nachrichten aus anderen Online-Applikationen im Hause zu uebertragen, die ohne manuellen Eingriff verteilt werden muessen. In der zweiten Stufe ging es um die Inhouse-X.400-Vernetzung, also die Verbindung von PC-Netzen mit dem MTA-Server und damit der Host-Mail. Hier war eine Vielzahl an Welten zu beruecksichtigen, mit dem vordringlichsten Ziel, die PC-Netze zu integrieren. Daher wurden unterschiedliche Buerooberflaechen getestet und auf ihre Funktionalitaet hin bewertet - ein Unterfangen, bei dem die umfangreiche Erfahrung im Betrieb einer Grossrechner-Mailbox eine wertvolle Hilfe war.

Vor allem die Beruecksichtigung der Administrationsfunktion entschied ueber den Overhead, den es bereits zu Beginn zu beschraenken galt. Erst danach folgte die Einbindung der Entwicklungsumgebung in den X.400-Verbund inklusive einer Reihe Unix-basierter Abteilungsrechner. In allen Faellen mussten unterschiedliche Editoren aufeinander abgestimmt werden. Im letzten Schritt war - zumindest was die Versorgung der Konzernzentrale angeht - Ruecksicht auf die Vielfalt der Editoren zu nehmen, in die der Telematikservice bei einem angestrebten Optimum an Funktionalitaet komfortabel eingebunden wurde.

Weitere Planungen bezogen die Anbindung der Gerling- Niederlassungen im Bundesgebiet mit ein. Zunaechst galt es dort, die PC-Netze ueber Standleitungen beziehungsweise X.25- Datenverbindungen mit der Zentrale in Koeln und dem dort installierten MTA-Server zu verbinden. Dies kann aber nur ein erster Schritt sein, denn bei entsprechend zunehmendem Nachrichtenaufkommen rechnet es sich aller Voraussicht nach, auch in den jeweiligen Niederlassungen eigene MTA-Server zu installieren, wobei sich diese quasi autark als eigene Cluster darstellen.

Es war und ist naheliegend, dass die Administration zumindest in Teilbereichen durch die zentrale X.400-Administration abgewickelt wird. Zugleich sollen die MTAs auch die Integration vollenden; jedenfalls ist es das Ziel, durch die mit steigendem Aufkommen ebenfalls notwendige Integration dezentraler, auf den Niederlassungen installierter Telematik-Server, ein X.400- Refiling-Netz aufzubauen. Dies haette den wirtschaftlichen Vorteil, dass Faxe und Mailings innerhalb des Gerling-Netzes so weit geroutet werden koennten, bis sie an dem zum Empfaenger naechstgelegenen Ort ankommen und dort erst in das oeffentliche Netz eingegeben werden (Stichwort: Least-Cost Routing).

Bei einem derartigen Telematik- beziehungsweise X.400-Netz besteht darueber hinaus die Moeglichkeit, im Prinzip auch fuer Dritte einen "Value Added Service" anzubieten. Daneben gibt es wesentliche qualitative Verbesserungen hinsichtich der Flexibilitaet und einer Verkuerzung der Reaktionszeit.

Im einzelnen stellen sich die Vorteile von X.400 folgendermassen dar:

- Versand und Empfang aus der gewohnten Oberflaeche,

- kein Schlangestehen am Faxgeraet,

- keine Blockade des Faxgeraets durch Massensendungen,

- Moeglichkeit zur Erstellung von "Mixed-Documents"-Mails, Fax, Telex entsprechend der jeweiligen Hardware des Empfaengers,

- Versand und Empfang multimedialer Dokumente (Verbunddokumente),

- X.400-Nachrichten sind mit jeder Systemsicherung gesichert und loeschen sich nicht.

Interessant sind auch die Gebuehreneinsparungen. Abbildung 2 fasst die Gebuehren bei den unterschiedlichen Diensten zusammen. Ausser beim gewoehnlichen Postbrief sind jeweils die Kosten fuer eine DIN- A4-Seite, 2000 Zeichen, ausschliesslich alphanumerisch, angegeben. Dieser Wert fuer X.400-P gilt bei einer PRMD-PRMD-Kopplung. X.400-A steht fuer die Kopplung mit der restlichen X.400-Welt ueber Carrier (hier kann es auch zu Gebuehrenunterschieden zwischen verschiedenen ADMD-Anbietern kommen). Im Fall der Nutzung ueber den Telebox-400- Service der Telekom belaeuft sich der Preis auf 0,50 Mark. Im internationalen Bereich sieht der Gebuehrenvergleich entsprechend Abbildung 3 aus.

Die internationalen Standards fuer den Auskunftsdienst X.500 ermoeglichen das Auffinden von anderen Teilnehmern, Datenquellen, Informationen und Anwendungen allein ueber Namen oder Begriffe - ohne Kenntnis komplexer Netzwerkadressen. Dabei zeichnen sich bereits heute umfangreiche Aktivitaeten zum Aufbau eines Directory- Services ab, der in spaeteren Stufen auch dezentralisiert angeboten werden muss und das Angebot von ADMDs einbeziehen wird.

X.400 bleibt da natuerlich nicht bei der Versendung von Textnachrichten stehen, wobei zunaechst die Nachfrage nach dem Versand von EDI-Nachrichten zunehmen wird. Im naechsten Schritt wird es dann aller Voraussicht zur Einbeziehung von ODA- Nachrichten kommen.

Bei der Integration von PC-Netzen ergeben sich staendig neue Moeglichkeiten, vor allem aus dem multimedialen Applikationsbereich, die den Versand von Verbunddokumenten erzwingen. Technisch existieren dabei schon heute keine Restriktionen. Gerade hier zeigt sich die Notwendigkeit, Voice- Mail-Systeme, die als integrierte oder externe Server an PABX- Systemen angebunden sind, zielgerichtet auf die Norm X.400 zu entwickeln. Im Grunde werden also Voice-Server in einen X.400- Verbund zu integrieren sein. Aber auch die Welt der Bild- und Bewegtbildverarbeitung fordert entsprechende Uebertragungsinstrumente. Hier bietet sich X.400 auch in der Zukunft als interessanter Dienst an.