Die vom amerikanischen Verteidigungsministertum initiierten TCP/ IP-Protokolle sind De-facto- oder anders gesagt Quasi-Standards. Der dritte und letzte Teil dieser Artikelfolge von Karl Reinhard* schildert die Migrationsmöglichkeiten zu OSI-Standards in der Anwendungsebene und - vor allem - in der Transportebene. Zwar ist TCP/IP ein herstellerunabhängiger Standard, aber eben doch noch kein ISO-Standard.
Der gegenwärtige TCP/IP-Boom gründet sich jedoch nicht nur auf die Vielzahl der Anbieter dieser Protokoll-Familie, sondern vor allen Dingen auf die Vielzahl der Kommunikationsanwendungen, die diesen Datentransport nutzen. Und es kommen immer weitere hinzu.
Allerdings muß hier ein Punkt festgehalten werden: TCP/IP ist nicht Bestandteil der internationalen Standards von ISO (International Standardisation Organisation). Dieses maßgebliche Gremium für die Standardisierung von Kommunikationsprotokollen und -diensten auf internationaler Ebene ist den meisten durch das ISO-7-Schichtenmodell für die Kommunikation bekannt. Dieses Gremium verabschiedete und verabschiedet Normen zur Rechnerkommunikation, die zum Teil umfassender und klarer strukturiert sind als diejenigen der TCP/IP-Protokoll-Familie. Alle Anbieter, Hersteller und Anwender sind sich einig, daß die Kommunikation in Zukunft nur noch auf ISO-Normen basieren wird.
Trotz des Aufkommens der ISO-Protokolle beziehungsweise der allgemeinen Übereinstimmung, diese in der Zukunft zu unterstützen, ist offene Kommunikation immer noch sehr stark geprägt durch TCP/IP. Die Gründe hierfür liegen in der historisch bedingten weiten Verbreitung von TCP/IP-Netzen, der großen Implementierungsbreite (TCP/IP-Anschlßsse stehen für fast alle EDV-Systeme zur Verfügung) sowie der großen Attraktivität für den Anwender durch die Vielzahl der verfügbaren Anwendungen.
Das Problem des Anwenders besteht einerseits darin, seine heutige Wettbewerbsfähigkeit durch den Einsatz offener Kommunikation mit möglichst großer Funktionalität zu sichern, und andererseits sich für die Zukunft zu wappnen, indem er den Einsatz von ISO-Normen vorausplant. Das bedeutet für ihn, unter Wahrung maximaler Funktionalität, einen kostengünstigen Übergang zu finden, mit anderen Worten: die Migration von TCP/IP nach ISO effizient zu gestalten.
Diesem Thema sich zu verschließen, bedeutet eine der wichtigsten Entwicklungen in der offenen Kommunikation zu verschlafen. Das heißt Flexibilität und damit ein Stück Wettbewerbsfähigkeit einzubüßen.
Somit stellt sich die Frage nach der Migration zu der künftigen ISO-Welt.
Thema Migration hat zwei Bereiche
Wie die ISO-Lösungen der Zukunft, so muß sich auch die Migration zu denselben an dem ISO-7-Schichten-Modell orientieren. Die Transportorientierung der unteren vier Schichten und die Orientierung der oberen drei Schichten in Richtung der Kommunikationsanwendung legen es nahe, das Thema der Migration in diese zwei Bereiche aufzuteilen.
Zunächst betrachten wir die Migration der Kommunikationsanwendungen (Schicht 5 bis 7). Der Begriff Kommunikationsanwendung wurde hier gewählt, um diese klar von den darauf aufsetzenden Anwendungen zu unterscheiden, die entweder diese Kommunikationsanwendungen intern nutzen, wie ein Büropaket, oder reine lokale Anwendungen wie Textverarbeitung und Tabellenkalkulation sind.
Eines steht wohl ohne Zweifel fest: Es gibt keinen Anwender, der von einem Tag auf den anderen alle bisherigen Kommunikationsanwendungen in seinem Rechnernetz entfernt und diese durch solche mit ISO-Protokollen ersetzt.
Vielmehr wird der Anwender danach trachten, diejenigen Anwendungen, für die es schon ISO-Produkte gibt, zu ersetzen und die anderen Anwendungen vorläufig beizubehalten. Ein gleichzeitiger Einsatz zweier Kommunikationsanwendungen nach unterschiedlichen Protokollen führt zu zwei getrennten Welten innerhalb des Rechners: Nutzt zum Beispiel eine Sekretärin eine Benutzeroberfläche mit der Kommunikationsanwendung "electronic mail" nach X.400, so hat sie nur Zugriff auf ihren "X.400-Briefkasten" und erhält keinerlei Information über den Briefkasten der anderen Kommunikationsanwendung, zum Beispiel SMTP. Letzteren erreicht sie nur über ein umständliches Wechseln der Benutzeroberfläche, was sicherlich mit einer anderen Bedienweise einhergeht und sie zusätzlich vom X.400-Briefkasten abschneidet. Das bedeutet, der Benutzer wird also nicht zwei verschiedene Kommunikationsanwendungen gleichen Typus nebeneinander einsetzen, sondern eine gegen die andere austauschen.
Nur für Funktionen in beiden Welten
Eine Zwisichenstufe können Gateways zwischen den bisherigen Anwendungen und den ISO-Produkten sein. Dadurch entsteht eine Landschaft mit Bereichen, in denen die bisherigen Kommunikationsanwendungen weiterhin eingesetzt werden, und anderen Bereichen, deren Kommunikationsanwendungen bereits migriert wurden. Dadurch wird an der Schnittstelle Rechnerleistung benötigt, die nur dazu dient, ein Format in ein anderes umzusetzen. Zusätzlich können hier nur Informationen beziehungsweise Funktionen umgesetzt werden, die in beiden Welten existieren und somit aufeinander abgebildet werden können. (Zum Beispiel läßt X.400 es zu, beliebige Dateien an die Nachricht anzuhängen, was bei SMTP standardmäßig nicht refllisiert ist.) Das heißt, mit dem Bedarf an weiterer Rechnerleistung geht eine Einschränkung der Funktionalität einher.
Welche Vorgehensweise der Anwender auch immer wählen wird, ob mit Gateway-Zwischenschritt oder ohne, er wird sicherlich jede Kommunikationsanwendung für sich ersetzen, wenn diese bei ISO normiert und am Markt verfügbar ist. Migration ist somit nicht ein einmaliger Vorgang, sondern ein Prozeß, der sich über eine längere Zeit hinzieht.
Trotz Migration keine Protokollfestlegung
Getreu dem alten chinesischen Sprichwort, "Auch die längste Reise beginnt mit dem ersten Schritt", müssen alle Unternehmen zur Wahrung ihrer Wettbewerbsfähigkeit den Migrationsweg baldmöglichst einschlagen. Die MultiNet-Veranstaltung soll dabei der Wegbegleiter sein, der stets die aktuelle Situation widerspiegelt, also den Überblick über verfügbare offene Kommunikationsprodukte gibt.
Zu beachten ist, daß durch die Migration der Kommunikationsanwendungen keinerlei Festlegung auf einzusetzende Transportprotokolle getroffen ist. So klar die Migration auf Anwendungsebene ist, so vielfältig kann dies für die Transportebene sein.
Drei Möglichkeiten seien hier vorgestellt:
- Der Anwender installiert auf seinem System zwei Anschlüsse (zweimal Hardware und Transportsoftware) und betreibt die verschiedenen Kommunikationen nebeneinander. Der Nachteil ist der hohe Investitionszusatzbedarf, der nach Abschluß der Migration nicht mehr gebraucht wird, außer zu einer eventuellen Lastverteilung, soweit alte Hardware mit neuer Transportsoftware betrieben werden kann.
- Die nächste Lösung ist das Einführen einer Schnittstelle nach der ISO-Transportdienst-Norm 8072, die es gestattet ISO-Produkte über TCP/IP einzusetzen, wie es zum Beispiel der RFC 1006 vorschlägt. Der Vorteil ist, daß es im Netz ein einheitliches Transportprotokoll gibt. Die Migration beschränkt sich zuerst allein auf die Anwendungen und eigene neue Anwendungen können bereits ISO-konform erstellt werden. Nach der vollständigen Migration der Anwendungen kann dann leicht die Transportprotokollsäule ausgetauscht werden.
- Ebenfalls eine Softwarelösung ist das Betreiben zweier Transportprotokolle über ein und dieselbe Hardware, das heißt ein und denselben Netzanschluß. Unter der Voraussetzung, daß die bisherige Hardware genutzt werden kann, ist die Migration auf einen reinen Softwarewechsel beschränkt. Im Rahmen der Realisierung wird hier ein Entscheidungsprogramm benötigt, das erkennt, für welche Protokoll-Familie das ankommende Datenpaket bestimmt ist.
Im Gegensatz zur Variante b) kommen hier die ISO-Kommunikationsanwendungen gleich von Anfang an über ISO-Transportprotokolle zum Einsatz. Nach vollständiger Migration aller Kommunikationsanwendungen kann dann das Entscheidungsprogramm und der TCP/IP-Zweig entfallen.
Freie Wahl für den Anwender
Bei den beiden letztgenannten Lösungsansätzen ist zu beachten, daß Partnersysteme jeweils die gleiche Protokollarchitektur aufweisen müssen, andernfalls wäre wiederum ein Gateway notwendig.
Aufgrund ihrer Anwenderorientierung sieht es die MultiNet-Initiative nicht nur als ihre Aufgabe an, die aktuelle Verfügbarkeit offener Kommunikationsprodukte insbesondere derer nach den allgemein akzeptierten zukünftigen Standards nach ISO aufzuzeigen, sondern auch sich intensiv dem Thema der Migration zu widmen. Der Anwender soll also im Rahmen von MultiNet den Leitfaden finden, der es ihm gestattet, herstellerübergreifende Kommunikation zu verwirklichen und dadurch an Wahlfreiheit für seine Investitionen gewinnen.
Weitere Vorteile für den Anwender liegen in den Forderungen der MultiNet Services GmbH, an die teilnehmenden Anbieter nur verfügbare Produkte zur Demonstration anzumelden und ihre Funktionalität in umfangreichen Tests vor der Messe nachzuweisen. Durch diese Überprüfungen erhält der Anwender Gewißheit, daß das in der MultiNet Halle 14 auf der CeBIT 89 gezeigte Produktspektrum bei ihm einsetzbar ist.
Getestet und für gut befunden
Auch die diesährige Multinet-Veranstaltung hat es sich zur Aufgabe gemacht, dem Anwender "state of the art" der offenen Kommunikation zu zeigen. CeBIT MultiNet '89, die gemeinschaftliche Demonstration herstelleübergreifender Rechnervernetzung, zeigt. daß mit offener Kommunikation zahlreiche Lösungen in heterogenen Netzwerken realisiert werden können. Teillnahmebedingung war, daß alle gezeigten Produkte auch tatsächlich verfügbar sind. Umfangreiche Tests vor der Veranstaltung sollten gewährleisten, daß keine Laborversionen gezeigt werden und die Funktionsfähigkeit der Produkte nachgewiesen ist.
* Karl Reinhard ist ein Geschäftsführer der MultiNet Services mbH, Pulheim/Köln