CW: Was kann man sich unter dem Componentware Consortium vorstellen?
Hubert: Das CWC ist ein offener Zusammenschluß von inzwischen rund 20 Firmen mit einem gemeinsamen Anliegen: Componentware. Ziel ist es, einen Standard für Componentware-Architektur zu etablieren. Das CWC ist in Europa noch in der Startphase, in Deutschland sind noch nicht viele Firmen Mitglied, Siemens ist dabei, wir sind dabei. Es steckt also noch in den Kinderschuhen.
CW: Wie wichtig ist denn die Initiative? Bei Componentware denkt man doch eher an OLE, Java-Applets und Opendoc.
Hubert: Das CWC ist im Vergleich dazu in der Tat sehr viel jünger, nämlich erst rund eineinhalb Jahre alt. Es hat zunächst einmal nur DV-Firmen angesprochen, ob sie der Meinung sind, daß Componentware Zukunft hat, und was nach ihrer Meinung Componentware überhaupt ist. Daraus hat es einen Minimalkonsens gebildet und diesen in eine Architektur umgesetzt. Die Definition von Components ist hier weniger eng gefaßt.
CW: Nämlich wie?
Hubert: Opendoc und OLE sind praktisch angelegt, auf die baldige Entwicklung von Produkten. Das CWC sagt lediglich, wohin die Reise in Sachen Komponenten in den nächsten zehn oder 20 Jahren gehen soll. Plug and play von Komponenten in unterschiedlichen Umgebungen ist das Ziel des Componentware-Konsortiums. Wir möchten Systeme schaffen, deren Lebensdauer nicht begrenzt ist. Wir wollen zu Systemen kommen, die sich evolutionär weiterentwickeln.
CW: Was heißt denn Componentware?
Hubert: Es geht heute immer mehr darum, größere und umfangreichere Systeme zu bauen. Die Zeiten von Inselanwendungen sind vorbei. Wir brauchen heute umfangreiche Anwendungen, die von mehreren Programmierern entwickelt werden, ohne daß die sich jemals treffen, die aber trotzdem miteinander funktionieren. Dafür sind Components gedacht.
CW: Nur sind die Components verschiedener Hersteller nicht unbedingt miteinander zu mischen.
Hubert: Genau das will aber das Konsortium. Die Hersteller müssen sich an gemeinsame Vereinbarungen und Reglementierungen halten. Das ist es, was heute in der Component-Welt fehlt. Wir wollen die stilistischen Richtlinien einbringen, wie sich die Komponenten in einem beliebigen skalierbaren System verhalten.
CW: Ist das eine Frage der Schnittstellen?
Hubert: Viel mehr. Nur Schnittstellen zu haben reicht nicht, um große Systeme zu bauen. Man muß auch explizit verstehen, wie diese Schnittstellen semantisch zusammenpassen. Was werden die Eigenschaften des Systems sein, wie sollen Teile des Systems miteinander kommunizieren, welche Semantik vereint sie? Das nennen wir Architektur. Und bei Architektur sprechen wir von Struktur und Stil. Components sind größer als Objekte und vereinen strukturelle sowie schwer faßbare stilistische, architektonische Eigenschaften.
CW: Die Architektur gibt es ja mit DCOM in der Windows-Welt, mit Opendoc in der Objektwelt.
Hubert: Ja, die haben ihre stilistischen Eigenschaften, ihren semantischen Standard, ihr Referenzmodell als Architektur veröffentlicht. Diese Architektur legt fest, wie ein System aus kleinen, einfachen Bausteinen zu einem System zusammenwächst. Dieser Prozeß ist sehr schwierig. Man kann kleine Bausteine leicht schreiben und testen. Aber ein System beliebig skalierbar, beliebig flexibel zu machen für eine beliebige Anwenderschaft ist die Herausforderung. Componentware ist der Versuch, diesen Schritt zu machen. Es geht also um mehr als Objekte.
CW: Gibt es für diese Aufgabe nicht die Common Object Request Broker Architecture, Corba, der Object Management Group?
Hubert: Corba vereinfacht es, die Verbindung zwischen zwei getrennten Objekten herzustellen, was aber nur einen Teil eines verteilten Systems ausmacht. Weder Schnittstellen noch Corba genügen, um ein evolutionäres System herzustellen, ein System, das der Entwicklung eines Unternehmens mit der Zeit nicht immer mehr hinterherhinkt, sondern sich mit der Zeit inkrementel verbessert. Dafür braucht man stilistische Regeln, wie das System zu wachsen hat, wie die Komponenten miteinander zusammenzuarbeiten haben.
CW: Will die CWC auch Methoden entwickeln, wie man mit Programmiertechniken umgeht?
Hubert: Eher, wie man mit den Werkzeugen umgeht. Ob man beispielsweise Vererbung nutzen darf oder nicht, ist eine stilistische Angabe, mit der ein Softwaredesigner etwas anfangen kann. Sie stellt sicher, daß ein System auf Dauer dieser Richtlinie entspricht und deshalb stabil wächst. Wenn jeder ein anderes Konzept in das System einbringen dürfte, hätte es eben keine Architektur. Das wäre ein ad hoc gewachsenes System wie die meisten Systeme heute - keiner blickt mehr durch.
CW: Die Opendoc-Seite behauptet, sie sei durch Ummantelungstechnik in der Lage, OLE-Objekte einzubinden. Ist das nicht die Lösung?
Hubert: Sie sagen, wir haben eine Architektur. Wenn man ein Opendoc-basierendes System baut, dann muß man diese Architektur zur Grundlage nehmen. Das heißt, es gibt stilistische Richtlinien, wie ich Komponenten baue und wie ich sie benutze. Dazu haben sie definiert, wie man OLE als Untermenge verwenden kann. OLE zu berücksichtigen ist eine Erweiterung. Wenn also die Opendoc- Architektur auf langfristige Sicht die Anforderungen eines Anwenders erfüllt, sollte er Opendoc benutzen.
CW: Da müßte sich doch alle Welt darauf stürzen. Es gibt zwei Architekturen, von denen eine sogar die andere integrieren kann. Fast alle bedeutenden DV-Hersteller unterstützen Opendoc. Warum schreiben die Entwickler nicht Opendoc-Komponenten en masse?
Hubert: Wir sind alle gebrannte Kinder. Jeder hat solche Dinge schon hundertmal erlebt. Opendoc hat auch ein paar unsichere Jahre hinter sich. Wenn eine Firma darauf setzt, kann es sie schnell etliche Millionen Mark kosten, ihre Systeme in diese Richtung zu bewegen. Und es bestimmt zu weiten Teilen ihre zukünftige Strategie. So schnell entscheidet man derlei nicht, sondern läßt erst einmal andere die Sache ausprobieren. Und hier in Deutschland wartet man lieber einige Jahre, bevor man ein Risiko eingeht. Deshalb wird Opendoc eher in den Vereinigten Staaten Fuß fassen. Erst wenn dort Firmen wie AT&T, Boeing oder Texas Instruments mit Opendoc Erfolg haben, werden sich deutsche Unternehmen überlegen, Opendoc in die eigene DV-Strategie aufzunehmen.
CW: Auch bei US-Softwarefirmen ist kein Run auf Opendoc zu erkennen. Auf der letzten Comdex wurden gerade einmal 20 Opendoc- Komponenten vorgestellt, obwohl es Opendoc nicht erst seit gestern gibt.
Hubert: Opendoc war lange keine stabile Entwicklungsumgebung, sondern nur ein Konzept. Erst seit etwa einem dreiviertel Jahr kann man notwendige Opendoc-Entwicklungsumgebungen und die entsprechenden Basiskomponenten kaufen. Das ist für die Software- Entwicklung ein winziger Zeitraum. Es fehlt noch an vielen Dingen. Alle sind skeptisch. Wir haben schon zu viele hoffnungsvolle Ansätze scheitern sehen.
CW: Dann wäre es doch sinnvoll, sich an Mainstreams anzulehnen.
Hubert: Eben. Deshalb haben viele auf die OLE-Welt gesetzt - und viele weitere werden es noch tun. Denn Microsoft ist groß, hat jede Menge Programmierer. Allein diese Masse schafft Vertrauen - egal wie gut oder schlecht die Technologie ist.
CW: Wird also Microsoft den Standard setzen?
Hubert: So weh es mir tut, wahrscheinlich. Aber ich hoffe nicht. DCOM ist als Architektur nicht schlecht. Aber die OLE- Implementierung, das OLE-Referenzmodell - also das, was jeder benutzt - ist überkomplex und ziemlich verhackt.
CW: Verhackt?
Hubert: Umständlich und schlecht geschrieben. OLE ist unsauber und hat keine klaren stilistischen Richtlinien. Schlechter Programmierstil. Auch wenn Microsoft sagt, OLE vereinfache die Welt: Es ist immer noch irre schwierig und fehlerträchtig. Es ist sehr schwer, eine gute OLE-Anbindung zu schreiben. Man muß testen, testen, testen. OLE hält nicht, was die Objekttechnologie und die Component-Technologie versprechen. Daß man es auch viel besser machen kann, zeigt das Beispiel Opendoc. Diese Technik um einiges besser als OLE. Ich neige eher dazu, Opendoc zu benutzen als Microsofts OLE.
CW: Was kann ein Consortium wie das CWC tun, um Fehlentwicklungen aufgrund der Marktmacht eines Unternehmens zu verhindern?
Hubert: Missionarsarbeit. Das heißt, gute Alternativen bringen, um Microsoft etwas Konkurrenz entgegenzusetzen. Java ist im letzten Jahr die große Hoffnung geworden für alle, die noch nicht völlig zur Microsoft-Welt gehören. Inzwischen scheint es diese sogar zu erobern. Um bei den Komponenten zu bleiben: Es müssen große Konsortien kommen und etwas Besseres als Microsoft bieten. Und zwar nicht nur bessere Technologie, einfacher und für große Systeme skalierbar, sondern auch ein besseres Marketing und günstigere Preise.
CW: Günstiger kann es Opendoc kaum geben. Es kostet nichts.
Hubert: Es muß auf viel mehr Betriebssysteme portiert werden. Die Softwaredesigner stehen vor einer Entscheidung: Wähle ich die sichere Seite von Microsoft? Da kann ich nichts falsch machen. Oder nehme ich das bessere Opendoc? Heute sind die Verfügbarkeit einer Software auf möglichst vielen Plattformen und die wirtschaftliche Stärke des Anbieters entscheidend.
CW: Glauben Sie, daß sich die Firmen und Gruppen tatsächlich annähern?
Hubert: Durchaus. In fünf oder zehn Jahren werden die Component- Konzepte und die Komponenten ganz anders aussehen als heute.
CW: Dann wird man nicht mehr von OLE oder Opendoc reden?
Hubert: Die Namen wird es wohl noch geben, aber ihr Inhalt wird sich wandeln. Man lernt ja dazu. Wir sind noch in der Bronzezeit der DV, und neue innovative Technik wird sich durchsetzen. Nicht alle innovativen Köpfe sind bei Microsoft.
CW: Heißt das, ein heutiger Anwender dieser Technik geht ein Risiko ein?
Hubert: Die Frage ist, wer damit arbeitet. Wenn ein erfahrener Softwaredesigner sich die Rosinen rauspickt, hat er durchaus brauchbare Dinge, sogar einige Vorteile. Aber ich würde keinem Programmierer, der gerade mal Objekttechnik gelernt hat, empfehlen, Opendoc oder OLE zu benutzen.