Melden Sie sich hier an, um auf Kommentare und die Whitepaper-Datenbank zugreifen zu können.

Kein Log-In? Dann jetzt kostenlos registrieren.

Falls Sie Ihr Passwort vergessen haben, können Sie es hier per E-Mail anfordern.

Der Zugang zur Reseller Only!-Community ist registrierten Fachhändlern, Systemhäusern und Dienstleistern vorbehalten.

Registrieren Sie sich hier, um Zugang zu diesem Bereich zu beantragen. Die Freigabe Ihres Zugangs erfolgt nach Prüfung Ihrer Anmeldung durch die Redaktion.

Software-Entwicklungstrends/Applikationen aus dem Code-Baukasten?


17.07.1998 - 

Hindernisse und Aussichten für den Hoffnungsträger Componentware

Die Vision, Softwarebausteine individuell zu neuen Gebilden sprich Anwendungen zu kombinieren, beginnt Wirklichkeit zu werden. Die Zahl der Anbieter von Software aus einzelnen, erweiterbaren Elementen wächst ständig. Komponenten wie Active X und Javabeans sind bereits heute sehr verbreitet.

Da auch Monolithen in kleinere Bestandteile aufgesplittet werden, verwundert die Einschätzung der Gartner Group nicht: Der Anteil komponentenbasierter Applika- tionsentwicklung für Lösungen für den unternehmensweiten Einsatz bis zum Jahr 2001 soll 60 Prozent betragen.

Noch beherrscht Standardsoftware den Markt. Doch stößt sie an ihre Grenzen: Trotz vielfältiger Funktionen deckt sie nur 50 bis 70 Prozent der Anforderungen von Unternehmen ab. Zudem sind diese Programme komplex, und ihre Anpassung oder Erweiterung ist zeit- und kostenintensiv, was nicht recht zur steigenden Dynamik von Geschäftsprozessen und zur Verkürzung von Technologiezyklen paßt.

Component-based Development (CBD) bietet demgegenüber entscheidende Vorteile. Sie basiert auf dem Grundgedanken, eine Anwendung so zu konzipieren, daß sich Teile daraus in anderen Anwendungen wiederverwenden oder von vornherein als Standardkomponenten einsetzen lassen.

Die Crux liegt genau hier: Geschäftskritische, individuelle Anwendungen müssen so zerlegt werden, daß die Allgemeingültigkeit und damit Wiederverwendbarkeit der Komponenten gewährleistet ist. Wenn es gelingt, beschleunigen wiederverwendbare eigene oder zugekaufte Komponenten die Software-Entwicklung und verbessern deren Qualität.

Dieser Schritt hin zu CBD ähnelt dem Weg von Manufaktur über Massenproduktion zur Montage vorfabrizierter Bauteile in der industriellen Fertigung. Die Massenproduktion ist heute flexibler als zu Zeiten des ersten Ford-T-Modells, bei hoher Qualität.

Grundlegendes Prinzip der Komponententechnologie ist die Trennung des Was - welche Dienste bietet eine Komponente an - vom Wie - wie gestaltet sich die technische Umsetzung. Dies ermöglicht erst die Wiederverwendung von Komponenten in Anwendungen verschiedenster Größe und Ausprägung. Dazu bedarf es einer standardisierten Vorgehensweise für das Hinzufügen von Teilen zu einer Applikation, für die Bestimmung des Verhaltens einer Komponente und das Ersetzen einer Komponente.

Zweitens lassen sich gemeinsame Dienste nur auf eine genau spezifizierte Art und Weise nutzbar machen. Dies ist zum Beispiel wichtig für Aufgaben, die für eine oder mehrere Applikationen möglicherweise auch über verschiedene Betriebssysteme hinweg gelten sollen, etwa für Sicherheitsstufen in Applikationen.

Drittens ist für die Kommunikation und Koordination der einzelnen Bestandteile eine gemeinsame Infrastruktur nötig. Als Infrastrukturelemente kommen dabei vor allem die Common Object Request Broker Architecture (Corba), das Distributed Component Object Model (DCOM) und Java in Frage (siehe Kasten). Softwarekomponenten, die nach diesem Standard modelliert werden, sind plattformübergreifend austauschbar.

Soweit die Theorie. In der Praxis krankte komponentenbasierte Software-Entwicklung für den unternehmensweiten Einsatz insbesondere an adäquaten Methoden sowie an der fehlenden Basis für die Interoperabilität der einzelnen Bausteine. Diese ist jetzt mit den Infrastrukturbausteinen Corba, DCOM und Java, einer einheitlichen Notation, der Unified Modelling Language (UML), und einem allgemein zugänglichen Component Catalogue, dem MS Repository, gegeben. Hier können Anbieter ihre Komponentenbeschreibungen ablegen und allgemein verfügbar machen.

Corba und Java stehen allerdings in direkter Konkurrenz zu DCOM. Beide Infrastrukturkomponenten existierten bisher auch getrennt voneinander. Zwar hat die Object Management Group jüngst beschlossen, daß Corba zukünftig mit Microsoft-Komponententechnik DCOM zusammenarbeiten soll und auch Microsoft selbst hat auf Druck großer Kunden Verbindungsoptionen zu Corba zumindest für den Transaktionsbereich angekündigt. Wie weit diese Öffnung zum Konkurrenzmodell aber gehen wird, ist noch nicht klar.

In den Sternen steht auch, wann die Infrastrukturumgebungen direkt miteinander interoperabel sein werden. Die Entscheidung für eine Technologie impliziert somit bis auf weiteres auch die Entscheidung gegen das andere Modell.

Jenseits dieser Differenzen litt Componentware an einem Manko, was die Abbildung von Geschäftsprozessen und -modellen sowie deren Änderung betraf: Tools, die den komplexen Anforderungen in puncto Applikationsentwurf sowie Identifikation, Spezifizierung und Zusammenstellung von Komponenten gerecht werden, gab es bisher nicht. Doch auch hier hat sich was getan. Der Durchbruch für die komponentenbasierte Software-Entwicklung wird nicht mehr von der Technologie gebremst. Die ist jetzt grundsätzlich verfügbar. Gegenwärtig liegt die Schwierigkeit nicht nur in der Unreife des Marktes, sondern vor allem in fehlenden Methoden, die den für die Wiederverwendung optimalen Zuschnitt von Komponenten ermöglichen. In der Praxis ist dies die größere Herausforderung.

Es gibt momentan nur wenige tatsächlich erhältliche Entwicklungswerkzeuge, die optimal auf die Grundanforderungen von Identifikation, Spezifizierung und Erstellung unternehmensweiter Komponenten zugeschnitten sind. Betriebswirtschaftlich muß der Return on Investment erheblich höher liegen als vorher, und die Entwickler müssen das Verfahren als die Methode der Zukunft für die Software-Entwicklung in heterogenen Unternehmenslandschaften betrachten.

Wichtig sind die Erfolge und Erfahrungen von Betrieben, die heute CBD einsetzen. Ihre Berichte dürften zu einer wachsenden Marktdurchdringung in den nächsten drei bis fünf Jahren erheblich beitragen.

Ein weiteres Hindernis bei der Einführung komponentenbasierter Applikationsentwicklung stellt die IT-Organisation vieler Firmen dar. Die Einführung der Komponentenmethode bedingt wie jeder ganzheitliche Software-Ansatz eine radikale Änderung in Organisation und Struktur. Das Denken in geschlossenen Anwendungen muß zum Denken in Komponenten werden. Die wichtigsten Komponentenmodelle wie Corba, DCOM und Javabeans werden in den nächsten Monaten weiter verfeinert und verbessert. Ein Trend dabei ist die zunehmende Interoperabilität der Infrastrukturbausteine untereinander.

Der zweite Trend ist die zunehmende Unterstützung der UML von Corba-IIOP, Active X und Java durch Anbieter von Entwicklungs-Tools.

Ein weiterer Trend ist die Standardisierung von einfachen Abläufen, die in vielen Applikationen gemeinsam auftreten.

Fazit: Die komponentenbasierte Methode wird sich als das führende Verfahren für die Software-Entwicklung durchsetzen, sobald zwei Haupthindernisse überwunden sind: Erstens muß der richtige Zuschnitt von Komponenten gewährleistet sein, das heißt die Zusammenfassung allgemeingültiger Funktionen mit dem Ziel der Wiederverwendung. Zweitens werden geeignete Methoden sowie eine wachsende Zahl vorhandener Unternehmenskomponenten zum Bewußtseinswandel in den Betrieben führen.

Corba etc.

Corba steht als Oberbegriff für Schnittstellen-Definitionen und besteht im wesentlichen aus dem Object Request Broker (ORB) und Diensten, beispielsweise für Sicherheit oder netzeinheitliche Bezeichnungen (Naming Conventions). Festgelegt hat diese Definitionen die Object Management Group (OMG) mit dem Ziel, plattformübergreifende Standards für Software-Objekte zu schaffen. Mitglieder sind mehr als 700 Hersteller, darunter auch Microsoft.

Der ORB umfaßt Software für die Verwaltung und Verbindung verteilter Softwarekomponenten. Er stellt für die Programmobjekte die Verbindung zu anderen Objekten her, ohne daß der Arbeitsplatzrechner wissen muß, wo im Netz sich die andere Komponente befindet. Die Kommunikation einzelner ORB vollzieht sich über TCP/IP und das Internet-Inter-ORB-Protokoll (IIOP).

Dem ORB sehr ähnlich ist DCOM, das proprietäre Microsoft-Protokoll für das Zusammenwirken verteilter Active-X-Komponenten. Hinter der Bezeichnung Active X können sich neben Active-X-Controls beispielsweise zusammengesetzte Dokumente, Scripting und Datenbankzugriffe verbergen. Active-X-Controls stellen einen eigenständigen Binärcode mit einer definierten Kommunikationsschnittstelle dar. Für jede Plattform ist ein eigener Binärcode nötig; aktuell werden nur Microsoft-Plattformen unterstützt.

Angeklickt

Komponenten sollen in den nächsten Jahren die Neuentwicklungen von Software beherrschen, doch bisher hat sich das Marktwachstum von Componentware in Grenzen gehalten. Gründe dafür sind im Fehlen geeigneter Methoden, in der geringen Zahl am Markt verfügbarer Komponenten, in den großen Investitionen in vorhandene Programme sowie in der Unternehmenskultur zu suchen. Inzwischen aber sind immerhin Methoden, notwendige Infrastrukturbausteine sowie erste Komponentenentwicklungs-Tools verfügbar.

Mario Mees ist Geschäftsführer der Sterling Software II GmbH in Düsseldorf.