Eine Anwendung von Grund auf neu zu schreiben, liefert wohl den effektiveren und schnelleren Code, doch Zeitaufwand und Kosten sind heute nur noch in Ausnahmefällen akzeptabel. Ohne den Einsatz vorgefertigter Komponenten läßt sich Software heute nicht mehr zu vernünftigen Preisen und in vertretbarer Zeit produzieren. Voraussetzung dafür sind standardisierte Schnittstellen und Verfahren, damit die Komponenten auch zusammenpassen, egal in welchem Land und von wem sie hergestellt wurden.

Dies erlaubt es, daß verschiedene Mitarbeiter einzelne Bestandteile einer Anwendung parallel erstellen oder von außen zukaufen können. So spart man einerseits Zeit durch das parallele Arbeiten an verschiedenen Teilen des Projekts, andererseits muß sich ein Unternehmen fehlendes eigenes Know-how nicht langwierig erarbeiten.

Zum Beispiel können die Komponenten entweder häufig benötigte Funktionen ausführen - wie etwa die eines Editors - oder sie liefern Spezialleistungen, für die besondere Kenntnisse erforderlich sind, etwa beim elektronischen Zahlungsverkehr. Derzeit konkurrieren in der Computerindustrie jedoch noch mehrere Vorschläge für Komponentenmodelle um Anerkennung durch den Markt beziehungsweise die Standardisierungsgremien.

Bis zum offiziellen Standard haben es die Visual Basic Extensions (VBX) von Microsoft zwar nicht geschafft, doch im Windschatten von Windows haben sie ein Modell geschaffen, wie modulare Softwareproduktion aussehen kann: Der Programmierer klickt einfach die gewünschte VBX an und zieht sie mit der Maus in sein Entwicklungsfenster. Selbst muß er dann nur noch sozusagen den Mörtel beimengen, der die Bausteine miteinander verbindet. Das ist im wesentlichen der Programmieraufwand.

Dafür tritt das konzeptionelle Denken stärker in den Vordergrund, denn je sorgfältiger ein Projekt von Anfang an geplant ist, desto reibungsloser paßt hinterher alles zusammen. Die richtige Auswahl der Komponenten und Funktionen spart viel Zeit bei der eigentlichen Anwendungserstellung.

Weil sich auf diese Weise einfach und schnell funktionierende Programme zusammenstellen lassen und der Windows-Markt groß genug ist, haben viele Anbieter eine große Vielfalt entsprechender Bausteine produziert.

Nicht alle davon halten jedoch professionellen Ansprüchen stand. Klein- und Kleinstfirmen in den USA beispielsweise, von dort stammen die meisten dieser Komponenten, sind zu einem weltweiten Support ihrer Produkte überhaupt nicht in der Lage, und den Distributoren hierzulande fehlt das Know-how dafür.

Viele Applikationen, also auch Softwarebausteine, entstehen im Rahmen professioneller kundenspezifischer Projekte. Statt für die immer wieder benötigten Funktionen zur Textbearbeitung jeweils weitere Editoren, Textsysteme, Notizblöcke und dergleichen zu schreiben, werden etwa programmierbare Textsysteme geschaffen. Sie setzen dort ein, wo das in Windows integrierte Edit-Control nicht mehr ausreicht und eigentlich ein Textprogramm aufzurufen wäre. Das ist aber in den meisten Fällen viel zu mächtig, und außerdem bräuchte jeder Benutzer dann auch eine Lizenz für das Textprogramm.

Softwarebausteine dagegen können Entwickler lizenzfrei in ihre Programme einbauen und nach ihrem Bedarf gestalten. Aus dem Fundus an Funktionen wählen sie nur diejenigen aus, die sie im jeweiligen Fall benötigen. Konkret wird eine Dynamic Link Library (DLL) in die Anwendung integriert. Damit verringert sich der Programmieraufwand erheblich, und die Produktivität steigt Projekte lassen sich schneller abwickeln.

Diese Tools sind vor allem für Programmierer gedacht, die mit 4GLs wie Visual Basic oder SQL Windows arbeiten. Schnittstellen für C, C++, Pascal für Windows und andere sind ebenfalls vorhanden.

Da die einzelnen Bestandteile programmierbar sind, läßt sich nicht nur deren Erscheinungsbild in gewissen Grenzen verändern. Vor allem ihr Verhalten können Entwickler weitgehend beeinflussen, weil sie in der Lage sind, beispielsweise fertige Menüpunkte in ihrer Funktionalität zu erweitern. Aufgabe eines Programmierteams ist dann noch die Verbindung dieser Elemente zu einem neuen Ganzen.

Entscheidend dafür sind die genaue Kenntnis des Funktionsumfangs und die vollständige Definition der Schnittstellen, sonst passen am Ende die einzelnen Teile nicht zusammen. Firmenspezifische Projekte sind schneller fertig und die Programme nicht zuletzt auch zuverlässiger, denn der Programmieraufwand verringert sich erheblich. Die Produktivität steigt. Die einzelnen Bausteine sind erprobt und bewährt, weil sie sich wesentlich gründlicher testen lassen als eine komplette Applikation.

Die Entwickler können dem Kunden so relativ schnell einen Prototyp zeigen, auf dessen Basis sie gemeinsam ihre Vorstellungen aufeinander abstimmen. Es ist möglich, Bildschirmmasken, den Datenfluß und ganz generell Details der Applikation noch sehr spät im Projekt zu verändern und teure Mißverständnisse zu vermeiden.

Bei überwiegend herkömmlich programmierten Projekten dagegen stellt sich oft erst kurz vor Schluß heraus, daß die noch ausstehenden 20 Prozent des Codes mehr Aufwand verursachen als sämtliche bisherige Arbeiten. Noch dazu geht es dabei meist um Feinheiten, die für die eigentliche Funktion der Anwendung nebensächlich sind. Die Konzeption läßt sich in diesem Projektabschnitt aber meist nicht mehr ändern, weil andere Teile des Codes auf diese Funktionen angewiesen sind.

Allerdings können VBX über das 16-Bit-Stadium nicht hinauskommen und sind nicht unabhängig von der Entwicklungsumgebung. Daher hat Microsoft die OLE Custom Controls (OCX) geschaffen und darauf aufbauend das Component Object Model (COM) entwickelt. Das Component Object Model, eine Gemeinschaftsentwicklung von Microsoft und Digital Equipment, definiert eine Binär- Schnittstelle, die die einzelnen Bausteine nicht nur unabhängig von der Programmiersprache macht, mit der die Anwendung erstellt wird. Die Bausteine lassen sich so auch nachträglich in Programme einfügen, sofern diese entsprechende Schnittstellen haben.

Diese Schnittstelle ist OLE 2.0. Sie legt fest, wie sich Objekte verhalten müssen, damit Anwendungen sie benutzen und integrieren können. Die darauf aufbauenden OLE Custom Controls (OCX) lassen sich in jeder Programmierumgebung nutzen, die die entsprechende Unterstützung implementiert hat.

OCX bieten weitergehende Möglichkeiten als VBX. Zum Beispiel sind die Property-Pages der OCX leichter zu handhaben als die Property- Listen der VBX, denn damit können Entwickler wie Endanwender die Eigenschaften von Objekten interaktiv einstellen. Wenn Objekte in einem fertigen Programm lediglich dargestellt werden sollen, ist dazu die Ausgangsanwendung nicht erforderlich sollen sie jedoch verändert werden, muß eine dazu geeignete Anwendung verfügbar sein.

Hauptkonkurrent von COM ist Opendoc, eine Gemeinschaftsentwicklung von IBM und Apple. IBMs Beitrag ist das System Object Model (SOM) beziehungsweise die verteilte (distributed) Ausführung DSOM, während Apple die Speicherarchitektur Bento beigesteuert hat. Opendoc ist wesentlich leistungsfähiger und einfacher in der Anwendung als COM, kann sich jedoch nicht auf eine so breite Marktbasis stützen wie OLE. Daher versucht die Object Management Group (OMG), ein internationales Konsortium von über 600 Softwarefirmen, eine herstellerübergreifende Basis für verteilte, heterogene Anwendungen zu schaffen: die Object Management Architecture (OMA).

Die Objekte in den verteilten Anwendungen arbeiten nach dem Marktprinzip zusammen: Anbieterbausteine oder Server-Objekte offerieren ihre Dienste, und Kundenbausteine oder Client-Objekte nehmen diese in Anspruch. Zusätzlich können die Anbieterbausteine auch ihrerseits Unterauftragnehmer einschalten, ohne daß der Auftraggeber davon etwas erfährt. Damit wird das Netz zur Anwendung neuer Qualität und ist nicht mehr nur Transportmittel.

Object Request Broker als Vermittler

Vermittler zwischen Angebot und Nachfrage sind die sogenannten Object Request Broker (ORB), die auf allen Plattformen tätig werden können, auf denen die Common Object Request Broker Architecture (Corba) implementiert ist. ORBs sind bereits von einer Reihe von Herstellern verfügbar, sie lassen sich derzeit aber nur im Rahmen der jeweiligen Plattform einsetzen. Damit sich auch die Object Request Broker verschiedener Hersteller untereinander über TCP/IP oder DCE verständigen können, hat die OMG das General Inter-ORB-Protocol entwickelt, das sich dem jeweiligen Transportprotokoll im Netz anpassen läßt.

Konkrete Gestalt nehmen im Netz verteilte Anwendungen erstmals mit der Programmiersprache Java von Sunsoft an. Hier heißen sie Applets und können etwa die Anwendung zu einem Objekt mitliefern, das in eine HTML-Seite eingebettet ist. Dadurch läßt sich beispielsweise ein Bild auch auf einem System darstellen, auf dem ein geeignetes Grafikprogramm nicht vorhanden ist.

Unnötigen Ballast vermeiden

Auch Microsoft ist inzwischen auf den Internet-Zug aufgesprungen und hat seine OCX zu Active-X weiterentwickelt. Wie mit Java lassen sich auch mit Active-X-Anwendungen in HTML-Seiten einfügen. Allerdings sind die Möglichkeiten von Java und der einfacheren Variante Java-Script erheblich vielfältiger.

Softwarebausteine für das Internet müssen schlank sein, denn die Bandbreite und damit die Übertragungsgeschwindigkeit in Weitverkehrsnetzen wie dem Internet ist vergleichsweise gering. Überflüssiger Funktionsballast muß daher über Bord gehen. Programme herkömmlicher Art, die MBs auf lokalen Festplatten belegen, sind für den Aufruf über das Internet ungeeignet. Softwarebausteine, die schon als OCX vorliegen, lassen sich leicht in Active-X oder auch in Java-Applets überführen und damit Internet-tauglich machen.

Überhaupt tritt mit diesen Applets das Programm selbst noch weiter in den Hintergrund, statt dessen steht die eigentliche Anwendung im Vordergrund. Schließlich will der Anwender etwa einen Brief schreiben, eine Mail lesen oder ein Bild betrachten und nicht ein Textprogramm bedienen oder einen Grafikeditor. Je nachdem, wie weit man die Modularisierung treibt, gibt es dieses Gesamtprogramm dann vielleicht gar nicht mehr, sondern nur noch Funktionsblöcke, die auch von verschiedenen Herstellern kommen könnten.

In diesem Zusammenhang wird zwar oft von Betriebssystem- Unabhängigkeit gesprochen, doch bei näherer Betrachtung erweist sich das als Etikettenschwindel: Die Schnittstelle wird lediglich verlagert und heißt nun Java oder OLE. Die über das Netz geladenen Anwendungen laufen auf jedem Betriebssystem, das diese unterstützt. Immerhin ist die Anpassung an diese Schnittstellen einfacher als an das Betriebssystem. Dessen Besonderheiten bleiben dabei allerdings auch ungenutzt.

Das stürmische Wachstum des Internet eröffnet den Programmierbausteinen neue Möglichkeiten. Was als Hilfsmittel für Programmierer gedacht war, könnte zu neuen Arten von Anwendungen für Nutzer führen. Ihre volle Schubkraft werden sie jedoch nur entwickeln können, wenn allgemein verbindliche Standards ihre universelle Verwendbarkeit sicherstellen.

Angeklickt

Zum Programmieren von Softwarebausteinen gibt es mehrere Ansätze. Ein früher Ansatz war Visual Basic. Microsofts nächster Schritt hieß Component Object Model und die Schnittstelle OLE. Dieses Konzept hat am Markt den größten Zuspruch gefunden. Wesentlich leistungsfähiger und flexibler, dabei aber einfacher zu handhaben, ist die IBM- und Apple-Entwicklung Opendoc. Mit dem Internet-Boom ist Java, eine ganz neue Generation von Programmiersprachen, populär geworden. Sie vereinfacht die Entwicklung sogenannter Applets, die schon im Konzept eine Interaktion dieser Miniapplikationen vorsieht. Dieser Beitrag erläutert die Grundzüge dieser Methoden.

Microsoft versus OMG

Zu den verbreiteten Objektmodellen zählen das Microsoft-eigene Konzept OLE/COM - beziehungsweise die angekündigte 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 Standardschnittstelle für die Integration von PC-Anwendungen durchgesetzt - auch wenn es wegen seines üppigen Ressourcenverbrauchs nicht gerade zum Einsatz ermuntert. Die OLE- Spezifikationen, das Microsoft-eigene Common Object Model (COM) und die Programmiersprache Visual Basic bilden das Gerüst für die "OLE Control Extension" (OCX). Die damit von Third-Party-Firmen entwickelten Software-Anwendungen sollen sich ohne die üblichen Schnittstellenprobleme in jede bestehende OLE/COM-Implementierung einfügen lassen.

Dadurch, daß Microsoft die OLE/COM-Spezifikationen kontrolliert, hat sich das Unternehmen eine Schlüsselposition im Componentware- Markt gesichert. Ein kleines Software-Unternehmen, das sich eine Nische im Windows-Markt sichern will, wird wohl kaum umhinkommen, in die OCX-Entwicklung einzusteigen.

Während OLE unter Windows funktioniert, wurde die Integrationsplattform Opendoc von vornherein für unterschiedliche Betriebssysteme - OS/2, Unix und Macintosh - konzipiert.

Als Objektmodell können 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. Weil Opendoc eine Corba-Implementierung als Transportmittel nutzt, taugt das Gemeinschaftsprodukt von IBM und Apple auch für die Integration verteilter Anwendungskomponenten im Netz.

*Rolf Heiler ist Geschäftsführer des System- und Softwarehauses Heiler Software in Stuttgart.