Die Betrachtung von OSI-Standards fand bisher hauptsächlich auf rein technischer Ebene statt. Die Diskussion drehte sich dabei meist um die standardisierten Protokolle sowie Interoperabilitätstests. Als Begründung für den Einsatz von OSI in heterogenen Umgebungen mußte immer wieder der Vergleich der Komplexität von bilateralen, herstellerspezifischen Gateways mit der Nutzung des standardisierten Verfahrens herhalten. Seit kurzem bemühen sich die OSI-Auguren nun, den Aspekt der Unterstützung alltäglicher Arbeitsabläufe in Unternehmen durch OSI-basierte Verfahren stärker in der Vordergrund zu stellen. Rainer Janssen* versucht dies in Teil 2 am Beispiel X.400 und FTAM.

Unter der Bezeichnung X.400 wurde bei CCITT ein Konzept zum Transport von Nachrichten im sogenannten Store-and-forward-Modus standardisiert. Es orientiert sich an der Arbeitsweise bei der Übertragung und Auslieferung von Briefpost, und viele Begriffe der X.400-Terminologie sind leichter verständlich, wenn man diese Analogie beachtet.

Die Architektur von Message-Handling-Systemen nach X.400 basiert auf einer Trennung der transportorientierten und der anwendungsorientierten Funktionen. Die transportorientierten Funktionen werden durch die Message Transfer Agents (MTA) realisiert, die Gemeinschaft aller MTAs bildet das Message-Transfer-System (MTS). Dahinter steckt die Philosophie, im Message Transfer System nur die allen Anwendungen gemeinsamen Funktionen zu realisieren, so daß es als universelle Plattform für unterschiedliche Arten von Anwendungen nutzbar ist.

X.400 orientiert sich an der gelben Briefpost

Die anwendungsorientierten Funktionen werden durch die User Agents (UA) unterstützt. Die Unterschiede zwischen verschiedenen Klassen von Anwendungen spiegeln sich dann in unterschiedlichen User Agents mit ihren zugehörigen Protokollen wider. Die Übertragung wird bei Message-Handling-Systemen vom Absender initiiert, das Verfahren basiert somit auf dem Konzept der Bringschuld.

Um die Nutzbarkeit von X.400 für EDI zu untersuchen, muß man heute drei Fälle unterscheiden.

X.400 (84): Die erste Version der X.400-Empfehlungen wurde

1984 beim CCITT verabschiedet. 1984 wurde nur ein erster Typ von User Agent standardisiert, der User Agent für den Nachrichtenaustausch zwischen Personen (IPM = Interpersonal Messaging), das entsprechende Protokoll wird als P2-Protokoll bezeichnet.

Da es bisher nur diesen ersten Typus des User Agent gibt, ist das Mißverständnis, X.400 sei nur für den Nachrichtenaustausch zwischen Personen gedacht, erklärbar. X.400 ist aber weitaus mehr, nämlich ein sehr mächtiges Konzept zur Bereitstellung einer Store-and-forward-Plattform für eine Fülle von Anwendungen. Übergänge zu anderen Diensten (Teletex, Telex, Telefax in Zukunft etc.) sind im Standard ebenfalls vorgesehen .

X.400 (88) beinhaltet X.500-Directory-Dienst

Da X.400 (84) nur den User Agent für IPM bietet und somit keine speziellen Funktionen zur Unterstützung von EDI-Anwendungen bereitstellt, ist die Nutzung für EDI zwar möglich, aber nur als Übergangslösung zu betrachten.

X.400 (88): In der Version X.400 (88), die 1988 bei CCITT verabschiedet wurde, sind einige wichtige funktionale Erweiterungen enthalten:

Zum Beispiel das Message-Store-Konzept. Diese Einheit (Message Store) bildet einen Puffer für den empfangenden User Agent, so daß auch solche User Agents, die nicht immer empfangsbereit sind (zum Beispiel PCs) in das Message-Handling-System integriert werden können. Message Store erlaubt darüber hinaus ein selektives Auslesen von Nachrichten durch den Empfänger (zum Beilspiel alle Nachrichten eines bestimmten Absenders).

In X.400 (88) sind außerdem eine Reihe von Security-Services spezifiziert, die auf kryptographischen Techniken basieren und somit die Sicherheit des Verbundes erhöhen. Zur Realisierung werden folgende Dienste genutzt:

- Zugriffskontrolle,

- Authentifizierung, Sende- und Empfangsbestätigung,

- Vertraulichkeit der Daten,

- Integrität der Daten,

- Verhinderung der Verleugnung des Absendens oder Empfangs von Nachrichten. Diese Dienste sind im Basisstandard X.400(88) als optional klassifiziert.

Ferner beinhaltet X.400 (88) die Nutzung eines Directory-Dienstes auf Basis X.500 durch Message-Handling-Systeme zur benutzerfreundlichen Adressierung (Umsetzung von Namen in Adressen sowie von EDI- in OSI- Adressen), die Verwaltung von Verteilerlisten und Authentifizierung.

Schließlich wurden noch neue Access Units zur Realisierung von Dienstübergängen aufgenommen:

- Physical Delivery Access Unit zur Kommunikation mit Teilnehmern, die nur über die Briefpost erreichbar sind, und

- Telematic Delivery Access Unit zur Kommunikation mit Partnern, die über Telematik-Dienste erreicht werden können.

Erste Produkte der Version X.400 (88) werden 1991/1992 auf dem Markt erwartet.

EDI und X.400 (Pedi): Wie oben dargestellt, bietet die 88er Version von X.400 eine verbesserte Funktionalität auch für EDI-Anwendungen. Sie enthält aber wie die Version von 1984 nur den User Agent für das Interpersonal Messaging.

1988 wurde bei CCITT eine Interim Rapporteur Group gebildet, um den Entwurf eines Standards zur besseren Unterstützung von EDI durch X.400 zu erarbeiten.

An der Arbeit dieser Gruppe beteiligten sich Postgesellschaften, Computerhersteller, Dienstanbieter, EDI-Standardorganisationen und Anwender (vorwiegend aus den Edifice und Cefic-Projekten).

Die Gruppe verfolgte den Ansatz, den EDI über X.400-Service analog zum IPM-Service als einen User Agent zu modellieren, der die Dienste des untergelagerten Message-Transfer-Systems der 88er Version von X.400 zur Übertragung nutzt. Das zugehörige Protokoll heißt Pedi und wurde im November 1990 unter der Bezeichnung X.435 bei CCITT verabschiedet.

Pedi-Protokoll liefert MHS-Basis für Edifact

Pedi erlaubt die Übertragung von EDI-Nachrichten in Edifact, X.12, UN/TDI oder anderen Formaten und sieht eine Reihe von Funktionen vor, die eine effiziente Unterstützung von EDI durch X.400 bieten, zum Beispiel:

- Message Store als Zwischenspeicher,

- Directory (Nutzung des Directory-Dienstes zur Umsetzung von EDI-Namen in X.400-Adressen oder um Informationen über Eigenschaften beziehungsweise Möglichkeiten des Partners zu erhalten),

- Security.

Ein wichtiger Gesichtspunkt bei der Nutzung von X.400 ist die Tatsache, daß die Postgesellschaften und Dienstanbieter eine weltweite Plattform zur Vermittelung von Nachrichten mittels X.400 anbieten werden (ADMD-Plattform, Administration Management Domain, öffentlicher Versorgungsbereich). Dadurch entfällt die Notwendigkeit bilateraler Verbindungen und der Zwang zu bilateralen Absprachen auf der technischen Ebene.

Ein Unternehmen als Betreiber eines privaten Versorgungsbereiches kann sich bei einer oder mehreren ADMDs registrieren lassen und somit unter Nutzung der ADMD-Plattform Nachrichten versenden und empfangen (siehe Abbildung auf Seite 18).

In den F.400-Empfehlungen von CCITT, die die Dienste der ADMDs beschreiben, ist festgelegt, daß eilige Nachrichten nach spätestens 45 Minuten, normale Nachrichten nach spätestens vier Stunden den ADMD-Verbund durchlaufen haben müssen (Bemerkung: Diese Grenzwerte beziehen sich auf 95 Prozent der zu übertragenen Nachrichten, es gibt daher keine Garantie, daß sie bei jeder Nachricht eingehalten werden, siehe F.410).

Bei einem Mißerfolg (Übertragung nicht möglich) wird daher bei eiligen Nachrichten erst nach spätestens vier Stunden (bei normalen Nachrichten nach 24 Stunden) eine Non Delivery Notification zur Information des Absenders über den Mißerfolg erzeugt.

In den F.435-Empfehlungen (EDI/X.400) wird eine schärfere Grenze spezifiziert: 95 Prozent der eiligen Nachrichten müssen den ADMD-Verbund in maximal 15 Minuten durchlaufen haben.

Direkte X.400-Verbindung umgeht ADMD-Plattform

Ist dies nicht ausreichend, so können Unternehmen in Absprache mit dem Partner entweder eine direkte X.400-Verbindung etablieren, das heißt die ADMD-Plattform umgehen, oder eine andere Kommunikationstechnik wählen. Die Partner sind in diesem Fall selbst dafür verantwortlich, ihre Systeme so einzurichten und zu betreiben, daß eine Auslieferung von Nachrichten in wenigen Minuten garantiert werden kann, und müssen einen höheren Aufwand zur Pflege dieser bilateralen Verbindungen einkalkulieren.

Bemerkung:

1. Der Fall der direkten Kommunikation zwischen zwei PRMDs über Landesgrenzen hinweg, ohne die Vermittlungsdienste von ADMDs in Anspruch zu nehmen, ist in den Normdokumenten nicht enthalten.

2. Die Darstellungen in den Normdokumenten legen die Interpretation nahe, daß eine PRMD, die sich über Landesgrenzen hinweg erstreckt, nicht zulässig ist, sondern es sich in einem solchen Fall um zwei getrennte PRMDs handelt. Diese Betrachtungsweise drückt sich auch in der Namenstruktur von X.400 aus, denn eine PRMD ist im Namensbaum immer unterhalb des Landes und der ADMD angesiedelt. Diese Struktur kann aber Probleme für ein multinationales Unternehmen bei der Nutzung von X.400 aufwerfen.

Wenn eine solche Organisation ein Message-Handling-System betreibt, welches sich über verschiedene Länder erstreckt, möchte sie auch als eine PRMD mit demselben Namen in allen Ländern behandelt werden. Es ergeben sich ebenfalls Anforderungen der multinationalen Organisation an Routing-Möglichkeiten zur Ausnutzung interner Netzressourcen (internationale Mietleitungen), die hier nicht im Detail dargestellt werden können und die die bestehende Struktur nicht erfüllen kann. Einige multinationale Organisationen haben daher bereits ihre Forderung nach entsprechender Anpassung der X.400-Struktur geäußert. Zur Zeit werden mögliche Lösungen in verschiedenen Gremien diskutiert.

Die Vorteile von X.400 sind, daß die Übertragung im Store-and-forward-Modus erfolgt, das heißt, es ist keine direkte Verbindung der Partner notwendig daß der X.400-Umschlag die Nutzung von Attributen zur Steuerung der Kommunikation, wie zum Beispiel Zeitstempel der Auslieferung, erlaubt sowie ein Versenden an mehrere Empfänger gleichzeitig möglich ist.

Als Nachteil ist zu werten, daß es Beschränkungen bezüglich der Länge der Nachrichten (heute: Nachricht <= 2 MB) gibt, daß heute nur Übergangslösungen möglich sind, die Umsetzung von EDI-Adressen in X.400 O/R-Namen notwendig (O/R = Originator/Recipient) ist und daß aus den unterschiedlichen Kodierungsverfahren (X.400 basiert auf ASN.1, Edifact benutzt IA5) eine Duplizierung gewisser Informationen folgt.

Die beiden letztgenannten Nachteile gelten allerdings nicht nur für EDI und X.400, sondern sind für alle OSI-Anwendungsstandards im Zusammenhang mit EDI relevant. ODA/Odif-Dokumente wurden bereits im Rahmen der Esprit-Projekte und auf zahlreichen Demonstrationen mittels X.400 übertragen. Aus X.400-Sicht handelt es sich dabei um eine transparente Übertragung von Inhalten, die außerhalb des MHS definiert sind. Bezüglich der Übertragung selbst gelten die gleichen Gesichtspunkte wie bei Edifact.

FTAM wurde 1988 bei ISO verabschiedet (IS 8571, Parts 1-4

Feb. 88, Part 5 March 89) und bietet eine weites Spektrum von

Anwendungsmöglichkeiten:

- Übertragung kompletter Dateien

- Remote-Zugriff auf Teile von Dateien und

- Manipulation von Dateien.

Ein wesentlicher Grundgedanke von FTAM ist das Konzept des Virtual Filestore. Dieses Konzept ermöglicht eine einheitliche Sichtweise unterschiedlicher Dateisysteme. Aufgabe der FTAM-Applikation ist es, diese virtuelle Beschreibung von Dateien auf das reale Dateisystem des jeweiligen Systems abzubilden .

FTAM-Produkte werden inzwischen von fast allen Herstellern angeboten, sie liefern (analog zu X.400) aber noch nicht den vollen Funktionsumfang des FTAM Standards, sondern sind Implementierungen von Teilmengen (sogenannte funktionaler Profile).

FTAM basiert im Gegensatz zu X.400 nicht auf einem Store-and-forward-Mechanismus, sondern auf einer Punkt-zu-Punkt-Verbindung über einem geeigneten Datennetz (zum Beispiel X.25, LAN). EDI-Daten werden heute als unstrukturierte Binärdateien übertragen. Beispiel einer solchen Anwendung ist das Projekt "Elektronische Abrechnung mit File-Transfer" (EAF) der Banken. Im Vergleich zu X.400 bietet FTAM folgende Vorteile:

- keine Beschränkung in der Dateigröße,

- Übertragung in Echtzeit,

- Bring- oder Holschuld ist implementierbar; X.400 basiert auf dem Konzept der Bringschuld, dadurch ist mehr Flexibilität in der Steuerung der Abläufe realisierbar. Zum Beispiel können Daten in einer Datei auf dem entfernten System durch den Initiator gesammelt werden, der Empfänger greift dann auf die lokale Datei auf seinem System zu).

Nachteile von FTAM sind:

- Punkt-zu-Punkt-Verbindung,

- kein Zeitstempel der Auslieferung (muß also bei Bedarf durch die FTAM-Anwendung realisiert werden).

Value Added Network Services (VANS) bieten als Basisdienst die Bereitstellung einer Mailbox und die Konvertierung des Kommunikationsprotokolls an. Sie realisieren die Entkoppelung von Sender und Empfänger und eignen sich somit für die asynchrone EDI-Kommunikation (Batch). VANS konnten bisher die Kommunikationsprobleme ihrer Kunden nur lösen, solange der Partner auch Kunde des gleichen VANS ist (zum Beispiel Geisco mit EDI-Express).

Auch zur Zeit findet die EDI-Kommunikation noch im wesentlichen auf dem Weg der Nutzung von VANS statt. Bisher sind nur wenige Verbindungen zwischen den VANS realisiert. Die Ursache hierfür sind weniger die technischen Probleme, sondern Tarifierungsfragen, rechtliche Probleme und die Tatsache, daß viele EDI-Projekte räumlich begrenzt sind. Zur Zeit werden aber mehr solcher Verbindungen vorwiegend auf Basis von X.400 realisiert.

Die Nutzung von Standards reduziert auf der einen Seite die Nachfrage nach VANS, da die Kommunikationsprobleme leichter zu lösen sind. Auf der anderen Seite profitieren auch die VANS vom steigenden Gesamtvolumen, welches durch die Standardisierung gefördert wird, und können selbst die Vorteile der Standardisierung

bei der Lösung technischer Probleme nutzen (X.400 zur Verbindung zwischen ihnen).

Gelegentlich wird argumentiert, daß zum Beispiel beim Einsatz von OSI-Standards die Dienste eines VANS nicht mehr benötigt werden. Man darf aber auf keinen Fall übersehen, daß VANS Services anbieten, die zum Teil oberhalb der Schicht 7 des OSI-Referenzmodells liegen. Der Einsatz von OSI-Produkten macht diese Dienste also nicht obsolet, da die OSI-Protokolle nur das Problem der Interoperabilität lösen. Ein Anwender hat bei Nutzung von OSI-Protokollen aber eine höhere Flexibilität, denn er kann dann entscheiden, ob er die zusätzlichen Funktionen weiterhin an den VANS delegieren oder im eigenen Hause implementieren möchte.

OSI ist ein sehr wichtiger Schritt zur Lösung von Kommunikationsproblemen, behandelt aber lediglich die Interoperabilität zwischen verschiedenen Systemen. OSI standardisiert die Dienstleistungen, die eine Ebene erbringen muß, und das Protokoll, das benötigt wird, um diese Leistung erbringen zu können. OSI standardisiert jedoch nicht die Art und Weise, wie eine Ebene einer höheren Ebene den Dienst anbietet.

Ein Softwarehaus, das zum Beispiel ein EDI-Paket bereitstellt, muß sich mit den X.400-Lösungen verschiedener Hersteller auseinandersetzen, wenn das Paket auf verschiedenen Systemen lauffähig sein und X.400 unterstützen soll. Es fehlen also standardisierte Schnittstellen, sogenannte APIs (Application Programming Interface).

Dieser Mangel wurde erkannt und führte zur Gründung der X.400 API Association (APIA). Diese Gruppe hat im Juni 1989 ihre erste Spezifikation verabschiedet, das sogenannte "X.400 Gateway API". Das Interface erleichtert die Nutzung eines X.400-Gateway-Dienstes durch die Beschreibung einer Schnittstelle. Als zweite Veröffentlichung ist das API zwischen einem X.400-System und einer Applikation (zum Beispiel EDI, Spreadsheet) angekündigt worden.

Das X.400 Gateway API wurde inzwischen als X/Open-Spezifikation veröffentlicht. Eine andere Spezifikation von X.400 APIA und X/Open behandelt die Nutzung von Directory-Diensten.

Für FTAM wurde durch die MAP-Gruppe (Manufacturing Automation Protocol) in den USA vor einigen Jahren das sogenannte FTAM-API veröffentlicht. Ein X/Open API analog zum X.400 API ist noch nicht verfügbar.

In den letzten Jahren wurde eine Reihe von Pilotprojekten initiiert, über die zum Teil bereits ausführlich berichtet wurde (zum Beispiel Aufbau von X.400 bei Hoechst und BASF). Die Erfahrungen aus diesen Projekten waren zumeist positiv, Probleme mit der Nutzung einer relativ jungen Technologie sind natürlich nicht zu vermeiden.

Durch die Nutzung des Edifact-Formates und die elektronische Übertragung wird zwar die Fernmelderechnung nicht geringer, es können aber erhebliche Einsparungen bei der Bearbeitung durch den Empfänger erzielt werden.

Zusammenfassung: Der Einsatz internationaler Standards für die Unterstützung der Geschäftskommunikation bringt zumindest mittel- und langfristig für den Anwender folgende Vorteile:

- Die Auswahl von Produkten kann sich nunmehr stärker nach der Eignung für die Applikation und nicht mehr in erster Linie nach der existierenden Hardware-Umgebung oder dem Produkt des Partners richten, die Flexibilität des Anwenders wächst.

- Es gibt keine isolierten Herstellerumgebungen mehr.

- Die Notwendigkeit zum Betrieb komplexer Gateways zur Verbindung unterschiedlicher Systeme entfällt schrittweise.

- Die Abhängigkeit von VANS zur Verbindung von Systemen zwecks Protokollanpassung entfällt.