Heute schon findet die eigentliche Programmentwicklung kaum noch in den Anwenderunternehmen statt. Die Meta Group Inc., Stamford, Connecticut, traegt dem Trend bereits Rechnung. Sie wird, wie der deutsche Geschaeftsfuehrer Luis Praxmarer verraet, ihre Abteilung Application Development Strategies demnaechst umbenennen - in Deployment Strategy Services. "Die Integration ist die Herausforderung der Zukunft", erlaeutert Praxmarer. "Der Entwickler ist nicht mehr jemand, der C-Code schreibt, sondern jemand, der Schnittstellen zusammenbringt."
Das Prinzip der Lego-Bausteine
In letzter Konsequenz wird sich dieses Prinzip auf allen Systemebenen wiederfinden: in der unternehmensweiten Anwendungsumgebung und in den einzelnen Applikationen gleichermassen. Componentware-Konzepte, wie sie bereits viele Anbieter propagieren, laufen darauf hinaus, dass auf der Basis gemeinsamer Schnittstellen beliebige Softwareteile miteinander integriert werden koennen.
Im Umfeld fest umrissener Applikationen hat sich dieses "Lego"- Prinzip bereits vor Jahren durchgesetzt. Neu ist die Moeglichkeit, Anwendungen unterschiedlichster Art zu einem durchgaengigen System zu verbinden.
Das erste Software-Unternehmen, das die Realisierbarkeit dieser Idee mit konkreten Produkten nachweisen wollte, war die Steven- Jobs-Company Next. Schon vor vier Jahren veroeffentlichte sie einen Katalog von extern entwickelten Softwarekomponenten, die sich wie die Teile eines Puzzles in eine "Nextstep"-Umgebung einpassen lassen sollten. Dieser Ansatz funktionierte damals allerdings nur innerhalb der geschlossenen Entwicklungs- und Betriebsumgebung von Next.
Einen Schritt weiter gehen Architekturentwuerfe, die auf einem weithin akzeptierten Objektmodell basieren. Dazu zaehlen das Microsoft-eigene Konzept OLE/ COM - beziehungsweise die angekuendigte Nachfolge-Architektur Distributed OLE - sowie das von IBM und Apple vorangetriebene Opendoc/Corba.
Object Linking and Embedding (OLE) hat sich in der Windows-Welt als Standard-Schnittstelle fuer die Integration von PC-Anwendungen durchgesetzt - auch wenn es wegen seines ueppigen Ressourcenverbrauchs nicht gerade zum Einsatz ermuntert. Die OLE- Spezifikationen, das Microsoft-eigene Common Object Model (COM) und die Programmiersprache Visual Basic bilden das Geruest fuer die "OLE Control Extension" (OCX). Diese von Third-Party-Firmen entwickelten Software-Anwendungen sollen sich ohne die ueblichen Schnittstellen-Probleme in jede bestehende OLE/COM-Implementierung einfuegen lassen.
Dadurch, dass Microsoft die OLE/COM-Spezifikationen kontrolliert, hat sich das Unternehmen eine Schluesselposition im Componentware- Markt gesichert. Ein kleines Software-Unternehmen, das sich eine Nische im Windows-Markt sichern will, wird kuenftig wohl kaum umhinkommen, in die OCX-Entwicklung einzusteigen.
Waehrend OLE unter Windows funktioniert, wurde die Integrationsplattform Opendoc von vornherein fuer unterschiedliche Betriebssysteme - OS/2, Unix und Macintosh - konzipiert.
Dieser Vorteil ruehrt nicht zuletzt daher, dass es sich dabei um ein Gemeinschaftsprojekt von IBM und Apple handelt.
Als Objektmodell koennen Opendoc-Entwickler sowohl COM als auch das System Object Model (SOM) der IBM nutzen. SOM entspricht der Common Object Request Broker Architecture (Corba), auf die sich die Mitglieder der Object Management Group (OMG) geeinigt haben. Da Opendoc eine Corba-Implementierung als Transportmittel nutzt, taugt das Gemeinschaftsprodukt von IBM und Apple auch fuer die Integration verteilter Anwendungskomponenten im Netz. Folglich konkurriert Opendoc weniger mit OLE als mit dem bislang noch nicht verfuegbaren Distributed OLE.
Auch die Microsoft-Fraktion bemueht sich mittlerweile darum, den auf der Server-Seite etablierten Corba-Standard zu beruecksichtigen. Digital Equipment hat die Aufgabe uebernommen, Corba und Distributed OLE unter einen Hut zu bringen.
Das von Corba verkoerperte Prinzip des Object Request Broker spielt auch die zentrale Rolle in einer Zukunftsvision, die die Object Management Group publiziert hat: Demzufolge kann sich ein Entwickler, der eine bestimmte Funktion benoetigt, aus einem im Intenet bereitgestellten Objektfundus bedienen. Sollte dieses spezielle Objekt noch nicht vorhanden sein, ist der Entwickler aufgerufen, die von ihm selbst erarbeitete Loesung dort hineineinzustellen, damit sie anderen Software-Ingenieuren zur Verfuegung steht. Wenn alle diese Objekte gemaess den Corba- Spezifikationen entwickelt sind, lassen sie sich, so die OMG, im Internet adressieren und in einer gemeinsamen Software-Umgebung nutzen.
Dieses Componentware-Konzept auf hoechster Ebene ist derzeit noch Zukunftsmusik. Seiner Realisierung einen Schritt naeher kommt es dann, wenn Sunsoft - wie angekuendigt - seine Programmiersprache Java mit Corba in Einklang gebracht haben wird.
Java ist eine auf C++ basierende Interpreter-Sprache, die Sunsoft entwickelt hat, um den statischen Informationseinheiten ("Pages") des World Wide Web (WWW) ausfuehrbaren Softwarecode ("Applets") hinzuzufuegen. Die Softwaretochter des Rechnerlieferanten Sun Microsystems plant eigenen Angaben zufolge, ihre Corba- Implementierung zu nutzen, um den Entwicklern die Suche nach geeigneten Softwarekomponenten im WWW zu erleichtern - egal, ob es sich nun um ein Java-Applet, ein OCX oder ein mit "Web Objects" von Next erstelltes Stueck Software handelt.
Java als kleinster gemeinsamer Nenner
Java ist im Augenblick der kleinste gemeinsame Nenner, auf den sich die gesamte Softwarebranche geeinigt zu haben scheint. Sogar Microsoft hat eine Lizenz der Programmiersprache erworben. Gleichzeitig arbeitet der Desktop-Marktfuehrer allerdings an einem Konkurrenzprodukt mit der Bezeichnung VB Script. Ob sich diese Visual-Basic-aehnliche Sprache am Markt durchsetzen wird, haengt davon ab, ob die Anbieter der gaengigen Web-Browser auf diesen Zug aufspringen werden. Ihr entscheidender Nachteil duerfte sein, dass sie nur mit den Microsoft-eigenen Betriebssystemen arbeitet.
Als relativ gesichert gilt, dass fast alle Anbieter herkoemmlicher Entwicklungssysteme ueber kurz oder lang Java-Schnittstellen bereitstellen werden. Sinnvoll waere es, die traditionellen Werkzeuge dahingehend zu erweitern, dass sie Java-Code als Alternative zu ihren eigenen Sprachen generieren koennen.
Noch attraktiver wird die Sunsoft-Entwicklung moeglicherweise durch die in Aussicht gestellten Compiler, die den fuer Interpreter- Sprachen typischen erhoehten Speicherbedarf verringern werden. Insider warnen allerdings davor: Der Performance-Gewinn koennte leicht auf Kosten der Betriebssystemunabhaengigkeit und der Sicherheit gehen.
Unternehmen, die jetzt die Weichen fuer ihre kuenftige Softwarestrategie stellen muessen, sind nicht zu beneiden. Im Zuge der Internet-Euphorie ist der Markt so schnellebig geworden, dass langfristige Entscheidungen schwerfallen. Eines wenigstens ist sicher: Ob mit oder ohne Componentware - um eine fundierte Analyse ihrer Geschaeftsprozesse und ein solides Anwendungsdesign wird eine grosse verteilte Organisation auf keinen Fall herumkommen.