Bisher genoss Microsoft nicht gerade den Ruf, eine Open-Systems- Company zu sein. Diesen Eindruck versucht Richard Tong, General Manager Product Management in der Business Systems Division von Microsoft, im Gespraech mit CW-Redakteur Hermann Gfaller zu zerstreuen.
CW: Es gibt Geruechte, wonach Microsoft versucht, mit OLE (Object Linking and Embedding, Anm. der Redaktion) andere, bereits eingefuehrte Objekttechniken wie Corba oder Opendoc vom Markt zu draengen. Stimmt das?
Tong: Ob Sie es glauben oder nicht, Microsoft mag Corba. Das Ziel dieser Technik, die Interoperabilitaet von Objekten, ist nur zu begruessen. Deswegen engagieren wir uns im Corba-Gremium der Object Management Group (OMG).
CW: Es ist also falsch, dass Microsoft an OLE-Versionen arbeitet, die eine aehnliche Funktionalitaet aufweisen wie Corba?
Tong: Nach meinem Verstaendnis kuemmert sich Corba vor allem um die Zusammenarbeit der verschiedenen Objektmodelle. Aber natuerlich wollen wir die OLE-Technik, so wie sie in Windows integriert ist, weiterentwickeln.
CW: Heisst das, dass OLE auf Microsoft-Plattformen begrenzt bleibt?
Tong: Nein. Unsere Vorstellung von Interoperabilitaet ist nicht auf Corba begrenzt. Das heisst: Wir lizenzieren OLE an andere Systemanbieter. Die bisher vier Lizenznehmer portieren die Technik sowie die Windows-Programmier-Schnittstellen auf Unix. Diese Systeme werden mit einer spaeteren OLE-Version in einer verteilten Umgebung zusammenarbeiten koennen.
CW: Ihr Ziel ist also, fuer die Interoperabilitaet nicht mehr auf Corba angewiesen zu sein?
Tong: Richtig.
CW: Welche Rolle bleibt dann noch fuer Corba?
Tong: Corba stellt vor allem Gateways zwischen den verschiedenen Corba-Implementierungen zur Verfuegung. Auf dieselbe Weise muss auch OLE eingebunden werden. Das ist die Aufgabe unseres Partners Digital Equipment.
CW: DEC hat die Aufgabenverteilung zwischen OLE und Corba einmal so beschrieben, dass OLE auf reine Windows-Umgebungen begrenzt bleibt, waehrend Corba die heterogenen DV-Landschaften anderer Hersteller verbindet. Microsoft braucht daher Corba, um die Windows-LANs an den Rest der Welt anzubinden.
Tong: Das sehe ich genauso. Allerdings gilt die schon erwaehnte Einschraenkung, dass ueber die OLE-Lizenzierung auch Unix-Anbieter unsere Technik in ihren lokalen Netzen verwenden koennen. Um die Microsoft-Position noch einmal ganz klar zu formulieren: Zu kaufen gibt es heute Windows-Clients mit OLE und von Drittanbietern Unix- Clients mit OLE. Wenn der Anwender Zugang zu heterogenen Umgebungen braucht, dann sollte man DECs Object Broker kaufen.
CW: Das klingt, als braeuchten sie die Standardorganisation OMG gar nicht...
Tong: Es koennte ja sein, dass ein Kunde sein Messaging-System
weder von Digital noch von Microsoft kaufen moechte. Hier kommt die OMG ins Spiel.
Die Organisation erstellt nicht Software, sondern Spezifikationen. Damit wird sichergestellt, dass sich Interoperabilitaet auch ohne Microsoft und DEC erzeugen laesst.
CW: Nun hat aber Microsoft gegen die Entscheidung der OMG gestimmt, zwei Technologieausschreibungen fuer eine Corba-OLE- Verbindung herauszugeben. Wie passt das zu ihren bisherigen Corba- Bekenntnissen?
Tong: Es gibt natuerlich OMG-Mitglieder, die Microsoft als ein Unternehmen anschwaerzen wollen, das sich bei offenen Standards unkooperativ verhaelt. Das sind Mitbewerber, die Geruechte streuen in der Hoffnung, dass dann ihre Produkte gekauft werden. Um es klar zu sagen. Wir stehen hinter der Technologieausschreibung. Allerdings haetten wir es lieber gesehen, wenn es nur eine davon gegeben haette und nicht eine fuer die aktuelle OLE-Version und eine fuer OLE 2.
CW: Es heisst, Microsoft wollte die kuenftigen OLE-Versionen aussen vor halten.
Tong: Das stimmt nicht. Wir haben uns gegen die Nennung konkreter Versionen gewehrt, um klarzumachen, dass es eine Schnittstelle fuer alle kuenftigen OLE-Versionen geben sollte. Es macht doch keinen Sinn, fuer jede Version eine neue Schnittstelle zu definieren. Die jetzige Ausschreibung liest sich so, als wuerden wir moeglicherweise mit der uebernaechsten OLE-Variante wieder von Corba abruecken.
CW: Was nicht stimmt?
Tong: Nein. Wir wollen eine Spezifikation, die fuer alle kuenftigen Versionen von OLE gilt, fuer immer.
OLE versus Opendoc
CW: Es gibt noch eine andere Technik, die immer als OLE- Wettbewerber angefuehrt wird: Opendoc.
Tong: Ja, hier gibt es eine Konkurrenz. Sie wissen, dass OLE- Objekte in Opendoc-Umgebungen laufen werden. Insofern koennte man Opendoc als OLE-Clone bezeichnen.
CW: Das sehen Apple und IBM natuerlich anders. Dort wird die OLE- Unterstuetzung lediglich als ein - wenn auch wichtiges - Feature einer ansonsten weit anspruchsvolleren Technik gesehen.
Tong: Das ist eine Frage der Perspektive. Fuer den Anwender ist nur wichtig, dass es einen hohen Grad an Interoperabilitaet gibt. Und hier haben wir den Opendoc-Entwicklern durch die Offenlegung der Spezifikationen des Common Object Model geholfen, die OLE zugrunde liegen.
CW: Worin besteht dann die Konkurrenz?
Tong: Hauptsaechlich darin, dass es mit Opendoc moeglich ist, auch Programme zu schreiben, die OLE nicht unterstuetzen. Man lockt OLE- Entwickler auf Opendoc, weil sich damit Windows-Anwendungen erstellen lassen, ermutigt sie jedoch gleichzeitig, die volle Opendoc-Funktionalitaet auszuschoepfen. Dann aber laufen die Programme nicht mehr in einer Standard-Windows-Umgebung.
CW: Einer der wesentlichen Unterschiede zu OLE liegt darin, dass Opendoc via Corba in heterogenen Umgebungen funktioniert. Gleicht die geplante Corba-Schnittstelle fuer OLE dieses Manko aus?
Tong: OLE ist verfuegbar, Opendoc nicht. Insofern kann man lediglich ueber moegliche Opendoc-Features sprechen. Langfristig gesehen, werden sich aber die beiden Techniken immer aehnlicher. Wichtiger sind die dafuer entwickelten Anwendungen. Dabei kommt es nicht nur auf die Einfachheit der Programmierung an (damit argumentieren Apple und IBM gegen OLE, Anm. der Red. ), sondern auch darauf, wie weit die Schnittstelle und das Betriebssysstem verbreitet sind, fuer die der Entwickler schreibt.