John Minters, Mitglied des X/Open User Council, bewertete die Allianz als "neues Kapitel in der Geschichte von Ositop" und betonte den "grossen Nutzen", den die User-Gemeinde daraus ziehen werde. Zugleich begruesste der X/Open-Anwendervertreter die Gruendung der Arbeitsgruppe "Open System Environment" (OSE) durch Ositop. Diese komme mit ihrem Taetigkeitsfeld der Auffassung von X/Open sehr entgegen, denn dort verstehe man unter offenen Systemen mehr als nur OSI-Loesungen. Waehrend einerseits X/Open von den Erkenntnissen der OSE-Gruppe profitieren koenne, stehe auf der anderen Seite Ositop die Partizipation an dem XPG4-Guide offen.
Im Rahmen der Allianz planen beide Vereinigungen die gegenseitige Entsendung von Repraesentanten in die Gremien von X/Open und Ositop. Darueber hinaus hofft das X/Open User Council, dass es mit Hilfe der neu gewonnen Mitglieder gelingt, den Forderungen in puncto Standards gegenueber Corporate Members kuenftig mehr Nachdruck zu verleihen.
Auch David Alexander, Technical Chairman von Ositop, betonte auf dem Anwendertreffen erneut die Bedeutung offener Standards - gerade in Zeiten des allgemeinen Downsizing. Rueckblickend auf die Normierungsdiskussionen der letzten Jahre fuegte der OSI-Spezialist selbstkritisch hinzu, dass die Anwender jetzt und heute Loesungen fuer die wachsenden Kompatibiltaetsprobleme erwarten, nicht erst in der Zukunft. Deshalb muessten die Aktivitaeten seiner Organisation kuenftig "alle Fragen offener Systeme umfassen und nicht nur OSI".
Vor diesem Hintergrund sehen Insider das OSE-Engagement von Ositop. In der Vergangenheit war der Schwerpunkt der Ositop-Arbeit nach Ansicht von Branchenkennern mehr in der Suche nach geeigneten Protokollen oder passenden Netzwerk-Management-Systemen zu finden, waehrend jetzt das Hauptgewicht der OSE-Group in der Suche nach einem Anforderungsprofil fuer offene Systeme liege, das allen Business-Applikationen gerecht werde.
Dabei tritt, wie bei dem Event in Bruessel deutlich wurde, die Frage nach der eingesetzten Technologie immer mehr in den Hintergrund. Die Kompatibilitaet der einzelnen Komponenten spielt nach Ansicht vieler OSI-Experten eine immer groessere Rolle. Dazu hat die OSE das "Music"-Modell entwickelt, das sich aus den Segmenten Management, User, System, Information und Communications zusammensetzt und den Anwendern bei der Analyse seiner Systembeduerfnisse helfen und ein vorhandenes Know-ledge gap abbauen soll.
Umfassende Klammer des Modells ist das Netz-Management mit Verwaltungs-Tools wie CMIP, ITIL oder DME. Darin eingebettet finden sich die Elemente User, worunter Benutzeroberflaechen wie Windows, Motif etc. zu verstehen sind, sowie Systeme mit Programmierungsfragen auf Systemebene wie Posix.1, XPG4-Base etc. wieder. Der Bereich Information untersucht die Frage nach geeigneten Interfaces zum Informationsaustausch. Die OSE-Group fuehrt hier Abfragesprachen, beispielsweise SQL, IRDS und ODA, auf. Als moegliche Kommunikationsprotokolle nennt die Gruppe TCP/IP und Gosip.
Auch wenn das Music-Modell den DV-Verantwortlichen Hilfestellung bei der Analyse ihrer Systemanforderungen und des Bedarfs an Soft- und Hardware bieten kann, blieb nach Ansicht vieler Experten eine Frage unbeantwortet: Was kann der Anwender heute kaufen und in zehn Jahren noch einsetzen? Oder wie ein IBM-Mitarbeiter am Rande des Meetings hinter vorgehaltener Hand laesterte: "OSI hat die Standards, aber keine Produkte - OSE verfuegt dagegen ueber das Equipment, besitzt jedoch keine Standards."
Wie ein moeglicher Migrationspfad zur offenen OSI-Welt in der Praxis aussehen koennte, untersucht derzeit ein Team unter der Leitung von Harald Nottebohm, dem Projekt-Manager fuer Open Communications Infrastructure (OCI). Angesichts der Tatsache, dass die OSI-Protokolle zu komplex sind und der Markt eine Standardisierung offenkundig nicht will, sucht die Gruppe nach neuen Wegen fuer den Wechsel zur offenen OSI-Welt. Darueber hinaus fehle es, so Nottebohm, an geeigneten Migrations-Tools.
"Die Migrationsprobleme sind in der Vergangenheit wohl unterschaetzt worden," gab der OSI-Experte in der Rueckschau unumwunden zu. Fuer die Zukunft sei daher "eine weiche Evolution" angesagt. Als ersten Schritt empfiehlt der Projekt-Manager eine Abkehr vom starren OSI-Schichtenmodell mit seinen sieben Layern. Eine Architektur, die nur aus drei Schichten bestehe, wuerde seiner Ansicht nach der Situation in modernen Netzen am ehesten gerecht.
Unabhaengig davon spielen fuer den OSI-Verfechter jedoch die Application Programming Interfaces (APIs) eine Schluesselrolle bei der Migration zu offenen Systemen. Diese sollten kuenftig beispielsweise mit entsprechenden Emulationen die Application Layers (Schicht fuenf bis sieben) gegenueber den Transport-Layern abschotten: Mit geeigneten APIs als Transport-Interfaces koennen Applikationen unabhaengig vom verwendeten Transportmedium entwickelt werden.
Darueber hinaus sei als zweites API das "High Level Interface" oberhalb der Layer-Ebene sieben notwendig, um die eigentliche Applikation vollkommen von der Transportebene unabhaengig zu machen. Diese Schnittstelle sei fuer die anwenderbasierten Applikationen bestimmt, waehrend das transportorientierte "Low Level Interface" von den Anbietern der entsprechenden Netzhardware zu programmieren waere. Nottebohms Vision: Applikationen koennten dann mit proprietaeren Applikations-Layern auf offenen Transport- Layern gefahren werden und umgekehrt.
Fuer diese API-Klasse kaemen nach Ansicht Nottebohms beispielsweise die Protokolle X400, FTAM, XDS, XMP, XTI Revised oder SAA CPI-C in Frage. Anwender sollten, so der abschliessende Rat des OSI-Gurus, die entsprechenden APIs unter Beruecksichtigung strategischer Gesichtspunkte auswaehlen: Dabei gilt es in erster Linie zu pruefen, ob die Schnittstellen den OSI-Stack oder die Multiprotokoll- Familie unterstuetzen. Ebenso sei zu bedenken, so der Fachmann weiter, ob eine Standardisierung durch das IEEE-Gremium wahrscheinlich ist und das API eine moegliche Integration zu den OSI-Protokollen unterstuetzt. Wenn es Schule macht, diese Aspekte staerker zu beruecksichtigen, seien die Anwender, so Nottebohm, "fuer zukuenftige Systementwicklungen gut geruestet".